ICT Projecten deel 7: Afspraken maken over kwaliteit

Goed contracteren over de kwaliteit van de software begint met een gemeenschappelijk referentiekader voor de beoordeling van die kwaliteit. Een goed vertrekpunt is ISO/IEC 25010. Deze norm bevat een raamwerk voor de beoordeling van de kwaliteit van ICT-systemen, waaronder programmatuur.

ISO/IEC 25010 maakt onderscheid tussen verschillende kwaliteitsaspecten, zoals betrouwbaarheid, veiligheid, snelheid, gebruiksgemak en onderhoudbaarheid. Niet alle aspecten zullen steeds in gelijke mate van belang zijn voor de klant. Wie software koopt om deze zelf door te ontwikkelen zal daaraan andere eisen stellen dan een klant die een standaard SaaS-dienst afneemt. Voor de eerste zal de onderhoudbaarheid van de software bij uitstek van belang zijn en voor de laatste zal vooral de functionele scope, de beschikbaarheid en het gebruiksgemak ertoe doen.

ISO/IEC 25010 houdt hiermee rekening en benadert het probleem van de kwaliteit van software daarom vanuit het perspectief van de betrokken stakeholders. Softwarekwaliteit volgens ISO/IEC 25010 is: “the degree to which the system satisfies the stated and implied needs of its various stakeholders and provides value”.

Een referentiekader alleen is uiteraard niet genoeg. Dat referentiekader zal vervolgens vertaald moeten worden naar specifieke kwaliteitsafspraken. ISO/IEC 25010 voorziet in indicatoren en meetvoorschriften voor het meetbaar maken van kwaliteitskenmerken, maar bevat geen concrete prestatienormen. De norm beschrijft met andere woorden wel hoe de responstijd van een systeem gemeten kan worden, maar niet wat de responstijd in een concrete toepassing moet zijn. Dit zal logischerwijs afhangen van het type applicatie en het doel waarvoor de applicatie wordt ingezet.

Van belang is dus dat voor ieder systeem wordt uitgewerkt welke kwaliteit concreet van een kwaliteitskenmerk verwacht mag worden. Dat kan worden gedaan door een specifieke norm op te nemen, bijvoorbeeld dat de responstijd maximaal drie seconden mag zijn. Of – iets algemener – dat een webapplicatie in ieder geval zal beschermen tegen de meest kritieke beveiligingsrisico’s volgens de OWASP Top 10. Maar ook kan worden gedacht aan verwijzing naar relevante benchmarks. Zo bestaat er een door TÜV gecertificeerde methode waarbij het kwaliteitskenmerk onderhoudbaarheid wordt getoetst op basis van een benchmarkmodel.

Het is overigens niet nodig om steeds voor alle aspecten van ISO/IEC 25010 concreet en meetbaar uit te werken welke kwaliteit daarvan verwacht mag worden. Vaak kan worden volstaan met uitwerking voor die eigenschappen die voor de betreffende toepassing bij uitstek relevant zijn.

Goede afspraken maken over softwarekwaliteit is dus mogelijk en belangrijk, maar gebeurt lang niet altijd. In de praktijk wordt dikwijls volstaan met het maken van geen of slechts summiere afspraken op dit onderwerp. Een interessante vraag is wat dit betekent voor de klant als de kwaliteit niet aan de verwachtingen voldoet. Staat de klant dan per definitie met lege handen? Het antwoord daarop luidt: nee, niet per se.

Ook wanneer geen expliciete afspraken zijn gemaakt over softwarekwaliteit mag een klant in veel gevallen een minimaal kwaliteitsniveau verwachten. Belangrijk in dat verband is de aard van de overeenkomst. Bij de verwerving van software wordt gebruikgemaakt van twee typen in het Burgerlijk Wetboek genoemde overeenkomsten: i) men koopt een licentie op standaardsoftware of ii) men geeft opdracht tot ontwikkeling van maatwerksoftware of het ter beschikking stellen van software als dienst (SaaS, PaaS, IaaS).

In de kooptitel is een regeling opgenomen over conformiteit. Het onderwerp van een koopovereenkomst moet de eigenschappen bezitten die de koper op grond van de overeenkomst mocht verwachten, waaronder de eigenschappen die voor normaal gebruik nodig zijn en waarvan de koper de aanwezigheid niet behoefde te betwijfelen. De conformiteitsregeling impliceert dus dat een afnemer recht heeft op een zeker minimum aan kwaliteit.

Maar let op: professionele partijen kunnen contractueel afwijken van artikel 7:17 BW. Een ‘as is’ bepaling kan worden beschouwd als zo’n afwijkende bepaling. De strekking van een dergelijke bepaling is dat de software door de klant wordt geaccepteerd in de staat waarin deze afgeleverd wordt, met inbegrip van alle zichtbare en onzichtbare gebreken. Voor professionele partijen kan dit betekenen dat het niet mogelijk is een beroep te doen op de conformiteitsregeling, tenzij dit onaanvaardbaar zou zijn naar maatstaven van redelijkheid en billijkheid. Het is voor afnemers dus zaak alert te zijn op een dergelijke ‘as is’ bepaling.

De overeenkomst op basis waarvan maatwerkprogrammatuur wordt ontwikkeld of op basis waarvan software als dienst ter beschikking wordt gesteld geldt als een overeenkomst van opdracht. De opdrachttitel kent geen conformiteitseis zoals de kooptitel die kent. Wel is de opdrachtnemer verplicht om de zorg van een goed opdrachtnemer in acht te nemen. Meer concreet betekent dit dat de ICT-leverancier de software moet ontwikkelen c.q. ter beschikking moet stellen als een redelijk bekwaam en redelijk handelend vakgenoot.

Wat betekent deze laatste norm voor de kwaliteitseisen die aan software gesteld mogen worden? Dat hangt allereerst af van de (beroeps)normen die gelden in de ICT. In de meeste sectoren zien beroepsnormen in de eerste plaats op gedrag en pas in de tweede plaats op de inhoudelijke kwaliteit van de werkzaamheden. Denk aan de gedragsregels die van toepassing zijn op de advocatuur. Deze regels zien vooral op de opstelling van de advocaat richting de cliënt en niet zozeer op de juridisch-inhoudelijke kwaliteit van de verrichte werkzaamheden. Dergelijke gedragsnormen zijn dus niet erg behulpzaam.

Iets soortgelijks is helaas zichtbaar in de jurisprudentie over de zorgplicht van ICT-leveranciers. In verreweg de meeste gevallen waarin een schending van een zorgplicht door een ICT-dienstverlener wordt aangenomen, gaat het om schending van een informatie- of waarschuwingsplicht. Dat wil zeggen: de ICT-dienstverlener schiet tekort in zijn rol als adviseur of projectleider. Zo is aangenomen dat een IT-leverancier zijn zorgplicht kan schenden wanneer hij slecht projectmanagement levert, de klant inadequaat informeert over de voortgang van een project, nalaat de klant te waarschuwen over de gevolgen van diens wijzigingsvoorstellen, of onvoldoende waarschuwt over een risicovolle back-upstructuur.

Toch kunnen ook kwaliteitsaspecten langs de band van de zorgplicht worden meegewogen bij de uitleg van een overeenkomst. Zo oordeelde de rechtbank Amsterdam in 2019 dat een ICT-leverancier zijn zorgplicht had geschonden door een CRM-systeem op te leveren dat voortdurend foutmeldingen gaf, vaak niet beschikbaar was en bovendien bewerkelijk was in het gebruik.

Omdat de zorgplicht van een IT-leverancier een relatief vage norm is die bovendien vooral ziet op gedrag en minder op kwaliteit, is het bij IT-dienstverlening gebruikelijk dat partijen een Service Level Agreement (SLA) sluiten. In de SLA wordt de zorgplicht voor wat betreft het kwaliteitsaspect als het ware nader ingekleurd en worden concrete afspraken gemaakt over de kwaliteit die de klant van de dienstverlening mag verwachten. Onderwerpen die in de SLA in ieder geval niet mogen ontbreken zijn:

• Beschikbaarheid van de dienst;
• Procedures ten aanzien van gepland en ongepland (nood)onderhoud;
• Bereikbaarheid en reactietijd van de service desk;
• Procedures (en soms oplostijd) bij foutmeldingen;
• Procesafspraken ten aanzien van de roadmap van de IT-leverancier en het beschikbaar maken van updates en nieuwe versies; en
• Service kredieten voor het geval het serviceniveau niet wordt gehaald.

Een bijzonder aandachtspunt bij het onderhandelen over een SLA is de zogenaamde exclusieve remedie clausule. Een dergelijke clausule heeft de strekking dat de remedies van de klant bij schending van de SLA beperkt zijn tot een specifieke sanctie, meestal vergoeding van een service krediet. Kwaliteitsafspraken kunnen nog zo concreet en ‘streng’ zijn opgesteld, maar als de sanctie op overtreding weinig voorstelt, dan hebben de afspraken nog altijd relatief weinig waarde. Onder omstandigheden zal het goedkoper zijn voor de leverancier om te wanpresteren.

• Een goed vertrekpunt bij het maken van afspraken over softwarekwaliteit is om overeen te komen dat software zal voldoen aan (relevante aspecten van) ISO/IEC 25010. Idealiter worden de belangrijkste kenmerken vervolgens concreet en meetbaar uitgewerkt in het contract.
• Voor het maken van meer specifieke kwaliteitsafspraken kan worden aangesloten bij relevante normenkaders en benchmarks. Denk aan ISO/IEC 27001 voor algemene informatiebeveiliging, ISO/IEC 27017 voor de beveiliging van clouddiensten, de OWASP Top 10 voor de beveiliging van webapplicaties, ITIL voor dienstverlening, of het door TÜV gecertificeerde benchmarkmodel voor onderhoudbaarheid.
• Denk bij het formuleren van een SLA goed na over de aard van de service levels: is de leverancier daadwerkelijk verplicht om een specifiek resultaat te bereiken of moet deze enkel een bepaalde inspanning leveren? Kan de leverancier een beroep doen op overmacht? Hoe verhoudt de SLA zich tot de wettelijke zorgplicht van de IT-leverancier?
• Afnemers moeten in het bijzonder alert zijn op ‘as is’ bepalingen in softwarecontracten en ‘exclusieve remedie’ clausules in SLA’s. Deze clausules kunnen de rechten en verhaalsmogelijkheden van afnemers sterk beperken. Voor leveranciers zijn zulke bepalingen juist gunstig.

Heeft u vragen over het succesvol uitvoeren van ICT-projecten, neem dan contact op met Jeroen van Helden, advocaat IT, Privacy & Cybersecurity.

De inhoud van deze blog is onderdeel van ‘ICT Projecten: een praktische handreiking’, een bundeling van artikelen over het succesvol uitvoeren van een ICT-project. Klik hier om de praktische handreiking te downloaden.

Wil je elke maand een overzicht van updates en blogs in je mailbox? Klik dan hier om je in te schrijven voor de nieuwsbrief!