Je software-project als scriptie: zo documenteer je een informatica-afstudeerproject

Je hebt wekenlang gecodeerd en een werkende applicatie staat er — en nu moet daar in een paar weken een volledige scriptie omheen. Dat is het moment waarop veel informaticastudenten vastlopen: niet op het bouwen, maar op het schrijven. Een tweede lezer beoordeelt niet primair je code, maar of je elke technische keuze kunt verantwoorden: waarom deze architectuur, waarom deze database, waarom deze testaanpak. Dit artikel laat zien hoe je van een werkend softwareproject een verdedigbare scriptie maakt, met dezelfde urgentie waarmee je een leeg document en een naderende deadline kent.

Het probleem is zelden gebrek aan werk — je hebt vaak al maanden git-commits, testresultaten en ontwerpbeslissingen liggen. Het probleem is dat die kennis in je hoofd zit, niet op papier. Onderstaande structuur helpt je om wat je al deed om te zetten in een tekst die je begeleider en examinator overtuigt, zonder dat je opnieuw hoeft te bouwen.

Wat verwacht een tweede lezer van een software-project als scriptie?

Drie dingen, in deze volgorde van belang:

• Een navolgbaar besluitvormingsproces. Niet alleen wélke technologie je koos, maar waarom — welke alternatieven overwoog je, en op welke criteria viel de keuze uit?
• Bewijs dat het werkt. Testresultaten, gebruikersevaluatie of een demonstratie die aantoont dat je software daadwerkelijk het probleem oplost dat je in de inleiding beschreef.
• Reflectie op het proces. Wat zou je anders doen, welke aannames bleken achteraf niet te kloppen, en wat is de bredere toepasbaarheid van je oplossing?

Dit is dezelfde onderliggende logica als bij een ontwerpgerichte scriptie in de bouwkunde of civiele techniek: het product zelf is niet het bewijs van wetenschappelijke kwaliteit, het proces eromheen wel.

Hoe zet je je git-geschiedenis om in bewijsmateriaal?

Je commit-geschiedenis is een onderbenutte bron voor je methodehoofdstuk. In plaats van achteraf te reconstrueren wat je wanneer deed, gebruik je je git-log als feitelijke tijdlijn:

• Groepeer commits per ontwikkelfase (opzet architectuur, implementatie kernfunctionaliteit, testen, bugfixes) en gebruik dit als basis voor je procesbeschrijving.
• Citeer significante architectuurbeslissingen met een tijdstempel. “Op basis van performanceproblemen bij de eerste implementatie (commit d4f21a, week 4) is overgestapt van synchrone naar asynchrone verwerking” is concreter en overtuigender dan een vage beschrijving achteraf.
• Bewaar een changelog of decision log als je dat nog niet deed — voor een lopend project is het niet te laat om vanaf nu bij elke belangrijke keuze een korte notitie te maken, ook al reconstrueer je de eerdere fases achteraf.

Hoe documenteer je architectuurbeslissingen overtuigend?

Voor elke significante technische keuze (framework, database, architectuurpatroon) geldt dezelfde structuur:

1. Het probleem. Welke eis of beperking maakte deze keuze nodig?
2. De overwogen alternatieven. Minstens twee, met hun voor- en nadelen voor jouw specifieke situatie.
3. De uiteindelijke keuze en motivatie. Waarom deze optie won, gekoppeld aan concrete criteria (performance, onderhoudbaarheid, teamkennis, tijd).
4. Het resultaat. Wat leverde de keuze in de praktijk op, en zou je hem achteraf opnieuw maken?

Deze structuur — bekend als een Architecture Decision Record (ADR) in de softwareontwikkelpraktijk — is direct herbruikbaar voor je scriptie: elke ADR wordt in feite een subsectie van je methode- of resultatenhoofdstuk.

Hoe toon je aan dat je software werkt?

“Het werkt” is geen wetenschappelijke claim totdat je het onderbouwt. Drie vormen van bewijs die in een informaticascriptie gangbaar zijn:

• Geautomatiseerde tests. Rapporteer je testdekking (coverage), het aantal unit- en integratietests, en wat een falende test in de praktijk betekende voor je ontwikkelproces. Een testrapport is directer bewijs dan een beschrijving in lopende tekst.
• Performancemetingen. Responstijden, belastingstests of geheugengebruik, gemeten vóór en na een optimalisatie, met de exacte meetomstandigheden (hardware, dataset-omvang) vermeld zodat de meting reproduceerbaar is.
• Gebruikersevaluatie. Een korte usability-test of vragenlijst onder eindgebruikers, ook met een klein aantal deelnemers (vijf tot tien is voor kwalitatieve usability-tests vaak al voldoende, in tegenstelling tot kwantitatief effectonderzoek — zie ons artikel over steekproefomvang voor het verschil tussen beide doelen).

Combineer minstens twee van deze drie vormen — een applicatie die alleen “getest is door de ontwikkelaar zelf” levert geen overtuigend resultatenhoofdstuk op.

Kan een CI/CD-pipeline als bewijs dienen?

Ja, en het wordt vaak onderbenut. Als je een continuous-integration-pipeline gebruikte (bijvoorbeeld GitHub Actions of GitLab CI) die bij elke commit automatisch je tests draaide, is de historie van die pipeline zelf bewijsmateriaal: het toont aan dat je software gedurende het hele ontwikkelproces getest werd, niet alleen aan het eind. Neem een screenshot of export van je pipeline-geschiedenis op als bijlage, en bespreek in je methodehoofdstuk kort welke checks automatisch liepen (linting, unit tests, build-verificatie) en hoe vaak een check faalde en tot een fix leidde — dat laatste is juist interessant materiaal voor je procesbeschrijving, geen ongemakkelijk detail om te verbergen.

Waar hoort je code in de scriptie thuis?

De volledige codebase hoort niet in de hoofdtekst. Gangbare indeling:

• Hoofdtekst: architectuurdiagrammen, korte, illustratieve codefragmenten (tien tot twintig regels, nooit hele bestanden) die een specifiek ontwerpprincipe demonstreren.
• Bijlage of repository-verwijzing: de volledige broncode, met een duidelijke verwijzing naar een (eventueel afgeschermde) git-repository, inclusief een README die uitlegt hoe de applicatie te draaien is.
• Reproduceerbaarheid. Vermeld exacte versienummers van gebruikte frameworks en libraries — softwareomgevingen veranderen snel, en een lezer die je werk over een jaar wil reproduceren heeft die informatie nodig.

Praktijkvoorbeeld: een webapplicatie voor roosterplanning

Een uitgewerkt (fictief, illustratief) voorbeeld laat zien hoe deze elementen samenkomen. Stel: je bouwde een webapplicatie die lesroosters automatisch optimaliseert voor een middelbare school.

• Probleem en context: handmatige roosterplanning kost de school tientallen uren per jaar en leidt tot conflicten die pas laat worden opgemerkt.
• Architectuurbeslissing: gekozen voor een constraint-satisfaction-algoritme in plaats van een simpel regelsysteem, gemotiveerd met een vergelijking van beide op flexibiliteit en rekentijd bij een testdataset van 40 klassen.
• Bewijs dat het werkt: een performancemeting die laat zien dat het algoritme een volledig rooster binnen twee minuten genereert bij de testdataset, plus een korte gebruikerstest met drie roostermakers van de school die de gegenereerde roosters beoordeelden op bruikbaarheid.
• Reflectie: het algoritme presteerde goed bij standaardconstraints, maar minder goed bij zeer specifieke, schoolgebonden uitzonderingsregels — een beperking die in het discussiehoofdstuk expliciet wordt besproken, met een concrete suggestie voor vervolgonderzoek.

Wat als je project nog niet af is?

Een onvoltooide applicatie is geen ramp voor je scriptie, zolang je transparant bent over wat wel en niet is opgeleverd. Beschrijf expliciet welke functionaliteit is gerealiseerd, welke bewust buiten scope viel (met motivatie), en welke nog openstaat als toekomstig werk. Een eerlijk “dit deel is niet af, en dit is waarom” wordt door beoordelaars beter ontvangen dan een tekst die een onvolledig product als compleet probeert te presenteren.

Veelgemaakte fouten bij het documenteren van een software-project

• De code laten spreken in plaats van de tekst. “De code legt zichzelf uit” is geen vervanging voor een geschreven verantwoording — een beoordelaar leest je scriptie, niet (noodzakelijk) je repository.
• Architectuurbeslissingen presenteren als vanzelfsprekend. Elke keuze die je maakte, had een alternatief. Als je dat alternatief niet noemt, oogt je keuze willekeurig in plaats van beargumenteerd.
• Alleen positieve resultaten rapporteren. Een deel dat niet goed werkte of een test die faalde, hoort net zo goed in je resultatenhoofdstuk thuis als wat wel lukte — het toont dat je kritisch naar je eigen werk kijkt.
• Vergeten om versienummers en omgevingsdetails te noteren. Zonder deze informatie is je werk over een half jaar al niet meer reproduceerbaar, ook niet door jezelf.

Handmatig documenteren versus met Tesify

Tesify vervangt in geen van deze rijen je eigen technische werk of je eigen redenering — het versnelt het omzetten van wat je al deed en weet naar een tekst die aan de verwachtingen van je opleiding voldoet. Wat de gratis versie van Tesify doet en waarvoor je betaalt, verschilt per functie; check de actuele voorwaarden op de website, want die kunnen wijzigen. Voor het bredere schrijfproces naast het software-specifieke deel geldt hetzelfde eerlijke uitgangspunt als in ons algemene stappenplan voor scriptie schrijven met AI: AI versnelt, maar de scriptie blijft jouw werk.