Sistema de venda d'entrades al Zoo de Barcelona · nents unitats de control i perifèrics (lectors,...

Zoo de Barcelona – Barcelona de Serveis Municipals, SA

Zoo de Barcelona · Divisió de Sistemes d‟Informació

Barcelona, 10 de març de 2016

SISTEMA DE CONTROL D’ACCÉS I

CONTROL D’AFORAMENT

DEL ZOO DE BARCELONA

Plec de condicions tècniques

del sistema de control d’accés i

control d’aforament del Zoo de Barcelona

Sumari

Plec de condicions tècniques d‟un sistema per al control d‟accés i control

d‟aforament de les entrades i sortides del parc zoològic de Barcelona.

El plec s‟inicia presentant breument el model tècnic i operatiu del sistema

i posteriorment es desenvolupen els seus requeriments tècnics i funcio-

nals. Finalment, es presenten les condicions de lliurament del projecte,

estructurades entorn els plans d‟execució.

plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 2

B:SM

ÍNDEX DE CONTINGUTS

1. INTRODUCCIÓ _________________________________________________ 4

ABAST I ÀMBIT D‟APLICACIÓ .................................................................................... 4

ÀMBIT DE SUBMINISTRAMENT .................................................................................. 5

2. MODEL DE VENDA I ACCÉS AL ZOO _______________________________ 6

TIPUS D‟ENTRADES ................................................................................................ 6

MODEL TÈCNIC ...................................................................................................... 7

CODIFICACIÓ DE LES ENTRADES .............................................................................. 8

3. REQUERIMENTS FUNCIONALS ___________________________________ 9

DIAGRAMES DEL SISTEMA ...................................................................................... 9

VALIDAR L‟ACCÉS AL RECINTE ............................................................................... 11

Validar entrades de taquilles ......................................................................... 11

Validar entrades dels socis ........................................................................... 12

Validar entrades Internet ............................................................................... 13

Validar invitacions ......................................................................................... 13

Validar accés de treballadors ........................................................................ 14

Resoldre incidències ..................................................................................... 14

CONTROLAR AFORAMENT REAL ............................................................................. 16

CONTROLAR ELS TORNS ....................................................................................... 18

EXPLOTAR DADES D‟ACCÉS I AFORAMENT .............................................................. 19

ADMINISTRAR I CONFIGURAR EL SISTEMA ............................................................... 21

4. REQUERIMENTS TÈCNICS ______________________________________ 22

CRITERIS DE DISSENY .......................................................................................... 23

MÒDUL DE CONTROL D‟ACCÉS .............................................................................. 24

Torn d‟accés ................................................................................................. 25

Pilona d‟emergència ..................................................................................... 26

Lector i validador d‟entrades ......................................................................... 27

Dispositiu mòbil PDA .................................................................................... 28

Dimensionament dels accessos al Zoo ......................................................... 30

APLICACIÓ DE CONTROL D‟AFORAMENT .................................................................. 31

APLICACIÓ DE BACKOFFICE .................................................................................. 32

SERVEIS CENTRALS ............................................................................................. 33

Entorn d‟execució ......................................................................................... 33

Continuïtat del servei .................................................................................... 34

Monitoratge del sistema ................................................................................ 34

Enregistrament de dades històriques ............................................................ 35


B:SM

Nivell de servei del sistema........................................................................... 35

Infraestructura de xarxa ................................................................................ 36

INTEGRACIÓ AMB SISTEMES I SERVEIS .................................................................... 37

Integració amb Sistema de Gestió de Socis (SGS) ...................................... 37

Integració amb el sistema de venda d‟entrades a taquilles ........................... 38

Integració amb el mòdul d‟entrades web del Zoo .......................................... 38

Integració amb altres canals de venda per Internet ...................................... 39

5. PLANS D’EXECUCIÓ ___________________________________________ 40

PLA D‟IMPLANTACIÓ ............................................................................................. 41

Cronograma i àmbit d‟intervenció ................................................................. 42

Pla de migració ............................................................................................. 45

Gestió del projecte ........................................................................................ 46

PLA DE FORMACIÓ ............................................................................................... 47

PLA DE MANTENIMENT .......................................................................................... 48

Manteniment correctiu i suport a l‟operació................................................... 48

Nivell de servei de resolució d‟incidències .................................................... 49

Manteniment preventiu i evolutiu .................................................................. 50

Període de garantia ...................................................................................... 51

Instal·lació i configuració dels components ................................................... 51

PLA DE PROVES ................................................................................................... 52

PLA DE CONTINGÈNCIA ......................................................................................... 53

PLA D‟ACCEPTACIÓ .............................................................................................. 54

Documentació tècnica ................................................................................... 55

Propietat intel·lectual ..................................................................................... 56

Llicenciament del programari ........................................................................ 56

Actualitzacions del programari ...................................................................... 56

Codi font de les aplicacions .......................................................................... 56


1. INTRODUCCIÓ

Barcelona de Serveis Municipals (B:SM) és una empresa de titularitat municipal que gesti-

ona algunes de les principals infraestructures de Mobilitat i Lleure de la

ciutat.

Entre d‟altres, B:SM gestiona el Parc Zoològic de Barcelona.

Actualment, el Zoo preveu implantar un nou sistema de control d‟accés i

control d‟aforament en totes les entrades i sortides del Parc a fi i efecte

de millorar l‟operativa d‟accés i validació d‟entrades del recinte.

Durant la darrera dècada, els models i els sistemes de venda d‟entrades (ticketing) i de

control d‟accés per parcs han evolucionat en la mesura en que ho ha fet la tecnologia i,

molt especialment, els hàbits dels espectadors, que ja compren entrades per Internet i

accedeixen al recinte amb entrades, invitacions i promocions en diferents formats identifi-

cats amb codis de barres.

El present plec tècnic descriu els requeriments i els plans d‟execució per al subministra-

ment, implantació, operació i manteniment d‟un sistema de control d‟accés i control

d‟aforament per a totes les entrades i sortides del Parc.

ABAST I ÀMBIT D’APLICACIÓ

L‟abast del present sistema de control d‟accés és la validació d‟entrades en tots els punts

de d‟accés al Parc Zoològic de Barcelona: accés Wellington, accés Prim, Escola, etc., així

com també el control de les sortides del recinte: sortida Wellington, sortida Prim, etc.

Gràfic 1: abast i àmbit d‟aplicació del sistema de control d‟accés del Zoo de Barcelona

El Sistema de control d‟accés del recinte ha d‟estar plenament integrat amb el sistema de

venda d‟entrades de taquilles (en licitació), amb el sistema de gestió de socis Zoo Club

(SGS) i amb el mòdul de venda per Internet (EuroMus) per tal de validar i permetre l‟accés

a les entrades emeses per taquilles, als socis, a les invitacions i a les entrades venudes

per Internet.

http://www.bsmsa.cat/

http://www.euromus.cat/

INTRODUCCIÓ: Àmbit de subministrament 5

B:SM

ÀMBIT DE SUBMINISTRAMENT

Seguidament es resumeixen els principals àmbits d’intervenció i de subministrament de

l‟Adjudicatari del present plec de condicions tècniques:

programari de control d’accés: disseny, desenvolupament, instal·lació, configuració, proves,

formació i manteniment de les aplicacions client i servidor del sistema per validar entrades i

controlar l‟accés al Parc.

L‟aplicació de control d‟accés ha de poder validar entrades del Parc d‟acord amb el model de

venda i validació descrit en el present plec tècnic i que es desenvoluparà en la fase de dis-

seny.

El Sistema també ha d‟incloure una aplicació de BackOffice per poder configurar les portes i

per poder explotar estadísticament les dades de validació i accés, entre d‟altres..

maquinari de control d’accés: disseny, fabricació, mecanització, instal·lació, configuració,

proves, formació, manteniment i suport a l‟operació dels mobles i del maquinari del sistema

per validar entrades i controlar l‟accés en les diferents entrades i sortides del Parc.

El Sistema ha d‟incloure els torns (mobles, torniquets, comandaments, etc.) i les correspo-

nents unitats de control i perifèrics (lectors, etc.) tal i com es descriu en el present plec tècnic.

El Sistema també ha d‟incloure tasques de manteniment preventiu i correctiu, i de suport tèc-

nic durant tot el seu cicle de vida, que inclou el diagnòstic i el seguiment de les incidències a

nivell de maquinari, programari i comunicacions.

Integració amb la venda d’entrades a taquilles / oficines: disseny, desenvolupament, con-

figuració, proves, manteniment i suport a l‟operació d‟una solució per integrar-se amb les ven-

des d‟entrades a les taquilles i/o oficines del Parc segons el model de validació descrit en el

plec.

Integració amb SGS: disseny, desenvolupament, instal·lació, configuració, proves, manteni-

ment i suport a l‟operació d‟una solució que permeti integrar el Sistema de control d‟accés

amb el sistema de gestió de socis Zoo Club (SGS) per permetre l‟accés als socis del Zoo.

Integració amb el canal de venda per Internet: disseny, desenvolupament i implantació

d‟una interfície de comunicació per validar entrades adquirides a llocs web.

manteniment i suport a l’operació: tasques de manteniment preventiu i correctiu, i de suport

tècnic durant tot el cicle de vida de la present licitació, que inclou el diagnòstic i el seguiment

de les incidències a nivell de programari i maquinari.

Observar que s‟exclou explícitament de l‟àmbit de subministrament el maquinari (HW) on

s‟executa els mòduls servidor (serveis centrals, BBDD) del sistema de control d‟accés. B:SM

adquirirà per separat el maquinari i les llicències del programari base (SO, BBDD, etc.) ne-

cessaris, segons el disseny tècnic i l‟arquitectura de sistemes proposada per l‟Adjudicatari

i supervisada i aprovada per B:SM.

Observar que s‟exclou el subministrament dels dispositius PDA i dels seus complements,

però que en canvi sí que s‟ha de subministrar el SW de validació d‟entrades de les PDA.

L‟Adjudicatari també ha de respectar les fites, els plans d‟execució i les condicions de lliu-

rament descrits en el present plec tècnic: pla d‟implantació, pla de formació, pla de man-

teniment i suport a l‟operació, pla de contingència i pla d‟acceptació.


2. MODEL DE VENDA I ACCÉS AL ZOO

Abans de presentar els requeriments tècnics i funcionals del sistema de control d‟accés,

que és l‟objecte d‟aquest plec, es descriu breument quin serà el model de venda i valida-

ció d‟entrades del parc zoològic de Barcelona.

TIPUS D’ENTRADES

El model de ticketing del Zoo es basa en un conjunt de mòduls i sistemes que permeten

comercialitzar diferents tipus d‟entrada a través de canals presencials (taquilles, agències,

etc.) o telemàtics (web, app, invitacions, etc.). Els tipus d’entrada que es volen comercialitzar

per poder accedir al Parc són els següents:

entrada estàndard individual: entrada amb tarifa normal segons el rang establert per edats.

L‟entrada estàndard es pot adquirir a taquilles del Parc.

Les entrades adquirides a taquilles són impreses en paper tèrmic gruixut i han de poder ser

reconegudes pel sistema de control d‟accés, que els ha de permetre accedir un únic cop al

dia.

entrada de grup: entrada amb tarifa especial per a grups que es pot adquirir a les taquilles i

cancel·lar de manera agrupada al control d‟accés del Parc. Una única entrada per tot el grup.

entrada web Zoo: Les entrades adquirides per Internet, a través de la web del Zoo, han de

poder ser validades directament en el control d‟accés del recinte, sense bescanvi a taquilles.

No obstant les entrades web adquirides a altres llocs Internet (Atrápalo, Urbancheck, Grou-

pon, etc.) s‟han de poder bescanviar a les taquilles del recinte ja que es requereix un compro-

vant.

carnet Zoo Club: passi anual que ha de permetre accedir directament al Parc sense necessi-

tar de fer cap bescanvi a les taquilles. El soci ha de poder entrar i sortir tantes vegades com

vulgui.

El carnet es pot comprar pel canal de venda per Internet, a taquilles i a les oficines Zoo Club.

entrada combinada: entrada amb tarifa reduïda que inclou dos parcs: Parc d‟atraccions del

Tibidabo i Zoo de Barcelona, etc. L‟entrada combinada es pot adquirir a les taquilles del Parc.

col·lectius amb descompte: entrada amb tarifa reduïda per persones que acreditin una de-

terminada condició: persona amb discapacitat, targeta rosa, carnet jove, etc. Cal fer una llista

negra diària per garantir que només obtenen entrades pel Parc un cop al dia.

campanyes de promoció: percentatges de descomptes en l‟entrada basat en campanyes

promocionals: 2x1, descomptes, etc. (diaris, supermercats, etiquetes, etc.). Només es poden

bescanviar a les taquilles del Parc.

bons d’agències (vouchers): entrada adquirida en una agència de viatges o similar que s‟ha

de bescanviar a les taquilles, ja que és una forma de pagament complerta o parcial de

l‟entrada. Hi pot haver múltiples formats de vouchers: Paper Ticket, Print at Home o Mobile

ticket.

invitacions: entrada gratuïta que ha de permetre l‟accés al Parc sense fer bescanvi a taqui-

lles. Un cas particular són les invitacions per socis que són entrades gratuïtes lliurades via

Internet als socis (6 per any) que només es poden bescanviar a les taquilles del Parc.

reserves de grup o escolars: entrada de grup o per escoles que es poden adquirir pel canal

de venda per telèfon o per Internet i que s‟han de bescanviar a les taquilles del Parc.

MODEL de venda i accés al Zoo: Model tècnic 7

B:SM

És important destacar que les entrades adquirides a través de la web del Zoo, les invitaci-

ons i els carnets dels socis Zoo Club han de poder ser validats directament pel control

d‟accés del recinte, sense necessitat de fer cap bescanvi a les taquilles. No obstant, en

cas d‟incidència, aquesta s‟ha de poder resoldre a les taquilles del Parc.

MODEL TÈCNIC

Les aplicacions i sistemes d’informació que haurien de fer possible la venda i validació

d‟aquests tipus d‟entrades són els següents:

mòdul taquilles (FrontOffice): aplicació de venda a les taquilles del Parc a través de TPV.

mòdul Internet: canal de venda per Internet subministrat pel Centre de Càlcul de Girona (Eu-

romus) i que s‟haurà d‟integrar amb el nou sistema de control d‟accés del recinte.

zona web de socis: portal Internet per socis que permet administrar les dades dels socis i

alhora accedir a les entrades gratuïtes o amb descompte específiques per a socis. (CCalGir).

mòdul de reserves: canal de reserva de grup i escoles subministrat pel Centre de Càlcul de

Girona (Euromus) i que s‟haurà d‟integrar amb el nou sistema de venda d‟entrades.

sistema de socis Zoo Club: Sistema de Gestió de Socis del Zoo (SGS) desenvolupat inter-

nament per B:SM i que s‟haurà d‟integrar amb el nou sistema de venda d‟entrades i el de con-

trol d‟accés.

El SGS és una aplicació web que enregistra les dades en una Base de Dades SQL i que dis-

posa de procediments i funcions per interactuar amb altres sistemes.

sistema de control d’accés: sistema de control d‟accés al recinte, que s‟ha d‟integrar ple-

nament amb les entrades venudes a través dels diferents canals: taquilles, Internet, etc., així

com també amb els carnets de socis ZooClub.

sistema de comptabilitat: aplicació de comptabilitat de B:SM (Fènix) i que s‟haurà d‟integrar

amb el sistema de venda d‟entrades.

passarel·la de pagament: sistema ConexFlow proveït per IECISA que permet cobrar les

transaccions realitzades amb targeta de crèdit a través dels datàfons del TPV.

Observar que el sistema de control d‟accés, objecte de licitació, s‟haurà d‟integrar amb el

nou sistema de venda d‟entrades i amb els sistemes d‟informació o mòduls existents en

vendes per Internet (CCalGir) i en gestió de socis Zoo Club (SGS),.

El Sistema de control d‟accés i control d‟aforament del Parc ha de ser una eina útil perquè

el personal tècnic, administratiu i comercial del Zoo pugui explotar centralitzadament les

dades oficials d’accés i aforament a nivell estadístic, comercial i administratiu. En particu-

lar, el sistema ha de permetre notificar les estadístiques integrades dels accessos validats

pel sistema de control d‟accés al nou sistema de venda d‟entrades.

Cal destacar que les dades dels sistemes poden ser objecte d‟auditoria i que en general,

els informes oficials d‟accés i aforament han de poder donar cobertura a les obligacions

legals, administratives o comercials de B:SM amb tercers.

El nou sistema de control d‟accés ha de ser plenament compatible amb el nou sistema de

venda d‟entrades que s‟implantarà en les entrades del recinte.

MODEL de venda i accés al Zoo: Codificació de les entrades 8

B:SM

Des del punt de vista tècnic, serà obligatori l‟ús de formats d‟entrada electrònica que per-

metin identificar unívocament i validar automàticament les entrades adquirides a les taqui-

lles, a Internet, les promocions, les invitacions, els vouchers i els carnets de socis del

Parc.

Com a mínim, el sistema de control d‟accés haurà de poder

validar entrades en format Paper Ticket, Home Ticket, Mo-

bile Ticket i dispositius NFC, segons aquest mateix plec.

Es preveu que l‟ús de formats electrònics permeti ampliar

els modes de comercialització i adquisició d‟entrades, i que

alhora també permeti facilitar la venda i la posterior valida-

ció dels serveis complementaris a l‟entrada.

Seguidament, es desenvolupen les principals característiques del model de codificació de

les entrades vàlides per accedir al Parc.

CODIFICACIÓ DE LES ENTRADES

D‟acord amb la tipologia d‟entrades del Zoo la codificació apte per al sistema de control

d‟accés podria ser la següent:

entrada de taquilles (entrades diàries): codificació en format 2D (a priori QR) d‟un codi de N

dígits a definir durant la fase de disseny del projecte i amb les següents consideracions:

El codi ha de contenir informació suficient perquè el sistema de control d‟accés pugui de-

terminar la data de validesa de l‟entrada i altres camps amb informació de seguretat: canal

de venda, seqüencial, codi d‟article, dígit de control, etc., a fi i efecte de permetre l‟accés.

El codi també ha de permetre incloure el nombre de persones en entrades de grup.

El codi ha d‟estar parcialment ofuscat, especialment en els camps amb dates de validesa.

El sistema de control d‟accés ha de poder descodificar i si cal desxifrar el codi de manera

autònoma sense necessitat d‟accedir a una llista blanca d‟entrades venudes a taquilles.

D‟aquesta manera s‟evita haver d‟actualitzar en temps real una llista d‟entrades venudes a

les taquilles.

El sistema ha de disposar d‟una funció antipassback diària d‟aquest tipus d‟entrades, ja

que les entrades generals només poden accedir al Parc un cop al dia. No obstant, les en-

trades de socis sí que poden entrar i sortir del Parc tantes vegades com vulguin.

entrada web del Zoo (entrada temporada): codificació en format 2D (a priori QR) d‟un codi

de N dígits que es lliurarà a l‟Adjudicatari durant la fase de disseny del projecte. Si és possi-

ble, s‟intentarà uniformitzar amb el codi emprat a les taquilles del recinte.

carnet del Zoo (entrada soci): codificació en format 1D (a priori EAN8/13) d‟un codi identifi-

cador del soci Zoo Club. El sistema de control d‟accés haurà de consultar en temps real al

Sistema de Gestió de Socis de B:SM la validesa del soci per tal de deixar-lo accedir al recinte.

Invitació del Zoo (entrada temporada): codificació en format 2D (a priori QR) equivalent a

les entrades de taquilles amb una data límit per poder utilitzar l‟entrada.

Seguidament es presenten els requeriments tècnics i funcionals específics del Sistema de

control d‟accés del Zoo, que és l‟objecte de contractació del present plec tècnic.


3. REQUERIMENTS FUNCIONALS

Es presenta el diagrama de casos d‟ús i el diagrama de blocs del Sistema de venda

d‟entrades del Zoo de Barcelona, i seguidament se‟n desenvolupen els requeriments fun-

cionals utilitzant els seus principals casos d‟ús com a fil conductor.

DIAGRAMES DEL SISTEMA

En el marc del model de venda d‟entrades i validació dels accessos establert per al Parc,

el diagrama de casos d‟ús del sistema de control d‟accés és el següent:

Gràfic 2: diagrama de casos d‟ús: sistema de control d‟accés al Zoo

L‟abast funcional del sistema rau bàsicament en validar les diferents tipologies d‟entrades

del Zoo i controlar els torns d‟accés. A través d‟una aplicació de BackOffice, també s‟ha

de poder configurar el sistema i explotar la informació d‟accés i aforament.

En el diagrama superior s‟han omès els casos d‟ús habituals per a l‟administració del sis-

tema, però en els requeriments posteriors se‟n fa esment.

Els actors que interactuen amb el sistema de de control d‟accés són els següents:

visitant: persona que adquireix una entrada a través d‟algun dels canals de venda disponi-

bles (taquilles, Internet); o bé que disposa del carnet de soci Zoo Club.

personal d’accés o taquilles (operador): personal que pot actuar sobre els torns del control

d‟accés ocasionalment: obertura manual de portes, tancament de l‟accés, etc.

personal d’oficina: personal administratiu o comercial del Parc que requereix poder explotar

estadísticament les dades del sistema de control d‟accés.

Assenyalar que es tracta d‟un control d‟accés instal·lat en totes les portes d‟accés al recin-

te: Wellington, Prim, etc. En la secció de requeriments tècnics es descriu en detalla la con-

figuració del sistema de control d‟accés basat en torns motoritzats en les principals zones

d‟entrada i sortida del recinte.

En el cas específic d‟emergència es preveu una única línia de control que permeti “allibe-

rar els braços” de tots els torns del recinte.

REQUERIMENTS funcionals: Diagrames del Sistema 10

B:SM

En aquest context, el diagrama de blocs del sistema és el següent:

Gràfic 3: diagrama de blocs: sistema control d‟accés al Parc Zoològic

Bàsicament, el sistema es compon de dues aplicacions: una aplicació de control d‟accés

en els torns i una aplicació de BackOffice per a la configuració del sistema i l‟explotació de

la informació d‟accés i d‟aforament.

aplicació control d’accés: aplicació destinada a la validació en temps real de les entrades.

» El mòdul client s‟executa en una controladora dels torns, que permet llegir les entra-

des a través del lector de codis de barra. Addicionalment el mòdul client també es pot

executar en un terminal mòbil tipus PDA.

» La comunicació entre la controladora i el mòdul servidor es realitza a través de la

xarxa LAN disponible a tots els punts d‟accés del Parc.

» El mòdul servidor del sistema de venda (Base de Dades, serveis centrals (servidor

d‟aplicació), etc.) s‟executa en un servidor instal·lat en un CPD de B:SM.

aplicació de BackOffice: aplicació C/S o web destinada a la configuració del Sistema i a

l‟explotació de les dades de venda i validació d‟entrades: informes, estadístiques, etc.

En la seva oferta, el Licitador ha d‟incorporar una memòria detallada amb les prestacions

tècniques i funcionals de les aplicacions i components del sistema de control d‟accés.

Les prestacions tècniques de les aplicacions, interfícies de comunicació i components

hardware del Sistema es desenvolupen en detall en el capítol de requeriments tècnics.

Seguidament es presenten els requeriments funcionals del sistema agrupats pels seus

principals casos d‟ús.

REQUERIMENTS funcionals: Validar l‟accés al recinte 11

B:SM

VALIDAR L’ACCÉS AL RECINTE

L‟eix central del sistema és la validació dels accessos al Parc mitjançant una aplicació de

control d‟accés basada en torns bidireccionals, amb el següent abast funcional.

El sistema de control d‟accés ha de poder verificar automàticament la validesa de les entra-

des del Zoo emeses per qualsevol dels punts de venda autoritzats: taquilles, web, invitacions,

etc., així com també els accessos diaris amb carnets de soci Zoo Club.

L‟abast del sistema són totes les entrades i sortides públiques del Zoo: accés Wellington,

accés Prim.

» En el cas de l‟accés per l‟Escola serà necessari trobar una solució per afegir les en-

trades de les reserves al comptatge global d‟aforament del recinte sense que sigui ne-

cessari la instal·lació d‟un torn.

» L‟abast del sistema de control d‟accés inclou la validació de les entrades per accedir

al recinte però no per sortir-ne. És a dir, la sortida serà lliure a través dels torns.

» L‟abast del sistema de control d‟aforament inclou el comptatge de persones

d‟entrada i el comptatge de persones a la sortida del recinte a través dels torns bidirec-

cionals.

» L‟abast del sistema inclou tota la relació d‟entrades i carnets descrita en el model de

venda i accés al recinte, i s‟ha de poder ampliar segons les necessitats del Parc.

Observar que l‟abast funcional del control d‟accés inclou tant les entrades o tiquets eme-

sos per qualsevol dels punts de venda (taquilles, web, etc.), com els carnets de soci Zoo

Club.

L‟Adjudicatari haurà de liderar el grup de treball per definir el format i continguts dels codis

de barra de les entrades venudes a través de qualsevol dels canals de venda.

Validar entrades de taquilles

El procés de validació de l‟accés per entrades adquirides a taquilles es realitzarà d‟acord

amb el model de ticketing descrit en el capítol anterior.

La codificació exacte de les entrades emeses a taquilles es definirà, conjuntament amb

els adjudicataris del sistema de venda d‟entrades i del sistema de control d‟accés durant

la fase de disseny d‟ambdós projectes i que seran coincidents en el temps (fase

d‟especificació).

El procediment de validació electrònica de les entrades consisteix en la lectura i

la posterior validació d‟un codi de barres únic, que identifica unívocament

l‟entrada diària, i que es representa en un format de codi de barres 2D.

D‟acord amb el model descrit, la codificació de les entrades ha de permetre validar aques-

tes sense necessitat d‟accedir a una llista blanca d‟entrades emeses per les taquilles. En

aquest cas, el sistema de control d‟accés haurà de marcar l‟entrada com a consumida en

una llista negra centralitzada per evitar que el mateix codi pugui tornar a accedir al recinte.

Aquest mètode de codificació de les entrades es considera prou robust i en cap cas es

considera necessari haver d‟integrar en temps real el control d‟accés amb els sistemes de

venda per transferir els codis d‟entrades venudes. Observar doncs que es tracta d‟un mo-


B:SM

del de validació de control d‟accés purament off-line i per tant més simple i eficient.

Durant la fase de disseny, l‟Adjudicatari del Sistema especificarà en detall les dades, la

composició i les característiques de les entrades del Zoo dels visitants per poder ser vali-

dades pel control d‟accés. En aquest procés, l‟Adjudicatari haurà de liderar l‟equip de tre-

ball amb la resta de proveïdors i documentar la solució.

Entre d‟altres, recordar que el sistema de control d‟accés ha de poder validar entrades de

grup i deixar accedir al recinte totes les persones del grup amb una sola lectura d‟entrada.

Validar entrades dels socis

El procés de validació de l‟accés per a socis depèn del número de soci del carnet Zoo

Club o de la codificació del codi de barres de l‟entrada bescanviada als punts de venda.

El procediment de validació electrònica de les entrades consisteix en

la lectura i la posterior validació d‟un codi únic, que identifica unívo-

cament el soci, i que es representa en un format de codi de barres.

És important destacar que, tant el carnet de soci com l‟entrada adquirida pel propi soci a

les taquilles del Zoo conté el mateix codi, és a dir, el número de carnet de soci, però amb

simbologies de codis de barra diferents i amb possible informació addicional per donar

una major seguretat a les entrades de socis emeses a les taquilles.

D‟acord amb el model descrit en el capítol anterior, els requeriments previstos en la codifi-

cació de les entrades de per a socis són els següents:

entrada de socis: hi ha dos tipus de codis per entrades de socis: el carnet Zoo Club i

l‟entrada que poden aconseguir els socis si van a taquilles (paper tèrmic gruixut d‟entrada).

carnet Zoo Club: Conté un codi que es correspon amb el número de soci (codi de con-

tracte + identificador de membre) en format EAN-13 de 7 o 8 dígits en total.

entrada venuda a taquilles: Codi que conté el número de soci (codi de contracte + iden-

tificador de membre) i altres informacions (data, etc.) en format 2D (a priori QR).

El codi imprès en les entrades venudes a taquilles o caixer podria estar ofuscat i/o xifrat

per raons de seguretat. A valorar durant la fase de disseny del projecte.

Per defecte, en mode “on-line”, el sistema de control d‟accés ha de poder consultar en

temps real la validesa del número de soci al Sistema de Gestió de Socis (SGS).

En mode “off-line”, el sistema de control d‟accés ha de validar el format del codi de soci

(número de dígits) i deixar-lo passar si és correcte.

El Sistema de control d‟accés ha d‟executar íntegrament tots els procediments de lectura i

validació d‟entrades (mode “on-line”) en un temps inferior a 2,5 segons.

El sistema ha de disposar d‟una funció antipassback d‟aquest tipus d‟entrades amb una

durada d‟uns 10 minuts (paràmetre de configuració).

Durant la fase de disseny, s‟especificarà en detall les dades, composició i característiques

de les entrades al Zoo dels socis per poder ser validades pel control d‟accés. En aquest

procés, l‟Adjudicatari haurà de liderar l‟equip de treball amb la resta de proveïdors i docu-

mentar la solució.


B:SM

Validar entrades Internet

El procés de validació de l‟accés per entrades adquirides al canal web del lloc Internet del

Zoo es realitzarà d‟acord amb el model de ticketing descrit en el capítol anterior.



l‟entrada, i que es representa en un format de codi de barres 2D.

Actualment la web del Zoo emet una entrada amb una codi aleatori únic que posterior-

ment es notifica al sistema de control d‟accés per crear una llista blanca d‟entrades.

En el futur, es preveu que la web del Zoo emeti entrades amb un codi únic que contingui

informació intel·ligible, com ara la data límit de validesa de l‟entrada, de manera equivalent

a les entrades emeses per les taquilles i que permeti garantir que el sistema de control

d‟accés les pot validar sense necessitat de consultar una llista blanca. En aquest cas, el

sistema de control d‟accés haurà de marcar l‟entrada com a consumida en una llista negra

per evitar que el mateix codi pugui tornar a accedir al recinte.

En aquest àmbit el requeriment per al sistema de control d‟accés és que aquest ha de po-

der validar tant entrades enregistrades en una llista blanca, com entrades amb codis in-

tel·ligibles amb un format equivalent o similar al de les entrades de les taquilles.

Durant la fase de disseny, l‟Adjudicatari del Sistema especificarà en detall les dades, la

composició i les característiques de les entrades web del Zoo per poder ser validades pel

control d‟accés. En aquest procés, l‟Adjudicatari haurà de liderar l‟equip de treball amb la

resta de proveïdors i documentar la solució.

D‟altra banda, recordar que les entrades web adquirides altres llocs Internet, com per

exemple Urban Check, Atrápalo o Let‟s Bonus s‟han de poder bescanviar a les taquilles

per una entrada estàndard del Zoo, ja que es requereix un comprovant de pagament.

No obstant, el Licitador pot proposar una solució de millora per poder validar les entrades

de llocs web de tercers directament en el control d‟accés del recinte.

Validar invitacions

El procés de validació de l‟accés per invitacions emeses a través de BackOffice del siste-

ma de venda d‟entrades o adquirides en la zona privada del lloc web del Zoo, es realitzarà

d‟acord amb el model de ticketing descrit en el capítol anterior.



l‟entrada, i que es representa en un format de codi de barres 2D.

En la mesura del possible s‟intentarà unificar el contingut de les entrades d‟invitació amb

les entrades emeses a les taquilles a fi i efecte d‟evitar la necessitat de traspassar llistes

blanques de codis d‟entrada entre sistemes d‟informació.

Durant la fase de disseny, s‟especificarà en detall les dades, la composició i les caracte-

rístiques de les invitacions del Zoo per poder ser validades pel control d‟accés. En aquest

procés, l‟Adjudicatari haurà de liderar l‟equip de treball amb la resta de proveïdors.

http://www.urbancheck.com/ofertas-y-descuentos/zoo-de-barcelona/

http://www.atrapalo.com/

http://www.letsbonus.com/


B:SM

Validar accés de treballadors

A més a més de les entrades, el sistema de control d‟accés ha de poder validar l‟accés

dels treballadors del Zoo de Barcelona.

Aquest col·lectiu es podria identificar amb una targeta NFC i/o amb un codi de barres 1D o

2D que inclourà el seu número de treballador.

El sistema de control d‟accés del Zoo ha de validar contra una llista blanca el número de

treballador per comprovar que efectivament té accés al recinte.

El licitador pot proposar tècniques o mètodes alternatius per validar l‟accés del col·lectiu

de treballadors del Parc: connectivitat a BBDD, vistes de dades, etc.

Durant la fase de disseny, s‟especificarà en detall les dades, la composició i les caracte-

rístiques de les targetes dels treballadors del Zoo per poder ser validades pel control

d‟accés. En aquest procés, l‟Adjudicatari haurà de liderar l‟equip de treball amb la resta de

proveïdors.

D‟altra banda, el sistema ha de disposar d‟algunes targetes màster pels operaris del con-

trol d‟accés.

Resoldre incidències

Els requeriments del sistema de control d‟accés en relació a les incidències que ha de

poder detectar en la porta d‟accés al Zoo són els següents:

En els punts d‟accés al Zoo, el Sistema de control d‟accés ha de poder detectar les se-

güents incidències amb les entrades:

» accés duplicat: lectura repetida d‟un codi d‟entrada que ja ha accedit prèviament al

recinte. El sistema ha de mostrar informació detallada de l‟accés anterior i la causa de

la denegació del pas.

» codi incorrecte: la lectura d‟un codi d‟entrada que no es correspon amb cap dels for-

mats d‟entrada vàlids. El sistema ha d‟impedir-ne l‟accés i ha de mostrar informació de-

tallada de la causa de la denegació del pas

» errors de lectura: l‟operador pot haver d‟assistir al visitant en l‟orientació de l‟entrada

o carnet de soci envers el lector de codis de barres incrustat en el moble.

» renovació de soci: lectura d‟un codi de soci que el SGS detecta com a donat de baixa

o pendent de validació en el sistema.

» soci inexistent: lectura d‟un codi de soci que el SGS detecta com a inexistent.

El sistema ha de disposar d‟una funció antipassback per tots els tipus d‟entrades amb una

durada d‟uns 10 minuts (paràmetre de configuració).

El passadís de control d‟accés ha de tenir una interfície gràfica, visual i sonora amb l‟usuari,

que li permeti reconèixer eficientment el resultat de la validació. En cas de llegir un codi dupli-

cat o incorrecte, el sistema n‟ha de poder notificar clarament la causa en una pantalla.

En cas d‟incidència amb les entrades, es preveu que els visitants siguin atesos per

l‟operador del sistema de control d‟accés.


B:SM

Observar que el sistema de control d‟accés ha d‟enregistrar una llista negra centralitzada

de codis validats i “consumits” per evitar que una mateixa entrada accedeixi dues vegades

al recinte.

Aquesta llista negra s‟haurà de mantenir a fi i efecte d‟evitar el seu creixement excessiu,

de manera que cada nit s‟hauria d‟eliminar de la llista negra les entrades caducades.

En la fase de disseny, B:SM i l‟Adjudicatari especificaran conjuntament els procediments

disponibles per poder resoldre les incidències en la zona d‟accés al Zoo.

En aquest àmbit, també cal afegir que el funcionament del sistema s‟han de dissenyar i

dimensionar d‟acord amb el corresponent pla de contingència o de continuïtat del negoci.

A nivell d‟aplicació de control d‟accés, cal garantir la continuïtat dels accessos en cas de

caiguda de serveis centrals (mode off-line) o dels sistemes amb els que interaccionen amb el

control d‟accés com per exemple el SGS (validació de socis).

» En la seva oferta, el Licitador haurà de presentar el funcionament del sistema de control

d‟accés en cas de manca de comunicació amb els serveis centrals del propi sistema, així

com també el procediment per transferir les dades locals als servidors un cop restablerta

la comunicació.

Observar que és especialment necessari dissenyar el sistema de control d‟accés amb un

mode de funcionament off-line i un procediment per recuperar les dades d‟accés un cop

es restableixi la comunicació amb els serveis centrals.

REQUERIMENTS funcionals: Controlar aforament real 16

B:SM

CONTROLAR AFORAMENT REAL

Un dels principals valors afegits del Sistema és l‟ús que se‟n deriva com a eina de control

d‟aforament, amb capacitat per comptar visitants i avaluar-ne el seus patrons d‟accés; fet

que a priori, hauria de permetre optimitzar els serveis i els recursos disponibles.

El sistema de control d‟accés ha de permetre l’ús bidireccional de tots els torns instal·lats

en les entrades i sortides del recinte.

En aquest àmbit, el sistema ha de disposar d‟un registre centralitzat de visitants que per-

meti enregistrar en temps real el nombre de persones que es troben dins del recinte, en

base a les entrades i les sortides comptabilitzades.

Durant l‟obertura del Parc, en base a les entrades validades i sortides realitzades en cada

porta d‟accés, el Sistema ha de poder comptabilitzar en temps real l’aforament real en el recin-

te.

» L‟Aplicació de monitoratge del control d‟aforament (BackOffice) ha de poder repre-

sentar en una interfície gràfica les portes d‟accés al recinte amb els accessos, així com

també els corresponents llindars i qualsevol incidències que es pugui produir.

» L‟Aplicació ha de representar l‟estat d‟aforament en un mapa esquemàtic del recinte.

» L‟Aplicació de BackOffice ha de permetre representar el nombre de transaccions

d‟entrada i sortida per cada carril d‟accés al recinte.

» L‟Aplicació ha d‟assistir al cap d‟operacions del Parc alhora de decidir l‟ús òptim i la

millor ubicació dels recursos humans i materials emprats durant l‟obertura del recinte:

personal de taquilles, porters, seguretat, etc.

En el cas particular de l‟accés per l’Escola del Zoo, el Licitador ha d‟oferir una solució que

permeti incorporar la informació d‟accés comptabilitzada amb el sistema de venda d‟entrades

al seu sistema de control d‟aforament.

» En aquest sentit, es pot valorar la integració entre sistemes a través de vistes de la

base de dades centralitzada d‟ambdós sistemes. No obstant, s‟accepten altres propos-

tes incorporades sempre en el preu de subministrament..

El Sistema ha de permetre fer el seguiment en temps real de l‟aforament instantani (flux en-

trada – flux sortida) del recinte, amb l‟objectiu de detectar situacions i llindars relacionats amb

l‟aforament màxim del mateix.

» El Sistema ha de poder detectar i notificar alarmes d‟aforament si es superen els llin-

dars d‟aforament previstos: aforament elevat, intensitat d‟entrada o sortida, màxim, etc.

» El monitoratge s‟ha de poder fer des del punt de control d’aforament del recinte, pre-

visiblement situat a les oficines, mitjançant un equip amb una interfície gràfica que

permeti veure les alarmes i consultar intuïtivament l‟aforament real del recinte.

» Des del punt de control d‟operacions s‟informarà via ràdio (walkie-talkie) al cap de

Parc del recinte sobre qualsevol incidència amb l‟aforament.

Un cop finalitzada l‟operació, es preveu que l‟aplicació de BackOffice d‟informes del sis-

tema de control d‟accés sigui una eina útil perquè el personal tècnic i d‟operacions de

B:SM pugui explotar les dades d‟accés i d‟aforament real de cada espectacle.

El licitador ha de poder demostrar la fiabilitat tècnica de les dades d‟accés i d‟aforament.

REQUERIMENTS funcionals: Controlar aforament real 17

B:SM

D‟altra banda, el Sistema també ha de contemplar aspectes normatius sobre la regulació

del control metrològic per el comptatge i control d‟afluència de persones en locals de con-

currència pública, a més a més dels ja descrits i entre d‟altres, els següents:

Es tracta de disposar d'un sistema que proporcioni el control, en temps real , de l'afluència

de les persones en les instal·lacions del Zoo de Barcelona. El sistema emprat ha de poder ser

utilitzat amb la garantia del seu funcionament correcte.

El sistema de comptatge de persones (control d'aforament ) es basa en la validació

d‟entrades per accedir al recinte i en la detecció de passos de sortida del recinte.

L'accés a les dades d'aforament ha d'estar protegit amb claus o contrasenyes que garantei-

xin la seguretat i inviolabilitat de les dades.

Tots els accessos dels usuaris permesos, s'han d'enregistrar amb la data i hora i l‟acció i les

dades modificades.

El sistema d'aforament ha de disposar d'un sistema de visualització en temps real, tan dels

comptatges d'aforament, com de les incidències .

Les dades d'aforament han d‟incloure informació de l‟aforament instantani, l‟aforament mà-

xim, els llindars mínim i màxim d'alarma .

El sistema de gestió d'aforament un cop superat el llindar mínim, per sota de l‟aforament

màxim, ha de enviar un missatge al destinatari configurat amb la indicació dels paràmetres

d'aforament indicats. El sistema d'enviament del missatge (e-mail, SMS, etc.) es proposarà en

l‟oferta del Licitador i serà valorat i aprovat per BSM.

El Licitador haurà de demostrar la fiabilitat tècnica de la informació gestionada.

Al inici de cada jornada, es realitzarà la posta a cero dels comptadors d'aforament, fet que

quedarà enregistrat en el registre d‟activitats del Sistema de control d‟accés i aforament.

El licitador pot oferir millores en les funcionalitats relacionades amb el control d‟aforament

per tal de detectar amb major facilitat i fiabilitat les situacions properes al límit d‟aforament

del recinte.

REQUERIMENTS funcionals: Controlar els torns 18

B:SM

CONTROLAR ELS TORNS

El sistema de control d‟accés ha de permetre actuar directament sobre els torns motorit-

zats dels passadissos instal·lats en totes les entrades i sortides del recinte.

El sistema de control d‟accés ha de disposar d‟un mecanisme per poder obrir els torns re-

motament en diverses situacions: accés obert o tancat, emergència, pas de treballadors, etc. .

» Per defecte, les portes es configuraran en mode validació en el sentit d‟entrada al re-

cinte i en mode d‟accés lliure en el sentit de sortida del recinte.

» És necessari instal·lar un quadre de comandaments HW o SW en cada taquilla per

poder operar sobre l‟estat dels torns: obert, tancat, mode validació, etc.

El quadre de comandament pot ser una solució HW o SW amb una consola de

control a les taquilles.

» Addicionalment el Parc ha de tenir un botó d’emergència per deixar caure els braços

dels torns en aquesta situació.

Opcionalment, el botó d‟emergència pot estar integrat en el quadre de comanda-

ment de cada taquilla.

» El sistema també ha de disposar de targetes màster pel pas d‟operaris d‟accés.

El sistema ha de disposar d‟un estat d‟emergència que permeti deixar tots els passos

oberts.

El sistema de control d‟accés ha de permetre l’ús bidireccional de tots els torns instal·lats

en les entrades i sortides del recinte:

Tots els torns del recinte han de poder operar en mode entrada (validació de tiquets) i també

en mode sortida (sortida lliure).

» El sistema de control d‟accés ha d‟oferir una consola de control HW o SW en cadascu-

na de les taquilles que permeti determinar el mode de funcionament dels torns: oberts,

tancats, sentit de circulació, validació, etc.

» El sistema ha de permetre programar els horaris d‟obertura i tancament dels sentits de

circulació dels torns. No obstant, també ha de permetre la definició instantània del mode

de funcionament de cadascun dels torns a través d‟una consola de control HW o SW en

cadascuna de les taquilles.

Tots els torns també han de poder operar en el mode emergència alliberant l‟espai disponi-

ble entre torns de tres braços i abaixant les pilones de separació entre torns de tres braços.

D‟altra banda, el sistema de control d‟accés també ha de gestionar correctament el pas de

les persones a través del passadís amb torns giratoris:

El sistema de control d‟accés s‟ha de basar en torns que girin els braços en el sentit del pas

del visitant (lectura i validació d‟entrada en l‟accés al recinte i detecció de presència en la sor-

tida del recinte).

D‟acord amb els requeriments tècnics descrits posteriorment, es preveu la instal·lació de

dos tipus de torns:

» Torniquets de tres braços.

REQUERIMENTS funcionals: Explotar dades d‟accés i aforament 19

B:SM

» Torns d‟un sol braç per persones amb cadira de rodes i cotxets.

El passadís del sistema de control d‟accés ha de disposar de sensors òptics per detectar la

presència de persones o objectes en el pas.

» Els torns no poden suposar en cap cas un perill per a la integritat física de les perso-

nes.

» El sistema basat en torns de tres braços ha de poder deixar els braços caiguts en

cas de caiguda elèctrica i també en cas d‟emergència.

» El passadís de control d‟accés ha de tenir una interfície gràfica, visual i sonora amb

l‟usuari, que li permeti reconèixer eficientment el resultat de la validació d‟entrades i ha

d‟indicar clarament si l‟usuari pot o no passar pel pas.

» Es valorarà positivament millores en la interfície d‟usuari dels torns.

Com a mínim, el sistema ha de permetre el pas d‟entre 15 i 20 persones per minut utilitzant

la validació basada en la lectura de codis de barra unidimensionals o bidimensionals.

En el capítol de requeriments tècnics es presenten les dimensions i les prestacions tècni-

ques del sistema de torns de control d‟accés.

EXPLOTAR DADES D’ACCÉS I AFORAMENT

La informació relativa a l‟accés d‟usuaris al Zoo és d‟interès per diverses àrees o unitats

del Parc Zoològic de Barcelona i també de Barcelona de Serveis Municipals (B:SM).

L‟aplicació de BackOffice del Sistema ha de ser una eina útil perquè el personal tècnic,

administratiu i comercial del Parc i de B:SM pugui explotar les dades oficials d‟accés.

Tots els procediments del sistema de control d‟accés han de ser conformes amb les lleis en

vigor i poden ser auditats.

El sistema ha de garantir la fiabilitat de les dades enregistrades ja que se‟n pot derivar res-

ponsabilitats legals, administratives o comercials amb B:SM.

Es requereix el següent número de llicències per a l‟aplicació de BackOffice:

» Mínim de 6 llicències de l‟aplicació de BackOffice d‟administració del sistema i gene-

ració d‟informes de control d‟accés i control d‟aforament.

» Mínim 1 llicència de l‟aplicació de BackOffice de monitoratge en temps real de

l‟aforament del sistema.

» Qualsevol altre aplicació de BackOffice del sistema proposada pel Licitador haurà de

tenir un mínim d‟una llicència.

Durant l‟horari d‟obertura del Parc, el Sistema ha d‟enregistrar periòdicament i centralitza-

dament (5 minuts) els valors instantanis d‟entrades, sortides i aforament real en les sales o

zones sotmeses al propi control d‟accés, així com les incidències o errors que es puguin

produir. El registre d‟activitats estarà associat a cada jornada.

Diàriament, s‟ha de poder enregistrar dades oficials d‟accés al Parc per les diferents por-

tes d‟accés.

El Sistema de control d‟accés ha de poder enregistrar les dades oficials d’accés al Parc per

cadascuna de les entrades.

» L‟aplicació de BackOffice d‟informes ha de permetre accedir a les dades relaciona-

REQUERIMENTS funcionals: Explotar dades d‟accés i aforament 20

B:SM

des amb l‟accés real al recinte i ha de permetre generar un informe oficial d’accés.

» L‟aplicació de BackOffice del Sistema ha de disposar de múltiples llistats i consultes

per poder explotar la informació i que com a mínim incorpori les següents:

Diari d‟accessos; Informe d‟accés per porta d‟accés i per zona.

Resum per d‟accessos per porta/zona, tarifa, tipus d‟entrada, etc.

» L‟aplicació de BackOffice del Sistema ha de disposar de llistats estadístics que per-

metin analitzar la situació i prendre decisions als gestors del recinte, com a mínim:

Estadística d‟accessos per porta/zona, període, franja horària, etc.

Accessos (resum diari, resum setmanal, evolució horària, evolució diària, evolució

per dia de la setmana, evolució mensual, etc.).

El Sistema ha de mantenir les dades oficials d‟accés del Zoo durant un mínim de 2 anys i

durant aquest període s‟ha de permetre l‟exportació i l‟accés a les dades històriques.

A posteriori, es preveu que el mòdul d‟aforament del sistema també sigui una eina útil

perquè el personal tècnic, administratiu i comercial de B:SM pugui explotar les dades ofi-

cials d‟accés al Zoo:

L‟aplicació de BackOffice del Sistema ha de permetre explotar les dades oficials d’accés a

les entrades i sortides del Parc, amb finalitats tècniques, comercials o administratives:

» patrons d’accés: l‟aplicació de BackOffice ha de permetre analitzar i avaluar el ritme i

els patrons d‟accés dels usuaris, amb diversos criteris de selecció: zona, E/S, horari,...

» informes oficials: l‟aplicació de BackOffice del sistema ha de permetre generar suma-

ris d‟accés de viatgers a partir de diversos criteris de selecció: zona, període, horari,

etc.

» informes estadístics: l‟aplicació de BackOffice ha de permetre consultar i generar in-

formes bàsics en format taula i també format gràfic, sobre l‟evolució de l‟accés al Zoo a

partir de diversos criteris de selecció: zona, període, horari, etc.

En general, l‟aplicació de BackOffice del sistema de control d‟accés ha de permetre expor-

tar gràfics i informes a algun dels formats més habituals en aplicacions ofimàtiques.

És especialment necessari destacar que el sistema de control d‟accés ha de permetre que

el sistema de venda d‟entrades pugui consultar les dades diàries d‟accés al recinte amb

entrades que no han passat per taquilla: entrades web Zoo, invitacions Zoo, socis, etc. És

doncs imprescindible una integració amb el sistema de venda d‟entrades per tal que

aquest pugui accedir a aquesta informació.

REQUERIMENTS funcionals: Administrar i configurar el sistema 21

B:SM

ADMINISTRAR I CONFIGURAR EL SISTEMA

Totes les funcions d‟administració i configuració del Sistema de control d‟accés es realit-

zaran a través de l‟aplicació de BackOffice.

Els requeriments funcionals relacionats amb l‟administració del Sistema de control d‟accés

són els següents:

L‟Adjudicatari ha d‟instal·lar i configurar plenament totes les aplicacions del sistema: aplica-

ció client (lector, controladora del torn), servidor d‟aplicacions, aplicació de BackOffice, etc.

L‟aplicació de BackOffice del Sistema ha de permetre donar d‟alta totes les portes i zones

d‟accés del recinte: identificador, nom, descripció, etc.

» L‟aplicació de BackOffice ha de permetre administrar les llistes blanques / negres

d‟entrades. Aquestes tasques sempre aniran a càrrec del personal tècnic de suport a

l‟operació de l‟Adjudicatari.

L‟aplicació de BackOffice ha de permetre administrar els usuaris de les aplicacions del Sis-

tema, com a mínim es preveuen tres tipus de perfils d‟usuari.

» supervisor: funcions de supervisió en funcions de control d‟accés.

» explotació: funcions d‟explotació de les dades d‟accés del sistema a fi i efecte

d‟obtenir informació estadística i informes oficials.

» administrador: plenes funcions d‟administració i configuració del sistema. Equival a

personal tècnic del propi Adjudicatari i de Sistemes de B:SM.

» Tots els usuaris s‟han de poder identificar amb nom d‟usuari i contrasenya. El Siste-

ma ha de permetre administrar les contrasenyes dels usuaris.

» L‟Adjudicatari és responsable d‟instal·lar i configurar plenament les aplicacions de

BackOffice del sistema, incloent l‟alta d‟usuaris de l‟aplicació.

En el registre d‟activitats del Sistema s‟hi enregistraran tots els accessos i intents d‟accés

dels usuaris, així com també qualsevol incidència que es pugui produir: errors, etc.

» El registre d‟activitats del Sistema s‟ha de mantenir un mínim de 2 anys.

» El registre d‟activitats s‟ha de poder exportar amb facilitat i és preferible implementar-

ho directament sobre taules d‟un gestor de BBDD.


4. REQUERIMENTS TÈCNICS

Els requeriments tècnics del sistema de control d‟accés al Zoo de Barcelona es desenvo-

lupen entorn els seus components HW / SW i les seves interfícies de comunicació.

Des del punt de vista tècnic el sistema es descompon en dues aplicacions: control d’accés

i BackOffice, d‟acord amb el següent diagrama:

Gràfic 4: diagrama de blocs: sistema de control d‟accés al Zoo de Barcelona

L‟aplicació de client del control d‟accés s‟executarà sobre la unitat de control dels torns

que serà íntegrament subministrada per l‟Adjudicatari, que és qui n‟haurà de fer la ins-

tal·lació, configuració, proves i posta en marxa. L‟aplicació també s‟haurà de poder execu-

tar en una PDA o dispositiu mòbil.

L‟aplicació servidor del control d‟accés s‟executarà en el servidor que conté els serveis

centrals del sistema i que, a priori, s‟allotjarà al Centre de Processament de Dades (CPD)

de Barcelona de Serveis Municipals (B:SM). En aquest mateix CPD s‟hi allotjarà el servei

de Base de Dades centralitzada de l‟aplicació de control d‟accés.

D‟acord amb això, els servidors dels serveis centrals del Sistema residiran en el CPD de

B:SM i el maquinari serà subministrats per B:SM, però l‟Adjudicatari haurà d‟instal·lar, con-

figurar, provar i posar en funcionament totes les aplicacions relacionades amb els serveis

centrals del sistema.

Les llicències del programari base (S.O., Gestor BBDD, Antivirus, Control remot, etc.) també

aniran a càrrec de B:SM.

Durant la fase de disseny l‟Adjudicatari i BSM consensuaran els requeriments tècnics dels

servidors: S.O., gestor BBDD, etc.

L‟aplicació de BackOffice s‟executarà sobre l‟ordinador de treball dels destinataris i

l‟Adjudicatari haurà d‟instal·lar, configurar, provar i posar en funcionament l‟aplicació. No

obstant, l‟aplicació de BackOffice ha de ser, preferiblement, en format web.

Seguidament es presenten els principals criteris de disseny del Sistema i posteriorment es

desenvolupen els requeriments tècnics agrupats per aplicació.

REQUERIMENTS tècnics: Criteris de disseny 23

B:SM

CRITERIS DE DISSENY

En general, els components hardware, els mòduls software i les interfícies de comunicació

del sistema de control d‟accés han de complir amb els següents criteris de disseny:

seguretat pública: el disseny del sistema ha de garantir la seguretat pública dels seus usua-

ris en cas de qualsevol situació d‟emergència i en estricte compliment del marc legislatiu vi-

gent.

estàndards: els components HW, els mòduls SW i les seves interfícies de comunicació s‟han

de basar en estàndards per garantir-ne la seva compatibilitat i capacitat d‟integració.

Les interfícies de comunicació (protocol i model de dades) del sistema de control d‟accés amb

tercers s‟han de basar en estàndards en totes les seves capes.

normatives: la instal·lació i tots els components han de complir amb les normatives exigibles

en el seu àmbit d‟operació: cablejat, baixa tensió, accessibilitat, seguretat, etc.

disponibilitat: el disseny dels serveis centrals i mòduls del sistema de control d‟accés ha de

permetre protegir i/o oferir alternatives tècniques o operatives enfront possibles incidències

tècniques per tal de garantir el nivell de servei requerit pel sistema.

fiabilitat: el disseny dels serveis centrals i de totes els mòduls del sistema també s‟ha de fo-

namentar en procediments i recursos que permetin disposar de dades plenament fiables.

traçabilitat: el disseny del sistema ha de facilitar la identificació i el diagnòstic d‟incidències

en tots els seus components (hardware, software) i en les seves interfícies de comunicació.

modular: el disseny del sistema ha de ser modular per facilitar la detecció d‟errors i la seva

capacitat d‟ampliació i d‟actualització en components hardware o software.

tractament de dades: el disseny del sistema ha de garantir la plena seguretat en l‟ús i el trac-

tament de les dades personals, financeres o comercials, d‟acord amb el marc legislatiu vigent.

parametrització: el sistema ha de permetre configurar àmpliament els seus paràmetres, evi-

tant l‟assignació de valors o funcions rígides (hard coded).

usabilitat i accessibilitat: la interfície del sistema amb l‟usuari (gràfic, auditiu, etc.) ha de ser

fàcil d‟utilitzar permetent una interacció accessible, efectiva i eficient en el seu context d‟ús.

B:SM es reserva l‟opció de supervisar i d‟intercedir pel compliment d‟aquests criteris de

disseny, especialment en aquells àmbits amb responsabilitats envers a tercers (auditors,

cossos de seguretat, inspectors, etc.) o bé on hi intervenen diversos proveïdors.

El sistema de control d‟accés del Zoo és un sistema crític i per tant, cal redundar esforços

per garantir un servei segur i fiable, tant en les condicions d‟operació habituals, com en

cas d‟incidència tècnica o d‟emergència.

REQUERIMENTS tècnics: Mòdul de control d‟accés 24

B:SM

MÒDUL DE CONTROL D’ACCÉS

Seguidament es presenten els requeriments tècnics del programari i del maquinari del

mòdul de control d‟accés del sistema.

L‟abast del mòdul de control d‟accés rau bàsicament en la validació de les entrades i iden-

tificadors dels visitants del Parc, així com també en el comptatge de l‟aforament real del

recinte en temps real.

En aquest context, els components de l‟aplicació de control d‟accés són els següents:

Gràfic 5: components del sistema de control d‟accés

Un primer resum de components segons la seva ubicació física seria el següent:

torns d’accés: passadissos de torniquets motoritzats amb lectors de codis de barra per a la

validació d‟entrades i components de xarxa per comunicar-se amb els serveis centrals del

Sistema.

» Tots els components de xarxa local (LAN) disponibles en les zones properes a les por-

tes d‟accés seran subministrats, instal·lats, configurats i mantinguts per B:SM.

» L‟Adjudicatari del present Sistema pot comptar amb la instal·lació d‟una xarxa de

transport fiable (fibra) fins als servidors ubicats en el CPD de B:SM.

pilones d’emergència: pilones antipànic de seguretat que cal ubicar entre torns de tres bra-

ços enfrontats per garantir una amplada mínima de 0,80m de pas lliure en cas d‟emergència.

» Les pilones d‟emergència han de caure automàticament en cas d‟emergència per

permetre l‟evacuació del recinte.

PDA d’accés: Dispositius mòbils que permetin llegir i validar les entrades de manera equiva-

lent als torns d‟accés. La comunicació local de les PDA s‟ha de realitzar via WiFi.

Centre de Processament de Dades: components de la xarxa de transport i components HW

i SW del mòdul servidor de l‟aplicació de control d‟accés. Inclou sortida Internet. Els equipa-

ments HW i el SW de base (SO, llicència BBDD, etc.) seran subministrats per BSM d‟acord

amb les especificacions indicades per l‟Adjudicatari en la seva oferta.

» Tots els components HW disponibles en el CPD del recinte seran subministrats per

B:SM i l‟Adjudicatari només proveirà i configurarà el SW del sistema de control d‟accés.


B:SM

Torn d’accés

En el sistema de control d‟accés del Zoo de Barcelona es preveuen dos tipus de torns:

Torn convencional: torn motoritzat de tres braços apte per exteriors .

» Torn de tres braços motoritzats amb sentit de gir bidireccional i protecció antipànic.

» Torn amb sensor òptic de pas.

» Torn de tres braços que permeti una amplada entre peus consecutius de 950mm

(Wellington) i de 850mm (Prim).

» Motorització de 24V de corrent contínua. Control de parell de força i protecció de so-

brecàrrega.

» El model ha de poder “deixar caure els braços” en cas de caiguda elèctrica i en cas

d‟emergència.

» El model també ha de permetre abaixar els braços manualment (mitjançant una clau

o botó) i per tant deixar el carril lliure per poder fer validació amb la PDA.

» La instal·lació dels torns i la connectivitat d‟aquests va a càrrec de l‟Adjudicatari.

» Les platines dels peus dels torns han d‟estar enrassades a nivell de terra.

» La distància màxima per poder manipular la part posterior dels torns serà de 20cm.

» Important: Tots els torns de tres braços s‟han d‟instal·lar enfrontats i separats per una

pilona d‟emergència que garanteixi una amplada lliure de pas superior als 0,80m en

cas d‟evacuació del recinte.

Torn adaptat: torn motoritzat d‟un sol braç adaptat per persones amb cadira de rodes i cot-

xets, apte per exteriors.

» Torn d‟un sol braç motoritzat amb sentit de gir bidireccional i protecció antipànic.

» Torn amb sensor òptic de pas.

» Torn d‟un sol braç que permeti una amplada lliure de pas superior als 0,80m.

» Motorització de 24V de corrent contínua. Control de parell de força i protecció de so-

brecàrrega.

» El model ha de poder “deixar el braç sense força” en cas de caiguda elèctrica i en

cas d‟emergència.

» El model també ha de permetre alliberar el braç manualment (mitjançant una clau o

botó) i per tant deixar el carril lliure per poder fer validació amb la PDA.

» La distància màxima per poder manipular la part posterior dels torns serà de 20cm.

» La instal·lació dels torns i la connectivitat d‟aquests va a càrrec de l‟Adjudicatari.

» Les platines dels peus dels torns han d‟estar enrassades a nivell de terra.

» Els torns adaptats es poden instal·lar sense pilona d‟emergència ja que han de tenir

una amplada lliure de pas de 0,80m en cas d‟evacuació i per tant no és necessari en-

frontar-los.

És imprescindible que la instal·lació de tots torns del sistema de control d‟accés compleixi

amb tota la normativa vigent en el seu àmbit d‟aplicació.


B:SM

Els torns s‟ubicaran en les zones indicades en la secció de dimensionament dels acces-

sos.

Tots els torns s‟han d‟instal·lar garantint que es podrà

accedir correctament al propi torn per realitzar tas-

ques de manteniment. En aquest sentit, és recoma-

nable instal·lar els torns en “zig-zag” en comptes de

fer-ho linealment.

Altres prestacions tècniques del mòdul de control d‟accés són les següents:

El sistema requereix d‟una consola de control centralitzat per poder determinar el mode de

funcionament dels torns (oberts, tancats, sentit de circulació, validació) instal·lat, a priori, en

cadascuna de les dues taquilles del recinte. Durant la fase de disseny, es definirà la ubicació

definitiva de les consoles de control d‟estat dels torns.

Els sistema ha de tenir un botó físic d’emergència per obertura en cas d‟emergència ubicat,

a priori, en les dues taquilles del recinte: Prim i Wellington. Durant la fase de disseny, es defi-

nirà la ubicació definitiva dels botons d‟emergència dels torns.

En particular, també es valorarà la possibilitat d‟instal·lar un botó físic d‟emergència a les

oficines centrals del recinte per poder centralitzar la notificació de l‟emergència.

Els mobles, els components (lector, visor, etc.) i el cablatge de les portes hauran d‟estar

protegides enfront possibles actes de vandalisme, comptant amb l‟encapsulació i protecció

adients per garantir el seu òptim funcionament i minimitzar-ne les incidències.

En cadascuna de les taquilles, un dels torns, el més proper a la taquilla, s‟ha de poder obrir

amb la consola de control o amb el comandament a distància donant una ordre de pas.

La instal·lació integral dels torns anirà a càrrec de l‟Adjudicatari, tal i com es descriu en el

capítol de plans d‟execució del present plec.

Pilona d’emergència

D‟acord amb el que s‟ha descrit anteriorment, els torns de tres braços s‟han d‟instal·lar

enfrontats i separats per una pilona d‟emergència, a fi i efecte de garantir que en cas

d‟evacuació l‟espai lliure disponible per cada carril d‟accés sigui superior als 0,80m.

Important: Si els torns tenen una distància lliure de pas superior als 80cm aleshores no

és necessari instal·lar pilones d‟emergència entre torns consecutius ni enfrontar-los.

Les prestacions tècniques requerides per a les pilones d’emergència són les següents:

Pilona d’emergència: separador metàl·lic cilíndric que evita el pas de persones entre torns i

que en cas d‟emergència ha deixar l‟espai lliure automàticament.

» Les dimensions de la pilona han de ser d‟entre 20cm (Prim) i 25cm (Wellington) de

diàmetre i una alçada a determinar en la fase de disseny (aprox. 0,80m d‟alçada).

» La distància entre l‟extrem del braç del torn i la pilona ha de poder ser de 3cm a Prim

i de 5 cm a Wellington.

» El model ha de poder “deixar caure la pilona” en cas d‟emergència i en cas de fallada

de l‟alimentació es valorarà si la pilona també ha de caure.

» El gruix de les pilones i el reforç interior de les mateixes han d‟evitar que aquestes es


B:SM

deformin per cops o sobrepès.

» La pilona i la seva instal·lació ha de complir amb tota la normativa vigent en el seu

àmbit d‟aplicació. En particular, i entre d‟altres, la normativa de seguretat i salut en la

manipulació de càrregues a la feina (Reial Decret 487/1997).

» Tota la instal·lació de les pilones va a càrrec de l‟Adjudicatari, incloent el forat per

encabir la pilona en situació d‟emergència.

Lector i validador d’entrades

Cadascun dels torns ha d‟anar equipat amb una unitat de control per a la lectura i valida-

ció de les entrades i carnets del recinte, així com també per implementar la interfície

d‟usuari amb el visitant del Parc. Les prestacions tècniques requerides pel lector són:

lector de codi de barres: lector de codis de barra de tipus area imager per poder llegir els

codis unidimensionals (1D) i bidimensionals (2D) més habituals: Codi 128, Codi 39, Interlea-

ved 2/5, EAN 13, QR Code, Data Matrix, etc.

» D‟acord amb el model de venda i accés al Zoo, es preveu la necessitat de llegir codis

EAN-13 (carnets Zoo Club) i codis QR (entrades EuroMus, entrades caixer).

lector de NFC: lector de dispositius NFC (13,56MHz).

pictogrames estat: matriu de LED o pantalla que permeti informar sobre l‟estat del torn:

obert, tancat, validació, etc.

visor informatiu viatger: pantalla que permeti mostrar missatges o imatges sobre l‟estat de

la validació a l‟usuari: estat, benvingut, accés duplicat, carnet caducat, entrada incorrecta, etc.

àudio: sortida d‟àudio que permet emetre senyals acústiques sobre l‟estat de validació.

unitat de control: ordinador on s‟executa l‟aplicació de control d‟accés i que controla tots els

perifèrics del moble: pictogrames, pantalla, àudio, lectors d‟entrades, etc.

» B:SM no es defineix cap requeriment tècnic particular sobre la plataforma (SO, CPU,

ROM, RAM, etc.) o el fabricant de la unitat de control, però la seva capacitat de pro-

cessament i emmagatzematge ha de permetre implementar tots els requeriments del

plec.

» La unitat de control i totes les seves aplicacions han de poder ser configurades remo-

tament, preferiblement a través d‟un accés web HTTP protegit amb usuari i clau.

» El dispositiu de lectura i validació ha de complir tant amb la normativa elèctrica com

amb la normativa electromagnètica vigent en el seu entorn d‟operació.

En la seva oferta el Licitador ha d‟incloure les especificacions tècniques dels lectors, de la

unitat de control i de tots els perifèrics requerits.

L‟Adjudicatari ha d‟afegir els components adients per poder garantir les següents condici-

ons d’operació amb els dispositius de validació dels trons d‟accés al Zoo:

El Sistema ha de garantir la plena continuïtat en la validació d’entrades en qualsevol dels

punts d‟accés al recinte, malgrat les possibles incidències en qualsevol dels següents àmbits:

» pèrdua comunicació / servei: els dispositius locals dels punts d‟accés han de poder

seguir llegint i validant entrades en local fins que es restableixi la comunicació amb el

servei central del mòdul d‟accés (mode “off-line”).


B:SM

Dispositiu mòbil PDA

En determinades circumstàncies s‟hauran de poder habilitar punts d‟accés controlats amb

personal equipat amb un dispositiu mòbil de tipus PDA i que permetin realitzar les lectures

i validacions d‟entrades equivalents a les d‟un torn d‟accés.

No obstant, el subministrament de les PDA anirà a càrrec de B:SM, ja que s‟està valorant

aprofitar els dispositius disponibles actualment al Zoo.

Els requeriments tècnics en relació a les prestacions físiques i elèctriques del dispositiu

mòbil de validació en els punts d‟accés al recinte són els següents:

La lectura i validació d‟entrades Paper Ticket, Home Ticket i Mobile Ticket s‟ha de poder fer

amb un únic dispositiu amb les següents prestacions físiques o elèctriques:

» model: dispositiu mòbil PDA amb lector de codis de barres 1D i 2D.

» dimensions: l‟ergonomia, les dimensions i el pes del dispositiu han de permetre que

el porter el pugui utilitzar fàcilment i amb una sola mà per llegir i validar les entrades. El

porter també ha de poder quedar-se amb les mans lliures: corretja de coll o de mà.

» protecció: el dispositiu mòbil ha de tenir, com a mínim, un índex de protecció IP 54 i

ha de poder operar correctament en les condicions ambientals de les portes d‟accés al

recinte (semi cobert).

» autonomia: el dispositiu ha de tenir una autonomia mínima de 6 hores en operació

continuada.

La capacitat de la bateria [Ah] ha de permetre assolir l‟autonomia requerida, però es valo-

rarà positivament qualsevol prestació tècnica que permeti optimitzar el consum, els temps

de recàrrega i el pes de les bateries del dispositiu.

B:SM no es defineix cap requeriment tècnic particular sobre la plataforma (SO, CPU, ROM,

RAM, etc.) o el fabricant del dispositiu de validació, però la seva capacitat de processa-

ment i emmagatzematge ha de permetre implementar tots els requeriments del plec.

Les prestacions tècniques requerides pel dispositiu mòbil són les següents:

El dispositiu de validació ha de tenir les següents prestacions tècniques:

» pantalla: preferiblement, pantalla gràfica tàctil de baix consum.

» botons: preferiblement, els botons estrictament necessaris per validar entrades. En

general, hi haurà més d‟un botó per executar l‟ordre d‟escanejar el codi de barres.

» avisos: el dispositiu ha de poder emetre notificacions amb sons.

» escàner codis 1D: el dispositiu ha de tenir un lector làser o per imatge dels formats

estàndard de codi de barres lineals més habituals: CODE 128, CODE 39, Interleaved

2/5, EAN, UPC, etc. B:SM es reserva el dret d‟afegir nous formats de codis de barres.

» escàner codis 2D: el dispositiu ha de tenir un lector per imatge de codi de barres bi-

dimensional imprès sobre paper (Paper / Home Ticket) i també mostrat en la pantalla

d‟un telèfon mòbil (Mobile Ticket). Formats: QR Code, Datamatrix, PDF 417, etc.

» xarxa local: el dispositiu ha de disposar d‟una interfície compatible amb la infraestruc-

tura de comunicacions del sistema en les portes d‟accés al recinte WiFi b/g/n.

» Sistema Operatiu: No s‟especifica fabricant ni versió mínima del sistema operatiu.


B:SM

» Opcionalment, el dispositiu pot tenir altres interfícies de comunicació: Bluetooth, etc.

» El dispositiu mòbil de validació ha de complir tant amb la normativa elèctrica com

amb la normativa electromagnètica vigent en el seu entorn d‟operació.

D‟altra banda, l‟Adjudicatari pot comptar amb punts d‟accés WiFi instal·lats en totes les

zones d‟accés al Zoo:

El punts d‟accés WiFi del Sistema poden tenir les següents prestacions tècniques:

» WiFi: 802.11 b/g/n (11Mbps / 54 Mbps). Compatibilitat amb dispositiu mòbil.

» seguretat: WPA-PSK-TKIP o WPA2-PSK-AES. Compatibilitat amb dispositiu mòbil.

» autenticació: WPA2 i per MAC en dispositiu local. Sense WiFi Protected Setup.

Compatibilitat amb dispositiu mòbil.

B:SM serà responsable del subministrament, instal·lació, configuració i manteniment de tots

els punts d‟accés WiFi del recinte.

També s‟omet de l‟àmbit de subministrament la instal·lació del cablatge PoE entre el punt

d‟accés WiFi i l‟armari de comunicacions amb la xarxa de transport. Aquesta instal·lació serà

subministrada i instal·lada per BSM i es farà arribar fins la ubicació definitiva del punt d‟accés

WiFi, consensuat entre l‟Adjudicatari i el personal tècnic de B:SM.

Dins l‟àmbit de les PDA és necessari subministrar els següents components:

Els components a subministrar relacionats amb el dispositiu mòbil són els següents:

» Software de control d’accés: 3 llicències per PDA per al SW de control d‟accés, equi-

valent al programari de validació dels torns.

Observar que s’exclou explícitament el subministrament del dispositiu PDA i dels seus

components: bateria de recanvi, alimentador, etc.

B:SM subministrarà a l‟Adjudicatari les PDA on s‟haurà d‟instal·lar el SW d‟acord amb les

especificacions del propi Adjudicatari. Cal tenir en compte que una de les opcions que

s‟estan valorant és l‟aprofitament de les PDA actuals (Motorola MC5509).

Per últim, l‟Adjudicatari ha d‟afegir els components adients per poder garantir les següents

condicions d’operació amb els dispositius de validació de les portes d‟accés al recinte:

El Sistema ha de garantir la plena continuïtat en la validació d’entrades en qualsevol dels

punts d‟accés al recinte, malgrat les possibles incidències en qualsevol dels següents àmbits:

» pèrdua comunicació / servei: els dispositius locals dels punts d‟accés han de poder

seguir llegint i validant entrades en mode llista negra fins que es restableixi la comuni-

cació amb el servei central del mòdul d‟accés.

» alimentació (dispositiu): si el dispositiu perd o esgota la seva font d‟alimentació,

aquest ha de permetre el canvi de bateria sense perdre la configuració o s‟ha de confi-

gurar autònomament i automàticament i amb un temps raonable. En cap cas

s‟acceptarà haver de tornar a instal·lar tot el programa.

http://grouper.ieee.org/groups/802/3/


B:SM

Dimensionament dels accessos al Zoo

La relació de tipus de torns i dispositius PDA que està previst instal·lar en les diferents

zones d‟entrada i sortida del Parc zoològic de Barcelona és la següent:

Zona d’entrada i/o sortida Torns 3 braços

Pilones emergència

Torns adaptats

Dispositius PDA

Accés taquilles Wellington 4 (950mm)* 2 2 2

Accés taquilles Prim 4 (850mm)* 2 1 1

Accés Oficina Zoo Club Wellington 0 0 0 0

Sortida botiga Prim 0 0 0 0

Accés escola 0 0 0 0

TOTAL 8 4 3 3

* Distància entre peus de torns consecutius. Observar que es els torns de Prim són de 850mm i

els torns de Wellington de 950mm.

Observar que el nombre total de carrils d‟entrada i sortida per Wellington serà de 8 (6 torns

i 2 PDA) i per Prim de 5 (5 torns i 1 PDA). El cap d‟operacions del Parc podria decidir tras-

passar una de les PDA de Wellington a Prim.

En la seva proposta tècnica, el Licitador ha de presentar un exemple detallat de distribució

dels torns en cadascuna de les zones d‟accés al Zoo.

Als Licitadors se‟ls facilitarà els plànols en format DWG i PDF de les diferents zones

d‟entrada i sortida del recinte per poder realitzar una proposta a escala de la ubicació dels

torns.

Cal tenir en consideració que tots els torns de les taquilles de Wellington s‟hauran

d‟instal·lar a la banda esquerra de les taquilles, de manera que la banda dreta no cal ins-

tal·lar-hi torns.

En aquest mateix sentit, cal destacar que B:SM instal·larà portes d‟emergència en l‟espai

sobrant a l‟esquerra de Wellington. Únicament cal instal·lar 6 torns (4 tres braços i 2

d‟adaptats d‟un sol braç).

En cas d‟evacuació, és imprescindible garantir un espai lliure de sortida d‟un mínim de

3,15m a l‟accés de Prim i de 4,80 metres a l‟esquerra de les taquilles de Wellington (dins

d‟aquest espai s‟hi inclou la porta a l‟esquerra de Prim).

Recordar que el subministrament de les PDA s‟exclou del present plec i que únicament

s‟han de subministrar les llicències del SW de control d‟accés per PDA [veure secció anteri-

or].

Durant la fase de disseny es consensuarà amb Serveis Tècnics de B:SM la ubicació defi-

nitiva de les diferents tipologies de torns com a pas previ a la seva fabricació.

Durant la fase de disseny B:SM es reserva l‟opció de sol·licitar una modificació de tipolo-

gia de torn per una de les dues zones d‟accés, és a dir es pot sol·licitar a l‟Adjudicatari la

substitució d‟un torn convencional per un d‟adaptat o viceversa sense cost addicional.

REQUERIMENTS tècnics: Aplicació de control d‟aforament 31

B:SM

APLICACIÓ DE CONTROL D’AFORAMENT

L‟abast de l‟aplicació de control d‟aforament consisteix bàsicament en el comptatge del

flux entrant i sortint del recinte, a fi i efecte de poder detectar situacions relacionades amb

l‟aforament del Parc zoològic de Barcelona en temps real.

En aquest context, els components de l‟aplicació de control d‟aforament són els següents:

Gràfic 6: components de l‟aplicació de control d‟aforament

En relació al control d‟aforament, es preveu un punt de control d‟aforament ubicat a les

oficines del Zoo per poder monitorar i supervisar l‟operació d‟accés i l‟estat d‟aforament

del recinte en temps real.

En el punt de control d’aforament, es requereix un lloc de treball per poder fer el seguiment i

monitoratge de l‟operació d‟accés al recinte des d‟un ordinador amb la corresponent aplicació.

» L‟entorn d‟execució de l‟aplicació de control d‟aforament pot ser de tipus Client / Ser-

vidor (C/S) o de tipus web basat en un navegador Internet, però en qualsevol cas, la in-

terfície d‟usuari ha de mostrar periòdicament i automàticament les alarmes i l‟estat

d‟aforament del recinte.

» B:SM es fa càrrec del subministrament hardware i l‟Adjudicatari de la instal·lació,

configuració i manteniment de tots els components software del punt de control.

Si els serveis centrals de l‟aplicació de control d‟aforament requereixen d‟un servidor web,

aquest s‟instal·larà en un CPD de B:SM.

En la fase de disseny, B:SM i l‟Adjudicatari del Sistema definiran en detall les funcions i

els equipaments necessaris en les ubicacions dels punts de control d‟aforament.

B:SM es reserva l‟opció de demanar amb posterioritat més llocs de treball amb l‟aplicació

de monitoratge d‟aforament o bé el canvi d‟ubicació d‟aquesta.

REQUERIMENTS tècnics: Aplicació de BackOffice 32

B:SM

APLICACIÓ DE BACKOFFICE

Dins l‟àmbit de subministrament s‟inclou una aplicació de BackOffice per configurar el Sis-

tema i per explotar les dades d‟accés del Zoo.

L‟aplicació de BackOffice ha de permetre administrar, configurar i explotar les dades del

sistema de control d‟accés des d‟algun lloc de treball de les oficines del recinte:

A les oficines del recinte es requereix d‟un lloc de treball d‟usuari administrador de l‟aplicació

de BackOffice per poder administrar i configurar el Sistema.

» L‟entorn d‟execució de l‟aplicació de BackOffice en mode administrador serà preferi-

blement a través d‟un navegador Internet.

» La configuració i administració del Sistema anirà a càrrec de l‟Adjudicatari.

» B:SM es fa càrrec del subministrament Hardware i l‟Adjudicatari de la instal·lació,

configuració i manteniment de tots els components Software del BackOffice.

A les oficines també es requereixen diversos llocs de treball d‟usuaris de consulta (explota-

ció) de l‟aplicació BackOffice per poder explotar les dades d‟accés i d‟aforament del Sistema.

» Preferiblement, l‟aplicació de BackOffice en mode consulta o explotació s‟hauria de

basar en tecnologia Internet i hauria de ser accessible a través d‟un navegador Internet.

Si els serveis centrals de l‟aplicació de BackOffice requereixen d‟un servidor web, aquest

s‟instal·larà en un CPD de B:SM o bé on la divisió de Sistemes indiqui.

En la fase de disseny, B:SM i l‟Adjudicatari del Sistema definiran qui i amb quins permisos

pot accedir a l‟aplicació de BackOffice del Sistema de control d‟accés i d‟aforament.

B:SM es reserva l‟opció de demanar amb posterioritat més llocs de treball amb l‟aplicació

de BackOffice en qualsevol oficina corporativa.

REQUERIMENTS tècnics: Serveis centrals 33

B:SM

SERVEIS CENTRALS

El sistema de control d‟accés al Zoo de Barcelona és un sistema crític, ja que un funcio-

nament imprecís, poc fiable o interromput seria una font de conflictes operatius que no es

podrien assumir. Per tant, és imprescindible garantir un elevat nivell de servei en un en-

torn plenament segur, amb dades d‟accés fiables i on cal redundar esforços per fer front a

possibles incidències tècniques amb el sistema.

Seguidament es desenvolupen els requeriments tècnics dels serveis centrals del sistema,

així com també de les interfícies amb serveis o aplicacions de tercers.

Entorn d’execució

Els requeriments i els principals condicionants tècnics de l‟entorn d‟execució dels serveis

centrals del sistema són els següents:

L‟estàndard de Base de Dades de B:SM és SQL Server 2008, i per tant els SSCC del siste-

ma s‟haurà d‟executar en aquest entorn. Alternativament, es disposa d‟un clúster Oracle.

» Les llicències SW dels serveis centrals (SO (Windows Server 2008 R2), BBDD, ser-

vidor web, etc.) i els components HW aniran a càrrec de B:SM, que també posarà a

la disposició de l‟Adjudicatari els servidors de pre-producció i els de producció.

» BSM no estableix cap requeriment particular sobre el fabricant o les versions de les

aplicacions d‟aquesta plataforma. No obstant si el SO es Windows, aquest haurà de

Windows 2008 R2 o superior; i si és Linux un Red Hat 5.8 o superior.

» B:SM es farà càrrec del subministrament Hardware i de les comunicacions amb del

CPD (rack, servidors, xarxa, Internet, etc.) i l‟Adjudicatari de la instal·lació, configura-

ció i manteniment de tots els components software: BBDD, servidor aplicacions, etc.

El Licitador descriurà en la seva oferta les prestacions tècniques de la plataforma (SO, ser-

vidors, BBDD, etc.) on s‟executen els serveis centrals del Sistema de control d‟accés

» Les prestacions del/s servidor/s (CPU, RAM, disc, etc.) han de garantir el compliment

dels requeriments tècnics i funcionals del mòdul de control d‟accés, i han de respectar

el pla de contingència proposat per l‟Adjudicatari.

» L‟Adjudicatari s‟ha de fer càrrec de la instal·lació, configuració i manteniment de tots

els seus components Software dels servidors dels serveis centrals del Sistema.

D‟acord amb això, els serveis centrals dels sistema s‟executaran en servidors instal·lats

en el Centre de Processament de Dades (CPD) de B:SM, qui també es farà càrrec, si cal,

de l‟adquisició del maquinari i programari per a la configuració bàsica dels servidors re-

querits i que s‟integraran amb les eines de seguretat i monitoratge corporatives.

Durant la fase de disseny, l‟Adjudicatari haurà de definir i consensuar amb la divisió de

Sistemes de B:SM l‟arquitectura i les prestacions tècniques requerides a nivell de maqui-

nari i programari en els serveis centrals del sistema.

Sempre sota la supervisió i aprovació per part de Sistemes de B:SM, l‟Adjudicatari serà

plenament responsable del disseny, de la implementació del model de dades i dels proce-

diments emmagatzemats o tasques de la Base de Dades del sistema de control d‟accés.

La proposta tècnica presentada pel Licitador estarà subjecte a la validació i aprovació per

part de B:SM.


B:SM

Continuïtat del servei

Els components i aplicacions client / servidor del sistema s‟han de dissenyar i dimensionar

d‟acord amb el corresponent pla de contingència o de continuïtat del negoci.

Els components i totes les aplicacions del sistema de control d‟accés al recinte han de dis-

posar d‟un pla de contingència amb el requeriment de continuïtat en les funcions de control

d‟accés, en cas d‟incidència tècnica greu: pèrdua de comunicacions, caiguda de servidor,

subministrament elèctric, emergència, etc.

» En la seva oferta, el Licitador haurà de presentar a B:SM els principals procediments i

prestacions del seu pla de continuïtat de negoci per l‟arquitectura de sistemes de la solu-

ció proposada pels punts de control d‟accés al Zoo.

A nivell d‟aplicació de control d‟accés, cal garantir la continuïtat dels accessos en cas de

caiguda de serveis centrals o dels sistemes amb els que interaccionen amb el control d‟accés

com per exemple el SGS (validació de socis), entrades de taquilles o web, etc. (mode off-line).

» En la seva oferta, el Licitador haurà de presentar a B:SM el funcionament del sistema

de control d‟accés en cas de manca de comunicació amb els serveis centrals del propi

sistema, així com també el procediment per transferir les dades locals als servidors un

cop restablerta la comunicació.

Observar que és especialment necessari dissenyar el sistema de control d‟accés amb un

mode de funcionament off-line i un procediment per recuperar les dades d‟accés un cop

es restableixi la comunicació amb els serveis centrals.

Monitoratge del sistema

Els serveis centrals del sistema de control d‟accés han de disposar de mecanismes de

monitoratge del maquinari i del programari dels mòduls client i servidor del propi sistema.

L‟Adjudicatari haurà d‟implantar funcions de monitoratge hardware mitjançant les eines

que conjuntament amb B:SM s‟estableixin durant l‟etapa de disseny.

L‟Adjudicatari haurà d‟implantar funcions de monitoratge software mitjançant un sistema

de traces que pugui ser exportable a una aplicació de gestió de traces. El nivell de detall

de les traces de programa del sistema ha de ser un paràmetre de configuració i aquestes

s‟han de poder agrupar per categories, com a mínim: error, advertència, informació.

Durant l‟etapa de disseny es valoraran diverses alternatives tècniques per implementar

l‟enregistrament de les traces: arxius de traces (log), etc.

Els serveis centrals del sistema han de disposar de mecanismes d‟avís i enviament

d‟alarmes per correu electrònic als responsables d‟Operació de la divisió de Sistemes.

El sistema ha de poder eliminar periòdicament i automàticament traces superiors a una

certa antiguitat, a fi i efecte d‟evitar un volum de dades excessiu en els arxius de registre.

Preferiblement, el monitoratge i configuració dels mòduls client del sistema de control

d‟accés es realitzarà a través d‟una interfície web (navegador).


B:SM

Enregistrament de dades històriques

El sistema ha de permetre guardar permanentment i periòdicament les dades històriques

generades per l‟ús de les aplicacions d‟accés, a fi i efecte d‟evitar un volum de dades ex-

cessiu en la base de dades del sistema.

Nivell de servei del sistema

Com a criteri general i amb l‟objectiu de poder acotar el disseny tècnic i la valoració eco-

nòmica de l‟arquitectura de sistemes dels serveis centrals, seguidament es presenten els

requeriments relacionats amb la seva disponibilitat i nivell de servei:

serveis crítics: els serveis assenyalats com a crítics estan sotmesos a requeriments d‟alta

disponibilitat, que haurà de ser superior o igual al 99,5% del temps, mesurat mensualment.

» Les solucions d‟alta disponibilitat generals o per cada servei hauran de ser aprovades

per BSM. En qualsevol cas es valorarà la relació entre el nivell de servei obtingut i el seu

cost d‟implantació (maquinari, programari...) i d‟explotació (operadors, manteniment...).

» A l‟Adjudicatari se l‟eximeix de caigudes a nivell de HW, SO i gestor de BBDD que no

siguin responsabilitat d‟aplicacions i components inclosos dins l‟àmbit de subministra-

ment.

» Recordar que s‟estableixen com a serveis crítics aquells que estan relacionats amb la

validació dels accessos en temps real.

horari del servei: totes les aplicacions i serveis del sistema han d‟estar operatives durant

l‟horari d‟oficina i d‟obertura del Parc.

» Els procediments massius de BackOffice (còpies de seguretat, transferència de dades,

neteja de dades, etc.) es realitzaran preferentment en horaris nocturns o de matinada.

suport a l’operació: la resolució d‟incidències en els serveis centrals del sistema s‟ha de

correspondre amb el que s‟indica en la corresponent secció del plec. [veure “manteniment”]

» En aquest àmbit, el temps de resolució de les incidències crítiques o greus també de-

termina el nivell de servei exigit. [veure nivell de resolució d‟incidències]

» Recordar que un dels criteris importants del sistema és la traçabilitat per poder diag-

nosticar amb facilitat les incidències de programari. En aquest àmbit és especialment

necessari que les traces de programa siguin prou detallades i alhora exportables a eines

que en permetin la consulta sense afectar el rendiment dels servidors.

» Els horaris del servei de suport tècnic s‟hauran d‟adaptar a les condicions establertes

per les àrees operatives del Zoo en cada àmbit [veure “manteniment i suport a l‟operació”].

L‟alta disponibilitat del servei de Base de Dades del sistema queda garantida per

l‟arquitectura redundant de la BBDD (si s‟utilitza el clúster Oracle), en canvi per a la resta de

serveis B:SM i l‟Adjudicatari valoraran conjuntament la solució per garantir el nivell de ser-

vei exigit.

A nivell de servidor, els serveis centrals del sistema s‟han d‟executar com a servei i s‟han

de dotar dels tots els mecanismes de salvaguarda necessaris, perquè en cas de caiguda

o excepció del servei, aquest es torni a executar sense la intervenció dels operadors.

En general, en els sistemes o serveis crítics s‟han de contemplar mecanismes d‟alta dis-

ponibilitat i contingència.


B:SM

Infraestructura de xarxa

Barcelona de Serveis Municipals posarà a disposició de l‟Adjudicatari del present plec una

complerta xarxa de comunicacions per poder connectar les diferents zones d‟accés al re-

cinte amb el Centre de Processament de Dades.

El Parc Zoològic de Barcelona disposa de 4 zones d‟accés públic al recinte: Accés Wellin-

gton, Accés Prim, Accés Zoo Club Wellington (previst 2017), Escola (únicament solució de

comptador d‟aforament sense torns).

Barcelona de Serveis Municipals instal·larà els punts d‟accés WiFi necessaris per perme-

tre la comunicació amb els dispositius mòbils de tipus PDA.

En el present plec, també s‟exclou el subministrament i la instal·lació del cablatge elèctric,

del cablatge de comunicacions i dels components de la infraestructura de xarxa de trans-

port entre el CPD i les diferents zones d‟accés al Parc.

REQUERIMENTS tècnics: Integració amb sistemes i serveis 37

B:SM

INTEGRACIÓ AMB SISTEMES I SERVEIS

El sistema de control d‟accés al Zoo s‟ha d‟integrar amb diversos sistemes d‟informació

per poder validar les entrades al recinte en temps real.

Integració amb Sistema de Gestió de Socis (SGS)

El sistema de control d‟accés s‟ha d‟integrar amb el Sistema de Gestió de Socis de B:SM

(SGS) per tal de poder consultar en temps real la validesa d‟un carnet de soci llegit pel

propi control d‟accés.

Actualment, totes les funcionalitats relacionades amb la gestió de socis del Parc es realit-

za a través del Sistema de Gestió de Socis (SGS) de B:SM.

Un dels requeriments del nou sistema de control d‟accés del Zoo és permetre l‟entrada als

socis del Parc, a partir de la lectura del codi de barres (7-8 dígits en format EAN-13) imprès

en la seva targeta Zoo Club.

En aquest cas i d‟acord amb els requeriments funcionals, el sistema de control d‟accés ha

de consultar en temps real al SGS sobre la validesa del carnet soci a través d‟una interfí-

cie de comunicacions que B:SM posarà a disposició de l‟Adjudicatari.

Previsiblement, aquesta interfície de comunicació serà un procediment emmagatzemat o

una funció SQL que podrà ser executada des dels serveis centrals del sistema de control

d‟accés en base a una petició realitzada per la unitat de control dels torns:

validesa del soci en temps real: es publicaria una funció SQL perquè el control d‟accés pu-

gui consultar en temps real si el soci està actiu. El control d‟accés haurà de mostrar clarament

la causa en cas de resposta negativa o altrament deixar accedir el soci al recinte.

En cap cas es podrà implementar aquesta integració mitjançant la càrrega manual o automà-

tica diària de fitxers (tipus Excel o similar) contra la BBDD central o local del control d‟accés.

Recordar que si cau la xarxa de comunicació o els serveis centrals, el sistema de control

d‟accés ha d‟operar en mode “off-line” validant que el format del carnet de socis és correc-

te i en aquest cas deixar-lo passar.

D‟altra banda, les entrades del Zoo adquirides pels socis a les taquilles incorporaran un

codi de barres (a priori QR) que, entre d‟altres camps, també contindrà el número de soci

del carnet Zoo Club. No obstant, en aquest cas no serà necessari que el sistema de con-

trol d‟accés consulti la validesa del número de soci al SGS ja que el sistema de venda a

les taquilles ja ho haurà fet prèviament.


B:SM

Integració amb el sistema de venda d’entrades a taquilles

El sistema de control d‟accés s‟ha d‟integrar amb el sistema de venda d‟entrades a les

taquilles del Parc per tal de poder validar en temps real les entrades venudes a les taqui-

lles.

D‟acord amb el model de venda i validació descrit en el capítol 2, les entrades de taquilles

es codificaran amb un codi únic, xifrada però intel·ligible pel sistema de control d‟accés,

que contindrà informació sobre la validesa de l‟entrada: data límit de validesa, taquilla,

número de sèrie, codi de control, etc.

A priori, no es preveu doncs necessari una integració basada en llistes blanques

d‟entrades venudes a les taquilles i transferides en temps real al sistema de control

d‟accés, fet que hauria de simplificar la solució i donar major robustesa enfront incidències

tècniques en la xarxa del model de validació.

D‟altra banda, observar que el sistema de control d‟accés haurà de mantenir una llista ne-

gra centralitzada de les entrades consumides per tal d‟evitar que una mateixa entrada pu-

gui accedir des de qualsevol punt d‟accés al recinte un cop cancel·lada.

Recordar que el sistema de control d‟accés també s‟ha d‟integrar amb el sistema de ven-

da d‟entrades en el traspàs d’informació estadística diària del nombre d‟accessos validats

directament als torns: carnets de socis, entrades web, invitacions, etc.

D‟altra banda, el sistema de control d‟accés també ha de poder obtenir la informació dels

accessos per l‟Escola a partir de les dades disponibles en el sistema de venda d‟entrades.

Integració amb el mòdul d’entrades web del Zoo

El sistema de control d‟accés s‟ha d‟integrar amb el mòdul de venda d‟entrades a través

del lloc Internet del Zoo (proveït pel Centre de Càlcul de Girona) per tal de poder validar di-

rectament les entrades web.

D‟acord amb el model de venda i validació descrit en el capítol 2, la integració amb el mò-

dul de venda d‟entrades web del Zoo s‟ha de poder realitzar per dues vies:

llista blanca d’entrades web: el sistema de control d‟accés ha de poder sincronitzar-se amb

una llista blanca d‟entrades web codificades unívocament amb un número aleatori. Un cop

validat el codi aquest ha de quedar marcat com a “consumit” en el sistema de control d‟accés.

El procés de sincronisme de llistes es definirà conjuntament amb els dos proveïdors i B:SM

durant la fase de disseny del sistema.

codificació intel·ligent: el sistema de control d‟accés ha de poder validar codis d‟entrades

xifrats però intel·ligibles, equivalents o similars als emesos per les taquilles del recinte.

En aquest cas, no és necessari un sincronisme de llistes blanques entre sistemes. El sistema

de control d‟accés ha de mantenir una llista negra centralitzada d‟entrades consumides.

La codificació exacte de les entrades emeses per les taquilles o a la web del Zoo es defi-

nirà, conjuntament amb els adjudicataris del sistema de venda d‟entrades i del sistema de

control d‟accés durant la fase de disseny d‟ambdós projectes i que seran coincidents en el

temps (fase d‟especificació).


B:SM

Integració amb altres canals de venda per Internet

Opcionalment, el sistema de control d‟accés s‟ha d‟integrar directament amb els canals de

venda per Internet de tercers: Atrápalo, Urban Check, Goupon, etc.

El licitador pot oferir una solució tècnica i funcional que permeti la validació directa de les

entrades adquirides a través de portals Internet de tercers a través del sistema de control

d‟accés sense necessitat de bescanviar les entrades a les taquilles del Zoo.


5. PLANS D’EXECUCIÓ

Seguidament es presenten els plans d‟execució i les condicions de lliurament de les apli-

cacions i serveis del sistema de control d‟accés i d‟aforament del Zoo de Barcelona, inclo-

sos dins l‟àmbit de subministrament del present plec de condicions.

En la seva oferta tècnica, el Licitador ha de presentar una primera proposta detallada de

cronograma i un sumari dels plans d‟execució per al subministrament de totes les aplica-

cions i serveis incloses dins l‟àmbit de subministrament del present plec.

Posteriorment, durant la fase de disseny del Sistema, l‟Adjudicatari haurà de desenvolupar

per complert tots els plans d‟execució proposats en la seva oferta:

pla d’implantació: proposta de planificació detallada del projecte d‟implantació de les aplica-

cions i serveis incloses dins l‟àmbit de subministrament del plec (fins a l‟inici d‟operacions).

pla de formació: proposta de formació per tot el personal que intervé en la implantació, ad-

ministració i operació de les aplicacions i components del Sistema.

pla de manteniment i suport a l’operació: proposta de manteniment i suport a l‟operació del

sistema de venda i validació d‟entrades del Parc.

pla d’acceptació: documentació a lliurar i proposta de proves per a l‟acceptació de les apli-

cacions i serveis del projecte.

En general, tots els documents i/o plans d‟execució del projecte hauran de ser necessàri-

ament aprovats per la Direcció del Projecte del Parc i Sistemes de B:SM, tot i que aquest

fet no eximirà a l‟Adjudicatari de la plena responsabilitat respecte al contingut del mateix.

Seguidament es descriuen els requeriments relacionats amb les condicions de lliurement

de les aplicacions i serveis del Sistema incloses en el plec.

PLANS D‟EXECUCIÓ: Pla d‟implantació 41

B:SM

PLA D’IMPLANTACIÓ

El seguiment i control del disseny, desenvolupament, integració, instal·lació configuració,

manteniment i operació de les diferents aplicacions del Sistema es realitzarà sobre la ba-

se del pla d'implantació, que serà elaborat prèviament per l'Adjudicatari i haurà de ser

aprovat per la direcció del Parc.

En la seva oferta tècnica, el Licitador ha d‟incloure una proposta de pla de treball, indicant

les tasques, els terminis i els recursos humans i materials proposats per poder implantar

el conjunt d‟aplicacions i serveis inclosos dins l‟àmbit de subministrament del present plec.

Com a mínim, en el pla d‟implantació haurà de definir i concretar els següents aspectes:

Les activitats, els terminis i les responsabilitats dels projectes planificats.

El perfil, responsabilitats i dedicació dels recursos humans proposats (propis, subcontrac-

tats, etc.) en cadascuna de les tasques del projecte.

El calendari de les tasques i de les principals fites dels projectes, incloent totes les restricci-

ons relacionals o temporals necessàries.

La relació de d‟entrades (documents, requeriments...) i sortides (documents, especificaci-

ons, subministraments...) en cadascuna de les fases de les tasques planificades.

Els components i recursos materials previstos, així com els requeriments o condicionants

relacionats amb la seva adquisició, fabricació, recepció, logística o instal·lació.

La metodologia i procediments previstos en relació al seguiment i coordinació dels projectes

en totes les seves fases: enginyeria, desenvolupament, homologació, instal·lació, proves, etc.

La metodologia de treball proposada en la realització dels serveis i en la implantació de les

aplicacions i serveis inclosos dins l‟àmbit de subministrament del plec.

Aquest projecte implica la implantació d'un nou Sistema que ha de coexistir amb el funci-

onament normal del Parc. L'Adjudicatari haurà de tenir en consideració les limitacions i

condicions introduïdes per aquesta problemàtica: disponibilitat horària, entorn de proves,

etc.

Per l‟elaboració del pla d‟implantació, el Licitador s‟haurà de basar en el cronograma ge-

neral del programa d‟implantació del Sistema en el present plec, on s‟hi indica la relació

d‟aplicacions i projectes i les seves principals fites.

En general, B:SM valorarà les propostes tècniques o organitzatives que permetin optimit-

zar o millorar els terminis i procediments relacionats amb la implantació del Sistema, con-

siderant les relacions de dependència amb altres projectes.


B:SM

Cronograma i àmbit d’intervenció

Seguidament es presenta un cronograma amb les durades màximes previstes en les fa-

ses d‟implantació de les aplicacions incloses dins l‟àmbit de subministrament del plec.

Gràfic 7: pla de treball previst: sistema de control d‟accés del Zoo de Barcelona.

Observar que tant les dates, com les fites del cronograma són estimatives i estan subjec-

tes a condicions temporals (publicació, contractació,...) i/o relacionals amb altres projectes.

No obstant, en el cronograma sí que s‟estableixen els terminis màxims previstos per cada

fase.

D‟acord amb el diagrama superior el termini de disseny, desenvolupament, proves i im-

plantació del Sistema és d‟uns 5 mesos. Cal destacar que la implantació del sistema pot

ser progressiva, és a dir primer s‟instal·larien i es provarien unes zones d‟accés (octubre

2016) i un cop validat el Sistema s‟implantaria la resta (desembre 2016).

Les tasques d‟enginyeria comú i desenvolupament de les aplicacions són relativament

intensives en recursos i per tant, requereixen un correcte dimensionament i organització

de l‟equip de treball proposat per poder generar la documentació, els desenvolupaments i

les proves d‟integració de les interfícies de comunicació amb els diferents sistemes.

El projecte de subministrament del Sistema s‟emmarca dins del programa de Ticketing del

Zoo, que conté els següents projectes:

venda d’entrades: projecte d‟implantació d‟un nou sistema de venda d‟entrades al Parc i que

s‟ha d‟integrar amb el nou sistema de control d‟accés al recinte.

maquinari i llicències: projecte de subministrament dels ordinadors TPV, servidors i altres

components HW requerits pel Sistema de venda i validació d‟entrades. Inclou llicències SO i

BBDD requerides pels serveis centrals del Sistema.

datàfons i passarel·la de pagament: projecte de subministrament i configuració de datàfons

integrats amb la passarel·la de pagament de B:SM (conexflow). Configuració de la pròpia

passarel·la de pagament per incloure les transaccions del Parc.

oficina Zoo Club: projecte de construcció d‟una nova oficina Zoo Club a Wellington (2017).

accessos Wellington: projecte d‟adaptació dels accessos a l‟entrada de Wellington (elimina-

ció jardinera, mur de separació, etc.), incloent l‟eliminació dels actuals torns.


B:SM

Algunes consideracions rellevants sobre les tasques i l‟àmbit d‟intervenció de l‟Adjudicatari

durant la fase d’especificació i enginyeria comú són les següents:

especificació: tasques relacionades amb l‟especificació detallada del desenvolupament del

sistema de control d‟accés del Parc segons el model de venda i validació d‟entrades.

» Des del punt de vista físic, la principal tasca d‟especificació serà la distribució i ubicació

precisa de les diferents tipologies de torn en les zones d‟accés al Parc. Aquesta tasca

tindrà prioritat i determinarà la tipologia de torns i pilones d‟emergència a subministrar.

» Les tasques d‟enginyeria comú s‟han de realitzar en coordinació amb la resta de prove-

ïdors i preferiblement s‟hauran d‟executar en paral·lel en tots els fronts. En concret, amb

el sistema de gestió de socis (BSM), el sistema de venda d‟entrades a taquilles (en licita-

ció), el mòdul de venda per Internet (CCalGir), etc.

» En aquesta fase l‟Adjudicatari ha de generar tots els documents d‟especificació deta-

llada de les interfícies de comunicació (protocol, model de dades, model d‟arxius, etc.)

entre el Sistema de control d‟accés i la resta de sistemes a interconnectar.

» En aquest àmbit és especialment important la integració amb el sistema de venda

d‟entrades per taquilles, web, invitacions, etc. per tal que aquestes entrades siguin reco-

negudes, validades i marcades com a “consumides” per part del sistema de control

d‟accés.

» Durant la fase d‟especificació, es prioritzarà també la definició i configuració de la codi-

ficació de tots els tipus d‟entrades. En aquesta fase l‟Adjudicatari ha de col·laborar en els

documents d‟especificació detallada dels continguts i formats dels codis de barra de les

entrades per a tots els tipus d‟entrada generades a través dels sistemes de venda.

» Tota la documentació d‟aquesta fase ha de ser lliurada a B:SM i aprovada per B:SM.

» La durada màxima de la fase de disseny tècnic i d‟enginyeria comú serà de 1,5 mesos

(6 setmanes), a comptar des de la data de signatura del contracte.

En aquesta mateixa línia, algunes consideracions rellevants sobre l‟àmbit d‟intervenció de

l‟Adjudicatari durant la fase de desenvolupament / adaptació aplicacions són les següents:

producció i desenvolupament: tasques relacionades amb la fabricació o desenvolupament

dels productes i aplicacions del sistema, d‟acord amb els requeriments del present plec.

» L‟Adjudicatari haurà de prioritzar aquells desenvolupaments relacionats amb les in-

terfícies de comunicació amb tercers (gestió de socis, entrades taquilles, entrades

web, estadístiques, etc.), respectant en qualsevol cas la planificació i les principals fites

del Sistema.

» L‟Adjudicatari també haurà de prioritzar la fabricació dels components del control

d‟accés basat en torniquets, a fi i efecte de garantir-ne la disponibilitat per la fase de

proves.

» L‟Adjudicatari haurà de prioritzar aquells desenvolupaments relacionats amb les llis-

tes blanques i negres d‟entrades, tan a nivell local com central.

» El tram final del desenvolupament s‟ha de compatibilitzar amb la prova pilot de totes

les aplicacions del Sistema i de les seves interfícies amb tercers.

» La durada màxima de la fase de desenvolupament de totes les aplicacions del Sis-

tema serà de 3 mesos a comptar des de l‟inici del contracte. Observar que la fabricació

dels components dels torns es podrà iniciar molt abans d‟acabar la fase de disseny

tècnic.


B:SM

Algunes consideracions relacionades amb l‟àmbit d‟intervenció de l‟Adjudicatari durant la

fase de prova pilot / pre-sèrie dels sistema són les següents:

prova pilot: després de la fase de desenvolupament es realitzarà una prova pilot integral per

validar tots els aspectes tècnics i funcionals de les aplicacions del Sistema i de les seves in-

terfícies amb altres sistemes i serveis de tercers en un entorn de producció.

» L‟Adjudicatari haurà de participar activament en la definició, realització i valoració de

les proves de configuració i d‟integració de sistemes i haurà de liderar un grup de treball

amb la resta de proveïdors per executar les proves pilot, sota la supervisió de B:SM.

» Entre d‟altres, es preveu necessari fer proves pilot en els següents àmbits: entrades

taquilles, entrades web, socis, aforament, estadístiques, mode off-line, emergència, etc.

» Durant aquesta fase l‟Adjudicatari ha d‟instal·lar, configurar i posar en funcionament els

torns, les aplicacions (control d‟accés, control d‟aforament, BackOffice), la integració amb

tercers i els serveis centrals del Sistema, d‟acord amb l‟arquitectura i la infraestructura

previstes en almenys una zona d‟accés al recinte (taquilla Prim o taquilla Wellington).

» La durada màxima de la prova pilot del Sistema serà de 1,5 mesos (6 setmanes) a

comptar des de la finalització de la fase de desenvolupament.

Finalment, algunes consideracions relacionades amb l‟àmbit d‟intervenció de l‟Adjudicatari

durant la fase d’implantació de totes les aplicacions del sistema són les següents:

instal·lació del Sistema: tasques relacionades amb la instal·lació, configuració, formació i

inici d‟operacions de tots els components i aplicacions del sistema de control d‟accés.

» Durant aquesta fase l‟Adjudicatari ha d‟instal·lar físicament els torns de control d‟accés

en totes les zones d‟accés del recinte.

» B:SM es compromet a deixar lliures els espais on s‟han d‟instal·lar els passadissos

d‟accés; desmuntant així els actuals torns de control d‟accés de les zones d‟accés.

» B:SM es compromet a subministrar i instal·lar el cablejat d‟alimentació i de comunicaci-

ons necessari per al correcte funcionament del sistema de control d‟accés.

» Durant aquesta fase l‟Adjudicatari ha d‟instal·lar, configurar i posar en funcionament els

torns, les aplicacions (control d‟accés i d‟aforament, BackOffice), la integració amb ter-

cers i els serveis centrals del Sistema, d‟acord amb l‟arquitectura i la infraestructura pre-

vistes.

» En especial, l‟Adjudicatari haurà de realitzar la instal·lació, configuració, prova i posta

en marxa de tots els passadissos de control d‟accés i dels serveis centrals d‟aquests.

» Durant aquesta fase l‟Adjudicatari també ha d‟executar el pla de formació.

» L‟Adjudicatari es compromet a realitzar les tasques de subministrament, instal·lació i

posta en marxa amb la màxima cura per tal d'evitar afectacions de servei no previstes.

En cas d‟afectar al servei, serà la seva responsabilitat restaurar els serveis afectats.

» És important destacar que algunes de les tasques d‟instal·lació i posta en marxa dels

torns de control d‟accés s‟hauran de realitzar en horari de Parc tancat.

» Totes les postes en marxa seran revisades i acceptades per tècnics de B:SM.

» El termini màxim per implantar i posar en marxa totes les aplicacions i els serveis cen-

trals del Sistema és de 1,5 mesos. La data límit per tenir el sistema operatiu és finals de

desembre del 2016.


B:SM

Observar que, abans d‟iniciar l‟operació real dels sistemes, l‟Adjudicatari ha de dur a ter-

me un pla de formació que permeti garantir la correcta preparació de tot el personal.

D‟acord amb la planificació prevista l‟operació del nou Sistema de venda i validació

d‟entrades ha d‟iniciar-se com a molt tard a finals de desembre de 2016.

Quan s‟iniciï l‟explotació del Sistema, qualsevol modificació o adaptació necessària es

realitzarà i implantarà , en primer lloc, en el servidor de pre-producció i un cop validades i

provades, les modificacions realitzades es traslladaran al servidor de producció d‟acord

amb les indicacions de la divisió de Sistemes i seguint la normativa de gestió del canvi.

Pla de migració

El sistema de control d‟accés s‟implantarà en dues etapes, la primera seria amb una prova

pilot en un dels accessos de Wellington a principis d‟octubre de 2016 i la segona a mitjans

de novembre de 2017 (instal·lació final).

Es preveu doncs un pla de migració basat en el següent esquema, que permet compatibi-

litzar dos models de venda i control d‟accés a Wellington durant un parell de mesos i

abans de fer la implantació definitiva d‟ambdós sistemes:

Gràfic 8: pla de migració previst en l‟accés Wellington en la fase de proves del sistema de control d‟accés del Zoo de Barcelona.

D‟acord amb això, es preveu una migració progressiva en l‟accés Wellington:

sistema actual: a la banda dreta es manté el sistema de venda i accés actual.

» Es mantenen tres punts de venda d‟entrades amb el sistema actual (Galaxy).

» Es mantenen els dos torns de la dreta de control d‟accés (SICA).

» Es manté un carril PDA a la dreta del control d‟accés (SICA – PDA).

» Les entrades web i part de les de taquilles (dreta) aniran amb el sistema actual.

sistema nou: a la banda esquerra s‟hi instal·la el nou sistema de venda d‟entrades i control

d‟accés en fase de proves.

» S‟instal·len dos punts de venda del nou sistema de venda d‟entrades (en licitació).

» S‟instal·len dos o tres torns nous a l‟esquerra de les taquilles de Wellington.

» Es contempla un possible carril PDA a l‟esquerra del control d‟accés.

» Les entrades de socis i part de les de taquilles (esquerra) aniran amb el sistema nou en

fase de proves.

El termini màxim per implantar el sistema en fase de proves és principis d’octubre de 2016.


B:SM

Gestió del projecte

D‟una banda, el Parc nomenarà un cap de projecte, que serà responsable de supervisar la

correcta execució de les aplicacions i serveis inclosos dins l‟àmbit de subministrament del

present plec.

En aquest mateix sentit, el Parc nomenarà els interlocutors i el seu àmbit d‟interlocució per

a cadascuna de les àrees i serveis afectats per la implantació del Sistema de control

d‟accés del Zoo.

D‟altra banda, l‟Adjudicatari haurà d‟anomenar un cap de projecte que serà l‟únic interlocu-

tor vàlid amb el Parc i que entre d‟altres, haurà de realitzar les següents funcions:

Vetllar per l‟assoliment dels objectius del projecte, segons planificació i pressupost previst.

Executar i fer el seguiment del projecte i del pla de treball (tasques, terminis, recursos, etc.),

generant la corresponent documentació: actes, planificació, informes, plans, etc.

Gestionar i executar el pla de comunicació del projecte. En particular, periòdicament, haurà

de comunicar al cap de projecte de BSM l‟estat d‟avançament dels projectes, amb la periodi-

citat que B:SM estableixi en cada moment, incloent un breu informe de seguiment i

l‟actualització de la planificació prevista.

Realitzar reunions de seguiment de projecte amb la periodicitat que B:SM estableixi.

Gestionar i valorar les peticions de canvi en el projecte, juntament amb BSM.

Gestionar i supervisar el compliment del pla de qualitat del projecte.

Gestionar i supervisar el riscos del projecte.

Gestionar i valorar els riscs del projecte i executar les actuacions previstes.

El Parc Zoològic de Barcelona anomenarà un Comitè de Direcció del projecte, en el que hi

haurà representats de les àrees o divisions afectades pel Sistema.

Aquest Comitè de Direcció vetllarà perquè l‟enfocament dels serveis i sistemes subminis-

trats es correspongui amb l‟abast i els objectius previstos.

Aquest Comitè de Direcció també podrà ser requerit en procediments administratius rela-

cionats amb l‟acceptació del projecte o l‟aplicació de les sancions previstes dins l‟àmbit del

present Contracte de subministrament i serveis.

PLANS D‟EXECUCIÓ: Pla de formació 47

B:SM

PLA DE FORMACIÓ

El Sistema de control d‟accés del Zoo és un sistema crític, i per tant, cal redundar els es-

forços per garantir que tot el personal que intervé en les operacions de venda i adminis-

tració té el suport tècnic i la formació necessària per poder operar amb el Sistema.

En aquest àmbit, és necessari que l‟Adjudicatari proposi un pla de formació per preparar

correctament tot el personal que interactua amb el Sistema.

Gràfic 9: àmbit i abast del pla de formació del sistema de control d‟accés al Zoo

En general, el pla de formació de l‟Adjudicatari ha de permetre assolir els terminis previs-

tos en el pla de treball per poder iniciar les operacions amb tot el personal format.

L‟Adjudicatari ha de proposar i dur a terme un pla de formació dirigit a tots els usuaris del

sistema de control d‟accés:

» àrea d’Operacions: proposta de formació pel personal d‟Operacions del Parc, com a

usuaris en totes les aplicacions del sistema: Control d‟accés, BackOffice.

» àrea de manteniment: proposta de formació pel personal de Manteniment del Parc i si

s‟escau a tercers (empresa de manteniment, etc.) per a totes les aplicacions i compo-

nents del sistema per poder assistir en la resolució de les incidències més habituals i

especialment al diagnòstic de les mateixes. Aquesta formació és considera vital.

» àrea d’Administració: proposta de formació pel personal d‟Administració del Parc com

a usuaris de l‟aplicació de BackOffice.

» àrea de Ticketing: proposta de formació continuada pel personal de les taquilles del

Parc, per poder fer front a incidències relacionades amb l‟accés al recinte.

» operaris d’accés: proposta de formació pels operaris d‟accés per poder fer front a in-

cidències relacionades amb l‟accés al recinte, així com també a l‟operació manual del

sistema de control d‟accés en situacions excepcionals.

» divisió de Sistemes: proposta de formació tècnica i funcional pel personal tècnic de la

divisió de Sistemes de B:SM en totes les aplicacions i components del Sistema.

» La proposta de formació per al personal propi i/o contractat pel Parc ha d‟incloure

classes pràctiques, que es podran realitzar en les zones d‟accés al Parc.

» El pla de formació ha de permetre garantir que el personal d‟operacions i manteni-

ment sàpiga resoldre de manera autònoma incidències lleus o freqüents amb el Siste-

ma.

» Totes les aplicacions i components del Sistema (Control d‟accés, BackOffice, etc.)

han de disposar d‟un manual d’usuari dirigit al personal tècnic i a tots els usuaris del

sistema.

Cal destacar, que el pla de formació de l‟Adjudicatari ha d‟incloure la proposta de formació

continuada pel possible personal itinerant que pot intervenir en el l‟operació de validació

d‟entrades del Zoo i especialment per al personal de manteniment i operacions.

PLANS D‟EXECUCIÓ: Pla de manteniment 48

B:SM

PLA DE MANTENIMENT

Durant tot el període del contracte, el Sistema de control d‟accés ha d‟estar recolzat per

un ampli pla de manteniment preventiu i correctiu que garanteixi el correcte funcionament i

evolució de les aplicacions i components subministrats.

En aquest context, l‟Adjudicatari haurà de realitzar un servei de manteniment HW/SW que

realitzarà tasques de 1er, 2on i 3er nivell en la resolució d‟incidències que es pugin produir

en tots els components del Sistema de control d‟accés: aplicació de control d‟accés, ma-

quinari i perifèrics control d‟accés, comunicacions, etc.

No obstant, l‟Adjudicatari haurà de formar el personal de manteniment del Parc, a fi i efec-

te que aquest personal pugui col·laborar en la resolució de les incidències més habituals.

Manteniment correctiu i suport a l’operació

El pla de manteniment correctiu i suport a l’operació del Sistema ha de permetre resoldre

les possibles incidències o mal funcionament de qualsevol de les seus components, apli-

cacions o interfícies de comunicació durant tot el seu cicle de vida.

L‟Adjudicatari ha de proposar i dur a terme un pla de manteniment correctiu i suport a

l’operació destinat a la resolució d‟incidències tècniques en qualsevol dels components sub-

ministrats del Sistema de control d‟accés al Parc, d‟acord amb les següents condicions:

» organització: el Licitador ha de presentar una breu proposta organitzativa amb l‟equip

de treball, els recursos i l‟assignació de tasques, per donar suport tècnic i operatiu en

tots els àmbits del Sistema: configuració, control d‟accés, incidències, errors, etc.

» L‟Adjudicatari ha de garantir que l‟equip de treball del pla de suport a l‟operació tingui

la formació i l‟experiència necessària per les tasques assignades, garantint en qualse-

vol cas una experiència amb el Sistema superior als 3 mesos fent tasques similars.

» L‟Adjudicatari ha de disposar dels mitjans i dels procediments necessaris (inventaris,

manuals, fitxes tècniques, drivers, CD, ...) per assegurar la qualitat del servei de man-

teniment correctiu a nivell de maquinari, programari i comunicacions.

» avís d’avaria: l‟Adjudicatari ha de donar un número de telèfon amb servei durant

l‟horari d’oficines i l’horari d’operació del Parc per poder notificar incidències o avaries.

» El pla de suport ha d‟incloure la metodologia per gestionar tot el cicle de vida de les

incidències: detecció, notificació, diagnòstic, classificació, resolució, acceptació, etc.

» El Licitador ha d‟emprar el SW gestió de manteniment (GMAO) que determini B:SM,

on ha de quedar enregistrada qualsevol incidència comunicada i resolta.

» El Licitador presentarà un informe trimestral amb el resum de la prestació de mante-

niment, on apareguin el nombre d‟avaries obertes i tancades i els temps mitjos de re-

solució d‟incidències.

» Els costos d‟execució del pla de manteniment correctiu i suport a l‟operació aniran a

càrrec de l‟Adjudicatari al cost establert, incloent materials (únicament durant el perío-

de de garantia), ma d‟obra, desplaçaments i qualsevol altra despesa o maquinària per

poder realitzar el manteniment del Sistema.

L‟horari d‟operació del Parc inclou tots els dies de l‟any, incloent els caps de setmana

(veure-ho a : http://www.zoobarcelona.cat/ca/vine-al-zoo/calendari-i-horaris/).

http://www.zoobarcelona.cat/ca/vine-al-zoo/calendari-i-horaris/


B:SM

Nivell de servei de resolució d’incidències

El nivell de servei exigible per a la prestació dels serveis de suport a l‟operació ve deter-

minat pel tipus d’incidència i la seva gravetat segons la següent classificació:

incidència crítica: qualsevol incidència que inhabiliti completa o parcialment el correcte fun-

cionament del procediment de control d‟accés al recinte. S‟hi inclou qualsevol incidència que

deixi el control d‟accés completament fora de servei i qualsevol incidència que no tingui una

funcionalitat o solució alternativa per poder seguir realitzant el control d‟accés i validació

d‟entrades.

incidència greu: qualsevol incidència que inhabiliti completament funcions clau del sistema,

però que tenen alguna alternativa fins a poder resoldre la incidència, com per exemple el mo-

de off-line per solucionar incidències que no permetin validar entrades o carnets “on line”.

incidència lleu: qualsevol altra incidència que afecti lleument o parcialment les funcions dis-

ponibles en les aplicacions de control d‟accés o BackOffice del Sistema.

L‟Adjudicatari ha d‟oferir un únic telèfon de notificació d’incidències o un mitjà electrònic

de dilluns a diumenge de 9h a 21h per tal de poder notificar oficialment l‟obertura de les

incidències.

L‟Adjudicatari ha d‟oferir un telèfon d’assistència tècnica de dilluns a divendres de 9h a

19h per tal de poder donar suport remot en incidències tècniques i resolució de dubtes.

L‟Adjudicatari és responsable de diagnosticar i fer el seguiment de totes les incidències

relatives al programari i maquinari del sistema de control d‟accés al Parc.

Les tasques de manteniment i suport presencial a l‟operació s‟han d‟adaptar a l‟horari de

resolució d‟incidències del sistema de control d‟accés.

L‟Adjudicatari ha de poder complir amb els següents temps de resolució d’incidències, a

comptar des de la notificació de la incidència fins a la seva resolució:

Dilluns a divendres

(9h a 19h)

Caps de setmana i festius

incidència crítica Màxim 4 hores Màxim 24 hores

incidència greu Màxim 8 hores Màxim 24 hores

incidència lleu Màxim 72 hores Sense servei

Aclarir que la resolució d‟incidència s‟ha de realitzar en l‟horari del Parc i per tant que in-

clou caps de setmana i festius (http://www.zoobarcelona.cat/ca/vine-al-zoo/calendari-i-horaris/).

En la present licitació s‟inclourà una bossa d’hores de manteniment per poder pagar les

hores d‟assistència tècnica dels operaris de l‟Adjudicatari en la resolució d‟incidències en

horari de cap de setmana i festiu, ja que el pagament de la resolució d‟incidències en ho-

rari laborable (de dilluns a divendres) s‟inclou en la quota de manteniment anual del siste-

ma.

El preu hora del manteniment en cap de setmana es comptabilitzarà a partir de l‟inici de

les tasques d‟assistència presencial al Parc i inclourà totes les despeses de transport i

http://www.zoobarcelona.cat/ca/vine-al-zoo/calendari-i-horaris/


B:SM

desplaçament.

El Licitador haurà de fer servir per al registre, seguiment i tancament de les incidències

l‟eina de gestió de manteniment que B:SM determini (previsiblement footprint).

L‟Adjudicatari presentarà un informe trimestral amb el resum de la prestació de suport a

l‟operació, on apareguin el nombre d‟avaries obertes i tancades i els temps mitjos de reso-

lució d‟incidències.

Els costos d‟execució del pla de manteniment correctiu i suport a l‟operació aniran a càr-

rec de l‟Adjudicatari, incloent materials (únicament si estan en garantia), ma d‟obra, des-

plaçaments i qualsevol altra despesa o maquinària per poder realitzar el manteniment del

Sistema de control d‟accés al Parc.

La resolució d‟una incidència haurà de ser acceptada pel corresponent responsable dins

de l‟estructura organitzativa del Parc. Qualsevol incompliment del pla de suport tècnic o

del temps de resolució d‟incidències pot donar peu a les penalitzacions establertes en el

contracte entre el Parc i l‟Adjudicatari.

Manteniment preventiu i evolutiu

Durant tot el període del contracte, el Sistema de control d‟accés també ha d‟estar recol-

zat per un pla de manteniment preventiu i evolutiu que garanteixi el correcte funcionament

i evolució de les aplicacions llicenciades i dels equipaments subministrats.

El manteniment preventiu i evolutiu del programari inclou les següents tasques:

L‟Adjudicatari ha d‟informar a B:SM de modificacions o adaptacions progressives relaciona-

des amb l‟evolució del seu propi programari i conjuntament amb B:SM es decidirà si aquestes

s‟han d‟instal·lar al Sistema de control d‟accés al Parc.

» Les tasques de manteniment preventiu s‟hauran de fer dins l‟horari feiner del perso-

nal d‟instal·lacions de la divisió de Sistemes i/o de la unitat d‟Operacions del Parc.

» L‟Adjudicatari ha de preveure un mínim d’una revisió semestral per realitzar tasques

de manteniment preventiu del Sistema (hardware i software).

» En qualsevol cas, el pla de manteniment preventiu proposat ha de permetre minimit-

zar la resolució d‟incidències tècniques per la via correctiva.

L‟Adjudicatari ha d„informar a B:SM de noves versions de les aplicacions llicenciades i con-

juntament amb B:SM es decidirà si aquestes s‟han d‟instal·lar al Sistema.

L‟Adjudicatari ha d‟instal·lar possibles actualitzacions i pedaços de seguretat (patch) en el

programari de base (Sistema operatiu, etc.) i programari propi del control d‟accés.

L‟Adjudicatari ha d‟informar a B:SM de possibles actualitzacions o pedaços de seguretat

(patch) en el programari de base (Sistema operatiu, gestor de BBDD, etc.) dels servidors.

Observar que a nivell software, aquestes condicions de manteniment evolutiu no impli-

quen haver de canviar o modificar les aplicacions ja acceptades amb requeriments addici-

onals a no ser que aquests estiguin implícits en la pròpia evolució del producte. No obs-

tant, B:SM valorarà positivament l‟actualització preventiva de les aplicacions susceptibles

a ser considerades un producte en comptes d‟un desenvolupament a mida, com és el cas

del BackOffice.


B:SM

Període de garantia

El període de garantia s‟iniciarà a partir de la data de signatura de l‟acta de recepció del

Sistema i que inclou totes les aplicacions i components de l‟àmbit de subministrament. El

període de garantia de les aplicacions i equipaments subministrats és de 24 mesos.

Observar que no és sol·licita un kit de recanvi de peces (unitat de control, perifèrics, etc.) en

concepte de reposició. No obstant, durant el període de garantia l‟Adjudicatari haurà de

poder reparar i si s‟escau canviar els components de maquinari en els terminis establerts

en cas d‟avaria.

Durant tot el període de contractació, les tasques de manteniment correctiu i preventiu de

les aplicacions i components subministrats aniran a càrrec de l‟Adjudicatari al preu esta-

blert en concepte de “manteniment anual”.

Instal·lació i configuració dels components

L‟Adjudicatari és responsable d‟instal·lar, configurar i provar tots els torns i tos els compo-

nents hardware, software i de comunicacions del sistema de control d‟accés al Zoo: perifè-

rics, actualitzacions SO, divers, programari específic, etc.

L‟Adjudicatari és responsable d‟instal·lar, integrar, configurar i posar en funcionament tots

els components de maquinari (lector, pantalla, etc.) del torn, incloent qualsevol element

que requereixi la mecanització del propi moble.

L‟Adjudicatari és responsable d‟instal·lar íntegrament tots els torns del sistema de control

d‟accés del Zoo.

L‟Adjudicatari és responsable d‟instal·lar íntegrament totes les pilones d‟emergència, in-

cloent la realització i mecanització dels forats per encabir aquestes.

Observar que el transport i trasllat de tots els components, incloent els torns fins a la seva

ubicació definitiva va a càrrec del l‟Adjudicatari.

L‟Adjudicatari pot comptar amb la disponibilitat de cablatge de xarxa propers a la ubicació

dels diferents torns i amb les corresponents canalitzacions.

L‟Adjudicatari pot comptar amb l‟eliminació dels actuals torns de la zona d‟accés.

Tots els components del sistema de control d‟accés del Zoo han de tenir el marcatge CE.

Sempre i quan sigui possible, la instal·lació i configuració es pot fer remotament i compta-

rà amb personal del Parc o del Mantenidor per fer verificacions bàsiques.

PLANS D‟EXECUCIÓ: Pla de proves 52

B:SM

PLA DE PROVES

Durant la fase d‟implantació l‟Adjudicatari haurà d‟executar un complert pla de proves que

inclouen el disseny, el desenvolupament, suport, gestió i seguiment de les preves unitàri-

es, d‟integració de rendiment, qualitat de codi, usabilitat, accessibilitat, funcionals

d‟acceptació d‟usuari i la seva documentació.

El pla de proves ha de contemplar proves exhaustives a nivell mecànic i funcional de tots

els components de tots els torns instal·lats en les zones d‟accés al Zoo.

Aquestes proves estaran encaminades a assegurar el correcte funcionament del sistema

en la seva totalitat, tant de les diferents configuracions parcials com dels desenvolupa-

ments, integració amb altres sistemes, validació de múltiples continguts i formats de codis

de barra, situacions d‟emergència, etc.

Durant la fase de definició s‟haurà d‟elaborar un Pla de proves i durant la fase de desen-

volupament s‟han de definir els casos de prova, executar i informar dels resultats.

Com a resultat de l‟execució de les proves, es realitzarà un informe del resultat de

l‟execució de les mateixes, i es presentarà a l‟equip de B:SM per a la seva consideració i

validació en cas que ho consideri necessari.

És responsabilitat de l‟Adjudicatari la generació del joc de dades de proves per tal de rea-

litzar proves en entorns d‟integració i pre-productius. En cas que s‟haguessin de realitzar

proves amb dades de producció, aquestes haurien de ser tractades mitjançant el proce-

diments establert per B:SM.

L‟Adjudicatari ha d‟utilitzar les eines que B:SM designi a cada moment per al registre de

plans de proves, casos detallats, resultats de les proves i gestió de defectes.

PLANS D‟EXECUCIÓ: Pla de contingència 53

B:SM

PLA DE CONTINGÈNCIA

En general, el Sistema de control d‟accés al Parc ha de dimensionar correctament els

seus components (torns, hardware, software) i les seves interfícies de comunicació per

donar servei a l‟operació en un entorn molt exigent.

Es preveu que la plataforma i els components de la xarxa de comunicacions resideixin en

el CPD del recinte, sota el paraigües d‟un pla de contingència o continuïtat del negoci:

El Sistema de control d‟accés ha de preveure la continuïtat del servei en cas d‟incidències

tècniques: sense connectivitat de xarxa (mode off-line), sense servidor (mode off-line), sense

SGS (possible mode off-line per socis), etc.

» El Sistema de control d‟accés ha de preveure la continuïtat del servei en cas

d‟incidències amb el servidor del propi Sistema: caiguda de servidors, connectivitat

xarxa, etc.

» El Sistema de control d‟accés ha de preveure la continuïtat del servei en cas

d‟incidència amb la xarxa de comunicacions: connectivitat LAN, connectivitat xarxa de

transport, etc.

El Sistema ha de sincronitzar totes les validacions i accessos realitzats en mode degradat

(off line) un cop restaurada la incidència amb la xarxa de comunicacions o el servidor.

El Sistema control d‟accés ha de preveure la continuïtat del servei en cas d‟incidència amb

el Sistema de Gestió de Socis (SGS), sistema de venda d’entrades a taquilla / web i ha de co-

mençar a operar en mode off-line, tal i com es descriu en el capítol de requeriments.

En general, el Sistema s‟ha d‟executar en una plataforma sotmesa a un pla de contingència

per garantir la disponibilitat del servei en pics de demanda o incidències tècniques: caiguda

de servidors, pèrdua de comunicacions, subministraments, etc.

El licitador haurà de presentar en la seva oferta les principals característiques del seu pla

de contingència o de continuïtat del negoci: límits d‟operació, proposta de redundància de

components (HW, SW, xarxa comunicacions), pla d‟emergència, pla de recuperació, etc. És

important assenyalar que aquest pla de contingència ha de contemplar tant les incidències en

equipaments del propi àmbit de subministrament, com incidències en la infraestructura de

comunicacions o de servidors subministrats per BSM.

PLANS D‟EXECUCIÓ: Pla d‟acceptació 54

B:SM

PLA D’ACCEPTACIÓ

En la seva oferta tècnica, el Licitador ha de proposar les línies mestres del pla

d‟acceptació de les aplicacions i serveis inclosos dins l‟àmbit de subministrament. Posteri-

orment durant la fase de disseny, l‟Adjudicatari haurà de desenvolupar el pla d‟acceptació,

que també haurà de ser revisat i aprovat per la Direcció del Projecte de B:SM.

El pla d‟acceptació ha de permetre concretar l‟esquema d‟acceptació, incloent una des-

cripció de les fites de lliurament més significatives i amb els seus procediments de valida-

ció. Entre d‟altres, el pla d‟acceptació hauria d‟incloure els següents aspectes:

Proves derivades del propis procediments de control i assegurament de la qualitat en rela-

ció al desenvolupament de les aplicacions i serveis subministrats.

Protocol de proves per la validació de les integracions amb tercers per a totes les interfícies

de comunicació del Sistema de venda i validació d‟entrades.

» Les proves d‟integració amb tercers poden requerir d‟aplicacions que emulin els proto-

cols i els models de dades consensuats durant la fase de disseny tècnic.

Protocol de les proves d‟acceptació “in situ” (SAT) en el Parc Zoològic de Barcelona.

Proves de verificació relacionades amb la disponibilitat i Nivell de Servei del Sistema.

En general, es valorarà positivament l‟aplicació d‟estàndards o de manuals de bones pràc-

tiques en relació als procediments de validació i d‟acceptació en serveis i sistemes TIC.

Com a criteri general, l‟acceptació d‟una aplicació requerirà l‟inici d‟operacions, el lliura-

ment de tota la documentació exigible i la realització per part de l‟Adjudicatari de les pro-

ves i validacions descrites en el seu propi pla d‟acceptació.

inici d’operacions: instal·lació i posada en funcionament en l‟entorn real d‟operació de tots

els components i serveis del Sistema a acceptar, segons els requeriments del plec tècnic.

verificació: l‟Adjudicatari haurà d‟executar les proves i validacions (check list, SAT...) indi-

cades en el seu propi pla d‟acceptació per verificar, documentar i opcionalment certificar el

correcte funcionament del Sistema o servei a acceptar.

documentació: lliurament de tota la documentació tècnica i administrativa relacionada amb

el sistema a acceptar, segons els requeriments del plec de condicions.

En general, no s‟efectuarà cap acceptació sense la documentació que certifiqui la correcta

instal·lació, configuració i posada en funcionament del Sistema complert.

L‟acceptació del Sistema està totalment condicionada al correcte funcionament dels ser-

veis centrals i de totes les aplicacions, equipaments i interfícies de comunicació del Sis-

tema.


B:SM

Documentació tècnica

En general, tots els documents del projecte hauran de ser acceptats formalment per

B:SM, fet que no eximirà a l‟Adjudicatari de la plena responsabilitat respecte al contingut.

La divisió de Sistemes i del Zoo requereix que l‟Adjudicatari inclogui els següents contin-

guts en la documentació tècnica de totes les aplicacions del Sistema:

Arquitectura física i lògica de l‟aplicació.

Components necessaris per al desenvolupament: mòduls, API, llibreries, controls, etc.

Arquitectura i configuració del servei de BBDD. Interfícies de dades amb tercers.

Especificació tècnica detallada de la configuració de la Base de Dades en els entorns de

Pre-Producció i Producció.

Especificació tècnica detallada per la divisió de Sistemes de BSM de les interfícies de co-

municació amb sistemes corporatius i tercers.

» Contingut i formats dels codis de barra acceptats en el procés de validació.

» Model de dades, procediments de bases de dades i interfícies de comunicació

(REST/JSON o equivalent) dels serveis centrals del sistema amb tercers.

Manual d‟usuari de totes les aplicacions .

» Inclou manual destinat a la formació continuada dels operadors de taquilles.

» Inclou manual de l‟aplicació de BackOffice destinat a l‟administració, consulta i ex-

plotació de dades del propi Sistema per personal administratiu i comercial del Parc.

Manual d‟instal·lació i de configuració destinat a personal tècnic i de Sistemes.

Especificació tècnica detallada per la divisió de Sistemes de BSM de les interfícies de co-

municació amb tercers: socis, venda per taquilles, venda per web, etc.

» Model de dades, procediments de bases de dades i/o interfícies de comunicació

(REST/JSON o equivalent) dels serveis centrals del sistema.

Guies ràpides d‟operació: inici i aturada del Sistema, consulta d‟estat, registre, etc.

Guies ràpides d‟administració/manteniment i resolució de incidències.

Si cal, indicar els processos i directoris que han de ser exclosos de l‟anàlisi del antivirus.

Procediment de recuperació de desastres indicant de quins elements cal fer còpia de segu-

retat (backup) i quines accions s‟ hauran de fer en cas de caiguda total o parcial del Sistema

per la seva posterior recuperació i restauració.

La documentació tècnica del projecte s‟ha de lliurar en la fase d‟implantació, previ a l‟inici

d‟operacions del sistema i servirà per complementar la formació a tot el personal del Parc i

a la divisió de Sistemes de B:SM.

L‟Adjudicatari es compromet a lliurar el model de dades d‟aquelles entitats de dades, tau-

les o vistes que B:SM requereixi per poder obtenir informació del sistema per altres usos,

com per exemple per al sistema corporatiu de Business Intelligence (BI), entre d‟altres.

És important destacar que l‟acceptació del projecte per part de B:SM també està condici-

onada al lliurament de tota la documentació tècnica del sistema.


B:SM

Propietat intel·lectual

La propietat intel·lectual dels treballs realitzats a l‟inici del contracte pertany de forma ex-

clusiva a l‟Adjudicatari. Per tant l‟Adjudicatari és el propietari dels codi font dels programes

a l‟inici del contracte, no obstant, s‟obliga a fer una cessió dels drets d‟explotació en ex-

clusiva, sense cost addicional i per temps indefinit a favor de BSM.

La propietat intel·lectual dels treballs de desenvolupament i evolutius realitzats durant el

contracte i encarregats exclusivament i específicament per B:SM pertany a B:SM, excepte

aquells drets d‟autors que es poguessin reconèixer, en el seu cas i, en aquest supòsit,

l‟adjudicatari s‟obliga a fer una cessió dels drets d‟explotació en exclusiva, sense cost ad-

dicional i per temps indefinit a favor de BSM.

B:SM disposarà del dret de transformació o modificació del programari subministrats i

desenvolupats a l‟empara del present contracte.

Llicenciament del programari

L‟Adjudicatari atorga els drets de llicenciament del programari subministrat amb caràcter

indefinit a B:SM, sense cost addicional al del contracte.

L‟ús de components de tercers en les aplicacions incloses dins l‟àmbit de subministrament

hauran de ser prèviament autoritzats per B:SM i si requereixen llicència aquesta anirà a

nom de B:SM i el cost anirà a càrrec de l‟Adjudicatari.

Les llicències dels programes de base dels serveis centrals del Sistema van a càrrec de

B:SM: llicència del sistema operatiu, llicència de servidors d‟aplicació, llicència de gestor

de base de dades, etcètera.

Aquest llicenciament comporta per a B:SM els drets d‟ús, modificació i transformació del

programari subministrat i adaptat.

Actualitzacions del programari

L‟adjudicatari te l‟obligació de realitzar les actualitzacions o upgrades periòdiques del pro-

gramari subministrat en concepte de manteniment preventiu o evolutiu del programari.

Durant el període de contractació, l‟Adjudicatari haurà d‟incorporar els evolutius de pro-

gramari relacionats amb el seu producte prèvia acceptació per part de B:SM. Observar

doncs que els evolutius del programari (noves versions) estan inclosos en el preu del

subministrament del sistema de venda i validació d‟entrades per a tota la durada del con-

tracte en concepte de manteniment del programari.

Codi font de les aplicacions

L‟Adjudicatari facilitarà els codis font de les adaptacions, modificacions o mòduls especí-

fics sol·licitats i realitzats exclusivament per B:SM.

Amb l‟objecte de garantir la continuïtat del programari subministrat per l‟Adjudicatari,

aquest haurà de facilitar els codis font en cas que l‟Adjudicatari discontinuï o traspassi a

una altra empresa les aplicacions objectes de la present licitació.

Sistema de venda d'entrades al Zoo de Barcelona · nents unitats de control i perifèrics (lectors,...

Documents

Transcript of Sistema de venda d'entrades al Zoo de Barcelona · nents unitats de control i perifèrics (lectors,...