Bronhouderportaal BRO sprintreview Sprint 18 Bulk & Info-release Verslag
Aanwezig in deze Sprintreview 1. Robin van den Assem (Hoogheemraadschap Delfland) 2. Marjan Bevelander (plv programmamanager BRO) 3. Henk Ferkranus (SvB-BGT, coördinator regio Noord) 4. Janko van Gelderen (Provincie Utrecht, grondwaterspecialist) 5. Marc de Goede (TNO, data manager) 6. Theo Gülcher (ICTU, softwareontwikkelaar) 7. Jippe Holwerda (ICTU, softwareontwikkelaar) 8. Tom Koenraads (ICTU, functioneel ontwerper) 9. Sandra Kramer (TNO, coördinator BRO Servicedesk) 10. Olaf Lem (Waterschap Rivierenland, coördinator ondergrond) 11. Bart-Jan de Leuw (Programmabureau BRO, ketenintegratiemanager) 12. Marcel Maasbommel (Wareco, senior adviseur Water) 13. Ad Meinster (TNO, data manager) 14. Tom Moesker (ICTU, product owner en projectmanager) 15. Ruud Mutsaers (TNO, accountmanager) 16. Tessa Schel (TNO, BRO Servicedesk) 17. Matthijs van Schooten (Munisense, programmeur) 18. Eric Simmelink? (TNO, coördinator grondwater) 19. Johan Stöver (ICTU, scrum master en softwareontwikkelaar) 20. Henriëtte Villevoije (Rijkswaterstaat, coördinator ondergrond) 21. Wilfred Visser (TNO, geoscientific software engineer) 22. Ria Volkers (Programmabureau BRO, ketenmanager) 23. Hans van der Ven (TNO, productmarketingmanager) 24. Caja van der Woude (Gemeente Amsterdam, coördinator BRO) 25. Erik van der Zee (Programmabureau BRO, ketenarchitect)
Agenda 12.00u Inloop en welkom en lunch 12.15u Releasedoelen en voortgang 12.30u Terugblik afgelopen Sprint - Demonstratie opleveringen - Bespreking van het resultaat 13.15u Vooruitblik komende Sprint(s) - Prioriteiten bepalen -Uitwerking belangrijkste wensen 14.30u Afsluiting - Samenvatting conclusies & afspraken - Korte evaluatie van deze review 15.15u Ruimte voor nabesprekingen Oproep Wie heeft nu of binnenkort al échte CPT-, GMWof BHR-p-ondergrondgegevens beschikbaar en wil graag begeleiding bij het aanleveren? Kalender di 27 mrt Sprintreview nr.19 (Den Haag) di 17 apr Sprintreview nr.20 di 08 mei Sprintreview nr.21 (Utrecht?) di 29 mei Sprintreview nr.22 (laatste) Tijd 12-16u Locatie Amersfoort, Utrecht of Den Haag Tussendoor: korte koffiebreaks.
1 DOELEN KOMENDE RELEASE DOOR DE PRODUCT OWNER
Voorlopige indeling Doelen Release 1.22 (voorheen: Release 4) Release 4 Algemeen doel Oplevering Basale invulling van alle nu nog openstaande wensen 1 juni 2018 (met tussenreleases in februari en april) week datum locatie sprintnr. hoofdsprintdoel (naast andere opleveringen) 04 di 23 jan Amersfoort #16 Aanleveren in bulk mogelijk maken 07 di 13 feb Utrecht #17 Meer informatie op het scherm 10 di 06 mrt Utrecht #18 Tussenrelease 1.18: Bulk & Info 13 di 27 mrt Den Haag #19 Nieuwe koppelingen 16 di 17 apr #20 Notificaties via de mail 19 di 08 mei Utrecht? #21 Tussenrelease 1.21: Koppelingen & notificaties 22 di 29 mei #22 Zoeken, rapporteren en archiveren 22 vr 01 jun Finale release 1.22: Finale oplevering Elke derde sprint gaat er een (tussen)release in productie
Doelen Release 1.22 Voorlopige indeling Nr. hoofdsprintdoel (naast andere opleveringen) Wat zit daar onder anderen in? #16 Aanleveren in bulk mogelijk maken Bulk upload én download #17 Meer informatie op het scherm Voorpagina, leveringshistorie, berichtenbanner, betere teksten #18 Tussenrelease: Bulk & Info Gerealiseerde verbeteringen in productie brengen #19 Nieuwe koppelingen Automatische koppelingen met (indien beschikbaar): de nieuwe syntax-validatieservice, een 1 e gegevensleverancier, AAT, grafische viewer. #20 Notificaties via de mail Validatie van mailadres, mailnotificatie bij uit te voeren taak en als termijn verloopt. #21 Tussenrelease: Koppelingen en notificaties Gerealiseerde verbeteringen in productie brengen #22 Zoeken, rapporteren en archiveren Zoeken naar, rapporteren over en archiveren van: organisaties, projecten, leveringen, bestanden, accounts, machtigingen en autorisaties.
2 TERUGBLIK AFGELOPEN SPRINT DOOR HET ONTWIKKELTEAM
Bronhouderportaal in cijfers Sprint 16 17 18 19 20 21 22 Peildatum 19 jan 13 feb 6 mrt 27 mrt 17 apr 8 mei 29 mei Maximum Aangemelde organisaties 50 59 69 # gemeenten 24 32 39 380 # waterschappen 9 9 9 22 # provincies 8 8 8 12 # andere bronhouderorganisaties 4 4 4 ±150 # organisaties die geen bronhouder zijn 5 6 9 - Actieve gebruikers 17 35 53 - # gebruikers met eherkenning 17 28 39 - # gebruikers met lokaal account 0 7 14 - Inrichting en gebruik # projecten 3 11 18 - # autorisaties van gebruikers 84 120 168 - # machtigingen voor bedrijven 0 2 4 - # leveringen aangeleverd 2 3 6 - # leveringen doorgeleverd 0 1 1 - De stand na 2 maanden: Voldoende aanmeldingen, maar we willen nu graag ook meer ondergrondgegevens écht zien doorgeleverd aan de BRO. Wees daarom de eerste in je categorie verdien een heerlijke hazelnootschuimtaart! Vraag naar de voorwaarden. -
Gerealiseerd in deze sprint Software 1. BBRO-1022 Herstel van nog openstaande kleine bevindingen Story: Als Tester wil ik graag eerder gemelde kleine bevindingen zoveel mogelijk opgelost hebben zodat ik ze bij de volgende testronde niet opnieuw tegenkom en opnieuw moet melden. 2. BRO-1028 Toelichting kunnen opvoeren bij elke processtap (in plaats van alleen bij aanlevering zoals nu het geval is) Story: Als gebruiker wil ik bij elke stap in de afwikkeling van een levering een toelichtingstekst kunnen toevoegen zodat ik voor mezelf en andere gebruikers relevante opmerkingen kan vastleggen. 3. BBRO-1018 Doorlooptijden tonen per processtap in de levering Story: Als Product Owner wil ik per stap in de afwikkeling van een levering de doorlooptijd vastleggen en tonen zodat (1) Gebruikers feedback krijgen over knelpunten in de afwikkeling, (2) vermeende traagheid bij automatische processtappen met cijfers is aan te tonen en (3) een basis is gelegd voor het genereren van doorlooptijd-statistieken voor maandrapportages. 4. BBRO-1027 Bewijs van levering kunnen printen Story: Als Leverancier wil ik van leveringsdetails die ik op het scherm zie vanuit mijn browser een goed leesbare print kunnen maken (in pdf of op papier) zodat ik die buiten het Bronhouderportaal om kan gebruiken als bewijs van geleverd werk. Besluit: Deze wenst krijgt extra prioriteit en een eerste basale implementatie moet zeker mee in de komende release. 5. BBRO-1029 Verschillende instanties van de applicatie beter van elkaar kunnen onderscheiden Story: Als Tester en als Bouwer wil ik direct kunnen zien in welke omgeving ik werk (in Acceptatie, Demonstratie of Productie) zodat er geen misverstanden ontstaan over op welke instantie mijn testbevinding betrekking op heeft. 6. BBRO-1023 Doorleveren aan LV BRO robuust maken tegen verstoringen Story: Als Bouwer wil ik de afhandeling van doorleveringen naar LV BRO robuust maken tegen verstoringen zodat een doorlevering na verloop van tijd altijd lukt, ook al ligt de verbinding er tussentijds tijdelijk uit. 7. BBRO-1093 Oplevering van een tussenrelease van de applicatie (De zogeheten: Bulk & Info-release) Story: Als Gebruiker wil ik kunnen beschikken over de nieuwste versie van het Bronhouderportaal met releasenotes en handleiding zodat ik niet tot eind mei hoef te wachten voor ik de verbeteringen en uitbreidingen kan gebruiken.
Gerealiseerd in deze sprint Documentatie BBRO-957 Software Architecture Document (SAD) bij applicatieversie 1.18 Story: Als opdrachtgever wil ik kunnen beschikken over documentatie zodat ik inzicht heb in wat er is gebouwd en met welke architectuur. BBRO-961 Gebruikshandleiding bij applicatieversie 1.18 Story: De handleiding moet in lijn zijn met de nieuwe versie in de applicatie.
Niet gerealiseerd in deze sprint BBRO-954 Mailadres valideren via mailnotificatie met validatiecode (testopstelling) Story: Als Product Owner wil ik dat gebruikers zelf hun mailadres kunnen valideren via een code die ze in hun mailbox ontvangen zodat de basis is gelegd voor het inrichten van notificaties die Gebruikers via de mail wensen te ontvangen. Als gevolg van griep in de teams verdaagd naar een volgende sprint.
Releasenotes tussenrelease Bulk & Info De opleveringen van Sprint 17 en 18 zijn nu in productie gegaan. Dat betekent: Nieuw in deze release Verwijzing naar helpinformatie op de startpagina; Meerdere bestanden tegelijk in één levering kunnen uploaden; Meerdere bestanden tegelijk kunnen downloaden voor controles; Storingsbestendigere afhandeling van grotere leveringen; Toelichting toevoegen nu bij elke stap in de levering; Alle stappen in een levering kunnen terugzien, mét doorlooptijden; Details van een levering kunnen printen (naar papier of pdf); Duidelijker keuzemenu bij toekenning van rollen aan gebruikers. En dan nu: Demonstratie...
Nieuwe release, vernieuwde homepagina
Bespreking na demonstratie 1. Als (beginnend) gebruiker zie je niet goed welke stappen je kunt doen en hoe de informatie die je op het scherm ziet je daar bij kan helpen. Je wil betere begeleiding op het scherm. A: Dit werd de afgelopen sprints al vaker genoemd. De uitleg staat in de handleiding. Maar los daarvan is dit iets waar we nog eens naar moeten kijken, want je wilt uiteindelijk een intuïtief werkende applicatie. Actie ICTU. 2. Voor een organisatie die net begint zijn het veel rollen om te verdelen. Wellicht zijn die in één persoon te verenigen. A: Geen probleem. De applicatie ondersteunt dit, al zien de schermen er dan wat complexer uit. 3. De positionering van de knoppen goedkeuren en afkeuren die je kunt kiezen zijn wat verwarrend ver uit elkaar gezet. A: Dit is bewust gedaan zodat je niet te makkelijk per ongeluk de verkeerde knop indrukt. 4. We missen het BRO-ID in de printbare leveringsdetails, terwijl dat een belangrijk gegeven is. A: Dit is wat lastiger geworden omdat in een bulkaanlevering met daarin meerdere bestanden nu meerdere BRO-IDs te tonen zijn, misschien wel 100 of 1.000 stuks. We gaan kijken wat de beste oplossing is. Actie ICTU. 5. De leveringshistorie zit nu té laag in het detailoverzicht. Als je honderd bestanden hebt moet je te veel scrollen. A: Eens. En dit kunnen we gelukkig makkelijk oplossen door dit segment hoger in het overzicht neer te zetten. BBRO-1102 6. De homepagina is nu minder strak geworden doordat er meer tekst op staat. A: Maar die tekst voorziet in een behoefte. Hier is in de vorige sprint juist om gevraagd. De tekst is zo kort als mogelijk. 7. Wie kan nu aangeven of het printbare bonnetje goed is? A: Dat kunnen we hier samen proberen te bedenken maar is uiteindelijk aan de leveranciers om aan te geven. 8. Het Referentie -veld roept vooral vragen op: Wat betekent dit en waar is het voor bedoeld? Het is niet duidelijk. A: Dat is eigenlijk niemand in de zaal duidelijk. Iets om na te vragen bij degenen die dit bedacht hebben. 9. Hoe kun je leveringen inzien? Is daar een viewer voor? A: Die viewer is geen onderdeel van het portaal. Je kunt daarover met het programmabureau (Ria) afstemmen. 10. Waarom verschillende tijdseenheden in de verschillende stappen in de levering? A: Dat is afgestemd op de tijdsduur. Als de stap seconden duurde is dat ook de eenheid. Uren tonen we in uren, etc. We kunnen de weergave qua tekst nog wat compacter te maken zodat die minder snel verspringt. Actie ICTU. 11. De reacties gaan zo langzamerhand wel over details. Laten we de applicatie nu in gebruik nemen en in de praktijk ontdekken wat goed werkt en wat beter kan.
4 BACKLOG SORTEREN ALLEN
Toelichting bij de backlog De backlog beschrijft openstaande wensen. Dat kan gaan om nieuwe functies, maar ook om bevindingen met reeds bestaande functies. Op dit moment is de backlog ingedeeld in vier categorieën: Prio 1. Noodzakelijk om snel te realiseren We weten al dat dit snel opgepakt moet en kan worden. Hier willen we vandaag liever niet te lang meer bij stil staan. Prio 2. Nieuw te realiseren zodra het kan Dit zijn belangrijke nieuwe functies, maar om te kunnen starten hebben (of hadden) we te maken met afhankelijkheden. Prio 3. Te verhelpen zodra het kan Dit zijn belangrijke bevindingen of verbeterwensen, maar we hebben (of hadden) te maken met afhankelijkheden. Prio 4. Top-20 overige prioriteiten Dit zijn in de Sprintreview regelmatig genoemde wensen. Welke zullen pakken we het eerst op en waarom juist die? In veel gevallen is er nog nadere afstemming nodig over het exacte ontwerp. In de pagina s hierna worden de volgende kleurencodes gebruikt: BBRO-9999 Deze wens heeft al een nummer gekregen om aan te geven dat het team er direct mee kan beginnen. Te ontwerpen Deze wens heeft nadere afstemming met gebruikers nodig om precies te bepalen wat hier nodig is. Wachten Eventuele verdere ontwikkeling is in afwachting van besluitvorming of opleveringen elders.
Prio 1. Noodzakelijk om snel te realiseren De volgende wensen betreffen gewenste automatische koppelingen met andere systemen. Deze koppelingen hebben prioriteit, maar zijn pas realiseerbaar als de te koppelen systemen ook beschikbaar zijn om mee te testen: 1. BBRO-1081 Schakelknop voor aan/uitzetten nieuwe functionaliteit ( feature toggle ) Story: Als Product owner wil ik kunnen kiezen welke functionaliteit rijp genoeg is om mee te nemen in de volgende release zodat die release niet wordt tegengehouden als er een functie tussen zit die al wel in testopstelling zit maar die nog niet gereed is voor productie. Toelichting: Deze functie is zo langzamerhand noodzakelijk om de komende sprints efficiënt verder te kunnen doorontwikkelen. 2. BBRO-1087 Helpinformatie tonen als je geen autorisaties hebt Story: Als Beheerder wil ik dat Gebruiker informatie op het scherm te zien krijgt als hij nog niet geautoriseerd is zodat hij snapt dat dit de reden is dat hij op het scherm geen informatie ziet. Toelichting: Dit zijn relatief eenvoudige wijzigingen die helpen voorkomen dat een gebruiker bellen met de vraag of de applicatie het wel doet. Moet helaas wel wachten op de volgende release. 3. BBRO-954 Mailadres valideren via mailnotificatie met validatiecode (in testopstelling) Story: Als Product Owner wil ik dat gebruikers zelf hun mailadres kunnen valideren via een code die ze in hun mailbox ontvangen zodat de basis is gelegd voor het inrichten van notificaties die Gebruikers via de mail wensen te ontvangen. Toelichting: Was in de vorige sprint ingepland maar niet gerealiseerd. Is wel noodzakelijk om alsnog te realiseren omdat anders andere functies die een gevalideerd mailadres nodig hebben in de vertraging komen.
Prio 2. Nieuw te realiseren zodra het kan De volgende wensen betreffen gewenste automatische koppelingen met andere systemen. Deze koppelingen hebben prioriteit, maar zijn pas realiseerbaar als de aan te koppelen systemen daadwerkelijk beschikbaar zijn om mee te gaan testen: Extra prioriteit omdat ze generiek zijn: 1. BBRO-67 Aansluiten op een IMBRO/XML-validatieservice (in testopstelling) Story: Als BRO Ketenmanager wil ik dat het Bronhouderportaal de syntax van aangeleverde bestanden bij een gemeenschappelijke validatieservice valideert (en niet in de applicatie zelf zoals nu het geval is) zodat (1) er geen verschillende uitkomsten kunnen zijn bij validaties door de verschillende schakels in de BRO-keten en (2) er minder ingrijpende aanpassingen nodig zijn in het Bronhouderportaal als er nieuwe registratieobjecten worden toegevoegd. Status: Samen met TNO is nu een testopstelling te maken om op 27 maart te demonstreren. 2. BBRO-260 Geautomatiseerd GMW-bestanden kunnen aanleveren (in testopstelling) Story: Als Leverancier wil ik vanuit mijn eigen softwaresysteem geautomatiseerd GMW-registraties, mutaties en correcties kunnen aanleveren aan het Bronhouderportaal (in plaats van handmatig via uploads zoals nu het geval is) zodat dit proces voor mij efficiënter wordt voor soorten leveringen die ik heel vaak moet doen. Status: Met één partij is afgesproken dit 27 maart te demonstreren. Andere leveranciers zijn welkom om aan te sluiten. Alleen prioriteit als er generieke oplossingen worden aangedragen: 1. Koppeling met AAT (in testopstelling) Wachten Story: Als Grote Bronhouderorganisatie wil ik een koppeling hebben met mijn geautomatiseerde kwaliteitscontrolesysteem zodat ik en deel van de kwaliteitscontrole kan automatiseren zodat mijn specialisten er minder werk van hebben. Besluit: Vooralsnog wordt er getest met AAT als losse tool. Je kunt bestanden openen en in deze tool controleren. 2. Koppeling met een grafische viewer (in testopstelling) Wachten Story: Als Kwaliteitscontroleur wil ik een koppeling hebben met mijn viewer waarin ik de inhoud van IMBRO/XML-bestanden die ik moet controleren grafisch kan weergeven zodat ik in staat ben om mijn werk te doen. Besluit: Vooralsnog komt er een losse viewer; je kunt bestanden downloaden en dan in deze viewer openen.
Ontwerp aanlever-webservice (in concept) Te adresseren risico s Hoe voorkom je dat je een verkeerd token gebruikt en bericht verkeerd aankomt? Hoe voorkom je dat een token wordt hergebruikt door anderen? Is dit veilig genoeg als de bronhouder goedkeuren en accorderen ook op automatisch zet? Hoe lang mag een token geldig blijven? Wat willen we daarover bepalen en waarom? 2x pull-mechanisme push & pull = complexer Hoe DoS-achtige aanleverdrukte en deadlocksituaties te beheersen? Veiligheid voorop Werkend krijgen vereist éénmalig inlog met eherkenning 2+ Werkt met gebruik van certificaat in de vorm van een token. Robuuste oplossing Laagdrempelig in gebruik Bij storing kun je terugvallen op handmatig aanleveren. Token bepaalt waar en aan wie bestand wordt afgeleverd. Werken met laagdrempelig REST in plaats van SOAP Je kunt zelf je token aanvragen en vernieuwen 2x pull-mechanisme: je initieert zelf, geen luisterservice nodig Praktische vragen Hoe een continue stroom berichten te bundelen in reeks afgebakende leveringen? Hoe koppeling robuust te maken tegen tijdelijke storingen en ongeldige of dubbele aanleveringen? Op welke ordegrootte aan verkeersdrukte moeten we berekend zijn?
Bespreking ontwerp aanlever-webservice 1. Voor de komende sprint maken we alleen een testopstelling met twee partijen (ICTU en een leverancier) die samen laten zien dat het technisch écht werkt. De oplevering in productie is op zijn vroegst een sprint later, afhankelijk van verdere besluitvorming. 2. Het is nog de vraag of we zonder PKIO-certificaat kunnen. We hopen van wel. Want je moet voor het aanleggen van de koppeling als leverancier óók al met eherkenning inloggen. En welk risico lopen we hier en wat is de impact? Krijg je niet overkill aan beveiliging? Maar dat is nog te toetsen door informatiebeveiligers. 3. De keuze voor wel of niet PKIO-certificaat staat los van het gebruik van de token: Want dat token hebben we nodig om te zorgen dat berichten in het juiste inbakje worden afgeleverd. Dus die investering is sowieso nodig en dus niet weggegooid. Als er een PKIO-certificaat nodig blijkt te zijn is dat een latere uitbreiding. 4. De testopstelling die de 27 ste zal worden gedemonstreerd wordt samen met Hoogheemraadschap Hollands Noorderkwartier voorbereid. Er zijn nog twee leveranciers die misschien mee gaan doen. 5. Op 21 maart is er softwareleveranciersoverleg. Daar staat ook deze oplossing op de agenda. Leveranciers die willen meedenken en meetesten zijn van harte welkom.
Prio 3. Te verhelpen zodra het kan De volgende verzoeken zijn uitgezet bij de hostingprovider. We zijn afhankelijk van technische oplevering aldaar: 1. Onterechte foutmeldingen bij inloggen voorkomen BBRO-1101 Bevinding: Als Gebruiker wil ik af van cryptische en onterechte foutmeldingen die ik af en toe krijg bij het inloggen zodat ik me daaraan niet meer hoef te ergeren. 2. Inlogpagina logischer indelen Wachten Bevinding : Als Gebruiker wil ik de inlogpagina logischer van opzet met alleen relevante informatie bevat zodat ik minder fouten maak tijdens het inloggen en minder vaak mijn account hoef te laten deblokkeren na teveel mislukte inlogpogingen. 3. BBRO-1030 Performancemonitoring aanzetten Bevinding : Als Administrator wil ik de prestaties van de applicatie kunnen volgen zodat ik overbelasting tijdig zie aankomen en maandelijks objectieve cijfers kan rapporteren over de beschikbaarheid van de applicatie binnen en buiten kantooruren. 4. Zelf je wachtwoord kunnen wijzigen Wachten Bevinding : Als Administrator wil ik dat een Gebruiker die inlogt met mailadres zelf het wachtwoord kan (en periodiek moet) wijzigen zodat ik kan voldoen aan de informatiebeveiligingsrichtlijn van de overheid. Nieuw: Als Gebruiker wil ik dat de browser na wijziging het gewijzigde wachtwoord onthoudt, niet het oude wachtwoord. 5. Zelf je wachtwoord kunnen resetten Wachten Bevinding : Als Gebruiker die inlogt met mailadres wil ik zelf op een veilige manier mijn wachtwoord kunnen resetten zonder tussenkomst van de Servicedesk zodat ik niet dagen op mijn nieuwe wachtwoord hoef te wachten als ik het vergeten was. 6. Eigen maildomein inrichten voor mailnotificaties Wachten Bevinding : Als Administrator wil ik gebruik kunnen maken van het @bronhouderportaal-bro.nl-domein (in plaats van een generiek mailadres van de hostingprovider zoals nu het geval is) zodat de Gebruiker die mailnotificaties ontvangt sneller snapt wie de afzender is en ik meer grip heb in het voorkomen dat mailnotificaties bij de Gebruiker in de spambox komen.
Performancemonitoring tijdelijk vanuit de cloud
Prio 4. Top-20 overige prioriteiten Deze wensen zijn de afgelopen weken door de Sprintreview-deelnemers geprioriteerd. Vandaag bespreken we de aanpak: NR Organisatie Amsterdam BRO NL-Noord RWS TNO Contactpersoon CDR Ria Henk F. Henriëtte Henk K. 13 In een project kunnen instellen dat goedkeuren en/of accorderen van leveringen automatisch mag gebeuren. BBRO-1104 5 4 2 11 20 Anoniem gebruik ondersteunen om bestanden via het Bronhouderportaal te kunnen laten valideren. Te ontwerpen 1 10 11 3 Controleren op dubbele bronbestanden zodat ze niet dubbel in de LV BRO terechtkomen. Te ontwerpen 2 1 1 4 5 Rapportage over organisaties, projecten, leveringen, accounts en bestanden per organisatie en per periode. Te ontwerpen 2 1 1 4 7 Mailnotificatie ontvangen zodat je weet dat er een nieuwe taak voor je klaar staat. Wacht op oplevering validatie mailadres 1 1 1 1 4 2 Als Coördinator alle projecten, leveringen en bestanden van de eigen bronhouderorganisatie kunnen inzien. BBRO-1085 1 1 1 3 6 Een zoekfunctie voor het terugvinden van organisaties, projecten, leveringen, accounts, bestanden en BRO-IDs. 1 1 1 3 14 Statusinformatie over een project op de projectbalk afbeelden zodat je daarvoor het project niet hoeft te openen. 1 1 2 17 In het leveringsoverzicht tonen wie er geacht wordt de volgende stap in de afhandeling te doen. 1 1 2 19 Alle leveringen in een project in één keer kunnen downloaden. 1 1 2 1 De status Ingenomen door LV BRO graag corrigeren zodat je direct ziet of die tot goed-of afkeuring heeft geleid. 1 1 8 Mailnotificatie ontvangen als de afhandelingstermijn voor een taak dreigt te verstrijken. 1 1 9 Mailnotificatievoorkeuren kunnen instellen per account en per project. 1 1 11 Brondocumenten van registratieobjecten uit komende tranches kunnen verwerken. 1 1 4 Archivering van organisaties, projecten, leveringen, accounts en bestanden als ze niet meer actueel zijn. 0 10 BHR-p brondocumenten kunnen verwerken zodat ook die via het portaal naar LV BRO kunnen gaan. BBRO-1086 0 12 Deelprojecten kunnen aanmaken zodat een hiërarchie kunt aanbrengen in de weergave en in het rechtenbeheer. 0 15 Bij aanlevering een referentiecode van de eigen administratie kunnen opvoeren om de link daarmee te bewaren. 0 16 Beter onderscheid maken tussen de keuze Afkeuren bij Controleren en Afkeuren bij de stap Accorderen. 0 18 In het leveringsoverzicht statusinformatie ook grafisch weergeven zodat je sneller ziet wat de status is. 0 Totaal 10 10 10 10 10 50 SCORE
Functionele ontwerpschetsen Tom Koenraads Te bepalen: Welke nieuwe functies willen we toevoegen om het werk te vereenvoudigen? Goedkeuren en accorderen kunnen instellen op automatisch? Schermvoorbeeld 1.1 Automatisch goedkeuren/accorderen instellen Schermvoorbeeld 1.2 Feedback krijgen over deze instelling Schermvoorbeeld 1.3 Feedback achteraf in het leveringsoverzicht Meerdere leveringen in één keer kunnen selecteren voor goedkeuren en accorderen? Schermvoorbeeld 2.1 Handmatig meerdere leveringen selecteren Schermvoorbeeld 2.2 Automatisch selecteren op basis van status Schermvoorbeeld 2.3 Feedback krijgen tijdens het goedkeuren Schermvoorbeeld 2.4 Alle leveringen automatisch selecteren Discussiepunten Vanaf welk moment is het zinvol om functies als deze in te bouwen? En wat willen we dan prioriteit geven? Eén van bovenstaande voorstellen of een andere variant? Voor de schermvoorbeelden: zie de volgende pagina s...
1.1 Automatisch goedkeuren/accorderen instellen Ontwerpschets
1.2 Feedback krijgen over deze instelling Ontwerpschets
1.3 Feedback achteraf in het leveringsoverzicht Ontwerpschets
Bespreking automatisch Goedkeuren/Accorderen Ja, we willen dit: 1. Story: Als Bronhouder wil ik goedkeuren en/of accorderen in een machtiging kunnen instellen op automatisch zodat ik stappen in het Bronhouderportaal die in ons aanleverproces onnodig zijn kan overslaan. 2. De standaardinstelling is Nee / Nee, oftewel: handmatig controleren en vaststellen. Als je beide opties op Ja zet krijg je een waarschuwing in de trant van: U merkt niets van de aanleveringen, maar u blijft wel wettelijk verantwoordelijk. Weet u het zeker? met bevestigen/annuleren-knoppen. 3. Er zijn risico s verbonden aan automatisering, daar zijn we het over eens. Het kan fout gaan in de aanlevering. En je bent als Bronhouder minder betrokken. Dat kan ook nadelig zijn. Maar het is uiteindelijk aan de verantwoordelijke Bronhouder zelf en niemand anders om die risico s goed te managen. Iets instellen op automatisch blijft optioneel! 4. De vraag is of er aan de instelling op automatisch ook een einddatum moet of mag zitten. Moet dat per machtiging? Wil je daar een algemeen beleid voor kunnen instellen? Je kunt er ook last van hebben dat een de instelling ineens weer omklapt naar handmatig. Daar zijn we nog niet over uit, dus die wordt in de komende sprint nog niet ingebouwd. Dat kan desgewenst in een volgende iteratie. 5. Sheet 1.2: Dit implementeren we, maar met de tekst aangepast: In de machtigingstegel die je als bronhouder ziet gaan we tonen de gemaakte instellingen tonen, maar ook als de instelling handmatig is. Dus het wordt: Wordt handmatig gecontroleerd / Wordt automatisch goedgekeurd etc. dus niet alleen als het automatisch is. 6. Sheet 1.3: Implementeren we niet: In het leveringsoverzicht dat de leverancier ziet wordt niet getoond dat er goedkeuring of accordering automatisch was. Want de leverancier maakt dat niet uit. Dat blijft zoals het nu is. 7. We gaan de eerste iteratie van deze functie in de komende sprint inbouwen en demonstreren. BBRO-1104
2.1 Handmatig meerdere leveringen selecteren Ontwerpschets
Bespreking Meerdere leveringen selecteren We hebben hier op dit moment nog geen behoefte aan. Dit wordt pas relevant als er grotere aantallen leveringen te verwerken zijn. Dan zien we wel verder.
5 AFSLUITING
Besluiten en actiepunten 1. Ten aanzien van de oproep om échte ondergrondgegevens aan te gaan leveren Het beeld in de groep na deze sprintreview is dat de applicatie nu wel mooi genoeg is (het kan altijd beter) en dat het tijd wordt dat we m gaan gebruiken. Maar wie heeft al nieuwe ondergrondgegevens? De conclusie is dat het zal lastig zijn om nieuwe putregistraties te krijgen, want die zijn er jaarlijks niet veel. Maar sonderingen zijn er wel. Dus laten we de energie erop richten om die nu in de BRO te krijgen. 2. Te realiseren in Sprint 19 1. De 12 stories die in dit verslag zijn voorzien zijn van een geel gearceerd BBRO-nummer worden de komende sprint opgepakt en in testopstelling opgeleverd. (zie blz 14, 17, 18, 21, 23 en 28) 3. Te ontwerpen in Sprint 19, in volgorde van prioriteit 1. Hoe om te gaan met het BRO-referentienummer in relatie tot andere metagegevens. 2. Weergave van printbare leveringsdetails verbeteren op basis van feedback van leveranciers. 3. De applicatie intuïtiever maken, zodat je als gebruiker sneller snapt wat er van je verwacht wordt. 4. Diverse kleine verbeteringen in de weergave (restpunten). 4. Locaties komende sprintreviews In verband met demonstratie van een testopstelling zitten we 27 maart in Den Haag, waarschijnlijk bij ICTU. Wat betreft de sessies daarna: Het is druk en het valt niet mee om in het midden van Nederland een locatie te vinden. We zoeken daarom nog even verder.
Evaluatie Wat ging goed? IIII Goede demo. Portaal ziet er al heel goed uit. We zijn er blij mee. Complimenten! IIII De hoofdlijnen werden goed bewaakt, geen detaildiscussie, ondanks (of dankzij?) dat de groep vandaag groot was. II Constructieve sessie, goed om bij aanwezig te zijn, het was weer top! I I We boeken veel voortgang in korte tijd. Nuttig om als geo-softwareleverancier te horen waar je als klant tegenaan loopt. Wat kan beter? I Graag meer bronhouders aan tafel. I Graag ook dataleveranciers aan tafel. I Hou er rekening met dat nieuwe deelnemers minder diep in de materie zitten. I Als bronhouders hebben we nog veel te regelen. I Laten we zorgen dat de BRO nu gevuld wordt! I Maak scherper onderscheid tussen wat we echt móeten hebben en wat leuk is om te hebben. I De beamer gaf de presentatie niet goed weer. I Graag het verslag van de review in het vervolg graag eerder rondsturen als het kan. I Koppel terug hoe deze wat-kan-beter -punten naderhand zijn opgepakt. I Fijn dat hier softwareleveranciers aanwezig waren.