Informe NTI Doc.desbloqueado

Contraloría General de la República División de Gestión de Apoyo Unidad de Tecnologías de Información

Normas Técnicas en Tecnologías de Información y Comunicaciones

Informe final Versión 1.0.0 Julio 2009

Normas Técnicas en Tecnologías de Información y Comunicaciones / 3

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-2009CO-2009, como lo consigna la norma No. 5.9: “5.9 Tecnologías de Información. El jerarca y los titulares subordinados, según sus competencias, deben propiciar el aprovechamiento de tecnologías de información que apoyen la gestión institucional mediante el manejo apropiado de la información y la implementación de solu ciones ágiles y de amplio alcance. Para ello deben observar la normativa relacionada con las tecnologías de información, emitida por la CGR.” Conscientes de que las tecnologías de información constituyen un factor crítico y estratégico para la modernización de los procesos de trabajo y para el desarrollo de soluciones tecnológicas de calidad, que apoyen las labores sustantivas y de apoyo, a continuación se emite un informe con los principales aspectos desarrollados en la Contraloría General, como Administración Activa, en atención de estas NT.

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

Al cabo de ese período, se logra culminar un primer esfuerzo de cumplimiento razonable e integrado de todos los aspectos contenidos en esas normas, sin que esto obste para ir profundizando y actualizando los resultados obtenidos, así como para atender nuevos requerimientos derivados de la normativa y del entorno.

Metodología Para atender la normativa se inició con el trabajo de preparación delineado en el artículo 6 de la Resolución No. R-CO-26-2007, a saber: • La constitución de un equipo de trabajo. • La designación de un responsable del proceso de implementación, coordinador del equipo de trabajo, con la autoridad necesaria para ejecutar el plan definido. • El estudio detallado de las normas técnicas referidas, para identificar las que apliquen a la entidad u órgano de conformidad con su realidad tecnológica y con base en ello establecer prioridades de implementación. • Una planificación debidamente documentada, que considere actividades, plazos para cada una, responsables, costos estimados y cualquier otro requerimiento asociado (infraestructura, personal, recursos técnicos.). Para su implementación, la señora Contralora, mediante oficio No. CO-0272 del 15 de agosto de 2007, designó como equipo de trabajo a la comisión ad hoc ya existente, que había coordinado la elaboración de los planes estratégico y táctico de tecnologías de información y comunicación de la Contraloría, y que apoya en su implementación y seguimiento. A este equipo se le asignó el objetivo de elaborar el cronograma de trabajo para el cumplimiento de las NT y darle seguimiento a la ejecución del mismo.


El equipo de trabajo está coordinado por la señora Subcontralora. La responsabilidad de la implementación técnica de las normas se delegó en la jefatura de la Unidad de Tecnologías de Información (UTI), quien a su vez constituyó y coordinó distintos grupos de trabajo para la consecución del objetivo. Esto último sin perjuicio de la responsabilidad del jerarca, titulares subordinados y los demás funcionarios de la institución, en cuanto al cumplimiento de sus roles en materia de control interno en general y sobre el componente funcional de Sistemas de Información en particular. Se elaboró un diagnóstico institucional sobre el estado de TI con respecto a las NT, incluyendo en éste una propuesta de productos, acciones y un cronograma de ejecución de las mismas. El documento fue presentado por el grupo ad hoc al Comité Gerencial de Tecnologías de Información y Comunicación (CGTIC), siendo avalado por este comité y tomado como base para la implementación de las NT. Ver minuta Nro. 3 del 12 de marzo de 2008, acuerdo 1, apartado 3. Asimismo, se planificó la implementación de las NT con base al cronograma resultante del referido diagnóstico institucional. Ver documento NTP0 Diagnóstico Inicial y NTP1 Cronograma de Implementación. El contenido del informe consigna en negrilla el texto de las normas y seguidamente, se resume el trabajo realizado para cumplir cada una de estas. Los documentos a los cuales se hace referencia al resumir el trabajo realizado están hipervinculados a su versión digital.

Capítulo I

Normas de Aplicación General


Capítulo I Normas de Aplicación General 1.1 Marco estratégico de TI El jerarca debe traducir sus aspiraciones en materia de TI en prácticas cotidianas de la organización, mediante un proceso continuo de promulgación y divulgación de un marco estratégico constituido por políticas organizacionales que el personal comprenda y con las que esté comprometido. 1.1.1 Con la representación de las áreas sustantivas y de apoyo de la CGR, se elaboró para su puesta en marcha y ejecución el Plan Estratégico en Tecnologías de Información y Comunicación (PETIC), del cual derivó un Plan Táctico (PTAC). Por su parte, en el Plan Anual Operativo las Unidades han incorporado los proyectos correspondientes para dar cumplimiento al dimensionamiento estratégico y táctico de TI, todo debidamente alineado al Plan Estratégico Institucional. Ver documentos PETIC y PETAC. 1.1.2 Se realizó la divulgación de los planes indicados en el punto 1.1.1 mediante charlas generales y específicas; así como por su publicación en la Intranet institucional, logrando el compromiso de los patrocinadores y funcionarios en el desarrollo de soluciones tecnológicas. 1.1.3 El CGTIC analizó la cartera de proyectos y estableció las prioridades de ejecución de los mismos, recomendando al Despacho de las señoras Contraloras su incorporación en el PTAC.


1.2 Gestión de la calidad La organización debe generar los productos y servicios de TI de conformidad con los requerimientos de sus usuarios con base en un enfoque de eficiencia y mejoramiento continuo. 1.2.1

Se elaboró un manual para la gestión y aseguramiento de la

calidad durante el desarrollo y evolución de las soluciones tecnológicas, el cual será aplicado a partir del segundo semestre del 2009. Ver documento NTP8 Marco General para la Gestión de la Calidad en TIC. 1.2.2 Con el objetivo de iniciar la generación de datos para la toma de decisiones relacionadas con el mejoramiento continuo, se desarrolló e implementó un sistema de información dirigido al registro de solicitudes de servicio y de su solución, los tiempos empleados y el procedimiento ejecutado. Este sistema, denominado Solicitud Orden de Servicio (SOS), disponible en la Intranet, permite la medición y el control de calidad, especialmente en el servicio de soporte técnico que se brinda en la UTI. 1.2.3 Se ajustaron e integraron la guía metodológica para el desarrollo de sistemas de información automatizados y la guía para el desarrollo de proyectos de TI, fortaleciendo el aseguramiento de la calidad mediante una mayor participación de los patrocinadores de proyectos en el desarrollo y pruebas de las soluciones tecnológicas. Ver documento NPT7 Metodología para el desarrollo de proyectos de TIC.


1.3 Gestión de riesgos 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. 1.3.1 Se definieron y valoraron los riesgos de TI

integrados a la

valoración de riesgos institucional, generando un manual de riesgos y una selección de los principales riesgos a considerar. Ver documento NTP3 Evaluación de riesgos en TIC. Estos riesgos se incorporaron en la Guía para desarrollo de soluciones tecnológicas. 1.3.2 Trimestralmente se valoran y actualizan los riesgos de TI.

1.4 Gestión de la seguridad de la información La organización debe garantizar, de manera razonable, la confidencialidad, integridad y disponibilidad de la información, lo que implica protegerla contra uso, divulgación o modificación no autorizados, daño o pérdida u otros factores disfuncionales. Para ello debe documentar e implementar una política de seguridad de la información y los procedimientos correspondientes, asignar los recursos necesarios para lograr los niveles de seguridad requeridos y considerar lo que establece la presente normativa en relación con los siguientes aspectos: 1.4.1 La implementación de un marco de seguridad de la información. La CGR elaboró un Marco de Seguridad para su aplicación en toda la Institución, el cual será divulgado en el segundo semestre del 2009. Ver documento NTP10_Marco de Seguridad en Tecnologías de Información.


1.4.2 El compromiso del personal con la seguridad de la información. Mediante la elaboración, implementación y divulgación del manual denominado Lineamientos y directrices de seguridad, toda la organización se encuentra comprometida con el tema de la seguridad en general. En adición, se han impartido charlas específicas sobre seguridad al personal, se ha insertado la seguridad vía mensajes por correo electrónico y mediante artículos en el sitio Web del Club de tecnologías y enviados por e-mail. Ver documento Directrices sobre Seguridad y Utilización de Tecnologías de Información y Comunicaciones (DSUTIC). 1.4.3 La seguridad física y ambiental. Se cuenta con un sistema de seguridad perimetral que involucra control de acceso electrónico en áreas de seguridad, cámaras para vídeo vigilancia, sensores de humo, alarma contra incendio, extintores, sistema de supresión de fuego especializado para equipo de computo registro en cámara y físico de ingresos al Centro de Procesamiento de Datos y una ubicación estratégica del mismo. 1.4.4 La seguridad en las operaciones y comunicaciones. La seguridad en las operaciones se da en términos de la ejecución de procedimientos elaborados con el fin de asistir al funcionario que realice estas actividades y la supervisión de las mismas, así como de las comunicaciones. Se incorporaron certificados digitales en los servicios sensitivos de acceso al público; como declaraciones juradas, acorde con la autenticidad, integridad y confidencialidad de las transacciones que requiere la CGR. Ver documento NTP10_Marco de Seguridad en Tecnologías de Información. 1.4.5 El control de acceso.

Mediante un sistema de asignación

de roles y privilegios en uso, no sólo se controla el acceso lógico a la información, sino que también se facilita el seguimiento de las


operaciones realizadas por los usuarios de los sistemas de información operando. A lo interno los niveles gerenciales y de jefatura son los que definen los roles y privilegios que sus funcionarios pueden tener para acceder a determinada aplicación; hacia lo externo es el máximo jerarca de la entidad quien define estas asignaciones y en ambos casos deben realizar solicitud formal para que sea aplicada. La asignación de roles y privilegios es una función que ha venido asumiendo el Centro de Operaciones de la CGR y en casos muy calificados el Patrocinador del sistema, de acuerdo con las Directrices sobre Seguridad y Utilización de Tecnologías de Información y Comunicaciones (DSUTIC). 1.4.6 La seguridad en la implementación y mantenimiento de software e infraestructura tecnológica. De acuerdo con la Guía para desarrollo de proyectos de TI, la UTI cuenta con un ambiente controlado e independiente, destinado a la ejecución de desarrollo de aplicaciones que aseguren la no interferencia con las operaciones diarias y que garanticen el cumplimiento de los requerimientos de usuario, un ambiente para efectos de pruebas de usuario y capacitación, así como obviamente el ambiente para sistemas operando. 1.4.7 La continuidad de los servicios de TI. Se desarrolló e implementó el Sistema de información para la continuidad de los servicios de TI (SCS), disponible en la Intranet, que permite el registro y actualización de eventos que afecten los servicios, su solución, su criticidad y su impacto, recursos, escalabilidad, procedimientos de recuperación y responsables. 1.4.8 El acceso a la información por parte de terceros y la contratación de servicios prestados por éstos. Para efectos de acceso a la información por parte de terceros, se requiere de convenios o contratos previamente establecidos, o de la solicitud del jerarca de una institución, para la


asignación de un rol que le facilite la consulta controlada. De igual manera, aplica para la contratación de servicios a terceros, en donde se establecen cláusulas específicas sobre la confidencialidad de la información. Ver DSUTIC. 1.4.9 El manejo de la documentación. Se realiza por medio del Sistema Integrado de Gestión y Documentos (SIGYD). Los documentos se clasifican por tipos documentales y están disponibles de acuerdo con la tabla de plazos autorizada por el Archivo Nacional. La Unidad de Servicios de información se responsabiliza por administrar eficientemente la documentación física y electrónica. Desde el punto de vista de TI, se mantiene un estándar de documentación para proyectos de tecnología. 1.4.10 La terminación normal de contratos, su rescisión o resolución. La UTI mantiene como política la administración de contratos relacionados con TI, a través de los coordinadores; segú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 del personal. La CGR cuenta con un Comité de Salud Ocupacional que se ocupa 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 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.


1.5.1 Se elaboró la Guía para desarrollo de proyectos en TI que se desarrollo. Ver documento NTP7 Metodología para el desarrollo de proyectos de TIC. 1.5.2 Con base en la Guía para desarrollo de proyectos de TI, los proyectos son liderados y administrados por los patrocinadores, con la asesoría e incorporación de la UTI, quien busca mediante la coordinación de proyectos su integración y la orientación para satisfacer las necesidades en cuanto a calidad, tiempo y presupuesto. 1.5.3 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, el cual es un documento viviente que se actualiza de acuerdo con las nuevas necesidades y disposiciones. Ver minutas de seguimiento en los expedientes respectivos.

1.6 Decisiones sobre asuntos estratégicos de TI El jerarca debe apoyar sus decisiones sobre asuntos estratégicos de TI en la asesoría de una representación razonable de la organización que coadyuve a mantener la concordancia con la estrategia institucional, a establecer las prioridades de los proyectos de TI, a lograr un equilibrio en la asignación de recursos y a la adecuada atención de los requerimientos de todas las unidades de la organización. 1.6.1 El Despacho de las señoras Contraloras se apoya en el CGTIC para la toma de decisiones relacionadas con aspectos estratégicos de tecnologías de información, atendiendo sus recomendaciones sobre prioridad de ejecución de las inversiones en TI, asignación de recursos y ejecución de proyectos. 1.6.2 El Despacho cuenta con un comité Ad hoc que apoya la gestión tecnológica y que se encarga de analizar en primera instancia los


requerimientos de las unidades y que están relacionados con TI, para posteriormente someterlos al CGTIC. Ver minutas de seguimiento PETIC, PTAC.

1.7 Cumplimiento de obligaciones relacionadas con la gestión de TI 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. 1.7.1 Se elaboró un Marco Jurídico – básico- de aplicación en la CGR, el cual es de actualización permanente en términos de leyes, 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. Ver documento NTP15 Marco Jurídico en Tecnologías de Información.

Capítulo II

Planificación y organización


Capítulo II Planificación y organización 2.1 Planificación de las tecnologías de información 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. 2.1.1 El funcionamiento de las TI es centralizado y opera con base al Plan Estratégico Institucional, a cual se alinean el PETIC y el PTAC. 2.1.2 Los coordinadores patrocinadores de proyecto se reúnen periódicamente, convocados por la UTI, para compartir avances e integrar esfuerzos. La Unidad de Gobierno Corporativo hace lo propio en el contexto del seguimiento trimestral y la evaluación semestral y anual del PAO, en coordinación con la UTI para establecer los ajustes que sean necesarios de aprobación en las instancias superiores. La comisión ad hoc para el seguimiento del PETIC-PTAC conoce de los avances en los proyectos a efectos de recomendarle al CGTIC lo que corresponda. De todo este trabajo se llevan minutas por parte de los líderes y reportes de avance según corresponda. 2.1.3 La comisión ad hoc tiene entre sus funciones la integración y actualización de los planes de TI como apoyo a la gestión de TI.


2.2 Modelo de arquitectura de información La organización debe optimizar la integración, uso y estandarización de sus sistemas de información de manera que se identifique, capture y comunique, en forma completa, exacta y oportuna, sólo la información que sus procesos requieren. 2.2.1 Se actualizó el modelo de Arquitectura de Información (MAI) tomando como insumo principal la nueva versión del manual general de fiscalización (MAGEFI). Esta versión del MAI está alineada al nuevo MAGEFI y define el modelo a nivel de insumos, actividades y productos de los procesos de la CGR. Se continuará con su evolución integral alineado al desarrollo de la documentación de los procedimientos derivados de estos mismos procesos. El modelo de Arquitectura de Información sirve de base para actualizar el PTAC y ha sido divulgado para su utilización en la CGR. Ver documento NPT9 Modelo de Arquitectura de información y el Manual General de Fiscalización (MAGEFI).

2.3 Infraestructura tecnológica La organización debe tener una perspectiva clara de su dirección y condiciones en materia tecnológica, así como de la tendencia de las TI para que conforme a ello, optimice el uso de su infraestructura tecnológica, manteniendo el equilibrio que debe existir entre sus requerimientos y la dinámica y evolución de las TI. 2.3.1 La CGR cuenta con una infraestructura tecnológica adecuada, alineada

y actualizada a las necesidades sustantivas y de apoyo,

producto de un direccionamiento estratégico en TI definido en el PETIC. Con base en este direccionamiento, análisis de capacidad de TI, riesgos, y al monitoreo del entorno, se elabora el presupuesto y se realizan las compras relacionadas.


2.4 Independencia y recurso humano de la Función de TI El jerarca debe asegurar la independencia de la Función de TI respecto de las áreas usuarias y que ésta mantenga la coordinación y comunicación con las demás dependencias tanto internas y como externas. 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. 2.4.1 El PETIC garantiza una visión institucional y promueve la 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. 2.4.2 La UTI mantiene una estructura orgánica actualizada y acorde con la gestión estratégica de TI. Cada uno de sus integrantes conoce muy bien sus obligaciones y responsabilidades. Su organización es plana y especializada por áreas. 2.4.3 El equipo de trabajo de la UTI es personal muy calificado, competente, capacitación.

motivado y actualizado de acuerdo con el plan de


2.5 Administración de recursos financieros La organización debe optimizar el uso de los recursos financieros invertidos en la gestión de TI procurando el logro de los objetivos de esa inversión, controlando en forma efectiva dichos recursos y observando el marco jurídico que al efecto le resulte aplicable. 2.5.1 El presupuesto de inversiones de la UTI y sus modificaciones, 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.

Capítulo III

Implementación de tecnologías de información


Capítulo III Implementación de tecnologías de información 3.1 Consideraciones generales de la implementación de TI La organización debe implementar y mantener las TI requeridas en concordancia con su marco estratégico, planificación, modelo de arquitectura de información e infraestructura tecnológica. Para esa implementación y mantenimiento debe: a. Adoptar políticas sobre la justificación, autorización y documentación de solicitudes de implementación o mantenimiento de TI. 3.1.1 El desarrollo de nuevos proyectos requiere de la elaboración de una ficha que de manera simple indique sus alcances, objetivos, recursos, relaciones, tiempos estimados y factores críticos de éxito. Esta solicitud representada por la ficha compite con otros proyectos de interés de los patrocinadores. El ajuste de soluciones tecnológicas por solicitud del patrocinador, requiere de un formulario de requerimientos. Ver documento NTP7 Metodología para el desarrollo de proyectos de TIC. b. Establecer el respaldo claro y explícito para los proyectos de TI tanto del jerarca como de las áreas usuarias. 3.1.2 Con base a la Metodología para el desarrollo de proyectos de TIC; debidamente aprobada, se establece que el patrocinador de la solución tecnológica debe aportar los recursos necesarios para su desarrollo e implementación. c. Garantizar la participación activa de las unidades o áreas usuarias, las cuales deben tener una asignación clara de responsabilidades y aprobar formalmente las implementaciones realizadas. 3.1.3 Por medio de la implementación de la Metodología para el desarrollo de proyectos de TIC se obliga al Patrocinador a participar


activamente y con responsabilidades en el desarrollo e implementación de la solución. d. Instaurar líderes de proyecto con una asignación clara, detallada y documentada de su autoridad y responsabilidad. 3.1.4 Por medio de la implementación de la Metodología para el desarrollo de proyectos de TIC, se obliga al patrocinador a nombrar un líder de proyecto con responsabilidades claras en el desarrollo e implementación de la solución. Ver documentos (designación de patrocinadores de proyectos a partir del PTAC) en los archivos de la UTI. e. Analizar alternativas de solución de acuerdo con criterios técnicos, económicos, operativos y jurídicos, y lineamientos previamente establecidos. 3.1.5 La Metodología para el desarrollo de proyectos establece como fase inicial un diagnóstico de la solución con posibles alternativas a evaluar para tomar la mejor decisión por parte del Patrocinador o bien el CGTIC. Ver documentos de diagnóstico sobre proyectos PTAC, en el expediente de cada uno. 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.1.6 Todas las soluciones tecnológicas se desarrollan o se adquieren partiendo de requerimientos claros según se establece en la Metodología para el desarrollo de proyectos de TIC, considerando aspectos de control, seguridad y auditoría.


g. Tomar las previsiones correspondientes para garantizar la disponibilidad de los recursos económicos, técnicos y humanos requeridos. 3.1.7 Con base a la cartera de proyectos y las prioridades establecidas por el CGTIC, se somete a la aprobación del Despacho el presupuesto o asignación de recursos adicionales de TI, que permitan cumplir con la ejecución del PTAC. h. Formular y ejecutar estrategias de implementación que incluyan todas las medidas para minimizar el riesgo de que los proyectos no logren sus objetivos, no satisfagan los requerimientos o no cumplan con los términos de tiempo y costo preestablecidos. 3.1.8 Todos los proyectos de la CGR incorporan un análisis de riesgos con el objetivo de administrarlos, para ello la Guía para desarrollo de proyectos de TI contempla los riesgos más relevantes en materia de TI con el fin de que sean valorados en cada proyecto. Ver documentos Informe mensual sobre proyectos PTAC. i. Promover su independencia de proveedores de hardware, software, instalaciones y servicios. 3.1.9 Si bien es cierto es sumamente difícil independizarse de proveedores de hardware y de software en términos de que siempre se tendrá que acudir a ellos; aunque sea para aplicar actualización de versiones, la CGR ha venido fortaleciendo a su personal de TI para que en un alto porcentaje se desempeñe de la forma más independiente posible. 3.1.10 Nuestros estudios de capacidad, el análisis del entorno, el

conocimiento y la capacidad del personal de UTI nos permite

seleccionar objetivamente la solución tecnológica más adecuada para suplir las necesidades de la CGR.


3.2 Implementación de software La organización debe implementar el software que satisfaga los requerimientos de sus usuarios y soporte efectivamente sus procesos, para lo cual debe: a. Observar lo que resulte aplicable de la norma 3.1 anterior. 3.2.1 Aplica prácticamente la totalidad de la norma indicada. b. Desarrollar y aplicar un marco metodológico que guíe los procesos de implementación y considere la definición de requerimientos, los estudios de factibilidad, la elaboración de diseños, la programación y pruebas, el desarrollo de la documentación, la conversión de datos y la puesta en producción, así como también la evaluación post implantación de la satisfacción de los requerimientos. 3.2.2 Para estos efectos la UTI se apoya en la aplicación de la Guía para desarrollo de proyectos de TI, la cual incluye todas las fases indicadas. c. Establecer los controles y asignar las funciones, responsabilidades y permisos de acceso al personal a cargo de las labores de implementación y mantenimiento de software. 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. d. Controlar la implementación del software en el ambiente de producción y garantizar la integridad de datos y programas en los procesos de conversión y migración. 3.2.4 Esta labor es realizada por el DBA (Administrador de Bases de Datos), con base al procedimiento establecido, debe contarse además


con el “Visto Bueno” del patrocinador en todas sus fases y la asistencia del Líder Técnico. Ver Metodología para desarrollo de proyectos en TI. Que es un DBA e. Definir los criterios para determinar la procedencia de cambios y accesos de emergencia al software y datos, y los procedimientos de autorización, registro, supervisión y evaluación técnica, operativa y administrativa de los resultados de esos cambios y accesos. 3.2.5 Generalmente los proveedores de software envían componentes para actualizar sus productos con fines de cerrar vulnerabilidades o de optimizar su producto, o se reciben vía Internet. Estas actualizaciones son revisadas, probadas cuando es factible, y aplicadas por los especialistas en la materia. Respecto al software desarrollado localmente, previamente se debe validar y probar su adecuada funcionalidad; por parte del Líder Técnico y los usuarios, en un ambiente de pruebas ya establecido. En relación con los datos, estos deben ser modificados por el usuario autorizado en el sistema, la UTI no altera datos en sus sistemas. f. Controlar las distintas versiones de los programas que se generen como parte de su mantenimiento. 3.2.6 Esta labor es compartida por el Coordinador de proyectos de la UTI, por el desarrollador del sistema y por el DBA, apoyándose en herramientas y bitácoras propias de Oracle a nivel de Aplicattion Server.


3.3 Implementación de Infraestructura tecnológica La organización debe adquirir, instalar y actualizar la infraestructura necesaria para soportar el software de conformidad con los modelos de arquitectura de información e infraestructura tecnológica y demás criterios establecidos. Como parte de ello debe considerar lo que resulte aplicable de la norma 3.1 anterior y los ajustes necesarios a la infraestructura actual. 3.3.1 La CGR cuenta con una infraestructura tecnológica adecuada, alineada

y actualizada a las necesidades sustantivas y de apoyo,

producto de un direccionamiento estratégico en TI definido en el PETIC. 3.3.2 La UTI elabora el presupuesto y deriva el plan de compras para la actualización de la infraestructura necesaria para soportar el software, con base a las necesidades que se generan de los diagnósticos para desarrollo de soluciones tecnológicas, del plan de capacidad, riesgos y del monitoreo del entorno. Ver plan en ejecución y el proyectado para el próximo año, 2010.

3.4 Contratación de terceros para la implementación y mantenimiento de software e infraestructura La organización debe obtener satisfactoriamente el objeto contratado a terceros en procesos de implementación o mantenimiento de software e infraestructura. Para lo anterior, debe: a. Observar lo que resulte aplicable de las normas 3.1, 3.2 y 3.3 anteriores. 3.4.1 Aplica todo lo relacionado a metodologías, guías, procedimientos, organización, controles y ambientes de trabajo, entre otros.


b. Establecer una política relativa a la contratación de productos de software e infraestructura. 3.4.2 Producto del plan de capacidad, monitoreo del entorno, obsolescencia tecnológica y necesidades de TI, se somete a consideración del comité Ad hoc y del CGTIC la contratación de productos; debidamente justificados, así como el presupuesto necesario para su aprobación y ejecución, todo con base al plan de compras anual de TI derivado del PTAC. c. Contar con la debida justificación para contratar a terceros la implementación y mantenimiento de software e infraestructura tecnológica. 3.4.3 Para la contratación se requiere la aprobación de la jefatura superior, quien a su vez debe tomar la decisión dependiendo de la necesidad, la justificación y el presupuesto disponible. 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. 3.4.4 Se utiliza el estándar de la CGR para la elaboración de carteles, en coordinación con la Unidad de Gestión de Apoyo. Ver documentos (ejemplos de compras típicas). 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. 3.4.5 Para toda solución tecnológica se establece un documento de requerimientos que deben satisfacerse para su aprobación, mediante las pruebas tipo lista de chequeo en el ambiente apropiado. Ver documento de pruebas aplicado en la adquisición de la red inalámbrica entre otros.


f. Implementar un proceso de transferencia tecnológica que minimice la dependencia de la organización respecto de terceros contratados para la implementación y mantenimiento de software e infraestructura tecnológica. 3.4.6 En toda implementación por tercerización, la UTI promueve un equipo de trabajo con funcionarios de la Unidad que absorban el conocimiento de la empresa contratada en esta materia, con fines de mantener la solución operando una vez terminado el contrato.

Capítulo IV

Prestación de servicios y mantenimiento


Capítulo IV Prestación de servicios y mantenimiento 4.1 Definición y administración de acuerdos de servicio 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: a. Tener una comprensión común sobre: exactitud, oportunidad, confidencialidad, autenticidad, integridad y disponibilidad b. c. Contar con una determinación clara y completa de los servicios y sus atributos, y analizar su costo y beneficio. d. e. Definir con claridad las responsabilidades de las partes y su sujeción a las condiciones establecidas. f. g. Establecer los procedimientos para la formalización de los acuerdos y la incorporación de cambios en ellos. h. i. Definir los criterios de evaluación sobre el cumplimiento de los acuerdos. j. k. Revisar periódicamente los acuerdos de servicio, incluidos los contratos con terceros. 4.1.1 Se definieron acuerdos de servicio a firmar con las distintas Gerencias de División, incorporando servicios que faciliten la evaluación de la función de TI y la delimitación de responsabilidades hasta su vencimiento. Ver documento NTP14 Acuerdo de Nivel de Servicio.


4.2 Administración y operación de la plataforma tecnológica La organización debe mantener la plataforma tecnológica en óptimas condiciones y minimizar su riesgo de fallas. Para ello debe: a. Establecer y documentar los procedimientos y las responsabilidades asociados con la operación de la plataforma. 4.2.1 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. b. Vigilar de manera constante la disponibilidad, capacidad, desempeño y uso de la plataforma, asegurar su correcta operación y mantener un registro de sus eventuales fallas. 4.2.2 Se cuenta con herramientas para monitoreo de la capacidad de TI en sus distintas funcionalidades y a partir de la implementación del Sistema de Contingencias se están registrando electrónicamente los eventos, su impacto y su solución. Ver NTP13 Manual Plan de Capacidad en TI. c. Identificar eventuales requerimientos presentes y futuros, establecer planes para su satisfacción y garantizar la oportuna adquisición de recursos de TI requeridos tomando en cuenta la obsolescencia de la plataforma, contingencias, cargas de trabajo y tendencias tecnológicas. 4.2.3 Con base a las orientaciones del PTAC y la prioridad de ejecución de la cartera de proyectos, se inician los procedimientos de contratación para la adquisición de bienes y servicios informáticos de acuerdo a la planificación de compras generada desde el PTAC e incluidas en el PAO.


d. Controlar la composición y cambios de la plataforma y mantener un registro actualizado de sus componentes (hardware y software), custodiar adecuadamente las licencias de software y realizar verificaciones físicas periódicas. 4.2.4 Se mantiene bajo control de la UTI el registro de licencias adquiridas por la CGR, así como el medio físico para su instalación. En el Sistema de Contingencias se encuentran actualizados los recursos informáticos disponibles en la infraestructura tecnológica. 4.2.5 Se realiza periódicamente un control de inventarios de software instalado total o parcial mediante un programa especializado. Ver reportes electrónicos más recientes con sus resultados. e. Controlar la ejecución de los trabajos mediante su programación, supervisión y registro. 4.2.6 El desarrollo de proyectos y actividades tecnológicas se controlan mediante cronogramas de trabajo supervisados por los coordinadores de área de la UTI; según su especialidad, y mediante sesiones de seguimiento. Ver Metodología para desarrollo de proyectos y cronogramas con corte al 30 de junio de 2009. f. Mantener separados y controlados los ambientes de desarrollo y producción. 4.2.7 La UTI cuenta con los dos ambientes de trabajo claramente separados y controlados. g. Brindar el soporte requerido a los equipos principales y periféricos. 4.2.8 El soporte requerido se brinda mediante contratos de mantenimiento preventivo y correctivo, garantía de funcionamiento, mantenimiento interno y por medio de contratación directa de un proveedor si es necesario. Se utilizan como herramientas de apoyo los sistemas SOS y SCS.


h. Definir formalmente y efectuar rutinas de respaldo, custodiar los medios de respaldo en ambientes adecuados, controlar el acceso a dichos medios y establecer procedimientos de control para los procesos de restauración. 4.2.9 Se mantiene un plan de actividades para la generación de respaldos diarios, semanales y mensuales, y un procedimiento para custodia interna y externa. Ver procedimientos registrados en el SCS. i. Controlar los servicios e instalaciones externos. 4.2.10 Mediante la administración de los contratos y el monitoreo de los servicios contratados, se controla la buena ejecución de los servicios e instalaciones externas.

4.3 Administración de los datos 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. 4.3.1 De acuerdo con los requerimientos de usuario se asegura la validez 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 de los usuarios de TI La organización debe hacerle fácil al usuario el proceso para solicitar la atención de los requerimientos que le surjan al utilizar las TI. Asimismo, debe atender tales requerimientos de manera eficaz, eficiente y oportuna; y dicha atención debe constituir un mecanismo de aprendizaje que permita minimizar los costos asociados y la recurrencia.


4.4.1 La UTI tiene implementado un sistema de control de cambios que 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.

4.5 Manejo de incidentes La organización debe identificar, analizar y resolver de manera oportuna los problemas, errores e incidentes significativos que se susciten con las TI. Además, debe darles el seguimiento pertinente, minimizar el riesgo de recurrencia y procurar el aprendizaje necesario. 4.5.1 Todo tipo de situación especial es analizada por funcionarios de la UTI en aras de lograr la mejor solución y tratándose de incidentes o eventos, estos son registrados en los SCS o de SOS, para minimizar el riesgo de recurrencia y para agilizar el tiempo de respuesta en caso de que se materialice de nuevo.

4.6 Administración de servicios prestados por terceros La organización debe asegurar que los servicios contratados a terceros satisfagan los requerimientos en forma eficiente. Con ese fin, debe: a. Establecer los roles y responsabilidades de terceros que le brinden servicios de TI. 4.6.1 Los roles se establecen desde que se inicia el procedimiento de contratación y se verifican para efectos de establecer responsabilidades con la confección del contrato y la reunión inicial de trabajo con el proveedor de bienes y servicios de TI.


b. Establecer y documentar los procedimientos asociados con los servicios e instalaciones contratados a terceros. 4.6.2 En lo que respecta a servicios de terceros, se establecen los requerimientos como parte del contrato, ya sea en cláusulas específicas o anexos del mismo, aplicando buenas prácticas. Ver ejemplos de contrato. c. Vigilar que los servicios contratados sean congruentes con las políticas relativas a calidad, seguridad y seguimiento establecidas por la organización. 4.6.3 La UTI mantiene coordinadores por área funcional que se encargan de administrar los contratos de sus respectivos proveedores, asegurando la calidad del producto contratado y su congruencia con los estándares manuales y lineamientos o directrices institucionales. Ver asignación de coordinaciones en expedientes de UTI. d. Minimizar la dependencia de la organización respecto de los servicios contratados a un tercero. 4.6.4 La UTI logra este objetivo por medio de conformar equipos de trabajo en donde se incluye la contraparte que absorberá los conocimientos necesarios para la continuidad de la solución tecnológica contratada. e. Asignar a un responsable con las competencias necesarias que evalúe periódicamente la calidad y cumplimiento oportuno de los servicios contratados. 4.6.5 Se conforman grupos afines a la solución tecnológica para que verifiquen la calidad del producto contratado y por medio del administrador del contrato se le da seguimiento al cumplimiento y calidad del mismo.

Capítulo V

Seguimiento


Capítulo V Seguimiento 5.1 Seguimiento de los procesos de TI La organización debe asegurar el logro de los objetivos propuestos como parte de la gestión de TI, para lo cual debe establecer un marco de referencia y un proceso de seguimiento en los que defina el alcance, la metodología y los mecanismos para vigilar la gestión de TI. Asimismo, debe determinar las responsabilidades del personal a cargo de dicho proceso. 5.1.1 La organización cuenta con un marco de referencia que es el Plan Estratégico Institucional (PEI), el PETIC y PTAC, unidos al Modelo de Arquitectura de Información, el Manual General de Fiscalización (MAGEFI) como un marco de procesos, la Auditoría Interna como un elemento de advertencia y asesoría y una Unidad de Gobierno Corporativo que se encarga de darle seguimiento a la función de TI; además del CGTIC y la comisión Ad hoc.

5.2 Seguimiento y evaluación del control interno en TI El jerarca debe establecer y mantener el sistema de control interno asociado con la gestión de las TI, evaluar su efectividad y cumplimiento y mantener un registro de las excepciones que se presenten y de las medidas correctivas implementadas. 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.


5.3 Participación de la Auditoría Interna La actividad de la Auditoría Interna respecto de la gestión de las TI debe orientarse a coadyuvar, de conformidad con sus competencias, a que el control interno en TI de la organización proporcione una garantía razonable del cumplimiento de los objetivos en esa materia. 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 A continuación se indican los productos elaborados durante la puesta en marcha de las Normas Técnicas.

Productos generados durante el proceso Producto NTP0-Diagnóstico Inicial NTP1-Cronograma de implementación NTP2-Plan de Implementación NTP3-Evaluación de riesgos en TI NTP4-Instrumento metodológico MAI NTP5-Diagnóstico Inicial MAI NTP6-Informe de gestión 2008-01 NTP7-Metodología para el desarrollo de Proyectos en TI NTP8-Marco General para la gestión de calidad en TI NTP9-Modelo de Arquitectura de información NTP10-Marco de Seguridad en TI

Fecha Dic. 2007 Ene.2008 Ene.2008 Mar.2008 Jun.2008 Jun.2008 Jul.2008 Jul. 2008 Ene.2009 Mar.2009 May.2009


NTP11-Mapeo Eléctrico NTP12-Plan continuo de capacitación NTP13-Plan de la Capacidad en TI NTP14-Acuerdo de Nivel de Servicio NTP15-Marco Jurídico en TI NTP16-Informe de gestión 2009-01

Jun.2009 Jun.2009 Jun.2009 Jun.2009 Jul.2009 Ago.2009

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. Para ello, debe establecer la brecha entre lo estipulado en el Marco de Seguridad y lo que se tiene, evolucionar la Arquitectura de Información en paralelo al avance del Manual General de Fiscalización (MAGEFI), aplicar algunos de los productos como el Plan de Capacidad en TI, asegurarse de mantener actualizados todos los productos, aprobar los Acuerdos de Servicio e implementar; a partir del segundo semestre 2009, los productos obtenidos; así como definir responsables de cada uno de ellos. Finalmente, garantizar un adecuado seguimiento de la implementación de estos productos.


Anexo - NTP0

Diagnostico Inicial



Normas técnicas para la gestión y control de las tecnologías de información Diagnóstico Inicial 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. Los coordinadores de la USTI son: Joaquín Gutiérrez (Seguridad, redes, telefonía), Maureen Peña (Plataforma de micros), Johnny Umaña (Plataforma de Servidores), Jorge León (Desarrollo y Evolución de Sistemas). En adición, Maureen asiste a la jefatura de Unidad en la elaboración de carteles, seguimiento, y compra de bienes y servicios tecnológicos. Este documento es la base para la elaboración del cronograma plurianual que estará siendo ejecutado hasta el 30 de junio del 2009.


Capítulo I Normas de Aplicación General 1.1 Marco estratégico de TI El jerarca debe traducir sus aspiraciones en materia de TI en prácticas cotidianas de la organización, mediante un proceso continuo de promulgación y divulgación de un marco estratégico constituido por políticas organizacionales que el personal comprenda y con las que esté comprometido.

Situación actual • Se reformuló el campo de acción E. • Se elaboró un nuevo Plan Estratégico (PETIC). • Se elaboró un Plan Táctico con los proyectos a desarrollar.

Producto Plan de divulgación del campo de acción E, PETIC y PTAC.

Acciones • El Comité Gerencial de Tecnologías de Información y Comunicación (CGTIC) debe establecer o aprobar las prioridades para el desarrollo de proyectos recomendados en el PTAC. • Planificar una charla sobre el PTAC para el mes de febrero a Jefaturas, una para la USTI, y dos para funcionarios.

1.2 Gestión de riesgos La organización debe responder adecuadamente a las 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.


Situación actual Aplicación del SEVRI a nivel institucional, no se tiene un Unidad u oficina responsable del seguimiento y rectoría relacionado con la gestión de riesgos.

Producto Unificación de esfuerzos relacionados con la administración de riesgos que puedan afectar las TICs, divulgar aún más el SEVRI, y gestionar riesgos por Unidad con base a un manual o sistema de riesgos definido. Se recomienda la creación de una oficina rectora que dicte; institucionalmente, las políticas sobre riesgos.

Acciones • Capacitación a coordinadores de la USTI. • Integrar áreas relacionadas (Caso de administración de planta eléctrica y UPS) • Evaluación y actualización trimestral de riesgos que afecten las TICs.

1.3 Gestión de la calidad La organización debe generar los productos y servicios de TI de conformidad con los requerimientos de sus usuarios con base en un enfoque de eficiencia y mejoramiento continuo.

Situación actual Se realizan pruebas de calidad sobre los sistemas de información y se validan contra los requerimientos de usuario, previo a su puesta en marcha. Se mantiene la opción de que el usuario registre su calificación sobre el servicio brindado para valorar la gestión de la USTI y el mejoramiento continuo.


Producto Aplicación institucional de la Guía Metodológica para desarrollo de sistemas y generación de métricas sobre la calidad de los productos y servicios brindados por la USTI, con el objetivo de planificar para el mejoramiento continuo de TI.

Acciones • Encuestas de satisfacción, son permanentes producto del registro que realiza el usuario. Labor permanente. • Definir parámetros y métricas para evaluar calidad por cada tipo de servicio. • Aplicación periódica de métricas. Labor permanente. • Fortalecer; institucionalmente, el registro de solicitudes de servicio en el sistema de información. (Charlas, circulares, registro obligado para atender solicitud). Labor permanente.

1.4 Gestión de proyectos 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.

Producto Aplicación institucional de la Guía Metodológica para desarrollo de sistemas.

Acciones • Aprobación de la Guía Metodológica actualizada. • Fortalecer la administración de proyectos con los patrocinadores. Labor permanente. • Seguimiento y control sobre los proyectos por parte de la USTI. Labor permanente.


1.5 Gestión de la Seguridad de la información La organización debe garantizar, de manera razonable, la confidencialidad, integridad y disponibilidad de la información, lo que implica protegerla contra uso, divulgación o modificación no autorizados, daño o pérdida u otros factores disfuncionales. Para ello debe documentar e implementar una política de seguridad de la información y los procedimientos correspondientes, asignar los recursos necesarios para lograr los niveles de seguridad requeridos y considerar lo que establece la presente normativa en relación con los siguientes aspectos: • La implementación de la seguridad de la información. • El compromiso del personal con la seguridad de la información. • La seguridad física y ambiental. • La seguridad en la operación y comunicación. • El control de acceso. • La seguridad en la implementación y mantenimiento de software e infraestructura tecnológica. • La continuidad de los servicios de TI. Además debe establecer las medidas de seguridad relacionadas con: • El acceso a la información por parte de terceros y la contratación de servicios prestados por éstos. • El manejo de la documentación. • La terminación normal de contratos, su rescisión o resolución. • La salud y seguridad del personal. Las medidas o mecanismos de protección que se establezcan deben mantener una proporción razonable entre su costo y los riesgos asociados.


Situación actual La información se mantiene restringida para el acceso de aquellos debidamente autorizados, se tiene muy buena seguridad física y ambiental, control sobre el acceso del personal y de terceros, así como sobre la implementación de software, y en el manejo de la comunicación.

Producto Manual de seguridad y utilización de las TIC, recién aprobado por el Consejo Consultivo.

Acciones • Divulgación del Manual de Seguridad. (Correos, dos charlas en febrero, cápsulas tecnológicas)

1.5.1 Implementación de la seguridad de la información La organización debe implementar un marco de seguridad de la información, para lo cual debe: a. Establecer un marco metodológico que incluya la clasificación de los recursos de TI, según su criticidad, la identificación y evaluación de riesgos, la elaboración e implementación de un plan para el establecimiento de medidas de seguridad, la evaluación periódica del impacto de esas medidas y la ejecución de procesos de concienciación y capacitación del personal. b. Mantener una vigilancia constante sobre todo el marco de seguridad y, definir y ejecutar periódicamente acciones para su actualización. c. Documentar y mantener actualizadas las responsabilidades tanto del personal de la organización como de terceros relacionados.


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 Nivel de criticidad de cada recurso de TI., plan de implementación de las medidas de seguridad en tecnologías de información, y plan de capacitación institucional actualizados.

Acciones • Actualizar los niveles de criticidad por recurso de TI. • Actualizar plan de implementación de las medidas de seguridad. • Actualizar plan de capacitación interna en seguridad. • Incorporar seguridad en TI como parte de la Inducción a nuevos funcionarios.

1.5.2 Compromiso del personal con la seguridad de la información El personal de la organización debe conocer y estar comprometido con las regulaciones sobre seguridad y confidencialidad con el fin de reducir los riesgos de error humano, robo, fraude o uso inadecuado de los recursos de TI. Para ello, el jerarca, por sí o mediante el funcionario que designe al efecto, debe: a. Informar y capacitar a los empleados sobre sus responsabilidades en materia de seguridad, confidencialidad y riesgos asociados con el uso de las TI. b. Implementar mecanismos para vigilar el debido cumplimiento de dichas responsabilidades.


c. Establecer, cuando corresponda, acuerdos de confidencialidad y medidas de seguridad específicas relacionadas con el manejo de la documentación y rescisión de contratos.

Situación actual Se tiene un manual de directrices sobre tecnologías de información en uso, y se está planificando la divulgación de su reciente actualización aprobada por el Despacho.

Producto Monitoreo de la seguridad, charlas periódicas, y cápsulas tecnológicas a todo el personal.

Acciones • Plan de divulgación. • Impartir charlas.

1.5.3 Seguridad física y ambiental La organización debe proteger los recursos de TI estableciendo un ambiente físico seguro y controlado, con medidas de protección suficientemente fundamentadas en políticas vigentes y análisis de riesgos. Como parte de esa protección debe considerar: a. Los controles de acceso a las instalaciones: seguridad perimetral, mecanismos de control de acceso a recintos o áreas de trabajo, protección de oficinas, separación adecuada de áreas. b. La ubicación física segura de los recursos de TI. c. El ingreso y salida de equipos de la organización. d. El debido control de los servicios de mantenimiento.


e. Los controles para el desecho y reutilización de recursos de TI. f. La continuidad, seguridad y control del suministro de energía eléctrica y del cableado de datos g. El acceso de terceros. h. Los riesgos asociados con el ambiente.

Situación actual Se tienen mecanismos de control para el acceso a las instalaciones, los equipos se encuentran ubicados en un ambiente bastante seguro, se cuenta con planta eléctrica y unidades de poder para suministro de energía eléctrica constante, y la definición de riesgos asociados con el ambiente.

Producto Procedimientos y controles documentados, mecanismos para la aplicación de los puntos anteriores, y un plan de compras si se requiere.

Acciones • Documentar los procedimientos y controles. • Definir plan de acción.

1.5.4 Seguridad en la operación y comunicación La organización debe implementar las medidas de seguridad relacionadas con la operación de los recursos de TI y las comunicaciones, minimizar su riesgo de fallas y proteger la integridad del software y de la información. Para ello debe:


a. Implementar los mecanismos de control que permitan asegurar la “no negación”, la autenticidad, la integridad y la confidencialidad de las transacciones y la transferencia o intercambio de información. b. Establecer procedimientos para proteger la información almacenada en cualquier tipo de medio fijo o removible (papel, cintas, discos, otros medios), incluso los relativos al manejo y desecho de esos medios. c. Establecer medidas preventivas, detectivas y correctivas con respecto a software “malicioso” o virus.

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 Elaborar los procedimientos y los mecanismos de control para el punto b, incluyendo el software necesario. Mantener software de seguridad actualizado.

Acciones • Continuar con la gestión que se viene realizando al respecto. • Implementar firma digital una vez que el Banco Central libere el servicio.

1.5.5 Control de acceso La organización debe proteger la información de accesos no autorizados.


Para dicho propósito debe: a. Establecer un conjunto de políticas, reglas y procedimientos relacionados con el acceso a la información, al software de base y de aplicación, a las bases de datos y a las terminales y otros recursos de comunicación. b. Clasificar los recursos de TI en forma explícita, formal y uniforme de acuerdo con términos de sensibilidad. c. Definir la propiedad, custodia y responsabilidad sobre los recursos de TI. d. Establecer procedimientos para la definición de perfiles, roles y niveles de privilegio, y para la identificación y autenticación para el acceso a la información, tanto para usuarios como para recursos de TI. e. Asignar los derechos de acceso a los usuarios de los recursos de TI, de conformidad con las políticas de la organización bajo el principio de “necesidad de saber” o “menor privilegio”. Los propietarios de la información son responsables de definir quiénes tienen acceso a la información y con qué limitaciones o restricciones. f. Implementar el uso y control de medios de autenticación (identificación de usuario, contraseñas y otros medios) que permitan identificar y responsabilizar a quienes utilizan los recursos de TI.

Ello debe acompañarse de un

procedimiento que contemple la requisición, aprobación, establecimiento, suspensión y desactivación de tales medios de autenticación, así como para su revisión y actualización periódica y atención de usos irregulares. g. Establecer controles de acceso a la información impresa, visible en pantallas o almacenada en medios físicos y proteger adecuadamente dichos medios. h. Establecer los mecanismos necesarios (pistas de auditoría) que permitan un adecuado y periódico seguimiento al acceso a las TI. i. Manejar de manera restringida y controlada la información sobre la seguridad de las TI.


Situación actual Se tienen políticas sobre el acceso a la información pero deben ser documentadas y fortalecidas en función de las normas técnicas, documentar la propiedad y custodia de los recursos de TI, se tienen procedimientos para asignación de roles con sus niveles de privilegios y la autenticación de los usuarios, y los controles de acceso a la información.

Producto Procedimientos y política de acceso a la información, actualizados.

Acciones • Centro de Operaciones con el control de roles y asignación de passwords. • Oficializar responsables de la información (Sistemas). • Actualizar procedimientos de acceso a la información. • Activar Log Miner como herramienta para análisis de manipulación de datos y modificaciones a programas fuente.

1.5.6 Seguridad en la implementación y mantenimiento de software e infraestructura tecnológica La organización debe mantener la integridad de los procesos de implementación y mantenimiento de software e infraestructura tecnológica y evitar el acceso no autorizado, daño o pérdida de información. Para ello debe: a. Establecer obligatoriamente la definición previa de requerimientos de seguridad que deben ser implementados como parte del software e infraestructura.


b. Contar con procedimientos claramente definidos para el mantenimiento y puesta en producción del software e infraestructura. c. Mantener un acceso restringido y los controles necesarios sobre los ambientes de desarrollo o mantenimiento y de producción. d. Controlar el acceso a los programas fuente y a los datos de prueba.

Situación actual Se tienen más de 150 procedimientos documentados y un plan de requerimientos de seguridad para los próximos tres años, así como ambientes separados para los ambientes de desarrollo y producción, y control sobre los programas fuentes y los datos.

Producto Procedimientos y requerimientos actualizados.

Acciones • Revisar documentación, actualizarla y fortalecerla. Labor permanente.

1.5.7 Continuidad de los servicios de TI La organización debe mantener una continuidad razonable de sus procesos y su interrupción no debe afectar significativamente a sus usuarios. Como parte de ese esfuerzo debe documentar y poner en práctica, en forma efectiva y oportuna, las acciones preventivas y correctivas necesarias con base en los planes de mediano y largo plazo de la organización, la valoración e impacto de los riesgos y la clasificación de sus recursos de TI según su criticidad.


Situación actual Se tiene más de 150 procedimientos actualizados que facilitan la continuidad de los servicios, se deben documentar los eventos que se presenten para crear base de conocimientos, y definir los esquemas de continuidad.

Producto Procedimientos de recuperación e instalación actualizados e integrados, y eventos documentados.

Acciones • Mantener procedimientos actualizados y funcionales. Labor permanente. • Documentar eventos preventivos y correctivos, y cambios a la plataforma. • Definir esquemas de continuidad para cada servicio de TI.

1.6 Decisiones sobre asuntos estratégicos de TI El jerarca debe apoyar sus decisiones sobre asuntos estratégicos de TI en la asesoría de una representación razonable de la organización que coadyuve a mantener la concordancia con la estrategia institucional, a establecer las prioridades de los proyectos de TI, a lograr un equilibrio en la asignación de recursos y a la adecuada atención de los requerimientos de todas las unidades de la organización.

Situación actual Se tiene un CGTIC que es convocado periódicamente.

Producto Comité Gerencial de Tecnologías de Información y Comunicación activo.


Acciones • Convocar periódicamente al CGTIC.

1.7 Cumplimiento de obligaciones relacionadas con la gestión de TI 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 Se mantienen contratos muy bien establecidos sobre el software en uso y el soporte a equipos, así como restricciones técnicas para el uso de software no licenciado.

Producto Marco Jurídico con incidencia en TI disponible y actualizado.

Acciones Óptima gestión de contratos. Labor permanente. Uso institucional de sólo las licencias contratadas. Labor permanente.


Capítulo II Planificación y Organización 2.1 Planificación de las tecnologías de información 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 Se tienen planes muy bien definidos que facilitan la planificación.

Producto PETIC, PTAC, Compromisos de gestión y PAO alineados a la estrategia.

Acciones • Mantener actualizados los planes. Labor permanente.

2.2 Modelo de arquitectura de información La organización debe optimizar la integración, uso y estandarización de sus sistemas de información de manera que se identifique, capture y comunique, en forma completa, exacta y oportuna, sólo la información que sus procesos requieren.

Situación actual Se tiene un modelo de datos que debe ser evolucionado hacia la arquitectura de información, y se cuenta con un diccionario de datos al cual se le deben agregar reglas de sintaxis para cada dato.


Producto Arquitectura de Información actualizada

Acciones • Crear grupo interdisciplinario (USI,USTI,DFOE,DAGJ,DCA). • Definir flujos de información. • Documentar las reglas de sintaxis de los datos. • Actualizar diccionario de datos con reglas de sintaxis. • Actualizar Arquitectura de Información.

2.3 Infraestructura tecnológica La organización debe tener una perspectiva clara de su dirección y condiciones en materia tecnológica, así como de la tendencia de las TI para que conforme a ello, optimice el uso de su infraestructura tecnológica, manteniendo el equilibrio que debe existir entre sus requerimientos y la dinámica y evolución de las TI.

Situación actual Se tiene una infraestructura tecnológica muy actualizada y optimizada para las funciones de la CGR.

Producto Infraestructura tecnológica optimizada y actualizada.

Acciones • Mantener actualizada la infraestructura. Labor permanente.


2.4 Independencia y recurso humano de la Función de TI El jerarca debe asegurar la independencia de la Función de TI respecto de las áreas usuarias y que ésta mantenga la coordinación y comunicación con las demás dependencias tanto internas y como externas. 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 Independencia funcional de la USTI, y personal capacitado adecuadamente.

Acciones • Definir independencia funcional de la USTI. Mantener independencia. • Ejecutar el plan de capacitación. (DNC). Labor permanente.

2.5 Administración de recursos financieros La organización debe optimizar el uso de los recursos financieros invertidos en la gestión de TI procurando el logro de los objetivos de esa inversión, controlando en forma efectiva dichos recursos y observando el marco jurídico que al efecto le resulte aplicable.


Situación actual Es norma en la CGR elaborar el presupuesto de inversiones con base a las necesidades tecnológicas de la institución; someter a la consideración del CGTIC, y con base a sus recomendaciones someterlo a la aprobación del Despacho.

Producto Presupuesto de Inversiones con base al PTAC, aprobado por el Despacho.

Acciones • Someter el plan de inversiones a la aprobación del Despacho por recomendación del CGTIC.


Capítulo III Implementación de tecnologías de información 3.1 Consideraciones generales de la implementación de TI La organización debe implementar y mantener las TI requeridas en concordancia con su marco estratégico, planificación, modelo de arquitectura de información e infraestructura tecnológica. Para esa implementación y mantenimiento debe: a. Adoptar políticas sobre la justificación, autorización y documentación de solicitudes de la implementación o mantenimiento de TI. b. Establecer el respaldo claro y explícito para los proyectos de TI tanto por parte de las áreas usuarias como del jerarca. c. Garantizar la participación activa de las unidades o áreas usuarias, las cuales deben tener una asignación clara de responsabilidades y aprobar formalmente las implementaciones realizadas. d. Instaurar líderes de proyecto con una asignación clara, detallada y documentada de su autoridad y responsabilidad. e. Analizar alternativas de solución de acuerdo con

criterios técnicos,

económicos, operativos y jurídicos, y lineamientos previamente establecidos. 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. g. Tomar las previsiones correspondientes para garantizar la disponibilidad de los recursos económicos, técnicos y humanos requeridos. h. Formular y ejecutar estrategias de implementación que incluyan todas las medidas para minimizar el riesgo de que los proyectos no logren sus objetivos, no satisfagan los requerimientos o no cumplan con los términos de tiempo y costo preestablecidos. i. Promover su independencia de proveedores de hardware, software, instalaciones y servicios.


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 Guía Metodológica para desarrollo de sistemas aplicada institucionalmente.

Acciones • Aplicación de la Guía Metodológica para desarrollo de sistemas. Labor permanente. • Participación muy activa de los patrocinadores. Labor permanente. • Capacitación de funcionarios de USTI. Labor permanente.

3.2 Implementación de software La organización debe implementar el software que satisfaga los requerimientos de sus usuarios y soporte efectivamente sus procesos, para lo cual debe: a. Observar lo que resulte aplicable de la norma 3.1 anterior. b. Desarrollar y aplicar un marco metodológico que guíe los procesos de implementación y considere la definición de requerimientos, los estudios de factibilidad, la elaboración de diseños, la programación y pruebas, el desarrollo de la documentación, la conversión de datos y la puesta en producción, así como también la evaluación post-implantación de la satisfacción de requerimientos. c. Establecer los controles y asignar las funciones, responsabilidades

y

permisos de acceso al personal a cargo de las labores de implementación y mantenimiento de software.


d. Controlar la implementación del software en el ambiente de producción y garantizar la integridad de datos y programas en los procesos de conversión y migración. e. Definir los criterios para determinar la procedencia de cambios y accesos de emergencia al software y datos, y los procedimientos de autorización, registro, supervisión y evaluación técnica, operativa y administrativa de los resultados de esos cambios y accesos. f. Controlar las distintas versiones de los programas que se generen como parte de su mantenimiento.

Situación actual Se cuenta con ambientes de pruebas y producción muy bien definidos, procedimientos de instalación de software y control de versiones, migración de datos, y la procedencia e importancia de los cambios. Se debe establecer un procedimiento para control de cambios.

Producto Software en uso de acuerdo con las necesidades de la institución.

Acciones • Revisar y documentar los criterios de aplicación de cambios.

3.3 Implementación de infraestructura tecnológica La organización debe adquirir, instalar y actualizar la infraestructura necesaria para soportar el software de conformidad con los modelos de arquitectura de información e infraestructura tecnológica y demás criterios establecidos. Como parte de ello debe considerar lo que resulte aplicable de la norma 3.1 anterior y los ajustes necesarios a la infraestructura actual.


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 Infraestructura tecnológica óptima y actualizada.

Acciones • Inversiones para mantener actualizada la infraestructura de soporte a la arquitectura de información institucional, incluye plan vivo de actualización y compras. Labor permanente.

3.4 Implementación de software e infraestructura contratada a terceros La organización debe obtener satisfactoriamente el objeto contratado a terceros en procesos de implementación o mantenimiento de software e infraestructura. Para lo anterior, debe: 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.


f. Implementar un proceso de transferencia tecnológica que minimice la dependencia del tercero que presta el servicio.

Situación actual Para la contratación de los bienes y servicios de TI se consideran las últimas especificaciones, los cambios tecnológicos, las necesidades de la CGR y las experiencias que se han tenido; los resultados han sido muy buenos. Para la aceptación del objeto contratado se realiza un plan de pruebas previamente elaborado por la USTI y que es del conocimiento de los proveedores, y se considera la transferencia tecnológica para mitigar la dependencia.

Producto Objeto contratado debidamente implementado.

Acciones g. Mantener política para contratación de bienes y servicios en TI. h. Mantener el plan de pruebas para garantizar el cumplimiento por parte del proveedor. i. Continuar con el proceso de transferencia de conocimientos establecido para la tecnología adquirida. Todas son labores permanentes. j.


Capítulo IV Prestación de servicios y mantenimiento 4.1 Definición y administración de acuerdos de servicios 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:

a. Tener

una

comprensión

común

sobre:

exactitud,

oportunidad,

confidencialidad, autenticidad, integridad y disponibilidad. b. Contar con una determinación clara y completa de los servicios y sus atributos, y analizar su costo y beneficio. c. Definir con claridad las responsabilidades de las partes y su sujeción a las condiciones establecidas. d. Establecer los procedimientos para la formalización de los acuerdos y la incorporación de cambios en ellos. e. Definir los criterios de evaluación sobre el cumplimiento de los acuerdos. f. Revisar periódicamente los acuerdos de servicio, incluidos los contratos con terceros.

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.


Producto Políticas aplicadas en la contratación de terceros.

Acciones • Actualización de políticas en los contratos que se celebren. • Documentar acuerdos de servicio y forma de evaluación.

4.2 Administración y operación de la plataforma tecnológica La organización debe mantener la plataforma tecnológica en óptimas condiciones, minimizar su riesgo de fallas y proteger la integridad del software y de la información. Para ello debe: a. Establecer y documentar los procedimientos y las responsabilidades asociados con la operación de la plataforma. b. Vigilar de manera constante la disponibilidad, capacidad, desempeño y uso de la plataforma, asegurar su correcta operación, mantener un registro de sus eventuales fallas, identificar eventuales requerimientos presentes y futuros, establecer planes para su satisfacción, garantizar la oportuna adquisición de recursos de TI requeridos tomando en cuenta la obsolescencia de la plataforma, contingencias, cargas de trabajo y tendencias tecnológicas. c. Controlar la composición y cambios de la plataforma y mantener un registro actualizado de sus componentes (hardware y software), custodiar adecuadamente las licencias de software y realizar verificaciones físicas periódicas. d. Controlar la ejecución de los trabajos mediante su programación, supervisión y registro. e. Mantener separados y controlados los ambientes de desarrollo y producción. f. Brindar el soporte requerido a los equipos principales y periféricos. g. Controlar los servicios e instalaciones externos.


h. Definir formalmente y efectuar rutinas de respaldo, custodiar los medios de respaldo en ambientes adecuados, controlar el acceso a dichos medios y establecer procedimientos de control para los procesos de restauración.

Situación actual Se tienen documentados todos los procedimientos para el mantenimiento de la plataforma tecnológica, excepto la solución telefónica que se tiene parcial. La plataforma está siendo monitoreada constantemente y con base a su comportamiento se afina, optimiza, y se realizan los planes de compra. Se tiene un registro de todos los componentes, ambiente separados para desarrollo y producción, rutinas y políticas de respaldo, y control sobre la ejecución de trabajos.

Producto Diagnóstico anual sobre la capacidad de las tecnologías en uso y el crecimiento proyectado.

Acciones • Planificar y ejecutar un análisis anual de capacidad en TI. • Mantener procedimientos documentados y operativos. (Solución telefónica) • Efectuar gestión de tecnologías eficientemente. Todas son labores permanentes.

4.3 Administración de los datos 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.


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 Sistemas de información actualizados mediante procedimientos oficiales.

Acciones • Definir política para desechar datos, asegurando la existencia de procedimientos oficiales para la actualización de sistemas de información. • Mantener la bitácora para registro y control de acceso activa. • Utilizar la herramienta de software Log Miner para análisis de bitácoras.

4.4 Asistencia y asesoramiento a los usuarios de TI La organización debe resolver en forma centralizada, oportuna y eficiente las necesidades que enfrente el usuario al utilizar las TI. Su atención debe constituir un mecanismo de aprendizaje que permita minimizar los costos asociados y la recurrencia.

Situación actual Se imparte capacitación para un mejor aprovechamiento de los sistemas en uso, y se capacita al personal usuario de nuevos sistemas antes de su puesta en marcha.

Producto Usuarios de sistemas debidamente capacitados en el uso efectivo de sistemas de información.


Acciones • Continuar con la capacitación a usuarios en el uso de los sistemas. • Fortalecer cultura en TICs vía charlas, cápsulas tecnológicas y cursos. Labor permanente.

4.5 Manejo de incidentes La organización debe identificar, analizar y resolver de manera oportuna los problemas, errores e incidentes significativos que se susciten con las TI. Además, debe darles el seguimiento pertinente, minimizar el riesgo de recurrencia y procurar el aprendizaje necesario.

Situación actual Esta es una labor permanente realizada en la USTI, de la cual se deriva conocimiento para la mejora continua.

Producto Mantener el registro y documentación de incidentes actualizado.

Acciones • Continuar con la resolución de incidentes cada vez que se presenten, manteniendo un registro documentado de los mismos para minimizar el riesgo de incidencia y fortalecer los conocimientos. Labor permanente.

4.6 Administración de servicios prestados por terceros La organización debe asegurar que los servicios contratados a terceros satisfagan los requerimientos en forma eficiente. Con ese fin, debe:


a. Establecer los roles y responsabilidades de terceros que le brinden servicios de TI. b. Establecer y documentar los procedimientos asociados con los servicios e instalaciones contratados a terceros. c. Vigilar que los servicios contratados sean congruentes con sus políticas relativas a calidad, seguridad y seguimiento. d. Asignar a un responsable con las competencias necesarias que evalúe periódicamente la calidad y cumplimiento oportuno de los servicios contratados.

Situación actual Los contratos son administrados; según área de trabajo, por los coordinadores respectivos.

Producto Administración de contratos con énfasis en cláusulas sobre responsabilidades, claras y aplicables.

Acciones • Mantener la administración efectiva de contratos, vía coordinadores.


Capítulo V Seguimiento 5.1 Seguimiento de los procesos de TI La organización debe asegurar el logro de los objetivos propuestos como parte de la gestión de TI, para lo cual debe establecer un marco de referencia y un proceso de seguimiento en los que defina el alcance, la metodología y los mecanismos para vigilar la gestión de TI. Asimismo, debe determinar las responsabilidades del personal a cargo de dicho proceso.

Situación actual Se tiene un marco de referencia clara, siendo necesaria la definición del proceso de seguimiento para vigilar la gestión de TI. Se propone una rendición de cuentas periódica.

Producto PETIC, PTAC, Compromisos de Gestión y PAO totalmente alineados.

Acciones • Rendición de cuentas periódica ante el CGTICS. Labor permanente.

5.2 Seguimiento y evaluación del control interno en TI El jerarca debe establecer y mantener el sistema de control interno asociado con la gestión de las TI, evaluar su efectividad y cumplimiento y mantener un registro de las excepciones que se presenten y de las medidas correctivas implementadas.

Situación actual El sistema de control interno se aplica sobre la gestión de TI, y se aplican medidas correctivas en función de las excepciones que se presenten.


Producto Gestión de control interno en TICs asociado al sistema institucional.

Acciones • Mantener la gestión de TI asociada al sistema institucional. Labor permanente.

5.3 Participación de la Auditoría Interna La actividad de la Auditoría Interna respecto de la gestión de las TI debe orientarse a coadyuvar, de conformidad con sus competencias, a que el control interno en TI de la organización proporcione una garantía razonable del cumplimiento de los objetivos en esa materia.

Situación actual Se solicita asesoría a la AI cada vez que se considera de provecho para el desarrollo y ejecución de proyectos.

Producto Auditoría interna con amplios conocimientos sobre la gestión de TI

Acciones • Participación consultora de la Auditoría Interna en desarrollos de TI. Labor permanente.

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


Arquitectura de Información la actividad más larga del proyecto y de finalización en el 2009. Las fechas recomendadas estarían influyendo en el desarrollo de sistemas y otros proyectos de TI. Es urgente la definición de prioridades en el desarrollo de sistemas por parte del CGTIC.


Anexo - NTP2

Cronograma de Implementación


Normas Técnicas en Tecnologías de Información y Comunicaciones / 85 Apéndice #3 Cronograma estimado par al ejecución del plan de implementación 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.

Cronograma de implementación de Normas Técnicas TI Acciones a realizar por cada norma

2008 I Semestre

1.1 Marco estratégico de TI Plan de divulgación PETIC y PTAC, Campo E. 1.2 Gestión de Riesgos Definición de riesgos tecnológicos e institucionales Valorar y actualizar los riesgos TIC 1.3 Gestión de la Calidad Elaborar el manual de gestión de calidad Desarrollar el sistema de registro, medición y control 1.4 Gestión de Proyectos Adaptar y aplicar la guía metodológica 1.5 Gestión de la Seguridad Aplicar las directrices de seguridad Desarrollar directrices de seguridad complementarias Divulgar el marco de seguridad de TIC Coordinar las directrices con la valoración de riesgos 1.6 Decisiones sobre asuntos estratégicos 1.7 Cumplimiento de obligaciones relacionadas con la gestión de TI Dar seguimiento al marco jurídico de TI 2.1 Planificación de las tecnologías de información Validar el plan táctico con el CGTIC 2.2 Modelo Arquitectura de Información Desarrollar el modelo de arquitectura 2.3 Infraestructura tecnológica Dar seguimiento al entorno tecnológico 2.4 Independencia y recurso humano TIC Integrar servicios y funciones de TIC 2.5 Administración de recursos financieros Aprobar el plan de inversiones (CGTIC) 3.1 Implementación de TI Aplicar guía metodológica para proyectos Capacitar en gestión de proyectos 3.2 Implementación de software Aplicar guía metodológica para proyectos de desarrollo de sistemas Revisar y documentar los criterios de aplicación 3.3 Implementación de la infraestructura tecnológica Dar seguimiento al entorno tecnológico 3.4 Implementación de software e infraestructura contratada a terceros Agregar procedimientos de outsourcing a la guía de proyectos Actualizar la política para contratación 4.1 Definición y administración de acuerdos de servicio Elaborar y actualizar el catálogo de servicios 4.2 Administración y operación de la plataforma tecnológica Desarrollar diagnóstico de capacidad 4.3 Administración de los Datos Elaborar procedimientos de procesamiento de transacciones Implementar sistema de contingencias 4.4 Asistencia y asesoramiento a los usuarios de TI Implementar plan de capacitación de TI Establecer la función de atención de usuarios centralizada Implantar los procedimientos para atención usuarios 4.5 Manejo de incidentes Mejorar los criterios de significancia 4.6 Administración de servicios prestados por terceros Agregar procedimientos de outsourcing a la guía de proyectos Actualizar la política para contratación 5.1 Seguimiento de los procesos de TI 5.2 Seguimiento y evaluación de control interno Revisar y mejorar continuamente el CI 5.3 Participación de la auditoria interna Aprovechar oportunidades de asesoría Programar auditorias de TI

2009 II Semestre

I Semestre


Anexo - NTP3

Evaluación de Riesgos en Tecnologías de Información



Introducción Actualmente, la gestión de Tecnologías de Información y Comunicaciones (TIC) en la CGR es una de las prioridades de la agenda del Despacho de la Contralora, lo cual se evidencia en la composición de los presupuestos de tecnología, el desarrollo de proyectos, la proyección de la formación y perfil del personal de la CGR en los temas tecnológicos, así como en la elaboración de un plan estratégico, totalmente alineado con los objetivos de la institución. En vista de la evolución de las mejores prácticas, es preciso realizar evaluaciones de riesgos constantemente, para mejorar y adecuar; si es necesario, el gobierno corporativo de las TIC, así como el marco de gestión, a los adelantos en la materia de TI. Actualmente la CGR posee 600 computadoras de uso personal y 78 impresoras distribuidas dentro de la organización y en los grupos externos de fiscalización. Para el almacenamiento de bases de datos se tienen dos áreas de almacenamiento en red; conectadas con fibra a servidores, con capacidades en disco de 500 GB y de 700 GB, con una ocupación total cercana al 70% de su espacio total. Además, dispone de servidores para la ejecución de programas de seguridad, monitoreo y vigilancia. Al respecto, la disponibilidad de equipo debe ajustarse a las necesidades y prioridades que se deriven de la inserción tecnológica deseada. 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


necesario evolucionar hacia el aprovechamiento de esas potencialidades tecnológicas en la gestión de la fiscalización. Además, se utiliza software especializado para administrar el ancho de banda y filtrar el acceso a Internet, software de antivirus, administrador de las direcciones del protocolo de Internet (IP), la administración del firewall, los certificados privados, un administrador de proyectos, software para registro de atención de averías, el directorio activo de todos los funcionarios de la CGR, la administración de la central telefónica, el software de capacitación en línea, y la vigilancia de la seguridad de las instalaciones. Lo anterior, representa una base tecnológica que requiere ser complementada con software especializado para la fiscalización, y software colaborativo; entre otros, que permitan una fiscalización ampliamente soportada en tecnología de punta. 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.

Modelo de análisis de riesgos Contexto estratégico La CGR es un órgano de control de la Asamblea Legislativa y tiene bajo su fiscalización 472 instituciones públicas, más Juntas de Educación, Asociaciones, y empresas privadas que administren fondos públicos, para que con base en los estudios realizados se le permita a la ciudadanía conocer, acerca de cómo sus gobernantes y funcionarios públicos están utilizando los recursos que se les asignaron. Presupuestariamente depende de un presupuesto aprobado por la Asamblea Legislativa. Para transparentar la gestión pública se basa en su ley orgánica, la ley de control interno, en el sistema para evaluación de riesgos, en resoluciones de cumplimiento


obligatorio, y en normas técnicas sobre la gestión en tecnologías de información comunicación. La clientela de la CGR la conforma prácticamente todo el país: ciudadanía, proveedores, instituciones, empresas, y organismos internacionales; los cuales confían en la gestión que lleva a cabo la Contraloría para garantizarle a la ciudadanía el buen manejo de la Hacienda Pública. Además de la transparencia hacia la ciudadanía sobre la gestión de los funcionarios públicos, también es muy importante mantener el control político con el objetivo de evaluar cualquier situación que pueda afectar la estrategia. 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: • Clasificación de las instituciones públicas con base en factores de riesgo. Esto significa que el monto del presupuesto no va a ser la única variable para determinar hacia dónde dirigir la fiscalización, sino que también interesa la calidad de la administración y sus órganos de decisión, de la auditoría interna, la contratación, la planificación, las variables financieras y otras. Es necesario que definamos un conjunto de variables y no busquemos el sistema perfecto para identificar las entidades de más riesgo y a partir de ahí definir a dónde vamos a ir y qué vamos a hacer. Esto también significa que no solo la institución esté clara hacia donde vamos, sino que los que están en el entorno también lo tengan claro, ya que lo más operativo lo


deberán asumir las auditorías internas y el mismo sistema de control de cada institución. • Aplicación de los temas estratégicos para la fiscalización, según las particularidades de las áreas de fiscalización y los resultados de la clasificación anterior, es decir, cada área deberá dedicarse prioritariamente a algunos de los temas aquí planteados, no necesariamente a todos. • Seguimiento de disposiciones como elemento esencial para ir midiendo el impacto de nuestra gestión. • Elaboración de indicadores sencillos para medir los resultados propuestos en el plan de trabajo. • Ejecución efectiva de la agenda de mejoras internas, ya que los proyectos que se definan darán el salto cualitativo que la institución requiere para tener un nivel mayor de incidencia en la gestión de las administraciones públicas. • Recurso humano y tecnología. En relación con las personas, éstas deben ser capaces, si existe una brecha frente a las necesidades de los procesos de trabajo, esta debe cerrarse por medio de capacitación u otras acciones que les permitan desarrollar mejor sus competencias. El gerente tiene una responsabilidad importante en materia de recurso humano, tiene una responsabilidad en forma directa e inmediata en su manejo, buscando el equilibrio para lograr un desarrollo integral de la gente y hacer converger los objetivos de las personas con los de la institución. Por su parte, la tecnología es fundamental para apoyar el trabajo no solo en la simplificación sino también siendo utilizada para almacenar y proporcionar información que apoye la toma de decisiones. • Medición del desempeño en función de resultados. Hay que darle un cambio a la evaluación del desempeño. Debe verse como una retroalimentación. Esta debe asociarse al logro de los objetivos de la unidad, más los compromisos personales. Es una evaluación asociada con resultados de proyectos tangibles.


Estos lineamientos contribuirán a la organización del trabajo y a la formulación de los planes de trabajo operativos de los próximos años de las diferentes Divisiones, Áreas y Unidades de la Contraloría General, base fundamental sobre la cual, rendiremos cuentas a la ciudadanía. De acuerdo con sanas prácticas de gestión, todo plan institucional en la Contraloría General, debe estar directamente relacionado con los objetivos estratégicos, estrategias, factores clave de éxito y las orientaciones del Plan Estratégico Institucional 20082012, de ahí que el plan estratégico en tecnologías de información y comunicación (PETIC) no es una excepción, en este sentido, la gestión institucional de tecnologías de información y comunicación para el período 2008-2012, se debe realizar de acuerdo con las siguientes orientaciones estratégicas: a. Control como medio y no como fin b. No afectación del interés público c. No coadministrar d. Mayor proactividad, presencia, impacto y oportunidad e. Enfoque preventivo f. Énfasis en los resultados de la gestión pública g. Fiscalización y control sobre una base costo-beneficio h. Aplicación de procesos con base en el Manual General de la Fiscalización Integral i. Cultura de medición continua de la gestión j. Mejora continua que fortalezca la autocrítica constructiva Con base a las orientaciones estratégicas se pueden observar posibles riesgos financieros, sociales, operativos, técnicos, legales, y humanos, sobre los cuales vamos a estar trabajando en el presente análisis y valoración de riesgos, siempre que estén relacionados con tecnologías de información.


Factores claves de éxito El cumplimiento de la estrategia institucional 2008-2012 está en función de lograr la articulación de esfuerzos institucionales alrededor de los siguientes elementos: a. Desarrollo de las competencias de los funcionarios ajustadas a los requerimientos de la CGR para enfrentar el entorno b. Aprovechamiento de las tecnologías de información en las fiscalización y la toma de decisiones c. Integración institucional que facilite la toma de decisiones y la consistencia de los productos de fiscalización.

Visión de la CGR Garantizamos a la sociedad costarricense, la vigilancia efectiva de la Hacienda Pública.

Misión de la CGR Somos el órgano constitucional, auxiliar de la Asamblea Legislativa que fiscaliza el uso de los fondos públicos para mejorar la gestión de la Hacienda Pública y contribuir al control político y ciudadano.

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: • Excelencia: Búsqueda de la máxima calidad y desempeño en el trabajo diario. • Respeto: Valorar los derechos y formar de pensar de los demás.


• 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. La CGR tiene cuatro macro procesos: a. Fiscalización Integral b. Gobierno Corporativo c. Gestión del Conocimiento d. Gestión del Recurso Humano La gestión de tecnologías de información apoya estos macro procesos con cuatro procesos:

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.

La Unidad de Tecnología de Información (UTI) El Reglamento Orgánico de la Contraloría General de la República, emitido mediante resolución No. R-CO-34-2009 del 22 de mayo de 2009, en su Capítulo II, Sección CUARTA, artículo 26, establece con respecto a la Unidad Tecnologías de Información:


Es la unidad encargada de implementar, desarrollar y evolucionar soluciones tecnológicas y de comunicación, para apoyar y facilitar la ejecución de los procesos internos Para ello lidera el proceso de gestión de tecnologías de información y comunicación y participa del proceso de asesoría interna en materia de su competencia.

Visión de la UTI Una Contraloría General posicionada y ampliamente digitalizada, con acceso inmediato a la información, con eficientes herramientas tecnológicas de apoyo para realizar fiscalización de la Hacienda Pública; todo con el objetivo de transparentar la gestión pública, fomentar la participación ciudadana, combatir la corrupción y apoyar el buen Gobierno.

Misión de la UTI Somos una Unidad especializada para brindar servicios oportunos en tecnologías de información y comunicación para fortalecer la fiscalización superior, la transparencia, la participación ciudadana, y la rendición de cuentas por medio de la gestión realizada en la Contraloría General.

Objetivos de la UTI Los siguientes son los objetivos estratégicos de la UTI: a. Contar con una infraestructura de Tecnologías de Información y Comunicaciones (TICs) estable y adecuada a las necesidades de la Institución y del país. b. Alinear la plataforma tecnológica hacia el logro de objetivos institucionales, integrada a procesos y actividades, y puesta al servicio de los usuarios internos y externos.


c. Desarrollar la infoestructura de soluciones y servicios definidos y priorizados en el Plan Institucional, en aras de impulsar la eficiencia, la eficacia, la transparencia, la participación ciudadana y el combatir de la corrupción. d. Fortalecer el Gobierno Electrónico mediante transparentar la gestión pública, la simplificación de procesos, la generación de trámites electrónicos y la participación ciudadana. e. Coordinar con el Centro de Capacitación, la capacitación de los funcionarios de la Contraloría General de la República y de otras instituciones para mejor uso y aprovechamiento de las TIC’s. f. Mantener una organización actualizada con las tendencias modernas de tecnologías de información y comunicaciones (TIC’s), y con los requerimientos de información y tecnología de la institución.

Contexto de la administración de riesgos La administración de riesgos se lleva a cabo considerando los procesos de USTI que están relacionados con las tecnologías de información y la Plan Estratégico 2008 – 2012, a efectos de establecer y fortalecimiento los controles necesarios en aquellos que así lo requieran. En la identificación de riesgos se consideran los efectos que una mala gestión pueda tener en la imagen de la CGR, las pérdidas producto de inversiones que no generen réditos, y las orientaciones estratégicas. 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.


La evaluación de riesgos se llevará a cabo sobre los procesos de la USTI: Infraestructura, Seguridad y Control, Suministro de Servicios, e Inserción tecnológica, basados en COBIT.


Portafolio de riesgos Marco de administración 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. La estrategia para la administración de los riesgos está basada en los siguientes aspectos: • 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.


El alcance de este ejercicio de análisis de riesgos comprende lo siguiente: • Actividades de gestión de la UTI las cuales están a cargo de la jefatura y de los coordinadores. • Procesos de la UTI que incluyen las operaciones continuas y el desarrollo de proyectos • Proyectos tecnológicos de trascendencia institucional lo cuales influyen en la imagen que se proyecta a la ciudadanía. • Riesgos relacionados con el recurso más importante de la organización: el recurso humano.

Criterios de evaluación de riesgos Para la evaluación de riesgos se utilizarán, como valores primarios, la calificación de impacto y probabilidad de cada riesgo. Para ambos casos se utilizarán tablas de 5 valores con las equivalencias que se señalan a continuación. A partir de esos valores se calculará el nivel de exposición y la severidad de los riesgos representándolos en el mapa térmico. 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.


Calificación de la probabilidad Para la calificar la probabilidad de los riesgos se utilizará una tabla de 5 valores:

P 5

4 3 2 1

Probabilidad Significado

Casi seguro Muy probable Probable Poco probable Raro

Calificación del impacto 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:

I 5

4 3 2 1

Impacto Significado

Mayor Importante Significativo Regular Menor

Severidad del riesgo 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:


Severidad Significado

S

4 3 2 1

Extrema Alta Moderada Baja

Mapa térmico En la siguiente tabla se presenta el modelo para el mapa térmico donde según la calificación de impacto y probabilidad el riesgo es calificado por corlo en su nivel de severidad. El corlo rojo representa severidad extrema, el color naranja severidad alta,

Impacto

el color amarillo claro severidad moderada y el color verde claro severidad baja:

5

M

A

E

E

E

4

M

A

A

E

E

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ías de los riesgos Las categorías utilizadas son las siguientes:

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.


Incumplimiento de directrices, procedimientos y Operación

metodologías y estándares en los procesos operativos de la UTI. Riesgos relacionados con las fallas potenciales de la

Infraestructura

infraestructura tecnológica utilizada en la CGR. Eventos que atentan contra la confidencialidad,

Seguridad

integridad y disponibilidad de la información. Relacionados con el desempeño y regularidad de los

Recurso humano

recursos humanos.

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.

Impacto de los riesgos según su categoría Gestión I Significado 5 Mayor 4

Importante

3

Significativo

2

Regular

1

Menor

Criterios de calificación Evento que impedirá el logro de los objetivos institucionales. El logro de objetivos institucionales se ve afectado de manera importante. Evento que representará un retraso significativo en el logro de objetivos institucionales. El evento afecta levemente el logro de objetivos de la UTI y de la CGR. Evento que afecta la gestión de la UTI sin llegar a impactar en el logro de los objetivos.


Operación I

Significado

5

Mayor

4 3

Importante Significativo

Criterios de calificación Evento que paraliza la prestación de servicios por parte de la unidad afectando a la institución de manera considerable. Evento que provoca la interrupción parcial de servicios. 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

1

Menor

respuesta que experimentan los usuarios. Evento que afecta sólo las operaciones de la UTI.

Infraestructura I

Significado

5

Mayor

4

Importante

3

Significativo

2

Regular

1

Menor

Criterios de calificación Falla severa en un componente vital de la infraestructura tecnológica que impide la operación normal de la institución. Falla en un componente de la infraestructura tecnológica que afecta parcialmente la prestación de servicios. Falla en un componente de la infraestructura tecnológica que afecta de manera intermitente la prestación de servicios. Falla en un equipo que afecta la prestación de servicios sólo en la UTI. Falla en un componente que puede ser sustituido de inmediato por mantener equipo similar en inventario. Se afecta la operación de la institución por minutos.

Seguridad I

5

Significado

Mayor

Criterios de calificación La seguridad es vulnerada y se desconocen sus efectos. Un ente no autorizado tiene acceso a información confidencial. Información total en la disponibilidad de información. Los datos institucionales han sido alterados.


Un ente no autorizado tiene acceso a información sensitiva. 4

Importante

Interrupción de más de 1 día hábil en la disponibilidad de la información. Se reciben ataques masivos sobre la plataforma. Un funcionario de la institución tiene acceso a información a la cual no está autorizado.

3

Significativo

Interrupción de 1 día hábil en la disponibilidad de la información. Pérdida de datos que se pueden restaurar por medio de los procesos de recuperación. Entes no autorizados tienen acceso a información parcial en

2

Regular

modo consulta. Interrupción de 4 horas en la disponibilidad de la información. Hay intentos de acceso a la información. Interrupción momentánea en la disponibilidad de la

1

Menor

información. Un ente no autorizado tiene la oportunidad de observar datos que se están utilizando en la operación de la institución.

Recurso humano (Revisar objetivos) I

Significado

Criterios de calificación Se prescinde de un funcionario importante para el logro de los objetivos.

5

Mayor

El evento imposibilita a todo el personal de la UTI para realizar sus funciones de manera indefinida. Evento que provoca que un funcionario exceda en más de un 40% el tiempo estimado para finalizar una actividad.


Los objetivos a lograr exceden las cargas de trabajo de los recursos asignados a la UTI. 4

Importante

Evento que imposibilita que el personal de la UTI pueda laborar durante un día hábil. Evento que provoca que un funcionario exceda en un 40% el tiempo estimado para finalizar una actividad. No se tiene participación del patrocinador para el logro de los objetivos.

3

Significativo

Evento que imposibilita a un funcionario de la UTI para laborar durante cinco días hábiles en el lapso de un mes. Situación que provoca que un funcionario exceda en un 20% el tiempo estimado para finalizar una actividad. Evento que provoca que un funcionario exceda en un 10% el tiempo estimado para finalizar una actividad.

2

Regular

Evento que afecta, de manera temporal y no mayor de 4 horas, que los funcionarios de la UTI puedan realizar sus funciones. Se asignan objetivos adicionales que afectan levemente la

1

Menor

carga de trabajo. Evento que imposibilita a un funcionario de la UTI para laborar durante un día hábil.

Criterios para la aceptación de riesgos 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.


Estructura de los riesgos 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.


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. El beneficio de utilizar los procesos de la UTI, como elemento central en la estructura de riesgos, es que se facilita el análisis y el diseño de posteriores planes de acción ya que en cada proceso se trabajará con un sub conjunto de riesgos lo que hace el ejercicio más manejable.

Identificación de riesgos La identificación de riesgos corresponde a la confección de una lista de los posibles eventos que pueden afectar las operaciones y los servicios ofrecidos por TI a la institución; para facilitar la posterior evaluación del riesgo en cuanto a su nivel de impacto se les asocia la categoría correspondiente: Id 1 2 3 4 5 6 7 8

9 10 11

Descripción del Riesgo Adquisición de soluciones automatizadas que no satisfagan las necesidades de la institución. Desarrollar productos que no

cumplen

especificaciones. Desarrollar productos

en

basados

con

las

requerimientos

incorrectos. Versiones de software desactualizadas. Adquirir software sin programas fuentes. Adquirir software que no tiene representación en el país. Equipo dañado no puede ser reparado. Red inalámbrica insegura. Daño físico en los equipos de la plataforma tecnológica. Obsolescencia de la infraestructura tecnológica. Desarrollo de sistemas y servicios que son difíciles de utilizar para el usuario.

Categoría Gestión Gestión Gestión Gestión Gestión Gestión Operación

Operación Operación Gestión Gestión


12 13 14 15 16 17 18 19 20 21 22 23

Gestión No existe guía de usuario para el uso del sistema. Gestión Retrasos en los procesos de contratación administrativa. Se adquiere equipo no compatible con la infraestructura

en uso. Se adquiere equipo sin que existan talleres para la

Gestión Gestión

reparación y mantenimiento de los mismos. Operación Trabajar directamente en equipos de producción. Versiones de software para desarrollo y producción diferentes. No contar con la metodología y procedimientos necesarios para la administración de los cambios. Libertad en el uso de componentes tecnológicos (software libre). Instalación de parches sin seguir las recomendaciones del proveedor. Ausencia de niveles de servicio aceptados que faciliten la gestión. Definición de niveles de servicio que sobrepasan la capacidad instalada de TI. No contar con los recursos necesarios para cumplir con los

Operación Operación Gestión Operación Gestión Gestión Gestión

24

niveles de servicio. Gestión No existe contrato de mantenimiento Debilidad en la administración de servicios de terceros

25

que implica que éstos no cumplan satisfactoriamente los Gestión

26 27 28

requerimientos del negocio. Gestión Incumplimiento de las políticas definidas por las partes. Operación Tiempo de respuesta degradado. No hacer planeamiento de la capacidad. Gestión Los recursos de la infraestructura tecnológica no son

29 30 31 32 33 34

suficientes para atender las demandas de servicios. Recuperación de software no es factible Suspensión de servicio de Internet Fallas en los equipos de comunicaciones Fallas en los servidores (computadores principales) Equipo de usuario final inseguro.

Gestión

Operación Infraestructura Infraestructura Infraestructura Seguridad


Ausencia de controles cruzados que comprueben la 35

36 37 38 39 40

41

integridad de la información y el funcionamiento correcto Seguridad de las aplicaciones. Errores en la creación de usuarios y en la asignación de privilegios de acceso. Sistemas sin mecanismos de trazabilidad de transacciones (pistas de auditoría). No se conocen los costos asignados a los servicios prestados por TI. No se cuenta con un proceso de análisis para mejorar los costos que están asociados a los servicios de TI. El personal no cuenta con el tiempo suficiente para recibir, de manera completa, la capacitación correspondiente. El personal no cuenta con las actitudes y aptitudes

Seguridad Seguridad Gestión Gestión Gestión

requeridas para hacer uso de la información por medio de RRHH las soluciones automatizadas. La capacitación que se brinda a los usuarios no es efectiva

42

43

44

45 46 47 48

para que puedan utilizar eficientemente los recursos Gestión informáticos disponibles. No se cuenta con presupuesto para diseñar e implementar programas de capacitación para los usuarios. No contar con una respuesta oportuna y efectiva para

Gestión

las consultas de los usuarios de TI y a la atención de los Operación incidentes. Las soluciones que se aplican, ante los incidentes reportados por los usuarios, no son efectivas. Los usuarios no están informados sobre los procedimientos que se deben seguir para reportar los incidentes. No se cuenta o no se aplica el procedimiento definido para la asignación, atención y seguimiento de los incidentes. No se realiza una adecuada gestión de métricas sobre los incidentes reportados y atendidos.

Operación Gestión Operación

Gestión


49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66

67

Se realizan cambios operativos que no se reflejan en la documentación. Se realizan cambios en la configuración de componentes de la infraestructura y no se reflejan en la documentación. No se conoce el impacto de hacer cambios en los componentes de la configuración. No se aplica el procedimiento oficializado para la gestión

Operación Operación Operación Operación

de problemas. No se documentan las soluciones aplicadas a los problemas. Operación Hay dificultad para definir el ámbito de acción de los proveedores para la solución de problemas. Alteración o pérdida de la información registrada en base

Gestión

Seguridad

de datos o equipos. Operación Información desactualizada o incorrecta. Seguridad Acceso no autorizado a la información. Instalaciones físicas mal diseñas que pongan en peligro la Gestión

integridad del equipo de cómputo y del personal. Seguridad Acceso no autorizado al centro de cómputo. Seguridad Ausencia de detectores de humo. Fallas en los equipos que mantienen el medio ambiente apropiado para la operación de TI (UPS, Aire acondicionado) No aplicación de las políticas para la generación de respaldos. No efectuar un monitoreo constante sobre la operación de la plataforma. Suspensión de servicios sin seguir el procedimiento establecido. No contar con un proceso para revisar periódicamente el

Infraestructura Operación Operación Operación Gestión

desempeño actual y la capacidad de los recursos de TI. Gestión No percibir los cambios que se realizan en el entorno. Utilización de indicadores sobre el desempeño de TI que no son relevantes y que no colaboran en la identificación de oportunidades de mejora en los procesos importantes de TI.

Gestión


No contar con un programa de control interno efectivo para 68

69 70 71 72 73

TI que incluya auto-evaluaciones y revisiones por parte de Gestión terceros. Gestión No contar con la documentación de los procesos de TI. Seguridad Uso de software no licenciado Exceder la cantidad de usuarios autorizados para utilizar un producto licenciado. Facilitar los medios para la instalación de software a terceros. Contar con un plan estratégico no alineado a la estrategia

Operación Operación Gestión

74

institucional. Gestión Se tiene Plan Estratégico desactualizado. No contar con un modelo de información del negocio que

75

sea utilizado en la creación y actualización de los sistemas Gestión

76

de información. Gestión Arquitectura de información desactualizada. Arquitectura de información no responde a la cadena de

77 78 79 80 81 82 83

84

85 86

valor. Adquisición de tecnologías que no aportan valor a la organización. Contar con equipo costoso que no cuenta con contratos de mantenimiento. No aplicación de los canales de comunicación establecidos

Gestión Gestión Gestión Gestión

para informar sobre la gestión de TI. No se tienen documentados los canales de comunicación. Gestión RRHH No se tiene dominio sobre las herramientas en uso. Equipo de trabajo con baja motivación, poco creativo y no comprometido con el logro de los objetivos. Contar con un sistema de administración de la calidad

RRHH

deficiente en la definición y aplicación de procesos y Operación procedimientos para el desarrollo de las TIC en la institución. Desarrollar productos que no cumplen con los requerimientos de calidad. No administrar los riesgos de TI.

Operación Gestión


87 88

89 90 91 92

93

94 95

Utilizar un marco de trabajo deficiente para la gestión de

Gestión

riesgos, y no alineado con el apetito del riesgo institucional. El personal no está capacitado adecuadamente para

Gestión

realizar una gestión efectiva de los riesgos. No contar con el contenido presupuestario para la ejecución

Gestión

de los proyectos. Gestión Inestabilidad en el equipo de proyecto. Gestión Desarrollo de proyectos no alineados al Plan Estratégico Gestión Los proyectos no están documentados No contar con un marco de referencia para la gestión de los proyectos en cuanto a su iniciación, planificación,

Gestión

ejecución, control y cierre, o aplicar ese marco de referencia deficientemente. Exceder el tiempo planificado para la ejecución de los

Gestión

proyectos. Falta de apoyo del patrocinador del proyecto.

Gestión

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

Descripción del riesgo Adquisición

1

de

Causas

soluciones

automatizadas que no satisfagan las necesidades de la institución.

2

Desarrollar

productos

que

Especificación requerimientos

no

adecuada.

No se validó el cumplimiento del producto. Errores

no analizar

cumplen con las especificaciones.

de

de

concepto

al

las

especificaciones

No se validaron los componentes del producto


3

4

Desarrollar productos basados en requerimientos incorrectos.

Versiones

de

Ausencia

de

de

validación requerimientos

Patrocinador sin compromiso No hay contrato de mantenimiento. software Personal

desactualizadas.

para

no

está

actualizar

capacitado

el

software.

No está planificada la actualización. Mala gestión en la 5

Adquirir software sin programas adquisición fuentes.

de

Adquisición

de

software software

es

imprescindible 6

Adquirir software que no tiene representación en el país.

No se tiene otra opción No hay contrato de mantenimiento.

7

Equipo

dañado

no

puede

reparado.

ser No se tienen repuestos en el país. 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

9

Daño físico en los equipos de la Alteración plataforma tecnológica.

Medio

tiene

Obsolescencia de la infraestructura para tecnológica.

sistema

ambiente

Sabotaje No se 10

del

eléctrico

no

apropiado

la

expertise actualizarla

Que no se renueven los contratos de mantenimiento


Desarrollo de sistemas y servicios 11

que son difíciles de utilizar para el usuario.

12 13

14

del sistema. Retrasos en

17

desarrollo

de

los

procesos

contratación administrativa. Se adquiere equipo no compatible con la infraestructura en uso.

talleres

para

la

reparación

para sistemas

No se piensa en las facilidades para su

elaboración

El sistema es muy simple de usar de Se apela el cartel o la adjudicación.

y

mantenimiento de los mismos.

16

compleja

el cliente No existe guía de usuario para el uso Se omitió

Se adquiere equipo sin que existan 15

Mentalidad

Negligencia administrativa. Elaboración especificaciones

Versiones de software para desarrollo y producción diferentes.

incorrectas

Aceptación de un modelo diferente No se solicita en las especificaciones

de

compra

El proveedor es representante único en el país Se obtuvieron

Trabajar directamente en equipos de del producción.

de

ambiente

de

passwords producción

Se autoriza realizar trabajo en este ambiente No se

han

actualizado

El soporte en Costa Rica no es el mejor

No contar con la metodología y 18

procedimientos necesarios para la No ha sido prioritario su desarrollo. administración de los cambios. No se respetan las políticas definidas

19

Libertad en el uso de componentes No se tienen las herramientas tecnológicos (software libre).

necesarias instalación

para

controlar

su


No 20

21

22

Instalación de parches sin seguir las los recomendaciones del proveedor.

control

parches

autorizados

No se revisa la documentación del

sobrepasan la capacidad instalada No se considera el recurso humano

contar

con

los

recursos

necesarios para cumplir con los niveles de servicio.

disponible Fallas de hardware y software superan Se

el

estimado

dañan

necesarias No se

26

herramientas

tiene

presupuesto.

No existe contrato de mantenimiento Se encuentra en periodo de garantía.

servicios de terceros que implica que responsables

definido

por

éstos no cumplan satisfactoriamente Administración

de

contrato. contratos

no

los requerimientos del negocio. adecuada. Incumplimiento de las políticas No se gestiona con base en las definidas por las partes.

políticas definidas Servidores d

27

realizado

las

Está en trámite. Debilidad en la administración de No se han 25

sobre

aceptados que faciliten la gestión. niveles. Definición de niveles de servicio que No se realiza el análisis de capacidades

No

24

tiene

proveedor Ausencia de niveles de servicio No hay acuerdos de servicios de

de TI.

23

se

Tiempo de respuesta degradado.

e

g

r

a

ocasionalmente d

a

d

o

s

Servidores ocasionalmente saturados Ataque a los componentes de la red Sistema consume muchos recursos (AB,CPU)


La 28

No

hacer

planeamiento

de

actividad

la del

capacidad.

no

plan

es

parte

de

gestión

No se tiene la capacidad para realizarlo No se planificaron las compras

Los recursos de la infraestructura con 29

base

tecnológica no son suficientes para de atender las demandas de servicios.

al

la

crecimiento infraestructura

Se da un crecimiento en recursos no planificado Procedimiento

30

Recuperación de software no es recuperación factible

incorrecto

No se cuenta con el recurso para recuperarlo Fallas en

31

para

Suspensión de servicio de Internet

el

proveedor

equipo

del

del

servicio

Se daño un componente interno Deficiencias en la administración Impericia humana

32

Fallas

en

los

equipos

comunicaciones

de Alteración Se

del

sistema

daño

eléctrico

el

equipo

Sabotaje Impericia 33

Fallas

en

los

servidores El

(computadores principales)

Se

humana

equipo alteró

se la

daño

configuración

Alteración del sistema eléctrico Se libera el equipo de algunas políticas 34

Equipo de usuario final inseguro.

se

de

trasladan

seguridad a

una

cuando

Institución

La instalación de componentes no es controlada en algunos casos


Ausencia de controles cruzados 35

que comprueben la integridad de la información y el funcionamiento correcto de las aplicaciones. Errores en la creación de usuarios

36

y en la asignación de privilegios de acceso. Sistemas

37

38

39

40

sin

mecanismos

No

se

Los

controles

programaron programados

son

débiles No

se

tiene

el

conocimiento

necesario para realizar la función Se desconoce la cobertura autorizada

para cada privilegio de No se realizaron

las

pruebas

trazabilidad de transacciones (pistas completas sobre el sistema que se de auditoría). puso en producción No se conocen los costos asignados No se tiene un modelo de costos a los servicios prestados por TI. No se maneja contabilidad de costos No se cuenta con un proceso de No se tienen los insumos necesarios análisis para mejorar los costos que No ha sido prioritario están asociados a los servicios de TI. El personal no cuenta con el Las cargas de trabajo tiempo suficiente para recibir, de no

están

balanceadas

manera completa, la capacitación No se tiene un plan de capacitación correspondiente. autorizado El personal no cuenta con las actitudes y aptitudes requeridas

41

para hacer uso de la información por

medio

de

las

soluciones

automatizadas. La capacitación que se brinda a los 42

usuarios no es efectiva para que puedan utilizar eficientemente los recursos informáticos disponibles.

La utilización del sistema es compleja No se tiene cultura informatizada

El instructor no tiene facilidad para la transferencia de conocimientos La capacitación no fue práctica


43

44

45

46

47

No se cuenta con presupuesto para No

se

diseñar e implementar programas las

partidas

presupuestaron necesarias

de capacitación para los usuarios. Se recortó la partida presupuestaria No contar con una respuesta Personal no capacitado. oportuna y efectiva para las consultas Desinterés por el usuario final. de los usuarios de TI y a la atención Saturación de consultas. de los incidentes. No se aprueba la solución Las soluciones que se aplican, ante por parte del usuario los incidentes reportados por los El técnico carece del conocimiento usuarios, no son efectivas. necesario No se han divulgado Los usuarios no están informados los procedimientos para sobre los procedimientos que se realizar los reportes deben seguir para reportar los Los usuarios han estado fuera de la incidentes. institución por meses No se cuenta o no se aplica el Se presentan solicitudes procedimiento

definido

para

la de

un

nivel

superior

asignación, atención y seguimiento Se atienden incidentes no registrados de los incidentes. en el sistema No se realiza una adecuada gestión El sistema no genera la información

48

de métricas sobre los incidentes necesaria para generar las métricas reportados y atendidos.

49

No se dispone del tiempo necesario No se tiene un sistema

Se realizan cambios operativos que para no se reflejan en la documentación.

control

de

cambios

Se realizan cambios sin que exista la documentación formal

Se 50

realizan

cambios

en

la

configuración de componentes de la infraestructura y no se reflejan en la documentación.

Los cambios se realizan bajo presión No existe un sistema para control de cambios


No se conoce el impacto de hacer 51

cambios en los componentes de la configuración.

No se tiene el ambiente completo para

pruebas

Urgía

la

preliminares

corrección

de

la

configuración No se aplica el procedimiento Se brindan soluciones sin que 52

oficializado

para

la

gestión

de se realice la gestión requerida

problemas.

53

Urge la solución del problema No es costumbre

No se documentan las soluciones informático aplicadas a los problemas.

de acción de los proveedores para la solución de problemas.

Alteración 55

o

pérdida

realizarlo

No se aplican sanciones por la

Hay dificultad para definir el ámbito 54

del

de

omisión No se

definieron

reglas

contractuales

claras

Los proveedores se trasladan el problema Violación

de

la

la Programa

con

fallas

seguridad de

lógica

información registrada en base de Recuperación de la base de datos datos o equipos.

con un respaldo desactualizado Fallas en disco no perceptibles Registro de datos incorrecta

56

57

Información

desactualizada

o Falla

incorrecta.

Acceso

no

en

el

Webservices

Desconocimiento del sistema por

autorizado

a

la

información.

parte del personal usuario Se comparte password

entre

el usuarios

Violación de la seguridad Instalaciones físicas mal diseñas que Estructura vieja no pensada para TI. 58

pongan en peligro la integridad del No equipo de cómputo y del personal.

es

importante

administración.

para

la


59

60

61

Acceso no autorizado al centro de cómputo. Ausencia de detectores de humo.

63

64

el

medio

ambiente

de otros No se tiene el presupuesto necesario

para la operación de TI (UPS, Aire Suministro

generación de respaldos.

No efectuar un monitoreo constante sobre la operación de la plataforma. Suspensión de servicios sin seguir el procedimiento establecido.

periódicamente el desempeño actual

energía

eléctrica

cintas

para

inapropiado Falta de los

respaldos

Daño en los equipos para toma de respaldos Exceso de estabilidad

seguridad de

la

por

plataforma

No se tienen todas las herramientas Iniciativas para suspensión de

servicios

sin

colegiarlas

La suspensión es urgente No existe sistema para evaluación del desempeño. Modificaciones

No percibir los cambios que se inciden realizan en el entorno.

de

preventivo

de

No aplicación de las políticas para la generar

y la capacidad de los recursos de TI.

66

contrato

apropiado mantenimiento

No contar con un proceso para revisar 65

Personal autorizado facilita el ingreso

para comprarlo Fallas en los equipos que mantienen No existe

acondicionado)

62

Administrador del CC lo permite

en

legales el

que

desarrollo

Cambios tecnológicos en el entorno que afectan el desarrollo


Utilización de indicadores sobre el desempeño de TI que no son 67

relevantes y que no colaboran en la No se realizó un análisis de los identificación de oportunidades de indicadores que se requieren en TI mejora en los procesos importantes de TI. No contar con un programa de

68

control interno efectivo para TI que incluya auto-evaluaciones y revisiones por parte de terceros.

69

70

No contar con la documentación de los procesos de TI.

No

se

tienen

directrices

No hay planificación para llevar a cabo el auto control La documentación no fue actualizada No se tiene manual para Gobierno Corporativo En equipo de usuario final las

Uso de software no licenciado

políticas

no

estaban

aplicadas

Se emite una autorización temporal

para pruebas Exceder la cantidad de usuarios El software permite exceder la cantidad 71

autorizados para utilizar un producto No se tiene control sobre los usuarios licenciado.

72

73

74

Facilitar los medios para la instalación de software a terceros.

instalados Se violó la seguridad para trasladar medios de instalación de software Desconocimiento contractual Se modifica la estrategia

Contar con un plan estratégico no y

no

se

comunica

alineado a la estrategia institucional. Se desarrollan sistemas que no Se

tiene

desactualizado.

Plan

responden a la estrategia institucional Estratégico No se tiene un administrador del PETIC.


No contar con un modelo de información 75

del

negocio

que

sea utilizado en la creación y actualización de los sistemas de

76

77

información. Arquitectura

de

No se tienen los recursos para elaborarlo

información No se tiene un administrador de la

desactualizada.

arquitectura No se diseño

Arquitectura de información no responde a la cadena de valor.

de a

la

información la

arquitectura con

base

de

valor

cadena

Se construyó primero la arquitectura de información Se instalan

78

Adquisición de tecnologías que no con aportan valor a la organización.

no

cuenta

con

contratos

de

mantenimiento. No aplicación de los canales de 80

comunicación

establecidos

para

informar sobre la gestión de TI.

81

82

adquirido Se venció se

tiene

contratar

convenios

canales de comunicación.

No se tiene dominio sobre las

la

garantía

Facilidad

y

presupuesto el

de

no para

mantenimiento

No se autoriza el gasto Problemas de

gestión

canales

de

comunicación no incluidos en los canales formales Funcionan muy

No se tienen documentados los los

herramientas en uso.

a

Se incluyen como parte del software

Contar con equipo costoso que 79

base

tecnologías

canales

bien informales

No se han documentado los canales informales El personal no fue capacitado La

transferencia

funcionó

tecnológica

no


Equipo 83

de

trabajo

baja

motivación, poco creativo y no Clima

laboral

no

adecuado

comprometido con el logro de los Se desconocen los objetivos objetivos. Contar con

un

administración 84

con

sistema

de

la

de

calidad Falta

de

experiencia

deficiente en la definición y aplicación administración de

procesos

y

de

la

en

la

calidad

procedimientos No existe existen directrices para

para el desarrollo de las TIC en la administrar la calidad institución. Desarrollar 85

productos

que

cumplen con los requerimientos de calidad.

86

88

89

90

Ausencia

de

de

validación requerimientos

Omisión de pruebas de calidad Incumplimiento de plan de calidad No existe la administración

No administrar los riesgos de TI. Utilizar

87

no

un

marco

de

basada

en

riesgos

No se tienen los recursos necesarios trabajo No se ha brindado la

deficiente para la gestión de riesgos, capacitación

necesaria.

y no alineado con el apetito del riesgo No existe la administración basada institucional. en riesgos. El personal no está capacitado No se ha brindado la capacitación adecuadamente para realizar una necesaria. gestión efectiva de los riesgos. Elaboración de No contar con el contenido presupuesto incorrecto. presupuestario para la ejecución de No presupuestar proyectos. los proyectos. Recorte presupuestario. Inestabilidad en el equipo de Reducción de personal. proyecto.

Clima laboral inadecuado.


Aceptar proyecto que no han sido 91

92

Desarrollo de proyectos no alineados al Plan Estratégico

Los

proyectos

contar

D e s c o n o c i m i e n t o del

no

están

documentados No

validados contra el Plan Estratégico. Plan

Estratégico.

Es obligatorio desarrollarlo. El personal omite la documentación La

documentación

existente

es

omisa

con

un

marco

de

referencia para la gestión de los 93

proyectos en cuanto a su iniciación, No hay metodología oficial para la planificación,

ejecución,

control gestión de proyectos.

y cierre, o aplicar ese marco de referencia deficientemente. 94

95

Exceder el tiempo planificado para la ejecución de los proyectos.

Planificación

no

adecuada

Modificación en los requerimientos Reducción de recursos

Falta de apoyo del patrocinador del No se tiene interés en el proyecto proyecto.

No hay personal disponible

Evaluación de riesgos Evaluación de riesgos absolutos La primera evaluación corresponde a los riesgos absolutos, es decir, valorar el nivel de severidad de cada riesgo sin tomar en cuenta el efecto de los controles que se aplican actualmente. Como fue definido anteriormente, la calificación se realiza utilizando dos criterios primarios que son la probabilidad (P) y el impacto (I) de cada riesgo, de esto valores


se deriva el nivel de exposición (P * I) y la severidad de los riesgos (se utiliza la escala de colores del mapa térmico para su representación): Id 1 2 3 4 5 6 7 8 9 10 11 12

13 14 15 16 17 18 19 20 21

Riesgo Adquisición de soluciones automatizadas que no satisfagan las necesidades de la institución. Desarrollar productos que no

cumplen

con

las

especificaciones. Desarrollar productos basados en requerimientos incorrectos. Versiones de software desactualizadas. Adquirir software sin programas fuentes. Adquirir software que no tiene representación en el país. Equipo dañado no puede ser reparado. Red inalámbrica insegura. Daño físico en los equipos de la plataforma tecnológica. Obsolescencia de la infraestructura tecnológica. Desarrollo de sistemas y servicios que son difíciles de utilizar para el usuario. No existe guía de usuario para el uso del sistema. Retrasos en los procesos de contratación administrativa. Se adquiere equipo no compatible con la infraestructura en uso. Se adquiere equipo sin que existan talleres para la reparación y mantenimiento de los mismos. Trabajar directamente en equipos de producción. Versiones de software para desarrollo y producción diferentes. No contar con la metodología y procedimientos necesarios para la administración de los cambios. Libertad en el uso de componentes tecnológicos (software libre). Instalación de parches sin seguir las recomendaciones del proveedor. Ausencia de niveles de servicio aceptados que faciliten la gestión.

P

I

S

3

3

9

2

4

8

2 3 1 1 3 5 3 3

4 4 4 4 3 5 4 4

8 12 4 4 9 25 12 12

3

3

9

3

3

9

3

3

9

2

3

6

4

3

12

3 4

4 4

12 16

3

4

12

3

3

9

3

3

9

3

3

9


22 23

Definición de niveles de servicio que sobrepasan la capacidad instalada de TI. No contar con los recursos necesarios para cumplir con los

2

3

6

2

3

6

3

4

12

24

niveles de servicio. No existe contrato de mantenimiento Debilidad en la administración de servicios de terceros

25

que implica que éstos no cumplan satisfactoriamente los

3

3

9

26 27 28

requerimientos del negocio. Incumplimiento de las políticas definidas por las partes. Tiempo de respuesta degradado. No hacer planeamiento de la capacidad. Los recursos de la infraestructura tecnológica no son

3 3 3

3 3 3

9 9 9

3

4

12

29 30 31 32

33 34 35

36 37 38 39 40

41

suficientes para atender las demandas de servicios. Recuperación de software no es factible Suspensión de servicio de Internet Fallas en los equipos de comunicaciones Fallas en los servidores (computadores principales) Equipo de usuario final inseguro. Ausencia de controles cruzados que comprueben la

2 3

4 4

8 12

2

5

10

2 4

5 3

10 12

integridad de la información y el funcionamiento correcto de

2

4

8

3

4

12

3

4

12

3

3

9

3

3

9

2

3

6

2

3

6

las aplicaciones. Errores en la creación de usuarios y en la asignación de privilegios de acceso. Sistemas sin mecanismos de trazabilidad de transacciones (pistas de auditoría). No se conocen los costos asignados a los servicios prestados por TI. No se cuenta con un proceso de análisis para mejorar los costos que están asociados a los servicios de TI. El personal no cuenta con el tiempo suficiente para recibir, de manera completa, la capacitación correspondiente. El personal no cuenta con las actitudes y aptitudes requeridas para hacer uso de la información por medio de las soluciones automatizadas.


La capacitación que se brinda a los usuarios no es efectiva 42

43

44

45 46 47 48 49 50 51 52

53 54 55 56 57 58 59

para que puedan utilizar eficientemente los recursos informáticos disponibles. No se cuenta con presupuesto para diseñar e implementar programas de capacitación para los usuarios. No contar con una respuesta oportuna y efectiva para las consultas de los usuarios de TI y a la atención de los incidentes. Las soluciones que se aplican, ante los incidentes reportados por los usuarios, no son efectivas. Los usuarios no están informados sobre los procedimientos que se deben seguir para reportar los incidentes. No se cuenta o no se aplica el procedimiento definido para la asignación, atención y seguimiento de los incidentes. No se realiza una adecuada gestión de métricas sobre los incidentes reportados y atendidos. Se realizan cambios operativos que no se reflejan en la documentación. Se realizan cambios en la configuración de componentes de la infraestructura y no se reflejan en la documentación. No se conoce el impacto de hacer cambios en los componentes de la configuración. No se aplica el procedimiento oficializado para la gestión de problemas. No se documentan las soluciones aplicadas a los problemas. Hay dificultad para definir el ámbito de acción de los proveedores para la solución de problemas. Alteración o pérdida de la información registrada en base de datos o equipos. Información desactualizada o incorrecta. Acceso no autorizado a la información. Instalaciones físicas mal diseñas que pongan en peligro la integridad del equipo de cómputo y del personal. Acceso no autorizado al centro de cómputo.

2

2

4

2

3

6

3

3

9

2

4

8

2

3

6

2

3

6

3

3

9

3

4

12

3

4

12

3

4

12

3

3

9

4

5

20

2

3

6

2

4

8

3 3

4 5

12 15

2

3

6

3

3

9


60 61 62 63 64 65

Ausencia de detectores de humo. Fallas en los equipos que mantienen el medio ambiente apropiado para la operación de TI (UPS, Aire acondicionado) No aplicación de las políticas para la generación de respaldos. No efectuar un monitoreo constante sobre la operación de la plataforma. Suspensión de servicios sin seguir el procedimiento establecido. No contar con un proceso para revisar periódicamente el

66

desempeño actual y la capacidad de los recursos de TI. No percibir los cambios que se realizan en el entorno. Utilización de indicadores sobre el desempeño de TI que

67

no son relevantes y que no colaboran en la identificación de

3

3

9

3

5

15

3

4

12

3

3

9

3

3

9

3

3

9

2

3

6

3

4

12

oportunidades de mejora en los procesos importantes de TI. No contar con un programa de control interno efectivo para 68

TI que incluya auto-evaluaciones y revisiones por parte de

2

3

6

69 70

terceros. No contar con la documentación de los procesos de TI. Uso de software no licenciado Exceder la cantidad de usuarios autorizados para utilizar un

2 2

3 3

6 6

producto licenciado. Facilitar los medios para la instalación de software a terceros. Contar con un plan estratégico no alineado a la estrategia

2

3

6

3

3

9

4

4

16

74

institucional. Se tiene Plan Estratégico desactualizado. No contar con un modelo de información del negocio que

4

4

16

75

sea utilizado en la creación y actualización de los sistemas

3

3

9

76

de información. Arquitectura de información desactualizada. Arquitectura de información no responde a la cadena de

3

4

12

2

3

6

2

3

6

71 72

73

77 78

valor. Adquisición de tecnologías que no aportan valor a la organización.


79 80 81 82 83

84

85 86 87 88 89 90 91 92

93

94 95

Contar con equipo costoso que no cuenta con contratos de mantenimiento. No aplicación de los canales de comunicación establecidos para informar sobre la gestión de TI. No se tienen documentados los canales de comunicación. No se tiene dominio sobre las herramientas en uso. Equipo de trabajo con baja motivación, poco creativo y no comprometido con el logro de los objetivos. Contar con un sistema de administración de la calidad deficiente en la definición y aplicación de procesos y procedimientos para el desarrollo de las TIC en la institución. Desarrollar productos que no cumplen con los requerimientos de calidad. No administrar los riesgos de TI. Utilizar un marco de trabajo deficiente para la gestión de riesgos, y no alineado con el apetito del riesgo institucional. El personal no está capacitado adecuadamente para realizar una gestión efectiva de los riesgos. No contar con el contenido presupuestario para la ejecución de los proyectos. Inestabilidad en el equipo de proyecto. Desarrollo de proyectos no alineados al Plan Estratégico Los proyectos no están documentados No contar con un marco de referencia para la gestión de los proyectos en cuanto a su iniciación, planificación, ejecución, control y cierre, o aplicar ese marco de referencia deficientemente. Exceder el tiempo planificado para la ejecución de los proyectos. Falta de apoyo del patrocinador del proyecto.

P = Probabilidad, I = Impacto, S = Severidad

2

3

6

2

2

4

2 3

2 4

4 12

3

4

12

4

4

16

3

3

9

4

4

16

4

4

16

3

3

9

2

5

10

2 4

3 3

6 12

4

4

16

4

4

16

4

3

12

4

4

16


Mapas térmicos riesgos absolutos Infraestructura 5

32, 33 31,

4

Impacto

61 49,

50, 51

3

14

7, 27

10

2 1 1

2

3

Probabilidad

4

5


Seguridad y control 5

Impacto

4

5, 6,

3

57

53

30, 35, 55

4, 9, 18, 36, 37, 56, 62

17, 84, 86, 87

47, 54, 58, 68, 70, 71

16, 19, 20, 26, 52, 59, 60, 63, 72,

15, 34

2

3

4

8

2

1 1

5

Probabilidad Suministro de servicios 5

Impacto

4 3 2

45

29, 82, 83

23, 40, 41,

11, 12, 21,

43, 46

38, 44, 64

92, 93

94

42

1 1

2

3

Probabilidad

4

5


Impacto

Inserción tecnológica (Gestión) 5

89

4

2, 3,

67, 76

22, 66, 69,

1, 13, 25,

77, 78, 79,

28, 39, 48,

3 2

73, 74,95

91,

81

1 1

2

3

4

5

Probabilidad Identificación de controles Id

Descripción del riesgo Adquisición

1

de

Controles Se realiza un diagnóstico sobre

soluciones las

automatizadas que no satisfagan de las necesidades de la institución.

necesidades

y

factibilidad

adquirir

la

solución.

Se le da participación del usuario para validar las necesidades. Pruebas de productos

2

Desarrollar

productos

que

no basadas

cumplen con las especificaciones.

en

casos

de

uso.

Aprobación de fases de análisis y diseño para comprobar el alcance.


Utilizar 3

casos

Desarrollar productos basados en especificar requerimientos incorrectos.

de

los

uso

para

requerimientos.

Validación y aprobación de los requerimientos por el patrocinador. Por medio de los contratos de mantenimiento

4

Versiones

de

software

desactualizadas.

se

planifican

y

aplican actualizaciones del software. Se

estableció

que

todos

la

los

directriz equipos

para estén

estandarizados en cuanto a las

5

6

7

8

Adquirir software sin programas fuentes.

versiones del software. Como parte de los carteles de licitación se solicitan todos los programas fuente. La presentación del software en el

Adquirir software que no tiene país es requisito de admisibilidad representación en el país.

Equipo dañado no puede ser reparado.

Red inalámbrica insegura.

de los procesos de contratación administrativa. Mantener vigentes los contratos de mantenimiento para los equipos. Contar con equipos de respaldos. Se utiliza un esquema de seguridad

para

acceso

la

a

restringir

red

el

inalámbrica.

La red inalámbrica existente entre el estacionamiento y el edificio principal está totalmente separada de la red institucional.


Se cuenta con planta de diesel y UPS. Está restringido el acceso al Centro 9

Daño físico en los equipos de la de Cómputo. Se ha dispuesto una plataforma tecnológica.

cámara de seguridad en la puerta. Se

cuenta

con

sensores

de

temperatura y humedad. Plan de renovación y fortalecimiento 10

Obsolescencia de la infraestructura de la infraestructura tecnológica. tecnológica.

Planificación de adquisiciones con

Desarrollo de sistemas y servicios 11

que son difíciles de utilizar para el usuario.

12

13

14

los

productos

constante

de

desarrollados.

Revisiones de los productos por parte de los clientes. Se incluye información en línea para

No existe guía de usuario para el uso del sistema.

Retrasos

anticipación. Supervisión

en

cada opción del sistema de modo que el usuario no necesite el manual. Se desarrollan tutores virtuales sobre

los

procesos

contratación administrativa.

de

la utilización de los sistemas. Se revisan previamente los carteles para validar que estén redactados

de forma clara y precisa. Se adquiere equipo no compatible Revisión de los carteles. Adquisición con la infraestructura en uso.

de tecnología de arquitectura abierta. Es un requisito de admisibilidad,

Se adquiere equipo sin que existan dentro de los procedimientos de 15

talleres

para

la

reparación

mantenimiento de los mismos.

y contratación administrativa, que los potenciales oferentes cuenten con el respectivo taller de servicio.


Se 16

17

Trabajar directamente en equipos de producción.

Versiones

de

cuenta

servidor

de

desarrollo.

puesta en producción de los nuevos

software

para

desarrollo y producción diferentes.

programas. Aplicación del procedimiento para la puesta en producción de los programas nuevos y modificados. Se han definido y

funciones.

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 políticas

19

un

Aplicación del procedimiento para la

No contar con la metodología y responsabilidades 18

con

Libertad en el uso de componentes el tecnológicos (software libre).

y

uso

institucionales de

estándar

de sobre

software

autorizado

para

institución.

la

Los perfiles de usuario no tienen autorización para instalar software. Se revisan las indicaciones 20

Instalación de parches sin seguir las de recomendaciones del proveedor.

los

proveedores.

Los parches se aplican primero en equipo de prueba. Se utiliza un software para gestionar

21

Ausencia de niveles de servicio las solicitudes de servicio pero los aceptados que faciliten la gestión.

tiempos de respuesta esperados no están acordados.


Análisis del PAO y portafolio de Definición de niveles de servicio que proyecto en conjunto con la Gerencia 22

sobrepasan la capacidad instalada de División tomando en cuenta de TI. No

23

contar

las cargas de trabajo y el personal con

los

actual. recursos Se cuenta con equipo renovado

necesarios para cumplir con los que presenta niveles aceptables de niveles de servicio.

estabilidad. Desarrollo periódico del Diagnóstico de Necesidades de Capacitación (DNC).

24

No existe contrato de mantenimiento Ejecución

del

programa

de

capacitación (de acuerdo con el

Debilidad en la administración de 25

servicios de terceros que implica que éstos no cumplan satisfactoriamente los requerimientos del negocio.

26

Incumplimiento de las políticas definidas por las partes.

disponible presupuestario). En el área de infraestructura se realiza un seguimiento periódico de

los

contratos

el

cumplimiento

Tiempo de respuesta degradado.

de

validar derechos

adquiridos por la institución. Se analizan las cláusulas de los contratos y se giran las instrucciones del caso. Monitoreo de los servicios para determinar

27

para

cargas

de

trabajo.

Balanceo de cargas de trabajo (distribución de funciones entre los servidores).


Antes

de

liberar

un

nuevo

servicio se realizan proyecciones sobre

las

requeridas 28

capacidades y

disponibles.

No hacer planeamiento de la Una vez al año se realiza un ejercicio capacidad.

para valorar la capacidad instalada y

las

proyecciones

de

nuevos

requerimientos; esto se hace como insumo para el Plan de Compras

Los recursos de la infraestructura 29

tecnológica no son suficientes para atender las demandas de servicios.

30

Institucional. Se planifica tecnología

la

adquisición

de

para

mantener

la

capacidad de procesamiento de información. Revisión de los respaldos generados.

Recuperación de software no es Se cuenta con equipos que se factible

pueden utilizar, ante contingencias, para reestablecer los servicios. Se cuenta con una red moderna

31

Suspensión de servicio de Internet

que da estabilidad en la operación interna. Contratos

32

Fallas

en

los

equipos

comunicaciones

de

mantenimiento.

de Equipo de contingencia y aplicación de respaldos de acuerdo con las políticas definidas. Contratos de mantenimiento.

33

Fallas

en

los

servidores Equipo de contingencia y aplicación

(computadores principales)

de respaldos de acuerdo con las políticas definidas.


Aplicación políticas

34

de

de

seguridad

por

medio

de

Active

Directory.

Perfiles

de

usuarios

limitados

software

y

para

Equipo de usuario final inseguro.

automática

instalar

modificaciones

en

el

hacer 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 35

que comprueben la integridad de la información y el funcionamiento correcto de las aplicaciones.

Por medio del Centro de Operaciones se revisa la calidad de la información en sistemas clave. El personal que tiene a cargo la

Errores en la creación de usuarios 36

y en la asignación de privilegios de acceso.

Sistemas 37

trazabilidad

capacitado para estas funciones. Como

parte

del

desarrollo

de

proyectos se deben definir los roles sin

mecanismos de

y una descripción. de Se ha definido la utilización de pistas

transacciones como parte de los estándares de

(pistas de auditoría).

38

implementación de la seguridad está

programación. Se utiliza el LogMiner. Se debe mejorar el registro de costos

No se conocen los costos asignados asociados a cada servicio para 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 39

análisis para mejorar los costos que asociados a cada servicio para están asociados a los servicios de contar con información precisa en TI.

este sentido.


El personal no cuenta con el Se informa con anticipación a las 40

41

tiempo suficiente para recibir, de jefaturas sobre las actividades de manera completa, la capacitación capacitación para que se tome en correspondiente. cuenta en la asignación de trabajos. El personal no cuenta con las Periódicamente, por medio del actitudes y aptitudes requeridas Centro de Capacitación, se realizan para hacer uso de la información charlas para fomentar la cultura por medio de las soluciones informática en la institución. automatizadas. Se preparan guías para la La capacitación que se brinda a los

42

usuarios no es efectiva para que puedan utilizar eficientemente los recursos informáticos disponibles.

capacitación que sirva de apoyo a los estudiantes e instructores. Se

preparan

Se

seleccionan

tutores los

virtuales. instructores

buscando personal con facilidad de expresión. Se está fomentando el uso de

No se cuenta con presupuesto para capacitación virtual que reduce 43

diseñar e implementar programas significativamente los costos. Para de capacitación para los usuarios.

esto se ha equipado al Centro de Capacitación. Utilización de un software para

No contar con una respuesta 44

oportuna

y

efectiva

para

las

consultas de los usuarios de TI y a la atención de los incidentes.

automatizar

la

presentación

de

los incidentes, la asignación y el

seguimiento

correspondiente.

Manejo de niveles de prioridad por procesos y usuarios críticos para la institución.


Se da capacitación a los técnicos Las soluciones que se aplican, ante en 45

Los usuarios no están informados sobre los procedimientos que se deben seguir para reportar los incidentes.

No se cuenta o no se aplica el 47

procedimiento definido para la asignación, atención y seguimiento de los incidentes.

No se realiza una adecuada gestión 48

de métricas sobre los incidentes reportados y atendidos.

49

nuevos

productos.

los incidentes reportados por los Se solicita al usuario que firme usuarios, no son efectivas.

46

los

la solicitud de servicio cuando el trabajo está concluido. Por medio del correo electrónico frecuentemente se envían mensajes a los funcionarios recordándoles políticas y procedimientos en materia de TI. Se cuenta para El

con

gestionar

personal

las

de

instrucciones procedimiento. un

un

funcionario

la

claras Se

software solicitudes.

USTI sobre cuenta

responsable

tiene el con del

seguimiento. Se aplican encuestas a los usuarios para conocer su nivel de satisfacción y sus recomendaciones para mejorar el servicio prestado. Documentación

Se realizan cambios operativos que procesos

de

los

operativos.

no se reflejan en la documentación. Actualización de guías de trabajo cuando se realizan cambios.


Se implementó una bitácora donde Se 50

realizan

cambios

en

la

configuración de componentes de la infraestructura y no se reflejan en la documentación.

realizados en la configuración de TI. Parte del procedimiento, para la aplicación de los cambios, es la actualización de la documentación

No se conoce el impacto de hacer 51

se registran todos los cambios

cambios en los componentes de la configuración.

correspondiente. Se tiene documentada la relación de componentes de TI necesarios para la implementación y funcionamiento

de los servicios clave. No se aplica el procedimiento Se tiene que oficializar y aplicar

52

oficializado para la gestión de el proceso para la gestión de problemas.

53

No se documentan las soluciones aplicadas a los problemas. Hay dificultad para definir el ámbito

54

de acción de los proveedores para la solución de problemas.

problemas. Se está elaborando el documento para la documentación, el proveedor si lo realiza por obligación contractual Se especifica claramente, en los carteles de los procedimientos, las responsabilidades de los proveedores y los servicios requeridos. Periódicamente revisan

Alteración 55

o

pérdida

de

la

información registrada en base de datos o equipos.

los

se respaldos.

Se tienen definidos roles de acceso por usuario y se revisa que no exista conflicto en los roles asignados. Se revisan los programas, con mucho detalle, antes de ponerlos en producción.


Se

revisa

del 56

Información

desactualizada

o

incorrecta.

Se de la

la

código creó la

generado.

una

CGR

gestión

de

calidad dependencia

especializada la

en

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

Acceso

no

autorizado

a

la

información.

Se

ha

esquema

implementado automático

para

un que

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

que pongan en peligro la integridad En el año 2005 se acondicionaron del equipo de cómputo y del los sitios de trabajo para tener más personal.

59

60

Acceso no autorizado al centro de cómputo. Ausencia de detectores de humo. Fallas en los equipos que mantienen

61

el medio ambiente apropiado para la operación de TI (UPS, Aire acondicionado)

visibilidad y fomentar el trabajo en equipo. Se cuenta con acceso restringido (por tarjeta) y cámaras de vigilancia. Se tiene una bitácora de acceso. Está pendiente por restricciones de presupuesto. Se han realizado revisiones de la instalación eléctrica. Se cuenta con planta y UPS.


Definición de 62

No aplicación de las políticas para la generación de respaldos.

de

contingencia

generación El

procedimiento para

de

personal

la

respaldos.

responsable

debe

informar cuando se presenta alguna dificultad en la generación de los respaldos. Se cuenta para

63

No efectuar un monitoreo constante Se

con

herramienta

monitorear cuenta

sobre la operación de la plataforma. monitorear

la

red.

con

software

los

servidores

para de

aplicaciones, bases de datos y sistemas. Bitácoras 64

Suspensión de servicios sin seguir el procedimiento establecido.

de

configuración de

servicios.

procedimientos

cambios y Se

en

la

suspensión han

definido

e

instruido

al

la

definición

y

personal. No 65

para

contar revisar

con

un

proceso

periódicamente

el

desempeño actual y la capacidad de los recursos de TI.

Está

pendiente

oficialización del procedimiento para realizar esta actividad. La

institución,

por

medio

de

Estrategia Institucional, mantiene 66

No percibir los cambios que se un monitoreo constante sobre los realizan en el entorno.

cambios en el entorno. Se encarga de reflejarlos en los planes de trabajo.


Utilización de indicadores sobre el desempeño de TI que no son 67

relevantes y que no colaboran en la Se debe mejorar la definición y identificación de oportunidades de análisis de indicadores de TI. mejora en los procesos importantes de TI. No contar con un programa de

68

control interno efectivo para TI que incluya auto-evaluaciones y revisiones por parte de terceros.

Se realizan las auto evaluaciones solicitadas en la Ley General de Control Interno. Se cuenta con descripción de

69

No contar con la documentación de procesos los procesos de TI.

procedimientos.

Los procesos se describen en el plan de TI. Los perfiles

70

y

Uso de software no licenciado

de

usuario

tienen

restricción para la instalación de software. Se lleva el inventario de licencias

Exceder la cantidad de usuarios 71

autorizados

para

utilizar

un

producto licenciado.

72

Facilitar

los

medios

adquiridas y licencias instaladas. Los usuarios no tienen autorización para instalar software (se restringe por perfil de usuario en Active

para

la

instalación de software a terceros.

Directory). Se ha instruido, sobre el tema, al personal de Servicio al Cliente que tiene a cargo la gestión de medios.


El ejercicio para la definición del Plan Estratégico y sus posteriores revisiones 73

Contar con un plan estratégico no alineado a la estrategia institucional.

se

participación de

todas

realizan de

con

la

representantes

las

Divisiones.

Se cuenta con el apoyo y seguimiento del Despacho de las Srs. Contraloras sobre el uso de las tecnologías de información. El Plan Estratégico

74

Se

tiene

Plan

se

revisa

Estratégico anualmente y se ajusta cuando se

desactualizado.

realizan cambios en la planificación

estratégica institucional. No contar con un modelo de El modelo de información está información 75

del

negocio

que documentado a nivel de las bases

sea utilizado en la creación y de datos y se cuenta con una actualización de los sistemas de aplicación automatizada que genera información.

76

77

78

Arquitectura

los informes. Se designó un funcionario para de

información

desactualizada.

Arquitectura de información no responde a la cadena de valor. Adquisición de tecnologías que no aportan valor a la organización.

que conozca la información de la institución y valide los proyectos pero no se han establecido los controles documentales del caso. Se deben mejorar la documentación de la arquitectura de la información en función de la cadena de valor. Se revisan las características de los productos de acuerdo con las necesidades de la institución.


Contar con equipo costoso que 79

no

cuenta

con

contratos

de

mantenimiento.

comunicación establecidos para informar sobre la gestión de TI.

81

82

tiene

un

renovación

plan

de

de

equipo.

Dentro del presupuesto se reservan las partidas correspondientes. Periódicamente se realizan

No aplicación de los canales de 80

Se

reuniones informativas con todo el personal de la USTI. Igualmente se mantiene informado al Despacho sobre la evolución de los proyectos y

la operativa de TI. No se tienen documentados los Está pendiente de documentarse los canales de comunicación.

canales formales. Desarrollo periódico del Diagnóstico de

No se tiene dominio sobre las herramientas en uso.

Necesidades de Capacitación (DNC). Ejecución

del

programa

de

capacitación (de acuerdo con el disponible presupuestario). Se realizan dos evaluaciones

Equipo 83

de

trabajo

con

baja

motivación, poco creativo y no comprometido con el logro de los objetivos.

de

clima

laboral

por

Comunicación sobre y

los

planes

compromisos

año.

constante de de

trabajo gestión.

Gestión orientada al logro de los objetivos.


Están definidos los estándares y Contar

con

un

administración 84

deficiente y

sistema

de

en

aplicación

la

la de

de

calidad definición

procesos

y

procedimientos para el desarrollo de las TIC en la institución.

Desarrollar 85

productos

procedimientos que se deben aplicar en el desarrollo de los productos. Se

realizan

cumplimiento

no

cumplen con los requerimientos de calidad.

de

alcance.

errores antes de liberar versiones o

actualizadas

de

los

productos de software. Aplicación de estándares

y

procedimientos Capacitación

de del

Anualmente

No administrar los riesgos de TI.

calidad.

personal

técnicas de calidad. Se cuenta con contra

86

de

Se aplican pruebas para identificar nuevas

que

revisiones

un

en plan

contingencias. se

realiza

un

ejercicio de valoración de riesgos. Se aplican los instrumentos definidos para el cumplimiento del SEVRI

Utilizar 87

un

deficiente

marco para

de

la

trabajo

gestión

de

riesgos, y no alineado con el apetito

Se aplican las indicaciones del SEVRI. Se realizan auto evaluaciones de

riesgos a nivel de procesos. del riesgo institucional. El personal no está capacitado Se utilizan las instrucciones definidas 88

adecuadamente para realizar una dentro del marco orientador del gestión efectiva de los riesgos. No

89

contar

con

el

contenido

presupuestario para la ejecución de los proyectos.

SEVRI. Exposición de la importancia de los

proyectos

en

la

Asamblea

Legislativa para darles prioridad. Recurrir a cooperación internacional.


Documentación de los proyectos. 90

Inestabilidad en el equipo de Divulgación proyecto.

del

dentro

proyecto

del

equipo.

Desarrollo de talleres Planificación de 91

Desarrollo de proyectos no alineados de acuerdo con el PAO y la al Plan Estratégico

aprobación del Gerente de División Organizacional. Verificación de

92

Los

proyectos

no

están

documentados

referencia para la gestión de los proyectos en cuanto a su iniciación, planificación,

ejecución,

control

y cierre, o aplicar ese marco de referencia deficientemente.

94

proyectos

Exceder el tiempo planificado para la ejecución de los proyectos.

que

cumplen

metodología Validar

No contar con un marco de

93

proyectos

los

con

la

correspondiente.

el

cumplimiento

de

estándares. Se cuenta con una metodología oficializada de

para

proyectos

de

la

gestión

la

aplicación

cual

es

obligatoria.

Capacitación sobre el tema para los directores de proyecto y los ingenieros de la USTI. Seguimiento frecuente los

proyectos

Reasignación Fortalecer

los

de

(por

semana).

de

recursos.

ejercicios

de

planificación. Establecimiento

95

Falta de apoyo del patrocinador del proyecto.

compromisos Vinculación

de

de de

gestión.

Planes

Anuales

Operativos entre la USTI y unidades usuarias.


Evaluación de riesgos controlados Id 1 2 3 4 5 6

7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Riesgo Adquisición de soluciones automatizadas que no satisfagan las necesidades de la institución. Desarrollar productos que no

cumplen

con

las

especificaciones. Desarrollar productos basados en requerimientos incorrectos. Versiones de software desactualizadas. Adquirir software sin programas fuentes. Adquirir software que no tiene representación en el país. Equipo dañado no puede ser reparado. Red inalámbrica insegura. Daño físico en los equipos de la plataforma tecnológica. Obsolescencia de la infraestructura tecnológica. Desarrollo de sistemas y servicios que son difíciles de utilizar para el usuario. No existe guía de usuario para el uso del sistema. Retrasos en los procesos de contratación administrativa. Se adquiere equipo no compatible con la infraestructura en uso. Se adquiere equipo sin que existan talleres para la reparación y mantenimiento de los mismos. Trabajar directamente en equipos de producción. Versiones de software para desarrollo y producción diferentes. No contar con la metodología y procedimientos necesarios para la administración de los cambios. Libertad en el uso de componentes tecnológicos (software libre). Instalación de parches sin seguir las recomendaciones del proveedor. Ausencia de niveles de servicio aceptados que faciliten la gestión. Definición de niveles de servicio que sobrepasan la capacidad instalada de TI.

P

I

S

1

3

3

1

4

4

1 2

4 4 4

4 8 4

4

4

2

3 3 4 3

3 6 4 6

2

3

6

2

2

2 3

4 6

1

3

3

1

3

3

1

1

4 4

4 4

2

4

8

1

3

3

1

3

3

2

3

6

1

3

3

1 1 1 2

1


23

No contar con los recursos necesarios para cumplir con los

24

niveles de servicio. No existe contrato de mantenimiento Debilidad en la administración de servicios de terceros

25

que implica que éstos no cumplan satisfactoriamente los

26

27 28 29

requerimientos del negocio. Incumplimiento de las políticas definidas por las partes. Tiempo de respuesta degradado. No hacer planeamiento de la capacidad. Los recursos de la infraestructura tecnológica no son

30 31 32 33 34

suficientes para atender las demandas de servicios. Recuperación de software no es factible Suspensión de servicio de Internet Fallas en los equipos de comunicaciones Fallas en los servidores (computadores principales) Equipo de usuario final inseguro. Ausencia de controles cruzados que comprueben la

35

integridad de la información y el funcionamiento correcto de

36 37 38 39 40

41

las aplicaciones. Errores en la creación de usuarios y en la asignación de privilegios de acceso. Sistemas sin mecanismos de trazabilidad de transacciones (pistas de auditoría). No se conocen los costos asignados a los servicios prestados por TI. No se cuenta con un proceso de análisis para mejorar los costos que están asociados a los servicios de TI. El personal no cuenta con el tiempo suficiente para recibir, de manera completa, la capacitación correspondiente. El personal no cuenta con las actitudes y aptitudes requeridas para hacer uso de la información por medio de las soluciones automatizadas.

2

3

6

1

4

4

2

3

6

1

3

3

1 2

3 3

3 6

1

4

4

1 2 2 1

4 4 3 3 3

4 8 6 6 3

2

3

6

1

4

4

1

2

2

3

3

9

3

3

9

1

3

3

1

3

3

2


La capacitación que se brinda a los usuarios no es efectiva 42

43

44

45 46

47 48 49 50 51 52 53 54 55 56 57 58 59

para que puedan utilizar eficientemente los recursos informáticos disponibles. No se cuenta con presupuesto para diseñar e implementar programas de capacitación para los usuarios. No contar con una respuesta oportuna y efectiva para las consultas de los usuarios de TI y a la atención de los incidentes. Las soluciones que se aplican, ante los incidentes reportados por los usuarios, no son efectivas. Los usuarios no están informados sobre los procedimientos que se deben seguir para reportar los incidentes. No se cuenta o no se aplica el procedimiento definido para la asignación, atención y seguimiento de los incidentes. No se realiza una adecuada gestión de métricas sobre los incidentes reportados y atendidos. Se realizan cambios operativos que no se reflejan en la documentación. Se realizan cambios en la configuración de componentes de la infraestructura y no se reflejan en la documentación. No se conoce el impacto de hacer cambios en los componentes de la configuración. No se aplica el procedimiento oficializado para la gestión de problemas. No se documentan las soluciones aplicadas a los problemas. Hay dificultad para definir el ámbito de acción de los proveedores para la solución de problemas. Alteración o pérdida de la información registrada en base de datos o equipos. Información desactualizada o incorrecta. Acceso no autorizado a la información. Instalaciones físicas mal diseñas que pongan en peligro la integridad del equipo de cómputo y del personal. Acceso no autorizado al centro de cómputo.

1

2

2

1

3

3

1

3

3

1

4

4

1

3

3

1

3

3

2

3

6

1

4

4

2

4

8

2

4

8

3

3

9

4

5

20

1

3

3

1

4

4

1

1

4 5

4 5

1

3

3

2

3

6


60 61 62 63 64 65

Ausencia de detectores de humo. Fallas en los equipos que mantienen el medio ambiente apropiado para la operación de TI (UPS, Aire acondicionado) No aplicación de las políticas para la generación de respaldos. No efectuar un monitoreo constante sobre la operación de la plataforma. Suspensión de servicios sin seguir el procedimiento establecido. No contar con un proceso para revisar periódicamente el

66

desempeño actual y la capacidad de los recursos de TI. No percibir los cambios que se realizan en el entorno. Utilización de indicadores sobre el desempeño de TI que

67

no son relevantes y que no colaboran en la identificación de

3

3

9

3

3

9

1

4

4

2

3

6

2

3

6

3

3

9

1

3

3

3

4

12

2

3

6

1 1

3 3

3 3

1

3

3

2

3

6

1

4

4

1

4

4

oportunidades de mejora en los procesos importantes de TI. No contar con un programa de control interno efectivo para 68

TI que incluya auto-evaluaciones y revisiones por parte de

69 70

terceros. No contar con la documentación de los procesos de TI. Uso de software no licenciado Exceder la cantidad de usuarios autorizados para utilizar un

71 72 73

producto licenciado. Facilitar los medios para la instalación de software a terceros. Contar con un plan estratégico no alineado a la estrategia

74

institucional. Se tiene Plan Estratégico desactualizado. No contar con un modelo de información del negocio que

75

sea utilizado en la creación y actualización de los sistemas

2

3

6

76

de información. Arquitectura de información desactualizada. Arquitectura de información no responde a la cadena de

2

4

8

2

3

6

1

3

3

77 78

valor. Adquisición de tecnologías que no aportan valor a la organización.


79 80 81 82 83

84

85 86

87 88 89 90 91 92

93

94 95

Contar con equipo costoso que no cuenta con contratos de mantenimiento. No aplicación de los canales de comunicación establecidos para informar sobre la gestión de TI. No se tienen documentados los canales de comunicación. No se tiene dominio sobre las herramientas en uso. Equipo de trabajo con baja motivación, poco creativo y no comprometido con el logro de los objetivos. Contar con un sistema de administración de la calidad deficiente en la definición y aplicación de procesos y procedimientos para el desarrollo de las TIC en la institución. Desarrollar productos que no cumplen con los requerimientos de calidad. No administrar los riesgos de TI. Utilizar un marco de trabajo deficiente para la gestión de riesgos, y no alineado con el apetito del riesgo institucional. El personal no está capacitado adecuadamente para realizar una gestión efectiva de los riesgos. No contar con el contenido presupuestario para la ejecución de los proyectos. Inestabilidad en el equipo de proyecto. Desarrollo de proyectos no alineados al Plan Estratégico Los proyectos no están documentados No contar con un marco de referencia para la gestión de los proyectos en cuanto a su iniciación, planificación, ejecución, control y cierre, o aplicar ese marco de referencia deficientemente. Exceder el tiempo planificado para la ejecución de los proyectos. Falta de apoyo del patrocinador del proyecto.

P = Probabilidad, I = Impacto, S = Severidad

1

3

3

1

2

2

2 2

2 4

4 8

1

4

4

1

4

4

2

3

6

2

4

8

2

4

8

2

3

6

2

5

10

1 1 2

3 3 4

3 3 8

2

4

8

2

3

6

2

4

8


Mapas térmicos riesgos controlados Infraestructura

Impacto

5 4

24, 49

31, 50, 51

3

7, 14, 27

10, 32, 33

61

1

2

3

2 1

Probabilidad

4

5


Seguridad y control 5

57

53

5, 6, 9, 16,

Impacto

4

17, 30, 36,

4, 18, 86,

55, 56, 62,

87

84 3

2

15, 19, 20,

8, 35, 59,

26, 34, 47,

63, 68, 72,

54, 58, 70

88

52, 60

37

1 1

2

3

4

5

4

5

Probabilidad Suministro de servicios 5

Impacto

4

3

2

29, 45, 83

82, 92, 93

40, 41, 43,

11, 21, 23,

44, 46

94

42

12, 64

1

2

38

1 3

Probabilidad


Inserción tecnológica 5

Impacto

4

3

2

76, 89 2, 3, 73, 74

95

1, 22, 66,

13, 25, 28,

69, 78, 79,

48, 75, 77,

90, 91

85

80

81

1

2

67

39, 65

1 3

Probabilidad

4

5


Para facilitar el análisis del nivel de riesgo de los procesos de TI se presenta en siguiente cuadro en el cual se presentan los valores totales de cantidad de riesgos, por cada proceso, en las evaluaciones de riesgos absolutos y riesgos controlados. Posteriormente esta información se presenta en gráficos y cuadros de porcentajes: Proceso de TI Infraestructura

Severidad Extrema Alta Moderada Baja Total de riesgos Seguridad y control Extrema Alta Moderada Baja Total de riesgos Suministro de Extrema Alta servicios Moderada Baja Total de riesgos I n s e r c i ó n Extrema Alta tecnológica Moderada Baja Total de riesgos

R. Absolutos

R. Controlados

1 10 1 0 12 7 22 8 0 37 2 11

0 4 5 3 12 1 6 19 11 37 0 4

6

9

0 19 3 15 9 0 27

6 19 0 6 12 9 27

En los siguientes gráficos y cuadros se observa la evaluación de los riesgos, según cada proceso de TI, tanto a nivel absoluto como a nivel controlado. De esta manera se puede notar fácilmente el efecto de los controles en la distribución de los riesgos según su severidad la cual está representada en lo gráficos por los colores usados en los mapas térmicos.


Riesgos de infraestructura Riesgos absolutos

Riesgos controlados

㄀

㄀

　

㈀

㐀

Severidad Extrema Alta Moderada Baja

㘀

㠀

㄀　

　

Riesgos absolutos 8% 84% 8% 0%

㄀

㈀

㌀

㐀

㔀

Riesgos controlados 0% 33% 42% 25%

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.


Riesgos se seguridad y control Riesgos absolutos

Riesgos controlados

㄀

㄀

　

㔀

㄀　


㄀㔀

㈀　

㈀㔀

　


㔀

㄀　

㄀㔀

㈀　


La mayor cantidad de riesgos identificados están asociados con el proceso de seguridad y control, de los 37 riesgos 7 están en las categorías de severidad extrema y alta por lo cual deben ser gestionados. Esos 7 riesgos representan el 19% de los riesgos identificados. Es importante notar que en la valoración de riesgos absolutos la cantidad el porcentaje de riesgos clasificados en esa categoría es de 78% lo cual significa que la aplicación de los controles colaboró, de manera muy importante, para reducir la cantidad de riesgos cuya severidad es extrema y alta.


Riesgos de suministro de servicios Riesgos absolutos

Riesgos controlados

㄀

㄀

　

㈀

㐀


㘀

㠀

㄀　

㄀㈀

　


㈀

㐀

㘀

㠀

㄀　


En la calificación de riesgos absolutos el 78% de los riesgos identificados (en total 19 para el proceso de suministro de servicios) se encuentran con calificación de severidad extrema o alta. En la segunda calificación, considerando la aplicación de los controles actuales, en la calificación de riesgos con severidad extrema se tiene 4%, eso representa el 21% de los riesgos identificados para el proceso.


Riesgos de inserción tecnológica Riesgos absolutos

Riesgos controlados

㄀

㄀

　

㈀


㐀

㘀

㠀

㄀　

㄀㈀

㄀㐀

㄀㘀


　

㈀

㐀

㘀

㠀

㄀　

㄀㈀


En cuanto al proceso de inserción tecnológica se identificaron 27 riesgos, es el segundo proceso en cantidad de riesgos identificados. De estos riesgos el 67% tienen una calificación absoluta con severidad extrema y alta. Después de calificarlos, tomando en cuenta la aplicación de los controles actuales, este porcentaje baja a 22% que corresponde a 6 riesgos con calificación de severidad alta.


Valoración del nivel de riesgo de los procesos 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: Proceso de TI Infraestructura Seguridad y control Suministro de servicios Inserción tecnológica En promedio

Riesgos absolutos

Riesgos controlados

10.9 10.6 9.3

5.7 5.2 5.0

8.9 9.9

5.4 5.3

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.


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: Id 4

18 31 38

39

Descripción del riesgo

Versiones

de

Proceso de TI relacionado

software

desactualizadas. No contar con la metodología y

Seguridad y control

procedimientos necesarios para la Seguridad y control administración de los cambios. Suspensión de servicio de Internet Infraestructura No se conocen los costos asignados Suministro de servicios a los servicios prestados por TI. No se cuenta con un proceso de análisis para mejorar los costos que Inserción tecnológica están asociados a los servicios de TI. Se realizan cambios en la

50

configuración de componentes de la infraestructura y no se reflejan en la

Infraestructura

documentación. No se conoce el impacto de hacer 51

cambios en los componentes de la Infraestructura configuración. No se aplica el procedimiento

52

53 60

oficializado

para

la

gestión

de Seguridad y control

problemas. No se documentan las soluciones aplicadas a los problemas. Ausencia de detectores de humo.

Seguridad y control Seguridad y control


Fallas en los equipos que mantienen 61

el

medio

ambiente

apropiado

para la operación de TI (UPS, Aire

Infraestructura

acondicionado) No contar con un proceso para revisar 65

periódicamente el desempeño actual Inserción tecnológica y la capacidad de los recursos de TI. Utilización de indicadores sobre el desempeño de TI que no son

67

relevantes y que no colaboran en la identificación de oportunidades de

Inserción tecnológica

mejora en los procesos importantes

76 82 86

87

de TI. Arquitectura

92

información

desactualizada. No se tiene dominio sobre las


Suministro de servicios herramientas en uso. No administrar los riesgos de TI. Seguridad y control Utilizar un marco de trabajo deficiente para la gestión de riesgos, y no alineado con el apetito del riesgo institucional. No contar

89

de

con

el

Seguridad y control

contenido

presupuestario para la ejecución de Inserción tecnológica los proyectos. Los proyectos documentados

no

están

Suministro de servicios


No

contar

con

un

marco

de

referencia para la gestión de los 93

proyectos en cuanto a su iniciación, planificación,

ejecución,

control

Suministro de servicios

y cierre, o aplicar ese marco de referencia deficientemente. 95

Falta de apoyo del patrocinador del proyecto.


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

Descripción del riesgo Se

Planes de acción presupuestaron las partidas

para contratar el mantenimiento 4

Versiones

de

software y se incluyó en el PAO la actividad

desactualizadas.

para actualización de plataforma. En el diagnóstico de capacitación se incorporó la capacitación necesaria. Con base al manual de normas

No contar con la metodología y técnicas 18

sobre

tecnologías

de

procedimientos necesarios para información, se revisará y actualizará la administración de los cambios. el método para administración de los cambios En el presupuesto del 2008 se

31

Suspensión Internet

de

servicio

de incluyó el alquiler de un canal alterno al proveedor actual del servicio para la solución de fallas locales en el ISP


No

se

conocen los

costos Se desarrollará un modelo de costos

38

asignados

39

prestados por TI. productos No se cuenta con un proceso En paralelo al modelo de costos se de análisis para mejorar los realizará el modelo para el análisis costos que están asociados a los respectivo servicios de TI. Se realizan cambios en la Se enfatizará en el personal

50

a

los

servicios para conocer el costo por servicios o

configuración de componentes la

No se conoce el impacto de hacer cambios en los componentes de la configuración. No se aplica el procedimiento 52

oficializado para la gestión de problemas.

53

60

de

actualizar

la

de la infraestructura y no se documentación con los cambios reflejan en la documentación.

51

obligación

No se documentan las soluciones aplicadas a los problemas.

Ausencia de detectores de humo.

que se realicen a la infraestructura Se coordinarán los cambios previo a

realizarlos

para

proyectar

el

impacto, incluyendo de ser posible al proveedor Se realizará un taller para analizar las razones por las cuales no se aplica en algunos casos el procedimiento, y para generar las acciones correctivas Se incluyó como parte del manual para continuidad de la operación, la obligación de documentar soluciones aplicadas para el mejoramiento continuo. Sin incluyó en el presupuesto del 2008 la adquisición de la solución


El CC mantiene una UPS exclusiva Fallas 61

en

los

equipos

que

mantienen el medio ambiente apropiado para la operación de TI (UPS, Aire acondicionado)

No 65

contar

con

un

para equipos críticos y se compró una adicional para respaldo de las tres que soportan toda la institución. Se está elaborando el procedimiento institucional para soporte de medio

ambiente. proceso A partir del 2008 se aplicará un

para revisar periódicamente el nuevo método de evaluación del desempeño actual y la capacidad desempeño basado en compromisos de los recursos de TI. de desempeño Utilización de indicadores sobre el desempeño de TI que no son Con base a los planes tácticos y

67

relevantes y que no colaboran en la nueva cartera de proyectos se la identificación de oportunidades rediseñaron los indicadores para de

mejora

en

los

procesos medir el desempeño

importantes de TI. Se tiene programada la revisión de 76

82

86

Arquitectura

de

información la arquitectura para ajustarla de

desactualizada.

No se tiene dominio sobre las herramientas en uso.

No administrar los riesgos de TI.

ser necesario, con base a la nueva cartera de proyectos Se desarrollará la

capacitación

necesaria para que el personal utilice las herramientas adecuadamente Se establecerán administradores de riesgos por área de coordinación, y reuniones mensuales de seguimiento para auto evaluación y mejora


Utilizar un marco de trabajo 87

deficiente para la gestión de riesgos, y no alineado con el apetito del riesgo institucional.

Se lleva a cabo estudio de auditoría, se desarrollo un sistema automatizado para control de riesgos, y se está realizando

una

evaluación

de

riesgos. Ajustar la cartera de proyectos al

No contar con el contenido presupuesto aprobado y elaborar 89

presupuestario para la ejecución un presupuesto extraordinario para de los proyectos.

92

Los

reprogramar los proyectos en caso

proyectos

no

están

documentados

de que este se apruebe Se harán auditorias

periódicas

para control de los expedientes de sistemas

No contar con un marco de referencia para la gestión de Se acordó capacitar en el 2008 a 93

los

proyectos

su

iniciación,

en

cuanto

a todos los gerentes sobre la necesidad

planificación, de aplicar la metodología, e iniciar

ejecución, control y cierre, o cada proyecto capacitando a todo el aplicar ese marco de referencia equipo de proyecto deficientemente. A partir de la nueva cartera de proyectos, los gerentes de División tienen que

95

Falta de apoyo del patrocinador del asegurar los recursos a los proyectos proyecto.

en los cuales son patrocinadores; total o compartido, e incluirlos como parte de su PAO


Evaluación de riesgos tratados En la siguiente tabla se presenta la calificación de los riesgos proyectando la aplicación de los planes de tratamiento (riesgos tratados): Id 4 18 31 38

39 50

51

52 53 60 61

65

67 76 82 86

87

Riesgo Versiones de software desactualizadas. No contar con la metodología y procedimientos necesarios para la administración de los cambios. Suspensión de servicio de Internet No se conocen los costos asignados a los servicios prestados por TI. No se cuenta con un proceso de análisis para mejorar los costos que están asociados a los servicios de TI. Se realizan cambios en la configuración de componentes de la infraestructura y no se reflejan en la documentación. No se conoce el impacto de hacer cambios en los componentes de la configuración. No se aplica el procedimiento oficializado para la gestión de problemas. No se documentan las soluciones aplicadas a los problemas. Ausencia de detectores de humo. Fallas en los equipos que mantienen el medio ambiente apropiado para la operación de TI (UPS, Aire acondicionado) No contar con un proceso para revisar periódicamente el desempeño actual y la capacidad de los recursos de TI. Utilización de indicadores sobre el desempeño de TI que no son relevantes y que no colaboran en la identificación de oportunidades de mejora en los procesos importantes de TI. Arquitectura de información desactualizada. No se tiene dominio sobre las herramientas en uso. No administrar los riesgos de TI. Utilizar un marco de trabajo deficiente para la gestión de riesgos, y no alineado con el apetito del riesgo institucional.

P

I

S

1

3

3

1

4

4

2

2

4

1

3

3

1

3

3

1

4

4

1

4

4

2

3

6

1

5

5

2

3

6

2

3

6

1

3

3

1

3

3

1

4

4

1

3

3

1

4

4

1

4

4


89 92

93

95

No contar con el contenido presupuestario para la ejecución de los proyectos. Los proyectos no están documentados No contar con un marco de referencia para la gestión de los proyectos en cuanto a su iniciación, planificación, ejecución, control y cierre, o aplicar ese marco de referencia deficientemente. Falta de apoyo del patrocinador del proyecto.

1

5

5

1

4

4

1

3

3

1

4

4

Es interesante observar la evolución de los riesgos en cada uno de los niveles de evaluación (absoluto, controlado y tratado); seguidamente se presenta la calificación para los riesgos prioritarios. ID

Riesgo

Absoluto

Controlado

Tratado

4

Versiones de software desactualizadas. No contar con la metodología y

12

8

3

18

procedimientos

la

12

8

4

31

administración de los cambios. Suspensión de servicio de Internet No se conocen los costos asignados a los

12

8

4

9

9

3

9

9

3

12

8

4

12

8

4

9

9

6

38

39

necesarios

para

servicios prestados por TI. No se cuenta con un proceso de análisis para mejorar los costos que están asociados a los servicios de TI. Se realizan cambios en la configuración

50

51

52

de componentes de la infraestructura y no se reflejan en la documentación. No se conoce el impacto de hacer cambios en los componentes de la configuración. No se aplica el procedimiento oficializado para la gestión de problemas.


53

No

se

documentan

las

soluciones

60

aplicadas a los problemas. Ausencia de detectores de humo. Fallas en los equipos que mantienen

61

el medio ambiente apropiado para la

20

20

5

9

9

6

15

9

6

9

9

3

12

12

3

12

8

4

12

8

3

16

8

4

16

8

4

10

10

5

16

8

4

16

8

3

16

8

4

operación de TI (UPS, Aire acondicionado) No contar con un proceso para revisar 65

periódicamente el desempeño actual y la capacidad de los recursos de TI. Utilización de indicadores sobre el desempeño de TI que no son relevantes y

67

que no colaboran en la identificación de oportunidades de mejora en los procesos

76

82

importantes de TI. Arquitectura de

información

desactualizada. No se tiene dominio sobre las herramientas

86

en uso. No administrar los riesgos de TI. Utilizar un marco de trabajo deficiente

87

para la gestión de riesgos, y no alineado

89 92

con el apetito del riesgo institucional. No contar con el contenido presupuestario para la ejecución de los proyectos. Los proyectos no están documentados No contar con un marco de referencia para la gestión de los proyectos en cuanto

93

a su iniciación, planificación, ejecución, control y cierre, o aplicar ese marco de

95

referencia deficientemente. Falta de apoyo del patrocinador del proyecto.


Organización para la gestión de los riesgos A efectos de mantener una organización adecuada para la Gestión de los Riesgos en la USTI, y con el objetivo de mantener riesgos actualizados, controlados, y planes de tratamiento para mitigarlos, se adecua la organización mediante asignar un asistente de la jefatura que recopile riesgos en un nivel preliminar, los procese, y para que actualice el mapa térmico para conocimiento de la jefatura y los coordinadores de área. La identificación y evaluación de los riesgos debe ser sustentado por un sistema participativo de planificación que considere la misión y la visión institucionales, así como objetivos, metas y políticas; por esa razón se estarán realizando reuniones una vez al mes con los coordinadores de área para considerar el tema. Se reforzará la administración basada en riesgos para los coordinadores de área y asistente de la jefatura, con el objetivo que darle robustez a la organización y a la UTI en su gestión, siempre bajo el modelo de administración de riesgos de la CGR, la política de valoración de riesgos emitida por el Despacho, la metodología para valoración de riesgos, y los lineamientos generados por la División de Estrategia Institucional. Los insumos para la identificación de riesgos estarán basados principalmente en los que a continuación se indican: • Planes institucionales, sectoriales y nacionales. • Análisis del entorno interno y externo. • Evaluaciones institucionales. • Descripción de la organización (procesos, presupuesto, sistema de control interno). • Normativa externa e interna asociada con la proceso/proyecto e institución. • Documentos de operación diaria y de la evaluación periódica.


A continuación se incluye el organigrama de la UTI; según la propuesta en donde se identifica al asistente de la jefatura, y a los coordinadores en su último nivel.

伀爀最愀渀椀稀愀挀椀渀䐀攀猀瀀愀挀栀漀䌀漀渀琀爀愀氀漀爀愀䜀攀渀攀爀愀氀䌀漀洀椀琀 䜀攀爀攀渀挀椀愀氀搀攀吀䤀䌀 됀猀䐀椀瘀椀猀椀渀䜀攀猀琀椀渀搀攀䄀瀀漀礀漀唀渀椀搀愀搀吀攀挀渀漀氀漀最愀猀䤀渀昀漀爀洀愀挀椀渀倀爀攀猀甀瀀甀攀猀琀漀礀䌀漀洀瀀爀愀猀

匀漀瀀漀爀琀攀愀䌀氀椀攀渀琀攀猀

䐀攀猀愀爀爀漀氀氀漀匀椀猀琀攀洀愀猀

䐀椀瘀椀猀椀渀搀攀䐀攀猀愀爀爀漀氀氀漀䤀渀猀琀椀琀甀挀椀漀渀愀氀唀渀椀搀愀搀搀攀匀椀猀琀攀洀愀猀礀吀攀挀渀漀氀漀最愀搀攀䤀渀昀漀爀洀愀挀椀渀

匀攀挀爀攀琀愀爀 愀

倀氀愀琀愀昀漀爀洀愀搀攀刀攀搀攀猀

倀氀愀琀愀昀漀爀洀愀吀攀挀渀漀氀最椀挀愀

䌀攀渀琀爀漀搀攀䌀 洀瀀甀琀漀 ⠀㄀⤀


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. a. Mantener un mapa térmico actualizado con los riesgos controlados que están identificados con una severidad alta o extrema. b. Desarrollar una reunión cada primer lunes de mes, para que la jefatura de la UTI evalúe con los coordinadores de área los planes de tratamiento que se están aplicando a los riesgos del mapa térmico identificados como alto o extremo, con el objetivo de actualizarlos si se considera que es factible mejorarlos para mitigar el riesgo. c. Fortalecer la administración basada en riesgos en los niveles de coordinación, mediante capacitación periódica y con base en los análisis que se realicen en las reuniones los días lunes primero de mes. d. Centralizar la actualización preliminar de los riesgos identificados, controlados, y planes de tratamiento, en un asistente de la jefatura de UTI que se encargará de preparar el material de la reunión de los lunes, y de alertar a la jefatura inmediatamente, en caso de que se detecte un nuevo riesgo que clasifique como alto o severo. e. Preparar al asistente de la jefatura para que procese los nuevos riesgos con fines de clasificarlos, para alertar a la jefatura en caso de riesgos extremos o altos. f. Cada coordinador de área debe administrar con base a los riesgos detectados, reportando al asistente los nuevos riesgos detectados, mitigados, o nuevos controles que han sido aplicados, a fin de mantener la administración de riesgos actualizada; sin importar para este caso el nivel de riesgo; todos deben ser reportados para procesarlos. g. Adquisición de un software institucional que facilite la administración basada en riesgos.


Anexo - NTP4

Instrumento metodológico MAI



Proyecto para el desarrollo de un Modelo de Arquitectura de Información para la Contraloría General de la República. Instrumento metodológico. Descripción de la metodología a utilizar La Arquitectura de Información (MAI) de la Contraloría General de la República será actualizada a partir de los procesos definidos o modificados en la más reciente versión oficializada del Manual General de Fiscalización (MAGEFI). Para la definición de dicha Arquitectura se utilizará la metodología de Business System Planning (BSP) (Planificación de los Sistemas del Negocio), la cual implementa un enfoque estructurado para ayudar a la organización a establecer los flujos de información y el manejo de los datos que son utilizados por los procesos. Se utilizará una versión simplificada de la metodología BSP, dado que a la fecha se dispone únicamente de la descripción macro de todos los procesos de la organización. El MAGEFI será el marco conceptual general, a partir del cual se detallarán los flujos de información y los datos involucrados. Se plantea inicialmente aplicar BSP a manera de plan piloto (posiblemente aplicado a por lo menos dos procesos representativos), para adaptar y afinar el método a nuestras necesidades, para luego abarcar todos los procesos con el apoyo de los expertos funcionales de cada una de las áreas de la organización.


Para cada uno de los procesos se deberá generar una tabla que incluya: • Nombre del proceso • Área(s) que lo ejecuta(n) definiendo responsables y participantes. • Detalle de los diferentes insumos y productos del proceso a nivel de entidad de información1. • Clientes inmediatos de los productos (internos y externos). • Sistemas de información involucrados. • Necesidad de sistemas de información u otras soluciones. Con dicha información se aplicarán cada uno de los pasos definidos en la técnica del BSP, a saber: Paso 1: Definir los procesos del Negocio • Lista de procesos • Breve descripción de cada proceso • Áreas responsables y participantes Paso 2: Definir clases de datos • Clase de datos: grupo de datos categorizado lógicamente a nivel de entidad de información. • Crear la Matriz de Proceso/Base de Datos Sujeto, indicando quién crea la información y quién la usa. 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

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.

1


Paso 4: Definir la arquitectura de información • Ordenar las bases de datos sujeto por proceso • Agrupar procesos y datos en sistemas principales • Se trazan los flujos de datos de un sistema a otro, del que lo crea al que lo utiliza. • Poner nombres (tentativos) a los subsistemas de información. Paso 5: Elaborar la matriz de prerrequisitos para determinar la secuencia de desarrollo. Paso 6: Identificación básica de macrosistemas y subsistemas.

Opciones para la recopilación de la información En la recopilación de la información requerida por el BSP para la definición de la Arquitectura de Información, es fundamental la participación de expertos funcionales para cada proceso definido en la última versión del MAGEFI. Estos mismos expertos serán los que en su momento deberán documentar y detallar a nivel de procedimientos, todas las actividades definidas para el proceso por ellos conocido. Para el éxito de ambos proyectos es fundamental la disponibilidad de tiempo y el compromiso de dichos expertos. 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: Opción 1: Realizar el levantamiento de información requerida para la definición del MAI, uniéndose al proceso de detallar los procesos definidos por el MAGEFI y documentar los respectivos procedimientos.


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. Opción 2: Realizar el levantamiento de información requerida para la definición del MAI realizando una coordinación directa entre el equipo de proyecto MAI y los expertos funcionales conocedores de los procesos, adelantándose al levantamiento de información que realizará el equipo MAGEFI. 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.


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


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. Adicionalmente, debe considerarse la dificultad de documentar un procedimiento por cada actividad que conforma cada proceso; si se consideran entre 3 y 5 actividades por proceso y en total se tienen 26 procesos, estamos hablando de que serán cerca de 120 procedimientos por documentar.

Anexo - NTP5

Diagnostico inicial MAI



Proyecto para el desarrollo de un Modelo de Arquitectura de Información para la Contraloría General de la República. Documento de Diagnóstico Necesidad que atiende el presente documento El presente documento expone los resultados de una investigación de mejores prácticas metodológicas a tomar en consideración para el desarrollo de un modelo de arquitectura de información (MAI) para la Contraloría General de la República (CGR), tomando en cuenta que esté acorde con las últimas orientaciones estratégicas y tácticas, que la institución se ha dictado para gestionar las tecnologías de información y comunicación. 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 La información y las comunicaciones son medios indispensables para el funcionamiento de cualquier organización, más aún para organizaciones como la Contraloría General, que procesa información o datos, por medio del conocimiento, para generar y comunicar nueva información (evaluaciones, refrendos, tasas, criterios técnicos, lineamientos, disposiciones, aprobaciones, etc.) En ese contexto, el manejo y aprovechamiento de la información y de las comunicaciones requiere importantes esfuerzos y costos, que deben verse compensados por el valor agregado que generan.


Asimismo, los esfuerzos y costos para gestionar la información y las comunicaciones dependen, indiscutiblemente, de las tecnologías relacionadas (TIC). La inversión en éstas y en el conocimiento necesario para que las personas las aprovechen al máximo, bien puede considerarse entre los principales rubros en los presupuestos de las organizaciones modernas, para mantenerse actualizadas en la materia. 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 efecto, un asunto trascendental en este contexto de alta dependencia de las TIC para la gestión estratégica, táctica y operativa de la información y las comunicaciones; es 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. La CGR emprende, actualmente, importantes esfuerzos para aplicar las referidas Normas Técnicas para la Gestión y el Control de las TIC, como mejores prácticas de apoyo para la gestión estratégica institucional. El Modelo de Arquitectura de Información (MAI), es una pieza fundamental para esos efectos, tal como lo han contemplado el Plan Estratégico de TIC 2007-2010 (PETIC) y su correspondiente Plan Táctico 20082010 (PTAC), que conforman el antecedente más cercano en esta materia. 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 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.


Para el caso de la Contraloría General, el Plan Estratégico del Área de Sistemas y Tecnología de Información del año 1998, propuso un modelo de arquitectura de información que, en buena medida, ha determinado el inventario de sistemas de información y de soluciones tecnológicas disponibles. Ese modelado, el conocimiento y la experiencia generada al construirlos serán insumo importante para el presente proyecto. 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. Estas orientaciones estratégicas y tácticas planteadas en el PETIC y en el PTAC constituyen un insumo básico para analizar y escoger el marco metodológico para desarrollar un modelo de arquitectura de información en la CGR. Este MAI deberá ser una herramienta a usar por el nivel estratégico de la organización, que ayude a visualizar con base en prioridades y lineamientos del Plan Estratégico Institucional, el aporte o apoyo que las TIC’s brindan al logro de objetivos institucionales. Es por ello que debe existir una adecuada interrelación entre el MAI y el Plan Estratégico de TIC (PETIC). Se puede indicar que un buen PETIC incorpora un estado actual y futuro del MAI y al mismo tiempo un buen MAI debe considerar los lineamientos o fundamentos básicos del PETIC.

Esquema metodológico El equipo de trabajo investigó varias metodologías relacionadas con el desarrollo de un Modelo de Arquitectura de Información, viendo este modelo como una pieza importante dentro de un modelo mayor que le da sentido y utilidad. Ese modelo


mayor es el Modelo de Arquitectura Empresarial (MAE) el cual busca establecer la forma en que los procesos de la organización se interrelacionan, apoyados por TIC’s en cuanto al manejo y procesamiento de la información. Este Modelo de Arquitectura Empresarial se divide en dos perspectivas: la perspectiva orientada al negocio, en donde se ven los procesos, sus interrelaciones y los datos involucrados (es aquí donde se tiene el MAI); y la perspectiva técnica que establece la forma en que se organiza y disponen las TIC para dar soporte a los procesos. El MAE constituye una herramienta vital en orden a orientar toda inversión en tecnología, proveyendo elementos imparciales que sustenten no sólo justificar dicha inversión, sino también la medición del impacto que se obtendrá en el logro de los objetivos institucionales. Dentro de este modelo general el MAI es verdaderamente una herramienta de gestión y toma de decisiones en materia de TIC, esto en la medida en que la perspectiva técnica responda a lo que el arquitecto plantea, en relación a lo que los procesos de la organización necesitan para el manejo de la información y los datos. Este documento presenta el siguiente esquema metodológico, tendiente a establecer un marco de referencia que permita conocer la forma en que debe desarrollarse una arquitectura de información, dentro de un enfoque incremental basado en un modelo de madurez. 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.


El modelo empresarial deberá considerar los siguientes componentes: 1.

Procesos del negocio de la CGR a. Misión, visión, valores, objetivos estratégicos b. Modelo de gestión de la CGR c. Macroprocesos y procesos de la cadena de Valor de la CGR.

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

El modelo empresarial describirá los procesos de la CGR y la forma en que esos procesos funcionan, los datos involucrados y el flujo que presentan; los recursos tecnológicos y de otras naturalezas que requieren para operar de manera óptima.


El MAI deberá entonces establecer el diseño general de los sistemas de información (no necesariamente ya automatizados), los datos y sus interrelaciones, documentar un diccionario de datos del negocio (institucional) con su esquema de clasificación, estableciendo criticidad, sensitividad y propiedad de los datos. Finalmente deberá establecer los controles de seguridad apropiados para cada una de las clasificaciones. Para la implementación de un MAE es claro que debe considerarse un desarrollo gradual por niveles, en el cual, ubicando la situación de la organización respecto de los diversos componentes del modelo, se establece un estado actual y se trabaja ordenadamente para lograr alcanzar el nivel inmediato superior. Para ello nuestra propuesta de niveles de capacidades asociados a cada componente es la siguiente:

䌀㨀尀䐀漀挀甀洀攀渀琀猀愀渀搀匀攀琀琀椀渀最猀尀樀氀攀漀渀尀䔀猀挀爀椀琀漀爀椀漀尀吀爀愀戀愀樀漀䄀挀琀甀愀氀尀䴀䄀䤀尀䔀匀儀唀䔀䴀䄀䐀䔀䴀䄀䐀唀刀䔀娀䐀䔀䰀伀匀䌀伀䴀倀伀一䔀一吀䔀匀䐀䔀䰀䴀䄀䤀 ⸀ 搀漀挀

Evolución según modelo de madurez La Contraloría General procurará evolucionar su modelo de información desde una perspectiva de madurez de capacidades. El equipo de trabajo aplicará un diagnóstico para determinar el estado actual de la CGR con respecto al modelo de referencia, el cual puede ser objeto de mejoras conforme se vaya desarrollando el proyecto. El horizonte de tiempo para ir alcanzando estados de madurez sucesivos, dependerá de lo que el modelo de procesos establezca y de la dedicación de recursos para alcanzarlo, según la relación que debe existir entre el MAI y el MAE como se explicó en el enfoque metodológico.


Alcances y limitaciones Coma ya se indicó la elaboración de cualquier modelo de información deberá partir de la perspectiva de los procesos del negocio, para que así logre los resultados esperados. El insumo fundamental para desarrollar el modelado de la arquitectura de información de la CGR, es la definición de los macro procesos y procesos institucionales de primer nivel, debidamente formalizada en el más reciente Manual General de Fiscalización (MAGEFI). 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 la recopilación de la información relacionada con los datos que utilizan y fluyen por los diferentes procesos de la organización se recurrirá a los expertos en los diferentes procesos. Para orientar y estandarizar la forma en que estos expertos documentan la visión del negocio desde la perspectiva de los datos, el equipo del proyecto MAI desarrollará los instrumentos de captura de información apropiados.


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. Se utilizará como referencia el último modelado de procesos definido para la CGR, con a las actividades allí propuestas, sean éstas vigentes o estén por implementarse, conforme a la propuesta del MAGEFI. 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. El modelo deberá estar debidamente documentado, tanto en forma narrativa como mediante una representación gráfica que permita resumir y visualizar con suma claridad los flujos de información y la forma en que interactúan los procesos institucionales a nivel de datos. Deberá clasificar los datos a nivel institucional permitiendo identificar los propietarios y responsables de los datos, catalogar los datos con base en su criticidad, sensitividad, multimedios y ubicación física. Deberá facilitar la determinación de los privilegios de acceso de los usuarios, así como los requerimientos de respaldo y disponibilidad, retención (tiempo de almacenamiento), desecho, y necesidad relativa


de cifrado (encripción). El modelo debe promover la seguridad informática en todos los alcances pertinentes. 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. Finalmente el proyecto de desarrollo del MAI establecerá una actividad de evaluación de resultados, con el fin de diagnosticar el cumplimiento del objetivo, así como del logro de los productos previstos. El anexo 2 contiene un cuadro de tareas a realizar estableciendo el plazo estimado y los responsables de realizarlas.

Modelo sostenible en el tiempo El modelo debe mantener vigencia, por lo que la organización deberá desarrollar los procedimientos de actualización y documentación pertinentes. El modelo deberá ser la referencia para definir, estandarizar y habilitar la infraestructura tecnológica de la organización, de forma que sea tanto una herramienta de administración de la información, como la base para dirigir la inversión tecnológica con alineación estratégica institucional. Finalmente la organización deberá revisar periódicamente el MAI para medir el alcance de sus resultados y determinar las actividades que requieren seguimiento o mejora.


Asimismo el PETIC deberá contemplar actividades tendientes a mantener vigente el MAI y alinear la perspectiva de desarrollo tecnológico a este modelo, tomando en cuenta tanto los sistemas que ya están operando, como la plataforma tecnológica instalada.

Objetivo del proyecto Actualizar y mejorar el modelo de arquitectura de la información de la CGR, en el transcurso de los próximos doce (12) meses, mediante la identificación, definición y documentación del conjunto de datos requeridos para apoyar la operación y la toma de decisiones en los diversos macro procesos y procesos de la CGR, y proponer un modelo de macro sistemas que apoyen el manejo de esos macro procesos.

Productos • Modelo de arquitectura de información de la CGR (MAI) • Propuesta de modelo de macro sistemas que soporten los macro procesos de Fiscalización Integral, Gobierno Corporativo, Gestión del Conocimiento y Gestión de Recursos.

Subproductos a. Representación lógica del flujo de información institucional, totalmente alineado al modelado organizacional planteado en el último MAGEFI. Debe considerar la creación y uso compartido de la información institucional de forma íntegra, flexible, funcional, eficiente y económica, así como oportuna, y con la debida seguridad. b. Modelo de referencia para clasificar datos a nivel institucional, que permita catalogar los datos con base en su criticidad y sensitividad, propiedad, niveles de seguridad (acceso, respaldo y disponibilidad, así como


requerimientos de cifrado), retención y desecho. El modelo de referencia debe ser documentado. c. Diccionario de datos institucional debidamente actualizado y documentado, con las respectivas reglas de sintaxis, que identifique y regule la utilización de los datos en los procesos; los clasifique y establezca la seguridad a aplicar. d. Procedimientos de actualización y documentación del modelo de arquitectura de información.

Factores críticos de éxito del MAI y gestión de riesgos 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: FCE de PETIC y PTAC

Correspondencia para el MAI

Potencial humano: La participación del personal

El equipo encargado del desarrollo del MAI debe

a partir de un perfil de competencias claramente

estar conformado por representantes de las

definido y adecuado a las tecnologías de

diversas unidades de la CGR, de manera que,

información facilitará el logro de las iniciativas

en conjunto, reúnan suficiente conocimiento y

contenidas en este plan.

experiencia sobre la institución, sus cometidos estratégicos, sus procesos y además sobre metodologías ampliamente aceptadas para el desarrollo de modelos de arquitectura.

Los funcionarios que se consulten en las diversas fases de desarrollo del MAI deben también ser de amplia experiencia en la institución y en los procesos respectivos.


Evolución:

Depuración,

documentación

Los requisitos para el desarrollo del MAI deben

y desarrollo del modelo de información y

contemplar

los

aspectos

de

depuración,

comunicación institucional.

documentación y desarrollo, partiendo de los insumos disponibles en la CGR.

Reactivación del “comité gerencial de tecnologías

El Comité Gerencial de Tecnologías de información

de información y comunicación”.

y comunicación debe conocer y aprobar el modelo de arquitectura, para que en conjunto con el modelo de infraestructura tecnológica, sea usado como base para la evolución en materia de tecnologías dentro de la organización.

Planificación detallada: se refiere al proceso

El

de planificación táctica, el cual desarrollará el

reformulaciones deberá tomar como referencia el

portafolio de proyectos, y al grupo de indicadores

modelo de arquitectura de información y alinear

de

las

la cartera de proyectos para que dicho modelo

actividades de ejecución continua que resulten

sea desarrollado, orientando las acciones hacia

pertinentes.

el logro de los objetivos para los cuales el MAI

gestión

necesarios

para

gestionar

PTAC

en

sus

futuras

revisiones

y

fue creado.

El MAI debe incluir una especificación de variables a medir u observar para dar cuenta de en qué medida está logrando un valor agregado al manejo de la información y las comunicaciones en la CGR. Asimismo, el PETIC y PTAC están expuestos a riesgos internos y externos que requieren medidas de gestión para aprovechar las probables oportunidades y mitigar las potenciales consecuencias negativas, según lo establecen ambos planes, respecto de lo cual también se puede establecer una correspondencia para el MAI:


Áreas generales de riesgo

Correspondencia para el MAI

en PETIC- PTAC EXTERNOS Contenido presupuestario: En vista de Debe preverse oportunamente si el que el presupuesto de la CGR depende desarrollo e implementación del MAI va del presupuesto nacional, pueden ocurrir a demandar recursos adicionales a la recortes en algunos rubros que obliguen dedicación de los funcionarios de CGR a disminuir el alcance y cumplimiento del que participarán en su planteamiento, portafolio de proyectos. O bien, puede tales como determinada disponibilidad suceder que aún existiendo el contenido tecnológica, asesorías, capacitación y presupuestario,

éste

no

haya

sido referencias bibliográficas.

estimado de forma adecuada, de manera que los recursos sean insuficientes para cumplir con los objetivos planteados.

No disponer de recursos externos, alianzas y convenios con entidades que tengan experiencia en el desarrollo de modelos de arquitectura de información. INTERNOS


Viabilidad de los proyectos: Los proyectos requieren condiciones particulares para realizarlos, según sus características tecnológicas,

jurídicas

y

de

otra

naturaleza.

No contar con un marco de referencia para la gestión del los proyectos en cuanto a su iniciación, planificación, ejecución, control y cierre, o aplicar ese marco de referencia deficientemente. Dependencia del proyecto MAGEFI: Que el nivel de detalle de la documentación de los procesos que se requiere no sea suficiente para el desarrollo del MAI.

Potencial humano capacitado: Contar El personal no cuenta con el tiempo con

personal

humano

capacitado, suficiente para dedicarse a las tareas

un perfil apropiado y el proceso de propias del desarrollo del modelo de capacitación facilitará aún más que el arquitectura de información. personal pueda desarrollar sus tareas y apoyar el cumplimiento de los objetivos institucionales.

Los expertos funcionales requeridos para el desarrollo del proyecto MAI tienen a su vez que dedicarse a las exigencias del proyecto de MAGEFI, en cuanto al desarrollo detallado de la documentación de los procesos de la organización.


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.


Anexo 1

Orientaciones estratégicas para el modelo de arquitectura de información y comunicación institucional El PETIC de la Contraloría General establece una situación deseada a mediano plazo (2010), caracterizada en los siguientes términos: • Gestión de TIC. La CGR contará con un marco de gestión basado en mejores prácticas, con los métodos, técnicas, métricas y herramientas respectivas que permitan la eficiencia, eficacia y economía de los servicios de TIC. • Infraestructura tecnológica. En los próximos 5 años, la CGR fortalecerá la infraestructura tecnológica en términos de capacidad, disponibilidad, eficiencia, y actualización. Para tal efecto, se considerará los equipos principales, el software de apoyo y de seguridad, la capacidad de almacenamiento masivo, el apoyo al usuario final, y la creación de capacidad del recurso humano. • Comunicaciones. La CGR incrementará su capacidad de conectividad externa e interna de forma útil y eficiente, segura y con alta disponibilidad. Se procurará la incorporación de tecnologías de comunicación inalámbrica y equipos móviles de computación de alto desempeño, así como redes convergentes (v.gr. datos, voz, vídeo) y telefonía basada en servicios de Internet. • Sistemas de información. La CGR desarrollará sistemas de información mediante la integración de los macro procesos institucionales. La contratación de servicios por outsourcing será una opción para el desarrollo de soluciones, dependiendo del sistema y del personal disponible en la CGR. • Suministro de servicios. Se facilitará el intercambio y el registro de la información desde las instituciones y entidades privadas sujetas de fiscalización, para que oportunamente la CGR analice, procese, y genere


productos soportados en tecnologías, tal como un almacén de datos gubernamental, junto con sistemas aplicativos que permitan explotar tal información. La CGR fortalecerá su Centro de Llamadas con el objetivo que nuestros clientes externos tengan un adecuado soporte para el mejor uso de los sistemas de información y comunicación. • Potencial humano. Se contará con un recurso humano entusiasta y dispuesto a fundamentar la ejecución de su trabajo en las tecnologías de información y comunicación que la Contraloría le facilita. Lo anterior, requiere definir y actualizar constantemente el perfil del funcionario que reúna las condiciones que permitan implementar este plan. Además, el PETIC señala que esa situación deseada responde a un modelo de información y comunicación institucional que, en un nivel preliminar de esbozo, muestra: • Los macro procesos institucionales y su relación sistémica apoyada en la gestión estratégica de las TIC, expresada en cuatro líneas de acción definidas como base para el alineamiento del PETIC con la Estrategia Institucional, a saber: Seguridad y Control, Inserción tecnológica, Suministro de servicios e Infraestructura Tecnológica;

Ese funcionamiento integrado de los macroprocesos institucionales, soportado en bases de datos para la gestión del conocimiento y el apoyo a la toma de decisiones, con una orientación hacia la administración de riesgos, se esquematiza en el PETIC.


Orientaciones tácticas para el modelo de información y comunicación institucional Por su parte, consecuentemente con el referido planteamiento del PETIC, el correspondiente PTAC, en punto al referido esbozo del modelo de información y comunicación institucional, establece que: • Cada macro proceso institucional estará soportado por un macro sistema. • Cada macro sistema estará compuesto a su vez por una serie de soluciones que solventan necesidades específicas de información, y • Los macro sistemas estarán integrados funcionalmente, para apoyar el proceso de toma de decisiones.

䤀洀瀀氀椀挀愀洀愀瀀攀漀搀攀氀漀猀瀀爀漀挀攀猀漀猀

䌀漀渀琀爀愀氀漀爀愀䜀攀渀攀爀愀氀搀攀氀愀刀攀瀀切戀氀椀挀愀

䤀洀瀀氀椀挀愀愀渀氀椀猀椀猀搀攀猀椀猀琀攀洀愀猀氀攀最愀搀漀猀

匀攀最甀爀椀搀愀搀礀挀漀渀琀爀漀氀䤀渀昀漀爀洀琀椀挀漀

䤀渀猀攀爀挀椀渀吀攀挀渀漀氀最椀挀愀

El PTAC prefigura esa orientación de la siguiente manera:

䴀愀挀爀漀瀀爀漀挀攀猀漀䜀漀戀椀攀爀渀漀䌀漀爀瀀漀爀愀琀椀瘀漀

䴀愀挀爀漀瀀爀漀挀攀猀漀䘀椀猀挀愀氀椀稀愀挀椀渀䤀渀琀攀最爀愀氀

䴀愀挀爀漀瀀爀漀挀攀猀漀䜀攀猀琀椀渀搀攀刀攀挀甀爀猀漀猀

䴀愀挀爀漀瀀爀漀挀攀猀漀䜀攀猀琀渀搀攀氀䌀漀渀漀挀椀洀椀攀渀琀漀

䴀愀挀爀漀猀椀猀琀攀洀愀




䈀愀猀攀搀攀搀愀琀漀猀瀀愀爀愀氀愀最攀猀琀椀渀搀攀氀挀漀渀漀挀椀洀椀攀渀琀漀䤀渀昀爀愀攀猀琀爀甀挀琀甀爀愀搀攀吀攀挀渀漀氀漀最愀猀搀攀䤀渀昀漀爀洀愀挀椀渀

Adicionalmente, el PTAC, al suministrar algunos elementos adicionales que ayuden a construir ese modelo de información y comunicación institucional, señala que:


• La integración de los macro sistemas y sus aplicaciones conllevará a la creación de un almacén de datos (datawarehouse) que depositará las variables de datos más importantes para apoyar el negocio institucional. Los sistemas locales aportarán datos para la mayoría de esas variables, y en el caso de información no disponible internamente, la CGR tendrá que convenir con otras instituciones para que pueda extraer datos de sus repositorios y bases de datos externas. • Este almacén de datos institucional debe facilitar la minería de datos, que básicamente consiste en el análisis de tendencias, evaluación de datos comparativos y la generación de alertas sobre condiciones de riesgo en la administración de la Hacienda Pública. • Al efecto, si bien la Contraloría General cuenta actualmente con un único repositorio de datos, no cuenta con las herramientas, experiencia, y desarrollo necesario. Éste carece de las funcionalidades de minería descritas, no obstante representa un importante avance en las aspiraciones de integración mencionadas. • La integración de la información implica un proceso de varias etapas. En primer lugar, la coordinación con la División de Estrategia Institucional en cuanto al mapeo y actualización de los macro procesos institucionales y la visualización de las soluciones y servicios tecnológicos que correspondan, tales como acceso a tecnologías móviles, conectividad, telefonía, y seguridad, entre otros. • Posteriormente, se debe analizar y evaluar la vigencia y nivel de servicio de los sistemas existentes y de aquellos que están en desarrollo actualmente. Por cuanto la institución cuenta con un único repositorio de información, será relativamente menos compleja la obtención de datos para la generación de alertas y de información relevante para la fiscalización, lo que permitirá un trabajo más eficiente y de mejor calidad. • Este proceso de integración sistemática de la información debe estar soportado por una infraestructura tecnológica que garantice la seguridad y


el máximo aprovechamiento de la capacidad tecnológica, a la cual la CGR dará mantenimiento y actualización. Asimismo, para el desarrollo de los macro sistemas y para la infraestructura tecnológica, la CGR aplicará una estrategia de seguridad y control basada en “mejores prácticas”. • Precisamente, por su importancia estratégica, la CGR planificará la infraestructura de la tecnología de información simultáneamente con el desarrollo de los procesos anteriores. La institución desarrollará y promoverá el uso de conexiones inalámbricas, la transmisión de voz sobre Internet, la optimización de los canales de acceso a Internet y otros servicios de conectividad, que permitan el acceso agilizado de los fiscalizadores al repositorio de bases de datos institucional. Lo anterior implica necesariamente el incremento de la capacidad de procesamiento, almacenamiento y conectividad de los servidores institucionales.


Anexo 2

Tabla de actividades propuestas y estimación de tiempo. Actividad

Responsable(s)

Tiempo estimado Junio 2008

Desarrollo de un diagnóstico de la situación Equipo MAI actual de la CGR respecto del modelo de madurez propuesto. Desarrollar instrumentos para la captura Equipo MAI

Junio 2008

de información que sirva de insumo para crear el MAI. Coordinar con equipo MAGEFI. Realizar talleres con expertos en los Equipo MAI diversos procesos de la CGR.

Coordinación

Julio 2008 con

Equipo MAGEFI Documentación por parte de los expertos Expertos en los procesos Segundo de los datos asociados a cada proceso.

semestre

2008 Clasificación de los datos de los procesos, Expertos en los procesos Segundo tipificar criticidad y seguridad.

semestre

Reunir y tabular la información que los Equipo MAI

2008 Noviembre

expertos provean respecto a la información

2008

que se utiliza en su proceso.

Enero 2009

Elaborar representación lógica del MAI.

Equipo MAI

Primer semestre

Elaborar documentación y diccionario del Equipo MAI

2009 Primer

MAI.

semestre

Plantear Macro-Sistemas que soporten los Equipo MAI

2009 Mayo 2009

macro-procesos.


Plantear

los

procedimientos

de DEI

actualización futura del MAI.

Equipo MAI

Segundo semestre

Utilización del MAI como herramienta DEI

2009 Segundo

para dirigir la inversión tecnológica con USTI

semestre

alineación estratégica institucional.

2009

Evaluación de resultados y revisión de DEI

Segundo

logro de objetivos y productos previstos.

semestre 2009

Equipo MAI


Anexo - NTP6

Informe de gestión 2008-01



Contraloría General de la República Normas Técnicas Informe de seguimiento 2008-01 Introducción El propósito de este documento es informar sobre las actividades realizadas al 30 de junio del 2008; en la Contraloría General de la República, con base al cronograma en ejecución establecido para cumplir con la implementación de las normas técnicas para la gestión y el control de las tecnologías de información, de acuerdo con la resolución Nro. R-CO-26-2007 emitida por el Despacho de la Contralora General, en La Gaceta Nro. 199 del 21/06/2007.

Actividades ejecutadas a. Se creo una Comisión Institucional Ad Hoc; como equipo de trabajo, para la elaboración del plan que permita el cumplimiento de las Normas Técnicas. El grupo lo coordina la Sra. Sub Contralora General, Licda. Marta Acosta, y lo integran la Licda. Rebeca Calderón y los Lics. Ronald Castro, José Alpízar, y Miguel Aguilar, en representación de las diferentes unidades. b. Como responsable de la implementación se designó a la Unidad de Sistemas y Tecnologías de Información (USTI) representada por Miguel Aguilar, quien coordina reuniones semanales con los especialistas de las diferentes áreas de la USTI, para seguimiento del plan de ejecución; en esta actividad se cuenta con la asesoría de José Alpízar. c. Se reactivó el Comité Gerencial de Tecnologías de Información y Comunicación (CGTIC), el cual está presidido por la Sub Contralora General. Norma 1.6. d. La comisión elaboró un diagnóstico de la situación actual, el cual incluye las acciones y productos esperados para cerrar la brecha existente, así


como el respectivo cronograma. Ambos documentos fueron validados por el CGTIC. e. Como parte de la promulgación y divulgación de un marco estratégico, se impartieron charlas al cuerpo gerencial y a funcionarios sobre el Plan Estratégico en Tecnologías de Información y Comunicación (PETIC), sobre el Plan Táctico (PTAC), y sobre el campo de acción E del Plan Estratégico Institucional. Norma 1.1. f. Se aprobaron en el CGTIC las prioridades y los proyectos a desarrollar, de acuerdo con las recomendaciones del PTAC. Se crearon los equipos de trabajo con sus respectivos líderes, y se les capacitó en el uso de herramientas para elaboración y seguimiento de proyectos. Norma 1.1. g. Se identificaron y definieron los riesgos generales en TI, se elaboró un manual de riesgos para la gestión y valoración trimestral, y se capacitaron dos funcionarios de USTI en SEVRI. Se está a la espera del estándar institucional a generar por parte de la División de Estrategia Institucional (DEI), para integrar estos riesgos de T.I con los definidos a nivel de la institución. Norma 1.2. h. Ya se tiene la estructura del Manual de Gestión de Calidad sobre las áreas de acción de TI; así como el diseño de un sistema de información que permita el registro de solicitudes por servicios de TI, soluciones, y métricas para mejora continua y control de calidad; se iniciará con la construcción del mismo. Norma 1.3. i. Los proyectos de TI están siendo fortalecidos por una participación cada vez más comprometida de los patrocinadores, evidente en el aporte de recurso humano. Buscando la estandarización en cada equipo, se les brindó la inducción necesaria para que apliquen la Guía Metodológica para desarrollo de proyectos. Norma 1.4. j. Respecto a la Guía Metodológica para el desarrollo de proyectos se realizó en la USTI una revisión de ésta, recopilando una serie de mejoras propuestas por el mismo personal que desarrolla las aplicaciones. Se elaboró la nueva


guía y se distribuyó a todos los líderes de proyecto, los cuales quince días después emitieron sus observaciones y recomendaciones para ser consideradas en a versión final,

generándose un único instrumento

metodológico para guiar el rumbo de acción de los proyectos de tecnología en la CGR, el cual se encuentra en su etapa final. Norma 1.4, 3.2 k. Se elaboró un Marco de Seguridad integral –actualmente en borrador-, en proceso de revisión, el cual incluye las Directrices de Seguridad aprobadas y en ejecución. Para efectos de divulgación; entre otros, se coordinó con RH para que como parte de la inducción se incluya lo correspondiente a seguridad en TI. Norma 1.5. l.

Sobre planificación de la capacidad, se trabaja en la elaboración de un manual –actualmente en borrador- para definir las unidades de medida, métricas e indicadores que sustenten las decisiones y orienten la evolución de la plataforma tecnológica. Norma 4.2.

m. Los compromisos de gestión y el PAO están alineados a la gestión estratégica de TI. Norma 2.1. n. Se tiene un equipo de trabajo actualizando el modelo de la Arquitectura de Información, para lo cual elaboró un diagnóstico de situación y un instrumento metodológico para su construcción. Este equipo ha realizado una investigación de mejores prácticas metodológicas para el desarrollo de dicho modelo, y se tomó la decisión de utilizar la metodología Bussiness System Process (BSP). Norma 2.2. o. El presupuesto de inversiones del 2009 está elaborado con base al PTAC. Norma 2.5.


Al 30 de junio se considera que la implementación de las normas técnicas avanza satisfactoriamente y que el ritmo de trabajo permite visualizar el cumplimiento de las mismas en la fecha establecida. Saludos cordiales, Miguel Aguilar

Anexo - NTP7

Guia Metodológica para administración Proyectos TI



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). La presente Guía Metodológica, se elabora no sólo para efectos de estandarización, sino también en cumplimiento con lo establecido en el Manual de Normas Técnicas para la Gestión y el Control de las Tecnologías de Información, emitidos por la CGR. Esta metodología para la administración de proyectos de TIC tiene como objetivo, esbozar una serie de pasos comunes a seguir, con el fin de mejorar las probabilidades de éxito de los proyectos, teniendo siempre presente que en última instancia el éxito de los mismos está en función del nivel de motivación y mística de que estén impregnados en los integrantes del equipo de trabajo, de la disponibilidad de recursos y del nivel de apoyo que brinde oportunamente la alta Gerencia. Un proyecto en Tecnologías de Información y Comunicaciones (TIC) es todo aquel que introduzca en la organización elementos tecnológicos que soporten y hagan más eficiente la ejecución o el desarrollo de un proceso. Se consideran como proyectos de este tipo, el desarrollo de un sistema automatizado, o la implantación de una solución tecnológica de hardware o de software, lo cual hace que el mismo proyecto sea muy distinto y variado en cuanto a sus actividades se refiere. Todo proyecto en TIC deberá estar siempre orientado al logro de los objetivos institucionales y obtiene su sentido en la medida que aporta un valor agregado a la organización, respondiendo a sus necesidades de manejo de la información y del conocimiento.


Para los efectos de esta metodología, se define un proyecto como: “Una secuencia de tareas con un principio y un final, limitadas en el tiempo por los recursos y los resultados deseados”. 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. Si el equipo a cargo del proyecto esta consciente de que su trabajo es importante y necesario para la organización, estará en una mejor posición para enfrentar y vencer, la serie de obstáculos que todo proyecto sin excepción enfrenta. En el desarrollo de todo proyecto existen diferentes actores cuyos roles serán debidamente establecidos dentro de la presente guía metodológica. En el anexo 1 se presentan cada uno de los diferentes roles involucrados, que serán partícipes de las actividades planteadas en cada una de las etapas del proyecto. Como todo instrumento metodológico está sujeto a mejoras en el tiempo, aspecto que se explica en el anexo 2. 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 Definir la guía metodológica para el desarrollo de proyectos en Tecnologías de Información y Comunicaciones, que será aplicada en la Contraloría General de la República.


3. Objetivos específicos a. Definir un marco de referencia común para todos los proyectos de TIC, uniformando técnicas y métodos de trabajo. b. Establecer las etapas y actividades a realizar, así como los entregables en cada una de ellas. c. Definir para los proyectos que contemplen el desarrollo de un sistema de información automatizado, las fases a cumplir con sus diferentes entregables. d. Señalar la organización, las funciones y las responsabilidades de los involucrados en el proceso de desarrollo de un proyecto de TIC.

4. Etapas de los Proyectos de TIC A continuación se presentan las etapas de un proyecto, con un breve detalle de los objetivos para cada una de ellas, en función de lograr los resultados deseados a tiempo y dentro del presupuesto esperado. (Ver figura # 1) 4.1. Etapa 0. Anteproyecto. La organización identifica una serie de necesidades que pueden ser atendidas mediante el desarrollo de un proyecto. • Se determinan las expectativas generales de los interesados, así como el efecto y resultados esperados. • Identificar los actores involucrados en el proyecto a desarrollar. • Confeccionar la ficha de anteproyecto. • Someter el anteproyecto a la evaluación del Comité Gerencial de Tecnologías de Información y Comunicación (CGTIC), el cual valorará su viabilidad y prioridad dentro de la organización.


4.2. Etapa 1. Iniciación. • Corroborar las expectativas generales de los usuarios, gerentes y de cualquier otro interesado, para establecer los resultados esperados y el alcance del proyecto. • Definir la organización del proyecto y seleccionar el equipo de trabajo. • Realizar un informe de diagnóstico que permita establecer las diferentes opciones de solución a ser evaluadas. • Elegir la alternativa de solución a ser desarrollada. 4.3. Etapa 2. Planeación. • Revisar los objetivos y alcances del proyecto en función de un adecuado balance entre resultado, tiempo y recursos. • Listar las tareas y actividades que se deben ejecutar para lograr los alcances definidos del proyecto. • Secuenciar u ordenar las actividades en función de las dependencias técnicas entre ellas y de los recursos disponibles. • Elaborar el calendario de requerimientos de recursos en el tiempo, para lograr los alcances deseados. • Obtener la aprobación para el plan de trabajo. • Mantener los planes de trabajo balanceados durante todo el desarrollo del proyecto, en función de las variaciones que se produzcan en los alcances, tiempos y recursos. 4.4. Etapa 3. Ejecución. • Asignar, controlar, supervisar y liderar el desarrollo de las actividades planeadas. • Efectuar reuniones de trabajo entre los integrantes del equipo de trabajo y el líder del proyecto.


• Comunicación constante entre los diferentes participantes en el proyecto y hacia la Unidad Ejecutora; comunicación que debe ser promovida por el líder del proyecto. • Gestionar la solución de los problemas que puedan surgir durante la ejecución y asegurar la consecución de recursos (dinero, gente, equipo), para llevar a cabo el proyecto. • Si el proyecto tiene como objetivo el desarrollo de un sistema automatizado, deberá desarrollar las fases indicadas en el anexo 4. 4.5. Etapa 4. Control. • Monitorear las desviaciones del plan y determinar sus posibles causas. • Efectuar las acciones correctivas para lograr la ejecución del plan. • Evaluar los requerimientos de cambios solicitados por los patrocinadores y los miembros del grupo; determinando el impacto en los alcances, en el tiempo o en los recursos. • Detectar variaciones en los alcances, en la asignación de recursos o en el tiempo en que se deseen lograr los resultados. • Retornar a la Etapa de planeación para hacer ajustes a las metas del proyecto y obtener aprobación de los patrocinadores, si fuese necesario. 4.6. Etapa 5. Conclusión. • Documentar las lecciones aprendidas durante su ejecución. • Informar sobre la terminación y los alcances logrados. • Consolidar toda la documentación generada. • Elaborar el informe final de proyecto. • Liberar los recursos asignados. • Entregar el informe final al Patrocinador.


Inicio

Figura # 1. Fases de un Proyecto.

Pl

n

an

ea

ció

Eje

cu

ció

n

Cierre

Control

A continuación se presenta de forma detallada las acciones que se deben realizar en cada una de las etapas.


6. Anteproyecto (Etapa 0) Todo proyecto tecnológico a desarrollar debe estar contemplado en el Plan Táctico de TIC (PTAC), el cual responde a las orientaciones que plantea el Plan Estratégico de Tecnologías de la Información y Comunicaciones (PETIC) de la Contraloría General de la República (CGR). El proceso de actualización del PTAC, que se realiza periódicamente; establece según las prioridades de la organización, cuales son los proyectos que se deben desarrollar con el fin de aportar el soporte tecnológico que la organización necesita para mantenerse actualizada y apoyada para el cumplimiento de sus metas y objetivos. 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. Los anteproyectos que no sean incluidos en el PTAC deberán ser re-evaluados en sus alcances y objetivos, cada vez con un mayor nivel de detalle, hasta que llegue el momento de incluirlo en una reformulación del PTAC. Dados los procesos de planeación estratégica, el anteproyecto sobrevivirá y llegará a ser un proyecto operativo, mientras el mismo tenga como alcances una función estratégica dentro de la organización. Si el mismo perdiera vigencia o dejara de ser importante para la organización, el mismo proceso de planeación se encargaría de eliminarlo. La organización como un todo y la USTI, realizarán cada año el ejercicio de planeación operativa (PAO), con un horizonte de planeación de dos años. Tomando como insumo la cartera de proyectos del PTAC, la USTI define los alcances, se detallan los recursos y se plantea un horizonte de tiempo esperado, para cada uno de los proyectos.


Para la estimación del tiempo, se puede recurrir a diferentes técnicas, como lo es el juicio experto o la comparación con proyectos ya concluidos. 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. 5.1. Planteamiento de los anteproyectos 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. En el proceso de planeación estratégica de la CGR se determinarán dichas necesidades y de un primer análisis de éstas se deberá plantear ante la jefatura de la USTI, una ficha de anteproyecto. Dicha jefatura realizará un análisis inicial de la propuesta antes de someterla a evaluación del CGTIC; el cual asignará una prioridad con la cual determinará si debe permanecer en espera de ser atendido o si es contemplado dentro de la siguiente revisión y reformulación del PTAC; todo conforme al proceso de planeación explicado anteriormente. El formato para la ficha de anteproyecto se encuentra detallado en el anexo 7. 5.2. Ajustes a los anteproyectos Cuando un anteproyecto requiera ajustes o replanteamientos, deberá reformularse la ficha de proyecto y volver a someterlo ante la jefatura de la USTI, quien le realizará un análisis y lo someterá a consideración del CGTIC.


Cualquier cambio en cuanto a los resultados esperados, alcance planeado, efecto, objetivos o productos, requiere de ser aprobado por el CGTIC antes de proceder con la etapa de iniciación del proyecto. 5.3. Productos de la etapa: • Ficha de anteproyecto 5.4. Punto de Control: Evaluación y priorización del anteproyecto por parte del CGTIC.


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. Una vez establecido formalmente quienes asumen las funciones de Patrocinador(es) de Proyecto, Líder de Proyecto y Líder Técnico de Proyecto; estos inicialmente proceden a realizar un diagnóstico de la situación con el fin de establecer estrategias de solución, para que el patrocinador del proyecto determine la forma en que se desarrollará. 6.1. Organización para el proyecto 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. La organización del proyecto requiere la interacción de personas de las diferentes áreas, según la siguiente definición de estructuras: • Unidad Ejecutora • Grupo de Apoyo • Equipo de Trabajo • Equipo de apoyo técnico Cada uno de los participantes tiene asignadas tareas y responsabilidades específicas, para un adecuado desempeño de su función.


Los participantes en el proyecto que conforman la organización descrita, son identificados como sigue: Participantes por parte de la unidad(es) patrocinadora(s): • Patrocinador(es) del Proyecto • Líder del Proyecto • Equipo de Trabajo Participantes por parte de la USTI:

• Coordinador de Proyectos (Jefatura o funcionario asignado) • Líder Técnico • Equipo de apoyo tecnológico Para la conformación de la organización del proyecto de TIC se deberá considerar el siguiente organigrama:

Organigrama del proyecto

Patrocinador del proyecto Grupo de apoyo

Coordinador de proyectos Líder de proyecto Líder Técnico Unidad Ejecutora

Equipo de trabajo

Equipo de apoyo técnico


Para un mayor detalle de los perfiles y de las responsabilidades de los miembros permanentes ejecutores de un proyecto de TIC, refiérase al anexo 3 de la presente metodología. A continuación se presenta una explicación de cada uno de estos ejecutores del proyecto: 6.1.1. Unidad Ejecutora La Unidad Ejecutora es el ente coordinador de los aspectos relacionados con el desarrollo del proyecto de TIC. Sus responsabilidades principales son: • Aprobar la organización, los recursos, y el cronograma del proyecto. • Velar por la calidad de los productos de cada una de las etapas y hacer las recomendaciones necesarias. • Resolver las situaciones que puedan afectar el buen funcionamiento del proyecto. • Aprobar los productos generados y ejercer los puntos de control establecidos en cada etapa. Está constituida por: • Patrocinador(es) del Proyecto (Coordinador) • Coordinador de Proyectos (Jefe de la USTI o a quien designe) • Líder del Proyecto. • Líder Técnico. 6.1.2. Patrocinador del Proyecto

Es el jefe de la Unidad Organizacional para la cual se va a desarrollar un proyecto de TIC. Según sea el proyecto pueden verse involucrados más de un patrocinador.


6.1.3. Grupo de Apoyo Lo conforman funcionarios cuya experiencia y conocimientos son de gran ayuda a nivel de asesoría para el equipo de proyecto. También lo pueden integrar grupos de usuarios con interés en los resultados del proyecto. 6.1.4 Coordinador de proyectos 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. 6.1.5. Líder del Proyecto El Líder del Proyecto es un funcionario con gran conocimiento de su área funcional, aspecto por el cual se le ha conferido la capacidad de tomar decisiones y la responsabilidad de participar activamente en la dirección del proyecto. Vela tanto por los mejores intereses de su área como por los de la Contraloría General de la República, en lo que respecta al proyecto de TIC. Es el responsable directo del proyecto y de los productos entregados. En aquellos casos en donde el proyecto tenga un mayor componente técnico en materia de introducción de nueva tecnología, estará justificado que la dirección sea asumida por un representante de la USTI, por su mayor experiencia en la materia tecnológica. 6.1.6. Líder Técnico del Proyecto Este es un funcionario al cual, por su formación en el área de informática, experiencia y capacidad, se le ha conferido la responsabilidad de administrar los aspectos tecnológicos de un proyecto de desarrollo informático. Es el responsable directo del


desarrollo del proyecto en lo que corresponde a la parte técnica, para ello aplica las políticas, normas y procedimientos de trabajo aprobados. 6.1.7. Equipo de apoyo tecnológico Son los funcionarios especialistas en el área de tecnologías de información que apoyan la labor del Líder Técnico, en materias tales como programación, base de datos, configuración y operación de equipos principales, y conectividad. 6.1.8. Equipo de trabajo Son usuarios de los procesos funcionales involucrados en el proyecto de TIC a desarrollar, conocedores de las necesidades a resolver e involucrados en la implementación de la solución. Un aspecto de primer orden para garantizar el éxito de un proyecto, estará en la escogencia de un excelente equipo de trabajo. 6.1.9. Equipo de proyecto Lo conforman el Líder de Proyecto, el Líder Técnico, el equipo de trabajo y el equipo de apoyo tecnológico. 6.2. Organización del Proyecto La información relacionada con la organización del proyecto debe quedar debidamente formalizada y documentada, para lo cual en el anexo 8 encontrará el formato de documento a utilizar.


6.3. Informe de diagnóstico: El informe de diagnóstico especifica los resultados de la valoración efectuada sobre la solicitud de desarrollo de un proyecto de TIC. Este documento es confeccionado en conjunto por el Líder Técnico y el Líder de Proyecto; debiendo contener las siguientes secciones: 6.3.1. Situación actual 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. En este análisis se debe hacer énfasis en la búsqueda de oportunidades de mejorar los procesos actuales, en procura de que la inserción de tecnología permita la realización de actividades de forma más eficiente y efectiva. 6.3.2. Alcances del proyecto 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


apartado del diagnóstico. Estas expectativas serán de referencia obligada para el equipo de trabajo, con el fin de mantener enfocado el proyecto. Si en algún momento se determinase que alguna de las expectativas enumeradas no podrá ser alcanzada, el grupo de proyecto está en la obligación de comunicar esta situación al interesado con las justificaciones del caso, no sin antes haber evaluado la posibilidad de modificar el proyecto para su cumplimiento. Si en algún momento, se determina que no es factible lograr alguna de las expectativas enumeradas, se deben realizar las modificaciones sustanciales del proyecto, sin descartar la posibilidad de cancelarlo, en caso de que fuese imposible lograr los alcances esperados. Si el proyecto lo que busca es el desarrollo de un sistema de información, en este apartado deberá incluir al menos una descripción de lo que se pretende obtener y hasta dónde se desea llegar con la automatización. 6.3.3. Objetivos del proyecto Definición de los objetivos generales y específicos esperados con el sistema o solución tecnológica, con base en lo planteado en la ficha de anteproyecto. Se refieren al nivel de desempeño que se debe lograr para satisfacer una necesidad determinada. 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.


6.3.4. Análisis de riesgo El Líder de Proyecto y el Líder Técnico deberán hacer un análisis de riesgos del proyecto de acuerdo con la metodología establecida institucionalmente, basándose en los siguientes riesgos y otros que considere de relevancia: a. El proyecto no está alineado con la Estrategia Institucional. b. El proyecto no está incluido dentro de la cartera de proyectos del PTAC. c. El proyecto no cuenta con un patrocinador comprometido. d. No se tiene el recurso humano necesario y calificado para el desarrollo del proyecto e. El recurso humano asignado al proyecto no dispone del tiempo requerido para el mismo. f. No se tiene el presupuesto necesario para la ejecución del proyecto. g. No se tiene la infraestructura tecnológica (interna y externa) apropiada para la puesta en operación de la solución tecnológica. h. El personal no tiene la suficiente capacitación para utilizar las herramientas tecnológicas requeridas por el proyecto. i. No se cuenta con el personal calificado en las materias relacionadas con el proyecto. j. Incumplimiento del plan de trabajo k. Los objetivos y alcances del proyecto pueden ser modificados. l. No se tiene la estructura administrativa (interna y externa) para soportar la operación de la solución tecnológica. 6.3.5. Identificación de estrategias de solución y su factibilidad Establecer y explicar las diferentes estrategias de solución para la construcción de la solución tecnológica de acuerdo a los alcances definidos, considerando el análisis de factibilidad económica, operativa y técnica.


Cuando se planteen dos o más estrategias de solución se deberá realizar un análisis comparativo entre ellas de ventajas y desventajas. Dentro de este análisis y en la medida de lo posible, se deberá realizar un análisis de costo/beneficio de las estrategias propuestas para hacer una evaluación de su factibilidad económica definida en términos de costos y ahorros. No sólo tomando en cuenta los costos de implementación de la solución sino también los costos asociados a su sostenibilidad durante su operación. Este análisis económico es fundamental para los proyectos donde se tenga adquisición de nueva tecnología. 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. El nivel de detalle de esta evaluación dependerá directamente de la complejidad del proyecto y de los recursos disponibles para la elaboración del estudio. En cualquier caso deberá contemplar las variables básicas que determinen la viabilidad del proyecto y su permanencia en el tiempo. 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.


Para cada una de las estrategias de solución se deberá identificar: • Ventajas y desventajas (Costo/Beneficio) • Factibilidad operativa, técnica, económica y legal • Riesgos asociados • Complejidad técnica en el desarrollo y en la implementación 6.3.6. Recomendación de una estrategia de solución Cuando se tengan dos o más estrategias de solución y basado en las consideraciones anteriores; el equipo de proyecto recomendará una de las estrategias de solución; o según sea el caso podría recomendar no continuar con el desarrollo del proyecto, al no considerarlo factible desde el punto de vista económico, operativo, legal o técnico. 6.4. Selección de la estrategia de solución: 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. En la selección de la opción la Unidad Ejecutora puede recomendar al CGTIC alguna de las siguientes decisiones: • Seleccionar alguna de las opciones recomendadas. • Posponer el proyecto para un momento más oportuno, esto de acuerdo con los intereses y prioridades de la Institución. • Cancelar el proyecto ya que el mismo no es viable desde el punto de vista operativo, legal, económico o técnico; o porque las prioridades institucionales así lo requieren.


Cuando la Unidad Ejecutora haya seleccionado el curso de acción para el proyecto que considere más adecuado, deberá documentarlo utilizando el formulario que se detalla en el anexo 9. 6.5. Insumos de la etapa: Ficha de anteproyecto. 6.6. Productos de la Etapa: • Informe de diagnóstico. • Descriptivo de la Organización del Proyecto. • Estrategia de solución para el proyecto. 6.7. Puntos de Control: El patrocinador (o patrocinadores) del proyecto oficializa(n) los nombramientos del líder de proyecto, así como la conformación de los equipos de trabajo, y la USTI la del líder técnico y la del equipo de apoyo técnico. La Unidad Ejecutora del proyecto define la estrategia de solución para el proyecto, eligiendo el curso de acción a partir del análisis de las diferentes opciones planteadas en el informe de diagnóstico.


7. Planeación (Etapa 2) El principal objetivo de esta etapa es especificar a un nivel detallado, las diferentes actividades a realizar, reflejadas en un plan de trabajo. Para ello el equipo de trabajo deberá empezar por analizar los objetivos y alcances del proyecto, deberá identificar los recursos requeridos y establecer un cronograma de proyecto. Se debe utilizar el software institucional para administración de proyectos. 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. Siendo la labor de planeación cíclica, como se muestra en la figura # 1, la misma se debe realizar tanto para el inicio, como durante la realización del proyecto. Si el proyecto mostrase atrasos considerables en alguna de sus etapas, que no pudiesen ser absorbidos por las holguras de los proyectos, o bien por un esfuerzo adicional que ubique de nuevo el proyecto en su planeación inicial, se debe realizar un nuevo plan de proyecto, para el resto de las actividades a cumplir. Esta nueva versión del plan puede variar los alcances del proyecto, o bien la calidad y cantidad de recursos asignados. 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.


7.1. Elaboración del Plan de Trabajo: Teniendo siempre presente cual es el objetivo que se pretende, se recomienda cumplir con los siguientes pasos, en un trabajo grupal. a. Se debe elaborar una lista o enumeración de todas las actividades que se deben realizar para cumplir la meta. b. Por cada actividad se debe tener claro cual es su propósito y el producto a lograr a su conclusión. c. El producto a lograr por cada actividad debe ser claro y conciso, si no es así se debe desglosar o partir la actividad, en tantas como sea necesario para que cada actividad tenga un producto definido y claro. d. Cuando se tengan las actividades debidamente enmarcadas en cuanto al producto a lograr, se debe proceder a definir que recursos humanos o técnicos requiere cada una de ellas. e. Nótese que hasta el momento no nos hemos preocupado por la duración de las actividades ni en que momento se han de ejecutar, nos hemos preocupado por crear consenso sobre lo que se quiere lograr y como lograrlo. El siguiente paso será determinar cuanto tiempo tomaremos en cumplir cada una de las actividades, en función de los recursos que tendremos disponibles. f. El siguiente paso consistirá en agrupar aquellas actividades cuyo producto intermedio o final, sea un componente de un mismo resultado. Todas estas actividades las podemos agrupar en una etapa o subproyecto, al final del cual siempre debe haber un producto claramente definido, al que llamaremos entregable intermedio o final, según sea el caso. La definición de las etapas o subproyectos, depende del tamaño del proyecto, del nivel de control que es necesario tener y del nivel de conocimiento que el grupo tenga sobre la materia.


g. Una vez agrupadas las actividades en etapas o subproyectos, se debe proceder a determinar cual es el tipo de relación que existe entre cada actividad, pudiendo ésta ser, predecesora inmediata o sucesora inmediata o sin relación. Predecesora inmediata será aquella actividad que debe haber sido concluida para que otra sucesora inmediata inicie. h. Entre una actividad predecesora inmediata y otra sucesora inmediata, puede haber un lapso de tiempo que llamaremos holgura, la cual puede ser negativa, cero o positiva. Será cero cuando una actividad de acuerdo al plan debe iniciar de inmediato, tan pronto concluye su predecesora. Será positiva cuando entre el tiempo de conclusión de la predecesora y el inició de la sucesora, pueden transcurrir “n” cantidad de días. Será negativa cuando la actividad sucesora, puede iniciar según el plan, “n” cantidad de días antes de que concluya la actividad antecesora. i. Con toda la información anterior, se debe proceder a balancear las actividades de manera tal que el entregable de la etapa o subproyecto se logre en el menor tiempo posible. Entendemos como balanceo el agrupar las actividades, de manera tal que muchas de ellas se puedan ejecutar en paralelo, cuando los recursos y las dependencias entre actividades lo permitan. Se debe evitar que un recurso quede sobrecargado más allá de lo razonablemente aceptable. En el caso de los recursos humanos, se deben considerar las ausencias planificables, programando por cada recurso el tiempo formalmente comprometido al proyecto. j. Todas aquellas actividades que al final del proceso de planeación presenten una holgura de cero, formarán lo que conoceremos como la ruta crítica. Estas son las actividades que no se deben retrasar, ya que su retrazo implica un atraso de la etapa o subproyecto. Se debe tener presente que aquellas actividades que presenten holguras positivas, una vez consumidas éstas entran a la ruta crítica y podría también retrazar el proyecto.


7.1.1. Fases para el desarrollo de un sistema de información automatizado En el caso de que el proyecto tenga como objetivo el desarrollo de un sistema de información automatizado, el plan de trabajo deberá contemplar las actividades propias de las fases explicadas ampliamente en el anexo 4. Para este caso el cronograma deberá detallar actividades agrupándolas por cada fase. Cuando un sistema requiera de ajustes por la atención de nuevos requerimientos, sin que esto pueda ser calificado como un cambio de versión en dicho sistema, su atención deberá cumplir con las fases propias del control de cambios para el mantenimiento de sistemas, mismas que están explicadas en el anexo 5. 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. 7.2. Formulario de planeación de recursos: Para documentar los diferentes recursos que se necesitan en el proyecto y el momento en que se requieren, deberá utilizarse el formulario que se detalla en el anexo 10. De ser necesario, durante el transcurso del proyecto se documentará en el mismo formulario, cualquier variación de los mismos. 7.3. Insumos de la etapa: • Informe de diagnóstico. • Descriptivo de la Organización del Proyecto. • Estrategia de solución para el proyecto.


7.4. Productos de la Etapa: • Plan de trabajo para el proyecto (Cronograma). • Formulario de planeación de recursos. 7.5. Puntos de Control: 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.


8. Ejecución (Etapa 3) El objetivo de esta etapa es propiamente desarrollar y cumplir el plan elaborado en la etapa anterior.

En reuniones periódicas el equipo de proyecto programa la

ejecución de las acciones a realizar y las metas a alcanzar, acorde con las actividades enumeradas en el plan general. Durante esta etapa el Líder de Proyecto deberá mantener informada a la Unidad Ejecutora respecto del avance en el desarrollo de las actividades, situaciones no planeadas que se presenten, actividades no programadas y resolución de problemas. 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. 8.1. Minutas de reuniones: No se debe menospreciar la importancia de las reuniones, por lo que es de suma importancia el dejar documentados todos los asuntos y acuerdos tratados en las reuniones, sean estas calendarizadas o no. El Líder de Proyecto deberá mantener como parte de la documentación del proyecto, las minutas de las reuniones que se realicen. Para la creación de las minutas deberá utilizarse el formulario que se presenta en el anexo 6. 8.2. Informes de avance: 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.


El informe de avance deberá ser corto y contener las siguientes secciones: • Tareas planeadas y completadas. • Tareas planeadas no completadas. • Tareas completadas no planeadas. • Gráfico de avance mensual y de avance acumulado. • Administración del riesgo. • Acciones correctivas o preventivas ejecutadas. • Observaciones. El informe de avance va dirigido a la Unidad Ejecutora del Proyecto y es responsabilidad del Líder del Proyecto no solo entregarlo, sino asegurarse de que es comprendido. 8.3. Productos intermedios propios del proyecto de TIC. Dependiendo del tipo de proyecto, durante su ejecución se presentarán productos intermedios (documentales o no) que deberán ser evaluados y en algunos casos aprobados por la Unidad Ejecutora.

En el caso de un proyecto de desarrollo de

sistemas de información los productos intermedios están debidamente identificados en el anexo 4 para cada una de las fases. 8.4. Insumos de la etapa: • Plan de trabajo para el proyecto (Cronograma). • Formulario de planeación de recursos. 8.5. Productos de la Etapa: • Minutas de reuniones. • Informes de avance. • Productos intermedios propios del proyecto de TIC.


8.6. Puntos de Control:

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.


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. 9.1. Cronograma de proyecto actualizado: El cronograma debe actualizarse periódicamente con el detalle de las actividades que se han completado, el porcentaje de avance de las actividades que están en proceso y los ajustes propios de un proyecto en ejecución donde se presentan nuevas tareas no planeadas o la necesidad de ajustar fechas, producto de desfases que deben quedar debidamente documentados. 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


importante es que el plan esta enmarcado en una realidad de la organización, siendo la misma un ente vivo y cambiante, y así lo será el plan. 9.2. Control de avance por unidades de logro 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. Para la aplicación de unidades de logro deberán seguirse los siguientes pasos: • Debe pasarse a una hoja electrónica la lista de tareas planeadas en el proyecto • A partir del cronograma de trabajo deben identificarse cuales son las tareas que pertenecen a la ruta crítica del proyecto. • A las tareas que son de ruta crítica se les asignará un aporte al logro de 1 UL por cada 2 días que se planea que dure la tarea. Por ejemplo:

una

tarea de ruta crítica que dure 11 días aportará 5.5 UL. • A las tareas que no son de ruta crítica se les asignará un aporte al logro de 1 UL por cada 5 días que se planea que dure la tarea. Por ejemplo: una tarea que no sea de ruta crítica que dura 11 días aportará 2.2 UL. • La tarea aportará sus UL al mes que corresponda con la fecha de finalización planeada.

Por ejemplo: Si la tarea inicia el 15/06/200X y finaliza el


08/08/200X, las unidades de logro de esa tarea se acumularán para el mes de agosto (por esto es importante dividir grandes tareas en tareas menores que mejor contabilicen el logro por mes). • Se suman por mes las UL para tener el total general de UL del proyecto. • Se sumarizan los totales por mes en la tabla de Logro Planeado y Logro Real, según hoja electrónica presentada más adelante. Nótese que de esta forma se hace diferencia entre el logro alcanzado y el avance en el tiempo, haciendo del manejo del porcentaje de avance una valoración real y no una estimación por criterio personal. • Con dicha información se puede crear una hoja electrónica que calcule de forma real el porcentaje de avance con relación a lo planeado y a lo ejecutado; que lo muestre por mes y por acumulado general para el proyecto. A continuación se presenta una hoja electrónica ejemplo que puede ser ajustada para cualquier proyecto.

䌀漀渀琀爀漀氀䄀嘀倀开䴀愀挀栀漀琀攀 ⸀ 砀氀猀

9.3. Formularios de acciones correctivas y preventivas: Cuando en el proceso de control se detecten o prevean desviaciones con respecto a lo que establece el plan de trabajo, de manera oportuna deberán ejecutarse acciones correctivas y preventivas que vengan a mitigar el impacto de dichas desviaciones sobre el logro de los objetivos y metas del proyecto. Las acciones correctivas o preventivas deben estar claramente explicadas e indicar el o los responsables de ejecutarlas. De ser necesario estas acciones deben quedar incorporadas en el plan de trabajo para su futuro seguimiento y documentadas en formularios cuyo formato se detalla en el anexo 11.

debidamente


9.4. Control de cambios. Durante la ejecución de cualquier proyecto se pueden presentar cambios que afecten directa o indirectamente el logro de los objetivos y de las metas. El proceso de control del proyecto deberá analizar; entre otros, los cambios en las condiciones del entorno, los cambios en los recursos, los cambios en las necesidades a solventar, los cambios en la tecnología, cambios en los objetivos, y cambios en la estrategia de solución. 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. 9.5. Insumos de la etapa: • Informes de avance. • Plan de trabajo para el proyecto (Cronograma). • Formulario de planeación de recursos. 9.6. Productos de la Etapa: • Cronograma de proyecto actualizado. • Control de avance por unidades de logro. • Gráficos de avance acumulado y avance mensual. • Formularios de acciones correctivas. • Control de cambios.


9.7. Puntos de Control: 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.


10. Etapa 5: Conclusión En esta etapa se debe revisar el cumplimiento de las metas iniciales a efectos de realizar el cierre del proyecto. Toda etapa de conclusión de un proyecto debe cumplir con las siguientes actividades básicas. • Enterar a los patrocinadores sobre los resultados del proyecto. • Entrega de productos con su respectiva aprobación. • Liberar los recursos que aún estén asignados al proyecto. • Documentar los procesos finales, entendiendo que el proceso de documentación fue un proceso rutinario durante toda la vida del proyecto; por lo que en esta etapa deberá dejarse actualizado el respectivo expediente de proyecto. 10.1. Informe de conclusión del proyecto: 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.


• Costo total del proyecto. • Explicación de las variaciones en el presupuesto. 10.2. Aceptación a satisfacción de los productos finales del proyecto: 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. Luego de la respectiva revisión, el coordinador de la Unidad Ejecutora debe dejar constancia de la aceptación de los productos mediante el formulario detallado en el anexo 13. 10.3. Expediente actualizado del proyecto: 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 de Sistemas y Tecnologías de Información será la encargada de mantener toda la documentación almacenada en un solo expediente o carpeta y de facilitar los medios para que todo funcionario interesado tenga acceso a dicha información. 10.4. Insumos de la etapa: • Cronograma actualizado con ejecución de tareas. • Documentos desarrollados durante el proyecto.


10.5. Productos de la Etapa: • Informe de conclusión del proyecto • Formulario de aceptación a satisfacción de los productos. • Expediente actualizado del proyecto • 10.6. Puntos de Control: La Unidad Ejecutora del Proyecto revisa el informe final del proyecto y lo hace del conocimiento de todos los interesados. La Unidad Ejecutora da por aceptados los productos finales del proyecto.


Anexo 1

Definición de roles En el desarrollo de un proyecto de TIC se presentan diferentes actores con funciones y responsabilidades que se describen a continuación:

• Comité Gerencial de Tecnologías de Información y Comunicaciones (CGTIC): por delegación del máximo jerarca (Contralor o Contralora General), es el máximo ente en lo referente a recomendar sobre las directrices y lineamientos a seguir en la planificación y dirección de los procesos de desarrollo tecnológico. Está conformado por representantes de alto nivel gerencial, por el Jefe de Auditoria Interna como asesor del Comité y por el Jefe la Unidad de Sistema y Tecnologías de Información (USTI). Este Comité reporta al máximo jerarca, quien lo preside. • Patrocinador del proyecto: es el máximo jerarca o en quien éste delegue, de la Unidad Organizacional para la cual se va a desarrollar el proyecto de TIC. • Coordinador de proyectos: este rol es asumido por la jefatura de la USTI o delegado en un funcionario de la misma Unidad, para velar por la adecuada ejecución de los proyectos de TIC observando aspectos como integración, calidad, logro de objetivos y eficiencia en los diseños y desarrollo de las soluciones. • Líder del proyecto: es un funcionario con gran conocimiento de su área funcional, aspecto por el cual se le ha conferido la capacidad de tomar decisiones y la responsabilidad de liderar activamente el proyecto; vela tanto por los mejores intereses de la Contraloría General de la República, como por los de su área en lo que al proyecto concierne. En casos justificados y por recomendación del CGTIC, la dirección puede ser asumida por un representante de la USTI.


• Líder Técnico del proyecto: éste es un funcionario al cual, por su formación en el área de informática, experiencia y capacidad, se la ha conferido la responsabilidad de administrar los aspectos tecnológicos de un proyecto de TIC. • Analista de sistemas: es el recurso profesional en informática (funcionario o no de la Contraloría General de la República) que trabaja bajo la coordinación y dirección del Líder Técnico del proyecto para la realización de tareas propias del proyecto de TIC, cuyas actividades entre otras son: análisis, diseño, desarrollo de los programas, pruebas, capacitación de usuarios, documentación y apoyo técnico a los usuarios en la puesta en operación de una solución tecnológica. • Programador de sistemas: es el recurso profesional en informática (funcionario o no de la Contraloría General de la República) que trabaja bajo la coordinación y dirección del Líder Técnico del proyecto para la realización del sistema y cuyas actividades entre otras son: el desarrollo de los programas, pruebas y documentación de los programas. • Usuario de TIC: se considera a todo aquel individuo (funcionario o no de la Contraloría General de la República) que tenga acceso autorizado a sistemas de Información, o que se beneficie de alguna solución tecnológica. Para efectos de la metodología vamos a considerar usuarios registradores y generadores de información, usuarios de consulta y usuarios expertos de los sistemas o de la tecnología, quienes además de tener acceso o interacción con el sistema o solución tecnológica, son usuarios de amplio dominio sobre el negocio que dicha tecnología o sistema soporta. Es posible que la misma persona desempeñe más de un rol en el desarrollo del proyecto, especialmente si pertenece a la USTI; pero en todo proyecto siempre se debe contar con el apoyo de la contraparte usuaria que tiene las necesidades específicas de manejo de la información y del conocimiento.


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. Esta Unidad adicionalmente deberá considerar las solicitudes de modificación expresas y aportes hechos por Líderes de Proyectos, producto de experiencias previas de aplicación de la misma guía y sus respectivas “lecciones aprendidas”. 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.


Anexo 3

Responsabilidades de los miembros del proyecto Patrocinador del Proyecto Entre sus responsabilidades se destacan las siguientes: • Aprobar formalmente la organización del proyecto. • Designar al Líder del Proyecto. • Aportar el personal de apoyo adecuado para llevar a cabo un análisis integral sobre la factibilidad técnica, legal, funcional y económica, del proyecto a realizar. • Apoyar en la solución de problemas y en la consecución de los recursos. • Aprobar los productos de cada etapa en el proceso de desarrollo del proyecto. • Evaluar, periódicamente, el progreso del proyecto, con base en los planes y los informes de avance, y hacer las recomendaciones que correspondan. • Aprobar ajustes al cronograma, en caso de ser necesario. • Aprobar cualquier cambio en procedimientos de trabajo que requiera la solución tecnológica para ser implementada. • En el caso de un nuevo sistema automatizado, debe aprobar el plan para levantamiento de información, conversión y carga de datos. • Aprobar el plan para capacitación de usuarios. • Aprobar la solución tecnológica y fecha para su entrada en operación.

Coordinador de Proyectos de la USTI. Entre sus responsabilidades se destacan las siguientes: • Actuar como un integrador de los alcances de los diferentes proyectos. • Balancear la utilización de los diferentes recursos de la USTI, sobre todo aquellos que están siendo utilizados en varios proyectos, tanto humanos como tecnológicos.


• Velar porque en cada proyecto se tenga un expediente con la información relevante. • Generar información histórica sobre el desarrollo de cada proyecto y ponerla a disposición de los grupos de trabajo de los nuevos proyectos, para ser utilizada como referencia. • Detectar desviaciones en los diferentes planes de trabajo y velar porque se tomen las medidas correctivas del caso. • Velar porque los diferentes proyectos en ejecución mantengan las orientaciones planteadas tanto en el Plan Estratégico de Tecnologías de Información y Comunicaciones (PETIC), como en el correspondiente Plan Táctico (PTAC). • Generar información operativa de los proyectos para el apoyo a la toma de decisiones por parte de la Jefatura de la USTI. • Apoyar en todos los pasos necesarios para dar inicio a los nuevos proyectos, desde las etapas preparatorias de conceptualización, hasta dejar constituidos y funcionando los equipos de trabajo. • Preparar y motivar a los integrantes de los equipos de trabajo, para que conozcan y cumplan el rol que se espera de ellos. • Mantener el equilibrio en el uso de los recursos asignados a los diferentes proyectos. • Mantener una secuencia lógica entre los alcances de los diferentes proyectos. • Brindar capacitación al equipo de trabajo en el uso de la Guía metodológica para desarrollo de proyectos en TIC.


Jefe de la USTI. El jefe de la USTI puede delegar algunas responsabilidades de coordinación en un funcionario que reúna los requisitos necesarios. Entre sus responsabilidades respecto a los proyectos de TIC se destacan las siguientes: • Coordinar la ejecución de los proyectos aprobados por el CGTIC. • Velar porque el desarrollo de los proyectos de TIC estén de acuerdo con las estrategias y orientaciones definidas en los planes. • Apoyar en la solución de problemas y en la consecución de los recursos. • Recibir, analizar y tramitar las solicitudes por nuevos proyectos de TIC. • Asignar al líder técnico que trabajará en el proyecto. • Participar en las reuniones de la Unidad Ejecutora cuando sea requerido. • Aprobar las diferentes etapas de aquellos proyectos que así lo requieran. • Apoyar al Líder Técnico en los asuntos del desarrollo del proyecto que lo requieran. • Coordinar el cumplimiento del cronograma de trabajo, en conjunto con el Líder del Proyecto y el Líder Técnico. • Identificar situaciones que puedan afectar el cumplimiento de los objetivos, y coordinar las acciones preventivas o correctivas necesarias.

Líder del Proyecto 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.


• Debe tener las siguientes características: • Amplio conocimiento y dominio de las actividades y procesos involucrados en el proyecto, así como de la problemática y perspectivas futuras que giren en torno a dichas actividades o procesos. • Disponer del tiempo suficiente que le demande el proyecto para participar muy activamente junto con el Líder Técnico y su equipo de trabajo, en las fases del proyecto donde su participación es crítica. • Mostrar alto nivel de compromiso e identificación con el proyecto en desarrollo. • Estar familiarizado con los conceptos básicos del desarrollo de proyectos de TIC y preferiblemente tener alguna experiencia al respecto. • Habilidad para administración de personal. • Facilidades para administrar proyectos. Responsabilidades Principales Administrar (planificar, dirigir, controlar, ejecutar y evaluar) las fases de un proyecto de TIC con eficiencia y eficacia. Funciones a. Comprobar la aplicación de las actividades establecidas en la Guía Metodológica para el Desarrollo de Proyectos de TIC. b. Elaborar, revisar y aprobar los planes del proyecto correspondientes a cada una de las fases del desarrollo y velar por su cumplimiento. c. Evaluar periódicamente el avance del proyecto, con base en lo planeado y ajustarlo en caso de que sea necesario. Elaborar informes periódicos sobre el desarrollo y cumplimiento del plan de trabajo. d. Facilitar y promover el trabajo en equipo.


e. Atender los problemas administrativos (disponibilidad de recursos, conflictos, modificación de procedimientos o procesos) que requieran su atención. f. Mantener las vías de comunicación adecuadas, para informar a todos los interesados en el proyecto, sobre los detalles del mismo. g. Lograr la colaboración apropiada de otras unidades organizacionales, que se vean afectadas o involucradas por el desarrollo del proyecto, con el objetivo de implementar una solución integral, eficaz y eficiente al problema. h. Definir los procedimientos administrativos en torno a la solución tecnológica que se desarrolle o implante. i. Definir las nuevas funciones y responsabilidades por puesto o la actualización de éstas, las cuales se deriven por el proyecto en desarrollo. j. Participar activamente en la definición de requerimientos y alcances del proyecto, considerando las necesidades propias de su área funcional, de otras áreas que por su función estén relacionadas con el proyecto, así como de los niveles de decisión. k. Participar en el estudio de paquetes de “software”, cuando sea requerido para el proyecto y emitir las observaciones pertinentes. l. Cuando el proyecto involucre un nuevo sistema de información deberá: • revisar y aprobar, junto con el Líder Técnico, el diseño funcional del sistema. • Evaluar el prototipo del sistema de información,

hacer las

recomendaciones pertinentes y aprobarlo formalmente. • Participar activamente en la definición de volúmenes de información, aspectos operacionales del sistema, criticidad, usuarios del sistema, procesos de entrada y salida, diseño de reportes, aspectos de seguridad y controles, interfaces, y requerimientos de “hardware”. • Evaluar el diseño final del sistema en sus apartados de seguridad y controles, procesos de entrada y salida, e interfaces y funcionalidad


del sistema, emitir las recomendaciones pertinentes y aprobarlo formalmente. • Participar y aprobar el plan de pruebas y del paralelo, y emitir, para tal efecto, las recomendaciones pertinentes. • Coordinar el levantamiento de datos para las pruebas y para la ejecución del paralelo del sistema. • Asignar personal de su área funcional para la digitación de datos no disponibles automáticamente. • Coordinar y participar activamente en las pruebas integradas del sistema, formular las recomendaciones pertinentes velando porque éste se ajuste al prototipo y diseño final aprobados, con exactitud y completitud conforme a los resultados deseados. • Identificar a los funcionarios que deberán recibir entrenamiento para el paralelo. • Participar activamente en la ejecución del paralelo, llevando registro de las modificaciones requeridas. • Identificar al personal de su área funcional, que requerirá entrenamiento en la operación del sistema. • Coordinar el planeamiento y ejecución del plan de capacitación. • Revisar y aprobar los manuales del usuario, capacitación, y operación del sistema. • Participar activamente en la planificación e implantación del sistema. • Hacer un seguimiento del sistema post-implantación y emitir las recomendaciones que procedan. • Participar en la evaluación posterior a la implantación de la solución desarrollada, llevando a cabo un análisis de los beneficios reales contra los planeados.


Líder Técnico del proyecto Perfil: • Ser un individuo con una preparación académica adecuada que lo faculte para llevar a cabo con éxito, el seguimiento, y el desarrollo de un proyecto de sistemas de información.

A la vez, debe ser una persona

experimentada, según lo que requiera el proyecto, en aspectos como el desarrollo de sistemas de información o el manejo técnico de herramientas tecnológicas específicas (bases de datos, redes, elementos de seguridad, comunicaciones, paquetes, entre otros), o sobre la solución tecnológica a desarrollar o implementar. • Tener capacidad de asimilar los procesos de las áreas funcionales relacionadas con su proyecto en desarrollo y aportar ideas creativas que mejoren los procesos, al operar éste como agente de cambio en la Organización. • Mantener una constante preocupación por mantenerse actualizado acerca de los últimos avances en la tecnología informática en el entorno, con el objetivo de analizarlos y determinar su aplicabilidad o adaptabilidad, si esto fuese requerido para el logro de los objetivos del proyecto. Responsabilidad principal • Colaborar con la Administración en llevar a cabo las fases de un proyecto de desarrollo tecnológico, sea en forma interna o servicio contratado, con eficiencia y eficacia.


Funciones a. Apoyar en la elaboración de los planes del proyecto requeridos y correspondientes a cada una de las etapas, de acuerdo con la metodología y estándares vigentes. b. Revisar los planes propuestos por el contratista e identificar y sugerir las modificaciones necesarias, para salvaguardar los intereses del usuario y de la Contraloría General de la República, en caso de contratación externa. c. Llevar un control de toda la información (documentación) que se genera en torno al proyecto tanto formal como informal, con el objetivo de respaldar cualquier incidente, debido a problemas de comunicación. d. Supervisar y controlar la ejecución real del proyecto, de acuerdo con los estándares vigentes, para verificar la observación de los planes y etapas específicas, con la finalidad de identificar oportunamente cualquier desfase o incumplimiento, interno o externo, y tomar las medidas correctivas. e. Detectar y analizar cualquier problema actual o potencial que ocasione variación sobre lo planeado, coordinando las medidas correctivas con el usuario responsable. f. g. Identificar y gestionar cualquier intervención o ayuda requerida, para el desarrollo del proyecto. h. El Líder Técnico debe velar por la aplicación de los cambios tecnológicos que llegue a conocer y que afecten el proyecto. i. Resolver los problemas y conflictos internos del proyecto que estén a su alcance y elevar a los mandos superiores los que no pueda solucionar. j. Presentar y justificar técnicamente el proyecto tanto frente a los usuarios, como ante otros coordinadores técnicos y jefaturas. k. Revisar y evaluar la calidad de los productos generados en las diferentes etapas del proyecto, desarrollados en forma interna o por el contratista, de acuerdo con los estándares vigentes y los planes. Por otra parte, identificar


las modificaciones necesarias y presentar las recomendaciones pertinentes para su consideración, por parte del usuario responsable, la jefatura de la USTI y el contratista si lo hubiera. l. Revisar y evaluar cualquier recomendación hecha por un miembro del proyecto antes de presentarla a otras personas o ante una eventual empresa contratada. m. Mantener una estrecha relación con los otros Líderes Técnicos de proyecto, el Equipo de Apoyo Tecnológico, y el coordinador de proyectos; con la finalidad de determinar y facilitar los enlaces requeridos entre sistemas; analizar la viabilidad técnica de las propuestas y compartir las experiencias del desarrollo de proyectos. Con esto se pretende identificar, entre otros aspectos, los requerimientos en áreas tales como: “software”, “hardware”, interfaces, comunicación y topología. n. Administrar con responsabilidad y discreción toda aquella información que, por su índole, lo amerite. o. Ofrecer continuos aportes y sugerencias de acuerdo con su conocimiento y experiencia en el uso de metodología, y estándares, que coadyuven en su depuración y mejoramiento, con la finalidad de “eficientizar” los métodos de trabajo. p. Mantener informado al Líder del Proyecto, al coordinador de proyectos y a la jefatura de la USTI, acerca de la ejecución del proyecto. En particular, si el proyecto se desarrolla bajo el esquema de contratación, en lugar de coordinar al equipo de apoyo tecnológico, tendría las siguientes funciones: a. Efectuar el control de calidad de los productos que entregue el proveedor contratado. b. Garantizar una transferencia tecnológica adecuada, de tal forma que inmediatamente que el proveedor entregue la herramienta pueda ser administrada técnicamente por la USTI.


c. Fungir como facilitador técnico para el proveedor contratado, de tal forma que suministre oportunamente la información técnica que se requiera, para que el proyecto se desarrolle sin contratiempos. d. Velar por el cumplimiento de los tiempos de entrega de los productos, según lo acordado con el proveedor. Proponer acciones correctivas en caso de desfases. e. Fungir como contraparte técnica por parte de la Contraloría General en defensa de los intereses institucionales, velando por el debido cumplimiento de los compromisos suscritos por el proveedor contratado.

Equipo de apoyo tecnológico Entre sus responsabilidades está: • Asistir la labor del Líder Técnico en materias como programación, diseño y optimización de bases de datos, operación de equipos principales, paso a producción de un sistema, sistemas operativos, seguridad, comunicaciones y definición de perfiles de acceso.

Equipo de trabajo Entre sus responsabilidades está: • Brindar toda la información y colaboración necesaria al Líder de Proyecto y al Líder Técnico, en todas las etapas, actividades y tareas que lo requieran. • Atender las tareas que el Líder del Proyecto les asigne.


Grupo de Apoyo Entre sus responsabilidades está: • Colaborar con el Líder de Proyecto en todas las etapas, actividades y tareas que lo requiera. • Atender las tareas que el Líder del Proyecto les solicite.


Matriz de Responsabilidades




Anexo 4

Fases para el desarrollo de sistemas 1. Análisis integral de requerimientos 1.1.

Consideraciones

Con el análisis integral de requerimientos del sistema a automatizar se espera: • Identificar, analizar y documentar los requerimientos funcionales y nofuncionales que debe soportar el sistema o solución propuesta. Los requerimientos funcionales se refieren a las cosas que el sistema debe realizar, por ejemplo que información se debe registrar y de que manera se debe procesar; los requerimientos no funcionales se refieren a los aspectos operativos del sistema como tiempos de respuesta, respaldos de información y presencia en la Internet o en la Intranet de la Contraloría. • Priorizar los requerimientos que ha de cubrir el nuevo sistema o solución, convirtiéndose en punto de referencia básico para validar el sistema final, comprobando que se ajusta a las necesidades del usuario. El proceso de análisis de requerimientos se puede representar en la siguiente figura:


El usuario o usuarios del futuro sistema deben realizar la especificación de los requerimientos funcionales y no funcionales del nuevo sistema, los cuales deberán ser priorizados de acuerdo a su grado de aporte a la consecución de los objetivos del proyecto. Para ello tendrá la colaboración del personal informático asignado al proyecto. Estos requerimientos serán analizados por los Analistas de Sistemas asignados al proyecto con el apoyo del Líder Técnico y si fuera necesario se podrá solicitar a los usuarios profundizar en la especificación de uno o varios de los requerimientos con la finalidad de que éstos sean lo más claros y específicos posibles. Paralelamente en este proceso de análisis se deben identificar posibles ajustes a la planeación de los recursos requeridos por el proyecto; así como los requerimientos críticos para el éxito del mismo. Con esta información se confeccionará el “Documento de Análisis” y se ajustará el cronograma para la conclusión del proyecto. 1.2.

Entregables

Se entiende como entregables aquellos documentos confeccionados en esta fase y que formarán parte del expediente o archivo del proyecto. En lo referente a la fase de análisis integral de requerimientos para el Desarrollo de un Sistema de Información se identifican los siguientes entregables: • Especificación de requerimientos: se entiende por especificación de requerimientos un documento con la descripción precisa y detallada que hace el usuario de las necesidades a ser resueltas con el sistema solicitado y sus restricciones. • Documento de análisis: en este documento se presentan los resultados obtenidos en la fase de Análisis y debe hacer referencia a la valoración de complejidad y prioridad preliminar de los requerimientos. Puede establecer


ajustes al formulario de recursos requeridos para la realización del proyecto y presentar ajustes al cronograma para la completitud del proyecto. 1.2.1. Especificación de requerimientos La especificación de requerimientos es la descripción precisa y detallada que hace el usuario de las necesidades a ser resueltas con el sistema solicitado y sus restricciones. 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. Los requerimientos se pueden agrupar en funcionales y no funcionales: 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: • Correcto: Cada requerimiento debe describir con exactitud la funcionalidad que se obtendrá del sistema, de manera que no exista conflicto entre ellos. Debe tener una referencia a la fuente del requerimiento, sea este el cliente o bien un requerimiento propio de la implementación del sistema.


• Factible: Se refiere a la posibilidad técnica, operativa, legal, económica y presupuestaria de implementar cada uno de los requerimientos dentro de la capacidad y limitaciones del sistema y su ambiente de desarrollo. El desarrollador debe chequear cada uno de los requerimientos y determinar qué se puede desarrollar y qué no, y qué puede desarrollarse pero tiene un costo excesivo. • Necesario: Cada uno de los requerimientos debe documentar una necesidad del usuario o bien un requisito del sistema, interfase o estándar. Debe poder indicarse el rastro del requerimiento desde su origen, de tal forma que sea válido y por ende necesario. • Claro: El lector del documento de requerimientos debe ser capaz de interpretarlo de una única forma. Para esto cada requerimiento debe describirse en forma sucinta, simple, en un lenguaje comprensible por el usuario. Para verificar la claridad de los requerimientos se pueden crear escenarios que ilustren la funcionalidad de porciones específicas del sistema. • Verificable: Un requerimiento es verificable si se puede utilizar algún tipo de pruebas tales como inspección o demostración para determinar si el requerimiento satisface las necesidades de los usuarios. Si el requerimiento no es verificable, determinar si se implementó correctamente. Para la especificación de los requerimientos funcionales del sistema se utilizarán los casos de uso del UML (Unified Modeling Language), lenguaje cuyo estándar es promovido por el OMG (Object Management Group) y que permite modelar, construir y documentar los elementos que forman un sistema de información, especialmente, orientado a objetos. Los casos de uso representan la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa, desde el punto de vista del usuario y especificando


qué respuestas debe ofrecer el sistema a las diversas acciones de los usuarios o, en general, los agentes externos al sistema. En esta tarea se elabora el modelo de casos de uso identificando: • Actores y casos de uso. • Descripción del escenario de cada caso de uso. Para completar la descripción del escenario, es preciso especificar el siguiente detalle:

Casos de uso de alto nivel: Caso de Uso Actores

Nombre del caso de uso Lista de actores (agentes externos), indicando quién inicia el caso de uso. Usualmente son roles, pero puede ser cualquier tipo de sistema

Tipo

Primario:

proceso principal

Secundario: casos de uso menores Opcionales: proceso que puede no ser tomado en cuenta en el sistema ________________________________________________________ Esencial: definido a nivel abstracto, independiente de la tecnología y la implementación Descripción

Real: describe concretamente el proceso en términos del diseño real. Muy breve descripción del caso de uso

Casos de uso expandidos:

Caso de Uso Actores

Nombre del caso de uso Lista de actores (agentes externos), indicando quién inicia el caso de uso. Usualmente son roles, pero puede ser

Propósito

cualquier tipo de sistema Intención del caso de uso


Tipo

Primario:

proceso principal

Secundario: casos de uso menores Opcionales: proceso que puede no ser tomado en cuenta en el sistema Esencial:

definido a nivel abstracto, independiente de la

tecnología y la implementación Real:

describe concretamente el proceso en

términos del diseño real. Referencias Casos de uso relacionados Precondición Condiciones dadas antes del proceso Curso Típico de Descripción de la interacción entre los actores y el sistema eventos

mediante las acciones numeradas de cada uno (se disponen en forma columnar) Describe la secuencia más común de eventos, bajo condiciones de normalidad y el proceso se

Poscondición Cursos

completa satisfactoriamente. Condiciones resultantes después del proceso Se describe la excepción al caso normal y se señala el punto

Alternativos

en que se daría.

Los casos de uso se describen en forma detallada en el anexo 14. 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.


1.2.2. Documento de análisis 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. Debe contener, al menos, la siguiente información: a. Identificación de recursos para desarrollo Teniendo ahora mayor claridad respecto a lo que el sistema debe resolver y el trabajo a realizar, se debe ajustar el formulario de recursos del proyecto Identificando requerimientos de recurso humano, “hardware”, “software”, comunicaciones, ambiente físico, volumen de datos, materiales, capacitación y otros recursos que serán requeridos para el desarrollo del proyecto. Si al ejecutar esta tarea se tiene un estimado de los recursos requeridos para las etapas de Implantación y operación, esto puede ser descrito en esta tarea, revisado y ajustado más adelante. b. Análisis de requerimientos Los requerimientos estudiados se analizan para identificar los siguientes elementos de cada solicitud: • Identificación del requerimiento: Debe ser una secuencia conformada por las siglas o código del sistema y un consecutivo que identifique de manera única al requerimiento (en el proyecto o sistema actual) • Breve descripción: Breve descripción y propósito del requerimiento. • Prioridad: asignada por el Patrocinador o Líder del Proyecto. Se recomienda utilizar tres valores posibles en concordancia con la priorización de requerimientos, es decir, Alto, Medio y Bajo. • Complejidad: nivel de dificultad para la solución de lo solicitado. Se recomienda utilizar tres valores posibles: Alta, Media y Baja.


• Tipo de requerimiento: Identificar si se trata de requerimiento funcional o de un requerimiento no funcional. • Dependencia con otros requerimientos: Hacer referencia a los requerimientos que están relacionados y que de alguna manera representan una dependencia; es decir, que para su atención se requiera resolver previamente otros requerimientos o que su atención es obligatoria para el cumplimiento de otros aspectos. • Tiempo estimado de construcción: estimación preliminar del tiempo requerido para la atención del requerimiento. Se debe utilizar una unidad de medida uniforme para cuantificar todos los requerimientos (horas, días, semanas) Seguidamente se presenta un ejemplo de la matriz 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. c. Definición de infraestructura tecnológica Se debe detallar la infraestructura computacional que soportará el sistema cuando esté en operación, a nivel de equipo principal y de usuarios, lenguaje de programación y especificación de la base de datos; y cualquier otro aspecto requerido para el funcionamiento del sistema. En términos generales, el tipo de tecnología a utilizar dependiendo del tipo de sistema; incluyendo aquella que no esté disponible en la CGR y que se constituye en un riesgo tecnológico.


d. Cronograma ajustado de las fases posteriores del proyecto 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. e. Aprobación de los requerimientos Se debe realizar una presentación a la Unidad Ejecutora de los requerimientos identificados, a efectos de efectuar los ajustes necesarios hasta obtener la aprobación por parte de la UE y continuar con la siguiente etapa.


2.

Diseño conceptual de la solución 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. En la siguiente figura se diagraman las principales actividades de esta fase:

2.2.

Entregables

Se entiende como entregables aquellos documentos confeccionados en esta fase y que formarán parte del expediente o archivo del proyecto.


En lo referente a la fase de diseño conceptual de la solución para el Desarrollo de un Sistema de Información se identifican los siguientes entregables: • Documento de diseño conceptual: a través de este documento se presentan los resultados de la primera actividad de diseño como la descripción general de procesos, identificación de relaciones de integración de sistemas, la identificación de usuarios y roles. Tiene el propósito de mostrar, de manera general, cómo estará constituido el nuevo sistema y será la base, en conjunto con la especificación de requerimientos, para el diseño detallado del sistema. 2.2.1. Documento de diseño conceptual Este documento deberá contener, al menos, la siguiente información: 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. b. Descripción de módulos y sub-módulos y su interacción Con base en el diseño conceptual de la solución, se detalla la estructura modular del sistema en cuanto a la jerarquía de los módulos y la forma en la que interactúan. Además de la descripción de los módulos se debe confeccionar el diagrama de contexto y el diagrama de flujo de datos. El diagrama de contexto establece las relaciones que el módulo tiene con otros sistemas, otros módulos o entidades externas. El diagrama de flujo de datos es la representación gráfica de las entradas, procesos y salidas de un módulo mostrando la interrelación de los procesos.


c. Identificación de interrelaciones con otros sistemas o módulos Se refiere a la identificación de sistemas o módulos que estarán relacionados con el sistema en construcción y la descripción de estas relaciones en lo referente al tipo y método de comunicación. Además, se debe indicar si es requerida la modificación de algún sistema existente para ajustarlo a la solución que se está diseñando. En esta actividad es importante que se analice la estructura de datos existente en los sistemas que estarán relacionados para la creación de un modelo lógico de datos en la siguiente fase. d. Identificar tipos de usuarios 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.


3.

Diseño detallado de la aplicación 3.1.

Consideraciones

El diseño detallado de la solución establece, con mayor detalle, las características que tendrá el nuevo sistema. Además, será la base para la fase de construcción o programación de los módulos. 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. El documento de diseño detallado debe especificar los módulos que tendrá el sistema, características de validación y restricciones sobre los elementos de datos, especificación de procesos, detalle de controles y seguridad, características de la interfaz de usuario y principales reportes que ofrecerá el sistema. Todos estos aspectos serán identificados con base en los requerimientos funcionales del proyecto y, de ser necesario, de las consultas efectuadas a los usuarios, Líder de Proyecto o contraparte y Patrocinador del proyecto. En la siguiente figura se muestra el esquema funcional de esta etapa en la construcción de sistemas:

El diseño detallado de la aplicación será revisado y aprobado por la Jefatura de la USTI o por quien éste designe para comprobar que el desarrollo propuesto está dentro de los estándares de la Unidad y que es consistente con la planificación de crecimiento tecnológico de la Institución. Dicha revisión debe ser consignada como visto bueno del documento.


3.2.

Entregables

Se entiende como entregables aquellos documentos confeccionados en esta fase y que formarán parte del expediente o archivo del proyecto. En lo referente a la fase de diseño detallado para el Desarrollo de un Sistema de Información se identifican los siguientes entregables: • Documento de diseño detallado: se refiere al documento donde se describen, con más detalle los elementos del nuevo sistema como descripción de módulos, modelado de datos, procesos, controles de acceso y seguridad, interfaz de usuario y reportes. • Diseño de pruebas: se refiere a un documento donde se estipulan los aspectos a considerar en el proceso de pruebas, con el propósito de contar con el suficiente tiempo para su planificación. 3.2.1. Documento de diseño detallado Este documento deberá contener, al menos, la siguiente información: a. Descripción de procesos Consiste en desagregar los módulos identificados en el diseño conceptual y describir las entradas, los procesos y las salidas que considera el sistema de acuerdo con el estándar fijado. Para la realización de esta actividad se utilizará la herramienta de software aprobada por la USTI. b. Diagrama lógico del modelo de datos Especificación del modelo entidad-relación del sistema, de la composición física que tendrán las tablas relacionales y su normalización. Este modelo debe ser validado por el DBA.


c. Definiciones de dominios para los datos Se refiere a la especificación de aspectos como: • Formato • Valor que asume por defecto • Rango de valores permisibles • Listas de valores • Mensajes informativos sobre los elementos Además se deben especificar las restricciones a nivel de bases de datos. d. Estimación del volumen de datos Estimación de la cantidad de registros que se ingresaran para cada tabla definida en el modelo de datos lo cual se debe realizar con el apoyo del Administrador de las Bases de Datos de acuerdo con el estándar respectivo. e. Definición de controles y seguridad a utilizar Definir los puntos de control que garanticen la seguridad, integridad y confidencialidad de la información a nivel de roles en la base de datos y control de acceso a las transacciones en la aplicación. Se deben identificar los tipos de eventos que deberán dejar registros de auditoria, bitácoras y otros controles que se establezcan en la definición de estándares para el desarrollo de sistemas. f. Diseñar la interfaz de usuario Establecer la apariencia de las pantallas con base en los estándares establecidos. Definir la estructuración del menú y los roles de usuario que tendrán acceso a cada opción del sistema.


g. Organización para la operación del sistema Identificar y definir los requerimientos operativos a nivel del ambiente administrativo donde se implantaría el nuevo sistema.

Podrían plantearse cambios en los

procedimientos actuales, necesidades de reubicar o de obtener nuevo personal, cambios en los flujos de la información en los puntos de control de la misma. 3.2.2. Diseño de pruebas: Con la finalidad de guiar el proceso de pruebas y realizar las tareas correspondientes para esta actividad con la debida anticipación, se debe efectuar un diseño de pruebas basado en casos de uso y orientadas a: • Asegurar que el producto cumple con lo solicitado por los usuarios • Certificar que el aplicativo funciona correcta y eficientemente El documento de diseño de pruebas debe contener los siguientes aspectos: a. Especificación de tipos de pruebas Identificar los tipos de pruebas a realizar: pruebas unitarias, pruebas de módulos, pruebas de integración, pruebas de esfuerzo, tiempos de respuesta y tráfico en la infraestructura de comunicaciones. • 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)


• Tiempo de respuesta: verificación de que el tiempo de respuesta es aceptable de acuerdo con los estándares de la industria • Tráfico en la infraestructura de comunicaciones: comprobación de capacidad de transmisión de datos (ancho de banda) para la operación del sistema b. Requerimientos para las pruebas La plataforma de “Hardware”, “Software”, conectividad y base de datos requerida. Si el sistema tendrá integración con otros sistemas o módulos deberá disponerse de un ambiente de pruebas de dichos sistemas. c. Casos y datos de prueba 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. Si se requiere la existencia de datos para la pruebas, se deberá señalar el método de captura de éstos en las estructuras de la base de datos. d. Usuarios para las pruebas Determinar las características y cantidad de los usuarios que serán requeridos en el proceso de pruebas y el tiempo a invertir en dicho proceso. Esto es importante para que las Unidades puedan efectuar la coordinación correspondiente con la debida anticipación.


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. En la siguiente figura se muestra el flujo de procesos esperado en esta fase donde es posible que se deban realizar ajustes en la programación para cumplir con las especificaciones del usuario:

Diseño detallado Construcción Construcción

Ajustes Ajustes

Pruebas Pruebas

Aceptación Aceptación

Implementación Figura No. 5: Construcción y pruebas


4.2.

Entregables

Se entiende como entregables aquellos documentos confeccionados en esta fase y que formarán parte del expediente o archivo del proyecto. En lo referente a la fase de programación para el Desarrollo de un Sistema de Información se identifican los siguientes entregables: • Scripts de creación de objetos en la BD: para la creación de tablas, llaves primarias y foráneas, índices, constraints, roles, usuarios y cualquier otro componente de la base de datos. • Componentes de programación: elementos de programación como menúes, formas, reportes, procedimientos y funciones almacenados en la base de datos, triggers de bases de datos y cualquier otro componente del nuevo sistema. • Constancia de pruebas: documentación de las pruebas donde se indiquen los resultados obtenidos y los ajustes a realizar. • Aceptación del sistema: nota del Líder del Proyecto donde se exprese que el nuevo sistema cumple satisfactoriamente con lo solicitado y que se pueda continuar con las actividades de capacitación e implementación. 4.2.1. Desarrollo o Construcción a. Implementación del modelo físico de datos 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.


b. Creación de roles y de usuarios 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 Durante el desarrollo de esta etapa se generan los programas que componen el Sistema de Información. Conforme se avanza en la programación se debe documentar cada uno de los componentes desarrollados de acuerdo con el estándar definido. Adicionalmente, el desarrollador debe adoptar los estándares establecidos en la nomenclatura, el manejo de versiones, y la documentación de los programas que establece el manual de estándares. d. Conversión y levantamiento de datos 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.


4.2.2. Pruebas a. Preparación y levantamiento de información para las 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. b. Ejecución de pruebas específicas Se debe probar el funcionamiento (cumplimiento de los requerimientos), facilidad de uso por el usuario (interfaz con el usuario), diálogos con el usuario y su control, para cada pantalla con la que debe interactuar el usuario. c. Ejecución de pruebas por el usuario final 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. d. Documentación de los resultados de las pruebas Generar la documentación que corresponda para dejar constancia de los resultados del proceso de pruebas, incluyendo los casos en donde éstos no fueron satisfactorios, lo cual implica ajustes a los programas y la aplicación de las pruebas correspondientes. Es importante que quede documentado quiénes y cuándo realizaron las pruebas, así como sus observaciones.


4.2.3. Ajustes de programación Si en la realización de pruebas se identifica la necesidad de efectuar ajustes en la programación, después de llevarlos a cabo se deben realizar las pruebas específicas y de integración de manera interactiva con los usuarios; de tal forma que al finalizar las modificaciones se realicen las pruebas correspondientes para que el sistema concluya satisfactoriamente. Se debe actualizar la documentación de los programas con base a las modificaciones realizadas.

4.2.4. Aceptación del sistema Una vez concluido el proceso de pruebas y los ajustes a la programación, el Patrocinador del proyecto debe emitir una nota dirigida a la Jefatura de la USTI, mediante la cual manifiesta que está satisfecho con el sistema dándolo por aceptado y autorizando a que se proceda con su implementación.


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. La documentación del proyecto se debe mantener actualizada en todo momento y formará parte de un expediente o archivo por proyecto donde todos los documentos producidos estén reunidos. 5.2.

Entregables

Se entiende como entregables aquellos documentos confeccionados en esta fase y que formarán parte del expediente o archivo del proyecto. En lo referente a la fase de documentación para el Desarrollo de un Sistema de Información se identifican los siguientes 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. 5.2.1. Documentación del proyecto Son todos los documentos generados e identificados como entregables, en cada una de las fases, y que deben formar parte del archivo del proyecto: Documentos de organización del proyecto • Cronograma original


• Cronograma ajustado • Correspondencia generada Solicitud para el desarrollo de un sistema de información • Memorando de solicitud • Informe de diagnóstico • Memorando de resultado del estudio • Selección de la solución • Solicitud formal del proyecto Análisis integral de requerimientos • Especificación de requerimientos • Priorización de requerimientos • Documento de análisis Diseño conceptual de la solución • Documento conceptual de la solución Diseño detallado de la aplicación • Documento de diseño detallado • Diseño de pruebas 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


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 5.2.2. Manual de usuario 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. El manual debe contener lo siguiente: • 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


5.2.3. Manual técnico 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. 5.2.4. Manual de operació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.


6.

Capacitación 6.1.

Consideraciones

De acuerdo con la complejidad en el uso del sistema desarrollado y de la cantidad de usuarios del sistema, se debe coordinar con el Centrro de Capacitación y con la Unidad de Recursos Humanos el lugar, hora y la cantidad de sesiones que va a comprender la capacitación. En caso de ser necesario se coordinará el uso del laboratorio de microcomputadoras de manera que la capacitación se lleve por medio de una interacción total sistema-usuario.

7.

Implementación 7.1.

Consideraciones

El Líder de Proyecto, siguiendo criterios de impacto, materialidad, riesgo asociado, sensibilidad y criticidad de la información involucrada, deberá considerar el tipo de pruebas adicionales que requiera el proyecto, logrando un adecuado balance costo/ beneficio. Entre otras podrá considerar pruebas en paralelo cuyo objetivo será verificar que el sistema nuevo genera resultados similares al sistema que estuviera en ese momento en funcionamiento – manual o automatizado-, pruebas de esfuerzo cuyo objetivo es poner a prueba el sistema y la plataforma frente a una fuerte demanda de los servicios. Estas pruebas pueden ser reales o simuladas, dependiendo de la disponibilidad de recursos humanos y tecnológicos. El proceso se muestra en la siguiente figura: 7.2.

Entregables

Se entiende como entregables aquellos documentos confeccionados en esta fase y que formarán parte del expediente o archivo del proyecto.


En lo referente a la fase de implementación para el Desarrollo de un Sistema de Información se identifican los siguientes entregables: • Plan de implementación: breve documento donde se describen las actividades a realizar para la implementación del sistema, desde el punto de vista técnico y organizacional. • Aprobación del inicio de operación: nota o acta del Patrocinador donde autoriza el inicio de operación en producción del sistema en vista de que fueron cumplidos todos los requerimientos funcionales y no funcionales. • Entrega del sistema: notificación a los usuarios y a la , administración en general (si fuese necesario), de la culminación del proyecto y sobre la fecha del inicio de operación del sistema. 7.2.1. Plan de implementación De acuerdo con la complejidad del sistema se debe generar un plan de implementación que incluya la calendarización de actividades, la ejecución de pruebas en paralelo, pruebas de esfuerzo y el traslado al ambiente de producción. a. Estrategia de implementación Definición del método de implementación más adecuado para el proyecto donde se considera si se realiza un paralelo o no, método de carga de datos a utilizar y cualquier otra decisión estratégica para la finalización exitosa del proyecto. Esta estrategia debe ser acordada con el Patrocinador del proyecto, el Líder del proyecto, el Líder Técnico y la Jefatura de la USTI. 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


del Patrocinador del proyecto, de la Jefatura de la USTI, de los usuarios y de los analistas. 7.2.2. Instalación del sistema Las actividades a realizar son las siguientes: • Preparar los aspectos relacionados con el ambiente físico y computacional para dar inicio con la operación del sistema Para lo anterior y de acuerdo a las características del sistema, se recomienda lo siguiente: • Activar los componentes de seguridad de acceso al sistema: identificación de usuarios, palabras de paso y atributos de usuario (roles), con la finalidad de garantizar que el ingreso al sistema en operación se realizará de forma segura. • Verificar que los requerimientos de “hardware”, de “software” y de comunicaciones se encuentran disponibles. • Verificar que se tenga el mobiliario, la instalación eléctrica (toma corrientes, conexión a tierra, protectores de picos) y el espacio físico necesario y acondicionado para su operación. • Verificar que los materiales que use el sistema se encuentren disponibles. Por ejemplo formularios especiales, papelería, cintas para impresora, medios de almacenamiento de datos y vídeos, cobertores para el equipo, así como todos los otros materiales requeridos. • Realizar la instalación del sistema en el ambiente de producción en coordinación con el DBA.


7.2.3. Conversión y carga inicial automatizada de datos 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. Las actividades a realizar son las siguientes: • Confirmar que el ambiente computacional (“software”, “hardware”) y personal, requerido para la carga o digitación de los datos al sistema, se encuentre disponible, según lo indicado en el plan. De lo contrario, realizar los ajustes necesarios para asegurar que la carga de los datos iniciales se haga en una forma satisfactoria. • Ejecutar las aplicaciones desarrolladas para la conversión y carga inicial de los datos al sistema. • Es recomendable realizar una depuración de los datos por convertir, para asegurar que no se incluyan datos erróneos al sistema. • Verificar que los datos introducidos se encuentren correctos y completos. • Comprobación por parte del Líder del Proyecto y del analista responsable, que la conversión y carga de datos se realizó en una forma satisfactoria. 7.2.4. Ejecución del paralelo Las actividades a realizar son las siguientes: Justificar la necesidad de ejecución de un procesamiento en paralelo. Esta decisión la toma el Líder de Proyecto, considerando las características e impacto del sistema. • Determinar la duración y forma en que se realizará el paralelo, de acuerdo con la naturaleza y complejidad del sistema.


• Determinar las funciones y responsabilidades del personal técnico y del usuario que participa en el paralelo. • Establecer los criterios de aceptación esperados para evaluar los resultados que se tengan al final de la ejecución del paralelo. • Iniciar el paralelo brindando asistencia al usuario en forma continua, para asegurar que los procedimientos se realizan en la forma correcta. Asimismo, identificar y corregir los problemas que se presenten. • Documentar los resultados de la ejecución del paralelo, considerando los criterios de evaluación establecidos. Indicar el criterio de aceptación considerado y el nombre de la persona que aprueba. • Dar un visto bueno, por parte del Líder del Proyecto, haciendo constar que el paralelo se concluyó en forma satisfactoria. 7.2.5. Aprobación formal del sistema para el inicio de su operación. Esta aprobación la hace el Patrocinador, mediante un acta de aceptación y puesta en operación del sistema. Aquí se confirma que el sistema terminado cumple con los requisitos acordados y que puede ser puesto en producción. 7.2.6. Hacer la entrega del sistema al usuario. El Patrocinador y el Jefe de la USTI notificarán formalmente acerca de la puesta en operación del sistema desarrollado 7.2.7. Hacer la entrega de programas fuente Cuando el sistema cuenta con la aceptación del Patrocinador o el Líder de Proyecto y ya está instalado en los equipo de producción, se debe entregar para su custodia, todos los programas, fuente en su versión final, generados en el desarrollo del sistema. Estos programas deben ir acompañados de la documentación especificada en el


procedimiento. Además se debe depurar el inventario de programas de manera tal que solo se haga entrega de los que realmente se requieren para la operación del sistema (borrar los programas temporales o transitorios, versiones de prueba y cualquier otro programa que no es definitivo).

8.

Evaluación post-implantación

Es necesario establecer el tiempo necesario (de una semana a 3 meses según el tamaño del sistema), para que se realice una evaluación durante su operación, y para que se hagan los ajustes necesarios, de manera que se satisfagan los requerimientos previamente establecidos. 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.


Anexo 5.

Mantenimiento de sistemas. 1. Mantenimiento de sistemas Para el mantenimiento de un sistema se tiene que elaborar la solicitud de modificación por escrito por parte del usuario administrador del sistema. Para ello la USTI tiene definido un estándar de formulario para control de cambios que el interesado deberá llenar y enviar para su respectivo trámite. 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. Durante la ejecución del trabajo de mantenimiento se deberán cumplir las siguientes fases: 1.1.

Planificación del trabajo de mantenimiento

Es necesario que se asignen los recursos necesarios (humanos, técnicos, y materiales), así como establecer un calendario de seguimiento: fechas de reunión con los usuarios y fechas de validación con el Patrocinador. 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á.


1.2.

Especificación de los nuevos requerimientos

En la misma forma en que fueron especificados en la fase de análisis de requerimientos, deben ser especificadas las nuevas necesidades. Podría ser que obedezcan a solicitudes que anteriormente tuvieran muy baja prioridad, por lo que no se les tomó en cuenta en esa oportunidad. De ser así debe quedar claro en el nuevo listado. 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.3.

Ajustes en programación y pruebas

Realizar los ajustes correspondientes a la programación y a la base de datos si fuera necesario, para dar cumplimiento a lo solicitado. Además, se debe valorar el tipo de pruebas a realizar (pruebas funcionales y pruebas de integración) según el impacto de los nuevos requerimientos en el sistema. Es importante que se asegure que las pruebas aplicadas cubren todos los aspectos afectados por las recientes modificaciones en el sistema para asegurar la estabilidad de la aplicación. 1.4.

Actualización de la documentación y de los programas fuente

Realizar los ajustes que correspondan en la documentación del sistema, en el manual de usuario, en el manual de operación y en el manual técnico, con la finalidad de que dichos documentos se mantengan vigentes en todo momento. Los cambios realizados en la programación y la base de datos deben manejarse como versiones de acuerdo con lo establecido en el estándar respectivo.


1.5.

Capacitación

Dependiendo del tipo de ajuste realizado, se verá la conveniencia de comunicarlos por medio de un correo o una pequeña charla. De lo contrario se deberá efectuar una capacitación de acuerdo a lo estipulado en la presente metodología referente a este tema. 1.6.

Implementación de los cambios

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

Evaluación post-implantación

Dependiendo del tipo de ajuste realizado, se deberá realizar una etapa de postimplantación, según lo establecido en esta Guía.


Anexo 6.

Formulario para documentación de las reuniones del proyecto. Proyecto: <> Memoria de Reunión No. XX-AÑO

División/Área: Lugar:

Elaborado por: Fecha:

Hora inicio:

Hora finalización:

ASISTENCIA: Invitado

Dependencia

Pre

X

Aus

X

ASUNTOS PENDIENTES Y SEGUIMIENTO DE ACUERDOS: Asunto

Responsable

Grado de avance / Finalización prevista

ASUNTOS TRATADOS:

Asuntos tratados 1) 2)

Comentarios Generales

ACUERDOS:

Acuerdos 1) 2) 3)

Responsable (s)

F e c h a prevista


Anexo 7.

Ficha de Anteproyecto.

FICHA DE ANTEPROYECTO Nombre del Proyecto ________________________________________________________ Resultado esperado

_________________________________________________________ _________________________________________________________

Efecto

_________________________________________________________ _________________________________________________________

Objetivo

_________________________________________________________ _________________________________________________________

Productos

_________________________________________________________ _________________________________________________________

Enfoque

_________________________________________________________ _________________________________________________________

Alcance

_________________________________________________________ _________________________________________________________

Relaciones de Coordinación

_________________________________________________________

Responsable

_________________________________________________________

Prioridad

_________________________________________________________

Requerimientos Iniciales

_________________________________________________________ _________________________________________________________

Fecha de inicio:

______________

Fecha de finalización: _______________________

Elaborado por: ___________________________________ Fecha:_____________________ Explicación Detallada Nombre del proyecto:

Es el título o enunciado que identifica al proyecto. Las principales características deseables al definir el nombre del proyecto son:


• Identificar la naturaleza del proyecto. • Ubicar el contexto en el que se desarrollará. • Debe ser conciso.

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. En el caso de existir contribución directa con más de un resultado esperado, éstos deben incluirse respetando un criterio de mayor a menor contribución.

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: • Escala de medición: La variable que indica la magnitud o avance del objetivo, como pueden ser el porcentaje o el volumen. • Horizonte de tiempo: El periodo definido para lograr la consecución del objetivo, por ejemplo en seis meses.


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


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.

Fecha de inicio y de finalización del proyecto: Se establecen fechas de inicio y fin propuestas que enmarquen el proyecto dentro de un tiempo específico; estas fechas deben ser de común acuerdo con todas las áreas involucradas.

Podrían estar determinadas por un periodo previamente asignado,

negociado, establecido por ley o se puede partir del hecho de que la administración requiere que el proyecto esté para determinada fecha, en cumplimiento de objetivos estratégicos. Es muy importante para efectos de planeación, realizar un estimado de la duración del proyecto; ya que las diferentes áreas involucradas deberán aportar los recursos que sean necesarios para que la duración del proyecto se cumpla. Los supuestos en que se basa la estimación de tiempos resultan fundamentales a efecto de crear expectativas realistas y acordes con los recursos y alcances esperados.

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.


Anexo 8.

Descriptivo de la Organización del Proyecto.

DESCRIPTIVO DE LA ORGANIZACIÓN DEL PROYECTO PROYECTO: Nombre del proyecto

.

Código de Proyecto: _____________ Siglas: _____________ Objetivo

_________________________________________________________ _________________________________________________________ _________________________________________________________

Líder de Proyecto:

_________________________________________________________

Líder Técnico:

_________________________________________________________ Integrantes del equipo de trabajo

Nombre ______________________________________ ______________________________________ ______________________________________ ______________________________________ ______________________________________

Unidad _____________________________ _____________________________ _____________________________ _____________________________ _____________________________

Integrantes del equipo de apoyo técnico Nombre ______________________________________ ______________________________________ ______________________________________

Unidad _____________________________ _____________________________ _____________________________

Patrocinador(es) del Proyecto Nombre Puesto ________________________________________________ ____________________ ________________________________________________ ____________________ ________________________________________________ ____________________ Elaborado por: ___________________________________ Fecha : ____________________


Explicación Detallada. Nombre del Proyecto: Es el título o enunciado que identifica al proyecto. Las principales características deseables al definir el nombre del proyecto son: • Identificar la naturaleza del proyecto. • Ubica el contexto en el que se desarrollará. • Debe ser conciso.

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.

Líder de Proyecto y Líder Técnico: Nombres del líder de proyecto y del líder técnico designados.

Integrantes del equipo de trabajo y del equipo de apoyo técnico: Se indicará en cada línea el nombre y la unidad de la persona que integrará cada uno de estos equipos. Para definir cada equipo deberá coordinarse con las respectivas áreas involucradas para que asignen a cada recurso con el tiempo suficiente para atender las tareas propias de su participación en el proyecto.

Patrocinadores del proyecto: Todo proyecto debe tener uno o varios patrocinadores. Estos serán funcionarios que no solo apoyan el proyecto sino que se involucran directamente en él. Por lo general


serán funcionarios ubicados en las más altas posiciones de mando de la organización, que no solo pedirán cuenta sobre el avance del mismo, sino que se encargaran de nivelar cualquier obstáculo que amenace al proyecto, y que promoverán el mismo ante las altas esferas de la CGR.

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.


Anexo 9.

Ficha de Estrategia de Solución del proyecto. ESTRATEGIA DE SOLUCION PROYECTO:

Nombre del proyecto

.

Código de Proyecto: _____________ Siglas: _____________

Estrategia de solución para el proyecto: _________________________________________________________ _________________________________________________________ _________________________________________________________ Aprobado por: ___________________________________ Fecha: ____________________

Explicación Detallada.

Nombre del Proyecto: Es el título o enunciado que identifica al proyecto.

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


Estrategia de solución para el proyecto: Se detalla la estrategia de solución que la Unidad Ejecutora eligió para el proyecto.


Aprobado por: Es el nombre del coordinador de la Unidad Ejecutora.

Fecha: Fecha en que se emite el documento.


Anexo 10.

Formulario para la Planeación de Recursos.

PLANEACION DE RECURSOS Nombre del proyecto: ___________________________________________________ Código de proyecto: ________ Siglas:

_________

Recursos Requeridos _________________________________________________________

Humanos: ____________ ________________________________________________________________________ __________________________________________________________________ Tecnológicos: _____________________________________________________________________ _____________________________________________________________________ _____________________________________________________________________ Materiales: ________________________________________________________________________ ________________________________________________________________________ __________________________________________________________________ Financieros: ________________________________________________________________________ ________________________________________________________________________ __________________________________________________________________ Elaborado por: ____________________________________ Fecha: ____________ Explicación detallada.


Nombre del Proyecto: En este campo se debe consignar el nombre con que ha venido siendo conocido el proyecto.

Código de Proyecto: En este campo se consignará el código que se le asignó al proyecto. Siglas: Se deben consignar las siglas que la USTI le asigne 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.


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: • se requiere contar con un servidor instalado en la red central de la CGR, a partir del mes de octubre, con las siguientes características técnicas....... • Se debe contar, a partir de julio, con un Sistema Administrador de Bases de Datos, Oracle 11g, con 12 licencias de prueba, instalado en el servidor de pruebas de la CGR.....

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. • Se necesita una oficina de 60 m2, equipada con cuatro escritorios, ..... • Se requiere contar con los servicios de un vehículo a disposición del grupo de trabajo, las 24 horas del día, a partir del mes de febrero y por 3 meses.

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.


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.


Anexo 11. Formulario para documentar Acciones Correctivas o Preventivas. DOCUMENTACIÓN DE ACCIONES CORRECTIVAS O PREVENTIVAS Nombre del Proyecto: ________________________________________________________ Código de Proyecto: _______ Siglas: _______ Actividad desfasada(o que se podría desfasar) según el Plan. __________________________________________________________________________ Motivos: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Acciones correctivas (o preventivas). __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Elaborado por: ___________________________________ Fecha: ___________________ Explicación detallada.

Nombre del proyecto: En este campo se debe indicar el nombre del proyecto, tal y como el mismo es conocido en toda la documentación.

Código del proyecto: Número de código asignado desde el inicio del proyecto.



Actividad desfasada según el plan: Se dice que una actividad esta desfasada cuando a través del proceso de revisión se determina que una actividad no esta logrando los alcances esperados, o bien los está logrando en un tiempo mayor al planeado. En este campo se debe indicar el nombre de todas aquellas actividades que el equipo de trabajo detectase como desfasadas. Lo ideal es que el desfase sea detectado lo antes posible, para facilitar la toma de acciones.

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.

Posibles acciones correctivas o preventivas para contrarrestar el desfase: Dependiendo del tipo de desfase, el equipo de trabajo tomara diversas acciones para contrarrestarlo. Por ejemplo si el desfase fuese en el tiempo, el equipo puede asignar más recursos a la actividad para acelerar su ejecución. Si el desfase fuese en alcances, el equipo buscará diversas alternativas para lograr los alcances iniciales. Si fuese imposible lograrlos se debe hacer la comunicación a la Unidad Ejecutora, para buscar el consenso sobre unos nuevos alcances modificados o reducidos.

Si las acciones

correctivas no lograsen, mantener vigente el plan del proyecto, se deberá elaborar un ajuste al plan, comunicándolo a todos los diferentes interesados o afectados por el proyecto.




Anexo 12.

Formulario para llevar el Control de Cambios del Proyecto CONTROL DE CAMBIOS EN EL PROYECTO Nombre del Proyecto: ________________________________________________________ Código de Proyecto: _______ Siglas: _______ Cambio requerido: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Justificación: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Impacto del cambio: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Requirió de ajustes en el plan de trabajo. ____________________ Elaborado por: ___________________________________ Fecha: ___________________ Explicación detallada.





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.

Impacto del cambio: Debe valorar el impacto como bajo, mediano y alto dependiendo de cuanto afecte el plan de trabajo.

Requirió ajustes en el plan de trabajo: Se indica con un si o con un no si la atención de dicho cambio requirió que se realizaran ajustes al plan de trabajo.




Anexo 13.

Formulario para la Aceptación de Productos Finales del Proyecto ACEPTACIÓN DE PRODUCTOS FINALES DEL PROYECTO Nombre del Proyecto: ________________________________________________________ Código de Proyecto: _______ Siglas: ________ Productos entregados:

_____________________________________________________ _____________________________________________________ _____________________________________________________ _____________________________________________________

Observaciones: __________________________________________________________________________ __________________________________________________________________________ __________________________________________________________________________ Acepta a satisfacción: _______________________________ Firma: ___________________ Fecha: ___________________ Explicación detallada.





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.



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.


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. 1.2 Casos de Uso Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. 1.3 Relaciones entre Casos de Uso 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: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado dentro del caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la siguiente figura se muestra cómo el caso de uso “Realizar Reintegro” puede incluir el comportamiento del caso de uso Identificación.


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

Ambos tipos de relación se representan como una dependencia etiquetada con el estereotipo correspondiente (<<>> o <>), de tal forma que la flecha indique el sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos de extensión del caso de uso base en los que se aplica la extensión. • Generalización ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso más específico. Se representa por una línea continua entre los dos casos de uso, con el triángulo que simboliza generalización en UML (usado también para denotar la herencia


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.

La generalización aplica también para los actores o agentes. Las funciones de un actor pueden especializarse. Un actor puede heredar las funciones del actor padre y a la vez tener funciones más específicas que lo especialicen.


Trabajando con Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales. 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


interesa abordar un caso de uso desde un nivel de abstracción alto, utilizando el formato de alto nivel. Cuando se quiere describir un caso de uso con más detalle, se usa el formato expandido.

1. Casos de Uso de Alto Nivel El siguiente Caso de Uso de Alto Nivel describe el proceso de sacar dinero cuando se está usando un cajero automático: • Caso de Uso: Realizar Reintegro • Actores: Cliente • Tipo: primario • Descripción: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va. En un caso de uso descrito a alto nivel la descripción es muy general, normalmente se condensa en dos o tres frases. Es útil para comprender el ámbito y el grado de complejidad del sistema.

2. Casos de Uso Expandidos 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:


• Caso de Uso: Realizar Reintegro • Actores: Cliente (iniciador) • Propósito: Realizar una operación de reintegro de una cuenta del banco • Visión General: Un Cliente llega al cajero automático, introduce la tarjeta, se identifica y solicita realizar una operación de reintegro por una cantidad específica. El cajero le da el dinero solicitado tras comprobar que la operación puede realizarse. El Cliente coge el dinero y la tarjeta y se va. • Tipo: primario y esencial • Referencias: Funciones: R1.3, R1.7 • Curso Típico de Eventos: Acción del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando 2. Pide la clave de identificación. un Cliente introduce una tarjeta en el cajero. 3. Introduce la clave. 5.

Selecciona

la

4. Presenta las opciones de operaciones operación

disponibles. de 6. Pide la cantidad a retirar.

Reintegro. 7. Introduce la cantidad requerida. 9. Recoge la tarjeta.

8. Procesa la petición y da el dinero solicitado. Devuelve la tarjeta y genera un recibo.

10. Recoge el recibo. 11. Recoge el dinero y se va. 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.


El significado de cada apartado de este formato es como sigue: • Caso de Uso: Nombre del Caso de Uso • Actores: Lista de actores (agentes externos), indicando quién inicia el caso de uso. Los actores son normalmente roles que un ser humano desempeña, pero puede ser cualquier tipo de sistema. • Propósito: Intención del caso de uso. • Visión General: Repetición del caso de uso de alto nivel, o un resumen similar. • Tipo:

primario, secundario u opcional (descritos más adelante).

• Esencial o real (descritos más adelante). • Referencias: Casos de uso relacionados y funciones del sistema que aparecen en los requisitos (si se levantaron previamente) • Curso Típico de Eventos: Descripción de la interacción entre los actores y el sistema mediante las acciones numeradas de cada uno. Describe la secuencia más común de eventos, cuando todo va bien y el proceso se completa satisfactoriamente. En caso de haber alternativas con grado similar de probabilidad se pueden añadir secciones adicionales a la sección principal, como se verá más adelante. • Cursos Alternativos: Puntos en los que puede surgir una alternativa, junto con la descripción de la excepción.

3. Identificación de Casos de Uso La identificación de casos de uso requiere un conocimiento medio acerca de los requisitos del sistema, y se basa en la revisión de los documentos de requerimientos (si los hay), y en el uso de la técnica de “lluvia de ideas” entre los miembros del equipo de trabajo y el líder técnico. Como guía para la identificación inicial de casos de uso hay dos métodos:


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.

Ejemplos de casos de uso: • Pedir un producto. • Matricularse en un curso de la facultad. • Comprobar la ortografía de un documento en un procesador de textos. • Comprar un libro en una tienda de libros en Internet

4. Identificación de los Límites del Sistema En la descripción de un caso de uso se hace referencia en todo momento al “sistema”. Para que los casos de uso tengan un significado completo es necesario que el sistema esté definido con precisión. 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. Ejemplos de sistemas son: • El hardware y software de un sistema informático. • Un departamento de una organización. • Una organización entera. Si no se está haciendo reingeniería del proceso de negocio lo más normal es escoger como sistema el primero de los ejemplos: el hardware y el software del sistema que se quiere construir.


5. Tipos de Casos de Uso a. Según Importancia Para establecer una primera aproximación a la priorización de casos de uso que identifiquemos, los vamos a distinguir entre: • Primarios: Representan los procesos principales, los más comunes, como “Realizar Reintegro” en el caso del cajero automático. • Secundarios: Representan casos de uso menores, que van a necesitarse esporádicamente. • Opcionales: Representan procesos que pueden no ser abordados en el presente proyecto. b. Según el Grado de Compromiso con el Diseño 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. Por el contrario, un caso de uso real describe concretamente el proceso en términos del diseño real, de la solución específica que se va a llevar a cabo. Se ajusta a un tipo de interfaz específica, y se baja a detalles como pantallas y objetos en las mismas. Para el ejemplo de un Caso de Uso Real en el caso del “reintegro” en un cajero automático tenemos la siguiente descripción del Curso Típico de Eventos:


Acción del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando un 2. Pide el PIN (Personal Identification Cliente introduce una tarjeta en la ranura Number). para tarjetas. 3. Introduce el PIN a través del teclado 4.

Presenta

numérico.

operaciones

5. etc.

6. etc.

las

opciones

de

disponibles.

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.

6. Consejos Relativos a Casos de Uso 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 Cuando se tiene una alternativa que ocurre de manera relativamente ocasional, se indica en el apartado Cursos Alternativos. Pero cuando se tienen distintas opciones,


todas ellas consideradas normales se puede completar el Curso Típico de Eventos con secciones adicionales. Así, si en un determinado número de línea hay una bifurcación se pueden poner opciones que dirigen el caso de uso a una sección que se detalla al final del Curso Típico de Eventos, en la siguiente forma: - Curso Típico de Eventos: • Sección: Principal Acción del Actor Respuesta del Sistema 1. Este caso de uso empieza cuando Actor 2. Pide la operación a realizar. llega al sistema. 3. Escoge la operación A. 5. Selecciona el tipo de pago:

4. Presenta las opciones de pago. 6. Genera recibo.

Si se paga al contado ver sección Pago al Contado. Si se paga con tarjeta ver sección Pago con Tarjeta.

7. Recoge el recibo y se va.

Cursos Alternativos: •

Líneas 3 y 5: Selecciona Cancelar. Se cancela la operación.

• Sección: Pago al Contado Acción del Actor 1. Mete los billetes correspondientes

Respuesta del Sistema 2. Coge los billetes y sigue pidiendo dinero hasta que la cantidad está satisfecha 3. Devuelve el cambio.


Cursos Alternativos: • Línea 3: No hay cambio suficiente. Se cancela la operación. • Sección: Pago con Tarjeta

7. Construcción del Modelo de Casos de Uso Para construir el Modelo de Casos de Uso se siguen los siguientes pasos: f. Después de listar las funciones del sistema, se definen los límites del sistema y se identifican los actores y los casos de uso. g. Se escriben todos los casos de uso en el formato de alto nivel. Se categorizan como primarios, secundarios u opcionales. h. Se dibuja el Diagrama de Casos de Uso. i. Se detallan relaciones entre casos de uso, en caso de ser necesarias, y se ilustran tales relaciones en el Diagrama de Casos de Uso. j. Los casos de uso más críticos, importantes y que conllevan un mayor riesgo, se describen en el formato expandido esencial. Se deja la definición en formato expandido esencial del resto de casos de uso para cuando sean tratados en posteriores ciclos de desarrollo, para no tratar toda la complejidad del problema de una sola vez. k. Se crean casos de uso reales sólo cuando: - Descripciones más detalladas ayudan significativamente a incrementar la comprensión del problema. - El cliente pide que los procesos se describan de esta forma. l. Ordenar según prioridad los casos de uso.


Anexo - NTP8

Marco General para Gestión de la Calidad en TIC



1.

ALCANCE DEL SISTEMA DE GESTIÓN DE CALIDAD 1.1.

Generalidades

La Unidad de Sistemas es la encargada de la gestión de tecnologías de información y telecomunicaciones en la Contraloría General de la República, posee la siguiente estructura:

伀爀最愀渀椀稀愀挀椀渀䐀攀猀瀀愀挀栀漀䌀漀渀琀爀愀氀漀爀愀䜀攀渀攀爀愀氀䌀漀洀椀琀 䜀攀爀攀渀挀椀愀氀搀攀吀䤀䌀 됀猀䐀椀瘀椀猀椀渀䜀攀猀琀椀渀搀攀䄀瀀漀礀漀唀渀椀搀愀搀吀攀挀渀漀氀漀最愀猀䤀渀昀漀爀洀愀挀椀渀倀爀攀猀甀瀀甀攀猀琀漀礀䌀漀洀瀀爀愀猀

匀漀瀀漀爀琀攀愀䌀氀椀攀渀琀攀猀

䐀攀猀愀爀爀漀氀氀漀匀椀猀琀攀洀愀猀

匀攀挀爀攀琀愀爀 愀

倀氀愀琀愀昀漀爀洀愀搀攀刀攀搀攀猀

䐀椀瘀椀猀椀渀搀攀䐀攀猀愀爀爀漀氀氀漀䤀渀猀琀椀琀甀挀椀漀渀愀氀唀渀椀搀愀搀搀攀匀椀猀琀攀洀愀猀礀吀攀挀渀漀氀漀最愀搀攀䤀渀昀漀爀洀愀挀椀渀

倀氀愀琀愀昀漀爀洀愀吀攀挀渀漀氀最椀挀愀

䌀攀渀琀爀漀搀攀䌀 洀瀀甀琀漀 ⠀㄀⤀

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.


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.


1.1.1. Alcance del sistema de gestión de la calidad El sistema de gestión de la calidad de Contraloría General de la República asegura la estandarización de los procesos de diseño, construcción y mantenimiento de soluciones tecnológicas que satisfagan las especificaciones definidas por los clientes. Este sistema es complementado con el aseguramiento de la calidad basado en la Capacidad de los Modelos de Madurez (CMM), el cual tiene por alcance el desarrollo mantenimiento de soluciones tecnológicas, siendo entre ellos congruentes y formando un solo sistema que se integra y complementa de buena manera. El Sistema de Gestión de la Calidad de las soluciones tecnológicas de la Contraloría General de la República, permite: • Asegurar la conformidad con los requerimientos del usuario, legales, vigentes y

aplicables.

• Aumentar la satisfacción de los usuarios por medio de una efectiva aplicación del SGC y su mejoramiento continuo, • Verificar la capacidad que tienen las soluciones tecnológicas en los procesos de la organización para la satisfacción de las necesidades de los usuarios. 1.2.

Términos y Definiciones

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

Política de la calidad.

La política de la calidad de Contraloría General de la República es la siguiente:


“En la Unidad de Tecnologías (UTI) de la Contraloría General de la República nos comprometemos a realizar nuestros mejores esfuerzos para ofrecer productos y servicios de calidad en el diseño, construcción y mantenimiento de soluciones tecnológicas, satisfaciendo las necesidades de nuestros usuarios, cumpliendo todos los requisitos vigentes, ya sean técnicos, legales o especificados, incorporando en los productos y servicios, las más innovadoras herramientas tecnológicas del mercado. En consecuencia, la UTI tiene como objetivo, la mejora continua, asegurando la calidad de sus productos con la participación y apoyo de su personal, el cual se destaca por su compromiso y profesionalismo” 1.4.

Diagrama de procesos

Según el MAGEFI, el proceso PA-08-05 Gestión de las Tecnologías de Información, tiene como objetivo el “Aprovechar las tecnologías de información y de comunicación para impulsar el desarrollo de los procesos internos” (pág. 53). Para dar cumplimiento a este cometido se han identificado las siguientes actividades en el proceso: • Diagnóstico de la necesidad de solución tecnológica • Análisis de los requerimientos • Diseño de la solución tecnológica • Obtención de la solución tecnológica • Implementación de la solución tecnológica • Operación de la solución tecnológica Como su objetivo lo menciona, se trata de un proceso cuyo producto de solución tecnológica que se orienta hacia lo interno de la institución, por lo que se trata de un proceso que apoya otros procesos organizacionales.


2.

SISTEMA DE GESTIÓN DE CALIDAD 2.1.

Requisitos Generales

El sistema de gestión de la calidad está conformado por el personal, su manera de relacionarse, los procesos y su interacción, los procedimientos e instructivos, así como también, por los recursos que se utilizan para garantizar la calidad de los productos y servicios, en donde se involucra cada paso, desde la compra de equipos, idear el producto, hasta puesta en marcha y entrega del producto al cliente. Los requisitos del sistema de gestión de la calidad implican que: • Se identifican y determinan los procesos que intervienen en él • Se determina la secuencia e interacción de éstos. • Se determinan los criterios y métodos que se requieren para asegurar la efectiva operación y control. • Se asegura la disponibilidad de la información necesaria para soportar su operación y seguimiento, así como su medición. • Se proporciona seguimiento y análisis y se implantan, cuando se requiere, las acciones necesarias para alcanzar los resultados planeados y la mejora continua. Dependiendo del proyecto tecnológico la UTI conformará un equipo especializado en la materia para realizar la validación del producto versus las especificaciones obtenidas previamente, con el objetivo de asegurar la satisfacción del cliente.


2.2.

Requisitos de la documentación.

2.2.1. Generalidades Para que el sistema opere consistentemente, se mantenga y pueda mejorarse, se deben establecer, documentar e implantar, documentos que incluyen: a. Las declaraciones documentadas de una Política y objetivos de la calidad, b. El presente Marco de Gestión de la Calidad, c. Los documentos y procedimientos requeridos por la organización para asegurar la planificación, operación y control efectivo de las actividades propias del proceso de Gestión de tecnologías de información y comunicación. 2.2.2. Manual de calidad 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. 2.2.3. Control de documentos El control de Documentos está establecido en la Metodología para el Desarrollo de Proyectos de Tecnologías de Información y Comunicaciones, y en términos generales establece: • Aprobar documentos antes de su Emisión y/o Publicación, •

Revisar y actualizar los documentos,

• Identificar las modificaciones y la condición de la revisión vigente de los documentos por medio de un adecuado control de versiones, • Asegurar que las revisiones vigentes estén disponibles en sus lugares de uso,


• Asegurar que los documentos se mantienen legibles e identificables, • Asegurar que los documentos de origen externo sean identificados y su distribución controlada, y • Evitar el uso de documentos obsoletos, planteando como serán identificados apropiadamente cuando se retienen con algún propósito. 2.2.4. Control de registros 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 3.1.

Enfoque al cliente

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. Lo anterior, se mide a través de la información que se proporciona acerca del desempeño de los productos y servicios que se tienen, con respecto a sus requerimientos y expectativas. Esta información se recopila por medio de la ficha técnica del proyecto (ver Manual de Estándares, Anexo No.7).


3.2.

Política de la Calidad

El líder de proyectos, se encarga de asegurar y vigilar que la Política de la Calidad establecida en la sección 1.3 de éste Manual sea: •

Apropiada al propósito de la organización;

• Incluya un compromiso para cumplir los requisitos y para la mejora continua; • Provea un marco de referencia para establecer y revisar los objetivos de calidad; • Sea comunicada y entendida por todos los miembros de la organización; • Se ajuste continuamente a los cambios internos y del entorno. 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. 3.3.2. Planificación del Sistema de Gestión de la Calidad (SGC) La CGR asegura que: • La planificación del SGC se realiza cumpliendo con los requerimientos citados en el punto 2.1 de este manual, así como con los objetivos de la calidad, y • Se mantiene la integridad del SGC cuando se planifica e implementa cambios en éste. • La planificación también se expresa en las actividades propuestas en cada uno de los procedimientos de la organización.


3.4.

Responsabilidad, autoridad y comunicación

3.4.1. Responsabilidad y autoridad 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. 3.4.2. Representante de la calidad El Coordinador de proyectos ha designado a cada líder de proyecto como Representante de la UTI para la Calidad, y es quien independientemente de otras responsabilidades, tiene la responsabilidad y autoridad que incluye: a. Asegurar que se establecen, implantan y mantienen los procesos necesarios para el sistema de gestión de la calidad en materia de TIC b. Informar a la Gerencia de la UTI y al Patrocinador del proyecto sobre el funcionamiento del sistema, incluyendo las necesidades para la mejora c. Promover la toma de conciencia de los requisitos de los clientes en todos los niveles de la organizació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.


3.4.3. Comunicación interna El Coordinador de proyectos, utilizará los procesos apropiados de comunicación establecidos en la Metodología para el Desarrollo de Proyectos de Tecnologías de Información.

3.5.

Revisión de la Gerencia

Las revisiones del SGC se realizan anualmente o cuando el Gerente de la UTI lo determine. El gerente de la UTI planea la revisión del sistema para asegurar su continua uniformidad, adecuación y eficacia. Esta revisión incluye la evaluación de las oportunidades de mejora y la necesidad de efectuar cambios en el sistema, incluyendo la Política de la Calidad y los Objetivos de la Calidad, entre otros.

4.

GESTIÓN DE RECURSOS 4.1.

Provisión de recursos

A través de las metas establecidas producto de los planes estratégicos, tácticos y operativos, características y condiciones de equipo, son los insumos que son revisados por la Jefatura de la UTI y determinan los recursos necesarios para implantar, mantener y mejorar continuamente la eficacia de los procesos del sistema de gestión de la calidad y para lograr la satisfacción del cliente. Dentro de estos recursos se incluyen la capacitación y entrenamiento del personal involucrado en actividades de TIC, equipos de cómputo o equipos especializados, programas de usuarios, sistemas operativos, paquetes especializados de programas, bases de datos y otros implementos.


4.2.

Recursos Humanos

4.2.1. Asignación de personal El personal con responsabilidades definidas en el Sistema de Gestión de la Calidad, es competente con base en la educación, formación, habilidades, prácticas y experiencia que son necesarias para la ejecución de sus actividades, las cuales deben estar definidas en el perfil del funcionario que desempeñarán dichos cargos. 4.2.2. Competencia, toma de conciencia y formación Para mantener al personal actualizado en las competencias sobre calidad, se realizarán las siguientes actividades: • Identificar necesidades de competencia del personal que ejecuta actividades que afectan a la calidad; • Proporcionar capacitación y entrenamiento para cubrir esas necesidades; • Evalúa la efectividad del entrenamiento provisto; • Institucionalmente asegurarse que los empleados están conscientes de la pertinencia e importancia de sus actividades y cómo ellas contribuyen al logro de los objetivos de la calidad. Se conservan las evidencias y registros correspondientes de la escolaridad o educación, formación, calificación y experiencia del personal. Lo anterior debido a la importancia de poder detectar las carencias de conocimientos y formación en todo ámbito, y poder cubrir tales necesidades mediante una correcta evaluación de competencias, y dictar programas de capacitación adecuados.


El siguiente diagrama proporciona un modelo válido para un programa de capacitación.

4.2.3. Infraestructura Identificar y mantener las instalaciones necesarias para lograr la conformidad de los productos y servicios incluyendo el espacio de trabajo, hardware, software básico y utilitario, y los servicios de soporte. 4.2.4. Ambiente de trabajo 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: • Temperatura del lugar de trabajo • Espacio de trabajo (Evitar interferencias) • Ergonomía • Iluminación


5.

CONSIDERACIONES EN EL DESARROLLO

El macro proceso “Gestión de Tecnologías de Información y Comunicación PA-08” que incorpora el MAGEFI y que involucra a la UTI, incorpora seis actividades que deben realizarse, a saber: diagnóstico, análisis, diseño, obtención, implementación y operación. Cada una de estas actividades conllevan tareas que consideran la planificación de la calidad, en la cual se pretende identificar las normas que son relevantes para el proyecto y poder determinar cómo satisfacerlas; el aseguramiento de la calidad, que consiste en aplicar las actividades planificadas y sistemáticas relativas a la calidad, para asegurar que el proyecto utilice todos los procesos necesarios para cumplir con los requisitos; el control de la calidad, cuyo fin es supervisar los resultados específicos del proyecto para determinar si cumplen con las normas de calidad relevantes y si se identifican modos de eliminar las causas de un rendimiento no satisfactorio. 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. Modelo de calidad congruente con el modelo de desarrollo de aplicaciones y estrategia de desarrollo institucional 5.1.

Etapa de Diagnóstico y Análisis

A lo largo de esta actividad, es un requisito que se emprenda la búsqueda de buenas prácticas de calidad sobre el servicio o producto, que se encuentren en el mercado,


incluyendo instituciones o empresas que utilicen o brinden soluciones similares para implementar un plan de visitas. 5.1.1. Planificación • Elaborar la ficha del proyecto de conformidad con lo establecido en la Metodología de Desarrollo de Proyectos en TIC. • Definir con el patrocinado el personal involucrado para documentar y conciliar las expectativas sobre el proyecto. • Desarrollar capacidad en los equipos de proyecto en temas de manejo de proyectos y procesos de documentación así como para el control de cambios. • Analizar los riesgos asociados con la implementación del producto o servicio. • Conservar los estándares definidos en la Unidad de Tecnologías de Información (UTI) durante el desarrollo del proyecto.

En caso de ser

necesaria la definición de un nuevo estándar, el gerente del proyecto debe de realizar la justificación del mismo a la jefatura de la UTI, documentando el requerimiento y justificando su elaboración. • Desarrollar un modelo conceptual con la misión por cumplir y sus objetivos en donde se desglosen las funcionalidades del producto con respecto a los objetivos del mismo. Este modelo debe ser revisado y aprobado por el usuario, indicando de ser el caso, los comentarios relevantes de cada funcionalidad. • Definir índices de seguimiento del proyecto de acuerdo con la Metodología para el Desarrollo de Proyectos en TIC y el Manual de Estándares. • Crear un diccionario de términos con las características de los mismos y los rangos y niveles de tolerancia. • Definir los datos operativos y datos históricos para poder determinar niveles de antigüedad de esos datos y su tratamiento o archivo de conformidad con la legislación vigente.


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 • Posterior al cierre de la etapa, se realizará un análisis del libro del proyecto para determinar que se cumplieran los objetivos definidos y que la documentación se encuentre completa y no sea ambigua. • Cronograma de actividades del proyecto con su ruta crítica y responsables de las actividades. • Lista de los participantes y su rol en el proyecto. • Plan de productos entregables con sus características y sus fechas. • Visto bueno de los entregables por parte del líder y del patrocinador del proyecto.


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

Etapa de Diseño

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 • Luego del análisis de los requerimientos del sistema, el líder técnico representará sus resultados en un diagrama de entidad-relación (ER), en el cual se deben de detallar los volúmenes esperados de registros y pueda detallar los requerimientos de capacidad de acuerdo con lo establecido en la metodología para el desarrollo de proyectos en TIC.


• Se debe de incluir un diagrama de relaciones desde y hacia otros sistemas o fuentes de datos; la manera en que esta comunicación será realizada y la frecuencia en que debe ser realizado estos procesos. Además de lo anterior, se debe de indicar las consecuencias y acciones en caso de que se presente una falla en esta comunicación. • Basado en el diagrama ER, se desarrollará un diseño lógico de la base de datos, el cual debe ser revisado por el equipo de trabajo para determinar si cumple con los requerimientos funcionales solicitados y aprobado por el administrador de las bases de datos (DBA). • Para todos los procesos de la aplicación como para los procesos en lote, se deben de definir los volúmenes de información esperados, la frecuencia de uso, los calendarios de ejecución y las relaciones de estos procesos con otras aplicaciones o sistemas, sean estas internas o externas. • Antes de la programación de la aplicación, el líder técnico debe presentar un prototipo de la aplicación que se desea desarrollar, en la que se definirán los objetivos de cada componente (página o forma por ejemplo), que serán documentadas haciendo referencia a la Metodología para el Desarrollo de Proyectos en TIC y a las funcionalidades que la misma debe realizar. También debe indicarse las entradas, salidas y el perfil de los usuarios que harán uso de la aplicación. • Antes de la programación de los procesos en lote (batch), estos deben ser diagramados e indicar con detalle el proceso que se debe de ejecutar. Además, debe de indicarse el proceso de recuperación que debe ser realizado en caso de presentarse una falla en el proceso. También, se deben de indicar las condiciones operacionales para su ejecución, detallando los datos de entrada, los datos de salida y el orden de ejecución. • Es obligación del grupo técnico definir el grado de dificultad de cada proceso, tiempo estimado de construcción y su importancia en el flujo del sistema.


• El líder técnico deberá de construir un “mapa” de la aplicación en la cual se debe de especificar la duración estimada, el perfil de seguridad de cada pantalla. • La aplicación debe contar con pantallas para el ingreso de parámetros globales de la aplicación, en las cuales los usuarios puedan modificar los valores comunes que se utilicen a lo largo del sistema. • Participantes por unidad administrativa y la carga de trabajo esperada. 5.2.2. Aseguramiento • El líder del proyecto debe verificar que exista la actividad de revisión y aceptación del prototipo en el cronograma de actividades.

Asimismo,

revisará que todas las formas de la aplicación se encuentren aceptadas por el patrocinador antes de que se inicie la etapa de construcción. • El líder del proyecto debe verificar que exista la actividad de revisión y aceptación del prototipo en el cronograma de actividades.

Asimismo,

revisará que todas las formas de la aplicación se encuentren aceptadas por el patrocinador antes de que se inicie la etapa de construcción. • Reuniones con los participantes del proyecto con agenda previa y una vez finalizada, la misma debe tener un resumen de acuerdos y estar debidamente firmada por los participantes. • Nivel de seguridad en cada componente de acuerdo con el marco de seguridad establecido. • Fuentes de datos consideradas para la cuantificación de las ocurrencias de los componentes (valores de inicio, crecimiento esperado). 5.2.3. Control • Cualquier requerimiento de ajuste o creación de soluciones tecnológicas, debe ser aceptado y aprobado según lo establecido en la metodología


• Asimismo, el líder del proyecto se encargará de revisar todos los documentos y su aceptación antes de ingresar a la etapa de construcción. • Revisión de las actas de las reuniones de acuerdo con lo establecido en la Metodología para el Desarrollo de Proyectos. • Estado de los productos entregables con un informe de avance y observaciones generales. • Cotejar que se contemplen los procesos que permitan contabilizar y depurar la información almacenada. Estos procesos deben de indicar las cifras de control que permitan verificar cantidades. • Cotejar que para los datos sensitivos se tengan definidas las pistas de auditoria y trazabilidad de los datos y procesos. 5.3.

Etapa de Obtención

En esta etapa, se realiza el proceso de obtener el producto o servicio. Se debe de considerar que eso implica para un proceso de construcción, contratación, compra, etc. En cualquier caso, el proceso debe de garantizar que se cumplan los requerimientos establecidos en las etapas anteriores. 5.3.1. Planificación • Todo programa concluido será documentado y trasladado al ambiente de pruebas en donde se le aplicarán las pruebas necesarias y se examinará funcionalidades, apariencia y facilidad de uso. Las pruebas serán realizadas tanto por el personal técnico, como por el personal del área patrocinadora. Toda prueba debe ser documentada con las observaciones pertinentes de conformidad con los aspectos evaluados. • Desarrollo de un modelo conceptual en donde se desglosen las funcionalidades del producto con respecto a los objetivos del mismo. Este mapa debe ser revisado y aprobado por el usuario, indicando de ser el caso, los comentarios relevantes de cada funcionalidad.


5.3.2. Aseguramiento • Verificar los requerimientos con cada participante y contar con su respectiva firma de conocimiento y observaciones pertinentes. • Cotejar que los formularios de control de cambios se encuentren debidamente completados y acorde con lo estipulado en la Metodología para el Desarrollo de Proyectos Informáticos. 5.3.3. Control • Documentación de cada componente detallando su participación en el proceso y su contenido. • Pruebas documentales de ejecución de cada componente y resultados obtenidos. 5.4.

Implementación

En esta etapa, se realizaran los procesos necesarios, principalmente la prueba de la solución seleccionada, para determinar que cumpla con los requerimientos y expectativas, que permitan finalizar el proceso con la etapa de operación. 5.4.1. Planificación • La unidad patrocinadora del proyecto será la responsable de analizar, probar y aceptar los productos entregables de acuerdo con los requerimientos establecidos en la Metodología para el Desarrollo de Proyectos de TIC y de conformidad con las necesidades y funcionalidades esperadas. Cada prueba debe ser documentada según lo establecido en la metodología de desarrollo. • Para la aceptación de los programas, las consultas deben ser documentadas con el respectivo plan de ejecución y determinar posibles seguros o accesos que afectan el tiempo de respuesta. Este plan debe estar aprobado por el


administrador de la base de datos (DBA) de la institución o un profesional asignado para tal fin. • El plan de pruebas debe estar acorde con los requerimientos establecidos por el patrocinador y recopilados en la etapa de análisis. • Estrategia para la trazabilidad de los datos y su nivel se seguridad. • Procesos y programas para la reconstrucción del producto o servicio. • Documentación adecuada sobre la operación de los sistemas. • Definición del plan de pruebas con fechas y responsables.

Toda la

información debe ser documentada. 5.4.2. Aseguramiento • Las pruebas serán documentadas indiferentemente si fue o no exitosa. Para todos los casos, se determinará quién es la persona responsable de la prueba, los participantes, el objetivo de la prueba, el resultado esperado y el resultado obtenido. También se registrará el tiempo consumido para cada prueba y los costos asociados. • Se realizarán pruebas de carga de proceso sobre el computador, sobre cada uno de los componentes y en los casos de procesos sensitivos se realizará un análisis de sentencias para determinar si su plan de ejecución es el más adecuado con respecto al rendimiento de la base de datos. • Al finalizar la etapa de pruebas, se debe de anexar a cada expediente de programa, los documentos del plan de ejecución y las observaciones del DBA o profesional responsable. 5.4.3. Control • Se revisarán los resultados obtenidos y las firmas de aceptación del patrocinador del proyecto. Si algún documento no se encuentra aceptado, el sistema o programa no podrá ser trasladado a producción.


• Pruebas parciales e integrales de los componentes con la definición de los márgenes de tolerancia permitidos. 5.5.

Operación

En esta etapa, el producto o servicio ingresará en un ambiente de producción para ser usado por los clientes. La idea fundamental es la de mantener el ciclo planificarhacer-revisar-actuar, que es la base para la mejora de la calidad. 5.5.1. Planificación • Analizar los riesgos asociados con la implementación del producto o servicio. • Formularios generales de comportamiento del sistema en los que se indique si .el comportamiento del sistema es el esperado. • Coordinar con el proveedor de servicio o soporte del producto en caso de tratarse de un producto externo, de lo contrario, coordinará con el líder del proyecto y el patrocinador, para que pueda brindar soporte adicional en los primeros días de operación por si se requiere de una ayuda adicional (en caso de ser necesario). • Definición del personal que brindará soporte en caso de que se presenten inconvenientes. Este personal debe tener una capacitación previa a la fecha del traslado a producción así como también contar con un plan para el manejo de contingencias, ingresado en el Sistema de Continuidad de Servicio. • Completar los formularios para el reporte de problemas definidos tanto en el Sistema de Solicitudes de Servicio (SSS) y en el Sistema de Continuidad de Servicio. • Definir los protocolos para el seguimiento de problemas y atención de procesos sensitivos. • Preparar las medidas para la medición del crecimiento de los datos desde el momento de la primer carga y del crecimiento


• 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 • Realizar una reunión semanal durante el primer mes de operación para analizar comportamiento y analizar los reportes de incidentes. • Seleccionar usuarios principales para medir el comportamiento de la aplicación y algunos de sus componentes. • Generar reportes diarios de comportamiento del producto o servicio y los respectivos procesos de análisis de datos, que debe ser analizado por el patrocinador, el líder del proyecto y la Jefatura de la UTI. 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.


• Realizar una comparación de resultados y seguimiento de los riesgos considerados y materializados en el proyecto, así como de las lecciones aprendidas. Este informe debe ser realizado por el líder del proyecto.

6.

MEDICIÓN, ANÁLISIS Y MEJORA 6.1.

Generalidades

La Contraloría General de la República , ha establecido los lineamientos para planificar e implementar los procesos de seguimiento, medición, análisis y mejora necesarios para demostrar la conformidad del producto y asegurarnos de la conformidad del sistema de gestión de la calidad, así como para mejorar continuamente la eficacia del sistema de gestión de la calidad. Estos lineamientos se describen en la Metodología para el Desarrollo de Proyectos en TIC. 6.2.

Seguimiento y Medición

6.2.1. Satisfacción del Usuario Una parte fundamental del sistema de gestión de la calidad de la Contraloría General de la República, es el de realizar el seguimiento de la información sobre la satisfacción del cliente con respecto al cumplimiento de los requisitos de los productos o servicios adquiridos. Por ello se ha establecido como norma, que cada grupo de desarrollo de proyecto elabore un procedimiento que permita conseguir y analizar la información relacionada con respecto a la satisfacción del cliente y los alcances de inicio del proyecto. Este procedimiento se encuentra definido en el Manual de Estándares en TIC. 6.2.2. Auditoria Interna Es importante que el Jefe de UTI nombre a un funcionario de la unidad para que realice auditorias a los procesos y procedimientos documentados que contemplen las


responsabilidades y requisitos de los líderes de proyecto con respecto a la aplicación del sistema de Gestión de la Calidad y que sus actividades están conforme con las disposiciones planeadas. El propósito principal es verificar que el sistema está implantado y que es eficaz. 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. 6.2.3. Seguimiento y medición de los procesos La Metodología para el Desarrollo de Proyectos de Información y Comunicaciones ha establecido métodos apropiados para el seguimiento de los resultados de los procesos que forman parte del sistema de gestión de la calidad. A través de dicho seguimiento se demuestra la capacidad de éstos para alcanzar los resultados planificados. Cuando no se alcanza los resultados planificados, se lleva a toman acciones apropiadas, según sea conveniente, para asegurar la eficacia de los procesos.


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. 6.2.4. Seguimiento y medición del producto o servicio El líder del proyecto y su personal se encargan de medir las características del producto para verificar que cumple con los requisitos establecidos. Esta actividad se realiza en las etapas apropiadas del proceso de realización del producto de acuerdo con las disposiciones planificadas y definidas en la Metodología para el Desarrollo de Proyectos Informáticos. 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. Las mediciones realizadas en cuanto al producto o servicio proveerán los datos necesarios para definir metas anuales de mejoramiento así como también establecer adecuados planes de recuperación. 6.3.

Control del producto o servicio no conforme

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.


Los productos no conformes son tratados mediante las siguientes maneras: a. Tomando acciones para eliminar la no conformidad detectada; b. Autorizando su uso, liberación o aceptación bajo concesión por una autoridad pertinente y, cuando sea aplicable, por el usuario; c. Tomando acciones para impedir su uso o aplicación originalmente previsto. En cualquiera de los casos anteriores, el líder de proyecto creará un acta de revisión de prueba con las no conformidades, observaciones, descripción de la naturaleza de los defectos y cualquier acción tomada posteriormente, incluyendo las concesiones que se hayan obtenido. En caso de haber corregido un producto no conforme, éste se somete a una nueva verificación para demostrar su conformidad con los requisitos. Cuando se detecta un producto no conforme después de la entrega o cuando ha comenzado su uso, el líder de proyecto toma las acciones apropiadas respecto a los efectos, o efectos potenciales, que éste pueda traer. 6.4.

Análisis de datos

Los responsables de cada una de las áreas de la organización y de los procesos relacionados con TIC, determinarán y recopilarán datos, ya sea por entrevista personal o telefónica, encuestas u otro medio que se defina, que luego de procesarse sirva de insumos para las reuniones con el personal de TIC que permitan analizar los datos apropiados para demostrar la idoneidad y la eficacia del sistema de gestión de la calidad y para evaluar dónde puede realizarse la mejora continua. El análisis de datos proporciona información sobre: • La satisfacción del cliente. • La conformidad con los requisitos del producto. • El Compromiso con el Sistema de Gestión de Calidad.


• El grado en que los procesos alcanzan los resultados planificados. • Otros considerados importantes 6.5.

Mejora

6.5.1. Mejora Continua Es obligatorio mejorar continuamente la eficacia del sistema de gestión de la calidad mediante el uso de la política de la calidad, los objetivos de la calidad, los resultados de las auditorías, el análisis de datos, las acciones correctivas y preventivas y la revisión por la gerencia, complementando con planes de mejora, y un continuo seguimiento por medio de reuniones periódicas dentro del grupo de TIC, así como ampliarlo a otro personal interno o externo que ayude a ir mejorando los procesos. Se establecerá bitácoras de seguimiento y evaluación de resultados, que serán analizados dos veces al año por la Gerencia de Proyectos, con miras a establecer metas de mejoramiento a nivel de producto y a nivel de servicio. 6.5.2. Acción Correctiva La Contraloría General de la República, a través de la Jefatura de Tecnologías de Información, tomará las acciones pertinentes para determinar la(s) causa(s) que de alguna manera, afecten el cumplimiento de no conformidades con objeto de prevenir que vuelvan a ocurrir. Las acciones correctivas son apropiadas para los efectos de las no conformidades encontradas. Para tales efectos, se seguirá lo indicado en la Metodología para el Desarrollo de Proyectos en Tecnologías de Información y Telecomunicaciones así como los procedimientos y formularios definidos en el Manual de Estándares de TIC.


6.5.3. Acción Preventiva Una vez al año, la Jefatura de Tecnologías de Información de la Contraloría General de la República a través del Comité de Apoyo, revisará, el Manual de Calidad y los elementos y sugerencias relacionadas, tanto a nivel interno como por conceptos de evolución externa de los conceptos de calidad. También, llegará a mantener toda la información que por aspecto de mediciones, artículos, recomendaciones o estudios, se hayan recopilado durante el año. La idea básica es la de establecer una base de datos en lo que respecta al tema de la calidad, y también tener un historial del comportamiento de las aplicaciones en uso por parte de la CGR. De esta manera, se podrá tener un patrón de comportamiento y poder medir las distorsiones estacionarias o permanentes de estos componentes para poder así, definir acciones preventivas.


Anexo - NTP9

Modelo de Arquitectura de Información



Modelo de Arquitectura de Información para la Contraloría General de la República. Versión 1.0 Año 2008. Introducción Este documento presenta una primera versión de modelado de una arquitectura de información para la Contraloría General de la República; estructurada a partir del análisis de los macroprocesos y procesos definidos en el Manual General de Fiscalización Integral denominado MAGEFI, en su versión resultante de la revisión integral que se le dio en el año 2008 con el propósito de actualizar y mejorar este instrumento normativo. Esta versión del MAGEFI fue aprobada mediante resolución R-CO-54-2008 el 27 de octubre del 2008 y publicada en el Diario Oficial La Gaceta No 218 del martes 11 de noviembre del 2008. Esta primera versión del Modelo de Arquitectura de Información (MAI) se sustenta en la definición de insumos y productos definidos para cada proceso en el MAGEFI y hace una primera definición de los flujos de información.

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.


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. Para el caso de la Contraloría General, el Plan Estratégico del Área de Sistemas y Tecnología de Información del año 1998, propuso un modelo de arquitectura de información que, en buena medida, ha determinado el inventario de sistemas de información y de soluciones tecnológicas disponibles. Este modelado de arquitectura de información previo se sustentó en la primera emisión del MAGEFI que se promulgó en el año 1999 y que se elaboró como parte de un proceso de modernización que impulsó la Contraloría General a mediados de 1996; orientado a definir un nuevo modelo de fiscalización superior de la Hacienda Pública.


Con la reciente revisión integral del MAGEFI y la promulgación de su nueva versión, se requiere actualizar el modelo de arquitectura 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. Esta realidad queda evidenciada en las últimas orientaciones estratégicas y tácticas que la CGR se ha dictado para gestionar las TIC institucionales; planteadas en el Plan Estratégico de Tecnologías de Información y Comunicaciones (PETIC); así como en su respectivo Plan Táctico (PTAC).

Relación entre el Plan Estratégico de TIC y el Modelo de Arquitectura de Información El MAI es una herramienta controlada y usada por el nivel estratégico de la organización, que ayuda a visualizar con base en prioridades y lineamientos del Plan Estratégico Institucional, el aporte o apoyo que las TIC’s brindan al alcance de objetivos. Es por ello que debe existir una adecuada interrelación entre el MAI y el Plan Estratégico de TIC (PETIC). En ese sentido, se puede indicar que un buen PETIC incorpora un estado actual y futuro del MAI y al mismo tiempo un buen MAI debe considerar los lineamientos o fundamentos básicos del PETIC.

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 insumo fundamental para desarrollar el modelado de la arquitectura de información de la CGR, es la definición de los macro procesos y procesos institucionales de primer nivel, debidamente formalizada en la más reciente versión del MAGEFI. 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.


En su siguiente versión el MAI podrá detallar aún más respecto a entidades de información y flujos, en la medida que avance el proyecto institucional de documentación de segundo nivel del MAGEFI, relativo a los procedimientos que conforman cada actividad de los procesos institucionales. 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. La técnica del BSP implementa un enfoque estructurado para ayudar a establecer un plan de sistemas de información que pueda satisfacer las necesidades de la organización, esto a partir del análisis de los procesos del negocio y de la información que fluye en ellos. En el desarrollo de esta primera versión del MAI la técnica BSP se aplicó en una versión simplificada, dado que se disponía únicamente de la descripción general de los procesos de la organización compilados en el MAGEFI. 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: • Procesos – Unidades funcionales, indicando si la unidad tiene responsabilidad primaria, mayor implicación o menor implicación en el proceso.


• Clases de datos – Unidades funcionales, indicando quien crea y quien usa la información a partir de los insumos y productos definidos para cada proceso. • Sistemas – Unidades funcionales, asociando unidades con sistemas, indicando para cada uno si actualmente existe, si está planeado, en construcción o si es un sistema actual que requiere evolución. • Sistemas – Procesos, asociando procesos a sistemas, indicando para cada uno si actualmente existe, si está planeado, en construcción o si es un sistema actual que requiere evolución. • Procesos – Bases de datos sujeto asociando entidades de información con procesos, indicando cual proceso crea y cual usa la información. Luego, a partir del análisis y procesamiento de la matriz de procesos – Bases de datos sujeto; se agrupan procesos y datos en sistemas principales a los cuales se les da un nombre tentativo. De estos sistemas principales se trazan los flujos de datos de un sistema a otro, del que crea la información al que la utiliza.

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.

䴀愀琀爀椀稀䈀匀倀

Atención de los sistemas actuales Los sistemas que están actualmente en operación, así como los que están en desarrollo deberán someterse a revisión a fin de buscar una integración, ya que estos sistemas fueron concebidos para solventar necesidades puntuales de algún alcance de un proceso determinado y deben ahora responder a un enfoque integral de procesos como lo plantea el MAGEFI.


En la definición de esta primera versión de MAI se tomaron en cuenta los sistemas actuales, los que están en desarrollo, los que se conoce que requieren de evolución y los que se tienen como sistemas planeados. Cada uno de ellos se asoció al macrosistema con el que guardaba mayor afinidad.

Descripción de Macrosistemas y Sistemas asociados A continuación se presentan los macrosistemas identificados y para cada uno de ellos la lista de sistemas asociados. Macrosistema de Fiscalización Integral: Comprende los sistemas que principalmente apoyan los procesos de Fiscalización Integral. 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) Macrosistemas de Gobierno Corporativo: Comprende los sistemas que principalmente apoyan los procesos de Gobierno Corporativo. Sistemas: • Monitoreo del Entorno (Planeado) • Planificación y Evaluación de la Gestión Institucional (Planeado)


• Diseño Organizacional (Planeado) • Asesoría interna (Planeado) • Mejora Continua (Planeado) Macrosistema de Gestión del Conocimiento: Comprende los sistemas que principalmente apoyan los procesos de Gestión del Conocimiento. Sistemas: • Integrado de Recursos Humanos (actual) • Sistema de Gestión del Conocimiento Institucional (planeado) • BD soluciones TIC (en construcción) • Memoria Anual (planeado) Macrosistema de Gestión de Recursos: Comprende los sistemas que principalmente apoyan los procesos de Gestión de Recursos. 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)

Descripción de los sistemas Para cada sistema identificado se presenta una descripción general y en un siguiente nivel se presenta un detalle con los sistemas actuales, planeados, en construcción o existentes pero que requieren evolución. Para cada sistema se plantean las entradas, flujos de datos y salidas.


Nombre del Sistema Estado Macrosistema Subsistemas asociados CRM (planeado)

Requerimientos de clientes externos

Planeado Fiscalización Integral

Help Desk (requiere evolución) Sistema de control de requerimientos de clientes externos (Planeado) Sistema de Preguntas Frecuentes (requiere evolución) Entradas Flujo de datos PP-01-I1 Requerimientos de los clientes Del cliente externo externos PP-01-I2 Mejores prácticas sobre gestión Del entorno pública PP-01-I3 Informes de análisis del entorno Sistema de Monitoreo del Entorno PP-01-I4 Histórico de productos de BD de Conocimiento fiscalización integral PP-01-I5 Información

sistematizada Sistema de Monitoreo del Entorno

sobre los sujetos fiscalizados PP-01-I6 Marco jurídico y técnico

Del entorno

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 Nombre del Sistema Pronunciamientos En construcción Estado Fiscalización Integral Macrosistema Subsistemas asociados Registro de pronunciamientos de la CGR (actual) Entradas PP-02-I1 Solicitud de Criterio PP-02-I2 Solicitud Interna de Servicio

Flujo de datos Del cliente externo Sistema de requerimientos de clientes

externos PP-02-I3 Productos de fiscalización BD de Conocimiento integral anteriores PP-02-I4 Asesoría interna escrita PP-02-I4 Criterio de asesoría externa PP-02-I5 Marco Jurídico PP-02-I6 Marco jurisprudencial doctrinal aplicable

Sistema de Asesoría Interna Del entorno Del entorno y Del entorno


Salidas PP-02-P1 Criterio emitido Nombre del Sistema Estado Macrosistema Subsistemas asociados Manejo de la participación

Fiscalización Previa Planeado Fiscalización Integral de la CGR en el proceso de contratación administrativa

(SIAC para tareas de la CGR) (actual) Manejo de nulidad de contratos (planeado) Calificación de Idoneidad (actual requiere evolución) Control de autorizaciones (planeado) Control de legalización de libros (planeado) Presupuestos públicos (actual) Planificación de Instituciones (construcción) Gestión Municipal (construcción) Gastos de Partidos Políticos (Planeado) Control de visado (planeado) Tarifas, cánones, viáticos, kilometraje y zonaje (planeado) Entradas PP-03-I1 Solicitud interna de servicio PP-03-I2 Oficios

Flujo de datos Sistema de Requerimientos de clientes

externos de solicitud de Del cliente externo

autorización y aprobación con sus anexos PP-03-I3 Recursos de objeción o Del cliente externo apelación en materia de contratación administrativa PP-03-I4 Requerimiento de dictámenes Del cliente externo previos favorables de carácter vinculante PP-03-I5 Histórico de productos de BD de Conocimiento fiscalización integral PP-03-I6 Marco jurídico PP-02-I7 Marco jurisprudencial doctrinal aplicable

Del entorno y Del entorno


PP-03-I8 Programación macroeconómica Del entorno del Poder Ejecutivo PP-03-I9 Información


sobre el sujeto fiscalizado 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 Nombre del Sistema Fiscalización Posterior En construcción Estado Fiscalización Integral Macrosistema Subsistemas asociados Registro de la Actividad Contractual (actual) Registro de Declaraciones Juradas de Bienes y Control de consistencia (actual) Ejecución presupuestaria (actual) Seguimiento de Disposiciones (actual) Manejo de las Denuncias (unido a Denuncia Electrónica) (actual) Control de Riesgos para la Fiscalización (planeado) Entradas PP-04-I1

Perfil

del

proyecto

Flujo de datos de Sistema de Planificación y Evaluación de

fiscalización posterior la Gestión Institucional PP-04-I2 Histórico de productos de BD de conocimiento fiscalización integral PP-04-I3 Marco jurídico PP-04-I4 Marco doctrinal


jurisprudencial aplicable PP-04-I5 Criterios técnicos externos Del entorno PP-04-I6 Informes de Auditorías Internas Cliente Externo y Externas PP-04-I7 Información


sobre el sujeto fiscalizado Salidas PP-04-P1 Nota Informe PP-04-P2 Informe PP-04-P3 Relación de hechos PP-04-P4 Denuncia penal


PP-04-P5 Oficios de cierre de disposiciones Nombre del Sistema Procedimientos Administrativos Planeado Estado Fiscalización Integral Macrosistema Subsistemas asociados Registro de Sancionados (actual) Entradas Flujo de datos PP-05-I1 Relación de hechos Sistema de Fiscalización Posterior PP-05-I2 Histórico de productos de BD de Conocimiento fiscalización integral PP-05-I3 La defensa y las pruebas de las Cliente externo partes PP-05-I4 Marco jurídico PP-05-I5 Marco doctrinal


jurisprudencial aplicable Salidas PP-05-P1 Resolución final del procedimiento administrativo PP-05-P2 Registro de sancionados PP-05-P3 Título ejecutivo Nombre del Sistema Estado Macrosistema Subsistemas asociados

Litigios


Entradas Flujo de datos PP-06-I1 Histórico de productos de BD de conocimiento fiscalización integral PP-06-I2 Marco jurídico PP-06-I3 Marco doctrinal


jurisprudencial aplicable PP-06-I4 La defensa y las pruebas de las Del cliente externo partes PP-06-I5 Demanda/Contra demanda y Del cliente externo sus antecedentes cuando corresponda 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


Nombre del Sistema Estado Macrosistema Subsistemas asociados

Asesoría sobre hacienda pública


Entradas PP-07-I1 Solicitud interna de servicio

Flujo de datos Sistema de Requerimientos de Clientes

PP-07-I2 Solicitudes de asesorías PP-07-I3 Perfil de proyecto

Externos Del cliente externo Sistema de Planificación y Evaluación de

la Gestión Institucional PP-07-I4 Histórico de productos de BD de conocimiento fiscalización integral PP-07-I5 Marco jurídico PP-07-I6 Marco jurisprudencial


doctrinal aplicable PP-07-I7 Informes del Ministerio de Del cliente externo Hacienda y de MIDEPLAN PP-07-I8 Análisis integral requerimientos del cliente externo

de Sistema de Requerimientos de Clientes Externos

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 Nombre del Sistema Estado Macrosistema Subsistemas asociados Sitio Web

Capacitación Externa


Campus Virtual Entradas PP-08-I1 Perfil de proyecto

Flujo de datos Sistema de Planificación y Evaluación de

la Gestión Institucional PP-08-I2 Histórico de productos de BD de Conocimiento fiscalización integral PP-08-I3 Marco jurídico PP-08-I4 Marco jurisprudencial doctrinal aplicable



PP-08-I5 Marco técnico PP-08-I6 Solicitud interna de servicio

Del entorno Sistema de Requerimientos de Clientes Externos

Salidas PP-08-P1 Datos de las actividades de capacitación externa Nombre del Sistema Rectoría Planeado Estado Fiscalización Integral Macrosistema Subsistemas asociados Ranking de Auditorías Internas (actual) Entradas PP-09-I1 Perfil de proyecto PP-09-I2 Marco jurídico PP-09-I3 Marco jurisprudencial

Flujo de datos Sistema de Planificación y Evaluación de la Gestión Institucional Del entorno y Del entorno

doctrinal aplicable PP-09-I4 Criterios legales y técnicos Del entorno externos PP-09-I5 Estudios de diagnóstico de Del entorno fuentes externas PP-09-I6 Información


sobre los sujetos pasivos PP-09-I7 Histórico de productos de BD de Conocimiento fiscalización integral 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


Servicio al Cliente Externo



Entradas PP-10-I1 Solicitud interna de servicio

Flujo de datos Sistema de Requerimientos de Clientes

Externos PP-10-I2 Productos de fiscalización BD de Conocimiento integral PP-10-I3 revocatoria

Recursos contra

de

apelación/ Del cliente externo

productos

de

fiscalización PP-10-I4 Quejas de los clientes externos Del cliente externo sobre productos

de fiscalización o el

servicio suministrado PP-10-I5 Opinión de los clientes externos Del cliente externo sobre su percepción de valor acerca de los productos de fiscalización 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 Nombre del Sistema Estado Macrosistema Subsistemas asociados Entradas Modelo Organizacional

Monitoreo del Entorno

Planeado Gobierno Corporativo

y

Flujo de datos Normativa Sistema de Diseño Organizacional

Interna PA-01-I1 Información difundida por los Del entorno medios de comunicación colectiva PA-01-I2 Opiniones rendidas sobre Del entorno proyectos de ley PA-01-I3 Actas legislativas

De la Asamblea Legislativa


PA-01-I4

Análisis

integral

de Sistema de Requerimientos de Clientes

requerimientos del cliente externo Externos PA-01-I5 Jurisprudencia de los tribunales Del entorno nacionales y pronunciamientos de la Procuraduría General de la República PA-01-I6 Publicaciones e investigaciones PA-01-I7 Opinión de expertos PA-01-I7 Opinión de expertos internos PA-01-I8 Histórico de productos de

Del entorno Del entorno Sistema de Asesoría Interna BD de Conocimiento

fiscalización integral PA-01-I9 Información sobre la gestión Del cliente externo institucional de los sujetos pasivos PA-01-I10 Reportes sobre sugerencias Sistema de Servicio al Cliente Externo 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 Nombre del Sistema

Planificación y Evaluación de la Gestión Institucional

Planeado Estado Gobierno Corporativo Macrosistema Subsistemas asociados Sistema institucional de riesgos (Planeado) Entradas Modelo Organizacional

y


Interna PA-02-I1 Histórico de Informe de labores Sistema del Conocimiento Institucional de la Contraloría General PA-02-I2 Solicitud interna de servicio

Sistema de Requerimientos de Clientes

Externos PA-02-I3 Informes de análisis del entorno Sistema de Monitoreo del Entorno PA-02-I4 Información sistematizada Sistema de Monitoreo del Entorno sobre los sujetos fiscalizados Informe de diagnóstico de necesidades Sistema de Monitoreo del Entorno de los sujetos fiscalizados


PA-02-I5

Directrices

técnicas

y De la Dirección General de Presupuesto

metodológicas emitidas por la Dirección Nacional del Ministerio de Hacienda General de Presupuesto Nacional del Ministerio de Hacienda PA-02-I6 Propuesta de Mejora Sistema de Mejora Continua PA-02-I7 Informes de análisis financiero Sistema de Contabilidad contables PA-02-I8 Informes de revisión interna y Sistema de Mejora Continua externa PA-02-I9 Informes de análisis integral de Sistema de Requerimientos de Clientes requerimientos del cliente externo Externos PA-02-I10 Reportes de medición de Sistema de Servicio al Cliente Externo valor público 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 Nombre del Sistema Diseño Organizacional Planeado Estado Gobierno Corporativo Macrosistema Subsistemas asociados Cuadro de Mando Integral (Planeado) Entradas PA-03-I1 Perfil de proyecto

Flujo de datos Sistema de Planificación y Evaluación de

la Gestión Institucional PA-03-I2 Mejores prácticas sobre gestión Del entorno pública o privada PA-03-I3 Normativa externa Salidas PA-03-P1 Modelo organizacional PA-03-P2 Normativa interna CGR

Del entorno


Nombre del Sistema Estado Macrosistema Subsistemas asociados Entradas Modelo Organizacional

Asesoría interna


y


Interna PA-04-I1 Solicitudes de asesoría PA-04-I2 Perfil de proyecto

Del cliente interno Sistema de Planificación y Evaluación de

la Gestión Institucional PA-04-I3 Informes de revisión interna o Sistema de Mejora Continua externa PA-04-I4 Criterios legales y técnicos Del entorno externos PA-04-I5 Histórico de asesorías internas BD de Conocimiento PA-04-I6 Marco jurídico Del entorno PA-04-I7 Marco jurisprudencial y Del entorno doctrinal aplicable PA-04-I8 Mejores prácticas sobre gestión Del entorno pública Salidas PA-04-P1 Asesoría interna escrita PA-04-P2 Asesoría interna verbal PA-04-P3 Advertencias de la auditoría interna


Mejora Continua



Entradas Modelo Organizacional PA-05-I1 Perfil de proyecto PA-05-I2

Propuestas

de

Flujo de datos Sistema de Diseño Organizacional Sistema de Planificación y Evaluación de diseño

la Gestión Institucional o Sistema de Requerimientos de Clientes

rediseño de nuevos productos Externos PA-05-I4 Reportes sobre sugerencias de Sistema de Servicio al Cliente Externo los clientes externos PA-05-I5 Mejores prácticas sobre gestión Del entorno pública o privada PA-05-I6 Inventario de riesgos externos Sistema de Monitoreo del Entorno PA-05-I7 Informes de evaluación Sistema de Planificación y Evaluación de institucional anteriores la Gestión Institucional PA-05-I8 Reportes de medición de valor Sistema de Servicio al Cliente Externo público PA-05-I9 Normativa interna PA-05-I10 Marco jurídico

Sistema de Diseño Organizacional Del entorno

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


Nombre del Sistema Estado Macrosistema Subsistemas asociados Prontuario (actual)

Integrado de Recursos Humanos

Actual Gestión del Conocimiento

Acciones de personal y pago de funcionarios (actual) Vacaciones (actual) Plan de vacaciones de los funcionarios (planeado) Control de Asistencia (actual) Capacitación interna (planeado) Evaluación del desempeño (requiere evolución) Registro de curriculums (actual) Pizarras electrónicas para organizaciones de empleados (actual) Guía telefónica de funcionarios (actual) Entradas Normativa Interna PA-06-I1 Solicitudes de empleo PA-06-I2 Perfil de competencias vigente

Flujo de datos Sistema de Diseño Organizacional Del entorno Sistema Integrado de Recursos Humanos

de las funcionarias y funcionarios de la CGR PA-06-I3 Histórico de evaluaciones del Sistema de Evaluación del Desempeño desempeño de funcionarios PA-06-I4 Modelo organizacional Sistema de Diseño Organizacional PA-06-I5 Solicitudes puntuales relativas Del cliente interno al personal. PA-06-I6 Información del mercado sobre Del entorno beneficios salariales y no salariales PA-06-I7 Informes de revisión interna y Sistema de Mejora Continua externa 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


Nombre del Sistema BD de Conocimiento Institucional Planeado Estado Gestión del Conocimiento Macrosistema Subsistemas asociados BD del negocio, labores de extracción y análisis de datos (planeado) Normativa para la Fiscalización (actual) Sistema de gestión y documentos - MTD (actual) Archivo Digital (requiere evolución) Expediente Electrónico (en construcción) Consulta al Sistema de Pronunciamientos de la CGR (actual) Sitio Web (actual) Administración de la Biblioteca y Servicios de Biblioteca Virtual (actual) Marco jurídico de la Contraloría General (requiere evolución) Bases de datos externas (planeado) Entradas Requerimientos de Información PA-07-I1 Datos internos PA-07-I2 Datos externos PA-07-I3 Mejores prácticas sobre gestión

Flujo de datos Del cliente interno BD de Conocimiento Del entorno Del entorno

de la información Salidas PA-07-P1 Información requerida disponible Nombre del Sistema BD soluciones TIC En construcción Estado Gestión del Conocimiento Macrosistema Subsistemas asociados Sistema de control de contingencias (en construcción) Sistema de solicitudes de soporte (en construcción) Administración de roles y claves de acceso (en construcción) Entradas Modelo Organizacional

y


Interna PA-08-I1 Solicitudes de servicios de los Del cliente interno clientes internos PA-08-I2 Perfil de proyecto

Sistema de Planificación y Evaluación de la Gestión Institucional


PA-08-I3 Información interna y externa Del entorno PA-08-I3 Información interna y externa BD de conocimiento PA-08-I4 Mejores prácticas de la Del entorno gestión de la información y tecnologías relacionadas PA-08-I5 Informes de análisis del entorno Sistema de Monitoreo del Entorno Salidas PA-08-P1 Datos de la solución de tecnología de información operando Nombre del Sistema Estado Macrosistema Subsistemas asociados Sitio Web

Memoria Anual

Planeado Gestión del Conocimiento

Herramientas de extracción y análisis de datos Entradas Modelo Organizacional

y


Interna PA-09-I1 Memoria organizacional Sistema de Memoria Anual PA-09-I2 Información interna BD de Conocimiento PA-09-I3 Mejores prácticas de la gestión Del entorno del conocimiento Salidas PA-09-P1 Memoria organizacional


Nombre del Sistema Presupuesto Institucional Actual Estado Gestión de Recursos Macrosistema Subsistemas asociados Módulo de Solicitudes de Pedido (En Construcción) Entradas Modelo Organizacional

y


Interna PA-10-I1 Presupuesto anual y sus Sistema de Presupuesto Institucional modificaciones,

aprobado

de

años

anteriores y del año en ejercicio PA-10-I2 Informes presupuestarios de Sistema de Presupuesto Institucional años anteriores PA-10-I3

Requerimientos Sistema de Planificación y Evaluación de

presupuestarios para el período la Gestión Institucional PA-10-I4 Informes de evaluación Sistema de Planificación y Evaluación de institucional PA-10-I5 Planes institucionales

la Gestión Institucional Sistema de Planificación y Evaluación de

la Gestión Institucional PA-10-I6 Solicitudes de los clientes Del cliente interno internos PA-10-I7 Lineamientos de planificación Sistema de Planificación y Evaluación de institucional PA-10-I8 Marco jurídico

la Gestión Institucional Del entorno

Salidas PA-10-P1 Datos de Recursos presupuestarios PA-10-P2 Separación de recursos Nombre del Sistema Estado Macrosistema Subsistemas asociados Entradas Modelo Organizacional

Contabilidad

Actual Gestión de Recursos

y


Interna PA-11-I1 Lineamientos emitidos por el De Contabilidad Nacional Órgano Rector


PA-11-I2 Marco jurídico, doctrinario, Del entorno jurisprudencial y técnico PA-11-I4 Estados financieros de periodos Sistema de Contabilidad anteriores y del ejercicio PA-11-I5 Presupuesto anual y sus Del entorno modificaciones,

aprobado

de

años

anteriores y del año en ejercicio Salidas PA-11-P1 Estados financieros PA-11-P2 Informes de análisis financiero contables Nombre del Sistema Tesorería Requiere evolución Estado Gestión de Recursos Macrosistema Subsistemas asociados Sistema de pago de viáticos (En construcción) Entradas Modelo Organizacional

y


Interna PA-12-I1 Solicitudes internas Del cliente interno PA-12-I2 Presupuesto anual y sus De la Asamblea Legislativa modificaciones,

aprobado

de

años

anteriores y del año en ejercicio PA-12-I3 Estados financieros Sistema de Contabilidad PA-12-I4 Marco jurídico, doctrinario, Del entorno jurisprudencial y técnico PA-12-I5 Informes presupuestarios PA-12-I6 Separación de recursos PA-12-I7 Recibo a satisfacción del bien PA-12-I8 Factura Comercial

Sistema de Presupuesto Institucional Sistema de Presupuesto Institucional Sistema de Bienes y Servicios Del entorno

Salidas PA-12-P1 Datos sobre recursos financieros ejecutados PA-12-P2 Orden de pago


Nombre del Sistema Bienes y Servicios Actual Estado Gestión de Recursos Macrosistema Subsistemas asociados Registro de proveedores (actual) Compras (actual) Suministros (requiere evolución) Activos fijos (actual) Trámites administrativos (requiere evolución) Entradas Modelo Organizacional

y


Interna PA-13-I1 Presupuesto anual aprobado De la Asamblea Legislativa del año en ejercicio PA-13-I2 PA-14-I3 Marco jurídico PA-13-I3 Marco jurisprudencial


doctrinario aplicable PA-13-I4, PA-14-I1, PA-15-I1 Solicitudes Del cliente interno de los clientes internos PA-13-I5 Separación de recursos PA-14-I2 Perfil de proyecto

Sistema de Presupuesto Institucional Sistema de Planificación y Evaluación de

la Gestión Institucional PA-14-I4 Marco jurisprudencial y técnico Del entorno aplicable PA-14-I5 Bienes recibidos Sistema de compras PA-15-I2 Mejores prácticas sobre gestión Del entorno pública o privada PA-15-I3 Servicios contratados

Sistema de compras

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


ANEXO Consideraciones relativas al documento MAGEFI analizadas al desarrollar el Modelo de Arquitectura de Información.

刀攀氀愀挀椀漀渀愀搀漀挀漀渀䴀愀最攀昀椀


Anexo - NTP10

Marco de Seguridad en tecnologías de Información



A. Introducción. Este documento define el marco de referencia de seguridad adecuado al nivel de las tecnologías de información y comunicaciones (TIC), sobre el cual la Contraloría General de la República (CGR) debe dirigir, implementar y administrar sus adquisiciones de TIC para garantizar la continuidad, integridad y confiabilidad de sus bases de datos automatizadas. El documento se sustenta en el conocimiento y la experiencia derivados del trabajo realizado por funcionarios de la Unidad de Sistemas y Tecnologías de Información de la CGR, y toma como referencia las siguientes normativas, como prácticas líderes: • La norma de referencia ISO 27001. • Las Normas técnicas para la gestión y el control de las Tecnologías de Información (N-2-2007-CO-DFOE). Mediante este Marco de Seguridad se cumple con la normativa de la CGR, específicamente en lo que corresponde al punto 1.4

B. POLÍTICA DE SEGURIDAD. B.1. Política de seguridad. Este acápite hace referencia al punto 1.4.1 de la Normativa de la CGR. La política de seguridad en tecnologías de información de la Contraloría General de la República se sustenta en los siguientes elementos: • Un marco de seguridad que define los elementos necesarios que deben considerarse a nivel institucional para el establecimiento de un esquema adecuado de seguridad tecnológica. Este documento se basa en las


recomendaciones de las Normas técnicas para la gestión y el control de las Tecnologías de Información (N-2-2007-CO-DFOE) y la ISO 27001. • Las directrices sobre seguridad y utilización de las tecnologías de información y comunicaciones de la CGR; aprobadas mediante resolución R-CO-612007 del 7/12/2007, el cual es la guía de referencia institucional para el uso adecuado de las TICS y que se constituye como un producto de este Marco de Seguridad.

B2. Revisión de la política de seguridad. El documento Directrices sobre seguridad y utilización de las tecnologías de información y comunicaciones debe ser revisado por un comité de seguridad (ver más adelante la conformación de este comité) al menos dos veces al año, considerando dentro de esto lo siguiente: • Una correcta aplicabilidad de las directrices que están operando: Se refiere al hecho de determinar si las directrices que se hayan establecido son aplicables para la Institución, o si deben ser modificadas o eliminadas. • Incorporación de nuevas directrices de acuerdo a requerimientos en seguridad que puedan surgir producto de cambios en el ambiente o de nuevas tecnologías o servicios incorporados dentro de la Contraloría. • Requerimientos específicos de la Administración Superior.

B3. Establecimiento de esquemas de sensibilización y capacitación al personal para el uso adecuado de las TICS a nivel institucional. Se deben definir y revisar por parte del Oficial de Seguridad en Tecnologías de Información (CSO)1, los procesos y planes necesarios de sensibilización y capacitación al personal, para la mejor utilización de las TICS. Este debe ser un proceso permanente y debe evaluarse periódicamente con el propósito de garantizar su adecuada aplicación. 1

Más adelante se define formalmente la figura del Oficial de Seguridad en TIC.


C. Organización de la seguridad de la información. C1. Estructura funcional de la seguridad de la información. La estructura necesaria para garantizar la vigencia y continuidad de la seguridad en tecnologías de información es la siguiente: 1. El Despacho es el encargado de aprobar o improbar las directrices de seguridad que sean consideradas como parte de la gestión de la seguridad y podrá apoyarse en las recomendaciones del Comité Gerencial de Tecnologías de Información y Comunicación (CGTIC). 2. Comité de seguridad en TIC. (CSTIC): Grupo interdisciplinario de funcionarios destinado al mantenimiento de las directrices de seguridad a nivel institucional. El CSTIC se reúne semestralmente o cuando sea requerido por alguno de sus miembros y dentro de sus funciones están: a. Analizar la incorporación de nuevas directrices de seguridad acorde a requerimientos específicos de la administración superior, o requerimientos producto de los monitoreos que sean realizados por el encargado de la seguridad en TIC (Oficial de Seguridad). b. Analizar la aplicación de las directrices existentes y proponer medidas para asegurar su cumplimiento. c. Someter al Despacho de las señoras Contraloras las nuevas directrices con el propósito de que sean aprobadas y oficializadas. Como parte del grupo interdisciplinario de funcionarios que conforman el CS, deberán considerarse al menos las siguientes áreas: • Despacho de las Contraloras Generales. • Unidad de Recursos Humanos. • División de Contratación Administrativa


• Unidad de Servicios Generales. • Unidad de Sistemas y Tecnologías de Información. • División de Fiscalización Operativa y Evaluativa. La Auditoria interna, en casos de que se considere pertinente, debe participar en calidad asesora con el propósito de fortalecer el sistema de control interno institucional. 1. El Oficial de Seguridad en TIC (CSO). Es el coordinador del CSTIC y dentro de sus funciones están: a. Coordinar el CSTIC a nivel Institucional. b. Analizar y recomendar la implementación de directrices relacionadas con la utilización de las TIC, en pro del mejoramiento de los niveles de seguridad de la información en la CGR. c. Coordinar con los encargados de los servicios y

con los usuarios, la

implementación de las medidas de seguridad. d. Velar

por

el

debido

cumplimiento

de

las

directrices

definidas

institucionalmente respecto a la seguridad y utilización de las tecnologías de información y comunicaciones. e. Coordinar con la jefatura de la USTI para la aplicación de medidas de seguridad necesarias para minimizar posibles vulnerabilidades que puedan poner en riesgo la información o recursos tecnológicos. f. Coordinar con la jefatura de la USTI la aplicación adecuada y la verificación de la integridad de los respaldos, por parte de los responsables de las áreas funcionales. g. Coordinar junto con la Jefatura de la USTI, la vigencia de la información almacenada dentro del sistema de Contingencias. h. Asesorar durante el desarrollo, adquisición o implementación de soluciones tecnológicas con el propósito de garantizar productos que cumplan con las directrices de seguridad institucional.


i. Coordinar con las áreas correspondientes de la organización, los procesos necesarios de sensibilización y educación a nivel de seguridad en las TIC para todos los funcionarios. j. Coordinar las acciones correspondientes cuando se suscite algún incidente de seguridad que ponga en riesgo la información de la CGR k. Participar en reuniones de diseño de los nuevos servicios o sistemas, apoyando al grupo de trabajo para la elaboración de un producto que cumpla con los requerimientos de seguridad institucional. El punto de referencia son las directrices institucionales en seguridad de información. l. Determinar la presencia de eventos que puedan poner en riesgo la seguridad o continuidad de las TIC, coordinar con los responsables y tomar las medidas correctivas. El CSO mantendrá en coordinación con

la jefatura de la USTI, comunicación

permanente con los responsables de las principales áreas funcionales (Soporte a usuarios, Servidores Principales, Redes y Telefonía y Desarrollo de Sistemas) de la USTI, para garantizar la aplicación de las medidas de seguridad necesarias sobre las TICS. La vigilancia y aplicación de las directrices relacionadas con la seguridad informática es responsabilidad de cada encargado de los servicios. Así, por ejemplo, las directrices relacionadas con la seguridad de la base de datos le corresponden en su aplicación, al encargado de esta área. En el caso de directrices que atañen a las estaciones de trabajo, deben ser definidas por la USTI y aplicadas por los usuarios.

C2. Auditorias respecto a la seguridad. 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.


Este proceso de verificación debe contemplar: • Análisis de vulnerabilidades sobre los servidores o recursos que se determinen pertinentes por la USTI. (Recursos críticos). • Pruebas de penetración sobre estos equipos. • Evaluación de la política de seguridad institucional. La revisión independiente debe rendir un informe con el detalle de los resultados de las pruebas efectuadas, de la

evaluación de la política de seguridad, y las

recomendaciones para mejorar los puntos críticos detectados como parte del estudio.

D. Gestión de Activos. D1. Inventario de activos. Se debe contar con los mecanismos automatizados para el registro y control de los activos institucionales. Específicamente todo lo relacionado a Tecnologías de Información y Comunicaciones debe estar registrado dentro de un sistema de información automatizado. 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.

D2. Responsabilidad de los activos. Cada activo de TI debe tener asociado un responsable de su custodia. La responsabilidad sobre los activos incluye: • La asignación de un responsable para cada activo que se adquiera.


• La reasignación de un responsable cuando el activo cambia de ubicación. • La reasignación de un responsable cuando el activo es devuelto o desechado. El sistema de control de activos debe mantener la asignación de los responsables de los activos intangibles tales como sistemas, programas o información.

D3. Uso aceptable de los activos. La USTI debe mantener directrices generales actualizadas para el uso adecuado de los activos de TIC. Estas directrices deben estar aprobadas por las autoridades superiores de la CGR y comunicados a todos los funcionarios. Debe contarse con los procedimientos correspondientes para poner en aplicación las directrices establecidas. Estos procedimientos igualmente deben estar aprobados por la USTI y comunicados por las vías que se establezcan a nivel institucional, a todos los funcionarios.

E. Compromiso del personal con la seguridad. Este capítulo corresponde al cumplimiento del punto 1.4.2 de la Normativa de la CGR.

E1. Información a los usuarios. 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. Se deben establecer los esquemas necesarios para garantizar la aceptación, entendimiento y aplicación adecuada por parte de los funcionarios respecto a las directrices existentes dentro de la institución para el uso adecuado de las TIC.

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.

1


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: • Información sobre las directrices existentes en el uso de las TIC, debidamente aprobados por las autoridades superiores de la institución. • Información respecto a los procedimientos específicos del uso adecuado de las tecnologías. • Mensajes informativos de sensibilización en el uso adecuado de las TIC. • Charlas periódicas relativas a la seguridad y utilización de las TIC.

E2. Seguimiento. El CSO debe definir los mecanismos de revisión respecto a la aplicación de las directrices institucionales para la utilización de las TIC. Las Unidades a las que le corresponda dentro de la Contraloría, deben definir claramente el esquema de sanciones que deben aplicar a nivel institucional por el incumplimiento de las directrices. Ese esquema de sanciones debe ser aprobado por las autoridades superiores de la Institución y publicarse oficialmente por los medios que corresponda.

F. Seguridad Física y del Entorno. Este capítulo corresponde al cumplimiento del punto 1.4.3 de la Normativa de la CGR.

F1. Perímetros de Seguridad Física. 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.


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.


F2. Consideraciones de control de acceso físico. 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.


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: • Existencia de un responsable del activo debidamente establecido. • Lineamientos existentes sobre el uso de los activos. • Protección mediante unidades ininterrumpidas de poder. • Ubicación adecuada del activo dentro de zonas comunes con acceso controlado. • Identificación de activos mediante identificadores electrónicos.

F3. Controles de acceso a áreas restringidas. 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: • Cámaras de video, con capacidad de grabación y almacenamiento de los videos de al menos una semana de antigüedad. Deben tener conectividad a un centro de monitoreo en donde se pueda estar vigilando la actividad sobre los recintos protegidos. • Personal disponible para vigilar el video.


• Acceso mediante tarjeta magnética a los recintos protegidos. Deben existir los roles correspondientes dentro del sistema de acceso para el control de autorización a los recintos. • Registro de bitácoras electrónicas respecto a los accesos realizados por funcionarios en las zonas protegidas. • Identificación de personal autorizado para el acceso a las zonas protegidas. Asignación de roles y permisos dependiendo de los niveles de autorización de acceso del personal. • Bitácora de control de accesos a las zonas restringidas. • Sistemas de detección y control de fuego, humo y humedad. • Sistemas de aire acondicionado • Ubicación adecuada de equipos dentro de los perímetros de seguridad, para facilitar las actividades de mantenimiento. • Procedimientos claramente establecidos respecto al ingreso, uso y mantenimiento de los equipos ubicados dentro de las áreas de seguridad. • Ubicación física segura de dispositivos de almacenamiento secundario donde se almacenen respaldos de información sensible. Control adecuado mediante bitácoras de la manipulación de esta información. • Sistemas adecuados de seguridad en las conexiones eléctricas. (Tierra en los tomas eléctricos). • Sistemas de suministro ininterrumpido de poder para los equipos ubicados dentro de los perímetros de seguridad. • Distribución de la alimentación eléctrica independiente para los equipos que cuenten con fuentes de poder redundantes. •

Registro de ingreso y salida de equipos a las áreas restringidas. Control sobre equipos en prueba mediante bitácoras.

• Deben existir diagramas de las conexiones de red de los equipos ubicados dentro de las áreas restringidas que muestre claramente adonde se está conectando cada uno de los equipos ubicados en las áreas restringidas. (Conexión equipo a switch, switch a switch, conexiones externas a switches,


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: • Jefe de la Unidad de Sistemas • Encargado del Centro de cómputo • Encargado del área de redes • Deben existir diagramas de las instalaciones eléctricas, con fin de determinar la relación entre equipo y fuente de alimentación eléctrica correspondiente.

F4. Mantenimiento de los equipos. 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: • Tipo de mantenimiento contratado. • Equipos de respaldo (stand by) que puedan ser utilizados en caso necesario. • Nombres, teléfonos y correos electrónicos de contactos técnicos (internos y externos) para aplicar en caso de ser necesario. • Periodicidad del mantenimiento preventivo (si lo tuviera). • Condiciones del mantenimiento correctivo (horarios, costos adicionales, horas mensuales). Los responsables de cada uno de estos activos; en coordinación con la jefatura de la USTI, deben definir las condiciones en que se deben realizar las acciones de mantenimiento preventivo a los mismos, garantizando: • Minimización del tiempo fuera de servicio del recurso. • Programación de los servicios de mantenimiento en horas no laborables. • Esquemas de planificación de los servicios de mantenimiento por anticipado.


• Sistemas para informar a los usuarios respecto a los servicios de mantenimiento programados. • Mapeo entre recursos y servicios, con el fin de determinar la relación entre el mantenimiento de un recurso y los servicios que se vean afectados. • Verificación previa de esquemas de respaldo y recuperación en caso de falla al retornar el servicio a producción. • Disponibilidad del personal técnico asociado al recurso para apoyar las labores de mantenimiento.

F5. Seguridad de equipos fuera de las instalaciones principales de la CGR. 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 forma en que serán registrados dentro de las bitácoras de la USTI, los equipos que salen de la institución. • Consideraciones técnicas a aplicar para los equipos que estarían saliendo de las instalaciones de la CGR. • Programas necesarios que debe tener el equipo que está saliendo de la institución. • Forma de actualización de los programas (Ejemplo: antivirus) para los equipos que se encuentren fuera de la Institución. • Esquema de soporte técnico para dar apoyo a los funcionarios que estén ubicados fuera de la institución.

F6. Seguridad en la reutilización de equipos. Con el propósito de garantizar la privacidad de la información contenida dentro de los equipos de los funcionarios, la USTI debe definir los procedimientos para los casos de reubicación de responsables de un equipo. Se debe garantizar:


• La eliminación de información sensible contenida en las unidades de almacenamiento asociadas al equipo. • La eliminación de programas que no sean necesarios. • La eliminación de configuraciones particulares que no se vayan a utilizar más.

F7. Seguridad en equipos que ingresan a la Institución. 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. Se debe contar con un esquema físico o lógico de separación de redes garantizando que equipos externos conectados a la red institucional pasen por sistemas de control y protección distintos a los equipos internos.

G. Gestión de comunicaciones y operaciones Este capítulo corresponde al cumplimiento del punto 1.4.4 de la Normativa de la CGR.

G1. Documentación de los procedimientos de operación. Los responsables de las áreas funcionales de la USTI, deben elaborar y darle mantenimiento a los procedimientos de operación, respaldo y recuperación de los recursos TIC a su cargo. Todos estos procedimientos deberán estar almacenados y accesibles a quien se disponga por parte de la USTI.


Los procedimientos deben estar registrados electrónicamente y contar con un respaldo físico que pueda ser accedido fácilmente sin necesidad de contar con un acceso a la red de comunicación institucional.1 Trimestralmente cada responsable de recursos, deberá proceder a validar la información contenida en los procedimientos bajo su responsabilidad. Se debe llevar dentro de cada procedimiento un registro para control de cambios efectuados al mismo, contemplando la fecha de la modificación del procedimiento, el responsable de la modificación y un detalle de la modificación efectuada.

G2. Separación de ambientes de trabajo. El ambiente utilizado para el desarrollo de aplicaciones debe estar separado del ambiente de producción. Para esto se deberá considerar una separación física o virtual, garantizando la independencia de estos ambientes. Los desarrolladores de sistemas no deben tener acceso a los sistemas y datos en producción, y las pruebas que se efectúen sobre sistemas en desarrollo se deben hacer sobre una plataforma independiente a la de producción, con un ambiente totalmente controlado.

G3. Controles contra código malicioso. 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.


La CGR dispondrá continuamente de la tecnología necesaria para poder vigilar en forma centralizada, la actividad reportada por estos programas de control de software malicioso. Se debe supervisar en forma regular el comportamiento de la plataforma de TIC de la institución, para identificar y atender posibles incidentes de seguridad. 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: • Forma de reporte de una propagación de virus u otro software maliciosos. • Acciones para controlar la diseminación de estos virus. • Procedimientos para volver a la normalidad un equipo dañado. La Unidad Técnica (USTI) debe contar con mecanismos de sensibilización a los usuarios sobre los riesgos sobre la información por una mala utilización de las TICS. Se deben establecer mecanismos periódicos de información a los usuarios respecto a programas maliciosos. Esta periodicidad debe ser de al menos una vez al mes. 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


Respecto al control de código malicioso, se deben establecer los siguientes niveles de seguridad: A. En las estaciones de trabajo: 1. Antivirus instalado y debidamente actualizado. 2. Antispyware instalado y debidamente actualizado. 3. Bloqueo de puertos, mediante firewall y/o antivirus, para el control de programas maliciosos que puedan utilizar vulnerabilidades sobre estos puertos para tomar control del equipo. 4. Sistema de detección y prevención de intrusos a nivel de estaciones de trabajo, garantizando que el tráfico de información desde y hacia la estación de trabajo no sea dañino, permitiendo bloquear cualquier intento de “intrusión” al equipo por parte de conexiones externas. 5. Contar con tecnología apropiada para proveer esquemas de cifrado a la información que se considere necesaria dentro de las estaciones de trabajo. 6. Proceso automatizado de las actualizaciones de seguridad sobre aplicaciones y sistema operativo. 7. Tecnología para el manejo automatizado de respaldos de la información del directorio de trabajo de las estaciones de trabajo. 8. Procesos regulares de análisis de vulnerabilidades sobre aplicaciones y sistemas operativos. 9. Manejo de respaldos automatizados para garantizar la restauración completa de la información a un momento determinado. (ver punto G4) B. En los servidores: 1. Contar con firewall a nivel de servidores que permita lograr un nivel de seguridad adicional al brindado por el firewall corporativo. 2. Procesos regulares de análisis de vulnerabilidades sobre aplicaciones y sistemas operativos.


3. Procesos regulares para aplicación de actualizaciones de seguridad. C. En la red: 1. Contar con sistemas de detección y prevención de intrusos a nivel de red que constantemente estén monitoreando el canal y determinando y controlando posibles ataques que puedan estar ocurriendo. 2. Sistema de control sobre equipos que no cumplan con las directrices de seguridad previamente establecidas a nivel institucional. (Control de acceso al medio)

G4. Respaldo de la información 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: • Para servidores principales: -- Procedimientos de respaldo diario de la información almacenada en las bases de datos. -- Procedimiento de respaldo semanal de la información. Ubicación distante de estos respaldos. -- Procedimientos de respaldo de configuraciones. -- Registro en bitácoras de los procesos de respaldo efectuados. Se debe registrar en esta bitácora la información necesaria para poder acceder a los registros en caso de que sea necesario. • Para equipos de comunicación u otros con menor cantidad de datos almacenados. -- Procedimientos de respaldo de configuraciones.


-- Procedimientos de respaldo de datos, en los casos en que sea necesario. • Para estaciones de trabajo. -- Procedimientos de respaldo de la información de los usuarios. Se debe suplir a los usuarios con la tecnología necesaria para el respaldo de la información contenida dentro de sus equipos. 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.

G5. Seguridad de las redes de comunicación. Todos los equipos que se encuentran conectados a la red de datos institucional, deberán ser controlados mediante un sistema de seguridad, Para garantizar esquemas adecuados de seguridad, se deben considerar esquemas físicos o lógicos de separación de las redes internas de datos según el tipo de equipo que esté ubicado en cada una de esas redes. Todos los accesos específicos a equipos críticos deben estar controlados por un sistema de seguridad. 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:


• Ubicación física y lógica de equipos principales, equipos de comunicaciones y equipo de seguridad. • Ubicación física y lógica de la segmentación de redes. • Mapeo de conexiones físicas dentro del Centro de Cómputo. • Topología general de las redes considerando: -- Direcciones IP -- Sistema Operativo de los equipos -- Conexiones existentes con otros equipos. -- Redes virtuales definidas (Vlans) -- Redes privadas virtuales existentes. -- Conexiones con sitios externos, velocidades y direccionamiento IP.

G6. Seguridad en las conexiones inalámbricas. 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 mantener actualizadas y en funcionamiento las directrices específicas para el uso y administración de la red inalámbrica institucional. Se deben tener las siguientes consideraciones respecto a la seguridad de las conexiones inalámbricas: a. Todo equipo inalámbrico que se conecte a la red institucional debe estar claramente identificado por la unidad Técnica de la CGR. (USTI). b. Se deben identificar y manejar en forma separada dos tipos de conexiones inalámbricas: las que requieren acceso a las redes internas institucionales y las que solamente requieren acceso a la Internet. Para cualquiera de estos accesos se deben utilizar esquemas de autenticación, inclusive cualquier red inalámbrica catalogada como “no confiable”.


c. El acceso a la red institucional por parte de las conexiones inalámbricas debe contar con los esquemas de control que sean establecidos para las redes alambicas. d. Los equipos concentradores de conexiones inalámbricas (access point) se deben instalar considerando que el área de cobertura de los mismos se circunscriba a los límites del edificio. e. La solución inalámbrica que se utilice debe contar con mecanismos de seguridad tales como: -- Sistemas de detección de intrusos. -- Manejo de la autenticación por medio de certificados digitales. (A nivel de equipo y no de usuario). -- Manejo de esquemas de cifrado seguros para la transmisión de la información por el medio inalámbrico. f. Deben realizarse análisis periódicos de la red inalámbrica con el propósito de detectar equipos no autorizados. (Access point y/o clientes).

G7. Seguridad de la información disponible en servidores de acceso público. 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. Un usuario que se conecte externamente, no podrá acceder directamente a las Bases de Datos institucionales, sino que su acceso lo debe hacer mediante una solicitud a un servidor intermedio de la CGR, el cual se debe encontrar en la zona pública, y este servidor es el que realiza el acceso hacia las bases de datos, obtiene la información y se la entrega al usuario final.


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

G8. Vigilancia de la actividad sobre la información almacenada en las Bases de Datos Institucionales. 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). Para ello es necesario considerar: • La información que será sujeta a monitoreo. • La permanencia de los datos monitoreados. • Los esquemas de revisión de estas bitácoras (periodicidad y método de revisión). • Los responsables de la revisión de la información almacenada en las bitácoras. • Los esquemas de seguridad (roles) para las personas que harán análisis sobre las bitácoras correspondientes. Los servidores institucionales deberán estar debidamente sincronizados con un servidor de tiempo único, de tal forma que la hora de los equipos sea congruente, esto para efectos de los análisis que se deban realizar sobre la actividad registrada en los reportes correspondientes de los servidores. 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.


Puede ser el procedimiento actual, traslado a bodega con indicaciones de deshecho o donación, y la limpieza de los discos y memorias. G9. Seguridad en el registro y transferencia de información. 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. Este capítulo corresponde al cumplimiento del punto 1.4.5 de la Normativa de la CGR.

H1. Administración de usuarios. Deben establecerse los procedimientos para el registro de usuarios nuevos a los sistemas institucionales. Estos procedimientos deberán considerar: • Los responsables del registro, • Los servicios a los cuales los usuarios tendrán acceso y • Las razones del 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.


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 garantizar los esquemas de seguridad necesarios para la identidad asignada a un usuario (código usuario y password) para el acceso a los servicios asociados a él (usuario/password). Asociado a la asignación de contraseñas deben existir directrices claramente establecidas a nivel institucional para su correcto uso. Deben considerarse: • Políticas de asignación de password fuertes y difíciles de robar. • Políticas de seguridad en el mantenimiento de estos password. • Sensibilización sobre las responsabilidades en el uso adecuado de los password asignados. • Procedimientos para la renovación periódica de los password.

H2. Accesos asociados al usuario. 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 acceso (interno o externo) a un servicio que requiere identificación de usuario, debe estar controlado con esquemas de autenticación y autorización.

I. Seguridad en los sistemas de información. Este capítulo corresponde al cumplimiento del punto 1.4.6 de la Normativa de la CGR.


I1. Análisis de especificaciones y requisitos de seguridad. El proceso de desarrollo e inserción de software considerará las directrices

de

seguridad de TI, de forma tal que sus productos sean conformes con las directrices de seguridad institucionales. Debe existir una metodología en el desarrollo de sistemas de información que garantice los controles de seguridad necesarios en las aplicaciones o sistemas nuevos, así como la calidad de los mismos. Dentro de esta metodología se debe considerar: • La validez de los datos de entrada a las aplicaciones, evitando el ingreso de registros incorrectos (que pongan en riesgo aspectos de integridad de la información). • La autenticidad de la información que es registrada dentro de las bases de datos. Para esto se deben establecer los mecanismos necesarios para brindar los esquemas de seguridad en la autenticación de los usuarios a las aplicaciones o servicios. • Procedimientos definidos para los procesos de prueba de los sistemas o soluciones que se vayan a poner en producción. Se deben definir, basado en los niveles de criticidad de la información, los esquemas de privacidad requeridos para los datos. En este sentido se debe considerar la implementación de mecanismos de cifrado (utilizando la tecnología que se considere oportuna) tanto en los procesos de transmisión de la información por la red, como de almacenamiento de datos, todo esto con el objetivo de garantizar la seguridad de la información.


I2. Implementación y actualización de soluciones tecnológicas. Cualquier cambio realizado sobre la infraestructura tecnológica deberá someterse a un procedimiento de aprobación previo y a una validación integral de las implicaciones del cambio ante el entorno. Todo cambio realizado debe quedar registrado basado en un sistema de control de cambios.

I3. Autorización de nuevos servicios en TIC. Cualquier requerimiento en TIC debe ser canalizado por las unidades solicitantes a la USTI utilizando un esquema jerárquico: 1. La unidad solicitará a la USTI el nuevo servicio que requiere. Esta solicitud se debe hacer mediante nota dirigida al Jefe de la USTI. 2. El jefe de la USTI evaluará preliminarmente la solicitud y determinará si es viable de realizar. En caso de que sea viable lo someterá a consideración de la Comisión Ad Hoc coordinada por la Subcontralora, para que ahí se decida su elevación al CGTIC de donde se emitirá la recomendación de aprobación o no de la solución tecnológica que será comunicada a la Unidad Solicitante. 3. Se excluyen del punto anterior soluciones que no impliquen mayores recursos y que no requieran de un líder de proyecto asignado por el Patrocinador.

I4. Acuerdos sobre confidencialidad. Se deben definir los criterios de privacidad respecto a la información institucional. En este sentido es necesario establecer como parte del modelo de arquitectura de información la identificación de los datos, su nivel de criticidad y su nivel de privacidad.


Con base en el modelo se deben establecer por parte de la unidad de Recursos Humanos los acuerdos de confidencialidad y de no-divulgación respecto a la utilización de la información considerada como crítica. Se deben contemplar los procedimientos para evaluar la vigencia de los acuerdos y posibles cambios que deban considerarse en caso necesario.

J. Gestión de incidentes de la seguridad de la información. J1. Manejo de los incidentes: 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 eventos de seguridad deben clasificarse según su nivel de criticidad y el manejo que se le dé deberá estar soportado por un sistema de información que permita apoyar el tratamiento del evento, permitiendo registrar la información relativa al mismo. Se deben tener definidos los procedimientos adecuados para la atención de los incidentes de seguridad, los cuales deben considerar: • La forma en que se debe atender el incidente. • El grupo de trabajo responsable de la atención del incidente. • El acceso a información de localización de las personas responsables del área técnica par atender el incidente. (internas y externas) • El uso de las bitácoras de información primaria para investigar. • La documentación que se debe generar del incidente.


K. Continuidad del negocio. Este capítulo corresponde al cumplimiento del punto 1.4.7 de la Normativa de la CGR.

K1. Manejo de la continuidad del negocio. El manejo de cualquier incidente relacionado con la continuidad de los servicios brindados por la CGR se debe tratar como una contingencia y debe ser canalizado según procedimientos claramente establecidos y accesibles por las personas responsables de la operación de los mismos. 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.


ANEXO 1 El rol del CISO: Chief Information Security Officer Tomado de Internet. En la actualidad las empresas producen un 60% más de información por año y el número de ataques a la misma se incrementa a pasos agigantados, sin embargo en muchos casos se sigue sin implementar políticas acorde a este crecimiento. Sin dudas, la información que genera una empresa es uno de los activos más importantes que esta posee. Tener control de las actividades que comprenden uso y generación de información requiere de políticas bien definidas en virtud de garantizar disponibilidad, integridad y confiabilidad de la misma así como contar con una persona que pueda llevar a cabo la planificación de las actividades necesarias para lograr estos objetivos. De acuerdo a la “Encuesta Global 2007 de Seguridad & Privacidad” de la consultora Deloitte, el 80 % de los ataques que una organización recibe procede de errores humanos. Al ranking de las brechas de seguridad lo lideran los ataques vía e-mail con un 52%. Luego más abajo se encuentra las actividades víricas, un 40%, las actividades de phishing con un 35%, la mala conducta de los empleados con un 31%, el spyware con 26% y la ingeniería social (17%). Es importante destacar que el informe menciona que la efectividad de los ataques internos producidos por los propios empleados es de un 39%. 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


una persona encargada de velar por el cumplimiento de los objetivos de la organización y que este rol tiene que estar en directa comunicación con el Directorio para poder realizar estas tareas. Este rol que cumple el CISO tiene su actividad principal orientada a garantizar que la información de la organización sea fidedigna y accesible por los miembros de la empresa que tengan que acceder a ella en base a sus objetivos. Para ello, tiene que contar con la posibilidad de implementar las medidas de control que crea conveniente así como coordinar actividades centrado en su misión. Se pueden detallar las siguientes actividades que estarán bajo el control del CISO de acuerdo a un revelamiento llevado a cabo entre las personas que están ocupando dichos cargos en latinoamérica durante el 1er CISO’s Meeting 2005 y que están ordenadas por orden de criticidad. 1. concientización de usuarios internos y externos 2. análisis de riesgos de negocio y tecnológicos 3. business continuity plan 4. administración de seguridad 5. control proactivo 6. monitoreo y reporting 7. análisis de normativas y regulaciones 8. definición de normativas internas 9. seguridad física de centros de cómputos 10. análisis de contingencias legales, forensics 11. capacitación / actualización permanente 12. gestión de mejoras en procesos 13. aplicación de tecnología para cumplir esquema disciplinario propuesto por rr.hh. 14. administración del área 15. análisis de riesgos en nuevas tecnologías 16. integración con gestión de ti


17. interacción con gerentes y usuarios diariamente 18. justificación del presupuesto 19. soporte a terceros 20. Durante mucho tiempo muchas de estas actividades estaban controladas principalmente por el área de sistemas (en el mejor de los casos), contando, en ocasiones, con personal que tuviera conocimientos de seguridad informática. 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


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.


Anexo - NTP11

Mapeo Eléctrico



Introducción En coordinación con la Unidad de Servicios Generales se llevaron a cabo una serie de actividades relaciones con energía eléctrica, según se identifican en el siguiente apartado, con el objetivo de aprovechar el conocimiento y la experiencia de su personal para documentar los sistemas eléctricos, sensores y alarmas relacionados con la gestión de tecnologías de información; tomando como referencia la siguiente normativa, como práctica líder: • Las Normas técnicas para la gestión y el control de las Tecnologías de Información (N-2-2007-CO-DFOE). Mediante este documento se cumple con parte de la normativa de la CGR, específicamente en lo que corresponde al punto 1.4, en los aspectos citados en el siguiente apartado.

Requerimientos Mapeo de conexiones eléctricas Documentación clara de cada una de las conexiones eléctricas que se encuentran dentro del Centro de Cómputo, etiquetando tableros y los cables e identificándoles con las fuentes de alimentación eléctrica correspondientes; así como de un “mapeo” de cada conexión y su correspondiente fuente eléctrica, con el propósito de conocer con exactitud a qué está conectado cada uno de los equipos de tecnología ubicados en el área de servidores del piso 10.

Distribución de cargas por unidades de poder (UPS) 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


un equipo estén conectados a una misma UPS, y para evitar que una UPS esté sobrecargada con respecto a otra.

Procedimientos para resolver problemas eléctricos Como parte del plan de contingencias en Tecnologías de Información y Comunicaciones, debemos tener documentados los procedimientos que se deben seguir para atender de la mejor forma cualquier problema eléctrico. Estos tienen que incluir los responsables de su ejecución, y las personas alternativas ante la ausencia del responsable principal, sus números de teléfono o medios de localización, para incluirlos en un manual de escalamiento.

Procedimientos de mantenimiento preventivo para el aire acondicionado También, se tienen que incluir en el plan de contingencias los procedimientos documentados respecto al plan de mantenimiento preventivo y correctivo relacionado con los aires acondicionados del Centro de Cómputo.

Lámparas de emergencia ante problemas eléctricos Se requiere contar con lámparas de emergencia que se activen automáticamente dentro del Centro de Cómputo cuando falle la corriente eléctrica, para que los encargados de tecnologías puedan desplazarse en forma segura en estas circunstancias. .

Aseguramiento de los cuartos de comunicaciones

Según el esquema de “niveles de seguridad” establecidos, los cuartos de comunicaciones ubicados en los distintos pisos tanto del edificio principal como del anexo tienen que estar asegurados e integrados al sistema de UPS. 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,


considerando el control de los mismos por parte de los funcionarios responsables de los equipos.

Control de acceso El control de acceso al piso 10 y a los cuartos de comunicación tiene que estar documentado, incluyendo los mecanismos en uso y los contactos en caso de fallas.

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 Documentar los parámetros de activación de las alarmas por incendio, de sensores, temperatura y otros en uso.

Actividades realizadas En coordinación con la Unidad de Gestión Administrativa se realizaron y calendarizarán las actividades comentadas a continuación.

1. Mapeo de conexiones eléctricas 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.


Acciones correctivas 1. Cambio de posición de dos interruptores que alimentan un equipo 220 voltios 2. Plazo de ejecución: 15 de junio 2009 3. Reacomodo de la caja de interruptores A y B según figura 2. 4. Plazo de ejecución: 15 de junio 2009 5. Etiquetar algunas salidas de toma corrientes con su respectivo interruptor 6. Plazo de ejecución: 15 de junio 2009


唀戀椀挀愀挀椀渀搀攀猀愀氀椀搀愀猀攀氀挀琀爀椀挀愀猀䌀甀愀爀琀漀䌀 洀瀀甀琀漀倀椀猀漀㄀　䘀攀挀栀愀㨀　㔀 ⴀ㈀　　㤀吀愀戀氀攀爀漀㄀　ⴀ䄀㌀ꘃ

吀愀戀氀攀爀漀㄀　ⴀ䈀㈀ꘃ

㄀　ⴀ䄀 ⴀ㄀

㄀　ⴀ䄀 ⴀ㄀㈀

㄀　ⴀ䈀 ⴀ㄀

㄀　ⴀ䈀 ⴀ㤀

㄀　ⴀ䄀 ⴀ㈀

㄀　ⴀ䄀 ⴀ㄀㌀

㄀　ⴀ䈀 ⴀ㈀

㄀　ⴀ䈀 ⴀ㄀　

㄀　ⴀ䄀 ⴀ㌀

㄀　ⴀ䄀 ⴀ㄀㐀

㄀　ⴀ䈀 ⴀ㌀

㄀　ⴀ䈀 ⴀ㄀㄀

㄀　ⴀ䄀 ⴀ㐀

㄀　ⴀ䄀 ⴀ㄀㔀

㄀　ⴀ䈀 ⴀ㐀

㄀　ⴀ䈀 ⴀ㄀㈀

㄀　ⴀ䄀 ⴀ㔀

㄀　ⴀ䄀 ⴀ㄀㘀

㄀　ⴀ䄀 ⴀ㘀

㄀　ⴀ䄀 ⴀ㄀㜀

㄀　ⴀ䈀 ⴀ㔀㄀　ⴀ䈀 ⴀ㄀㌀㄀　ⴀ䈀 ⴀ㄀㄀　ⴀ䈀 ⴀ㘀㄀　ⴀ䈀 ⴀ㄀㐀

㄀　ⴀ䄀 ⴀ㜀

㄀　ⴀ䄀 ⴀ㄀㠀

㄀　ⴀ䈀 ⴀ㜀

㄀　ⴀ䈀 ⴀ㄀㔀

㄀　ⴀ䄀 ⴀ㠀

㄀　ⴀ䄀 ⴀ㄀㤀

㄀　ⴀ䈀 ⴀ㠀

㄀　ⴀ䈀 ⴀ㄀㘀

㄀　ⴀ䄀 ⴀ㤀

㄀　ⴀ䄀 ⴀ㈀　

㄀　ⴀ䈀 ⴀ㤀

㄀　ⴀ 䄀ⴀ㄀　

㄀　ⴀ䄀 ⴀ㈀㄀

㄀　ⴀ䈀 ⴀ㄀　

㄀　ⴀ 䄀ⴀ㄀㄀

㄀　ⴀ䄀 ⴀ㈀㈀

㄀　ⴀ䄀ⴀ㄀㜀㄀　ⴀ䄀ⴀ㄀㈀㄀　ⴀ䄀ⴀ㐀㄀　ⴀ䄀 ⴀ㄀㌀

㄀　ⴀ䈀ⴀ㜀

㄀　ⴀ䈀 ⴀ㘀

㄀　ⴀ䈀ⴀ㠀

㄀　ⴀ䈀ⴀ㄀㄀

㄀　ⴀ䄀ⴀ㄀㘀

㄀　ⴀ䈀ⴀ㄀㈀

㄀　ⴀ䈀ⴀ㔀

㄀　ⴀ䄀ⴀ㄀㌀

㄀　ⴀ䈀 ⴀ㄀㘀

㄀　ⴀ䈀ⴀ㄀㘀

㄀　ⴀ䈀 ⴀ㔀

㄀　ⴀ䄀ⴀ㈀㄀　ⴀ䈀ⴀ㈀

㄀　ⴀ䄀 ⴀ㄀㄀　ⴀ䈀 ⴀ㄀

㄀　ⴀ䄀 ⴀ㔀㄀　ⴀ䈀 ⴀ㤀

㄀　ⴀ䈀ⴀ㐀

㄀　ⴀ䄀ⴀ㄀　㄀　ⴀ䈀ⴀ㌀

㄀　ⴀ䈀ⴀ㐀

Distribución de salidas de c 1 Figura No.1 Distribución de salidas de corriente según interruptor correspondiente


吀愀戀氀攀爀漀㄀　ⴀ䄀㌀ꘃ

吀愀戀氀攀爀漀㄀　ⴀ䈀㈀ꘃ

䘀愀猀攀䄀㴀㈀　愀洀瀀䘀愀猀攀䈀㴀㈀　愀洀瀀䘀愀猀攀䌀㴀㈀㌀愀洀瀀

䘀愀猀攀䄀㴀㈀㤀⸀㘀愀洀瀀䘀愀猀攀䈀㴀㈀㜀⸀㌀愀洀瀀

㄀　ⴀ䄀 ⴀ㄀䘀愀猀攀䄀㌀Ⰰ㜀愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㈀䘀愀猀攀䄀　⸀㌀愀洀瀀

㄀　ⴀ䄀 ⴀ㈀䘀愀猀攀䈀㌀⸀㘀愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㌀䘀愀猀攀䈀

㄀　ⴀ䄀 ⴀ㌀䘀愀猀攀䌀㔀⸀　愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㐀䘀愀猀攀䌀

㄀　ⴀ䄀 ⴀ㐀䘀愀猀攀䄀　愀洀瀀

㄀⸀　愀洀瀀

㜀⸀　愀洀瀀㄀　ⴀ䄀 ⴀ㄀㔀䘀愀猀攀䄀㜀⸀　愀洀瀀

㄀　ⴀ䄀 ⴀ㔀䘀愀猀攀䈀　愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㘀䘀愀猀攀䈀

㄀　ⴀ䄀 ⴀ㘀䘀愀猀攀䌀 ጠ 䘀愀猀攀䄀㈀⸀㈀愀洀瀀 ጠ ㈀⸀㐀愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㜀䘀愀猀攀䌀

㄀　ⴀ䄀 ⴀ㜀䘀愀猀攀䈀㘀⸀　愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㠀䘀愀猀攀䄀

㄀　ⴀ䄀 ⴀ㠀䘀愀猀攀䌀　愀洀瀀

㄀　ⴀ䄀 ⴀ㄀㤀䘀愀猀攀䈀

㄀　ⴀ䄀 ⴀ㤀䘀愀猀攀䄀㐀⸀　愀洀瀀㄀　ⴀ䄀 ⴀ㄀　䘀愀猀攀䈀䰀䤀䈀刀䔀㄀　ⴀ䄀 ⴀ㄀㄀䘀愀猀攀䌀　⸀㔀愀洀瀀

　⸀㤀愀洀瀀

　愀洀瀀

㈀⸀㄀愀洀瀀

㐀⸀㜀愀洀瀀㄀　ⴀ䄀 ⴀ㈀　䘀愀猀攀䌀㈀⸀㠀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀䘀愀猀攀䄀㌀⸀㤀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㄀䘀愀猀攀䈀 ጠ 䘀愀猀攀䄀㌀⸀㔀愀洀瀀 ጠ ㌀⸀㠀愀洀瀀

㄀　ⴀ䈀 ⴀ㈀䘀愀猀攀䈀㐀⸀㌀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㈀䘀愀猀攀䈀

㄀　ⴀ䈀 ⴀ㌀䘀愀猀攀䄀　⸀㌀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㌀䘀愀猀攀䄀

㄀　ⴀ䈀 ⴀ㐀䘀愀猀攀䈀㈀⸀㌀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㐀䘀愀猀攀䈀

㌀⸀㜀愀洀瀀

㈀⸀㔀愀洀瀀

㘀⸀　愀洀瀀

㄀　ⴀ䈀 ⴀ㔀䘀愀猀攀䄀㔀⸀㐀愀洀瀀㄀　ⴀ䈀 ⴀ㘀䘀愀猀攀䈀㐀⸀㐀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㔀䘀愀猀攀䄀 ጠ 䘀愀猀攀䈀㈀⸀㐀愀洀瀀 ጠ ㄀⸀㘀愀洀瀀㄀　ⴀ䈀 ⴀ㄀

㄀　ⴀ䈀 ⴀ㄀㘀䘀愀猀攀䄀　⸀㐀愀洀瀀

㄀　ⴀ䈀 ⴀ㜀䘀愀猀攀䄀㈀⸀㘀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㜀

㄀　ⴀ䈀 ⴀ㠀䘀愀猀攀䈀㐀⸀㈀愀洀瀀

㄀　ⴀ䈀 ⴀ㄀㠀

㄀　ⴀ䈀 ⴀ㤀䘀愀猀攀䄀　⸀㐀愀洀瀀

㄀　ⴀ䄀 ⴀ㈀㄀䘀愀猀攀䄀

㄀　ⴀ䈀 ⴀ㄀　䘀愀猀攀䈀 ጠ 䘀愀猀攀䄀

　愀洀瀀

㌀⸀㌀愀洀瀀 ጠ ㌀⸀㜀愀洀瀀

㄀　ⴀ䄀 ⴀ㈀㈀䘀愀猀攀䈀 ጠ 䘀愀猀攀䌀㔀⸀㄀愀洀瀀 ጠ 㔀⸀㔀愀洀瀀

Figura No.2 Ubicación de los interruptores que alimentan las cargas de centro de cómputo


1. Procedimiento para resolver problemas eléctricos Se definió un esquema de detección y corrección de fallas eléctricas en los sistemas de cómputo para determinar el procedimiento a seguir en caso de ocurrencia de cada una de las fallas principales. En la figura No.3 se muestra el esquema.

Figura No.3 Esquema de ocurrencia de fallas eléctricas y su respectivo plan de acción


Procedimiento de mantenimiento preventivo para el aire acondicionado Plan de mantenimiento preventivo Para los sistemas de aire acondicionado se realizan revisiones semanales y trimestrales, las primeras son realizadas por el personal de la CGR y las semanales son realizadas por una empresa subcontratada. Las revisiones semanales incluyen lo siguiente: VERIFICAR EL CORRECTO FUNCIONAMIENTO DE LAS UNIDADES DE AIRE ACONDICIONADO DE USTI ANOTAR TEMPERATURA DEL CUARTO DE CÓMPUTO (DIARIA) MEDIR AMPERAJES DE COMPRESORES DE LOS DOS EQUIPOS PRINCIPALES

Mantenimiento correctivo Hay un procedimiento de mantenimiento correctivo en caso de falla de los equipos: Este proceso da inicio cuando se detecta una falla o el no funcionamiento de un equipo de aire acondicionado en la institución. Las formas de detectar una falla en el sistema de airea condicionado son: a) La alarma ubicada en el puesto de ascensores de seguridad se activa. B) Cualquier reporte de los funcionarios que laboran en la Unidad de Servicios de Tecnologías e Información. 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.


Si es un aire acondicionado ubicado en el piso 10, se da alta prioridad al requerimiento, por encontrarse la Unidad de Sistemas y Tecnología de Información en este piso y por ende, los servidores de la institución. Si la alarma se diera en horario de oficinas el personal de seguridad procede a llamar al centro de cómputo a la extensión 8134 para comunicarse con la persona que se encuentre en el sitio. Si no contestara nadie, entonces llamar a USG o Mantenimiento. Si la alarma se diera fuera de horario de oficinas, debe desplazarse al décimo piso y revisar cual es la temperatura del sensor ubicado en el cielo raso. Esta temperatura debe estar entre 22ºC y 24ºC como máximo. Se debe anotar en bitácoras la temperatura a la que se encontró el sensor. Si la temperatura es superior a los 25ºC, revisar la unidad de aire acondicionado principal está encendido. Esta debe de marcar la temperatura en la pantalla que se ubica propiamente en la unidad. Si esta encendido entonces apagar con el control esperar 15 segundos y volver a encender y esperar que la temperatura se ajuste al valor permitido. Si la unidad esta apagada apagar y encender como el en caso anterior. Si no enciende la unidad se debe de se debe encender con el control la unidad de respaldo, (unidad grande) y esperar que la temperatura se ajuste al valor permitido. Verificar que la unidad este encendida. Esta debe de marcar la temperatura en la pantalla que se ubica propiamente en la unidad. Si esta unidad no enciende entonces reportar a Mantenimiento inmediatamente y abrir ventilas, puertas y colocar abanicos. Si la temperatura no llega a su valor permitido en 15 minutos, se debe de se debe encender con el control la unidad de respaldo, (unidad grande) y esperar que la temperatura se ajuste al valor permitido. Verificar que la unidad este encendida. Esta debe de marcar la temperatura en la pantalla que se ubica propiamente en la unidad.


Si esta unidad no enciende entonces reportar a Mantenimiento inmediatamente y abrir ventilas, puertas y colocar abanicos. Lámparas de emergencia ante problemas eléctricos Estas se estarán instalando en la siguiente fecha: Plazo de ejecución: 22 de junio 2009

Aseguramiento de los cuartos de telecomunicaciones En estos momentos solamente 4 cuartos de telecomunicaciones que no se encuentran totalmente cerrados, por los que se van a cerrar. Para esto se requiere colocar paneles de madera y una puerta con llave para su aseguramiento. Plazo de ejecución: 30 de julio 2009

Sistema de extinción y alarmas En estos momentos se cuenta con un sistema de detección de incendio activo. El sistema de supresión se encuentra instalado pero inactivo ya que falta la capacitación del personal para su activación. Esta capacitación se tiene programada para la semana del 01 al 05 de junio del 2009. Los procedimientos en caso de activación de los sistemas se tendrán para esa misma fecha.

Anexo - NTP12

Plan Continuo de Capacitación en TI



Estudio para la elaboración del plan de educación continua en tecnologías de información y comunicación Introducción El presente trabajo denominado “Estudio para La Elaboración del Plan De Educación Continua En Tecnologías De Información Y Comunicación” es un producto intermedio del Proyecto “Educación Continua en Tecnologías de Información Y Comunicación (TIC’s)” que a su vez forma parte de las iniciativas del Plan Estratégico de Tecnologías de Información y Comunicación (PETIC) Para ubicar el estudio en el contexto que le dio creación, a continuación se citan los resultados esperados del Proyecto de Educación Continua en Tecnologías de Información Y Comunicación (TIC’s): • Personal capacitado y actualizado en el uso de las TIC’s para la gestión de los procesos institucionales • Personal capacitado y actualizado para la gestión de TIC’s Este Proyecto espera llegar a desarrollar un recurso humano entusiasta y dispuesto a aprovechar las tecnologías de información y comunicación que la CGR le facilita para la ejecución de su trabajo y por ello su objetivo principal es incrementar la capacidad de todo el personal de la Contraloría General de la República en el tema de TIC’s.. Bajo ese enfoque el presente estudio pretende realizar un diagnóstico de necesidades de capacitación en materia de TIC’s, que brinde los insumos suficientes para la elaboración del Plan de capacitación continua que permita alcanzar los resultados del proyecto.


Mediante la aplicación de este Plan se espera disminuir sensiblemente la brecha existente en las habilidades y destrezas requeridas para el mejor uso de las TIC’s, así como mantener la competencia técnica del personal dicha materia.

METODOLOGIA APLICADA EN EL ESTUDIO 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. Luego de la aplicación de los instrumentos, se procedió a la tabulación de la información recolectada, estandarizando las respuestas y manteniendo una clasificación temática que permitiera una adecuada comprensión de los datos y una presentación de información relevante para seleccionar los temas que deben formar parte del Plan de Capacitación Continua en TIC’s.

Instrumentos aplicados A continuación se describen los principales instrumentos que se desarrollaron, aplicaron y tabularon en el presente estudio:

Consulta sobre los Conocimientos, Destrezas y Habilidades en materia de TIC’s Se realizó una consulta a diferentes Unidades de la Contraloría General de la República sobre los principales conocimientos, destrezas y habilidades que deben tener los diferentes funcionarios que laboraran en la Institución en materia de TIC’s.


A partir de dicha información se elaboraron y aplicaron diferentes instrumentos para obtener la información necesaria para realizar un diagnóstico de la situación actual de los funcionarios en cuanto a dichos temas.

Encuesta aplicada en la División De Fiscalización Operativa Y Evaluativa (DFOE) Se aplicó una encuesta en la DFOE, 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 requeridas en materia de TIC’s, que son de tipo general. (Ver anexo 1). Se obtuvo información sobre necesidades de capacitación en TIC`s aplicables a cualquier tipo de Fiscalización, así como para la Fiscalización de la Gestión y Control de las TIC’s, esto principalmente por medio del Macroproyecto de Tecnologías de Información y Comunicación (Ver anexo 2). En este momento se encuentran asignados 21 funcionarios a dicho Macroproyecto, los cuales deben tener especial atención en la planificación de la capacitación relacionada con TIC’s (Ver anexo 3) Parte de la encuesta consultó sobre las competencias de los funcionarios, donde se incluyeron algunas relacionadas con la utilización de TIC’s en las labores que les corresponde ejecutar. (Ver anexo 4)

Encuesta aplicada en las Divisiones de Desarrollo Institucional (DDI), Estrategia Institucional (DEI), Asesoría y Gestión Jurídica (DAGJ) y en Contratación Administrativa (DCA) 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).


Parte de la encuesta consultó sobre las competencias de los funcionarios, donde se incluyeron algunas relacionadas con la utilización de TIC’s en las labores que les corresponde ejecutar. (Ver anexo 6)

Encuesta aplicada en la Unidad de Tecnologías de Información y Comunicación (USTI) 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. La encuesta se aplicó a todos los funcionarios de la USTI, de los cuales se obtuvo la información necesaria para determinar sus necesidades de capacitación en materia de TIC’s (Ver anexo 7). Parte de la encuesta consultó sobre las competencias de los funcionarios, donde se incluyeron algunas relacionadas con la utilización de TIC’s en las labores que les corresponde ejecutar. (Ver anexo 8)

Entrevista para determinación de necesidades de capacitación en materia de TIC’s para los niveles de Jefatura de esta Contraloría General. 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).


Entrevista para determinación de necesidades de capacitación en materia de TIC’s para el nivel secretarial de esta Contraloría General. Se procedió a entrevistar a un selecto grupo de secretarias que por su nivel y experiencia, como lo son las secretarias del Despacho, la Secretaria de División de la DFOE, de la Secretaría Técnica y de la USTI, las cuales poseen el expertiz necesario para realizar aportes significativos en relación con las necesidades de sus colegas en materia de TIC’s (Ver anexo 10)

ENTREVISTA-TALLER PARA DETERMINACIÓN DE NECESIDADES DE CAPACITACIÓN EN MATERIA DE SISTEMAS DE INFORMACIÓN DE LA CONTRALORÍA GENERAL DE LA REPÚBLICA Para obtener información sobre las principales necesidades de los funcionarios en materia de conocimiento y uso de los sistemas de información existentes en la Institución, se realizó una entrevista y a la vez un taller de trabajo con el coordinador de desarrollo de sistemas de la USTI, quien desde su posición de experto en la materia, nos dio sus valiosas opiniones sobre lo consultado y conjuntamente con el entrevistador, se realizó un trabajo de definición de requerimientos de aprendizaje en esa materia (Ver anexo 11). Al respecto, se determinaron los sistemas y las unidades que requieren capacitación tanto para efectos de registro como para efecto de consulta.

Coordinación con el Proyecto de Maletín Electrónico Se realizaron reuniones de coordinación con los integrantes del proyecto de Maletín Electrónico, para revisar los alcances de ambos proyectos y preveer que dichos esfuerzos no se dupliquen, sino que por el contrario, se complementen. Cabe señalar que un funcionario de la Unidad de Recursos Humanos, encargado de la planificación de la Capacitación, está integrando actualmente ambos proyectos.


Análisis de la Información recolectada Se realizó un análisis de la información recolectada mediante los instrumentos descritos anteriormente, la cual consistió en comparar los conocimientos que requieren los puestos en esta Contraloría General de la República, con los conocimientos que los funcionarios perciben tener. De este análisis se obtuvieron aquellos temas en que mayormente se requiere aplicar actividades de aprendizaje para llevar a los funcionarios al perfil requerido. 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. En cuanto a la consulta sobre la aplicación de las competencias relacionadas con TI, se consultó sobre tres comportamientos, uno correspondiente a la competencia Liderazgo y dos sobre la competencia Innovación. Sobre la competencia Liderazgo, se consultó sobre el comportamiento “Toma decisiones acertadas y consistentes apoyado en las TIC’s”, y al respecto un 69% acumula a los funcionarios que opinan que no aplican ese comportamiento o que lo aplican en un nivel bajo y a un nivel medio. (Ver anexo 12)


Sobre la competencia Innovación, se consultó sobre dos comportamientos, “Asimila e incorpora fácilmente la aplicación de nuevas TIC’s en los trabajos” y “Actualiza sus conocimientos en temas de interés para la Institución y en el uso de TIC’s”, a los cual respondieron, en el primer caso un 56% y en el segundo 62% de los funcionarios, que no lo aplican, lo aplican a un nivel bajo y a nivel medio. (Ver anexo 12) 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. Como se mencionó anteriormente, en el presente estudio también se investigó y coordinó con el proyecto de Maletín Electrónico, el cual inició como un esfuerzo por dotar de herramientas y conocimientos en materia de TIC’s a los funcionarios de la DFOE. Por el alcance de los temas del Maletín, es necesario que el proyecto se haga extensivo a todos los funcionarios de la Institución. Al respecto, se puede decir que los temas que está considerando el Maletín Electrónico, están totalmente comprendidos en el presente estudio, sin embargo, se han tomado las previsiones y coordinación necesarias para que ambos esfuerzos se complementen.


TEMAS DEL PLAN DE CAPACITACIÓN CONTINUA EN TECNOLOGÍAS DE INFORMACIÓN 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

Fiscalizadores

Técnico-Secretarial

Administrativos

capacitación en dicha materia, del 2009 al 2012.

1

X

X

X

2 2 3 2 3 3

X

X

X

X

Jefaturas

CONTINUA EN TIC’s

Prioridad

TEMAS PARA EL PLAN DE CAPACITACION

SOFTWARE APLICATIVO Elaboración de Presentaciones, manejo y edición de imágenes, fotografías, video y audio, cambio de formato Manejo de Proyectos Software para la creación de flujos de procesos Cartografía Estadística Mapas Mentales Manejo de GPS HERRAMIENTAS Y UTILITARIOS: el conocimiento para el uso

X X X X

X

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 traductores Reuniones virtuales y chat, mensajería unificada 3 Seguridad de la información, compresión y empaquetamiento 2 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 Plan Estratégico en Tecnologías de Información y 1 Comunicación (PETIC)

X

X

X

X

X

X

X

X

X

X

X

X

Dirigido específicamente a los funcionarios del

Macroproyecto de TIC’s de la FOE, similar a la Maestría

fiscalización de TI Proceso de auditoría operativa y su aplicabilidad a la

1

X

1

X

evaluación de la gestión y control de las TI 1 Modelos de gestión y control con TI En qué consiste un sistema de gestión de calidad para los

X

1

X

SEVRI y la vinculación que tiene con éste la valoración de 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 riesgos en TI. Normas ISO 27001 e ISO 27002 y su aplicación a la Gestión de TI Administración de Proyectos (PMI y PMBoK)

X

X

X

X

X

X

X X X

X

1

X

1

X

X

Administrativos

X X

X

EN FISCALIZACION DE GESTION Y CONTROL DE LAS

sobre Auditoría de TI de la UCR. Conceptos fundamentales de auditoría aplicables a la

X X

X

CUALQUIER TIPO DE FISCALIZACIÓN Modelado de Datos 1 Extracción y análisis de datos con Excel 1 Extracción y análisis de datos con ACL O IDEA 1 Pruebas de auditoría sobre procesos de e información 1 electrónica y recopilación de evidencia CONOCIMIENTOS ESPECÍFICOS DE TIC’s APLICABLES TIC’s:


Plan Táctico (PETAC) 1 Modelo de Arquitectura de Información (MAI) 1 Proceso de valoración del Riesgo (SEVRI y riesgos en TI) 1 COSO (Committee of Sponsoring Organizations of the 1 Treadway Commission) COBIT (Control objectives for Information and related 1 Technology) ITIL (Information Technology Infrastructure Library) 1 CONOCIMIENTOS GENERALES DE TI APLICABLES A

Jefaturas

CONTINUA EN TIC’s

Prioridad


Fiscalizadores


X

X

1

X

capas, objetos, etc. 1 Administración de la tercerización de TI Plataforma Tecnológica (Operaciones, Telecomunicaciones,

X

Seguridad, Base de Datos, otros) Conceptos sobre administración de datos CICLO DE CHARLAS SOBRE LOS

1

X

1

X

(conceptos claves: o aplicaciones entiendo los siguientes conceptos: teorías, etapas del CVDS, CMMi, Casos de uso,

SISTEMAS

INSTITUCIONALES: Corresponde a charlas sobre todos los

X

sistemas Institucionales, como aprovecharlos al máximo,

X

X

X

X

1

tecnológica Desarrollo e implementación de sistemas de información

Administrativos

1

seguimiento) 1 Planificación estratégica de TI Modelo de Arquitectura de Información y de infraestructura


Marco jurídico relacionado con las TI (Importancia y

Jefaturas

CONTINUA EN TIC’s

Prioridad


Fiscalizadores


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 con los procesos Institucionales definidos en el MAGEFI Infraestructura Tecnológica (Redes, Telefonía, Bases de

1

X

1

X

Datos, Seguridad, Servidores) 1 Metodología de Gestión de Proyectos de TI 1 Herramientas de Software disponibles y su utilidad Aprovechamiento de la Información para la toma de 1 decisiones Rol del usuario en la Metodología de Desarrollo de Sistemas 1 MAESTRÍAS Maestría en Computación del TEC 2

X X

X X

X

Información CERTIFICACIONES

2

X

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 crecientes relacionadas con el gobierno de TI, promover

1

X

1

X

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

Administrativos


Maestría Profesional en Auditoría de Tecnologías de la

Jefaturas

CONTINUA EN TIC’s

Prioridad


Fiscalizadores


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 recomendadas en Seguridad de la información para

1

X

1

X

2 2 1 1 1

X X X X X

1 1

X X

1

X

1 1 1 1 1 1

X X X X X X

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 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) Certificación en Administración de Bases de Datos ORACLE Certificación en Desarrollo bajo la herramienta ORACLE Certificación en Administración de Servidores de Microsoft Certificación en redes para transmisión (Voz, datos, vídeo) TEMAS ESPECÍFICOS PARA LA USTI Casos Uso y Prueba (Metodologías) XML / Webservises JAVA / SQL/QUERY / HTML / XHTML / PHP / JAVA SCRIPT / CSS ORACLE (Herramientas de Desarrollo/Bases de Datos) Datawarehouse Seguridad en TIC’s Adm. de Redes ATM Telefonía Sistemas operativo/soft Usuario Final

Administrativos


Certificación ISO/IEC 27000 son estándares de seguridad

Jefaturas

CONTINUA EN TIC’s

Prioridad


Fiscalizadores


X X X X

Administrativos

2 2 2 1


Adm. de Proyectos Gestión de TIC’s Gestión Calidad en TIC’s Elementos de diseño de sitios Web

Jefaturas

CONTINUA EN TIC’s

Prioridad


Fiscalizadores



RECOMENDACIONES A continuación se exponen algunas sugerencias o recomendaciones que coadyuven a fortalecer los efectos y alcances de los resultados este Plan de Capacitación Continua en TIC’s: 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. Es recomendable la emisión de una política que promueva que se incluya en los procedimientos de trabajo de la Institución, la utilización intensiva las TIC’s y que la supervisión de sus resultados asegure su buen uso, lo cual se pueda evidenciar en la calidad y la oportunidad de los productos. En la medida de lo posible, se recomienda que se realicen exámenes de ubicación antes de llevar los eventos, de forma que se pueda determinar el nivel de conocimiento previo que tiene el participante, lo que brindará insumos para el instructor y también permitirá medir el nivel de aprendizaje logrado en el evento. En ese mismo sentido, se recomienda que las actividades tengan mecanismos de evaluación final que evidencien el conocimiento adquirido en el curso. De esta forma se podrá sustentar la aprobación respectiva y se podrá llevar un registro más claro del nivel adquirido por el participante. Se deberá hacer un uso intensivo de la plataforma tecnológica existente para apoyar los eventos de aprendizaje, a saber: la red institucional, el laboratorio de micros, el campus virtual, entre otros), de forma que se potencie la efectividad y el alcance de los eventos, así como la oportunidad de acceder a cursos no presenciales.


Se deberá llevar un registro eficiente de las actividades de aprendizaje recibidas por los funcionarios, relacionadas con los temas del presente plan. Esto permitirá llevar el pulso del avance del proyecto y brindará información sobre los conocimientos individuales de los participantes, lo cual podrá ser utilizado para la toma de decisiones. La evaluación del desempeño debe incorporar información sobre la aplicación de la tecnología en los trabajos y la disposición a utilizarla por parte del funcionario de la Contraloría General de la República y evidenciar las brechas que tiene con respecto al perfil del puesto. Asimismo, en cada evaluación se deberá proponer un plan de acción para disminuir las brechas señaladas en el punto anterior, el cual será un insumo para la planificación de las actividades de aprendizaje. 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. Se debe procurar la inclusión en los Planes Operativos Anuales de las diferentes Unidades de la Institución, el tiempo correspondiente a las actividades de aprendizaje en materia de TIC’s, tanto para los funcionarios participantes como para aquellos que funjan como profesores, facilitadores o expertos de contenido, para lo cual se deberá coordinar el respectivo apoyo institucional.

Esto ayudará a solventar

las limitaciones presupuestarias actuales y además permitirá que los eventos sean muy enfocados a las necesidades de la Contraloría, dado el conocimiento que los instructores tienen sobre la Institución


Se deberá gestionar la incorporación de los recursos económicos necesarios para apoyar las actividades de aprendizaje del presente Plan de Capacitación, para solventar aquellas que deban ser contratadas externamente.


ANEXOS ANEXO 1

Porcentaje de aplicación de conocimientos de tipo general en materia de TIC’s Encuesta aplicada en la DFOE 刀䔀匀唀䴀䔀一䐀䔀刀䔀匀倀唀䔀匀吀䄀匀匀漀昀琀眀愀爀攀瀀愀爀愀瀀爀漀挀攀猀愀洀椀攀渀琀漀搀攀瀀愀氀愀戀爀愀猀匀漀昀琀眀愀爀攀瀀愀爀愀洀愀渀攀樀漀搀攀栀漀樀愀猀攀氀攀挀琀爀渀椀挀愀猀匀漀昀琀眀愀爀攀瀀愀爀愀瀀爀攀猀攀渀琀愀挀椀漀渀攀猀搀攀搀椀愀瀀漀猀椀琀椀瘀愀猀匀漀昀琀眀愀爀攀瀀愀爀愀氀愀挀爀攀愀挀椀渀搀攀攀猀焀甀攀洀愀猀漀洀愀瀀愀猀挀漀渀挀攀瀀琀甀愀氀攀猀匀漀昀琀眀愀爀攀瀀愀爀愀挀爀攀愀挀椀渀搀攀戀愀猀攀猀搀攀搀愀琀漀猀匀漀昀琀眀愀爀攀瀀愀爀愀氀愀挀爀攀愀挀椀渀搀攀昀氀甀樀漀猀搀攀瀀爀漀挀攀猀漀猀匀漀昀琀眀愀爀攀瀀愀爀愀氀愀挀漀洀瀀爀攀猀椀渀搀攀愀爀挀栀椀瘀漀猀匀漀昀琀眀愀爀攀礀攀焀甀椀瀀漀瀀愀爀愀爀攀猀瀀愀氀搀漀搀攀椀渀昀漀爀洀愀挀椀渀 ⠀焀甀攀洀愀搀漀搀攀搀愀琀漀猀 ⤀ 匀漀昀琀眀愀爀攀礀攀焀甀椀瀀漀瀀愀爀愀攀猀挀愀渀攀漀搀攀椀洀最攀渀攀猀礀琀攀砀琀漀匀漀昀琀眀愀爀攀礀攀焀甀椀瀀漀瀀愀爀愀氀愀最爀愀戀愀挀椀渀礀攀搀椀挀椀渀搀攀愀甀搀椀漀匀漀昀琀眀愀爀攀礀攀焀甀椀瀀漀瀀愀爀愀琀漀洀愀爀礀攀搀椀琀愀爀昀漀琀漀最爀愀昀愀猀匀漀昀琀眀愀爀攀礀攀焀甀椀瀀漀瀀愀爀愀最爀愀戀愀挀椀渀礀攀搀椀挀椀渀搀攀瘀椀搀攀漀匀漀昀琀眀愀爀攀搀攀挀漀爀爀攀漀攀氀攀挀琀爀渀椀挀漀匀漀昀琀眀愀爀攀礀攀焀甀椀瀀漀瀀愀爀愀氀愀爀攀洀椀猀椀渀搀攀昀愀砀䤀渀瘀攀猀琀椀最愀挀椀渀攀渀䤀渀琀攀爀渀攀琀匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀瀀愀爀愀挀漀渀琀爀漀氀搀攀琀爀愀戀愀樀漀 ⠀匀䤀䜀夀䐀⤀ 匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀䴀搀甀氀漀搀攀琀漀洀愀搀攀搀攀挀椀猀椀漀渀攀猀 ⠀䴀吀䐀⤀ 匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀瀀愀爀愀猀攀最甀椀洀椀攀渀琀漀搀攀搀椀猀瀀漀猀椀挀椀漀渀攀猀匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀瀀愀爀愀氀愀愀挀琀椀瘀椀搀愀搀挀漀渀琀爀愀挀琀甀愀氀搀攀氀愀愀搀洀椀渀椀猀琀爀愀挀椀渀瀀切戀氀椀挀愀 ⠀匀䤀䄀䌀 ⤀ 匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀搀攀瀀爀攀猀甀瀀甀攀猀琀漀猀瀀切戀氀椀挀漀猀搀攀氀愀愀搀洀椀渀椀猀琀爀愀挀椀渀瀀切戀氀椀挀愀 ⠀匀䤀倀倀 ⤀ 匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀搀攀渀漀爀洀愀琀椀瘀愀瀀愀爀愀氀愀昀椀猀挀愀氀椀稀愀挀椀渀匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀搀攀愀爀挀栀椀瘀漀搀椀最椀琀愀氀 ⠀匀䄀䐀⤀ 匀椀猀琀攀洀愀椀渀猀琀椀琀甀挀椀漀渀愀氀瀀愀爀愀氀愀爀攀挀攀瀀挀椀渀搀攀䐀攀挀氀愀爀愀挀椀漀渀攀猀䨀甀爀愀搀愀猀

一椀渀最甀渀漀䈀愀樀漀一椀渀最礀䈀愀樀漀䴀攀搀椀漀一椀渀最ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㌀Ⰰ㔀─ 㔀Ⰰ㤀─ 㤀Ⰰ㐀─ ㈀㜀Ⰰ㌀─ ㌀㘀Ⰰ㜀─ 㐀Ⰰ㈀─ ㄀㐀Ⰰ　─ ㄀㠀Ⰰ㈀─ 㐀㄀Ⰰ㌀─ 㔀㤀Ⰰ㐀─ 㐀Ⰰ㔀─ ㄀㐀Ⰰ㌀─ ㄀㠀Ⰰ㤀─ ㌀㜀Ⰰ㐀─ 㔀㘀Ⰰ㌀─ ㌀㘀Ⰰ㜀─ 㐀㠀Ⰰ㌀─ 㐀㘀Ⰰ㤀─ 㐀㌀Ⰰ　─

㈀㤀Ⰰ　─ ㌀　Ⰰ㐀─ ㈀㤀Ⰰ　─ ㈀㌀Ⰰ㄀─

㘀㔀Ⰰ㜀─ 㜀㠀Ⰰ㜀─ 㜀㔀Ⰰ㤀─ 㘀㘀Ⰰ㄀─

㈀㄀Ⰰ㜀─ ㄀㔀Ⰰ　─ ㄀㜀Ⰰ㔀─ ㄀㜀Ⰰ㄀─

㠀㜀Ⰰ㐀─ 㤀㌀Ⰰ㜀─ 㤀㌀Ⰰ㐀─ 㠀㌀Ⰰ㈀─

㈀㌀Ⰰ㐀─ ㈀㘀Ⰰ㤀─ ㌀㔀Ⰰ　─ ㈀㤀Ⰰ㐀─ 㐀㌀Ⰰ㐀─ 㔀Ⰰ㤀─ ㈀㄀Ⰰ㌀─ 㐀Ⰰ㈀─ ㄀Ⰰ㐀─ ㈀Ⰰ㄀─ ㌀　Ⰰ㐀─

㈀㜀Ⰰ㘀─ ㈀㜀Ⰰ㘀─ ㈀㤀Ⰰ　─ ㈀㠀Ⰰ㌀─ ㈀㐀Ⰰ㠀─ ㄀㄀Ⰰ㈀─ ㈀㈀Ⰰ　─ ㄀㄀Ⰰ㈀─ 㤀Ⰰ㠀─ 㘀Ⰰ㘀─ ㌀㄀Ⰰ㠀─

㔀㄀Ⰰ　─ 㔀㐀Ⰰ㔀─ 㘀㐀Ⰰ　─ 㔀㜀Ⰰ㜀─ 㘀㠀Ⰰ㈀─ ㄀㜀Ⰰ㄀─ 㐀㌀Ⰰ㐀─ ㄀㔀Ⰰ㐀─ ㄀㄀Ⰰ㈀─ 㠀Ⰰ㜀─ 㘀㈀Ⰰ㈀─

㈀㐀Ⰰ㔀─ ㈀㈀Ⰰ㜀─ ㄀㠀Ⰰ㤀─ ㈀㈀Ⰰ㐀─ ㄀㤀Ⰰ㤀─ ㌀㄀Ⰰ㠀─ ㈀㜀Ⰰ㘀─ ㌀　Ⰰ㐀─ ㌀㐀Ⰰ㘀─ ㌀㔀Ⰰ㌀─ ㈀㔀Ⰰ㈀─

㜀㔀Ⰰ㔀─ 㜀㜀Ⰰ㌀─ 㠀㈀Ⰰ㤀─ 㠀　Ⰰ㄀─ 㠀㠀Ⰰ㄀─ 㐀㤀Ⰰ　─ 㜀㄀Ⰰ　─ 㐀㔀Ⰰ㠀─ 㐀㔀Ⰰ㠀─ 㐀㐀Ⰰ㄀─ 㠀㜀Ⰰ㐀─

㈀㘀Ⰰ㈀─

㐀㔀Ⰰ㔀─

㜀㄀Ⰰ㜀─

㈀㄀Ⰰ　─

㤀㈀Ⰰ㜀─

㌀　Ⰰ㄀─ 㤀Ⰰ㄀─ ㈀㔀Ⰰ㤀─

㌀㈀Ⰰ㔀─ ㈀㐀Ⰰ㔀─ ㈀㤀Ⰰ　─

㘀㈀Ⰰ㘀─ ㌀㌀Ⰰ㘀─ 㔀㐀Ⰰ㤀─

㈀　Ⰰ㘀─ 㐀　Ⰰ㤀─ ㈀㘀Ⰰ㘀─

㠀㌀Ⰰ㈀─ 㜀㐀Ⰰ㔀─ 㠀㄀Ⰰ㔀─

㔀　Ⰰ㌀─

㈀㠀Ⰰ㜀─

㜀㤀Ⰰ　─

㄀　Ⰰ㠀─

㠀㤀Ⰰ㤀─


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. Encuesta aplicada en la División DFOE 䌀伀一伀䌀䤀䴀䤀䔀一吀伀匀䜀䔀一䔀刀䄀䰀䔀匀䐀䔀吀䤀䄀倀䰀䤀䌀䄀䈀䰀䔀匀䄀䌀唀䄀䰀儀唀䤀䔀刀吀䤀倀伀䐀䔀䘀䤀匀䌀䄀䰀䤀娀䄀䌀䤀팀一㄀⸀ ꀀꀀꀀꀀꀀꀀꀀ 吀攀渀最漀挀漀渀漀挀椀洀椀攀渀琀漀猀猀漀戀爀攀 ᰠ 洀漀搀攀氀愀搀漀搀攀搀愀琀漀猀ᴠ 礀挀漀洀漀瀀愀爀琀攀搀攀攀氀氀漀挀漀渀漀稀挀漀Ⰰ 攀渀琀椀攀渀搀漀礀猀攀愀瀀氀椀挀愀爀氀漀猀挀漀渀挀攀瀀琀漀猀搀攀㨀㈀⸀ ꀀꀀꀀꀀꀀꀀꀀ 倀甀攀搀漀洀愀渀攀樀愀爀氀愀猀漀瀀挀椀漀渀攀猀戀猀椀挀愀猀搀攀栀攀爀爀愀洀椀攀渀琀愀猀瀀愀爀愀氀愀攀砀琀爀愀挀挀椀渀礀愀渀氀椀猀椀猀搀攀搀愀琀漀猀㬀攀渀琀爀攀攀氀氀愀猀㨀㌀⸀ ꀀꀀꀀꀀꀀꀀꀀ 䔀渀挀甀愀渀琀漀愀氀愀攀樀攀挀甀挀椀渀搀攀瀀爀甀攀戀愀猀搀攀愀甀搀椀琀漀爀 愀猀漀戀爀攀瀀爀漀挀攀猀漀猀攀椀渀昀漀爀洀愀挀椀渀攀氀攀挀琀爀 渀椀挀愀礀氀愀爀攀挀漀瀀椀氀愀挀椀渀搀攀攀猀琀攀琀椀瀀漀搀攀攀瘀椀搀攀渀挀椀愀Ⰰ 挀漀渀漀稀挀漀愀猀瀀攀挀琀漀猀戀猀椀挀漀猀猀漀戀爀攀㨀䌀伀一伀䌀䤀䴀䤀䔀一吀伀匀䔀匀倀䔀䌀 촀䘀䤀䌀伀匀䐀䔀吀䤀䄀倀䰀䤀䌀䄀䈀䰀䔀匀䔀一䘀䤀匀䌀䄀䰀䤀娀䄀䌀䤀伀一䐀䔀䜀䔀匀吀䤀伀一夀䌀伀一吀刀伀䰀䐀䔀䰀䄀匀吀䤀㐀⸀ ꀀꀀꀀꀀꀀꀀꀀ 䌀甀攀渀琀漀挀漀渀挀漀渀漀挀椀洀椀攀渀琀漀猀戀猀椀挀漀猀猀漀戀爀攀挀漀渀挀攀瀀琀漀猀昀甀渀搀愀洀攀渀琀愀氀攀猀搀攀愀甀搀椀琀漀爀 愀愀瀀氀椀挀愀戀氀攀猀愀氀愀昀椀猀挀愀氀椀稀愀挀椀渀搀攀吀䤀㔀⸀ ꀀꀀꀀꀀꀀꀀꀀ 䌀漀渀漀稀挀漀洀漀搀攀氀漀猀搀攀最攀猀琀椀渀礀挀漀渀琀爀漀氀挀漀渀吀䤀㨀㘀⸀ ꀀꀀꀀꀀꀀꀀꀀ 䌀漀渀漀稀挀漀氀愀

椀洀瀀漀爀琀愀渀挀椀愀礀瀀甀攀搀漀瀀漀渀攀爀攀樀攀洀瀀氀漀猀搀攀瀀漀氀琀椀挀愀猀焀甀攀甀渀愀攀渀琀椀搀愀搀搀攀戀攀椀洀瀀氀攀洀攀渀琀愀爀攀渀洀愀琀攀爀椀愀搀攀吀䤀 ⸀ 㜀⸀ ꀀꀀꀀꀀꀀꀀꀀ 倀甀攀搀漀搀攀猀挀爀椀戀椀爀 Ⰰ 攀渀昀漀爀洀愀最攀渀攀爀愀氀Ⰰ 攀渀焀甀 挀漀渀猀椀猀琀攀甀渀猀椀猀琀攀洀愀搀攀最攀猀琀椀渀搀攀挀愀氀椀搀愀搀瀀愀爀愀氀漀猀瀀爀漀挀攀猀漀猀搀攀吀䤀 ⸀ 㠀⸀ ꀀꀀꀀꀀꀀꀀꀀ 䌀漀渀漀稀挀漀攀氀瀀爀漀挀攀猀漀搀攀瘀愀氀漀爀愀挀椀渀搀攀爀椀攀猀最漀猀猀攀最切渀氀愀渀漀爀洀愀琀椀瘀愀搀攀氀匀䔀嘀刀䤀礀氀愀瘀椀渀挀甀氀愀挀椀渀焀甀攀琀椀攀渀攀挀漀渀 猀琀攀氀愀瘀愀氀漀爀愀挀椀渀搀攀爀椀攀猀最漀猀攀渀吀䤀 ⸀ 㤀⸀ ꀀꀀꀀꀀꀀꀀꀀ 䌀漀渀爀攀猀瀀攀挀琀漀愀氀愀猀渀漀爀洀愀猀䤀匀伀㈀㜀　　㄀攀䤀匀伀㈀㜀　　㈀Ⰰ 挀漀渀漀稀挀漀愀氀漀焀甀攀猀攀爀攀昀椀攀爀攀渀氀漀猀猀椀最甀椀攀渀琀攀猀挀漀渀挀攀瀀琀漀猀㨀㄀　⸀ ꀀꀀꀀꀀ 刀攀猀瀀攀挀琀漀愀氀愀愀搀洀椀渀椀猀琀爀愀挀椀渀搀攀瀀爀漀礀攀挀琀漀猀攀渀琀椀攀渀搀漀氀漀猀猀椀最甀椀攀渀琀攀猀挀漀渀挀攀瀀琀漀猀㨀㄀㄀⸀ ꀀꀀꀀꀀ 䔀渀琀椀攀渀搀漀氀愀椀洀瀀漀爀琀愀渀挀椀愀搀攀焀甀攀氀愀漀爀最愀渀椀稀愀挀椀渀挀甀攀渀琀攀挀漀渀甀渀瀀爀漀挀攀猀漀搀攀猀攀最甀椀洀椀攀渀琀漀搀攀氀洀愀爀挀漀樀甀爀 搀椀挀漀焀甀攀愀昀攀挀琀愀氀愀最攀猀琀椀渀搀攀氀愀猀吀䤀 ⸀ ㄀㈀⸀ ꀀꀀꀀꀀ 匀漀戀爀攀攀氀洀愀爀挀漀樀甀爀 搀椀挀漀爀攀氀愀挀椀漀渀愀搀漀挀漀渀氀愀猀吀䤀挀漀渀漀稀挀漀Ⰰ 攀渀琀爀洀椀渀漀猀最攀渀攀爀愀氀攀猀Ⰰ 氀漀猀攀愀氀愀搀漀瀀漀爀氀愀猀椀最甀椀攀渀琀攀渀漀爀洀愀琀椀瘀愀爀攀猀瀀攀挀琀漀愀搀椀挀栀愀洀愀琀攀爀椀愀㨀㄀㌀⸀ ꀀꀀꀀꀀ 匀漀戀爀攀氀愀瀀氀愀渀椀昀椀挀愀挀椀渀攀猀琀爀愀琀最椀挀愀搀攀吀䤀挀漀渀漀稀挀漀㨀㄀㐀⸀ ꀀꀀꀀꀀ 匀攀焀甀 攀猀

甀渀䴀䄀䤀礀攀渀琀椀攀渀搀漀氀愀椀洀瀀漀爀琀愀渀挀椀愀搀攀焀甀攀琀漀搀愀漀爀最愀渀椀稀愀挀椀渀挀甀攀渀琀攀挀漀渀猀甀洀漀搀攀氀漀搀攀椀渀昀漀爀洀愀挀椀渀愀挀琀甀愀氀椀稀愀搀漀⸀ ㄀㔀⸀ ꀀꀀꀀꀀ 䔀渀琀椀攀渀搀漀氀愀椀洀瀀漀爀琀愀渀挀椀愀搀攀焀甀攀氀愀猀漀爀最愀渀椀稀愀挀椀漀渀攀猀挀甀攀渀琀攀渀挀漀渀甀渀愀搀攀猀挀爀椀瀀挀椀渀最爀 昀椀挀愀搀攀猀甀椀渀昀爀愀攀猀琀爀甀挀琀甀爀愀琀攀挀渀漀氀最椀挀愀⸀ ㄀㘀⸀ ꀀꀀ 䌀漀渀漀稀挀漀氀愀爀愀稀渀瀀漀爀氀愀挀甀愀氀琀愀渀琀漀攀氀洀漀搀攀氀漀搀攀椀渀昀漀爀洀愀挀椀渀挀漀洀漀搀攀椀渀昀爀愀攀猀琀爀甀挀琀甀爀愀琀攀挀渀漀氀最椀挀愀挀漀渀猀琀椀琀甀礀攀渀椀渀猀甀洀漀猀搀攀氀愀瀀氀愀渀椀昀椀挀愀挀椀渀搀攀氀愀猀吀䤀 ⸀ ㄀㜀⸀ ꀀꀀ 䔀渀琀椀攀渀搀漀攀氀挀漀渀挀攀瀀琀漀搀攀 ᰠ 椀渀搀攀瀀攀渀搀攀渀挀椀愀ᴠ 挀甀愀渀搀漀攀猀琀攀猀攀愀瀀氀椀挀愀愀氀愀昀甀渀挀椀渀搀攀吀䤀挀漀渀爀攀猀瀀攀挀琀漀愀氀爀攀猀琀漀搀攀氀愀漀爀最愀渀椀稀愀挀椀渀⸀ ㄀㠀⸀ ꀀꀀꀀꀀ 䌀甀渀搀漀猀攀栀愀戀氀愀搀攀氀搀攀猀愀爀爀漀氀氀漀漀搀攀氀愀椀洀瀀氀攀洀攀渀琀愀挀椀渀搀攀猀椀猀琀攀洀愀猀搀攀椀渀昀漀爀洀愀挀椀渀漀愀瀀氀椀挀愀挀椀漀渀攀猀攀渀琀椀攀渀搀漀氀漀猀猀椀最甀椀攀渀琀攀猀挀漀渀挀攀瀀琀漀猀㨀㄀㤀⸀ ꀀꀀꀀꀀ 䔀渀琀椀攀渀搀漀氀愀椀洀瀀漀爀琀愀渀挀椀愀搀攀攀猀琀愀戀氀攀挀攀爀挀漀渀琀爀漀氀攀猀挀甀愀渀搀漀猀攀挀漀渀琀爀愀琀愀愀琀攀爀挀攀爀漀猀瀀愀爀愀椀洀瀀氀攀洀攀渀琀愀爀猀椀猀琀攀洀愀猀攀渀氀愀漀爀最愀渀椀稀愀挀椀渀⸀ ㈀　⸀ ꀀꀀꀀꀀ 䌀漀渀爀攀猀瀀攀挀琀漀愀氀漀愀渀琀攀爀椀漀爀 Ⰰ 攀渀琀椀攀渀搀漀氀愀椀洀瀀漀爀琀愀渀挀椀愀搀攀㨀㈀㄀⸀ ꀀꀀꀀꀀ 䌀漀渀漀稀挀漀氀漀猀猀椀最甀椀攀渀琀攀猀挀漀渀挀攀瀀琀漀猀爀攀氀愀挀椀漀渀愀搀漀猀挀漀渀瀀氀愀琀愀昀漀爀洀愀琀攀挀渀漀氀最椀挀愀㨀㈀㈀⸀ ꀀꀀꀀꀀ 匀漀戀爀攀氀愀愀搀洀椀渀椀猀琀爀愀挀椀渀搀攀搀愀琀漀猀攀渀琀椀攀渀搀漀愀氀漀焀甀攀猀攀爀攀昀椀攀爀攀渀氀漀猀猀椀最甀椀攀渀琀攀猀挀漀渀挀攀瀀琀漀猀㨀㈀㌀⸀ ꀀꀀꀀꀀ 䔀渀琀椀攀渀搀漀氀愀愀瀀氀椀挀愀挀椀渀搀攀栀攀爀爀愀洀椀攀渀琀愀猀挀漀洀漀攀氀䈀匀䌀攀渀氀愀攀瘀愀氀甀愀挀椀渀搀攀氀搀攀猀攀洀瀀攀漀⸀

匀

一漀

匀

一漀

㈀　Ⰰ㜀─ 㜀㤀Ⰰ㌀─ ㈀㠀Ⰰ㔀─ 㜀㄀Ⰰ㔀─ ㄀㠀Ⰰ㄀─ 㠀㄀Ⰰ㤀─ ㄀㤀Ⰰ㈀─ 㠀　Ⰰ㠀─ ㌀㌀Ⰰ㔀─ 㘀㘀Ⰰ㔀─ 㘀　Ⰰ㐀─ ㌀㤀Ⰰ㘀─ ㄀㐀Ⰰ㠀─ 㠀㔀Ⰰ㈀─ ㌀㐀Ⰰ㘀─ 㘀㔀Ⰰ㐀─ ㈀㔀Ⰰ㔀─ 㜀㐀Ⰰ㔀─ ㈀㌀Ⰰ㐀─ 㜀㘀Ⰰ㘀─ ㄀㘀Ⰰ㌀─ 㠀㌀Ⰰ㜀─ 㐀㈀Ⰰ㜀─ 㔀㜀Ⰰ㌀─ 㜀㄀Ⰰ　─ ㈀㤀Ⰰ　─ 㐀㤀Ⰰ　─ 㔀㄀Ⰰ　─ ㈀㄀Ⰰ㔀─ 㜀㠀Ⰰ㔀─ ㄀㠀Ⰰ㈀─ 㠀㄀Ⰰ㠀─ 㔀㠀Ⰰ　─ 㐀㈀Ⰰ　─ ㌀㤀Ⰰ㈀─ 㘀　Ⰰ㠀─ 㐀　Ⰰ㈀─ 㔀㤀Ⰰ㠀─ ㄀㤀Ⰰ㔀─ 㠀　Ⰰ㔀─ 㜀㜀Ⰰ㘀─ ㈀㈀Ⰰ㐀─ 㘀㌀Ⰰ㔀─ ㌀㘀Ⰰ㔀─ ㌀㌀Ⰰ㄀─ 㘀㘀Ⰰ㤀─ ㌀㜀Ⰰ㐀─ 㘀㈀Ⰰ㘀─ ㄀　Ⰰ㄀─ 㠀㤀Ⰰ㤀─


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 Encuesta aplicada en la DFOE 䌀伀䴀倀䔀吀䔀一䌀䤀䄀

䌀伀䴀倀伀刀吀䄀䴀䤀䔀一吀伀䌀愀瀀愀挀椀搀愀搀搀攀䄀戀猀琀爀愀挀挀椀渀倀攀爀椀挀椀愀攀渀攀氀洀愀渀攀樀漀搀攀椀渀昀漀爀洀愀挀椀渀倀爀漀瀀漀渀攀挀甀爀猀漀猀搀攀愀挀挀椀渀攀渀昀渀搀攀氀爀椀攀猀最漀䘀椀猀挀愀氀椀稀愀挀椀渀搀攀䌀愀氀椀搀愀搀Ⰰ 瀀爀漀洀甀攀瘀攀礀攀渀猀攀愀䄀甀琀漀渀漀洀愀礀爀攀猀瀀漀渀猀愀戀椀氀椀搀愀搀瀀愀爀愀愀氀挀愀渀稀愀爀洀攀琀愀猀吀漀洀愀搀攀挀椀猀椀漀渀攀猀愀挀攀爀琀愀搀愀猀礀挀漀渀猀椀猀琀攀渀琀攀猀愀瀀漀礀愀搀漀攀渀氀愀猀䰀䤀䐀䔀刀䄀娀䜀伀吀䤀䌀 ✀猀匀攀最甀爀椀搀愀搀瀀愀爀愀瀀爀漀瀀漀渀攀爀礀搀攀昀攀渀搀攀爀椀搀攀愀猀䌀漀洀甀渀椀挀愀挀椀渀攀猀挀爀椀琀愀挀漀栀攀爀攀渀琀攀Ⰰ 挀氀愀爀愀礀瀀爀攀挀椀猀愀䌀漀洀甀渀椀挀愀挀椀渀漀爀愀氀搀攀洀愀渀攀爀愀挀氀愀爀愀Ⰰ 愀猀攀爀琀椀瘀愀Ⰰ 漀瀀漀爀琀甀渀愀礀攀昀攀挀琀椀瘀愀䌀漀洀甀渀椀挀愀漀瀀漀爀琀甀渀愀洀攀渀琀攀愀猀甀渀琀漀猀猀椀最渀椀昀椀挀愀琀椀瘀漀猀愀猀甀猀猀甀瀀攀爀椀漀爀攀猀礀愀氀攀焀甀椀瀀漀䌀伀䴀唀一䤀䌀䄀䌀䤀팀一匀愀戀攀攀猀挀甀挀栀愀爀礀猀攀椀渀琀攀爀攀猀愀愀甀琀渀琀椀挀愀洀攀渀琀攀攀渀攀猀琀椀洀甀氀愀爀愀氀漀猀挀漀洀瀀愀攀爀漀猀䤀渀琀攀爀愀挀琀切愀愀猀攀爀琀椀瘀愀洀攀渀琀攀挀漀渀猀甀瀀攀爀椀漀爀攀猀 Ⰰ攀焀甀椀瀀漀搀攀琀爀愀戀愀樀漀礀挀漀渀挀氀椀攀渀琀攀猀䔀猀琀愀戀氀攀挀攀礀洀愀渀琀椀攀渀攀爀攀氀愀挀椀漀渀攀猀攀砀椀琀漀猀愀猀愀氀椀渀琀攀爀渀漀礀昀甀攀爀愀搀攀氀愀䌀䜀刀吀爀愀戀愀樀愀搀攀洀愀渀攀爀愀攀昀椀挀椀攀渀琀攀攀渀攀焀甀椀瀀漀猀洀甀氀琀椀搀椀猀挀椀瀀氀椀渀愀爀椀漀猀礀吀刀䄀䈀䄀䨀伀䔀一琀椀攀渀攀昀氀攀砀椀戀椀氀椀搀愀搀䈀爀椀渀搀愀愀瀀漀礀漀愀猀甀瀀攀爀椀漀爀攀猀礀挀漀洀漀洀椀攀洀戀爀漀搀攀氀攀焀甀椀瀀漀琀椀攀渀攀䔀儀唀䤀倀　甀渀渀椀瘀攀氀搀攀琀爀愀戀愀樀漀攀氀攀瘀愀搀漀倀氀愀渀椀昀椀挀愀礀搀攀琀攀爀洀椀渀愀攀渀昀漀爀洀愀爀攀愀氀椀猀琀愀氀漀猀爀攀挀甀爀猀漀猀礀攀氀琀椀攀洀瀀漀渀攀挀攀猀愀爀椀漀猀䄀䐀䴀䤀一䤀匀吀刀䄀䌀䤀伀一刀攀愀氀椀稀愀甀渀愀愀搀攀挀甀愀搀愀愀猀椀最渀愀挀椀渀搀攀氀琀爀愀戀愀樀漀攀渀琀爀攀氀漀猀䐀䔀刀䔀䌀唀刀匀伀匀夀洀椀攀洀戀爀漀猀搀攀氀攀焀甀椀瀀漀刀攀猀瀀攀琀愀礀挀甀洀瀀氀攀氀漀猀瀀氀愀稀漀猀搀攀攀樀攀挀甀挀椀渀攀猀琀愀戀氀攀挀椀搀漀猀吀䤀䔀䴀倀伀匀攀漀爀最愀渀椀稀愀愀搀攀挀甀愀搀愀洀攀渀琀攀瀀愀爀愀愀琀攀渀搀攀爀挀漀渀挀愀氀椀搀愀搀礀瀀爀漀渀琀椀琀甀搀氀愀猀搀椀昀攀爀攀渀琀攀猀氀愀戀漀爀攀猀愀猀椀最渀愀搀愀猀䠀愀戀椀氀椀搀愀搀瀀愀爀愀琀爀愀戀愀樀愀爀挀漀渀愀甀琀漀渀漀洀愀攀椀洀瀀愀爀挀椀愀氀椀搀愀搀䰀伀䜀刀伀䐀䔀䰀漀最爀愀焀甀攀猀甀瀀爀漀搀甀挀挀椀渀礀氀愀搀攀氀攀焀甀椀瀀漀琀攀渀最愀漀爀搀攀渀Ⰰ 刀䔀匀唀䰀吀䄀䐀伀匀挀愀氀椀搀愀搀Ⰰ 瀀爀攀挀椀猀椀渀礀爀椀最甀爀漀猀椀搀愀搀䄀猀椀洀椀氀愀攀椀渀挀漀爀瀀漀爀愀昀挀椀氀洀攀渀琀攀氀愀愀瀀氀椀挀愀挀椀渀搀攀渀甀攀瘀愀猀吀䤀䌀 ✀猀攀渀氀漀猀琀爀愀戀愀樀漀猀䤀一一伀嘀䄀䌀䤀팀一䄀挀琀甀愀氀椀稀愀猀甀猀挀漀渀漀挀椀洀椀攀渀琀漀猀攀渀琀攀洀愀猀搀攀椀渀琀攀爀猀瀀愀爀愀氀愀䤀渀猀琀椀琀甀挀椀渀礀攀渀攀氀甀猀漀搀攀吀䤀䌀 ✀猀䴀愀渀琀椀攀渀攀甀渀戀甀攀渀搀攀猀攀洀瀀攀漀愀切渀攀渀猀椀琀甀愀挀椀漀渀攀猀搀攀洀甀挀栀愀瀀爀攀猀椀渀䄀唀吀伀䌀伀一吀刀伀䰀刀攀挀漀渀漀挀攀昀漀爀琀愀氀攀稀愀猀 Ⰰ 椀搀攀渀琀椀昀椀挀愀猀甀猀攀爀爀漀爀攀猀礀氀椀洀椀琀愀挀椀漀渀攀猀礀琀漀洀愀愀挀挀椀漀渀攀猀瀀愀爀愀洀攀樀漀爀愀爀倀䔀一匀䄀䴀䤀䔀一吀伀匀䤀匀吀 준 䴀䤀䌀伀

一䄀㈀Ⰰ㐀─ ㈀Ⰰ㐀─ 㘀Ⰰ㌀─ ㄀㔀Ⰰ㜀─ ㈀㌀Ⰰ㄀─

䈀愀樀漀一䄀ⴀ䈀愀樀漀㄀㌀Ⰰ㘀─ ㄀㘀Ⰰ㄀─ ㄀㔀Ⰰ㐀─ ㄀㜀Ⰰ㠀─ ㄀㈀Ⰰ㘀─ ㄀㠀Ⰰ㤀─ ㄀㜀Ⰰ㔀─ ㌀㌀Ⰰ㈀─ ㄀㄀Ⰰ㤀─ ㌀㔀Ⰰ　─

䴀攀搀椀漀一䄀ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㜀㄀Ⰰ　─ 㔀㐀Ⰰ㤀─ 㘀㠀Ⰰ㔀─ 㔀　Ⰰ㜀─ 㘀㤀Ⰰ㤀─ 㔀㄀Ⰰ　─ 㜀㈀Ⰰ　─ ㌀㠀Ⰰ㠀─ 㜀㄀Ⰰ㌀─ ㌀㘀Ⰰ㐀─ 匀漀戀爀攀吀䤀

㄀㈀Ⰰ㤀─ 㐀Ⰰ㔀─ ㄀Ⰰ㜀─

㠀Ⰰ㜀─ 㜀Ⰰ㜀─ 㜀Ⰰ　─

㈀㄀Ⰰ㜀─ ㄀㈀Ⰰ㈀─ 㠀Ⰰ㜀─

㐀㘀Ⰰ㈀─ 㐀　Ⰰ㤀─ 㔀㈀Ⰰ㠀─

㘀㜀Ⰰ㠀─ 㔀㌀Ⰰ㄀─ 㘀㄀Ⰰ㔀─

㄀Ⰰ㜀─

㄀㄀Ⰰ㔀─

㄀㌀Ⰰ㌀─

㔀　Ⰰ㜀─

㘀㐀Ⰰ　─

㌀Ⰰ㄀─

㔀Ⰰ㤀─

㤀Ⰰ㄀─

㐀㐀Ⰰ㠀─

㔀㌀Ⰰ㠀─

㐀Ⰰ㔀─

㐀Ⰰ㈀─

㠀Ⰰ㜀─

㌀㜀Ⰰ㐀─

㐀㘀Ⰰ㈀─

㌀Ⰰ㄀─

㌀Ⰰ㄀─

㘀Ⰰ㌀─

㌀㜀Ⰰ㠀─

㐀㐀Ⰰ㄀─

㄀Ⰰ㜀─

㌀Ⰰ㠀─

㔀Ⰰ㘀─

㈀㤀Ⰰ㜀─

㌀㔀Ⰰ㌀─

㔀Ⰰ㤀─

㔀Ⰰ㤀─

㄀㄀Ⰰ㤀─

㌀㐀Ⰰ㘀─

㐀㘀Ⰰ㔀─

㐀Ⰰ㤀─

㈀Ⰰ㠀─

㜀Ⰰ㜀─

㌀㔀Ⰰ　─

㐀㈀Ⰰ㜀─

㤀Ⰰ㠀─

㘀Ⰰ㘀─

㄀㘀Ⰰ㐀─

㐀㤀Ⰰ　─

㘀㔀Ⰰ㐀─

㈀㜀Ⰰ㘀─ ㌀Ⰰ㔀─

㔀Ⰰ㈀─ 㘀Ⰰ㌀─

㌀㈀Ⰰ㤀─ 㤀Ⰰ㠀─

㌀㔀Ⰰ㌀─ 㐀㜀Ⰰ㤀─

㘀㠀Ⰰ㈀─ 㔀㜀Ⰰ㜀─

㈀Ⰰ㐀─ ㄀Ⰰ㜀─

㈀Ⰰ㐀─ ㌀Ⰰ㄀─

㐀Ⰰ㤀─ 㐀Ⰰ㤀─

㌀㠀Ⰰ㔀─ ㌀　Ⰰ㐀─

㐀㌀Ⰰ㐀─ ㌀㔀Ⰰ㌀─

㄀㄀Ⰰ㈀─

㐀Ⰰ㈀─

㄀㔀Ⰰ㐀─

㌀㐀Ⰰ㘀─

㔀　Ⰰ　─

㐀Ⰰ㤀─

㤀Ⰰ㄀─

㄀㐀Ⰰ　─

㐀㜀Ⰰ㈀─

㘀㄀Ⰰ㈀─

匀漀戀爀攀吀䤀

㌀Ⰰ㄀─

㄀㌀Ⰰ㘀─

㄀㘀Ⰰ㠀─

㐀㤀Ⰰ㌀─

㘀㘀Ⰰ㄀─


㄀Ⰰ㜀─

㔀Ⰰ㈀─

㜀Ⰰ　─

㐀㘀Ⰰ㔀─

㔀㌀Ⰰ㔀─

㄀Ⰰ㜀─

㌀Ⰰ㔀─

㔀Ⰰ㈀─

㌀㐀Ⰰ㌀─

㌀㤀Ⰰ㔀─


ANEXO 5

Grado de Conocimientos sobre TIC’s Encuesta Aplicada en DDI, DEI, DAGJ y en DCA 䤀䤀倀䄀刀吀䔀匀漀戀爀攀攀氀洀愀渀攀樀漀搀攀猀漀昀琀眀愀爀攀椀渀猀琀椀琀甀挀椀漀渀愀氀䈀 猀椀挀漀䰀愀猀爀攀猀瀀甀攀猀琀愀猀椀渀搀椀挀愀渀攀氀最爀愀搀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀攀渀攀氀琀攀洀愀挀漀渀猀甀氀琀愀搀漀刀䔀匀唀䴀䔀一䐀䔀刀䔀匀倀唀䔀匀吀䄀匀吀攀砀琀漀猀攀氀攀挀琀爀渀椀挀漀猀䠀漀樀愀搀攀䌀 氀挀甀氀漀倀爀攀猀攀渀琀愀挀椀漀渀攀猀䴀愀渀攀樀漀搀攀椀洀最攀渀攀猀䴀愀渀攀樀漀搀攀瘀椀搀攀漀䴀愀渀攀樀漀搀攀䄀甀搀椀漀䌀爀漀渀漀最爀愀洀愀猀匀攀最甀爀椀搀愀搀搀攀氀愀椀渀昀漀爀洀愀挀椀渀

一椀渀最甀渀漀䈀愀樀漀㄀Ⰰ㘀─ 㘀Ⰰ㌀─ ㄀㄀Ⰰ㄀─ ㈀㈀Ⰰ㈀─ 㤀Ⰰ㔀─ ㈀㘀Ⰰ㈀─ ㄀㘀Ⰰ㜀─ ㈀㔀Ⰰ㐀─ 㐀㔀Ⰰ㈀─ ㈀㜀Ⰰ㠀─ 㔀㄀Ⰰ㘀─ ㈀㤀Ⰰ㐀─ 㐀㌀Ⰰ㜀─ ㈀㜀Ⰰ　─ ㈀㤀Ⰰ㐀─ ㌀㔀Ⰰ㜀─

䄀挀甀洀甀氀愀搀漀一椀渀最礀䈀愀樀漀㜀Ⰰ㤀─ ㌀㌀Ⰰ㌀─ ㌀㔀Ⰰ㜀─ 㐀㈀Ⰰ㄀─ 㜀㌀Ⰰ　─ 㠀㄀Ⰰ　─ 㜀　Ⰰ㘀─ 㘀㔀Ⰰ㄀─

䴀攀搀椀漀㌀㐀Ⰰ㤀─ 㐀㐀Ⰰ㐀─ ㌀㐀Ⰰ㤀─ ㌀㐀Ⰰ㄀─ ㈀　Ⰰ㘀─ ㄀㈀Ⰰ㜀─ ㈀　Ⰰ㘀─ ㈀　Ⰰ㘀─

䄀挀甀洀甀氀愀搀漀一椀渀最ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㐀㈀Ⰰ㤀─ 㜀㜀Ⰰ㠀─ 㜀　Ⰰ㘀─ 㜀㘀Ⰰ㈀─ 㤀㌀Ⰰ㜀─ 㤀㌀Ⰰ㜀─ 㤀㄀Ⰰ㌀─ 㠀㔀Ⰰ㜀─

䤀䤀倀䄀刀吀䔀匀漀戀爀攀攀氀洀愀渀攀樀漀搀攀猀漀昀琀眀愀爀攀椀渀猀琀椀琀甀挀椀漀渀愀氀䔀猀瀀攀挀椀愀氀椀稀愀搀漀䰀愀猀爀攀猀瀀甀攀猀琀愀猀椀渀搀椀挀愀渀攀氀最爀愀搀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀攀渀攀氀琀攀洀愀挀漀渀猀甀氀琀愀搀漀刀䔀匀唀䴀䔀一䐀䔀刀䔀匀倀唀䔀匀吀䄀匀䌀愀爀琀漀最爀愀昀愀䔀猀琀愀搀猀琀椀挀愀䴀愀瀀愀猀䴀攀渀琀愀氀攀猀䔀砀琀爀愀挀挀椀渀礀䄀渀氀椀猀椀猀搀攀搀愀琀漀猀䴀愀渀攀樀漀搀攀䜀倀匀

䄀挀甀洀甀氀愀搀漀一椀渀最甀渀漀䈀愀樀漀一椀渀最礀䈀愀樀漀㤀㜀Ⰰ㘀─ 㜀㈀Ⰰ㈀─ ㈀㔀Ⰰ㐀─ 㠀㠀Ⰰ㄀─ 㘀㄀Ⰰ㄀─ ㈀㜀Ⰰ　─ 㜀㜀Ⰰ　─ 㐀㌀Ⰰ㜀─ ㌀㌀Ⰰ㌀─ 㜀㘀Ⰰ㈀─ 㐀㘀Ⰰ㠀─ ㈀㤀Ⰰ㐀─ 㤀㔀Ⰰ㈀─ 㜀㤀Ⰰ㐀─ ㄀㔀Ⰰ㤀─

䄀挀甀洀甀氀愀搀漀䴀攀搀椀漀一椀渀最ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㄀　　Ⰰ　─ ㈀Ⰰ㐀─ 㤀㠀Ⰰ㐀─ ㄀　Ⰰ㌀─ 㤀㈀Ⰰ㄀─ ㄀㔀Ⰰ㄀─ 㤀㔀Ⰰ㈀─ ㄀㤀Ⰰ　─ ㄀　　Ⰰ　─ 㐀Ⰰ㠀─


ANEXO 5 (Continuación)

Grado de Conocimientos sobre TIC’s Encuesta Aplicada en DDI, DEI, DAGJ y en DCA 䤀䤀倀䄀刀吀䔀匀漀戀爀攀栀攀爀爀愀洀椀攀渀琀愀猀眀攀戀Ⰰ 挀漀渀猀甀氀琀愀猀攀氀攀挀琀爀渀椀挀愀猀 Ⰰ 甀琀椀氀椀稀愀挀椀渀搀攀䔀焀甀椀瀀漀搀攀挀 洀瀀甀琀漀Ⰰ 甀渀椀搀愀搀攀猀瀀攀爀椀昀爀椀挀愀猀礀漀琀爀漀猀攀焀甀椀瀀漀猀搀攀漀昀椀挀椀渀愀⸀ 䰀愀猀爀攀猀瀀甀攀猀琀愀猀椀渀搀椀挀愀渀攀氀最爀愀搀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀攀渀攀氀琀攀洀愀挀漀渀猀甀氀琀愀搀漀刀䔀匀唀䴀䔀一䐀䔀刀䔀匀倀唀䔀匀吀䄀匀䄀瀀漀礀漀攀渀氀愀戀漀爀攀猀搀攀伀昀椀挀椀渀愀䤀渀瘀攀猀琀椀最愀挀椀渀攀渀氀愀圀攀戀Ⰰ 甀猀漀搀攀戀甀猀挀愀搀漀爀攀猀 Ⰰ 搀椀挀挀椀漀渀愀爀椀漀猀礀琀爀愀搀甀挀琀漀爀攀猀刀攀甀渀椀漀渀攀猀瘀椀爀琀甀愀氀攀猀礀挀栀愀琀Ⰰ 洀攀渀猀愀樀攀爀愀甀渀椀昀椀挀愀搀愀䐀椀最椀琀愀氀椀稀愀挀椀渀搀攀搀漀挀甀洀攀渀琀漀猀唀猀漀搀攀爀攀挀漀渀漀挀椀洀椀攀渀琀漀 瀀琀椀挀漀搀攀挀愀爀愀挀琀攀爀攀猀䄀挀挀攀猀漀愀猀椀猀琀攀洀愀猀搀攀椀渀昀漀爀洀愀挀椀渀䌀䜀刀䌀漀渀猀甀氀琀愀搀攀戀愀猀攀猀搀攀搀愀琀漀猀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀䌀漀洀瀀爀攀猀椀渀礀攀洀瀀愀焀甀攀琀愀洀椀攀渀琀漀搀攀愀爀挀栀椀瘀漀猀

匀 ㄀㈀㈀

一漀㐀

吀漀琀愀氀㄀㈀㘀

匀 㤀㘀Ⰰ㠀─

一漀㌀Ⰰ㈀─

吀漀琀愀氀㄀　　Ⰰ　─

㄀㄀㤀

㜀

㄀㈀㘀

㤀㐀Ⰰ㐀─

㔀Ⰰ㘀─

㄀　　Ⰰ　─

㠀㄀㘀㠀

㐀㔀㔀㠀

㄀㈀㘀㄀㈀㘀

㘀㐀Ⰰ㌀─ 㔀㐀Ⰰ　─

㌀㔀Ⰰ㜀─ 㐀㘀Ⰰ　─

㄀　　Ⰰ　─ ㄀　　Ⰰ　─

㐀㘀

㠀　

㄀㈀㘀

㌀㘀Ⰰ㔀─

㘀㌀Ⰰ㔀─

㄀　　Ⰰ　─

㄀　㔀

㈀㄀

㄀㈀㘀

㠀㌀Ⰰ㌀─

㄀㘀Ⰰ㜀─

㄀　　Ⰰ　─

㄀　㐀

㈀㈀

㄀㈀㘀

㠀㈀Ⰰ㔀─

㄀㜀Ⰰ㔀─

㄀　　Ⰰ　─

㘀㘀

㘀　

㄀㈀㘀

㔀㈀Ⰰ㐀─

㐀㜀Ⰰ㘀─

㄀　　Ⰰ　─

䤀䤀倀䄀刀吀䔀匀漀戀爀攀渀漀洀愀琀椀瘀愀Ⰰ 瀀氀愀渀攀愀挀椀渀Ⰰ 洀漀搀攀氀漀猀搀攀最攀猀琀椀渀礀挀漀渀琀爀漀氀爀攀氀愀挀椀漀渀愀搀漀猀挀漀渀氀愀猀吀䤀䌀 ✀猀 ⠀一愀挀椀漀渀愀氀攀猀攀䤀渀琀攀爀渀愀挀椀漀渀愀氀攀猀 ⤀ 䰀愀猀爀攀猀瀀甀攀猀琀愀猀椀渀搀椀挀愀渀攀氀最爀愀搀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀攀渀攀氀琀攀洀愀挀漀渀猀甀氀琀愀搀漀刀䔀匀唀䴀䔀一䐀䔀刀䔀匀倀唀䔀匀吀䄀匀一漀爀洀愀猀琀挀渀椀挀愀猀瀀愀爀愀最攀猀琀椀渀礀挀漀渀琀爀漀氀搀攀吀䤀䌀 ✀猀倀䔀吀䤀䌀倀吀䄀䌀䴀䄀䤀 ⠀䴀漀搀攀氀漀搀攀䄀爀焀甀椀琀攀挀琀甀爀愀搀攀䤀渀昀漀爀洀愀挀椀渀⤀ 倀爀漀挀攀猀漀搀攀瘀愀氀漀爀愀挀椀渀搀攀氀刀椀攀猀最漀 ⠀匀䔀嘀刀䤀礀爀椀攀猀最漀猀攀渀吀䤀⤀ 䌀伀匀伀 ⠀䌀漀洀洀椀琀琀攀攀漀昀匀瀀漀渀猀漀爀椀渀最伀爀最愀渀椀稀愀琀椀漀渀猀漀昀琀栀攀吀爀攀愀搀眀愀礀䌀漀洀洀椀猀猀椀漀渀⤀ 䌀伀䈀䤀吀 ⠀䌀漀渀琀爀漀氀漀戀樀攀挀琀椀瘀攀猀昀漀爀䤀渀昀漀爀洀愀琀椀漀渀愀渀搀爀攀氀愀琀攀搀吀攀挀栀渀漀氀漀最礀⤀ 䤀吀䤀䰀 ⠀䤀渀昀漀爀洀愀琀椀漀渀吀攀挀栀渀漀氀漀最礀䤀渀昀爀愀猀琀爀甀挀琀甀爀攀䰀椀戀爀愀爀礀⤀

匀

一漀

吀漀琀愀氀

匀

一漀

吀漀琀愀氀

㐀㈀㌀　㈀㘀

㠀㐀㤀㘀㄀　　

㄀㈀㘀㄀㈀㘀㄀㈀㘀

㌀㌀Ⰰ㌀─ ㈀㌀Ⰰ㠀─ ㈀　Ⰰ㘀─

㘀㘀Ⰰ㜀─ 㜀㘀Ⰰ㈀─ 㜀㤀Ⰰ㐀─

㄀　　Ⰰ　─ ㄀　　Ⰰ　─ ㄀　　Ⰰ　─

㄀㔀

㄀㄀㄀

㄀㈀㘀

㄀㄀Ⰰ㤀─

㠀㠀Ⰰ㄀─

㄀　　Ⰰ　─

㐀㜀

㜀㤀

㄀㈀㘀

㌀㜀Ⰰ㌀─

㘀㈀Ⰰ㜀─

㄀　　Ⰰ　─

㈀㄀

㄀　㔀

㄀㈀㘀

㄀㘀Ⰰ㜀─

㠀㌀Ⰰ㌀─

㄀　　Ⰰ　─

㄀㘀

㄀㄀　

㄀㈀㘀

㄀㈀Ⰰ㜀─

㠀㜀Ⰰ㌀─

㄀　　Ⰰ　─

㤀

㄀㄀㜀

㄀㈀㘀

㜀Ⰰ㄀─

㤀㈀Ⰰ㤀─

㄀　　Ⰰ　─


ANEXO 6

Nivel de aplicación del comportamiento o competencia Encuesta Aplicada en DDI, DEI, DAGJ y en DCA 䌀伀䴀倀䔀吀䔀一䌀䤀䄀

䌀伀䴀倀伀刀吀䄀䴀䤀䔀一吀伀䌀愀瀀愀挀椀搀愀搀搀攀䄀戀猀琀爀愀挀挀椀渀倀䔀一匀䄀䴀䤀䔀一吀伀倀攀爀椀挀椀愀攀渀攀氀洀愀渀攀樀漀搀攀椀渀昀漀爀洀愀挀椀渀匀䤀匀吀 준 䴀䤀䌀伀倀爀漀瀀漀渀攀挀甀爀猀漀猀搀攀愀挀挀椀渀攀渀昀渀搀攀氀爀椀攀猀最漀䘀椀猀挀愀氀椀稀愀挀椀渀搀攀䌀愀氀椀搀愀搀Ⰰ 瀀爀漀洀甀攀瘀攀礀攀渀猀攀愀䄀甀琀漀渀漀洀愀礀爀攀猀瀀漀渀猀愀戀椀氀椀搀愀搀瀀愀爀愀愀氀挀愀渀稀愀爀洀攀琀愀猀䐀愀漀爀椀攀渀琀愀挀椀渀礀攀猀琀愀戀氀攀挀攀瀀爀椀漀爀椀搀愀搀攀猀䰀䤀䐀䔀刀䄀娀䜀伀吀漀洀愀搀攀挀椀猀椀漀渀攀猀愀挀攀爀琀愀搀愀猀礀挀漀渀猀椀猀琀攀渀琀攀猀愀瀀漀礀愀搀漀攀渀氀愀猀吀䤀䌀 ✀猀匀攀最甀爀椀搀愀搀瀀愀爀愀瀀爀漀瀀漀渀攀爀礀搀攀昀攀渀搀攀爀椀搀攀愀猀䌀漀洀甀渀椀挀愀挀椀渀攀猀挀爀椀琀愀挀漀栀攀爀攀渀琀攀Ⰰ 挀氀愀爀愀礀瀀爀攀挀椀猀愀䌀漀洀甀渀椀挀愀挀椀渀漀爀愀氀搀攀洀愀渀攀爀愀挀氀愀爀愀Ⰰ 愀猀攀爀琀椀瘀愀Ⰰ 漀瀀漀爀琀甀渀愀礀攀昀攀挀琀椀瘀愀䌀漀洀甀渀椀挀愀漀瀀漀爀琀甀渀愀洀攀渀琀攀愀猀甀渀琀漀猀猀椀最渀椀昀椀挀愀琀椀瘀漀猀愀猀甀猀猀甀瀀攀爀椀漀爀攀猀礀愀氀攀焀甀椀瀀漀匀漀氀椀挀椀琀愀漀瀀漀爀琀甀渀愀洀攀渀琀攀氀愀愀礀甀搀愀漀攀氀愀猀攀猀漀爀愀洀椀攀渀琀漀搀攀氀愀䌀伀䴀唀一䤀䌀䄀䌀䤀팀一瀀攀爀猀漀渀愀愀瀀爀漀瀀椀愀搀愀匀愀戀攀攀猀挀甀挀栀愀爀礀猀攀椀渀琀攀爀攀猀愀愀甀琀渀琀椀挀愀洀攀渀琀攀攀渀攀猀琀椀洀甀氀愀爀愀氀漀猀挀漀洀瀀愀攀爀漀猀䤀渀琀攀爀愀挀琀切愀愀猀攀爀琀椀瘀愀洀攀渀琀攀挀漀渀猀甀瀀攀爀椀漀爀攀猀 Ⰰ攀焀甀椀瀀漀搀攀琀爀愀戀愀樀漀礀挀漀渀挀氀椀攀渀琀攀猀䔀猀琀愀戀氀攀挀攀礀洀愀渀琀椀攀渀攀爀攀氀愀挀椀漀渀攀猀攀砀椀琀漀猀愀猀愀氀椀渀琀攀爀渀漀礀昀甀攀爀愀搀攀氀愀䌀䜀刀吀爀愀戀愀樀愀搀攀洀愀渀攀爀愀攀昀椀挀椀攀渀琀攀攀渀攀焀甀椀瀀漀猀洀甀氀琀椀搀椀猀挀椀瀀氀椀渀愀爀椀漀猀吀刀䄀䈀䄀䨀伀䔀一礀琀椀攀渀攀昀氀攀砀椀戀椀氀椀搀愀搀䈀爀椀渀搀愀愀瀀漀礀漀愀猀甀瀀攀爀椀漀爀攀猀礀挀漀洀漀洀椀攀洀戀爀漀搀攀氀攀焀甀椀瀀漀䔀儀唀䤀倀　琀椀攀渀攀甀渀渀椀瘀攀氀搀攀琀爀愀戀愀樀漀攀氀攀瘀愀搀漀倀氀愀渀椀昀椀挀愀礀搀攀琀攀爀洀椀渀愀攀渀昀漀爀洀愀爀攀愀氀椀猀琀愀氀漀猀爀攀挀甀爀猀漀猀礀攀氀琀椀攀洀瀀漀渀攀挀攀猀愀爀椀漀猀刀攀愀氀椀稀愀甀渀愀愀搀攀挀甀愀搀愀愀猀椀最渀愀挀椀渀搀攀氀琀爀愀戀愀樀漀攀渀琀爀攀氀漀猀䄀䐀䴀䤀一䤀匀吀刀䄀䌀䤀伀一洀椀攀洀戀爀漀猀搀攀氀攀焀甀椀瀀漀䐀䔀刀䔀䌀唀刀匀伀匀夀吀䤀䔀䴀倀伀刀攀猀瀀攀琀愀礀挀甀洀瀀氀攀氀漀猀瀀氀愀稀漀猀搀攀攀樀攀挀甀挀椀渀攀猀琀愀戀氀攀挀椀搀漀猀匀攀漀爀最愀渀椀稀愀愀搀攀挀甀愀搀愀洀攀渀琀攀瀀愀爀愀愀琀攀渀搀攀爀挀漀渀挀愀氀椀搀愀搀礀瀀爀漀渀琀椀琀甀搀氀愀猀搀椀昀攀爀攀渀琀攀猀氀愀戀漀爀攀猀愀猀椀最渀愀搀愀猀䰀伀䜀刀伀䐀䔀刀䔀匀唀䰀吀䄀䐀伀匀

䤀一一伀嘀䄀䌀䤀팀一

䄀唀吀伀䌀伀一吀刀伀䰀

䠀愀戀椀氀椀搀愀搀瀀愀爀愀琀爀愀戀愀樀愀爀挀漀渀愀甀琀漀渀漀洀愀攀椀洀瀀愀爀挀椀愀氀椀搀愀搀䰀漀最爀愀焀甀攀猀甀瀀爀漀搀甀挀挀椀渀礀氀愀搀攀氀攀焀甀椀瀀漀琀攀渀最愀漀爀搀攀渀Ⰰ 挀愀氀椀搀愀搀Ⰰ 瀀爀攀挀椀猀椀渀礀爀椀最甀爀漀猀椀搀愀搀䄀猀椀洀椀氀愀攀椀渀挀漀爀瀀漀爀愀昀挀椀氀洀攀渀琀攀氀愀愀瀀氀椀挀愀挀椀渀搀攀渀甀攀瘀愀猀吀䤀䌀 ✀猀攀渀氀漀猀琀爀愀戀愀樀漀猀䄀挀琀甀愀氀椀稀愀猀甀猀挀漀渀漀挀椀洀椀攀渀琀漀猀攀渀琀攀洀愀猀搀攀椀渀琀攀爀猀瀀愀爀愀氀愀䤀渀猀琀椀琀甀挀椀渀礀攀渀攀氀甀猀漀搀攀吀䤀䌀 ✀猀䴀愀渀琀椀攀渀攀甀渀戀甀攀渀搀攀猀攀洀瀀攀漀愀切渀攀渀猀椀琀甀愀挀椀漀渀攀猀搀攀洀甀挀栀愀瀀爀攀猀椀渀刀攀挀漀渀漀挀攀昀漀爀琀愀氀攀稀愀猀 Ⰰ 椀搀攀渀琀椀昀椀挀愀猀甀猀攀爀爀漀爀攀猀礀氀椀洀椀琀愀挀椀漀渀攀猀礀琀漀洀愀愀挀挀椀漀渀攀猀瀀愀爀愀洀攀樀漀爀愀爀

䄀挀甀洀甀氀愀搀漀一䄀䈀愀樀漀一䄀礀䈀愀樀漀㄀㐀Ⰰ㌀─ ㌀Ⰰ㈀─ ㄀㄀Ⰰ㄀─ ㄀㐀Ⰰ㌀─ 㔀Ⰰ㘀─ 㠀Ⰰ㜀─ ㄀㤀Ⰰ　─ 㤀Ⰰ㔀─ 㤀Ⰰ㔀─ ㈀㌀Ⰰ　─ ㄀㄀Ⰰ㤀─ ㄀㄀Ⰰ㄀─ 㘀Ⰰ㌀─ 㐀Ⰰ　─ ㈀Ⰰ㐀─ 㜀㌀Ⰰ㠀─ 㜀㈀Ⰰ㈀─ ㄀Ⰰ㘀─

䄀挀甀洀甀氀愀搀漀䴀攀搀椀漀一䄀ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㔀㤀Ⰰ㔀─ 㐀㔀Ⰰ㈀─ 㔀㜀Ⰰ㤀─ 㐀㌀Ⰰ㜀─ 㘀㄀Ⰰ㄀─ 㐀㈀Ⰰ㄀─ 㘀㈀Ⰰ㜀─ ㌀㤀Ⰰ㜀─ ㈀㤀Ⰰ㐀─ ㈀㌀Ⰰ　─ 㠀㈀Ⰰ㔀─ 㠀Ⰰ㜀─

㄀㤀Ⰰ　─ ㄀㌀Ⰰ㔀─ 㐀Ⰰ㠀─ 㜀Ⰰ㄀─ ㈀Ⰰ㐀─ 㜀Ⰰ㄀─

㌀㈀Ⰰ㔀─ ㄀㄀Ⰰ㤀─ 㤀Ⰰ㔀─

㌀㜀Ⰰ㌀─ ㈀㤀Ⰰ㐀─ ㌀㠀Ⰰ㄀─

㘀㤀Ⰰ㠀─ 㐀㄀Ⰰ㌀─ 㐀㜀Ⰰ㘀─

㄀Ⰰ㘀─

㜀Ⰰ㄀─

㠀Ⰰ㜀─

㐀㈀Ⰰ㤀─

㔀㄀Ⰰ㘀─

㈀Ⰰ㐀─

㌀Ⰰ㈀─

㔀Ⰰ㘀─

㌀㄀Ⰰ　─

㌀㘀Ⰰ㔀─

㄀Ⰰ㘀─

㈀Ⰰ㐀─

㐀Ⰰ　─

㈀　Ⰰ㘀─

㈀㐀Ⰰ㘀─

㐀Ⰰ　─

㈀Ⰰ㐀─

㘀Ⰰ㌀─

㈀㤀Ⰰ㐀─

㌀㔀Ⰰ㜀─

㄀Ⰰ㘀─

㐀Ⰰ　─

㔀Ⰰ㘀─

㈀㤀Ⰰ㐀─

㌀㐀Ⰰ㤀─

㈀Ⰰ㐀─

㄀Ⰰ㘀─

㐀Ⰰ　─

㈀㘀Ⰰ㈀─

㌀　Ⰰ㈀─

㔀Ⰰ㘀─

㈀Ⰰ㐀─

㜀Ⰰ㤀─

㈀㄀Ⰰ㐀─

㈀㤀Ⰰ㐀─

㌀Ⰰ㈀─

㈀Ⰰ㐀─

㔀Ⰰ㘀─

㈀㈀Ⰰ㈀─

㈀㜀Ⰰ㠀─

㌀Ⰰ㈀─

㔀Ⰰ㘀─

㠀Ⰰ㜀─

㌀㠀Ⰰ㄀─

㐀㘀Ⰰ㠀─

㘀㠀Ⰰ㌀─

㄀Ⰰ㘀─

㘀㤀Ⰰ㠀─

㄀㐀Ⰰ㌀─

㠀㐀Ⰰ㄀─

㐀Ⰰ㠀─

㄀Ⰰ㘀─

㘀Ⰰ㌀─

㌀　Ⰰ㈀─

㌀㘀Ⰰ㔀─

㌀Ⰰ㈀─

㈀Ⰰ㐀─

㔀Ⰰ㘀─

㈀㐀Ⰰ㘀─

㌀　Ⰰ㈀─

㈀Ⰰ㐀─

㌀Ⰰ㈀─

㔀Ⰰ㘀─

㈀㄀Ⰰ㐀─

㈀㜀Ⰰ　─

㘀Ⰰ㌀─

㈀Ⰰ㐀─

㠀Ⰰ㜀─

㌀㈀Ⰰ㔀─

㐀㄀Ⰰ㌀─

㐀Ⰰ㠀─

㠀Ⰰ㜀─

㄀㌀Ⰰ㔀─

㌀㐀Ⰰ㤀─

㐀㠀Ⰰ㐀─

㈀Ⰰ㐀─

㄀㄀Ⰰ㤀─

㄀㐀Ⰰ㌀─

㐀㈀Ⰰ㄀─

㔀㘀Ⰰ㌀─

㈀Ⰰ㐀─

㈀Ⰰ㐀─

㐀Ⰰ㠀─

㈀㠀Ⰰ㘀─

㌀㌀Ⰰ㌀─

㄀Ⰰ㘀─

㈀Ⰰ㐀─

㐀Ⰰ　─

㌀㈀Ⰰ㔀─

㌀㘀Ⰰ㔀─


匀漀戀爀攀吀䤀匀漀戀爀攀吀䤀


ANEXO 7

Grado de Conocimientos sobre TIC’s Encuesta Aplicada en USTI 䤀䤀倀䄀刀吀䔀䤀一䘀伀刀䴀䄀䌀䤀팀一䔀匀倀䔀䌀 촀䘀䤀䌀䄀匀伀䈀刀䔀䌀伀一伀䌀䤀䴀䤀䔀一吀伀匀䔀一吀䤀䌀 ✀猀䰀愀猀爀攀猀瀀甀攀猀琀愀猀椀渀搀椀挀愀渀攀氀最爀愀搀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀攀渀攀氀琀攀洀愀挀漀渀猀甀氀琀愀搀漀刀䔀匀唀䴀䔀一䐀䔀刀䔀匀倀唀䔀匀吀䄀匀䌀愀猀漀猀唀猀漀礀倀爀甀攀戀愀倀䠀倀䨀䄀嘀䄀伀刀䄀䌀䰀䔀䄀搀洀䈀愀猀攀猀搀攀䐀愀琀漀猀匀攀最甀爀椀搀愀搀攀渀吀䤀䌀 ✀猀䄀搀洀搀攀刀攀搀攀猀䔀渀刀唀倀䄀搀洀吀攀氀攀昀漀渀愀匀漀昀琀唀猀甀愀爀椀漀䘀椀渀愀氀䄀搀洀搀攀䌀漀爀爀攀漀䄀搀洀搀攀倀爀漀礀攀挀琀漀猀䜀攀猀琀椀渀搀攀吀䤀䌀 ✀猀䜀攀猀琀椀渀䌀愀氀椀搀愀搀攀渀吀䤀䌀 ✀猀

一椀渀最甀渀漀㌀　Ⰰ　─ 㘀㔀Ⰰ　─ ㌀㔀Ⰰ　─ ㈀　Ⰰ　─ ㈀㔀Ⰰ　─ ㄀㔀Ⰰ　─ ㈀　Ⰰ　─ 㘀㔀Ⰰ　─ 㘀　Ⰰ　─ 㔀Ⰰ　─ 㐀　Ⰰ　─ ㄀㔀Ⰰ　─ 　Ⰰ　─ 㔀Ⰰ　─

䈀愀樀漀一椀渀最礀䈀愀樀漀䴀攀搀椀漀一椀渀最ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㠀　Ⰰ　─ 㘀㔀Ⰰ　─ ㄀㔀Ⰰ　─ ㌀㔀Ⰰ　─ 㜀㔀Ⰰ　─ 㤀　Ⰰ　─ ㄀　Ⰰ　─ ㄀㔀Ⰰ　─ 㠀　Ⰰ　─ 㤀㔀Ⰰ　─ 㐀㔀Ⰰ　─ ㄀㔀Ⰰ　─ ㈀㔀Ⰰ　─ 㐀㔀Ⰰ　─ 㔀Ⰰ　─ ㈀　Ⰰ　─ ㌀㔀Ⰰ　─ 㠀　Ⰰ　─ ㄀　Ⰰ　─ 㐀㔀Ⰰ　─ 㤀　Ⰰ　─ 㔀　Ⰰ　─ 㐀　Ⰰ　─ ㌀㔀Ⰰ　─ ㄀　　Ⰰ　─ 㘀　Ⰰ　─ 㐀　Ⰰ　─ 㐀　Ⰰ　─ ㄀　　Ⰰ　─ 㤀　Ⰰ　─ ㄀　Ⰰ　─ ㈀㔀Ⰰ　─ ㄀　　Ⰰ　─ 㤀㔀Ⰰ　─ 㔀Ⰰ　─ ㌀㔀Ⰰ　─ ㄀㔀Ⰰ　─ 㘀㔀Ⰰ　─ ㄀　Ⰰ　─ 㔀　Ⰰ　─ 㘀　Ⰰ　─ 㠀㔀Ⰰ　─ ㈀　Ⰰ　─ ㈀㔀Ⰰ　─ ㌀　Ⰰ　─ 㠀㔀Ⰰ　─ ㄀㔀Ⰰ　─ 㔀㔀Ⰰ　─ 㤀　Ⰰ　─ 㔀　Ⰰ　─ 㐀　Ⰰ　─ 㔀　Ⰰ　─ 㔀　Ⰰ　─ 㤀　Ⰰ　─ 㐀㔀Ⰰ　─ 㐀　Ⰰ　─


ANEXO 8

Nivel de aplicación del comportamiento o competencia Encuesta Aplicada en DDI, DEI, DAGJ y en DCA 䌀伀䴀倀䔀吀䔀一䌀䤀䄀

䌀伀䴀倀伀刀吀䄀䴀䤀䔀一吀伀䌀愀瀀愀挀椀搀愀搀搀攀䄀戀猀琀爀愀挀挀椀渀倀攀爀椀挀椀愀攀渀攀氀洀愀渀攀樀漀搀攀椀渀昀漀爀洀愀挀椀渀倀爀漀瀀漀渀攀挀甀爀猀漀猀搀攀愀挀挀椀渀攀渀昀渀搀攀氀爀椀攀猀最漀䘀椀猀挀愀氀椀稀愀挀椀渀搀攀䌀愀氀椀搀愀搀Ⰰ 瀀爀漀洀甀攀瘀攀礀攀渀猀攀愀䄀甀琀漀渀漀洀愀礀爀攀猀瀀漀渀猀愀戀椀氀椀搀愀搀瀀愀爀愀愀氀挀愀渀稀愀爀洀攀琀愀猀䐀愀漀爀椀攀渀琀愀挀椀渀礀攀猀琀愀戀氀攀挀攀瀀爀椀漀爀椀搀愀搀攀猀䰀䤀䐀䔀刀䄀娀䜀伀吀漀洀愀搀攀挀椀猀椀漀渀攀猀愀挀攀爀琀愀搀愀猀礀挀漀渀猀椀猀琀攀渀琀攀猀愀瀀漀礀愀搀漀攀渀氀愀猀吀䤀䌀 ✀猀匀攀最甀爀椀搀愀搀瀀愀爀愀瀀爀漀瀀漀渀攀爀礀搀攀昀攀渀搀攀爀椀搀攀愀猀䌀漀洀甀渀椀挀愀挀椀渀攀猀挀爀椀琀愀挀漀栀攀爀攀渀琀攀Ⰰ 挀氀愀爀愀礀瀀爀攀挀椀猀愀䌀漀洀甀渀椀挀愀挀椀渀漀爀愀氀搀攀洀愀渀攀爀愀挀氀愀爀愀Ⰰ 愀猀攀爀琀椀瘀愀Ⰰ 漀瀀漀爀琀甀渀愀礀攀昀攀挀琀椀瘀愀䌀漀洀甀渀椀挀愀漀瀀漀爀琀甀渀愀洀攀渀琀攀愀猀甀渀琀漀猀猀椀最渀椀昀椀挀愀琀椀瘀漀猀愀猀甀猀猀甀瀀攀爀椀漀爀攀猀礀愀氀攀焀甀椀瀀漀匀漀氀椀挀椀琀愀漀瀀漀爀琀甀渀愀洀攀渀琀攀氀愀愀礀甀搀愀漀攀氀愀猀攀猀漀爀愀洀椀攀渀琀漀搀攀氀愀䌀伀䴀唀一䤀䌀䄀䌀䤀팀一瀀攀爀猀漀渀愀愀瀀爀漀瀀椀愀搀愀匀愀戀攀攀猀挀甀挀栀愀爀礀猀攀椀渀琀攀爀攀猀愀愀甀琀渀琀椀挀愀洀攀渀琀攀攀渀攀猀琀椀洀甀氀愀爀愀氀漀猀挀漀洀瀀愀攀爀漀猀䤀渀琀攀爀愀挀琀切愀愀猀攀爀琀椀瘀愀洀攀渀琀攀挀漀渀猀甀瀀攀爀椀漀爀攀猀 Ⰰ攀焀甀椀瀀漀搀攀琀爀愀戀愀樀漀礀挀漀渀挀氀椀攀渀琀攀猀䔀猀琀愀戀氀攀挀攀礀洀愀渀琀椀攀渀攀爀攀氀愀挀椀漀渀攀猀攀砀椀琀漀猀愀猀愀氀椀渀琀攀爀渀漀礀昀甀攀爀愀搀攀氀愀䌀䜀刀吀爀愀戀愀樀愀搀攀洀愀渀攀爀愀攀昀椀挀椀攀渀琀攀攀渀攀焀甀椀瀀漀猀洀甀氀琀椀搀椀猀挀椀瀀氀椀渀愀爀椀漀猀吀刀䄀䈀䄀䨀伀䔀一礀琀椀攀渀攀昀氀攀砀椀戀椀氀椀搀愀搀䈀爀椀渀搀愀愀瀀漀礀漀愀猀甀瀀攀爀椀漀爀攀猀礀挀漀洀漀洀椀攀洀戀爀漀搀攀氀攀焀甀椀瀀漀䔀儀唀䤀倀　琀椀攀渀攀甀渀渀椀瘀攀氀搀攀琀爀愀戀愀樀漀攀氀攀瘀愀搀漀倀氀愀渀椀昀椀挀愀礀搀攀琀攀爀洀椀渀愀攀渀昀漀爀洀愀爀攀愀氀椀猀琀愀氀漀猀爀攀挀甀爀猀漀猀礀攀氀琀椀攀洀瀀漀渀攀挀攀猀愀爀椀漀猀䄀䐀䴀䤀一䤀匀吀刀䄀䌀䤀伀一刀攀愀氀椀稀愀甀渀愀愀搀攀挀甀愀搀愀愀猀椀最渀愀挀椀渀搀攀氀琀爀愀戀愀樀漀攀渀琀爀攀氀漀猀䐀䔀刀䔀䌀唀刀匀伀匀夀洀椀攀洀戀爀漀猀搀攀氀攀焀甀椀瀀漀刀攀猀瀀攀琀愀礀挀甀洀瀀氀攀氀漀猀瀀氀愀稀漀猀搀攀攀樀攀挀甀挀椀渀攀猀琀愀戀氀攀挀椀搀漀猀吀䤀䔀䴀倀伀匀攀漀爀最愀渀椀稀愀愀搀攀挀甀愀搀愀洀攀渀琀攀瀀愀爀愀愀琀攀渀搀攀爀挀漀渀挀愀氀椀搀愀搀礀瀀爀漀渀琀椀琀甀搀氀愀猀搀椀昀攀爀攀渀琀攀猀氀愀戀漀爀攀猀愀猀椀最渀愀搀愀猀䠀愀戀椀氀椀搀愀搀瀀愀爀愀琀爀愀戀愀樀愀爀挀漀渀愀甀琀漀渀漀洀愀攀椀洀瀀愀爀挀椀愀氀椀搀愀搀䰀伀䜀刀伀䐀䔀䰀漀最爀愀焀甀攀猀甀瀀爀漀搀甀挀挀椀渀礀氀愀搀攀氀攀焀甀椀瀀漀琀攀渀最愀漀爀搀攀渀Ⰰ 刀䔀匀唀䰀吀䄀䐀伀匀挀愀氀椀搀愀搀Ⰰ 瀀爀攀挀椀猀椀渀礀爀椀最甀爀漀猀椀搀愀搀䄀猀椀洀椀氀愀攀椀渀挀漀爀瀀漀爀愀昀挀椀氀洀攀渀琀攀氀愀愀瀀氀椀挀愀挀椀渀搀攀渀甀攀瘀愀猀吀䤀䌀 ✀猀攀渀氀漀猀琀爀愀戀愀樀漀猀䤀一一伀嘀䄀䌀䤀팀一䄀挀琀甀愀氀椀稀愀猀甀猀挀漀渀漀挀椀洀椀攀渀琀漀猀攀渀琀攀洀愀猀搀攀椀渀琀攀爀猀瀀愀爀愀氀愀䤀渀猀琀椀琀甀挀椀渀礀攀渀攀氀甀猀漀搀攀吀䤀䌀 ✀猀䴀愀渀琀椀攀渀攀甀渀戀甀攀渀搀攀猀攀洀瀀攀漀愀切渀攀渀猀椀琀甀愀挀椀漀渀攀猀搀攀洀甀挀栀愀瀀爀攀猀椀渀䄀唀吀伀䌀伀一吀刀伀䰀刀攀挀漀渀漀挀攀昀漀爀琀愀氀攀稀愀猀 Ⰰ 椀搀攀渀琀椀昀椀挀愀猀甀猀攀爀爀漀爀攀猀礀氀椀洀椀琀愀挀椀漀渀攀猀礀琀漀洀愀愀挀挀椀漀渀攀猀瀀愀爀愀洀攀樀漀爀愀爀倀䔀一匀䄀䴀䤀䔀一吀伀匀䤀匀吀 준 䴀䤀䌀伀

一䄀䈀愀樀漀一䄀礀䈀愀樀漀㄀　Ⰰ　─ 㔀Ⰰ　─ 㔀Ⰰ　─ 　Ⰰ　─ 　Ⰰ　─ 　Ⰰ　─ 㔀Ⰰ　─ 㔀Ⰰ　─ 　Ⰰ　─ ㌀　Ⰰ　─ ㄀㔀Ⰰ　─ ㄀㔀Ⰰ　─ 　Ⰰ　─ 　Ⰰ　─ 　Ⰰ　─ 㘀㔀Ⰰ　─ 㘀　Ⰰ　─ 㔀Ⰰ　─

䴀攀搀椀漀一䄀ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㘀㔀Ⰰ　─ 㔀㔀Ⰰ　─ 㘀　Ⰰ　─ 㘀　Ⰰ　─ 㘀㔀Ⰰ　─ 㘀　Ⰰ　─ 㜀　Ⰰ　─ 㐀　Ⰰ　─ 㔀　Ⰰ　─ 㔀　Ⰰ　─ 㠀㔀Ⰰ　─ ㈀　Ⰰ　─

㄀　Ⰰ　─ 　Ⰰ　─ 　Ⰰ　─

　Ⰰ　─ 㔀Ⰰ　─ 　Ⰰ　─

㄀　Ⰰ　─ 㔀Ⰰ　─ 　Ⰰ　─

㘀㔀Ⰰ　─ ㌀　Ⰰ　─ 㔀　Ⰰ　─

㜀㔀Ⰰ　─ ㌀㔀Ⰰ　─ 㔀　Ⰰ　─

　Ⰰ　─

㔀Ⰰ　─

㔀Ⰰ　─

㔀　Ⰰ　─

㔀㔀Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㔀㔀Ⰰ　─

㔀㔀Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㈀㔀Ⰰ　─

㈀㔀Ⰰ　─

　Ⰰ　─

㔀Ⰰ　─

㔀Ⰰ　─

㐀　Ⰰ　─

㐀㔀Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㐀㔀Ⰰ　─

㐀㔀Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㐀　Ⰰ　─

㐀　Ⰰ　─

㄀　Ⰰ　─

　Ⰰ　─

㄀　Ⰰ　─

㌀㔀Ⰰ　─

㐀㔀Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㌀　Ⰰ　─

㌀　Ⰰ　─

　Ⰰ　─

㔀Ⰰ　─

㔀Ⰰ　─

㜀㔀Ⰰ　─

㠀　Ⰰ　─

㜀㔀Ⰰ　─ 　Ⰰ　─

㔀Ⰰ　─ 　Ⰰ　─

㠀　Ⰰ　─ 　Ⰰ　─

㄀㔀Ⰰ　─ 㐀㔀Ⰰ　─

㤀㔀Ⰰ　─ 㐀㔀Ⰰ　─

　Ⰰ　─ 　Ⰰ　─

　Ⰰ　─ 　Ⰰ　─

　Ⰰ　─ 　Ⰰ　─

㌀㔀Ⰰ　─ ㌀　Ⰰ　─

㌀㔀Ⰰ　─ ㌀　Ⰰ　─

　Ⰰ　─

㔀Ⰰ　─

㔀Ⰰ　─

㐀㔀Ⰰ　─

㔀　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㌀　Ⰰ　─

㌀　Ⰰ　─

　Ⰰ　─

㄀　Ⰰ　─

㄀　Ⰰ　─

㈀㔀Ⰰ　─

㌀㔀Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㌀　Ⰰ　─

㌀　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

　Ⰰ　─

㌀　Ⰰ　─

㌀　Ⰰ　─


匀漀戀爀攀吀䤀匀漀戀爀攀吀䤀


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 䴀愀渀攀樀漀攀氀攀挀琀爀渀椀挀漀搀攀琀攀砀琀漀猀䄀瀀漀礀漀攀渀氀愀戀漀爀攀猀搀攀漀昀椀挀椀渀愀一攀挀攀猀椀搀愀搀攀猀搀攀搀椀最椀琀愀氀椀稀愀挀椀渀 ⠀瀀愀猀漀愀昀漀爀洀愀琀漀攀氀攀挀琀爀渀椀挀漀⤀ 搀攀搀漀挀甀洀攀渀琀漀猀䴀愀渀攀樀漀搀攀瀀爀攀猀攀渀琀愀挀椀漀渀攀猀攀樀攀挀甀琀椀瘀愀猀 ⸀ 䌀漀渀猀甀氀琀愀搀攀戀愀猀攀猀搀攀搀愀琀漀猀漀搀攀挀漀渀漀挀椀洀椀攀渀琀漀⸀ 䄀挀挀攀猀漀愀猀椀猀琀攀洀愀猀搀攀椀渀昀漀爀洀愀挀椀渀䴀愀渀攀樀漀搀攀栀漀樀愀猀搀攀挀氀挀甀氀漀⸀ 䴀愀渀攀樀漀搀攀椀洀最攀渀攀猀䴀愀渀攀樀漀搀攀瘀椀搀攀漀猀 ⸀ 䴀愀渀攀樀漀搀攀愀甀搀椀漀⸀ 䴀愀渀攀樀漀搀攀愀爀挀栀椀瘀漀猀 ⸀ 䴀愀渀攀樀漀搀攀氀愀猀攀最甀爀椀搀愀搀搀攀氀愀椀渀昀漀爀洀愀挀椀渀⸀ 唀猀漀椀渀琀攀渀猀椀瘀漀搀攀氀挀漀爀爀攀漀Ⰰ 攀氀椀洀椀渀愀爀渀漀琀愀猀 Ⰰ 挀漀洀瀀愀爀琀椀爀愀最攀渀搀愀倀䐀䘀伀瀀攀渀伀昀昀椀挀攀匀䤀匀吀䔀䴀䄀匀

匀䤀䄀䌀一伀刀䴀䄀吀䤀嘀䄀匀䤀匀吀䔀䴀䄀䤀一䘀伀刀䴀䄀䌀䤀팀一䰀䔀䜀䤀匀䰀䄀吀䤀嘀伀䔀堀倀䔀䐀䤀䔀一吀䔀䐀䤀䜀䤀吀䄀䰀䌀伀䴀倀刀䄀匀䌀伀䴀倀䔀一䐀䤀伀匀匀䤀䜀夀䐀匀椀猀琀攀洀愀猀搀攀挀氀愀瘀攀猀䌀漀渀昀椀最甀爀愀挀椀渀攀椀渀猀琀愀氀愀挀椀渀搀攀椀洀瀀爀攀猀漀爀愀猀匀椀猀琀攀洀愀猀瀀愀爀愀昀甀渀挀椀漀渀愀爀椀漀猀䐀漀挀甀洀攀渀琀愀挀椀渀礀匀攀爀瘀椀挀椀漀猀搀攀氀愀圀攀戀

匀攀爀瘀椀挀椀漀猀匀漀挀椀愀氀攀猀

匀攀最甀椀洀椀攀渀琀漀搀攀䐀椀猀瀀漀猀椀挀椀漀渀攀猀

倀爀椀漀爀⸀ 匀攀挀爀攀琀愀爀愀吀 挀渀椀挀愀匀攀爀瘀椀挀椀漀猀搀攀䄀搀洀椀渀椀猀琀爀愀挀椀渀䘀椀渀愀渀挀椀攀爀愀匀攀爀瘀椀挀椀漀猀䴀甀渀椀挀椀瀀愀氀攀猀匀攀爀瘀椀挀椀漀猀䔀挀漀渀洀椀挀漀猀瀀愀爀愀攀氀䐀攀猀愀爀爀漀氀氀漀匀攀爀瘀椀挀椀漀猀搀攀伀戀爀愀倀切戀氀椀挀愀匀攀爀瘀椀挀椀漀猀倀切戀氀椀挀漀猀䜀攀渀攀爀愀氀攀猀䄀洀戀椀攀渀琀愀氀攀猀礀䄀最爀漀瀀⸀ 䐀攀渀甀渀挀椀愀猀礀䐀攀挀氀愀爀愀挀椀漀渀攀猀䨀甀爀愀搀愀猀

䌀漀渀琀爀愀琀愀挀椀渀䄀搀洀椀渀椀猀琀爀愀琀椀瘀愀

唀渀椀搀愀搀搀攀匀攀爀瘀椀挀椀漀猀䜀攀渀攀爀愀氀攀猀䜀攀爀攀渀挀椀愀䄀搀洀椀渀椀猀琀爀愀琀椀瘀愀䐀攀猀瀀愀挀栀漀䌀漀渀琀爀愀氀漀爀愀礀匀甀戀挀漀渀琀爀愀氀漀爀愀䜀攀爀攀渀挀椀愀猀䄀甀搀椀琀漀爀愀䤀渀琀攀爀渀愀

唀渀椀搀愀搀搀攀匀攀爀瘀椀挀椀漀猀搀攀倀爀漀瘀攀攀搀甀爀愀

唀渀椀搀愀搀搀攀匀攀爀瘀椀挀椀漀猀䘀椀渀愀渀挀椀攀爀漀猀

刀攀挀甀爀猀漀猀䠀甀洀愀渀漀猀䌀攀渀琀爀漀搀攀䌀愀瀀愀挀椀琀愀挀椀渀䜀攀爀攀渀挀椀愀搀攀唀渀椀搀愀搀搀攀倀爀攀渀猀愀礀䔀猀琀爀愀琀攀最椀愀䌀漀洀甀渀椀挀愀挀椀渀䤀渀猀琀椀琀甀挀椀漀渀愀氀唀渀椀搀愀搀搀攀䐀攀猀愀爀爀漀氀氀漀伀爀最愀渀椀稀愀挀椀漀渀愀氀匀攀爀瘀椀挀椀漀猀搀攀䤀渀昀漀爀洀愀挀椀渀匀椀猀琀攀洀愀猀礀吀攀挀渀漀氀漀最愀猀搀攀䜀攀爀攀渀挀椀愀搀攀䐀攀猀愀爀爀漀氀氀漀䤀渀昀漀爀洀愀挀椀渀

䌀漀渀琀爀愀琀愀挀椀渀䄀搀洀椀渀椀猀琀爀愀琀椀瘀愀

䄀猀攀猀漀爀椀愀礀䄀猀攀猀漀爀椀愀礀䜀攀猀琀椀渀䨀甀爀椀搀椀挀愀䜀攀猀琀椀渀䨀甀爀椀搀椀挀愀

䘀椀猀挀愀氀椀稀愀挀椀渀伀瀀攀爀愀琀椀瘀愀礀䔀瘀愀氀甀愀琀椀瘀愀

䐀䤀嘀䤀匀䤀伀一䔀匀

唀渀椀搀愀搀攀猀䘀甀渀挀椀漀渀愀氀攀猀䌀㴀䌀伀一匀唀䰀吀䄀刀㴀刀䔀䜀䤀匀吀刀伀一㴀一漀爀攀焀甀椀攀爀攀渀䌀愀瀀愀挀 ⸀

䌀䌀

䌀䌀

䌀䌀䌀

刀

刀

䌀䌀䌀

䌀

䌀

䌀

䌀䌀

䌀䌀

䌀䌀

䌀䌀

䌀䌀

䌀䌀

䌀䌀

䌀

䌀

䌀䌀

䌀䌀

愀椀搀椀瘀挀琀

搀

䌀䌀䌀

䌀

䌀

䌀䌀

䌀

䌀

䌀䌀

䌀䌀

漀氀椀挀切戀

猀

䌀䌀

䌀

䌀䌀

䌀

䌀

䌀䌀

䌀䌀

漀氀椀挀切戀

猀

䌀䌀

䌀

䌀

䌀䌀

䌀

䌀

䌀䌀

䌀䌀

刀

刀

刀刀

刀

刀刀

刀

刀

刀

刀刀

刀刀

刀

刀刀刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

䌀䌀䌀

䌀

䌀

䌀

䌀

䌀䌀

䌀

䌀䌀䌀

䌀

䌀䌀

䌀

䌀

䌀䌀

䌀䌀

刀刀刀

刀

刀

刀

刀

刀刀

刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

刀刀刀

刀

刀

刀

刀

刀刀

刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

刀刀刀

刀

刀

刀

刀

刀刀

刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

刀刀刀

刀

刀

刀

刀

刀刀

刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

刀刀刀

刀

刀

刀

刀

刀刀

刀

刀刀刀

刀

刀刀

刀

刀

刀刀

刀刀

猀吀䐀愀猀漀猀礀猀琀猀搀漀 ⴀ 䴀琀椀瘀琀漀攀猀甀攀渀愀猀愀渀渀攀猀挀爀漀攀猀琀攀椀漀渀椀攀椀挀渀椀漀椀猀洀攀渀挀椀漀琀椀挀䈀䄀椀挀愀渀搀椀渀䄀倀攀倀椀猀挀甀椀 搀攀爀瘀愀爀 ⠀촀 匀愀搀攀氀愀氀戀爀漀猀氀愀氀猀漀猀搀洀嘀攀挀渀攀渀瀀椀渀 ⤀ 䐀漀樀漀匀攀猀琀攀搀搀攀琀甀愀猀漀攀猀琀䄀  椀搀攀琀甀愀搀  愀椀椀漀礀攀搀猀攀猀椀瘀挀爀椀䘀甀椀挀愀挀搀攀攀猀愀挀攀猀瀀甀琀爀漀挀琀爀漀愀琀稀愀琀愀 渀䐀氀搀椀猀椀挀椀漀椀琀攀椀琀攀漀猀甀瀀漀爀愀椀猀琀爀愀椀猀爀洀琀爀爀洀猀甀洀愀氀椀攀琀椀夀爀琀愀焀甀爀瘀琀椀瘀洀攀猀 洀 洀愀戀昀漀漀渀昀漀攀攀最漀渀攀最漀爀挀愀挀攀猀䜀刀䌀䤀渀䌀倀爀䤀渀倀爀刀一昀椀猀䜀䜀匀䤀吀漀倀漀䄀搀匀攀䄀挀吀爀吀爀䔀氀䄀䄀䄀䄀䄀䄀䌀䌀䄀䌀䌀䈀䌀䈀䌀䌀䌀䌀䌀䌀刀刀䌀刀刀刀刀刀愀搀椀搀椀瘀挀琀


ANEXO 11

Conocimientos sobre los Sistemas de la CGR Según entrevista realizada al coordinador de desarrollo de sistemas de la USTI


ANEXO 12

Resumen de comportamientos relacionados con la aplicación de TIC’s Encuestas realizadas a la DFOE, DDI, DEI, DAGJ, DCA, USTI 䌀伀䴀倀䔀吀䔀一䌀䤀䄀䌀伀䴀倀伀刀吀䄀䴀䤀䔀一吀伀䰀䤀䐀䔀刀䄀娀䜀伀

吀漀洀愀搀攀挀椀猀椀漀渀攀猀愀挀攀爀琀愀搀愀猀礀挀漀渀猀椀猀琀攀渀琀攀猀愀瀀漀礀愀搀漀攀渀氀愀猀吀䤀䌀 ✀猀

䐀椀瘀椀猀椀渀⼀唀渀椀搀愀搀䐀䘀伀䔀䐀䐀䤀Ⰰ䐀䔀䤀Ⰰ 䐀䄀䜀䨀 Ⰰ 䐀䌀䄀唀匀吀䤀吀漀琀愀氀攀猀

一䄀

䈀愀樀漀

㄀㈀Ⰰ㤀─ 㠀Ⰰ㜀─ ㄀㤀Ⰰ　─ ㄀㌀Ⰰ㔀─ ㄀　Ⰰ　─ 　Ⰰ　─ ㄀㐀Ⰰ㘀─ 㤀Ⰰ㜀─

一䄀ⴀ䈀愀樀漀䴀攀搀椀漀一䄀ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㈀㄀Ⰰ㜀─ ㌀㈀Ⰰ㔀─ ㄀　Ⰰ　─ ㈀㐀Ⰰ㌀─

㐀㘀Ⰰ㈀─ ㌀㜀Ⰰ㌀─ 㘀㔀Ⰰ　─ 㐀㐀Ⰰ㐀─

㘀㜀Ⰰ㠀─ 㘀㤀Ⰰ㠀─ 㜀㔀Ⰰ　─ 㘀㠀Ⰰ㠀─

䌀伀䴀倀䔀吀䔀一䌀䤀䄀䌀伀䴀倀伀刀吀䄀䴀䤀䔀一吀伀

一䄀㐀Ⰰ㤀─ 㐀Ⰰ㠀─ 　Ⰰ　─ 㐀Ⰰ㘀─

䈀愀樀漀㤀Ⰰ㄀─ 㠀Ⰰ㜀─ 　Ⰰ　─ 㠀Ⰰ㘀─

一䄀ⴀ䈀愀樀漀㄀㐀Ⰰ　─ ㄀㌀Ⰰ㔀─ 　Ⰰ　─ ㄀㌀Ⰰ㈀─

䴀攀搀椀漀一䄀ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㐀㜀Ⰰ㈀─ 㘀㄀Ⰰ㈀─ ㌀㐀Ⰰ㤀─ 㐀㠀Ⰰ㐀─ ㌀　Ⰰ　─ ㌀　Ⰰ　─ 㐀㈀Ⰰ㠀─ 㔀㘀Ⰰ　─

䌀伀䴀倀䔀吀䔀一䌀䤀䄀䌀伀䴀倀伀刀吀䄀䴀䤀䔀一吀伀

一䄀㌀Ⰰ㄀─ ㈀Ⰰ㐀─ 　Ⰰ　─ ㈀Ⰰ㠀─

䈀愀樀漀一䄀ⴀ䈀愀樀漀㄀㌀Ⰰ㘀─ ㄀㘀Ⰰ㠀─ ㄀㄀Ⰰ㤀─ ㄀㐀Ⰰ㌀─ ㄀　Ⰰ　─ ㄀　Ⰰ　─ ㄀㌀Ⰰ　─ ㄀㔀Ⰰ㜀─

䴀攀搀椀漀一䄀ⴀ䈀愀樀漀ⴀ䴀攀搀椀漀㐀㤀Ⰰ㌀─ 㘀㘀Ⰰ㄀─ 㐀㈀Ⰰ㄀─ 㔀㘀Ⰰ㌀─ ㈀㔀Ⰰ　─ ㌀㔀Ⰰ　─ 㐀㘀Ⰰ㄀─ 㘀㄀Ⰰ㠀─

䐀椀瘀椀猀椀渀⼀唀渀椀搀愀搀䐀䘀伀䔀䄀猀椀洀椀氀愀攀椀渀挀漀爀瀀漀爀愀昀挀椀氀洀攀渀琀攀氀愀䐀䐀䤀Ⰰ䐀䔀䤀Ⰰ 䐀䄀䜀䨀 Ⰰ 䐀䌀䄀䤀一一伀嘀䄀䌀䤀팀一愀瀀氀椀挀愀挀椀渀搀攀渀甀攀瘀愀猀吀䤀䌀 ✀猀攀渀唀匀吀䤀氀漀猀琀爀愀戀愀樀漀猀吀漀琀愀氀攀猀䐀椀瘀椀猀椀渀⼀唀渀椀搀愀搀䐀䘀伀䔀䄀挀琀甀愀氀椀稀愀猀甀猀挀漀渀漀挀椀洀椀攀渀琀漀猀攀渀䐀䐀䤀Ⰰ䐀䔀䤀Ⰰ 䐀䄀䜀䨀 Ⰰ 䐀䌀䄀䤀一一伀嘀䄀䌀䤀팀一琀攀洀愀猀搀攀椀渀琀攀爀猀瀀愀爀愀氀愀唀匀吀䤀䤀渀猀琀椀琀甀挀椀渀礀攀渀攀氀甀猀漀搀攀吀䤀䌀 ✀猀吀漀琀愀氀攀猀


Anexo - NTP13

Plan de la Capacidad en TI



PROCESO: GESTIÓN DE LA CAPACIDAD 1.

Introducción

El propósito de este documento es proporcionar una guía para la planeación de la capacidad de la tecnología de información y comunicaciones de la Contraloría General de la República (CGR), con el objetivo de aprovechar mejor los recursos institucionales y permitir que se adquiera la tecnología adecuada y con la capacidad para cubrir eficientemente y con el mejor desempeño las necesidades y requerimientos reales, presentes y futuros. La Unidad de Tecnologías de Información (UTI) tiene la responsabilidad de mantener as tecnologías de Información y comunicaciones (TIC) actualizadas y optimizadas como herramientas para apoyar y facilitar la gestión de fiscalización y demás tareas sustantivas de la institución. Como consecuencia de la gestión de la información automatizada y el cambio permanente en las TIC’s, la institución se ha propuesto mantener su infraestructura tecnológica operando eficaz y eficientemente para el cumplimiento de sus objetivos. Como producto del aumento constante en la automatización de procesos en la CGR, se requiere el estar gestionando nuevos requerimientos con miras a fortalecer las necesidades de procesamiento, almacenamiento, consulta y extracción de información. Bajo esta perspectiva, es necesario administrar y planificar la capacidad requerida de la infraestructura tecnológica de la CGR. 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.


Los componentes que se incluyen dentro de este plan consideran hardware, bases de datos, sistemas operativos y telecomunicaciones. Por último, es importante recordar que la planificación de la capacidad debe realizarse periódicamente y debe llevarse a cabo por personal capacitado y con experiencia en este campo. Es importante mencionar que este documento facilita el cumplimiento de los puntos 2.3, 3.3 y 4.2 de las Normas Técnicas emitidas por la CGR. 1.1.

Infraestructura tecnológica

La organización debe tener una perspectiva clara de su dirección y condiciones en materia tecnológica, así como de la tendencia de las TI para que conforme a ello, optimice el uso de su infraestructura tecnológica, manteniendo el equilibrio que debe existir entre sus requerimientos y la dinámica y evolución de las TI. 1.2.

Implementación de infraestructura tecnológica

La organización debe adquirir, instalar y actualizar la infraestructura necesaria para soportar el software de conformidad con los modelos de arquitectura de información e infraestructura tecnológica y demás criterios establecidos. Como parte de ello debe considerar lo que resulte aplicable de la norma 3.1 y los ajustes necesarios a la infraestructura actual.


Norma

4.1 La organización debe mantener la plataforma tecnológica en

Administración óptimas condiciones, minimizar su riesgo de fallas y proteger la y operación de integridad del software y de la información. Para ello debe: la

plataforma

tecnológica

Establecer y documentar los procedimientos y las responsabilidades asociados con la operación de la plataforma. Vigilar de manera constante la disponibilidad, capacidad, desempeño y uso de la plataforma, asegurar su correcta operación, mantener un registro de sus eventuales fallas, identificar eventuales requerimientos presentes y futuros, establecer planes para su satisfacción, garantizar la oportuna adquisición de recursos de TI requeridos tomando en cuenta la obsolescencia de la plataforma, contingencias, cargas de trabajo y tendencias tecnológicas. Controlar la composición y cambios de la plataforma y mantener un registro actualizado de sus componentes (hardware y software), custodiar adecuadamente las licencias de software y realizar verificaciones físicas periódicas. Controlar la ejecución de los trabajos mediante su programación, supervisión y registro. Mantener separados y controlados los ambientes de desarrollo y producción. Brindar el soporte requerido a los equipos principales y periféricos. Controlar los servicios e instalaciones externos. Definir formalmente y efectuar rutinas de respaldo, custodiar los medios de respaldo en ambientes adecuados, controlar el acceso a dichos medios y establecer procedimientos de control para los procesos de restauración.


1.3.

Tareas de la Gestión de la Capacidad

• Conocer el estado actual de la tecnología en la CGR. • Analizar el entorno relacionado con TIC. • Alinear las TIC a los planes de la institución; el plan estratégico en TIC. • Considerar los acuerdos de servicio establecidos. • Comparar el rendimiento de la infraestructura contra los parámetros definidos. • Realizar modelos y simulaciones de capacidad para diferentes escenarios futuros previsibles. • Dimensionar adecuadamente los servicios y aplicaciones alineándolos a los procesos de la CGR y necesidades reales de los usuarios. • Gestionar la demanda de servicios tecnológicos racionalizando su uso. • Considerar el recurso humano necesario. La gestión de la capacidad de TIC facilita el dimensionamiento de la infraestructura a utilizar para un mayor aprovechamiento de las inversiones necesarias en tecnologías. Los principales beneficios derivados de una correcta Gestión de la Capacidad son: • Se optimiza el rendimiento de los recursos humanos y tecnológicos. • Se dispone de la capacidad necesaria en el momento oportuno, evitando así que se pueda resentir la calidad del servicio. • Se evitan gastos innecesarios producidos por compras de “última hora”. • Se planifica el crecimiento de la infraestructura adecuándolo a las necesidades reales. • Se reducen los gastos de mantenimiento y de administración asociados a equipos y aplicaciones obsoletos o innecesarios. • Se disminuye el riesgo de posibles incompatibilidades y fallos en la infraestructura informática.


En resumen, se racionaliza la gestión de las compras y el mantenimiento de los servicios en TIC con la consiguiente reducción de costos e incremento en el rendimiento. Los principales problemas a los que se enfrenta la implementación de una adecuada política de Gestión de la Capacidad son: • Información insuficiente para una planificación realista de la capacidad. • Expectativas injustificadas sobre el ahorro de costos y mejoras del rendimiento. • Insuficiencia de recursos para el correcto monitoreo del rendimiento. • Infraestructuras informáticas distribuidas y excesivamente complejas en las que es difícil un correcto acceso a los datos. • No existe el compromiso suficiente de los niveles superiores por implementar rigurosamente los procesos asociados. • La rápida evolución de las tecnologías puede obligar a una revisión permanente de los planes y escenarios contemplados. • Un incorrecto dimensionamiento de la propia Gestión de la Capacidad.

2.

Objetivos 1.1.

Objetivo General:

El objetivo primordial de la Gestión de la Capacidad es poner a disposición de clientes, usuarios y la propia UTI, los recursos tecnológicos necesarios para desempeñar de una manera eficiente sus tareas a un costo razonable. En otras palabras, asegurar que la Infraestructura Tecnológica satisfaga las necesidades actuales y futuras de TIC para la operación eficiente de la CGR.


1.1.

Objetivos específicos:

• Minimizar cantidad e impacto de futuros incidentes que degraden la calidad del servicio. • Racionalizar el uso de la capacidad de la infraestructura TI. • Administrar costos razonables en infraestructura de TI. • Aumentar la productividad y satisfacción de los usuarios.

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

Las personas encargadas de administrar cada uno de los componentes seleccionados, serán los responsables de gestionar su capacidad.

4.

Actividades por realizar para cada componentes

Con el fin de generar la información requerida por el plan de la capacidad, en este apartado se deben definir claramente los detalles de cómo y cuándo se obtendrá esta información - por ejemplo, las previsiones de la CGR obtenidas a partir de los planes


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

Identificar las herramientas de medición

Identificar las herramientas de medición a utilizar para evaluar el comportamiento de un componente tecnológico ante determinadas cargas de trabajo, así como para establecer o realizar proyecciones de capacidad ante el cambio de los requerimientos de TI. 4.2.

Establecer las variables de medición

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

Tendencias de mercado y consecuencias

Al estudiar las tendencias y cambios tecnológicos en el mercado y con base en los acuerdos de servicio, los nuevos requerimientos y el análisis de la infraestructura tecnológica actual se puede estimar que cambios o adquisiciones se deben realizar en el futuro. 4.4.

Definir procesos y calendario de medición

La herramienta de medición que se utilice para cada componente determinará la frecuencia y los procesos que se requieren para realizar el análisis, las mediciones y la generación de resultados. Por lo general se analizan datos históricos que permitan establecer, variaciones importantes, problemas de infraestructura, capacidad excedida o sobrestimada y tendencias o proyecciones.


4.5.

Sustitución

Evaluar si por obsolescencia tecnológica, costos de mantenimiento, análisis financiero o por incompatibilidad con la infraestructura tecnológica en uso, se hace necesario la sustitución de alguno de los componentes de TICs.´ 4.6.

Riesgos

Establecer cual sería la probabilidad y el impacto de una falla de un componente tecnológico en la infraestructura de TI, de tal forma que se pueda mitigar el riesgo asociado. Asimismo, contemplar las oportunidades que pueda brindar el mercado en el lanzamiento de nuevas tecnologías. 4.7.

Prioridades

Como es bien entendido por la mayoría de administradores de infraestructura tecnológica, se deben establecer cuáles componentes son prioritarios de conformidad con el sistema de continuidad de servicio y también para cumplir con los acuerdos de servicio y los requerimientos de TI. 4.8.

Presupuesto

Finalmente, no se pueden dejar de lado los costos de la infraestructura tecnológica y cuál sería el presupuesto requerido y justificado para satisfacer las necesidades actuales y futuras en materia de TICs, de tal forma que se puedan realizar las previsiones financieras adecuadas. De los requerimientos de TICs y de los acuerdos de servicio se debe obtener la información necesaria para:


• 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. Con base en todo lo anterior, se debe realizar un proceso continuo de Gestión de la Capacidad que involucra las siguientes actividades: 4.9.

Seguimiento y control continuo

Seguimiento continuo de la infraestructura tecnológica en uso para análisis de rendimiento y de necesidades de ajustes para satisfacer adecuadamente los requerimientos de la CGR. Un correcto seguimiento de la capacidad disponible, permite reconocer puntos débiles de la infraestructura de TIC o cuellos de botella y evaluar posibilidades de balanceo de cargas o redistribución de servicios o datos para continuar dando un servicio de calidad. La Gestión de la Capacidad debe evaluar a priori, basándose en la experiencia, los resultados y las tendencias del mercado. En resumen el monitoreo debería permitir: • Analizar las tendencias de demanda de capacidad. • Evaluar el uso real que se hace de ella.


• Emitir informes de rendimiento, • Validar las métricas para la evaluación de la capacidad real y su impacto en la calidad del servicio.

5.

Análisis y Evaluación de datos

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

Con base en el monitoreo y en el análisis de datos se deben determinar los ajustes requeridos para la optimización de uso de los recursos de TIC mediante la Gestión del cambio, Generando el proceso necesario para la implementación del mismo. 5.2.

Almacenar la información

Se contará con una aplicación que permitirá almacenar la información relativa a la capacidad, incluyendo los planes de capacidad y los informes de gestión sobre los recursos de TI. 5.3.

Base de Datos de la Capacidad (BDC)

La BDC debe almacenar toda la información institucional, financiera, técnica y de servicio que reciba y genere la Gestión de la Capacidad, relativas a la capacidad de la infraestructura y sus elementos. Idealmente, la BDC debe estar interrelacionada con la BDCG (Base de datos de la capacidad gerencial) para que esta última ofrezca una imagen integral de los sistemas


y aplicaciones con información relativa a su capacidad. Esto no es óbice para que ambas bases de datos puedan ser “físicamente independientes”. 5.4.

INSUMOS

• Riesgos en materia de TIC. • Incidentes registrados. • Acuerdos de servicio establecidos • La arquitectura de información de la CGR. • Plan de Contingencia o para continuidad de servicios. • Rendimiento esperado por servicio o componente. • Avances o actualización tecnológica relacionada. • Requerimientos de información, de procesamiento y de telecomunicaciones. • Información relativa a la capacidad de la infraestructura de TIC. • Las previsiones o perspectivas de la CGR sobre necesidades. • Los cambios necesarios para adaptar la capacidad de TI a las novedades tecnológicas y las necesidades emergentes de usuarios y clientes. • La disponibilidad esperada. • Posibilidades presupuestarias.


6.

Análisis de capacidad

A continuación se establecen las variables a medir por cada componente seleccionado y los parámetros sobre los cuales se aplicará la medición; así como el instrumento a utilizar. ESTABLECIMIENTO DE METRICAS PARA EQUIPOS DE SEGURIDAD Consideraciones básicas A. Ancho de Banda Internet. Variables a medir: 1. Ancho de banda utilizado de entrada 2. Ancho de banda utilizado de salida 3. Eficiencia de la red. (entrada y salida) 4. Delay de transacciones por aplicación.

Valor normal

Punto crítico

Alerta

4Mb 2Mb 90% < 2 seg

5Mb 3Mb 75% 5 seg

> 5 Mb > 3 Mb > 75% > 5 seg

100% 15%

50% 70%

< 50% > 70%

10%

70%

> 70%Mas de 180/255

45% del canal

80% del canal

> 80% del canal

30%

60%

70%

20% 50% 1Mbps 30% del ancho de banda total

40% 70% 6Mbps 50% del ancho de banda total

65% 80% 8Mbps >70 % del ancho de banda total

20% 50%

70% 70%

80% 80%

25% 25% 60%

60% 15% 75%

80% 10% 80%

Punto crítico

Alerta

Instrumento de medición: Packeteer. B. Enrutadores 1. Confiabilidad de la interface. 2. Indice de carga de la interface de transmision TX 3. Indice de carga de la interface de recepción RX 4. Estadísticas para 5 minutos: 4.1 Tasa de transferencia en bits por segundo. 5. Utilización de CPU Instrumento de medición: Comandos sistema operativo C. Firewall 1. Utilización de CPU 2. Memoria utilizada. 3. Tasa de transferencia por subred 4. Ancho de banda utilizado por subred Instrumento de medición: Programa ASDM instalado en el Firewall. D. Appliance E-3100 Mc.Afee 1. Carga de CPU. 2. Memoria utilizada / memoria disponible Instrumento de medición: Programa administrador del Appliance. E. Detectores de intrusos. 1. Carga del CPU 2. Memoria disponible 3. Disco utilizado/disponible Comandos Sistema operativo

ESTABLECIMIENTO DE METRICAS PARA EQUIPOS PRINCIPALES Consideraciones básicas Tiempo de medición: Continuo Servidor es de base de datos y aplicaciones Variables a medir:

Valor normal


1. Utilización de UPC. La utilización óptima de la UPC son los siguientes: • 60% para usuarios • 20% para el sistema • 10% para E/S • 10% desocupado 2. Utilización de Memoria

65%

85%

90% o más de un 50% de utilización de la UPC por sistema operativo

< 65%

>85%

>90%

3.Paginación

5%

10% 15%

30%

5. Tasa utilización disco %iowait

10%

15%

6. %Crecimiento anual de disco

50%

70%

75%

Valor normal

Punto crítico

Alerta

1. % Utilización CPU.

65%

85%

2. % Utilización de Memoria

< 65%

>85%

90% o más de un 50% de utilización de la UPC por sistema operativo >90%

3.Promedio de tiempo de escritura del redo log

30s

90s

100s

4. Lock wait

10s

30s

60s

5. I/O wait

5%

15%

25%

6. Network wait

2%

10%

15%

7. Latch wait

1%

10%

15%

Instrumento de medición: Foglight y comandos del sistema operativo (Solaris

ESTABLECIMIENTO DE METRICAS PARA BASES DE DATOS Consideraciones básicas Tiempo de medición: Continuo Base de datos ORACLE Métricas:

Instrumento de medición: Foglight y comandos del sistema operativo (solaris) ESTABLECIMIENTO DE METRICAS PARA REDES Y TELEFONÍA


A. Switches. Switch de Servidores Switch de Backbone Switch de Acceso Métricas: B.

% Utilización Ancho de banda POR SUBRED

< 70%

70%

>75%

< 70%

70%

>75%

< 70%

70%

>75%

Instrumento de medición: EPI-Center de Extreme Networks

B. Access Point (red inalámbrica) Métricas: % Utilización Ancho de banda por puerto de access point Instrumento de medición: Hipath de Siemens y EPI-Center de Extreme Networks

C. Media Gateway con Proveedor de Servicio

Métricas: % Utilización de canales E1s Instrumento de medición: OTM de Nortel Networks

Anexo - NTP14

Acuerdo de Nivel de Servicio



Contraloría General de la República Proceso Gestión de Tecnologías de Información Acuerdo de Nivel de Servicio Introducción En aras de mejorar el servicio en tecnologías de información y comunicación y la satisfacción del cliente, se establece el presente Acuerdo de Nivel de Servicio (SLA por sus siglas en inglés), de acuerdo con las Normas Técnicas emitidas por la Contraloría General de la República (CGR) en su capítulo IV sobre prestación de servicios y mantenimiento.

Objetivo Fijar el nivel de calidad del servicio en Tecnologías de Información y Comunicación (TIC´s); manteniendo alineada la tecnología con los planes de la CGR, entre la Unidad de Tecnologías de Información como el proveedor de servicios de TIC´s; representada por su jefatura, y la Gerencia de la División XXXX como el cliente; representada por su Gerente.

Servicios tecnológicos A continuación se establecen los servicios que forman parte de este SLA: 1. Correo Electrónico 2. Red Convergente 3. Internet 4. Disponibilidad de la información 5. Telefonía a nivel de servidores


Requerimientos del Cliente A continuación se enumeran los requerimientos del cliente a nivel de servicios de tecnologías de información. 1. Alta disponibilidad para acceder a la información. 2. Alta disponibilidad en el servicio de correo electrónico. 3. Suficiente espacio para almacenamiento de sus datos. 4. Servicio para control de programas maliciosos. 5. Acceso telefónico permanente. 6. Custodia, confidencialidad e integridad de sus datos residentes en los servidores principales.

Acuerdos por servicio A continuación se especifica el nivel de servicio a brindar por el proveedor para cada uno de los servicios contemplados en este documento de acuerdos.

Correo Electrónico Compromisos del Proveedor 1. Disponibilidad del servicio 24x7. 2. 100 MB de almacenamiento de datos para cada cliente de correo. 3. Encriptación de la clave de acceso de cada cliente de correo. 4. Eliminación en un 90% de correo spam o basura. 5. Eliminación en un 95% de virus incluidos en documentos entrantes. 6. Privacidad de correo entrante y saliente para cada cliente. 7. Custodia y respaldo de la base de datos de correo. 8. Recuperación de la base de datos en un plazo máximo de 3 horas.


Compromisos del cliente 1. Cumplimiento de las directrices de seguridad vigentes. 2. Reportar cualquier falla que se detecte, en un plazo máximo de dos horas, a efectos de prevenir la expansión de la misma. 3. Reportar el uso indebido de información o activos de la CGR por parte de usuarios internos o personal externo.

Red convergente Compromisos del proveedor 1. Disponibilidad de red 24x7. 2. Conexión a velocidades de 10/100/1000. 3. Redundancia de los componentes primarios de la red convergente. 4. Disponibilidad complementaria y alternativa de conexión inalámbrica.

Compromisos del cliente 1. Cumplimiento de las directrices de seguridad vigentes 2. Reportar cualquier falla que se detecte, en un plazo máximo de dos horas, a efectos de prevenir la expansión de la misma.

Internet Compromisos del Proveedor 1. Disponibilidad del servicio 24x7. 2. 8 Mb de ancho de banda. 3. Aplicación de filtro de Contenidos. 4. Recuperación del servicio en un plazo máximo de 3 horas.


Compromisos del cliente 1. Cumplimiento de las directrices de seguridad vigentes. 2. Reportar cualquier falla que se detecte, en un plazo máximo de dos horas, a efectos de prevenir la expansión de la misma.

Disponibilidad de la Información Compromisos del Proveedor 1. Disponibilidad del servicio 24x7. 2. Brindar los controles que garanticen el acceso seguro y debido a la información. 3. Custodia y respaldo de la base de datos. 4. Iniciar la atención inmediata de recuperación de la base de datos en horario normal y en un plazo máximo de 2 horas fuera de horario.

Compromisos del cliente 1. Cumplimiento de las directrices de seguridad vigentes. 2. Reportar cualquier falla que se detecte, en un plazo máximo de dos horas, a efectos de prevenir la expansión de la misma. 3. Reportar oportunamente cualquier cambio en el rol operativo de algún usuario de la BD, que amerite una modificación en el respectivo control de acceso a la información.

Telefonía Compromisos del Proveedor 1. Disponibilidad del servicio 24x7. 2. Buzón para grabación de mensajes de hasta 10 Mb. 3. Facilidad de candado electrónico en el teléfono. 4. Privacidad de las llamadas entrantes y salientes para cada cliente.


5. Custodia y respaldo de las llamadas recibidas y efectuadas. 6. Recuperación de la base de datos en caso de contingencias, en un plazo máximo de 3 horas. 7. Proveer herramientas que faciliten la gestión de la telefonía en cumplimiento de la normativa de control interno vigente.

Compromisos del cliente 1. Cumplimiento de las directrices de seguridad vigentes. 2. Reportar cualquier falla que se detecte, en un plazo máximo de dos horas, a efectos de prevenir la expansión de la misma. 3. Hacer un uso racional de los servicios telefónicos. 4. Seguimiento para identificar niveles extremos de uso telefónico y para gestionar la corrección de prácticas inapropiadas. 5. Limpiar frecuentemente los buzones de mensajes.

Centro de Llamadas A efectos de facilitar la administración de incidentes relacionados con tecnologías de información, el proveedor pone a disposición de sus clientes un sistema automatizado para su registro y control, denominado Solicitud Órden de Servicio (SOS) 24x7, la posibilidad de solución remota y la atención en sitio en horario normal. Los incidentes deben ser reportados en horario normal a la extensión telefónica indicada por el proveedor o mediante registro en el SOS.

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


servicio por proveedores externos como en el caso de telefonía o acceso a servicios externos vía enlaces de comunicación contratados a terceros, o por fallas de la infraestructura tecnológica nacional.

Disminución de la calidad del servicio La calidad del servicio se puede ver afectada si previa negociación se decide brindar un tiempo de respuesta mejorado para acceder a una solución tecnológica para el registro, consulta o recibo de datos externos. Cuando los servicios no se encuentren dentro de los parámetros establecidos, el Proveedor trabajará en la solución del problema e informará al Cliente sobre el avance. Si el desempeño no mejora, se realizará una reunión conjunta, para discutir y resolver los problemas que han ocasionado la disminución del nivel de servicio y se elaborará un informe completo para la administración sobre los asuntos en referencia.

Evaluación Se llevará a cabo una reunión semestral cliente/proveedor para evaluar el servicio prestado durante los seis meses y para considerar eventuales cambios a realizar sobre el SLA con base al análisis de eventos presentados.


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.

Miguel Aguilar Zamora

Gerente de División

Jefe UTI

Gerente de División


Anexo - NTP15

Marco Jurídico en Tecnologías de Información



1. Introducción Como resultado de la recopilación de leyes, normativa, pronunciamientos, contratos, resoluciones y directrices; entre otras, y en cumplimiento a la norma Nro. 1.7 del documento “Normas Técnicas para la Gestión y el Control de las Tecnologías de Información” (N-2-2007-CO-DFOE) aprobadas mediante Resolución del Despacho de la Contralora General de la Republica, Nro. R-CO- 26-2007 del 7 de junio del 2007, se elabora este Marco Jurídico a ser utilizado para la gestión y gobernabilidad de las tecnologías de información y comunicación (TIC`s) de la Contraloría General de la República (CGR). La referida

norma 1.7 ya citada, establece el cumplimiento de obligaciones

relacionadas con la gestión de TI; para el cual toda organización debe identificar y velar por el cumplimiento del Marco Jurídico que tiene incidencia sobre la gestión de las tecnologías de información, con el propósito de evitar posibles conflictos legales que pudieran ocasionar eventuales perjuicios económicos y de otra naturaleza.

2. Antecedentes La Contraloría General de la República, ha venido organizándose y tomando medidas necesarias para implantar mecanismos y sistemas de información, que ayuden al control y fiscalización de los recursos del Estado y que sirvan como herramientas aplicables a los entes e instituciones de fiscalización. Es así, como en el año 2008 se lleva a cabo una revisión integral del Manual General de Fiscalización Integral, denominado MAGEFI, con el propósito de actualizar y mejorar este instrumento normativo, con los siguientes objetivos: a. Adecuar los procesos institucionales de conformidad con los cambios normativos en el marco legal relacionados con el quehacer del órgano contralor.


b. Ajustar dichos procesos a la luz de las nuevas ideas rectoras de la Contraloría General cuya revisión participativa implicó cambios en la misión, visión y valores institucionales. c. Reforzar el enfoque de procesos interrelacionados en la gestión institucional orientada al logro de la misión. Subyace a la dinámica e integración de procesos del MAGEFI, el concepto de cadena de valor, el cual se refiere a un instrumento de gestión estratégica orientada a la generación de valor público. Mediante el presente Marco Jurídico, aplicable a la gestión de las tecnologías de información y comunicación para la Contraloría General de la República, se pretende reforzar y fortalecer el uso apropiado de las tecnologías de información. Lo anterior, mediante una mayor regulación a la información que produce la institución , en función de su aplicabilidad, protección de datos personales, resguardo del flujo de datos, protección de licencias de uso de programas; así como la debida aplicación de las licencias de software adquiridas, políticas asociadas con proveedores de software y detección ágil en cuanto a regulaciones por delitos informáticos fraudes u otras acciones no legales, en los contratos relacionados con TIC’s , sus requerimientos de garantías contractual y sus principales repercusiones, principalmente.

3. Objetivo Elaborar el Marco Jurídico que contenga el compendio de leyes, pronunciamientos, contratos y otros aplicables a las Tecnologías de Información, utilizadas por la Contraloría General de la República, el cual estará incorporado en el sistema de Expediente Electrónico de la CGR. Dicho Marco Jurídico, estará conformado por las leyes, decretos, resoluciones, contratos, procedimientos, directrices, estándares y prácticas relacionadas con la


identificación,

revisión y toma de acciones correctivas continuas, en relación con

las obligaciones legales, gubernamentales, técnicas, contractuales, de seguridad y sobre confidencialidad y sensibilidad de los datos en los procesos de transferencia electrónica de datos interna y externa a la Contraloría General.

4. Lineamientos generales con relación a la ejecución de contratos 4.1 La adquisición de bienes y servicios se paga contra recibo a satisfacción de la Unidad de Tecnologías de Información, fecha a partir de la cual inicia el período de garantía. 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.3 En caso de incumplimientos contractuales por parte de la Contratista, y que no obedezcan a fuerza mayor o caso fortuito debidamente documentado, la CGR se reserva el derecho de resolver el contrato y de ejercer las medidas que correspondan para resarcir los eventuales daños y perjuicios que se le pudieren haber ocasionado. 4.4 Las licencias contratadas son para utilizar únicamente en equipos de la CGR. 4.5 Para todos los efectos, el expediente de la contratación, en especial el cartel, la oferta y el acto de adjudicación, forman parte integral del contrato. 4.6 Los horarios de servicio se establecen contractualmente de lunes a viernes entre las 8 a.m. y las 5 p.m. 4.7 Los servicios de escalamiento se encuentran registrados en el Sistema automatizado de Contingencias.


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

• Constitución Política de la República de Costa Rica, de 7 de noviembre de 1949. • Ley No. 7494, “Ley de Contratación Administrativa”, Gaceta 110, Alcance 90 de 8 de junio de 1995. • Ley No. 8292 “Ley General de Control Interno”, de 4 de setiembre del 2002. • Ley No. 8474, Ley de certificados, firmas y documentos electrónicos, LA GACETA 197 DEL 13-10-2005. • Ley 8422 contra la corrupción y el enriquecimiento ilícito en la función pública, Decreto No. 00000-J. • Ley de Derechos de autor y derechos conexos. 5.2 Lineamientos internos • Lineamientos para la atención de denuncias planteadas ante la CGR. • Lineamientos para el uso de la pizarra electrónica. • Lineamientos para desarrollo de sitios Web. 5.3Reglamentos • Reglamento autónomo de servicio para la regulación del correo electrónico masivo o no deseado, La Gaceta Nº 151 — Miércoles 4 de agosto del 2004 (RACSA). • Reglamento para la administración de los bienes y derechos de propiedad intelectual de la CGR, La gaceta No. 175 del 7 de setiembre del 2004.


• Reglamento para la Utilización del Sistema de Compras Gubernamentales CompraRed, La gaceta no. 204 del 24-10-2005, decreto 32717-h. • Reglamento a la Ley de Certificados, Firmas Digitales y Documentos Electrónicos La Gaceta 77 – Viernes 21 de abril del 2006 DECRETO 33018• Reforma al Reglamento a la Ley de Contratación Administrativa, La Gaceta 93 – Miércoles 16 de mayo del 2007DECRETO 33758-H. • Reglamento para la administración de los bienes y derechos de propiedad intelectual de la CGR, La Gaceta No. 175 — Martes 7 de setiembre del 2004. 5.4 Decretos • Reforma al Decreto Ejecutivo Número 33411-H del 27 de Setiembre del 2006, Reglamento a la Ley de Contratación Administrativa”, La Gaceta N° 88 – Viernes 08 de mayo de 2009 Decreto Nº 35218-H DEL 30/04/2009. • Decreto No. 25038-H, Reglamento General de Contratación Administrativa, Gaceta 62 del 28 de marzo de 1992. 5.5 Normas • Normas Técnicas para la gestión y el control de las Tecnologías de Información, N-2-2007-CO-DFOE. 5.6 Estatutos • Estatuto Autónomo de Servicios, Resolución No. 4-DHR-96. 5.7 Resoluciones • R-CO-44-2007, Contraloría General de la República, Actualizar los límites económicos que establecen los incisos a) al j) de los artículos 27 y 84 de la Ley de Contratación Administrativa y sus reformas, La Gaceta No. 23


• R-CO-62-2006. Modificar el inciso b) de las disposiciones transitorias de la resolución D-4-2005-CO-DDI, de las diez horas del 14 de diciembre del dos mil cinco, publicada en La Gaceta número 243 del viernes 16 de diciembre del 2005, mediante la cual se emitieron las “Directrices para el registro, la validación y el uso de la información sobre la actividad contractual desplegada por los entes y órganos sujetos al control y la fiscalización de la contraloría general de la república”, • R-CO-62 —Contraloría General de la República— Directrices generales a los sujetos pasivos de la Contraloría General de la República para el adecuado registro o incorporación y validación de información en el sistema de información sobre presupuestos públicos (SIPP) D-2-2005-CODFOE. La Gaceta no. 131 del 7-07-2005 contraloría general de la república resoluciones 5.8 Directrices • R-CO-61-2007 Directrices sobre Seguridad y Utilización de Tecnologías de Información y Comunicaciones 5.9 Contratos En la actualidad, la administración de contratos en TIC esta distribuida por áreas especializadas, esto con el fin de facilitar la gestión y comunicación correspondiente entre los proveedores y la Contraloría General. A continuación se muestran los proveedores actuales y el tipo de servicio que brindan, así como datos importantes relacionados con el contrato vigente.


5.9.1 Administración de redes AEC Electrónica, servicio de reemplazo avanzado de partes o equipo completo; todos nuevos, en un plazo de 48 horas, así como el servicio de atención de valor agregado 24x7 para los switches de backbone de la CGR y la actualización de versiones de software para los equipos marca Extreme Networks, según contrato No. 2008-000019, 2008-000018 y especificaciones en Anexo 1, por un año. 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. Siemens Enterprise Communications C.A.M. S.A., adquisición, instalación y puesta en funcionamiento de una solución inalámbrica en toda la institución excepto los pisos 9 y 11, con una garantía de funcionamiento de tres años y con una capacidad instalada de 108 Mbps por piso. El máximo de capacidad instalada que proveerán los Access Point es de300 Mbps en el modo específico de operación del estándar 802.11n-draft-2.0. Contrato No. 2008-000017 y Anexo 1. 5.9.2 Administración de microcomputadores e impresoras Central de Servicios, garantía de funcionamiento de tres años por 11 Microcomputadores, Contrato No. 2006-000004. Central de Servicios, garantía de funcionamiento de tres años por 22 Microcomputadores, Contrato No. 2006-000022. Central de Servicios, garantía de funcionamiento de tres años por 21 Microcomputadores, Contrato No. 2007-000017.


Central de Servicios, garantía de funcionamiento de tres años por 30 Microcomputadores, Contrato No. 2008-000007. Componentes El Orbe, garantía de funcionamiento de tres años por 13 Microcomputadores, 10 terminales para operar con software CITRIX y 11 monitores LCD, Contrato No. 2008-000006. Componentes El Orbe, garantía de funcionamiento de tres años por 3 Microcomputadores, 2 ordenadores PALM con dos años de garantía y 2 Docking Station, Contrato No. 2007-000016. I.S. Productos de Oficina Centroamérica S.A., adquisición de 3 impresoras láser de red Kyocera Mita modelo FS-2000D, 1 fax Kyocera KM-1116 MFP y una reproductora digital marca Duplo modelo DP-S550, todos con tres años de garantía. Contrato No. 2008-000008. 5.9.3 Administración de Servidores Control Electrónico S.A., Arreglo de discos (SAN) y Servidores con garantía de tres años. Contrato No. 2008-000018. Control Electrónico S.A., Mantenimiento preventivo y correctivo de hardware y software; incluyendo reemplazo de partes, por un año y cinco meses y medio, en un servidor, en un arreglo de discos (SAN) y en una unidad para generación de respaldos. Contrato No. 2009-000005. Componentes El Orbe, garantía de funcionamiento por tres años de 4 Servidores Server Blade y 2 Docking Station. Contrato No. 2007-000019.


ComputerNet

Centroamericana S.A., software para respaldos automáticos de 4

servidores con sistema operativo Solaris y 2 con sistema operativo Windows en UNIX (Solaris), Oracle (Solaris) y Windows; incluye un año de garantía y dos visitas al año para mantenimiento preventivo. Contrato No. 2007-000023. 5.9.4 Administración de la Seguridad Consulting Group Chami Centroamericana S.A., 501 Licencias de Antivirus y de antispyware p/Windows y 5 Licencias p/Macintosh, contrato prorrogable por 4 años según Pedido No. 20130, solicitud 280517, desde el 14 de diciembre del 2008 hasta el 13 de diciembre del 2012. SPC Internacional S.A., Servicios de Mantenimiento de los Smarnets para un firewall, tres routers y dos detector de intrusos, con una duración de un año y cinco meses, hasta el 15 de diciembre del 2010. Contrato No. 2009-000009. SPC Internacional S.A., adquisición de una solución de Control y Filtro de Contenido (Websense) y actualizaciones para el acceso a Internet de una población de 500 usuarios y un ancho de banda de 8 Mbps por un plazo máximo de cuatro años. La no prórroga del contrato debe comunicarse con 90 días de anticipación. Contrato No. 2008-0023 con vigencia a partir del 7 de diciembre del 2008. 5.9.5 Administración de la Telefonía Continex S.A., adquisición, instalación y puesta en funcionamiento de una solución telefónica con mensajería unificada, contestador automático, distribución automática de llamadas, sistema de correo de voz, sistema básico para envío y recepción de fax y respuesta de voz interactiva; incluye tres años de garantía y dos visitas al año para mantenimiento preventivo. La Contratista garantiza el abastecimiento de repuestos y reparación de unidades durante un período de cinco años. Contrato No. 2005-000020.


Continex S.A., adquisición, Instalación y configuración de bienes para la Solución Telefónica, 63 transformer (IP) y administración de OTM Billing, 8 licencias, 3 clientes Soft Phone y 13 Headset; incluye tres años de garantía. Contrato No. 2007-000003. 5.9.6 Administración de Telecomunicaciones Instituto Costarricense de Electricidad (ICE), marcación directa a la extensión soportado por un enlace PRI-RDSI, cuyo rango de numeración es del 501-8000 al 501-8999 con 600 extensiones en operación y 400 en reserva, asociado a número de identificación 296-J015 y al equipo terminal marca Nortel. La comercialización de tonos de invitación a marcar para accesar la red del país es una prohibición; entre otras, establecidas en la cláusula 8. Es un contrato permanente. Radiográfica Costarricense S.A. (RACSA), servicios de telecomunicaciones: 1 puerto de Internet dedicado a 8 MB, 1 Frame Relay a 256 Kbps para conexión con el Ministerio de Hacienda, 1 Frame Relay a 128 Kbps para conexión con la Asamblea Legislativa, 1 cuenta conmutada y los componentes para lograr la conectividad, por un máximo de cuatro años. De acuerdo con cláusula Quinta, inciso i) la CGR no puede vender ni proveer a terceros bajo ninguna circunstancia, servicios de telecomunicaciones, específicamente transporte de voz, datos y facsímil. Contrato No. 2008-00022 y sus dos Anexos. Informática Trejos S.A., adquisición de un administrador de ancho de banda marca Packeteer y su licencia PacketWise y sus actualizaciones para administración de 10 Mbps, con una garantía de un año. Contrato 2008-00013.


5.9.7 Acceder a información de Base de Datos Sistemas Maestros de Información S.A., suscripción de 20 usuarios para acceder a la base de datos Master Lex Normas y Master Lex Jurisprudencia, su instalación y sus actualizaciones, con una duración máxima de tres años. Incluye fórmula para reajuste de precios y un Anexo con las características de los productos contratados. Contrato 2008-000003. 5.9.8 Administración de Base de Datos Oracle de Centroamérica S.A., servicio de Soporte Técnico y actualización de productos indicados en la cláusula sétima, las cuales se brindan conforme a las políticas de servicios de soporte de Oracle Corporation según Anexo 1, con una duración de tres años. Aplican para los productos incluidos en este contrato las leyes y reglamentos de exportación de los Estados Unidos de América (USA). Contrato No. 2008-000009.


6. Conclusiones Como es posible apreciar, la cantidad de normativa que aplica a la gestión contractual se convierte en un riesgo alto para la ejecución, control y seguimiento, en el tanto no se tenga claro y documentado cuáles son las normas que aplican a dicha gestión. 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. Finalmente, se considera que la incorporación de este Marco Jurídico dentro del sistema de Expediente Electrónico, permitirá una mejor observancia del mismo y por ende, minimizar los riesgos asociados al seguimiento normativo en la gestión contractual institucional.

Anexo - NTP16

Informe de gestión 2009-01



Contraloría General de la República Normas Técnicas para la gestión y el control de las Tecnologías de Información Resolución Nro. R-CO-26-2007, La Gaceta Nro. 119, 21/06/2007 Informe de seguimiento 2009-01 Introducción Basados en el cronograma de actividades elaborado para cumplir con la implementación de las normas técnicas de acuerdo con la resolución Nro. R-CO-26-2007 emitida por el Despacho de la Contralora General, en La Gaceta Nro. 199 del 21/06/2007, a continuación se incluye una descripción corta de lo realizado al 30 de mayo del 2009, un anexo sobre el cumplimiento de cada una de las normas, y un CD con los productos elaborados a la fecha para su consideración y recomendaciones.

Actividades ejecutadas 1. Se creo una Comisión Institucional Ad Hoc; como equipo de trabajo, para la elaboración del plan que permita el cumplimiento de las Normas Técnicas. El grupo lo coordina la Sra. Sub Contralora General, Lic. Marta Acosta, y lo integran la Licda. Rebeca Calderón y los Lics. Ronald Castro, José Alpízar, y Miguel Aguilar, en representación de las diferentes unidades. 2. Como responsable de la implementación se designó a la Unidad de Sistemas y Tecnologías de Información (USTI) representada por Miguel Aguilar, quien coordina reuniones periódicas con los especialistas de las diferentes áreas de la USTI, para seguimiento del plan de ejecución; contando para ello con la asesoría de José Alpízar. 3. Se mantiene en funcionamiento el Comité Gerencial de Tecnologías de Información y Comunicación (CGTIC), el cual está presidido por la Sub Contralora General.


4. Se elaboró un diagnóstico de la situación al 30 de diciembre de 2007, el cual incluye las acciones y productos esperados para el cumplimiento de la normativa y para cerrar la brecha existente, así como el respectivo cronograma. Ambos documentos fueron validados por el CGTIC. 5. Como parte de la promulgación y divulgación de un marco estratégico, se impartieron charlas al cuerpo gerencial y a funcionarios sobre el Plan Estratégico en Tecnologías de Información y Comunicación (PETIC), sobre el Plan Táctico (PTAC), y sobre el campo de acción E del Plan Estratégico Institucional. 6. Se aprobaron y actualizaron en el CGTIC las prioridades y los proyectos a desarrollar, de acuerdo con la cartera incluida en el PTAC. Se crearon los equipos de trabajo con sus respectivos líderes, y se les capacitó en el uso de herramientas para elaboración y seguimiento de proyectos; inicialmente, y posteriormente en la elaboración de casos de uso para levantado de requerimientos y de casos de prueba. 7. Se identificaron y definieron los riesgos generales en TI, se elaboró un manual de riesgos para la gestión y valoración trimestral, y se capacitaron dos funcionarios de USTI en SEVRI. Se está a la espera del estándar institucional a generar por parte de la División de Estrategia Institucional (DEI), para integrar estos riesgos de T.I. con los definidos a nivel de la institución. Se realizó la primera revisión del documento original con fines de actualizarlo y de selección de los riesgos más relevantes a incorporar en la Guía Metodológica para desarrollo de proyectos de TI. 8. A efectos de generar productos de calidad, se elaboró un documento para la Gestión de Calidad sobre el desarrollo y evolución de soluciones tecnológicas, el cual se comenzará a aplicar a partir de su validación por el CGTIC. 9. Se desarrolló y está operando un sistema de información para facilitar el registro de solicitudes por servicios relacionados con TI, en aras de mejora continua y control de calidad en TICs.


10. Los proyectos de TI siguen siendo fortalecidos por una participación cada vez más comprometida de los patrocinadores, evidente al asumir y mantener la dirección del proyecto y en el aporte de recurso humano calificado. Buscando la estandarización en cada equipo, se les brindó la inducción necesaria para que apliquen la Guía Metodológica para desarrollo de proyectos, capacitación en el uso de la herramienta de software para administración de proyectos y para la elaboración de casos de uso en el levantado de requerimientos y desarrollo de pruebas. 11. Respecto a la Guía Metodológica para el desarrollo de proyectos se realizó en la USTI una revisión de ésta, recopilando una serie de mejoras propuestas por el mismo personal que desarrolla aplicaciones. Dichas propuestas serán revisadas para definir su posible incorporación al nuevo documento de metodología, que deberá estar integrado con la actual metodología de desarrollo de proyectos al 30 de junio del 2009. 12. Basándonos en la norma ISO-27001, se elaboró un Marco de Seguridad en Tecnologías de Información a divulgar en la CGR durante el mes de junio del 2009, el cual incluye las Directrices de Seguridad aprobadas y en ejecución por la CGR. Para efectos de divulgación; entre otros, se coordinó con RH para que como parte de la inducción se incluya lo correspondiente a seguridad en TI. 13. Sobre planificación de la capacidad en TICs, se trabaja en la elaboración de un manual; que debe ser evolucionado con base a la experiencia que se genere, el cual estará terminado al 15 de junio del 2009. Este incluirá las unidades de medida, métricas e indicadores básicos que sustenten las decisiones orientadas hacia la optimización y evolución de la plataforma tecnológica. 14. Los compromisos de gestión y la elaboración del PAO se confeccionan alineados a los objetivos estratégicos de la CGR y a la gestión estratégica de TI.


15. Se concluyó el desarrollo del modelo de la Arquitectura de Información, basándose en la metodología del Bussines System Planning. El modelo incorpora el nivel base y se continuará con su desarrollo en paralelo a la elaboración de los procedimientos del MAGEFI. Previamente se generó un diagnóstico para dirigir y orientar el desarrollo. 16. Como parte de los proyectos de Maestría, se está desarrollando un Marco Jurídico relacionado con TICs para su aplicación en la CGR. 17. Está concluida la recopilación de información para obtener el DNC relacionado con TI y su procesamiento estará concluido para el 15 de junio del 2009. 18. En coordinación con la Unidad de Recursos Humanos se insertaron las competencias tecnológicas en los distintos puestos de la CGR. 19. En relación con las directrices de seguridad física y ambiental se ha fortalecido el soporte eléctrico mediante la instalación de un transformador exclusivo para el manejo de los aires acondicionados y por la adquisición e implementación de una unidad de poder ininterrumpido (UPS) para continuidad de los servicios tecnológicos. Se instalaron sensores de humo, de temperatura y de incendio, alarmas y alertas por fallas relacionadas con el ambiente, cámaras para el registro de accesos a las áreas restringidas y control de acceso, y una unidad de aire acondicionado adicional. En conjunto con la Unidad de Servicios Generales, para finales de abril se espera contar con un mapeo eléctrico del Centro de Cómputo que permita distribuir adecuadamente las cargas eléctricas en caso de ser necesario. 20. El presupuesto de inversiones del 2010 se elaboró con base al PTAC. Al 30 de mayo del 2009 se considera que la implementación de las normas técnicas avanza satisfactoriamente y que el ritmo de trabajo permite visualizar el cumplimiento de las mismas en la fecha establecida.

Anexo - NTP17

Estado de las normas técnicas 20090730


Cumplido

Pendiente Cumplido

Elaboración de riesgos en TIC

Marco de seguridad integral documentado Plan de divulgación Niveles de criticidad de los recursos de TI

1.3 Gestión de riesgos

1.4 Gestión de la seguridad de la información

1.4.1 Implementación de la seguridad de la información

Cumplido

Directrices de seguridad física y ambiental Directrices de seguridad en la operación y comunicación

1.4.4 Seguridad en la operación y comunicación

Cumplido

Cumplido

Divulgación y aplicación del manual de directrices de seguridad

1.4.2 Compromiso del personal con la seguridad de la información 1.4.3 Seguridad física y ambiental

Cumplido

Cumplido

Manual de gestión de la calidad sobre las áreas de acción de TI

1.2 Gestión de la calidad

Estado actual Cumplido

Producto según Diagnóstico inicial Plan de divulgación campo de acción E, PETIC, PTAC

Norma 1.1 Marco estratégico de TI

Se realizó y documentó un Mapeo Eléctrico por la Unidad de Gestión de Apoyo, incluyendo acciones a realizar. Esta UGA debe mantener actualizado el documento. Se tienen sistemas de alarma, de supresión de incendio, detectores de humo y de vídeo vigilancia. Se incorporaron certificados digitales en los servicios sensitivos de acceso al público; como declaraciones juradas, acorde con la autenticidad, integridad y confidencialidad de las transacciones que requiere la CGR y se documentaron los procedimientos relacionados. Ver sistema de contingencias en la Intranet.

El campo de acción E fue eliminado. Se elaboró el Marco general para la Gestión de la Calidad en Tecnologías de Información y Comunicaciones, el cual debe ser implementado a partir del segundo semestre del 2009. Se elaboró el manual que denominado Evaluación de Riesgos en Tecnologías de información y se actualizó al 30 de mayo del 2009. Sus principales riesgos forman parte de la Guía para desarrollo de proyectos en TI y son evaluados para cada proyecto de TI. Se elaboró el Marco de seguridad en Tecnologías de Información, del cual se debe generar el informe de brechas respecto al estado actual, a efectos de establecer las acciones que estarían cerrando la brecha. Se programará para realizarlo en el segundo semestre del 2009. Se están registrando en el sistema de contingencias. El sistema se encuentra en producción desde el primero de julio y en actualización constante. . La versión definitiva se libera el 1 de julio. ¿?? Tenemos hasta junio?? El 30 Se complementará con la divulgación del marco de seguridad.

Observaciones La divulgación de los planes se realizó por medio de charlas al nivel gerencial e institucional y su publicación en la Intranet.

1. Descripción del Estado de las Normas al 30 de julio del 2009


Comité de Salud Ocupacional operando Guía metodológica para la gestión de proyectos de TI

1.4.11 La salud y seguridad ocupacional

1.5 Gestión de proyectos

Cumplido

Cumplido

Cumplido

Administración de contratos

1.4.10 La terminación normal de contratos, su rescisión o resolución

Para efectos de acceso a la información por parte de terceros, se requiere de convenios o contratos previamente establecidos, o de la solicitud del jerarca de una institución, para la asignación de un rol que le facilite la consulta controlada, igual en contrato de servicios mediante cláusulas de confidencialidad. Se realiza por medio del Sistema Integrado de Gestión y Documentos (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. La UTI mantiene como política la administración de contratos relacionados con TI, a través de los coordinadores; segú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. La CGR cuenta con un Comité de Salud Ocupacional que se ocupa permanentemente de este tema y con el cual se ha coordinado la ergonomía de los puestos de trabajo y su entorno. Metodología para el desarrollo de 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.

Cumplido

Cumplido

Se implementó el sistema de contingencias a partir del 1 de julio

Mediante un sistema de asignación de roles y privilegios en uso, no sólo se controla el acceso lógico a la información, sino que también se facilita el seguimiento de las operaciones realizadas por los usuarios de los sistemas de información operando. Físicamente se complementa con los controles de acceso establecidos en coordinación con la UGA. La UTI cuenta con un ambiente controlado e independiente, destinado a la ejecución de desarrollo de aplicaciones que aseguren la no interferencia con las operaciones diarias y que garanticen el cumplimiento de los requerimientos de usuario, un ambiente para efectos de pruebas de usuario y capacitación, así como obviamente el ambiente para sistemas operando.

Cumplido

Administración de documentos

Plan de continuidad Plan de contingencia actualizado para garantizar la continuidad de los servicios de TI Control de acceso a la información por parte de proveedores de servicios y de terceros.

Cumplido

Cumplido

1.4.9 El manejo de la documentación

1.4.8 El acceso a la información por parte de terceros y la contratación de servicios prestados por éstos.

1.4.7 Continuidad de los servicios de TI

Directrices de seguridad en la implementación y mantenimiento de software e infraestructura tecnológica.

1.4.6 Seguridad en la implementación y mantenimiento de software e infraestructura tecnológica Guía metodológica para el desarrollo de proyectos.

Directrices de seguridad del control de acceso

1.4.5 Control de acceso


Cumplido

Cumplido

Estructura orgánica actualizada acorde con PETIC

Programa de actualización, información a usuarios

Cumplido

Plan de capacidad

2.4 Independencia y recurso humano de la función de TI

Cumplido

Infraestructura tecnológica alineada a PETIC

2.3 Infraestructura tecnológica

Cumplido

Cumplido

Cumplido

Cumplido

Cumplido

Cumplido

Modelo de arquitectura de información nivel 1.

Compromisos de gestión y PAO alineado al PETIC y PTAC

Seguimiento oportuno a contratos de TI. Seguimiento al PETIC y PTAC

Funcionamiento efectivo del Comité Gerencial de Tecnologías de Información y Comunicación Marco jurídico con incidencia en TI disponible, actualizado y aplicado.

2.2 Modelo de arquitectura de información

2.1 Planificación de las tecnologías de información

1.7 Cumplimiento de obligaciones relacionadas con la gestión de TI

1.6 Decisiones sobre asuntos estratégicos de TI

El PETIC garantiza una visión institucional y promueve la 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 Se elaboró un estudio para la elaboración del Plan de Educación continua en tecnologías de información y comunicación.

El comité gerencial atiende convocatorias a reuniones, según sea necesario. Además, cuenta con un comité Ad hoc para análisis preliminar de las propuestas de soluciones tecnológicas. Se elaboró un Marco Jurídico – básico- de aplicación en la CGR, el cual es de actualización permanente en términos de leyes, 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. Existe una gestión práctica por área de la administración de los contratos en UTI. Seguimiento de proyectos constante a través de reuniones periódicas con los líderes de proyectos. Proyectos del PTAC fungen como compromisos de gestión de cada área. Se ha respetado el mecanismo de inclusión de proyectos definido en el PTAC. Los siguientes niveles del modelo de información, dependen del 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. La CGR cuenta con una infraestructura tecnológica adecuada, alineada y actualizada a las necesidades sustantivas y de apoyo, producto de un direccionamiento estratégico en TI definido en el PETIC. 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.


Cumplido Cumplido

Software en uso de acuerdo con las necesidades de la institución Aplicación de la guía metodológica para el desarrollo de sistemas Infraestructura tecnológica alineada al PETIC

4.3 Administración de los datos

4.2 Administración y operación de la plataforma tecnológica.

3.4 Contratación de terceros para la implementación y mantenimiento de software e infraestructura 4.1 Definición y administración de acuerdos de servicios

Políticas y procedimientos revisados y actualizados

Pendiente

Identificación completa y registrada y seguimiento de los servicios de la función de TI Diagnóstico anual de capacidad, mantenimiento y evolución de la plataforma tecnológica

Cumplido

Cumplido

Cumplido

Servicios contratados a terceros con base en estándares institucionales

Cumplido

Cumplido

Metodología para desarrollo de proyectos de TI aplicada institucionalmente

3.1 Consideraciones generales de la implementación de TI. La organización debe implementar y mantener las TI requeridas en concordancia con su marco estratégico, planificación, modelo de arquitectura de información e infraestructura tecnológica. 3.2 Implementación de software

3.3 Implementación de infraestructura tecnológica

Cumplido

Presupuesto de inversiones con base en el PTAC

2.5 Administración de recursos financieros

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. De acuerdo con los requerimientos de usuario se asegura la validez de las transacciones mediante funciones tecnológicas integradas a la base de datos; su integridad, almacenamiento y su vigencia.

Se definieron los acuerdos de nivel de servicio a firmar con los Gerentes de División, está pendiente la revisión y firma para su aplicación y administración. Se elaboró el Manual Plan de la Capacidad en TI para implementar en el segundo semestre del 2009.

El software que se desarrolla e implementa es con base al PTAC al plan de compras derivado del PETIC, ambos aprobados por el Despacho de las señoras Contraloras. Para todos los proyectos de TI se aplica a nivel institucional la Metodología para desarrollo de proyectos. La CGR cuenta con una infraestructura tecnológica adecuada, alineada y actualizada a las necesidades sustantivas y de apoyo, producto de un direccionamiento estratégico en TI definido en el PETIC. Aplica todo lo relacionado a metodologías, guías, procedimientos, organización, controles y ambientes de trabajo, entre otros.

Las TI se implementan con base a PETIC y PTAC.

Se cuenta con un modelo de Arquitectura de Información en su nivel inicial.

El presupuesto de inversiones de la UTI y sus modificaciones, 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. La cartera de proyectos de TI se desarrolla e implementa con base a esta metodología y es aplicada por los Patrocinadores y el equipo de trabajo en su totalidad.


Pendiente

Sistema de conocimiento efectivo que genere aprendizaje y autoservicio Resolver y documentar los incidentes en función de la mejora continua

5.3 Participación de la Auditoría

Auditoría interna auditando, asesorando y recomendando mejoras en materia de TI.

Cumplido

Cumplido

Cumplido

Compromisos de gestión y PAO alineados Diseño e implementación de medidas de control interno en TI, integradas al SCI

5.2 Seguimiento y evaluación del control interno en TI

Cumplido

Evaluación periódica del PETIC, PTAC

5.1 Seguimiento de los procesos de TI

Cumplido

Servicios contratados a terceros con base en estándares internacionales

Cumplido

Cumplido

Centro de atención a usuarios centralizado.

4.6 Administración de servicios prestados por terceros

4.5 Manejo de incidentes

4.4 Atención de requerimientos de los usuarios de TI

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.

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 trimestral al cumplimiento del PTAC.

Se relaciona con la norma 2.1

Todo tipo de situación especial es analizada por funcionarios de la UTI en aras de lograr la mejor solución y tratándose de incidentes o eventos, estos son registrados en los SCS o de SOS, para minimizar el riesgo de recurrencia y para agilizar el tiempo de respuesta en caso de que se materialice de nuevo. En lo que respecta a servicios de terceros, se establecen los requerimientos como parte del contrato, ya sea en cláusulas específicas o anexos del mismo, aplicando buenas prácticas. La organización cuenta con un marco de referencia que es el Plan Estratégico Institucional (PEI), el PETIC y PTAC, unidos al Modelo de Arquitectura de Información, el Manual General de Fiscalización (MAGEFI) como un marco de procesos, la Auditoría Interna como un elemento de advertencia y asesoría y una Unidad de Gobierno Corporativo que se encarga de darle seguimiento a la función de TI; además del CGTIC y la comisión Ad hoc.

Se recomienda evolucionar a la implementación de un centro de atención de usuarios tipo call center. Se realizó un estudio para desarrollar un Plan de Educación en TI.

La UTI tiene implementado un sistema de control de cambios que 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.



Informe NTI Doc.desbloqueado

Recommend Documents