Softwareontwikkelingsovereenkomst – model

Presentatie

De softwareontwikkelingsovereenkomst regelt de opdracht tot het op maat ontwikkelen van software, een applicatie of een specifieke functionaliteit door een externe ontwikkelaar of softwarebureau voor een opdrachtgever. Afhankelijk van de precieze inrichting kwalificeert zij als een overeenkomst van opdracht (art. 7:400 e.v. BW) wanneer het accent op inspanning ligt, of vertoont zij trekken van aanneming van werk wanneer een concreet, afgebakend resultaat is overeengekomen (naar analogie van art. 7:750 e.v. BW). Methodiek: waterval versus agile: de overeenkomst dient duidelijk te maken volgens welke methodiek wordt gewerkt. Bij een waterval-aanpak wordt een gedetailleerd functioneel en technisch ontwerp vooraf vastgesteld, met een vast opleverpunt. Bij een agile aanpak (scrum, sprints) wordt in iteraties gewerkt op basis van een product backlog, wat vraagt om een andere prijsafspraak (regie/tijd-en-materiaal in plaats van een vaste prijs) en een flexibeler acceptatieproces per sprint. Intellectuele eigendom op de broncode: cruciaal is te bepalen wie eigenaar wordt van de broncode en de bijbehorende auteursrechten. Op grond van art. 2 lid 3 Auteurswet vereist een overdracht van auteursrecht een schriftelijke akte; ontbreekt een uitdrukkelijke overdrachtsbepaling, dan blijft de ontwikkelaar in beginsel auteursrechthebbende en verkrijgt de opdrachtgever slechts een gebruiksrecht (licentie), ook al heeft hij de ontwikkeling volledig betaald. Acceptatietesten: de overeenkomst regelt doorgaans een acceptatieprocedure waarbij de opdrachtgever de opgeleverde software test aan de hand van vooraf overeengekomen acceptatiecriteria, met een termijn voor het melden van gebreken en het recht op herstel voordat definitieve acceptatie plaatsvindt. Aansprakelijkheid en garantie: de ontwikkelaar garandeert doorgaans dat de opgeleverde software gedurende een bepaalde periode vrij is van wezenlijke gebreken (bugs) die de overeengekomen functionaliteit belemmeren, met een verplichting deze binnen een redelijke termijn kosteloos te herstellen. Wanneer te gebruiken: bij het uitbesteden van de bouw van een applicatie, website, platform of specifieke softwaremodule aan een externe ontwikkelaar of softwarebureau, als eenmalig of projectmatig traject (in tegenstelling tot doorlopend onderhoud). Partijen: de opdrachtgever en de softwareontwikkelaar (freelancer of softwarebureau). Essentiële bedingen: de functionele en technische specificaties, de ontwikkelmethodiek, de planning en mijlpalen, de prijs (vast of regiebasis), de regeling van intellectuele eigendom, de acceptatieprocedure, en garantie op gebreken. Veelgemaakte fouten: het ontbreken van een uitdrukkelijke overdracht van auteursrecht (waardoor de opdrachtgever geen eigenaar van de broncode wordt), vage of ontbrekende specificaties die tot geschillen leiden over wat precies moest worden opgeleverd, en het niet regelen van de broncode-overdracht (source code escrow) bij een vaste-prijs-project.

Informatie om aan te passen

• Naam van de opdrachtgever

• Adres van de opdrachtgever

• Naam van de softwareontwikkelaar

• KvK-nummer van de ontwikkelaar

• Omschrijving van de te ontwikkelen software

• Ontwikkelmethodiek (waterval of agile)

• Prijs (vast bedrag of tarief, excl. btw)

• Prijsafspraak betreft een vast bedrag

• Voorziene opleverdatum

• Termijn voor acceptatietesten (dagen)

• Garantietermijn na oplevering (maanden)

• Broncode en auteursrecht worden overgedragen

Personaliseer uw sjabloon

Veelgestelde vragen

Wie wordt eigenaar van de broncode na ontwikkeling?

Dit hangt af van wat partijen afspreken. Zonder uitdrukkelijke overdracht van auteursrecht (art. 2 lid 3 Auteurswet vereist hiervoor een schriftelijke akte) blijft de ontwikkelaar in beginsel auteursrechthebbende, ook al heeft de opdrachtgever de ontwikkeling volledig betaald.

Wat is het verschil tussen waterval en agile ontwikkeling?

Bij een waterval-aanpak wordt vooraf een volledig ontwerp vastgesteld met een vast opleverpunt. Bij agile ontwikkeling (scrum) wordt in korte sprints gewerkt op basis van een product backlog, wat doorgaans wordt gecombineerd met facturatie op regiebasis in plaats van een vaste prijs.

Wat gebeurt er als de opgeleverde software gebreken vertoont?

De opdrachtgever krijgt een overeengekomen termijn om de software te testen en gebreken te melden. De ontwikkelaar moet deze gebreken binnen een redelijke termijn kosteloos herstellen; pas na goedkeuring vindt definitieve acceptatie plaats.

Is een vaste prijs of regiebasis beter voor softwareontwikkeling?

Een vaste prijs geeft budgetzekerheid maar vereist gedetailleerde specificaties vooraf. Regiebasis (tijd en materiaal) biedt flexibiliteit bij veranderende inzichten, maar minder kostenzekerheid. De keuze hangt af van hoe goed de scope vooraf kan worden vastgelegd.

Hoe lang geldt de garantie na oplevering van de software?

Dit is vrij te bepalen tussen partijen, maar gebruikelijk is een garantietermijn van enkele maanden na definitieve acceptatie, waarbinnen de ontwikkelaar wezenlijke gebreken kosteloos moet herstellen.

Bijbehorende sjablonen