Als men een huis gaat kopen weet men exact aan welke eisen het huis moet voldoen. De beslissing wordt gemaakt op basis van wensen en eisen (requirements) van de koper van het huis. De ligging van het huis, de grootte van het huis de prijs en ga zo maar door. Dit geldt niet alleen voor een huis, maar ook voor een auto, vakantie of elektronische apparatuur.
Gek genoeg gebeurt het specificeren van een softwareapplicatie te beperkt. Dit is een algemeen probleem binnen de ICT. Het specificeren, als er al gespecificeerd wordt, richt zich voornamelijk op functional requirements. De non-functional requirements worden meestal niet gespecificeerd. Een reden hiervoor zou kunnen zijn dat non-functional requirements minder tastbaar zijn. Met dit blog hoop ik een verandering in denkwijze over te brengen bij systeemarchitecten en business-acceptanten zodat er in een vroeg stadium al nagedacht wordt over performance.
Voor een performance consultant is de eerste stap van het performancetesttraject het houden van de technische intake. Bij de technische intake worden de voorbereidingen getroffen voor de uitvoer van de performancetest. Onder andere het verkrijgen van klikpaden, toegang tot de applicatie regelen, kennismaking met het project en het opvragen van de performance requirements. Wat zijn de acceptatiecriteria van het project? Hoe “snel” moet de applicatie zijn? Deze vraag wordt bijna altijd beantwoord met de vraag:
“Wat is gangbaar”?
Dat is helaas een lastige vraag. Als je de homepage opvraagt van bijvoorbeeld een zoekmachine verwacht je een andere responstijd dan wanneer je een vliegticket opzoekt bij een ticketvergelijkingssite. Er is dus geen standaard antwoord op te geven. Daarom is het van belang dat er duidelijkheid bestaat voordat een applicatie ontwikkeld wordt, en wat de responstijden (percentiel/gemiddelde) moeten zijn van de functionaliteiten en pagina’s van de nieuwe applicatie. Dit geeft ontwikkelaars ook een idee wat de gebruiker verwacht bij bepaalde functionele handelingen. Als er voor specifieke functionele handelingen in een applicatie performancecriteria bekend zijn, kan dit opgenomen worden in een functioneel- of technisch ontwerp. Hierdoor wordt er vroegtijdig in de ontwikkeling van de applicatie performance awareness gecreëerd bij de ontwikkelaars van de applicatie, zodat een ontwikkelaar, los van de functionaliteiten, ook nadenken over wat een gebruiker verwacht qua performance.
“Wie moet deze performance requirements dan opstellen?”
Dit is een vraag die ook vaak wordt gesteld tijdens een intake. De ontwikkelaars zelf? Systeembeheer? Voor het antwoord op deze vraag refereer ik naar de eerste alinea. Als je iets koopt bepaal je zelf waar iets aan moet voldoen en kies je het juiste product. Dus de business moet aangeven wat gewenst is. De business bepaalt toch ook welke functionaliteiten beschikbaar moeten worden in de applicatie?
Het resultaat zal zijn dat een performancetester beter advies kan geven of de applicatie voldoet aan de verwachtingen van de business, waardoor de drempel van acceptatie van de applicatie door uw klanten wordt verlaagd.
Raymond Steenvoorden
