Document toolboxDocument toolbox

2018-09-20 BWG 1

Owned by Dirk Diddens (Deactivated)
Last updated: 12 Nov, 2018
6 min read

Presentatie (pptx, 4,5 MB)

Klik op een onderwerp om er feedback op te geven.

Verslag


TimeItemWhoNotes
13:00

Introductie:

  • rondje IV (incl. voorstelling Dirk, Evy) 
  • toelichting agenda
Els
13u00 - 13u30

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?  (
Els

 

13u30 - 15u00

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.
Els
  • 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
15u00 - 15:15

Pauze



15:15 – 15:30

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

Els
15:30 – 16:30

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.
Naomi
  • Bespreking definities OSLO:
    •  Werken
      • definitie van "werken" bevat "werken"?
      • hoe definiëren we werken? de attributen die specifiek voor werken gedefinieerd zijn, zijn enkel van toepassing op grondwerken. Misschien moet de definitie dus strikter. 
      • reinigingswerken, herstelling van een riolering, plaatsing deksel, schilderwerken op openbare weg?  Bij gemeente is dit duidelijk wel werken.  In GIPOD niet?  >> suggestie bv. "grondwerken". In GIPOD zouden dit dan innames zijn. Het concept manifestatie verdwijnt. Er zullen (grond)werken zijn en andere innames met een type. Deze lijst moet nog bekeken worden. 
      • Dit wordt de volgende BWG opgenomen 
  • Wat nemen we in GIPOD op?
    • De BWG discussieert over wat er dan in GIPOD moet worden opgenomen. Is het wel zinvol om alle interventies (bv technieker die gaat naar kast) dan moeten worden opgenomen. Hierbij wordt opgemerkt dat de mate waarin iets hinder zal veroorzaken bepalend is . Het doel van GIPOD is immers de hinder te verminderen en een bron te zijn voor geplande hinder.
    • IV geeft nogmaals aan dat er een verschil is tussen wat mogelijk kan ingevoerd worden in GIPOD versus wat is verplicht in te voeren in GIPOD. Het kader hiervoor is het decreet.
  • Inname versus hinder (gevolg van inname op mobiliteit)
    • hinder werd omschreven als de gevolgen van een inname op het openbaar domein.
    • hinder kan in vele gevallen 100% identiek zijn met inname.
    • verkeersmaatregelen die genomen worden nav een inname en die gevolgen hebben op de normale verkeerssituatie zijn hinder. (bv 30 ipv 50, wisselende stroken, ...)  
    • fietscorridor tgv werf: ruimtelijke inname op openbare weg? omleiding?  Nu bestaat geen hinderzone. Wél ndz. in nieuwe GIPOD.
    • hinder valt samen met signalisatie en aanvraag signalisatievergunning
  • werk- versus werfzone
    • werfzone bevat container, kraan, ... voetgangsbrug?
    • gemeente: werkzone kan niet gewijzigd worden, maar gemeente wil wel kunnen zeggen: zet container of kraan op ander terrein. De gemeente zal dus de werfzone bepalen bij het verlenen van de signalisatievergunning. Deze zone zal als één zone worden ingetekend om zo ook de link te kunnen leggen, met signalisatievergunning. Het lijkt niet nodig om al de elementen van een werfzone afzonderlijk te kunnen intekenen, behalve dan om te kunnen inschatten waar ze geplaatst mogen worden in functie van de hinder (bv container ergens anders zetten...). De vraag is of dit via GIPOD moet aangeleverd worden.
    • totale inname zone : de vraag stelt zich of dit niet eerder gelijk is aan de som van de werk- , bijkomende werf zone en de  hinderzone ? Dit zou een berekende geometrie zijn die zelf de som maakt van de onderliggende zones.
    • voorlopige conclusie
      • werkzone moet afzonderlijk bewaard worden (sperperiode, ...)
      • aannemer /gemeente geeft de werfzone in zijn geheel door.
      • wat is inname zone? Is dit enkel inname of nemen we ook de hinder mee en moet het dan niet anders genoemd worden? 
  • periode en status van inname.
    • Huidige problematiek is dat de waarde van vooral "concreet gepland" niet erg duidelijk is en door alle partijen anders wordt geïnterpreteerd. Het doel is om de semantiek duidelijker af te spreken en er tevens voor te zorgen dat de gevraagde aanpassingen tot een minimum worden beperkt zodat de data correcter in GIPOD zit. 
    • Het voorstel is om een status op 2 niveau's te hebben
      • op inname: heel eenvoudig (kunnen eventueel automatisch worden afgeleid)
      • op datum: geeft de waarde van de datum mee
    • Er ontstaat een discussie over de waarde van "effectief gepland"
      • het gaat nog steeds om een geplande datum
      • voor grote werken: einddatum moet kunnen wijzigen, dus bv. afzonderlijke status op start- en einddatum.  Op elke datum variabiliteit zetten.  Default waarde kan ingesteld worden variabel volgens duur van werken.  Maar moet nog kunnen gewijzigd worden. Er werd gesuggereerd om met marges te werken. Dit bestond vroeger in GIPOD maar werd aangepast omdat het een negatief effect had op de datakwaliteit.
      • hoe perfect moet effectief gepland zijn?  Op dag niveau?  Ook bij kleine werken kan men wel aangeven dat een werk in die week "gepland" is maar of het ook effectief dan uitgevoerd wordt, kan nooit voorspeld worden. het zou dus toch best zijn om toch de status aan te passen op het ogenblik dat de werken echt uitgevoerd worden. Dit moet ook nog wel bekeken worden met wederkerige patronen. Mogelijk is er toch een onderscheid tussen innames zoals een wekelijkse markt, jaarlijkse koers, enz..  en werken. Bij dat eerste zou GIPOD veel meer automatisch kunnen afleiden op basis van de ingegeven effectieve planningen.
      • De data kunnen ook tijdens de uitvoering nog wijzigen, zeker de einddatum ligt niet altijd heel zeker vast.
    • voor prioritaire assen voor De Lijn: in principe effectieve planning moet 4-6 weken . Dit wordt in de praktijk weinig gerespecteerd waardoor er toch nog veel ad hoc overleg volgt en de waarde van GIPOD daalt. Dit moet zeker verder bekeken worden in de werkgroepen.
    • Conflictberekening moet worden herbekeken. Mogelijk zal de "waarde" van ene conflict anders zijn op basis van de status van de datum.
    • Ontsluiting naar derden (via public API) wordt op dit ogenblik automatisch gedaan indien een werk op concreet gepland staat. Er moet bekeken worden of dit niet anders moet. Andere status of via een veld waarbij de beheerder kan aangeven of het ontsloten mag worden? Daarbij moeten wel goede defaults worden voorzien. 
    • Automatische afhandeling van de status van de inname moet goed bekeken worden. Dit kan zeker zinvol zijn voor bepaalde innames (bv typisch heel veel huidige manifestaties) maar is niet wenselijk voor alle werken. per type werk te bepalen?

Topics volgende werkgroep

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