D-2) Beheerst naar beheer

Document D-2
Ministerie van Infrastructuur en Milieu
Beheerst naar beheer
Versie 1.0
Datum
Status
15 juli 2014
Definitief
Definitief | Beheerst naar beheer | Versie 1.0
Colofon
Versie
1.0
Contactpersoon
Paul Leunissen
M 06 - 5250 6691
[email protected]
Ministerie van Infrastructuur en Milieu
Hoofddirectie Financiën, Management en Bedrijfsvoering
Directie Concern Informatievoorziening
Afdeling Architectuur en Informatie Management
Team Architectuur
Koningskade 4
Postbus 20906
2500 EX Den Haag
Auteurs
Adam Loorbach
Stephen Oostenbrink
Pagina 3 van 13
Definitief | Beheerst naar beheer | Versie 1.0
Inhoud
1
Inleiding ........................................................................................................... 7
1.1
Doel ............................................................................................................................ 7
1.2
Leeswijzer .................................................................................................................... 7
1.3
Referenties ................................................................................................................... 7
2
Achtergrond ...................................................................................................... 8
2.1
Kenmerken IenM omgeving ............................................................................................. 8
2.2
Noodzaak voor hoge kwaliteit documentatie ....................................................................... 8
2.3
Acceptatiecriteria deliverables .......................................................................................... 8
3
Requirements IenM .......................................................................................... 10
3.1
Documentatie deliverables............................................................................................. 10
3.2
Platform en koppeling eisen ........................................................................................... 10
4
Oplevering leverancier ...................................................................................... 11
4.1
Documentatie deliverables............................................................................................. 11
4.2
Software en scripts deliverables ..................................................................................... 12
5
Acceptatie IenM ............................................................................................... 13
5.1
Ingangscriteria ............................................................................................................ 13
5.2
Deliverables ................................................................................................................ 13
Pagina 5 van 13
Definitief | Beheerst naar beheer | Versie 1.0
1
Inleiding
1.1
Doel
Het doel van dit document is om het proces te beschrijven dat IenM hanteert om
opleveringen door leveranciers beheerst naar beheer te brengen.
1.2
Leeswijzer
Dit document is als volgt opgebouwd:
Hoofdstuk 2 beschrijft de achtergrond m.b.t. het proces
Hoofdstuk 3 beschrijft de input artefacten die IenM oplevert richting de
leverancier op basis waarvan de oplossing ontwikkeld dient te worden.
Hoofdstuk 4 beschrijft de deliverables die de leverancier dient op te leveren.
Hoofdstuk 5 beschrijft het acceptatie proces door IenM en de deliverables die
tijdens dit proces worden opgeleverd.
1.3
Referenties
De volgende documenten zijn relevant om dit document goed te begrijpen.
#
Referentie
Document
1
Afkortingen en
begrippen
IenM - Standaard Platform - Afkortingen en begrippen v1.0.docx
2
SGA
IMEA - Katern - Service Gerichte Architectuur - v1.0.docx
3
SP
IMEA - Katern - Standaard Platform - v1.0.docx
4
Aansluitvoorwaarden
IMEA - Aansluitvoorwaarden - v1.0.docx
5
Aansluitvoorwaarden
applicaties
IenM - Standaard Platform - Aansluitvoorwaarden Applicaties
en Componenten - v1.0.docx
Pagina 7 van 13
Definitief | Beheerst naar beheer | Versie 1.0
2
Achtergrond
Dit hoofdstuk beschrijft de kenmerken van IenM en keuze voor het ontwikkel- en
opleverproces.
2.1
Kenmerken IenM omgeving
2.1.1
Bedrijfskritische applicaties en complexe omgevingen
Veel (bedrijfskritische) applicaties binnen IenM zijn afhankelijk van het goed
functioneren van meerdere ketenpartijen. In geval van calamiteiten moeten
problemen snel kunnen worden gelokaliseerd en opgelost.
2.1.2
Typen beheerders, verloop en achtervang
IenM kent meerdere typen beheerders die een groot aantal applicaties van
verschillende leveranciers beheren. Naast natuurlijk verloop is het ook noodzakelijk
dat er achtervang wordt ingericht voor alle rollen i.v.m. afwezigheid tijdens
vakanties en ziekte.
2.1.3
Wisselende leveranciers en infrastructuren
Als gevolg van aanbestedingen is het mogelijk dat er van leverancier wordt
gewisseld voor het ontwikkelen van een nieuwe release of dat de hosting van een
applicatie wordt verplaatst naar een andere infrastructuur.
2.2
Noodzaak voor hoge kwaliteit documentatie
Bovenstaande kenmerken creëren de noodzaak dat alle applicaties dusdanig goed
gedocumenteerd zijn, dat beheertaken zonder problemen kunnen worden overgedragen tussen beheerders onderling, en tevens dat de ontwikkeling van een
nieuwe release en beheer kan worden uitbesteed aan een andere leverancier. Om
deze reden schrijft IenM een lijst van deliverables voor die als onderdeel van elke
release opgeleverd en geaccepteerd dienen te worden.
2.3
Acceptatiecriteria deliverables
Om tot acceptatie van deliverables te komen dient aan de volgende voorwaarden te
zijn voldaan:
1. Een deliverable heeft het standaard ontwikkelproces doorlopen en is akkoord
bevonden door de daarvoor gemandateerde accepterende partij(en).
2. Een deliverable voldoet aan de hiervoor van toepassing zijnde eisen en/of
aan met de accepterende partij(en) gemaakte aanvullende afspraken.
3. Documentatie heeft het formaat van het vastgestelde standaard template
tenzij er additionele afspraken hieromtrent zijn gemaakt met de
accepterende partij(en).
4. Alle software componenten voldoen aan de zgn. ‘Definition of Done’ zoals die
is vastgesteld binnen het projectteam.
5. Alle producten voldoen aan de architectuurkaders zoals beschreven in de
verschillende architectuurdocumenten, zie lijst van referentiedocumenten in
paragraaf 1.3.
6. Alle documentatie heeft de status definitief en minimaal versienummer 1.x.
Pagina 8 van 13
Definitief | Beheerst naar beheer | Versie 1.0
7. Alle gedefinieerde tests zijn succesvol doorlopen.
8. Er is bepaald wat er met de restpunten gebeurt en wanneer deze opgelost
moeten zijn.
9. Het product is gereed om in productie genomen te worden.
Pagina 9 van 13
Definitief | Beheerst naar beheer | Versie 1.0
3
Requirements IenM
Dit hoofdstuk beschrijft wat IenM als input documentatie oplevert, op basis waarvan
de leverancier de koppeling of applicatie dient te ontwikkelen.
3.1
Documentatie deliverables
3.1.1
Scope / User stories
IenM beschrijft de functionele vraag in de vorm van User stories. Indien relevant
wordt er tevens een Scope document opgeleverd waarin achtergrond informatie en
een voorzet voor specifiekere requirements is opgenomen. Daarnaast dient het
scope document als naslagwerk voor IenM waarin de gemaakte keuzes rondom de
koppelingen en applicaties duidelijk zijn gedocumenteerd. Ten slotte worden de
implicaties beschreven van het uitvallen van de koppeling en/of ketencomponent en
welke tegenmaatregelen noodzakelijk zijn.
3.1.2
Ketenoverzicht
Het ketenoverzicht document beschrijft de infrastructuur en componenten van de
keten. Hierin wordt de infrastructuur en de omgeving(en) beschreven waarin de
koppeling zal draaien in termen van gebruikte IP adressen, URI’s, PKIoverheid
certificaten en OIN’s. Hiermee beschikken de verschillende betrokken partijen over
eenduidige informatie over de technische inrichting van de connectiviteit,
infrastructuur en omgeving waar de koppeling draait en de keten waarvan deze
onderdeel is.
3.2
Platform en koppeling eisen
Voor elke koppeling of applicatie zijn standaard eisen van toepassing, gebaseerd op
het onderliggende Standaard Platform. Deze eisen zijn opgenomen in een aantal
IMEA katernen en eisen documenten, zie 1.3 Referenties.
Pagina 10 van 13
Definitief | Beheerst naar beheer | Versie 1.0
4
Oplevering leverancier
Dit hoofdstuk beschrijft de deliverables die IenM verwacht bij elke oplevering door
een leverancier. Hierbij is een opdeling gemaakt in documentatie en software
deliverables.
4.1
Documentatie deliverables
4.1.1
Functioneel ontwerp
In het functioneel ontwerp worden de User stories vertaald naar functionele
requirements en afgestemd met IenM. Indien de requirements voor een deel reeds
zijn opgenomen in een scope document, dan worden deze in het FO verder
aangescherpt en uitgewerkt.
4.1.2
Technisch ontwerp
In het technisch ontwerp worden de functionele requirements gemapped op de
technische implementatie. Op deze manier wordt afgedwongen dat de oplossing aan
alle gestelde eisen voldoet.
4.1.3
Provisioning handleiding
De provisioning handleiding beschrijft eventuele handmatige stappen die nodig zijn
om de koppeling of applicatie te kunnen uitrollen. De IenM ketenbeheerder is hierbij
de verantwoordelijke partij en stuurt waar nodig de technisch beheerder van de
hosting partij aan.
4.1.4
Testaanpak
In de testaanpak beschrijft de leverancier hoe de applicatie getest zal worden, welke
testen de leverancier zelf kan uitvoeren en eventueel welke testen nog door IenM
uitgevoerd dienen te worden.
4.1.5
Systeem testrapport
Het systeem testrapport bevat de resultaten van de systeemtest door de
leverancier.
4.1.6
Beheerhandleiding
De beheerhandleiding bevat alle noodzakelijke achtergrond informatie en instructies
om de koppeling of applicatie goed in beheer te kunnen nemen. Waar nodig kan
worden verwezen naar generieke beheeractiviteiten zoals beschreven in de
generieke beheerhandleidingen van de diverse platform componenten, zoals de ESB.
4.1.7
Koppelvlakhandleiding
De koppelvlakhandleiding bevat alle noodzakelijke informatie en instructies voor
afnemers om gebruik te kunnen maken van het koppelvlak. Dit is een zelfstandig
leesbaar en te gebruiken document en moet alle benodigde informatie bevatten om
gebruik te maken van het koppelvlak.
4.1.8
Performance testrapport
Het performance testrapport beschrijft de resultaten van de performance test zoals
deze is uitgevoerd door de leverancier.
Pagina 11 van 13
Definitief | Beheerst naar beheer | Versie 1.0
4.1.9
Release notes
Tijdens elke release worden release notes opgeleverd die de specifieke
aandachtspunten en wijzigingen t.o.v. de voorgaande release beschrijven.
4.2
Software en scripts deliverables
4.2.1
Software component
Het software component is de verzameling installatie artefacten die de
implementatie van de gevraagde oplossing vormen.
4.2.2
Source code
De meegeleverde source code dient te voldoen aan de door IenM gestelde eisen en
dient door IenM te compileren zijn.
4.2.3
Unit tests
De meegeleverde unit tests dienen te voldoen aan de door IenM gestelde eisen,
zoals code coverage, en dienen ook door IenM uitvoerbaar te zijn.
4.2.4
Functionele testscripts
De leverancier dient functionele testscripts mee te leveren die automatisch uit te
voeren zijn. Deze dienen o.a. te voldoen aan de test coverage eisen.
4.2.5
Koppeling en backend test suite
Voor alle koppelingen en backend systemen dienen functionele tests in de vorm van
SoapUI test suites opgeleverd te worden. Deze dienen o.a. te voldoen aan de test
coverage eisen.
4.2.6
Performance testscript
Naast functionele tests dienen ook de door de leverancier uitgevoerde performance
testscripts aangeleverd te worden.
4.2.7
Smoke testscript
Na het uitrollen op preproductie en productie wordt door de beheerder een smoke
testscript uitgevoerd om te testen of de versie correct werkt. Van belang is dat dit
script geen wijzigingen in productie data veroorzaakt.
Pagina 12 van 13
Definitief | Beheerst naar beheer | Versie 1.0
5
Acceptatie IenM
Dit hoofdstuk beschrijft de stappen die IenM doorloopt tijdens het acceptatieproces
en de deliverables die tijdens dit proces worden opgeleverd.
5.1
Ingangscriteria
Een koppeling of applicatie wordt pas uitgerold nadat de leverancier alle deliverables
heeft opgeleverd en deze door IenM zijn gereviewd en geaccepteerd. Het uitrollen
gebeurt onder verantwoordelijkheid van de IenM ketenbeheerder, die waar nodig de
technisch beheerder van de hosting partij aanstuurt.
5.2
Deliverables
5.2.1
Functionele accepatie test rapport
IenM voert een Functionele Acceptatie Test (FAT) uit en verwerkt de resultaten in
het FAT rapport.
5.2.2
Gebruikers acceptatie test rapport
Indien relevant voert IenM ook een Gebruikers Acceptatie Test (GAT) uit en
verwerkt de resultaten in het GAT rapport.
5.2.3
Acceptatietest resultaat
De deliverable Acceptatietest resultaat is de formele goedkeuring of afkeuring van
de release in de acceptatieomgeving en is gebaseerd op de conclusies uit het FAT en
GAT rapport. In het geval van goedkeuring kan de release worden uitgerold naar
preproductie en productie, in het geval van afkeuring wordt de release teruggerold
en de oplevering afgewezen.
5.2.4
Restpuntenlijst
De restpuntenlijst beschrijft de bevindingen van de FAT en GAT die niet blokkerend
waren voor de uitrol naar productie, maar nog wel in de volgende release opgelost
dienen te worden.
5.2.5
Wijzigingenlijst
De wijzigingenlijst bevat extra wensen die tijdens de FAT en GAT naar voren zijn
gekomen, maar die geen onderdeel waren van de originele scope. Deze dienen als
input tijdens het vaststellen van de requirements voor de volgende release.
5.2.6
Decharge
Nadat een release twee weken zonder verstoring in productie heeft gedraaid, wordt
formeel decharge verleend door middel van het decharge rapport.
Pagina 13 van 13

Download Report