Auditoria desarrollo sistemas de información

UNIVERSIDAD PRIVADA DEL NORTE Laureate International Universities

FACULTAD DE INGENIERÍA

CARRERA DE INGENIERÍA DE SISTEMAS

COMPUTACIONALES

“AUDITORIA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN EN EL GOBIERNO REGIONAL

CAJAMARCA”

TESIS PARA OPTAR EL TÍTULO PROFESIONAL DE:

INGENIERO DE SISTEMAS

AUTOR:

BACH. ARTURO FERNANDO GRANADOS RODRÍGUEZ

ASESOR: ING. HUGO ALEJANDRO PÉREZ QUIROZ

CAJAMARCA – PERÚ

2012

ii

DEDICATORIA

Arturo Fernando Granados Rodríguez

A Dios por el regalo de la vida. A la Santísima Virgen María que siempre nos cuida bajo su Manto Sagrado.

A mi mami Nora desde el cielo, mi padre Roberto y mi hermana Karla, pues ellos me llenan de felicidad.

A mi esposa Gladys y mi hijito Matías pues en ellos descubrí el que el amor nos hace seguir adelante.

iii

AGRADECIMIENTO

Arturo Fernando Granados Rodríguez

A todo el staff del Gobierno Regional Cajamarca, en especial a mis amigos del Centro de Información y Sistemas por la colaboración brindada.

A mi familia por tanto y tanto apoyo y cariño demostrado. Sin ellos no hubiera tenido la motivación necesaria para terminar mi presente proyecto.

A mi asesor y profesores de mi alma mater, pues con sus conocimientos y experiencias, crearon en mí el anhelo de la investigación.

iv

PRESENTACIÓN Señores:

Miembros del Jurado Calificador de la

Escuela Académico Profesional de Ingeniería de Sist emas

En cumplimiento con las disposiciones vigentes contenidas en el Reglamento de

Grados y Títulos de la Facultad de Ingeniería de la Universidad Privada del Norte,

tengo a bien presentar y someter a vuestra consideración el presente trabajo de

investigación, titulado:

“AUDITORIA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓ N EN EL

GOBIERNO REGIONAL CAJAMARCA”

El presente trabajo ha sido realizado en base a los conocimientos alcanzados en las

aulas universitarias durante mi formación profesional, además de las experiencias

adquiridas fuera de ella.

Agradeciendo por anticipado su valiosa atención y decisión, así como el tiempo y la

dedicación que le están brindando a la presente.

Atentamente.

__________________________

Bach. Arturo Fernando

Granados Rodríguez

v

RESUMEN

La presente investigación tuvo como propósito la aplicación de una Auditoria del

Desarrollo de Sistemas de Información, en ella se establece procesos de verificación

sistemática, independiente y documentado lo cual determina si los resultados y

actividades relacionadas a los proyectos de desarrollo de software, cumplen con lo

planificado para lograr el cumplimiento de las políticas y objetivos del Gobierno

Regional Cajamarca.

El presente estudio es una investigación aplicada - descriptivo – correlacional, el

diseño es no experimental 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.

Población y muestra está conformado por el área de sistema del Gobierno Regional de

Cajamarca. Por ser el número de unidades de análisis pequeña (07 miembros del

staff) se han considerado a todos ellos. Durante el proceso de ejecución del presente

estudio, se revisaron trabajos de investigación relacionados con el tema, así como

fuentes bibliográficas primarias.

Para realizar la auditoria y plantear las mejoraras al desarrollo del sistema de

información, se ha elaborado un cuestionario. Con los resultados se demuestra que la

entidad auditada carece de procedimientos de control interno, como garantía para una

gestión eficaz orientada a la consecución de los objetivos institucionales. Además falta

de documentación donde se gestiones problemas e incidentes en el desarrollo del

proyecto software.

Palabras clave: Auditoria del desarrollo de sistemas, Sistema de Información.

Desarrollo de sistema de información

vi

ABSTRACT

The purpose of this research was the implementation of an Audit of Information

Systems Development, it provides for systematic verification processes, independent

and documented process which determines whether the results and activities related to

software development projects comply with the planned to achieve compliance with the

policies and objectives of the Regional Government Cajamarca.

This study is an applied research - descriptive - correlational design is not experimental

cross section, because the nature of the problem is not causation, it is without

deliberately manipulate the variables, since we observed only the facts as presented in

context.

Population and sample consists of the system area of the Regional Government of

Cajamarca. As the number of small units of analysis (07 staff members) have seen

them all. During the implementation process of the present study, we reviewed

research on the topic, and primary literature sources.

To conduct the audit and referred the development will improve the information system,

has developed a questionnaire. The results demonstrated that the audited entity lacks

internal control procedures, to guarantee effective management toward the

achievement of corporate goals. Besides lack of documentation where problems and

incidents efforts in developing the software project.

Keywords: Audit of Systems Development, Information System. Information system

development

vii

INTRODUCCIÓN

La información que es tratada en organizaciones es un recurso crítico que debería ser

protegida, pues la misma es la base de las decisiones que son tomadas a lo largo del

tiempo. La necesidad que el Gobierno Regional Cajamarca cuente con procedimientos

de control interno es aceptada ampliamente como garantía de una gestión eficaz

orientada a la consecución de objetivos marcados. La función auditora es

precisamente la encargada de comprobar la existencia de estos procedimientos de

control y de verificar su correcta definición y aplicación, determinando las deficiencias

que existan al respecto y los riesgos asociados a estas carencias de control.

El presente estudio está organizado en seis capítulos:

En el Capítulo I: Marco Metodológico.- Aborda generalidades de la investigación, el

plan de investigación, realidad problemática, antecedentes del problema, formulación

del problema, justificación, limites de la investigación, hipótesis, variable independiente

y dependiente, indicadores, objetivo general y específicos, metodología y diseño de

contrastación.

En el Capítulo II: Marco Referencial . – Se considera al Marco Teórico que es la base

para la investigación de la auditoria del desarrollo de sistemas de información.

En el Capítulo III .- Desarrollo de la Metodología. Aborda la manera como se llevó a

cabo la investigación, las características de la población y muestra, una descripción

detallada de los instrumentos de recolección de datos, procedimiento de aplicación y el

diseño estadístico utilizados para el respectivo análisis de los datos.

En el Capítulo IV .- Análisis de Resultados . Se plasma los resultados obtenidos en el

estudio y el análisis y discusión de dichos resultados y sus posibles explicaciones.

En el Capítulo V .- Conclusiones y Recomendaciones. Se presentan las

conclusiones, señalando algunas sugerencias para ulteriores estudios y finalmente,

En el Capítulo VI.- Referencias Bibliográficas . Se incluye material bibliográfico, así

como información que debe incluirse en la tesis.

viii

ÍNDICE GENERAL DEDICATORIA ii

AGRADECIMIENTO iii

PRESENTACIÓN iv

RESUMEN v

ABSTRACT vi

INTRODUCCIÓN vii

ÍNDICE GENERAL viii

ÍNDICE DE FIGURAS xiv

ÍNDICE DE GRÁFICOS xv

ÍNDICE DE CUADROS xvii

ÍNDICE DE TABLAS xviii

CAPÍTULO I: MARCO METODOLÓGICO 1

I. GENERALIDADES 2

1.1 Autor 2

1.2 Asesor 2

1.3 Título 2

1.4 Institución a la que pertenece el proyecto 2

1.5 Lugar y ejecución del proyecto 2

1.6 Tipo de investigación 2

1.7 Duración 2

1.8 Cronograma de Trabajo 2

1.9 Recursos 3

1.9.1. Humanos 3

1.9.2. Materiales 3

1.9.3. Tecnológicos 3

1.10 Presupuesto 4

1.11 Financiamiento 4

II. PLAN DE INVESTIGACIÓN 5

2.1. El Problema 5

2.1.1. Realidad Problemática 5

ix

2.1.2. Antecedentes del Problema 6

2.1.3. Formulación del Problema 8

2.1.4. Justificación del Problema 8

2.1.5. Limitaciones de la Investigación 9

2.2. Hipótesis 9

2.2.1. Formulación de la Hipótesis 9

2.2.2. Variables 9

2.2.3. Indicadores 10

2.3. Objetivos 11

2.3.1. Objetivo General 11

2.3.2. Objetivos Específicos 11

2.4. Metodología 12

2.5. Diseño de Contrastación 13

CAPÍTULO II: MARCO REFERENCIAL 14

II. MARCO TEÓRICO 15

2.1 ¿Qué es un Sistema? 15

2.2 Información 15

2.3 Sistema de Información (SI) 16

2.4 Clasificación de los Sistemas de Información 19

2.5 Tipos de Sistemas de Información 20

2.5.1 Los sistemas a Nivel Operativo 20

2.5.2 Los sistemas a Nivel del Conocimiento 21

2.5.3 Los sistemas a Nivel Administrativo 21

2.5.4 Los sistemas a Nivel Estratégico 21

2.6 AUDITORIA 21

2.6.1 Definición de Auditoria 21

2.7 Auditor 23

2.8 ISACA (Information Systems Audit and Control Association) 23

2.9 Principios de Auditoria 23

2.10 Objetivos Generales de la Auditoria 26

2.11 Alcance de la Auditoria 26

2.12 Implantación de sistema de control interno informático 27

2.12.1 Controles de desarrollo, adquisición y mantenimiento de

sistemas de información 27

x

2.13 Motivos para Efectuar una Auditoria de Tecnologías de

Información 28

2.14 CONTROL INTERNO 29

2.14.1 Componentes del Control Interno 30

2.15 AUDITORIA INFORMÁTICA 31

2.15.1 Control Interno y Auditoria Informática: Campos Análogos 32

2.16 Técnicas y Herramientas Usadas por la Auditoría Informática 33

2.17 AUDITORIA DE SISTEMAS DE INFORMACIÓN 34

2.18 Objetivos de la Auditoria de Sistemas 36

2.19 Planteamiento y Metodología 37

CAPÍTULO III: DESARROLLO DE LA METODOLOGÍA 39

III. ASPECTOS GENERALES DE LA ENTIDAD 40

3.1 Identificación de la entidad auditada 40

3.2 Direccionamiento Estratégico 40

3.2.1 Misión 40

3.2.2 Visión 40

3.3 Ubicación Geográfica 40

3.3.1 Logo 40

3.3.2 Dirección 40

3.3.3 Vista Satelital 41

3.3.4 Exteriores del Gobierno Regional 41

3.4 Organigrama 42

3.5 Análisis de la Entidad Auditada 44

3.6 Marco Legal el Centro de Información y Sistemas 44

3.7 Estructura Orgánica del Centro de Información y Sistemas 47

3.8 Recursos Humanos Del Centro De Información y Sistemas 47

3.9 Problemática del Centro de Información y Sistemas 48

3.10 Alineamiento con el Plan Estratégico Institucional y Sectorial 49

3.11 Estrategias para el logro de las metas del Plan Operativo

informático 50

3.12 Aplicación de auditoría del desarrollo de sistemas de

información en el centro de información y sistemas 51

3.12.1 Auditoría de la organización y gestión del área de sistemas 51

3.12.2 Objetivo de Control OG1: procesos, organización y relaciones 51

xi

3.12.3 Objetivo de Control OG2: Gestión de Recursos Humanos 51

3.12.4 Objetivo de Control OG3: Plan Estratégico de Tecnologías de

l la Información del área 52

3.12.5 Objetivo de Control OG4: Gestión de la calidad 53

3.13 Auditoría de proyectos de desarrollo y mantenimiento 56

3.13.1 Auditoria de la gestión y planificación del proyecto 56

3.13.2 Objetivo de Control P1 56

3.13.3 Objetivo de Control P2 57

3.14 Auditoría de la fase de estudio de viabilidad 60

3.14.1 Objetivo de Control V1 60

3.15 Auditoria de la fase de análisis 61

3.15.1 Objetivo de Control A1 61

3.15.2 Objetivo de Control A2 62

3.16 Auditoria de la fase de diseño 63

3.16.1 Objetivo de Control D1 63

3.16.2 Objetivo de Control D2 64

3.17 Auditoria de la fase de construcción 65

3.17.1 Objetivo de Control CS-1 65

3.17.2 Objetivo de Control CS-2 67

3.18 Auditoria de la fase de implantación y aceptación 68

3.18.1 Objetivo de Control IA-1 68

3.18.2 Objetivo de Control IA-2 69

3.19 Auditoria de la fase de mantenimiento 70

3.19.1 Objetivo de Control M-1 70

3.19.2 Objetivo de Control M-2 70

CAPÍTULO IV: ANÁLISIS DE RESULTADOS 73

IV. RESULTADOS Y DISCUSIÓN 74

4.1 Pregunta N° 01 74







xii



































4.42 Pregunta N° 42 100

4.43 Pregunta N° 43 101

xiii

4.44 Pregunta N° 44 101

4.45 Pregunta N° 45 102

4.46 Pregunta N° 46 103

4.47 Pregunta N° 47 103

CAPÍTULO V: CONCLUSIONES Y RECOMENDACIONE S 105

5.1 Conclusiones 106

5.2 Recomendaciones 106

CAPÍTULO VI: REFERENCIAS BIBLIOGRÁFICAS - ANEXOS 108

VI. REFERENCIAS BIBLIOGRÁFICAS 109

VII. HALLAZGOS DE AUDITORIA 112

xiv

ÍNDICE DE FIGURAS

1. Figura N° 01: Cronograma de actividades. 3

2. Figura N° 02: Diseño de contrastación 13

3. Figura N° 03: Definición de sistema 15

4. Figura N° 04: El Ciclo de la Información (Burch) 16

5. Figura N° 05: Atributos de la Calidad de la Información 16

6. Figura N° 06: Actividades de un Sistema de Información 18

7. Figura N° 07: Sistema de Información 19

8. Figura N° 08: Actividades de un Sistema de Información 31

9. Figura N° 09: Definición de Auditoria de Sistemas 35

10. Figura N° 10: Objetivos de Auditoria de Sistemas 37

11. Figura N° 11: Logo Institucional 40

12. Figura N° 12: Vista Satelital del Gobierno Regional Cajamarca 41

13. Figura N° 13: Exteriores del Gobierno Regional Cajamarca 41

14. Figura N° 14: Estructura Orgánica del Gobierno Regional Cajamarca 43

15. Figura N° 15: Estructura Orgánica del Centro de Información y Sistemas 47

16. Figura N° 16: Datos inconsistentes en la base de datos 113

xv

ÍNDICE DE GRÁFICOS

1. Gráfico N° 01: Auditorias Anteriores 74

2. Gráfico N° 02: Documentación de funciones 74

3. Gráfico N° 03: Organigrama 75

4. Gráfico N° 04: Puesto de Trabajo 76

5. Gráfico N° 05: Promoción de Staff a puestos superiores 76

6. Gráfico N° 06 Staff cumple requisitos al puesto que acceden 77

7. Gráfico N° 07: Formación y motivación del staff 78

8. Gráfico N° 08: Sugerencias del staff 78

9. Gráfico N° 09: Aprobación del proyecto 79

10. Gráfico N° 10: Metodología de desarrollo de sistemas de información 80

11. Gráfico N° 11: Metodología cubre las fases y es adaptable 80

12. Gráfico N° 12: Asignación de responsable de proyecto 81

13. Gráfico N° 13: Dimensión del proyecto 82

14. Gráfico N° 14: Registro de problemas 82

15. Gráfico N° 15: Información Histórica 83

16. Gráfico N° 16: Equipos de trabajo y responsables de las áreas 84

17. Gráfico N° 17: Reuniones del equipo de trabajo 84

18. Gráfico N° 18: Documentación del proyecto 85

19. Gráfico N° 19: Documentación de requisitos 86

20. Gráfico N° 20: Solicitud de participación de personal de otras áreas 86

21. Gráfico N° 21: Nuevos proyectos software 87

22. Gráfico N° 22: Fechas de realización del proyecto 88

23. Gráfico N° 23: Recopilación de información 88

24. Gráfico N° 24: Métricas 89

25. Gráfico N° 25: Guías de prácticas de análisis y diseño 89

26. Gráfico N° 26: Modelo del sistema 90

27. Gráfico N° 27: División de subsistemas 90

28. Gráfico N° 28: Interfaces 91

29. Gráfico N° 29: Normas de diseño 92

30. Gráfico N° 30: Plan de pruebas 92

31. Gráfico N° 31: Aceptación del sistema 93

32. Gráfico N° 32: Validación de la especificación 93

33. Gráfico N° 33: Arquitectura del sistema 94

34. Gráfico N° 34: Migración y carga inicial de datos 95

xvi

35. Gráfico N° 35: Entorno de desarrollo y pruebas 95

36. Gráfico N° 36: Repositorio de productos software 96

37. Gráfico N° 37: Técnicas de programación 97

38. Gráfico N° 38: Programar, probar y documentar componentes 97

39. Gráfico N° 39: Estándares y normas de programación 98

40. Gráfico N° 40: Prueba de cada componente 99

41. Gráfico N° 41: Procedimientos de migración y carga inicial de datos 99

42. Gráfico N° 42: Aceptación formal del sistema 100

43. Gráfico N° 43: Plan de formación y aceptación 101

44. Gráfico N° 44: Capacitación a usuarios 101

45. Gráfico N° 45: Procedimientos de mantenimiento 102

46. Gráfico N° 46: Monitorear nivel de servicio 103

47. Gráfico N° 47: Peticiones de mantenimiento 103

xvii

ÍNDICE DE CUADROS

1. Cuadro N° 01: Personal del CIS 47

2. Cuadro N° 02: Análisis FODA - CIS 49

3. Cuadro N° 03: Alineamiento con el Plan Estratégico Institucional y

Sectorial

50

xviii

ÍNDICE DE TABLAS

1. Tabla N° 01: Presupuesto. 4

2. Tabla N° 02: Indicadores de variable independiente 10

3. Tabla N° 03: Indicadores de variable dependiente 11

4. Tabla N° 04: Similitudes y Diferencias entre Control Interno y Auditoria

Informática

33

5. Tabla N° 05: Auditoría de la organización y gestión del área de sistemas 55

6. Tabla N° 06: Auditoría de proyectos de desarrollo y mantenimiento 59

7. Tabla N° 07: Auditoría de la fase de estudio de viabilidad, fase análisis,

fase diseño, construcción, implantación, aceptación y mantenimiento

72

8. Tabla N° 08: Aplicativos informáticos Gobierno Regional Cajamarca 112

Carrera de Ingeniería de Sistemas Computacionales

1 Bach. Arturo Fernando Granados Rodríguez

Capítulo I:

MARCO METODOLÓGICO



I. GENERALIDADES

1.1. AUTOR

Bach. Arturo Fernando Granados Rodríguez

1.2. ASESOR Ing. Hugo Alejandro Pérez Quiroz

1.3. TITULO

AUDITORIA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN EN EL GOBIERNO REGIONAL CAJAMARCA.

1.4. INSTITUCIÓN A LA QUE PERTENECE EL PROYECTO

Universidad Privada del Norte, Facultada de Ingeniería, Carrera de Ingeniería de Sistemas Computacionales

1.5. LUGAR DE EJECUCION DEL PROYECTO

Área de sistemas del Gobierno Regional Cajamarca,

1.6. TIPO DE INVESTIGACION 1.6.1 De acuerdo al propósito de la investigación : Aplicada

1.6.2 De acuerdo a su grado de profundidad: Descriptivo - Correlacional 1.6.3 De acuerdo al método y técnicas de investigac ión: No experimental

1.7. DURACION

Se realizo en un tiempo de 4 meses (Marzo a Julio del 2012) 1.8. CRONOGRAMA DE TRABAJO



Cronograma de trabajo en Microsoft Project.

Figura N° 01: Cronograma de Actividades

Fuente Propia

1.9. RECURSOS

1.9.1. Humanos Director del CIS Staff. Área de planeamiento estratégico Área de sistemas

Asesor Tesista 1.9.2. Materiales Materiales de escritorio y oficina Fotocopias Memoria USB

Computadora de Escritorio Tintas para impresora Canon 1.9.3. Tecnológicos

Paquete Office 2007 (Microsoft Word, Microsoft Power Point, Microsoft Excel y Microsoft Project) Internet Speedy 2 MB Telefonía Impresora



1.10. PRESUPUESTO

Costo total del proyecto, teniendo en cuenta los recursos utilizados en el desarrollo del mismo.

Recursos Unidad Cantidad Costo uni(S/.)

Costo total(S/.)

Humanos - Asesor

Asesor

1

300

300

Sub-Total 300 Materiales - Papel Bond Atlas de 80 gr

Millar

1

30

30

- Bolígrafos Faber Castell 0.35 Unidad 4 0.50 2.00 - Corrector Faber Castell Unidad 1 3 3 - Lápiz de Grafito Faber Castell Unidad 4 0.50 2.00 - Fotocopias Unidad 1000 0.067 67 - Memoria USB de 8GB Unidad 1 32 32 - Tintas para Impresora Canon Unidad 2 53 106

- Computadora de Escritorio (Intel Core 2 Quad, 2GB RAM, 300GB Disco Duro), Monitor Samsung 22’’, Mouse & Teclado Logitech, Parlantes 5.1 Logitech)

Unidad

1

1

3200

Sub-Total 3442 Tecnológicos - Impresora Multifuncional Canon

Mp190

Unidad

1

180

180

- Línea Tarifa Semi-Plana + Speedy 2 MB

Unidad

1

139

139

Sub-Total 319 Costo Total 4061

Tabla N° 01: Presupuesto

Fuente: Elaboración Propia

1.11. FINANCIAMIENTO

El presente proyecto será autofinanciado.



II. PLAN DE INVESTIGACION

2.1. EL PROBLEMA 2.1.1. Realidad Problemática

La investigación surge a raíz que en todo ámbito institucional se requiere información oportuna y confiable, para la toma de decisiones realidad que ha permitido el desarrollo de sistemas de información. Usualmente, la mayoría de las instituciones, y en este caso, el Gobierno Regional de Cajamarca, en el desarrollo de sistemas de información carece de un análisis técnico profesional, lo cual ha generado una información poco confiable, inoportuna e inconsistente a la hora de tomar decisiones. El Gobierno Regional Cajamarca, entra en vigencia por la Constitución Política del Estado Peruano y la Ley Nº 27867 el año 2003, y su modificatoria Ley Orgánica de Gobiernos Regionales. Esta, indica que es un organismo público con personería jurídica de derecho público, con autonomía política, económica y administrativa en asuntos de su competencia. El Gobierno Regional cuenta con departamento de sistemas el cual lo denominan Centro de Información y Sistemas – CIS, el mismo que da soporte técnico a los diversos procesos administrativos de la institución. Después de haber tenido entrevistas con el Director del CIS (Centro de Información y Sistemas) así como con su staff, dieron a conocer algunos de los problemas que se mencionan a continuación: - Carencia de procedimientos de control interno, como garantía para

una gestión eficaz orientada a la consecución de los objetivos del CIS y de la institución.

- Falta de documentación para la gestión del cambio, problemas e incidentes en el desarrollo del proyecto software.

- Falta de mecanismos de comunicación debidamente documentados entre el staff.

- Falta de una metodología y procedimientos estándares para el desarrollo de sistemas de información: gestión y planificación del proyecto, viabilidad, análisis, diseño, construcción, implantación y mantenimiento.

Ante estos problemas nace el presente trabajo de investigación aplicativo que permitirá mejorar el Área de Sistemas del Gobierno Regional Cajamarca.



2.1.2. Antecedentes del Problema Presento algunos antecedentes de casos de instituciones a Nivel Internacional y Nacional que han desarrollado Auditorias Informáticas con mucho éxito. Nivel Internacional

1. Autor: Carlos Giovanni Guzmán de León

Título: “Lineamientos Generales para una Auditoría de Sistemas en el Centro de Información de una Institución Bancaria” – Agosto 2000

Institución: Universidad Mariano Gálvez de Guatemala Obtener Grado Académico: MAGISTER ARTIUM EN SISTEMAS con Énfasis en Finanzas Resumen u Objetivo: Importancia que tiene la función de la Auditoría de Sistemas, en las instituciones financieras, así como la necesidad de planificarla y desarrollarla.

2. Autor: Guillermo Ramón Caal Chupina Título: “Planeación de la Auditoria Operacional en el Área de Ingresos de una empresa que utiliza el Comercio Electrónico” – Octubre 2006 Institución: Universidad de San Carlos de Guatemala Obtener Titulo de: Contador Público y Auditor en el Grado de Licenciado Resumen u Objetivo: Los elementos del proceso administrativo y la necesidad de considerar la participación de un especialista en Auditoria; asimismo, apoyar la actualización e innovación de herramientas electrónicas y metodológicas para el desarrollo de la actividad del Contador Público y Auditor en la planeación y ejecución de una auditoria operacional.

3. Autor: Francisco Dagoberto Xiloj Charuc Título: “Auditoria Externa en un Ambiente de Sistemas de

Información Computarizado en el Área de Ingresos de una Empresa Comercializadora de Vehículos” – Agosto 2008

Institución: Universidad de San Carlos de Guatemala Obtener Titulo de: Contador Público y Auditor



Resumen u Objetivo: La importancia de comprender los procedimientos y técnicas de Auditoría a aplicarse en una empresa Comercializadora de Vehículos, así mismo saber cómo aplicar los procedimientos y las técnicas más eficientes para Auditar estos nuevos y cada vez más complejos sistemas de información, con la ayuda de la tecnología.

Nivel Nacional

1. Autor: José A. Rau Álvarez Título: “Auditoría Estratégica y Plan de Negocios de una

Empresa de Confecciones de Calcetines” – 2004 Institución: Pontificia Universidad Católica del Perú Obtener Grado de Máster en: Administración de Negocios Resumen u Objetivo: Efectúa una auditoría estratégica, que analiza factores tales como la recesión que es uno de los más importantes a nivel macro, el estudio recomienda aprovechar los actuales espacios que existen para reducir costos. Debe introducirse mejoras tecnológicas y de capacitación para una mejor asignación de costos y reducción de los mismos. Así, con un desarrollo de un mejor control de calidad y manejo de mermas podría reducirse costos y ofrecer artículos con un mayor valor para el cliente.

2. Autor: Liliana Antonieta Palomino Chávez

Título: “Auditoria de Gestión en la Escuela de Ingeniería

de Sistemas” Institución: Universidad Nacional de Trujillo Obtener Titulo de: Ingeniero Informático Resumen u Objetivo: Identifica aspectos prioritarios en la parte de Gestión, aplicando Tecnologías Informáticas que mejoren el proceso que más incurren en incidencias que es el proceso de Matriculas de la Facultad de Ingeniería de Sistemas.

3. Autor: Gissela Karina Chávez García Título: “Auditoria Informática Aplicada al Sistema

Integrado de Gestión Comercial, Comercializadora y Distribuidora Jiménez S.A. de la Empresa Distribuidora Codijisa - Trujillo” - 2008



Institución: Universidad Privada del Norte – Trujillo Obtener Titulo de: Ingeniero de Sistemas Resumen u Objetivo: La aplicación de una Auditoria Informática permite mejorar el sistema, minimizando los errores en un 88.33%.

2.1.3. Formulación del Problema

¿En qué medida la Aplicación de una Auditoria del Desarrollo de Sistemas de Información garantiza la integralidad, confiabilidad de la información del Gobierno Regional Cajamarca?

2.1.4. Justificación del Problema

La seguridad informática cobra cada vez mayor importancia en la sociedad, pues se enfoca en la protección de la infraestructura computacional y todo lo relacionado con esta. Para ello existen una serie de estándares, protocolos, métodos, reglas, herramientas y leyes concebidas para minimizar los posibles riesgos a la información. La seguridad informática comprende software, bases de datos, archivos y todo lo que la organización valore (activo) y signifique un riesgo si ésta llega a manos de otras personas. Este tipo de información se conoce como información privilegiada o confidencial. La presente investigación es necesaria pues la administración del Gobierno Regional de Cajamarca, demanda sistemas de información que le permita realizar la gestión con eficacia y eficiencia. Esto conlleva al desarrollo de un sistema de información, que controle, evalúe y fortalezca la validez y confiabilidad de procesamiento de la Información. El estudio ha permitido identificar las principales deficiencias, que actualmente carece de procedimientos de control, verificar su correcta definición y aplicación que garanticen la integridad y confiabilidad de la información. Por ello, es conveniente realizar la mejora a través de la auditoria del desarrollo de sistemas de información, que permita minimizar los riesgos de la información. La presente investigación se justifica en los siguientes aspectos: Justificación Académica

1. El presente proyecto de tesis ayudará a profundizar el conocimiento en investigación acerca de la realización de una Auditoria del Desarrollo de Sistemas de Información en el Gobierno Regional de Cajamarca.

2. El desarrollo de la tesis permitirá hacer uso de los conocimientos

adquiridos durante el transcurso de la carrera profesional de Ingeniería de Sistemas.



3. Servirá como base, aporte y guías de futuras tesis y proyectos relacionadas al campo de Auditoria Informática.

Justificación Operativa • Staff del área de sistemas del Gobierno Regional Cajamarca • Tesista • Asesor

2.1.5. Limitaciones de la Investigación

El dominio de la investigación está delimitado al Gobierno Regional Cajamarca en el área de sistemas. Y el periodo de estudio caracteriza a la investigación como trasversal, porque se realizará en un momento determinado del tiempo, durante los meses de marzo a julio del 2012.

2.2. HIPOTESIS

2.2.1. Formulación de la Hipótesis

La aplicación de una Auditoria del Desarrollo de Sistemas de Información permite mejorar el área de Sistemas en el Gobierno Regional Cajamarca.

2.2.2. Variables

Variable Independiente: Auditoría . Definición conceptual.- 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 organización y utiliza eficientemente los recursos. Definición operacional: Se medirá a través de los siguientes indicadores: Relevancia, Confiabilidad, Fiabilidad, Eficacia, Seguridad y Desempeño Variable Dependiente: Desarrollo de Sistemas de inf ormación

Definición Conceptual.- El desarrollo de software es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Definición operacional.- Se medirá a través de los siguientes indicadores: Documentación, Ciclo de vida, Equipo Técnico, Alcance del proyecto, Situación actual del proyecto, Modelo del Sistema, Interfaces, Plan de



pruebas, Validación de requisitos, Arquitectura del Sistema, Migración y carga inicial de datos, Entorno de desarrollo y pruebas, Técnicas de programación, Programación de componentes, Pruebas de integración de componentes, Plan de formación y aceptación por usuarios, Capacitación a usuarios, Monitorear nivel de servicio, Registro de peticiones de mantenimiento

2.2.3. Indicadores El proceso se ha llevado a cabo a través de una encuesta cuyo instrumento de

recopilación de datos ha sido el cuestionario diseñado en concordancia con los indicadores seleccionados:

VARIABLE INDEPENDIENTE: Auditoría DEFINICIÓN DIMENSIONES INDICADORES INSTRUMENTO

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 organización y utiliza eficientemente los recursos.

Inspección

• Relevancia • Confiabilidad

Formulario, Análisis de encuestas, Análisis de

Documentación

Evidencias

• Fiabilidad

Integridad

• Eficacia

Información

• Seguridad • Desempeño

Tabla N°2 Indicadores de Variable Independiente

Fuente: Elaboración Propia



VARIABLE DEPENDIENTE: Desarrollo de Sistemas de inf ormación

DEFINICIÓN DIMENSIONES INDICADORES INSTRUMENTO

Es un marco de trabajo conceptual de la ingeniería de software que promueve interaciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto.

Gestión y planificación del proyecto

• Documentación • Ciclo de vida del proyecto • Equipo Técnico

Formulario, Análisis de encuestas, Análisis de

Documentación

Fase de Viabilidad

• Alcance del proyecto • Situación actual del proyecto

Fase Análisis

• Modelo del Sistema • Interfaces • Plan de pruebas • Validación de requisitos

Fase Diseño

• Arquitectura del Sistema • Migración y carga inicial de

datos

Fase Construcción

• Entorno de desarrollo y pruebas

• Técnicas de programación • Programación de

componentes • Pruebas de integración de

componentes Fase de Implantación y Aceptación

• Plan de formación y aceptación por usuarios

• Capacitación a usuarios

Fase de Mantenimiento

• Monitorear nivel de servicio • Registro de peticiones de

mantenimiento.

Tabla N°3 Indicadores de Variable Dependiente

Fuente: Elaboración Propia 2.3. OBJETIVOS

2.3.1. Objetivo General Realizar una Auditoria del Desarrollo de Sistemas de Información para mejorar el área de Sistemas en el Gobierno Regional Cajamarca.

2.3.2. Objetivos Específicos

---- Evaluar la metodología seguida en el desarrollo de Sistemas de Información.



---- Identificar las fases de dicha metodología.

---- Evaluar la adecuación entre el proceso de desarrollo de aplicaciones y los objetivos de la organización.

---- Revisar el cumplimiento de estándares y normas de control interno en el desarrollo de aplicaciones.

---- Determinar si se cumplen las normas de seguridad y control de cambios.

2.4. METODOLOGIA

Tipo de Investigación : El presente estudio es una investigación aplicada-

descriptivo – correlacional; el diseño es no experimental 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.

Ámbito de Estudio: El presente trabajo de investigación se desarrolló en el área

de sistemas del Gobierno Regional de Cajamarca. Población y muestra: Está conformado por el área de sistema del Gobierno

Regional de Cajamarca. Por ser el número de unidades de análisis pequeña (07 miembros del staff) se han considerado a todos ellos.

Unidad de Análisis: Está conformada por el total del personal del área y desarrollo

del sistema de información del Gobierno Regional de Cajamarca Técnica e Instrumentos de Recolección de Datos:

− Técnicas: Durante el proceso de ejecución del presente estudio, se revisaran trabajos de investigación relacionados con el tema, así como fuentes bibliográficas primarias.

− Instrumentos y Recolección de Datos: Para realizar la auditoria y plantear las mejoraras al desarrollo del sistema de información, se ha elaborado un cuestionario, el cual consta de 47 preguntas.

Procesamiento, análisis e interpretación 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 gráficos. En el análisis y discusión se tomará en cuenta el marco teórico y los antecedentes de estudio.

Para determinar el Desarrollo de Sistemas de Inform ación. Se realizó a través de la evaluación de sus fases de desarrollo de sistemas, cumplimiento de estándares y normas de control interno.



2.5. DISEÑO DE CONTRASTACION Diseño de Contrastación La verificación será lógica, pues es la prueba de coherencia de los enunciados según la literatura consultada. Se utilizará Investigación ex-post-facto. La población 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 tamaño de la muestra para la presente investigación es de 7 miembros del staff a quienes se aplicó la encuesta de Auditoria de Sistemas de Información.

Formalización:

M1 X M2

Figura N° 02: Diseño de Contrastación

Fuente Propia donde,

M1: Situación problemática del área de sistemas del Gobierno Regional Cajamarca

X : Aplicación de la auditoria del desarrollo de sistemas. M2: Situación problemática después de la aplicación de la auditoria del desarrollo de sistemas de información.

A través de la aplicación de la auditoria se contrastará con la hipótesis Al finalizar la presente investigación se analizan M2, para determinar la validez de la hipótesis, con el planteamiento de los mejoras del desarrollo de sistemas de información.

Área de

Sistemas – CIS

Área de

Sistemas – CIS

Post – Test Sin grupo de control



Capítulo II:

MARCO REFERENCIAL



II. MARCO TEORICO

2.1 ¿Qué es un Sistema? Según el Ing. Villanueva Sánchez Grover en su Tesis “Sistema de Gestión Estratégica aplicando el Enfoque Sistémico y las Tecnologías de la Información para lograr Ventajas Competitivas en el Instituto Nacional de Cultura de La Libertad”. Ref. Tes [2]. "Un sistema es una entidad autónoma dotada de una cierta permanencia, y constituida por elementos interrelacionados, que forman subsistemas estructurales y funcionales. Se transforma, dentro de ciertos límites de estabilidad, gracias a regulaciones internas que le permiten adaptarse a las variaciones de su entorno específico". 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 cohesión de un cierto número de entidades llamadas partes de un sistema. Un sistema no es algo dado por la naturaleza sino definido por la inteligencia”. Rodríguez Ulloa (1994) Por lo tanto, “se define a un Sistema como un conjunto de elementos interrelacionados que responden a un propósito determinado que como un todo tiene característica que sus partes separadamente no tienen. Está conectado, interactúa y es influenciado por su entorno”. Villanueva Sánchez (2008)

Figura Nº 03: Definición de Sistema

Fuente Tes [1] 2.2 Información Según John Burch & Gary Grudnitski en su libro "Diseño de sistemas de información" Ref. Lib [1].



Es el eslabón indispensable que une a todos los componentes de la organización para una mejor operación y para su supervivencia en un ambiente competitivo y poco amigable.

Figura Nº04 El Ciclo de la Información (Burch)

Lib[1]. Pag.20 Además hace mención que la calidad de la información está en base a: exactitud (inf. clara y libre de tendencias o desviaciones) oportunidad (dentro del marco de tiempo necesario) y relevancia (importancia).

Figura Nº05 Atributos de la Calidad de la Información

Lib[1]. Pag.20

2.3 Sistema de Información (SI) Según Ralph M. Stair, en su libro “Principios de SISTEMAS DE INFORMACION – Enfoque Administrativo”. Ref. Lib [02] “Un Sistema de Información (SI) es un conjunto de componentes interrelacionados para recolectar, manipular y diseminar datos e información y para disponer de un mecanismo de retroalimentación útil en el cumplimiento de un objetivo”.



“Todos interactuamos en forma cotidiana con sistemas de información, para fines tanto personales como profesionales; utilizamos cajeros automáticos, los empleados de las tiendas registran nuestras compras sirviéndose de códigos de barras y escáner u obtenemos información en módulos equipados con pantallas sensibles al tacto, las muy famosas touch screen. Las principales compañías gastan en la actualidad más de 1 000 millones de dólares al año en tecnología de información y el futuro dependeremos aún más de los sistemas de información“ Según Kenneth Laudon. & Jane Laudon en su libro “Sistemas De Información Gerencial”. Ref. Lib [03] “Un sistema de información se puede definir técnicamente como un conjunto de componentes interrelacionados que recolectan (o recuperan), procesan, almacenan y distribuyen información para apoyar la toma de decisiones y el control en una organización. Además de apoyar la toma de decisiones, la coordinación y el control, los sistemas de información también pueden ayudar a los gerentes y trabajadores a analizar problemas, visualizar asuntos complejos y crear productos nuevos”. Los sistemas de información contienen información acerca de gente, lugares y cosas importantes dentro de la organización o en el entorno que se desenvuelven. Por información 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 físico antes de ser organizados y ordenados en una forma que las personas puedan entender y utilizar. Hay tres actividades en un sistema de información que producen la información 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 organización como de su entorno externo. El procesamiento convierte esta entrada de datos en una forma significativa. La salida transfiere la información procesada a la gente que lo usará o a las actividades para las que se utilizará. Los sistemas de información también requieren retroalimentación que es la salida que se devuelve al personal adecuado de la organización para ayudarle a evaluar o corregir la etapa de entrada.



Figura Nº06 Actividades de un Sistema de Información Fuente: Sistemas de Información Gerencial Lib [03]

Según Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. En su libro “Auditoría de Tecnologías y Sistemas de Información”. Ref Lib [06]. Pg. 346. En un sentido amplio se puede considerar que un SI es un conjunto de elementos que interactúan para que la empresa pueda alcanzar sus objetivos satisfactoriamente. Según COBIT los componentes o recursos de un SIson los siguientes:

� Datos En general se consideran datos tanto los estructurados como los no estructurados, las imágenes, los sonidos, etc.

� Aplicaciones Se incluyen las aplicaciones manuales y las informáticas

� Infraestructura En infraestructura se incluyen las tecnologías y las instalaciones (por ejemplo hardware, sistemas operativos, sistema de gestión 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 información para planificarlos, organizarlos, administrarlos y gestionarlos



Figura Nº07 Sistema de Información

Fuente: “Auditoría de Tecnologías y Sistemas de Información”. Ref Lib [06]. Pg. 347. Para comprobar que el sistema de información está funcionando según 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 auditoria parcial de un sistema de información 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 información.

2.4 Clasificación de los Sistemas de Información Según Vinceç Fernández Alarcón, en su libro “Desarrollo de Sistemas De Información – Una metodología basada en el modelado”. Ref. Lib [04]. Propone diversos criterios para la clasificación de los Sistemas de Información:

1. Por el grado de formalidad: � Sistemas de Información Formales y los Informales

2. Por el nivel de automatización conseguido:

� En las organizaciones, pueden existir sistemas que necesitan una alta participación de los trabajadores – poco automatizadas (Por ejemplo, los sistemas para responder a preguntas personalizadas a través de un e-mail) -, mientras que otros sistemas son capaces de trabajar sin la intervención



humana – muy automatizadas (por ejemplo, las centrales telefónicas totalmente automatizadas).

3. Por su relación con la toma de decisiones

� Una de las funciones que deben cumplir los sistemas de información es colaborar en la toma de decisiones. En función del lugar jerárquico en donde se tomen las decisiones, los sistemas de información se podrán clasificar en estratégicos, de control u operativos

4. Por la naturaleza de sus entradas y salidas � Un sistema de información puede recibir información de diversas

fuentes de información (personas, empresas, otros sistemas de información, etc.) así como en distintos formatos (a través de un teclado, por la red, de un disquete, memoria USB, CD, DVD etc.) del mismo modo, los Sistema de Información pueden proporcionar información a través de distintos formatos (impreso, por pantalla, en internet, etc.)

5. Por el origen y el grado de personalización � En las empresas se pueden encontrar Sistemas de Información

que han sido diseñados e implementados sólo para ellos, o también sistemas comprados que son utilizados por otras empresas.

6. Por el valor que representan para las organización � El sistema que contiene la información de los clientes suele

tener una mayor importancia que el sistema de información de presupuestos (ya que este es más sencillo y se puede hacer manualmente).

2.5 Tipos de Sistemas de Información Según Kenneth Laudon. & Jane Laudon en su libro “Sistemas De Información Gerencial”. Ref. Lib [03] Plantean cuatro principales tipos de sistemas de información que dan servicio a los diferentes niveles de la organización: sistemas a nivel operativo, sistemas a nivel del conocimiento, sistemas a nivel administrativo y sistemas a nivel estratégicos. 2.5.1 Los sistemas a Nivel Operativo apoyan a los gerentes operativos en el seguimiento de las actividades y transacciones elementales de la organización como ventas, ingresos, depósitos en efectivo, nómina, decisiones de crédito y flujo de materiales en una fábrica. El objetivo principal de los sistemas a este nivel es responder las preguntas de rutina y seguir el flujo de las transacciones



a través de la organización. ¿Cuántas partes hay en el inventario? ¿Qué pasó con el pago del señor Gutiérrez? En general, para contestar este tipo de preguntas la información debe estar a la mano y ser actual y precisa. Entre los ejemplos de sistemas a nivel operativo están un sistema para registrar los depósitos realizados en un cajero automático o uno que lleve el registro del número de horas trabajadas cada día por los empleados de una fábrica. 2.5.2 Los sistemas a Nivel del Conocimiento apoyan a los trabajadores del conocimiento y de datos de una organización. El propósito de estos sistemas es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organización 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, están entre las aplicaciones de crecimiento más rápido en los negocios actuales. 2.5.3 Los sistemas a Nivel Administrativo sirven a las actividades de supervisión, 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 periódicos más que información instantánea de operaciones. Un ejemplo es un sistema de control de reubicación que informe los costos totales de mudanza, búsqueda de vivienda y financiamiento de vivienda para empleados de todas las divisiones de la compañía y notifique cualquier costo actual que exceda los presupuestos. 2.5.4 Los sistemas a Nivel Estratégico ayudan a los directores a enfrentar y resolver aspectos estratégicos y tendencias a largo plazo, tanto en la empresa como en el entorno externo. Su función principal es compaginar los cambios del entorno externo con la capacidad organizacional existente. ¿Cuáles serán los niveles de empleo dentro de cinco años? ¿Cuáles son las tendencias a largo plazo de los costos de la industria y dónde encaja nuestra empresa? ¿Qué productos deberemos estar elaborando dentro de cinco años? Los sistemas de información también apoyan las principales funciones empresariales como ventas y marketing, manufactura, finanzas, contabilidad, y recursos humanos. Una organización típica tiene sistemas a nivel operativo, administrativo, del conocimiento y estratégico para cada área funcional. 2.6 AUDITORIA. 2.6.1 Definición de Auditoria En su libro, Carlos Muñoz Razo. “Auditoria en Sistemas Computacionales”, Ref. Lib [05]



Los inicios de la auditoria se remontan a la revisión y el diagnóstico que se practicaba a los registros operacionales contables de las empresas; después se pasó al análisis, verificación y evaluación de sus aspectos financieros; posteriormente se amplió al examen de algunos rubros de la administración, siguiendo con el análisis de aquellos aspectos que intervenían en todas sus actividades y, por último, su alcance se incrementó conforme se avanzó en la llamada revisión integral. Nos muestra además una definición de auditoría: Auditoria es la revisión independiente que realiza un auditor profesional, aplicando técnicas, métodos 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 dicha evaluación. En la página Web del INEI: ¿QUÉ ES LA AUDITORÍA INFORMÁTICA? Ref. URL [1] Hare referencia a: La Auditoría cumple una función muy valiosa e independiente, no toma acciones pero da sugerencias, y sus conclusiones deben tomarse en cuenta en la toma de decisiones. La auditoría se apoya de herramientas de análisis, verificación y exposición conformando así elementos de juicio, los cuales permitirán 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 auditoría, además esta actitud es comprensible. Pero los sistemas en ocasiones son muy sofisticados, lo cual hace que el auditor disponga de un nivel técnico adecuado e insuficiente frente al tiempo que tiene para realizar su trabajo. Como parte de la auditoría esta la evaluación 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 Auditoría, por considerarse información confidencial y activos muy importantes que respaldan su actividad. La evaluación debe ceñirse de acuerdo a las normas o reglas implantadas y se considera que debe aplicarse una metodología que pueda resolver los problemas que puedan presentarse. Francisco Dagoberto Xiloj Charuc, en su Tesis Ref. Tes [03]: “Auditoría Externa en un Ambiente de Sistemas de Información Computarizado en el Área de Ingresos de una Empresa Comercializadora de Vehículos”. Nos menciona: La Auditoría consiste en un examen sistemático de los libros, documentos y demás 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 opinión que el Contador Público y Auditor, emite sobre los estados financieros preparados por la entidad, a una fecha determinada y el resultado de las operaciones por un período terminado en esa fecha, así como los estados de flujos de efectivo y patrimonio de los accionistas. 2.7 Auditor En su libro, Carlos Muñoz Razo. “Auditoria en Sistemas Computacionales”, Ref. Lib [05] Del latín Auditor, oris s.m. 1. Persona capacitada para realizar auditorías en empresas u otras instituciones. Pertenece a un colegio oficial. Del latín auditor ; el que oye, del verbo audire . Oír. Anteriormente oyente El autor del libro propone la siguiente definición para la auditoria: “Es la revisión independiente de alguna o algunas actividades, funciones específicas, resultados u operaciones de una entidad administrativa, realizada por un profesional de la auditoria, con el propósito de evaluar su correcta realización y, con base en ese análisis, poder emitir una opinión sobre la razonabilidad de sus resultados y cumplimiento de sus operaciones” Según la Página Web, ¿QUÉ ES LA AUDITORÍA INFORMÁTICA? Del Instituto Nacional De Estadística e Informática (INEI). Ref URL [1]. Pg 11 “Si nos remontamos al campo de la etimología veremos que auditoría viene del latín auditorius, proviniendo de aquí la palabra auditor, la misma que significa o que se refiere a aquel que tiene la virtud de oir”. 2.8 ISACA (Information Systems Audit and Control As sociation - Asociación de Control y Auditoría de Sistemas de In formación) Ref. URL [5]: Desde su creación, ISACA se ha convertido en una organización global que establece las pautas para los profesionales del gobierno, control, seguridad y auditoría de información. Sus normas de auditoría y control de SI son seguidos por profesionales de todo el mundo y sus investigaciones abordan temas profesionales que son desafíos para sus constituyentes. 2.9 Principios de Auditoria En el libro “Auditoría de Tecnologías y Sistemas de Información” de Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. Ref Lib [06]. Pg. 349, 350, 351, 352. Algunos de los principios publicados por ISACA son:



1. Formalidad

• Responsabilidad, atribuciones y obligaciones Las responsabilidades, atribuciones y obligaciones que abarca la función de auditoría de los sistemas de información deben documentarse de manera apropiada (formal) en unos estatutos de auditoría en el caso de la auditoría interna, o en una carta de encargo o contrato en el caso de la auditoría externa.

2. Independencia

• Independencia profesional En todas las cuestiones relacionadas con la auditoria, el auditor de sistemas de información debe ser independiente de la organización auditada tanto en actitud como en apariencia. • Relación con la organización La función de auditoría de los sistemas de información debe ser lo suficientemente independiente del área que se esté auditando para permitir realizar de manera objetiva la auditoria.

3. Ética y normas profesionales

• Condigo de Ética profesional Al igual que en otros colectivos profesionales, distintos organismos han publicado unos códigos de conducta o normas deontológicas que el auditor de sistemas de información ha de cumplir. Así el auditor que sea miembro de ISACA debe acatar el Código 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 información, se debe ejercer la atención profesional correspondiente y el cumplimiento de las normas aplicables de auditoría profesional.

4. Idoneidad

• Habilidades y conocimientos



EI auditor de sistemas de información debe ser técnicamente idóneo y tener la experiencia y los conocimientos necesarios para realizar el trabajo de auditor. • Formación profesional continúa

EI auditor de sistemas de información debe mantener la idoneidad técnica mediante su formación profesional continua.

5. Planificación

• Planificación de la Auditoria

EI auditor de sistemas de información debe planificar el trabajo de auditoría para satisfacer los objetivos de la auditoria y para cumplir con las normas de auditoría aplicables a la profesión.

6. Ejecución de la auditoria

• Evidencia

Durante el transcurso de una auditoria, el auditor de sistemas de información debe obtener evidencia adecuada (fiable, relevante y útil) y suficiente para lograr los objetivos de la auditoria. Los hallazgos y conclusiones de la auditoria se deben basar en el análisis e interpretación apropiados de dicha evidencia. • Documentación

EI proceso de auditoria deberá documentarse, describiendo las labores de auditoría realizadas y la evidencia de auditoría que respalda los hallazgos y conclusiones del auditor.

• Supervisión

EI personal de auditoría de SI debe ser supervisado para brindar una garantía razonable de que se lograran los objetivos de la auditoria y que se cumplirán las normas profesionales de auditoría aplicables.

7. Información

• Contenido y formato de los informes

En el momento de completar el trabajo de auditoría, el auditor de sistemas de información debe proporcionar un informe con un formato apropiado a los destinatarios. EI informe de auditoría debe enunciar el alcance, los objetivos, el periodo de cobertura y la naturaleza y



amplitud del trabajo de auditoría realizado. El informe debe identificar al auditarlo (cliente), los destinatarios en cuestión y cualquier restricción con respecto a su circulación. EI informe debe enunciar los hallazgos, las conclusiones y las recomendaciones, y cualquier reserva o consideración que tuviera el auditor con respecto a la auditoria.

2.10 Objetivos Generales de la Auditoria En el Libro “Auditoria en Sistemas Computacionales”, de Carlos Muñoz Razo. Ref Lib [05]. Entre los objetivos más relevantes, encontramos a los siguientes: � Realizar una revisión independiente de las actividades, áreas o funciones

especiales de una institución, a fin de emitir un dictamen profesional sobre la razonabilidad de sus operaciones y resultados.

� Hacer una revisión especializada, desde un punto de vista profesional y autónomo, del aspecto contable, financiero y operacional de las áreas de la empresa.

� Evaluar el cumplimiento de los planes, programas, políticas, y lineamientos que regulan la actuación de los empleados y funcionarios de una institución, 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.

2.11 Alcance de la Auditoria En el libro “Auditoría de Tecnologías y Sistemas de Información” de Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. Ref Lib [06]. Pg. 352. EI auditor debe determinar el alcance de su trabajo de acuerdo con las Normas Técnicas y decidir los procedimientos de auditoría, así como su extensión, 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 diseñados para soportar la opinión técnica en aquellas aéreas más significativas y en las que sea más probable que se puedan producir errores importantes deben ser más amplios y extensos que en aquellas otras en que no se den estas circunstancias. EI auditor debe requerir del auditado (cliente) cuanta información precise para realizar los trabajos de auditoría. Cualquier limitación al trabajo impuesta por el auditado o sobrevenida a lo largo del trabajo que impida la aplicación de lo



dispuesto en las Normas Técnicas debe ser considerada en el informe de auditoría como una limitación al alcance. Para planificar y organizar la actividad de auditoría de sistemas de información, el auditor debe incluir en el alcance de la auditoria los procesos relevantes y los procesos para supervisar esa actividad así como todos los recursos relacionados con el SI. 2.12 Implantación de sistema de control interno inf ormático Según Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. En su libro “Auditoría de Tecnologías y Sistemas de Información”. Ref Lib [06] 2.12.1 Controles de desarrollo, adquisición y mante nimiento de sistemas de información Permiten alcanzar la eficacia del sistema, economía y eficiencia, integridad de los datos, protección de los recursos y cumplimiento con las leyes y regulaciones: � Metodología del ciclo de vida del desarrollo de sistemas: su empleo podrá

garantizar a la alta Dirección que se alcanzaran los objetivos definidos para el sistema. Estos son algunos controles que deben existir en la metodología:

� La alta Dirección debe publicar una normativa sobre el uso de

metodología de ciclo de vida del desarrollo de sistemas y revisar esta periódicamente.

� La metodología debe establecer los papeles y responsabilidades de las distintas aéreas del Departamento de Informática y de los usuarios, así como la composición y responsabilidades del equipo del proyecto.

� Las especificaciones del nuevo sistema deben ser definidas por los usuarios y quedar escritas y aprobadas antes de que comience el proceso de desarrollo.

� Debe establecerse un estudio tecnológico de viabilidad en el cual se formulen formas alternativas de alcanzar los objetivos del proyecto acompañadas de un análisis coste-beneficio -de cada alternativa-.

� Cuando se seleccione una alternativa debe realizarse el plan director del proyecto. En dicho plan deberá existir una metodología de control de costes.

� Procedimientos para la definición y documentación de especificaciones de: diseño, de entrada, de salida, de ficheros, de procesos, de programas, de controles de seguridad, de pistas de auditoría, etc.

� Plan de validación, verificación y pruebas. � Estándares de prueba de programas, de pruebas de sistemas � Plan de conversión; prueba de aceptación final.



� Los procedimientos de adquisición de software deberán seguir las políticas de adquisición de la Organización y dichos productos deberán ser probados y revisados antes de pagar por ellos y ponerlos en uso.

� La contratación de programas de servicios de programación a medida ha de estar justificada mediante una petición escrita de un director de proyecto.

� Deberán prepararse manuales de operación y mantenimiento como parte de todo proyecto de desarrollo o modificación de sistemas de información, así como manuales de usuario.

� Explotación y mantenimiento: 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 autorización adecuada. Estos son algunos de los controles que se deben implantar: � Procedimientos de control de explotación � Sistema de contabilidad para asignar a usuarios los costos asociados

con la explotación de un sistema de información. � Sistema de contabilidad para asignar a usuarios los costes asociados

con la explotación de un sistema de información. � Procedimientos para realizar un seguimiento y control de los cambios de

un sistema de información.

2.13 Motivos para Efectuar una Auditoria de Tecnolo gías de Información

Según el Mg. Ing. Alberto Mendoza De Los Santos, en una presentación de sus clases de la Universidad Privada del Norte. Ref. PPT [1]. Pg. 15, 16, 17

Entre los principales justificativos o motivos de una auditoría, encontramos:

� Aumento del presupuesto del Departamento de procesamiento de

datos. � Desconocimiento de la situación informática de la empresa. � Falta total o parcial de seguridades lógicas y físicas que garanticen la

integridad del personal, equipos e información. � Descubrimientos de fraudes efectuados con el uso del computador. � Falta de una planificación informática. Falta de visión. � Organización que no funciona correctamente, debido a falta de políticas,

objetivos, normas, metodología, estándares, delegación de autoridad, asignación de tareas y adecuada administración del recurso humano.

� Descontento general de los usuarios, motivado generalmente, por incumplimiento de plazos y mala calidad de resultados.

� Falta de documentación o documentación incompleta de sistemas.

Dentro de los motivos para efectuar una auditoria, el INEI en su página Web: ¿QUÉ ES LA AUDITORÍA INFORMÁTICA? Ref. URL [1]. Hace referencia a:



Cuando existen síntomas de debilidad en la empresa, éstas acuden a las auditorías externas para poder determinar en donde están las falencias. Estos síntomas se pueden agrupar clases:

� Cuando existe Desorganización y Descoordinación : - Los promedios conseguidos no se habitúan a los estimados, por que los parámetros de productividad no son respetados y sufren un desvío. - Los objetivos que la empresa persigue, no coinciden con los obtenidos. - Esto puede darse debido a un cambio masivo de personal, o también porque un área tuvo una mala reestructuración, también puede deberse a una norma importante que haya sido modificada.

� Cuando hay insatisfacción del cliente y una mala im agen:

- Cuando no hay capacidad de satisfacer las necesidades del cliente. - 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. - Los resultados periódicos no son entregados en los plazos establecidos. Las pequeñas imprecisiones pueden ocasionar que la información no refleje lo real y que la actividad que ejerce el usuario se vea afectada por este motivo.

� Debilidades Económico-Financieras:

- Elevación de costos de forma repentina y desmesurada. - Cuando se da la necesidad de justificar las inversiones informáticas. - Cuando se dan otras prioridades en el aspecto presupuestario. - Costos y plazos de nuevos proyectos.

� Cuando existe inseguridad:

Se da una evaluación de nivel de riesgos, la que contempla los puntos siguientes: • Seguridad Lógica. • Seguridad Física. • Aspectos de confidencialidad. - La continuidad en el servicio es importante. En ocasiones se considera más importante que los aspectos de seguridad. - Si existen problemas en los que el centro de procesamiento de datos se encontrara fuera de control, una auditoría no tendría sentido por considerarse inútil, por eso deben tomarse en cuenta los más mínimos indicios para su aplicación.

2.14 CONTROL INTERNO

Según el Mg. Ing. Alberto Mendoza De Los Santos, en una presentación de sus clases de la Universidad Privada del Norte. Ref. PPT [2]. Pg. 22



Esta referido fundamentalmente a la adopción de medidas preventivas, que tienen como finalidad salvaguardar los bienes de la empresa. Busca evitar acciones nefastas como sabotajes, fraudes y otro tipo de situaciones que lleven a inestabilidad o desaparición del negocio.

Según Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. En su libro “Auditoría de Tecnologías y Sistemas de Información”. Ref Lib [06] Pag. 05, 06 El Control Interno informático controla diariamente que todas las actividades de sistemas de información sean realizadas cumpliendo los procedimientos, estándares y normas fijados por la Dirección de la Organización y/o la Dirección de Informática, así como los requerimientos legales. La misión del Control Interno Informático es asegurarse de que las medidas que se obtienen de los mecanismos implantados por cada responsable sean correctas y validas. 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 Auditoria Informática, así como de las

auditorías externas al Grupo. • Definir, implantar y ejecutar mecanismos y controles para comprobar el

logro de los grados adecuados del servicio informático, lo cual no debe considerarse como que la implantación de los mecanismos de medida y la responsabilidad del logro de esos niveles se ubique exclusivamente en la función de Control Interno, sino que cada responsable de objetivos y recursos es responsable de esos niveles, así como de la implantación de los medios de medida adecuados.

2.14.1 Componentes del Control Interno

Según el Mg. Ing. Alberto Mendoza De Los Santos, en una presentación de sus clases de la Universidad Privada del Norte. Ref. PPT [2]. Pg. 22. La nueva economía ha obligado a las empresas a realizar cambios. Algunos de estos cambios, se pueden resumir en:

� Restructuración de los procesos empresariales (BPR: Business Process

Re-engineering)



� Gestión de la calidad (TQM) � Redimensionamiento por reducción o crecimiento hasta el nivel correcto � Outsourcing � Descentralización

Los cambios que se mencionan, se deben a fuerzas externas que presionan a la empresa (ver Figura N°5). Ante esta situación, las empresas deben evaluar sus sistemas de control interno de manera permanente. Para enfrentar y manejar estas fuerzas, se hace necesaria la adopción de la tecnología disponible. Los Sistemas de información constituyen un soporte fundamental para poner en marcha las estrategias planteadas por la alta dirección. Esto origina también un aumento de las necesidades de control y auditoria. Es en este escenario que aparecen 2 conceptos fundamentales: El control interno y la Auditoria informática

Figura Nº08 Actividades de un Sistema de Información

2.15 AUDITORIA INFORMÁTICA

En el libro “Auditoría de Tecnologías y Sistemas de Información” de Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. Ref Lib [06] Pag. 07 La Auditoria Informática 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 organización y utiliza eficientemente los recursos. De este modo la auditoria Informática sustenta y confirma la consecución de los objetivos tradicionales de la auditoria:



• Objetivos de protección de activos e integridad de datos • Objetivos de gestión que abarcan, no solamente los de protección de

activos, sino también los de eficacia y eficiencia.

En el Libro “Auditoria en Sistemas Computacionales”, de Carlos Muñoz Razo. Ref Lib [05]. Es la revisión técnica especializada y exhaustiva que se realiza a los sistemas computacionales, software e información utilizados en una empresa, sean individuales, compartidos y/o de redes, así como a sus instalaciones, telecomunicaciones, mobiliario, equipos de periféricos y demás componentes. Dicha revisión se realiza de igual manera a la gestión informática, el aprovechamiento de sus recursos, las medias de seguridad y de los bienes de consumo necesarios para el funcionamiento del centro de cómputo. El propósito fundamental es evaluar el uso adecuado de los sistemas para el correcto ingreso de datos, el procesamiento adecuado de la información y la emisión oportuna de sus resultados en la institución, incluyendo la evaluación 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 página Web: ¿QUÉ ES LA AUDITORÍA INFORMÁTICA?. Ref. URL [1]. Hace referencia a los objetivos fundamentales de la Auditoria informática: La Auditoría debe iniciar su actividad cuando los Sistemas están operando, éste es el principal objetivo, el de mantener tal situación. Tal objetivo debe conseguirse tanto a nivel global como parcial. La operatividad de los sistemas ha de constituir entonces la principal preocupación del Auditor informático. Para conseguirla hay que acudir a la realización de Controles técnicos generales de operatividad y Controles técnicos específicos de operatividad, previos a cualquier actividad de aquel.

2.15.1 Control Interno y Auditoria Informática: Ca mpos Análogos

El control interno Informático y la auditoría Informática, tienen similitudes en sus objetivos profesionales. Son campos análogos que propician una transición natural entre ambas disciplinas. Sin embargo existen diferencias que conviene resaltar.



Tabla Nº4 Similitudes y Diferencias entre Control Interno y Auditoria Informática

2.16 Técnicas y Herramientas Usadas por la Auditorí a Informática

El INEI en su página Web: ¿QUÉ ES LA AUDITORÍA INFORMÁTICA?. Ref. URL [1]. Hace referencia a: Cuestionarios La información recopilada es muy importante, y esto se consigue con el levantamiento de información y documentación de todo tipo. Los resultados que arroje una auditoría se ven reflejadas en los informes finales que estos emitan y su capacidad para el análisis 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 información necesaria para ser disernida 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 preimpresos, los cuales son dirigidas a las personas que el auditor considera más indicadas, no existe la obligación de que estas personas sean las responsables de dichas áreas a auditar. Cada cuestionario es diferente y muy específico para cada área, además deben ser elaborados con mucho cuidado tomando en cuenta el fondo y la forma. De la información que ha sido analizada cuidadosamente, se elaborará otra información la cual será emitida por el propio Auditor. Estas informaciones serán cruzadas, lo que vine a ser uno de los pilares de la auditoría. Muchas veces el auditor logra recopilar la información por otros medios, y que estos pre impresos podían haber proporcionado, cuando se da este caso, se puede omitir esta primera fase de la auditoría. Entrevistas



Existen tres formas para que el auditor logre relacionarse con el personal auditado. La solicitud de la información 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 método estricto de sometimiento a un cuestionario. La entrevista es un medio por el que el auditor usará metodologías las que han sido establecidas previamente con la finalidad de encontrar información concreta. La importancia que la entrevista tiene en la auditoría se debe a que, la información que recoge es mayor se encuentra mejor elaborada, y es más concreta que las que pueden proporcionar los medios técnicos, o los cuestionarios. La entrevista personal entre el auditor y el personal auditado, es basada en una serie de preguntas específicas en las que el auditado deberá responder directamente. El sistema de interrogación se establece previamente y el auditor tendrá mucho cuidado, esta entrevista se debe dar de una forma muy cordial y bajo los parámetros de lo correcto, esto se hace con la finalidad de que sea lo menos tensa posible, y que el auditado conteste de la forma más natural, con mucha sencillez. Sólo que esta sencillez con la que se elaboran las preguntas deberán 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 reelaboración de sus cuestionarios de acuerdo a la situación 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 análisis, cruce y elaboración posterior del informe final, pero esto no indica que el auditado tenga que ser sometido a un interrogatorio automatizado lo cual no ofrece ningún camino. Por el contrario el auditor realizara 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 de sus Check Lists.

2.17 AUDITORIA DE SISTEMAS DE INFORMACIÓN

Según Alonso Tamayo Alzate en su Libro “Auditoria de Sistemas – Una visión práctica”. Ref Lib [07] “La Auditoria de sistemas es la parte de la auditoría interna que se encarga de llevar a cabo la evaluación de normas, controles, técnicas y procedimientos que se tienen establecidos en una empresa para logar confiabilidad, oportunidad, seguridad y confidencialidad de la información que se procesa a través de



computadores; es decir, en estas evaluaciones se está involucrado tanto los elementos técnicos como humanos que intervienen en el proceso de información”

Figura Nº09 Definición de Auditoria de Sistemas

Según el Instituto Nacional de Estadística e Informática (INEI) en su investigación “Auditoria de Sistemas”. Ref. URL [2]. “La Auditoria de Sistemas es el conjunto de técnicas que permiten detectar deficiencias en las organizaciones de informática y en los sistemas que se desarrollan u operan en ellas, incluyendo los servicios externos de computación, que permitan efectuar acciones preventivas y correctivas para eliminar las fallas y carencias que se detecten. Se verifica la existencia y aplicación de todas las normas y 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 efectúan Auditoras de Sistemas, con la finalidad de asegurar la eficiencia de las organizaciones de informática, así como la confiabilidad y seguridad de sus sistemas.” Según el Mg. Ing. Alberto Mendoza De Los Santos, en una presentación de sus clases de la Universidad Privada del Norte. Ref. PPT [1]. Pg. 05 La Auditoria de Tecnologías de Información es un “Examen objetivo, crítico, sistemático, eminentemente posterior y selectivo de las políticas, normas, prácticas, procedimientos y procesos con el fin de emitir una opinión respecto a la eficiencia en la utilización de los recursos informáticos; la confiabilidad, consistencia, integridad y oportunidad de la información y la efectividad de los controles en los sistemas de información computarizados.”



Según Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. En su libro “Auditoría de Tecnologías y Sistemas de Información”. Ref Lib [06] Pag. 33 En la década del 1970 (concretamente se funda en 1967) se consolida la que hoy se llama Information Systems Audit and Control Association (ISACA), siendo aun hoy la Única entidad, a nivel mundial, de los auditores de SI, y que gestiona una certificación en esta materia: Certified Information Systems Auditor (CISA). Esta asociación, que está presente en más de 140 países, a través de más de 170 capítulos (Chapters, en ingles) en todo el mundo, establece normas y procedimientos para la función de la auditoria de SI y los profesionales que las realizan. Las preocupaciones fundamentales con respecto a la tecnología aludida anteriormente siguen siendo GIS mismas o se han incrementado con la evolución tecnológica. Estas inquietudes tanto de la Dirección de una entidad, como de sus accionistas o de la sociedad en general, se pueden concretar en:

• La veracidad de la información, en cuanto a su totalidad y exactitud,

procesada por los sistemas de tecnología.

• La utilización racional y ajustada a las necesidades reales de los

recursos tecnológicos.

• EI "mantenimiento" o "sostenibilidad" de la estructura tecnológica y su

crecimiento no debe ser traumático en el soporte de nuevas actividades.

• La confidencialidad de la información

• La protección de sus activos, especialmente el software y la

información.

2.18 Objetivos de la Auditoria de Sistemas Según Alonso Tamayo Alzate en su Libro “Auditoria de Sistemas – Una visión práctica”. Ref Lib [07] A continuación se exponen los objetivos que persigue la auditoria de sistemas, los cuales se presentan agrupados en objetivos generales y objetivos específicos, de la siguiente forma:



Figura Nº10 Objetivos de Auditoria de Sistemas

Objetivos Generales • Evaluar las políticas generales sobre la planeación, ambiente laboral,

entrenamiento y capacitación, desempeño, supervisión, motivación y remuneración del talento humano.

• Evaluar políticas generales de orden técnico con respecto al software, hardware, desarrollo, implantación, operación y mantenimiento de sistemas de información-

• Evaluar políticas generales sobre seguridad física con respecto a instalaciones, personal, equipos, documentación, back-ups, pólizas y planes de contingencias.

• Evaluar los recursos informáticos de la empresa con énfasis en su nivel tecnológicos, producción de software y aplicaciones más comúnmente utilizadas.

• Asesorar a la gerencia y altos directivos de la empresa en lo relacionado con los sistemas de información, de tal forma que el proceso de toma de decisiones se efectúe lo más acertadamente posible.

• Conocer las políticas generales y actitudes de los directivos frente a la auditoria y seguridad de los sistemas de información y proceder a hacer las recomendaciones pertinentes.

2.19 Planteamiento y Metodología

En el libro “Auditoría de Tecnologías y Sistemas de Información” de Mario Piattini Velthuis, Emilio Del Peso Navarro y Mar Del Peso Ruíz. Ref Lib [06] Pag. 575 La Auditoria se desglosa en:

• Auditoría de la organización y gestión del área de desarrollo y

mantenimiento

• Auditoría de la planificación y gestión del proyecto



• Auditoría de la fase de estudio de viabilidad

• Auditoría de la fase de análisis

• Auditoría de la fase de diseño

• Auditoría de la fase de construcción

• Auditoría de la fase de implantación

• Auditoría de la fase de mantenimiento

La metodología 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 prácticas y metodologías para su aplicación,

cuyo objetivo es facilitar el gobierno de las TIC (ITGI, 2007a y 2007b ). COBIT

está basado en la evaluación 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 Métrica versión 3 (MAP,

2007), se especifican uno o más objetivos de control de detalle o también

denominadas practicas de control, que contribuyen a lograr el cumplimiento de

dicho objetivo de control de alto nivel; para lo cual se ha basado también en la

propuesta de Rodero (2001). Así mismo, se aportan una serie pruebas de

cumplimiento que permitan comprobar la existencia y correcta aplicación de

dichos controles. Será la función del auditor determinar el grado de

cumplimiento y madurez de cada uno de ellos.



Capítulo III:

DESARROLLO DE LA

METODOLOGÍA



III. ASPECTOS GENERALES DE LA ENTIDAD 3.1. IDENTIFICACIÓN DE LA ENTIDAD AUDITADA El Gobierno Regional Cajamarca, al amparo de la Constitución Política del Estado y la Ley Nº 27867, Ley Orgánica de Gobiernos Regionales y modificatorias, es un organismo público con personería jurídica de derecho público, con autonomía política, económica y administrativa en asuntos de su competencia; constituyendo para su administración económica y financiera un pliego presupuestal.

3.2. Direccionamiento Estratégico

3.2.1 MISIÓN

El Gobierno Regional de Cajamarca, en cumplimiento de sus competencias exclusivas, compartidas y delegadas, contribuye al desarrollo integral y sostenible de la región, organizando y conduciendo democrática, descentralizada y desconcentradamente la gestión pública regional, en el marco de las políticas nacionales y sectoriales.

3.2.2 VISIÓN

Institución pública regional con identidad propia, capital humano calificado y nivel tecnológico avanzado, capaz de administrar y brindar con calidad recursos y servicios públicos, propiciar condiciones favorables para el desarrollo de la inversión privada y liderar procesos de concertación con la sociedad civil, en el marco de una efectiva lucha contra la pobreza y la defensa del medio ambiente y sus recursos.

3.3 Ubicación Geográfica 3.3.1 LOGO

Figura Nº11 Logo Institucional Fuente: Gobierno Regional Cajamarca

3.3.2 DIRECCIÓN

Jr. Santa Teresa de Journet 351- Urb. La Alameda Teléfonos: 599000 - 599001 - 599002



3.3.3 Vista Satelital

Figura Nº12 Vista Satelital del Gobierno Regional Cajamarca Fuente: Google Maps

3.3.4 Exteriores del Gobierno Regional

Figura Nº13 Exteriores del Gobierno Regional Cajamarca Fuente: Gobierno Regional Cajamarca

Gobierno Regional Cajamarca



3.4 ORGANIGRAMA

La estructura orgánica del Gobierno Regional Cajamarca, fue aprobada mediante la Ordenanza Regional Nº 020-2005-GR.CAJ-CR de fecha 18 de octubre del año 2005, de acuerdo con las disposiciones legales vigente y en amparo del artículo 9 inciso a) de la Ley Orgánica de Gobiernos Regionales Ley Nº 27867, donde se dispone que los Gobiernos Regionales son competentes para aprobar su organización interna.

Es necesario indicar que la actual estructura orgánica es el resultado de haber modificado la anterior que estuvo vigente el año 2005, dadas las condiciones y para un mejor funcionamiento del Gobierno Regional.



Figura Nº14 Estructura Orgánica del Gobierno Regional Cajamarca

Fuente: Gobierno Regional Cajamarca



3.5. ANÁLISIS DE LA ENTIDAD AUDITADA El Gobierno Regional Cajamarca cuenta con el Centro de Información y Sistemas, en el cual procesan toda la información necesaria para los Sistemas de Información, pero no figura en su Estructura Orgánica. Según nos relató el Director de dicha oficina; el Centro de Información y Sistemas (CIS) debería estar como una dependencia de la Gerencia de Desarrollo Social. Según Reglamento de Organización y Funciones (ROF) del Gobierno Regional Cajamarca. Artículo 92º

El Centro de Información y Sistemas cumple con las funciones siguientes:

a. Formular y evaluar el programa de Sistemas de Información, según las

necesidades del Gobierno Regional y sobre la base del soporte tecnológico informático.

b. Formular, ejecutar y evaluar los programas de control de software y

mantenimiento de los equipos de cómputo; y de contingencia. c. Ejecutar y participar en la ejecución de otros programas informáticos definidos

por la Alta Dirección del Gobierno Regional o por mandato de norma nacional expresa.

d. Mantener actualizado el Portal de Información del Gobierno Regional. e. Otras funciones que le sean asignadas. Fuente: Reglamento de Organización y Funciones, aprobado por Ordenanza Regional Nº 020 – 2005 GRCAJ- CR.

3.6 MARCO LEGAL DEL CENTRO DE INFORMACIÓN Y SISTEMA S

El Centro de Información y Sistemas del Gobierno Regional de Cajamarca es integrante del Sistema Nacional de Informática y se desarrolla acorde con los lineamientos, normas y recomendaciones técnicas de la Oficina Nacional de Gobierno Electrónico e Informática de la Presidencia del Consejo de Ministros. Incluyendo además las evaluaciones y seguimientos informáticos que realizan las Oficinas de la Contraloría, INDECOPI, y otros organismos reguladores y controladores. Por otro lado el CIS cuenta con la siguiente base legal:

1. Ordenanza Regional 020-2005-GR.CAJ-CR., que aprueba el Reglamento de Organización y Funciones del Gobierno Regional Cajamarca.

2. Resolución Ministerial Nº 073-2004-PCM, Guía para la Administración Eficiente del Software Legal en la Administración Pública.

3. El Centro de Información y Sistema forma parte del Sistema Nacional de Informática, con RESOLUCION MINISTERIAL Nº 206-2004-PCM se Constituyen el Padrón Nacional de Unidades Informáticas de la



Administración Pública y autorizan ejecución de registro de unidades informáticas del Sistema Nacional de Informática.

4. 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 Planificación Estratégica se definió la Misión, Visión de Futuro y Valores que orientarán al Centro de Información y Sistemas del Gobierno Regional de Cajamarca:

1.1. Misión

“Planificar, dirigir, ejecutar, supervisar y evaluar el empleo de equipos,

soporte, comunicaciones y sistemas de información; contribuyendo con el

Gobierno Regional de Cajamarca para que organice y conduzca la gestión

pública, en el marco de las políticas nacionales y sectoriales para contribuir

al desarrollo integral y sostenible de la región”.

1.2. Visión

“El Centro de Información y Sistemas, es capaz de utilizar tecnología de

última generación para proporcionar un servicio eficiente, confiable y

oportuno, generando confianza y transparencia en la ciudadanía. Así

mismo administra todos los recursos informáticos; propone y ejecuta

proyectos que simplifican los procesos administrativos, de planeamiento y

de evaluación de gestión institucional, que identifican a la institución como

una de las más eficientes y modernas”.

1.3. Principios de Conducta Ética

Constituyen principios de conducta ética del personal los siguientes:

a. Imagen

Todo el personal, deberá estar comprometido con el Centro de

Información y Sistemas; les corresponde como responsabilidad

conjunta, la promoción y preservación de su imagen positiva como

un valor que pertenece a todos, que es compartido y del cual se es

responsable por el sólo hecho de compartir un ideal común y ser un

miembro del CIS.

b. Integridad



El Personal del CIS deberá actuar con rectitud, honradez, y

honestidad, procurando satisfacer los intereses legítimos del

Gobierno Regional Cajamarca, 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 corrupción en todos los ámbitos de desempeño de la institución

y cumplir cabalmente con sus funciones.

c. Eficiencia

El personal del CIS brindará calidad en cada una de las labores a su

cargo, buscando el resultado más adecuado y oportuno.

d. Idoneidad

El personal del CIS, se desenvolverá con aptitud técnica, legal y

moral en el desempeño de su labor. Propenderá a una formación

sólida acorde a la realidad, capacitándose permanentemente para el

debido cumplimiento de sus labores.

e. Veracidad

El personal del CIS se expresará con autenticidad en las relaciones

laborales con todos los miembros del Gobierno Regional y con

terceros.

f. Lealtad y Obediencia

El personal del CIS actuará con fidelidad y solidaridad hacia toda la

Institución, cumpliendo órdenes que le imparta el superior jerárquico

competente, en la medida que reúnan las formalidades del caso y

tengan por objeto la realización 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 administración de la institución. Asimismo, actuará con reserva y

diligencia en el manejo de la información que conoce.

g. Justicia y Equidad

El personal del CIS, actuará con permanente disposición 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 ciudadanía en general.

Fuente: Plan Operativo Informático 2012



3.7 ESTRUCTURA ORGÁNICA INTERNA DEL CENTRO DE INFOR MACIÓN Y SISTEMAS

Figura Nº15 Estructura Orgánica del Centro de Información y Sistemas Fuente: Plan Operativo Informático

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

3.8 RECURSOS HUMANOS DEL CENTRO DE INFORMACIÓN Y SI STEMAS

RECURSOS HUMANOS CANTIDAD DIRECCIÓN O GERENCIA Jefe Asistente administrativo

1 1

REDES Y COMUNICACIONES Administrador de Red y Soporte 1 SISTEMAS Analista de Sistemas 1 Web Master 1 Programador de Aplicaciones 1 Diseñador de Interfaces 1 PLANEAMIENTO ESTRATÉGICO INFORMÁTICO Gestor de Proyectos Informáticos 1 Responsable de Investigación y Planeamiento 1 SOPORTE TECNICO Técnico Electrónico 2 Soporte Help Desk 1

TOTAL 12

Cuadro Nº01 Personal del CIS Fuente: Plan Operativo Informático

Director

Administrador Red Sistemas

Web Análisis y Desarrollo

Investigación y Gestión de Proyectos

Soporte Técnico

Apoyo Administrativo



3.9 PROBLEMÁTICA DEL CENTRO DE INFORMACIÓN Y SISTEM AS

La problemática actual del Centro de Información y Sistemas se presenta

mediante el análisis FODA, por medio de este análisis de Fortalezas,

Debilidades, Oportunidades y Amenazas, se obtendrá un diagnóstico que

permitirá tomar decisiones acordes con los objetivos y políticas que

formularemos.

SITUACION ACTUAL DESCRIPCION

Fortalezas a utilizar

F1. Elaboración del Plan Operativo Informático 2012. F2. Personal identificado con el CIS. F3. Coordinación permanente con los diferentes usuarios. F4. Equipo de trabajo eficiente y eficaz. F5. Capacidad de asesoramiento permanente en relación a sistemas informáticos y sus aplicaciones. F6. Implementación de los sistemas de información mediante el desarrollo de software personalizado. F7. Infraestructura física acorde a las exigencias del área. F8. Uso y administración del portal web, que permite fortalecer la imagen institucional. F9. Deseo e iniciativa del personal informático en actualizarse en las nuevas tecnologías informáticas. F10.Mejoramiento de la Red de Datos y Telefónica. F11. Promoción del intercambio de información con la Implementación de MAD y MOD a nivel Regional.

Principales Oportunidades para

aprovechar

O1. Decisión institucional para modernizar y estandarizar tecnológicamente el gobierno regional. O2. Adecuación de Data Center y Red de Cómputo de la Sede del Gobierno Regional Cajamarca (Proyecto Gobierno Electrónico). O3. Desarrollo tecnológico que ofrece nuevas oportunidades para lograr mayor eficiencia. O4. Disponibilidad de software en el mercado para la implementación del requerimiento de aplicaciones. O5. Existencia de normatividad estadística e informática a nivel nacional que sirve de referencia para un normal desarrollo de las actividades informáticas. O6. Tendencia a un Modelo de Gobierno Electrónico. O7. Existencia de entidades públicas como INDECOPI, Contraloría, MEF. O8. Potencial productivo que ofrece internet.

Principales Debilidades a superar

D1. Uso de software no licenciado. D2.Falta de equipos de contingencia para continuidad de servicios críticos. D3. El CIS no figura dentro de la Estructura Orgánica del Gobierno Regional.



Principales Amenazas a neutralizar

A1. Situación económica del País, que se expresa en el escaso presupuesto para la adquisición de equipos de cómputo y Licencias de software. A2. Constante amenazas de virus informáticos, correos maliciosos; en la red. A3. Creciente demanda por servicios informáticos relacionados a consultas masivas. A4. La realidad del crecimiento tecnológico trae como consecuencia la obsolescencia de los equipos de cómputo. A5. Débil planificación nacional en el ámbito informático debido a la falta de integración del sector público. A6. Alto costo de software. A7. Inestabilidad laboral. A8. Desconocimiento por parte del personal del Gobierno Regional Cajamarca acerca del Rol que cumple el CIS.

Cuadro Nº02 Análisis FODA - CIS

Fuente: Plan Operativo Informático

3. 10 Alineamiento con el Plan Estratégico Instituc ional y Sectorial

Las acciones que pretende realizar el Centro de Información y Sistemas se

encuentran alineadas con el Plan Estratégico Sectorial Multianual (PESEM

2007-2011) de la Presidencia del Consejo de Ministros (PCM), aprobado

mediante Resolución Ministerial N° 281- 2007 – PCM :

OBJETIVO ESTRATÉGICO

SECTORIAL

OBJETIVOS INSTITUCIONALES

OBJETIVOS ESPECIFICOS

INFORMÁTICOS 1. Lograr un estado moderno, eficaz y eficiente que responda a las necesidades de la ciudadanía.

a) Contribuir con el incremento de las capacidades de las personas, facilitando la igualdad de oportunidades para la población; impulsando la mejora de la calidad y cobertura de los servicios públicos de educación, salud, saneamiento y la asistencia social, así como la reducción del analfabetismo y la desnutrición infantil y fomentando el desarrollo de la ciencia, la tecnología y la cultura en la Región. b) Lograr niveles de eficiencia y transparencia, en la gestión pública regional, institucionalizando estrategias de rendición de cuentas, facilitando el acceso a la

a.1 Mejorar la gestión pública y propiciar la descentralización del estado mediante el uso intensivo de las tecnologías de la información y comunicación. b.1. Promover el incremento de capacidades competitivas en la Administración Pública, empresas y ciudadanos por medio del uso de las tecnologías de la



información pública y promoviendo la vigilancia y auditoria social. c) Contribuir con la integración de la Región Cajamarca desarrollando la articulación vial, eléctrica, de telecomunicaciones; implementando estrategias de coordinación y cooperación con instituciones públicas y privadas; revalorando la identidad regional y fortaleciendo la Concertación y cooperación interregional a todo nivel.

información. b.2. Fortalecimiento del Órgano Institucional. b.3. Fortalecimiento del Órgano Informático Institucional. c.1.Optimizar el flujo de la información de los sistemas y la comunicación de las estaciones de la red interna a través del mejoramiento, estandarización y actualización de los elementos que conforman la red institucional

Cuadro Nº03 Alineamiento con el Plan Estratégico Institucional y Sectorial

Fuente: Plan Operativo Informático

3.11 Estrategias para el logro de las metas del Pla n Operativo Informático

Las siguientes son las principales estrategias planteadas de acuerdo a las

diferentes necesidades tecnológicas por las que atraviesa el Gobierno Regional

Cajamarca

1. Mejorar la disponibilidad de herramientas tecnológicas.

2. Desarrollar la infraestructura tecnológica.

3. Generar rentabilidad de forma sostenible en el desarrollo de proyectos

informáticos.

4. Analizar requerimientos funcionales para incorporarlos a la cadena de

valor midiendo el avance hacia sus objetivos.

5. Disponer de personal de sistemas con nivel competitivo y asegurar que

dicho nivel se mantenga.

6. Llevar a cabo el cumplimiento de normativas como ente del Sistema

Nacional de Informática.

7. Desarrollar programas de capacitación continua a los usuarios

8. Fortalecer las actividades y procesos del Gobierno Regional Cajamarca.

9. Mejorar la atención a los usuarios

10. Desarrollar sistemas de información.

11. Reducir la vulnerabilidad de la red.

12. Integrar por medio de una base de datos institucional los procesos dentro

del GRC.



3.12 APLICACIÓN DE AUDITORIA DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN EN EL CENTRO DE

INFORMACIÓN Y SISTEMAS

3.12.1 AUDITORÍA DE LA ORGANIZACIÓN Y GESTIÓN DEL ÁREA DE SISTEMAS

3.12.2 Objetivo de Control OG1: Procesos, organización y relaciones: El área de

sistemas debe tener definidos los procesos de su organización.

SI NO Observaciones

OG1-C1: Deben establecerse de forma clara las funciones del área.

• Existe algún documento que contiene las

funciones que son competencia del centro de

información y sistemas, está aprobado y se

respeta.

X

OG1-C2: Debe especificarse en el organigrama puestos del área y el staff.

• Existe un organigrama con la estructura de

organización del área.

X

OG1-C3: Debe establecerse el marco de trabajo de los procesos del área de sistemas, de modo que permita la ejecución y puesta en práctica del plan operativo informático.

• EI marco de trabajo permite la definición y

seguimiento de los objetivos de los procesos que

han sido definidos e implementados, así como

formalmente documentados y aprobados.

X

OG1-C4: Deben establecerse roles y responsabilidades para la gestión del aseguramiento de la calidad, gestión 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.

X

• Las responsabilidades y roles han sido

correctamente establecidos, formalizados,

documentados y satisfacen los requisitos del área.

Son ejecutados por personal con la suficiente

formación y experiencia en la materia.

X

3.12.3 Objetivo de Control OG2: Gestión de Recursos Humano s: El área de sistemas debe contar con recursos humanos adecuados para gestionar el desarrollo y



mantenimiento de SI.

OG2-C1: Deben existir procedimientos de contratación objetivos.

• Las ofertas de puestos del área se difunden de

forma suficiente fuera de la organización y las

selecciones del personal se hacen de forma

objetiva.

X

• Las personas seleccionadas cumplen los

requisitos del puesto al que acceden.

X

OG2-C2: Debe existir un plan de capacitación que este en consonancia con los objetivos del área y alineados con los objetivos institucionales.

• Se tiene aprobado un plan de capacitación a corto,

medio y largo plazo que sea coherente con el plan

operativo informático

X

OG2-C3: Debe existir una biblioteca accesible por el personal del área.

• Están disponibles un número suficiente de libros,

publicaciones periódicos, monografías de

reconocido prestigio, ya sea en formato electrónico

o papel. El personal tiene acceso a ellos.

X

OG2-C4: El personal debe estar motivado en la realización de su trabajo.

• Existe algún mecanismo que permita a los

empleados hacer sugerencias sobre mejoras en la

organización del área.

X

• No existe una gran rotación de personal, existe un

buen ambiente de trabajo.

X

3.12.4 Objetivo de Control OG3: Plan Estratégico de Tecnologías de la Información del área: El área de sistemas debe participar en la definición del plan estratégico de Tecnologías de la Información

OG3-C1: el área debe tener y difundir su propio plan a corto, medio y largo plazo.

• Existe el plan estratégico de Tecnologías de la

Información.

X

• Se revisa y actualiza con periodicidad en función

de las nuevas situaciones.

X

• Se difunde a todo el staff para que se sientan X



participes del mismo.

OG3-C2: La realización de nuevos proyectos debe basarse en el plan estratégico de Tecnologías de la Información y en el plan operativo informático en cuanto a objetivos, marco general.

• Las fechas de realización coinciden con las del

plan estratégico.

X

• La documentación relativa a cada proyecto que

existe en el plan estratégico se pone a disposición

del director de proyecto una vez comenzado el

mismo. Esta información debe contener los

objetivos, los requisitos generales y un plan inicial.

X

3.12.5 Objetivo de Control OG 4: Gestión de la calidad: El área de sistemas debe disponer de procesos de desarrollo regidos por estándares y principios de ingeniería 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 catálogo de problemas, incluyendo para

cada uno de ellos la solución o soluciones

encontradas, proyecto en el que sucedió, persona

que lo resolvió.

X

• EI catálogo es accesible para todos los miembros

del área, esta actualizado y tiene uno o varios

índices que faciliten la búsqueda.

X

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

X

OG4-C2: Debe mantenerse y comunicarse periódicamente al área las modificaciones del plan de calidad a fin de promover la mejora continua.

• El plan existe y se actualiza periódicamente. X

• Existen y se ejecutan actividades de mejora

continua según los estándares, prácticas,

procedimientos y políticas de calidad del

departamento adoptadas por el área de sistemas.

X

OG4-C3: Debe existir algún mecanismo de creación y actualización de prácticas y



estándares de calidad así como de prácticas, estándares de desarrollo y mantenimiento.

• EI mecanismo para la creación y actualización de

prácticas y estándares está documentado y es

conocido en el área.

X

• Están definidas las prácticas de análisis y diseño,

e incluye las técnicas y herramientas a usar. Así

como también hay una guía o prácticas de

programación para cada uno de los lenguajes

homologados

X

• Hay un estándar general para toda la

documentación generada, incluyendo

documentación técnica (análisis, diseño,

documentación de los programas), manuales de

usuario, etc.

X

OG4-C4: Debe existir un procedimiento de monitorización y medición del cumplimiento de estándares y prácticas de calidad así como de los de desarrollo y mantenimiento.

• Se realizan informes ejecutivos periódicamente

sobre la calidad de los SI en el área.

X

• Están definidas métricas de calidad y éstas están

alineadas con los objetivos de calidad del área y

ayudan en la consecución de los objetivos del

área.

X

• Se realizan inspecciones en los hitos de los

proyectos para verificar el cumplimiento de los

estándares y prácticas.

X

OG4-C5: Debe practicarse la reutilización del software.

• Existe un repositorio con todos los productos

software susceptibles de ser reutilizados: librerías

de funciones, clases de objetos, componentes

software, documentos (catálogo de requisitos

comunes, arquitecturas).

X

• EI repositorio o catálogo es conocido y accesible

por todos los miembros del área, esta actualizado

y tiene uno o varios índices que faciliten la

X



búsqueda.

OG4-C6: Debe existir un modelo de la arquitectura de información que se actualice regularmente y defina los sistemas apropiados que optimicen el uso de la información.

• Existe un diccionario de datos institucional con las

reglas de sintaxis de la organización, el esquema

de clasificación de datos y sus niveles de

seguridad correspondientes.

X

• Se garantiza la consistencia y seguridad de la

información de los SI con los recursos

proporcionales y dicha información se alinea con la

estrategia y objetivos de la institución.

X

OG4-C7: Los lenguajes, compiladores, software de pruebas, software de control de versiones; utilizados en el área deben ser previamente válidos.

• Existe un mecanismo para la adquisición y

validación de cualquier nuevo producto software

usado en el desarrollo. Se deben evaluar al menos

los siguientes parámetros: productividad,

portabilidad a otros entonos, transición desde los

productos actuales, riesgo de cambio,

cumplimiento de los estándares del área,

compatibilidad con el entono tecnológico, costos,

entre otros.

X

• Cuando se valida un nuevo producto de desarrollo

se forma al personal del área que lo vaya a

manejar.

X

• Se registra la información más importante acerca

de la configuración de los productos recién

adquiridos.

X

Tabla N° 05: Auditoría de la organización y gestión del área de sistemas

Fuente: Propia



3.13 AUDITORÍA DE PROYECTOS DE DESARROLLO Y MANTENIMIENTO

3.13.1 Auditoria de la gestión y planificación del proyect o

SI NO Observaciones

3.13.2 Objetivo de Control P1: El proyecto de desarrollo debe estar aprobado, definido y planificado formalmente.

P1-C1: Debe existir documento de aprobación del proyecto que defina claramente los objetivos, restricciones y las áreas afectadas.

• Existe algún documento de aprobación del

proyecto autorizada por algún órgano competente.

X

• En el documento de aprobación están definidos de

forma ciara y precisa los objetivos del mismo y las

restricciones de todo tipo que deben tenerse en

cuenta (recursos técnicos y humanos,

presupuesto, entre otros.) y su alineación con el

plan estratégico.

X

• Se han identificado las unidades de la

organización a las que afecta.

X

P1-C2: Debe designarse un responsable o director del proyecto.

• La designación se ha llevado a cabo según el

procedimiento establecido.

X

• Se le ha comunicado al director su designación

junto con toda la información relevante del

proyecto.

X

P1-C3: El proyecto debe ser catalogado en función de sus características, se debe determinar el modelo de ciclo de vida que seguirá.

• Se ha descrito y dimensionado el proyecto según

las normas establecidas.

X

• Se han evaluado los riesgos asociados al

proyecto, especialmente cuando se van a usar

tecnologías no usadas hasta el momento.

X

• Se ha elegido el ciclo de vida más adecuado al

tipo de proyecto.

X

• Se ha hecho uso de la información histórica que se

dispone tanto para dimensionar el proyecto y sus

riesgos como para seleccionar el ciclo de vida.

X



P1-C4: Una vez determinado el ciclo de vida a seguir, se debe elegir el equipo técnico que realizará el proyecto y se determinará el plan del proyecto.

• La designación del equipo de desarrollo se ha

llevado a cabo según el procedimiento establecido.

X

• Se ha comunicado a todos los miembros del staff

de desarrollo los objetivos del proyecto, la

responsabilidad que tendrán en el mismo, las

fechas en las participaran y la dedicación completa

o parcial.

X

• EI plan de proyecto realizado es realista y utiliza la

información histórica de la que se disponga para

realizar estimaciones.

X

3.13.3 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 aéreas afectadas por el proyecto deben participar en la gestión del proyecto.

• Se ha constituido formalmente el comité de

dirección del proyecto y están incluidos los

responsables de todas las unidades afectadas.

X

• EI comité tiene una periodicidad de reunión

mínima, y en cualquier caso siempre que lo exija el

desarrollo del proyecto, debe tener competencia

para asignación de recursos, la revisión de la

marcha del proyecto y para modificar el plan del

proyecto en función de las revisiones.

X

• Las reuniones se hacen con un orden del día

previo y las decisiones tomadas quedan

documentadas en las actas de dicho comité.

X

• EI número de reuniones y la duración de las

mismas no superan un límite razonable

comparado con la envergadura del proyecto.

X

P2-C2: Se debe establecer un mecanismo para la resolución de los problemas que pueden surgir a lo largo del proyecto.



• Existen hojas de registro de problemas y hay

alguna persona del proyecto encargada de su

recepción, así como un procedimiento conocido de

tramitación.

X

• Existe un método 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

dirección.

X

• Se controla la solución del problema y se deja

constancia del mismo.

X

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.

X

• La documentación afectada se actualiza de forma

adecuada y se !leva un control de versiones de

cada producto, consignando la ultima fecha de

actualización.

X

• Se remite la nueva versión de los documentos

actualizados a los participantes en el proyecto.

X

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 límites temporales y

presupuestarios marcados al inicio del proyecto. Si

no es así debe ser aprobado por el comité de

dirección.

X

• Se ha tenido en cuenta los riesgos del reajuste. X

• Se ha hecho uso de la información histórica que se

dispone en el área sobre estimaciones.

X

• 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 algún procedimiento que permite registrar el X



tiempo que dedica y qué tarea realiza cada

participante.

• Existe algún procedimiento para analizar las

desviaciones y proponer acciones correctivas.

X

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 metodología usada.

• Antes de comenzar una nueva etapa, se ha

documentado la etapa previa y se ha revisado y

aceptado, especialmente en las fases de análisis y

diseño.

X

• La documentación cumple los estándares y

procedimientos establecidos en el área.

X

• Se respeta el uso de recursos previamente

establecido.

X

P2-C7: Cuando termina el proyecto se debe cerrar toda la documentación del mismo, liberar los recursos utilizados y hacer balance.

• La documentación del proyecto es completa y está

catalogada perfectamente para accesos

posteriores.

X

• Los recursos, tanto personales como materiales,

se ponen a disposición del área del que provienen.

X

• El comité de dirección y el director del proyecto

hacen balance del proyecto, estudiando los

posibles problemas y sus causas, los cambios del

plan. Toda esta información se registra en los

archivos históricos sobre estimaciones y

problemas.

X

Tabla N° 06: Auditoría de proyectos de desarrollo y mantenimiento

Fuente: Propia


60

3.14 AUDITORÍA DE LA FASE DE ESTUDIO DE VIABILIDAD

SI NO Observaciones

3.14.1 Objetivo de Control V1: Antes de la definición del proyecto deben estudiarse los requisitos, situación actual, identificando seguidamente las alternativas de solución y seleccionando aquella que satisfaga más 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 descripción

general de la necesidad planteada por el usuario y

los objetivos generales así como las posibles

restricciones técnicas, operativas y económicas.

X

• Se han determinado formalmente el grupo de

usuarios que participará en el proyecto,

identificándose sus perfiles y dejando claras sus

tareas y responsabilidades.

X

V1-C2: Debe estudiarse la situación actual y determinar los sistemas afectados.

• Se han realizado modelos del sistema. X

• Se ha realizado un diagnóstico de la situación

actual.

X

V1-C3: Los usuarios y responsables de las unidades que afecta el nuevo sistema establecerán 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

cómo valoran el sistema actual y lo que esperan

del nuevo sistema.

X

• Existe un catálogo de requisitos. Cada requisito

tiene una prioridad y está clasificado en funcional y

no funcional.

X

• EI catálogo de requisitos ha sido revisado y

aprobado por el grupo de usuario y los

responsables así como por el comité de dirección.

X


61

3.15 AUDITORIA DE LA FASE DE ANÁLISIS

3.15.1 Objetivo de Control A1: Se debe elaborar una especificación detallada que

permita describir con precisión el sistema de información.

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 información necesaria.

• Las técnicas que se utilizan para la recopilación de

información es la adecuada en función de las

características del proyecto y los tipos de usuario a

entrevistar.

X

• Se remite el guión a los entrevistados con tiempo

suficiente para que estos puedan preparar la

entrevista y la documentación que deseen aportar

a la misma. Y el guión incluye todas las cuestiones

necesarias para obtener la información sobre las

funciones deseadas y problemas que se quieren

resolver.

X

A1-C2: A partir de la información obtenida de las entrevistas se debe realizar la descripción inicial del SI y obtener el catálogo de requisitos detallado del mismo.

• Existe un catálogo de requisitos, estos están

justificados y detallados.

X

• Cada requisito tiene una prioridad y están

clasificados en funcionales y no funcionales.

X

• La especificación del sistema incluye los requisitos

no funcionales: de seguridad, rendimiento,

disponibilidad, formación.

X

A1-C3: Se estructura el sistema de información en subsistemas de análisis, para facilitar la especificación de los distintos modelos y la traza de requisitos.

• La desintegración de los subsistemas está

orientada a los procesos del sistema.

X

• Se han asignado los requisitos a cada uno de los

subsistemas identificados, y consecuentemente

actualizado el catálogo de requisitos.

X

A1-C4: Se debe realizar el modelo del sistema que sirva de base para el diseño. En el caso de análisis estructurado, mediante la elaboración y descripción detallada del modelo de datos y de procesos. Y en el caso de un análisis orientado a objetos a través del modelo de clases y el de interacción de objetos, mediante el análisis de los


62

casos de uso.

• Los modelos son correctos técnicamente y se han

realizado con la técnica adecuada.

X

• Existe un diccionario de datos o repositorio, es

correcto y se gestiona de forma de automatizada,

respetándose todos los procedimientos de gestión

de cambios.

X

A1-C5: Se deben especificar todas las interfaces entre el sistema y el usuario, tales como formatos de pantallas, diálogos, formatos de informes y formularios de entrada.

• Se han descrito con suficiente detalle las

interfaces: pantallas a través de las cuales el

usuario navegará por la aplicación, incluyendo

todos los campos significativos, menús, botones,

etc.; así como informes y formularios asociados si

existen. Si hay normas de diseño o estilo de

pantallas, informes, formularios, etc. en el área, se

verificará que se respetan.

X

• La interfaz de usuario se ha aprobado por el grupo

de usuarios y por el comité de dirección.

X

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.

X

• Se ha elaborado el plan de pruebas de aceptación

del sistema, éste es coherente con el catálogo de

requisitos y con la especificación funcional del

sistema.

X

3.15.2 Objetivo de Control A2 : Se debe garantizar la calidad de los distintos modelos generados en el proceso de análisis del SI, y asegurar que los usuarios y los analistas tienen el mismo concepto del sistema.

A2-C1: Se debe de verificar la calidad técnica de cada modelo y asegurar la coherencia entre los distintos modelos.

• La calidad formal de los distintos modelos,

comprobando si son conforme a la técnica seguida

X


63

para la elaboración de cada producto y a las

normas determinadas en el catálogo de normas.

• Se ha realizado una validación de los distintos

modelos con los requisitos especificados para el

sistema de información, tanto a través del catálogo

de requisitos, mediante la traza de requisitos,

como a través de la validación directa del usuario.

X

A2-C2: Debe realizarse una validación formal de la especificación de requisitos y de los modelos del análisis del sistema.

• Los usuarios ratifican que los requisitos

especificados en el catálogo de requisitos, así

como los casos de uso son validos, consistentes y

completos.

X

• Cualquier petición de cambio en los requisitos que

pueda surgir posteriormente deben ser evaluada y

aprobada.

X

• La actualización del plan de proyecto seguirá los

criterios, detallándose en este punto en mayor

medida la entrega y transición al nuevo sistema.

X

3.16 AUDITORIA DE LA FASE DE DISEÑO

3.16.1 Objetivo de Control D1: Se debe definir una arquitectura del sistema que sea coherente con la especificación funcional que se tenga y con el entorno tecnológico. D1-C1: organización en subsistemas de diseño, la especificación del entono tecnológico, requisitos de operación, administración, seguridad y control de acceso deben estar definidos de forma clara y ser conformes a los estándares y normas del centro de información y sistemas.

• Están diferenciados y definidos los subsistemas

específicos del sistema de información (en

adelante, subsistemas específicos) y los

subsistemas de soporte.

X

• Están definidos todos los elementos que

configuran el entorno tecnológico (servidores, PC,

periféricos, conexiones de red, sistemas gestores

de bases de datos) junto con su planificación de

capacidades y sus requisitos de operación,

X


64

administración, seguridad y control de acceso.

• Existe un catálogo de excepciones, de requisitos,

normas y estándares originados como

consecuencia de la adopción de una determinada

solución de arquitectura o infraestructura.

X

• Los elementos seleccionados están dentro de los

estándares del área y son capaces de responder a

los requisitos establecidos de volúmenes, tiempos

de respuesta, seguridad.

X

D1-C2: Se debe realizar un diseño detallado de los subsistemas de soporte y del sistema de información específico.

• Se han identificado los mecanismos genéricos de

diseño, así como las librerías y clases reutilizables.

X

• EI tamaño de los módulos o clases es adecuado y

el factor de acoplamiento entre ellos es mínimo y

la cohesión interna es máxima.

X

• Los módulos o clases, se diseñan para poder ser

reutilizados en el futuro por otros SI.

X

D1-C3: Se debe diseñar la estructura de datos adaptando las especificaciones del sistema al entorno tecnológico.

• EI modelo de datos tiene en cuenta el entorno

tecnológico y los requisitos de rendimiento para los

volúmenes y frecuencias de acceso estimados,

migración de datos.

X

3.16.2 Objetivo de Control D2: Se deben generar todas las especificaciones necesarias para la construcción del sistema de información:

D2-C1: Se deben generar unas especificaciones de construcción.

• Se han fijado formalmente las directrices para la

construcción de los componentes del sistema, así

como de las estructuras de datos.

X

D2-C2: Se debe especificar el procedimiento de migración y carga inicial de datos así como los requisitos de operación.

• Se definen los procedimientos de migración y sus

componentes asociados, con las especificaciones

X


65

de construcción oportunas.

• Se definen los requisitos relativos a la propia

formación del sistema en el entorno de operación y

aquellos relacionados con la documentación que el

usuario requiere para operar con el nuevo sistema.

X

D2-C3: Debe realizarse la especificación técnica del plan de pruebas.

• Existe el plan de pruebas y contempla todos los

recursos necesarios para llevarlas a efecto.

X

• Es adecuado para validar cada uno de los

componentes del sistema, incluyendo pruebas de

caja blanca. Tendrán en cuenta las posibles

condiciones lógicas de ejecución, además de

posibles fallos del hardware o software de base y

ataques de seguridad.

X

• Permite validar la integración de los distintos

componentes y el sistema en conjunto.

X

D2-C4: Se debe realizar una aprobación formal del diseño del sistema.

• Se realiza la presentación del diseño al comité de

dirección y se registra la aprobación del mismo.

X

• Se actualiza el plan de proyecto según los criterios

de dirección y se registra la aprobación del mismo.

X

3.17 AUDITORIA DE LA FASE DE CONSTRUCCIÓN

3.17.1 Objetivo de Control CS -1: Los componentes que se desarrollen deben utilizar técnicas de programación correctas

CS1-C1: Se debe preparar adecuadamente el entorno de desarrollo y de pruebas, así como los procedimientos de operación y seguridad.

• Se han creado e inicializado las bases de datos o

ficheros necesarios y cumplen las especificaciones

de construcción del sistema obtenidas en la fase

de diseño.

X

• Se han preparado los editores, compiladores,

herramientas necesarias y están disponibles los

puestos de trabajo.

X


66

• Se han preparado los procedimientos de copia de

seguridad y restauración.

X

• Están disponibles todos los elementos lógicos y

físicos para realizar las pruebas unitarias y de

integración.

X

• Están documentados todos los procedimientos de

operación, seguridad y control de acceso al SI

para cuando el sistema este en explotación. Y

estos procedimientos tienen en cuenta los

estándares y normas del departamento de

informática, recogidos previamente en el catálogo

de normas y estándares.

X

CS1-C2: Se debe programar, probar y documentar cada uno de los componentes identificados en el diseño del sistema.

• Se han desarrollado todos los componentes y se

han seguido los estándares, normas de

programación y documentación del área (código

comentado y documentado).

X

• Se ha probado cada componente de forma unitaria

siguiendo el plan de pruebas y se ha generado el

informe de prueba.

X

• Se ha realizado la codificación, prueba de los

componentes y procedimientos de migración y

carga inicial de datos.

X

CS1-C3: Deben realizarse las pruebas de integración para verificar si los subsistemas interactúan correctamente a través 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

según lo especificado en el plan de pruebas.

X

• Se han evaluado las pruebas y se han tomado las

acciones correctoras necesarias para solventar las

incidencias encontradas, actualizándose el

proyecto en consecuencia.

X

CS1-C4: Deben realizarse las pruebas de sistema para comprobar la integración del sistema de información globalmente.


67

• Las pruebas verifican el funcionamiento correcto

de las interfaces entre los distintos subsistemas

que lo componen y con el resto de sistemas de

información con los que se comunica, así como el

cumplimiento de la especificación de requisitos, de

acuerdo a las verificaciones establecidas en el

plan de pruebas para el nivel de pruebas del

sistema.

X

• Se ha generado un informe de pruebas de sistema

y se han evaluado las pruebas y tomándose las

acciones correctoras necesarias para solventar las

incidencias encontradas, actualizándose el

proyecto en consecuencia.

X

• No han participado los usuarios, solo participó el

equipo de desarrollo.

X

3.17.2 Objetivo de Control CS -2: Los proyectos de desarrollo deben definir los

procedimientos y formación 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

necesarios.

X

• Los procedimientos se han realizado después de

la especificación del SI y antes de su formación.

X

CS2-C2: Se deben especificar los perfiles de usuario requeridos para el nuevo sistema.

• Están definidos los distintos perfiles de usuario

requeridos para la formación y explotación del

nuevo sistema.

X

• Para cada perfil se ha definido el rango de fechas

y la dedicación necesaria

X

CS2-C3: Se deben desarrollar todos los procedimientos de usuario siguiendo los estándares del área.


68

• Están desarrollados todos los procedimientos de

usuario, recopilados formando el manual de

usuario, y son coherentes con las actividades

descritas en la especificación del sistema.

X

• Los manuales de usuario y el resto de

procedimientos cumplen los estándares del área y

llevan asociado su control de versiones.

X

3.18 AUDITORIA DE LA FASE DE IMPLANTACIÓN Y ACEPTACIÓN.

3.18.1 Objetivo de Control IA -1: El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en explotación.

IA1-C1: El plan de formación y aceptación se debe revisar para adaptarlo a la situación final del proyecto.

• Se revisa el plan de formación original y se

documenta adecuadamente.

X

• Se establece un plan de formación con la

implantación necesaria para el equipo de

formación, en función de los distintos perfiles y

niveles de responsabilidad identificados y se

cuenta con la infraestructura y recursos humanos

para llevarla a cabo.

X

• Esta incluida la instalación de todos los

componentes desarrollados, así como los

elementos adicionales (formación, librerías,

utilidades).

X

IA1-C2: Se deben realizar las pruebas de formación y aceptación del sistema que se especificaron en fases anteriores.

• Se prepara el entorno real de operación y los

recursos necesarios para realizar las pruebas

X

• Las pruebas de formación del sistema participan

los usuarios y con ellas se verifica si el SI cumple

las especificaciones funcionales así como detalles

de diseño interno, como interactúa correctamente

con el entorno.

X

• Se han evaluado los resultados de las pruebas y X


69

se han tornado las acciones correctoras

necesarias para solventar las incidencias

encontradas, actualizándose el proyecto en

consecuencia.

IA1-C4: El sistema debe ser aprobado formalmente antes de ponerse en explotación.

• Se ha realizado las pruebas de formación y

aceptación.

X

• Se ha fijado el acuerdo de nivel de servicio. X

• El grupo de usuarios y el comité de dirección

firman su conformidad.

X

3.18.2 Objetivo de Control IA -2: El sistema se pondrá en explotación formalmente y pasará a estar en mantenimiento sólo cuando haya sido aceptado y esté preparado todo el entorno el que se ejecutará.

IA2-C1: Se deben instalar todos los procedimientos de explotación.

• Se han instalado además del sistema principal

todos los procedimientos auxiliares, como copias,

recuperación, etc., tanto manual como automático.

X

• Están documentados de forma correcta. X

• Los usuarios finales han recibido la formación

necesaria y tienen en su poder toda la

documentación necesaria, fundamentalmente

manuales de usuario.

X

• Se han eliminado procedimientos antiguos que

sean incompatibles con el nuevo sistema.

X

IA2-C2: Si existe un sistema antiguo, el sistema nuevo se pondrá en explotación 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 este

funcionando con todas las garantías. Esta

situación no debe prolongarse más tiempo del

necesario.

X

• Los datos se convierten de acuerdo al

procedimiento desarrollado y se verifica la

X


70

consistencia de la información entre el sistema

nuevo y et antiguo.

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 dirección y

por el área de desarrollo y mantenimiento.

X

• Tiene en cuenta los tiempos de respuesta

máximos que se pueden permitir ante situaciones

de no funcionamiento.

X

• EI procedimiento a seguir ante cualquier problema

o para el mantenimiento del sistema será conocido

por todos los usuarios.

X

3.19 AUDITORIA DE LA FASE DE MANTENIMIENTO

3.19.1 Objetivo de Control M -1: La gestión del proceso de mantenimiento de

sistemas de información 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 gestión del mantenimiento de los SI del área y de infraestructura tecnológica.

• El plan existe y está aprobado por la dirección del

área y se revisa periódicamente.

X

• EI plan acordado es compatible con el proceso de

gestión de cambios y de problemas.

X

• Existe un procedimiento definido y acordado por

todas las áreas participantes en el plan de

mantenimiento a fin de facilitar que la gestión de

los cambios o ejecución de las peticiones de

mantenimiento así como gestión de los problemas

de los SI se haga de una manera eficaz y

eficientemente.

X

3.19.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 producción, deben de ser gestionados formalmente y de una manera controlada a fin de asegurar


71

la mitigación del riesgo debido a los impactos negativos en la estabilidad e integridad del SI en producción.

M2-C1: Se debe establecer un sistema estandarizado de registro de información 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 gestión efectiva del mantenimiento.

• Existe un catalogo de problemas y de peticiones

de mantenimiento sobre los sistemas de

información.

X

• Todas las peticiones de mantenimiento son

presentadas de una forma estandarizada, para

permitir su clasificación y facilitar la identificación

del tipo de mantenimiento requerido.

X

• En cada petición de cambio se recoge al menos la

identificación, origen y tipo de petición, se le

asigna una prioridad inicial y se le incorpora una

descripción, lo más precisa posible, que facilite su

posterior análisis.

X

• Para cada petición 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

mantenimiento.

X

M2-C2: Se debe llevar a cabo un diagnóstico y análisis del cambio para dar respuesta a las peticiones de mantenimiento que son aceptadas.

• La información registrada es la correcta. X

• Si se trata de una petición de mantenimiento

correctivo, se evalúa hasta qué punto es crítico el

problema. Si el problema es crítico, su análisis y

solución comienza inmediatamente con el fin de

reanudar rápidamente el nivel de servicio. Y el

procedimiento de actuación establecido no exime

de una revisión posterior del problema para valorar

los posibles efectos secundarios, establecer una

solución definitiva y actualizar todos los productos

implicados y su documentación.

X


72

M2-C3: Se realiza el seguimiento de los cambios que se están llevando a cabo en los procesos de desarrollo, de acuerdo a los puntos de control del ciclo de vida del cambio establecidos previamente.

• Sólo se han modificado los elementos que se ven

afectados por el cambio y que se han realizado las

pruebas correspondientes, especialmente las

pruebas de integración y del sistema.

X

• Se realiza un informe de la evaluación del cambio

para su posterior aprobación.

X

• Se realizan las pruebas de regresión que

especificadas en la actividad anterior,

comprobando que ningún sistema no modificado,

pero con posibilidades de verse afectado, ha

variado su comportamiento habitual.

X

• La aprobación de la petición se realiza al finalizar

las pruebas de regresión, y después de comprobar

que todo lo que ha sido modificado o puede verse

afectado por el cambio, funciona correctamente.

X

Tabla N° 07: Auditoría de la fase de estudio de viabilidad, fase análisis, fase diseño, construcción, implantación, aceptación y mantenimiento

Fuente: Propia


73

Capítulo IV:

ANÁLISIS DE RESULTADOS


74

IV. RESULTADOS Y DISCUSIÓN

4.1 Pregunta N° 01

Grafico N° 01. Auditorias anteriores.

Fuente: Elaboración propia

En el gráfico N°01, muestra que el Centro de información y sistemas (CIS), del

Gobierno Regional Cajamarca, entre las fechas comprendidas de Enero del 2011 a

Julio del 2012, no ha sido auditado. Ello significa que no tienen procedimientos de

control interno, como garantía para una gestión eficaz orientada a la consecución

de los objetivos.

4.2 Pregunta N° 02 Grafico N° 02. Documentación de funciones.


100%

¿El Centro de Información y Sistemas ha sido auditado con anterioridad (cualquier tipo de

auditoria)?

a)SI b)NO c)No Sabe No Opina

100%

¿Existe algún documento que establece en forma clara las funciones del área?



75

En el gráfico N°02 muestra que existe, este documento es el ROF (Reglamento de

Organización y Funciones) el cual se constituye en un documento técnico normativo

de gestión institucional que establece entre otras: Las funciones generales y

específicas de la entidad y de cada uno de sus órganos y unidades orgánicas. Las

funciones del Centro de información y sistemas (CIS) están contemplados en el

Artículo 92 del ROF del Gobierno Regional Cajamarca.

4.3 Pregunta N° 03

Grafico N° 03. Organigrama


En el gráfico N° 03, muestra que existe una Estructura Orgánica del Gobierno

Regional Cajamarca, aprobado con Ordenanza Regional N° 020-2005-GR.CAJ-CR

18.10.05. Y Modificada por Ordenanza Regional N° 001-2009-GR.CAJ 21.01.09.

Con ello se demuestra que constan diferentes niveles de jerarquía, y la relación

entre ellos. Cabe mencionar que el CIS no figura en la Estructura Orgánica del

Gobierno Regional. Existe como una unidad funcional que depende de la Sub

Gerencia de Desarrollo Institucional. Actualmente está en propuesta en el Plan

Operativo Informático en el Formato N° F1 – 07 la creación de la “Sub Gerencia de

Desarrollo Institucional y Tecnologías de Información”.

100%

¿Existe un organigrama con la estructura de organización del área?



76

4.4 Pregunta N° 04

Grafico N° 04. Puesto de Trabajo


En el gráfico N° 04, muestra que sólo el 71% tiene conocimiento que cada puesto

de trabajo describe: roles, responsabilidades, funciones, dependencia jerárquica,

requisitos mínimos de formación y experiencia. El 29% no tiene conocimiento

acerca de los puestos de trabajo del área. El documento que presenta la

descripción de puestos es el ROF (Reglamento de Organización y Funciones). Las

funciones del Centro de información y sistemas (CIS) están contemplados en el

Artículo 92 del ROF del Gobierno Regional Cajamarca.

4.5 Pregunta N° 05

Grafico N° 05. Promoción de Staff a puestos superiores


71%

29%

¿Cada puesto de trabajo describe roles, responsabilidades, funciones, dependencia

jerárquica, requisitos mínimos de formación y experiencia?


20%

80%

¿Están establecidos los procedimientos de promoción de personal a puestos superiores,

teniendo en cuenta la experiencia y formación?



77

En el gráfico N° 05, señala que el 80% dice que no está establecido el

procedimiento de promoción 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 público, en el cual establece Objetivos y Bases Legales

(Decretos Supremos) señalando requisitos mínimos, funciones a desempeñar

según el servicio o cargo a ocupar, periodo de contratación (con opción a

renovación). Pero no indica promoción de staff a puestos superiores.

4. 6 Pregunta N° 06

Grafico N° 06. Staff cumple requisitos al puesto qu e acceden


En el gráfico N° 06, nos señala que existe un 72% que afirma que el staff

seleccionado cumple con los requisitos del puesto, por el contrario el 14% niega

dicha afirmación. Y el 14% no sabe no opina. El Gobierno Regional cuando requiere

staff, procede a convocatoria o concurso público, señalando requisitos mínimos, en

el que el postulante debe cumplir.

72%

14%

14%

¿El personal seleccionado cumple los requisitos del puesto al que acceden?



78

4.7 Pregunta N° 07

Grafico N° 07. Formación y motivación del staff


El grafico N° 07 nos muestra que todo el staff del área cuenta con la formación

necesaria y además son motivados para la realización de su trabajo. Esta

motivación la realiza el director del CIS, enfatizando las cualidades del staff.

4.8 Pregunta N° 08

Grafico N° 08. Sugerencias del staff


100%

¿El personal de área cuenta con la formación adecuada y son motivados para la realización de

su trabajo?


60%

40%

¿Existe algún mecanismo que permita al personal hacer sugerencias sobre mejoras en la

organización del área?



79

El grafico N° 08 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 afirmación. El director del CIS confirmó

que hacen reuniones periódicas en las cuales los miembros del staff realizan

sugerencias para la mejora del área, las cuales se toman en cuenta.

4.9 Pregunta N° 09

Grafico N° 09. Aprobación del proyecto.


El gráfico N° 09 señala que el 86% no existe documento de aprobación de proyecto

informático autorizado por alta gerencia, en cambio el 14% afirma que si existe

dicho documento. El Gobierno Regional Cajamarca emite Resolución Ejecutiva

Regional y basándose en el Plan Operativo Informático detallando lo siguiente

Ficha Técnica para la Programación de Actividades y Proyectos Informáticos, el

cual describe objetivos, costo total, duración, unidad ejecutora del proyecto.

14%

86%

¿Existe algún documento de aprobación del proyecto informático autorizado por la alta

gerencia?



80

4.10 Pregunta N° 10

Grafico N° 10. Metodología de desarrollo de sistema s de información


El grafico N° 10 señala que el 60% afirma que se establece una metodología de

desarrollo de sistemas de información soportada por herramientas de ayuda. Por el

contrario el 40% niega dicha afirmación. En la documentación proporcionada y

revisada, no se tiene una metodología de desarrollo de sistemas de información

documentada.


Grafico N° 11. Metodología cubre las fases y es ada ptable


60%

40%

¿Se tiene implantada una metodología de desarrollo de sistemas de información soportada

por herramientas de ayuda?


100%

¿La metodología cubre todas las fases del desarrollo y es adaptable a distintos tipos de

proyectos?



81

El gráfico N° 11 indica que la metodología de desarrollo de sistemas de información

cubre todas las fases del desarrollo. Es adaptable a los distintos tipos de proyectos

software. En la documentación proporcionada y revisada, no se tiene una

metodología de desarrollo de sistemas de información documentada.


Grafico N° 12. Asignación de responsable de proyect o.


El gráfico N° 12 indica que el 72% conoce la asignación de un responsable o

director de proyecto informático. Por el contrario el 14% no conoce la designación

del responsable del proyecto. En tanto el 14% no sabe no opina. Cada proyecto

informático del CIS es asignado a un responsable, el cual lo dirige siguiendo lo

establecido en el Plan Operativo Informático.

72%

14%

14%

¿Se ha asignado un responsable o director de proyecto?



82


Grafico N° 13. Dimensión del proyecto.


El gráfico N° 13 muestra que el 43% que no sabe y no opina y el 43% que

desconoce las dimensiones, riesgos y ciclo de vida del proyecto; indican la gran

falta de información acerca del proyecto por parte del staff del CIS. Sólo 14%

conoce que se ha descrito y dimensionado el proyecto, evaluando riesgos y el ciclo

de vida que se tomará cada proyecto.


Grafico N° 14. Registro de problemas


14%

43%

43%

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


29%

71%

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



83

El gráfico N° 14 muestra que el 71% no lleva un registro de problemas que se

producen los proyectos de desarrollo de sistemas. Por el contrario el 29% afirma

que si existe un registro del mismo. De la documentación revisada no existe un

registro de los incidentes, problemas y soluciones que se producen en el desarrollo

de sistemas.


Grafico N° 15. Información Histórica.


El gráfico N° 15 muestra que al 100% se ha hecho uso de la información histórica

existente, para dimensionar el proyecto, riesgos y el ciclo de vida según el proyecto.

100%

¿Se ha hecho uso de la información histórica que se dispone tanto para dimensionar el proyecto y sus riesgos como para seleccionar el ciclo de vida ?



84


Grafico N° 16. Equipos de trabajo y responsables de las áreas.


En el gráfico N° 16 indica que el 86% se constituye formalmente al equipo de

trabajo, además de los responsables de las áreas donde se ve inmerso el proyecto.

En cambio el 14% no sabe no opina. La integración del staff y de los responsables

de las áreas donde se implantará el nuevo software, se constituye de manera

verbal, mas no documentado.


Grafico N° 17. Reuniones del equipo de trabajo.


86%

14%

¿Se ha constituido formalmente al equipo de trabajo, así como los responsables de las áreas

inmersas en el proyecto?


86%

14%

¿Se realizan reuniones con una frecuencia mínima y las decisiones tomadas quedan documentadas?



85

En el gráfico N° 17 señala que el 86% si realizan reuniones periódicas y las

decisiones de aquellas reuniones son documentadas. En cambio el 14% niega

dicho enunciado. Las reuniones de staff si se hace con frecuencia mínima (cada 7

días), pero las decisiones tomadas no quedan documentadas, sólo se las

menciona.


Grafico N° 18. Documentación del proyecto.


En el gráfico N° 18 muestra un 86% que existe documentación del proyecto, es

completo y está catalogada. En cambio existe un 14% no sabe no opina. De la

información revisada y analizada que puede afirmar que la documentación es

completa, pero no está catalogada para accesos posteriores.

86%

14%

¿La documentación del proyecto es completa y está catalogada para accesos posteriores?



86


Grafico N° 19. Documentación de requisitos.


En el gráfico N° 19 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 documentación necesaria.


Grafico N° 20. Solicitud de participación de person al de otras áreas.


71%

29%

¿Existe un documento que recoge la descripción general de requisitos establecidos por el usuario?


20%

60%

20%

¿Existe un protocolo para solicitar al resto de las áreas la participación del personal en el proyecto

y se aplica dicho protocolo?



87

En el gráfico N° 20 muestra que el 20% que no sabe y no opina y el 60% que

desconoce la existencia de un protocolo de solicitud de participación de personal de

otras áreas inmersas en el proyecto. En cambio el 20 % afirma dicho enunciado. La

participación de personal de otras áreas incluidas en el proyecto se hace de manera

verbal, mas no existe un protocolo específico.


Grafico N° 21. Nuevos proyectos software.


En el gráfico N° 21 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 realización de nuevos proyectos software se basa íntegramente al Plan

Operativo Informático.

40%

20%

40%

¿La realización de nuevos proyectos software se basa en el Plan Operativo informático?



88


Grafico N° 22. Fechas de realización del proyecto.


En el gráfico N° 22 indica que entre el 20% que no sabe y no opina y el 20% que

tiene desconocimiento acerca de las fechas de realización de proyectos inmersos

en el POI. Se puede afirmar junto con el 60% que las fechas de realización

coinciden con el POI, pues éste dispone fechas a corto plazo.


Grafico N° 23. Recopilación de información.


60%20%

20%

¿Las fechas de realización del proyecto coinciden con los del Plan Operativo Informático?


86%

14%

¿La recopilación de información es la adecuada en función de las características del proyecto y a

los tipos de usuario a entrevistar?



89

En el gráfico N° 23 señala que el 86% afirma que recopilan de la información es la

adecuada. Por el contrario el 14% niega dicho enunciado. La recopilación de la

información se realiza de manera adecuada con las características del proyecto y

los usuarios a entrevistar

Pregunta N° 24

Grafico N°24. Métricas.

Fuente: Elaboración propia En el gráfico N° 24 indica que existe un 60% que no realizan métricas para estimar

la calidad del software. Por el contrario existe un 40% que afirma dicho enunciado.

No realizan ninguna métrica para estimar la calidad del software.


Grafico N° 25. Guías de prácticas de análisis y dis eño.


40%

60%

¿Se realizan varios tipos de métricas para poder estimar la calidad del software?


40%

60%

¿Se definen prácticas de análisis y diseño. Además existe una guía de practicas para cada lenguaje de

programación?



90

En el gráfico N° 25 indica que el 40% afirma que se definen prácticas de análisis y

diseño, además existe una guía para cada lenguaje de programación. Por el

contrario, existe un 60% que niega dicho enunciado. Las prácticas de análisis y

diseño se realizan de manera empírica además no existe una guía de prácticas

para cada lenguaje de programación.


Grafico N° 26. Modelo del sistema.

Fuente: Elaboración propia En el gráfico N° 26 indica al 100% que se realiza modelos del sistema.


Grafico N° 27. División de subsistemas.


100%

¿Se han realizado modelos del sistema?


72%

14%

14%

¿La división de los subsistemas están orientados a los procesos de la organización?



91

En el gráfico N° 27 muestra que el 72% afirma que la división de los subsistemas

está orientada a los procesos de la organización. El 14% niega lo expuesto. Y por

último el 14% no sabe no opina. La subdivisión de los subsistemas se hace a través

de Módulos: Modulo de Administración Documentaria (MAD) y Modulo de

Administración Organizacional (MAO).


Grafico N° 28. Interfaces.


En el gráfico N° 28 indica que el 100% afirma que se detallan las interfaces del

sistema.

100%

¿Se detallan las interfaces: pantallas a través de las cuales el usuario navegará por la aplicación,

menús, botones y formularios asociados?



92


Grafico N° 29. Normas de diseño.

Fuente: Elaboración propia En el gráfico N° 29 muestra que el 72% afirma que existen normas de diseño. El

14% niega lo expuesto. Y por último el 14% no sabe no opina.


Grafico N° 30. Plan de pruebas.


En el gráfico N° 30 señala 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.

72%

14%

14%

¿Existen normas de diseño o estilo de pantallas, informes, formularios?


43%

43%

14%

¿Debe especificarse un plan de pruebas definiendo requisitos de alcance y entorno?



93


Grafico N° 31. Aceptación del sistema.

Fuente: Elaboración propia En el gráfico N° 31 muestra que el 43% afirma que se elabora un plan de pruebas

de aceptación del sistema, por el contrario el 57% niega dicho enunciado.


Grafico N° 32. Validación de la especificación.


En el gráfico N° 32 señala que el 71% afirma que realizan validación formal de la

especificación de requisitos y modelos del análisis del sistema. Por el contrario el

43%

57%

¿Se ha elaborado un plan de pruebas de aceptación del sistema, es coherente con los

requisitos y con la especificación funcional del sistema?


71%

29%

¿Se ha realizado una validación formal de la especificación de requisitos y de los modelos del

análisis del sistema?



94

29% niega dicho enunciado. La validación se realiza pero no de manera

documentada.

Grafico N° 33. Arquitectura del sistema.

Pregunta N° 33


En el gráfico N° 33 indica que el 86% afirma que se define la arquitectura del

sistema, es coherente con la especificación funcional y con el entorno tecnológico.

Por el contrario el 14% dice que no a la pregunta.

86%

14%

¿Se ha definido una arquitectura del sistema que sea coherente con la especificación funcional y

con el entorno tecnológico?



95


Grafico N° 34. Migración y carga inicial de datos.

Fuente: Elaboración propia En el gráfico N° 34 muestra que el 43% afirma que se especifica el procedimiento

de migración y carga inicial de datos, así como los requisitos de operación. En

cambio el 43% niega el enunciado. Y por último el 14 % no sabe no opina.


Grafico N° 35. Entorno de desarrollo y pruebas.


43%

43%

14%

¿Se especifica el procedimiento de migración y carga inicial de datos así como los requisitos de

operación?


72%

14%

14%

¿Se prepara adecuadamente el entorno de desarrollo y de pruebas, así como los

procedimientos de operación y seguridad?



96

En el gráfico N° 35 indica que el 72% prepara adecuadamente el entorno de

desarrollo y pruebas, procedimientos de operación y seguridad. Sin embargo el

14% dice que no preparan el entorno y otro 14% no sabe no opina.


Grafico N° 36. Repositorio de productos software.


En el gráfico N° 36 indica un 80% que existe un repositorio con todos los productos

software que pueden ser reutilizados. Por el contrario el 20% niega dicha

existencia.

80%

20%

Existe un repositorio con todos los productos software susceptibles de ser reutilizados: Librerías

de funciones, clases de objetos, componentes software, documentos (catalogo de requisitos

comunes, arquitecturas).



97


Grafico N° 37. Técnicas de programación.


En el gráfico N° 37 indica que el 100% de los componentes se desarrollan utilizando

técnicas de programación correctas.


Grafico N° 38. Programar, probar y documentar compo nentes.


100%

¿Los componentes que se desarrollan utilizan técnicas de programación correctas?


57%29%

14%

¿Se programa, prueba y documenta cada uno de los componentes identificados en el diseño del

sistema?



98

En el gráfico N° 38 indica que el 57% si se programa, prueba y documenta todos los

componentes identificados en el diseño del sistema. En cambio existe un 29% que

niega dicho enunciado. Y por último el 14% no sabe no opina.


Grafico N° 39. Estándares y normas de programación.


En el gráfico N° 39 indica que el 57% afirma que se programan todos componentes,

siguiendo estándares y normas de programación, así como también de

documentación. Pero el 43% dice que no a la pregunta. Se programa con

estándares de programación pero no se documenta.

57%

43%

¿Se programa todos los componentes, siguendo estándares y normas de programación y

documentación (código comentado y documentado)?



99


Grafico N° 40. Prueba de cada componente.


En el gráfico N° 40 indica un 57% afirmando que se prueba cada componente de

forma unitaria siguiendo el plan de pruebas. Si se detecta un fallo de especificación

o diseño, el proyecto se actualizará según procedimiento establecido. Por el

contrario el 29% niega dicho enunciado. Y por último un 14% que no sabe no opina.


Grafico N° 41. Procedimientos de migración y carga inicial de datos.


57%29%

14%

¿Se prueba cada componente de forma unitaria siguiendo el plan de pruebas. Si se

detecta un fallo de especificación o diseño, el proyecto se actualizará según el

procedimiento establecido para ello?


29%

57%

14%

¿Se realiza codificación, prueba de los componentes y procedimientos de migración y

carga inicial de datos?



100

En el gráfico N° 41 indica que entre el 14% que no sabe y no opina y el 29% que

dice que no se realiza codificación ni pruebas ni mucho menos migración y carga

inicial de datos. Por el contrario el 29% afirma dicha interrogante. Si se realiza la

codificación, prueba de componentes y se realiza procedimientos de migración y

carga inicial de datos al nuevo sistema.


Grafico N° 42. Aceptación formal del sistema.


En el gráfico N° 42 indica al 100% la aceptación del nuevo sistema por parte de los

usuarios. Pero dicha aceptación no es documentada.

100%

¿El sistema debe ser aceptado formalmente por los usuarios antes de ser puesto en ejecución

total?



101


Grafico N° 43. Plan de formación y aceptación.


En el gráfico N° 43 indica que el 86% niega que exista un plan de formación y

aceptación del nuevo sistema, por el contrario el 14% afirma dicha pregunta.


Grafico N° 44. Capacitación a usuarios.


14%

86%

¿Existe un plan de formación y aceptación?


100%

¿Los usuarios reciben capacitación necesaria y tienen toda la documentación, fundamentalmente

manuales de usuario?



102

En el gráfico N° 44 indica que el 100% afirma que se capacita a los usuarios y se

les proporciona manual de usuarios.


Grafico N° 45. Procedimientos de mantenimiento.


En el gráfico N° 45 indica que existe el 57% afirma que el procedimiento de

mantenimiento se realiza a fin de facilitar la gestión de cambios. En cambio el 43%

niega dicha existencia.

57%

43%

¿Existe un procedimiento de mantenimiento a fin de facilitar la gestión de cambios?



103


Grafico N° 46. Monitorear nivel de servicio.


En el gráfico N° 46 señala 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 sólo el 14% afirma que se revisa periódicamente el nivel de servicio

para monitorizar el grado de cumplimiento.


Grafico N° 47. Peticiones de mantenimiento.


14%

57%

29%

¿Se revisa periódicamente el nivel de servicio para monitorizar su grado de cumplimiento?


12%

50%

38%

¿Las peticiones de mantenimiento se presentan de forma estándar, para permitir su clasificación y facilitar la identificación del tip o

de mantenimiento requerido?



104

En el gráfico N° 47 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 sólo el 12% afirma que las peticiones de

mantenimiento se presentan de forma que permite su clasificación e identificación

del tipo de mantenimiento.


105

Capítulo V:

CONCLUSIONES Y RECOMENDACIONES


106

V. CONCLUSIONES Y RECOMENDACIONES

5.1 CONCLUSIONES

La metodología evaluada en el desarrollo de sistemas de información no es la

adecuada, pues se realiza de manera muy empírica.

La identificación de las fases de la metodología no son las correctas. Algunas fases

no se toman en cuenta como la gestión de proyectos software.

La evaluación de la adecuación entre el proceso de desarrollo y los objetivos de la

institución no son los correctos.

No se realiza el cumplimiento de estándares y normas de control interno en el

desarrollo de sistemas de información.

No cumplen con normas de seguridad e integridad de datos, ni tampoco el control

de cambios.

Falta de comunicación entre el staff.

Falta de documentación crítica en las casi todas las fases del proyecto software.

5.2 RECOMENDACIONES

1. Establecer una metodología para el desarrollo de sistemas de información, El

uso de una metodología sería muy eficiente pues se estaría desarrollando

sistemas de información conforme a un estándar.

2. Establecer las siguientes fases en el proyecto software: gestión de proyectos,

viabilidad del proyecto, análisis, diseño, programación o construcción,

implantación y aceptación y mantenimiento de software.

3. Establecer un control interno y así de esta manera mejorar el área de sistemas.


107

4. Implementar una gestión de comunicación entre el staff.

5. Tener una documentación adecuada de todos los procesos de desarrollo y que

todo el personal tenga acceso.

6. Cumplir con lo establecido de las normativas ISO y Métricas aplicadas sobre la

metodología de desarrollo de sistemas de información.

7. Dar continua capacitación especializada en temas específicos de Desarrollo de

Sistemas de Información a todo el staff.

8. Realizar regularmente copias de seguridad de la información esencial de la

entidad, además del software en concordancia con políticas institucionales.

9. Realizar investigaciones acerca de auditorías informáticas que permitan tener un

eficiente control interno.

10. La presente investigación se realizó con el diseño de Investigación ex-post-facto,

para futuras investigaciones se podría tomar como diseño de la investigación pre

test y post test.


108

Capítulo VI:

REFERENCIAS BIBLIOGRÁFICAS

- ANEXOS


109

VI. REFERENCIAS BIBLIOGRÁFICAS

Tesis: Tes [01]: CHÁVEZ GARCÍA, Gissela Karina. “Auditoria Informática Aplicada

al Sistema Integrado de Gestión Comercial, Comercializadora y Distribuidora Jiménez S.A. de la Empresa Distribuidora Codijisa- Trujillo”. [Tesis para optar el Título Profesional de Ingeniero de Sistemas]. Trujillo: Universidad Privada del Norte. 2004

Tes [02]: VILLANUEVA SÁNCHEZ, Grover Eduardo. “Sistema de Gestión

Estratégica aplicando el Enfoque Sistémico y las Tecnologías de la Información para lograr Ventajas Competitivas en el Instituto Nacional de Cultura de La Libertad”. [Tesis para optar el Título Profesional de Licenciado en Administración]. Trujillo. Universidad César Vallejo. 2008

Tes [03]: XILOJ CHARUC, Francisco Dagoberto. “Auditoría Externa en un

Ambiente de Sistemas de Información Computarizado en el Área de Ingresos de una Empresa Comercializadora de Vehículos”. [Tesis para optar el Título Profesional de Contador Público y Auditor]. Guatemala. 2008

Libros: Lib [01] BURCH & GRUDNITSKI, “Diseño de Sistemas de Información –

Teoría y Práctica”, Editorial Limusa, 1996 Lib [02] STAIR, Ralph M. “Principios de SISTEMAS DE INFORMACION –

Enfoque Administrativo”, Internacional Thomson Editores S.A., 1999 Lib [03] LAUDON, Kenneth C. & LAUDON, Jane P. “Sistemas De

Información Gerencial”, Pearson Educación S.A. de C.V., 2004 Lib [04] FERNANDEZ ALARCON, Vinceç. “Desarrollo de Sistemas De

Información – Una metodología basada en el modelado”, Ediciones UPC., 2006

Lib [05] MUÑOZ RAZO, Carlos. “Auditoria en Sistemas Computacionales”,

Pearson Educación de México.


110

Lib [06] PIATTINI VELTHUIS, Mario, DEL PESO NAVARRO, Emilio DEL

PESO RUÍZ, Mar. “Auditoría de Tecnologías y Sistemas de Información”, Editorial Ra-Ma, 2008.

Lib [07] TAMAYO ALZATE, Alonso. “Auditoria de Sistemas – Una visión

práctica”, Universidad Nacional de Colombia Sede Manizales, 2001 Lib [08] Universidad de Buenos Aires. “Manual de Procedimientos de

Auditoría Interna” [en línea]. Buenos Aires. [Fecha de acceso 08 de abril 2012]. URL disponible en http://www.uba.ar/download/institucional/informes/manual.pdf

Direcciones Electrónica – Páginas Web: URL [1]: INSTITUTO NACIONAL DE ESTADÍSTICA E INFORMÁTICA (INEI)

¿QUÉ ES LA AUDITORÍA INFORMÁTICA? [En línea] [Fecha de acceso 08 de abril 2012]. URL disponible en

http://www1.inei.gob.pe/biblioineipub/bancopub/Inf/Lib5105/Libro. URL [2]: Oficina Nacional de Gobierno Electrónico e Informática (ONGEI)

Auditoria de Sistemas [En línea] [Fecha de acceso 08 de abril 2012]. URL disponible en http://www.ongei.gob.pe/publica/metodologias/Lib5002/libro.htm

URL [3]: Oficina Nacional de Gobierno Electrónico e Informática (ONGEI)

Auditoria de Sistemas [En línea] [Fecha de acceso 08 de abril 2012]. URL disponible en http://www.ongei.gob.pe/publica/metodologias/Lib5002/libro.htm

URL [4]: Desarrollo ágil de Software [En línea] [Fecha de acceso 08 de abril 2012]. URL disponible en http://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software

URL [5]: Historia de ISACA [En línea] [Fecha de acceso 08 de abril 2012].

URL disponible en

http://www.isaca.org/About-ISACA/History/Espanol/Pages/default.aspx

Diapositivas: PPT [1]: Mg. Ing. Alberto Mendoza De los Santos. Auditoria de Sistemas.

[Diapositiva]. Cajamarca: Universidad Privada del Norte; 2009. 19 diapositivas.

PPT [2]: Mg. Ing. Alberto Mendoza De los Santos. Control Interno. [Diapositiva].

Cajamarca: Universidad Privada del Norte; 2009. 44 diapositivas.


111

ANEXOS


112

VII. HALLAZGOS DE AUDITORIA

A continuación de enumeran los principales hallazgos después de haber aplicado la

auditoria del desarrollo de sistemas de información:

1. Aplicativos informáticos que administra el Gobierno Regional Cajamarca:

N° Denominación Descripción

1. Sistema de Aplicaciones

Regionales

Sistema Integrado para la administración

de datos de las diferentes áreas y sectores

del gobierno regional; siendo estas:

personal, planillas, visitar, inventario

informático.

2. Sistema de Abastecimiento Para el control de requerimientos, órdenes

de compra, servicios, pecosas y almacén.

3. Sistema de Gestión Documentaria Para el registro, control y seguimiento de la

documentación a nivel regional.

Tabla N° 08: Aplicativos informáticos Gobierno Regional Cajamarca

Fuente: Centro de Información y Sistemas

2. Documentación de los Aplicativos:

- Manual de Usuario: Sí (Desactualizado), el Modulo de Planillas del

sistema SAR no cuenta con manual de usuarios. - Manual Técnico: NO - Diccionario de Datos: SI, pero solo actualizado al 2010.

3. Ausencia de una metodología en el desarrollo de sistemas de información.

4. Ausencia de copias de seguridad o respaldo (backup) de la información

esencial de la entidad y de los aplicativos informáticos que pondrían en

riesgo la integridad de la información.

5. La gestión del cambio en los sistemas informáticos no se encuentra

documentada, lo cual no permite el control y seguimiento de las

actualizaciones y podría afectar la continuidad de las operaciones de la

entidad.


113

Los requerimientos en mención se realizan verbalmente o a través de correo

electrónico, denotándose la ausencia de documentos que permitan rastrear

las modificaciones.

6. Datos duplicados, inconsistentes, incompletos o de pruebas en la base de

datos de producción del Sistema de Aplicaciones Regionales, esto limita el

uso y explotación y afecta directamente la confiabilidad de la información.

Se constató la presencia de datos inconsistentes, incompletos o de pruebas

tal como se muestra:

Figura N° 16: Datos inconsistentes en la base de datos

Fuente: Centro de Información y Sistemas

7. No se realiza control de versiones de los códigos fuentes, ejecutables de los

sistemas informáticos, lo cual no permite identificar los cambios o

actualizaciones correspondientes a cada versión del sistema software.

8. Ausencia o desactualización de documentos que orienten y uniformicen los

procesos de mantenimiento, administración y uso de los aplicativos.

Esto dificulta la compresión y uso de la información, generando riesgos de

errores y omisiones.

Auditoria desarrollo sistemas de información

Technology

presente investigacin

ingeniera de sistemas

desarrollo de sistemas

presente estudio

presente proyecto

ingeniero de sistemas

investigacin aplicada

centro de informacin