De levensloop van een softwareproduct begint met de ontwikkelingsfase. In die fase wordt van niets toegewerkt naar een eerste versie van een werkend computerprogramma. De ontwikkelingsfase zelf bestaat ook weer uit een aantal onderdelen. De ontwikkeling van software begint met een idee voor een toepassing. De insteek is om een of meer processen in een organisatie efficiënter te maken of te verbeteren door te automatiseren in de informatievoorziening en -verwerking. Een dergelijk idee kan zowel vanuit de techniek als vanuit de organisatie van de softwaregebruiker ontstaan. Deze initiatiestap wordt gevolgd door een hele serie fasen en stappen die uiteindelijk moeten leiden tot een eerste werkende versie van de software.

Ontwerpen

Wanneer er voldoende basis om van een automatiseringsidee naar software toe te werken, wordt begonnen met het maken van een ontwerp. Het maken van ontwerp is voor een groot deel de taak van de partij die de software gaat ‘schrijven’. Het ontwerp vormt voor die persoon of organisatie immers de leidraad voor de ontwikkelingswerkzaamheden. Afhankelijk van de ontwikkelmethodiek doorloopt het ontwerpproces een aantal stadia. Allereerst wordt een programma van eisen en wensen opgesteld. Hierin komt vast te staan welke kenmerken het nieuwe product moet vertonen en onder welke omstandigheden het product moet presteren. Daaruit volgt een model waarin de relatie wordt gelegd tussen de processen binnen een organisatie die zullen worden ondersteund en de informatiestromen en gegevensverzamelingen die daarbij een rol spelen. Hierin speelt een diepgaande procesanalyse een belangrijke rol. Op basis van dit model zullen de te automatiseren processtappen worden gekozen die verder worden uitgewerkt in een functioneel ontwerp.

In functioneel ontwerp (FO) wordt bepaald wat de architectuur van de van het softwareproduct is. Bij complexe producten met veel functionaliteit is het niet wenselijk of mogelijk om alle programmatuur in een enkel monolithisch product te realiseren. Door het product in afzonderlijke modules te ontwerpen en ontwikkelen, is het project overzichtelijker en kan beter worden ingehaakt op veranderingen. Een dergelijk ontwerp is modulair.

Het FO bevat voorts een beschrijving van hetgeen de verschillende modules van de te ontwikkelen software aan functionaliteit moeten bieden. Ten slotte wordt vastgelegd op welke wijze de modules onderling en met andere programmatuur moeten communiceren. Het functioneel ontwerp is meestal geen diepgaand technisch document, zodat de inhoud ervan ook kan worden beoordeeld door de personen of organisaties die de software moeten gaan gebruiken. Hierbij is de achterliggende gedachte dat de gebruiker degene is die uiteindelijk bepaalt wat de software moet kunnen. Het FO is met andere woorden geschreven in een taal die door de gebruiker is te begrijpen. Wanneer er sprake is van software die geschikt moet zijn voor gebruik door meerdere organisatie (standaardsoftware), zal de softwareontwikkelaar het FO voor een belangrijk deel baseren op het onderzoek dat hij heeft gedaan naar de wensen onder potentiële gebruikers. Wanneer sprake is van maatwerkprogrammatuur of programmatuur die moet worden in gekocht volgens een aanbestedingsprocedure, is de gebruiker intensiever betrokken bij het opstellen van het FO.

Als het FO van de verschillende modules bekend is, dan kan daarna per module een technisch ontwerp (TO) worden opgesteld. Het TO bevat een schematische beschrijving van de manier hoe de in het functioneel ontwerp gevraagde specificaties technisch kunnen worden gerealiseerd. Daarbij wordt bijvoorbeeld gekeken naar de hulpmiddelen die tijdens het ontwikkelproces worden ingezet. Gedacht kan worden aan het te gebruiken ontwikkelingsplatform en het databasemodel dat moet worden gebruikt. Het technisch ontwerp bevat daarnaast een plan van aanpak: de volgorde waarin de verschillende onderdelen van een applicatie worden opgebouwd, wordt bepaald. Het technisch ontwerp kan, zeker bij omvangrijke automatisering, opgedeeld zijn in verschillende fasen en mijlpalen. In het TO kan worden opgenomen, dat een mijlpaal pas is bereikt wanneer hetgeen de ontwikkelaar heeft voortgebracht, succesvol is getest en geschikt is voor implementatie. Pas wanneer een mijlpaal is bereikt, wordt verder gaan met de realisatie van de volgende mijlpaal.

Naast de functiegerichte ontwerpstappen is ook de interactie met de gebruiker onderhevig aan ontwerp. De communicatie van de gebruiker met de software wordt gevoerd door de gebruikersinterface. Deze wordt gebaseerd op dialoog- en gebaarelementen zoals die in de gebruiksomgeving, namelijk de apparatuur en het daarop geïnstalleerde besturingssysteem, beschikbaar zijn. Het ontwerpen van de gebruikersinterface bestaat uit drie elementen.

1. Gebruikersinvoer ontwerpen: bepalen op welke wijze de gebruiker gegevens in de software kan invoeren;
2. Signalering en uitvoering: bepalen hoe de software zijn resultaten en signalen met de gebruiker deelt;
3. Vormgeving: de gebruikersinterface wordt op een voor de gebruiker prettige en logische wijze ingericht, gekleurd en gestijld. Hierbij kan rekening worden gehouden met de huisstijl van de organisatie die de software in gebruik gaat nemen.

De eerste twee elementen van het ontwerpen van de gebruikersinterface betreft het interactie-ontwerp. Het derde element betreft het grafisch ontwerp.

Methoden voor softwareontwikkeling

Voor het ontwikkelen van software kan grofweg van twee soorten methoden gebruik worden gemaakt: de klassieke watervalmethode en agile ontwikkelmethoden. Bij de watervalmethode wordt iedere ontwerpfase volledig afgerond en als vertrekpunt gehanteerd voor de volgende ontwerpfase. Dus eerst worden het FO en TO opgesteld, vervolgens wordt de software geschreven. Daarna wordt de software geïmplementeerd en getest. Wanneer er tijdens het testen gebreken aan het licht komen, worden deze gerepareerd. Daarna wordt de software opgeleverd en is het ontwikkeltraject afgerond.

Bij ‘agile’ ontwikkelingsmethoden (agile betekent: lenig, wendbaar) wordt de software niet in één ontwerpfase, maar in meerdere afzonderlijke en aaneengesloten ontwerpfasen tot stand gebracht. Een voorbeeld van een agile ontwikkelmethode is Scrum. In elke fase wordt een gedeelte van de functionaliteit van het gehele product ontworpen, geschreven, geïmplementeerd en getest. Hierdoor staat snel werkende software, omdat het product wordt gerealiseerd in kleine overzichtelijke trajecten met behapbare doelen. Hierdoor wordt gedurende het ontwikkelproces een steeds complexer geheel tot stand gebracht. Binnen agile ontwikkelingsmethoden is meer ruimte om in te haken op veranderende eisen en wensen. In de praktijk gebruiken de meeste softwareontwikkelaars een combinatie van de watervalmethode en een agile methode.

Programmeren: de totstandkoming van een broncode en objectcode

Wanneer het (voorlopige) ontwerpen van de software afgerond is en de ontwikkelmethode duidelijk is, wordt de volgende stap in de ontwikkelingsfase gezet. Dit is het schrijven van de programmatuur: de functionaliteit van de software wordt met behulp van een programmeertaal en ander gereedschap (hulpsoftware, compilers; linkers) gerealiseerd door het ontwikkelteam van de softwareontwikkelaar. Dat wat de programmeurs in hun programmeertaal schrijven, wordt de broncode genoemd. Alleen het broncode-exemplaar van de programmatuur is bruikbaar voor het onderhouden en doorontwikkelen van de software. Een broncode alleen, kan door een computer niet worden uitgevoerd als werkbaar programma. Daarvoor is het nodig dat de broncode wordt omgezet naar objectcode, dus een voor een computer begrijpbare versie van de software. Hiervoor wordt speciale ontwikkelsoftware ingezet, waarmee de broncode wordt ‘gecompileerd’. Wanneer de broncode is gecompileerd, betekent dit niet dat het programma definitief is. Een compilatie kan bijvoorbeeld ook dienen om te controleren of het programmeerwerk het gewenste resultaat opgeleverd heeft.

Hoe omvangrijker de te ontwikkelen software is, hoe meer manuren er doorgaans in de ontwikkelingsfase worden gestoken. Omvangrijke automatiseringsprojecten kunnen jarenlang duren. Gedurende die tijd kan er dus sprake zijn van werkende software, maar deze is nog niet geschikt voor het beoogde gebruik. Gedurende langetermijntrajecten wordt de software, zeker wanneer een agile ontwikkelingsmethode wordt toegepast, wel van tijd tot tijd getest.

Uniciteit softwarebroncodes

Uit het voorgaande blijkt dat reeds in de ontwikkelingsfase elke broncode uniek is. Ook de volgende aspecten van software ontwikkeling dragen bij aan die authenticiteit:

1. In de ontwikkelingsfase kan gebruik worden gemaakt van bepaalde best practices en richtlijnen voor softwareontwikkeling. Met het hanteren van dergelijke richtlijnen wordt de oplevering van software met een bepaald kwaliteitsniveau beoogd.
2. Software kan ontwikkeld worden door een individu tot door grote internationale ondernemingen. De wijze waarop een broncode is samengesteld, kan daarmee sterk samenhangen. Bij grotere softwareontwikkelaars immers, worden de functies van softwarearchitect, projectmanager en programmeur ingevuld door verschillende personen, terwijl een individuele ontwikkelaar deze functies zelf uitoefent. In het laatste geval, kan bijvoorbeeld zijn afgeweken van richtlijnen of kan het ontwikkelingsproces niet goed zijn gedocumenteerd.
3. Software wordt overal ter wereld ontwikkeld. Dit betekent niet per definitie dat bij de buitenlandse softwareontwikkeling andere werkwijzen worden doorlopen. Wel kan de wijze waarop een broncode juridisch wordt beschermd, van land tot land verschillen.
4. Software hoeft niet altijd vanaf de grond te zijn opgebouwd. Het is mogelijk dat een softwareontwikkelaar gebruik maakt van onderdelen die reeds ontwikkeld zijn. Die onderdelen kunnen Open Source software betreffen, dat is software waarvan de broncode door de maker kosteloos ter beschikking wordt gesteld.

Direct betrokkenen bij de ontwikkelingsfase

De volgende partijen zijn betrokken bij de ontwikkelingsfase:

1. Softwareontwikkelaar: de persoon of organisatie die software ontwikkelt, ook wel softwarehouse of softwareleverancier genoemd.
2. Softwarearchitecten: de personen die verantwoordelijk zijn voor de wijze waarop in hoofdlijnen het FO wordt omgezet in werkende software, dus waarop de software wordt opgebouwd. Zij maken keuzes omtrent ontwikkelplatforms, hulsoftware, programmeertalen, database-inrichting et cetera.
3. Programmeurs: de personen die de software schrijven en testen.
4. Projectmanager: de personen die de voortgang van de ontwikkeling van het softwareontwikkelingsproces of onderdelen daarvan sturen en bewaken.
5. Gebruikers: de personen of organisaties die de software (potentieel) gaan gebruiken. Gedurende de ontwikkelingsfase kunnen de gebruikers betrokken zijn bij het opstellen van het functioneel ontwerp en het testen van hetgeen wordt ontwikkeld.

Het softwareontwikkelteam

Het softwareontwikkelteam van de softwareontwikkelaar is de spil van zijn bedrijf. Dit team is ook verantwoordelijk voor de kwaliteit en het goede functioneren van de software. Die kwaliteit kan afhangen van enkele mensen. Afhankelijk van de grootte van de softwareontwikkelaar, kan het vertrek of uitvallen van een van hen al van invloed zijn op de continuïteit van de software. De gebruiker heeft in de regel geen invloed op de samenstelling van het softwareontwikkelteam.

Belang gebruikers

De wijze waarop de ontwikkeling van de software verloopt is van belang voor de gebruiker: er wordt immers bepaald hoe de software eruit gaat zien of eruit ziet. Vooral wanneer het maatwerksoftware betreft, zal de gebruiker zoveel mogelijk de vinger aan de pols willen houden. Softwareontwikkelaar en gebruiker kunnen een procedure overeenkomen waarin dat mogelijk wordt gemaakt. Zo bijvoorbeeld worden afgesproken dat de oplevering van elke mijlpaal binnen het ontwikkelingsproces binnen een bepaalde termijn moet plaatsvinden en door de gebruiker wordt geaccordeerd. Bij standaardsoftware vindt een dergelijke gang van zaken meestal niet plaats: deze is meestal de ontwikkelingsfase voorbij op het moment dat de gebruiker ermee in aanraking komt.

Bij maatwerksoftware zijn die afspraken tussen softwareontwikkelaar en gebruiker (de opdrachtgever) reeds van belang in de ontwikkelingsfase. Aan maatwerkprojecten ligt daarom vaak een contract ten grondslag. In het contract worden afspraken gemaakt over onder andere voortgangbewaking, informatievoorziening, de wijze van testen, de mogelijkheden tot aanpassing van het functioneel ontwerp en meerwerk.

Verbanden in het kader van de softwarelevensloop

De ontwikkelingsfase is de start van de levensloop van een softwareproduct. Reeds in die periode echter, wordt voor een aanmerkelijk deel het vervolg van die levensloop bepaald. Gedacht kan onder andere worden aan:

1. De vestiging van een pandrecht op hetgeen tijdens de ontwikkelingsfase tot stand wordt gebracht. Dit pandrecht kan worden gevestigd ten behoeve van de partijen die investeren in het ontwikkelingstraject.
2. Het vastleggen en de overdracht van het eigendom van de software. Tijdens het ontwikkelingstraject ontstaan er rechten op de software (waarover meer in het volgende hoofdstuk). Deze rechten kunnen al gedurende dat traject worden vastgelegd, zodat het lastiger wordt om de software na te maken. Deze rechten kunnen tevens in de ontwikkelingsfase worden overgedragen, bijvoorbeeld in het kader van de overname van de softwareontwikkelaar.
3. Bij een goede broncode-escrowregeling wordt er gekeken naar het onwikkelproces en ook naar de personen die daarvoor verantwoordelijk zijn. Dit is essentieel voor het kunnen verzorgen van de continuïteit als de softwareleverancier wegvalt.

De IT-Jurist kan in de ontwikkelingsfase een rol van betekenis hebben voor een softwareontwikkelaar en zijn opdrachtgever bij het vastleggen en beheren van afspraken. Omvangrijke ontwikkelingstrajecten verlopen in aanzienlijk veel gevallen niet zoals bij aanvang van het traject werd verwacht. Een oorzaak daarvan kan al zijn dat die verwachting niet bij de softwareontwikkelaar en zijn opdrachtgever hetzelfde is. Daarnaast komt overschrijding van termijnen en budgetten regelmatig voor.

Om dergelijke problemen te beperken, zou kunnen worden gekozen voor een strenge trajectbewaking, waarbij, zoals in de vorige paragraaf beschreven, een bewust accorderingsmoment plaatsvindt. Dit kan door het tekenen van een akkoordverklaring. Deze akkoordverklaring kan met de status van het ontwikkelingstraject kan bijvoorbeeld worden gedeponeerd bij een IT-notaris. Deze aanpak kan een remedie zijn voor de in grote en langdurige projecten veel voorkomende personeelswisselingen en mogelijk zoekgeraakte broncodes. Immers ook de uitvoerder van het project beschikt over de notarieel vastgelegde stukken. Bij de wisseling van een projectleider of ingehuurde onderaannemers kan zodoende een veel betere overdracht van het project plaatsvinden. Voorts wordt door deze projectdeponering bewijs veiliggesteld, zodat partijen op voorhand weten waar ze aan toe zijn in geval van een conflict. Wilt u meer weten over dit onderwerp, neemt u dan gerust contact met ons op.