Samenvattingen · InformaticaNL · HAVO

Domein A: Vaardigheden

Domein A legt de denk- en werkgereedschappen vast die je in heel de informatica gebruikt. Je leert computationeel denken (decompositie, patroonherkenning, abstractie en algoritmisch denken), abstraheren en modelleren, projectmatig werken volgens een ontwerpcyclus (watervalt versus agile), en gestructureerd samenwerken met documentatie, versiebeheer en testen. Deze vaardigheden vormen de kern van het schoolexamen en keren terug in elk volgend domein.

4 Onderdelen~23 min leestijd4 VaardighedenNiveau Basis 1 · Standaard 2 · Verdieping 1

T·0111 / 12

Examenprofiel

Computationeel denken toepassen: een probleem decomponeren, patronen herkennen, abstraheren en de oplossing uitwerken als een algoritme (een eindige, ondubbelzinnige reeks stappen).Van een praktijksituatie een passend model maken (datamodel én procesmodel) door bewust te abstraheren, en abstractieniveaus en het black-box-principe herkennen en uitleggen.Projectmatig en methodisch werken volgens een ontwerp-/ontwikkelcyclus met toetsbare eisen, planning en mijlpalen; het watervalmodel en agile/iteratief werken vergelijken en beargumenteerd kiezen.Gestructureerd samenwerken met versiebeheer (commit, branch, samenvoegen, terugdraaien), heldere documentatie, leesbare code en systematisch testen.

Operatoren:leg uitbeschrijfberedeneerontwerppas toevergelijk

basisniveau

Ken de vier pijlers van computationeel denken, de fasen van de ontwerpcyclus en de basisbegrippen van versiebeheer, en pas ze toe op een eenvoudige casus.

verhoogd niveau

Verdieping: weeg watervalt beargumenteerd af tegen agile, formuleer toetsbare functionele én niet-functionele eisen en beheer een samenwerkingsstroom met branches, merges en terugdraaien.

Diepte

Tekst

Inhoud · 4 onderdelen

Domein A: Vaardigheden

Computationeel denken#

Basisexamenblad-nl

Computationeel denken: van probleem naar oplossing

Afb. 1De vier pijlers verbinden een probleem met een uitvoerbare oplossing: eerst opsplitsen, dan patronen zien, dan weglaten wat niet nodig is, en ten slotte een algoritme opstellen.

Computationeel denken is de manier van probleemoplossen die aan de basis van heel de informatica ligt: je pakt een probleem zó aan dat een computer — of een mens die stap voor stap werkt — het kan uitvoeren. Het is nadrukkelijk géén „denken zoals een machine"; het is een menselijke gereedschapskist die je ook gebruikt bij een recept, een treinreis plannen of een toernooi organiseren. De informatica ordent die kist in vier pijlers: decompositie (opsplitsen), patroonherkenning, abstractie (weglaten wat er niet toe doet) en algoritmisch denken (een stappenplan opstellen). Deze vier komen zelden los voor — je splitst een probleem, ziet dat de stukken op elkaar lijken, laat details weg en giet de oplossing in stappen — en de houding keert terug in élk ander domein, van programmeren tot databases.

Decompositie betekent een groot, onhanteerbaar probleem opdelen in kleinere deelproblemen die je apart kunt oplossen. De reden is eenvoudig: een deelprobleem overzie je, een berg niet, en kleine stukken kun je los testen en onder teamleden verdelen. Wil je bijvoorbeeld een app maken die een schoolrooster toont, dan splits je dat in: lesgegevens inlezen, botsingen tussen lokalen opsporen, het rooster op het scherm tekenen en wijzigingen opslaan. Elk deel is nu een op zichzelf staande, behapbare taak. Goede decompositie levert deelproblemen op die zo min mogelijk van elkaar afhangen, zodat een fout in het één de rest niet meesleept — precies wat je in Domein D (programmeren) terugziet als functies en modules.

Patroonherkenning is het opmerken dat verschillende (deel)problemen dezelfde onderliggende structuur delen, zodat één oplossing meerdere keren dienst doet. Zie je dat „de hoogste toets-score zoeken", „de duurste bestelling zoeken" en „de langste route zoeken" allemaal neerkomen op het maximum van een rij bepalen, dan hoef je dat maximum-idee maar één keer goed te bedenken. Herhaling in de wereld vertaalt zich zo naar herbruikbare code: een lus die telkens hetzelfde doet, of een functie die je op verschillende gegevens loslaat. Patroonherkenning maakt oplossingen korter, betrouwbaarder en sneller te bouwen, en vormt de brug naar generaliseren — het volgende, abstracte niveau.

Abstractie is het bewust weglaten van details die er voor jouw doel niet toe doen, zodat alleen de essentie overblijft. Een metrokaart is het schoolvoorbeeld: afstanden en bochten kloppen niet, maar de enige vraag die telt — „welke lijn neem ik en waar stap ik over?" — beantwoordt de kaart perfect. In de informatica bepaal je bij elk model welke gegevens relevant zijn: voor een klaslijst noteer je naam en klas, niet de schoenmaat. Door te abstraheren maak je een probleem eenvoudiger én kun je dezelfde oplossing op meer gevallen toepassen. Let op: abstraheren is een keuze mét gevolgen — laat je iets weg dat tóch belangrijk blijkt, dan klopt je model niet meer. Abstractie werk je in de volgende paragraaf verder uit.

Algoritmisch denken, ten slotte, is het uitschrijven van de oplossing als een eindige, ondubbelzinnige reeks stappen: een algoritme. Elke stap moet zó precies zijn dat wie hem uitvoert niets hoeft te raden, de volgorde ligt vast, en na eindig veel stappen ben je klaar met het juiste resultaat. „Zoek de goedkoopste route" is een wens; „vergelijk alle routes en onthoud telkens de kortste tot nu toe" is een algoritme. Dit is de kern die in Domein B (grondslagen) en D (programmeren) wordt uitgediept, inclusief de vraag hóé snel een algoritme is — of het bij

n

gegevens ongeveer

n

of eerder

n^2

stappen kost. Samen vormen de vier pijlers één werkwijze: splitsen, patronen zien, weglaten, en het geheel in stappen gieten.

Uitgewerkt voorbeeld

Een schoolzwemtoernooi automatiseren met de vier pijlers

Een school wil een programma om een zwemtoernooi te regelen: leerlingen inschrijven, races indelen, tijden bijhouden en per onderdeel de winnaar bepalen. Pak dit probleem aan met computationeel denken.

Stap 1 — Decompositie
Splits het geheel in behapbare deelproblemen: (1) leerlingen inschrijven, (2) inschrijvingen indelen in heats, (3) tijden invoeren, (4) per onderdeel de winnaar bepalen. Elk deel is nu apart te bouwen en te testen.
Stap 2 — Patroonherkenning
„Winnaar per onderdeel" is telkens hetzelfde deelprobleem: zoek in een rij tijden de kleinste. Je bedenkt de oplossing voor dat patroon één keer en hergebruikt hem voor élk onderdeel.
Stap 3 — Abstractie
Bewaar per zwemmer alleen wat voor de uitslag telt: naam, onderdeel en tijd. Details als leeftijd, klas of lievelingsslag laat je weg — ze maken het model onnodig ingewikkeld.
Stap 4 — Algoritmisch denken
Schrijf de stappen ondubbelzinnig op: neem de eerste tijd als beste, loop de overige tijden langs en vervang de beste telkens als je iets kleiners tegenkomt; de overgebleven waarde hoort bij de winnaar. Herhaal voor elk onderdeel.
$\text{beste} \leftarrow \min(\text{beste},\ \text{huidige tijd})$

Resultaat: Door te decomponeren (vier deeltaken), een patroon te herkennen („kleinste zoeken"), te abstraheren (alleen naam, onderdeel, tijd) en dat in een algoritme te gieten, ligt er een heldere, herbruikbare aanpak klaar. Het winnaars-algoritme kost ongeveer $n$ vergelijkingen voor $n$ zwemmers en werkt zonder aanpassing voor elk onderdeel.

Veelgemaakte fouten

Computationeel denken verwarren met „programmeren" of met „denken als een computer" — het is een bredere, menselijke probleemaanpak die ook zónder computer werkt.
Decompositie en abstractie door elkaar halen: opsplitsen (decompositie) is iets anders dan details weglaten (abstractie).
Bij patroonherkenning stoppen bij oppervlakkige gelijkenis (hetzelfde onderwerp) in plaats van dezelfde onderliggende structuur zoeken.

Actieve herhaling

Je moet voor de mediatheek een systeem bedenken dat bijhoudt welke boeken zijn uitgeleend. Beschrijf hoe je dit probleem met de vier pijlers van computationeel denken aanpakt: geef per pijler (decompositie, patroonherkenning, abstractie, algoritmisch denken) concreet aan wat je doet.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Abstractie en modelleren#

Standaardexamenblad-nl

Concreet versus abstract: het model bewaart de essentie

Afb. 2Modelleren = weglaten met een doel. In elke rij verdwijnen de details en blijft alleen datgene over wat de bijbehorende vraag beantwoordt.

Modelleren is het bouwen van een vereenvoudigde weergave van een stukje werkelijkheid: een model. Waar de vorige paragraaf abstractie als denkpijler introduceerde, is modelleren die abstractie in actie — je maakt een bewuste selectie van wat je overneemt en wat je weglaat, altijd met een doel voor ogen. „Alle modellen zijn onjuist, maar sommige zijn bruikbaar" vat het goed samen: een model klopt nooit tot in elk detail met de werkelijkheid, en dat hóéft ook niet; het moet alleen goed genoeg de vragen beantwoorden waarvoor je het maakt. Een dienstregeling is een model van het echte busverkeer, een plattegrond een model van een gebouw. In de informatica leg je zulke modellen zó vast dat een computer ermee kan werken en rekenen.

Een krachtig idee is dat je één systeem op meerdere abstractieniveaus kunt beschrijven, van heel concreet tot heel abstract, en telkens het niveau kiest dat bij je vraag past. Neem een computer: onderaan zijn er stroompjes en transistoren, daarboven bits en logische poorten, daarboven machine-instructies, daarboven een programmeertaal, en bovenaan een app met knoppen. Wie een app maakt, hoeft niet aan transistoren te denken; wie een chip ontwerpt juist wél. Hoe hoger het niveau, hoe meer details zijn weggeabstraheerd en hoe makkelijker je erover praat — maar hoe minder je ziet van wat er „onder de motorkap" gebeurt. Deze gelaagdheid maakt grote systemen überhaupt behapbaar en keert terug in Domein E (architectuur) en bij de netwerklagen.

Nauw hiermee verbonden is het black-box-idee: je gebruikt iets op grond van wat het dóét (de in- en uitvoer), zonder te weten hóé het van binnen werkt. Een rekenmachine is een black box — je typt 7 × 8 en krijgt 56, zonder de schakelingen te kennen. Elk goed afgebakend deel van een systeem is voor de buitenwereld zo'n black box met een duidelijke interface: wat stop je erin, wat komt eruit. Dat is enorm handig, want zolang de afspraak over in- en uitvoer blijft staan, mag de binnenkant veranderen (sneller, zuiniger) zonder dat de rest kapotgaat. Zo hangen abstractie, hergebruik en onderhoudbaarheid samen: de black box verbergt complexiteit en beschermt de rest tegen wijzigingen.

Modellen zijn er in soorten, en twee kom je in de informatica steeds tegen. Een datamodel beschrijft wélke gegevens je bewaart en hoe ze samenhangen: welke dingen (entiteiten) er bestaan, welke eigenschappen ze hebben, en hoe ze gekoppeld zijn — een leerling hoort bij een klas, een boek bij een uitlening. Een procesmodel beschrijft juist de stappen en de volgorde van handelingen: hoe verloopt „een boek uitlenen" van scannen tot bevestigen? Waar het datamodel de zelfstandige naamwoorden vastlegt (de dingen), legt het procesmodel de werkwoorden vast (het gedrag). Beide gebruiken schema's — denk aan het ERD in Domein H (databases) en aan stroomdiagrammen — zodat een idee ondubbelzinnig op papier staat vóórdat je één regel code schrijft.

Waarom al die moeite? Omdat abstractie precies de twee eigenschappen oplevert die software groot en levensvatbaar maken: schaalbaarheid en hergebruik. Door details achter een nette interface te verbergen, kun je een systeem laten groeien zonder dat de complexiteit je boven het hoofd stijgt — je voegt een onderdeel toe zonder alle andere te hoeven begrijpen. En een goed geabstraheerde oplossing (een functie „grootste getal", een module „inloggen") werkt in het ene project net zo goed als in het volgende, zodat je niet telkens opnieuw begint. Het gevaar is de verkeerde abstractie: laat je iets weg dat later tóch nodig blijkt, dan moet je je model verbouwen. Modelleren is dus altijd afwegen — genoeg weglaten om het simpel te houden, genoeg bewaren om het juist te houden.

Uitgewerkt voorbeeld

Een datamodel voor het uitlenen van boeken

De mediatheek wil bijhouden welke leerling welk boek heeft geleend en tot wanneer. Ontwerp een eenvoudig datamodel en laat zien welke abstractie je toepast.

Stap 1 — Bepaal het doel
Leg eerst vast welke vragen het model moet beantwoorden: „wie heeft welk boek?" en „is het te laat?". Dat doel bepaalt wat essentieel is en wat je mag weglaten.
Stap 2 — Kies entiteiten en essentiële gegevens
Kies drie dingen (entiteiten): Leerling (naam, klas), Boek (titel, exemplaarcode) en Uitlening (welke leerling, welk boek, inleverdatum). Alleen deze gegevens heb je nodig om beide vragen te beantwoorden.
Stap 3 — Abstraheer: laat bewust weg
Gegevens als schoenmaat, kleur van de kaft of het gewicht van het boek doen er niet toe voor de uitleen-administratie. Ze weglaten is de abstractie: je bewaart de essentie, niet de hele werkelijkheid.
Stap 4 — Leg de samenhang vast
Een Uitlening koppelt precies één Leerling aan één Boek met een datum; zo weet je wie wat heeft en of de inleverdatum verstreken is. Deze relaties teken je later formeel uit in een ERD (Domein H, databases).

Resultaat: Het datamodel bestaat uit Leerling, Boek en Uitlening met alleen de doelrelevante eigenschappen. Het is een abstractie omdat het bewust de details weglaat die de twee vragen niet helpen beantwoorden — genoeg bewaard om juist te zijn, genoeg weggelaten om eenvoudig te blijven.

Veelgemaakte fouten

Denken dat een model „zo waarheidsgetrouw mogelijk" moet zijn — een model is juist een doelgerichte vereenvoudiging; te veel detail maakt het onbruikbaar.
Te veel of te weinig weglaten: essentiële gegevens schrappen (model klopt niet) of alles bewaren (dan is er geen echte abstractie).
Datamodel en procesmodel verwarren — het eerste beschrijft de dingen, het tweede de handelingen.

Actieve herhaling

Een sportvereniging wil de deelname aan trainingen bijhouden. (a) Maak een eenvoudig datamodel: noem drie gegevens die je bewaart en leg per gegeven uit waarom het essentieel is. (b) Noem één gegeven dat je bewust weglaat en beredeneer waarom. (c) Leg uit waarom jouw model een abstractie van de werkelijkheid is.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Projectmatig en methodisch werken#

Standaardexamenblad-nl

De ontwerp-/ontwikkelcyclus

Afb. 3De fasen vormen een cyclus: na evaluatie en onderhoud begin je een nieuwe ronde. Bij agile werken doorloop je deze lus vele keren kort achter elkaar, bij waterval in principe één keer.

Een informaticaproject slaagt zelden door meteen te gaan typen; het slaagt door methodisch te werken volgens een ontwerp- of ontwikkelcyclus. Die cyclus verdeelt het werk in vaste fasen die je in vaste volgorde doorloopt: analyse (wat is precies het probleem en wat moet de oplossing kunnen?), ontwerp (hoe gaan we het maken — schermen, gegevens, structuur?), realisatie (bouwen en programmeren), testen (werkt het en klopt het?) en evaluatie/onderhoud (voldoet het, en houden we het draaiend?). Door eerst na te denken en pas dan te bouwen, voorkom je dure fouten: een verkeerd begrepen eis die je in de analyse ontdekt, kost een gesprek; ontdek je hem pas na het bouwen, dan kost hij een verbouwing.

De analysefase draait om requirements, oftewel eisen: een zo precies mogelijke beschrijving van wat het systeem moet kunnen en waaraan het moet voldoen. Je onderscheidt functionele eisen (wát het systeem doet — „de gebruiker kan een boek reserveren") van niet-functionele eisen (hóé goed — „een pagina laadt binnen twee seconden", „het werkt op de telefoon"). Goede eisen zijn concreet en toetsbaar, zodat je later objectief kunt vaststellen of eraan voldaan is; een vage eis als „de app moet gebruiksvriendelijk zijn" is waardeloos totdat je hem meetbaar maakt. Eisen komen van de opdrachtgever en de gebruikers, en juist hier ontstaan de meeste projectfouten: bouw je het verkeerde, dan helpt foutloos programmeren niet.

Hóé je de cyclus doorloopt, kan verschillen. In het watervalmodel doorloop je de fasen strikt één keer en na elkaar, als water dat van trede naar trede valt: pas als de analyse helemaal af en goedgekeurd is, begin je aan het ontwerp, enzovoort. Dat geeft rust, duidelijke afspraken en veel documentatie vooraf, en het past bij projecten waarvan de eisen vanaf het begin vaststaan en niet meer veranderen. De keerzijde is starheid: kloppen de eisen achteraf niet, of verandert de wens onderweg, dan is terug naar een eerdere fase duur en omslachtig — en fouten in de analyse komen vaak pas aan het licht als (bijna) alles al gebouwd is.

Het iteratieve of agile werken keert dat om: je doorloopt de cyclus niet één keer, maar vele keren in korte rondes. In elke iteratie (vaak een „sprint" van één tot enkele weken) analyseer, ontwerp, bouw en test je een klein, wérkend stukje van het geheel, dat je meteen aan de opdrachtgever laat zien. Zo lever je incrementeel op — steeds een beetje meer werkende software — en kun je na elke ronde bijsturen op grond van feedback. Dat past uitstekend bij projecten waar de eisen nog niet vaststaan of onderweg veranderen, wat in de praktijk bijna altijd zo is. De prijs is minder zekerheid vooraf en meer discipline in overleg en testen; documentatie ontstaat gaandeweg in plaats van in één groot document vooraf.

Welk model je ook kiest, je moet plannen. Een planning verdeelt het werk over de beschikbare tijd, legt de volgorde van taken vast (sommige kunnen pas ná andere) en zet mijlpalen: herkenbare tussenmomenten waarop een afgerond deel klaar moet zijn, zoals „eerste werkende versie" of „getest en opgeleverd". Mijlpalen maken voortgang zichtbaar en helpen op tijd bij te sturen als je achterloopt. In teamverband verdeel je bovendien taken en spreek je af wie wat doet. Deze projectmatige houding — analyseren, plannen, in fasen of iteraties werken en op mijlpalen controleren — is precies wat bij het schoolexamen in de praktische opdrachten wordt beoordeeld: niet alleen je eindproduct telt, maar ook je navolgbare werkwijze.

Uitgewerkt voorbeeld

Watervalt of agile? De boekenruil-app

Een klas bouwt in een half jaar een app om tweedehands schoolboeken te ruilen; de wensen staan nog niet vast en veranderen waarschijnlijk. Kies watervalt of agile, beredeneer je keuze en benoem wat de eerste iteratie oplevert.

Stap 1 — Weeg de situatie
Vier signalen springen eruit: de eisen zijn onzeker, ze zullen waarschijnlijk veranderen, de doorlooptijd is kort (een half jaar), en je wilt onderweg kunnen tonen en bijsturen.
Stap 2 — Toets het watervalmodel
Waterval werkt alleen goed als de eisen vooraf vaststaan; je doorloopt de fasen dan één keer. Hier staan de eisen juist niet vast, dus is het risico groot dat je aan het eind het verkeerde blijkt te hebben gebouwd.
Stap 3 — Kies agile en onderbouw
Agile past bij veranderende eisen: je werkt in korte sprints, levert na elke sprint een werkend stukje op en verzamelt feedback om bij te sturen. Zo verklein je het risico en houd je de wensen en het product op elkaar afgestemd.
Stap 4 — Bepaal de eerste iteratie
Kies het kleinste zinvolle werkende geheel: een leerling kan een boek plaatsen en de lijst met aangeboden boeken bekijken. Test dit met klasgenoten en gebruik hun reacties als invoer voor sprint 2 (bijvoorbeeld zoeken of reageren).

Resultaat: De onderbouwde keuze is agile, omdat de eisen onzeker en veranderlijk zijn. De eerste iteratie levert een minimale, wérkende versie op — boek plaatsen en de lijst bekijken — die je meteen kunt tonen en waarop je verder bouwt.

Veelgemaakte fouten

De fasen van de cyclus in de verkeerde volgorde zetten of testen/evaluatie vergeten — testen is een aparte, essentiële fase, geen bijzaak achteraf.
Agile gelijkstellen aan „zonder plan werken". Agile is juist strak georganiseerd in korte iteraties met veel overleg en testen.
Vage, niet-toetsbare eisen opschrijven („mooi", „gebruiksvriendelijk") zonder ze meetbaar te maken.

Actieve herhaling

Een klas wil in een half jaar een app bouwen waarmee leerlingen tweedehands schoolboeken kunnen ruilen. De precieze wensen staan nog niet vast en zullen waarschijnlijk veranderen. Kies gemotiveerd tussen het watervalmodel en een agile aanpak, en beschrijf wat je in de eerste iteratie (of eerste fase) oplevert.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Samenwerken, documenteren en versiebeheer#

Verdiepingexamenblad-nl

Samenwerkstroom met versiebeheer

Afb. 4De vaste stroom bij samenwerken met Git: je wijzigt op je eigen branch, legt het vast in een commit, deelt het (push), voegt het samen (merge) met de hoofdlijn, waarna iedereen de bijgewerkte versie heeft.

Software maak je bijna nooit alleen en zelden in één keer af: er werken meerdere mensen aan, over langere tijd, aan dezelfde bestanden. Daarom horen bij professioneel werken drie dingen die dit domein afsluiten: documenteren (zorgen dat anderen — en jij later — de code begrijpen), versiebeheer (samen aan dezelfde code werken zonder elkaars werk kwijt te raken) en testen (bewaken dat het klopt en blijft kloppen). Dit zijn geen bijzaken achteraf, maar bepalen of een project ook na maanden nog te begrijpen, te wijzigen en te vertrouwen is. Bij het schoolexamen tellen ze mee: een goed product zonder navolgbare documentatie is een half product.

Documentatie is alles wat uitlegt hoe en waarom een systeem werkt: van commentaar bij een lastig stuk code en duidelijke, sprekende namen voor variabelen en functies, tot een handleiding voor de gebruiker en een technische beschrijving voor wie later verder bouwt. Leesbare code is voor een groot deel al documentatie op zich: een variabele aantalLeerlingen zegt meer dan x, en een functie met één duidelijke taak leest als een zin. Goede documentatie legt vooral het waaróm vast — de code toont al wát er gebeurt, maar niet waaróm die keuze is gemaakt. De vuistregel: schrijf zó dat een klasgenoot (of jijzelf over drie maanden) het zonder jouw mondelinge uitleg begrijpt.

Versiebeheer is een systeem dat de geschiedenis van je project bijhoudt, zodat je nooit werk kwijtraakt en met meerdere mensen tegelijk aan dezelfde code kunt werken. Git is hiervan veruit het bekendst. Het kernidee is de commit: een opgeslagen momentopname van het hele project met een korte beschrijving van wat je veranderde („knop voor reserveren toegevoegd"). De reeks commits vormt een tijdlijn die je altijd kunt teruglezen — en waarnaar je kunt terugkeren: maak je een fout, dan draai je terug naar een eerdere, werkende commit in plaats van in paniek te repareren. Zo is versiebeheer tegelijk een vangnet (terugdraaien), een logboek (wie deed wat, wanneer en waarom) en de basis voor samenwerken.

Samenwerken zonder elkaar in de weg te zitten gebeurt met branches. Een branch is een aparte „zijlijn" waarop jij aan jouw onderdeel werkt terwijl een teamgenoot ongestoord op een eigen branch aan het zijne werkt; niemands halve werk breekt dat van de ander. Ben je klaar en werkt jouw stuk, dan voeg je je branch met samenvoegen (merge) terug bij de hoofdlijn. Raakten jullie hetzelfde stukje code aan, dan ontstaat een merge-conflict dat je bewust moet oplossen door te kiezen welke versie klopt — het systeem verzint dat nooit voor je. Een gedeelde opslagplaats (repository, vaak online via een dienst als GitHub) houdt alles bijeen en zorgt dat iedereen de nieuwste versie kan ophalen en de zijne kan delen.

Testen, ten slotte, is het systematisch controleren of het programma doet wat het moet — en dat blijft doen nadat je iets verandert. Je bedenkt vooraf testgevallen, inclusief lastige randgevallen (een lege lijst, een verkeerde invoer, het grootste toegestane getal), en vergelijkt de werkelijke uitvoer met de verwachte. Testen hoort in élke iteratie thuis, niet alleen aan het eind, want een fout die je vroeg vindt is goedkoop te herstellen. Samen met heldere afspraken over wie wat doet, een gedeelde planning en respect voor elkaars werk vormt dit „verantwoord en gestructureerd samenwerken": niet toevallig goed uitkomen, maar door documentatie, versiebeheer en testen bórgen dat het werk van het hele team optelt tot één betrouwbaar geheel. Hiermee sluit Domein A aan op alle maakdomeinen die volgen.

Uitgewerkt voorbeeld

Samen aan één app werken met commits en branches

Leerling A en B werken met Git aan dezelfde app. Leg uit hoe ze zonder werk te verliezen samenwerken, wat er bij een merge-conflict gebeurt, en hoe A een foutieve laatste commit terugdraait.

Stap 1 — Ieder een eigen branch
A maakt een branch „zoekfunctie", B een branch „inloggen". Ze werken los van elkaar, zodat het halve werk van de één dat van de ander nooit overschrijft.
Stap 2 — Werk vastleggen in commits
Beiden slaan hun voortgang op als commits met duidelijke beschrijvingen. De geschiedenis blijft zo leesbaar: je ziet wie wat wanneer en waarom veranderde.
Stap 3 — Samenvoegen en een conflict oplossen
Bij het samenvoegen (merge) van de branches met de hoofdlijn komt A's werk bij dat van B. Hebben ze hetzelfde bestand op dezelfde plek aangepast, dan ontstaat een merge-conflict; A en B bekijken samen de botsende regels en kiezen bewust welke versie blijft.
Stap 4 — Een fout terugdraaien
A ontdekt dat zijn laatste commit een fout bevat. Omdat elke commit een momentopname is, keert hij terug naar de vorige, werkende commit (terugdraaien) zonder de rest van de geschiedenis of het werk van B te verliezen.

Resultaat: Door op aparte branches te werken, alles in heldere commits vast te leggen, conflicten bewust op te lossen en gericht te kunnen terugdraaien, raken A en B geen werk kwijt en blijft de geschiedenis navolgbaar — precies wat versiebeheer mogelijk maakt.

Veelgemaakte fouten

Denken dat versiebeheer alleen „back-ups maken" is; het gaat vooral om samenwerken, een leesbare geschiedenis en gericht kunnen terugdraaien.
Een commitbeschrijving overslaan of nietszeggend maken („update", „asdf") — juist die beschrijving maakt de geschiedenis bruikbaar.
Denken dat een merge-conflict een crash of fout is; het is een normaal moment waarop jíj moet kiezen welke versie klopt.
Testen bewaren tot het einde in plaats van in elke iteratie te testen.

Actieve herhaling

Twee leerlingen werken samen met Git aan dezelfde app. Leerling A voegt een zoekfunctie toe, leerling B verbetert tegelijk het inlogscherm. (a) Leg uit hoe branches voorkomen dat ze elkaars werk overschrijven. (b) Wat gebeurt er bij het samenvoegen als beiden hetzelfde bestand hebben aangepast, en hoe los je dat op? (c) Leerling A ontdekt dat zijn laatste commit een fout bevat — leg uit hoe versiebeheer hem helpt.

Actief ophalen

Haal de kernpunten op — onthul ze daarna.

Bronnen: Examenprogramma informatica (HAVO) (CvTE / Examenblad)

Referenties en bronnen

Bronnen

CvTE / Examenblad

Examenprogramma informatica (HAVO)

Domein A: Vaardigheden

4 Onderdelen~23 min leestijd4 VaardighedenNiveau Basis 1 · Standaard 2 · Verdieping 1

Domein A: Vaardigheden

Kernpunten

Een schoolzwemtoernooi automatiseren met de vier pijlers

Kernpunten

Een datamodel voor het uitlenen van boeken

Kernpunten

Watervalt of agile? De boekenruil-app

Kernpunten

Samen aan één app werken met commits en branches

Bronnen

Domein A: Vaardigheden

Kernpunten

Een schoolzwemtoernooi automatiseren met de vier pijlers

Kernpunten

Een datamodel voor het uitlenen van boeken

Kernpunten

Watervalt of agile? De boekenruil-app

Kernpunten

Samen aan één app werken met commits en branches

Bronnen