Introductie:

• rondje IV (incl. voorstelling Dirk, Evy) 
• toelichting agenda

Toelichting projectaanpak

• Hoe gaan we van de functionaliteit in het business case document naar concrete features/stories en taken? 
• Hoe wordt de co-creatie vorm gegeven? 
• Hoe verzamelen we feedback ook na en tussen de werkgroepen?  
• Hoe kunnen de punten die we op de werkgroep bespreken voorbereid worden en nadien besproken met de eigen mensen?  (

Discussie: roadmap in productiestelling vernieuwd GIPOD  

• Er zijn verschillende mogelijkheden om het vernieuwde GIPOD in gebruik te nemen. We stellen een aantal mogelijke oplossingen voor en gaan wat dieper in op de voor- en nadelen. Het doel is om uiteindelijk op het bestuurscomité van 2 oktober een advies van de werkgroep voor te leggen. De voorstellen kunnen ook na de werkgroep nog bekeken en becommentarieerd worden. Het doel is om ten laatste op de businesswerkgroep van 2 oktober een voorkeurscenario vast te leggen. Dat stellen we begin oktober voor op het bestuurscomité.
• Discussie in de werkgroep over gewenste scenario’s en prioriteiten.

• Leden van de BWG: voorkeur voor eenmalige overschakeling.
  
  • pro: makkelijker transitie organiseren (opleidingen, ...)
  • pro: makkelijker voor opleiding als men dadelijk een stabiel functionerend geheel kan aanbieden.
  • pro: planning IT'ers
  • pro:minder kosten omdat er dan maar een project gedaan moet worden en één aanpassing indien men software van dienstenleveranciers gebruikt. Anders worden er mogelijk meer dan een keer kosten aangerekend.
  • con: latere beschikbaarheid vernieuwde modules hinder en omleiding, kleine werken
  • con: langer traject voor er iets in productie gezet wordt, kan het risico wel verhogen
• Opmerkingen:
  • Het doel is wel om API 's stabiel te houden ook bij nieuwe releases. Er is steeds een overgangsperiode alvorens een nieuwe versie van de API verplicht wordt en de oude wordt uitgeschakeld. Dit wordt samen oip de BWG bekeken. 
  • wat is risico op vertragingen bij elk van de scenario's? 
    • antwoord IV: Het risico op vertraging - ook bij de integrerende partijen is kleiner indien eerst met inname begonnen kan worden. Dit is de basis van GIPOD ook voor de integratoren. Op deze basis worden de andere modules en extra functies (zoals hindermodule..) gebouwd. In de ontwikkeling worden dan eerst in beta stabiele API voor creatie en wijziging inname aangeboden waardoor er meer tijd is om deze ook effectief te integreren.    
  • planning test belangrijker dan planning productie
    • dit moet toelaten dat alle partijen hun eigen ontwikkelingen afstemmen op het beschikbaar zijn van de betaomgeving
  • Ook het risico inschatten dat niet alle partijen klaar zijn met integratie. 
    • antwoord IV: er worden afzonderlijke technische werkgroepen ingericht waarin de status van de verschillende partijen mee wordt opgenomen. Voor de migratie zelf zal een draaiboek worden opgemaakt dat van uur tot uur zal beschrijven wat gedaan moet worden.
• Wat indien er vertragingen zijn?
  • AIV: De project aanpak volgt de ontwikkelingen zeer nauw op. Mogelijke problemen zullen al heel snel opgespoord worden. Indien er vertragingen zouden zijn, kunnen er verschillende maatregelen genomen worden. Gaande van uitstel in productie stelling tot opleveren van basis versie met enkel basisfuncties. Het is ook aan de BWG zelf om bij het formuleren van de vereisten voor R2 mee te zorgen dat ze binnen het voorziene tijd opgeleverd kunnen worden. Indien er toch problemen zouden zijn dan zal samen met de BWG het beste scenario worden gezocht en aan het bestuurscomité worden voorgelegd.
• Gent:
  • kleine werken asap in het systeem  gewenst.  Doch ok met big-bang.
  • Bij vertraging van project, vermijden dat overgangstermijn ook wordt uitgesteld.
• Backsynch. mogelijk van innames van nieuw naar oud?  Els: nee, afspraak is one-way synch omwille van kosten en verlies van informatie.
• Samenvatting: voorkeur big-bang release voor R2, aandacht dat timing gehanghaafd blijft, aandacht voor risicomanagement project

Pauze

Stand van zaken en korte toelichting OSLO2-model voor het GIPOD

Status GIPOD-model voor inname met de specificatie werk

• Bespreking en discussie over eigen GIPOD-model met o.a.
• Concept zones (werf en werk, ..).
• Data die bijgehouden worden (gepland, vergund, effectief?).
• Semantiek van de statussen.
• Types werk en inname.
• Semantiek van de verschillende attributen.

Topics volgende werkgroep

• detaillering inname
• inname-hinder
• fasering en projecten (timing, wederkerigheid, status, ontsluiting naar buitenwereld, ...)