Sie sind auf Seite 1von 136

Ao de la Inversin para el Desarrollo Rural y la Seguridad Alimentaria

UNIVERSIDAD PERUANA LOS ANDES


FACULTAD DE INGENIERA
CARRERA PROFESIONAL DE INGENIERA DE SISTEMAS Y COMPUTACIN

INFORME TCNICO

AUDITORA DEL DESARROLLO DE SISTEMAS DE INFORMACIN EN EL GOBIERNO REGIONAL DE JUNN


PRESENTADO POR:

CHRISTIAN PERCY, QUISPE HUAMN


PARA OPTAR EL TTULO PROFESIONAL DE:

INGENIERO DE SISTEMAS Y COMPUTACIN HUANCAYO - PER 2013

___________________________________ Ph. D. Mohamed Mehdi Hadi Mohamed Presidente

___________________________________ Ing. Jorge Vladimir Pachas Huaytn Jurado

___________________________________ Mg. Ral Enrique Fernndez Bejarano Jurado

___________________________________ Ing. Rafael Edwin Gordillo Flores Jurado

___________________________________ Mg. Miguel ngel Carlos Canales Secretario Docente

Dedicatoria

A Dios, por su infinito amor, su cuidado la fuerza y voluntad que me brinda para continuar en el cumplimiento de mis objetivos. A mi padre y mi madre por ser ellos la motivacin de mi vida. A mis hermanos por sus consejos y apoyo moral.
Christian Quispe Huamn

NDICE

DEDICATORIA......................................................................................... NDICE ..................................................................................................... NDICE DE FIGURA. ............................................................................... NDICE DE TABLAS ................................................................................ NDICE DE GRFICOS ........................................................................... RESUMEN ............................................................................................... INTRODUCCIN .....................................................................................

I II VII VIII IX XI XII

CAPITULO I GENERALIDADES 1.1. DEFINICIN DEL PROBLEMA ..................................................... 13 14 14 15 16 16 16 17 18 18 19 19 19 19 20


II

1.1.1. PROBLEMA GENERAL................................................................. 1.1.2. PROBLEMAS ESPECIFICOS ....................................................... 1.2. 1.3. JUSTIFICACIN ........................................................................... OBJETIVOS ..................................................................................

1.3.1. OBJETIVO GENERAL ................................................................... 1.3.2. OBJETIVOS ESPECFICOS ......................................................... 1.4. 1.5. 1.6. 1.7. INDICADORES .............................................................................. LIMITACIONES DE LA INVESTIGACIN ..................................... METODOLOGA ............................................................................ RECURSOS ..................................................................................

1.7.1. HUMANOS .................................................................................... 1.7.2. MATERIALES ................................................................................ 1.7.3. TECNOLGICOS .......................................................................... 1.8. CRONOGRAMA DE TRABAJO.....................................................

1.9.

PRESUPUESTO ...........................................................................

21 22 22 22 23 25 26

1.10. ASPECTOS GENERALES DE LA ENTIDAD ................................ 1.10.1. IDENTIFICACIN DE LA ENTIDAD AUDITADA ......................... 1.10.2. DIRECCIONAMIENTO ESTRATGICO ...................................... 1.10.3. UBICACIN GEOGRAFICA ........................................................ 1.10.4. ORGANIGRAMA .......................................................................... 1.10.5. ANLISIS DE LA ENTIDAD AUDITADA ...................................... 1.10.6. MARCO LEGAL DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGIA DE LA INFORMACIN (ORDITI) ........................................................................................ 1.10.7. ESTRUCTURA ORGANICA INTERNA DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGIA DE LA INFORMACIN ............................................................................. 1.10.8. RECURSOS HUMANOS DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGIA DE LA INFORMACIN ............................................................................. 1.10.9. PROBLEMTICA DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGIA DE LA INFORMACIN ORDITI .......................................................................................... 1.10.10. ALINEAMIENTO CON EL PLAN ESTRATEGICO INSTITUCIONAL Y SECTORIAL .............................................................................. 1.10.11. ESTRATEGIAS PARA EL LOGRO DE LAS METAS DEL PLAN OPERATIVO INFORMTICO........................................................

28

32

32

33

35

36

CAPITULO II MARCO TERICO 2.1 2.2 2.3 2.4 2.5 2.6 SISTEMA ....................................................................................... INFORMACIN ............................................................................. SISTEMA DE INFORMACIN (SI) ................................................ CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN .......... TIPOS DE SISTEMAS DE INFORMACIN (SI) ............................ AUDITORIA ................................................................................... 37 38 39 42 43 45
III

2.7 2.8

AUDITOR ...................................................................................... ISACA (INFORMATION SYSTEMS AUDIT AND CONTROL ASSOCIATION ASOCIACIN DE CONTROL Y AUDITORA DE SISTEMAS DE INFORMACIN ....................................................

47

47 47 50 51

2.9

PRINCIPIOS DE AUDITORA .......................................................

2.10 OBJETIVOS GENERALES DE LA AUDITORA ............................ 2.11 ALCANCE DE LA AUDITORA ...................................................... 2.12 IMPLANTACION DE UN SISTEMA DE CONTROL INTERNO INFORMTICO ............................................................................. 2.13 MOTIVOS PARA EFECUTAR UNA AUDITORA DE TECNOLOGAS DE INFORMACIN ....................................................................... 2.14 CONTROL INTERNO .................................................................... 2.14.1 COMPONENTES DEL CONTROL INTERNO ............................... 2.15 AUDITORA INFORMTICA ......................................................... 2.15.1 CONTROL INTERNO Y AUDITORI INFORMTICA: CAMPOS ANALOGOS .................................................................................. 2.16 TCNICAS Y HERRAMIENTAS USADAS POR LA AUDITORA INFORMTICA .............................................................................. 2.17 AUDITORIA DE SISTEMAS DE INFORMACIN .......................... 2.18 OBJETIVOS DE LA AUDITORA DE SISTEMAS .......................... 2.19 PLANTEAMIENTO Y METODOLOGA .........................................

51

53 55 57 58

58

59 62 64 65

CAPITULO III METODOLOGA 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. TIPO DE INVESTIGACIN ........................................................... MBITO DE ESTUDIO .................................................................. POBLACIN Y MUESTRA ............................................................ UNIDAD DE ANLISIS .................................................................. TECNICA E INSTRUMENTOS DE RECOLECCIN DE DATOS . PROCESAMIENTO, ANLISIS E INTERPRETACIN DE DATOS .......................................................................................... 3.7. DETERMINACION DEL DESARROLLO DE SISTEMAS DE INFORMACION ............................................................................. 69
IV

67 67 67 67 68

68

CAPITULO IV DESARROLLO 4.1. AUDITORA DEL DESARROLLO DE SISTEMAS DE INFORMACIN EN LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACIN - ORDITI .......................... 4.2. AUDITORA DE LA ORGANIZACIN Y GESTIN DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACIN - ORDITI ........................................................ 4.3. AUDITORA DE LA GESTIN Y PLANIFICACIN DEL PROYECTO .................................................................................. 4.4. AUDITORA DE LA FASE DE ESTUDIO DE VIABILIDAD DEL PROYECTO .................................................................................. 4.5. 4.6. 4.7. AUDITORA DE LA FASE DE ANALISIS DEL PROYECTO ......... AUDITORA DE LA FASE DE DISEO DEL PROYECTO ............ AUDITORA DE LA FASE DE CONSTRUCCION DEL PROYECTO .................................................................................. 4.8. AUDITORA DE LA FASE DE IMPLEMENTACION Y ACEPTACIN DEL PROYECTO .......................................................................... 4.9. AUDITORA DE LA FASE DE MANTENIMIENTO DEL PROYECTO .................................................................................. 90 88 85 80 81 83 76 70 70

CAPITULO V ANALISIS DE RESULTADOS 5.1. 5.2. RESULTADOS Y DISCUSIN ...................................................... HALLAZGOS DE LA AUDITORA ................................................. 93 119

5.2.1. HALLAZGOS DE AUDITORA DE LA ORGANIZACIN Y GESTION DE SISTEMAS .............................................................................. 5.2.2. HALLAZGOS DE AUDITORA DE LA GESTIN Y PLANIFICACIN DEL PROYECTO .......................................................................... 5.2.3. HALLAZGOS DE AUDITORA DE LA FASE DE ESTUDIO DE VIABILIDAD ................................................................................... 5.2.4. HALLAZGOS DE AUDITORA DE LA FASE DE ANLISIS .......... 120 120
V

119

120

5.2.5. HALLAZGOS DE AUDITORA DE LA FASE DE DISEO ............ 5.2.6. HALLAZGOS DE AUDITORA DE LA FASE DE CONSTRUCCIN ......................................................................... 5.2.7. HALLAZGOS DE AUDITORA DE LA FASE DE IMPLANTACIN Y ACEPTACIN ............................................................................... 5.2.8. HALLAZGOS DE AUDITORA DE LA FASE DE MANTENIMIENTO ........................................................................ 5.2.9. APLICATIVOS INFORMTICOS QUE ADMINISTRA EL GOBIERNO REGIONAL DE JUNN................................................................... 5.2.10. DOCUMENTACIN DE LOS APLICATIVOS ............................... 5.2.11. OBSERVACIONES ...................................................................... 5.3. DISEO DE CONTRASTACIN ......................................................

120

121

121

121

122 122 122 123

CONCLUSIONES .................................................................................... RECOMENDACIONES ............................................................................ BIBLIOGRAFA ........................................................................................ ANEXOS ..................................................................................................

126 127 129 132

VI

INDICE DE FIGURAS
FIGURAS CAPITULO I Figura N 01. Logo Institucional ................................................................. Figura N 02. Vista Satelital del Gobierno Regional de Junn .................... Figura N 03. Exteriores del Gobierno Regional de Junn .......................... Figura N 04. Estructura Orgnica del Gobierno Regional de Junn .......... Figura N 05. Estructura Orgnica de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin .............................................. 32 23 24 24 25

FIGURAS CAPITULO II Figura N 06. Definicin de Sistema .......................................................... Figura N 07. El ciclo de la Informacin .................................................... Figura N 08. Atributos de la calidad de la Informacin.............................. Figura N 09. Actividades de un sistema de informacin.. .................. Figura N 10. Sistema de Informacin........................................................ Figura N 11. Fuerzas que presionan a un Sistema ................................... Figura N 12. Definicin de Auditoria de Sistemas ..................................... Figura N 13. Objetivos de Auditoria de Sistemas ..................................... 38 38 39 41 42 57 62 64

FIGURAS CAPITULO V Figura N 14. Datos inconsistentes en la base de datos ............................ Figura N 15. Diseo de Contrastacin ...................................................... 123 124

VII

INDICE DE TABLAS
TABLAS CAPITULO I Tabla N 01. Indicadores de Variable Independiente ................................. Tabla N 02. Indicadores de Variable Dependiente ................................... Tabla N 03. Cronograma de Trabajo ........................................................ Tabla N 04. Presupuesto .......................................................................... Tabla N 05. Personal de la ORDITI .......................................................... Tabla N 06. Anlisis FODA-ORDITI .......................................................... Tabla N 07. Alineamiento con el Plan Estratgico Institucional y Sectorial. 17 18 20 21 33 34 35

TABLAS CAPITULO II Tabla N 08. Similitudes y Diferencias ente Control Interno y Auditoria Informtica ................................................................................................. 59

TABLAS CAPITULO IV Tabla N 09. Auditoria de la organizacin y gestin de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI .............. Tabla N 10. Auditoria de gestin y panificacin del proyecto .................... Tabla N 11. Auditoria de la fase de Estudio de Viabilidad del proyecto.... Tabla N 12. Auditora de la Fase de Anlisis del proyecto. . Tabla N 13. Auditora de la Fase de Diseo del proyecto ... Tabla N 14. Auditora de la Fase de Construccin del proyecto . Tabla N 16. Auditora de la Fase de Mantenimiento del proyecto. ........ 75 79 80 83 85 88

Tabla N 15. Auditora de la Fase de Implantacin y Aceptacin del proyecto 90 92

TABLAS CAPITULO V Tabla N 17. Aplicativos Informticos del Gobierno Regional de Junn 122
VIII

INDICE DE GRFICOS
GRFICOS CAPITULO V Grfico N 01. Auditorias anteriores ........................................................... Grfico N 02. Documentacin de Funciones ............................................ Grfico N 03. Organigrama ....................................................................... Grfico N 04. Puesto de Trabajo .............................................................. Grfico N 05. Promocin de Staff a puestos superiores ........................... Grfico N 06. Staff cumple con los requisitos al puesto que accede ........ Grfico N 07. Formacin y Motivacin del Staff ........................................ Grfico N 08. Sugerencias del Staff .......................................................... Grfico N 09. Aprobacin del Proyecto ..................................................... Grfico N 10. Metodologa de Desarrollo de Sistemas de Informacin..... Grfico N 11. Metodologa cubre las fases y es adaptable ....................... Grfico N 12. Asignacin de responsables del proyecto........................... Grfico N 13. Dimensin del proyecto ...................................................... Grfico N 14. Registro de Problemas ....................................................... Grfico N 15. Informacin Histrica .......................................................... Grfico N 16. Equipos de Trabajo y responsables de las reas ............... Grfico N 17. Reuniones del equipo de trabajo ........................................ Grfico N 18. Documentacin del proyecto .............................................. Grfico N 19. Documentacin del Proyecto .............................................. Grfico N 20. Solicitud de participacin de personal de otras reas ......... Grfico N 21. Nuevos proyectos de Software ........................................... Grfico N 22. Fechas de realizacin del proyecto .................................... Grfico N 23.Recopilacin de Informacin................................................ 93 94 94 95 96 96 97 97 98 99 99 100 100 101 102 102 103 103 104 104 105 106 106
IX

Grfico N 24. Mtricas .............................................................................. Grfico N 25. Guas de prcticas de anlisis y diseo .............................. Grfico N 26. Modelo del Sistema ............................................................ Grfico N 27. Divisin de Subsistemas ..................................................... Grfico N 28. Interfaces ............................................................................ Grfico N 29. Normas de Diseo .............................................................. Grfico N 30. Plan de Pruebas ................................................................. Grfico N 31. Aceptacin del sistema ....................................................... Grfico N 32. Validacin de la especificacin ........................................... Grfico N 33. Arquitectura del Sistema ..................................................... Grfico N 34. Migracin y cara inicial de datos ......................................... Grfico N 35. Entorno de Desarrollo y pruebas ........................................ Grfico N 36. Repositorio de productos de software ................................ Grfico N 37. Tcnicas de programacin.................................................. Grfico N 38. Programar, probar y documentar componentes ................. Grfico N 39. Estndares y normas de programacin .............................. Grfico N 40. Prueba de cada componente .............................................. Grfico N 41. Procedimientos de migracin y carga inicial de datos ........ Grfico N 42. Aceptacin formal del sistema ............................................ Grfico N 43. Plan de formacin y aceptacin .......................................... Grfico N 44. Capacitacin a usuarios...................................................... Grfico N 45. Procedimientos de mantenimiento ...................................... Grfico N 46. Monitorear nivel de servicio ................................................ Grfico N 47. Peticiones de mantenimiento ..............................................

107 107 108 108 109 109 110 110 111 111 112 112 113 113 114 114 115 115 116 116 117 117 118 118

RESUMEN
La Auditoria del desarrollo de sistemas en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI del Gobierno Regional de Junn, que se realiz utilizando COBIT (Objetivos de Control para tecnologa de informacin), nos permite realizar un examen crtico para evaluar la eficiencia y eficacia de los procesos informticos.

En el Captulo I se definen las generalidades del presente informe y los objetivos que se busca lograr.

En el Captulo II se presenta el marco terico describiendo los temas conceptuales del presente informe tanto de la metodologa como de los aspectos tcnicos.

En el Captulo III se desarrolla la metodologa a utilizar en el proyecto de auditoria.

En el Captulo IV se desarrolla la auditoria bajo estndar de la metodologa COBIT: sus procesos y objetivos de control.

En el Captulo V se muestra el anlisis de resultados de la auditoria, adems de los hallazgos encontrados. Finalmente en el Captulo VI ya habiendo terminado con el proceso de auditora se obtuvieron las conclusiones y las recomendaciones del proyecto realizado.

El estudiante.
XI

INTRODUCCIN
Este es un proyecto de titulacin que utiliza metodologa COBIT con sus guas para la realizacin de la auditoria de sistemas informticos en el Gobierno Regional de Junn.

Para iniciar la auditoria se obtuvo conocimiento acerca de las actividades principales del negocio, con lo cual se observ los procesos que se realizan y quienes los hacen, finalmente se obtuvo los problemas que la empresa presenta en materia informtica para luego determinar la metodologa a utilizar. Tomando como referencias las guas de auditoria de COBIT se realiz varias pruebas de las cuales se tiene documentos y resultados que se analizan para determinar la situacin de la empresa en cuanto a los sistemas informticos.

El presente trabajo se expone en siete captulos En el Captulo I se definen las generalidades del presente informe y los objetivos que se busca lograr, en el Captulo II se presenta el marco terico describiendo los temas conceptuales del presente informe tanto de la metodologa como de los aspectos tcnicos; en el Captulo III se desarrolla la metodologa a utilizar en el proyecto de auditoria; en el Captulo IV se desarrolla la auditoria bajo estndar de la metodologa COBIT: sus procesos y objetivos de control; en el Captulo V se muestra el anlisis de resultados de la auditoria, adems de los hallazgos encontrados y finalmente en el Captulo VI damos a conocer las conclusiones y las recomendaciones conclusiones del presente informe con las recomendaciones para cuando se implemente un Sistema de Seguridad de la Informacin (SGSI).

El estudiante.
XII

CAPITULO I GENERALIDADES

1.1.

DEFINICION DEL PROBLEMA


La investigacin surge a raz que en todo mbito institucional se requiere informacin oportuna y confiable, para la toma de decisiones realidad que ha permitido el desarrollo de sistemas de informacin.

Usualmente, la mayora de las instituciones, y en este caso, el Gobierno Regional de Junn, en el desarrollo de sistemas de informacin carece de un anlisis tcnico profesional, lo cual ha generado una informacin poco confiable, inoportuna e inconsistente a la hora de tomar decisiones.

El Gobierno Regional de Junn, entra en vigencia por la Constitucin Poltica del Estado Peruano y la Ley N 27867 Ley Orgnica de Gobierno Regionales el ao 2003 y su modificatoria Ley N 27902. Esta, indica que es un organismo pblico con personera jurdica de derecho pblico, con autonoma poltica, econmica y administrativa en asuntos de su competencia; constituyendo para su administracin econmica y financiera un pliego presupuestal.

El Gobierno Regional de Junn cuenta con un departamento de sistemas el cual lo denominan Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI, el mismo que da soporte tcnico a los diversos procesos administrativos de la institucin.

13

Despus de las entrevistas con el Director de ORDITI (Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin) as como con su staff, dieron a conocer algunos de los problemas que se mencionan a continuacin: Falta de una metodologa y procedimientos estndares para el desarrollo de sistemas de informacin: gestin y planificacin del proyecto, viabilidad, anlisis, diseo, construccin, implantacin y mantenimiento. Carencia de procedimientos de control interno, como garanta para una gestin eficaz orientada a la consecucin de los objetivos de ORDITI y de la institucin. Falta de documentacin para la gestin del cambio, problemas e incidentes en el desarrollo del proyecto software. Falta de mecanismos de comunicacin debidamente documentados entre el staff.

Ante estos problemas nace el presente trabajo de investigacin aplicativo que permitir mejorar la calidad de sistemas informticos de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn., bajo normas internacionales.

1.1.1. PROBLEMA GENERAL


La Aplicacin de una Auditora del Desarrollo de Sistemas de Informacin garantiza la integridad y confiablidad de la informacin en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn?

1.1.2. PROBLEMAS ESPECIFICOS


a) Cmo debe analizarse el contexto en el que acta la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn? b) Cmo debe disearse una metodologa para la aplicacin de la Auditora para mejorar la integridad y confiabilidad de la
14

informacin en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn? c) Cmo debe desarrollarse encuestas dirigidas al staff de Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn? d) Cmo debe aplicarse la Auditora del desarrollo de sistemas de informacin? e) Cmo debe evaluarse los resultados y hallazgos de la autora aplicada al desarrollo de sistemas de informacin de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn?

1.2.

JUSTIFICACIN
La presente investigacin se justifica en los siguientes aspectos:

La aplicacin de una Auditoria del Desarrollo de Sistemas de Informacin permite mejorar la integridad y confiabilidad de la informacin en el rea de Sistemas en el Gobierno Regional de Junn.

La confiabilidad de la informacin cobra cada vez mayor importancia en la sociedad, pues se enfoca en la proteccin de la infraestructura computacional y todo lo relacionado con esta. Para ello existen una serie de estndares, protocolos, mtodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la informacin. La seguridad informtica comprende software, bases de datos, archivos y todo lo que la organizacin valore (activo) y signifique un riesgo si sta llega a manos de otras personas. Este tipo de informacin se conoce como informacin privilegiada o confidencial.

La presente investigacin es necesaria pues el Gobierno Regional de Junn, demanda sistemas de informacin que le permita realizar la gestin con eficacia y eficiencia. Esto conlleva al desarrollo de un sistema de informacin, que controle, evale y fortalezca la validez y confiabilidad de
15

procesamiento de la Informacin. El estudio ha permitido identificar las principales deficiencias, que actualmente carece de procedimientos de control, verificar su correcta definicin y aplicacin que garanticen la integridad y confiabilidad de la informacin.

Por ello, es conveniente realizar la mejora a travs de la Auditora del desarrollo de sistemas de informacin, que permita identificar y minimizar los riesgos de la informacin.

1.3.

OBJETIVOS 1.3.1. OBJETIVO GENERAL


Realizar una Auditora del Desarrollo de Sistemas de Informacin para mejorar la integridad y confiabilidad de la informacin en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn.

1.3.2. OBJETIVOS ESPECFICOS


a) Analizar el contexto en el que acta la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn. b) Disear una metodologa para la aplicacin de la Auditora para mejorar la integridad y confiabilidad de la informacin en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn. c) Desarrollar encuestas dirigidas al staff de Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn. d) Aplicar la Auditora del desarrollo de sistemas de informacin. e) Evaluar los resultados y hallazgos de la autora aplicada al desarrollo de sistemas de informacin de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn.

16

1.4.

INDICADORES
El proceso se ha llevado a cabo a travs de una encuesta cuyo instrumento de recopilacin de datos ha sido el cuestionario diseado en concordancia con los indicadores seleccionados:
VARIABLE INDEPENDIENTE: Auditora del Desarrollo de Sistemas DEFINICIN DIMENSIONES Gestin y planificacin del proyecto Fase de Viabilidad Fase Construccin Fase de Implantacin y Aceptacin INDICADORES Documentacin Ciclo de vida del proyecto Equipo Tcnico Alcance del proyecto Situacin actual del proyecto Modelo del Sistema Interfaces Plan de pruebas Validacin de requisitos Arquitectura del Sistema Migracin y carga inicial de datos Entorno de desarrollo y pruebas Tcnicas de programacin Programacin de componentes Pruebas de integracin de componentes Plan de formacin y aceptacin por usuarios Capacitacin a usuarios Monitorear nivel de servicio Registro de peticiones de mantenimiento. INSTRUMENTO

Es una disciplina encargada de aplicar un conjunto de tcnicas y procedimiento s con el fin de evaluar la seguridad de los sistemas de informacin durante todo el proceso de desarrollo.

Fase Anlisis

Observacional, a travs de encuestas, cuestionarios, entrevistas al staff.

Fase Diseo

Fase de Mantenimiento

Tabla N 01. Indicadores de Variable Independiente Fuente: Elaboracin Propia.

17

VARIABLE DEPENDIENTE: Mejorar la Integridad y Confiabilidad DEFINICIN DIMENSIONES El trmino integridad se refiere a la correccin y Integridad completitud de los datos en una base de datos. Y la confiabilidad de un Sistema de Informacin est Confiabilidad referida a la calidad de la Informacin que produce y tambin a la eficiencia con la que ese sistema funciona. INDICADORES Eficacia Fiabilidad Validez Consistencia Porcentaje. INSTRUMENTO

Funcionamiento Seguridad Desempeo Relevancia Calidad

Tabla N 02. Indicadores de Variable Dependiente Fuente: Elaboracin Propia.

1.5.

LIMITACIONES DE LA INVESTIGACIN
El dominio de la investigacin est delimitado al Gobierno Regional de Junn en el rea de sistemas. Y el periodo de estudio caracteriza a la investigacin como trasversal, porque se realizar en un momento determinado del tiempo, durante los meses de marzo a julio del 2013.

1.6.

METODOLOGA
Todo trabajo de investigacin debe estar enmarcado dentro de una metodologa, es decir, una serie de pasos que guen el desarrollo del proyecto, a tal efecto, se ha decidido aplicar la metodologa propuesta por la ISACA (Information Systems Audit and Control Association), que est basada en COBIT (Control Objectives for Information and Related Technologies), la cual proporciona un conjunto estructurado de buenas prcticas y metodologas para su aplicacin, cuyo objetivo es facilitar el gobierno de las Tecnologas de Informacin y Comunicaciones. COBIT est basado en la evaluacin de riesgos, de manera que partiendo de los riesgos potenciales a los que est sometida la actividad, en este caso el
18

desarrollo o mantenimiento de SI, se determinan una serie de objetivos de control de alto nivel que minimicen esos riesgos. Para cada objetivo de control de alto nivel, se agrupa por cada una de las fases del ciclo de vida del software identificadas en Mtrica versin 3 (MAP, 2007), se especifican uno o ms objetivos de control de detalle o tambin denominadas prcticas de control, que contribuyen a lograr el cumplimiento de dicho objetivo de control de alto nivel. As mismo, se aportan una serie pruebas de cumplimiento que permitan comprobar la existencia y correcta aplicacin de dichos controles.

1.7.

RECURSOS 1.7.1. HUMANOS


Director de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI. Staff. rea de Planeamiento Estratgico. rea de Sistemas. Asesor. Bachiller.

1.7.2. MATERIALES
Materiales de escritorio y oficina. Fotocopias. Memoria USB. Computadora de escritorio. Tner para impresin HP 85A.

1.7.3. TECNOLOGICOS
Paquete Office 2013 (Microsoft Word, Microsoft Power Point, Microsoft Excel y Microsoft Project). Internet Speedy 2MB. Telefona. Impresora.

19

1.8.

Nombre de tarea
Comienzo lun 05/03/12 lun 05/03/12 lun 05/03/12 mar 06/03/12 jue 08/03/12 mar 20/03/12 jue 29/03/12 jue 05/04/12 jue 26/04/12 jue 10/05/12 jue 10/05/12 lun 21/05/12 lun 28/05/12 mar 29/05/12 mi 30/05/12 jue 31/05/12 vie 01/06/12 lun 04/06/12 mar 05/06/12 mi 06/06/12 jue 07/06/12 vie 08/06/12 lun 11/06/12 mar 12/06/12 mi 13/06/12 jue 14/06/12 vie 15/06/12 lun 18/06/12 mar 19/06/12 mi 20/06/12 jue 21/06/12 vie 22/06/12 vie 29/06/12 vie 29/06/12 lun 02/07/12 lun 16/07/12 lun 16/07/12 lun 02/07/12 lun 16/07/12 lun 16/07/12 vie 29/06/12 lun 02/07/12 vie 22/06/12 jue 21/06/12 mi 20/06/12 mar 19/06/12 lun 18/06/12 vie 15/06/12 jue 14/06/12 mi 13/06/12 mar 12/06/12 lun 11/06/12 vie 08/06/12 jue 07/06/12 mi 06/06/12 mar 05/06/12 lun 04/06/12 vie 01/06/12 jue 31/05/12 mi 30/05/12 mar 29/05/12 lun 28/05/12 lun 21/05/12 vie 18/05/12 vie 22/06/12 mi 09/05/12 mi 25/04/12 mi 04/04/12 mi 28/03/12 lun 19/03/12 mi 07/03/12 lun 05/03/12 mi 09/05/12 lun 16/07/12 Fin

Duracin

PRESUPUESTO - AUDITORIA DEL DESARROLLO DE SISTEMAS - ORDITI - JUNIN JULIO JUNIO MAYO ABRIL MARZO 1 Semana 2 Semana 3 Semana 4 Semana 1 Semana 2 Semana 3 Semana 4 Semana 1 Semana 2 Semana 3 Semana 4 Semana 1 Semana 2 Semana 3 Semana 4 Semana 1 Semana 2 Semana

Cronograma de Actividades del Proyecto

96 das

SERVICIOS
1 da 2 das 8 das 7 das 5 das

48 das

Reunion con staff

Reconocimiento de la entidad

Recoleccion de la informacin

Definir Marco Normativo

Organizar informacin

Revisar Documentacin

15 das

Elaboracin de cuestionarios

10 das

FASE DE EJECUCIN
7 das 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 1 da 2 das 1 da 1 da 1 da 1 da

32 das

Aplicacin de cuestionarios

Realizar entrevistas con staff

Realizar control de la organizacin y gestin

Evaluar procesos, organizacin y relaciones

CRONOGRAMA DE TRABAJO

Evaluar gestin de recursos humanos

Evaluar Plan estratgico de TI

Evaluar direccion de la poltica tecnolgica

Evaluar gestion de inversiones de TI

Evaluar gestion de la calidad

Realizar objetivos de control de gestin y planificacin del proyecto

Evaluar el proyecto de desarrollo

Evaluar la gestin de tiempo y recursos

Evaluar mecanismos de de resolucin de problemas

Realizar objetivos de control de viabilidad

Evaluar requisitos del proyecto

Evaluar especificacin detallada del SI

Evaluar la calidad de procesos de anlisis

Evaluar arquitectura del sistema

Evaluar las especificaciones para la construccin

Evaluar componentes de desarrollo

Evaluar procedimientos para usuarios

Evaluar aceptacion del sistema

FASE ELABORACION DE INFORME

20

Realizar Informe de auditora

Presentar informe de auditora

CIERRE

Cierre del proyecto

Tabla N 03. Cronograma de Trabajo Fuente: Elaboracin Propia.

1.9.

PRESUPUESTO
Costo total del proyecto, teniendo en cuenta los recursos utilizados en el desarrollo del mismo.
COSTO RECURSOS UNIDAD CANTIDAD UNITARIO (S/.) COSTO TOTAL (S/.)

Humanos
Asesor

Asesor 1

300.00 Sub-Total

300.00 300.00

Materiales
Papel Bond Atlas de 80 Gr Bolgrafos Faber Castell 0.35 Lpiz de Grafito Faber Castell Fotocopias Memoria USB DE 16 GB Toner para impresora HP 85A Lpiz de Grafito Faber Castell Computadora de Escritorio (Intel Core 2 Quad, 4GB RAM, 500GB Disco Duro), Monitor LG 22, Mouse & Teclado Microsoft, Parlantes 5.1 Logitech)

Millar

30.00 0.50 3.00 0.03 32.00 53.00 3.00

30.00 2.00 3.00 30.00 32.00 106 3.00

Unidad 4 Unidad 1 Unidad 1000 Unidad 1 Unidad 2 Unidad 1

Unidad 1

1900.00

1900.00

Sub-Total Tecnolgicos
Impresora Multifuncional HP 85A Paquete Office 2013. Lnea Tarifa Semi-Plana + Speedy 2 MB

2106.00

Unidad 1 Unidad 1 Unidad 1

180.00 1299.00 80.00 Sub-Total

180.00 1299.00 80.00 1599.00

Costo Total
Tabla N 04. Presupuesto Fuente: Elaboracin Propia.

S/. 3965.00

Todo trabajo de investigacin debe estar enmarcado dentro de una


21

metodologa, es decir, una serie de pasos que guen el desarrollo del proyecto, a tal efecto, se ha decidido aplicar la metodologa propuesta por la ISACA (Information Systems Audit and Control Association), que est basada en COBIT.

1.10. ASPECTOS GENERALES DE LA ENTIDAD 1.10.1. IDENTIFICACION DE LA ENTIDAD AUDITADA

El Gobierno Regional de Junn, entra en vigencia por la Constitucin Poltica del Estado Peruano y la Ley N 27867 Ley Orgnica de Gobierno Regionales el ao 2003 y su modificatoria Ley N 27902. Esta, indica que es un organismo pblico con personera jurdica de derecho pblico, con autonoma poltica, econmica y administrativa en asuntos de su competencia; constituyendo para su administracin econmica y financiera un pliego presupuestal.

1.10.2.

DIRECCIONAMIENTO ESTRATGICO

A. MISIN Institucin Publica descentralizada, con autonoma poltica, econmica y administrativa; que fomenta el desarrollo regional integral sostenible; organiza y conduce la gestin pblica regional de acuerdo a sus competencias exclusivas,

compartidas y delegadas en el marco de las polticas nacionales y sectoriales; para contribuir al bienestar de la poblacin principalmente en los sectores ms vulnerables. B. VISIN Gobierno Regional de Junn consolidado en una Gestin por Resultados, con liderazgo en el territorio e institucionalmente; que garantiza el ejercicio pleno de los derechos y la igualdad de oportunidades de los habitantes; que promueve la inversin pblica y privada, con inversiones sustanciales en la industrializacin de nuestra produccin primaria; que promueve,
22

articula e implementa polticas ambientales; gestora de los sistemas administrativos con eficiencia y eficacia; poblacin con muchas oportunidades para aplicar su mximo potencial; con empleos dignos y permanentes; conduciendo la gestin pblica regional con transparencia, rendicin de cuentas y practicando la democracia participativa, con unidades econmicas

asociadas y competitivas, en el marco de un desarrollo sostenible.

1.10.3.

UBICACIN GEOGRFICA

a) LOGO

Figura N 01. Logo Institucional Fuente: Pgina Web del Gobierno Regional de Junn.

b) DIRECCION Jr. Loreto N 363 - Huancayo.

23

c) VISTA SATELITAL

Figura N 02. Vista Satelital del Gobierno Regional de Junn Fuente: Elaboracin Propia.

d) EXTERIORES DEL GOBIERNOR REGIONAL DE JUNN

Figura N 03. Exteriores del Gobierno Regional de Junn Fuente: Elaboracin Propia.

24

1.10.4.

ORGANIGRAMA

La estructura orgnica del Gobierno Regional de Junn, fue aprobada mediante la Ordenanza Regional N 087-2008-GRJ/CR de fecha 27 de agosto del ao 2008, de acuerdo con las disposiciones legales vigente y en amparo del artculo 9 inciso a) de la Ley Orgnica de Gobiernos Regionales Ley N 27867, donde se dispone que los Gobiernos Regionales son competentes para aprobar su organizacin interna.

Figura N 04. Estructura Orgnica del Gobierno Regional de Junn

25

Fuente: Elaboracin Propia.

1.10.5.

ANALISIS DE LA ENTIDAD AUDITADA


Desarrollo Institucional y Tecnologa de la Informacin ORDITI, en el cual procesan toda la informacin necesaria para los Sistemas de Informacin y figura en su Estructura Orgnica. Segn nos relat el Director de dicha oficina; la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin dependencia de - ORDITI, debera estar como una la Gerencia de Regional de

El Gobierno Regional de Junn cuenta con la Oficina Regional de

Comunicaciones.

Segn Reglamento de Organizacin y Funciones (ROF) del Gobierno Regional de Junn.

Artculo 55 La Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI, cumple con las funciones siguientes:

a) Proponer a los rganos de gobierno del Gobierno Regional Junn, estudios, planes y programas orientados al cambio y adecuacin sistemtica de funciones, estructura, cargos, procedimientos y de la tecnologa de informacin para optimizar los servicios y supervisar el cumplimiento de los mismos. b) Disear, normar, organizar y monitorear los sistemas

informticos del Gobierno Regional. c) Formular el Programa de Desarrollo Institucional en

coordinacin con las dems unidades orgnicas del Gobierno Regional. d) Formular y/o actualizar los documentos de gestin institucional como el Reglamento de Organizacin y Funciones, Cuadro de Asignacin de Personal, Manual de Organizacin y Funciones, y Texto nico de Procedimientos Administrativos.
26

e) Asesorar a los rganos del Gobierno Regional en la adopcin e implementacin de polticas de desarrollo de gestin,

modernizacin, racionalizacin y simplificacin administrativa. f) Administrar la utilizacin de los servidores, equipos

informticos, aplicaciones y bases de datos asignados para mantener la operatividad de los sistemas. g) Monitorear y mantener actualizada la base de datos de mantenimiento preventivo y correctivo de los equipos de cmputo y de comunicaciones. h) Realizar y mantener el inventario de equipos de cmputo. i) Cautelar la seguridad de los sistemas de informacin en el Gobierno Regional. j) Administrar la red de data del Gobierno Regional. k) Proponer normas y aprobar los requerimientos de tecnologa de informacin y de sistemas informticos en el Gobierno Regional. l) Establecer procesos y metodologas sobre las etapas de optimizacin e informatizacin. m) Formular el Plan Operativo Informtico y su correspondiente Evaluacin. n) Formular el Plan Estratgico de Sistemas de Informacin. o) Brindar asesoramiento tcnico para la adquisicin de equipos informticos y accesorios. p) Autorizar la adquisicin de equipos informticos y accesorios. q) Autorizar la asignacin de equipos informticos a las diferentes unidades orgnicas. r) Formular normas tcnicas de uso y mantenimiento de los equipos informticos, as como difundir y controlar su correcta aplicacin. s) Administrar el portal electrnico (Internet e Intranet), brindando asistencia tcnica a los usuarios. t) Elaborar normas y herramientas tcnicas adecuadas para impulsar y ejecutar la poltica de Desarrollo Institucional dentro
27

de la organizacin del Gobierno Regional. u) Formular y proponer normas y directivas tendientes a optimizar la gestin pblica en el mbito regional. v) Desarrollar sistemas de informacin gerencial del Gobierno Regional. w) Proponer una adecuada racionalizacin de personal, material y espacios de acuerdo a criterios tcnicos y eficacia para un mejor servicio a los usuarios. x) Desarrollar labores de produccin, desarrollo y soporte tcnico, a fin de automatizar los procesos de apoyo a la gestin. y) Desarrollar y disear sistemas y normas de seguridad de informacin z) Utilizar tcnicas estadsticas para establecer, controlar y verificar la capacidad de los procesos y las caractersticas de los servicios a su cargo. aa) Proponer procedimientos para mejorar la gestin de los servicios que presta a la sociedad o Gobierno Regional. bb) Proponer procedimientos para modernizar la gestin de su

Unidad Orgnica. cc) Definir indicadores de gestin que permitan evaluar el avance que se logre en el desempeo de la Unidad Orgnica, as como efectuar su seguimiento y, en funcin a dichos resultados reevaluar y proponer modificaciones a los objetivos, polticas y estrategias establecidas si fuera necesario. dd) Las dems funciones que le sean asignadas.

Fuente: Reglamento de Organizacin y Funciones, aprobado por Ordenanza Regional N 0872008-GRJ/CR.

1.10.6.

MARCO LEGAL DE LA OFICINA REGIONAL DE

DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACIN (ORDITI)


La Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI es integrante del Sistema Nacional de
28

Informtica y se desarrolla acorde con los lineamientos, normas y recomendaciones tcnicas de la Oficina Nacional de Gobierno Electrnico e Informtica de la Presidencia del Consejo de Ministros. Incluyendo adems las evaluaciones y seguimientos informticos que realizan las Oficinas de la Contralora, INDECOPI, y otros organismos reguladores y controladores.

Por otro lado ORDITI cuenta con la siguiente base legal: a) Ordenanza Regional 0872008-GRJ/CR, que aprueba el Reglamento de Organizacin y Funciones del Gobierno Regional de Junn. b) Resolucin Ministerial N 073-2004-PCM, Gua para la Administracin Eficiente del Software Legal en la

Administracin Pblica. c) Directiva Gerencial N 010-2012-GR JUNIN GGR/ORDITI, Normas para la adquisicin y uso de software legal en el gobierno regional Junn d) La Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI, forma parte del Sistema Nacional de Informtica, con RESOLUCION MINISTERIAL N 206-2004PCM se Constituyen el Padrn Nacional de Unidades Informticas de la Administracin Pblica y autorizan ejecucin de registro de unidades informticas del Sistema Nacional de Informtica. e) La Oficina de Derechos de Autor del INDECOPI, es la autoridad nacional competente responsable de cautelar y proteger administrativamente el derecho de autor y propiedad intelectual, mediante Decreto Ley N 807 en la que estipula multas y procedimientos a aplicarse en caso de infracciones a los mismos. Durante el proceso de Planificacin Estratgica se defini la Misin, Visin de Futuro y Valores que orientarn a la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del
29

Gobierno Regional de Junn. a). Misin Ser una oficina transparente y confiable del Gobierno Regional.

c). Visin Hacer del Gobierno Regional una organizacin al servicio del Ciudadano.

C. Principios de Conducta tica Constituyen principios de conducta tica del personal los siguientes: Imagen Todo el personal, deber estar comprometido con el Centro de Informacin y Sistemas; les corresponde como responsabilidad conjunta, la promocin y preservacin de su imagen positiva como un valor que pertenece a todos, que es compartido y del cual se es responsable por el slo hecho de compartir un ideal comn y ser un miembro de la ORDITI.

Integridad El Personal de la ORDITI deber actuar con rectitud, honradez, y honestidad, procurando satisfacer los intereses legtimos del Gobierno Regional de Junn, sus usuarios y la sociedad en su conjunto; desechando el provecho o ventaja personal obtenido por s o interpuesta por personas. Profesar y practicar un claro rechazo a la corrupcin en todos los mbitos de desempeo de la institucin y cumplir cabalmente con sus funciones.

Eficiencia El personal de la ORDITI brindar calidad en cada una de las labores a su cargo, buscando el resultado ms adecuado
30

y oportuno. Idoneidad El personal de la ORDITI, se desenvolver con aptitud tcnica, legal y moral en el desempeo de su labor. Propender a una formacin slida acorde a la realidad, capacitndose permanentemente para el debido

cumplimiento de sus labores.

Veracidad El personal de la ORDITI, se expresar con autenticidad en las relaciones laborales con todos los miembros del Gobierno Regional y con terceros.

Lealtad y Obediencia El personal de la ORDITI, actuar con fidelidad y solidaridad hacia toda la Institucin, cumpliendo rdenes que le imparta el superior jerrquico competente, en la medida que renan las formalidades del caso y tengan por objeto la realizacin de actos de servicio que se vinculen con las labores a su cargo, salvo los supuestos de arbitrariedad o ilegalidad manifiestas, los cuales deber poner en conocimiento de la administracin de la institucin. Asimismo, actuar con reserva y diligencia en el manejo de la informacin que conoce.

Justicia y Equidad El personal de la ORDITI, actuar con permanente disposicin para el cumplimiento de sus funciones, otorgando a cada uno lo que le es debido, actuando con equidad en sus relaciones con sus superiores, los subordinados y con la ciudadana en general.

31

1.10.7.

ESTRUCTURA

ORGNICA

INTERNA

DE

LA

OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACIN

Figura N 05. Estructura Orgnica de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin Fuente: Elaboracin Propia.

Se debe mencionar que no se cuenta con personal Asistente Administrativo, pero se incluye en el presente organigrama por ser un cargo que se debera considerarse.

1.10.8.

RECURSOS HUMANOS DE LA OFICINA REGIONAL

DE DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACION.


RECURSOS HUMANOS Direccin o Gerencia Jefe Asistente Administrativo Redes y Comunicaciones Administrador de Red y Soporte 1
32

CANTIDAD

1 1

Sistemas Analista de Sistemas Web Master Programador de Aplicaciones Diseador de Interfaces Planeamiento Estratgico Informtico Gestor de Proyectos Informticos Responsable de Investigacin y Planeamiento Soporte Tcnico Tcnico Electrnico Soporte Help Desk TOTAL
Tabla N 05. Persona de la ORDITI Fuente: Elaboracin Propia.

1 1 1 1

1 1

1 1 12

1.10.9.

PROBLEMTICA DEL LA OFICINA REGIONAL DE

DESARROLLO INSTITUCIONAL Y TECNOLOGIA DE LA INFORMACION - ORDITI


La problemtica actual de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI se presenta mediante el anlisis FODA, por medio de este anlisis de Fortalezas, Debilidades, Oportunidades y Amenazas, se obtendr un diagnstico que permitir tomar decisiones acordes con los objetivos y polticas que formularemos.

SITUACION ACTUAL

DESCRIPCION
F1. Elaboracin del Plan Operativo Informtico 2012. F2. Personal identificado con la ORDITI. F3. Coordinacin permanente con los diferentes usuarios. F4. Equipo de trabajo eficiente y eficaz. F5. Capacidad de asesoramiento permanente en relacin a sistemas informticos y sus aplicaciones. F6. Implementacin de los sistemas de informacin mediante el desarrollo de software personalizado. F7. Infraestructura fsica acorde a las exigencias del rea.

Fortalezas a utilizar

33

Oportunidades para aprovechar

Debilidades a superar

Amenazas a neutralizar

F8. Uso y administracin del portal web, que permite fortalecer la imagen institucional. F9. Deseo e iniciativa del personal informtico en actualizarse en las nuevas tecnologas informticas. F10. Decisin institucional para modernizar y estandarizar tecnolgicamente el gobierno regional. F11. Adecuacin de Data Center y Red de Cmputo de la Sede del Gobierno Regional de Junn (Proyecto Gobierno Electrnico). O1. Desarrollo tecnolgico que ofrece nuevas oportunidades para lograr mayor eficiencia. O2. Disponibilidad de software en el mercado para la implementacin del requerimiento de aplicaciones. O3. Existencia de normatividad estadstica e informtica a nivel nacional que sirve de referencia para un normal desarrollo de las actividades informticas. O4. Tendencia a un Modelo de Gobierno Electrnico. O5. Existencia de entidades pblicas como INDECOPI, Contralora, MEF. O6. Potencial productivo que ofrece internet. O7. Mejoramiento de la Red de Datos y Telefnica. O8. Promocin del intercambio de informacin con la Implementacin de MAD y MOD a nivel Regional. D1. Uso de software no licenciado. D2.Falta de equipos de contingencia para continuidad de servicios crticos. D3. La ORDITI no figura dentro de la Estructura Orgnica del Gobierno Regional. D4. Desconocimiento por parte del personal del Gobierno Regional de Junn acerca del Rol que cumple el CIS A1. Situacin econmica del Pas, que se expresa en el escaso presupuesto para la adquisicin de equipos de cmputo y Licencias de software. A2. Constante amenazas de virus informticos, correos maliciosos; en la red. A3. Creciente demanda por servicios informticos relacionados a consultas masivas. A4. La realidad del crecimiento tecnolgico trae como consecuencia la obsolescencia de los equipos de cmputo. A5. Dbil planificacin nacional en el mbito informtico debido a la falta de integracin del sector pblico. A6. Alto costo de software. A7. Inestabilidad laboral.
Tabla N 06. Anlisis FODA-ORDITI Fuente: Elaboracin Propia.

34

1.10.10.

ALINEAMIENTO CON EL PLAN ESTRATEGICO

INSTITUCIONAL Y SECTORIAL
Las acciones que pretende realizar el Centro de Informacin y Sistemas se encuentran alineadas con el Plan Estratgico Sectorial Multianual (PESEM 2007-2011) de la Presidencia del Consejo de Ministros (PCM), aprobado mediante Resolucin Ministerial N 281- 2007 PCM :
OBJETIVO ESTRATEGICO SECTORIAL 1. Lograr un estado moderno, eficaz y eficiente que responda a las necesidades de la Ciudadana. OBJETIVOS INSTITUCIONALES a) Contribuir con el incremento de las capacidades de las personas, facilitando la igualdad de oportunidades para la poblacin; impulsando la mejora de la calidad y cobertura de los servicios pblicos de educacin, salud, saneamiento y la asistencia social, as como la reduccin del analfabetismo y la desnutricin infantil y fomentando el desarrollo de la ciencia, la tecnologa y la cultura en la Regin. b) Lograr niveles de eficiencia y transparencia, en la gestin pblica regional, institucionalizando estrategias de rendicin de cuentas, facilitando el acceso a la informacin pblica y promoviendo la vigilancia y Auditora social. OBJETIVOS ESPECIFICOS INFORMATICOS a.1 Mejorar la gestin pblica y propiciar la descentralizacin del estado mediante el uso intensivo de las tecnologas de la informacin y comunicacin.

b.1.Promover el incremento de capacidades competitivas en la Administracin Pblica, empresas y ciudadanos por medio del uso de las tecnologas de la informacin. b.2. Fortalecimiento del rgano Institucional. b.3. Fortalecimiento del rgano Informtico Institucional. c) Contribuir con la integracin de la c.1.Optimizar el flujo de la Regin Junn desarrollando la informacin de los articulacin vial, elctrica, de sistemas y la telecomunicaciones; comunicacin de las implementando estrategias de estaciones de la red coordinacin y cooperacin con interna a travs del instituciones pblicas y privadas; mejoramiento, revalorando la identidad regional y estandarizacin y fortaleciendo la Concertacin y actualizacin de los cooperacin interregional a todo elementos que conforman nivel. la red institucional Tabla N 07. Alineamiento con el Plan Estratgico Institucional y Sectorial. Fuente: Elaboracin Propia.

35

1.10.11.

ESTRATEGIAS PARA EL LOGRO DE LAS METAS

DEL PLAN OPERATIVO INFORMTICO


Las siguientes son las principales estrategias planteadas de acuerdo a las diferentes necesidades tecnolgicas por las que atraviesa el Gobierno Regional de Junn. a) Mejorar la disponibilidad de herramientas tecnolgicas. b) Desarrollar la infraestructura tecnolgica. c) Generar rentabilidad de forma sostenible en el desarrollo de proyectos informticos. d) Analizar requerimientos funcionales para incorporarlos a la cadena de valor midiendo el avance hacia sus objetivos. e) Disponer de personal de sistemas con nivel competitivo y asegurar que dicho nivel se mantenga. f) Llevar a cabo el cumplimiento de normativas como ente del Sistema Nacional de Informtica. g) Desarrollar programas de capacitacin continua a los usuarios h) Fortalecer las actividades y procesos del Gobierno Regional de Junn. i) Mejorar la atencin a los usuarios j) Desarrollar sistemas de informacin. k) Integrar por medio de una base de datos institucional los procesos dentro del GRJ.

36

CAPITULO II MARCO TERICO


2.1 SISTEMA
Segn el Ing. Villanueva Snchez Grover1: "un sistema es una entidad autnoma dotada de una cierta permanencia, y constituida por elementos interrelacionados, que forman subsistemas estructurales y funcionales. Se transforma, dentro de ciertos lmites de estabilidad, gracias a regulaciones internas que le permiten adaptarse a las variaciones de su entorno especfico". Brian Wilson sostiene que el vocablo sistema tiene varias interpretaciones, dependiendo del contexto en el que es usado. Por otra parte, Stafford Beer refiere que hablar de un sistema es hablar de la cohesin de un cierto nmero de entidades llamadas partes de un sistema. Un sistema no es algo dado por la naturaleza sino definido por la inteligencia. Por lo tanto, se define a un Sistema como un conjunto de elementos interrelacionados que responden a un propsito determinado que como un todo tiene caracterstica que sus partes separadamente no tienen. Est conectado, interacta y es influenciado por su entorno.

VILLANUEVA SNCHEZ, Grover Eduardo. Sistema de Gestin Estratgica aplicando el Enfoque Sistmico y las Tecnologas de la Informacin para lograr Ventajas Competitivas en el Instituto Nacional de Cultura de La Libertad. [Tesis para optar el Ttulo Profesional de Licenciado en Admi nistracin]. Trujillo. Universidad Csar Vallejo. 2008.
1

37

Figura N 06. Definicin de Sistema Fuente: Libro N 03 (vase Bibliografa).

2.2

INFORMACIN
Segn John Burch & Gary Grudnitski2: Es el eslabn indispensable que une a todos los componentes de la organizacin para una mejor operacin y para su supervivencia en un ambiente competitivo y poco amigable.

Figura N 07. El ciclo de la Informacin Fuente: Libro N 01, Pg. 20 (vase Bibliografa).

Adems hace mencin que la calidad de la informacin est en base a : exactitud (informacin clara y libre de tendencias o desviaciones) oportunidad (dentro del marco de tiempo necesario) (importancia). y relevancia

BURCH & GRUDNITSKI, Diseo de Sistemas de Informacin Teora y Prctica, Editorial Limusa, 1996.

38

Figura N 08. Atributos de la Calidad de la Informacin Fuente: Libro N 01, Pg. 20 (vase Bibliografa).

2.3

SISTEMA DE INFORMACION (SI)


Segn Ralph M. Stair3, en su libro Principios de Sistemas de Informacin Enfoque Administrativo: Un Sistema de Informacin (SI) es un conjunto de componentes interrelacionados para recolectar, manipular y diseminar datos e informacin y para disponer de un mecanismo de retroalimentacin til en el cumplimiento de un objetivo. Todos interactuamos en forma cotidiana con sistemas de informacin, para fines tanto personales como profesionales; utilizamos cajeros automticos, los empleados de las tiendas registran nuestras compras sirvindose de cdigos de barras y escner u obtenemos informacin en mdulos equipados con pantallas sensibles al tacto, las muy famosas touch screen. Las principales compaas gastan en la actualidad ms de 1 000 millones de dlares al ao en tecnologa de informacin y el futuro dependeremos an ms de los sistemas de informacin Segn Kenneth Laudon. & Jane Laudon4 : Un sistema de informacin se

STAIR, Ralph M. Principios de SISTEMAS DE INFORMACION Enfoque Administrativo, Internacional Thomson Editores S.A., 1999. 4 LAUDON, Kenneth C. & LAUDON, Jane P. Sistemas De Informacin Gerencial, Pearson Educacin S.A. de C.V., 2004.

39

puede definir tcnicamente como un conjunto de componentes interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen informacin para apoyar la toma de decisiones y el control en una organizacin. Adems de apoyar la toma de decisiones, la

coordinacin y el control, los sistemas de informacin tambin pueden ayudar a los gerentes y trabajadores a analizar problemas, visualizar asuntos complejos y crear productos nuevos.

Los sistemas de informacin contienen informacin acerca de gente, lugares y cosas importantes dentro de la organizacin o en el entorno que se desenvuelven. Por informacin se entiende los datos que se han modelado en una forma significativa y til para los seres humanos. En contraste, los datos son consecuencia de los hechos en bruto y representan eventos que ocurren en las organizaciones o en el entorno fsico antes de ser organizados y ordenados en una forma que las personas puedan entender y utilizar.

Hay tres actividades en un sistema de informacin que producen la informacin que las organizaciones necesitan para tomar decisiones, controlar operaciones, analizar problemas y creas nuevos productos o servicios. Estas actividades son entrada, procesamiento y salida. La entrada captura o recolecta datos en bruto tanto al interior de la organizacin como de su entorno externo. El procesamiento convierte esta entrada de datos en una forma significativa. La salida transfiere la informacin procesada a la gente que lo usar o a las actividades para las que se utilizar. Los sistemas de informacin tambin requieren retroalimentacin que es la salida que se devuelve al personal adecuado de la organizacin para ayudarle a evaluar o corregir la etapa de entrada.

40

Figura N 09. Actividades de un sistema de informacin Fuente: Libro N 03, Pg. 25 (vase Bibliografa).

Segn Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruz5 : En un sentido amplio se puede considerar que un SI es un conjunto de elementos que interactan para que la empresa pueda alcanzar sus objetivos satisfactoriamente. Segn COBIT los componentes o recursos de un SI son los siguientes: Datos: En general se consideran datos tanto los estructurados como los no estructurados, las imgenes, los sonidos, etc. Aplicaciones Se incluyen las aplicaciones manuales y las informticas Infraestructura En infraestructura se incluyen las tecnologas y las instalaciones (por ejemplo hardware, sistemas operativos, sistema de gestin de base de datos, sistemas de red, multimedia y el medio en el que se ubican) que permiten que se procesen las aplicaciones. Personal Los conocimientos que ha de tener el personal de los sistemas de informacin para gestionarlos. planificarlos, organizarlos, administrarlos y

5 PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

41

Figura N 10. Sistema de Informacin Fuente: Libro N 06, Pg. 347 (vase Bibliografa).

Para comprobar que el sistema de informacin est funcionando segn lo previsto, este habr de disponer de un sistema de control interno que prevenga los eventos no deseados o en su defecto los detecte y los corrija. Es conveniente recordar que el resultado de la Auditora parcial de un sistema de informacin no se puede extrapolar al conjunto del sistema. EI funcionamiento inadecuado de alguno (o algunos) de los procesos y recursos que intervienen en otras partes del sistema (subsistemas) puede invalidar el sistema de informacin.

2.4

CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN


Segn Vince Fernndez Alarcn6 propone diversos criterios para la clasificacin de los Sistemas de Informacin: Por el grado de formalidad: Sistemas de Informacin Formales y los Informales Por el nivel de automatizacin conseguido: En las organizaciones, pueden existir sistemas que necesitan una alta participacin de los trabajadores poco automatizadas (Por ejemplo, los sistemas para responder a preguntas personalizadas a

6 FERNANDEZ ALARCON, Vicente. Desarrollo de Sistemas De Informacin Una metodologa basada en el modelado, Ediciones UPC., 2006.

42

travs de un correo electrnico) -, mientras que otros sistemas son capaces de trabajar sin la intervencin humana muy

automatizadas (por ejemplo, las centrales telefnicas totalmente automatizadas). Por su relacin con la toma de decisiones: Una de las funciones que deben cumplir los sistemas de informacin es colaborar en la toma de decisiones. En funcin del lugar jerrquico en donde se tomen las decisiones, los sistemas de informacin se podrn clasificar en estratgicos, de control u operativos Por la naturaleza de sus entradas y salidas : Un sistema de informacin puede recibir informacin de diversas fuentes de informacin (personas, empresas, otros sistemas de informacin, etc.) as como en distintos formatos (a travs de un teclado, por la red, de un disquete, memoria USB, CD, DVD etc.) del mismo modo, los Sistema de Informacin pueden proporcionar informacin a travs de distintos formatos (impreso, por pantalla, en internet, etc.) Por el origen y el grado de personalizacin: En las empresas se pueden encontrar Sistemas de Informacin que han sido diseados e implementados slo para ellos, o tambin sistemas comprados que son utilizados por otras empresas. Por el valor que representan para la organizacin: El sistema que contiene la informacin de los clientes suele tener una mayor importancia que el sistema de informacin de presupuestos (ya que este es ms sencillo y se puede hacer manualmente).

2.5

TIPOS DE SISTEMAS DE INFORMACIN


Segn Kenneth Laudon. & Jane Laudon7 : Plantean cuatro principales tipos de sistemas de informacin que dan servicio a los diferentes niveles de la organizacin: sistemas a nivel operativo, sistemas a nivel del

7 LAUDON, Kenneth C. & LAUDON, Jane P. Sistemas De Informacin Gerencial, Pearson Educacin S.A. de C.V., 2004.

43

conocimiento, sistemas a nivel administrativo y sistemas a nivel estratgicos. Los sistemas a Nivel Operativo Apoyan a los gerentes operativos en el seguimiento de las actividades y transacciones elementales de la organizacin como ventas, ingresos, depsitos en efectivo, nmina, decisiones de crdito y flujo de materiales en una fbrica. El objetivo principal de los sistemas a este nivel es responder las preguntas de rutina y seguir el flujo de las transacciones a travs de la organizacin. Cuntas partes hay en el inventario? Qu pas con el pago del seor Gutirrez?

En general, para contestar este tipo de preguntas la informacin debe estar a la mano y ser actual y precisa. Entre los ejemplos de sistemas a nivel operativo estn un sistema para registrar los depsitos realizados en un cajero automtico o uno que lleve el registro del nmero de horas trabajadas cada da por los empleados de una fbrica. Los sistemas a Nivel del Conocimiento Apoyan a los trabajadores del conocimiento y de datos de una organizacin. El propsito de estos sistemas es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organizacin a controlar el flujo del trabajo de oficina. Los sistemas a nivel del conocimiento, especialmente en forma de estaciones de trabajo y sistemas de oficina, estn entre las aplicaciones de crecimiento ms rpido en los negocios actuales. Los sistemas a Nivel Administrativo Sirven a las actividades de supervisin, control, toma de decisiones y administrativas de los gerentes de nivel medio. La pregunta principal que plantean estos sistemas es van bien las cosas? Por lo general este tipo de sistemas proporcionan informes peridicos ms que informacin instantnea de operaciones. Un ejemplo es un sistema de control de reubicacin que informe los costos totales de mudanza, bsqueda de vivienda y financiamiento de vivienda para empleados de
44

todas las divisiones de la compaa y notifique cualquier costo actual que exceda los presupuestos. Los sistemas a Nivel Estratgico Ayudan a los directores a enfrentar y resolver aspectos estratgicos y tendencias a largo plazo, tanto en la empresa como en el entorno externo. Su funcin principal es compaginar los cambios del entorno externo con la capacidad organizacional existente. Cules sern los niveles de empleo dentro de cinco aos? Cules son las tendencias a largo plazo de los costos de la industria y dnde encaja nuestra empresa? Qu productos deberemos estar elaborando dentro de cinco aos?

Los sistemas de informacin tambin apoyan las principales funciones empresariales como ventas y marketing, manufactura, finanzas, contabilidad, y recursos humanos. Una organizacin tpica tiene sistemas a nivel operativo, administrativo, del conocimiento y estratgico para cada rea funcional.

2.6

AUDITORIA
En su libro, Carlos Muoz Razo8 indica que : Los inicios de la Auditora se remontan a la revisin y el diagnstico que se practicaba a los registros operacionales contables de las empresas; despus se pas al anlisis, verificacin y evaluacin de sus aspectos financieros; posteriormente se ampli al examen de algunos rubros de la administracin, siguiendo con el anlisis de aquellos aspectos que intervenan en todas sus actividades y, por ltimo, su alcance se increment conforme se avanz en la llamada revisin integral. Nos muestra adems una definicin de auditora: Es la revisin independiente que realiza un auditor profesional, aplicando tcnicas, mtodos y procedimientos especializados, a fin de evaluar el cumplimiento de las funciones, actividades, tareas y procedimientos de una entidad administrativa, as como dictaminar sobre el resultado de

MUOZ RAZO, Carlos. Auditora en Sistemas Computacionales, Pearson Educacin de Mxico.

45

dicha evaluacin. En la pgina Web del INEI: QU ES LA AUDITORA INFORMTICA? 9, hace referencia a: La Auditora cumple una funcin muy valiosa e independiente, no toma acciones pero da sugerencias, y sus

conclusiones deben tomarse en cuenta en la toma de decisiones. La auditora se apoya de herramientas de anlisis, verificacin y exposicin conformando as elementos de juicio, los cuales permitirn determinar las debilidades y disfunciones. Es muy probable que se afecte la susceptibilidad del personal auditado, debido a que se interrumpe de alguna manera sus tareas, en el momento de realizar la auditora, adems esta actitud es comprensible. Pero los sistemas en ocasiones son muy sofisticados, lo cual hace que el auditor disponga de un nivel tcnico adecuado e insuficiente frente al tiempo que tiene para realizar su trabajo . Como parte de la auditora esta la evaluacin del personal, para esto existe el Chek List, que es un cuestionario, el cual es archivado bajo estrictas medidas de seguridad por las empresas que se encargan de realizar este trabajo de Auditora, por considerarse informacin confidencial y activos muy importantes que respaldan su actividad. La evaluacin debe ceirse de acuerdo a las normas o reglas implantadas y se considera que debe aplicarse una metodologa que pueda resolver los problemas que puedan presentarse. Francisco Dagoberto Xiloj Charuc10 nos menciona: La Auditora consiste en un examen sistemtico de los libros, documentos y dems registros contables de una entidad, con el objeto de obtener elementos de juicio y evidencia comprobatoria suficiente y competente para fundamentar de una manera objetiva y profesional la opinin que el Contador Pblico y

INSTITUTO NACIONAL DE ESTADSTICA E INFORMTICA (INEI) QU ES LA AUDITORA INFORMTICA? [En lnea] [Fecha de acceso 08 de abril 2013]. URL disponible en http://www1.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5105/Libro. 10 XILOJ CHARUC, Francisco Dagoberto. Auditora Externa en un Ambiente de Sistemas de Informacin Computarizado en el rea de Ingresos de una Empresa Comercializadora de Vehculos. [Tesis para optar el Ttulo Profesional de Contador Pblico y Auditor]. Guatemala. 2008

46

Auditor, emite sobre los estados financieros preparados por la entidad, a una fecha determinada y el resultado de las operaciones por un perodo terminado en esa fecha, as como los estados de flujos de efectivo y patrimonio de los accionistas.

2.7

AUDITOR
Carlos Muoz Razo propone la siguiente definicin para la Auditora: Es la revisin independiente de alguna o algunas actividades, funciones especficas, resultados u operaciones de una entidad administrativa, realizada por un profesional de la Auditora, con el propsito de evaluar su correcta realizacin y, con base en ese anlisis, poder emitir una opinin sobre la razonabilidad de sus resultados y cumplimiento de sus operaciones

Segn la Pgina Web, Qu es la auditora informtica? Del Instituto Nacional De Estadstica e Informtica (INEI). Hace referencia a Si nos remontamos al campo de la etimologa veremos que auditora viene del latn auditorius, proviniendo de aqu la palabra auditor, la misma que significa o que se refiere a aquel que tiene la virtud de or.

2.8

ISACA (INFORMATION SYSTEMS AUDIT AND CONTROL ASSOCIATION - ASOCIACIN DE CONTROL Y AUDITORA DE SISTEMAS DE INFORMACIN)
Desde su creacin, ISACA se ha convertido en una organizacin global que establece las pautas para los profesionales del gobierno, control, seguridad y auditora de informacin. Sus normas de auditora y control de SI son seguidos por profesionales de todo el mundo y sus investigaciones abordan temas profesionales que son desafos para sus constituyentes.

2.9

PRINCIPIOS DE AUDITORA
Segn Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso

47

Ruz11, algunos de los principios publicados por ISACA son: Formalidad Responsabilidad, atribuciones y obligaciones Las responsabilidades, atribuciones y obligaciones que abarca la funcin de auditora de los sistemas de informacin deben documentarse de manera apropiada (formal) en unos estatutos de auditora en el caso de la auditora interna, o en una carta de encargo o contrato en el caso de la auditora externa. Independencia Independencia profesional En todas las cuestiones relacionadas con la Auditora, el auditor de sistemas de informacin debe ser independiente de la organizacin auditada tanto en actitud como en apariencia.

Relacin con la organizacin La funcin de auditora de los sistemas de informacin debe ser lo suficientemente independiente del rea que se est auditando para permitir realizar de manera objetiva la Auditora. tica y normas profesionales Cdigo de tica profesional Al igual que en otros colectivos profesionales, distintos organismos han publicado unos cdigos de conducta o normas deontolgicas que el auditor de sistemas de informacin ha de cumplir. As el auditor que sea miembro de ISACA debe acatar el Cdigo de tica Profesional de ISACA, de lo contrario se pueden se pueden tomar medidas disciplinarias. Diligencia profesional En todos los aspectos del trabajo del auditor de sistemas de informacin, se debe ejercer la atencin profesional correspondiente y el cumplimiento de las normas aplicables de auditora profesional.

11

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

48

Idoneidad Habilidades y conocimientos EI auditor de sistemas de informacin debe ser tcnicamente idneo y tener la experiencia y los conocimientos necesarios para realizar el trabajo de auditor.

Formacin profesional continua EI auditor de sistemas de informacin debe mantener la idoneidad tcnica mediante su formacin profesional continua. Planificacin Planificacin de la Auditora EI auditor de sistemas de informacin debe planificar el trabajo de auditora para satisfacer los objetivos de la Auditora y para cumplir con las normas de auditora aplicables a la profesin.

Ejecucin de la Auditora Evidencia Durante el transcurso de una Auditora, el auditor de sistemas de informacin debe obtener evidencia adecuada (fiable, relevante y til) y suficiente para lograr los objetivos de la Auditora. Los hallazgos y conclusiones de la Auditora se deben basar en el anlisis e interpretacin apropiados de dicha evidencia. Documentacin EI proceso de Auditora deber documentarse, describiendo las labores de auditora realizadas y la evidencia de auditora que respalda los hallazgos y conclusiones del auditor. Supervisin EI personal de auditora de SI debe ser supervisado para brindar una garanta razonable de que se lograran los objetivos de la Auditora y que se cumplirn las normas profesionales de auditora aplicables.

49

Informacin Contenido y formato de los informes En el momento de completar el trabajo de auditora, el auditor de sistemas de informacin debe proporcionar un informe con un formato apropiado a los destinatarios. EI informe de auditora debe enunciar el alcance, los objetivos, el periodo de cobertura y la naturaleza y amplitud del trabajo de auditora realizado. El informe debe identificar al auditarlo (cliente), los destinatarios en cuestin y cualquier restriccin con respecto a su circulacin. EI informe debe enunciar los hallazgos, las conclusiones y las recomendaciones, y cualquier reserva o consideracin que tuviera el auditor con respecto a la Auditora.

2.10 OBJETIVOS GENERALES DE LA AUDITORA


Carlos Muoz Razo12, menciona: Entre los objetivos ms relevantes, encontramos a los siguientes: Realizar una revisin independiente de las actividades, reas o funciones especiales de una institucin, a fin de emitir un dictamen profesional sobre la razonabilidad de sus operaciones y resultados. Hacer una revisin especializada, desde un punto de vista profesional y autnomo, del aspecto contable, financiero y operacional de las reas de la empresa. Evaluar el cumplimiento de los planes, programas, polticas, y lineamientos que regulan la actuacin de los empleados y funcionarios de una institucin, as como evaluar las actividades que se desarrollan en sus reas y unidades administrativas. Dictaminar de manera profesional e independiente sobre los resultados obtenidos por una empresa y sus reas, as como sobre el desarrollo de sus funciones y el cumplimiento de sus objetivos y operaciones.

12

MUOZ RAZO, Carlos. Auditora en Sistemas Computacionales, Pearson Educacin de Mxico.

50

2.11 ALCANCE DE LA AUDITORA


Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso13, mencionan: EI auditor debe determinar el alcance de su trabajo de acuerdo con las Normas Tcnicas y decidir los procedimientos de auditora, as como su extensin, el auditor utilizar su juicio profesional, teniendo en cuenta, muy especialmente, los conceptos de importancia relativa y los riesgos.

EI concepto de importancia relativa es inherente al trabajo del auditor. En consecuencia, los procedimientos diseados para soportar la opinin tcnica en aquellas areas ms significativas y en las que sea ms probable que se puedan producir errores importantes deben ser ms amplios y extensos que en aquellas otras en que no se den estas circunstancias.

EI auditor debe requerir del auditado (cliente) cuanta informacin precise para realizar los trabajos de auditora. Cualquier limitacin al trabajo impuesta por el auditado o sobrevenida a lo largo del trabajo que impida la aplicacin de lo dispuesto en las Normas Tcnicas debe ser considerada en el informe de auditora como una limitacin al alcance.

Para planificar y organizar la actividad de auditora de sistemas de informacin, el auditor debe incluir en el alcance de la Auditora los procesos relevantes y los procesos para supervisar esa actividad as como todos los recursos relacionados con el SI.

2.12 IMPLANTACIN INFORMTICO

DE

SISTEMA

DE

CONTROL

INTERNO

Segn Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso

13

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

51

Ruz14 mencionan que La implantacin de un sistema de control interno informtico permite alcanzar la eficacia del sistema, economa y eficiencia, integridad de los datos, proteccin de los recursos y cumplimiento con las leyes y regulaciones.

Esto se cumple de acuerdo a las siguientes metodologas: Metodologa del ciclo de vida del desarrollo de sistemas Su empleo podr garantizar a la alta Direccin que se alcanzaran los objetivos definidos para el sistema. Estos son algunos controles que deben existir en la metodologa: a) La alta Direccin debe publicar una normativa sobre el uso de metodologa de ciclo de vida del desarrollo de sistemas y revisar esta peridicamente. b) La metodologa debe establecer los papeles y responsabilidades de las distintas areas del Departamento de Informtica y de los usuarios, as como la composicin y responsabilidades del equipo del proyecto. c) Las especificaciones del nuevo sistema deben ser definidas por los usuarios y quedar escritas y aprobadas antes de que comience el proceso de desarrollo. d) Debe establecerse un estudio tecnolgico de viabilidad en el cual se formulen formas alternativas de alcanzar los objetivos del proyecto acompaadas de un anlisis coste-beneficio -de cada alternativa. e) Cuando se seleccione una alternativa debe realizarse el plan director del proyecto. En dicho plan deber existir una metodologa de control de costes. f) Procedimientos para la definicin y documentacin de

especificaciones de: diseo, de entrada, de salida, de ficheros, de procesos, de programas, de controles de seguridad, de pistas de auditora, etc.
14

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

52

g) Plan de validacin, verificacin y pruebas. h) Estndares de prueba de programas, de pruebas de sistemas i) Plan de conversin; prueba de aceptacin final. j) Los procedimientos de adquisicin de software debern seguir las polticas de adquisicin de la Organizacin y dichos productos debern ser probados y revisados antes de pagar por ellos y ponerlos en uso. k) La contratacin de programas de servicios de programacin a medida ha de estar justificada mediante una peticin escrita de un director de proyecto. l) Debern prepararse manuales de operacin y mantenimiento como parte de todo proyecto de desarrollo o modificacin de sistemas de informacin, as como manuales de usuario.

El establecimiento de controles asegurara que los datos se tratan de forma congruente y exacta y que el contenido de sistemas solo ser modificado mediante autorizacin adecuada. Estos son algunos de los controles que se deben implantar: a) Procedimientos de control de explotacin b) Sistema de contabilidad para asignar a usuarios los costos asociados con la explotacin de un sistema de informacin. c) Sistema de contabilidad para asignar a usuarios los costes asociados con la explotacin de un sistema de informacin. d) Procedimientos para realizar un seguimiento y control de los cambios de un sistema de informacin.

2.13 MOTIVOS

PARA

EFECTUAR

UNA

AUDITORA

DE

TECNOLOGAS DE INFORMACIN
Segn entrevista personal con el Mg. Ing. Henry George, Maquera Quispe: Entre los principales justificativos o motivos de una auditora, encontramos:

53

Aumento del presupuesto del Departamento de procesamiento de datos. Desconocimiento de la situacin informtica de la empresa. Falta total o parcial de seguridades lgicas y fsicas que garanticen la integridad del personal, equipos e informacin. Descubrimientos de fraudes efectuados con el uso del computador. Falta de una planificacin informtica. Falta de visin. Organizacin que no funciona correctamente, debido a falta de polticas, objetivos, normas, metodologa, estndares, delegacin de autoridad, asignacin de tareas y adecuada administracin del recurso humano.

Descontento general de los usuarios, motivado generalmente, por incumplimiento de plazos y mala calidad de resultados. Falta de documentacin o documentacin incompleta de sistemas.

Dentro de los motivos para efectuar una Auditora, el INEI en su pgina Web: Qu es La Auditora Informtica?, Hace referencia cuando existen sntomas de debilidad en la empresa, stas acuden a las auditoras externas para poder determinar en donde estn las falencias. Estos sntomas se pueden agrupar clases:

Cuando existe Desorganizacin y Descoordinacin: a) Los promedios conseguidos no se habitan a los estimados, porque los parmetros de productividad no son respetados y sufren un desvo. b) Los objetivos que la empresa persigue, no coinciden con los obtenidos. c) Esto puede darse debido a un cambio masivo de personal, o tambin porque un rea tuvo una mala reestructuracin, tambin puede deberse a una norma importante que haya sido modificada.

Cuando hay insatisfaccin del cliente y una mala imagen: a) Cuando no hay capacidad de satisfacer las necesidades del cliente.
54

b) Las fallas en hardware no son reparadas, ni se resuelven las incidencias en plazos establecidos y razonables, ocasionando un descontento en el usuario por sentirse abandonado. c) Los resultados peridicos no son entregados en los plazos establecidos. Las pequeas imprecisiones pueden ocasionar que la informacin no refleje lo real y que la actividad que ejerce el usuario se vea afectada por este motivo.

Debilidades Econmico-Financieras: a) Elevacin de costos de forma repentina y desmesurada. b) Cuando se da la necesidad de justificar las inversiones informticas. c) Cuando se dan otras prioridades en el aspecto presupuestario. d) Costos y plazos de nuevos proyectos.

Cuando existe inseguridad: Se da una evaluacin de nivel de riesgos, la que contempla los puntos siguientes: a) Seguridad Lgica. b) Seguridad Fsica. c) Aspectos de confidencialidad. La continuidad en el servicio es importante. En ocasiones se considera ms importante que los aspectos de seguridad. Si existen problemas en los que el centro de procesamiento de datos se encontrara fuera de control, una auditora no tendra

sentido por considerarse intil, por eso deben tomarse en cuenta los ms mnimos indicios para su aplicacin.

2.14 CONTROL INTERNO


Segn el entrevista personal con el Mg. Ing. Henry George, Maquera Quispe: Entre los principales justificativos o motivos de una auditora, encontramos que: Esta referido fundamentalmente a la adopcin de medidas preventivas, que tienen como finalidad salvaguardar los bienes
55

de la empresa. Busca evitar acciones nefastas como sabotajes, fraudes y otro tipo de situaciones que lleven a inestabilidad o desaparicin del negocio.

Segn Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruz15: El Control Interno informtico controla diariamente que todas las actividades de sistemas de informacin sean realizadas cumpliendo los procedimientos, estndares y normas fijados por la Direccin de la Organizacin y/o la Direccin de Informtica, as como los requerimientos legales.

La misin del Control Interno Informtico es asegurarse de que las medidas que se obtienen de los mecanismos implantados por cada responsable sean correctas y vlidas.

Como principales objetivos podemos indicar los siguientes: Controlar que todas las actividades se realizan cumpliendo los procedimientos y normas fijados, evaluar su bondad y asegurarse del cumplimiento de las normas legales. Asesorar sobre el conocimiento de las normas. Colaborar y apoyar el trabajo de Auditora Informtica, as como de las auditoras externas al Grupo. Definir, implantar y ejecutar mecanismos y controles para comprobar el logro de los grados adecuados del servicio informtico, lo cual no debe considerarse como que la implantacin de los mecanismos de medida y la responsabilidad del logro de esos niveles se ubique exclusivamente en la funcin de Control Interno, sino que cada responsable de objetivos y recursos es responsable de esos niveles, as como de la implantacin de los medios de medida adecuados.

15

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

56

2.14.1 Componentes del Control Interno Segn el Mg. Ing. Henry George, Maquera Quispe: La nueva economa ha obligado a las empresas a realizar cambios. Algunos de estos cambios, se pueden resumir en: Restructuracin de los procesos empresariales (BPR: Business Process Re-engineering) Gestin de la calidad (TQM) Redimensionamiento por reduccin o crecimiento hasta el nivel correcto Outsourcing Descentralizacin.

Los cambios que se mencionan, se deben a fuerzas externas que presionan a la empresa (ver Figura N11). Ante esta situacin, las empresas deben evaluar sus sistemas de control interno de manera permanente. Para enfrentar y manejar estas fuerzas, se hace necesaria la adopcin de la tecnologa disponible. Los Sistemas de informacin constituyen un soporte fundamental para poner en marcha las estrategias planteadas por la alta direccin. Esto origina tambin un aumento de las necesidades de control y Auditora. Es en este escenario que aparecen dos (02) conceptos fundamentales: El control interno y la Auditora informtica.

Figura N 11. Fuerzas que presionan a un Sistema Fuente: Elaboracin Propia.

57

2.15 AUDITORA INFORMTICA


Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso16 mencionan que: La Auditora Informtica es el proceso de recoger, agrupar y evaluar evidencias parar determinar si un sistema informatizado salvaguarda los activos, mantiene la integridad de los datos, lleva a cabo eficazmente los fines de la organizacin y utiliza eficientemente los recursos. De este modo la Auditora Informtica sustenta y confirma la consecucin de los objetivos tradicionales de la Auditora :

Objetivos de proteccin de activos e integridad de datos Objetivos de gestin que abarcan, no solamente los de proteccin de activos, sino tambin los de eficacia y eficiencia.

Carlos Muoz Razo17 sostiene que: Es la revisin tcnica especializada y exhaustiva que se realiza a los sistemas computacionales, software e informacin utilizados en una empresa, sean individuales, compartidos y/o de redes, as como a sus instalaciones, telecomunicaciones, mobiliario, equipos de perifricos y dems componentes. Dicha revisin se realiza de igual manera a la gestin informtica, el aprovechamiento de sus recursos, las medias de seguridad y de los bienes de consumo necesarios para el funcionamiento del centro de cmputo.

El propsito fundamental es evaluar el uso adecuado de los sistemas para el correcto ingreso de datos, el procesamiento adecuado de la informacin y la emisin oportuna de sus resultados en la institucin, incluyendo la evaluacin en el cumplimiento de las funciones, actividades y operaciones de funcionarios, empleados y usuarios involucrados con los servicios que proporcionan los sistemas computacionales a la empresa.

El INEI en su pgina Web: Qu es la Auditora Informtica? Hace

16

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008. 17 MUOZ RAZO, Carlos. Auditora en Sistemas Computacionales, Pearson Educacin de Mxico.

58

referencia a los objetivos fundamentales de la Auditora informtica: La Auditora debe iniciar su actividad cuando los Sistemas estn operando, ste es el principal objetivo, el de mantener tal situacin. Tal objetivo debe conseguirse tanto a nivel global como parcial.

La operatividad de los sistemas ha de constituir entonces la principal preocupacin del Auditor informtico. Para conseguirla hay que acudir a la realizacin de Controles tcnicos generales de operatividad y Controles tcnicos especficos de operatividad, previos a cualquier actividad de aquel.

2.15.1 Control Interno y Auditora Informtica: Campos Anlogos El control interno Informtico y la auditora Informtica, tienen similitudes en sus objetivos profesionales. Son campos anlogos que propician una transicin natural entre ambas disciplinas. Sin embargo existen diferencias que conviene resaltar.

Tabla N 08. Similitudes y diferencias entre Control interno y Auditora Informtica Fuente: Libro N 06, Pg. 24 (vase Bibliografa).

2.16 TCNICAS Y HERRAMIENTAS USADAS POR LA AUDITORA INFORMTICA


El INEI en su pgina Web: Qu es la Auditora Informtica? Hace
59

referencia a: Cuestionarios La informacin recopilada es muy importante, y esto se consigue con el levantamiento de informacin y documentacin de todo tipo. Los resultados que arroje una auditora se ven reflejadas en los

informes finales que estos emitan y su capacidad para el anlisis de situaciones de debilidades o de fortalezas que se dan en los diversos ambientes. El denominado trabajo de campo consiste en que el auditor busca por medio de cuestionarios recabar informacin necesaria para ser discernida y emitir finalmente un juicio global objetivo, los que deben ser sustentados por hechos demostrables, a quienes se les llama evidencias.

Esto se puede conseguir, solicitando el cumplimiento del desarrollo de formularios o cuestionarios lo que son pre impresos, los cuales son dirigidas a las personas que el auditor considera ms indicadas, no existe la obligacin de que estas personas sean las responsables de dichas reas a auditar. Cada cuestionario es diferente y muy especfico para cada rea, adems deben ser elaborados con mucho cuidado tomando en cuenta el fondo y la forma. De la informacin que ha sido analizada cuidadosamente, se elaborar otra informacin la cual ser emitida por el propio Auditor. Estas informaciones sern cruzadas, lo que vine a ser uno de los pilares de la auditora.

Muchas veces el auditor logra recopilar la informacin por otros medios, y que estos pre impresos podan haber proporcionado, cuando se da este caso, se puede omitir esta primera fase de la auditora.

Entrevistas Existen tres formas para que el auditor logre relacionarse con el personal auditado.

60

La solicitud de la informacin requerida, esta debe ser concreta y debe ser de la materia de responsabilidad del auditado, en la entrevista no se sigue un plan predeterminado ni un mtodo estricto de sometimiento a un cuestionario, la entrevista es un medio por el que el auditor usar metodologas las que han sido establecidas previamente con la finalidad de encontrar informacin concreta.

La importancia que la entrevista tiene en la auditora se debe a que, la informacin que recoge es mayor y se encuentra mejor elaborada, y es ms concreta que las que pueden proporcionar los medios tcnicos o los cuestionarios. La entrevista personal entre el auditor y el personal auditado, es basada en una serie de preguntas especficas en las que el auditado deber responder directamente. El sistema de

interrogacin se establece previamente y el auditor tendr mucho cuidado, esta entrevista se debe dar de una forma muy cordial y bajo los parmetros de lo correcto, esto se hace con la finalidad de que sea lo menos tensa posible, y que el auditado conteste de la forma ms natural, con mucha sencillez. Slo que esta sencillez con la que se elaboran las preguntas debern tener un fondo muy profundo, el cual es distinto en cada caso.

El auditor cuando es ducho en la materia y tiene mucha experiencia, realiza un trabajo de reelaboracin de sus cuestionarios de acuerdo a la situacin y al escenario auditado.

Este es un personaje que sabe que es lo que busca, debido a que tiene bien en claro lo que necesita, y porque lo necesita. Su trabajo es el pilar fundamental para el anlisis, cruce y elaboracin posterior del informe final, pero esto no indica que el auditado tenga que ser sometido a un interrogatorio automatizado lo cual no ofrece ningn camino. Por el contrario el auditor realiza la entrevista de tal forma que el auditado pueda responder a las preguntas formuladas de manera normal, lo que servir para llegar al cumplimiento de los cuestionarios
61

de sus Check Lists.

2.17 AUDITORA DE SISTEMAS DE INFORMACIN


Segn Alonso Tamayo Alzate18 : La Auditora de sistemas es la parte de la auditora interna que se encarga de llevar a cabo la evaluacin de normas, controles, tcnicas y procedimientos que se tienen establecidos en una empresa para logar confiabilidad, oportunidad, seguridad y confidencialidad de la informacin que se procesa a travs de computadores; es decir, en estas evaluaciones se est involucrado tanto los elementos tcnicos como humanos que intervienen en el proceso de informacin.

Figura N 12. Definicin de Auditoria de Sistemas Fuente: Libro N 07, Pg. 10 (vase Bibliografa).

Segn el Instituto Nacional de Estadstica e Informtica (INEI) en su investigacin Auditora de Sistemas. La Auditora de Sistemas es el conjunto de tcnicas que permiten detectar deficiencias en las organizaciones de informtica y en los sistemas que se desarrollan u operan en ellas, incluyendo los servicios externos de computacin, que permitan efectuar acciones preventivas y correctivas para eliminar las fallas y carencias que se detecten.

Se
18

verifica

la

existencia

y aplicacin de todas las normas y

TAMAYO ALZATE, Alonso. Auditora de Sistemas Una visin prctica, Universidad Nacional de Colombia, 2003.

62

procedimientos requeridos para minimizar las posibles causas de riesgos tanto en las instalaciones y equipos, como en los programas

computacionales y los datos, en todo el mbito del Sistema: usuarios, instalaciones, equipos.

Las Instituciones efectan Auditoras de Sistemas, con la finalidad de asegurar la eficiencia de las organizaciones de informtica, as como la confiabilidad y seguridad de sus sistemas.

Segn entrevista personal con el Mg. Ing. Henry George, Maquera Quispe: La Auditora de Tecnologas de Informacin es un Examen objetivo, crtico, sistemtico, eminentemente posterior y selectivo de las polticas, normas, prcticas, procedimientos y procesos con el fin de emitir una opinin respecto a la eficiencia en la utilizacin de los recursos informticos; la confiabilidad, consistencia, integridad y oportunidad de la informacin y la efectividad de los controles en los sistemas de informacin computarizados.

Segn Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruz19 : En la dcada del 1970 (concretamente se funda en 1967) se consolida la que hoy se llama Information Systems Audit and Control Association (ISACA), siendo an hoy la nica entidad, a nivel mundial, de los auditores de SI, y que gestiona una certificacin en esta materia: Certified Information Systems Auditor (CISA). Esta asociacin, que est presente en ms de 140 pases, a travs de ms de 170 captulos (Chapters, en ingls) en todo el mundo, establece normas y procedimientos para la funcin de la Auditora de SI y los profesionales que las realizan.

Las preocupaciones fundamentales con respecto a la tecnologa aludida anteriormente siguen siendo GIS mismas o se han incrementado con la
19

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

63

evolucin tecnolgica. Estas inquietudes tanto de la Direccin de una entidad, como de sus accionistas o de la sociedad en general, se pueden concretar en: La veracidad de la informacin, en cuanto a su totalidad y exactitud, procesada por los sistemas de tecnologa. La utilizacin racional y ajustada a las necesidades reales de los recursos tecnolgicos. EI "mantenimiento" o "sostenibilidad" de la estructura tecnolgica y su crecimiento no debe ser traumtico en el soporte de nuevas actividades. La confidencialidad de la informacin La proteccin de sus activos, especialmente el software y la informacin.

2.18 OBJETIVOS DE LA AUDITORA DE SISTEMAS


Segn Alonso Tamayo Alzate20, resalta los objetivos que persigue la Auditora de sistemas, los cuales se presentan agrupados en objetivos generales y objetivos especficos, de la siguiente forma:

Figura N 13. Objetivos de Auditoria de Sistemas Fuente: Libro N 07, Pg. 11 (vase Bibliografa).

Objetivos Generales

Evaluar las polticas generales sobre la planeacin, ambiente laboral,


20

TAMAYO ALZATE, Alonso. Auditora de Sistemas Una visin prctica, Universidad Nacional de Colombia, 2003.

64

entrenamiento y capacitacin, desempeo, supervisin, motivacin y remuneracin del talento humano. Evaluar polticas generales de orden tcnico con respecto al software, hardware, desarrollo, implantacin, operacin y mantenimiento de sistemas de informacinEvaluar polticas generales sobre seguridad fsica con respecto a instalaciones, personal, equipos, documentacin, back-ups, plizas y planes de contingencias. Evaluar los recursos informticos de la empresa con nfasis en su nivel tecnolgicos, produccin de software y aplicaciones ms comnmente utilizadas. Asesorar a la gerencia y altos directivos de la empresa en lo

relacionado con los sistemas de informacin, de tal forma que el proceso de toma de decisiones se efecte lo ms acertadamente posible. Conocer las polticas generales y actitudes de los directivos frente a la Auditora y seguridad de los sistemas de informacin y proceder a hacer las recomendaciones pertinentes.

2.19 PLANTEAMIENTO Y METODOLOGA


Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso21, mencionan que:

La Auditora se desglosa en: Auditora de la organizacin y gestin del rea de desarrollo y mantenimiento. Auditora de la planificacin y gestin del proyecto. Auditora de la fase de estudio de viabilidad Auditora de la fase de anlisis Auditora de la fase de diseo

21

PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008.

65

Auditora de la fase de construccin Auditora de la fase de implantacin Auditora de la fase de mantenimiento

La metodologa que se aplica es la propuesta por la ISACA (Information Systems Audit and Control Association), que est basada en COBIT (Control Objectives for Information and Related Technologies), la cual proporciona un conjunto estructurado de buenas prcticas y metodologas para su aplicacin, cuyo objetivo es facilitar el gobierno de las TIC. COBIT est basado en la evaluacin de riesgos, de manera que partiendo de los riesgos potenciales a los que est sometida la actividad, en este caso el desarrollo o mantenimiento de SI, se determinan una serie de objetivos de control de alto nivel que minimicen esos riesgos.

Para cada objetivo de control de alto nivel, agrupados por cada una de las fases del ciclo de vida del software identificadas en Mtrica versin 3 (MAP, 2007), se especifican uno o ms objetivos de control de detalle o tambin denominadas prcticas de control, que contribuyen a lograr el cumplimiento de dicho objetivo de control de alto nivel; para lo cual se ha basado tambin en la propuesta de Rodero (2001). As mismo, se aportan una serie pruebas de cumplimiento que permitan comprobar la existencia y correcta aplicacin de dichos controles. Ser la funcin del auditor determinar el grado de cumplimiento y madurez de cada uno de ellos.

66

CAPITULO III METODOLOGIA


3.1. TIPO DE INVESTIGACIN
El presente estudio es una investigacin aplicada- descriptivo correlacional; el diseo es Ex post - facto de corte transversal, porque la naturaleza del problema no es de causalidad, pues se realiza sin manipular deliberadamente las variables, puesto que solo se observaron los hechos como se presentan en su contexto.

3.2.

MBITO DE ESTUDIO
El presente trabajo de investigacin se desarroll en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn.

3.3.

POBLACIN Y MUESTRA
Est conformado por la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn. Por ser el nmero de unidades de anlisis pequea (07 miembros del staff) se han considerado a todos ellos.

3.4.

UNIDAD DE ANLISIS
Est conformada por el total del personal de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin del Gobierno Regional de Junn.

67

3.5.

TCNICA E INSTRUMENTOS DE RECOLECCIN DE DATOS:


Tcnicas: Durante el proceso de ejecucin del presente estudio, se revisaran trabajos de investigacin relacionados con el tema, as como fuentes bibliogrficas primarias. Instrumentos y Recoleccin de Datos: Para realizar la Auditora y plantear las mejoras al desarrollo del sistema de informacin, se ha elaborado un cuestionario, el cual consta de 47 preguntas. Para la Auditora: La metodologa que se aplica es la propuesta por la ISACA (Information Systems Audit and Control Association), que est basada en COBIT (Control Objectives for Information and Related Technologies), la cual proporciona un conjunto estructurado de buenas prcticas y metodologas para su aplicacin, cuyo objetivo es facilitar el gobierno de las Tecnologas de Informacin y

Comunicaciones. COBIT est basado en la evaluacin de riesgos, de manera que partiendo de los riesgos potenciales a los que est sometida la actividad, en este caso el desarrollo o mantenimiento de SI, se determinan una serie de objetivos de control de alto nivel que minimicen esos riesgos. Para cada objetivo de control de alto nivel, se agrupa por cada una de las fases del ciclo de vida del software identificadas en Mtrica versin 3 (MAP, 2007), se especifican uno o ms objetivos de control de detalle o tambin denominadas prcticas de control, que contribuyen a lograr el cumplimiento de dicho objetivo de control de alto nivel. As mismo, se aportan una serie pruebas de cumplimiento que permitan comprobar la existencia y correcta aplicacin de dichos controles

3.6.

PROCESAMIENTO, ANLISIS E INTERPRETACIN DE DATOS:


Luego de aprobado el tema de tesis, se procedi a recolectar los datos; de la encuesta dirigida al staff. Estos datos son vaciados al programa Microsoft Excel; cuyos resultados son presentados en grficos. En el anlisis y discusin se tomar en cuenta el marco terico y los antecedentes de estudio.
68

3.7.

DETERMINACIN DEL DESARROLLO DE INFORMACIN:

SISTEMAS DE

Se realiz a travs de la evaluacin de sus fases de desarrollo de sistemas, cumplimiento de estndares y normas de control interno.

69

CAPITULO IV DESARROLLO

4.1.

AUDITORA

DEL

DESARROLLO

DE

SISTEMAS

DE

INFORMACIN EN LA OFICINA REGIONAL DEL DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFOMACIN ORDITI


Aplicando la divisin funcional a la Oficina Regional del Desarrollo Institucional y Tecnologa de la Informacin ORDITI, una de las reas que tradicionalmente aparece es la de desarrollo. Esta funcin abarca todas las fases que se deben de seguir desde que aparece la necesidad de disponer de un determinado sistema de informacin hasta que ste es construido e implantado. Para delimitar el mbito de este captulo, se entender la organizacin en general y el rea especfica aadido a esto todo el ciclo de vida del Proyecto de software: Auditoria de la organizacin y gestin de la Oficina Regional del Desarrollo Institucional y Tecnologa de la Informacin ORDITI. Auditoria de la Gestin y Planificacin del Proyecto. Auditoria de la fase de Estudio de Viabilidad del Proyecto. Auditoria de la fase de Anlisis del Sistema de Proyecto. Auditoria de la fase de Diseo del Sistema de Proyecto. Auditoria de la fase de Construccin del Sistema de Proyecto. Auditoria de la fase de Implantacin y Aceptacin del Proyecto. Auditoria de la fase de Mantenimiento del Sistema de Proyecto.

70

4.2.

AUDITORIA DE LA ORGANIZACIN Y GESTIN DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACIN ORDITI.

AUDITORIA DE LA ORGANIZACIN Y GESTIN DE LA OFICINA REGIONAL DE DESARROLLO INSTITUCIONAL Y TECNOLOGA DE LA INFORMACIN ORDITI. 4.2.1. Objetivo de Control OG1: Procesos, organizacin y relaciones: El rea de sistemas debe tener definidos los procesos de su organizacin. SI NO Observaciones

OG1-C1: Deben establecerse de forma clara las funciones del rea. Existe algn documento que contiene las funciones que son competencia del centro de X informacin y sistemas, est aprobado y se respeta. OG1-C2: Debe especificarse en el organigrama puestos del rea y el staff. Existe un organigrama con la estructura de organizacin del rea. OG1-C3: Debe establecerse el marco de trabajo de los procesos del rea de sistemas, de modo que permita la ejecucin y puesta en prctica del plan operativo informtico. EI marco de trabajo permite la definicin y seguimiento de los objetivos de los procesos que han sido definidos e implementados, as como formalmente documentados y aprobados. OG1-C4: Deben establecerse roles y responsabilidades para la gestin del aseguramiento de la calidad, gestin de riesgos, seguridad y conformidad. El staff cuenta con los sistemas de aseguramiento de la calidad apropiados, as como los controles y asesoramiento de expertos. Las responsabilidades y roles han sido correctamente establecidos, formalizados, documentados y satisfacen los requisitos del rea. Son ejecutados por personal con la suficiente formacin y experiencia en la materia. X X X

4.2.2. Objetivo de Control OG2: Gestin de Recursos Humanos: El rea de sistemas debe contar con recursos humanos adecuados para gestionar el desarrollo y mantenimiento de SI. 71

OG2-C1: Deben existir procedimientos de contratacin objetivos. Las ofertas de puestos del rea se difunden de forma suficiente fuera de la organizacin y las selecciones del personal se hacen de forma objetiva. Las personas seleccionadas cumplen los X X

requisitos del puesto al que acceden. OG2-C2: Debe existir un plan de capacitacin que este en consonancia con los objetivos del rea y alineados con los objetivos institucionales. Se tiene aprobado un plan de capacitacin a corto, medio y largo plazo que sea coherente con el plan operativo informtico OG2-C3: Debe existir una biblioteca accesible por el personal del rea. Estn disponibles un nmero suficiente de libros, publicaciones peridicos, monografas de X X

reconocido prestigio, ya sea en formato electrnico o papel. El personal tiene acceso a ellos. OG2-C4: El personal debe estar motivado en la realizacin de su trabajo. Existe algn mecanismo que permita a los empleados hacer sugerencias sobre mejoras en la organizacin del rea. No existe una gran rotacin de personal, existe un buen ambiente de trabajo. X X

4.2.3. Objetivo de Control OG3: Plan Estratgico de Tecnologas de la Informacin del rea: El rea de sistemas debe participar en la definicin del plan estratgico de Tecnologas de la Informacin OG3-C1: el rea debe tener y difundir su propio plan a corto, medio y largo plazo. Existe el plan estratgico de Tecnologas de la Informacin. Se revisa y actualiza con periodicidad en funcin de las nuevas situaciones. X X

72

Se difunde a todo el staff para que se sientan partcipes del mismo.

OG3-C2: La realizacin de nuevos proyectos debe basarse en el plan estratgico de Tecnologas de la Informacin y en el plan operativo informtico en cuanto a objetivos, marco general. Las fechas de realizacin coinciden con las del plan estratgico. La documentacin relativa a cada proyecto que existe en el plan estratgico se pone a disposicin del director de proyecto una vez comenzado el mismo. Esta informacin debe contener los X X

objetivos, los requisitos generales y un plan inicial.

4.2.4. Objetivo de Control OG4: Gestin de la calidad: El rea de sistemas debe disponer de procesos de desarrollo regidos por estndares y principios de ingeniera de software ampliamente aceptados. OG4-C1: Debe existir un registro de problemas que se producen en los proyectos del rea, incluyendo los fracasos de proyectos completos. Existe un catlogo de problemas, incluyendo para cada uno de ellos la solucin o soluciones encontradas, proyecto en el que sucedi, persona que lo resolvi. EI catlogo es accesible para todos los miembros del rea, esta actualizado y tiene uno o varios ndices que faciliten la bsqueda. Se registran y controlan todos los proyectos fracasados (aquellos que comienzan y no llegan a su fin), as como los recursos invertidos en los mismos. OG4-C2: Debe mantenerse y comunicarse peridicamente al rea las modificaciones del plan de calidad a fin de promover la mejora continua. El plan existe y se actualiza peridicamente. Existen y se ejecutan actividades de mejora continua segn y los estndares, de prcticas, del 73 X X X X X

procedimientos

polticas

calidad

departamento adoptadas por el rea de sistemas. OG4-C3: Debe existir algn mecanismo de creacin y actualizacin de prcticas y estndares de calidad as como de prcticas, estndares de desarrollo y mantenimiento. EI mecanismo para la creacin y actualizacin de prcticas y estndares est documentado y es conocido en el rea. Estn definidas las prcticas de anlisis y diseo, e incluye las tcnicas y herramientas a usar. As como tambin hay una gua o prcticas de programacin para cada uno de los lenguajes homologados Hay un estndar general generada, tcnica (anlisis, para toda la X X X

documentacin documentacin usuario, etc.

incluyendo diseo,

documentacin de los programas), manuales de

OG4-C4: Debe existir un procedimiento de monitorizacin y medicin del cumplimiento de estndares y prcticas de calidad as como de los de desarrollo y mantenimiento. Se realizan informes ejecutivos peridicamente sobre la calidad de los SI en el rea. Estn definidas mtricas de calidad y stas estn alineadas con los objetivos de calidad del rea y ayudan en la consecucin de los objetivos del rea. Se realizan inspecciones en los hitos de los proyectos para verificar el cumplimiento de los estndares y prcticas. OG4-C5: Debe practicarse la reutilizacin del software. Existe un repositorio con todos los productos software susceptibles de ser reutilizados: libreras de funciones, clases de objetos, componentes software, documentos (catlogo de requisitos X X X X

comunes, arquitecturas). EI repositorio o catlogo es conocido y accesible por todos los miembros del rea, esta actualizado 74

y tiene uno o varios ndices que faciliten la

OG4-C6: Debe existir un modelo de la arquitectura de informacin que se actualice bsqueda. regularmente y defina los sistemas apropiados que optimicen el uso de la informacin. Existe un diccionario de datos institucional con las reglas de sintaxis de la organizacin, el esquema de clasificacin de datos y sus niveles de X

seguridad correspondientes. Se garantiza la consistencia y seguridad de la informacin de los SI con los recursos X proporcionales y dicha informacin se alinea con la estrategia y objetivos de la institucin. OG4-C7: Los lenguajes, compiladores, software de pruebas, software de control de versiones; utilizados en el rea deben ser previamente vlidos. Existe un mecanismo para la adquisicin y validacin de cualquier nuevo producto software usado en el desarrollo. Se deben evaluar al menos los siguientes parmetros: productividad, X

portabilidad a otros entonos, transicin desde los productos actuales, de los riesgo de del cambio, rea,

cumplimiento

estndares

compatibilidad con el entorno tecnolgico, costos, entre otros. Cuando se valida un nuevo producto de desarrollo se forma al personal del rea que lo vaya a manejar. X

Se registra la informacin ms importante acerca de la configuracin de los productos recin adquiridos. X

Tabla N 09. Auditoria de la organizacin y gestin de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin ORDITI Fuente: Elaboracin Propia.

75

4.3.

AUDITORA PROYECTO.

DE

LA

GESTIN

PLANIFICACIN

DEL

AUDITORA DE LA GESTIN Y PLANIFICACIN DEL PROYECTO SI NO Observaciones

4.3.1. Objetivo de Control P1: El proyecto de desarrollo debe estar aprobado, definido y planificado formalmente. P1-C1: Debe existir documento de aprobacin del proyecto que defina claramente los objetivos, restricciones y las reas afectadas. Existe algn documento de aprobacin del X

proyecto autorizada por algn rgano competente. En el documento de aprobacin estn definidos de forma clara y precisa los objetivos del mismo y las restricciones de todo tipo que deben tenerse en cuenta (recursos tcnicos y humanos, X presupuesto, entre otros.) y su alineacin con el plan estratgico. Se han identificado las unidades de la X

organizacin a las que afecta. P1-C2: Debe designarse un responsable o director del proyecto. X La designacin se ha llevado a cabo segn el procedimiento establecido. Se le ha comunicado al director su designacin junto X

con toda la informacin relevante del proyecto. P1-C3: El proyecto debe ser catalogado en funcin de sus caractersticas, se debe determinar el modelo de ciclo de vida que seguir. Se ha descrito y dimensionado el proyecto segn las normas establecidas. Se han evaluado los riesgos asociados al X X

proyecto, especialmente cuando se van a usar tecnologas no usadas hasta el momento. Se ha elegido el ciclo de vida ms adecuado al tipo de proyecto. Se ha hecho uso de la informacin histrica que se dispone tanto para dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de vida. P1-C4: Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo tcnico que realizar el proyecto y se determinar el plan del proyecto. X X

76

La designacin del equipo de desarrollo se ha llevado a cabo segn el procedimiento establecido. Se ha comunicado a todos los miembros del staff de desarrollo los objetivos del proyecto, la

responsabilidad que tendrn en el mismo, las fechas en las participaran y la dedicacin completa o parcial. EI plan de proyecto realizado es realista y utiliza la informacin histrica de la que se disponga para realizar estimaciones. X

4.3.2. Objetivo de Control P2: El proyecto se debe gestionar de forma que se consigan los mejores resultados posibles teniendo en cuenta las restricciones de tiempo y recursos. P2-C1: Los responsables de las areas afectadas por el proyecto deben participar en la gestin del proyecto. Se ha constituido formalmente el comit de direccin del proyecto y estn incluidos los X

responsables de todas las unidades afectadas. EI comit tiene una periodicidad de reunin mnima, y en cualquier caso siempre que lo exija el desarrollo del proyecto, debe tener competencia para asignacin de recursos, la revisin de la marcha del proyecto y para modificar el plan del proyecto en funcin de las revisiones. Las reuniones se hacen con un orden del da previo y las decisiones tomadas quedan X X

documentadas en las actas de dicho comit. EI nmero de reuniones y la duracin de las mismas no superan un lmite razonable comparado con la envergadura del proyecto. P2-C2: Se debe establecer un mecanismo para la resolucin de los problemas que pueden surgir a lo largo del proyecto. X

77

Existen hojas de registro de problemas y hay alguna persona del proyecto encargada de su recepcin, as como un procedimiento conocido de tramitacin. Existe un mtodo para catalogar y dar prioridad a los problemas, as como para trasladarlos a la persona que de los debe resolver, informando si es necesario al director del proyecto y al comit de direccin. Se controla la solucin del problema y se deja constancia del mismo. P2-C3: Debe existir un control de cambios a lo largo del proyecto. Existe un mecanismo para registrar los cambios que pudieran producirse, as como para evaluar el impacto de los mismos. La documentacin afectada se actualiza de forma adecuada y se !leva un control de versiones de cada producto, consignando la ltima fecha de X X X X X

actualizacin. Se remite la nueva versin de los documentos actualizados a los participantes en el proyecto. P2-C4: Cuando sea necesario reajustar el plan del proyecto, normalmente en un hito al finalizar una fase, debe hacerse de forma adecuada. Se respetan los lmites temporales y X X

presupuestarios marcados al inicio del proyecto. Si no es as debe ser aprobado por el comit de direccin. Se ha tenido en cuenta los riesgos del reajuste. Se ha hecho uso de la informacin histrica que se dispone en el rea sobre estimaciones. Se notifica el cambio a todas las personas que participen en el proyecto y se ven afectados. X

P2-C5: Debe hacerse un seguimiento de los tiempos utilizados tanto por tarea como a lo largo del proyecto Existe algn procedimiento que permite registrar el X 78

tiempo que dedica y qu tarea realiza cada participante. Existe algn procedimiento para analizar las X desviaciones y proponer acciones correctivas. P2-C6: Se debe controlar que se sigan las etapas del ciclo de vida adoptado para el proyecto y que se generan todos los documentos asociados a la metodologa usada. Antes de comenzar una nueva etapa, se ha documentado la etapa previa y se ha revisado y aceptado, especialmente en las fases de anlisis y diseo. La documentacin cumple los estndares y procedimientos establecidos en el rea. Se respeta el uso de recursos previamente establecido. P2-C7: Cuando termina el proyecto se debe cerrar toda la documentacin del mismo, liberar los recursos utilizados y hacer balance. La documentacin del proyecto es completa y est catalogada posteriores. Los recursos, tanto personales como materiales, se ponen a disposicin del rea del que provienen. El comit de direccin y el director del proyecto hacen balance del proyecto, estudiando los X posibles problemas y sus causas, los cambios del plan. Toda esta informacin se registra en los archivos problemas.
Tabla N 10. Auditoria de la gestin y planificacin del Proyecto Fuente: Elaboracin Propia.

perfectamente

para

accesos

X X

histricos

sobre

estimaciones

79

4.4.

AUDITORA DE LA FASE DE ESTUDIO DE VIABILIDAD DEL PROYECTO


AUDITORA DE LA FASE DE ESTUDIO DE VIABILIDAD DEL PROYECTO SI NO Observaciones

4.4.1.1 Objetivo de Control V1: Antes de la definicin del proyecto deben estudiarse los requisitos, situacin actual, identificando seguidamente las alternativas de solucin y seleccionando aquella que satisfaga ms eficaz y eficientemente los requisitos identificados. V1-C1: Debe haberse establecido el alcance de las iniciativas requeridas para satisfacer las necesidades planteadas por el usuario. Existe un documento que recoge la descripcin general de la necesidad planteada por el usuario y los objetivos generales as como las posibles restricciones tcnicas, operativas y econmicas. Se han determinado formalmente el grupo de usuarios que participar en el proyecto, X X

identificndose sus perfiles y dejando claras sus tareas y responsabilidades. V1-C2: Debe estudiarse la situacin actual y determinar los sistemas afectados. X Se han realizado modelos del sistema. Se ha realizado un diagnstico de la situacin X actual. V1-C3: Los usuarios y responsables de las unidades que afecta el nuevo sistema establecern de forma clara los requisitos del mismo. Se ha realizado un plan detallado de entrevistas con el grupo de usuarios y con los responsables de las unidades afectadas que permita conocer cmo valoran el sistema actual y lo que esperan del nuevo sistema. Existe un catlogo de requisitos. Cada requisito tiene una prioridad y est clasificado en funcional y no funcional. EI catlogo de requisitos ha sido revisado y aprobado por el grupo de usuario y los responsables as como por el comit de direccin.
Tabla N 11. Auditoria de la fase de Estudio de Viabilidad del Proyecto Fuente: Elaboracin Propia.

80

4.5.

AUDITORA DE LA FASE DE ANLISIS DEL PROYECTO


AUDITORA DE LA FASE DE ANLISIS DEL PROYECTO

4.5.1. Objetivo de Control A1: Se debe elaborar una especificacin detallada que permita describir con precisin el sistema de informacin. A1-C1: Debe realizarse un plan detallado de sesiones de trabajo con el grupo de usuarios del proyecto y los responsables de las unidades afectadas para recopilar la informacin necesaria. Las tcnicas que se utilizan para la recopilacin de informacin es la adecuada en funcin de las caractersticas del proyecto y los tipos de usuario a entrevistar. Se remite el guin a los entrevistados con tiempo suficiente para que estos puedan preparar la entrevista y la documentacin que deseen aportar a la misma. Y el guin incluye todas las cuestiones necesarias para obtener la informacin sobre las funciones deseadas y problemas que se quieren resolver.

A1-C2: A partir de la informacin obtenida de las entrevistas se debe realizar la descripcin inicial del SI y obtener el catlogo de requisitos detallado del mismo. X Existe un catlogo de requisitos, estos estn justificados y detallados. Cada requisito tiene una prioridad y estn X clasificados en funcionales y no funcionales. La especificacin del sistema incluye los requisitos no funcionales: de seguridad, rendimiento, X

disponibilidad, formacin. A1-C3: Se estructura el sistema de informacin en subsistemas de anlisis, para facilitar la especificacin de los distintos modelos y la traza de requisitos. X La desintegracin de los subsistemas est orientada a los procesos del sistema. Se han asignado los requisitos a cada uno de los subsistemas identificados, y consecuentemente actualizado el catlogo de requisitos. A1-C4: Se debe realizar el modelo del sistema que sirva de base para el diseo. En el caso de anlisis estructurado, mediante la elaboracin y descripcin detallada del modelo de datos y de procesos. Y en el caso de un anlisis orientado a objetos a travs del modelo de clases y el de interaccin de objetos, mediante el anlisis de los casos de uso. X

81

Los modelos son correctos tcnicamente y se han realizado con la tcnica adecuada. Existe un diccionario de datos o repositorio, es correcto y se gestiona de forma de automatizada, respetndose todos los procedimientos de gestin de cambios.

A1-C5: Se deben especificar todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, dilogos, formatos de informes y formularios de entrada. Se han descrito con suficiente detalle las

interfaces: pantallas a travs de las cuales el usuario navegar por la aplicacin, incluyendo todos los campos significativos, mens, botones, etc.; as como informes y formularios asociados si existen. Si hay normas de diseo o estilo de pantallas, informes, formularios, etc. en el rea, se verificar que se respetan. La interfaz de usuario se ha aprobado por el grupo de usuarios y por el comit de direccin. A1-C6: Debe especificarse el plan de pruebas que el nuevo sistema debe superar para ser aceptado. Se han definido los requisitos del entono de pruebas y el alcance de las pruebas. Se ha elaborado el plan de pruebas de aceptacin del sistema, ste es coherente con el catlogo de requisitos y con la especificacin funcional del sistema. X X X X

4.5.2. Objetivo de Control A2: Se debe garantizar la calidad de los distintos modelos generados en el proceso de anlisis del SI, y asegurar que los usuarios y los analistas tienen el mismo concepto del sistema. A2-C1: Se debe de verificar la calidad tcnica de cada modelo y asegurar la coherencia entre los distintos modelos. La calidad formal de los distintos modelos, comprobando si son conforme a la tcnica seguida X

82

para la elaboracin de cada producto y a las

normas determinadas en el catlogo normas. Se ha realizado una validacin de losde distintos X sistema de informacin, a travs del catlogo A2-C2: Debe realizarse una tanto validacin formal de la especificacin de requisitos y de los modelos del anlisis del sistema. de requisitos, mediante la traza de requisitos, como travs de la validacin directa del usuario. Los a usuarios ratifican que los requisitos especificados en el catlogo de requisitos, as como los casos de uso son validos, consistentes y completos. Cualquier peticin de cambio en los requisitos que pueda surgir posteriormente deben ser evaluada y aprobada. La actualizacin del plan de proyecto seguir los criterios, detallndose en este punto en mayor medida la entrega y transicin al nuevo sistema.
Tabla N 12. Auditoria de la fase de Anlisis del Proyecto Fuente: Elaboracin Propia.

modelos con los requisitos especificados para el

4.6.

AUDITORA DE LA FASE DE DISEO DEL PROYECTO.


AUDITORA DE LA FASE DE DISEO DEL PROYECTO

4.6.1. Objetivo de Control D1: Se debe definir una arquitectura del sistema que sea coherente con la especificacin funcional que se tenga y con el entorno tecnolgico. D1-C1: organizacin en subsistemas de diseo, la especificacin del entorno tecnolgico, requisitos de operacin, administracin, seguridad y control de acceso deben estar definidos de forma clara y ser conformes a los estndares y normas del centro de informacin y sistemas. Estn diferenciados y definidos los subsistemas especficos del sistema de informacin (en adelante, subsistemas especficos) y los subsistemas de soporte. Estn definidos todos los elementos que configuran el entorno tecnolgico (servidores, PC, perifricos, conexiones de red, sistemas gestores de bases de datos) junto con su planificacin de capacidades y sus requisitos de operacin, administracin, seguridad y control de acceso.

83

Existe un catlogo de excepciones, de requisitos, normas y estndares originados como consecuencia de la adopcin de una determinada solucin de arquitectura o infraestructura. Los elementos seleccionados estn dentro de los X estndares del rea y son capaces de responder a los requisitos establecidos de volmenes, tiempos de respuesta, seguridad.

D1-C2: Se debe realizar un diseo detallado de los subsistemas de soporte y del sistema de informacin especfico. Se han identificado los mecanismos genricos de diseo, as como las libreras y clases reutilizables. EI tamao de los mdulos o clases es adecuado y el factor de acoplamiento entre ellos es mnimo y la cohesin interna es mxima. Los mdulos o clases, se disean para poder ser reutilizados en el futuro por otros SI. D1-C3: Se debe disear la estructura de datos adaptando las especificaciones del sistema al entorno tecnolgico. EI modelo de datos tiene en cuenta el entorno tecnolgico y los requisitos de rendimiento para los volmenes y frecuencias de acceso estimados, migracin de datos. X X X X

4.9.1.2. Objetivo de Control D2: Se deben generar todas las especificaciones necesarias para la construccin del sistema de informacin: D2-C1: Se deben generar unas especificaciones de construccin. Se han fijado formalmente las directrices para la construccin de los componentes del sistema, as como de las estructuras de datos. D2-C2: Se debe especificar el procedimiento de migracin y carga inicial de datos as como los requisitos de operacin. Se definen los procedimientos de migracin y sus componentes asociados, con las especificaciones de construccin oportunas. X X

84

Se definen los requisitos relativos a la propia formacin del sistema en el entorno de operacin y aquellos relacionados con la documentacin que el usuario requiere para operar con el nuevo sistema. D2-C3: Debe realizarse la especificacin tcnica del plan de pruebas. Existe el plan de pruebas y contempla todos los recursos necesarios para llevarlas a efecto. Es adecuado para validar cada uno de los componentes del sistema, incluyendo pruebas de caja blanca. Tendrn en cuenta las posibles condiciones lgicas de ejecucin, adems de posibles fallos del hardware o software de base y ataques de seguridad. Permite validar la integracin de los distintos componentes y el sistema en conjunto. D2-C4: Se debe realizar una aprobacin formal del diseo del sistema. Se realiza la presentacin del diseo al comit de direccin y se registra la aprobacin del mismo. Se actualiza el plan de proyecto segn los criterios de direccin y se registra la aprobacin del mismo.
Tabla N 13. Auditoria de la fase de Diseo del Proyecto Fuente: Elaboracin Propia.

4.7.

AUDITORA DE LA FASE DE CONSTRUCCION DEL PROYECTO


AUDITORA DE LA FASE DE CONSTRUCCIN DEL PROYECTO

4.7.1. Objetivo de Control CS-1: Los componentes que se desarrollen deben utilizar tcnicas de programacin correctas CS1-C1: Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, as como los procedimientos de operacin y seguridad. Se han creado e inicializado las bases de datos o ficheros necesarios y cumplen las especificaciones de construccin del sistema obtenidas en la fase de diseo. Se han preparado los editores, compiladores, herramientas necesarias y estn disponibles los puestos de trabajo.

85

Se han preparado los procedimientos de copia de seguridad y restauracin. Estn disponibles todos los elementos lgicos y fsicos para realizar las pruebas unitarias y de X integracin. Estn documentados todos los procedimientos de operacin, seguridad y control de acceso al SI para cuando el sistema est en explotacin. Y estos procedimientos tienen en cuenta los estndares y normas del departamento de informtica, recogidos previamente en el catlogo de normas y estndares.

CS1-C2: Se debe programar, probar y documentar cada uno de los componentes identificados en el diseo del sistema. Se han desarrollado todos los componentes y se han seguido los estndares, normas de programacin y documentacin del rea (cdigo comentado y documentado). Se ha probado cada componente de forma unitaria siguiendo el plan de pruebas y se ha generado el informe de prueba. Se ha realizado la codificacin, prueba de los componentes y procedimientos de migracin y carga inicial de datos. CS1-C3: Deben realizarse las pruebas de integracin para verificar si los subsistemas interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos especificados en las verificaciones correspondientes. Se han llevado a cabo y realizado un informe segn lo especificado en el plan de pruebas. Se han evaluado las pruebas y se han tomado las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. CS1-C4: Deben realizarse las pruebas de sistema para comprobar la integracin del sistema de informacin globalmente. X X X X X

86

Las pruebas verifican el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica, as como el cumplimiento de la especificacin de requisitos, de acuerdo a las verificaciones establecidas en el plan de pruebas para el nivel de pruebas del sistema. Se ha generado un informe de pruebas de sistema y se han evaluado las pruebas y tomndose las acciones correctoras necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia. No han participado los usuarios, solo particip el equipo de desarrollo. 4.7.2. Objetivo de Control CS-2: Los proyectos de desarrollo deben definir los procedimientos y formacin necesarios para que los usuarios puedan utilizar el nuevo sistema adecuadamente. CS2-C1: El desarrollo de los componentes de usuarios debe estar planificado. En el plan de proyecto, est incluido el plan para el desarrollo de los procedimientos de usuario e incluye todas las actividades y recursos X X X X

necesarios. Los procedimientos se han realizado despus de la especificacin del SI y antes de su formacin. CS2-C2: Se deben especificar los perfiles de usuario requeridos para el nuevo sistema. Estn definidos los distintos perfiles de usuario requeridos para la formacin y explotacin del nuevo sistema. Para cada perfil se ha definido el rango de fechas y la dedicacin necesaria CS2-C3: Se deben desarrollar todos los procedimientos de usuario siguiendo los estndares del rea. X X X

87

Estn desarrollados todos los procedimientos de usuario, recopilados formando el manual de usuario, y son coherentes con las actividades descritas en la especificacin del sistema. Los manuales de usuario y el resto de X X

procedimientos cumplen los estndares del rea y llevan asociado su control de versiones.

Tabla N 14. Auditoria de la fase de Construccin del Proyecto Fuente: Elaboracin Propia.

4.8.

AUDITORA

DE

LA

FASE

DE

IMPLEMENTACION

ACEPTACION DEL PROYECTO


AUDITORA DE LA FASE DE IMPLANTACIN Y ACEPTACIN DEL PROYECTO 4.8.1. Objetivo de Control IA-1: El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en explotacin. IA1-C1: El plan de formacin y aceptacin se debe situacin final del proyecto. Se revisa el plan de formacin original y se documenta adecuadamente. Se establece un plan de formacin con la implantacin necesaria para el equipo de formacin, en funcin de los distintos perfiles y niveles de responsabilidad identificados y se cuenta con la infraestructura y recursos humanos para llevarla a cabo. Est incluida la instalacin de todos los componentes desarrollados, as como los elementos adicionales (formacin, libreras, utilidades). revisar para adaptarlo a la X

IA1-C2: Se deben realizar las pruebas de formacin y aceptacin del sistema que se especificaron en fases anteriores. Se prepara el entorno real de operacin y los X recursos necesarios para realizar las pruebas Las pruebas de formacin del sistema participan los usuarios y con ellas se verifica si el SI cumple las especificaciones funcionales as como detalles de diseo interno, como interacta correctamente con el entorno. Se han evaluado los resultados de las pruebas y se han tornado las acciones correctoras X X

necesarias para solventar las incidencias encontradas, actualizndose el proyecto en consecuencia.

88

IA1-C4: El sistema debe ser aprobado formalmente antes de ponerse en explotacin. Se ha realizado las pruebas de formacin y aceptacin. Se ha fijado el acuerdo de nivel de servicio. El grupo de usuarios y el comit de direccin firman su conformidad. X X X

4.8.2. Objetivo de Control IA-2: El sistema se pondr en explotacin formalmente y pasar a estar en mantenimiento slo cuando haya sido aceptado y est preparado todo el entorno el que se ejecutar. IA2-C1: Se deben instalar todos los procedimientos de explotacin. Se han instalado adems del sistema principal todos los procedimientos auxiliares, como copias, X X

recuperacin, etc., tanto manual como automtico. Estn documentados de forma correcta. Los usuarios finales han recibido la formacin necesaria y tienen en su poder toda la X documentacin necesaria, fundamentalmente

manuales de usuario. Se han eliminado procedimientos antiguos que sean incompatibles con el nuevo sistema. IA2-C2: Si existe un sistema antiguo, el sistema nuevo se pondr en explotacin de forma coordina con la retirada del antiguo, migrando los datos si es necesario. Hay un periodo de funcionamiento en paralelo de los dos sistemas, hasta que el nuevo sistema est funcionando con todas las garantas. Esta X X

situacin no debe prolongarse ms tiempo del necesario. Los datos se convierten de acuerdo al procedimiento desarrollado y se verifica la consistencia de la informacin entre el sistema nuevo y el antiguo. X

89

IA2-C4: Para terminar el proyecto se pondr en marcha el mecanismo de mantenimiento. EI mecanismo existe y est aprobado por el director de proyecto, por el comit de direccin y por el rea de desarrollo y mantenimiento. Tiene en cuenta los tiempos de respuesta X X

mximos que se pueden permitir ante situaciones de no funcionamiento. EI procedimiento a seguir ante cualquier problema o para el mantenimiento del sistema ser conocido por todos los usuarios.

Tabla N 15. Auditoria de la fase de Implantacin y Aceptacin del Proyecto Fuente: Elaboracin Propia.

4.9.

AUDITORA DE LA FASE DE MANTENIMIENTO DEL PROYECTO


AUDITORA DE LA FASE DE MANTENIMIENTO DEL PROYECTO

4.9.1. Objetivo de Control M-1: La gestin del proceso de mantenimiento de sistemas de informacin debe ser eficiente y eficaz para conseguir mantener el coste del mantenimiento de los SI del rea bajo control. M1-C1: Debe existir una estrategia y un plan para la gestin del mantenimiento de los SI del rea y de infraestructura tecnolgica. X El plan existe y est aprobado por la direccin del rea y se revisa peridicamente. X EI plan acordado es compatible con el proceso de gestin de cambios y de problemas. Existe un procedimiento definido y acordado por todas las reas participantes en el plan de mantenimiento a fin de facilitar que la gestin de los cambios o ejecucin de las peticiones de X mantenimiento as como gestin de los problemas de los SI se haga de una manera eficaz y eficientemente. 4.9.2. Objetivo de Control M-2: Todos los cambios, ya sean incidentes, problemas o peticiones de mantenimiento, incluido el mantenimiento correctivo de emergencia o cambios relacionados con la infraestructura tecnol6gica del entorno de produccin, deben de ser gestionados formalmente y de una manera controlada a fin de asegurar la mitigacin del riesgo debido a los impactos negativos en la estabilidad e integridad del SI en produccin.

90

M2-C1: Se debe establecer un sistema estandarizado de registro de informacin para las peticiones de mantenimiento, con el fin de controlar y canalizar los cambios propuestos por un usuario, mejorando el flujo de trabajo y proporcionando una gestin efectiva del mantenimiento. Existe un catlogo de problemas y de peticiones de mantenimiento sobre los sistemas de X informacin. Todas las peticiones de mantenimiento son X

presentadas de una forma estandarizada, para permitir su clasificacin y facilitar la identificacin del tipo de mantenimiento requerido. En cada peticin de cambio se recoge al menos la identificacin, origen y tipo de peticin, se le asigna una prioridad inicial y se le incorpora una descripcin, lo ms precisa posible, que facilite su posterior anlisis. Para cada peticin de mantenimiento aceptada se determina de quien es la responsabilidad de atender la solicitud para proceder a su estudio posterior, es decir, se le asigna un responsable de X

mantenimiento. M2-C2: Se debe llevar a cabo un diagnstico y anlisis del cambio para dar respuesta a las peticiones de mantenimiento que son aceptadas. La informacin registrada es la correcta. Si se trata de una peticin de mantenimiento correctivo, se evala hasta qu punto es crtico el problema. Si el problema es crtico, su anlisis y solucin comienza inmediatamente con el fin de reanudar rpidamente el nivel de servicio. Y el procedimiento de actuacin establecido no exime de una revisin posterior del problema para valorar los posibles efectos secundarios, establecer una X X

solucin definitiva y actualizar todos los productos implicados y su documentacin.

91

M2-C3: Se realiza el seguimiento de los cambios que se estn llevando a cabo en los procesos de desarrollo, de acuerdo a los puntos de control del ciclo de vida del cambio establecidos previamente. Slo se han modificado los elementos que se ven afectados por el cambio y que se han realizado las pruebas correspondientes, especialmente las X

pruebas de integracin y del sistema. Se realiza un informe de la evaluacin del cambio para su posterior aprobacin. Se realizan las pruebas en la de regresin que X

especificadas

actividad

anterior, X

comprobando que ningn sistema no modificado, pero con posibilidades de verse afectado, ha variado su comportamiento habitual. La aprobacin de la peticin se realiza al finalizar las pruebas de regresin, y despus de comprobar que todo lo que ha sido modificado o puede verse afectado por el cambio, funciona correctamente.

Tabla N 16. Auditoria de la fase de Mantenimiento del Proyecto Fuente: Elaboracin Propia.

92

CAPITULO V ANALISIS DE RESULTADOS

5.2.

RESULTADOS Y DISCUSIN A. Pregunta N 01

La Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI ha sido auditada con anterioridad (cualquier tipo de auditoria)?

100%

Si

No

No Sabe /No Opina

Grfico N 01: Auditorias anteriores. Fuente: Elaboracin Propia.

En el grfico N01, muestra que La Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin - ORDITI, del Gobierno Regional de Junn, entre las fechas comprendidas de Enero de 2012 a Julio de 2013, no ha sido auditado. Ello significa que no tienen control interno, como garanta para una gestin eficaz orientada a la consecucin de los objetivos.

93

B. Pregunta N 02

Existe algn documento que establece en forma clara las funciones del rea?
0%

100%

Si

No

No Sabe /No Opina

Grfico N 02: Documentacin de Funciones. Fuente: Elaboracin Propia.

En el grfico N02 muestra que existe, este documento es el ROF (Reglamento de Organizacin y Funciones) el cual se constituye en un documento tcnico normativo de gestin institucional que establece entre otras: Las funciones generales y especficas de la entidad y de cada uno de sus rganos y unidades orgnicas. Las funciones de La Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin ORDITI estn contemplados en el Artculo 55 del ROF del Gobierno Regional de Junn.

C. Pregunta N 03

Existe un organigrama con la estructura de organizacion del rea?

100%

Si

No

No Sabe /No Opina

Grfico N 03: Organigrama. Fuente: Elaboracin Propia.

94

En el grfico N03, muestra que existe una Estructura Orgnica del Gobierno Regional de Junn, aprobado con Ordenanza Regional N 1302011-GRJ/CR, derogando las ordenanzas regionales N 095 y 099-2009GRJ/CR, se demuestra constantes niveles de jerarqua y la relacin entre ellos, Cabe mencionar que la ORDITI existe como unidad funcional que depende de la Gerencia General Regional.

D. Pregunta N 04

Cada puesto de trabajo describe roles, responsabilidades, funciones, dependencia jerarquica, requisitos minimos de formacin y experiencia?
29%
71%

Si

No

No Sabe /No Opina

Grfico N 04: Puesto de Trabajo. Fuente: Elaboracin Propia.

En el grfico N04, muestra que solo el 71% tiene conocimiento que cada puesto de trabajo describe: roles, responsabilidades, funciones, dependencia jerrquica, requisitos mnimos de formacin y experiencia, El 229% no tiene conocimiento acerca de los puestos de trabajo del rea. El documento que presenta la descripcin de puestos es el ROF (Reglamento de Organizaciones y Funciones). Las funciones de la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin ORDITI estn contemplados en el Articulo 55 del ROF del Gobierno Regional de Junn.

95

E. Pregunta N 05

Estan establecidos los procedimientos de promocion de personal a puestos superiores, teniendo en cuenta la experiencia y formacin?
20%

80%

Si

No

No Sabe /No Opina

Grfico N 05: Promocin de Staff a puestos superiores. Fuente: Elaboracin Propia.

En el grfico N05, seala que el 80% dice que no est establecido el procedimiento de promocin de staff; en cambio el 20% afirma que existe dicho procedimiento. El Gobierno Regional cada vez que requiere de staff procede a convocatoria o concurso pblico, en el cual establece objetivos y bases legales (Decretos Supremos) sealando requisitos mnimos, funciones a desempear segn el servicio o cargo a ocupar, periodo de contratacin (con opcin a renovacin pero no indica promocin de staff a puestos superiores.

F. Pregunta N 06

El personal seleccionado cumple con los requisitos del puesto al que acceden?
14% 14%

72%

Si

No

No Sabe /No Opina

Grfico N 06: Staff cumple con los requisitos al puesto que accede. Fuente: Elaboracin Propia.

96

En el grfico N06, nos seala que existe un 72% que afirma que el Staff seleccionado cumple con los requisitos del puesto, por el contrario el 14% niega dicha afirmacin, y el 14% no sabe no opina. El Gobierno Regional de Junn cuando requiere staff, procede a convocatoria o concurso pblico, sealando requisitos mnimos, en que el postulante debe cumplir.

G. Pregunta N 07

El personal de rea cuenta con la formacin adecuada y son motivados para la realizacin de su trabajo?
0% 0%

100%

Si

No

No Sabe /No Opina

Grfico N 07: Formacin y motivacin del Staff. Fuente: Elaboracin Propia.

En el grfico N07, nos muestra que todo el staff del rea cuenta con la formacin necesaria y adems son motivados para la realizacin de su trabajo. Esta motivacin la realiza el Director de la ORDITI enfatizando las cualidades del staff.

H. Pregunta N 08

Exite algn mecanismo que permita al personal hacer sugerencias sobre mejoras en la organizacin del rea?
0% 40% 60%

Si

No

No Sabe /No Opina

Grfico N 08: Sugerencias del Staff. Fuente: Elaboracin Propia.

97

En el grfico N08, muestra que solo el 60% afirma que existe un mecanismo que permite a los miembros del staff hacer sugerencias para la mejora del rea. Sin embargo existe un 40% que niega dicha afirmacin. El Director de la ORDITI confirm que hacen reuniones peridicas en las cuales los miembros del staff realizan sugerencias para la mejora del rea, las cuales se toman en cuenta.

I. Pregunta N 09

Exite algn documento de aprobacin del proyecto informtico autorizado por la alta gerencia?
0%
14%

86%

Si

No

No Sabe /No Opina

Grfico N 09: Aprobacin del Proyecto. Fuente: Elaboracin Propia.

En el grfico N09, el 86% seala que no existe documento de aprobacin de proyecto autorizado por la alta gerencia, en cambio el 14% afirma que si existe dicho documento. El Gobierno Regional de Junn emite resolucin Ejecutiva Regional y basndose en el Plan Operativo Informtico detallando lo siguiente: Ficha tcnica para la programacin e Actividades y Proyectos Informticos, el cual describe los objetivos, costo total, duracin, unidad ejecutora del proyecto.

98

J. Pregunta N 10

Se tiene implantada una metodologa de desarrollo de sistemas de informacin soportada por herramientas de ayuda?

40% 60%

Si

No

No Sabe /No Opina

Grfico N 10: Metodologa de Desarrollo de Sistemas de Informacin. Fuente: Elaboracin Propia.

En el grfico N10, seala que el 60% afirma que se establece una metodolgica de desarrollo de sistemas de informacin soportado por herramientas de ayuda. Por el contrario el 40% niega dicha informacin. En la documentacin proporcionada revisada, no se tiene una metodologa de desarrollo de sistemas de informacin documentada.

K. Pregunta N 11

La metodologa cubre todas las fases del desarrollo y es adaptable a distintos tipos de proyectos?
0%

100%

Si

No

No Sabe /No Opina

Grfico N 11: Metodologa cubre las fases y es adaptable. Fuente: Elaboracin Propia.

En el grfico N11, indica que la metodologa de desarrollo de sistemas de informacin cubre todas las fases de desarrollo. Es adaptable a los distintos tipos de proyectos de software. En la documentacin
99

proporcionada y revisada, no se tiene una metodologa de desarrollo de sistemas de informacin documentada.

L. Pregunta N 12

Se ha asignado un responsable o director de proyecto?


14% 14%

72%

Si

No

No Sabe /No Opina

Grfico N 12: Asignacin de responsables del proyecto. Fuente: Elaboracin Propia.

En el grfico N12, indica que el 72% conoce la asignacin de un responsable o director de proyecto informtico. Por el contrario el 14% no conoce la designacin del responsable del proyecto. En tanto el 14% no sabe no opina. Cada proyecto informtico de la ORDITI es asignado a un responsable, el cual lo dirige siguiendo lo establecido en el Plan Operativo Informtico.

M. Pregunta N 13

Se ha descrito y dimensionado el proyecto; evaluando riesgos y ciclo de vida del proyecto?


20%

20%

60%

Si

No

No Sabe /No Opina

Grfico N 13: Dimensin del proyecto. Fuente: Elaboracin Propia.

100

En el grfico N13, muestra que el 43% que no sabe y no opina y que el 43% desconoce las dimensiones, riesgos y ciclo de vida del proyecto; indican la gran falta de informacin acerca del proyecto por parte del staff de la ORDITI. Solo el 14% conoce que se ha descrito y dimensionado el proyecto, evaluando riesgos y el ciclo de vida que se tomar en cada proyecto.

N. Pregunta N 14

Existe un registro de problemas que se producen en los proyectos de desarrollo de sistemas?


0% 29%

71%

Si

No

No Sabe /No Opina

Grfico N 14: Registro de problemas. Fuente: Elaboracin Propia.

En el grfico N14 muestra que el 71% no lleva registro de problemas que se producen en los proyectos de desarrollo de sistemas. Por el contrario el 29% afirma que si existe un registro del mismo. De la documentacin revisada no existe un registro de los incidentes, problemas y soluciones que se producen en el desarrollo de sistemas.

101

O. Pregunta N 15

Se ha hecho uso de la informacin historica que se dispone tanto para dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de vida?
0%

100%

Si

No

No Sabe /No Opina

Grfico N 15: Informacin Histrica. Fuente: Elaboracin Propia.

En el grfico N15 muestra que al 100% se ha hecho uso de la informacin histrica existente, para dimensionar el proyecto, riesgos y el ciclo de vida segn el proyecto.

P. Pregunta N 16

Se ha constituido formalmente al equipo de trabajo, as como los responsables de las reas inmersas en el proyecto?
20%
20% 60%

Si

No

No Sabe /No Opina

Grfico N 16: Equipos de trabajo y responsables de las reas. Fuente: Elaboracin Propia.

En el grfico N16 indica que el 86% se constituye formalmente al equipo de trabajo, adems de los responsables de las reas donde se ve inmerso el proyecto. En cambio el 14% no sabe no opina. La integracin del staff y de los responsables d las reas donde se implantar el nuevo software, se constituye de manera verbal, mas no documentado.
102

Q. Pregunta N 17

Se realizan reuniones con una frecuencia mnima y las decisiones tomadas quedan documentadas?
0% 14%

86%

Si

No

No Sabe /No Opina

Grfico N 17: Reuniones del equipo de trabajo. Fuente: Elaboracin Propia.

En el grfico N17 seala que el 86% si realiza reuniones peridicas y las decisiones de aquellas reuniones son documentadas. En cambio el 14% niega dicho enunciado. Las reuniones de staff si se hace con frecuencia mnima (cada 7 das), pero las decisiones tomadas no quedan documentadas, solo se las menciona.

R. Pregunta N 18

La documentacin del proyecto es completa y est catalogada para accesos posteriores?


14%

86%

Si

No

No Sabe /No Opina

Grfico N 18: Documentacin del Proyecto. Fuente: Elaboracin Propia.

En el grfico N18 muestra un 86% que existe documentacin del proyecto, es completo y est catalogada. En cambio existe un 14% que no sabe no opina. De la informacin revisada y analizada se puede afirmar
103

que la documentacin es completa, pero no est catalogada para accesos posteriores.

S. Pregunta N 19

Existe un documento que recoge la descripcin general de requisitos establecidos por el usuario?
0% 29%

71%

Si

No

No Sabe /No Opina

Grfico N 19: Documentacin de requisitos. Fuente: Elaboracin Propia.

En el grfico N19 indica un 71% que existe un documento que recoge los requisitos del usuario. Pero existe un 29% que niega dicho enunciado. De la toma de requisitos se puede afirmar que se realiza la documentacin necesaria.

T. Pregunta N 20

Existe un protocolo para solicitar al resto de las reas la participacin del personal en el proyecto y se aplica dicho protocolo?
20% 20%

60%

Si

No

No Sabe /No Opina

Grfico N 20: Solicitud de participacin de personal de otras reas. Fuente: Elaboracin Propia.

104

En el grfico N20 muestra que el 20% que no sabe y no opina y el 60% que desconoce la existencia de un protocolo de solicitud de participacin de personal de otras reas inmersas en el proyecto. En cambio el 20% afirma dicho enunciado. La participacin del personal de otras reas incluidas en el proyecto se hace de manera verbal, mas no existe un protocolo especfico.

U. Pregunta N 21

La realizacin de nuevos proyectos de software se basa en el Plan Operativo Informtico?

40%

40%

20%

Si

No

No Sabe /No Opina

Grfico N 21: Nuevos proyectos de software. Fuente: Elaboracin Propia.

En el grfico N21 muestra que entre el 40% que no sabe y no opina y el 20% que desconoce si los proyectos se basan en el POI; podemos afirmar junto con el 40% que la realizacin de nuevos proyectos de software se basa ntegramente al Plan Operativo Informtico.

105

V. Pregunta N 22

Las fechas de realizacin del proyecto coinciden con los del Plan OperativoInformtico?
20% 20% 60%

Si

No

No Sabe /No Opina

Grfico N 22: Fechas de realizacin del proyecto. Fuente: Elaboracin Propia.

En el grfico N22 indica que entre el 20% que no sabe no opina y el 20% que tiene desconocimiento acerca de las fechas de realizacin de proyectos inmersos en el POI. Se puede afirmar junto con el 60% que las fechas de realizacin coinciden con el POI, pues este dispone de fechas a corto plazo.

W. Pregunta N 23

La recopilacin de informacin es la adecuada en funcin de las caracteristicas del proyecto y a los tipos de usuario a entrevistar?
0% 14%

86%

Si

No

No Sabe /No Opina

Grfico N 23: Recopilacin de Informacin. Fuente: Elaboracin Propia.

En el grfico N23 seala que el 86% afirma que la recopilacin de la informacin es la adecuada. Por el contrario el 14% niega dicho enunciado. La recopilacin de la informacin se realiza de manera
106

adecuada con las caractersticas del proyecto y los usuarios a entrevistar.

X. Pregunta N 24

Se realizan varios tipos de mtricas para poder estimar la calidad del software?
0%

40% 60%

Si

No

No Sabe /No Opina

Grfico N 24: Mtricas. Fuente: Elaboracin Propia.

En el grfico N24 indica que existe un 60% que no realiza mtricas para estimar la calidad del software. Por el contrario existe un 40% que afirma dicho enunciado. No realizan ninguna mtrica para estimar la calidad del software.

Y. Pregunta N 25

Se definen practicas de anlisis y diseo. Adems existe una gua de practivas para cada lenguaje de programacin?
0% 40% 60%

Si

No

No Sabe /No Opina

Grfico N 25: Guas de prcticas de anlisis y diseo. Fuente: Elaboracin Propia.

107

En el grfico N25 indica que el 40% afirma que se definen prcticas de anlisis y diseo, adems existe una gua para cada lenguaje de programacin. Por el contrario, existe un 60% que niega dicho enunciado. Las prcticas de anlisis y diseo se realizan de manera emprica adems no existe una gua de prcticas para cada lenguaje de programacin.

Z. Pregunta N 26

Se han realizado modelos del sistema?


14% 43%

43%

Si

No

No Sabe /No Opina

Grfico N 26: Modelo del Sistema. Fuente: Elaboracin Propia.

En el grfico N26 indica al 100% que se realizan modelos del sistema.

AA. Pregunta N 27

La division de los subsistemas estn orientados a los procesos de la organizacin?


14% 14%

72%

Si

No

No Sabe /No Opina

Grfico N 27: Divisin de subsistemas. Fuente: Elaboracin Propia.

108

En el grfico N27 muestra que el 72% afirma que la divisin de los subsistemas est orientado a los procesos de la organizacin. El 14% niega lo expuesto. Y por ltimo el 14% no sabe no opina. La subdivisin de los subsistemas se hace a travs de Mdulos: Mdulo de Administracin Documentaria (MAD) y Mdulo de Administracin Organizacional (MAO).

BB. Pregunta N 28

Se detallan las interfaces: pantallas a travs de las cuales el usuario navegar por la aplicacin, mens, botones y formularios asociados?
0% 0%

100%

Si

No

No Sabe /No Opina

Grfico N 28: Interfaces. Fuente: Elaboracin Propia.

En el grfico N28 indica que el 100% afirma que se detallan las interfaces del sistema.

CC. Pregunta N 29

Existen normas de diseo o estilo de pantallas, informes y formularios?


14% 14%

72%

Si

No

No Sabe /No Opina

Grfico N 29: Normas de Diseo. Fuente: Elaboracin Propia.

109

En el grfico N29 muestra que el 72% afirma que existen normas de diseo. El 14% niega lo expuesto. Y por ltimo el 14% no sabe no opina.

DD. Pregunta N 30

Deben especificarse un plan de pruebas definiendo requisitos de alcance y entorno?


14% 43%

43%

Si

No

No Sabe /No Opina

Grfico N 30: Plan de pruebas. Fuente: Elaboracin Propia.

En el grfico N30 seala que existe un 43% que afirma que se especifica un plan de pruebas, por el contrario el 43% niega lo expuesto. Y el 14% no sabe no opina.

EE.

Pregunta N 31

Se ha elaborado un plan de pruebas de aceptacin del sistema; es coherente con los requisitos y con la especificacin funcional del sistema?
0%
43% 57%

Si

No

No Sabe /No Opina

Grfico N 31: Aceptacin del sistema. Fuente: Elaboracin Propia.

110

En el grfico N31 muestra que el 43% afirma que se elabora un plan de pruebas de aceptacin del sistema, por el contrario el 57% niega dicho enunciado.

FF.

Pregunta N 32

Se ha realizado una validacin formal de la especificacin de requisitos y de los modelos del anlisis del sistema?
0% 29%

71%

Si

No

No Sabe /No Opina

Grfico N 32: Validacin de la especificacin. Fuente: Elaboracin Propia.

En el grfico N32 seala que el 71% afirma que se realizan validacin formal de la especificacin de requisitos y modelos del anlisis del sistema. Por el contrario el 29% niega dicho enunciado. La validacin se realiza pero no de manera documentada.

GG. Pregunta N 33

Se ha definido una arquitectura del sistema que sea coherente con la especificacin funcional y con el entorno tecnolgico?
0% 14%

86%

Si

No

No Sabe /No Opina

Grfico N 33: Arquitectura del Sistema. Fuente: Elaboracin Propia.

111

En el grfico N33 indica que el 86% afirma que se define la arquitectura del sistema, es coherente con la especificacin funcional y con el entorno tecnolgico. Por el contrario el 14% dice que no a la pregunta.

HH. Pregunta N 34

Se especifca el procedimiento de migracin y carga inicial de datos as como los requisitos de operacin?
14% 43% 43%

Si

No

No Sabe /No Opina

Grfico N 34: Migracin y carga inicial de datos. Fuente: Elaboracin Propia.

En el grfico N34 muestra que el 43% afirma que se especifica el procedimiento de migracin y carga inicial de datos, as como los requisitos de operacin. En cambio el 43% niega el enunciado. Y por ltimo el 14% no sabe no opina.

II. Pregunta N 35

Se prepara adecuadamente el entorno de desarrollo y de pruebas, as como los procedimientos de operacin y seguridad?
14% 14% 72%

Si

No

No Sabe /No Opina

Grfico N 35: Entorno de Desarrollo y Pruebas. Fuente: Elaboracin Propia.

112

En el grfico N35 indica que el 72% prepara adecuadamente el entorno de desarrollo y pruebas, procedimientos de operacin y seguridad. Sin embargo el 14% dice que no preparan el entorno y otro 14% no sabe no opina.

JJ.

Pregunta N 36

Existe un repositorio con todos los productos software susceptibles de ser reutilizados: Librerias de funciones, clases de objetos, componente de software, documentos (catlogo de requisitos comunes, arquitecturas?
0% 20% 80%

Si

No

No Sabe /No Opina

Grfico N 36: Repositorio de productos de software. Fuente: Elaboracin Propia.

En el grfico N36 indica un 80% que existe un repositorio con todos lo productos software que pueden ser reutilizados. Por el contrario el 20% niega dicha existencia.

KK. Pregunta N 37

Los componentes que se desarrollan utilizan tcnicas de programacin correctas?


0% 0%

100%

Si

No

No Sabe /No Opina

Grfico N 37: Tcnicas de programacin. Fuente: Elaboracin Propia.

113

En el grfico N37 indica que el 100% de los componentes se desarrollan utilizando tcnicas de programacin correctas.

LL.

Pregunta N 38

Se programa, prueba y documenta cada uno de los componentes identificados en el diseo del sistema?
14% 29% 57%

Si

No

No Sabe /No Opina

Grfico N 38: Programar, probar y documentar componentes. Fuente: Elaboracin Propia.

En el grfico N38 indica que el 57% si se programa, prueba y documenta todos los componentes identificados en el diseo del sistema. En cambio existe un 29% que niega dicho enunciado. Y por ltimo el 14% no sabe no opina.

MM. Pregunta N 39

Se programa todos los componentes, siguiendo estndares y normas de programacin y documentacin (cdigo comentado y documentado?
0% 43% 57%

Si

No

No Sabe /No Opina

Grfico N 39: Estndares y normas de programacin. Fuente: Elaboracin Propia.

114

En el grfico N39 indica que el 57% afirma que se programan todos los componentes siguiendo estndares y normas de programacin, as como tambin de documentacin. Pero el 43% dice que no a la pregunta. Se programa con estndares de programacin pero no se documenta.

NN. Pregunta N 40

Se prueba cada componente de forma unitaria siguiendo el plan de pruebas. Si se detecta un fallo de especificacin o diseo, el proyecto se actualizar segn el procedimiento establecido para ello?
14% 29% 57%

Si

No

No Sabe /No Opina

Grfico N 40: Prueba de cada componente. Fuente: Elaboracin Propia.

En el grfico N40 indica un 57% afirmando que se prueba cada componente de forma unitaria siguiendo el plan de prueba. Si se detecta un fallo de especificacin o diseo, el proyecto se actualizar segn procedimiento establecido. Por el contrario el 29% niega dicho enunciado. Y por ltimo un 14% que no sabe no opina.

OO. Pregunta N 41

Se realiza codificacin, prueba de los componentes y procedimientos de migracin y carga inicial de datos?
14% 29%

57%

Si

No

No Sabe /No Opina

Grfico N 41: Procedimientos de migracin y carga inicial de datos. Fuente: Elaboracin Propia.

115

En el grfico N41 indica que entre el 14% que no sabe y no opina y el 29% que dice que no se realiza codificacin ni pruebas ni mucho menos migracin y carga inicial de datos. Por el contrario el 29% afirma dicha interrogante. Si se realiza la codificacin, prueba de componentes y se realiza procedimientos de migracin y carga inicial de datos al nuevo sistema.

PP.

Pregunta N 42

El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en ejecucin total?

100%

Si

No

No Sabe /No Opina

Grfico N 42: Aceptacin formal del sistema. Fuente: Elaboracin Propia.

En el grfico N42 indica al 100% la aceptacin de los nuevos sistemas por parte de los usuarios. Pero dicha aceptacin no es documentada.

QQ. Pregunta N 43

Existe un plan de formacin y aceptacin?


14%

86%

Si

No

No Sabe /No Opina

Grfico N 43: Plan de formacin y aceptacin. Fuente: Elaboracin Propia.

116

En el grfico N43 indica que el 86% niega que exista un plan de formacin y aceptacin del nuevo sistema, por el contrario el 14% afirma dicha pregunta.

RR. Pregunta N 44

Los usuarios reciben capacitacin necesaria y tien toda la documentacin, fundamentalmente manuales de usuario?
0%

100%

Si

No

No Sabe /No Opina

Grfico N 44: Capacitacin a usuarios. Fuente: Elaboracin Propia.

En el grfico N44 indica que el 100% afirma que se capacita a los usuarios y se les proporciona manual de usuarios.

SS.

Pregunta N 45

Existe un procedimiento de mantenimiento a fin de facilitar la gestin de cambios?

43%

57%

Si

No

No Sabe /No Opina

Grfico N 45: Procedimientos de mantenimiento. Fuente: Elaboracin Propia.

117

En el grfico N45 indica que el 57% afirma que el procedimiento de mantenimiento se realiza a fin de facilitar la gestin de cambios. En cambio el 43% niega dicha existencia.

TT.

Pregunta N 46

Se revisa peridicamente el nivel de servicio para monitorizar su grado de cumplimiento?


14%

29%

57%

Si

No

No Sabe /No Opina

Grfico N 46: Monitorear nivel de servicio. Fuente: Elaboracin Propia.

En el grfico N46 seala entre el 57% que dice no a la pregunta y el 29% que no sabe no opina; se tiene un gran desconocimiento acerca del monitoreo del servicio. Por el contrario slo el 14% afirma que se revisa peridicamente el nivel de servicio para monitorizar el grado de cumplimiento.

UU. Pregunta N 47

Las peticiones de mantenimiento se presentan en forma estndar, para permitir su clasificacin y facilitar la identificacin del tipo de mantenimiento requerido?
12% 38% 50%

Si

No

No Sabe /No Opina

Grfico N 47: Peticiones de mantenimiento. Fuente: Elaboracin Propia.

118

En el grfico N47 entre el 50% que dice no a la pregunta y el 38% que no sabe no opina; se tiene un gran desconocimiento acerca de las peticiones de mantenimiento. Por el contrario slo el 12% afirma que las peticiones de mantenimiento se presentan de forma que permiten su clasificacin e identificacin del tipo de mantenimiento.

5.3.

HALLAZGOS DE LA AUDITORIA:
A continuacin se enumera los principales hallazgos despus de haber aplicado la Auditoria del desarrollo de sistemas de informacin:

5.3.1. Hallazgos de Auditoria de la Organizacin y Gestin de

Sistemas No existen responsabilidades y roles correctamente establecidos, formalizados, documentados. Adems no son ejecutados por personal con la suficiente formacin y experiencia en la materia. No estn disponibles un nmero suficiente de libros, publicaciones, monografas de reconocido prestigio, ya sea en formato electrnico o papel. Casi todo el personal no tiene acceso a ellos. No existe una gran rotacin de personal. El Plan Estratgico se revisa pero No se actualiza peridicamente en funcin de las nuevas situaciones. La documentacin relativa a cada proyecto que existen en el Plan estratgico no se pone a disposicin del director de proyecto una vez comenzado el mismo. No existe un catlogo de problemas. Existe Plan de calidad, pero no existen ni se ejecutan actividades de mejora continua. No se realizan informe ejecutivos peridicamente sobre la calidad de los sistemas de informacin. No estn definidas mtricas de calidad. No existe repositorio o catlogo. No existen actividades de mejora continua segn los estndares de calidad. No existe un diccionario de datos institucional con al reglas de
119

sintaxis de la organizacin.

5.3.2. Hallazgos de Auditoria de la Gestin y Planificacin del

proyecto No existe el mnimo de reuniones peridicas. No existen hojas de registro de problemas y no existe alguna persona del proyecto encargada de su recepcin. No existe mtodo para catalogar y dar probidad a los problemas. No existe un mecanismo para registrar los cambios que pudieran producirse. No se respetan los lmites temporales y presupuestarios marcados al inicio del proyecto. No se notifica el cambio a todas las personas que participen en el proyecto y se ven afectados. La documentacin no cumple los estndares y procedimientos establecidos en el rea. La documentacin del proyecto no es completa y tampoco est catalogada perfectamente para accesos posteriores.
5.3.3. Hallazgos de Auditoria de la Fase de Estudio de Viabilidad

No se ha realizado un plan detallado de entrevistas con el grupo de usuarios.

5.3.4. Hallazgos de Auditoria de la Fase de Anlisis

No se remite el guion a los entrevistados con tiempo suficiente para que estos puedan preparar la entrevista y la documentacin que deseen aportar a la misma.

No existe un catlogo de requisitos. La interfaz de usuario no se ha aprobado por el grupo de usuarios.

5.3.5. Hallazgos de Auditoria de la Fase de Diseo

No existe catlogo de excepciones, de requisitos, normas y estndares.

120

No se actualiza el plan de proyecto segn os criterios de direccin y se registra la aprobacin del mismo.

5.3.6. Hallazgos de Auditoria de la Fase de Construccin

No se han preparado los procedimientos de copia de seguridad y restauracin. No se documentan todos los procedimientos de operacin, seguridad y control de acceso al SI para cuando el sistema est en explotacin.

No se generan informes de pruebas del sistema y no se han evaluado las pruebas.

5.3.7. Hallazgos de Auditoria de la Fase de Implantacin y

Aceptacin No existe un periodo de funcionamiento en paralelo de los dos sistemas, hasta que el nuevos sistema este funcionado con todas las garantas. No existe mecanismo de mantenimiento aprobado por el director de proyecto.

5.3.8. Hallazgos de Auditoria de la Fase de Mantenimiento

No existe un plan para la gestin del mantenimiento de los sistemas de informacin. No existe un catlogo de problemas ni de peticiones de mantenimiento sobre los sistemas de informacin. No se realizan peticione de cambios y/o mantenimiento. No se realizan informes de la evaluacin del cambio para su posterior aprobacin.

121

5.3.9. Aplicativos informticos que administra el Gobierno Regional

de Junn DENOMINACION Sistema de Aplicaciones Regionales DESCRIPCION Sistema Integrado para la administracin de datos de las diferentes reas y sectores del Gobierno Regional; siendo estas: personal, planillas, vistas, inventario informtico. Sistema de Abastecimiento Sistema de Gestin Documentaria
Tabla N 17. Aplicativos Informticos del Gobierno Regional de Junn. Fuente: Elaboracin Propia.

Para el control de requerimientos, rdenes de compra, servicios, pecosas y almacn. Para el registro, control y seguimiento de la documentacin a nivel regional.

5.3.10. Documentacin de los Aplicativos

Manual de Usuario:

Si (Desactualizado), el Modulo de Planillas del Sistema SAR no cuenta con manual de usuarios.

Manual Tcnico: Diccionario de Datos:

No S, pero solo actualizado al 2010.

5.3.11. Observaciones

Ausencia de una metodologa en el desarrollo de sistemas de informacin. Ausencia de copias de seguridad o respaldo (backup) de la informacin esencial de la entidad y de los aplicativos que pondran en riegos la integridad de la informacin.

La gestin de cambio en los sistemas informativos no se encuentra documentada, lo cual no permite el control y seguimiento de las actualizaciones y podra afectar la continuidad de las operaciones de la entidad.

Los requerimientos en mencin se realizan verbalmente a travs


122

de correo electrnico, denotndose la ausencia de documentos que permitan rastrear las modificaciones. Datos duplicados, inconsistentes, incompletos o pruebas en la base de datos de produccin del Sistema de Aplicaciones Regionales, esto limita el uso y explotacin y afecta directamente la confiablidad de la informacin. Se constat la presencia de datos inconsistentes, incompletos o de pruebas tal como se muestra:

Figura N 14. Datos Inconsistentes en una base de datos. Fuente: Gobierno Regional de Junn.

No se realiza control de versiones de los cdigos fuentes, ejecutables de los sistemas informticos, lo cual no permite identificar los cambios o actualizaciones correspondientes a cada versin del sistema software.

Desactualizacin y, en algunos casos, ausencia de documentos que orienten y uniformicen los procesos de mantenimiento, administracin y uso de los aplicativos.

Esto dificulta la comprensin y uso de la informacin, generando riesgos de errores y omisiones.

5.4.

DISEO DE CONTRASTACIN:
La verificacin fue lgica, pues es la prueba de coherencia de los enunciados segn la literatura consultada. Se utilizar Investigacin Ex post-facto, la cual es el estudio de los fenmenos que ya se han

123

producido. La poblacin de estudio est constituida por 7 miembros del staff del rea de sistemas. La muestra est representada por los 7 empleados. Por lo tanto, se ha determinado que el tamao de la muestra para la presente investigacin es de 7 miembros del staff a quienes se aplic la encuesta de Auditoria de Sistemas de Informacin. (Vase Anexo N 01)

Formalizacin:

Identificacin de necesidades
Implantancin SGSI mediante controles fsicos, tcnicos y organizativos

Conocer el entorno

Definir la metodologa en La implantacin de los controles

X
Identificar procesos clave del negocio Desarrollo de anlisis de riesgos

Definir el alcance

Seleccionar objetivos y controles

M2

POST-TEST Sin grupo de control


ORDITI

Figura N 15. Diseo de Contrastacin Fuente: Elaboracin Propia.

124

Donde: X: M2: Aplicacin de la Auditoria del desarrollo de sistemas. Situacin problemtica despus de la aplicacin de la Auditoria del desarrollo de sistemas de informacin.

A travs de la aplicacin de la Auditoria se contrastara con la justificacin. Al finalizar la presente investigacin se analiza M2, para determinar la validez de la justificacin, con el planteamiento de las mejoras del desarrollo de sistemas de informacin. La solucin est referida una serie de recomendaciones que debe seguir el Gobierno Regional de Junn, siendo la principal el establecer una metodologa para el desarrollo de sistemas de informacin, El uso de una metodologa sera muy eficiente pues se estara desarrollando sistemas de informacin conforme a un estndar.

125

CONCLUSIONES
Del presente informe tcnico concluimos que: 1. No se cumple con los estndares y normas de control interno en el desarrollo de sistemas de informacin. 2. La metodologa evaluada en el desarrollo de sistemas de informacin no es la adecuada, pues se realiza de manera muy informal y emprica. 3. La identificacin de las fases de la metodologa no son las correctas. Fases importantes como la gestin de proyectos de software no son tomadas en cuenta. 4. No cumplen con normas de seguridad e integridad de datos, ni tampoco el control de cambios. 5. Falta de comunicacin entre el staff. 6. Falta de documentacin critica en casi todas las fases del proyecto software.

126

RECOMENDACIONES
Del presente informe tcnico recomendamos lo siguiente: 1. Adoptar e implantar estndares y normas de control a travs del uso de la Metodologa COBIT (Control Objectives for Information and Related Technologies), la cual proporciona en conjunto estructura de buenas prcticas y metodologas en lo que se refiere al gobierno de Tecnologas de comunicacin y Comunicaciones. 2. Establecer una metodologa para el desarrollo de sistemas de informacin como la metodologa de El Ciclo de Vida para desarrollo de sistemas, que es el conjunto de actividades que los analistas, diseadores y usuarios realizan para desarrollar e implantar un sistema de informacin; 3. Establecer e incluir las siguientes fases en el proyecto software: gestin de proyectos, viabilidad del proyecto, anlisis, diseo, programacin o construccin implantacin, aceptacin y

mantenimiento de software ya que cumpliran las fases de una metodologa estndar como el Ciclo de Vida para desarrollo de sistemas. 4. Implementar un Sistema de Gestin de la Seguridad de la Informacin (SGSI) bajo estndar internacional ISO/IEC 270001; para cumplir con lo establecido de las normativas ISO y Mtricas aplicadas sobre la gestin de seguridad de Tecnologas de Informacin. 5. Implementar una gestin de comunicacin interno en la Oficina Regional de Desarrollo Institucional y Tecnologa de la Informacin y dar continua capacitacin especializada en temas especficos de Desarrollo de Sistemas de Informacin a todo el staff.
127

6. Realizar regularmente copias de seguridad de la informacin esencial de la entidad, adems de manuales de usuario, biblioteca de datos y documentacin crtica de cada proyecto de software en concordancia con las polticas institucionales.

128

BIBLIOGRAFA
Tesis: Tesis N 01: CHVEZ GARCA, Gissela Karina. Auditora Informtica Aplicada al Sistema Integrado de Gestin Comercial, Comercializadora y Distribuidora Jimnez S.A. de la Empresa Distribuidora Codijisa- Trujillo. [Tesis para optar el Ttulo Profesional de Ingeniero de Sistemas]. Trujillo: Universidad Privada del Norte. 2004. Tesis N 02: VILLANUEVA SNCHEZ, Grover Eduardo. Sistema de Gestin Estratgica aplicando el Enfoque Sistmico y las Tecnologas de la Informacin para lograr Ventajas Competitivas en el Instituto Nacional de Cultura de La Libertad. [Tesis para optar el Ttulo Profesional de Licenciado en Administracin]. Trujillo. Universidad Csar Vallejo. 2008. Tesis N 03: XILOJ CHARUC, Francisco Dagoberto. Auditora Externa en un Ambiente de Sistemas de Informacin Computarizado en el rea de Ingresos de una Empresa Comercializadora de Vehculos. [Tesis para optar el Ttulo Profesional de Contador Pblico y Auditor]. Guatemala. 2008

Libros: Libro N 01: BURCH & GRUDNITSKI, Diseo de Sistemas de


129

Informacin Teora y Prctica, Editorial Limusa, 1996. Libro N 02: STAIR, Ralph M. Principios de SISTEMAS DE

INFORMACION Enfoque Administrativo, Internacional Thomson Editores S.A., 1999. Libro N 03: LAUDON, Kenneth C. & LAUDON, Jane P. Sistemas De Informacin Gerencial, Pearson Educacin S.A. de C.V., 2004. Libro N 04: FERNANDEZ ALARCON, Vicente. Desarrollo de Sistemas De Informacin Una metodologa basada en el modelado, Ediciones UPC., 2006. Libro N 05: MUOZ RAZO, Carlos. Auditora en Sistemas

Computacionales, Pearson Educacin de Mxico.

Libro N 06: PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL PESO RUZ, Mar. Auditora de Tecnologas y Sistemas de Informacin, Editorial Ra-Ma, 2008. Libro N 07: TAMAYO ALZATE, Alonso. Auditora de Sistemas Una visin prctica, Universidad Nacional de Colombia, 2003.

Direcciones Electrnicas Pginas Web.: URL N 01: INSTITUTO INFORMTICA NACIONAL (INEI) DE ES ESTADSTICA LA E

QU

AUDITORA

INFORMTICA? [En lnea] [Fecha de acceso 08 de abril 2013]. URL disponible en

http://www1.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5105/ Libro.

130

URL N 02: Oficina Nacional de Gobierno Electrnico e Informtica (ONGEI) Auditora de Sistemas [En lnea] [Fecha de acceso 08 de abril 2013]. URL disponible en

http://www.ongei.gob.pe/publica/metodologias/Lib5002/libro .htm

URL N 03: Oficina Nacional de Gobierno Electrnico e Informtica (ONGEI) Auditora de Sistemas [En lnea] [Fecha de acceso 08 de abril 2013]. URL disponible en

http://www.ongei.gob.pe/publica/metodologias/Lib5002/libro .htm

URL N 04: Desarrollo gil de Software [En lnea] [Fecha de acceso 08 de abril 2013]. URL disponible en

http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_soft ware.

URL N 05: Historia de ISACA [En lnea] [Fecha de acceso 08 de abril 2013]. URL disponible en http://www.isaca.org/AboutISACA/History/Espanol/Pages/default.aspx.

131

ANEXOS

132

ANEXO N 01

133

134

Das könnte Ihnen auch gefallen