PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE RIGE LA CELEBRACIÓN DEL CONTRATO DE SERVICIOS DE DESARROLLO, MANTENIMIENTO Y SOPORTE DE APLICACIONES Y SISTEMAS CON DESTINO LA D. G. DE ORDENACIÓN DEL JUEGO

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE RIGE LA CELEBRACIÓN DEL CONTRATO DE SERVICIOS DE DESARROLLO, MANTENIMIENTO Y SOPORTE DE APLICACIONES Y SISTEMAS CON DESTINO LA D. G. DE ORDENACIÓN DEL JUEGO

I.- ÁMBITO

II.- ALCANCE Y ACTIVIDADES DE LOS SERVICIOS III.- PRESTACIÓN DE SERVICIOS

IV.- MODELO DE SERVICIOS

XXXXX X: MARCO DE REFERENCIA DE LA DIRECCIÓN GENERAL DE ORDENACIÓN DEL JUEGO ANEXO II: DESCRIPCIÓN DEL TRAMITADOR

ANEXO III: INDICADORES PARA LA EVALUACIÓN DE LA CALIDAD DEL SERVICIO

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 1 de 75-

I.- Ámbito.

En esta cláusula se especifican los requerimientos técnicos de la contratación. Estas especificaciones abarcan tanto la descripción y caracterización del entorno físico y lógico en el que se ejecutarán los servicios, como la definición a alto nivel de los distintos lotes de servicios a contratar.

1.- Servicios

Las principales líneas de servicios objeto de este contrato y recogidas en el presente pliego de prescripciones técnicas (en adelante, PPT) se pueden agrupar en cuatro lotes diferenciados:

• Servicios de desarrollo, mantenimiento y soporte de aplicaciones y sistemas en el ámbito de las actuaciones de Inspección del Juego: Desarrollo, soporte y mantenimiento de las aplicaciones y sistemas que sustentan las actuaciones de la Subdirección General de Inspección del Juego, sin olvidar el soporte técnico a usuarios.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Servicios de desarrollo, mantenimiento y soporte en el ámbito de la tramitación electrónica: Desarrollo de nuevas funcionalidades, mantenimiento correctivo y evolutivo, así como soporte técnico a usuarios de las aplicaciones que permiten la tramitación electrónica de las personas físicas y jurídicas en sus relaciones con la Dirección General de Ordenación del Juego (en adelante, DGOJ).

• Servicios de desarrollo, mantenimiento y soporte en el ámbito de las aplicaciones corporativas de gestión del juego y servicios horizontales: Desarrollo de nuevas funcionalidades, mantenimiento correctivo y evolutivo, soporte técnico a usuarios de las aplicaciones corporativas de la DGOJ, así como servicios horizontales y de integración que se facilitan a todas las aplicaciones.

• Servicios de gestión y soporte de carácter horizontal: En este lote se engloban las actividades de carácter horizontal destinadas a gestionar y dar soporte al resto de lotes con el fin de asegurar unos mínimos de calidad de los productos entregados por parte de los distintos contratistas, una gestión y seguimiento eficiente de los trabajos realizados mediante la Oficina Técnica de Proyectos, El cumplimiento y desarrollo de la normativa y políticas vigentes en materia de seguridad, así como el centro de atención a usuarios.

Aparte de las actividades específicas para cada servicio, el adjudicatario deberá realizar una serie de actividades orientadas a controlar los niveles de servicio del presente contrato.

En la descripción de los servicios a ejecutar se incluye, para cada uno de ellos, las actividades que como mínimo debe realizar el adjudicatario y los productos a obtener.

El adjudicatario deberá organizar la prestación de los servicios de acuerdo a una resolución eficaz y eficiente de las incidencias y peticiones, y por tanto, considerando siempre los ámbitos de usuarios a los que prestará soporte.

2.- Caracterización del entorno

2.1.- Infraestructura tecnológica de la DGOJ

Las tareas a efectuar dentro de los distintos lotes se realizarán sobre la infraestructura tecnológica de la DGOJ, que de forma resumida se puede describir en:

• Sistema Operativo: Red Had Linux 6.0 o superior.

• Servidor de aplicaciones: Tomcat ó 8.x o superior.

• Servicios web sobre tecnología Tomcat CFX y PLT

• Servicio de identidades: SSO desarrollado ad-hoc por la DGOJ basado en LDAP o XXXX.

• Base de datos:

⮚ Oracle 12C con Data Guard, Advanced Security y Data Vault.

⮚ HP Vertica 7.2.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 2 de 75-

• Plataforma corporativa de descarga de ficheros: Axway Synchrony.

• Herramienta de análisis y explotación de datos de Inspección: Hp Vertica y PowerBI.

• Infraestructuras proporcionadas por un proveedor de hosting y administrados por él:

⮚ Balanceadores F5.

⮚ Cabina de almacenamiento.

⮚ Seguridad (doble capa de elementos de seguridad más una capa adicional basada en IMPERVA).

⮚ Gestor documental Alfresco. La DGOJ sólo se encarga de definición de usuarios y permisos.

⮚ Gestor de contenidos: Drupal.

⮚ Gestor de base de datos MySQL, que da servicio tanto a Drupal como a Alfresco.

• Desarrollos basados en J2EE, versión de JDK: 1.7.

• Suite soluciones Secretaría de Estado de Administraciones Públicas.

⮚ @firma.

⮚ Sistema de Intermediación de Certificados.

⮚ Registro de Apoderamientos.

⮚ Pasarela de pagos para el abono de tasas.

⮚ Cl@ve.

⮚ Notific@.

• Entorno de preproducción y desarrollo con mismas funcionalidades y servicios que el entorno de producción.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Adicionalmente, en el Anexo I se encuentran más detalles sobre la metodología a aplicar en el desarrollo y referencias al entorno tecnológico.

2.2.- Seguimiento de proyectos y aplicación de metodologías de desarrollo sw

La DGOJ dispone de una serie de herramientas corporativas para el seguimiento de proyectos y ayuda al desarrollo:

• Project para la gestión temporal de los proyectos.

• GLPI para la gestión de las incidencias y solicitudes de los usuarios internos de la DGOJ.

• Alfresco/share como repositorio de documentación viva de los proyectos (wiki).

• Redmine como herramienta de ticketing y reporte de horas de los trabajos realizados en el ámbito de desarrollo.

• Testlink como herramienta para la centralización de casos de prueba y el reporte de ejecuciones.

• Selenium y junit para el desarrollo de pruebas automáticas.

• Maven, SVN y Xxxxxxx para la gestión del código e integración continua.

2.3.- Sistemas Linux

La DGOJ dispone de una planta de alrededor de 70 sistemas Linux, típicamente destinados a soportar servidores de aplicaciones (Tomcat) o Bases de Datos (Oracle).

Aunque son administrados por el proveedor tecnológico de Hosting y Housing (se ocupa de la administración, mantenimiento, monitorización, parcheo, ...), la DGOJ tiene cierta autonomía para utilizar dichos sistemas y obtener cierta información (como por ejemplo rendimiento, acceso a archivos de logs de las aplicaciones o a ficheros generados por las mismas, …).

Salvo las máquinas destinadas a albergar las bases de datos, se trata de máquinas virtuales (algo totalmente transparente para la DGOJ) y el acceso a las mismas se realiza a través de autenticación integrada con el LDAP.

2.4.- Performance y mantenimiento de base de datos

La DGOJ cuenta con dos servicios de bases de datos Oracle completamente diferenciados, pero entre los que existe cierto intercambio de información:

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 3 de 75-

• Gestión: sede electrónica, aplicaciones de juego y servicios web ofrecidos a los operadores.

• Inspección: descarga de ficheros de juego de los Sistemas de Control Interno de los Operadores de Juego.

Ambos entornos tienen sus correspondientes entornos de pruebas y producción y cuentan con las siguientes opciones y herramientas:

• Data Guard.

• Data Vault.

• Data Encription.

• Grid Control.

• Rman.

• Data Compression.

La administración de las bases de datos en su totalidad es realizada por la DGOJ.

2.5.- Entornos de análisis de datos de la SG. de Inspección

La DGOJ dispone de un entorno de análisis diferenciado de los sistemas de explotación, orientado a la S. G. de Inspección del Juego, con entorno de pruebas y producción.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Para el análisis preliminar y exploraciones iniciales se dispone de un cluster del producto HP Vertica, que gestiona y mantiene nuestro proveedor tecnológico. La extracción de datos a esta plataforma se hace con la herramienta de software libre Talend, y la explotación con el cliente de software libre Squirrel.

II.- Alcance y actividades de los servicios.

Los trabajos previstos en el Plan director de sistemas de información y comunicaciones de la DGOJ (en lo sucesivo Plan director de la DGOJ) tienen un alto grado de dependencia de las necesarias especificaciones funcionales de los responsables de los servicios prestados en el ejercicio de las competencias atribuidas, de desarrollos normativos previstos o no, de las actuaciones de otras entidades con las que se relacionan los sistemas informáticos de la DGOJ, e incluso de los cambios de prioridades propiciados por los mencionados responsables de los servicios.

Por consiguiente, el número de entregas o prestaciones incluidas en el presente contrato no pueden definirse con exactitud al tiempo de conformar el presente pliego, estableciéndose un presupuesto máximo por cada uno de los lotes de contratación en forma de número de Unidades de Trabajo (UTs) estimadas a proporcionar (Umbral de UTs máximo).

Por cada lote de contratación se especificará el número de unidades de trabajo (UT) estimadas (Umbral de UT) a proporcionar, entendiendo a los efectos de esta contratación la fórmula de conversión y los coeficientes de ponderación reflejados en el ANEXO X “ESTIMACIÓN DE UNIDADES DE TRABAJO Y FÓRMULA DE CONVERSIÓN” xxx Xxxxxx de Cláusulas Administrativas (en adelante PCAP) que rige la presente contrato.

1.- Lote 1: Servicios de desarrollo, mantenimiento y soporte de aplicaciones y sistemas en el ámbito de las actuaciones de Inspección del Juego

El lote 1 es el dedicado al soporte y mantenimiento de las aplicaciones y sistemas que sustentan las actuaciones de la Subdirección General de Inspección del Juego, unidad encargada de la auditoría, vigilancia, inspección y control del juego online, así como la investigación y persecución del juego ilegal. De entre las tareas encomendadas a esta Subdirección, destaca la monitorización y seguimiento de las operaciones de juego (protección de menores, investigación del fraude, colaboración en la investigación en materia de blanqueo de capitales) acorde al mantenimiento de los distintos sistemas desarrollados a tal efecto. Es decir, la actividad de juego de los operadores está sometida a monitorización permanente, en particular, la identificación de los participantes, los premios otorgados y la devolución de participaciones en los supuestos de anulación de juegos.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 4 de 75-

La labor de monitorización consiste en el análisis de la información que proporcionan de forma regular los propios operadores supervisados de acuerdo con la normativa en vigor (xxxx://xxx.xxxxxxxxxxxxxxx.xx/xx/xxxxxxx-xxxxxxx- SCI) con el objetivo de mantener un estrecho seguimiento de la situación de los mismos y detectar, con premura suficiente en la mayor parte de los casos, posibles situaciones de riesgo.

1.1.- Entorno funcional existente asociado al lote 1

1.1.1.- Aplicaciones y sistemas que dan servicio a la S. G. de Inspección del Juego

De entre las funciones atribuidas a la Dirección General de Ordenación del Juego se incluye la regulación, autorización, supervisión, coordinación, control y, en su caso, sanción de las actividades de juego de ámbito estatal.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

La primera de las competencias de la DGOJ es la organización y control de las actividades de juego a través de su monitorización y supervisión, para lo cual se establece para los operadores la obligación de implantar en su sistema técnico de juego un Sistema de Control Interno (en adelante SCI) que capture y registre la totalidad de las operaciones de juego y las transacciones económicas que se realicen entre los participantes y la unidad central de juegos del propio operador. Este sistema permite que las labores inspectoras de supervisión y control puedan realizarse de forma electrónica, siendo un sistema pionero en habilitar la vía electrónica como un nuevo medio de relación con el regulado y de refuerzo y cumplimiento de la política pública.

La DGOJ cuenta para el cumplimiento de las competencias anteriormente descritas con la aplicación NAIPE (en producción desde 2013) cuyo cometido es precisamente descargar y almacenar en los sistemas informáticos del organismo, con objeto de un posterior análisis, toda la información sobre las transacciones que registran los operadores de juego online realizadas por los jugadores cuando juegan a través de las páginas web que ellos ofrecen a través de internet (lo que se conoce como “evidencias de juego”). NAIPE se conecta a ellos diariamente para descargar los ficheros, que se encuentran en formato XML, y guardarlos en los sistemas de ficheros de la organización, así como en una estructura de base de datos. NAIPE se encarga tanto de la recepción de la información del SCI, como de su descompresión, carga en base de datos, validación y evaluación de la calidad.

Desde el punto de vista de la arquitectura, NAIPE se basa en un producto comercial de transferencia de ficheros, Axway Suite 5 (anteriormente Axway Synchrony), que se reparte en varios módulos, cada uno con una funcionalidad específica (Integrator para procesamiento de ficheros, Gateway para transferencia, Secure Relay como intermediario en la conexión, Composer para definir y modificar flujos de transformación de datos, y Sentinel para monitorización de cargas). Puesto que este software sólo se encarga de transferir ficheros sin ningún tipo de inteligencia adicional, sobre él se ha construido una aplicación web programada en Java-J2EE (framework Java Server Faces con Spring e Hibernate) sobre un servidor de aplicaciones Apache Tomcat, que constituye precisamente la interfaz gráfica de NAIPE utilizada por los usuarios de la aplicación, y que les permite llevar la gestión de las planificaciones de carga, las validaciones y la calidad de los ficheros, así como la monitorización periódica de los ficheros que han sido cargados y los que no. También hace recuento de los errores de los ficheros, extrae muestras de los errores para enviarlas a los operadores, permite activar o desactivar registros, guarda traza de auditoría de todo lo que se hace con ella, y otras interesantes funcionalidades que la convierten en una aplicación única en su especie.

En los últimos años, XXXXX ha asimilado la evolución del modelo de datos de los ficheros que reportan los operadores (versión 2 del XSD), la incorporación de nuevos tipos de juego, la inclusión de las redes de juego, y ha experimentado una mejora de algunas de sus funcionalidades con el fin de potenciar su productividad y eficiencia, aumentando su usabilidad y convirtiéndola en un activo de primer orden.

NAIPE ha permitido al área de Inspección llevar a cabo investigaciones de vital trascendencia para el organismo. De hecho, se puede decir que es la aplicación que sustenta la mayor parte de la actividad de toda la Subdirección General de Inspección del Juego. Por eso, su evolución y perfeccionamiento tienen una importancia capital. Sin embargo, la información tal como se cargaba en base de datos adolecía de ciertos problemas: extenso volumen, consultas con elevados tiempos de respuesta, mucha información redundante, que eclipsaba los datos realmente relevantes… Se hizo necesario tratar dicha información con el objeto de poder tener indicadores no solo sobre la evolución individual de

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 5 de 75-

cada operador x xxx xxxxxxx, sino también sobre tendencias de comportamiento entre jugadores u operadores que puedan delatar algún compartimiento ilícito.

De ahí surgió un ecosistema de aplicaciones y procesos que hacen uso de la misma, reestructurándola y dotándola de sentido desde el punto de vista del negocio del juego, para satisfacer las necesidades del área usuaria.

El primer sistema en ser construido fue CENSO, que vio la luz en 2014. Su cometido es unificar la información de las distintas cuentas de juego en los diferentes operadores, tanto a nivel de datos personales (Registro de Usuario) como de transacciones económicas (Cuenta de Juego). Esta información procede de los operadores de juego online y llega a la DGOJ a través del sistema NAIPE. Adicionalmente, CENSO se alimenta de otras fuentes externas: el Sistema de Verificación de Jugadores (SVJ) y de los Registros RGIAJ (Interdicción de Acceso al Juego) y Vinculados, sistemas también radicados en la Dirección General. CENSO unifica de forma automática toda esta información en fichas de jugador único, que facilitan una visión 360º de cada uno de los jugadores. La unificación automática se realiza en base a ciertos criterios (similitud de DNI/NIE/documento, nombre y apellidos, fecha de nacimiento), aunque el usuario también puede realizar unificaciones y desagregaciones de forma manual. La operativa básica consiste en cargas de los datos desde el mes señalado hasta el último mes del que se disponen datos, conservando las acciones manualmente realizadas en los procesos de unificación y separación.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Este sistema está programado directamente sobre la base de datos Oracle, mediante lenguaje PL/SQL. Todos los procedimientos automáticos y manuales se encuentran desarrollados en forma de procedimientos y Jobs de base de datos, almacenados en sus correspondientes paquetes e invocables acompañados de los parámetros necesarios, siguiendo la sintaxis definida para ellos.

A continuación, llegó la Plataforma Big Data (basada en el gestor de base de datos columnar Vertica, de HP), para albergar, analizar y explotar la información procedente de NAIPE relativa a las partidas y los jugadores participantes en las mismas, en términos de características de la partida, identificación de los jugadores que juegan, y los movimientos económicos que realizan. Este sistema permite hacer consultas en tiempos del orden de segundos, lo cual es un gran avance teniendo en cuenta la volumetría de la información (1 TB/año).

Esta plataforma de Big Data basada en la base de datos columnar HP Vertica, se encuentran en constante evolución, estando llamada a ser el repositorio principal de la información recibida de los operadores, y para ello ha de soportar y dar cobijo a todos los tipos de registro que establece la normativa, los cuales podrán ser consultados en tiempos del orden de segundos… y todo lo que esto permite (detección de conductas fraudulentas, colusión, irregularidades en la identificación de los jugadores, juego de menores…).

Para terminar, mencionar que se tienen configurados distintos procesos de extracción y carga de información de unas bases de datos a otras, que responden a necesidades específicas de manipulación y cruces de datos por parte del área usuaria. Estos procesos tienen su origen en la etapa anterior a la plataforma mencionada, por lo que se deberían de ir abandonando en favor de la misma.

1.2.- Descripción de los trabajos a realizar en el lote 1 1.2.1.- Aplicación NAIPE

• Mantenimiento evolutivo:

⮚ Nuevos tipos de juego (la introducción de un nuevo tipo de juego tiene impacto en la aplicación, a nivel de presentación gráfica, carpetas a rastrear en los procesos de carga, etc.).

⮚ Nuevas validaciones necesarias en SGI, bien internas (definidas a través de flujos de Axway), bien externas (definidas por jobs de base de datos).

⮚ Cambios en el XSD que dicta el formato de los ficheros a reportar por los operadores. Incorporación de nuevas versiones de XSD a nivel de modelo de datos y de aplicación.

⮚ Modificaciones sobre la aplicación para poder procesar la información que reportan los operadores de juego, ya que a pesar de haber establecido una estructura fija (salvo las mencionadas evoluciones en el anterior apartado) para los ficheros a través de un XSD, sigue habiendo operadores que reportan datos en

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 6 de 75-

formatos incorrectos o longitudes que rebasan lo que se ha reservado en base de datos para los distintos campos. Esto siempre obliga a modificar el modelo de datos y los flujos de procesamiento, con el fin de descargar y almacenar en la base de datos toda esta información, que por parte del área usuaria se considera valiosa, sin perjuicio de que se lleven a cabo paralelamente gestiones encaminadas a la corrección de los ficheros por parte de los operadores en cuestión.

⮚ Mejoras relacionadas con la usabilidad en la capa de interfaz gráfica.

⮚ Optimización del rendimiento y tiempos de carga.

• Mantenimiento correctivo:

⮚ Corrección de todas las incidencias y defectos técnicos que se detecten en la aplicación, así como las pruebas y tareas necesarias para su implantación.

⮚ Resolución de problemas de seguridad detectados en las 2 auditorías de seguridad anuales que la DGOJ realiza, así como aquellos que surjan fuera de ellas (p.ej. detectados directamente por el usuario), con el fin de asegurar la aplicación y cumplir lo dispuesto en el Esquema Nacional de Seguridad.

• Mantenimiento adaptativo:

⮚ Aplicación de Service Packs, parches y nuevas versiones del producto Axway.

⮚ Tareas de integración con otros sistemas de información de la Dirección General (CENSO, Big Data, BI, Sirop). Creación de tablas auxiliares, invocaciones a web services, etc.

• Documentación de las tareas realizadas.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Generación de los ficheros que se han desplegar en cada entrega de versión: WAR del portal web, Jobs y objetos de base de datos, y paquete con la definición de los más de 100 flujos programados. Despliegue desatendido de dichos entregables en los entornos de desarrollo y pre-producción.

• Operativa de producción:

⮚ Monitorización de las cargas:

▪ Estudio del reporte diario periódico de la mañana en busca de incongruencias.

▪ Supervisión de planificaciones establecidas por el usuario, en busca de posibles solapamientos con procesos de compresión, cargas del usuario, backup, etc. Replanificación a otra hora.

▪ Monitorización de las cargas a nivel de componentes de Axway (Gateway, Integrator, Sentinel): comprobación de que todos los ficheros han sido cargados y detección de posibles ficheros perdidos en el proceso de carga. Monitorización de errores de Oracle durante las cargas. Posibles causas:

o Fallos en la aplicación.

o Fallo en el acceso a base de datos.

o Llenado de tablespaces y ASM.

o Llenado de espacio de logs en base de datos.

o Inusabilidad de índices por coincidencia con procesos de compresión.

o Problemas en las comunicaciones y redes, etc.

▪ Monitorización de Jobs de validaciones externas que se prolongan demasiado tiempo.

▪ Monitorización específica de la planificación diferencial nocturna, que varía mucho en función de lo que encuentre en los distintos almacenes.

▪ Monitorización especial en los días de cargas mensuales (1 y 2 de cada mes).

⮚ Acciones y resolución de problemas:

▪ Terminación manual de cargas, si se detecta que se están realizando incorrectamente, y replanificación de las mismas.

▪ Terminación manual de Jobs de base de datos (suele tratarse de validaciones externas).

▪ Recargas manuales de ficheros, acompañadas del borrado de la información corrupta. Planificación de las mismas, buscando las ventanas temporales más adecuadas teniendo en cuenta las planificaciones definidas en cada momento. Casos típicos que necesitan recarga manual posterior:

o Ficheros que no se han cargado correctamente (error en carga).

o Ficheros que han provocado un error de Oracle.

o Ficheros mal asociados a registros.

o Versión no soportada (la aplicación NAIPE aún no está configurada para soportar una determinada versión del XSD).

o Ficheros rechazados por rebasar el tamaño máximo.

▪ Recreación de índices antiguos y creación de nuevos índices.

▪ Modificación del número de hilos dedicado a cada tipo de fichero, para hacer frente a un

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 7 de 75-

aumento/disminución desproporcionado de ficheros de un determinado tipo de registro o relativos a un determinado tipo de juego.

▪ Activación y desactivación del modo acumulado de ejecución de validaciones, según la situación lo requiera (p.ej. cargas mensuales a primeros de mes).

▪ Propuesta de cambios en la configuración de la base de datos (cuya administración realiza la DGOJ), que pueda solucionar problemas detectados.

⮚ Tareas de configuración:

▪ Configuración del tamaño máximo de fichero a descargar y de número máximo de ficheros a descargar en una planificación diferencial, para hacer frente a situaciones anómalas (ficheros demasiado voluminosos, número excesivo de nuevos ficheros en un almacén…).

⮚ Tareas auxiliares a realizar durante las cargas:

▪ Purgado de transferencias en Gateway Navigator.

▪ Borrado del contenido de carpetas temporales.

⮚ Asistencia al usuario de la Subdirección General de Inspección del Juego:

▪ Asistencia en la configuración de nuevos operadores y cambios de certificados o IPs en operadores ya introducidos en el sistema: pruebas de conectividad, certificados, implementaciones del protocolo SFTP, etc.

▪ Asistencia al usuario en la planificación de cargas. Fraccionamiento de las mismas, buscando ventanas de tiempo libres, en caso de que el contenido a cargar se prevea muy voluminoso.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

▪ Creación de vistas sobre tablas y campos que necesite el usuario.

1.2.2.- Sistema CENSO

Siguiendo las directrices del área usuaria, CENSO se planteó desde el primer momento como un sistema flexible a desarrollar bajo una filosofía incremental. El motivo principal era el hecho de que a priori, antes de la construcción del mismo, se desconocía la distribución de jugadores del censo, las características de los registros de usuario de los distintos operadores de juego online, posibles anomalías que se podrían encontrar… Lo cual obligó a definir unas reglas iniciales para la unificación automática de jugadores, sobre las cuales y a medida que se hicieran cargas de Censo y se inspeccionase la calidad de los datos existentes, se harían modificaciones sobre las reglas, se volverían a lanzar cargas y a estudiar el número de jugadores unificados y no unificados… y esto volvería a motivar nuevas propuestas de cambio sobre las reglas. Al final, esto conforma un proceso de desarrollo de tipo incremental sin un término o final establecido, y que obliga a disponer de un recurso que conozca a la perfección los módulos y paquetes de CENSO y sea capaz de programar nuevas reglas o reprogramar reglas ya definidas en el sistema.

Al mismo tiempo, a medida que aumentan las reglas y procesos de unificación, se incrementan los tiempos de procesamiento, con lo cual se hace necesario idear y llevar a cabo formas de optimizar la gestión de los datos dentro de los algoritmos utilizados en el sistema. Esto es especialmente crítico, toda vez que la base de datos donde se encuentra CENSO es la misma que donde está instalado NAIPE y a su vez la misma donde el usuario lanza sus consultas masivas, con lo cual es imprescindible que los procesos de carga de CENSO ocupen el mínimo tiempo posible, para dejar ventanas temporales a los procesos de carga de NAIPE y las consultas del usuario, así como otros procesos periódicos que se llevan a cabo en la base de datos (compresión, estadísticas, etc.).

Como se ha mencionado, CENSO es un eslabón más en el trasiego de información que nace desde los Sistemas de Control Interno de los más de 50 operadores de juego on-line y termina en las Plataformas de BI y Big Data. Como en toda cadena donde un sistema se apoya en otros, cualquier cambio que se produzca en uno repercute en todos los que dependen de él. En el caso de CENSO, éste se ve afectado por cambios en NAIPE (desde alteraciones del XSD que establece la estructura de los ficheros a reportar, hasta nuevos campos en las tablas), y ha de realizarse el correspondiente mantenimiento adaptativo. Por otro lado, cambios de requisitos o de necesidades de usuario en los sistemas finales (en este caso la plataforma Big Data o BI, con mención especial a ésta última, por contener un módulo de interfaz gráfica de CENSO) pueden generar una nueva necesidad de adaptación en CENSO (por ejemplo, incluir nuevos campos de control en una tabla para poder filtrar por ellos desde la plataforma BI).

Adicionalmente, CENSO dispone de unas posibilidades de configuración (p.ej. los campos de los que se quiere hacer seguimiento de cambios a lo largo del tiempo, el diccionario de equivalencias de palabras a la hora de tratar la cadena

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 8 de 75-

de nombre y apellidos, el porcentaje de umbral a partir del cual se consideran similares dos cadenas) que también pueden recaer en el recurso que se encargue de este sistema. Más ampliamente, será necesario asistir al usuario de Inspección a la hora de realizar investigaciones en CENSO y a la hora de lanzar y monitorizar las cargas, ya que en ocasiones duran hasta varias horas. Esto supone un ahorro evidente de tiempo, que el área inspectora puede dedicar a tareas propias de su competencia.

1.2.3.- Plataforma de Big Data

La plataforma de Big Data es un sistema de información final, al que tiene acceso el usuario, y que le permite realizar explotación de los grandes volúmenes de información que se recibe de los operadores. Como todo sistema que hace uso de datos, es preciso definir en él las estructuras que albergarán los datos recibidos mediante procesos de carga periódicos, en los que se transforma la información mediante flujos y mapeos que luego se pretende explotar.

No solo será necesario construir las estructuras de información (tablas o “tablones” construidos a partir de varias tablas) que surjan a partir de nuevas necesidades, sino que habrá que definir procesos almacenados que carguen datos en ellas. Aparte del trabajo de mapeo xx xxxxxx, también será necesario definir la periodicidad de las cargas, el alcance de las mismas (tablas de origen, posibles cruces o filtros predeterminados, intervalos de fechas de los registros), su carácter incremental o no incremental, su colocación en el complejo entramado de procesos que se van definiendo (para conseguir la armonía en el conjunto y evitar solapamientos, que podrían desembocar en resultados no deseados).

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Las cargas, una vez definidas, deberán ser configuradas, programadas y ejecutadas, de forma automática por defecto, pero es muy posible que se plantee la necesidad de realizar cargas manuales. La monitorización de las mismas es otro trabajo que no es sencillo, por el número y la variedad de las mismas. La capacidad de resolver los problemas derivados de fallos en conexión, errores de base de datos, fallos de memoria o cualquier otro tipo de incidencia, es totalmente imprescindible, ya que una primera consecuencia puede ser el almacenamiento de datos corruptos (con el consiguiente trastorno para el usuario). Otra consecuencia es el tener que borrar esos datos inservibles, y tener que volver a repetir la carga de forma separada, para no duplicar información. Esta es una muestra de las tareas que el recurso tendrá que llevar a cabo, y que pueden englobarse en una categoría más amplia de asistencia al usuario en la utilización de la plataforma (consultas, cruces entre tablones, tablas, o ficheros externos de formatos como Excel, CSVs…), y en cómo sacar el máximo provecho de las funcionalidades de la plataforma.

Adicionalmente, debido a que la forma de trabajar en esta plataforma es mediante sentencias SQL, y que el modelo de datos está relativamente normalizado, las consultas del usuario suelen implicar cruces entre varias tablas. Para facilitarle la labor al inspector de juego, el recurso que trabaje en este sistema se encargará de confeccionar consultas predefinidas o “vistas” que respondan a búsquedas típicas que aparezcan en el transcurso de investigaciones en el seno de la Subdirección General de Inspección del Juego.

Una característica especial de la base de datos HP Vertica es que brinda la posibilidad de optimizar los procesos de búsqueda de datos relativos a consultas frecuentes, mediante la ejecución del módulo DB Designer. Sin embargo, esta función es de configuración y activación manual, lo cual supone otra tarea a realizar por el recurso solicitado: vigilancia de consultas y aplicación de los procesos de optimización.

Finalmente comentar que, así como ocurriera en el sistema CENSO, se dará la casuística de tener que adaptar la plataforma a potenciales cambios que se produzcan en los sistemas origen (NAIPE y CENSO, a día xx xxx), ya sean nuevas tablas/campos, modificación de tablas/campos ya existentes, o incorporación de nuevos tipos de juego tienen su impacto en la Plataforma Big Data, y por tanto esas adaptaciones entran también en la lista de tareas que el recurso realizará sobre este sistema de información.

Por consiguiente, este sistema precisará de un recurso que se encargue de la configuración, ejecución y monitorización de las cargas, así como de la asistencia al usuario a la hora de realizar sus consultas basadas en las competencias atribuidas.

1.2.4.- Asistencia en el análisis y tratamiento de información de las bases de datos

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 9 de 75-

Mediante la operación directa sobre las bases de datos y utilización de herramientas nativas (típicamente PL/SQL) se pretende obtener “kits” de trabajo útiles para su día a día (consultas predefinidas, creación de vistas, creación de alarmas disparadas por procesos batch, etc). Se deberán obtener soluciones cerradas de análisis de información (sistemas de Business Inteligente), de forma que el usuario final pueda realizar consultas directas sobre la base de datos sin necesidad de esperar al desarrollo de complejos procesos de transformación, generación xx xxxxxxxxxx de consultas, etc.

1.3.- Estimación de unidades de trabajo asociadas a los trabajos a realizar en el lote 1

En conjunto se estima que los servicios objeto de este lote de contratación van a requerir 1.040 UT (umbral de UT de este lote).

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 10 de 75-

2.- Lote 2: Servicios de desarrollo, mantenimiento y soporte en el ámbito de la tramitación electrónica

2.1.- Entorno funcional existente asociado al lote 2

El lote 2 es el dedicado al soporte, mantenimiento y nuevos desarrollos de aplicaciones que implementan la solución de administración electrónica de la DGOJ para la tramitación y gestión de procedimientos y servicios al ciudadano.

Al objeto de dar cumplimiento a sus competencias, la DGOJ ha venido realizando desde su creación en 2011 una serie de trabajos y adaptaciones tecnológicas con el fin último de proporcionar un servicio electrónico a sus administrados, así como una tramitación electrónica de los procedimientos tendiendo a un uso de papel cero. Es por esto, que de forma periódica deben hacerse adaptaciones y mejoras de los aplicativos existentes al objeto de actualizar las distintas tecnologías, monitorizar la operativa de los componentes, aplicar resultados de auditorías llevadas a cabo, etc.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Sobre estas premisas, la DGOJ ha venido desarrollando, una serie de modificaciones en los sistemas existentes, así como implantando nuevos sistemas y aplicativos al objeto de dar cobertura a las necesidades actuales y futuras derivadas de las competencias atribuidas y el desarrollo de la administración electrónica. Ante esta situación, se considera imperativo continuar con los trabajos iniciados en años anteriores con al menos el mismo nivel de calidad del software puesto a disposición de los administrados y de los usuarios internos de la dirección.

2.1.1.- Aplicaciones JAVA: sede y tramitación electrónica

La disposición transitoria primera de la Ley 13/2011, de 27 xx xxxx, de regulación del Juego, determina que hasta la efectiva constitución de la Comisión Nacional del Juego, las competencias previstas para la misma, serán ejercidas por la Dirección General de Ordenación del Juego creada por Acuerdo del Consejo de Ministros del 11 xx xxxxx de 2011 y contemplada en el Real Decreto 256/2012, de 27 de enero, por el que se desarrolla la estructura orgánica básica del Ministerio de Hacienda y Administraciones Públicas.

Dentro del citado Real Decreto 256/2012, se contempla que la Dirección General de Ordenación del Juego recogerá las funciones de regulación, autorización, supervisión, coordinación, control y, en su caso, sanción, de las actividades de juego de ámbito estatal.

Dicha actividad se traduce en la expedición de licencias de juego (generales y singulares), cobro de tasas, autorizaciones administrativas, gestión de los Registros Generales de Interdicciones de Acceso al Juego (RGIAJ) y de Personas Vinculadas al Juego (RGPVJ), gestión de expedientes de inspección, expedientes sancionadores y diversos requerimientos de información, así como una gran cantidad de procedimientos de comunicación e información periódica con los operadores de juego.

Dentro del 7º Acuerdo Consejo de Ministros por el que se aprueban medidas para la reducción de las cargas administrativas y mejora de la regulación se contempla que antes de diciembre de 2.013 la DGOJ deberá “posibilitar la tramitación telemática de los procedimientos ligados a la concesión de licencias y cumplimiento de las obligaciones de información de los operadores de juego, establecidas en la Ley 13/2011, de 27 xx xxxx, de regulación del juego. (Ref. IP-MHA-02)”.

Con tal fin, durante el año 2014, la DGOJ instaló lo que se vino a denominar “la oficina sin papeles”, conformada por una serie de aplicaciones donde el núcleo central está formado por un tramitador de expedientes del juego plenamente integrado con la sede electrónica (registro, notificaciones, …) y basado en un software desarrollado y cedido en 2011 por el ahora Ministerio de Educación y Formación Profesional. A lo largo del año 2015 y posteriores, se fue consolidando la utilización de esta suite de herramientas, así como incorporándose nuevas funcionalidades demandadas por los gestores de la DGOJ dentro del proceso de mejora continua adoptado por la DGOJ.

Esta solución de “oficina sin papeles” está soportada sobre este conjunto de aplicaciones:

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 11 de 75-

• gestsolg: Tramitador interno para los gestores de la DGOJ empleada para la tramitación administrativa de las solicitudes. Accesible únicamente desde la red interna de la DGOJ.

• tramite: Sede electrónica externa empleada por los ciudadanos para la tramitación de solicitudes que utiliza las definiciones de formularios y de flujos de tramitación creadas en Gestsol.

• AplicacionWebDeRegistro (AWR): Aplicación que gestiona la actividad de la oficina de registro presencial de la DGOJ, empleada para creación de apuntes de salida y de entrada de la documentación presentada físicamente que llega o sale de la DGOJ.

• awgca-web: Aplicación de uso interno utilizada para la generación de copias auténticas de la documentación presentada a la DGOJ.

• sso: Aplicación de uso interno empleada para acceder de forma unificada a las aplicaciones de la red interna de la DGOJ.

• gesclagesex: Aplicación de uso interno que permite la gestión de las claves de acceso para usuarios externos a la DGOJ.

• cid: Aplicación de uso tanto interno como externo que permite la consulta de documentos por su valor de Código Seguro de Verificación CSV.

• consultaregistro: Aplicación de uso tanto interno como externo que permite la consulta de los apuntes realizados dentro del registro electrónico de la DGOJ.

• registroelectronico: Aplicación de uso tanto interno como externo empleada para que los solicitantes puedan registrar y firmar electrónicamente solicitudes realizadas empleando la aplicación tramite.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• enotificaciones: Aplicación de uso tanto interno como externo que permite a un solicitante la visualización de las notificaciones que le han sido enviadas desde la DGOJ de forma electrónica.

• pasp-web: Aplicación que permite realizar pagos de tasas vinculadas a solicitudes en una entidad financiera, está íntimamente relacionada con la aplicación tramite.

• consultaidusuario: Aplicación de uso interno empleada para comprobar la existencia del identificador de usuario contra el Active Directory y el LDAP, y muestra la información personal almacenada en cada una de ellas.

• annservice: Servicio web de uso interno que permite la creación y almacenamiento de anotaciones a otras aplicaciones y servicios web que carecen de acceso a base de datos.

• cidws: Servicio web que permite la consulta de documentos por su CSV.

• envoltorio: Servicio web que unifica toda la funcionalidad para el acceso a @firma con el fin de recuperar datos de certificados electrónicos y hacer validación de firmas.

• gestsolws: Servicio web empleado por aplicaciones que hacen algún tipo de gestión de trámites de forma externa a gestsolg, permite la validación de usuarios, creación y modificación de trámites, cambio de estado de solicitudes y generación de formularios.

• registroparaguas3: Servicio web empleado por tramite y gestosolg para consultar si un usuario tiene apuntes en el registro.

• rtws: Servicio web que permite la creación de apuntes en el registro electrónico.

• selladorcdocu: Servicio web que permite realizar firma de documentos en formato PDF por medio de invocación a servicios de @firma.

• smimews: Servicio web empleado para el envío de correos electrónicos.

• validarfirmas: Servicio web empleado para validar si la firma está bien generada e incluir en ella OSCP-TSA.

• wsnotificaciones: Servicio web empleado para la creación de notificaciones electrónicas.

• wssubir: Servicio web empleado para subir ficheros de gran tamaño.

• notifica-ws: Servicio web empleado para realizar integración con los servicios de Notific@.

• regin: gestión de interesados que se relacionan con la DGOJ por diversos medios.

En el Anexo II se puede ver una descripción más profunda sobre el tramitador y su base funcional.

2.2.- Descripción de los trabajos a realizar en el lote 2

2.2.1.- Trabajos comunes en entornos de aplicaciones JAVA: sede y tramitación electrónica

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 12 de 75-

Durante el periodo objeto de esta contratación corresponde llevar a cabo la gestión integral de los trabajos de diseño, desarrollo, mantenimiento evolutivo y correctivo, soporte técnico, documentación técnica, pruebas e implantación (hasta la aceptación en el entorno de preproducción y la puesta a disposición para la subida al entorno de producción), así como el soporte para la puesta en producción, de las prestaciones y sistemas descritos con anterioridad para cada entorno.

También es necesario tener en cuenta, que la progresiva implantación de las aplicaciones y la extensión de su uso puede hacer necesario cierta reingeniería orientada a la optimización de las aplicaciones, con vistas a mejorar su rendimiento o estabilidad, basándose en:

• Aprovechamiento de la arquitectura hardware (la utilización de balanceadores en momentos de carga o de cabinas de almacenamiento para compartición de datos entre distintas instancias de la misma aplicación, por poner dos ejemplos).

• Detección de “puntos críticos” en cuanto al rendimiento y rediseño (índices, optimización de algoritmos…).

• Utilización de nuevas tecnologías que hagan soslayar problemas de las actualmente utilizadas.

Así mismo, se tendrá que asegurar la producción de los servicios proporcionados a través de otros centros directivos, en especial aquellos proporcionados por la Dirección de Tecnologías de la Información y las Comunicaciones, teniendo que evolucionar o adaptarse a las nuevas versiones de los productos utilizados.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Adicionalmente, se dará soporte especializado a los usuarios finales (gestores de la DGOJ o de las CC.AA.) de las aplicaciones, desarrollando los manuales necesarios para una correcta utilización de las mismas y diseñando y ofertando los cursos formativos necesarios para la correcta implantación de las nuevas funcionalidades.

En lo referente a trámites a implantar en la sede electrónica, se facilitará la incorporación de los trámites de la DGOJ a un entorno electrónico, apoyando y diseñando, si es necesaria, una reingeniería de procesos, aportando nuevas soluciones para el caso de que los productos que tiene implantados la DGOJ no satisfagan las necesidades de los usuarios finales. Así mismo, se pretende poner a disposición de los ciudadanos, a través de dispositivos móviles, aquellos trámites considerados de más impacto y beneficio para ellos, tales como las gestiones asociadas al RGIAJ, presentación de reclamaciones y denuncias, consultas y sugerencias, etc.

2.2.2.- Estimación de unidades de trabajo asociadas a los trabajos a realizar en el lote 2

En conjunto se estima que los servicios objeto de este lote de contratación van a requerir 997 UT (umbral de UT de este lote).

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 13 de 75-

3.- Lote 3: Servicios de desarrollo, mantenimiento y soporte en el ámbito de las aplicaciones corporativas de gestión del juego y servicios horizontales

3.1.- Entorno funcional existente asociado al lote 3

El lote 3 es el dedicado al soporte, mantenimiento y nuevos desarrollos de aplicaciones y sistemas corporativos desarrolladas específicamente para la DGOJ y que incluyen las aplicaciones que dan soporte informático a los Registros de Juego, tanto de Licencias, como de Personas Vinculadas e Interdictos, más otras aplicaciones que facilitan la integración de datos y funcionalidades horizontales al resto de los aplicativos detallados en los otros lotes.

Al objeto de dar cumplimiento a sus competencias, la DGOJ ha venido realizando desde su creación en 2011 una serie de trabajos y adaptaciones tecnológicas con el fin último de soportar los registros de juego, la gestión de operadores habilitados, de las máquinas recreativas embarcadas en buques y la gestión del juego ocasional. Por otro lado, se ha realizado una integración de estas aplicaciones con el tramitador, al objeto de automatizar el traspaso de información desde la solución de administración electrónica a las aplicaciones de gestión específicas de la DGOJ, y facilitar progresivamente la gestión de expedientes por áreas de negocio. Por todo ello, es imperativo continuar con los trabajos iniciados en años anteriores con al menos el mismo nivel de calidad del software puesto a disposición de los gestores del organismo.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

3.1.1.- Aplicaciones JAVA: aplicaciones corporativas del juego

El Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 xx xxxx, de regulación del juego, en lo relativo a los requisitos técnicos de las actividades de juego, establece en su artículo 27.2 que la Comisión Nacional del Juego dispondrá los medios necesarios y establecerá los procedimientos adecuados para permitir a los operadores el acceso telemático al Registro General de Interdicciones de Acceso al Juego (en adelante RGIAJ).

Por otro lado, y también en base a la disposición transitoria primera de la Ley 13/2011, la DGOJ ha asumido la gestión del Registro de Prohibidos que era competencia del Ministerio del Interior.

El RGIAJ, junto con el Registro de Personas Vinculadas a Operadores de Juego (RPVOJ) y el Registro General de Licencias de Juego, constituyen los tres registros del sector del juego que establece el artículo 46.1 del Real Decreto 1614/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 xx xxxx, de regulación del juego, en lo relativo a licencias, autorizaciones y registros del juego.

En relación con el Registro General de Licencias de Juego, se gestionan las cuatro secciones del mismo definidas en el artículo 49 del Real Decreto 1614/2011 (concurrentes, generales, singulares, especial de autorizaciones de juegos de loterías).

El artículo 46.4 del Real Decreto 1614/2011 establece que los Registros del sector del juego estarán soportados por un sistema informático, en las condiciones que establezca la Comisión Nacional del Juego, que deberá garantizar el cumplimiento de las funciones para las que han sido creados.

La información mínima a mantener en dichos registros viene definida por el artículo 51 del Real Decreto 1614/2011 y por la convocatoria de licencias vigente en cada momento. Actualmente es aplicable a efectos de terminar la información a contener en dicho registro la Orden HAP/1995/2014, de 29 de octubre, por la que se aprueba el pliego de bases que regirán la convocatoria de licencias generales para el desarrollo y explotación de actividades de juego de la Ley 13/2011, de 27 xx xxxx, de regulación del juego. La Ley 13/2011, de 27 xx xxxx, de regulación del juego, y complementariamente la Resolución de 10 de octubre de 2014, de la Dirección General de Ordenación del Juego, por la que, de conformidad con el artículo 17 del Real Decreto 1614/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 xx xxxx, de regulación del juego, en lo relativo a licencias, autorizaciones y registros del juego, se establece el procedimiento de solicitud y otorgamiento de las Licencias Singulares para el desarrollo y explotación de los distintos tipos de actividades de juego.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 14 de 75-

Adicionalmente, la gestión del RGIAJ se realiza de forma conjunta con las CC.AA., permitiendo a las CC.AA. la gestión de forma autónoma de los permisos de acceso en consulta al RGIAJ, estar al tanto de las modificaciones del mismo y comunicar a la DGOJ las actualizaciones que en el ámbito del registro de prohibidos de su competencia tengan que tener ámbito nacional, dentro del marco de los acuerdos que alcanzados en esta materia en el Consejo de Políticas de Juego según lo establecido en el artículo 62 del Real Decreto 1614/2011 en lo relativo a cooperación interadministrativa.

Para todo ello, la DGOJ ha desarrollado un conjunto de sistemas o aplicaciones entre las que destacan:

• SIROP: Sistema de Información de Registro de Operadores de Juego

Sistema de información que, además de soportar los registros anteriormente citados a excepción del RGIAJ, incorpora y consolida datos de distinta naturaleza relativos a los operadores de juego online, permitiendo establecer cuadros de mandos y compartir información entre las distintas subdirecciones al objeto de facilitar el conocimiento y la toma de decisiones en la gestión diaria de la DGOJ.

Las características más destacadas son las siguientes:

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

- Integración con la sede electrónica para la carga de datos directamente en el RGPVJ o cualquiera de las secciones de los registros de licencias.

- Integración con la sede electrónica, cargando cualquiera de los datos definidos en cualquiera de los trámites habilitados en la misma y utilizando el mecanismo de exportación de información de la sede electrónica.

- Integración con los servicios de gestión documental de la DGOJ (CDOCU).

- Integración con los servicios web publicados para la integración con los registros de prohibidos autonómicos.

- Gestión de avales asociados con las licencias generales y singulares.

- Gestión de tasas asociadas con las licencias generales y singulares.

- Expedientes de homologación de operaciones

- Información agregada de expedientes sancionadores.

- Soporte de las funciones del convenio de autocontrol de los operadores de juego online.

- Información sobre operadores ilegales.

- Gestión del juego ocasional.

- Gestión de las máquinas recreativas embarcadas en buques autorizados de línea regular.

- Integración con los servicios de seguridad corporativos de acceso a aplicaciones de la DGOJ.

- Tratamiento histórico de cualquier información cargada en el sistema.

- Auditoría de acciones haciendo uso de las funcionalidades de auditoría corporativas de la DGOJ.

• RGIAJ: Registro de Interdicciones de Acceso al Juego

Aplicación que permite la gestión del Registro de Interdicciones de Acceso al Juego a través de web services que son invocados desde el trámite correspondiente de la sede electrónica para facilitar la inscripción, cancelación, modificación y certificación de la situación en el RGIAJ de forma on line y también mediante tramitación en papel.

• CAEAT: Convenio de intercambio de datos con la Agencia Estatal de Administración Tributaria

Aplicación Web interna que permite solicitar la descarga de los justificantes de los modelos 763 presentados por los Operadores de Juego en la Agencia Tributaria. La comunicación con la AEAT se realiza a través de un Servicio Web, actuando la DGOJ como cliente y la AEAT como servidor de dicho servicio. Dicha aplicación permite a su vez una consulta de las peticiones realizadas, así como un resumen de los modelos presentados por el operador y que han podido ser descargados correctamente.

• SIGMA: Servicio de Investigación Global xxx Xxxxxxx de Apuestas

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 15 de 75-

Aplicación para la gestión de alertas sobre fraude en las apuestas deportivas utilizada por los miembros de la Comisión Nacional para combatir la manipulación de las competiciones deportivas y el fraude en las apuestas (CONFAD).

3.1.2.- Aplicaciones JAVA: consolidación de información y gestión de expedientes por áreas de negocio

Todo este conjunto de aplicaciones, crean la base para la gestión electrónica de expedientes que se realiza mediante la aplicación EXPEL que integra la información tratada por cada una de ellas:

• EXPEL: Visor y Gestor de EXPedientes Electrónicos

Es un contenedor de trámites, que permite incorporar a cada tipología de expedientes unos tipos de trámites concretos, permitiendo incorporar los trámites desde el propio Expel o desde el tramitador, enlazando directamente las solicitudes contenidas con la aplicación de tramitación.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Facilita al usuario la gestión y visualización de los documentos asociados al expediente mediante una serie de vistas por trámites, actos administrativos, documental o de evaluación, adaptadas a cada perfil de usuario. Facilita además la puesta a disposición de los expedientes a los interesados mediante un visor stand alone y su envío a otras Administraciones Publicas en formato ENI compatibles a través de INSIDE, así como el archivado de los mismos a través de ARCHIVE.

Adicionalmente, permite una gestión avanzada de los permisos de acceso a los documentos en función del perfil del usuario.

3.1.3.- Aplicaciones JAVA: aplicaciones uso horizontal

El marco de desarrollo de la DGOJ cuenta con un conjunto de soluciones que dotan al resto de aplicaciones del órgano de servicios de seguridad y monitorización centralizados donde se estandarizan ciertas necesidades de las aplicaciones desarrolladas.

• APSEC: Aplicación para la Gestión de Permisos.

Aplicación web cuyo objeto es ofrecer una interfaz de administración para la gestión de los permisos de los usuarios sobre las aplicaciones. Entre sus funcionalidades se recogen:

- Administración del modelo de autorización de las aplicaciones (basado en perfiles, módulos, acciones).

- Administración de los perfiles que podrán tener los usuarios en cada una de las aplicaciones de la DGOJ.

- Administración de las direcciones de los servicios web consumidos por las aplicaciones de la DGOJ.

- Administración de grupos de datos y su asignación a usuarios (ej. CC.AA.).

- Consultar el listado de permisos asignados a un usuario respecto a una aplicación.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 16 de 75-

- Realizar apuntes de auditoría (asociadas a acceso y/o tratamiento de datos).

- Validación del login del usuario y el código de aplicación.

- Consultar el listado completo de los grupos de acceso a datos.

- Consultar el listado completo de los posibles valores que puede tener cada grupo de acceso a datos.

- Consultar el listado de grupos de acceso a datos y sus respectivos valores que tiene disponible cada usuario.

• WSSEC: Servicios de Seguridad

Servicio web cuyo objeto es ofrecer a las aplicaciones un conjunto de servicios/funcionalidades reutilizables entre ellas y relacionadas con la seguridad de la información.

Este componente está preparado para que pueda ser invocado tanto por aplicaciones basadas en el framework, como por cualquier otra que pueda realizar peticiones mediante webservice. Por otro lado, es importante anotar que este componente interactúa con la BBDD de seguridad, así como con los siguientes componentes para temas de validación: LDAP corporativo y la BBDD de la sede.

• FWORK: FrameWork corporativo

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Establece un marco tecnológico común a las aplicaciones del órgano, así como funcionalidades ya integradas:

- Autenticación de los usuarios a través del sistema de Single Sign-On implantado en la DGOJ.

- Autorización de los usuarios a las aplicaciones, basado en listado de permisos asignados (módulos y acciones).

- Auditoría de acceso de los usuarios a las aplicaciones y auditoría de la lógica de negocio de las aplicaciones.

- Sistema de monitorización de los componentes de arquitectura que utiliza la aplicación, permitiendo verificar de forma on-line si dichos elementos están operativos (ej: LDAP, Servidor de Correo, Servicios Web, Base de datos, etc.).

- Integración con los principales sistemas de la DGOJ (LDAP, Servidor de Correo, etc.).

- Módulo xx Xxxxx Site Scripting para garantizar la seguridad de las mismas y evitar este tipo de ataques.

- Generación de informes en forma PDF, Word y Excel utilizando la herramienta Xxxxxx Reports.

Adicionalmente, existe un “Piloto” a modo de aplicación ejemplo que contiene toda la funcionalidad facilitada por el framework a modo de ejemplo para los desarrolladores

• Otras Aplicaciones de uso horizontal:

• WSLDAP: Servicio de acceso al LDAP

Servicio web que centraliza la ejecución de acciones contra el LDAP de la DGOJ.

• wsFiltro: Servicio de comprobación de login

Servicio web para validar si el usuario se ha validado en el SSO y permitir que las aplicaciones recuperen información de dicho usuario.

• cdocu-ws: servicio de catálogo documental

Servicio web que permite catalogar y firmar documentos, así como subir de forma transparente y asíncrona los documentos al gestor documental.

• alfresco-ws: servicio web de Alfresco

Servicio que implementa con protocolo cmis las operaciones de acceso a Alfresco

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 17 de 75-

• WSMOC: Servicios de monitorización

El objetivo del servicio web WSMOC consiste en realizar la monitorización de los siguientes recursos de la DGOJ:

⮚ Servicios web internos y externos.

⮚ Aplicaciones internas de la DGOJ.

⮚ Esquemas de base de datos.

⮚ LDAP.

⮚ Ficheros y carpetas.

El servicio web consulta los recursos que se encuentren catalogados en la DGOJ y devuelve datos de rutas, máquinas, ubicaciones y estado de cada uno. De esta forma se facilita al proveedor externo de hosting la monitorización para localizar posibles caídas de servicio y su causa.

Este servicio está apoyado por una aplicación web que permite la visualización de los resultados de las consultas de monitorización por personal de la DGOJ, además de por las herramientas de monitorización.

• DdgojFirmaUpgradeWsSecure: Servidor de firma

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Servicio basado en las librerías de @Firma que permite realizar el sellado, sellado de tiempo, y upgrade para firmas longevas en distintos formatos

• GesApliSSO Single Sign On y Gestión de aplicaciones integradas en el SSO

Aplicación que permite la identificación en un único punto para todas las aplicaciones de la DGOJ, basada en el uso de cookies y en perfiles/grupos de LDAP y que se ve apoyada por el uso de la aplicación GesApliSSO que permite definir aplicaciones integradas con el SSO, usuarios y grupos que pueden acceder y distinto nivel de visibilidad de las aplicaciones según el entorno (internet, extranet-acceso CCAA).

Así mismo, se cuenta con una serie de servicios web que aíslan a las aplicaciones de la problemática del acceso al

LDAP, permitiendo a través de ellos conocer los principales atributos de un usuario en cuestión o de un grupo o de las relaciones de usuarios con grupos o grupos entre sí, como por ejemplo:

- Cambio de contraseña.

- Autenticación en aplicaciones con sesiones comunes a todas las aplicaciones.

- Apertura y cierre de sesiones del SSOWeb, de forma que el acceso a las aplicaciones se realice de forma segura.

- Operaciones relacionadas con usuarios, atributos y grupos: búsqueda, creación, borrado, modificación, …

En cuanto a la aplicación GesApliSSO, las principales características son:

o Un módulo que facilita a perfiles determinados la gestión de usuarios y los grupos que representarán las aplicaciones accesibles desde el SSO.

o Un componente reutilizable que facilita a cada aplicación acceder a las credenciales almacenadas en el LDAP en lugar de guardar la información de credenciales en su base de datos. Se proporciona por tanto una forma para que cada aplicación no tenga que crear su propia pantalla de gestión de usuarios y pueda reutilizar este módulo que ofrece el servicio centralizado.

o Un módulo para visualizar la información personal de un usuario tanto en AD como en LDAP.

o Un módulo de gestión que permite:

▪ Mostrar el listado de las aplicaciones a las que un usuario tiene acceso.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 18 de 75-

▪ Mostrar un listado de las aplicaciones a las que un usuario no tiene acceso pero puede solicitarlo.

▪ Listar las aplicaciones integradas y sin integrar dadas de alta en el sistema.

▪ Permitir el alta, baja y modificación de aplicaciones y agrupación de las aplicaciones por área.

▪ Mostrar un formulario para localizar aplicaciones de manera específica.

▪ Listar las membresías de usuarios y grupos correspondiente a una aplicación.

▪ Gestionar los grupos hijos del grupo de la aplicación.

o Funcionalidades de suplantación, restringidas para tareas de soporte. La funcionalidad de suplantación debe ofrecerse de forma controlada y con la adecuada auditoría y siempre que el usuario conozca la contraseña del usuario a suplantar.

o El portal web debe permitir a través del mismo el cambio de contraseñas de usuarios externos- CC.AA.

3.1.4.- Aplicaciones JAVA: web services

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

El Real Decreto 1613/2011, de 14 de noviembre, por el que se desarrolla la Ley 13/2011, de 27 xx xxxx, de regulación del juego, en lo relativo a los requisitos técnicos de las actividades de juego, establece en su artículo 26.3, en relación a la identificación de los participantes en las actividades de juego, que La Comisión Nacional del Juego establecerá los procedimientos necesarios para facilitar la autenticación y comprobación de los datos de identidad de los residentes en España en tiempo real.

En el artículo 27.2 dicho Real Decreto establece que la Comisión Nacional del Juego dispondrá los medios necesarios y establecerá los procedimientos adecuados para permitir a los operadores el acceso telemático al Registro General de Interdicciones de Acceso al Juego.

Por otro lado, y también en base a la disposición transitoria primera de la Ley 13/2011, la DGOJ ha asumido la gestión del Registro de Prohibidos que era competencia del Ministerio del Interior.

Al objeto de cumplir con estos requisitos legales y funcionales, la DGOJ incorporó en su momento a su arquitectura tecnológica una serie de servicios web publicados para los operadores de juego, para facilitar a estos la verificación del cumplimiento de las prohibiciones subjetivas recogidas en el artículo 6.2 de la Ley 13/2011.

La descripción funcional de dicho servicio web e información relacionada se puede encontrar en xxxx://xxx.xxxxxxxxxxxxxxx.xx/xx/xxxxxxxx-xxx-xxxxxxxxxxxx-xxxxxxxxx

Adicionalmente se han desarrollado una serie de alarmas y estadísticas para dotar a la DGOJ del conocimiento necesario sobre la utilización de dichos servicios web por parte de los operadores. Dichos procesos se realizan mediante procesos PL/SQL directamente sobre los datos de las peticiones de los servicios web.

Así mismo, con el objeto de ofrecer a los operadores de juego online el servicio de verificación de datos de identidad, la DGOJ hace uso del Sistema de Verificación de Datos de Identidad proporcionado por la Dirección General de la Policía a través de los servicios de la Dirección de Tecnologías de la Información y las Comunicaciones. Dada la criticidad de este servicio, recogida en la normativa reguladora del juego, se ha de prestar en régimen de 24x7, en un entorno de alta disponibilidad, con soporte para la gestión de incidencias a los operadores que incluye la posibilidad de que coexistan en producción varias versiones del software y activación de un plan de contingencia en el caso de caída del servicio principal.

Las aplicaciones asociadas a esta funcionalidad son:

• XXXXX: Servicio Web de Verificación de jugadores

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 19 de 75-

Este servicio web permite a los operadores de juego verificar la identidad de sus usuarios y su situación en el registro de interdicción de acceso al juego (RGIAJ). Durante el 2015 se realizaron las siguientes nuevas funcionalidades:

⮚ XXXXXXX: Consulta alternativa de interdictos

Sistema utilizado durante la activación del Plan de Contingencia para poder seguir dando servicios de consulta de situación en el Registro de Interdicciones de Acceso al Juego a los operadores con licencia mientras esté caído el servicio principal XXXXX.

⮚ GOPER: Gestión de operadores

Aplicación web que permite la configuración del servicio de verificación de jugadores (XXXXX), gestión de los operadores y consulta sobre los datos gestionados a través del servicio para la resolución de incidencias.

3.2.- Descripción de los trabajos a realizar en el lote 3

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

3.2.1.- Trabajos comunes en entornos de aplicaciones JAVA: aplicaciones corporativas del juego, tramitador de expedientes, framework y aplicaciones uso horizontal y web services

Durante el periodo objeto de esta contratación corresponde llevar a cabo la gestión integral de los trabajos de diseño, desarrollo, mantenimiento evolutivo y correctivo, soporte técnico, documentación técnica, pruebas e implantación (hasta la aceptación en el entorno de preproducción y la puesta a disposición para la subida al entorno de producción), así como el soporte para la puesta en producción, de las prestaciones y sistemas descritos con anterioridad para cada entorno.

También es necesario tener en cuenta, que la progresiva implantación de las aplicaciones y la extensión de su uso puede hacer necesario cierta reingeniería orientada a la optimización de las aplicaciones, con vistas a mejorar su rendimiento o estabilidad, basándose en:

• Aprovechamiento de la arquitectura hardware (la utilización de balanceadores en momentos de carga o de cabinas de almacenamiento para compartición de datos entre distintas instancias de la misma aplicación, por poner dos ejemplos).

• Detección de “puntos críticos” en cuanto al rendimiento y rediseño (índices, optimización de algoritmos…).

• Utilización de nuevas tecnologías que hagan soslayar problemas de las actualmente utilizadas.

Así mismo, se tendrá que asegurar la producción de los servicios proporcionados a través de otros centros directivos, en especial aquellos proporcionados por la Dirección de Tecnologías de la Información y las Comunicaciones, teniendo que evolucionar o adaptarse a las nuevas versiones de los productos utilizados.

Adicionalmente, se dará soporte especializado a los usuarios finales (gestores de la DGOJ o de las CC.AA.) de las aplicaciones, desarrollando los manuales necesarios para una correcta utilización de las mismas y diseñando y ofertando los cursos formativos necesarios para la correcta implantación de las nuevas funcionalidades.

Deberán realizase adicionalmente las operaciones de mantenimiento y subida de versión de los componentes del framework de carácter crítico para solventar vulnerabilidades graves de seguridad o funcionalidades imprescindibles en el ciclo de desarrollo, con su correspondiente aplicación al piloto.

3.2.2.- Estimación de unidades de trabajo asociadas a los trabajos a realizar en el lote 3

En conjunto se estima que los servicios objeto de este lote de contratación van a requerir 1044 UT (umbral de UT de este lote).

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 20 de 75-

4.- Lote 4: Servicios de Calidad, Gestión de Proyectos y Seguridad

El lote 4 es el dedicado a las distintas actuaciones transversales que dan soporte al resto de áreas de desarrollo de la DGOJ. Entre estas, se encuentran las distintas líneas de actuación relacionadas con la seguridad y el cumplimiento de la normativa y políticas vigentes, así como el aseguramiento de la calidad de los entregables generados por los distintos proyectos de desarrollo, y la gestión y seguimiento de los mismos mediante la Oficina Técnica de Proyectos.

4.1.- Entorno funcional existente asociado al lote 4 4.1.1.- Auditorías de seguridad

La DGOJ dispone en su infraestructura tecnológica de los elementos de seguridad necesarios para asegurar que la información albergada en sus servidores es tratada de la forma correcta. Se dispone de sistema xx xxxxx firewall, firewall de aplicaciones basado en Imperva, sondas OSSIM y servidor de alerta temprana del CCN.

Todos ellos administrados por el proveedor de infraestructura que los monitoriza, opera y mantiene y que eleva a la DGOJ los correspondientes informes y alertas.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

4.1.2.- ENS/LOPD

Utilización de las herramientas estándar para seguimiento de la implantación del Esquema Nacional de Seguridad, entre las cuales destacan:

• XXXXX, para el análisis y gestión de riesgos.

• CLARA, para la auditoría de cumplimiento ENS/STIC de Sistemas Windows.

• INES para el reporte al CCN del estado de implantación del ENS en la DGOJ.

Así como utilización de paquetes ofimáticos para la generación xx xxxxxxx de mandos asociados a dichas tareas.

4.1.3.- Oficina Técnica de Proyectos

Desde su creación, la oficina técnica de proyectos realizará el seguimiento de todo el ciclo de vida de los proyectos siguiendo la metodología implantada en la DGOJ y utilizando las herramientas corporativas. Como mínimo la oficina de proyectos realiza las siguientes actividades:

• Creación y seguimiento del Plan de Proyectos anual.

• Seguimiento de los proyectos en cada una de sus fases.

• Generación de informes para los distintos responsables de la DGOJ.

Se encarga de la parametrización, soporte (incluyendo la generación de material, sesiones formativas, etc) y mantenimiento de las herramientas de seguimiento de proyectos corporativos.

La oficina de proyectos realiza labores de asesoría a los equipos de trabajo en temas referentes a la gestión de proyectos, y en este ámbito de actuación como mínimo realiza las siguientes actividades:

• Realización de sesiones de presentación y formación de la gestión de proyectos.

• Generación de material de soporte y difusión del mismo.

• Soporte multicanal (teléfono, e-mail, etc…).

4.1.4.- Oficina de Calidad

Desde su creación en 2011, la DGOJ viene incrementando la informatización de sus procesos mediante el incremento

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 21 de 75-

de nuevas aplicaciones y nuevas funcionalidades al objeto de dar cumplimiento de la forma más eficiente posible a las competencias atribuidas, así como dar cumplimiento a la normativa vigente y los proyectos reformistas que vienen abordándose por parte de la Administración General del Estado.

Ante el crecimiento del ecosistema de aplicaciones de la DGOJ, y habiéndose consolidado la actividad de la dirección desde su creación, en los últimos ejercicios se ha pretendido mejorar e incrementar la gestión de las pruebas sobre las aplicaciones existentes, y por ende mejorar la calidad de los sistemas puestos a disposición de los distintos usuarios, ya sean internos o externos a la dirección.

El alcance de las pruebas se ha circunscrito a las aplicaciones y sistemas propiedad de la DGOJ anteriormente citadas en los lotes 1 y 2, habiéndose establecido diferente nivel de profundización y prioridad de las mismas en función de las necesidades del servicio. El desarrollo de estas actividades se ha venido realizando de acuerdo a la planificación que acordada entre el equipo de Testing y el responsable de la Dirección General de Ordenación del Juego en base a las necesidades y prioridades identificadas tanto por el equipo de desarrollo de cada proyecto como por la Dirección General.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Como resultado de las pruebas anteriormente definidas el equipo de Testing genera los informes necesarios para la comunicación de los resultados a los responsables de la Dirección General de Ordenación del Juego, así como documentar su actividad y procesos acorde con las especificaciones y requerimientos definidos por la metodología actual utilizada por la Dirección General.

De manera complementaria se reportan los hallazgos encontrados, independientemente de su tipología o criticidad, a los equipos de desarrollo por medio de las herramientas de ticketing utilizadas por la DGOJ tales como RedMine y GLPI. Permitiendo la trazabilidad y gestión de dichas incidencias por parte de los responsables de desarrollo de la DGOJ así como por los equipos de desarrollo involucrados. Siendo responsabilidad del equipo de Testing la gestión de las solicitudes y correctivos generados para la comunicación de los hallazgos, siendo este el instrumento de comunicación con los equipos de desarrollo y responsables de la DGOJ.

Todo ello, al amparo de la metodología definida por parte de la DGOJ para el desarrollo de estas actividades, y siguiendo los modelos documentales y de comunicaciones existentes.

4.1.5.- Centro de soporte a usuarios

A lo largo del ejercicio 2015, la DGOJ consideró necesario establecer un centro de Atención, o soporte, al Usuario (CAU) al ver como se producía en los últimos años un exponencial incremento del número dudas y solicitudes realizadas por parte de los ciudadanos, operadores y empleados internos sobre el juego online, la sede electrónica y las aplicaciones corporativas. Este incremento de consultas de soporte vino derivado del incremento del número xx xxxxx de juego online fruto del segundo proceso de apertura xxx xxxxxxx, así como de los jugadores, y el número de aplicaciones internas, así como la generalización del uso de medios electrónicos de tramitación.

El objetivo actual del CAU es el desarrollo de tareas con los operadores de juego y los ciudadanos. Tareas tales como:

• Respuesta, en castellano o inglés, de las consultas recibidas en los diferentes buzones de atención al usuario, siendo estos:

⮚ Buzón de soporte a operadores para resolución de asuntos relacionados con el Servicio de Verificación de Jugadores.

⮚ Buzón de dudas en cuanto al uso de la sede electrónica (eadministracion).

⮚ Buzón de incidencias informáticas.

⮚ Buzón de dudas elevadas al portal específico de juego responsable de xxxxxXXXX.xx.

• Respuesta, en castellano o Inglés, a las consultas telefónicas realizadas por los operadores y ciudadanos asociadas al Servicio de Verificación de Jugadores, la sede electrónicas y a los procedimientos electrónicos accesibles en la misma, así como de los usuarios internos asociadas al uso de las herramientas informáticas de la DGOJ.

• Gestión de las incidencias abiertas en la herramienta de ticketing GLPI por parte de los usuarios internos de la

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 22 de 75-

DGOJ, y su correlación, en su caso, con peticiones en la herramienta Redmine que emplean los distintos equipos de desarrollo de la DGOJ, de forma que se asegure la trazabilidad de las mismas.

• Reportes semanales de uso del servicio en cuanto al número de consultas realizadas, tipología, tiempos de respuesta, etc., que den respuesta a los distintos informes, tanto de la propia Dirección General, como del departamento, que son solicitados en este sentido.

• Creación de una base de datos de conocimiento de preguntas y respuestas más frecuentes, así como los procedimientos definidos para la resolución de la operativa diaria mediante una WIKI.

• Gestión de las solicitudes que los equipos de desarrollo hacen para la promoción de entornos.

• Evaluar y establecer prioridades para la resolución de las incidencias y problemas encontrados en los desarrollos.

4.2.- Trabajos a realizar en el lote 4 4.2.1.- ENS/LOPD

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

En este aspecto el objetivo principal de la DGOJ es el alineamiento de la seguridad de la Dirección General a la normativa de seguridad definida por el ENS y la normativa vigente en materia de Protección de Datos Personales, así como a lo definido por la Política de Seguridad del departamento. Por ello será necesario el desarrollo de todos los trabajos necesarios que permitan alcanzar y asegurar los niveles de adecuación.

Dentro de este marco de trabajo se enmarcan numerosas actividades, entre las cuales es posible destacar las siguientes, en base a su importancia para la consecución del objetivo:

• Revisión y definición en el caso de que sea necesario confeccionar normas de seguridad hasta ahora no contempladas en la política de seguridad de la DGOJ:

⮚ Elaboración de la documentación organizativa asociada (procedimientos, registros, manuales, guías, etc.).

▪ Política de seguridad.

▪ Normas y estándares de seguridad.

▪ Procedimientos de seguridad.

▪ Guías para el uso de las herramientas de seguridad.

⮚ Soporte al arranque de los procedimientos de acuerdo a las buenas prácticas definidas para tal efecto.

⮚ Soporte en la implantación de las medidas técnicas.

• Seguimiento del progreso en la adecuación al Esquema Nacional de Seguridad.

⮚ Soporte para la definición del plan de implantación del ENS en la DGOJ.

⮚ Ejecución de los acciones de adecuación al ENS.

⮚ Monitorización y seguimiento del avance de las actividades.

• Estudio de seguridad según artículo 35 del Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica (informe a CCN).

• Realización de actividades de monitorización y seguimiento preventivo.

• Elaboración de Informes y auditorías:

⮚ Revisión de auditorías de seguridad y de hacking ético realizadas por el proveedor de infraestructuras sobre los recursos y sistemas de la DGOJ

⮚ Auditorías de cumplimiento de estándares: ISO27001 y ENS.

⮚ Creación del Programa de Auditoría y seguimiento de controles.

⮚ Análisis & Gestión de Riesgos Trimestrales (trimestral).

⮚ Vulnerabilidades y Parches Publicados, e impacto en la Infraestructura (mensual).

⮚ Incidentes Control Acceso (trimestral).

⮚ Auditoría – Estado de Cuentas de Acceso (trimestral).

⮚ Creación de una metodología asociada a las auditorías.

⮚ Seguimiento y soporte de las acciones correctivas.

• Análisis de las vulnerabilidades detectadas.

o Análisis de los resultados de la ejecución de distintas auditorías de hacking ético, vulnerabilidades y pruebas de penetración sobre las aplicaciones, portales web, infraestructuras y sistemas de la DGOJ.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 23 de 75-

o Apoyo al equipo de Testing en la posible realización de auditorías técnicas de seguridad de las aplicaciones, portales web y sistemas a petición de la DGOJ, así como paso previo a su pase producción cuando se tratan de aplicaciones de nueva construcción o con cambios sustanciales ante una nueva release.

• Adecuación de la DGOJ a la normativa vigente en materia de Protección de Datos.

⮚ Análisis anual del estado y nivel de cumplimiento.

⮚ Mantenimiento de los documentos de seguridad mediante la revisión y actualización.

⮚ Revisión y actualización de procedimientos técnicos, legales y organizativos de cumplimiento.

⮚ Identificación de aspectos técnicos requeridos, así como la situación actual de la DGOJ al respecto.

⮚ Soporte a la implantación de medidas técnicas a aplicar en los distintos sistemas y aplicativos de la DGOJ.

⮚ Elaboración de cuantos informes y respuesta a consultas sean requeridos por el Responsable de Seguridad de la DGOJ.

⮚ Actualización del Registro de actividad de la DGOJ.

• La oficina de seguridad realizará como mínimo las siguientes actividades de Análisis de Riesgos siguiendo la metodología de MAGERIT:

⮚ Revisión periódica del inventario y clasificación de activos.

⮚ Revisión de amenazas.

⮚ Revisión y selección de Xxxxxxxxxxxx.

⮚ Re-evaluaciones periódicas del riesgo.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

⮚ Gestión del riesgo.

• La oficina de seguridad realizará como mínimo las siguientes actividades de soporte técnico y a proyectos:

⮚ Gestión y soporte durante la adquisición, desarrollo y operación de soluciones tecnológicas de seguridad.

⮚ Aseguramiento de la seguridad en la adquisición y/o desarrollo de Sistemas de Información.

• La oficina de seguridad realizará como mínimo las siguientes actividades de Formación:

⮚ Presentaciones del estado de la gestión de la seguridad en la DGOJ al responsable de seguridad de la DGOJ y a quien este considere.

4.2.2.- Plan de continuidad del negocio (PCN)

Las tareas que se espera que se realicen dentro de este ámbito son las siguientes:

• Estudio de la situación actual de los sistemas y de la documentación disponible relacionada con el PCN.

• Identificar y analizar la información reutilizable desarrollada para el cumplimiento del ENS para el desarrollo del PCN (por ejemplo los análisis de riesgos).

• Definir e identificar y analizar los requerimientos específicos de la DGOJ con respecto a la continuidad del negocio incluyendo aspectos regulatorios, así como la estrategia de recuperación de los sistemas.

• Identificar y definir roles y responsabilidades para el desarrollo y ejecución del PCN.

• Establecer y definir los procedimientos que permitan garantizar la continuidad de los servicios.

Colaborar y dar suporte en el desarrollo de las pruebas y ejercicios desarrollados para realizar la comprobación del plan.

4.2.3.- Oficina Técnica de Proyectos

Sin menoscabo de seguir dando el servicio a la DGOJ en cuanto al seguimiento de los proyectos, la obtención de estudios e informes asociados a cada proyecto que se les pueda solicitar, las principales tareas demandadas serán:

• Monitorización del grado de avance del proyecto y gestión de riesgos.

⮚ Preparación de la reunión de seguimiento con el contratista para conocer las tareas realizadas, el grado de avance, los riesgos detectados y las dependencias existentes.

⮚ Obtención y cruce del grado de avance con Project y Redmine y actualización de la información.

⮚ Realización de la reunión de seguimiento.

⮚ Revisión y cierre del informe de seguimiento.

⮚ Valoración de los indicadores de nivel de servicio acordados para cada contratista en los periodos establecidos.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 24 de 75-

⮚ Alimentar el cuadro de mando global de seguimiento (% avance, entregables, incidencias pruebas, incidencias producción, calidad de SW, seguridad).

⮚ Seguimiento de los contratistas asociados a los distintos lotes en cuanto al número de UT realizadas mensuales por proyecto, desviación con respecto al presupuesto, elaboración de estadísticas, desviación de ET respecto a planificaciones y UT estimadas, etc.

• Mantenimiento del entorno colaborativo para la gestión y desarrollo de las aplicaciones de administración electrónica:

En la DGOJ el ciclo de vida del desarrollo de las aplicaciones se apoya en un conjunto de herramientas de trabajo colaborativo, desde la planificación y seguimiento del proyecto, el almacenamiento del código fuente y artefactos, la gestión de peticiones de servicio, hasta la documentación de los propios proyectos.

Se realizarán las operaciones de mantenimiento y subida de versión que aseguren el funcionamiento del conjunto de herramientas y la resolución de vulnerabilidades. Así mismo, se realizarán los cambios de parametrización en las herramientas personalizables que sean precisas para cumplir con los cambios sugeridos por la PMO en la gestión de proyectos o en la metodología de desarrollo. Más concretamente, las tareas a realizar para el mantenimiento del entorno colaborativo podrían considerarse, entre otras:

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

⮚ Mantenimiento correctivo y resolución de incidencias de la herramienta de gestión del servicio.

⮚ Mantenimiento correctivo y resolución de incidencias de la herramienta de planificación, seguimiento y documentación de proyectos.

⮚ Mantenimiento correctivo y resolución de incidencias de las herramientas del entorno de integración continua y aseguramiento de la calidad.

⮚ Actualización de manuales de uso.

4.2.4.- Oficina de Calidad

Más allá de continuar con los trabajos existentes en cuanto a la evaluación de la calidad de los productos de software y documentales en cuanto a los mínimos de calidad establecidos en la metodología de la DGOJ, para la consecución del objetivo detallado, se identifican las siguientes tareas mínimas a realiza por parte de la Oficina de Calidad:

• Realizar una revisión y análisis de los entornos existentes, realizando el mantenimiento y actualización xxx Xxxx de Aplicaciones actual de la DGOJ.

• Llevar a cabo el mantenimiento y actualización del Plan de Calidad de la DGOJ (puntos de control, inventario de controles, modelo de aceptación/rechazo, acuerdos de Nivel de Servicio, contenido de los informes de certificación, etc.).

• Será responsabilidad de la oficina de calidad ejecutar el Plan de Calidad en todas y cada una de las aplicaciones que el Área IT considere oportuno, realizando para ello al menos las siguientes actividades:

⮚ Revisión de la documentación aportada por los distintos equipos de desarrollo al objeto de validar su calidad acorde a estándar establecido en la DGOJ.

⮚ Diseño y desarrollo de pruebas unitarias para cada una de las funcionalidades, tomando como base los requerimientos identificados así como los casos de uso definidos por los equipos de desarrollo.

⮚ Realización de pruebas de código estático.

⮚ Realización de pruebas de estabilidad y rendimiento (carga y estrés).

⮚ Definición y desarrollo de nuevas pruebas funcionales, en base a la experiencia y conocimientos del equipo de Testing, así como de la documentación del desarrollo entregada para la identificación de errores y casos de uso no considerados por parte de los equipos de desarrollo.

⮚ Definición y desarrollo de pruebas de usuario de cara a la identificación de los problemas o dificultades que pudieran presentarse como parte de la operativa de trabajo con las aplicaciones probadas, como por ejemplo, los tiempos de carga necesarios para el acceso a la información por medio de las herramientas o la identificación de incoherencias en la navegación y uso de las aplicaciones.

⮚ Generación de los juegos de datos, ficheros o cualquier otro soporte necesario para el correcto desarrollo de las pruebas definidas por parte del equipo de Testing.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 25 de 75-

⮚ La validación de los requerimientos definidos por el departamento para la recolección y recopilación de información por medio de formularios (Normalización y congruencia de formularios).

⮚ Revisión de los hallazgos encontrados anteriormente sobre los desarrollos por parte del equipo de Testing. De manera general, la aproximación utilizada por la DGOJ se basa en el desarrollo iterativo e incremental de las pruebas sobre cada uno de los desarrollos.

⮚ Recomendaciones para la mejora de la usabilidad de los desarrollos, y la mejora de las interfaces presentadas a los usuarios o los mensajes presentados a los mismos.

⮚ Automatización y ejecución de los casos de prueba, siempre que sea posible, por medio de la herramienta definida por la DGOJ (Squash). En estos casos será necesaria la definición detallada así como el registro de los casos de prueba desarrollados para la ejecución automatizada de las pruebas.

Además, en los casos en los que existan requerimientos específicos por parte de la DGOJ, estos deberán ser incluidos como parte del programa de pruebas a realizar sobre la aplicación correspondiente.

4.2.5.- Centro de soporte a usuarios

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

La DGOJ desea mantener el servicio de soporte a usuarios anteriormente indicado (véase apartado II.3.1.5 Centro de soporte a usuarios), así como la calidad del mismo, y mejorar y ampliar el soporte a la operativa ofrecido por la base de conocimiento. Además, en los casos en los que existan requerimientos específicos por parte de la DGOJ en cuanto al servicio de soporte a usuarios a prestar, estos deberán ser incluidos como parte del mismo.

4.3.- Estimación de unidades de trabajo asociadas a los trabajos a realizar en el lote 4

En conjunto se estima que los servicios objeto de este lote de contratación van a requerir 1.036 UT (umbral de UT de este lote).

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 26 de 75-

III.- Prestación de servicios.

Los servicios a prestar en cada uno de los lotes, se clasifican en tres grandes grupos de actividades:

• Servicios de organización y gestión del servicio.

• Servicios no planificables.

• Servicios planificables.

1.- Servicios de organización y gestión del servicio

Agrupa las diferentes actividades necesarias para asegurar que la ejecución de los servicios se ajusta al modelo de la DGOJ, adoptando sus estándares, con los niveles de calidad requeridos y ayudando a su consolidación y evolución. Con los servicios de gestión el adjudicatario deberá:

• Asegurar el nivel de interlocución con la DGOJ en términos de servicio.

• Asegurar que sus equipos tienen el conocimiento del modelo de servicios (Ver cláusula IV Modelo de servicios).

• Garantizar la correcta aplicación del modelo de servicios en la prestación desempeñada por sus perfiles profesionales.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Definir, asignar a sus perfiles profesionales y coordinar las diferentes tareas asociadas a la prestación de cada uno de los servicios demandados por DGOJ, garantizando una óptima gestión de sus capacidades.

• Garantizar los niveles de servicio mínimos requeridos para satisfacer las necesidades de la DGOJ.

• Asegurar la calidad en todas las entregas realizadas a la DGOJ, tanto de software, como de documentación, informes, presentaciones, o cualquier entregable relacionado con la prestación de los servicios objeto del presente pliego de prescripciones técnicas.

• Asegurar la visión integral del servicio prestado, y contribuir activamente a su mejora continua.

• Garantizar la correcta adquisición del conocimiento funcional y técnico a lo largo de la vida del contrato, necesario para la adecuada prestación de los servicios.

• Gestionar adecuadamente el conocimiento recibido y generado a lo largo de la ejecución del contrato, garantizando su documentación y su traspaso a la DGOJ de forma periódica.

2.- Servicios no planificables

Agrupa las líneas de servicio que, por su naturaleza, no pueden planificarse en el tiempo. Dentro de esta categoría se pueden distinguir las siguientes tipologías:

• Mantenimiento correctivo. Actividades a realizar en el producto entregado (software, bases de datos, documentación, etc.) ante una incidencia o funcionamiento incorrecto, deficiente o incompleto, sin incremento de funcionalidad o documentación. Son las tareas relacionadas con la subsanación de errores o fallos ocultos que se pongan de manifiesto en el funcionamiento de las aplicaciones en producción, o que se descubran mediante pruebas o cualesquier medio, así como la conclusión de la documentación incompleta y subsanación de la que contenga deficiencias.Además sirve para evitar fallos como consecuencia de actuaciones, actualizaciones, cambios de versión, etc.

Los productos originados como consecuencia de la subsanación de fallos se entregarán con una prioridad que dependerá de la criticidad de la incidencia. Estas actuaciones tendrán como entregable el propio software así como toda la documentación pertinente asociada a las actividades realizadas y asociada a la actualización de los sistemas que apliquen.

Las actividades incluidas en los servicios de mantenimiento correctivo son las siguientes:

⮚ Catalogación y priorización de las incidencias detectadas en sistemas o en la documentación por el equipo de trabajo correspondiente. La categorización de las incidencias o correctivos se realiza en base a la

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 27 de 75-

metodología existente en la DGOJ (ver Anexo I), esta categorización en base a la criticidad conlleva la priorización de las incidencias.

⮚ Resolución de las incidencias por riguroso orden de prioridad.

⮚ En caso de tratarse de un correctivo relacionado con una versión de software, preparación de los componentes a desplegar en los entornos de preproducción y producción de la nueva versión resultante de la corrección de las incidencias detectadas. Estos despliegues comprenden principalmente las siguientes tareas:

▪ Creación de la Hoja de Tránsito con los documentos de despliegue y manuales asociados, así como la creación del paquete con los elementos a desplegar.

▪ Soporte a Sistemas o al equipo de pruebas en el despliegue en el entorno de preproducción.

▪ Soporte al equipo de pruebas en la ejecución de las pruebas por parte de este equipo, así como resolución de las incidencias que puedan surgir durante la fase de pruebas.

▪ Soporte a Sistemas en el despliegue en el entorno de Producción.

• Soporte al usuario. El objetivo del soporte a usuarios es canalizar y dar respuesta a las consultas de los usuarios ya sea por los aplicativos o por los contenidos.

• Evolutivos menores. Actividad que no está incluida en las definiciones previas, asociada a pequeños desarrollos, y que satisface los siguientes requisitos:

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

⮚ Requiere una gestión abreviada y rapidez en su ejecución (plazo de solución inferior a 5 UT).

⮚ Normalmente el esfuerzo de ejecución por petición no va a superar las 5 UT e implica especialización en los sistemas de información afectados (aplicaciones, modelo de datos, etc.).

3.- Servicios planificables

Agrupa las líneas de servicio que por su naturaleza, pueden ser planificadas en el tiempo. Dentro de esta categoría se pueden distinguir las siguientes tipologías:

• Mantenimiento evolutivo. Concebido como extensión, ampliación y/o mejora de funcionalidad sobre el sistema de información para satisfacer las necesidades cambiantes de la DGOJ. Este mantenimiento cubre situaciones que no se pueden prever en los estadios iniciales del proyecto y que surgen cuando se comienza a utilizar el sistema y se analiza su desempeño diario para recoger mejoras y nuevas funcionalidades. A su vez, el mantenimiento evolutivo se puede catalogar en:

⮚ Mantenimiento adaptativo. Estas actividades están motivadas por el cambio del entorno técnico y/o funcional en el que el sistema software debe operar derivado de cambios normativos, de versiones de las infraestructuras, de rediseño de funcionalidades existentes a petición del usuario, etc. Una enumeración no exhaustiva incluiría cambios en el sistema operativo, en la versión de base de datos, servidor de aplicaciones, etc.

En el desarrollo de los sistemas de información se emplearán los estándares definidos y las mejores prácticas xxx xxxxxxx para poder garantizar que el producto realizado sea lo más independiente posible de los cambios que puedan surgir en el software de base sobre el que se sustenta el sistema. Esto permitirá que la adaptación a nuevas versiones sea lo más ligera posible, quedando idealmente restringida a la realización de pruebas de regresión sobre la nueva versión.

⮚ Mantenimiento perfectivo. Consiste en cualquier inserción, eliminación, modificación, extensión y/o mejora realizadas sobre un sistema después de su entrega para mejorar su funcionamiento y/o mantenibilidad. Acciones llevadas a cabo para mejorar la calidad interna del sistema en cualquiera de sus aspectos: optimización de rendimiento y eficiencia, reestructuración del código, definición más clara del portal o solicitudes de mejora de los usuarios que supongan una gestión más ágil.

⮚ Mantenimiento preventivo. Son las actividades realizadas con el propósito de prevenir problemas latentes antes de que estos ocurran y mejorar la calidad del software mantenido, sin modificación de funcionalidad.

⮚ Mantenimiento correctivo. Actividades a realizar en el producto entregado ante una incidencia o funcionamiento incorrecto, deficiente o incompleto, con incremento de funcionalidad o documentación.

Es decir, son las tareas relacionadas con la subsanación de errores que por su índole implica una

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 28 de 75-

planificación asociada a un análisis específico al objeto de subsanar la incidencia y un cambio de versión del producto frente a una actualización, que es lo que conllevaría un mantenimiento correctivo no planificable.

• Nuevos desarrollos. Concebido como el desarrollo de nuevas funcionalidades que pueden dar lugar a una nueva versión de los sistemas, o incluso, a la generación de un nuevo aplicativo dentro del ámbito funcional objeto de este contrato.

• Análisis, estudio y documentación. Concebido como actividades de estudio previo y/o análisis de situaciones de negocio/mercado para la confección de un documento de solución detallado, que sirva a la DGOJ como elemento para la toma de decisión previa al posible planteamiento de un futuro proyecto de desarrollo o de un futuro automatismo de publicación de contenidos, o lo que es más importante, que permita al equipo de desarrollo estimar el encargo de trabajo (ET) en base a dicho análisis (Ver cláusula IV.3. Modelo de gestión: Supervisión, control y seguimiento de la ejecución).

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Validación de la calidad. Concebido como actividades enfocadas a la verificación de los niveles de calidad de productos entregados asociados a los servicios prestados por los distintos contratistas a la DGOJ. El fin último del servicio es la validación del cumplimiento de la metodología establecida en cuanto a niveles mínimos aceptables, tanto en cuanto a funcionalidades, calidad del código fuente y documentación de productos software, como documentación de otra índole solicitada como encargo de trabajo (estudios, informes, o análisis de algún tipo).

A continuación, se muestra un diagrama conceptual de los servicios a prestar en cada uno de los lotes objeto de la contratación:

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 29 de 75-

IV.- Modelo de servicios.

1.- Fases del servicio

Siguiendo la metodología de la DGOJ, la prestación del servicio se dividirá en varias fases o etapas:

• Planificación.

• Transición.

• Hito de transferencia del servicio.

• Prestación del servicio.

• Devolución del servicio.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

1.1.- Fase de planificación

La fase de planificación será única, simultánea para todos los servicios y en algunos momentos solapada con la transferencia del servicio. Los objetivos asociados a esta fase inicial son los siguientes:

• Organización y constitución del equipo de trabajo base propuesto.

• Desarrollo del Plan General de los servicios.

• Definición del Plan de Riesgos, incluyendo la identificación de riesgos principales y las acciones asociadas, con especial foco en la garantía de la continuidad en la resolución de incidencias y peticiones (principalmente las críticas).

• Elaboración de un Plan de Hitos principales, incluyendo fechas y requisitos para que se produzcan.

Con referencia a la fase posterior de Transición el adjudicatario desarrollará un Plan de la Transición del servicio y conocimiento. Dicho plan de transición deberá contemplar al menos las siguientes actividades y contenidos:

• Detalle de las actividades a realizar por los equipos de trabajo y cronograma asociado.

• Identificación y recopilación de la documentación necesaria (documentación de los sistemas y aplicaciones, documentación técnica, procedimientos de actuación, etc.) para la xxxxxxxx del servicio.1

• Identificación de los riesgos específicos a la fase de transición, con especial énfasis en las tareas iniciadas o previstas en el momento en el que el adjudicatario asume el servicio.

• Definición de los hitos principales de la transición incluyendo fechas y requisitos para que se produzcan.

• Identificación de las actividades de comunicación y formación necesarias para garantizar la fase de transición.

1 En aquellos casos en los que no exista documentación previa necesaria para prestar el servicio, el adjudicatario entrante deberá planificar, de acuerdo con la DGOJ, y ejecutar su elaboración, sin coste adicional.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 30 de 75-

En esta documentación, además de identificar todas las actividades a llevar a cabo con las fechas de inicio y fin de cada una de ellas, se incluirán los criterios aplicables de aceptabilidad y cualquier otro detalle adicional que se estime pertinente. Adicionalmente, los documentos propuestos tendrán que ser aprobados por la DGOJ previamente a su ejecución.

En cualquier caso, se espera la participación activa del adjudicatario para garantizar la correcta alineación de las planificaciones. La DGOJ podrá identificar dependencias y condicionantes que el adjudicatario deberá respetar.

Una vez exista un plan definitivo de transición acordado, las fechas de transferencia serán inamovibles, salvo que la DGOJ requiera una nueva planificación del plan definitivo de transición.

1.2.- Fase de transición

1.2.1.- Transferencia del conocimiento

Mientras continúa la fase de planificación, y después de que la DGOJ apruebe el plan general diseñado, podrá iniciarse la fase de transferencia del conocimiento.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

El objetivo de esta fase es el traspaso de los elementos básicos e imprescindibles para la prestación del servicio, entre el adjudicatario saliente y el entrante. Durante la misma, el adjudicatario saliente sigue prestando servicio a la DGOJ, por lo que su disponibilidad será limitada, y el adjudicatario entrante ejecuta el plan definitivo de transición con todas las actividades que le permitan prepararse para asumir el servicio.

La forma de transferir el conocimiento entre el adjudicatario saliente y el entrante será aplicando la técnica del solapamiento. Esta técnica consiste en que el personal del adjudicatario entrante, una vez conoce de manera básica, los procedimientos de trabajo a través del estudio de los documentos que los describen, podrá participar en las labores de prestación del servicio junto con el personal del adjudicatario saliente, para conocer en detalle práctico el uso de las herramientas y la aplicación práctica de los procedimientos.

Durante esta fase, la gestión del servicio sigue siendo del adjudicatario saliente, por lo que las actividades se desarrollarán teniendo en cuenta la prioridad del servicio sobre cualquier otra circunstancia.

Esta fase durará 30 días naturales como mínimo (incluyendo la fase de planificación) y las empresas que participen en esta etapa deberán firmar el preceptivo acuerdo de confidencialidad sobre la información que se reciba.

Todos los intercambios formales de entregables, deberán quedar documentados y aceptados por ambos adjudicatarios (entrante y saliente), de manera formal y fehaciente.

El adjudicatario entrante tiene obligación de documentar todas las actividades realizadas durante del proceso de transición y entregar esa documentación a la DGOJ cuando termine el proceso de transición. Para la correcta certificación de esta fase, se solicitará al adjudicatario el Estado del Arte de los Servicios correspondientes a este pliego.

1.2.2.- Transferencia de servicios

La transferencia de servicios entre adjudicatarios (entrante y saliente) deberá ser llevada a cabo por el adjudicatario entrante, quien contará con la información aportada por el adjudicatario actual.

La transferencia del servicio finaliza con el hito de transferencia del servicio del adjudicatario saliente al entrante, cuya fecha estará definida en el plan definitivo de transición aprobado por la DGOJ. El adjudicatario entrante se compromete a cumplir con dicha fecha de finalización de la transición.

1.3.- Hito de transferencia del servicio

Se trata del hito culminante de la transición. Antes de que pueda ocurrir este hito, el adjudicatario entrante deberá

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 31 de 75-

haber realizado las siguientes tareas:

• Ejecución de todas las actividades planificadas en relación a este hito en el plan definitivo de transición.

• Registro documental de todas las entregas de documentación habidas entre adjudicatarios o entre la DGOJ y el adjudicatario entrante.

• Registro documental de todos los hechos significativos de la transición.

• Presentación de la base de datos de conocimiento de la operativa del equipo de trabajo.

Al final de la fase de desarrollo de la transferencia, se procederá a ejecutar el hito de transferencia del servicio, que marcará el inicio de la fase de prestación del servicio supervisada, y por lo tanto, la finalización de la prestación del servicio por el adjudicatario saliente.

A su vez, el adjudicatario entrante recibirá, si no lo ha hecho en momentos anteriores, todas las peticiones de servicio y trabajos inacabados. El adjudicatario entrante es responsable de atender la lista de tareas y trabajos que estén iniciados o pendientes de inicio, en el momento en que asuma el servicio. Esto incluye, de manera expresa, la resolución de incidencias que no hayan podido ser resueltas por el adjudicatario saliente, antes del hito de transferencia del servicio.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

El cumplimiento del hito de transferencia del servicio, deberá quedar formalmente documentado mediante actas y deberá ser aceptado tanto por parte del adjudicatario entrante, como por parte de la DGOJ.

Tan pronto como el adjudicatario entrante adquiera el servicio se entrará en la fase de prestación supervisada del servicio.

1.4.- Fase de prestación del servicio

La fase de prestación y cobro del servicio, comenzará tras el cumplimiento del hito de transferencia del servicio y tendrá una duración de veinticuatro meses acorde a lo establecido en la cláusula de “Plazo de duración del contrato” del PCAP, que finalizará formalmente con la fase de devolución del servicio, sin menoscabo de una posible prórroga del contrato.

Desde este momento, el adjudicatario entrante es responsable de ofrecer los servicios que se detallan en este pliego, y en los términos que éste indica. En particular cabe destacar que asume lo siguiente:

• Cumplimiento de los acuerdos de Nivel de Servicio.

• Mantenimiento de la documentación de los servicios objeto de la transferencia. La documentación deberá ser actualizada ante cualquier necesidad del servicio, así como a generar la nueva documentación que se estime necesario.

• Seguimiento de los procesos y procedimientos operacionales y de soporte, según lo indicado en el presente pliego.

• Cumplimiento de todas las tareas de seguimiento del servicio, incluyendo la presentación de los informes acordados.

• Todo el resto de las tareas identificadas en el presente pliego.

1.5.- Fase de devolución del servicio

En todos los casos, existirá una fase de devolución del servicio para garantizar la transferencia del conocimiento adquirido o generado durante la prestación del servicio por parte del adjudicatario hacia la DGOJ, o hacia el adjudicatario que la DGOJ designe, sin que ello repercuta en una pérdida del control o del nivel de calidad del servicio.

En caso de cese o finalización de contrato, el adjudicatario estará obligado a devolver el control de los servicios objeto del contrato, simultaneándose los trabajos de devolución con los de prestación del servicio, sin coste adicional.

El servicio deberá seguir prestándose, pero adicionalmente habrá que realizar las actividades propias de la reversión del servicio. Durante esta fase, la DGOJ reducirá el número de cambios y nuevos proyectos al mínimo posible, para reducir

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 32 de 75-

la complejidad de la gestión del servicio, en estas circunstancias.

Al inicio de la fase de devolución del servicio, el adjudicatario hará una evaluación y planificación de todas las actividades necesarias. Dicho traspaso se realizará con una duración mínima de 30 días naturales desde la notificación del inicio de esta fase.

El adjudicatario deberá realizar el proceso de transición de salida o devolución del servicio, asegurando que se mantienen correctamente, durante el traspaso, el control de servicios y deberá colaborar activamente con la DGOJ y con el futuro adjudicatario durante este proceso, para facilitar la transferencia del conocimiento y de los servicios.

El adjudicatario deberá hacer entrega a la DGOJ de una versión actualizada de toda la documentación e información manejada para la prestación del servicio antes de la finalización del contrato.

2.- Medición de los niveles de servicio

El presente pliego establece el conjunto de acuerdos de Nivel de Servicio (ANS), que serán objeto de seguimiento mensual y el nivel de cumplimiento de los mismos como umbral de calidad de servicio.

Se entiende por ANS el nivel de prestación del servicio exigido al contratista para cada uno de los indicadores.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

El principal objetivo del ANS es establecer parámetros medibles que permitan a la DGOJ, como responsable del servicio, y al adjudicatario, controlar la calidad de los servicios prestados, tanto de manera puntual como en su evolución en el tiempo.

El adjudicatario proporcionará la información necesaria para el seguimiento del ANS establecido mediante los correspondientes informes de seguimiento, y garantizará el mantenimiento de históricos de actividad durante todo el período de vigencia del contrato.

La información será objetiva y obtenida preferentemente a través de los registros elaborados con las herramientas de gestión. Tanto las herramientas de gestión como la forma de extracción de la información serán aprobadas por la DGOJ.

El contratista presentará mensualmente el informe correspondiente a la medición del ANS; dicha información deberá ser obtenida mediante los procedimientos y mecanismos establecidos por la DGOJ, que se reserva el derecho de contrastar la información facilitada.

El incumplimiento de los valores comprometidos en el ANS supondrá la aplicación de las penalidades previstas en el pliego de cláusulas administrativas particulares.

El ANS inicialmente definido será de aplicación desde el momento en que el adjudicatario comience a prestar el servicio.

A fin de mejorar la calidad del servicio prestado, el ANS recogido en el Anexo III, estará orientado a la mejora continua.

En los indicadores definidos se establece el Nivel de Servicio mínimo exigido para los servicios objeto de este contrato. Los niveles de servicio por debajo de este umbral estarán sujetos a penalidades que se calcularán conforme al procedimiento descrito en el pliego de cláusulas administrativas particulares. El cumplimiento de los niveles de servicio se revisará mensualmente en las reuniones de seguimiento del contrato.

ACUERDOS DE NIVEL DE SERVICIO
INDICADOR		DESCRIPCIÓN	SERVICIOS A APLICAR	NIVEL DE SERVICIO
I_1	Perfiles asignados durante la ejecución	Indicador para la comprobación de que los requisitos de los perfiles profesionales adscritos a la ejecución del contrato son, como	-Organización y gestión del servicio	Experiencia de los perfiles profesionales adscritos a la

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 33 de 75-

ACUERDOS DE NIVEL DE SERVICIO
INDICADOR		DESCRIPCIÓN	SERVICIOS A APLICAR	NIVEL DE SERVICIO
		mínimo, iguales a los exigidos en el PCAP		ejecución del contrato ≥ Experiencia de los perfiles profesionales exigidos
I_2	Tiempo entrega de informes de seguimiento	Tiempo entrega informes de seguimiento del servicio	-Organización y gestión del servicio	≤ 2 días laborales, tras el plazo de entrega periódico estimado por la DGOJ
I_3	Cumplimiento de plazos de entrega de ET planificados	Indicador para la detección de desviaciones en la consecución de los plazos de los hitos y entregables previstos en las planificaciones. Las planificaciones estarán aprobadas por la DGOJ acorde al modelo de gestión del presente pliego	-Mantenimiento evolutivo -Mantenimiento correctivo -Nuevos desarrollos -Análisis, estudio y documentación -Validación de la calidad	Desviación ≤ 25%
I_4	Calidad de la estimación de encargos de trabajo planificados	Indicador para la detección de desviaciones en las estimaciones previstas en las planificaciones. Las planificaciones estarán aprobadas por la DGOJ acorde a la cláusula IV.3 (Modelo de gestión: Supervisión, control y seguimiento de la ejecución) del presente pliego	-Mantenimiento evolutivo -Mantenimiento correctivo -Nuevos desarrollos -Análisis, estudio y documentación	desviación sea ≤ 25%
I_5	Índice de solución de peticiones	Indicador del nivel de resolución, utilizando el porcentaje de peticiones solucionadas (de las pendientes al inicio de dicho mes) durante el mes, del total de peticiones pendientes registradas al inicio de dicho mes. Estas peticiones hacen referencia a cualquier actividad no planificable distinta del mantenimiento correctivo	-Soporte al usuario (CAU)	Grado de cumplimiento según nivel de la petición
I_6	Índice de esfuerzo dedicado en correctivos	Este indicador mide el esfuerzo dedicado a la resolución de correctivos durante el servicio, lo que servirá para evaluar los niveles de calidad del mismo acorde a los mínimos establecidos. Este indicador se calcula trimestralmente	-Mantenimiento correctivo	≤ 10%
I_7	Índice de calidad del código fuente	Este indicador mide la calidad del código fuente entregado en base a unas métricas preestablecidas. La herramienta de análisis utilizada es	-Mantenimiento evolutivo -Nuevos desarrollos -Mantenimiento correctivo	% determinado de cumplimiento de la herramienta SONAr en distintos

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 34 de 75-

ACUERDOS DE NIVEL DE SERVICIO
INDICADOR		DESCRIPCIÓN	SERVICIOS A APLICAR	NIVEL DE SERVICIO
		SONAR, y los umbrales de calidad de las reglas a aplicar pueden consultarse en el Aneso I. Se calcula trimestralmente		aspectos
I_8	Índice de calidad del desarrollo en las pruebas de aceptación	Como indicador se utilizará el número de incidencias (altas, medias y bajas) imputables a desarrollo, detectadas a lo largo del primer ciclo de pruebas de aceptación realizadas por el equipo de testing	-Mantenimiento evolutivo -Nuevos desarrollos -Mantenimiento correctivo	≥ 85, calidad media del software
I_9	Índice de calidad del desarrollo en la Nª regresión	Mide el porcentaje ponderado del nº casos de prueba no afectados por incidencias (bloqueantes, altas, medias y bajas) imputables a desarrollo, detectadas en el N ciclo de pruebas de regresión, respecto del nº total de casos de pruebas ejecutados	-Mantenimiento evolutivo -Nuevos desarrollos -Mantenimiento correctivo	≥ 90, calidad media del software en ciclos de regresión
I_10	Índice de calidad del desarrollo según ciclos de pruebas de regresión	Mide el nº de ciclos de pruebas de regresión, en el ciclo completo, necesarios para solucionar todas las incidencias bloqueantes y altas	-Mantenimiento evolutivo -Nuevos desarrollos -Mantenimiento correctivo	Nactualizaciones <3
I_11	Calidad en el cumplimento documentalista exigido por la metodología de la DGOJ	Mide el porcentaje del nº de entregables establecido por la metodología de la DGOJ sin incidencias altas ni medias respecto del nº total de entregables establecidos	-Todos los servicios	≥ 80%
I_12	Ratio de eficacia de puesta en producción de encargos de trabajo (ET)	Mide el porcentaje del nº de encargos de trabajo (ET) puestos en producción con respecto a los inicialmente previstos	-Mantenimiento evolutivo -Nuevos desarrollos -Mantenimiento correctivo	≥ 85%
I_13	Índice de solución de incidencias de Calidad	Mide el nivel de resolución, utilizando el porcentaje de las incidencias solucionadas por los equipos de desarrollo frente a las incidencias abiertas por el equipo de Calidad en las revisiones. Las incidencias funcionales abiertas por el equipo de calidad deben estar solucionada en la siguiente entrega de versión (ya sea una nueva iteración o una nueva versión	Validación de la Calidad	≥ 80% del tiempo total

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Los indicadores de calidad y sus acuerdos de nivel de servicio pueden verse afectados siempre y cuando se produzcan eventos y circunstancias ajenas al contratista y que afectan a los trabajos a desarrollar:

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 35 de 75-

• Incidencias críticas, de carácter masivo o de afección de servicios críticos: En caso de producirse una Incidencia crítica de carácter masivo, cuya causa origen sea ajena al servicio prestado por el adjudicatario (como la caída general de alguna de las aplicaciones o servicios relevantes), y que por su impacto en el servicio incremente en un 30% la demanda media anual de servicio diaria y por tanto afecte de forma negativa al cumplimiento de los ANS, se analizarán los días afectados por la incidencia concreta de forma independiente. Este análisis permitirá verificar si el incumplimiento del nivel de servicio está ocasionado por esta causa.

• Condiciones anormales de prestación del servicio: En caso de producirse problemas de rendimiento o dimensionamiento de la infraestructura, sistemas de información, etc. propiedad de la DGOJ, que soportan la gestión del servicio objeto del contrato y que de forma clara perjudiquen el normal desempeño del servicio prestado por el adjudicatario, se analizará la circunstancia de forma independiente. Este análisis permitirá verificar si el incumplimiento del nivel de servicio está ocasionado por esta causa.

3.- Modelo de gestión: supervisión, control y seguimiento de la ejecución 3.1.- Procedimiento y herramientas de planificación y valoración

El adjudicatario aplicará la metodología de planificación, ejecución, análisis, diseño, construcción e implantación de aplicaciones, así como el entorno de desarrollo que proporcione la DGOJ.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Como parte de las tareas objeto del contrato, el adjudicatario se compromete a generar la documentación de los trabajos realizados de acuerdo con los criterios que establezca la DGOJ por medio de la Oficina Técnica de Proyectos. La DGOJ designará un responsable del proyecto, JPdgoj, que asumirá la dirección y control del mismo y actuará como principal interlocutor con el adjudicatario por parte de la Administración.

Asimismo, el adjudicatario designará al menos a un CTcontratista, el cual actuará como interlocutor con la DGOJ, debiendo facilitar al responsable de la misma el reporte de actividad que éste requiera en cada momento sobre el avance de los trabajos, justificación de posibles retrasos y cualquier otra información que se precise. Este CTcontratista estará asistido por un número adecuado de personas con los conocimientos necesarios para llevar a cabo las tareas descritas en el presente pliego.

El CTcontratista canalizará la comunicación entre la empresa contratista y el personal integrante del equipo de trabajo adscrito al contrato, de un lado, y la DGOJ, de otro lado, en todo lo relativo a las cuestiones derivadas de la ejecución del contrato.

Así mismo, distribuirá el trabajo entre los perfiles profesionales encargados de la ejecución del contrato, e impartirá las órdenes e instrucciones de trabajo que sean necesarias en relación con la prestación del servicio contratado.

Al inicio del proyecto se establecerá la periodicidad y soporte documental de las reuniones de control y seguimiento de la ejecución del contrato. En ellas se evaluarán todas aquellas incidencias habidas durante la prestación del servicio, que hubieran originado retrasos en el cumplimiento de los objetivos planificados.

El contratista será responsable de la elaboración de las actas de las reuniones de control y seguimiento, que serán revisadas, y en su caso, corregidas y aprobadas por ambas partes.

En los plazos previstos, el CTcontratista nombrado por el contratista entregará a la DGOJ, los entregables y la correspondiente documentación para su verificación y control de calidad. Toda la documentación requerida en el presente documento se entregará en castellano y totalmente actualizada.

Se entregará toda la documentación definida en los requerimientos enumerados en el punto de la memoria dedicado al detalle de los trabajos a realizar.

La documentación quedará en propiedad exclusiva de la DGOJ, sin que el contratista pueda conservarla, ni obtener copia de la misma o facilitarla a terceros sin la expresa autorización del centro directivo.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 36 de 75-

Una vez finalizado el plazo de ejecución del contrato, se comprobará la entrega de los productos, la documentación y la información prevista en el contrato.

En fase de ejecución de la contratación, el modelo de gestión se ajustará al siguiente esquema para cada lote:

• El JPdgoj de cada área funcional confeccionará las solicitudes o encargos de trabajo (ET) en los que se hará constar las prestaciones a realizar, el entorno técnico, el tipo de prestación funcional o servicio solicitado, las fechas límite de disponibilidad, y la prioridad asignada a cada una de las prestaciones.

En caso de tratarse de un ET asociado a servicios de nuevos desarrollos, o mantenimientos evolutivos, se proporcionarán las especificaciones funcionales o el análisis funcional y, en su caso, los requerimientos o elementos de diseño técnico a asumir por el adjudicatario a efectos de su desarrollo. Todo ello, sin menoscabo de ser el análisis funcional o las especificaciones funcionales el propio ET solicitado.

Para permitir el seguimiento del servicio que se requiere a efectos de esta contratación es preciso que los ET estén conformados por prestaciones perfectamente identificables en cuanto a su puesta en producción o disponibilidad.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Cada ET estará configurado por los siguientes elementos, algunos de los cuales ya se han avanzado anteriormente:

⮚ Código asignado al ET.

⮚ El tipo de servicio o prestación asociada al encargo de trabajo. Al menos se considerarán siete tipos diferenciados de prestaciones o servicios:

▪ Nuevos desarrollos.

▪ Mantenimiento evolutivo.

▪ Mantenimiento correctivo

▪ Análisis, estudio y documentación.

▪ Soporte al usuario.

▪ Validación de calidad.

▪ Organización y gestión del servicio.

En el caso del mantenimiento correctivo se identificará también en el ET el código asignado al ET del que derivan las incidencias objeto del mantenimiento correctivo.

⮚ En su caso, las especificaciones funcionales.

⮚ La especificación de contorno, bien por referencia a una especificación genérica para cada entorno o escenario técnico, y/o por definición de los requerimientos o elementos de diseño técnico, disponibilidad, escalabilidad, accesibilidad, usabilidad, interoperabilidad, seguridad, …, a asumir por el adjudicatario a efectos de su desarrollo.

⮚ Datos específicos relativos a la planificación temporal del ET. Respecto a esta planificación, en relación a prestaciones que impliquen actuaciones de desarrollo, al menos se proporcionarán las fechas límite de disponibilidad para pruebas de aceptación en el entorno de preproducción a efectos de la puesta en producción; y la prioridad asignada a cada una de las prestaciones.

⮚ La relación de entregables resultado del ET (a concretar por cada ET): especificación de diseño técnico que no formen parte de la especificación del contorno; diferentes versiones evolutivas de pruebas funcionales; maqueta funcional, prueba de concepto; código fuente; versión en preproducción; juego de pruebas funcionales; versión validada en producción; documentos asociados al encargo, kit de ayuda, manuales; planificación y programación de actividades; etc.

• Se considerará como ET de tipo mantenimiento correctivo no computable (es decir no facturable) aquel derivado de incidencias detectadas por el usuario final o en los procedimientos de pruebas y control de calidad que puedan derivar del incumplimiento de las especificaciones funcionales o de no haber tenido en cuenta el entorno tecnológico circundante, cuando esta información hubiera sido proporcionada al CTcontratista en un ET anterior. Es decir, son todas aquellos ET de desarrollo correctivo derivados de incidencias imputables al

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 37 de 75-

adjudicatario.

• Se considerarán ET de tipo desarrollo correctivo computable, aquéllos derivados de incidencias no imputables al adjudicatario.

• El coordinador técnico del entorno por parte del adjudicatario (CTcontratista), una vez recibido el ET, lo evaluará en un tiempo razonable y comunicará el resultado de la evaluación al JPdgoj, que comprenderá la siguiente información:

⮚ El número de UT que requerirá la realización de cada prestación.

⮚ Las fechas estimadas de disponibilidad de cada prestación, tanto para pruebas de aceptación en el entorno de preproducción a efectos de la puesta en producción en caso de tratarse de ET que impliquen desarrollo de software, como fecha de disponibilidad del producto de análisis o estudio solicitado, fin de actividades planificadas, así como otras fechas sobre las que se hubiera proporcionado en el ET una fecha límite de disponibilidad.

⮚ Las horas estimadas, desde la fecha de inicio de las actuaciones pertinentes, para la aceptación en el entorno de preproducción a efectos de la puesta en producción, o para la finalización del servicio o prestación en caso de no implicar desarrollo.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• En el caso de ET del tipo de “Mantenimiento correctivo” que sean susceptibles de planificarse por su importancia, así como para tareas de “Análisis, estudio y documentación”, “Validación de calidad” y residualmente para ET de “Mantenimiento evolutivo”, tanto la solicitud del ET por parte del JPdgog como la respuesta del CTcontratista se podrán calificar como de gestión abreviada. En este caso en la solicitud del JPdgog se requerirá exclusivamente la información estrictamente indispensable, no siendo necesario proporcionar aquella información ya aportada con el ET original ni los datos específicos relativos a la planificación temporal del ET. Es decir bastará con aportar el código asignado al ET, (en su caso) el código asignado al ET del que derivan las incidencias objeto del desarrollo correctivo, el tipo de prestación o servicio, y (en su caso) la descripción de la incidencia a corregir. Respecto a la respuesta del CTcontratista será suficiente con proporcionar las fechas estimadas de disponibilidad de cada prestación para pruebas de aceptación en el entorno de preproducción a efectos de la puesta en producción. Se asumirá en todo caso una prioridad alta para su ejecución.

• La evaluación efectuada por el CTcontratista deberá ser aprobada por el JPdgoj Si este último no estuviera de acuerdo con la evaluación se establecerá un proceso de diálogo hasta que el CTcontratista realice una evaluación que pueda ser aprobada por el JPdgoj que será la que se aplicará al ET.

• Cuando en el trascurso del desarrollo de un ET por el adjudicatario se produzca una modificación de las especificaciones funcionales se actualizará la evaluación correspondiente siguiendo un proceso similar al indicado anteriormente.

• La ejecución del ET podrá ser objeto de controles concomitantes por parte del JPdgoj y, en todo caso, cuando el CTcontratista ponga el resultado del ET a disposición del JPdgoj para su control de calidad.

• Cuando se haya realizado el ET a satisfacción de la DGOJ (y solamente en este caso, es decir cuando se haya producido por la DGOJ la aceptación del ET en el entorno de preproducción a efectos de la puesta en producción) se generará un importe facturable con cargo a la contratación, por el importe que corresponda al Nº de UT estimadas aprobadas (no a las realizadas) para el ET, facturadas al importe unitario ofertado por el adjudicatario.

• No obstante lo anterior, se reserva un 40% de las UT para prestaciones o servicios calificados como de tipo de gestión abreviada.

• La gestión del inventario de ET, tanto de las solicitudes como de los entregables, así como de los términos del acuerdo, de su ejecución, y aceptación se llevará a cabo a través de una forja de desarrollo colaborativo

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 38 de 75-

proporcionada por la DGOJ.

• Cuando un ET sea calificado como urgente por parte de la DGOJ, tal consideración podría afectar a la priorización establecida para ET anteriores, pudiendo requerir un nuevo ejercicio de asignación de prioridades de los ET en curso entre el JPdgoj y CTcontratista.

3.2.- Supervisión, control y seguimiento de la ejecución

La planificación, seguimiento y control del servicio se efectuará sobre las siguientes bases:

• Revisión y aprobación por parte del Director administrativo (Dadgoj) y/o los Jefes de Proyecto de la DGOJ (JPdgoj) de la planificación y evaluación de los ET elaboradas por los interlocutores o coordinadores técnicos (CTcontratista) del adjudicatario, de acuerdo con las prioridades y directrices establecidas por la DGOJ.

• Seguimiento continuo de la evolución de los trabajos por el Director administrativo (Dadgoj) o/y los Jefes de Proyecto de la DGOJ (JPdgoj).

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Reuniones de seguimiento y revisiones técnicas entre el gestor de la contratación por parte del adjudicatario (Gcontratista) o/y el o los interlocutores o coordinadores técnicos (CTcontratista) del adjudicatario, y el Director administrativo (Dadgoj) o/y los Jefes de Proyecto de la DGOJ (JPdgoj), al objeto de revisar la planificación de los trabajos, las especificaciones funcionales de cada uno de los objetivos, el grado de cumplimiento de los mismos, los niveles de prestación del servicio y las reasignaciones y variaciones de efectivos de personal dedicado al proyecto.

• El Director administrativo (Xxxxxx) o/y los Jefes de Proyecto de la DGOJ (JPdgoj) podrán rechazar en todo o en parte los trabajos realizados, en la medida que no respondan a lo especificado o no superen los controles de calidad acordados.

4.- Metodología en la elaboración de los trabajos 4.1.- Metodología de desarrollo

El adjudicatario aplicará la metodología de planificación, ejecución, análisis, diseño, construcción e implantación de aplicaciones, así como el entorno de desarrollo que proporcione la DGOJ.

4.2.- Calidad

En el documento Anexo I se pueden encontrar más detalles sobre la metodología a aplicar en el desarrollo y referencias al entorno tecnológico.

4.3.- Documentación de los trabajos

Como parte de los trabajos objeto del contrato, el adjudicatario se compromete a generar para cada producto obtenido toda la documentación que sea aplicable de acuerdo con la metodología y especificaciones de la DGOJ.

La documentación será propiedad exclusiva de la DGOJ sin que el contratista pueda conservarla ni obtener copia de la misma o facilitarla a terceros sin la expresa autorización del mismo, que la daría en su caso previa petición formal del contratista con expresión del fin.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 39 de 75-

ANEXO I

XXXXX DE REFERENCIA DE LA DGOJ

I.- Objeto.

El marco de referencia reflejado en el presente documento tiene como objeto establecer una visión global de las especificaciones técnicas, metodológicas y organizativas que deben ser tenidas en cuenta por los adjudicatarios de contratos cuyo objeto corresponda a la DGOJ.

En ningún caso, se trata de un documento completo donde se profundice en cada uno de los aspectos, sino que su finalidad es concretar las bases y directrices globales sin necesidad de profundizar un nivel de detalle antes de la adjudicación del contrato. Resuelto el mismo, la DGOJ proporcionará al adjudicatario un kit de bienvenida donde se detallen los aspectos aquí reflejados; acceso a las diferentes herramientas requeridas, así como la ubicación de las diferentes guías y/o manuales que pudieran existir para facilitar la aplicación de este marco de referencia.

II.- Ámbito de aplicación.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

El presente marco de referencia es de aplicación a todo proyecto de definición, diseño, construcción e implementación que sea realizado por un contratista para satisfacer las necesidades de la DGOJ, tanto si se tratan de nuevos desarrollos como si se corresponden con evolutivos y/o mantenimientos de sistemas ya existentes en el órgano.

III.- Vigencia.

El presente marco de referencia ha sido aprobado por el responsable de desarrollo, estableciendo de esta forma las especificaciones técnicas y organizativas en materia de gestión de ejecución de proyectos.

IV.- Referencias.

La información contenida en el presente documento a modo de presentación contextual, ha sido elaborada y/o sintetizada a partir de los siguientes documentos internos del órgano, los cuales se pondrán a disposición del contratista del servicio al iniciarse el contrato.

No obstante lo anterior, en caso de considerarse necesario el conocimiento de alguno de los documentos referenciados para la correcta constitución de la oferta, el licitador interesado podrá solicitar acceso al documento, siendo potestativo la concesión de dicho acceso por motivos de seguridad.

Directrices Globales

• Arquitectura de referencia en materia de control de acceso a los sistemas y/o aplicaciones.

ARQ.SEG.Arquitectura_de_Control_Acceso

• Arquitectura de referencia en materia de comunicaciones donde se establece la segregación en segmentos de red así como los dispositivos de interconexión u otros elementos / características de seguridad a tener en cuenta.

ARQ.SEG.Arquitectura_de_Comunicaciones Gestión de Proyectos

• Guía de metodologías, donde se recogen en detalle las fases, actividades y entregables que deben ser contemplados durante la gestión y ejecución de los proyectos.

GUI.PMO.Guia_de_Metodologias

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 40 de 75-

• Guía del jefe de proyecto, donde se resumen los aspectos claves que deben ser tenidos en cuenta por el responsable del contratista encargado de la ejecución del proyecto, durante las distintas fases de la metodología.

GUI.PMO.Guia_del_Jefe_de_Proyecto

• Control y Gestión de la Documentación, el cual establece los estándares de la documentación.

PRO.PMO.Control_y_Gestion_de_la_Documentacion

• Gestión documental de proyectos, donde se establece la estructura de carpetas que debe ser aplicada para el almacenamiento de información de los proyectos.

PRO.PMO.Gestion_Documental_de_Proyectos

• Modelo de Gestión de Encargos de Trabajo, Guías y plantillas relacionadas con la gestión de la nueva unidad de trabajo: Encargo de Trabajo, en la herramienta de soporte de gestión y seguimiento Redmine.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

XXX.XXX.XX_Modelo_Gestion_Encargos_de_Trabajo

• Gestión Económica

GUI.PMO.Gestión_Económica_en_Unidades_de_Trabajo

• Acuerdos a Nivel de Servicio, donde se especifican los indicadores que conforman el ANS y su evaluación.

GUI.PMO.ANS_Evaluación_Calidad_del_Servicio

Ejecución de Proyectos

• Gestión de la calidad del código fuente, el cual recoge las directrices de calidad que se aplicarán al código fuente, así como el conjunto de reglas que se verificarán con la herramienta de soporte empleada.

NOR.PMO.Gestion_de_la_Calidad_de_Codigo_Fuente

• Versionado del código fuente, donde se recoge el estándar de versionado que debe ser empleado durante el desarrollo de proyectos.

NOR.PMO.Versionado_del_Codigo_Fuente

• Manual del desarrollador, el cual describe en detalle las actividades que debe seguir un desarrollador para trabajar con el framework.

GUI.FRW.Manual_del_Desarrollador

• Encargos de Trabajo a Calidad, procedimiento con pautas, directrices que encaminen a los Contratistas en la creación de Encargos de Trabajo que evalúen la Calidad de sus entregas de producto:

GUI.PMO.Modelo_Gestion_ET_a_Calidad

Validación del Servicio

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 41 de 75-

• Validación de la calidad de documentación, el cual recoge las directrices y normativa de calidad que se aplicarán a los entregables asociados a los servicios prestados a la DGOJ.

NOR.PMO.Gestión_de_la_Calidad_Documental

• Validación de la calidad funcional, se recoge las directrices y normativa de calidad funcional aplicada a cada pase de versión de software. Adicionalmente, relacionado con la calidad funcional existe un procedimiento de uso de la herramienta TestLink,

PRE.PMO.Categorización_Pruebas NOR.PMO.Gestion_de_la_Calidad_Funcional MAN.PMO.Manual_de_Usuario_TestLink.docx

• Validación de la calidad de software, proceso incluido en el documento normativo asociado a la gestión de calidad del código fuente, donde como se ha indicado anteriormente, se recogen las directrices de calidad que se aplicarán al código fuente, así como el conjunto de reglas que se verificarán con la herramienta de soporte empleada.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

NOR.PMO.Gestion_de_la_Calidad_de_Codigo_Fuente Soporte del Servicio

• Integración GLPI con Redmine, procedimiento de integración de incidencias/solicitudes GLPI con Redmine que impactan en los servicios TI ofrecidos por el Área de Informática a otras áreas/departamentos de la DGOJ.

PRO.CAU.Integración_de_GLPI_en_Redmine

V.- Marco tecnológico.

En la actualidad existen multitud de tecnologías que responden a necesidades similares. Ahora bien, esta variedad se convierte también en un arma xx xxxxx filo ya que suele convertir los entornos tecnológicos de un organismo / empresa en ámbitos muy heterogéneos que dificultan las labores de gestión y mantenimiento y por consiguiente, un incremento desde una perspectiva económica.

Ante esto, la DGOJ establece la necesidad de orientar sus Sistemas de Información hacia un enfoque homogéneo donde se reduzcan la variedad de tecnologías empleadas.

En los siguientes subapartados se establece el marco de referencia tecnológico tanto a nivel de infraestructura de sistemas como de arquitectura de desarrollo, siendo este de obligado cumplimiento para todo proyecto que se ejecute en la DGOJ.

Excepcionalmente se permitirán otras tecnologías cuando por las características del proyecto no pudiera ser aplicado el marco de referencia. En líneas generales, estas excepciones serán recogidas en el propio pliego.

1.- Infraestructura de sistemas

ÁMBITO	SOLUCIÓN	OBSERVACIONES
Sistema operativo	Red Hat Enterprise Linux Server 5	Servidores de BBDD Oracle
	Red Hat Enterprise Linux Server 6	Resto de servidores
Servidor Web	Apache HTTP Server 2.2
Servidor de aplicaciones	Apache Tomcat 6
	Apache Tomcat 8

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 42 de 75-

Servidor BBDD	Oracle Database 12	Aplicaciones de negocio
	MySql 5.5	Aplicaciones de soporte
Gestor documental	Alfresco EE 4
Gestor de contenidos	Drupal 7

2.- Arquitectura de desarrollo

La diversidad de tecnologías existentes para abordar el desarrollo de un sistema de información, la complejidad para trabajar con algunas de ellas, y la problemática ante futuros mantenimientos de las aplicaciones, motivó la creación de una arquitectura de referencia en materia de desarrollo.

Este marco de referencia ofrece una arquitectura común de construcción de aplicaciones JavaEE, simplificando los desarrollos (encapsulación), fomentando la reutilización de componentes (servicios ad-hoc incorporados) y homogeneizando las tecnologías empleadas.

En los siguientes apartados se mencionan algunos de los aspectos más notables ofrecidos por la arquitectura sin profundizar en los mismos. Una vez formalizado el contrato el contratista dispondrá de acceso a los diferentes manuales y/o guías disponibles sobre el uso de la arquitectura:

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

• Manuales de las herramientas.

• Guía del desarrollador.

• Guías técnicas para la integración se servicios / capas.

• …

2.1.- Contexto tecnológico

A modo ilustrativo, se indican a continuación las diferentes tecnologías/frameworks y versiones que son contempladas en la arquitectura de desarrollo de la DGOJ.

COMPONENTE	VERSIÓN	ENLACE DOCUMENTACIÓN
Spring Framework	3.2.13.RELEASE	xxxx://xxx.xxxxxxxxxxxxxxx.xxx
Spring MVC	3.1.3.RELEASE	xxxx://xxxxxx.xxxxxxxxxxxx.xxx/xxxxxx/xxxx/0.0.x/xxxxxxxxx/xxx.xxxx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 43 de 75-

COMPONENTE	VERSIÓN	ENLACE DOCUMENTACIÓN
DHTMLX	4.0.3	xxxx://xxxxxx.xxx/
JQuery	1.8	xxxx://xxxxxx.xxx/
Spring Security	3.1.3.RELEASE	xxxx://xxxxxx.xxxxxxxxxxxx.xxx/xxxxxx-xxxxxxxx/xxxx/xxxxx.xxxx
Spring LDAP	1.3.1	xxxx://xxx.xxxxxxxxxxxx.xxx/xxxx
Spring Batch	2.1.9.RELEASE	xxxx://xxxxxx.xxxxxxxxxxxx.xxx/xxxxxx-xxxxx/
Quartz	1.8.6	xxxx://xxxxxx-xxxxxxxxx.xxx/
Apache CXF	2.7.0	xxxx://xxx.xxxxxx.xxx/
Xxxxxx Reports	4.6.0	xxxx://xxxxxxxxx.xxxxxxxxxx.xxx/xxxxxxx/xxxxxxxxxxxxx-xxxxxxx
Hibernate	0.0.0.Xxxxx	xxxx://xxx.xxxxxxxxx.xxx
QueryDSL	2.8.2	xxxx://xxx.xxxxxxxx.xxx/
Log4j	1.2.17	xxxx://xxxxxxx.xxxxxx.xxx/xxx0x/0.0/
Slf4j	1.7.7	xxxx://xxx.xxx0x.xxx/
Java	1.6	xxxx://xxx.xxxxxx.xxx/xxxxxxxxxxx/xxxx/xxxxx.xxxx
iTextPDF	5.5.6	xxxx://xxxxxxxx.xxx/
Visor PDF	1.2	xxxxx://xxxxxxx.xxxxxx.xx/xxx.xx/
Librería gráficos HTML	1.0.2	xxxx://xxxxxxx.xxx/
@firma (miniapplet)	1.2	xxxx://xxxxx-xxx.xxxxxxxxxxxxxxxxxxxxxxxxx.xxx.xx/xxx/xxxxxxxxxxxxx
Editor HTML	4.3.2	xxxx://xxxxxxxx.xxx/

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

2.2.- Ámbito de desarrollo

La primera premisa a la hora de abordar la construcción de una aplicación será contar con el entorno de desarrollo (IDE) propio de la DGOJ, siendo este autoinstalable y pre-configurado para trabajar directamente con la arquitectura.

En segundo lugar, la propia arquitectura proporciona mecanismos para establecer la estructura del proyecto, que dependerán de la tipología de aplicación a desarrollar:

• Proyecto base de negocio: Dicho proyecto contendrá toda la lógica de negocio, de acceso a base de datos y de integración con terceros sistemas. Este proyecto por sí solo no se puede desplegar en un servidor de aplicaciones.

• Proyecto base de presentación: Dicho proyecto contendrá los componentes de presentación que se requieren para el intercambio de información entre el navegador web del cliente y la aplicación. Un proyecto base de presentación deberá contener un proyecto base de negocio para disponer de la lógica de negocio, acceso a datos e integración con terceros sistemas.

• Proyecto base de servicios Web: Dicho proyecto puede contener la lógica de negocio, de acceso a datos y de integración con terceros sistemas, o por el contrario puede contener un proyecto base de negocio. Además dicho proyecto contendrá los componentes necesarios para desplegar la aplicación como un servicio web.

• Proyecto base StandAlone: Dicho proyecto contendrá toda la lógica de negocio, de acceso a base de datos y de integración con terceros sistemas, para utilizarse de forma independiente a un servidor de aplicaciones. El proyecto será autoejecutable desde el ordenador del usuario que únicamente deberá disponer de la máquina virtual de Java.

2.3.- Servicios y funcionalidades

La arquitectura de la DGOJ, además de proporcionar las características inherentes a los framework utilizados, proporciona las funcionalidades que se indican a continuación a las aplicaciones que se desarrollan bajo esta arquitectura:

• Autenticación de los usuarios a través del sistema de Single Sign-On implantado en la DGOJ, por lo que permite comprobar la validez del usuario de forma completamente transparente para la aplicación.

• Autorización de los usuarios a las aplicaciones, basado en un sistema que permite configurar el listado de permisos asignados a un usuario para el acceso a determinados módulos y acciones dentro de una aplicación.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 44 de 75-

• Auditoría de acceso de los usuarios a las aplicaciones y auditoría de la lógica de negocio de las aplicaciones.

• Sistema de monitorización de los componentes de arquitectura que utiliza la aplicación, permitiendo verificar de forma on-line si dichos elementos están operativos (ej: LDAP, servidor de correo, servicios Web, base de datos, etc.).

• Integración con los principales sistemas de la DGOJ (LDAP, servidor de correo, etc.).

• Módulo xx Xxxxx Site Scripting para garantizar la seguridad de las mismas y evitar este tipo de ataques.

• Generación de informes en forma PDF, Word y Excel utilizando la herramienta Xxxxxx Reports.

Tras la formalización del contrato, la DGOJ proporcionará información técnica y detallada de cada uno de los servicios y funcionalidades que proporciona la arquitectura a utilizar por el contratista.

VI.- Marco metodológico.

La adquisición y/o desarrollo de Sistemas de la Información es considerado un aspecto clave en la transición de todo organismo hacia un modelo basado en las Tecnologías de la Información. Ante ello, son múltiples las metodologías de planificación, desarrollo y mantenimiento de sistemas de información que han surgido en este contexto, y entre ellas, METRICA v3, para la sistematización de actividades del ciclo de vida de los proyectos software en el ámbito de las administraciones públicas.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

A pesar de la completitud de estas metodologías se tratan de enfoques pesados dada la cantidad de documentación a generar y por tanto difíciles de abordar correctamente. Ante esto, la DGOJ decidió establecer una metodología más ágil, con pilares basados en METRICA v3, pero que se centrará en aquellos entregables que aportaban valor tanto a la ejecución como al seguimiento del proyecto; sin olvidar el mantenimiento futuro.

En los siguientes subapartados se establecen los aspectos principales de las metodologías establecidas en la DGOJ en materia de gestión de proyectos y ejecución de los mismos. En cualquier caso, estas deberán ser establecidas como unos mínimos de forma que el contratista podrá complementarlas con aquellas actividades y/o entregables que considere oportuno. De igual forma, es importante anotar que podrían existir proyectos cuya ejecución no se adapte en su completitud a la metodología. En estos casos, se deberán exponer los motivos durante la reunión de arranque del mismo, así como una propuesta firme de fases y actividades.

Finalmente es importante anotar que la metodología hace distinción a la hora de concretar los entregables que deben ser realizados por el contratista. En concreto, se podrán distinguir entre:

• Requeridos: Serán aquellos que se deberán generar por todos los proyectos que usen esta metodología, independientemente de las características del proyecto.

• Requeridos solo si aplica: Serán aquellos que se deberán generar por los proyectos en función de las características de los mismos.

• Opcionales: Serán aquellos que se podrán generar de manera complementaria, de forma que se enriquezca el producto final. Puede darse el caso que alguno de estos entregables opcionales pase a ser requerido en base a las características especiales del proyecto.

En líneas generales, la DGOJ dispone xx xxxxxxxxxx específicas para los diferentes entregables, debiendo ser empleadas las mismas por parte del contratista. En caso de no existir una plantilla prestablecida, se empleará la plantilla genérica.

1.- Gestión de proyectos

La finalidad de esta metodología es servir de marco común a todos los proyectos en cuanto a las actividades de gestión y seguimiento de los proyectos, estableciéndose para ello una serie de fases, actividades y entregables.

FASE	CORRESPONDENCIA PMI (PROYECT MANAGEMENT INSTITUTE)	DESCRIPCIÓN
Arranque de proyecto	Inicio	Comienza con la adjudicación del proyecto al

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 45 de 75-

FASE	CORRESPONDENCIA PMI (PROYECT MANAGEMENT INSTITUTE)	DESCRIPCIÓN
		contratista. En ella se definirán las normas y aspectos logísticos a seguir en el proyecto
Planificación de proyecto	Planificación	Se acuerda la planificación del proyecto que servirá como línea base
Seguimiento y ejecución de proyecto	Ejecución	Realizar seguimiento y control del proyecto
	Seguimiento y control
Cierre de proyecto	Cierre	Formalizar el cierre del proyecto

Las actividades contempladas en estas fases están pensadas para su realización desde las instalaciones de la DGOJ, por lo que se presupone la posibilidad de acceder a todas las herramientas puestas a disposición por el órgano. En caso de realizarse el proyecto desde una instalación externa, se deberán tener en cuenta los siguientes matices:

• La herramienta de gestión del servicio se sustituirá por la emisión de correos electrónicos.

• La herramienta de gestión de proyectos se sustituirá por Microsoft Project.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Finalmente se muestran los entregables contemplados dentro de la metodología:

		DESARROLLO		INFRAESTRUCTURA
METODOLOGÍA	ENTREGABLE	Interacción	WebServices		APLICABILIDAD
GESTIÓN	Acta de reunión de Arranque	Requerido
	Ficha de Proyecto	Requerido
	Planificación	Requerido
	Listado de Riesgos	Requerido
	Informe seguimiento	Requerido
	Informe de facturación	Requerido
	Informe de cierre de proyecto	Requerido
	Inventario de entregables	Requerido
	Informe de ANS		Requerido		Solicitado por los responsables de la DGOJ
		(solo si aplica)
	Acta de reunión de Inicio		Requerido		Proyectos nuevos o en su defecto solicitado por los responsables de la DGOJ
		(solo si aplica)
	Presentación de Inicio Proyecto		Requerido		Proyectos nuevos o en su defecto solicitado por los responsables de la DGOJ
		(solo si aplica)
	Plan de comunicación		Requerido		Proyectos que precisen difusión del mismo
		(solo si aplica)
	Plan de formación		Requerido		Proyectos que precisen difusión del mismo
		(solo si aplica)
	Acta de reunión	Requerido

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 46 de 75-

		DESARROLLO		INFRAESTRUCTURA
METODOLOGÍA	ENTREGABLE	Interacción	WebServices		APLICABILIDAD
		(solo si aplica)			Reuniones adicionales de relevancia (que no sea de seguimiento o de arranque)
	Gestión de configuración	Opcional			Proyectos de gran envergadura (duración superior a 1 año)

2.- Ejecución de proyectos

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

La metodología de ejecución de proyectos está concebida para dar respuesta a la mayoría de los proyectos desarrollados en la DGOJ, donde se tenga como objeto la definición, implementación y/o mantenimiento de un Sistema de Información.

FASE	DESCRIPCIÓN
Requisitos	Fase en la que se marcarán los objetivos y se definirán los requisitos a satisfacer por el sistema
Análisis	Fase en la que se concebirán los modelos marcados por los requisitos de forma que se permita su posterior diseño y construcción del software. En el caso de adquisición de productos, hará foco en el análisis de las funcionalidades proporcionadas, cuales requieren adecuarse a los requisitos de la DGOJ, y si son necesarias adaptaciones y/o elaboración de desarrollos específicos
Diseño	Fase en la que se definirán técnicamente los componentes del sistema de cara a su construcción y/o instalación (en caso de una solución adquirida)
Construcción	Fase en la que se implementarán/parametrizarán los componentes del sistema de la información en base al diseño previo
Pruebas	Fase en la que se realizarán distintas baterías de pruebas que garanticen la calidad del sistema y en la que se realizarán distintos manuales de apoyo al usuario
Implantación	Fase en la que se implantará el sistema de la información y en la que se formalizará la aceptación del mismo

Finalmente se muestran los entregables contemplados dentro de la metodología:

		DESARROLLO		INFRAESTRUCTURA
METODOLOGÍA	ENTREGABLE	Interacción Usuario	WebServices		APLICABILIDAD
EJECUCIÓN	01. Requisitos	Listado de Requisitos	Requerido	A
		Matriz de trazabilidad	Requerido	A
		Estrategia de convivencia	Requerido (solo si aplica)		Proyectos que requieran convivencia con otro ya existente

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 47 de 75-

			DESARROLLO		INFRAESTRUCTURA
METODOLOGÍA		ENTREGABLE	Interacción Usuario	WebServices		APLICABILIDAD
		Estrategia de implantación	Requerido (solo si aplica)			Proyectos donde se concrete llevar un control estricto en la implantación, debido a la criticidad del sistema.
		Estrategia de pruebas	Opcional			Proyectos que requieran un alto volumen de pruebas y/o elevada complejidad
	02. Análisis	Análisis Funcional	Requerido		A
		Plan de pruebas funcionales*	Requerido
		Estrategia de migración	Requerido (solo si aplica)			Proyectos que requieran una migración de datos
		Modelo de datos lógico	Requerido (solo si aplica)			Proyectos que requieran un modelo de datos
		Prototipo	Opcional			Proyectos donde interese ver el aspecto visual, previo a su implementación.
	03. Diseño	Diseño Técnico	Requerido		A
		Diseño Interfaces Usuario	R		A
		Diseño Interfaz Servicio Web		R
		Diseño de arquitectura	Requerido		A
		Diseño Técnico de migración	Requerido (solo si aplica)			Proyectos que requieran una migración de datos
		Modelo de datos físico	Requerido (solo si aplica)			Proyectos que requieran un modelo de datos
		Plan de pruebas de carga / rendimiento	Requerido (solo si aplica)			Proyectos que vayan a tener una carga alta de uso o una importante criticidad.
		Plan de pruebas de integración*	Requerido (solo si aplica)			Proyectos que requieran una integración compleja con otros sistemas, y/o múltiples integraciones.
	04. Construcción	Código Fuente	Requerido
		Instalable / Módulos / Plugins / Librerías			R
		Plan de pruebas de aceptación	Requerido (solo si aplica)			Proyectos que vayan a requerir de una validación del usuario

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 48 de 75-

			DESARROLLO		INFRAESTRUCTURA
METODOLOGÍA		ENTREGABLE	Interacción Usuario	WebServices		APLICABILIDAD
	05. Pruebas	Informe de pruebas funcionales*	Requerido
		Manual de Explotación	Requerido
		Manual de Implantación	Requerido
		Manual de Implantación de Procesos Automáticos	Requerido (solo si aplica)			Proyectos que vayan a requerir la automatización de procesos.
		Informe de pruebas de aceptación	Requerido (solo si aplica)			Proyectos que vayan a requerir de una validación del usuario
		Informe de pruebas de carga /rendimiento	Requerido (solo si aplica)			Proyectos que vayan a tener una carga alta de uso o una importante criticidad.
		Informe de pruebas integración	Requerido (solo si aplica)			Proyectos que requieran una integración compleja con otros sistemas, y/o múltiples integraciones.
		Manual de usuario	A		A	Proyectos en los que el sistema proporcione una interfaz de usuario.
		Auditoria Seguridad	Requerido (solo si aplica)			Proyectos donde aplique la realización de una auditoría de seguridad
	06. Implantación	Acta de aceptación del sistema	Requerido
		Material de formación	A		A	Proyectos en los que se considere necesario este tipo de material.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

* Los documentos relacionados con las pruebas se entregan a través de la herramienta Testlink, siempre y cuando no se acuerde utilizar la plantilla del entregable en formato Excel.

3.- Validación del servicio

3.1.- Validación de la calidad de documentación

El procedimiento de validación de la calidad de documentación, llevado a cabo por la Oficina de Gestión de Proyectos (PMO) de la DGOJ, parte de un número de entregables mínimos obligatorios por tipología de proyecto a los que se le puede o no sumar los entregables considerados como no obligatorios según la metodología de la DGOJ. Dicha suma de entregables se acuerda durante la reunión de arranque del proyecto.

Una vez que se solicita la validación de documentación se evalúan ítems como el uso adecuado de las plantillas de la casa, la trazabilidad entre los documentos implicados en las distintas fases del desarrollo, etc.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 49 de 75-

En caso de incumplimiento de los ítems, la PMO reportará las incidencias a través de la herramienta Redmine. El detalle de la criticidad, priorización de las incidencias reportadas se puede ver en el documento normativo:

NOR.PMO.Gestión_de_la_Calidad_Documental

3.2.- Validación de la calidad funcional

El procedimiento de validación funcional comienza con el análisis de la documentación de la aplicación a probar entregada al equipo de Calidad. Con dicha documentación se genera el plan de pruebas y posteriormente los casos de prueba definidos son almacenados en la herramienta Testlink (repositorio de casos de prueba). Según la relevancia que se le dé a alguna de las funcionalidades de la aplicación a probar se puede automatizar la ejecución de dicho plan con las herramientas, librerías empleadas para tal efecto, como por ejemplo Selenium o JUnit.

Ya sea la ejecución de casos de prueba manual o automática la valoración de los resultados obtenidos de la ejecución de pruebas funcionales se realiza acorde a una serie de métricas prestablecidas en cuanto a criticidad de la incidencia detectada, resumidas del siguiente modo:

• Bloqueante, cuando:

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

⮚ No es posible realizar la instalación/despliegue de la aplicación o esta es inestable.

⮚ Afecta a módulos funcionales básicos para el funcionamiento del sistema (no es posible realizar el despliegue de la aplicación sin ellos).

⮚ Impiden la normal ejecución de las pruebas, independientemente de la tipología de las mismas.

⮚ Ejemplos:

▪ Despliegue de componentes sin cargar las librerías/esquemas correctos originan múltiples incidencias antes no existentes.

▪ Problemas en el despliegue por falta de componentes.

• Alta, para aquellos casos de prueba que:

⮚ Impidan la ejecución de los casos de prueba mínimos para comprobar los aspectos funcionales de la aplicación en pruebas.

⮚ Afecte gravemente a la utilización del sistema al conllevar una pérdida de una o varias funcionalidades.

⮚ Demuestren la falta de implementación de uno o varios requisitos definidos.

⮚ Ejemplos:

▪ Incapacidad de continuar con la ejecución de las pruebas por el incremento exponencial de las incidencias altas o por la falta de control de los errores lanzados por la aplicación.

▪ Fallo en la gestión de información válida por parte de la aplicación (errores en la validación de la información introducida por parte del usuario).

▪ La incoherencia entre los flujos definidos en la documentación (p.ej. fichas de trámite) y la implementación de real de la aplicación.

Nota: El sistema NO debería ser desplegado con defectos de impacto ALTO sin solucionar, salvo autorización expresa del jefe de proyecto por parte de la DGOJ.

• Media, cuando:

⮚ La incidencia bloquea la ejecución de los casos de prueba de segundo nivel definidos.

⮚ Xxxx defectos que, aunque implican una pérdida de funcionalidad o de operatividad, pueden sortearse mediante el uso de otra función del sistema.

⮚ La gestión de los errores por parte de la aplicación sea inapropiada y/o se muestren mensajes de error incorrectos.

⮚ Ejemplos:

▪ Error en la validación de un campo no obligatorio de un formulario.

▪ Uso de valores erróneos para campos preconfigurados (por ejemplo, listado de valores mostrados en un combo).

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 50 de 75-

▪ Comportamientos no esperados del usuario en el uso de la aplicación.

• Baja, para los casos en los que:

⮚ No se bloquea la ejecución de los casos de prueba pero se obtienen resultados diferentes a los previstos.

⮚ Se trate de defectos que no afectan al funcionamiento normal del sistema, aunque la reiteración de los fallos producidos por el defecto dificulta la operación del sistema por los usuarios.

⮚ Ejemplos:

▪ Uso frecuente de la funcionalidad en que se manifiesta el error.

▪ Incoherencia en los campos solicitados al usuario como obligatorios y los requeridos realmente por la aplicación.

• Mejora, para:

⮚ Todos los puntos de mejora de la usabilidad identificados por el equipo de Calidad o por el usuario final de la aplicación.

⮚ Propuestas de modificación del formato de los componentes para simplificar la visualización de los mismos.

⮚ Ejemplos:

▪ Modificar el color de un texto para facilitar la lectura del mismo.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

▪ Propuesta para modificar el espacio ocupado por un botón para mejorar la usabilidad de la aplicación tomando como referencia las buenas prácticas definidas en este aspecto.

En caso de reportar incidencias se gestionan a través de la herramienta Redmine.

Como último paso el equipo responsable de la valoración de calidad funcional emite de a través de la herramienta Testlink el informe con los resultados obtenidos.

3.3.- Validación de la calidad de software

La Oficina de Certificación de Aplicaciones (en adelante OCA) garantizará previamente al pase a producción de una aplicación, que cumple con los requisitos mínimos estipulados para su pase al entorno productivo con un mínimo de calidad en código aceptable.

La OCA emitirá un informe con el resultado de las métricas del análisis estático del código fuente a los responsables de la DGOJ previamente al pase a producción basándose en la herramienta Sonar.

A continuación, se definen los criterios mínimos necesarios de obligado cumplimiento por parte de las aplicaciones para el pase al entorno productivo:

• Se considerará saludable cuando cumpla todos los umbrales de calidad medidos en el apartado VIII.3.1 del presente anexo (todas las métricas en estado), con la salvedad del umbral de pruebas unitarias, que se

permitirá que esté aceptable (es decir el valor de la métrica debe ser superior al 10%, en estado ), pero todas las pruebas deben tener un resultado satisfactorio.

• Se considerará aceptable cuando todos los umbrales de calidad medidos en el apartado VIII.3.1 del presente anexo estén en estado saludable o aceptable (todas las métricas en estado o), es decir, ninguna métrica

podrá tener problemas de calidad (en el estado ). No obstante, sería aconsejable revisar dichas métricas para el próximo pase al entorno productivo.

• En caso contrario, cuando alguno de los umbrales de calidad medidos en el apartado VIII.3.1 del presente anexo esté en estado enfermo (en el estado ), se desaconsejará el pase a producción por el incumplimiento de las métricas de calidad.

En todos los casos, el responsable del proyecto deberá autorizar el pase a producción, siendo consciente del grado de cumplimiento o incumplimiento de las métricas de calidad establecidas. La Oficina de Certificación de Aplicaciones desaconsejará el pase a producción, y por tanto la finalización del desarrollo de la aplicación, si está en estado enfermo

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 51 de 75-

( ).

Para mayor detalle consultar el documento normativo proporcionado por la DGOJ. NOR.PMO.Gestion_de_la_Calidad_de_Codigo_Fuente

VII.- Cumplimiento normativo.

Las Tecnologías de la Información y la Comunicación (en adelante TIC) se han convertido hoy por hoy en un mecanismo esencial a la hora de alcanzar los objetivos de la DGOJ, suponiendo a su vez, beneficios importantes en cuanto a la eficacia y eficiencia del mismo.

Ahora bien, al existir está clara dependencia, los sistemas TIC se convierten en elementos estratégicos para la Dirección General. Elementos que deben ser administrados con diligencia, tomando las medidas adecuadas para protegerlos frente a daños accidentales o deliberados que puedan afectar a la disponibilidad, integridad o confidencialidad de la información tratada o los servicios prestados.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

A su vez, no debemos olvidar un conjunto de normativas que han surgido durante los últimos años con objeto de proteger los activos de información, así como los servicios de los diferentes organismos estatales, y entre las que se encuentran:

• Real Decreto 3/2010, de 8 de enero, por el que se regula el Esquema Nacional de Seguridad en el ámbito de la Administración Electrónica, modificado el 4 de noviembre de 2015.

• Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales.

• Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal, modificado el 8 xx xxxxx de 2012.

• Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica.

Por todo ello, la estrategia de la DGOJ pasa por abordar la seguridad de forma integrada en todos los procesos y cualquiera de los ámbitos (infraestructura, aplicaciones, procedimentales, organizativos, etc.). En este punto, entrarán en juego los propios contratistas que presten servicio a la DGOJ en el desarrollo, construcción y mantenimiento de sistemas debiendo:

• Velar por el cumplimiento de las normativas previamente indicadas dentro del contexto que le corresponda (ej.: emplear criptografía cuando así sea requerido para proteger la información de base de datos).

• Aceptar y respetar las políticas, normativas y procedimientos de seguridad internas de la DGOJ que velan por la protección de la información y los servicios.

VIII.- Herramientas.

Los xxxxxx tecnológico y procedimental se apoyan sobre un conjunto estandarizado de herramientas, que son proporcionadas a los diferentes contratistas de servicio durante la gestión y ejecución de los proyectos.

En la reunión de arranque del proyecto se establecerán las necesidades reales de las mismas, y en líneas generales, se tratarán de soluciones preparadas para su utilización al ser parametrizadas y administradas por la propia DGOJ.

1.- Gestión de proyectos

El seguimiento y control de los proyectos por parte de la DGOJ se realiza desde tres perspectivas:

• Portfolio de proyecto, donde se recoge una visión general del avance de los proyectos en su conjunto.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 52 de 75-

• Visión de proyecto, relacionada con el seguimiento propio de las actividades e hitos de un proyecto concreto.

Con objeto de dar respuesta a estas tres visiones, la DGOJ ha establecido en el órgano las herramientas Microsoft Project y Redmine, las cuales deberán ser empleadas regularmente por el equipo del contratista para:

• Registrar las fases/actividades que se realizarán en el proyecto, así como el coste en horas estimado (Project y Redmine).

• Planificación de las actividades en el tiempo y por recurso (diagrama XXXXX en Project).

• Notificación de las horas incurridas por parte del equipo del contratista (Redmine).

Tras la formalización del contrato, la DGOJ facilitará una plantilla de Microsoft Project con las fases estándar que se marcan en la metodología para la elaboración de la planificación y configurará la herramienta Redmine, de forma que los recursos humanos que integren el equipo de trabajo puedan hacer uso de un área de trabajo asociada a los proyectos que se derivan del presente PPT.

Opcionalmente, los contratistas podrán emplear toda aquella herramienta adicional de control y seguimiento del proyecto. Por ejemplo, los Jefes de Proyecto podrían llevar el seguimiento de actividades en detalle en herramientas tradicionales de gestión de proyectos, garantizando siempre que actualizan, con carácter semanal, las herramientas corporativas de la DGOJ.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Microsoft Project

Herramienta de gestión de proyectos y planificación. Redmine

Herramienta de ticketing y reporte de horas de los trabajos realizados en el ámbito de desarrollo.

TIPO PETICIÓN	DESCRIPCIÓN
Gestión	Asociado a servicios de organización y gestión del servicio, agrupa las diferentes actividades necesarias para asegurar que la ejecución de los servicios se ajusta al modelo de la DGOJ, adoptando sus estándares, con los niveles de calidad requeridos y ayudando a su consolidación y evolución
Soporte	Asociado al servicio de soporte al usuario, técnico o no, son peticiones no planificables para la revisión / consulta / adecuación de la información de la aplicación orientadas tanto al CAU como a otros contratistas de la Dirección General. Por ejemplo: revisar el estado de un expediente que está en estado inconsistente por parte del equipo técnico responsable del sistema, o atención del CAU a un usuario al objeto de resolver una consulta
Evolutivo	Mantenimiento correctivo, concebido como extensión, ampliación y/o mejora de funcionalidad sobre el sistema de información para satisfacer las necesidades cambiantes de la DGOJ. Este mantenimiento cubre situaciones que no se pueden prever en los estadios iniciales del proyecto y que surgen cuando se comienza a utilizar el sistema y se analiza su desempeño diario para recoger mejoras y nuevas funcionalidades. Está asociado a mantenimiento adaptativo, perfectivo, preventivo y correctivo, cuando este último es de suficiente índole como para considerarse un servicio planificable
Correctivo	Propias del servicio de mantenimiento correctivo. Son peticiones para la gestión de incidencias en las aplicaciones propias del servicio de mantenimiento correctivo. Funcionalidad para la que no se obtiene el resultado esperado
Nuevos desarrollos	Concebido como el desarrollo de nuevas funcionalidades que pueden dar lugar a una nueva versión de los sistemas, o incluso, a la generación de un nuevo aplicativo dentro del ámbito funcional objeto de este contrato
Análisis y estudio	Asociado a servicios de análisis, estudio y documentación, concebida como

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 53 de 75-

TIPO PETICIÓN	DESCRIPCIÓN
	actividades de estudio previo y/o análisis de situaciones de negocio/mercado para la confección de un documento de solución detallado, que sirva a la DGOJ como elemento para la toma de decisión previa al posible planteamiento de un futuro proyecto de desarrollo o de un futuro automatismo de publicación de contenidos, o lo que es más importante, que permita al equipo de desarrollo estimar el encargo de trabajo (ET) en base a dicho análisis. La confección de estudios y documentación asociada a servicios de consultoría se engloban en este tipo de peticiones de trabajo
Calidad	Petición relacionada con el servicio planificable de validación de la calidad de los productos entregados, ya sea a nivel de calidad de la documentación, como calidad del código o calidad de la funcionalidad requerida. El equipo de trabajo responsable del servicio deberá validar el cumplimiento de la metodología de la DGOJ en cuanto a los niveles mínimos de calidad del producto asociado a la petición

2.- Ejecución de proyectos

En el contexto del desarrollo y construcción de aplicaciones, la DGOJ pone a disposición de los contratistas un conjunto de herramientas / soluciones pre-configuradas. En caso de proyectos de carácter evolutivo / mantenimiento, se reutilizarán las instancias / configuraciones ya existentes de las aplicaciones.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Eclipse

Se trata del entorno de desarrollo escogido por la DGOJ para el desarrollo y construcción de sistemas de información basados en J2EE. En concreto se emplea una versión personalizada de eclipse Juno donde se han incorporado los plugins y configuración requerida para trabajar con la arquitectura de desarrollo de la DGOJ.

Maven 3.x

Herramienta de software libre para la gestión y construcción de proyectos Java a partir de un fichero pom.xml que describe la forma de construir el proyecto. El motor permite descargar las dependencias del proyecto de un repositorio centralizado, así como publicar el artefacto construido en el propio repositorio, poniéndolo disponible para cualquier proyecto maven con acceso al repositorio.

Nexus

Esta solución mantendrá el repositorio de artefactos de la DGOJ, y por tanto, las versiones estandarizadas y aceptables de las librerías que pueden ser empleadas durante la construcción de los sistemas. En líneas generales, su existencia será transparente para el equipo de desarrollo ya que su administración es realizada por parte de la DGOJ.

Subversión

Se corresponde con la herramienta empleada en la DGOJ para el versionado del código fuentes de las distintas aplicaciones propiedad del órgano.

Testlink

Se corresponde con la herramienta empleada por la DGOJ para la centralización de casos de prueba y el reporte de ejecuciones por parte de los equipos desarrolladores. Con dicha herramienta se busca mejorar la trazabilidad y seguimiento de las labores realizadas durante el desarrollo en cuanto a planificación, diseño y ejecución de pruebas.

Xxxxxxx

Se trata de la herramienta encargada de realizar aquellas actividades de integración continua que sean requeridas durante la construcción del sistema. Por cada aplicación, la DGOJ establece un contexto de trabajo que será

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 54 de 75-

posteriormente gestionado por el equipo de trabajo. Entre sus configuraciones mínimas se encontrarán:

• Compilación del código fuente liberado en subversión.

• Ejecución de las pruebas de calidad, lanzando para ello la herramienta SONAR.

3.- Validación del servicio

3.1.- Control de la calidad del software

Sonar

Se corresponde con la herramienta empleada por la DGOJ para garantizar que la construcción de los sistemas se realiza acorde a las buenas prácticas y por tanto se facilitan los futuros mantenimientos.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

La valoración de los resultados obtenidos se realiza acorde a una serie de métricas pre-establecidas, que a grandes rasgos pueden resumirse del siguiente modo:

MÉTRICA APLICABLE	MÉTRICAS (PORCENTAJE)	UMBRAL PROYECTO SALUDABLE	UMBRAL PROYECTO ACEPTABLE (CON ALERTAS)	UMBRAL PROYECTO ENFERMO
Normas de codificación	Cumplimiento de reglas de codificación	Menor 80% 🡪	Menor 80% 🡪	Menor 70% 🡪
	Evidencias bloqueantes	Igual 0% 🡪		Mayor 0% 🡪
	Evidencias críticas	Igual 0% 🡪		Mayor 0% 🡪
Documentación del código	Documentación del código	Mayor 70% 🡪	Menor 70% 🡪	Menor 50% 🡪
Duplicidad del código	Líneas de código duplicadas	Menor 5% 🡪	Mayor 5% 🡪	Mayor 15% 🡪
Pruebas unitarias	Cobertura pruebas Junit	Mayor 50% 🡪	Menor 50% 🡪	Menor 10% 🡪
	Éxito de las pruebas unitarias Junit	Igual 100% 🡪	Menor 100% 🡪	Menor 75% 🡪
Complejidad código fuente	Complejidad por clase	Menor 50% 🡪	Mayor 50% 🡪	Mayor 75% 🡪
	Complejidad por método	Menor 8% 🡪	Mayor 8% 🡪	Mayor 10% 🡪
	Ciclos entre paquetes	Igual 0% 🡪	Mayor 0% 🡪

En líneas generales se mantendrán las reglas proporcionadas por las diferentes herramientas que integran la solución (CheckStyle, PMD, FindBug, etc.), entregándose el detalle concreto de aplicación una vez formalizado el contrato.

3.2.- Control de documentación

Ante la necesidad de disponer de un repositorio estructurado de documentación del proyecto, la DGOJ proporcionará al adjudicatario acceso a una carpeta de red dedicada, junto a un repositorio común de documentación del proyecto (SVN), donde deberá almacenar toda la documentación que se genere en el ámbito del proyecto, al objeto de gestionar el conocimiento generado y facilitar la labor de fiscalización por parte de la administración.

Adicionalmente, para aquellos proyectos donde se requiera o desee de un entorno colaborativo, la DGOJ pondrá a disposición de los interesados una solución wiki basada en el producto Alfresco.

3.3.- Control de calidad funcional

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 55 de 75-

Con el objetivo de garantizar la calidad de las aplicaciones, desde un punto de vista funcional, y por consiguiente, reducir el número de incidencias que pudieran surgir en el entorno productivo, la DGOJ dispone las siguientes herramientas:

• Selenium y Junit

Se corresponden con las herramientas empleadas por la DGOJ para el desarrollo de pruebas automáticas.

• Testlink

Se corresponde con la herramienta empleada por la DGOJ para la centralización de casos de prueba y el reporte de ejecuciones. Con dicha herramienta se busca mejorar la trazabilidad y seguimiento de las labores realizadas durante el desarrollo en cuanto a planificación, diseño y ejecución de pruebas.

3.4.- Soporte del servicio

Se considerarán herramientas de “Soporte al servicio” a las soluciones puestas a disposición por la DGOJ para la gestión y demanda de servicios de TIC ofrecidos por el Área de Informática.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

En concreto, la DGOJ dispone de la solución abierta GLPI donde se centralizarán todas las peticiones de servicios requeridas por los usuarios finales, es decir, usuarios internos de la DGOJ y/o proveedores; así como las incidencias que pudieran ir surgiendo en los distintos sistemas de información.

A continuación, se exponen algunos ejemplos típicos de solicitudes que se realizan a través de la misma:

• Solicitud de una nueva cuenta de usuario.

• Petición de un pase a producción. Problemas con el ordenador personal.

• Solicitud de un cambio en la configuración del servidor Apache.

• Incidencia detectada por un usuario final durante el empleo de una aplicación.

Los perfiles profesionales del equipo de trabajo del contratista de servicios actuarán como usuarios finales en la herramienta, es decir, como solicitantes de peticiones y/o notificadores de incidencias relacionados con los servicios TIC ofrecidos por el Área de Informática a otras áreas/departamentos de la DGOJ.

En caso de tratarse de solicitudes que incluyan actividades de mantenimiento y/o evolutivos emitidas por los usuarios internos, el equipo de soporte al usuario (CAU) de la DGOJ, se encargará de velar su resolución gestionando dichas solicitudes haciendo de intermediario entre el usuario final y los distintos contratistas de servicios de mantenimiento de las aplicaciones de la DGOJ.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 56 de 75-

ANEXO II DESCRIPCIÓN DEL TRAMITADOR

I.- Conceptos básicos de tramitación electrónica.

El Tramitador de la DGOJ es un sistema de información que permite la gestión electrónica de un proceso de tramitación administrativa. Está formado por varias aplicaciones con diferente alcance funcional, pero construidas bajo un mismo marco de referencia, lo que les da un aspecto común a nivel de presentación.

Cada una de las aplicaciones que constituyen el tramitador, está especializada en un aspecto concreto del proceso de tramitación, así existirá una aplicación que facilitará a los interesados la presentación de solicitudes, otra que permitirá a los gestores realizar la tramitación propiamente dicha y una última que facilitará la integración de otras aplicaciones con las funcionalidades de tramitación.

A continuación se detallará cada uno de los conceptos básicos manejados por este sistema de información.

1.- Trámite

Un trámite o un procedimiento es la secuencia de actos administrativos necesaria para generar una resolución.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Desde el punto de vista de la tramitación electrónica, un procedimiento o trámite es una secuencia de fases que determinan los estados en que se pueden encontrar los expedientes que se tramitan.

Un procedimiento se caracteriza, por tanto, por llevar asociado un “workflow” o flujo de trabajo en el que se especifican las fases del procedimiento y las posibles transiciones entre estados dentro de cada fase. Una secuencia de fases típica sería la siguiente:

Presentación de

solicitudes

Tramitación de

solicitudes

Resolución

La transición entre fases dentro de un trámite viene marcada por fechas. Habrá un plazo para la presentación de solicitudes, otro para la tramitación de las mismas y otro para la generación de resoluciones.

2.- Interesado

Se denomina interesado a aquella persona física o jurídica que inicia un procedimiento. En los procedimientos gestionados por el tramitador, el interesado siempre será aquel usuario registrado en la aplicación que inicia el procedimiento mediante la creación de una solicitud.

La aplicación distingue dos tipos de usuarios registrados:

• Usuarios internos: son usuarios registrados en la red de la DGOJ y cuyo login o credencial de acceso al sistema será su usuario de red.

• Usuarios externos: son usuarios no registrados en el directorio de la DGOJ y cuya credencial de acceso es el documento identificativo que especificaron en el proceso de registro en la sede electrónica.

El interesado, como ya se indicó, es la persona que inicia una solicitud, y será a él, o a su representante en caso de que lo hubiera designado, a quien se le dirijan todas las comunicaciones generadas durante el proceso de tramitación. El tramitador también da la posibilidad de crear solicitudes por parte de los gestores del trámite, ya sea para trámites de carácter interno, o, de forma no tan habitual, en nombre de un interesado externo.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 57 de 75-

3.- Expediente

El expediente es el conjunto de documentos asociados a la solicitud que un interesado crea dentro de un procedimiento, o a la iniciada por parte de la administración. Los documentos que conforman un expediente pueden haber sido generados por la administración o haber sido aportados por el propio interesado.

En el caso del expediente electrónico, la Ley 11/2007, de 22 xx xxxxx, de acceso electrónico de los ciudadanos a los Servicios Públicos, lo define como el conjunto de documentos electrónicos correspondientes a un procedimiento administrativo, cualquiera que sea el tipo de información que contengan.

Aunque la solicitud de un ciudadano es un documento que forma parte de su expediente, por cuestiones de sencillez y, dado que la aplicación solo gestionará procedimientos iniciados a solicitud del interesado, el concepto de solicitud y el de expediente se utilizan dentro del tramitador como sinónimos.

4.- Flujo

Se denomina flujo o workflow al conjunto de pasos que componen un procedimiento administrativo.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

El flujo, por tanto, es el “esqueleto” del procedimiento y será una de las partes más importantes a definir en la creación

de nuevos procedimientos electrónicos.

En la definición de un nuevo flujo hay que especificar las fases del procedimiento, los estados de los expedientes en cada fase, las posibles transiciones entre estados, las acciones que permiten pasar de un estado a otro, los perfiles que pueden ejecutar dichas acciones y sobre qué formularios del expediente se ejecutan estas acciones (muchos de estos conceptos son explicados en apartados posteriores).

2

Borrador gestor/ Borrador

4 Registrada/ Registrada

Asignar exclusión

Modificar exclusión

Nueva solicitud

Confirmar y registrar

13

En exclusión/ En revision

Asignar exclusión administrativa

16

Terminar Exclusión

exclusión terminada/

En revisión administrativa

Exlcluir 25

Excluida no subsanable/ Excluida no subsanable

1 2

No existe Borrador/

Nueva solicitud Borrador

Registrar

Admitir

Subsanar

Eliminar

Confirmar

8 Registrada gestor/ Registrada

Registrar gestor

Admitir

3

Confirmada/ Confirmada

24

Excluida subsanable/ Excluida subsanable

Presentación

11

eliminada

23

Admitida/ Admitida

Subsanar gestor

ConfirmarRyeraeligziasrtrsaur bsanación

Resolución

Confirmar

17

En fase de resolución/ En fase de resolución

Terminar resolución

18

Resolución terminada/ En fase de resolución

Modificar Resolución

Asignar resolución

21

En subsanación/ En subsanación

26

Subsanando por gestor/ Subsanando por gestor

Tramitación

Comunicar resolución

10

Resuelta/ Resuelta

Figura 1. El gráfico muestra un flujo de ejemplo para un trámite con 3 fases diferenciadas: presentación, tramitación y resolución

En el gráfico se muestran las fases, los estados de los expedientes y las acciones que desencadenan los cambios de

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 58 de 75-

estado.

Se permite la creación de nuevos flujos a través de la interacción directa con la base de datos, definiendo los estados que uno desee y las transiciones entre ellos, o bien mediante la utilización de una herramienta de definición de flujos de tramitación denominada DEVIF.

5.- Estado de un trámite

El estado de un trámite hace referencia a la situación de un procedimiento de cara a su tramitación. Un trámite puede estar en tres estados distintos:

• Preparación: el trámite se está creando y configurando y por tanto no es accesible por los interesados.

• Abierto: el procedimiento se encuentra en alguna de las fases de su tramitación y es visible por los interesados que, en función de la fase concreta en la que se encuentre dicho procedimiento, podrán interactuar en él o no.

• Cerrado: la tramitación del procedimiento concluyó y por tanto no es posible ninguna interacción por parte del usuario aunque sí podrá consultar toda la tramitación de sus expedientes o solicitudes en dicho trámite.

6.- Fase

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Una fase es un conjunto de acciones aplicables sobre un expediente electrónico en función del estado del mismo.

Las fases de un trámite vienen determinadas por el flujo que se definió para el trámite y siempre están delimitadas por fechas.

Todo flujo de un trámite tendrá al menos tres fases:

• La primera será la de “Preparación”, la cual es utilizada por el gestor que configura el flujo para realizar las pruebas pertinentes sin que el trámite sea accesible por los interesados.

• La última de todas será la fase de “Cierre” en la cual el trámite queda inactivo.

• Entre estas dos fases comentadas existirán las fases propias de la tramitación electrónica. En el caso de procedimientos en los que haya fases colectivas delimitadas por fechas, como puede ser una presentación colectiva de solicitudes o una subsanación colectiva, deberá existir más de una fase. Si la tramitación es individual para cada solicitud, como por ejemplo la tramitación de una queja o sugerencia, bastará con que exista una única fase.

7.- Estado de un expediente

El estado de un expediente es la situación administrativa en la que se encuentra y que vendrá caracterizado por las acciones que se hayan llevado a cabo sobre él. Algunos estados comunes a la mayoría de procedimientos son: “En borrador”, “Confirmado”, “Registrado”, “Excluido”, “Admitido” o “Resuelto”.

Las transiciones entre estados de un expediente se producen por la ejecución de acciones sobre él, bien por el ciudadano, desde la aplicación de presentación de solicitudes, o bien por el gestor.

El conjunto de posibles estados de un expediente para una fase y las transiciones entre estos estados están determinados por el flujo elegido para el trámite.

8.- Perfil

El perfil de un usuario del sistema es el conjunto de permisos de los que dispone para interactuar con la aplicación.

El perfil de un usuario delimita qué tareas de gestión puede realizar (gestión de trámites, gestión de solicitudes o gestión de usuarios), qué acciones puede llevar a cabo dentro de estas tareas de gestión y qué acciones puede ejecutar sobre los expedientes que gestiona.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 59 de 75-

Algunos perfiles de ejemplo son: “Administrador”, “Supervisor”, “Gestor”, “Consultor”, etc.

9.- Acción

Una acción es cualquiera de las operaciones que puede realizar un usuario, ya sea ciudadano o gestor, sobre un expediente electrónico y que generalmente conlleva un cambio del estado del expediente. Existen acciones, como por ejemplo “Ver solicitud” en las que la transición es reflexiva, es decir, partiendo de un estado se alcanza el mismo.

Las acciones se definen para un estado del expediente en una fase concreta y sobre un formulario determinado y son solo ejecutables por un determinado perfil de usuario. Al igual que las fases y las transiciones entre estados del expediente, las acciones se definen en el flujo del procedimiento.

10.- Formulario

Un formulario es un documento electrónico que forma parte de un expediente electrónico para un trámite. Todo formulario está formado por un conjunto xx xxxxxx que el interesado o el gestor del trámite deben rellenar.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Las acciones definidas en el flujo del trámite sobre el expediente se ejecutan sobre un formulario concreto, pudiendo existir de 1 a N formularios para un trámite.

La definición de formularios se hace desde dentro del tramitador, con herramientas administrativas que permiten la definición visual de los mismos, así como de dotarles de la posibilidad de incluir condiciones, validaciones y asignaciones.

11.- Área

Un área es una unidad lógica utilizada por los gestores de un determinado trámite para hacer una clasificación interna de las solicitudes.

Cada trámite tendrá configuradas una serie de áreas. Un gestor podrá tener visibilidad sobre un conjunto de ellas, pudiendo ser sobre todas y teniendo que tener visibilidad al menos sobre una.

La separación de solicitudes entre áreas se llevará a cabo por los gestores con mayor visibilidad o puede ser configurada para que se haga de forma automática en función del valor de ciertos campos de un formulario.

12.- Comunicación

Una comunicación, como su propio nombre indica, es un escrito que, por vía electrónica, se le remite al gestor o al interesado durante la tramitación de un expediente.

Las comunicaciones pueden ser elaboradas por el gestor del trámite, o bien se pueden generar de forma automática por el tramitador como respuesta a una acción ejecutada, sirviendo generalmente como recordatorio o advertencia para el gestor, o bien como mensajes de confirmación para el solicitante.

13.- Notificación

Una notificación es un documento en el que se comunica a un interesado un acto administrativo determinado. Desde el punto de vista del tramitador la notificación será un documento electrónico que entrará a formar parte del expediente electrónico del interesado.

Las notificaciones electrónicas que se envíen al interesado desde el tramitador interno podrán ser consultadas por este en la sede electrónica de la DGOJ.

14.- Subflujo

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 60 de 75-

Se trata de un concepto, incluido dentro del concepto general de flujo de tramitación, que permite hacer una clasificación adicional sobre las posibilidades de ejecución de tareas disponibles en un determinado estado del expediente para un perfil concreto.

El subflujo es un marcador empleado para definir transiciones entre estados del trámite que sólo serán accesibles a solicitudes que tienen entre su información ese marcador. Es una herramienta que permite personalizar el comportamiento de un flujo para un determinado tipo de solicitudes, evitando de este modo la creación de nuevos flujos con grandes similitudes entre sí.

II.- Gestión de solicitudes.

1.- Flujo de tramitación de una solicitud

En este apartado se muestra, como ejemplo, un flujo de trabajo con los principales estados por los que pasa un expediente o solicitud durante su tramitación electrónica.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

La mayoría de estos estados son de uso común en todos los flujos de trabajo definidos en el sistema, por lo que muy posiblemente serán utilizados durante la gestión electrónica de las solicitudes a cualquier procedimiento de la DGOJ.

12

Borrador gestor/ Borrador

13

4 Registrada/ Asignar En exclusión/

terminar exclusión

16

Exclusión terminada/ En revisión administrativa

54

25

Excluir

No subsanable

Excluida no

Confirmar y registrar

Registrada

Registrar

exclusión En revisión

administrativa

Asignar exclusión

pte notificación/ Ver notificación subsanable/

Pendiente Excluida no

notificación subsanable

Nueva solicitud

Subsanar

1

No existe

2

Borrador/ Nueva solicitud Borrador

3

Confirmar Confirmada

Confirmada/

Registrar gestor 8 Registrada

53

Subsanable pte notificación/ Pendiente notificación

Ver notificación

gestor/ Registrada

Registrar gestor

Eliminar

24

Excluida subsanable/ Excluida subsanable

Admitir

Eliminar

27

Subsanada confirmada/ Subsanada confirmada

Realizar subsanación

Admitir

Confirmar

Subsanar gestor

11

eliminada

21

En subsanación/ En subsanación

Subsanar gestor

23

Admitida/ Admitida

Confirmar y registrar

26

Subsanando por gestor/ Subsanando por gestor

Modificar Resolución

17

En fase de resolución/

En fase de Terminar 18

resolución resolución Resolución

terminada/ En fase de resolución

Comunicar resolución

19

Resolución pte notificación/ En fase de resolución

Ver notificación

10

Resuelta/ Resuelta

Figura 2: Flujo de ejemplo para la tramitación de solicitudes

2.- Presentación de la solicitud

La primera de las fases de un procedimiento es la presentación de las solicitudes por parte de los interesados. Este proceso de presentación comprende desde la creación de la solicitud hasta su presentación en un registro electrónico o presencial.

Cuando una solicitud se da de alta en el sistema pasa al estado “Borrador”, si la da de alta el propio interesado, o “Borrador gestor”, si la solicitud en soporte papel fue entregada en un registro presencial y es el propio gestor del trámite el que la da de alta tras su recepción. Mientras una solicitud está en estado borrador su creador puede modificarla e incluso eliminarla.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 61 de 75-

Cuando todos los datos de la solicitud han sido cumplimentados con éxito la solicitud debe ser confirmada. La confirmación supone el bloqueo de la solicitud de forma que ya no puede ser modificada en el futuro.

Una vez confirmada la solicitud, el siguiente paso es su registro. Este registro puede ser realizado por el propio usuario o por el gestor del trámite.

En caso de que sea el interesado el que realice el registro de su solicitud en el sistema, este proceso de registro se puede hacer de dos formas distintas:

• De forma electrónica si dispone de un certificado electrónico admitido por la DGOJ.

• De forma presencial, entregando en un registro el resumen de la solicitud que se puede generar a través de la aplicación de tramitación de la sede electrónica de la DGOJ.

Si la solicitud ha sido entregada por el interesado en un registro presencial será el gestor del trámite el que deberá registrar la solicitud electrónica introduciendo la fecha en la que se produjo el registro real.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Si el interesado entregó en el registro el resumen de la solicitud los datos de la misma están en el sistema, por lo que el gestor no deberá añadir ningún dato más a parte de la fecha real de registro. Si por el contrario los datos no están en el sistema el gestor deberá dar de alta una nueva solicitud a nombre del interesado y rellenarla con los datos de la solicitud en papel.

Es importante señalar que todas las acciones que se han señalado en la fase de presentación para su realización por los gestores pueden ser realizadas también durante la fase de revisión administrativa.

3.- Revisión administrativa

Una vez completada la presentación de solicitudes y que estas están registradas se inicia la fase de revisión administrativa de las mismas. En esta fase los gestores revisarán la totalidad de las solicitudes presentadas al procedimiento, comprobando la corrección de las mismas. Para esta actividad utilizarán principalmente las áreas de gestión que se hayan definido previamente.

Si una solicitud registrada cumple con todos los requisitos establecidos pasará a estado “Admitida”, lo que supone su paso a la fase posterior de resolución de solicitudes.

Si por el contrario tiene un error que no puede ser corregido pasará a estado “Excluida no subsanable” y, como su propio

nombre indica, quedará excluida del procedimiento notificando de ello al interesado.

Si el error de la solicitud puede ser corregido por el interesado esta pasará a estado “Excluida subsanable”. En este caso, el interesado será notificado de tal obligación y dispondrá de un periodo de tiempo para llevarla a cabo, tras el cual la solicitud solo podrá pasar a los estados “Admitida”, si la subsanación es correcta, o “Excluida no subsanable”, si la subsanación ha sido insuficiente o no se ha producido.

Como se puede ver en el gráfico de estados, la notificación al ciudadano de la posibilidad de subsanación o de la exclusión definitiva de su solicitud implica la existencia de varios estados “Excluido no subsanable” y “Excluido subsanable”, uno para cuando la notificación está pendiente de apertura y otro para cuando la notificación ha sido realizada o rechazada.

Al igual que ocurre con el formulario de solicitud, el formulario de exclusión requiere del paso del expediente por dos estados para poder completarse. Estos estados son “En exclusión”, que es análogo a “En borrador” para la fase de presentación y el formulario de solicitud, y “Exclusión terminada”, que es análogo a “Confirmada”.

4.- Fase de revisión

La fase de revisión supone el fin del procedimiento. En esta fase los gestores resuelven las solicitudes que previamente

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 62 de 75-

han sido admitidas durante la fase de revisión administrativa.

La resolución supone completar, por parte de los gestores del trámite, un formulario de resolución, tal y como se ha explicado anteriormente para el formulario de solicitud y para el de exclusión, así como notificar al interesado el resultado.

III.- Acciones.

De forma resumida, se puede detallar la configuración necesaria para la tramitación de un flujo como:

• Definición de los estados.

• Dentro de los estados las descripciones públicas y privadas de los mismos.

• Las acciones entre estados.

• Los permisos que determinan quiénes pueden realizar esas acciones.

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

Las acciones vienen definidas por una serie de características que determinan qué sucede con el expediente en cuestión cuando se ejecuta. Dichas características forman parte de la definición del flujo sobre el que se ejecuta el trámite, y son las siguientes:

FLSO_IDFLUJO	Id del flujo se calcula por la secuencia de SQ_IDFLUJO
FLSO_IDFASECONVOCATORIA	Fase de la convocatoria
FLSO_IDESTADOSOLICITUDINI	Id del estado inicial de la solicitud se calcula por la secuencia de SQ_IDESTADOSOLICITUD
FLSO_IDESTADOSOLICITUDFIN	Id del estado final de la solicitud se calcula por la secuencia de SQ_IDESTADOSOLICITUD
FLSO_ACCION	Acción que va a realizar el cambio de estado
FLSO_IDPERFIL	Id del perfil se calcula por la secuencia de SQ_IDPERFIL
FLSO_IDTEXTO	Texto de la acción, esta almacenada en la tabla de TEXTOS
FLSO_IDCOMUNICACION	Si tiene notificación se le pone el id de la notificación
FLSO_TIENEAPUNTEHISTORICO	Nos indica si hacemos un apunte en el histórico de convocatorias
FLSO_ACCIONCOLECTIVA	Si la acción se pinta como colectiva o no
FLSO_MUESTRAINDIVIDUAL	Si la acción sólo se muestra en colectiva
FLSO_BAJALOGICA	Si el registro está en baja lógica
FLSO_USUALTA	Usuario que dio de alta el registro
FLSO_FECALTA	Fecha en la que se dio de alta el registro
FLSO_USUMODIFICA	Usuario que modificó por última vez el registro
FLSO_FECMODIFICA	Fecha en la que se modificó por última vez el registro
FLSO_ORDEN	Orden con el que se muestra la acción
FLSO_ESINICIAL	Indica si el estado es inicial o no
FLSO_ESFINAL	Indica si el estado es final o no
FLSO_MUESTRAMOTIVO	Nos dice si se muestra una caja de texto con el motivo para que quede en el histórico. Los valores son: • S: muestra el motivo • N: no muestra el motivo • A: el histórico se hace antes de realizar la acción (por ejemplo, en el alta se da de alta la solicitud y luego se muestra los criterios y se hace el apunte antes de mostrar la solicitud con sus criterios)
FLSO_GUARDADCTM	Indica si la acción del flujo conlleva que la solicitud se guarde en el gestor documental
FLSO_IDMENSAJEAMOSTRAR	Indica si al terminar de realizar la acción se muestra un mensaje
FLSO_MUESTRAAPUNTEHISTORICO	Indica si el apunte del histórico será visible por el usuario
FLSO_IDFORMULARIO	Identificador del formulario, se calcula con la secuencia

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 63 de 75-

	SQ_IDFORMULARIO
FLSO_PERFILAASIGNAR	Identificador del perfil se calcula por la secuencia de SQ_IDPERFIL
FLSO_ACCIONGLOBAL	Son para las acciones que no tienen en cuenta el estado de la solicitud para poder realizarlas
FLSO_MUESTRADOCHISTORICO	Indica si muestra la documentación en el apunte del histórico
FLSO_TIENEFECPLAZO	Indica si la acción tiene fecha de plazo, posibles valores: • N: se deja como estuviera, si estaba informada en el histórico y en la solicitud se mantiene • B: se deja en blanco • M:Se pide al usuario que la introduzca de forma manual • A: pone la fecha de plazo con la del sistema
FLSO_TIENEFECREGISTRO	Indica si pide la fecha en la que se hizo el registro
FLSO_CREANOTIFICACION	Indica si se debe crear notificación, posibles valores: • 0 no tiene que crear notificación • 1 tiene que crear notificación en el panel de notificaciones • 2 por AWR completa el apunte en AWR recuperando el asiento de la tabla FORMULARIO_SOLCITUD
FLSO_ACCIONINTEGRACION	Nombre de la acción de integración. Esta acción implica un cambio de estado realizado por una aplicación externa sobre una solicitud a través de GestsolWS
FLSO_REGISTROSALIDA	Indica el comportamiento con respecto al registro de salida, posibles valores: • registroSalida = 0 ⮚ Formulario de solicitud: Se crea el resumen y se firma con estampación de CSV, si se sube al gestor documental el pdf del formulario se crea CSV, pero sin estampación el CSV ⮚ Otro Formulario: No se crea resumen y se firma con estampación de CSV el pdf formulario • registroSalida = 1: Se crea registro de salida por registro electrónico ⮚ Formulario de solicitud: No se crea el resumen y se firma con estampación de CSV el pdf formulario ⮚ Otro Formulario: No se crea resumen y se firma con estampación de CSV el formulario • registroSalida = 2:Se crea registro de salida por AWR ⮚ Formulario de solicitud: No se crea el resumen y se firma con estampación de CSV el pdf formulario ⮚ Otro Formulario: No se crea resumen y se firma con estampación de CSV el formulario • registroSalida = 3: ⮚ Formulario de solicitud: No se crea el resumen y se firma con estampación de CSV el pdf formulario ⮚ Otro Formulario: No se crea resumen y se firma con estampación de CSV el formulario
FLSO_TIPOVISUALIZACION	Está relacionado con la visibilidad de grupos, posibles valores: • Nulo indica que la acción sería visible para todos los usuarios independientemente del grupo • 1 que la acción se oculta a los grupos • 2 que la acción sólo es visible cuando se entre por grupo
FLSO_VISUALIZACIONMULTIAREA	Está relacionado con la visibilidad cuando el trámite es multiárea, posibles valores:

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 64 de 75-

	• Nulo indica que la acción sería visible para todos los usuarios independientemente del área • 1 que la acción se oculta a los usuario de las áreas secundarias • 2 que la acción sólo es visible a los usuarios de las áreas secundarias
FLSO_VALIDACRITMARCSUBSAINT	Si está a "S" mira si en el flujo existe la acción modificarSubsanacion, si existe valida que se haya incluido al menos un criterio para subsanar, si no existe esa acción no hace nada
FLSO_MUESTRACUADROMANDO	Indica si esta acción se tiene en cuenta para mostrar las solicitudes que tienen esta acción en tareas compartidas para un perfil: • N: no se tiene en cuenta para mostrar • S: Si se tiene en cuenta para mostrar
FLSO_IDSUBFLUJO	Indica a qué subflujo pertenece esta acción. El 0 es el subflujo por defecto, y siempre se mostrará

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 65 de 75-

ANEXO III

INDICADORES PARA LA EVALUACIÓN DE LA CALIDAD DEL SERVICIO

La actividad de los perfiles profesionales que componen el contrato quedará reflejada en un conjunto de métricas sobre las que se definirán criterios de calidad y acuerdos de nivel de servicio internos.

El nivel de cumplimiento de estos acuerdos será tenido en cuenta para la aplicación de las penalidades descritas en el pliego de cláusulas administrativas particulares.

Los acuerdos de nivel de servicio considerados se dividen en tres grandes categorías:

A. Calidad del proceso de gestión del servicio (organización)

B. Calidad del servicio

C. Calidad de los productos finales

A.- Indicadores de calidad del proceso de gestión del servicio (organización):

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_1: Perfiles asignados durante la ejecución

Indicador		I_1 Perfiles asignados durante la ejecución
Responsables indicador	del	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado servicio/s	al	• Servicio de organización y gestión del servicio
Objetivo indicador	del	Garantizar el cumplimiento de los requisitos de los perfiles profesionales durante la ejecución del contrato
Descripción indicador	del	Indicador para la comprobación de que los requisitos de los perfiles profesionales adscritos a la ejecución del contrato son, como mínimo, iguales a los requisitos exigidos en el Anexo XI xxx Xxxxxx de Cláusulas Administrativas Particulares en cuanto a experiencia y formación para cada uno de los productos o materias requeridos.
Niveles de servicio		Experiencia de los perfiles profesionales adscritos a la ejecución del contrato ≥ Experiencia de los perfiles profesionales requeridos
Métrica		Cuadros de experiencia mínima exigida en los últimos 48 meses a los perfiles profesionales de cada lote para cada producto y materia requerido (Anexo XI del PCAP)
Periodicidad análisis	de	Cuando se produzca algún cambio en los perfiles profesionales adscritos a la ejecución del contrato
Fuente de información de los datos
Datos			Sistema de información	Alimentación
Documentación aportada por el adjudicatario según la cláusula X.2.2.5 xxx xxxxxx de cláusulas administrativas particulares			Equipo prestador del servicio	Manual

I_2: Tiempo de entrega de informes de seguimiento

Indicador I_2 Tiempo entrega de informes de seguimiento

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 66 de 75-

Responsables indicador	del	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado servicio/s	al	• Servicio de organización y gestión del servicio
Objetivo indicador	del	Garantizar la adecuada gestión de los informes de seguimiento y las planificaciones, de forma que la tramitación de las mismas se realice de forma ágil y correcta en el menor tiempo posible, ajustándose siempre a los procedimientos definidos por la DGOJ
Descripción indicador	del	Tiempo entrega informes de seguimiento del servicio
Niveles de servicio		≤ 2º días laborales tras el plazo de entrega periódico estimado por la DGOJ
Métrica		Fecha de entrega periódica de los documentos de seguimiento establecidos en el ANEXO I
Periodicidad mínima de análisis		Quincenal
Fuente de información de los datos
Datos			Sistema de información	Alimentación
Fecha de entrega del informe			Equipo prestador del servicio	Manual

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

B.- Indicadores de calidad del servicio:

I_3: Cumplimiento de plazos de entrega de encargos de trabajo planificados

Indicador	I_3 Cumplimiento de plazos de entrega de ET planificados
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicios de mantenimiento evolutivo • Servicio de mantenimiento correctivo • Servicio de nuevos desarrollos • Servicio de análisis, estudio y documentación • Servicio de validación de la calidad
Objetivo del indicador	Conseguir que se cumplen los plazos de los hitos y entregables previstos en las planificaciones aprobadas para cada encargo de trabajo (ET)
Descripción del indicador	Indicador para la detección de desviaciones en la consecución de los plazos de los hitos y entregables previstos en las planificaciones. Las planificaciones estarán aprobadas por la DGOJ acorde a la cláusula IV.3 (Modelo de gestión: Supervisión, control y seguimiento de la ejecución) del presente pliego
Niveles de servicio	Se requiere cumplir la planificación de los hitos y entregables y la eventual desviación sea ≤ 25%
Métrica	𝑁ú𝑚𝑒𝑟𝑜 𝑑í𝑎𝑠 𝑟𝑒𝑎𝑙𝑒𝑠 ( − 1) ∗ 100 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑑í𝑎𝑠 𝑝𝑙𝑎𝑛𝑖𝑓𝑖𝑐𝑎𝑑𝑜𝑠 Nº Días Reales: Días que han sido necesarios para completar la versión; en el caso de que estén vencidas y no cumplidas, los días reales se computan hasta el último día del periodo Nº Días Planificados: Días previstos o aprobados en planificación para entregar el producto

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 67 de 75-

	Consideraciones • Tanto numerador como denominador se calculan sobre las mismas versiones: Las cumplidas en el periodo • Las versiones que no están cumplidas en el momento del análisis y acarrean desviación, será tenidas en cuenta en el periodo en el que se termine el trabajo encargado • Las planificaciones iniciales asociadas a cada encargo de trabajo deben ser propuestas por el contratista y aprobadas por la DGOJ • Se realizan los cálculos en base a la fecha de puesta a disposición de la DGOJ del encargo de trabajo (ET) planificado • Por necesidades del servicio, cambios de prioridades, o similar, es posible que sea necesario reajustar la planificación a lo largo del proyecto. Las nuevas fechas se deberán volver a proponer por parte del contratista y aprobar por parte de la DGOJ • Unidad mínima de cómputo de desviación de 1 día con independencia del valor del indicador en caso de ser menor a este valor
Periodicidad mínima de análisis	Se analizarán los encargos de trabajo planificados para entregar al objeto de validación en el periodo (mensual)
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Planificación detallada actualizada	Herramienta de planificación (Project o similar)	Manual
Informes de seguimiento	Equipo prestador del servicio	Manual

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_4 Calidad de la estimación de encargos de trabajo planificados

Indicador	I_4 Calidad de la estimación de encargos de trabajo planificados
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicios de mantenimiento evolutivo • Servicio de mantenimiento correctivo • Servicio de nuevos desarrollos • Servicio de análisis, estudio y documentación
Objetivo del indicador	Conseguir que se cumplan las estimaciones previstas en las planificaciones aprobadas para cada encargo de trabajo (ET).
Descripción del indicador	Indicador para la detección de desviaciones en las estimaciones previstas en las planificaciones. Las planificaciones estarán aprobadas por la DGOJ acorde a la cláusula IV.3 (Modelo de gestión: Supervisión, control y seguimiento de la ejecución) del presente pliego
Niveles de servicio	Se requiere cumplir la estimación de la planificación y que la eventual desviación sea ≤ 25%
Métrica	𝑇𝑜𝑡𝑎𝑙 𝐻𝑜𝑟𝑎𝑠 𝐸𝑠𝑡𝑖𝑚𝑎𝑑𝑎𝑠 ( − 1) ∗ 100 𝑇𝑜𝑡𝑎𝑙 𝐻𝑜𝑟𝑎𝑠 𝐷𝑒𝑑𝑖𝑐𝑎𝑑𝑎𝑠 Total Horas estimadas del ET: Este dato se obtiene del campo “Tiempo total estimado” de la herramienta Redmine.

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 68 de 75-

	Total Horas dedicadas del ET: Este dato se obtiene del campo “Tiempo total dedicado” de la herramienta Redmine. Consideraciones • Tanto numerador como denominador se calculan sobre las mismas versiones: Las cumplidas en el periodo. • Las versiones que no están cumplidas en el momento del análisis y acarrean desviación, será tenidas en cuenta en el periodo en el que se termine el trabajo encargado • Las estimaciones iniciales asociadas a cada encargo de trabajo deben ser propuestas por el contratista y aprobadas por la DGOJ. • Por necesidades del servicio, cambios de alcance, o similar, es posible que sea necesario reajustar la estimación a lo largo del proyecto. Las nuevas estimaciones se deberán volver a proponer por parte del contratista y aprobar por parte de la DGOJ.
Periodicidad mínima de análisis	Se analizarán los encargos de trabajo planificados para entregar al objeto de validación en el periodo (mensual)
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Estimaciones detalladas.	Herramienta de extracción de datos (Redmine)	Semiautomática
Tiempo dedicado	Equipo prestador del servicio	Exportación de Redmine

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_5: Índice de solución de peticiones

Indicador	I_5 Índice de solución de peticiones
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicio de soporte al usuario (CAU) / soporte técnico
Objetivo del indicador	Conseguir la mejora de la calidad de servicio, que redundará en el aumento de la satisfacción del usuario y en una reducción del coste asociado a cada petición
Descripción del indicador	Indicador del nivel de resolución, utilizando el porcentaje de peticiones solucionadas (de las pendientes al inicio de dicho mes) durante el mes, del total de peticiones pendientes registradas al inicio de dicho mes. Estas peticiones hacen referencia a cualquier actividad no planificable distinta del mantenimiento correctivo
Niveles de servicio	Los grados de prioridad son los siguientes: • Bloqueantes ≥ 95% • Urgentes ≥ 90% • Alta ≥ 85% • Normales ≥ 75% • Baja ≥ 70%
Métrica	𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑒𝑡𝑖𝑐𝑖𝑜𝑛𝑒𝑠 𝑠𝑜𝑙𝑢𝑐𝑖𝑜𝑛𝑎𝑑𝑎𝑠 (𝑒𝑛 𝑓𝑢𝑛𝑐𝑖ó𝑛 𝑑𝑒 𝑙𝑎 𝑝𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑) ( ) ∗ 100 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑝𝑒𝑡𝑖𝑐𝑖𝑜𝑛𝑒𝑠 𝑎𝑏𝑖𝑒𝑟𝑡𝑎𝑠 (𝑒𝑛 𝑓𝑢𝑛𝑐𝑖ó𝑛 𝑑𝑒 𝑙𝑎 𝑝𝑟𝑖𝑜𝑟𝑖𝑑𝑎𝑑)

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 69 de 75-

Periodicidad mínima de análisis	Mensual
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Peticiones registradas y solucionadas	Sistema de gestión de peticiones (GLPI/Redmine)	Semiautomática
Informes de seguimiento	Equipo prestador del servicio	Manual

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_6: Índice de esfuerzo dedicado en correctivos

Indicador	I_6 Índice de esfuerzo dedicado en correctivos
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicio de mantenimiento correctivo • Servicios de mantenimiento de carácter funcional
Objetivo del indicador	Conseguir la mejora de la calidad de servicio, que redundará en el aumento de la satisfacción del usuario y en una reducción del coste asociado al servicio en cuanto al mantenimiento correctivo
Descripción del indicador	Este indicador mide el esfuerzo dedicado a la resolución de correctivos durante el servicio frente a las horas dedicadas con carácter funcional, lo que servirá para evaluar los niveles de calidad del mismo acorde a los mínimos establecidos. Este indicador se calcula trimestralmente
Niveles de servicio	≤ 10% del tiempo total
Métrica	𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠 𝑑𝑒𝑑𝑖𝑐𝑎𝑑𝑎𝑠 𝑎 𝑐𝑜𝑟𝑟𝑒𝑐𝑡𝑖𝑣𝑜𝑠 𝑒𝑛 𝑒𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜 ( ) ∗ 100 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 ℎ𝑜𝑟𝑎𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠 𝑖𝑚𝑝𝑢𝑡𝑎𝑑𝑎𝑠 𝑎 𝑑𝑒𝑠𝑎𝑟𝑟𝑜𝑙𝑙𝑜𝑠 𝑒𝑛 𝑒𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜
Periodicidad mínima de análisis	Trimestral
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Registro de imputación de tiempos	Herramienta de Ticketing (Redmine)	Semiautomática

I_7: Índice de calidad del código fuente

Indicador	I_7 Índice de calidad del código fuente
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicio de mantenimiento evolutivo • Servicio de nuevos desarrollos • Servicio de mantenimiento correctivo
Objetivo del indicador	Conseguir dotar a la DGOJ de productos software entregados con unos estándares de calidad mínimos establecidos en la implementación del código

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 70 de 75-

Descripción del indicador	Este indicador mide la calidad del código fuente entregado en base a unas métricas preestablecidas. La herramienta de análisis utilizada es SONAR, y los umbrales de calidad de las reglas a aplicar pueden consultarse en el Anexo I
Niveles de servicio	Los umbrales establecido para un “proyecto sano”.
Métrica
		Métrica aplicable	Métricas (Porcentaje)	Umbral proyecto sano
		5.2 Normas de codificación	Cumplimiento de reglas de codificación	Menor 80% 🡪
			Evidencias bloqueantes	Igual 0% 🡪
			Evidencias críticas	Igual 0% 🡪
		5.3 Documentación del código	Documentación del código	Mayor 50% 🡪
		5.4 Duplicidad del código	Líneas de código duplicadas	Menor 15% 🡪
Periodicidad mínima de análisis	Trimestral. Se tendrán en cuenta todas las entregas de código realizadas durante ese periodo. Para ello se analizará la calidad del código de todas aquellas entregas de versión cerrada de los equipos de Desarrollo en PRE cada trimestre.
Fuente de información de los datos
Datos			Sistema de información	Alimentación
Código fuente de la versión			Herramienta de SONAR	Automático

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

C.- Indicadores de calidad de los productos finales:

I_8: Índice de calidad del desarrollo en las pruebas aceptación

Indicador	I_8 Índice de calidad del desarrollo en las pruebas de aceptación
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicio de mantenimiento correctivo • Servicio de mantenimiento evolutivo • Servicio de nuevos desarrollos
Objetivo del indicador	Conseguir la calidad y mejora en el desarrollo del software, que redundará en el aumento de la satisfacción del usuario y en una reducción del coste de mantenimiento posterior
Descripción del indicador	Como indicador se utilizará el número de incidencias (altas, medias y bajas) imputables a desarrollo, detectadas a lo largo del primer ciclo de pruebas de aceptación realizadas por el equipo de Calidad
Niveles de servicio	≥ 85 (calidad media del software)
Métrica	𝑁º 𝐼𝑛𝑐𝑑. 𝑚𝑒𝑑𝑖𝑎𝑠 + (2 ∗ 𝑁º 𝐼𝑛𝑐𝑑. 𝑎𝑙𝑡𝑎𝑠) + (0,2 ∗ 𝑁º 𝐼𝑛𝑐𝑑. 𝑏𝑎𝑗𝑎𝑠) 100 ∗ (1 − 𝑁º 𝑡𝑜𝑡𝑎𝑙 𝑐𝑎𝑠𝑜𝑠 𝑝𝑟𝑢𝑒𝑏𝑎𝑠. )

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 71 de 75-

	Nº Incd.altas: Nº de incidencias altas y/o bloqueantes Nº Incd.medias: Nº de incidencias medias Nº Incd.bajas: Nº de incidencias bajas Nº total casos pruebas: Nº total de casos de prueba ejecutados Consideraciones: • Sólo se contabilizan las incidencias nuevas detectadas durante el ciclo en curso • Sólo se contabilizan las incidencias una vez • Sólo se contabilizan, entre las incidencias cerradas, las resueltas; no, las incidencias anuladas ni modificadas por la DGOJ • Sólo se contabilizan las incidencias de instalación y funcionales, incluyendo aquellas que afectan a la presentación de pantallas e interfaces
Periodicidad mínima de análisis	Se calcula para cada ciclo de pruebas completo de una versión
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Informe de Calidad con nº incidencias en pruebas aceptación	Sistema de gestión de incidencias (Redmine)	Semiautomática

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_9: Índice de calidad del desarrollo en la Nª de regresión

Indicador	I_9 Índice de calidad del desarrollo en la Nª de regresión
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	Mantenimiento y evolución de Sistemas de Información
Objetivo del indicador	• Servicio de mantenimiento correctivo • Servicio de mantenimiento evolutivo • Servicio de nuevos desarrollos
Descripción del indicador	Mide el porcentaje ponderado del nº casos de prueba no afectados por incidencias (bloqueantes, altas, medias y bajas) imputables a desarrollo, detectadas en el 1er ciclo de pruebas de regresión, respecto del nº total de casos de pruebas ejecutados
Niveles de servicio	Basado en los casos de prueba afectados por incidencias bloqueantes, altas, medias y bajas en la actualización. De forma similar al I_8, pero tras una nueva entrega (actualización) “depurada” por desarrollo al objeto de corregir las incidencias detectadas en las regresiones anteriores o en las pruebas de aceptación (en caso de ser la 1ª regresión) Considera los casos de prueba afectados por incidencias en la actualización, independientemente de que existieran o no en la entrega inicial objeto de pruebas (ciclo inicial) ≥ 90 (calidad media del software en regresiones)
Métrica	𝑁º 𝐼𝑛𝑐𝑑. 𝑚𝑒𝑑𝑖𝑎𝑠 + (2 ∗ 𝑁º 𝐼𝑛𝑐𝑑. 𝑎𝑙𝑡𝑎𝑠) + (0,2 ∗ 𝑁º 𝐼𝑛𝑐𝑑. 𝑏𝑎𝑗𝑎𝑠) 100 ∗ (1 − 𝑁º 𝑡𝑜𝑡𝑎𝑙 𝑐𝑎𝑠𝑜𝑠 𝑝𝑟𝑢𝑒𝑏𝑎𝑠. ) Nalta/bloq: Nº de incidencias altas y/o bloqueantes Nmedia: Nº de incidencias medias Nbaja: Nº de incidencias bajas Ntotal: Nº total de casos de prueba ejecutados en la Nª regresión Consideraciones: las mismas que para el indicador I_7 y, además, se consideran las incidencias

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 72 de 75-

	detectadas en el ciclo inicial de pruebas que permanecen abiertas y las incidencias abiertas detectadas en esta Nª regresión
Periodicidad mínima de análisis	El indicador se calcula para cada regresión, o actualización, hasta que la versión en pruebas tenga los niveles de calidad aceptados para su pase a producción
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Informe de Calidad con nº incidencias en pruebas aceptación	Sistema de gestión de incidencias (Redmine)	Semiautomática

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_10: Índice de calidad del desarrollo según ciclos de pruebas de regresión

Indicador	I_10 Índice de calidad del desarrollo según ciclos de pruebas de regresión
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicio de mantenimiento correctivo • Servicio de mantenimiento evolutivo • Servicio de nuevos desarrollos
Objetivo del indicador	Reducir el número de regresiones y optimizar el uso de recursos
Descripción del indicador	Mide el nº de ciclos de pruebas de regresión, en el ciclo completo, necesarios para solucionar todas las incidencias bloqueantes y altas
Niveles de servicio	Nactualizaciones < 3
Métrica	Nactualizaciones: Nº de entregas de tipo actualización requeridas para que la versión en fase de testing no contenga ninguna incidencia alta ni bloqueante de tipo funcional o de instalación
Periodicidad mínima de análisis	El indicador se calcula para cada ciclo completo de pruebas de aceptación
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Informe de Calidad con nº incidencias en pruebas aceptación	Sistema de gestión de incidencias (Redmine)	Semiautomática

I_11: Calidad en el cumplimento documentalista exigido por la metodología de la DGOJ

Indicador	I_11 Calidad en el cumplimento documentalista exigido por la metodología de la DGOJ
Responsables del indicador	• De la definición, extracción y seguimiento: DGOJ • Del cumplimiento: Responsable del servicio del contratista
Vinculado al servicio/s	Todos los Servicios
Objetivo del indicador	Proporcionar los mecanismos necesarios para poder dotar a la DGOJ de documentación bajo los criterios establecidos de calidad

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 73 de 75-

Descripción del indicador	Mide el porcentaje del nº de entregables establecido por la metodología de la DGOJ sin incidencias altas ni medias respecto del nº total de entregables establecidos
Niveles de servicio	≥ 80%
Métrica	𝑁º 𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠_𝐸𝑛𝑡𝑟𝑒𝑔𝑎𝑏𝑙𝑒𝑠_sin _𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑐𝑖𝑎𝑠 100 ∗ 𝑁º. 𝐷𝑜𝑐𝑢𝑚𝑒𝑛𝑡𝑜𝑠_𝐸𝑛𝑡𝑟𝑒𝑔𝑎𝑏𝑙𝑒𝑠_𝑇𝑜𝑡𝑎𝑙 Nº.Docuementos Entregables_sin_incidencias: Nº de entregables obligatorios por metodología sin ninguna incidencia alta ni media Nº.Documentos_Entregables_Total: Nº de entregables obligatorios establecidos de acuerdo a la metodología DGOJ
Periodicidad mínima de análisis	El indicador se calcula en el siguiente periodo trimestral para entregas con cambios en los requisitos del periodo anterior
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Número de entregables	No aplica	Manual
Número de entregables sin incidencias	No aplica	Manual

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_12: Ratio de eficacia de puesta en producción de encargos de trabajo (ET)

Indicador	I_12 Ratio de eficacia de puesta en producción de encargos de trabajo (ET)
Responsables del indicador	• De la definición, extracción y seguimiento: DGOJ • Del cumplimiento: Responsable del servicio del proveedor
Vinculado al servicio/s	• Servicio de mantenimiento correctivo • Servicio de mantenimiento evolutivo • Servicio de nuevos desarrollos
Objetivo del indicador	Proporcionar los mecanismos necesarios para poder dotar a la DGOJ de información de efectividad entre los trabajos de desarrollo planificados y los puestos en producción habiendo pasado las pruebas de aceptación acorde a los niveles de calidad estimados
Descripción del indicador	Mide el porcentaje del nº de encargos de trabajo (ET) puestos en producción con respecto a los inicialmente previstos
Niveles de servicio	≥ 85%
Métrica	𝑁º 𝑈𝑇 𝑑𝑒 𝑙𝑜𝑠 𝐸𝑇 𝑝𝑢𝑒𝑠𝑡𝑜𝑠 𝑒𝑛 𝑝𝑟𝑜𝑑𝑢𝑐𝑐𝑖ó𝑛 𝑒𝑛 𝑒𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜 100 ∗ 𝑁º 𝑈𝑇 𝑑𝑒 𝑙𝑜𝑠 𝐸𝑇 𝑞𝑢𝑒 𝑑𝑒𝑏𝑒𝑟í𝑎𝑛 ℎ𝑎𝑏𝑒𝑟𝑠𝑒 𝑝𝑢𝑒𝑠𝑡𝑜 𝑒𝑛 𝑝𝑟𝑜𝑑𝑢𝑐𝑐𝑖ó𝑛 𝑒𝑛 𝑒𝑙 𝑝𝑒𝑟𝑖𝑜𝑑𝑜. Consideración: • No se considerarán, ni en el numerador ni en el denominador, los encargos de trabajo (ET) derivados de desarrollos calificados como gestión abreviada
Periodicidad mínima de análisis	Trimestral

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 74 de 75-

Fuente de información de los datos
Datos	Sistema de información	Alimentación
Número de encargos disponibles para pasar a producción	Herramienta de ticketing (Redmine)	Manual
Número de encargos planificados y aprobados	Project	Manual

XXXXX XXXXX XXXXXXXXXXX - 2020-09-14 17:55:26 CEST

La autenticidad del documento puede ser comprobada mediante el CSV: OIP_XHPHU2SMRPVVTTCX79CZFGJ5BDL2 en xxxxx://xxx.xxx.xxxxxxxx.xxx.xx

I_13: Índice de solución de incidencias de Calidad

Indicador	I_13 Índice de solución de incidencias de Calidad
Responsables del indicador	• De la definición, forma de extracción y seguimiento: Director Técnico de la DGOJ • De la extracción y cumplimiento: Responsable del servicio del adjudicatario
Vinculado al servicio/s	• Servicio de Validación de la Calidad
Objetivo del indicador	Conseguir la mejora de la calidad de servicio, incidiendo en la calidad del software entregado, a través de las incidencias funcionales.
Descripción del indicador	Indicador del nivel de resolución, utilizando el porcentaje de las incidencias solucionados por los equipos de desarrollo frente a las incidencias abiertas por el equipo de Calidad frente en las revisiones. Las incidencias funcionales abiertas por el equipo de calidad deben estar solucionada en la siguiente entrega de versión (ya sea una nueva iteración o una nueva versión
Niveles de servicio	≥ 80% del tiempo total
Métrica	𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑐𝑖𝑎𝑠 𝑠𝑜𝑙𝑢𝑐𝑖𝑜𝑛𝑎𝑑𝑎𝑠 ( ) ∗ 100 𝑁ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑐𝑖𝑎𝑠 𝑎𝑏𝑖𝑒𝑟𝑡𝑎𝑠
Periodicidad mínima de análisis	Trimestral
Fuente de información de los datos
Datos	Sistema de información	Alimentación
Registro de imputación de tiempos	Herramienta de Ticketing (Redmine)	Semiautomática

xxxxx.xxxxxxxxxxxx@xxxxxxxx.xxx.xx X/ Xxxxxx 0, 0x xxxxxx

28014 – Madrid

TEL: 00 000 00 00

FAX: 00 000 00 00

-Página 75 de 75-