Document D-2 Ministerie van Infrastructuur en Milieu Beheerst naar beheer Versie 1.0 Datum 15 juli 2014 Status Definitief
Colofon Versie 1.0 Contactpersoon Paul Leunissen M 06-5250 6691 Paul.Leunissen@minienm.nl 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
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
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
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
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
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
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 4.1.4 Testaanpak 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. 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
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 4.2.3 Unit tests De meegeleverde source code dient te voldoen aan de door IenM gestelde eisen en dient door IenM te compileren zijn. 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
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 5.2.6 Decharge 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. 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