Plan van Aanpak Pilot



Vergelijkbare documenten
Ministerie van Infrastructuur en Milieu Beheerst naar beheer

Aanscherpen en doorontwikkelen compliancy (eisen)

Digikoppeling adapter

Draaiboek Invoering Basisregistratie Personen l Afnemers

Digitale bereikbaarheidskaart

Roadmap BIM Loket. Versie 7, 1 december Inleiding

Betere besluitvorming bij crisis en ramp door betere informatiepositie

Strategie Applicatie integratie Open.Amsterdam project. versie 1.0 juni 2008

Je weet wat je wilt bereiken, maar wie & wat loop je tegen het lijf?

Voorwaarden StUF Testplatform

PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D

VERA 3.0. Bijlage E.1 Implementatieplan koppelingen. Versie: 3.0 Datum: Status: Definitief

Omschrijving. Technische context

Ontwikkelen & Beheren van testomgevingen is ook een vak!

ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden

Intake <applicatie> Conclusie & Aanbevelingen. <Datum> 1.0. <Auteur> ###-#######

Marktscan Digikoppeling 2017

Checklist basisontwerp SDM II

PROJECTVOORSTEL PILOT KOPPELVLAKKEN RSGB BEVRAGINGEN NIEUWE STIJL

Inhoud. Deel een Het ontwikkeltraject 13. Inleiding 11

De impact en implementatie van de outsourcing op de bedrijfsvoering is als één van de 6 deelprojecten ondergebracht binnen het project outsourcing.

Ontwikkelingen rondom transparantie, compliancy en StUF Testplatform

J-STD-016. Documentatiestandaard

Beoordelingsformulieren: Uitleg Beoordeling. A: Is in ontwikkeling, maar nog niet op het reproductieve niveau

Onboarding Traject 04 oktober 2017

Plan van Aanpak. project Tetris Packing

ADDENDUM. Regie- en Zaakservices 1.0. Kwaliteitsinstituut Nederlandse Gemeenten. Leveranciers. tussen KING en Leveranciers

Leveranciers bijeenkomst

Sturing op standaardisatie op weg naar gegevenslandschap. Regiegroep gegevens en berichtenstandaarden 3 oktober 2018

Opleidingsgebied ICT. 2 e beoordeling: Eindbeoordeling:

PROJECT: IRIS-WEB. (Plan van aanpak)

Proof of Concept standaard voor omgevingsdocumenten

Ontwikkelaar ICT. Context. Doel

Vault Easy Best Practice voor AutoCAD

INTERPRETATIEDOCUMENT vastgesteld door het CCvD Bodembeheer

Prototype/Usability testverslag

1. Work Breakdown Structure en WBS Dictionary

Portal Planning Process

Inhoud Deel een Het ontwikkeltraject 1 2 3

Implementatie iwlz 1.1. Diemen 10 juli 2015

Bijlage 3: Master testplan

Werkgroep CORV 22 juni 2015

HERGEBRUIK VAN REQUIREMENTS

Project Fasering Documentatie ICT Beheerder. Auteurs: Angelique Snippe Tymen Kuperus

Handleiding voor aansluiten op Digilevering

Persoonlijk Actieplan (PAP)

ADDENDUM. Regie- en Zaakservices 1.0. Kwaliteitsinstituut Nederlandse Gemeenten. Leveranciers. tussen KING en Leveranciers

Procesvalidatie voor een veiliger ketentest

Verificatie & Validatie

Traditioneel vs. Best Value. Gemeente Groningen en Gouw IT 2 oktober 2014, Best Value Event Noord-Nederland

SAMENWERKINGSCONVENANT REALISATIE NIEUWE KOPPELVLAKSTANDAARDEN VOOR BEVRAGEN VAN BASISGEGEVENS TUSSEN GEMEENTE DEN HAAG

PRORAIL PoC Protocol MFP s en grootformaatprinters

Checklist IPv6 Implementatie

Workshop 12 ART-DECOR en Acute overdracht. Michael Tan Kai Heitmann Maarten Ligtvoet

Functiebeschrijving Technische Architect

BeheerVisie ondersteunt StUF-ZKN 3.10

EENDUIDIG VASTLEGGEN EN UITWISSELEN VAN MEDICATIEGEGEVENS VOOR VEILIG MEDICIJNGEBRUIK

Operatie BRP Resultaten en stand van zaken

UWV Testservice. Resultaatgerichte invoering van een adaptief procesmodel

ADDENDUM. Transitie Jeugd: Aansluiting en gebruik CORV. Kwaliteitsinstituut Nederlandse Gemeenten. Ministerie van Veiligheid en Justitie.

Project Fasering Documentatie Applicatie Ontwikkelaar

Testplan IpMEDT3 project

Ansur & Apparatuurbeheer. Hans Schop. Wat doe ik binnen medische technologie? Vision meets Precision. Vision meets Precision

TROWA. Visie en scope Informatiemodel Waterschapsverordening. Datum : : 2.0, definitief

Offerte / Gemeente Breda / Versie 2.0

Mijnbuur opvolger van Burgernet in Twente

DYNAMIC INFRASTRUCTURE Helping build a smarter planet

Vernieuwing VMS ICT oplossing v0.1

Testrapport Kiezen op Afstand Inhoudelijke Stresstest

Inlichtingenbureau Voortgangsrapportage April Realisatie van het Sectorloket-systeem

Uitstroom + Crebonummer Applicatie- en mediaontwikkelaar; Crebonummer Niveau Niveau 4

Project Plan van Aanpak. Naam project:

Checklist testen WOZ-inzage MijnOverheid

Inlichtingenbureau Voortgangsrapportage Juni Realisatie van het Sectorloket-systeem

Implementatieplan Doorontwikkelen BRON vavo. vavo inwinnen. Versie 0.9, 20 maart Implementatieplan Doorontwikkelen BRON vavo 1

Casemanagement bij kankerpatiënten

bedrijfsinformatie VERSLAG BEZOEK FINLAND 21 februari 2017 d.d. 27 februari 2017

Adviesrapport. Procedurebeschrijvingen. VICtor beheer

Software Test Plan. Yannick Verschueren

Roadmap gemeenten, praktijkproeven & leveranciersbetrokkenheid

Toetsdocument. Geonovum. Certificering BGT IMGeo bronhoudersoftware. datum 1 maart versie 1.2. status publiek

Resultaten versnellingskamer. PGO regio Friesland. Alliade/Meriant & Tjongerschans initiators in de regio

Bijlage II: Documentatie

BelRAIgebruiksvoorwaarden. softwareontwikkelaars

RLBS (robbert Location based services)

Kwaliteitsbewaking en testen in ICT beheerorganisaties

DigiNotar certificaten

Efficiency door de BRP?

IP Businessmanager voor gevorderden

Factsheet Ontwikkeling generiek Individueel Zorgplan

Opzetten van het Nederlands Medicatie Verificatie Systeem

Afbeelding: TriamFloat Effectmetingsmodel

Wij testen..maar....wat test jij?

Van papier naar digitaal

24 November Opzetten van het Nederlands Medicatie Verificatie Systeem

Wil Haasdijk Instituut Fysieke Veiligheid

Papierloos Vergaderen Gemeente Brummen

ONS AANKONDIGINGEN Nedap healthcare Deze PDF is gegenereerd op

ADDENDUM: betreffende het ontwikkelen, aansluiten, integreren en gebruiken van standaarden voor decentralisaties in het sociaal domein.

Transcriptie:

Plan van Aanpak Pilot DBK-applicaties Beproeven compatibiliteit DBK-applicaties op innovatieplatform voor de Veiligheidsregio s Status : concept Versienummer : V0.2 Datum : Augustus 2012

Blad : 2 / 6 Inhoudsopgave 1. DEFINITIE PILOT... 3 1.1. DOELSTELLING VAN DE PILOT... 3 1.2. CONTEXT VAN DE PILOT... 3 2. AANPAK PILOT... 4 2.1. DEELNEMERS PILOT... 4 2.2. RANDVOORWAARDEN EN UITGANGSPUNTEN... 4 2.3. BEGRENZING PILOT... 4 3. REALISATIE PILOT... 5 3.1. UIT TE VOEREN STAPPEN PILOT... 5 3.2. OP TE LEVEREN PRODUCTEN EN DIENSTEN... 5 3.3. INITIËLE PLANNING... 6 3.4. BENODIGDE CAPACITEIT... 6

Blad : 3 / 6 1. Definitie pilot 1.1. Doelstelling van de pilot Doel is uiteindelijk het ontwikkelen van een objectieve testomgeving om de interoperabiliteit tussen Digitale Bereikbaarheids Kaart (DBK)-applicaties 1 te borgen en objectief vast te stellen dat de applicaties voldoen aan de gestelde (functionele) eisen. In de eindsituatie krijgen de softwareleveranciers van DBK-applicaties de mogelijkheid hun applicatie te testen tegen een DBK referentieomgeving op het innovatieplatform en kunnen bij een positief testresultaat aantonen dat de applicatie voldoet aan de eisen en samenwerkt met ander DBK-applicaties. In de pilot gaat het er om, te bepalen: of het testen van DBK applicaties van leverancier X tegen een DBK referentie van leverancier Y werkt; welke problemen daarbij aan het licht komen en of die voor de leveranciers bruikbare feedback vormen; wat er nodig is om in de toekomst zo n DBK referentieomgeving succesvol in te richten en in de lucht te houden; hoe dit soort testen in de toekomst georganiseerd moeten worden: welke testen zijn relevant, hoe die uit te voeren en te beoordelen, wat het vraagt van de leverancier, etc. Standaardisatie is belangrijk binnen het OOV-domein. Het gaat daarbij zowel om standaarden op bv. het gebied van architectuur (voldoen aan de Veiligheidsregio Referentie Architectuur) als op het gebied van gegevensuitwisseling (voldoen aan het informatiemodel DBK en/of OOV). De standaarden worden besproken en vastgesteld binnen de OOV-sector. Aan leveranciers die functionaliteit (applicaties) leveren wordt de eis gesteld dat zij voldoen aan deze standaarden. Het is belangrijk dat leveranciers middels een objectieve test kunnen aantonen dat zij aan de hiervoor gestelde eisen kunnen voldoen. Het is de bedoeling dat er een innovatieplatform veiligheidsregio s komt. Om te bepalen welke maatregelen hiervoor nodig zijn wordt een pilot uitgevoerd met leveranciers van twee DBK-applicaties, te weten Falck AVD en Nieuwland. 1.2. Context van de pilot De aanbesteding van DBK binnen de veiligheidsregio s laat zien dat regio's nog zoekende zijn t.a.v. wat ze van DBK applicaties mogen verwachten. Met name wat onder de motorkap gebeurt, is voor regio s zelf niet te beoordelen. Dat geldt nu maar ook zodra er nieuwe versies van de DBK applicaties uitkomen. Daarom wil NVBR een eenduidige en representatieve testomgeving, om vast te stellen dat applicaties voldoen aan de zgn conformiteitstoets, die gebaseerd is op de landelijke standaarden: programma van eisendbk, programma van eisen DBK dataserver, Informatiemodel DBK en berichtenspecificaties. NB: Het informatiemodel DBK 2.1 is opgeleverd. Vervolgens moeten de applicaties hier nog op worden aangepast. Leveranciers zijn betrokken geweest bij gesprekken met Geonovum over aanpassing van het informatiemodel en zijn dus al op de hoogte van de wijzigingen. Dit moet implementatie vergemakkelijken. 1 Zowel maken/beheren applicaties als (mobiele) gebruiksapplicaties en de DBK dataserver

Blad : 4 / 6 2. Aanpak pilot 2.1. Deelnemers pilot Er zijn vier partijen betrokken bij de pilot: Falck AVD en Nieuwland als softwareleveranciers van DBK-applicaties. Zij bieden hun applicatie(s) aan om te testen op het i-bridge platform en werken actief mee aan het testen. De leveranciers behouden zelf het intellectueel eigendom op hun eigen product. Veiligheidsregio s. Zij spelen een rol bij het beoordelen van de testresultaten. Dit op uitnodiging van NVBR. Projectteam innovatieplatform. Het projectteam innovatieplatform faciliteert het testen van de applicaties op het innovatieplatform. Zij faciliteert de testomgeving en de technische en organisatorische ondersteuning van de testen. Zij vertaalt technische opmerkingen van de leveranciers (over de testopzet, testen, omgeving, etc) naar voor NVBR hanteerbare observaties, conclusies en aanbevelingen. NVBR. De NVBR is opdrachtgever voor de pilot en voert regie over het geheel. Zij laat de testresultaten valideren (bijv door testers namens regio's), geeft aan welke mogelijke aanpassingen er aan het i-bridge platform en/of de geteste applicaties nodig zijn. Dit mede op basis van de reacties van de softwareleveranciers, het projectteam innovatieplatform en de regio s. 2.2. Randvoorwaarden en uitgangspunten Voor de realisatie van de pilot worden de volgende randvoorwaarden en uitgangspunten gehanteerd: Zowel server-serververkeer als applicatie-serververkeer zullen worden getest. Als ring testen, dus ook app-app. De (server)applicaties worden bij voorkeur op de testserver van het innovatieplatform geïnstalleerd en in een enkel geval virtueel (bijv. de serversoftware van de leveranciers). Voor de DBK server is geen test/verificatie van de installatiehandleiding nodig want het uitgangspunt is dat de veiligheidsregio s de installatie door leveranciers laten doen. Voor de DBKgebruiksapplicatie/user interfaces dient de installatiehandleiding/procedure wel getest te worden binnen het innovatieplatform, aangezien installatie hiervan t.z.t. door de veiligheidsregio s zelf plaats zal gaan vinden. In de pilot wordt IMDBK-versie 2.1 gebruikt, uit de pilot kan blijken dat er een 2.2-versie moet komen. 2.3. Begrenzing pilot De pilot beperkt zich tot het uitvoeren van een test met twee leveranciers van DBK-applicaties om de toegevoegde waarde van het innovatieplatform als testplatform 2 te beproeven. Evaluatie van de pilot kan mogelijk leiden tot een meer structurele aanpak van het testen van DBK-applicaties. Dit valt niet binnen de scope van de pilot. 2 Platform in de brede zin van het woord, niet beperkt tot het technische systeem

Blad : 5 / 6 3. Realisatie pilot 3.1. Uit te voeren stappen pilot De volgende stappen moeten worden doorlopen voor een succesvolle pilot: Het voeren van inhoudelijk overleg over: o De te hanteren specificaties, standaarden etc. die moeten worden gebruikt om de applicaties te kunnen testen op het platform o De te hanteren processen en procedures bij het testen o De wijze waarop de pilot zal worden geëvalueerd Technisch overleg tussen de leveranciers en het projectteam innovatieplatform om vast te stellen wat er aan beide kanten moet gebeuren om de test te laten plaatsvinden Het daadwerkelijk uitvoeren van de test Het beoordelen van de testresultaten in samenspraak met de leveranciers en de veiligheidsregio s Het opstellen van een evaluatierapport m.b.t. de resultaten van de pilot. 3.2. Op te leveren producten en diensten De volgende producten en diensten dienen te worden opgeleverd in de pilot Product/Dienst Omschrijving Verantwoordelijke Beschrijving startsituatie pilot Beschrijving van de te hanteren specificaties, standaarden etc. en de te hanteren processen en procedures voor de pilot Beschrijving evaluatiecriteria Testplan Test Testrapport pilot Beschrijving van de evaluatiecriteria die zullen worden gebruikt om de pilot te evalueren Beschrijving testplan - Welke activiteiten incl. planning - Typen testen - Testscenario s - Wie doet wat en wie is waarvoor verantwoordelijk - Gerealiseerde test DBK-applicatie Falck AVD en Nieuwland op basis van testplan Beschrijving testrapport - Beschrijving testresultaten per uitgevoerde activiteit - - Te nemen maatregel per opgeleverd testresultaat - Evaluatie op basis van evaluatiecriteria - Voorstel vervolgactiviteiten

Blad : 6 / 6 3.3. Initiële planning Product/Dienst Omschrijving Betrokken deelnemers Beschrijving Beschrijving van de te hanteren startsituatie pilot specificaties, standaarden etc. en de te hanteren processen en Beschrijving evaluatiecriteria Testplan Test Testrapport pilot procedures voor de pilot Beschrijving van de evaluatiecriteria die zullen worden gebruikt om de pilot te evalueren Beschrijving testplan - Welke activiteiten incl. planning - Wie doet wat en wie is waarvoor verantwoordelijk Gerealiseerde test DBK-applicatie Falck AVD en Nieuwland op basis van testplan Beschrijving testrapport - Beschrijving testresultaten per uitgevoerde activiteit - Te nemen maatregel per opgeleverd testresultaat - Evaluatie op basis van evaluatiecriteria - Voorstel vervolgactiviteiten Datum oplevering 3.4. Benodigde capaciteit Product/Dienst Omschrijving Benodigde capaciteit Beschrijving Beschrijving van de te hanteren specificaties, standaarden etc. 40 uren startsituatie pilot en de te hanteren processen en procedures voor de pilot Beschrijving Beschrijving van de evaluatiecriteria die zullen worden 20 uren evaluatiecriteria gebruikt om de pilot te evalueren Testplan Beschrijving testplan 16 uren - Welke activiteiten incl. planning - Wie doet wat en wie is waarvoor verantwoordelijk Test Gerealiseerde test DBK-applicatie Falck AVD en Nieuwland op basis van testplan n.t.b. in overleg met Falck AVD en Nieuwland Testrapport Beschrijving testrapport 40 uren pilot - Beschrijving testresultaten per uitgevoerde activiteit - Te nemen maatregel per opgeleverd testresultaat - Evaluatie op basis van evaluatiecriteria - Voorstel vervolgactiviteiten 40 uren