4.3.2. Mantis Bug Tracker

DESARROLLO DE UNA APLICACIÓN DE GESTIÓN DE PLANES DE MEJORAMIENTO PARA LAS ENTIDADES DEL DISTRITO CAPITAL EMPLEANDO EL SOFTWARE OPEN SOURCE DE GESTIÓN DE INCIDENCIAS MANTIS BUG TRACKER

GUSTAVO ADOLFO SOTO LAMBRAÑO CODIGO: 20042020104 [email protected]

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE INGENIERIA PROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS BOGOTA D.C. 2016

DESARROLLO DE UNA APLICACIÓN DE GESTIÓN DE PLANES DE MEJORAMIENTO PARA LAS ENTIDADES DEL DISTRITO CAPITAL EMPLEANDO EL SOFTWARE OPEN SOURCE DE GESTIÓN DE INCIDENCIAS MANTIS BUG TRACKER

GUSTAVO ADOLFO SOTO LAMBRAÑO CODIGO: 20042020104 [email protected]

Trabajo de Grado para optar al título de Ingeniero de Sistemas

Director OSWALDO ROMERO

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS FACULTAD DE INGENIERIA PROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS BOGOTA D.C. 2016

Nota de Aceptación:

______

Firma del Director

______

Firma del Jurado

______

Firma del Jurado

Bogotá D.C. 2016

TABLA DE CONTENIDO

GLOSARIO ...... 10

1. INTRODUCCIÓN ...... 15

1.1. DESCRIPCIÓN DEL PROBLEMA ...... 16

1.2. FORMULACIÓN DEL PROBLEMA ...... 18

2. JUSTIFICACIÓN ...... 19

3. OBJETIVOS ...... 21

3.1. OBJETIVO GENERAL ...... 21

3.2. OBJETIVOS ESPECÍFICOS ...... 21

4. MARCO REFERENCIAL ...... 22

4.1. PLAN DE MEJORAMIENTO ...... 22

4.1.1. Ley 87 de 1993 ...... 22

4.1.2. MECI ...... 24

4.1.2.1. Principios: ...... 25

4.1.2.2. Estructuras de control: ...... 26

4.1.2.3. Roles y responsabilidades: ...... 29

4.1.3. NTCGP:1000 ...... 30

4.1.4. Generalidades ...... 31

4.1.5. Ámbito de aplicación ...... 32

4.1.6. Sistema de gestión de la calidad ...... 32

4.1.7. Medición, análisis y mejora ...... 33

4.2. HALLAZGOS DE AUDITORÍAS REALIZADAS POR LA CONTRALORÍA DE BOGOTÁ 34

4.3. HERRAMIENTAS DE DESARROLLO ...... 38

4.3.1. Lenguaje de programación PHP ...... 38

4.3.2. Mantis Bug Tracker ...... 39

4.4. METODOLOGÍA DE DESARROLLO ...... 40

5. ALCANCES Y LIMITACIONES ...... 48

5.1. ALCANCES ...... 48

5.2. LIMITACIONES ...... 48

6. DISEÑO METODOLÓGICO ...... 49

6.1. METODOLOGÍA DE INVESTIGACIÓN ...... 49

6.2. METODOLOGÍA DE INGENERÍA ...... 51

6.3. RESULTADOS ESPERADOS ...... 54

7. ANÁLISIS DE REQUERIMIENTOS ...... 55

7.1. DESCRIPCIÓN DEL SISTEMA ACTUAL ...... 55

7.2. OBJETIVOS DEL SISTEMA ...... 55

7.3. REQUISITOS DE INFORMACIÓN ...... 56

7.4. CASOS DE USO ...... 56

7.5. DIAGRAMAS DE CASOS DE USO (UML) ...... 58

7.5.1. SUBSISTEMA GESTIÓN DE AUDITORÍAS ...... 59

7.5.2. SUBSISTEMA GESTIÓN DE HALLAZGOS ...... 59

7.5.3. SUBSISTEMA GESTIÓN DE CAMPOS PERSONALIZADOS ...... 61

7.5.4. SUBSISTEMA GESTIÓN DE USUARIOS ...... 62

7.6. ACTORES DEL SISTEMA...... 62

7.7. DIAGRAMA DE ESTADOS ...... 63

7.8. DISEÑO DE LA BASE DE DATOS ...... 64

7.8.1. Planteamiento del problema ...... 64

7.8.2. Planteamiento del general ...... 65

7.8.3. DISEÑO CONCEPTUAL ...... 66

7.8.4. Tablas ...... 66

7.8.5. Relaciones ...... 67

7.8.6. Diagrama Modelo entidad-relación...... 67

7.9. IMPLEMENTACIÓN BASE DE DATOS ...... 68

7.9.1. Comparación modelo entidad-relación y tablas de MantisBT ...... 68

8. DESARROLLO E IMPLEMENTACION ...... 71

8.1. ENTORNO GENERAL DE DESARROLLO ...... 71

8.1.1. Lenguaje de servidor PHP ...... 71

8.1.2. Herramienta para gestión de incidentes Mantis Bug Tracker ...... 72

8.1.3. Paquete de servicios Web WAMPP ...... 73

8.2. CONTROL DE CAMBIOS ...... 75

8.2.1. Interfaz gráfica ...... 76

8.2.2. Archivos de configuración ...... 79

8.2.3. Modificación de los módulos ...... 82

9. PLAN DE PRUEBAS ...... 83

9.1. PROPOSITO DEL PLAN ...... 83

9.2. ALCANCES ...... 83

9.3. ENTORNO DE PRUEBAS ...... 84

9.4. ROLES Y RESPONSABILIDADES ...... 84

9.5. PRUEBAS A APLICAR ...... 85

9.6. CASOS DE PRUEBA ...... 85

10. IMPACTO Y APLICACIONES A FUTURO ...... 87

11. ANÁLISIS DE COSTO-BENEFICIO PARA IMPLEMENTACIÓN EN ENTIDADES DEL DISTRITO...... 88

11.1. CÁLCULO DE CARGAS DE TRABAJO ...... 88

11.2. COSTOS TANGIBLES E INTANGIBLES ...... 92

11.2.1. Espacio en disco del servidor...... 94

11.3. BENEFICIOS ...... 95

12. CONSOLIDACIÓN DE PLAN DE MEJORAMIENTO...... 96

13. INGRESO AL APLICATIVO EL PLAN DE MEJORAMIENTO COMPILADO...... 103

14. ENCUESTA DE SATISFACCIÓN ...... 107

15. CONCLUSIONES ...... 114

BIBLIOGRAFÍA ...... 116

REFERENCIAS ELECTRÓNICAS ...... 117

ANEXOS ...... 118

Anexo A. DOCUMENTO DE ELICITACION DE REQUISITOS ...... 118

A.I. LISTA DE CAMBIOS ...... 118

A.II. OBJETIVOS DEL SISTEMA ...... 118

A.III. CATÁLOGO DE REQUISITOS DEL SISTEMA ...... 121

A.III.I. REQUISITOS DE INFORMACIÓN ...... 121

A.III.II. REQUISITOS FUNCIONALES ...... 126

A.III.III. DEFINICIÓN DE ACTORES ...... 153

A.III.IV. REQUISITOS NO FUNCIONALES ...... 154

A.IV. MATRIZ DE RASTREABILIDAD OBJETIVOS/REQUISITOS ...... 157

Anexo B. MANUAL DE USUARIO ...... 159

B.I. INTRODUCCIÓN ...... 159

B.II.I. Auditor ...... 159

B.II.II. Líder de proceso ...... 160

B.III. INTERFAZ GRÁFICA ...... 160

B.IV. PERFILES DE USUARIO ...... 164

B.V. ESTADOS DE EJECUCIÓN DE LOS HALLAZGOS ...... 164

B.VI. ESTADOS DE RESOLUCIÓN DE LOS HALLAZGOS ...... 165

B.VII. USO DEL SISTEMA ...... 166

B.VII.I. Crear usuarios ...... 166

B.VII.II. Iniciar sesión ...... 166

B.VII.III. Crear una auditoría ...... 169

B.VII.IV. Configurar auditoría ...... 169

B.VII.V. Reportar un hallazgo ...... 171

B.VII.VI. Asignar un hallazgo ...... 172

B.VII.VII. Rechazar un hallazgo ...... 174

B.VII.VIII. Monitorizar un hallazgo: ...... 175

B.VII.IX. Iniciar un hallazgo ...... 176

B.VII.X. Agregar Seguimientos ...... 176

B.VII.XI. Resolver un hallazgo ...... 177

B.VII.XII. Cerrar un hallazgo ...... 177

B.VII.XIII. Reabrir un hallazgo ...... 178

B.VIII. ADJUNTAR EVIDENCIAS ...... 178

Anexo C. CASOS DE PRUEBAS ...... 179

C.I. CASOS DE PRUEBA – SUBSISTEMA MANEJO DE USUARIOS ...... 179

C.II. CASOS DE PRUEBA – SUBSISTEMA AUDITORÍAS ...... 182

C.III. CASOS DE PRUEBA – SUBSISTEMA HALLAZGOS ...... 187

C.IV. CASOS DE PRUEBA – SUBSISTEMA CAMPOS PERSONALIZADOS ...... 192

Anexo D. ACCESO AL DESARROLLO DE LA APLICACIÓN...... 193

LISTA DE FIGURAS

Figura 1 Consolidado Hallazgos alcaldías locales ...... 17 Figura 2: Matriz de seguimiento plan de mejoramiento Secretaría de Gobierno ...... 17 Figura 3: Hallazgos de auditorías sector salud – Contraloría de Bogotá...... 18 Figura 4: Grafico explicativo de MECI ...... 25 Figura 5: Subsistemas del MECI ...... 26 Figura 6: Esquema del ciclo PHVA adaptado a la norma NTCGP: 1000 ...... 31 Figura 7: Acceso a las Auditorías de la Contraloría de Bogotá D.C...... 34 Figura 8: Estructura en árbol de las sectoriales de la Contraloría para descargar informes ...... 35 Figura 9: Total Auditorías 2014 Contraloría de Bogotá ...... 36 Figura 10: Total Hallazgos Auditorías Contraloría Bogotá D.C. de 2014...... 36 Figura 11. Relación de Hallazgos sector Salud...... 37 Figura 12: Captura de pantalla de Mantis Bug Tracker ...... 39 Figura 13: Esquema de responsabilidades para el analista ...... 44 Figura 14: Esquema de responsabilidades para el arquitecto ...... 44 Figura 15: Esquema de responsabilidades para el desarrollador ...... 44 Figura 16: Esquema de responsabilidades para el director de proyecto ...... 45 Figura 17: Esquema de responsabilidades para el stakeholder (Sin responsabilidades específicas)...... 45 Figura 18: Esquema de responsabilidades para el probador ...... 45 Figura 19: Flujo de trabajo de OpenUP ...... 47 Figura 20: Diagrama de paquetes del sistema...... 58 Figura 21: Diagrama de Caso de uso para la gestión de auditorías...... 59 Figura 22: Diagrama de Caso de uso para la gestión de hallazgos...... 60 Figura 23: Diagrama de Caso de uso para la gestión de campos personalizados...... 61 Figura 24: Diagrama de Caso de uso para la gestión de usuarios...... 62 Figura 25: Diagrama de Caso de uso para los actores del sistema...... 63 Figura 26: Diagrama estados de los hallazgos...... 64 Figura 27: Diagrama estados de los hallazgos...... 67 Figura 28: Captura de pantalla de Mantis Bug Tracker ...... 73 Figura 29: Navegador Web con una página de muestra de WAMPP bajo...... 73 Figura 30: Pantalla de la aplicación PHPMyAdmin ...... 74 Figura 31: Comparación sección “Mi Vista” original vs aplicación modificada ...... 77 Figura 32: Comparación sección “Hallazgos” original vs aplicación modificada ...... 78 Figura 33: Comparación sección “Ingreso” original vs aplicación modificada ...... 79 Figura 34: Proceso Manual Vs Proceso Sistematizado ...... 92 Figura 35: Tamaño Base de datos con 25 hallazgos ...... 94 Figura 36: Gráfica espacio en disco ...... 95 Figura 37: Auditorías creadas en el Aplicativo...... 103 Figura 38: Módulo de consulta de hallazgos ...... 103

Figura 39: Módulo de reportes...... 104 Figura 40: Detalle del hallazgo 3.7.8...... 104 Figura 41: Seguimientos hallazgo 3.7.8 ...... 105 Figura 42: Historial del hallazgo 3.7.8 ...... 105 Figura 43: Formato para imprimir hallazgo 3.7.8 ...... 106 Figura 44: Participación de perfiles de la encuesta...... 109 Figura 45: Pregunta 1 ...... 109 Figura 46: Pregunta 2 ...... 110 Figura 47: Pregunta 3...... 110 Figura 48: Pregunta 4...... 111 Figura 49: Pregunta 5...... 111 Figura 50: Pregunta 6...... 112 Figura 51: Impacto de la implementación por perfil ...... 112 Figura 52: Justificación implementación del sistema ...... 113 Figura 53: Menú principal aplicación ...... 160 Figura 54: Pantalla “Mi vista” ...... 161 Figura 55: Pantalla “Ver hallazgos” ...... 162 Figura 56: Pantalla “Mi cuenta” ...... 162 Figura 57: Pantalla “Preferencias”...... 163 Figura 58: Pantalla “Administrar Cuenta” ...... 163 Figura 59: Diagrama de estados de ejecución...... 165 Figura 60: Mensaje de correo electrónico de acceso a cuenta...... 167 Figura 61: Formulario establecer contraseña ...... 167 Figura 62: Pantalla de ingreso ...... 168 Figura 63: Pantalla de confirmación primer ingreso ...... 168 Figura 64: Ubicación de la opción “Reportar hallazgo” ...... 171 Figura 65: Selección de auditoría a reportar un hallazgo ...... 171 Figura 66: Formulario para la reporte de un hallazgo...... 172 Figura 67: Opción de asignación de hallazgo en su creación...... 173 Figura 68: Opción de asignación de hallazgo creado...... 174 Figura 69: Opción de rechazo de hallazgo para el caso de líder ...... 174 Figura 70: Agregar seguimiento al rechazar del hallazgo ...... 175 Figura 71. Configuración base de datos en archivo config_inc.php ...... 194 Figura 72. Dirección Ip de la máquina virtual ...... 195 Figura 73: Creación de usuarios con el usuario de prueba “auditor1” ...... 196

LISTA DE TABLAS

Tabla 1: Elementos comunes entre NTGPC 1000: 2009 y MECI ...... 32 Tabla 2: Hallazgos Contraloría de Bogotá D.C. de 2014 por sector ...... 35 Tabla 3: Auditorías y hallazgos del Sector Salud en 2014 ...... 37 Tabla 4: Productos de trabajo para el proyecto ...... 53 Tabla 5: Objetivos del sistema para la aplicación ...... 56 Tabla 6: Requisitos de información planteados ...... 56 Tabla 7: Casos de Uso del Sistema ...... 57 Tabla 8: Lista de entidades del modelo relacional resultante clasificadas ...... 66 Tabla 9: Lista de entidades del modelo relacional resultante clasificadas ...... 67 Tabla 10: Lista de entidades del modelo relacional resultante clasificadas ...... 68 Tabla 11: Lista de roles y responsabilidades ...... 84 Tabla 12: Formato para los casos de prueba del prototipo ...... 85 Tabla 13: Casos de prueba aplicación ...... 86 Tabla 14: Cálculo de carga de trabajo con un proceso manual ...... 90 Tabla 15: Cálculo de carga de trabajo con el sistema propuesto ...... 91 Tabla 16: Variación tiempo destinado en horas para la ejecución del plan de mejoramiento .... 92 Tabla 17: Costos tangibles del sistema ...... 93 Tabla 18: Proyección espacio servidor ...... 94 Tabla 19: Cantidad de Hallazgos Hospital El Tunal Auditoría Especial 2014 ...... 96 Tabla 20: Seguimiento plan de mejoramiento Hospital De Bosa ...... 97 Tabla 21: Seguimiento plan de mejoramiento Hospital De Bosa ...... 98 Tabla 22: Seguimiento plan de mejoramiento Hospital De Bosa ...... 99 Tabla 23: Seguimiento plan de mejoramiento Hospital De Bosa ...... 100 Tabla 24: Seguimiento plan de mejoramiento Hospital De Bosa ...... 101 Tabla 25: Seguimiento plan de mejoramiento Hospital De Bosa ...... 102 Tabla 26: Perfiles personas encuestadas...... 109 Tabla 27: Siglas especiales...... 118 Tabla 28: Lista de cambios del documento de requisitos ...... 118 Tabla 29: Objetivo 1 – Gestión de auditorías ...... 118 Tabla 30: Objetivo 2 – Gestión de hallazgos ...... 119 Tabla 31: Objetivo 3 – Presentación de informes ...... 119 Tabla 32: Objetivo 4 – Gestión de usuarios ...... 119 Tabla 33: Objetivo 5 – Medición de la gestión ...... 120 Tabla 34: Objetivo 6 – Gestión de notificaciones ...... 120 Tabla 35: Objetivo 7 – Manejo de campos (Indicadores de gestión) ...... 120 Tabla 36: Objetivo 7 – Manejo de campos (Indicadores de gestión) ...... 121 Tabla 37: Requisito de información 1: Información de la auditoría ...... 121

Tabla 38: Requisito de información 2: Información sobre hallazgos ...... 122 Tabla 39: Requisito de información 3: Información de seguimientos ...... 123 Tabla 40: Requisito de información 4: Información sobre usuarios ...... 123 Tabla 41: Requisito de información 5: Indicadores de gestión ...... 124 Tabla 42: Requisito de información 6: Documentación ...... 125 Tabla 43: RF-01: Crear auditoría...... 126 Tabla 44: RF-02: Modificar auditoría...... 127 Tabla 45: RF-03: Agregar origen...... 127 Tabla 46: RF-04: Modificar origen agregado...... 128 Tabla 47: RF-05: Eliminar origen agregado...... 129 Tabla 48: RF-06: Agregar campos personalizados...... 130 Tabla 49: RF-07: Modificar campos personalizados agregados...... 131 Tabla 50: RF-08: Eliminar campos personalizados agregados...... 132 Tabla 51: RF-09: Agregar usuarios a la auditoría...... 133 Tabla 52: RF-10: Agregar usuarios a la auditoría ...... 134 Tabla 53: RF-11: Quitar usuarios a la auditoría...... 135 Tabla 54: RF-12: Subir documentos ...... 136 Tabla 55: RF-13: Agregar hallazgos ...... 136 Tabla 56: RF-14: Seleccionar prueba...... 137 Tabla 57: RF-15: Ver hallazgo...... 138 Tabla 58: RF-16: Cambiar estado hallazgo ...... 139 Tabla 59: RF-17: Asignar hallazgo ...... 140 Tabla 60: RF-18: Cerrar hallazgo...... 141 Tabla 61: RF-19: Agregar seguimiento ...... 141 Tabla 62: RF-20: Monitorizar hallazgo ...... 142 Tabla 63: RF-21: Agregar monitor a hallazgo ...... 143 Tabla 64: RF-22: Quitar monitor a hallazgo...... 144 Tabla 65: RF-23: Agregar archivo a hallazgo...... 144 Tabla 66: RF-24: Registrar eventos hallazgo ...... 145 Tabla 67: RF-25: Imprimir hallazgos ...... 146 Tabla 68: RF-26: Crear campos personalizados...... 147 Tabla 69: RF-27: Modificar campos personalizados...... 147 Tabla 70: RF-28: Eliminar campos personalizados...... 148 Tabla 71: RF-29: Crear usuarios ...... 149 Tabla 72: RF-30: Modificar usuarios...... 150 Tabla 73: RF-31: Eliminar usuarios ...... 151 Tabla 74: RF-32: Iniciar sesión...... 151 Tabla 75: RF-33: Cerrar sesión...... 152 Tabla 76: RF-34: Modificar datos cuenta...... 153 Tabla 77: Actor espectador ...... 153

Tabla 78: Actor auditor ...... 154 Tabla 79: Actor líder ...... 154 Tabla 80: Actor administrador ...... 154 Tabla 81: Entorno de ejecución del servidor...... 155 Tabla 82: Tiempo de respuesta del Sistema...... 155 Tabla 83: Disponibilidad del Sistema...... 156 Tabla 84: Presentación del Sistema...... 156 Tabla 85: Requisitos del sistema Vs. Objetivos del Sistema...... 157 Tabla 86: Caso de prueba login_01: Inicio de sesión correcto ...... 179 Tabla 87: Caso de prueba login_02: Inicio de sesión expirada ...... 179 Tabla 88: Caso de prueba logout_01: Cerrar sesión ...... 179 Tabla 89: Caso de prueba modify_01: Modificar datos propios de usuario ...... 180 Tabla 90: Caso de prueba create_01: Crear usuario ...... 180 Tabla 91: Caso de prueba modify_02: Modificar datos cualquier usuario ...... 181 Tabla 92: Caso de prueba delete_01: Eliminar usuario ...... 181 Tabla 93: Caso de prueba audit_01: Crear auditoría ...... 182 Tabla 94: Caso de prueba audit_02: Modificar Auditoría ...... 182 Tabla 95: Caso de prueba audit_03: Acceder a auditoría ...... 183 Tabla 96: Caso de prueba origin_01: Agregar origen de auditoría ...... 183 Tabla 97: Caso de prueba origin_02: Modificar origen de auditoría ...... 183 Tabla 98: Caso de prueba origin_03: Eliminar origen de auditoría...... 184 Tabla 99: Caso de prueba aud_field_01: Agregar campos personalizados...... 184 Tabla 100: Caso de prueba aud_field_02: Modificar origen de auditoría...... 185 Tabla 101: Caso de prueba aud_field_03: Eliminar campos personalizados agregados...... 185 Tabla 102: Caso de prueba usr_audit_01: Agregar usuarios a la auditoría...... 186 Tabla 103: Caso de prueba usr_audit_02: Quitar usuarios a la auditoría...... 186 Tabla 104: Caso de prueba finding_01: Agregar hallazgos...... 187 Tabla 105: Caso de prueba finding_02: Modificar hallazgos...... 187 Tabla 106: Caso de prueba finding_03: Ver hallazgo ...... 188 Tabla 107: Caso de prueba finding_04: Cambiar estado hallazgo...... 188 Tabla 108: Caso de prueba finding_05: Asignar hallazgo...... 189 Tabla 109: Caso de prueba finding_06: Cerrar hallazgo...... 189 Tabla 110: Caso de prueba trace_finding_01: Agregar seguimiento...... 190 Tabla 111: Caso de prueba mon_finding_01: Monitorizar hallazgo...... 190 Tabla 112: Caso de prueba mon_finding_02: Agregar monitor a hallazgo...... 191 Tabla 113: Caso de prueba mon_finding_03: Quitar monitor a hallazgo...... 191 Tabla 114: Caso de prueba file_finding_01: Agregar archivo a hallazgo...... 191 Tabla 115: Caso de prueba cust_field_01: Crear campos personalizados...... 192 Tabla 116: Caso de prueba cust_field_02: Modificar campos personalizados...... 192 Tabla 117: Caso de prueba cust_field_03: Eliminar campos personalizados...... 193

GLOSARIO

Administrador: Es el encargado de mantener el correcto funcionamiento de sistemas informáticos o aplicaciones concretas como servidores o aplicaciones Web.

Algoritmo: Conjunto de instrucciones que permiten realizar una tarea y/o solucionar un problema.

API (Application Programming Interface): Conjunto de procedimientos y funciones que permiten mediante una capa de abstracción acceder a funcionalidades de bajo nivel de manera local o remota, son usadas o incluidas en librerías de tecnologías específicas y lenguajes de programación.

Aplicación Web: Es una aplicación que se encuentra implementada en arquitectura cliente-servidor y tecnologías de internet. Se accede mediante un navegador y, una conexión de acceso a internet o una red interna.

Archivo: Conjunto de bits almacenados de manera unitaria, con su propia codificación y extensión, que se encuentra almacenado en un directorio de manera lógica y en un dispositivo de almacenamiento de manera física.

Atacante: Individuo con conocimientos técnicos que se dedican a acceder a sistemas informáticos por medios avanzados y aprovechando debilidades de estos, sin importar su fin e intenciones.

Ataque: Acción que realiza un individuo de acceder y/o tomar el control de un sistema para fines determinados.

Auditoría: Inspección y análisis que se realiza a los sistemas informáticos con base en normas y metodológicas existentes, con el fin de asegurar la efectividad de los sistemas dentro de un contexto organizacional.

Autenticación: conjunto de técnicas y métodos que permiten garantizar la autenticidad de la información ingresada en un sistema.

Backend (Aplicación Web): Modulo de una aplicación Web que provee servicios administrativos sobre algunas funcionalidades definidas.

Backup: Copia de respaldo o seguridad de la información que se realiza con el propósito de prevenir perdidas de información, y ser realiza conforme a un plan de recuperación de desastres.

Base de datos: Conjunto de datos almacenados sistemáticamente, indexados y relacionados para su mejor búsqueda, y relacionada a un contexto especifico.

Clave: Conjunto finito de caracteres de distinta procedencia que permiten acceder a la información o a un sistema de diferentes maneras mediante un proceso de validación.

Cliente: Una entidad (computador) que solicita servicios de un servidor a través de una red, aunque dichas peticiones las puede finalizar el mismo de forma que el procesamiento de la información es realizado entre ambas partes.

Configuración: Conjunto de datos de tipo paramétrico de un sistema o aplicación que determinan el funcionamiento de ciertas características de estos.

Contraseña: Clave que permite el acceso en conjunto con un alias de usuario a un sistema informático o aplicación web.

Control de acceso: Procedimientos de seguridad física o lógica cuyo propósito es la administración e implementación de accesos a sistemas informáticos.

Control: Conjunto de procedimientos que mediante procesos de análisis de los elementos de un sistema informático, permiten conocer su estado y realizar una toma de decisiones en cuanto a la mejora o corrección de este.

Cross Site Request Forgery (CSRF): Falsificación de Peticiones en Sitios Cruzados, técnica mediante la cual el atacante pasándose por un usuario de confianza, envía comandos a un sitio causando acciones indeseadas.

Cross-Site Scripting (XSS): Secuencia de Comandos en Sitios, técnica mediante la cual se inyecta código malicioso en sitios web legítimos mediante la inclusión directa en código HTML o la manipulación de solicitudes HTTP en direcciones URL.

CSS (Cascade Style Sheet): Hoja de estilos en cascada, lenguaje que permite almacenar una configuración que incluye los parámetros de presentación de las etiquetas en documentos HTML y XHTML.

Cuenta: Configuración individual que le permite a un usuario realizar operaciones en un sistema con ciertos privilegios definidos por los administradores.

Dato: Representación simbólica de un atributo de una entidad en contextos específicos, a menudo es descriptivos.

DBMS (Data Base Management System): Sistema de gestión, de bases de datos, conjunto de programas que permiten administrar una base de datos.

Denegación de servicio: Acción de denegar el acceso a recursos y servicios del sistema a usuarios legítimos mediante técnicas de hacking.

Desarrollador: Persona que se dedica a programar y realizar distintos proyectos de software en varios lenguajes.

Detección: Acción de encontrar elementos anormales en un sistema, con el propósito de tomar medidas para evitar daños.

Dirección: Identificación usada por un sistema o software para ubicar elementos como recursos u otros sistemas.

Directorio: Espacio definido en un sistema de archivos para el almacenamiento de archivos u otros directorios.

DNS: Servidor de red que cumple la función de registrar y direccionar dominios mediante relaciones de nombre y direcciones IP, para permitir la localización de otros servidores, computadores o recursos en Internet o en redes internas.

Error: Fallo de un programa o de dispositivos físicos que impiden el funcionamiento normal de un sistema y a menudo se traduce en resultados indeseados.

Exploit: Programa o rutina que aprovecha vulnerabilidades específicas de aplicaciones y sistemas operativos para aprovecharlos con fines maliciosos en conjunto con un atacante.

Formulario: Documento con espacios llamados campos, en los cuales los usuarios introducen información sobre un contexto especifico, y son enviados generalmente a servidores web mediante peticiones.

Framework: Marco de trabajo, en programación es un conjunto de componentes que permiten simplificar el desarrollo de software en lenguajes específicos.

Frontend: Se refiere a los módulos o parte de estos que componen las aplicaciones web, que presentan información al usuario final en las páginas visibles al público.

FTP (File Transfer Protocol): Protocolo de arquitectura cliente –servidor, el cual es usado para transferencia directa de archivos en una red de tipo TCP/IP.

Función: Rutina que hace parte de un programa y que puede ser llamada un número finito de veces de manera programática.

Hacking: Acto de realizar penetraciones en sistemas informáticos mediante distintas técnicas y medios avanzados.

HTML (HyperText Markup Language): Lenguaje de marcado hipertexto, es un lenguaje predominante para la construcción de páginas web, consistente en una estructura de etiquetas jerárquicas que corresponden a macro y micro componentes, visibles o no.

HTTP (HyperText Transfer Protocol): Protocolo de Transferencia de Hipertexto, actualmente es el protocolo usado para envió y recepción de peticiones de arquitectura cliente/servidor mediante un esquema URL.

Impacto: Consecuencias finales de un riesgo sobre sistemas informáticos, medidas de varias maneras de acuerdo a la metodología de auditoría usada.

Integridad: Grado de completitud y no modificación de la información.

IP (Internet Protocol): Protocolo de internet, conjunto de reglas que permiten la conexión y envió de paquetes a través de la red, utilizando un direccionamiento numérico.

JavaScript: Lenguaje de rutinas interpretado que ejecuta secuencias en un navegador web incrustadas dentro de páginas escritas en HTML o también de forma directa por los navegadores para agregar funcionalidades extra.

Log: Es un registro de las transacciones de un sistema informático o de aplicaciones y servicios concretos, usada para fines de control y auditoria.

Navegador Web: Programa que permite la navegación en sitios de Internet mediante la interpretación y presentación de múltiples tecnologías asociadas, comúnmente HTML y JavaScript.

OpenUP: Es una metodología y un proceso de desarrollo de software propuesto por un conjunto de empresas de tecnología, quienes lo donaron en el año 2007 a la Fundación Eclipse.

Petición: Solicitud que se hace mediante un protocolo específico entre dos máquinas para la realización de operaciones.

PHP (HyperText Preprocessor): Es un lenguaje de rutinas multiplataforma de lado del servidor e interpretado, con el cual se crean sitios web de contenido dinámico.

Política: Conjunto de reglas específicas y normas que establecen la forma de realizar procesos de manera correcta y previniendo riesgos.

Privilegio: Regla que concede el uso de funcionalidades avanzadas en un sistema informático a determinados usuarios o simplemente negarlos.

Redirección: Acción de redirigir entre un par de direcciones a un usuario, por parte de un sistema informático o una aplicación web.

Servidor: Es un computador o servicio que provee servicios a clientes mediante el envío y recepción de solicitudes remotas.

Servidor Web: Servicio que procesa solicitudes y provee servicios web mediante el protocolo HTTP.

Sesión: Secuencia de páginas que visita un usuario en una aplicación web desde que inicia la conexión hasta que la finaliza el o el servidor web después de un tiempo determinado de inactividad del usuario.

Sistema operativo: Conjunto de programas y componentes que controlan un computador y proveen una capa de ejecución entre el hardware, los programas y el usuario.

Software: Componentes lógicos que ejecutan tareas específicas en el hardware en conjunto para la formación de sistemas de información.

SQL (Structured Query Language): Lenguaje estándar para el manejo e implementación de bases de datos relacionales mediante el uso de consultas y algebra relacional.

URL (Uniform Resource Locator): Sistema de identificación de direcciones mediante caracteres para la representación de recursos en una red o internet, normalmente sitios o directorios.

Usuario: Persona que interactúa con un sistema informático tanto en el envío y recepción de información, como en la interacción en el uso de servicios que provee el sistema.

Web 2.0: Segunda generación de la Web, se refiere a páginas que ofrecen un contenido dinámico y mayor interactividad entre los usuarios, gracias a las tecnologías que permiten funcionalidades avanzadas en sitios web y la creación de servicios web nuevos.

XML (eXtensible Markup Language): Lenguaje usado para el intercambio de información, con una estructura de etiquetas jerárquicas en forma de información estructurada, para presentación de documentos, usado para el intercambio de información entre varias plataformas y asegurar interoperabilidad.

1. INTRODUCCIÓN

Los sistemas de software se han convertido en herramientas indispensables para llevar a cabo, entre otros, los procesos operativos al interior de una Organización, de manera ágil y efectiva. Dicho rol, no ha pasado desapercibido en las Entidades del sector público distrital, en donde la implementación de soluciones de software ha sido el engranaje perfecto para el desarrollo de los planes estratégicos al interior de las mismas, y a su vez un componente fundamental dentro de los gastos de inversión del presupuesto de la ciudad.

En la actualidad, hablar de Entidades Distritales que no cuenten con sistemas de información para gestionar la totalidad, o parte, de sus procesos operativos no es posible, ya que todos los sectores de la Administración Distrital cuentan con software especializado en alguno de los diferentes procesos institucionales, como lo son los estratégicos, misionales, administrativos y de control1. Es por ello que se hace indispensable buscar mecanismos que permitan gestionar eficientemente los procesos internos de las entidades de Distrito beneficiándose de las bondades que trae la implementación de software en las diferentes unidades de negocio.

También cabe resaltar que gran parte del software existente en las Entidades es propietario, con lo cual se están llevando a cabo esfuerzos para migrar muchas de estas plataformas existentes a software libre, lo cual supone una amplia gama de oportunidades para aquellos jóvenes y profesionales, que en esfuerzos colectivos puedan impactar el desarrollo e implementación de estas herramientas para la optimización de recursos en el Distrito. El Distrito Capital ha venido estimulado2 desde ya hace varios años, una política pública de software libre a fin de racionalizar el gasto en cada una de las Entidades pertenecientes a la administración distrital.

Adicionalmente, se puede apreciar un gran número de entidades del distrito llevando a cabo parte de sus procesos operativos de una manera manual o en su defecto haciendo uso únicamente de hojas de cálculo y procesadores de texto. Esto puede deberse, en gran medida, a los altos costos que trae para una Entidad llegar a automatizar el 100% de todos sus procesos tanto misionales, administrativos y de evaluación y mejoramiento continuo, mediante la implementación de software hecho a la medida.

1 Los indicadores reportados por la comisión distrital de sistemas reportan niveles de cumplimiento superiores al 90% para el primer trimestre de 2012, el documento se puede consultar en http://www.cds.gov.co/images/Documentos/gestionCDS/2013/informe_consolidado_indicadores_de_gesti on_cds_I_trimestre_2012.pdf 2 Se recomienda en la resolución 305 de 2008, en su capítulo tercero, artículos 64 al 69, disponible en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=33486

1.1. DESCRIPCIÓN DEL PROBLEMA

Se puede observar en varias entidades que para formular un plan de mejoramiento recurren a extensas hojas de cálculo, llamadas matrices de plan de mejoramiento, con un gran número de columnas que normalmente son mayores a 15 y un sin número de filas de acuerdo a la cantidad de observaciones y hallazgos encontrados en las diferentes auditorías realizadas al interior de la Organización o por los Entes de Control.

Posterior a la formulación del plan de mejoramiento, se evidencia claramente la dificultad a la que se ven expuestos los auditores de la Organización e inclusive los líderes de proceso y/o jefes de oficina, para hacer seguimiento periódico a las acciones de mejora propuestas para cerrar los hallazgos producto de las auditorías. Llevar a cabo dichas tareas, en hojas de cálculo que están modificando varias personas al mismo tiempo, supone un desperdicio de tiempo por parte de los implicados, inclusive de recursos físicos como excesivo papel, impresiones y espacio físico de archivo.

Adicional a ello, se observa la dificultad de tener continuidad y trazabilidad a las acciones de mejora realizadas por los diferentes líderes de proceso y/o jefes de área, inclusive en los seguimientos realizados por los auditores, en cuanto que hay Entidades en donde la rotación del personal es bastante grande por lo cual, a la llegada de una nueva persona, por lo general se pierde el rumbo de cómo estaban las cosas y en muchas ocasiones se ve la necesidad de reconstruir todas las actividades realizadas previamente para saber en qué avance de ejecución se encuentra una acción de mejora.

Otro aspecto a tener en cuenta, son todas las evidencias y registros documentales que soportan la gestión para un cierre de hallazgo. Es recurrente observar que dichos registros hay que consultarlos en más de una fuente, como lo pueden ser: carpetas, A- Z, archivos de computador, documentos que no están en la oficina, sino que están en otra, lo cual dificulta al máximo la tarea del auditor de realizar seguimiento a las acciones realizadas por el responsable de resolver el hallazgo.

Observando los diferentes sectores que componen la Administración Pública del Distrito Capital, todos son susceptibles a los procesos de auditoría interna y externa. Analizando uno de esos sectores, el sector Gobierno quién es el encargado de orientar y liderar las políticas de gobierno del Distrito, se evidencia que en el seguimiento realizado a los planes de mejoramiento3 de cada una de las alcaldías locales, estas cuentan con una gran cantidad de hallazgos y acciones.

3 http://www.gobiernobogota.gov.co/Informes/Informes%20de%20Control%20Interno/Planes%20de%20 Mejoramiento%20Contralor%C3%ADa/2014/20143710496783%20ALC%20SANTAFE0001.pdf

Figura 1 Consolidado Hallazgos alcaldías locales

Por otro lado, en la última Auditoría Regular realizada por la Contraloría de Bogotá a La Secretaría de Gobierno, dejó en evidencia 35 hallazgos4 a los cuales se les realiza seguimiento mediante la siguiente matriz establecida por la Contraloría.

Figura 2: Matriz de seguimiento plan de mejoramiento Secretaría de Gobierno

En la anterior Figura, se puede observar que dicha matriz de seguimiento es bastante robusta; cuando la cantidad de hallazgos de una entidad es bastante grande y además crece año tras año, llega un punto en donde buscar información histórica referente a

4 http://www.gobiernobogota.gov.co/Informes/Informes%20de%20Control%20Interno/Planes%20de%20 Mejoramiento%20Contralor%C3%ADa/2014/PLAN%20%20MEJORAMIENTO%202014-Final.pdf

17 algún hallazgo se vuelve una tarea muy dispendiosa, en el sentido que el volumen de documentos se empieza a hacer bastante extenso. Igualmente, al momento de realizar seguimiento

En la vigencia 2014, la Contraloría de Bogotá realizó 11 auditorías regulares y 3 auditorías especiales a las Entidades pertenecientes al sector salud, para un total de hallazgos de 403.

Figura 3: Hallazgos de auditorías sector salud – Contraloría de Bogotá5.

Auditorías Contraloría Distrital 2014 Sector Salud Entidad No. De Hallazgos Auditoría regular No. De Hallazgos Auditoría Especial Total Hallazgos Hospital de Suba 32 0 32 Capital Salud 40 0 40 Hospital de Bosa 32 0 32 Hospial Centro Oriente 47 0 47 Hospital Engativa 38 0 38 Hopital Fontibón 31 0 31 Hospital Meissen 37 0 37 Hospital Pablo VI 5 0 5 Hospital San Blas 46 0 46 Hospital Tunjuelito 23 0 23 Hospital Usme 34 0 34 Hospital Tunal 0 8 8 Hospital La Victoria 0 9 9 Secretaría Ditrital de Salud 0 21 21 Total Hallazgos 365 38 403

En promedio, cada a entidad le formulan 29 hallazgos. Para cada una de estas Entidades, realizar la gestión de planes de mejoramiento de dichos hallazgos, en combinación con los hallazgos provenientes de auditorías internas, puede llegar a resultar bastante tedioso, en la medida que la información generada para la resolución de las acciones correctivas va creciendo considerablemente conforme va pasando el tiempo; esto combinado con la matriz de seguimiento que tiene establecida la Contraloría, la cual es bastante extensa, como se pudo observar en la figura 2, dificulta la ejecución y seguimiento manual de los respectivos planes de mejora.

1.2. FORMULACIÓN DEL PROBLEMA

¿Cómo implementar un aplicativo que permita a las Entidades del Distrito Capital realizar un seguimiento ágil y efectivo a los planes de mejoramiento producto de las diferentes auditorías internas y externas, visto como un elemento de control del Modelo Estándar de Control Interno (MECI), a un bajo costo?

5 http://www.contraloriabogota.gov.co/

2. JUSTIFICACIÓN

Hay que tener en cuenta, que gran parte de las actividades que se realizan en el distrito están reglamentadas, bien sea por normatividad distrital o de orden estatal. En este sentido, el mejoramiento continuo en las Entidades se encuentra expresamente formulado en el Modelo Estándar de Control Interno – MECI en los elementos de control de planes de mejoramiento institucional y por procesos. En este sentido, es necesario optimizar el tiempo y los recursos necesarios para dicha actividad en el Distrito.

La normatividad existente referente a los mecanismos de control y autocontrol que deben existir e implementarse en las Entidades de Distrito está expuesta en el decreto 1599 MECI: 2005 “Modelo Estándar de Control Interno”. Dicha normatividad contempla los mecanismos mediante los cuales las Entidades Públicas deben ejercer el control interno, lo cual es aplicable a cada uno de los miembros de la Organización, con el fin de propiciar la cultura del autocontrol. La implementación del MECI en las Entidades del Distrito está dado por el cumplimiento de una serie de componentes y elementos de control contenidos dentro de tres grandes subsistemas que son: Subsistema de Control Estratégico, Subsistema de Control de Gestión y Subsistema de Control de Evaluación.

El componente del MECI que finaliza el ciclo PHVA (planear, hacer, verificar y actuar) es el de planes de mejoramiento, compuesto por los elementos de control de: Plan de Mejoramiento Institucional, Plan de Mejoramiento por Procesos y Plan de Mejoramiento Individual. Este componente permite a la alta gerencia tomar medidas respecto a desviaciones detectadas en el ejercicio de las funciones propias de la organización, a fin de incentivar el mejoramiento continuo de cada uno de los funcionarios y los procesos.

Es necesario para los auditores, líderes de proceso y alta gerencia contar con un sistema que centralice la información producto de las acciones de mejora propuestas para cerrar los hallazgos provenientes de las auditorías, de una manera ágil y efectiva, para lo cual se requiere el desarrollo de un software que permitirá gestionar los diferentes planes de mejoramiento que se suscriben, producto de las auditorías tanto internas como externas, realizadas a la Organización.

Existen diversas herramientas de software en el mercado que permiten a las entidades llevar a cabo la implementación holística de los componentes y elementos del MECI, entre ellos el de planes de mejoramiento, que en armonía con el sistema de garantía de la calidad NTCGP-1000 exhortan a estas al mejoramiento continuo llevando a cabo el ciclo PHVA. Sin embargo, el costo de dichas herramientas puede llegar a ser bastante elevado, más aún en entidades que no cuentan con recursos necesarios y suficientes, por lo cual esta herramienta permitirá mitigar costos relacionados en cuanto que se hará uso de herramientas existentes de software libre para la gestión de incidencias.

Si bien se han establecido políticas y se han realizado algunas implementaciones de software libre en algunas Entidades del Distrito, todavía sigue priorizado el gasto y la

19 inversión en la adquisición de software propietario y la implementación de software libre ha estado limitada básicamente a servidores de correo, CMS, servidores Web, sistemas operativos y ofimática, salvo algunas excepciones como por ejemplo la Secretaría de Gobierno con su Sistema de Gestión Documental ORFEO6.

La implementación de esta herramienta se realizará mediante el uso de aplicaciones de software libre de conformidad con las políticas Distritales referente este tema, permitiendo dotar a las Entidades del Distrito de una herramienta estándar para la gestión de planes de mejoramiento ahorrando costos de implementación y licencias.

Con la herramienta desarrollada se podrá hacer la adaptación e implementación de un sistema de gestión de planes de mejoramiento para Entidades del Distrito en concordancia, teniendo como base los parámetros establecidos en el MECI y la Resolución 003 de 2014 de la Contraloría de Bogotá D.C., para la presentación del informe de plan de mejoramiento a la Contraloría de Bogotá.

Otros beneficios que traería la implementación de un sistema de tales características son:

• Centralización de la información.

• Seguimiento por parte del auditor.

• Recopilación de evidencias en un solo lugar.

• Realización de informes estadísticos automáticos.

• Minimización de riesgos por el incumplimiento de la ejecución de planes de mejoramiento formulados para resolver hallazgos de entes de control.

• Monitoreo constante a hallazgos próximos a vencer su plazo de ejecución.

• Trazabilidad de las acciones de mejora e impacto mínimo en la continuidad de actividades por la eventual rotación de personal.

• Notificación por correo electrónico ante cualquier evento que se produzca en los hallazgos que se están gestionando.

6 http://gestion.gobiernobogota.gov.co/wiki/doku.php/orfeo:inicio

3. OBJETIVOS

3.1. OBJETIVO GENERAL

Desarrollar e implementar un sistema que permita a las Entidades del Distrito gestionar los elementos de control del MECI (Modelo Estándar de Control Interno) de plan de mejoramiento por procesos y plan de mejoramiento Institucional mediante el uso de herramientas de software libre.

3.2. OBJETIVOS ESPECÍFICOS

• Discriminar la cantidad de hallazgos que formuló la Contraloría de Bogotá a los Entes Sujetos de Control en las auditorías regulares y especiales realizadas en la vigencia 2014.

• Compilar el plan de mejoramiento realizado por una Entidad que haya sido auditada por la Contraloría de Bogotá en el 2014.

• Ingresar en el Aplicativo el plan de mejoramiento compilado.

• Realizar entrevistas a 10 funcionarios de la Entidad la cual se compiló el plan de mejoramiento a fin de evaluar los beneficios del Aplicativo.

• Realizar un comparativo entre el tiempo destinado a realizar seguimiento a los planes de mejoramiento de manera tradicional Vs el seguimiento realizado por medio del Aplicativo.

• Medir la cantidad de espacio que ocupa el almacenamiento de todo el plan de mejoramiento en el disco duro del servidor y proyectar cuanto sería el almacenamiento necesario para un plan de mejoramiento de 1000 hallazgos.

• Diseñar 1 manual de administración y 1 manual de usuario que permitan un apropiado uso de la aplicación.

• Documentar el desarrollo de la aplicación para exponer sobre posibles desarrollos paralelos de aplicaciones con funciones similares en entidades en el distrito.

• Documentar plan de pruebas de la aplicación.

• Llevar a cabo un estudio de los costos que estarán presentes en el proyecto discriminados en costos de capital, costos de mantenimiento y costos de operación, lo cual será parte integral del análisis de Costo-Beneficio, a fin de evaluar la posible implementación en Entidades del Estado.

4. MARCO REFERENCIAL

Para efectos de conocer el entorno conceptual mediante el cual se desarrollará el presente proyecto, se hace necesario conocer las diferentes temáticas bajo las cuales se enmarca el mismo. Se empezará planteando la definición de plan de mejoramiento, la principal norma que lo rige y los diferentes modelos de gestión, como el MECI y la NTCGP:1000 que hacen uso de él como parte fundamental de sus componentes de control.

Adicionalmente, se realizará una explicación de las herramientas de desarrollo que se usarán para el desarrollo del proyecto, así como la metodología de desarrollo, que para efectos del presente proyecto se optará por hacer uso de la metodología OpenRUP.

4.1. PLAN DE MEJORAMIENTO

El mejoramiento continuo está contemplado en la administración pública tanto en el sistema de control interno como en el Sistema de Gestión de la Calidad; la normatividad existente que define estos sistemas se encuentra dada en la Ley 87 de 19937, Ley 489 de 19988, Ley 872 de 20039, La Norma Técnica de Calidad en la Gestión Pública y el Modelo Estándar de Control Interno (MECI) – Decreto 1599 de 200510. Es por ello que se hace de obligatoria aplicación un plan de mejoramiento como una “hoja de ruta” que permita estandarizar los procesos de control y auditoría en las entidades del distrito en conformidad con la normativa establecida. A continuación se expondrá de manera breve las principales leyes que se aplican y guían la implementación de metodologías de control para el ámbito distrital.

4.1.1. LEY 87 DE 1993

Los principios y reglas del control interno se encuentran definidos en esta primera ley, la cual establece en cada uno de sus artículos las normas para implementar el control interno en las entidades gubernamentales; esta ley pretende mediante una serie de parámetros reglamentar el ejercicio del control interno, permitiendo estandarizar en primera instancia la aplicación de controles internos. Esta ley está comprendida por los siguientes artículos:

 Artículo 1°: Definición del control interno: La norma establece la siguiente definición de control interno:

7 Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley/1993/ley_0087_1993.html 8 Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley/1998/ley_0489_1998.html 9 Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley/2003/ley_0872_2003.html 10 Disponible en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=16547

“Se entiende por control interno el sistema integrado por el esquema de organización y el conjunto de los planes, métodos, principios, normas, procedimientos y mecanismos de verificación y evaluación adoptados por una entidad, con el fin de procurar que todas las actividades, operaciones y actuaciones, así como la administración de la información y los recursos, se realicen de acuerdo con las normas constitucionales y legales vigentes dentro de las políticas trazadas por la dirección y en atención a las metas u objetivos previstos”

En el parágrafo respectivo se establece la aplicación del control interno a través de las políticas que establezcan dichas entidades.

 Artículo 2°: Objetivos del sistema de Control Interno: Los objetivos que se deben cumplir para lograr la función de control interno se establecen en este artículo, atendiendo los principios constitucionales del ejercicio de la función pública. Así mismo se establecen las características de la oficina de control interno (tomándolo como base para la realización de este trabajo y su posterior aplicación a nivel local) en el artículo 1011 del Decreto Nacional 205 de 2003.

 Artículo 3°: Características del Control Interno: Define las características del ejercicio de control interno, cabe destacar que parte de las funciones de la aplicación desarrollada en este proyecto en cuanto a la ejecución efectiva de este ejercicio, se establecen en el numeral e:

“Todas las transacciones de las entidades deberán registrarse en forma exacta, veraz y oportuna de forma tal que permita preparar informes operativos, administrativos y financieros”.

 Artículo 4°: Elementos para el Sistema de Control Interno: Establece los elementos que debe tener la implementación del control interno para su aplicación directa bajo responsabilidad de los directivos.

 Artículo 5°: Campo de aplicación: Según este artículo, se debe aplicar el control interno en las entidades donde el estado posea más de un 90% de capital social.

 Artículo 6°: Responsabilidad del control interno: Los responsables sobre la implementación del control interno deberá ser asumida por los representantes legales y los jefes de las distintas dependencias que componen las entidades.

 Artículo 7°: Contratación del servicio de control interno con empresas privadas: Delimita las condiciones para la contratación de servicios de auditoría por parte de empresas colombianas.

 Artículo 8°: Evaluación y control de gestión en las organizaciones: El representante legal deberá vigilar la apropiada implementación de un sistema de evaluación y control de la gestión.

11 Disponible en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=16546#10

 Artículo 9°: Definición de la unidad u oficina de coordinación del control interno: Se define el concepto de oficina de control interno, encargada de vigilar los entes de control en las entidades públicas.

 Artículo 10°: Jefe de la unidad u oficina de coordinación del Control Interno: En conjunto con el decreto nacional 1826 de 199412, se reglamenta la designación de funcionario de nivel jerárquico superior para las funciones de, jefe de control interno.

 Artículo 11°: Designación del jefe de la unidad u oficina de coordinación del Control Interno: Define los parámetros para la designación de auditores, norma modificada por Ley 1474 de 201113 y reglamentado por Decreto 1826 de 1994.

 Artículo 12°: Funciones de los auditores internos: En conjunto con el Decreto 1826 de 1994, se reglamenta y definen las funciones de los auditores internos. Se destaca que la aplicación a desarrollar en el presente proyecto apoyaría parte de estas funciones.

 Artículo 13°: Comité de Coordinación del Sistema de Control Interno: Conforme a lo establecido en el artículo 5 de la presente ley, los altos niveles jerárquicos deberán establecer el comité citado en el título de este artículo, bajo reglamento del Decreto 1826 de 1994.

 Artículo 14°: Informe de los funcionarios del Control Interno: Modificando por la Ley 1474 de 2011, establece el valor probatorio de los informes de auditoría en procesos de investigación, en la ley 1474 se detallan en profundidad las condiciones para definir este valor probatorio.

 Artículo 15°: Término de Aplicación: Estable las condiciones de aplicación a partir de la vigencia de la ley. 29 de noviembre de 1993

 Artículo 16°: Vigencia: La promulgación de la ley se hizo el 29 de noviembre de 1993.

Dado los dos últimos artículos, se establece que la mayoría de entidades ya deben contar con un sistema de control interno, lo cual justifica en este trabajo la implementación de un sistema que se encuentre en conformidad con esta ley para el ámbito de aplicación del proyecto.

4.1.2. MECI

Mediante el Decreto 1599 de 2005 y con el fin de armonizar los sistemas de control en las entidades públicas, se crea el Modelo Estándar de Control Interno también conocida como MECI: 2005, por el cual se adopta el Modelo Estándar de Control Interno para las entidades del estado. Esta herramienta permite crear y aplicar planes de mejoramiento en conjunto con las normas ISO 9001 y GP 1000:2004 para el control

12 Disponible en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=4576 13 Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley/2011/ley_1474_2011.html

24 de la calidad. También está basado en sistemas de control internos validos a nivel internacional como lo son el COSO (Committee of Sponsoring Organizations), el COCO (Criteria of Control.), el GAO (Government Accountability Office)14. Un vistazo general a la metodología es el siguiente:

Figura 4: Grafico explicativo de MECI

Fuente: Sitio de Auditoría y Control de Seguridad en la Información15

4.1.2.1. PRINCIPIOS16:

Como medida primaria y para guiar la implementación del MECI, se han definido los siguientes principios que se encuentran alineados con los principios constitucionales tal como se define en la norma.

 Autocontrol: Es la capacidad que ostenta cada servidor público para controlar su trabajo, detectar desviaciones y efectuar correctivos para el adecuado cumplimiento de los resultados que se esperan en el ejercicio de su función, de tal manera que la ejecución de los procesos, actividades y/o tareas bajo su responsabilidad, se desarrollen con fundamento en los principios establecidos en la Constitución Política.

 Autorregulación: Es la capacidad institucional para aplicar de manera participativa al interior de las entidades, los métodos y procedimientos que permitan el desarrollo e implementación del Sistema de Control Interno bajo un entorno de integridad, eficiencia y transparencia en la actuación pública.

14 Tomado de http://www.uceva.edu.co/index.php/modelos-gestion/meci.html 15 Tomado de http://auditorsystemgrp1.weebly.com/meci.html 16 Toda la información expuesta es tomada del numeral 1, decreto 1599 de 2005

 Autogestión: Es la capacidad institucional de toda entidad pública para interpretar, coordinar, aplicar y evaluar de manera efectiva, eficiente y eficaz la función administrativa que le ha sido asignada por la Constitución, la ley y sus reglamentos.

4.1.2.2. ESTRUCTURAS DE CONTROL:

De acuerdo a los artículos 3º y 4º de la Ley 87 de 1993 definen en general el MECI como un sistema, cuyas partes se componen de tres funciones principalmente como lo son los subsistemas, los controles y elementos de control. El siguiente diagrama describe la estructura del MECI:

Figura 5: Subsistemas del MECI

Fuente: Sitio Web del Municipio de Turbo, Antioquia17

En resumidas cuentas, los subsistemas de control que componen el MECI son18:

 Subsistema de control estratégico: Permiten la orientación estratégica y organizacional de la entidad. Está compuesta por los siguientes componentes:

o Componente ambiente de control: Está conformado por elementos de control que al interrelacionarse, otorgan una conciencia de control a la entidad pública influyendo de manera profunda en la planificación, la gestión de operaciones y en

17 http://meciturbo.blogspot.com/p/matriz-meci-turbo.html 18 Para mayor información sobre subsistemas del MECI, se puede consultar directamente el decreto1599 de 2005, en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=16547

los procesos de mejoramiento institucional, con base en el marco legal que le es aplicable a la entidad. Posee los siguientes elementos de control:

. Acuerdos, compromisos o protocolos éticos

. Desarrollo del Talento Humano

. Estilo de dirección

o Componente direccionamiento estratégico: Conjunto de elementos de control que al interrelacionarse, establecen el marco de referencia que orienta la entidad pública hacia el cumplimiento de su misión, el alcance de su visión y la conduce hacia el cumplimiento de sus objetivos globales. Posee los siguientes elementos de control:

. Planes y programas

. Modelo de operación por procesos

. Estructura organizacional

o Componente administración del riesgo: Conjunto de elementos de control que al interrelacionarse, permiten a la entidad pública evaluar aquellos eventos negativos, tanto internos como externos, que puedan afectar o impedir el logro de sus objetivos institucionales o los eventos positivos, que permitan identificar oportunidades, para un mejor cumplimiento de su función. Posee los siguientes elementos de control:

. Contexto estratégico

. Identificación del riesgo

. Análisis del riesgo

. Valoración del riesgo

. Políticas de administración del riesgo

 Subsistema de control de gestión: Conjunto de componentes de Control, que al interrelacionarse bajo la acción de los niveles de autoridad y/o responsabilidad correspondientes, aseguran el control a la ejecución de los procesos de la entidad pública, orientándola a la consecución de los resultados y productos necesarios para el cumplimiento de su misión.

o Componente actividades de control: Constituye el conjunto de elementos que garantizan el Control a la ejecución de la función, planes y programas de la entidad pública, haciendo efectivas las acciones necesarias al manejo de riesgos y orientando la operación hacia la consecución de sus resultados, metas y objetivos. Posee los siguientes elementos de control:

. Políticas de operación

. Procedimientos

. Controles

. Indicadores

. Manual de procedimientos

o Componente información: Componente de control, conformado por un conjunto de datos que al ser ordenados y procesados adquiere significado para los grupos de interés de la entidad pública a los que va dirigido. Hace parte fundamental de la operación de la entidad al convertirse en insumo para la ejecución de los procesos y a su vez en producto de los mismos. Garantiza la base de la transparencia de la actuación pública, la rendición de cuentas a la comunidad y el cumplimiento de obligaciones de información. Posee los siguientes elementos de control:

. Información primaria

. Información secundaria

. Sistemas de información

o Componente comunicación: Componente de control, que apoya la construcción de visión compartida, y el perfeccionamiento de las relaciones humanas de la entidad pública con sus grupos de interés internos y externos, facilitando el cumplimiento de sus objetivos institucionales y sociales, en concordancia con lo establecido en el artículo 32 de la Ley 489 de 1998. Posee los siguientes elementos de control:

. Comunicación organizacional

. Comunicación informativa

. Medios de comunicación

 Subsistema de control de evaluación: Conjunto de componentes de control que al actuar “interrelacionadamente”, permiten valorar en forma permanente la efectividad del Control Interno de la entidad pública; la eficiencia, eficacia y efectividad de los procesos; el nivel de ejecución de los planes y programas, los resultados de la gestión, detectar desviaciones, establecer tendencias y generar recomendaciones para orientar las acciones de mejoramiento de la organización pública.

o Componente autoevaluación: Conjunto de elementos de control que al actuar en forma coordinada en la entidad pública, permite en cada área organizacional medir la efectividad de los controles en los procesos y los resultados de la gestión en tiempo real, verificando su capacidad para cumplir las metas y resultados a su cargo y tomar las medidas correctivas que sean necesarias al cumplimiento de los objetivos previstos por la entidad. Posee los siguientes elementos de control:

. Autoevaluación del control

. Autoevaluación de gestión

o Componente evaluación independiente: Componente de control que garantiza el examen autónomo y objetivo del Sistema de Control Interno, la gestión y resultados corporativos de la entidad pública por parte de la oficina de Control Interno, Unidad de Auditoría Interna o quien haga sus veces. Presenta como características la independencia, la neutralidad y la objetividad de quien la realiza y debe corresponder a un plan y a un conjunto de programas que establecen objetivos específicos de evaluación al control, la gestión, los resultados y el seguimiento a los Planes de Mejoramiento de la entidad pública. Posee los siguientes elementos de control:

. Evaluación del Sistema de Control Interno

. Auditoría Interna

o Componente planes de mejoramiento: Conjunto de elementos de control, que consolidan las acciones de mejoramiento necesarias para corregir las desviaciones encontradas en el Sistema de Control Interno y en la gestión de operaciones, que se generan como consecuencia de los procesos de Autoevaluación, de Evaluación Independiente y en las observaciones formales provenientes de los Órganos de Control. Posee los siguientes elementos de control:

. Plan de Mejoramiento Institucional

. Planes de Mejoramiento por Procesos

. Planes de Mejoramiento Individual

4.1.2.3. ROLES Y RESPONSABILIDADES:

En MECI se definen unos roles con responsabilidades específicas que permiten su implementación a diferentes niveles y con el propósito de mantener el control. A continuación se expondrá brevemente los roles que se exponen en el MECI:

 Responsabilidad de la Alta Dirección: Asegurar la comunicación entre los diferentes niveles del sistema de control interno y la autoridad correspondiente.

 Representante de la Dirección: Cualquier representante legal de la alta dirección quien podrá realizar una evaluación independiente y haga parte del Comité de Control Interno.

 Comité de Coordinación de Control Interno: El Comité de Coordinación de Control Interno se reunirá por lo menos cada dos (2) meses. Deberá adoptar un reglamento interno y cumplir con las funciones establecidas en los Decretos 1826 de 1994 y 2145 de 1999.

 Servidores públicos y/o particulares que ejercen funciones públicas: En un sentido general, los funcionarios públicos deben velar por el correcto ejercicio y ejecución de sus funciones, aplicar los controles y realizar la autoevaluación correspondiente a sus funciones dentro del cargo.

 Oficina de Control Interno, Unidad de Auditoría o quien haga sus veces: Con base en los artículos 3º numeral d), 9º y 12 de la Ley 87 de 1993, es responsable por realizar evaluación independiente al Sistema de Control Interno y la Gestión de la entidad pública, así como por el seguimiento al Plan de Mejoramiento Institucional, generando las recomendaciones correspondientes y asesorando a la alta dirección para su puesta en marcha.

4.1.3. NTCGP:1000

En conformidad con la ley 872 de 200319, todas las entidades públicas deberán adoptar un sistema de gestión de la calidad; la normativa que reglamenta el sistema que debe ser adoptad en las entidades públicas pertenecientes a la rama del poder público, se publicó inicialmente con el decreto 4110 de 200420, por medio del cual se adopta la norma técnica de calidad en la gestión pública, en su primera versión conocida como NTCGP 1000: 2004; posteriormente la norma es modificada en el decreto 4485 DE 200921, el cual establece la actualización de la norma y de paso su adopción al nuevo estándar, ahora denominado NTCGP 1000: 2009, el cual rige a partir de la fecha de vigencia de la expedición del decreto. La sigla NTCGP se entiende por “Norma Técnica de Calidad en la Gestión Pública”.

Originalmente esta norma tiene el propósito de medir y mejorar el desempeño de las instituciones, mediante un enfoque de procesos y satisfacción del cliente, la implementación de la norma pretende unificar la manera en que se prestan servicios y la forma en que responden a las necesidades de los clientes, mediante un esquema de control y vigilancia continua. Algunas de las ventajas de la implementación de la norma son22:

 Mejora en la comunicación de los procesos y su interacción

 Medición y esquematización de riesgos mediante mapas y puntos de control

 Vigilancia sobre la prestación de servicios

 Se adapta a lo decretado en la ley 872 de 2003

 Adaptarse a la implementación de otras normas sobre gestión de la calidad en las que está basado NTCGP 1000: 2009 como ISO 9001

Esta norma en especial también puede complementarse con planes de mejoramiento como el descrito en el punto anterior de este trabajo (MECI). A continuación se expondrán los principales puntos establecidos actualmente la norma23.

19 Disponible en http://www.elabedul.net/San_Alejo/Leyes/Leyes_2003/ley_872_2003.php 20 Disponible en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=15423#0 21 Disponible en http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=37853#0 22 Adaptado de http://www.icontec.org/index.php/es/tipos-de-certificados-que-le-pueden-interesar/50- colombia/certificacion-sistema/333-gestion-de-la-calidad-ntcgp-1000 23 Los puntos expuestos a continuación son tomados directamente del documento de la norma NTCGP 1000: 2009

4.1.4. Generalidades

Los conceptos de los que parte la norma están establecidos como ya se mencionó en la ley 823 de 2003, en conjunto y derivado con normas sobre gestión de calidad existentes, como la más reciente y sobre la cual se realizó la última actualización como lo es la norma ISO 9001: 2008; sin embargo esta norma integra más conceptos orientados a la prestación de servicios en las entidades públicas.

Una de las bases para la aplicación de la norma es la metodología PHVA (Planear, Hacer, Verificar y Actuar), un proceso cíclico que permite una mejora continua al no establecer un punto de finalización y reevaluando el estado actual de la implementación de sistemas de mejora;

Figura 6: Esquema del ciclo PHVA adaptado a la norma NTCGP: 1000

Fuente: Norma NTCGP 1000: 2009, Instituto Nacional de Salud24

También se han definido los siguientes principios para la gestión de la calidad en entidades de la rama del poder público y otras entidades similares:

 Enfoque hacia el cliente: El objetivo principal es la satisfacción del cliente, mediante la compresión adecuada de las necesidades y los requisitos necesarios para lograrlo.

 Liderazgo: Mediante una concientización sobre el logro de los objetivos y mejorando el ambiente de trabajo, se logrará cumplir con el propósito del mejoramiento y la calidad por parte de los servidores públicos.

24 Disponible en http://190.26.202.205/recursos_user/imagenes//Calidad/PHVA_NTCGP_1000_2009.PNG

 Participación activa de los servidores públicos y/o particulares que ejercen funciones públicas: Se debe ejercer un compromiso activo por parte de los servidores en el cumplimiento de los logros de la entidad.

 Enfoque basado en procesos: Todas las actividades se manejan en conjunto como procesos los cuales están entrelazados en una red que permite su aplicación de manera acoplada.

 Enfoque del sistema para la gestión: Una compresión adecuada de los procesos permite el logro eficaz de los objetivos.

 Mejora continua: Gracias a la implementación de mejoras y buenas prácticas se puede lograr una mejora continuada en los productos y/o servicios que se ofrezcan.

 Enfoque basado en hechos y datos para la toma de decisiones: Las decisiones están basadas en datos y mediciones reales, permitiendo lograr una objetividad en la toma de estas decisiones.

 Relaciones mutuamente beneficiosas con los proveedores de bienes o servicios: Aunque las entidades y los proveedores son independientes, una relación equilibrada permite agregar un valor a la relación.

 Coordinación, cooperación y articulación: La mejor forma de brindar a los clientes un producto/servicio adecuado, se debe centrar en el trabajo en equipo el cual permite un uso racional de los recursos.

 Transparencia: Este principio se logra al permitir acceso a la información de los procesos que permite un mejor control social.

Cabe destacar que esta norma también está diseñada para trabajar en conjunto con otros sistemas de gestión de la calidad diferentes a los citados en este punto, con el objetivo de reforzar la mejora continua.

4.1.5. Ámbito de aplicación

Se confirma de acuerdo a los puntos anteriores que el ámbito para la aplicación de la norma son las entidades públicas pertenecientes a la rama del sector público, tal como lo especifica la ley 853 de 2003.

4.1.6. Sistema de gestión de la calidad

En este punto se especifican todos los requisitos para la implantación de un sistema de gestión de la calidad, conforme a los artículos 3 y 7 de la ley 853 de 2003; cabe destacar que la norma señala dos grupos de requisitos a cumplir:

Tabla 1: Elementos comunes entre NTGPC 1000: 2009 y MECI Modelo Estándar de Control Interno Norma Técnica de Calidad en la Gestión Pública Subsistema: Control Estratégico Numeral 4. Sistema de Gestión de la Calidad Componente: Direccionamiento Estratégico 4.1 Requisitos Generales Literales a, b, c, d, e y f

Intencionalidad del Verificar el cumplimiento de las condiciones que hacen posible el desarrollo de la Modelo Estándar de función para la cual fue creada la entidad, a través de la planeación, la Control Interno caracterización de los procesos y una estructura organizacional adecuada para el desarrollo de sus funciones. Intencionalidad de la Establecer, implementar y mantener un Sistema de Gestión de la Calidad que Norma Técnica de permita mejorar continuamente la eficacia, eficiencia y efectividad del Calidad en la Gestión desempeño de la organización dentro de un alcance que considere todos los Pública procesos que le permiten a la entidad cumplir su función. Desarrollo de una: - planificación del Sistema respectivo - identificación de sus procesos, su secuencia e interacción, - asignación de recursos para la operación y el seguimiento de los procesos, Aspectos comunes - desarrollo de la documentación necesaria para soportar la operación de los procesos y su interacción, - implementación de las acciones necesarias para alcanzar los resultados planificados (por ejemplo: programas, planes, proyectos, procedimientos, entre otras). Modelo Estándar de Control Interno Norma Técnica de Calidad en la Gestión Pública Subsistema: Control Estratégico Numeral 4. Sistema de Gestión de la Calidad Componente: Administración de riesgo 4.1 Requisitos Generales Elemento: Valoración de riesgos Literal g) Intencionalidad del Verificar que los controles existentes contribuyen a evitar, compartir o mitigar los Modelo Estándar de diferentes riesgos identificados en la entidad. Control Interno Intencionalidad de la Identificar las situaciones que pueden impedir el logro de los objetivos o Norma Técnica de desarrollo de los procesos y minimizar su materialización a través de acciones Calidad en la Gestión correctivas (en el caso de que el riesgo se hayan materializado) o preventivas. Pública Establecer controles sobre los riesgos que pueden impedir el logro de los objetivos de la entidad o el cumplimiento de su función. Aspectos comunes Los controles pueden estar definidos dentro de los procedimientos o ser evidenciados como una acción resultado del análisis de los riesgos. Modelo Estándar de Control Interno Norma Técnica de Calidad en la Gestión Pública Subsistema: Control de gestión Capítulo 4. Sistema de Gestión de la Calidad Componente: Información 4.1 Requisitos Generales Elemento: Información primaria, Información Literal d secundaria, Sistemas de Información Intencionalidad del Procurar que la información de la entidad refleje la gestión de la operación de Modelo Estándar de sus procesos y decisiones, permitiéndole actuar con transparencia y cumpliendo Control Interno con las obligaciones de información requerida por sus grupos de interés. Intencionalidad de la Garantizar que se cuenta con los recursos físicos, financieros, humanos y de Norma Técnica de información (requisitos del cliente, legales aplicables y procedimientos) Calidad en la Gestión requeridos para la operación eficaz de los procesos. Pública - Desarrollar la documentación necesaria para soportar la operación de los procesos, su secuencia e interacción

- Identificar fuentes de información (entradas a procesos) necesarias para la Aspectos comunes operación. Ejemplos de estas fuentes de información son los mecanismos para la recepción, registro y atención de sugerencias, recomendaciones, peticiones, necesidades, quejas o reclamos de los clientes.

Fuente: Norma NTGPC 1000: 2009

4.1.7. Medición, análisis y mejora

En esta última etapa se proponen una serie de puntos para realizar un proceso de mejora al final de la iteración en la elaboración del producto o la prestación del servicio; en este punto se establece lo siguiente:

 Seguimiento y medición: Se establecen requisitos para el seguimiento del producto o servicio, tales como indicadores de satisfacción al cliente, auditoría interna, seguimiento y medición de procesos y seguimiento de producto o servicio,

 Control del producto y/o servicio no conforme: También se establece el seguimiento de los productos que no entran en conformidad con los requisitos establecidos por el cliente, para prevenir su uso, entrega u ofrecimiento y analizarlo para realizar conclusiones que fortalezcan procesos de mejora.

 Análisis de datos: Se deben realizar mediciones para establecer la conveniencia y efectividad del sistema de gestión de la calidad, y contribuir a la mejora del mismo.

 Mejora: Se debe corregir de manera continua y utilizando los datos obtenidos de auditorías anteriores el sistema de gestión de la calidad mediante acciones preventivas y correctivas.

4.2. HALLAZGOS DE AUDITORÍAS REALIZADAS POR LA CONTRALORÍA DE BOGOTÁ

En la página Web de la Contraloría de Bogotá D.C., se puede consultar todas las Auditorías que se realizan a los Sujetos de Control por cada sector de la administración. El link donde se encuentran todas las auditorías es http://www.contraloriabogota.gov.co/destino.asp?solicitud=informes.htm

Figura 7: Acceso a las Auditorías de la Contraloría de Bogotá D.C.

Fuente: Sitio Web Contraloría de Bogotá D.C.

Una vez entramos a la página se debe ingresar a la opción “Auditoría Gubernamental”, tal como se muestra en la Figura 7. Al entrar a dicho opción se despliega el siguiente árbol en donde se puede navegar como una estructura de carpetas por las diferentes sectoriales de la Contraloría.

Figura 8: Estructura en árbol de las sectoriales de la Contraloría para descargar informes

Fuente: Sitio Web Contraloría de Bogotá D.C.

Se llevó a cabo la consolidación de todas las auditorías realizadas en la vigencia 2014 en cada sectorial de la Contraloría y cuyo resultado del análisis se muestra a continuación:

Tabla 2: Hallazgos Contraloría de Bogotá D.C. de 2014 por sector

AUDITORIAS AUDITORIAS AUDITORÍAS DE VISITA ESPECIALES REGULARES FISCAL TOTAL TOTAL SECTOR # De # De # De # De # De # De AUDITORÍAS HALLAZGOS Auditorías Hallazgos Auditorías Hallazgos Auditorías Hallazgos Desarrollo Económico Industria y Turismo 6 56 3 53 9 12 18 121 Educación Cultura Recreación y Deporte 17 162 6 155 6 9 29 326 Gobierno 9 38 11 223 19 50 39 311 Grupo Especial De Apoyo Y Fiscalizacion Tic 7 18 0 0 0 0 7 18 Hábitat y Ambiente 10 118 9 308 10 14 29 440 Hacienda 8 50 4 35 6 4 18 89 Integración Social 11 95 2 55 0 0 13 150 Movilidad 7 85 5 161 4 11 16 257 Participación Ciudadana 27 160 20 279 23 4 70 443 Salud 3 32 17 475 0 0 20 507 Servicios Públicos 11 115 7 151 1 1 19 267 TOTALES 116 929 84 1895 78 105 278 2929

Fuente: Auditorías descargadas del Sitio Web Contraloría de Bogotá D.C.

Al sector al que más Auditorías le realizaron fue el de Participación Ciudadana con un total de 70 correspondiente al 25% del total de auditorías, discriminadas en 27 auditorías especiales, 20 auditorías regulares y 23 auditorías de visita fiscal.

Figura 9: Total Auditorías 2014 Contraloría de Bogotá

Fuente: Auditorías descargadas del Sitio Web Contraloría de Bogotá D.C.

Al Sector que más se le formularon hallazgos fue al sector salud con un total de 507 hallazgos que corresponde al 17% del total de hallazgos, siendo 32 de ellos de auditorías especiales, 475 de auditorías regulares y ningún hallazgo de visitas fiscales.

Figura 10: Total Hallazgos Auditorías Contraloría Bogotá D.C. de 2014.

Fuente: Auditorías descargadas del Sitio Web Contraloría de Bogotá D.C.

Teniendo en cuenta que el sector Salud fue el sector al que más Hallazgos le formularon en las diferentes auditorías llevadas a cabo en la vigencia 2014, se observa que el Sujeto de Control que más hallazgos le formularon fue al Hospital Simon Bolivar con u total de 53 hallazgos que corresponden al 10.5% del total de hallazgos del Sector Salud.

Tabla 3: Auditorías y hallazgos del Sector Salud en 2014

AUDITORÍAS Y HALLAZGOS SECTOR SALUD 2014 AUDITORIAS AUDITORIAS AUDITORÍAS DE VISITA % % TOTAL TOTAL AUDITORIAS HALLAZGOS Sujetro De Control ESPECIALES REGULARES FISCAL # De # De # De # De # De # De AUDITORÍAS HALLAZGOS SECTOR SECTOR Auditorías Hallazgos Auditorías Hallazgos Auditorías Hallazgos SALUD SALUD HOSPITAL EL TUNAL 1 7 0 0 0 0 1 7 5% 1% HOSPITAL LA VICTORIA 1 8 0 0 0 0 1 8 5% 2% FONDO FINANCIERO DISTRITAL FFDS 1 17 1 32 0 0 2 49 10% 10% CAPITAL SALUD 0 0 1 26 0 0 1 26 5% 5% HOSPITAL DE BOSA 0 0 1 28 0 0 1 28 5% 6% HOSPITAL CENTRO ORIENTE 0 0 1 37 0 0 1 37 5% 7% HOSPITAL CHAPINERO 0 0 1 29 0 0 1 29 5% 6% HOSPITAL ENGATIVA 0 0 1 34 0 0 1 34 5% 7% HOSPITAL FONTIBON 0 0 1 28 0 0 1 28 5% 6% HOSPITAL KENNEDY 0 0 1 23 0 0 1 23 5% 5% HOSPITAL MEISSEN 0 0 1 35 0 0 1 35 5% 7% HOSPITAL PLABLO VI 0 0 1 5 0 0 1 5 5% 1% HOSPITAL SAN BLAS 0 0 1 31 0 0 1 31 5% 6% HOSPITAL SANTA CLARA 0 0 1 23 0 0 1 23 5% 5% HOSPITAL SIMON BOLIVAR 0 0 1 53 0 0 1 53 5% 10% HOSPITAL SUBA 0 0 1 26 0 0 1 26 5% 5% HOSPITAL TUNJUELITO 0 0 1 20 0 0 1 20 5% 4% HOSPITAL USAQUEN 0 0 1 16 0 0 1 16 5% 3% HOSPITAL USME 0 0 1 29 0 0 1 29 5% 6% TOTALES 3 32 17 475 0 0 20 507 100% 100%

Fuente: Auditorías descargadas del Sitio Web Contraloría de Bogotá D.C.

Otras Entidades que se destacan por un gran número de hallazgos en el sector Salud es el Fondo Financiero Distrital FFDS, Hospital centro Oriente y Hospital de Meissen con el 9.76%, 7.3% y 6.9% respectivamente.

Figura 11. Relación de Hallazgos sector Salud.

Fuente: Auditorías descargadas del Sitio Web Contraloría de Bogotá D.C.

Con base en los datos obtenidos de las Auditorías realizadas por la Contraloría de Bogotá en donde se observa claramente que el sector Salud es el que más se ve impactado por la cantidad de hallazgos que se le realizan, se optó por realizar énfasis en este sector durante el desarrollo del proyecto para llevar a cabo la consolidación de un plan de mejoramiento de algún sujeto de control de este Sector a fin de cumplir con los objetivos específicos del presente proyecto.

4.3. HERRAMIENTAS DE DESARROLLO

El desarrollo del presente proyecto se llevará a cabo 100% con herramientas de software libre, teniendo como base fundamental el software de gestión de incidencias Mantis Bug Tracker, el cual está escrito en PHP.

4.3.1. Lenguaje de programación PHP

PHP es un lenguaje de scripting y del lado de servidor, que es utilizado para incluir funcionalidades dentro de código HTML (dentro de la etiqueta o incluso en páginas con su propia extensión (.php, .php4, .php5 ó .phtml)25 . A diferencia de lenguajes de script, del lado de cliente como Javascript, el servidor procesa en su totalidad el código programado de su lado, entregándole al cliente un archivo en HTML procesado con los resultados que fueron programados en el script, de forma que cualquier petición entre el servidor, el cliente y aplicativos de terceros (como bases de datos o sistemas de autenticación) se realiza de forma transparente. La ventaja de usar este lenguaje es la facilidad con las que el usuario puede ver resultados y obtener funcionalidades sin necesidad de ejecutar comandos externos o desde el sitio en PHP, además de explotar las funcionalidades de la ejecución de un aplicativo en un típico esquema cliente servidor. El funcionamiento de las páginas en PHP alojadas en un servidor es el siguiente:

 El navegador del cliente solicita el documento PHP.

 Llega la solicitud del servidor y el servidor localiza el documento, lanza el intérprete de PHP y ejecuta todo su código.

 Una vez ejecutado el código se genera el resultado en HTML y lo devuelve al servidor para que lo transfiera al cliente.

 El servidor transfiere el resultado en HTML y es mostrado en el navegador del cliente.26

25 Siempre y cuando se generen scripts en estas dos formas, el servidor reconocerá el código para ser ejecutado en PHP. “http://www.php.net/manual/es/tutorial.firstpage.php” 26 Tomado de “http://www.manualdephp.com/manualphp/introduccion-php.html”

4.3.2. Mantis Bug Tracker

Mantis Bug Tracker27 es una completa solución que permite montar sistemas para la gestión de incidentes y errores en proyectos de desarrollo, que se encuentra licenciado bajo GNU, lo cual permite su uso libre. Esta herramienta trabaja sobre el lenguaje PHP, lo cual le facilita ser implementado bajo una gran variedad de sistemas operativos a través de una interfaz web, además de mantener una gran compatibilidad con varios motores de bases de datos conocidos. Algunas de las características28 que podemos encontrar en Mantis son:

 Implementación en una aplicación web

 Interfaz simple

 Gestión de usuarios

 Facilidad para el diseño de formularios

 Notificaciones por correo electrónico

 Generación de reportes

 Generación de páginas personalizadas para reportes de incidentes

 Seguimiento y trazabilidad de las diferentes actividades y acciones de los usuarios

Si bien esta herramienta está diseñada para el ámbito del control de proyectos de desarrollo, el esquema de gestión de incidentes puede ser adaptado para las necesidades expuestas en este anteproyecto, con miras al apoyo de proceso de gestión y mejora.

Figura 12: Captura de pantalla de Mantis Bug Tracker

Fuente: Sitio Web de Mantis Bug Tracker29

27 El software mantis se encuentra disponible en http://www.mantisbt.org/index.php 28 Una completa lista de características que posee Mantis se encuentra disponible en http://www.mantisbt.org/wiki/doku.php/mantisbt:features 29 Imagen tomada de http://www.mantisbt.org/index.php

4.4. METODOLOGÍA DE DESARROLLO

Para poder llevar un proceso de construcción del prototipo, se hace necesario escoger una metodología que sea ágil debido a la cantidad de recursos que se manejaran para el proyecto, y la necesidad de concentrar el proceso de desarrollo en actividades investigativas que desarrollen los métodos para abordar las pruebas, y las actividades no relacionadas que hacen parte de otras metodologías más formales no interfieran con el proceso de desarrollo. Para este proyecto, se escogió una metodología ágil, que se adapta a las necesidades de este proyecto, esta metodología se denomina OpenUP, derivada de Unified Process, que integra los procesos básicos del desarrollo de software definidos de esta metodología, con métodos que permiten agilizar el desarrollo del software y administrar los recursos que maneja el proyecto.

4.4.1. Metodología OpenUP

OpenUP es una metodología desarrollada a partir de la metodología conocida como “Unified Process”, definida como “mínima y suficiente” ya que, si bien no incluye todos los componentes básicos que hacen parte de un proyecto de software, contiene los tópicos básicos para un proceso de desarrollo completo, con la agilidad de un proceso ágil.

Como metodología ágil, es una metodología de peso ligero cuyo propósito es la comunicación de todos los componentes del proyecto, que facilitan su entendimiento, mediante prácticas de desarrollo ágil que permitan coordinar sus componentes, y se orienta hacia un desarrollo comunicativo y natural del desarrollo de software, de baja “ceremonosidad”30 que apunta a ser aplicada a una gran variedad y tipos de proyectos. OpenUP es una metodología de tipo incremental e iterativo que se enfoca en un ciclo de vida estructurado31, lo cual le permite manejar escenarios de casos, manejo del riesgo y centrada en la arquitectura para gura el proceso de desarrollo.

4.4.1.1. Principios: Open UP reúne cuatro principios básicos que se complementan y funcionan conjuntamente:

 Balance: Se debe procurar maximizar los beneficios de los stakeholders32 sin descuidar las restricciones que involucra el proyecto. Para llegar a tener éxito en el proyecto se sugiere enfatizar y tener claridad en tres factores:

o El problema que se quiere resolver.

o Plantear las restricciones del equipo de desarrollo (cronograma, costos).

o Plantear las restricciones (limitaciones) sobre la solución.

 Colaboración: La implementación de buenas prácticas colaborativas direcciona los intereses de los participantes en el proyecto y ayudan a generar un conocimiento

30 Ceremonioso como la característica de especificar varios proceso y documentación respectiva, lo cual se volvería inestable e inmanejable en proyectos pequeños con pocos integrantes

31 Tomado de “Introduction to OpenUP”, http://epf.eclipse.org/wikis/openup/ 32 Un stakeholder es cualquier grupo o individuo que puede afectar o ser afectado por el logro de los objetivos de la empresa. RE. FREEMAN: Strategic Managment.

40 consensuado acerca del mismo. Fomentar un ambiente de trabajo saludable permite trabajar en equipo de una manera efectiva.

 Enfoque: Ligar una arquitectura a las decisiones técnicas es fundamental de lo contrario un sistema evolucionará al azar y de forma ineficiente. Prácticamente incapaz integrarse a otros proyectos, por lo cual, una reconstrucción sería inevitable.

 Evolución: Dividir el proyecto en ciclos cortos para obtener realimentaciones tempranas y continuas. Los cambios se adoptaran con mayor naturalidad al proyecto.

4.4.1.2. Prácticas: Cada uno de los principios básicos recomienda la implementación de una serie de prácticas, las que se exponen a continuación son propias del principio de balance:

 Conocer a la audiencia: Se debe conocer a los interesados para comunicar sus necesidades.

 Separar el problema de la solución: Al hacer una clara separación entre el problema (lo que el cliente necesita) de la solución (lo que el sistema debe hacer).

 Crear una comprensión compartida del dominio: Se debe comprender las diferentes limitaciones que afectan a los elementos que integran el proyecto para evitar entregas con poco valor.

 Usar escenarios y casos de uso para capturar requisitos: Especificar mediante casos de uso los distintos tipos de requerimientos como los funcionales, no funcionales y de soporte.

 Establecer y mantener un acuerdo sobre las prioridades: Mediante la toma de decisiones y comunicándose regularmente con los stakeholders, se establecen prioridades sobre las actividades.

 Hacer intercambios para maximizar valor: Evaluación de la arquitectura que represente mejor el beneficio/costo de la implementación.

 Manejar el alcance: Definir los alcances para determinar hasta donde llegar en un proyecto en común acuerdo entre desarrolladores y stakeholders.

 Saber cuándo parar: Definir las limitaciones que permitan establecer los parámetros de calidad adecuados.

Las siguientes prácticas se refieren al principio de colaboración:

 Mantener un entendimiento común: Todos los integrantes del equipo deben llegar a un acuerdo común y centrar sus intereses.33

 Propiciar un ambiente de alta confianza: Los integrantes deben estar seguros para comunicar mejor las ideas.34

33 Una descripción detallada se encuentra en: http://epf.eclipse.org/wikis/openupsp/openup_basic/guidances/concepts/core_principle_collaborate,_KkTIs Mp7EdqC_NfSivunjA.html

 Compartir la Responsabilidad: Cada miembro de trabajo posee una responsabilidad primaria y a su vez compartida por su trabajo.

 Aprender continuamente: Es importante desarrollar las habilidades del individuo de manera continua y con los compañeros de trabajo.

 Organizar alrededor de la arquitectura: Se debe centrar las actividades y las ideas en la arquitectura y sus necesidades.

Las siguientes prácticas son propias del principio de enfoque:

 Crear la arquitectura para lo que se conoce hoy.

 Desarrollar las soluciones tan simples como sea posible: Se debe centrar en la arquitectura de manera simple, ajustándose a las necesidades del cliente y sin sobrecargarla con especulaciones de futuras modificaciones.

 Sobrellevar la complejidad elevando el nivel de abstracción: La simplicidad del sistema está limitada por el manejo de los problemas importantes y evitando excesivos niveles de detalle.

 Permitir al problema dirigir la solución: La arquitectura debe guiarse por las necesidades de los “stakeholders” en vez de las soluciones propuestas.

 Organizar la arquitectura con bajo acoplamiento, componentes altamente cohesionados: Organizar los componentes del sistema de manera que potencien la cohesión y reduzcan el acoplamiento mejorara la compresión y aumentará la flexibilidad de la solución.

 Reutilizar recursos existentes: Se recomienda el uso de recursos existentes, siguiendo el principio de reusó.

 Apalancar la arquitectura como una herramienta colaborativa: Se debe centrar colaborativamente una herramienta que permita unificar los conceptos de arquitectura para el proyecto.

Por último, las siguientes prácticas corresponden al principio de evolución:

 Desarrollar el proyecto en las iteraciones: El desarrollo se debe guía a través de iteraciones que permitan mostrar y discutir los cambios con los “stakeholders” y mejorar el software.

 Las iteraciones se enfocan en encontrar la dirección al siguiente hito: Dividir el proyecto en fases por ejemplo, Inicio, Elaboración, Construcción y Transición, a cada fase asignar un hito (objetivo) claramente visible. El enfoque de cada iteración dentro de una fase está en alcanzar ese hito.

34http://epf.eclipse.org/wikis/openupsp/openup_basic/guidances/concepts/core_principle_collaborate,_KkT IsMp7EdqC_NfSivunjA.html

 Maneje los riesgos: Medir los riesgos35 disminuye la probabilidad de fracaso de un proyecto.

 En este sentido, reconocer y priorizar los riesgos es el primer paso para posteriormente proponer estrategias para mitigarlos: Se debe discutir entre los miembros del proyecto los riesgos a los que se enfrenta y realizar una lista de riesgos priorizada.

 Adopte y maneje el cambio: Se recomienda manejar y documentar los cambios en los proyectos y discutirlo con los “stakeholders”, permitiendo un ahorro de costos y mejorar su predicción.

 Mida el progreso objetivamente: Se debe medir el progreso del proyecto objetivamente para determinar el estado de este, una medida del progreso es el software en funcionamiento.

 Reevaluar continuamente lo que hace: Realizar una retrospectiva acerca de los errores cometidos permite mejorar el desempeño en proyectos futuros y evaluar los riesgos.

4.4.1.3. Disciplinas:

 Análisis y Diseño: Explica cómo crear un diseño desde los requerimientos que pueden ser implementados por los desarrolladores.

 Gestión de Configuración y Cambios: Se enfoca en cómo controlar los cambios en los artefactos, para asegurar una evolución sincronizada entre los elementos que componen el sistema.

 Implementación: Comprende como ajustar la solución que se está desarrollando a una arquitectura bien definida que cumpla con los requisitos establecidos.

 Gestión del Proyecto: El propósito principal es crear un entorno de trabajo eficaz para maximizar el rendimiento del grupo, además de construir un marco apropiado para gestionar los riegos del proyecto de esta forma adaptarse mejor a los cambios.

 Requerimientos: Se trata de definir las tareas necesarias para elicitar, analizar, especificar validar y administrar los requerimientos del sistema que va a ser desarrollado.

 Pruebas: Contiene la descripción y especificación de cada una de las pruebas que se aplican al proyecto.

4.4.1.4. Roles: Es un conjunto de responsabilidades que son asignadas a uno o más integrantes de un proyecto.

 Analista: Representa al cliente y a los usuarios finales, obtiene información de los stakeholders para entender el problema que debe ser resuelto.

35 Riesgo: Es la probabilidad de que una amenaza se convierta en un hecho.

Figura 13: Esquema de responsabilidades para el analista

Fuente: Adaptación propia Eclipse OpenUP Wiki Español.

 Arquitecto: Es responsable de diseñar la arquitectura del software, dentro de la que se incluye las decisiones técnicas y de implementación del proyecto.

Figura 14: Esquema de responsabilidades para el arquitecto

Fuente: Adaptación propia Eclipse OpenUP Wiki Español.  Desarrollador: Es el encargado de desarrollar una parte del sistema, se incluye un diseño que se ajuste a la arquitectura. Es responsable de realizar pruebas unitarias y de integrar los componentes para conformar la solución.

Figura 15: Esquema de responsabilidades para el desarrollador

Fuente: Adaptación propia Eclipse OpenUP Wiki Español.

 Director del proyecto: La persona que desempeña este rol es la encargada de liderar la planeación del proyecto, coordina las comunicaciones con los stakeholders y mantiene al equipo enfocado en los objetivos del proyecto.

Figura 16: Esquema de responsabilidades para el director de proyecto

Fuente: Adaptación propia Eclipse OpenUP Wiki Español.

 Stakeholder: Este rol representa a las personas o grupos interesados en el proyecto, puede ser representado por todos aquellos que de una u otra forma se verán afectados por el resultado del proyecto.

Figura 17: Esquema de responsabilidades para el stakeholder (Sin responsabilidades específicas).

Fuente: Adaptación propia Eclipse OpenUP Wiki Español.

 Probador: Es el encargado de realizarlas pruebas principales, incluye definir, implementar y definir las pruebas necesarias así como analizar y verificar los resultados de las mismas.

Figura 18: Esquema de responsabilidades para el probador

Fuente: Adaptación propia Eclipse OpenUP Wiki Español.

 Cualquier rol: Cualquier persona en el equipo puede desempeñar este rol, principalmente para llevar a cabo tareas generales, como por ejemplo participar en evaluaciones o revisiones de proyecto.

4.4.1.5. Tareas: Cada una de las tareas que se listan a continuación esta enmarcadas dentro de las disciplinas que se trataron en el numeral anterior36.

Tareas de análisis y diseño:

 Analizar los requerimientos arquitectónicos.

 Diseñar la solución.

 Desarrollar la arquitectura.

Tareas de la gestión de cambios:

 Capturar y registrar solicitudes de cambio.

Tareas de la disciplina de implementación:

 Implementar test de desarrollo.

 Implementar la solución.

 Ejecutar pruebas de desarrollo.

Tareas de la gestión de proyecto:

 Evaluar los resultados.

 Administrar la iteración.

 Planear la iteración.

 Planear el proyecto.

Tareas de la disciplina de requerimientos:

 Definir la visión

 Requisitos Detallados

 Buscar y describir los requerimientos

4.4.1.6. Proceso: Este proceso de entrega define un proceso de desarrollo de software que se soporta sobre los principios fundamentales del OpenUP. Está diseñado para soportar equipos pequeños - de 3 a 6 integrantes - trabajando sobre proyectos cuya duración sea de 3 a 6 meses.

36 Para una descripción detallada de las tareas que conforman el procesos de desarrollo open UP remítase a: http://epf.eclipse.org/wikis/openupsp/openup_basic/tasks/request_change,_0mwzEclgEdmt3ad ZL5Dmdw.html

Figura 19: Flujo de trabajo de OpenUP

Fuente: Eclipse OpenUP Wiki Español

5. ALCANCES Y LIMITACIONES

5.1. ALCANCES

Se desarrollará e implementará una aplicación web para que las Entidades del Distrito realicen seguimiento efectivo y oportuno a los planes de mejoramiento conforme en lo sugerido en el Modelo Estándar de Control Interno y la Norma NTCGP:1000.

La Aplicación se desarrollará 100% mediante el uso de herramientas de Software Libre, a fin de minimizar los costos de implementación en las Entidades, en conformidad con las normas impuestas en el Distrito.

Se realizarán pruebas con base en datos reales sobre procesos de mejoramiento continuo llevados a cabo de manera manual en entidades del distrito.

Se documentará el proceso de desarrollo para permitir futuras implementaciones de otros planes de mejoramientos basados en normas tanto existentes como futuras.

5.2. LIMITACIONES

No se establecerán nuevas normas o procedimientos que no sean de obligatorio cumplimento su implementación.

Tampoco se dará soporte a otros planes de mejoramiento que no hayan sido expuestos en este documento, ni se implementarán procesos de apoyo basados en otras metodologías específicas de auditoría.

No se implementará la aplicación como parte de un proceso completo de auditoría para todas las entidades del distrito.

6. DISEÑO METODOLÓGICO

Para una consecución exitosa del proyecto se requiere utilizar metodologías para el desarrollo de actividades en dos ámbitos básicos; el objetivo de realizar este análisis es aplicar todos los estándares posibles para definir un marco común en la consecución de este proyecto.

El primer ámbito es el investigativo, el cual se realizará para diseñar e implementar métodos que permitan capturar la información y permitir su análisis en el plan de mejora por parte de los interesados.

El segundo ámbito el aplicativo; aplicando la metodología de ingeniería seleccionada para este caso que es el desarrollo de software guiado por OpenUP, en todas sus fases y siguiendo todas las recomendaciones y herramientas que propone esta metodología.

6.1. METODOLOGÍA DE INVESTIGACIÓN

Este primer conjunto de actividades va enfocado a una adecuada gestión documental que permita analizar adecuadamente el problema y apoyar otros procesos en el desarrollo de la aplicación; este proceso se realizará a la par con el proceso de gestión de requerimientos que plantea OpenRUP.

6.1.1. Tipo de estudio

Es necesario considerar en un primer aspecto que pasos se deben seguir paralelo a la metodología de ingeniería centrándose en las soluciones y un abordaje del problema que considere las mejores soluciones para apoyar la elaboración y seguimiento del plan de mejoramiento.

6.1.1.1. Fase uno: Recopilación documental: Esta fase consiste en una recopilación documental acerca de los planes y políticas internas de una Entidad del Distrito, que estén alineadas con el plan de mejoramiento; además de integrar otros métodos que se utilicen para realizar seguimientos a los hallazgos de las auditorías y realizar plan para la integración del proyecto. Será un estudio explicativo37.

Para esta fase, se llevará a cabo, entre otras actividades las siguientes:

 Consultar toda la normatividad existente respecto a la obligatoriedad de un sujeto de control, de proyectar y llevar a cabo planes de mejoramiento producto de los diferentes hallazgos encontrados en las Auditorías realizadas por los Entes de Control.

 Consultar y recopilar todos los hallazgos formulados por la Contraloría de Bogotá D.C. en la vigencia 2014 a los diferentes sujetos de control.

37 De acuerdo la definición que se encuentra en el libro “Metodología de la Investigación”, Hernández Sampieri Roberto, Fernández Collado Carlos, Baptista Lucio Pilar, 1991, Págs. 74,75

 Compilar el plan de mejoramiento realizado por una Entidad que haya sido auditada por la Contraloría de Bogotá D.C.

 Verificar y cuantificar toda la información que se generó en una Entidad auditada por la Contraloría de Bogotá D.C., una vez ejecutado y cerrado el plan de mejoramiento.

6.1.1.2. Fase dos: Desarrollo de la aplicación: Luego de recopilar la información necesaria y diseñar las técnicas suficientes para el abordaje del problema, se realizará un enfoque de desarrollo tecnológico38, en el cual se aplicaran las soluciones en un desarrollo web.

En este escenario se contemplaran las siguientes actividades:

 Análisis de requerimientos: se realizará un análisis completo que cubra todas las necesidades que lleguen a resolver el problema planteado. Esto teniendo en cuenta:

o Objetivos del sistema: gestión de auditorías, gestión de hallazgos, presentación de informes, gestión de usuarios, gestión de notificaciones, campos personalizados y almacenamiento de documentos.

o Requisitos de información: Información de la auditoría, información sobre los hallazgos, información de seguimientos, información sibre usuarios, indicadores de gestión.

o Casos de uso: establecer casos de uso bajo los siguientes subsistemas. Subsistema gestión de usuarios, subsistema gestión de auditorías, subsistema gestión de hallazgos y subsistema gestión de campos personalizados.

 Diseñar diagramas UML: Diagramas de caso de uso, diagramas de estado y diagramas de paquetes.

 Diseño de Base de Datos: diseño conceptual, diseño entidad-relación.

 Desarrollo e implementación web: tomando como referencia el software libre de gestión de incidencias Mantis Bug Tacker (MantisBT), se hará la adaptación de este a los requerimientos obtenidos en el análisis del problema.

o Implementación servidor Web.

o Implementación servidor de base de datos.

o Archivos de configuración.

o Interfaz gráfica.

6.1.1.3. Fase tres: Acoplamiento con el plan de mejora: Por último, se acoplará y expondrá a los interesados la aplicación y su implementación dentro del plan de

38 Una explicación detallada sobre enfoque de desarrollo tecnológico se puede encontrar en el artículo “El conocimiento como recurso sustantivo del cambio tecnológico en las organizaciones”, Fernando García Córdoba, Ricardo Muñoz Sánchez, revista “Criterio Libre”, Universidad Libre, Colombia, Julio-Diciembre de 2008, Pág. 86, vía http://www.unilibre.edu.co/CriterioLibre/images/revistas/11/CriterioLibre11art03.pdf.

50 mejora, así como posteriores trabajos para mejorar la aplicación y continuar coordinadamente con el plan de mejora, lo cual será un proceso explicativo

 Plan de pruebas:

o Entorno de pruebas: recursos de los usuarios, servidor web, conectividad.

o Roles y responsabilidades: administrador de pruebas, diseñador de pruebas, ejecutor de pruebas

o Casos de prueba: propósito, prerrequisito, datos de prueba, pasos, notas y preguntas.

6.1.2. Metodología a aplicar

Debido a que el plan de mejora es un proceso que combina recopilación de evidencias con aplicación de los correctivos de manera cíclica, se requiere que la solución se adapte de igual manera, obteniendo mediante las metodologías sugeridas en el plan dicha obtención de la información y su interpretación adecuada por parte de los interesados, se requiere abordar un enfoque cualitativo39 que permita seguir estos procedimientos como se encuentran establecidos y ofrecer la información clara para facilitar el trabajo de los interesados que se encargan del proceso de mejora.

6.2. METODOLOGÍA DE INGENERÍA

En este apartado se explicará cómo se aplicará la metodología de ingeniería, explicando la forma en que se relacionaran los elementos y herramientas que ofrece esta metodología y contextualizándolos en el proyecto propuesto, además de aclarar cómo se manejarán algunas limitaciones de los recursos en la metodología.

6.2.1. Tareas:

 Requerimientos: La información provendrá de los documentos generados sobre el plan de mejoramiento, más concretamente los establecidos en el MECI, NTCGP 1000: 2009 y la Resolución 003 de 2014 de la Contraloría de Bogotá; a partir de esta información se documentarán los requisitos para que la aplicación se pueda acoplar con esta normatividad.

 Administración de proyecto: Se realizará un manejo de los recursos que pertenecen al proyecto junto con los actuales que provienen, acoplándolos para implementar la solución entre los integrantes de este proyecto.

 Arquitectura: Las tareas relacionadas se enfocarán a adaptar la arquitectura proveniente de Mantis Big Tracker junto con los requerimientos para la integración con el plan de mejoramiento, diseñando los módulos para la captura y presentación de la información.

39 Tomando el concepto de enfoque cualitativo, del libro “Metodología de la investigación Científica,” Alberto Ramírez, Pontificia Universidad Javeriana, Págs. 43, 44, 45, vía http://javeriana.edu.co/fear/ecologia/documents/ALBERTORAMIREZMETODOLOGIADELAINVESTIGACI ONCIENTIFICA.pdf

 Desarrollo: La implementación como se mencionó en el punto anterior, se realizara en MantisBT, aprovechando los recursos que posee esta herramienta y adaptándola a la aplicación del plan de mejora y las funcionalidades adicionales que sean necesarias para el funcionamiento de la aplicación.

 Pruebas: Se aplicarán técnicas de pruebas que permitan validar el funcionamiento del sistema con los interesados y en conformidad con las políticas que avalan y reglamentan la aplicación del plan de mejora.

6.2.2. Roles

Los roles descritos a continuación son solo una descripción de las actividades que se desarrollarán los integrantes en el proyecto, de manera conjunta y compartida, debido a la limitada cantidad de integrantes, sin embargo esto no representará limitación ya que la metodología lo permite:

• Analista: Este rol deberá organizar la información obtenida en el proceso investigativo, clasificarlo y especificarlo en los requerimientos y detallar los caso de uso que deberá tener la aplicación para que contenga todas las funciones necesarias, en conjunto con los stakeholders; también hará parte del plan de mejora que permita corregir errores en la aplicación y agregar funcionalidades nuevas.

• Arquitecto: Aunque MantisBT ya posee su propia arquitectura, este rol será fundamental para realizar la adaptación proponiendo y haciendo los cambios que sean necesarios para adaptar la aplicación al plan.

• Desarrollador: Será encargado de implementar de manera específica MantisBT y de su instalación en los recursos informáticos.

• Director de proyecto: La dirección se encargará de dirigir las tareas necesarias para el progreso y desarrollo del proyecto, y presentar los progresos del proyecto a los interesados.

• Los interesados o clientes (Stakeholders): Para el caso del proyecto, será el director interno de proyecto de grado y los jefes de la oficina de control interno de las entidades del Distrito..

• Probador: Este rol se encargará de realizar todas las pruebas de la aplicación para asegurar su funcionamiento, validando su funcionamiento en conformidad con lo aprobado por los involucrados en el plan de mejoramiento. Este rol será primordial para que la aplicación sea aceptada como parte del plan de mejoramiento.

6.2.3. Productos de trabajo

En la siguiente tabla se detallarán los productos de trabajo en el contexto del proyecto, para su entendimiento y correcta aplicación.

Tabla 4: Productos de trabajo para el proyecto

Tarea Producto Descripción

Cuaderno de Contendrá todas las especificaciones de la aplicación en cuanto a Arquitectura arquitectura su estructura, en conjunto con la documentación de MantisBT.

Principalmente los componentes adaptados de MantisBT al Implementación proyecto.

Es el producto de la implementación de MantisBT en ciclos Build establecidos para mostrar avances a los interesados. Desarrollo Pruebas de Las pruebas serán coordinadas junto con los interesados para desarrollador aprobar o autorizar modificaciones acorde a los requerimientos.

Es la representación programática del aplicación web mostrando Diseño su adaptación de MantisBT a una herramienta del plan de mejoramiento,

Es una lista opcional acerca de los riesgos que podrían afectar al proyecto de desarrollo y las acciones de mitigación de estos; Lista de riesgos sería desarrollado en conjunto con los lineamientos de las políticas.

Es una lista de tallada de todas las tareas que harán parte del Lista de tareas proyecto, todas las actividades que necesiten ser desarrolladas Gestión de para el proyecto serán contenidas en este documento. proyecto Este plan contendrá las acciones que se realizaran para el Plan de iteración desarrollo de los módulos necesarios para la aplicación web.

Este artefacto de planificación contendrá las estrategias que se deberán realizar y la descripción general acerca de actividades Plan de proyecto específicas de control, en conjunto con lo establecido en las normas del plan de mejoramiento.

Contendrá una lista detallada de términos que se usarán en el Glosario proyecto de pruebas, todos asociados a los términos de auditoría, desarrollo web y planes de mejoramiento.

Visión Será el bosquejo general de cómo se desarrollaran las pruebas y cómo será la aplicación y su integración al plan de mejoramiento. Estará enfocado hacia la descripción de las funciones del sistema Visión general del desde el punto de vista técnico, mostrando los recursos que se necesitarán y sus costos asociados para implementarlo, Requerimientos sistema probablemente no se necesite debido al análisis que se realiza de los recursos en este documento. Describirá cuáles serán los procedimientos comportamentales de las pruebas y la forma en que interactuará con el usuario, en la Casos de uso aplicación web describirá las interacciones entre los interesados, los responsables y el plan.

Modelo de casos Contendrá de manera gráfica una representación de los casos de de uso. uso tal como se describieron en el artefacto anterior, usando la notación UML. Es una descripción sobre como los módulos deberán Pruebas Casos de prueba comportarse, describiendo las entradas de las pruebas, los comportamientos de acuerdo a los casos establecidos a nivel

técnico y de implementación de las aplicación web.

Probablemente no sea necesario debido a la complejidad de la Scripts de prueba aplicación web.

Es un registro formal sobre las pruebas que se realizarán o se Registro de han realizado, realizando un seguimiento detallado de cómo se pruebas llevan a cabo y serán aprobadas en conjunto con los responsables del plan de mejoramiento.

Fuente: Autores del anteproyecto

6.3. RESULTADOS ESPERADOS

Después de exponer como se realizará la aplicación de las metodologías en el contexto del proyecto actual, se esperan los siguientes resultados en su finalización:

 Aplicación web de gestión de incidentes con las funcionalidades propuestas.

 Documentación de la aplicación web con detalles de su integración con el plan de mejoramiento.

 Estudio de beneficio – costo de la implementación del Aplicativo en las Entidades del Distrito.

 Manual de administración y lineamientos para su posterior modificación y mantenimiento.

 Documentación técnica que permita la mejora de la aplicación ajustándose a lo expuesto en la norma NTCGP: 1000, al MECI y la Resolución 003 de 2014 de la Contraloría de Bogotá.

7. ANÁLISIS DE REQUERIMIENTOS

En la primera fase del desarrollo de la aplicación, se debe realizar un análisis completo que cubra todas las necesidades que se plantearon en los primeros puntos del proyecto alineado con la normativa; es por ello que se realizó un proceso para la identificación de cada aspecto y característica que debe poseer la aplicación, además de los lineamientos que fueron acordados entre el integrante del presente proyecto y las partes interesadas. Este proceso se realizó utilizando la elicitación de requisitos40 la cual se complementa con los productos descritos en OPENUP para esta fase; en el presente punto se describirá como se realizó el proceso, sin embargo los productos que componen esta fase se expondrán en detalle en el anexo A del presente documento.

7.1. DESCRIPCIÓN DEL SISTEMA ACTUAL

La primera parte de este proceso es obtener una primera aproximación a una representación del sistema, para lo cual se debe recolectar la información sobre las necesidades de los interesados mediante unas técnicas para garantizar una completa recolección de la información desde varios ámbitos. Se realizaron varias técnicas y se puede destacar las siguientes conclusiones:

 Las Entidades del sector público se rigen bajo la ley 87 de 1993, el decreto 1599 de 2005 (que describe el MECI) y NTCGP:1000 para la implementación y ejecución de planes de mejora y revisión de procesos, evidenciando un conjunto de marcos definido para estos procesos, y complementando la definición de los productos en esta fase.

 Si bien se cuenta con una serie de procesos definidos normativamente para el mejoramiento continuo, estos se desarrollan en forma manual sin ningún control ni procesos de gestión documental adecuados en gran cantidad de las Entidades del Distrito.

 Tampoco se cuenta con procesos agiles para el análisis de dicha información por parte de los auditores y líderes de área, evidenciando retrasos y demoras en la implementación pronta de las mejoras y el estudio de las incidencias reportadas.

 Por ahora, solo se cuenta con reportes hechos en tablas de Microsoft Excel para el registro de la información, los archivos generados tampoco cuentan con algún tipo guía que oriente la gestión de dichos documentos y de igual manera unas políticas de seguridad adecuadas.

7.2. OBJETIVOS DEL SISTEMA

Una vez identificado el ámbito de la aplicación y con tal de centralizar todos estos procesos relacionados con el plan de mejora, se plantean una serie de objetivos que definen las características que se deben afrontar para lograr esta unificación de

40 Metodología para la Elicitación de Requisitos de Sistemas Software Versión 2.3 Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática Sevilla, abril de 2002. Este documento se encuentra en el ANEXO G.

55 procesos dentro de los planes de mejora. A continuación se dará una lista de los objetivos con los que deberá cumplir la aplicación para lograr este propósito:

Tabla 5: Objetivos del sistema para la aplicación OBJ-01 Gestión de auditorias OBJ-02 Gestión de hallazgos OBJ-03 Presentación de informes OBJ-04 Gestión de usuarios OBJ-05 Medición de la gestión OBJ-06 Gestión de notificaciones OBJ-07 Manejo de campos (Indicadores de gestión) OBJ-08 Almacenamiento de documentos

Fuente: Autor del proyecto

7.3. REQUISITOS DE INFORMACIÓN

La información necesaria para definir las entidades de información que también serán necesarias para el planteamiento de la base de datos, se definirán en este punto, agregando y describiendo los requerimientos de cada entidad que permitirá agregar la información necesaria para la gestión de las auditorías y los hallazgos. Los requisitos planteados en este proceso se enumeran en la siguiente tabla:

Tabla 6: Requisitos de información planteados IRQ-01 Información de la auditoría IRQ-02 Información sobre hallazgos IRQ-03 Información de seguimientos IRQ-04 Información sobre usuarios IRQ-05 Indicadores de gestión IRQ-06 Documentación

Fuente: Autor del proyecto

7.4. CASOS DE USO

Las funcionalidades propuestas para el prototipo estarán especificadas en los siguientes casos de uso que mostrarán en la lista a continuación, a su vez se presenta una lista de los subsistemas en los cuales se encuentran clasificados los casos de uso:

 Subsistema gestión de usuarios: Este subsistema agrupa las funcionalidades que se encargan del manejo de los usuarios y sus funciones.

 Subsistema gestión de auditorías: Este conjunto de casos describe como se deben gestionar las auditorías y sus funciones relevantes.

 Subsistema gestión de hallazgos: Las funciones que se deben realizar para el manejo de los hallazgos se describen en este conjunto de casos de uso.

 Subsistema gestión de campos personalizados: En este grupo se encuentran los casos de uso referente a la gestión de campos personalizados.

Tabla 7: Casos de Uso del Sistema NOTACIÓN NOMBRE Subsistema UC-01 Crear auditoría UC-02 Modificar auditoría UC-03 Agregar origen UC-04 Modificar origen agregado UC-05 Eliminar origen agregado UC-06 Agregar campos personalizados Gestión de auditorías UC-07 Modificar campos personalizados agregados UC-08 Eliminar campos personalizados agregados UC-09 Agregar usuarios a la auditoría UC-10 Quitar usuarios a la auditoría UC-11 Acceder a auditoría UC-12 Subir documentos UC-13 Agregar hallazgos UC-14 Modificar hallazgos UC-15 Ver hallazgo UC-16 Cambiar estado hallazgo UC-17 Asignar hallazgo UC-18 Cerrar hallazgo UC-19 Agregar seguimiento Gestión de hallazgos UC-20 Monitorizar hallazgo UC-21 Agregar monitor a hallazgo UC-22 Quitar monitor a hallazgo UC-23 Agregar archivo a hallazgo UC-24 Registrar eventos hallazgo UC-25 Imprimir información hallazgos UC-26 Crear campos personalizados Gestión de campos UC-27 Modificar campos personalizados personalizados UC-28 Eliminar campos personalizados UC-29 Crear usuarios UC-30 Modificar usuarios UC-31 Eliminar usuarios Gestión de usuarios UC-32 Iniciar sesión UC-33 Cerrar sesión UC-34 Modificar datos cuenta

Fuente: Autor del proyecto

7.5. DIAGRAMAS DE CASOS DE USO (UML)

Figura 20: Diagrama de paquetes del sistema.

Fuente: Autores del proyecto

7.5.1. SUBSISTEMA GESTIÓN DE AUDITORÍAS

Este sistema es el encargado del manejo de las auditorías y sus elementos correspondientes.

Figura 21: Diagrama de Caso de uso para la gestión de auditorías.

Fuente: Autores del proyecto

7.5.2. SUBSISTEMA GESTIÓN DE HALLAZGOS

Este subsistema se encarga del manejo y configuración de los hallazgos y sus funciones correspondientes.

Figura 22: Diagrama de Caso de uso para la gestión de hallazgos.

Fuente: Autores del proyecto

7.5.3. SUBSISTEMA GESTIÓN DE CAMPOS PERSONALIZADOS

Este subsistema se encarga del manejo de campos personalizados para su asociación en implementación en auditorias y hallazgos.

Figura 23: Diagrama de Caso de uso para la gestión de campos personalizados.

Fuente: Autores del proyecto

7.5.4. SUBSISTEMA GESTIÓN DE USUARIOS

Este subsistema administra los usuarios y sus funciones individuales sobre sus cuentas.

Figura 24: Diagrama de Caso de uso para la gestión de usuarios.

Fuente: Autores del proyecto

7.6. ACTORES DEL SISTEMA.

Estos son los actores del sistema, todos deben tener una cuenta para poder acceder y el administrador puede tener funciones de auditor. Cabe anotar que un auditor al agregar a un usuario a un hallazgo, puede heredarle permisos efectivos sobre la auditoría sin importar su rol.

Figura 25: Diagrama de Caso de uso para los actores del sistema.

Fuente: Autores del proyecto

7.7. DIAGRAMA DE ESTADOS

En complemento con los diagramas de casos de uso, se adjunta el siguiente diagrama de estados, el cual detalla cómo se realiza el manejo de los estados de los hallazgos en la aplicación por parte de los usuarios que pueden modificar dichos estado. También se utilizará la notación UML para la exposición de los estados.

Figura 26: Diagrama estados de los hallazgos.

Fuente: Autores del proyecto

7.8. DISEÑO DE LA BASE DE DATOS

El diseño de la aplicación de los planes de mejora también incluye una consideración para el almacenamiento en bases de datos; este planteamiento se desarrolla con el fin de proponer un almacenamiento de toda la información relacionada con las auditorías junto con funcionalidades extra como el almacenamiento de archivos; a continuación se expondrá de manera conceptual el diseño de la base de datos, anotando que como tal la implementación y diseño específicos están a cargo del entorno Mantis Bug Tracker, y por tanto solo exponiendo de manera breve lo concerniente al tema de y sin entrar en detalles técnicos del entorno, solo enfocándose en la implementación dentro de la aplicación del plan de mejora.

7.8.1. Planteamiento del problema

La aplicación básicamente recopila información sobre hallazgos agrupados en auditorías, sobre las cuales se agrupan planes de mejoramiento; cada hallazgo contiene información la cual se utiliza para realizar seguimientos a dichos planes de

64 mejoramiento y constatar que se estén ejecutando por parte de los auditores, mediante unos indicadores de cumplimiento; en conjunto con el entorno de desarrollo, MantisBT es una herramienta originalmente desarrollada para reporte y gestión de seguimientos en proyectos de software que se adapta al proceso de auditorías, por lo cual se necesita un planteamiento el cual permita adaptar la base de datos ya creada por Mantis para realizar las tareas asociadas al seguimientos de los procesos de auditoría y aplicación de los planes de mejora.

7.8.2. Planteamiento del general

La herramienta que se plantea realiza proceso de seguimientos para la aplicación de los planes de mejora en Entidades del Distrito, que permite realizar un proceso de seguimientos mediante el planteamiento de hallazgos agrupados en auditorías pertenecientes a una o más áreas de la Entidad. La herramienta cuenta con los siguientes componentes básicos:

 Una aplicación web con gestión de usuarios realizada bajo el gestor de seguimientos MantisBT.

 Una base de datos que se utilizará para almacenar la información y que ya está previamente definida y creada por MantisBT.

La información utilizada para la implementación de la base de datos se agrupará en los siguientes componentes:

 Auditorías: Toda la información concerniente a la creación de auditorías se agrupará en este conjunto de entidades, que tendrán como propósito la creación de un perfil de auditorías con la información necesaria para su descripción y definición de características que permitirán agrupar hallazgos y brindarles campos de configuración.

 Hallazgos: Este conjunto de entidades recibirá información para la definición de campos del conjunto de auditorías, de esta forma todos los hallazgos se agruparán en auditorías y tendrán la información específica de acciones a seguir en un proceso puntual; además se podrán definir permisos a usuarios para que puedan tener más privilegios sobre las acciones de la auditoría.

 Campos personalizados: Los campos se utilizarán para definir indicadores de seguimiento en los hallazgos, podrán ser agregados a una o más auditorías y hallazgos así como la creación de nuevos campos.

 Usuarios: La información relacionada será gestionada por Mantis, sin embargo será necesaria para la definición de permisos en roles (previamente definidos en la sección requerimientos), los cuales podrán variar dependiendo de las acciones que tomen los auditores en los hallazgos, además de las acciones habituales de gestión y acceso a la plataforma.

7.8.3. DISEÑO CONCEPTUAL

Este apartado expondrá como se mencionó previamente, una definición conceptual y representativa que maneja la base de datos de la aplicación del plan de mejora; la representación se realizará mediante un diagrama entidad-relación correspondiente a la metodología de Peter Chen, en el cual se mostrarán las principales entidades con sus atributos y relaciones tal como se manejan en la aplicación.

7.8.4. Tablas

Tabla 8: Lista de entidades del modelo relacional resultante clasificadas Entidad Definición Atributos En el contexto de la base de datos, es un  Identificador numérico conjunto de hallazgos enmarcados y orientados  Nombre hacia un área determinada dentro de la  Descripción Auditoría Entidad, cuenta con orígenes y campos  Estado personalizados que pueden ser heredados  Activado dentro de los hallazgos.  Visibilidad Es un reporte que el auditor realiza para apoyar  Identificador numérico procesos de mejoramiento sobre procesos en  Descripción la Entidad, producto de las actividades de  Reproductibilidad auditoría interna o externa, los cuales cuentan  Severidad con indicadores de seguimiento y son  Prioridad Hallazgo monitoreados por distintos usuarios.  Resumen  Fecha del hallazgo  Estado  Análisis Causal  Acciones correctivas Es el actor que usará el sistema, puede estar  Identificador numérico asociado a uno o más hallazgos y posee sus  Nombre Usuario propios datos de acceso.  Alias  Contraseña  Correo Electrónico Es un conjunto de permisos que puede tener  Identificador numérico Rol un usuario sobre una auditoría  Nombre Un archivo digital que puede almacenar la  Identificador numérico Archivo aplicación y puede estar asociado a auditorías  Nombre o a hallazgos.  Contenido Son campos que se definen para ingresar  Identificador numérico información sobre indicadores de mejora sobre  Nombre hallazgos aunque se asocian directamente con  Tipo Campo auditorías.  Valores por defecto personalizado  Expresión regular  Longitud mínima  Longitud Máxima Son reportes específicos que se realizan sobre  Identificador numérico Seguimiento cada seguimiento para reportar detalles de  Descripción avance por parte de los usuarios asociados. Son descriptores que indican de donde  Identificador numérico Origen proviene la información sobre la auditoría.  Nombre Es el registro sobre las acciones que realizan  Identificador numérico los usuarios sobre los hallazgos y la  Fecha Historial descripción de dichas acciones.  Descripción  Cambio realizado.

Fuente: Autores del proyecto

7.8.5. Relaciones

Tabla 9: Lista de entidades del modelo relacional resultante clasificadas Entidad Relaciones Entidad implicada Están asociados uno o más usuarios Usuarios Puede tener uno o más hallazgos Hallazgos Tiene asociados uno o más campos Campos personalizados Auditoría personalizados Está asociada con uno o más orígenes Orígenes Puede tener uno o más archivos Archivo Está en una auditoría Auditoría Están asociados uno o más usuarios con un Usuario rol específico sobre el hallazgo Tiene uno o más seguimiento Seguimiento Hallazgo Está asociado con uno o más campos Campos personalizados personalizados Puede tener un solo archivo Archivo Tiene uno o más registros en el historial Historial Puede estar asociado con una auditoría Auditoría Puede realizar un hallazgo Hallazgo Usuario Puede reportar un seguimiento Seguimiento Tiene un rol Rol Esta registrado en un registro del historial Historial Archivo Puede estar asociado a una o más auditorías Auditoría Campo Está asociado a una o más auditorías Auditoría personalizado Tiene un valor registrado por hallazgo Hallazgo Está asociado a un hallazgo Hallazgo Seguimiento Es reportado por un usuario Usuario Origen Está asociado a una o más auditorías Auditoría Está asociado a un hallazgo Hallazgo Historial Es reportado por un usuario Usuario

Fuente: Autores del proyecto

7.8.6. Diagrama Modelo entidad-relación.

Complementando la exposición sobre la base de datos, se genera el modelo entidad- relación; el diagrama resultante del proceso de análisis es el siguiente:.

Figura 27: Diagrama estados de los hallazgos.

Fuente: Autores del proyecto

7.9. IMPLEMENTACIÓN BASE DE DATOS

La base de datos como tal no se modelo ni se implementó completamente, el trabajo concerniente al desarrollo a la base de datos se dejó para que MantisBT generara el modelo predeterminado que viene por defecto en la instalación del Framework. A continuación se mostrará cómo se adaptaron los requerimientos de los datos necesarios para los planes de mejoramiento mediante una comparación del modelo conceptual y la implementación realizada por Mantis.

7.9.1. Comparación modelo entidad-relación y tablas de MantisBT

En la siguiente tabla de relación entre el modelo conceptual y el modelo de MantisBT se muestra como se implementa el modelo en la parte técnica; para este propósito se usó el motor de mases de datos de MySQL usando los siguientes tipos de dato41:

• Entero (Integer, TinyInt y SmallInt)

• Texto (Text, MediumText y LongText)

• Para archivo se utilizan datos tipo BLOB.

Las tablas de la implementación pueden variar con respecto al modelo entidad- relación debido a detalles específicos definidos en Mantis.

Tabla 10: Lista de entidades del modelo relacional resultante clasificadas Atributo Tamaño Tipo de dato Tabla/Atributo Clave Domino equivalente candidat no primo MantisBT a Auditoría Mantis_project_table Identificador 10 INT Id X numérico Nombre 128 VARCHAR Name X Descripción - LONGTEXT Description X

41 Para mayor información sobre tipos de datos en MySQL consultar https://dev.mysql.com/doc/refman/5.6/en/data-types.html

Estado 6 SMALLINT Status X Activado 6 SMALLINT Enabled X Visibilidad 4 TINYINT Access_min X Hallazgo Mantis_bug_table Identificador 10 INT Id X numérico Descripción - LONGTEXT Description X Reproductibilidad 6 SMALLINT Reproductibility X Severidad 6 SMALLINT Severity X Prioridad 6 SMALLINT Priority X Resumen 128 VARCHAR Summary X Fecha del 10 INT Date Submitted X hallazgo Estado 6 SMALLINT State X Análisis Causal - LONGTEXT Steps to_reproduce X Acciones - LONGTEXT Additional X correctivas Information Usuario Mantis_user_table Identificador 10 INT Id X numérico Nombre 64 VARCHAR realname X Alias 32 VARCHAR Username X Contraseña 32 VARCHAR Password X Correo 64 VARCHAR email X Electrónico Rol Mantis_project_user_list_table Id del rol 10 SMALLINT Access level X Id de auditoria 10 INT Project_id X Id de usuario 10 INT User_id X Mantis_project_file_table, Archivo42 Mantis_bug_file_table Identificador 10 INT Id X numérico Nombre 250 VARCHAR Title X Contenido - LONGBLOB Content X Campo Personalizado Mantis_custom_field_table Identificador 10 INT id X numérico Nombre 64 VARCHAR name X Tipo 6 SMALLINT Type X Valores por 255 VARCHAR Possible_values X defecto Expresión regular 255 VARCHAR Valid_regexp X Longitud mínima 11 INT Length_min X Longitud Máxima 11 INT Length_max X Seguimiento Mantis_bugnote_Table Identificador 10 INT Id X numérico Descripción - LONGTEXT Note X Origen Mantis_category_table Identificador 10 INT Id X numérico Nombre 128 VARCHAR Name X Historial Mantis_bug_history_table Identificador 10 INT Id X

42 Si bien en el modelo se define una sola entidad para archivo, en MantisBT se manejan dos entidades separadas para guardar archivos en Auditorías y Seguimientos, sin embargo las tablas son idénticas salvo sus relaciones con las entidades anteriormente mencionadas.

69 numérico Fecha 10 INT Date_modified X Descripción 64 VARCHAR Field_name X Cambio 255 VARCHAR New_value X realizado.

Fuente: Autores del proyecto

8. DESARROLLO E IMPLEMENTACION

Complementando con el ciclo de desarrollo para la construcción de la herramienta para la gestión de planes de mejoramiento en procesos de auditoría, se optó por utilizar e implementar sobre plataformas de software libre gracias a los reducidos costos; una de las ventajas del proyecto es la complejidad mínima en cuanto al número de herramientas que se utilizaron y que conforman la aplicación, web, lo cual permitió concentrar fácilmente los esfuerzos en la construcción de la herramienta y su adaptación a las políticas de las Entidades del Distrito. Esta sección estará dedicada a exponer desde el punto de vista técnico el proceso de construcción de la herramienta desde sus componentes hasta el desarrollo.

8.1. ENTORNO GENERAL DE DESARROLLO

El entorno sobre el cual corre la herramienta y se realizó el desarrollo se compone de las siguientes partes, tal como se encuentra compuesta cualquier aplicación web básica:

 Un lenguaje de programación que se ejecuta en el servidor y actúa en conjunto con el servidor web para responder las peticiones recibidas, en este caso se escogió PHP.

 Junto al lenguaje de programación el servidor web quien recibe y responde las peticiones bajo el protocolo HTTP, el escogido fue Apache Web Server.

 Un servidor para manejo de la información en una base de datos relacional, en este caso por costos y complejidad se escogió MySQL.

 Por último, un entorno de desarrollo que proporciones funciones para reporte y gestión de incidentes, en este caso se escogió MantisBT que si bien está orientado a procesos de programación y software, fue adaptado para cumplir con las funciones de herramienta de gestión de planes de mejoramiento.

A continuación se explican en detalle en qué consisten las herramientas mencionadas en la lista anterior.

8.1.1. Lenguaje de servidor PHP

43 Siempre y cuando se generen scripts en estas dos formas, el servidor reconocerá el código para ser ejecutado en PHP. “http://www.php.net/manual/es/tutorial.firstpage.php”

71 usar este lenguaje es la facilidad con las que el usuario puede ver resultados y obtener funcionalidades sin necesidad de ejecutar comandos externos o desde el sitio en PHP, además de explotar las funcionalidades de la ejecución de un aplicativo en un típico esquema cliente servidor. El funcionamiento de las páginas en PHP alojadas en un servidor es el siguiente:

 El navegador del cliente solicita el documento PHP.

 Llega la solicitud del servidor y el servidor localiza el documento, lanza el intérprete de PHP y ejecuta todo su código.

 Una vez ejecutado el código se genera el resultado en HTML y lo devuelve al servidor para que lo transfiera al cliente.

 El servidor transfiere el resultado en HTML y es mostrado en el navegador del cliente.44

8.1.2. Herramienta para gestión de incidentes Mantis Bug Tracker

Mantis45 es una completa solución que permite montar sistemas para la gestión de incidentes y errores en proyectos de desarrollo, que se encuentra licenciado bajo GNU, lo cual permite su uso libre. Esta herramienta trabaja sobre el lenguaje PHP, lo cual le facilita ser implementado bajo una gran variedad de sistemas operativos a través de una interfaz web, además de mantener una gran compatibilidad con varios motores de bases de datos conocidos. Algunas de las características46 que podemos encontrar en Mantis son:

 Implementación en una aplicación web

 Interfaz simple

 Gestión de usuarios

 Facilidad para el diseño de formularios

 Notificaciones por correo electrónico

 Generación de reportes

 Generación de páginas personalizadas para reportes de incidentes

 Seguimiento y trazabilidad de las diferentes actividades y acciones de los usuarios

44 Tomado de “http://www.manualdephp.com/manualphp/introduccion-php.html” 45 El software mantis se encuentra disponible en http://www.mantisbt.org/index.php 46 Una completa lista de características que posee Mantis se encuentra disponible en http://www.mantisbt.org/wiki/doku.php/mantisbt:features

Figura 28: Captura de pantalla de Mantis Bug Tracker

Fuente: Sitio Web de Mantis Bug Tracker47

8.1.3. Paquete de servicios Web WAMPP

Para ofrecer funcionalidades de bases de datos y alojamiento de sitios de prueba, tenemos el paquete WAMPP (Windows, Apache, MySQL, PHP and Perl, que contiene un paquete de servicios para implementación de sitios web multiplataforma, en este caso se usó el sistema operativo Linux Ubuntu.

Figura 29: Navegador Web con una página de muestra de WAMPP bajo.

Fuente: Bud’s Techshed48

47 Imagen tomada de http://www.mantisbt.org/index.php

El paquete contiene los siguientes programas que serán utilizados para las funcionalidades que se describen a continuación:

 Servidor Web Apache49: Es un servicio que implementa un servidor HTTP que permite alojar páginas con contenido dinámico, y accederlas desde cualquier sitio, cuenta con licencia libre; en el ámbito del prototipo, permite correr sitios web de prueba para pen testing, los sitios que se implementarán se describirán en secciones posteriores.

 MySQL:50 Este motor de base de datos permite alojar e implementar bases de datos de gran funcionalidad con pocos recursos, esencial para guardar información sobre las pruebas por parte del prototipo, tales como configuración y eventos de las pruebas. También aloja bases de datos de las aplicaciones de prueba para pen testing. Las funcionalidades de este motor pueden ser controladas a través de una aplicación web llamada “PHPMyAdmin51” incluida en el paquete XAMPP.

Figura 30: Pantalla de la aplicación PHPMyAdmin

Fuente: Sourceforge.net52

 PHP (Hypertext Preprocessor): El lenguaje de programación junto con los componentes necesarios viene incluidos de manera predeterminada en el paquete.

48 http://budstechshed.com/set-up-wordpress-on-your-own-local-wamp-webserver/ 49 Para información más detallada, consultar https://httpd.apache.org/ 50 Disponible individualmente en https://www.mysql.com/ 51 Disponible en http://www.phpmyadmin.net/home_page/index.php 52 http://sourceforge.net/projects/phpmyadmin/

8.2. CONTROL DE CAMBIOS

Al igual que la aplicación y como parte de la función original de MantisBT, se hizo un seguimiento sobre los cambios de la aplicación para llevar un control de los cambios realizados y especificar los cambios en los distintos archivos modificados. Los cambios se realizaron según el siguiente modelo de reporte:

 Identificador de incidencia: El número que le corresponde la incidencia

 Categoría: El componente que se modifica.

 Fechas: Se toman tanto las fechas en la cual se tomó la solicitud y la fecha del último cambio.

 Severidad: Impacto del cambio realizado

 Reproducibilidad: Si se puede reproducir el cambio realizado y el número de veces en forma cualitativa.

 Resolución: El estado de corrección del cambio.

 Estado: El estado propio de la incidencia con respecto a la atención y acciones realizadas en la funcionalidad.

 Resumen: El nombre de la incidencia.

 Descripción: El detalle del cambio a realizar/corregir.

 Nota: Aquí se encuentran los detalles específicos sobre cada cambio reportado con referencia al componente modificado y la línea que se modificó, este archivo esta con el comentario correspondiente a la línea modificada. Un ejemplo es:

o Archivo: config_inc.php

Variable: $g_manage_user_threshold

Valor por defecto: ADMINISTRATOR

Nuevo Valor: MANAGER

El ejemplo anterior se refiere a un archivo de configuración, el siguiente refiere a un archivo de un módulo:

o Archivo: manage_user_edit_page.php

Consecutivo de cambio: 001

Descripción:

-Se comentarea la siguiente linea para limitar el acceso a esta página al límite propuesto en la variable global manage_user_edit_threshold.

//access_ensure_global_level( config_get( 'manage_user_threshold' ) );

La línea que se comentareo anteriormente se modifica por esta.

access_ensure_global_level( config_get( 'manage_user_edit_threshold' ) );

Cada cambio se reporta en una nueva incidencia y se agregan los detalles correspondientes y los archivos modificados con un consecutivo de cambio según el caso. A continuación se detallan los cambios realizados en los archivos de MantisBT y su adaptación al propósito de este proyecto.

8.2.1. Interfaz gráfica

Uno de los principales cambios se realizó en la interfaz gráfica de la aplicación, por su naturaleza se usa una interfaz web la cual puede ser accedida desde cualquier navegador reciente, por lo cual se entiende que está construida en HTML (Lenguaje de Marcado Hipertexto) y CSS (Hojas de estilo en cascada) para la definición de las reglas de visualización. Algunos de los cambios más relevantes fueron:

 Cambio del logo original de MantisBT por el de la Entidad y reposicionamiento de este.

 Cambio de colores para algunos elementos como cabeceras o tablas (a continuación se mostrará más en detalle)

 Modificación de los bordes, ahora son redondeados y sombreados en algunas secciones.

 Modificación de los campos para registrar incidencias, que en este caso son los hallazgos.

 Se agrega una lista desplegable para seleccionar el proyecto deseado, en este caso la auditoría y se ubica en la parte superior izquierda.

 Se agrega una propiedad que permite resaltar cuando se pasa por encima del registro con el ratón, los hallazgos en la tabla.

 Se modifica la vista de impresión para incluir el logo de la Etntidad.

 Se modificó los botones de acciones para hacerlos más grandes en la sección “Ver hallazgos.”

A continuación se realizará un comparativo entre las principales secciones originales de MantisBT y la aplicación web modificada y adaptada para las Entidades del Distrito. Nótese que aún se conservan muchos atributos originales de MantisBT y que otros cambios no citados en la interfaz pertenecen a otros elementos de la aplicación como archivos de configuración y la lógica, que se expondrán más adelante:

 Sección “Mi vista”:

Figura 31: Comparación sección “Mi Vista” original vs aplicación modificada

Fuente: Autor del proyecto.

 Sección “Hallazgos”:

Figura 32: Comparación sección “Hallazgos” original vs aplicación modificada

Fuente: Autor del proyecto.

 Sección “Pantalla de ingreso”:

Figura 33: Comparación sección “Ingreso” original vs aplicación modificada

Fuente: Autor del proyecto.

8.2.2. Archivos de configuración

MantisBT maneja la configuración de la aplicación en un archivo; este se encarga de definir algunos aspectos clave como los roles y los permisos sobre las funcionalidades de la aplicación, archivo que fue modificado como base para la adaptación de la aplicación tal como se plantea en los requerimientos. El archivo modificado se llama “config_inc.php” y se encuentra en el raíz del proyecto y se encuentra codificado en el lenguaje php, este archivo contiene variables con valores de configuración que usan los distintos módulos de la aplicación a manera de una configuración global; este archivo también cuenta con variables de configuración sobre configuración técnica tal como el tipo de almacenamiento y la ubicación y manejo del servidor de la aplicación.

Los principales cambios fueron:

 Se desactivó la creación de cuentas por parte de cualquier usuario nuevo.

 Título del proyecto en el contenido de un correo electrónico es “Plan de Mejoramiento”.

 Título de la ventana de la aplicación: “Plan de Mejoramiento”

 Roles de acceso en la siguiente jerarquía:

o Espectador

o Auditor

o Líder de proceso

o Administrador

 Prioridad del hallazgo:

o Ninguna

o Baja

o Normal

o Alta

o Urgente

 Estados del hallazgo

o Nuevo

o Iniciado

o Confirmado

o Asignado

o Resuelto

o Cerrado

 Estados de resolución del hallazgo

o Nuevo

o Reabierto

o Cerrado

 Permisos específicos sobre acciones de la aplicación, especificado en los casos de uso, además de especificar y limitar permisos originales para que los roles de Auditor y Líder tengan menos permisos en comparación con la instalación original del MantisBT.

 Activación de almacenamiento en la base de datos y restricciones en la subida de archivos máximo de 1 MB y de formatos “.doc”, “.docx”, “.xls”, “.xlsx,ppt”, “.pptx”, “.jpg”, “.jpeg”, “.png”, “.pdf”, “.txt”, “.bmp”.

 Visibilidad de campos en hallazgos, se removieron los siguientes campos: “Información adicional” y “pasos a reproducir”, básicamente estos se ocultaron.

 Visibilidad de campos en vista de impresión, se ocultaron los siguientes campos originales del mantis:

o Proyección

o Plataforma

o Sistema Operativo

o Versión del producto

o Build de producto

o Versión objetivo

o Arreglado en versión

o Etiquetas

 Visibilidad de campos en vista “editar hallazgo”, se ocultaron los siguientes campos:

o Reportero

o Estado

o Resolución

o Resumen

o Descripción

 Visualización de errores

 Permisos sobre manejo de usuarios cedidos exclusivamente al administrador, excepto por la creación que se le otorga al auditor.

 Las opciones "Crear enlace permanente" y "Guardar filtro actual" se quitan y se restringen al administrador.

Adicional a esto, también se modificó el archivo de definición del lenguaje para adaptar los términos originales del Mantis a los del lenguaje particular de un entorno de auditoría y mejoramiento continuo; este archivo se llama “strings_spanish.txt” dentro de la carpeta lang del proyecto.

8.2.3. Modificación de los módulos

Los módulos de la aplicación no sufrieron cambios sustanciales en cuanto al manejo de la información y los procedimientos de MantisBT, sin embargo y como parte del objetivo, se modificaron algunos archivos con los siguientes cambios:

 Página de resumen: Se modificó el archivo “summary_page.php” para ocultar algunos vínculos sobre estadísticas como:

o Estadísticas de Tiempo para Hallazgos Resueltos.

o Por Fecha (días)

o Efectividad del Auditor

 Se quita el botón clonar por no ser funcional para el proyecto, se modifica el archivo “html_api.php” de la carpeta “core”.

 Se modifica “my_view_page.php” para mostrar todos los hallazgos monitorizados sin importar su rol, antes solo mostraba a los monitores del rol “auditor”.

9. PLAN DE PRUEBAS

En la última parte del desarrollo se realizó un proceso para las pruebas de software para validar las funcionalidades con las partes. En este apartado se mostrarán los diferentes componentes del plan de pruebas y las estrategias sobre cómo se abordó el proceso, sin detallar la parte técnica. Para documentar el proceso adecuadamente, se utilizaron varios enfoques para la construcción del plan de pruebas ya que actualmente no existen estándares para la construcción y abordaje de las pruebas, tomando las partes relevantes a la implementación de las pruebas. Entre los documentos de referencia está el brindado por el departamento de sistemas de la Universidad de los Andes53, de Array Development54 (un trabajo realizado como ejemplo por parte de estudiantes de la Universidad Pontificia Católica del Perú) y recomendaciones adicionales de la Universidad de Buenos Aires55.

9.1. PROPOSITO DEL PLAN

El presente plan tiene como objetivo la planificación y ejecución de las pruebas sobre la aplicación de los planes de mejoramiento de las Entidades del Distrito, no solo incluyendo la acciones para su exitosa ejecución, también como parte en si de un conjunto de mejoras que permitan su correcto funcionamiento de acuerdo a las políticas a las que se encuentra sujeta la entidad y teniendo en cada momento trazabilidad absoluta de cada proceso de mejoramiento continuo.

9.2. ALCANCES

El enfoque principal de las pruebas son los módulos que se plantearon en la sección de requerimientos, centrándose en las pruebas funcionales que validarán el funcionamiento de los módulos y tomar acciones correctivas en caso de encontrar defectos y errores, de forma que se podrán reportar y corregirlos rápidamente además de realizar los cambios que el cliente considere necesarios.

Las pruebas de aceptación se implementarán permitiendo al cliente probar los módulos de la aplicación uno a uno y corroborando a satisfacción o denegando el funcionamiento de los módulos, de forma que se encuentre el sistema a conformidad de acuerdo a los requisitos definidos. Las pruebas se relazarán tanto sobre requerimientos funcionales como sobre los no funcionales.

53 El documento de ejemplo del plan de pruebas puede ser descargado de http://sistemas.uniandes.edu.co/~arti4001/dokuwiki/lib/exe/fetch.php?media=principal:calendario:dt_ptl_pl npruebas.doc/, con referencias adicionales de http://sistemas.uniandes.edu.co/~isis2603/dokuwiki/doku.php?id=principal:pruebas 54 Un ejemplo de un plan de pruebas puede ser consultado de http://www.oocities.org/farp81/documentacion.html 55 La documentación puede ser consultada en http://materias.fi.uba.ar/7548/

9.3. ENTORNO DE PRUEBAS

El entorno de las pruebas será reducido incluyendo solo los elementos necesarios para que desde cualquier equipo pueda ser accedida la aplicación, por lo tanto se especifican los siguientes elementos dentro del entorno:

 Recursos de los usuarios: Computadores PC con sistema operativo Windows, los cuales tienen una antigüedad entre uno y seis años, por lo cual se espera que tengan como requerimientos mínimos procesadores mínimo de 32 bits, modelos Intel Pentium 4 o Athlon X2, con 512 MB de memoria RAM y con acceso a red obligatoriamente, y sistema operativo Windows XP o Linux, por lo cual se considera que están habilitados para su acceso a la aplicación sin la necesidad de tener recursos adicionales para su ejecución.

 Servidor Web: El servidor web será manejado por la Entidad; el nivel de usuarios es bajo por lo cual no se hace necesario tener un servidor con prestaciones muy altas para cumplir con las tareas de los planes.

 PC cliente: El pc que realizará las pruebas cumplirá con todos los requisitos citados en el punto “Recursos de los usuarios”, y será aportado por los integrantes del proyecto.

9.4. ROLES Y RESPONSABILIDADES

Tabla 11: Lista de roles y responsabilidades Cargo Responsable Responsabilidades específicas / comentarios Administrador de Gustavo Soto Proporcionar atención especial al pruebas funcionamiento correcto de las tareas principales del sistema.

Responsabilidades:

 Proporcionar dirección técnica.  Adquirir los recursos apropiados.  Administración de reportes. Diseñador de Identificar, asignar la prioridad, e pruebas implementar los casos de la prueba a ejecutar.

Responsabilidades:

 Generar el plan de prueba.  Generar la especificación de los distintos tipos de prueba.  Generar el modelo de prueba.  Evaluar la eficacia del esfuerzo en la prueba. Ejecutor de Realizar las pruebas pruebas Responsabilidades:

 Ejecutar pruebas.  Registrar resultados.  Recuperación después de errores.  Documentación de errores y sugerencias.

9.5. PRUEBAS A APLICAR

El tipo de pruebas que se realizadan son las de tipos funcionales56, los otros tipos de prueba no se realizarán ya que la aplicación no será de gran escala ni requeriría pruebas intensivas, solo se centrará en las funcionalidades principales y no sobre el funcionamiento propio de MantisBT ya que no serán sustanciales los cambios sobre el gestor de incidencias.

9.6. CASOS DE PRUEBA

Para la documentación de los casos de prueba del prototipo se utilizará el siguiente formato57:

Tabla 12: Formato para los casos de prueba del prototipo caso-de-prueba-único: Título de Casos de Prueba Propósito Una o dos oraciones cortas sobre el aspecto del sistema que está siendo probado. Si esto toma mucho tiempo, rompa el caso de prueba o ponga más información en las descripciones de las características. Prerrequisitos Suposiciones que deben cumplirse antes de que correr el caso de prueba. Por ejemplo, "registrado", "inicio de sesión como invitado permitido", "el usuario testuser existe". Datos de prueba Lista de variables y sus posibles valores usados en el caso de prueba. Ud. puede enlistar valores específicos o describir rangos de valores. El caso de prueba deberá ser ejecutado una vez por cada combinación de valores. Estos valores se escriben notación de asignación, uno por línea. Por ejemplo: loginID = {loginID válido, loginID inválido, email válido, email inválido , vacío} password = {válido, inválido, vacío} Pasos Pasos a ejecutar la prueba. Vea las reglas de formateo para pasos abajo. La siguiente lista solo es un ejemplo:

 visitar LoginPage  teclear usernameOrEmail  teclear password  hacer click en Entrar  ver: la página de los términos de uso  hacer click hasta el fondo de la página  hacer en click Aceptar  ver: PersonalPage

verificar el mensaje de bienvenida si el inicio de sesión es correcto Notas y preguntas  NOTA

56 La definición puede ser consultada en detalle en http://www.calidadysoftware.com/testing/pruebas_funcionales.php 57 La plantilla es provista por ReadySet, en http://readyset.tigris.org/nonav/es/templates/test-case- format.html

 PREGUNTA

Fuente: Autor del proyecto

Los casos de pruebas se documentarán en detalle en el anexo C, la lista de los casos de uso aplicados a las pruebas es el siguiente:

Tabla 13: Casos de prueba aplicación NOTACIÓN NOMBRE Subsistema Login_01 Inicio de sesión correcto Login_02 Inicio de sesión incorrecto Login_03 Inicio de sesión expirada Logout_01 Cerrar sesión Subsistema manejo de Modify_01 Modificar datos propios de usuario usuarios Modify_02 Modificar datos cualquier usuario Create_01 Crear usuario Delete_01 Eliminar usuario Audit_01 Crear auditoría Audit_02 Modificar Auditoría Audit_03 Acceder a auditoría Origin_01 Agregar origen de auditoría Origin_02 Modificar origen de auditoría Origin_03 Eliminar origen de auditoría. Subsistema auditorías Aud_field_01 Agregar campos personalizados Aud_field_02 Modificar campos personalizados agregados Aud_field_03 Eliminar campos personalizados agregados Usr_audit_01 Agregar usuarios a la auditoría Usr_audit_02 Quitar usuarios a la auditoría Doc_audit_01 Subir documentos Finding_01 Agregar hallazgos Finding_02 Modificar hallazgos Finding_03 Ver hallazgo Finding_04 Cambiar estado hallazgo Finding_05 Asignar hallazgo Finding_06 Cerrar hallazgo Subsistema hallazgos Tracing_01 Agregar seguimiento Mon_finding_01 Monitorizar hallazgo Mon_finding_02 Agregar monitor a hallazgo Mon_finding_03 Quitar monitor a hallazgo File_finding_01 Agregar archivo a hallazgo Prn_finding_01 Imprimir información hallazgos Cust_field_01 Crear campos personalizados Subsistema campos Cust_field_02 Modificar campos personalizados personalizados Cust_field_03 Eliminar campos personalizados

Fuente: Autor del proyecto

10. IMPACTO Y APLICACIONES A FUTURO

 Desarrollo sobre plataformas con licencias de software libre: Gracias a las políticas del distrito (concretamente la Comisión Distrital de Sistemas) y el desarrollo de esta herramienta, se demuestra las ventajas de desarrollar aplicaciones sobre plataformas con licencias libres, lo cual permite consolidar la implementación de estas plataformas lo cual permite a futuro implementar estas tecnologías aprovechando sus ventajas citadas en la introducción de este proyecto.

 Aplicación a otras entidades del distrito: Añadido al punto anterior, esta clase de aplicaciones demuestra que, aprovechando la maleabilidad que permite este tipo de aplicaciones gracias a las licencias libres, se puede lograr una flexibilidad de forma que no solo cumpla con las normas establecidas para el control, también se puede ajustar al modus operandi de cada entidad, de forma que esta herramienta puede ser modificada para ajustarse a los procedimientos propios que tiene cada entidad y en conjunto, mejorar la herramienta basándose en las experiencias propias de cada caso.

 Integración con otros procesos y metodologías de auditoría: Otro de los objetivos que se esperan después de implementar esta herramienta, es la posibilidad de integrar la herramienta con otros procesos y metodologías de auditoría que permita a las entidades distritales ampliar sus procesos y planes de mejoramientos en áreas que aún no hayan sido cubiertas y en conjunto con estos planes, mejorar la herramientas permitiendo su ajuste y adaptación para implementar estos planes en estos ámbitos específicos.

 Mejoramiento en el monitoreo sobre los planes de control: La implementación de la aplicación permitió también el monitoreo sobre los hallazgos formulados por parte de entes externos, logrando mostrar las evidencias de la efectividad en la documentación de estos planes de mejora y su seguimiento, registrando eventos e indicadores e involucrando a los actores internos de las Entidades, lo cual repercute en una mejor gestión del proceso de mejoramiento continuo y corrección de desviaciones encontradas en las diferentes auditorías.

 Mantenimiento y mejora de la aplicación: Se recomienda seguir con el desarrollo y mantenimiento de la aplicación para cumplir con las aplicaciones citadas anteriormente, por lo cual se recomiendan implementar las siguientes mejoras en la aplicación:

o Captura de la información mediante tecnologías de lado del cliente como Jquery y Ajax.

o Seguridad mediante cifrado de datos del almacenamiento y las comunicaciones.

o Mejoras en tiempos de respuesta.

o Modificación de la interfaz.

o Comunicación con otros sistemas informáticos de control pertenecientes a entes externos y gubernamentales para el envío de informes consolidados.

11. ANÁLISIS DE COSTO-BENEFICIO PARA IMPLEMENTACIÓN EN ENTIDADES DEL DISTRITO.

En el evento que una Entidad del Distrito desee implementar y abordar un proyecto de estas características, es crucial contar con un análisis de costos de implementación a fin de evaluar los posibles beneficios que tendrá el sistema al interior de las Organizaciones, en especial en los equipos de auditoría y líderes de los procesos.

Es importante hacer énfasis en la cobertura que el sistema tendría dentro de la Organización, así como la profundidad en cuanto a la cantidad de usuarios potenciales que podría haber. Teniendo en cuanta que las oficinas de Control Interno y Calidad hacen parte de procesos transversales en las Instituciones, cabe destacar que cualquier software que se implemente en dichas oficinas, repercutirá en mayor o menor proporción en toda la Organización, ya que por lo general los procesos de auditoría conllevan a la ejecución de planes de mejoramiento que permiten a cada una de las áreas funcionales establecer acciones que impactaran positivamente en el logro de los objetivos Institucionales.

Por otro lado, al tratarse de un proyecto de software libre, no se debe caer en la trampa de pensar que no se incurrirá en ningún tipo de costo, ya que esto reside principalmente en costos asociados a licenciamientos como sistemas operativos, frameworks, bases de datos, sin embargo los demás costos inherentes a la implementación de cualquier proyecto estarán presentes, tal es el caso de consultorías, adaptación del sistema a la Organización, capacitaciones, puesta en marcha del sistema, hardware, mantenimiento. 58.

Paralelamente se deben considerar los beneficios que traerá a la Entidad la erogación de los costos identificados ya que muy a menudo están bastante relacionados y con frecuencia depende uno del otro. En gran medida la medición de los costos permite evaluar los beneficios del nuevo sistema.

Inicialmente se entrará a realizar un cálculo de cargas de trabajo, esto teniendo en cuenta que uno de los principales impactos que tendrá en Sistema en la Entidades, es la optimización del tiempo que gastan los auditores y líderes de proceso en la formulación y seguimiento a planes de mejoramiento.

Posteriormente haremos un estudio de los costos tangibles e intangibles asociados a la implementación del proyecto para así determinar los beneficios tanto tangibles como intangibles de la solución.

11.1. CÁLCULO DE CARGAS DE TRABAJO

En este cálculo se realizará una comparación entre llevar a cabo el proceso de una manera manual Vs llevarlo de una forma sistematizada, teniendo en cuenta las

58 Modelo de Análisis Costos-Beneficio para Sistemas Integrados de Administración Financiera

88 actividades propias estandarizadas que se realizan en el desarrollo de un plan de mejoramiento.

Para medir la carga laboral se tomó como base la Guía de Modernización de Entidades Públicas59 del Departamento Administrativo de la Función Pública, que da lineamientos para poder medir y estimar el tiempo requerido que emplean los servidores públicos para realizar diferentes tareas.

De igual manera y para complementar los cálculos realizados en cuanto al tiempo total empleado por mes para cada actividad, nos apoyamos en la Guía Metodológica para el Estudio de Cargas de Trabajo de la Universidad Nacional60 en donde se establece que el tiempo resultante de realizar una tarea, obedece a la fórmula.

푇 = (푇푚 + 4푇푝 + 푇푀)/6

Donde

 T = Tiempo resultante

 Tm = Tiempo mínimo asignado a la tarea

 Tp = Tiempo promedio asignado a la tarea

 TM = Tiempo máximo asignado a la tarea.

En esta matriz61 se puede observar que a la anterior fórmula se le hace una corrección multiplicando el resultado por 1.07, esto con el fin de estandarizar los meses a 30 días.

En la Tabla 14: Cálculo de carga de trabajo con un proceso manual y la Tabla 15: Cálculo de carga de trabajo con el sistema propuesto, se puede observar los tiempos requeridos para realizar las actividades en cada escenario, esto teniendo en cuenta que algunas actividades se suprimirían una vez sea implementado el sistema.

59 http://portal.dafp.gov.co/form/formularios.retrive_publicaciones?no=1431 60 http://www.unal.edu.co/dnp/Archivos_base/DocumentoTrabajo_GuiaEstudioCargasTrabajo.pdf 61 https://www.funcionpublica.gov.co/documents/418537/1239516/Anexo+6.+Copia+de+Matriz+Perfiles+y +Cargas/32f34ac1-b5f6-4ade-a883-9650cdc6ec15

Tabla 14: Cálculo de carga de trabajo con un proceso manual

Cantidad de Tiempo Mínimo - Tm Tiempo Promedio - Tp Tiempo Máximo - TM Tiempo Tiempo de Promedio Mes - Hora Tiempo Tiempo veces que se Máximo - trabajo por Minimo - Promedio - Líder de repite la tarea Seg Min Horas Días Seg Min Horas Días Seg Min Horas Días TM tarea Auditor Tm (Horas) Tp (Horas) Proceso Procedimiento Actividad Tarea Quien realiza la tarea en el mes (Horas) (Horas) Ingresar en matriz los hallazgos de auditoría Auditor 5 0 8 0 0 0,13 0 10 0 0 0,17 0 15 0 0 0,25 0,19 0,94 0,00 Consolidar hallazgos de Informar sobre la formulación de un plan de auditoría mejora Auditor 5 0 1 0 0 0,02 0 2 0 0 0,03 0 4 0 0 0,07 0,04 0,19 0,00 Definir análisis causal Líderes de proceso 25 0 3 0 0 0,05 0 4 0 0 0,07 0 6 0 0 0,10 0,07 0,00 1,86 Formular plan de Definir acciones de mejora Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 Consolidar plan de mejoramiento Establecer meta a alcanzar Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 mejoramiento Establecer indicadores de seguimiento Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 Imprimir plan de mejoramiento Auditor 5 0 2 0 0 0,03 0 3 0 0 0,05 0 5 0 0 0,08 0,06 0,28 0,00 Aprobar plan de Firma entre las partes del plan de mejoramiento mejoramiento Auditor / Lider 5 0 1 0 0 0,02 0 2 0 0 0,03 0 5 0 0 0,08 0,04 0,21 0,21 Archivar plan de mejoramiento Auditor 5 0 2 0 0 0,03 0 3 0 0 0,05 0 6 0 0 0,10 0,06 0,30 0,00 Realizar Acciones de Varias Tareas dependiendo del plan de Mejora y/o Correctivas mejoramiento Líderes de proceso 25 0 8 0 0 0,13 0 10 0 0 0,17 0 15 0 0 0,25 0,19 0,00 4,68 Fotocopiar registros documentales que soporten la ejecución de las acciones Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 7 0 0 0,12 0,09 0,00 2,30 Ejecutar Plan de Consolidar Evidencias Archivar en AZ las evidencias fotocopiadas Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 mejoramiento Diligenciar matrices de seguimiento Líderes de proceso 5 0 12 0 0 0,20 0 15 0 0 0,25 0 20 0 0 0,33 0,27 0,00 1,37 Solicitar a auditoría el cierre de halazgos Líderes de proceso 2 0 1 0 0 0,02 0 2 0 0 0,03 0 3 0 0 0,05 0,04 0,00 0,07 Resolver hallazgos Atender visita de auditoría para seguimiento y/o cierre de hallazgos Líderes de proceso 2 0 28 0 0 0,47 0 35 0 0 0,58 0 50 0 0 0,83 0,65 0,00 1,30 Agendar con el líder de proceso visita de Notificación de seguimiento Auditor 5 0 1 0 0 0,02 0 2 0 0 0,03 0 2 0 0 0,03 0,03 0,16 0,00 seguimiento Enviar correo electrónico u oficio firmado de notificación Auditor 5 0 1 0 0 0,02 0 2 0 0 0,03 0 2 0 0 0,03 0,03 0,16 0,00 Dirigirse personalmente a las oficinas para revisar avances Auditor 5 0 6 0 0 0,10 0 7 0 0 0,12 0 10 0 0 0,17 0,13 0,65 0,00 Seguimiento a plan de Revisar evidencias documentales que mejoramiento respalden la ejecución del plan Auditor 25 0 4 0 0 0,07 0 5 0 0 0,08 0 7 0 0 0,12 0,09 2,30 0,00 Evaluar indicadores de seguimiento Auditor 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 2,38 0,00 Realizar seguimiento

Evaluar nivel de avance de la meta propuesta Auditor 25 0 3 0 0 0,05 0 4 0 0 0,07 0 6 0 0 0,10 0,07 1,86 0,00 Diligenciar Matriz de Seguimiento Auditor 5 0 10 0 0 0,17 0 12 0 0 0,20 0 15 0 0 0,25 0,22 1,08 0,00 Imprimir matriz de seguimiento Auditor 5 0 5 0 0 0,08 0 6 0 0 0,10 0 9 0 0 0,15 0,11 0,56 0,00 Firmar Plan de mejoramiento Auditor / Lider 5 0 2 0 0 0,03 0 3 0 0 0,05 0 5 0 0 0,08 0,06 0,28 0,28

Cerrar Plan de Verificar evidencias Auditor 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 2,38 0,00 Mejoramiento Verificar si se cumplió la meta propuesta Auditor 25 0 2 0 0 0,03 0 4 0 0 0,07 0 6 0 0 0,10 0,07 1,78 0,00 Diligenciar Matriz de Seguimiento Auditor 5 0 10 0 0 0,17 0 12 0 0 0,20 0 15 0 0 0,25 0,22 1,08 0,00 Cierre Plan de Imprimir plan de mejoramiento Auditor 5 0 5 0 0 0,08 0 6 0 0 0,10 0 9 0 0 0,15 0,11 0,56 0,00 Mejoramiento Firmar Plan de mejoramiento Auditor / Lider 5 0 2 0 0 0,03 0 3 0 0 0,05 0 5 0 0 0,08 0,06 0,28 0,28 Archivo y formalización Archivar los registros documentales tanto del del cierre área auditada como de auditoría del plan de mejoramiento firmado Auditor / Lider 25 0 5 0 0 0,08 0 7 0 0 0,12 0 10 0 0 0,17 0,13 3,20 3,20 Total Horas por quien realiza la tarea 20,66 25,06

Fuente: Autor del proyecto

Tabla 15: Cálculo de carga de trabajo con el sistema propuesto

Cantidad de Tiempo Mínimo - Tm Tiempo Promedio - Tp Tiempo Máximo - TM Tiempo Tiempo de Promedio Mes - Hora Tiempo Tiempo veces que se Máximo - trabajo por Minimo - Promedio - Líder de Quien realiza la repite la tarea Seg Min Horas Días Seg Min Horas Días Seg Min Horas Días TM tarea Auditor Tm (Horas) Tp (Horas) Proceso Procedimiento Actividad Tarea tarea en el mes (Horas) (Horas) Consolidar Ingresar en el aplicativo los hallazgos hallazgos de de auditoría Auditor 5 0 4 0 0 0,07 0 5 0 0 0,08 0 7 0 0 0,12 0,09 0,46 0,00 auditoría Asignar hallazgos a líderes Auditor 5 30 0 0 0 0,01 40 0 0 0 0,01 0 1 0 0 0,02 0,01 0,06 0,00 Consolidar plan Definir análisis causal Líderes de proceso 25 0 3 0 0 0,05 0 4 0 0 0,07 0 6 0 0 0,10 0,07 0,00 1,86 de Formular plan de Definir acciones de mejora Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 mejoramiento mejoramiento Establecer meta a alcanzar Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 Establecer indicadores de seguimiento Líderes de proceso 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 0,00 2,38 Aprobar plan de Aprobar plan en el aplicativo Auditor 5 0 1 0 0 0,02 0 2 0 0 0,03 0 4 0 0 0,07 0,04 0,19 0,00 Realizar Acciones Varias Tareas dependiendo del plan de de Mejora y/o mejoramiento Líderes de proceso 25 0 8 0 0 0,13 0 10 0 0 0,17 0 15 0 0 0,25 0,19 0,00 4,68 Escanear registros documentales que soporten la ejecución de las acciones Líderes de proceso 25 0 3 0 0 0,05 0 4 0 0 0,07 0 7 0 0 0,12 0,08 0,00 1,93 Ejecutar Plan de Consolidar Adjuntar en el aplicativo las evidencias mejoramiento Evidencias escaneadas Líderes de proceso 25 0 2 0 0 0,03 0 4 0 0 0,07 0 5 0 0 0,08 0,07 0,00 1,71 Ingresar seguimiento en el aplicativo Líderes de proceso 25 0 2 0 0 0,03 0 3 0 0 0,05 0 6 0 0 0,10 0,06 0,00 1,49 Cambiar de estado en el aplicativo los Resolver hallazgos hallazgos a resueltos Líderes de proceso 2 40 0 0 0 0,01 0 1 0 0 0,02 0 2 0 0 0,03 0,02 0,00 0,04 Revisar evidencias del sistema Auditor 25 0 2 0 0 0,03 0 3 0 0 0,05 0 5 0 0 0,08 0,06 1,41 0,00 Seguimiento a Evaluar indicadores de seguimiento Auditor 25 0 4 0 0 0,07 0 5 0 0 0,08 0 8 0 0 0,13 0,10 2,38 0,00 plan de Realizar seguimientoEvaluar nivel de avance de la meta mejoramiento propuesta Auditor 25 0 3 0 0 0,05 0 4 0 0 0,07 0 6 0 0 0,10 0,07 1,86 0,00 Ingresar seguimiento en el aplicativo Auditor 25 0 2 0 0 0,03 0 3 0 0 0,05 0 6 0 0 0,10 0,06 1,49 0,00

Verificar evidencias Auditor 25 0 5 0 0 0,08 0 6 0 0 0,10 0 8 0 0 0,13 0,11 2,75 0,00 Cierre Plan de Cerrar Plan de Verificar si se cumplió la meta Auditor 25 0 2 0 0 0,03 0 4 0 0 0,07 0 6 0 0 0,10 0,07 1,78 0,00 Mejoramiento Mejoramiento Ingresar seguimiento en el aplicativo Auditor 25 0 2 0 0 0,03 0 3 0 0 0,05 0 6 0 0 0,10 0,06 1,49 0,00 Cambiar estado de hallazgos a cerrado Auditor 25 30 0 0 0 0,01 0 2 0 0 0,03 0 4 0 0 0,07 0,04 0,93 0,00 Total Horas por quien realiza la tarea 14,80 18,84

Fuente: Autor del proyecto

Como resumen del cálculo de carga de trabajo concluimos que hay una variación significativa en la reducción del tiempo en horas-mes destinadas a la ejecución del proceso de plan de mejoramiento.

Tabla 16: Variación tiempo destinado en horas para la ejecución del plan de mejoramiento Proceso Proceso Manual Rol Sistematizado Var (Horas-Mes) (Horas-Mes) Auditor 20,66 14,80 -28,37% Lider 25,06 18,84 -24,81%

Fuente: Autor del proyecto

Se puede evidenciar una disminución del 28.37% en el tiempo que destina una auditor en las tareas propias que se requieren llevar a cabo en el seguimiento plan de mejoramiento. Adicionalmente, para el líder de proceso también se evidencia una disminución del 24.81% en la ejecución del plan de mejoramiento.

Figura 34: Proceso Manual Vs Proceso Sistematizado

Fuente: Autor del proyecto

11.2. COSTOS TANGIBLES E INTANGIBLES

Teniendo en cuenta que los costos tangibles consideran todas aquellas erogaciones que son fácilmente detectables y cuantificables en determinado periodo de tiempo, se considera pertinente incluir costos tales como hardware, software y servicios.

 Hardware: Servidor, estaciones de trabajo.

 Software: Licencia base de datos, Framework Mantis BT

 Servicios: Ingeniero de implementación, capacitaciones, asistencia usuario final, mantenimiento servidor, respaldo.

Tabla 17: Costos tangibles del sistema Costos tangibles Año 0 Año 1 Año 2 Año 3 Hardware 3.000.000 0 0 0 Servidor 3.000.000 0 0 0 Estaciones de trabajo 0 0 0 0 Software 0 0 0 0 Framework Mantis BT 0 0 0 0 Licencias Base de Datos 0 0 0 0 Servicios 11.000.000 5.000.000 5.000.000 5.000.000 Ingeniero de implementación 5.000.000 0 0 0 Capacitaciones 3.000.000 1.000.000 1.000.000 1.000.000 Asistencia al usuario final 2.000.000 2.000.000 2.000.000 2.000.000 Mantenimiento Servidor 0 1.000.000 1.000.000 1.000.000 Respaldo 1.000.000 1.000.000 1.000.000 1.000.000 Total 14.000.000 5.000.000 5.000.000 5.000.000 Fuente: Autor del proyecto

Las entidades no incurrirán en costos asociados a licencias de software, con lo cual es pertinente destacar que por ese aspecto hay un ahorro sustancial de recursos presupuestales.

El mayor costo se evidencia en los servicios asociados a la implementación y mantenimiento del servidor y la aplicación. En el primer año, el costo mas significativo corresponde a los honorarios de un ingeniero de implementación, quien se estima lleve a cabo el proceso 6 semanas, periodo en el cual se realizarán las configuraciones especiales que requiera la aplicación y la respectiva puesta en marcha en la infraestructura que posea la Entidad.

Los costos de asistencia al usuario final fueron proyectados con base a los honorarios promedio que recibe un ingeniero de soporte por prestación de servicios mensualmente y la carga de trabajo máxima que le traerá el soporte a la aplicación medido en Horas-Mes.

Honorarios ingeniero de soporte -> $4.000.000 mes

Honorarios x Hora -> $16.667

Horas Mes dedicadas al soporte de la aplicación -> 10

Honorarios anuales soporte usuario final -> 16.667 * 10 * 12 = $2.000.000

Se estimaron 10 horas de Soporte-Mes teniendo en cuenta que el sistema tiene un bajo nivel de transaccionalidad y los usuarios por Entidad corresponderán al equipo auditor y jefes de oficina y/o responsables de proceso, lo cual en el peor de los casos corresponde a un 5% del universo de empleados y/o contratistas.

Costos como estaciones de trabajo o infraestructura web no se tuvieron en cuenta ya que se parte de la base que las Entidades ya poseen dichas configuraciones.

Por otro lado, existen algunos costos que no pueden llegar a ser cuantificables como insatisfacción del cliente interno, pérdida de información, inoportunidades en la entrega de información.

11.2.1. ESPACIO EN DISCO DEL SERVIDOR.

Un plan de mejoramiento que en promedio tenga 25 hallazgos, con 3 seguimientos en promedio y 1.000 caracteres en cada uno de los campos que más información contienen como lo son la descripción, acciones de correctivas, análisis causal y seguimientos, puede llegar a ocupar un espacio de 0.67MB.

Figura 35: Tamaño Base de datos con 25 hallazgos

Si proyectamos el sistema cuando tenga 2.500 hallazgos, se puede estimar un espacio de la Base de datos de 67 MB. Es un espacio bastante reducido para almacenar tan volumen de información, teniendo en cuenta que ese estado se alcanzaría cuando se ingresen aproximadamente 250 auditorías promediando 10 hallazgos por auditoría, que perfectamente puede ser el histórico de auditorías de 3 años en una Entidad grande (más de 100 empleados).

Ahora bien, si adicional a ello se estima un cargue de evidencias (archivos pdf, Word, Excel, power point) de 5 archivos por hallazgo, de 2MB cada uno, cada hallazgo ocuparía 10 MB en el almacenamiento de archivos adjuntos lo cual supondría un total del 25.000 MB (25 GB).

Se puede evidenciar que el espacio de almacenamiento en Base de Datos tendrá su mayor impacto en la cantidad de evidencias que se carguen al sistema. Aun así, es un espacio bastante cómodo para almacenar en un solo sitio tres años de información que pueden llegar a ser consultadas en un pequeño instante de tiempo sin causar traumatismos en la Entidad por búsqueda de información histórica o por evidenciar acciones llevadas a cabo con años de anterioridad.

Tabla 18: Proyección espacio servidor Espacio en Espacio en Disco sin Espacio en Disco de disco total Hallazgos archivos adjuntos (MB) archivos adjuntos (MB) (MB) 25 0,67 250 251 75 2,01 750 752 225 6,03 2.250 2.256 675 18,09 6.750 6.768 2025 54,27 20.250 20.304 2500 67 25.000 25.067

Fuente: Autor del proyecto

Figura 36: Gráfica espacio en disco

Fuente: Autor del proyecto

11.3. BENEFICIOS

Con base en la estimación de costos realizada, la implementación del sistema tiene su mayor impacto en la disminución de tiempo que se dedica al proceso de plan de mejoramiento al interior de una Organización. Si bien, la cuantificación monetaria de ese tiempo ahorrado no implica la disminución de honorarios al equipo auditor y a los líderes de proceso, el tiempo ahorrado ha de ser valioso para optimizar otro tipo de proceso y tareas al interior de los equipos.

Por otra parte, la eficiencia en la clasificación y custodia de la información es otro factor muy importante a tener en cuenta, ya que al consolidarse en un solo lugar y contar con una base de conocimiento sólida de la gestión de planes de mejoramiento, repercutirá positivamente en la formulación y logros de objetivos institucionales.

En última instancia, se minimiza considerablemente el riesgo que conlleva el incumplimiento en la ejecución de planes de mejoramiento formulados por los entes de control, cuyas sanciones están establecidas en la Ley 42 de 1.993. 62

62 Ley 42 de 1.993 “Sobre la organización del sistema de control fiscal interno y los organismos que lo ejercen”.

12. CONSOLIDACIÓN DE PLAN DE MEJORAMIENTO.

Una vez consultadas todas las auditorías realizadas por la Contraloría de Bogotá en la vigencia 2014, por medio de la página web de dicha Entidad, se optó por incluir en el Aplicativo, a modo de prueba, la evaluación de un plan de mejoramiento de una Entidad del sector salud, ya que este es al que más se le realizó hallazgos en esa vigencia.

Para dicha tarea tomamos la Auditoria Regular de 2014 realizada al Hospital de Bosa63 y la Auditoría especial de la misma vigencia realizada al Hospital El Tunal64.

Para la Auditoría del Hospital El Tunal, se ingresaron al aplicativo un total de 7 hallazgos, los cuales aparecen referenciados en el Anexo 1 de dicha Auditoría. Tabla 19: Cantidad de Hallazgos Hospital El Tunal Auditoría Especial 2014

Tabla 19: Cantidad de Hallazgos Hospital El Tunal Auditoría Especial 2014

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernament al/Salud/PAD_2014/Especial/AGEIME_HOSPITAL_ELTUNAL_CONTRATACION.pdf

En el Anexo D “Seguimiento al Plan de Mejoramiento” del informe de Auditoría Regular de 2014 al Hospital de Bosa 63, se evidencia seguimiento al plan de mejoramiento vigente de dicho Sujeto de Control, el cual se muestra a continuación:

63 http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2 014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

64 http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2 014/Especial/AGEIME_HOSPITAL_ELTUNAL_CONTRATACION.pdf

Tabla 20: Seguimiento plan de mejoramiento Hospital De Bosa

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

Tabla 21: Seguimiento plan de mejoramiento Hospital De Bosa

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

Tabla 22: Seguimiento plan de mejoramiento Hospital De Bosa

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

Tabla 23: Seguimiento plan de mejoramiento Hospital De Bosa

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

100

Tabla 24: Seguimiento plan de mejoramiento Hospital De Bosa

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

101

Tabla 25: Seguimiento plan de mejoramiento Hospital De Bosa

Fuente: http://www.contraloriabogota.gov.co/intranet/contenido/informes/AuditoriaGubernamental/Salud/PAD_2014/Regular/AGEIMR_HOSPITAL_BOSA.pdf

102

13. INGRESO AL APLICATIVO EL PLAN DE MEJORAMIENTO COMPILADO.

Teniendo en cuenta los dos insumos descritos en el 12, un plan de mejoramiento cerrado y un plan de mejoramiento para formular, se crearon dos auditorías en el sistema y en cada uno se ingresaron lo hallazgos respectivos a fin de probar al funcionalidad de la aplicación y la agilidad del proceso.

Figura 37: Auditorías creadas en el Aplicativo.