Bijlage 2. Programma van Eisen

Bestek nr. 16EN2014/3

Bijlage 2 Programma van Eisen

WESP3.0: Implementatie Dynamische Kielspeling WESP4.0: Migratie naar Enterprise Architectuur SRK

Bijlage 2, Programma van eisen – WESP3.0/4.0 versie 2.0, d.d. 15/12/2014

1/13


INHOUDSOPGAVE 1 2

INLEIDING ................................................................................................................................................... 3 NIET-FUNCTIONELE EISEN ................................................................................................................... 4

2.1 HUIDIG APPLICATIELANDSCHAP ................................................................................................................... 4 2.2 INTERACTIES HUIDIGE WESP APPLICATIE..................................................................................................... 5 2.3 HET WAN-SRK ............................................................................................................................................. 6 2.4 HET VIRTUALISATIE PLATFORM (VPT) ......................................................................................................... 7 3 4

TE REALISEREN AANPASSING AAN WESP (DEELOPDRACHT A, RELEASE 3.0).................. 8 MIGRATIE NAAR ENTERPRISE ARCHITECTUUR SRK................................................................. 9

4.1 ARCHITECTUURVISIE ...................................................................................................................................... 9 5

EISEN BEHEER EN ONDERHOUD ...................................................................................................... 10

5.1 EISEN T.A.V. 1STE EN 2DE LIJN ONDERHOUD ................................................................................................... 10 5.1.1

Service domeinen medebeheerders .............................................................................................. 10

5.1.2

Monitoring ....................................................................................................................................... 10

5.1.3

Onderhoud ....................................................................................................................................... 11

5.1.4

Acceptatieomgeving ....................................................................................................................... 11

5.1.5

Application Logging ....................................................................................................................... 11

5.1.6

Standaarden ..................................................................................................................................... 11

5.2 EISEN T.A.V. 3DE LIJN ONDERHOUD (DEELOPDRACHT C1/C2) ................................................................... 11 6

BIJLAGEN ................................................................................................................................................... 13 FIGUREN

Figuur 1: Huidig applicatielandschap ............................................................................................................... 4 Figuur 2: Interacties huidige WESP applicatie ................................................................................................. 5 Figuur 3: SRK WAN verbindingen .................................................................................................................... 6 Figuur 4: Algemene architectuur VPT-SRK...................................................................................................... 7 Figuur 6: Opzet huidige WESP applicatie ........................................................................................................ 8 Figuur 6: Opzet toekomstige WESP applicatie met probabilistisch rekenhart ............................................ 8 Figuur 7: Kanaal ESB - Domein ........................................................................................................................ 10


2/13


1 Inleiding Dit Programma van Eisen (PVE) heeft betrekking op de basisopdracht van het bestek 16EN2014/3 (Deelopdracht A), d.i. de realisatie van de “Dynamische Kielspeling (DKS) GNB Scheldegebied inclusief aanpassingen en interface naar de bestaande Westerschelde Planner (WESP)” met als doel het vastleggen en aflijnen van het eisenpakket van Opdrachtgevers met betrekking tot het realiseren van een probabilistisch rekenhart in de bestaande WESP. Uitgewerkt in de hoofstukken 2 t/m 3. Vervolgens wordt in hoofdstuk 4 de achtergrond geschetst waarmee rekening dient te worden gehouden bij Deelopdracht B2: Zowel DKS als WESP migreren naar de nieuwe Enterprise Architectuur Schelderadarketen. In hoofdstuk 5 geeft het eisenpakket weer t.a.v. het 3de lijnsonderhoud (deelopdracht C1/C2) en de eisen die de bestaande 1ste/2de lijnscontractant stelt.


3/13


2 Niet-functionele eisen 2.1 Huidig applicatielandschap

Figuur 1: Huidig applicatielandschap


4/13


2.2 Interacties huidige WESP applicatie

Figuur 2: Interacties huidige WESP applicatie

Voor verdere details omtrent het huidige WESP en zijn interactie met de omgeving zie het TO versie 2


5/13


2.3 Het WAN-SRK Het netwerk dat de verschillende locaties van SRK met elkaar verbindt wordt het SRK WAN genoemd. Het SRK WAN is geografisch gespreid over België en Nederland. Het WAN zorgt ervoor dat de locaties langs de Schelde gekoppeld worden aan een globaal netwerk zodat het uitwisselen van gegevens tussen deze locaties sterk vereenvoudigd kan worden.

Figuur 3: SRK WAN verbindingen


6/13


2.4 Het Virtualisatie Platform (VPT) Het virtualisatie platform van de Schelderadarketen bevindt zich in het datacentrum van het Schelde Coördinatie Centrum (SCC) te Vlissingen. Om een gedegen disaster recovery te kunnen realiseren werd er een stand-by datacenter in het datacentrum van de verkeerscentrale Zandvliet voorzien. Onderstaande figuur geeft de opzet weer van de vooropgestelde architectuur.

Figuur 4: Algemene architectuur VPT-SRK

WESP draait primair op het datacentrum in Vlissingen. Het is mogelijk om gebruik te maken van de fail over locatie in Zandvliet


7/13


3 Te realiseren aanpassing aan WESP (deelopdracht A, release 3.0) De Opdrachtnemer dient te vertrekken vanuit de huidige applicatie, de broncode wordt hierbij overgedragen aan de Opdrachtnemer.

ECS Distributie

VWM / HMC

(elektronische kaarten

(verwachte hydro-meteo parameters)

En diepte grids)

WESP

IVS

(Registratie scheepsbewegingen)

Deterministisch rekenhart

Figuur 5: Opzet huidige WESP applicatie

De Opdrachtnemer dient de huidige WESP applicatie aan te passen zodanig dat de interfaces naar de bestaande applicaties identiek blijven, maar dat er intern een probabilistisch rekenhart beschikbaar wordt gesteld aan de WESP gebruiker:

ECS Distributie

VWM / HMC

(elektronische kaarten

(verwachte hydro-meteo

en diepte grids)

parameters)

DKS Probalistisch rekenhart

WESP

IVS

(Registratie scheepsbewegingen)

Deterministisch rekenhart

Figuur 6: Opzet toekomstige WESP applicatie met probabilistisch rekenhart


8/13


De oplossing dient indien mogelijk fundamentele web- en webservice standaarden te gebruiken voor de communicatie tussen WESP en het probabilistisch rekenhart. In bijlage zijn alle relevante documenten toegevoegd, m.n.:  

Functioneel en Technisch Ontwerp van de huidige WESP applicatie (release 2.0) Functionele en Operationele Eisen m.b.t. release 3.0

4 Migratie naar Enterprise Architectuur SRK In dit hoofdstuk wordt uiteengezet met welke visie, betreffende de architectuur, men rekening dient te houden bij Deelopdracht B2: WESP3.0 migreren naar de nieuwe Enterprise Architectuur Schelderadarketen, dit wordt WESP release 4.0.

4.1 Architectuurvisie In recente jaren hebben de Opdrachtgevers eerste stappen gezet in de richting van een meer service-georiënteerde architectuur. Die architectuur werd geënt op een uitgebreid, reeds bestaand software landschap (zie hoofdstuk 2.1) welke ruwweg als een verzameling van applicatie silo’s kan worden geïnterpreteerd. Om die reden werd een studie uitgevoerd met als doel een enterprise architectuur uit te tekenen, die geschikt is om de toekomstige uitdagingen van het Gemeenschappelijk Nautisch Beheer vlot het hoofd te kunnen bieden. Opdrachtgevers hebben nood aan een veel flexibelere architectuur in de vorm van een sterk modulair platform. Dat platform dient echter niet als een allesomvattende monoliet te worden gezien, integendeel. Een modulair platform moet gezien worden als een verzameling van bouwstenen, modules, die in een los verband (door toepassing van “loose coupling”) kunnen samenwerken. Zulk een architectuur laat toe dat nieuwe modules flexibel kunnen worden toegevoegd of dat bepaalde bestaande modules flexibel kunnen worden vervangen. Met de “module” als basis concept worden drie gespecialiseerde concepten geïntroduceerd: 

Kanaal: Een kanaal vormt een specifieke ontsluitingsmodule naar een welbepaald gebruikersgroep toe met gerelateerde noden. Een voorbeeld van een specifiek kanaal zou een ontsluiting kunnen zijn ten behoeve van de verkeersleiders en andere stakeholders waarmee deze in hun dagdagelijkse opdracht interageren. Een kanaal representeert een “virtueel” applicatie concept op basis van beschikbare services die worden aangereikt door het volgende concept.



Enterprise Service Bus: Het “Enterprise Service Bus” concept vertegenwoordigt de patronen en de benodigde “middleware” en specifieke software ontwikkeling om “enterprise” services te realiseren, herbruikbare diensten die door kanalen kunnen worden geconsumeerd. Ook services worden opgevat als modules. Bij het ontwerp en de ontwikkeling van deze herbruikbare diensten is onderlinge coherentie een zeer belangrijk streven. Ook wordt de toepassing van de filosofie van een “Canonical Data Model” voorzien in deze laag.



Domein: Een “enterprise” service biedt binnen de onderneming een universele manier om toegang te verkrijgen tot een dienst volgens een welbepaalde “quality of service”. De echte implementatie van die service wordt echter gerealiseerd binnen een domein module welke voor de Schelderadarketen relevante business functies voor lange termijn verankert. Op die manier kan een “enterprise” service gehandhaafd blijven doch een nieuwe implementatie krijgen zonder dat kanalen daar hinder van ondervinden.

De kanaal, enterprise service bus en domein concepten worden gepositioneerd in een 3 lagen model:


9/13


Figuur 7: Kanaal ESB - Domein

5 Eisen Beheer en onderhoud 5.1 Eisen t.a.v. 1ste en 2de lijn onderhoud De huidige 1ste en 2de lijnscontractant legt een aantal aanbevelingen op voor nieuwe systemen/applicaties. Deze aanbevelingen zijn geschreven vanuit het perspectief van de dagelijkse praktijk van de B&O, waarbij mede gekeken is naar een aantal Best Practices binnen Service Delivery (ITIL), Service Transitie (ITIL), Application Service Level management (ASL) en Service Productie (ITIL).

5.1.1

Service domeinen medebeheerders

Het te leveren systeem dient de scheidingen in beheer zo goed als mogelijk te respecteren. Deze scheidingen zijn georganiseerd in de domeinen beheer virtualisatie, beheer operating systemen, beheer applicaties en beheer netwerk. Deze domeinen worden door diverse leveranciers ingevuld. De leverancier(s) dienen medewerking te verlenen aan het beschrijven van een security document waarin deze scheidingen worden vastgelegd.

5.1.2

Monitoring

De geleverde dienst wordt bewaakt met behulp van één of meerdere systemen voor monitoring en systeem management van de afnemer en de aan de afnemer verbonden operatoren. De opdrachtnemer dient medewerking te verlenen aan de integratie van het te leveren systeem bij de monitoring door de klant en de aan de klant verbonden operatoren. Er wordt gebruik gemaakt van Check_mk (gebaseerd op Nagios Core).


10/13


5.1.3

Onderhoud

Onderhoud op de te leveren systemen dient een minimale taakbelasting te zijn voor het te leveren systeem. Daar waar mogelijk worden onderhoud en/of controle taken ingeregeld via de monitoring van de servicedek SRK-MRCC.

5.1.4

Acceptatieomgeving

Voor het te leveren systeem dient naast een productie omgeving ook een acceptatie omgeving ingericht te worden.

5.1.5

Application Logging

Logging dient voor alle te leveren systemen flexibel instelbaar te zijn, en moet waar nodig voorzien in de informatie die noodzakelijk is om goed en snel te kunnen troubleshooten bij incident en problem management.

5.1.6

Standaarden

Het te leveren systeem dient zo optimaal als mogelijk gebaseerd te zijn op open IT standaarden.

5.2 Eisen t.a.v. 3de lijn onderhoud (deelopdracht C1/C2) De volgende taken en verantwoordelijkheden worden op verzoek door Opdrachtnemer uitgevoerd in het kader van 3e lijns support voor de ondersteunde applicatie: • Event Management a. Aanleveren van alle relevante informatie zodat de applicatie gemonitord kan worden op goed functioneren (bijvoorbeeld uitlezen van logfiles, gebruik maken van SNMP traps) • Incident Management en Request Fulfillment (Ondersteuning 1e lijn) a. Telefonische hulp tijdens calamiteiten die door het personeel ter plaatse opgelost kunnen worden aan de hand van telefonische instructies b. Het eventueel tot stand brengen van een “remote access” toegang teneinde calamiteiten te verhelpen c. Indien nodig (en in het uiterste geval) hulp ter plekke, waarbij naar de betreffende locatie zal worden gegaan om ter plaatse ondersteuning te bieden d. Aanleveren 1e lijns richtlijndocument • Problem Management a. Root cause analysis i. Probleem onderzoek ii. Foutidentificatie iii. Oplossing en/of workaround maken en aanleveren iv. Bepalen of definitieve oplossing nodig is v. Foutbeoordeling vi. Zoeken van definitieve oplossing b. Goedkeuren van permanente oplossing c. Informeren van changemanagement d. Informeren van incidentmanagement • Change management (preventief, correctief) a. Opleveren nieuwe versie van de software/hardware b. (release) notes c. Testresultaten d. Openstaande bevindingen e. Analyse van de impact op de ondersteunde applicatie als gevolg van changes in de omgeving van de ondersteunde applicatie


11/13


•

Configuratie management a. Aanleveren informatie voor het actualiseren van de CMDB in verband met wijzigingen in de componenten in beheer • Release and deployment management a. Bijdragen aan opstellen Release management Policy b. Bijdragen aan / opstellen van Test- en Releasekalender c. Compatibiliteitsmatrix aanleveren • Reparatie / carry-in afspraken: reparatieservice voor componenten van deelsystemen (indien van toepassing) • Gevraagd en ongevraagd advies met betrekking tot optimalisatie bestaande systemen • Kennisoverdracht ingeval van nieuwe releases/updates/… • Opleiding, bestaande uit: a. Overzicht van de toepassing b. Systeemarchitectuur Standaard procedures m.b.t. het beheer en onderhoud (backup, recovery, shutdown, restart, failover, …)


12/13


6 Bijlagen Volgende bijlagen maken integraal deel uit van dit bestek: 1.

Functioneel Ontwerp WESP 2.0: WESP-R2-FS-1.3 d.d. 15 maart 2013

2.

Technisch Ontwerp WESP 2.0: WESP-R2.TO.3.1 d.d. 15 maart 2013

3.

Marktonderzoek Dynamische Kielspeling: versie 3.0 d.d. 19.2.2014

4.

Functionele en Operationele Eisen: versie 3.0 d.d. 31.3.2014

5.

Deterministisch vs. Probabilistisch Toelatingsbeleid Vergelijkend onderzoek voor de Scheldehavens 29.3.2013, Universiteit van Gent


13/13

Bijlage 2. Programma van Eisen

Recommend Documents