Toetsen of het Wat geleverd is
In het artikel over de levering, implementatie en opleiding is al ingegaan op de centrale Wat- en Hoe-vraag. Idealiter wordt daarbij voldoende precies afgesproken aan welke eisen de software moet voldoen en Hoe en Wanneer die software wordt opgeleverd. De acceptatieprocedure is de formele procedure om vast te stellen of het Wat voldoet aan de overeengekomen specificaties.
In de acceptatieprocedure wordt dus over het algemeen opgenomen:
- De wijze waarop er getoetst wordt: dit wordt meestal uitgewerkt in een bijlage (plan van aanpak bijvoorbeeld).
- Wanneer van acceptatie sprake is: als de software voldoet aan de overeengekomen specificaties en is vastgesteld dat de software anderszins ook geschikt is voor normaal gebruik door de afnemer. Let er op dat hierbij ook goed wordt gekeken naar de uitkomsten van de migratie/conversie van data. Het is mooi dat de software voldoet aan alle overeengekomen eisen, maar de data moet ook op de juiste plek uit het nieuwe systeem kunnen worden gehaald.
- In hoeverre kleine gebreken acceptatie in de weg mogen staan: kleine gebreken zijn meestal gebreken die ingebruikname van de software niet hoeven te beletten. Meestal wordt overeengekomen dat dergelijke gebreken de acceptatie niet in de weg mogen staan, met die kanttekening dat die gebreken wel zo spoedig mogelijk alsnog moeten worden hersteld.
- Of er een separate integrale acceptatietest plaatsvindt of niet. En zo ja, welke aanvullende eisen daarvoor dan gelden (performance, keten-test, etc.).
- Wat de gevolgen zijn bij niet-acceptatie: bijvoorbeeld een of meerdere herstelmogelijkheden en hertesten. En eventueel ook het recht om de overeenkomst te ontbinden en schadevergoeding te vorderen als na twee of drie mislukte tests geen acceptatie volgt.
Het doorlopen van de acceptatieprocedure moet een helder beeld opleveren over:
- Is de software klaar om in gebruik te nemen?
- Is de noodzakelijke data op de juiste wijze gemigreerd/geconverteerd?
- Zijn alle medewerkers voldoende opgeleid?
- Welke restpunten zijn er en wanneer zijn die opgelost?
Dit alles moet er toe leiden dat de afnemer het gerechtvaardigde besluit kan nemen om de software te gaan gebruiken. Dit is een belangrijk besluit omdat dit het einde van de ontwikkeling/levering/implementatiefase betekent en de gebruiks- en onderhoudsfase doet beginnen waarbij partijen andere rollen gaan krijgen. Daarover meer in volgende artikelen in deze serie.
Waarom een beëindigingsmogelijkheid aanbrengen na mislukte tests?
Door af te spreken dat bij niet-acceptatie de afnemer gerechtigd is om de overeenkomst te ontbinden wordt in feite contractueel invulling gegeven aan de wettelijke vereisten rondom verzuim, ingebrekestelling en ontbinding. Het voorkomt dat er alsnog een ingebrekestelling moet worden verstuurd. Let op: op grond van de wet moet de ingebrekestelling een reële kans bieden aan de leverancier om alsnog deugdelijk te presteren. Dit kan tot aanzienlijke extra vertraging leiden.
Verder gaat de wet (artikel 6:265 BW) ervan uit dat elke tekortkoming de ontbinding rechtvaardigt, "tenzij de tekortkoming gezien haar bijzondere aard of geringe betekenis deze ontbinding niet rechtvaardigt.” Dit levert uiteraard snel discussie op over “het gewicht” van de tekortkoming, zeker bij grote softwareprojecten waar de belangen van beide partijen bij nakoming van de overeenkomst heel groot kunnen zijn. Door een expliciete ontbindingsregeling op te nemen in de acceptatieregeling wordt een discussie over het gewicht van de tekortkoming voorkomen, mits maar aan de voorwaarden van die regeling wordt voldaan.
Aandachtspunten:
Bij het optuigen van een acceptatieprocedure gelden wel een aantal aandachtspunten:
- Acceptatie is geen garantie op geen gebreken: Acceptatie na het doorlopen van de acceptatieprocedure betekent niet dat er nooit meer een bug, gebrek of storing in de software kan zitten. Daarvoor dienen de garantieregeling en de onderhoudsregeling.
- De garantieregeling (kosteloos herstellen van later opkomende gebreken) is bedoeld om de software te laten voldoen aan de oorspronkelijke specificaties. De leverancier draagt hier dus het risico. Vaak wordt deze periode beperkt in tijd (bijvoorbeeld 6 maanden). Daarna valt men terug op de onderhoudsverplichting.
- De onderhoudsregeling wordt doorgaans gebruikt om later opkomende gebreken te herstellen of om de software compatibel te houden met andere programmatuur (bijvoorbeeld nieuwe versies van platform-programmatuur).
- Toetsen aan specificaties niet alomvattend: Uiteraard zal de software moeten voldoen aan de specificaties en zal dit moeten worden getoetst. Los van de specificaties (wat in feite het aflopen van een checklist kan zijn) is het van belang om ook vast te stellen of software in algemene zin geschikt is om in gebruik te kunnen nemen. Dit gaat veel verder dan alleen maar vaststellen of alle overeengekomen functionaliteiten aanwezig zijn. Doorgaans moet de software een bepaald proces ondersteunen waarbij de software slechts een onderdeel is van een groter geheel. Dit kun je toetsen door een “real life case” bij de hand te pakken en te
toetsen hoe de software daarmee om gaat. - Stress-tests: Er zal ook getest moeten worden of de software blijft functioneren bij een grote belasting (bijvoorbeeld veel gebruikers tegelijk) en/of bij grote hoeveelheden data. Het is natuurlijk mooi dat de software in een soort klinische omgeving doet wat het moet doen, maar dat wil niet zeggen dat dit ook het geval is in een groter geheel.
- OTAP-straat: het is gebruikelijk om afspraken te maken over OTAP. Dit houdt in dat er voor de Ontwikkeling, Testen (kwaliteitstest van de leverancier), Acceptatie, en voor de Productie (gebruiksomgeving) separate softwareomgevingen worden ingericht. Zodoende kunnen aanpassingen aan de software of nieuwe versies alvast worden ontwikkeld, getest en door de afnemer worden onderworpen aan een acceptatieprocedure zonder dat dit enig gevolg heeft voor de software die feitelijk gebruikt wordt in de productieomgeving. Als de nieuwe versie of release is geaccepteerd kan die nieuwe versie in de Productieomgeving worden geplaatst (“deployen”) om daadwerkelijk te worden gebruikt door de afnemer.
Conclusie
Een goede acceptatieregeling is dus van groot belang. Niet alleen toets je hiermee of er geleverd is wat is afgesproken en of de software ook daadwerkelijk in gebruik kan worden genomen. Het markeert ook een heel belangrijk punt: ofwel partijen stoppen er mee (niet-acceptatie) ofwel gaan over tot de gebruiks- en onderhoudsfase.
Leest u vooral ook de andere onderwerpen uit onze serie IT-contracten en blijf het geheel in samenhang bekijken.
