Sistema de Estudios de Posgrado Escuela de Administración de Negocios Auditoría del Área de Tecnologías de Información de la Oficina de Planificación Universitaria de la Universidad de Costa Rica Trabajo Final de Graduación aceptado por la Comisión del Programa de Posgrado en Administración y Dirección de Empresas, de la Universidad de Costa Rica, como requisito parcial para optar por el grado de Magíster en Administración y Dirección de Empresas con énfasis en Auditoría de Tecnologías de Información Estudiante Bach. Carlos Martín Gómez Borbón Ciudad Universitaria “Rodrigo Facio” San José, Costa Rica - 2007 ii Dedicatoria A Dios por permitirme estar aquí y poder realizar mis metas, además de darme la fuerza para seguir adelante. A mis padres por todo el apoyo que me han dado durante toda mi formación académica e inculcarme el salir adelante, educarme y disciplinarme para ser alguien en la vida. A mis hermanos por estar ahí en el momento que lo necesite y hacerme ver que tengo a alguien por quien luchar en la vida. A todos y cada uno de mis profesores que han compartido sus conocimientos. A la persona que me ha dado su apoyo incondicional en todo. iii Agradecimientos Oficina de Planificación Universitaria (OPLAU). A la Licda. Maritza Monge, Directora, por el apoyo brindado y su anuencia para el desarrollo de este trabajo en la oficina a su digno cargo. A Francela Salazar, Jefa de la Sección de Tecnologías de Información, por todo su apoyo y por fungir como supervisora laboral de la práctica profesional. Francisco Rodríguez y Francisco Lee, Bernardo Salguero, colaboradores en el área de Tecnologías de Información de la OPLAU, por su colaboración. A los guías del trabajo. Al Magíster Oscar Durán, por todo su consejo de este trabajo en calidad de lector. Al Magíster Xiomar Delgado, en calidad de profesor coordinador; su orientación y carisma hicieron posible la conclusión de este trabajo. A todo el cuerpo docente, que con mucho esmero, calidad y profesionalismo, compartió su conocimiento con nosotros. No puedo dejar de lado a mis compañeros del grupo de maestría, por su apoyo, amistad, por las largas sesiones de estudio que compartimos. iv Gómez Borbón Carlos M. Auditoría del Área de Tecnologías de Información en la Oficina de Planificación Universitaria de la Universidad de Costa Rica Programa de Posgrado en Administración y Dirección de Empresas -San José, C.R.- cmgb, 2007 v HOJA DE APROBACIÓN El presente Trabajo Final de Graduación fue aceptado por la Comisión de Posgrado en Administración y Dirección de Empresas, de la Universidad de Costa Rica, como requisito parcial para optar al grado de Magíster con énfasis en Auditoría de Tecnologías de Información. ___________________________ Doctor Anibal Barquero Chacón Director del Programa de Maestría ___________________________ Master Xiomar Delgado Profesor Coordinador __________________________ Master Oscar Durán Profesor Lector ___________________________ Licda. Francela Salazar Jiménez Supervisar Laboral ____________________________ Bach. Carlos Martín Gómez Borbón Estudiante vi Índice Dedicatoria ...............................................................................................................ii Agradecimientos...................................................................................................... iii Resumen................................................................................................................. 1 Introducción............................................................................................................. 3 Introducción ......................................................................................................... 3 Limitaciones......................................................................................................... 4 Objetivo................................................................................................................ 4 Objetivo general................................................................................................... 5 Alcance................................................................................................................ 6 Capítulo I ................................................................................................................. 7 Marco contextual ................................................................................................. 7 Ciclo de vida ........................................................................................................ 8 Historia ............................................................................................................. 8 Definición del “Ciclo de vida del software”........................................................ 9 Modelos de ciclo de vida ................................................................................ 10 Métricas para el desarrollo de sistemas ............................................................ 11 Reseña de la Universidad de Costa Rica .......................................................... 13 Generalidades................................................................................................ 13 Historia ........................................................................................................... 13 Propósitos y funciones fundamentales de la Universidad de Costa Rica....... 13 Estructura orgánica de la Universidad de Costa Rica .................................... 15 Situación Actual de la Oficina de Planificación Universitaria ............................. 17 Generalidades................................................................................................ 17 Origen ............................................................................................................ 17 Antecedentes ................................................................................................. 17 Misión de la Oficina de Planificación Universitaria ......................................... 17 Visión de la Oficina de Planificación Universitaria.......................................... 17 Objetivos de la Oficina de Planificación Universitaria ........................................ 18 Objetivo General ............................................................................................ 18 Objetivos Específicos..................................................................................... 18 Aspectos Administrativos................................................................................... 18 Estructura orgánica ........................................................................................ 18 Funciones del área de TI................................................................................ 19 Organigrama de la Oficina de Planificación Universitaria............................... 21 Elementos de TI de la OPLAU........................................................................... 22 Recurso humano ............................................................................................... 22 Protocolos de comunicación .............................................................................. 22 Metodología........................................................................................................... 23 Etapas del proceso de auditoría ........................................................................ 24 Planificación de la Auditoría............................................................................... 24 Planificación preliminar .................................................................................. 24 Planificación detallada ................................................................................... 24 Alcance .......................................................................................................... 25 Ejecución........................................................................................................ 25 vii Programas de la auditoría ..................................................................................... 28 Comunicación de resultados ................................................................................. 56 Informe ejecutivo ............................................................................................... 57 Origen de la Auditoría .................................................................................... 57 Objetivo de la auditoría...................................................................................... 57 Cumplimiento con normas de auditoría ............................................................. 58 Período de revisión............................................................................................ 58 Limitaciones al alcance...................................................................................... 59 Resumen ejecutivo ............................................................................................ 59 Informe final de auditoría...................................................................................... 60 Carta de Presentación.................................................................................... 60 Observaciones y recomendaciones................................................................... 61 Bibliografía consultada .......................................................................................... 74 1 Resumen El objetivo general de esta Auditoría es la evaluación de la metodología de desarrollo de sistemas de información utilizada por los desarrolladores de la Oficina de Planificación Universitaria de la Universidad de Costa Rica, con el fin de identificar los principales aspectos sujetos a mejora, para lo cual se establecerán una serie de recomendaciones cuya implementación coadyuvará con la gestión. Esta oficina se dedica, primordialmente, a contribuir en el proceso de planificación como un instrumento de desarrollo institucional. Es una oficina técnica y asesora en materia de planificación, presupuesto y evaluación de la Universidad de Costa Rica. La auditoría se llevará a cabo mediante la modalidad de una práctica profesional con base en los conocimientos y herramientas proporcionados durante los cursos impartidos en la Maestría en Auditoría de Tecnologías de Información. Una vez finalizada la aplicación de esta se procederá a redactar un informe final con los principales hallazgos y recomendaciones, esperando que la institución tenga una herramienta que ayude a solventar debilidades o bien reforzar aspectos que no se encuentre totalmente controlados. 2 Palabras clave: Control Interno Auditoría Ciclo de vida del software Métricas Director de la investigación Magíster Xiomar Delgado Unidad Académica: Programa de Posgrado en Administración y Dirección de Empresas Sistema de Estudios de Posgrado. 3 Introducción Evaluación de la metodología utilizada para el desarrollo de sistemas de información, la evaluación de procesamiento de la información por los mismos. Introducción La Oficina de Planificación Universitaria es una dependencia de la Universidad de Costa Rica (U.C.R.), la cual tiene como actividades principales la elaboración del plan estratégico de UCR, la evaluación de los planes estratégicos formulados por las unidades académicas y administrativas que conforman la U.C.R, además de la asignación de presupuesto institucional, así como la elaboración de información sensible para la toma de decisiones a nivel de la Rectoría y del Consejo Universitario (CU). También tiene entre sus funciones la elaboración de los sistemas de información institucionales, tales como Sistemas de Formulación de Presupuesto, Sistema de Formulación de Proyectos Institucionales, Sistemas de Recomendación de Presupuesto y Proyectos, Sistemas de Evaluación Plan Anual Operativo y demás. Ya que estos sistemas de información generan información sensible para la toma de decisiones para los altos niveles de la Universidad de Costa Rica, nace la necesidad de realizar una evaluación de las técnicas de desarrollo así como verificar la seguridad, la eficiencia y eficacia de estos. Al efectuar este estudio, se mostrará la situación actual de los controles y un análisis del ciclo de vida del desarrollo utilizado para asegurar la eficiencia y eficacia del proceso de desarrollo y de la confiabilidad de los resultados finales. El producto obtenido de la evaluación será de ayuda para la Oficina de Planificación Universitaria en la toma de decisiones, en caso de detectar aspectos sujetos de 4 mejora, y así poder tener herramientas más eficientes para la toma de decisiones por parte de los altos niveles de la Universidad de Costa Rica y de la Oficina de Planificación (OPLAU). Con la realización de este proyecto, se pondrán en práctica las técnicas, procedimientos y metodologías impartidas por profesionales expertos, quienes fungieron como profesores de los cursos. Limitaciones Debido a la sensibilidad de la información que manipula la OPLAU, se puede dar la posibilidad de que alguna información no se pueda facilitar si no es con el visto bueno del máximo jerarca de la Institución. Objetivo El estudio se realizará en el periodo comprendido entre Junio a Agosto del 2007, se enfocará en la evaluación de la metodología utilizada para el desarrollo de sistemas, así como la seguridad de los sistemas en producción “Sistema de Presupuesto y Proyectos Institucionales”; dichos sistemas poseen una plataforma cliente/servidor vía web, a los cuales tienen acceso alrededor de 2000 usuarios. 5 Objetivo general Comprobar la existencia y cumplimiento de procedimientos y políticas organizacionales para el desarrollo de sistemas, así como el cumplimiento de estos. Esto se realizara mediante los siguientes objetivos específicos: a. Constatar si la Administración formula y mantiene políticas de seguridad razonables para los sistemas de información. b. Comprobar la existencia de una metodología para el desarrollo de los sistemas de información. c. Verificar las políticas establecidas en cuanto a los controles de acceso, su autorización y difusión. d. Confirmar la pertinencia del procesamiento de los datos e. Evaluar los controles de acceso del Sistema de Información. El enfoque de la auditoría en el área de desarrollo es crucial pues es un sector que representa el manejo de información altamente sensible, un nivel de riesgo muy alto, donde, por su naturaleza, debe contar con controles que fortalezcan la seguridad, efectividad, eficiencia de los recursos, así como la integridad de la información. Se trata de verificar la existencia de esos controles y su evaluación, de manera que permita definir el alcance de las pruebas, con el fin de rendir un informe a las autoridades de la Oficina, que tome en consideración aportes y recomendaciones que proporcionen valor agregado a esta estancia y que sea factible de implementar. 6 Alcance La investigación estará dirigida a la revisión de la metodología aplicada en el desarrollo de sistemas de información del Área de Tecnologías de Información de la Oficina de Planificación de la Universidad de Costa Rica. En lo que se refiere al ciclo de vida del software, se hará una verificación en la administración del proceso de desarrollo y los mecanismos de control implementados para tal fin. El periodo que comprenderá el estudio se inicia en el mes de junio a agosto del 2007. 7 Capítulo I MARCO CONTEXTUAL 8 Ciclo de vida Historia “La necesidad de una metodología para el desarrollo del software se inicia en el año 1970, en donde se da un aumento significativo en la complejidad de las aplicaciones, donde la técnica de “code & fix” (codificar y corregir) no se adaptaba a las nuevas exigencias del mercado de desarrollo de aplicaciones informáticas. Esta técnica se basaba en requerimientos ambiguos y sin especificaciones puntuales.”1 Al no seguir normas para el proyecto, los clientes o usuarios sólo daban especificaciones muy generales del producto final. Se programaba, se corregía y se volvía a programar sobre la misma marcha del proyecto. Esta tarea no estaba administrada, no tenia supervisión ni era gestionadas de modo alguno modo, es decir se tenia que corregir a medida que surgían los errores, tantos los lógicos provenientes de la codificación, como los de requerimientos solicitados por el cliente o usuario final. El ciclo de vida de este tipo de proyectos finalizaba cuando se satisfacían las especificaciones, no solo las primeras por las cuales nació la necesidad del programa, sino, también todas aquellas que fueron surgiendo sobre la marcha. Como se puede observar, esta metodología de desarrollo es sumamente deficiente lo que implica una serie de desventajas para los productores y desarrolladores de software, en cuanto a tiempo y costo ya que lo planificado no siempre se cumple, es por esto que se inicia el planteamiento de una serie de metodologías para el desarrollo de proyectos informáticos y es así como nace la metodología Ciclo de vida del software. 1 usr.code, http://www.tectimes.com/lbr/Graphs/revistas/lpcu097/capitulogratis.pdf 9 Definición del “Ciclo de vida del software” La norma ISO 12207 define el ciclo de vida del software como “como un marco de referencia que contiene las actividades y las tareas involucradas en el desarrollo, la explotación y el mantenimiento de un producto software, abarcando desde la definición hasta la finalización de su uso”2. Otros autores definen el ciclo de vida del software como “el proceso por el cual los analistas de sistemas, los ingenieros de software, los programadores y los usuarios finales elaboran sistemas de información y aplicaciones informáticas”3. Según la Contraloría General de la República de Costa Rica (CGR) se puede entender el ciclo de vida de software como “conjunto de etapas que los usuarios, analistas, diseñadores de sistemas y otros funcionarios involucrados, realizan para desarrollar e implantar un sistema de información computadorizado” Las etapas del ciclo de vida del desarrollo de software (CVDS) son descritas por diversos autores, pero con diferencias en cuanto al número, denominación y detalle de estas, no obstante, en el fondo coinciden entre sí. Teniendo en cuenta estas definiciones, se puede decir que el ciclo de vida del software es una metodología que facilita la administración, supervisión, así como una forma de gestionar de manera ordenada, la implementación de una nueva aplicación informática o bien del mantenimiento de las existentes; además, el control de calidad también se ve facilitado si la separación entre fases se realiza de manera tal que se puedan verificar y llevar a cabo pruebas por separado sobre los productos parciales obtenidos. 2 ISO/IEC 12207:2002, AMENDMENT, Information Technology – Software Life Cicle Process. 3 Whitten J., Bentley L., Barlow V. 1996. 10 Modelos de ciclo de vida Existen diversos tipos de modelos de ciclo de vida; sus principales diferencias radican en: 1. El alcance. 2. Las características o contenidos de las fases en que se divide el ciclo. Tomando en cuenta que la Universidad de Costa Rica se encuentra bajo la supervisión de la Contraloría General de República, adoptaremos en la auditoría el modelo que esta institución propone para las entidades a su cargo, el cual está constituido por las siguientes etapas: 1. Estudio preliminar (303.05.01) 2. Estudio de factibilidad (303.05.02) 3. Análisis y determinación de los requerimientos de información (303.05.03) 4. Diseño conceptual del sistema (303.05.04). 5. Diseño físico del sistema (303.05.05). 6. Desarrollo de la programación (303.05.06). 7. Desarrollo de la documentación (303.05.07). 8. Prueba del sistema (303.05.08). 9. Implantación (303.05.09). 10. Evaluación post-implantación (303.05.10). 11 Métricas para el desarrollo de sistemas Es conveniente contar con un modelo para el desarrollo de aplicaciones informáticas, como se vio anteriormente, pero de igual forma existe la necesidad de contar con una metodología que arroje indicadores sobre la eficiencia, efectividad y calidad de las aplicaciones desarrolladas desde los primeros pasos de la metodología utilizada sin tomar en cuenta cuál sea está. Es por esta razón que durante el proceso de desarrollo es necesario implementar un sistema de métricas. Para el desarrollo de software podemos encontrar un sin número de metodologías para la aplicación de métricas en la producción de sistemas de información, entre las cuales podemos citar, por ejemplo, COCOMO, Métricas Bang, Métricas de calidad de especificaciones, FURPS (Funcionalidad, Facilidad de uso, Fiabilidad, Rendimiento, Capacidad de soporte), PF (puntos de fusión), pero lo más importante del uso de este tipo de herramientas es tener presente que medir por medir no es una buena técnica; lo más importante es saber interpretar y aplicar estas medidas para beneficio de la organización, con el fin de alinear los objetivos de TI con los objetivos de esta, lo cual, a fin de cuenta, es lo más importante. Estas técnicas de medición ofrecen a las organizaciones un instrumento útil para la sistematización que da soporte al ciclo de vida del software con el fin de alcanzar los siguientes objetivos para la organización: 1. Proporcionar sistemas de información que ayuden a conseguir los fines de la organización mediante el establecimiento de un marco estratégico para el desarrollo de estos. 2. Dotar a la organización de productos software que satisfagan las necesidades de los usuarios y dar una mayor importancia al análisis de requisitos. 12 3. Mejorar la productividad de los departamentos de Sistemas y Tecnologías de la Información y las Comunicaciones, permitiendo una mayor capacidad de adaptación a los cambios. 4. Facilitar la comunicación y entendimiento entre los distintos participantes en la producción de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, así como las necesidades de todos y cada uno de estos. 5. Facilitar la operación, mantenimiento y uso de los productos software obtenidos Es por esta razón que muchas normas y estándares destacan la importancia del uso de las métricas en el proceso de gobernabilidad de tecnologías de información; por ejemplo, Cobit 4.1 y el modelos CMMI incluyen en sus dominios métricas para de medir la eficiencia y efectividad de los procesos de desarrollo de sistemas de información computarizados. La metodología de indicadores es necesaria y de obligatoria aplicación durante cada una de las etapas que componen el ciclo de vida del software. 13 Reseña de la Universidad de Costa Rica Generalidades Historia Por decreto N.o 362 en el gobierno del Dr. Rafael Ángel Calderón Guardia, se fundó la Universidad de Costa Rica como una entidad dedicada a la educación superior. Propósitos y funciones fundamentales de la Universidad de Costa Rica El propósito de la Universidad de Costa Rica es “obtener las transformaciones que la sociedad necesita para el logro del bien común, mediante una política dirigida a la consecución de una verdadera justicia social, del desarrollo integral, de la libertad plena y de la total independencia de nuestro pueblo”. Para cumplir con tal propósito, la Universidad, la cual está constituida por una comunidad de profesores, estudiantes y funcionarios administrativos, está dispuesta a estimular la formación de una conciencia creativa, crítica y objetiva en los miembros de la comunidad costarricense, con el fin de permitir que los sectores populares tengan mayor participación en los diversos procesos de la actividad nacional. Las funciones de la Universidad de Costa Rica, son las siguientes: 1. Contribuir al progreso de las Ciencias, Artes, Humanidades y la técnica, reafirmando su interrelación y aplicándolas al conocimiento costarricense. 2. Estudiar los problemas de la comunidad y participar en proyectos con tendencia al pleno desarrollo de los recursos humanos, en función de un plan integral destinado a formar un régimen social justo, que elimine las causas de la ignorancia y la miseria y evite la indebida explotación de los recursos del país. 14 3. Contribuir a elevar el nivel cultural de la nación costarricense por la acción universitaria. 4. Impulsar y desarrollar la enseñanza e investigación de alto nivel. 5. Formar un personal idóneo el cual se dedique a la enseñanza, Ciencias, Artes y Letras para que participe eficazmente en el desarrollo del sistema de educación costarricense. 6. Proporcionar a los estudiantes una cultura superior de orden general, como base y complemento de la formación especial o profesional. 7. Mantener la libertad de cátedra como principio de la enseñanza universitaria, que otorga a los miembros del claustro plenas posibilidades para expresar sus convicciones filosóficas, religiosas y políticas. 8. Garantizar dentro del ámbito universitario el diálogo, la libre expresión de las ideas y opiniones, así como la coexistencia de las diferentes ideologías y corrientes del pensamiento filosófico, religioso o político, sin otra limitación que el respeto mutuo. 9. Formar profesionales en todos los campos del saber capaces de orientar, provechosamente para el país, las fuerzas productivas de la sociedad costarricense y crear una conciencia crítica en torno a los problemas de la dependencia y del subdesarrollo. 15 Estructura orgánica de la Universidad de Costa Rica Figura N.o 1 Como se observa en el organigrama anterior, la Universidad se rige por la Asamblea Universitaria, organismo de mayor jerarquía, donde reside la máxima autoridad de la Institución. Actúa por medio de dos órganos: la Asamblea Plebiscitaria y la Asamblea Colegiada Representativa. El Consejo Universitario es el organismo inmediato en jerarquía; tiene entre sus funciones definir las políticas generales institucionales y fiscalizar la gestión de la Universidad de Costa Rica. El Rector(a) es el funcionario de más alta jerarquía ejecutiva, ejerce la representación judicial y extrajudicial, lleva a cabo el control y la evaluación de las 16 actividades de la institución. Tiene un órgano asesor que es el Consejo de Rectoría, en el cual se canaliza su autoridad según corresponda. De la Rectoría dependen además las siguientes oficinas administrativas: Centro de Informática, Oficina Jurídica, Oficina de Asuntos Internacionales, Oficina Ejecutora del Plan de Inversiones y la Oficina de Planificación Universitaria. Estas oficinas están dedicadas a ciertas actividades específicas y se rigen por los reglamentos que apruebe el Consejo Universitario. En la Universidad funcionan las siguientes Vicerrectorías: Docencia, Investigación, Acción Social, Administración y Vida Estudiantil. La docencia se desarrolla en las unidades académicas y es coordinada por la Vicerrectoría de Docencia, de ella dependen las seis áreas docentes, Ciencias Sociales, Artes y Letras, Ciencias Básicas, Ciencias Agroalimentarias, Ingeniería y Salud. Además, existe la Asamblea de Facultad como órgano superior de la Facultad. Dichas asambleas se encargan de coordinar las distintas labores académicas y son presididas por un decano. Hay trece facultades, de las cuales nueve se dividen en escuelas y, por razones de tradición histórica, cuatro no. Actualmente, la Universidad cuenta con cuarenta y cuatro escuelas, que son unidades académicas a las que corresponde poner en práctica la enseñanza, la investigación y la acción social. La Investigación se realiza en las mismas unidades, en los centros e institutos de investigación, estaciones experimentales y en otras instancias similares, igualmente es coordinada por la Vicerrectoría de Investigación. La Acción Social es coordinada por la Vicerrectoría de Acción Social y la parte estudiantil se encarga la Vicerrectoría de Vida Estudiantil. 17 Situación Actual de la Oficina de Planificación Universitaria Generalidades Origen Antecedentes 4“La Oficina de Planificación Universitaria (OPLAU) fue creada por el Consejo Universitario en la sesión N.o 3082, del 17 de abril de 1984, como una oficina adscrita a la Rectoría; pero no fue sino a partir de enero de 1985 cuando inicia sus labores. Durante más de 20 años de existencia, la directriz orientadora de su labor ha sido la búsqueda del desarrollo institucional mediante la aplicación del proceso de planificación en el quehacer institucional.” Misión de la Oficina de Planificación Universitaria Liderar la planificación universitaria, mediante el fortalecimiento de una cultura que promueva el desarrollo y la excelencia de la Institución. Visión de la Oficina de Planificación Universitaria Ser una oficina proactiva que permanezca a la vanguardia en las tendencias de planificación, para fortalecer el liderazgo en la comunidad universitaria y contribuir con el desarrollo institucional. 4 Universidad de Costa Rica (2007). Oficina de Planificación Universitaria (2007). Consultado febrero del 2007 en la página http://www.oplau.ucr.ac.cr 18 Objetivos de la Oficina de Planificación Universitaria Objetivo General Fortalecer la gestión y el desarrollo institucional para lograr de manera eficaz y eficiente, los fines institucionales, con base en un proceso ordenado y sistemático de planificación, congruente con las demandas del entorno. Objetivos Específicos Desarrollar, de manera permanente, un sistema de información, eficaz y eficiente, que permita la óptima toma de decisiones en los distintos niveles jerárquicos. Procurar el desarrollo óptimo de la gestión de planificación, al contribuir de este modo, con el beneficio social; como corolario de la inversión realizada por la sociedad en la educación superior. Aspectos Administrativos Estructura orgánica La Oficina de Planificación Universitaria (O.PLA.U.) está a cargo de la Directora que es la persona encargada de dirigir la Oficina. Su nombramiento o remoción lo realiza la Rectoría, de conformidad con el Estatuto Orgánico y el Reglamento General de Oficinas Administrativas. Esta conformada por un Consejo Técnico Asesor y cuatro Secciones, dentro de las cuales figura la Sección de Tecnologías de Información. Esta Oficina también posee una Unidad de Servicios Administrativos. Los principales objetivos de esta sección son: 1. El Consejo Técnico Asesor está conformado por la Dirección y por las jefaturas de las secciones de la OPLAU. Su objetivo es analizar y 19 recomendar los asuntos que la Dirección o las jefaturas de las secciones sometan a consideración con el fin de dar soluciones integrales. 2. La Sección de Planeamiento es la encargada de fortalecer el desarrollo institucional, mediante el establecimiento de un sistema efectivo de planeamiento; basado en estrategias de cambio que permitan a la Universidad cumplir pertinentemente con su misión. 3. La Sección de Presupuesto tiene como propósito desarrollar los procesos presupuestarios, como una herramienta de gestión que coadyuva con el desarrollo institucional, al expresar, en términos monetarios, las acciones contempladas en los planes institucionales, de manera que los recursos asignados se utilicen pertinentemente, eficaz y eficientemente. De esta sección depende la Unidad de Autoevaluación y Administración de Riesgo. 4. La Sección de Evaluación contribuye en el desarrollo institucional, por medio de la evaluación crítica y prospectiva de los resultados de la planificación, de modo que la información resultante coadyuve con la definición de políticas, estrategias y acciones, pertinentes y oportunas. A la vez, esta sección cuenta con una dependencia denominada Unidad de Autoevaluación y Administración del riesgo. 5. La Sección de Tecnologías de Información. Es la encargada de generar sistemas de información y utilizar la tecnología en beneficio de la gestión de planificación y el desarrollo institucional. De ella depende el Sistema de Información Geográfico. Funciones del área de TI. 1. Analizar, diseñar, documentar e implementar sistemas de información, tanto para uso institucional, como para los procesos internos de la Oficina. 2. Mantener actualizados los sistemas de información y sus bases de datos. 3. Procesar información generada por otras dependencias, con el fin de realizar estudios específicos encomendados a la Oficina. 4. Coadyuvar en el desarrollo y la integración del proceso de planificación. 20 5. Colaborar con las diferentes secciones, en los respectivos procesos de planeamiento, presupuestación y evaluación. 6. Velar por el buen funcionamiento de los equipos de cómputo de la Oficina, así como del software que estos utilizan. 7. Capacitar a los funcionarios de la Oficina en las distintas herramientas informáticas en uso. 8. Brindar asesoría en el campo informático a los usuarios de los sistemas desarrollados por la Oficina. 9. Investigar los aspectos relacionados con nuevas tecnologías de información, para fortalecer los procesos que lleva a cabo la Oficina y coadyuvar con el desarrollo institucional. 10. Participar, de manera proactiva en comisiones institucionales e interinstitucionales. 11. Participar en equipos de trabajo que se integran en la Oficina, con el fin de asesorar los procesos de planeamiento estratégico en las unidades, o para desarrollar procesos a nivel interno en la Oficina. 12. Suministrar conocimiento en TI a la dependencia que requiere interactuar con los sistemas de información de la OPLAU. 21 A continuación se muestra el organigrama interno de la Oficina Organigrama de la Oficina de Planificación Universitaria Figura N.o 2 Fuente: OPLAU 22 Elementos de TI de la OPLAU. La Oficina utiliza, en el desarrollo de su gestión, el siguiente equipo: Cantidad Tipo de Equipo Especificaciones 30 Computadoras personales de escritorio. Procesador Pentium 4 de 2.8 Ghz. Con 256 Mhz de memoria RAM. Con un disco duro de 80 Ghz. 2 Servidores de alto rendimiento Procesador Xeon de 2.8 Ghz. 5 discos duros de 72 Ghz cada uno. 4 Ghz de memoria RAM. 2 Servidores de rendimiento medio Procesador Xeon 2.8 Ghz. 3 discos duros de 72 Ghz. 1 Ghz de memoria RAM. 2 Impresoras Láser HP 3 Impresoras Epson de Inyección de Tinta 2 Switches Cisco WS-C2950T- 24 34 Conexiones de red (roja) 1 Conexión de red (azul) Recurso humano El área de TI de la OPLAU esta compuesta por el siguiente recurso humano: • Una jefatura. • Tres analistas-desarrolladores. Protocolos de comunicación • En la actualidad, toda la red local se comunica mediante TCP / IP y es el mismo protocolo que se utiliza para la comunicación remota. • En este momento internamente se están migrando los archivos de un servidor con Novell, por lo que en menor medida se utiliza IPX como protocolo de comunicaciones. 23 Capítulo II METODOLOGÍA 24 Etapas del proceso de auditoría En la realización del proceso de auditoría se plantean las siguientes etapas a saber: Planificación de la Auditoría, Alcance de la Auditoría, Evidencia de la Auditoría y Comunicación de Resultados. Lo anterior tomando como guía el Manual de Normas Generales de Auditoría para el Sector Público, publicado en el diario oficial La Gaceta N.o 236 del 18 de diciembre de 2006. Planificación de la Auditoría Planificación preliminar En esta sección se debe obtener información general sobre el asunto objeto de estudio. En tal caso se determina la viabilidad de efectuar la auditoría de acuerdo con el objetivo establecido y además se deben identificar las actividades sustantivas para establecer las áreas de indagación. De esta forma se recopila y revisa información con el fin de determinar la más relevante para la auditoría en la Sección de Tecnologías de Información, para lo cual se recurre la aplicación de entrevistas y cuestionarios, así como a la observación de los diferentes procesos que se consideren importantes para el estudio. Es relevante definir en esta etapa los criterios de evaluación, con base en los cuales se examinarán las condiciones existentes, para lo cual el auditor podrá acudir a diversas fuentes, según su juicio profesional, como serían los indicadores de gestión establecidos por el propio sujeto de auditoría, las mejores prácticas y los organismos profesionales. Planificación detallada En la planificación detallada se deben establecer las áreas críticas objeto de examen. En este apartado es necesario obtener una comprensión más detallada de los aspectos encontrados en la planificación preliminar; asimismo, se establecerán los objetivos de la auditoría en la Sección de Tecnología de Información, específicamente en cuanto a seguridad física y lógica de la granja de servidores que administra esa sección. 25 Alcance El alcance se establecerá en función de las conclusiones que se deriven de la planificación preliminar. Debe estar orientado hacia los asuntos que serán objeto de estudio, la naturaleza y oportunidad de las pruebas, el período y el enfoque de la auditoría. En este apartado se debe especificar claramente el objeto de la evaluación en la entidad u órgano de que se trate, lo cual puede comprender elementos como operaciones, programas, actividades, unidades o procesos. Ejecución Durante la etapa se deben ejecutar los programas específicos para alcanzar los objetivos de la auditoría; comprende una serie de actividades, tales como: realizar pruebas, evaluar controles y recolectar la evidencia necesaria, utilizando para ello técnicas y prácticas de auditoría estudiadas en los cursos impartidos en la maestría, para obtener, justificar y presentar apropiadamente los hallazgos de auditoría, con sus atributos de criterio, condición, causa y efecto. Comunicación de resultados Las instancias correspondientes deben ser informadas, verbalmente y por escrito, sobre los principales resultados, las conclusiones y las disposiciones o recomendaciones producto de la auditoría que se lleve a cabo, lo cual se constituirá en la base para el mejoramiento de los asuntos examinados. Sujetos y fuentes de información Para la recolección de información, se utilizaron como instrumentos el cuestionario y la entrevista. Según Roberto Hernández Sampiere, en su publicación “Metodología de la investigación”, páginas 108 – 171, el cuestionario “consiste en un conjunto de preguntas respecto de una o más variables” y la entrevista implica “que una persona calificada (entrevistador) aplica cuestionarios o preguntas a los sujetos participantes”. Se aplicó un cuestionario y una entrevista a las diferentes 26 personas que están directamente relacionadas con las tecnologías de información en el área de desarrollo de la Oficina de Planificación Universitaria de la Universidad de Costa Rica. Las personas entrevistadas y encuestadas fueron las siguientes: • Licda. Ana Francela Salazar, jefa de la Sección de Tecnologías de Información. • Ingeniero de Sistemas Francisco Rodríguez, Analista programador • Ingeniero de Sistemas Francisco Lee, analista programador • Ingeniero de Sistemas Bernardo Salguero, analista programador. Se consultaron documentos, archivos e informes referentes al tema de investigación; esto, con el fin de analizar las diferentes variables de estudio, entre ellos: • Directrices del Centro de Informática de la Universidad de Costa Rica • Manual de Normas Generales de Auditoría para el Sector Público, de la Contraloría General de la República • Ley General de Control Interno N.º 8292 y sus Normas Generales • Estatuto Orgánico de la Universidad de Costa Rica • Políticas de la Universidad de Costa Rica • Reglamento General de Oficinas Administrativas • Reglamento de la Oficina de Planificación Universitaria • Plan de Desarrollo Estratégico • Estructura organizativa de la Universidad de Costa Rica 27 Otras de las fuentes de información que se utilizaron fueron los libros y folletos sobre tecnologías de información, así como investigaciones realizadas sobre temas semejantes al objeto de estudio. Es muy importante destacar que debido a la naturaleza del estudio, durante todo el proceso se utiliza el método de observación que consiste en el registro sistemático, válido y confiable de comportamiento o conducta manifiesta. De esta forma, dicho método permite corroborar lo señalado en las entrevistas y cuestionarios, así como verificar y realizar pruebas en los procesos y procedimientos que se consideran relevantes en la auditoría. 28 Capítulo III Programas de la auditoría 29 En este capítulo se hace una breve descripción de los procedimientos que se siguieron en el desarrollo de la auditoría, además se muestran las herramientas e instrumentos aplicados en la recolección de la información y las personas entrevistadas y los procesos observados. La primer herramienta aplicada es un cuestionario de control interno con el fin de determinar la intensidad de las pruebas que se aplicaran así como para el desarrollo del programa de auditoria. Para cumplir con cada actividad del programa se diseñan papeles de trabajo y además de la aplicación de técnicas tales como entrevistas, visitas de observación, cuestionarios, los cuales servirán para la recolección de la evidencia competente y suficiente que justifiquen de forma idónea los hallazgos encontrados durante el proceso. Los machotes más significativos utilizados son los siguientes: 30 OBJETIVOS DE AUDITORÍA: Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado Real Dif. I. INFORMACIÓN A OBTENERSE EN LA SEDE DE LA FIRMA (UNIDAD) DE AUDITORÍA No. Procedimientos Ref. P/T Iniciales Auditor Fecha 1. Compruebe en la oficina de Auditoria Interna la existencia de un Archivo Permanente (AP) y el archivo corriente (AC) de la última auditoría; caso de existir, revise y complemente: a. La última fecha de actualización del AP a fin de determinar su utilidad; b. Obtenga los números telefónicos, fax, localización de la sede, dirección postal, dirección electrónica, página Web; c. La Ley de la entidad, sus reglamentos, decretos y otras disposiciones que regulan su funcionamiento y afines con las actividades sustantivas (Ej. Ley de Presupuesto, Control interno, Ley de Contratación, etc.); d. Confirme con el departamento legal de la FIRMA (ENTIDAD) la vigencia de las disposiciones obtenidas u obtenga del Web y otros medios una versión actualizada de las disposiciones; e. Los presupuestos de la entidad de los últimos dos años examinados; f. El organigrama y las funciones de cada sección administrativa; g. Los manuales de administración de personal, contabilidad, de compras y otras relacionadas con la gestión financiera y administrativa de la entidad; h. Los programa de auditoría, los cuestionarios u otros medios utilizados para conocer y evaluar el control interno; i. Los informes de planificación preliminar y detallada; j. El informe de control interno; k. El informe de la última auditoría; l. Los informes de la unidad de auditoría interna (UAI) de la entidad y de la Contraloría General de la República (CGR) – (SECTOR PÚBLICO) m. Las recomendaciones de los informes a los que se refiere los puntos k) l) y m) deberán obtenerse en papel o en formato electrónico para que facilite su seguimiento; n. Otra información que considere de utilidad para los propósitos de la 31 No. Procedimientos Ref. P/T Iniciales Auditor Fecha auditoría. Documente el trabajo realizado y deje evidencia de los papeles de trabajo que retira. II. INFORMACIÓN A OBTENERSE EN LA ENTIDAD AUDITADA. No. Procedimientos Ref. P/T Iniciales Auditor Fecha 3. Solicite una cita con la máxima autoridad de la entidad para desarrollar la siguiente agenda: a. Entrega del oficio de presentación de la FIRMA (UNIDAD) DE AUDITORÍA; b. Explicación de los objetivos y el alcance de la auditoría. c. Expectativas que tiene de la presente auditoría; d. Solicitud de oficinas para el equipo y otras facilidades logísticas indispensables; e. Designación de un coordinador para tratar asuntos de la auditoría; f. Apreciaciones y criterios personales sobre los siguientes temas: • Principales actividades sustantivas y coordinación con otras entidades gubernamentales o de la universidad de Costa Rica, para apoyar su desarrollo. • Los riesgos que percibe y los controles que se han implementado para desarrollar las actividades principales; • Fortalezas y debilidades del sistema de recursos humanos y en qué grado se fundamenta en el mérito, la evaluación del desempeño, la conducta ética, la estabilidad por competencia; y en qué grado se aplican; • Grado de entendimiento sobre los planes, objetivos, estrategias y expectativas institucionales; • La rendición de cuentas y formas de llevarla a cabo en la entidad; • Evaluación general que le daría al ambiente de control interno en la entidad entendido como presencia de valores éticos, planificación estratégica, organización, sistema de recursos humanos, apoyo de la auditoría interna; • Otros aspectos de importancia que se estime necesario; Prepare una narrativa sobre los resultados de esta visita y documente hasta donde sea posible. 32 No. Procedimientos Ref. P/T Iniciales Auditor Fecha 4. Con la ayuda del coordinador institucional confirme los datos de la información recopilada sobre la entidad en la sede de la FIRMA (UNIDAD) DE AUDITORÍA, de faltar alguna obténgala vía el coordinador: a. La vigencia de las disposiciones legales, de ser necesario obtenga una versión actualizada de las disposiciones; b. Planes estratégicos y otras formas de planificación de corto, mediano y largo plazo; c. El organigrama y las funciones de las secciones que componen la OPLAU d. Los manuales administrativos y financieros; e. Los presupuestos de los últimos dos años examinados; f. Los nombres, cargos, ubicación, números telefónicos y de fax de los actuales funcionarios de las entidades vinculadas al examen. Prepare una narrativa sobre los resultados de esta confirmación de datos y documente hasta donde sea posible. 5. Con la participación del coordinador institucional realice un recorrido por las instalaciones relacionadas con el examen, tratando de identificar, entre otros aspectos: a. Funciones que se realizan en las distintas oficinas o unidades visitadas; b. Haga énfasis en conocer al personal que participa en los procesos de ingresos, desembolsos, adquisiciones, prestación de los servicios u otras actividades sustantivas, administración de personal, custodia, autorización, registro, controles previos, y otros comunes a toda organización (para esta acción será conveniente disponer de un flujograma o elaborar uno con base en el recorrido. Igualmente será útil tener bien identificado el ciclo de las operaciones); c. Consulte durante su visita en localización de los archivos ; d. En todo caso preocúpese porque al final del recorrido usted conozca o identifique claramente al personal clave en cada departamento; e. También determine en qué grado los sistemas de información se llevan manual o electrónicamente? Prepare una narrativa y flujogramas sobre los resultados de esta visita y documente hasta donde sea posible ELABORADO: _______________ SUPERVISADO: ______________ FECHA: _______________ FECHA: ______________ Programa Auditoria etapa de diseño 33 Objetivo 1: Evaluar las metodologías utilizadas en la organización para el diseño de sistemas y las especificaciones del diseño del sistema contra los requerimientos del usuario. Criterio: COBIT AI2.1 La metodología de desarrollo de la organización debe estipular la aplicación de técnicas y procedimientos apropiados en estrecha relación con los usuarios del sistema, en la creación de las especificaciones del diseño. Además de cumplir con las normativas dictadas por la Contraloría General de la Republica en el “Manual de normas técnicas de control interno relativas a sistemas de información” en el cual se cita que todas las organizaciones supervisadas por este ente, deben contar con una metodología para el desarrollo de aplicaciones informáticas. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia una metodología documentada para el diseño de sistemas. 2 Verificar que la metodología autorizada, es del conocimiento de los desarrolladores de sistemas y además la ponen en práctica para el diseño. 3 Verificar que la metodología vincula al usuario en la creación de las especificaciones de diseño y que estas especificaciones se relacionan con los requerimientos del usuario. 4 Verificar que la metodología considera aspectos del diseño como: • la entrada, • procesamiento, • salida, • controles internos, • seguridad, • recuperación en caso de desastre, • tiempo de respuesta, • reportes, • control de cambios del sistema. 5 Verificar que los usuarios clave de los sistemas están involucrados en el proceso de diseño del sistema. 6 Verificar que la revisión del diseño y el proceso de aprobación aseguran que todos los problemas han sido resueltos antes de comenzar a trabajar sobre las siguientes fases del proyecto. 34 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 7 Verificar en el procedimiento: • quién hace, • cuando y cómo, • cuáles formas se utilizan en el sistema, • si son necesarias • número de copias que se mantiene y • validar la existencia de puntos de control. Objetivo 2: Evaluar los procesos de autorización de los diseños de sistemas para asegurar que la programación del mismo no inicie hasta que estén todas las aprobaciones en orden. Criterio COBIT AI2.3 Se requiere que las especificaciones de diseño para todos los proyectos de desarrollo sean revisadas y aprobadas por la Gerencia, por los departamentos usuarios afectados y por la alta gerencia de la organización, cuando esto sea pertinente. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia de un documento para el control de aprobaciones o que se documentan las aprobaciones de los diseños. 2 Verificar que las aprobaciones hayan sido extendidas por las personas pertinentes. 3 Verificar que los módulos que se están programando cuenten con todos los diseños debidamente aprobados 4 Verificar que la utilización de herramientas de diseño fueron evaluadas de conformidad con el sistema que se va a desarrollar, identificar cómo se usará la herramienta de diseño y si la misma se ajusta al procedimiento. Objetivo 3: Evaluar la definición y documentación de los requerimientos de archivos para comprobar si son consistentes con los estándares existentes. 35 Criterio: COBIT AI2.4 La organización debe asegurar la aplicación de un procedimiento apropiado para la definición y documentación del formato de los archivos para cada proyecto de desarrollo. Este procedimiento deberá garantizar el respeto a las reglas de diccionario de datos. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia de procedimientos documentados para la definición del formato de los archivos para el proyecto. Verificar que los documentos estén actualizados, autorizados y sean del conocimiento de los desarrolladores de sistemas. 2 Verificar que el diseño de los archivos se apega a las necesidades del sistema. 3 Verificar que en el diseño del sistema se contemplan procedimientos definidos para el manejo de archivos. 4 Comprobar que el diseño físico del sistema (según el detalle definido en el diseño conceptual) esté documentado. 5 Verifique que en los procedimientos se establezca como mínimo la descripción de los siguientes elementos: • Entradas al sistema • Tipos de transacciones • Documentos fuente • Formularios • Responsable de rellenar formularios • Resoluciones • Técnicas • Métodos de procesamiento • Interfaces del sistema • Estructura de los archivos • Requerimientos de hardware • Requerimientos de software 36 Objetivo 4: Evaluar las especificaciones de los programas para asegurar que estas concuerdan con las especificaciones de diseño. Criterio: COBIT AI2.5 Deben estar por escrito las especificaciones detalladas de los programas para cada proyecto de desarrollo. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia por escrito de las especificaciones de los programas. 2 Verificar la existencia de documentación sobre el sistema de conformidad con los requerimientos, así como el conocimiento de éste por parte de los integrantes del equipo de desarrollo. 3 Verificar que las especificaciones hayan sido aprobadas por las instancias competentes 4 Verificar que las especificaciones en el diseño estén de acuerdo con la arquitectura y las tecnologías seleccionadas para el sistema. 5 Compruebe que en esta etapa se encuentran contempladas las siguientes actividades: • La codificación de los módulos que componen los programas. • La compilación de los módulos que componen los programas. • La prueba y depuración de los módulos que componen los programas. • El desarrollo de la documentación adecuada. 37 Objetivo 5: Evaluar los mecanismos para la recopilación y entrada de datos de cada nuevo proyecto de desarrollo para verificar la concordancia entre el diseño de la entrada de datos y la recolección de los mismos. Criterio: COBIT AI2.6 El diseño de los sistemas de la organización deben especificar de mecanismos adecuados, para la recopilación y entrada de datos para cada proyecto. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia de diagramas de flujo de datos debidamente documentados. 2 Verificar que todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas estén claramente identificadas. 3 Verificar la existencia de un diccionario de datos documentado en el cual se representan explícitamente las relaciones entre los objetos de datos y los distintos objetos que los manipulan en el sistema. 4 Verificar que el diccionario de datos se encuentra aprobado por las personas pertinentes. 5 Verificar que en el diseño se aplica el concepto de ocultación de información, esto es, que los datos que utiliza cada módulo son estrictamente necesarios, no más, no menos. 6 Verificar que en el diseño se han establecido todos los controles de programación para evitar la entrada de datos no necesarios o con errores de digitación. 38 Objetivo 6: Evaluar los mecanismos, la definición y documentación de las interfaces internas y externas para cada proyecto de desarrollo para comprobar su existencia y pertinencia. Criterio: COBIT AI2.8 El diseño debe incluir todas las interfases internas y externas del sistema. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia de diagramas debidamente documentados que ilustran el flujo de datos entre las interfaces del sistema. 2 Verificar la pertinencia de los diagramas con los distintos módulos del sistema y sus pasos de datos. Además, verificar que los diagramas están en concordancia con los requerimientos de datos. 3 Verificar que los diagramas están aprobados por la o las personas pertinentes. 4 Verificar que los diagramas son conocidos y utilizados por todos los desarrolladores del sistema. 5 Verificar que se comprueba todo el flujo de datos de módulo a módulo para asegurarse de que los datos se ajustan a los límites establecidos durante el análisis. 6 Verificar que las interfaces de comunicación con otros sistemas incluyen comunicación con todas las arquitecturas y sistemas que se requiera en la organización. 7 Verificar que para las interfaces que se comunican con entes externos o viceversa se han diseñado con todas las medidas de seguridad requeridas. 39 Objetivo 7: Evaluar los mecanismos para la recopilación y entrada de datos de cada nuevo proyecto de desarrollo para verificar la concordancia entre el diseño de la entrada de datos y la recolección de los mismos. Criterio: COBIT AI2.6 El diseño de los sistemas de la organización deben especificar de mecanismos adecuados, para la recopilación y entrada de datos para cada proyecto. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF . P/T AUDITOR FECHA 1 Verificar la existencia de diagramas de flujo de datos debidamente documentados. 2 Verificar que todas las estructuras de datos y las operaciones a llevar a cabo en cada una de ellas estén claramente identificadas. 3 Verificar la existencia de un diccionario de datos documentado en el cual se representan explícitamente las relaciones entre los objetos de datos y los distintos objetos que los manipulan en el sistema. 4 Verificar que el diccionario de datos se encuentra aprobado por las personas pertinentes. 5 Verificar que en el diseño se aplica el concepto de ocultación de información, esto es, que los datos que utiliza cada módulo son estrictamente necesarios, no más, no menos. 6 Verificar que en el diseño se han establecido todos los controles de programación para evitar la entrada de datos no necesarios o con errores de digitación. 7 Verificar que en el diseño se han reducido al máximo las entradas de datos para minimizar el error por digitación. 8 Verificar que se han diseñado todas las ayudas posibles para el usuario en cuanto a la entrada de datos al sistema. 9 Verificar que no existen entradas de datos innecesarias, por ejemplo, verificar la utilización de máscaras de entrada. 40 Objetivo 8: Evaluar el diseño de la interfase usuario-máquina para garantizar que los usuarios no tendrán problemas para utilizar el sistema debido a la claridad con que se comunicarán con el mismo. Criterio: COBIT AI2.9 El diseño debe especificar una interfase usuario-máquina fácil de utilizar y que sea capaz de auto documentarse. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verificar la existencia documentada de modelos de diseño de interfaz de usuario. 2 Verificar que para el diseño de los modelos se tomó en cuenta la participación de los usuarios que utilizarán el sistema, los desarrolladores y los analistas de sistemas. 3 Verificar que existan los modelos de diseño (creado por el ing. en sistemas), el modelo del usuario (percepción del sistema) y verificar que se han conciliado satisfactoriamente ambos modelos. 4 Verificar que los modelos están debidamente autorizados por las personas pertinentes. 5 Verificar que el modelo de diseño incorpora representaciones de datos, arquitecturas de interfaces y procedimentales del software. 6 Verificar que para el diseño de interfaces se han utilizado herramientas que permiten hacerse una idea clara del sistema. 41 Programa etapa de desarrollo Objetivo 1: Evaluar si el desarrollo de sistemas de información cumple con las necesidades de la organización y con las políticas organizacionales. Criterio: Tomado del “Manual Sobre Normas Técnicas de Control Interno Relativas a Los Sistemas de Información Computadorizados” de la Contraloría General de la República. 303.01 Desarrollo en concordancia con los planes y las políticas del SIC. El desarrollo de los SIC constituye el conjunto de actividades predefinidas y estructuradas sistemáticamente, para la obtención de sistemas con un alto nivel de calidad, que permitan el logro de los objetivos o fines especificados por el usuario. Los sistemas de información computadorizados que se desarrollen, por principio, deben estar enunciados en el plan estratégico y en el plan anual operativo relativo al SIG. El desarrollo de los SIC se efectuará teniendo como base fundamental el plan estratégico, el plan anual operativo y las políticas relativas al SIG. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Determine la existencia de políticas relativas al desarrollo de sistemas de información computadorizados. 2 Verifique la existencia de planes estratégicos y operativos relativos a sistemas de información computadorizados. 3 Verifique la existencia de una metodología documentada para el desarrollo de sistemas. 4 Determine que la metodología es del conocimiento de los desarrolladores de sistemas. 5 Verifique que los usuarios de los sistemas están involucrados en el proceso de desarrollo de esos sistemas. 42 Objetivo 2: Evaluar la existencia y aplicación del manual de estándares en la organización. Criterio: Tomado del “Manual Sobre Normas Técnicas de Control Interno Relativas a Los Sistemas de Información Computadorizados” de la Contraloría General de la República. 303.02 Manual de estándares para el desarrollo de los sistemas de información computadorizados (SIC) Se establecerá y mantendrá actualizado un Manual de estándares para el desarrollo de los SIC. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique la existencia de un manual de estándares para el desarrollo de los sistemas de información computadorizados. 2 Determine que el manual de estándares detalla los procedimientos necesarios para guiar dicha actividad 3 Verifique que el manual haya sido aprobado por la instancia competente en la organización. 4 Determine la existencia de mecanismos empleados por la organización para garantizar la actualización permanente del manual. 5 Verifique que los manuales de estándares se revisan y actualizan periódicamente de acuerdo con los procedimientos definidos para tal fin. 6 Verifique que se propicia la divulgación necesaria del manual a los funcionarios pertinentes. 43 Objetivo 3: Identificar la definición del proyecto de desarrollo y su ejecución. Criterio: Tomado del “Manual Sobre Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados” de la Contraloría General de la República. 303.03 Proyecto de desarrollo del SIC. Se preparará un proyecto para cada SIC que se pretenda desarrollar, así como para los que sean objeto de modificaciones importantes. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique la existencia de un plan detallado de actividades técnicas y administrativas orientadas a desarrollar e implantar dicho sistema. 2 Verifique que el plan se encuentre debidamente documentado. 3 Solicite a la Jefatura de la Unidad Informática la documentación que define la metodología del ciclo de vida para el desarrollo de sistemas establecida por la organización. 4 Verifique que en la práctica, el equipo de desarrollo utiliza las técnicas y/o estándares de programación establecidas en el plan. 5 Revise la metodología del ciclo de vida de desarrollo de sistemas en lo relativo a la documentación relacionada con la definición del proyecto. 6 Compare lo que establece la metodología del ciclo de vida de desarrollo de sistemas en lo relativo a la documentación de la definición del proyecto, con la documentación del proyecto para verificar que se hayan contemplado todas las especificaciones. 7 Verifique que el Plan del proyecto establezca claramente su objetivo y alcance. 8 Verifique que el plan del proyecto establezca la asignación de recursos (humanos, financieros, materiales y tecnológicos) y tiempos necesarios para su desarrollo. 9 Confirme con los analistas de sistemas que conocen la metodología del ciclo de vida de desarrollo de sistemas utilizada por la organización. 44 Objetivo 4: Verificar que el desarrollo se lleve a cabo de conformidad con las especificaciones establecidas en el diseño del proyecto. Criterio: Tomado del “Manual Sobre Normas Técnicas de Control Interno Relativas a Los Sistemas de Información Computadorizados” de la Contraloría General de la República. 303.05.06 Desarrollo de la programación Los programas requeridos por el SIC se desarrollarán de conformidad con las especificaciones definidas en el diseño físico y se preparará la documentación respectiva. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique que el programador estudia, analiza y sigue las especificaciones preparadas por el analista durante la etapa de diseño físico. 2 Verifique que se mantienen los lineamientos establecidos en el diseño, relacionados con: • codificación, • compilación, • prueba y • depuración de los módulos que integran los sistemas. 3 Verifique que se detectan y corrigen los errores de sintaxis y de lógica, y se genera la respectiva documentación. 4 Verifique que los resultados alcanzados por los programas durante la realización de las pruebas en la etapa de desarrollo, cumplen con las especificaciones definidas en el diseño físico. 5 Solicite y revise la documentación que corrobore la prueba de los módulos que integran los programas. 6 Revise que los nombres de: 1. las variables, 2. procedimientos, 3. funciones, 4. programas, 5. pantallas, 6. reportes y 7. archivos, Se han especificado de conformidad con los estándares definidos. 7 Verifique que el desarrollo de los sistemas se lleva a cabo en un ambiente controlado y seguro, según la ISO 17799: • verifique que existe la seguridad física y ambiental pertinentes para el desarrollo del sistema de información 45 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA • corrobore la existencia de responsables para el manejo de las comunicaciones y de las operaciones durante el proceso de desarrollo • corrobore se cuenta con mecanismos para preservar la seguridad del software • verifique el desarrollo en ambientes controlados • verifique que se mantienen los respaldos necesarios del sistema • control de versiones del código fuente Objetivo 5: Verificar la existencia y gestión del responsable o administrador del proyecto de desarrollo de SIC. Criterio: Tomado del “Manual Sobre Normas Técnicas de Control Interno Relativas a Los Sistemas de Información Computadorizados” de la Contraloría General de la República. 303.04 Administrador del proyecto de desarrollo del SIC Se nombrará un funcionario que tendrá la responsabilidad directa de planear, organizar, dirigir, coordinar y controlar el proyecto de desarrollo del SIC. Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique la existencia de un responsable o director del proyecto. 2 Solicite al responsable o director del Proyecto la documentación que define el desarrollo de la programación del sistema solicitado. 3 Verifique que sus funciones incluyan el trabajar como enlace entre los usuarios, analistas, programadores y la jefatura de la Unidad de Informática 4 Verificar la existencia de los mecanismos de retroalimentación establecidos para el proyecto. 46 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/h Real/h Dif. N.º PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 5 Verifique que se da seguimiento de los mecanismos de retroalimentación establecidos para el proyecto. 6 Verifique que se hayan establecido los controles y medidas necesarias para contrarrestar los riesgos inherentes relativos al desarrollo de los sistemas de información computadorizado. 7 Verifique si los costos y plazos del proyecto son seguidos por un responsable designado para el seguimiento del proyecto. 8 Verifique la existencia de desviaciones presupuestarias significativas y si éstas se han documentado, comunicado y aprobado por las autoridades competentes en la organización. 47 Programa etapa de implementación Objetivo 1: Verificar que los procesos de capacitación de sistemas de información cuenten con adecuados planes de pruebas para garantizar el correcto funcionamiento de los desarrollos. Criterio: Inciso 303.05.08 Pruebas del sistema. Según el “Manual de normas técnicas de control interno relativas a sistemas de información” Contraloría General de la Republica, se ddeberán realizarse las pruebas necesarias y precisas con el fin de garantizar la que confiabilidad y la funcionalidad así como conformidad de las especificaciones establecidas. Según el Objetivo PO10 de Planeación y Organización de COBIT, en su apartado número 10 de Administración de Proyectos, en el 10.11 se establece: “El marco de referencia de administración de proyectos de la organización deberá requerir la creación de un plan de pruebas para cada proyecto de desarrollo, implementación y modificación.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique la existencia de planes de pruebas para cada proyecto de desarrollo o modificación de sistemas de información. 2 Corrobore que cuente con la aprobación correspondiente 3 Confirme el uso de los planes de pruebas de sistemas en los proyectos de desarrollo de la entidad. 4 Verifique que los planes de pruebas son de conocimiento de los usuarios y de los consultores o desarrolladores. 5 Constate que se presentan informes sobre los resultados de dichas pruebas. 6 Confirme con la autoridad competente el uso de los resultados de los planes de pruebas en los desarrollos contratados o realizados. 7 Corrobore que las pruebas realizadas en los desarrollos contratados o realizados quedan debidamente documentadas. 48 Objetivo 2: Verificar que los procesos de implementación de sistemas de información cuenten con adecuados planes de entrenamiento con el fin de garantizar el conocimiento y manejo de los productos adquiridos y/o desarrollados por parte de los usuarios. Criterio: Según el Objetivo PO10 de Planeación y Organización de COBIT, en su apartado número 10 de Administración de Proyectos, en el 10.12 se establece: “El marco de referencia de administración de proyectos de la organización deberá requerir la creación de un plan de entrenamiento para cada proyecto de desarrollo, implementación y modificación.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Solicite el plan de entrenamiento desarrollado por la organización empleado en proyectos de desarrollo, implementación y modificación 2 Verifique que cuenta con la aprobación correspondiente. 3 Corrobore la existencia de un funcionario responsable de dar seguimiento a los procesos de capacitación de los desarrollos de sistemas. 4 Verifique que los funcionarios responsables del uso de los sistemas de información reciben la capacitación apropiada. 5 Determine el cumplimiento de todos los módulos o etapas establecidas en el plan de entrenamiento. 6 Corrobore la presencia de los funcionarios responsables del funcionamiento del sistema 7 Verifique que el personal asignado para el proceso de implementación está debidamente calificado. 49 Objetivo 3: Determinar que el proceso de capacitación de los sistemas de información ha generado los beneficios planeados. Criterio: Según el Objetivo PO10 de Planeación y Organización de COBIT, en su apartado número 10 de Administración de Proyectos, en el 10.13 se establece: “El marco de referencia de administración de proyectos de la organización deberá requerir que, como parte integral de las actividades del equipo del proyecto, se desarrolle un plan de revisión post-implementación para cada sistema de información nuevo o modificado, con la finalidad de determinar si el proyecto ha generado los beneficios planeados.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Solicite el plan de revisión post-implementación desarrollado por la organización empleado en proyectos de desarrollo, implementación y modificación 2 Verifique que cuenta con la aprobación correspondiente. 3 Corrobore la existencia de un funcionario responsable de dar seguimiento a las pruebas desarrolladas en dicho plan. 4 Verifique que se completan los procesos de capacitación de los usuarios establecidos o que lo requieren para cada desarrollo. 5 Corrobore que se documentan las desviaciones con los beneficios planteados o esperados por la organización para cada desarrollo. 6 Verifique las acciones tomadas por la dirección o autoridad competente sobre las desviaciones que se presentan para cada proceso de implementación de sistemas. 7 Constate el cumplimiento de los cronogramas establecidos para cada proceso de implementación, así como la revisión y corrección de los ajustes pertinentes. 50 Programa etapa de documentación Objetivo 1: Validar que la documentación del sistema de información se desarrolló de conformidad con lo establecido en el Manual de estándares. Criterio: Según el “Manual Sobre Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados” de la Contraloría General de la República, en el inciso 304 Desarrollo de la documentación “La documentación de los SIC se desarrollará de acuerdo con lo establecido en el Manual de estándares.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Determine la existencia de Manuales relacionados con los sistemas de información computadorizados. 2 Verifique que se encuentren debidamente aprobados 3 Corrobore que la documentación del sistema considere los procedimientos básicos considerados en el Manual de estándares para el desarrollo de los SIC. 4 Verifique que el proceso de documentación se lleve a cabo desde el inicio del desarrollo de los sistemas. 5 Corrobore que la documentación esté completa y que su contenido sea aplicable al sistema desarrollado. 6 Revise que estén incorporados todos los detalles relativos al desarrollo del sistema. 7 Corrobore detalles de presentación del documento como: • Idioma • Índice • Contenidos • Responsables 51 Objetivo 2: Identificar la existencia de documentación adecuada y suficiente para cada uno de los Sistemas de Información Computadorizados desarrollados. Criterio: Según el “Manual Sobre Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados” de la Contraloría General de la República, en el inciso 304.02 Documentación del sistema: “Se elaborará en forma adecuada y suficiente y se mantendrá actualizada, la documentación del sistema para cada Sistemas de Información Computadorizados (SIC) que se desarrolle.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique si existe un Manual de Sistema. 2 Solicite a la autoridad competente el Manual de Sistema del último sistema desarrollado. 3 Verifique que el Manual cuenta con los siguientes requerimientos: • la información relativa a los objetivos • antecedentes del SIC, • los estudios preliminar (301.01) • estudios de factibilidad (301.02) • las aprobaciones respectivas • la descripción • diseño general • diagrama del sistema • subsistemas o aplicaciones que lo conforman • los objetivos y funciones de los programas • el diseño de la entrada y salida de datos • el diseño de los archivos y forma de acceso 4 Determine si en el Manual del sistema se describe y presenta en forma adecuada el Sistema de Información Computadorizado. 5 Verifique que incluye lo que hace el sistema así como el ámbito de acción del mismo. 6 Valide los controles incorporados. 7 Verifique que exista en la documentación evidencia 52 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA de sus limitaciones. 8 Revise que la documentación proporcione la información necesaria para que los interesados puedan tener una comprensión clara y confiable del SIC 5. 9 Identifique las indicaciones que debe incluir la documentación del sistema para su mantenimiento y posibles modificaciones requeridas. Objetivo 3: Verificar que la documentación del sistema de información ha sido elaborada según los procedimientos establecidos, salvaguardando la suficiencia y pertinencia necesaria para su uso. Criterio: Según el “Manual Sobre Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados” de la Contraloría General de la República, en el inciso 304.03 Documentación del programa: “La documentación de cada programa del SIC deberá mantenerse en forma adecuada, suficiente y actualizada.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Corrobore la existencia de un Manual del programa. 2 Solicite a la autoridad competente el Manual del programa. 3 Verifique los mecanismos empleados por la organización para garantizar el control efectivo sobre las modificaciones, revisiones y correcciones del Manual del programa. 4 Verifique que el Manual del programa incorpore: • el código y título o nombre del programa o 5 Sistemas de Información Computadorizados 53 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA programas que integran el SIC, • la descripción del programa en forma narrativa, • el diagrama de lógica o algoritmo y • tabla de decisiones si las hubiera, formato y descripción de los archivos, • listado del programa fuente, • listado de los controles, • instrucciones de operación, • registro de cambios a los programas y su autorización, • listado de la última corrida de prueba 5 Valide la efectividad de los mecanismos de seguridad existentes en cuanto al acceso a la documentación de los programas. Objetivo 4: Corroborar que la documentación requerida por el usuario de los Sistemas de Información Computadorizados cumpla con los lineamientos organizacionales y se encuentren actualizados. Criterio: Según el “Manual Sobre Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados” de la Contraloría General de la República, en el inciso 304.04 Documentación del usuario: “Deber mantenerse en forma adecuada, suficiente y actualizada, la documentación del usuario del SIC.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique la existencia de manuales de usuario para los diferentes SIC desarrollados. 2 Valide que su contenido permita que los usuarios sean autosuficientes en el manejo del sistema y presentada en lenguaje corriente. 54 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 3 Corrobore que la documentación del usuario contenga: • la descripción del SIC • la descripción de las entradas y salidas de datos, • los procedimientos de control, • los procedimientos para la corrección de errores Objetivo 5: Validar que la documentación de las operaciones del computador relativas al Sistema de Información Computadorizadas esté desarrollada en forma adecuada y suficiente. Criterio: Según el “Manual Sobre Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados” de la Contraloría General de la República, en el inciso 304.05 Documentación de las operaciones del computador: “Se elaborará en forma adecuada y suficiente y se mantendrá actualizada, la documentación de las operaciones del computador relativas al SIC.” Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA 1 Verifique la existencia de Manuales de las operaciones 2 Valide que las instrucciones permiten ejecutar las labores diversas que requiere la corrida de tales programas, aún sin tener experiencia acerca de los programas en particular. 3 Verifique que los manuales de procedimientos incluyan: • al menos el diagrama general del sistema, • el código y nombre de los programas que se ejecutarán, • una breve descripción de la finalidad del 55 Fecha de Terminación Días Laborables Visto Bueno Fecha de Inicio Estimado Real Estimado/hrs Real/hrs Dif. No. PROCEDIMIENTOS DE AUDITORÍA REF. P/T AUDITOR FECHA programa, • la descripción y diagrama general de procesos, • el calendario de procesos, • las entradas y salidas del proceso, • instrucciones especiales 4 Valide que el Manual de Instrucciones muestre: • instrucciones de conclusión del trabajo, • interfaces con otros sistemas • y procedimientos de respaldo de la información procesada. 5 Corrobore la existencia de mecanismos o políticas necesarias para la rotación de operadores. 56 Capítulo IV COMUNICACIÓN DE RESULTADOS 57 Informe ejecutivo Origen de la Auditoría Esta auditoría se origina para dar cumplimiento a los objetivos del curso PF2566, práctica profesional 2, cuya finalidad es que los estudiantes de las maestrías profesionales desarrollen, de manera eficaz, una práctica de carácter profesional en una empresa, institución pública o sector, ubicados en nuestro país, o bien en el exterior, con el fin de: 1. Beneficiar a aquellas empresas, instituciones públicas o sectores que así lo soliciten con la incorporación de una persona profesional externa, que presente, desde un punto de vista objetivo, recomendaciones en torno a problemas específicos de las organizaciones en el área de TI. 2. Propiciar la participación del estudiante en las vivencias y experiencias de una empresa al desarrollar un trabajo para ella. 3. Facilitar al estudiante el dominio de su aprendizaje, mediante la puesta en práctica de los conocimientos adquiridos en la carrera. Objetivo de la auditoría Evaluar la metodología utilizada para el desarrollo de software que soporta la gestión de la Oficina de Planificación Universitaria y el grado de cumplimiento con la normativa que la regula. 58 Cumplimiento con normas de auditoría Este informe se debería regir por lo indicado en el “Manual de Normas técnicas de control interno de referentes a sistemas de información”, así como en los artículos N.o 366, 377, 388 y 39 (1º párrafo)9 de la Ley General de Control Interno N.o 8292; sin embargo, por ser elaborado por un estudiante se considera de carácter académico, de manera que la aplicación de esta normativa queda a criterio de las autoridades de la Oficina de Planificación Universitaria. Período de revisión De junio a agosto de 2007 6 “Artículo 36. - Informes dirigidos a los titulares subordinados. Cuando los informes de auditoría contengan recomendaciones dirigidas a los titulares subordinados, se procederá de la siguiente manera: a)El titular subordinado, en un plazo improrrogable de diez días hábiles contados a partir de la fecha de recibido el informe, ordenará la implantación de las recomendaciones. Si discrepa de ellas, en el transcurso de dicho plazo elevará el informe de auditoría al jerarca, con copia a la auditoría interna, expondrá por escrito las razones por las cuales objeta las recomendaciones del informe y propondrá soluciones alternas para los hallazgos detectados. b)Con vista de lo anterior, el jerarca deberá resolver, en el plazo de veinte días hábiles contados a partir de la fecha de recibo de la documentación remitida por el titular subordinado; además, deberá ordenar la implantación de recomendaciones de la auditoría interna, las soluciones alternas propuestas por el titular subordinado o las de su propia iniciativa, debidamente fundamentadas. Dentro de los primeros diez días de ese lapso, el auditor interno podrá apersonarse, de oficio, ante el jerarca, para pronunciarse sobre las objeciones o soluciones alternas propuestas. Las soluciones que el jerarca ordene implantar y que sean distintas de las propuestas por la auditoría interna, estarán sujetas, en lo conducente, a lo dispuesto en los artículos siguientes. c)El acto en firme será dado a conocer a la auditoría interna y al titular subordinado correspondiente, para el trámite que proceda.” 7 “Artículo 37.—Informes dirigidos al jerarca. Cuando el informe de auditoría esté dirigido al jerarca, este deberá ordenar al titular subordinado que corresponda, en un plazo improrrogable de treinta días hábiles contados a partir de la fecha de recibido el informe, la implantación de las recomendaciones. Si discrepa de tales recomendaciones, dentro del plazo indicado deberá ordenar las soluciones alternas que motivadamente disponga; todo ello tendrá que comunicarlo debidamente a la auditoría interna y al titular subordinado correspondiente.” 8 “Artículo 38.—Planteamiento de conflictos ante la Contraloría General de la República. Firme la resolución del jerarca que ordene soluciones distintas de las recomendadas por la auditoría interna, esta tendrá un plazo de quince días hábiles, contados a partir de su comunicación, para exponerle por escrito los motivos de su inconformidad con lo resuelto y para indicarle que el asunto en conflicto debe remitirse a la Contraloría General de la República, dentro de los ocho días hábiles siguientes, salvo que el jerarca se allane a las razones de inconformidad indicadas. La Contraloría General de la República dirimirá el conflicto en última instancia, a solicitud del jerarca, de la auditoría interna o de ambos, en un plazo de treinta días hábiles, una vez completado el expediente que se formará al efecto. El hecho de no ejecutar injustificadamente lo resuelto en firme por el órgano contralor, dará lugar a la aplicación de las sanciones previstas en el capítulo V de la Ley Orgánica de la Contraloría General de la República, N° 7428, de 7 de setiembre de 1994.” 9 “Artículo 39.—Causales de responsabilidad administrativa. El jerarca y los titulares subordinados incurrirán en responsabilidad administrativa y civil, cuando corresponda, si incumplen injustificadamente los deberes asignados en esta Ley, sin perjuicio de otras causales previstas en el régimen aplicable a la respectiva relación de servicios.” 59 Limitaciones al alcance Por limitaciones de tiempo, no se realizó la aplicación del programa de pruebas a los sistemas desarrollados por la OPLAU; por consiguiente, no se realizan en el informe final recomendaciones ni observaciones con respecto a este tema. Estas pruebas se dejarán para su aplicación en una etapa posterior debido a la importancia de verificar la confiabilidad de datos procesados y sus resultados para la toma de decisiones. Resumen ejecutivo Como se ha visto durante la historia del desarrollo de aplicaciones informáticas es necesario contar con herramientas que guíen a los desarrolladores a la obtención de los objetivos y metas, además de, garantizar que se realiza de manera eficiente, eficaz el proceso de desarrollo de sistemas de información, además de garantizar que los objetivos de TI se encuentran alineados con los objetivos de la organización. Durante la ejecución del presente trabajo se detectaron varios aspectos sujetos a mejora, en lo referente al desarrollo de las aplicaciones informáticas de la Oficina de Planificación Universitaria, entre las cuales podemos citar las siguientes: carencia de políticas, de estándares de desarrollo, dependencia del personal de TI en la administración de los sistemas implementados, falta de pruebas más rigurosas a los sistemas que se traslada a producción, documentación insuficiente tanto de las bases de datos como del código fuente de lo sistemas. Todas estas carencias detectadas van contra el aseguramiento de la calidad, confiabilidad, integridad de la información, así como al aprovechamiento de los recursos de TI existen en la OPLAU. 60 Informe final de auditoría Carta de Presentación San José, Costa Rica XX de agosto del 2007 Oficina de Planificación Universitaria Licda. Maritza Monge M. Directora. De nuestra consideración. Tengo el agrado de dirigirme a usted, a efecto de elevar para su consideración el alcance del trabajo de auditoría realizado al área de Tecnologías de Información de la Oficina de Planificación Universitaria, practicada en el periodo que comprende los meses de junio a agosto del 2007. El contenido de informe ha sido dividido de la siguiente forma con el propósito de facilitar su análisis: a) Título b) Situación actual c) Criterio. d) Causa. e) Efecto f) Recomendación. Al agradecer al personal de TI de la OPLAU la colaboración prestada durante la realización de este trabajo al personal de TI de la OPLAU, quedando a su disposición para cualquier aclaración, que estime necesaria. ___________________________ Ing. Carlos M. Gómez Borbón. Auditor. 61 Observaciones y recomendaciones REF P/T TÍTULO: Implementación de políticas CONDICIÓN: Con base en la evaluación realizada se comprobó que la OPLAU no cuenta con políticas para el desarrollo de sistemas de información. CRITERIO: Capítulo 3 de las “Normas técnicas para la gestión y el control de las tecnologías de información” (N-2-2007-CO-DFOE), Inciso 3.1 Consideraciones generales de la implementación de TI de la Contraloría General de República. Inciso 3.02.04 Políticas relativas a los sistemas de información (Manual de normas técnicas de control interno referentes a sistemas de información) de la Contraloría General de la República. Cobit 4.0. PO6.3 Administración de políticas para TI. “Elaborar y dar mantenimiento a un conjunto de políticas que apoyen la estrategia de TI.” PO6.4 Implantación de políticas de TI. “Asegurarse de que las políticas de TI se implantan y se comunican a todo el personal relevante, y se refuerzan, de tal forma que estén incluidas y sean parte integral de las operaciones empresariales.” Nota: Tomado textualmente de Cobit 4.0 CAUSA: La dirección no ha implantado ningún documento oficial que dicte las directrices al área de TI. 62 EFECTO: Debido a la ausencia de un marco regulador que dicte las pautas y lineamientos de desarrollo de sistemas de información, se produce una desorganización, lo cual puede provocar que proyectos fundamentales para el logro de los objetivos de la organización no se cumplan, dando como contraste un mal uso de los recursos humanos y tecnológicos. RECOMENDACIÓN: A la administración: Implementar un documento formal de políticas claras y consistentes que ayuden a maximizar de forma eficiente y eficaz los recursos de TI, donde se implemente al menos: 1. La intención de las políticas 2. Roles y responsabilidades 3. Procesos de excepción 4. Enfoque de cumplimiento y referencias a procedimientos 5. Estándares y directrices 6. Temas clave como calidad 7. Seguridad 8. Confidencialidad 9. Controles internos 10. Propiedad intelectual. Su relevancia se debe confirmar y aprobar de forma regular. 63 RE F P/T TÍTULO: Metodología de desarrollo CONDICIÓN: Durante el proceso de evaluación, se determinó la carencia de una metodología de desarrollo de sistemas. CRITERIO: 303.05.03 Análisis y determinación de requerimientos de información Se realizará un análisis del sistema actual y se determinarán y documentarán los requerimientos de información del sistema de información en desarrollo. CAUSA: La dirección de TI no ha definido de forma oficial una metodología de desarrollo para sus sistemas de información. EFECTO: La carencia de una metodología para el desarrollo de software produce: 1. Retrasos considerables en la planificación. 2. Poca productividad. 3. Elevadas cargas de mantenimiento 4. Baja calidad y fiabilidad del producto. 5. Dependencia 6. Altos costos RECOMENDACIÓN: A la Dirección de TI Definir, de manera inmediata, una metodología que oriente al personal de TI en el proceso de desarrollo y mantenimiento de aplicaciones, con el fin de garantizar la calidad, la integridad, la confiabilidad de la información y de los procesos de TI. 64 Esta debe contar con al menos las siguientes etapas: 1. Análisis de requisitos. 2. Diseño 3. Implantación 4. Prueba 5. Instalación 6. Aceptación REF P/T TÍTULO: Carencia de estándares CONDICIÓN: Durante el proceso de auditoría se advirtió la carencia de estándares de desarrollo. CRITERIO: Cobit 4.0 PO8.3 Estándares de desarrollo y de adquisición “Adoptar y mantener estándares para todo el desarrollo y adquisición que siguen el ciclo de vida, hasta el último entregable e incluyen la aprobación en puntos clave con base en criterios de aprobación acordados.” Nota: Tomado textualmente de Cobit 4.0 CAUSA: Debido al incipiente nivel de madurez de la organización, esta no ha implantado estándares para el desarrollo de aplicaciones informáticas. EFECTO: La carencia de estándares produce retrasos en el desarrollo, retrasos en los 65 proyectos, que pueden provocar que el proyecto sea desechado, lo cual puede resultar sumamente costoso y ver comprometida su imagen antes las autoridades universitarias y el público en general. RECOMENDACIÓN: A la Dirección de TI. Implementar, de manera inmediata un documento formal, debidamente aprobado por la autoridad competente y comunicado al personal de TI, que contemple al menos los siguientes documentos: 1. Estándares de codificación de software 2. Normas de nomenclatura. 3. Formatos de archivos. 4. Estándares de diseño para esquemas y diccionario de datos 5. Estándares para la interfaz de usuario 6. Interoperabilidad 7. Eficiencia de desempeño de sistemas 8. Escalabilidad. 9. Estándares para desarrollo y pruebas 10. Validación contra requerimientos 11. Planes de pruebas, unitarias, de regresión y de integración. 66 REF P/T TÍTULO: Documentación insuficiente e inadecuada. CONDICIÓN: Durante el proceso de evaluación, se determinó la carencia de documentación de la mayoría de de los sistemas y de las bases de datos. CRITERIO: Cobit 4.0 AI4 Facilitar la operación y el uso. “El conocimiento sobre los nuevos sistemas debe estar disponible. Este proceso requiere la generación de documentación y manuales para usuarios y para TI, y proporciona entrenamiento para garantizar el correcto uso y operación de las aplicaciones y la infraestructura”. Nota: Tomado textualmente de Cobit 4.0 CAUSA: Esta situación se da por la carencia de estándares y políticas que orienten a los desarrolladores durante el proceso de implementación de los sistemas de información. También debido a la falta de cultura de los desarrolladores en el uso de las mejores prácticas. EFECTO: Una documentación inadecuada relativa al proceso de desarrollo de los sistemas produce que el mantenimiento y la administración de los sistemas sea una labor ardua, además de incurrir en altos costos económicos de mantenimiento y causar un uso inadecuado por parte de los usuarios finales; además puede propiciar que la información resultante no sea la idónea y lleve a tomar decisiones administrativas inadecuadas. 67 RECOMENDACIÓN: A la Administración: Elaborar los documentos necesarios que orienten a los desarrolladores, tales como estándares y políticas, así como implementar un procedimiento de evaluación de cada una de las fases del ciclo de vida del software, una vez finalizada. REF P/T TÍTULO: Dependencia de los desarrolladores CONDICIÓN: Durante el proceso de la auditoria, se determinó que los desarrolladores son los usuarios responsables de los sistemas producidos, tanto del mantenimiento de la información como del procesamiento de los datos, así como de la administración de la base de datos. CRITERIO: Cobit 4.0 PO4.11 Segregación de funciones. “Implantar una división de roles y responsabilidades que reduzca la posibilidad de que un solo individuo afecte negativamente un proceso crítico.” PO4.13 Personal clave de TI. “Definir e identificar al personal clave de TI y minimizar la dependencia excesiva en ellos. Debe existir un plan para contactar al personal clave en caso de emergencia.” PO7.5 Dependencia sobre los individuos. “Minimizar la exposición a dependencias críticas sobre individuos clave por medio de la captura del conocimiento (documentación), compartir el conocimiento, planeación de la sucesión y respaldos de personal.” Nota: Tomado de forma textual de Cobit 4.0 68 CAUSA: Esto se da por la falta de políticas de segregación de funciones. EFECTO: 1 - La administración de los programas por parte de los desarrolladores provoca que estos no cumplan con la eficiencia y efectividad debido a que se pierde la independencia. 2 – Se produce un mal uso de los recursos humanos de desarrollo, lo que implica un costo muy alto para la institución. 3 – Uso inadecuado de la información confidencial, lo cual expone a la institución a posibles demandas y sanciones legales. RECOMENDACIÓN: A la administración: Implementar un proceso de asignación de roles y responsabilidades que aseguren que el personal realice solo las tareas autorizadas, relevantes a sus puestos y posiciones dentro de la organización, con el fin de eliminar la dependencia. REF P/T TÍTULO: Controles inadecuados e insuficientes CONDICIÓN: Durante la evaluación, se determinó que se carece de controles que permitan garantizar la confiabilidad, integridad y la calidad de la información, de manera pertinente. 69 CRITERIO: AI2.3 Control y auditabilidad de las aplicaciones. “Asegurar que los controles del negocio se traduzcan correctamente en controles de aplicación, de manera que el procesamiento sea exacto, completo, oportuno, aprobado y auditable. Los aspectos que se consideran especialmente son: mecanismos de autorización, integridad de la información, control de acceso, respaldo y diseño de pistas de auditoría.” Nota: Tomado textualmente de Cobit 4.0 CAUSA: Esto se da debido a la falta de políticas y lineamientos claros y precisos por parte de la dirección, aunado a esto la falta de experiencia de los desarrolladores en la implementación de controles que aseguren la seguridad, confiabilidad e integridad de la información. EFECTO: La carencia de mecanismos de control que aseguren la información de manera pertinente, la información puede producir un mal uso de está, además de prestarse fraude, comprometiendo así la imagen y la reputación de la oficina ante la alta dirección de la UCR, además cabe mencionar la posibilidad de verse envuelta en procesos legales que darían al traste con la excelente labor realizada por la OPLAU. RECOMENDACIÓN: A la administración: Elaborar procedimientos de control, así como su implementación. Dichos procedimientos deben ser claros y precisos y ser divulgados al personal de TI para su inmediata implementación tanto en los sistemas en desarrollo como en 70 producción. REF P/T TÍTULO: Prueba de los sistemas CONDICIÓN: Las pruebas de los sistemas que salen a producción son inadecuadas e insuficientes CRITERIO: Cobit 4.0 AI7.2 Plan de prueba “Establecer un plan de pruebas y obtener la aprobación de las partes relevantes. El plan de pruebas se basa en los estándares de toda la organización y define roles, responsabilidades y criterios de éxito.” AI7.7 Prueba final de aceptación “Garantizar que los procedimientos proporcionan, como parte de la aceptación final o prueba de aseguramientos de la calidad de los sistemas de información nuevos o modificados, una evaluación formal y la aprobación de los resultados de prueba por parte de la gerencia de los departamentos afectados del usuario y la función de TI. Las pruebas deberán cubrir todos los componentes del sistema de información (ejemplo, software aplicativo, instalaciones, procedimientos de tecnología y usuario) y garantizar que los requerimientos de seguridad de la información se satisfacen para todos los componentes. Los datos de prueba se deben salvar para propósitos de pistas de auditoría y para pruebas futuras.” Nota: Tomados de forma textual de Cobit 4.0 71 CAUSA Debido a la carencia de estándares y políticas que orienten a los desarrolladores, además de la falta de una división de funciones adecuada y por la carga de trabajo asignadas a los analistas-desarrolladores, es que se deja de lado la realización de pruebas más rigurosas a los sistemas que pasan a producción, además de que se debe cumplir con los cronogramas preestablecidos por las autoridades universitarias. EFECTO: Una inadecuada aplicación de pruebas a los sistemas en todas sus fases de desarrollo da como resultado sistemas poco seguros y de mala calidad, que pueden dar al traste con las funciones que realiza la OPLAU, así como una anuencia por parte de los usuarios finales en su uso. Además de crear un ambiente de desconfianza en las autoridades universitarias con respecto a la calidad de la información brindada para la toma de decisiones. RECOMENDACIÓN: A la administración: Elaborar un documento formal, aprobado por la autoridad competente, que incluya al menos: 1. Preparación del sitio. 2. Requerimientos de entrenamiento. 3. Instalación o actualización de un ambiente de pruebas definido. 4. Planear / ejecutar / documentar / retener casos de prueba. 5. Manejo y corrección de errores y aprobación formal. 6. Prueba de desempeño, estrés, de usabilidad. 7. Pruebas piloto y de seguridad. 72 REF P/T TÍTULO: Administración de cambios CONDICIÓN: Durante el transcurso de la auditoria se detectó la carencia procedimientos para la realización de cambios a los sistemas de información, tanto en producción como en desarrollo. CRITERIO: AI6.1 Estándares y procedimientos para cambios CAUSA: Debido al incipiente nivel de madurez en el que se encuentra la organización en materia de desarrollo de software, no se han implementado los documentos necesarios para la administración de cambios. EFECTO: Al no contar con mecanismos de administración de cambios, se ve comprometida la confiabilidad, la integridad de la información, además de comprometer la eficiencia, la eficacia y seguridad de los sistemas de información. Produce ineficiencia en la administración de los proyectos, en la administración de versiones, así como usuarios insatisfechos, pérdida de credibilidad por parte de la alta dirección y de los usuarios finales. 73 RECOMENDACIÓN: A la administración: Establecer procedimientos que se encuentren debidamente documentados, aprobados por la autoridad competente; además, estos procedimientos deben publicarse a fin de que orienten la administración de cambio de los sistemas de información, de manera consistente y segura, donde se incluyan todas las solicitudes de cambios a aplicaciones, procedimientos, procesos, parámetros de sistema, servicio y las plataformas fundamentales (incluso mantenimiento y parches). 74 Bibliografía consultada IT Governance Institute, Cobit 4.0, www.isaca.org. Contraloría General de la República. Manual de Normas Generales de Control Interno para la Contraloría General de la República y las Entidades y Órganos sujetos a su Fiscalización. San José, 2002 Contraloría General de la República. Manual de Normas Técnicas de Control Interno Relativas a los Sistemas de Información Computadorizados. San José, 1995. Contraloría General de la República, Manual de Normas Técnicas para la Gestión y el Control de las Tecnologías de Información Contraloría General de la República Ley General de Control Interno. San José, 18 de julio de 2002. Norma Técnica Peruana ISO/IEC 12207. TECNOLOGÍA DE LA INFORMACIÓN.Procesos del ciclo de vida del software. 2006-07-13. 2ª Edición http://static.scribd.com/docs/euui219c88ske.pdf Franklin, E. Auditoría administrativa.. Editorial McGraw Hill. México: (primera edición), 2001. Hernández Sampieri, Roberto, Fernández Collado, Carlos y Baptista Lucio, Pilar. Metodología de la Investigación. Cuarta Edición. 2006 Universidad de Costa Rica, Oficina Jurídica. Compendio de Normas Universitarias. Primera edición: 2006. Vicerrectoría de Docencia. Catálogo de la Universidad de Costa Rica. Editorial de la Universidad de Costa Rica, 2006. Whittington, O. Ray. Auditoria un Enfoque Integral. Santa Fe de Bogotá, Colombia: Editorial Mc Graw Hill. doceava edición, 2000. Laudon K. Y Laudon J. 1996. Administración de los Sistemas de Información. 3era. Edición. Pág.: 426. 75 Senn J. Análisis y Diseño de Sistemas de Información. 2da. edición. 1992. Pág.: 33. Sage A. Y Palmer. J. 1998. Software Systems Engineering. Pág: 48. Whitten J., Bentley L., Barlow V. 1996. Análisis y Diseño de Sistemas de Información. 3era. Edición. Pág.: 95. Yourdon E. 1993. Análisis Estructurado Moderno. Pág.: 86. Referencias web Pilar Navas, El ciclo de la vida en Internet. http://www.getec.etsit.upm.es/docencia/gproyectos/planificacion/cvida.htm usr.code, Ciclo de Vida del software, Http://www.tectimes.com/lbr/Graphs/revistas/lpcu097/capitulogratis.pdf http://www.monografias.com/trabajos4/cicdevida/cicdevida.shtml