IDRD · Web viewSe recomienda revisar y ajustar el procedimiento integrando al mismo la actividad...

71
INSTITUTO DISTRITAL DE RECREACION Y DEPORTE – IDRD INFORME FINAL DE AUDITORIA GESTIÓN DE SISTEMAS DE INFORMACIÓN Y DESARROLLO DE SOFTWARE FASE III OFICINA DE CONTROL INTERNO Período Auditado CONTROL EVALUACIÓN Y SEGUIMIENTO V2

Transcript of IDRD · Web viewSe recomienda revisar y ajustar el procedimiento integrando al mismo la actividad...

INSTITUTO DISTRITAL DE RECREACION Y DEPORTE – IDRD

INFORME FINAL DE AUDITORIA

GESTIÓN DE SISTEMAS DE INFORMACIÓN Y DESARROLLO DE SOFTWARE FASE III

OFICINA DE CONTROL INTERNO

Período Auditado

1 de enero de 2020 - 30 de agosto de 2020

DICIEMBRE DE 2020

TABLA DE CONTENIDO

3PRESENTACION

41. GENERALIDADES

41.1. OBJETIVO GENERAL

41.2. OBJETIVOS ESPECÍFICOS

41.3. CRITERIOS DE AUDITORIA

71.4. ALCANCE DE LA AUDITORIA

81.5. LIMITACIONES DEL PROCESO AUDITOR

82. INFORME DETALLADO DE AUDITORIA

82.1. Objetivo 1

82.1.1 Resultados de la Prueba 1 y Análisis

182.1.2 Conclusiones

192.1.3 Aspectos logrados

192.1.4 Fortalezas.

192.1.5 Oportunidades de mejora.

202.1.6 Hallazgos

222.2. Objetivo 2

222.2.1 Resultados de la Prueba 2 y Análisis

382.2.2 Conclusiones

392.2.3 Aspectos Logrados

392.2.4 Fortalezas

392.2.5 Oportunidades de mejora

402.2.6 Resultados de la Prueba 3 y Análisis

452.2.7 Conclusiones

452.2.8 Oportunidades de Mejora

463. Conclusiones Generales

PRESENTACION

La Oficina de Control Interno en cumplimiento de su rol de “Evaluación y Seguimiento” debe desarrollar sus actividades de evaluación de manera planeada, documentada, organizada, y sistemática, en el marco del Sistema de Control Interno.

Es importante resaltar que este rol debe desarrollarse de manera objetiva e independiente, pues su propósito es realizar la evaluación y emitir un concepto acerca del funcionamiento del Sistema de Control Interno, de la gestión desarrollada y de los resultados alcanzados por el IDRD; que permita generar recomendaciones y sugerencias que contribuyan al fortalecimiento de su gestión y desempeño.

En virtud de lo anterior y dando cumplimiento al Plan Anual de Auditoría del año 2020, la Oficina de Control Interno desarrolló Auditoría al proceso de Gestión de Tecnología de la Información y las Comunicaciones - Fase III Gestión de Sistemas de Información y Desarrollo de Software, para lo cual se contó con el apoyo del líder de la Subdirección Administrativa y Financiera como por el Coordinador del Área de Sistemas y su equipo de trabajo, quienes atendieron los requerimientos de información formulados por el equipo auditor.

El presente informe contiene los resultados, incluyendo:

1. Los aspectos satisfactorios en relación con los criterios de auditoría definidos y/o aspectos positivos que se resaltan para que sean mantenidos.

2. Las oportunidades de mejora identificadas cuya implementación contribuiría a optimizar la gestión y/o el desempeño.

3. Los hallazgos correspondientes a aquellas situaciones que se alejaron del deber ser considerado en los criterios de auditoría.

1. GENERALIDADES

1.1. OBJETIVO GENERAL

Evaluar la Gestión de Sistemas de Información y Desarrollo de Software para contribuir con la eficiencia en la gestión de la información de los procesos que soportan.

1.2. OBJETIVOS ESPECÍFICOS

1. Evaluar si los mantenimientos evolutivos, correctivos o adaptativos al software del IDRD cumplen con los requerimientos establecidos por los usuarios de acuerdo con la muestra seleccionada.

2. Evaluar la implementación de los lineamientos del Dominio de Sistemas de Información del Marco de Referencia de Arquitectura TI en la Gestión de Sistemas de Información y Desarrollo de Software.

1.3. CRITERIOS DE AUDITORIA

1. De acuerdo con lo establecido en el procedimiento “GESTIONAR EL DESARROLLO Y/O ACTUALIZACION DE SOFTWARE” Versión 1 del 2 de noviembre de 2017 se tiene la obligación de cumplir las siguientes actividades:

· El responsable de área debe enviar la solicitud de desarrollo y/o actualización del software o formulario. Debe diligenciar el Formato.

· El Profesional Universitario / Especializado / Técnico debe revisar la solicitud y concertar reunión con el usuario. Igualmente debe determinar la viabilidad técnica. Lo anterior dejando constancia en Acta.

· El Profesional Universitario / Especializado/ Técnico debe realizar el levantamiento de requerimientos, para lo cual debe utilizar el formato de Levantamiento de Requerimientos.

· El Profesional Universitario / Especializado / Técnico debe proyectar el cronograma de trabajo.

· El Profesional Universitario / Especializado Técnico debe realizar el desarrollo y validarlo en interacciones dejando constancia en Acta

· El Profesional Universitario /especializado/Técnico debe dejar soporte de la aprobación del desarrollo y/o actualización del software por parte del solicitante mediante acta y las observaciones en el formato de solicitud

· El Profesional Universitario / Especializado / Técnico debe realizar la documentación y/o actualización del código fuente y de la demás documentación requerida y remitir al responsable del área solicitante.

· El responsable del área debe realizar la aprobación de los manuales y de la demás documentación relacionada.

· El profesional designado por el área debe realizar la capacitación del software desarrollado.

2. De acuerdo con lo establecido en la Política de Gobierno Digital, la cual es parte del Modelo Integral de Planeación y Gestión las entidades públicas deben implementar los habilitadores transversales de dicha Política. Dentro de los tres habilitadores se define el habilitador Arquitectura dentro del cual se define el Modelo de Gestión y Gobierno de TI y este último define los lineamientos del Dominio Sistemas de Información. Por lo anterior el IDRD debe implementar los siguientes lineamientos:

· MGGTI.LI.SI.01 - Metodología para el desarrollo de sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe definir una metodología formal para el desarrollo y mantenimiento de software, que oriente los proyectos de construcción o evolución de los sistemas de información que se desarrollen a la medida, ya sea internamente o a través de terceros.

· MGGTI.LI.SI.02 - Derechos patrimoniales sobre los sistemas de información: Cuando se suscriban contratos con terceras partes bajo la figura de "obra creada por encargo" o similar, cuyo alcance incluya el desarrollo de elementos de software, la entidad debe incluir en dichos contratos, la obligación de transferir a la institución los derechos patrimoniales sobre los productos desarrollados.

· MGGTI.LI.SI.03 - Guía de estilo y usabilidad: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe definir o adoptar una guía de estilo y usabilidad para la institución. Esta guía debe estar particularizada de acuerdo con la caracterización de usuarios y según el canal utilizado por los sistemas de información y, así mismo, debe estar alineada con los principios de usabilidad definidos por el Estado colombiano, asegurando la aplicación de la guía en todos sus sistemas de información. Para los componentes de software, que sean propiedad de terceros, se debe realizar su personalización hasta donde sea posible de manera que se pueda brindar una adecuada experiencia de usuario.

· MGGTI.LI.SI.04 - Ambientes independientes en el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe identificar y mantener la independencia de los ambientes requeridos durante el ciclo de vida de los sistemas de información, ya sea directamente o través de un tercero. Ejemplos de ambientes son: desarrollo, pruebas, capacitación y producción.

· MGGTI.LI.SI.05 – Análisis de requerimientos de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe incorporar un proceso formal de análisis y gestión de requerimientos de software en el ciclo de vida de los sistemas de información de manera que se garantice su trazabilidad y cumplimiento.

· MGGTI.LI.SI.06 - Integración continua durante el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe garantizar que, dentro del proceso de desarrollo de sistemas de información, se ejecuten estrategias de integración continua sobre los nuevos desarrollos de sistemas de información.

· MGGTI.LI.SI.07 - Entrega continua durante el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe garantizar que, dentro del proceso de desarrollo de sistemas de información, se ejecuten estrategias de entrega continua sobre los nuevos desarrollos de sistemas de información, posterior a la implementación de estrategias de integración continua.

· MGGTI.LI.SI.08 - Despliegue continuo durante el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe garantizar que, dentro del proceso de desarrollo de sistemas de información, se ejecuten estrategias de despliegue continuo sobre los nuevos desarrollos de sistemas de información, posterior a la implementación de estrategias de entrega continua.

· MGGTI.LI.SI.09 - Plan de pruebas durante el ciclo de vida de los sistemas de información: En el proceso de desarrollo y evolución de un sistema de información, la dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe contar con un plan de pruebas que cubra lo funcional y lo no funcional. La aceptación de cada una de las etapas de este plan debe estar vinculada a la transición del sistema de información a través de los diferentes ambientes.

· MGGTI.LI.SI.10 - Manual del usuario, técnico y de operación de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe asegurar que todos sus sistemas de información cuenten con la documentación técnica y funcional debidamente actualizada.

· MGGTI.LI.SI.11 - Estrategia de mantenimiento de los sistemas de información: Para el mantenimiento de los sistemas de información, la dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe hacer un análisis de impacto ante cualquier solicitud de cambio en alguno de sus componentes, con el fin de determinar la viabilidad del cambio y las acciones a seguir.

· MGGTI.LI.SI.12 - Servicios de mantenimiento de sistemas de información con terceras partes: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe establecer criterios de aceptación y definir Acuerdos de Nivel de Servicio (ANS) cuando se tenga contratado con terceros el mantenimiento de los sistemas de información. Los ANS se deben aplicar en las etapas del ciclo de vida de los sistemas de Información que así lo requieran y se debe velar por la continuidad del servicio.

· MGGTI.LI.SI.13 - Plan de calidad de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe implementar un plan de aseguramiento de la calidad durante el ciclo de vida de los sistemas de información.

· MGGTI.LI.SI.14 - Requerimientos no funcionales y atributos calidad de los sistemas de información: En la construcción o modificación de los Sistemas de Información, la Dirección de Tecnologías y Sistemas de la Información o quien haga sus veces, debe identificar los requerimientos no funcionales aplicables asociados a los atributos de calidad, garantizando su cumplimiento una vez entre en operación el sistema.

· MGGTI.LI.SI.15 - Accesibilidad: Los sistemas de información que estén disponibles para el acceso a la ciudadanía o aquellos que de acuerdo con la caracterización de usuarios lo requieran, deben cumplir con las funcionalidades de accesibilidad que indica la política de Gobierno Digital.

1.4. ALCANCE DE LA AUDITORIA

Evaluar el procedimiento “Gestionar el Desarrollo y/o actualización del Software.", la implementación de los lineamientos del Dominio Sistemas de Información del Marco de Referencia de Arquitectura TI, y la aplicación de controles del Manual de Políticas de Seguridad Digital y de la Información relacionados con Adquisición, Desarrollo y Mantenimiento de Sistemas, en el periodo comprendido del 01 de enero de 2020 al 31 de agosto de 2020.

1.5. LIMITACIONES DEL PROCESO AUDITOR

Durante el desarrollo del proceso auditor se presentó limitación por la falta de oportunidad de la entrega de la información de los registros del procedimiento “Gestionar el Desarrollo y/o Actualización de Software” cuya responsabilidad es del Área de Sistemas de la Subdirección Administrativa y Financiera.

2. INFORME DETALLADO DE AUDITORIA

2.1. Objetivo 1

Evaluar si los mantenimientos evolutivos, correctivos o adaptativos al software del IDRD cumplen con los requerimientos establecidos por los usuarios de acuerdo con la muestra seleccionada.

2.1.1 Resultados de la Prueba 1 y Análisis

Mediante correo electrónico del 28 septiembre del 2020 se solicitó al Área de Sistemas de la Subdirección Administrativa y Financiera - SAF, información de la gestión de desarrollo de software para los diferentes sistemas de información del IDRD, realizadas durante la vigencia 2020 con corte al 31 de agosto, obteniendo respuesta por este mismo medio.

Con la información suministrada por el Área de Sistemas, se estableció segmentar la muestra para los sistemas de información SIM y ORFEO teniendo en cuenta que sobre dichos aplicativos el IDRD realiza actividades de actualización y/o desarrollo de software, adicionalmente se tuvo en cuenta que el SIM soporta las áreas misionales y el ORFEO soporta transversalmente a los procesos de la entidad.

Se identificó que durante el periodo evaluado para los sistemas de información SIM y ORFEO se realizaron 31 y 7 solicitudes respectivamente, las cuales se relacionan en las siguientes tablas:

Tabla No. 1 Solicitudes de actualización y/o desarrollo de software para SIM

NUM

NUMERO DE SOLICITUD GLPI

DESCRIPCION SOLICITUD

1

69742

Certificados Formulario Experiencias Significativas Y Pedagógicas De Las Escuelas De Formación

2

70137

Formulario De Inscripción Pedalea En Tu Parque

3

70206

Formulario Concurso Código De Integridad Y Buen Gobierno

4

72038

Aplicativo Reactivación Económica Sector Recreación Y Deportes - Fase I

5

63041

Información Para Publicación Caminata Pagina Web Domingo 12 De Enero 2020

6

63233

Información Para Publicación De Caminata Pagina Web Sábado 18 Y Domingo 19 Enero 2020

7

63 323

Soporte - Torneos Deportivos Interbarrios 2020

8

63 419

Información Para Publicación Caminatas En Pagina Idrd

9

63 545

Información Para Publicación De Caminata Pagina Web Domingo 26 Enero 2020

10

63 697

Soporte Error En Ingreso A Formulario Encuesta A Usuarios Proyección Ciclovía 2020

11

64 117

Solicitud Link De Inscripción ALOHA CAMPISTA 2020

12

64 338

Información Link Publicación 09 De Febrero 2020 Y El Consentimiento Informado De Alhoja Campista

13

66 179

Formulario

14

67 113

Solicitud Urgente Formato De Capacitación Que Ya Está Hecho Para Certificación

15

68 133

Solicitud Elaboración Formulario De Inscripción Para Curso

16

68 144

Formulario día del Desafío

17

69 910

Fwd: Formato de Solicitud de Desarrollo de Formulario de Inscripción Curso F.A.D.

18

70 075

Solicitud de mejora Modulo rendimiento - SIM

19

72 042

Solicitud Desarrollo Aplicativo Inscripción FESTIVAL ESCOLAR - DEPORTE ESCOLAR - STRD

20

72 336

Solicitud Desarrollo Formulario Inscripción JUEGOS INTERCOLEGIADOS DISTRITAL VIRTUAL 2020 - DEPORTE ESCOLAR - STRD

21

72 462

Fwd: Nuevo Formulario Para Sistemas

22

72 537

Formulario De Inscripción Variables Seminario De Actividad Física Y Salud Mental

23

72 731

Solicitud Desarrollo Formulario Inscripción TORNEOS DE RETOS VIRTUALES EN HABILIDADES DEPORTIVAS

24

72 735

Formulario De Inscripción Página Web Presencialidad Recreo Vía

25

72 811

Solicitud Link De Inscripción Piloto Caminatas

26

72 976

Solicitud Formulario

27

73 274

Re: Solicitud Formulario Google Drive

28

73 344

Fwd: Solicitud Formulario De Inscripción

29

73 586

Re: Formulario De Reactivación

30

73 616

Formulario Registro Asistencia A Capacitación

31

73 696

Informe Formulario Reactivación

De las treinta y una solicitudes (31) identificadas en el periodo evaluado se observa que 30 corresponden a mantenimientos evolutivos y una corresponde a mantenimiento correctivo; es decir el 98% corresponden a nuevas necesidades de los usuarios.

Tabla No. 2 Solicitudes de actualización y/o desarrollo de software para ORFEO

NUM

ITEM

NUMERO DE CASO GLPI

DESCRIPCION

1

17

64624

Descripción puntual de lo que quiere desarrollar: Se requiere hacer el ajuste en la bandeja de Informados para mantener el orden cronológico cuando se cambia de página.

2

18

64307

Descripción puntual de lo que quiere desarrollar: Se requiere quitar la restricción de fecha en la funcionalidad de Generar planilla de cambio de custodia, para que el sistema permita seleccionar mediante el calendario los radicados que hayan sido generados y no tengan solicitud de cambio de custodia de cualquier día.

3

19

65774

Descripción puntual de lo que quiere desarrollar: Se requiere agregar la columna "Destinatario" en la vista de la pestaña "Documentos", debido a que cuando se hacen copias no se puede identificar a que destinatario pertenece cada una.

4

20

N/A

Generar el modiulo en el sistema que permita generar firma mecanica

5

21

N/A

Descripción puntual de lo que quiere desarrollar: Se requiere hacer un desarrollo que muestre a través de un semaforo los días de vencimiento de los radicados de acuerdo a los tiempos configurados en sus tipos documentales.

6

22

N/A

Descripción general: Se debe realziar la conversión de todo archivo a archivo .pdf al momento de realziar el marcado como impreso.

7

23

N/A

Descripción puntual de lo que quiere desarrollar: Se requiere reubicar la funcionalidad de paz y salvo en la sección de permisos administrativos

Las siete solicitudes (7) identificadas en el periodo evaluado se observa que todas corresponden a mantenimientos evolutivos; es decir el 100% corresponden a nuevas necesidades de los usuarios.

Se procedió a revisar y analizar cada una de las respuestas y evidencias suministradas y presentadas, con el fin de verificar el cumplimiento de los lineamientos, actividades y el diligenciamiento de los registros establecidos en el procedimiento “GESTIONAR EL DESARROLLO Y/O ACTUALIZACION DE SOFTWARE”.

En virtud del análisis de la información suministrada y con el fin de despejar inquietudes y solicitar aclaración de algunos temas sobre el particular, se realizaron mesas de trabajo con el Área de Sistemas los días 16 de septiembre y 7, 8,13,15, 29 y 30 de octubre-2020, resultados registrados en las Actas Internas OCI-250-A, OCI-273-A, OCI-274-A, OCI-275-A, OCI-277-A, OCI-317-A y OCI-318, la cuales fueron socializadas a los participantes.

Realizado el análisis de la información suministrada por SAF se presenta el siguiente resultado:

· Lineamiento Repositorio Digital

Se observó, que de acuerdo con lo establecido en el lineamiento del numeral 7 del procedimiento que indica que “la documentación soporte del procedimiento reposará en el archivo digital del grupo de desarrollo del área de sistemas”, no se cuenta con el archivo digital que hace referencia el lineamiento.

El Área de Sistemas Informa que antes de inicio de la emergencia sanitaria se gestionaban los registros en formato físico y durante la emergencia se gestionan en formato digital, pero no se cuenta con un repositorio centralizado para la gestión de los registros del procedimiento. Adicionalmente se observa que los registros en formato digital durante la vigencia 2020 son almacenados en los equipos o Drive asignados a los desarrolladores y los formatos físicos se encuentra en Área de Sistemas.

De otra parte, el Área de Sistemas informa que inició desde el pasado mes de abril una prueba piloto para gestionar los registros del procedimiento apoyados en la herramienta de software GLPI y espera definir si dicha herramienta se adecua para la gestión del procedimiento y sus respectivos registros.

· Normativa

Se observa que en el numeral 5-Normativa del procedimiento no incluye las siguientes normas las cuales deben ser aplicadas para la gestión de los sistemas de información de la Entidad:

· Decreto 1008 Decreto 1008 del 14 de junio 2018 “Por el cual se establecen los lineamientos generales de la política de Gobierno Digital y se subroga el capítulo 1 del título 9 de la parte 2 del libro 2 del Decreto 1078 de 2015, Decreto Único Reglamentario del sector de Tecnologías de la Información y las Comunicaciones"".

· Resolución Número 003 (septiembre 11 de 2017) “Por la cual se adopta la Guía de sitios Web para las entidades del Distrito Capital y se dictan otras disposiciones.”, de la Alta Consejería de TIC

· Lineamientos de accesibilidad web para sitios institucionales, Alcaldía de Bogota- Secretaria General- Alta Consejería de TIC 2019.

Lo anterior evidencia desactualización de la normatividad y por lo tanto incrementa el riesgo de incumplimiento normativo.

· Aplicación del procedimiento para el Sistema de Información SIM

Para la aplicación de la prueba a las solicitudes del sistema de información SIM, el Área de Sistemas informa que los registros del procedimiento hasta antes de la emergencia sanitaria se llevaban en formato físico y que durante la emergencia sanitaria se han venido elaborando en formato electrónico. Lo anterior evidencia que no se cumplió con el lineamiento de gestionar la información en el archivo digital de dicha Área.

Por lo anterior y para poder verificar registros en físico, el Área de Sistemas procedió a digitalizar los documentos de solicitudes en la muestra seleccionada. A continuación, se describe el resultado de la verificación de la aplicación del procedimiento:

Requerimiento GLPI 63041

5

63041

INFORMACIÓN PARA PUBLICACIÓN CAMINATA PAGINA WEB DOMINGO 12 DE ENERO 2020

Para la solicitud relacionada con el ítem número 5 y registrada en el sistema GLPI con el número 63041, la cual corresponde a un mantenimiento evolutivo se observa los siguiente:

La solicitud se diligenció debidamente en formato físico y cuenta con las firmas del responsable de área de sistemas, del responsable del área solicitante, del usuario solicitante y del desarrollador.

El acta de reunión que indica el procedimiento en la actividad número 2 “Revisar la solicitud y concertar reunión con el usuario” no fue elaborada, por lo tanto, no hay evidencia de la ejecución de la actividad.

El formato “Levantamiento de Requerimientos” que indica el procedimiento en la actividad número 6 “Realizar el levantamiento de requerimientos” fue elaborado y diligenciado en su totalidad.

Las Actas de reunión que indica el procedimiento en la actividad número 9 “Validar el desarrollo” y número 12 “Aprobar el desarrollo y/o actualización de software” no fueron elaboradas, por lo tanto, no hay evidencia de la ejecución de la actividad.

El Área de sistemas informa que en la práctica se realizan pruebas internas a los productos de software dejando evidencia en el formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0, sin embargo, para la presente solicitud no se evidenció la elaboración de dichos formatos. Adicionalmente se observa que la actividad de pruebas internas y sus respectivos registros no están incluidas en el procedimiento.

Las situaciones descritas anteriormente, evidencian debilidades en el cumplimiento en la elaboración de los registros establecidos, falta de completitud en el diligenciamiento de algunos formatos y desactualización del procedimiento con respecto a actividades que se realizan en la práctica

Requerimiento GLPI 63323

7

63323

Soporte - torneos deportivos Interbarrios 2020

Para la solicitud relacionada con el número 7 y registrada en el sistema GLPI con el número 63323, la cual corresponde a un mantenimiento evolutivo se observa los siguiente:

La solicitud se diligenció debidamente en formato físico y cuenta con las firmas del responsable de área de sistemas, del área solicitante, del usuario solicitante y del desarrollador.

El acta de reunión que indica el procedimiento en la actividad número 2 “Revisar la solicitud y concertar reunión con el usuario” no fue elaborada, por lo tanto, no hay evidencia de la ejecución de la actividad.

El formato “Levantamiento de Requerimientos” que indica el procedimiento en la actividad número 6 “Realizar el levantamiento de requerimientos” fue elaborado y diligenciado en su totalidad.

Las actas de reunión que indica el procedimiento, en la actividad número 9 “Validar el desarrollo” y número 12 “Aprobar el desarrollo y/o actualización de software”, no fueron elaboradas, por lo tanto, no hay evidencia de la ejecución de la actividad.

El Área de sistemas informa que en la práctica se realizan pruebas internas a los productos de software dejando evidencia en el formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0, sin embargo, para la presente solicitud no se evidenció la elaboración de dichos formatos. Adicionalmente se observa que la actividad de pruebas internas y sus respectivos registros no están incluidas en el procedimiento.

Las situaciones descritas anteriormente, evidencian debilidades en el cumplimiento en la elaboración de los registros establecidos, falta de completitud en el diligenciamiento de algunos formatos y desactualización del procedimiento con respecto a actividades que se realizan en la práctica

Requerimiento GLPI 72336

20

72336

Solicitud Desarrollo formulario inscripción JUEGOS INTERCOLEGIADOS DISTRITAL VIRTUAL 2020 - DEPORTE ESCOLAR – STRD

Para la solicitud relacionada con el número 20 y registrada en el sistema GLPI con el número 72336, la cual corresponde a un mantenimiento evolutivo se observa los siguiente:

La solicitud no se diligenció debidamente ya que no cuenta con las firmas del responsable de área de sistemas, del responsable del área solicitante, del usuario solicitante y del desarrollador.

El acta de reunión que indica el procedimiento en la actividad número 2, “Revisar la solicitud y concertar reunión con el usuario”, no fue elaborada, por lo tanto, no hay evidencia de la ejecución de la actividad.

El formato “Levantamiento de Requerimientos”, que indica el procedimiento en la actividad número 6 “Realizar el levantamiento de requerimientos”; no fue diligenciado en su totalidad, ya que no cuenta con los nombres y firmas del Usuario Funcional, del Desarrollador y la del Documentador

Las actas de reunión, que indica el procedimiento en la actividad número 9 “Validar el desarrollo” y número 12 “Aprobar el desarrollo y/o actualización de software”; no fueron elaboradas, por lo tanto, no hay evidencia de la ejecución de la actividad.

Se observa que en el Sistema de Gestión de Calidad se cuenta con el formato “Acta de entrega de Software”, aprobado el 25 de febrero de 2019; sin embargo, no se evidenció que dicho formato haya sido diligenciado. Adicionalmente en el procedimiento “Gestionar el desarrollo y/o actualización del Software” dicho formato no está descrito explícitamente como registro, lo anterior evidencia la desactualización del procedimiento.

El Área de sistemas informa que en la práctica se realizan pruebas internas a los productos de software dejando evidencia en el formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0, sin embargo, para la presente solicitud no se evidenció la elaboración de dichos formatos. Adicionalmente se observa que la actividad de pruebas internas y sus respectivos registros no están incluidas en el procedimiento.

Las situaciones descritas anteriormente, evidencian debilidades en el cumplimiento en la elaboración de los registros establecidos, falta de completitud en el diligenciamiento de algunos formatos y desactualización del procedimiento con respecto a actividades que se realizan en la práctica

· Aplicación del procedimiento para el Sistema de Información ORFEO:

Requerimiento GLPI 64624

17

64624

Descripción puntual de lo que quiere desarrollar: Se requiere hacer el ajuste en la bandeja de Informados para mantener el orden cronológico cuando se cambia de página.

Para la solicitud relacionada con el número 17 y registrado en el sistema GLPI con un numero 64624, la cual corresponde a un mantenimiento evolutivo se observa los siguiente:

Fue solicitada por la Subdirección administrativa y Financiera el 14 de mayo de 2020. Se verifica que la solicitud no se diligenció debidamente ya que no cuenta con las firmas del responsable de área de sistemas, del responsable del área solicitante, del usuario solicitante y del desarrollador.

Se evidencia que el acta de reunión que indica el procedimiento en la actividad número 2 “Revisar la solicitud y concertar reunión con el usuario” no fue elaborada, por lo tanto, no hay evidencia de la ejecución de la actividad.

Se evidencia que el formato “Levantamiento de Requerimientos” que indica el procedimiento en la actividad número 6 “Realizar el levantamiento de requerimientos” no fue diligenciado en su totalidad ya que no cuenta con los nombres y firmas del Usuario Funcional, del Desarrollador y la del Documentador.

Las actas de reunión que indica el procedimiento en la actividad número 9 “Validar el desarrollo” y número 12 “Aprobar el desarrollo y/o actualización de software” no fueron elaboradas, por lo tanto, no hay evidencia de la ejecución de la actividad.

El Área de sistemas informa que en la práctica se realizan pruebas internas a los productos de software dejando evidencia en el formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0, sin embargo, para la presente solicitud no se evidenció la elaboración de dichos formatos. Adicionalmente se observa que la actividad de pruebas internas y sus respectivos registros no están incluidas en el procedimiento.

Las situaciones descritas anteriormente, evidencian debilidades en el cumplimiento en la elaboración de los registros establecidos, falta de completitud en el diligenciamiento de algunos formatos y desactualización del procedimiento con respecto a actividades que se realizan en la práctica

Requerimiento 21 sin registro en GLPI

21

N/A

Descripción puntual de lo que quiere desarrollar: Se requiere hacer un desarrollo que muestre a través de un semaforo los días de vencimiento de los radicados de acuerdo a los tiempos configurados en sus tipos documentales.

Para la solicitud relacionada con el número 21 y no registrada en el Sistema GLPI y la cual corresponde a un mantenimiento evolutivo se observa los siguiente:

La solicitud se diligenció debidamente y cuenta con la firma del responsable de área de sistemas y del responsable del área solicitante, al igual que el usuario solicitante y del desarrollador.

EL acta de reunión que indica el procedimiento en la actividad número 2 “Revisar la solicitud y concertar reunión con el usuario”, no fue elaborada, por lo tanto, no hay evidencia de la ejecución de la actividad.

El formato “Levantamiento de Requerimientos” que indica el procedimiento en la actividad número 6 “Realizar el levantamiento de requerimientos” no fue diligenciado en su totalidad ya que no cuenta con los nombres y firmas del Usuario Funcional, del Desarrollador y la del Documentador.

Las Actas de reunión que indica el procedimiento en la actividad número 9 “Validar el desarrollo” y número 12 “Aprobar el desarrollo y/o actualización de software” no fueron elaboradas, por lo tanto, no hay evidencia de la ejecución de la actividad.

El Área de sistemas informa que en la práctica se realizan pruebas internas a los productos de software dejando evidencia en el formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0, sin embargo, para la presente solicitud no se evidenció la elaboración de dichos formatos. Adicionalmente se observa que la actividad de pruebas internas y sus respectivos registros no están incluidas en el procedimiento.

Las situaciones descritas anteriormente, evidencian debilidades en el cumplimiento en la elaboración de los registros establecidos, falta de completitud en el diligenciamiento de algunos formatos y desactualización del procedimiento con respecto a actividades que se realizan en la práctica

Requerimiento 20 sin registro en GLPI

20

N/A

Generar el módulo en el sistema que permita generar firma mecanica

Para la solicitud relacionada con el número 20 y no registrada en el Sistema GLPI y la cual corresponde a un mantenimiento evolutivo se observa los siguiente:

El formato “Solicitud Desarrollo y/o Actualización de Software” no se diligenció debidamente, por lo anterior, no es posible evidenciar la descripción de la necesidad, el área que la solicitó y la autorización correspondiente. De acuerdo con el formato de “levantamiento de requerimientos el cronograma indica que la actividad inició el primero de mayo y terminó el 19 de mayo del 2020.

El acta de reunión que indica el procedimiento en la actividad número 2 “Revisar la solicitud y concertar reunión con el usuario”; no fue elaborada, por lo tanto, no hay evidencia de la ejecución de la actividad.

El formato “Levantamiento de Requerimientos” que indica el procedimiento en la actividad número 6 “Realizar el levantamiento de requerimientos” no fue diligenciado en su totalidad ya que no cuenta con los nombres y firmas del Usuario Funcional, del Desarrollador y la del Documentador.

Las Actas de reunión que indica el procedimiento en la actividad número 9 “Validar el desarrollo” y número 12 “Aprobar el desarrollo y/o actualización de software” no fueron elaboradas, por lo tanto, no hay evidencia de la ejecución de la actividad.

El Área de sistemas informa que en la práctica se realizan pruebas internas a los productos de software dejando evidencia en el formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0, sin embargo, para la presente solicitud no se evidenció la elaboración de dichos formatos. Adicionalmente se observa que la actividad de pruebas internas y sus respectivos registros no están incluidas en el procedimiento.

Las situaciones descritas anteriormente, evidencian debilidades en el cumplimiento en la elaboración de los registros establecidos, falta de completitud en el diligenciamiento de algunos formatos y desactualización del procedimiento con respecto a actividades que se realizan en la práctica

· Aplicación del procedimiento para el Sistema de Información ISolución

Se observa que las actualizaciones del sistema de información ISolución son gestionadas por la Oficina Asesora de Planeación directamente con el proveedor del producto. El Área de Sistemas informó que esta situación se debe a que el proyecto de implementación del sistema en su momento fue liderada y soportada presupuestalmente por la Oficina Asesora de Planeación y a la fecha el Área de Sistemas gestiona únicamente el soporte de la infraestructura del sistema.

Lo anterior evidencia que para este producto el Área de Sistemas no ejerce gobierno y control para las actualizaciones del software y por lo tanto no se aplica el procedimiento “Gestionar el Desarrollo y/o Actualización de Software”, desatendiendo la función 19 del Artículo 11 de la resolución 6 de 2017 emitida por la Junta Directiva del IDRD que estable la funciones a cargo de la SAF, asignándole la responsabilidad de “Dirigir la implementación, administración y gestión de los recursos tecnológicos e informáticos del Instituto”.

Por otra parte, en el numeral 7-Lineamientos o políticas de operación del procedimiento “Gestionar Desarrollo y/o actualización del Software”, se establece que “En caso de que el área u oficina que administra el software sea apoyada por el área de sistemas, la coordinación y responsabilidad de dichos ajustes estarán a cargo única y exclusivamente del área que administra el software”, dicho lineamiento genera incertidumbre respecto de cuáles son los software a los cuales el área de Sistemas aplica y a cuales no aplica el procedimiento para los desarrollos y/o actualización de los mismos. Adicionalmente deja abierta la posibilidad que otras áreas asuman actividades propias del proceso de Gestión de Tecnologías de la Información y las Comunicaciones.

2.1.2 Conclusiones

De acuerdo con los resultados de la verificación realizada se concluye:

1. No se ha implementado el archivo digital o repositorio único establecido en los lineamentos o políticas de operación del procedimiento, lo cual genera ineficiencias en la gestión documental del mismo.

2. La normatividad que orienta el procedimiento se encuentra desactualizada con respecto a la Política de Gobierno Digital y normas Distritales relacionadas con la Guía y accesibilidad de los sitios web, lo anterior incrementa la probabilidad del riesgo de incumplimiento normativo.

3. El 98% de las solicitudes de Desarrollo y/o actualización del Software identificadas durante el periodo del 1 de enero al 31 de agosto de 2020, corresponden a solicitudes de mantenimiento evolutivo. Lo anterior evidencia que las solicitudes de los usuarios principalmente están enfocadas a atender nuevas necesidades.

4. Se observó que ninguna de las tres (3) solicitudes de desarrollo de software, revisadas para el sistema ORFEO, cumplen al 100% con los registros establecidos en el procedimiento. Lo anterior evidencia debilidades en el conocimiento, la aplicación y control del mismo.

5. Se observó que ninguna de las cuatro (4) solicitudes de desarrollo de software, revisadas para el sistema SIM, cumplen al 100% con los registros establecidos en el procedimiento. Lo anterior evidencia debilidades en el conocimiento, la aplicación y control del mismo.

6. Las actividades establecidas en el procedimiento “Gestionar el Desarrollo y Actualización de Software” versión 1 del 2 de noviembre de 2017, no se cumplen estrictamente y de forma estándar, tanto en el grupo que soporta el sistema SIM como en el grupo que soporta el Sistema ORFEO.

7. El formato “Acta de entrega de software”, el cual hace parte del Sistema de Gestión no está especificado explícitamente en el procedimiento como registro de alguna de las actividades, por lo anterior su utilización no está controlada a pesar de ser un elemento de control fundamental para la trazabilidad del cumplimiento de los requerimientos de los usuarios. Adicionalmente el Área de Sistemas informa que tiene establecidos otros elementos de control como el formato para describir de forma detallada el requerimiento y el formato de pruebas, sin embargo, dichos formatos no se encuentran formalizados en el procedimiento “Gestionar el Desarrollo y/o Actualización de Software”.

8. El gobierno y control de las actualizaciones del software para el sistema de información ISolución no está en cabeza del Área de Sistemas del IDRD. Lo anterior significa que no se tiene un gobierno centralizado de todos los sistemas de información.

2.1.3 Aspectos logrados

En relación con este objetivo no se identificaron fortaleza que generaran valor agregado al Proceso.

2.1.4 Fortalezas.

El área de sistemas utiliza herramienta automatizada para la gestión del procedimiento de desarrollo de software como GITLAB para la gestión de versiones del código fuente, la cual permite realizar actividades del ciclo de vida de los sistemas de información de forma más eficiente.

2.1.5 Oportunidades de mejora.

OM 1: Se recomienda culminar y evaluar los resultados de la prueba piloto del uso del sistema GLPI para gestionar el procedimiento” GESTIONAR EL DESARROLLO Y/O ACTUALIZACION DEL SOFTWARE”, y definir si dicha herramienta cumple con las necesidades del procedimiento. En caso de ser conforme la prueba piloto, actualizar y formalizar el procedimiento.

OM 2: Se recomienda ajustar el procedimiento incluyendo actividades de control que permitan asegurar el cumplimiento de la elaboración de todos registros establecidos en las actividades correspondientes.

OM3: Se recomienda revisar y ajustar el procedimiento, integrando al mismo las actividades de pruebas internas y pruebas de aceptación y el uso del formato “FORMATO PRUEBAS FUNCIONALES DE SOFTWARE” versión 1.0. Lo anterior debido a que el procedimiento no las tiene señaladas explícitamente y considerando que estas son fundamentales para asegurar el cumplimiento de los requerimientos de los usuarios y la calidad del producto de software.

OM4: Se recomienda revisar y ajustar el procedimiento integrando al mismo la actividad de pruebas de seguridad apoyados en herramientas automatizas (Owasp Zap o similares), la cual el Área de Sistemas informa que viene aplicando.

OM5: Se recomienda establecer registro de evidencia formal para las actividades número 14 “Aprobar los manuales y demás documentación” y de la actividad 15 “Realizar la capacitación del software desarrollado”.

OM7: Se recomienda centralizar la gestión de las actualizaciones del software Isolución en el Área de Sistemas para asegurar la aplicación de los lineamientos y actividades establecidas en el procedimiento “Gestionar el Desarrollo y/o actualización del software” y demás elementos relacionados del proceso.

OM8: Se recomienda especificar de forma clara el lineamiento establecido en el numeral 7-Lineamientos o Políticas de operación, teniendo en cuenta que no se especifica de forma concreta cuales son los sistemas de información que no apoya el Área de Sistemas.

OM9: Se recomienda actualizar la normatividad que orienta el procedimiento, la cual se encuentra desactualizada con respecto a la Política de Gobierno Digital y normas Distritales relacionadas con las guías y accesibilidad de los sitios web.

OM10: Establecer las actividades necesarias para asegurar la transferencia de conocimiento a la Entidad en materia de construcción y mantenimiento de los desarrollos de software realizados por los contratistas del equipo de trabajo de SIM y ORFEO.

2.1.6 Hallazgos

Hallazgo 1. Archivo Digital

Se observó que de acuerdo con lo establecido en el lineamiento del numeral 7 del procedimiento que indica “la documentación soporte del procedimiento reposará en el archivo digital del grupo de desarrollo del área de sistemas”, no se cuenta con el archivo digital al que hace referencia el lineamiento.

Lo anterior obedece a que antes de la emergencia sanitaria se gestionaban los registros del SIM y ORFEO en formato físico y durante la emergencia sanitaria (COVID-19) se vienen gestionando en formato digital, pero no se cuenta con un almacenamiento digital centralizado. Dichos registros actualmente son almacenados en los equipos personales o Drive asignados a los desarrolladores.

En consecuencia, la situación presentada ha generado dispersión de los registros del procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACION DE SOFTWARE y debilidades en el control de la completitud de los mismos para cada una de las solicitudes de desarrollo de software.

Así las cosas, se incrementa el riesgo de pérdida de la información propia de la gestión de software, la cual es necesaria para mantener una adecuada calidad de los productos SIM y ORFEO.

Hallazgo No. 2: Registros del Procedimiento Gestionar Desarrollo y/o Actualización del Software

Se carece de evidencias de la actividad de aprobación por parte de los usuarios del producto solicitado, considerando el incumplimiento en la elaboración de los registros estipulados en la actividad 12 “Aprobar el desarrollo y/o actualización de software”, de lo cual debe quedar soporte mediante Acta de Reunión. Así mismo se incumplió la elaboración de la Acta de la actividad número 9 “Validar el desarrollo”, lo cual debe tener en cuenta las observaciones del usuario final.

Igualmente, se incumplió con el diligenciamiento de los registros establecidos en el procedimiento para los sistemas de información SIM Y ORFEO, debido a que se diligenciaron parcialmente los formatos “Solicitud Desarrollo y/o Actualización de Software y/o Formulario” y el formato “Levantamiento de Requerimientos”, del procedimiento Gestionar el Desarrollo y/o Actualización del Software.

Lo anterior obedeció a falta de controles para la verificación del cumplimiento estricto de las actividades del procedimiento y la elaboración de los registros correspondientes.

En consecuencia, la falta de registros de la aprobación por parte de los usuarios de los productos solicitados de las actividades de validar y aprobar, el diligenciamiento parcial de las solicitudes de desarrollo y el formato de levantamiento de requerimientos deja incertidumbre en cuanto a la satisfacción de las necesidades de los usuarios.

Así las cosas, se incrementa la probabilidad del riesgo de desarrollar y poner al servicio software que no ha sido validado y que no cumpla con todas las actividades establecidas en el procedimiento que aseguran la calidad del proceso y de los productos de software.

Adicionalmente se incrementa la probabilidad del riesgo de desarrollar software que no cumpla con los requerimientos de los usuarios, y por lo tanto no permita cumplir sus necesidades de gestión de la información.

Hallazgo No. 3 Gestión de actualizaciones al software Isolución

Se observa que las actualizaciones del sistema de información ISolución son gestionadas por la Oficina Asesora de Planeación directamente con el proveedor del producto. Lo anterior evidencia que para este producto el Área de Sistemas no ejerce gobierno y control para las actualizaciones del software y por lo tanto no se aplica el procedimiento “Gestionar el Desarrollo y/o Actualización de Software” desatendiendo la función 19 del Artículo 11 de la resolución 6 de 2017 emitida por la Junta Directiva del IDRD que estable la funciones a cargo de la SAF, asignándole la responsabilidad de “Dirigir la implementación, administración y gestión de los recursos tecnológicos e informáticos del Instituto.

Lo anterior obedece a que el proyecto de implementación del sistema ISolución en su momento fue liderada y soportada presupuestalmente por la Oficina Asesora de Planeación y a la fecha el Área de Sistemas gestiona únicamente el soporte de la infraestructura del sistema.

En consecuencia, no se aplican los procedimientos establecidos por el proceso de Gestión de Tecnologías de la Información y las Comunicaciones para la actualización del software generando falta de unidad de criterio en la gestión de los sistemas de información

Así las cosas, se dispersan las funciones del Área de Sistemas, generando posibles ineficiencias y desarticulación en la gestión del soporte y mantenimiento del sistema ante incidentes de seguridad de la información que afecten la disponibilidad, integridad y confidencialidad de la información.

Respuesta Subdirección Administrativa y Financiera

Respuesta: Si bien es cierto que el área de sistemas no tiene la gestión administrativa del funcionamiento de Isolucion no se puede afirmar que no se cumplan con los procedimientos establecidos dentro del proceso de gestión de TIC, el área informó que la documentación de Isolucion es administrada y gestionada por la oficina asesora de planeación, los mantenimientos y las indisponibilidades que se puedan generar se programan de manera conjunta con el área de sistemas, el proveedor y la oficina asesora de planeación, siempre se han realizado reuniones para la planeación y ejecución, para el periodo revisado por la auditoría fase 3, solo se ha presentado una actualización, de la cual cuenta la documentación la oficina asesora de planeación, por tal razón se desconoce por parte del área de sistemas el origen de este hallazgo.

Análisis de la respuesta

La Política de Gobierno Digital establece el Modelo de Gestión y Gobierno de TI cuyo objetivo es brindar a las Entidades Públicas a través del Líder Estratégico de TI (director o Jefe de Tecnologías de la Información y las Comunicaciones), o quien haga sus veces, una orientación para gestionar y gobernar las Tecnologías de la Información (TI) de forma adecuada y de esta forma ofrecer mejores servicios a los ciudadanos cumpliendo con la Política de Gobierno Digital.

Adicionalmente uno de los principios del modelo Gestión y Gobierno de TI es la estandarización entendida como la definición de un ecosistema tecnológico estandarizado para controlar la diversidad tecnológica, la complejidad técnica y reducir los costos asociados al mantenimiento de la operación.

El proceso Auditor evidenció que la gestión de la actualización del Sistema de Información Isolución no se maneja de forma estandarizada como los demás sistemas información del IDRD, en los cuales el Área de Sistemas gestiona y gobierna el desarrollo y/o actualización del software.

Por lo anterior la gestión de Isolución en el IDRD de manera diferencial no se alinea con el objetivo y principios del Modelo de Gestión y Gobierno de TI, en consecuencia, la respuesta no procede y se mantiene el hallazgo. Se recomienda tener en cuenta que la gestión de los sistemas de información debe analizarse integralmente y no solamente de acuerdo con el criterio de un área en específico.

2.2. Objetivo 2

Evaluar la implementación de los lineamientos del Dominio de Sistemas de Información del Marco de Referencia de Arquitectura TI en la Gestión de Sistemas de Información y Desarrollo de Software.

2.2.1 Resultados de la Prueba 2 y Análisis

Mediante correo electrónico del 28 septiembre del 2020, se solicitó al coordinador del Área de Sistemas de la Subdirección Administrativa y Financiera - SAF, información respecto de la implementación del Dominio de Sistemas de Información, el cual es parte integral del Modelo de Gestión y Gobierno de TI del elemento transversal Arquitectura de la Política de Gobierno Digital, obteniendo respuesta por este mismo medio.

Se procedió a revisar y analizar cada una de las respuestas y evidencias reportadas y a verificar su alcance teniendo en cuenta como criterio la G.GEN.04. Guía General de Evidencias del Marco de Referencia de AE para la Gestión de TI en el Estado Versión 1.3 de octubre de 2019 al igual que las evidencias establecidas en el MGGTI.G.GEN.01 – Documento Maestro del Modelo de Gestión y Gobierno de TI Versión 1.0 del 31 de octubre de 2019.

Dichos documentos se establecieron como criterios teniendo en cuenta que no se evidenció que el IDRD haya definido formalmente otro marco de referencia para la implementación de los lineamientos del Dominio Sistemas de Información. Adicionalmente se tuvo en cuenta las equivalencias de los lineamientos definidas en el MGGTI.G.GEN.01 – Documento Maestro del Modelo de Gestión y Gobierno de TI Versión 1.0 del 31 de octubre de 2019, las cuales se generaron de acuerdo con la actualización del modelo por parte del MINTIC a finales de 2019.

En virtud del análisis de la información suministrada y con el fin de despejar inquietudes y solicitar aclaración de algunos temas sobre el particular, se realizaron mesas de trabajo con el Área de Sistemas los días 16 de septiembre y 7,8,13,15,29 y 30 de octubre-2020, resultados registrados en las Actas Internas OCI-250-A, OCI-273-A, OCI-274-A, OCI-275-A, OCI-277-A, OCI-317-A y OCI-318, la cuales fueron socializadas a los participantes.

Realizado el análisis de la información suministrada por el Área de Sistemas se presenta el siguiente resultado:

1.Lineamiento MGGTI.LI.SI.01 - Metodología para el desarrollo de sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe definir una metodología formal para el desarrollo y mantenimiento de software, que oriente los proyectos de construcción o evolución de los sistemas de información que se desarrollen a la medida, ya sea internamente o a través de terceros

Evidencias

Criterios de Calidad

Proceso de desarrollo de software

Las metodologías de referencia deben contemplar al menos las siguientes fases, tener en cuenta que no necesariamente deben ser secuenciales, pueden ser iterativas e incrementales:

- Identificación y priorización de necesidades.

- Definición del Alcance.

– Gestión de requerimientos.

– Aseguramiento de la calidad.

– Arquitectura y Diseño de Software. Incluye validación de cumplimiento de Arquitectura de Referencias.

– Elaboración de términos de referencia.

– Construcción, pruebas funcionales y ajustes de Software. –

- Validación de cumplimiento de lineamientos de usabilidad y diseño gráfico.

– Pruebas no funcionales y ajustes de Software.

- Dimensionamiento de recursos tecnológicos.

– Puesta en producción y estabilización.

– Gestión de garantía. – Soporte.

Se evidencia que el IDRD en el marco del proceso de Gestión de Tecnologías de Información cuenta con el procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE Versión 1 del 2º de noviembre de 2017 y el procedimiento GESTIONAR CAMBIOS DE SEGURIDAD DE LA INFORMACIÓN

HYPERLINK "https://isolucion.idrd.gov.co/Isolucion4IDRD/Administracion/frmFrameSet.aspx?Ruta=Li4vRnJhbWVTZXRBcnRpY3Vsby5hc3A/UGFnaW5hPUJhbmNvQ29ub2NpbWllbnRvNElEUkQvOS85OTM1MkMwMC0yRUMyLTQ2OUUtODA5MS05Q0Q0NzU1RUU3RkQvOTkzNTJDMDAtMkVDMi00NjlFLTgwOTEtOUNENDc1NUVFN0ZELmFzcCZJREFSVElDVUxPPTY4MjA=" Versión 1 de octubre de 2017 con base en los cuales se realiza el mantenimiento de los sistemas de información y su puesta en producción.

Se observa que el procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE Versión 1 del 2º de noviembre de 2017, cuenta con actividades que permitan la identificación de alcance, gestión de requerimientos, elaboración de términos de referencia, dimensionamiento de recursos tecnológicos y puesta en producción, lo anterior evidencia que el procedimiento está alineado con el lineamiento

Adicionalmente se observa que el procedimiento no cuenta con actividades que permitan priorizar las solicitudes, verificar la solicitud con la Arquitectura de referencia, Validación de cumplimiento de lineamientos de usabilidad y diseño gráfico y Pruebas no funcionales. El Área de Sistemas informa que está adelantando actividades de mejoramiento del procedimiento y que tienen planeado generar una nueva versión del mismo para el primer trimestre del 2021.

2.Lineamiento MGGTI.LI.SI.02 - Derechos patrimoniales sobre los sistemas de información: Cuando se suscriban contratos con terceras partes bajo la figura de "obra creada por encargo" o similar, cuyo alcance incluya el desarrollo de elementos de software, la entidad debe incluir en dichos contratos, la obligación de transferir a la institución los derechos patrimoniales sobre los productos desarrollados.

Evidencias

Criterios de Calidad

Contratos de cesión de derechos en donde los contratistas cedan los derechos de los productos generados durante la ejecución de los contratos de TI

Se recomienda que el contrato de cesión de derechos debe ser radicado ante la Dirección Nacional de Derechos de autor.

Se observa que en los contratos de prestación de servicios profesionales se incluyó la cláusula “11. Ceder los acuerdos de licenciamiento, propiedad de los códigos fuentes y derechos de propiedad intelectual relacionados con el contenido de los aplicativos desarrollados para el IDRD.” La cual evidencia la obligación por parte del contratista de ceder los derechos de autor.

Sin embargo, el criterio de calidad del lineamiento recomienda que “el contrato de cesión de derechos debe ser radicado ante la Dirección Nacional de Derechos de autor”, a lo anterior el Área de Sistemas indicó que esta actividad a la fecha no se ha adelantado.

3.Lineamiento MGGTI.LI.SI.03 - Guía de estilo y usabilidad: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe definir o adoptar una guía de estilo y usabilidad para la Institución. Esta guía debe estar particularizada de acuerdo con la caracterización de usuarios y según el canal utilizado por los sistemas de información y, así mismo, debe estar alineada con los principios de usabilidad definidos por el Estado Colombiano, asegurando la aplicación de la guía en todos sus sistemas de información. Para los componentes de software, que sean propiedad de terceros, se debe realizar su personalización hasta donde sea posible de manera que se pueda brindar una adecuada experiencia de usuario.

Evidencias

Criterios de Calidad

Guía de estilo y usabilidad.

Sistemas de Información de la entidad que aplican la guía de estilo y usabilidad.

Para los sistemas de información que involucren interacción con el ciudadano, deben cumplir con los lineamientos de Gobierno en Línea.

El documento debe contar con manejo de versiones, pues estos lineamientos están en constante evolución y se deben ir adaptando con las arquitecturas de referencia y buenas prácticas de la industria.

Se observa que el IDRD sin perjuicio de lo definido por la normatividad nacional debe dar cumplimiento a la Resolución Número 003 (septiembre 11 de 2017) de la COMISIÓN DISTRITAL DE SISTEMAS -C.D.S.- DE LA SECRETARÍA GENERAL.

Se observa que dentro del procedimiento no se evidencian elementos que permitan asegurar el cumplimiento de dicha resolución, el Área de sistemas informa que los temas de estilo y usabilidad para la página web de la entidad son gestionados por el área de comunicaciones. Igualmente informan que para los sistemas de información se cumplen algunos requerimientos relacionados con el diseño gráfico de la entidad, su aplicación total está pendiente de cumplimiento.

Se recomienda incluir en el procedimiento la aplicación de los criterios de estilo y usabilidad gestionados por la Oficina Asesora de Comunicaciones.

4.Lineamiento MGGTI.LI.SI.04 - Ambientes independientes en el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe identificar y mantener la independencia de los ambientes requeridos durante el ciclo de vida de los sistemas de información, ya sea directamente o través de un tercero. Ejemplos de ambientes son: desarrollo, pruebas, capacitación y producción.

Evidencias

Criterios de Calidad

Ambientes independientes en el ciclo de vida de los sistemas de información.

La entidad debe evidenciar la existencia, durante el ciclo de vida de los sistemas de información, de ambientes independientes y controlados.

Se recomienda que un ambiente de esta conformado por los siguientes elementos: - Código Fuente - Configuración del ambiente - ID - Entorno de desarrollo - Documentación y Manuales de instalación - Definición de roles y responsabilidades Una vez puesto en operación el sistema de información la entidad debe tener bajo su custodia copias de sus ambientes de manera que las pueda utilizar para futuras actualizaciones. Así mismo, la entidad debe contar con un esquema de operación y control cambios donde se especifique un protocolo de paso de versiones entre ambientes, el cual incluya las características y configuraciones de los diferentes ambientes, así como los responsables de su administración.

Se observa que en el Manual de Seguridad Digital y de la de Información Versión 3 del 31 de diciembre de 2019 se estableció la política:

“4.9.4. Separación de los ambientes

• El lDRD cuenta con ambientes de desarrollo y producción separados por máquinas físicas y máquinas virtuales.

• El IDRD controla el acceso al ambiente de desarrollo de la misma forma que controla el acceso al ambiente de producción, siguiendo las directrices de la política de control de acceso.”

Adicionalmente el Área de Sistemas informa que el IDRD cuenta con la separación de ambientes productivos de los no productivos en lo relacionado con servidores, sistemas operativos, Vlan y con los permisos independientes de acceso para cada ambiente.

Se evidencia que se cuenta con ambientes de pruebas para los sistemas de información Isolucion, SIM, Orfeo, Seven, Kactus, GLPI, OTRS, ambientes de desarrollo para SIM y ORFEO y ambientes productivos para todos los sistemas de información.

5. Lineamiento MGGTI.LI.SI.05 – Análisis de requerimientos de los sistemas de información: “La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe incorporar un proceso formal de análisis y gestión de requerimientos de software en el ciclo de vida de los sistemas de información de manera que se garantice su trazabilidad y cumplimiento.”

Evidencias

Criterios de Calidad

Análisis de requerimientos de los sistemas de información

Dentro de la metodología de referencia de desarrollo de sistemas de información, dentro de la fase de gestión de requerimientos se define y detalla el proceso que contemple dentro de la gestión la identificación, levantamiento, análisis, validación y trazabilidad de los requerimientos.

En el repositorio del proyecto deben existir los artefactos, documentos o registros en herramientas donde se registra las salidas de las etapas del ciclo de vida de los requerimientos. Formatos, artefactos y/o herramientas donde se lleve el ciclo de vida de los requerimientos, contemplando las siguientes etapas: - Identificación. - Especificación. - Calidad. - Análisis. - Validación. - Trazabilidad.

Este proceso, al igual que la metodología debe ser debidamente socializado con todos los involucrados tanto al interior de la entidad como con proveedores.

Se observa que dentro de los documentos del proceso Gestión de TIC se cuenta con el procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE el cual establece actividades para el análisis de la viabilidad técnica de la solicitud y el levantamiento del requerimiento del cual se deja evidencia en el Formato de Levantamiento de Requerimientos.

Adicionalmente se observa que en el numeral 7-Lineamientos o políticas de operación del procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE se establece que “La documentación soporte del procedimiento reposará en el archivo digital de desarrollo del área de Sistemas”. La verificación del cumplimiento de dicho procedimiento se estableció como objetivo de la prueba 1 de esta Auditoria.

6. Lineamiento MGGTI.LI.SI.06 - Integración continua durante el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe garantizar que, dentro del proceso de desarrollo de sistemas de información, se ejecuten estrategias de integración continua sobre los nuevos desarrollos de sistemas de información.

Evidencias

Criterios de Calidad

Integración continua durante el ciclo de vida de los sistemas de información.

Dentro de las metodologías de referencia de desarrollo de sistemas de información y como parte del esquema de operación de ambientes dentro del ciclo de vida de los sistemas de información, se deben incluir actividades o procedimiento de integración continua.

Se recomienda que el proceso de integración se apoye en herramientas de software que permitan su automatización.

Se observa que el IDRD cuenta con la herramienta GITLAB para soportar la gestión del código fuente y control de versiones del software para los sistemas de información SIM y ORFEO. Lo anterior teniendo en cuenta que estas son las herramientas de software a las cuales el IDRD realiza desarrollo de Software con recursos internos.

7. Lineamiento MGGTI.LI.SI.07 - Entrega continua durante el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe garantizar que, dentro del proceso de desarrollo de sistemas de información, se ejecuten estrategias de entrega continua sobre los nuevos desarrollos de sistemas de información, posterior a la implementación de estrategias de integración continua.

Evidencias

Criterios de Calidad

Mecanismos utilizados para la entrega continua.

La guía de evidencias del MINTIC no describe criterios de calidad para este lineamiento

El Área de Sistemas del IDRD informa que con respecto a este lineamiento no ha tomado decisiones del alcance para su implementación.

8. Lineamiento MGGTI.LI.SI.08 - Despliegue continuo durante el ciclo de vida de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe garantizar que, dentro del proceso de desarrollo de sistemas de información, se ejecuten estrategias de despliegue continuo sobre los nuevos desarrollos de sistemas de información, posterior a la implementación de estrategias de entrega continua.

Evidencias

Criterios de Calidad

Mecanismos utilizados para el despliegue continuo.

La guía de evidencias del MINTIC no describe criterios de calidad para este lineamiento

El Área de Sistemas del IDRD informa que con respecto a este lineamiento no ha tomado decisiones del alcance para su implementación.

9. Lineamiento MGGTI.LI.SI.09 - Plan de pruebas durante el ciclo de vida de los sistemas de información: En el proceso de desarrollo y evolución de un sistema de información, la dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe contar con un plan de pruebas que cubra lo funcional y lo no funcional. La aceptación de cada una de las etapas de este plan debe estar vinculada a la transición del sistema de información a través de los diferentes ambientes.

Evidencias

Criterios de Calidad

Evidencia de la ejecución de los ciclos de pruebas sobre los desarrollos propios.

Dentro de los planes de proyecto de desarrollo de sistemas de información se debe contar con planes de pruebas funcionales y no funcionales. Documentos, artefactos e informes que evidencien la aprobación de las pruebas por las partes involucradas.

Estos planes deben estar en el repositorio documental del proyecto y ser validados y aprobados por el área de calidad de sistemas de información o quien haga sus veces. Los ítems mínimos del plan son:

- Pruebas a realizar

- Recursos necesarios

- Responsables

- Criterios de calidad En el repositorio se debe encontrar los documentos, artefactos e informes de la ejecución de las pruebas.

Se observa que no se tiene establecido formalmente el plan de pruebas para los desarrollos de software, en el procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE. En la actividad “9-Validar el desarrollo” se establece que se debe “validar el desarrollo presentado durante las interacciones “, se observa, dicha validación no especifica que se debe realizar plan de pruebas funcionales y no funcionales.

El Área de Sistemas realiza pruebas de seguridad mediante el uso de la herramienta de software Owasp Zap la cual permite realizar escaneos de seguridad a las aplicaciones (basado en diccionario de vulnerabilidades) dicha herramienta ampara su uso bajo licencia GPL.

10. Lineamiento MGGTI.LI.SI.10 - Manual del usuario, técnico y de operación de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe asegurar que todos sus sistemas de información cuenten con la documentación técnica y funcional debidamente actualizada.

Evidencias

Criterios de Calidad

Manuales de Usuario. Manuales técnicos y de operación.

Dentro de las metodologías de referencia de desarrollo de sistemas de información y como parte del esquema de operación de ambientes dentro del ciclo de vida de los sistemas de información, se deben definir entregables del producto, la documentación de usuario, técnica y de operación necesaria para cada sistema de información.

Se recomienda incluir en la documentación/artefactos para usuarios debe contener y/o hacer referencia:

- La descripción del sistema de información.

- El objetivo del sistema de información.

- Los procesos de negocio y las áreas que soporta.

- La descripción de los módulos y funcionalidades que lo componen.

- El uso de las funcionalidades del sistema de información.

- Errores funcionales más comunes y su solución.

La documentación/artefactos técnicos debe contener y/o hacer referencia:

- Errores técnicos más comunes y su solución.

- Descripción de despliegue y configuración de los componentes que conforman el sistema de información.

- Diseño técnico del sistema de información.

Toda la documentación existente debe ser accedida desde el repositorio documental que tenga definido la entidad/sector y estar actualizada cada vez que se actualice el sistema de información.

El sistema de información SIM cuenta con 17 manuales de usuario los cuales el Área de Sistemas informa que no todos están publicados en el sistema de información; adicionalmente en el procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE la actividad “13-Realizar la documentación y/o actualización” se establece que se debe “Realizar la documentación y/o actualización del código fuente y de la demás documentación requerida.”.

Se observa, que para el Sistema de información SIM y ORFEO la actualización de la documentación del código fuente se registra en el repositorio GITLAB, sin embargo, se observa que el procedimiento no especifica de forma concreta cual es la “demás documentación requerida” dejando vacíos de interpretación y alcance de la actividad. Se recomienda definir y formalizar el tipo de documentación técnica y sus contenidos mínimos con el fin de asegurar su documentación y actualización, adicionalmente se recomienda que dicha documentación sea parte del Sistema de Gestión con el fin de asegurar el control de versiones y publicación.

Se evidenció que el sistema de información ORFEO cuenta con manuales de usuario los cuales el Área de Sistemas informa que están publicados en el sistema. Se evidencia que los diferentes manuales de usuario publicados en la herramienta en la opción “Ayuda” presentan fecha de 2017, sin embargo, no es posible identificar la fecha de creación y los controles de cambio del documento. Se recomienda incluir en cada documento el control de cambios correspondientes con el objetivo de llevar la traza y determinar su nivel de actualización.

En la siguiente imagen se puede observar uno de los documentos de los manuales de usuario publicados donde se evidencia lo observado:

Imagen 1. Manual de Usuario de ORFEO

11. Lineamiento MGGTI.LI.SI.11 - Estrategia de mantenimiento de los sistemas de información: Para el mantenimiento de los sistemas de información, la dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe hacer un análisis de impacto ante cualquier solicitud de cambio en alguno de sus componentes, con el fin de determinar la viabilidad del cambio y las acciones a seguir.

Evidencias

Criterios de Calidad

Proceso documentado y formalizado de gestión de cambios.

Procedimiento documentado y formalizado de un proceso o procedimiento de gestión de cambios.

El procedimiento debe contar actividades de revisión de impacto y aprobación del cambio por parte de los grupos de interés afectados por el cambio solicitado.

Las actas y los controles de cambios deben estar disponibles en el repositorio documental de la entidad.

Los controles de cambio deben tener:

- Descripción del cambio.

- Solicitante del cambio.

- Análisis de impacto del cambio a nivel de negocio, y tecnológico.

- Listado de los sistemas de información afectados por el cambio (tomado del inventario de sistemas de información).

- Formato con modificaciones derivadas del cambio al inventario de elementos de TI (Sistemas de información, interfaces, elementos de infraestructura).

- Atributos de calidad requeridos

Se evidencia que el proceso de Gestión de Tecnologías de Información y las Comunicaciones cuenta con el procedimiento “GESTIONAR CAMBIOS DE SEGURIDAD DE LA INFORMACIÓN. Versión 1 del 6 de octubre de 2017”, el cual tiene como objetivo Gestionar de manera correcta los cambios requeridos en sistemas de Información, servicios, dispositivos y/o infraestructura tecnológica del IDRD.” Adicionalmente también se cuenta con el Formato SOLICITUD DE CAMBIO DE SEGURIDAD DE LA INFORMACIÓN en el cual se deja registro del tipo de cambio, la descripción, solicitante, la justificación, el análisis de impacto, identificación del riesgo, entregables y criterios de aceptación y la aprobación del mismo.

El Área de Sistemas informa que los Sistemas de Información cuentan con el rol de administrador funcional, sin embargo, no se tiene formalizado dicho rol como tampoco sus funciones y responsabilidades.

Imagen 2. Formato Solitud de Cambio de Seguridad de la Información

12. Lineamento MGGTI.LI.SI.12 - Servicios de mantenimiento de sistemas de información con terceras partes: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe establecer criterios de aceptación y definir Acuerdos de Nivel de Servicio (ANS) cuando se tenga contratado con terceros el mantenimiento de los sistemas de información. Los ANS se deben aplicar en las etapas del ciclo de vida de los sistemas de Información que así lo requieran y se debe velar por la continuidad del servicio.

Evidencias

Criterios de Calidad

Los ANS para la prestación del servicio de mantenimiento de los sistemas de información, que deben ser validados en conjunto al inicio del contrato y se define un periodo de transición para empezar a aplicar los mismos.

En el repositorio general de TI, así como el de cada proyecto, deben existir tanto los pliegos, RFP y contratos con las clausulas explícitas de ANS.

Los ANS debe tener: - Descripción - Servicio y/o Funcionalidad sobre el que aplica el ANS.

- Métricas asociadas.

- Rango permitido para la métrica.

-Sanción o penalidad en caso de incumplimiento.

- Frecuencia de medición. - Responsabilidades.

Se observa que para los sistemas de información SEVEN y KACTUS se suscribió el contrato 0286 de 2020 cuyo objeto es “Realizar los servicios de soporte, mantenimiento y actualización del Sistema de Información Gerencial Integrado SEVEN - ERP y KACTUS - HR, incluyendo bolsa de horas para atender los requerimientos de usuario final del Instituto Distrital de Recreación y Deporte – IDRD –.”, no se tienen establecidos Acuerdos de Niveles de Servicio-ANS.

Se observa que el Contrato 1018 cuyo objeto “Contratar el servicio de soporte y mantenimiento del software Isolucion”, el Área de Sistemas del IDRD informa que para el caso de mantenimientos generados por cambios normativos se tiene establecido como tiempo de respuesta lo establecido en la norma correspondiente. Se recomienda que la entidad revise la pertinencia que los contratos cuyo objeto y alcance el soporte y mantenimiento de sistemas de información celebrados con terceros, la supervisión sea conjunta entre el área líder del proceso y el área de sistemas precisando el alcance de cada supervisor.

13. Lineamiento MGGTI.LI.SI.13 - Plan de calidad de los sistemas de información: La dirección de Tecnologías y Sistemas de la Información o quien haga sus veces debe implementar un plan de aseguramiento de la calidad durante el ciclo de vida de los sistemas de información.

Evidencias

Criterios de Calidad

Plan de calidad.

Dentro de los planes de proyecto de desarrollo de sistemas de información se debe contar con planes de calidad. Estos planes deben estar en el repositorio documental del proyecto y ser validados y aprobados por el área de calidad de software o quien haga sus veces.

Para los planes debe considerarse:

- Alcance.

- Objetivos.

- Responsables.

- Actividades.

- Estrategia de ejecución del plan de calidad.

Indica cómo se va a ejecutar el plan y como validar su ejecución. - Métricas e indicadores. - Cronograma de actividades. - Incluye validaciones periódicas. Mecanismos de control.

El Área de Sistemas del IDRD informa que con respecto a este lineamiento no ha tomado decisiones del alcance de su implementación, adicionalmente informa que tienen planeado generar un plan de calidad para el primer trimestre de 2021.

14. Lineamiento MGGTI.LI.SI.14 - Requerimientos no funcionales y atributos calidad de los sistemas de información: En la construcción o modificación de los Sistemas de Información, la Dirección de Tecnologías y Sistemas de la Información o quien haga sus veces, debe identificar los requerimientos no funcionales aplicables asociados a los atributos de calidad, garantizando su cumplimiento una vez entre en operación el sistema.

Evidencias

Criterios de Calidad

Documento de especificación de requerimientos funcionales y no funcionales (atributos de calidad).

Este documento debe incluir las restricciones funcionales y técnicas de las arquitecturas de referencia y solución y los atributos de calidad para la entidad

El Área de Sistemas del IDRD informa que con respecto a este lineamiento no ha tomado decisiones del alcance de su implementación, adicionalmente informa que tienen planeado generar un plan de calidad para el primer trimestre de 2021.

15. Lineamiento. MGGTI.LI.SI.15 – Accesibilidad Los sistemas de información que estén disponibles para el acceso a la ciudadanía o aquellos que de acuerdo con la caracterización de usuarios lo requieran, deben cumplir con las funcionalidades de accesibilidad que indica la política de Gobierno Digital.

Evidencias

Criterios de Calidad

Informes del nivel de accesibilidad de los sistemas de información dispuestos a los ciudadanos realizados de forma manual y de forma automática.

Plan de pruebas que incorpore un criterio de aceptación para accesibilidad de acuerdo a la caracterización de usuarios realizada sobre el sistema.

Las pruebas pueden ser ejecutadas con herramientas informáticas que evalúan el nivel de cumplimiento A, AA, o AAA

El Área de Sistemas del IDRD informa que el portal www.idrd.gov.co es gestionado por el área de comunicaciones, adicionalmente informa que para el sistema SIM el cual tiene servicios a la ciudadanía no se han realizado verificaciones de accesibilidad.

Se procedió a realizar una prueba del nivel de cumplimiento del nivel A y AA de la página web www.idrd.gov.co con la herramienta TAW, la cual es una herramienta automática on-line para analizar la accesibilidad de sitios web, creada teniendo como referencia técnica las pautas de accesibilidad al contenido web ( WCAG 2.0) del W3C “El Consorcio World Wide Web (W3C- ).

La W3C es una comunidad internacional donde las organizaciones Miembro, personal a tiempo completo y el público en general trabajan conjuntamente para desarrollar estándares Web. El objetivo de TAW es comprobar el nivel de accesibilidad alcanzado en el diseño y desarrollo de páginas web con el fin de permitir el acceso a todas las personas independientemente de sus características diferenciadoras.  Cabe aclarar que esta herramienta solo analiza la página principal pero su resultado de la prueba es un indicador de cumplimiento de los criterios de accesibilidad para establecer planes de mejora.

Los resultados de prueba para el Nivel A de cumplimiento, muestran que la sede electrónica de la Entidad www.idrd.gov.co tiene 30 problemas y 248 advertencias, a continuación se presentan imágenes con los resultados. Cabe aclarar que existen varias herramientas para la verificación del nivel de accesibilidad y cada una realiza la verificación de algunos criterios.

Imagen 3. Validación accesibilidad Nivel A

Los resultados de prueba para el Nivel AA de cumplimiento muestran que la sede electrónica de la Entidad www.idrd.gov.co tiene 29 problemas y 256 advertencias, a continuación se presentan imágenes con los resultados. Cabe aclarar que existen varias herramientas para la verificación del nivel de accesibilidad y cada una realiza la verificación de algunos criterios.

Imagen 4. Validación accesibilidad Nivel AA

2.2.2 Conclusiones

1. En el PETI 2019 - 2020 se definió el Proyecto No. 12 Arquitectura Empresarial, dicho proyecto estableció la definición del estado Actual de la Arquitectura de TI y la definición de la Arquitectura de TI Objetivo y para avanzar de forma planeada en la implementación del elemento transversal Arquitectura. Sin embargo, el Área de sistemas informó que dicho proyecto no se ejecutó por restricciones presupuestales.

2. Algunos requerimientos para su implementación requieren la articulación y trabajo armónico con otras áreas de la entidad como es el caso de los lineamientos de accesibilidad y la guía de estilo y usabilidad y que toma mayor relevancia para los sistemas de información que prestan servicio a la ciudadanía.

3. El IDRD cuenta con avances en la implementación de siete (7) de los lineamientos del Dominio de Sistemas de Información, lo que corresponde al 46% del total. Los avances y logros alcanzados se han implementado en el marco de la gestión del proceso TI. Se evidenciaron avances en los lineamientos: MGGTI.LI.SI.01 - Metodología para el desarrollo de sistemas de información, MGGTI.LI.SI.02 - Derechos patrimoniales sobre los sistemas de información, MGGTI.LI.SI.04 - Ambientes independientes en el ciclo de vida de los sistemas de información, MGGTI.LI.SI.05 – Análisis de requerimientos de los sistemas de información, MGGTI.LI.SI.06 - Integración continua durante el ciclo de vida de los sistemas de información, MGGTI.LI.SI.10 - Manual del usuario, técnico y de operación de los sistemas de información, MGGTI.LI.SI.11 - Estrategia de mantenimiento de los sistemas de información.

4. El IDRD no cuenta con avances en la implementación de ocho (8) de los lineamientos del Dominio de Sistemas de Información, lo que corresponde al 54% del total. No se evidenciaron avances en los lineamientos: MGGTI.LI.SI.03 - Guía de estilo y usabilidad , MGGTI.LI.SI.07 - Entrega continua durante el ciclo de vida de los sistemas de información, MGGTI.LI.SI.08 - Despliegue continuo durante el ciclo de vida de los sistemas de información, MGGTI.LI.SI.09 - Plan de pruebas durante el ciclo de vida de los sistemas de información, MGGTI.LI.SI.12 - Servicios de mantenimiento de sistemas de información con terceras partes, MGGTI.LI.SI.13 - Plan de calidad de los sistemas de información, MGGTI.LI.SI.14 - Requerimientos no funcionales y atributos calidad de los sistemas de información, MGGTI.LI.SI.15 Accesibilidad

2.2.3 Aspectos Logrados

En desarrollo de la Auditoria no se observaron aspectos que representen logros en esta materia.

2.2.4 Fortalezas

No se observaron situaciones que generen valor agregado a la gestión del proceso.

2.2.5 Oportunidades de mejora

OM1: Se recomienda que el IDRD defina y formalice los alcances específicos que la entidad requiere lograr en cuanto a la implementación de cada uno de los lineamientos del Dominio de Sistemas de Información, de acuerdo con sus necesidades y capacidades para apoyar sus objetivos estratégicos.

OM2: Se recomienda que el plan de implementación de los lineamientos del Dominio Sistemas de Información y el general del modelo de Gestión y Gobierno de TI se presente para que se avalado por el Comité Institucional de Gestión y Desempeño-CIGD.

OM3: Se recomienda al Líder del proceso de Gestión de Tecnologías de la Información y las Comunicaciones incluir dentro en la agenda del Comité Institucional de Gestión y Desempeño el seguimiento a la implementación de los lineamientos del elemento transversal Arquitectura TI el cual incluye el Dominio Sistemas de Información.

OM4: Se recomienda definir y formalizar los Acuerdos de Niveles de Servicio-ANS que se deben incluir en las obligaciones de los contratos que se suscriban con terceros para el soporte y mantenimiento de los sistemas de información.

OM5: Se recomienda definir e implementar el nivel de accesibilidad que se requiere cumplir con la sede electrónica de la entidad y demás portales relacionados, al igual que para el sistema de información SIM, los cuales tienen interacción con la ciudadanía. Adicionalmente se recomienda que para su implementación se articule la gestión con la Oficina Asesora de Comunicaciones y demás áreas pertinentes.

OM6: Se recomienda que, para el análisis e implementación integral del Dominio Sistemas de Información, adicional a los lineamientos evaluados en esta Auditoria, se tengan en cuenta los lineamientos establecidos en MAE.G.GEN.01 – Documento Maestro del Modelo de Arquitectura Empresarial relacionados con la gestión de sistemas de información, emitido por el MINTIC.

OM7: Se recomienda realizar los trámites pertinentes para el registro de los Derechos Patrimoniales del Sistema de información SIM ante la Dirección Nacional de Derechos de Autor.

OM8: Se recomienda incluir en el procedimiento GESTIONAR EL DESARROLLO Y/O ACTUALIZACIÓN DE SOFTWARE, actividades que aseguren la aplicación de los criterios de Estilo, Usabilidad y Accesibilidad.

OM9: Se recomienda definir y formalizar el Rol de Administrador Funcional de cada Sistema de Información, estableciendo sus funciones y responsabilidades. Lo anterior permitirá mejorar el gobierno y control funcional de los sistemas de información y diferenciar las funciones del administrador técnico.

Adicionalmente a la evaluación del avance en la implementación de los Lineamientos del Dominio se verificaron las respuestas dadas por el IDRD para la autoevaluación del FURAG 2019. Para lo anterior se identificaron y verificaron las preguntas 81 y 83 y las respuestas correspondientes, a continuación, se muestra el resultado de la prueba realizada.

2.2.6 Resultados de la Prueba 3 y Análisis

Realizado el análisis de la información suministrada por el Área de Sistemas presenta el siguiente resultado:

Pregunta 81 Con relación a la planeación y gestión de los sistemas de información

OPCION A: La entidad reportó para la opción a) que Cuenta con un catálogo actualizado de todos los sistemas de información, aportando como evidencia el documento electrónico Sistemas de Información v1.0, dicho documento muestra una tabla que relaciona ocho (8) sistemas de información: ORFEO, KACTUS, SEVEN, GLPI, SIM, ISOLUCION, OTRS, PAGINA WEB y describe i