Institut Municipal d Informàtica Direcció d Operacions i Sistemes

(1)

Institut Municipal d’Informàtica Direcció d’Operacions i Sistemes

Plec de prescripcions tècniques que regeix el contracte

de Serveis per a la migració de la plataforma CI/CD

(Continuous Integration/ Continuous Deployment) a

OpenShift de l'Ajuntament de Barcelona amb mesures

de contractació pública sostenible

(2)

1 INTRODUCCIÓ ... 5 2 OBJECTE ... 6 3 ABAST ... 7 3.1 ACTIVITATS ... 7 3.1.1 Llançament de projecte ... 9 3.1.2 Presa de requeriments... 10 3.1.3 Desenvolupament ... 11 3.1.4 Testing ... 11 3.1.5 Migració de dades ... 13 3.1.6 Data Quality ... 14 3.1.7 Desplegament i implantació ... 14 3.1.8 Estabilització ... 14

3.1.9 Control i seguiment del projecte ... 15

3.1.10 Gestió de riscos ... 15

3.1.11 Gestió del canvi ... 16

3.1.12 Gestió de la qualitat ... 16 3.1.13 Gestió de desplegaments ... 16 3.1.14 Suport ... 16 3.1.15 Elaboració de manuals ... 17 3.1.16 Tancament de projecte ... 17 3.2 LLIURABLES ... 18

4 AVALUACIÓ I SEGUIMENT DE L’EXECUCIÓ DEL CONTRACTE ... 20

4.1 COMITÈS DE DIRECCIÓ I DE SEGUIMENT ... 20

5 REQUISITS ... 21

5.1 REQUISITS FUNCIONALS ... 21

5.1.1 RF1 Migració de la plataforma a OpenShift ... 21

5.1.2 RF2 Desplegament de Anchore en DevOps ... 22

5.1.3 RF3 Deploy a OpenShift ... 23

5.1.4 RF4 Desenvolupament de les aplicacions de prova Java ... 23

5.1.5 RF5 Construcció i desplegament ... 24

(3)

5.2 REQUISITS TÈCNICS ... 24

5.2.1 Arquitectura i infraestructura ... 24

5.2.2 Control de Versions... Error! No s'ha definit el marcador. 5.2.3 Tests de codi ... Error! No s'ha definit el marcador. 6 ENTORN TECNOLÒGIC ... 24

6.1 PLATAFORMA ACTUAL: ... 26

6.1.1 Jenkins ... 26

6.1.2 ICP ... 27

6.2 PLATAFORMA DE DESTÍ ... 27

6.2.1 Split del cluster actual. ... 27

6.2.2 Nova plataforma de Kubernetes, OpenShift. ... 27

7 ACORDS DE NIVELL DE SERVEI (ANS) ... 28

8 CONDICIONS GENERALS DE PRESTACIÓ DEL SERVEI ... 30

8.1 HORARI I UBICACIÓ ... 30

8.2 EQUIP DE TREBALL ... 30

8.3 IDIOMA ... 31

8.4 EINES DE SUPORT AL SERVEI ... 31

9 DURADA DEL CONTRACTE ... 32

10 PROPOSTA... 33

11 CONDICIONS GENERALS D’EXECUCIÓ ... 36

12 ANNEX: INFORMACIÓ ADDICIONAL I/O ACLARIMENTS... 37

13 ANNEX: METODOLOGIA ADINET ... 38

13.1 METODOLOGIA PER A PROJECTES INET CLAUS EN MÀ... 38

13.1.1 Fase de llançament ... 38

13.1.2 Fase d’elaboració ... 39

13.1.3 Fase de construcció ... 40

13.1.4 Fase de transició ... 41

14 ANNEX: REQUISITS D’ARQUITECTURA I INFRASTRUCTURA ... 43

14.1 RA1.[OBLIGATORI]ARQUITECTURA DE CAPES ... 43

(4)

14.3 RA3.[OBLIGATORI]PREPARADA PER A SER DESPLEGADA EN CONTENIDORS DOCKERS ... 43

14.4 RA4.[OBLIGATORI]REQUISITS DE MODULARITAT I ESCALABILITAT ... 44

14.5 RA5.[OBLIGATORI]ARQUITECTURA DEL SISTEMA ... 45

14.6 RA6.[OBLIGATORI]ESTRUCTURA MULTI-IDIOMA ... 46

14.7 RA7.[OBLIGATORI]TRAÇABILITAT ... 47

14.8 RA8.[OBLIGATORI]COMPONENTS DE SOFTWARE LLIURE ... 47

14.9 RA9.[OBLIGATORI]ENTORNS PER APLICACIONS ... 47

14.10 ESTÀNDARDS DE DESENVOLUPAMENT ... 47

(5)

1 Introducció

L’institut Municipal d’Informàtica (en endavant IMI) és l’organisme autònom de l’Ajuntament de Barcelona responsable de subministrar tots els serveis de les tecnologies de la informació i comunicació (TIC) a l’Ajuntament de Barcelona i els seus organismes autònoms.

Concretament, l’IMI participa en el disseny i execució de l’estratègia TIC de l’Ajuntament de Barcelona, ofereix assessorament i suport en tots aquells projectes o programes de l’Ajuntament que requereix una estratègia de sistemes d’informació i telecomunicacions i impulsa i executa projectes tecnològics de diversa índole.

L’IMI decideix impulsar l’any 2018 un Acord Marc que dona cobertura a la contractació de projectes vinculats al disseny i construcció d’aplicacions, així com als seus serveis associats. Eren objecte d’aquest Acord Marc els treballs de desenvolupament i evolució d’aplicacions, així com altres serveis relacionats que siguin impulsats tant per part de l’IMI com d’altres organismes de l’Ajuntament de Barcelona adscrits a l’Acord Marc.

A efectes d’homologació, l’Acord Marc es dividia en tres agrupacions de Lots i en 8 Lots i sublots diferents.

1. Agrupació de Lots de Consultoria

- Lot 1: Consultoria Estratègica i de Processos TIC (Consultoria estratègica, d’organització i processos, i d’avantprojectes)

- Lot 2: Consultoria Tecnològica 2. Agrupació de Lots de Construcció

- Lot 3: J2EE - Lot 4: SAP

- Lot 5: Data Analytics

- Lot 6 PYTHON, que es divideix en dos sublots: o Sublot 1 (Sistemes d’informació)

o Sublot 2 (Aplicacions) 3. Agrupació de Lot de Gestió

- Lot 7: Oficina Tècnica

El present contracte, degut a la seva naturalesa i objecte de contractació, deriva del Lot de construcció J2EE, que té com a objectiu desenvolupar noves aplicacions, evolucionar aplicacions ja existents, realitzar migracions tecnològiques i/o implantar productes ja existents.

(6)

2 Objecte

La present licitació té per objecte la contractació de la realització del projecte de Migració de l’actual plataforma CI/CD (Continuous Integration/ Continuous Deployment) a OpenShift. L'Institut Municipal d'Informàtica de l'Ajuntament de Barcelona disposa actualment d'un sistema d'Integració contínua (CI) I entrega continua (CD) desenvolupat a mida amb diferents productes open source. Aquest sistema resideix sobre una instància de kubernetes de l'empresa IBM anomenada IBM Cloud Private (en endavant, ICP).

A conseqüència de la compra de l'empresa RedHat per part de la mateixa IBM, IBM va decidir deixar l'ICP sense continuïtat i adopta OpenShift (de RedHat) com a la plataforma cloud per a tots els seus clients. Aquest any 2021 serà l'últim any de manteniment de l'ICP I els clients haurem de migrar a OpenShift per continuar gaudint del suport i manteniment de l'empresa imprescindible per poder tenir la plataforma productiva.

Per continuar donant servei, com fins ara, es migrarà la plataforma de DevOps construïda sobre ICP al nou OpenShift. Encara que tant l'ICP com OpenShift són productes basats en kubernetes la migració no pot ser transparent i obliga a fer adaptacions, modificacions i, potser, millores, per tal de continuar funcionant con fins ara. Aquest contracte se centra únicament en la migració de l’entorn de DevOps (CI/CD).

Per últim, com a part d’aquesta migració també s’inclou en el contracte el desenvolupament d’un parell d’aplicacions java sobre la plataforma OpenShift. L’objectiu d’aquesta aplicació serà validar tota la migració en la nova plataforma.

L’objecte de contractació del present plec es contextualitza en l’expedient 18000204 que regeix l’Acord Marc per al desenvolupament de projectes TIC de l’Ajuntament de Barcelona, concretament en el lot 3 de desenvolupament d’aplicacions J2EE.

(7)

3 Abast

3.1 Activitats

Les activitats a executar per part dels adjudicataris del present contracte són les que s’indiquen a continuació:

Activitat Descripció Durada estimada

Llançament del projecte

Conjunt de tasques

comunicatives destinades a informar i implicar als interlocutors clau i grups d’interès els objectius,

planificació, recursos i fites del projecte.

2 setmanes

Presa de requeriments

Tasques per a la identificació de les necessitats i traduir-les a requeriments tècnics i funcionals

1 mes

Disseny i prototipatge

Disseny de la solució tecnològica i prototip que resolgui les

necessitats expressades als requeriments.

2 mes

Desenvolupament

Activitats de desenvolupament d’acord amb el disseny tècnic i funcional definit.

1 mes

Testing

Tests que permetin detectar possibles errors i assegurar que es compleix amb els

requeriments tècnics i funcionals i amb les necessitats dels usuaris de manera contínua

2 setmanes

Data Quality

Assegurar el correcte funcionament del sistema a través del registre dels diferents indicadors del sistema.

6 mesos

(8)

Desplegament i implantació

Assegurar el correcte

funcionament del nou sistema i l’acceptació d’aquest per part dels usuaris.

2 mesos

Estabilització

Garantir que el sistema

d’informació presenta un volum baix d’incidències i que els usuaris han finalitzat el procés d’adaptació.

6 mesos

Control i seguiment del projecte

Coordinar i assegurar la correcta execució del projecte al llarg del seu transcurs.

12 mesos

Gestió de riscos

Identificar i mitigar els riscs que apareguin al llarg del transcurs del projecte.

12 mesos

Gestió del canvi

Realitzar les accions de formació, comunicació i conscienciació a tots els usuaris afectats per el projecte de construcció.

1 mes

Gestió de la qualitat

Realitzar les activitats orientades a la gestió i control de la qualitat dels treballs desenvolupats al llarg del transcurs del projecte.

12 mesos

Gestió de desplegaments

Planificar i coordinar amb els responsables del projecte de construcció els desplegaments als diferents entorns i les pujades a producció.

Per a projectes de codi obert, s’inclourà en aquesta activitat totes les tasques relacionades amb l’obertura de codi.

6 mesos

(9)

Suport

Recepció i resolució

d’incidències dels diferents usuaris del sistema d’informació.

6 mesos

Elaboració de manuals Generar els manuals d’usuari i

d’aplicació. 1 mes

Tancament de projecte

Traspassar el coneixement del projecte als responsables que l’IMI designi.

1 setmanes

El projecte pot realitzar-se amb metodologies Àgils en funció de la necessitat de l’Ajuntament; en qualsevol cas, l’ús d’una metodologia o altra no modifica les activitats objecte del lot.

Es detallen a continuació cada una de les activitats indicades anteriorment:

3.1.1 Llançament de projecte

L’activitat de llançament del projecte té com a objectiu comunicar als interlocutors clau del contracte els elements més rellevants del projecte (objectius, planificació, recursos, model de govern, riscos etc). Les tasques a realitzar per part de l’adjudicatari inclouran:

• Realització de la reunió de Kick-Off per a compartir: objectius, planificació amb fites clau, organització i model de relació.

• Definició conjunta, amb la direcció del projecte, de l’abast detallat dels treballs, així com els resultats esperats per totes les parts implicades.

• Definició conjunta, amb la direcció del projecte, dels criteris de qualitat i les toleràncies del projecte: criteris de validació dels productes resultants, els estàndards de qualitat, criteris de gestió de possibles canvis en l’abast o desviacions temporals en l’execució, model de gestió de riscos.

• Coordinació i suport a l’organització i execució de la reunió de llançament del projecte, que ha de permetre compartir amb tots els agents implicats: el context i els objectius a assolir, l’abast i la planificació dels treballs i les seves fites clau, el plantejament metodològic i les eines que s’empraran per a les tasques de gestió i execució del projecte, així com el model organitzatiu i de relació del projecte.

• L’adjudicatari haurà d’elaborar el document de llançament de projecte que ha de recollir com a mínim tots els punts esmentats anteriorment. Aquest document es presentarà de forma prèvia a la reunió de llançament a l’àrea de l’Ajuntament de Barcelona

(10)

responsable del projecte i els stakeholders que es considerin clau per a l’execució del mateix.

Així mateix, l’adjudicatari serà responsable dotar el contracte amb els recursos necessaris (humans i materials), que permetin el correcte desenvolupament de les tasques que conformen l’abast del servei amb temps i qualitat requerits d’acord amb les condicions d’aquest plec. Si escau, la direcció del projecte, via el departament de comunicació, haurà de fer el comunicat intern adequat per a què tots els actors implicats (d’ara en endavant stakeholders) estiguin al corrent dels nous processos a dissenyar; els stakeholders són font de suggeriments que poden ser de gran valor per al projecte.

3.1.2 Presa de requeriments

La presa de requeriments té com a objectius identificar les necessitats que ha de cobrir el projecte de construcció i traduir-les a requeriments tècnics i funcionals.

Independentment de si es tracta d’un nou desenvolupament, de l’evolució d’una aplicació ja existent, d’una migració tecnològica o de la implantació d’un producte, l’adjudicatari haurà de realitzar l’activitat de presa de requeriments.

Les tasques a realitzar per part de l’adjudicatari són:

 Descripció inicial a alt nivell del sistema d’informació, delimitació de l’abast i generació d’un catàleg de requeriments generals.

 Elaboració del pla de treball en base a la metodologia seleccionada per a l’execució del projecte.

 Realització de sessions de treball amb els usuaris clau i altres tècniques per a obtenir tota aquella informació rellevant que permeti definir les especificacions funcionals i tècniques.

 Descripció detallada de les especificacions tècniques i funcionals de manera que permetin descriure amb precisió el sistema d’informació: funcionalitats, restriccions, freqüència, seguretat, control d’accessos...)

 Definició i generació els models lògics que serviran de base per al disseny posterior (diagrames de flux o qualsevol altra representació que es consideri adequada per al modelat).

 Identificació i anàlisi de totes aquelles integracions amb altres sistemes d’informació necessàries.

Cal tenir en compte que poden sorgir modificacions (tant per augment com per decrement) en els requeriments tècnics i funcionals per diverses causes, com poden ser la falta d’alguna informació específica, l’aparició de noves necessitats no contemplades inicialment, desplegaments a usuaris escalonats, etc.

(11)

Aquests canvis es gestionaran segons els criteris definits en l’activitat de llançament de contracte. L’adjudicatari haurà de portar a terme el control de canvis, analitzant i comunicant als interlocutors l’impacte que poden tenir sobre el transcurs del projecte i haurà de mantenir tota la documentació actualitzada.

3.1.3 Desenvolupament

L’activitat de desenvolupament té com a objectiu traduir el disseny especificat a codi o bé realitzar les parametritzacions corresponents. De les activitats de desenvolupament s’obtenen resultats tangibles que s’aniran testejant a mesura que es desenvolupin i es presentaran a l’Ajuntament de Barcelona sempre que es consideri necessari per a la seva validació, d’acord amb el pla de qualitat i de proves definit.

 Configuració dels components i productes necessaris per al desenvolupament del nou sistema.

 Definició de les infraestructures necessàries

 Desenvolupament de la solució.

Les tasques de desenvolupament poden veure’s modificades per canvis en requeriments tècnics i/o funcionals. L’adjudicatari haurà de valorar l’impacte d’aquests en quant a cost, eficiència i temps, informant a l’Ajuntament de Barcelona i seguint els criteris de tolerància definits en l’activitat de llançament del projecte.

La metodologia utilitzada per al desenvolupament de les aplicacions serà ADINET en funció del tipus de projecte. La metodologia es detalla en l’annex 1.

3.1.4 Testing

L’activitat de testing té com a objectiu la realització de les proves per a detectar possibles errors i assegurar que es compleixen amb els requeriments tècnics i funcionals i amb les necessitats dels usuaris.

L’adjudicatari caldrà que defineixi l’estratègia de proves, que es pot veure modificada al llarg del transcurs del projecte. Estarà obligat a actualitzar el pla de proves cada cop que hi hagi modificacions en algun dels requeriments funcionals i/o tècnics.

Les tasques a realitzar per l’adjudicatari referents a la definició de l’estratègia de proves són:

 Definició i documentació de l'estratègia de proves en funció dels objectius i aspectes crítics o principals definits en el projecte.

 Definició dels aspectes crítics o principals a provar.

 Definició dels objectius de cobertura per cada tipus de prova:

(12)

o Proves unitàries: Caldrà donar cobertura a la totalitat del codi associat a cada classe de cas d'ús crític / principal.

o Proves d’integració i sistema/acceptació: proves del tipus: funcionals, càrrega, proves de qualitat, proves d’usabilitat, proves d’accessibilitat, integració entre sistemes, proves d’acceptació d’usuari.

 Coordinació amb els diferents interlocutors la realització de les proves d’integració amb altres sistemes d’informació.

 Definició dels casos de prova

 Planificació dels casos de prova

 Creació del Pla Mestre de proves

Aquestes proves (unitàries i d’integració i sistema) permetran valorar com treballa el sistema, i caldrà que quedin documentades amb el seu corresponent resultat.

Una vegada definida l’estratègia de proves per part de l’adjudicatari, caldrà definir els casos de test i portar a terme la implementació i test usuari.

L’adjudicatari haurà de:

 Entregar la descripció detallada dels casos de proves amb els passos a realitzar per completar la prova o bé amb la captura automàtica.

 Entregar la definició de l’entorn de proves

 Elaborar els casos de prova funcionals. o Definir les proves

o Relacionar les proves amb els casos d’ús o Planificar les proves

 Descompondre el sistema en parts que permetin el desenvolupament dels tests de forma simultània i reduir així els recursos utilitzats en aquesta disciplina.

 Realització de tests unitaris de les parts i integració de les parts del sistema, que implica: o Planificació de la segmentació

o Acceptació de la segmentació (opcional, segons la complexitat) o Implementació elements dissenyats

o Dissenyar i implementar tests unitaris o Execució dels tests unitaris

o Realitzar integració

o Acceptació de la integració (opcional, segons la complexitat)

Finalitzades les tasques anteriors, l’adjudicatari haurà de portar a terme l’execució del pla de proves a l’entorn de preproducció:

 Realització de les proves de càrrega del sistema que assegurin el rendiment en producció.

 Creació del Pla de Proves de Preproducció.

(13)

 Execució del Pla de Proves de Preproducció

 Avaluació dels resultats

Una vegada es compleixi el nivell de qualitat definit al Pla Mestre de Proves es podran realitzar les proves d’acceptació d’usuari (UAT). Caldrà que l’adjudicatari comuniqui els resultat als responsables de l’IMI per a què es puguin portar a terme les proves d’usuari (UAT).

Referent a les proves d’usuari, les tasques a realitzar per l’adjudicatari són:

 L’execució de les proves amb els usuaris clau que en aquest cas seran de la direcció d’operacions de l’IMI.

 La comprovació i documentació de si es compleixen les especificacions funcionals dels casos d' ús i les no funcionals.

 L’avaluació dels resultats i resolució de defectes identificats.

Les proves es repetiran tantes vegades com s’estimi necessari fins a l’obtenció del resultat objectiu establert.

Addicionalment, el responsable del contracte de l’IMI portarà a terme les seves pròpies proves funcionals, tècniques i d’arquitectura a les quals s’haurà de sotmetre el proveïdor adjudicatari del lot constructor per a validar que el projecte compleix amb els estàndards de qualitat definits.

En cas que l’Ajuntament de Barcelona consideri que no s’ha superat el Pla de proves, ja sigui en la seva totalitat o alguna de les proves definides, l’adjudicatari de la construcció no podrà continuar amb la construcció fins que no es solucionin els errors i se superin les proves fallides. A més, la no superació de les proves implicarà l’aplicació de penalitzacions.

3.1.5 Migració de dades

L’activitat de migració de dades té com a objectiu la transferència de dades d’un sistema a un altre tenint en compte les característiques de les bases de dades origen i destí i mantenint sempre la integritat, exactitud i consistència d’aquestes.

 Definició de l’estratègia de migració de dades, planificació del procés i determinació de l’abast i la viabilitat.

 Realització de totes les proves necessàries que garanteixin que les dades s’han migrat correctament i que no s’hi han produït incoherències.

 Anàlisi dels resultats obtinguts i aplicació de tots aquells ajustos necessaris per a garantir coherència i integritat de les dades en tot moment.

(14)

3.1.6 Data Quality

L’activitat de data quality té com a objectiu assegurar el correcte funcionament del sistema a través de la millora de la qualitat de les dades, obtenint unes dades precises i coherents i augmentant el valor de les dades com un actiu de l’organització.

 Mesurar el grau de qualitat de les dades a través d’un perfilat de les dades (data profiling)

 Qualitat de les dades (data quality)

 Neteja de les dades (data cleansing)

3.1.7 Desplegament i implantació

L’activitat de desplegament té com a objectiu assegurar el correcte funcionament del nou sistema i l’acceptació d’aquest per part dels usuaris.

Independentment de si es tracta d’una nova aplicació, de l’evolució d’una aplicació existent, d’una migració tecnològica o de la implantació d’un producte, sempre caldrà realitzar la fase de desplegament i implantació, la durada de la qual por variar en funció de l’abast de la mida del projecte i del nombre d’usuaris afectats.

 Definició de l’estratègia de desplegament i implantació. En cas que es tracti d’un nou sistema d’informació que substitueixi a un altre anterior, caldrà planificar la transició entre un i altre minimitzant els impactes als usuaris.

 Elaboració del pla de desplegament amb cronograma, fites clau, impacte i usuaris afectats.

 Coordinació amb les àrees d’Explotació i Sistemes de l’IMI per a planificar i executar les activitats de pujada a producció d’acord amb els procediments de traspàs de programari a l’entorn productiu.

 Elaboració del pla de gestió del canvi: formació, comunicació i suport.

3.1.8 Estabilització

L’activitat d’estabilització té com a objectiu garantir que el sistema d’informació presenta un volum baix d’incidències i que els usuaris han finalitzat el procés d’adaptació.

 Recepció i resolució d’incidències, comunicació i tancament d’aquestes.

 Registre a les eines corporatives de l’IMI de consultes, peticions i incidències, amb la corresponent tipologia.

(15)

 Desenvolupament de les accions correctives necessàries per a garantir el correcte funcionament del sistema.

La durada de l’activitat d’estabilització del sistema serà del 50% de la duració total estimada del projecte de construcció (inclòs el desplegament).

3.1.9 Control i seguiment del projecte

L’activitat de control i seguiment del projecte té com a objectiu la coordinació del projecte durant tot el seu transcurs.

• Control, assegurament i garantia de la coherència de la planificació del projecte i activitats des d’una perspectiva global.

• Vigilància del correcte desenvolupament del projecte en abast, temps i forma.

• Detecció, anàlisi i aplicació d’accions de contingència i mitigació de tots els riscos que puguin sorgir al llarg del transcurs del projecte.

• Assessorament i suport a la presa de decisions al llarg del projecte. • Coordinació dels diferents stakeholders implicats en el projecte.

• Assegurament de la qualitat del producte final (acompliment dels requeriments tècnics i funcionals i satisfacció dels usuaris).

• Proporció de suport a l’equip d’Arquitectura de l’IMI en l’activitat de validació de dissenys.

• Establiment dels estàndards de qualitat rellevants per a la correcta execució i gestió del projecte.

• Gestió i supervisió dels desplegaments.

• Informació sobre l’estat i avenç del projecte a l’eina de gestió de projectes corporativa de l’IMI.

3.1.10 Gestió de riscos

L’activitat de gestió de riscos té com a objectiu la identificació i mitigació dels riscs que apareguin al llarg del transcurs del projecte. Les principals tasques a realitzar per part de l’adjudicatari són:

 Definir i posar en marxa indicadors per avaluar desenvolupament projecte

 Identificar riscs de projecte

 Proposar accions mitigadores dels riscs

(16)

3.1.11 Gestió del canvi

L’activitat de gestió del canvi té com a objectiu la realització de les accions de formació, comunicació i conscienciació a tots els usuaris afectats per el projecte de construcció. L’adjudicatari ha de definir i elaborar com a mínim:

 Pla de comunicació als equips desenvolupadors [Només en cas de que el projecte canviï algun aspecte del funcionament actual de la plataforma de CI/CD]

 Pla de formació

o Desenvolupadors [Només en cas que el projecte canviï algun aspecte del funcionament actual de la plataforma de CI/CD]

o Equip d’arquitectura (intern i extern) o Equip d’operacions

 Pla de transferència de coneixement

o AM d’arquitectura (Cal garantir que l’AM receptor del contracte es queda amb els coneixements i detalls necessaris per mantenir i evolucionar el sistema)

3.1.12 Gestió de la qualitat

L’activitat de gestió de la qualitat té com a objectiu la realització de les activitats orientades a la gestió i control de la qualitat dels treballs desenvolupats al llarg del transcurs del projecte. Les principals tasques a realitzar per part de l’adjudicatari són:

 Establir els estàndards de qualitat

 Proposar i desenvolupar millores en els processos interns de l’IMI

3.1.13 Gestió de desplegaments

L’activitat de gestió de desplegaments té com a objectiu la planificació i coordinació dels desplegaments als diferents entorns amb els responsables del projecte de construcció i les pujades a producció. Les principals tasques a realitzar per part de l’adjudicatari són:

 Minimitzar impacte dels desplegaments als usuaris

 Minimitzar els errors de desplegament

 Definir criteris d’entrada i sortida de versions

3.1.14 Suport

L’activitat de suport té com a objectiu la recepció i resolució d’incidències dels diferents usuaris del sistema d’informació. El proveïdor adjudicatari serà responsable d’assegurar la resolució de les incidències, consultes i peticions que puguin sorgir al llarg del desplegament i implantació. Les tasques a realitzar per l’adjudicatari són:

 Registre d’incidències a les eines corporatives de l’Ajuntament de Barcelona.

 Recepció d’incidències per diferents canals, anàlisis, resolució i comunicació a usuaris.

(17)

 Anàlisi global de les incidències rebudes.

 Elaboració dels procediments de suport i atenció a l’usuari dins el marc del projecte.

3.1.15 Elaboració de manuals

L’activitat de documentació té com a objectiu generar els manuals d’usuari i d’aplicació un cop finalitzats els desenvolupaments. Aquests manuals i/o guies d’ús s’hauran de mantenir actualitzades a mesura que es vagin incorporant modificacions en quant a requeriments tècnics i funcionals.

Els manuals d’usuari i d’operació serviran de base per a establir el contingut de les formacions a usuaris finals que posteriorment s’hauran d’executar i per a garantir el coneixement. Per tant, un cop finalitzats i validats aquests materials, en funció de la seva complexitat, l’adjudicatari haurà de generar documentació addicional enfocant el contingut a sessions de formació. Aquest haurà d’incloure:

 Casos pràctics a realitzar per part dels usuaris, recollint les operatives clau.

 La relació de totes les funcionalitats dels sistema i al seva descripció, breu però concisa i completa.

3.1.16 Tancament de projecte

El tancament del projecte té com a objectiu la validació i acceptació per part del comitè de direcció del projecte dels productes resultants dels treballs que conformen l’abast del projecte. El resultat inclourà el lliurament de tota la documentació generada i la transferència del coneixement al personal intern per al seu coneixement.

La documentació haurà d’incloure el llistat d’encerts (per reutilitzar-los en futurs projectes) i errades (per no repetir-les) com a part del know-how. Per fer-ho s’hauran de plantejar les següents preguntes:

 Quins aspectes van funcionar bé per al mateix projecte i per a l'equip del projecte?  El projecte ha assolit els objectius? Per què no? Quins canvis caldria introduir-hi per

revertir la situació?

 Quins aspectes de feblesa identifiquem per al projecte i per al seu equip?  Què més cal fer o què cal fer diferent?

 Quins imprevistos va haver de gestionar l'equip i què podíem haver evitat?  Quines circumstàncies del projecte caldria haver previst?

Aquesta activitat es donarà per finalitzada quan el cap de projecte de l’Ajuntament de Barcelona rebi formalment tots els lliurables que es requereixen i aquest lliurament quedi acreditat.

(18)

3.2 Lliurables

De cadascuna de les activitats descrites anteriorment, s’indiquen en la següent taula, els productes a lliurar per part de l’adjudicatari al finalitzar la corresponent fita. S’especifica també el contingut mínim de la documentació generada i el format en el que caldrà que s’entregui:

Activitat Lliurables Contingut mínim Format

Llançament de projecte

Document de llançament de projecte

Exposició clara d’elements rellevants per a la correcta execució projecte:

- Objectius i abast concret. - Planificació i calendari amb

activitats i fites clau. - Agents i recursos implicats. - Metodologia a utilitzar al llarg del

projecte

- Organització i Model de relació. Riscos potencials. Presentació Disseny tècnic Document de disseny tècnic i arquitectura - Característiques tècniques de l’aplicació

- Integracions amb altres sistemes - Elements necessaris per executar el

projecte (xarxa, màquines, etc)

Informe detallat Presentació

Desenvolupam ent

Codi amb les proves unitàries i d’integració finalitzades

- Proves realitzades

- Resultats obtinguts Informe detallat

Testing Pla de proves

- Estratègia de proves

- Proves d’integració continua - Planificació i calendari de proves

previst - Fites clau - Usuaris

- Joc de dades, configuracions i eines de prova

Informe detallat

Migració de

dades Pla de migració

- Definició de l’estratègia de migració de les dades

- Definició de l’estratègia d’extracció de les dades i tractament

- Proves i validacions de l’execució de la migració

- Anàlisi del resultats obtinguts

- Informe detallat - Fitxers de

suport

(19)

Desplegament i implantació Pla de desplegament - Definició de l’estratègia de desplegament i implantació - Valoració de l’èxit del

desplegament

Informe detallat

Estabilització Informe fase

estabilització

- Resolució de les incidències

- Detall de les accions correctores Informe detallat

Control i seguiment del projecte

Informes de seguiment

Documents de suport a les reunions de seguiment i govern del projecte

- Relació tasques dutes a terme - Resultat i productes (executiva) - Seguiment planificació i calendari,

desviacions i riscos identificats - Proposta accions mitigadores - Properes passes - Informes de seguiment - Acta reunió seguiment - Documents de suport Gestió de

qualitat Pla de qualitat

- Estàndards de qualitat

- Proposta i desenvolupament de millores en els processos interns de l’IMI Informe detallat Gestió de desplegaments Manual de desplegament

- Detall dels passos del procediment de desplegament

- Política de versionat

Manual

Suport

Alta i gestió de les incidències a l’eina de suport

- Registre de les incidències

- Anàlisi de les incidències de forma global

- Procediments de suport i atenció a usuaris Eina de suport Elaboració de manuals Manual d’operació

Detall de processos i procediments necessaris per a la operació de la nova solució Manual Tancament de projecte Document de tancament - Tasques realitzades - Conclusions del projecte

- Mètode de traspàs de coneixement - Lliçons apreses

Presentació

(20)

4 Avaluació i seguiment de l’execució del contracte

En aquest apartat s’indiquen els òrgans dels quals és necessari disposar per a conèixer si s’hi està duent a terme una correcta execució. Són els següents:

4.1 Comitès de Direcció i de Seguiment

La direcció, supervisió, avaluació i aprovació dels resultats parcials i finals dels treballs relacionats amb el contracte li correspon al Comitè de Direcció del Contracte.

L’empresa adjudicatària nomenarà un Director del Contracte que, a banda de tenir la funció de Direcció executiva i efectiva dels treballs, liderant l’equip que es posi a disposició del contracte, s’integrarà en aquest Comitè de Direcció per tal de reportar els avanços en l’elaboració i execució del contracte sempre que es consideri necessari. El comitè de direcció es convocarà d’acord amb el que s’estableixi en el document de llançament del contracte.

Per altra banda, el Comitè de Seguiment correspon al seguiment del dia a dia del contracte, control dels riscos i planificació del treball. Ha de garantir l’execució del contracte en calendari, fites, pressupost i qualitat. Serà el responsable de resoldre les incidències i conflictes que, per la seva importància, no hagi de resoldre el Comitè de Direcció i de decidir quins s’han d’aixecar al Comitè de Direcció.

En la fase de llançament de contracte es definirà quins són els membres del Comitè de Direcció i seguiment del contracte, així com els membres de l’equip del treball, els seus rols i responsabilitats. Els Comitès de Direcció es realitzaran, com a mínim, a l’inici de l’execució de l’estudi previ i abans de finalitzar. Els Comitès de Seguiment es faran, com a mínim, de forma mensual.

(21)

5 Requisits

5.1 Requisits funcionals

5.1.1 RF1 Migració de la plataforma a OpenShift

Un cop finalitzada la migració de tota la plataforma DevOps especificada al punt 6.1 d’aquest document aquesta ha de continuar funcionant com fins ara.

En aquest punt encara no s’hauran fet les adaptacions per desplegar a OpenShift i per tant, la plataforma continuarà desplegant a ICP i WAS com ho feia abans de la migració.

Tots els productes continuaran donant servei a través de la mateixa url que ho feia a ICP per tal que als usuaris no els hi afecti el canvi.

5.1.1.1 RF1.1 Migració de Gitlab

Un cop migrat el gitlab continuarà donant servei com a la plataforma ICP. Mantindrà tota la seva informació intacta així com les seves integracions (AD, orquestrador...).

En el moment de la migració es valorarà si es desplega la mateixa versió que estigui donant servei a ICP o si, durant el projecte es veu convenient actualitzar a una versió més moderna, aquesta serà l’última LTS estable.

5.1.1.2 RF1.2 Migració del Subversion

Un cop migrat el subversion continuarà donant servei com a la plataforma ICP. Mantindrà tota la seva informació intacta així com les seves integracions (Oracle, AD, orquestrador, servidor de correu...).

La versió a migrar serà la que en el moment de la migració estigui donant servei a ICP.

5.1.1.3 RF1.3 Migració del Sonarqube

Un cop migrat el sonarqube continuarà donant servei com a la plataforma ICP. Mantindrà tota la seva informació intacta així com les seves integracions (Oracle, AD, orquestrador, servidor de correu...).

5.1.1.4 RF1.4 Migració de Nexus

Un cop migrat el nexus continuarà donant servei com a la plataforma ICP. Mantindrà tota la

(22)

5.1.1.5 RF1.5 Migració de l’Orquestrador

Un cop migrat l’orquestrador, amb els seus diferents components, continuarà donant servei com a la plataforma ICP. Mantindrà tota la seva informació intacta així com les seves integracions (AD, orquestrador, servidor de correu...).

5.1.1.6 RF1.6 Migració de XWiki

Un cop migrat l'Xwiki, amb els seus diferents components, continuarà donant servei com a la plataforma ICP. Mantindrà tota la seva informació intacta així com les seves integracions (AD, orquestrador, servidor de correu...).

5.1.1.7 RF1.6 Migració de Jenkins

Un cop migrat, Jenkins, amb els seus diferents components, continuarà donant servei com a la plataforma ICP. Mantindrà tota la seva informació intacta així com les seves integracions (AD, orquestrador, servidor de correu...).

5.1.2 RF2 Desplegament de Anchore en DevOps

S’afegirà el producte Anchore a la plataforma i s’integrarà amb les pipelines de Jenkins. Per fer aquesta integració es desenvoluparà una SharedLib de Jenkins que encapsularà totes les seves crides.

Finalment s’afegirà aquesta nova SharedLib als pipelines que ho necessitin per tal que s'analitzin les diferents imatges que es construeixen.

L’execució, o no, d’aquesta anàlisi ha d’estar parametritzada i hem d'assegurar que els usuaris finals puguin tenir accés al resultat.

Durant el projecte caldrà reavaluar si anchore és la millor opció disponible en aquest moment, ja que pot ser que disposem d’altres productes propis d’OpenShift (Quay) que sigui més convenient d’utilitzar. Si arribés el cas, només canviaria el producte, la resta d’activitats vinculades a aquest requeriment es mantindran igual.

(23)

5.1.3 RF3 Deploy a OpenShift

Tota la plataforma DevOps ha de ser capaç de fer el deploy dels diferents instal·lables a la nova plataforma OpenShift tal com ho feia a ICP. Nota: L’orquestrador no consta d’un únic instal·lable sinó que és un conjunt que s’encarreguen d’implementar la seva funcionalitat. Cal migrar-los tots.

Caldrà adaptar les diferents pipelines per adaptar els manifests generats actualment perquè funcionin en OpenShift.

Per exemple: La plataforma actual fa servir ingress i la nova fa servir route.

Es important remarcar que no serà una substitució sinó que es permetrà desplegar tant en ICP com en OpenShift el mateix instal·lable.

5.1.4 RF4 Desenvolupament de les aplicacions de prova Java

Per tal de validar tota la migració, així com les noves capacitats de la plataforma per al desplegament d’aplicacions java, es desenvoluparà una aplicació de proves amb les següents característiques:

 CRUD (Create, read, update and delete) d’una entitat senzilla (per exemple Persona)

 Emmagatzemant en la BD corporativa OracleBackend

 I generació d’un informe (PDF) a partir de les dades de l’entitat cridant al servei de generació de reports comú de l’IMI.

L’aplicació estarà composta per:

 Un front-end (SPA)

 Un back-end (REST)

Per tal de poder comparar, el mateix backend s’implementarà 2 cops:

 1 amb SpringBoot

o Publicació sobre jvm i Native (aquesta funcionalitat esta en beta així que veurem com va)

 1 amb Quarkus

o Publicació sobre jvm i Native.

La intenció és intentar executar les aplicacions sobre la jvm Graalvm (versió estable en el moment d’execució del projecte) i s'executaran de dues maneres possibles:

 Execució normal sobre la jvm

 Execució nativa

(24)

5.1.5 RF5 Construcció i desplegament

I finalment, es validarà que tant les noves aplicacions desenvolupades en aquest plec, com les aplicacions ja fetes es construiran i es desplegaran com a contenidors a OpenShift a través de la plataforma DevOps.

Aquesta validació es farà amb algunes aplicacions facilitades per part de l’equip d’arquitectura de l’IMI.

5.2 Requisits tècnics

5.2.1 Arquitectura i infraestructura

Veure l’annex “Requisits d’Arquitectura i Infraestructura”.

5.2.2 Control de Versions

Tot el que es desenvolupi al projecte, així com aspectes de configuració s’emmagatzemaran al repositori de codi pertinent.

L’eina de control de versions a utilitzar serà una instància de GitLab pròpia de l’IMI. El flux de treball està establert i es connecta amb el pipeline de desenvolupament.

5.2.3 Qualitat de Codi

El codi que es desenvolupi, incloent-ne les demos, ha de complir un mínim de qualitat. L’eina utilitzada per realitzar la inspecció de codi és Sonarqube. Les mètriques mínimes que ha de complir el codi són les indicades a la taula següent:

Mètrica Valor

Errors bloquejants 0

Errors crítics 0

Nous errors 0

Noves vulnerabilitats 0

(25)

5.2.4 Test Unitaris

Els tests unitaris es realitzaran en temps de construcció de l’aplicació i els seus resultats quedaran reflectits en el SonarQube. Les mètriques mínimes que ha de complir són les indicades a la taula següent:

Mètrica Valor

Cobertura 60%

Cobertura de nou codi 30% Fallides de tests unitaris 0

5.2.5 Test de serveis

Es desenvoluparà un test per cada un dels serveis (REST o no) que es desenvolupin al projecte. Cada test ha d’implementar els casos d’èxit, com tots els possibles casos d’error del servei. La implementació d’aquests tests ha de ser amb jmeter o qualsevol altre eina (prèviament acceptada per l’IMI) que pugui ser fàcilment integrada amb Robot framework.

5.2.6 Tests funcionals

Els tests funcionals es realitzaran sobre Robot framework. Durant el projecte es pactarà sobre quines funcionalitats es realitzaran els test, amb quina profunditat, quin nivell de validació és farà servir...

Com a mínim es realitzarà un test basic de navegació de l’aplicació. Es a dir, es validarà.

(26)

6 Entorn tecnològic

6.1 Plataforma actual:

La plataforma DevOps actual està composada per:

 Gitlab – comunity edition (omnibus)

 Subversion (legacy)

 Sonarqube

 Nexus

 Orquestrador, Release Management (eina feta a mida)

 XWiki

 Jenkins

Cadascuna d’aquestes eines està desplegada a l’ICP. Cada producte aixeca 1 o més pods per a funcionar i es comuniquen entre elles dintre del mateix namespace. Completa el sistema tot un seguit de jobs (cronjobs) encarregats d’executar diferents tasques de manteniment com poden ser la neteja periòdica del Nexus.

6.1.1 Jenkins

Versió actual 2.235. (cada any realitzem una actualització de l’eina, que aquesta vegada recaurà sobre aquest el projecte, per dates).

Considerem que el jenkins és el producte més complex de la migració, ja que té una integració més profunda amb el dimoni de docker. Hem de tenir en compte que, en l’entorn, actual, dintre dels diferents pipelines de construcció, jenkins es capaç d’accedir a comandes docker (Docker in Docker) per tal de construir imatges i aixecar contenidors. Caldrà veure si el funcionament actual es pot continuar fent servir al nou entorn o cal canviar d'estratègia per adaptar-se.

6.1.1.1 Entorns

Un únic Jenkins (amb els seus diferents slaves) dóna servei a la construcció i desplegament per als tres entorns: integració, pre-producció i producció.

Aquest sistema ha sigut suficient fins ara, però és veritat que no independitza els diferents entorns. Donat que els recursos són finits, una càrrega excessiva de desplegaments/construcció als entorns no productius pot impedir o endarrerir un desplegament productiu.

6.1.1.2 Shared Libs

En la implementació actual s’ha fet servir el concepte de Shared Libs. Gràcies a aquestes llibreries tots els pipelines comparteixen codi.

(27)

Caldrà modificar aquestes llibreries per adaptar-les al nou paradigma.

6.1.2 ICP

Disposen de la versió 3.2.1 d’ICP que utilitza kubernetes 1.13.12. Característiques:

 Tenim desplegat un únic clúster.

 Cada entorn té els seus propis workers d’execució: Integració, Pre-producció i Producció.

 Cada aplicació/projecte té 3 namespaces, 1 per entorn on té desplegada la seva aplicació.

 Existeix un entorn extra anomenat actualment alm amb els seus propis workers, format per un únic namespace on resideix tota la plataforma DevOps comentada. És el que cal migrar.

 Totes les eines actuals fan servir Ingress per publicar el seus serveis i front-ends

6.2 Plataforma de destí

6.2.1 Split del cluster actual.

El nou entorn estarà format, com a mínim, per dos clústers kubernestes d’OpenShift. Un per l’entorn d’integració i pre-producció, i un altre per l’entorn de producció.

Excepte que es decideixi una altra cosa, durant l’execució del projecte l’entorn DevOps es desplegarà al clúster d’integració. Des de aquest entorn es desplegarà a qualsevol entorn en qualsevol dels clústers disponibles.

Aquest Split pot ser una oportunitat per millorar la limitació comentada en l’apartat 6.1.1.1.

6.2.2 Nova plataforma de Kubernetes, OpenShift.

La nova plataforma serà OpenShift 4.6 (o 4.7, depenent del moment d’inici del projecte). Entre les diferències amb l’entorn anterior remarquem:

- ICP: Nginx ingress controller 0.23.1 basat en Nginx 1.15.9

- OpenShift ver. 4.6: HA Proxy ingress controller basat en HA Proxy 2.0.16

(28)

7 Acords de Nivell de Servei (ANS)

Els Acords de Nivell de Servei que s’aplicaran durant l’execució del present contracte de Serveis per a la migració de la plataforma CI/CD (Continuous Integration/ Continuous Deployment) a OpenShift i que permetran monitoritzar i avaluar la qualitat i la gestió, són els que s’indiquen a la següent taula:

Codi Indicador Descripció Càlcul Periodicitat Valor

límit RpA Rotació de personal adscrit al servei Percentatge de rotacions del personal adscrit al servei RpA = Rotacions / Persones adscrites al contracte Trimestral 30% DtE Desviació temps execució Fase/Fita Fase/Fita executada en el període de temps establert

DtE = Temps

execució Fase o Fita - Temps establert d'execució

n/a (per cada fita) 1

setmana

CdE Compliment dates execució

Rati de Fases/Fites executades en temps

CdE = Fases i Fites executades en temps / Total Fases i Fites executades Semestral 89% QdG Qualitat dels documents generats com a part de la activitat en la prestació del servei Rati de documents acceptats per part de les àrees responsables del servei sense esmenes o iteracions en la seva elaboració QdG = Documents acceptats en primera instància / Documents lliurats

n/a (per cada fita) 85%

TrR Temps de resposta a peticions urgents Retard en la resposta a peticions urgents respecte al temps establert

Trp = Temps de resposta - Temps establert de resposta

n/a (cada cop que hi hagi una petició urgent 2 hore PrP Puntualitat en la resposta a peticions urgents

Rati de peticions urgents que reben resposta dintre del període de resposta definit respecte al total de peticions urgents PrP = Nombre de peticions urgents respostes en temps / Total de peticions urgents Mensual 85%

(29)

CeQ Compliment amb els estàndards de qualitat Percentatge d’elements que compleixen els estàndards d’arquitectura en fer el seu anàlisi

CeQ = Elements que compleixen l’estàndard d’arquitectura / Nombre elements analitzats Un cop finalitzat el disseny i 90% NsU Nivell de satisfacció de l'usuari clau Qualitat del desenvolupament percebuda per l'usuari mesurat mitjançant enquestes de qualitat NsU = Puntuació assignada a l'enquesta de qualitat Un cop finalitzat el projecte 8 QdD Qualitat dels desplegaments Rati de desplegaments executats en el temps establert per la finestra d'actuació aprovada QdD = Desplegaments efectuats en temps / Total desplegaments Trimestral 80% TrP Temps de resposta a incidències

Rati d'incidències per a les quals es compleix amb el temps de resposta establert segons la tipologia i criticitat de la incidència TrP = Nombre d’incidències amb resposta a temps / Total incidències Trimestral 95% TrI Temps de resolució d'incidències

Rati d'incidències per a les quals es compleix amb el temps de resolució establert segons la tipologia i criticitat de la incidència TrI = Nombre d'incidències resoltes a temps / Total incidències Trimestral 89%

Nota: En cas que dos ANS penalitzin dos cops, s’aplicarà el més restrictiu, en cap cas els dos.

(30)

8 Condicions generals de prestació del servei

8.1 Horari i Ubicació

La ubicació de la prestació dels serveis d’aquest contracte es regirà per l’establert a l’apartat 9.1 del Plec de Prescripcions Tècniques de l’Acord Marc.

8.2 Equip de treball

Tal i com s’indica a l’Acord Marc (apartat 7.2.1 del plec de prescripcions tècniques), l’adjudicatari haurà de presentar l’estructura organitzativa dimensionada i basada en els perfils declarats que permeti assegurar la cobertura de l’execució del present contracte.

L’equip mínim que es considera necessari per a l’execució del present contracte és el que s’indica a la següent taula:

Perfil Nombre de recursos

Cap de projecte expert 1

Arquitecte expert 1

L’experiència, les certificacions i els requeriments mínims exigits d’aquests perfils són els que es troben definits a l’apartat 7.1 del PPT que regeix l’Acord Marc.

Es valorarà l’experiència en els següents apartats, de la forma definida al Quadre de Característiques del Contracte:

Experiència de l’arquitecte en les eines DevOps (CI/CD): es valorarà l’experiència de

l’arquitecte en la instal·lació, configuració, desenvolupament i operació de les diferents eines a migrar.

Experiència de l’arquitecte en la plataforma kubernetes: es valorarà l’experiència de

l’arquitecte en la operació, desplegament i configuració de clústers kubernetes com a SRE (Site reliability engineering) o similar.

Experiència de l’adjudicatari del cap de projecte en projectes de DevOps amb kubernetes on-premise: donat que el projecte que s’haurà de gestionar no és comú, sinó molt específic en

certes tecnologies, es valorarà l’experiència en aquest tipus d’implantacions.

Els licitadors concretaran en la forma que s’indica en el plec de clàusules administratives particulars la composició de l’equip de treball que posaran a disposició del contracte, acreditant que compleixen amb els requisits d’experiència definits en l’Acord Marc.

(31)

L’Ajuntament es reserva el dret de verificar les capacitats del personal que participa en el projecte en qualsevol moment i rebutjar-lo en cas que no compleixin amb els requisits exigits. Les despeses que en derivin com a conseqüència de canvis en l’equip de projecte aniran a càrrec de l’adjudicatari.

L’empresa adjudicatària haurà de mantenir l’equip de treball adscrit al contracte durant tota la vigència d’aquest. En cas que s’hagi de produir la substitució d’algun membre de l’equip, que no sigui per causes de força major, l’adjudicatari ho comunicarà a l’Ajuntament de Barcelona i la substitució s’haurà de fer per un perfil que com a mínim tingui les mateixes característiques professionals i tècniques que les exigides en aquesta clàusula; en cas contrari i sense el consentiment de l’Ajuntament de Barcelona aquest fet serà susceptible a sanció.

A més, en cas de substituir algun membre de l’equip de treball, s’exigirà el següent:

• Un període de formació, a càrrec de l’adjudicatari, pel nou membre que s’incorpori a l’execució del contracte.

• Un període de coexistència, d’un mínim d’un mes, entre la persona que causa la baixa i la persona que s’incorpora.

8.3 Idioma

A més de l’especificat a l’apartat “ Annex: RA6. [Obligatori] Estructura multi-idioma”, el codi, els comentaris que s’afegeixen al codi, el nom de les variables o altres components del codi, així com documentació tècnica (no d’usuari), s’han d’escriure en anglès. Per contra, la documentació contractual, els paths de les URLs de l’aplicació i de les APIs, s’han d’escriure en català, ja que són part visible per l’usuari de l’aplicació.

8.4 Eines de suport al servei

Les eines de suport al servei seran les indicades a l’apartat 9.4 del Plec de Prescripcions Tècniques de l’Acord Marc.

(32)

9 Durada del contracte

La durada del contracte és la definida al Quadre de Característiques del Contracte, apartat “Durada i càlcul de l’import de licitació”.

(33)

10 Proposta

Els licitadors presentaran la seva oferta tècnica de realització del contracte tant per fer comprensible la seva proposta com per facilitar i fer possible la seva valoració d’acord amb els criteris d’adjudicació assenyalats en el Quadre de Característiques que regeix per aquesta contractació.

El licitador haurà de presentar la seva oferta en format electrònic, on tots els arxius han d’estar en qualsevol dels següents formats admesos per la Plataforma de Licitació Electrònica:

 Format de text natiu de Microsoft Word: .docx

 Format de full de càlcul natiu de Microsoft Excel: .xlsx.

 Format de presentació natiu de Microsoft PowerPoint: .pptx

 Format documental natiu de Adobe Acrobat: .pdf

 Format gràfic: .jpg

 Format gràfic: .tiff | .tif

 Format OpentDocument text: .odt

 Format OpentDocument full de càlcul: .ods

 Format OpentDocument presentació: .odp

 Format OpentDocument imagen: .odi

 Format comprimit natiu de Winzip i suportat por Microsoft Windows: .zip

Com a mesura alternativa per adjuntar arxius d’altres formats, es poden enviar en un arxiu comprimit (ZIP).

S’exigeix claredat, llegibilitat i usabilitat de la documentació presentada per les empreses licitadores, en particular:

 un estil de títols d’apartats que permeti establir correctament la jerarquia dels apartats del document

 un estil homogeni al llarg de tot el document, evitant desajustos de format en cas que el licitador copiï i enganxi parts d’altres documents

 en cas del PDF, format no protegit, fonts incrustades i que accepti cerques, selecció i copiat del text

El licitador haurà de presentar uns continguts mínims i estar obligatòriament estructurada de la forma següent:

Es presentaran dos sobres electrònics, el sobre electrònic AB on s’inclourà la documentació administrativa i la proposta tècnica que haurà de ser valorada segons els criteris de judici de

valor assenyalats en el quadre de característiques, i el sobre electrònic C que haurà de

contenir la documentació que haurà de ser valorada segons els criteris avaluables de forma

(34)

A l’interior de cada sobre electrònic s’ha d’incorporar una relació, en full independent, dels documents que hi conté ordenats numèricament, especialment en el sobre electrònic AB ja que aquest ha de respondre a les explicacions i compromisos sobre tots i cadascun dels criteris de valoració subjectius definits.

En el sobre electrònic AB s’inclourà la documentació següent indexada de manera que faciliti

la seva localització, per a cada apartat i entre parèntesi s’ha indicat el nombre màxim de

pàgines de què pot constar, tipus de lletra Nimbus Roman, Liberation Sans, Arial o Times New Roman, grandària 12 i interlineat simple:

 Resum executiu (màxim 3 pàgines)

Resum dels continguts més significatius de la proposta del contracte, destacant-ne els recursos i les propostes de valor afegit.

 Plantejament general i tècnic del projecte (màxim 10 pàgines)

En aquesta secció el licitador ha d’exposar el seu enteniment del projecte i les línies principals de la seva estratègia per afrontar-lo tenint en compte els requeriments exposats els apartats 5 i 6 del plec de prescripcions tècniques. El licitador presentarà els diagrames i esquemes que cregui necessaris i que ajudin a visualitzar el grau de comprensió de la solució.

 Proposta de matriu d’assignació de responsabilitats (màxim 2 pàgines)

En aquesta secció el licitador ha d’exposar el seu enteniment del projecte i de les tasques a realitzar, així com la responsabilitat de cadascuna d’elles, segons allò definit a l’apartat 5 d’aquest plec. El licitador presentarà una taula RACCI senzilla, on acrediti aquest coneixement. Ha de quedar especialment clar quan considera que la tasca és pròpia del projecte i quan es necessitarà d’equips externs.

 Pla de qualitat (màxim 2 pàgines)

En aquesta secció el licitador ha d’exposar les eines que es faran servir per tal d’assegurar la qualitat final de la solució a partir de l’expressat en el punt 5.2 d’aquest plec. El licitador presentarà els diagrames i esquemes que cregui necessaris i que ajudin a visualitzar com funcionarà aquest pla.

 Proposta d’estabilitat del sistema (màxim 5 pàgines)

En aquesta secció el licitador ha d’exposar com planteja el desplegament de la plataforma, a partir de l’expressat en el punt 6.1.1.13.1.115.2 d’aquest plec. Cal detallar clarament com planteja el desplegament de la plataforma per tal de donar una possible solució a la limitació actual.

 Pla de formació (màxim 10 pàgines)

(35)

En aquesta secció el licitador ha d’exposar el seu pla, a partir de l’expressat en el punt 3.1.115.2 d’aquest plec, per assegurar que es forma adequadament a tots els implicats, tant al personal tècnic IMI, l’AM de manteniment i els desenvolupadors que fan servir la plataforma (si fos necessari). En aquest punt es recalca que la qualitat del material utilitzat és important, ja que permetrà l’assimilació dels coneixements de forma més eficient.

 Pla de transició del projecte a servei (màxim 10 pàgines)

En aquesta secció el licitador ha d’exposar el seu pla per garantir la continuïtat del servei en el cas de canvi de proveïdor, a partir de l’expressat en el punt 3.1.115.2 d’aquest plec.

En el sobre electrònic C s’inclourà la documentació que s’especifica en el Quadre de

Característiques del Contracte.

(36)

11 Condicions generals d’execució

Les condicions generals d’execució són les definides al capítol 13 del Plec de Prescripcions Tècniques de l’Acord Marc amb les actualitzacions que es detallen a continuació.

L’IMI, com a Organisme Autònom de caràcter administratiu de l’Administració Local depenent de l’Ajuntament de Barcelona, es troba subjecte al Principi de Legalitat i posa especial èmfasi en el compliment de les obligacions legals que es deriven de la normativa de protecció de dades (Reglament General de Protecció de Dades, RGPD 2016/679, de 27 d’abril, Llei Orgànica de Protecció de Dades i de Garantia de Drets Digitals, LOPDGDD 3/2018, de 5 de desembre i altre normativa connexa), de la Llei 11/2007 d’Accés dels Ciutadans als Serveis Públics, així com de la resta de l’ordenament jurídic que sigui d’aplicació.

Aquest Plec de Prescripcions Tècniques ha estat emès, en data 12 de març de 2021, pel Sr. Ivan Ortiz Q uintana, tècnic responsable del contracte i adscrit a la Direcció d’Operacions i Sistemes, amb el vistiplau de

Sra. Amparo Rodríguez Rodríguez Directora d’Operacions i Sistemes

(37)

12 Annex: Informació addicional i/o aclariments

Si és de l’interès dels licitadors sol·licitar informació per la presentació de l’oferta, l’IMI posarà a disposició les adreces de correu imi_gestio_contractacio@bcn.cat i iortiz@bcn.cat, on els licitadors podran fer arribar les seves consultes.

En l’assumpte del correu indicar:

Contracte per a la realització Serveis per a la migració de la plataforma CI/CD (Continuous Integration/ Continuous Deployment) a OpenShift, basat en l’Acord Marc 18000204 – Lot 3

S’atendran les sol·licituds d’informació fins a 3 dies laborables abans de la data límit de presentació d’ofertes.