Softwareontwikkelingslevenscyclus (SDLC): de route van idee naar werkende software
Elke app, website of bedrijfssysteem die je gebruikt, is niet zomaar ontstaan. Er ging een proces aan vooraf waarin bedacht werd wat de software moest doen, hoe ze gebouwd zou worden, wie de code zou schrijven en hoe controleren dat alles werkt. Dat proces heet de softwareontwikkelingslevenscyclus, in het Engels Software Development Life Cycle of kortweg SDLC. Het is geen technologie op zich, maar een manier van werken: een stappenplan dat teams helpt om van een idee tot betrouwbare, werkende software te komen.
Een handige vergelijking is het bouwen van een huis. Niemand begint zomaar met metselen: eerst wordt besproken wat de bewoners nodig hebben, dan tekent een architect een plan, vervolgens bouwen vaklui de fundering en muren, wordt alles gekeurd, en na oplevering blijft er onderhoud nodig. Bij software verloopt dat in grote lijnen hetzelfde, alleen zijn de 'bouwstenen' regels code in plaats van stenen en beton. Omdat softwarefouten onzichtbaar kunnen blijven tot het te laat is - denk aan een bank die verkeerde bedragen overmaakt - is een doordacht proces geen overbodige luxe.
Wat is het precies?
De klassieke SDLC bestaat uit een aantal fasen die elkaar min of meer opvolgen. Eerst is er de requirementsanalyse: in gesprek met opdrachtgevers en toekomstige gebruikers wordt vastgelegd wat het systeem moet kunnen. Daarna volgt het ontwerp, waarin architecten bepalen hoe de software technisch in elkaar zit: welke onderdelen er zijn en hoe die met elkaar communiceren.
Vervolgens komt de implementatie of bouwfase, waarin programmeurs de daadwerkelijke code schrijven. Daarna volgt testen: controleren of de software doet wat bedoeld is, zowel op onderdeelniveau (unittests) als in samenhang (integratietests) en door echte gebruikers (acceptatietests). Pas als dat goed genoeg bevonden is, volgt de uitrol of deployment, waarbij de software live gaat. Tot slot is er onderhoud: bugs oplossen, updates doorvoeren en de software laten meegroeien met nieuwe wensen.
Hoe strikt deze fasen na elkaar doorlopen worden, verschilt sterk per aanpak. Bij het klassieke watervalmodel doorloopt een project elke fase precies één keer, in vaste volgorde, vaak met uitgebreide documentatie tussendoor. Bij agile werken (waaronder de bekende methode Scrum) wordt de hele cyclus juist steeds in het klein herhaald: in korte periodes van meestal een tot vier weken, 'sprints' genoemd, wordt telkens een stukje werkende software opgeleverd en bijgesteld op basis van feedback. Een nog verdergaande variant is DevOps, waarbij ontwikkeling (development) en beheer (operations) worden samengevoegd en waarbij nieuwe code, dankzij automatisering, soms meerdere keren per dag automatisch getest en uitgerold wordt. Dat laatste heet continuous integration/continuous deployment, afgekort CI/CD.
Wat wil men ermee bereiken?
Het belangrijkste doel van een SDLC is risicobeheersing. Software-engineeronderzoek laat al decennia zien dat een fout die pas na oplevering wordt ontdekt, vaak vele malen duurder is om te herstellen dan een fout die al in de ontwerpfase wordt opgemerkt. Door het proces in duidelijke stappen te knippen, met controlemomenten, wil men fouten zo vroeg mogelijk opsporen.
Daarnaast gaat het om voorspelbaarheid: opdrachtgevers willen weten wanneer een project ongeveer klaar is en wat het gaat kosten, iets wat bij ongestructureerde 'ad hoc'-programmeerprojecten vaak volledig uit de hand loopt. Een derde doel is kwaliteit en veiligheid, vooral bij systemen waar mensenlevens, geld of privacy van afhangen, zoals in de zorg, bij banken of bij de overheid. Tot slot speelt samenwerking een grote rol: bij grote projecten werken tientallen tot honderden mensen samen, en een gedeeld proces zorgt ervoor dat niemand langs elkaar heen werkt.
Voorbeelden uit de praktijk
De geschiedenis van softwareontwikkeling bevat zowel afschrikwekkende als voorbeeldige praktijkgevallen die laten zien hoeveel een SDLC ertoe doet.
Knight Capital Group (Verenigde Staten, 2012): dit handelsbedrijf verloor ongeveer 440 miljoen dollar in slechts 45 minuten, nadat nieuwe handelssoftware werd uitgerold terwijl oude, verouderde testcode op één van de servers niet was verwijderd. Het incident wordt in de softwarewereld veel aangehaald als lesmateriaal over hoe kwetsbaar de uitrolfase (deployment) kan zijn.
HealthCare.gov (Verenigde Staten, 2013): de federale website voor zorgverzekeringen crashte massaal bij lancering. Onderzoek naar de mislukking wees op onvoldoende belastingtests, onduidelijke aansturing tussen tientallen contractanten en een veel te krap tijdschema - een schoolvoorbeeld van een gebrekkig doorlopen ontwikkelproces bij een groot overheidsproject.
Spotify (Zweden, vanaf 2012): het Zweedse streamingbedrijf werd bekend om zijn eigen manier van agile opschalen, beschreven in een veelgelezen whitepaper van Henrik Kniberg en Anders Ivarsson met kleine, relatief zelfstandige teams ('squads'). Het zogeheten Spotify-model werd door veel andere bedrijven overgenomen, al heeft Spotify zelf later laten weten dat het model in de praktijk minder strak werd toegepast dan het op papier leek.
NASA Space Shuttle-software (Verenigde Staten, jaren tachtig-negentig): het team in Houston dat de boordsoftware van de spaceshuttle schreef, werd in 1996 in het tijdschrift Fast Company beschreven als een van de meest rigide softwareteams ooit, met extreem strikte review- en testprocedures die resulteerden in bijzonder weinig fouten per regel code.
Nederlandse overheidsprojecten (Belastingdienst, DUO): de Algemene Rekenkamer heeft meermaals kritisch gerapporteerd over IT-vernieuwingstrajecten bij Nederlandse overheidsdiensten, waarbij verouderde legacysystemen gecombineerd moesten worden met nieuwe ontwikkelmethoden, wat tot vertraging en fors hogere kosten leidde.
Hoe ver is de techniek?
Omdat de SDLC eerder een verzameling werkwijzen dan een technologie is, verandert ze voortdurend mee met inzichten en gereedschappen. Het watervalmodel werd voor het eerst systematisch beschreven in 1970 door Winston Royce, die overigens zelf al waarschuwde dat een strikt lineaire aanpak risicovol was. Als reactie hierop ontstonden vanaf de jaren negentig lichtere, iteratieve methoden, met als mijlpaal het Agile Manifesto uit 2001. Rond 2009 kwam daar de DevOps-beweging bij, gericht op nauwere samenwerking tussen bouwers en beheerders van software.
De meest recente ontwikkeling is de opkomst van AI-hulpmiddelen die meeschrijven aan code, zoals GitHub Copilot, en van 'low-code'- en 'no-code'-platforms waarmee mensen zonder programmeerachtergrond eenvoudige applicaties kunnen bouwen. Dit verandert vooral de implementatiefase, maar roept ook nieuwe vragen op over kwaliteitscontrole: wie is verantwoordelijk als AI-gegenereerde code een fout bevat? Ook 'DevSecOps', waarbij beveiliging vanaf het begin in elke fase wordt meegenomen in plaats van pas aan het eind, wint terrein als reactie op toenemende cyberdreigingen.
Ondanks decennia van verfijning blijft een aanzienlijk deel van softwareprojecten te laat, te duur of onvoldoende bruikbaar. Onderzoeksbureau Standish Group publiceert al jaren het veelgeciteerde CHAOS Report met cijfers over projectsucces, al is de precieze methodologie en betrouwbaarheid van die cijfers onder onderzoekers omstreden. Vast staat wel dat grote, complexe IT-projecten - zeker bij overheden met oude legacysystemen - een hardnekkig probleem blijven, ongeacht welk proces gevolgd wordt. Andere blijvende obstakels zijn wisselende eisen tijdens een project, 'technische schuld' (de opeenstapeling van snelle, niet-optimale oplossingen die later lastig te herstellen zijn) en communicatiekloven tussen technische teams en opdrachtgevers.
Wie werken eraan?
Standaarden voor de softwareontwikkelingslevenscyclus worden internationaal vastgelegd door samenwerkingsverbanden van de International Organization for Standardization (ISO), de International Electrotechnical Commission (IEC) en het Institute of Electrical and Electronics Engineers (IEEE), onder meer in de norm ISO/IEC/IEEE 12207. Onderzoek naar procesvolwassenheid wordt sinds de jaren tachtig sterk beïnvloed door het Software Engineering Institute (SEI) van Carnegie Mellon University, bekend van het CMMI-raamwerk waarmee organisaties hun ontwikkelproces kunnen laten beoordelen.
Op het gebied van gereedschappen die teams helpen bij het toepassen van SDLC-methoden, zijn bedrijven als Microsoft (met Azure DevOps en GitHub), Atlassian (met Jira) en GitLab toonaangevend. De non-profitorganisatie Agile Alliance beheert de erfenis van het Agile Manifest en organiseert conferenties en opleidingen wereldwijd.
In Nederland doen onderzoeksinstituten als TNO en universitaire vakgroepen software engineering, onder meer aan de TU Delft en de Universiteit Utrecht, onderzoek naar betere ontwikkelmethoden. Overheidsorganisaties zoals Logius en DICTU passen SDLC-principes toe bij de digitalisering van publieke dienstverlening, en de Algemene Rekenkamer volgt de resultaten daarvan kritisch.