Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Normas Técnicas en
Tecnologías de Información y
Comunicaciones
Introducción
Las Normas técnicas para la gestión y el control de las tecnologías de información (TI),
en adelante referidas como NT, según la resolución No. R-CO-26-2007 mediante la
cual se emitieron, constituyen los criterios básicos de control que deben ser observados
en la gestión institucional de esas tecnologías, de frente a un adecuado uso de los
recursos invertidos en ellas y a facilitar su control y la fiscalización.
De manera congruente con este objetivo, estos criterios básicos de control sobre las
TI se incorporan a las Normas de Control Interno para el Sector Público, N-2-2009-
CO-2009, como lo consigna la norma No. 5.9:
Alcance
Como lo dictan las referidas Normas, la Contraloría y las instituciones y órganos sujetos
a su fiscalización, ha contado con dos años a partir del 31 de julio de 2007, para
cumplir con la serie de criterios básicos de gestión y control de las NT.
4 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Metodología
Capítulo I
Normas de Aplicación General
1.1 Marco estratégico de TI
La organización debe responder adecuadamente a las amenazas (ver este concepto con
respecto a la definición , no son solo amenazas) que puedan afectar la gestión de las
TI, mediante una gestión continua de riesgos que esté integrada al sistema específico
de valoración del riesgo institucional y considere el marco normativo que le resulte
aplicable.
La organización debe administrar sus proyectos de TI de manera que logre sus objetivos,
satisfaga los requerimientos y cumpla con los términos de calidad, tiempo y presupuesto
óptimos preestablecidos.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 15
La organización debe identificar y velar por el cumplimiento del marco jurídico que
tiene incidencia sobre la gestión de TI con el propósito de evitar posibles conflictos
legales que pudieran ocasionar eventuales perjuicios económicos y de otra naturaleza.
La organización debe lograr que las TI apoyen su misión, visión y objetivos estratégicos
mediante procesos de planificación que logren el balance óptimo entre sus requerimientos,
su capacidad presupuestaria y las oportunidades que brindan las tecnologías existentes
y emergentes.
b. Establecer el respaldo claro y explícito para los proyectos de TI tanto del jerarca
como de las áreas usuarias.
f. Contar con una definición clara, completa y oportuna de los requerimientos, como
parte de los cuales debe incorporar aspectos de control, seguridad y auditoría bajo
un contexto de costo – beneficio.
3.2.3 La UTI mantiene tres ambientes: uno para los sistemas que se
encuentran productivos y operando, uno para desarrollo de aplicaciones
y otro para capacitación y pruebas a realizar por los equipos de trabajo
que se encuentran implementando software. La administración de los
permisos está bajo responsabilidad del administrador de base de datos
(DBA) y del administrador de sistemas operativos en ausencia del DBA,
según se establece en la Metodología para desarrollo de proyectos.
f. Controlar las distintas versiones de los programas que se generen como parte de su
mantenimiento.
a. Observar lo que resulte aplicable de las normas 3.1, 3.2 y 3.3 anteriores.
La organización debe tener claridad respecto de los servicios que requiere y sus
atributos, y los prestados por la Función de TI según sus capacidades. El jerarca y la
Función de TI deben acordar los servicios requeridos, los ofrecidos y sus atributos, lo
cual deben documentar y considerar como un criterio de evaluación del desempeño.
Para ello deben:
La organización debe asegurarse de que los datos que son procesados mediante TI
corresponden a transacciones válidas y debidamente autorizadas, que son procesados
en forma completa, exacta y oportuna, y transmitidos, almacenados y desechados en
forma íntegra y segura.
La organización debe asegurar que los servicios contratados a terceros satisfagan los
requerimientos en forma eficiente. Con ese fin, debe:
c. Vigilar que los servicios contratados sean congruentes con las políticas relativas a
calidad, seguridad y seguimiento establecidas por la organización.
Capítulo V Seguimiento
5.1 Seguimiento de los procesos de TI
5.2.1 La UTI debe rendir cuentas sobre la gestión con base al PTAC
y al PAO, además de que todos los funcionarios de la institución se
convierten en controladores de la buena operación de la tecnología en
uso. Adicional, la Unidad de Gobierno Corporativo le da seguimiento al
cumplimiento del PTAC.
44 / Normas Técnicas en Tecnologías de Información y Comunicaciones
5.3.1 Esta es una labor que se mantiene muy bien ejecutada por
la Auditoría Interna de la CGR, suministrando recomendaciones de
valor agregado para el fortalecimiento del control interno. Ver informes
recientes 2007-2009 y oficios de atención de recomendaciones.
Productos elaborados
Producto Fecha
NTP0-Diagnóstico Inicial Dic. 2007
NTP1-Cronograma de implementación Ene.2008
NTP2-Plan de Implementación Ene.2008
NTP3-Evaluación de riesgos en TI Mar.2008
NTP4-Instrumento metodológico MAI Jun.2008
NTP5-Diagnóstico Inicial MAI Jun.2008
NTP6-Informe de gestión 2008-01 Jul.2008
NTP7-Metodología para el desarrollo de Proyectos en TI Jul. 2008
NTP8-Marco General para la gestión de calidad en TI Ene.2009
NTP9-Modelo de Arquitectura de información Mar.2009
NTP10-Marco de Seguridad en TI May.2009
Normas Técnicas en Tecnologías de Información y Comunicaciones / 45
Conclusiones
Con base a los resultados obtenidos es claro que la Contraloría General de la República
ha logrado un cumplimiento razonable de la normativa, generando un conjunto de
productos que le servirán de base para evolucionar a modelos de madurez superiores
a los actuales.
Introducción
Con base al análisis grupal realizado por los coordinadores de las diferentes áreas
de servicio de la USTI y de la jefatura de Unidad, se establece para cada una de las
normas técnicas el producto esperado y las acciones a realizar para cerrar la brecha
que pudiese existir entre la situación actual y lo requerido por las normas técnicas.
Cuando las acciones son de índole normales; es decir operativas, se indica con la
frase: “Labor Permanente” y no se incluyen en el cronograma.
Este documento es la base para la elaboración del cronograma plurianual que estará
siendo ejecutado hasta el 30 de junio del 2009.
50 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
Producto
Aplicación institucional de la Guía Metodológica para desarrollo de sistemas.
Acciones
Situación actual
Producto
Manual de seguridad y utilización de las TIC, recién aprobado por el Consejo Consultivo.
Acciones
Situación actual
Se tienen los recursos clasificados por criticidad, así como una evaluación de riesgos, y
un plan de implementación de la seguridad. Se realizan los análisis de comportamiento
de la seguridad constantemente y se debe fortalecer la capacitación del personal.
Producto
Acciones
Para ello, el jerarca, por sí o mediante el funcionario que designe al efecto, debe:
Situación actual
Producto
Acciones
• Plan de divulgación.
• Impartir charlas.
Situación actual
Producto
Acciones
Situación actual
Se mantienen medidas de seguridad muy efectivas, las cuales podrían ser fortalecidas
con la puesta en marcha de la firma digital en coordinación con el Banco Central. Se
tienen procedimientos para la protección de la información almacenada en los medios
magnéticos bajo control y custodia de la USTI. Se cuenta con medidas altamente
preventivas y correctivas contra software malicioso o virus.
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Producto
Situación actual
Producto
Acciones
La organización debe identificar y velar por el cumplimiento del marco jurídico que
tiene incidencia sobre la gestión de TI con el propósito de evitar posibles conflictos
legales que pudieran ocasionar eventuales perjuicios económicos y de otra naturaleza.
Situación actual
Producto
Acciones
La organización debe lograr que las TI apoyen su misión, visión y objetivos estratégicos
mediante procesos de planificación que logren el balance óptimo entre sus
requerimientos, su capacidad presupuestaria y las oportunidades que brindan las
tecnologías existentes y emergentes.
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
Además, debe brindar el apoyo necesario para que dicha Función de TI cuente con
una fuerza de trabajo motivada, suficiente, competente y a la que se le haya definido,
de manera clara y formal, su responsabilidad, autoridad y funciones.
Situación actual
Al depender en el último año directamente del Despacho, los logros han sido altamente
satisfactorios, producto de mantener una independencia funcional que ha facilitado la
puesta en marcha de TI en la CGR.
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Para el desarrollo de proyectos se utiliza la Guía Metodológica la cual cubre los puntos
de la norma 3.1. Existe independencia de los proveedores excepto en lo que concierne
a reparación de equipos, lo cual se cubre vía contratos de mantenimiento.
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
La USTI ha contado con el apoyo del Despacho para la adquisición razonable de las
tecnologías necesarias para mantener una infraestructura tecnológica optimizada y
acorde con las necesidades de la CGR.
Producto
Acciones
a. Observar lo que resulte aplicable de las normas 3.1, 3.2 y 3.3 anteriores.
b. Establecer una política relativa a la contratación de productos de software
e infraestructura.
c. Contar con la debida justificación para contratar a terceros.
d. Establecer un procedimiento o guía para la definición de los “términos de
referencia” que incluyan las especificaciones y requisitos o condiciones
requeridas o aplicables, así como para la evaluación de ofertas.
e. Establecer, verificar y aprobar formalmente los criterios, términos y conjunto
de pruebas de aceptación de lo contratado; sean instalaciones, hardware
o software.
72 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Situación actual
Producto
Acciones
La organización debe tener claridad respecto de los servicios que requiere y sus
atributos, y los prestados por la Función de TI según sus capacidades.
El jerarca y la Función de TI deben acordar los servicios requeridos, los ofrecidos y sus
atributos, lo cual deben documentar y considerar como un criterio de evaluación del
desempeño. Para ello deben:
Situación actual
Los servicios ofrecidos han sido previamente autorizados por el Despacho y se tiene
claridad con respecto a disponibilidad, confidencialidad e integridad de la ellos.
Es conveniente documentar los acuerdos y la forma de evaluación que se estaría
realizando para cada servicio.
74 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Producto
Acciones
Situación actual
Producto
Acciones
La organización debe asegurarse de que los datos que son procesados mediante TI
corresponden a transacciones válidas y debidamente autorizadas, que son procesados
en forma completa, exacta y oportuna, y transmitidos, almacenados y desechados en
forma íntegra y segura.
76 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Situación actual
Los datos procesados por TI se generan con base a transacciones autorizadas por cada
una de las unidades relacionadas con los sistemas. Es necesario definir una política
para desechar datos, de común acuerdo con los patrocinadores de los sistemas,
verificando la existencia de los procedimientos adecuados.
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
La organización debe asegurar que los servicios contratados a terceros satisfagan los
requerimientos en forma eficiente. Con ese fin, debe:
78 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Situación actual
Los contratos son administrados; según área de trabajo, por los coordinadores
respectivos.
Producto
Acciones
Capítulo V Seguimiento
5.1 Seguimiento de los procesos de TI
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
Situación actual
Producto
Acciones
Conclusión
De acuerdo con los análisis realizados, es totalmente viable y factible cumplir con
la normativa en el plazo establecido, siendo la actualización del modelo para la
Normas Técnicas en Tecnologías de Información y Comunicaciones / 81
El siguiente cronograma muestra los plazos estimados de las actividades generales que permitirán obtener un nivel de cumplimiento razonable con las
normas técnicas. Este instrumento detalla solamente las normas para las cuales la Comisión consideró aplicar esfuerzos de mejoramiento.
Introducción
Se tiene una red de área local, con sistemas tolerantes a fallas y con capacidad
para enlazar a los funcionarios con sistemas de información automatizados, correo
electrónico, intranet e Internet. Ahora bien, en vista de la importancia que reviste la
conectividad y las nuevas tendencias móviles de la comunicación tecnológica, resulta
90 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Finalmente, se cuenta con varios sistemas de información que soportan tanto las
tareas sustantivas como las de apoyo al nivel institucional; considerándose algunos
como muy críticos.
Contexto estratégico
Otro aspecto que es de importancia para la CGR es la imagen que se pueda reflejar
a la ciudadanía, con el objetivo de mantener y mejorar la confianza que se tiene en la
institución como garante de la Hacienda Pública.
Para dar cumplimiento al propósito de fortalecer el buen gobierno, todos los funcionarios
deben tener presentes aspectos importantes de nuestra gestión, como los siguientes:
Visión de la CGR
Misión de la CGR
Valores
Los siguientes elementos constituyen la guía de actuación que debe inspirar la gestión
y rectitud de los actos de los funcionarios de la Contraloría General de la República, a
efecto de implementar la visión y misión institucionales:
• Justicia: Dar a los demás lo que les corresponde de acuerdo con sus
derechos y deberes.
• Integridad: Es realizar todas las acciones con rectitud.
• Compromiso: Es sentirse identificado con la Contraloría General y así dar el
máximo esfuerzo.
a. Fiscalización Integral
b. Gobierno Corporativo
c. Gestión del Conocimiento
d. Gestión del Recurso Humano
a. Infraestructura
b. Seguridad y Control
c. Suministro de Servicios
d. Inserción Tecnológica
Sobre estos cuatro procesos se realizará una valoración de los riesgos a los cuales
están expuestos, y el nivel de exposición de los mismos.
Visión de la UTI
Misión de la UTI
Objetivos de la UTI
En los anexos 1 y 2 se presentan los riesgos relacionados con los objetivos del Plan
Estratégico Institucional 2008-2012 y con los objetivos del Plan Táctico Institucional
2009-2011; riesgos que constituyen el fundamento para la valoración de riesgos a nivel
operativo, y que estarán siendo aplicados y revisados en el contexto de la ejecución y
seguimiento del PAO 2009 y de la formulación detallada del PAO 2010.
98 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Portafolio de riesgos
Es importante definir claramente el marco de trabajo que será utilizado para la gestión
de los riesgos en la Unidad de Tecnologías de Información de la CGR; los objetivos son
los siguientes:
a. Contar con un marco de referencia para la gestión de los riesgos; este marco
de referencia debe ser conocido y comprendido por todos los miembros de
la Unidad.
b. Preparar a la organización para eventos de riesgo que pueda atentar contra
los servicios prestados por la UTI.
c. Orientar la gestión de la Unidad para tomar medidas que ayuden, dentro
de las posibilidades de la Institución, a mantener la continuidad de las
operaciones.
d. Fortalecer la imagen institucional por medio de una operación tecnológica
más estable y confiable.
• Utilizar los sub procesos de COBIT por guía y referencia para la identificación
de riesgos de gestión.
• Complementar la identificación de riesgos basándose en los procesos de la
Unidad, esto para identificar riesgos operativos.
• Utilizar escalas de calificación de los riesgos (impacto, probabilidad,
exposición) de acuerdo con modelos internaciones.
100 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Para clasificar los riesgos se utilizarán 5 categorías asociadas con el origen del riesgo.
Se utilizarán criterios de referencia específicos para cada categoría con el propósito de
de facilitar la evaluación de impacto para cada riesgo.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 101
Calificación de la probabilidad
Probabilidad
P Significado
5 Casi seguro
4 Muy probable
3 Probable
2 Poco probable
1 Raro
Para calificar el impacto se utilizará una tabla general de referencia con 5 valores;
adicionalmente se utilizarán tablas específicas donde se describirán los criterios para
asignar la calificación de impacto según la categoría de cada riesgo:
Impacto
I Significado
5 Mayor
4 Importante
3 Significativo
2 Regular
1 Menor
Para medir la severidad del riesgo se utilizarán 4 valores que se determina según la
calificación del impacto y la probabilidad, es decir el nivel de exposición:
102 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Severidad
S Significado
4 Extrema
3 Alta
2 Moderada
1 Baja
Mapa térmico
5 M A E E E
4 M A A E E
Impacto
3 B M A A E
2 B M M A A
1 B B B M M
1 2 3 4 5
Probabilidad
Categoría Descripción
Riesgos relacionados con la ausencia o aplicación
Gestión incorrecta de métodos de gestión de las tecnologías de
información y comunicaciones.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 103
Inserción Tecnológica
Es posible que un riesgo pertenezca o está relacionado con dos o más categorías;
por ejemplo, el incumplimiento de un procedimiento operativo puede dar lugar a un
evento de seguridad. En estos casos el riesgo será asociado a la categoría que se
considere más relevante o donde el impacto sea mayor.
Gestión
I Significado Criterios de calificación
5 Mayor Evento que impedirá el logro de los objetivos institucionales.
El logro de objetivos institucionales se ve afectado de manera
4 Importante
importante.
Evento que representará un retraso significativo en el logro de
3 Significativo
objetivos institucionales.
El evento afecta levemente el logro de objetivos de la UTI y
2 Regular
de la CGR.
Evento que afecta la gestión de la UTI sin llegar a impactar en
1 Menor
el logro de los objetivos.
104 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Operación
I Significado Criterios de calificación
Evento que paraliza la prestación de servicios por parte de
5 Mayor
la unidad afectando a la institución de manera considerable.
4 Importante Evento que provoca la interrupción parcial de servicios.
3 Significativo Evento que provoca interrupciones intermitentes.
Evento que provoca la interrupción momentánea de los
servicios de la unidad, esta interrupción es percibida por la
2 Regular institución.
Evento que provoca una disminución en los tiempos de
respuesta que experimentan los usuarios.
1 Menor Evento que afecta sólo las operaciones de la UTI.
Infraestructura
I Significado Criterios de calificación
Falla severa en un componente vital de la infraestructura
5 Mayor
tecnológica que impide la operación normal de la institución.
Falla en un componente de la infraestructura tecnológica que
4 Importante
afecta parcialmente la prestación de servicios.
Falla en un componente de la infraestructura tecnológica que
3 Significativo
afecta de manera intermitente la prestación de servicios.
Falla en un equipo que afecta la prestación de servicios sólo
2 Regular
en la UTI.
Falla en un componente que puede ser sustituido de
1 Menor inmediato por mantener equipo similar en inventario. Se
afecta la operación de la institución por minutos.
Seguridad
I Significado Criterios de calificación
La seguridad es vulnerada y se desconocen sus efectos.
Un ente no autorizado tiene acceso a información confidencial.
5 Mayor
Información total en la disponibilidad de información.
Los datos institucionales han sido alterados.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 105
Se aceptarán aquellos riesgos cuya severidad, la cual se obtiene del impacto del riesgo
y su probabilidad, esté calificada como Baja y Moderada; estos valores se representan
en el mapa término con los colores verde claro y amarillo claro respectivamente.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 107
Como se indicó anteriormente, la UTI apoya los macro procesos institucionales por
medio de cuatro procesos; éstos son los siguientes:
Infraestructura
El proceso de infraestructura se refiere al soporte tecnológico brindado por medio
de la red de comunicaciones interna, conexiones inalámbricas, acceso vía Internet a
la CGR, a las unidades para almacenamiento de datos en red, a los servidores, a la
plataforma de usuario final, al software en uso debidamente autorizado y soportado
por la CGR, a la solución telefónica en uso, y a todos los componentes necesarios para
mantener el ambiente necesario para su operación.
Seguridad y Control
En este proceso estamos hablando de las cámaras de vídeo, acceso al Centro
de Cómputo y a la UTI en general, software y hardware necesario para fortalecer
la seguridad y el control, monitoreo en general, administración de componentes o
funcionalidades.
Suministro de Servicios
El suministro de servicios abarca acuerdos de atención de usuarios, niveles de
disponibilidad de la plataforma, atención de averías, desarrollo y evolución de sistemas,
operación de equipos, continuidad de los servicios, mantenimiento y reparación de
equipos, conexiones de red, y evacuación de dudas.
Inserción Tecnológica
Se pretende con este proceso que todos los funcionarios utilicen la tecnología con
mucho entusiasmo, que le saquen todo el provecho posible, que producto de su
uso hagan aportes que faciliten el mejoramiento continuo de la plataforma, y que las
inversiones en TI permitan una mejor gestión y fiscalización.
108 / Normas Técnicas en Tecnologías de Información y Comunicaciones
A partir de esos procesos y tomando como punto de partida los sub dominios de Cobit
se realizará la identificación de los riesgos y el posterior análisis. De este modo se
determinará el nivel de riesgo absoluto y controlado de cada uno de los procesos de la
Unidad. Igualmente, los mapas térmicos se presentarán por cada proceso.
Identificación de riesgos
Identificación de causas
Cada uno de los riesgos identificados está asociado con una o varias causas, conocer
las causas es importante para enfocar los posteriores esfuerzos de mitigación y
contingencia así como para calificar los controles existentes. Las causas asociadas a
cada riesgo identificado son las siguientes:
Ausencia de validación
Desarrollar productos basados en
3 de requerimientos
requerimientos incorrectos.
Patrocinador sin compromiso
No hay contrato de mantenimiento.
Versiones de software Personal no está capacitado
4
desactualizadas. para actualizar el software.
No está planificada la actualización.
Mala gestión en la
Adquirir software sin programas adquisición de software
5
fuentes. Adquisición de software es
imprescindible
Adquirir software que no tiene
6 No se tiene otra opción
representación en el país.
No hay contrato de mantenimiento.
Equipo dañado no puede ser No se tienen repuestos en el país.
7
reparado. No hay repuestos para ese equipo.
No hay presupuesto para reparación.
La red es vulnerable
8 Red inalámbrica insegura. No se tiene la capacidad para
configurar adecuadamente la red
Impericia humana
Daño físico en los equipos de la Alteración del sistema eléctrico
9
plataforma tecnológica. Medio ambiente no apropiado
Sabotaje
No se tiene la expertise
Obsolescencia de la infraestructura para actualizarla
10
tecnológica. Que no se renueven los contratos de
mantenimiento
Normas Técnicas en Tecnologías de Información y Comunicaciones / 115
La actividad no es parte
No hacer planeamiento de la del plan de gestión
28
capacidad. No se tiene la capacidad para
realizarlo
No se planificaron las compras
Los recursos de la infraestructura con base al crecimiento
29 tecnológica no son suficientes para de la infraestructura
atender las demandas de servicios. Se da un crecimiento en recursos no
planificado
Procedimiento para
Recuperación de software no es recuperación incorrecto
30
factible No se cuenta con el recurso para
recuperarlo
Fallas en el equipo del
proveedor del servicio
31 Suspensión de servicio de Internet
Se daño un componente interno
Deficiencias en la administración
Impericia humana
Fallas en los equipos de Alteración del sistema eléctrico
32
comunicaciones Se daño el equipo
Sabotaje
Impericia humana
Fallas en los servidores El equipo se daño
33
(computadores principales) Se alteró la configuración
Alteración del sistema eléctrico
Se libera el equipo de algunas
políticas de seguridad cuando
34 Equipo de usuario final inseguro. se trasladan a una Institución
La instalación de componentes no
es controlada en algunos casos
118 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Evaluación de riesgos
Id Riesgo P I S
Adquisición de soluciones automatizadas que no satisfagan
1 3 3 9
las necesidades de la institución.
Desarrollar productos que no cumplen con las
2 2 4 8
especificaciones.
3 Desarrollar productos basados en requerimientos incorrectos. 2 4 8
4 Versiones de software desactualizadas. 3 4 12
5 Adquirir software sin programas fuentes. 1 4 4
6 Adquirir software que no tiene representación en el país. 1 4 4
7 Equipo dañado no puede ser reparado. 3 3 9
8 Red inalámbrica insegura. 5 5 25
9 Daño físico en los equipos de la plataforma tecnológica. 3 4 12
10 Obsolescencia de la infraestructura tecnológica. 3 4 12
Desarrollo de sistemas y servicios que son difíciles de utilizar
11 3 3 9
para el usuario.
12 No existe guía de usuario para el uso del sistema. 3 3 9
13 Retrasos en los procesos de contratación administrativa. 3 3 9
Se adquiere equipo no compatible con la infraestructura en
14 2 3 6
uso.
Se adquiere equipo sin que existan talleres para la reparación
15 4 3 12
y mantenimiento de los mismos.
16 Trabajar directamente en equipos de producción. 3 4 12
17 Versiones de software para desarrollo y producción diferentes. 4 4 16
No contar con la metodología y procedimientos necesarios
18 3 4 12
para la administración de los cambios.
Libertad en el uso de componentes tecnológicos (software
19 3 3 9
libre).
Instalación de parches sin seguir las recomendaciones del
20 3 3 9
proveedor.
Ausencia de niveles de servicio aceptados que faciliten la
21 3 3 9
gestión.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 127
Infraestructura
5 32, 33 61
31, 49,
4
50, 51
Impacto
3 14 7, 27 10
1 2 3 4 5
Probabilidad
132 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Seguridad y control
5 57 53 8
1 2 3 4 5
Probabilidad
Suministro de servicios
2 42
1 2 3 4 5
Probabilidad
Normas Técnicas en Tecnologías de Información y Comunicaciones / 133
5 89
2 81
1 2 3 4 5
Probabilidad
Identificación de controles
Se cuenta con un
servidor de desarrollo.
Trabajar directamente en equipos
16 Aplicación del procedimiento para la
de producción.
puesta en producción de los nuevos
programas.
Aplicación del procedimiento para
Versiones de software para
17 la puesta en producción de los
desarrollo y producción diferentes.
programas nuevos y modificados.
Se han definido
No contar con la metodología y responsabilidades y funciones.
18 procedimientos necesarios para la Se cuenta con un procedimiento
administración de los cambios. para aplicar los cambios en los
sistemas de información.
Definición y aplicación de
políticas institucionales sobre
Libertad en el uso de componentes el uso de software autorizado
19
tecnológicos (software libre). y estándar para la institución.
Los perfiles de usuario no tienen
autorización para instalar software.
Se revisan las indicaciones
Instalación de parches sin seguir las de los proveedores.
20
recomendaciones del proveedor. Los parches se aplican primero en
equipo de prueba.
Se utiliza un software para gestionar
Ausencia de niveles de servicio las solicitudes de servicio pero los
21
aceptados que faciliten la gestión. tiempos de respuesta esperados no
están acordados.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 137
Aplicación automática de
políticas de seguridad por
medio de Active Directory.
Perfiles de usuarios limitados
para instalar software y hacer
34 Equipo de usuario final inseguro.
modificaciones en el equipo.
Los equipos se encuentran en garantía.
A los equipos se les ha aplicado el
Service Pack recomendado por el
proveedor.
Ausencia de controles cruzados
Por medio del Centro de Operaciones
que comprueben la integridad de
35 se revisa la calidad de la información
la información y el funcionamiento
en sistemas clave.
correcto de las aplicaciones.
El personal que tiene a cargo la
implementación de la seguridad está
Errores en la creación de usuarios
capacitado para estas funciones.
36 y en la asignación de privilegios de
Como parte del desarrollo de
acceso.
proyectos se deben definir los roles
y una descripción.
Sistemas sin mecanismos de Se ha definido la utilización de pistas
37 trazabilidad de transacciones como parte de los estándares de
(pistas de auditoría). programación. Se utiliza el LogMiner.
Se debe mejorar el registro de costos
No se conocen los costos asignados asociados a cada servicio para
38
a los servicios prestados por TI. contar con información precisa en
este sentido.
No se cuenta con un proceso de Se debe mejorar el registro de costos
análisis para mejorar los costos que asociados a cada servicio para
39
están asociados a los servicios de contar con información precisa en
TI. este sentido.
140 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Se revisa la calidad
del código generado.
Se creó una dependencia
Información desactualizada o
56 de la CGR especializada en
incorrecta.
la gestión de la información.
Se brinda asesoría y capacitación
constante a los usuarios.
Se han definido políticas de TI con
responsabilidad para los usuarios.
Se ha implementado un
Acceso no autorizado a la
57 esquema automático para que
información.
los usuarios cambien sus claves.
No se gestionan claves por medios
informales de comunicación.
Las instalaciones tienen puertas
Instalaciones físicas mal diseñas con control de acceso restringido.
que pongan en peligro la integridad En el año 2005 se acondicionaron
58
del equipo de cómputo y del los sitios de trabajo para tener más
personal. visibilidad y fomentar el trabajo en
equipo.
Se cuenta con acceso restringido
Acceso no autorizado al centro de
59 (por tarjeta) y cámaras de vigilancia.
cómputo.
Se tiene una bitácora de acceso.
Está pendiente por restricciones de
60 Ausencia de detectores de humo.
presupuesto.
Fallas en los equipos que mantienen
Se han realizado revisiones de la
el medio ambiente apropiado para
61 instalación eléctrica. Se cuenta con
la operación de TI (UPS, Aire
planta y UPS.
acondicionado)
144 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Definición de procedimiento
de contingencia para la
generación de respaldos.
No aplicación de las políticas para
62 El personal responsable debe
la generación de respaldos.
informar cuando se presenta alguna
dificultad en la generación de los
respaldos.
Se cuenta con herramienta
para monitorear la red.
No efectuar un monitoreo constante Se cuenta con software para
63
sobre la operación de la plataforma. monitorear los servidores de
aplicaciones, bases de datos y
sistemas.
Bitácoras de cambios en la
configuración y suspensión
Suspensión de servicios sin seguir
64 de servicios. Se han definido
el procedimiento establecido.
procedimientos e instruido al
personal.
No contar con un proceso
Está pendiente la definición y
para revisar periódicamente el
65 oficialización del procedimiento para
desempeño actual y la capacidad
realizar esta actividad.
de los recursos de TI.
La institución, por medio de
Estrategia Institucional, mantiene
No percibir los cambios que se un monitoreo constante sobre los
66
realizan en el entorno. cambios en el entorno. Se encarga
de reflejarlos en los planes de
trabajo.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 145
Se tiene un plan de
Contar con equipo costoso que
renovación de equipo.
79 no cuenta con contratos de
Dentro del presupuesto se reservan
mantenimiento.
las partidas correspondientes.
Periódicamente se realizan
reuniones informativas con todo el
No aplicación de los canales de
personal de la USTI. Igualmente se
80 comunicación establecidos para
mantiene informado al Despacho
informar sobre la gestión de TI.
sobre la evolución de los proyectos y
la operativa de TI.
No se tienen documentados los Está pendiente de documentarse los
81
canales de comunicación. canales formales.
Desarrollo periódico del Diagnóstico de
Necesidades de Capacitación (DNC).
No se tiene dominio sobre las
82 Ejecución del programa de
herramientas en uso.
capacitación (de acuerdo con el
disponible presupuestario).
Se realizan dos evaluaciones
de clima laboral por año.
Equipo de trabajo con baja
Comunicación constante
motivación, poco creativo y no
83 sobre los planes de trabajo
comprometido con el logro de los
y compromisos de gestión.
objetivos.
Gestión orientada al logro de los
objetivos.
148 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Id Riesgo P I S
Adquisición de soluciones automatizadas que no satisfagan
1 1 3 3
las necesidades de la institución.
Desarrollar productos que no cumplen con las
2 1 4 4
especificaciones.
3 Desarrollar productos basados en requerimientos incorrectos. 1 4 4
4 Versiones de software desactualizadas. 2 4 8
5 Adquirir software sin programas fuentes. 1 4 4
6 Adquirir software que no tiene representación en el país. 1 4 4
7 Equipo dañado no puede ser reparado. 1 3 3
8 Red inalámbrica insegura. 2 3 6
9 Daño físico en los equipos de la plataforma tecnológica. 1 4 4
10 Obsolescencia de la infraestructura tecnológica. 2 3 6
Desarrollo de sistemas y servicios que son difíciles de utilizar
11 2 3 6
para el usuario.
12 No existe guía de usuario para el uso del sistema. 2 2 4
13 Retrasos en los procesos de contratación administrativa. 2 3 6
Se adquiere equipo no compatible con la infraestructura en
14 1 3 3
uso.
Se adquiere equipo sin que existan talleres para la reparación
15 1 3 3
y mantenimiento de los mismos.
16 Trabajar directamente en equipos de producción. 1 4 4
17 Versiones de software para desarrollo y producción diferentes. 1 4 4
No contar con la metodología y procedimientos necesarios
18 2 4 8
para la administración de los cambios.
Libertad en el uso de componentes tecnológicos (software
19 1 3 3
libre).
Instalación de parches sin seguir las recomendaciones del
20 1 3 3
proveedor.
Ausencia de niveles de servicio aceptados que faciliten la
21 2 3 6
gestión.
Definición de niveles de servicio que sobrepasan la capacidad
22 1 3 3
instalada de TI.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 151
Infraestructura
1 2 3 4 5
Probabilidad
156 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Seguridad y control
5 57 53
5, 6, 9, 16,
17, 30, 36, 4, 18, 86,
4
55, 56, 62, 87
Impacto
84
15, 19, 20, 8, 35, 59,
3 26, 34, 47, 63, 68, 72, 52, 60
54, 58, 70 88
2 37
1 2 3 4 5
Probabilidad
Suministro de servicios
2 42 12, 64
1 2 3 4 5
Probabilidad
Normas Técnicas en Tecnologías de Información y Comunicaciones / 157
Inserción tecnológica
5 76, 89
4 2, 3, 73, 74 95 67
2 80 81
1 2 3 4 5
Probabilidad
158 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Riesgos de infraestructura
㈀ 㐀 㘀 㠀 ㈀ ㌀ 㐀 㔀
Después de valorar los controles, desde el punto de vista del proceso de infraestructura,
se tienen 4 riesgos que deben ser gestionados, éstos representan el 33% de los riesgos
identificados y relacionados con este proceso.
160 / Normas Técnicas en Tecnologías de Información y Comunicaciones
㔀 㔀 ㈀ ㈀㔀 㔀 㔀 ㈀
㈀ 㐀 㘀 㠀 ㈀ ㈀ 㐀 㘀 㠀
㈀ 㐀 㘀 㠀 ㈀ 㐀 㘀 ㈀ 㐀 㘀 㠀 ㈀
Es importante conocer la calificación global de riesgo que tiene cada proceso tanto a
nivel en la calificación de riesgos absolutos como de riesgos controlados; este valor se
obtuvo con el promedio de la calificación de exposición (impacto * probabilidad) para
los riesgos en cada proceso. Los resultados son los siguientes:
Se puede notar fácilmente que la calificación de los procesos es muy similar, a nivel
de riesgos absolutos los procesos de infraestructura así como de seguridad y control
son los que tienen las calificaciones más altas a nivel de severidad promedio de sus
riesgos. En vista de que para los cuatro procesos de TI la calificación está entre 8 y
12 les corresponde un nivel promedio de severidad de alta (representada en color
anaranjado). En cuanto a los riesgos controlados también la calificación es muy
similar para todos los procesos, en este caso son los procesos de infraestructura e
inserción tecnológica los que tienen las calificaciones mayores. Todos los procesos
tienen calificaciones que están entre 4 y 6 por lo cual se ubican en nivel moderado
como promedio de severidad de sus riesgos que se representan en color amarillo.
Según estás calificaciones la situación de los procesos es muy similar tanto a nivel
de riesgos absolutos como de riesgos controlados; esto quiere decir que los controles
están orientados a gestionar los riesgos de manera equitativa.
164 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Riesgos prioritarios
Después de realizar el análisis de riesgos y determinar su nivel de severidad tanto en la
calificación de riesgos absolutos como de riesgos controlados se ha determinado que
los siguientes riesgos son de prioritaria atención:
Planes de tratamiento
A continuación se indican los planes de acción para cada uno de los riesgos cuya
evaluación de severidad, a nivel de riesgos controlados, fue de extrema o alta:
Id Riesgo P I S
4 Versiones de software desactualizadas. 1 3 3
No contar con la metodología y procedimientos necesarios
18 1 4 4
para la administración de los cambios.
31 Suspensión de servicio de Internet 2 2 4
No se conocen los costos asignados a los servicios prestados
38 1 3 3
por TI.
No se cuenta con un proceso de análisis para mejorar los
39 1 3 3
costos que están asociados a los servicios de TI.
Se realizan cambios en la configuración de componentes de
50 1 4 4
la infraestructura y no se reflejan en la documentación.
No se conoce el impacto de hacer cambios en los
51 1 4 4
componentes de la configuración.
No se aplica el procedimiento oficializado para la gestión de
52 2 3 6
problemas.
53 No se documentan las soluciones aplicadas a los problemas. 1 5 5
60 Ausencia de detectores de humo. 2 3 6
Fallas en los equipos que mantienen el medio ambiente
61 2 3 6
apropiado para la operación de TI (UPS, Aire acondicionado)
No contar con un proceso para revisar periódicamente el
65 1 3 3
desempeño actual y la capacidad de los recursos de TI.
Utilización de indicadores sobre el desempeño de TI que
67 no son relevantes y que no colaboran en la identificación de 1 3 3
no se reflejan en la documentación.
No se conoce el impacto de hacer cambios
51 12 8 4
en los componentes de la configuración.
No se aplica el procedimiento oficializado
52 9 9 6
para la gestión de problemas.
172 / Normas Técnicas en Tecnologías de Información y Comunicaciones
伀爀 最愀渀椀稀愀挀椀渀
䐀攀猀瀀愀挀栀漀
䌀 漀渀琀爀 愀氀漀爀 愀 䜀 攀渀攀爀 愀氀
䌀 漀洀椀琀 䜀 攀爀攀渀挀椀愀氀
搀攀 吀 䤀 䌀 됀猀
䐀椀瘀椀猀椀渀
䜀 攀猀琀椀渀 搀攀 䄀 瀀漀礀漀
唀渀椀搀愀搀
吀攀挀渀漀氀漀最愀猀 䤀 渀昀漀爀 洀愀挀椀渀
倀爀攀猀甀瀀甀攀猀琀漀 礀
匀攀挀爀攀琀愀爀 愀
䌀 漀洀瀀爀 愀猀
Recomendaciones
Con base en el análisis de Administración Basada en Riesgos, llevado a cabo en la
Unidad de Tecnologías de Información, se derivan una serie de recomendaciones que
se incorporan a continuación en el presente documento.
Instrumento metodológico.
El MAGEFI será el marco conceptual general, a partir del cual se detallarán los flujos
de información y los datos involucrados.
Para cada uno de los procesos se deberá generar una tabla que incluya:
Con dicha información se aplicarán cada uno de los pasos definidos en la técnica del
BSP, a saber:
Paso 3: Mapear como utiliza la organización los datos (a nivel de entidad de información)
• Generar matriz de procesos y responsables
• Generar matriz de procesos y sistemas
1
Una entidad es una cosa u objeto en el mundo real que es distinguible de todos los demás objetos. Una entidad tiene un
conjunto de propiedades y los valores para algún conjunto de estas propiedades pueden identificar a una entidad de forma
univoca. Un conjunto de entidades es la totalidad de las entidades de mismo tipo que comparten las mismas propiedades.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 181
Teniendo presente que la fecha límite, planteada para cumplir con lo que establece la norma
2.2 del Manual de Normas Técnicas para la Gestión y el Control de las Tecnologías de
Información, de contar con un modelo de Arquitectura de Información, está definida como
30 de junio del año 2009, se hace necesario analizar las siguientes alternativas de acción:
Ventajas:
• Se realiza un proceso coordinado mediante el cual los expertos funcionales
de cada proceso responden a un único requerimiento de definición de los
procesos, tanto para detallar el MAGEFI como para crear el MAI.
• En el análisis detallado de los procesos los expertos funcionales pueden
determinar de mejor manera las entidades y flujos de información inmersos
en el proceso.
Desventajas:
• Se ve difícil lograr recabar toda la información requerida para crear el MAI,
con el suficiente tiempo para tener dicho modelo bien documentado a
junio 2009; a no ser que la documentación detallada de los procesos del
MAGEFI se logre enmarcar dentro de las mismas fechas y esto para todos
los procesos compilados en dicho manual.
• En la definición detallada de los procesos del MAGEFI podría suceder
que no todos los procesos puedan ser atendidos al mismo ritmo debido a
las múltiples ocupaciones de los expertos funcionales, lo cual afectaría la
definición del MAI debido al faltante de la información de esos procesos.
Ventajas:
• Se puede recopilar la información necesaria para crear el MAI con suficiente
tiempo para cumplir con la fecha límite planteada (junio 2009).
• Se contaría con el apoyo del Despacho para que los expertos funcionales
respondan primero a los requerimientos de información para crear el MAI,
los cuales son menores en cantidad respecto a lo requerido para detallar
los procesos del MAGEFI y documentar los procedimientos.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 183
• Se tendría una muy buena base para la definición de procesos del MAGEFI.
Desventajas:
• Los expertos funcionales deberán responder inicialmente a lo que el
proyecto de creación del MAI les demande, para luego trabajar en detallar
y documentar los procesos del MAGEFI.
• Podría darse una duplicidad de esfuerzos, aunque este riesgo se puede
mitigar con la apropiada asesoría a los expertos y la coordinación respecto
a los requerimientos planteados por ambos proyectos (MAGEFI y MAI).
• El levantamiento de información para crear el MAI se adelanta a la definición
de los procesos y a la documentación de los procedimientos, pudiendo
estos cambiar cuando se realice el correspondiente análisis detallado.
• Se corre el riesgo de definir un modelo de arquitectura de información que
refleja los datos y los flujos a como se hacen las cosas hoy y no a como
el MAGEFI lo plantea, esto por cuanto este manual introduce cambios de
visión respecto al cómo se hacen las cosas.
Recomendación:
Teniendo como fecha límite para contar con el Modelo de Arquitectura de Información el
30 de junio de 2009, recomendamos la aplicación de la opción 2, la cual permitirá contar a
tiempo con los insumos requeridos para crear el MAI y dar así cumplimiento a lo establecido
por la norma 2.2 del Manual de Normas Técnicas para la Gestión y el Control de las
Tecnologías de Información.
Dado que el MAI es un modelo “vivo” dentro de la organización, todo cambio en los procesos
se puede y deberá aplicar posteriormente. Es así como cualquier cambio que surja con
la posterior institucionalización de los procesos del nuevo MAGEFI, puede ser aplicado al
modelo de Arquitectura de Información sin ningún problema.
184 / Normas Técnicas en Tecnologías de Información y Comunicaciones
El equipo de proyecto MAI ve difícil lograr coordinar las fechas del proyecto MAGEFI con
la fecha límite de 30 de junio de 2009, tomando en cuenta las múltiples ocupaciones
de los expertos en los procesos y las temporadas “pico” en procesos como lo son la
tramitación de presupuestos ordinarios o los procesos de contratación administrativa
que se incrementan conforme se acerca el fin y principio del año.
Documento de Diagnóstico
Esta propuesta constituye el primer producto documental del proyecto a ser aprobado
formalmente, que conocerá la jefatura de la Unidad de Sistemas y Tecnología de
Información en primera instancia, para que la retroalimente y le dé el trámite necesario
para su aprobación. De esa forma el trabajo sucesivo del proyecto puede contar con
el respaldo superior necesario, para llevarlo a buen término en el ámbito institucional.
Justificación
Es sumamente riesgoso que las organizaciones hagan altas inversiones en TIC sin
una idea clara de cómo debe ordenarse sistemáticamente el flujo de datos y las
comunicaciones; para apoyar de manera intencionada la operación de los procesos,
así como el cumplimiento de la estrategia y planes organizacionales.
La teoría y práctica administrativa y del control interno, en virtud del carácter estratégico
e importancia relativa de estas inversiones, cada vez con más urgencia llaman la
atención sobre las mejores prácticas en esta materia. Es así como la Contraloría
General, en las Normas Técnicas para la Gestión y el Control de las Tecnologías de
Información, emitidas mediante la Resolución del Despacho de la Contralora General
de la República, Nro. R-CO-26-2007 del 7 de junio de 2007, publicada en La Gaceta
Nro.119 del 21 de junio de ese mismo año, incluye una norma referida al modelo de
arquitectura de información, en los siguientes términos:
en éstos fluye, el manejo que debe dársele y la integración entre los procesos a nivel
de flujos de información.
Este MAI deberá guiar la inserción, mantenimiento y evolución de las TIC en los procesos,
como principio básico para justificar la inversión en los elementos tecnológicos que
apoyarán el logro de las metas institucionales. Ese modelado debe ser la base sobre la
cual se construya la fiabilidad y el valor agregado de la incorporación de las TIC a los
procesos de la organización.
Con la elaboración del MAI, la CGR cumple además con el referido numeral que
específicamente regula este aspecto en las Normas Técnicas para la Gestión y el
Control de las Tecnologías de Información, emitidas por este Órgano Contralor.
Antecedentes
Ese modelado previo requiere ser actualizado para que responda a los aspectos
cambiantes de la institución. Además, los adelantos técnicos en la materia incorporan
requisitos que aquel modelo no contempló en su momento. Esa realidad queda
evidenciada en las últimas orientaciones estratégicas y tácticas que la CGR se ha
dictado para gestionar las TIC institucionales, las cuales se resumen y presentan en el
anexo 1 del presente documento.
Esquema metodológico
Para ello, a continuación señala como puntos de referencia los componentes del modelo
de arquitectura empresarial (dentro del cual, una de las piezas es la arquitectura de la
información) y un esquema de madurez para definirla y guiar su implementación en
la CGR, desde un nivel básico hasta uno óptimo.
192 / Normas Técnicas en Tecnologías de Información y Comunicaciones
2. Información y comunicaciones
a. Flujos de datos basado en el modelo organizacional
b. Manejo operativo, plazos, responsables, propiedad y custodia, seguridad
sobre los datos
c. Definición e integración de los macrosistemas para la organización.
3. Aplicaciones
a. Inventario de sistemas y soluciones
b. Interfaces y relaciones, flujos de datos
c. Enlaces de telecomunicación y servicios extendidos (Internet, extranet,
intranet)
4. Tecnología
a. Plataformas físicas
b. Conectividad
c. Seguridad de los datos
d. Sistemas de base
e. Gestores de bases de datos
f. Lenguajes y herramientas de desarrollo
䌀㨀 尀䐀漀挀甀洀攀渀琀猀 愀渀搀
匀攀琀琀椀渀最猀尀樀氀攀漀渀尀䔀猀挀爀椀琀漀爀椀漀尀吀爀愀戀愀樀漀 䄀挀琀甀愀氀尀䴀䄀䤀 尀䔀匀儀唀䔀䴀䄀 䐀䔀 䴀䄀䐀唀刀䔀娀 䐀䔀 䰀伀匀 䌀伀䴀倀伀一䔀一吀䔀匀 䐀䔀䰀 䴀䄀䤀 ⸀ 搀漀挀
Alcances y limitaciones
El nivel de desarrollo del MAI en la CGR será hasta el nivel que lo permita el modelado
organizacional existente; inicialmente en términos de insumo, actividades del proceso
y productos, que es lo definido en el nuevo MAGEFI.
Las personas con conocimiento experto en los procesos, mismas que deberán
implementar en la organización lo que el MAGEFI plantea, serán las personas que
deberán aportar la visión de datos asociada a los procesos, que servirá como insumo
para desarrollar el MAI de la CGR.
Estrategia de desarrollo
El equipo del proyecto MAI realizará un diagnóstico dirigido a ubicar la situación actual
de la CGR en el modelo de capacidades planteado como punto de referencia. Una
vez ubicado el estado actual se trabajará para lograr las condiciones requeridas en el
siguiente nivel.
Para ello este equipo aplicará antes los instrumentos desarrollados en un proceso
piloto para evaluarlos y ajustarlos.
Una vez que se cuente con dichos instrumentos para el levantamiento de la información
requerida para hacer el MAI, será necesario desarrollar talleres con expertos funcionales
de las diversas divisiones operativas de la CGR, con el fin de explicarles el trabajo a
realizar, el instrumento metodológico a utilizar y los plazos sugeridos para recopilar la
información para cada uno de los procesos.
Los expertos documentarán sobre la información que cada uno de sus procesos requiere
o genera y harán llegar al equipo del proyecto MAI los formularios debidamente llenos.
El equipo del proyecto MAI procesará la información que remitan los expertos funcionales
y elaborará el modelo de información que incluye el diseño de su representación lógica,
el diccionario de datos institucional y el modelo de referencia para la clasificación
de los datos. Deberá considerar el uso compartido de la información, su integridad,
flexibilidad, y la correcta, eficiente y económica, oportuna y segura operación.
A partir del MAI actualizado será posible plantear los macro sistemas sustantivos y de
apoyo, así como los sistemas o soluciones adicionales que requiere la institución para
operar. Esta propuesta de macrosistemas, unida al MAI será el insumo indispensable
para que la USTI desarrolle una intensa actividad tendiente a inventariar las necesidades
de información, documentarlas y confrontarlas contra los sistemas actuales, para
luego identificar sistemas que requieren modificaciones, así como nuevos sistemas a
incluir dentro de un plan de sistemas.
El modelo debe mantener vigencia, por lo que la organización deberá desarrollar los
procedimientos de actualización y documentación pertinentes.
Productos
Subproductos
Como parte del alineamiento del Plan Estratégico y del Plan Táctico de Tecnologías de
Información y Comunicación (PETIC-PTAC), el proyecto de Modelo de Arquitectura de
Información depende de un conjunto de factores críticos de éxito (FCE) consignados
en esos planes, respecto de los cuales se puede establecer una correspondencia para
el MAI, a saber:
procesos respectivos.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 199
Evolución: Depuración, documentación Los requisitos para el desarrollo del MAI deben
de gestión necesarios para gestionar las la cartera de proyectos para que dicho modelo
actividades de ejecución continua que resulten sea desarrollado, orientando las acciones hacia
fue creado.
INTERNOS
Normas Técnicas en Tecnologías de Información y Comunicaciones / 201
Referencias investigadas
a. Cuenca González et al. Arquitectura de Empresa, Visión General. IX Congreso
de Ingeniería de Organización. Setiembre 2005.
b. Garrett, Jesse James. The elements of user experience. www.jjg.net/ia/
Marzo 30, 2000.
c. IT Governance Institute. COBIT 4.1. Rolling Meadows, Chicago, Illinois,
2007. www.itgi.org
d. Office of Management and Budget (OMB). Federal Enterprise Architecture.
http://www.whitehouse.gov/omb/egov/a-1-fea.html
e. The Open Group. The Open Group Architecture Framework (TOGAF), versión
8.1.1, enterprise edition. 2007.
f. United States Departament of Commerce. Enterprise Architecture Capability
Maturity Model (ACMM). Version 1.2. December 10, 2007.
g. Zachman, J.A. A framework for information systems architecture. IBM
Systems Journal, Vol. 26, No. 3, 1987.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 203
Anexo 1
Orientaciones estratégicas para el modelo de arquitectura de información
y comunicación institucional
Seguridad y Control,
Inserción tecnológica,
Suministro de servicios e
Infraestructura Tecnológica;
䌀 漀渀琀爀愀氀漀爀愀 䜀 攀渀攀爀愀氀 搀攀
䤀渀猀 攀爀挀 椀渀 吀 攀挀 渀漀氀最椀挀 愀
氀愀 刀 攀瀀切戀氀椀挀愀
搀攀 氀漀猀 瀀爀漀挀攀猀 漀猀
䤀洀瀀氀椀挀愀 洀愀瀀攀漀
䤀洀瀀氀椀挀愀 愀渀氀椀猀椀猀 搀攀
猀 椀猀 琀攀洀愀猀 氀攀最愀搀漀猀
Anexo 2
Tabla de actividades propuestas y estimación de tiempo.
Actividades ejecutadas
Saludos cordiales,
Miguel Aguilar
Anexo - NTP7
Guia Metodológica para
administración Proyectos TI
218 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normas Técnicas en Tecnologías de Información y Comunicaciones / 219
1. Introducción.
Con el fin de establecer un lenguaje común a nivel institucional; así como un estándar
en la ejecución y documentación de proyectos de tecnologías de información y
comunicación, se define en este documento la Guía Metodológica que se debe aplicar
en la Contraloría General de la República (CGR).
Esto significa que un proyecto tiene un resultado deseado específico, una fecha límite
o fecha objetivo en la que el proyecto debe estar realizado y un presupuesto que limita
la cantidad de personal, suministros y dinero que pueden utilizarse para realizar el
proyecto.
Sin importar los objetivos que los proyectos busquen, se puede ver que todos presentan
etapas básicas, con algunas pequeñas variantes. Cada una de éstas será detallada en
la presente guía.
2. Objetivo
3. Objetivos específicos
Inicio
Pl
an
ea
ció
n
n
ció
cu
Eje
Control
Cierre
6. Anteproyecto (Etapa 0)
Todo proyecto a desarrollar debe tener su ficha de anteproyecto, misma que será
evaluada y priorizada por el Comité Gerencial de Tecnologías de Información y
Comunicaciones (CGTIC), a solicitud de la Unidad de Sistemas y Tecnologías de
Información (USTI). Este comité elige de los anteproyectos planteados, aquellos que
serán tomados en cuenta en la cartera de proyectos del PTAC.
Se debe tener claro que en esta etapa, aún no se ha creado un equipo de trabajo
ni se ha realizado una evaluación profunda, sobre las tres variables básicas de todo
proyecto a saber: tiempo, recursos y alcances. Por lo tanto es de esperar, que al
crearse el equipo de trabajo y se entre a los niveles de detalle como en la etapa de
planeación, los contenidos de dichas variables cambien.
Todo anteproyecto de TIC intenta resolver una serie de necesidades que manifiesta la
organización en el desarrollo o actualización de alguno de sus procesos.
• Ficha de anteproyecto
5.4. Punto de Control:
6. Iniciación (Etapa 1)
En esta etapa se corroboran los alcances globales del proyecto y las expectativas
generales de los diferentes interesados. Además se define la organización del proyecto
estableciendo las funciones y responsabilidades de cada uno de los involucrados, así
como el perfil deseable de los integrantes del equipo de trabajo. Ver anexo 1.
Es necesario que las personas a cargo del proyecto tengan una estructura organizativa
que garantice un formalismo operacional, que permita lograr los fines propuestos.
Esta estructura podría variar en función de la magnitud y complejidad de los proyectos
y puede ser matricial.
• Unidad Ejecutora
• Grupo de Apoyo
• Equipo de Trabajo
• Equipo de apoyo técnico
Patrocinador
del proyecto
Grupo de Coordinador de
apoyo proyectos
Líder de
proyecto
Líder
Técnico
Unidad Ejecutora
Equipo de apoyo
Equipo de trabajo
técnico
230 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Esta función la lleva a cabo el Jefe de la USTI con fines de armonizar y asegurar
el aprovechamiento de componentes tecnológicos, puede ser ejecutada por el
coordinador de proyectos de la USTI.
desarrollo del proyecto en lo que corresponde a la parte técnica, para ello aplica las
políticas, normas y procedimientos de trabajo aprobados.
El Líder Técnico con la colaboración del Líder de Proyecto debe realizar un análisis
de la situación actual donde se describa la forma como el proceso se está realizando;
ya sea con alguna herramienta tecnológica existente o de forma totalmente manual.
Los alcances establecen de manera clara, hasta dónde llegará el proyecto de TIC y
deberán permitir el manejo de expectativas comunes entre todos los interesados y
participantes del proyecto.
Uno de los aspectos más críticos de todo proyecto, es detallar y comunicar lo que cada
uno de los interesados (muchos de ellos patrocinadores) esperan. Por ello resulta
imprescindible que para cada interesado se establezca lo que espera obtener cuando
éste concluya.
Las expectativas de cada interesado deberán ser conocidas por los demás y por
todos los integrantes del equipo de trabajo y deberán quedar documentadas en este
234 / Normas Técnicas en Tecnologías de Información y Comunicaciones
En caso de requerir un cambio en los objetivos del proyecto, esto se verá como un
cambio a lo establecido en la ficha de anteproyecto y deberá atenderse como se
estableció en el punto 5.2 de esta guía metodológica.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 235
Para ello se sugiere tener en cuenta los costos administrativos, operativos, laborales,
tecnológicos, y otros. Se deben considerar los beneficios tangibles e intangibles que
se obtienen con el sistema, por ejemplo: tiempo requerido para la actualización o
conclusión del proceso, desplazamiento de personas, aprovechamiento de equipo y
las herramientas existentes, aprovechamiento de mejores prácticas en el mercado,
reducción de gastos y simplificación de trámites.
Si bien es cierto se cuenta con unas fechas de inicio y de fin sugeridas, esta definición
de tiempo para el desarrollo del proyecto se debe ir afinando conforme el equipo de
trabajo conozca más detalles del mismo. Con base en los alcances identificados del
proyecto, estudio de la situación actual y el análisis de riesgos se deberá presentar
la estimación inicial del tiempo que se requiere para cada una de las opciones de
las soluciones señaladas; acompañadas de los supuestos y restricciones que apoyan
dichas estimaciones.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 237
La Unidad Ejecutora del proyecto deberá indicar su criterio sobre la forma en que
debe desarrollarse, basado en los resultados obtenidos en el diagnóstico realizado.
Ficha de anteproyecto.
• Informe de diagnóstico.
• Descriptivo de la Organización del Proyecto.
• Estrategia de solución para el proyecto.
7. Planeación (Etapa 2)
Como requisito para iniciar con esta etapa, el equipo de trabajo debe ya estar
formalmente constituido y se debe tener una estrategia de solución, establecida a
partir del análisis de los resultados del diagnóstico elaborado en la etapa anterior, la
cual determina el curso de acción para las tareas que deberá realizar el equipo de
proyecto, con miras a lograr el objetivo propuesto.
El elaborar el plan es una labor muy delicada y se debe realizar con la participación
de todos los miembros del equipo. Como en toda actividad grupal surgirán una serie
de opciones sobre como realizar las cosas, por lo que será habilidad del Líder de
Proyecto conciliar criterios, de modo tal que se llegue a un consenso sobre cuales son
las actividades a desarrollar, para llegar a cumplir las finalidades del proyecto.
240 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Si los cambios que un sistema requiere son de tal impacto que realmente se estaría
generando una nueva versión, el tratamiento de tales requerimientos deberá atenderse
con la rigurosidad de un proyecto de desarrollo de sistemas normal.
• Informe de diagnóstico.
• Descriptivo de la Organización del Proyecto.
• Estrategia de solución para el proyecto.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 243
La Unidad Ejecutora del Proyecto revisa y da su visto bueno al plan de trabajo del
proyecto y a la planeación de recursos, como requisito para poder continuar con la
etapa de ejecución. Si el plan no satisface las expectativas de los integrantes de la
Unidad Ejecutora, ésta puede solicitar al equipo de trabajo una reformulación.
244 / Normas Técnicas en Tecnologías de Información y Comunicaciones
8. Ejecución (Etapa 3)
Dependiendo del mismo plan de trabajo y del tipo de proyecto, durante la etapa de
ejecución se crearán productos intermedios que deberán ser revisados y aprobados
por la Unidad Ejecutora.
Los informes de avance deberán emitirse con una periodicidad no mayor al mes,
estableciendo valoraciones sobre el desempeño general del proyecto, resaltando
aquellos aspectos que afectan el cumplimiento de los tiempos y de las metas planeadas.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 245
• Minutas de reuniones.
• Informes de avance.
• Productos intermedios propios del proyecto de TIC.
246 / Normas Técnicas en Tecnologías de Información y Comunicaciones
La Unidad Ejecutora del Proyecto revisa los informes de avance que emite el equipo de
proyecto, así como los ajustes y actualizaciones realizadas al cronograma de trabajo.
La Unidad Ejecutora del Proyecto revisa los productos intermedios propios del tipo de
proyecto de TIC que se desarrolla. En algunos casos el equipo de trabajo requerirá
que se apruebe determinado producto intermedio, antes de continuar con el desarrollo
de tareas subsiguientes.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 247
9. Control (Etapa 4)
Antes de ver el control como una etapa separada, se debe tener claro que éste es una
acción que siempre está presente durante el desarrollo del proyecto. Su fin primordial
es detectar desviaciones del plan de ejecución en forma oportuna, de manera que
permita tomar acciones correctivas y preventivas. De ser necesario se deberá retomar
el proceso de planeación, para ejecutar las acciones necesarias, reflejándolas en una
nueva versión del plan.
La meta del control es lograr que los objetivos definidos en el plan de trabajo se
cumplan, a partir del seguimiento, ajuste y realimentación de las acciones planeadas
y ejecutadas.
El proceso de control del proyecto valora como insumo los cambios en el entorno, los
cambios en los recursos, los cambios en las necesidades a solventar, las acciones
realizadas y el plan de trabajo; para emitir acciones correctivas y acciones preventivas.
Se debe hacer todo el esfuerzo porque el plan se cumpla, sin embargo todo plan
no es más que una aproximación del futuro y por más cuidado y experiencia que
se haya puesto en la elaboración del mismo, siempre existirán una serie de factores
que se pueden haber escapado durante la elaboración del mismo. Otro aspecto muy
248 / Normas Técnicas en Tecnologías de Información y Comunicaciones
El Líder de Proyecto y el Líder Técnico deben llevar un control del avance del proyecto,
que no sea por estimación o por algún criterio experto, sino que sea totalmente objetivo,
enfocando el logro real de cada tarea.
Para ello deben hacer uso de la asignación de Unidades de Logro (UL) a las tareas
del plan de trabajo y crear un seguimiento de las unidades alcanzadas por el proyecto
de forma acumulada y mensual. A cada tarea planeada se le asigna una cantidad de
unidades de logro y para la contabilización de unidades deberá tenerse en cuenta que
sólo las tareas completas ofrecen logro y que el aporte al logro varia dependiendo de
si la tarea pertenece a la ruta crítica o no.
䌀漀渀琀爀漀氀䄀嘀倀开䴀愀挀栀漀琀攀
⸀ 砀氀猀
Todo cambio que afecte el curso de acción, los alcances o la estrategia de solución;
debe quedar documentado, sobre todo si dichos cambios impactan el cronograma de
proyecto. Además el Líder del Proyecto deberá hacer del conocimiento de la Unidad
Ejecutora todo cambio importante, la cual tiene que aprobar si se atiende o no dicho
cambio.
Para llevar el control de cambios del proyecto se debe usar el formulario que se detalla
en el anexo 12.
• Informes de avance.
• Plan de trabajo para el proyecto (Cronograma).
• Formulario de planeación de recursos.
La Unidad Ejecutora del Proyecto revisa los informes que emite el equipo de proyecto
y el control de avance; cuando identifique tareas desfasadas aprobará acciones
correctivas o preventivas tendientes a mitigar el desfase. La Unidad Ejecutora puede
decidir retomar el proceso de planeación y generar una nueva versión del plan.
252 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Toda etapa de conclusión de un proyecto debe cumplir con las siguientes actividades
básicas.
Todo Líder de Proyecto, con el apoyo del resto de los integrantes del equipo, tiene
que elaborar el informe final de cierre del proyecto, el cual debe cubrir los siguientes
puntos:
• Resumen ejecutivo con los principales logros, comparados con las metas
originales del proyecto.
• Puntos o tareas que quedaron pendientes, ya sea porque requieren de una
mayor investigación o elaboración; o porque se deberán retomar para una
segunda versión del proyecto.
• Resumen de los asuntos conflictivos y soluciones.
• Recomendaciones para mejorar la administración y ejecución de proyectos
futuros.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 253
La Unidad Ejecutora debe revisar y dar por aceptados a satisfacción los productos
finales del proyecto. Si algún producto no se considera como terminado el proyecto
no está en fase de conclusión.
Es necesario recordar que toda la información relativa al proyecto que recién termina,
es de vital importancia para otros proyectos o trabajos futuros. Es por ello que el Líder
del Proyecto deberá dejar debidamente actualizado el expediente. Este expediente
debe contener todos los entregables de cada fase del proyecto, y debe mantenerse en
formato digital de acuerdo al expediente electrónico definido en la CGR.
La Unidad Ejecutora del Proyecto revisa el informe final del proyecto y lo hace del
conocimiento de todos los interesados.
Anexo 1
Definición de roles
Anexo 2
Actualización de la Guía Metodológica para el Desarrollo de Proyectos
de Tecnología de Información y Comunicaciones.
Dado el ritmo acelerado que impone el entorno tecnológico y los cambios que
toda organización debe realizar para mantenerse actualizada, se establece la
necesidad de realizar periódicamente las revisiones y los ajustes que corresponda
a la Guía Metodológica para el desarrollo de Proyectos de TIC. El responsable de
esta actualización será la Unidad de Sistemas y Tecnologías de Información, quien
podrá pedir el apoyo y la asesoría de otros funcionarios de la Contraloría General de la
República, que estime conveniente.
Una vez hechos los ajustes correspondientes, los puntos modificados o agregados debe
ser sometidos a consideración del Comité Gerencial de Tecnologías de Información y
Comunicaciones quien debe recomendar su aplicación para proceder a su publicación
y a la divulgación respectiva.
258 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo 3
Responsabilidades de los miembros del proyecto
Patrocinador del Proyecto
Jefe de la USTI.
Perfil:
• El Líder del Proyecto debe ser un representante, del área funcional que
propone e impulsa el desarrollo de proyecto de TIC.
• Debe coordinar estrechamente con el patrocinador del proyecto, por
cuanto sus responsabilidades incluyen la toma de decisiones, la resolución
de problemas y el logro de la colaboración necesaria de otras unidades
organizacionales, cuando sea requerida.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 261
Responsabilidades Principales
Funciones
Perfil:
Responsabilidad principal
Funciones
Equipo de trabajo
Grupo de Apoyo
Matriz de Responsabilidades
270 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normas Técnicas en Tecnologías de Información y Comunicaciones / 271
272 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo 4
Fases para el desarrollo de sistemas
1.1. Consideraciones
Con el análisis integral de requerimientos del sistema a automatizar se espera:
1.2. Entregables
Para ello, el Líder Técnico y el analista asignado deben trabajar en conjunto con el
grupo de usuarios, de manera que generen experiencia en traducir en requerimientos
(descripción precisa y detallada de la funcionalidad del sistema), las necesidades que
poseen y que sean muy comprensibles. Para lograr este propósito el usuario experto
puede aportar la documentación que considere pertinente, como boletas, formularios,
legislación, normativa, documentos y tipos de reportes.
a. Requerimientos funcionales
Son las indicaciones de servicio que el sistema debe proveer en cuanto a actualización
de datos, opciones de consulta, reportes a generar, interacción con otros sistemas,
bitácoras de seguimiento y pistas de Auditoria (en coordinación con la Auditoria
Interna).
Entre las características que se espera que posean los requerimientos funcionales
están las siguientes:
qué respuestas debe ofrecer el sistema a las diversas acciones de los usuarios o, en
general, los agentes externos al sistema.
uso. Usualmente son roles, pero puede ser cualquier tipo de sistema
Tipo Primario: proceso principal
________________________________________________________
la implementación
a. Requerimientos no funcionales
Son las propiedades y restricciones del sistema, pueden ser de índole organizacional,
como consecuencia de alguna política organizacional o de procedimiento, o pueden
ser de operabilidad como los son: confiabilidad, tiempo de respuesta, almacenamiento,
capacidades de dispositivos de E/S, migración de herramienta, y conversión de
archivos.
278 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Este documento reúne los resultados del proceso de análisis y será la base, en conjunto
con la especificación de requerimientos, para la planificación de las fases posteriores
en lo referente a la construcción del sistema.
b. Análisis de requerimientos
ID Descripción del req. Prioridad Complejidad Tipo Req. Dependencia Días const.
Con esta matriz se puede realizar un análisis cuantitativo de los requerimientos que
permita identificar aquellos que son críticos para el éxito y completitud del proyecto;
además ofrece un elemento importante para la toma de decisiones por parte del Líder
de Proyecto y Líder Técnico.
Con mayor claridad de lo que deberá desarrollarse se puede ahora ajustar el cronograma
del proyecto para las siguientes etapas, indicando las fechas de inicio y finalización
para cada una de ellas así como los responsables de las actividades.
2.1. Consideraciones
Esta fase tiene el propósito de identificar los primeros elementos de diseño del nuevo
sistema. Los insumos principales de esta fase son: el documento de especificación de
requerimientos y el documento de análisis.
2.2. Entregables
a. Identificación de módulos
Un módulo es una parte o división del sistema. Consiste en agrupar funcionalidad que
está relacionada y que soporta un eje o situación específica del negocio sobre la cual
se está desarrollando el proyecto.
Identificar los tipos de usuarios y el rol a cumplir por ellos dentro del sistema,
especificándose quiénes pueden ingresar, modificar, borrar o consultar información
y cuál información. Qué tipos de usuarios utilizan cada uno de los módulos y qué
funciones lleva a cabo.
284 / Normas Técnicas en Tecnologías de Información y Comunicaciones
3.1. Consideraciones
La base de información para las actividades del diseño detallado son los documentos
de especificación de requerimientos, documento de análisis y diseño conceptual.
3.2. Entregables
a. Descripción de procesos
• Formato
• Valor que asume por defecto
• Rango de valores permisibles
• Listas de valores
• Mensajes informativos sobre los elementos
• Pruebas unitarias: son las pruebas que se realizan a cada programa del
sistema
• Pruebas de módulos: pruebas que se aplicarán a los módulos o partes
funcionales del sistema, incluye a todos los programas del módulo.
• Pruebas de integración: pruebas totales del sistema y de su integración con
otros sistemas, incluye todos los programas.
• Pruebas de esfuerzo: comprobación de recursos computacionales para
soportar la aplicación (servidor de bases de datos, servidor Web, recursos
de las máquinas de usuario, red)
288 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Identificar todos los escenarios posibles con diversidad de datos de entrada y acciones
realizadas por el usuario, con el propósito de identificar posibles puntos de error en el
sistema.
4. Programación y pruebas
4.1. Consideraciones
En esta fase se confeccionan los programas y se realizan las pruebas a partir de los
documentos de requerimientos, casos de uso, especificación de programas, análisis y
diseño. Como producto se tendrán los componentes de programación, una constancia
de pruebas y de aceptación del producto.
Diseño detallado
Construcción
Construcción
Ajustes
Ajustes
Pruebas
Pruebas
Aceptación
Aceptación
Implementación
4.2. Entregables
Escribir las rutinas (scripts) para la creación de objetos en la base de datos de acuerdo
con el modelo entidad relación, especificando llaves primarias y llaves foráneas.
Cuando el DBA reciba los scripts los completará con los parámetros de almacenamiento
adecuados de acuerdo con el tamaño de los registros y de las tablas.
Estos scripts deberán ser revisados por el Administrador de Bases de Datos y aplicados
en conjunto.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 291
Se crean los roles y se asocian a los usuarios que se definan, según las acciones que
les correspondan. Se debe implementar la seguridad en la base de datos.
c. Programación
En caso de requerirse una migración de datos desde una aplicación anterior o bien
desde un ingreso masivo de información, se debe tomar en cuenta la depuración
que requiera esta información. El Líder de Proyecto deberá considerar este traspaso
como un subproyecto adicional, donde incluirá los requerimientos de recurso
humano y tecnológico para su ejecución, asimismo deberá negociar estos recursos.
Esta conversión o ingreso masivo de información se ejecutará durante la etapa de
implantación.
Cada uno de los módulos generados deberá estar sujeto a una revisión de su
funcionalidad por parte del Líder de Proyecto o quien él designe y a una revisión de
tipo técnico para garantizar su calidad.
292 / Normas Técnicas en Tecnologías de Información y Comunicaciones
4.2.2. Pruebas
Se debe retomar el documento de diseño de pruebas para comprobar que está acorde
con las características del sistema y que está vigente en cuanto a los casos de prueba
a realizar y a la definición de usuarios que van a participar en este proceso. De ser
necesario se realizará la generación de datos para las pruebas de los módulos.
Esta actividad requiere que se pruebe la operación integral de todos los componentes
del sistema y su interacción con otros sistemas, de manera que se asegure el
cumplimiento de los requerimientos de integración especificados. Estas pruebas
deben ser realizadas por el usuario final con al apoyo y colaboración del equipo de
desarrollo.
5. Documentación
5.1. Consideraciones
La documentación del sistema se genera durante el desarrollo de todas las fases del
proyecto; sin embargo, hay un conjunto de documentos específicos a generar: manual
de usuario, manual de operación y manual técnico.
5.2. Entregables
• Manual de usuario: guía para la utilización del sistema por los usuarios.
• Manual técnico: descripción, a nivel técnico, de todos los componentes del
sistema.
• Manual de operación: descripción de procesos operativos del sistema.
Son todos los documentos generados e identificados como entregables, en cada una
de las fases, y que deben formar parte del archivo del proyecto:
• Cronograma ajustado
• Correspondencia generada
Programación y pruebas
• Scripts de creación de objetos
• Inventario de componentes de programación
• Constancia de pruebas
• Aceptación del sistema
Capacitación
• Constancia de la capacitación
296 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Implementación
• Plan de implementación
• Aprobación del inicio de operación
• Entrega del sistema
Manual de usuario
Manual técnico
Manual de operación
El manual del usuario debe ser conciso y práctico, sin dejar de ser exhaustivo,
de manera que los usuarios encuentren en él toda la información necesaria para
interactuar con el sistema. Se debe combinar la descripción textual, con la gráfica, de
manera que al usuario se le facilite su uso.
• Introducción
• Estándares del Sistema
• Requerimientos tecnológicos
• Cómo se ingresa al Sistema
• Descripción del Menú Principal del Sistema
• Descripción textual y gráfica de cada pantalla (sea de registro o consulta)
• Descripción del uso e impresión de reportes
• Cómo y a quién reportar errores del sistema
Normas Técnicas en Tecnologías de Información y Comunicaciones / 297
En este manual se deben describir, de manera detallada, todos los componentes del
sistema desde el punto de vista técnico. En dicha documentación deben explicarse
todos los aspectos necesarios para el posterior mantenimiento de la aplicación.
Manual donde se describan todas las actividades operativas del sistema como
creación de usuarios, procedimientos de respaldo y recuperación, procesos diarios o
periódicos, generación de datos para otros sistemas o entidades y la descripción de
cualquier otro proceso.
298 / Normas Técnicas en Tecnologías de Información y Comunicaciones
6. Capacitación
6.1. Consideraciones
7. Implementación
7.1. Consideraciones
7.2. Entregables
a. Estrategia de implementación
b. Calendarización de actividades
Se refiere a un cronograma específico para esta etapa. Se deben revisar las actividades,
recursos y tiempos programados en la planificación inicial del proyecto para hacer las
modificaciones que se requieran. Estas modificaciones deben ser del conocimiento
300 / Normas Técnicas en Tecnologías de Información y Comunicaciones
En caso de requerirse una migración de datos desde una aplicación anterior o bien
mediante el ingreso masivo de información, el Líder de Proyecto deberá considerar
este traspaso como un subproyecto, donde incluirá los requerimientos de recurso
humano y tecnológico para su ejecución y sus respectivos controles de calidad y
completitud.
Aquí se confirma que el sistema terminado cumple con los requisitos acordados y que
puede ser puesto en producción.
8. Evaluación post-implantación
Esta etapa supone la realización de una sesión con el equipo de proyecto para discutir
las lecciones aprendidas en el proceso de desarrollo e implantación, de donde incluso
pueden derivarse mejoras a ser incorporadas a esta Guía Metodológica de acuerdo al
proceso establecido para su actualización. Adicionalmente se generará una rendición
de cuentas final y la relación costo/beneficio efectiva del proyecto.
304 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo 5.
Mantenimiento de sistemas.
1. Mantenimiento de sistemas
Una vez aprobado el ajuste con base a lo establecido por el procedimiento de control
de cambios, se conforma el equipo de trabajo para el desarrollo correspondiente,
dándole tratamiento como un proyecto normal, ajustando todo al tamaño y condiciones
del trabajo a realizar.
Para llevar a cabo el mantenimiento se debe hacer una lista con las actividades por
medio de las cuales éste se realizará. Con esta lista de actividades, se determinará
si es necesario formular un cronograma para esta etapa, o simplemente efectuar un
acuerdo entre el Líder de Proyecto y el Líder Técnico sobre cómo se realizará, y cuál
será el alcance que tendrá.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 305
Para especificarlos debe existir una sesión de trabajo, en la cual el Líder Técnico deje
claro qué se puede atender y qué no, de manera que todos los requerimientos que
sean viables se implementen en el mantenimiento, con el visto bueno del Líder de
proyecto.
1.5. Capacitación
Con todos los ajustes aprobados y efectuada la capacitación, se realizarán los ajustes
necesarios en el equipo de producción (tanto en el equipo principal como en el equipo
periférico, según corresponda), implementando el sistema actualizado, de acuerdo
con los estándares definidos.
Dependiendo del tipo de ajuste realizado, se deberá realizar una etapa de post-
implantación, según lo establecido en esta Guía.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 307
Anexo 6.
Formulario para documentación de las reuniones del proyecto.
ASISTENCIA:
X
X
prevista
ASUNTOS TRATADOS:
ACUERDOS:
Anexo 7.
Ficha de Anteproyecto.
FICHA DE ANTEPROYECTO
Efecto _________________________________________________________
_________________________________________________________
Objetivo _________________________________________________________
_________________________________________________________
Productos _________________________________________________________
_________________________________________________________
Enfoque _________________________________________________________
_________________________________________________________
Alcance _________________________________________________________
_________________________________________________________
Relaciones de
Coordinación _________________________________________________________
Responsable _________________________________________________________
Prioridad _________________________________________________________
Requerimientos _________________________________________________________
Iniciales _________________________________________________________
Explicación Detallada
Resultado esperado:
Deben establecerse los resultados esperados en los campos de acción de la Contraloría
que aparecen en la estrategia institucional, con los cuales se considere que el proyecto
contribuye.
En este apartado debe anotarse tanto la numeración como el resultado esperado tal y
como se consignan en el documento de la Estrategia Institucional. Lo anterior con el
objeto de interrelacionar ordenadamente la planificación con la estrategia institucional.
Efecto:
Para que un proyecto sea viable dentro de la CGR, el mismo debe aportar un valor
agregado a la misma, o sea que el mismo coadyuve a que la organización cumpla sus
fines y objetivos. En estos términos se deben aportar los razonamientos que muestren
como el proyecto ayudará a que la CGR sea más eficiente y productiva. Un proyecto
que no se pueda justificar en los términos anteriores, simplemente no se debe realizar.
Objetivo:
Es el nivel de desempeño que se debe lograr para satisfacer una necesidad determinada.
Los objetivos deben tener una relación directa con dicha necesidad, y es conveniente
que se estructuren según los siguientes componentes:
• El para qué: cuando sea necesario se puede indicar para qué se quiere
alcanzar el objetivo, lo cual está en función de la necesidad que se desea
satisfacer, de manera que el lector perciba expresamente esa necesidad
aún cuando no tenga conocimiento en la materia.
Según sea el caso puede definir un objetivo general y varios objetivos específicos.
Productos:
Los resultados inmediatos del proyecto que propiciarán el alcance del objetivo.
Enfoque:
Determina la(s) característica(s) u orientación particular con que se quiere desarrollar
el proyecto. Por ejemplo: participativo, consensuado, externalización, fiscalización
horizontal o unilateral.
Alcance:
Ámbito de acción propio del proyecto.
Relaciones de coordinación:
Definen la interacción del proyecto, definiendo en principio lo que se requiere
para su desarrollo (identifica proveedores), y lo que debe aportar a otras unidades
organizacionales o a otros proyectos (identifica clientes). En primer lugar se establecen
los clientes del proyecto, que llevan al producto deseado, lo cual conduce a los
proveedores que suministran los recursos para obtener los productos. En este aparte
se debe definir el rol que asume cada uno de los involucrados en el proyecto.
Responsable:
Unidad patrocinadora a la que se le asignará la responsabilidad de administrar el
proyecto, y en consecuencia la que debe rendir cuentas por el logro de los objetivos
planteados.
Prioridad:
Normas Técnicas en Tecnologías de Información y Comunicaciones / 311
El grado de urgencia del asunto. Debe estar relacionado con el impacto de los productos
y con la disponibilidad de tiempo para la ejecución. Se define en función del tiempo
con que se cuenta para tener los productos y de su impacto.
Requerimientos iniciales:
Indican en forma general los aspectos o acciones necesarias que deben desarrollarse
en el proyecto, con el propósito de que éste brinde los efectos y resultados esperados.
Dichos requerimientos deben analizarse según los componentes del modelo gerencial
de esta Contraloría General: Procesos Internos, Recursos Humanos y Sistemas de
Información.
Elaborado por:
En este campo se debe consignar el nombre del funcionario que está promoviendo en
su etapa inicial el proyecto.
Fecha:
Este campo almacenará la fecha en que se elaboró el documento.
312 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo 8.
Descriptivo de la Organización del Proyecto.
Objetivo _________________________________________________________
_________________________________________________________
_________________________________________________________
Nombre Unidad
______________________________________ _____________________________
______________________________________ _____________________________
______________________________________ _____________________________
______________________________________ _____________________________
______________________________________ _____________________________
Nombre Unidad
______________________________________ _____________________________
______________________________________ _____________________________
______________________________________ _____________________________
Explicación Detallada.
Código de Proyecto:
Para efectos prácticos y con el fin de mejorar aspectos de documentación y archivo,
todo sistema será conocido por un código asignado tomando como referencia el
número de gestión y proceso que tendrá el proyecto en el Sistema de Gestión y
Documentos (SIGYD). Con dicho número se podrá entonces revisar en el SIGYD toda
la correspondencia asociada, el detalle del equipo de trabajo, fechas importantes y las
horas dedicadas. Por ejemplo: 2008000123-5.
Siglas:
Se deben consignar las siglas que la USTI le asigne al proyecto.
Elaborado por:
En este campo se debe consignar el nombre del funcionario que está promoviendo en
su etapa inicial el proyecto.
Fecha:
Este campo almacenará la fecha en que se elaboró el documento.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 315
Anexo 9.
Ficha de Estrategia de Solución del proyecto.
ESTRATEGIA DE SOLUCION
_________________________________________________________
_________________________________________________________
_________________________________________________________
Explicación Detallada.
Código de Proyecto:
Código asignado tomando como referencia el número de gestión y proceso que tendrá
el proyecto en el Sistema de Gestión y Documentos (SIGYD).
Siglas:
Se deben consignar las siglas que la USTI le asigne al proyecto.
Aprobado por:
Es el nombre del coordinador de la Unidad Ejecutora.
Fecha:
Fecha en que se emite el documento.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 317
Anexo 10.
Formulario para la Planeación de Recursos.
PLANEACION DE RECURSOS
Recursos Requeridos
Humanos: _________________________________________________________
____________
________________________________________________________________________
__________________________________________________________________
Tecnológicos:
_____________________________________________________________________
_____________________________________________________________________
_____________________________________________________________________
Materiales:
________________________________________________________________________
________________________________________________________________________
__________________________________________________________________
Financieros:
________________________________________________________________________
________________________________________________________________________
__________________________________________________________________
Explicación detallada.
318 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Código de Proyecto:
En este campo se consignará el código que se le asignó al proyecto.
Recursos Humanos:
En este campo se debe anotar cada una de las personas que se requerirán durante el
ciclo de vida del proyecto, con el fin de que las mismas sean ubicadas a tiempo, según
sea el caso. Además deberá indicarse para cada persona el grado de dedicación al
proyecto, dentro de un periodo debidamente especificado en esta sección.
Para que un proyecto sea exitoso cada integrante del equipo de trabajo debe
comprometer un número determinado de horas de su horario normal. De no ser así,
ese funcionario no debe estar integrando el equipo de trabajo y debe ser sustituido.
No existe una formula fija, sin embargo reglas basadas en la experiencia indican que
el líder de un proyecto de mediano a gran tamaño, debe dedicarse a tiempo completo
al proyecto; los otros integrantes del equipo podrían no estar a tiempo completo pero
su grado de dedicación debe quedar claramente establecido para todos los miembros,
ya que esto incide directamente en el tiempo requerido para el logro de las metas y
objetivos del proyecto.
Según sea el caso se debe anotar el perfil requerido para el recurso; por ejemplo: se
requiere un programador en JAVA con basta experiencia, durante un lapso de cinco
meses, para laborar a medio tiempo. Se requiere los servicios de un experto en
instalación de redes de fibra óptica, para trabajar por tres meses a tiempo completo,
para laborar en las oficinas centrales de la CGR.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 319
Recursos Tecnológicos:
En este campo se deben anotar aquellos recursos tecnológicos con que se debe contar
en un momento determinado, para la buena marcha del proyecto. Es necesario indicar
cantidades, tiempo y especificaciones técnicas.
Por ejemplo:
Recursos Materiales:
En este campo se deben anotar aquellos recursos materiales, necesarios para la buena
marcha del proyecto. Es necesario indicar cantidades, tiempo y características.
Ejemplos.
Recursos Financieros:
En este campo se debe hacer referencia a un presupuesto de gastos, lo mismo que
a un flujo de efectivo, dependiendo de la complejidad del proyecto, los presupuestos
serán más o menos detallados. En algunos proyectos de la CGR, podrían no tener
presupuesto o flujos de efectivo, sobre todo aquellos que lo único que requieren es
el aporte del esfuerzo personal de su grupo de trabajo, para obtener un determinado
producto como lo es por ejemplo un desarrollo interno de sistemas, un ante-proyecto,
la redacción de una política o lineamiento.
320 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Elaborado por:
En este campo se debe consignar el nombre de la persona que elaboró el documento.
Fecha:
En este campo se debe consignar la fecha en que se elaboró el documento.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 321
Anexo 11.
Formulario para documentar Acciones Correctivas o Preventivas.
Motivos:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Explicación detallada.
Siglas:
Se deben consignar las siglas que la USTI le asigne al proyecto.
322 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Motivos:
En este campo se deben documentar los motivos por los que, a criterio del equipo de
trabajo, la actividad tiende a estar o está desfasada.
Elaborado por:
En este campo se debe consignar el nombre de la persona que elaboró el documento.
Fecha:
En este campo se debe consignar la fecha en que se elaboró el documento.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 323
Anexo 12.
Formulario para llevar el Control de Cambios del Proyecto
Cambio requerido:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Justificación:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Explicación detallada.
Siglas:
Se deben consignar las siglas que la USTI le asigne al proyecto.
Cambio requerido:
Debe detallar en que consistió el cambio dentro del proyecto.
Justificación:
Asociado al cambio anterior debe indicar la justificación o el por qué se presentó el
cambio.
Elaborado por:
En este campo se debe consignar el nombre de la persona que elaboró el documento.
Fecha:
En este campo se debe consignar la fecha en que se elaboró el documento.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 325
Anexo 13.
Formulario para la Aceptación de Productos Finales del Proyecto
Productos entregados:
_____________________________________________________
_____________________________________________________
_____________________________________________________
_____________________________________________________
Observaciones:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Fecha: ___________________
Explicación detallada.
Siglas:
Se deben consignar las siglas que la USTI le asigne al proyecto.
326 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Productos entregados:
Se listan todos los productos finales que deja el proyecto que concluye. Pueden ser;
entre otros, sistemas operando, documentación, o tecnología operando.
Observaciones:
El coordinador de la Unidad Ejecutora puede dejar constancia de puntos que considera
importantes en relación a alguno de los productos, sobre todo si los requiere ser
retomado en futuras versiones del proyecto.
Acepta a satisfacción:
En este campo se debe consignar el nombre del coordinador de la Unidad Ejecutora,
dando por aceptados los productos finales.
Firma:
Firma del coordinador de la Unidad Ejecutora.
Fecha:
En este campo se debe consignar la fecha en que se elaboró el documento.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 327
Anexo 14.
Diagramas de Casos de Uso
Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso
del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere
a su interacción externa. En el diagrama de casos de uso se representa también el
sistema como una caja rectangular con el nombre en su interior. Los casos de uso
están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido
a los casos de uso en los que participa mediante una línea. En la siguiente figura se
muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.
1. Elementos
Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores,
casos de uso y relaciones entre casos de uso.
328 / Normas Técnicas en Tecnologías de Información y Comunicaciones
1.1 Actores
Un actor es algo con comportamiento, como una persona (identificada por un rol), un
sistema informatizado u organización, y que realiza algún tipo de interacción con el
sistema. Se representa mediante una figura humana. Esta representación sirve tanto
para actores que son personas como para otro tipo de actores.
Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo
para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción
con un alcance menor como caso de uso con fines de mejorar la comunicación en
el equipo de desarrollo y en el manejo de la documentación de casos de uso. Si
queremos utilizar casos de uso más pequeños, las relaciones entre estos y los casos
de uso ordinarios pueden ser de los siguientes tres tipos:
• Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos
de extensión) en los cuales, dependiendo de ciertos criterios, se va a
realizar una interacción adicional. El caso de uso que extiende describe un
comportamiento opcional del sistema (a diferencia de la relación Incluye que
se da siempre que se realiza la interacción descrita) En la siguiente figura
se muestra como el caso de uso “Comprar Producto” permite explícitamente
extensiones en el siguiente punto de extensión: info regalo. La interacción
correspondiente a establecer los detalles sobre un producto que se envía
como regalo están descritos en el caso de uso “Detalles Regalo”.
entre clases) pegado al extremo del caso de uso más general. Al igual que
en la herencia entre clases, el caso de uso hijo hereda las asociaciones y
características del caso de uso padre. El caso de uso padre se trata de un
caso de uso abstracto, que no está definido completamente. Este tipo de
relación se utiliza mucho menos que las dos anteriores. El caso de uso hijo
hereda el comportamiento y significado del caso de uso padre.
UML no define un formato para describir un caso de uso. Tan sólo define la manera
de representar la relación entre actores y casos de uso en un diagrama: el Diagrama
de Casos de Uso. Sin embargo, un caso de uso individual no es un diagrama, es
un documento de texto. En la siguiente sección se define el formato textual para la
descripción de un caso de uso que se va a utilizar en este documento.
Un escenario es un camino concreto a través del caso de uso, una secuencia específica
de acciones e interacciones entre los actores y el sistema. En un primer momento
332 / Normas Técnicas en Tecnologías de Información y Comunicaciones
El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se
está usando un cajero automático:
Los casos de uso que se consideren los más importantes y que se considere que son
los que más influencian al resto, se describen a un nivel más detallado en el formato
expandido.
La principal diferencia con un caso de uso de alto nivel está en que incluye un apartado
de Curso Típico de Eventos, pero también incluye otros apartados como se ve en el
siguiente ejemplo:
Normas Técnicas en Tecnologías de Información y Comunicaciones / 333
Cursos Alternativos:
• Línea 4: La clave es incorrecta. Se indica el error y se cancela la operación.
• Línea 8: La cantidad solicitada supera el saldo. Se indica el error y se
cancela la operación.
334 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Como guía para la identificación inicial de casos de uso hay dos métodos:
Normas Técnicas en Tecnologías de Información y Comunicaciones / 335
a. Basado en Actores
1. Identificar los actores relacionados con el sistema y/o la organización.
2. Para cada actor, identificar los procesos que inicia o en los que participa.
b. Basado en Eventos
1. Identificar los eventos externos a los que el sistema va a tener que responder.
2. Relacionar los eventos con actores y casos de uso.
Al definir los límites del sistema se establece una diferenciación entre lo que es interno
y lo que es externo al sistema. El entorno exterior se representa mediante los actores.
a. Según Importancia
En las descripciones que se han visto se han descrito los casos de uso a un nivel
abstracto, independientemente de la tecnología y de la implementación. Un caso de
uso definido a nivel abstracto se denomina esencial. Los casos de uso definidos a alto
nivel son siempre esenciales por naturaleza, debido a su brevedad y abstracción.
5. etc. 6. etc.
En principio, los casos de uso reales deberían ser creados en la fase de Diseño de
Bajo Nivel y no antes. Sin embargo, en algunos proyectos se plantea la definición de
interfaces en fases tempranas del ciclo de desarrollo, en base a que son parte del
contrato. En este caso se pueden definir algunos o todos los casos de uso reales, a
pesar de que suponen tomar decisiones de diseño muy pronto en el ciclo de vida.
No hay una diferencia estricta entre un Caso de Uso Esencial y uno Real, el grado de
compromiso con el diseño es un continuo, y una descripción específica de un caso de
uso estará situada en algún punto de la línea entre Casos de Uso Esenciales y Reales,
normalmente más cercano a un extremo que al otro, pero es raro encontrar Casos de
Uso Esenciales o Reales puros.
a. Nombre
El nombre de un Caso de Uso debería ser un verbo, para enfatizar que se trata de un
proceso, por ejemplo: Comprar Artículos o Realizar Pedido.
b. Alternativas
todas ellas consideradas normales se puede completar el Curso Típico de Eventos con
secciones adicionales.
• Sección: Principal
Cursos Alternativos:
• Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.
Cursos Alternativos:
• Línea 3: No hay cambio suficiente. Se cancela la operación.
• Sección: Pago con Tarjeta
1.1. Generalidades
伀爀 最愀渀椀稀愀挀椀渀
䐀攀猀瀀愀挀栀漀
䌀 漀渀琀爀 愀氀漀爀 愀 䜀 攀渀攀爀 愀氀
䌀 漀洀椀琀 䜀 攀爀攀渀挀椀愀氀
搀攀 吀 䤀 䌀 됀猀
䐀椀瘀椀猀椀渀
䜀 攀猀琀椀渀 搀攀 䄀 瀀漀礀漀
唀渀椀搀愀搀
吀攀挀渀漀氀漀最愀猀 䤀 渀昀漀爀 洀愀挀椀渀
倀爀攀猀甀瀀甀攀猀琀漀 礀
匀攀挀爀攀琀愀爀 愀
䌀 漀洀瀀爀 愀猀
Jefatura de Unidad:
Es el responsable de la Unidad y coordina toda la gestión del desarrollo de proyectos
tecnológicos. En el rol del proceso de calidad es el encargado de velar por el
cumplimiento de las políticas de calidad.
344 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Soporte Administrativo:
Consiste en brindar servicios asistenciales relacionados con presupuesto y compras
en tecnologías de información.
Soporte a Clientes:
Este grupo brinda soporte técnico a las computadoras, sus accesorios y programas
que tienen los usuarios internos de la CGR. Este soporte implica la atención de fallas
en los equipos, instalación de programas y recuperación de datos.
Desarrollo de Sistemas:
Los funcionarios pertenecientes a este grupo se encargan de la gestión de desarrollo
y evolución de sistemas y aplicaciones.
Plataforma Tecnológica:
El grupo de plataforma tecnológica es el encargado del buen funcionamiento y
desempeño de los servidores y bases de datos.
Plataforma de redes:
Es el grupo encargado de la gestión de las comunicaciones tanto digitales como
telefónicas, administrando la infraestructura de firewall, “routers” y “ switches” para el
transporte de datos, voz y video, así como la seguridad relacionada con antivirus, filtro
de contenidos y perimetral.
Centro de Cómputo:
Administra la infraestructura tecnológica centralizada en la sala del centro, supervisa
el buen funcionamiento y asegura la generación de respaldos de bases de datos y
sistemas operativos.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 345
Para un mejor entendimiento del presente Manual, son aplicables los términos y
definiciones de la norma internacional ISO 9000:2000 Sistemas de Gestión de la
Calidad –Fundamentos y vocabulario.
2.2.1. Generalidades
Este manual de la calidad incluye el alcance del Sistema de Gestión de Calidad, sus
exclusiones y las consideraciones en materia de calidad que se contemplan en las
soluciones tecnológicas.
La CGR considera los registros como un tipo especial de documento por lo que se
establece y mantienen registros para proporcionar evidencia de la conformidad con los
requisitos así como del funcionamiento efectivo del producto o servicio. Los registros
permanecen legibles, fácilmente identificables y recuperables de conformidad con
las políticas establecidas para la retención y desecho de documentos definidas por
Archivos Nacionales.
3. RESPONSABILIDAD DE LA DIRECCIÓN
Cada líder de proyecto contará con el apoyo del Coordinador de Proyectos, el líder
técnico y el grupo de apoyo de manera que se pueda asegurar las necesidades y
expectativas de los usuarios que han sido convertidas en requisitos y son cumplidas con
la finalidad de lograr la satisfacción de éstos, considerando siempre las obligaciones
reglamentarias y legales.
3.3. Planificación
3.3.1. Objetivos de la calidad
El líder de proyectos, asegura que los objetivos de calidad han sido establecidos para
todas las funciones y niveles relevantes dentro de la organización, y que son medidos
y consistentes con la política de la calidad.
Las responsabilidades de las personas que participan en cada uno de los proceso
de la Contraloría General de la República, están regidos por: “Manual de Actividades
Ocupacionales”; Manual Descriptivo de Puestos” y por el “Estatuto Autónomo de
Servicios”.
Además existe un organigrama (Ver 1.1) donde se han definido las líneas de autoridad
de la institución.
La responsabilidad de cada líder de proyecto incluye las relaciones con partes externas
sobre asuntos relacionados con el Sistema de Gestión de la Calidad.
352 / Normas Técnicas en Tecnologías de Información y Comunicaciones
4. GESTIÓN DE RECURSOS
4.2.3. Infraestructura
Por medio de las unidades de apoyo se administran los factores humanos y físicos
(ambiente de trabajo), necesarios para lograr la conformidad de los productos y
servicios, tales como:
5. CONSIDERACIONES EN EL DESARROLLO
La gestión de la calidad del proyecto debe abordar tanto la gestión del proyecto
como el producto del mismo. Mientras que la gestión de la calidad del proyecto es
aplicable a todos los proyectos, independientemente de la naturaleza de su producto,
las medidas y técnicas de calidad del producto son específicas del tipo de producto
producido por el proyecto.
5.1.1. Planificación
5.1.2. Aseguramiento
• El líder del proyecto se encargará de que todos los participantes del grupo de
desarrollo comprenda su labor y sus responsabilidades dentro del proyecto.
• Se debe contar con un patrocinador del proyecto que participe y se
comprometa.
• El líder del proyecto revisará mensualmente los productos obtenidos en el
mes y la documentación relacionada con cada uno de ellos.
• Cada proyecto debe tener un “Libro de Proyecto” en el Sistema de Expediente
Electrónico, al que se le debe de incorporar toda la documentación
establecida en la Metodología para el Desarrollo de Proyectos del mismo.
• Se debe de establecer un grupo de proyecto que lo constituya como mínimo
un líder de proyecto y un líder técnico.
• Reporte mensual que se presentará al Gerente de Proyectos de acuerdo
con lo establecido en la Metodología y el Manual de Estándares.
• Elaboración de listas de cotejo con las actividades de la etapa.
• Presentación del producto final de la etapa en donde se encuentre el
Gerente de Proyectos, el Patrocinador y los involucrados directos.
5.1.3. Control
• Visto bueno de los plazos para los entregables por parte del Comité de
Apoyo.
• Mapa de riesgos y administración de los mismos.
• Matriz de las formas de comunicación que se utilizarán en el proyecto.
• Reportes mensuales de avance.
• Diagrama organizacional del proyecto con los roles establecidos.
• Documentación de análisis realizado en internet, libros, referencias o visitas
realizadas.
• Verificar la aceptación de la etapa de Análisis del proyecto por parte del
Patrocinador, del Gerente de Proyectos y del grupo de apoyo.
• Verificación de las minutas de reuniones.
• Determinar los planes de contingencia de acuerdo con los riesgos
encontrados.
• Conciliar y confirmar los supuestos establecidos de acuerdo con la
Metodología para el Desarrollo (detallar qué implica y qué debe contener).
Durante esta etapa, se inicia la creación de un modelo de solución que cumpla con
los requisitos recopilados en las etapas anteriores. Al final del proceso, se debe tener
un modelo que cumpla con las necesidades del cliente.
5.2.1. Planificación
5.2.2. Aseguramiento
5.2.3. Control
5.3.1. Planificación
5.3.2. Aseguramiento
5.3.3. Control
5.4. Implementación
5.4.1. Planificación
5.4.2. Aseguramiento
5.4.3. Control
5.5. Operación
5.5.1. Planificación
• Verificar que todas las tablas tengan definidos los procesos para “purgar
datos” o de tablas históricas para su migración.
• Preparar un plan de contingencia y los protocolos que deben de seguirse
para ser incorporados al Sistema de Continuidad de Servicio.
• Definición de los umbrales de tolerancia para detener la implementación o
continuar con la misma.
• Plan de recuperación de datos en caso de una reversión.
• Definición del grupo encargado de realizar el seguimiento de la
implementación del producto o del servicio.
• Plan de divulgación sobre la implementación del producto o servicio.
5.5.2. Aseguramiento
5.5.3. Control
• Realizar el seguimiento del registro de bitácoras por parte del líder del
proyecto.
• Garantizar la búsqueda de soluciones a los problemas o inconvenientes
reportados.
• Realizar reuniones de seguimiento con personal designado por el
patrocinador del sistema.
• Preparar la documentación para el cierre del proyecto de conformidad con
lo establecido en la Metodología para el Desarrollo de Proyectos en TIC.
366 / Normas Técnicas en Tecnologías de Información y Comunicaciones
6.1. Generalidades
El Jefe de UTI debe de establecer los lineamientos para la realización de las auditorias
internas, desde la planeación de los programas, tomando en consideración el estado
y la importancia de los procesos y las áreas a auditar, así como los resultados de
auditorias anteriores. También debe definir los criterios de auditoria, el alcance de la
misma, su frecuencia y metodología, así como la transmisión del informe de resultados
y la conservación de los registros.
El personal de TIC que fungirá como auditor interno debe ser seleccionado de tal
manera que se asegura que la ejecución de las auditorias se lleven a cabo de manera
imparcial y objetiva, en otras palabras, los auditores no pueden auditar los procesos
en que estén involucrados.
Los responsables de cada una de las áreas que se estén auditando conocen la
importancia de tomar acciones rápidas sin pérdidas de tiempo, para eliminar las no
conformidades detectadas y sus causas.
Este proceso se enriquece con la entrega de informes mensuales sobre los incidentes
reportados, en los cuales se resumen la cantidad y su duración de atención. Estos
son recopilados por medio del Sistema de Solicitudes de Servicio, que se encuentra
en operación en la UTI.
La liberación del producto y la prestación del servicios no se lleva a cabo hasta que no
se haya completado satisfactoriamente las disposiciones planificadas, a menos que
sean aprobados de otra manera por el Gerente de la UTI y, cuando corresponda, por
el patrocinador del proyecto.
El producto que no sea conforme con los requisitos se identifica y controla por parte
del líder de proyecto, para prevenir su uso o entrega no intencional. Los controles,
las responsabilidades y autoridades relacionadas con el tratamiento del producto
no conforme están definidos en la Metodología para el Desarrollo de Proyectos de
Información y Comunicaciones.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 369
6.5. Mejora
6.5.1. Mejora Continua
Necesidad
En el contexto de la alta dependencia de las TIC para la gestión estratégica, táctica y
operativa de la información y las comunicaciones; es un asunto trascendental disponer
de un Modelo de Arquitectura de Información (MAI), que soportado en el modelado
de los procesos de la organización, establezca cual es la información que en éstos
fluye, el manejo que debe dársele y la integración entre los procesos a nivel de flujos
de información.
Este MAI deberá guiar la inserción, mantenimiento y evolución de las TIC en los procesos,
como principio básico para justificar la inversión en los elementos tecnológicos que
apoyarán el logro de las metas institucionales. Ese modelado debe ser la base sobre la
cual se construya la fiabilidad y el valor agregado de la incorporación de las TIC a los
procesos de la organización.
376 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normativa técnica
Las Normas Técnicas para la Gestión y el Control de las Tecnologías de Información,
emitidas mediante la Resolución del Despacho de la Contralora General de la República,
Nro. R-CO-26-2007 del 7 de junio de 2007, publicada en La Gaceta Nro.119 del 21
de junio de ese mismo año, incluye una norma referida al modelo de arquitectura de
información, en los siguientes términos:
Con la definición de esta primera versión del MAI la Contraloría General de la República
cumple con el referido numeral que específicamente regula este aspecto en dichas
Normas Técnicas.
Antecedentes
Toda organización cuenta con alguna estructura de información y comunicaciones.
Aún cuando nunca se haya dado a la tarea de identificarla ni documentarla, la
existencia y funcionamiento de la organización llevan necesariamente a tal estructura.
Al respecto, definir y documentar un modelo de arquitectura de información es un
nivel más evolucionado de gestión de la información, toda vez que es producto ya de
una decisión intencionada para mejorar la administración de TIC’s.
Alcances y limitaciones
La elaboración de un modelo de arquitectura de información debe partir de la
perspectiva de los procesos del negocio, para que así logre los resultados esperados.
El nivel de desarrollo del MAI en esta primera versión se alinea al nivel que lo permite
el modelado organizacional existente; inicialmente en términos de insumo, actividades
del proceso y productos, que es lo definido en el nuevo MAGEFI.
378 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Al momento de definir esta primera versión del MAI la Institución está iniciando con
la divulgación del nuevo MAGEFI, que será implementado paulatinamente por las
distintas unidades organizacionales que conforman la institución y las que el modelo
de fiscalización requiera para su funcionamiento.
Enfoque metodológico
La técnica utilizada para definir el modelo de arquitectura de información fue Business
System Planning, BSP (Planeamiento de los Sistemas del Negocio) con un enfoque
simplificado.
En primera instancia el equipo de trabajo realizó una revisión general del MAGEFI en
su nueva versión. Posteriormente, para cada uno de los procesos generó las siguientes
tablas:
Arquitectura de información
En el siguiente gráfico se presenta la arquitectura de información de la Contraloría
General de la República, condensando la información generada durante la aplicación
de la técnica del BSP.
䴀愀琀爀椀稀 䈀匀倀
Sistemas:
• Requerimientos de clientes externos (Planeado)
• Pronunciamientos (en construcción)
• Fiscalización Previa (Planeado)
• Fiscalización Posterior (en construcción)
• Procedimientos Administrativos (planeado)
• Litigios (Planeado)
• Asesoría sobre hacienda pública (Planeado)
• Capacitación Externa (Planeado)
• Rectoría (planeado)
• Servicio al Cliente Externo (Planeado)
Sistemas:
• Monitoreo del Entorno (Planeado)
• Planificación y Evaluación de la Gestión Institucional (Planeado)
Normas Técnicas en Tecnologías de Información y Comunicaciones / 381
Sistemas:
• Integrado de Recursos Humanos (actual)
• Sistema de Gestión del Conocimiento Institucional (planeado)
• BD soluciones TIC (en construcción)
• Memoria Anual (planeado)
Sistemas:
• Presupuesto Institucional (actual)
• Contabilidad (actual)
• Tesorería (requiere evolución)
• Bienes y Servicios (actual)
• Sistema de pagos (actual)
• Trámite de viáticos (en construcción)
Salidas
PP-01-P1 Respuestas a los requerimientos de clientes externos.
PP-01-P2 Solicitud interna de servicio
PP-01-P3 Propuestas de diseño o rediseño de nuevos productos
PP-01-P4 Análisis integral de requerimientos del cliente externo
Salidas
PP-02-P1 Criterio emitido
Salidas
PP-03-P1 Oficio de respuesta a solicitudes de fiscalización previa
PP-03-P2 Resoluciones en materia de contratación administrativa y levantamiento
de incompatibilidades
PP-03-P3 Certificación de la Efectividad Fiscal
Salidas
PP-04-P1 Nota Informe
PP-04-P2 Informe
PP-04-P3 Relación de hechos
PP-04-P4 Denuncia penal
Normas Técnicas en Tecnologías de Información y Comunicaciones / 385
Salidas
PP-05-P1 Resolución final del procedimiento administrativo
PP-05-P2 Registro de sancionados
PP-05-P3 Título ejecutivo
Salidas
PP-06-P1 Escrito inicial del proceso
PP-06-P2 Oficios de atención al proceso judicial
PP-06-P3 Atención de audiencias en sede judicial
386 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Salidas
PP-07-P1 Documentos de análisis u opinión sobre Hacienda Pública
PP-07-P2 Asesorías escritas
PP-07-P3 Asesorías verbales
PP-07-P4 Memoria Anual
PP-07-P5 Documentos técnicos de análisis macro
PP-07-P6 Manuales o guías de buenas prácticas
Salidas
PP-08-P1 Datos de las actividades de capacitación externa
Salidas
PP-09-P1 Directrices
PP-09-P2 Políticas
PP-09-P3 Reglamento
PP-09-P4 Manual de normas
PP-09-P5 Orden
PP-09-P6 Solicitud de colaboración obligada
388 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Salidas
PP-10-P1 Productos de fiscalización entregados
PP-10-P2 Resolución de los recursos o quejas sobre el producto y servicio
PP-10-P3 Productos de divulgación
PP-10-P4 Oficios de respuesta a los solicitantes de servicios
PP-10-P5 Reportes de medición de valor público
PP-10-P6 Reportes sobre sugerencias de los clientes externos
Salidas
PA-01-P1 Informes de análisis del entorno
PA-01-P2 Inventario de riesgos externos
PA-01-P3 Información sistematizada sobre los sujetos fiscalizados
PA-01-P4 Informe de diagnóstico de necesidades de los sujetos fiscalizados
PG-01-P1 Solicitudes de asesoría interna
Salidas
PA-02-P1 Planes Institucionales
PA-02-P2 Informe de evaluación
PA-02-P3 Perfil de proyecto
PA-02-P4 Lineamientos de planificación institucional
PA-02-P5 Requerimientos presupuestarios para el período
Salidas
PA-03-P1 Modelo organizacional
PA-03-P2 Normativa interna CGR
Normas Técnicas en Tecnologías de Información y Comunicaciones / 391
Salidas
PA-04-P1 Asesoría interna escrita
PA-04-P2 Asesoría interna verbal
PA-04-P3 Advertencias de la auditoría interna
392 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Salidas
PA-05-P1 Propuestas de proyectos de mejora
PA-05-P2 Propuestas de acciones de mejora
PA-05-P3 Informes de revisión interna y externa
Normas Técnicas en Tecnologías de Información y Comunicaciones / 393
Salidas
PA-06-P1 Datos del personal con experiencias de aprendizaje
PA-06-P2 Datos del personal contratado
PA-06-P3 Retroalimentación del desempeño del personal
PA-06-P4 Mecanismos de promoción de valores y de ideas rectoras
PA-06-P5 Incentivos laborales aplicados
Perfil de competencias vigente de las funcionarias y funcionarios de la CGR
394 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Salidas
PA-07-P1 Información requerida disponible
Salidas
PA-08-P1 Datos de la solución de tecnología de información operando
Salidas
PA-09-P1 Memoria organizacional
396 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Salidas
PA-10-P1 Datos de Recursos presupuestarios
PA-10-P2 Separación de recursos
Salidas
PA-11-P1 Estados financieros
PA-11-P2 Informes de análisis financiero contables
Salidas
PA-12-P1 Datos sobre recursos financieros ejecutados
PA-12-P2 Orden de pago
398 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Salidas
PA-13-P1 Recibo a satisfacción del bien
PA-13-P2 Bienes recibidos
PA-13-P3 Servicios contratados
PA-13-P4 Resoluciones por incumplimientos contractuales
PA-13-P5 Interposición de juicio para reclamo de daños y perjuicios
PA-14-P1 Datos de los bienes en operación
PA-15-P1 Servicios auxiliares prestados
PA-15-P2 Informe de cumplimiento de servicios
Normas Técnicas en Tecnologías de Información y Comunicaciones / 399
ANEXO
刀攀氀愀挀椀漀渀愀搀漀 挀漀渀
䴀愀最攀昀椀
400 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo - NTP10
Marco de Seguridad en
tecnologías de Información
402 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normas Técnicas en Tecnologías de Información y Comunicaciones / 403
A. Introducción.
B. POLÍTICA DE SEGURIDAD.
1
Más adelante se define formalmente la figura del Oficial de Seguridad en TIC.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 405
Como parte del grupo interdisciplinario de funcionarios que conforman el CS, deberán
considerarse al menos las siguientes áreas:
La CGR debe someter cada dos años sus funciones de seguridad informática a
procesos independientes de verificación de su funcionamiento, aplicabilidad,
efectividad y eficiencia.
408 / Normas Técnicas en Tecnologías de Información y Comunicaciones
D. Gestión de Activos.
Los activos de TIC deben estar clasificados según su nivel de criticidad, considerando
dentro de este inventario tanto los recursos físicos (computadoras, servidores, equipos
de comunicaciones) como los recursos lógicos (sistemas, paquetes, licencias).
Los niveles de criticidad serán analizados y definidos por los patrocinadores de las
soluciones tecnológicas.
La CGR debe contar con los mecanismos necesarios para informar a todos los
funcionarios sobre sus responsabilidades en el uso de las Tecnologías de Información
y Comunicaciones. Para esto se deben realizar en coordinación con la Unidad de
Recursos Humanos charlas de inducción y sensibilización1 respecto a las TIC.
1
Se entiende por sensibilización el proceso mediante el cual se pretende inculcar en los funcionarios la conciencia del uso
adecuado de las TIC para garantizar los niveles adecuados de seguridad que requiere la institución.
410 / Normas Técnicas en Tecnologías de Información y Comunicaciones
La USTI debe definir un proceso de información a los usuarios respecto al uso de las
tecnologías. Este mecanismo debe considerar al menos:
E2. Seguimiento.
El CSO debe definir los niveles de seguridad necesarios para garantizar las medidas
de protección a los activos tecnológicos de la CGR. Estos niveles de seguridad deben
estar asociados al nivel de criticidad y seguridad que se le definan a los activos.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 411
Se definen tres niveles de criticidad, los cuales estarán asociados a diferentes controles
según el nivel. Los niveles son:
Activos críticos: Son aquellos que su ausencia provoca que se imposibiliten los
procesos básicos de la Contraloría, provocando problemas internos y externos.
Activo medianamente críticos: Son aquellos activos que son necesarios para el quehacer
de la CGR, sin embargo se puede disponer de un tiempo determinado para volverlo a
poner en operación en caso de que falle.
Activos no críticos: Son aquellos que su ausencia temporal no presenta ningún riesgo
para el quehacer de la CGR. El recurso debe volver a ponerse en funcionamiento.
Para cada uno de estos tres tipos de criticidad, se asocian niveles de control y seguridad
sobre los activos. Estos niveles son:
Nivel 1: Nivel máximo. En este nivel se establecen controles sobre activos (equipos e
información) que sean considerados como críticos a nivel Institucional.
Nivel 2: Nivel intermedio. Este nivel debe contemplar controles sobre activos (equipos
e información) que sean menos críticos, y que no contemplen todas las medidas de
seguridad establecidas para el perímetro –Nivel 1-.
Nivel 3: Nivel bajo. Este nivel debe contemplar el resto de la plataforma de TIC, la cual
estará regida según las directrices institucionales en el uso de las tecnologías, pero
no estará protegida por los esquemas de seguridad considerados en los niveles 1 y 2.
412 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Para cada uno de los perímetros de seguridad física definidos en el punto anterior, se
deben considerar condiciones básicas de seguridad. Estas condiciones deben ser:
Nivel 1:
• Recinto privado con acceso restringido.
• Cámaras de vigilancia con capacidad de almacenamiento de la información
de al menos una semana de tiempo y transmisión en vivo de la imagen a
un centro de control.
• Sensores de calor, humedad con conectividad a un centro de control para
el envío de alertas.
• Puertas de seguridad para el acceso al recinto.
• Control y registro electrónico de los accesos que se realicen al recinto.
• Administración por parte de un encargado formalmente definido.
• Control mediante bitácora del personal que acceda al recinto.
• Control mediante bitácora de los ingresos y salidas de equipos al recinto.
• Dispositivos de control de fuego.
• Aires acondicionados acordes a la capacidad instalada de equipos y con
conexión a unidades alternas de energía. (Para garantizar su operación
ante fallo del sistema eléctrico).
• Conexión eléctrica con protección y fuentes ininterrumpidas de poder.
• Ubicación física de los equipos considerando la facilidad de manipulación
por parte de personal técnico, y alejados de fuentes posibles de riesgo:
rayos del sol en forma directa, humedad, emisiones contaminantes y calor.
• Registro, por medio de bitácoras de los accesos a los equipos por parte de
personal de mantenimiento externo.
• Diagramas disponibles respecto a las fuentes de almacenamiento eléctrico
de los equipos ubicados dentro del recinto.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 413
Nivel 2:
• Recinto privado con acceso restringido.
• Puertas de seguridad para el acceso al recinto.
• Control y registro electrónico de los accesos que se realicen al recinto.
• Dispositivos de control de fuego.
• Si es necesario aires acondicionados.
• Conexión eléctrica con protección y fuentes ininterrumpidas de poder.
• Ubicación física de los equipos considerando la facilidad de manipulación
por parte de personal técnico, y alejados de fuentes posibles de riesgo:
rayos del sol en forma directa, humedad, emisiones contaminantes y calor.
Nivel 3:
Según el nivel establecido para los perímetros de seguridad, la CGR debe considerar
la incorporación de los siguientes elementos dentro de los esquemas de acceso a los
perímetros:
etc). Esta documentación deberá estar disponible para ser accedida por las
personas que se definan dentro de los esquemas de acceso al centro de
cómputo:
Para cada uno de los activos TIC considerados como críticos se tiene que contar con
un esquema de mantenimiento asociado, sea este preventivo o correctivo en donde
se identifique:
La USTI debe establecer los procedimientos que aplican para los casos en donde
los funcionarios utilicen los equipos a su cargo en sitios externos al edificio principal.
Estos procedimientos deben contemplar:
La USTI debe definir la política que aplica para equipos externos (no-propiedad de
la CGR), que requieran conectarse a la red institucional prevaleciendo el interés de
garantizar la seguridad de la información almacenada dentro de las bases de datos
institucionales.
La CGR debe contar con tecnología adecuada para el control de software o actividades
maliciosas detectadas dentro de la red de datos institucional. En este sentido el CSO
debe vigilar el entorno respecto a programas y técnicas dañinas que puedan poner en
riesgo la seguridad interna de la CGR, y aplicar las medidas necesarias para minimizar
las posibilidades de ser vulnerada.
1
Esto se define de esta manera considerando un evento en donde los sistemas y recursos tecnológicos no estén disponibles.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 419
El CSO debe definir los procedimientos para actuar ante la aparición de código
malicioso dentro de la Plataforma de TIC Institucional. Estos procedimientos deben
indicar:
Los canales utilizados para el proceso de sensibilización a los usuarios serán los que
se consideren más apropiados, contemplando al menos:
• Correo electrónico
• Charlas.
• Documentos técnicos disponibles en forma electrónica.
• intranet
420 / Normas Técnicas en Tecnologías de Información y Comunicaciones
B. En los servidores:
C. En la red:
Los encargados de las distintas áreas funcionales de la USTI, deben definir los
procedimientos de respaldo de la información almacenada tanto en los servidores
principales de la CGR como en los equipos de los usuarios finales, considerando:
Los encargados de las distintas áreas funcionales de la USTI deben establecer los
procedimientos de verificación de la funcionalidad de los respaldos. Se deben efectuar
pruebas periódicas (al menos 1 vez cada tres meses) para garantizar la integridad de
estos respaldos.
Se debe contar con tecnología que permita detectar actividad anómala sobre las redes
de comunicación de datos institucionales. Esta tecnología debe tener la capacidad de
detectar, informar y corregir, si fuera necesario cualquier tipo de ataque sobre equipos
internos de la institución.
Se debe contar con una documentación clara y fácilmente accesible sobre la topología
de la red Institucional. Esta documentación debe contener con al menos información
respecto a:
Normas Técnicas en Tecnologías de Información y Comunicaciones / 423
Toda conexión que sea establecida desde dispositivos inalámbricos hacia la red interna
de la CGR debe contemplar esquemas de autenticación, confidencialidad e integridad.
La USTI debe contar con los mecanismos necesarios para que la información que sea
puesta a disposición de los usuarios externos de la CGR, cuente con los esquemas de
seguridad necesarios contra posibles accesos indebidos.
Para los casos de registro por parte de usuarios de información sensible, se debe contar
con esquemas que garanticen la seguridad de la información transmitida (cifrado de
datos), y autenticidad del sitio (certificados digitales).
Se debe contar con tecnología adecuada para la vigilancia de los accesos y manipulación
de la información almacenada en las bases de datos institucionales (bitácoras).
Los responsables de las áreas funcionales de la USTI deben realizar, para los casos en
donde se determine (producto de la verificación de las bitácoras) las investigaciones
necesarias para cualquier incidente sobre los accesos a la información.
426 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Se deben establecer mecanismos para garantizar que los datos que sean considerados
como críticos se transfieran en forma segura a través de las redes internas de
comunicación de la CGR.
Par tal efecto se deben implementar por parte de la USTI, los mecanismos necesarios
para garantizar “no negación”, “autenticidad”, “integridad” y “confidencialidad” de la
información.
H. Control de Acceso.
Todo registro de un usuario debe ser producto de una solicitud formal en donde se
indiquen los roles y privilegios a los que este usuario tendrá acceso.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 427
Deben establecerse los mecanismos para la revisión periódica de los roles y privilegios
asignados a los usuarios y los procedimientos de revocación de estos privilegios
cuando ya no se requieran.
Se deben establecer en forma clara los privilegios de acceso a los servicios de acuerdo
con el perfil de seguridad asociado a cada usuario.
Cualquier requerimiento en TIC debe ser canalizado por las unidades solicitantes a la
USTI utilizando un esquema jerárquico:
Se debe contar con una política claramente establecida respecto al manejo que se le
deba dar a los incidentes de seguridad presentados sobre la plataforma tecnológica
de la CGR.
Los planes de continuidad del negocio deben estar soportados por un sistema de
información que permita disponer, en forma eficiente, de toda la información
relacionada con el tema de las contingencias.
432 / Normas Técnicas en Tecnologías de Información y Comunicaciones
ANEXO 1
El rol del CISO: Chief Information Security Officer
Tomado de Internet.
El informe también menciona que más empresas están optando por tener entre sus filas
el rol de CISO o Chief Information Security Officer. Si sumamos los datos enunciados
anteriormente, se puede comprender mucho mejor el porque de esta decisión ya que
viendo la seguridad de la información como proceso integral que comprende políticas,
procesos orientados al riesgo y enfocados al negocio de la empresa, se requiere que la
coordinación, planificación, organización y control de la información este en manos de
Normas Técnicas en Tecnologías de Información y Comunicaciones / 433
20.
Las amenazas actuales así como la cantidad de información que se tiene que gestionar
ha aumentado tan drásticamente que requiere de una verdadera centralización de
las decisiones que garanticen lo mejor posible la protección de la información. Estas
decisiones principalmente políticas dentro de la organización no tendrían que estar
supeditada a la disponibilidad de un área que tiene múltiples actividades asociadas
como es el área de sistemas.
Es importante entender que las actividades del CISO no son técnicas totalmente y
tienen que ser comparadas con las actividades que puede desarrollar un CEO (Chief
Executive Officer) dentro de la empresa, pero orientada a la información de la misma.
Sus conocimientos si tienen que estar al alcance de comprender cuales son las
políticas y procesos necesarios para cumplir con sus tareas.
Como antes se menciono, su contacto con el Directorio es algo muy importante a fin
de que la comunicación sea directa y que se pueda contar con el apoyo necesario.
Este tipo de organización de actores está incluyéndose actualmente como una de
las buenas prácticas de seguridad. De esta forma, el Directorio también podrá estar
permanentemente informado de los riesgos que se están incurriendo y así aplicar las
medidas adecuadas en caso de ser necesario.
El CISO podrá contar, dependiendo de lo que entienda necesario, con un equipo a cargo de
hacer cumplir las políticas y/o tercerizar la partes técnicas a empresas teniendo bajo su cargo
el cumplimiento de los objetivos que comprendan las implementaciones que se requieran.
Este tipo de relación tiene virtudes muy importantes. Primeramente, la
Normas Técnicas en Tecnologías de Información y Comunicaciones / 435
organización contará con una persona que vele por la seguridad de la información
y segundo, reducirá sus costos al tercerizar las actividades de implementación
al tiempo que podrá elegir los mejores actores para llevarlas a cabo.
Por el lado de la empresa que se haya contratado, esta contara con una persona
de contacto que tiene poder de decisión dentro de la organización así como la
información necesaria para poder realizar el trabajo en el menor tiempo posible y con
los mejores resultados dado que no perderá recursos en tratar de dilucidar cuales son
los requerimientos.
Como se vio en la lista de tareas enunciadas anteriormente, otra de las áreas que
están a cargo del CISO son las referentes a la seguridad física (control de alarmas de
incendio o robo, guardias de seguridad, cámaras, etc) dado que no solo es a través
de actividades lógicas que se puede comprometer la seguridad. Para ello podrá contar
con herramientas que le permita en todo momento conocer el estado de las distintas
dependencias de la organización al tiempo que podrá dirigir las actividades y recursos
físicos de seguridad para lograr su objetivo.
A fin de contar con toda la información requerida para cumplir con sus actividades,
se puede contar con la implementación de herramientas como los tableros de control,
que permitirán tener una visualización general de las actividades y de los incidentes
reportados. Para poder mantener esta herramienta, es necesaria una concientización
del personal a fin de que los mismos reporten las incidencias de seguridad. Por
supuesto, el personal tiene que poder ver el beneficio de este tipo de reportes ya que
si no, solo se sentirán controlados lo que originaría problemas internos al tiempo que
podría propender a tratar de saltar los controles instituidos.
Se podrá observar que el rol del CISO es de extrema importancia en las decisiones
tomadas por el directorio y que su consulta se hace necesaria para poder cumplir
con los objetivos de la empresa al tiempo que se protegen sus activos. Siendo que
el directorio o la alta gerencia no necesariamente tiene que conocer los aspectos
fundamentales de la seguridad física y lógica, el contar con un actor como el CISO,
permitirá concentrar sus esfuerzos en las actividades que permitan el crecimiento sin
comprometer a la seguridad de la organización por el simple desconocimiento.
436 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo - NTP11
Mapeo Eléctrico
438 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normas Técnicas en Tecnologías de Información y Comunicaciones / 439
Introducción
Requerimientos
Mapeo de conexiones eléctricas
Identificar y documentar las cargas que está soportando cada una de las UPS´s
que alimentan los equipos de tecnologías con el objetivo de asegurar una correcta
distribución de las mismas, evitando que las fuentes de poder redundantes de
440 / Normas Técnicas en Tecnologías de Información y Comunicaciones
un equipo estén conectados a una misma UPS, y para evitar que una UPS esté
sobrecargada con respecto a otra.
Al igual que en el Centro de Cómputo, no se tiene que permitir el acceso directo del
público o funcionarios no autorizados a los equipos. Este aseguramiento debe ser físico,
Normas Técnicas en Tecnologías de Información y Comunicaciones / 441
Control de acceso
Extintores
El o los extintores en uso tienen que estar documentados, así como el protocolo de
uso y activación, el tipo de elemento (gas u otro) utilizado para amortiguar o apagar
posibles conatos de incendio.
Alarmas
Actividades realizadas
Se realizó una revisión de conexiones eléctricas, logrando identificar los circuitos a los
cuales están conectadas las regletas de cada uno de los equipos. Esto se muestra en
la figura No.1.
Se logró identificar que las cargas de los tableros A y B están balanceadas, esto debido
a que la diferencia de las corrientes en cada fase de cada tablero de distribución es
la normal.
442 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Acciones correctivas
吀 愀戀氀攀爀漀 ⴀ䄀 吀 愀戀氀攀爀漀 ⴀ䈀
㌀ꘃ ㈀ꘃ
ⴀ䄀 ⴀ ⴀ䄀 ⴀ㈀ ⴀ䈀 ⴀ ⴀ䈀 ⴀ㤀
ⴀ䄀 ⴀ㈀ ⴀ䄀 ⴀ㌀ ⴀ䈀 ⴀ㈀ ⴀ䈀 ⴀ
ⴀ䄀 ⴀ㌀ ⴀ䄀 ⴀ㐀 ⴀ䈀 ⴀ㌀ ⴀ䈀 ⴀ
ⴀ䄀 ⴀ㐀 ⴀ䄀 ⴀ㔀 ⴀ䈀 ⴀ㐀 ⴀ䈀 ⴀ㈀
ⴀ䄀ⴀ㜀
ⴀ䄀 ⴀ㔀 ⴀ䄀 ⴀ㘀 ⴀ䈀 ⴀ㔀 ⴀ䈀 ⴀ㌀
ⴀ䈀 ⴀ
ⴀ䄀 ⴀ㘀 ⴀ䄀 ⴀ㜀 ⴀ䈀 ⴀ㘀 ⴀ䈀 ⴀ㐀 ⴀ䄀ⴀ㈀
ⴀ䄀 ⴀ㜀 ⴀ䄀 ⴀ㠀 ⴀ䈀 ⴀ㜀 ⴀ䈀 ⴀ㔀 ⴀ䄀ⴀ㐀
ⴀ䄀 ⴀ㠀 ⴀ䄀 ⴀ㤀 ⴀ䈀 ⴀ㠀 ⴀ䈀 ⴀ㘀
ⴀ䄀 ⴀ㤀 ⴀ䄀 ⴀ㈀ ⴀ䈀 ⴀ㤀
ⴀ 䄀ⴀ ⴀ䄀 ⴀ㈀ ⴀ䈀 ⴀ
ⴀ䄀 ⴀ㌀
ⴀ 䄀ⴀ ⴀ䄀 ⴀ㈀㈀
ⴀ䈀ⴀ㜀
ⴀ䈀 ⴀ㘀 ⴀ䈀ⴀ
ⴀ䈀ⴀ㠀
ⴀ䄀ⴀ㘀 ⴀ䄀ⴀ㌀ ⴀ䈀 ⴀ㘀
ⴀ䄀 ⴀ㔀
ⴀ䈀 ⴀ㤀
ⴀ䄀ⴀ ⴀ䄀ⴀ㈀ ⴀ䄀 ⴀ
ⴀ䈀ⴀ㐀
ⴀ䈀ⴀ㌀ ⴀ䈀ⴀ㈀ ⴀ䈀 ⴀ
ⴀ䈀ⴀ㐀
Distribución de salidas de c 1
吀 愀戀氀攀爀漀 ⴀ䄀 吀 愀戀氀攀爀漀 ⴀ䈀
㌀ꘃ ㈀ꘃ
ⴀ䈀 ⴀ
ⴀ䄀 ⴀ ⴀ䄀 ⴀ㈀ ⴀ䈀 ⴀ
䘀愀猀攀 䄀
䘀愀猀攀 䄀 䘀愀猀攀 䄀 䘀愀猀攀 䈀 ጠ 䘀愀猀攀 䄀
㌀⸀㤀 愀洀瀀
㌀Ⰰ㜀 愀洀瀀 ⸀㌀ 愀洀瀀 ㌀⸀㔀 愀洀瀀 ጠ ㌀⸀㠀 愀洀瀀
ⴀ䈀 ⴀ㈀
ⴀ䄀 ⴀ㈀ ⴀ䄀 ⴀ㌀ ⴀ䈀 ⴀ㈀
䘀愀猀攀 䈀
䘀愀猀攀 䈀 䘀愀猀攀 䈀 䘀愀猀攀 䈀
㐀⸀㌀ 愀洀瀀
㌀⸀㘀 愀洀瀀 ⸀ 愀洀瀀 ㌀⸀㜀 愀洀瀀
ⴀ䈀 ⴀ㌀
ⴀ䄀 ⴀ㌀ ⴀ䄀 ⴀ㐀 ⴀ䈀 ⴀ㌀
䘀愀猀攀 䄀
䘀愀猀攀 䌀 䘀愀猀攀 䌀 䘀愀猀攀 䄀
⸀㌀ 愀洀瀀
㔀⸀ 愀洀瀀 㜀⸀ 愀洀瀀 ㈀⸀㔀 愀洀瀀
ⴀ䈀 ⴀ㐀
ⴀ䄀 ⴀ㐀 ⴀ䄀 ⴀ㔀 ⴀ䈀 ⴀ㐀
䘀愀猀攀 䈀
䘀愀猀攀 䄀 䘀愀猀攀 䄀 䘀愀猀攀 䈀
㈀⸀㌀ 愀洀瀀
愀洀瀀 㜀⸀ 愀洀瀀 㘀⸀ 愀洀瀀
ⴀ䈀 ⴀ㔀
ⴀ䄀 ⴀ㔀 ⴀ䄀 ⴀ㘀 ⴀ䈀 ⴀ㔀
䘀愀猀攀 䄀
䘀愀猀攀 䈀 䘀愀猀攀 䈀 䘀愀猀攀 䄀 ጠ 䘀愀猀攀 䈀
㔀⸀㐀 愀洀瀀
愀洀瀀 ⸀㤀 愀洀瀀 ㈀⸀㐀 愀洀瀀 ጠ ⸀㘀 愀洀瀀
ⴀ䈀 ⴀ㘀 ⴀ䈀 ⴀ
ⴀ䄀 ⴀ㘀 ⴀ䄀 ⴀ㜀 ⴀ䈀 ⴀ㘀
䘀愀猀攀 䈀
䘀愀猀攀 䌀 ጠ 䘀愀猀攀 䄀 䘀愀猀攀 䌀 䘀愀猀攀 䄀
㐀⸀㐀 愀洀瀀
㈀⸀㈀ 愀洀瀀 ጠ ㈀⸀㐀 愀洀瀀 愀洀瀀 ⸀㐀 愀洀瀀
ⴀ䈀 ⴀ㜀
ⴀ䄀 ⴀ㜀 ⴀ䄀 ⴀ㠀
䘀愀猀攀 䄀
䘀愀猀攀 䈀 䘀愀猀攀 䄀 ⴀ䈀 ⴀ㜀
㈀⸀㘀 愀洀瀀
㘀⸀ 愀洀瀀 ㈀⸀ 愀洀瀀
ⴀ䈀 ⴀ㠀
ⴀ䄀 ⴀ㠀 ⴀ䄀 ⴀ㤀
䘀愀猀攀 䈀
䘀愀猀攀 䌀 䘀愀猀攀 䈀
㐀⸀㈀ 愀洀瀀 ⴀ䈀 ⴀ㠀
愀洀瀀 㐀⸀㜀 愀洀瀀
ⴀ䄀 ⴀ㈀ ⴀ䈀 ⴀ㤀
ⴀ䄀 ⴀ㤀 䘀愀猀攀 䌀 䘀愀猀攀 䄀
䘀愀猀攀 䄀 ㈀⸀㠀 愀洀瀀 ⸀㐀 愀洀瀀
㐀⸀ 愀洀瀀
ⴀ䄀 ⴀ ⴀ䄀 ⴀ㈀ ⴀ䈀 ⴀ
䘀愀猀攀 䈀 䘀愀猀攀 䄀 䘀愀猀攀 䈀 ጠ 䘀愀猀攀 䄀
䰀䤀䈀刀 䔀 愀洀瀀 ㌀⸀㌀ 愀洀瀀 ጠ ㌀⸀㜀 愀洀瀀
ⴀ䄀 ⴀ ⴀ䄀 ⴀ㈀㈀
䘀愀猀攀 䌀 䘀愀猀攀 䈀 ጠ 䘀愀猀攀 䌀
⸀㔀 愀洀瀀 㔀⸀ 愀洀瀀 ጠ 㔀⸀㔀 愀洀瀀
Figura No.2 Ubicación de los interruptores que alimentan las cargas de centro de cómputo
Normas Técnicas en Tecnologías de Información y Comunicaciones / 445
Mantenimiento correctivo
Se presentan dos vías por las cuales el/la usuario/a puede notificar la falla o el
no funcionamiento del equipo: a) llamando directamente a Mantenimiento ó b)
comunicando a la Unidad de Gestión Administrativa (UGA) el daño que presenta
en el equipo. En esta segunda opción, la UGA comunica a Mantenimiento el reporte
recibido.
Normas Técnicas en Tecnologías de Información y Comunicaciones / 447
Introducción
Este estudio se realizó utilizando una serie de consultas por medio de instrumentos
como entrevistas, encuestas y algunos talleres de trabajo, asegurando la participación
de la casi la totalidad de los funcionarios encuestados y además la opinión funcionarios
expertos en el uso de las TIC’s y con un conocimiento amplio del quehacer de esta
Contraloría General.
Instrumentos aplicados
Se aplicó una encuesta en las Divisiones DDI, DEI, DAGJ Y DCA, a todos los funcionarios
de nivel de Fiscalizador, Fiscalizador Asociado, Fiscalizador Asistente y Auxiliar
de Fiscalizador, donde se obtuvo como resultado las necesidades de capacitación
requeridos en materia de TIC’s, tanto de nivel general como específico (Ver anexo 5).
454 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Por la naturaleza de las funciones que realiza la USTI, se realizó una encuesta
específica para los funcionarios de esta Unidad, ya que sus necesidades en materia
de capacitación en TIC’s requieren conocimientos avanzados, orientados al desarrollo
de aplicaciones, gestión de bases de datos, soporte a usuarios, entre otras.
Para obtener información sobre las principales necesidades de las Jefaturas en materia
de TIC’s, se realizó una entrevista al Jefe de la USTI, quien desde su posición de experto
en la materia y además de homologo en sus labores de jefatura, nos dio sus valiosas
opiniones sobre lo consultado. Es meritorio señalar que se obtuvo información acorde
con el nivel de la población meta y totalmente alineada con la Estrategia Institucional
(Ver anexo 9).
Normas Técnicas en Tecnologías de Información y Comunicaciones / 455
Este listado de temas se sometieron al análisis del criterio experto del Jefe de la USTI, a
partir del cual, se reclasificaron o conjuntaron algunos conocimientos que pertenecían
a un mismo tema, se eliminaron otros que ya estaban incluidos en otro tema y se
eliminaron algunos temas que ya deben estar superados debido a que se ha impartido
suficiente capacitación y además se consideran como requisitos mínimos que los
funcionarios deben poseer.
Después se aplicó un criterio experto para aplicar una prioridad de 1 a 3 a todos los
temas, siendo 1 la mayor prioridad y 3 la menor, no obstante que todos los temas
incluidos en esta lista son los de mayor prioridad en la Institución y por lo tanto deben
ser incluidos en el Plan de Capacitación Continua en TIC’s.
Con base en lo anterior, es importante rescatar que existe alto porcentaje de los
funcionarios encuestados que no aplican esos comportamientos o que los aplican
en forma baja o media. Esto muestra la existencia de una brecha u oportunidad
de desarrollo para subir el nivel de aplicación y llevarlo a nivel alto, como es lo
esperado. En relación con este punto, existen varias razones que propician que los
comportamientos en análisis no se apliquen en un nivel alto, algunas veces se aduce
falta de conocimiento, dificultad para llevar a la práctica los conocimientos que poseen,
por falta de iniciativa y algunas veces se da que luego de la capacitación, se le asignan
otros trabajos en los que no se presenta la oportunidad de aplicar lo aprendido en el
corto plazo lo que provoca algunas veces que los conocimientos se desactualicen o
se olviden. Sin embargo, por el momento, con el presente estudio, se espera que
se desarrolle un Plan de Capacitación Continua en TIC’s que coadyuve al desarrollo
de los conocimientos en la materia, así como generar la motivación suficiente para
facilitar que los puedan llevar a la práctica en sus labores.
Luego del análisis de la información que fue comentada en párrafos anteriores, como
resultado final se presentan a continuación los temas que forman parte del plan de
capacitación continua en TIC’s para la Contraloría General de la República, los cuales
serán una guía para la planificación e implementación de los planes anuales de
capacitación en dicha materia, del 2009 al 2012.
Técnico-Secretarial
Administrativos
Fiscalizadores
TEMAS PARA EL PLAN DE CAPACITACION
CONTINUA EN TIC’s
Prioridad
Jefaturas
SOFTWARE APLICATIVO
Elaboración de Presentaciones, manejo y edición de
1 X X X
imágenes, fotografías, video y audio, cambio de formato
Manejo de Proyectos 2 X X
Software para la creación de flujos de procesos 2 X
Cartografía 3 X
Estadística 2 X
Mapas Mentales 3 X X
Manejo de GPS 3 X X
HERRAMIENTAS Y UTILITARIOS: el conocimiento para el uso
de este tipo de herramientas puede lograrse mediante la
utilización de guías virtuales
Investigación en la Web, uso de buscadores, diccionarios y
3 X X
traductores
Reuniones virtuales y chat, mensajería unificada 3 X X X
Seguridad de la información, compresión y empaquetamiento
2 X X X
de archivos
CICLO DE CHARLAS SOBRE NORMATIVA, PLANEACIÓN,
MODELOS DE GESTIÓN Y CONTROL DE TIC’s
Normas técnicas para gestión y control de TIC’s 1 X X
Plan Estratégico en Tecnologías de Información y
1 X X
Comunicación (PETIC)
Normas Técnicas en Tecnologías de Información y Comunicaciones / 459
Técnico-Secretarial
Administrativos
Fiscalizadores
TEMAS PARA EL PLAN DE CAPACITACION
CONTINUA EN TIC’s
Prioridad
Jefaturas
Plan Táctico (PETAC) 1 X X
Modelo de Arquitectura de Información (MAI) 1 X X
Proceso de valoración del Riesgo (SEVRI y riesgos en TI) 1 X X
COSO (Committee of Sponsoring Organizations of the
1 X X
Treadway Commission)
COBIT (Control objectives for Information and related
1 X X
Technology)
ITIL (Information Technology Infrastructure Library) 1 X X
CONOCIMIENTOS GENERALES DE TI APLICABLES A
CUALQUIER TIPO DE FISCALIZACIÓN
Modelado de Datos 1 X
Extracción y análisis de datos con Excel 1 X X
Extracción y análisis de datos con ACL O IDEA 1 X
Pruebas de auditoría sobre procesos de e información
1 X
electrónica y recopilación de evidencia
CONOCIMIENTOS ESPECÍFICOS DE TIC’s APLICABLES
EN FISCALIZACION DE GESTION Y CONTROL DE LAS
TIC’s: Dirigido específicamente a los funcionarios del
Macroproyecto de TIC’s de la FOE, similar a la Maestría
sobre Auditoría de TI de la UCR.
Conceptos fundamentales de auditoría aplicables a la
1 X
fiscalización de TI
Proceso de auditoría operativa y su aplicabilidad a la
1 X
evaluación de la gestión y control de las TI
Modelos de gestión y control con TI 1 X
En qué consiste un sistema de gestión de calidad para los
1 X
procesos de TI (importancia de la emisión de políticas)
El proceso de valoración de riesgos según la normativa del
SEVRI y la vinculación que tiene con éste la valoración de 1 X
riesgos en TI.
Normas ISO 27001 e ISO 27002 y su aplicación a la Gestión
1 X
de TI
Administración de Proyectos (PMI y PMBoK) 1 X
460 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Técnico-Secretarial
Administrativos
Fiscalizadores
TEMAS PARA EL PLAN DE CAPACITACION
CONTINUA EN TIC’s
Prioridad
Jefaturas
Marco jurídico relacionado con las TI (Importancia y
1 X
seguimiento)
Planificación estratégica de TI 1 X
Modelo de Arquitectura de Información y de infraestructura
1 X
tecnológica
Desarrollo e implementación de sistemas de información
(conceptos claves: o aplicaciones entiendo los siguientes
1 X
conceptos: teorías, etapas del CVDS, CMMi, Casos de uso,
capas, objetos, etc.
Administración de la tercerización de TI 1 X
Plataforma Tecnológica (Operaciones, Telecomunicaciones,
1 X
Seguridad, Base de Datos, otros)
Conceptos sobre administración de datos 1 X
CICLO DE CHARLAS SOBRE LOS SISTEMAS
INSTITUCIONALES: Corresponde a charlas sobre todos los
X X X X
sistemas Institucionales, como aprovecharlos al máximo,
utilizando la información
CICLO DE CHARLAS SOBRE TI PARA LOS NIVELES DE
JEFATURA: Difundir todos los recursos que en materia de
TI posee la Institución y como puede sacar provecho de
ellos
Modelo de Arquitectura de la Información (MAI) y su relación
1 X
con los procesos Institucionales definidos en el MAGEFI
Infraestructura Tecnológica (Redes, Telefonía, Bases de
1 X
Datos, Seguridad, Servidores)
Metodología de Gestión de Proyectos de TI 1 X
Herramientas de Software disponibles y su utilidad 1 X
Aprovechamiento de la Información para la toma de
1 X
decisiones
Rol del usuario en la Metodología de Desarrollo de Sistemas 1 X
MAESTRÍAS
Maestría en Computación del TEC 2 X
Normas Técnicas en Tecnologías de Información y Comunicaciones / 461
Técnico-Secretarial
Administrativos
Fiscalizadores
TEMAS PARA EL PLAN DE CAPACITACION
CONTINUA EN TIC’s
Prioridad
Jefaturas
Maestría Profesional en Auditoría de Tecnologías de la
2 X
Información
CERTIFICACIONES 1
Certified Information Systems Auditor (CISA) Certificación
para auditores respaldada por la Asociación ISACA 1 X
(Information Systems Audit and Control Association).
Certificación en Gobierno de Tecnologías de la Información
en Empresas, Governance of Enterprise IT Certification
(CGEIT), creada por ISACA para apoyar las demandas
1 X
crecientes relacionadas con el gobierno de TI, promover
la buena práctica del mismo y reconocer profesionistas
talentosos en el área
CISM (Certified Information Security Management) es
una certificación para administradores de seguridad de la
información respaldada por la ISACA. Está enfocada en la
gerencia y define los principales estándares de competencias
1 X
y desarrollo profesionales que un director de seguridad de
la información debe poseer, competencias necesarias para
dirigir, diseñar, revisar y asesorar un programa de seguridad
de la información.
462 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Técnico-Secretarial
Administrativos
Fiscalizadores
TEMAS PARA EL PLAN DE CAPACITACION
CONTINUA EN TIC’s
Prioridad
Jefaturas
Certificación ISO/IEC 27000 son estándares de seguridad
publicados por la Organización Internacional para la
Estandarización (ISO) y la Comisión Electrotécnica
Internacional (IEC). La serie contiene las mejores prácticas
1 X
recomendadas en Seguridad de la información para
desarrollar, implementar y mantener Especificaciones para
los Sistemas de Gestión de la Seguridad de la Información
(SGSI).
Certificación en La Biblioteca de Infraestructura de
Tecnologías de Información, ITIL (del inglés Information
Technology Infrastructure Library), es un marco de trabajo
de las mejores prácticas destinadas a facilitar la entrega de
1 X
servicios de tecnologías de la información (TI). ITIL resume
un extenso conjunto de procedimientos de gestión ideados
para ayudar a las organizaciones a lograr calidad y eficiencia
en las operaciones de TI.
Certificación en Administración de Proyectos (PMI) 2 X
Certificación en Administración de Bases de Datos ORACLE 2 X
Certificación en Desarrollo bajo la herramienta ORACLE 1 X
Certificación en Administración de Servidores de Microsoft 1 X
Certificación en redes para transmisión (Voz, datos, vídeo) 1 X
TEMAS ESPECÍFICOS PARA LA USTI
Casos Uso y Prueba (Metodologías) 1 X
XML / Webservises 1 X
JAVA / SQL/QUERY / HTML / XHTML / PHP / JAVA SCRIPT
1 X
/ CSS
ORACLE (Herramientas de Desarrollo/Bases de Datos) 1 X
Datawarehouse 1 X
Seguridad en TIC’s 1 X
Adm. de Redes 1 X
ATM Telefonía 1 X
Sistemas operativo/soft Usuario Final 1 X
Normas Técnicas en Tecnologías de Información y Comunicaciones / 463
Técnico-Secretarial
Administrativos
Fiscalizadores
TEMAS PARA EL PLAN DE CAPACITACION
CONTINUA EN TIC’s
Prioridad
Jefaturas
Adm. de Proyectos 2 X
Gestión de TIC’s 2 X
Gestión Calidad en TIC’s 2 X
Elementos de diseño de sitios Web 1 X
464 / Normas Técnicas en Tecnologías de Información y Comunicaciones
RECOMENDACIONES
El presente Plan de Capacitación Continua en TIC’s tiene una vigencia del 2009 al
2012, por lo que requiere de una implementación paulatina en los diferentes planes
anuales de capacitación, esto permitirá que la inversión en tiempo de los participantes
y en el costo de los eventos quede prorrateada en los respectivos Planes Operativos y
Presupuestos Anuales de la Institución.
Se deberán revisar los perfiles de puestos, para asegurar que contienen los
conocimientos necesarios en materia de TIC’s, de forma que se complementen
con las competencias que sobre ésta materia han sido emitidos por la Unidad de
Recursos Humanos. Esto impulsará con mayor claridad, la búsqueda del desarrollo
de los funcionarios para dotarlos de los conocimientos, habilidades y destrezas que
los faculten para el ejercicio eficaz y eficiente de las funciones que les corresponde
ejecutar en este Órgano Contralor.
ANEXOS
ANEXO 1
Porcentaje de aplicación de conocimientos de tipo general en materia
de TIC’s
匀 漀昀琀眀愀爀攀 瀀愀爀愀 氀愀 挀 爀攀愀挀 椀渀 搀攀 攀猀 焀甀攀洀愀猀 漀 洀愀瀀愀猀 挀 漀渀挀 攀瀀琀甀愀氀攀猀 ㌀㘀Ⰰ㜀─ ㈀㤀Ⰰ ─ 㘀㔀Ⰰ㜀─ ㈀Ⰰ㜀─ 㠀㜀Ⰰ㐀─
匀 漀昀琀眀愀爀攀 瀀愀爀愀 挀 爀攀愀挀 椀渀 搀攀 戀愀猀 攀猀 搀攀 搀愀琀漀猀 㐀㠀Ⰰ㌀─ ㌀ Ⰰ㐀─ 㜀㠀Ⰰ㜀─ 㔀Ⰰ ─ 㤀㌀Ⰰ㜀─
匀 漀昀琀眀愀爀攀 瀀愀爀愀 氀愀 挀 爀攀愀挀 椀渀 搀攀 昀氀甀樀漀猀 搀攀 瀀爀漀挀 攀猀 漀猀 㐀㘀Ⰰ㤀─ ㈀㤀Ⰰ ─ 㜀㔀Ⰰ㤀─ 㜀Ⰰ㔀─ 㤀㌀Ⰰ㐀─
匀 漀昀琀眀愀爀攀 瀀愀爀愀 氀愀 挀 漀洀瀀爀攀猀 椀渀 搀攀 愀爀挀 栀椀瘀漀猀 㐀㌀Ⰰ ─ ㈀㌀Ⰰ─ 㘀㘀Ⰰ─ 㜀Ⰰ─ 㠀㌀Ⰰ㈀─
匀 漀昀琀眀愀爀攀 礀 攀焀甀椀瀀漀 瀀愀爀愀 爀攀猀 瀀愀氀搀漀 搀攀 椀渀昀漀爀洀愀挀 椀渀 ⠀焀甀攀洀愀搀漀 搀攀
搀愀琀漀猀 ⤀ ㈀㌀Ⰰ㐀─ ㈀㜀Ⰰ㘀─ 㔀Ⰰ ─ ㈀㐀Ⰰ㔀─ 㜀㔀Ⰰ㔀─
匀 漀昀琀眀愀爀攀 礀 攀焀甀椀瀀漀 瀀愀爀愀 攀猀 挀 愀渀攀漀 搀攀 椀洀最攀渀攀猀 礀 琀攀砀琀漀 ㈀㘀Ⰰ㤀─ ㈀㜀Ⰰ㘀─ 㔀㐀Ⰰ㔀─ ㈀㈀Ⰰ㜀─ 㜀㜀Ⰰ㌀─
匀 漀昀琀眀愀爀攀 礀 攀焀甀椀瀀漀 瀀愀爀愀 氀愀 最爀愀戀愀挀 椀渀 礀 攀搀椀挀 椀渀 搀攀 愀甀搀椀漀 ㌀㔀Ⰰ ─ ㈀㤀Ⰰ ─ 㘀㐀Ⰰ ─ 㠀Ⰰ㤀─ 㠀㈀Ⰰ㤀─
匀 漀昀琀眀愀爀攀 礀 攀焀甀椀瀀漀 瀀愀爀愀 琀漀洀愀爀 礀 攀搀椀琀愀爀 昀漀琀漀最爀愀昀愀猀 ㈀㤀Ⰰ㐀─ ㈀㠀Ⰰ㌀─ 㔀㜀Ⰰ㜀─ ㈀㈀Ⰰ㐀─ 㠀 Ⰰ─
匀 漀昀琀眀愀爀攀 礀 攀焀甀椀瀀漀 瀀愀爀愀 最爀愀戀愀挀 椀渀 礀 攀搀椀挀 椀渀 搀攀 瘀椀搀攀漀 㐀㌀Ⰰ㐀─ ㈀㐀Ⰰ㠀─ 㘀㠀Ⰰ㈀─ 㤀Ⰰ㤀─ 㠀㠀Ⰰ─
匀 漀昀琀眀愀爀攀 搀攀 挀 漀爀爀攀漀 攀氀攀挀 琀爀渀椀挀 漀 㔀Ⰰ㤀─ Ⰰ㈀─ 㜀Ⰰ─ ㌀Ⰰ㠀─ 㐀㤀Ⰰ ─
匀 漀昀琀眀愀爀攀 礀 攀焀甀椀瀀漀 瀀愀爀愀 氀愀 爀攀洀椀猀 椀渀 搀攀 昀愀砀 ㈀Ⰰ㌀─ ㈀㈀Ⰰ ─ 㐀㌀Ⰰ㐀─ ㈀㜀Ⰰ㘀─ 㜀Ⰰ ─
䤀渀瘀攀猀 琀椀最愀挀 椀渀 攀渀 䤀渀琀攀爀渀攀琀 㐀Ⰰ㈀─ Ⰰ㈀─ 㔀Ⰰ㐀─ ㌀ Ⰰ㐀─ 㐀㔀Ⰰ㠀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 瀀愀爀愀 挀 漀渀琀爀漀氀 搀攀 琀爀愀戀愀樀漀 ⠀匀 䤀䜀 夀 䐀⤀ Ⰰ㐀─ 㤀Ⰰ㠀─ Ⰰ㈀─ ㌀㐀Ⰰ㘀─ 㐀㔀Ⰰ㠀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 䴀搀甀氀漀 搀攀 琀漀洀愀 搀攀 搀攀挀 椀猀 椀漀渀攀猀 ⠀䴀吀 䐀⤀ ㈀Ⰰ─ 㘀Ⰰ㘀─ 㠀Ⰰ㜀─ ㌀㔀Ⰰ㌀─ 㐀㐀Ⰰ─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 瀀愀爀愀 猀 攀最甀椀洀椀攀渀琀漀 搀攀 搀椀猀 瀀漀猀 椀挀 椀漀渀攀猀 ㌀ Ⰰ㐀─ ㌀Ⰰ㠀─ 㘀㈀Ⰰ㈀─ ㈀㔀Ⰰ㈀─ 㠀㜀Ⰰ㐀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 瀀愀爀愀 氀愀 愀挀 琀椀瘀椀搀愀搀 挀 漀渀琀爀愀挀 琀甀愀氀 搀攀 氀愀
愀搀洀椀渀椀猀 琀爀愀挀 椀渀 瀀切戀氀椀挀 愀 ⠀匀 䤀䄀䌀 ⤀ ㈀㘀Ⰰ㈀─ 㐀㔀Ⰰ㔀─ 㜀Ⰰ㜀─ ㈀Ⰰ ─ 㤀㈀Ⰰ㜀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 搀攀 瀀爀攀猀 甀瀀甀攀猀 琀漀猀 瀀切戀氀椀挀 漀猀 搀攀 氀愀
愀搀洀椀渀椀猀 琀爀愀挀 椀渀 瀀切戀氀椀挀 愀 ⠀匀 䤀倀 倀 ⤀ ㌀ Ⰰ─ ㌀㈀Ⰰ㔀─ 㘀㈀Ⰰ㘀─ ㈀ Ⰰ㘀─ 㠀㌀Ⰰ㈀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 搀攀 渀漀爀洀愀琀椀瘀愀 瀀愀爀愀 氀愀 昀椀猀 挀 愀氀椀稀愀挀 椀渀 㤀Ⰰ─ ㈀㐀Ⰰ㔀─ ㌀㌀Ⰰ㘀─ 㐀 Ⰰ㤀─ 㜀㐀Ⰰ㔀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 搀攀 愀爀挀 栀椀瘀漀 搀椀最椀琀愀氀 ⠀匀 䄀䐀⤀ ㈀㔀Ⰰ㤀─ ㈀㤀Ⰰ ─ 㔀㐀Ⰰ㤀─ ㈀㘀Ⰰ㘀─ 㠀Ⰰ㔀─
匀 椀猀 琀攀洀愀 椀渀猀 琀椀琀甀挀 椀漀渀愀氀 瀀愀爀愀 氀愀 爀攀挀 攀瀀挀 椀渀 搀攀 䐀攀挀 氀愀爀愀挀 椀漀渀攀猀
䨀 甀爀愀搀愀猀 㔀 Ⰰ㌀─ ㈀㠀Ⰰ㜀─ 㜀㤀Ⰰ ─ Ⰰ㠀─ 㠀㤀Ⰰ㤀─
468 / Normas Técnicas en Tecnologías de Información y Comunicaciones
ANEXO 2
Resumen de Conocimientos Generales de TIC’s aplicables a cualquier
fiscalización y Específicos para la Fiscalización de la Gestión y Control
de las TIC’s.
⸀ ꀀꀀꀀꀀ 䔀 渀琀椀攀渀搀漀 氀愀 椀洀瀀漀爀 琀愀渀挀椀愀 搀攀 焀甀攀 氀愀 漀爀 最愀渀椀稀愀挀椀渀 挀甀攀渀琀攀 挀漀渀 甀渀 瀀爀 漀挀攀猀漀 搀攀 㜀Ⰰ ─ ㈀㤀Ⰰ ─
猀攀最甀椀洀椀攀渀琀漀 搀攀氀 洀愀爀 挀漀 樀甀爀 搀椀挀漀 焀甀攀 愀昀攀挀琀愀 氀愀 最攀猀琀椀渀 搀攀 氀愀猀 吀 䤀 ⸀
㈀⸀ ꀀꀀꀀꀀ 匀漀戀爀 攀 攀氀 洀愀爀 挀漀 樀甀爀 搀椀挀漀 爀 攀氀愀挀椀漀渀愀搀漀 挀漀渀 氀愀猀 吀 䤀 挀漀渀漀稀挀漀Ⰰ 攀渀 琀爀 洀椀渀漀猀 㐀㤀Ⰰ ─ 㔀Ⰰ ─
最攀渀攀爀 愀氀攀猀Ⰰ 氀漀 猀攀愀氀愀搀漀 瀀漀爀 氀愀 猀椀最甀椀攀渀琀攀 渀漀爀 洀愀琀椀瘀愀 爀 攀猀瀀攀挀琀漀 愀 搀椀挀栀愀 洀愀琀攀爀 椀愀㨀
㌀⸀ ꀀꀀꀀꀀ 匀漀戀爀 攀 氀愀 瀀氀愀渀椀昀椀挀愀挀椀渀 攀猀琀爀 愀琀最椀挀愀 搀攀 吀 䤀 挀漀渀漀稀挀漀㨀 ㈀Ⰰ㔀─ 㜀㠀Ⰰ㔀─
㐀⸀ ꀀꀀꀀꀀ 匀攀 焀甀 攀猀 甀渀 䴀 䄀 䤀 礀 攀渀琀椀攀渀搀漀 氀愀 椀洀瀀漀爀 琀愀渀挀椀愀 搀攀 焀甀攀 琀漀搀愀 漀爀 最愀渀椀稀愀挀椀渀 挀甀攀渀琀攀 㠀Ⰰ㈀─ 㠀Ⰰ㠀─
挀漀渀 猀甀 洀漀搀攀氀漀 搀攀 椀渀昀漀爀 洀愀挀椀渀 愀挀琀甀愀氀椀稀愀搀漀⸀
㔀⸀ ꀀꀀꀀꀀ 䔀 渀琀椀攀渀搀漀 氀愀 椀洀瀀漀爀 琀愀渀挀椀愀 搀攀 焀甀攀 氀愀猀 漀爀 最愀渀椀稀愀挀椀漀渀攀猀 挀甀攀渀琀攀渀 挀漀渀 甀渀愀 㔀㠀Ⰰ ─ 㐀㈀Ⰰ ─
搀攀猀挀爀 椀瀀挀椀渀 最爀 昀椀挀愀 搀攀 猀甀 椀渀昀爀 愀攀猀琀爀 甀挀琀甀爀 愀 琀攀挀渀漀氀最椀挀愀⸀
㘀⸀ ꀀꀀ 䌀 漀渀漀稀挀漀 氀愀 爀 愀稀渀 瀀漀爀 氀愀 挀甀愀氀 琀愀渀琀漀 攀氀 洀漀搀攀氀漀 搀攀 椀渀昀漀爀 洀愀挀椀渀 挀漀洀漀 搀攀 ㌀㤀Ⰰ㈀─ 㘀 Ⰰ㠀─
椀渀昀爀 愀攀猀琀爀 甀挀琀甀爀 愀 琀攀挀渀漀氀最椀挀愀 挀漀渀猀琀椀琀甀礀攀渀 椀渀猀甀洀漀猀 搀攀 氀愀 瀀氀愀渀椀昀椀挀愀挀椀渀 搀攀 氀愀猀 吀 䤀 ⸀
㜀⸀ ꀀꀀ 䔀 渀琀椀攀渀搀漀 攀氀 挀漀渀挀攀瀀琀漀 搀攀 ᰠ 椀渀搀攀瀀攀渀搀攀渀挀椀愀ᴠ 挀甀愀渀搀漀 攀猀琀攀 猀攀 愀瀀氀椀挀愀 愀 氀愀 昀甀渀挀椀渀 搀攀 㐀 Ⰰ㈀─ 㔀㤀Ⰰ㠀─
吀 䤀 挀漀渀 爀 攀猀瀀攀挀琀漀 愀氀 爀 攀猀琀漀 搀攀 氀愀 漀爀 最愀渀椀稀愀挀椀渀⸀
㠀⸀ ꀀꀀꀀꀀ 䌀 甀渀搀漀 猀攀 栀愀戀氀愀 搀攀氀 搀攀猀愀爀 爀 漀氀氀漀 漀 搀攀 氀愀 椀洀瀀氀攀洀攀渀琀愀挀椀渀 搀攀 猀椀猀琀攀洀愀猀 搀攀 㤀Ⰰ㔀─ 㠀 Ⰰ㔀─
椀渀昀漀爀 洀愀挀椀渀 漀 愀瀀氀椀挀愀挀椀漀渀攀猀 攀渀琀椀攀渀搀漀 氀漀猀 猀椀最甀椀攀渀琀攀猀 挀漀渀挀攀瀀琀漀猀㨀
㤀⸀ ꀀꀀꀀꀀ 䔀 渀琀椀攀渀搀漀 氀愀 椀洀瀀漀爀 琀愀渀挀椀愀 搀攀 攀猀琀愀戀氀攀挀攀爀 挀漀渀琀爀 漀氀攀猀 挀甀愀渀搀漀 猀攀 挀漀渀琀爀 愀琀愀 愀 琀攀爀 挀攀爀 漀猀 㜀㜀Ⰰ㘀─ ㈀㈀Ⰰ㐀─
瀀愀爀 愀 椀洀瀀氀攀洀攀渀琀愀爀 猀椀猀琀攀洀愀猀 攀渀 氀愀 漀爀 最愀渀椀稀愀挀椀渀⸀
㈀ ⸀ ꀀꀀꀀꀀ 䌀 漀渀 爀 攀猀瀀攀挀琀漀 愀 氀漀 愀渀琀攀爀 椀漀爀 Ⰰ 攀渀琀椀攀渀搀漀 氀愀 椀洀瀀漀爀 琀愀渀挀椀愀 搀攀㨀 㘀㌀Ⰰ㔀─ ㌀㘀Ⰰ㔀─
㈀⸀ ꀀꀀꀀꀀ 䌀 漀渀漀稀挀漀 氀漀猀 猀椀最甀椀攀渀琀攀猀 挀漀渀挀攀瀀琀漀猀 爀 攀氀愀挀椀漀渀愀搀漀猀 挀漀渀 瀀氀愀琀愀昀漀爀 洀愀 琀攀挀渀漀氀最椀挀愀㨀 ㌀㌀Ⰰ─ 㘀㘀Ⰰ㤀─
㈀㈀⸀ ꀀꀀꀀꀀ 匀漀戀爀 攀 氀愀 愀搀洀椀渀椀猀琀爀 愀挀椀渀 搀攀 搀愀琀漀猀 攀渀琀椀攀渀搀漀 愀 氀漀 焀甀攀 猀攀 爀 攀昀椀攀爀 攀渀 氀漀猀 猀椀最甀椀攀渀琀攀猀 ㌀㜀Ⰰ㐀─ 㘀㈀Ⰰ㘀─
挀漀渀挀攀瀀琀漀猀㨀
㈀㌀⸀ ꀀꀀꀀꀀ 䔀 渀琀椀攀渀搀漀 氀愀 愀瀀氀椀挀愀挀椀渀 搀攀 栀攀爀 爀 愀洀椀攀渀琀愀猀 挀漀洀漀 攀氀 䈀 匀䌀 攀渀 氀愀 攀瘀愀氀甀愀挀椀渀 搀攀氀 Ⰰ─ 㠀㤀Ⰰ㤀─
搀攀猀攀洀瀀攀漀⸀
Normas Técnicas en Tecnologías de Información y Comunicaciones / 469
ANEXO 3
MACROPROYECTO DE FISCALIZACIÓN DE LA GESTIÓN DE LAS TIC’S
FUNCIONARIO PARTICIPANTES POR ÁREA DE FISCALIZACIÓN
䴀 䄀 䌀 刀 伀倀刀 伀夀 䔀 䌀 吀 伀 䐀䔀 䘀 䤀 匀䌀 䄀 䰀 䤀 娀 䄀 䌀 䤀 팀一 䐀䔀 䰀 䄀 䜀 䔀 匀吀 䤀 팀一 䐀䔀 䰀 䄀 匀 吀 䤀 䌀 猀
ANEXO 4
Nivel de aplicación del comportamiento o competencia
ANEXO 5
Grado de Conocimientos sobre TIC’s
ANEXO 5 (Continuación)
Grado de Conocimientos sobre TIC’s
ANEXO 6
Nivel de aplicación del comportamiento o competencia
䰀 伀䜀 刀 伀 䐀䔀 䠀愀戀椀氀椀搀愀搀 瀀愀爀愀 琀爀愀戀愀樀愀爀 挀 漀渀 愀甀琀漀渀漀洀愀 攀 椀洀瀀愀爀挀 椀愀氀椀搀愀搀 ㈀Ⰰ㐀─ ㌀Ⰰ㈀─ 㔀Ⰰ㘀─ ㈀Ⰰ㐀─ ㈀㜀Ⰰ ─
刀 䔀 匀 唀䰀 吀 䄀䐀伀匀 䰀 漀最爀愀 焀甀攀 猀 甀 瀀爀漀搀甀挀 挀 椀渀 礀 氀愀 搀攀氀 攀焀甀椀瀀漀 琀攀渀最愀 漀爀搀攀渀Ⰰ
挀 愀氀椀搀愀搀Ⰰ 瀀爀攀挀 椀猀 椀渀 礀 爀椀最甀爀漀猀 椀搀愀搀 㘀Ⰰ㌀─ ㈀Ⰰ㐀─ 㠀Ⰰ㜀─ ㌀㈀Ⰰ㔀─ 㐀Ⰰ㌀─
䄀猀 椀洀椀氀愀 攀 椀渀挀 漀爀瀀漀爀愀 昀挀 椀氀洀攀渀琀攀 氀愀 愀瀀氀椀挀 愀挀 椀渀 搀攀 渀甀攀瘀愀猀
匀 漀戀爀攀 吀 䤀
吀 䤀䌀 ✀猀 攀渀 氀漀猀 琀爀愀戀愀樀漀猀 㐀Ⰰ㠀─ 㠀Ⰰ㜀─ ㌀Ⰰ㔀─ ㌀㐀Ⰰ㤀─ 㐀㠀Ⰰ㐀─
䤀一一伀嘀 䄀䌀 䤀팀一
䄀挀 琀甀愀氀椀稀愀 猀 甀猀 挀 漀渀漀挀 椀洀椀攀渀琀漀猀 攀渀 琀攀洀愀猀 搀攀 椀渀琀攀爀猀 瀀愀爀愀 氀愀
䤀渀猀 琀椀琀甀挀 椀渀 礀 攀渀 攀氀 甀猀 漀 搀攀 吀 䤀䌀 ✀猀 ㈀Ⰰ㐀─ Ⰰ㤀─ 㐀Ⰰ㌀─ 㐀㈀Ⰰ─ 㔀㘀Ⰰ㌀─ 匀 漀戀爀攀 吀 䤀
䴀愀渀琀椀攀渀攀 甀渀 戀甀攀渀 搀攀猀 攀洀瀀攀漀 愀切渀 攀渀 猀 椀琀甀愀挀 椀漀渀攀猀 搀攀
洀甀挀 栀愀 瀀爀攀猀 椀渀 ㈀Ⰰ㐀─ ㈀Ⰰ㐀─ 㐀Ⰰ㠀─ ㈀㠀Ⰰ㘀─ ㌀㌀Ⰰ㌀─
䄀唀吀 伀䌀 伀一吀 刀 伀䰀 刀 攀挀 漀渀漀挀 攀 昀漀爀琀愀氀攀稀愀猀 Ⰰ 椀搀攀渀琀椀昀椀挀 愀 猀 甀猀 攀爀爀漀爀攀猀 礀 氀椀洀椀琀愀挀 椀漀渀攀猀 礀
琀漀洀愀 愀挀 挀 椀漀渀攀猀 瀀愀爀愀 洀攀樀漀爀愀爀 Ⰰ㘀─ ㈀Ⰰ㐀─ 㐀Ⰰ ─ ㌀㈀Ⰰ㔀─ ㌀㘀Ⰰ㔀─
474 / Normas Técnicas en Tecnologías de Información y Comunicaciones
ANEXO 7
Grado de Conocimientos sobre TIC’s
ANEXO 8
Nivel de aplicación del comportamiento o competencia
ANEXO 9
Conocimientos que deben tener las Jefaturas sobre las TIC’s
Según entrevista realizada a la Jefatura de USTI
ANEXO 10
Conocimientos que deben tener las Secretarias en materia de TIC’s
Según entrevista realizada a las secretarias del Despacho, la secretaria
de División de la DFOE, de la Secretaría Técnica y de la USTI
匀 䤀匀 吀 䔀 䴀䄀匀
匀 䤀䄀䌀
一伀刀 䴀䄀吀 䤀嘀 䄀
匀 䤀匀 吀 䔀 䴀䄀 䤀一䘀 伀刀 䴀䄀䌀 䤀팀一 䰀䔀 䜀 䤀匀 䰀䄀吀 䤀嘀 伀
䔀 堀倀 䔀 䐀䤀䔀 一吀 䔀 䐀䤀䜀 䤀吀 䄀䰀
䌀 伀䴀倀 刀 䄀匀
䌀 伀䴀倀 䔀 一䐀䤀伀匀
匀 䤀䜀 夀 䐀
匀 椀猀 琀攀洀愀猀 搀攀 挀氀愀瘀攀猀
䌀 漀渀昀椀最甀爀愀挀椀渀 攀 椀渀猀 琀愀氀愀挀椀渀 搀攀 椀洀瀀爀攀猀 漀爀愀猀
匀 椀猀 琀攀洀愀猀 瀀愀爀愀 昀甀渀挀椀漀渀愀爀椀漀猀
䐀漀挀甀洀攀渀琀愀挀椀渀 礀 匀 攀爀瘀椀挀椀漀猀 搀攀 氀愀 圀 攀戀
la USTI
搀 猀 吀䐀 礀 愀猀
愀 猀 猀
搀漀 猀 漀猀 猀琀
ANEXO 11
唀渀椀搀愀搀攀猀 䘀 甀渀挀 椀漀渀愀氀攀猀 䌀 愀搀 椀搀 漀 漀 琀漀 ⴀ䴀 攀猀 琀椀瘀
椀搀 椀瘀 氀椀挀 氀椀挀 渀愀 攀 渀 猀 渀 猀 爀 愀 挀 甀攀
椀瘀 挀琀 椀漀 挀 攀 渀 攀 猀 攀 漀 琀
㴀 䌀 伀一匀 唀䰀 吀 䄀 䄀 挀琀 䄀 切戀 切戀
渀挀 搀椀 洀 椀漀 椀漀 䈀椀 椀挀 椀猀 攀渀
䐀䤀嘀 䤀匀 䤀伀一䔀 匀 倀 攀 倀 爀愀 ⠀촀渀 挀甀 椀猀 椀挀 琀 椀渀
刀 㴀 刀 䔀 䜀 䤀匀 吀 刀 伀 氀愀 氀 氀愀 氀 漀猀 戀爀 漀猀 匀愀 爀瘀 搀攀 猀 嘀椀 搀攀
猀琀 攀 瀀愀 渀 ⤀ 䐀 漀 搀攀挀 匀攀 渀 樀漀 攀 䄀 搀洀 渀
一㴀 一漀 爀攀焀甀椀攀爀攀渀 䌀 愀瀀愀挀 ⸀ 搀攀 琀甀愀 搀攀 琀甀愀 攀 猀 漀 攀猀 琀 搀 愀 椀 漀 礀 攀 椀 猀 䘀 椀 搀 椀
甀 攀 猀 瀀甀 椀瘀 挀 爀椀 搀攀 椀挀 猀 愀挀
琀爀漀 挀 攀猀 愀 挀
甀瀀 琀爀漀 愀 琀 稀 愀 琀愀 渀 䐀 愀 氀搀 椀猀 椀挀 椀漀 漀猀 椀琀攀 椀琀攀 漀爀
椀猀 琀爀愀 爀洀 琀爀 爀洀 猀 甀 椀猀 洀 愀 氀椀 攀 琀椀 夀 洀 爀琀愀 焀甀 爀瘀 琀椀瘀
攀 最 漀渀 昀漀 漀渀 攀猀 昀漀 攀 攀最 漀爀 挀 愀 挀 攀 猀 䜀 洀 洀 愀戀
刀 䌀 䤀渀 䌀 倀爀 䤀渀 倀 爀 刀 一 昀椀猀 䜀 䜀 匀 䤀 吀漀 倀漀 䄀搀 匀 攀 䄀挀 吀爀 吀爀 䔀氀
倀 爀椀漀爀⸀ 䄀 䄀 䄀 䄀 䄀 䄀 䌀 䌀 䄀 䌀 䌀 䈀 䌀 䈀
匀 攀挀 爀攀琀愀爀愀 吀 挀 渀椀挀 愀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 攀爀瘀椀挀 椀漀猀 搀攀 䄀搀洀椀渀椀猀 琀爀愀挀 椀渀
䘀 椀渀愀渀挀 椀攀爀愀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 攀爀瘀椀挀 椀漀猀 䴀甀渀椀挀 椀瀀愀氀攀猀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 攀爀瘀椀挀 椀漀猀 䔀 挀 漀渀洀椀挀 漀猀 瀀愀爀愀 攀氀
䐀攀猀 愀爀爀漀氀氀漀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
䘀 椀猀 挀 愀氀椀稀愀挀 椀渀
匀 攀爀瘀椀挀 椀漀猀 搀攀 伀戀爀愀 倀 切戀氀椀挀 愀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
伀瀀攀爀愀琀椀瘀愀 礀
匀 攀爀瘀椀挀 椀漀猀 倀 切戀氀椀挀 漀猀 䜀 攀渀攀爀愀氀攀猀
䔀 瘀愀氀甀愀琀椀瘀愀
䄀洀戀椀攀渀琀愀氀攀猀 礀 䄀最爀漀瀀⸀ 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
䐀攀渀甀渀挀 椀愀猀 礀 䐀攀挀 氀愀爀愀挀 椀漀渀攀猀
䨀 甀爀愀搀愀猀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 攀最甀椀洀椀攀渀琀漀 搀攀 䐀椀猀 瀀漀猀 椀挀 椀漀渀攀猀
䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 攀爀瘀椀挀 椀漀猀 匀 漀挀 椀愀氀攀猀 䌀 䌀 䌀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
䄀猀 攀猀 漀爀椀愀 礀
䄀猀 攀猀 漀爀椀愀 礀 䜀 攀猀 琀椀渀 䨀 甀爀椀搀椀挀 愀
䜀 攀猀 琀椀渀 䨀 甀爀椀搀椀挀 愀
刀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
䌀 漀渀琀爀愀琀愀挀 椀渀
䌀 漀渀琀爀愀琀愀挀 椀渀 䄀搀洀椀渀椀猀 琀爀愀琀椀瘀愀
䄀搀洀椀渀椀猀 琀爀愀琀椀瘀愀 刀 䌀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
刀 攀挀 甀爀猀 漀猀 䠀甀洀愀渀漀猀 刀 刀 䌀 刀 刀 刀 刀 刀
䌀 攀渀琀爀漀 搀攀 䌀 愀瀀愀挀 椀琀愀挀 椀渀 刀 刀 䌀 刀 刀 刀 刀 刀
䜀 攀爀攀渀挀 椀愀 搀攀
唀渀椀搀愀搀 搀攀 倀 爀攀渀猀 愀 礀
䔀 猀 琀爀愀琀攀最椀愀
Conocimientos sobre los Sistemas de la CGR
䌀 漀洀甀渀椀挀 愀挀 椀渀 刀 刀 䌀 刀 刀 刀 刀 刀
䤀渀猀 琀椀琀甀挀 椀漀渀愀氀
唀渀椀搀愀搀 搀攀 䐀攀猀 愀爀爀漀氀氀漀
伀爀最愀渀椀稀愀挀 椀漀渀愀氀 䌀 䌀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 攀爀瘀椀挀 椀漀猀 搀攀 䤀渀昀漀爀洀愀挀 椀渀 刀 刀 䌀 刀 刀 刀 刀 刀
匀 椀猀 琀攀洀愀猀 礀 吀 攀挀 渀漀氀漀最愀猀 搀攀
䜀 攀爀攀渀挀 椀愀 搀攀 䐀攀猀 愀爀爀漀氀氀漀
䤀渀昀漀爀洀愀挀 椀渀 刀 刀 䌀 刀 刀 刀 刀 刀
唀渀椀搀愀搀 搀攀 匀 攀爀瘀椀挀 椀漀猀 䘀 椀渀愀渀挀 椀攀爀漀猀
䌀 刀 刀 䌀 刀 刀 刀 刀 刀
478 / Normas Técnicas en Tecnologías de Información y Comunicaciones
ANEXO 12
Resumen de comportamientos relacionados con la aplicación de TIC’s
Encuestas realizadas a la DFOE, DDI, DEI, DAGJ, DCA, USTI
䌀 伀䴀倀 䔀 吀 䔀 一䌀 䤀䄀 䌀 伀䴀倀 伀刀 吀 䄀䴀䤀䔀 一吀 伀 䐀椀瘀椀猀 椀渀⼀唀渀椀搀愀搀 一䄀 䈀 愀樀漀 一䄀ⴀ䈀 愀樀漀 䴀攀搀椀漀 一䄀ⴀ䈀 愀樀漀ⴀ䴀攀搀椀漀
䐀䘀 伀䔀 ㈀Ⰰ㤀─ 㠀Ⰰ㜀─ ㈀Ⰰ㜀─ 㐀㘀Ⰰ㈀─ 㘀㜀Ⰰ㠀─
吀 漀洀愀 搀攀挀 椀猀 椀漀渀攀猀 愀挀 攀爀琀愀搀愀猀 礀
䐀䐀䤀Ⰰ䐀䔀 䤀Ⰰ 䐀䄀䜀 䨀 Ⰰ 䐀䌀 䄀 㤀Ⰰ ─ ㌀Ⰰ㔀─ ㌀㈀Ⰰ㔀─ ㌀㜀Ⰰ㌀─ 㘀㤀Ⰰ㠀─
䰀 䤀䐀䔀 刀 䄀娀䜀 伀 挀 漀渀猀 椀猀 琀攀渀琀攀猀 愀瀀漀礀愀搀漀 攀渀 氀愀猀
唀匀 吀 䤀 Ⰰ ─ Ⰰ ─ Ⰰ ─ 㘀㔀Ⰰ ─ 㜀㔀Ⰰ ─
吀 䤀䌀 ✀猀 吀 漀琀愀氀攀猀 㐀Ⰰ㘀─ 㤀Ⰰ㜀─ ㈀㐀Ⰰ㌀─ 㐀㐀Ⰰ㐀─ 㘀㠀Ⰰ㠀─
䌀 伀䴀倀 䔀 吀 䔀 一䌀 䤀䄀 䌀 伀䴀倀 伀刀 吀 䄀䴀䤀䔀 一吀 伀 䐀椀瘀椀猀 椀渀⼀唀渀椀搀愀搀 一䄀 䈀 愀樀漀 一䄀ⴀ䈀 愀樀漀 䴀攀搀椀漀 一䄀ⴀ䈀 愀樀漀ⴀ䴀攀搀椀漀
䐀䘀 伀䔀 㐀Ⰰ㤀─ 㤀Ⰰ─ 㐀Ⰰ ─ 㐀㜀Ⰰ㈀─ 㘀Ⰰ㈀─
䄀猀 椀洀椀氀愀 攀 椀渀挀 漀爀瀀漀爀愀 昀挀 椀氀洀攀渀琀攀 氀愀
䐀䐀䤀Ⰰ䐀䔀 䤀Ⰰ 䐀䄀䜀 䨀 Ⰰ 䐀䌀 䄀 㐀Ⰰ㠀─ 㠀Ⰰ㜀─ ㌀Ⰰ㔀─ ㌀㐀Ⰰ㤀─ 㐀㠀Ⰰ㐀─
䤀一一伀嘀 䄀䌀 䤀팀一 愀瀀氀椀挀 愀挀 椀渀 搀攀 渀甀攀瘀愀猀 吀 䤀䌀 ✀猀 攀渀
唀匀 吀 䤀 Ⰰ ─ Ⰰ ─ Ⰰ ─ ㌀ Ⰰ ─ ㌀ Ⰰ ─
氀漀猀 琀爀愀戀愀樀漀猀 吀 漀琀愀氀攀猀 㐀Ⰰ㘀─ 㠀Ⰰ㘀─ ㌀Ⰰ㈀─ 㐀㈀Ⰰ㠀─ 㔀㘀Ⰰ ─
䌀 伀䴀倀 䔀 吀 䔀 一䌀 䤀䄀 䌀 伀䴀倀 伀刀 吀 䄀䴀䤀䔀 一吀 伀 䐀椀瘀椀猀 椀渀⼀唀渀椀搀愀搀 一䄀 䈀 愀樀漀 一䄀ⴀ䈀 愀樀漀 䴀攀搀椀漀 一䄀ⴀ䈀 愀樀漀ⴀ䴀攀搀椀漀
䐀䘀 伀䔀 ㌀Ⰰ─ ㌀Ⰰ㘀─ 㘀Ⰰ㠀─ 㐀㤀Ⰰ㌀─ 㘀㘀Ⰰ─
䄀挀 琀甀愀氀椀稀愀 猀 甀猀 挀 漀渀漀挀 椀洀椀攀渀琀漀猀 攀渀
䐀䐀䤀Ⰰ䐀䔀 䤀Ⰰ 䐀䄀䜀 䨀 Ⰰ 䐀䌀 䄀 ㈀Ⰰ㐀─ Ⰰ㤀─ 㐀Ⰰ㌀─ 㐀㈀Ⰰ─ 㔀㘀Ⰰ㌀─
䤀一一伀嘀 䄀䌀 䤀팀一 琀攀洀愀猀 搀攀 椀渀琀攀爀猀 瀀愀爀愀 氀愀
唀匀 吀 䤀 Ⰰ ─ Ⰰ ─ Ⰰ ─ ㈀㔀Ⰰ ─ ㌀㔀Ⰰ ─
䤀渀猀 琀椀琀甀挀 椀渀 礀 攀渀 攀氀 甀猀 漀 搀攀 吀 䤀䌀 ✀猀 吀 漀琀愀氀攀猀 ㈀Ⰰ㠀─ ㌀Ⰰ ─ 㔀Ⰰ㜀─ 㐀㘀Ⰰ─ 㘀Ⰰ㠀─
480 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Anexo - NTP13
Plan de la Capacidad en TI
482 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normas Técnicas en Tecnologías de Información y Comunicaciones / 483
Debido a lo anterior y para cumplir con las exigencias de las normas técnicas emitidas
por la CGR en materia de tecnologías de información para las instituciones públicas,
en este documento se establece un modelo para medir la capacidad para evaluar y
proyectar la infraestructura tecnológica actual y requerida por la institución.
484 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Los componentes que se incluyen dentro de este plan consideran hardware, bases de
datos, sistemas operativos y telecomunicaciones.
2. Objetivos
1.1. Objetivo General:
3. Alcance
Este documento define las actividades necesarias para asegurar que las mejoras,
cambios y los nuevos servicios que afecten la infraestructura tecnológica, proveerán
un ambiente que cumple con los estándares de servicio acordados y las necesidades
de la CGR.
Los componentes a los que se aplicará la gestión de capacidad son los servidores de
bases de datos, aplicaciones, y correo institucional, la base de datos de producción,
enrutadores, ancho de banda Internet, Firewall, programas protectores contra virus
informáticos y código malicioso, detectores de intrusos, switches de RED y la central
telefónica.
3.1. Responsables
PETIC y PETAC, las previsiones del volumen de trabajo de los usuarios (modelo o
arquitectura de información), o las proyecciones de nivel de servicio obtenido por el
uso de herramientas de modelación-; así como las características de capacidad por
cada uno de los componentes para apoyar la toma de decisiones.
Establecer las variables de medición así como las métricas y los parámetros sobre las
que se van a comparar y medir.
4.5. Sustitución
4.6. Riesgos
4.7. Prioridades
4.8. Presupuesto
• Definir cuáles son los períodos en los que requiere mayor capacidad (picos).
• Niveles de servicio esperados.
• Tiempo de respuesta esperada.
• Complejidad.
• Capacidad de crecimiento requerida.
• Requerimientos nuevos.
• Nuevos proyectos tecnológicos.
• Recurso humano necesario.
Los datos recopilados deben ser analizados para tomar decisiones relacionadas con
la ejecución de acciones correctivas que permitan mantener una infraestructura
tecnológica acorde con las necesidades de la CGR.
5.1. Ajustes
5.4. INSUMOS
6. Análisis de capacidad
B. Enrutadores
1. Confiabilidad de la interface. 100% 50% < 50%
2. Indice de carga de la interface de 15% 70% > 70%
transmision TX
3. Indice de carga de la interface de 10% 70% > 70%Mas de 180/255
recepción RX
4. Estadísticas para 5 minutos:
4.1 Tasa de transferencia en bits por 45% del canal 80% del canal > 80% del canal
segundo.
5. Utilización de CPU 30% 60% 70%
Instrumento de medición: Comandos
sistema operativo
C. Firewall
1. Utilización de CPU 20% 40% 65%
2. Memoria utilizada. 50% 70% 80%
3. Tasa de transferencia por subred 1Mbps 6Mbps 8Mbps
4. Ancho de banda utilizado por subred 30% del ancho de 50% del ancho de banda total >70 % del ancho de banda total
banda total
Instrumento de medición: Programa ASDM
instalado en el Firewall.
D. Appliance E-3100 Mc.Afee
1. Carga de CPU. 20% 70% 80%
2. Memoria utilizada / memoria disponible 50% 70% 80%
3.Paginación 5% 10%
15%
30%
5. Tasa utilización disco %iowait 10% 15%
Consideraciones básicas
Métricas:
90% o más de un 50% de
1. % Utilización CPU. 65% 85% utilización de la UPC por sistema
operativo
2. % Utilización de Memoria < 65% >85% >90%
3.Promedio de tiempo de escritura del redo
30s 90s 100s
log
4. Lock wait 10s 30s 60s
A. Switches.
Switch de Servidores
Switch de Backbone
Switch de Acceso
Métricas:
Métricas:
% Utilización Ancho de banda por puerto de
access point < 70% 70% >75%
Instrumento de medición: Hipath de
Siemens y EPI-Center de Extreme Networks
Métricas:
% Utilización de canales E1s < 70% 70% >75%
Instrumento de medición: OTM de Nortel
Networks
Anexo - NTP14
Acuerdo de Nivel de Servicio
498 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Normas Técnicas en Tecnologías de Información y Comunicaciones / 499
Introducción
Objetivo
Servicios tecnológicos
1. Correo Electrónico
2. Red Convergente
3. Internet
4. Disponibilidad de la información
5. Telefonía a nivel de servidores
500 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Correo Electrónico
Compromisos del Proveedor
Red convergente
Compromisos del proveedor
Internet
Compromisos del Proveedor
Disponibilidad de la Información
Compromisos del Proveedor
Telefonía
Compromisos del Proveedor
Centro de Llamadas
Suspensión de servicios
El proveedor no podrá brindar los servicios incluidos en este SLA, cuando éste se
suspenda por razones de mantenimiento preventivo a servidores, red o bases de datos;
previamente acordado y comunicado a todos los funcionarios, o por mantenimiento
correctivo, producto de fallas fuera del control del proveedor, o por interrupción del
504 / Normas Técnicas en Tecnologías de Información y Comunicaciones
Evaluación
Vigencia
Este Acuerdo de Servicios tiene una vigencia de un año a partir de la firma de aceptación
de las partes y se prorroga automáticamente por períodos iguales, si ninguna de las
partes decide su finalización con un mes de anticipación en días naturales.
Se firma este Acuerdo de Nivel de Servicios en San José, a las 11 horas del día xx del
mes de junio del 2009.
1. Introducción
2. Antecedentes
3. Objetivo
Dicho Marco Jurídico, estará conformado por las leyes, decretos, resoluciones,
contratos, procedimientos, directrices, estándares y prácticas relacionadas con la
Normas Técnicas en Tecnologías de Información y Comunicaciones / 511
4.2 La factura del proveedor debe ser revisada por el administrador del contrato y por
la asistente presupuestaria para que con su visto bueno (VB) se autorice el pago por
parte de la jefatura como Unidad técnica responsable.
4.4 Las licencias contratadas son para utilizar únicamente en equipos de la CGR.
5. Documentos relacionados
Con el propósito de poner a disposición de los funcionarios el Marco Jurídico que rige
el accionar institucional en tecnologías de información y comunicación, a continuación
registramos todas aquellas leyes y demás, a las que estamos supeditados y obligados.
5.1 Leyes
5.3Reglamentos
5.4 Decretos
5.5 Normas
5.6 Estatutos
5.7 Resoluciones
5.8 Directrices
5.9 Contratos
AEC Electrónica, servicio de reemplazo para un switch Black Diamond modelo 6808
y servicio de soporte en línea de atención 48hr AHR, ambos por un año. Resolución
administrativa 1-2009 de ampliación.
Control Electrónico S.A., Arreglo de discos (SAN) y Servidores con garantía de tres
años. Contrato No. 2008-000018.
6. Conclusiones
Es por ello que se convierte en un factor clave de éxito para nuestra gestión contractual,
el repasar constantemente este Marco Jurídico y el mantenerlo actualizado de acuerdo
con la normativa o documentos relacionados, así como con base a la generación de
nuevos documentos aplicables a las tecnologías de información y comunicación.
Introducción
Actividades ejecutadas
Plan de continuidad
1.4.7 Continuidad de los Plan de contingencia actualizado Cumplido Se implementó el sistema de contingencias a partir del 1 de julio
servicios de TI para garantizar la continuidad de los
servicios de TI
1.4.8 El acceso a la información Control de acceso a la información por Cumplido Para efectos de acceso a la información por parte de terceros, se
por parte de terceros y la parte de proveedores de servicios y de requiere de convenios o contratos previamente establecidos, o de la
contratación de servicios terceros. solicitud del jerarca de una institución, para la asignación de un rol
prestados por éstos. que le facilite la consulta controlada, igual en contrato de servicios
mediante cláusulas de confidencialidad.
1.4.9 El manejo de la Administración de documentos Cumplido Se realiza por medio del Sistema Integrado de Gestión y Documentos
documentación (SIGYD). Los documentos se clasifican por tipos documentales y
están disponibles de acuerdo con la tabla de plazos autorizada por
el Archivo Nacional. Para TI aplica el estándar establecido en la
Metodología para desarrollo de Proyectos de TI.
1.4.10 La terminación normal Administración de contratos Cumplido La UTI mantiene como política la administración de contratos
relacionados con TI, a través de los coordinadores; según
530 / Normas Técnicas en Tecnologías de Información y Comunicaciones
de contratos, su rescisión o
resolución especialidad y afinidad, con el objetivo de un control periódico y
directo sobre la ejecución, su continuidad, rescisión o la resolución
del mismo.
1.4.11 La salud y seguridad Comité de Salud Ocupacional Cumplido La CGR cuenta con un Comité de Salud Ocupacional que se ocupa
ocupacional operando permanentemente de este tema y con el cual se ha coordinado la
ergonomía de los puestos de trabajo y su entorno.
1.5 Gestión de proyectos Guía metodológica para la gestión de Cumplido Metodología para el desarrollo de
proyectos de TI Proyectos de Tecnología Información y Comunicaciones. Actualmente
en uso para todos los proyectos de TI. Se mantiene en ejecución
la cartera de proyectos aprobada por el Despacho de las señoras
Contraloras y que se encuentra incorporado en el PTAC.
1.6 Decisiones sobre asuntos Funcionamiento efectivo del Cumplido El comité gerencial atiende convocatorias a reuniones, según sea
estratégicos de TI Comité Gerencial de Tecnologías de necesario. Además, cuenta con un comité Ad hoc para análisis
Información y Comunicación preliminar de las propuestas de soluciones tecnológicas.
1.7 Cumplimiento de Marco jurídico con incidencia en TI Cumplido Se elaboró un Marco Jurídico – básico- de aplicación en la CGR,
obligaciones relacionadas con la disponible, actualizado y aplicado. el cual es de actualización permanente en términos de leyes,
gestión de TI normativa, resoluciones y contratos, entre otros, con el propósito de
evitar posibles conflictos legales que lleguen a ocasionar eventuales
perjuicios económicos y de otra naturaleza a la institución. Se
actualizará con un proyecto de maestría del ITEC y se someterá a
revisión a la DCA.
Seguimiento oportuno a contratos de Cumplido Existe una gestión práctica por área de la administración de los
TI. contratos en UTI.
2.1 Planificación de las Seguimiento al PETIC y PTAC Cumplido Seguimiento de proyectos constante a través de reuniones periódicas
tecnologías de información con los líderes de proyectos.
Compromisos de gestión y PAO Cumplido Proyectos del PTAC fungen como compromisos de gestión de cada
alineado al PETIC y PTAC área.
Se ha respetado el mecanismo de inclusión de proyectos definido en
el PTAC.
2.2 Modelo de arquitectura de Modelo de arquitectura de información Cumplido Los siguientes niveles del modelo de información, dependen del
información nivel 1. desarrollo de la siguiente fase del MAGEFI en lo que respecta a
procedimientos, de donde se deben generar los insumos necesarios
para los siguientes niveles y para la elaboración del diccionario de
datos.
2.3 Infraestructura tecnológica Infraestructura tecnológica alineada Cumplido La CGR cuenta con una infraestructura tecnológica adecuada,
a PETIC alineada y actualizada a las necesidades sustantivas y de apoyo,
producto de un direccionamiento estratégico en TI definido en el
PETIC.
Plan de capacidad Cumplido Se elaboró el Manual Plan de la Capacidad en TI, que le permitirá a
la UTI mejorar la actualización de su infraestructura tecnológica a
partir del segundo semestre del 2009.
2.4 Independencia y recurso Estructura orgánica actualizada Cumplido El PETIC garantiza una visión institucional y promueve la
humano de la función de TI acorde con PETIC independencia funcional en el desarrollo de soluciones tecnológicas.
Actualmente la UTI depende de la División de Gestión de Apoyo y
su independencia funcional se ve fortalecida por medio de una
participación directa del Despacho en distintas comisiones ad hoc
enfocadas a la función de TI en la Institución, por la existencia de
una cartera de proyectos a desarrollar y la existencia del CGTIC
Normas Técnicas en Tecnologías de Información y Comunicaciones / 531
Programa de actualización, Cumplido Se elaboró un estudio para la elaboración del Plan de Educación
información a usuarios continua en tecnologías de información y comunicación.
2.5 Administración de recursos Presupuesto de inversiones con base Cumplido El presupuesto de inversiones de la UTI y sus modificaciones,
financieros en el PTAC se deriva del PTAC y es aprobado por el Despacho con base en
las recomendaciones que emita el CGTIC y el comité ad hoc de
seguimiento al PETIC-PTAC.
3.1 Consideraciones generales Metodología para desarrollo Cumplido La cartera de proyectos de TI se desarrolla e implementa con base a
de la implementación de TI. La de proyectos de TI aplicada esta metodología y es aplicada por los Patrocinadores y el equipo de
organización debe implementar institucionalmente trabajo en su totalidad.
y mantener las TI requeridas
en concordancia con su marco Se cuenta con un modelo de Arquitectura de Información en su nivel
estratégico, planificación, inicial.
modelo de arquitectura de
información e infraestructura Las TI se implementan con base a PETIC y PTAC.
tecnológica.
3.2 Implementación de software Software en uso de acuerdo con las Cumplido El software que se desarrolla e implementa es con base al PTAC
necesidades de la institución al plan de compras derivado del PETIC, ambos aprobados por el
Despacho de las señoras Contraloras.
Aplicación de la guía metodológica Cumplido Para todos los proyectos de TI se aplica a nivel institucional la
para el desarrollo de sistemas Metodología para desarrollo de proyectos.
3.3 Implementación de Infraestructura tecnológica alineada Cumplido La CGR cuenta con una infraestructura tecnológica adecuada,
infraestructura tecnológica al PETIC alineada y actualizada a las necesidades sustantivas y de apoyo,
producto de un direccionamiento estratégico en TI definido en el PETIC.
3.4 Contratación de terceros Servicios contratados a terceros con Cumplido Aplica todo lo relacionado a metodologías, guías, procedimientos,
para la implementación y base en estándares institucionales organización, controles y ambientes de trabajo, entre otros.
mantenimiento de software e
infraestructura
4.1 Definición y administración Identificación completa y registrada Pendiente Se definieron los acuerdos de nivel de servicio a firmar con los
de acuerdos de servicios y seguimiento de los servicios de la Gerentes de División, está pendiente la revisión y firma para su
función de TI aplicación y administración.
532 / Normas Técnicas en Tecnologías de Información y Comunicaciones
4.2 Administración y operación Diagnóstico anual de capacidad, Cumplido Se elaboró el Manual Plan de la Capacidad en TI para implementar
de la plataforma tecnológica. mantenimiento y evolución de la en el segundo semestre del 2009.
plataforma tecnológica
En el Sistema de Contingencias, disponible en la Intranet, se
encuentran registrados 221 procedimientos asociados con la
operación de la plataforma y los responsables por recurso tecnológico.
4.3 Administración de los datos Políticas y procedimientos revisados y Cumplido De acuerdo con los requerimientos de usuario se asegura la validez
actualizados de las transacciones mediante funciones tecnológicas integradas a
la base de datos; su integridad, almacenamiento y su vigencia.
4.4 Atención de requerimientos Centro de atención a usuarios Cumplido La UTI tiene implementado un sistema de control de cambios que
de los usuarios de TI centralizado. facilita al usuario la solicitud de ajustes o de incorporación de nuevas
funcionalidades a los sistemas que están operando en la Institución y
disponiendo un sistema para auto servirse o registrar su requerimiento
(Ver SOS), o realizando una llamada para registro o servicio remoto
en línea. La UTI atiende estos requerimientos en orden de urgencia,
importancia, prioridad y mediante capacitación dirigida.
5.3 Participación de la Auditoría Auditoría interna auditando, Cumplido Esta es una labor que se mantiene muy bien ejecutada por la
asesorando y recomendando mejoras Auditoría Interna de la CGR, suministrando recomendaciones de
Normas Técnicas en Tecnologías de Información y Comunicaciones / 533