Bijlage 2. Programma van Eisen

Transcriptie

1 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

2 INHOUDSOPGAVE 1 INLEIDING NIET-FUNCTIONELE EISEN HUIDIG APPLICATIELANDSCHAP INTERACTIES HUIDIGE WESP APPLICATIE HET WAN-SRK HET VIRTUALISATIE PLATFORM (VPT) TE REALISEREN AANPASSING AAN WESP (DEELOPDRACHT A, RELEASE 3.0) MIGRATIE NAAR ENTERPRISE ARCHITECTUUR SRK ARCHITECTUURVISIE EISEN BEHEER EN ONDERHOUD EISEN T.A.V. 1 STE EN 2 DE LIJN ONDERHOUD Service domeinen medebeheerders Monitoring Onderhoud Acceptatieomgeving Application Logging Standaarden EISEN T.A.V. 3 DE LIJN ONDERHOUD (DEELOPDRACHT C1/C2) BIJLAGEN 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 Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 2/13

3 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 3 de lijnsonderhoud (deelopdracht C1/C2) en de eisen die de bestaande 1 ste /2 de lijnscontractant stelt. Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 3/13

4 2 Niet-functionele eisen 2.1 Huidig applicatielandschap Figuur 1: Huidig applicatielandschap Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 4/13

5 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 Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 5/13

6 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 Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 6/13

7 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 Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 7/13

8 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 (elektronische kaarten En diepte grids) VWM / HMC (verwachte hydro-meteo parameters) 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 (elektronische kaarten en diepte grids) VWM / HMC (verwachte hydro-meteo parameters) DKS Probalistisch rekenhart WESP IVS (Registratie scheepsbewegingen) Deterministisch rekenhart Figuur 6: Opzet toekomstige WESP applicatie met probabilistisch rekenhart Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 8/13

9 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 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 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: Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/2014 9/13

10 Figuur 7: Kanaal ESB - Domein 5 Eisen Beheer en onderhoud 5.1 Eisen t.a.v. 1 ste en 2 de lijn onderhoud De huidige 1 ste en 2 de 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) 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 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). Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/ /13

11 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 Acceptatieomgeving Voor het te leveren systeem dient naast een productie omgeving ook een acceptatie omgeving ingericht te worden 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 Standaarden Het te leveren systeem dient zo optimaal als mogelijk gebaseerd te zijn op open IT standaarden. 5.2 Eisen t.a.v. 3 de lijn onderhoud (deelopdracht C1/C2) De volgende taken en verantwoordelijkheden worden op verzoek door Opdrachtnemer uitgevoerd in het kader van 3 e 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 1 e 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 Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/ /13

12 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, ) Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/ /13

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 Technisch Ontwerp WESP 2.0: WESP-R2.TO.3.1 d.d. 15 maart Marktonderzoek Dynamische Kielspeling: versie 3.0 d.d Functionele en Operationele Eisen: versie 3.0 d.d Deterministisch vs. Probabilistisch Toelatingsbeleid Vergelijkend onderzoek voor de Scheldehavens , Universiteit van Gent Bijlage 2, Programma van eisen WESP3.0/4.0 versie 2.0, d.d. 15/12/ /13