Testen & acceptatie van software: enkele juridische aspecten

Presentatie over: "Testen & acceptatie van software: enkele juridische aspecten"— Transcript van de presentatie:

1

2 Testen & acceptatie van software: enkele juridische aspecten
NGI – Afdeling IT-Recht, 10 november 2011 Mr. Peter van Schelven

3 Recht is geen ‘regelkunde’, maar een ‘expectancy-kunde’

4 Verwachtingen? precontractuele communicatie (sales, RFP, offerte etc)
reclame inhoud tekst van contract afspraken tijdens het project (agile, scrum, RAD, IAD etc) proof of concept, functionele en technische specificaties en ontwerpen het oude systeem communicatie tijdens project juridisch kernprobleem: onderlinge afstemming van communicatie juridisch voorbeeld: Rechtbank Nanterre 14 mei 1982

5 Verwachtingen o.g.v. de wet? (1)
Voorbeeld: EG-RICHTLIJN 14 juni 1993 betreffende medische hulpmiddelen Art. 1 lid 2 sub a: medisch hulpmiddel: elk instrument, toestel of apparaat, elke stof of elk ander artikel dat of die alleen of in combinatie wordt gebruikt, met inbegrip van de software die voor de goede werking ervan benodigd is, en ……… diagnose, preventie, bewaking, behandeling of verlichting van ziekten etc… Art. 3: De hulpmiddelen moeten voldoen aan de in bijlage I neergelegde essentiële eisen die erop van toepassing zijn, rekening houdend met de bestemming van de betrokken hulpmiddelen.

6 Verwachtingen o.g.v. de wet? (2)
Eisen t.a.v. ontwerp, fabricage en verpakking. Voorbeeld art Bijlage I: “Hulpmiddelen met programmeerbare elektronische systemen moeten zodanig zijn ontworpen dat herhaalbaarheid, betrouwbaarheid en prestatievermogen van deze systemen overeenkomstig het beoogde gebruik, gewaarborgd zijn. In geval van een eerste fouttoestand (in het systeem) ( "single fault condition") moeten er passende maatregelen worden getroffen om de daaraan verbonden risico's zoveel mogelijk uit te te schakelen of te verminderen.”

7 V & V –definities (Boehm)
Verificatie => are we building the product right? (IEEE => proces of evaluating a system or component to determine whether the products or a given development phase satisfy the conditions imposed at the start of that phase) Validatie => are we building the right product? (IEEE => proces of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements)

8 Contractuele levels van commitment
‘as-is’ leverantie conformance to specification fitness for use fitness for purpose

9 5 perspectieven op kwaliteit (Garvin)
een transcedent perspectief een ‘product-based’ perspectief een ‘user-based’ perspectief een ‘manufacturing-based’ perspectief een ‘value-based’ perspectief

10 Fouten, gebreken (1) Juridisch definitie ≠ ICT-technische definitie
Aanwezigheid fout, gebrek ≠ wanprestatie Biza-modelcontract = ‘user based’ `‘het niet (volledig) voldoen van de programmatuur aan de overeengekomen specificaties, dan wel het anderszins niet naar behoren functioneren van de programmatuur.’ ICT~Office Voorwaarden = ‘manufacturing based’ ‘het substantieel niet voldoen aan schriftelijk uitdrukkelijk overeengekomen functionele of technische specificaties.’

11 Fouten, gebreken (2) ARBIT 2010 = ‘user based’
Iedere storing en/of ander mankement als gevolg waarvan de Prestatie niet geschikt is voor het Overeengekomen gebruik. Overeengekomen gebruik = het door Opdrachtgever beoogde gebruik van de Prestatie zoals dat ten tijde van het sluiten van de Overeenkomst op grond van het Bestek en/ of op basis van de in artikel 4 bedoelde informatie, voor Wederpartij kenbaar is of redelijkerwijs moet zijn, een en ander voor zover dat gebruik in de Overeenkomst niet uitdrukkelijk is uitgesloten of beperkt.

12 Rechtszaken maatwerksoftware
Rechtbank Rotterdam: geen specs, toch belang gebruiker op goed werkend programma voorop. Dus softwareontwikkeling is resultaatsverplichting. Rechtbank Utrecht: software moet geschikt zijn voor normaal gebruik. Groot aantal zaken wegens schenden waarschuwingsplicht of wegens falend projectmanagement

13 Contractuele aspecten fouten
Object van testen door klant: executable code; broncode; documentatie? Contractuele aspecten foutenbegrip Reikwijdte definitie? Wel/niet koppelen aan doelstellingen klant of alleen aan ‘specs’? Wel/niet koppelen aan contractuele garantieregeling? Uitsluiting van subjectieve aspecten (cosmetica)? Uitsluiting van bepaalde kwaliteitseigenschappen van software? Beperken tot reproduceerbare fouten? Hoe en wanneer worden gebreken gerapporteerd? Procedure voor het erkennen en classificeren van gebreken? Trechtermodel of is er ruimte voor claim wegens ‘verborgen’ gebreken’? Faultinjection als testmethode?

14 Contractuele gevolgen van fouten en gebreken?
Duiding van de rol van ICT-bedrijf mede o.g.v. overeengekomen testregeling: wel of geen system-integrator? Herstelplicht binnen acceptatieprocedure en binnen de garantieregeling? Onderhoudsplicht bij onderhoudscontract? Let op samenhang van contract inzake leverantie en onderhoud Vgl. Hoge Raad 15 april 2011 = > onderhoudsovereenkomst is geen vrijbrief voor gebreken Melden van gebreken binnen “bekwame termijn”; art. 6:89 BW Aansprakelijkheid leverancier?

15 Pres. Rb Almelo 1999 (Genap/Improve)
“… Improve (= softwareleverancier, PvS) heeft terecht gesteld dat fouten in computersystemen niet zijn uit te sluiten. Mede vanwege de grote hoeveelheid van gebruikshandelingen en de grote variatie die daarin bestaat, is moeilijk te overzien hoe een systeem in de toekomst zal werken. De onvoorziene fouten die in de loop der tijden bekend worden, hoeven daarom niet noodzakelijkerwijs een tekortkoming in de nakoming van de leveringsovereenkomst te zijn. Het is daarom begrijpelijk dat leveranciers hun garantietermijn beperken en fouten die later opduiken, afhandelen in het kader van onderhoudscontracten. Deze onvoorziene fouten moeten echter worden onderscheiden van gebreken in het systeem die bij de oplevering al bekend waren dan wel waren te voorzien. De leverancier die bij de oplevering van een computersysteem weet of had moeten weten dat een bepaalde fout zich zal voordoen na de afgesproken garantietermijn, voldoet niet aan zijn plicht om een goed werkend computersysteem af te leveren.”

16 Rb Arnhem 2006 (Silicon/Jaeger)
“…Ofschoon naar het oordeel van de rechtbank bij nieuw ontwikkelde software in zeker mate getolereerd kan worden dat zich in de beginfase “kinderziektes” of “aanloopproblemen” voordoen - in dit licht leest de rechtbank de bepaling in artikel 7.1 van de overeenkomst dat “Supplier does not warrant that operation of the Products will be error free or uninterrupted, or that all non-conformities can be corrected” -, sluit dit niet uit dat in beginsel een normaal gebruik van de software mogelijk moet zijn.” (Rb-uitspraak is in deze kwestie door het Hof vernietigd op de preabele vraag of er uberhaupt wel gebreken waren. Hof: neen)

17 Contractuele regeling van acceptatietest
Wel of niet overeengekomen? => vgl. klassieke licenties en SaaS Is klant verplicht een acceptatietest uit te voeren? Mag klant een testomgeving creëren? => auteursrechtelijke aspecten? Procedure van de test en selectie van testcases, testtools etc. Aandachtspunten test: coverage; reproduceerbaarheid; test-criteria; stabiliteit/invoed testomgeving; inhoud, oorzaak en effect van gebreken, Good for me, bad for you – probleem: het interpreteren van de testresultaten Ondersteuning door leverancier? Gevolgen van ‘acceptatie’: – ingangsdatum garantie – betalingsregeling – finale kwijting/decharge ontwikkelaar? Voorwaardelijke acceptatie? Fictieve acceptatie – operationele ingebruikname

18 Overige aandachtspunten
Doel softwaretest: vaststellen van aanwezigheid van gebreken. Niet: aantonen van afwezigheid van gebreken (Dijkstra) SGOA-arbitraal vonnis 1998: veroordeelt klant tot uitvoeren van een softwaretest + rapportage aan arbiters, teneinde goed beeld te krijgen van de inhoud van de storingen. HR , NJ 76, 486 (Pseudovogelpest-arrest): geen beroep op exoneratie als verkoper goederen levert “waarvan het hem vòòr of bij de levering bekend was dat zij gebreken hadden die de koper niet hoefde te verwachten…”