Projectspecifieke berichten in VISI archief - 1 of alle?

[ArneBruinse]

Gerapporteerd door Arne Bruinse op 16-12-2020:
Tijdens het testen van het importeren van een "VISI archief" is er onduidelijkheid over de vraag welke projectspecifieke berichten er in het "VISI archief" moeten worden opgenomen.

• Moet alleen het laatste projectspecifieke bericht opgenomen worden in het "VISI archief"?
  --Uitkomst overleg Jeroen/Arne 20-1-21: Nee. Het laatste raamwerk wordt gebruikt voor de communicatie, maar de rest moet er wel bij als archief/naslagwerk.

• Moeten alle projectspecifieke berichten opgenomen worden in het "VISI archief"? (Met "alle projectspecifieke berichten" wordt bedoeld dat iedere wijziging van personen en rollen traceerbaar is in een gewijzigd projectspecifieke bericht.)

• -Uitkomst overleg Jeroen/Arne 20-1-21: Hiermee wachten we totdat we alle import export testen afgerond hebben.

• Moet per raamwerk een projectspecifiek bericht opgenomen worden in het "VISI archief"? (Een raamwerk heeft een unieke namespace en in het projectspecifieke bericht wordt verwezen naar het raamwerk waarbij het projectspecifieke bericht hoort.)

• -hier gaan we verder op in in aparte issues:

• --- Rol verwijderd in update raamwerk #89 Het idee is dat we passive gaan beoordelen of we hiermee het deactiveren van een rol kunnen aanbieden en dat we wel de lijn gaan volgen dat een (gebruikte)rol wel altijd aanwezig moet zijn in het laatste PSB. Dit punt moeten we nog een keer in detail doorspreken of dit echt wenselijk is.

• --- Deactiveren van Person In Role elementen in een PSB #81 Dit gaat over pir regels deactiveren

• --- Verder willen we gaan onderzoeken of de documentatie aangepast moet worden op het punt dat er een raamwerk namespace verwijzing in het PSB hoort, want in een project met 20 raamwerken, zou een opvolging van 1 persoon kunnen resulteren in 20 psb's om uit te wisselen. Dit wordt de praktijk nu ook niet toegepast en alles werkt naar behoren met het uitwisselen van de laatste stand van zaken met 1 psb. Om nieuwe leveranciers te behoeden voor evt onnodige complexe implementaties kan het van meerwaarde zijn om de documentatie hierop aan te passen. (NIEUW issue maken- of deze als er geen issue voor archief overblijft )

Achtergrond:
Deze vraag is ontstaan doordat in een project een persoon toegevoegd is en 40 minuten later verwijderd is (Ilca I.). Het project is gearchiveerd. Het VISI archief heeft alle projectspecifieke berichten. Bij het inlezen van het "VISI archief" a) converteert software A alleen het laatste projectspecifieke bericht in personen / users, en b) converteert software B alle projectspecifieke berichten in personen / users. Dus de verwijderde persoon is niet aangemaakt in software A, maar wel in software B.

Verwijzing naar Leidraad van VISI Standaard:
https://github.com/bimloket/visi/wiki/Bijlage-11-Richtlijn-voor-het-archiveren-van-VISI--projecten

---

Format voor (intake en afhandeling van) issues GC180508-09

GC / 8 mei 2018

Wat komt er binnen (vraag /opmerking)
(uitgangspunt: de vraagsteller is ‘bewust onbekwaam’)

1. Omschrijving van de vraag/opmerking zelf (bij voorkeur in het format van ‘userstory’):
   “Als <gebruiker/rol> wil ik zodat ik krijg”
2. Naam, functie (soort gebruiker/rol), diens organisatie, en de soort organisatie van de vraagsteller (stakeholder)
3. Datum en oorsprong van het verzoek*
4. Waarop heeft de vraag betrekking:
   a. Open Standaard (VISI / COINS)
   b. VISI-raamwerk / COINS referentiekader
   c. Software (VISI / COINS)
5. Wat is de urgentie )
   ‘M’ (must have; hindert de dagelijkse procesgang/doorgang van een project; moet zo spoedig mogelijk worden opgelost)
   ‘S’ (should have; hinder kan worden omzeild in dagelijks werk; moet binnen redelijke termijn worden opgelost)
   ‘C’ (could have; geen directe hinder; kan een keer worden opgepakt)
   ‘W’ (won’t have, c.q. nice to have; komt nu niet aan bod maar kan in de toekomst, bij een vervolgproject, wellicht mogelijk interessant zijn)
6. Toelichting op de urgentie*

‘Open Standaard’

1. Stel vast of het een ‘bug’ is, of een ‘verbetervoorstel’, of een ‘ander verzoek’

2. Bug
   a. Beschrijf het bestaande gedrag
   b. Beschrijf het gewenste gedrag
   c. Benoem de stappen om het probleem te reproduceren

3. Verbetervoorstel
   a. Maak de userstory expliciet; mogelijk valt die uiteen in meerdere user stories
   (“a list of the types of users who can engage in the activities described in the use case. Actor names should not correspond to job titles”).
   b. Beschrijf de randvoorwaarden
   (“anything the solution can assume to be true when the use case begins”).
   c. Completeer de ‘definiton of ‘done’
   (“anything that must be true when the use case is complete”).
   d. Beschrijf het verbetervoorstel / of gewenst gedrag
   (“the set of steps the actors take to accomplish the goal of the use case. A clear description of what the system should do in response to each user action.”)
   e. Beschrijf de voordelen van de verbetering
   f. Beschrijf eventuele “Alternate Flows”
   (“capture the less common user/system interactions, such as being on a new computer and answering a security question).
   g. Beschrijf eventuele “Exception Flows”
   (“things that can happen that prevent the user from achieving their goal, such as providing an incorrect username and password).

4. Ander verzoek
   a. Beschrijf de vraag zo gedetailleerd mogelijk
   b. Beschrijf de voordelen van het voldoen aan het verzoek

5. Plaats de gedocumenteerde bug, verbetervoorstel of ander verzoek op de verzamellijst ter prioritering in het kader van de release cyclus (ook op github??)

‘VISI Raamwerk’ of ‘COINS Referentiekader’

1. Stel vast of het een ‘bug’ is of een ‘verbetervoorstel’ in de standaard, of een probleem bij het gebruik van de standaard (bij VISI: het maken van raamwerken; bij COINS: het gebruik van een referentiekader)

2. Indien ‘Bug’ of ‘verbetervoorstel’ voor de Standaard
   a. Verplaats de vraag naar het bakje ‘Standaard’ en handel daar af conform procedure

3. Indien probleem bij gebruik
   a. Beschrijf de vraag zo gedetailleerd mogelijk (indien alsnog een probleem met de standaard blijkt: zie 2.)
   b. Beschrijf de voordelen van het voldoen aan het verzoek
   c. Plaats op lijst ter afhandeling (door beheerder van de OS, helpdesk of adviseur)

‘Software’

1. Betreft het VISI-software of COINS-software
   a. Is het een generiek probleem -> zie punt 2
   b. Is het een specifiek probleem: informeer (de helpdesk) van de desbetreffende softwareleverancier
   c. Informeer eventueel de desbetreffende Expertcommissie en Gebruikerscommissie

2. Generiek probleem voor de Standaard
   a. Verplaats naar het bakje ‘Standaard’ en handel daar af

 
P.S. Definition of ‘DONE’ (checklist):

De ‘definition of done’ is de checklist van dingen die gedaan moeten zijn voordat je klaar bent met een issue. Er is een generieke definitie, maar ‘done’ moet goed aansluiten bij de vraag. Het kan dus voorkomen dat er nog specifieke dingen aan moeten worden toegevoegd. Dat moet dan gebeuren voordat het oplossen van de vraag start.
• Generieke ‘definition of ‘done’ is helder
• Eventuele specifieke dingen die ook moeten zijn gedaan, moeten aan de generieke definition of ‘done’ worden toegevoegd

De check van de oplossing is dan (voor zover relevant):
• Alle ‘to do’ items voor de User Story zijn voldaan, inclusief de specifiek toegevoegde dingen.
• Relevante gebruikersdocumentatie is gemaakt of aangepast.
• Relevante technische documentatie is bijgewerkt en geactualiseerd.
• De ‘reporter’ heeft het werk geaccepteerd.
• Er is feedback van eindgebruiker(s)/vraagsteller gevraagd/gekregen op het opgeleverde product.
• Alle unit- (bouwer), integratie (productowner) functionele (key users) testen zijn succesvol gedraaid.
• Indien hiervan afgeweken wordt dan is dit opgenomen in de userstory (afwijkingen opgenomen in userstory).

[ElisabethKloren]

@ArneBruinse wat is het verzoek aan de beheercommissie voor versie 1.7? Het format is niet ingevuld.

[ArneBruinse]

de uitleg staat bovenaan: dit is een bevinding/vragastuk dat voortkomt uit de migratietesten en dat door de EC verder uitgezocht moet worden. Uitkomst van de project migratie overleggen en/of het visi TC kan een gevuld format opleveren. Tot die tijd is het geen vraag aan de beheercommissie.
Versie 1.7 hebben we er aan gekoppeld omdat de projectmigratie erg hoge prioriteit heeft gekregen. Of dit werkelijk in 1.7 opgelost kan worden weet ik nog niet.

[ArneBruinse]

@ElisabethKloren voorlopig gebruiken we dit issue als notitieblok voor de lopende overleggen

[ArneBruinse]

Update uit werksessie 17-12-2021(michon/jeroen/arne)
We gaan in de 1.6 documentatie zoveel mogelijk vastleggen. De eventuele omissies zullen we dan tzt voor 1.7 of 1.8 inschieten.