4C/ID & Leeruitkomsten

In deze blog wordt de methodiek besproken waarbij leeruitkomsten ontwikkeld kunnen worden.

De leeruitkomsten moeten voldoen aan de volgende eisen:

1. Geformuleerd volgens de Tuning-methode
2. Geheel in lijn met HBO-i
3. Overeenkomstig de SSDLC
4. Direct toepasbaar in 4C/ID
5. Data filtering/sortering mogelijk

Tenslotte wordt de ontwikkeling van leeruitkomsten op opleidingsniveau beschreven.

Mijn collega's Henk Bosman en John Brouwers wil ik hier hartelijk bedanken voor hun bijdrage aan de analyse en het inzetten van hun grote technische inzicht. Zonder hun inzet was het resultaat niet zover gekomen.

1. Leeruitkomsten volgens Tuning

Het Tuningmodel is een formaat om een formulering mee op te bouwen. Hiermee wordt een eenduidige en complete formulering gestimuleerd. In de tabel hieronder staat een correcte formulering in de laatste rij:

2. Leeruitkomsten valide met HBO-i

Als voorbeeld nemen we het testproces dat in de Software Architectuurlaag van de domeinbeschrijving van HBO-i is opgenomen. Een eerste stap is de 'cellen' te markeren die over testen gaan.

Van deze gemarkeerde cellen is steeds het centrale werkwoord en zelfstandig naamwoord geselecteerd. Zo ontstaat een lijst met processtappen:

Aan elke processtap is een label toegevoegd: X/G/V , waar de letters respectievelijk 'wordt niet uitgevoerd'/'gegeven'/'zelf uitvoeren' betekenen. Ook is elke processtap gekoppeld aan een HBO-i activiteit.

Professional Skills

In geen geval willen we de Professional Skills (PS) bij het ontwikkelen van het onderwijs vergeten. Daarom zijn in dit proces bij de HBO-i activiteiten de bijbehorende Professional Skills getoond, zie afbeelding hieronder. In bijlage 3 van de domeinbeschrijving van HBO-i staat een overzicht welke PS bij welke HBO-i activiteit horen. Wellicht moet er een keuze worden gemaakt.

Natuurlijk moet opleiding breed gekozen worden welke PS per HBO-i activiteit worden aangeboden.

Processen

Uit alle 'cellen' van de HBO-i architectuurlaag hebben we de processen gedestilleerd. Deze zijn in de Leeruitkomsten repository op Github te vinden.

3. Leeruitkomsten valide met de beroepspraktijk

Sinds enkele jaren streven we naar meer samenhang in het onderwijs en gebruiken daarbij de SSDLC van Snyk. Over de ontwikkeling van ons onderwijsmodel gaat de blog Onderwijsstrategie I. Een SSDLC is een cirkelvormig model. Dit is logisch gezien het iteratieve karakter, maar het maakt het moeilijk om relaties mee vast te leggen. Daarom is de cirkelvorm uit elkaar getrokken en zijn relaties gelegd tussen de processtappen en de fasen van het SSDLC.

Validatie

De processtappen zijn zowel gekoppeld aan het model van de beroepspraktijk als gekoppeld aan de HBO-i domeinbeschrijving. Een eerste validatie is natuurlijk om te kijken of de SSDLC-fase past bij de HBO-i activiteit. Daarnaast is gebleken dat het ook een mooie 'praatplaat' is. Zoals: 'Hoort die relatie tussen processtap x wel bij SSDLC-fase y.' Hierdoor ontstaat kalibratie en gemeenschappelijk begrip en kunnen concrete keuzes gemaakt worden die later in het onderwijsmateriaal weerspiegeld worden.

Enige tijd geleden heeft mijn collega Henk Bosman, die een schat aan technische kennis heeft, bij wijze van proef, een vaardighedenhiërarchie ontwikkeld. Toen merkte hij al op dat testen meer fasen omvat dan één SSDLC-fase. Het ligt dan ook meer voor de hand om een vaardigheden hiërarchie op te bouwen aan de hand van processen dan aan fasen. Dat neemt niet weg dat de fasen voor zowel de beroepspraktijk als voor de onderwijspraktijk van cruciaal belang zijn voor sturing op het project.

Deze vaardighedenhiërarchie is gebruikt om het gedestilleerde testproces uit HBO-i te valideren. Het blijkt buitengewoon goed te matchen. Een paar kleine punten roepen nog om overleg.

4. Leeruitkomsten en 4C/ID

In de blog over ontwikkelstrategie werd onderstaand eenvoudig model gepresenteerd. Het is tijd om dit model bij te werken en in overeenstemming te brengen met de bevindingen in deze blog. Om vervolgens de vaardighedenhiërarchie op de juiste wijze te koppelen. Dit is belangrijk om uiteindelijk ook de prestatiedoelen en de beoordelingsinstrumenten te kunnen ontwikkelen.

De processen en processtappen uit HBO-i blijken goed als vaardighedenhiërarchie te kunnen dienen. Alle processen in de HBO-i Software Engineering architectuurlaag blijken uitstekend te passen bij de SSDLC-fasen. Bij het ontwikkelen van onderwijs kunnen één of meer vaardigheden geselecteerd worden en in een rijke context aangeboden worden. In de afbeelding hieronder wordt een processtap van het Testproces geoefend in de onderwijspraktijk in een leertaak die als context de Todo-applicatie heeft:

5. Leeruitkomsten als data

Vanuit alle diagrammen zijn de gegevens omgewerkt naar datarecords. Hiermee kan voldaan worden aan de eis voor filtering/sortering. De data is te vinden in de Github repository.

Per record is op basis van de processtap een passende Tuning-zin opgenomen (alleen Handelingswerkwoord en Onderwerp), bijvoorbeeld: De student valideert requirements.

Tuning Context

Tot nu toe lijkt het ons niet nodig om de context per record te beschrijven omdat HBO-i de contexten per niveau voorschrijft. Dit kan dus worden opgenomen bij de inleiding van de leeruitkomsten per niveau.

Tuning Standaarden

Recent is een verzameling standaarden door het Team SE verzameld, de zogenoemde standaardenkaart. Deze standaarden worden toegevoegd aan de juiste processtappen/records, rekening houdend met opbouw in niveau. Dit vraagt in de komende tijd overleg en een nadere uitwerking.

Leeruitkomsten op opleidingsniveau

Natuurlijk kunnen andere afstudeerrichtingen de methodiek volgen zoals in deze blog beschreven is, maar kunnen studenten instromen vanuit een andere architectuurlaag? Hoe vind je de verschillen? Zijn de verschillen overbrugbaar?

Laten we de proef op de som nemen. We gaan uit van onderstaande situatie waarin studenten vanuit een semester Intermediate Management op niveau 2 doorstromen naar Advanced Programming op niveau 3.

Laten we het testproces van de architectuurlaag Software Engineering en de architectuurlaag Organisatieprocessen met elkaar vergelijken om de verschillen in kaart te brengen.

Om te bepalen of deze doorstroommogelijkheid een goed idee is, kijken we naar twee aspecten:

1. Processtappen die niet op niveau 1 aangeboden worden
2. Complexiteit opbouw

De processtappen 'Opstellen testontwerp' en 'Evalueren test' zijn niet op niveau 1 aangeboden. Op niveau 2 (architectuurlaag Software Engineering) is dit dus een 'nieuw' onderwerp. Studenten die vanuit Organisatieprocessen doorstromen zullen dus in elk geval op deze processtappen moeten bijspijkeren.
Daarnaast is er sprake van opbouw in omgevingscomplexiteit, inhoudelijke complexiteit en het toevoegen van standaarden (bijvoorbeeld integratietesten op niveau 2). Dit betekent dat processtappen die op niveau 1 worden aangeboden, zoals 'Opstellen test', op niveau 2 verhoogd kunnen zijn in moeilijkheidsgraad. Dus ook voor die categorie processtappen moet worden nagegaan of de studenten vanuit Organisatieprocessen hiervoor moeten schakelen.

Deze analyse zou gedaan moeten worden voor alle processen. Vervolgens moet een opleiding een keuze maken of zij deze route toegankelijk willen maken waarbij ook allerlei andere zaken op de achtergrond een rol spelen. Het zou goed zijn om deze analyse transparant te maken om het gesprek inhoudelijk en goed te kunnen voeren.

Conclusie

De conclusie van deze blog is dat het opstellen van leeruitkomsten niet veel tijd hoeft te kosten, 100% valide kan zijn met HBO-i, en 100% valide met een gekozen beroepspraktijkmodel. Verder helpen de ontwikkelde leeruitkomsten om helderheid te verschaffen bij het uitzetten van leerroutes.

In de volgende blog aandacht voor 4C/ID en programmatisch toetsen.