Master Software Engineering

Zelfevaluatierapport ten behoeve van de externe beoordeling van de
Master Software Engineering
CROHO-registratie 60228
Onderwijsinstituut Informatiewetenschappen
Universiteit van Amsterdam
Februari 2007
Faculteit der Natuurwetenschappen, Wiskunde en Informatica
Hogeschool van Amsterdam
in samenwerking met
12-FEB-07 1

Personalia
Prof.dr. P. Klint Opleidingsdirecteur
Drs. H. Dekkers, Prof.dr. D.N.J. van Eijck, Dr. J. Vinju
Opleidingscoördinatoren
Drs. H. Dekkers en Prof.dr. P. Klint (met bijdragen van het docententeam)
Auteur(s) zelfevaluatie
Dr. P. van Emde Boas Voorzitter van de Examencommissie
Dr. A.D. Pimentel Voorzitter van de Opleidingscommissie (tot Dec. 2006)
A. Belgraver, Drs H. Dekkers, Drs. J. van Ginkel (vz.), M. van der Schee
Opleidingscommissie (sinds Dec. 2006)
Prof.dr. K.J.F. Gaemers Decaan Faculteit der Natuurwetenschappen, Wiskunde en
Informatica (FNWI)
Prof.dr. J.A. Bergstra Directeur Onderwijsinstituut Informatiewetenschappen
Dr. A. Haker Studieadviseur
Kenmerken van de instelling
Naam van de instelling Universiteit van Amsterdam
Adres Spui 21
1012 WX Amsterdam
Instellingsbestuur College van Bestuur UvA
Postbus 19268
1000 GG Amsterdam
Contactpersoon Mw.dr. J.A. le Loux-Schuringa
Kenmerken van de opleiding
Naam van de opleiding Master Software Engineering (CROHO-registratie 60228)
Studielast: 60 studiepunten
Variant(en) Voltijds- en deeltijdsvariant
Adres Onderwijsinstituut Informatiewetenschappen
Nieuwe Achtergracht 166
1018 WV Amsterdam
Contactpersoon Drs. C.R. van Wensen
12-FEB-07 2

INLEIDING
De éénjarige Master Software Engineering (CROHO-registratie 60228) aan de Universiteit
van Amsterdam (UvA) is in het cursusjaar 2003-2004 van start gegaan. De opleiding heeft
als doel om hooggekwalificeerde Software Engineers op te leiden die zowel in het
onderzoek als in de bedrijfspraktijk carrière zullen maken. Aan de opleiding wordt
bijgedragen door de Hogeschool van Amsterdam (HvA) en Vrije Universiteit Amsterdam
(VUA).
Deze zelfstudie beschrijft de visie op Software Engineering die aan de opleiding ten
grondslag ligt, de doelstellingen van de opleiding, het onderliggende leermodel, de
gebruikte besturingsmechanismen, de instroom, en het feitelijke curriculum. Daarnaast
wordt feitenmateriaal gegeven om beoordeling van de opleiding mogelijk te maken.
De volgende kenmerken dragen in belangrijke mate bij aan de kwaliteit van de opleiding:
● Het curriculum is gebaseerd op een algemeen aanvaarde kennisbasis op het gebied
van Software Engineering (SWEBOK) en daarvan afgeleide curriculumopzet
(SEEK).
● Het curriculum bevat geen enkele keuze en kan daardoor zeer efficiënt aangeboden
worden. Dit bevordert de sociale cohesie in elke jaargroep.
● Sterke nadruk op motivatie en studiehouding. Dit resulteert in hoog rendement
(circa 90%), geringe vertraging, grote inzet van studenten (circa veertig uur per
week) en zeer goed bezochte colleges.
● Er is een zeer effectief en flexibel kwaliteitssysteem met veel interactie tussen
studenten en docententeam.
● Er is veel aandacht voor het aanleren van academische vaardigheden. Hierbij wordt
sterk de nadruk gelegd op het verwerven van inzicht, het kunnen oplossen van
problemen en het presenteren van kennis.
● Het studieprogramma is flexibel, geïntegreerd en gestroomlijnd. Het is toegesneden
op de karakteristieken van de instroom en ondersteunt een sterk
ontwikkelingsmodel. Door de flexibiliteit kan het studieprogramma worden
afgestemd op de specifieke behoeften van de jaargang en de individuele student.
● Door gerichte voorbereiding, planning en begeleiding kan een student bij zijn
afstuderen in 4-5 maanden aantonen dat hij van mastersniveau is.
● Het onderwijs wordt verzorgd door een klein en hecht docententeam dat excellente
wetenschappelijke reputatie combineert met langjarige praktijkervaring in het
bedrijfsleven. Hierdoor krijgen studenten intensieve, gerichte begeleiding van hoog
niveau.
Van de alumni vindt 85% direct na de opleiding een baan, meestal in het bedrijfsleven
i.h.b. zakelijke dienstverlening, 12% bij universiteit of onderzoeks-instelling. 84% van de
alumni geeft de opleiding een 8 of hoger en beveelt deze graag aan bij collega's of
voormalige medestudenten. De eindtermen van de opleiding worden als zeer relevant
beoordeeld.
Deze zelfstudie is totstandgekomen dankzij inhoudelijke bijdragen van het docenteam,
commentaar en suggesties van de Opleidingscommissie (met dank aan dr. A. Pimentel), de
Examencommissie (met dank aan dr. P. van Emde Boas), en hulp bij het verzamelen van
gegevens en de organisatie van deze accreditatie door het Onderwijsinstituut
Informatiewetenschappen (met dank aan Prof.dr. J.A. Bergstra, mw. dr. A. Haker, mw.dr.
ing. M. Kranenburg, mw. L.M Schnater, en drs. C.R. van Wensen).
12-FEB-07 INLEIDING 3

INHOUDSOPGAVE
INLEIDING...........................................................................................................................3
INHOUDSOPGAVE.............................................................................................................4
OVERZICHT GEHANTEERDE BEGRIPPEN....................................................................6
VISIE OP SOFTWARE ENGINEERING.............................................................................7
Methodes op maat..............................................................................................................7
Onderzoeker zijn................................................................................................................7
Vakmanschap.....................................................................................................................7
Evoluerende technologieën ...............................................................................................8
Engineering is teamwork...................................................................................................8
DOELSTELLINGEN VAN DE MASTEROPLEIDING .....................................................9
Algemene eindtermen .......................................................................................................9
Specifieke eindtermen......................................................................................................10
Eenjarige opleiding..........................................................................................................10
T1.1 Domeinspecifieke eisen.................................................................................10
T1.2 Niveau............................................................................................................11
T1.3 Oriëntatie.......................................................................................................11
T1.B1 Analyse eindkwalificaties...........................................................................11
CURRICULUM...................................................................................................................14
Bepalen vereiste kennis en vaardigheden........................................................................14
Overzicht curriculum.......................................................................................................14
Didactische vormen..........................................................................................................14
Basis van curriculum in onderzoek en praktijk................................................................16
Ontwikkelen vak..............................................................................................................17
Deeltijdvariant..................................................................................................................17
Verbeterpunten.................................................................................................................18
T2.1 Eisen WO.......................................................................................................18
T2.2 Relatie tussen doelstellingen en inhoud programma.....................................19
T2.3 Samenhang programma.................................................................................19
T2.4 Studielast.......................................................................................................19
LEERMODEL.....................................................................................................................21
Attitudevorming...............................................................................................................22
Basisvaardigheden...........................................................................................................23
Automatiseren..................................................................................................................24
Zelfontplooiing.................................................................................................................24
Leeromgeving..................................................................................................................25
INSTROOM.........................................................................................................................26
Instroomprofiel.................................................................................................................26
Werving............................................................................................................................27
Selectie.............................................................................................................................27
Schakelprogramma...........................................................................................................28
T2.5 Instroom.........................................................................................................30
T2.6 Duur...............................................................................................................30
T2.7 Afstemming tussen vormgeving en inhoud...................................................31
T2.8 Beoordeling en toetsing.................................................................................31
BESTURING EN KWALITEITSVERBETERING............................................................33
Wekelijkse voortgangsbespreking...................................................................................33
Kleine omgeving..............................................................................................................33
Vierjarige kwaliteitscyclus...............................................................................................33
Algemene UvA policy t.a.v. opleidingen en docententeams...........................................34
Docententeam Master Software Engineering..................................................................34
T3.1 Eisen WO.......................................................................................................36
12-FEB-07 INHOUDSOPGAVE 4

T3.2 Kwantiteit personeel......................................................................................36
T3.3 Kwaliteit personeel........................................................................................37
Continuïteit.......................................................................................................................38
Instroom en selectie.........................................................................................................38
Kwaliteit uitstroom .........................................................................................................38
Fraude...............................................................................................................................38
Afsluiting.........................................................................................................................39
Alumni.............................................................................................................................39
Ontwikkeling van de opleiding........................................................................................40
T4.1 Materiële voorzieningen................................................................................41
T4.2 Studiebegeleiding..........................................................................................41
T5.1 Evaluatie resultaten.......................................................................................41
T5.2 Maatregelen tot verbetering...........................................................................41
T5.3 Betrekken van medewerkers, studenten, alumni en beroepenveld................42
T6.1 Gerealiseerd niveau.......................................................................................42
T6.2 Onderwijs-rendement....................................................................................43
Appendix A: Kwantitatieve gegevens Master Software Engineering.................................44
A1. Instroom en Uitstroom..............................................................................................44
A2. Gemiddelde eindcijfers.............................................................................................44
A3. Studentenevaluaties...................................................................................................45
A4. Fraudegevallen..........................................................................................................46
A5. Evaluatie door alumni...............................................................................................46
Appendix B. Overzicht Vakken...........................................................................................53
B1. Software Evolution....................................................................................................53
B2. Software Architecture................................................................................................54
B3. Requirements Engineering........................................................................................56
B4. Software Testen.........................................................................................................58
B5. Software Constructie.................................................................................................63
B6. Software Proces.........................................................................................................64
B7. Afstudeerproject........................................................................................................68
Appendix C: Vergelijking curriculum met SWEBOK en SEEK.........................................71
SWEBOK.........................................................................................................................71
SEEK................................................................................................................................72
Appendix D. Vergelijkbare opleidingen..............................................................................73
Appendix E: Overzicht Scripties..........................................................................................76
Scripties 2005-2006.........................................................................................................76
Scripties 2004-2005.........................................................................................................77
Scripties 2003-2004.........................................................................................................78
Appendix F. Standaardvoorzieningen Universiteit van Amsterdam...................................80
Appendix G. Kwaliteitszorg Universiteit van Amsterdam..................................................83
Kwaliteitsplan UvA .........................................................................................................83
Kwaliteitsplan FNWI.......................................................................................................83
12-FEB-07 INHOUDSOPGAVE 5

OVERZICHT GEHANTEERDE BEGRIPPEN
Adviesraad: een groep externe deskundigen die advies geven over de opzet van de hele
opleiding.
Afstudeerproject: afsluitend project dat gebaseerd is op een vantevoren opgesteld plan
van aanpak en bestaat uit een stage van drie maanden, meestal uitgevoerd bij een externe
organisatie, en de verslaglegging daarvan in een afstudeerscriptie. Door de uitgebreide
voorbereiding (plan van aanpak, literatuurstudie) en de gefaseerde beoordelingsprocedure
is er effectief circa 5-6 maanden beschikbaar voor het afstudeerproject.
Afstudeerscriptie: het schriftelijke verslag waarin de resultaten van de stage beschreven
worden. Voor de afstudeerscriptie wordt een vast sjabloon gehanteerd.
Klankbordgroep: een groep externe deskundigen die op incidentele basis feedback geven
op de opzet van een specifiek vak.
Literatuurstudie: een studie van wetenschappelijke publicaties die relevant zijn voor het
afstudeerproject. Het resultaat is een geannoteerde bibliografie.
Papersessie: wekelijks bijeenkomst in kleine groepen waarin aan de vakken gerelateerde
wetenschappelijke publicaties behandeld worden. Dit is een belangrijke onderwijsvorm
voor het aanleren van vaardigheden en leren kennen van de vakliteratuur.
Plan van aanpak: een plan voor het afstudeerproject volgens een vast sjabloon.
Stage: het praktische, uitvoerende, deel van het afstudeerproject. Vindt meestal plaats bij
een externe organisatie.
SEEK: Software Engineering Education Knowledge: een door ACM en IEEE in 2004
opgestelde lijst van kennis die elke in de software afgestudeerde bachelor moet weten.
SEEK is een op SWEBOK gebasserd curriculum. Zie: http://sites.computer.org/ccse/.
SWEBOK: Software Engineering Body of Knowledge (www.swebok.org): een door de
IEEE opgesteld overzicht van alle kennis op het gebied van software engineering.
Vak: één van de zes inhoudelijke eenheden die in de opleiding aangeboden worden. Het
betreft Requirements Engineering, Software Architectuur, Software Proces, Software
Constructie, Software Testen en Software Evolutie.
Voortgangsbespreking: wekelijkse bijeenkomst in kleine groepen waarin de voortgang
van de studie zowel op het niveau van de groep als van de individuele student besproken
wordt.
12-FEB-07 6

VISIE OP SOFTWARE ENGINEERING
Methodes op maat
Software Engineering richt zich op het systematisch ontwerpen, bouwen en onderhouden
van grote software systemen die op tijd en binnen de begroting opgeleverd worden,
betrouwbaar en efficiënt zijn, voldoen aan de wensen van de klant, en ook op langere
termijn goed onderhoudbaar zijn. Een professionele software engineer moet ervoor zorgen
dat het software systeem steeds wordt aangepast aan de veranderende wensen en eisen van
de klant en dat de software de veranderende bedrijfsprocessen goed blijft ondersteunen.
Software Engineering is een moeilijk vakgebied. Er zijn geen oplossingen die altijd
werken. Zelfs best practices geven geen garantie op succes. Redenen hiervoor zijn 1 :
● Softwareproducten behoren tot de meest complexe door de mens gemaakte
systemen. Software heeft intrinsieke eigenschappen (zoals complexiteit,
onzichtbaarheid, en veranderbaarheid) die niet eenvoudig te adresseren zijn.
● Programmeertechnieken en -processen die goed werken voor een individuele
ontwikkelaar of een klein ontwikkelteam om systemen van bescheiden omvang te
maken schalen niet naar de ontwikkeling van grote, complexe, systemen met een
omvang van miljoenen regels code, jaren inspanning om te bouwen, en honderden
ontwikkelaars.
● Het innovatietempo in computer- en softwaretechnologie versnelt de vraag naar
nieuwe en evoluerende softwareproducten. De verwachtingen van klanten en de
sterke competitie in de markt stellen onze mogelijkheden op de proef om
kwaliteitssoftware op te leveren binnen aanvaardbare planningen.
Het analyseren van situatie en methode is van groter belang dan het beheersen van best
practices. Naast kennis gaat het vooral om inzicht en vaardigheden. Daarbij moet de
afstand tussen technische mogelijkheden en bedrijfsmatige wensen overbrugd worden.
Onderzoeker zijn
De wetenschappelijke kennis op het gebied van Software Engineering is omvangrijk. Op
tal van gebieden vindt gespecialiseerd onderzoek plaats. Fundamenteel onderzoek is soms
moeilijk toegankelijk en relatief schaars. Er zijn vanuit de praktijk een overvloed aan best
practices bekend. Studenten moeten leren deze kennis te vinden, te filteren en te
gebruiken.
Tijdens het toepassen leert een student theorie en best practices pas echt op waarde
schatten. De opleiding biedt uitdagende, confronterende en realistische praktijkopdrachten.
Studenten zijn daarna in staat om aan de hand van een situatieanalyse te bepalen welke
theorie op welke wijze toepasbaar is. Deze sterke binding tussen theorie en praktijk vormt
een rode draad in de opleiding. Het afstudeerproject is een proeve van bekwaamheid
waarbij een student de tijd krijgt om zijn kennis toe te passen en zich deze vaardigheden
helemaal eigen te maken.
Vakmanschap
Het ontwikkelen van grote software systemen betekent in de praktijk dat vele beslissingen
genomen moeten worden. Een Software Engineer moet in staat zijn om de juiste keuzes te
maken. Dit vereist vakmanschap: inzicht in de problematiek, kennis van mogelijke
1 Ontleend aan Software Engineering 2004, Curriculum Guidelines for Undergraduate Degree Programs in
Software Engineering, The Joint Task Force on Computing Curricula IEEE Computer Society and
Association for Computing Machinery, 2004.
12-FEB-07 VISIE OP SOFTWARE ENGINEERING 7

oplossingen, heldere analytische vaardigheden, het overzien van het grote geheel en het
verwerven van de benodigde kennis. De opleiding zal de student confronteren met
problemen die in korte tijd moeten worden opgelost. Studenten leren om problemen op een
gestructureerde manier te analyseren. De beperkte tijd zorgt ervoor dat hoofd- en bijzaken
moeten worden onderscheiden.
Lef, de wil om te experimenteren en de wil om te leren zijn cruciaal. Studenten moeten
leren abstraheren, maar de duivel schuilt vaak in de details. Daar waar nodig moet de
student de diepte in gaan, waarbij het doel niet uit het oog wordt verloren.
Evoluerende technologieën
Technologie is continu in verandering. Nieuwe toepassingen en technieken zijn aan de
orde van de dag. Er is een enorme diversiteit aan technologieën. Toch zijn de problemen
die een Software Engineer tegenkomt herkenbaar en overal van toepassing. Software
Engineers moeten dan ook niet gebonden zijn aan één technologie, maar de vaardigheid
hebben om zich een nieuwe technologie en nieuwe tools snel eigen te maken. In de
opleiding zal de student met verschillende technologieën geconfronteerd worden. Vanuit
de opleiding ligt de focus op het oplossen van problemen en niet op het doorgronden van
een bepaalde technologie. Reflectie op eigen kennis en vaardigheden is daarbij essentieel.
Engineering is teamwork
Bij de ontwikkeling van grote softwaresystemen zijn verschillende stakeholders betrokken.
De ontwikkeling van deze systemen vergt planning, coördinatie en afstemming. Hiervoor
is het van belang dat studenten goed leren samenwerken en kennis nemen van technieken
en methodes om grote projecten in goede banen te leiden. In de opleiding zal dan ook veel
in teams worden samengewerkt. Studenten moeten hierbij samen met andere studenten
beslissingen nemen, zaken doorspreken en afstemmen. Naast verbale communicatie vindt
veel afstemming plaats door middel van documenten. In de opleiding wordt veel aandacht
besteed aan het helder en beknopt documenteren. In alle vakken wordt de nadruk gelegd
op technieken en methodes (best practices) die gebruikt kunnen worden in grootschalige
projecten.
12-FEB-07 8

DOELSTELLINGEN VAN DE MASTEROPLEIDING
Een goede Software Engineer heeft kennis van de methoden en technieken van het
vakgebied software engineering en weet deze in de praktijk toe te passen. Een opleiding
alleen is daarvoor niet toereikend. Alleen in de praktijk zal een Software Engineer
geconfronteerd worden met de echte problematiek en de weerbarstigheid daarvan. Slechts
dan zal hij expertise op kunnen bouwen en diep inzicht kunnen krijgen.
Een goede opleiding zorgt ervoor dat de student op een zo hoog mogelijk niveau start als
praktiserend of onderzoekend Software Engineer en in staat is om te leren van zijn
ervaringen zodat hij in staat is om snel het niveau van professional te bereiken en zich
voortdurend te verbeteren.
Dit profiel is als volgt vastgelegd in de eindtermen van de opleiding.
Algemene eindtermen
De master Software Engineer:
A1.heeft op het gebied van Software Engineering inzicht in de belangrijkste theorieën,
methoden en technieken en beschikt over voldoende achtergrond om zich op korte
termijn te kunnen inwerken in nieuwe methoden en technieken.
A2.is in staat om met dit inzicht bestaande en nieuwe problemen innovatief op te
lossen, waarbij theorie op de juiste wijze in de praktijk wordt toegepast. Hierbij kan
de master zowel domeinspecifieke problemen als problemen op het gebied van de
Software Engineering analyseren en oplossen.
A3.kan een waardevolle bijdrage leveren aan complexe software projecten waarin
wordt verlangd dat men academische kennis en kunde zelfstandig en kritisch
toepast.
A4.heeft voldoende technische kennis en intellectuele capaciteiten om na enige jaren
ervaring een leidinggevende of adviserende rol te vervullen in het werkveld van de
Software Engineering.
A5.is op het gebied van Software Engineering in staat een visie te ontwikkelen en bij
te dragen aan de evolutie, innovatie en beleidsontwikkeling van softwaresystemen .
A6.kan Software Engineering problemen aanpakken met behulp van abstractie en
modelvorming en is in staat om op basis van onvolledige informatie tot oplossingen
te komen die rekening houden met de maatschappelijke context.
A7.is in staat zich zowel mondeling als schriftelijk helder uit te drukken en weet
problemen en oplossingen op het juiste abstractieniveau uit te leggen.
A8.kan goed in multidisciplinaire teams functioneren.
A9.heeft onderzoeksvaardigheden op academisch niveau waardoor hij of zij in staat is
zelfstandig onderzoek op het gebied van de Software Engineering uit te voeren.
A10.is in staat om kennis te nemen van ervaringen van anderen en te reflecteren op
eigen prestaties; daardoor kan hij zichzelf continu ontwikkelen.
A11.is vaardig in het exploreren (zoeken, lezen en beoordelen) van de vele vormen,
zowel wat betreft inhoud als medium, van documentatie en literatuur op het gebied
van de Software Engineering.
12-FEB-07 DOELSTELLINGEN VAN DE MASTEROPLEIDING 9

Specifieke eindtermen
De master Software Engineer:
S1. beheerst methoden en technieken om een software systeem te analyseren en mee te
laten evolueren met de veranderende eisen die aan dat systeem worden gesteld.
S2. is in staat kwalitatief hoogwaardige systemen te beoordelen door het systematisch
gebruik van testmethoden en technieken.
S3. is in staat richtlijnen op het gebied van softwareconstructie op te stellen,
bijvoorbeeld ten aanzien van coding standards, herstructurering, configuratie
management, en build processen.
S4. is in staat systeemeisen te vertalen in een systeemarchitectuur en afwegingen tussen
conflicterende eisen zorgvuldig te maken en te motiveren.
S5. is in staat wensen van systeemgebruikers om te zetten in specifieke requirements,
objectmodellen en acceptatietests.
S6. is op de hoogte van diverse software procesmodellen en kent de voor- en nadelen
daarvan. Hij is in staat een ontwikkelingsproces te kiezen voor een specifiek
project, en het geselecteerde proces optimaal af te stemmen op de eisen die door
dat project worden gesteld.
Eenjarige opleiding
Er is gekozen voor een éénjarige opleiding. Door een uitgekiend, intensief, programma
worden studenten opgeleid tot een Master of Science die goed toegerust is op een carrière
als wetenschappelijk onderzoeker of professioneel Software Engineer.
De éénjarige variant is aantrekkelijk voor zowel de student als voor de universiteit. De
student kan na een gedegen vooropleiding in relatief korte tijd een grote stap zetten. Voor
de universiteit is er sprake van een overzichtelijk, goed stuurbaar programma.
Deze éénjarige master levert om diverse redenen studenten op van een volwaardig
academisch niveau:
● In een korte, intensieve, opleiding is het gemakkelijker om het uiterste uit
studenten te halen. Studenten besteden circa 40 uur per week aan de opleiding.
● De opleiding is sterk gericht op het eindresultaat. Hierdoor is de student in staat om
zich te blijven motiveren en gedurende het hele studiejaar een topprestatie te
leveren.
● Doordat het opleidingsprogramma op maat van de student is gesneden, is er
nauwelijks vertraging in de vorm van vakken die moeten worden ingehaald. Voor
studenten die meer tijd nodig hebben is er uitloop mogelijk in de maanden juli,
augustus en september.
T1.1 Domeinspecifieke eisen 2
De eindkwalificaties van de opleiding sluiten aan bij de eisen die door (buitenlandse) vakgenoten en de
beroepspraktijk gesteld worden aan een opleiding in het betreffende domein (vakgebied/discipline en/of
beroepspraktijk).
De eindkwalificaties sluiten aan bij internationale eisen door:
● Het curriculum te baseren op SWEBOK.
2 We geven door de hoofdtekst heen (in lichtgrijze kaders) antwoord op de vragen die gesteld worden in
het Algemeen Referentiekader WO-opleidingen, Het Academisch Timmermansoog, Certiked, oktober
2005.
12-FEB-07 DOELSTELLINGEN VAN DE MASTEROPLEIDING 10

● Gebruik van recente leerboeken en wetenschappelijke publicaties.
● Sterke koppeling tussen opleiding en onderzoek.
● Actieve exploratie van de wetenschappelijke literatuur door studenten.
● Wetenschappelijke en beroepsmatige reputatie van het docententeam.
Zie verder de hoofdstukken CURRICULUM (blz. 14) en LEERMODEL (blz. 21).
T1.2 Niveau
De eindkwalificaties van de opleiding sluiten aan bij algemene international geaccepteerde beschrijvingen
van de kwalificaties van een Bachelor of een Master.
De opleiding is een nieuwe opleiding die in 2003 is ontwikkeld. Hierbij is bij het opzetten
van de kwalificaties nauw gewerkt vanuit het Dublin profiel voor masteropleidingen.
Zie verder het hoofdstuk CURRICULUM (blz. 14) en het onderstaande overzicht waarin
de Dublin descriptoren zijn afgezet tegen de opleidingsdoelen en eindkwalifcaties.
T1.3 Oriëntatie
De eindkwalificaties van de opleiding sluiten aan bij de volgende beschrijvingen
van een Bachelor en een Master in het WO:
a. De eindkwalificaties zijn ontleend aan eisen vanuit de wetenschappelijke discipline, de internationale
wetenschapsbeoefening en voor daarvoor in aanmerking komende opleidingen de relevante praktijk in het
toekomstige beroepenveld
b. Een WO-bachelor heeft de kwalificaties voor toegang tot tenminste één verdere WO-studie op
masterniveau en eventueel voor het betreden van de arbeidsmarkt
c. Een WO-master heeft de kwalificaties om zelfstandig wetenschappelijk onderzoek te verrichten of multi- en
interdisciplinaire vraagstukken op te lossen in een beroepspraktijk waarvoor een WO-opleiding vereist is of
dienstig is
De opleiding is een nieuwe opleiding die in 2003 is ontwikkeld. Het verrichten van
wetenschappelijk onderzoek en de aansluiting met de beroepspraktijk waarvoor een WOopleiding
vereist of dienstig is, is verwerkt in de eindkwalificaties.
Zie verder de hoofdstukken CURRICULUM (blz. 14) en LEERMODEL (blz. 21).
T1.B1 Analyse eindkwalificaties
Onderstaand overzicht laat zien hoe de Dublin descriptoren terugkomen in de eindkwalificaties en
opleidingsdoelen zoals gegeven op blz. 9 en 10.
Dublin descriptoren Master Software Engineering
1. Kennis en inzicht
Algemene eindkwalificaties
Heeft aantoonbare kennis en
inzicht, gebaseerd op de kennis
en het inzicht op het niveau van
Master en die deze overtreffen
en/of verdiepen, alsmede een
A1.De master heeft op het gebied van Software Engineering inzicht in
de belangrijkste theorieën, methoden en technieken en beschikt over
voldoende achtergrond om zich op korte termijn te kunnen inwerken
in nieuwe methoden en technieken.
basis of een kans bieden om een A2.De master is in staat om met dit inzicht bestaande en nieuwe
originele bijdrage te leveren aan problemen innovatief op te lossen, waarbij theorie op de juiste wijze
het ontwikkelen en/of toepassen in de praktijk wordt toegepast. Hierbij kan de master zowel
van ideeën, vaak in
domeinspecifieke problemen als problemen op het gebied van de
onderzoeksverband.
Software Engineering analyseren en oplossen.
A3.De master kan een waardevolle bijdrage leveren aan complexe
software projecten waarin wordt verlangd dat men academische
kennis en kunde zelfstandig en kritisch toepast.
A4.De master heeft voldoende technische kennis en intellectuele
capaciteiten om na enige jaren ervaring een leidinggevende of
adviserende rol te vervullen in het werkveld van de Software
12-FEB-07 DOELSTELLINGEN VAN DE MASTEROPLEIDING 11

2. Toepassen kennis en inzicht
Is in staat om kennis en inzicht en
probleemoplossende vermogens
toe te passen in nieuwe of
onbekende omstandigheden
binnen een bredere (of
multidisciplinaire) context die
gerelateerd is aan het vakgebied;
is in staat om kennis te integreren
en met complexe materie om te
gaan.
3. Oordeelsvorming
Is in staat om oordelen te
formuleren op grond van
onvolledige of beperkte
informatie en daarbij rekening te
houden met
sociaalmaatschappelijke en
ethische verantwoordelijkheden,
die zijn verbonden aan het
toepassen van de eigen kennis en
oordelen.
4. Communicatie
Is in staat om conclusies, alsmede
de kennis, motieven en
overwegingen die hieraan ten
grondslag liggen, duidelijk en
ondubbelzinnig over te brengen
op een publiek van specialisten of
Engineering.
A9. De master is in staat om kennis te nemen van ervaringen van
anderen en te reflecteren op eigen prestaties; daardoor kan hij zichzelf
continu ontwikkelen.
Specifieke eindkwalificaties
S1.De master beheerst methoden en technieken om een software
systeem te analyseren en mee te laten evolueren met de veranderende
eisen die aan dat systeem worden gesteld.
S2.De master is in staat kwalitatief hoogwaardige systemen te
beoordelen door het systematisch gebruik van testmethoden en
technieken.
S3.De master is in staat richtlijnen op het gebied van
softwareconstructie op te stellen, bijvoorbeeld ten aanzien van coding
standards, herstructurering, configuratie management, en build
processen.
S4.De master is in staat systeemeisen te vertalen in een
systeemarchitectuur en afwegingen tussen conflicterende eisen
zorgvuldig te maken en te motiveren.
S5.De master is in staat wensen van systeemgebruikers om te zetten
in specifieke requirements, objectmodellen en acceptatietests.
S6.De master is op de hoogte van diverse software procesmodellen en
kent de voor- en nadelen daarvan. Hij is in staat een
ontwikkelingsproces te kiezen voor een specifiek project, en het
geselecteerde proces optimaal af te stemmen op de eisen die door dat
project worden gesteld.
Algemene eindkwalificaties
A2.De master is in staat om met dit inzicht bestaande en nieuwe
problemen innovatief op te lossen, waarbij theorie op de juiste wijze
in de praktijk wordt toegepast. Hierbij kan de master zowel
domeinspecifieke problemen als problemen op het gebied van de
Software Engineering analyseren en oplossen.
A5.De master is op het gebied van Software Engineering in staat een
visie te ontwikkelen en bij te dragen aan de evolutie, innovatie en
beleidsontwikkeling van softwaresystemen
A9.De master heeft onderzoeksvaardigheden op academisch niveau
waardoor hij of zij in staat is zelfstandig onderzoek op het gebied van
de Software Engineering uit te voeren.
Algemene eindkwalificaties
A5.De master is op het gebied van Software Engineering in staat een
visie te ontwikkelen en bij te dragen aan de evolutie, innovatie en
beleidsontwikkeling van softwaresystemen
A6.De master kan Software Engineering problemen aanpakken met
behulp van abstractie en modelvorming en is in staat om op basis van
onvolledige informatie tot oplossingen te komen die rekening houden
met de maatschappelijke context.
Algemene eindkwalificaties
A7.De master is in staat zich zowel mondeling als schriftelijk helder
uit te drukken en weet problemen en oplossingen op het juiste
abstractieniveau uit te leggen.
A8.De master kan goed in multidisciplinaire teams functioneren.
12-FEB-07 DOELSTELLINGEN VAN DE MASTEROPLEIDING 12

niet-specialisten.
5. Leervaardigheden
Bezit de leervaardigheden die
hem of haar in staat stellen een
vervolgstudie aan te gaan met een
grotendeels zelfgestuurd of
autonoom karakter
Algemene eindkwalificaties
A10.De master is in staat om kennis te nemen van ervaringen van
anderen en te reflecteren op eigen prestaties; daardoor kan hij zichzelf
continu ontwikkelen.
A11.De master is vaardig in het exploreren (zoeken, lezen en
beoordelen) van de vele vormen, zowel wat betreft inhoud als
medium, van documentatie en literatuur op het gebied van de
Software Engineering.
12-FEB-07 13

CURRICULUM
Bepalen vereiste kennis en vaardigheden
Bij de bepaling van kennis en vaardigheden die in deze opleiding onderwezen worden is
uitgegaan van de de Software Engineering Body of Knowledge (SWEBOK, zie
www.swebok.org),. SWEBOK is een onder leiding van de IEEE totstandgekomen
beschrijving van alle kennis op het gebied van Software Engineering. Met SWEBOK als
startpunt is een curriculum opgesteld dat de volgende kenmerken heeft:
● Een goede overdekking van het complete Software Engineering proces.
● Een balans tussen “harde” (=technische) vakken en meer “zachte” (=sociaaleconomisch
en bedrijfskundige) vakken.
● Voldoende wetenschappelijke diepgang.
● Voldoende aansluitend op best practices.
● Ruimte voor het eigen maken, verdiepen en integreren van de aangeboden
theoretische kennis door het aanbieden van velerlei praktijkopdrachten en het
inplannen van relatief veel tijd voor de afstudeerstage.
Overzicht curriculum
Het resultaat is een curriculum waarin de volgende vakken centraal staan:
● Software Evolutie (zie blz. 53).
● Software Architectuur (zie blz. 54).
● Requirements Engineering (zie blz. 56).
● Software Testen (zie blz. 58).
● Software Constructie(zie blz. 63).
● Software Proces (zie blz. 64).
● Afstudeerproject (inclusief voorbereiding, literatuurstudie en stage, zie blz. 68 ).
Didactische vormen
Kennis en vaardigheden worden onderwezen in de volgende didactische vormen:
● Hoorcolleges waarin theoretische kennis wordt onderwezen.
● Practica waarin de theoretische kennis toegepast wordt in praktijkcases.
● “Papersessies” waarin wetenschappelijk artikelen die gerelateerd zijn aan de
hoorcollege's als uitgangspunt dienen voor het aanleren van
onderzoeksvaardigheden en het verwerven van inzichten in het vakgebied.
● Studenten reviewen elkaars werk en krijgen op deze manier een beter inzicht in
kwaliteit van het werk.
● Tijdens workshops wordt een onderwerp kort ingeleid door een docent en wordt
het samen met de studenten (en eventuele gasten) uitgediept en besproken.
Bij de bepaling van de inhoud en de didactische vormen spelen de overwegingen een rol
die al eerder geschetst zijn in het hoofdstuk VISIE OP SOFTWARE ENGINEERING (blz.
7).
Inhoudelijke samenhang
Een globaal overzicht van het curriculum wordt gegeven in Figuur 1 (Globaal rooster).
12-FEB-07 CURRICULUM 14

Weken
0-8
Weken
9-16
Weken
17-28
Weken
29-40
Week 50
Introductiedagen
Software Evolutie
Software Architectuur
Requirements Engineering
Software Testen
Software Proces
voortgangsbesprekingen
Software Constructie
Voorbereiding Stage
Literatuurstudie Wekelijkse
Afstudeerproject
Afstuderen
Figuur 1: Globaal rooster
Maandelijkse
Voortgangsbesprekingen
De verschillende vakken sluiten sterk op elkaar aan doordat ze allen overeenkomen met
een fase binnen de diverse varianten van de Software Life Cycle 3 . Dit geeft de gelegenheid
om aangeleerde kennis terug te laten komen vanuit een ander perspectief. Dit versterkt het
leerproces. Daar waar mogelijk worden de practicum opdrachten van verschillende vakken
op elkaar afgestemd.
Een gedetailleerde beschrijving van elk van deze vakken is te vinden vanaf blz. 53.
Afstudeerproject
Gedurende de gehele opleiding is er veel aandacht voor het afstudeerproject. Tijdens het
afstuderen dient de student in korte tijd een uitdagend probleem te onderzoeken en te
komen tot een oplossing. In feite dient de student hier tot een synthese te komen van al het
aangeleerde. De opgedane inzichten, vaardigheden en technieken dienen te worden
toegepast. In het afstudeerproject verdiept de student zich in een deelgebeid van de
software engineering.
Naast het opleidingsdoel fungeert het afstudeerproject ook als proeve van bekwaamheid.
Dit wordt ook als zodanig aan de studenten gepresenteerd. Het afstudeerproject draagt in
sterke mate bij aan de doelgerichtheid van de opleiding. Hier wordt aangetoond dat
studenten over het gewenste eindniveau beschikken.
Tijdens de opleiding wordt in de volgende stappen naar het afstudeerproject toegewerkt:
3 H. van Vliet, Software Engineering: Principles and Practice, Wiley, 2000 (2 nd Edition).
12-FEB-07 CURRICULUM 15
Wekelijkse Papersessies

● Ontwikkelen vakbekwaamheid door het schrijven van een aantal betogen op basis
van papers en het opzetten van een of twee onderzoekjes. Dit gebeurt tijdens de
voorafgaande vakken en het literatuuronderzoek.
● Vinden afstudeerplek met mogelijkheden voor een uitdagende opdracht.
● Voorbereiding onderzoek middels plan van aanpak en literatuurstudie.
● Stage: uitvoering van het feitelijke onderzoeksdeel van het afstudeerproject.
● Rapportage: verslaglegging van de resultaten in een afstudeerverslag.
Door de vroegtijdige aandacht voor het afstuderen, slagen de meeste studenten erin om
vóór de jaarwisseling een afstudeerplek te vinden. Door de aangeleerde vaardigheden,
gerichte voorbereiding en ondersteuning kan de student in korte tijd al zijn aandacht
richten op het feitelijke onderzoek.
Het is daarnaast belangrijk om de student een goed gevoel te geven over wat er qua niveau
van hem verwacht wordt. Dit wordt onder meer bereikt door studenten de scripties van
voorgaande jaren te laten reviewen en zo een indruk te krijgen wat goed is en wat minder
goed.
Doordat er een tweetal maanden zit tussen de literatuurstudie en de afstudeerstage, kan de
informatie bezinken en doordacht worden. Dit biedt ruimte voor creativiteit en frisheid bij
het van start gaan van de uitvoering. Ook kan de student zo beter het overzicht bewaren.
Basis van curriculum in onderzoek en praktijk
De opleiding stelt zich ten doel om een goed geïntegreerd, kwalitatief hoogwaardig,
programma aan te bieden dat een antwoord biedt op de grote uitdagingen binnen de
Software Engineering. De kwaliteit van deze opleiding wordt, zoals gebruikelijk is bij een
academische opleiding, geborgd doordat deze gebaseerd is op het onderzoek door de
betrokken opleidingsinstellingen in het algemeen en het docententeam in het bijzonder.
De opleiding is geïnitieerd vanuit de onderzoeksgroep Programmatuur bij het Informatica
Instituut van de Universiteit van Amsterdam o.l.v. Prof.dr. J.A. Bergstra en de
onderzoeksgroep Interactive Software Engineering and Renovation van het Centrum voor
Wiskunde en Informatica o.l.v. Prof.dr. P. Klint. Dit onderzoek vormt de primaire basis
voor de vakken Software Evolution en Software Construction. Naast algemene kennis en
inzicht op het gebied van software engineering, is hier veel kennis aanwezig op het gebied
van testen, proces, evolutie en constructie.
Het vak Software Architectuur wordt gegeven door Prof. dr. H. van Vliet die aan de VU
verbonden is als hoogleraar software engineering en daar onderzoek verricht op het gebied
van software architectuur.
Op het gebied van Requirements Engineering en Testen is minder formele kennis vanuit
het onderzoek aanwezig bij het huidige docententeam. Gezien het belang van deze vakken
is besloten om ze op te nemen in het curriculum en de kennis op te bouwen. Hiertoe wordt
gebruik gemaakt van de standaard literatuur en wordt voor de actuele inzichten gewerkt
met papers uit de recente literatuur en is de inhoud daarnaast getoetst aan de hand van de
SWEBOK. Daarnaast is kennis uit de praktijk gebruikt bij het inrichten en geven van het
vak.
Voor het vak Software Process is gekozen om het in te laten vullen door een docent met
een sterke praktijkervaring en grote reputatie.
12-FEB-07 CURRICULUM 16

Terwijl academisch onderzoek vaak gespecialiseerd is, is Software Engineering breed en
zijn de problemen deels praktisch van aard. Er is gekozen om het docententeam deels te
laten bestaan uit mensen met een sterke
praktijkervaring. Hierdoor wordt
Selectie competenties/eindtermen
gegarandeerd dat ook de echte
praktijkproblemen aan bod komen. Om te
zorgen dat de vakken de ontwikkelingen op Inrichten didactische vormen
het vakgebied blijven volgen wordt gebruik
gemaakt van ad hoc klankbordgroepen van
externe experts. Daarnaast bestaat het
Selecteer theorie
voornemen om in 2007 een adviesraad in te
richten bestaande uit zowel experts uit het
bedrijfsleven worden gevraagd als
Selecteer praktijkcases
hoogleraren die onderzoek doen op het
betreffende vak. Deze adviesraad zal
adviseren over het curriculum als geheel.
Bepaal toetsingsvormen
Ontwikkelen vak
Voor de opleiding zijn drie vakken nieuw
ontwikkeld. Daarnaast zijn drie bestaande
vakken aangepast. Bij het ontwikkelen van de
vakken wordt gebruikgemaakt van het
ontwikkelmodel zoals is weergegeven in
Figuur 2. Er is er veel ruimte voor de
hoofddocent om dit te doen op zijn manier,
mits dit binnen het didactische model van de
opleiding past. Om de kwaliteit van de
Geef onderwijs in dit vak
Toets studenten
Evalueer en verbeter vak
Figuur 2: Ontwikkelingsmodel per vak
vakken te garanderen zijn de volgende maatregelen getroffen:
● Het samenstellen van een vak gebeurt meestal in teamverband. Naast de
hoofddocent is hier de ondersteunende docent bij betrokken en vaak nog iemand uit
de betreffende onderzoeksgroep of het docententeam van de opleiding.
● Gebruik van SWEBOK als overkoepelend instrument.
● Gebruik van standaardliteratuur.
● Regelmatige gesprekken tussen de hoofddocent en de opleidingscoördinator
● Vrijmaken van voldoende voorbereidingstijd voor docent.
● Docenten nemen kennis van wetenschappelijke publicaties, en volgen conferenties
op dit vakgebied.
● Inhoud en practicum wordt afgestemd met vakassistent.
● Vak is ingekaderd door het leermodel van de opleiding.
● Er zijn veel contacturen beschikbaar om de inhoud van het vak nader toe te spitsen
op de kunde van de studenten.
● Opleidingscoördinator is regelmatig persoonlijk aanwezig bij de wekelijkse
voortgangsbesprekingen met de studenten. Signalen worden direct besproken met
de hoofddocent. Indien nodig wordt er bijgestuurd.
Deeltijdvariant
De opleiding wordt zowel in een voltijd- als in een deeltijdvariant aangeboden. In de
deeltijdvariant wordt de opleiding in half tempo in twee jaar gedaan. Daarbij wordt als
schema aangehouden dat alleen vakken gevolgd worden op maandag en dinsdag met
uitloop naar de dinsdagavond voor papersessies en voortgangsbespreking. De
deeltijdstudenten volgen op maandag en dinsdag samen met de voltijdstudenten hetzelfde
onderwijs. Bij het afstudeerproject kunnen deeltijdstudenten kiezen om dit voltijd te doen,
12-FEB-07 CURRICULUM 17

dan wel in deeltijd. Ter verduidelijking laat Tabel 1 het schema van de deeltijdopleiding
zien.
Verbeterpunten
Voor de komende jaren hebben wij de volgende verbeterpunten geïdentificeerd:
● Gebruikmaken van klankbordgroepen om inhoud van de vakken te blijven
verbeteren.
● Instellen van een adviesraad om het hele curriculum te blijven verbeteren.
● Problemen op het gebied van configuratiemanagement terug laten komen in het
practicum.
● Voor de deeltijdvariant is constante zorg nodig om een goede aansluiting tussen de
vakken te blijven garanderen.
Tabel 1: Schema deeltijdopleiding
T2.1 Eisen WO
Het programma sluit aan bij de volgende criteria voor het programma van een WO-opleiding:
1. Kennisontwikkeling door studenten vindt plaats in interactie tussen het onderwijs en het wetenschappelijk
onderzoek binnen relevante disciplines
2. Het programma sluit aan bij ontwikkelingen in de relevante wetenschappelijke
discipline(s) door aantoonbare verbanden met actuele wetenschappelijke theorieën
3. Het programma waarborgt de ontwikkeling van vaardigheden op het gebied van wetenschappelijk
onderzoek
4. Bij daarvoor in aanmerking komende opleidingen heeft het programma aantoonbare verbanden met de
12-FEB-07 CURRICULUM 18

actuele praktijk van de relevante beroepen.
● Dit wordt gewaarborgd door het gebruik van wetenschappelijke literatuur door
studenten (in de papersessies), en het gebruik van actuele wetenschappelijke
inzichten die op jaarlijkse vakconferenties naar voren komen.
● Dit wordt gewaarborgd door SWEBOK, visie op SE, en de kennis, ervaring en
uitwisseling die docenten hebben met bedrijfsleven
● Het afstudeerproject vindt plaats in een wetenschappelijke setting als in een
bedrijfssetting.
Zie verder de hoofdstukken CURRICULUM (blz. 14) en LEERMODEL (blz. 21).
T2.2 Relatie tussen doelstellingen en inhoud programma
Het programma is een adequate concretisering van de eindkwalificaties, qua niveau, oriëntatie en
domeinspecifieke eisen.
De eindkwalificaties zijn adequaat vertaald in leerdoelen van (onderdelen
van) het programma.
De inhoud van het programma biedt studenten de mogelijkheid om de geformuleerde eindkwalificaties te
bereiken.
De eindkwalificaties zijn geconcretiseerd in het leermodel en in de vakbeschrijvingen.
Daarbij staan zowel de leerdoelen als de relatie tussen praktijk en theorie centraal.
T2.3 Samenhang programma
Studenten volgen een inhoudelijk samenhangend studieprogramma.
Zie hoofdstukken LEERMODEL (blz. 21) en CURRICULUM (blz. 14).
T2.4 Studielast
Het programma is studeerbaar doordat factoren, die betrekking hebben op dat programma en die de
studievoortgang belemmeren zoveel mogelijk worden weggenomen.
De wekelijkse voortgangsbespreking geeft direct zicht op belemmerende factoren. Daar
waar problemen in het programma worden gesignaleerd wordt hier direct naar een
oplossing gezocht, zowel voor de korte termijn als structureel. Voorbeelden hiervan zijn:
● Aanbieden Unix crash course t.b.v. Software Evolutie
● Aanpassen collegemateriaal om opdrachten t.b.v. Software Evolutie beter
uitvoerbaar te maken.
Daarnaast wordt gebruik gemaakt van de studentenevaluaties en worden vakken
geëvalueerd tussen docent en opleidingscoördinator. Hierbij ligt de focus op de vakken die
gezien de evaluaties extra aandacht nodig hebben. Zie hoofdstuk BESTURING EN
KWALITEITSVERBETERING. (blz. 33). Er is één leerroute voor deeltijders en voltijders
en één instroommoment. Dit heeft als voordeel dat
● vroegtijdige en gelijktijdige voorbereiding op het afstudeerproject mogelijk is.
● attitudes zoals werkhouding en het nauwkeurig refereren naar werk van anderen
snel gezamelijk aangeleerd worden.
Studenten geven tijdens de voortgangsbespreking aan vooral last te hebben van de
onduidelijke normering, hoge studiedruk en problemen bij het samenwerken bij de
practica. Deze problemen komen voor een deel door de aard van de opleiding.
Bij de 'softe' vakken als Software Architectuur, Requirements Engineering en Software
Process, is er voor de student veel ruimte om eigen invulling te geven aan de opdracht. De
normering ligt hier vooral op het meta niveau, zoals goede motivatie, heldere verwoording,
12-FEB-07 CURRICULUM 19

mate van probleemoplossing en complexiteit. Studenten kunnen hun eigen werk in het
begin niet goed beoordelen. Er wordt hard gewerkt maar de feedback door de begeleiders
is kritisch. Het voordeel is dat studenten zich hierdoor de gestelde norm eigen maken. Het
nadeel is dat de beloning voor het harde werken in de vorm van positieve feedback
uitblijft. Hierdoor zijn er altijd klachten over de onduidelijke normering. Dit vermindert
sterk in de loop van het studiejaar. De wekelijkse voortgangsmeeting wordt gebruikt om
stoom af te blazen. Ook wordt de feedback met de practicumgroepen nabesproken.
De studenten worden geconfronteerd met veel werk en veel toetsmomenten. Het is de
bedoeling dat ze hierdoor leren om effectieve lees en leerstrategieen te ontwikkelen. De
studiedruk is hoog en er worden hoge eisen gesteld aan het eindresultaat van de studenten.
Elke jaargang heeft dan ook last van deze hoge werkdruk. Enerzijds is dit een kwestie van
leren en aanpassen aan de kant van de student. Anderzijds probeert de opleiding de druk te
verlichten door te schuiven met de deadlines, opdrachten eventueel te verlichten of de
werkdruk te bespreken.
Studenten ervaren verder hoe lastig het is om samen te werken. Dit manifesteert zich
vooral doordat niemand in de groep aan het begin een goed idee heeft wat er moet
gebeuren en wat de beoordelingsnormen zijn. Het zoeken van een goede balans tussen
overleggen en individueel experimenteren is lastig. De neiging bestaat om een consensus
te bereiken en alles direct te willen overzien. Door de aard van de opdrachten is dit echter
niet mogelijk. Vanuit de opleiding worden hier tips aangeboden. Ook worden
studiegroepen zo samengesteld dat er goed samengewerkt kan worden.
12-FEB-07 CURRICULUM 20

LEERMODEL
Een student kan veel leren in één jaar. Hiervoor is het niet alleen belangrijk om kennis aan
te bieden, maar ook om de student zo effectief mogelijk te laten studeren. Om dit te
bereiken dient de student over de juiste studiehouding te beschikken en wordt er gericht
gewerkt aan het verbeteren van de leervaardigheden. De leeromgeving van de student is
hierop ingericht.
De opleiding hanteert hiervoor het leermodel dat in Figuur 3 (Leermodel voor de
opleiding) is weergegeven. Het bestaat uit een fase waarin gewerkt wordt aan de juiste
studiehouding, een fase waarin basisvaardigheden worden aangeleerd, een
automatiseringsfase waarin deze basisvaardigheden herhaald en geconsolideerd worden, en
tenslotte een fase van zelfontplooiing waarin de student de aangeleerde vaardigheden naar
eigen inzicht moet toepassen en verder moet ontwikkelen. De begeleiding per groep c.q.
individuele student start zeer intensief en neemt geleidelijk af.
Vaardigheden die worden aangeleerd zijn
onder meer:
● Vinden van relevante informatie.
● Wetenschappelijke publicaties lezen
en beoordelen.
● Analyseren, argumenteren.
● Abstraheren en specificeren.
● Helder schriftelijk communiceren.
● Reviewen van teksten.
● Samenwerken.
● Onderzoeken.
Een student kan zich vaardigheden alleen
eigen maken door daar zelf actief mee aan de
slag te gaan. Dit vindt deels plaats in
teamverband, deels moet er individueel
worden gewerkt. Vanuit de opleiding wordt
ervoor gezorgd dat de student elke week
voldoende tijd besteedt aan deze
vaardigheden en daarvoor geschikte
opdrachten en begeleiding krijgt.
Leeromgeving
Attitude
Basisvaardigheden
Automatiseren
Zelfontplooiing
Figuur 3: Leermodel voor de opleiding
De vaardigheden worden aangeleerd tijdens de practicumopdrachten en tijdens de
papersessies. Bij de papersessies wordt gewerkt in iteraties van vier weken. In elke iteratie
moet een mini (literatuur) onderzoek worden uitgevoerd en een betoog / verslag worden
geschreven. Door te werken in kortlopende iteraties is er veel herhaling en kan de student
telkens fris opnieuw beginnen. De student kan het geleerde zo direct in de praktijk
brengen. Door de herhaling krijgt de student routine. Door feedback kan de student zich
verbeteren.
De opleiding doet een grote investering om de vele eindproducten en tussenproducten van
de studenten allen inhoudelijk te behoordelen. Doordat er veel ruimte is voor individuele
feedback en studenten in toenemende mate individueel werken, kunnen studenten met
uiteenlopende competenties op maat begeleid worden. Zo heeft de student zelf veel
invloed op de keuze van zijn onderwerp voor papersessies en is er bij practicumopdrachten
ruime vrijheid om zelf invulling daaraan te geven..
12-FEB-07 LEERMODEL 21

In de laatste fase werkt de student vooral individueel, bepaalt hij/zij zelf de structuur en
zorgt de opleiding voor feedback op ingeleverde documenten. Gezien de beperkte tijd
wordt strikt de hand gehouden aan deadlines. De mijlpalen zijn echter niet meer wekelijks
maar tweewekelijks/maandelijks.
De fasen uit het leermodel zullen nu in meer detail worden besproken.
Attitudevorming
Voor elke student wordt een attitude nagestreefd die als volgt te karakteriseren is:
● Gemotiveerd en gedreven, wil uit zichzelf het maximum halen dat erin zit.
● Neemt zelf initiatief en lift niet mee met anderen.
● Maakt gemotiveerde keuzes.
● Durft fouten te maken en leert daarvan.
● Is creatief in het vinden van oplossingen.
● Gruwt van plagiaat.
Als groepsattitude wordt gestreefd naar:
● Goede onderlinge samenwerking.
● Gericht op kwaliteit en prestatie.
Een ander doel in deze fase is om de studenten die niet over het juiste profiel beschikken
uit te laten stromen op een zo vroeg mogelijk moment. Dit is van belang voor de student
zelf, maar ook voor de groep is het van belang dat er geen studenten zijn die verstorend
werken tijdens practicumopdrachten.
Vooral in het begin van de opleiding wordt veel aandacht besteed aan het vormen van de
juiste attitude. Hiermee wordt gestart op de eerste dag van de introductie en het is al
mogelijk om binnen een viertal weken deze cultuur te laten ontstaan. Op het moment dat
deze gemeengoed is geworden, is er minder begeleiding nodig.
Dit wordt bereikt door:
● Verwachtingen duidelijk en herhaaldelijk uit te spreken.
● Positief gedrag expliciet (meestal persoonlijk, soms openlijk) te waarderen en te
bevestigen.
● De student gevoel voor kwaliteit bij te brengen door gerichte feedback en
inhoudelijke beoordelingen. Goede cijfers moeten verdiend worden en daarmee
waarde krijgen voor de student. Hiertoe wordt een beoordeling uitvoerig toegelicht.
Er worden onvoldoendes uitgedeeld als werk van onvoldoende niveau is.
● Tijdens de eerste weken scherp te controleren op ongewenst gedrag. Bijvoorbeeld
door aanwezigheidslijsten, aandacht besteden aan de samenwerking, aanwezigheid
bij practica van begeleiding, etc. Studenten worden hier direct (telefonisch of
persoonlijk) op aangesproken.
● Snel alle studenten te leren kennen en inzicht te krijgen in hoe ieder een
functioneert. Hierdoor kunnen studenten waardering krijgen voor goed werk en
wordt voorkomen dat een student in anonimiteit met minimale inspanning het jaar
probeert door te komen.
● Studenten laten voelen en realiseren dat ze nog veel te leren hebben. Dit is voor de
opleiding een hele opgave, want een groot aantal studenten heeft de afgelopen jaren
met beperkte inspanning alleen maar zeer hoge cijfers gehaald en is niet meer
gewend om op de tenen te lopen.
● Wekelijkse voortgangsbesprekingen waarin elke week in kleine groepen de
voortgang van de groep en van individuele studenten wordt besproken. Dit is voor
12-FEB-07 LEERMODEL 22

de opleiding bovendien een belangrijk instrument voor kwaliteitsbewaking (zie
hoofdstuk BESTURING EN KWALITEITSVERBETERING, blz. 33).
Tijdens de eerste fase van de studie is het belangrijk om bovenstaande maatregelen goed te
balanceren. Het is een vrij schoolse aanpak, m.a.w. er zijn zeer duidelijke kaders
waarbinnen de student dient te studeren. De sturing, werkdruk en de eerste onvoldoendes
kunnen hard aankomen. De studenten moeten voelen dat ze ook echt beter zullen worden
van deze opleiding, dat ze er trots op zullen zijn als ze eenmaal Master zijn. De keuze voor
een éénjarige Master brengt ook de noodzaak met zich mee om deze vaardigheden snel te
verwerven om het studieprogramma in één jaar te kunnen doorlopen.
Basisvaardigheden
In het begin krijgt de student voor het eerst door waar hij/zij staat. Voor het eerst in jaren
vallen er onvoldoendes. Hard werken is niet voldoende, er moet ook en vooral slim
gewerkt worden. Vanuit de opleiding wordt in deze fase veel aandacht besteed aan het
aanleren van de vaardigheden die nodig zijn om tot goede resultaten te komen en die nodig
zijn om zelfstandig een onderzoek uit te voeren. Hier wordt de basis gelegd voor de
competenties die de student aan het einde van de opleiding dient te beheersen.
Vaardigheidsdoelen:
● Keuzes kunnen maken: geen volledigheid maar focus, diepgang en kwaliteit.
● Wetenschappelijke artikelen kunnen lezen en eigen maken.
● Betoog kunnen opbouwen.
● Besef van analyse.
● Kunnen opstellen van een bibliografie.
Kennisdoelen:
● Student neemt kennis van het bestaan van academische publicaties en kan ze
categoriseren.
● Student krijgt op deze manier kennis van het vak buiten de reguliere colleges
(verbreding gezichtsveld). Elke vier weken komen circa 3 tot 9 papers met
verschillende onderwerpen aan bod.
● Student integreert de in colleges aangeboden kennis en verdiept deze door
toepassing tijdens practicum.
Middelen:
● Wetenschappelijke publicaties.
● De student krijgt open, uitdagende practicumopdrachten waar meerdere
oplossingsrichtingen mogelijk zijn. De student dient zelf een keuze te maken en
deze te verantwoorden. Van tevoren is niet duidelijk wat goed is en wat fout is.
● Terugkoppeling in kleine groepjes in wekelijkse sessies onder begeleiding in
workshopachtige vorm.
● Papersessies zijn eerst gericht op doen en leren, pas in een latere fase op presteren.
● Aanbieden van handvatten, oefenstof, vraagbaak en duidelijke structuur.
● Persoonlijk (mondeling) commentaar van de docent.
Handvatten:
● Hoe lees ik een paper?
● Hoe schrijf ik een paper?
● Hoe formuleer ik een onderzoeksvraag?
● Hoe structureer ik een betoog?
● Hoe beoordeel ik theorieën/ situaties?
12-FEB-07 LEERMODEL 23

● Hoe vind ik informatie?
● Hoe review ik een paper?
Automatiseren
De nieuwe vaardigheidseisen zijn vooral een logische uitbreiding op het eerder
aangeleerde. De moeilijkheidsgraad van het aanleren van deze vaardigheden is veel lager
dan tijdens de vorige fase. De student moet nu vooral meer handigheid en routine krijgen.
Dit moet terug komen in de kwaliteit van de resultaten en in de vaardigheid om goede
keuzes te maken. Met de aangeleerde basisvaardigheden is de student in staat om tot meer
diepgang te komen en significant meer kennis te verwerven. De hoeveelheid werk gemeten
in te lezen pagina’s neemt toe, maar de student dient dit in dezelfde of minder tijd aan te
kunnen.
Vaardigheidsdoelen:
● Zelfstandig onderzoek uitvoeren.
● Relevante artikelen kunnen vinden.
● In korte tijd veel bronnen kunnen doorlezen en beoordelen op toepasbaarheid.
● Goede analyses kunnen maken.
● Elkaar kunnen reviewen.
● Goed kunnen schrijven.
Kennisdoelen:
● Student krijgt diepgaande kennis van de state-of-the-art op een bepaald
onderzoeksgebied.
● Student ontwikkelt intuïtie voor de (verwachte) kwaliteit van zijn geschreven en
gepresenteerde werk.
Middelen:
● Herhaling van de middelen uit de vorige fase.
● Meer tijd voor individueel werk.
● Feedback van de docent.
Zelfontplooiing
De student is nu in staat om zelfstandig een onderzoek uit te voeren op behoorlijk niveau.
De student is vrij om dit in te richten. Alleen de tijdlijn en resultaatcriteria zijn gegeven.
De student legt verantwoording af over de planning, opzet en voortgang van het
onderzoek. De begeleiding is coachend van aard. De workshops zijn minder gericht op
gestructureerde begeleiding, maar richten zich op nieuwe interessante zaken die de student
eventueel kan gebruiken in zijn eigen werk. De student is nu in staat om in korte tijd
diepgaande kennis en inzichten te verwerven.
Tijdens de laatste weken van het laatste blok en tijdens het afstuderen krijgt de student
kans om zich te ontplooien door een onderwerp naar eigen keuze uit te diepen. Het
geleerde (informatie zoeken, beoordelen, analyseren, betoog schrijven, experimenteren) in
de praktijk te brengen en hier verdere stappen in te zetten. De tijd is ruim in vergelijking
met de druk in het eerste deel van de opleiding en de student kan zich volledig richten op
het afstuderen. Er is geen afleiding door andere vakken en van andere studenten.
Eens per maand is er een feedback moment om vinger aan de pols te houden. Daarnaast is
de begeleiding situationeel. Als de persoon of opdracht er om vraagt kan er meer
ondersteuning worden geboden. De student zal echter zelf moeten aantonen over de
vaardigheden te beschikken om de scriptie met goed gevolg af te leggen.
12-FEB-07 LEERMODEL 24

Vaardigheidsdoelen:
● Zelfstandig kunnen uitvoeren van een complex Software Engineering onderzoek.
● Rapporteren (schriftelijk en mondeling) over plannen en behaalde resultaten.
● De belangrijkste gerelateerde wetenschappelijke literatuur kunnen vinden.
● Uitdagende onderzoeksvraag kunnen formuleren.
● Goede review uit kunnen voeren.
● Scherpe analyses.
● Structuur kunnen aanbrengen.
● Reflectie op eigen werk.
Kennisdoelen:
● Diepgaande geïntegreerde kennis op bepaald deelgebied van het vakgebied.
Middelen:
● Vierwekelijkse workshop.
● Afstudeerplan volgens vastgelegd sjabloon.
● Literatuurstudie die ten dienste staat van het afstuderen.
● Afstudeerverslag volgens vastgelegd sjabloon.
● Situationele begeleiding door afstudeerorganisatie/docenten opleiding.
Leeromgeving
Het is essentieel om de student een stimulerende omgeving aan te bieden. Hierbij gaat het
niet alleen om faciliteiten maar ook om aandacht, betrokkenheid, waardering, reageren op
signalen van de student, het aangaan van gesprekken en de nabijheid van docenten. Dit
wordt als volgt bereikt:
● Uniforme structuur en opzet in alle vakken.
● Werk wordt zo min mogelijk gefragmenteerd uitgevoerd. Hiertoe is gekozen om de
maandag en dinsdag voor het ene vak te reserveren, en de woensdag en donderdag
voor het tweede vak. Een student werkt aan twee vakken per blok. Een blok duurt
acht weken. Elk blok heeft een “hard” (= meer technisch) vak en een “soft” vak.
● De vrijdag wordt gebruikt voor de voortgangsbespreking, papersessies, en het
halen van de deadlines. Daarnaast wordt in de eerste vier weken van een blok
gewerkt aan papers voor het ene vak, de laatste vier weken voor het tweede vak.
● Voor alle uren waarin geen college is, zijn practicumzalen met voldoende
werkplekken gereserveerd om de praktijkopdrachten uit te voeren.
● Er is centrale begeleiding gedurende hele jaar voor alle vakken.
● Aan de vaardigheden wordt wekelijks aandacht besteed in de vorm van intensieve
en kwalitatief hoogwaardige begeleiding bij de practica en in de vorm van
papersessies op de vrijdag.
● Veel aandacht wordt besteed aan roostering en het tijdig regelen van zalen.
● Blackboard wordt bij alle vakken intensief gebruikt als digitale informatie bank
voor de student, hierop komen ook alle memo’s (zie ook blz. 80).
● Contacturen bij practica.
● Contacturen/aanwezigheid docent bij sociale evenementen.
12-FEB-07 25

INSTROOM
Instroomprofiel
Er zijn twee instroomprofielen te onderscheiden voor deze opleiding: WO bachelors en
HBO bachelors die als gemeenschappelijk kenmerk hebben dat ze:
● Gemotiveerd zijn en graag willen leren.
● Grote inzet hebben.
● Grosso modo de capaciteit hebben om de opleiding te voltooien.
● Software van enige omvang hebben ontwikkeld.
● Kennis hebben van basistechnieken en -methoden.
Capabilities
Handicaps
Motivators
Demotivators
Profiel WO Bachelors Profiel HBO Bachelors
Goede basiskennis
Analytische vaardigheden
Motivatie
Onvoldoende praktische
vaardigheden
Onvoldoende oplossingsgericht
denken
Redelijke basiskennis
Kan projectmatig werken
Praktische vaardigheden
Motivatie
Kan niet goed projectmatig werken Is al lang niet meer uitgedaagd
Onvoldoende taalvaardigheid
Beter worden/leren
Master in 1 jaar
Betere kansen op de arbeidsmarkt
(banen en beloning)
Matige analytische vaardigheden
Onvoldoende taalvaardigheid
Denkt in absolute termen i.p.v. het
afwegen van alternatieven met
sterktes en zwaktes
Beter willen worden/leren
Master in 1 jaar
Betere kansen op de arbeidsmarkt
(banen en beloning)
Onvoldoende theoretische analyses Stof is niet nuttig/toepasbaar
Stof is te toepassingsgericht
Werken in groepen
Onvoldoende beloond voor hard
werken
Onvoldoendes
Schoolse aanpak
Opdrachten zijn niet concreet genoeg
Werken in groepen
Onvoldoende beloond voor hard
werken
Onvoldoendes
Academisch aanpak
De opleiding als geheel moet een goede balans zien te vinden tussen beide, deels
conflicterende, profielen. Dit wordt bereikt door aan specifieke ongunstige factoren
aandacht te besteden en gunstige factoren te versterken voor beide groepen. Bij opdrachten
en samenstelling van de lesstof worden de kenmerken van beide groepen meegenomen.
Opdrachten hebben daartoe zowel een theoretische als concrete element. Er wordt zowel in
groepen als individueel gewerkt. Er wordt per student feedback gegeven. Studenten die
zich niet lekker voelen worden snel herkend en krijgen speciale aandacht. Hier wordt door
de opleiding per jaargang specifiek op gereageerd. Verder zorgt een goede selectie (zie de
12-FEB-07 INSTROOM 26

sectie Selectie, hieronder) voor een instroom die de kansen op een goede uitstroom
maximaliseert.
Uit de cijfers in de appendix Kwantitatieve gegevens Master Software Engineering op
pagina 44 blijkt dat vooral HBO Bachelors de weg naar de opleiding weten te vinden. Dit
kan voor een deel verklaard worden uit het feit dat er nog weinig WO bachelors zijn. De
komende jaren zal extra aandacht worden besteed aan het werven van studenten met een
WO Bachelor als achtergrond. Dit zal gedaan worden door bij de voorlichting speciale
aandacht aan deze groep te besteden en duidelijk te maken dat deze mastersopleiding voor
hen een interessant perspectief biedt.
Uit de analyse van de instroom van de eerste jaren kan geconcludeerd worden dat HBO
bachelors kunnen instromen mits ze
● Een voldoende achtergrond in programmeren hebben.
● Zeer gemotiveerd zijn.
● Voldoende taalvaardig zijn.
● Een goede cijferlijst hebben.
Ook blijkt dat studenten met een achtergrond in Kunstmatige Intelligentie prima kunnen
meedoen aan de opleiding.
Werving
Werving heeft als doel om de instroom van voldoende gekwalificeerde en gemotiveerde
studenten voor de opleiding te garanderen. Hierbij is het van groot belang om ervoor te
zorgen dat de verwachtingen van de student en de feitelijke inhoud van de opleiding goed
met elkaar overeenkomen.
De doelgroepen voor de werving zijn:
● WO Bachelor informatica/informatiekunde.
● HBO Bachelor Informatica.
● Reeds werkzame Software Engineers die zich willen bijscholen.
De werving bestaat uit de volgende onderdelen. Een uitvoerige informatiebrochure geeft
aan waarom de student de opleiding moet kiezen en wat hij kan verwachten.
Vertegenwoordiging en presentaties bij cruciale informatiemarkten en
voorlichtingsbijeenkomsten hebben tot doel om actief nieuwe studenten te bereiken. Een
website geeft de informatie over de opleiding en bevat o.a. verhalen van afgestudeerde
studenten, lijsten van afstudeerstages en stagebedrijven. Tenslotte blijkt mond-tot-mond
reclame door tevreden alumni wel een van de meest effectieve wervingsmechanismen.
Verbeterpunten voor de komende jaren:
● Verbeteren en uitbouwen van de eigen website.
● Systematische en goede vermeldingen op relevante opleidingswebsites.
● Nadrukkelijker werving van WO bachelor studenten van universiteiten in het hele
land.
● Betere presentie bij bama markten.
● Systematisch meten van het effect van de verschillende wervingsinstrumenten.
● Een wervingsplan met explicietere doelstellingen en planning.
● Contact met externe docenten van bachelorsopleidingen.
Selectie
Voor toelating tot de opleiding komen in principe in aanmerking:
12-FEB-07 INSTROOM 27

● Iedere bachelor Informatica of Technische Informatica van een Nederlands
universiteit.
● Eenieder die een buitenlandse kwalificatie heeft die vergelijkbaar is met hier
bovengenoemde eis. Met als voorwaarde dat het Nederlands en het Engels actief en
passief voldoende worden beheerst. De beoordeling van een buitenlands diploma
vindt plaats op basis van criteria en procedures van het Nuffic.
● Iedere HBO bachelor Informatica, Technische Informatica, Information
Engineering, of Elektrotechniek met afstudeerrichting Computerkunde, met
eindcijfer gemiddeld 7 of hoger die een pakket heeft gevolgd dat de volgende of
hiermee vergelijkbare vakken omvat: (a) Algoritmen en datastructuren, (b)
Systeemarchitectuur, (c) Besturingssystemen, (d) Programmeertalen, (e) Software
Engineering.
● Eenieder die (een substantieel deel van) een gerelateerde opleiding succesvol heeft
afgerond en die tijdens een assessment procedure aantoont over voldoende
kwaliteit, motivatie en voorkennis te beschikken om de opleiding succesvol af te
kunnen ronden.
Elke aanvraag tot toelating wordt getoetst door de Toelatingscommissie. Zonder
toestemming van de Toelatingscommissie heeft een kandidaat geen toegang tot de
opleiding.
Op basis van CV, cijferlijst en motiveringsbrief wordt een eerste selectie van kandidaten
gemaakt. Hierbij wordt gelet op de volgende punten:
● Cijfers voor vakken die relevante voorkennis bevatten.
● Kwaliteit van de motiveringsbrief (taalkundig, motivering).
● Ervaring met realistische softwareprojecten zoals blijkt uit cijferlijst en CV.
In sommige gevallen is op basis hiervan al een selectie te maken. In andere gevallen vindt
er een gesprek met de kandidaat plaats waarin de volgende punten aan de orde komen:
● Vaststellen van voorkennis aan de hand van een checklist.
● Vaststellen van programmeerervaring door inleveren van programmeeropdracht of
review van eerder uitgevoerd project.
● Vaststellen motivatie.
Tenslotte wordt de toelating van de geselecteerde kandidaten nog eens door de voorzitter
van de examencommisssie formeel bekrachtigd.
Verbeterpunten voor de komende jaren:
● Introduceren van een online test waarmee studenten zelf hun profiel kunnen
toetsen.
● Invoeren van een expliciete, schriftelijke, toets om voorkennis en competenties te
meten.
● Beter gebruik maken van profielen van succesvolle en minder succesvolle
studenten uit de afgelopen jaren.
● Beter meten van de correlatie tussen eindresultaten van afgestuurde studenten en
hun performance tijdens de selectie.
Schakelprogramma
Er bestaat op dit moment geen formeel schakelprogramma. Er bestaan plannen om in de
nabije toekomst een schakelprogramma aan te gaan bieden om deficiënties in de
vooropleidingen aan te vullen, maar zover is het nog niet. Studenten worden tijdens de
selectie alleen aangenomen als redelijkerwijze verwacht kan worden dat ze de opleiding
met succes kunnen voltooien.
12-FEB-07 INSTROOM 28

Hier volgt een beknopte samenvatting van de achtergrondkennis die voor de opleiding
wordt verondersteld, met literatuurverwijzingen.
Basis discrete wiskunde: Kennis van verzamelingen, relaties, eenvoudige combinatoriek. 4
Basis logica: Kennis van propositie- en predikatenlogica 5 .
Basis formele taaltheorie:
Reguliere talen, eindige automaten, contextvrije regelsystemen, ontleden, ontledergeneratie.
6
Basis datastructuren en algoritmiek: Elementair begrip van arrays, gelinkte lijsten, dubbel
gelinkte lijsten, stapels, wachtrijen, bomen, enzovoort, en van bewerkingen daarop. 7 Zie bij
voorbeeld ook www.informatics.susx.ac.uk/courses/dats/dats.html voor een behandeling
van datastructuren en algoritmen in Java. De student wordt ook geacht iets te weten van
8 9
(eenvoudige) complexiteitsanalyse van algoritmen.
Compilerbouw: Scannen, bouwen van ontleedbomen, type checking, code generatie. 10
Inleiding software engineering: Basiskennis over architectuur, programmeerstijlen,
11 12
ontwerp aan de hand van een pakket van eisen, enzovoort.
Ontwerp patronen: “Design patterns” geven een matrijs voor de standaard code in een
object ge-oriënteerd programma, ten behoeve van hergebruik en code-generatie. 13
Modelleren: Basiskennis modelleren met gebruikmaking van een of andere
modelleeromgeving, bij voorbeeld UML (Unified Modelling Language). 14
Een indicatie van de programmeervaardigheden die verondersteld worden:
● Java: Programma's geschreven hebben van (zeg) minstens 3000 regels.
● C: Programma's geschreven hebben van (zeg) minstens 1000 regels
● Unix/Linux: Ervaring hebben met de Unix/Linux shell, met het installeren van
software pakketten, en met software engineering tools zoals make, CVS en
configure. 15
4 E.M. de Vrie, R.J. Berends, et. al. Discrete Wiskunde, Academic Service, 1999.
5 J. van Eijck en E. Thijsse, Logica voor alfa's en informatici, Academic Service, 1989, te downloaden via
www.cwi.nl/~jve/lai/.
6 A. Aho, R. Sethi, J. Ullman, Compilers: Principles, Techniques and Tools, Adfdison Wesley, 1988
(eerste vier hoofdstukken).
7 R. Lafore, Data Structures and Algorithms in Java (2 nd Edition), Sams, 2002.
8 M.T. Goodrich, R. Tamassia, Datastructures and Algorithms in Java, Wiley, 2004 (third edition).
9 G.J.E. Rawlins, Compared to What? -- An Introduction to the Analysis of Algorithms. W.H. Freeman,
1992.
10 A. Aho, R. Sethi, J. Ullman, Compilers: Principles, Techniques and Tools, Adfdison Wesley, 1988
(hoofdstukken vijf tot en met negen).
11 H. van Vliet, Software Engineering: Principles and Practice, Wiley, 2000 (2 nd Edition).
12 I. Sommerville, Software Engineering, Addison-Wesley, 2004 (7 th Edition).
13 E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented
Software, Addison-Wesley Professional, 1995.
14 www.uml.org
15 S. Figgins, J.P. Hekman, E. Siever, S. Spainhour, Linux in a Nutshell, O'reilly, 2000.
12-FEB-07 INSTROOM 29

● Ontwikkelervaring: Ervaring hebben met het ontwikkelen van software in een
professionele omgeving (IDE, Integrated Development Environment) is wenselijk,
bij voorbeeld met Eclipse 16 of Jbuilder. 17
Deze indicatie is alleen globaal. Wie ervaring heeft met andere programmeertalen
en -omgevingen komt zeker ook in aanmerking.
Vaardigheden waarop een sterk beroep wordt gedaan tijdens de opleiding zijn:
● Schrijven: Het vermogen om heldere, goed gestructureerde teksten te schrijven in
het Nederlands en (in mindere mate) in het Engels. 18
● Presenteren: Het vermogen om een onderwerp over het voetlicht te brengen voor
een groep.
● Samenwerken: Het vermogen om constructief in een team te werken aan specifieke
opdrachten.
T2.5 Instroom
Het programma sluit qua vorm en inhoud aan bij de kwalificaties van de instromende studenten:
• bachelor: VWO, HBO-propedeuse of daarmee vergelijkbare kwalificaties, blijkend uit toelatingsonderzoek
• master: bachelor en eventueel (inhoudelijke) selectie
tabellen:
• instroom
• studentenaantallen.
Zie Appendix Kwantitatieve gegevens Master Software Engineering op blz. 44.
T2.6 Duur
De opleiding voldoet aan formele eisen m.b.t. de omvang van het curriculum:
1. bachelor: in de regel 180 studiepunten
2. master: minimaal 60 studiepunten, afhankelijk van de opleiding
De opleiding is in totaal 60 ECTS verdeeld over de volgende leereenheden:
Software Architectuur 6
Software Evolutie 6
Software Testen 6
Requirements Engineering 6
Software Process 6
Software Constructie 6
Voorbereiding Masterproject 2
Literatuurstudie 4
Masterproject SE 18
Totaal 60
Een ECTS staat voor tussen de 24 en 30 werkuren. Voor de opleiding komt dit neer op een
weekbelasting van tussen de 36 en 45 uur. Dit blijkt ook redelijk overeen te komen met de
daadwerkelijke studiebelasting. Goede studenten kunnen het met 36 uur af, maar weken
waarin meer dan 40 uur wordt gewerkt zijn geen uitzondering.
16 www.eclipse.org
17 www.borland.com.jbuilder
18 L. Koenen, R. Smits, Handboek Nederlands, Erven J. Bijleveld, 2004.
12-FEB-07 INSTROOM 30

Voor studenten die meer moeite hebben met het verwerven van de juiste vaardigheden zit
extra ruimte ingebouwd in het jaar om deze vaardigheden te verwerven. Zo is er voorzien
in de mogelijkheid tot uitloop van het afstudeerproject. Grootste risico op uitloop is het
niet tijdig vinden van een afstudeerplaats. Hier wordt dan ook veel aandacht aan besteed.
Mocht er toch vertraging zijn, dan is hier uitloop voor mogelijk. Ook zijn er twee weken
kerstvakantie waar eventueel gestudeerd kan worden voor tentamens die herkanst moeten
worden.
Verhouding zelfstudie / contacturen
In het begin van de opleiding zijn er relatief veel contacturen. De uren zelfstudie zijn voor
het lezen van boeken en papers. Gedurende het eerste blok is er per week circa 10 uur
zelfstudie. Dit neemt toe in de loop van het jaar. Het tweede blok is er circa 14 uur per
week ruimte voor zelfstudie. De blokken daarna is er circa 20 uur per week ruimte voor
zelfstudie. Dit wordt besteed aan de literatuurstudie, bestuderen literatuur, het
masterproject en de voorbereiding daarvan.
De tentamenweken zijn grotendeels vrij voor zelfstudie, deze tentamenweken zitten aan
het einde van blok 1 en blok 2. Elk blok duurt 8 weken.
Evaluatie studiebelasting
Tijdens de studentenevaluatie en tijdens de wekelijkse voortgangbespreking is de
studiebelasting een belangrijk agendapunt.
T2.7 Afstemming tussen vormgeving en inhoud
• Het didactisch concept is in lijn met de doelstellingen
• De werkvormen sluiten aan bij het didactisch concept
Dit wordt beschreven in de hoofdstukken LEERMODEL (blz. 21) en CURRICULUM
(blz. 14).
T2.8 Beoordeling en toetsing
Door de beoordelingen, toetsingen en examens wordt adequaat getoetst of de studenten de
leerdoelen van (onderdelen van) het programma hebben gerealiseerd
Zie hoofdstukken CURRICULUM, BESTURING EN KWALITEITSVERBETERING,
(blz. 14 ) en de vakbeschrijvingen in Appendix Overzicht Vakken op blz. 53.
Toetsing van de vaardigheden vindt plaats deels middels het practicum, deels door middel
van tentamens en bij de vakken later in het jaar wordt het betoog van de student in het
cijfer meegenomen. Er wordt getoetst op inzicht, kennis en vaardigheden. Ook wordt
ervoor gezorgd dat bij elk vak een belangrijk deel van het cijfer bestaat uit beoordeling van
individueel werk.
Toetsen dienen te voldoen aan de volgende richtlijnen:
● Voldoende niveau.
● Goede mix tussen eenvoudige, standaard en lastige vragen.
● Kennisvragen zijn representatief voor de opgegeven stof.
● Afgestemd op leerdoelen.
● Haalbaar qua tijd.
● Geen ambiguïteit.
Elke toets wordt vooraf bekeken door minimaal een andere docent. Over het algemeen
worden toetsen vaker bekeken. De toetsresultaten van de studenten kunnen aanleiding zijn
12-FEB-07 INSTROOM 31

tot het bijstellen van een toets, dan wel tot het bijstellen van het programma. Voor het
bijstellen van de toets gaat het om zaken als:
● Is een vraag goed begrepen?
● Geven de gegeven antwoorden goed zicht op het inzicht, en kennis van de student,
m.a.w. zijn de leerdoelen gerealiseerd?
Voor de practica gelden de volgende richtlijnen:
● Goede relatie met college en theorie.
● Afgestemd op leerdoelen (vaardigheid en inzicht).
● Haalbaar qua tijd.
● Uitdagend, in de zin dat student veel moet doen om tot een goede oplossing te
komen.
● Biedt mogelijkheid tot reflectie en inzicht in stof.
Elk practicum wordt vooraf opgesteld in samenwerking met minimaal één andere docent.
Resultaten in practica kunnen aanleiding zijn tot feedback sessies (individueel dan wel
gericht op de groep). Dit is het geval als:
● Studenten niet goed het belang van het practicum snappen.
● Er veel zaken standaard fout gaan.
Op basis van de voortgang van het practicum kan eventueel de practicumopdracht dan
wel de colleges of andere ondersteunende materialen worden aangepast.
Voldoende mogelijkheden tot deelname
Voor elk tentamen zijn er maximaal twee herkansingen. Hiervoor zijn er vaste
tentamenperiodes vanuit de UvA. Echter de kleinschaligheid van de opleiding maakt het
mogelijk om hier flexibeler mee om te gaan. De datum van herkansingen wordt als het
even kan afgestemd op de wensen van de betreffende studenten.
De beoordeling van toetsingen zijn onder meer geborgd doordat studenten hun resultaten
en de beoordeling kunnen inzien.
12-FEB-07 32

BESTURING EN KWALITEITSVERBETERING
Het globale model van de opleiding is weergegeven in Figuur 4 (Opleidingsmodel). De
opleiding wordt bestuurd door een klein team van coördinatoren onder leiding van de
opleidingsdirecteur. Dit team heeft uitgebreide ervaring met zowel wetenschappelijke als
praktische aspecten van Software Engineering. De coördinatoren zijn intensief betrokken
bij het geven van de opleiding. Dit team verzorgt de begeleiding bij de practica, en de
papersessies en verzorgt de vakken gerelateerd aan het afstuderen. Daarnaast worden
enkele vakken (deels) door de coördinatoren gegeven. Hierdoor zijn de lijnen naar de
docenten en studenten kort. Er bestaat voortdurend overzicht over de huidige situatie zodat
snel gereageerd kan worden op eventuele problemen.
De volgende maatregelen zijn genomen om de kwaliteit van specifieke aspecten van de
opleiding te bewaken.
Werving
Wekelijkse voortgangsbespreking
De wekelijks voortgang van zowel de
studenten als de opleiding als geheel wordt
wekelijks gevolgd in een
voortgangsbespreking in kleine groepen
onder leiding van de coördinatoren. Dit kan
Selectie
leiden tot maatregelen om faciliteiten te
verbeteren of aan te passen, vakken bij te
sturen, of individuele studenten aan te
spreken. Het is ook een mechanisme om
overbelasting of uitval van studenten te
Attitudevorming
signaleren en in te grijpen als
(practicum)groepen niet functioneren. Ook
is het een mechanisme om gewenste
attitude en uitgangspunten van de opleiding
zonodig wekelijks over het voetlicht te
brengen. Tenslotte, wordt de
Kennis
Vaardigheden
voortgangsbespreking gebruikt om het
tijdig zoeken naar stageopdrachten te
stimuleren. Zonder overdrijven kan gesteld
Plan van aanpak
worden dat de wekelijks
voortgangsbespreking is uitgegroeid tot de
primaire maatregel om de kwaliteit van de
opleiding te bewaken.
Literatuurstudie
Afstudeerproject
Kleine omgeving
In deze kleine omgeving is er een sterke
uitwisseling tussen de verschillende
docenten, coördinatoren en studenten. Er
wordt veelvuldig en scherp geëvalueerd.
Keuze
Stageopdracht
Figuur 4: Opleidingsmodel
Een van de sterkste punten is de ervaring, betrokkenheid en kwaliteitsbewustheid van het
docententeam. Daarnaast is er ruimte om nieuwe didactische vormen uit te proberen.
Vierjarige kwaliteitscyclus
De opleiding is net van start gegaan. Het docententeam is nog vers en bruist van de nieuwe
ideeën. Er is veel contact met de studenten en dit geeft nog eens een extra impuls.
Ongetwijfeld zal dit na enige tijd stabiliseren. Het is dan ook zaak om op een
gestructureerde manier te zorgen voor prikkelende feedback, nieuwe ideeën en continue
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 33
K
w
a
l
i
t
e
i
t
s
b
e
w
a
k
i
n
g

kwaliteitsverbetering. Een voorstel dat nog zal worden uitgewerkt is om een vierjarige
evaluatie te doen die bestaat uit de volgende elementen:
● Houden van een zelfevaluatie.
● Benchmark met andere opleiding.
● Assessment met adviesraden en alumni.
● Onderzoek door buitenstaander naar de kwaliteit van de scripties.
● Audit van onderwijsdeskundige om te kijken naar mogelijke verbeteringen in het
didactisch concept.
Algemene UvA policy t.a.v. opleidingen en docententeams
Per opleiding is een team van docenten samengesteld, dat verantwoordelijk is voor de
ontwikkeling en uitvoering van het onderwijs. Bij de samenstelling van de docenten teams
is rekening gehouden met de benodigde expertise en de balans tussen de verschillende
onderzoeksvelden. Doordat het wetenschappelijk personeel (WP) een 40% : 60%
taakverdeling onderwijs : onderzoek heeft, is de koppeling van het onderwijs met
onderzoek gegarandeerd.
Hieronder wordt aangegeven hoe dit bij de Master Software Engineering is ingevuld.
Elk lid van de wetenschappelijke staf is in beginsel lid van een onderzoeksinstituut. Voor
het lidmaatschap van een onderzoeksinstituut gelden kwaliteitseisen - promotie en frequent
publiceren - die jaarlijks worden getoetst.
Vakinhoudelijke competenties
De koppeling van onderwijs en onderzoek is karakteristiek voor het wetenschappelijk
onderwijs. Dit betekent dat de verantwoordelijkheid voor het onderwijs te allen tijde ligt
bij het vaste (en dus grotendeels gepromoveerd) wetenschappelijk personeel (HL, UHD,
UD) en dat het grootste gedeelte van het onderwijs ook daadwerkelijk gegeven wordt door
het vast wetenschappelijk personeel. Alle docenten participeren actief in internationaal
wetenschappelijk onderzoek.
De vakinhoudelijke kwaliteit van de docenten blijkt uit hun actieve participatie in het
wetenschappelijk onderzoek en praktijkervaring, hierdoor kunnen zij ook gemakkelijk
voorbeelden uit de praktijk van het onderzoek in het onderwijs inweven.
De verdeling van expertise bij docenten en het gegeven dat een belangrijk deel
gepromoveerd is, dragen er aan bij dat zij in staat zijn de Dublin descriptoren, vertaald in
eindtermen van de opleiding, af te dekken. In sommige gevallen reikt de expertise van
docenten niet ver genoeg en worden voor specifieke onderwerpen specialisten ingezet.
Docententeam Master Software Engineering
De docenten worden geselecteerd op hun algemene kennis op het gebied van Software
Engineering. Er vindt een langzame roulatie in het team plaats om te komen tot een
optimale samenstelling gegeven de beschikbaarheid en expertise van docenten. Indien
nodig worden externe docenten ingehuurd voor hun specifieke expertise.
De begeleiding bij practicum werkzaamheden wordt uitgevoerd door het
coördinatorenteam. Hierdoor staat de student in direct contact met docenten waardoor de
kwaliteit van de begeleiding en feedback hoog is. De begeleiding is daarnaast niet alleen
inhoudelijk gericht maar heeft ook een belangrijke rol in de attitude en competenties van
de student. Het is van belang om dit te beleggen bij mensen met het juiste profiel.
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 34

M/ FTE
Organisatie Functie V Onderwijs Rol
Prof .dr .P.
Opleidingsdirekteur,
Klint
docent Software Evolutie
UvA/II HL M 0.20 en Software Constructie
Prof .dr .J.
Opleidingscoördinator en
van Eijck CWI HL M 0.20 docent Software Testen
Prof. dr. H.
Docent Software
van Vliet VU HL M 0.065 Architecture
Dr. P. Lago
Docent Software
VU UD V 0.065 Architecture
P. van Lith Multi
Docent Software Proces
Motions Directeur M 0.13
Dr. J. Vinju
Project-
Lid coördinatieteam
CWI leider M 0.30
Drs. H.
Lid coördinatieteam en
Dekkers
Docent Requirements
UvA/II Docent M 1.0 Engineering
Totaal 1.96
De hier genoemde docenten zijn in het studiejaar 2006-2007 bij de opleiding betrokken.
De meeste docenten (Klint, Lago, van Eijck, van Vliet, Vinju) hebben een academische
achtergrond en zijn actief in onderzoek op het gebied van Software Engineering. Daarnaast
zijn nog de volgende docenten met niet-direct wetenschappelijke kwalificaties bij de
opleiding betrokken.
Drs. Hans Dekkers heeft 13 jaar werkervaring waarvan 11 jaar in de Software Engineering,
6 jaar als (project) manager. Hij veel ervaring met people management,
verandermanagement en het inrichten van organisaties. Gedurende 1 jaar is hij als interim
manager verantwoordelijk geweest voor opleidings- en trainingsafdeling van SNT (circa
100 trainers, projectleiders en lesstofontwikkelaars). Hij heeft veel ervaring met
doelgericht leren waarbij veel sturing vanuit de leerorganisatie optreedt en allerlei
ondersteunende leervormen.
Peter van Lith heeft jarenlange bedrijfservaring op het gebied van Software Engineering
(Extreme Programming, Interaction Design, Software Renovation) en Robotica. Hij heeft
onder andere gewerkt bij Emendo (softwarerenovatie), Trilog (softwarerenovatie),
Tryllian (agents), en MultiMotions (robotica). Daarnaast heeft hij een zelfstandig
consultancybedrijf Lithp Systems.
Verder zijn in eerdere jaren bij de opleiding betrokken geweest:
M FTE
Organisatie Functie /V Onderwijs Rol
Drs. D. van den
Docent Requirements
Berg HvA Docent M 0.13 Engineering
Dr. M. van den
Docent Software
Brand
Evolutie en Software
CWI HL M 0.13 Constructie
R. Esmaili
Docent Software
HvA Docent M 0.065 Testen
Dr. T. Kuipers
Docent Software
SIG CTO M 0.13 Process
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 35

T3.1 Eisen WO
Eisen WO: het onderwijs wordt voor een belangrijk deel verzorgd door onderzoekers die een bijdrage
leveren aan de ontwikkeling van het vakgebied.
Het docenteam is hier boven besproken.
T3.2 Kwantiteit personeel
Er wordt voldoende personeel ingezet om de opleiding met de gewenste kwaliteit te verzorgen
Voor de 6 vakken gaan we uit van de volgende investering, waarbij geen rekening is
gehouden met drastische vernieuwing van het lesprogramma:
Activiteit Tijd
Docent
Voorbereiden 8 colleges van 2 uur 32
Geven colleges (inclusief reistijd) 32
Voorbereiden 6 werkcolleges van 2 uur 12
Geven werkcolleges (inclusief reistijd) 24
Tijd
ondersteuning
Begeleiden praktikum (6 uur per week) 48
Nakijken praktikumopgaven 32
Opstellen tentamen en hertentamen 8
Nakijken tentamen en hertentamen 24
Incidentele contacten met studenten 15
Totaal 147 80
Kortom het verzorgen van één vak kost 227 uur. Dit correspondeert met 0.14 FTE (docent
0.09 FTE en assistent 0.05 FTE).
Voor de papersessies en de voortgangsbesprekingen is een docent per groep van 10
studenten nodig.
Dit leidt tot het volgende overzicht van de tijdsinvestering in de opleiding (voor 30
studenten):
Activiteit Tijd
6 vakken à 227 uur = 6 × 227 1362
28 voortgangsbesprekingen (1 uur), drie groepen, inc. reistijd = 28 × 2 × 3 168
28 papersessies (2 uur), drie groepen, inc. reistijd = 28 × 3 × 3 252
Beoordelen van 6 papers per student (à 1 uur) = 6 × 1 × 30 180
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 36

Activiteit Tijd
Begeleiden en beoordelen van literatuurstudie per student = 4 × 30 120
Begegeleiden opstellen plan van aanpak stage = 4 × 30 120
Begeleiden externe stage (25) en scriptie = 24 × 25 600
Begeleiden intern stage (5) en scriptie = 48 × 5 240
Afstuderen (beoordelen scriptie, presentaties, e.d.) 4 × 30 120
Organisatie, planning en communicatie 350
Totaal 3512
Het verzorgen van de totale opleiding kost 3512 uur, ofwel 2.2 FTE. Als we deze scherpe
calculatie vergelijken met de beschikbare capaciteit (1.96 FTE) dan ziet we dat er iets te
weinig personeel is. De belasting om de totale opleiding te geven wordt door de staf dan
ook als vrij zwaar ervaren. Dit komt vermoedelijk doordat de intensiteit van deze vorm van
onderwijs veel meer tijd, aandacht en energie van de staf vergt.
Bovendien is er momenteel weinig ruimte om verder te vernieuwen, om werving en
communicatie beter aan te pakken, of om calamiteiten op te vangen.
Lesuitval in geval van ziekte of overige calamiteiten
Doordat bij de meeste vakken twee docenten betrokken zijn wordt de kans op lesuitval
door ziekte verminderd. Mocht een college toch uitvallen dan beperkt de flexibiliteit van
de opleiding de impact hiervan. De flexibiliteit maakt het mogelijk om:
● College op korte termijn opnieuw in te roosteren.
● Programma onderdelen met elkaar te verschuiven zodat het uitvallen van het
college niet leidt tot tijd die studenten niet kunnen besteden.
T3.3 Kwaliteit personeel
Het personeel is gekwalificeerd voor de inhoudelijke, onderwijskundige en
organisatorische realisatie van het programma.
Didactische eisen personeel
Het docententeam beschikt over ruime ervaring met lesgeven, het geven van feedback en
vergelijkbare vaardigheden als presenteren, motiveren en verduidelijken.
Is het personeel adequaat toegerust op doceren?
Zie hierboven.
Richt het personeel zich op actieve participatie van de student?
Student wordt aangezet tot actieve participatie door de didactische vormen. De begeleiding
richt zich op grote inzet van de student. Er worden geen makkelijke antwoorden gegeven.
De student moet zelf nadenken over bepaalde zaken en bewust worden van de implicaties
van gemaakte keuzen.
Kan docerend personeel goed omgaan met de verschillende leerstijlen van studenten?
De verschillende leerstijlen komen aan bod in de verschillende didactische vormen en het
behandelen van theorie aan de hand van concrete voorbeelden. Daarnaast is er een
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 37

gevarieerd docententeam die beschikt over verschillende achtergronden en invalshoeken.
Hierdoor kan het team goed omgaan met verschillende leerstijlen van studenten.
Continuïteit
Bij alle vakken is er iemand uit het team van coördinatoren of uit de onderzoeksgroep van
het betreffende vak die in geval van uitval van een docent het vak over kan nemen.
Instroom en selectie
De opleiding is zich er zeer van bewust dat een kwalitatief goede instroom essentieel is
voor een goed eindresultaat. Goede werving en selectie (zie hieronder) vormen daar een
onderdeel van. Uitval wordt tot een minimum beperkt door goede informatie te geven
tijdens de werving en door selectie van de instroom. Door in het begin veel aandacht aan
de juiste werkhouding te bespreken is er direct een gewenste uitval van studenten die niet
over de juiste motivatie beschikken. De instroom zelf hebben we al eerder gekarakteriseerd
(zie blz. 26 en 44).
Daarnaast wordt zo snel mogelijk inzicht gekregen in de capaciteiten van studenten. Met
die studenten waar, op basis van eerste ervaringen en cijfers, twijfel bestaat of ze de
ontwikkeling kunnen doormaken die de opleiding beoogt wordt dit in een
functioneringsgesprek met de student besproken. Ons uitgangspunt is dat studenten die het
eerste blok met goed resultaat afsluiten in principe de hele opleiding met goed gevolg
kunnen voltooien.
Kwaliteit uitstroom
Zoals al eerder is opgemerkt is een goede instroom een primaire factor om een goede
uitstroom te garanderen. Naast de controle op de kwaliteit van de uitstroom per vak is er
speciale aandacht voor de kwaliteit van het afstudeerproject en daarover te schrijven
scriptie. De scriptie is immers het meest tastbare en blijvende resultaat van de opleiding en
dient als visitekaartje van de opleiding. Op de kwaliteit van de scriptie wordt toegezien
door scherpe controle op de voorbereiding (plan van aanpak, literatuurstudie), de
uitvoering (stage) en verslaglegging (afstudeerscriptie).
De opleiding stelt zich ten doel om te voorkomen dat afstudeerscripties van onvoldoende
niveau worden goedgekeurd. Hiertoe worden duidelijke en faire spelregels, en criteria
gehanteerd om te komen tot een uniforme beoordeling. Er zijn drie kansen om een scriptie
in te leveren ter goedkeuring. Voor 15 juli, voor 1 september, voor 15 september. Lukt het
de laatste keer niet, dan dient het daaropvolgende studiejaar een nieuw afstudeerproject te
worden uitgevoerd. Het hele leermodel en de kwaliteitsbewaking zijn er echter op gericht
om dit te voorkomen.
Naast de toetsing van de kwaliteit van de opgeleverde scripties door de voorzitter van de
examencommissie (Prof.dr. P. van Emde Boas) en door diens vervanger Dr. P. Rodenburg
is in het eerste jaar van het academisch niveau van de opgeleverde scripties ook getoetst
door dr. W.H. Kaper, docent van het Amstel Instituut. Dit zal steekproefgewijs regelmatig
herhaald worden.
Fraude
Helaas is in de afgelopen jaren gebleken dat voor enkele studenten de werkdruk te hoog is
en zij soms overgaan tot het kopiëren van werk van medestudenten of van teksten die
direct van het Internet gehaald worden. Dit is een veel breder probleem waar nog geen
waterdichte maatregelen tegen te nemen zijn. Tijdens de introductiedagen en de
voortgangsbesprekingen wordt het onderwerp fraude expliciet aan de orde gesteld en
studenten worden geconfronteerd met de consequenties. Daarnaast wordt, in geval van
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 38

twijfel, door docenten gericht op plagiaat gelet. Doordat docenten en begeleiding een goed
beeld van de student hebben en de totstandkoming van werk kunnen volgen kan mogelijke
fraude relatief snel gesignaleerd worden. De geconstateerde gevallen zijn in Appendix
Kwantitative gegevens Master Software Engineering op pagina 46samengevat. Wij hebben
al deze gevallen direct gemeld bij de examencommissie en dit heeft steeds geleid tot
uitsluiting voor het betreffende vak. Het geval in het jaar 2005-2006 is nog in behandeling.
In alle gevallen betrof het studenten die sociaal vrij geïsoleerd in de groep opereerden,
matig presteerden, en in de tweede helft van het jaar waarin de individuele vrijheid groter
is hun toevlucht tot tot plagiaat namen. In alle gevallen betrof het teksten die letterlijk uit
andere (meestal online) bronnen overgenomen waren.
Afsluiting
Onze studenten werken bijzonder hard om aan alle verplichtingen van de opleiding te
voldoen. Door het verzorgen van een passende afsluiting wordt dit beloond. De diploma’s
worden uitgereikt tijdens een plechtige ceremonie die gekenmerkt wordt door:
● Aantrekkelijke locatie.
● Enkele korte praatjes door vertegenwoordigers van de in de opleiding
participerende organisaties of van belanghebbende buitenstaanders (b.v.
bedrijfsleven).
● Iedere student krijgt individueel zijn diploma uitgereikt en wordt individueel
toegesproken.
● Iedere student krijgt de speciale Software Engineering baret uitgereikt.
● Familie en vrienden kunnen aanwezig zijn.
● Er is een fotosessies voor groepsfoto's (zie voorbeelden).
● Feestelijke borrel ter afsluiting.
Alumni
Op dit moment heeft het alumnibeleid formeel nog onvoldoende vorm gekregen. Informeel
zijn er echter regelmatig contacten:
● Adresgegevens worden bijgehouden.
● Alumni bevelen de opleiding aan bij collega's.
● Alumni bieden zelf stageplaatsen aan en worden actief ingeschakeld bij het vinden
van stageplaatsen.
● Alumni worden via de WO monitor door de UvA geënqueteerd.
● We hebben de alumni zelf in mei 2006 geënqueteerd
Hoewel onze alumni lid kunnen worden van de algemene alumnivereniging van de UvA
en, de facto, de contacten met de alumni redelijk goed lopen, streven wij na om:
● Van onze alumni systematische terugkoppeling te krijgen over de kwaliteit van
onze opleiding en de match met hun baan bij onderzoeksinstelling of bedrijfsleven.
● De alumni in te schakelen bij de werving van studenten.
● De alumni in te schakelen bij het vinden van stageplaatsen.
● De alumni als ambassadeurs van onze opleiding op te laten treden.
Hiertoe zullen wij op korte termijn onze banden met de alumni beter gaan organiseren:
● Als onderdeel van het opzetten van de nieuwe website voor de opleiding zullen we
daarin ook plaats maken voor onze alumni in de vorm van adresgegevens en een
mailinglijst.
● We gaan de alumni systematischer inlichten over de voortgang van de opleiding.
● We gaan een jaarlijkse terugkomdag organiseren om de contacten verder te
versterken.
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 39

De uitkomsten van de enquête onder alumni zijn te vinden op blz. 46. Hieruit blijkt dat de
meeste alumni direct na het behalen van het diploma een baan hebben, dat zij zeer tevreden
zijn over de opleiding als geheel, en nog steeds profijt hebben van hetgeen ze geleerd
hebben.
Ontwikkeling van de opleiding
De ontwikkeling van de opleiding over de afgelopen jaren kan alsvolgt gekarakteriseerd
worden.
2003/2004:
● 1 e jaar van de opleiding; intensieve opstartfase.
● Curriculum wordt gebaseerd op SWEBOK.
● Invoeren van wekelijkse voortgangsbesprekingen.
● Laten uitvoeren van externe toets op kwaliteit van de scripties.
2004/2005:
● Invoeren van een uniform concept binnen alle vakken door uniformeren
paperopdrachten, centrale begeleiding en uniforme beoordeling.
● Vernieuwen van het vak Software Proces.
● Ervoor zorgen dat het organiseren van afstudeerplaatsen zoveel mogelijk vóór
januari klaar is, zodat de literatuurstudie helemaal ten dienste kan staan van het
afstudeerproject.
● Ontwikkelen van additioneel didactisch materiaal ten behoeve van Software
Evolution.
2005/2006:
● Consolideren van de opleiding.
● Verbeteren van de vakken Testen en Requirements Engineering.
● Gestructureerd aanleren van vaardigheden.
● Maatregelen nemen om de schaalbaarheid te verbeteren i.v.m. grote instroom.
● Bestendigen van het vak Software Proces.
● Starten met eigen website: www.software-engineering-amsterdam.nl
● Starten met deeltijdopleiding.
● Voorbereiden en laten uitvoeren van accreditatie.
2006/2007:
● Afstemmen practica tussen Software Architectuur en Software Evolutie
● Integreren practica Software Constructie en Software Process in het leerbedrijf.
● Verbeteren van de vakken Testen en Requirements Engineering.
● Starten met adviesraad.
● Starten met alumnivereniging.
● Bestendigen en beter balanceren van de instroom.
● Ontwikkelen van beleid op het gebied van tentamens.
Lange termijn ambitie
● Afleveren van alumni op topniveau.
● Bijdrage aan de maximale ontplooiing instromers uit HBO en WO.
Verbeterpunten in de komende jaren:
● Instellen en gebruik maken van de klankbordgroepen en adviesraad.
● Oprichten alumnivereniging.
● Evaluatie van vakken beter structureren op basis van vakmodel conform figuur.
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 40

● De resultaten van de voortgangsbesprekingen systematischer vastleggen.
● Gebruik maken van één van de commerciële dienstverleners die systematisch naar
plagiaat in ingeleverde werkstukken zoekt.
● De faciliteiten zijn voor verbetering vatbaar, maar dit kan alleen op UvA-niveau.
● Beter formaliseren en vastgeleggen van de informatiestromen binnen de opleiding.
● Beleid formuleren t.b.v. tentaminering.
● Enquêteren bedrijven waarbij alumni werkzaam zijn.
T4.1 Materiële voorzieningen
Materiële voorzieningen: de huisvesting en materiële voorzieningen zijn toereikend om het programma te
realiseren.
Zie de algemene beschrijving van faciliteiten in Appendix Standaardvoorzieningen
Universiteit van Amsterdam (blz. 80) en in het hoofdstuk LEERMODEL (blz. 21) de
specifieke inrichting van de leeromgeving.
T4.2 Studiebegeleiding
De studiebegeleiding en de informatievoorziening aan studenten zijn adequaat met het oog op
studievoortgang
De studiebegeleiding en de informatievoorziening aan studenten sluiten aan bij de behoefte van studenten.
Er is intensieve studiebegeleiding voor de studenten. In groepen van 10 hebben studenten
begeleiding van een vaste docent. Dit wordt elke acht weken gewisseld. Hierdoor krijgen
studenten vanuit meerdere invalshoeken feedback en leren ze de feedback ook te
relativeren. Verder wordt verwezen naar het leermodel voor meer informatie over
begeleiding
T5.1 Evaluatie resultaten
De opleiding wordt periodiek geëvalueerd, mede aan de hand van toetsbare streefdoelen.
De opleiding wordt periodiek geëvalueerd volgens de doelstelling, criteria en methoden
van de kwaliteitszorg UvA (zie pagina 83). De belangrijkste instrumenten daarvan zijn:
● Opleidingscommissie.
● Onderwijsevaluatie.
● Een geïntegreerd systeem van kwaliteitszorg.
● Studententevredenheidsmonitor.
● Uitkomsten alumni-enquête.
In de kleine omgeving van deze opleiding is er een sterke uitwisseling tussen de
verschillende docenten, coördinatoren en studenten. Er wordt veelvuldig geëvalueerd en
scherp geëvalueerd. Een van de sterkste punten is de ervaring, betrokkenheid en
kwaliteitsbewustheid van het docententeam. Daarnaast is er ruimte om nieuwe didactische
vormen uit te proberen. Zie hiervoor ook het hoofdstuk BESTURING EN
KWALITEITSVERBETERING (blz. 33).
T5.2 Maatregelen tot verbetering
De uitkomsten van deze evaluatie vormen de basis voor aantoonbare verbetermaatregelen die bijdragen aan
realisatie van de streefdoelen.
Zie T5.1 en Appendix Kwaliteitszorg Universiteit van Amsterdam op blz. 83.
Bij alle onderdelen in het plan staan verbeterpunten. Deze komen naar voren uit formele en
informele evaluaties. De afgelopen jaren zijn tal van grote en kleine
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 41

verbeteringsmaatregelen genomen. Dit alles omdat de docenten veel eer scheppen in het
neerzetten van een kwalitatief zeer goede opleiding.
T5.3 Betrekken van medewerkers, studenten, alumni en beroepenveld
Bij de interne kwaliteitszorg zijn medewerkers, studenten, alumni en het afnemend beroepenveld van de
opleiding actief betrokken.
Zie T5.1 en Appendix Kwaliteitszorg Universiteit van Amsterdam op blz. 83.
Voor de korte termijn zijn er docenten bij de opleiding betrokken die uit de praktijk
komen. Voor de komende jaren is de opleiding voornemens adviesraden in te richten om
de aansluiting met de praktijk verder te verankeren.
Doordat de eerste afstudeerders slechts twee jaar geleden de opleiding hebben verlaten is
er nog weinig aan alumni-activiteiten verricht. Het komende jaar zal dit een focuspunt
worden. De website zal hier een rol in moeten gaan spelen om een community te vormen,
waar alumni elkaar kunnen bereiken.
Bij de afstudeerprojecten zijn tientallen bedrijven betrokken die tijdens de uitvoering van
dat project en vooral bij de beoordeling ervan duidelijk hun mening geven over zowel de
individuele student als over de opleiding zelf. Uit het feit dat zeer veel afstudeerders direct
door het stagebedrijf in dienst worden genomen concluderen wij voorzichtig dat het
afnemend beroepenveld tevreden is over onze afstudeerders. Bovendien worden er
gastcolleges gegeven door deskundigen uit het afnemende veld.
Tenslotte bezoeken docenten en coordinatoren alle stagebedrijven en krijgen daardoor een
nauwkeuring beeld van het niveau van onze studenten en de wensen van de stagebedrijven.
T6.1 Gerealiseerd niveau
De gerealiseerde eindkwalificaties zijn in overeenstemming met de nagestreefde eindkwalificaties qua
niveau, oriëntatie en domeinspecifieke eisen.
Het eerste jaar is een gedetailleerde studie naar het gerealiseerde niveau van de opleiding
uitgevoerd door W. Kaper (Amstel Instituut). Daarbij is aandacht besteed aan het
wetenschappelijk niveau van de opleiding als geheel, studeerbaarheid, kwaliteit van de
scripties, realiseren van de gestelde eindtermen, enz. Hiervoor is naast een vergelijking
van de eindtermen met het aangeboden curriculum, ook een selectie van scripties in detail
bestudeerd en is een enquête onder de afgestuderden gehouden. De conclusies hiervan
waren zeer positief. Enkele citaten:
● De master Software Engineering wil een beroepsopleiding zijn op academisch
niveau. Hoewel er op het gebied van software engineering wetenschappelijk
onderzoek wordt gedaan naar software ontwikkelmethoden, en docenten van de
opleiding hierbij betrokken zijn, zullen de meeste afgestudeerden een carrière
vinden als leiders van software ontwikkelteams. De opleiding richt zich qua
eindtermen op deze verwachte beroepspraktijk.
● De hiervoor nodige analytische vaardigheden (zie de eindtermen) zijn van
academisch niveau. De discipline der software engineering laat zich wat dit
aangaat vergelijken met een discipline als geneeskunde. Zij verhoudt zich tot
informatica ongeveer zoals geneeskunde tot biologie. Software engineering is
interdisciplinair in de zin dat behalve analyse van software (=informatica) ook
analyse van bedrijfsprocessen en van gebruikerswensen aan de orde is. Dit alles
tezamen vormt echter wel één goedomschreven discipline.
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 42

● In de diverse colleges wordt zeer veel aandacht besteed aan het lezen van recente
wetenschappelijke publicaties. Wij sluiten niet uit dat in deze opleiding door
studenten meer wetenschappelijke publicaties gelezen en bediscussieerd worden
dan in andere mastersopleidingen.
● We concluderen dat in de ogen van studenten de opleiding Software Engineering
een curriculum realiseert dat past bij de eindtermen van deze opleiding.
De daarop volgende jaren zijn er tal van verbeteringen doorgevoerd in zowel de opleiding
(inhoud en onderwijsvormen) als in de selectie (naast het vaststellen van de vereiste
voorkennis meer nadruk op reeds aanwezige programmeerervaring en taalvaardigheid).
Naast de nadruk in het curriculum op het aanleren van een wetenschappelijke attitude
onderbouwen de volgende overwegingen verder het academische niveau van de opleiding:
● Delen van de gegeven vakken worden ook in tweejarige mastersopleidingen
computer science bij VU en UvA gebruikt. Dit geldt voor het vak Software
Architecture als geheel en voor delen van Software Evolution en Software
Construction.
● De in de opleiding gebruikte literatuur wordt elders ook in universitaire curricula
gebruikt.
Weerspiegelen de afstudeeropdrachten de eindkwalificaties?
Er zijn duidelijke criteria opgesteld voor het afstudeerproject. Deze zijn in lijn met de
eindkwalificaties. Om te borgen dat een student een goed project heeft vindt er nauw
overleg plaats tussen docent en begeleider op een geformaliseerde manier. Er zijn twee
controlemomenten. De eerste is of een afstudeerplaats / opdracht vanuit een bedrijf /
instelling voldoende potentie heeft voor een academische afstudeeropdracht die bij de
opleiding aansluit. Dit gebeurt op het moment dat de student contact heeft met een bedrijf.
Het tweede controlemoment is als de student de onderzoeksvragen concretiseert. De
student werkt dit uit in een plan van aanpak dat door de opleiding dient te worden
goedgekeurd.
Naast controle op het academische gehalte wordt er ook gekeken naar de haalbaarheid van
het project. Daarnaast wordt het plan gebruikt om de student feedback te geven en te
begeleiden bij zijn afstudeerproject.
T6.2 Onderwijs-rendement
Voor het onderwijsrendement zijn streefcijfers geformuleerd in vergelijking
met relevante andere opleidingen.
Het onderwijsrendement voldoet aan deze streefcijfers.
Uitstroom en rendement worden gegeven in Appendix Kwantitatieve gegevens Master
Software Engineering op blz. 44.
Zoals uit de Onderwijsvisitatie Informatica 2002 19 blijkt had de UvA toen een zeer laag
propedeuserendement van 33.7%. Geen enkele Nederlandse Universiteit haalt daarbij een
rendement hoger dan 58% (VU). De UvA haalt in deze visitatie een redelijk postpropedeuserendement
van 70,7%. Hoogste score is 83% (TUE) dat als “relatief goed” gezien
wordt.
Wij mogen ons rendement zonder meer als goed aanmerken, al moet daar direct bij
aangetekend worden dat dit slechts op drie cohorten studenten is gebaseerd: 89% in 2003,
100% in 2004, en 89% in 2005, zie blz. 44.
19 Onderwijsvisitatie Informatica, VSNU, 2002, Zie
http://www.qanu.nl/comasy/uploadedfiles/informatica[1].internet.pdf
12-FEB-07 BESTURING EN KWALITEITSVERBETERING 43

Appendix A: Kwantitatieve gegevens Master Software Engineering
In deze appendix geven wij enkele kwantitatieve gegevens over de opleiding. Voor het
lopende jaar 2005-2006 zijn nog niet alle gegevens beschikbaar. Bovendien zit er een
kleine foutmarge in de gegevens doordat de officiële UvA administratie en de
administratie van de opleiding zelf niet altijd volledig synchroon lopen.
A1. Instroom en Uitstroom
Instroom, rendement en achtergrond
Nog WO HBO
Instroom Gehaald Rendement bezig bachelor bachelor
2003-2004 19 17 89% 1 2 17
2004-2005 15 15 100% 0 0 15
2005-2006 28 (+8) 25 89% 1 1 36
2006-2007 20 (+4) 4 20
Tussen haakjes staan de gegevens voor deeltijdstudenten.
Van de lichting van 2006-2007 zijn 3 voltijdstudenten gestopt na het eerste blok; 2
voltijdstudenten en een deeltijdstudent zijn gestopt na het tweede blok. Een daarvan is
geswitched naar de master Informatiekunde.
Een van de deeltijdstudenten in 2005/2006 is inmiddels gestopt. Bij de overigen is de
vertraging minimaal (één deeltijdstudent moet nog een vak inhalen).
Specificatie achtergrond instromers
HBO
Technische
HBO
Informatie
HBO
Bedrijfsk.
Overig
HBO
Hogere Inf. HBO Inf. Inf. kunde Informatica
2003-2004 9 1 0 1 2 6
2004-2005 8 2 0 2 1 2
2005-2006 14 12 4 1 2 4
A2. Gemiddelde eindcijfers
De gemiddelde eindcijfers per vak zijn alsvolgt. Tussen haakjes staat de spreiding.
Vak 2003-2004 2004-2005 2005-2006 2006-2007
Software Evolution 7.3 (0,6) 7.3 (0.7) 7.5 (0.5) 8.1 (0.6)
Software Architecture 7.3 (0.4) 7.2 (0.5) 6.8 (0.3) 6.8 (0.4)
Software Testing 7.0 (0.6) 7.5 (0.4) 7.6 (0.5)
Requirements Engineering 7.7 (0.5) 7.1 (0.6) 7.1 (0.5)
Software Construction 7.6 (0.5) 7.5 (0.4) 7.5 (0.6)
Software Process 7.1 (0.9) 7.4 (0.4) 7.4 (0.4)
Literatuurstudie 7.5 (0.5) 7.6 (0.6) -
Masterproject 7.4 (0.7) 7.6 (0.6) 7.4 (0.4)
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 44

De herkansingen per vak zijn alsvolgt.
Vak 2003-2004 2004-2005 2005-2006
1x 2x 3x Niet 1x 2x Niet 1x 2x Niet
Software Evolution 19 15 23 4 1
Software Architecture 13 6 15 30 2 3
Software Testing 13 6 13 2 28
Requirements
19 11 4 34 1
Engineering
Software Construction 18 1 15 32 2
Software Process 13 3 1 2 16 1 33 1
Literatuurstudie 19 15 27
Masterproject 16 2 1 13 2 15 10 2
Vak 2006-2007
1x 2x 3x Niet
Software Evolution 21 3 (1?) 6
Software Architecture 14 1 (2?) 2
Software Testing
Requirements Engineering
Software Construction
Software Process
Literatuurstudie
Masterproject
A3. Studentenevaluaties
Vak 2003-2004 2004-2005 20 2005-2006 21 2006-2007
Software Evolution 6.7 7.7 7.4 7.1
Software Architecture 7.7 7.4 7.5 6.9
Software Testing 5.3 6.4 5.4 7.2
Requirements Engineering 7.4 - 7.6 7.7
Software Construction 6.9 7.7 7.2/7.9
Software Process 6.8 6.4 6.5/7.3
Literatuurstudie 7.1 - 22 -
20 Door een administratieve fout zijn de vakken Requirements Engineering en Masterprotect niet
geëvalueerd.
21 Van een aantal vakken zijn de resultaten onderscheiden naar voltijd/deeltijd.
22 Vanaf 2004-2005 zijn de Literatuurstudie en de Voorbereiding Mastersprojects als geheel geëvalueerd.
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 45

Voorbereiding
Mastersproject
Vak 2003-2004 2004-2005 2005-2006 2006-2007
6.5 7.3 7.5
Mastersproject 7.8 - -
Het is duidelijk dat het vak “Software Testing” in de eerste drie jaar niet goed beoordeeld
werd. Voor het huidige studiejaar is een verbetertraject ingezet dat blijkens de betere
beoordeling door studenten goede resultaten oplevert. Zie verder de vakbeschrijving op
blz. 58.
A4. Fraudegevallen
Jaar Aantal
gevallen
Betrokken
studenten
Toelichting
2003-2004 1 1 Paper Software Process
2004-2005 0 0
2005-2006 2 1 Paper Software Process
A5. Evaluatie door alumni
Paper Software Constructie
In mei 2006 hebben wij een enquête gehouden onder de alumni van de twee studiejaren
2003-2004 en 2004-200. Van de aangeschreven 32 alumni heeft 63% gereageerd. De
resultaten zijn zeer positief en kunnen alsvolgt samengevat worden:
● 85% van de respondenten had direct na het afstuderen een baan.
● De trefwoorden Automatisering/ICT, Ontwerp en Advisering passen het beste bij
hun functies.
● De alumni vervullen veelal functies in het ICT-bedrijfsleven i.h.b. zakelijke
dienstverlening.
● 12% is werkzaam bij een universiteit of onderzoeksinstelling.
● De aansluiting tussen opleiding en functie is zeer goed.
● 84% van de respondenten geeft de opleiding een 8 of hoger en beveelt deze graag
aan bij collega's of voormalige medestudenten.
● 29% geeft aan suggesties voor het verbeteren van de inhoud te hebben.
● 47% zou tot een nog hoger cijfer komen als de diepgang van de opleiding nog
verder wordt opgevoerd, b.v. in een tweejarige opleiding. Kennelijk hebben zij
door de opleiding de smaak van het studeren te pakken gekregen, maar
vermoedelijk waren zij nooit voor een tweejarige opleiding gekomen.
● De respondenten vinden in zeer grote meerderheid dat vaardigheden die zij
belangrijk achten in de opleiding voldoende aandacht krijgen.
● De eindtermen van de opleiding worden van (redelijk tot groot) belang geacht door
de alumni. De eindterm “Heeft zich rekenschap gegeven van de maatschappelijke,
ethische en sociale aspecten van Software Engineering” scoort daarbij het laagst
(met 52%).
Tenslotte nog enkele smaakmakende citaten:
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 46

● “De opleiding heeft door zijn intensieve en diepgravende aard, in het vakgebied,
mij veel bijgebracht over de "echte" wereld van software. De kloof tussen mijn
HBO opleiding en de Masters werd gedurende de opleiding steeds duidelijker.”
● “Wat mij vooral aansprak was de kleinschaligheid en de persoonlijke begeleiding.
Dat is bij groot succes misschien moeilijk zo te houden, maar dat is denk ik wel
wat het verschil maakt met veel andere opleidingen.”
● “Dankzij intensieve begeleiding was ik in staat om in 1 jaar vele malen meer te
leren dan drie jaar HBO.”
● “De 1-jarige masteropleiding SE is een unieke en voor het bedrijfsleven een goed
aansluitende en hoogwaardige opleiding.”
Resultaten alumni-enquête
Totaal aantal reacties: 20
Deelname naar afstudeerjaar
2004 60 %
2005 40 %
Tijd tussen afstuderen en eerste baan
< 3 maanden 85 %
3-6 maanden 5 %
6-12 maanden 0 %
> 1 jaar 0 %
Nog geen baan gevonden 0 %
Naar vervolgopleiding 5 %
Type contract
Eerste baan
Vervolgfuncties
Tijdelijke baan, zonder uitzicht op
vast dienstverband
Tijdelijke baan, met uitzicht op vast
dienstverband
0%, 6%
17%, 11%
Vast dienstverband 11%, 50%
Free lance contract
Eigen bedrijf 6%, 0%
Trefwoord best passend bij functie
Welk van onderstaande trefwoorden past het beste bij uw eerste baan, meest recente
of huidige functie?
Advisering 11%, 22%
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 47

Automatisering / ICT 28%, 50%
Beleidsontwikkeling 6%, 0%
Directie / Management 6%, 0%
Logistiek
Marketing
Onderwijs 0%, 6%
Onderzoek, promotie 0%, 6%
Onderzoek, overig 6%, 6%
Ontwerp 17%, 28%
Organisatie / Coordinatie / Planning 6%, 6%
Techniek / Apparatuurontwikkeling 0%, 17%
Overig 6%, 6%
Overige trefwoorden:
• Auditing
• Software ontwikkeling
Branches waarin alumni werkzaam zijn
In welke branche had u uw eerste baan, meest recente of huidige functie?
Bankwezen
Bedrijfsleven 11%, 28%
Industrie
Middelbare school of HBO 0%, 6%
Onderzoeksbureau /
onderzoeksinstituut
6%, 0%
Overheid 0%, 6%
Universiteit 0%, 6%
Verzekeringswezen
Zakelijke dienstverlening 11%, 11%
Ziekenhuis
Overig 6%, 11%
Overige branches:
• SAP
• Accountancy
• Trading
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 48

Verband tussen opleiding en werkzaamheden tijdens de eerste baan
Geheel 28 %
In belangrijke mate 39 %
Ten dele 28 %
In geringe mate 6 %
Eigenlijk niet 0 %
Verband tussen opleiding en werkzaamheden tijdens de huidige functies
Geheel 17%, 11%
In belangrijke mate 0%, 44%
Ten dele 17%, 11%
In geringe mate
Eigenlijk niet
Vereist opleidingsniveau van de eerste baan
Minimaal HBO 72 %
Minimaal WO 17 %
Anders 11 %
Vereist opleidingsniveau van de huidige functie
Minimaal HBO 28%, 50%
Minimaal WO 0%, 17%
Anders 6%, 0%
Rapportcijfer van de opleiding
1 0 %
2 0 %
3 0 %
4 0 %
5 0 %
6 0 %
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 49

7 16 %
8 53 %
9 26 %
10 5 %
Verbeterpunten voor de opleiding
Verbeteringen die zouden kunnen leiden tot hoger rapportcijfer
Inhoud 29 %
Diepgang 47 %
Vormgeving /
onderwijsmethodes
Studeerbaarheid 12 %
Programmering / roostering 6 %
Huisvesting 12 %
24 %
Werkplekken 24 %
Administratie 0 %
Overig 24 %
Overige verbeterpunten:
• minder werk in practicum groepjes
• presenteren, argumenteren
• Meer betrekken met andere vakgebieden
• begeleiding
• opleidingsduur naar 2 jaar met meer inhoud en
diepgang
Eindtermen 23
Kunt u van onderstaande vaardigheden aangeven in welke mate deze belangrijk zijn
voor uw huidige functie of meest recente functie en of hier genoeg aandacht aan is
besteed tijdens uw studie?
Heeft inzicht in de belangrijkste technologische
ontwikkelingen en hieraan gerelateerde wetenschappelijke
resultaten
Belang
Enig Redelijk Groot
21% 32% 47%
Is in staat dit inzicht in te zetten ten behoeve van innovatie 11% 26% 63%
Kan software-engineeringproblemen aanpakken met behulp
van abstractie en modelvorming en is in staat de oplossingen
11% 26% 63%
23 Onderdeel van deze vraag was ook of elke eindterm wel/niet voldoende in de opleiding aan bod komt.
Helaas zijn deze onderdelen van het antwoord door een technische storing niet geregistreerd.
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 50

zowel in algemene termen als in wiskundige en technische
termen te formuleren
Heeft zich rekenschap gegeven van de maatschappelijke,
ethische en sociale aspecten van Software Engineering
Is vaardig in het exploreren (zoeken, lezen en beoordelen) van
de vele vormen, zowel wat betreft de inhoud als medium, van
documentatie en literatuur op gebied van Software Engineering
Beheerst methoden en technieken om een softwaresysteem mee
te laten evolueren met de veranderde eisen die aan dat systeem
worden gesteld
Is in staat kwalitatief hoogwaardige systemen te ontwikkelen
door het systematisch gebruik van methoden en technieken op
het gebied van requirements analyse, ontwerp, architectuur,
constructie en testen
Beheerst een scala aan testmethoden en technieken, weet
wanneer welke techniek ingezet dient te worden en heeft
hiermee ook praktische ervaring opgedaan.
Is in staat richtlijnen op het gebied van softwareconstructie op
te stellen, bijvoorbeeld ten aanzien van coding standards,
herstructurering, configuratie management en build processen
Is in staat systeemeisen te vertalen in een systeemarchitectuur
en afwegingen tussen conflicterende eisen zorgvuldig te maken
en te motiveren
Is in staat wensen van systeemgebruikers om te zetten in
specifieke requirements, objectmodellen en acceptatietests
Is op de hoogte van diverse software procesmodellen en kent
de voor- en nadelen van deze. Hij is in staat een
ontwikkelingsproces te kiezen voor een specifiek project en het
geselecteerde proces optimaal af te stemmen op de eisen die
door dat project gesteld worden.
Heeft voldoende technische kennis en intellectuele capaciteiten
om na enige jaren ervaring een leidinggevende rol in het
werkveld van de Software Engineering te kunnen spelen
Is in staat een visie te ontwikkelen op het gebied van Software
Engineering en zodoende bij te dragen aan de evolutie en
innovatie van concrete Software Engineering projecten.
47% 26% 26%
0% 37% 63%
5% 42% 53%
11% 11% 79%
26% 37% 37%
16% 37% 47%
0% 42% 58%
11% 37% 53%
16% 53% 32%
5% 37% 58%
5% 32% 63%
Aanbevelen van de opleiding aan derden
Zou u de opleiding aanbevelen aan uw medestudenten van eerdere opleidingen?
Zeker niet 0 %
0 %
5 %
32 %
Zeker wel 63 %
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 51

Zou u de opleiding aanbevelen aan uw huidige collega's?
Zeker niet 0 %
0 %
17 %
39 %
Zeker wel 44 %
Vaardigheden
Kunt u van onderstaande vaardigheden aangeven in welke mate deze belangrijk zijn
voor uw huidige functie of meest recente functie en of hier genoeg aandacht aan is
besteed tijdens uw studie?
Belang
Voldoende in
studie?
Enig Redelijk Groot Ja Nee
Schriftelijke vaardigheden 6% 50% 44% 94% 6%
Mondelinge vaardigheden 0% 28% 72% 78% 22%
Beheersing van de Engelse taal 6% 33% 61% 61% 39%
Informatie verzamelen 6% 22% 72% 100% 0%
Samenwerken 0% 22% 78% 94% 6%
Zelfstandig werken 0% 17% 83% 72% 28%
Feedback geven en ontvangen 0% 22% 78% 83% 17%
Problemen analyseren 0% 11% 89% 78% 22%
Time-management 6% 39% 56% 61% 39%
Discussiëren 6% 28% 67% 83% 17%
Abstract denken 11% 33% 56% 94% 0%
Praktisch probleem aanpakken m.b.v.
theorie
6% 39% 56% 89% 11%
Kwaliteit van literatuur beoordelen 28% 39% 33% 83% 17%
Origineel onderzoek doen 44% 33% 22% 83% 17%
12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering 52

Appendix B. Overzicht Vakken
B1. Software Evolution
Motivering
Wil een software systeem zijn waarde voor de gebruikers behouden, dan is het van groot
belang dat het systeem mee kan evolueren met de veranderende eisen die de business en de
technologie stellen. Vaak zal het gaan om veranderingen die plaats vinden terwijl het
systeem al in productie is. Dit vak beoogt de student bewust te maken van het verschijnsel
software-evolutie en van de methoden en technieken die nodig zijn om deze evolutie te
controleren. Na afloop van dit onderdeel is de student in staat om een keuze te maken uit
verschillende technieken om systemen te analyseren en meer flexibel te maken.
Te verwerven competenties
● Inzicht in rol en belang van software maintenance, software evolutie en software
renovatie in de software life cycle.
● Globaal overzicht van methoden en technieken voor analyse en transformatie van
source code.
● Kennis van en ervaring met enkele specifieke technieken voor analyse en
transformatie van source code.
Opzet van het vak
Het vak is opgezet als een soort “shocktherapie”. Al bij het eerste college wordt de
opdracht gegeven om over een niet-triviaal open source systeem (ruim 110 KLOC) een
tiental vragen te beantwoorden. Daarbij mag iedere denkbare aanpak gebruikt worden:
handmatig analyse, tools opsporen die toepasbaar zijn, of zelf tools bouwen. Deze pijnlijke
ervaring vormt een uitstekende motivatie voor de op het college behandelde stof.
Aan het einde van het vak worden dezelfde vragen nog eens gesteld maar dan worden de
in het college aangeleerde technieken toegepast.
Onderwerpen van college
● Belang en oorzaken van software maintenance en software evolution; het
onderhoudsproces. De noodzaak tot renovatie.
● Termherschrijven; ASF+SDF als specificatiemiddel voor analyse en transformatie
● Feitenextractie; Relational calculus; Rscript als specificatiemiddel voor het
analyseren van feiten.
● Toepassen deze technieken op diverse cases.
Opzet en onderwerpen van het practicum
● Serie 1: Beantwoorden van een tiental vragen over een bestaand systeem, in de
eerste drie jaar Java's Abstract Windowing Toolkit (AWT), in het laatste jaar een
Wikisysteem.
● Serie 2: Gebruik van ASF+SDF:
• Enkele eenvoudige opgaven op het gebied van termherschrijven en logica.
• Uitbreiden van een eenvoudige programmeertaaltje met een nieuwe constructie
en aanpassen van een gegeven typechecker.
● Serie 3: Gebruik van Rscript:
• Eenvoudige opgaven om vertrouwd te raken met Rscript.
• Dezelfde vragen als uit serie 1 maar nu op te lossen m.b.v. Rscript
Opzet en onderwerpen van de papersessie
12-FEB-07 Appendix B. Overzicht Vakken 53

In de paper sessies zijn recente artikelen besproken uit relevante conferentieproceedings
zoals Conference on Software Maintenance and Renovation (CSMR), Working
Conference on Reverse Engineering (WCRE), en anderen. Daarbij komen onderwerpen
aan de orde als metrieken, feitenextractie, clustering van feiten, en softwaretransformaties.
Volgens de opzet van de papersessies moeten de besproken artikelen vanuit verschillende
gezichtspunten besproken worden.
Toetsing
De toetsing vindt plaats door:
● Beoordeling praktikumopdrachten.
● Beoordeling papersessie.
● Beoordeling schriftelijk tentamen.
Literatuurlijst
● M.G.J. van den Brand & P. Klint, User Manual ASF+SDF Meta-Environment.
● P. Klint A tutorial introduction to Rscript: a relational approach to software
analysis.
● Papers uit een aantal conferenties op dit gebied, zoals International Conference on
Software Maintenance (ICSM), Conference on Software Maintenance and
Renovation (CSMR), en International Workshop on Program Comprehension
(IWPC).
Referentie naar vergelijkbare colleges
Delen van dit college zijn eerder gebruikt in het college Programming Environments in de
Mastersopleidingen Computer Science en Grid Computing.
Evaluatie door studenten en docenten
De studenten zijn positief over dit college en melden veel geleerd te hebben (zie blz. 45).
De hoeveelheid stof in dit college is erg groot en zowel docenten als studenten vinden het
jammer dat aan bepaalde onderdelen niet meer aandacht besteed kan worden.
Belangrijkste verbeterpunten
Er zijn reeds een aantal wijzingen doorgevoerd om de onderdelen nog beter op elkaar af te
stemmen. Op dit moment is er geen tijd om de feitenextractie zoals die nodig is in
praktikumserie 3 door de studenten uit te laten voeren. Bij sommige studenten blijkt de
voorkennis toch iets te mager, i.h.b. bijzonder op het gebied van taalontwerp en
compilerconstructie. Dit zou wellicht opgevangen kunnen worden door nog een aantal
extra theoriecollege's in te lassen. Daarnaast hebben we er in het huidige studiejaar voor
gekozen om dezelfde case te gebruiken (source code van een Wikisysteem) voor dit
praktikum en voor het praktikum bij het gelijktijdig gegeven vak Software Architectuur.
Hierdoor is er meer tijd voor het bestuderen van de code en ontstaat er meer samenhang
tussen beide vakken.
B2. Software Architecture
Motivering
In een software architectuur worden de eerste, belangrijke, ontwerpbeslissingen
vastgelegd. Bij het bepalen van de architectuur worden afwegingen gemaakt tussen
functionele en niet-functionele (kwaliteits) eisen van alle betrokkenen, teneinde een
afgewogen globaal ontwerp voor het systeem te verkrijgen. Centrale boodschap is dat er
12-FEB-07 Appendix B. Overzicht Vakken 54

niet één beste ontwerp is, maar dat verschillende keuzes met betrekking tot het pakket
eisen tot alternatieve oplossingen leiden.
Te verwerven competenties
● Inzicht in de problematiek rondom Software Architectuur.
● Begrip van de plaats van Software Architectuur binnen systeemontwikkeling.
● Kennis van enkele methoden en technieken voor het ontwerpen, documenteren en
beoordelen van een software architectuur.
● Vaardigheden om verschillende “viewpoints” van een software architectuur te
ontwerpen en bijbehorende “views” te documenteren.
● Vaardigheden om een architectuur te beoordelen.
Opzet van het vak
Tijdens het college worden presentaties van studenten afgewisseld met hoorcolleges over
de theorie. De behandelde theorie wordt in groepjes toegepast op een casus, en de
resultaten daarvan worden gepresenteerd en besproken. De globale lijn is dat de
achitectuur van een bestaand systeem eerst wordt gereproduceerd uit de code. Dit leidt tot
een eerste representatie (view) van de architectuur. Vervolgens worden additionele views
gemaakt, worden belangrijke ontwerpbeslissingen gedocumenteerd, en tenslotte
beoordelen studenten elkaars architectuurbeschrijvingen. Twee colleges worden verzorgd
door ervaren software architecten, welke vertellen over hun ervaringen, en de rol die
architectuur in hun organisatie speelt.
Onderwerpen van college
● Wat is software architectuur, waarom is dit belangrijk.
● Hoe ontwerp je een architectuur.
● Hoe documenteer je een architectuur m.b.v. views en viewpoints.
● Hoe leg je ontwerpbeslissingen vast.
● Wat is de relatie tussen software kwaliteit en software architectuur.
● Hoe beoordeel je een architectuur.
Opzet en onderwerpen van het practicum
De studenten krijgen na het eerste college een flink stuk software, en worden geacht de
architectuur daarvan te herontdekken. Deze wordt in eerste instantie in een enkele view
gedocumenteerd. Vervolgens moeten de studenten nog twee andere views voor deze
architectuur bedenken en documenteren. Daarna identificeren zij belangrijke
ontwerpbeslisingen en documenteren die. Vervolgens moeten de studenten vier
“architectural tactics” bedenken voor een gegeven kwaliteitsattribuut., en twee hiervan
toepassen op de architectuur. Tenslotte beoordelen zij elkaars architectuurbeschrijvingen
met een scenario-gedreven methode.
Papersessie
Er zijn 9 papers geselecteerd die te categoriseren zijn in drie thema’s. Elke groep studenten
krijgt 1 thema toegewezen dat ze moeten uitdiepen aan de hand van de drie aangeleverde
papers. Het is de eerste paperopdracht voor de studenten (eerste blok). De focus ligt op het
begrijpen van de aangeleverde papers. Daartoe moeten de studenten de 3 papers
gestructureerd lezen en hierover een vragenlijst invullen. Vervolgens dient iedere student
een paper uit te kiezen en zich hier een mening over te vormen. Ten slotte moet de student
deze mening onderbouwen of aangeven hoe deze mening onderbouwd kan worden.
De studenten geven binnen hun themagroep een korte presentatie aan elkaar. De beste
wordt uitgekozen om klassikaal te behandelen. Een vertegenwoordiger van elke groep
12-FEB-07 Appendix B. Overzicht Vakken 55

presenteert. De klassikale presentatie bestaat uit een korte samenvatting van het thema
d.m.v. de drie papers en een presentatie van de meest interessante mening. De presentaties
vinden plaats voor een docentenforum dat vragen stelt en in een “Idols”-achtige setting een
oordeel over de presentaties geeft. Hierdoor krijgt de hele groep een gevoel bij de
kwaliteit. De beste presentatie wordt door de studenten uitgekozen. Het werk is verder
individueel, maar elke vrijdag wordt er twee uur groepsgewijs aan besteed in een
workshopachtige setting onder begeleiding van een docent.
Toetsing
Een deel van het eindcijfer wordt bepaald door de wekelijkse documenten met
practicumresultaten. Een deel via een schriftelijk tentamen. Voor het tentamen is een,
vergelijkbaar, proeftentamen beschikbaar.
Literatuurlijst
Voor het theoriedeel gebruiken we Len Bass et al, Software Architecture in Practice,
second edition, Addison-Wesley, 2003. In de slides van het vak is verder nog materiaal uit
IEEE 1471 (standaard voor architectuurdocumentatie) gebruikt, en materiaal uit eigen en
andermans research.
Evaluatie door studenten en docenten
Goed, zie blz. 45.
Belangrijkste verbeterpunten
Zoals al aangegeven bij Software Construction wordt inmiddels een gezamenlijke case
gebruikt.
B3. Requirements Engineering
Motivering
Het goed opstellen van requirements is een van de lastigste onderdelen van de Software
Engineering, tegelijkertijd is het niet goed opstellen van requirements een van de
belangrijkste redenen waarom software projecten mislukken.
Te verwerven competenties
● Kennis van actuele theorie op gebied van Requirements Engineerig en User
Centered Design
● Kennis van Michael Jackson Problem frames en inzicht in hoe dit gebruikt kan
worden bij Requirements Engineering
● Inzicht in de problematiek rondom Requirements Engineering.
● Het kunnen verwerven van kennis en inzicht in een bedrijfssituatie.
● Kunnen structureren van grote hoeveelheden informatie
● Kunnen uitvoeren van gestructureerde analyse van het probleemdomein
● Vaardigheden om een Requirementspecificatie te schrijven en te beoordelen.
● Inzicht in de toegepaste en uitgediepte best practices en theorie.
Opzet van het vak
Eerst wordt gezorgd voor een sterke theoretische basis. Hiertoe dienen studenten het boek
en een zestal papers te lezen. Daarnaast wordt er gedurende het hele blok tweewekelijks
college gegeven. De verworven kennis wordt na drie weken getoetst.
Studenten passen deze kennis vervolgens toe in een practicum. Het practicum vindt plaats
in een bedrijfsomgeving met echte belanghebbenden. Hierdoor ervaart de student aan den
lijve wat de problemen zijn en hoe lastig het is om de technieken toe te passen.
12-FEB-07 Appendix B. Overzicht Vakken 56

Tijdens het practicum is er begeleiding vanuit de docent in coachende vorm. Tijdens deze
begeleiding en in de colleges in deze periode wordt voor de studenten het verband
duidelijk tussen de theorie en de eigen practicum ervaring.
De paper opdracht versterkt het leereffect. De student verdiept zich in een van de aspecten
die tijdens het practicum naar voren zijn gekomen.
Onderwerpen van college
● Overzicht:
o Wat is (het belang van) requirement engineering.
o Inzicht in problematiek.
o Development: Elicitatie, Analyse, Documentation, Validation
o Management: Change and version control, Tracing, Tooling
o Elicitatie technieken
● Methode Wiegers
● Contextual Design
● Introduction to Problem solving (Polya)
● Michael Jackson Problem Frames
● Collaborative workshops
● Documentatie
● Validatie
● Prototyping
Opzet en onderwerpen van het practicum
Er zijn twee verschillende cases met echte opdrachtgevers. Studenten dienen zelf
requirements te achterhalen en te documenteren. Daarbij zijn ze in de rol van adviseur, die
niet alleen opschrijft wat de opdrachtgever zegt en wil, maar vooral kijkt naar wat er nodig
is en waarom dit nodig is. Hiervoor is de opdrachtgever per groep zes uur beschikbaar
gedurende drie weken. De eerste twee weken kan de groep zich voorbereiden.
De requirements specificatie wordt opgeleverd aan een andere groep, die met de andere
case bezig was. Deze groep moet de requirements valideren en een prototype bouwen. De
enige informatie bron is het document. De resultaten van deze groep worden gepresenteerd
aan de opdrachtgever en aan de groep die de requirements heeft opgesteld.
Toetsing
Tentamen, practicum en paper.
Literatuurlijst
Ten behoeve van studenten:
● Karl Wiegers. Software requirements, Second Edition, Microsoft Press, 2003.
● Contextual Risk Analysis for Interview Design Tira Cohene and Steve Easterbrook
● Participatory Development, Structure in the toolbox Finn Kensing and Andreas
Munk-Madsen June 93/Vol. 36, No 4 Communications of the ACM.
● Contextual Design, Beyer and Holtzblatt, interactions, 1999
● Apprenticing with the Customer, Beyer and Holtzblatt, Communications of the
ACM, May 1995/Vol. 38, No. 5
● Designing for Usability: Key principles and what designers think, Gould and
Lewis, Communications of the ACM, March 1985/Vol. 28, No. 3
● Task Descriptions as functional requirements, Lauesen, IEEE, 2003
12-FEB-07 Appendix B. Overzicht Vakken 57

Ten behoeve van ontwikkeling collegemateriaal:
● Ian Sommerville, Pete Sawyer Requirements Engineering: A Good Practice Guide
Addison Wesley.
● Gerald Kotonya, Ian Sommerville. Requirements Engineering : Processes and
Techniques Wiley.
● Alistair Sutcliffe User-Centred Requirements Engineering. Springer
● Yourdon, Structured Analysis, Prentice Hall.
● Rumbaugh ao. Object-Oriented Modeling and Design, Prentice Hall.
● Jackson, Software Requirements & Specifications, Addison-Wesley.
● Alexander, Writing better requirements, Addison-Wesley.
● Lausen, Software Requirements – Styles and Techniques
● Holtzblatt, Contextual Design
Daarnaast is veel paper materiaal gebruikt. Hier worden de belangrijkste overzichtpapers
genoemd:
● Papers opgenomen in de proceedings van de 13th IEEE international Requirements
Engineering conference dd 2005.
● Päivi Parviainen, Hanna Hulkko, Jukka Kääriäinen, Juha Takalo & Maarit Tihinen;
Requirements engineering: Inventory of technologies; VTT PUBLICATIONS 508.
● Technical Report RE Group; TR-2003-01; Aug. 2003; Evaluating the
Requirements Engineering Process Using Major Concerns; Li Jiang, Armin
Eberlein, Behrouz Homayoun Far.
Referentie naar vergelijkbare colleges
● Requirements Management and Systems Engineering, A. Katasonov, University of
Jyväskylä, Finland.
● Human-Computer Interaction; Year Two; Undergraduate Course; Department of
Informatics; University of Sussex 2005-06; John Halloran.
● Lectures van Ian Sommerville Lancaster University.
Evaluatie door studenten en docenten
Positief, zie blz. 45
Belangrijkste verbeterpunten
● Meer focus in de colleges (minder slides / onderwerpen).
● Gestructureerd aanleren conceptueel modelleren.
● Spreiden leeswerk over grotere periode
B4. Software Testen
Motivering
Testen is in de praktijk het moeilijkste, duurste en meest arbeidsintensieve onderdeel van
het software-ontwikkelproces. Het testen van software systemen is van groot belang om te
verifiëren dat een systeem het gewenste gedrag vertoont en te valideren dat het systeem
beantwoordt aan de requirements.
Om te kunnen nagaan of aan bepaalde requirements is voldaan is het van belang om die
eisen te kunnen specificeren. Dat kan gebeuren in natuurlijke taal, in een of andere
domein-specifieke taal, of in een formele specificatietaal. Daarmee wordt het onderwerp
verbreed tot specificeren en testen. Om testen te kunnen integreren in een softwareontwikkelproces
(van requirements analyse tot implementatie), moet testen worden
verweven met code-ontwikkeling. Hier gaat testen samen met debuggen en met het
12-FEB-07 Appendix B. Overzicht Vakken 58

gebruik van `unit test' en regressie test technieken. Een derde onderwerp dat in de cursus
aan de orde komt is het achteraf valideren van systemen van derden, waarbij het testen zelf
als proces wordt beschouwd, met een heel scala van beschikbare technieken.
Te verwerven competenties
● Opstellen kwaliteitseisen.
● Maken van formele specificaties.
● Nagaan of code aan een formele of informele specificatie voldoet.
● Overzicht krijgen van diverse testtechnieken (proces en produkt).
● Selecteren van testtechnieken.
● Zelf testtechnieken uitvoeren en over uitgevoerde testen helder rapporteren.
● Testtechnieken integreren in het softwareontwikkelproces.
● Gevonden fouten in de eigen code op systematische wijze herstellen.
Opzet van het vak
(NB: Naar aanleiding van de ongunstige evaluatie in voorgaande jaren
is het vak dit jaar grondig op de schop genomen. We beschrijven hier
de nieuwe opzet, die in de cursus van november/december 2006 voor het
eerst is gevolgd.)
Drie hoofdonderwerpen:
● Leren gebruiken van de formele specificatietaal Alloy en de hiervoor
beschikbare tools. Hoe schrijf je een specificatie in Alloy? Eerst
voor eenvoudige modellering (specificeren van het metronet van
Amsterdam), dan voor graaf algoritmen (het google algoritme voor het
ordenen van knopen in een graaf naar belangrijkheid, algoritmen voor
het vinden van een minimum spanning tree in een graaf, enzovoorts), en
tenslotte voor het modelleren en testen van aspecten van eigen
software design.
● Leren kennen en gebruiken van technieken voor integratie van testen in
het softwareontwikkelproces. Hierbij gaat het om het ontwikkelen van
testbare software, en het gebruiken van interactief testen om het
ontwikkelproces te verbeteren. Dit onderwerp komt aan de orde in
oefeningen met unit testing, met specificatie-gebaseerd testen, en met
wetenschappelijke debugging technieken.
● Ontwikkelen en uitvoeren van acceptatietests. Hierbij gaat het om het
vormen van een oordeel over de kwaliteit van bestaande software
pakketten, waarbij de source code al dan niet beschikbaar kan zijn.
Dit onderwerp wordt belicht middels het aanleren van technieken uit de
praktijk van het acceptatietesten.
12-FEB-07 Appendix B. Overzicht Vakken 59

Onderwerpen van het college
● Overzicht van test-technieken; grondslagen van testen.
● Formele specificatie en testen.
● Precondities, postcondities en invarianten.
● Testen en (wetenschappelijk) debuggen.
● De logische basis van Alloy.
● Formele specificaties testen met Alloy.
● Specificeren van algoritmen met Alloy.
● Design by Contract en testen.
Opzet en onderwerpen van het practicum
Week 1: Unit Test leren gebruiken, Alloy tutorial doorwerken,
Eenvoudig testrapport leren opstellen
Week 2: Literatuurstudie testtechnieken en testjargon. Practicum-oefening
met Alloy: maak een formele specificatie van familierelaties,
waarin begrippen als `ouder', `grootouder', `vader', `moeder',
`stiefvader', `stiefmoeder', `broer', `zus', `oom', `tante',
`voorouder', `kind', `kleinkind', `neef', `nicht' moeten voorkomen.
Week 3: Literatuurstudie, plus Alloy specificatie opdracht: maak een
formele specificatie van het Amsterdamse metronet, en zorg dat
je met de specificatie kunt nagaan hoeveel maal overstappen er
nodig is om van A naar B te komen.
Week 4: Maak een bugrapportage voor een bug die je hebt gevonden in
het Alloy systeem, volgens de methode uit het boek van Zeller.
Maak een Alloy specificatie voor een ring. Completeer en test
een Alloy specificatie voor sudokus.
Week 5: Practicumopdracht Scientific Debugging.
Een formele specificatie maken voor een internet dating programma.
Week 6: Practicumopdracht Scientific Debugging.
Werk een Alloy specificatie van Prim's algoritme voor het
vinden van een minimum spanning tree verder uit.
Week 7: Practicum opdracht delta debugging. Literatuurstudie over
acceptatietesttechnieken.
Toetsing
Huiswerkopdrachten en schriftelijk tentamen.
Literatuurlijst
● Daniel Jackson, Software Abstractions, Logic, Language and Analysis, MIT Press,
2006.
● Andreas Zeller, Why Programs Fail; A Guide to Systematic Debugging, Morgan
Kaufmann, 2005.
12-FEB-07 Appendix B. Overzicht Vakken 60

Verwijzingen naar vergelijkbare colleges
● http://www.testingeducation.org/ Deze website geeft tal van interessante
verwijzingen, bij voorbeeld naar een universitaire eindtoets Software Testing van
Florida University of Technology.
(http://blackbox.cs.fit.edu/blog/kaner/archives/000008.html).
● http://www.win.tue.nl/~jromijn/2IW30/ Master course Software Testing aan de
Technische Universiteit Eindhoven.
Evaluatie door studenten en docenten
Studentenevaluatie: de studenten geven dit vak in 2005/06 het gemiddelde rapportcijfer
5.43. Dat is dus net)geen voldoende. Dit oordeel geeft aan dat verbetering zeker nodig is.
Hieronder besteden we eerst aandacht aan wat goed ging, en daarna uitvoeriger aan wat
niet goed ging. Bij alle verbeterpunten noemen we een aantal mogelijke remedies. die
inmiddels doorgevoerd zijn in het vak zoals dat in het najaar 2006 gegeven is. Globale
verandering: waar eerst zowel het testproces als ook specifieke testtechnieken behandeld
werden (door twee verschillende docenten) is het vak nu technischer en ook homogener
gemaakt en wordt bovendien door één docent gegeven. Verder is betere toolondersteuning
bij de praktica beschikbaar.
Het vernieuwde college is ontstaan op grond van de volgende analyse van de resultaten
van het college in 2005-2006.
Wat goed ging:
● Nuttige vaardigheden geleerd. Oefenen met unit test. Voor sommigen:
kennismaking met functioneel programmeren. Anderen noemden: oefenen met
het opstellen van een acceptatietestrapporten.
● Goede feedback op resultaten. De practicum-resultaten werden uitvoerig besproken
en van commentaar voorzien op het college. Dit werd door studenten
gewaardeerd.
● Veel achtergrondmateriaal beschikbaar gekregen. Er is veel tijd en energie
gestoken in het samenstellen van een uitvoerige syllabus. Dit werd door
verscheidene studenten zeer gewaardeerd, al klaagden anderen dat allerlei papers
uit de reader in de colleges niet of nauwelijks aan de orde kwamen.
Wat minder goed ging. We geven hieronder kort commentaar op de hoofdproblemen die in
de evaluatie worden geconstateerd.
● Gebrek aan coherentie. Invalshoek van de twee docenten was zeer verschillend, en
dat was tijdens de colleges te merken. Er bestaat uiteraard een natuurlijk verband
tussen specificatie-gebaseerd testen en requirements engineering, maar dat verband
werd in de cursus Software Testing niet uitgewerkt.
Mogelijke remedies: meer vooroverleg tussen de docenten, of het docententeam
anders samenstellen. Tijdens het college explicieter behandelen wat de
verschillende onderdelen met elkaar te maken hebben. Veelheid van onderwerpen
terugbrengen, en in de cursus expliciet aandacht besteden aan verbanden met RE.
Verder valt te overwegen om het college te splitsen in twee onderdelen: technieken
voor acceptatietesten en technieken voor specificatie-gebaseerd testen. Deze twee
12-FEB-07 Appendix B. Overzicht Vakken 61

hoofdonderwerpen van een cursus Software Testing zijn immers min of meer
onafhankelijk van elkaar.
● Mix tussen theorie en praktijk niet optimaal. Theorie van verschillende
testmethoden werd wel behandeld, maar met niet alles daarvan werd in de praktijk
geoefend. Mede daardoor ging de theorie soms te snel.
Op dit punt zijn de aanbevelingen van de studenten niet eensluidend. Sommigen
bepleiten het college te focussen op testmethoden uit de praktijk, anderen vinden
juist dat de focus duidelijker op de fundamentele zaken moet worden gericht:
``Zaken als T-map, acceptatietesten etc. komen in de praktijk wel terug.''
Mogelijke remedie: Meer specifieke oefeningen met verschillende testmethoden,
de relevantie laten zien van eenvoudige logische theorie voor de praktijk van het
testen, en het toepassen van deze theorie ook onderdeel maken van de practica.
Kleine oefeningen met het opstellen en testen van specificaties voor een OO taal of
een imperatieve taal onderdeel maken van het practicum.
● Practica sloten niet goed aan op de colleges. De practicumopdrachten besloegen
maar een deel van de collegestof, en legden daardoor een eenzijdige nadruk.
Mogelijke remedie: Practicumopdrachten zo formuleren dat ze echt (uitsluitend)
betrekking hebben op testen en specificeren. Betere mix maken van kleine
oefeningen om de theorie te illustereren en grotere opdrachten om kennis te maken
met het opstellen van acceptatie-testrapporten.
● Gebrek aan begeleiding bij de practica. De begeleiding bij de practica was
minimaal. De docenten bepaalden zich tot het oplossen van opstartproblemen, en
waren bereikbaar voor consultatie per email. Hiervan werd nu en dan gebruik
gemaakt, maar enkele studenten gaven te kennen dat een email consult geen
vervanging is voor persoonlijke begeleiding. De begeleiding bij ASF+SDF sessies
werd wat dit betreft als lichtend voorbeeld genoemd.
Oorzaak: Gebrek aan mankracht. Mogelijke remedie: student-assistent of aio
hiervoor inzetten. Voortaan cijfers toekennen voor ingeleverde
practicumopdrachten ipv alleen +, +/- of -.
● Cursusinhoud veronderstelt niet aanwezige vaardigheden. Studenten verslikten zich
in de Haskell vaardigheden die in (te) korte tijd moesten worden aangeleerd.
Blijkbaar ontbrak de abstracte kijk die voor het snel oppakken van een nieuwe
functionele programmeertaal (naast ASF+SDF) nodig is. Verbanden tussen
ASF+SDF en Haskell werden niet gezien. Aan het echt oefenen met QuickCheck
(de random test generator voor Haskell) kwam men veelal niet toe omdat het lezen
en begrijpen van de functionele notatie nog teveel moeilijkheden opleverde.
Mogelijke remedies: Haskell voortaan weglaten. Een andere mogelijkheid waar
door een aantal studenten voor gepleit wordt: Haskell en logica training voortaan
vooraf laten gaan aan het college Software Testen, in een aparte module.
● Cursusmateriaal weinig overzichtelijk. Kopieerkwaliteit van de cursusreader was
hier en daar slecht. Ook bevatte de reader zoveel materiaal dat lang niet alles in de
colleges aan de orde is geweest.
12-FEB-07 Appendix B. Overzicht Vakken 62

Mopelijke remedies: reader beknopter maken, en zorgen dat alles leesbaar wordt
gereproduceerd. Een andere mogelijkheid is de cursus voortaan te baseren op een
geschikt tekstboek.
Andreas Zeller, Why programs fail? overdekt een deel van de stof zeer goed, maar
laat de heuristiek van het testen (hoe ontdek ik fouten in een programma?) buiten
beschouwing. Maar Zeller aangevuld met een of twee colleges over testmethodiek
(bij voorbeeld gebaseerd op de Tmap methode) zou een goede basis kunnen zijn
voor een vernieuwde cursus Software Testen.
● De toetsing tijdens het tentamen was eenzijdig. Tentamen gaf weinig aandacht aan
testtechnieken, testplannen, enzovoort. Het werd te laat duidelijk hoe de
practicumresultaten werden meegewogen in het eindcijfer.
Oorzaak: Dit was een open boek tentamen. Kennis over hoe bepaalde
testtechnieken in elkaar zitten kan bij zo'n tentamen niet worden getoetst.
Mogelijke remedies: geen open boek. Practicumopdrachten beoordelen met cijfer.
Vantevoren specificeren hoe zwaar het practicumresultaat meetelt.
B5. Software Constructie
Motivering
Softwareconstructie beoogt om abstractere beschrijvingen van een systeem zoals ontwerp
en architectuur om te zetten in een goed werkend systeem dat aan gegeven functionele en
niet-functionele eisen voldoet. Het vak software constructie houdt zich bezig met
methoden en technieken die specifiek gericht zijn op de programmeer- en
implementatie-activiteiten van een software engineering project. Het is de volgende fase in
het programmeren. Voorbeelden van zulke activiteiten zijn coding en debugging, detailed
design, unit testing,reviews op andermans code, optimalisaties, component integratie,
enzovoort. Dit vak beoogt om de student enerzijds op de hoogte te stellen van de best
practices op dit gebied en anderzijds een aantal geavanceerde technieken aan te leren op
het gebied van component-based software engineering en programmageneratie.
Te verwerven competenties
● Kennis van de principes van programmageneratie. Toepassing van de ASF+SDF
Meta-Environment als hulpmiddel voor programmageneratie. Vaardigheid in het
toepassen van programmageneratoren.
● Kennis van de principes van component-based systems. Kennis van de ToolBus
coordination architectuur om dergelijke systemen te realiseren. Vaardigheid om
deze techniek in concrete gevallen toe te passen.
● Kennis van de best practices van software constructie.
Opzet van het vak
Het vak bestaat uit een hoorcollege, praktikum, papersessies en een boek dat als
achtergrondmateriaal dient.
Onderwerpen van college
● Programmageneratoren.
● Component-based systems; de ToolBus coordinatie architectuur.
Opzet en onderwerpen van het practicum
12-FEB-07 Appendix B. Overzicht Vakken 63

● Serie 1: Gebruik van de programmagenerator APIGEN.
● Serie 2: Gebruik van de ToolBus.
Opzet en onderwerpen van de papersessie
In de paper sesssies is aandacht besteed aan papers op drie gebieden: Aspect-oriented
programming, Design patterns, en Code generation. Uitgaande van een toegewezen paper
moet de student daarbij een vraagstelling gerelateerd aan het paper formuleren, daar
literatuur bij zoeken, en in een beschouwing uitwerken en aan de medestudenten
presenteren. In drie workshops wordt eerst een inleiding gegeven tot een van de drie
gebieden en daarna worden door studenten hun resultaten gepresenteerd.
Toetsing
De toetsing vindt plaats door:
● Beoordeling van de uitgewerkte praktikumopgaven.
● Beoordeling van het gepresenteerde paper.
● Een aantal korte schrfitelijke toetsen over het achtergrondmateriaal (Code
Complete)
Literatuurlijst
● J. Herrington, Code Generation in Action, 2003.
● S.C. McConnell, Code Complete, 2 nd Edition, 2005.
● Technische documentatie van APIGEN en ToolBus.
● Papers uit relevante conferenties en tijdschriften zoals International Conference on
Software Engineering (ICSE), International Conference on Object-Oriented
Programming, Systems, Languages and Applications (OOPSLA), Software
Practice and Experience, en Science of Computer Programming.
Referentie naar vergelijkbare colleges
Delen van dit college zijn eerder gebruikt in het college Programming Environments in de
Mastersopleidingen Computer Science en Grid Computing.
Evaluatie door studenten en docenten
Dit vak wordt positief beoordeeld (zie blz. 45).
Belangrijkste verbeterpunten
Om nog betere synergie in het curriculum te krijgen is besloten om in het huidige
studiejaar de practica van de vakken Software Constructie en Software Proces met elkaar
te integreren. Het eerste deel van het practicum richt zich nu op het aanleren van de
ToolBus architectuur. Het tweede deel valt samen met het practicum Software Proces en
richt zich (dit jaar) op het bouwen van visualisatietools voor software-analyses. Op deze
manier kunnen de inzichten die aangeleerd worden bij Software Constructie direct
toegepast worden in software van een realistische omvang. Hierdoor wordt de aandacht
van de studenten ook minder versnipperd en is het leereffect groter.
B6. Software Proces
Motivering
Het managen van de ontwikkeling van software moet niet uitsluitend worden onderwezen
vanuit een theoretische achtergrond. Er bestaat aardig wat literatuur over het
ontwikkelproces, waarvan een deel is gebaseerd op de beschrijving van de uit te voeren
taken en de op te leveren onderdelen. Veel belangrijker is het kunnen ervaren van de
verschillende problemen die zich bij de ontwikkeling van software kunnen voordoen.
12-FEB-07 Appendix B. Overzicht Vakken 64

Daarbij is van belang om te zien dat ontwikkelen vooral gaat om het managen van mensen
en het bewaken van de doelstellingen van een project.
Studenten krijgen in dit onderdeel de gelegenheid om in een echt project mee te maken wat
het betekent om een complex software project uit te voeren en te ontdekken hoe moeilijk
het is om een groep mensen samen op effectieve wijze aan hetzelfde project te laten
werken. Met name de onderlinge communicatie, het vaststellen van de doelstellingen van
de klant en het bewaken van de voortgang en de realisatie van de doelstelling zijn het
onderwerp van dit module.
Te verwerven competenties
● Inzicht in ontwikkelingen op het gebied van Software Proces.
● Inzicht in de problematiek die door de verschillende methodes en practices moet
worden opgelost.
● Inzicht in hoe goed een aantal van deze methodes deze problemen oplossen.
● Kennis van methodes om te plannen, schatten, testen, ontwikkelen en opleveren en
hoe dit op elkaar afgestemd kan worden.
● Inzicht in de principes van moderne lichtgewicht methodes zoals eXtreme
Programming en Interaction Design en hoe je deze kunt gebruiken om goede
software op een klantvriendelijke, effectieve en efficiënte manier te ontwikkelen.
Opzet van het vak
In de colleges worden de belangrijke aspecten in het software proces behandeld. Dit
gebeurt aan de hand van problemen die veelvuldig voorkomen. Er wordt behandeld hoe
deze problemen kunnen worden opgelost met de principes van Interaction Design en
Iteratief Ontwikkelen (XP).
In een uitgebreid practicum vormen de studenten een eigen software huis waarin een
management team wordt samengesteld en verschillende disciplines met elkaar gaan
samenwerken aan de ontwikkeling en uitbreiding van een complex software project. Er
zijn architecten, interaction designers, ontwikkelaars, testers en auditors aan het werk.
Daarnaast wordt aandacht besteed aan marketing, contact met de klant, maken van
documentatie en de presentatie naar de klant. Op deze manier komen de in de colleges
besproken problemen naar voren en worden in de praktijk ervaren. De studenten dienen
deze problemen zoveel mogelijke zelfstandig op te lossen door het opzetten en uitvoeren
van een proces dat op XP / ID principes gebaseerd is.
Het vak wordt afgesloten met een betoog / onderzoek van de studenten. Hierin wordt
gereflecteerd op het practicum en wordt een onderdeel van het proces nader uitgediept.
Onderwerpen van de colleges
● Intro+Historie.
● Offerte.
● Specificaties.
● Planning.
● Testen.
● Ontwikkeling.
● Opleveren.
12-FEB-07 Appendix B. Overzicht Vakken 65

Opzet en onderwerpen van het practicum 24
Als voorbeeld wordt een real-time robot simulator gebruikt, die is ontwikkeld door AI
studenten van de Universiteit van Amsterdam. Hierbij krijgen de Software Engineering
studenten te maken met een systeem, waarin aspecten voorkomen, die in administratieve
systemen ongebruikelijk zijn. Het gevolg is dat zij zich in korte tijd enkele complexe
benaderingen eigen moeten maken en de opzet van het systeem moeten zien te
doorgronden. Daarin spelen met name de architecten en interaction designers een
belangrijke rol. Ontwikkelaars kunnen daardoor niet direct aan de slag of lopen het risico
later in het project tegen ernstige problemen aan te lopen. Vanaf het begin van het project
is duidelijk dat de onderlinge communicatie een groot probleem kan veroorzaken.
De aangeboden software moet verder worden ontwikkeld en verbeterd. Hiertoe hebben de
studenten direct toegang tot gebruikers als de opdrachtgever / eigenaar van het software
pakket. De studenten dienen bugs op te lossen, de software te verbeteren en nieuwe
features toe te voegen. Het proces dienen ze zelf in te richten. Hiervoor worden door de
opleiding een aantal richtlijnen / handvatten gegeven, zoals functiehuis, planning van de
eerste activiteiten, lijst met op te lossen bugs. Om een maximaal leereffect te bereiken
wordt de verantwoordelijkheid voor het proces bij de afdelingen gelegd en niet bij het
management. Het softwarehuis doorloopt een aantal fases die aansluiten op de gegeven
colleges.
Gedurende de uitvoering van het module wordt wekelijks of tweewekelijks een onderdeel
opgeleverd, waarbij voor iedere ‘iteratie’ een volledige planning en rapportage moet
worden opgeleverd en een compleet werkend systeem inclusief de bijbehorende
documentatie wordt verwacht.
Opzet en onderwerpen van de papersessie
Het vak wordt afgesloten met een individuele paperopdracht. De student dient afstand te
nemen en met een helikopterblik naar het software huis te kijken. Daarmee kan de student
laten zien dat hij / zij de collegestof begrepen heeft en weet toe te passen in een analyse.
Ook dient de student op een zelf te selecteren onderdeel van het ontwikkelproces de diepte
in te gaan. Dit vereist analyse vaardigheden en het leren beheersen van een bepaalde
techniek en die in een breder kader kunnen plaatsen. Hiertoe moet de student de
aangeboden literatuur actief gebruiken en als dit niet toerijkend is, relevante literatuur
zoeken.
Toetsing
De toetsing of de stof in het college begrepen en beheerst wordt vindt plaats door middel
van het practicum en het te schrijven paper. In het practicum wordt ook getoetst of de
student over de juiste vaardigheden beschikt. Het paper toetst inzicht, analyse
vaardigheden en of de student op een goede manier technieken kan analyseren en
beoordelen. Voor iedere afdeling van het softwarehuis wordt per iteratie een beoordeling
gemaakt en een cijfer toegekend. Het management wordt apart beoordeeld op de resultaten
van hun afdelingen.
Literatuurlijst
● K. Beck, Extreme Programming explained (Second edition).
● A. Cooper, The Inmates are running the Asylum.
24 Deze bescrhijving betreft het college 2005-2006. In 2006-2007 is in combinatie met het practicum voor
Sofware Constructie een andere case gebruikt (software visualisatie). De bescrheven opzet is gelijk
gebleven.
12-FEB-07 Appendix B. Overzicht Vakken 66

Verder wordt bij elk college een lijst van relevante en interessante literatuur gegeven. Ook
worden een aantal papers beschikbaar gesteld met inzichten die voor het halen van het
practicum van belang zijn.
Referentie naar vergelijkbare colleges
Er blijkt al eerder een vergelijkbare opzet te zijn uitgeprobeerd, beschreven in: “Teaching
a Software Development Methodology” (Hazzan, Orit eb Yael Dubinsky). Een van de
studenten heeft als verdiepend paper een vergelijking gemaakt tussen de door ons
gevolgde opzet en die uit dit paper. Het blijkt dat met name het in de praktijk ervaren van
de verschillende problemen inzichten verschaft, die met alleen collegestof niet te bereiken
zijn. Een belangrijk verschil van onze benadering is dat de studenten meer vrijheid hebben
bij het toepassen van verschillende technieken en het beschrijven van hun ervaringen. In
de benadering van Hazzan et al wordt bijvoorbeeld dagelijks een reflectie geëist en worden
de verschillende methoden afgedwongen. Zo zijn studenten verplicht om pair
programming toe te passen, waardoor ze in ieder geval enige ervaring met de benadering
opdoen. In onze opzet hebben de studenten een veel grotere mate van vrijheid, waarbij ook
verschillende technieken binnen het project door elkaar gebruikt worden en de studenten
hun ervaringen onderling kunnen uitwisselen.
Evaluatie door studenten en docenten
Eerste jaar rapportcijfer studenten: 6.77, tweede jaar rapportcijfer: 6.4.
In het eerste jaar was het vak vooral theoretisch. De docent had een beperkte ervaring. Het
tweede jaar is het vak behoorlijk veranderd. Er is een zeer ervaren docent gekomen. Ook is
een practicum ontwikkeld zodat studenten met de gegeven stof aan de slag konden en aan
den lijve konden ondervinden wat de problematiek was. Tijdens dit practicum werd er
geen software ontwikkeld, en de problemen waren voor de studenten dan ook theoretisch.
In het derde jaar is het practicum aangepast. Er is nu een software huis waarbij de
studenten zelf echt software ontwikkelen en in aanraking komen met echte problemen. De
beperkte hoeveelheid tijd en de grote hoeveelheid eigen te maken nieuwe technieken
maakt dit een zeer intensieve opzet, die door studenten als zeer dynamisch en zwaar wordt
ervaren.
Wat vooral opvalt bij de papers en de reflectie van de studenten is dat in een aantal
gevallen pas na afloop van het project en het schrijven van de reflectie duidelijk wordt
hoeveel er tijdens het practicum is gebeurd en dat dit tot een heel ander inzicht heeft geleid
dan de studenten in het begin hadden aangenomen. Opvallend was het commentaar van
een student, die vooraf van mening was dat er veel te weinig college uren waren
ingeroosterd en die na afloop tot de conclusie kwam dat hij zonder het intensieve
practicum nooit tot dezelfde inzichten zou zijn gekomen als hij nu in de praktijk had
ervaren. Met name het principe van test-first development had hij als onpraktisch
afgedaan, maar door dit in het project toe te passen ontdekte hij dat er een aantal fouten in
zijn oplossingen waren geslopen die hij anders in het geheel niet zou hebben opgemerkt.
Juist het verschaffen van dit soort inzichten moet het doel zijn van een practicum, waarbij
de colleges als onderbouwing van het geheel dienen.
Belangrijkste verbeterpunten 25
● In het practicum komen goed de problemen terug uit de praktijk. Echter deze
problemen moeten nog beter als leermoment worden benut. De studenten zijn
25 Een aantal van deze punten zijn al doorgevoerd. I.h.b. de combinatie met het practicum van het vak
Software Constructie werkt positief.
12-FEB-07 Appendix B. Overzicht Vakken 67

tezeer gefocust op het ontwikkelen van de software en analyseren / reflecteren nog
te weinig. De begeleiding nodigde hier wel toe uit, maar nog te ad hoc. Dit moet op
een meer structurele wijze worden opgepakt. Dit kan bijvoorbeeld door: naast het
opleveren van software ook reflectieverslagen te laten schrijven. Ook kan de
complexiteit worden verlaagd, waardoor student beter overzicht heeft en goed de
discussie kan voeren. Ten slotte kan het werkcollege beter benut worden om
bepaalde problemen te bespreken met de studenten en uit te nodigen tot discussie.
● De tijd was te beperkt voor het practicum. Door te combineren met het Software
Constructie practicum kan dit probleem worden opgeheven. Zo ontstaat er ook de
ruimte om te wisselen van rollen tijdens het project. In de huidige opzet wordt maar
een beperkt aantal studenten zelf rechtstreeks geconfronteerd met het management
probleem. Studenten die dit op een wat grotere afstand volgen krijgen vaak de
indruk dat dit management project gemakkelijk beter zou kunnen, maar dragen
daar niet actief aan bij. Veel problemen uit de praktijk komen hierdoor ook binnen
het project aan de orde, maar vaak zonder dat de studenten zich dit realiseren.
● De gecombineerde rol van klant en docent werd in veel gevallen als verwarrend
ervaren. Een scheiding van beide taken zou tot een uitholling van het concept
kunnen leiden, maar een duidelijker afbakening van de twee rollen is wel
noodzakelijk.
● Behandelen van andere actuele ontwikkelmethodes in het college en bespreken hoe
die omgaan met de behandelde problematiek.
Optioneel:
● College over gebruik van metrieken.
● College over software kwaliteit / CMM.
B7. Afstudeerproject
Keuze Stageopdracht
Het tijdig vinden van een afstudeeropdracht is cruciaal omdat er dan voldoende tijd is om
een goed plan van aanpak te schrijven. Ook kan dan de literatuurstudie gebruikt worden
ten behoeve van het afstudeerproject. In de eerste maanden van de opleiding wordt
wekelijks tijdens de voortgangsbespreking gewezen op de noodzaak van het vinden van
een afstudeerplek voor januari. De voortgang hiervan wordt nauwlettend in de gaten
gehouden. Verder probeert de opleiding een aantal afstudeerplaatsen te regelen voor de
studenten bij zowel bedrijven als bij CWI, HvA, UvA en VU. In de loop der jaren groeit
het netwerk van bedrijven waarbij stage is gelopen en wordt het gemakkelijker om
plaatsen te vinden. De website zal hierbij een steeds belangrijker rol spelen. Ook zullen de
studenten zichzelf verkopen. Een goed uitgevoerde stage zal bij het betreffende bedrijf
wederom interesse opwekken voor een afstudeerder van de Masteropleiding. Daarnaast
moeten studenten elkaars netwerk zoveel mogelijk benutten.
Plan van aanpak
Door veel aandacht te besteden aan een plan van aanpak, wordt gezorgd voor haalbaarheid
(goede scope) en vooral voor focus van het afstudeerproject. De focus stelt de student in
staat om de gewenste diepgang te bereiken. Om het plan van aanpak op te stellen is het
nodig om kennis te nemen van de organisatie en de omstandigheden. Hiervoor is tijd
beschikbaar. Daarnaast voert de student ook een literatuurstudie uit. Dit geeft hem beter
zicht op het onderwerp wat leidt tot een betere vraagstelling en een beter plan. Het plan
wordt opgesteld aan de hand van een van tevoren gegeven sjabloon. Hierdoor en doordat al
een aantal keer een mini onderzoek is uitgevoerd, is de student in staat om tot een
kwalitatief goed plan te komen.
12-FEB-07 Appendix B. Overzicht Vakken 68

Literatuurstudie
De literatuurstudie heeft als doel om al voor het uitvoeren van de feitelijke
afstudeeropdracht een indruk te krijgen van het onderwerp en de daarvoor relevante
literatuur. Het resultaat is een geannoteerde bibliografie.
Van tevoren hebben de studenten zich al bekwaamd in schrijven, lezen, zoeken van
informatie, waardoor literatuurstudie, opzetten onderzoek en schrijven verslag eenvoudiger
worden.
Uitvoering en scriptie
Van april tot en met juli vindt het afstudeeronderzoek plaats. De student moet dit
zelfstandig uit kunnen voeren. Om te zorgen dat het student op het juiste spoor blijft is er
zowel begeleiding vanuit de afstudeerplek als vanuit de opleiding. De begeleiding vanuit
het de afstudeerplek bestaat meestal uit een wekelijks voortgangsgesprek en is inhoudelijk
van aard. Vanuit de opleiding is de begeleiding maandelijks en is meer procesmatig. Er
wordt daarbij gekeken of de student goed op koers ligt en of er nog speciale aandacht
nodig is. Daarbij stelt de opleiding zich ten doel om halverwege de uitvoering een gesprek
te hebben met de begeleider vanuit de afstudeerplek. Indien nodig kan er intensievere
begeleiding geboden worden.
De student wordt gestimuleerd om de afstudeerscriptie in delen te schrijven. Zo kan de
voortgang beter worden gecontroleerd en vormt de rapportage een minder grote hindernis.
De opleiding stelt zich ten doel om te voorkomen dat afstudeerscripties van onvoldoende
niveau worden doorgelaten. Hiertoe worden duidelijke en faire spelregels en criteria
gehanteerd om te komen tot een uniforme beoordeling. Indien een scriptie van
onvoldoende niveau is zal deze worden afgewezen. Er zijn drie kansen om het afstuderen
te halen. Voor 15 juli, voor 1 september, voor 15 september. Lukt het de laatste keer niet,
dan het daaropvolgende studiejaar een nieuw afstudeerproject te worden uitgevoerd. Het
hele leermodel en de kwaliteitsbewaking zijn er echter op gericht om dit te voorkomen.
De beoordeling van een scriptie gebeurt door middel van een gestructureerde review door
minimaal drie personen. Beoordelingscriteria voor het afstuderen:
● Complexiteit van de problematiek:
o Is het probleem ongestructureerd / gestructureerd.
o Is er veel informatie / kennis nodig om het probleem te begrijpen.
o Spreekt de oplossingsrichting voor zich, of is het van tevoren lastig om te
bedenken hoe dit probleem wordt opgelost.
● Aanpak:
o Heldere aanpak.
o Gebruik technieken geleerd in de opleiding.
● Oplossing:
o Hoe goed is de student in staat geweest om het probleem te analyseren / begrijpen.
o Hoe zelfstandig heeft de student hieraan gewerkt.
o Wat is de kwaliteit / complexiteit van de gevonden oplossing.
o Er wordt verwezen naar relevante bronnen.
o Hoe goed zijn de beschikbare bronnen, inzichten uit de academische wereld
gebruikt?
o Literatuurverwijzingen voldoen aan de gangbare regels.
o In hoeverre is hier sprake van iets nieuws.
12-FEB-07 Appendix B. Overzicht Vakken 69

o Is het probleem ook opgelost.
o Is de oplossing gevalideerd.
o Heeft het bedrijf hieraan iets gehad.
o Kan de oplossing / scriptie gepubliceerd worden.
● Kwaliteit van de scriptie:
o Logische structuur.
o Heldere beschrijving.
o Helder taalgebruik.
12-FEB-07 Appendix B. Overzicht Vakken 70

Appendix C: Vergelijking curriculum met SWEBOK en SEEK
In dit hoofdstuk wordt kort toegelicht hoe goed het curriculum een overdekking geeft van
SWEBOK en SEEK. SWEBOK probeert alle kennis op het gebied van software
engineering samen te vatten zoals een software engineer die na vier jaar praktijkervaring
dient te hebben en formuleert dus geen curriculum. SEEK formuleert slechts een
undergaduate curriculum en de vergelijking betreft dus slechts thematiek en niet het
eindniveau.
SWEBOK
In het volgende overzicht worden de disciplines zoals onderkend door SWEBOK getoond.
Daarnaast wordt aangegeven hoe deze aan de orde komen in de opleiding. De gebruikte
schaal is Niet, Matig, Afdoende, Sterk.
SWEBOK Komt aan bod in vak Mate van
overdekking
Software requirements Requirements Engineering Sterk
Software design Software Architectuur / Software Afdoende
Constructie
Software construction Software Constructie Sterk
Software testing Software Testen Sterk
Software maintenance Software Evolutie Afdoende tot sterk
Software configuration Software Evolutie / Software Matig
management
Architectuur / Software Proces
Software engineering
management
Software Process Afdoende tot sterk
Software engineering
process
Software Proces Matig tot afdoende
Software engineering tools Software Constructie / Softweare Matig tot afdoende
and methods
Evolutie / hele opleiding
Software quality Gehele opleiding Afdoende
Toelichting
Software Design komt in de opleiding vooral aan bod in de vakken Software Architectuur
en Software Constructie. Bij Software Architectuur ligt de nadruk op het ontwikkelen van
een architectuur als communicatiemiddel tussen stakeholders. Het voor alle facetten van
design benodigde inzicht en vaardigheid wordt in de cursus behandeld en voor zover
mogelijk aangeleerd. Dit zijn vaardigheden als het zien van design als wicked problem, het
stellen van design goals, het modelleren, opstellen van viewpoints, documenteren van
designbeslissingen, en evalueren van design. Ook begrippen als kwaliteitsattributen,
scenario's, en anticipatie van veranderingen spelen een belangrijke rol.
Bij Software Architectuur wordt de student geconfronteerd met een applicatie die
ontwikkeld is met tal van design patterns. In het vak Software Constructie wordt ingegaan
op detailed design, design patterns, code standaarden en coordinatiemechanismen.
In de master opleiding wordt niet expliciet stilgestaan bij zaken als:
● Concurrency en performance.
● Distributie van componenten.
● Exception Handling en fault tolerance.
● Data persistence.
12-FEB-07 Appendix C: Vergelijking curriculum met SWEBOK en SEEK 71

● Measures voor design.
● Design strategieën.
Basisvaardigheden met modelleren wordt verondersteld als voorkennis. Hetzelfde geldt
voor UML. Studenten zijn vrij om diagramstijlen te kiezen.
Onderdelen van Software Configuration Management komen in verschillende vakken
terug, er wordt echter onvoldoende expliciete aandacht aan besteed.
De studenten worden tijdens de studie geconfronteerd met een veelheid aan Software
Tools en leren al werkende de mogelijkheden en beperkingen. Er wordt relatief weinig
expliciete aandacht aan besteed. In het vak Software Conmstructie bouwen de studenten
een geïntegreerde ontwikkelomgeving met losse componenten als editor, compiler,
interpreter.
SEEK
In het volgende overzicht worden de “knowledge areas” zoals onderkend door SEEK
getoond. Daarnaast wordt aangegeven hoe deze aan de orde komen in de opleiding.
SEEK Komt aan bod in vak Mate van overdekking
Computing Essentials Verondersteld als voorkennis Incidenteel worden
tekortkomingen aangevuld
Mathematics & Verondersteld als voorkennis Incidenteel worden
Engineering Essentials
tekortkomingen aangevuld
Professional Practice Software Proces Redelijk
Software Modelling & Software Architectuur/
Goed
Analysis
Requirements Engineering
Software Design Software Architectuur/
Diverse aspecten van
Requirements Engineering/ design zijn verspreid over
Software Constructie/
Software Proces
verschillende vakken
Software Validation & Software Testing Redelijk, verificatie wordt
Verification
nauwelijks behandeld
Software Evolution Software Evolutie Goed
Software Process Software Proces Goed
Software Quality Gehele opleiding Goed
Software Management Software Proces/ Gehele
opleiding
Redelijk
12-FEB-07 72

Appendix D. Vergelijkbare opleidingen
De volgende Mastersopleidingen in Software Engineering zijn min of meer vergelijkbaar:
● Master of Software Engineering, Carnegie Mellon University: een opleiding van
een jaar met vergelijkbaar programma. Zie: http://www.mse.cs.cmu.edu/, en
verder de detailvergelijking hieronder.
● Computer Science Master Degree with Software Engineering Profile, Master's
programma van verschillende omvang (60, 90 en 120 ECTS) bij Mälardalen
University, Department of Computer Science and Electronics, Zweden. Vertoont
grote gelijkenis met ons programma. Zie http://www.mdh.se/ide/eng/.
● Postgraduate Diploma in Advanced Software Engineering, University of
Westminster, Cavendish School of Computer Science, Groot Brittannië. Een
master van 60 ECTS. Heeft vergelijkbare basisvakken maar legt meer nadruk op
ontwikkelen van webapplicaties en mobiliteit. Zie: http://www.wmin.ac.uk/cscs.
● Master of Software Engineering, Seattle University. Een driejarige
deeltijdopleiding voor werkende professionals. Omvang is vermoedelijk 90 ECTS.
Aanzienlijke overlap in vakken met onze opleiding. Zie:
http://www.seattleu.edu/scieng/comsci/MSE/default.asp
● Master Computer Science with Software Engineering Profile, Vrije Universiteit
Amsterdam. Omvang 120 ECTS. Zie: http://www.cs.vu.nl/imse/index-en.html
● Master in de ingenieurswetenschappen: computerwetenschappen,
afstudeerrichting: software engineering, Universiteit van Gent. Een breder, minder
gespecialiseerd curriculum dan onze opleiding. Zie:
http://www.opleidingen.ugent.be/studiekiezer/nl/opl/emcosw.htm.
BENCHMARK MET CARNEGIE MELLON: Master of Software Engineering
Globale vergelijking
De opleiding van Carnegie Mellon (CM) komt redelijk overeen met de master Software
Engineering aan de UvA. De doelstelling is hetzelfde maar de master van de UvA heeft
een meer wetenschappelijke focus. Er zijn ook andere accentverschillen. Allereerst zijn de
vakken langs andere lijnen georganiseerd. In de master van CM is er meer expliciete
aandacht voor modellering en analyse. In de UvA master Software Engineering ligt er
meer nadruk op onderdelen als Requirements Engineering, Software Evolutie, en Software
Constructie.
Bovendien zijn de afstudeerprojecten verschillende wijze opgezet. Het afstudeerproject bij
de master van CM is vooral gericht op het op hoog niveau uitvoeren van taken in een groot
softwareproject en daarover reflecteren. In de master aan de UvA is dat een individuele
opdracht gericht op onderzoeken en wordt een meer creatieve bijdrage van de student
verwacht.
De omvang van de opleiding laat zich ook goed vergelijken. Het grote verschil is dat er
circa vijf maanden bij CM zijn ingeruimd voor keuzevakken. De toegevoegde waarde van
deze keuzevakken in de master CM laat zich moeilijk vaststellen. Verder is er meer ruimte
voor het afstudeerproject.
Diploma
Leidt op tot MSE (Master in Software Engineering) in plaats van MSc, maar dit geldt
alleen voor instromers met minimaal 2 jaar werkervaring. Als een student deze ervaring
12-FEB-07 Appendix D. Vergelijkbare opleidingen 73

niet heeft kwalificeert hij zich voor het diploma Master of Science in Information
Technology.
Doel opleiding CM
“The goal of the program is to prepare students for future roles as leaders in the software
industry. The program strives to produce graduates that are technically astute while
coupling their technical aptitudes with managerial, leadership, and communications
skills.”
Duur opleiding CM
4 semesters (van 4 maanden) i.p.v. 10 maanden (2 ½ semester). De zomer wordt gebruikt
als 1 semester.
Het programma wordt aangeboden in 12 maanden (waarna de student de universiteit
verlaat en de studie afsluit met een afstudeerproject bij een bedrijf), 16 maanden, of part
time.
Kerntheorie: 30% circa 5 maanden
Studio: 40% circa 6.5 maand
Keuzevakken: 30% circa 5 maanden
Analyse
De kerntheorie is qua omvang iets kleiner dan de 6 maanden die ervoor staan bij de UvAopleidibng.
De studio is qua doelstelling vergelijkbaar met het afstuderen (synthese), hier
is 2.5 maand meer tijd voor dan bij de UvA. Echter een belangrijk deel van het werk is
uitvoerend van aard (ontwikkelen en opleveren van software voor externe klanten in
gemeenschappelijke teams), dit deel valt niet in de scope van de UvA-opleiding.
Keuzevakken zijn volledig vrij en dragen in dat opzicht niet bij tot de te verwerven
competenties van de studenten zoals geformuleerd voor de opleiding bij Carnegy Mellon.
Dit betekent dat de omvang van de twee opleidingen goed vergelijkbaar is. Het grote
verschil zit in de keuzevakken. Deze dragen in mindere mate bij tot de specifieke
opleidingsdoelen. Wel zit de student langer in een universitaire omgeving.
Focus programma
Vier onderliggende thema’s hebben meer focus op:
● Modelvorming/formele notaties.
● Analyse.
Minder focus t.o.v. UvA-opleiding op:
● Requirements Engineering, Software Constructie, Software Evolutie.
● Werken met verschillende technologieën.
Kernvakken CM
Models of Software Systems
komt beperkt aan bod in onze opleiding
Deciding what to design
Verwarrende naamgeving. Gaat in op het softwareproces en komt ook overeen met onze
opleiding, met name in Requirements Engineering en Software Proces.
12-FEB-07 Appendix D. Vergelijkbare opleidingen 74

Managing Software Development
Delen komen overeen met Software Proces en Requierments Engineering, delen vallen
meer daar buiten (leadership/legal/CMM).
Analysis of Software Artifacts
Verification, testing, slicing komen gedeeltelijk aan de orde in Software Testing. Model
checking and abstract execution ontbreekt in de UvA-opleiding. Ook ontbreekt in de UvAopleiding
expliciete (reflectieve, overkoepelende) aandacht voor typeanalyse en
performance analyse.
Architectures for Software Systems
Komt redelijk overeen met onderdelen in Software Architectuur, Requirements
Engineering en Software Proces. Wel ligt er bij CM iets meer focus op het leren van
bestaande architectuurstijlen en principes dan in onze opleiding.
Communications
De onderdelen die hierin worden aangeleerd zijn sterk verweven in de Master SE aan de
UvA.
Instroomeisen
Vergelijkbaar met onze opleiding. Wel is onduidelijk hoe streng de voorwaarden worden
toegepast.
12-FEB-07 Appendix D. Vergelijkbare opleidingen 75

Appendix E: Overzicht Scripties
Een volledig overzicht van alle afstudeerscripties (inclusief een PDF versie) is te vinden op
http://homepages.cwi.nl/~paulk/thesesMasterSoftwareEngineering/index.html.
Scripties 2005-2006
1. Reinier l'Abee, Expliciet Gestructureerde Informatie Acquisitie Tijdens het
Architectuurproces (in Dutch), pdf
Organisation: Getronics PinkRoccade
Supervised by: Hans Dekkers, Rik Farenhorst (Getronics PinkRoccade), and Job
Vondeling (Getronics PinkRoccade)
2. Raymond Backus, Testing at Onguard: Invoeren van gestructureerde testmethodes
in een bestaand software ontwikkelproces (in Dutch), pdf
Organisation: OnGuard Nerderland B.V.
Supervised by: Bram van den Abeele (OnGuard) and Jan van Eijck
3. Paul Bakker, The Framework Productivity Measurement Method, pdf
Organisation: Info Support
Supervised by: Ronald Verduin (Info Support) and Jurgen Vinju
4. Menno Bredenoord, How to optimize Rscript comprehensions?, pdf
Organisation: Centrum voor Wiskunde en Informatica (CWI)
Supervised by: Paul Klint
5. Bart den Haak, Dynamic configurable web visualization of complex data relations,
pdf
Organisation: Software Improvement Group (SIG)
Supervised by: Jurgen Vinju and Gerjon de Vries (SIG)
6. Sabrina Jim, From UML diagrams to behavioural source code, pdf
Organisation: Centrum voor Wiskunde en Informatica (CWI)
Supervised by: Paul Klint
7. Jermaine Jong, The Trinidad Platform, pdf
Organisation: Capgemini
Supervised by: Hans Dekkers and Sander Hoogendoorn (Capgemini)
8. Richard Kettelerij, Designing a Measurement Programme for Software
Development Projects, pdf
Organisation: Ordina
Supervised by: Hans Dekkers and Dirk Koopman (Ordina)
9. Sannie Kwakman, Variability through Aspect Oriented Programming in J2ME
game development, confidential,
Organisation: Gamica
Supervised by: Ferdy Blaset (Gamica) and Jurgen Vinju
10.Sven Langenhuisen, Generate Domain Specific Knowledge to Support Silicon
Bases MEMs Development, pdf
Organisation: Cavendish Kinetics
Supervised by: Jan van Eijck and Dirkj Ortloff (Cavendish Kinetics)
11.Arnold Lankamp, The ToolBus: Inter Tool Communication, pdf
Organisation: Centrum voor Wiskunde en Informatica (CWI)
Supervised by: Paul Klint
12.Jacob Ooms, Ontwerp van een Group Decision Support System (in Dutch), pdf
Organisation: Memori Supervised by: Hans Dekkers and Dirk G.A. Kenis
(Memori)
13.Maarten Pater, Searching in public protein databases for novel Peroxisomal PTS1
containing Proteins, confidential
Organisation: Academic Medical Center (AMC), Amsterdam
Supervised by Jan van Eijck, G. A. Jansen (AMC), Jurgen Vinju
12-FEB-07 Appendix E: Overzicht Scripties 76

14.Tim Prijn, Framework Software Quality Analysis: A Case Study, pdf
Organisation: Info Support
Supervised by: Bastiaan Rodenburg (Info Support) and Jurgen Vinju
15.Jeroen Quakernaat, Het analyseren en verbeteren van een architectuurbeschrijving
(in Dutch), pdf
Organisation: Getronics PinkRoccade
Supervised by: Hans Dekkers, Rik Farenhorst (Getronics PinkRoccade), and Job
Vondeling (Getronics PinkRoccade)
16.Julien Rentrop, Software Metrics as Benchmarks for Source Code Quality of
Software Systems, pdf
Organisation: Software Improvement Group (SIG)
Supervised by: Patrick Duin (SIG) and Jurgen Vinju
17.Robin Rijnbeek, SIP-based communication between Microsoft Live
Communications Server and the NEC Philips Private Branch Exchange,
confidential,
Organisation: NEC Philips Unified Solutions
Supervised by: Gerard Hoogland (NEC Philips) and Paul Klint
18.Youri op't Roodt, The effect of Ajax on performance and usability in web
environments, pdf
Organisation: Hyves (Startphone Limited)
Supervised by: Koen Kam (Hyves) and Jurgen Vinju
19.Daniel Vrancken, Analyse Databasegebruik van het ChipSoft Framework (in
Dutch), pdf
Organisation: ChipSoft
Supervised by: Jan van Eijck and Jan Truijens (ChipSoft)
20.Bart Vreeken, Datatransformaties door middel van Model Driven Architecture pdf
Organisation: Ordina
Supervised by: Etienne Bido (Ordina) and Hans Dekkers
21.Bas Warmerdam, Software Quality Improvement at the AMC medical image
processing group, confidential
Organisation: Academic Medical Centre (AMC), Amsterdam
Supervised by: Hans Dekkers and J.G. Snel (AMC)
22.Rene Wiegers, Interaction with 3D VTK widgets: A quantitative study on the
influence of 2DOF a nd 6DOF input devices on user performance, pdf
Organisation: Centrum voor Wiskunde en Informatica (CWI)
Supervised by: Jan van Eijck and Robert van Liere (CWI)
23.Jacco van Willegen, Extractie van dode code in een heterogeen systeem: statisch
analyse in combinatie met dynamische analyse (in Dutch), pdf
Organisation: Centrum voor Wiskunde en Informatica (CWI)
Supervised by: Paul Klint
24.Jonathan Witkamp, Reconstructing Software Architecture Documentation for
Maintainability, pdf
Organisation: Lost Boys
Supervised by: Hans Dekkers and J. Meijerink (Lost Boys)
Scripties 2004-2005
1. Jeroen Arnoldus, Grammaticacontrole met behulp van Rscript (in Dutch), pdf
Organisation: Centrum voor Wiskunde en Informatica
Supervised by: Mark van den Brand and Paul Klint
2. Onno Bagijn, SOx IT Testing process compliance for Shell People, pdf
3. Arjan Borst, Ontwikkeling van een framework voor distributed computing (in
Dutch), pdf
12-FEB-07 Appendix E: Overzicht Scripties 77

Organisation: Amsterdam Medical Centre (AMC)
Supervised by: Hans Dekkers and Jeroen Snel (AMC)
4. Raimondo Faustinelli, De mate van anonimiteit in mixnetwerken gebruikmakend
van redundante berichten (in Dutch), pdf
Organisation: Technical University Delft (TUD) Supervised by: K. Cartrysse
(TUD), Jan van Eijck, and J.C.A. van der Lubbe (TUD)
5. Marinus Geuze, Reengineering Legacy in een veranderende software architectuur
(in Dutch), pdf
Organisation: PinkRoccade Civility
Supervised by: Hans Dekkers and B. Rebergen (PinkRoccade Civility)
6. Edwin de Groot, Softwarekwaliteit van MDA tools (in Dutch), pdf
Organisation: Centrum voor Wiskunde en Informatica
Supervised by: Mark van den Brand and Jan van Eijck
7. Peter Heibrink, Integratietest voor de ASF+SDF Meta-Environment (in Dutch), pdf
Organisation: Centrum voor Wiskunde en Informatica
Supervised by: Mark van den Brand and Paul Klint
8. Bram de Jager, Kostenschatten, een methodische aanpak voor Imtech ICT
Information Technology (in Dutch), pdf
Organisation: Imtech
Supervised by: Hans Dekkers, S. Hadinegoro (Imtech) and D. Lameir (Imtech)
9. Jonne Kats, The project leader's cockpit, pdf
Organisation: Philips Medical Systems (PMS)
Supervised by: L. Hofland (PMS), Paul Klint and R. Krikhaar (PMS)
10.Johan de Koning, Virtuele Maquette, 3D visualisatie met behulp van een database
(in Dutch), pdf
Organisation: Geodan
Supervised by: Jan van Eijck and Valik Solorzano Barboza
11.Joost Meijles, Analysis of designers' work, pdf
Organisation: Philips Medical Systems (PMS)
Supervised by S.B. Buunen (PMS), Paul Klint and R. Krikhaar (PMS)
12.Stelian Paraschiv, Gebruik van GPS voor routeplanning en routetracering (in
Dutch), pdf
Organisation: Ben & Jerry's Ijs-Express
Supervised by: C. Bevelander (Ben & Jerry's) and Jan van Eijck
13.Gerbrand Stap, COBOL data flow restructuring, pdf
Organistation: Free University of Amsterdam (VUA)
Supervised by: Mark van den Brand, Steven Klusener (VUA), and Niels Veerman
(VUA)
14.Bas Terwijn, Selecting middleware for the Intelligent Autonomous Systems group,
pdf
Organisation: University of Amsterdam (Uva)
Supervised by: Jan van Eijck and M. Maris (UvA)
15.Willem Visscher, Software process improvement bij HGH (in Dutch),
(Confidential); Organisation: Het Glazen Huis Business Consultancy (HGH);
Supervised by: Hans Dekkers and Peter Kranenburg (HGH)
Scripties 2003-2004
1. Idris Alamutu, Towards the integration of two repositories, pdf
Organisation: Mattic
Supervised by: Mark van den Brand and Jeanot Bijpost (Mattic)
2. August L'Annee de Betrancourt (joint work with Peter Lamers), Developing a
suitable structured testing approach for a small web development company, pdf
Organisation: Basket Builders (BB)
12-FEB-07 Appendix E: Overzicht Scripties 78

Supervised by: Alban Ponse and David Smits (BB)
3. Yassin Asri, Model based generation of a 3 tier application, pdf
Organisation: Mattic
Supervised by: Mark van den Brand and Jeanot Bijpost (Mattic)
4. Wilfred Belo, Model Driven Architecture (in Dutch), pdf
Organisation: Ordina
Supervised by: J.F.J. Branderhorst (Ordina) and Alban Ponse
5. Rinke Blootens, Draadloos race-informatiesysteem (in Dutch), (Confidential)
Organisation: Track Timing
Supervised by: Paul Klint and B. Nagels (Track Timing)
6. Shahjihan Chaudry, Anti-spam Masters project, pdf
Organisation: Centrum voor Wiskunde en Informatica
Supervised by: Paul Klint and Sjouke Mauw (CWI/TUE)
7. Hans Dekkers, Business case: the role of the IT architect, pdf
Organisation: Free University Amsterdam (VUA)
Supervised by: Paul Klint and Henk Koning (VUA)
8. Sabrina Filemon, Automatic homework checking: utopia?, pdf
Organisation: Hogeschool van Amsterdam (HvA)
Supervised by: Mark van den Brand
9. Chris Houwing, Visualisatie statistische gegevens (in Dutch), pdf
Organisation: Centraal Bureau voor de Statistiek (CBS)
Supervised by: O. ten Bosch (CBS), E. de Jonge (CBS), and Paul Klint
10.Erik-Jan Kok, FleetOnline (in Dutch), pdf
Organisation: Geodan Mobile Solutions
Supervised by: Barend Gehrels (Geodan) and Alban Ponse
11.Said Lakhloufi, JFC/Swing editor voor de ASF+SDF Meta-Environment (in
Dutch), pdf
Organisation: Centrum voor Wiskunde en Informatica (CWI)
Supervised by: Mark van den Brand, Hayco de Jong (CWI), Paul Klint, Taeke
Kooiker (CWI), Paul Klint and Jurgen Vinju (CWI)
12.Peter Lamers (joint work with August L'Annee de Betrancourt), Developing a
suitable structured testing approach for a small web development company, pdf
Organisation: Basket Builders (BB)
Supervised by: Alban Ponse and David Smits (BB)
13.Martijn Langereis (joint work with Erik Mulder), XML Stage (in Dutch), pdf
Organisation: Basket Builders (BB)
Supervised by: Alban Ponse and Steven Verver (BB)
14.Erik Mulder (joint work with Martijn Langereis), XML Stage (in Dutch), pdf
Organisation: Basket Builders (BB)
Supervised by: Alban Ponse and Steven Verver (BB)
15.Matthias Oliveiro, Reverse requirements engineering applied (in Dutch), pdf
Organisation: Interswitch
Supervised by Daan van den Berg and Jan van Eijck
16.Silvester Prinsen, Project Insight, (Confidential)
Organisation: Grimas
Supervised by: Mark van den Brand, Gerard van Huizen (Grimas), and Jan Tukker
(Grimas)
17.Martijn Thörig, OO overlay op relationele systemen (in Dutch), pdf
Organisation: Mattic
Supervised by: Mark van den Brand and Jeanot Bijpost (Mattic)
18.Fatma Tosun, Evaluating software configuration management tools for Opticon
Sensors Europe B.V., pdf; Organisation: Opticon Sensors Europe; Supervised by
Mark van den Brand and R. de Vries (Opticon)
12-FEB-07 Appendix E: Overzicht Scripties 79

Appendix F. Standaardvoorzieningen Universiteit van Amsterdam
Het Onderwijsinstituut is gehuisvest op het Roeterseilandcomplex (REC) als onderdeel
van de Faculteit Natuurwetenschappen, Wiskunde en Informatica (FNWI). Het REC
bestaat uit een aantal universitaire gebouwen, waarin naast onderwijs- en
onderzoeksinstituten van de FNWI twee andere faculteiten (FEE en FMG) zijn gehuisvest
en waar voorzieningen voor studenten (bibliotheken, studiezalen, mensa) zijn.
Een belangrijk deel van de wetenschappelijke staf is gehuisvest in het Science Park
Amsterdam (de Watergraafsmeer) of in de binnenstad. Voor deze medewerkers geldt dat
zij voor het geven van onderwijs en/of de begeleiding van groepen studenten moeten
reizen, hetgeen een aanzienlijke belasting is.
In één van de gebouwen op het REC is een docentenkamer ingericht, bestaande uit een
kleine vergaderkamer en een werkkamer met 3 computerwerkplekken. Van deze
voorziening wordt veel gebruik gemaakt.
Het plan is om de gehele faculteit binnen vier jaar te clusteren in het het Science Park
Amsterdam, waarmee in elk geval de reistijd voor de meeste docenten sterk wordt
gereduceerd.
Onderwijsruimten
De opleiding maakt gebruik van de beschikbare onderwijsruimten op het REC, in het
Science Park Amsterdam en in een enkel geval de binnenstad. Het grootste deel van het
onderwijs wordt gegeven op het REC. De onderwijsruimten op het REC worden jaarlijks
verdeeld op basis van de aanvragen door de verschillende opleidingen van de daar
gevestigde faculteiten (FNWI, FMG, FEE). Gebruik makend van de toegewezen zalen
worden in het voorjaar de onderwijsroosters voor het volgend academisch jaar gemaakt.
De opleiding beschikt over voldoende hoor- en werkcollegeruimten, zij het dat het soms
nodig is opeenvolgende onderwijsactiviteiten in een ander gebouw te roosteren. Dit brengt
voor studenten (en docenten) verplaatsingen tussen gebouwen met zich mee.
Voor de reguliere cursussen is het eenvoudig om zalen te reserveren. Het reserveren van
zaalruimten voor incidentele activiteiten door het jaar heen levert, mits tijdig aangevraagd,
ook geen onoverkomelijke problemen op.
De onderwijsruimten verkeren in goede staat en zijn, naast een whiteboard of krijtbord,
bijna allemaal standaard uitgerust met een beamer en een overheadprojector. Eventueel
zijn internetaansluiting, diaprojector, televisie en videorecorder beschikbaar op aanvraag.
Deze extra faciliteiten zijn te reserveren bij de op het REC aanwezige ICT-groep van de
faculteit en de Audiovisuele Dienst van het REC.
De FNWI beschikt in de Watergraafsmeer sinds 2000 over een Studio Classroom, sinds
2005 beschikt de FNWI over zo’n ruimte op het REC. In deze experimentele
onderwijsruimten wordt (werk)college gegeven met optimale visuele- en
audiomogelijkheden.
Helaas zijn de mogelijkheden voor studenten om -buiten de geroosterde
onderwijsactiviteiten- samen te werken in de onderwijsgebouwen van het REC beperkt. Er
zijn geen vrij toegankelijke project- of werkgroep ruimtes. Dit is voor de opleiding een
punt van zorg dat niet op korte termijn lijkt te kunnen worden weggenomen.
Computerwerkplekken
De opleiding maakt voor de practica gebruik van de computerpracticumruimten op het
REC. In gebouw Euclides zijn 5 computerzalen beschikbaar met in totaal ruim 100
werkplekken (PC’s onders Windows of Linux). Verder zijn er verspreid over de andere
gebouwen enkele computerpracticumruimten. In deze ruimten worden de practica van de
vakken uitgevoerd, buiten de practicumtijden zijn deze computerruimten voor
12-FEB-07 Appendix F. Standaardvoorzieningen Universiteit van Amsterdam 80

zelfwerkzaamheid beschikbaar. De gebouwen op het REC zijn over het algemeen geopend
van 9:00-20:00u.
Elke werkplek is voorzien van een snelle computer met internet en alle benodigde
software. De meeste van deze computerwerkplekken worden gedeeld met andere
opleidingen en zijn verdeeld over verschillende gebouwen op het REC en dus goed
bereikbaar. Vanuit elke werkplek is minstens één printer bereikbaar. Studenten hebben ook
de mogelijkheid om per maand 200 prints gratis af te drukken. Alle werkplekken zijn
volgens ARBO richtlijnen ingericht en studenten worden gewezen op RSI gevaar bij
veelvuldig computergebruik.
Verder kunnen studenten in het Studie- en Informatiecentrum van de faculteit en in het
Studiecentrum Roeterseiland gebruik maken van computerfaciliteiten.
Bibliotheken
De collectie boeken, (elektronische) tijdschriften voor de faculteit is ondergebracht in
bibliotheken in de verschillende gebouwen op het REC en in de Watergraafsmeer.
Materiaal dat in het archief is opgenomen is opvraagbaar en binnen één dag voor gebruik
beschikbaar. Van elk studieboek is minimaal een (niet uitleenbaar) exemplaar aanwezig in
de bibliotheek. Literatuur die niet aanwezig is op de locatie REC , kan worden
aangevraagd via het Interbibliothecair Leenverkeer (IBL). Mits voorradig op een van de
Nederlandse universiteiten, is de aanvraag binnen twee werkdagen geleverd.
Naast de papieren collectie beschikt de universiteit over een zeer uitgebreide digitale
bibliotheek van wetenschappelijke tijdschriften, die vanaf elke computer binnen de
universiteit bereikbaar is.
Onderwijsbureau
Het Onderwijsbureau waar de studentenadministratie van de opleiding is ondergebracht,
vormt een centraal punt in de informatievoorziening richting studenten. Studenten kunnen
er terecht voor: informatie over inschrijvingen, het aanvragen examens, enz. Het
Onderwijsbureau is gehuisvest in gebouw C, centraal op het REC.
Het Onderwijsbureau is voor studenten geopend van maandag t/m donderdag van 10:00-
14:00u.
De informatievoorziening naar de studenten vanuit het onderwijsbureau gebeurt
voornamelijk per e-mail of via de website van de opleiding (op: www.student.uva.nl).
Wanneer de verhuizing van de opleiding naar de nieuwbouw in de Watergraafsmeer
plaatsvindt, zal een samenvoeging van de Onderwijsbureau’s van alle opleidingen van de
FNWI plaatsvinden.
ICT-diensten
Sinds september 2004 zijn diverse informatievoorzieningen die via internet worden
aangeleverd gebundeld in de portal MijnUvA.nl. Deze portal bevat
-Studieweb: een applicatie gekoppeld aan het registratiesysteem ISIS. Studenten melden
zich aan voor vakken en kunnen hier hun geregistreerde studieresultaten inzien.
-Blackboard: een elektronische leeromgeving voor studenten en docenten, waarop
documenten geplaatst kunnen worden en discussiefora geopend kunnen worden. Tevens
kan blackboard gebruikt worden voor toetsing en dient het als hulpmiddel voor het
genereren en aanleveren van cijfers.
-De website van de opleiding (www.student.uva.nl) waarop alle informatie over de studie
staat voor de zittende studenten, zoals onderwijsmededelingen, studieprogramma’s,
roosters, etc.
-Studentmail
12-FEB-07 Appendix F. Standaardvoorzieningen Universiteit van Amsterdam 81

Door de invoering van MijnUvA.nl is een centrale plaats ontstaan voor het beheren van
alle informatie die de student nodig heeft met één gebruikersnaam en wachtwoord.
Bereikbaarheid informatie via het internet
Alle informatie op het internet is bereikbaar vanaf een UvA-adres. Voor het inloggen
vanaf huis biedt UvA de studenten tegen gereduceerd tarief UvA-inbel en UvAdsl.
Tevens is het mogelijk om via de UvA tegen gereduceerd tarief software voor thuisgebruik
te verkrijgen via www.surfspot.nl.
Naast een studentaccount (van de UvA) hebben FNWI-studenten ook een science-account.
Met dit account kan de student toegang krijgen tot specifieke software voor de opleiding.
UvA- dsl
Studenten hebben de mogelijkheid om door middel van een goedkoop UvA-dsl
abonnement thuis gebruik te maken van het UvA-netwerk en van de faciliteiten van de
universiteit.
UvA-VPN
Met het nieuwe UvA-VPN kunnen studenten en medewerkers vanaf een willekeurige
plaats in de wereld via een internetkoppeling toegang te krijgen tot digitale bronnen (zoals
toegang tot de digitale bibliotheek) die anders alleen vanuit het UvA-netwerk bereikbaar
zijn. De toegang wordt geregeld met behulp van de Virtual Private Networking techniek
(VPN).
Studiegids
Elk jaar worden de studieprogramma’s en vakomschrijvingen en een overzicht van
regelingen en voorzieningen gebundeld en gepubliceerd in de studiegids. Studenten
kunnen de gedrukte versie van deze gids -kosteloos- afhalen op het Onderwijsbureau. De
informatie over opleidingsprogramma’s en de vakomschrijvingen zijn ook te raadplegen in
de Digitale Studiegids van de UvA (www.studiegids.uva.nl)
International Office
Het International Office van de FNWI ondersteunt Nederlandse studenten die een stage in
het buitenland willen gaan doen of een uitwisselingsprogramma willen volgen en verzorgt
voor een zeer groot gedeelte de toelating van internationale studenten tot de Engelstalige
masters. Daarnaast ondersteunt het International Office de internationale studenten bij het
aanvragen van visa, het aanvragen van beurzen en het vinden van huisvesting.
Studievereniging VIA
Voor de studenten van alle opleidingen is de Vereniging Informatiewetenschappen
Amsterdam actief. Deze studievereniging organiseert de verkoop van boeken en syllabi,
excursies en lezingen. Daarnaast heeft de vereniging een groot en gewaardeerd aandeel in
de introductie van eerstejaarsstudenten.
UvA-voorzieningen
Een overzicht van alle voorzieningen van de UvA kan worden gevonden op:
http://www.uva.nl/voorzieningen/
12-FEB-07 Appendix F. Standaardvoorzieningen Universiteit van Amsterdam 82

Appendix G. Kwaliteitszorg Universiteit van Amsterdam
Kwaliteitsplan UvA
Het UvA-brede rapport met als titel "Naar een systeem van Integrale Kwaliteitszorg
Onderwijs UvA" beschrijft de stand van zaken omtrent kwaliteitszorg op universitair
niveau in augustus 2004. Daarnaast wordt beschreven hoe een systeem van integrale
kwaliteitszorg opgezet kan worden en er worden enkele maatregelen voorgesteld om tot
een dergelijk systeem te komen. Aan de UvA worden op vele terreinen van kwaliteitszorg
diverse activiteiten ondernomen, zoals onderwijsevaluaties, rendementsverbetering,
verbetering van de kleine kwaliteit, opbouw van relaties met alumni. Voor van een
systeem van integrale kwaliteitszorg sprake kan zijn, zou:
● de wijze waarop aan kwaliteitsverbetering wordt gewerkt, meer een cyclisch
karakter moeten krijgen en transparanter worden door te werken volgens de
PDCAcyclus;
● de organisatieaspecten, die onderdeel zijn van onderwijskwaliteit, dan wel deze
direct beïnvloeden, meer aandacht in de kwaliteitszorg moeten krijgen. Hierdoor
neemt het integrale karakter toe;
● de verantwoordelijkheden van de verschillende betrokkenen duidelijker moeten
worden;
● de kwaliteitsverbetering transparanter gedocumenteerd moeten worden in
kwaliteitsplannen en kwaliteitsverslagen;
● de activiteiten van de verschillende niveaus (docent, jaarcoördinator,
onderwijsdirecteur, decaan, CvB) beter op elkaar afgestemd moeten worden,
waardoor de samenhang toeneemt.
Kwaliteitsplan FNWI
In mei 2004 is het ‘Integraal Kwaliteitsplan Onderwijs aan de FNWI’ verschenen. In dit
plan is beschreven welke visie gehanteerd wordt ten aanzien van de kwaliteit van
onderwijs. In het kwaliteitsplan worden de noodzakelijke voorwaarden geschetst voor
kwalitatief hoogstaand onderwijs. Doel van het plan is te komen tot een een integrale
aanpak, waarin, naast directe kwaliteitszorg en borging t.a.v. het onderwijs zelf, ook
andere factoren zoals verbetering van onderwijskwaliteit middels het personeelsbeleid,
financiële beleid en planning zullen worden opgenomen.
Dit Kwaliteitsplan sluit geheel aan bij het UvA-brede rapport, maar gaat dieper in op de
situatie op opleidingsniveau. Tevens wordt hierin beschreven welke rol de betrokken
partijen (studenten, docenten, alumni en het werkveld) kunnen spelen in de bewaking van
de kwaliteit van de opleidingen.
Enkele elementen uit het “Integraal Kwaliteitsplan Onderwijs aan de FNWI”
Kwaliteit en kwantiteit van de instroom
De FNWI is initiatiefnemer in het project Bètapartners, dat tot doel heeft de instroom in
de bètavakken te bevorderen. In dit project werken acht scholen in de regio nauw samen
met de Universiteit van Amsterdam, de Vrije Universiteit, de Hogeschool van
Amsterdam en wetenschapsmuseum NEMO. Daarnaast is in februari 2005 het Bètabrugproject
van start gegaan: scholieren, die niet voldoen aan de ingangseisen van de bètaopleidingen,
wordt de gelegenheid gegeven om deficiënties weg te werken en alsnog in
te stromen.
12-FEB-07 Appendix G. Kwaliteitszorg Universiteit van Amsterdam 83

Intake bacheloropleidingen
De kwaliteit van de instroom zal worden gewaarborgd door een intakeprocedure. Naast
de formele inschrijving als student behelst deze procedure in de bacheloropleidingen een
gesprek met de studieadviseur waarin aan de orde komt: de motivatie van de student
voor de opleiding en het bepalen van de noodzaak voor het wegwerken van eventuele
deficiënties. Het doel van dit ‘intakegesprek’ is dat de verwachting van de student en van
de opleiding op elkaar worden afgestemd. Deze intakeprocedure zal in het studiejaar
2005/2006 van start gaan.
Jaargesprekken en digitaal portfolio
Gezien de organisatie binnen de FNWI worden jaargesprekken met docenten gevoerd
door de onderzoeksdirecteur. Dit heeft soms tot gevolg dat de nadruk van het jaargesprek
ligt op het onderzoek. Om een meer evenwichtig jaargesprek te voeren, is in november
2004 een “procedure jaargesprekken” verschenen, waarin beschreven wordt op welke
manier onderwijs geïntegreerd dient te worden in de jaargesprekken. Nieuw is dat op
verzoek de opleidingsdirecteur aanwezig zal zijn bij het jaargesprek. Het jaargesprek zal
wat betreft het onderwijs gebaseerd zijn op het competentieprofiel en het digitaal
portfolio voor UvA-docenten. De ontwikkeling van een digitaal portfolio voor docenten
is nu in volle gang.
Raad van Advies
De Raad van Advies vervult de rol van externe beoordelaar, die nodig is voor een
kritische reflectie op het onderwijs binnen het onderwijsinstituut. In de Raad van Advies
zullen vertegenwoordigers uit het bedrijfsleven, vakverenigingen, onderwijskundigen en
middelbare scholen plaats nemen. De raad komt tenminste één keer per jaar bijeen om op
basis van studiegids, afgenomen tentamens, scripties en jaarverslag een extern oordeel
over de opleiding te geven. Hierbij wordt de opleiding getoetst aan haar doelstellingen en
wordt in het oordeel meegenomen of de opleiding aansluit bij de arbeidsmarkt. Aan het
samenstellen van één Raad van Advies per onderwijsinstituut wordt op dit ogenblik
actief gewerkt.
Kwaliteitsteam FNWI
Voor de implementatie van de actiepunten, die voortkomen uit het Kwaliteitsplan
Onderwijs, is in januari 2005 het Kwaliteitsteam Onderwijs FNWI opgericht. Dit team
heeft als doel om, zoals de naam al zegt, de kwaliteit van het onderwijs te verbeteren.
Naast de implementatie van de actiepunten uit het kwaliteitsplan heeft dit team als overige
taak de voorbereiding van de samenwerking tussen de opleidingen met het oog op de
situatie in 2008, als alle opleidingen op een locatie gevestigd zijn en de drie
onderwijsinstituten samengaan tot één onderwijsorganisatie (notitie ‘Onderwijs FNWI
2008). Het Kwaliteitsteam is een facultair team en bestaat uit vertegenwoordigers van de
onderwijsinstituten, een vertegenwoordiger van het AMSTEL-instituut, een afgevaardigde
vanuit de FSR en het Hoofd Onderwijs.
Kwaliteit van de opleiding
De doelstellingen van de opleiding kunnen bereikt worden door het uitvoeren van de ‘plando-check-act’
cyclus op alle relevante onderdelen. Voor de kwaliteit van het geboden
onderwijs gebeurt dat met behulp van een evaluatiecyclus (figuur G.1 ).
12-FEB-07 Appendix G. Kwaliteitszorg Universiteit van Amsterdam 84

Aanpassing cursus
In overleg met OC en
Opleidingsdirecteur
Vakevaluatie
Terugkoppeling
naar docent
Bespreking in OC
Conclusie OC:
goed of niet voldoende
Figuur G.1 Planmatige jaarlijkse evaluatie terugkoppelingscyclus
Actoren
Bij de zorg voor de kwaliteit van het onderwijs van de opleiding spelen een aantal organen
of personen een belangrijke rol, deze worden hieronder in hun onderlinge samenhang
besproken:
● Opleidingscommissie
De Opleidingscommissie heeft als taak de opleidingsdirecteur te adviseren over het
onderwijsbeleid. De opleidingscommissie bestaat uit docenten (waaronder de
voorzitter) van de opleiding en studenten (van elke OC zijn minstens evenveel
studenten als docenten lid). De Opleidingsdirecteur is geen lid van de commissie,
wel kan deze -op verzoek van de commissie- vergaderingen bijwonen. De
Opleidingscommissie komt eens per vier tot zes weken bijeen en bespreekt het
onderwijs, de onderwijsevaluaties, adviseert over de Onderwijs- en
Examenregeling (OER).
● Examencommissie
De Examencommissie is verantwoordelijk voor de tentamens en de examens,
beoordeelt de vakkenpakketten van de studenten en verleent vrijstellingen. Zij
beslist over het behalen van diploma’s, neemt examens af en zorgt voor de
uitreiking van diploma’s. Daarnaast waarborgt de examencommissie adequate
tentaminering bij de diverse examenonderdelen en adviseert zij over de Onderwijs-
en Examenregeling (OER). Tevens heeft deze commissie als taak om klachten en
fraudegevallen af te handelen en curriculumaanpassingen te doen als dit nodig is
(bv. bij gehandicapte studenten).
● Onderwijsdirecteur
De Onderwijsdirecteur is algemeen verantwoordelijk voor de inhoudelijke en
didactische kwaliteit van bestaande opleidingen en de ontwikkeling van nieuwe
opleidingen. Daarbij bewaakt hij de samenhang en onderlinge afstemming tussen
de opleidingen binnen het onderwijs instituut.
● Opleidingsdirecteur
De Opleidingsdirecteur is verantwoordelijk voor de ontwikkeling en uitvoering van
het onderwijsprogramma. De opleidingsdirecteur werkt in nauw contact met de
12-FEB-07 Appendix G. Kwaliteitszorg Universiteit van Amsterdam 85

etrokken opleidingscoördinatoren, de directeuren van de onderzoeksinstituten, de
opleidingscommissie en het docententeam.
● Docent
De docent vervult een centrale rol in het onderwijs. Hij geeft het onderwijs zodanig
dat het voldoet aan de door de opleiding gestelde kwaliteitseisen. Hij is
verantwoordelijk voor zowel de inhoud en de organisatie van het toegewezen
examenonderdeel inclusief de hoorcolleges, de ondersteunende werkcolleges en
practica als voor de afstemming met andere vakken. Verder levert de docent een
bijdrage aan indirecte onderwijstaken zoals het lidmaatschap van een
docententeam, en/of de Opleidings- of Examencommissie en verzorgen van
voorlichting. De docent zoals hierboven beschreven is de ‘verantwoordelijke’
docent. Hij kan taken delegeren naar zijn medewerkers, maar blijft te allen tijde
verantwoordelijk voor zijn vak en kan hier zonodig op worden aangesproken.
Doel onderwijsevaluatie
Het onderwijs wordt geëvalueerd met als doel:
● Kwaliteit van het onderwijs bewaken.
● Kwaliteit van het totale onderwijs per jaar bewaken (samenhang, studeerbaarheid,
niveau en rendement).
● Kwaliteit van de opleiding als geheel bewaken.
De opleiding hanteert hiertoe een kwaliteitsoordeel op drie niveaus dat planmatig wordt
uitgevoerd om de bovengestelde doelen te bereiken, volgens de plan do check en act
cyclus, te weten:
● Op het niveau van een individueel vak.
● Op het niveau van een studiejaar.
● Op het niveau van de opleiding in zijn geheel.
De evaluaties per vak richten zich voornamelijk op de inhoud van het vak, de didactiek
van de docent en de aansluiting op de rest van het programma. Toetsing van de eindtermen
gebeurt (gedeeltelijk) in de jaarlijkse evaluaties door de docententeams. Deze jaarlijkse
evaluaties hebben betrekking op de aansluiting van het jaar op aanwezige kennis, de link
van vakken met het studieveld en de geoefende vaardigheden. Als aanvulling op deze
evaluatie wordt ook jaarlijks o.l.v. de Opleidingsdirecteur door het docententeam naar de
uitwerking van de einddoelen in het programma gekeken. Ook wordt dan bepaald in
hoeverre de verschillende vaardigheden van de student getraind zijn.
Procedure uitvoering evaluatie onderwijsproces
De vakken worden geëvalueerd conform de “Regeling Onderwijsevaluatie” van het
Onderwijsinstituut Informatiewetenschappen (dd. 27 november 2005). In de afgelopen
jaren zijn enkele wijzigingen in de uitvoering van deze regeling opgetreden: het aantal
studenten wordt afgelezen uit de studentenadministratie (en niet meer aan de docent
gevraagd), het verslag van de docent wordt niet meer via het Onderwijsinstituut verspreid
maar op verzoek van de leden van de OC gemaakt, daarin worden ook de
slagingspercentages besproken.
Alle vakevaluaties worden besproken in de Opleidingscommissie en krijgen de
beoordeling ‘goed’ of ‘niet voldoende’. Indien dit laatste het geval is, volgt contact tussen
de voorzitter van de Opleidingscommissie en de betreffende docent. Naar aanleiding van
dit contact stelt de docent schriftelijk veranderingen die worden gerapporteerd aan de
Opleidingscommissie. Het jaar volgend op de veranderingen wordt met extra aandacht
12-FEB-07 Appendix G. Kwaliteitszorg Universiteit van Amsterdam 86

naar de evaluaties gekeken door de Opleidingscommissie, om te toetsen of de uitgevoerde
veranderingen het verwachte resultaat heeft opgeleverd. De Opleidingscommissie
rapporteert aan de Opleidingsdirecteur.
Betrokkenheid van studenten en docenten
De betrokkenheid van studenten bij de kwaliteitszorg is, zoals uit het bovenstaande blijkt,
erg groot. Studenten en docenten participeren in de opleidingscommissie. Op facultair
niveau opereert de Facultaire Studentenraad (FSR). De FSR bestaat uit 12 (gekozen)
studenten en heeft instemmingsrecht en adviesrecht. Daarnaast bestaat de “FNWI
Studenten Community ICT en Onderwijs”, gevormd door leden van de
onderwijsorganisatie en FNWI-studenten en opgericht als instrument dat overkoepelend
naar de kwaliteit van ICT in het onderwijs kijkt en een laagdrempelig aanspreekpunt voor
problemen en wensen is.
Universiteitsbreed wordt tweejaarlijks de tevredenheid onder studenten ten aanzien van het
onderwijs gemeten door middel van de ‘Student Tevredenheids Monitor’. In deze monitor
komen aspecten als het academisch niveau van de opleiding aan de orde, maar ook de
tevredenheid over faciliteiten, de sociale omgeving van de faculteit en de organisatie van
het onderwijs.
Tot slot wordt de mening van studenten op verschillende manieren gevraagd door
‘externen’, zoals bij de Keuzegids Hoger onderwijs en de Elsevier studentenenquête.
Betrokkenheid van alumni en beroepenveld
Voor de veranderende eisen die worden gesteld door het afnemend veld aan de
afgestudeerden en dus aan het geboden onderwijs, wordt onderzoek gedaan naar de
arbeidsmarktpositie van alumni en naar hun evaluatie van de opleiding, zie blz. 46.
Om het contact met het afnemend veld te intensiveren wordt per onderwijsinstituut een
Raad van Advies ingesteld. De opleiding zal voor specifieke vragen aan het afnemend veld
alsmede bij het gebruik maken van de diensten van de in te stellen Raad van Advies steeds
een voorstel (bijvoorbeeld t.a.v. onderwijs kwaliteit en inhoud) voorleggen en laten
toetsen, de aanbevelingen verwerken en uitvoeren en ze vervolgens beoordelen op hun
effectiviteit (b.v. rendementverbetering, betere plaatsingsmogelijkheden van
afgestudeerden van de bachelor of master etc.)
12-FEB-07 Appendix G. Kwaliteitszorg Universiteit van Amsterdam 87