PSA PRJ2019 Vervanging SDE OPS
Auteur:
[email protected]
Aanmaakdatum:
18 november 2014
Laatste wijziging:
16 juni 2015
Versie:
0.1
Documentbeheer Wijzigingshistorie
Datum
Auteur
Versie
Wijziging
24 juni 2014 10 dec 2014 12 dec 2014 16 jun 2015 16 jun 2015
D. Jumelet R. Pijnenburg R. Pijnenburg / I. Sluis J. Schoonderbeek J. Schoonderbeek
0.1 0.5 0.6 0.9 1.0
Eerste opzet Aangepast op SDE voor ATM en ICT Laatste aanpassing m.b.t. functionaliteit Bijgewerkt met courante principes/richtlijnen Review commentaren verwerkt
Reviewers
Naam
Functie
Klaas Brongers
ICT-Architect
Ingrid Sluis-Huijbregts Rogier Bastiaens Jan Grinwis
ICT Demand ICT Supply Infrabeheer
blad 2
Inhoud Documentbeheer..........................................................................................................2 Wijzigingshistorie ...................................................................................................2 Reviewers ..............................................................................................................2 Inhoud ..........................................................................................................................3 Leeswijzer..............................................................................................................4 1.
INLEIDING EN SCOPE...................................................................................5 Inleiding .................................................................................................................5
2.
Algemeen ........................................................................................................6 Algemene Principes en richtlijnen..........................................................................6
3.
Bedrijfsprocessen............................................................................................8 3.1 3.2
Stakeholders. ............................................................................................8 Principes en Richtlijnen. ...........................................................................9
4.
Applicatie en data..........................................................................................10
5.
Infrastructuur .................................................................................................13 Interne Hosting ....................................................................................................13
6.
Beheer...........................................................................................................16
blad 3
Leeswijzer Luchtverkeersleiding Nederland (LVNL) heeft ervoor gekozen nieuwe bedrijfsoplossingen (of veranderingen daarin) onder architectuur te ontwikkelen. Dit heeft tot gevolg dat bij aanvang van een project naast een Project Plan ook een Project Start Architectuur (PSA) moet worden opgeleverd.
De PSA omvat de kaders, context en werkafspraken die de architect met het projectteam maakt. Een PSA wordt aan het begin van een project opgesteld en vormt, samen met het Plan van Aanpak, de start documentatie voor het project.
Doelstelling PSA Een PSA is de vertaling van de algemene LVNL principes, beleidslijnen naar voor dit project specifieke standaarden, normen, richtlijnen en naar de modellen/werkwijzen die het project dient te hanteren. De principes waaraan in deze PSA wordt gerefereerd zijn vastgelegd in de Referentie Architectuur en worden toegepast op basis van “Comply or Explain”. Dit betekent dat principes altijd geldig zijn, tenzij ze leiden tot ongewenste uitkomsten of niet passen bij het onderwerp. In dat geval kan gemotiveerd afgezien worden van het toepassen van een principe. De principes en de onderbouwing hiervan zijn opgenomen in een bijlage. Hier is ook opgenomen welke principes niet van toepassing zijn en waarom. Context
Een PSA geeft de context van de oplossing weer, niet de oplossing zelf. Hierdoor wordt voor een breder publiek(opdrachtgever, beheerder, gebruiker, eigenaar) helder wat de oplossingsrichting beoogd en waarom het een bepaalde kant opgaat.
Kaders
Een tweede doel van de PSA is het geven van kaders voor het inhoudelijke projectresultaat en voor de te hanteren methoden en technieken. De PSA bevat daarvoor: - de context van de verandering die het project gaat realiseren en het strategische doel van de verandering; - de afbakening van het verandergebied wat betreft scope; - de uitwerking van het verandergebied naar de verschillende aspecten van de architectuur waarbij per onderdeel van de architectuur wordt ingegaan op te hanteren principes en te hanteren modellen. - Architectuurmodellen opgesteld in de architectuurtaal ArchiMate.
blad 4
1. INLEIDING EN SCOPE Inleiding Momenteel maakt LVNL gebruik van de tool Service Desk Express (SDE) van BMC voor de ondersteuning van zowel de operationele ICT (onder beheer van divisie Ops) als de niet operationele ICT (onder beheer van afdeling CS\ICT). De leverancier heeft aangekondigd dat het de ontwikkeling van SDE is gestopt en dat de tool tot uiterlijk 2017 zal worden ondersteund. Dit is de reden dat LVNL PRJ2019 heeft geïnitieerd om een nieuwe IT-beheertool in gebruik te gaan nemen. M.b.t. dit project heeft geen RFI plaatsgevonden; er is gekozen voor een niet openbare aanbesteding. Met deze Project Start Architectuur wordt aangegeven welke functionaliteit LVNL nodig heeft voor de ondersteuning van het ICT-beheer van de twee bedrijfsonderdelen Ops en CS\ICT, en welke richtlijnen meegegeven worden aan de oplossing die aangeboden wordt. Vanuit bedrijfsperspectief mag er geen verandering van functionaliteit of proces plaatsvinden. De focus voor deze PSA ligt dan ook op applicatiekenmerken en benodigde infrastructuur.
blad 5
2. Algemeen Met dit project wordt beoogd een oplossing te realiseren die de huidige, dubbel geinstalleerde applicatie vervangt, en die het beheer van zowel de operationele als de niet-operationele ICT komponenten geautomatiseerd ondersteund. Onder “operationeel” verstaat LVNL die zaken, die direct ondersteunend zijn aan het verlenen van luchtverkeersleidingsdiensten; deze zaken vallen onder de divisie Operations, afgekort Ops. Onder “niet-operationeel” verstaat LVNL in het kader van deze PSA de zaken die onder de divisie Corporate Services ressorteren, en dan met name onder de afdeling Information & Communication Technology (CS\ICT). Deze afdeling ondersteunt kantoorautomatisering en secundaire/niet-kritieke systemen ten behoeve van Ops. De belangrijkste kwaliteitskenmerken van de te realiseren oplossing zijn: 1. In lijn met de gangbare standaarden van LVNL en de afdelingen Ops en CS\ICT. 2. Aansluiting op het te realiseren compliancysysteem. 3. Gefaseerde invoering, waarbij de eerste stap de migratie van de operationele ICT komponenten betreft, en pas daarna de niet-operationele componenten. De omgeving valt binnen openingstijden van ICT. De oplossing wordt gerealiseerd binnen de architectuur van zowel het servicedomein ATM specifiek als het domein Generieke ICT Systemen.
Algemene Principes, richtlijnen en requirements De volgende generieke principes zijn van toepassing op dit project:
A01
Principe
Rationale
Kies generiek boven specifiek
Specifieke ICT oplossingen, zoals zelfbouw of maatwerk, zijn over het algemeen duurder in aanschaf en onderhoud, en minder flexibel inzetbaar, dan soortgelijke generieke ICT oplossingen. Functionele aanpassingen aan het ICTlandschap worden doorgevoerd vanuit de behoeften die de bedrijfsvoering (met alle hierbij relevante stakeholders) heeft. Eerst de vragen Wat en Waarom en daarna pas de vragen m.b.t. het Hoe. CS\ICT diensten mogen niet direct of indirect gebruikt worden voor het uitvoeren van luchtverkeersleiding, maar hooguit dienen ter ondersteuning van nietbedrijfskritische processen. Dit geldt voor: • generieke ICT diensten; • LVNL CS-specifieke diensten; • diensten die ATM specifiek zijn.
A02
Veranderingen zijn bedrijfsgedreven
A03
ICT-services worden uitsluitend operatieondersteunend worden ingezet.
blad 6
Bovenstaande leidt tot de volgende (project)richtlijnen:
A02-‐1 A02-‐2
Richtlijn
Implicaties en toelichting
Er zijn goedgekeurde business cases en ontwerpen.
Middels de businesscase is door het MT groen licht gegeven voor de start van dit traject.
De functionele requirements De functionele requirements zijn vooraf zijn door de gebruikers bepaald en voor de twee gebieden in kaart opgesteld en vastgelegd. gebracht: J:\PRJ 2019 (Vervanging SDE OPS)\5. Gunningsfase\ knock-out criteria v1.0
Naast bovenstaande richtlijnen gelden de volgende, algemene requirements:
AR-‐1
Requirement
Implicaties en toelichting
Er is sprake van gefaseerde invoering, waarbij ATM eerst overgaat; pas na succesvolle implementatie voor ATM wordt de implementatie voor ICT opgestart.
ATM dient op korte termijn over te gaan op de nieuwe applicatie. Ter vermijden van risico’s (tijd, geld en complexiteit) bij de implementatie gaat ICT niet parallel over.
blad 7
3. Bedrijfsprocessen. De bestaande processen veranderen in essentie niet. Omdat de scope van Compliancy nog onvolledig is, wordt dit proces niet verder uitgewerkt. Ter referentie hieronder het huidige architectuurmodel voor Compliancy.
3.1 Stakeholders. Het systeem zal zowel voor operationele- als voor niet operationele registraties worden gebruikt. Vanuit dit perspectief kunnen dan ook de volgende gebruikers worden onderkend:
Stakeholder
Concern(s).
ST-1
Gebruiker Operationele Systemen
Is het systeem 24x7 beschikbaar? Kan ik doen wat ik moet doen (functioneel, zie hfdst.4)? Kan ik meldingen doorzetten naar de nietoperationele omgeving?
ST-2
Gebruiker Niet-operationele systemen
Is het systeem beschikbaarheid tijdens kantoortijden? Kan ik doen wat ik moet doen (functioneel, zie hfdst.4)
ST-3
Technisch beheer
Ben ik in staat om het technisch beheer uit te voeren?
ST-4
Functioneel beheer
ST-5
Leverancier software
Kan het systeem voldoende volgen als er wijzigingen plaatsvinden in de business (alignment)? Kan ik het systeem technisch ondersteunen?
ST-6
Manager
Krijg ik de gewenste MI informatie? Kan ik analyses uitvoeren?
ST-7
Compliancy Officer
Kan ik aantonen dat de LVNL systeemomgeving overeenkomstig wet- en regelgeving is/wordt ingericht.
blad 8
3.2 Principes en Richtlijnen.
Relevante principes M.b.t. de bedrijfsprocessen gelden voor deze voorziening de volgende principes.
B001
Principe
Rationale
Functionaliteit wordt hergebruikt waar mogelijk
Wanneer nieuwe functionaliteit moet worden gerealiseerd, dan dient gestreefd te worden naar maximaal gemeenschappelijk (her)gebruik van bestaande oplossingen. Een eventuele keuze tussen hergebruik en aanschaf/bouw wordt beslist op basis van het MoSCoW-principe. Hergebruik van bestaande functionaliteit betekent hergebruik van bestaande, al geïmplementeerde oplossingen. Dit scheelt mogelijk in kosten voor licenties, implementatie, en beheer.
Bovenstaand principe wordt vertaald naar de volgende (project) richtlijnen:
RB0101 RB0102
Richtlijnen
Implicatie en toelichting
Vanuit de processen dienen periodiek en geautomatiseerd Compliancygegevens beschikbaar te worden gesteld aan het centrale Compliancysysteem.
Compliancy is voor LVNL een belangrijk issue en dient door het Management bewaakt te kunnen worden. Voor dit doel moeten automatische rapportages worden gegenereerd.
Wanneer behoefte is aan toegevoegde functionaliteit (zoals bijvoorbeeld Composites ter ondersteuning van workflows), dan wordt dit vanuit centrale regie (Functioneel beheer) gerealiseerd.
Voorkomen moet worden dat gebruikers zelf functionaliteit gaan toevoegen met het karakter van een (kleine) bedrijfsapplicatie. Dit komt de bedrijfszekerheid en de beheerbaarheid niet ten goede. (I04). Uiteraard is het wel mogelijk om deze functionaliteit te realiseren, maar dan centraal aangestuurd, zodat inrichting, documentatie en beheer optimaal gefaciliteerd kunnen worden.
blad 9
4. Applicatie en data De in het vorige hoofdstuk beschreven processen worden door een aantal applicatieservices ondersteund en uitgevoerd. Hieronder een modelweergave van de functionaliteit en de applicatiecomponenten die een rol spelen in beide alternatieven, alsmede de infrastructuurservices die in de verschillende scenario’s nodig zijn ter ondersteuning.
De applicatie biedt dan de volgende functionaliteit: Functie
Omschrijving
Configuratie en availability beheer
Beheren van alle item die als CI zijn aangemerkt. Uitvoeren van analyses op deze items t.b.v. de hier benoemde processen/werkwijzen
Incidentbeheer
Registratie en navolging van incidenten
Change- en release beheer
Registratie van de realisatiestappen.
Compliancy rapportages
Registratie van alle activiteiten en statussen op basis van de eisen die vanuit Compliance worden gesteld.
Risico management beheer
Registratie van de risico impact voor geplande activiteiten op operationele systemen
Probleem beheer
Registratie en navolging van problemen
blad 10
Relevante principes De volgende principes zijn van toepassing op deze voorziening: Principe
Rationale
AP1
Er wordt één pakket gekozen om beide bedrijfsonderdelen (Ops en CS\ICT) te faciliteren.
A06
Gemeenschappelijke services zijn gebaseerd op COTS en het beheer ingericht op basis van Best Practices vanuit de markt.
Indien e.e.a niet via gescheiden configuraties in één installatie kan worden opgelost, dan wordt de applicatie twee maal geïmplementeerd. Verschillen in werkwijzen kunnen uitsluitend via configuratie worden geaccommodeerd. De consequentie van één fysiek systeem is in dit geval dat er geen conflicten in inrichting (functioneel gebruik) mogen ontstaan.
Bovenstaande principes leiden dan tot de volgende voor dit project relevante richtlijnen:
ID
Richtlijn
Implicaties en toelichting
PRJ2019-43
De inrichting van ATM is leidend; Aanpassingen aan werkwijze en inrichting worden primair met ATM afgestemd.
ATM is de belangrijkste gebruiker.
PRJ2019-57
Er wordt gebruik gemaakt van één applicatie voor het bedienen van zowel ATM als ICT.
De consequentie van het streven naar één systeem is in dit geval dat er conflicten zouden kunnen ontstaan in de eisen/wensen qua gebruik van ATM vis-à-vis ICT.
PRJ2019-44
Verschil in requirements tussen ATM en ICT worden uitsluitend opgelost in configuratie, niet in aanpassingen/maatwerk.
Verschillen in inrichting zijn goedkoper te realiseren en onderhouden dan aanpassingen/maatwerk in de applicatie zelf. Slechts indien inrichtingseisen onoplosbaar conflicteren, wordt er een tweede instantie geïmplementeerd. Er wordt niet teruggevallen op aanpassingen (maatwerk) aan de applicatie.
PRJ2019-54
Indien er sprake is van een dubbele implementatie, hoeft alle informatie die in beide implementaties benodigd is toch maar één keer te worden ingevoerd
De databases voor beide implementaties zijn logisch gekoppeld, hetzij door het delen van tabellen, hetzij door synchronisatie, hetzij anderszins, zodat invoer of wijziging van een gedeeld gegeven ook direct in de andere implementatie effect heeft.
blad 11
PRJ2019-42
De applicatie wordt gerealiseerd met standaard software, wordt gehost op het standaard ICT-platform, en maakt gebruik van standaard infrastructurele voorzieningen.
Hierdoor wordt aanvullende software en maatwerk voorkomen, dit draagt bij tot een efficiënt ingericht ICT landschap (A06).
PRJ2019-55
Interfaces worden dusdanig gerealiseerd dat de applicatie blijft functioneren, onafhankelijk van de status van gekoppelde systemen
Op deze manier wordt de continuïteit van de individuele applicatie niet onnodig belast bij problemen/uitval van gekoppelde systemen.
PRJ2019-56
Er dient een koppeling naar de NAW database gemaakt te worden ten behoeve van persoonsinformatie
Hiermee is informatie van medewerkers in de oplossing altijd up-to-date
PRJ2019-15
Compliancy wordt ondersteund vanuit de standaard mogelijkheden van de applicatie
Er mag geen maatwerk in de applicatie zelf benodigd zijn voor het ondersteunen van de gebruikseisen vanuit compliancy.
PRJ2019-53
Voor alle data die in de applicatie wordt opgeslagen geldt dat de beveiligingsclassificatie moet zijn vastgelegd.
De beveiligingsclassificatie is nodig om te bepalen welke data op welke plaatsen ontsloten mag worden, bijvoorbeeld bij het implementeren van werken op afstand (I08).
blad 12
5. Infrastructuur Ten behoeve van PRJ2019 worden vanuit de infrastructuur voorzieningen geboden. De basis hiervan wordt gevormd door de service Hosting. In dit hoofdstuk worden deze services modelmatig uitgewerkt, beschreven en zijn de relevante principes en specificaties opgenomen. Tevens is aangeven welke andere infrastructuurvoorzieningen worden geraakt door de realisatie. Voor dit traject wordt gebruik gemaakt van de service Interne hosting op het ICT Hyper-V platform. Deze service is Geo-redundant uitgevoerd waardoor een hoge beschikbaarheid kan worden gegarandeerd. Andere kenmerken van deze service zijn dat er geen externe afhankelijkheid is en dat interfaces met aanpalende systemen intern worden gerealiseerd.
Interne Hosting Hieronder het model dat de functionaliteit van Interne Hosting weergeeft:
blad 13
Relevante principes De volgende infrastructuur architectuurprincipes zijn van toepassing op deze voorziening: Principe
Rationale
I03
Technologie is primair gebaseerd op marktconforme producten.
Standaardisatie vergroot de beheersbaarheid. Binnen ICT leidt dit principe tot een 4 tal mainstreams: - Windows producten (OS en appl’s) - Cicso producten m.b.t. netwerk - Oracle producten m.b.t. structured dataopslag - Hardware van Dell
I06
De sourcingsstrategie is leidend Onderliggende services worden door ICT bij het hosten van applicaties beheerd; bedrijfsapplicaties worden door externe leveranciers beheerd. Door deze duidelijke scheiding kan ICT de beschikbaarheid van bedrijfsapplicaties beter garanderen.
Bovenstaande principes leiden dan tot de volgende Infrastructurele richtlijnen:
Richtlijnen
Implicatie en toelichting
I06
Er wordt gebruik gemaakt van de service “Geo-redundante Windows server”.
De applicatie wordt gehost op een georedundant uitgevoerd, middels Hyper-V gevirtualiseerd Win2012R2 server platform.
I06
Er wordt gebruik gemaakt van de service “Geo-redundante Data Management”
De database kan gehost worden op een georedundant uitgevoerd Oracle DBMS platform (12c of evt 11.2). Als dit niet past, is eventueel MS SQL (2012 of 2008) mogelijk. Het geniet zeker niet de voorkeur, maar als beide bovengenoemde diensten niet passen, dan dient de leverancier de database binnen de eigen black box te implementeren en onderhouden.
I07
Het systeem wordt niet extern ontsloten
Een externe interface levert veiligheidsrisico’s op, terwijl er geen noodzaak is voor gebruikers om het systeem vanaf niet-LVNL locaties te kunnen benaderen.
I08
De applicatie is enabled voor alle door ICT ondersteunde devices.
De mogelijkheid moet bestaan om de applicatie ook te gebruiken met mobile devices op LVNL locaties.
De applicatie is uitwijkbaar via de ICT geo redundante service “on premise hosting”
Het principe van geo-redundatie wordt gebruikt om i.g.v. ernstige verstoringen de applicatie vanuit de uitwijk locatie op te starten (binnen 48 uur).
blad 14
blad 15
6. Beheer Omdat er gebruik wordt gemaakt van al bestaande techniek, blijft de scope van beheer hier beperkt tot de inrichting en beheer van de in het voorgaande geschetste oplossing. In dit model wordt duidelijk dat voor de te realiseren oplossing een beheerorganisatie moet worden ingericht die verantwoordelijk is o.a. voor de LCM op de gevraagde functionaliteit. Het beheer wordt ingericht op basis van het volgende model:
blad 16
Relevante principes De volgende principes zijn van toepassing op deze voorziening: Principe
Rationale
M03
Onderhoud en beheer moeten los (kunnen) staan van de fabrikant van de oplossing.
Hiermee voorkomt LVNL dat een monopolist wordt binnengehaald (en daarmee mogelijke prijsopdrijving).
M04
In de installatie, operatie en onderhoud van automatiseringsoplossingen maakt CS\ICT waar mogelijk gebruik van geautomatiseerde processen
Automatisering van de ICT dienstverlening verhoogt de consistentie en herhaalbaarheid, verlaagt de foutgevoeligheid, en verminderd de beheerinspanning in uren en kosten.
M01
Het beheer wordt ingericht op basis van het principe “Managed Service”
Met managed service wordt feitelijk een SAAS constructie bedoeld met dien verstande dat er gebruik wordt gemaakt van door ICT geleverde (en onderhouden) On Premise hardware / OS. Dit wordt vertaald naar services/buildingblocks. Voor de PSA is een buildingblock een service. Een buildingblock wordt “as-is” aangeboden, het is niet iets waar je nog wat weg kunt laten of iets aan toe kunt voegen.
Onder andere bovenstaande principes leiden dan tot de volgende beheerrichtlijnen:
ID
Richtlijn
Toelichting en implicaties
MR01
ICT is verantwoordelijk voor het beheer van de infrastructuur. In het diagram zijn dit de groene vlakken. De leverancier is verantwoordelijk voor het technisch beheer, in het diagram is dit het zwarte vlak.
MR02
De applicatie wordt gedurende kantoortijden actief bewaakt en beheerd.
Beschikbaarheid mag buiten kantoortijden unattended zijn.
MR03
Er zijn noodprocedures beschreven i.g.v. onbeschikbaarheid.
Het moet mogelijk zijn om de operationele omgeving buiten de kantoortijden van ICT opnieuw te herstarten (ligt vast in RACI)
blad 17
MR04
De configuratie is uitwijkbaar via de ICT service “georedundante on-premise hosting”
Het principe van georedundantie wordt toegepast om in geval van ernstige verstoringen de applicatie vanuit de uitwijklocatie te kunnen exploiteren.
MR05
Hosting van de applicatie vereist een Technisch Ontwerp waar zowel leverancier als ICT achter kunnen staan.
Is er een TO opgesteld, afgestemd, goedgekeurd en overgedragen aan ICT.
MR06
Businessapplicaties worden proactief beheerd.
Monitoring van de applicatie is door de leverancier ingeregeld.
MR07
Applicaties/clients voor gebruik op de desktop worden altijd gescript.
In het geval er voor de oplossing software op de desktop geinstalleerd moet worden, dient de leverancier de packaging te regelen voor uitrol ervan.
MR08
De data binnen de applicatie is geclassificeerd en op passende wijze beschermd.
Dataclassificatie door de business, met ondersteuning van de leverancier, leidt tot implementatie van passende beveiligingsmaatregelen.
Projectorganisatie PO01
Het systeem wordt dusdanig opgeleverd dat alle betrokken partijen hun taak kennen en daarop toegerust zijn, zowel voor functioneel als voor technisch beheer.
Duidelijkheid m.b.t. beheer; wie doet wat en wanneer. Alle betrokken partijen worden opgenomen in een RACI matrix waarin ze worden gekend en welke ze accorderen. Partijen die verantwoordelijk zijn (R) voor een bepaalde activiteit, beschrijven deze en geven aan wat ze van andere betrokken partijen verwachten.
PO02
Leverancier neemt, samen met de business eigenaar, het initiatief bij de inrichting van functioneel beheer. De gebruikersorganisatie is betrokken middels key users.
De leverancier geeft aan welke werkzaamheden hij tot functioneel beheer rekent en welke partijen daar een rol in hebben. Voor zowel de Operationele als voor de ICT implementatie is tenminste één key-user benoemd. Inrichting belegd op basis van taakbelegging Management Informatie
PO03
De leverancier is verantwoordelijk voor het technisch beheer.
De leverancier geeft aan welke werkzaamheden hij tot technisch beheer rekent, hoe deze worden ingevuld, wat de raakvlakken zijn met de andere beheerdisciplines en welke eisen hij aan ICT en andere betrokken partijen stelt
PO04
ICT is verantwoordelijk voor de onderliggende services. Dit zijn - Hosting - Netwerk - Desktops - Dataopslag - Externe toegang t.b.v. beheer
De leverancier is verantwoordelijk voor de aansluiting op deze services.
PO05
ICT kan ongehinderd Lifecycle De inrichting en werkwijze zoals deze Management (LCM) uitvoeren op de door de leverancier wordt gevoerd, mag onderliggende services het LCM niet blokkeren.
blad 18
PO06
Er worden bij de LVNL twee afzonderlijke, gescheiden omgevingen gerealiseerd: één productieomgeving, en één test/acceptatieomgeving.
ICT levert en beheert voor beide omgevingen de onderliggende services. De leverancier doet inrichting en beheer voor beide omgevingen.
PO07
De documentatie op het gebied van functionele en technische inrichting en beheer is onderdeel van de oplevering.
De functionele ontwerpdocumentatie word overgedragen aan de business, en dient door hen expliciet geaccepteerd te worden. De technische ontwerpdocumentatie word overgedragen aan ICT, en dient door ICT expliciet geaccepteerd te worden. De software is opgenomen in de asset database.
PO08
Het systeem wordt door de leverancier opgeleverd en door LVNL geaccepteerd
Changes, verstoringen en licenties CH01
De leverancier draagt er zorg voor dat ICT te allen tijde één en slechts één aanspreekpunt heeft.
Duidelijkheid over communicatielijnen, en beschikbaarheid van deze lijnen wanneer ze nodig blijken.
CH02
Softwarelicenties worden aangeschaft via ICT; de leverancier geeft aan welke licenties (soort en aantallen) er besteld moeten worden.
Benodigde licenties in relatie tot het licentiemodel dient te worden onderbouwd.
CH03
De leverancier verleent, indien daartoe wordt gevraagd, technische ondersteuning bij het diagnosticeren en/of oplossen van verstoringen.
Wanneer ICT een verstoring ondervind aan het systeem van de leverancier, of wanneer dit systeem mogelijk betrokken is bij een verstoring, kan ICT de leverancier om bijstand verzoeken. De leverancier verschaft dan technische informatie over de werking van de door hem beheerde black-Box, verzorgt het debuggen/troubleshooten, en verschaft de benodigde rapportages en logs.
blad 19
Contracten en documentatie/overeenkomsten CN01 De dienst wordt door de leverancier Duidelijkheid naar organisatie voldoende gespecificeerd en beschreven voor opname in de PDC CN02
De leverancier geeft een resultaatverplichting af op de te leveren dienst.
Zekerheid over kwaliteit en niveau van de af te nemen dienst.
CN03
De SLA beschrijft minimaal: - reactietijden - openingstijden - Flow hoe storingen worden opgelost
Duidelijkheid naar organisatie
CN04
Er wordt een DAP opgesteld tussen ICT en de interne gebruikersorganisatie(s)
Duidelijkheid naar organisatie
CN05
Er wordt een DAP opgesteld tussen ICT en leverancier(s) m.b.t. (ten minste) - technisch beheer - LCM - change management - incident management
Er zijn geen onbeheerde onderdelen. Leverancier zorgt voor aansluiting op de LVNL ICT processen Change Management en Incident Management
blad 20
