Succes hangt vaak samen met vertrouwen. Met name in het bedrijfsleven en politiek komt dit maar al te vaak naar voren: ministers die na een motie van wantrouwen aftreden en beurskoersen die door een voorspelling of typefout onnodig fluctueren of zelfs crashen. Ook in de ict draait succes in veel gevallen om vertrouwen. Met name ontwikkelaars lijken het hierin niet altijd even makkelijk te hebben en worden regelmatig bekritiseert.
Wie herinnert zich niet de lancering van Windows Vista? Een introductie die het imago van Windows destijds een flinke deuk deed oplopen. De vraag is dan ook hoe met vertrouwen om te gaan en uiteraard, hoe wordt vertrouwen na een flinke deuk weer hersteld?
Gevoel van veiligheid
Allereerst is het goed om te bekijken hoe het komt dat het vertrouwen zo laag is. Tegenwoordig zien we steeds vaker dat dit te maken heeft met veiligheid. Het gaat bij zowel vertrouwen als veiligheid om een gevoel. Dit gevoel wordt gevoed door zaken die we zelf hebben meegemaakt, verhalen van familie en vrienden of uit de media.
Ook in de ict-wereld wordt het vertrouwen en het gevoel van veiligheid bepaald door ervaringen en verhalen. Deze ervaringen en verhalen gaan dan over botnets, virussen, spyware, maar ook over hoaxes (e-mails die je waarschuwen voor nepbedreigingen). De IT-wereld toont hiermee dus veel overeenkomsten met de ‘echte' wereld.
Er kan zelfs gesteld worden dat de computergebruiker zich tegenwoordig minder veilig voelt dan vroeger. Vroeger was het voldoende om af en toe een virusscanner te draaien, nu is het draaien van firewall software en het uitvoeren van regelmatige beveiligingsupdates niet meer weg te denken.
De computergebruiker voelt zich minder veilig, maar betekent dit ook dat de gebruiker minder vertrouwen heeft in de programmatuur? Ja en nee. Het overgrote deel van het vertrouwen komt voort uit hoe goed een systeem werkt. Wantrouwen ontstaat meer door het algemene gevoel van veiligheid. Ondanks dat een computer doet wat hem is opgedragen blijkt het systeem toch niet altijd goed te werken.
Verborgen requirements
Een veel gehoorde kreet tijdens het testen van een systeem is: "Ja hij doet het wel, maar …". De tester komt in het maar-gedeelte dan met nieuwe requirements. De ontwikkelaar reageert dan vaak: "Dat stond niet gespecificeerd, dus dat maken we niet". Afhankelijk van de situatie wordt hier vervolgens een oplossing voor gevonden.
Als er goed gekeken wordt naar welke requirements meestal missen, dan blijken dit vaak de aanvullende requirements te zijn (of zoals soms genoemd non-functional requirements). Deze requirements gaan over bijvoorbeeld performance, bruikbaarheid, schaalbaarheid, betrouwbaarheid (zie bijvoorbeeld ISO 9126 of QUINT2 voor een goede verdeling hiervan). De aanvullende requirements specificeren als het ware de softwarekwaliteit. Door de klant wordt er vaak vanuit gegaan dat de softwarekwaliteit wel goed is. Toch blijkt dan tijdens testen dat de klant (of tester) en de ontwikkelaar hier toch verschillen van mening.
De mate waarin op softwarekwaliteit wordt gelet verschilt met het soort systeem dat wordt gebouwd. Voor mission critical systemen, zoals transactiesystemen bij een bank, wordt er doorgaans meer gelet op softwarekwaliteit dan op een intranetsite die snel uitgerold moet worden.
Toch lijkt de publieke opinie sterk te oordelen over slechte softwarekwaliteit. Denk nog eens terug aan Windows Vista. De publieke opinie werd vooral bepaald doordat Windows Vista langzaam zou zijn. Microsoft heeft veel geïnvesteerd om dit met Windows 7 weer te herstellen.
Hieruit blijkt dat er als het ware met twee maten wordt gemeten. Er worden requirements opgeschreven/vastgesteld waar een systeem aan moet voldoen, maar uiteindelijk wordt er grotendeels naar andere zaken gekeken tijdens het opleveren. Softwarekwaliteit is voor de klant in eerste instantie niet belangrijk, maar uiteindelijk wordt het eindoordeel er wel op gebaseerd. Een functie minder is dan lang zo erg niet.
Extra aandacht
Het is dus belangrijk om tijdens ontwerpen, ontwikkelen, testen, en opleveren extra rekening te houden met softwarekwaliteit. Hierbij gaat het vooral om het expliciet maken van de verwachte softwarekwaliteit. Op deze manier ontstaat er een duidelijk beeld van wat het systeem in zijn totaliteit zal gaan doen in plaats van alleen op gebied van functionaliteit. Softwarekwaliteit specificeren en meetbaar maken is niet altijd eenvoudig, maar gelukkig zijn er modellen zoals ISO 9126 en QUINT2. Verder wordt er door CISQ (http://www.it-cisq.org/) hard gewerkt aan het opstellen van standaarden voor het specificeren van softwarekwaliteit.
Een ander aandachtsgebied is de houding van de ontwikkelaar. Sommige ontwikkelaars richten zich eerst op het bouwen van functionaliteiten, en kijken daarna pas naar de aanvullende requirements (zoals performance). In veel gevallen is het dan al te laat. Er is dan vaak geen mogelijkheid meer om de performance radicaal te verbeteren omdat het systeem reeds voor 80% gebouwd is. De performance is een afgeleide van de gekozen softwarearchitectuur. Het is dan ook belangrijk om een architectuur in vroeg stadium te testen op de aanvullende requirements en dit vervolgens regelmatig te herhalen. Op deze manier kan op ieder moment besloten worden om het systeem zoals het dan is in productie te nemen. Het enige dat ontbreekt is functionaliteit, maar het systeem werkt prima en voldoet aan de aanvullende requirements.
Ondersteuning management
Investeren in softwarekwaliteit is soms nog moeilijk te verkopen. Ook hier lijkt de achterliggende gedachte te zijn dat er een standaardkwaliteit wordt geboden. Specificeer deze standaardkwaliteit dus ook en zorg dat dit geleverd wordt. Maak softwarekwaliteit onderdeel van normale systeemontwikkeling en zorg dat het niet het kind van de rekening wordt. De juiste support van het management is daarvoor van belang. Ga eens het gevecht aan en kies voor minder functionaliteit, maar met een betere kwaliteit.
Nounou. Wel een beetje pretentieus artikel, hoor.
Beste schrijver, kan je onderbouwen waarom ‘het vertrouwen zo laag is’? Waar baseer je dat op?
Dan over de verborgen requirements die je noemt, en de poging tot het in verband brengen met vertrouwen. Laten we vaststellen dat we met het maken van software proberen te realiseren dat we de manier waarop we met elkaar werken en communiceren proberen te automatiseren. Wake-up call: communiceren is vooral een intuïtief proces. Dat is niet digitaal. Dat kan je slechts omzetten in een model. En een model is nooit de werkelijkheid.
Wat jij vertrouwen noemt, is volgens mij niet meer dat het snijvlak van afspraken tussen ontwikkelaar en afnemer dat beschrijft waar werking, zowel functioneel als non-functioneel, ophoudt en context begint.