Volgorde van weergave van AppendixTypes, CE's en SE's in VISI berichten

[JanaxLooij]

Wat komt er binnen (vraag /opmerking)

1. Omschrijving van de vraag/opmerking zelf (bij voorkeur in het format van ‘userstory’):

“Als gebruiker wil ik dat het bericht dat ik verstuur in dezelde volgorde binnenkomt bij mijn contractpartner zodat ik zeker weet dat de informatie op dezelfde manier geinterpreteerd wordt, wat niet het geval is als een tabel bij mij onder een invoerveld staat en bij de contrctpartner erboven. "Zie onderstaande tabel" kan dan naar een andere tabel verwijzen dan dat ik bedoel "

"Als raamwerkbouwer wil ik tabellen of een tabel tussen simple elements in kunnen plaatsen in een CE zodat ik niet veel meer CE's moet aanmaken en moet plaatsen omdat dat het bouwen van een raamwerk foutgevoeliger en tijdrovender maakt. Als ik in 1 CE veel meer velden kan afwisselen met tabellen dan is mijn raamwerk mooier en leesbaarder in de software pakketten doordat er minder ce namen getoond worden en is er een meer correcte manier van bundeling van informatie. Want als je altijd dezelfde 10 ce's in dezelfde volgorde in alle berichten plaatst, was in mijn ogen de bedoeling van de bedenkers van de systematiek dat je dat middels 1 complex element kon oplossen."

"Als software leverancier wil ik niet teveel complex elements in berichten hebben omdat dat de leesbaarheid en daarmee gebruiksvriendelijkheid van de software achteruit gaat."

"Als gebruiker wil ik graag een bericht met weinig hoofdstuk namen, want als er teveel staan leiden ze de aandacht af van de belangrijkere teksten en zijn ze vaak onzinning omdat er steeds sets van hoofdstuknamen zijn die eigenlijk 1 hoofdstuk horen te zijn,"

2. Naam, functie (soort gebruiker/rol), diens organisatie, en de soort organisatie van de vraagsteller (stakeholder)
   Arne Bruinse, Bakker&Spees, VISI Consultant/product owner. Namens onze consultants en klanten.

3. Datum en oorsprong van het verzoek*
   Dit speelt al jaren. In codeplex is dit item 2014-02-28 | aangemaakt.

4. Waarop heeft de vraag betrekking:
   a. Open Standaard (VISI / COINS)
   b. VISI-raamwerk / COINS referentiekader
   c. Software (VISI / COINS)
   abc

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)
   S.

6. Toelichting op de urgentie*
   We blijven raamwerken hierdoor steeds teveel CE's geven, wat echt een probleem vormt in de leesbaarheid. Volgens mij is het een vrij eenvoudige aanpassing, dus waarom zouden we het niet regelen?

‘Open Standaard’

3. Verbetervoorstel
   a. Maak de userstory expliciet; mogelijk valt die uiteen in meerdere user stories
   zie hierboven
   b. Beschrijf de randvoorwaarden
   Je kunt op dit moment meerdere SE's en CE's in 1 CE stoppen in het raamwerk. Alleen is alleen de volgorde onderling tussen de se's vastgelegd en kun je ze niet ordenen zoals bijv. eerst 2 se's dan een ce(tabel), dan 3 se's dan 3 ce's enz..

c. Completeer de ‘definiton of ‘done’
Een raamwerkbouwer kan de volgorde van se's en ce's binnen de CE vastleggen en alle software pakketten tonen die volgorde op die manier in zowel een opstel als een leesvenster of een afdruk.

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.”)
zie hierboven

e. Beschrijf de voordelen van de verbetering
minder ce's in berichten
minder foutkansen in raamwerk bouwen
betere leesbaarheid van berichten
eenvoudiger beheer van raamwerken
geen onnodge ce namen meer in berichten
geen verschil meer in interpretatie van een bericht weergave qua veld volgorde per leverancier (zie bovenstaande tabel etc)

f. Beschrijf eventuele “Alternate Flows”
(“capture the less common user/system interactions, such as being on a new computer and answering a security question).
nvt

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).
nvt

5. Plaats de gedocumenteerde bug, verbetervoorstel of ander verzoek op de verzamellijst ter prioritering in het kader van de release cyclus (ook op github??)
   @ElisabethKloren wat bedoel je hiermee? de issuelijst is toch de verzamellijst.

‘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).

---

---

Aanleiding
In een raamwerk wordt de volgorde van ComplexElements (CE) niet expliciet vastgelegd. Ook de locatie van AppendixType bij een bericht ligt niet expliciet vast in een raamwerk.

Oplossing 1
VISI Standaard aanvullen met de mogelijkheid om de volgorde van berichten expliciet te definieren in raamwerken.

Oplossing 2
In de leidraad en in het testscenario vastleggen dat de berichtinhoud (CE's) in dezelfde volgorde getoond moet worden als hoe het in de raamwerk XML staat.

Hierbij moet ook beschreven worden hoe de definitie van 1 of meerdere CE's in een CE geinterpreteerd moet worden qua volgerde van CE.

En ook de locatie (s) van appendixtypes in het bericht.

Oplossing 3
???

This work item was migrated from CodePlex

CodePlex work item ID: '1227'
Vote count: '1'

[JanaxLooij]

[100023@22-2-2016]
Dit item heeft sterke overeenkomst met issue 1250. Dat was Closed Fri at 10:37 AM by jvgeijlswijk

Dit is op 19-02-2016 besproken bij het doornemen van de product backlog van VISI.
1250 is gesloten en de volgorde wordt overgeheveld naar workitem 1227.

• Let op !! onder 1250 staat veel informatie over dit workitem. Zie daar !! *
  (in aanwezigheid van: Ge, Peter, Arne, Paul, Roy, Jos, Jeroen.)

[JanaxLooij]

[jvgeijlswijk@8-4-2016]
Prioriteit is ingesteld.

[ArneBruinse]

uit te denken problemen:

• moet je deze specificatie van de presentatielaag wil in de visi systematiek willen stoppen
• als je dit wilt zal het se block en ce block in de raamwerk xml door een element blok vervangen moeten worden en evt zelf die elementen ref niet specifiek maken voor ce of se maar gewoon een generieke ref-optie

[ArneBruinse]

@ElisabethKloren Voor de notulen: Deze is door ons onderzocht en het is niet haalbaar om deze verbetering in de 1.7 systematiek door te voeren, zolang we gebruik moeten maken van de huidige promotor.

Iets technischer: De EXP _2 file zegt specifiek dat er eerst een set met CE's en dan een set met SE's in een CE moet staan, waardoor ook de raamwerk XSD's die controle structuur krijgen. De oplossing met volgorde attributen lukt ook niet omdat er in de EXP file geen ruimte voorzien is om extra attributen aan de verwijzingen naar SE's en CE's toe te voegen.

Als we dit op willen lossen, zullen we dus eerst de volgende items af moeten werken:
#110 : Hierin kan @jvgeijlswijk dit probleem ook als een van de problemen met de huidige promotor beschrijven om tot een duidelijke probleemanalyse rondom de promotor te komen.

#87 : het werken aan de oplossing, hoogstwaarschijnlijk het "opruimen"/vervangen van de promotor

Hierna kunnen we dit item weer opnieuw oppakken. Ik zet hem daarom nu na overleg met de werksessie voorlopig op 1.8, zodat we dit item wel zien en in het achterhoofd kunnen houden bij het bedenken van de nieuwe oplossing