In een van onze eerdere nieuwsbrieven berichtten wij over de jaarlijkse SCL (The Society for Computers and Law) conferentie die in het najaar 2010 werd gehouden en waar ook Mitopics bij aanwezig was. Susan Atkinson (Gallenalliance Solicitors) sprak over de contractkwesties bij de nieuwe softwareontwikkelmethodes. Daarbij maakte zij een vergelijking tussen de meer traditionele Waterfall en alternatieve en moderne, Agile[1] softwareontwikkelmethode. De verschillen tussen beide methoden moeten ook in een contract naar voren komen. Mitopics zet de belangrijkste verschillen en vereisten bij dergelijke contracten voor u op een rij.
Traditioneel wordt een IT-contract geschreven aan de hand van de eisen en specificaties die van te voren bekend zijn en waar in een strikt geplande volgorde wordt ontwikkeld. Vanwege de toegenomen wensen van afnemers zijn ook de IT-projecten en softwareontwikkeling in de loop der jaren steeds dynamischer geworden. Als gevolg daarvan zijn ook de methoden om software te ontwikkelen veranderd. Contracten moeten antwoorden bieden voor dergelijke veranderingen.
In een modern ontwikkeltraject lijken de softwarespecificaties zich vaker te evolueren en worden daarmee ook een onderdeel van het ontwikkelproces. Alleen de kosten en de belangrijkste mijlpalen worden bij de start van het project vastgesteld. In tegenstelling tot de Waterfall-methode waarbij analyse, design, ontwikkeling en testen sequentieel plaatsvinden, worden in een Agile-methode tijdgebonden iteraties van software(onderdelen)/objecten ontwikkeld waarbij ontwerp- en ontwikkelcycli gelijktijdig plaatsvinden. Testen vormt bij de Agile-methode een integraal onderdeel van het ontwikkelproces en daarvoor worden meerdere matrices gebruikt, zowel voor het meten van het niveau van de productiviteit als voor de kwaliteit van de code. Bij Waterfall-methode wordt slechts gemeten tegen de vereisten die aan het begin van het project in de functionele (en technische) specificaties zijn opgenomen.
Wanneer voor nieuw te ontwikkelen software de functionele specificaties niet van te voren duidelijk (kunnen) zijn, is het van belang vooraf te onderkennen dat hiervoor in het contract enerzijds ruimte moet zijn en dat daar anderzijds goede afspraken tegenover moeten staan. In een dergelijk geval zal een traditioneel IT-contract niet gauw voldoen, aangezien dat contract uitgaat van eerder gedefinieerde eisen en specificaties waaraan zal moeten worden voldaan. Er wordt immers geen kant-en-klaar product aangeschaft maar een softwareontwikkeldienst: er wordt ontwikkelcapaciteit ingekocht. Het contract zal dan ook als zodanig moeten zijn ingericht. Bij de (moderne) Agile softwareontwikkelmethode is een grotere rol voor de afnemer weggelegd omdat hij continu betrokken wordt bij het ontwikkelproces. Hij zal immers zijn input moeten geven en indien nodig de specificaties en/of eisen moeten bijstellen. Niettemin zal er ook in dit geval een duidelijke verdeling van rechten en plichten gemaakt moeten worden. Hierbij is het van belang goed te letten op de mate waarin partijen deskundig zijn, invloed willen hebben in het project en de in te zetten ontwikkelcapaciteit.
Gelet op de complexiteit van deze materie is het raadzaam zich te laten bijstaan door een ervaren IT-jurist die u bij het opstellen van een dergelijk contract kan begeleiden.
[1] Ook wel RAD (Rapid Application Development) genoemd. De risico’s worden vermeden doordat software in korte overzichtelijke perioden (iteraties) ontwikkeld wordt. Elke iteratie wordt als een miniatuurproject gezien, en omvat alle noodzakelijke projectdelen: planning, analyse, ontwerp, testen en documentatie.