In de onderstaande afbeelding is op de eenvoudigste wijze weergegeven hoe de gebruiker omgaat met het systeem. De gebruiker voert gegevens in waarna het systeem deze omzet en het weer terugkoppelt aan de gebruiker. Voor de gebruiker zal in eerste instantie niet duidelijk zijn welke gegevens het systeem terugkoppelt, in hoeverre er reeds een transformatie heeft plaatsgevonden en of dat de input dan wel de output niet correct is.
Op het moment dat een gebruiker een
melding indient dan zal dat zijn omdat hij een afwijking heeft gevonden op wat
hij verwacht had. Het kan ook zijn dat de gebruiker op een bepaald moment niks
verwacht had maar toch een terugkoppeling uit het systeem krijgt. In de
bovenstaande afbeelding zit de gebruiker op het moment dat hij een melding
doorgeeft aan de beheerders van het systeem dus in zijn beleving altijd aan de
Output-Fout kant. Voor de analyse is het noodzakelijk dat de gebruiker
communiceert wat de gebruiker te zien krijgt, wat hij daar dan verwacht had en
waarom hij dat daar verwachte. Maar ook welke handelingen hij verrichte voordat
de afwijking aan hem gepresenteerd werd.
De gebruiker zal dus uit zich zelf
de volgende vragen moeten beantwoorden:
Waarom wilt de gebruiker het opgelost zien? Waarom is het een probleem?
Wat is het probleem precies? Waarom juist dat?
Waar treedt het probleem op? Waarom juist daar?
Wanneer treedt het probleem op? Waarom juist dan?
Wie is/zijn bij het probleem betrokken? Waarom juist hij/zij?
Hoe gebeurt het? Waarom
op die manier?
Het is belangrijk dat de gebruiker zelf de afwijking
kan reproduceren, dit onder woorden kan brengen en eventueel kan communiceren
aan de hand van screenprints en loggingen. Een voorbeeld spreekt immers
boekdelen en een plaatje zegt meer dan een duizend woorden. Een referentie naar
een FO, TO of een andere bron waarin requirements staan beschreven worden zeer
op prijs gesteld. Alleen als aan al deze
voorwaarden is beantwoord kan een gedegen analyse door de beheerders van het
systeem gemaakt worden. Indien deze informatie ontbreekt dan zal dit opgevraagd
moeten worden bij de gebruiker die de melding heeft ingediend voordat het euvel
serieus aangepakt kan worden.
Zodra de melding door
de klant gemeld wordt aan de beheerders van het systeem zal deze dusdanig
bewerkt moeten worden dat het voor andere gebruikers duidelijk is waar het om
gaat. Daarom mag in de verklarende beschrijving geen rechtstreekse kopie staan
van de initiële melding van de gebruiker. Dit is ook om bij alle vervolg
stappen van het proces sneller te laten doorlopen en miscommunicatie te
voorkomen.
De analyse valt uit
één in twee gedeeltes, het functionele en van daar uit de technische analyse.
De beheerders van het systeem moet zich er voor hoeden dat in deze fase gedegen
informatie wordt geproduceerd en niet de analyse een (al dan niet gehele) kopie
betreft van de verklarende beschrijving . Of nog erger dat de verklarende
beschrijving leeg wordt gelaten. In de functionele analyse moet staan hoe de
functie wordt aangeroepen, wat de gebruikte invoergegevens zijn en welke
sources voor de spaak zorgen. Dit kan dan vervolgens na verdere analyse aangevuld worden met pseudo-code. Niet alleen de juist situatie dient
beschreven te worden maar ook de fout situatie en op welke manier dit
gecommuniceerd dient te worden richting de gebruiker. Na de functionele analyse
vindt de technische analyse plaats indien de functioneel specialist dit nodig
acht. Dit is het geval als blijkt dat de melding van de klant niet door middel
van sturingstabellen is op te lossen. Bij de technische analyse dient te worden
beschreven aan welke objecten nieuwe code toegevoegd moet worden en/of in welke
objecten oude code zal worden aangepast dan wel verwijderd. (Met een uitgebreide
beschrijving welke code dit dan betreft.) Daarnaast wordt tijdens de technische
analyse beschreven in welke laag van de applicatie de aanpassing plaats zal
vinden. Denk daarbij grof weg aan: schermen, database, transport en/of de
data-dictionary, repository of zelfs opleidingsmateriaal.
De uiteindelijk toegepaste
oplossing wordt volledig, uitvoerig en eenduidig beschreven in de bevinding’s
artefact. Deze oplossing wordt uiteindelijk naar de klant teruggekoppeld.
Als laatste komt de
tester om de hoek kijken, voor de tester is het belangrijk dat het bovenstaande
volledig is uitgevoerd. Anders zal de tester geen simulatie uit kunnen voeren
met de eindgebruiker in gedachten. Dit omdat de tester de bovenstaande gegevens
zal omvormen tot testscripts en die zal proberen uit te voeren. Daarvoor is het
dus nodig dat de tester toegang heeft tot een stabiele omgeving waarin geen
technische of functionele werkzaamheden plaats vinden.
Zou dit niet fantastisch zijn als dit allemaal
gebeurd is, helaas is dit maar zelden het geval. Net zo zelden als dat een
gebruiker weet wat hij doet en een opdrachtgever weet wat hij opgeleverd wilt
krijgen. Net zo zelden als alle partijen op één lijn zitten en net zo zelden
als de roadmap die aan het begin gemaakt wordt gaande de tijd overeind blijft
staan. Net zo zelden als een melding een alleen staand geval is en net zo
zelden als van te voren duidelijk is wanneer we klaar zijn als dat we een
onuitputtelijke bron van resources hebben.
Deze zeldzaamheden maakt dat we nog twee vragen
beantwoord moeten krijgen:
Welke werkzaamheden doen we
eerst? Waarom juist die?
Wat voor terugkoppelingen verwacht
je? Waarom juist dan?
Geen opmerkingen:
Een reactie posten