search

nl-digigo / visi

Beheeromgeving van de VISI open standaard.
https://nl-digigo.github.io/visi/
6 stars 4 forks source link

Geen bericht zonder inhoud versturen #57

Open JanaxLooij opened 6 years ago

JanaxLooij commented 6 years ago

Wat komt er binnen (vraag /opmerking)

  1. Omschrijving van de vraag/opmerking zelf (bij voorkeur in het format van ‘userstory’): “Als gebruiker wil ik niet dat visi software onvolledige berichten kan versturen, omdat ik altijd de zekerheid wil hebben dat een bericht volledig is en ik geen problemen kan ondervinden met het beantwoorden van onvolledige berichten”

"Als Applicatiebeheerder wil ik dat als een software fout op de ene server gemaakt wordt, dat dat bericht dan als fout op die ene server blijft en geweigerd wordt op de ontvangende server, zodat de serverbeheerder waar de fout ontstaan is dit zelfstandig kan oplossen."

  1. Naam, functie (soort gebruiker/rol), diens organisatie, en de soort organisatie van de vraagsteller (stakeholder) Arne Bruinse, VISI Consultant Bakker&Spees, namens diverse gebuikers en onze ondersteuners.

  2. Datum en oorsprong van het verzoek* Created 2016-03-08 on codeplex

  3. Waarop heeft de vraag betrekking: a. Open Standaard (VISI / COINS) c. Software (VISI / COINS)

  4. Wat is de urgentie ) ‘M’ (must have; hindert de dagelijkse procesgang/doorgang van een project; moet zo spoedig mogelijk worden opgelost)

  5. Toelichting op de urgentie* Je wilt gebruikers de ergernis van een probleemoplossing tussen 2 leveranciers zoveel mogelijk besparen. Dat is niet goed voor het imago van de systematiek. Met deze oplossing blijft een eventuele storing alleen urgent op de server waar hij speelt. Dat is ook waar de XSD techniek voor bedacht is.

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

Probleemstelling: In de VISI Standaard wordt niet afgedwongen dat een bericht (MessageType) de - in het raamwerk - gedefinieerde - elmenten (ComplexElementType) heeft. DIt betekent dat in een raamwerk een bericht met drie ComplexElementTypes kunt definieren (CE1, CE2 en CE3), maar vervolgens een VISI bericht zonder ComplexElementTypes of met maar 1 ComplexElementType (CE2) kunt versturen.

Het is voor alle betrokkenen duidelijk dat dit gedrag onwenselijk is, en dat alle 3 de ComplexElementTypes erin moeten zitten, maar het gepromote raamwerk (de xsd) geeft aan dat ze optioneel zijn.

Voorstel: Graag oplossen dat de XSD alle ComplexElementTypes uit een bericht ook verplicht stelt, zodat een bericht ook voldoet aan de definitie uit het raamwerk.

Benodigde aanpassing: Promotor dient de ComplexElementTypes verplicht te maken.

This work item was migrated from CodePlex

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

ArneBruinse commented 3 years ago
ArneBruinse commented 3 years ago

P.S.: dan dit volgorde attribuut ook opnemen bij SE's in TE's :-) (TableElements) bij Appendix type moet voortaan dan een table ipv een CE

ArneBruinse commented 3 years ago

@JensCobussen @jvgeijlswijk willen jullie hier een voorstel doen voor de aanpassing van de _ 2, 3, en 5 files? Of wil je dat ik bij ons een programmeur vraag dit op te pakken?

ArneBruinse commented 3 years ago

Voorstel voor aanpassing in _2.exp...

Vervang: ENTITY ComplexElementType; -- A ComplexElementType contains a set of SimpleElementTypes. Each stated SimpleElementType occurs exactly the number of times mentioned. description : STRING; startDate : OPTIONAL DATETIME; endDate : OPTIONAL DATETIME; state : OPTIONAL STRING; dateLaMu : OPTIONAL DATETIME; userLaMu : OPTIONAL STRING; language : OPTIONAL STRING; category : OPTIONAL STRING; helpInfo : OPTIONAL STRING;

complexElements : OPTIONAL SET [0:?] OF ComplexElementType; simpleElements : OPTIONAL SET [0:?] OF SimpleElementType;

minOccurs : OPTIONAL INTEGER; maxOccurs : OPTIONAL INTEGER; END_ENTITY;

Door: ENTITY ComplexElementType; -- A ComplexElementType contains a set of SimpleElementTypes. Each stated SimpleElementType occurs exactly the number of times mentioned. description : STRING; startDate : OPTIONAL DATETIME; endDate : OPTIONAL DATETIME; state : OPTIONAL STRING; dateLaMu : OPTIONAL DATETIME; userLaMu : OPTIONAL STRING; language : OPTIONAL STRING; category : OPTIONAL STRING; helpInfo : OPTIONAL STRING;

tableElements : OPTIONAL SET [0:?] OF TableElementType; simpleElements : OPTIONAL SET [0:?] OF SimpleElementType; END_ENTITY;

ENTITY TableElementType; -- A TableElementType contains a set of SimpleElementTypes which represents a "row" of the table. Each "row" occurs exactly the number of times mentioned (minOccurs-maxOccurs). description : STRING; startDate : OPTIONAL DATETIME; endDate : OPTIONAL DATETIME; state : OPTIONAL STRING; dateLaMu : OPTIONAL DATETIME; userLaMu : OPTIONAL STRING; language : OPTIONAL STRING; category : OPTIONAL STRING; helpInfo : OPTIONAL STRING;

simpleElements : OPTIONAL SET [0:?] OF SimpleElementType;

minOccurs : OPTIONAL INTEGER; maxOccurs : OPTIONAL INTEGER; END_ENTITY;

jvgeijlswijk commented 3 years ago

Voorstel voor aanpassing in _5.exp...

Vervang: ENTITY ComplexElementTemplate; template : ComplexElementTemplate; template : SimpleElementVirtual; END_ENTITY;

Door: ENTITY ComplexElementTemplate; template : TableElementTemplate; template : SimpleElementVirtual; END_ENTITY;

ENTITY TableElementTemplate; template : SimpleElementVirtual; END_ENTITY;

ArneBruinse commented 3 years ago

@jvgeijlswijk @JensCobussen We hebben deze aanpassing onderzocht en vinden het aanpassen van CE in CE naar TE in CE een te grote aanpassing ten opzichte van wat het oplevert. De fout van missende CE's komt bijna nooit voor, waardoor voor ons de business value als zeer laag gezien wordt.

Daarom bij deze het voorstel om de huidige situatie te handhaven en eventuele controle op lege bericht hoofdstukken eventueel te integreren in een nieuwe validatiemethode.

ArneBruinse commented 2 years ago

laatste idee uit gesprek tussen @jvgeijlswijk en @ArneBruinse : wij stellen voor om dit op te lossen via een regel in de documentatie, zodat niet de validatie techniek hier enorm voor aangepast moet worden. Dit kan makkelijk gewoon door de software leveranciers zelf in de software geborgd worden.