Plataforma de gestión integral del S.E.R.Z.

Arquitectura de la aplicación

La arquitectura de la aplicación debe ser robusta y también modular para que en caso de que uno de los elementos/subsistemas fallen, el resto no se vean comprometidos.

El sistema también debe ser capaz de registrar y almacenar todos los eventos siempre que se consideren de relevancia

La arquitectura que se considera adecuada, y así se ha planteado, es la de un sistema horizontal que aglutine los módulos con los cuales se defina toda la lógica de negocio de las operaciones que se definan en el análisis funcional del Proyecto de Propuesta de Gestión por el adjudicatario en la licitación y en este documento. Estas operaciones deberán ser reutilizables permitiendo que la lógica de negocio se consuma por diferentes dispositivos.

Asimismo, todos los elementos, componentes o sub-sistemas de la aplicación deberán ser capaces de operar de forma autónoma cuando se pierda la conectividad. Cuando la conectividad sea retomada por el elemento de la arquitectura se proporcionará al sistema horizontal un registro completo de los datos que no se han transmitido durante el tiempo que falló la conectividad.

No obstante, si un contratista lo considera adecuado puede ofertar en el momento de la licitación otro tipo de arquitectura del sistema, en su Proyecto de Propuesta de Gestión siendo valorado dentro de los criterios de adjudicación.

Toda la Plataforma deberá seguir el Esquema Nacional de Seguridad indicado en los Anexos de Requisitos de Proyectos de Aplicaciones informáticas que se regula mediante el Real Decreto 951/2015.

Código fuente y programación

La elección de los lenguajes de programación quedará a elección de la licitadora.

El tipo de código empleado (propietario o software libre) podrá ser empleado de forma total en cualquiera de sus versiones o también de forma mixta.

El software propietario podrá ser entregado al Ayuntamiento de forma binaria (ejecutables e instalables) para todos los sistemas disponibles en las versiones que se considere necesario.

Aquel software que se desarrolle como software libre deberá publicarse a la comunidad y será entregado al Ayuntamiento cuando cada versión haya sido liberada y proveer acceso al control de versiones donde éste se almacene

Todas las versiones, tanto de aplicaciones como de sistemas deberán estar correctamente identificadas y almacenadas. En cada versión se deberá generar una hoja con los cambios introducidos en cada una de ellas.

Las aplicaciones deberán seguir la guía de estilo del Ayuntamiento de Zaragoza disponible en https://www.zaragoza.es/sede/portal/guia-estilo/index2. .

Requisitos funcionales

• Proveerá de la lógica de negocio necesaria para que funcionen todos los sub-sistemas y elementos que componen la plataforma
• Si durante el transcurso del contrato se integran otros sistemas, también deberán ser integrados en él,
• Se encargará de monitorizar la existencia de una correcta comunicación y estado entre el sistema horizontal y los sub-sistemas y elementos que componen la Plataforma
• En el caso de detectar cualquier error será capaz de auto-generar incidencias
• Incorporará todos los procesos que sean susceptibles de automatizarse. Por ejemplo:
  • Vehículos residentes:
    • Procesamiento de altas, bajas y modificaciones tramitadas por el ciudadano
    • Monitorización del cumplimiento de las condiciones de los vehículos dados de alta según indica la ordenanza municipal
  • Vehículos de Carga y Descarga:
    • Verificación y cotejo de peticiones.
  • Gestión de propuestas de sanción y envíos a Policía Municipal
  • Incorporación de datos de terceros al sistema
  • Envío de datos a sistemas de terceros
• Ofrecer un API de “Datos Abiertos”: La empresa debe facilitar el acceso a la Interfaz de Programación de Aplicaciones (API), de forma que se pueda acceder a todos los datos públicos del servicio (delimitación de zonas, Zonas de Bajas Emisiones, etc.) en tiempo real, así como la integración con una posible plataforma MaaS municipal, antes del fin del primer año de operación. El detalle de los datos y su estructura, además de las características del acceso en tiempo real, mantenimiento, formato, periodicidad y la provisión de datos históricos, serán los acordados por el Servicio de Movilidad Urbana junto con la Oficina de Participación, Transparencia y Gobierno Abierto del Ayuntamiento de Zaragoza.

La empresa deberá reutilizar, siempre que sea posible, los modelos de datos abiertos utilizados por el Ayuntamiento de Zaragoza, evitando en la medida de lo posible la creación de datos que ya se encuentren disponibles en el catálogo de datos abiertos.

El ayuntamiento de Zaragoza podrá reutilizar los datos que se generen en el contexto de este proyecto y publicarlos en el catálogo de datos abiertos.

Requisitos No Funcionales

• El sistema y módulos se actualizarán a las políticas de seguridad conforme éstas evolucionen en el tiempo. Asimismo, también deberán ir actualizándose a las nuevas versiones y paquetes estables del software utilizado , como de las librerías necesarias para operar, etc
• Las comunicaciones deberán seguir una capa de seguridad del más alto estándar
• Controlarán los permisos de acceso de los usuarios en la comunicación en los casos donde se considere necesario
• El sistema horizontal seguirá los requisitos y recomendaciones el Servicio de Redes y Sistemas del Ayuntamiento de Zaragoza
• Se comunicará con servicios de terceros, tanto públicos como privados, para intercambiar datos de forma bidireccional
  • Parkings privados y públicos
  • Hoteles
  • Dirección General de Tráfico
  • MaaS (Mobility as a Service)
  • Sistemas municipales: Padrón, Sanciones, Expedientes, Recaudación…
  • Otros
• El software que se desarrolle deberá ser robusto, seguro, flexible y reutilizable
• Se registrarán las operaciones y los errores en la aplicación y serán fácilmente consultables
• El sistema estará disponible durante las 24 horas los 365 días del año de forma ininterrumpida

Requisitos funcionales

• Alta de nuevo usuario
• Identificación de usuarios: cualquier usuario podrá identificarse o iniciar sesión en la aplicación al menos a través de los siguiente métodos
  • Usuario y contraseña del portal
  • Certificado electrónico
  • Cl@ve Pin
  • Cl@ve Permanente
  • Huella dactilar. Esta opción se permitirá configurar tras el acceso con alguna de la anteriores
• Alta y gestión de vehículos en la aplicación y en el sistema según los requisitos que se indique en la normativa S.E.R.Z

  En el listado de vehículos deberá incluir una serie de identificaciones sencillas para el usuario:

  • Identificar fácilmente el vehículo que se utilice de manera “Habitual”. Este vehículo podrá ser sugerido al usuario
  • Identificar fácilmente el vehículo reservado dado de alta como “Autónomo”. Si corresponde a alguna Zona de estacionamiento regulado esta deberá aparecer en el detalle del vehículo.
• Poder ver listados de todas las operaciones realizadas y consultar el detalle de cada una de ellas
• El acceso a la geolocalización del dispositivo será imprescindible para realizar las operaciones de aparcar y “desaparcar”
• Generación de incidencias, quejas y sugerencias
• Solicitud de baja del usuario
• Recibir notificaciones de difusión

Requisitos NO Funcionales

• La aplicación deberá ser fácil de utilizar para el usuario y permitirá realizar los pasos de forma intuitiva
• La aplicación deberá estar disponible para todas las tecnologías y versiones existentes en el mercado de uso generalizado
• La aplicación se actualizará a las políticas de seguridad conforme evolucionen en el tiempo
• Las comunicaciones deberán seguir una capa de seguridad del más alto estándar
• La aplicación seguirá la guía de estilo del ayuntamiento de Zaragoza
• El software que se desarrolle deberá ser robusto, seguro, flexible y reutilizable
• Se registrarán las operaciones y los errores en la aplicación y se comunicarán con el “Gestor de Incidencias”
• En el caso de que no haya conectividad entre el dispositivo del usuario y el servidor, se permitirá el almacenamiento
• La aplicación deberá cumplir el Real Decreto 1112/2018, de 7 de septiembre sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.
• Generación de manual de usuario
• Integración de ayuda en la aplicación
• Generación de propuestas para el nombre y la imagen de la aplicación

Requisitos Funcionales

• Identificación de usuarios
• Lectura de información geolocalizada en un mapa, listado de las propuestas de sanción y listado de incidencias registradas en vía pública
• Análisis a través de imágenes de los vehículos y comprobación del estado del estacionamiento
• Confirmación de propuestas de sanción y transformación en Sanciones
• Generación de incidencias
• Generación automática de incidencias del dispositivo

Requisitos NO Funcionales

• El sistema deberá ser fácil de utilizar para el usuario y permitirá realizar los pasos de forma intuitiva.
• El sistema se actualizará a las políticas de seguridad conforme evolucionen en el tiempo.
• Las comunicaciones deberán seguir una capa de seguridad del más alto estándar.
• Se registrarán las operaciones y los errores en la aplicación y se comunicarán con el “Gestor de Incidencias”
• Recibir mensajes, órdenes y comandos desde un Centro de Gestión.
• Acceso a la geolocalización del dispositivo
• La aplicación deberá cumplir el Real Decreto 1112/2018, de 7 de septiembre sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.
• La aplicación deberá ser compatible con los actuales y futuros equipos del personal de Policía Local y del Ayuntamiento.
• Ofertar formación para el personal al que va destinado la aplicación
• Generación de manuales de usuario e integración de ayuda en la aplicación

Requisitos Funcionales

• Análisis a través de imágenes de los vehículos
• Informar de su geolocalización y estado del sistema de forma periódica
• Generación automática de alertas sobre vehículos no autorizados a revisar
• Generación automática de incidencias del sistema tanto hardware como software

Requisitos NO Funcionales

• El sistema se actualizará a las políticas de seguridad conforme evolucionen en el tiempo
• Las comunicaciones deberán seguir una capa de seguridad del más alto estándar
• Se registrarán las operaciones y los errores en el sistema y se comunicarán con el “Gestor de Incidencias”
• Recibir mensajes, órdenes y comandos desde un Centro de Gestión.
• Tendrán la capacidad de operar incluso cuando no dispongan de conexión con el sistema horizontal para comunicar las alertas. Una vez recuperada la conectividad, enviarán la información al sistema horizontal para que sea procesada y cotejada con los sucesos ocurridos.
• Generación de manuales de usuario e integración de ayuda en la aplicación

Requisitos Funcionales

Sin necesidad de identificación de usuario (login) se presentarán las siguientes funcionalidades:

• Alta o registro de nuevo usuario
• Mostrar información, tanto a través de mapas como de listados de la ocupación de las plazas que son objeto del S.E.R.Z.. La información y capas mostradas será interactiva.
• Mostrar información sobre los elementos con los que puede interactuar el usuario (parquímetros y paneles de información variable
• Mostrar información de afecciones viarias.
• Proveer de información pública a la ciudadanía a través de una sección con “Datos Abiertos”. Los datos podrán proveer de terceros, de informes automáticos, de requisitos proporcionados por la Dirección del Contrato, etc. Todos estos informes no podrán mostrar información privada y deberán cumplir la Normativa de Protección de Datos vigente durante toda la duración del contrato.

  También deberá existir un acceso al API de Datos Abiertos que permitirá ofrecer operaciones de consulta del estado del Estacionamiento Regulado en la ciudad.

• Proveer tanto a ciudadanos como a empresas particulares de un formulario de contacto para tramitar diferentes tipos de peticiones
• Resolver dudas de los usuarios a partir de una sección de “Preguntas frecuentes”
• Proveer a los usuarios de manuales de uso y facilitar acceso a las aplicaciones móviles para el ciudadano.
• Identificación de usuarios: cualquier usuario podrá identificarse o iniciar sesión en la aplicación al menos a través de los siguiente métodos
  • Usuario y contraseña del portal
  • Certificado electrónico
  • Cl@ve Pin
  • Cl@ve Pin
  • Huella dactilar. Esta opción se permitirá configurar tras el acceso con alguna de la anteriores

  Una vez el usuario se haya identificado o haya hecho login en el sistema proporcionará un conjunto de funcionalidades.

• Alta y gestión de vehículos en la aplicación y en el sistema según los requisitos que se indique en la normativa S.E.R.Z.
• Alta y gestión de formas de pago en la aplicación y en el sistema según se indique en la normativa S.E.R.Z
• Aparcamiento de los vehículos. En este caso el usuario deberá indicar el lugar aproximado donde ha aparcado el vehículo (dirección) y a partir de ese dato se calculará la zona.
• Listar todas las operaciones realizadas con los vehículos disponibles.
• Listar todas las transacciones monetarias realizadas.
• Generación de incidencias, quejas y sugerencias
• Solicitud de baja

Trabajadores por cuenta propia o PYMEs

Para los trabajadores por cuenta propia se contemplarán las siguientes operaciones:

• Alta y gestión de vehículo como autónomo o PYME. En el listado de vehículos se distinguirá claramente que el vehículo está registrado como autónomo.
• Alta y gestión de los pagos periódicos relacionados con el vehículo declarado como autónomo

Usuarios asociados como Persona Jurídica

Existirán una serie de actores que podrán acceder al portal de gestión con el objetivo de informar de vehículos que no son de su propiedad. Cada uno de estos tipos de actores tendrán una o varias posibles acciones a realizar

Hoteles

Informarán a la plataforma del acceso de vehículos privados que vayan a realizar uso de aparcamientos en sus instalaciones para que no sean sancionados por acceder a zonas de acceso controlado (Z.B.E. o A.P.R.). Para ello se le facilitará al establecimiento la funcionalidad de agregar una hoja de cálculo o rellenar un formulario. El establecimiento deberá indicar la matrícula del vehículo, el día de acceso y el día de finalización de uso de la instalación.

El establecimiento hostelero también dispondrá de la opción de indicar estos datos de forma automática comunicándose el sistema de gestión informática que dispongan con el Sistema Horizontal de la plataforma (PGISERZ).

Parkings privados

Informarán a la plataforma del acceso de vehículos privados que vayan a realizar uso de aparcamientos en sus instalaciones para que no sean sancionados por acceder a zonas de acceso controlado (Z.B.E. o A.P.R.).

Estos datos deberán informarlos de forma periódica a la Plataforma de Gestión Integral. Se deberá indicar tanto la entrada en el reciento como la salida de forma independiente. Para el acceso se deberá facilitar la matrícula y la fecha y hora de acceso y la tipificación de que la acción es de entrada. Para la salida se deberá facilitar la matrícula y la fecha y hora de salida y la indicación de que la acción es de salida.

También existirá la opción de que el sistema de gestión informática del aparcamiento que dispongan con el Sistema Horizontal de la plataforma. Si se utiliza esta opción se informará de la matrícula del vehículo, de la fecha y hora de entrada y de la fecha y hora de salida. Podrán darse casos en los que la entrada y salida se realice en días distintos, por tanto del parámetro que no se haya presentado no se informará.

Talleres de automoción

Todo aquel negocio de este tipo que solicite, acredite que cumple los requisitos en la ordenanza podrá aceder a la ZBE y utilizar las zonas de aparcamiento dentro de ella para el estacionamiento regulado en la vía pública.

El portal web no permitirá “aparcar” nuevos vehículos una vez que se haya llegado al cupo máximo otorgado al negocio.

Requisitos NO Funcionales

• La aplicación web estará disponible durante las 24 horas los 365 días del año de forma ininterrumpida
• El sistema se actualizará a las políticas de seguridad conforme evolucionen en el tiempo
• • Las comunicaciones deberán seguir una capa de seguridad del más alto estándar
• Se registrarán las operaciones y los errores en el sistema y se comunicarán con el “Gestor de Incidencias”
• El sistema y módulos se actualizarán a las políticas de seguridad conforme éstas evolucionen en el tiempo. Asimismo, también deberán ir actualizándose a las nuevas versiones y paquetes estables del software utilizado, como de las librerías necesarias para operar, etc.
• Controlarán los permisos de acceso de los usuarios en la comunicación en los casos donde se considere necesario
• El Sistema Horizontal seguirá los requisitos y recomendaciones el Servicio de Redes y Sistemas del Ayuntamiento de Zaragoza.
• El software que se desarrolle deberá ser robusto, seguro, flexible y reutilizable
• Se registrarán las operaciones y los errores en la aplicación y serán fácilmente consultables.
• La aplicación deberá cumplir el Real Decreto 1112/2018, de 7 de septiembre sobre accesibilidad de los sitios web y aplicaciones para dispositivos móviles del sector público.

Requisitos funcionales

• Identificación de usuarios: cualquier usuario podrá identificarse o iniciar sesión en la aplicación al menos a través de los siguiente métodos
  • Usuario y contraseña del portal
  • Certificado electrónico
  • Cl@ve Pin
  • Cl@ve Permanente
  • Huella dactilar. Esta opción se permitirá configurar tras el acceso con alguna de la anteriores.
• Gestión completa de perfiles y roles de usuario
• Gestión completa de usuarios, permitiendo asignarles perfiles/roles
• Control de acceso de usuarios y del uso de la plataforma en los diferentes subsistemas y elementos que componen la plataforma

Requisitos NO Funcionales

• La aplicación web estará disponible durante las 24 horas los 365 días del año de forma ininterrumpida
• El sistema se actualizará a las políticas de seguridad conforme evolucionen en el tiempo
• Las comunicaciones deberán seguir una capa de seguridad del más alto estándar.
• Se registrarán las operaciones y los errores en el sistema y se comunicarán con el “Gestor de Incidencias”.
• El sistema y módulos se actualizarán a las políticas de seguridad conforme éstas evolucionen en el tiempo Asimismo, también deberán ir actualizándose a las nuevas versiones y paquetes estables del software utilizado, como de las librerías necesarias para operar, etc.
• Controlarán los permisos de acceso de los usuarios en la comunicación en los casos donde se considere necesario.
• El Sistema Horizontal seguirá los requisitos y recomendaciones el Servicio de Redes y Sistemas del Ayuntamiento de Zaragoza.
• El software que se desarrolle deberá ser robusto, seguro, flexible y reutilizable.
• Se registrarán las operaciones y los errores en la aplicación y serán fácilmente consultables

Entornos

Para el correcto desarrollo e implantación del software y desarrollos, evoluciones y correcciones la empresa licitadora deberá proporcionar al menos dos entornos “software” que se describen a continuación

De forma opcional, la empresa concesionaria podrá presentar más entornos de desarrollo, integración, pruebas, etc.

Preproducción

Este entorno será el entorno previo al mundo real. Su finalidad principal será simular el entorno de producción para validad su usabilidad testando correctamente las funcionalidades de la Plataforma.

La configuración será exactamente igual a la que se utilice en el entorno de Producción. Las características técnicas que deberá presentar serán casi similares a las de entorno de Producción. Los datos relativos a los usuarios que se utilizarán serán simulados y no permitirán asociar datos personales a datos reales.

Para las integraciones con sistemas de terceros se realizarán con los sistemas de Preproducción de éstos siempre que sea posible. Para llevarlas a cabo se realizarán en varios bloques, abordando pruebas de comunicación, pruebas de integración y pruebas funcionales.

Para las pruebas funcionales, se deberán identificar los datos de prueba (con los que se puede trabajar) para realizar verificaciones de las funcionalidades que se vean afectadas. Únicamente en el caso de que no existan modificaciones de datos en los sistemas de terceros y si los datos no vulneran la Ley Orgánica de Protección de Datos, se podrán utilizar datos reales.

No se requerirá que este entorno esté operativo de forma ininterrumpida. El entorno deberá ser operativo entre las 8:00 y las 17:00 de lunes a viernes. En los días festivos que se ajusten al calendario laboral aprobado por el Gobierno del Ayuntamiento de Zaragoza no será necesario que el entorno esté operativo.

El acceso a este entorno y los elementos que lo conformen estará restringido al público en general y se proporcionará acceso y visibilidad únicamente al personal que se considere necesario.

El personal perteneciente a la Dirección de Control del Contrato del Ayuntamiento de Zaragoza tendrá acceso a todos los elementos para poder realizar verificaciones y pruebas.

Producción

Este entorno será el mundo real, donde se realizarán las operaciones y transacciones y será el utilizado por los usuarios. Asimismo, también se deberá caracterizar porque su infraestructura tenga una mayor capacidad que el entorno de Preproducción, una mejor gestión de tráfico y operaciones y otras características para asegurar su funcionamiento ininterrumpido.

Como norma general, todas las máquinas y elementos de la Plataforma en este entorno se encontrarán ocultas para evitar ciber-ataques. Como excepciones se encontrarán aquellas máquinas que permitan el acceso a las páginas web, tanto la pública como las privadas y también el acceso a los módulos de información de libre disposición. Con este objetivo se deberá proporcionar un dominio.

El personal de la Dirección de Control del Contrato del Ayuntamiento de Zaragoza deberá tener acceso a todos los recursos que se considere necesario: servidores, bases de datos, páginas web, módulos de información, etc.

De este entorno será necesario realizar copias de seguridad periódicas de los datos. Además, también deberá realizarse el traspaso de datos al Ayuntamiento de Zaragoza al menos una vez a la semana mediante un sistema automatizado.

Para desplegar nuevo software en este entorno, las pruebas funcionales y de regresión deberán haber sido ejecutadas y pasadas de forma satisfactoria en el entorno de Preproducción con toma de evidencias y generación de documentos. La Dirección de Control del Contrato recibirá la documentación de la realización de estas pruebas al menos dos días laborables antes de que se vaya a producir la promoción del software. Durante este tiempo el personal de la Dirección del Contrato podrá presentar alegaciones a la promoción del software.

En este entorno también se deberán lanzar pruebas automatizadas utilizando usuarios de pruebas que serán claramente identificables. Los datos generados por estas pruebas serán eliminados de la base de datos una vez lanzadas las pruebas.

Otros entornos

La empresa concesionaria también podrá disponer de otros entornos previos donde realizar desarrollos, despliegues, integraciones y cualquier tipo de pruebas sin estar abiertos a la Dirección de Control del Contrato del Ayuntamiento de Zaragoza si lo considera necesario.

Pruebas y Validaciones

Cualquier cambio requerirá de un documento de evidencias donde se muestre que los cambios han sido correctamente abordados y también para garantizar que la Plataforma dispone de la capacidad suficiente como para soportar de forma simultánea todas las operaciones necesarias.

Estas pruebas las podremos detallar en varios grupos:

Pruebas funcionales

Cada uno de los elementos y módulos de la plataforma dispondrá de un conjunto de funcionalidades que se podrán abordar por un actor. Estas funcionalidades estarán compuestas por una o varias operaciones e incluso interacciones con otros elementos.

La prueba de cada una de las funcionalidades será una prueba funcional y para cada prueba se deberán tener en cuenta todas las casuísticas existentes para asegurar que ninguna de las operaciones queda sin probar. Junto con el software estas pruebas deberán ir evolucionando y presentando los cambios reflejados en el software.

Con cambios en el software se deberán presentar dos tipos de prueba:

• Evidencias del cambio: serán aquellas pruebas que comprenden operaciones asociadas con el cambio en el software relacionado
• Pruebas de regresión: son las funcionalidades de elemento, módulo o pieza del software no afectadas por el cambio que se realiza. Con ellas se garantiza que no existen afecciones debidas al cambio realizado

Se valorará muy positivamente que esas pruebas estén automatizadas y que permitan observar unos resultados rápidos, incluso para la resolución de pequeños errores.

Las pruebas, también deberán ejecutarse en el entorno de producción al menos cada vez que se promocione el código con datos ficticios para poder trazarlos correctamente y que no sean de aplicación en los índices de servicio.

Para realizar el despliegue en Producción de un cambio de software, el conjunto de pruebas asociadas a la pieza de código tendrán que haber pasado los test de forma correcta. Además, el conjunto de pruebas deberá ser remitido a la Dirección de Control del Contrato y validado por ésta.

En el caso de que sean nuevos desarrollos, se deberán realizar análisis de los cambios, tanto funcionales como técnicos y diseñar un conjunto de pruebas para cada una de las aplicaciones y módulos que componen la plataforma. Estas nuevas pruebas se integrarán en el conjunto de las ya existentes.

Pruebas automatizadas

Se trata de aquellas pruebas que pueden ser ejecutadas de forma autónoma sin interacción de ningún operador con la plataforma. Estas pruebas siempre deberán de realizarse con usuarios claramente identificables y trazables en la Plataforma en aras de garantizar la identificación de errores.

Cada vez que se ejecute un conjunto de pruebas automatizadas se generará un informe en una hoja de cálculo o consultable desde la Web Privada de la Plataforma en el que deberán figurar:

• Número prueba
• Nombre prueba
• Resultado
• Descripción prueba
• ID Usuario
• Fecha y hora
• Observaciones: deberá indicar información sobre el error en caso de que se presente

Test de estrés o Pruebas de carga

A partir de las pruebas automatizadas, se podrá generar un conjunto de pruebas de estrés para evaluar el desempeño de la plataforma y tratar de llevarla al límite de su funcionamiento. Este tipo de pruebas tratan de evaluar que la capacidad de los elementos de la Plataforma es la correcta y que permite presentar unos tiempos de respuesta correctos y un funcionamiento óptimo del conjunto de elementos operando de forma simultánea.

Las pruebas de estrés siempre se realizarán con datos que puedan ser fácil identificación para su eliminación del sistema

Durante la instalación e implantación del sistema, estas pruebas deberán ir ejecutándose tanto en los entornos de Producción como Preproducción para garantizar su correcto funcionamiento y dimensionado.

Una vez puesto en marcha, este tipo de pruebas deberán realizarse al menos una vez al mes en el entorno de Preproducción fuera del horario crítico de funcionamiento del Servicio de Estacionamiento Regulado según indique la ordenanza. Las pruebas deberán dimensionarse en relación con la cantidad de usuarios que existan y el número de elementos de la Plataforma que puedan funcionar a la vez.

En el caso de que se utilice una arquitectura de software flexible que se auto-escale y adapte a las necesidades de las peticiones, se deberá garantizar el buen funcionamiento de ésta.

Pruebas de integración

Para garantizar el funcionamiento de las integraciones con terceros se deberán realizar pruebas de integración. Estas pruebas de integración garantizarán que la conectividad y comunicación entre los elementos o componentes es correcta.

Estas pruebas se podrán desglosar en pruebas de subsistemas o módulos para disponer de una identificación y trazabilidad correcta.

Las pruebas se deberán ejecutar tanto en el entorno de Preproducción como en el de Producción cuando existan cambios en la tipología de las integraciones.

Soporte al usuario

La empresa licitadora deberá encargarse de prestar la atención al usuario a través del CAU (Centro Atención al Usuario) a través de una serie de canales descritos en el apartado “OFICINA DE ATENCIÓN AL PÚBLICO”.

Los servicios que al menos se pondrán a disposición del usuario y el ciudadano serán:

• Información de carácter general relativa a todos los ámbitos de la presente ordenanza y el posterior contrato
• Concertación de cita previa para realizar gestiones presenciales
• Comunicación, registro de avisos y peticiones y consulta de estados de tramitación
• Registro de sugerencias, quejas, reclamaciones y felicitaciones de los ciudadanos. Consulta del estado de tramitación de éstas.
• Registro y consulta del estado de tramitación de diferentes tipos solicitudes:
  • Alta, baja y modificación en zona de acceso restringido
  • Alta, baja y modificación de Tarjeta de residente y otros tipos de permisos

Cualquier contacto que realice un usuario para realizar algún tipo de trámite deberán registrarse en el módulo del Portal Privado o de Gestión del Servicio que será el encargado de centralizar la gestión de las incidencias. Entre los datos registrados se encontrarán como mínimo los siguientes datos:

• Fecha y hora de registro
• Asunto
• Descripción
• Documentos adjuntos
• Datos contacto usuario: nombre y apellidos, teléfono contacto, email
• Nombre operario atención cliente

A partir de estos datos se deberá iniciar el procedimiento por el cual se deberá proporcionar al usuario una respuesta o solución.

Incidencias

Como en toda aplicación informática se podrán presentar eventos que no formen parte del desarrollo habitual del servicio. Estos eventos causan o podrán causar una interrupción o una reducción en la calidad del servicio. Para tratarlo y mejorarlo será necesario buscar la forma idónea para minimizar estos eventos y dar la respuesta lo más rápidamente y de forma eficaz

La Plataforma de Gestión Integral del Sistema presentará un conjunto de herramientas que permitirán identificar los sucesos que vayan ocurriendo y gestionarlos adecuadamente para darles solución. Estos sucesos los denominaremos incidencias.

Las incidencias podrán ser generadas tanto de forma automática (por el módulo de monitorización al encontrar cambios de estado a erróneos) como manuales (a través de las aplicaciones móviles, de las aplicaciones web, a partir de correos electrónicos e incluso de llamadas de los usuarios.

Ciclo de vida

Las incidencias tendrán un ciclo de vida que abarcará desde su apertura hasta su cierre con la revisión de que se ha abordado de forma correcta.

Para cumplir con este objetivo se ha diseñado un flujo que debería seguir el proceso de resolución con el número mínimo de estados y el número mínimo de intervinientes. Este diseño puede ser modificado y mejorado por la empresa licitadora para recoger un mejor detalle del proceso de mantenimiento.

Como datos generales, las incidencias deberán recoger al menos los siguientes:

• Título o concepto
• Descripción
• Estado
• Responsable: identificador dentro de la plataforma del usuario que se encuentra realizando las gestiones de la incidencia
• Elemento genérico afectado: tipo de elemento físico o software afectado por la incidencia (parquímetro, señalización horizontal o vertical, vigilantes, App Móvil Ciudadano Android, etc)
• Identificador del elemento afectado (sólo si aplica). Aquellas incidencias que afecten a todo un conjunto o elementos similares no deberán indicar este campo
• Listado de comentarios y gestiones realizadas
• Histórico de transiciones y motivaciones
• Listado de ficheros asociados: podrán tener asociado un listado de ficheros o archivos que se utilizarán como evidencias de la transición entre sus estados y los trabajos y operaciones que se llevan a cabo en aras de resolverlas.
• Fecha y hora de apertura o creación
• Fecha y hora de resolución
• Fecha y hora de cierre

El flujo de la incidencia y todos los estados por los que pase deberán quedar almacenados en la Base de Datos, así como también las gestiones, cambios de responsable, motivaciones y los comentarios que se realizan para identificar el proceso llevado a cabo.

En el siguiente flujo se puede observar los responsables de actuar sobre cada uno de los estado, las transiciones y las acciones de las que serán responsables cada uno de ellos desde la apertura al cierre de la incidencia.

Figura 3: Flujo de incidencias

• Abierta: Este será el estado inicial de cualquier nueva incidencia generada. Sobre este estado actuará el personal de mantenimiento de la empresa concesionaria pudiendo pasar a los estados “Rechazada” o “En curso”. En esta incidencia se deberán rellenar varios datos cuando se realice su apertura:
  • Título o concepto
  • Descripción
  • Estado: Abierta
  • Elemento genérico afectado: tipo de elemento físico o software afectado por la incidencia (parquímetro, señalización horizontal o vertical, vigilantes, App Móvil Ciudadano, etc)
  • Identificador del elemento afectado (sólo si aplica): quedarán exentas de rellenar este valor aquellas incidencias que afecten a todo un conjunto o elementos que no dispongan de él.
  • Ficheros asociados (sólo si aplica): podrán ser imágenes, vídeos, registros de ejecución de software (log) donde se muestren las trazas del error, etc
  • Fecha y hora de apertura o creación
• En curso:Este estado expresará que se está trabajando para resolver el incidente por parte de la empresa licitadora. El equipo de mantenimiento deberá realizar todas las gestiones y actuaciones necesarias para llevarla a cabo pudiendo indicar todos los comentarios que sean necesarios para identificar y describir los trabajos realizados.

  Una vez finalizados los trabajos de sub-sanación, la empresa podrá cambiar esta incidencia al estado “Resuelta” añadiendo evidencias (documentos gráficos, escritos, informes de pruebas, etc) de los trabajos realizados

• Resuelta Este estado indicará que ya han sido finalizados los trabajos de forma correcta y que quedará a expensas de la verificación por la Dirección del Contrato para su posterior cierre definitivo. Cuando se llegue a este estado, se rellenará de forma automática el dato “Fecha y hora de resolución” y cambiará el responsable al que está asignada a algún miembro de la Dirección del Contrato. La persona a la que irá dirigido estará establecida por configuración en la aplicación.

  También en este cambio se enviará un correo electrónico al nuevo responsable para avisarle del hecho.

• Revisión: Esta acción se llevará a cabo para evolucionar una incidencia en estado “Resuelta”. El actor encargado de esta acción será la Dirección del Contrato. La verificación de la incidencia se tendrá que realizar a partir de las evidencias de resolución adjuntadas a la incidencia.

  Si se considera que la resolución es satisfactoria, la incidencia se evolucionará al estado “Cerrada”. En caso contrario, se evolucionará al estado “En curso” indicando un comentario por el personal de la dirección del contrato y se borrará la “Fecha y hora de resolución” de la incidencia.

• Cerrada: A este estado se evolucionará cuando desde la Dirección del Contrato se verifique que la incidencia ha sido resuelta correctamente. Cuando llegue a este estado la incidencia se guardará el valor “Fecha y hora de cierre” y finalizará su ciclo de vida.
• Rechazada: La incidencia pasará a este estado cuando el equipo de mantenimiento de la empresa considere en el análisis inicial que no existe motivación para realizar la gestión del caso como incidencia. Para poder llevarla a este estado se introducirá un motivo por parte del gestor que realice este cambio. Al pasar a este estado se cambiará el responsable al que está asignada a algún miembro de la Dirección del Contrato. La persona a la que irá dirigido estará establecida por configuración en la aplicación web.

  También en este cambio se enviará un correo electrónico al nuevo responsable para avisarle del suceso.

• Verificación: Acción que se realizará por parte de la Dirección del Contrato a una incidencia que se encuentre en estado “Rechazado”. Se revisará la interpretación y motivación que se le ha dado por parte del equipo de mantenimiento de la empresa.

  Si la evaluación ha sido correcta, la incidencia pasará al estado “Cerrada” y no computará como incidencia resuelta. En caso contrario, la incidencia regresará al estado “Abierta” indicando una motivación.

El cálculo para la penalización y/o sanción de incidencias se computará entre la “Fecha y hora de resolución” y la “Fecha y hora de apertura”. Estos campos únicamente serán modificables en los momentos indicados en la descripción de los estados indicado previamente.

Las incidencias que hayan sido “Rechazadas” no computarán en este índice de control del desempeño del contrato.

El nivel de criticidad de cada una de las incidencias será determinada en función de la afección que presente para el desempeño del servicio. Cada uno de los elementos de la Plataforma y del Servicio tendrá asignados unos niveles diferentes para representar correctamente la casuística que presenten y el impacto que presenta cada una de ellas respecto al servicio prestado.

Señalización horizontal

Como señalización horizontal se entienden todos aquellos elementos identificadores que se hallan pintados en la calzada y aceras. Este tipo de señalización vial deberá cumplir la normativa estatal vigente (La normativa vigente en señalización vial horizontal durante la redacción de este pliego es “Norma de Carreteras 8.2-IC” del Ministerio de Transportes.).

Se tendrán dos niveles de criticidad asociados a estos elementos para evaluar los posibles problemas que se presenten: “bajo” y “alto”.

El nivel “bajo” estará asociado a aquellos problemas que se presenten en la señalización y que no impidan el correcto desempeño y funcionamiento del servicio de estacionamiento regulado.

En este se tipificarían:

• Deterioro: se observa que la pintura no es muy visible y presenta necesidad de repintado
• No ajustada a plazas de estacionamiento: la pintura se ajusta a las especificaciones de la ordenanza pero existe una diferencia menor de medio metro con los límites indicados en normativa
• Tono de color erróneo al especificado: en la ordenanza se establece un tono de color determinado para cada uno de los identificadores. En este caso el color genérico es correcto pero no así su tono

El nivel de incidencia “alto” estará representado por problemas que implicarían problemas en el desempeño correcto del servicio, podrían no informar o confundir al usuario, o podrían ser problemas que se presentan de forma recurrente. Algunos ejemplos de estos problemas serían:

• Zona Mal pintada (formas erróneas o no ajustada a regulación): las formas que presenta la señalización o la forma no se ajustan a la ordenanza, especificaciones o a la normativa vigente
• Necesidad de re-asfaltado: tras muchos trabajos de fresado el asfalto ha quedado demasiado deteriorado
• Incoherencias entre señalíticas: la señalización genera confusión al usuario debido a que no está bien pintada o incurre en conflicto con el resto de señalización
• Color erróneo conforme a lo especificado: en la ordenanza se indica un color exacto para cada marca vial y el color pintado no se ajusta conforme a lo especificado

Cámaras de video-vigilancia

Con el objetivo de controlar el acceso a las zonas a las que sólo podrán entrar una serie de vehículos se van a instalar videocámaras. Estos elementos deberán registrar imágenes y analizar los vehículos que aparezcan en las imágenes para identificarlos y analizar si tienen permiso de acceso.

Estos elementos formarán una red repartida en los límites de las zonas y se establecen dos niveles de incidencia: “Bajo” y “Alto”.

El nivel de criticidad “Bajo” será asignado a aquellas incidencias que suceden de forma puntual en alguno de estos dispositivos informativos y que no afectan al funcionamiento del dispositivo ni tampoco al servicio de estacionamiento regulado.

Dentro de este nivel se contemplan los siguiente supuestos como ejemplo:

• Arquetas o canalizaciones en mal estado
• Sistema de amarre poco estable o inadecuado

En el nivel de criticidad “Alto” corresponderá a acontecimientos que se producen de forma recurrente o generan afecciones al funcionamiento del servicio de estacionamiento regulado. El nivel “alto” comprenderá incidencias tales como:

• Cámara mal enfocada, no capta vehículos
• Cámara obtiene imágenes ilegibles o borrosas
• Niveles de reconocimiento de matriculas insuficientes
• No se reciben notificaciones de estado en Sistema Horizontal
• No se actualizan datos de listas de control de matrículas

Sistema Horizontal

El Sistema Horizontal es un concepto que engloba todo el software que contendrá a la lógica de negocio de la Plataforma de Gestión Integral. El software del Sistema Horizontal se encontrará dividido en los módulos lógicos y funcionales que se consideren necesarios y oportunos para su correcto desarrollo y mantenimiento. En este software se tendrán en cuenta un total de cinco niveles de criticidad: “Bajo”, “Medio”, “Alto”, “Crítico” y “Bloqueante”.

El nivel de criticidad “Bajo” será asignado a cualquier suceso que ocurre de forma puntual en alguna de las operaciones de los módulos y que no afectan al funcionamiento general de la aplicación ni tampoco al Servicio de Estacionamiento Regulado.

Dentro de este nivel se contemplan los siguientes supuestos como ejemplo:

• Una operación de un módulo presenta una respuesta inadecuada para una petición concreta
• Uno de los procesos automáticos no procesa los datos para un caso concreto

El nivel de criticidad “Medio” será asociado a un suceso que ocurre en un módulo del sistema de forma puntual y/o genera afecciones en algunas operativas principales del sistema.

Dentro de este nivel se contemplan los siguiente supuestos como ejemplo:

• Una operación de un módulo presentan una repuesta inadecuada para una casuística completa siendo independiente el problema de los datos de entrada
• Una operación de un módulo no responde correctamente de forma puntual y genera afecciones en una operación del sistema
• Uno de los procesos automáticos no procesa los datos para una casuística concreta

En el nivel de criticidad “Alto” corresponderá a acontecimientos que se producen de forma recurrente o generan afecciones al funcionamiento del Servicio de Estacionamiento regulado.

El nivel “alto” comprenderá incidencias tales como:

• Una operación de un módulo no responde, no se obtiene la respuesta esperada o tiene un comportamiento no previsto para cualquier casuística
• Uno de los procesos automáticos no procesa los datos o no funciona
• Una de las operaciones de un módulo no dependiente de terceros tarda más de 10 segundos en responder

El nivel de criticidad “Crítico” corresponderá a sucesos que imposibilitarán la realización de operativas u operaciones de los módulos de carácter esencial y que tendrán afecciones en la prestación del Servicio de Estacionamiento Regulado. Entre estas afecciones se encontrarán algunas como las siguientes:

• La operación de aparcar o desaparcar para los usuarios de aplicaciones municipales no funciona o no responde correctamente
• No se registran alertas de un vehículo de videovigilancia
• No se pueden listar alertas de revisión generadas por el vehículo de videovigilancia
• No se pueden registrar propuestas de sanción
• No funciona más de un proceso automático
• Una de las operaciones de un módulo no dependiente de terceros tarda más de 60 segundos en responder

El nivel de criticidad “Bloqueante” se encontrará asociado con el bloqueo de un conjunto de funcionalidades o de operaciones pertenecientes al sistema horizontal y que provocarán que se vea bloqueado el Servicio de Estacionamiento Regulado.

Entre estas afecciones principalmente se contemplan:

• Ninguna de las operaciones de un módulo responde, no responden de la forma esperada o tienen un comportamiento no previsto para cualquier casuística
• El módulo de monitorización no recibe o registra mensajes de estado de los sub-sistemas que conforman la Plataforma
• El módulo que permite la operatividad de aplicaciones de terceros no funciona o no responde correctamente
• Las operaciones de un módulo no dependiente de terceros tardan en responder más de 180 segundos

App Móvil Ciudadano

La App Móvil para el Ciudadano permitirá a cualquier usuario operar y realizar las operaciones más comunes. Esta aplicación proporcionará el interfaz al usuario en pocos pasos haciéndola fácilmente utilizable y accesible. Con esto, toda la lógica se encontrará radicada en los módulos del Sistema Horizontal.

Como cada aplicación será independiente según el sistema operativo o tecnología en que se base, las incidencias se considerarán recurrentes si se dan en el mismo sistema. Si una misma incidencia ocurre únicamente en un sistema. En el software se tendrán en cuenta un total de cinco niveles de criticidad: “Bajo”, “Medio”, “Alto”, “Crítico” y “Bloqueante”.

El nivel de criticidad “Bajo” será asignado a cualquier suceso que ocurre de forma puntual en alguna de las operaciones que se realicen en la aplicación y que no afecten al funcionamiento general de la aplicación ni tampoco al Servicio de Estacionamiento Regulado.

Dentro de este nivel se contemplan los siguientes supuestos como ejemplo:

• Usuario no puede realizar recargas o pagos
• Usuario no puede añadir métodos de pago a su listado
• Usuario no puede agregar vehículos a su listado

El nivel de criticidad “Medio” será asociado a un suceso que ocurre en varios dispositivos de forma puntual y/o genera afecciones en algunas operativas principales del sistema.

Dentro de este nivel se contemplan los siguiente supuestos como ejemplo:

• Usuario no puede aparcar o “des-aparcar”.
• Varios usuarios no pueden realizar recargas o pagos
• Varios usuarios no pueden añadir métodos de pago a su listado
• Varios usuarios no pueden agregar vehículos a su listado

En el nivel de criticidad “Alto” corresponderá a acontecimientos que se producen de forma recurrente en la aplicación o generan afecciones para muchos usuarios dentro de la aplicación.

El nivel “alto” comprenderá incidencias tales como:

• Servicios de información de ocupación del SERZ no funcionan
• Ningún usuario puede dar de alta vehículos o medios de pago a su listado
• La aplicación tarda más de 10 segundos en responder

El nivel de criticidad “Crítico” corresponderá a sucesos que imposibilitarán a los usuarios la ejecución de funcionalidades de carácter esencial y que tendrán afecciones en la prestación del Servicio de Estacionamiento Regulado en gran cantidad de usuarios

Entre estas afecciones se encontrarán algunas como las siguientes:

• Varios usuarios no pueden aparcar o des-aparcar utilizando la misma versión en el mismo Sistema Operativo Móvil o tecnología en la que se base
• Mapas de ocupación de las zonas reguladas por el SERZ no funcionan
• Funcionalidad de aparcar/des-aparcar no funciona para ningún usuario
• La aplicación tarda más de 60 segundos en responder

El nivel de criticidad “Bloqueante” se encontrará asociado sucesos en la aplicación que no permitirán acceder a sus funcionalidades esenciales y que provocarán que se vea bloqueado el normal funcionamiento del Servicio de Estacionamiento Regulado a través de la App Móvil, bloqueando gran cantidad de operaciones.

Entre estas afecciones principalmente se contemplan:

• Login no funciona
• Aplicación no arranca en una versión puesta al servicio del usuario
• La aplicación tarda en responder más de 180 segundos

Web Pública

La Web Pública o Portal Público estará compuesta por un conjunto de funcionalidades (algunas requerirán identificación de usuario y otras no) que permitirán al Ciudadano consultar datos abiertos, contactar con el servicio de asistencia y operar con los datos que se disponen de él.

En el software se tendrán en cuenta un total de cinco niveles de criticidad: “Bajo”, “Medio”, “Alto”, “Crítico” y “Bloqueante”

El nivel de criticidad “Bajo” será asignado los sucesos que ocurren en una funcionalidad del portal de forma puntual y que permiten seguir operando al usuario sin afección a otras funcionalidades.

Dentro de este nivel se contemplan los siguientes supuestos como ejemplo:

• Usuario no puede realizar recargas o pagos
• Usuario no puede añadir métodos de pago a su listado
• Usuario no puede agregar vehículos a su listado

El nivel de criticidad “Medio” será asociado a los sucesos que se presentan a varios usuarios de forma puntual y/o generan afecciones en algunas otras funcionalidades principales del portal.

Dentro de este nivel se contemplan los siguiente supuestos como ejemplo:

• Varios usuarios no pueden realizar recargas o pagos
• Varios usuarios no pueden añadir métodos de pago a su listado
• Varios usuarios no pueden agregar vehículos a su listado

En el nivel de criticidad “Alto” corresponderá a acontecimientos de carácter recurrente en una funcionalidad de la web que generan afecciones en otras funcionalidades o generan afecciones para muchos usuarios dentro de la aplicación.El nivel “alto” comprenderá incidencias tales como:

• Servicios de información de ocupación del SERZ no funcionan
• Ningún usuario puede dar de alta vehículos o medios de pago a su listado
• No funciona el formulario de contacto
• La página web tarda más de 10 segundos en cargar

El nivel de criticidad “Crítico” corresponderá a sucesos que imposibilitarán la ejecución de funcionalidades de carácter esencial o que no funcionarán correctamente para todos los usuarios.

Entre estas afecciones se encontrarán algunas como las siguientes:

• Mapas de ocupación de las zonas reguladas por el SERZ no funcionan
• No se dispone de acceso a los datos abiertos
• La página con los datos de contacto no está disponible
• La página web tarda más de 60 segundos en cargar

El nivel de criticidad “Bloqueante” se encontrará asociado con el bloqueo de un conjunto de funcionalidades u operaciones que se vea bloqueado el funcionamiento del Servicio de Estacionamiento Regulado a través del Portal Público

Entre estas afecciones principalmente se contemplan:

• Login no funciona
• Página web no carga
• La página web tarda más de 180 segundos en cargar

Web Privada o Portal de Gestión del Servicio

La Web Privada o Portal de Gestión del Servicio será una web de acceso único para la gestión del Servicio de Estacionamiento Regulado y también para la Dirección del Contrato. Contendrá funcionalidades para permitir la correcta gestión y control del conjunto del servicio. Éstas funcionalidades estarán ligadas con la gestión de incidencias, gestión de mapas GIS, y otras definidas en la sección de la Aplicación Web de Gestión del Sistema.

En esta pieza de software se tendrán en cuenta un total de cinco niveles de criticidad: “Bajo”, “Medio”, “Alto”, “Crítico” y “Bloqueante”.

El nivel de criticidad “Bajo” será asignado los sucesos que ocurren en una funcionalidad del portal a un único usuario de forma puntual y que permiten seguir operando al usuario sin afección a otras funcionalidades.

Dentro de este nivel se contemplan los siguientes supuestos como ejemplo:

• Usuario no configurado correctamente
• Una funcionalidad para un usuario le provoca un error de forma recurrente

El nivel de criticidad “Medio” será asociado a los sucesos que se presentan a varios usuarios de forma puntual en alguna funcionalidad y/o generan afecciones en algunas otras funcionalidades principales del portal.

Dentro de este nivel se contemplan los siguiente supuestos como ejemplo:

• Rol de uno o varios usuarios no configurado correctamente
• Una funcionalidad para varios usuarios le provoca un error de forma recurrente

En el nivel de criticidad “Alto” corresponderá a acontecimientos de carácter recurrente en una funcionalidad para todos los usuarios del portal que tienen acceso a esa funcionalidad.

El nivel “alto” comprenderá incidencias tales como:

• Los usuarios no pueden importar mapas GIS
• Los usuarios no pueden acceder al detalle de las incidencias
• El portal tarda más de 10 segundos en cargar

El nivel de criticidad “Crítico” corresponderá a sucesos que imposibilitarán la ejecución de funcionalidades de carácter esencial o que no funcionarán correctamente para todos los roles o perfiles de usuario.

Entre estas afecciones se encontrarán algunas como las siguientes:

• Capa de afecciones urbanas no actualizada
• No se generan los informes
• No se generan los índices de cumplimiento del servicio
• No se permite la gestión de los mapas GIS
• La página web tarda más de 60 segundos en cargar

El nivel de criticidad “Bloqueante” se encontrará asociado con el bloqueo de la mayoría de las funcionalidades que presta el portal, por tanto la afección será de un nivel mayúsculo para la Gestión del Servicio y también la Dirección del Contrato . Entre estas afecciones principalmente se contemplan:

• Login no funciona
• Página web no carga
• La página web tarda más de 180 segundos en cargar