ANEXO 1 PROPOSICIÓN TÉCNICApntdocumentos.inai.org.mx/templates/jf_taman/contenido/... · 2016-06-26 · “Desarrollo de la Plataforma Nacional de Transparencia Primera Etapa

!www.intellego.com.mx!!Teléfono!+!52!(55)!3004!2984!al!86,!Prolongación!Reforma!1236C3.!México,!D.F.!RFC!

INT010509RB0!!

INSTITUTO NACIONAL DE TRANSPARENCIA, ACCESO A LA INFORMACIÓN Y PROTECCIÓN DE DATOS PERSONALES

DIRECCIÓN GENERAL DE ADMINISTRACIÓN LICITACIÓN NO. LA-006HHE001-N100-2015 Y LPN-006HHE001-008-15

Página 1 de 11

ANEXO 1 PROPOSICIÓN TÉCNICA

México D.F. a 7 de Septiembre de 2015 INSTITUTO NACIONAL DE TRANSPARENCIA, ACCESO A LA INFORMACIÓN Y PROTECCIÓN DE DATOS PERSONALES Av. Insurgentes Sur 3211, Col. Insurgentes Cuicuilco, Delegación Coyoacán México D.F., C.P. 04530. Con este documento de propuesta técnica para la ejecución de los servicios del

“Desarrollo de la Plataforma Nacional de Transparencia Primera Etapa” aceptamos

expresamente las condiciones contenidas en el anexo técnico de la presente Licitación

Pública Nacional Electrónica, manifestando bajo protesta de decir verdad que

cumplimos con todos y cada uno de los requisitos técnicos referidos en el anexo en

comento, así como en las modificaciones y respuesta dadas en la Junta de Aclaraciones.

ATENTAMENTE

_______________________________ ANTONIO ARIAS ROBINSON

REPRESENTANTE LEGAL INTELLEGO, S.C. RFC INT010509RB0


INT010509RB0!!



Página 2 de 11

ÍNDICE

1.! Alcance del servicio!....................................................................................................!3!2.! Supuestos!......................................................................................................................!5!3.! Sistema de Solicitudes de Acceso a la Información!................................................!8!4.! Sistema de Evaluación de las Obligaciones de Transparencia!............................!86!5.! Sistema de Gestión de Medios de Impugnación (Recurso de Revisión y Atracción)!...........................................................................................................................!89!6.! Sistema de Comunicación entre Órganos Garantes y Sujetos Obligados!.........!102!7.! Motor de Búsqueda!..................................................................................................!108!8.! Pruebas a la PNT!......................................................................................................!110!9.! Bolsa de horas de desarrollo!..................................................................................!111!10.! Entregables!...........................................................................................................!111!11.! Garantía!................................................................................................................!113!12.! Vigencia de la Contratación!...............................................................................!113!13.! Propiedad Intelectual!.........................................................................................!113!14.! Forma de Pago!.....................................................................................................!114!15.! Pena Convencional!..............................................................................................!114!


INT010509RB0!!



Página 3 de 11

1.! Alcance del servicio Actualmente el INAI dispone de aplicaciones que cuentan con funcionalidad que será de utilidad para el desarrollo de la Plataforma Nacional, estas aplicaciones serán la base para la construcción de la Plataforma Nacional, por lo cual, el servicio que el INAI contratará considera lo siguiente:

1.! Revisión de funcionalidad existente en el Sistema para Solicitudes de Acceso a la Información.

2.! Adecuaciones necesarias al Sistema para Solicitudes de Acceso a la Información, originadas por cambios en la Ley General de Transparencia y Acceso a la Información Pública, así como requerimientos adicionales originados por posibles reformas en la Ley Federal de Transparencia y Acceso a la Información Pública Gubernamental y las Leyes locales de la materia.

3.! Revisión de funcionalidad existente en el Sistema de Portales de Obligaciones de Transparencia.

4.! Adecuaciones necesarias al Sistema de Portales de Obligaciones de Transparencia, originadas por cambios en la Ley General de Transparencia y Acceso a la Información Pública, así como requerimientos adicionales originados por posibles reformas en la Ley Federal de Transparencia y Acceso a la Información Pública Gubernamental y las Leyes locales de la materia.

5.! Configuración de la lógica de operación de la Gestión de Medios de Impugnación y Comunicación entre Organismos Garantes y Sujetos Obligados en el BPM existente en el Sistema de Solicitudes de Acceso a la Información o en BPM propuesto por Intellego, siempre y cuando sea software libre y previo VoBo de la DGTI del INAI.

6.! Integrar el motor de búsqueda empresarial, con el que cuenta el INAI, para que indexe la información que estará contenida en la Plataforma Nacional de Transparencia.

7.! Incluir una solución que permita contar con múltiples estadísticas y dinamismo en las consultas que se realicen en él, para el análisis de información y toma de decisiones directivas e institucionales.

8.! Integrar todos los Sistemas y soluciones mencionados previamente mediante el bus de comunicación existente en el Sistema de Solicitudes de Acceso a la Información.

9.! Integrar los diferentes sistemas de la Plataforma Nacional de Transparencia a través de un portal que permita consultar información relativa a los cuatro sistemas que conformarán la Plataforma.

10.!Actualizar e incorporar nueva funcionalidad a los aplicativos para dispositivos móviles con sistema operativo iOS, Android y Windows Phone.


INT010509RB0!!



Página 4 de 11

11.!Los diferentes sistemas de información que integrarán la Plataforma Nacional de Transparencia, deberán de ser parametrizables de tal forma que las estructuras en las que almacenen la información sean dinámicas y las consultas que se realicen a través de aplicaciones para dispositivos móviles inteligentes, así como en el portal de Internet de la Plataforma, deberá facilitar la consulta de las estructuras dinámicas.


INT010509RB0!!



Página 5 de 11

2.! Supuestos

BPM

•! Se hará uso del BPM Actual, tomando en cuenta las características con las que se cuenta o se podría proponer uno por Intellego tomando en cuenta previo VoBo de la DGTI.

•! Dicho BPM permite la interoperabilidad con el ESB “in house”, El portal en LifeRay, CM Alfresco y Motor de Alertas.

•! Solo se modelarán procesos en BPM para la operación de la Gestión de Medios de Impugnación y Comunicación entre Organismos Garantes y Sujetos Obligados.

Administrador de Contenidos

•! Actualmente se cuenta con Alfresco como solución de Administrador de Contenidos.

•! La DGTI ya cuenta con la implementación de la lógica de Administración de Machotes para la creación de secciones con base a requerimientos futuros de nuevas obligaciones de transparencia, por lo que, queda como parte de Intellego realizar adecuaciones requeridas que serán tomados de la bolsa de horas de desarrollo que requiere el cliente para nuevas adecuaciones.

•! El tamaño de los archivos adjuntos en las solicitudes de información estarán oscilando en un rango mínimo de 5MB y máximo de 20MB, siendo este configurable en la solución.

•! Los archivos adjuntos serán almacenados en Alfresco y la funcionalidad del Portal será mediante descarga, quedando como parte pre-visualización derivada del plugin del Navegador que se esté utilizando y no de la solución del Portal.

Funcionalidad del Portal

•! Actualmente ya existe el total de la funcionalidad implementada en las Transacciones de Solicitud de Acceso a la Información implementado en el Portal de LifeRay.

•! Por el punto anterior, se asume que referente a la funcionalidad no se harán nuevos diseños ni desarrollo, si no mantenimiento a los existentes con la finalidad de cumplir con los cambios a la Ley de Transparencia.

•! El tiempo invertido para hacer las adecuaciones por los cambios a la Ley serán tomados de la bolsa de horas de desarrollo que requiere el cliente para nuevas adecuaciones.


INT010509RB0!!



Página 6 de 11

•! El código fuente de las aplicaciones existentes que integran el Portal, se encuentra completo y sin ningún tipo de error al momento de compilarlo y ejecutarlo bajo las especificaciones proporcionadas por la convocante.

•! Respecto a los requerimientos que se menciona en la página 73 de la Licitación donde se hace referencia al Numeral 6. Nuevo Sistema de Obligaciones de Transparencia, la DGTI menciona que dicha funcionalidad ya existe actualmente implementada, por lo que el Alcance de Intellego será implementar los puntos de mejora de la Pág. 118 en el punto F.6. Mejoras de la Herramienta.

Reportes

•! Intellego implementará de 7 a 10 Reportes que estarán contenidos en el Portal Nacional de Transparencia.

•! El dinamismo de los reportes se refiere a los criterios de filtrado para la generación de los resultados de los mismos.

Búsquedas Federadas

•! Ya se cuenta con un mecanismo de búsquedas federadas, las cuales deberán solo adecuarse al Portal y a las Aplicaciones Móviles.

•! El dinamismo de los reportes se refiere a los criterios de filtrado para la generación de los resultados de los mismos.

Seguridad

•! La plataforma ya cuenta con mecanismo de autenticación SSO y el alcance de Intellego sería adecuar el componente existente a la integración de la solución

•! La plataforma actual cuenta con un componente que utiliza los certificados de la FIEL del SAT para a autenticación y acreditación de autoridad jurídica y los cuales se validan contra el servicio de OSCP del SAT. Por lo que intellego hará uso de este mismo componente para adecuarlo a la plataforma de integración.

Solicitudes de Información vía Telefónica

•! La DGTI ya cuenta actualmente con un centro de atención telefónica que hoy día atiende las solicitudes de información.

•! El alcance es adecuar las aplicaciones del Portal que actualmente puede registrar la solicitud.


INT010509RB0!!



Página 7 de 11

Infraestructura

•! Intellego solo proporcionará el dimensionamiento de la infraestructura requerida para cumplir con los requerimientos de su actual Arquitectura Física y Lógica

•! Intellego no absorberá los costos de esta Infraestructura requerida. •! La infraestructura de envío de mensajes SMS no forma parte de la licitación y

por lo tanto el alcance de Intellego es realizar pruebas con la solución que el INAI proporcione. El alcance de las pruebas no se encuentra estipulado en la licitación, sin embargo, Intellego tomará las horas invertidas para estas actividades de la bolsa de horas solicitadas por la DGTI.

Arquitectura Física y Lógica

•! Intellego deberá integrar las aplicaciones existentes, basándose en la Arquitectura Física y Lógica actualmente diseñada por la DGTI.

•! Queda fuera del alcance de Intellego proponer una Arquitectura nueva.

Dispositivos Móviles

•! El código fuente de las aplicaciones se encuentra codificado en los siguientes lenguajes:

-! iOS: Objective-C -! Android: Java -! Windows Phone: C#

•! El código fuente de las aplicaciones existentes se encuentra completo y sin

ningún tipo de error al momento de compilarlo y ejecutarlo bajo las especificaciones proporcionadas por la convocante.

Las versiones de los sistemas operativos para las aplicaciones móviles serán: Windows 8 o posterior, IOS a partir de la 7.1.2 y Android a partir de la versión 4.0.

Documentación

•! El requerimiento del anexo técnico del INAI no solicita documentación MAAGTIC.


INT010509RB0!!



Página 8 de 11

Componentes de la Solución:

3.! Sistema de Solicitudes de Acceso a la Información Intellego llevará a cabo la revisión detallada para validar la funcionalidad existente en el Sistema de Solicitudes de Acceso a la Información con el que cuenta el INAI, el cual a continuación se indica:

1.! Acceso desde múltiples medios electrónicos (Teléfonos móviles y tabletas basados en Windows 8 o posterior, Windows Phone, iOS y/o Android).

2.! Simplificar el proceso de solicitud de información.

3.! Mecanismos de búsqueda más sencillos.

4.! Visualizar las obligaciones de transparencia a nivel nacional.

5.! Contar con un buscador de información pública a nivel nacional.

6.! Un asistente (wizard) que brinde apoyo a los usuarios nuevos o poco experimentados para realizar búsquedas, solicitudes de información o interposición de recursos de revisión.

7.! Acceso a los sistemas INFOMEX que se encuentran operando en los Estados de la República y/o Sujetos Obligados de la Ley Federal de Transparencia de los otros Poderes y Organismos Autónomos Federales mediante un bus de servicios empresariales.

8.! Explotación y exportación de datos en formatos abiertos.

9.! Elaboración de solicitudes de información o recursos de revisión, vía telefónica.

10.!Deberá operar en un ambiente on-premise dentro del centro de datos del INAI.

11.!Mecanismo de notificación de estatus de solicitudes.

12.!Integración a redes sociales. A continuación se enumeran los componentes de la solución con la que cuenta el INAI:

1.! Componentes Funcionales

1.1.!Portal Nacional de Transparencia (Portal Ciudadano, el cual está integrado dentro del Sistema Electrónico de solicitudes de Información con el que cuenta el INAI)

1.2.!Aplicaciones Móviles para el Ciudadano

1.3.!Flujos de trabajo y Atención (BPM)


INT010509RB0!!



Página 9 de 11

1.4.!Búsquedas Federadas de información

1.5.!Repositorio y Datos de Transparencia

1.6.!Conexión a Redes Sociales y Mensajes SMS

2.! Componentes No Funcionales

2.1.!Seguridad

2.2.!Gestión de Identidad

2.3.!Monitoreo de la disponibilidad de los servicios que incluya alertas preventivas para el personal técnico que administre la aplicación.

2.4.!Bus de servicios empresariales (ESB – Enterprise Service Bus)

3.! Diagrama de componentes de la solución

Arquitectura Funcional:


INT010509RB0!!



Página 10 de 11

Arquitectura Tecnológica Propuesta La arquitectura a utilizar en el servicio será la requerida por la Convocante en la junta de aclaraciones:

Se utilizarán las siguientes herramientas: Alfresco, LifeRay, Node.JS, Mulesoft, Java, base de datos Oracle 11g, Mongo y MySQL de conformidad con lo establecido en la Junta de Aclaraciones.


INT010509RB0!!



Página 11 de 11

4.! Fronteras del Servicio

La solución tecnológica tendrá las siguientes fronteras físicas de servicio:

5.! Componentes funcionales de la Solución

5.1.!Portal Nacional de Transparencia (Portal Ciudadano, el cual está integrado dentro del Sistema Electrónico de solicitudes de Información con el que cuenta el INAI)

•! La solución proveerá una presentación web para el Portal Nacional de Transparencia, por medio del cual, el ciudadano pueda realizar diversas interacciones.

5.1.1.!Portal

El portal contará con las siguientes características:

5.1.1.1.! Definido bajo la consultoría de arquitectura de información, que permita una efectiva definición de la solución web en términos de accesibilidad y usabilidad establecidos:

5.1.1.2.! Estándares del W3C ( Consorcio World Wide Web)

5.1.1.3.! Guía para la Acción Pública (GAP). Los sitios web accesibles. Una herramienta para el acceso a la información y a la interacción en condiciones de igualdad: http://www.conapred.org.mx/userfiles/files/GAP-Web-OK-Accss.pdf

5.1.1.4.! Ser fácil de utilizar

5.1.1.5.! Intuitivo

5.1.1.6.! Atractivo para usuarios ciudadanos

5.1.1.7.! Tener tiempos de respuesta ágiles.


INT010509RB0!!



Página 12 de 11

5.1.1.8.! Utilizar lenguaje ciudadano

5.1.1.9.! Los usuarios del sitio contarán con la posibilidad de poderse registrar en el portal. Los mecanismos de registros serán al menos:

5.1.1.9.1.! Cuentas de redes sociales

5.1.1.9.2.! Usuario y Contraseña mediante un Single Sign On

5.1.1.9.3.! Uso de FIEL para permitir la identificación oficial del usuario para procesos de protección de datos personales ARCO (Acceso, Rectificación, Cancelación y Oposición)

5.1.1.10.! Asociar las credenciales de acceso del usuario con otras cuentas de los distintos sistemas INFOMEX integrándolas al Single Sign On

5.1.1.11.! El portal indicará de manera clara, qué sistemas Infomex están adheridos a la nueva plataforma para que el usuario pueda determinar la información que podrá encontrar.

5.1.1.12.! El portal será lo suficientemente flexible para crear secciones nuevas que puedan requerirse en un futuro próximo, considerando al menos las nuevas obligaciones de transparencia que contemplen las leyes en la materia.

5.1.1.13.! El portal será lo suficientemente flexible para crear machotes de documentos que servirán en un futuro para estandarizar las respuestas a solicitudes de información que generan los sujetos obligados.

5.1.1.14.! Estadísticas de uso, información más consultada, visitas.

5.1.2.!Buscador Asistido

El portal contará con un módulo de búsquedas asistidas, por medio del cual le facilite el proceso al ciudadano.

5.1.2.1.! El buscador será capaz de consultar múltiples fuentes de datos al mismo tiempo, tales como:

5.1.2.1.1.! Respuestas a solicitudes de información pública a nivel nacional.

5.1.2.1.2.! Obligaciones de transparencia a nivel nacional.

5.1.2.1.3.! Sitios en Internet (Portales Gubernamentales)

5.1.2.2.! Los resultados de las búsquedas contarán con las siguientes características:

5.1.2.2.1.! Ser mostrados por relevancia.


INT010509RB0!!



Página 13 de 11

5.1.2.2.2.! Poder ser ordenados, de acuerdo a varios criterios.

5.1.2.2.3.! Contar con opción de refinamiento.

5.1.2.2.4.! Descargar el resultado de la búsqueda o enviarla por correo en su estructura nativa.

5.1.2.2.5.! Brindar sugerencias de búsquedas alternativas.

5.1.2.2.6.! En caso de no obtener un resultado satisfactorio para el usuario, pre-construirá con la información recopilada una solicitud de información.

5.1.2.3.! El buscador contará con la siguiente funcionalidad

5.1.2.3.1.! Dar sugerencias

5.1.2.3.2.! Considerar faltas de ortografía

5.1.2.3.3.! Uso de sinónimos y Tesauro1

5.1.2.3.4.! Ayuda e información más buscada, más reciente o más relevante

5.1.2.3.5.! En campos de texto contar con autocomplete

5.1.2.3.6.! Reconocer como parte de las opciones de búsqueda con operadores lógicos para facilitar las búsquedas que realicen los usuarios.

5.1.2.3.7.! Incluir la funcionalidad de “nube de palabras”

5.1.2.3.8.! Contar con la lógica del algoritmo C4.5 o similar para el armado de árboles de decisión

5.1.2.3.9.! Estadísticas de:

5.1.2.3.9.1.! Uso

5.1.2.3.9.2.! Palabras o frases más buscadas

5.1.2.3.9.3.! Por hora, día

5.1.2.3.9.4.! Consultas por dirección IP

5.1.2.3.9.5.! Otras

5.1.3.!Solicitud de información, Protección de datos personales (ARCO) y Recurso de Revisión (Queja)

! 1 http://es.wikipedia.org/wiki/Tesauro


INT010509RB0!!



Página 14 de 11

Por medio del portal, cualquier ciudadano poderá realizar solicitudes de información pública, de protección de datos personales (ARCO) o interponer el recurso de revisión (Queja).

Las características y funcionalidades de este módulo son:

5.1.3.1.! Proveer interfaces y formularios de captura dirigidos e inteligentes, por medio de los cuales deberá:

5.1.3.1.1.! Ser simples y sencillos de utilizar, siguiendo los lineamientos de usabilidad y accesibilidad previamente definidos.

5.1.3.1.2.! Simplificar la solicitud de información y/o protección de datos personales (ARCO) en no más de 5 pasos, así como la interposición del recurso de revisión.

5.1.3.1.3.! Orientar al usuario para hacer solicitudes o interponer recursos de revisión, lo más específicos y bien formados posibles mediante el asistente (Wizard).

5.1.3.1.4.! Integración del cálculo de costos de reproducción y envío a nivel informativo de cada uno de los sistemas Infomex que se encuentren adheridos a la nueva plataforma.

5.1.3.1.5.! Mostrar información adicional relevante, tales como solicitudes y sus respuestas, obligaciones de transparencia o sitios gubernamentales, más comunes u opciones adicionales que puedan responder al usuario sin necesidad de emitir una solicitud formal.

5.1.3.1.6.! Considerar la posibilidad de emitir solicitudes de protección de datos (ARCO).

5.1.3.1.7.! Considerar la posibilidad de emitir la solicitud a diversos sujetos obligados que se adhieran a la plataforma de forma simultánea (Solicitudes a Múltiples Sujetos Obligados).

5.1.3.1.8.! Considerar la opción para realizar solicitudes o recursos de revisión, vía telefónica.

5.1.3.2.! Proveer un panel de seguimiento que permita al usuario visualizar el estado de cada una de las solicitudes que haya solicitado en los sistemas Infomex que se adhieran a la plataforma, así como interponer un recurso de dichas


INT010509RB0!!



Página 15 de 11

solicitudes, si se cumplieran las reglas establecidas para hacerlo.

5.1.3.3.! Solicitud Asistida (wizard):

5.1.3.3.1.! Reducir la generación de solicitudes de información innecesarias cuando se puede obtener información que ya es pública de solicitudes similar o porque la información ya fue publicada por el sujeto obligado con anterioridad o porque la búsqueda es referente a algún trámite o servicio al cual lo podremos referir, entre otras.

5.1.3.3.2.! Encontrar rápida y fácilmente la información que busca sin necesidad de generar una nueva solicitud.

5.1.3.3.3.! Utilización de algoritmos como C4.5 que permitan generar árboles de decisión dinámicos para facilitar el acceso de información mediante presentación de lista de sugerencias.

5.1.3.3.4.! Si el usuario desea seguir adelante, el Asistente (Wizard) lo llevará de la mano para redactar y enviar una solicitud donde una sola pregunta se dirija a uno o varios sujetos obligados. (Solicitudes a Múltiples Sujetos Obligados).

5.1.3.3.5.! El usuario también podrá adjuntar uno o varios archivos que refuercen su solicitud donde el tamaño autorizado para cada archivo o la suma de los mismos sea parametrizable para cubrir las distintas reglas de negocio existentes entre los distintos sistemas Infomex.

5.1.3.4.! Solicitud Avanzada

5.1.3.4.1.! Simplificar la solicitud de información y/o protección de datos personales (ARCO) en no más de 5 pasos, así como la interposición del recurso de revisión.

5.1.3.4.2.! Agilizar el proceso de solicitud y de respuesta logrando que la interface ayude al usuario a ordenar sus ideas y a dividir adecuadamente las preguntas a cada una de los sujetos obligados involucrados al mismo tiempo que podrá adjuntar uno o varios archivos ligados a la pregunta específica o a toda la solicitud de tal forma que cuando esta llegue a cada uno de los sujetos obligados en cuestión, el personal asignado a responderla, tenga una idea muy clara de que se le solicita (general y particularmente) y pueda responder rápidamente.

5.1.4.!Noticias y socialización de la información


INT010509RB0!!



Página 16 de 11

El portal deberá contar con funcionalidades de administración de contenido y redes sociales, de forma que permita realizar las siguientes actividades:

5.1.4.1.! Mostrar noticias que los sujetos obligados puedan publicar con base en criterios de relevancia, caducidad, temporalidad.

5.1.4.2.! Mostrar indicadores estadísticos relevantes con base en la información contenida en el portal.

5.1.4.3.! Socializar información, permitiendo a los usuarios compartir y comentar información del portal en diferentes redes sociales.

5.1.5.!Alertas

Dado que el principal objetivo de la solución es la de permitir realizar solicitudes de información pública, de datos personales (ARCO) o interposición de recursos de revisión (QUEJA), el ciudadano deberá ser alertado cuando una solicitud sea resuelta o requiera de la atención del usuario. Por tal motivo, deberá existir un módulo de alertas que permita la siguiente configuración:

5.1.5.1.! Emisión de alertas vía SMS

5.1.5.2.! Emisión de alertas vía correo electrónico.

5.1.5.3.! Emisión de alertas vía Portal Nacional de Transparencia.

5.1.5.4.! Emisión de alertas vía Twitter.

Adicionalmente, el portal deberá contar con alertas sobre la disponibilidad de los servicios.

5.1.6.!Requisitos adicionales a la Funcionalidad

La solución entregada deberá contar con los siguientes componentes en la arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio:

5.1.6.1.! Deberá estar totalmente integrada a los demás componentes tecnológicos de la solución, garantizando su compatibilidad comprobada con información del fabricante para lograr agilidad en la ejecución de cambios y mantenimientos.

5.1.6.2.! La solución deberá permitir a los autores, copiar contenido, pegarlo directamente en un elemento web de Editor de texto enriquecido, un elemento web de Editor de contenido o un control de campo HTML en una página y hacer que el formato


INT010509RB0!!



Página 17 de 11

HTML semánticamente correcto resultante se muestre en los estilos definidos por el diseñador del sitio.

5.1.6.3.! La solución deberá permitir direcciones URL descriptivas.

5.1.6.4.! Permitir descubrir fácilmente contenido y acceder a múltiples taxonomías desde un servicio de almacén de términos central usando la navegación impulsada por metadatos y campos incrustados de metadatos en los documentos.

5.1.6.5.! Los formularios deberán tener el soporte para ser consultados en múltiples dispositivos.

5.1.6.6.! Almacenamiento de los contenidos documentales generados en los procesos y accesibles desde estos últimos.

5.1.6.7.! Soporte para grandes volúmenes de archivos. Se debe considerar que el Administrador Empresarial de Contenido cuente con los requerimientos tecnológicos y con la capacidad para manejar la información documental contenida sin que desmejore su rendimiento.

5.1.6.8.! Como parte del proceso de auditoría, la solución deberá permitir el seguimiento a la información generada en la misma y a las tareas efectuadas por el personal que participa en el proceso, permitiendo la trazabilidad como un componente del mecanismo de seguridad.

5.1.6.9.! Permitir la comunicación de interfaces a través de servicios web y el uso de APIS2

5.1.6.10.! Posibilidad de utilizar múltiples taxonomías para clasificar y mostrar el contenido.

5.1.6.11.! Mecanismos de seguridad para acceso a la información (por documento, secciones, categorías, carpetas).

5.1.6.12.! Exposición en portales e interfaces web del contenido de ciertas partes de los repositorios.

5.1.6.13.! Proveer la capacidad de calificar la utilidad de la información aquí contenida y presentada, basándose en el esquema de “estrellas” utilizado en redes sociales. Esta información será de uso exclusivo para el Instituto

5.2.!Aplicaciones móviles para el ciudadano

La solución deberá poder ser accesible desde dispositivos móviles a los servicios por medio de Aplicaciones Móviles para el Ciudadano, adecuadas a

! 2 http://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones


INT010509RB0!!



Página 18 de 11

los tipos de dispositivo y sistemas operativos disponibles más comunes, que son iOS, Android y Windows Phone.

Las aplicaciones deben contar con las siguientes características:

5.2.1.! Deben ser definidas bajo la consultoría de arquitectura de información, que permita una efectiva definición en términos de usabilidad y accesibilidad.

5.2.1.1.! Ser fáciles de utilizar

5.2.1.2.! Intuitivas.

5.2.1.3.! Atractivas para usuarios ciudadanos.

5.2.1.4.! Tener tiempos de respuesta ágiles.

5.2.1.5.! Utilizar lenguaje ciudadano.

5.2.1.6.! El diseño de cada aplicación debe estar orientado a explotar las características propias de cada plataforma.

5.2.2.! La accesibilidad de las aplicaciones deberá:

5.2.2.1.! Ser fáciles de utilizar

5.2.2.2.! Poder ser usado por personas sin experiencia en sistemas.

5.2.2.3.! Poder ser utilizado por personas con capacidades cognitivas y físicas diferentes

5.2.3.! Los usuarios deberán contar con la posibilidad de poderse registrar. Los mecanismos de registro serán al menos:

5.2.3.1.! Cuentas de redes sociales

5.2.3.2.! Usuario y Contraseña mediante un Single Sign On

5.2.4.! Buscador asistido

Las aplicaciones deberán contar con un módulo de búsquedas asistidas, por medio del cual le facilite el proceso al ciudadano.


INT010509RB0!!



Página 19 de 11

5.2.4.1.! El buscador deberá ser capaz de consultar múltiples fuentes de datos al mismo tiempo, tales como:

5.2.4.1.1.! Respuestas a solicitudes públicas a nivel nacional

5.2.4.1.2.! Obligaciones de transparencia a nivel nacional

5.2.4.2.! Los resultados de las búsquedas deberán:

5.2.4.2.1.! Ser mostrados por relevancia

5.2.4.2.2.! Poder ser ordenados, de acuerdo a varios criterios

5.2.4.2.3.! Contar con opción de refinamiento

5.2.4.2.4.! Descargar el resultado de la búsqueda o enviarla por correo en su estructura nativa.

5.2.4.2.5.! Brindar sugerencias de búsquedas alternativas

5.2.4.3.! El buscador deberá contar al menos con la siguiente funcionalidad:

5.2.4.3.1.! Deberá dar sugerencias

5.2.4.3.2.! Considerar faltas de ortografía

5.2.4.3.3.! Uso de sinónimos y Tesauro

5.2.4.3.4.! Ayuda e información más buscada, más reciente o más relevante.

5.2.4.3.5.! En campos de texto contar con autocomplete

5.2.4.3.6.! Deberá reconocer como parte de las opciones de búsqueda con operadores lógicos para facilitar las búsquedas que realicen los usuarios.

5.2.4.3.7.! Deberá incluir la funcionalidad de “nube de palabras”


INT010509RB0!!



Página 20 de 11

5.2.4.3.8.! Contar con la lógica del algoritmo C4.5 o similar para el armado de árboles de decisión

5.2.4.3.9.! Estadísticas de:

5.2.4.3.9.1.! Uso

5.2.4.3.9.2.! Palabras o frases más buscadas

5.2.4.3.9.3.! Por hora, día

5.2.4.3.9.4.! Consultas por dirección IP

5.2.4.3.9.5.! Otras

5.2.5.! Solicitud de información, Protección de datos personales (ARCO) y Recurso de Revisión (Queja)

Por medio de las aplicaciones, cualquier ciudadano deberá poder realizar solicitudes de información pública, protección de datos personales (ARCO) y Recursos de Revisión (Queja). Las características y funcionalidades de este módulo son:

5.2.5.1.! Proveer interfaces y formularios de captura dirigidos e inteligentes, por medio de los cuales deberá:

5.2.5.1.1.! Ser simples y sencillos de utilizar, siguiendo los lineamientos de usabilidad y accesibilidad previamente definidos.

5.2.5.1.2.! Simplificar la solicitud de información y/o protección de datos personales (ARCO) en no más de 5 pasos, así como la interposición del recurso de revisión donde este último podrá ser interpuesto además por un tercero. (Usuario distinto al que realizó la solicitud de información)


INT010509RB0!!



Página 21 de 11

5.2.5.1.3.! Orientar al usuario para hacer solicitudes o interponer recursos de revisión, lo más específicos y bien formados posibles mediante el asistente (Wizard).

5.2.5.1.4.! Mostrar información adicional relevante, tales como solicitudes más comunes u opciones adicionales que puedan responder al usuario sin necesidad de emitir una solicitud formal.

5.2.5.1.5.! Considerar la posibilidad de emitir solicitudes de protección de datos (ARCO)

5.2.5.1.6.! Considerar la posibilidad de emitir la solicitud a diversos sujetos obligados que se adhieran a la plataforma de forma simultanea (Solicitudes a Múltiples Sujetos Obligados)

5.2.5.2.! Proveer un panel de seguimiento que permita al usuario visualizar el estado de cada una de las solicitudes que haya solicitado en los sistemas Infomex que se adhieran a la plataforma, así como interponer un recurso de dichas solicitudes, si se cumplieran las reglas establecidas para hacerlo.

5.2.5.3.! Solicitud Asistida (wizard):

5.2.5.3.1.! Reducir la generación de solicitudes de información innecesarias cuando se puede obtener información que ya es pública de solicitudes similar o porque la información ya fue publicada por la Dependencia o Entidad de Gobierno con anterioridad o porque la búsqueda es referente a algún trámite o servicio al cual lo podremos referir, entre otras causas.

5.2.5.3.2.! Encontrar rápida y fácilmente la información que busca sin necesidad de generar una nueva solicitud.

5.2.5.3.3.! Utilización de algoritmos como C4.5 que permitan generar árboles de decisión dinámicos para facilitar el acceso de información mediante presentación de lista de sugerencias.

5.2.5.3.4.! Si el usuario desea seguir adelante, el Asistente (Wizard) lo llevará de la mano para redactar y enviar una solicitud donde una sola pregunta se dirija a uno o varios


INT010509RB0!!



Página 22 de 11

sujetos obligados. (Solicitudes a Múltiples Sujetos Obligados).

5.2.5.3.5.! El usuario también podrá adjuntar uno o varios archivos que refuercen su solicitud donde el tamaño autorizado para cada archivo o la suma de los mismos sea parametrizable para cubrir las distintas reglas de negocio existentes entre los distintos sistemas Infomex

5.2.5.4.! Solicitud Avanzada

5.2.5.4.1.! Simplificar la solicitud de información y/o protección de datos personales (ARCO) en no más de 5 pasos, así como la interposición del recurso de revisión donde este último podrá ser interpuesto además por un tercero. (Usuario distinto al que realizó la solicitud de información).

5.2.5.4.2.! Agilizar el proceso de solicitud y de respuesta logrando que la interface ayude al usuario a ordenar sus ideas y a dividir adecuadamente las preguntas a cada uno de los sujetos obligados involucrados al mismo tiempo que podrá adjuntar uno o varios archivos ligados a la pregunta específica o a toda la solicitud de tal forma que cuando esta llegue a cada uno de los sujetos obligados en cuestión, el personal asignado a responderla, tenga una idea muy clara de que se le solicita (general y particularmente) y pueda responder rápidamente.

5.2.6.! Alertas

Dado que el principal objetivo de la solución es la de permitir realizar solicitudes de información pública, el ciudadano deberá ser alertado cuando una solicitud sea resuelta o requiera de la atención del usuario. Por tal motivo, deberá existir un módulo de alertas que permita la siguiente configuración:

5.2.6.1.! Emisión de alertas vía SMS

5.2.6.2.! Emisión de alertas vía correo electrónico

5.2.6.3.! Publicación de un mensaje vía Portal Nacional de Transparencia


INT010509RB0!!



Página 23 de 11

5.2.6.4.! Emisión de alertas vía twitter

5.2.6.5.! Emisión de alertas a través de las aplicaciones móviles a desarrollar mediante mecanismos Push Notifications

5.2.7.! Noticias y socialización de la información

Las aplicaciones deberán contar con funcionalidades de administración de contenido y redes sociales, de forma que permita realizar las siguientes actividades:

5.2.7.1.! Mostrar noticias que los sujetos obligados puedan publicar con base en criterios de relevancia, caducidad, temporalidad.

5.2.7.2.! Mostrar indicadores estadísticos relevantes con base en la información contenida en el portal.

5.2.7.3.! Socializar información, permitiendo a los usuarios compartir y comentar información del portal en diferentes redes sociales

5.2.8.! Requisitos adicionales a la Funcionalidad

La solución entregada deberá contar con los siguientes componentes de arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio:

5.2.8.1.! Deberá estar totalmente integrada a los demás componentes tecnológicos de la solución, garantizando su compatibilidad para lograr agilidad en la ejecución de cambios y mantenimientos.

5.2.8.2.! Interfaz intuitiva.- Deberá considerar las guías de diseño de cada plataforma (e.g. Android, iOS, Windows Phone) para poder tener la mejor experiencia de interfaz en cada uno de estos dispositivos.

5.2.8.3.! Proveer la capacidad de calificar la utilidad de la información aquí contenida y presentada, basándose en el esquema de “estrellas” utilizado en redes sociales. Esta información será de uso exclusivo para el Instituto.

5.3.!Flujos de trabajo y Atención

Este módulo, fundamental para el sistema, será quien se encargue de generar, administrar y controlar todos los procesos de las solicitudes generadas, así como generar las alertas y notificaciones necesarias


INT010509RB0!!



Página 24 de 11

5.3.1.! Administración y publicación de formularios

Contar con un servicio que facilite el desarrollo de formas electrónicas para la captura y asociación a flujos de trabajo:

5.3.1.1.! Creación y publicación de formas electrónicas.

5.3.1.2.! Asociación a flujos.

5.3.1.3.! Manejo de versiones, de forma en que un cambio en una forma o flujo, no afecte los procesos que se encuentran en ejecución

5.3.2.! Flujo de solicitudes de información, protección de datos personales (ARCO), gestión interna y recursos de revisión

Cada proceso debe contar con un flujo asociado que deberá estar totalmente integrado y administrado por una solución que contenga:

5.3.2.1.! Diseño e implementación de los flujos por medio de una vista gráfica y una básica, permitiendo a expertos y usuarios con conocimientos del proceso de negocio, poder representar los pasos a seguir.

5.3.2.2.! Ejecución y administración. Los flujos deberán poder realizar las siguientes actividades:

5.3.2.2.1.! Podrán ser ejecutados desde los formularios.

5.3.2.2.2.! Podrán ser ejecutados desde otros medios o sistemas.

5.3.2.2.3.! Podrán ejecutar diferentes tareas.

5.3.2.2.4.! Podrán contar con flujos asociados y sincronizarlos, para el caso en que una solicitud sea competencia de varios sujetos obligados.

5.3.2.2.5.! Podrán definirse tiempos promedio de resolución, con el fin de asignar notificaciones y alertas en caso de que dichos tiempos no se cumplan.

5.3.2.2.6.! Podrán ser revisados y reiniciados manualmente en caso de errores no esperados.

5.3.3.! Filtrado de solicitudes

Siendo uno de los escenarios más comunes, la solución deberá permitir el filtrado de solicitudes:


INT010509RB0!!



Página 25 de 11

5.3.3.1.! Permitir el filtrado de información por Institución o agrupación de instituciones.

5.3.3.2.! Los flujos pueden ser respondidos y cerrados, tanto de forma manual, como de forma automática, en caso de que las reglas de negocio así lo determinen.

5.3.3.3.! Los flujos cerrados de esta manera generan respuestas al ciudadano y dejan los registros correspondientes

5.3.4.! Notificaciones y alertas para solicitudes y procesos

El sistema deberá poder emitir notificaciones y alertas:

5.3.4.1.! La solución deberá permitir el envío de notificaciones automáticas definidas mediante reglas de negocio, ante eventos y cambios de estatus o cumplimiento o número de fechas predeterminadas en el proceso.

5.3.4.1.1.! Las notificaciones deberán poder dirigirse a cualquiera de los involucrados en el caso correspondiente e incluso a más de una parte simultáneamente.

5.3.4.1.2.! La notificación podrá consistir en un correo electrónico, en cuyo cuerpo se integra un texto predefinido con contenido HTML más la información variable correspondiente.

5.3.4.1.3.! Las notificaciones se podrán enviar como liga de acceso a los documentos y como archivo adjunto, considerando mecanismos de seguridad que solo permitan el acceso al documento notificado, mediante el uso de usuario, contraseña y certificado digital.

5.3.4.1.4.! Las notificaciones y alertas pueden ser tareas específicas asignadas en los flujos de trabajo.

5.3.4.1.5.! Las notificaciones y alertas pueden ser generadas fuera de los flujos, en caso de que los tiempos promedio de respuesta no se cumplan o surjan errores no esperados.


INT010509RB0!!



Página 26 de 11

5.3.4.1.6.! Las notificaciones y alertas deben ser bajo la forma de:

5.3.4.1.6.1.! Correos

5.3.4.1.6.2.! SMS

5.3.4.1.6.3.! Portal Nacional de Transparencia

5.3.4.1.6.4.! Emisión de alertas vía twitter

5.3.5.! Consulta y seguimiento al estado de los flujos

La plataforma deberá contar con herramientas de reporteo y visualización de solicitudes:

5.3.5.1.! Consulta de información por Institución o agrupación de instituciones que se adhieran a la plataforma.

5.3.5.2.! Visualización de los flujos en sus diferentes estados.

5.3.5.3.! Emisión de alertas y notificaciones vía correo electrónico, twitter y SMS.

5.3.5.4.! Manejar diferentes niveles de permisos, pudiendo filtrarse por diferentes niveles jerárquicos.

5.3.5.5.! Posibilidad de crear reportes específicos.

5.3.6.! Procesos a implantar

Se implementarán los siguientes flujos a nivel general

5.3.6.1.! Proceso de atención simplificado de solicitudes de información o protección de datos (ARCO)

5.3.6.2.! Proceso de atención simplificado de recursos de revisión y afirmativa ficta

5.3.6.3.! Proceso de gestión interna para la atención de solicitudes de información


La solución deberá contar con los siguientes componentes de arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio:


INT010509RB0!!



Página 27 de 11


5.3.7.2.! Capacidad de envío de notificaciones a las entidades involucradas mediante correos electrónicos, SMS o a través del portal.

5.3.7.3.! Capacidad de almacenamiento y tratamiento de información y evidencias en las diferentes etapas del proceso.

5.3.7.3.1.! El Sistema deberá permitir ingresar y almacenar los diferentes documentos digitales, notas, pruebas y evidencias presentados durante las diferentes etapas del proceso. Esta información deberá ser almacenada en el sistema de manera integrada con el Administrador Empresarial de Contenido.

5.3.7.3.2.! Proveer esquemas de colaboración entre los involucrados.

5.3.7.3.3.! Mantener un histórico de la información o documentos utilizados en el proceso.

5.3.7.4.! Capacidad de generar Flujos de trabajo asíncronos para la resolución de solicitudes de información.

5.3.7.5.! Interfaz para Dispositivos móviles, Tableta, Teléfonos inteligentes, Escritorio y Web.

5.3.7.6.! Motor para el manejo de Flujos de Trabajo síncrono y asíncrono.

5.3.7.7.! Capa de integración basada en servicios web.

5.3.7.8.! Front-end de captura, seguimiento y cierre de Solicitudes basadas en flujos de trabajo, con soporte a Multibrowser.

5.3.7.9.! Reporte y Monitoreo del Estatus de Solicitudes Ingresadas.

5.3.7.10.! Filtro de Solicitudes competentes.

5.3.7.11.! Búsqueda y localización de solicitudes, configurables por campos y por búsquedas en contenidos.

5.3.7.12.! Detección de solicitudes, personas, entidades, solicitudes duplicadas


INT010509RB0!!



Página 28 de 11

5.3.8.! Integración con fuentes internas

Por medio de esta funcionalidad, se deberá operar la solicitud de información con los sujetos obligados. La funcionalidad incluye:

5.3.8.1.! Establecer comunicación con fuentes internas.

5.3.8.2.! Emitir solicitudes de información por medio de interfaces bien definidas.

5.3.8.3.! Recibir y procesar las respuestas, pudiendo ser necesario transformarlas para adaptarlas a las necesidades del resto de la solución.

5.3.8.4.! Manejar los errores esperados e inesperados, manteniendo esquemas de reintento y encolamiento

5.3.9.! Integración con el generador de flujos

Los procesos de integración deberán poder ser invocados y administrados desde el motor de flujos de negocio

5.4.! Búsquedas Federadas de información

Se deberá proporcionar un mecanismo de búsqueda de información contenida en la ejecución de los procesos de solicitudes y los archivos adjuntos asociados. Por gestión de conocimiento en el alcance de este proyecto se entiende como la capacidad de la aplicación informática para permitir la explotación, relación e integración de la información obtenida de manera tal que permita: identificar, obtener y explotar el conocimiento de lo sucedido durante la gestión de los procesos de solicitud de información y publicación de obligaciones de transparencia.

5.4.1.! Búsquedas federadas en bases de datos y repositorios documentales internos y externos

Por medio de esta funcionalidad, se deberá permitir búsquedas federadas que permita:

5.4.1.1.! Proporcionar modo de limitar las búsquedas a un conjunto concreto de resultados de búsqueda.


INT010509RB0!!



Página 29 de 11

5.4.1.2.! Las fuentes de resultados se crean y se usan para especificar una ubicación desde la cual obtener resultados de búsqueda y para especificar un protocolo para obtener dichos resultados.

5.4.1.3.! Establecer comunicación con fuentes externas.

5.4.1.4.! Realizar búsquedas flexibles por cualquier campo o atributo del sistema.

5.4.1.4.1.! El sistema deberá ofrecer una estructura interna de búsqueda de información extremadamente flexible basada en índices.

5.4.1.4.2.! Deberá ser posible definir mediante configuración, búsquedas basadas en cualquier campo o atributo de los objetos de negocios del sistema


La solución entregada deberá contar con los siguientes componentes arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio:


5.4.2.2.! Soporte múltiples tipos de búsquedas, incluyendo búsqueda contextual, búsqueda fonética, y búsqueda de gente y conocimientos.

5.4.2.3.! Que tenga capacidad de extraer entidades de texto de la información, a discreción del usuario, en el proceso de indexación.

5.4.2.4.! Que tenga la capacidad de generar refinadores de búsqueda a partir de cualquier atributo de la información, por elección del cliente.

5.4.2.5.! Que a la interface de búsqueda pueda aplicarse un diseño de búsqueda a discreción del usuario.

5.4.2.6.! Que permita obtener reportes de consulta de:

5.4.2.6.1.! Consultas con éxito más frecuente.

5.4.2.6.2.! Consultas con cero resultados.


INT010509RB0!!



Página 30 de 11

5.4.2.6.3.! Consultas en las que el usuario haya seleccionado un elemento.

5.4.2.6.4.! Consultas en las que el usuario no seleccionó ningún elemento.

5.4.2.7.! Análisis del contenido y la interacción del usuario.

5.4.2.8.! Reglas de consulta.

5.4.2.9.! Que permita integrarse con herramientas de terceros para la integración de taxonomías, ontologías y otras herramientas lingüísticas.

5.4.2.10.! API de consulta que permita integrar la herramienta a otras aplicaciones.

5.4.2.11.! Reglas de Consulta que permitan búsquedas federadas a otras fuentes de información o bloques de resultados

5.5.!Repositorio de Datos de transparencia

El repositorio de información concentra todos los datos relevantes dentro del sistema. Así mismo, provee los mecanismos necesarios para el control de flujos, registro y almacenamiento de información estadística.

La plataforma en su capa de datos y almacén de datos debe cumplir con las siguientes funciones:

5.5.1.! Gestión documental

El sistema deberá ser capaz de almacenar documentos relevantes para el sistema:

5.5.1.1.! Almacenamiento de los contenidos documentales generados en los procesos y accesibles desde los procesos.

5.5.1.2.! Soporte para grandes volúmenes de archivos. Se debe considerar que el Administrador Empresarial de Contenido cuente con los requerimientos tecnológicos y con la capacidad para manejar la información documental contenida sin que desmejore su rendimiento.

5.5.1.3.! Soporte para el ciclo de vida de documentos (resguardo, acceso, destrucción, control de versiones).

5.5.1.4.! Soportar diferentes formatos y tipos de documentos



INT010509RB0!!



Página 31 de 11

La solución entregada deberá contar con los siguientes componentes de arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio:


5.5.2.2.! Capacidad de analizar y mejorar el plan de ejecución mediante el uso de herramientas de sugerencia de desempeño integradas a la plataforma.

5.5.2.3.! Capacidad de diagnosticar el desempeño de la base de datos utilizando trazas y vistas administrativas integradas a la plataforma.

5.5.2.4.! Cifrar los datos que residen en la base de datos empleando algoritmos de cifrado estándares de industria, como lo son DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, 256-bit AES.

5.5.2.5.! Contar con la capacidad de restringir el acceso a la base de datos según políticas de acceso.

5.5.2.6.! Proteger la privacidad y confidencialidad de la información eliminando la posibilidad de pérdida de información, robo y acceso no autorizado.

5.5.2.7.! Enviar la traza de auditoría hacia una bitácora de sistema, de seguridad o a una localidad remota.

5.5.2.8.! Permitir la definición de registros de auditoría a nivel granular de manera integrada en la gestión de la base de datos, permitiendo auditar consultas, modificaciones, actualizaciones, entradas, salidas; todo esto a nivel de Base de Datos, esquema, tabla.

5.5.2.9.! Permitir el crecimiento de la solución de forma modular de acuerdo a las necesidades del INAI.

5.5.2.10.! Contar nativamente con funcionalidades de compresión de datos almacenados a través de software.

5.5.2.11.! Capacidad de conectarse con herramientas que ejecuten algoritmos predictivos como: Árbol de decisión, Regresión Lineal entre otros.

5.5.2.12.! Ser compatible con software ETL


INT010509RB0!!



Página 32 de 11

5.5.2.13.! Ser compatible con soluciones de Inteligencia de Negocios (BI)

5.5.2.14.! Permitir la carga de datos en tablas a partir de archivos vía una herramienta de carga optimizada de la solución.

5.5.2.15.! Permitir el monitoreo de la utilización de la Base de Datos en periodos de uso normal y de pico para identificar, diagnosticar y resolver problemas de desempeño

5.6.!Conexión a Red Social

La plataforma deberá contar con conexiones a redes sociales para notificar y publicar información de interés social

5.6.1.! Conexión a redes sociales

5.6.1.1.! Capacidad para compartir (share) información en redes sociales


La solución entregada deberá contar con los siguientes componentes arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio:


5.6.2.2.! Capacidad de completar y agregar campos de información adicional en el Perfil.

5.6.2.3.! Capacidad de cargar desde/hacia datos del perfil de usuario a fuentes de datos ya existentes (LDAP, Bases de Datos, Archivos).

6.! Requerimientos no funcionales

6.1.!Seguridad

La solución deberá ser completamente confiable, segura y escalable, por lo que debe cubrir estos aspectos desde su concepción arquitectónica, así como utilizar e implementar productos de administración y operación tanto de la solución como de los códigos y configuraciones fuente

6.1.1.!Seguridad


INT010509RB0!!



Página 33 de 11

Si bien la información contenida en el portal es pública, eso no implica que la plataforma no debe ser totalmente segura y confiable. Por este motivo, La arquitectura de la plataforma debe de contar con procesos, artefactos y mecanismos para la mitigación de amenazas:

6.1.1.1.! Suplantación de identidades:

6.1.1.1.1.! Evitar que usuarios, por error o por dolo, aparente ser otro usuario o tome la identidad de uno previamente registrado.

6.1.1.2.! Falsificación:

6.1.1.2.1.! La información presente en el portal debe contar con un estricto mecanismo de acceso, pudiendo ser vista, modificada e incluso borrada solo por los actores. Ningún actor no autorizado puede modificar la información contenida en el portal.

6.1.1.2.2.! La información no puede ser borrada físicamente. En caso de ser requerido, esta puede únicamente ser borrada lógicamente

6.1.1.3.! No Repudiación:

6.1.1.3.1.! Todas las operaciones dentro del portal, deberán estar adecuadamente autorizadas y registradas.

6.1.1.3.2.! Las operaciones realizadas por ciudadanos deben ser registradas con base en el mecanismo de autenticación que hayan elegido.

6.1.1.3.3.! Las operaciones realizadas por Servidores Públicos, incluidos aquellos del INAI, deberán ser registradas con base en una autenticación por firma electrónica.

6.1.1.3.4.! Todas las operaciones deberán dejar un registro de quien, cuando y que acción correspondió con dicha operación

6.1.1.4.! Revelar información:

6.1.1.4.1.! Se debe tener especial cuidado en no revelar ni compartir información proporcionada por los ciudadanos, bajo los términos y lineamientos de la Ley Federal de Protección de Datos Personales en Posesión de Particulares (LFPDPPP)

6.1.1.5.! Negación de servicio:


INT010509RB0!!



Página 34 de 11

6.1.1.5.1.! La plataforma debe ser altamente escalable y deberá contar con monitoreo continuo y esquemas de protección contra ataques de negación de servicio.

6.1.1.6.! Elevación de privilegios

6.2.!Gestión de Identidad

Las operaciones realizadas en la solución deberán estar adecuadamente identificadas y asociadas a una persona, ya sea las solicitudes realizadas por ciudadanos como las operaciones efectuadas por servidores públicos. Por tal motivo, la plataforma deberá ser capaz de gestionar las identidades de quienes la utilicen.

6.2.1.!Gestión de identidades

La Plataforma deberá proporcionar mecanismos de autenticación para reconocer a las personas que realizan operaciones sobre la misma.

6.2.1.1.! Identidades de ciudadanos

6.2.1.1.1.! Los ciudadanos deberán autenticarse por alguna de las siguientes maneras:

6.2.1.1.1.1.! Credenciales de redes sociales (Facebook, Twitter, Google+)

6.2.1.1.1.2.! Creación de un usuario, por medio de un correo electrónico y una contraseña utilizando un single sign on.

6.2.1.1.1.3.! Uso de la FIEL

6.2.1.1.2.! Las identidades de los usuarios autenticados deben ser registradas y almacenadas para operaciones futuras.

6.2.1.1.2.1.! Particularmente, para algunos escenarios de consulta, se deberán solicitar y almacenar información adicional, tales como domicilio, teléfono. Dicha información se resguardará y se considerarán datos personales protegidos por la ley.

6.2.1.1.3.! Se proveerán funcionalidades adicionales a los usuarios autenticados tales como:

6.2.1.1.3.1.! Consultas sobre el estado y resultado de solicitudes realizadas,


INT010509RB0!!



Página 35 de 11

6.2.1.1.3.2.! Adecuaciones básicas al portal, donde el usuario podrá modificar el portal de forma en que muestre información que le parezca relevante.

6.2.1.1.3.3.! Envío de alertas y notificaciones a cuentas de correo o redes sociales

6.2.1.2.! Identidades de Servidores Públicos

6.2.1.2.1.! Los Servidores Públicos deberán acceder a la solución, por medio de la utilización de su firma electrónica (FIEL).

6.2.1.2.2.!

6.2.1.3.! Validaciones

6.2.1.3.1.! Las credenciales deberán de validarse, de acuerdo a su naturaleza

6.2.1.4.! Los Servidores Públicos deberán previamente ser autorizados por parte de un administrador del sistema, permitiéndoles el acceso y el tipo de operación que puedan realizar

6.3.!Bus de servicios empresariales (Conectividad e Interoperabilidad)

Intellego construirá o implementará un bus de servicios empresariales (ESB por sus siglas en inglés) que permita la conectividad e interoperabilidad de las distintas aplicaciones que se encuentran consideradas, ver imagen de arquitectura siguiente:


INT010509RB0!!



Página 36 de 11


INT010509RB0!!



Página 37 de 11

El ESB considerará:

6.3.1.! Los componentes de la capa de interoperabilidad deberán incluir:

6.3.1.1.! Arquitectura subyacente para integrar e intercambiar mensajes entre diferentes servicios, tanto dentro de la organización como con entidades externas.

6.3.1.2.! Recibir mensajes entrantes y enviar mensajes salientes.

6.3.1.3.! Analizar mensajes recibidos para identificar sus formatos concretos.

6.3.1.4.! Evaluar el contenido del mensaje para determinar cómo se encaminará y procesará.

6.3.1.5.! Entrega los mensajes a sus destinatarios.

6.3.1.6.! Registra el estado de los documentos

6.3.1.7.! Deberá proveer una plataforma central para comunicarse con cualquier aplicación requerida sin ligar al receptor del mensaje con el que envía el mensaje.

6.3.1.8.! Deberá contar con la capacidad de integrar de forma transparente a través de diferentes protocolos de transporte tales como HTTP(s), JMS, FTP, SMTP, TCP.

6.3.1.9.! Determinará el destino de los mensajes entrantes.

6.3.1.10.! En relación a la seguridad, el ESB deberá autenticar, autorizar, y contar con funcionalidad de encriptación para asegurar los mensajes entrantes y salientes.

6.3.1.11.! Deberá contar con un ambiente de monitoreo y administración del ESB para configurarlo, que sea confiable y tenga un alto desempeño; al mismo tiempo, nos deberá permitir monitorear la ejecución de los mensajes y su flujo dentro del ESB.

6.3.1.12.! El ESB deberá ser robusto y escalable para gestionar grandes volúmenes de mensajes de manera rápida, fiable y con suficiente margen para el crecimiento futuro, así como garantizar alta disponibilidad para obtener el funcionamiento ininterrumpido de la plataforma nacional de transparencia.

6.3.1.13.! Simplificar y automatizar la interoperabilidad, reduciendo costos de operación y mantenimiento y evitando errores.


INT010509RB0!!



Página 38 de 11

6.3.1.14.! Documentos de Definición de estándares y procedimientos entre el INAI y las instituciones, basado en estándares de comunicación abiertos

6.4.!Implementación de nueva funcionalidad

6.4.1.!Tramos de administración

Actualmente la herramienta contempla tramos de administración donde intervine un administrador de órgano garante, administradores de sujetos obligados y usuarios de unidades administrativas a diferentes niveles, será necesario desarrollar la funcionalidad suficiente para incorporar un nuevo elemento al tramo de administración, este se encontrará en el primer nivel y será denominado administrador de entidades federativas, este nuevo tramo de administración permitirá realizar la administración del catálogo de entidades federativas, catálogo de sectores y de usuarios para cada entidad.

El nuevo tramo de administración quedará de la siguiente manera: administrador de entidades federativas, administrador de entidad, administrador de sujeto obligado y administrador de unidad administrativa.

Cabe mencionar que cada entidad federativa configurará sus procedimientos de acuerdo a la normatividad emitida en dicha entidad.

El identificador de entidad federativa deberá permitir determinar a lo largo de los procedimientos configurados en el BPM la pertenencia de cada uno de los elementos configurados o gestionados.

Deberá existir la funcionalidad para asignar distintos perfiles de acceso a cada usuario de la plataforma para delimitar el rol en cada uno de los sistemas contenidos en la misma, desarrollar el concepto de Single Sign On.

6.4.2.!Módulo de Tablero de Control

La herramienta deberá considerar un mecanismo que permita extraer información estadística y depositarla en tablas resumen, con la finalidad de construir un tablero de control que apoye la toma de decisiones, a través de semáforos, gráficos de barras y alertas a los usuarios de las entidades federativas, sujetos obligados y unidades administrativas, en el seguimiento a los procedimientos y los pasos que les son asignados dentro del flujo de trabajo que se configure en el BPM.

Dicho mecanismo deberá ser totalmente configurable y cada entidad federativa será responsable de su parametrización de acuerdo a la configuración de los procedimientos establecidos.

Los rubros considerados a ser graficados son los siguientes:


INT010509RB0!!



Página 39 de 11

Procedimientos registrados, procedimientos en trámite, procedimientos concluidos y gestión interna de procedimientos.

Cabe mencionar que las gráficas mostrarán información relacionada con el alcance del usuario que está ingresando al módulo, es decir, dependiendo del perfil del usuario se mostrará la información de su competencia.

Así mismo, la herramienta deberá considerar como primer filtro para mostrar la información un periodo de tres meses anteriores a la fecha actual, esto con la finalidad de no afectar el desempeño de la herramienta.

a)! Procedimientos registrados (totalidad de solicitudes, recursos de revisión y recursos de inconformidad)

Gráfica de barras con el número de procedimientos registrados distribuidos por año, el dar clic sobre alguna de las barras permitirá mostrar una nueva gráfica de barras con el detalle del año seleccionado distribuyendo los procedimientos registrados por mes, este mecanismo se utilizará para mostrar información por semana del año y en la última gráfica por día, al dar clic sobre una barra de día, la aplicación mostrará una tabla con todos los procedimientos registrados en el día seleccionado donde se podrá visualizar el número de folio, la fecha de registro, entidad federativa, sujeto obligado y el nombre del particular.

Los filtros adicionales que deberá contemplar esta gráfica serán: sector, entidad federativa, sujeto obligado, nombre del particular y periodo, las opciones de filtrado se descartarán de acuerdo al alcance del usuario registrado.

b)! Procedimientos en trámite (Con fecha de registro y sin fecha de conclusión)

Grafica de barras apiladas con colores de semáforo, se requiere que cada nivel de usuario (administrador general, administrador de entidad federativa y administrador de sujeto obligado) tenga la opción de configurar el número de días para cada uno de los tres rangos (rojo, amarillo y verde), cuando el usuario dé clic sobre alguno de los colores será necesario mostrar la tabla con el listado de los procedimientos en trámite que corresponda, adicionalmente, se requiere que se implemente un mecanismo que alerte a los usuarios del tablero cuando un procedimiento pase de un rango a otro, esta alerta se debe realizar vía correo electrónico dependiendo de la configuración establecida por el usuario.

La tabla de detalle que se deberá mostrar al dar clic sobre alguno de los tres colores de semáforo de la gráfica contendrá la siguiente información: número de folio, fecha límite de atención, días


INT010509RB0!!



Página 40 de 11

naturales entre la fecha límite de atención y la fecha actual, en su caso, número de folios turnados a unidades administrativas, número de folios concluidos que fueron turnados a las unidades administrativas, vínculo a una tabla que muestre los folios turnados y generados para dicho procedimiento y nombre del solicitante, el orden para mostrar la información deberá ser de acuerdo a los días naturales entre la fecha límite de atención y la fecha actual de menor a mayor.

La tabla que contendrá el detalle de los folios turnados a las unidades administrativas debiendo mostrar la siguiente información: estado del folio (Pendiente o Concluido), número de folio, nombre de la unidad administrativa, fecha de turnado y en su caso fecha de respuesta.

Adicionalmente, será necesario identificar y configurar pasos clave de los procedimientos que podrán servir para construir gráficas comparativas, por ejemplo:

•! Se requiere construir una gráfica donde se muestren los procedimientos en trámite, contra los procedimientos en trámite donde se ha realizado una prevención, será necesario que cada administrador de entidad federativa identifique el paso del procedimiento que está relacionado con la prevención y lo configure en la herramienta para que de esta manera la aplicación construya en la tabla resumen un campo bandera (0,1) donde se identifique si un procedimiento se gestionó a través del paso de interés.

•! Otros ejemplos de este tipo de gráficas son: procedimientos en trámite contra procedimientos con ampliación de plazo, en las que se requirió pago, que fueron enviados al comité y por nombre del particular.

Los filtros adicionales que deberá contemplar las gráfica serán: sector, entidad federativa, sujeto obligado, nombre del particular y periodo, las opciones de filtrado se descartarán de acuerdo al alcance del usuario registrado.

c)! Procedimientos concluidos (fecha de conclusión)

Gráfica de barras apilada con dos elementos, el primero de ellos con el total de procedimientos concluidos y el segundo con el número de procedimientos en trámite.

La herramienta deberá mostrar el detalle de los procedimientos de cada bloque al dar clic sobre alguno de ellos en la gráfica, la tabla que contiene el detalle deberá visualizar los siguientes campos: número de folio, fecha de respuesta, tipo de respuesta, entidad federativa y sujeto obligado.


INT010509RB0!!



Página 41 de 11

Adicionalmente, será necesario identificar y configurar pasos clave de los procedimientos que podrán servir para construir gráficas comparativas como las mencionadas en el inciso anterior.

Los filtros adicionales que deberá contemplar esta gráfica serán: sector, entidad federativa, sujeto obligado, nombre del particular y periodo, las opciones de filtrado se descartarán de acuerdo al alcance del usuario registrado.

d)! Gestión interna de procedimientos

•! Este tipo de gráfica únicamente estará disponible para los administradores de entidad federativa, de sujeto obligado y de unidades administrativas.

•! La herramienta deberá generar gráficas de barras con el número de procedimientos que han sido turnados a las diferentes unidades administrativas que pertenecen a un sujeto obligado, al dar clic sobre alguna de las barras se deberá mostrar una tabla detalle con la siguiente información: folio, fecha de turnado, fecha de respuesta, y los días transcurridos entre las dos fechas anteriores.

•! La herramienta deberá generar gráficas de barras con el número de procedimientos que fueron asignadas a las diferentes unidades administrativas y que se encuentran pendientes de atención, al dar clic sobre alguna de las barras se deberá mostrar una tabla detalle con la siguiente información: folio, fecha de turnado, fecha de respuesta y los días transcurridos entre las dos fechas anteriores.

Los filtros disponibles para este tipo de gráficas deben considerar: sujeto obligado, unidad administrativa y periodo. Antes de mostrar información al administrador de entidad federativa, será necesario que el usuario seleccione a un sujeto obligado del catálogo.

En resumen el módulo de tablero de control deberá contar con:

•! Una sección de administración que permita configurar el nombre y correo electrónico de las personas que recibirán las alertas

•! Una sección de administración que permita configurar los rangos (rojo, amarillo y verde) que serán establecidos para la gráfica de semáforo.

•! Una sección de administración de gráficas para procedimientos en trámite y concluidos que permita identificar pasos clave del procedimiento configurados en el


INT010509RB0!!



Página 42 de 11

BPM, que habilitarán banderas en una tabla resumen y que indicarán que se crearán gráficas adicionales del procedimiento en trámite y concluido.

•! Una sección de despliegue de gráficas resultantes.

Adicionalmente, cuando se dé clic sobre el número de folio del procedimiento se deberá mostrar una página de detalle con información relevante del procedimiento.

6.4.3.!Módulo estadístico

La herramienta deberá contar con un módulo público que permita generar información estadística de los procedimientos establecidos.

Las opciones de consulta que se deberán considerar son:

•! Procedimientos iniciados

Con las siguientes opciones de filtrado:

a)! Entidad federativa

b)! Sector

c)! Sujeto obligado

d)! Rango de fechas

El resultado deberá ser agrupado por entidad federativa y sujeto obligado.

El módulo deberá permitir exportar la tabla resultante a formatos XLS, XML, CSV, TXT y JSON.

El módulo deberá permitir al administrador general de la Plataforma Nacional establecer el número de registros a exportar referido en el párrafo anterior.

•! Procedimientos iniciados a través del Centro de Atención a la Sociedad (CAS)


a)! Entidad Federativa

b)! Sector

c)! Sujeto obligado


INT010509RB0!!



Página 43 de 11

d)! Rango de fechas




•! Procedimientos en trámite



b)! Sector

c)! Sujeto obligado

d)! Rango de fechas


Adicionalmente, se deberá contar con una opción que permita mostrar el detalle de los procedimientos que se encuentran en trámite. La tabla de detalle deberá contener como mínimo la siguiente información: nombre de la entidad federativa, nombre del sujeto obligado, número de folio, fecha de registro, fecha límite de atención y número de días naturales entre la fecha actual y la fecha límite.



•! Procedimientos concluidos



b)! Sector

c)! Sujeto obligado


INT010509RB0!!



Página 44 de 11

d)! Tipo de respuesta

e)! Rango de fechas




Para la generación de las estadísticas solicitadas se deberá considerar un mecanismo que no afecte el desempeño de la base de datos, se podrán considerar tablas resumen de la información contienda en la base de datos de tal forma que no se requiera una gran cantidad de procesamiento para generar los resultados.

6.4.4.!Módulo de ampliación de plazo

El administrador de entidad federativa deberá ofrecer a través de la interfaz de usuario una opción que permita realizar ajustes a la fechas límites de atención de los diferentes procedimientos que se encuentren en trámite, dicho ajuste será motivado por una reconfiguración del calendario de días inhábiles, para realizar el ajuste será necesario que el proceso automatizado a construir considere el historial de la solicitud, el procedimiento configurado y el calendario de días inhábiles asignado al sujeto obligado para determinar con precisión el plazo que deberá ser asignado. El mecanismo establecido deberá permitir seleccionar a uno o más sujetos obligados para aplicar los ajustes necesarios cuidando siempre el desempeño óptimo de la aplicación.

6.4.5.!Módulo de configuración de calendarios

El administrador de entidad federativa deberá ofrecer a través de la interfaz de usuario una opción que permita configurar los calendarios de días inhábiles para cada uno de los sujetos obligados correspondientes, la configuración realizada será considerada para los cálculos de plazos que realizará la herramienta.

6.4.6.!Módulo de aplicación de pagos

El administrador de entidad federativa deberá ofrecer a través de la interfaz de usuario una opción que permita cargar y aplicar de manera masiva los pagos a los procedimientos en los que se ha realizado la reproducción de materiales en materia de transparencia, el reporte de números de folio de los procedimientos en los que se han pagado


INT010509RB0!!



Página 45 de 11

derechos será generado a través de una herramienta proporcionada por la institución bancaria designada para este efecto. El mecanismo automatizado de aplicación de pagos deberá cuidar que no se degrade el desempeño de la herramienta.

En la carga masiva de la información de los pagos deberá notificarse vía correo electrónico a la unidad de enlace del sujeto obligado correspondiente.

6.4.7.!Módulo de reportes

Deberá permitir generar reportes detallados de Solicitudes de Información, Recursos de Revisión y Recursos de Inconformidad por sujeto obligado de cada entidad federativa.

La generación del reporte deberá ser dinámico, permitiendo seleccionar los campos de información que genere el BPM.

El módulo deberá permitir exportar el reporte anual resultante a formatos XLS, CSV, TXT y JSON.

6.4.8.!Módulo de regreso de pasos

Módulo que deberá estar disponible para el administrador de entidad federativa, este módulo tendrá la funcionalidad de permitir al usuario regresar un procedimiento al paso indicado por la Unidad de Transparencia del sujeto obligado, cabe mencionar que los procedimientos serán configurados por cada una de las entidades federativas. Para ubicar el procedimiento en cuestión será necesario proporcionar al módulo el número de folio del procedimiento, como resultado de la búsqueda se mostrará una tabla con los números de folio coincidentes, para abrir la pantalla que muestre los pasos del procedimiento que han sido ejecutados por los diversos actores que intervienen en la gestión del procedimiento será necesario dar clic sobre el número de folio de interés, la pantalla que muestra los pasos de la gestión deberá permitir seleccionar únicamente un paso para posteriormente confirmar el regreso a través de un botón, solo se realizará una baja lógica de los pasos intermedios y será necesario registrar los nuevos pasos de la gestión. Los regresos de paso deberán registrarse en una bitácora que contenga información de la fecha, hora, motivo y usuarios que realizaron la acción.

6.4.9.!Módulo de seguimiento a gestión para los particulares

Módulo que deberá estar disponible para el particular, este módulo tendrá la funcionalidad de mostrar en un listado paginado, el estado actual que guardan los procedimientos iniciados por el particular, con la posibilidad de realizar búsquedas por número de folio del procedimiento, entidad federativa, sujeto obligado y/o periodo, la tabla a mostrar deberá contener la siguiente información: número de folio, fecha de


INT010509RB0!!



Página 46 de 11

registro, entidad federativa, sujeto obligado y estado que guarda el procedimiento al momento de la consulta.

6.4.10.! Módulo de tablero de control para el particular

Se deberán mostrar de manera gráfica los siguientes rubros.

a)! Número total de procedimientos (solicitudes de Información, recursos de revisión e inconformidad) registrados por el particular.

b)! Número total de procedimientos registrados por el particular y que se encuentran en trámite.

c)! Número total de procedimientos registrados por el particular y que han sido concluidos.

d)! Número total de procedimientos pendientes de atención por parte del particular.

Al dar clic sobre las gráficas la herramienta deberá mostrar el detalle de los procedimientos que se encuentran en cada caso.

6.4.11.! Asistente de registro de solicitudes de información

Se deberán realizar ajustes al asistente de registros de solicitudes de información pública y de datos personales de tal forma que permita registrar solicitudes a los diferentes sujetos obligados de las entidades federativas que pertenezcan a un sector previamente definido.

Así mismo, se deberá agregar un catálogo que permita identificar la procedencia de una solicitud de información (escrito material, correo electrónico, PNT, verbalmente o CAS).

6.4.12.! Bitácora de errores

La herramienta deberá llevar un registro de los errores que se presentan en la operación de la misma, dicho informe de errores deberá tener la opción de consultarse a través de la interfaz gráfica en el módulo del administrador de entidades federativas y deberá integrar la funcionalidad necesaria para exportar la información a formatos XLS, XML, CSV, texto y JSON.

La información mínima que deberá contener el reporte de errores es la siguiente: folio, fecha, hora, usuario, módulo donde se presenta el error, descripción del error presentado.

6.4.13.! Integración con redes sociales

Actualmente la herramienta emite alertas a través de mensajes SMS, correo electrónico, Portal Nacional de Transparencia y Twitter, sin embargo, será


INT010509RB0!!



Página 47 de 11

necesario incorporar funcionalidad que permita enviar alertas a través de mensajes privados en Facebook y Google+.

6.4.14.! Acceso al repositorio de datos por cada uno de los Órganos Garantes

Cada administrador de Entidad Federativa debe contar con acceso al repositorio de datos de transparencia (CM) existente en el sistema de solicitudes de información.

El acceso mencionado en el párrafo anterior debe estar limitado por Entidad Federativa, evitando que los administradores puedan contar con acceso a documentos de otra Entidad Federativa.

6.4.15.! Texto de la Solicitud y su respuesta editables

El administrador de la entidad federativa y el administrador del sujeto obligado deben contar con un módulo que les permita editar los campos de textos de las solicitudes, así como los de las respuestas para los casos de testeo de datos personales en solicitudes de información pública.

6.4.16.! Roles de usuario CAS para cada entidad federativa

La PNT debe contar con la funcionalidad necesaria para configurar perfiles de usuario tipo “CAS” para los casos donde cuentan con un Centro de Atención Telefónica (Call Center).

6.4.17.! Incluir la incorporación de código Captcha en la funcionalidad de logueo

Desarrollar en la funcionalidad de logueo de usuario a la PNT un código “Captcha” que permita evitar el alta o logueo de usuarios simulados por un robot y de esta manera evitar SPAM.

6.5.!Licenciamiento

Desarrollar la solución utilizando software libre u otro tipo de software, para el desarrollo y operación de este proyecto en tanto no se establezca requisitos de pago de licenciamiento, ni dependencia de la plataforma tecnológica sobre la que operará el sistema resultante, así como contemplar la entrega completa del código fuente y la titulación de la propiedad intelectual a nombre del INAI de todas las aplicaciones resultantes de este proyecto.

6.6.!Propiedad intelectual

El Instituto será propietario de los derechos de autor del software, configuraciones, documentos, patentes, estándares, modelos, interfaces y cualquier producto que se obtenga a partir de este proyecto.


INT010509RB0!!



Página 48 de 11

7.! Nuevo Sistema de Obligaciones de Transparencia

Actualmente se está considerando integrar mediante el bus de comunicación del sistema electrónico de solicitudes de información con el que cuenta el INAI, la funcionalidad existente en el portal de obligaciones de transparencia (POT) que a continuación se describe:

Conformando la Plataforma Nacional de Transparencia, el sistema de consulta de obligaciones de transparencia se sustentará en políticas y lineamientos que en su caso emita el Sistema Nacional de Transparencia, para la homologación de la información conformando de manera centralizada, estandarizada y organizada, la información necesaria que marcan las leyes en materia de transparencia, logrando mejorar la calidad del servicio que se ofrece a través de accesos libres a la información pública contemplando los mecanismos indispensables de usabilidad para que el público en general pueda utilizarlo de manera sencilla, amigable y clara.

Así mismo, dicho sistema, facilitará las tareas de evaluación en el cumplimiento de las obligaciones de transparencia marcadas por la Ley General de Transparencia y Acceso a la Información Pública y/o que de ella emanen. Además de la adaptación que tengan las mismas leyes.

Con el propósito de ofrecer a la ciudadanía en general un portal donde encuentre la información que generan los Sujetos Obligados, se desarrollará un portal de transparencia, denominado “Sistema de Portales de Obligaciones de Transparencia”, el cual será un medio electrónico para facilitar el acceso de manera estándar a la información pública obligatoria.

La aplicación es un sistema informático en el que se almacenará y organizará la información Obligatoria que la Ley General de Transparencia y Acceso a la Información Pública, así como de la Ley Federal de Transparencia y Leyes Locales de la Materia ordenen poner a disposición de los ciudadanos.

Objetivo General del Sistema

El Sistema de Portales de Obligaciones de Transparencia tiene como objetivo centralizar los servicios de Transparencia y Acceso a la Información Pública de los diferentes Sujetos Obligados, permitiendo a la ciudadanía y al público en general resolver sus necesidades de información de manera sencilla y ágil empleando las buenas prácticas en la materia.

Adicionalmente el Sistema ayudará a los Sujetos Obligados a cumplir puntualmente con las disposiciones, normatividad y obligaciones de transparencia que marca la Ley General de Transparencia y Acceso a la Información Pública, integrando la información de manera estandarizada. Asimismo facilitará las actividades para la evaluación del cumplimiento de la Ley por parte de los Sujetos Obligados.


INT010509RB0!!



Página 49 de 11

Objetivos específicos

•! Centralizar los servicios de Obligaciones de Transparencia. •! Resolver de manera sencilla y ágil las consultas de información de la ciudadanía y

público en general. •! Simplificar el cumplimiento puntual de las disposiciones, normatividades y

obligaciones de transparencia por parte de los Sujetos Obligados. •! Facilitar las actividades de evaluación del cumplimiento de la Ley por parte de

los Sujetos Obligados.

Requerimientos del Sistema

En este apartado se proporciona un listado de las funciones del sistema y un esquema, este último con el objetivo de mostrar de manera gráfica la organización de los requerimientos que ya se encuentran implementados en un sistema de información del cual será necesario realizar la validación de dicha funcionalidad.

La organización de los requerimientos se basa principalmente en cinco grupos:

1.! Portal, en este grupo se localizan aquellos que hacen referencia al acceso de la

ciudadanía y público en general a la información de transparencia e información del sistema “de consulta”.

2.! Integración de información, este grupo está integrado por aquellos que permitirán la incorporación de la información de transparencia al sistema.

3.! Evaluación de información, en este grupo se localizan los referentes a las funciones de evaluación de cumplimiento de obligaciones de transparencia.

4.! Administración del sistema, en este grupo se localizan aquellos que permitirán la configuración para la integración de información, evaluación, gestión de información histórica, así como la de aspectos particulares del sistema.

5.! Control de acceso, este grupo está integrado por aquellos que regularán el acceso a los diferentes usuarios del sistema.

A continuación se muestra el esquema de los requerimientos que ya están implementados en el sistema:


INT010509RB0!!



Página 50 de 11

Esquema de Requerimientos


INT010509RB0!!



Página 51 de 11

La siguiente tabla presenta el listado de los requerimientos del sistema “consulta de obligaciones de transparencia”:

NÚM. REQUERIMIENTO DESCRIPCIÓN

A.! 1. PORTAL

A.! 1.1 Información sobre el Sistema

A.! 1.1.1 El sistema mostrará el objetivo

A.! 1.1.2 El sistema mostrará los servicios que ofrece al público en general.

A.! 1.1.3 El sistema mostrará la Visión

A.! 1.1.4 El sistema mostrará los objetivos específico.

A.! 1.1.5

El sistema mostrará el listado de contactos para que los usuarios del Portal comuniquen sus dudas o comentarios.

Se consideran los siguientes datos para el listado: Nombre. Cargo. Teléfonos. Correo-electrónico. Domicilio. Área. Especialización en que puede responder a una duda o comentario

A.! 1.1.6

El sistema permitirá al usuario acceder a la información estadística del uso del Portal.

Las estadísticas, así como sus correspondientes despliegues, quedan sujetas a la disponibilidad de la información que proporcione la herramienta analítica de sitios Web (la cual podrá estar contenida en la herramienta del buscador).

A.! 1.1.7 El sistema presentará la ley de transparencia vigente

Los 3 formatos disponibles serán: •! Word (ver. 97-2003). •! HTML. •! PDF (ver. 6.0 o anterior).

A.! 1.1.8

El sistema presentará el listado (directorio) de los Sujetos Obligados y los vínculos a sus sitios Web.

Por cada Sujeto se presentará la siguiente información: •! Nombre del Sujeto. •! Logotipo (imagen). •! URL del Portal. •! Datos de la Unidad de Transparencia: nombre

completo del responsable, teléfono(s), correo electrónico.

•! Ubicación. •! URL del croquis de ubicación.

A.! 1.1.9 El sistema mostrará vínculos a otras

Los vínculos serán totalmente estáticos (no se contempla un catálogo para su gestión) y podrán


INT010509RB0!!



Página 52 de 11


aplicaciones relacionadas con el tema de transparencia del Distrito Federal.

mostrarse a través de una imagen y una leyenda alusiva, se mostrarán en el lado derecho del Portal.

A.! 1.1.10

El sistema presentará el resultado de las evaluaciones de los Sujetos Obligados

El resultado se compone de un listado de todos los Sujetos Obligados con su nombre y sus respectivas calificaciones (resultado final, es decir, el índice global del cumplimiento de las obligaciones de transparencia) de las evaluaciones del ejercicio actual y de dos ejercicios anteriores (mostrando únicamente la calificación global de cada evaluación), ordenados de manera descendente por el resultado de la última evaluación. El listado de Sujetos Obligados se presentará en grupos de 10. Adicionalmente se podrá consultar el detalle de todas las evaluaciones a nivel de fracción (siempre y cuando no se hubiera modificado la ley ni la metodología de evaluación).

A.! 1.1.11

El sistema proporcionará al usuario ayuda en línea sobre el uso del Portal.

La ayuda en línea estará disponible a través de los siguiente mecanismos: •! Guía de usuario en formato PDF. •! Guía de usuario en formato HTML. •! Tutorial en línea de las secciones más

importantes del uso del Portal. La ayuda en línea será estática, es decir no se contempla un módulo para su mantenimiento, por lo que para actualizarlos será directamente en el servidor donde se encuentren residentes dichos archivos.

A.! 1.2 Consulta de información de transparencia

A.! 1.2.1 El sistema permitirá consultar la información de transparencia de acuerdo con los años configurados en la estructura de la normatividad por cada artículo y fracción.

A.! 1.2.2

El sistema permitirá consultar la información de transparencia por artículo y fracción.

Una vez elegido el artículo y fracción, se seleccionará el tipo de búsqueda a realizar: •! Todos los Sujetos Obligados.

•! Clasificación (Órgano).

•! Sub-clasificación (Categoría).

•! Por un Sujeto Obligado específico.


INT010509RB0!!



Página 53 de 11


•! Formato (Tópico). Sólo en el caso de que el artículo y/o fracción tenga más de un formato asociado.

El sistema mostrará el listado de información general de acuerdo a los datos seleccionados de los formatos.

A.! 1.2.3

El sistema permitirá consultar la información de transparencia por Sujeto Obligado.

Una vez elegido el Sujeto Obligado, se deberán seleccionar los siguientes criterios: •! Tema.

•! Subtema.



A.! 1.2.4

El sistema permitirá consultar la información de transparencia por tema.

Una vez elegido el tema, se deberán seleccionar los siguientes criterios: •! Subtema.


•! Sub-clasificación (Categoría).

•! Sujeto Obligado.



A.! 1.2.5

El sistema permitirá mostrar el detalle de cada uno de los registros de los listados de información general obtenidos en las consultas por Artículo y Fracción, por

El sistema mostrará toda la información del formato, así como el acceso a los documentos adjuntos del registro.


INT010509RB0!!



Página 54 de 11


Sujeto, por Tema y Subtema.

A.! 1.2.6

El sistema permitirá realizar consultas horizontales a la información de transparencia de los Sujetos Obligados, solamente aplica en el caso de las consultas por Artículo y Tema.

La información podrá mostrarse acorde a las siguientes opciones: •! Todos los Sujetos Obligados.


A.! 1.2.7

El sistema permitirá exportar los datos de los listados de información general para las consultas por Artículo y Fracción, por Sujeto y por Tema y Subtema, consideradas en los puntos anteriores, a un archivo en formato Excel (ver. 97-2003).

Sólo se exportarán los datos mostrados en el listado de información general que arroja la consulta.

A.! 1.3 Buscador

A.! 1.3.1

El sistema tendrá integrada una herramienta especializada en indexar y realizar búsquedas de grandes cantidades de información en forma rápida y sistematizada, de acuerdo a palabras o frases usadas como criterios de búsqueda y sus coincidencias en cada documento.

Los requerimientos para esta herramienta dependerán de las características y capacidades del software que se seleccione, por lo que en este documento únicamente se enlistan elementos que deberán considerarse para dicha herramienta.

A.! 1.4 Voz del Ciudadano

A.! 1.4.1 El sistema proporcionará un mecanismo para obtener retroalimentación de los visitantes del Portal, que consiste en la aplicación de un cuestionario de


INT010509RB0!!



Página 55 de 11


satisfacción.

A.! 1.4.2 El sistema guardará las respuestas de las preguntas que el visitante ingresó.

B.! 2. INTEGRACIÓN DE INFORMACIÓN

B.! 2.1 Captura mediante formularios Web

B.! 2.1.1 El sistema permitirá el registro y la modificación de la información, en los artículos y/o fracciones que apliquen, mediante la captura haciendo uso de formularios Web.

B. 2.1.2

El sistema permitirá la carga de archivos anexos a un registro, en formato PDF, Word y Excel, en los artículos y/o fracciones que apliquen.

La verificación de la versión de los documentos será responsabilidad del Sujeto Obligado (versión 97 ó 2003). El sistema almacenará los archivos anexos con una nomenclatura especial, como se muestra a continuación: CódigoSujeto_EtiquetaCampo_Fecha_Consecutivo

B. 2.1.3

El sistema validará el tamaño de los archivos anexos, el cual no deberá ser mayor a 10 MB.

La recomendación específica para Tribunales, Instituto Electoral del Distrito Federal y otros Entes, es que las resoluciones no excedan de 2 MB.

B. 2.1.4

El sistema registrará la fecha de última actualización de cada uno de los formatos correspondientes a los artículos y fracciones.

La actualización puede realizarse mediante los formularios Web o mediante la carga de archivos.

B. 2.1.5

El sistema permitirá, después de la captura o carga de información de cada uno de los formatos, la impresión de un comprobante de la integración de información de transparencia correspondiente.

El comprobante considerará los siguientes datos: •! Fecha y hora en que se realizó la integración.

•! Método utilizado (vía formulario Web o carga de archivo XML).

•! Artículo, fracción y formato.

•! Usuario que realizó la integración.

•! Nombre del Sujeto Obligado.


INT010509RB0!!



Página 56 de 11


B. 2.1.6 El sistema permitirá eliminar la información de transparencia por registro.

B. 2.2 Importación de archivos XML

B. 2.2.1

El sistema permitirá el registro de la información mediante la carga de archivos XML, en los artículos y/o fracciones que apliquen.

La carga de información mediante archivos XML únicamente aplica para los formatos de artículos y/o fracciones en los que no se incluyan archivos anexos. No se considerará la carga de archivos XML con archivos anexos.

B. 2.2.2 El sistema permitirá que la carga de información sea incremental o total correspondiente al año en curso.

B. 2.2.3 El sistema validará la estructura de los archivos XML de acuerdo con la configuración de cada formato.

B. 2.2.4 El sistema procesará los archivos XML e incorporará la información a la base de datos.

B. 2.2.5 El sistema notificará al usuario los errores que ocurrieron durante la importación y el procesamiento de los archivos XML.

B. 2.3 Consulta de estado de importación

B. 2.3.1 El sistema presentará el progreso de la transferencia de archivos XML y anexos (PDF, Word y Excel).

B. 2.3.2

El sistema permitirá que el usuario consulte el estado del procesamiento del archivo XML que importó

Los estados considerados para mostrar son: Recibido, Procesando, Rechazado, Finalizado.

B. 2.3.3 El sistema presentará los resultados del procesamiento de los archivos XML.

B. 2.4 Exportación de información

B. 2.4.1

El sistema permitirá a los usuarios de cada Sujeto Obligado realizar la exportación de su información correspondiente a los artículos y fracciones (los que apliquen) en formato Excel.

Únicamente se exportarán los datos que se muestran en los listados de información obtenidos en una consulta (corresponden a los datos que en los formatos correspondientes se configuraron para permitir dicha acción).


INT010509RB0!!



Página 57 de 11


C.! 3. EVALUACIÓN DE INFORMACIÓN

C. 3.1 Evaluación automática

C. 3.1.1

El sistema permitirá realizar evaluaciones automáticas del nivel de cumplimiento de cada uno de los Sujetos Obligados.

La revisión consistirá en verificar si se registró o actualizó la información de los formatos que le apliquen al Sujeto, de acuerdo con los periodos de actualización especificados. El resultado de la evaluación automática no se almacenará.

C. 3.1.2

El sistema presentará el porcentaje de avance en la agregación de información de un Sujeto en específico, por fracción.

Donde el 100% de avance será cuando el Sujeto tenga actualizaciones en todos los formatos que le apliquen. La calificación se calculará de la siguiente manera: 1. Número de formatos por fracción actualizados / total de formatos de la fracción que aplican *100. Nota: Sólo se tomarán en cuenta las fracciones que tengan asociados formatos al Ente.

C. 3.1.3 El sistema proporcionará la opción de impresión del resultado de la evaluación automática del Sujeto al que se le aplicó la revisión.

C. 3.2 Evaluación manual

C. 3.2.1

El sistema permitirá realizar la evaluación del nivel de cumplimiento por Sujeto de manera manual, es decir habilitará que el Evaluador registre los resultados de la valoración cualitativa de la información incorporada por los Entes a través de la calificación de los criterios que apliquen al Sujeto Obligado.

Para registrar la valoración de los criterios, se presentará el nombre del Sujeto Obligado, un listado con todos los criterios agrupados por ley, artículo y fracción que le apliquen al Sujeto en específico, y se proporcionarán las secciones para registrar: la valuación del criterio (escala de calificación) y recomendaciones por cada criterio.

C. 3.2.2 El sistema permitirá ingresar la valoración de cumplimiento de cada uno de los criterios que le apliquen al Sujeto acorde a la escala de calificación de criterios.

C. 3.2.3

El sistema permitirá que el Evaluador indique cuando ha terminado de aplicar la evaluación a un

Una vez establecida la finalización de la evaluación, no se podrán modificar los datos de la misma.


INT010509RB0!!



Página 58 de 11


Sujeto Obligado.

C. 3.2.4

El sistema permitirá aplicar evaluaciones manuales no formales, es decir, evaluaciones que no estén dentro de los periodos de evaluaciones formales.

El sistema no almacenará los resultados de las evaluaciones no formales.

C. 3.2.5 El sistema deshabilitará el acceso al módulo de Integración de Información para todos los Sujetos que se encuentren dentro del periodo de evaluación, al presentarse la fecha de inicio del mismo.

3.2.6 El sistema al finalizar la evaluación manual de un Sujeto calculará el Índice de Criterios Sustantivos, de cada uno de los artículos que le apliquen y únicamente si el artículo tiene este tipo de criterios.

C. 3.2.7 El sistema al finalizar la evaluación manual de un Sujeto calculará el Índice de Criterios Adjetivos, de cada uno de los artículos que le apliquen y únicamente si el artículo tiene este tipo de criterios.

C. 3.2.8 El sistema al finalizar la evaluación manual de un Sujeto y una vez calculados los índices de criterios sustantivos por cada artículo (que le aplique), calculará el Índice Compuesto de Criterios Sustantivos.

C. 3.2.9

El sistema al finalizar la evaluación manual de un Sujeto y una vez calculados los índices de criterios adjetivos por cada artículo (que le aplique), calculará el Índice Compuesto de Criterios Adjetivos.

C. 3.2.10 En caso de que algún artículo no tenga criterios adjetivos, para el cálculo del Índice Compuesto de Criterios Adjetivos, el sistema tomará el valor del Índice de criterios sustantivos de ese artículo.

C. 3.2.11 El sistema al finalizar la evaluación manual de un Sujeto calculará el Índice Global del Cumplimiento de las Obligaciones de Transparencia.

C. 3.2.12

El sistema al finalizar la evaluación manual proporcionará la opción de imprimir el resultado de la evaluación aplicada, tanto de una revisión no programada como de una programada.

El resultado de la evaluación aplicada comprenderá la siguiente información: •! Nombre del Sujeto Obligado.

•! Fecha de la aplicación de la revisión.

•! Artículo.


INT010509RB0!!



Página 59 de 11


•! Fracción.

•! Criterios.

•! Valuación por criterio.

•! Recomendaciones por criterio.

•! Resumen:

!! Artículo.

o! Índice de Criterios Sustantivos.

o! Índice de Criterios Adjetivos.

!! Fracción.



!! Índice Compuesto de Criterios Sustantivos.

!! Índice Compuesto de Criterios Adjetivos.

!! Índice Global del Cumplimiento de las Obligaciones de Transparencia.

C. 3.2.13

El sistema al finalizar la evaluación manual guardará el resultado de la misma, cuando se trate de una revisión formal.



•! Artículo.

•! Fracción.

•! Criterios.



•! Resumen:

!! Artículo.



INT010509RB0!!



Página 60 de 11



!! Fracción.





!! Índice Global del Cumplimiento de las Obligaciones de Transparencia.

C. 3.2.14 El sistema almacenará los índices calculados por cada Sujeto Obligado, cuando se trate de una evaluación formal.

C. 3.2.15 Al presentarse la fecha de fin del periodo de evaluación, el sistema habilitará el acceso al módulo de Integración de Información a los Sujetos evaluados.

C. 3.2.16

El sistema mostrará el listado de las notificaciones de revisión de resultados realizadas por los Sujetos Obligados, recibidas a la fecha.

Solamente se presentará esta información correspondiente a la evaluación vigente.

C. 3.2.17

El sistema permitirá consultar el seguimiento de la aplicación de la última evaluación configurada.

La consulta mostrará un listado de los Sujetos Obligados mostrando la fecha de inicio de la evaluación y la fecha de término. En caso de que no se haya iniciado una evaluación, se señalará la celda con un color distinto, para identificar los Entes a los que no se les ha aplicado la evaluación.

C. 3.3 Auto-evaluación

C. 3.3.1

El sistema permitirá al Responsable del Sujeto Obligado realizar una auto-evaluación del nivel de cumplimiento del Sujeto Obligado.

La revisión consistirá en verificar si se registró o actualizó la información de los formatos que le apliquen al Ente, de acuerdo con los periodos de actualización especificados.

El resultado de la auto-evaluación no se almacenará.


INT010509RB0!!



Página 61 de 11


C. 3.3.2

El sistema presentará el reporte de porcentaje de avance de la agregación de información del Sujeto por fracción con la opción de imprimir el reporte.

Donde el 100% de avance será cuando el Sujeto tenga actualizaciones en todos los formatos que le apliquen. La calificación se calculará de la siguiente manera:

1. Número de formatos por fracción actualizados / total de formatos de la fracción que aplican *100.

Nota: Sólo se tomarán en cuenta las fracciones que tengan asociados formatos que le apliquen al Ente.

C. 3.4 Consulta de resultados de evaluación Sujeto Obligado

C. 3.4.1

El sistema mostrará al Responsable y al Usuario de la Unidad Administrativa el reporte de resultados de la evaluación manual de su información, con la opción de imprimir el resultado.



•! Artículo.

•! Fracción.

•! Criterios.



•! Resumen:

!! Artículo.



!! Fracción.





!! Índice global del cumplimiento de las obligaciones de transparencia.


INT010509RB0!!



Página 62 de 11


Solamente se mostrará el reporte de las evaluaciones aplicadas en el año en curso y los dos años anteriores.

C. 3.4.2

El sistema proporcionará al Responsable la opción para notificar que ya revisó el reporte de resultados de la evaluación aplicada.

Para la notificación se guardarán los datos de nombre del Sujeto, fecha y hora de notificación.

C. 3.5 Reporte

C. 3.5.1

El sistema permitirá generar un reporte de una evaluación en específico, que contenga un listado de todos los Sujetos Obligados evaluados.

El sistema permite seleccionar un periodo de evaluación formal (considerando únicamente los periodos del año en curso y en los dos años anteriores). Por cada uno de los Sujetos Obligados se mostrará la siguiente información: •! Sujeto Obligado.

•! Artículo.



•! Índice Compuesto de Criterios Sustantivos.

•! Índice Compuesto de Criterios Adjetivos.


INT010509RB0!!



Página 63 de 11


•! Índice global del cumplimiento de las obligaciones de transparencia.

C. 3.5.2

El sistema permitirá exportar el reporte de evaluación en formato de Excel.

El nombre del archivo se conforma de la siguiente manera: ReporteGeneralEvaluacion_+[Identificador del periodo de evaluación] Por ejemplo: ReporteGeneralEvaluacion_2008-1.xls

D.! 4. ADMINISTRACIÓN DEL SISTEMA

D. 4.1 Registro de información

D. 4.1.1

El sistema permitirá modificar la información general acerca del sistema.

La información considerada es:

•! Objetivo.

•! Visión.

•! Objetivos específicos.

•! Servicios.

•! Contactos.

•! Ley de Transparencia.

D. 4.1.2 El sistema permitirá anexar archivos de la Ley de Transparencia en tres formatos.

Los formatos considerados son HTML, Word (versión 97 ó 2003) y PDF (versión 6 o anterior). El sistema no validará la versión de los documentos.

D. 4.2 Consulta de voz del ciudadano

D. 4.2.1

El sistema generará gráficas con base en las respuestas de los visitantes del Portal para que con ello pueda medirse su nivel de satisfacción con respecto a la estructura y servicios del Portal.


INT010509RB0!!



Página 64 de 11


D. 4.2.2 El sistema mostrará en un listado los comentarios ingresados por los visitantes del Portal.

D. 4.3 Administración de cuestionario

D. 4.3.1

El sistema permitirá integrar un mecanismo para obtener retroalimentación de los visitantes del Portal, que consiste en la aplicación de un cuestionario de satisfacción.

Debe contemplarse un espacio para sugerencias.

D. 4.3.2 El sistema permitirá modificar las preguntas del cuestionario de satisfacción del mecanismo de retroalimentación.

D. 4.3.3

El sistema permitirá eliminar (baja lógica) las preguntas del cuestionario de satisfacción del mecanismo de retroalimentación.

El sistema dejará de mostrar los resultados de la recopilación de la información correspondiente a la pregunta eliminada.

D. 4.4 Consulta de Bitácoras

D. 4.4.1

El sistema permitirá realizar la consulta de los registros de la bitácora.

Para realizar la consulta se considerarán los siguientes filtros: •! Rango de fechas.

•! Usuario.

•! Componente o sección del sistema.

•! Ley /Artículo / Fracción / Formato.



INT010509RB0!!



Página 65 de 11


D. 4.4.2

El sistema permitirá generar estadísticas gráficas sobre los movimientos que realizan los usuarios.

Para generar las estadísticas se considerarán los siguientes filtros: •! Rango de fechas.

•! Usuario.

•! Componente o sección del sistema.



Adicionalmente, se considerarán los siguientes niveles de agrupación:

•! Por mes.

•! Por día.

•! Por Órgano.

•! Por Sujeto Obligado.

•! Por componente o sección.

•! Por Ley.

•! Por artículo.

•! Por fracción.

•! Por formato.

•! Por tema.

D. 4.4.3

El sistema permitirá realizar la consulta de la bitácora de errores del módulo de Integración de Información.

Para realizar la consulta se considerarán los siguientes filtros: •! Rango de fechas.

•! Usuario.



D. 4.5 Estadísticas de uso del Portal

D. 4.5.1 Integrar una Los requerimientos para esta herramienta dependerán de las características y capacidades del


INT010509RB0!!



Página 66 de 11


herramienta especializada en la recopilación y análisis de la información de los logs de actividad de los servidores Web (dicha herramienta podrá estar incluida en el buscador).

software que se seleccione, por lo que en este documento únicamente se enlistan elementos que deberán considerarse para dicha herramienta.

D. 4.6 Administración de Sujetos Obligados

D. 4.6.1

El sistema permitirá agregar nuevas clasificaciones de Sujetos Obligados

La información a almacenar será: identificador, nombre de la clasificación y descripción.

D. 4.6.2 El sistema permitirá modificar los datos de las clasificaciones registradas previamente.

D. 4.6.3

El sistema permitirá eliminar clasificaciones de Entes del catálogo.

Se eliminarán (baja lógica) clasificaciones siempre y cuando no tengan Sujetos Obligados asociados.

D. 4.6.4

El sistema permitirá agregar, modificar y eliminar subclasificaciones a una clasificación.

Se eliminarán (baja lógica) clasificaciones siempre y cuando no tengan Sujetos Obligados asociados.

D. 4.6.5

El sistema permitirá agregar un Sujeto al padrón o catálogo de los mismos.

La información a almacenar para el padrón es: •! Código del Sujeto.

•! Nombre del Sujeto.

•! Nombre corto.

•! Clasificación del Sujeto.

•! Logotipo (imagen).

•! URL del Portal.

•! Ubicación.

•! URL del croquis de ubicación.

D. 4.6.6 El sistema permitirá modificar los datos de un Sujeto.

Los datos que pueden modificarse son: •! Código del Sujeto.


INT010509RB0!!



Página 67 de 11


•! Nombre del Sujeto.

•! Nombre corto.

•! Clasificación del Sujeto por Órgano.

•! Logotipo (imagen).

•! URL del Portal.

•! Ubicación.

•! URL del croquis de ubicación.

D. 4.6.7 El sistema permitirá eliminar un Sujeto del padrón.

La eliminación implica deshabilitar el Sujeto.

D. 4.7 Administración de Usuarios

D. 4.7.1

El sistema permitirá administrar las cuentas de los usuarios así como asignarles su perfil.

La administración de usuarios contempla registro, modificación y eliminación (baja lógica). Los datos generales que se consideran serán: nombre, primer apellido, segundo apellido, clave de usuario (login), contraseña, CURP, dirección electrónica (email), teléfono, Sujeto Obligado al que pertenece, departamento o área. Como mecanismo de seguridad la contraseña se almacenará de manera cifrada; además deberá considerar mínimo 8 caracteres y el uso de letras, números y caracteres especiales. A cada usuario se le podrá asignar únicamente un perfil.

D. 4.7.2 El sistema considerará para su funcionamiento los siguientes perfiles: Administrador, Responsable de Evaluación, Responsable de Información Pública, Usuario Evaluador, Usuario de Unidad Administrativa.

D. 4.7.3 El sistema permitirá al Administrador gestionar las cuentas de los usuarios con los perfiles de Responsable de Evaluación y Responsable de la Información.

D. 4.7.4 El sistema permitirá al Administrador registrar únicamente un usuario con el perfil de Responsable de Evaluación.

D. 4.7.5 El sistema permitirá al Administrador registrar únicamente un usuario con el perfil de Responsable de la Información por cada uno de los Sujetos Obligados.

D. 4.7.6 El sistema permitirá al Administrador modificar la

No se permitirá agregar usuarios con el perfil de Administrador, así como tampoco eliminar del único usuario con dicho perfil.


INT010509RB0!!



Página 68 de 11


información de su propia cuenta de usuario.

D. 4.7.7

El sistema permitirá al Administrador crear perfiles de usuarios y sus permisos los cuales podrán ser únicamente para el acceso a las secciones de consulta del sistema.

Se podrán asignar permisos para la consulta de las siguientes secciones: •! Consulta de resultados de evaluación.

•! Consulta de bitácora de movimientos.

•! Consulta de bitácora de errores en la carga de archivos.

•! Consulta de estadísticas de uso del Portal.

•! Consulta de la Voz del Ciudadano.

D. 4.7.8 El sistema permitirá modificar y eliminar únicamente los perfiles creados mediante el sistema.

D. 4.7.9

El sistema permitirá a cada uno de los Responsables de Información, administrar las cuentas de los Usuarios de Unidad Administrativa, del Sujeto Obligado al que pertenece.

El sistema deberá asignar a los usuarios el mismo Sujeto Obligado al que pertenece el Responsable.

D. 4.7.10 El sistema permitirá al Responsable de Evaluación administrar las cuentas de los Usuarios Evaluadores.

D. 4.8 Administración de temas

D. 4.8.1 El sistema permitirá agregar nuevos temas al catálogo.

Los datos de los temas a guardar serán: identificador, tema y descripción.

D. 4.8.2 El sistema permitirá modificar los datos de los temas registrados previamente.

D. 4.8.3 El sistema permitirá eliminar temas del catálogo.

Se eliminarán (baja lógica) temas siempre y cuando no tengan algún subtema, así como algún artículo y/o fracción asociadas.

D. 4.8.4 El sistema permitirá agregar nuevos subtemas al catálogo.

Los datos de los subtemas a guardar serán: identificador, tema al que pertenece, subtema y descripción.


INT010509RB0!!



Página 69 de 11


D. 4.8.5 El sistema permitirá modificar los datos de los subtemas registrados previamente.

D. 4.8.6 El sistema permitirá eliminar subtemas del catálogo.

Se eliminarán (baja lógica) subtemas siempre y cuando no tengan algún artículo y/o fracción asociados.

D. 4.9 Configuración de periodos de evaluación

D. 4.9.1

El sistema permitirá especificar el periodo de la evaluación ingresando su fecha de inicio, fecha de término, un identificador y los Entes a evaluar.

Los Sujetos que se incluyan en la evaluación, el Responsable de Evaluación los seleccionarán a través de un listado agrupado por tipo de Órgano.

D. 4.9.2

El sistema permitirá realizar modificaciones en los datos de un periodo de evaluación formal.

El sistema permitirá modificar los datos (periodo, identificador, Sujetos) de una evaluación formal, siempre y cuando ésta no haya sido aplicada o esté vigente su periodo de aplicación.

D. 4.9.3

El sistema permitirá eliminar la configuración de periodos de la evaluación formal.

El sistema permitirá eliminar los datos (periodo, identificador, Sujetos) de una evaluación formal, siempre y cuando ésta no haya sido aplicada o esté vigente su periodo de aplicación.

D. 4.10 Configuración de normatividad

D. 4.10.1

El sistema permitirá configurar una nueva estructura de la normatividad que rige las obligaciones de transparencia.

Este caso se presenta cuando existe una abrogación. La información que se ingresa es: •! Normatividad (LTAIPDF, Código Electoral u otras)

•! Fecha de publicación de la normatividad

•! Fecha de inicio de vigencia de la normatividad

•! Artículo

o! Número

o! Nombre corto

o! Texto de la Ley

•! Fracción

o! Número


INT010509RB0!!



Página 70 de 11


o! Nombre corto

o! Texto de la Ley

Adicionalmente, por cada una de las fracciones también se deberá especificar: •! Descripción, en lenguaje ciudadano, del

contenido del artículo y/o fracción.

•! Número de años que se deberá visualizar la información desde las consultas del menú del Portal.

•! Indicar si la información del artículo y/o fracción será susceptible a copiarse entre periodos.

La nueva estructura se mantendrá como temporal hasta que se confirme su publicación. Sin embargo, será visible en las siguientes secciones para poder realizar la configuración: •! Relación de Entes con artículos y/o fracciones.

•! Relación de subtemas con artículos y/o fracciones.

•! Configuración de la metodología de evaluación.

D. 4.10.2

El sistema permitirá configurar la nueva estructura de la ley mediante formulario Web.

El sistema permitirá realizar la nueva configuración a partir de la estructura vigente.

D. 4.10.3 El sistema permitirá configurar la nueva estructura de la ley mediante la carga de un archivo XML.

D. 4.10.4

El sistema permitirá al Administrador, cuando él así lo requiera, habilitar la estructura temporal para su uso en la configuración de formatos.

Cuando se habilite la estructura temporal para el módulo de Administración de Formatos, el sistema permitirá configurar los formatos necesarios conforme a la estructura temporal. Además, se habilitará la estructura temporal para la sección donde se relacionan a los Sujetos Obligados con los formatos que les aplica.


INT010509RB0!!



Página 71 de 11


D. 4.10.5

El sistema permitirá al Administrador habilitar la estructura temporal para su uso en el módulo de Integración de Información, siempre y cuando ya se haya habilitado la estructura temporal para la configuración de formatos.

Cuando se habilite la estructura temporal para el módulo de Integración de Información, el sistema bloqueará la integración de información conforme a la estructura vigente. Los Sujetos Obligados podrán integrar la información únicamente conforme a los formatos configurados para la estructura temporal. Además, se habilitará la estructura temporal para la sección donde el responsable de cada Sujeto configura los formatos que le aplican donde podrá relacionar a los usuarios de Unidad Administrativa del Sujeto Obligado con los formatos que les aplica, justificar los formatos en los que por la naturaleza del Sujeto no le aplican y asignar la Unidad Administrativa que genera y detenta la información solicitada en el formato.

D. 4.10.6 El sistema permitirá al Administrador habilitar la estructura temporal para su publicación en el Portal, siempre y cuando ya se haya habilitado la estructura temporal para su uso en el módulo de Integración de Información.

D. 4.10.7

El sistema, después de habilitar la configuración temporal para su publicación en el Portal, deberá almacenar la configuración e información relacionada a la estructura anterior y está no podrá ser modificada.

La información de transparencia relacionada a la configuración anterior ya no será visible a través de las consultas por menú que ofrecerá el Portal.

D. 4.10.8

El sistema permitirá modificar la estructura temporal de la LTAIPDF y la normatividad adicional, siempre y cuando no se haya habilitado la publicación en el Portal.

En caso de eliminar una normatividad, artículo o fracción, se borrarán también las configuraciones que se hayan realizado hasta el momento. Los estatus de la habilitación para la Administración de Formatos, Integración de Información y Publicación en el Portal no se verán afectados por las modificaciones a la estructura temporal.

D. 4.10.9 El sistema permitirá cancelar las modificaciones a la Ley de Transparencia y a la normatividad adicional, siempre y cuando no se haya habilitado la publicación en el Portal.


INT010509RB0!!



Página 72 de 11


D. 4.10.10

El sistema permitirá agregar nuevos artículos y fracciones a la Ley vigente y normatividad adicional que aplique en materia de Transparencia, a través de un formulario Web.

Este caso se presenta cuando haya una reforma.

La información que se ingresa es: •! Normatividad (Ley de transparencia, Código

Electoral u otras).

•! Fecha de publicación de la normatividad.

•! Fecha de inicio de vigencia de la normatividad.

•! Artículo.

•! Fracción.

Adicionalmente, por cada una de las fracciones también se deberá especificar: •! Descripción, en lenguaje ciudadano, del

contenido del artículo y/o fracción.

•! Número de años que se deberá visualizar la información desde las consultas del menú del Portal.

•! Indicar si la información del artículo y/o fracción será susceptible a copiarse entre periodos.

Los nuevos artículos y fracciones no se verán reflejados inmediatamente en el Portal, sino hasta que se habilite su publicación.

D. 4.10.11 El sistema permitirá al Administrador, cuando él así lo requiera, habilitar la administración de los formatos de los artículos y fracciones que se hayan agregado a la estructura vigente.

D. 4.10.12 El sistema permitirá al Administrador, cuando él así lo requiera, habilitar la publicación en el Portal de los nuevos artículos y fracciones que se hayan agregado a la estructura vigente.

D. 4.10.13

El sistema permitirá modificar los artículos y/o fracciones de la versión vigente, acorde a las reformas de la Ley y de la normatividad

Este caso se presenta cuando hay modificaciones al texto de un artículo o fracción que no impliquen cambios en los formatos, en cuyo caso se deberá eliminar y agregar un nuevo artículo o fracción. Los cambios realizados se verán reflejados inmediatamente en el Portal.


INT010509RB0!!



Página 73 de 11


adicional en materia de Transparencia.

D. 4.10.14

El sistema permitirá eliminar un artículo y/o fracción de la versión vigente, acorde a las reformas de la Ley y de la normatividad adicional en materia de Transparencia.

Eliminar en este contexto significa realizar una baja lógica del artículo y/o fracción, almacenando su estructura, sus asociaciones con Entes, Criterios y Formatos, así como la información de transparencia integrada por los Sujetos Obligados. No se permitirá modificar dicha información posteriormente. Los cambios realizados se verán reflejados inmediatamente en el Portal.

D. 4.11 Relación de Sujetos Obligados con artículos y fracciones

D. 4.11.1

El sistema permitirá relacionar cada uno de los Sujetos con los artículos y fracciones, según le apliquen.

La relación se basa en las obligaciones de transparencia que establecen la Ley y la normatividad adicional.

D. 4.11.2 El sistema permitirá cambiar las relaciones de cada uno de los Sujetos con los artículos y fracciones.

D. 4.11.3

El sistema permitirá eliminar las relaciones de cada uno de los Sujetos con los artículos y fracciones.

La eliminación será una baja lógica.

D. 4.12 Configuración de formatos

D. 4.12.1

El sistema permitirá a los Responsables de Información asignar a los Usuarios de Unidad Administrativa, del Sujeto al que pertenece, los formatos de los artículos y/o fracciones que tiene asociados.

D. 4.12.2 El sistema permitirá capturar por cada formato la Unidad Administrativa que genera y detenta la información a la que hace referencia el formato.

D. 4.12.3

El sistema permitirá capturar la justificación para un formato que no sea aplicable al Sujeto, es decir aquellos casos que por Ley está obligado pero por la naturaleza o razón de ser del mismo no le aplica.

D. 4.13 Relación de subtemas con artículos y fracciones


INT010509RB0!!



Página 74 de 11


D. 4.13.1 El sistema permitirá asociar los subtemas con artículos y fracciones, acorde al ámbito de estos últimos.

D. 4.13.2 El sistema permitirá cambiar las relaciones de los subtemas con las fracciones y artículos.

D. 4.13.3 El sistema permitirá eliminar las relaciones de los subtemas con las fracciones y artículos.

D. 4.14 Configuración de metodología de evaluación

D. 4.14.1

El sistema permitirá registrar nuevos criterios de evaluación.

Los datos que se guardarán son: •! Nombre del criterio.

•! Descripción.

•! Normatividad a la que está asociado:

o! Ley.

o! Artículo.

o! Fracción.

•! Tipo de criterio (sustantivo o adjetivo).

D. 4.14.2

El sistema permitirá modificar los datos de los criterios registrados previamente.

Los datos que se modificarán son: •! Nombre del criterio.

•! Descripción.

•! Normatividad a la que está asociado:

o! Ley.

o! Artículo.

o! Fracción.

•! Tipo de criterio (sustantivo o adjetivo).

En caso de que se modifiquen las asociaciones con la normatividad (ley, articulo, fracción), entonces se deshabilitarán dichas relaciones registradas previamente.


INT010509RB0!!



Página 75 de 11


D. 4.14.3

El sistema permitirá eliminar criterios de evaluación. Cuando un criterio es borrado, el sistema dejará de mostrar toda información relacionada con éste en las siguientes evaluaciones.

Se deshabilita el criterio y dejará de mostrarse en el sistema.

D. 4.14.4 El sistema permitirá relacionar los criterios de los artículos y fracciones con cada uno de los Sujetos, según le apliquen.

D. 4.14.5 El sistema permitirá cambiar las relaciones de los criterios, fracciones y artículos de cada uno de los Sujetos.

D. 4.14.6

El sistema permitirá eliminar las relaciones de los criterios, fracciones y artículos de cada uno de los Sujetos.


D. 4.14.7

El sistema permitirá administrar un catálogo de ponderaciones de los dos tipos de criterios (sustantivos y adjetivos).

La ponderación se expresará en porcentajes (0 al 100%). El sistema validará que el total de porcentaje de ponderación de los tipos de criterios sea igual a 100%.

D. 4.14.8

El sistema permitirá administrar un catálogo de ponderaciones para cada artículo, fracción y criterios.

La administración incluye la modificación de los valores de ponderación por artículo, fracción y criterios. Los valores se expresarán en quebrados (ejemplo: 1/7). Los valores que se tomarán para la configuración inicial del sistema serán los establecidos en el documento de Criterios y metodología de evaluación de la información pública de oficio que deben dar a conocer los Sujetos Obligados en sus portales de Internet.

D. 4.14.9 El sistema permitirá administrar un catálogo para la escala de calificación

La administración incluye el registro, la modificación y eliminación de alguna calificación de la escala.


INT010509RB0!!



Página 76 de 11


de criterios. La información que se requiere de cada calificación es: descripción y valor (numérico con dos posiciones para decimales).

D. 4.14.10 El sistema mostrará un listado de Sujetos e indicará por cada uno si tiene asignada o no su configuración de ponderación para la evaluación.

D. 4.14.11

El sistema mostrará por Sujeto los artículos, fracciones y criterios que le apliquen junto con sus respectivas ponderaciones para que el Responsable de Evaluación realice los ajustes a las ponderaciones o bien acepte los valores presentados.

Los valores de las ponderaciones que se presentan son tomados del Catálogo de Ponderaciones.

D. 4.14.12

El sistema validará que el total del porcentaje de ponderación de los artículos, fracciones y de cada grupo acorde al tipo de criterios, sea igual al 100% por cada uno.

Estás validaciones se realizarán durante la asignación de ponderaciones a Sujetos Obligados.

D. 4.14.13 Cuando el Responsable de Evaluación acepta los valores de ponderación de los artículos, fracciones y criterios de un Sujeto, se guarda la configuración de ponderación de evaluación del mismo.

D. 4.15 Administración de formatos

D. 4.15.1

El sistema permitirá al Responsable de Evaluación y al Administrador configurar los formatos correspondientes a cada uno de los artículos y/o fracciones de la(s) ley(es) que apliquen.

Los formatos servirán para homogeneizar la captura mediante formularios Web, para la carga de información mediante archivos XML, para el almacenamiento de la información así como para la publicación de información en el Portal.


INT010509RB0!!



Página 77 de 11


D. 4.15.2

El sistema permitirá crear uno o más formatos por cada uno de los artículos y/o fracciones de la(s) ley(es) que apliquen.

Para el registro de cada formato se considera el registro de un título, una descripción y el periodo de actualización de la información. En el caso de que exista una configuración de estructura temporal, y que se haya habilitado dicha estructura para la Administración de Formatos, se permitirá elegir si el formato corresponde con artículo o fracciones de la estructura actual o de la temporal. Los nuevos formatos no se verán reflejados inmediatamente en el módulo de Integración de Información ni en el Portal, sino hasta que se habiliten.

D. 4.15.3 El sistema permitirá definir distintas secciones dentro de un mismo formato.

D. 4.15.4

El sistema permitirá definir los datos que se deberán solicitar en cada uno de los formatos.

La información general que se considera para cada uno de los datos es etiqueta y descripción de la información que se espera durante la integración de la información.

D. 4.15.5

El sistema permitirá definir, por cada uno de los datos registrados, el tipo de campo esperado.

Los tipos de campo que se considerarán son: •! Texto corto.

•! Texto largo.

•! Numérico.

•! Moneda (considerar multimoneda como son euros y dólares).

•! Fecha.

•! Hora.

•! URL o vínculo a documentos externos al sistema (Con etiqueta).

•! Archivo Anexo (PDF, Word, Excel e Imágenes).


INT010509RB0!!



Página 78 de 11


D. 4.15.6

El sistema permitirá definir, por cada uno de los datos registrados una o varias validaciones de formato.

Las validaciones que se considerarán son: •! Restricción de caracteres especiales

(Únicamente letras, Alfanumérico, con o sin caracteres especiales). Aplica sólo cuando el tipo de dato sea Texto.

•! Longitud. Aplica sólo cuando el tipo de dato sea Texto o Numérico

•! Obligatorio o no

D. 4.15.7

El sistema permitirá especificar, por cada uno de los datos registrados, si se muestra o no en el listado general de la información.

El listado general de la información aparecerá en el Portal después de realizar alguna consulta de la información de transparencia. Además, los datos que se hayan elegido para mostrarse serán los datos que se exportarán a Excel cuando el usuario lo solicite.

D. 4.15.8 El sistema permitirá especificar, por cada uno de los formatos, el número máximo de registros permitidos durante la captura o carga de información.

D. 4.15.9

El sistema agregará, de manera predeterminada, un campo para señalar el año al que corresponde la información, un campo para indicar la fecha de actualización de la información que se va agregar y un campo para agregar notas.

Los campos no podrán modificarse ni eliminarse del formato y tendrán las siguientes características: Año: •! Campo numérico, sin decimales.

•! Longitud de 4 caracteres.

•! Será obligatorio.

Fecha de actualización: •! Campo fecha.

•! Caracteres alfanuméricos.

•! Será obligatorio.

Notas: •! Campo de texto.

•! Caracteres alfanuméricos.

•! Dato opcional.

D. 4.15.10 El sistema permitirá agregar listados o tablas dentro de cada formato.

D. 4.15.11 El sistema generará el esquema XML de cada uno de los formatos configurados.


INT010509RB0!!



Página 79 de 11


D. 4.15.12

El sistema permitirá la descarga del esquema XML correspondiente a cada uno de los formatos.

El esquema será necesario para los Sujetos Obligados que deseen cargar su información mediante archivos XML.

D. 4.15.13

El sistema generará los formularios en HTML para permitir a los Sujetos Obligados la captura de su información.

El sistema permitirá desplegar la vista preliminar del formulario.

D. 4.15.14

El sistema permitirá la modificación de los formatos registrados.

La modificación considera agregar y eliminar campos, así como poder modificar las etiquetas de los campos.

No se permitirá modificar los tipos de datos ni las validaciones.

D. 4.15.15

El sistema permitirá la eliminación de los formatos registrados.

Eliminar en este contexto significa realizar una baja lógica del formato, almacenando su estructura, sus asociaciones con Sujetos y usuarios, así como la información de transparencia integrada por los Sujetos Obligados. No se permitirá modificar posteriormente dicha información. Los cambios realizados se verán reflejados inmediatamente en el Portal.

D. 4.15.16

El sistema permitirá habilitar cada formato para su uso en el módulo de Integración de Información.

Implica que antes de integrar la información, el responsable de cada Usuario de Información deberá relacionar a los usuarios de Unidad Administrativa del Sujeto Obligado con los formatos que les aplica.

D. 4.15.17

El sistema habilitar cada formato para su publicación en el Portal, siempre y cuando ya se haya habilitado para su uso en el módulo de Integración de Información.

La publicación en el portal dependerá de que el artículo o fracción al que corresponda el formato también esté habilitado para la publicación.


INT010509RB0!!



Página 80 de 11


D. 4.16 Relación de Sujetos Obligados con formatos

D. 4.16.1

El sistema permitirá relacionar cada uno de los Entes con los formatos de cada artículo y/o fracción, según le apliquen.

Considerando aquellos casos en los que el Sujeto está obligado pero por su naturaleza o razón de ser no le aplican.

D. 4.16.2 El sistema permitirá cambiar las relaciones de cada uno de los Sujetos con los formatos.

D. 4.16.3

El sistema permitirá eliminar las relaciones de cada uno de los Entes con los formatos.


D. 4.17 Administración de información histórica

D. 4.17.1

El sistema permitirá realizar respaldos de la información de transparencia de todos los Sujetos Obligados, de uno o varios años.

Para realizar el respaldo se deberá especificar el año del cual se desea el respaldo.

El respaldo incluirá la información de transparencia contenida en la base de datos así como sus archivos anexos. Adicionalmente, se deberán incluir en el respaldo los formatos asociados a la información.

D. 4.17.2

El sistema permitirá eliminar la información de transparencia de todos los Sujetos Obligados, de uno o varios años.

El sistema deberá validar que no se elimine la información del año en curso. Adicionalmente, validará que exista un respaldo de la información de los años indicados. Los formatos asociados no se eliminarán del sistema.

D. 4.17.3

El sistema permitirá restaurar la información de transparencia contenida en respaldos.

Para realizar la restauración se deberá anexar el archivo del respaldo que se desea recuperar.

El sistema deberá validar que no exista información de los años a restaurar. En caso de existir información, deberá eliminarse así como los archivos anexos asociados antes de realizar la restauración.

El sistema deberá validar si el espacio disponible en el servidor es suficiente para realizar la restauración.

El sistema también deberá restaurar los formatos.


INT010509RB0!!



Página 81 de 11


D. 4.17.4

El sistema calculará el volumen de información que se respaldará o eliminará.

La estimación del volumen deberá considerar la información contenida en la base de datos así como de los archivos anexos.

D. 4.17.5 Al iniciar el proceso de respaldo, eliminación o restauración de información, el sistema deshabilitará el acceso al módulo de Integración de Información para todos los Sujetos.

D. 4.17.6 Al finalizar el proceso de respaldo, eliminación o restauración de información, el sistema habilitará el acceso al módulo de Integración de Información para todos los Sujetos.

D. 4.17.7 El sistema notificará los errores que llegasen a ocurrir durante el proceso de respaldo, eliminación o restauración de información.

D. 4.17.8

El sistema registrará en una bitácora todos los respaldos, eliminaciones y restauraciones de información que se realicen.

La información que se considerará será la siguiente: •! Proceso (Respaldo, eliminación, restauración).

•! Año respaldado / eliminado / restaurado.

•! Cantidad de registros.

•! Cantidad de archivos.

•! Fecha y hora en que inició el proceso.

•! Fecha y hora en que terminó el proceso.

D. 4.18 Copiar información de transparencia del periodo anterior

D. 4.18.1

El sistema permitirá realizar la copia de la información de transparencia del periodo anterior, mediante la selección de los artículos y fracciones que se deseen copiar.

El sistema mostrará todos los artículos y fracciones de la estructura vigente, especificando cuáles se indicaron que si se pueden copiar. Además se considerará ingresar el año de origen del cual se tomará la información de los Sujetos y el año destino al que se copiará la información.

D. 4.18.2

El sistema notificará cuando exista información correspondiente al año destino al que se requiere copiar la información.

En caso de que el usuario confirme que desea continuar con la copia, la información existente se eliminará y se copiará la información del año anterior.

D. 4.18.3 Al realizar la copia el sistema generará una réplica de la información contenida en el año de origen y la asigna al año de destino, de los artículos y fracciones seleccionados.


INT010509RB0!!



Página 82 de 11


E.! 5. CONTROL DE ACCESO

E. 5.1

El sistema solicitará la autenticación de los usuarios para el acceso a los módulos de Integración de información de transparencia, Administración y Evaluación de Información a través de clave de usuario y contraseña y opcionalmente, mediante el uso de certificados digitales.

El uso de certificados digitales dependerá de que la opción haya sido habilitada desde el módulo de Administración. Y el proceso para la validación de un certificado digital será llevado por la Unidad Certificadora. El sistema solamente recibirá el resultado de dicho proceso que consistirá en indicar sí es válido o no el certificado.

E. 5.2 El sistema contemplará un tiempo de 20 minutos de inactividad para la expiración de las sesiones.

E. 5.3

El sistema registrará en una bitácora los movimientos realizados en los módulos de Integración de información de transparencia, Administración y Evaluación de Información.

Los datos que se considerarán son: •! Usuario (Que realiza la actividad).

•! Fecha y Hora.

•! Componente (Sección del sistema).

•! Operación.

•! Ley /Artículo / Fracción / Formato (Aplica sólo para las operaciones realizadas en el módulo de Integración de información de Transparencia).

•! Sujeto Obligado (Aplica sólo para las operaciones realizadas en el módulo de Integración de información de Transparencia y en el de Evaluación de la información).

E. 5.4 El sistema permitirá al Administrador habilitar y deshabilitar el uso de certificados digitales para la autenticación de usuarios.

F.! 6. MEJORAS A LA HERRAMIENTA

F. 6.1. PORTAL

F. 6.1.1. Se deberán revisar, configurar y adecuar las herramientas desarrolladas que permiten la integración del buscador empresarial con la herramienta de obligaciones de transparencia tomando en cuenta que podrá existir una


INT010509RB0!!



Página 83 de 11


configuración de normatividad distinta para cada entidad federativa, dado que la herramienta actualmente está diseñada para una sola Entidad Federativa.

F. 6.1.2.

Se deberá agregar funcionalidad que permita establecer un vínculo entre dos formatos, por ejemplo, si se consulta el formato que muestra datos relacionados con el directorio de servidores públicos y en este se contempla la clave del puesto, que el usuario tenga la posibilidad de dar clic en esa clave y que se muestre una plantilla con el detalle correspondiente a la clave del puesto. (Funcionalidad actual del POT)

F. 6.1.3.

Se deberá agregar funcionalidad que permita a los particulares realizar búsquedas de información por sujetos obligados agrupados por rubros, es decir, si se considera realizar búsquedas por “Finanzas” se consulten todas las dependencias que se han clasificado en dicho rubro a nivel nacional, sin necesidad, de seleccionarlas una por una.

Para lograr lo anterior, se deberá implementar un catálogo de equivalencias para agrupar todas las dependencias de gobierno por “sector”.

F. 6.1.4. La solución deberá identificar los campos comunes de la configuración, para que cuando se comparen sujetos obligados que pertenezcan a entidades federativas diferentes solo se muestren dichos campos.

F. 6.1.5. La solución del buscador empresarial deberá considerar el mapeo de los campos comunes que se generan para cada Entidad Federativa.

F. 6.1.6.

Módulo de denuncia por incumplimiento

En el Portal de Obligaciones de Transparencia (POT) se deberá incluir un mecanismo que permita a los particulares registrar denuncias por incumplimiento a las obligaciones de transparencia, la denuncia se podrá realizar a través de un nombre de usuario o contraseña que previamente se haya registrado en la PNT. Los datos considerados para el registro de denuncias son los siguientes:

1)! Datos obligatorios. •! Nombre del sujeto obligado denunciado. •! Descripción clara y precisa del incumplimiento. •! Medio para recibir notificaciones.

2)! Datos opcionales •! Archivos con medios de prueba del incumplimiento. •! Nombre del denunciante. •! Perfil (edad, genero, nacionalidad, escolaridad y ocupación)

Cabe mencionar que los datos ingresarán a un procedimiento que será configurado en el BPM existente en la PNT o uno propuesto por Intellego que cuente con el VoBo de la DGTI del INAI y que en su caso exista una configuración particular para cada entidad federativa de acuerdo a la


INT010509RB0!!



Página 84 de 11


normatividad que emita el Sistema Nacional de Transparencia.

F. 6.1.7.

Se deberán realizar ajustes en el diseño al módulo denominado “portal ciudadano” del POT, para homologarlo al diseño general de la PNT, así como el diseño responsivo para consulta mediante dispositivos móviles inteligentes.

F. 6.1.8. Se deberá agregar funcionalidad al mecanismo que exporta la información del POT en los formatos XLS, XML, TXT, CSV y JSON.

F. 6.2. INTEGRACIÓN DE INFORMACIÓN

F. 6.2.1.

Se deberá estandarizar el código de página utilizado en el Sistema de Obligaciones de Transparencia con el fin de garantizar la correcta interpretación de los datos cargados en la herramienta, contemplado el mismo estándar en el módulo de carga masiva.

F. 6.2.2. Se deberá estandarizar los formatos de expresiones regulares (definición de caracteres especiales y reglas de negocio) utilizados para validar la carga masiva de información mediante archivos XML.

F. 6.2.3. Se deberá mejorar el mecanismo de carga masiva de información de tal forma que se realice en procesos paralelos aprovechando los recursos de infraestructura disponibles.

F. 6.2.4 Se deberá modificar la funcionalidad de validación de caracteres que actualmente existe para que sea configurable desde un archivo, dado que actualmente se encuentra en código.

F. 6.2.4. Se deberán modificar los mensajes de error enviados por la solución como resultado de la carga masiva de información de tal manera que sean comprensibles para usuarios no técnicos.

F. 6.2.5. La solución deberá ofrecer un mecanismo de notificación de estado de carga de información masiva vía correo electrónico.

F. 6.3. EVALUACIÓN DE INFORMACIÓN

F. 6.3.1. Se deberá revisar la funcionalidad del módulo de evaluación y realizar las mejoras necesarias.

F. 6.3.2. Se deberán integrar las opciones de evaluación para que el administrador general tenga acceso a las mismas, así como de todas las opciones disponibles en el sistema.

F. 6.4. ADMINISTRACIÓN DEL SISTEMA

F. 6.4.1. Se deberá realizar la adecuación para que el sistema permita la configuración de formatos de manera general y estos puedan heredarse hacia


INT010509RB0!!



Página 85 de 11


las Entidades Federativas.

F. 6.4.2. En las páginas que corresponda la visualización de listados grandes de formatos, campos, criterios, asignación de formatos, asignación de artículos, temas, subtemas, se deberán implementar mecanismos de filtrado.

F. 6.4.3. Mejorar la funcionalidad del respaldo de información, así como de la recuperación de la misma, de acuerdo con las opciones configuradas en el sistema.

F. 6.4.4. La consulta de las bitácoras (integración de información y movimientos) deberá restringirse de acuerdo al perfil del usuario.

F. 6.4.5.

Se deberá desarrollar un tramo de administración de tres niveles:

•! Administrador General

o! Se deberá agregar la funcionalidad de un perfil de usuario denominado “Administrador general”, este rol solo podrá ser asignado a un único usuario.

o! La solución deberá permitir al administrador general dar de alta, modificar y dar de baja lógica a las diferentes entidades federativas del país.

o! La solución deberá permitir al administrador general crear, modificar, dar de baja lógica y asignar cuentas de usuario para cada entidad federativa del país.

o! La solución deberá contar con un catálogo de sectores que

permita clasificar a los diferentes sujetos obligados de cada entidad federativa.

o! Actualmente la solución solo permite un usuario con el rol

“Admin”, deberá modificarse la funcionalidad para que se puedan crear, modificar, dar de baja y asignar tantos usuarios con este rol por cada Entidad Federativa.

•! Administrador de entidad federativa

o! La solución deberá permitir a cada Entidad Federativa registrar a los sujetos obligados correspondientes.

o! La solución deberá permitir a cada Entidad Federativa crear, modificar, dar de baja lógica y asignar cuentas de usuario para cada sujeto obligado.


INT010509RB0!!



Página 86 de 11


o! La solución deberá permitir clasificar a cada uno de los sujetos obligados de acuerdo a un catálogo de sectores previamente configurado por el administrador general.

•! Administrador de sujeto obligado

o! Se deberán agregar los campos de control necesarios que

permitan identificar la pertenencia de cada sujeto obligado con su Entidad Federativa.

o! La solución deberá permitir a cada sujeto obligado registrar a

sus diferentes unidades administrativas.

o! La solución deberá permitir a cada sujeto obligado crear, modificar, dar de baja y asignar cuentas de usuario para cada unidad administrativa.

F. 6.5.

La solución deberá permitir realizar la configuración de formatos, periodos de evaluación, sujetos obligados, normatividad, catálogos generales, asignación de formatos, artículos, fracciones, criterios, bitácora, copia de información a cada una de las entidades federativas.

F. 6.6. La solución deberá permitir heredar la configuración de la Ley General de Transparencia a nivel de normatividad y formatos, para que cada entidad federativa realice los ajustes necesarios.

F. 6.7. La solución deberá contar con un mecanismo que permita la habilitación de edición de los formatos heredados por las Entidades Federativas.

F. 6.8.

La herramienta deberá contemplar la generación de web service dinámicos para que se construyan conforme se configuren los formatos en el Sistema de Obligaciones de Transparencia y estos de manera automática se conecten al bus de comunicaciones existente en la PNT.

F. 6.9.

Se deberá realizar la adecuación correspondiente para que el sistema permita el ingreso de un nivel más (inciso) en el apartado de artículos y fracciones, así como de la replicación de la misma funcionalidad en todos los módulos del sistema.

4.! Sistema de Evaluación de las Obligaciones de Transparencia

Desarrollar una herramienta informática mediante la cual se gestionen las diferentes etapas del proceso de evaluación de la Información Pública de Oficio, al tiempo de ofrecer niveles de acceso con privilegios diferenciados acorde al rol de responsabilidades que atenderán los diferentes actores del proceso.

Para cumplir tal cometido, se requiere tomar en cuenta los siguientes aspectos:


INT010509RB0!!



Página 87 de 11

a)! El Sistema de Evaluación de las obligaciones de transparencia se basará en un conjunto ordenado de normas y procedimientos que regularán dicho proceso. Las más relevantes son:

•! La Ley General de Transparencia en su Título Quinto, Capítulo I al VI, artículos 60 al 88;

•! Los Lineamientos Técnicos Generales para la publicación y evaluación de la información pública de oficio establecida en el Título Quinto de la Ley General de Transparencia;

•! Los criterios y metodología de evaluación de la información de oficio en el ámbito federal;

•! El “Padrón de Sujetos Obligados”, que estará conformado por cualquier autoridad, entidad, órgano y organismo de los Poderes Ejecutivo, Legislativo y Judicial, órganos autónomos, partidos políticos, fideicomisos y fondos públicos, así como cualquier persona física, moral o sindicato que reciba y ejerza recursos públicos o realice actos de autoridad en el ámbito federal.

b)! Para construir la herramienta de gestión del proceso de evaluación de la información de oficio, el Sistema a desarrollar deberá considerar los siguientes elementos:

•! Carga y consulta del “Programa Anual de Verificación y Evaluación” donde estarán establecidos los periodos de evaluación

•! Catálogo de Unidades Administrativas que intervienen en el proceso de verificación y evaluación; que, de acuerdo con las características de cada Entidad Federativa, realizarán la evaluación.

•! El sistema deberá permitir la agrupación de sujetos obligados para ser evaluados por la Unidad Administrativa del Órgano Garante de cada una de las Entidades.

•! Catálogo de evaluadores asignados por cada una de las unidades administrativas evaluadoras, que incluya la posibilidad de agrupar los sujetos obligados que serán evaluados para que sean asignados a cada uno de los evaluadores.

•! Proceso que permita la consulta del “Padrón de Sujetos Obligados” y la asignación aleatoria de sujetos obligados a las áreas correspondientes

•! Catálogo de direcciones electrónicas de los portales de internet de todos los sujetos obligados

•! Identificar los tres tipos de evaluación: diagnóstica, vinculatoria con recomendaciones, vinculatoria con vistas al órgano de control así como, si es de forma aleatoria o muestral


INT010509RB0!!



Página 88 de 11

•! Elaboración de una herramienta flexible que permita la carga de los criterios a evaluar, el registro de códigos de evaluación asignados por criterio, así como los requerimientos, recomendaciones u observaciones (Art. 84 LGTAIP) (tabla de verificación) formulados por el área evaluadora de acuerdo con las obligaciones de cada sujeto obligado

•! El Sistema programará la asignación de artículos, fracciones e incisos que le corresponda a cada sujeto obligado.

c)! Al iniciar cada proceso de evaluación, que consistirá en verificar que la

información esté completa, publicada y actualizada en tiempo y forma, el Sistema permitirá:

•! Controlar las distintas versiones de los documentos emitidos.

d)! Al término de la evaluación el Sistema deberá generar:

•! Un archivo (tabla de verificación) con el registro de códigos de evaluación asignados por criterio, los requerimientos, recomendaciones u observaciones y los índices simples, compuestos y globales por cada sujeto obligado evaluado.

•! La tabla de verificación de cada sujeto obligado evaluado estará disponible para que la unidad administrativa responsable de la evaluación realice la validación correspondiente.

•! El Sistema permitirá la retroalimentación entre la Dirección General de Evaluación y el área evaluadora correspondiente en un periodo establecido.

•! Una vez validadas, el Sistema emitirá el Documento de requerimientos, recomendaciones u observaciones para cada sujeto obligado que constituirá el Dictamen.

•! El Sistema emitirá el Informe de Resultados y el Dictamen correspondiente por sujeto obligado para su presentación al Pleno del INAI.

•! Las tablas de verificación retornarán a las áreas generadoras para la notificación de los resultados al sujeto obligado evaluado.

•! Revisar y en su caso adecuar el módulo de consulta ciudadana de los resultados que deberá estar disponible por Entidad Federativa y Sujeto Obligado.


INT010509RB0!!



Página 89 de 11

5.! Sistema de Gestión de Medios de Impugnación (Recurso de Revisión y Atracción)

Características generales:

•! Plataforma web diseñada e implementada bajo los estándares de la industria.

•! Accesibilidad y usabilidad establecidos:

o! Estándares del W3C (Consorcio World Wide Web).

o! Guía para la Acción Pública (GAP). Los sitios web accesibles. Una herramienta para el acceso a la información y a la interacción en condiciones de igualdad: http://www.conapred.org.mx/userfiles/files/GAP-Web-OK-Accss.pdf

o! Ser fácil de utilizar.

o! Intuitivo.

o! Tener tiempos de respuesta ágiles.

o! Debe ser funcional e independiente del cliente en el que se ejecute.

•! La plataforma debe permitir el acceso mediante distintos mecanismos que permitan la integración con software Single Sign On.

•! La plataforma debe permitir el uso de FIEL como mecanismo para la identificación de usuarios.

•! Firmado electrónico.

•! Manejo de flujos de trabajo configurables y adaptables en cualquier momento mediante el BPM existente en la PNT o BPM propuesto por Intellego previo VoBo de la DGTI del INAI, para cada Entidad Federativa.

Posibilidad de extender la funcionalidad utilizando distintos medios como servicios web y módulos programados que se acoplen a la solución.

•! Mecanismos de envío de información como correo electrónico, SMS dirigidos a los recurrentes, mensajes a través del mismo sistema, configurables en su contenido y presentación.

•! Manejo de grupos de usuarios y grupos de sujetos obligados.

•! Administración de usuario y áreas de adscripción independiente de los procesos y funcionalidad del sistema.

•! Administración de unidades administrativas internas y externas al Órgano Garante por cada Entidad Federativa.

•! Administración por procesos o funcionalidades.


INT010509RB0!!



Página 90 de 11

•! Administración de usuarios con distintos niveles de acceso a funcionalidad y/o información.

•! La herramienta deberá considerar un mecanismo que permita extraer información estadística y depositarla en tablas resumen, con la finalidad de construir un tablero de control que apoye la toma de decisiones, a través de semáforos, gráficos de barras y alertas a los usuarios de las entidades federativas, sujetos obligados y unidades administrativas, en el seguimiento a los procedimientos y los pasos que les son asignados dentro del flujo de trabajo que se configure en el BPM.

o! Dicho mecanismo deberá ser totalmente configurable y cada entidad federativa será responsable de su parametrización de acuerdo a la configuración de los procedimientos establecidos.

o! Los rubros considerados a ser graficados son los siguientes:

o! Procedimientos registrados, procedimientos en trámite, procedimientos concluidos y gestión interna de procedimientos.

o! Cabe mencionar que las gráficas mostrarán información relacionada con el alcance del usuario que está ingresando al módulo, es decir, dependiendo del perfil del usuario se mostrará la información de su competencia.

o! Así mismo, la herramienta deberá considerar como primer filtro para mostrar la información un periodo de tres meses anteriores a la fecha actual, esto con la finalidad de no afectar el desempeño de la herramienta.

o! Procedimientos registrados (totalidad de recursos de revisión y recursos de inconformidad)

o! Gráfica de barras con el número de procedimientos registrados distribuidos por año, el dar clic sobre alguna de las barras permitirá mostrar una nueva gráfica de barras con el detalle del año seleccionado distribuyendo los procedimientos registrados por mes, este mecanismo se utilizará para mostrar información por semana del año y en la última gráfica por día, al dar clic sobre una barra de día, la aplicación mostrará una tabla con todos los procedimientos registrados en el día seleccionado donde se podrá visualizar el número de folio, la fecha de registro, entidad federativa, sujeto obligado y el nombre del particular.

o! Los filtros adicionales que deberá contemplar esta gráfica serán: sector, entidad federativa, sujeto obligado, nombre del particular y periodo, las opciones de filtrado se descartarán de acuerdo al alcance del usuario registrado.

o! Procedimientos en trámite (Con fecha de registro y sin fecha de conclusión)

o! Grafica de barras apiladas con colores de semáforo, se requiere que cada nivel de usuario (administrador general, administrador de entidad


INT010509RB0!!



Página 91 de 11

federativa y administrador de sujeto obligado) tenga la opción de configurar el número de días para cada uno de los tres rangos (rojo, amarillo y verde), cuando el usuario dé clic sobre alguno de los colores será necesario mostrar la tabla con el listado de los procedimientos en trámite que corresponda, adicionalmente, se requiere que se implemente un mecanismo que alerte a los usuarios del tablero cuando un procedimiento pase de un rango a otro, esta alerta se debe realizar vía correo electrónico dependiendo de la configuración establecida por el usuario.

o! La tabla de detalle que se deberá mostrar al dar clic sobre alguno de los tres colores de semáforo de la gráfica contendrá la siguiente información: número de folio, fecha límite de atención, días naturales entre la fecha límite de atención y la fecha actual, en su caso, número de folios turnados a ponencias, número de folios concluidos que fueron turnados a las ponencias, vínculo a una tabla que muestre los folios turnados y generados para dicho procedimiento, el orden para mostrar la información deberá ser de acuerdo a los días naturales entre la fecha límite de atención y la fecha actual de menor a mayor.

o! La tabla que contendrá el detalle de los folios turnados a las ponencias debiendo mostrar la siguiente información: estado del folio (Pendiente o Concluido), número de folio, ponencia, fecha de turnado y en su caso fecha de respuesta.

o! Procedimientos concluidos (fecha de conclusión)

o! Gráfica de barras apilada con dos elementos, el primero de ellos con el total de procedimientos concluidos y el segundo con el número de procedimientos en trámite.

o! Gestión interna de procedimientos

o! La herramienta deberá generar gráficas de barras con el número de procedimientos que han sido turnados a las diferentes ponencias, al dar clic sobre alguna de las barras se deberá mostrar una tabla detalle con la siguiente información: folio, fecha de turnado, fecha de respuesta, y los días transcurridos entre las dos fechas anteriores.

o! La herramienta deberá generar gráficas de barras con el número de procedimientos que fueron asignadas a las diferentes ponencias y que se encuentran pendientes de atención, al dar clic sobre alguna de las barras se deberá mostrar una tabla detalle con la siguiente información: folio, fecha de turnado, fecha de respuesta y los días transcurridos entre las dos fechas anteriores.

o! Los filtros disponibles para este tipo de gráficas deben considerar: sujeto obligado, ponencia y periodo.

o! En resumen el módulo de tablero de control deberá contar con:


INT010509RB0!!



Página 92 de 11

o! Una sección de administración que permita configurar el nombre y correo electrónico de las personas que recibirán las alertas

o! Una sección de administración que permita configurar los rangos (rojo, amarillo y verde) que serán establecidos para la gráfica de semáforo.

o! Una sección de administración de gráficas para procedimientos en trámite y concluidos que permita identificar pasos clave del procedimiento configurados en el BPM, que habilitarán banderas en una tabla resumen y que indicarán que se crearán gráficas adicionales del procedimiento en trámite y concluido.

o! Una sección de despliegue de gráficas resultantes.

o! Adicionalmente, cuando se dé clic sobre el número de folio del procedimiento se deberá mostrar una página de detalle con información relevante del procedimiento.

•! Delegación de actividades.

•! Actividades parametrizables.

•! La plataforma debe poder manejar diferentes calendarios aplicables a los procesos y actividades definidas.

•! Exportación de información en distintos formatos dependiendo de su naturaleza, por ejemplo: PDF, MsWord, Excel, JSON y XML.

•! Integración con herramientas ETL.

•! Uso de plantillas para la generación automatizada de documentos.

•! Mecanismo para generar reportes por configuración de manera rápida.

•! La plataforma deberá tener un mecanismo de auditoria que permita identificar los accesos y transacciones realizadas por los usuarios, sin que ello afecte del desempeño del sistema.

•! El sistema debe contar el mecanismo para solventar posibles errores debidos a errores de los usuarios, por ejemplo la posibilidad de realizar nuevamente alguna actividad o cancelar un procedimiento en ejecución. (Regreso de Pasos)

•! La transmisión de la información en la plataforma de ser mediante un canal cifrado.

•! Deberá estar totalmente integrada a los demás componentes tecnológicos de la solución, garantizando su compatibilidad para lograr agilidad en la ejecución de cambios y mantenimientos.

•! Capacidad de diagnosticar el desempeño de la base de datos utilizando trazas y vistas administrativas integradas a la plataforma.


INT010509RB0!!



Página 93 de 11

•! Cifrar los datos que residen en la base de datos empleando algoritmos de cifrado estándares de industria, como lo son DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, 256-bit AES.

•! Contar con la capacidad de restringir el acceso a la base de datos según políticas de acceso.

•! Proteger la privacidad y confidencialidad de la información eliminando la posibilidad de pérdida de información, robo y acceso no autorizado.

•! Enviar la traza de auditoría hacia una bitácora de sistema, de seguridad o a una localidad remota.

•! Permitir la definición de registros de auditoría a nivel granular de manera integrada en la gestión de la base de datos, permitiendo auditar consultas, modificaciones, actualizaciones, entradas, salidas; todo esto a nivel de Base de Datos, esquema, tabla.

•! Permitir el crecimiento de la solución de forma modular de acuerdo a las necesidades del INAI.

•! Contar nativamente con funcionalidades de compresión de datos almacenados a través de software.

•! Permitir la carga de datos en tablas a partir de archivos vía una herramienta de carga optimizada de la solución.

•! Soporte para grandes volúmenes de archivos. Se debe considerar el uso de un Administrador Empresarial de Contenido que cuente con los requerimientos tecnológicos y con la capacidad para manejar la información documental contenida sin que desmejore su rendimiento.

•! Como parte del proceso de auditoría, la solución deberá permitir el seguimiento a la información generada en la misma y a las tareas efectuadas por el personal que participa en el proceso, permitiendo la trazabilidad como un componente del mecanismo de seguridad.

•! Permitir la comunicación de interfaces a través de servicios web y el uso de APIS

•! Mecanismos de seguridad para acceso a la información (por documento, secciones, categorías, carpetas).

•! Exposición en portales e interfaces web del contenido de ciertas partes de los repositorios.

•! Proveer un panel de seguimiento que permita al usuario visualizar el estado de cada una de los procedimientos que administra la plataforma.

El sistema de gestión de medios de impugnación debe gestionar a través de flujos de trabajo las etapas procesales desde su inicio, hasta su resolución e incluso los


INT010509RB0!!



Página 94 de 11

eventos posteriores que de esta última deriven, como pueden ser el cumplimiento a la resolución o la impugnación ésta.

Procesos a implantar

Se deberán implementar los siguientes flujos:

•! Recursos de revisión.

•! Reposición de proceso.

•! Audiencias.

•! Accesos a información clasificada.

•! Acumulación.

•! Requerimiento de alcances.

•! Envío de alcances por parte del sujeto obligado.

•! Envío de información.

•! Cumplimiento a resoluciones.

•! Inconformidad.

•! Impugnación.

•! Medidas de apremio.

•! Inclusión de terceros interesados.

•! Atracción.

•! Recurso de inconformidad.

Recurso de revisión

Esté proceso permite la gestión de un recurso de revisión desde su ingreso hasta la notificación de la resolución.

La integración de recursos de revisión al Sistema se puede hacer mediante la importación de la información desde el sistema de solicitudes de acceso a la información o mediante el registro manual para aquellos casos en los que el recurrente presentó su recurso de revisión por escrito libre o medio impreso.

El proceso de recurso de revisión integra a algunos “subprocesos” que le permiten extender la funcionalidad, estos se describen a continuación:

Cumplimiento a resoluciones del Pleno


INT010509RB0!!



Página 95 de 11

Este proceso permite a la Dirección de Seguimiento a Resoluciones, vigilar que los sujetos obligados cumplan en tiempo y forma con las resoluciones emitidas por el Pleno del Instituto.

Inconformidad

Este es un subproceso asociado al Cumplimiento a Resoluciones, permite dar seguimiento a aquellos casos en los que un recurrente informa a la Dirección de Seguimiento a Resoluciones que no está conforme con la forma en que la Unidad de Transparencia dio cumplimiento a la resolución del Pleno.

Alcances Unidad de Transparencia

Éste subproceso está asociado al proceso de recurso de revisión y permite a las unidades de Transparencia enviar información que consideren pertinente para la resolución del recurso de su interés.

Envío de Información a la Unidad de Transparencia

Es un subproceso que permite enviar información a las unidades de Transparencia por parte de las Ponencias del Instituto, sin que se requiera una respuesta de parte de ellas, es decir, el envío de información es únicamente informativo.

Acuerdo de Trámite

Mediante el subproceso de acuerdo de trámite se pueden generar diferentes flujos: solicitud de audiencia, solicitud de acceso a información clasificada, solicitud de acumulación y notificación de acumulación a la Unidad de Transparencia o similar en el ámbito nacional.

Requerimiento de Alcances

El subproceso de alcances permite a las Ponencias solicitar a las unidades de enlace información adicional que el Comisionado Ponente considere necesaria o importante para la resolución del recurso de revisión.

Flujos de trabajo y Atención

Este módulo, fundamental para el sistema, será quien se encargue de generar, administrar y controlar todos los procesos requeridos para la gestión de los recursos de revisión, así como la configuración de tiempos, alertas y notificaciones necesarias.

Administración y publicación de formularios

Contar con un servicio que facilite el desarrollo de formas electrónicas para la captura y asociación a flujos de trabajo:

•! Creación y publicación de formas electrónicas.

•! Asociación a flujos.


INT010509RB0!!



Página 96 de 11

•! Manejo de versiones, de forma en que un cambio en una forma o flujo, no afecte los procesos que se encuentran en ejecución.

Cada proceso debe contar con un flujo asociado que deberá estar totalmente integrado y administrado por una solución que contenga:

•! Diseño e implementación de los flujos permitiendo a usuarios con conocimientos del proceso de negocio y posterior a una transferencia de conocimiento por parte de Intellego, puedan representar los pasos a seguir.

•! Ejecución y administración. Los flujos deberán poder realizar las siguientes actividades:

!! Podrán ser ejecutados desde los formularios.

!! Podrán ser ejecutados desde otros medios o sistemas.

!! Podrán ejecutar diferentes tareas.

!! Podrán contar con flujos asociados (subprocesos)

!! Podrán definirse tiempos promedio de resolución, con el fin de asignar notificaciones y alertas en caso de que dichos tiempos no se cumplan.

!! Podrán ser revisados y reiniciados manualmente en caso de errores no esperados.

Notificaciones y alertas

El sistema deberá poder emitir notificaciones y alertas:

•! La solución deberá permitir el envío de notificaciones automáticas definidas mediante reglas de negocio, ante eventos y cambios de estatus o cumplimiento o número de fechas predeterminadas en el proceso.

o! Las notificaciones deberán poder dirigirse a cualquiera de los involucrados

en el caso correspondiente e incluso a más de una parte simultáneamente.

o! La notificación podrá consistir en un correo electrónico, en cuyo cuerpo se integra un texto predefinido con contenido HTML más la información variable correspondiente.

o! Las notificaciones se podrán enviar como liga de acceso a los documentos y como archivo adjunto, considerando mecanismos de seguridad que solo permitan el acceso al documento notificado, mediante el uso de usuario, contraseña y certificado digital.


INT010509RB0!!



Página 97 de 11

o! Las notificaciones y alertas pueden ser tareas específicas asignadas en los flujos de trabajo.

o! Las notificaciones y alertas pueden ser generadas fuera de los flujos, en caso de que los tiempos promedio de respuesta no se cumplan o surjan errores no esperados.

o! Las notificaciones y alertas deben ser bajo la forma de: •! Correos

•! SMS (Solo usuarios recurrentes)

•! Redes sociales (Solo usuarios recurrentes)

Consulta y seguimiento al estado de los flujos

La plataforma deberá contar con herramientas de reporteo y visualización:

•! Visualización de los flujos en sus diferentes estados.

•! Manejar diferentes niveles de permisos, pudiendo filtrarse por diferentes niveles jerárquicos.

•! Posibilidad de crear reportes específicos.

Requisitos adicionales a la Funcionalidad

La solución deberá contar con los siguientes componentes de arquitectura tecnológica para garantizar la funcionalidad requerida y ofrecer funcionalidad adicional necesaria para la correcta operación del sitio del sistema:

o! Capacidad de almacenamiento y tratamiento de información y

evidencias en las diferentes etapas del proceso.

!! El Sistema deberá permitir ingresar y almacenar los diferentes documentos digitales, notas, pruebas y evidencias presentados durante las diferentes etapas del proceso. Esta información deberá ser almacenada en el sistema de manera integrada con el Administrador Empresarial de Contenido.

!! Proveer esquemas de colaboración entre los involucrados.

!! Mantener un histórico de la información o documentos utilizados en el proceso.

o! Capacidad de generar Flujos de trabajo asíncronos.

o! Interfaz para Dispositivos móviles, Tableta, Teléfonos inteligentes, Escritorio y Web. (Interfaz responsiva)

o! Motor para el manejo de Flujos de Trabajo síncrono y asíncrono.


INT010509RB0!!



Página 98 de 11

Módulos de apoyo al proceso

Expediente electrónico

El sistema debe ser capaz de gestionar la información documental asociada a los expedientes de los recursos de revisión considerando el ciclo de vida documental alineado a los procesos institucionales.

El listado de documentos que integran el expediente electrónico debe ser parametrizable, es decir, los administradores del sistema pueden definir que documentos recolectados durante la gestión de un recurso de revisión forman o no parte del expediente electrónico. Se debe poder configurar que documentos pueden ser agregados si no son recolectados durante la gestión, así como la visibilidad de los mismos de acuerdo a los roles de los usuarios.

Gestión documental

El sistema deberá ser capaz de almacenar documentos:

•! Almacenamiento de los contenidos documentales generados en los procesos y accesibles desde los procesos.

•! Soporte para grandes volúmenes de archivos. Se debe considerar que el Administrador Empresarial de Contenido cuente con los requerimientos tecnológicos y con la capacidad para manejar la información documental contenida sin que desmejore su rendimiento.

•! Soporte para el ciclo de vida de documentos (resguardo, acceso, destrucción, control de versiones).

•! Soportar diferentes formatos y tipos de documentos.

Importación de recursos de revisión

Para la gestión de un recurso de revisión el sistema deberá establecer comunicación con el sistema de solicitudes de acceso a la información a fin de que todos los recursos de revisión interpuestos por ese medio puedan ser importados al sistema de gestión de medios de impugnación en forma automatizada o a petición de un usuario con los privilegios necesarios.

El sistema de gestión de medios también debe poder acceder y en su caso importar la información de solicitudes de información interpuestas en el sistema de solicitudes de acceso a la información.

La aplicación debe permitir registrar un recurso de revisión en forma manual y validar los datos registrados versus la información de la solicitud asociada a ese recurso, esto con la finalidad de evitar errores humanos.


INT010509RB0!!



Página 99 de 11

Se debe poder crear una relación entre una misma solicitud de información y varios recursos de revisión es decir se debe poder dar seguimiento como un mismo expediente el proceso o procesos de reposición a una resolución.

Turnado de recursos de revisión

El sistema tendrá un módulo de turnado en el cual los usuarios con los roles adecuados podrán asignar los medios de impugnación a los comisionados.

Este módulo debe permitir turnar a uno, a varios o a todos los comisionados de acuerdo a la configuración que los usuarios encargados de su operación le den.

Este módulo debe poder identificar aquellos recursos de revisión cuya interposición es extemporánea y caracterizarlos en ese sentido.

Al momento de turnar los recursos de revisión se les deben asociar los plazos máximos para su resolución. En caso de que el calendario de días inhábiles asociado al proceso de recurso de revisión se modifique los plazos de resolución deberán actualizarse automáticamente.

Terceros interesados

Durante la gestión de un recurso de revisión debe ser posible la integración de uno o más actores nuevos a los cuales se les denominará “terceros interesados”, estos actores podrán ser notificados a los actos que ocurran a partir de su ingreso al proceso.

Si el tercero interesado es un usuario del sistema, se le debe de poder notificar a través de éste, de lo contrario a través de los otros mecanismos que provea el sistema, la información relativa a esas notificaciones debe quedar registrada en el sistema como parte del expediente electrónico.

Si el tercero interesado es un usuario del sistema debe poder enviar información al Instituto a través de la aplicación, siempre y cuando el estado del proceso en el que participa lo permita.

Módulo de atracción

El sistema deberá integrar un módulo en el cual un usuario con un rol específico podrá consultar todos los recursos de revisión que se han registrado a través de la Plataforma Nacional de Transparencia, en dicho módulo se podrán realizar consultas sobre la información de registro de los recursos de revisión, así como, en la información de registro de las


INT010509RB0!!



Página 100 de 11

solicitudes de información pública y datos personales a las que están asociados los recursos de revisión.

Detectado un recurso de revisión interpuesto ante alguna de las Entidades Federativas que cumpla con los criterios de atracción establecidos, deberá existir el mecanismo que permita la atracción del expediente correspondiente para ser resuelto por el INAI, sin que la Entidad Federativa y el recurrente pierdan vista del caso.

Módulos de Administración

Administración de grupos

Permite crear y modificar grupos de usuarios de la APF que serán usados para el envío de requerimientos y comunicados por parte de la Unidad Administrativa competente del INAI.

Registro de operadores de la Unidad de Transparencia

Este módulo permite a los Titulares de las Unidades de Transparencia de los sujetos obligados dar de alta usuarios que los apoyen con la atención de los asuntos que se les notifican a través del Sistema de Medios de Impugnación.

Registro de usuario del comité de información

Este módulo permite a los Titulares de las Unidades de Transparencia de los sujetos obligados registrar usuario con el perfil del comité de información, este perfil es de sólo lectura y puede tener vista a toda la información que se encuentra en el tablero de control del sujeto obligado en cuestión, pero sin posibilidad de ejecutar actividad alguna.

Módulo de regreso de pasos

Permite al INAI o a las Entidades Federativas en sus correspondientes flujos del proceso, el regreso a un estado previo con la finalidad de que los usuarios puedan corregir la información registrada en el sistema.

Módulo de cancelación de procesos

Permite al INAI o a las Entidades Federativas terminar procesos que se hubieran disparado por error en sus correspondientes flujos.

Administración de leyendas

Permite al INAI o a las Entidades Federativas definir una leyenda que será incluida en los correos electrónicos y/o notificaciones que sean enviados desde la aplicación. A la leyenda se le puede definir una vigencia.


INT010509RB0!!



Página 101 de 11

Módulo de asistentes

Esté módulo permite registrar usuarios como asistentes de otros usuario, con ello podrán atender las actividades de las cuales el usuario asistido es responsable.

Administración de calendarios

En él se pueden registrar distintos tipos de calendarios para los cuales se puede designar los días inhábiles que serán utilizados en la gestión de las actividades.

Organigrama

Permite dar de alta usuarios, roles y departamentos, así como definir las relaciones entre ellos.

Requerimientos no funcionales

Seguridad

La solución deberá ser completamente confiable, segura y escalable, por lo que debe cubrir estos aspectos desde su concepción arquitectónica, así como utilizar e implementar productos de administración y operación tanto de la solución como de los códigos y configuraciones fuente.

La arquitectura de la plataforma debe de contar con procesos y mecanismos para la mitigación de amenazas:

Falsificación:

o! La información presente en el portal debe contar con un estricto mecanismo de acceso, pudiendo ser vista, modificada e incluso borrada solo por los actores. Ningún actor no autorizado puede modificar la información contenida en la aplicación.

o! La información no puede ser borrada físicamente. En caso de ser requerido, esta puede únicamente ser borrada lógicamente, a menos que si naturaleza haga necesario un borrado físico.

No Repudiación:

o! Todas las operaciones dentro del portal, deberán estar adecuadamente autorizadas y registradas.

o! Las operaciones realizadas por los usuarios deben ser registradas con base en el mecanismo de autenticación definido por el INAI.

o! Todas las operaciones deberán dejar un registro de quien, cuando y que acción correspondió con dicha operación


INT010509RB0!!



Página 102 de 11

Revelar información:

o! Se debe tener especial cuidado en no revelar ni compartir información proporcionada por los ciudadanos, bajo los términos y lineamientos de la Ley Federal de Protección de Datos Personales en Posesión de Particulares (LFPDPPP)

o! Negación de servicio:

o! La plataforma debe ser altamente escalable y deberá contar con monitoreo continuo y esquemas de protección contra ataques de negación de servicio.

Elevación de privilegios

6.! Sistema de Comunicación entre Órganos Garantes y Sujetos Obligados

Se deberá configurar en el BPM con el que cuenta Sistema de Solicitudes de Información o con el BPM propuesto por Intellego previo Vo.Bo. de la DGTI del INAI, la funcionalidad existente en la Herramienta de Comunicación (HCom), contando con las siguientes características:

Características generales:

•! Plataforma web diseñada e implementada bajo los estándares de la industria.

•! Accesibilidad y usabilidad establecidos:

o! Estándares del W3C (Consorcio World Wide Web).

o! Guía para la Acción Pública (GAP). Los sitios web accesibles. Una herramienta para el acceso a la información y a la interacción en condiciones de igualdad: http://www.conapred.org.mx/userfiles/files/GAP-Web-OK-Accss.pdf

o! Ser fácil de utilizar.

o! Intuitivo.

o! Tener tiempos de respuesta ágiles.

o! Debe ser funcional e independiente del cliente en el que se ejecute.

•! La plataforma debe permitir el acceso mediante distintos mecanismos que permitan la integración con software Single Sign On.


INT010509RB0!!



Página 103 de 11

•! La plataforma debe permitir el uso de FIEL como mecanismo para la identificación de usuarios.

•! Firmado electrónico.

•! Manejo de flujos de trabajo configurables y adaptables en cualquier momento.

Posibilidad de extender la funcionalidad utilizando distintos medios como servicios web y módulos programados que se acoplen a la solución.

•! Mecanismos de envío de información como correo electrónico, SMS, mensajes a través del mismo sistema, configurables en su contenido y presentación.

•! Manejo de grupos de usuarios y grupos de sujetos obligados.

•! Administración de usuario y áreas de adscripción independiente de los procesos y funcionalidad del sistema.

•! Administración de unidades administrativas internas y externas al Instituto.

•! Administración por procesos o funcionalidades.

•! Administración de usuarios con distintos niveles de acceso a funcionalidad y/o información.

•! La herramienta deberá considerar un mecanismo que permita extraer información estadística y depositarla en tablas resumen, con la finalidad de construir un tablero de control que apoye la toma de decisiones, a través de semáforos, gráficos de barras y alertas a los usuarios de las entidades federativas, sujetos obligados y unidades administrativas, en el seguimiento a los procedimientos y los pasos que les son asignados dentro del flujo de trabajo que se configure en el BPM.

o! Dicho mecanismo deberá ser totalmente configurable y cada entidad federativa será responsable de su parametrización de acuerdo a la configuración de los procedimientos establecidos.

o! Los rubros considerados a ser graficados son los siguientes:

o! Procedimientos registrados, procedimientos en trámite, procedimientos concluidos y gestión interna de procedimientos.

o! Cabe mencionar que las gráficas mostrarán información relacionada con el alcance del usuario que está ingresando al módulo, es decir, dependiendo del perfil del usuario se mostrará la información de su competencia.

o! Así mismo, la herramienta deberá considerar como primer filtro para mostrar la información un periodo de tres meses anteriores a la fecha actual, esto con la finalidad de no afectar el desempeño de la herramienta.

o! Procedimientos registrados (totalidad de recursos de revisión y recursos de inconformidad)


INT010509RB0!!



Página 104 de 11

o! Gráfica de barras con el número de procedimientos registrados distribuidos por año, el dar clic sobre alguna de las barras permitirá mostrar una nueva gráfica de barras con el detalle del año seleccionado distribuyendo los procedimientos registrados por mes, este mecanismo se utilizará para mostrar información por semana del año y en la última gráfica por día, al dar clic sobre una barra de día, la aplicación mostrará una tabla con todos los procedimientos registrados en el día seleccionado donde se podrá visualizar el número de folio, la fecha de registro, entidad federativa, sujeto obligado y el nombre del particular.

o! Los filtros adicionales que deberá contemplar esta gráfica serán: sector, entidad federativa, sujeto obligado, nombre del particular y periodo, las opciones de filtrado se descartarán de acuerdo al alcance del usuario registrado.

o! Procedimientos en trámite (Con fecha de registro y sin fecha de conclusión)

o! Grafica de barras apiladas con colores de semáforo, se requiere que cada nivel de usuario (administrador general, administrador de entidad federativa y administrador de sujeto obligado) tenga la opción de configurar el número de días para cada uno de los tres rangos (rojo, amarillo y verde), cuando el usuario dé clic sobre alguno de los colores será necesario mostrar la tabla con el listado de los procedimientos en trámite que corresponda, adicionalmente, se requiere que se implemente un mecanismo que alerte a los usuarios del tablero cuando un procedimiento pase de un rango a otro, esta alerta se debe realizar vía correo electrónico dependiendo de la configuración establecida por el usuario.

o! La tabla de detalle que se deberá mostrar al dar clic sobre alguno de los tres colores de semáforo de la gráfica contendrá la siguiente información: número de folio, fecha límite de atención, días naturales entre la fecha límite de atención y la fecha actual, en su caso, número de folios turnados a ponencias, número de folios concluidos que fueron turnados a las ponencias, vínculo a una tabla que muestre los folios turnados y generados para dicho procedimiento, el orden para mostrar la información deberá ser de acuerdo a los días naturales entre la fecha límite de atención y la fecha actual de menor a mayor.

o! La tabla que contendrá el detalle de los folios turnados a las ponencias debiendo mostrar la siguiente información: estado del folio (Pendiente o Concluido), número de folio, ponencia, fecha de turnado y en su caso fecha de respuesta.

o! Procedimientos concluidos (fecha de conclusión)

o! Gráfica de barras apilada con dos elementos, el primero de ellos con el total de procedimientos concluidos y el segundo con el número de procedimientos en trámite.


INT010509RB0!!



Página 105 de 11

o! Gestión interna de procedimientos

o! La herramienta deberá generar gráficas de barras con el número de procedimientos que han sido turnados a las diferentes ponencias, al dar clic sobre alguna de las barras se deberá mostrar una tabla detalle con la siguiente información: folio, fecha de turnado, fecha de respuesta, y los días transcurridos entre las dos fechas anteriores.

o! La herramienta deberá generar gráficas de barras con el número de procedimientos que fueron asignadas a las diferentes ponencias y que se encuentran pendientes de atención, al dar clic sobre alguna de las barras se deberá mostrar una tabla detalle con la siguiente información: folio, fecha de turnado, fecha de respuesta y los días transcurridos entre las dos fechas anteriores.

o! Los filtros disponibles para este tipo de gráficas deben considerar: sujeto obligado, ponencia y periodo.

o! En resumen el módulo de tablero de control deberá contar con:

o! Una sección de administración que permita configurar el nombre y correo electrónico de las personas que recibirán las alertas

o! Una sección de administración que permita configurar los rangos (rojo, amarillo y verde) que serán establecidos para la gráfica de semáforo.

o! Una sección de administración de gráficas para procedimientos en trámite y concluidos que permita identificar pasos clave del procedimiento configurados en el BPM, que habilitarán banderas en una tabla resumen y que indicarán que se crearán gráficas adicionales del procedimiento en trámite y concluido.

o! Una sección de despliegue de gráficas resultantes.

o! Adicionalmente, cuando se dé clic sobre el número de folio del procedimiento se deberá mostrar una página de detalle con información relevante del procedimiento.

•! Delegación de actividades.

•! Actividades parametrizables.

•! La plataforma debe poder manejar diferentes calendarios aplicables a los procesos y actividades definidas.

•! Exportación de información en distintos formatos dependiendo de su naturaleza, por ejemplo: PDF, MsWord, Excel, JSON y XML.

•! Integración con herramientas ETL.

•! Uso de plantillas para la generación automatizada de documentos.


INT010509RB0!!



Página 106 de 11

•! Mecanismo para generar reportes por configuración de manera rápida.

•! La plataforma deberá tener un mecanismo de auditoria que permita identificar los accesos y transacciones realizadas por los usuarios, sin que ello afecte del desempeño del sistema.

•! El sistema debe contar el mecanismo para solventar posibles errores debidos a errores de los usuarios, por ejemplo la posibilidad de realizar nuevamente alguna actividad o cancelar un procedimiento en ejecución.

•! La transmisión de la información en la plataforma debe ser mediante un canal cifrado.

•! Deberá estar totalmente integrada a los demás componentes tecnológicos de la PNT, garantizando su compatibilidad para lograr agilidad en la ejecución de cambios y mantenimientos.

•! Capacidad de diagnosticar el desempeño de la base de datos utilizando trazas y vistas administrativas integradas a la plataforma.

•! Cifrar los datos que residen en la base de datos empleando algoritmos de cifrado estándares de industria, como lo son DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bit RC4, DESX, 128-bit AES, 192-bit AES, 256-bit AES.

•! Contar con la capacidad de restringir el acceso a la base de datos según políticas de acceso.

•! Proteger la privacidad y confidencialidad de la información eliminando la posibilidad de pérdida de información, robo y acceso no autorizado.

•! Enviar la traza de auditoría hacia una bitácora de sistema, de seguridad o a una localidad remota.

•! Permitir la definición de registros de auditoría a nivel granular de manera integrada en la gestión de la base de datos, permitiendo auditar consultas, modificaciones, actualizaciones, entradas, salidas; todo esto a nivel de Base de Datos, esquema, tabla.

•! Permitir el crecimiento de la solución de forma modular de acuerdo a las necesidades del INAI.

•! Contar nativamente con funcionalidades de compresión de datos almacenados a través de software.

•! Permitir la carga de datos en tablas a partir de archivos vía una herramienta de carga optimizada de la solución.

•! Soporte para grandes volúmenes de archivos. Se debe considerar el uso del Administrador Empresarial de Contenido incluido en el sistema de solicitudes de información siempre y cuando este último cuente con los requerimientos


INT010509RB0!!



Página 107 de 11

tecnológicos y con la capacidad para manejar la información documental contenida sin que desmejore su rendimiento.

•! Como parte del proceso de auditoría, la solución deberá permitir el seguimiento a la información generada en la misma y a las tareas efectuadas por el personal que participa en el proceso, permitiendo la trazabilidad como un componente del mecanismo de seguridad.

•! Permitir la comunicación de interfaces a través de servicios web y el uso de APIS

•! Mecanismos de seguridad para acceso a la información (por documento, secciones, categorías, carpetas).

•! Exposición en portales e interfaces web del contenido de ciertas partes de los repositorios.

•! Proveer un panel de seguimiento que permita al usuario visualizar el estado de cada una de los procedimientos que administra la plataforma.

El sistema de herramienta de comunicación debe gestionar a través de flujos de trabajo la comunicación entre el INAI, las Entidades Federativas y los Sujetos Obligados.

Procesos a implantar

Se deberán implementar los siguientes flujos:

•! Envío de comunicado a los sujetos obligados.

•! Requerimientos a los sujetos obligados.

•! Consultas por parte de los sujetos obligados al Instituto.

Comunicado a los sujetos obligados

Este proceso debe permitir al INAI y Entidades Federativas enviar información a una, varias o todas la unidades de transparencia de los Sujetos Obligados a nivel nacional, este proceso es unidireccional, es decir los destinatarios no tienen oportunidad de dar respuesta a la información que reciben.

Requerimiento a los sujetos obligados

Este proceso debe permitir al INAI y Entidades Federativas solicitar información a una, varias o todas la unidades de transparencia de los Sujetos Obligados a nivel nacional a través de una sola petición y se dará seguimiento de manera independiente a cada uno de los destinatarios.

Consultas por parte de los sujetos obligados al Instituto

Permite a las Unidades de Enlace de la APF enviar a la DGCV preguntas, dudas o solicitud de aclaración sobre algún tema relacionado con el ámbito de competencia


INT010509RB0!!



Página 108 de 11

del Instituto. Este proceso usa un subproceso para el turnado a las diferentes áreas dentro del Instituto y en su caso solicitar información adicional a las Unidades de Enlace.

7.! Motor de Búsqueda

Buscador de la Plataforma Nacional de Transparencia: El buscador tiene como objetivo permitir realizar búsquedas en la información de todos los sujetos obligados a nivel nacional, el alcance de este comprende los siguientes elementos:

•! Realizar los siguientes tipos de búsquedas:

o! No estructurada. o! Estructurada o categorizada.

•! Filtrar (detallar) los resultados encontrados al añadir más palabras

clave.

•! Indexar información contenida en documentos en formato HTML, MS Word, MS Excel, PDF, Power Point y texto plano así como archivos XML.

Tipos de búsqueda

La solución informática permitirá responder eficientemente al menos a dos tipos de búsqueda:

No estructurada:

Será posible buscar información por medio de la introducción de palabras o frases y deberá regresar al menos la información relacionada con la o las fracciones que contengan ese dato. La solución deberá aplicar conceptos de usabilidad que faciliten las consultas al público. Asimismo el sistema deberá realizar búsquedas en el contenido de los archivos que se anexen a la información publicada.

Estructurada o categorizada:

La solución permitirá realizar consultas estructuradas o por categorías. La solución deberá aplicar conceptos de usabilidad que faciliten las consultas a la ciudadanía.

Independientemente del tipo de búsqueda, la solución informática deberá:


INT010509RB0!!



Página 109 de 11

•! Utilizar diccionarios de términos, afinidad de conceptos, decodificación de abreviaturas y demás facilidades que permitan localizar bajo el idioma español la información deseada.

•! Filtrar los resultados de las búsquedas a fin de identificar con mayor puntualidad la información deseada.

•! El acceso a la información fuente en su formato original, en caso de existir.

•! Ser tolerantes a variaciones en palabras tales como plural, singular, genero, mayúsculas, minúsculas, acentos, sinónimos.

•! Enfocar los resultados de las búsquedas a usuario final, es decir, aplicando criterios de usabilidad y en lenguaje “natural”

La herramienta de búsqueda con la que cuente el sistema deberá permitir realizar búsquedas utilizando sinónimos, los cuales deberán relacionarse con los títulos de la información estructurada.

Buscador de Información (Search engine)

El buscador deberá permitir la realización de búsquedas, basadas en palabras claves, y también búsquedas estructuradas o que consideren varios parámetros de búsqueda.

El Buscador de Información utilizado deberá presentar los resultados categorizados de acuerdo a diferentes criterios como:

•! Sujeto obligado que generó la información.

•! Tipo de Información.

•! Otras categorías relacionadas a la información de transparencia que se tenga contenida en el portal.

El buscador de información deberá permitir hacer drill-down o refinación de los resultados encontrados cuando el usuario seleccione una categoría de resultados encontrada y al añadir más palabras clave para refinar los resultados.

El buscador deberá poder instalarse en cuantos servidores sea necesario, considerando que soporte múltiples consultas concurrentes por segundo y que tenga capacidad de indexar grandes cantidades de información distribuida en diferentes contenedores.

El buscador de información deberá permitir indexar información contenida en al menos documentos en formato HTML, MS Word, Ms Excel, PDF, PowerPoint, así como textos plano y archivos XML.


INT010509RB0!!



Página 110 de 11

El buscador de información deberá tener un conector para indexar información contenida en las bases de datos más comunes (Oracle, MsSQL, MySQL).

El buscador de información deberá poder consumir información o datos que estén contenidos en otros portales web, manteniendo siempre una referencia al portal web que haya sido la fuente de información.

El buscador de información deberá permitir búsquedas mediante palabras claves, así como búsquedas avanzadas utilizando diferentes parámetros o campos que existan en la información integrada.

El buscador de información deberá tener un módulo de lingüística avanzada donde puedan definirse diccionarios, sinónimos, equivalencias de palabras. Deberá contar con soporte nativo para el idioma español.

El buscador de información deberá contar con una consola de administración que permita configurar los flujos de integración de contenido, y con una consola de administración que permita conocer estadísticas sobre las búsquedas realizadas en el portal, así como conocer estadísticas sobre las búsquedas de información fallidas.

El buscador de información deberá permitir ajustar el orden en que aparecen los resultados de las búsquedas, de modo que sea posible ajustar la relevancia de los resultados, o en dado caso, asignar prioridad a ciertos resultados que se deseen resaltar.

El buscador de información deberá contar con una interface de programación de aplicaciones (API) basada en Java.

Base de datos

La base de datos deberá estar certificada para trabajar con el servidor de aplicaciones Java que será incluido en la solución. La base de datos deberá contar con un driver basado en la tecnología JDBC.

8.! Pruebas a la PNT

Se realizarán las pruebas conforme a los términos de la convocatoria:

•! Pruebas unitarias.

•! Pruebas de interfaz de usuario.

•! Pruebas de migración.

•! Pruebas de rendimiento.

•! Pruebas de esfuerzo.

•! Pruebas de carga.

•! Pruebas de volumen.


INT010509RB0!!



Página 111 de 11

•! Pruebas de fallas, recuperación y operación.

•! Pruebas de interfaces entre sistemas.

•! Pruebas de seguridad y control de acceso.

•! Pruebas de integridad de los datos y de la base de datos.

•! Pruebas funcionales.

•! Pruebas de usuario.

•! Pruebas integrales

9.! Bolsa de horas de desarrollo

Se requiere una bolsa de 7,200 horas de desarrollo para solventar adecuaciones a la Plataforma Nacional de Transparencia originadas por cambios de alcance, motivados por la funcionalidad requerida en la documentación legal que adicionalmente se vaya a publicar durante la vigencia del proyecto, tales como Reglamentos, Lineamientos, Leyes de Transparencia nuevas a nivel Federal o Estatal.

10.!Entregables

Proponemos a la convocante elaborar un plan de trabajo detallado que no vaya más allá de las fechas de los términos de la convocatoria y las precisiones de las juntas de aclaraciones en las que en diciembre de 2015 ya se tengan los productos terminados como lo pide la convocatoria.

Componente 1.- Sistema para Solicitudes de Acceso a la Información

Productos:

Entregable: Sistema Descripción Tiempo de Entrega: conforme al plan de trabajo acordado entre ambas partes.

Integración a la PNT del Sistema de Solicitudes de Acceso a la Información

Componente 2.- Sistema de Obligaciones de Transparencia

Productos:


Integración a la PNT del Sistema de Obligaciones de Transparencia


INT010509RB0!!



Página 112 de 11

Componente 3- Sistema de Gestión de Medios de Impugnación (Recurso de Revisión y Atracción)

Productos:


Integración a la PNT del Sistema de Medios de Impugnación

Componente 4- Sistema de Comunicación entre Órganos Garantes y Sujetos Obligados

Productos:


Integración a la PNT del Sistema de Comunicación entre Órganos Garantes y Sujetos Obligados

Componente 5- Motor de Búsqueda

Productos:


Integración a la PNT del Buscador de información estructurada y no estructurada a nivel nacional

Componente 6- Bolsa de horas de desarrollo

Productos:

Entregable: Software Descripción Tiempo de Entrega: A partir de la notificación del fallo

Desarrollo de funcionalidad en la PNT que se encuentre fuera del alcance descrito en este anexo.

Ambientes de la PNT que debe entregar el licitante ganador.


INT010509RB0!!



Página 113 de 11

Intellego entregará 3 ambientes de la PNT funcionando y con toda la documentación específica de cada instalación:

1.! Ambiente de Desarrollo – conforme al plan de trabajo acordado entre ambas partes.Ambiente de Pruebas – conforme al plan de trabajo acordado entre ambas partes.

2.! Ambiente de Producción – conforme al plan de trabajo acordado entre ambas partes.

11.!Garantía

El licitante ganador proporcionará una garantía de 6 meses contra defectos e insuficiencias en la implementación de la funcionalidad de este proyecto. Los 6 meses se contabilizarán a partir de la fecha de entrega y aceptación del proyecto. Asimismo, Intellego quedará obligado ante el Instituto a responder de los defectos y vicios ocultos y calidad de los servicios, así como de cualquier otra responsabilidad en que incurra, de conformidad con lo establecido en el artículo 52, Segundo Párrafo, del Reglamento de Adquisiciones, Arrendamientos y Servicios del Instituto Federal de Acceso a la Información y Protección de Datos.

12.!Vigencia de la Contratación

La contratación tendrá una vigencia que comprende a partir de la notificación del fallo y hasta el 31 de diciembre de 2015.

13.!Propiedad Intelectual

Intellego será el único responsable, para el caso de que al prestar los servicios objeto de este contrato al INAI, haga uso indebido de marcas o viole derechos de autor u otros derechos de propiedad intelectual, eximiendo de toda responsabilidad al Instituto.

En el caso de que durante la prestación de los servicios, se diera la creación de obras, éstas se considerarán realizadas en virtud de una obra por encargo de conformidad con el artículo 83, de la Ley Federal del Derecho de Autor vigente, por lo que la titularidad de cada uno de los derechos patrimoniales sobre las mismas corresponderá al Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales concerniéndole las facultades relativas a su divulgación, integridad y de colección sobre este tipo de creaciones.

Bajo el supuesto señalado en el párrafo inmediato anterior, Intellego se obliga a suscribir los contratos de cesión de derechos, cartas de colaboración remunerada, o cualesquiera instrumentos necesarios para la acreditación o constitución en favor del “INAI” de los derechos de propiedad intelectual generados.


INT010509RB0!!



Página 114 de 11

14.!Forma de Pago

Los pagos se tramitarán conforme a la normatividad vigente del INAI y se efectuarán en moneda nacional, con base en la recepción del servicio, a entera satisfacción de la Dirección General de Tecnologías de la Información del INAI.

El pago se realizará en una sola exhibición por cada uno de los entregables del proyecto descritos en el apartado “Entregables”, contra entrega y aceptación de los trabajos por parte de la Dirección General de Tecnologías de la Información y no podrá exceder de veinte días naturales contados a partir de la entrega de la factura respectiva, previa entrega de los bienes o prestación de los servicios de conformidad con lo establecido en el Artículo 50, del Reglamento de Adquisiciones, Arrendamientos y Servicios del Instituto Federal de Acceso a la Información y Protección de Datos; Así como el Capítulo X, Numeral 16 de las Bases y Lineamientos en Materia de Adquisiciones, Arrendamientos y Servicios del Instituto Nacional de Transparencia, Acceso a la Información y Protección de Datos Personales.

15.!Pena Convencional

Conforme a los términos de la convocatoria.

Documents

ANEXO 1 PROPOSICIÓN TÉCNICApntdocumentos.inai.org.mx/templates/jf_taman/contenido/... · 2016-06-26 · “Desarrollo de la Plataforma Nacional de Transparencia Primera Etapa