CONTRATO MIXTO DE SUMINISTRO Y SERVICIOS TITULAD O ... · implantación y posterior...

Dirección General de Policía Municipal

S.G .Informática, Comunicaciones y NN.TT.

Avda. Principal, 6 – Ciudad de la Seguridad. Madrid 28011

Sistema de Tratamiento de Emergencias de la PMM Página 1 de 79

CONTRATO MIXTO DE SUMINISTRO Y SERVICIOS TITULAD O “ADQUISICIÓN Y MANTENIMIENTO DEL SISTEMA

DE TRATAMIENTO DE EMERGENCIAS DE LA DIRECCIÓN GENERAL DE LA POLICÍA MUNICIPAL DE MADRID”

Firmado por: JOSE RAMON LLANO LLANOCargo: SUBDIRECTOR INFORMÁTICAFecha: 13-11-2017 10:00:47

Pág

ina:

1 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4

http://www-2.munimadrid.es/VerificacionCove/CotejoCOVE.jsp?codigoVerificacion=PY3e43039f2c66a4


ÁREA DE GOBIERNO DE SALUD, SEGURIDAD Y EMERGENCIAS

Dirección General de la Policía Municipal



PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL CONTRATO MIXTO DE SUMINISTRO Y SERVICIOS TITULADO “ADQUISICI ÓN Y MANTENIMIENTO DEL SISTEMA DE TRATAMIENTO DE EMERGENCIAS DE LA DIRECCIÓN GENERAL DE LA POLICÍA MUNICIPAL DE MADRID”

INDICE

1. INTRODUCCIÓN ........................................................................................................................ 4

2. ANTECEDENTES........................................................................................................................ 4

3. OBJETO DEL CONTRATO ....................................................................................................... 5

4. ALCANCE DEL CONTRATO Y TRABAJOS A REALIZAR ........ ....................................... 6

5. REQUISITOS FUNCIONALES ................................................................................................. 8

5.1. REQUISITOS DEL SUBSISTEMA DE GESTIÓN DE INCIDENTES. .................................................... 9

5.2. REQUISITOS DEL SUBSISTEMA DE TRATAMIENTO DE INCIDENTES EN MOVILIDAD . ................. 23 5.3. REQUISITOS DEL SUBSISTEMA DE TRATAMIENTO DE INCIDENTES DESCENTRALIZADO. .......... 25 5.4. REQUISITOS DEL SUBSISTEMA DE SUPERVISIÓN. .................................................................... 25 5.5. REQUISITOS DEL SUBSISTEMA DE GESTIÓN DE RECURSOS POLICIALES. ................................. 29

5.6. REQUISITOS DEL SUBSISTEMA DE INTERACTUACIÓN CON OTRAS AGENCIAS. ......................... 30

5.7. REQUISITOS DEL SUBSISTEMA DE EXPLOTACIÓN DE LA INFORMACIÓN. ................................. 31

5.8. REQUISITOS DEL SUBSISTEMA DE ADMINISTRACIÓN. ............................................................. 34

6. REQUISITOS DE USABILIDAD ............................................................................................. 39

6.1. REQUISITOS DE INTERFAZ ...................................................................................................... 39

6.2. UTILIDADES ........................................................................................................................... 41

7. REQUISITOS TÉCNICOS DE PLATAFORMA TECNOLÓGICA ..... ............................... 44

7.1. ENTORNO INFORMÁTICO ........................................................................................................ 45

7.2. ENTORNO TECNOLÓGICO DE COMUNICACIONES ..................................................................... 47

8. OTROS REQUISITOS TÉCNICOS Y DE SEGURIDAD ..................................................... 50

8.1. REQUISITOS DE INTEGRACIÓN ................................................................................................ 50

8.2. REQUISITOS DE EXPLOTACIÓN Y MANTENIMIENTO ................................................................. 56 8.3. REQUISITOS DE RENDIMIENTO ............................................................................................... 56

8.4. REQUISITOS DE MONITORIZACIÓN ......................................................................................... 57

8.5. REQUISITOS DE SEGURIDAD Y CONFIDENCIALIDAD ................................................................ 58 8.6. REQUISITOS DE AUDITORÍA .................................................................................................... 58

9. FASES DEL PROYECTO. ........................................................................................................ 59

9.1. PRESTACIÓN 1: IMPLANTACIÓN DEL SISTEMA DE TRATAMIENTO DE EMERGENCIAS DE PMM. 59

9.2. PRESTACIÓN 2: SERVICIOS DE SOPORTE Y MANTENIMIENTO. ................................................ 60


Pág

ina:

2 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







10. ENTREGABLES. ....................................................................................................................... 62

11. SEGUIMIENTO Y CONTROL DE LOS TRABAJOS .......................................................... 63

11.1. ACUERDO DE NIVEL DE SERVICIO (ANS) ........................................................................... 64

11.2. EJEMPLO DE CÁLCULO DE INDICADORES DE NIVEL DE SERVICIO (ANS) ............................. 69

11.3. REQUISITOS DE EQUIPO DE TRABAJO, ENTORNO TECNOLÓGICO Y MATERIAL. ..................... 70

12. CONTROL ECONÓMICO Y FACTURACIÓN .................................................................... 71

13. TRANSFERENCIA TECNOLÓGICA .................................................................................... 72

14. PROPIEDAD INTELECTUAL Y SEGURIDAD .................................................................... 73

15. CONDICIONES DE GARANTÍA ............................................................................................ 73

16. DOCUMENTACIÓN TÉCNICA .............................................................................................. 73

17. CLÁUSULAS SOCIALES ......................................................................................................... 74

18. CONDICIÓN ESPECIAL DE EJECUCIÓN DE CARÁCTER SOCIAL ............................ 75

19. CLÁUSULA DE CONFIDENCIALIDAD ............................................................................... 77


Pág

ina:

3 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA EL CONTRATO MIXTO DE SUMINISTRO Y SERVICIOS TITULADO “ADQUISICI ÓN Y MANTENIMIENTO DEL SISTEMA DE TRATAMIENTO DE EMERGENCIAS DE LA DIRECCIÓN GENERAL DE LA POLICÍA MUNICIPAL DE MADRID” 1. Introducción

El presente documento constituye el Pliego de Prescripciones Técnicas para establecer las condiciones que han de regir la ejecución del contrato para la toma de requisitos, diseño de la solución, instalación, configuración, implantación y posterior soporte-mantenimiento de la Plataforma Tecnológica de Gestión de Operativa de la Dirección General de la Policía Municipal de Madrid.

2. Antecedentes

La Dirección General de la Policía Municipal de Madrid, DGPM, tiene como misión garantizar el derecho de la ciudadanía a una seguridad integral y una respuesta adecuada, en tiempo y medios, a todas las personas y entidades que lo requieran a través de la prestación del servicio de PMM, así como garantizar la mejora continua de la calidad del servicio.

Para ello dispone en la actualidad de un Sistema Integral de Tratamiento de Emergencias, SITE. Dicha plataforma funciona de forma ininterrumpida cubriendo las necesidades técnicas, operativas y de atención al ciudadano ante los requerimientos que deba atender Policía Municipal de Madrid, PMM y los Agentes de Movilidad.

La plataforma SITE de PMM se basa en una aplicación desarrollada a medida en entorno Visual Basic versión 6.0. y con base de datos SQL Server que fue puesta en funcionamiento en el año 2001. Entre sus funcionalidades, además de las propias de una aplicación de Mando y Control de las Emergencias, destacan las de integración con los sistemas de comunicaciones tanto de telefonía como de radio, sistema de grabación, integración con el sistema de recursos humanos, etc.

Si bien durante estos años se han ido efectuando las pertinentes evoluciones tecnológicas y operativas en el centro, en la actualidad está en fase de no evolución, realizándose tan solo un mantenimiento correctivo para corregir cualquier problema o error en la misma.

La evolución tecnológica ha dado lugar a que sea muy complicado mantener este tipo de aplicaciones por estar descatalogadas las herramientas y software base en las que se sustentan, como es la versión de entorno de desarrollo Visual Basic, la versión de Windows para las que se desarrollaron o la propia base de datos.

Lo indicado anteriormente imposibilita por tanto cubrir requisitos que hoy en día son necesarios así como cualquier mejora o evolución tecnológica, tan necesaria después de los años que ha prestado servicio y el cambio de panorama tecnológico y necesidades actuales. Sirva de ejemplo no tener integrado un sistema GIS o no poder ser desplegada en entorno de movilidad tipo tablet, tan útil para el cuerpo de PMM.

Para cubrir las necesidades y retos que se presentan ante los requisitos tecnológicos, funcionales y operativos y para hacer frente a las exigencias y demanda existente del servicio de PMM de la ciudad de


Pág

ina:

4 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Madrid, se requiere un proceso de renovación y modernización de la plataforma tecnológica de gestión de Emergencias, cubriendo requisitos actuales y nuevos que se expondrán en este pliego y se detallarán en la fase de análisis inicial del proyecto.

3. Objeto del contrato El objeto de la presente contratación mixta de suministro y servicios para realizar un proyecto llave

en mano y su posterior mantenimiento para la puesta en marcha de un nuevo Sistema de Tratamiento de las Emergencias que dará soporte a los servicios que presta la Policía Municipal de Madrid al ciudadano y a otros organismos municipales de emergencia que se pudieran integrar.

A nivel general, los objetivos que se persiguen con este contrato se resumen en los siguientes puntos:

• La renovación del actual sistema de gestión de requerimientos ciudadanos que da soporte al Centro de Gestión de Emergencias de PMM.

• Producto de gestión operativa, del software de base y de los servicios profesionales para realizar la toma de requisitos, diseño de la solución, instalación, configuración y adaptación, implantación y posterior soporte-mantenimiento de todos los elementos solicitados en este pliego.

• Obtener un entorno tecnológico en el Centro de Gestión de Emergencias de PMM basado en criterios y capacidades de fiabilidad, alta disponibilidad, robustez, redundancia, tolerancia a fallos, interoperabilidad, cooperación, escalabilidad y evolución que garanticen desde el primer día la mejora continua del servicio actual, tanto en sus aspectos operativos como de percepción ciudadana, y suponga concentrar más y mejores servicios de atención al ciudadano en el ámbito de las competencias de la Policía Municipal de Madrid.

Dará soporte a los procesos operativos diarios de gestión de las peticiones de servicio recibidas a través del número 092 y cualquier otro de los canales que la ciudadanía pueda utilizar para acceder a los servicios de la PMM, permitiendo un esquema de trabajo integrado con el resto de organismos que participen en la gestión de la emergencia, como pueda ser el 112, Samur o Bomberos de Madrid.

Deberá atender todas las llamadas recibidas en el teléfono de atención de emergencias de PMM en tiempo y forma y, para asegurar esto, será imprescindible verificar la correcta integración de las comunicaciones tanto en las llamadas entrantes de los ciudadanos para comunicar sus incidencias como para las llamadas salientes (radio y telefonía) hacia los recursos y/o organismos que intervendrán en la gestión de dichas incidencias.


Pág

ina:

5 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







4. Alcance del contrato y trabajos a realizar El alcance del presente contrato incluye las tareas genéricas de toma de requisitos, diseño de la

solución, instalación, configuración, parametrización, implantación, formación, puesta en marcha y posterior soporte-mantenimiento de los elementos necesarios, así como cualquier otra tarea necesaria para cubrir las funcionalidades actualmente disponibles y otras nuevas que se pasan a describir:

• Análisis funcional completo de requisitos que complete y detalle los expuestos en el presente Pliego de Prescripciones Técnicas, y la matriz de ajuste de funcionalidades.

• Diseño de la solución propuesta que complete y la definición de entornos diferenciados de pruebas, producción y respaldo.

• Equipos y licencias, y su instalación, configuración, administración, soporte y mantenimiento de la plataforma hardware y software de base correspondiente a los diversos servidores necesarios para implantar la solución propuesta: servidores de bases de datos incluidos el SGBD, servidores de aplicaciones, servidores web, servidores GIS, balanceadores de carga, backup, ampliación del sistema de almacenamiento, etc.

• Preparación de entornos separados de preproducción/pruebas/formación, de producción y de respaldo, acordes a la solución propuesta.

• Se podrán configurar los puestos para acceder a cualquiera de los entornos de producción, pruebas o respaldo en función de los permisos y privilegios necesarios.

• Creación de un prototipo software y realización de pruebas con los usuarios o responsables de aceptación de las mismas, previas a las puestas en producción.

• Servicios de formación y transferencia tecnológica:

o A nivel de usuario para los operadores de sala, supervisores y responsables de PMM para el correcto uso de la nueva plataforma.

o A nivel técnico para los servicios técnicos de la DGPM sobre labores básicas de administración y configuración, sobre el modelo de datos a utilizar para la explotación de información y para dar un soporte de nivel 1 en caso de incidencias.

• Las tareas necesarias para la instalación, configuración, puesta en marcha, soporte y mantenimiento de los puestos de operador en el centro principal y de respaldo, así como en unidades de distrito, unidades especiales o puestos en movilidad.

• Servicios que garanticen la utilización de las plataformas hardware y software existentes y no sustituidas, tanto del centro principal como del centro de respaldo, y la integración e interoperabilidad con los sistemas y organismos con los que actualmente se está integrado para el tratamiento de las emergencias:

o Servidores y equipamiento de red.

o Puestos de operadores de telefonía y de radio, y puestos de supervisores de sala.

o Directorio Activo.

o Sistemas de comunicación de radio y telefonía.

o Sistema de grabación.

o Sistema de Emergencias 112.

o Sistemas de Emergencias de Samur y bomberos.

o Aplicaciones de PMM: Recursos Humanos, Conformación de patrullas, Planificación de los servicios, Partes de Intervención, Incidente Único, Módulo de Consultas de Perfiles


Pág

ina:

6 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Altos, etc.

o GIS corporativo y Base de Datos Ciudad (en adelante BDC) del Ayuntamiento de Madrid. El GIS de la plataforma a desarrollar deberá ser compatible con la tecnología de ESRI, que es la empleada en el Sistema de Información Geográfica Corporativo del Ayuntamiento de Madrid (SIGMA). Esto implica que el GIS de la plataforma deberá poder consumir la cartografía oficial del Ayuntamiento en su formato original, tal como es consumida por SIGMA.

o Almacén de datos corporativo Datawarehouse.

Estará dentro del alcance de contrato y se planteará dentro de la solución propuesta cualquier adaptación o desarrollo a medida que precise la nueva plataforma para conseguir las integraciones indicadas.

• Proceso de migración desde la plataforma actual a la nueva, de forma que se garantice la prestación ininterrumpida del servicio de recepción y gestión de llamadas, y tratamiento de emergencias; incluyendo un plan de contingencia que deberá ser aprobado por esta Dirección General de la Policía Municipal.

• De cara a futuras ampliaciones, el sistema dispondrá de capacidad de escalabilidad dentro del ámbito de PMM, pero también capacidad multiagencia para poder ser ampliado a otros organismos o cuerpos de seguridad y emergencias.

• Capacidad de integración con otras agencias para recibir y enviar información, así como para poder mostrar en el mapa incidentes propios y de otras agencias.

• Solución para la prevención, planificación y gestión de crisis orientada a Planes de Emergencia.

• Servicios de soporte y mantenimiento de 2 años a contar desde la puesta en producción definitiva de la plataforma, de toda la infraestructura y de sus integraciones.

• Tareas relacionadas con la gestión, control y seguimiento de los trabajos:

o Gestión de proyecto.- Se hará seguimiento y actualización del Plan de Proyecto en los plazos, tareas y recursos humanos y materiales. En caso de desvío de la planificación en más de 15 días presentará un Plan de Actuación con medidas para contrarrestar dicho desvío.

o Gestión y control de la configuración y la documentación de los diferentes elementos, tanto de los actuales a sustituir como de los nuevos que se vayan sustituyendo, utilizando para ello una herramienta consensuada entre la empresa adjudicataria y la Dirección Técnica de la DGPM, así como el control de versiones mediante Subversion.

o Control de calidad.- El Responsable Técnico de la DGPM podrá realizar o delegar para que se realicen actuaciones de control de calidad de los entregables, que permitan evitar errores y conocer el cumplimiento de los estándares a los que estarán sometidos los entregables.

o Gestión de cambios.- Cualquier cambio en los requisitos o modificación ocasionada por cualquier otro motivo, y que ocasione cambios no previstos ha de ser registrado y gestionado dentro de la planificación del proyecto, dando lugar a la actualización de los documentos o entregables correspondientes, tales como análisis de requisitos, configuración, pruebas, etc.

o Gestión de Incidencias.- Dentro del soporte a usuarios y en el transcurso de todo el contrato, especialmente en el soporte y mantenimiento, se pueden originar incidencias que den lugar o no a cambios. En cualquier caso se ha de llevar un registro de las mismas con


Pág

ina:

7 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







la información relacionada como es fecha de apertura y de cierre, persona de contacto, prioridad o relevancia, descripción, actuación/resolución adoptada, etc.

La prestación de los trabajos y servicios relacionados con el diseño, implantación, soporte y mantenimiento de la nueva plataforma han de seguir los estándares municipales proporcionados por IAM y por la DGPM con el objeto de poder garantizar su futuro mantenimiento.

Cualquier elemento hardware así como las herramientas y tecnologías de desarrollo empleadas se deberán adecuar a lo indicado en la Guía de Estándares Tecnológicos del IAM publicada en el portal del Ayuntamiento de Madrid.

5. Requisitos Funcionales Este apartado tiene por objeto la descripción detallada de los requisitos funcionales que deberá cubrir el Sistema de Tratamiento de Emergencias que de soporte al servicio de PMM. No obstante y según se define en el alcance y apartado correspondiente de fases del contrato, será necesario el correspondiente análisis funcional para revisar y ampliar en lo necesario estos requisitos.

La gestión de este servicio implica disponer tanto de sistemas de información y comunicaciones como herramientas de apoyo al trabajo del personal de PMM. Con el fin de estructurar este sistema se ha dividido en los siguientes subsistemas atendiendo a las tareas que se deben realizar:

• Subsistema de Gestión de Incidentes.- Gestiona el ciclo de vida de los incidentes, desde su creación y cambios de estados hasta su cierre.

• Subsistema de Tratamiento de Incidentes en Movilidad.- Permite a los agentes de los patrullas recibir y enviar información relativa a los incidentes en los que intervengan así como de la actuación realizada en dicha intervención.

• Subsistema de Tratamiento de Incidentes Descentralizado.- Permite la supervisión y tratamiento de incidentes desde la Unidades de PMM, con funcionalidades similares a las del Subsistema de Gestión de Incidentes, aunque sin interferir con éste, de tal forma que tales Unidades no podrán tratar ni intervenir en aquellos sucesos gestionados por el órgano central de gestión de incidentes en Policía Municipal (CISEM).

• Subsistema de Supervisión.- Permite monitorizar la sala y los puestos de operador, así como la toma decisiones sobre la forma en que los incidentes deber ser gestionados. También establece la forma en la que se generarán alertas y avisos a los diferentes perfiles (supervisores, operadores y patrullas) ante ciertas situaciones.

• Subsistema de Gestión de Recursos Policiales.- Determina los patrullas que están operativos y las tareas que tienen planificadas.

• Subsistema de Interactuación con otras Agencias.- Define la información que se ha de compartir con otras agencias como Emergencias o el 112 para la gestión de los incidentes.

• Subsistema de Explotación de la Información.- Permite extraer información, estadísticas y monitorizar información a partir de los indicadores predefinidos.

• Subsistema de Administración.- Incluye todas las tareas de mantenimiento de puestos, usuarios, estados de incidentes, catálogo de incidentes, ficheros de traza, etc.


Pág

ina:

8 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







En los siguientes subapartados se describen los requisitos básicos de cada subsistema.

5.1. Requisitos del Subsistema de Gestión de Incidentes . El subsistema de Gestión de Incidentes deberá contemplar toda la información y campos requeridos en las llamadas, cartas de servicio e incidentes para su gestión, tratamiento y toma de decisiones, así como cualquier otro dato utilizado actualmente en los sistemas y aplicaciones del Servicio de PMM, tal y como se describen en este apartado.

Este subsistema ha de cubrir el ciclo de vida, fases y estados por los que pasa tanto una llamada como un incidente.

Denominamos “llamada” a cada una de las comunicaciones entre un punto externo y el servicio de PMM. Esa comunicación puede ser telefónica o puede ser telemática. En cualquier caso, la llamada necesitará de un proceso de evaluación y resolución decisión de si actuar o no, y cómo actuar.

Denominamos “incidente” a todo suceso o situación sobrevenida que necesite la actuación de la Policía Municipal de Madrid. Según esta definición y las situaciones descritas en el párrafo anterior, podemos decir que una llamada no siempre provoca la creación de un incidente.

El ciclo de vida de un incidente se divide en tres fases: creación, seguimiento y cierre.

5.1.1. Fase de Creación. Esta es la fase en la que se recibe una solicitud de presencia de efectivos de PMM. Las vías por las que se puede recibir son:

• Se recibe una llamada en el 092.

• Se recibe una “carta de llamada”. Las “cartas de llamada” son peticiones de servicio que se reciben desde puntos externos, como el 112 de la Comunidad de Madrid.

• Se recibe una petición de servicio desde otra agencia integrada en CISEM: Samur y bomberos.

• La propia PMM determine la necesidad de actuar. Por ejemplo en estos casos:

o Un patrulla detecta algo en su labor de patrullaje.

o Un ciudadano contacta con cualquier patrulla que se encuentra de servicio.

o Como resultado de otras tareas como por ejemplo de video-vigilancia


Pág

ina:

9 d

e 79

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Se recibe una petición de servicio desde otra agencia u organismo a través de llamada telefónica (no 092). Como ejemplo de agencias no integradas serían Selur, Guardia Civil, Policía Nacional.

• Un ciudadano recurre a una de las líneas de atención especializada que ofrece PMM, como por ejemplo una app específica.

• Alarmas de organismos o colectivos externos como por ejemplo de joyeros.

Un incidente se va a crear cuando sea necesaria la intervención de Policía Municipal. Las formas de creación posibles serán:

• Creación manual de un incidente.- Un operadorRadio será en la mayoría de los casos quien realice este tipo de creación. Un incidente se creará de forma manual en los siguientes casos:

o Un patrulla alerta de un incidente determinado y lo comunica vía radio a Emisora

o Se recibe una petición de servicio desde una agencia u organismo que no está integrado en la Plataforma de Tratamiento de Emergencias. Por lo normal la comunicación es vía telefónica pero usando números distintos al 092.

o Un grupo de video vigilancia, por ejemplo, detecta por las cámaras alguna situación en la que es necesario que acuda un patrulla PMM.

El operadorPMM dispondrá de una pantalla para crear un nuevo incidente en el que deberá introducir los siguientes datos:

- Anotar quién realiza la petición de servicio.

- Conocer lo que sucede y anotar la información relevante.

- Ubicar el incidente.

- Tipificar el incidente.

• Creación automática de un incidente.- En estos casos, ningún operadorPMM interviene en el proceso de creación. Los datos facilitados en las comunicaciones telemáticas deberán ser los suficientes como para poder cumplimentar la información necesaria descrita en el punto anterior.

• Creación programada de un incidente.- Se plantea la posibilidad de programar o planificar un incidente como consecuencia de un evento, que se genere automáticamente con una localización, tipificación, descripción y un plazo o fecha de activación. Cuando se cumpla el plazo o fecha de activación se activará automáticamente la creación de una “carta de llamada propia de PMM” que se asignará a un operador en función de sus datos. Este tipo de eventos podrán ser planificados como periódicos o puntuales.

El personal de PMM se organiza de forma que existe un grupo de operadores destinado a atender las llamadas, “operadorTeléfono”, y un segundo grupo encargado del seguimiento de los incidentes una vez se han creado, “operadorRadio”. Ambos grupos tienen la capacidad de crear un incidente.

En la sala de telefonía existe un número de puestos de “operadorTeléfono”. Todas las llamadas se reciben a través de una centralita telefónica que balancea la carga de llamadas recibidas en cada puesto.

Cuando se reciba una llamada en un puesto, el operadorTeléfono descuelga y se inicia la conversación con el llamante. A través de dicha conversación el operador deberá:

• Identificar al llamante.- Es necesario conocer el teléfono desde el que llama, así como su identidad y ubicación en caso ser posible. La aplicación debe ser capaz de recoger la información


Pág

ina:

10

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







de identificación del número desde el que se está realizando la llamada (ANI) y debe ser capaz de gestionar la información ALI que permita conocer de forma automática la ubicación del llamante.

También ha de permitir tipificar al llamante según anteriores llamadas que se hubieran recibido y mostrar el historial e información de esas llamadas o incidentes asociados. El sistema debe estar preparado para definir un conjunto de llamantes y catalogarles según criterios establecidos, como puedan ser organismos públicos, agencias de emergencias, etc.

• Conocer lo que sucede y anotar la información relevante.- Dependiendo de lo que el llamante cuenta el operador necesitará preguntarle sobre detalles de forma que la información recogida sea lo más completa posible. Toda aquella información que sea relevante deberá ser anotada.

La aplicación deberá permitir definir plantillas con lista de preguntas o guiones que faciliten al operador, si así lo requiere, realizar preguntas al llamante en función del tipo de incidente u otros datos.

• Ubicar el incidente.- El operadorTeléfono debe disponer de opciones para ubicar la dirección postal (calle, número, portal, piso, puerta) por calle y número o calle sin número, cruce de dos calles, punto singular de la ciudad o marcar la ubicación en un mapa. Esta información debe estar codificada de forma que sea posible la geolocalización del incidente. También para determinar en qué parte de la ciudad se está produciendo de forma que su seguimiento y atención se realice por los efectivos adecuados. El mapa debe tener definidos los límites de distritos para la correcta asignación de unidad. Además de la información anterior, se dispondrá de un texto en el que el operadorTeléfono puede introducir información importante (dirección ampliada) para ubicar el incidente y que no es posible hacerlo con los sistemas mecanizados anteriores.

• Tipificar el incidente.- Una vez conocido lo que sucede es necesario tipificar el incidente de forma que se inicie el protocolo a seguir para ese tipo de incidente. El sistema deberá permitir introducir el tipo de incidente de forma directa y facilitar un sistema ágil para seleccionar el correcto entre los existentes en un catálogo actualizable.

Cada código se podrá catalogar en 3 distintos niveles de gravedad, pudiéndose preasignar una determinada planificación de servicios distinta para cada uno de esos niveles.

Con independencia de lo anterior, el operador tendrá la posibilidad de definir el servicio como PRIORITARIO o NO PRIORITARIO, a través de una casilla específica, (que tendrá que ser obligatoriamente cumplimentada para poder continuar el proceso), derivándose determinadas consecuencias posteriores, que podrán implicar una gestión o tratamiento diferenciado.

• Determinar incidentes próximo.- El sistema deberá detectar de forma automática en función de la cercanía, que será configurable, y de la tipificación, si existe un incidente próximo para que el operadorTeléfono determine si la llamada se refiere a ese incidente y asociarla a él. En tal caso el sistema mostrará al operadorTeléfono los incidentes próximos existentes con los datos relevantes como son la fecha y hora de creación del incidente, distancia, estado, etc.

• Resolver.- Una vez introducida toda la información facilitada por el llamante, y tipificado el incidente, el operadorTeléfono deberá decidir qué hacer. Para ello deberá disponer de información complementaria que le ayude a tomar la decisión:

o Deberá conocer si existen llamadas anteriores recientes o no de ese mismo número de teléfono, siendo parametrizable el plazo o periodo de comprobación.

o Podrá conocer si desde ese mismo número de teléfono se han recibido llamadas inoportunas (bromas, etc.).

o Deberá conocer si existe un incidente que coincida con la llamada en curso pero causado


Pág

ina:

11

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







por la llamada de otro llamante o agencia. Por ejemplo, conociendo los incidentes que se han producido en un tiempo cercano en una ubicación cercana a la ubicación del incidente de la llamada en curso.

Las posibles formas de resolver serán al menos las siguientes:

- Cuando la llamada no ha supuesto ningún tipo de actuación (se ha cortado, errónea, etc.), no se crea el incidente y la llamada se cierra como “Llamada errónea”.

- Cuando la llamada no proceda por no ser el asunto competencia de PPM. No se traslada la incidencia a Sala ni a ningún otro servicio. Cierre como “No procede”.

- Cuando la llamada ha supuesto que el operadorTeléfono realice alguna tarea de información al ciudadano sin más actuación. No se crea el incidente y la llamada se cierra como “Consulta ciudadana”.

- Cuando la llamada supone una actuación administrativa del operadorTeléfono, sin precisar el envío de un patrulla. Por ejemplo, se llama a algún organismo externo a emergencias para solventar el problema. Una vez finalizada la actuación administrativa la llamada se cierra como “Solucionado en 092”. Este tipo de cierre deberá generar un incidente ya cerrado. Deberá cumplirse todos los requisitos de cierre de incidente que se describirán a lo largo del documento.

- Cuando la llamada implica el envío de un patrulla. La llamada se resuelve como “Enviar patrulla” o “Enviar a radio” . En este caso se cierra la llamada y se crea un incidente a partir de la llamada.

- Cuando la llamada es una segunda llamada de un mismo llamante que insiste. El operadorTeléfono asociará la llamada al incidente ya creado y la llamada quedará cerrada. La información recabada en la llamada se acumulará al incidente. “Llamada reiteración”. Si el incidente ya está cerrado dará la opción de reabrirlo.

- Cuando el operador detecta que la llamada en proceso se corresponde con un incidente ya creado por la llamada de otro llamante. El operadorTeléfono asociará la llamada al incidente existente. La información recabada en la llamada se acumulará al incidente. “Asociar llamada”. Si el incidente ya está cerrado dará la opción de reabrirlo si la historia del incidente lo permite.

- Es posible que la llamada sea para informar de la desaparición de la causa que originó el incidente. En este caso el operadorTeléfono asociará la llamada al incidente existente y se cierra. La información recabada en la llamada se acumulará al incidente. “Llamada anulación”.

Hay ocasiones en que la urgencia es tal que es necesario adelantar el envío del patrulla al cierre de la llamada. El operadorTeléfono deberá poder pasar el incidente al operadorRadio para que envíe un patrulla mientras sigue en conversación con el llamante. En este caso se inicia un proceso con varios pasos posibles:

El operadorTeléfono seleccionará “Anticipar patrulla”. Se creará un incidente pero la llamada no quedará cerrada. El operadorTeléfono podrá seguir incluyendo anotaciones en la misma llamada que serán remitidas a los operadoresRadio con “Actualizar” . Para finalizar la llamada pulsará “Cerrar llamada”.

Dependiendo del tipo de incidente es posible que sea necesaria la presencia de otras agencias en el incidente. El sistema deberá proponer las agencias susceptibles de ser avisadas atendiendo a una planificación establecida. El operadorTeléfono tendrá la decisión final sobre qué agencias son las que deben ser avisadas. En el caso de agencias no integradas de forma telemática, el operadorTeléfono deberá


Pág

ina:

12

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







avisar utilizando el procedimiento establecido entre agencias, por ejemplo por teléfono que muestre y al que permita llamar el sistema.

El sistema deberá proponer al operadorTeléfono o asignar automáticamente atendiendo a un conjunto de reglas establecido cual es el puesto de operador de radio al que se va a remitir el incidente para su seguimiento. El operadorTeléfono tendrá la capacidad de poder cambiar el puesto propuesto.

Cartas de llamada Las “cartas de llamada” son peticiones de servicio que se reciben desde puntos externos. Las cartas de llamada se depositarán en un buzón de entrada y serán recogidas por un operadorTeléfono, que revisará, tipificará y resolverá como si de una llamada se tratase.

El sistema permitirá que las cartas de llamada sean recibidas a través de un webservice o de XML según se expone en el apartado de requisitos de integración, y habilitará un formulario específico para su cumplimentación y envío.

Cartas de llamada desde el 112 Cuando un ciudadano llama al 112 (servicio de emergencias de la Comunidad de Madrid) el operador del 112 realiza las mismas tareas que el operadorTeléfono, pero en el caso de resolver no decide si enviar un patrulla, sino que resolverá remitiendo el aviso a la/s agencia/s competente/s. Cuando el aviso se dirige a PMM, se genera una carta de llamada y se remite por medios telemáticos al CISEM. Los datos que se remiten son los mismos que se recogerían en el caso de una llamada telefónica.

El sistema de Tratamiento de Emergencias ha de permitir recibir estas cartas de llamada por un operadorTeléfono a través de un buzón de entrada que actualmente llega en formato XML. El operador accede a la carta de llamada, revisa los datos, tipifica la llamada y resuelve de la misma forma que si fuese una llamada más al 092.

Cartas de llamada desde otras agencias de Emergencias El sistema de Tratamiento de Emergencias ha de permitir recibir cartas de llamada de las agencias de SAMUR, bomberos y Movilidad del Ayuntamiento de Madrid. Actualmente esta información se recibe a través de sistema de Incidente Único de CISEM.

Cartas de llamada desde dispositivo móvil de un ciudadano Se permitirá que un ciudadano envíe al sistema una carta de llamada desde un dispositivo móvil tipo Smartphone a través de una app. La app deberá enviar la información mínima requerida para poder abrir una carta de llamada incluida la posición (X, Y), previa validación de la conexión por parte del sistema de Tratamiento de Emergencias para evitar ataques indiscriminados de denegación de servicio u otros tipos de ataques.

La forma de recibir la información en el sistema de Tratamiento de Emergencias de PMM será en principio vía webservice y permitirá la interacción o comunicación con el demandante del servicio.

5.1.2. Fase de Seguimiento Una vez se ha determinado que es necesario enviar un patrulla al lugar del incidente, todo lo que suceda hasta que el incidente se resuelva y se cierre forma parte de la fase de seguimiento.


Pág

ina:

13

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







En esta fase primero se designará qué patrulla de las disponibles es la que se encargará de atender el incidente. Es posible que a lo largo del esta fase sea necesario enviar más patrullas o requerir los servicios de otras agencias.

En esta fase de seguimiento el operador de radio deberá ofrecer apoyo al patrulla y recabar y ofrecer la información necesaria.

Es posible que se inicie la fase de seguimiento sin que haya finalizado la fase de Creación. Son los casos en lo que mientras el operador telefónico sigue atendiendo la llamada, pasa nota a los operadores de radio para que vayan enviando un patrulla por tratarse de una emergencia.

A lo largo de su ciclo de vida un incidente pasa por distintos estados dependiendo de las decisiones que toman los operadores o de los acontecimientos que suceden. Atendiendo a todo lo descrito hasta ahora se puede diseñar un diagrama que describa los estados de un incidente y las transiciones posibles entre estados:


Pág

ina:

14

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Los “canales de radio” y los “operadores de radio” El medio de comunicación con los patrullas es la radio. Dada la cantidad de patrullas en servicio y la cantidad de incidentes simultáneos que se pueden dar, es necesario organizar un medio de comunicación que funciona en modo broadcast (todos con todos) y con un acceso en exclusión mutua (sólo puede hablar uno a la vez). Para afrontar este problema se ha establecido un conjunto de canales de radio.

Todas los patrullas de una misma unidad deben comunicarse entre sí. En cada unidad existe una emisora, denominada “Ferrolnn” (donde nn es un valor numérico), utilizada para las comunicaciones entre la unidad y sus patrullas.

Según lo anterior podemos establecer una relación entre unidades y canales de radio de forma que


Pág

ina:

15

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







todas los patrullas de una unidad y el ferrol usarán el mismo canal de radio para comunicarse. Diremos que “la unidad tiene asignado un canal de radio”.

Por cuestiones de eficiencia, es posible que varias unidades tengan asignado el mismo canal de radio. Los criterios de determinan asignación de canal de radio son variados: geográficos, volumen de incidentes, tipo de unidad.

Para que pueda comunicarse con los patrullas de una unidad es necesario que acceda al canal de radio asignado a dicha unidad. Esta labor la realizan los “operadores de radio”, operadorRadio, desde su “puesto de operador de radio”. Los puestos de operador de radio son los que tienen asignado uno o varios canales de radio, independientemente del operadorRadio que ocupe el puesto. La relación entre puestos de operador de radio y canales de radio es lo que denominamos “mapa de canales de radio” que se podrá configurar o definir según se indica en el Subsistema de Supervisión y que figura más adelante en este documento.

El mapa de canales varía dependiendo del turno y del día de la semana. Se contempla la posibilidad de que un mismo canal de radio sea gestionado por más de un operadorRadio al mismo tiempo.

Gestión de patrullas disponibles El inventario de patrullas disponibles y sus tareas planificadas es gestionado por dos aplicaciones externas al sistema de Tratamiento de Emergencias en cuestión, denominadas Asignación y Planificación de CISEM, y que deberán integrarse según el apartado de “Requisitos de Integración”. El día o días previos al servicio las distintas unidades introducen en esas aplicaciones externas los patrullas que van a estar en servicio y las tareas que tiene planificadas cada patrulla para ese día y turno. Al inicio del servicio en cada turno las Unidades validan la previsión realizada y dicha información vuelca a la herramienta de gestión de incidentes.

Cuando empieza el turno, cada patrulla trabaja en el ámbito territorial habitual en sus tareas programadas. Pero es posible que por necesidades de servicio algún patrulla tenga que agregarse a una unidad como refuerzo. Es necesario que se pueda agregar un patrulla a una unidad. A partir de ese momento ese patrulla aparecerá en la relación de patrullas disponibles que puedan atender los incidentes propios de esa unidad.

Asignación de patrulla Una vez se ha creado el incidente, el primer paso que se da es la asignación del recurso de un patrulla de forma que se le comunique la existencia del incidente para que se persone en el lugar.

Para poder asignar el patrulla es necesario que el operadorRadio conozca los patrullas que tiene en servicio, el estado de disponibilidad de cada una y su situación en el mapa. Los estados en los que se puede encontrar un patrulla son al menos los siguientes:

• Disponible: El patrulla está realizando alguna actividad que puede dejar de hacer para atender un incidente.

• No disponible: El patrulla está realizando una actividad que no le permite atender un incidente

• Asignado: El patrulla está atendiendo a un incidente pero todavía no ha llegado al lugar.

• En destino: El patrulla está atendiendo a un incidente y ya se encuentra “en el punto”.

• Meseta: El patrulla se encuentra en su descanso reglamentario.


Pág

ina:

16

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Un incidente se puede asignar a un patrulla cuando la patrulla se encuentra en los siguientes estados: Disponible, Asignado, Ocupado y En destino. En los dos últimos casos el incidente se pondrá en cola y será atendido cuando el patrulla finalice con el incidente en curso o deje de estar asignado a él.

Dependiendo de la gravedad o dimensión del incidente, el operadorRadio podrá asignar más de un patrulla al mismo incidente. El incidente no podrá finalizarse hasta que todos los patrullas asignados a él dejen de estarlo, pudiéndose visualizar de una manera ágil todos los indicativos que estén asignados a una misma incidencia.

El operadorRadio podrá poner a los patrullas en estado de meseta. La duración de la meseta sea un valor configurable. Cuando el patrulla se reincorpora al servicio contacta con el operadorRadio para que vuelva a tenerla como “Disponible”. El sistema deberá alertar al operadorRadio que un patrulla ha superado el tiempo máximo de meseta y todavía no se ha reincorporado al servicio.

El tiempo que se pueda dar de margen deberá ser configurable. Es posible que un patrulla tenga que interrumpir su descanso para poder atender un incidente. En un momento posterior el patrulla podrá disfrutar del tiempo de descanso pendiente. El sistema debería tener en cuenta la posibilidad de que un patrulla puede disfrutar de su meseta en varios periodos con vistas a controlar el tiempo y a disparar la alerta comentada en el párrafo anterior.

La asignación de patrullas se realiza atendiendo a una serie de criterios utilizados para proponer de forma automática al operadorRadio:

• Si el incidente está localizado en un área geográfica asignada a una unidad deberá acudir preferentemente un patrulla de dicha unidad. Definimos “área geográfica” como una extensión geográfica de la ciudad que puede abarcar uno o varios barrios y cuya forma puede ser variable, y sirve para determinar los patrullas que van a atender los incidentes producidos en esa área y para analizar los incidentes que se producen en el área geográfica. Como ejemplo de área tenemos los distritos de la ciudad de Madrid, “Madrid Rio”, “M-30” y “La Casa de Campo”.

• Un incidente será atendido por un patrulla del distrito policial que geográficamente le corresponda.

• Se plantearán diferentes opciones a la hora de asignar patrullas a un incidente, proponiendo el sistema la asignación del que se encuentre más próximo o el que pueda llegar antes al incidente, dependiendo de las circunstancias concurrentes. En todo caso, el operador ha de tener opción para aprobar dicha propuesta o elegir cualquier otro indicativo que considere conveniente.

Antes de cada turno, cada patrulla tiene planificada una serie de tareas que debe realizar. Esta asignación de tareas se realiza desde las aplicaciones de gestión de recursos policiales Planificación y Asignación de CISEM, ajenas al sistema que estamos analizando. Algunas tareas planificadas son incompatibles con la disponibilidad del patrulla para atender incidentes. El operadorRadio debe tener conocimiento de estas tareas planificadas en pantalla puesto que en algunas ocasiones puede condicionar el proceso de asignación de patrulla.

Se contemplará la posibilidad de que cuando el operadorRadio asigne el incidente a un patrulla, si el ciudadano llamante es un interesado del incidente, y el teléfono de contacto es un móvil, el sistema pueda remitir un SMS al ciudadano informando que un patrulla se pone en camino hacia el lugar del incidente si así se considera conveniente por parte del servicio.

Si el equipamiento del patrulla lo permite se remitirá a dicho patrulla toda la información posible según se indica en el Subsistema de Tratamiento de Incidentes en Movilidad.


Pág

ina:

17

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







A petición de la patrulla, el operadorRadio podrá remitir también un mensaje con la recomendación de itinerario a seguir por el patrulla para llegar al lugar del incidente.

Enviar a otro puesto de operador de radio Puede que un incidente inicialmente esté mal localizado y al localizarlo correctamente corresponda atenderlo a una unidad gestionada desde otro puesto de operador de radio. También será posible que, una vez conocido mejor el detalle, un incidente deba ser atendido por un patrulla de una unidad especializada, entonces el incidente deberá remitirse al puesto y cambiarse al canal correspondiente.

Cuando un operadorRadio cambie de canal a un incidente, el incidente deberá llegarle al buzón de entrada del operadorRadio del canal de destino.

Llegada del incidente al puesto de operador de radio Dependiendo de la localización del incidente o del tipo de incidente éste deberá ser atendido por un patrulla de una unidad u otra. Al conocer el canal por el que esa unidad se comunica se sabrá el puesto, o puestos, de operador de radio con capacidad de hacer el seguimiento de dicho incidente. A todos ellos se les activará una alerta que indique que tiene un incidente sin leer. En el caso de haber más de un incidente sin leer se mostrarán ordenados por orden de prioridad o de urgencia según se configure, de forma que sea atendido antes el más prioritario.

El operadorRadio deberá acceder a los datos del incidente recién llegado y, atendiendo a la información leída, decidirá qué hacer con él.

Una vez el patrulla informe de la finalización de sus actuaciones y el operador valide las mismas ordenará retirarse al indicativo y el incidente se cerrará.

Estado de espera El estado de espera se utiliza para las situaciones en que es necesario realizar alguna gestión de investigación por parte del operador de radio antes de asignar un patrulla, o aquellas en las que el patrulla asignada tiene que esperar a algo que debe suceder ajeno al patrulla para poder seguir.

Como ejemplos tenemos el caso en que la ubicación del incidente es ambigua y el operadorRadio deba concretar mejor. Para ello buscará en el mapa, en el callejero o podrá llamar al “llamante” para que concrete mejor la ubicación. En otras ocasiones se trata de la situación en la que un patrulla va a hacer una inspección y el propietario no está y llegará en un plazo de tiempo, la patrulla abandona el lugar y regresará en el tiempo establecido.

Por tanto debe ser posible poner un incidente en estado de espera y sacarlo de dicha estado.

Que un incidente se ponga en espera no deberá tener ningún efecto en el cómputo de tiempos de respuesta que se deben cumplir.

Anotar llegada de patrulla al punto Es necesario realizar un control y gestión de los tiempos, y para ello registrar el momento en el que el patrulla cambia de un estado a otro, al igual que el resto de acciones relacionadas con el tratamiento de los incidentes, como por ejemplo cuando se encola un incidente en un canal determinado o cuando cambia de un canal a otro en caso de hacerse.

Se mostrará al operadorRadio el momento en el que el patrulla llega al lugar del incidente, “en el


Pág

ina:

18

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







punto”.

La mayoría de patrullas lleva un sistema de posicionamiento GPS instalado en el vehículo o integrado en la emisora. El sistema debería ser capaz de anotar de forma automática la llegada al punto del patrulla utilizando dicho sistema de posicionamiento.

Hay patrullas que no disponen de este dispositivo o el dispositivo no funciona por lo que la llegada al punto es notificada por el patrulla a través de radio. El operadorRadio deberá disponer de algún mecanismo para anotar este evento.

Deberá tenerse en cuenta que es posible que un incidente tenga asignadas varios patrullas y que cada patrulla llegará al punto en momentos distintos, por lo que sistema deberá poder discriminar qué patrulla de entre las asignadas es la que comunica su llegada al punto.

Añadir información Es necesario anotar en el incidente todo lo que va sucediendo así como la información relevante que se pueda ir conociendo con respecto a los implicados en el incidente.

La acción de añadir información al incidente puede ser un acto independiente o puede realizarse en cualquiera del resto de acciones de forma que se pueda justificar o aclarar por qué se ha tomado cada decisión.

El sistema debería disponer de una ayuda de forma que existiera un conjunto de textos predefinidos que el operadorRadio podría invocar a través de combinaciones de teclas o que el sistema podría proponer a partir del texto que está introduciendo el operadorRadio.

Se anotará junto datos del puesto, momento en que se añade información y quien la añade, sin posibilidad de eliminarla en ningún caso.

Dado que existe integración con otras agencias, la información proveniente de las agencias integradas referida a un incidente será anotada de forma automática.

En los incidentes multiagencia deberá tenerse en cuenta si se desea que la información que se añade sea sólo para conocimiento propio o para conocimiento de todas las agencias participantes.

Documentos anexos Debe ser posible añadir al incidente documentos de los tipos más habituales en formatos estándar como PDF, GIF, etc. Por ejemplo con una foto o un volcado de pantalla. Los documentos deberán estar firmados digitalmente, con datos de fecha y hora correspondiente, utilizando la plataforma disponible en CISEM que actualmente es SIAVAL.

Los documentos anexados podrán ser consultados en cualquier momento.

Se podrá eliminar un documento anexado, si bien ha de quedar registro de dicho borrado. Esta operación debería estar permitida a usuarios con privilegios adecuados.

Consulta de llamadas relacionadas El operador de radio deberá poder consultar las llamadas relacionadas con un incidente. Esto es, consultar los datos registrados por el operadorTeléfono y acceder a la grabación de la llamada.

Liberar un recurso policial Es necesario poder liberar un recurso policial de un incidente al que esté asignado, siendo posible que el incidente pase a no tener asignado ningún recurso. El recurso liberado pasará al estado de


Pág

ina:

19

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







“Disponible”.

Estado “No disponible” El operador radio podrá poner a cualquier indicativo en Estado “no disponible”, en base a las informaciones que éste lo traslade o las instrucciones que reciba de los responsables de la Sala.

Incidentes relevantes También es posible que surja un acontecimiento tal que suponga la creación de un grupo de patrullas que van a atender todos los incidentes relacionados con dicho acontecimiento. Este grupo podrá disponer de un canal de radio propio paras sus comunicaciones. El sistema deberá permitir asociar todos estos incidentes dentro de un mismo expediente volcando toda la información de los incidentes particulares en el suceso principal, para una posterior consulta de información y obtención de estadísticas.

Requerir la presencia de otra agencia Es necesario poder solicitar los servicios de otra agencia en cualquier momento de la vida del incidente. Las agencias pueden estar integradas con PMM mediante comunicaciones telemáticas o no. Dependiendo del caso, el sistema deberá remitir una solicitud de servicio a través de la correspondiente integración o deberá facilitar los datos de contacto (teléfono, etc.).

El conjunto de agencias, la definición de la vía de comunicación (integrada o no), y los datos de contacto deberán ser administrables.

Las agencias que se han de integrar con el sistema de Tratamiento de Incidentes de Emergencias de PMM al menos son 112, Bomberos, SAMUR y Movilidad

En cualquier caso el sistema permitirá al operadorRadio introducir un texto que será remitido a la/s agencia/s destinataria/s y anotado en el incidente.

El sistema deberá permitir avisar simultáneamente a más de una agencia.

Sistema de cartografía. Se ha de disponer del apoyo de un servicio de cartografía que facilite a los operadores de PMM el seguimiento de los incidentes y la toma de decisiones. La pantalla de mapa será una pantalla en la que se muestre la cartografía de la ciudad, se muestre la información que el operador necesite ver en cada momento y en la que pueda realizar dentro del propio mapa las operaciones relativas a la asignación y seguimiento de incidentes y patrullas.

Dada toda la información que se debe mostrar en la pantalla, la pantalla de mapa o cartográfica se podrá mostrar en un monitor distinto al monitor utilizado para la consulta y manipulación de datos. La información mostrada en ambas pantallas deberá ser coherente independientemente de la pantalla sobre la que se esté operando.

El sistema cartográfico deberá permitir utilizar la BDC del Ayuntamiento de Madrid , así como a la hora de utilizar el mapa poder seleccionar entre un sistema GIS comercial y otro propio del Sistema de Tratamiento de Emergencias, siempre y cuando sean compatibles con ESRI, o en caso de no tenerlo el del Ayuntamiento basado en ESRI.

El operador de Teléfono podrá posicionar un incidente a través de la pantalla de mapa y se mostrará una marca indicando la posición del incidente. Esa misma marca se mostrará cuando el operador use cualquier otra técnica de posicionamiento de incidentes.


Pág

ina:

20

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Una vez localizado el incidente, el sistema deberá mostrar los patrullas que se encuentran en un radio determinado y configurable.

Dado un patrulla y un incidente, el sistema podrá mostrar el itinerario más corto para que el patrulla llegue al lugar del incidente, basado en la distancia y/o en el tiempo estimado de llegada, utilizando datos de densidad de tráfico en tiempo real, así como datos históricos, al objeto de obtener resultados óptimos.

El operador podrá consultar los datos de un incidente al seleccionarlo en el mapa.

El operador podrá asociar la llamada a un incidente arrastrando el icono de la llamada sobre el incidente a asociar.

Será necesario que se disponga de vistas o zoom de la ciudad para que los operadores realicen el seguimiento de los incidentes de unas zonas determinadas de la ciudad.

El operador podrá ver todos los incidentes o seleccionar los incidentes que quiere ver. Los incidentes podrán mostrarse con iconos distintos dependiendo del tipo de incidente y del estado en que se encuentre.

También podrá ver la posición de los patrullas de las unidades asignadas, las de una unidad concreta, los patrullas asociadas a un incidente o un patrulla concreta. Los patrullas se representarán con iconos distintos dependiendo del tipo de patrulla y del estado en que se encuentre.

5.1.3. Fase de cierre Esta fase se produce cuando se cierra el incidente y por tanto dejan de estar asignados todos los patrullas pasando a estado de Disponible. En esta fase posterior al cierre se recogen los datos necesarios que no han sido recogidos todavía y se redacta el “Parte del Intervención Policial”.

Cuando el último patrulla asignado a un incidente abandona el lugar el incidente podrá cerrarse. El cierre de un incidente deberá ser acompañado de un resultado de la actuación realizada.

Los posibles tipos de cierre podrían ser:

• Cierre en positivo: Existía la causa por la que se solicitó la presencia policial.

• Cierre en negativo: Tras presentarse el patrulla en el lugar no se ha observado que exista la causa por la que se solicitó su presencia.

• Cierre sin respuesta: Este cierre se aplica en los casos en que al final, debido a las limitaciones de recursos, no se ha podido acudir a un incidente.

• Cierre por repetido: Existe un segundo incidente que coincide con el que se está cerrando y el seguimiento de los hechos se hará en el otro que se mantiene abierto. Es necesario crear en ambos incidentes una referencia al otro incidente repetido. Es necesario que parte de la historia del incidente se pase del incidente que se cierra al que permanece abierto. Los patrullas asociadas al incidente que se cierra pasarán a asociarse al incidente que permanece.

• Cierre resuelto en Emisora: El incidente ha sido resuelto por el operadorRadio sin que haya tenido que acudir ningún patrulla.

• Cierre por no proceder: Será aquellos casos en los que se decide que el motivo del incidente no justifica el envío de un patrulla.


Pág

ina:

21

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Es posible que, en el momento de cierre de un incidente la tipificación inicial no describa correctamente el tipo de incidente que ha sido. El sistema deberá permitir al operador introducir una nueva tipificación tanto durante el propio incidente como en el momento del cierre.

En todo caso, se contemplará la posibilidad de establecer un cierre operativo y un posterior cierre administrativo, tras efectuarse una valoración global del suceso, con independencia de la cumplimentación posterior del Parte de Intervención Policial que pueda realizar la Unidad actuante.

Reabrir un incidente Es necesario que se pueda reabrir un incidente. Cuando se reabre un incidente pasa al buzón de entrada del operadorRadio encargado de llevar su seguimiento.

Cuando un operadorTeléfono recibe una nueva llamada relacionada con un incidente ya cerrado el sistema preguntará al operadorTeléfono si desea reabrir el incidente bien por asociación o bien por reincidencia.

Búsqueda de incidentes El sistema deberá permitir buscar incidentes por los datos relevantes de un incidente, esto es, deberá existir un sistema de búsqueda de incidentes basado en formulario. Para ellos deberá existir una pantalla con todos los datos por lo que se pueda buscar un incidente. Entre los datos estarán la fecha y hora de inicio y la fecha y hora de fin del rango de tiempo en el que se realizará la búsqueda. El sistema propondrá por defecto como rango temporal de búsqueda configurable, por ejemplo de las últimas veinticuatro horas, y que el operador pueda cambiar dicho rango.

Una vez completados los criterios de búsqueda, el sistema localizará todos aquellos incidentes cuya información cumpla los criterios de búsqueda y los presentará al operador para que seleccione el que desea ver. Además tendrá acceso al Parte de Intervención correspondiente a dicho incidente, según se describe en los Requisitos de Integración.

El sistema recordará los criterios de búsqueda de forma que el operador podrá reiterar la última búsqueda realizada o iniciar una nueva búsqueda.

Impresión de un incidente Un incidente podrá imprimirse. El proceso de impresión consistirá en la generación de un documento PDF que el operador podrá guardar para remitirlo o podrá enviar a impresora para obtenerlo en papel.

El impreso deberá mostrar la fecha de impresión, se registrará en el correspondiente log que ha sido impreso y se restringirá la posibilidad de imprimir en función del perfil o rol.

El operador podrá decidir si incluye los ficheros anexos en el documento resultante.

El formato del documento generado deberá basarse en una plantilla que podrá ser modificable de forma sencilla y ajena a procesos de programación.

Parte del Intervención Policial Una vez cerrado un incidente los patrullas deberán informar de su actuación rellenando el correspondiente Parte de Intervención Policial (PIP) del incidente.

Lo podrán rellenar desde los patrullas con dispositivos tipo Tablet o Smartphone utilizando el “Subsistema de Tratamiento de Incidentes en Movilidad” que se describe en el siguiente apartado, o en la


Pág

ina:

22

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







oficina de la Unidad utilizando la actual aplicación de PMM “Partes de Intervención”.

5.2. Requisitos del Subsistema de Tratamiento de Inciden tes en Movilidad.

Los agentes de PMM que se encuentran patrullando y se les asigne que intervengan en un incidente, han de disponer de un módulo del sistema que les permita, mediante el envío de datos, interactuar para recibir y enviar información relativa al incidente así como de la actuación realizada en dicha intervención.

Este módulo ha de permitir que cuando el operador de radio le asigne un incidente a un patrulla, si el equipamiento del patrulla lo permite, reciba toda la información posible del incidente como es la dirección, datos del llamante, tipología y descripción del incidente, agencias informadas, etc.

Igualmente el módulo del sistema que utilice el patrulla propondrá un itinerario a seguir para llegar a la dirección del incidente a través del oportuno navegador.

Es necesario que el módulo y las pantallas que se diseñen para ser usadas por los patrullas en un Tablet o Smartphone sean sencillos y orientados ser usados a través de pantalla táctil y de teclado.

El usuario del patrulla podrá:

• Seleccionar qué incidente de los asignados quiere ver.

• Sobre un incidente se podrá:

o Consultar los datos básicos y la historia.

o Marcar la llegada al punto, si bien se tener la posibilidad automática de enviar la llegada al punto por GPS.

o Marcar la finalización de su actuación en el incidente.

o Recibir alertas en caso de producirse en el Subsistema de Supervisión.

o Ver un mapa donde esté posicionado el incidente y los patrullas asignados.

o Ver en el mapa el itinerario más corto al incidente desde su posición.

o Redactar el Parte de Intervención según se explica a continuación en este apartado.

• Acceder a herramientas como una agenda informativa y algunos plugins.

Cuando en un incidente se sobrepase el tiempo de respuesta máximo permitido, el sistema deberá mostrar una alerta al usuario del patrulla.

En todo caso, el contenido concreto de la información que ha de trasladarse a los actuantes, a la cual se ha hecho referencia en anteriores párrafos, será definido por el servicio previamente a la incorporación efectiva de esta utilidad.

Parte del Intervención Policial (PIP) Finalizada la actuación del patrulla en el incidente, este podrá informar de su actuación. En la actualidad dispone en la oficina de la Unidad de la aplicación web “Partes de Intervención” que cumple con los requisitos que se exponen a continuación.

Será necesario que el módulo de Tratamiento de Emergencias en Movilidad integre dicha aplicación “Partes de Intervención” o realice las mismas funcionalidades, de forma que la información recogida deberá estar normalizada y en campos diferenciados que permitan fácilmente su búsqueda,


Pág

ina:

23

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







consulta o explotación de la información, y sea transferida a la base de datos de Partes de Intervención.

Para ello agente de PMM podrá, desde el dispositivo que tenga en el vehículo, seleccionar sobre que incidente va a reportar información, y podrá distinguir sobre cuales ha informado ya.

Estará ya asociada toda la información relativa a patrullas actuantes, datos del incidente, hora a la que se informa, etc., pudiendo rellenar además lo siguiente:

• Personas relacionadas con la intervención, pudiendo ser varias en cada PIP con los datos relativos a:

o Identificación de cada persona (tipo de documento de identificación, número de documento, nombre, apellidos, nacionalidad, fecha nacimiento, género, lugar y fecha de nacimiento, etc.),

o Dirección de la persona (localidad, tipo de vía, nombre vía, número, piso, letra, código postal, etc.),

o Datos de contacto (teléfono, email, etc.)

o Motivo/causa en la intervención (tipo de implicado, motivo detención, etc.)

o Datos del carnet de conducir (tipo de carnet, fecha expedición, fecha caducidad, etc.).

o Observaciones.

• Vehículos relacionados con la intervención: o Datos del vehículo (marca, modelo, color, matrícula, tipo de vehículo, etc.).

o Datos del seguro (nº de póliza, compañía, fecha caducidad).

o Datos de ITV (fecha ITV, resultado ITV, caducidad)

o Observaciones.

o Objetos/Animales/otros elementos relacionados con la intervención, con datos relativos a su clasificación, descripción, cantidad de cada tipo, observaciones, etc.

• Datos de la intervención: tipo de resultado, descripción y observaciones.

• Asociación entre las personas, vehículos y objetos, para saber su pertenencia o relación entre ellos.

• Minuta.

• Se podrán anexar ficheros al PIP, como por ejemplo fotos o documentos PDF.

El parte se podrá corregir o modificar, quedando registradas las modificaciones, así como momento y usuario que las realizan.

No se podrá generar el parte de intervención si ha transcurrido un plazo máximo, expresado en horas, que será configurable.

Se podrá generar un informe o impreso de cada PIP en formato PDF con un formato y contenido basado en una plantilla modificable, similar al que se obtiene en la aplicación de Partes de Intervención.

Si se pierde la conexión desde un patrulla que esté rellenando un PIP o se esté enviando cualquier otra información, se deberá volcar esa información al sistema cuando se vuelva a tener conexión.


Pág

ina:

24

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







5.3. Requisitos del Subsistema de Tratamiento de Inciden tes Descentralizado. Este subsistema permitirá la gestión, supervisión y tratamiento de incidentes desde la Unidades de distrito y especializadas de PMM, con funcionalidades similares a las del Subsistema de Gestión de Incidentes, pero sin interferir en los incidentes tratados desde CISEM y viceversa.

Es necesario que los mandos de las unidades puedan conocer la actividad de los patrullas que están a su cargo, y si así lo requieren se pueda crear, hacer seguimiento y cerrar incidentes de su unidad, así como realizar consultas, reporting, utilizar el GIS, etc.

En este sentido se plantea disponer de un perfil de usuario en el sistema que muestre en las Unidades mediante técnicas cartográficas la ubicación de los patrullas pertenecientes a su unidad así como la ubicación de los incidentes vivos localizados en su zona de influencia.

También deberá existir un sistema de consulta que permita ver e informarse sobre los incidentes localizados en la zona de influencia y los incidentes atendidos por patrullas pertenecientes la unidad.

Cuando un incidente lo requiera, el mando de unidad podrá marcar dicho incidente para hacer su seguimiento. Dispondrá de un filtro o vista que permita ver sólo aquellos incidentes marcados para seguimiento, independientemente del estado en el que estén. Una vez marcado para seguimiento un incidente, aparecerá en la pantalla de seguimiento de todos los mandos de unidad. Cualquier mando de unidad podrá desmarcar el incidente para anular el seguimiento.

Se trabajará desde las unidades de forma similar a como lo hacen los operadores de telefonía y de radio en Emisora con un canal diferente para cada unidad policial, ya que las funcionalidades que precisan son prácticamente las mismas adaptadas a las características geográficas y de especialización de cada unidad.

Por lo tanto el perfil del mando de Unidad será similar al de un supervisor de Emisora, y también podrá haber algún puesto de operador de telefonía y de radio.

En todo caso, el contenido concreto de las características de este perfil, definido con carácter general en los párrafos anteriores, será definido por los responsables de Policía Municipal previamente a la incorporación efectiva de esta utilidad.

5.4. Requisitos del Subsistema de Supervisión. Este subsistema permitirá monitorizar la sala y los puestos de operador (realizando la configuración por perfiles), facilitar la toma de decisiones sobre la forma en que los incidentes deber ser gestionados y establecer la forma en la que se generarán alertas y avisos a los diferentes perfiles (operadores y patrullas) ante ciertas situaciones.

Dentro del Subsistema de Supervisión se incluirán funcionalidades que cubran las siguientes necesidades de información y operación:

• Monitorizar lo que está sucediendo en cada momento en los puestos de operador.

• Administrar y gestionar la configuración de los puestos.

• Definición de alertas y avisos a los supervisores, operadores y patrullas.

• Para la toma de decisiones y adopción de medidas a aplicar, poder consultar y actuar sobre cualquier incidente, tanto por los supervisores como por los responsables de Unidades de PMM.

• Llevar un seguimiento de lo que está sucediendo en la ciudad, tanto por los supervisores como por los responsables de Jefatura y de las Unidades de PMM.


Pág

ina:

25

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Monitorización Además de los perfiles de operadorTeléfono, operadorRadio y patrulla (módulo o Subsistema de Tratamiento de Incidentes en Movilidad), es preciso en el sistema un perfil o tipo de usuario supervisor que haga la monitorización de los puestos de telefonía y radio, y otras funcionalidades como la configuración de la sala de radio o la configuración del mapa de canales.

Supervisión sala telefonía y radio El supervisor debe conocer los puestos de operador que están activos en cada momento así como el usuario que ocupa dicho puesto, y disponer de indicadores y alertas que indiquen la carga de trabajo que está soportando cada puesto de operador.

El sistema deberá dar información de la carga de trabajo soportada en cada puesto de forma que se pueda tomar decisiones de redistribuir el trabajo si es necesario. A modo orientativo sería necesario conocer el número de incidentes abiertos que está gestionando cada puesto de operadorRadio así como el volumen de incidentes gestionados en el turno por cada puesto.

El supervisor precisa consultar y operar con cualquier incidente de la misma forma que un operadorRadio. Cuando un incidente lo requiera, el supervisor de radio podrá marcar dicho incidente para hacer su seguimiento. Dispondrá de un filtro o vista que permita ver sólo aquellos incidentes marcados para seguimiento, independientemente del estado en el que estén. Una vez marcado para seguimiento un incidente, aparecerá en la pantalla de seguimiento de todos los supervisores de radio. Cualquier supervisor podrá desmarcar el incidente para anular el seguimiento.

Configuración de puestos La sala de radio dispone de una serie de puestos de trabajo destinado a ser utilizados por PMM. La organización existente actualmente usa como elemento de referencia el “puesto de operadorRadio”. Los patrullas de una misma unidad utilizan el mismo canal de radio para comunicarse entre ellas, con su Ferrol y con la emisora V-0. Un mismo canal de radio puede ser utilizado para la comunicación de varias unidades.

Un puesto de operadorRadio lleva el seguimiento de los incidentes que van atender los patrullas de un conjunto de unidades policiales. La definición del conjunto de unidades asignado a cada puesto de operadorRadio se basa en carga de trabajo, de forma que desde cada puesto de operadorRadio se gestione un número de incidentes similar al resto.

Cuando varias unidades comparten un mismo canal de radio es porque esas unidades están asignadas al mismo puesto de operadorRadio.

Cuando un operadorRadio va a empezar su relevo, el supervisor le informa del puesto de operadorRadio que debe ocupar, y de forma indirecta sabe los incidentes de qué unidades a gestionar. El operadorRadio, con carácter general, no tendrá que seleccionar nada cuando entre en el sistema, el sistema deberá ser capaz de otorgarle el servicio según el puesto de operadorRadio en el que se haya conectado. No obstante, debe existir también la posibilidad de elegir canales, al objeto de permitir la necesaria flexibilidad en la gestión del servicio.

Cuando se crea un incidente, dependiendo del tipo de incidente que sea y la ubicación se determina la unidad policial que debería atender ese incidente. Conociendo el canal por el que los patrullas de esa unidad se comunican se sabe el puesto de operadorRadio al que se debe asignar el incidente creado.


Pág

ina:

26

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Determinación del mapa de canales Un mapa de canales habitual o predeterminado configura la sala de forma que desde cada puesto de operadorRadio se gestiona los incidentes de una o varias unidades a través de un único canal de radio.

Sin embargo hay turnos de trabajo en los que el volumen de trabajo es menor y se puede cubrir con menos efectivos. Para estos casos el sistema permitirá fusionar dos o más puestos de operadorRadio en uno. El operadorRadio que ocupe ese puesto gestionará los incidentes de las unidades habituales a través del canal radio asociado a esas unidades y los incidentes de las unidades reasignadas en la fusión a través del canal asignado a ese segundo grupo.

Esta operación de fusión puede hacerse en más de un puesto de operadorRadio haciendo que el número de puestos operativos sea variable.

Es necesario tener la capacidad de poder almacenar un mapa de canales de forma que se pueda configurar la sala según ese mapa cuando el supervisor lo decida, de tal forma que exista una flexibilidad absoluta a la hora de determinar que canales deben ser gestionados en cada puesto de operador.

Alertas y avisos a puestos de operador Se plantean los siguientes requisitos con el fin de detectar ciertas situaciones que den lugar a aletas o avisos del sistema a los operadores y a los agentes que están en patrullas asignados a incidentes. Las alertas deberán verse claramente en pantalla en un color diferente que llame la atención y parpadeando, según la urgencia o prioridad que se establezca por configuración del sistema.

Se define “tiempo de asignación” como el tiempo que transcurre desde que el operadorTeléfono crea un incidente y lo envía al operadorRadio hasta que el operadorRadio asigna un patrulla a dicho incidente.

Se define “tiempo de llegada” como el tiempo que transcurre desde que se asigna un patrulla a un incidente hasta que el un patrulla llega al lugar del incidente (“en el punto”).

Se define “tiempo de respuesta” como el tiempo que transcurre desde que el operadorTeléfono crea un incidente y lo envía al operadorRadio hasta que un patrulla llega al lugar del incidente (“en el punto”).

Trespuesta = Tasignacion + Tllegada

El servicio de PMM tiene como exigencia que el tiempo de respuesta no puede superar un tiempo dado, por ejemplo 8 minutos en el caso de incidentes urgentes y 15 min en los no urgentes. En el caso de los incidentes urgentes los 8 minutos se dividirán de forma orientativa en 2 minutos como tiempo de asignación y 6 minutos para el tiempo de llegada. Estos plazos pueden cambiar con el tiempo, por lo que deberán ser configurables.

• Alerta de tiempo de conversación excedido.- El sistema deberá alertar al supervisor y al operadorTeléfono cuando el operadorTeléfono supere el tiempo de conversación máximo que se haya establecido para llamadas entrantes. El tiempo máximo que se debe destinar a atender una llamada entrante deberá ser configurable en el sistema

• Alerta de tiempo de asignación excedido.- El sistema deberá alertar al supervisor y al operadorRadio cuando el operadorRadio supere el tiempo de asignación máximo que se ha


Pág

ina:

27

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







establecido para asignar patrullas a un incidente. Ese tiempo deberá ser configurable en el sistema en función del tipo de incidente.

• Alerta de tiempo de llegada excedido.- El sistema deberá alertar al supervisor, al operadorRadio y al patrulla cuando se supere el tiempo de llegada máximo que se ha establecido para la llegada al punto del patrulla asignado a un incidente. Ese tiempo deberá ser configurable en el sistema en función del tipo de incidente.

• Alerta de tiempo de respuesta excedido.- El sistema deberá alertar al supervisor y al operadorRadio cuando se supere el tiempo de respuesta máximo que se ha establecido. Ese tiempo deberá ser configurable en el sistema en función del tipo de incidente, permitiendo también que esta alerta se extienda al patrulla asignado, de forma opcional, si se considerara conveniente.

• Alerta desvío de ruta.- Con ayuda de un sistema de seguimiento geográfico de los patrullas, se monitorizará si el recorrido del patrulla al lugar del incidente se desvía del camino aconsejable un margen determinado expresado en metros y configurable, para alertarle.

• Alerta novedad en incidente.- Si se produce alguna novedad en el incidente, como un cambio de estado o nueva información, el sistema deberá avisar al supervisor y al operadorRadio de dicho cambio.

• Alerta de avalancha.- El sistema deberá alertar al supervisor cuando se registre un número de llamadas entrantes por unidad de tiempo que supere a una cantidad dada. Esta cantidad deberá ser configurable en el sistema.

En el caso que el sistema de telefonía lo permita, si se produce una avalancha de llamadas debidas a un incidente localizado, el supervisor podrá desviar las llamadas procedentes de una zona de la ciudad a una locución grabada. La forma de determinar la zona a desviar puede ser:

o Uno o varios barrios

o Uno o varios distritos

o Una zona circular determinada por punto de la ciudad y un radio. Para determinar el punto de la ciudad se puede usar cualquiera de las opciones de localización de un incidente.

• Alerta de gestor de avalancha activado.- El sistema deberá alertar al supervisor cuando un sistema de gestión de avalanchas esté activado de forma que recuerde volver a la situación habitual una vez desaparezca la causa que generó la avalancha.

• Alerta de carga de trabajo.- El sistema alertará de la carga de trabajo soportada por un puesto de operadorRadio cuando el número de incidentes abiertos que está gestionando dicho puesto exceda un número configurable, de forma que se pueda tomar decisiones de redistribuir el trabajo si es necesario.

• Alerta a la superioridad.- Cuando un incidente lo requiera, el supervisor podrá alertar a la superioridad. Para ello debe existir una lista de mandos/cargos susceptibles de ser avisadas. Partiendo de esa lista de contactos predefinida, en el momento de remitir la alerta a la superioridad el supervisor podrá añadir o excluir destinatarios de la lista. También podrá introducir un comentario en forma de texto.

Para cada destinatario se deberá determinar el mecanismo por el que se les debe alertar, siendo inicialmente vía correo electrónico. La alerta consistirá en un mensaje que incluirá al menos la siguiente información:

� Descripción del tipo de incidente � Localización


Pág

ina:

28

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







� Día y hora de creación � Historia del incidente � Comentario del supervisor que envía la alarma

• Alerta al supervisor de un incidente.- Si un operadorRadio considera necesario informar o alertar al supervisor sobre un incidente. Para ello podrá activar una alarma de aviso sobre ese incidente que llegará al puesto del supervisor.

• Alertas a la ciudadanía.- Es posible que surja un incidente que requiera que se alerte a la población de una zona de la ciudad para que tome una serie de medidas preventivas. Se podrá utilizar un mapa para determinar la zona de la ciudad destinataria de los mensajes de alerta, y se planteará como alertar a la población de esa zona geográfica.

La matriz de comunicaciones es un elemento que permite gestionar desde un único interfaz comunicaciones telefónicas, TETRA (entre otras) permitiendo la intercomunicación entre las mismas, junto con un sistema de grabación de apoyo para el operador. La Matriz a integrar será GEMYC o equivalente. En el escenario futuro la monitorización de las conversaciones se realizará replicando los audios de la matriz de conmutación, tal como se especifica en el apartado 7.2, en el que se indica que la integración futura con CTI pasa a ser una matriz de comunicaciones, que incluye las funcionalidades de dicha integración, la transferencia de llamadas a la que se debe añadir la posibilidad de interconectar en multiconferencia varias llamadas, tanto telefónicas como de radio y la marcación para telefonía, y selección de canales para TETRA, tal y como se menciona en el apartado 5.4.

La selección de canales cuando se realice con servidores DCS debe realizarse por perfiles y no por puestos, y la posibilidad de selección debe regirse por perfiles de usuario.

5.5. Requisitos del Subsistema de Gestión de Recursos Po liciales. Este subsistema se encarga de determinar los recursos policiales disponibles y no disponibles así como las tareas planificadas que tienen, para tenerlo en cuenta en su asignación a un incidente en la fase de despacho y seguimiento.

• Determinará los patrullas que están disponibles y no disponibles así como su composición, estados posibles, etc., para la asignación a los incidentes.

Esta información proviene actualmente del módulo de Asignación de CISEM, por lo que es requisito básico de este subsistema que pueda integrarse con ese módulo e incorporar la información que precisa. Lo realizará antes de cada cambio de turno de forma genérica, y de forma puntual después de cualquier modificación que se produzca en ese módulo de CISEM, según se explica en el apartado de “Requisitos de Integración”.

Desde el subsistema de Gestión de Recursos Policiales también se podrán crear patrullas o modificar datos como por ejemplo la unidad a la que está asignado en un turno determinado, por lo que en caso de hacerse dicha información ha de trasladarse al módulo de Asignación de CISEM.

• Igualmente el Subsistema de Gestión de Recursos Policiales debe determinar las tareas que tienen planificadas los patrullas, y mostrar dichas tareas al operadorRadio en pantalla para que lo pueda tener en cuenta a la hora de realizar la correspondiente asignación de recursos a un incidente.


Pág

ina:

29

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Actualmente la relación de tareas asignadas y a que patrullas junto con información relativa a fechas, hora y duración, sitio, etc., se realiza a través del módulo de Asignación de CISEM. Por lo tanto también es requisito básico que este subsistema se integre con dicho módulo según se indica en el apartado de “Requisitos de Integración”.

5.6. Requisitos del Subsistema de Interactuación con otr as Agencias. Es necesario poder solicitar y recibir los servicios de otra agencia en cualquier momento de la vida del incidente. Las agencias podrán estar integradas con PMM mediante comunicaciones telemáticas o no.

El conjunto de agencias, la definición de la vía de comunicación (integrada o no), los datos de contacto y los tipos de incidentes en los que se propondrán participen deberán ser administrables.

El sistema deberá remitir una solicitud de servicio a través de la correspondiente integración o deberá facilitar los datos de contacto (teléfono, etc.), y de permitirlo el sistema de comunicaciones, realizar la llamada. Se deberá permitir avisar simultáneamente a más de una agencia.

En caso de ser agencias integradas se podrá enviar o recibir información con datos y documentos telemáticos en formato normalizado entre los sistemas de PMM y las demás agencias. Las agencias que han de integrarse con el sistema de Tratamiento de Incidentes de Emergencias de PMM al menos serán 112, Bomberos, SAMUR y Movilidad, según se describe en el apartado de Requisitos de Integración, donde se indica la información a compartir así como la forma en la que se puede hacer.

Cuando un operador de PMM solicite los servicios de una/s agencia/s integrada/s (es el caso de Bomberos, SAMUR y Movilidad) enviará la correspondiente carta de llamada del incidente del sistema de PMM. La contestación de la/s agencia/s de aceptación o no se registrará en el sistema de PMM. Y en caso de asociarse dicha agencia al incidente se podrá enviar y recibir más información por los mismos medios como por ejemplo anotaciones que se quieran compartir en el bitácora o histórico del incidente o el cierre del incidente.

Igualmente PMM podrá recibir de una/s agencia/s integrada/s petición de servicio (es el caso de 112, Bomberos, SAMUR y Movilidad) a través de cartas de llamada que PMM aceptará o no, devolviendo la correspondiente contestación. En cualquier caso, se acepte o no, el sistema registrará tanto las cartas de llamada recibidas como la contestación realizada. Y en caso de aceptarse igualmente se podrá enviar y recibir más información.

Cuando una agencia de Emergencias del Ayuntamiento de Madrid (Bomberos o SAMUR) cree un incidente en su sistema y no solicite intervención de PMM, la información de dicho incidente ha de integrarse o tratarse en el sistema de Tratamiento de Emergencias como propio de la otra agencia, para facilitar las siguientes funcionalidades:

• Permitir al GIMU, Gestor de Información de Mando Único, obtener la información que precisa como pueden ser informes de incidentes propios de PMM, compartidos y en los que intervienen SAMUR o bomberos pero no policía.

• Permitir en función del rol o perfil ver en el mapa GIS los incidentes de la otras agencias diferenciándolos de los de PMM.

Actualmente estas funcionalidades están cubiertas por el módulo de Incidente Único de CISEM, y deberán ser cubiertas por el nuevo sistema de Tratamiento de Emergencias de PMM.


Pág

ina:

30

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







5.7. Requisitos del Subsistema de Explotación de la Info rmación.

El servicio de PMM es un servicio que se ofrece a los ciudadanos y está sometido a unos requerimientos de calidad y satisfacción. Además supone un buen porcentaje del trabajo diario que realizan los patrullas. La importancia de este servicio dentro de la organización es tal que es necesario disponer de un buen servicio de explotación que permita satisfacer todas las necesidades de información que se tienen desde los distintos estamentos municipales y policiales.

Las necesidades de información se pueden agrupar en dos vertientes:

• Explotación de la información relacionada con los incidentes

• Explotación de la información relacionada con la auditoria interna del servicio de PMM.

En ambas vertientes será necesario disponer de la capacidad de poder generar un conjunto de informes y/o estadísticas que se requieren de forma periódica. También será necesario disponer de la capacidad de poder elaborar cualquier tipo de consulta al sistema de forma que se pueda responder a cualquier solicitud de información requerida por los estamentos superiores.

Los informes se generarán en un formato de fichero que podrá seleccionar el usuario. Los formatos que se proponen son: Microsoft Excel, Microsoft Word y PDF. El documento generado se basará en un plantilla que podrá ser configurada y modificada, según se indica en el Subsistema de Administración.

Si bien el Subsistema de Explotación de Información debería contemplar la posibilidad de extraer cualquier dato almacenado, a continuación se muestran aquellos indicadores que tienen mayor relevancia.

• Incidente: o Estados:

� Día, hora, minuto y segundo de inicio de estado. � Día de la semana de creación. � Día del mes de creación.

o Operador/es que intervienen. o Tipo de incidente de creación. o Tipo de incidente de cierre. o Distrito. o Barrio. o Posición GPS. o Unidad policial. o Área geográfica. o Patrulla/s que intervienen. o Puesto de operador que interviene. o Llamadas asociadas. o Forma de cierre. o Historia. o Forma de posicionamiento en la llegado al punto. o Datos del parte de intervención.

• Llamada o Operador que la atiende.


Pág

ina:

31

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







o Origen. o Día, hora, minuto y segundo de entrada. o Forma de resolver. o Incidente asociado. o Tiempo de llamada.

• Operador: o Identificador. o Turno.

• Puesto de operador: o Operadores que lo ocupan. o Grupo al que pertenece.

• Tipo de incidente: o Prioridad. o Urgencia.

• Patrulla: o Unidad a la que pertenece. o Tipo de patrulla. o Turno. o Subinspección a la que pertenece. o Inspección a la que pertenece.

Los informes se podrán extraer acotando los datos en función de filtros que el usuario establezca en pantalla. Estos filtros podrán ser los siguientes:

• Rango de tiempo a considerar detallando día, hora y minuto de inicio y fin. • Unidades policiales: una, varias, todas. • Subinspecciones: una, varias, todas. • Inspecciones: una, varias, todas. • Tipos de incidente de cierre:

o uno, varios, todos • Prioridad del incidente. • Incidentes urgentes/no urgentes/todos • Barrios: uno, varios, todos. • Distrito: uno, varios, todos. • Distrito policial: uno, varios, todos. • Área geográfica: una, varias, todas. • Fragmento de texto contenido en las anotaciones de la historia. • Tipo de patrulla: uno, varios, todos. • Turno: uno, todos. • Operador que participa. • Patrulla que participa. • Dirección:

o Calle o Rango de números de la calle

• Zona geográfica determinada mediante técnicas GIS. • Forma de cierre del incidente: una, varias, todas. • Forma de resolver una llamada: una, varias, todas.


Pág

ina:

32

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Origen de la llamada: uno, varios, todos.

Los resultados obtenidos en los informes realizarán las siguientes métricas: • Tiempo medio transcurrido entre estados. • Tiempo máximo transcurrido entre estados. • Total llamadas que superan un tiempo máximo de duración • Porcentaje de llamadas que superan un tiempo máximo de duración • Porcentaje de incidentes en los que el tiempo entre dos estados está en un rango

determinado por un tiempo máximo y uno mínimo. • Total de incidentes. • Total de llamadas. • Total de incidentes por día de la semana. • Total de incidentes por uso horario. • Total de incidentes por día del mes. • Total de llamadas por uso horario.

A continuación se exponen a modo de ejemplo informes que se requieren periódicamente y que serán necesarios:

• Tiempos medios de respuesta.- Informe con los tiempos medios de respuesta (llegada al punto) por tipo de incidente, unidad policial y rango de tiempo.

• Incidentes por unidad geográfica.- Número de incidentes por tipo de incidente, unidad geográfica (área geográfica, barrio, distrito o ciudad) y rango de tiempo.

• Incidentes por uso horario.- Número de incidentes por tipo de incidente, unidad geográfica, por hora y un rango de tiempo.

• Peticiones de servicio por tipo de incidente y día del mes.- Número de peticiones de servicio (de 092, 112, otras unidades, etc.) por tipo de incidente y día del mes para un mes concreto.

• Origen de llamada.- Porcentaje de incidentes que tienen su origen distinto a la centralita 092 por unidad geográfica en un rango de tiempo determinado. El usuario podrá seleccionar el origen externo de llamadas que desea estudiar (112, centro respaldo, unidad especializada, etc.), el rango de tiempo (mes completo, días completos, etc.) y unidad geográfica.

• Intervenciones de una unidad por barrio y turno.- Número de incidentes por tipo de incidente, patrulla, barrio, turno y rango de tiempo. El informe generado será una sucesión de tablas de forma que se generará una tabla por barrio. Cada tabla tendrá tantas filas como turnos de forma que se muestre, para cada tipo de incidente padre, el número de incidentes atendidos por patrullas de la unidad consultada en ese turno. Cuando varias patrullas acudan a un mismo incidente, el incidente sólo se contabilizará una sola vez.

• Incidentes por tipo que cumplen el tiempo de respuesta máximo establecido.-Obtiene el porcentaje de incidentes por tipo de incidente, unidad policial, por turno, en un rango de tiempo y cuyo tiempo de respuesta es igual o inferior a un tiempo dado.

• Incidentes por tipo que cumplen el tiempo de asignación máximo establecido.-Similar al anterior per con el tiempo de asignación igual o inferior a un tiempo dado.

En un futuro está previsto que la interconexión del nuevo sistema TETRA y sus servidores DCS sea siempre a través de las matrices de comunicación. Igualmente la integración telefónica también


Pág

ina:

33

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







deberá realizarse mediante dicha matriz que a su vez utilizará protocolos con el estándar SIP para integrarse con el CUCM (Cisco Unified Communications Manager) del Servicio Telefónico Corporativo.

Por otro lado, debido a las políticas de datos abiertos (open data) y transparencia, se debe permitir en todo momento tener acceso a los datos para explotaciones y análisis de datos posteriores.

Para ello se dotará de las herramientas, informes o programas que permitan descargar los datos en bruto y desagregados en varios formatos no propietarios, como por ejemplo son CSV y XML, de las tablas que constituyan el núcleo de la aplicación, así como las tablas auxiliares para su interpretación.

Dependiendo del volumen de registros, esta extracción podrá ser total, incremental o por rango de fechas. En la medida de lo posible estos procesos se programarán y ejecutarán de forma desatendida, con la periodicidad que se desee, dejando los conjuntos de datos, en unos recursos de red o similar especificados por los responsables técnicos del Ayuntamiento.

Si por el volumen de información o por la importancia de tener información en tiempo real, fuese necesario, se habilitará un sistema que permita obtener la información en tiempo real y/o solo el subconjunto de información en el cual se esté interesado. La forma de realizar esta extracción será mediante un interfaz de programación de aplicaciones (API) basado en estándares abiertos según los estándares establecidos por el Ayuntamiento.

5.8. Requisitos del Subsistema de Administración.

Este subsistema incluirá las tareas de mantenimiento de datos maestros, así como configuración y parametrización básicas.

Permitirá actualizar información relativa a los puestos, a los usuarios, a los estados de incidentes, al catálogo de incidentes, ficheros de traza, etc.

Permitirá configurar y parametrizar las diferentes opciones según las cuales pueden trabajar los distintos perfiles de usuarios del sistema. A continuación se describen las principales funcionalidades que deberá tener o a las que permitir acceder:

• Permitirá al personal habilitado dar de alta, baja o modificar a un usuario. Sobre el usuario se requerirá la siguiente información:

o Identificador: que deberá coincidir con el identificador que tiene el operador en el dominio del CISEM.

o Número policial.

o Nombre y apellidos.

o Unidad policial de pertenencia.

o Rol o perfil asignado.

• Permitirá dar de alta, baja o modificar un rol o perfil, y asignarle las funcionalidades u opciones y permisos de la aplicación que van a poder ejecutar los usuarios que tengan asignado dicho perfil. Por ejemplo serán perfiles a configurar los de operadorTeléfono, operadorRadio, supervisor, patrulla, etc.

• El Subsistema de Administración permitirá dar de alta, baja o modificar un canal de radio, así como definir las unidades policiales que se van a comunicar habitualmente por cada canal de radio.


Pág

ina:

34

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Será posible definir canales de radio por los que no se vaya a comunicar habitualmente ninguna unidad, y administrar la configuración de los incidentes que gestionarán las Unidades policiales directamente.

Sobre un canal se ha de mantener al menos la siguiente información:

o Número de canal de radio

o Descripción del canal de radio

o Unidades que se van a comunicar por ese canal

• Permitirá dar de alta, baja o modificar un puesto de usuario, así como definir lo que se puede hacer desde ese puesto, lo cual dependerá del tipo de usuario: operadorTeléfonoperadorRadio, supervisor, etc.

Sobre un puesto de operador se ha de mantener al menos la siguiente información:

o Nombre de la máquina en el dominio.

o Descripción del puesto de operador.

o Grupo de trabajo al que pertenece.

o Rol asignado.

o Extensión de la centralita telefónica asignada al puesto de operador.

o Canal o canales de radio asignados al puesto.

• En este módulo o subsistema se podrá realizar el mantenimiento del catálogo de incidentes. Los incidentes se tipificarán jerárquicamente hasta en cuatro niveles. Podrá haber tipos de incidentes no habilitados, que solo se puedan usar para la apertura de un incidente y que solo se puedan usar para el cierre. Esta programación, así como la creación y supresión de incidentes, será configurable desde el rol de administrador.

Sobre un tipo de incidente se ha de mantener al menos la siguiente información:

o Código de tipo de incidente.

o Descripción.

o Prioridad.

o Agencias que deberían participar según el protocolo establecido.

o Apto para apertura.

o Apto para cierre.

o Habilitado para su uso.

o Unidad que debería atender los incidentes de este tipo de incidente.

o Icono con el que se representará en el mapa.

En este catálogo tendrán cabida los tipos de incidentes tanto de PMM como de otras agencias con las cuales se integre o comparta información el sistema.

• Existirá un catálogo de conversión de incidentes entre agencias integradas, que permitirá establecer la conversión de cada tipo de incidente de una agencia con el de otra agencia que esté integrada en el Subsistema de Interactuación con otras Agencias.

Este catálogo se podrá mantener desde el Subsistema de Administración y contendrá al menos información sobre la correspondencia de cada código de incidente de PMM con cada una de las demás agencias, así como fecha de inicio y de fin de vigencia de dicha correspondencia.

• Definir los criterios de ordenación según los cuales se vean en pantalla diversas listas como por ejemplo:


Pág

ina:

35

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







o Los incidentes de un canal pendientes de asignar patrullas, en función de su prioridad o urgencia.

o Patrullas que puedan asignarse a un incidente, en función de su disponibilidad, cercanía, tipo de incidente y de recurso, etc.

• Tiempos de asignación y de respuesta a cumplir en determinadas acciones, y en caso de ser necesario mostrar una alerta o aviso a quien corresponda (operador de radio, patrulla asignado, etc.):

o Tiempo de asignación en caso de incidentes de cierta tipología o urge. Por ejemplo 2 minutos, o lo que se configure, para ciertos tipos de incidentes.

o Tiempo de respuesta o de llegada al punto en caso de incidentes de cierta tipología o urgencia.

• Definir la distancia de llegada al punto por GPS. Se podrá configurar en metros que distancia es suficiente para que el sistema registre automáticamente la llegada al punto de un patrulla según su posición GPS.

• El Subsistema de Administración permitirá definir y configurar los diferentes estados y listas de valores que permitirán definir los requisitos expuestos, como son:

o Estados de un incidente y la transición entre estos.

o Estados en los que pueda estar un patrulla y su transición.

o Estados o tipos de una llamada entrante.

o Estados de tareas que pueden ser asignadas a un patrulla.

o Cualquier lista de valores que pudiera ser necesaria definir para las diferentes opciones o desplegables, como puedan ser lista de nacionalidades, provincias, turnos, unidades, distritos, etc.

o Definición de textos predefinidos, tal y como se indican en al apartado de Utilidades en Requisitos de Usabilidad.

• Permitirá realizar el mantenimiento de la estructura policial, pudiendo modificar u obtener del Subsistema de Gestión de Recursos Policiales la codificación, descripción y dependencia jerárquica de las unidades policiales, las inspecciones, las subinspecciones y los distritos policiales.

• Los incidentes se podrán categorizar en una escala de prioridades, en principio del 0 al 9, en función del tipo de incidente. Las prioridades determinan:

o El orden en que se deben mostrar los incidentes pendientes a un operador para su tramitación.

o La representación gráfica con el que se van a mostrar los incidentes en pantalla.

o El tiempo de asignación máximo y el tiempo de respuesta máximo.

El sistema permitirá dar de alta, baja o modificar las prioridades. Sobre una prioridad se mantendrán al menos la siguiente información:

o Nivel de prioridad.

o Estilo de representación gráfica en pantalla de datos.

o Tiempo de asignación máximo y tiempo de respuesta máximo.

• El subsistema de administración permitirá realizar el mantenimiento de las áreas geográficas de forma que los usuarios habilitados para ello puedan darlas de alta, baja o modificarlas.


Pág

ina:

36

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Las áreas geográficas se utilizarán para las propuestas de asignación de patrullas a incidentes, obtención de informes y estadísticas, definir las agencias externas que están integradas con PMM en dicha área geográfica, etc. La información relevante de un área geográfica será:

o Nombre del área geográfica.

o Una descripción.

o La extensión geográfica que delimita.

o Unidad policial que atenderá los incidentes producidos en dicho área.

Un área geográfica puede tener cualquier forma posible, sin que tenga que ser obligatoriamente un polinomio cerrado.

Cuando se asigne una unidad policial a un área geográfica los incidentes producidos en dicho área, el sistema propondrá como patrullas a asignar las patrullas en servicio de dicha unidad. Un supervisor tendrá la capacidad de desactivar/reactivar esta política de asignación.

Es necesario contemplar la posibilidad de que un área geográfica cambie de geometría y sea necesario recordar la extensión del área y los elementos del callejero que estaban incluidos en el área en cada momento.

• El Subsistema de Administración permitirá realizar el mantenimiento de la agenda de contactos y de las agencias externas a PMM a las que se pueda solicitar su prestación de servicio en un incidente, de forma que se puedan dar altas, bajas o modificarlas. La información básica que debe mantenerse es la siguiente:

o Nombre de la agencia.

o Descripción.

o Áreas geográficas en las que se puedan solicitar servicio.

o Nivel de integración con el sistema de PMM.

o Vía de contacto para solicitar servicio o contactar (telefónica, email, etc.)

o Datos de contacto.

El sistema de teclado rápido por defecto de la agenda de contactos ha de ser configurado desde la administración (véase apartado de Utilidades en Requisitos de Usabilidad).

• Mantenimiento de la agenda informativa (véase apartado de Utilidades en Requisitos de Usabilidad). Desde el Subsistema de Administración se podrá indicar el contenido de la agenda informativa, compuesta de forma jerárquica por ítems que tendrán un nombre, descripción y documentación asociada a consultar por los operadores en caso de que lo consideren necesario.

• Mantenimiento de acceso a aplicaciones externas mediante opciones de menú o de forma similar integrada y ágil. Este subsistema permitirá incluir opciones de menú o similares desde las que ejecutar aplicaciones externas en ciertas pantallas de la aplicación, con el fin de que los operadores puedan por ejemplo acceder a la aplicación correspondiente para consultar una matrícula en la DGT o una persona en el Padrón.

• El Sistema de Tratamiento de Emergencias ha de estar integrado con la BDC del Ayuntamiento o la que determine el Ayuntamiento. En el apartado de Requisitos de Integración se detalla está integración, pero hay que indicar que el Subsistema de Administración ha de permitir ciertas funcionalidades relacionadas con la gestión de los datos de la BDC, como son las siguientes:

o Determinar y configurar con que callejero se podrá trabajar y cómo se accederá a los datos.

o En el caso de ser necesario determinar el proceso que permita la carga de datos


Pág

ina:

37

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







actualizados y cuando hacerla.

• Si bien la herramienta GIS se podrá configurar desde cada puesto y por cada usuario la forma en la que ver el mapa (capas, zoom, unidad o zona geográfica por defecto, etc.), el Subsistema de Administración permitirá definir aspectos generales de la herramienta GIS como son por ejemplo las siguientes:

o Configuración de herramientas GIS que se podrán utilizar en el sistema.

o Iconos de los diferentes elementos en el mapa, siendo principalmente estos los de incidentes y patrullas, diferenciándolos en función de su estado.

o Definición de capas que se podrán seleccionar por cada usuario con acceso al GIS. Se podrán incluir capas nuevas que permitan por ejemplo ubicar y acceder a cámaras de video de seguridad o cualquier otra funcionalidad que el sistema no tenga inicialmente.

o Ubicación de ortofoto si se dispone de ella.

• El Subsistema de Administración permitirá la definición, ubicación y acceso a logs y ficheros de auditoría. Se podrá configurar que información se registrará en los logs y ficheros que posteriormente se requiera auditar, así como la ubicación de dichos ficheros y un control de acceso restringido a los mismos.

• Igualmente se deberá definir desde el Subsistema de Administración cualquier plantilla que sea necesaria para obtener un informe o estadística en el Subsistema de Explotación de la Información. Para ello se podrán configurar los datos básicos de los ficheros de plantillas como son el nombre, descripción, formato, ubicación de la plantilla, conjunto de campos o datos que contendrá, etc.


Pág

ina:

38

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







6. Requisitos de usabilidad Con el fin de conseguir la necesaria eficacia y facilidad en el uso de la aplicación del sistema requerido en sus diferentes funcionalidades y por los diferentes tipos de usuarios o perfiles, se han definido y clasificado estos requisitos en dos tipos:

• Requisitos de Interfaz.-

• Utilidades, a facilidades de uso mediante herramientas que permitan acceder rápidamente a ciertas funciones, buscar información, etc.

No obstante sobre dicha eficacia y facilidad de uso inciden todos los requisitos expuestos en este documento, si bien destacar que lo hacen de forma esencial los requisitos de rendimiento y de integración que se describen en apartados posteriores.

6.1. Requisitos de Interfaz Para facilitar la usabilidad de la aplicación en la Gestión del Incidente, se precisa que al menos

inicialmente sea lo más parecida al actual SITE en lo que a la interfaz se refiere, información que muestra tanto en aspecto como disposición, flujo o paso entre pantallas para cubrir las diferentes funcionalidades a la hora de rellenar datos, asignar recursos, buscar información, etc.

A continuación se muestran ejemplos de las pantallas más representativas, la de telefonía y la de seguimiento del incidente:


Pág

ina:

39

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Destacar los siguientes requisitos de interfaz: • Se utilizará para las aplicaciones simultáneamente 2 pantallas, siendo normalmente una para el

mapa y la otra para la aplicación de Gestión de Incidentes. • El número de ventanas simultáneas a utilizar en cualquier momento en la aplicación de Gestión

de Incidentes no deberá ser mayor que el número de las que muestra la ventana de seguimiento de incidentes de SITE, tal y como se puede observar en la imagen superior, salvo en casos justificados y con el consenso de los responsables técnicos y de los usuarios del Ayuntamiento, lo cual se deberá especificar y aceptar antes de su implantación.

• Para evitar que el puesto de un operador y las pantallas que utiliza se configuren de diferente forma cada vez que abra su sesión o las modifique de forma fortuita, su configuración será fija no pudiendo modificarse salvo que sea con permisos de administración o pida confirmación al usuario cuando fuera a modificar la disposición de las ventanas.

• El tamaño de la letra y los colores utilizados de las diferentes ventanas serán configurables para adaptar la pantalla a cada usuario en función de su capacidad visual. Esta configuración no podrá afectar, dentro de unos límites mínimos y máximos a especificar, a la correcta visibilidad de la información que se ha de mostrar en cada ventana.

• Dado lo anterior el sistema no permitirá trabajar por defecto con ventanas flotantes, y en caso de intentar mover alguna avisará al usuario.

• El sistema utilizará pantallas emergentes (que se muestran por encima de las demás en la aplicación) solo cuando sea necesaria una respuesta del usuario y debido a que muestre un mensaje, aviso o alerta.

• Con el fin de evitar tener que pasar por múltiples pantallas para realizar cualquier acción en el uso de la aplicación, está no permitirá tener que abrir más de 2 ventanas al realizar dicha acción salvo


Pág

ina:

40

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







en casos justificados y con el consenso de los responsables técnicos y de los usuarios del Ayuntamiento, lo cual se deberá especificar y aceptar antes de su implantación.

• El paso de una ventana a otra será de forma ordenada al igual que el cierre de las mismas y sin perder de vista nunca por algún medio claro y visible (poner en otro color, parpadeo, etc.,) la ubicación de las que estén pendientes de cerrar.

• Solo se utilizarán pantallas emergentes y modales (que se muestran por encima de las demás y solo deja trabajar con ellas) en caso de requerir obligatoriamente una contestación urgente del usuario.

• Se utilizarán colores que resalten más que los utilizados normalmente, a definir, para ciertos objetos de las ventanas como puedan ser incidentes, patrullas, botones, mensajes, alertas o ventanas completas, en función de la prioridad o urgencia que requieran de su contestación o tramitación por parte del operador. Por ejemplo cuando un incidente supere el umbral máximo configurado de tiempo de asignación o de tiempo de respuesta según su tipología este se verá resaltado en otro color y parpadeante.

• El tamaño de la ventana de anotaciones, bitácora o historial de observaciones introducidas por un operador en un incidente, deberá poder mostrar al menos entre 5 y 10 anotaciones a la vez en pantalla para que el operador pueda ver fácilmente el historial de esas anotaciones en el incidente sin tener que hacer scrolling o zoom.

6.2. Utilidades Para facilitar el uso del sistema por parte de los usuarios se plantean a continuación algunas utilidades o herramientas a tener disponibles en la aplicación:

• Agenda de contactos.- Se dispondrá de una agenda de contactos que podrá contener órganos oficiales propios del ayuntamiento, órganos oficiales externos y personas privadas (físicas y jurídicas).

Es posible que un mismo contacto ofrezca más de un servicio y se necesita tener referencia de cada uno sus servicios, así como el canal de comunicación disponible para cada uno de ellos (teléfono, email, etc.).

La agenda deberá disponer de un sistema de búsqueda ágil que permita localizar un contacto bien por la identificación del propio contacto o por los servicios que ofrece. Una vez localizado el contacto, el sistema deberá permitir llamar al número de teléfono si el sistema de comunicaciones y telefonía lo permite, o enviar un email, etc.

De los teléfonos de la agenda, habrá un conjunto de números que son los más utilizados por los operadores, siendo necesario un teclado rápido de números habituales con ese conjunto de números más frecuentemente, de forma que el operador pueda lanzar la llamada a esos números de forma inmediata en cualquier momento.

El conjunto de números que aparecerán en el teclado rápido será limitado en número (configurable). Si bien habrá un conjunto por defecto, el sistema permitirá a cada operador definir su propio teclado rápido.

La configuración del teclado rápido por defecto será realizada por personal autorizado. • Agenda informativa.-Es necesario disponer de un repositorio de información útil a disposición

de todos los operadores. Se considera información útil cualquier documento con la normativa, comunicados, etc., que pueda afectar o servir de utilidad tanto a los operadores como a las patrullas en servicio. Como ejemplos de información de la agenda tenemos:


Pág

ina:

41

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







� Normativa: � Relativa al servicio del taxi. � Límites de velocidad. � Industrias.

� Cortes de calles de carácter permanente: por mercadillos semanales, etc. � Pautas de comportamiento ante crisis. � Organización:

� Distribución de unidades por canal de radio para redactar los partes de incidente. � Tabla de códigos de agrupaciones de denuncias. � Normas para indicar el posicionamiento de incidentes en la M-30.

Esta información deberá estar estructurada de forma jerárquica atendiendo al criterio de organización que se determine. Cada ítem informativo deberá disponer:

o De un título del ítem informativo.

o Un texto descriptivo.

o Documentos anexos.

Existirán varias formas de poder localizar la información (recorrido por el árbol jerárquico, búsqueda por palabras clave que categoricen los ítems informativos, o búsqueda por fragmento de texto).

La actualización de la agenda informativa sea realizará desde la Administración por personal autorizado.

• Textos predefinidos.- Si el usuario teclea una combinación de letras, es necesario disponer de un catálogo de textos predefinidos para sustituir dicha combinación por un fragmento de texto predefinido, de forma inmediata para ahorrar tiempo en el tecleo. El mantenimiento del catálogo de textos predefinidos deberá estar permitido a personal autorizado.

• Mensajería.- Es necesario disponer de un sistema de comunicación entre operadores que permita el envío de mensajes internos de diversas formas:

o Mensajería básica.- Cada operador podrá dispondrá de una cuenta de mensajería: � En la que recibirá los mensajes que le manden. � Podrá mandar mensajes a uno o varios operadores. � Podrá mandar mensajes a uno o varios puestos de operador. � Podrá eliminar de la cuenta los mensajes ya vistos. � Reenviar mensajes. � Contestar a un mensaje, al remitente o a todos.

o Mensajería avanzada para supervisores.- Cada supervisor dispondrá de las funcionalidades descritas para la mensajería básica más las siguientes:

� Podrá mandar mensajes a uno o varios grupos de puestos de operador. � Podrá mandar mensajes a todos los operadores. � Podrá determinar la vigencia del mensaje.

El sistema deberá incluir una funcionalidad que permita consultar o buscar mensajes enviados con criterios como origen, destino, rango de fechas o fragmento de texto contenido

• Barra de telefonía.- Siempre y cuando el Sistema de Comunicaciones y telefonía lo permita, la aplicación deberá facilitar realizar cualquier operación relativa a las comunicaciones telefónicas. Se definen las siguientes operaciones necesarias:

o Descolgar el teléfono ante llamadas entrantes. o Marcar un número de teléfono tecleado.


Pág

ina:

42

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







o Marcar un número obtenido a través de la agenda de contactos. o Rellamada. o Iniciar una conferencia a tres. o Retener una llamada. o Transferir una llamada. o Activar/desactivar el estado de “ocupado”, que bloquea la entrada de llamadas.

• Barra de radio.- Igualmente siempre que el Sistema de Comunicaciones lo permita, El sistema facilitará realizar cualquier operación relativa a las comunicaciones por radio. Se definen las siguientes operaciones necesarias:

o Activar/desactivar el micrófono o Seleccionar el canal/es de radio por los que comunicarse

• Facilidades de uso en el mapa y herramienta GIS.- Se permitirá configurar el mapa en cada puesto y por cada usuario en la forma en la que verá el mapa por defecto o predeterminada (capas, zoom, unidad o zona geográfica por defecto, etc.). Esa configuración estará relacionada con el usuario y no con el puesto, de tal forma que cuando éste entre en cualquier puesto, se le muestre su configuración personal establecida, salvo que desde el rol de administrador se decida establecer una configuración única para todos los usuarios.

• Accesos a aplicaciones externas.- El sistema deberá estar capacitado para permitir a los operadores acceder sistemas de información externos de una forma integrada y ágil mediante opciones de menú que ejecuten o invoquen a otras aplicaciones. Por ejemplo para acceder a otras aplicaciones para consultar datos de un vehículo, personas, licencias de taxis o licencias de un comercio. Estas opciones serán configurables mediante el Subsistema de Administración.

En el mismo sentido, permitirá establecer vínculos, a páginas web de producción propia, que permitan visualizar de forma inmediata protocolos de actuación e instrucciones internas, que puedan resultar de interés para los operadores.


Pág

ina:

43

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







7. Requisitos técnicos de Plataforma Tecnológica

En este apartado se describe la plataforma tecnológica de los actuales sistemas hardware y software tanto de Informática como de Comunicaciones que da servicio a SITE, así como los requisitos y mejoras a cubrir por el nuevo sistema que lo sustituya que deberán cumplirse durante todo el período de vigencia del contrato.

Se describirán los actuales entornos y presentará una propuesta de ampliación o mejora así como su valoración, si bien será durante la ejecución del contrato en la fase de diseño de la arquitectura y propuesta de solución cuando se detalle.

Cualquier componente o elemento que actualmente no esté en dicha plataforma deberá ser suministrado, configurado, instalado y mantenido dentro del alcance de este contrato.

El nuevo Sistema de Tratamiento de Emergencias de la PMM debe disponer de una plataforma

hardware y software para dar servicio al menos a los siguientes componentes o sistemas:

• Centro Principal.- Se corresponde con el entorno de producción situado en las instalaciones de CISEM (calle Rufino Blanco) y los siguientes puestos a los que dar servicio:

o sala de telefonía y/o radio con 35 puestos de operador + 8 puestos de supervisor,

o sala de telefonía y/o radio con otros 3 puestos de operador + 1 de supervisor de agentes de otros cuerpos o agencias,

o 5 puestos de mando y control para los responsables de PMM y puestos de oficina,

o 4 puestos de mando y control para otros responsables,

o Sala de 112 ubicada en Pozuelo con 2 puestos de telefonía

• Centro de Respaldo: Se corresponde con el entorno de respaldo situado en las instalaciones de la Jefatura de PMM (Avenida Principal) y los siguientes puestos a los que dar servicio:

o 6 operadores de telefonía y radio + 1 con perfil de supervisor,

o 1 operador de telefonía y radio de agente de otros cuerpos o agencias.

• Entorno de pruebas y formación: Se dispondrá de entorno con servidores específicos para estas funciones. Se podrá acceder a él desde cualquier puesto de operador configurado a tal efecto y capacidad de servicio para al menos 15 puestos.

Dentro del entorno de formación se dispondrá de un conjunto de casos prácticos y pruebas configurables y reutilizables que faciliten el aprendizaje de cualquier nuevo operador o persona, para los distintos roles establecidos.

• Despliegue del Subsistema de Tratamiento de Incidentes Descentralizado con acceso al sistema para al menos 80 unidades de distrito y unidades especiales para realizar consultas, reporting, utilizar el GIS, creación de incidentes, etc. Se podrán configurar para acceder a cualquiera de los entornos de producción, pruebas o respaldo en función de los permisos y privilegios necesarios.

• Despliegue del módulo o Subsistema de Tratamiento de Incidentes en Movilidad para permitir a cualquier agente o vehículo recibir información de asignación y reportar información de sus actuaciones, estimados en al menos 1.500 puestos.


Pág

ina:

44

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







7.1. Entorno informático Actualmente se dispone en el CPD de Rufino Blanco donde se encuentra el entorno de producción y

de otro en la Avenida Principal donde se encuentra el entorno de respaldo.

En el entorno de producción se dispone de:

• Servidores Dell PowerEdge R720 con Esxi virtualizados con hipervisor. Se dispone de 2 Host con 96 GB de RAM cada uno y 1 socket con 8 cores, almacenamiento local de 150 GB, 2 tarjetas gigabit Ethernet y 2 HBA.

Posibilidad de ampliación en 1 socket por host, y en memoria añadiendo hasta 18 DIMMS de 32 GB cada uno.

• Sistema de almacenamiento mediante cabinas de EMC, VNX5300, con posibilidad de ampliación en bandejas de 15 discos cada una.

En el entorno de respaldo se dispone de:

• Servidores similar al de producción, pero se dispone de 1 host con similares características. La ampliación puede ser en 1 socket en dicho host.

• Sistema de almacenamiento mediante cabinas de EMC, VNX5300, con posibilidad de ampliación en bandejas de 15 discos cada una.

Los puestos actuales de operador son PCs con equipos con Dell Optiplex 3020, con 4GB de RAM, 500 GB de HD y Windows 7.

7.1.1. Requisitos de equipamiento hardware.

Se proveerán los elementos hardware y servicios profesionales necesarios para disponer de la plataforma de servidores. Los trabajos incluirán la integración de los nuevos servidores en las plataformas comunes de la DGPM de backup1 y monitorización de sistemas.

Basándose en los actuales servidores y puestos clientes de la DGPM descritos se diseñará, suministrará e implantará una arquitectura hardware ampliando la actual con las siguientes características:

• La capacidad de procesamiento global y de memoria central de cada servidor debe mejorar las capacidades de la actual plataforma.

• Los equipos servidores propuestos deben tener la capacidad de escalar internamente en capacidad de procesamiento, al menos, un 30% más de su configuración inicial en capacidad de memoria central, al menos, hasta el doble de la configuración inicial.

• Los equipos de almacenamiento deben tener la capacidad de escalar internamente hasta, al menos, 2 veces su configuración inicial.

• La arquitectura de los servidores debe ser acorde a la actual y a las necesidades del nuevo aplicativo de emergencias.

• Los equipos deben disponer de soporte 24x7.

A continuación se plantea una arquitectura hardware y un conjunto de servidores con unas configuraciones mínimas a modo de ejemplo para dar una idea aproximada de las necesidades de una plataforma con las características expuestas que cubra los requisitos planteados en este documento.


Pág

ina:

45

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Servidores.- Se proponen como necesarios los siguientes servidores, teniendo en cuenta que en el centro principal estarían en cluster en arquitectura activo-activo para garantizar alta disponibilidad, y siendo suficiente 1 de cada tipo en el centro de respaldo y 1 de cada tipo en el entorno de pruebas/formación.

o Servidores de BBDD.

o Servidores de aplicaciones.

o Servidores web.

o Servidores GIS.

• Sistema de almacenamiento.- Se considera necesaria una capacidad inicial de 8 TB para el de producción y de 4 TB para los otros dos entornos.

• Clientes.- Los equipos actuales implantados parecen suficientemente equipados. No obstante existe la posibilidad de que se virtualicen, por lo que el nuevo sistema ha de contemplarlo.

Para aplicar los requisitos hardware se planteará en las ofertas de las empresas licitadoras la forma en que la implantación del nuevo sistema afectará a la arquitectura actual de los CPDs y como se ampliará en caso de ser necesario.

7.1.2. Requisitos de equipamiento software. Los siguientes requisitos deberán cumplirse durante todo el período de vigencia del contrato, así

como cualquier trabajo relacionado con su puesta en servicio y correcto funcionamiento de versiones, despliegue, configuración, administración de base de datos, etc.

• Aplicación del Sistema para el Tratamiento de las Emergencias.- Con sus diferentes módulos o subsistemas, se configurará y adaptará de la forma necesaria para poder cubrir los requisitos de este pliego para los diferentes roles o perfiles de trabajo.

• Software de base.- Se actualizarán los sistemas operativos o cualquier otro software de base asociado a los equipos tanto clientes como servidores cuando sea necesario.

• Base de datos.- Se requiere que las bases de datos sean las utilizadas en la DGPM y en el IAM, siendo estas Oracle versión 10 o superior, o SQL Server versión 12 o superior, o equivalentes. Cualquier otro gestor de base de datos o versión deberá ser aprobado por la dirección técnica del Ayuntamiento.

La versión de la base de datos deberá estar certificada para el sistema a implantar y estar certificado su funcionamiento en los servidores indicados en el apartado anterior.

El licenciamiento debe ser adecuado, al menos, para las prestaciones iniciales de los servidores y para el número de puestos de usuarios a cubrir.

En un funcionamiento normal la base de datos de producción estará separada de cualquier otra base de datos (históricos, explotación, etc.) para garantizar un óptimo rendimiento.

Licencias GIS.- Como requisito funcional se ha planteado en este pliego que a la hora de utilizar el mapa se pueda seleccionar entre el del Ayuntamiento basado en ESRI o entre otro sistema GIS ya sea comercial o propio del Sistema de Tratamiento de Emergencias, siempre y cuando sea compatible con ESRI..

Está incluido en el alcance de este contrato el software y las licencias necesarias para los servidores y puestos de usuario que estén certificadas con la plataforma para cumplir este requisito en los diferentes entornos de producción, respaldo y pruebas/formación.


Pág

ina:

46

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Igualmente se incluye en el alcance cualquier software y su mantenimiento necesario y que no se ha explicitado en este documento para conseguir los requisitos expuestos, como por ejemplo herramientas para la obtención de informes o software necesario para realizar desarrollos a medida de integración con otros sistemas.

7.2. Entorno tecnológico de comunicaciones

En este apartado se describen los sistemas de comunicaciones con los que ha de integrarse el nuevo Sistema de Tratamiento de Emergencias de la PMM, así como los requisitos que ha de cumplir en los puestos clientes, integraciones, etc.

Situación de partida En lo relativo a telefonía, integración CTI - en la actualidad desde el 092 se produce la apertura de carta de incidencia con el volcado del número llamante y la posibilidad de uso de modulo telefónico desde SITE que permite la consulta de agenda telefónica y funcionalidades telefónicas de marcación, descuelgue, trasferencia, consulta etc.

En lo relativo a radio TETRA la aplicación SITE permite integración de los siguientes servicios TETRA: • Mensaje datos cortos y status con red TETRA. • Mensaje SMS con redes móviles. • Posicionamiento GPS de recursos al llegar al punto de incidente (emisoras de vehículos /

portátiles). No se refleja en mapa.

Escenario futuro La nueva solución incluirá:

• Integración directa de posiciones GPS con TETRA

• Integración con futura matriz de comunicaciones

• Funcionalidades de grabación.

• Funcionalidades radio.

• Funcionalidades telefonía.

• Gestión de posiciones de terminales TETRA

• Otras funcionalidades

7.2.1. Integración con los sistemas de voz telefonía y TETRA y futura matriz de comunicaciones

El sistema incluirá una integración llave en mano, con los sistemas de voz actúales de telefonía y TETRA y la futura matriz de comunicaciones.

La integración permitirá, entre otras funciones: o Funcionalidad CTI. o Transferencia llamadas. o Marcación desde la aplicación de llamadas TETRA. o Recoger en la aplicación el identificador de radio llamante. o Integración agendas teléfonicas.


Pág

ina:

47

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







o transferencia llamada de telefonía a radio asociado al incidente en curso con mensaje especial de espera para el llamante.

o Acceso directo a últimas conversaciones realizadas por el operador.

La matriz de comunicaciones es un elemento que permite gestionar desde un único interfaz comunicaciones telefónicas, TETRA (entre otras) permitiendo la intercomunicación entre las mismas, junto con un sistema de grabación de apoyo para el operador. La Matriz a integrar será GEMYC o equivalente.

7.2.2. Funcionalidades de grabación Acceso a través de las API,s de la grabadora radio / telefonía (independiente de las grabaciones que gestiona la matriz de comunicaciones). Integración con el sistema de grabación, de forma que la aplicación recoja todas las grabaciones de TETRA y telefonía asociadas a un incidente concreto (llamadas entrantes, salientes, transferencias, consultas), permitiendo además la consulta de grabaciones a un operador mientras la incidencia permanezca abierta, además de consultas posteriores.

La integración deberá resolver en qué grabadora se encuentra la converasación, ya que cada una grabará en local y luego consolidará en su NAS.

7.2.3. Funcionalidades de radio Independientemente de las asociadas a la futura matriz de comunicaciones, se requieren las siguientes funcionalidades:

o Mensaje datos cortos y status con red TETRA. o Mensajes de datos largos TETRA teniendo en cuenta la precaución de no recuperar dicha

información con mayor tasa de la que el sistema TETRA permite y siempre teniendo en cuenta que es un sistema compartido

o Posicionamiento en mapa de los recursos TETRA y cálculo automático de los estados del recurso.

7.2.4. Funcionalidades de telefonía Independientemente de las asociadas a la futura matriz de comunicaciones, se requieren las siguientes funcionalidades:

o Integración CTI con los sistemas de voz. o Apertura de carta de incidencia con el volcado del número llamante. o Consulta de agenda telefónica y funcionalidades telefónicas de marcación descuelgue,

trasferencia, consulta, etc. o Obtención de la ubicación de llamadas desde móviles, su posicionamiento en mapa y

seguimiento de las mismas. o Posibilidad de transferir llamada desde el operador de telefonía al de radio, asociado al

incidente en curso con mensaje especial de espera para el llamante. Posibilidad de interconectarlas, con independencia de la secuencia en que se produzcan.

o Ubicación automática de llamados fijas en mapa (dependiente de Convenio con la CMT). o Consulta a base de datos de interés policial referente a llamada entrante: la aplicación a

través de la obtención del llamante podría consultar información adicional de interés


Pág

ina:

48

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







policial y mostrarla al operador como complemento por ejemplo relativo a Violencia de Género, problemas reincidentes o llamada maliciosa.

o Mensajes SMS con redes móviles. Para un escenario futuro se utilizará la plataforma corporativa MENTES de envío de SMS, cuya integración deberá realizarse a través de SBAE (Servicios Básicos de Administración Electrónica de IAM)

7.2.5. Gestión posiciones de terminales TETRA Se requieren las siguientes funcionalidades: Explotación de información de posiciones de terminales TETRA

o Consolidar las posiciones que le inserta TETRA o Recibir posiciones de Apolos y consolidar en BBDD. o Preparar posiciones para tabla accesible por consola de video, que usa para posicionar

vehículos OCR. o Reenvía por socket posiciones al módulo “incidente único”. o Herramienta visual y ágil para visualizar en tiempo real posiciones. (Tiene 3 opciones

de visualización: posiciones de menos de 15 minutos (por defecto), de menos de una hora y superiores a una hora).

o Seguimiento online individualizado de vehículos y portátiles. o Informes de taza y zona de posiciones almacenadas. o Histórico de posiciones por vehículo/portátil sobre el mapa. o Informe de la última posición de todos los vehículos y portátiles.

Funcionalidades de administración para este servicio o Alta, modificación y vinculación de Vehículos/portátiles y equipos GPS. o Alta, modificación y vinculación de Unidades e indicativos. o Gestión de perfiles de visualización. o Gestión de usuarios. o Forzar Cambio de turno para actualización de los datos

7.2.6. Otras funcionalidades Se requieren las siguientes funcionalidades adicionales:

o Integración con cámaras de vídeo del sistema CISEVI (en ubicaciones fijas y en patrullas policiales – el asignado al incidente – con posibilidad de grabación en local, así como con futuros dispositivos portátiles que porten los policías que atiendan el incidente). El protocolo de video que usaría CISEVI para servir video a externos sería H.264 RTP/RTSP

o Publicación de mensajes en redes sociales, como twitter, facebook y similares.


Pág

ina:

49

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







8. Otros requisitos técnicos y de seguridad

8.1. Requisitos de Integración El Sistema de Tratamiento de Emergencias de PMM deberá disponer de las funcionalidades de integración de comunicaciones (detalladas en el apartado 7.2. Entorno Tecnológico de Comunicaciones) , de tal forma que desde la aplicación el operador pueda realizar todas las funciones que necesite cualquiera que sea el canal de comunicación empleado (XML procedentes del 112, teléfono, radio, integración con Samur y bomberos, etc.), sin necesidad de emplear dispositivos físicos o aplicaciones específicas.

Deberá gestionar las comunicaciones de voz e integrarse con los sistemas de voz, así como con todos los elementos auxiliares existentes (centralita, sistema de grabación, etc.).

Dará soporte integral al proceso de gestión de la emergencia, lo cual incluye: la gestión de las comunicaciones, tanto con los ciudadanos como con los organismos o agencias que intervengan en la gestión de la emergencia, la aplicación de los protocolos operativos asociados a la misma, la propuesta de medios o recursos para su resolución, el seguimiento de la intervención y el cierre de la misma.

Facilitará la interoperabilidad con las plataformas de otros organismos involucrados en la gestión de emergencias. Con el objetivo de poder realizar una coordinación lo más eficiente posible de las emergencias y optimizar los tiempos de resolución de las mismas, la plataforma deberá permitir realizar una integración “telemática” del modo más sencillo posible.

Se integrará con otras aplicaciones corporativas. PMM cuenta con aplicaciones propias que complementan el proceso de gestión de emergencias. La nueva plataforma se integrará con todas ellas, y optimizará, siempre que sea posible, los procesos transversales de intercambio de información.

Para conseguir estos requisitos generales contará con una serie de desarrollos que permitan la integración con otros sistemas, y que permita recibir y enviar información a través de webservices, XML o tecnología similar consensuada y aprobada por el responsable técnico del Ayuntamiento. A continuación se describen:

8.1.1. Integración con otras agencias El sistema dispondrá capacidad multiagencia para poder ser ampliado a otros organismos o cuerpos de seguridad y emergencias, pero también para su integración con otras agencias para recibir y enviar información, así como para poder mostrar en el mapa incidentes propios y de otras agencias.

Actualmente se dispone de integración con 112, Samur y Bomberos. En la fase de implantación, desde el comienzo del funcionamiento del nuevo sistema de Tratamiento de Emergencias de PMM, será requisito imprescindible disponer de la integración con estas 3 agencias en la misma medida.

La solución que se plantee con el nuevo sistema de Tratamiento de Emergencias de 112 ha de garantizar que la misma información se reciba y envíe de/a estas agencias, sin errores o perdida de información ni retrasos que dificulten o menoscaben la operativa del tratamiento del incidente. Será una solución que se pueda monitorizar para detectar su degradación o posibles problemas de rendimiento o fallo, y que se pueda trazar o auditar mediante algún sistema tipo ficheros logs o similar.


Pág

ina:

50

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







La integración con 112 se basa en un protocolo normalizado que se articula a través de una pasarela que envía las cartas de llamada de 112 a PMM en formato XML desde las instalaciones de 112. Como respuesta PMM envía la aceptación o no de dicha carta de llamada por la misma pasarela. En caso de ser aceptada el operador de telefonía de PMM creará el incidente que seguirá su tratamiento correspondiente en el sistema de Tratamiento de Emergencias. Se enviarán a 112 los cambios de estado y finalmente cuando el incidente finalice se enviará el cierre a 112 por la misma pasarela.

En esta integración con 112 corresponde a la DGPM garantizar las comunicaciones y equipamiento hardware de la pasarela con 112, siendo el nuevo sistema de Tratamiento de Emergencias de PMM el que se encargará por un lado de recibir el XML correspondiente de 112 en las instalaciones de 112 y enviarlo a las instalaciones de la DGPM, y posteriormente realizar su tratamiento para ser recogido como carta de llamada y enviar o recibir el resto de información a 112.

La integración con SAMUR y Bomberos se hará a través de un sistema de intercambio de información o bus de integración basado por ejemplo en colas asíncronas que permitan leer y escribir dicha información en/desde el sistema propio de esas agencias (actualmente una base de datos Oracle llamada SITREM externo). La información a intercambiar deberá ser leída o escrita desde/en el sistema de las agencias y automáticamente se registrará también en el sistema de PMM por medios telemáticos a través de esta capa de integración.

Principalmente es la siguiente información:

• Incidentes creados por SAMUR y Bomberos.- Se registrará la información básica o carta de llamada de los incidentes propios de SAMUR o Bomberos a través del sistema de intercambio en el sistema de Tratamiento de Emergencias de PMM, aunque estos incidentes no requieran de la intervención de PMM, especificándose claramente esta circunstancia, para evitar errores en la gestión posterior.

Esta información contendrá entre otros datos el tipo de incidente y la posición para que un usuario con el perfil adecuado pueda ver en el GIS del sistema de Tratamiento de Emergencias de PMM dichos incidentes.

Según los requisitos funcionales cuando el operador de PMM cree un incidente el sistema detectará si existe un incidente próximo, es decir a una distancia y tipología configurables. En caso de ser un incidente próximo de estas agencias, SAMUR y Bomberos, también deberá detectarlo y avisar al operador de PMM para que pueda asociarse a ese incidente ya creado.

Una vez creado el incidente en el sistema de PMM se devolverá a través del sistema de intercambio de información un código de identificación del mismo y se registrará en el sistema de información de SAMUR y Bomberos, para que estén relacionados los incidentes de ambos sistemas.

• Solicitud de intervención desde SAMUR o Bomberos a PMM.- De forma similar a la integración con 112, PMM puede recibir una carta de llamada de SAMUR o Bomberos, la cual se mostrará al operador correspondiente de PMM según el canal o ubicación geográfica para que pueda asociarse a dicho incidente.

• Resultado de la solicitud de intervención de SAMUR o Bomberos a PMM.- Se registrará la contestación de PMM en el sistema propio de SAMUR y Bomberos.

• Solicitud de intervención desde PMM a SAMUR y/o Bomberos.- Cuando el operador de PMM crea un incidente ha de tener la posibilidad de enviar una petición o carta de llamada a SAMUR y


Pág

ina:

51

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Bomberos. Se realizará registrándola en el sistema de información de SAMUR y Bomberos.

• Resultado de la solicitud de intervención de PMM a SAMUR y/o Bomberos.- Se leerá la contestación de SAMUR y/o Bomberos del sistema de información de esas agencias, e incorporará dicha contestación al sistema de PMM, mostrándola al operador de PMM.

• Actualización de información de incidente de otra agencia.- En el caso de que las otras agencias modifiquen algún dato de la carta de llamada, especialmente en la dirección o ubicación del incidente, esta modificación se incorporará a través del sistema de intercambio de información al sistema de Tratamiento de Emergencias de PMM.

Si la modificación la ha realizado PMM dichos cambios se trasladarán al sistema de información de SAMUR y Bomberas si esas agencias se han asociado o participan en la intervención.

• Compartir información a/desde SAMUR y Bomberos.- Se permitirá al operadorRadio introducir un texto para que sea compartido y remitido a la/s agencia/s destinataria/s y dicho envío quedará anotado en el bitácora o historial del incidente.

Igualmente se podrá recibir información de las agencias con las que estará integrada y de las cuales haya recibido una carta de llamada y aceptado como incidente.

• Cambio de estado de los recursos.- El sistema de integración también deberá tener la capacidad de intercambiar información relativa recursos asignados a un incidente y a los estados de dichos recursos (asignado, liberado, etc.) de los.

En el caso de PMM serán los patrullas creados en el sistema de Tratamiento de Emergencias de PMM y en el caso de las otras agencias serán los recursos que hubieran dado de alta ellas en el sistema de Tratamiento de Emergencias de PMM.

• Cambio de estados de incidentes.- Se intercambiará y registrará cualquier cambio de estado de un incidente de PMM así como el de las otras agencias a través del sistema de intercambio de información. Se tendrá por cada agencia el estado que tiene para ella el incidente así como el momento en que ha llegado a ese estado, especialmente el cierre.

El sistema de Tratamiento de Emergencias de PMM podrá cerrar un incidente cuando todos los recursos de PMM que intervengan estén liberados. Podrá estar asignado algún recurso que no sea de PMM o el incidente sin cerrar por dicha agencia, pero en tal caso el sistema deberá avisar al operadorRadio de dicha situación.

8.1.2. Integración con otras aplicaciones o servicios corporativos El nuevo sistema de Tratamiento de Emergencias de PMM ha de disponer al menos de las actuales funcionalidades de las que dispone el actual SITE. Al igual que la integración con otras agencias, el intercambio de información se realizará mediante un sistema de colas asíncronas y uso de webservice o técnica similar, que deberá estar consensuada con el responsable técnico del Ayuntamiento.

Concretamente se debe hacer la integración y el intercambio de información con las siguientes aplicaciones y servicios:

Asignación y conformación de patrullas de CISEM. Actualmente existe una aplicación de Asignación y conformación de patrullas de CISEM. Esta aplicación de la DGPM permite intercambiar la siguiente información con SITE, y deberá hacerlo con


Pág

ina:

52

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







el nuevo sistema:

• Indica la composición personal (personas concretas) y material (etilómetros, equipos de radio, vehículo, etc.) de los patrullas.

• Indica para cada unidad de distrito cuales son los patrullas disponibles en cada turno.

• Determina cuales son los patrullas agregados o que se asignan temporalmente a otra unidad de distrito para por ejemplo hacer un refuerzo del servicio en dicho distrito o zona.

• Establece la relación de tareas planificadas y la asignación a patrullas, junto con información relativa a fechas, hora y duración, sitio, etc.

Esta información, tanto de los patrullas como de las tareas planificadas y asignadas, es imprescindible para poder asignar patrullas a un incidente por lo que se deberá mostrar al operadorRadio en pantalla para que la pueda tener en cuenta.

El subsistema de Gestión de Recursos Policiales se ha de nutrir de esta información y por tanto es requisito obligatorio que esté integrado con este módulo o el que sistema que incorpore la información indicada. Lo realizará en cada cambio de turno de forma genérica, y de forma puntual después de cualquier modificación que se produzca en este módulo de CISEM.

Desde el subsistema de Gestión de Recursos Policiales también se podrán crear patrullas o modificar datos como por ejemplo la unidad a la que está asignado en un turno determinado, por lo que en caso de hacerse dicha información ha de trasladarse al módulo de Asignación de CISEM.

Integración con TETRA. El sistema permitirá una integración total con la red TETRA, tanto a nivel de voz como de mensajes como de posiciones GPS, todos los elementos que se requieran para realizar dichas integraciones estarán incluidos llave en mano en el alcance del proyecto. En función de la capacidad de los sistemas de comunicación, el sistema tendrá la integración necesaria para recibir los cambios de estados de los patrullas a través de mensajes cortos vía tetra desde sus equipos de radio, teniendo en cuenta la precaución de no recuperar dicha información con mayor tasa de la que el sistema TETRA permite y siempre teniendo en cuenta que es un sistema compartido

Para ello se tendrá asociado/s a cada patrulla su/s equipo de radio en el subsistema de Gestión de Recursos Policiales, que obtendrá del módulo de Asignación de CISEM.

Partes de Intervención de CISEM. Una vez finalizada la actuación del patrulla en el incidente, este podrá informar de su actuación. En la actualidad se dispone de la aplicación web “Partes de Intervención” que cumple con los requisitos expuestos en el “Subsistema de Tratamiento de Incidentes en Movilidad”.

Será necesario que el sistema nuevo integre dicha aplicación “Partes de Intervención” pudiendo ejecutarla desde el subsistema en movilidad o realice las mismas funcionalidades.

También será necesario poder acceder al Parte de Intervención concreto de un incidente desde las opciones de consulta que pueda haber de dicho incidente en los módulos o subsistemas correspondientes de Tratamiento de Incidentes Descentralizado, Supervisión o Explotación de Información.


Pág

ina:

53

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Llegada al punto del patrulla El sistema deberá ser capaz de anotar de forma automática la llegada al punto del patrulla utilizando el sistema de posicionamiento y las opciones de configuración correspondientes, según se indica en el subsistema de Administración.

Integración con APP Será necesario establecer el protocolo y las medidas de confianza para que un ciudadano pueda enviar una carta de llamada a través de su Smartphone. Se podrá establecer una conexión enviando datos mediante webservice, y el ciudadano recibirá confirmación de aceptación de la carta de llamada y del cambio de estado del incidente.

• Inicialmente la integración y protocolo podrán ser similares al de 112 con PMM de forma simplificada teniendo en cuenta que se dispone de:

• Los datos sobre los que el ciudadano habrá dado su consentimiento de uso por parte de PMM en el momento de instalar la app, como por ejemplo el nombre completo, número de teléfono, posibilidad de uso del posicionamiento (X,Y) de su Smartphone, etc. Estos datos deberán ser registrados por el sistema para posteriores comprobaciones en las cartas de llamada recibidas.

• Los datos que rellene el ciudadano en la app en el momento de establecer la llamada y que permitan saber la tipología y gravedad del incidente, o incluso una foto o fichero enviado.

Información al alertante Si el ciudadano llamante es un interesado del incidente, y el teléfono de contacto es un móvil, el sistema permitirá que si los responsables de Policía Municipal lo consideran oportuno, se pueda remitir un mensaje, en principio vía SMS o vía webservice a la APP que envió la carta de llamada, al ciudadano informando que un patrulla se pone en camino hacia el lugar del incidente.

Base de Datos Ciudad/Callejero del Ayuntamiento de Madrid. Actualmente se dispone del callejero de la Base de Datos Ciudad (BDC) del Ayuntamiento para el tratamiento de los incidentes desde SITE. La responsabilidad de actualizar y modificar el callejero es una competencia del Área de Gobierno de Urbanismo y Vivienda y es un órgano dependiente de esta área de gobierno quien facilita los datos actualizados.

Por tanto esta integración, que deberá realizarse de acuerdo con los procedimientos y estándares establecidos por IAM, consiste básicamente en acceder a esos datos para su uso en el nuevo sistema. Para ello se puede utilizar un webservice si cumple con los requisitos de rendimiento, o bien crear un proceso de carga de los datos.

Es necesario que tener en cuenta lo siguiente:

• Trasladar al nuevo sistema de Tratamiento de Emergencias de PMM las peculiaridades y casuísticas de la información que se requiere por la BDC del Ayuntamiento.

• Son frecuentes las modificaciones en nombres de calle, números de portales, desaparición de calles, etc. También es necesario contemplar la posibilidad de que una calle cambie de barrio y distrito y tener referencia de esa doble pertenencia en el tiempo.

• En las búsquedas hay que tener en cuenta por ejemplo los nombres que una calle ha tenido en el tiempo, los números que ha tenido un portal, o los nombres que han tenido las calles que interseccionan en un cruce.


Pág

ina:

54

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Las búsquedas se han de poder realizar de las siguientes formas:

o Por calle-numero o calle sin número.

o Por puntos de interés.

o Por cruces.

o Por posicionamiento en un mapa, con coordenadas X e Y.

• El GIS será coherente con la BDC.

• Dado que se producen modificaciones constantes, en caso de optarse por el proceso de carga este se deberá realizar con cierta frecuencia, por ejemplo semanalmente, y sin penalizar en ningún caso el rendimiento de los sistemas.

• La información básica que interesa disponer es: o Calles y portales:

� Nombre de la calle � Número de portal � El posicionamiento GPS � El barrio � El distrito � Las áreas geográficas a las que pertenece.

o Cruces de calles: � Nombre de las calles que se cruzan � El posicionamiento GPS � El barrio � El distrito � Las áreas geográficas a las que pertenece.

o Puntos singulares: � La descripción del punto singular � El posicionamiento GPS � El barrio � El distrito � Las áreas geográficas a las que pertenece.

Consulta de datos a otras aplicaciones o bases de datos Con el fin de poder consultar datos de organismos externos y de aplicaciones propias de PMM, es necesario acceder a ellos vía webservice y crear las correspondientes pantallas de consulta de información, así como las opciones de menú para poder ejecutarlas desde diversos perfiles como son los de operador o supervisor. Para el caso de consultas a aplicaciones o bases de datos del Ayuntamiento de Madrid deberá realizarse de acuerdo con los procedimientos y estándares establecidos por IAM

• Datos de vehículos y personas en la DGT.

• Datos de personas y objetos en CNP.

• Datos relativos a personas en Padrón municipal

• Información sobre licencias e inspecciones de locales (“industrias”) de PMM.


Pág

ina:

55

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







8.2. Requisitos de Explotación y mantenimiento La explotación y mantenimiento del sistema una vez implantado ha de cumplir una serie de requisitos para el correcto uso del sistema, además de lo indicado en el apartado “Soporte y Mantenimiento del Sistema” que se expone posteriormente en este documento.

Para que dicha explotación y mantenimiento se realice de forma correcta es necesario establecer los procedimientos de trabajo y protocolos de validación, al menos en relación a los siguientes puntos sobre los elementos que están dentro del alcance de este contrato:

• Soporte y mantenimiento de aplicaciones, sistemas operativos, software base, etc.

• Soporte y mantenimiento de elementos de red y comunicaciones.

• Soporte y mantenimiento de puestos de trabajo, perfiles o roles de usuario y permisos de acceso disponibles y como solicitarlos.

• Administración de bases de datos

• Relaciones en el equipo de trabajo y formas de comunicación.

• Difusión de la información

• Formación y manuales disponibles.

Será necesario por parte de la empresa adjudicataria de este contrato crear y entregar antes de la implantación del sistema un documento denominado Plan de explotación y mantenimiento con el mencionado contenido, que una vez validado por los responsables técnico y operativo del Ayuntamiento, tendrá difusión y las oportunas explicaciones sobre él a todos los usuarios y personal que intervenga en el uso del sistema de Tratamiento de Emergencias.

8.3. Requisitos de Rendimiento La operativa y manejo de las aplicaciones del nuevo sistema en los puestos de operador ha de permitir que se cumpla con los tiempos requeridos de atención a las incidencias en cada uno de sus pasos o estados, desde la recepción de la carta de llamada hasta el cierre, al menos tal y como se hace actualmente.

El tiempo de carga o apertura del sistema cuando se produzca un relevo y por tanto un cambio de usuario en un puesto debe ser lo suficientemente ágil como para no interferir en los tiempos de asignación y resolución de un incidente recibido en esos momentos.

El manejo en las aplicaciones del nuevo sistema para la apertura de ventanas, consulta y búsqueda de datos, aplicación de filtros, uso de textos predefinidos, posicionamiento en el mapa, envío de alertas, etc., será suficientemente ágil y rápido especialmente en los tipos de incidentes urgentes o donde se maneje mayor cantidad de información, como para permitir realizar todas las tareas desde la recepción de cartas de llamada hasta la asignación de patrullas en pocos segundos.

Los procesos que complementan la operativa del tratamiento de incidentes, como es la consulta del callejero, cargas de datos, la llegada al punto por GPS o las integraciones con otros sistemas tales como 112 u otras agencias, no penalizarán en ningún momento el rendimiento de dicha operativa. Por tanto serán lo suficientemente rápidos como lo son actualmente y no retrasarán al operador de PMM en su trabajo de tratamiento del incidente, ni a las agencias externas en el envío o recepción de la información que se intercambia.

El número de usuarios concurrentes y el número de incidentes simultáneos no afectará al rendimiento del sistema. Para comprobarlo será necesario que las pruebas incluyan pruebas de


Pág

ina:

56

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







rendimiento y de estabilidad del sistema.

En caso de no ser suficientemente rápida la aplicación en alguno de los puntos expuestos en este documento durante el transcurso del contrato será necesario que la empresa licitadora realice los ajustes necesarios en el sistema para conseguirlo.

8.4. Requisitos de Monitorización Con el fin de garantizar el buen uso, la disponibilidad y la estabilidad del sistema se requieren las siguientes monitorizaciones en función de quien y para qué realizarlas.

En el contexto de trabajo del supervisor de sala, se requiere que puedan ver el uso del sistema por parte de los operadores en la sala, ver el conjunto de los incidentes pendientes de cerrar, ver de cada puesto la carga de trabajo, definir y configurar el mapa de canales, crear y enviar alertas, etc., y en general realizar acciones que le permitan el reparto de carga de trabajo y la toma de decisiones sobre la gestión de los incidentes.

Este tipo de monitorización es propia de las funciones del perfil de supervisor y deberá ser cubierta mediante los permios y la configuración de dicho perfil.

En el contexto de trabajo directivos y responsables de PMM, se requiere un acceso global a la gestión de incidentes, pero sin que se puedan realizar actuaciones que afecten al desarrollo operativo de los incidentes o se pueda interferir en éstos. En consecuencia, este rol, debe permitir un acceso total a la información, en tiempo real y con un “refresco” inmediato, pero sin posibilidad de realizar cambios o gestión alguna.

En el contexto de trabajo de otros responsables y componentes de determinados servicios de PPM, se requiere un acceso como “invitado”, en el cual podrían acceder a la misma información global, sin posibilidad de cambios, pero con determinadas limitaciones, que habrían de ser programables por los administradores de la aplicación.

En el contexto de un técnico de sistemas, será necesario que se disponga de herramientas que permitan monitorizar los diferentes componentes del sistema (servidores de aplicaciones y base de datos, puestos de trabajo, equipos de comunicaciones y de red, logs y ficheros de auditoria, etc.) con el fin de detectar riesgos y adelantarse a problemas o vulnerabilidades como puedan ser lentitud o falta de rendimiento, perdida de servicio, intrusismos, etc.

Esta monitorización requiere de un sistema automático sobre los servicios que presta la infraestructura del sistema, que detecte y alerte.

El sistema de monitorización deberá generar una alerta, mensaje o aviso indicando el servicio, estado en que se encuentra, gravedad y medidas a adoptar. Actualmente se dispone de Nagios para monitorizar los sistemas de CISEM, pudiendo utilizarse ese mismo o uno similar e integrable en lo que a alertas y gestión de los sistemas se refiere.

Con el sistema de monitorización se pretende cubrir todos los sistemas y servicios. Si no fuera posible monitorizar algún sistema de manera automática, se deberá realizar comprobación manual cada cierto tiempo y según se exprese en el Plan Preventivo, que se expone en el apartado de “Servicios de Soporte y Mantenimiento”.


Pág

ina:

57

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







8.5. Requisitos de Seguridad y Confidencialidad Las restricciones de utilización del sistema y de acceso a los datos e informaciones a las personas, las políticas de establecimiento de perfiles de usuario, de trazabilidad de accesos y acciones, así como la garantía de disponibilidad e integridad, la protección del sistema frente a manipulaciones no autorizadas, y los mecanismos de utilización de las aplicaciones, así como los requisitos de seguridad en las comunicaciones y en la base de datos, se realizarán de acuerdo con los mecanismos de seguridad establecidos por el Ayuntamiento de Madrid.

El sistema de gestión de usuarios del CISEM se basa en un directorio activo de Microsoft y un dominio. Este directorio activo se utiliza para:

• Autenticar a los usuarios en el dominio y en las aplicaciones

• Determinar las aplicaciones a las que tiene acceso cada usuario

• Determinar las operaciones/opciones que puede ejecutar el usuario en cada aplicación (roles)

• Determinar el conjunto de datos que puede ver el usuario en cada aplicación (ámbitos)

En materia de seguridad y gestión de usuarios, el sistema deberá aportar al menos la misma funcionalidad que el actual sistema de CISEM e integrase con él o establecer la relación de confianza necesaria entre ambos para que sea transparente de cara a los usuarios y de cara a su administración.

Se definirán procedimientos para asegurar la fiabilidad del software y los criterios para garantizar la integridad de la información. Para ello determinar riesgos, identificar amenazas y eliminar vulnerabilidades.

Se utilizarán sistemas de control de accesos a las aplicaciones, a los datos en las bases de datos y a los sistemas de almacenamiento de ficheros y documentos anexos dada su naturaleza de posible prueba judicial, sistemas de identificación, asignación y cambio de derechos de acceso, restricción de acceso desde equipos ajenos o externos a la organización, tratamiento de la desconexión de la sesión, limitación de reintentos y procedimiento de cambio de contraseña con la suficiente complejidad o garantías para evitar suplantaciones.

8.6. Requisitos de Auditoría Con el fin de poder analizar problemas de seguridad o vulnerabilidades en el sistema, se requieren herramientas de auditoría que se adecúen a los requisitos y procedimientos para al complimiento de la normativa vigente.

Como resultado se deberá disponer de logs y ficheros de auditoria que registren toda la información posible asociada a una acción como es nombre o descripción de la acción, momento en que se realiza, cuantas veces se ha realizado dicha acción (por ejemplo número de intentos fallidos de acceso con contraseña), usuario que la ha realizado y desde que sistema o equipo.

Las acciones auditables serán al menos las siguientes:

• En la gestión de incidente, las peticiones de servicio o cartas de llamada, la asignación o des-asignación de recursos, cambios de estado, notificaciones y avisos a/de otras agencias, etc.

• En la Administración del sistema y de usuarios, las altas, modificaciones y bajas de usuarios, asignación o cambio de perfil de un usuario, cambios relevantes en la configuración del sistema como por ejemplo subidas a producción (a definir en el análisis de requisitos del sistema), etc.

• En los accesos a las aplicaciones y bases de datos.- accesos de cada usuario a las aplicaciones,


Pág

ina:

58

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







accesos a la configuración del sistema y accesos a la base de datos.

Según se indicó en el apartado correspondiente al Subsistema de Administración, este permitirá la definición, ubicación y acceso a logs y ficheros de auditoría. Se podrá configurar que información se registrará en los logs y ficheros que posteriormente se requiera auditar, así como la ubicación de dichos ficheros y un control de acceso restringido a los mismos.

9. Fases del Proyecto. En el apartado correspondiente al alcance se indican las tareas genéricas y trabajos a realizar bajo el amparo de este contrato mixto. Estas tareas se pueden resumir en 2 fases con sus correspondientes hitos.

9.1. Prestación 1: Implantación del Sistema de Tratamien to de Emergencias de PMM. La Implantación del Sistema de Tratamiento de Emergencias de PMM, con una duración prevista de 1 año, incluirá las siguientes fases:

• Análisis completo de requisitos, permitirá completar los requisitos expuestos en este documento y la matriz de ajuste de los mismos.

• Desarrollo, con un enfoque de proyecto cíclico con uso de prototipos se plantea que las sub-fases o tareas correspondientes sean las siguientes:

o Diseño de la solución propuesta y de los entornos de trabajo de producción, pruebas/formación y respaldo.

o Equipos y licencias, y preparación de los entornos. o Adaptación y configuración del sistema según los requisitos. o Integración con otros sistemas. o Preparación de prototipo y realización de pruebas en el entorno de pruebas/formación.

Estas pruebas incluirán además de pruebas de integración, pruebas de rendimiento y de estabilidad del sistema.

o Servicios de formación y transferencia tecnológica: - Formación a usuarios para el correcto uso del nuevo sistema. Se prevé que será

necesario formar a más de 300 personas entre operadores, responsables y técnicos. El contenido de esta formación contemplará la forma en que la herramienta se usará para cubrir las funcionalidades descritas en este PPT. La duración mínima para impartir dicho contenido será de 80 horas por curso a cada grupo de personas.

- Formación a técnicos de Informática y Comunicaciones, con contenido relativo a las labores básicas de administración y configuración, así como del modelo de datos a utilizar para la explotación de datos y para dar soporte de nivel 1 en caso de incidencias. Se prevé que será necesario formar al menos a 20 personas. La duración mínima para impartir dicho contenido será de 40 horas por curso a cada grupo de personas.

Estos servicios incluirán la preparación del entorno de pruebas/formación y de los equipos o puestos necesarios, así como la preparación y entrega de los manuales de usuario relativos a los contenidos a impartir y manuales de administración y configuración.

• Implantación, incluyendo las tareas de:


Pág

ina:

59

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







o Actualización del Plan de continuidad a aplicar posteriormente a la implantación incluyendo medidas preventivas, plan de contingencia, etc.

o Migración desde la plataforma actual a la nueva, de forma que se garantice la prestación ininterrumpida del servicio de recepción y gestión de llamadas, y tratamiento de emergencias, incluyendo un plan de contingencia que deberá ser aprobado por esta Dirección General de la Policía Municipal.

o Se pondrá en funcionamiento o quedará operativo tanto el entorno de producción como el de respaldo.

9.2. Prestación 2: Servicios de Soporte y Mantenimiento. Los Servicios de soporte y mantenimiento serán de 2 años a contar desde la implantación y puesta en producción definitiva del nuevo sistema, de toda la infraestructura y de sus integraciones, incluyendo los diferentes entornos, puestos de usuario, administración de las base de datos, etc. Se realizarán las siguientes tareas y servicios:

Mantenimiento correctivo. Servicio de soporte Nivel 2. Se requerirá un soporte inicial presencial de al menos 40 días en modo 24x7 y posteriormente no presencial según se define en el apartado de “Seguimiento y Control de los trabajos” mediante el acuerdo de nivel de servicio de este mantenimiento correctivo para soporte y gestión de incidencias (medidas correctivas).

El objeto del servicio de soporte es asegurar en todo momento el perfecto funcionamiento del sistema de Tratamiento de Emergencias de PMM así como su integración con otros sistemas incluidos dentro del alcance de este contrato. Por ello, una vez notificada una incidencia y si se constata la avería, una vez identificado el problema, se procederá a su solución en el menor tiempo posible, no pudiendo superar el tiempo de resolución indicado en los niveles de servicio o mediante la puesta en marcha de los medios de respaldo disponibles.

Las incidencias serán filtradas por el nivel 1 de atención de incidencias con personal propio de la DGPM o con personal externo contratado, y en caso de ser necesario trasladadas al nivel 2 de soporte del Sistema de Tratamiento de Emergencias de PMM.

El nivel 2, objeto de este contrato, deberá realizar la recogida de la incidencia que llegará por el canal de entrada actualmente establecido en CISEM, y deberá realizar el procesamiento de la misma y su resolución. También deberá realizarse un seguimiento del estado de resolución de la incidencia. Por tanto se ha de llevar un registro de las mismas con la información relacionada como es fecha de apertura y de cierre, persona de contacto, prioridad o relevancia, descripción, actuación/resolución adoptada, etc. Esta información se trasladará mensualmente como informe de soporte en formato digital al responsable técnico del Ayuntamiento para la valoración y seguimiento del nivel de servicio prestado y control de los trabajos según se indica en el apartado correspondiente de este documento.

En el caso de imposibilidad de resolución en los términos fijados en los niveles de servicio expuestos posteriormente en este Pliego, dar traslado de la situación a los servicios técnicos municipales responsables del sistema. Si existen elementos o medios alternativos para prestar el servicio, estos deben ponerse en funcionamiento hasta que se solucione la incidencia.

En las incidencias de criticidad muy alta o alta, observadas en el servicio soporte, la empresa adjudicataria deberá informar personalmente a los responsables de los servicios técnicos municipales, de las causas y consecuencias de la incidencia, así como de las actuaciones realizadas hasta su subsanación.


Pág

ina:

60

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Si fuera necesario se establecerá hacer uso del Plan de Contingencias incluido en el Plan de Continuidad.

Los servicios de nivel 2 de soporte se aplicarán a los diferentes entornos de producción, pruebas y respaldo, a las integraciones con otros sistemas, así como a las incidencias o consultas ocasionadas de los usuarios en relación a errores o problemas de uso de cualquier elemento hardware o software del sistema implantado.

Mantenimiento preventivo. En relación al mantenimiento preventivo, se entregará al comienzo de esta fase de mantenimiento un documento con el Plan Preventivo que incluya tareas de prevención tales como revisiones, pruebas o modificaciones en la configuración del sistema así como de su integración con otros sistemas, y la periodicidad en la que se realizarán dichas actuaciones.

El objeto de este mantenimiento preventivo es adelantarse y evitar en lo posible incidencias o errores, así como problemas de rendimiento o problemas no contemplados en la fase de implantación.

Este plan deberá tener en cuenta actuaciones preventivas sobre los diferentes entornos, especialmente el de producción y el de respaldo.

Los resultados serán documentados y entregados al responsable técnico del Ayuntamiento y al responsable operativo de PMM.

Mantenimiento adaptativo

Dentro del mantenimiento adaptativo se incluirán las siguientes tareas:

• Las actualizaciones de versiones, aplicación de parches y mejoras del sistema, así como del software base y cualquier otro software imprescindible para su correcto funcionamiento, como es el de base de datos, sistema operativo, GIS, etc.

Incluirá la configuración y desarrollos necesarios para cubrir los requisitos no cubiertos en la fase de implantación y los requisitos nuevos que surjan durante la vigencia del contrato.

Esta tarea incluye cualquier trabajo y coste relacionado con ella, como es instalación y configuración tanto de los puestos de usuario como de los servidores, las licencias, etc.

• Las tareas de administración que supongan cualquier cambio en la configuración del sistema que sea necesario para el correcto funcionamiento del mismo, incluidas las adaptaciones y modificaciones sobrevenidas por cuestiones legales, técnica, operativas o de procedimiento de PMM. Por ejemplo el cambio de estructura jerárquica de PMM, la adecuación de la tipología de incidentes, la modificación de áreas geográficas, etc.

• La formación a los usuarios de las modificaciones realizadas en el sistema durante esta fase de mantenimiento y que afecten a la operativa o modo de uso del sistema. En los casos en que los cambios sean sencillos será suficiente con trasladarlos mediante el correspondiente manual de usuario.

• Mantener los diferentes entornos de producción, de pruebas/formación y de respaldo en condiciones operativas, actualizados con los mismos niveles de versión y configuración similar.

• Mantenimiento y actualización de las integraciones con otros sistemas, como por ejemplo el 112, SAMUR y Bomberos. Esta tarea supondrá hacer las modificaciones necesarias tanto en la configuración y adaptación del sistema como en los desarrollos que se hubieran realizado durante la fase de implantación para conseguir las integraciones requeridas y que podrían cambiar.


Pág

ina:

61

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Actualización de cualquier documentación realizada durante el proyecto de implantación y durante el mantenimiento como es el Plan de Continuidad y de Contingencias, manuales de usuario, etc.

• Se realizará la correspondiente transferencia tecnológica a los servicios técnicos del Ayuntamiento, más allá de la formación a usuarios, en la que se trasmitirá la documentación técnica sobre la configuración de los sistemas hardware y software y la correspondiente transferencia de conocimiento. Igualmente las modificaciones en modelo de datos y del resto de entregables técnicos incluidos en apartados de “Entregables”.

Para la gestión, control y seguimiento de las tareas de mantenimiento y soporte será preciso realizar las siguientes tareas y presentarlas mensualmente a los responsables del Ayuntamiento:

• Gestión de proyecto.- Como continuación de la fase de implantación, el mantenimiento y soporte se gestionarán actualizando el Plan de Proyecto con la información del Plan Preventivo y resto de tareas planteadas indicando plazos, tareas y recursos humanos y materiales.

• Gestión y control de la configuración y la documentación utilizando para ello una herramienta consensuada entre la empresa adjudicataria y la Dirección Técnica de la DGPM, así como el control de versiones mediante Subversion.

• Gestión de cambios.- Cualquier cambio en los requisitos o modificación ocasionada por cualquier otro motivo, y que ocasione modificaciones en el sistema durante el mantenimiento ha de ser registrado y gestionado dentro de la planificación del proyecto, dando lugar a la actualización de los documentos o entregables correspondientes, tales como análisis de requisitos, configuración, pruebas, etc.

• Gestión de Incidencias.- Se ha de llevar un registro de las mismas con la información relacionada como es fecha de apertura y de cierre, persona de contacto, prioridad o relevancia, descripción, actuación/resolución adoptada, etc.

10. Entregables. Durante el contrato se entregarán los siguientes elementos (documentos, entornos, software, etc.), y serán actualizados o sustituidos si fuera necesario. Los documentos se entregarán en formato digital y versionados según lo indicado en la gestión y control de la configuración y la documentación, de forma que sea ágil y sencillo ver las modificaciones en los mismos. Se entregarán al cumplir cada hito de la planificación del proyecto, o según se indica a continuación, y serán validados por los responsables técnico y operativo del Ayuntamiento.

• Plan de Gestión del proyecto, tanto durante la fase de implantación como de soporte y mantenimiento. En caso de desvío de la planificación en más de 15 días presentará un Plan de Actuación con medidas para contrarrestar dicho desvío.

• Documento de análisis de requisitos, incluyendo matriz de ajuste de funcionalidades y análisis de funcionalidades complementarias según lo indicado en el pliego.

• Documento de Diseño de la solución propuesta. • Prototipo con la solución planteada. • Plan de pruebas y resultados de las mismas. • Manuales de usuario y Manuales de administración y configuración del sistema. • Plan de continuidad, que incluya al Plan de contingencias.


Pág

ina:

62

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Entorno de producción y entorno de respaldo completos y en funcionamiento con todo lo necesario en servidores y en puestos de usuarios: herramientas, productos, licencias y configuraciones necesarias para sustituir al sistema actual sin pérdida de servicio.

• Entorno de Pruebas/formación lo más parecido al de producción, y en el que poder realizar las pruebas y la formación. Este entorno deberá permitir hacer pruebas de diverso tipo y se contemplarán dichas pruebas en la planificación. Serán al menos de:

o Cobertura de requisitos funcionales y de interfaz. o Rendimiento.- Simular el uso de bastantes usuarios o procesos accediendo a la aplicación,

al servidor, a base de datos, etc. o Seguridad.- Validación, control de acceso, etc. o Integración.- Con 112, de acceso a la información de recursos, callejero, intercambio de

información con otros aplicativos o sistemas como los de SAMUR y Bomberos, etc. o Monitorización y auditoría.

• Documento de gestión y control de configuración, con el inventario y la descripción de la tecnología utilizada, incluyendo software base y de integración, licencias (Oracle, etc.), configuración (servidor y puestos), tareas de administración, etc. Esta información se entregará inicialmente cuando se tenga instalado el entorno de pruebas/formación, y posteriormente se irá actualizando y le irá añadiendo la información del resto de entornos y puestos.

• delo de datos necesario para la integración con otras aplicaciones y sistemas así como un usuario o forma de acceder a sus datos con los permisos necesarios, o en su defecto facilitar mediante procedimientos o desarrollos para que así sea.

Esta información se deberá entregar a los servicios técnicos del Ayuntamiento en formato consensuado con el responsable técnico del Ayuntamiento antes de finalizar la fase de pruebas, y se mantendrá añadiendo cualquier modificación posterior.

• Plan de explotación y mantenimiento con los procedimientos y protocolos establecidos para la explotación y mantenimiento del sistema según se indica en el apartado “Requisitos de explotación”. Este documento se deberá entregar, validar y difundir antes de finalizar la fase de implantación.

• En relación al mantenimiento preventivo el Plan Preventivo. Este documento se deberá entregar y validar antes de finalizar la fase de implantación.

• Informes mensuales de soporte según lo indicado en el pliego. 11. Seguimiento y control de los trabajos

El seguimiento y control de los trabajos será realizado por el responsable o Jefe de Proyecto de la empresa adjudicataria junto con los responsables técnico y operativo del Ayuntamiento.

El seguimiento del contrato se realizará a través de reuniones periódicas, inicialmente mensuales, donde el adjudicatario presentará un Informe de Seguimiento, que previamente habrá enviado por medios electrónicos y en el que se incluirá como mínimo lo siguiente:

• Plan de proyecto actualizado, y en caso de ser necesario Plan de actuación de desviación de la planificación.

• Listado de entregables y de los elementos que conforman la configuración de los entornos así como su estado, tanto en la fase de implantación como en el posterior mantenimiento.


Pág

ina:

63

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







• Informe de soporte en la fase de soporte, con la relación y detalle de las incidencias. Para el seguimiento del soporte se aplicará lo expuesto en el acuerdo de nivel de servicio.

• Documentos actualizados. Esto incluirá la última versión de los documentos de análisis de requisitos, de diseño, manuales de usuario, etc., con las modificaciones realizadas desde la anterior reunión de seguimiento.

Además los responsables del Ayuntamiento podrán establecer controles de calidad, y para ello podrán realizar o delegar para que se realicen actuaciones de control de calidad de los entregables, que permitan evitar errores y conocer el cumplimiento de los estándares a los que estarán sometidos.

11.1. Acuerdo de nivel de servicio (ANS) Con el fin de asegurar una calidad mínima en la prestación de los servicios objeto del contrato, el

adjudicatario tendrá la obligación de cumplir al menos los ANS descritos en este apartado.

Se definen los siguientes niveles de criticidad y tiempos para el tratamiento de incidencias en el servicio:

Nivel de criticidad Descripción

Alto Impacto grave en los procesos de negocio: la plataforma implicada está parada o en funcionamiento altamente degradado.

Medio Impacto moderado en los procesos de negocio. El servicio está funcionando de forma degradada.

Bajo No tiene impacto en los procesos de negocio. Afecta a entornos no productivos.

Tiempo máximo de respuesta. Es el tiempo que transcurre en alguna de estas situaciones: o Desde la asignación de la incidencia al equipo de mantenimiento hasta que éste comunica un

diagnóstico o solicita más información al usuario.

o Desde la respuesta del usuario ante una petición de más información por parte del equipo de mantenimiento y una nueva comunicación aportando el diagnóstico o solicitando nuevamente información al usuario.

En los casos en los que se sucedan varias comunicaciones justificadas de este tipo (solicitud de información-respuesta de usuario), se computará únicamente el transcurrido desde la última comunicación por parte del usuario y no el acumulado desde la asignación de dicha incidencia.

Las necesidades de consultas sucesivas sobre el mismo caso se justificarán posteriormente ante el responsable del contrato del Ayuntamiento.

Tiempo de Resolución. Es el tiempo que transcurre entre el diagnóstico del problema y una de las siguientes actuaciones:

o La resolución de la incidencia y el registro.

o La notificación de una solución alternativa para dar continuidad a la operativa del usuario.

o La anulación o reasignación de la misma, siempre con el visto bueno del responsable del Ayuntamiento.

Se entiende como resolución el restablecimiento del servicio o servicios afectados, bien con una


Pág

ina:

64

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







resolución definitiva bien con una solución temporal, un equipo de sustitución u otro mecanismo similar. En este segundo caso, la responsabilidad del adjudicatario permanecerá hasta la resolución completa del incidente, pudiendo cambiar la criticidad si es el caso. Los tiempos se miden dentro del horario de servicio.

Los tiempos se computan desde el momento en que es comunicada una incidencia. El tiempo de no disponibilidad se corresponde con el tiempo transcurrido desde dicha comunicación cuando el sistema completo está no disponible o no operativo hasta su resolución.

El sistema que utiliza la Administración deja constancia de las llamadas realizadas. Si una llamada no fuera atendida, se entenderá que el aviso se ha realizado y notificado a efectos de cómputo de tiempo.

La criticidad de una incidencia será comunicada en el aviso. Se podrá reducir o aumentar el nivel de criticidad de un incidente en cualquier momento si los responsables municipales determinan que el impacto del mismo afecta o no afecta gravemente a la operativa del servicio.

En el caso de que la incidencia afecte a más de un 5% de los puestos de operador de una ubicación se considerará el nivel de criticidad del servicio MEDIA, y cuando la incidencia afecte a más del 40% de los puestos de operador ALTA.

Si en algún aviso se prevé el incumplimiento del tiempo de resolución por causas ajenas al adjudicatario se deberá comunicar por escrito con la debida justificación al interlocutor municipal antes de que se agote el tiempo de resolución.

Las demoras injustificadas podrán dar lugar a la aplicación de penalizaciones.

Para poder cumplir con las condiciones de servicio “ALTA”, el horario de servicio del Soporte será el siguiente: Lunes a domingo, de 00:00 a 24:00

Para poder cumplir con las condiciones de servicio “MEDIA” y “BAJA”, el horario de servicio del Soporte será el siguiente: Lunes a viernes, de 08:00 a 18:00

Los tiempos de respuesta y resolución para el servicio se configuran en función del nivel de criticidad de la Incidencia relacionada según la siguiente tabla:

Nivel de criticidad

Tiempo máximo de respuesta en horas laborables

Tiempo máximo de resolución en horas laborables

Alto 15 minutos 3 horas

Medio 1 horas 12 horas

Bajo 4 horas 48 horas


Pág

ina:

65

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Los Acuerdos de Nivel de Servicio relativos a la monitorización y resolución de incidencias serán los recogidos en la siguiente tabla:

Periodo

de medición

Tiempos Establecidos acordes a la criticidad

Umbral de alerta parcial (número de

requerimientos de soporte no

atendidos en el periodo

Peso Umbral

de alerta(Ua)

Umbral máximo de

cumplimiento(Um)

Tiempo de

respuesta Mensual

Alta < 15 min. 1 4

14 42

Media < 1 h. 2 1

Baja < 4 h. 4 0,25

Tiempo de

resolución Mensual

Alta < 3 h. 1 4

Media < 12 h. 2 1

Baja < 48 h 4 0,25

Indicadores de las Condiciones de Servicio

Los indicadores asociados a la calidad del servicio serán los descritos a continuación:

• Tiempos máximos (respuesta o Resolución) ITM

• Tiempo medio de respuesta TMr

• Tiempo medio de Resolución TMR

• Tiempo máximo de no disponibilidad del sistema TMNDIS

• Tiempos máximos (respuesta o Resolución) ITM = ∑(Pi x Ni) Dónde:

- Ni es, por cada elemento del servicio y criticidad de la tabla anterior, el número de requerimientos de soporte que han superado el tiempo indicado y

- Pi el peso de cada uno de dichos elementos según la tabla anterior.

Como acuerdo de nivel de servicios requeridos (ANS), se consideran como umbral de alerta y umbral máximo de incumplimiento medio mensual del período facturado los siguientes:

Umbral de alerta (Ua) Umbral máximo de cumplimiento (Um)

14 42

Dónde:

- Ua es el Umbral de alerta medido en el número ponderado de requerimientos de servicio no


Pág

ina:

66

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







atendidos en plazo. Por debajo de este umbral el servicio es completamente satisfactorio y no se aplica ningún descuento. A partir de que se supera este umbral se dispara la alerta en cuanto a que el servicio empieza a dejar de ser satisfactorio y se empiezan a aplicar descuentos proporcionales a las distancias a dicho umbral.

- Um el Umbral máximo de cumplimiento, medido en número de requerimientos de servicio no atendidos en plazo. Cuando el valor del indicador se sitúa en este umbral se aplica el descuento máximo.

• Tiempo medio de respuesta TMr= ∑i=1,n (Tri*Pi)/N Dónde:

- Tri el tiempo de respuesta de cada incidencia.


- N es el número de incidencias atendidas en el periodo de un mes



30 minutos 1,5 h

Dónde:

- Ua es el Umbral de alerta medido en horas de los tiempos de atención de los requerimientos. Por debajo de este umbral el servicio es completamente satisfactorio y no se aplica ningún descuento. A partir de que se supera este umbral se dispara la alerta en cuanto a que el servicio empieza a dejar de ser satisfactorio y se empiezan a aplicar descuentos proporcionales a las distancias a dicho umbral.

- Um el Umbral máximo de cumplimiento, medido en horas de los tiempos de atención de requerimientos del mantenimiento operativo no atendidos en plazo. Cuando el valor del indicador se sitúa en este umbral se aplica el descuento máximo.

• Tiempo medio de Resolución TMR= ∑i=1,n (TRi*Pi)/N Dónde:

- TRi el tiempo de resolución de cada incidencia.


- N es el número de incidencias atendidas en el periodo de un mes



18h 54h

Dónde:

- Ua es el Umbral de alerta medido en horas de los tiempos de resolución de los requerimientos. Por debajo de este umbral el servicio es completamente satisfactorio y no se aplica ningún


Pág

ina:

67

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







descuento. A partir de que se supera este umbral se dispara la alerta en cuanto a que el servicio empieza a dejar de ser satisfactorio y se empiezan a aplicar descuentos proporcionales a las distancias a dicho umbral.

- Um el Umbral máximo de cumplimiento, medido en horas de los tiempos de resolución de los requerimientos de servicio no atendidos en plazo. Cuando el valor del indicador se sitúa en este umbral se aplica el descuento máximo.

• Tiempo máximo de no disponibilidad del sistema TMNDIS= ∑i=1,n (TnDIi) Dónde:

- TnDIi el tiempo de no disponibilidad del sistema debido a cada incidencia que tenga este efecto en el mes.

Como acuerdo de nivel de servicios requeridos (ANS), se consideran como umbral de alerta y umbral máximo de no disponibilidad mensual del sistema del período facturado los siguientes:


2h 6h

Dónde:

- Ua es el Umbral de alerta medido en horas no disponibilidad en el periodo. Por debajo de este umbral el servicio es satisfactorio y no se aplica ningún descuento. A partir de que se supera este umbral se dispara la alerta en cuanto a que el servicio empieza a dejar de ser satisfactorio y se empiezan a aplicar descuentos proporcionales a las distancias a dicho umbral.

- Um el Umbral máximo de cumplimiento, medido en horas no disponibilidad en el periodo. Cuando el valor del indicador se sitúa en este umbral se aplica el descuento máximo.

El ANS establece que no es admisible traspasar los umbrales, en cuyo caso se produce el incumplimiento de las condiciones de contrato dando lugar a las correspondientes penalizaciones.

El adjudicatario facilitará a Ayuntamiento informes de incidencias y de cumplimiento de los acuerdos de nivel de servicio con la periodicidad y nivel de detalle requeridos.

Del mismo modo, el adjudicatario se compromete a enviar al Ayuntamiento el informe de seguimiento del servicio correspondiente al mes anterior, entre los días 1 y 5 de cada mes.


Pág

ina:

68

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







11.2. Ejemplo de cálculo de indicadores de nivel de servi cio (ANS) A continuación se muestra un caso concreto de cómo aplicar y calcular estos indicadores, partiendo

de unas hipotéticas incidencias ocurridas en un sistema durante un periodo de un mes.

En la tabla se muestran los datos de 15 incidencias con sus niveles de criticidad, pesos asociados, tiempos de respuesta y de resolución.

Incidencia Nivel de Criticidad

Peso (Pi)

T.Respuesta (Tr)

T.Resolución (TR)

Parada del Sistema (S/N)

Incumplimientos (Ni)

PixNi Tr Normalizado (Pi x Tr)

TR Normalizado (Pi x TR)

1 Alto 4 0,25 1 S 0 0 1 4 2 Bajo 0,25 2 30 N 0 0 0,5 7,5 3 Bajo 0,25 3,25 10 N 0 0 0,8125 2,5 4 Bajo 0,25 4 2 N 0 0 1 0,5 5 Bajo 0,25 3 1 N 0 0 0,75 0,25 6 Bajo 0,25 4 3 N 0 0 1 0,75 7 Bajo 0,25 5,5 4 N 1 0,25 1,375 1 8 Bajo 0,25 2,5 49 N 1 0,25 0,625 12,25 9 Bajo 0,25 1 1 N 0 0 0,25 0,25 10 Bajo 0,25 2,25 2 N 0 0 0,5625 0,5 11 Bajo 0,25 3 9 N 0 0 0,75 2,25 12 Bajo 0,25 0,5 9 N 0 0 0,125 2,25 13 Medio 1 1 6 N 0 0 1 6 14 Medio 1 1 19 N 1 1 1 19 15 Medio 1 0,5 40 N 1 1 0,5 40 16 Medio 1 0,16 20 N 1 1 0,16 20 17 Medio 1 0,5 1 N 0 0 0,5 1 18 Medio 1 1 2 N 0 0 1 2 19 Medio 1 1,5 12 N 1 1 1,5 12 20 Medio 1 2 20 N 2 2 2 20

Los tiempos máximos de respuesta y resolución de los indicadores del ANS, resumidos en la siguiente tabla, marcan que las incidencias 7, 8, 14, 15, 16, 19 y 20 producen incumplimientos de dichos tiempos, concretamente 2 de nivel bajo y 6 de nivel medio. Además la incidencia 1 produjo una no disponibilidad del sistema.

El resto de los tiempos de incidentes que aparecen en este ejemplo son menores o iguales a los requeridos por lo que son acordes a la criticidad establecida y por tanto no son aplicables descuentos por incumplimientos.

Nivel de criticidad Peso

Tiempo máximo

de respuesta (horas)

Tiempo máximo

de resolución (horas)

Nº incidentes máx

(en el periodo)

Alto 4 0,25 (15 minutos) 3 1

Medio 1 1 12 2

Bajo 0,25 4 48 4


Pág

ina:

69

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







Para ver si son aplicables descuentos por esos incumplimientos es preciso calcular los indicadores y compararlos con los umbrales de cada indicador:

ITM = ∑i=1,n(Pi x Ni) = 6,5

TMr = ∑i=1,n (Tri*Pi)/N = 0,8205

TMR = ∑i=1,n (TRi*Pi)/N = 7,7

TMNDIS = ∑p=1,q TRp = 1

Indicador Umbral alerta (Ua) Umbral máx,cumpl.(Um)

ITM 14 42

TMr 0,50 1,50

TMR 18 54

TMNDIS 2 6

Siendo TMr el indicador que supera el umbral de alerta 0,50 al tener un valor de 0,8205. El resto están por debajo de dicho umbral.

11.3. Requisitos de equipo de trabajo, entorno tecnológic o y material. Para la correcta realización de los trabajos establecidos y dar cumplimiento a la Instrucción 5/2012 sobre servicios externos contratados por el Ayuntamiento de Madrid y los Entes que conforman su Sector Público, en materia de personal para la correcta gestión de los contrato de servicio, se establecen los siguientes requisitos para las prestación 1 y 2:

o La empresa adjudicataria constituirá un equipo de trabajo cuyos componentes serán expertos, en la medida que lo requiera su función, en los productos sobre los que se prestará el servicio.

o El Jefe de Equipo designado por el contratista será el único interlocutor con el Responsable del Contrato propuesto por los servicios técnicos del Ayuntamiento de Madrid para este proyecto, y será obligación de la empresa contratista el designar sustituto para los supuestos de ausencia del mismo.

o El personal de la empresa adjudicataria estará ubicado tanto en sus propias dependencias, como en una dependencia concreta e independiente dentro del edificio de Ayuntamiento de Madrid, debiendo el personal de las empresas contratistas portar durante su estancia en Ayuntamiento de Madrid la correspondiente identificación, y se abstendrá de emplear medios y materiales de titularidad de la Administración.

o A la extinción de los contratos de servicios, no podrá producirse en ningún caso la consolidación de las personas que hayan realizado los trabajos objeto del contrato como personal del organismo autónomo contratante.

o La presente contratación no creará vinculación laboral alguna entre el personal que se destine a la ejecución del contrato y el Ayuntamiento de Madrid. Dicho personal estará expresamente sometido al poder direccional y de organización de la empresa adjudicataria en todo ámbito y orden legalmente establecido, siendo, por tanto, ésta la única responsable y obligada al cumplimiento de cuantas disposiciones legales resulten aplicables.


Pág

ina:

70

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







o A la extinción del contrato de servicios, no podrá producirse en ningún caso la consolidación de las personas que hayan realizado los trabajos objeto del contrato como personal del organismo autónomo contratante.

o El adjudicatario se compromete a proporcionar a sus equipos los medios necesarios para poder realizar las entregas en los formatos de las herramientas necesarias, especialmente en el caso de aquellas entregas que deban realizarse mediante herramientas de puesto o clientes. El Ayuntamiento de Madrid proporcionará al adjudicatario la infraestructura para el uso de todas las herramientas centralizadas.

o El adjudicatario deberá proporcionar los medios materiales necesarios para la ejecución del contrato (móvil, portátil, todo el software necesario para el servicio requerido en el proyecto concreto, etc.), así como las comunicaciones de datos entre las dependencias desde las que el equipo designado realice los servicios, en su caso, y las municipales implicadas en aquél.

12. Control económico y facturación Durante la ejecución de los trabajos y con anterioridad a la emisión de las certificaciones se

comprobará la adecuación de los servicios prestados, y los nuevos elementos entregados.

En las reuniones de seguimiento y control se evaluarán todas aquellas circunstancias habidas en el servicio en el período anterior. Cuando se hayan originado retrasos en la resolución de las incidencias, y cuando tales circunstancias sean, a juicio de los responsables técnico y operativo del Ayuntamiento, imputables al adjudicatario, por falta de responsabilidad, incompetencia, desidia u otras causas de índole similar, se incluirán en la Fórmula de cumplimiento de las condiciones de servicio, sin perjuicio de las acciones y penalizaciones que, de acuerdo con la normativa vigente y el pliego de cláusulas administrativas, resulten procedentes.

Las facturaciones parciales se realizarán de acuerdo a lo indicado en el Pliego de Cláusulas Administrativas, y de acuerdo a lo siguiente:

Prestación 1.- Se definen 3 hitos de la siguiente forma:

• Hito 1.- Este hito finalizará 3 meses después de los comienzos de los trabajos. Con este hito se deberá entregar al menos:

o Plan Gestión de proyecto de Implantación.

o Documento de Análisis de Requisitos en modo borrador con la matriz de ajuste de funcionalidades y análisis de funcionalidades complementarias, y junto con las correspondientes actas de reuniones realizadas y documentación anexa.

o Plan de Formación.

o Plan de Integración. o Documento de Diseño.

o Herramientas, productos, ampliación de entorno de virtualización y de almacenamiento y licencias, así como la instalación y configuración de la plataforma hardware y software correspondiente a los diversos entornos necesarios para implantar la solución propuesta para sustituir al sistema actual sin pérdida de servicio.

o Plan de pruebas.

o Informes mensuales de seguimiento.

• Hito 2.- Este hito, con una duración prevista de 6 meses, comenzará inmediatamente después de


Pág

ina:

71

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







la finalización y aprobación del hito 1, con la entrega de los siguientes elementos descritos en el apartado de fases de proyecto y el apartado de entregables de este pliego:

o Entregables del hito 1 actualizados. o Prototipo con la solución planteada en el entorno de pruebas. o Manuales de usuario y Manuales de administración y configuración del sistema en modo

borrador o Plan de continuidad, que incluya al Plan de contingencias. o Documento de gestión y control de configuración. o Documentos técnicos y código fuente relativo a los desarrollos realizados hasta la fecha.

o Modelo de datos definido o utilizado hasta la fecha.

o Informes mensuales de seguimiento.

• Hito 3.- Se corresponde con la finalización de la prestación 1, con la implantación y entrega final de todo lo indicado en la misma. Su duración prevista es de 3 meses y comenzará inmediatamente después de la finalización y aprobación del hito 2.

Prestación 2.- Se realizarán PAGOS MENSUALES PARCIALES Y PROPORCIONALES según el importe correspondiente a cada año y lo indicado en el Pliego de Cláusulas Administrativas.

Los importes de facturación estimados para la licitación de este contrato son los siguientes:

Prestación 1: Importe 1.814.516,00 € IVA incluido (1.499.600,00 € sin IVA)

• Hito 1: Importe 1.124.271,50 € IVA incluido (929.150,00 € sin IVA).

• Hito 2: Importe 460.163,00 € IVA incluido (380.300,00 € sin IVA).

• Hito 3: Importe 230.081,50 € IVA incluido (190.150,00 € sin IVA).

Prestación 2: Importe 848.089,00 € IVA incluido (700.900,00 € sin IVA)

Año 1: Importe 434.450,50 € IVA incluido (359.050,00 € sin IVA)

Año 2: Importe 413.638,50 € IVA incluido (341.850,00 € sin IVA)

13. Transferencia tecnológica Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete, en todo

momento, a facilitar a las personas designadas por el Director Técnico de la DGPM a tales efectos, la información y documentación en lengua castellana que estas soliciten para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos, y herramientas utilizados para resolverlos.

A la finalización del contrato quedarán a disposición de la DGPM cualquier documentación o entregable realizados durante la ejecución del proyecto así como el código fuente desarrollado durante el mismo para las adaptaciones e integraciones requeridas y los diferentes entornos con sus correspondientes herramientas software y licencias actualizadas y vigentes hasta la fecha.


Pág

ina:

72

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







14. Propiedad intelectual y seguridad El adjudicatario entregará en formato electrónico los productos resultantes de los trabajos al amparo

del presente contrato, y aceptará expresamente que los derechos de explotación de los mismos corresponden únicamente a Dirección General de la Policía Municipal, con exclusividad y a todos los efectos.

En lo referente a los desarrollos que se hagan durante el transcurso del proyecto para integrar con otras aplicaciones o herramientas externas estos trabajos sí pasarán a ser propiedad del Ayuntamiento, tanto la documentación y desarrollos como código fuente o cualquier otro elemento resultante de dichos trabajos de integración.

15. Condiciones de Garantía La garantía de los trabajos realizados y modificaciones en el software entregado e instalado será de

dos años a contar desde la finalización del contrato.

Esta garantía cubre posibles fallos de funcionamiento en el software. Ante un eventual fallo de este tipo se entregará un nuevo parche o versión, y su instalación y configuración, y la documentación estarán igualmente cubiertos por esta garantía. La empresa adjudicataria deberá cumplir obligatoriamente esta cláusula de garantía en un plazo determinado y consensuado con el Dpto. de Informática de la DGPM.

En el caso de la prestación 1 la garantía cubrirá todos los entregables y los trabajos realizados durante dicha prestación desde el momento en que se apruebe y recepcione el hito 3, momento en el cual comenzará la prestación 2.

La garantía de los trabajos realizados durante la prestación 2 comenzará después de cada entrega o mantenimiento realizado.

16. Documentación Técnica Cada licitante deberá aportar en el sobre de documentación administrativa una memoria técnica. Esta

memoria técnica deberá contener como máximo 40 páginas en formato DINA4, con interlineado sencillo, fuente Arial 11 puntos, márgenes laterales 3 cm, márgenes superior e inferior de 2,5 cm. En caso de superarse las 40 páginas, a partir de la 41 incluida no se considerarán ni valorarán esas páginas.

Incluirá con el máximo detalle al menos los siguientes apartados: 1. Plan de Proyecto de Implantación que incluya el detalle de las tareas con sus fases e hitos, los

responsables, los recursos y perfiles que las realizarán y el calendario propuesto. Se deberán indicar las fases y cuando se realizará la implantación sustitutiva y si habrá periodo en paralelo con el actual sistema SITE, y en tal caso como se hará.

2. Plan de Formación.- Detallará como realizar la formación a los diferentes roles o perfiles del operativo (operador, supervisor, etc.) así como a los técnicos de Informática y Comunicaciones, indicando resumen del contenido, calendario y medios para realizar dicha formación.

3. Matriz de ajuste de funcionalidades expuestos en este documento, indicando en dicha matriz al menos la siguiente información

� Identificación del requisito de forma codificada. � Tipo de requisito: funcional, de integración, etc.


Pág

ina:

73

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







� Descripción del requisito. � Requisito obligatorio: Sí/No � Prioridad del requisito:

- Nivel 1: Obligado, para el cumplimiento de las necesidades operativas o técnicas. - Nivel 2: Recomendable no obligado, puede cumplirse parcialmente o

posteriormente. - Nivel 3: Deseable, puede no cumplirse ya que no afecta a las necesidades

operativas o técnicas siendo considerado como una mejora para facilitarlas. � Trazabilidad: Id. Requisito asociado/relacionado. � Sistema externo: Nombre del sistema externo relacionado o del que depende. � Forma de cobertura por parte del sistema a implantar:

- Mediante configuración o parametrización. - Cubierto en nueva versión o programación estándar soportada por el sistema. - Programación no estándar o externa al sistema, y no soportada en futuras

versiones. - No cubierto.

� Tiempo o fase estimada para el cumplimiento del requisito - En la implantación inicial - Nº de meses previstos necesarios para la cumplir el requisito. - No cubierto.

Junto con la matriz de requisitos se presentará un análisis de funcionalidades complementarias o de requisitos no cubiertos, identificando aquellos requisitos prioritarios no cubiertos y los riesgos asociados.

4. Plan de integración con otros sistemas (telefonía, callejero, Asignación, 112, cámaras, SITREM externo, etc.), indicando tareas y modo de abordar dicha integración, así como fase en la que plantea tener la integración (en la implantación inicial, previsión de número de meses posteriores a la implantación, etc.).

5. Plan de Soporte y Mantenimiento, indicando: � Tareas a realizar. � Número de personas � Perfiles técnicos � Dedicación a tareas en % o en horas.

La no presentación de esta memoria con los requisitos mínimos dará lugar a la NO admisión de la oferta.

17. Cláusulas Sociales Los servicios objeto de este contrato deberán desarrollarse respetando las normas socio-laborales

vigentes en España y en la Unión Europea o de la Organización Internacional del Trabajo.

El cumplimiento de las cláusulas sociales deberá acreditarse en los 3 primeros meses desde la formalización de contrato.

En toda la documentación, publicidad, imagen o materiales que deban aportar los licitadores o que sean necesarios para la ejecución del contrato, deberá hacerse un uso no sexista del lenguaje, evitar


Pág

ina:

74

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







cualquier imagen discriminatoria de las mujeres o estereotipos sexistas, y fomentar con valores de igualdad la presencia equilibrada, la diversidad y la corresponsabilidad.

La empresa adjudicataria tiene la obligación de adoptar las medidas de seguridad y salud en el trabajo que sean obligatorias para prevenir de manera rigurosa los riesgos que puedan afectar a la vida, integridad y salud de las personas trabajadoras asignadas a la prestación objeto del contrato.

Asimismo, deberá acreditar el cumplimiento de las obligaciones siguientes: • La evaluación de riesgos y planificación de la actividad preventiva correspondiente a las

actividades que constituyen la prestación contratada. • La formación e información en materia preventiva a las personas adscritas a la ejecución

del contrato. • El justificante de la entrega de equipos de protección individual que, en su caso, sean

necesarios.

La empresa adjudicataria deberá acreditar el cumplimiento de estos extremos mediante la documentación de las actuaciones realizadas en materia de prevención de riesgos laborales que correspondan en cada una de las actividades que constituyen la prestación objeto del contrato.

La empresa adjudicataria deberá acreditar mediante declaración responsable la afiliación y el alta en la Seguridad Social de las personas trabajadoras destinadas a la ejecución del contrato. Esta obligación se extenderá a todo el personal subcontratado por la empresa adjudicataria principal, destinado en la ejecución del contrato.

Con carácter previo a la finalización del contrato, la empresa adjudicataria deberá presentar un informe relativo al cumplimiento de las cláusulas sociales exigidas en este contrato, con la evaluación de las intervenciones planificadas.

18. Condición especial de ejecución de carácter social La empresa adjudicataria deberá adoptar medidas que favorezcan la conciliación de la vida personal,

laboral y familiar de las personas trabajadoras adscritas a la ejecución del contrato. Las medidas a adoptar deberán describirse, siendo medidas sobre los siguientes aspectos:

- Medidas en la mejora del empleo y de desarrollo profesional: Son medidas que faciliten la estabilidad del puesto de trabajo, la realización de reconocimientos médicos, la formación en prevención de riesgos, permitir la formación en horario laboral, la formación específica del puesto de trabajo, un plan de promoción interna, un plan de desarrollo competencial, etc.

La empresa licitadora deberá demostrar haber ejecutado un plan de formación en seguridad y salud en el trabajo de al menos 2 horas de duración, para las personas trabajadoras adscritas a la ejecución del contrato.

- Medidas en relación a la flexibilidad temporal.- Se trata de medias que faciliten la jornada continua, la jornada flexible con un mínimo de 2 horas semanales, permitir excedencias de corta duración, facilitar el intercambio de horas de trabajo por horas de descanso, la reducción de jornada por estudios, el permiso no retribuido por motivos personales, la posibilidad de acumular las vacaciones tras la baja maternal o el


Pág

ina:

75

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







permiso de paternidad, disponer de protocolos de protección para trabajadoras víctimas de violencia de género, etc.

La empresa licitadora deberá tener medidas de conciliación laboral y personal de forma definida y publicada.

- Medidas de apoyo a la familia.- Medidas que faciliten el permiso de lactancia acumulado, permiso de paternidad, permiso de 15 días para uniones de hecho, permiso no retribuido por enfermedad de hijos/as o familiares, permiso no retribuido para acompañar a familiares o personas dependientes, modificar el horario por motivos personales o familiares, reducción de jornada o excedencia por cuidado de hijos o familiares enfermos, etc.

- Medidas de igualdad de oportunidades: Medidas que faciliten una política de promoción interna y carrera profesional con perspectiva de género, el acceso de mujeres a puestos de responsabilidad, oportunidades de crecimiento profesional con independencia del género, formación con independencia de la categoría profesional y el género, ofertas de trabajo neutras, formación y sensibilización en igualdad de oportunidades, etc.

Se realizará un seguimiento del cumplimiento de estas condiciones especiales de ejecución cada año antes de la liquidación de la primera factura a partir del segundo año de vigencia del contrato y en años sucesivos, de forma que la empresa deberá presentar declaración responsable al respecto.


Pág

ina:

76

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







19. Cláusula de Confidencialidad

CONFIDENCIALIDAD, PROTECCIÓN DE DATOS PERSONALES Y SEGURIDAD DE LA INFORMACIÓN

La empresa adjudicataria y el personal a su servicio en la prestación del contrato, tal y como se define en la letra g) del artículo 3 de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, están obligados en su calidad de encargados de tratamiento de datos personales por cuenta del (Órgano de contratación) al cumplimiento de lo dispuesto en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, el 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, así como de las disposiciones que en materia de protección de datos se encuentren en vigor a la adjudicación del contrato o que puedan estarlo durante su vigencia.

La empresa adjudicataria se obliga especialmente a lo siguiente:

1º) Deberá guardar la debida confidencialidad y secreto sobre los hechos, informaciones, conocimientos, documentos y otros elementos a los que tenga acceso con motivo de la prestación del servicio (art. 10 LOPD), sin que pueda conservar copia o utilizarlos para cualquier finalidad distinta a las expresamente recogidas en el presente pliego, incurriendo en caso contrario en las responsabilidades previstas en la legislación vigente (art. 12.4 LOPD). Igualmente, deberá informar a sus empleados de que sólo pueden tratar la información del Ayuntamiento para cumplir los servicios objeto de este pliego y también de la obligación de no hacer públicos, ceder o enajenar cuantos datos conozcan (artículo 9 LOPD). Esta obligación subsistirá aún después de la finalización del contrato.

2º) Asimismo, deberá incluir una cláusula de confidencialidad y secreto en los términos descritos (art. 10 LOPD) en los contratos laborales que suscriban los trabajadores destinados a la prestación del servicio objeto del presente pliego. La empresa adjudicataria, al igual que su personal, se someterán a los documentos de seguridad vigentes en el Ayuntamiento de Madrid para cada uno de los ficheros a los que tengan acceso, e igualmente a las especificaciones e instrucciones de los responsables de seguridad en materia de protección de datos de cada una de las dependencias municipales afectadas.

3º) Dicho compromiso afecta tanto a la empresa adjudicataria como a los participantes y colaboradores en el proyecto y se entiende circunscrito tanto al ámbito interno de la empresa como al ámbito externo de la misma. El Ayuntamiento de Madrid se reserva el derecho al ejercicio de las acciones legales oportunas en caso de que bajo su criterio se produzca un incumplimiento de dicho compromiso.

4º) Únicamente tratará los datos personales a los que tenga acceso para la prestación del contrato conforme al contenido de este pliego de prescripciones técnicas y a las instrucciones que el (Órgano de contratación) le pueda especificar en concreto y que se incluirían como una Adenda al presente contrato. No aplicará o utilizará los datos personales indicados con fin distinto al previsto en el contrato, ni los comunicará, ni siquiera para su conservación, a otras personas salvo autorización expresa por parte del responsable del fichero en los términos previstos en el artículo 21 del Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.

5º) A cumplir todas y cada una de las medidas de seguridad (nivel básico, medio o alto) que sean de aplicación en función de la tipología de datos que se utilicen y traten para la prestación del servicio objeto


Pág

ina:

77

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







del presente contrato y que vienen previstas en el Título VIII del Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal. A este respecto no se registrarán datos de carácter personal en ficheros que no reúnan las condiciones determinadas en el referido Titulo VIII respecto a su integridad y seguridad y a las de los Centros de tratamiento, locales, equipos, sistemas y programas. (Artículo 9.2. LOPD).

Durante la realización de los servicios que se presten como consecuencia del cumplimiento del presente contrato, el adjudicatario y su personal se someterán al estricto cumplimiento de los documentos de seguridad vigentes para los ficheros de datos de carácter personal a los que tengan acceso, así como a las instrucciones de los responsables de seguridad de las dependencias municipales en las que desarrollen su trabajo.

El acceso a las bases de datos del Ayuntamiento de Madrid necesarias para la prestación del servicio se autorizará al adjudicatario para el exclusivo fin de la realización de las tareas objeto de este contrato, quedando prohibido para el adjudicatario y para el personal encargado de su realización su reproducción por cualquier medio y la cesión total o parcial a cualquier persona física o jurídica. Lo anterior se extiende asimismo al producto de dichas tareas.

El adjudicatario se compromete a formar e informar a su personal en las obligaciones que de tales normas dimanan, para lo cual programará las acciones formativas necesarias.

El personal prestador del servicio objeto del contrato tendrá acceso autorizado únicamente a aquellos datos y recursos que precisen para el desarrollo de sus funciones.

6º) Los diseños, desarrollos o mantenimientos de software deberán, con carácter general, observar los

estándares que se deriven de la normativa de seguridad de la información y de protección de datos, y en concreto lo relativo a la identificación y autenticación de usuarios, estableciendo un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado, limitando la posibilidad de intentar reiteradamente el acceso no autorizado al sistema de información.

7º) El Ayuntamiento de Madrid se reserva el derecho de efectuar en cualquier momento los controles

y auditorias que estime oportunos para comprobar el correcto cumplimiento por parte del adjudicatario de sus obligaciones, el cual está obligado a facilitarle cuantos datos o documentos le requiera para ello.

8º) Todos los datos personales que se traten o elaboren por la empresa adjudicataria como consecuencia de la prestación del contrato, así como los soportes del tipo que sean en los que se contengan son propiedad del Ayuntamiento de Madrid.

9º) Una vez cumplida la prestación contractual, los datos de carácter personal deberán ser destruidos o devueltos al Ayuntamiento de Madrid conforme a las instrucciones que haya dado, al igual que cualquier soporte o documento que contenga algún dato de carácter personal objeto del tratamiento.

10º) De conformidad con lo que establece el artículo 12.4 de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, el incumplimiento por parte del adjudicatario de las estipulaciones del presente contrato lo convierten en responsable del tratamiento respondiendo directamente de las infracciones en que hubiera incurrido, así como del pago del importe íntegro de cualquier sanción que, en materia de protección de datos de carácter personal, pudiera ser impuesta al Ayuntamiento de Madrid, así como de la totalidad de los gastos, daños y perjuicios que sufra el Ayuntamiento de Madrid como consecuencia de dicho incumplimiento (art. 12.4 LOPD).


Pág

ina:

78

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4







11º) Aportará una memoria descriptiva de las medidas que adoptará para garantizar la seguridad, confidencialidad e integridad de los datos manejados y de la documentación facilitada. Dicha memoria deberá contener el nivel de seguridad que permite alcanzar así como información sobre la posibilidad de definir distintos perfiles de acceso, existencia de un mecanismo de identificación y autenticación y, en su caso, descripción de la gestión de contraseñas. También y cuando proceda, el tratamiento que se aplicará a los soportes y documentos, el procedimiento de gestión de copias de respaldo y el contenido del registro de accesos. Asimismo, el adjudicatario deberá informar al organismo contratante, antes de transcurridos siete días de la fecha de comunicación de la adjudicación, la persona que será directamente responsable de la puesta en práctica y de la inspección de dichas medidas de seguridad, adjuntando su perfil profesional”.

12º)Se comprometerá a la no difusión de ningún tipo de código de acceso o cualquier otro tipo de información que pueda facilitar la entrada a los sistemas del CISEM , así como a no hacer un uso incorrecto de los permisos y privilegios que se concedan a su personal para la ejecución de este contrato.

Igualmente adoptará las medidas para que el personal asociado al desarrollo de este contrato respete estas condiciones de seguridad.


Pág

ina:

79

de 7

9

Cód

igo

de v

erifi

caci

ón :

PY

3e43

039f

2c66

a4

Par

a la

ver

ifica

ción

del

sig

uien

te c

ódig

o po

drá

cone

ctar

se a

la s

igui

ente

dire

cció

nhttp

://w

ww

-2.

mun

imad

rid.e

s/V

erifi

caci

onC

ove/

Cot

ejoC

OV

E.js

p?co

digo

Ver

ifica

cion

=P

Y3e

4303

9f2c

66a4



CONTRATO MIXTO DE SUMINISTRO Y SERVICIOS TITULAD O ... · implantación y posterior...

Documents

Transcript of CONTRATO MIXTO DE SUMINISTRO Y SERVICIOS TITULAD O ... · implantación y posterior...