Sistema de venda d'entrades al Zoo de Barcelona · nents unitats de control i perifèrics (lectors,...
Transcript of 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
plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 3
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
plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 4
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.
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ó.
plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 6
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.
plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 9
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-
REQUERIMENTS funcionals: Validar l‟accés al recinte 12
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ó.
REQUERIMENTS funcionals: Validar l‟accés al recinte 13
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.
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, 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.
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, 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.
REQUERIMENTS funcionals: Validar l‟accés al recinte 14
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.
REQUERIMENTS funcionals: Validar l‟accés al recinte 15
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.
plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 22
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.
REQUERIMENTS tècnics: Mòdul de control d‟accés 25
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ó.
REQUERIMENTS tècnics: Mòdul de control d‟accés 26
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
REQUERIMENTS tècnics: Mòdul de control d‟accés 27
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”).
REQUERIMENTS tècnics: Mòdul de control d‟accés 28
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.
REQUERIMENTS tècnics: Mòdul de control d‟accés 29
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.
REQUERIMENTS tècnics: Mòdul de control d‟accés 30
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.
REQUERIMENTS tècnics: Serveis centrals 34
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).
REQUERIMENTS tècnics: Serveis centrals 35
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.
REQUERIMENTS tècnics: Serveis centrals 36
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.
REQUERIMENTS tècnics: Integració amb sistemes i serveis 38
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ó).
REQUERIMENTS tècnics: Integració amb sistemes i serveis 39
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.
plec de condicions tècniques: sistema de control d‟accés del parc zoològic de Barcelona 40
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.
PLANS D‟EXECUCIÓ: Pla d‟implantació 42
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.
PLANS D‟EXECUCIÓ: Pla d‟implantació 43
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.
PLANS D‟EXECUCIÓ: Pla d‟implantació 44
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.
PLANS D‟EXECUCIÓ: Pla d‟implantació 45
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.
PLANS D‟EXECUCIÓ: Pla d‟implantació 46
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/).
PLANS D‟EXECUCIÓ: Pla de manteniment 49
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
PLANS D‟EXECUCIÓ: Pla de manteniment 50
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.
PLANS D‟EXECUCIÓ: Pla de manteniment 51
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.
PLANS D‟EXECUCIÓ: Pla d‟acceptació 55
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.
PLANS D‟EXECUCIÓ: Pla d‟acceptació 56
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ó.