Onderwijsinstituut Informatiewetenschappen Universiteit van Amsterdam Februari Faculteit der Natuurwetenschappen, Wiskunde en Informatica

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 in samenwerking met

Hogeschool van Amsterdam 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 Adres

Universiteit van Amsterdam 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 Studielast: Variant(en) Adres Contactpersoon

12-FEB-07

Master Software Engineering (CROHO-registratie 60228) 60 studiepunten Voltijds- en deeltijdsvariant Onderwijsinstituut Informatiewetenschappen Nieuwe Achtergracht 166 1018 WV Amsterdam Drs. C.R. van Wensen

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 zijn1: ●

●

●

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 eisen2 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 1. Kennis en inzicht 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 basis of een kans bieden om een originele bijdrage te leveren aan het ontwikkelen en/of toepassen van ideeën, vaak in onderzoeksverband.

Master Software Engineering Algemene eindkwalificaties 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. 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. 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

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.

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

12-FEB-07

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.

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

12-FEB-07

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.

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

Software Architectuur Weken 9-16

Requirements Engineering Software Testen Software Proces

Weken 17-28

Software Constructie Voorbereiding Stage Literatuurstudie

Afstudeerproject Weken 29-40 Week 50

Wekelijkse Papersessies

Software Evolutie

Maandelijkse Voortgangsbesprekingen

Weken 0-8

Wekelijkse voortgangsbesprekingen

Introductiedagen

Afstuderen Figuur 1: Globaal rooster

De verschillende vakken sluiten sterk op elkaar aan doordat ze allen overeenkomen met een fase binnen de diverse varianten van de Software Life Cycle3. 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 (2nd Edition).

12-FEB-07

CURRICULUM

15

●

● ● ● ●

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 Selecteer praktijkcases bedrijfsleven worden gevraagd als hoogleraren die onderzoek doen op het betreffende vak. Deze adviesraad zal Bepaal toetsingsvormen adviseren over het curriculum als geheel. Ontwikkelen vak Geef onderwijs in dit vak Voor de opleiding zijn drie vakken nieuw ontwikkeld. Daarnaast zijn drie bestaande vakken aangepast. Bij het ontwikkelen van de Toets studenten vakken wordt gebruikgemaakt van het ontwikkelmodel zoals is weergegeven in Figuur 2. Er is er veel ruimte voor de Evalueer en verbeter vak hoofddocent om dit te doen op zijn manier, mits dit binnen het didactische model van de Figuur 2: Ontwikkelingsmodel per vak opleiding past. Om de kwaliteit van de 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. Profiel WO Bachelors

Profiel HBO Bachelors

Goede basiskennis

Redelijke basiskennis

Capabilities Analytische vaardigheden Motivatie

Kan projectmatig werken Praktische vaardigheden Motivatie

Onvoldoende praktische vaardigheden Handicaps Onvoldoende oplossingsgericht denken

Matige analytische vaardigheden Onvoldoende taalvaardigheid Denkt in absolute termen i.p.v. het afwegen van alternatieven met sterktes en zwaktes

Kan niet goed projectmatig werken Is al lang niet meer uitgedaagd Onvoldoende taalvaardigheid Beter worden/leren

Beter willen worden/leren

Motivators Master in 1 jaar

Master in 1 jaar

Betere kansen op de arbeidsmarkt Betere kansen op de arbeidsmarkt (banen en beloning) (banen en beloning) Onvoldoende theoretische analyses Stof is niet nuttig/toepasbaar Stof is te toepassingsgericht

Opdrachten zijn niet concreet genoeg

Werken in groepen

Werken in groepen

Demotivators Onvoldoende beloond voor hard werken

Onvoldoende beloond voor hard werken

Onvoldoendes

Onvoldoendes

Schoolse aanpak

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 predikatenlogica5. 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 (eenvoudige) complexiteitsanalyse van algoritmen.8 9 Compilerbouw: Scannen, bouwen van ontleedbomen, type checking, code generatie.10 Inleiding software engineering: Basiskennis over architectuur, programmeerstijlen, ontwerp aan de hand van een pakket van eisen, enzovoort. 11 12 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 (2nd 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 (2nd Edition). 12 I. Sommerville, Software Engineering, Addison-Wesley, 2004 (7th 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 Eclipse16 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 Software Evolutie Software Testen Requirements Engineering Software Process Software Constructie Voorbereiding Masterproject Literatuurstudie Masterproject SE Totaal

6 6 6 6 6 6 2 4 18 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.

Keuze Stageopdracht

De volgende maatregelen zijn genomen om de kwaliteit van specifieke aspecten van de opleiding te bewaken. Werving K Wekelijkse voortgangsbespreking De wekelijks voortgang van zowel de w studenten als de opleiding als geheel wordt a Selectie wekelijks gevolgd in een voortgangsbespreking in kleine groepen l onder leiding van de coördinatoren. Dit kan i leiden tot maatregelen om faciliteiten te Attitudevorming verbeteren of aan te passen, vakken bij te t sturen, of individuele studenten aan te e spreken. Het is ook een mechanisme om overbelasting of uitval van studenten te i signaleren en in te grijpen als Vaardigt (practicum)groepen niet functioneren. Ook Kennis heden is het een mechanisme om gewenste s attitude en uitgangspunten van de opleiding b zonodig wekelijks over het voetlicht te brengen. Tenslotte, wordt de e Plan van aanpak voortgangsbespreking gebruikt om het w tijdig zoeken naar stageopdrachten te stimuleren. Zonder overdrijven kan gesteld a worden dat de wekelijks Literatuurstudie k voortgangsbespreking is uitgegroeid tot de primaire maatregel om de kwaliteit van de i opleiding te bewaken. n AfstudeerKleine omgeving project g In deze kleine omgeving is er een sterke uitwisseling tussen de verschillende docenten, coördinatoren en studenten. Er Figuur 4: Opleidingsmodel wordt veelvuldig 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. 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

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

Organisatie

Functie

M/ V

FTE Onderwijs

Prof .dr .P. Klint Prof .dr .J. van Eijck Prof. dr. H. van Vliet Dr. P. Lago P. van Lith

UvA/II

HL

M

0.20

CWI

HL

M

0.20

VU

HL

M

0.065

VU Multi Motions

UD

V

0.065

Directeur Projectleider

M

0.13

M

0.30

M

Lid coördinatieteam en Docent Requirements 1.0 Engineering 1.96

Dr. J. Vinju CWI

Lid coördinatieteam

Drs. H. Dekkers UvA/II Totaal

Rol Opleidingsdirekteur, docent Software Evolutie en Software Constructie Opleidingscoördinator en docent Software Testen Docent Software Architecture Docent Software Architecture Docent Software Proces

Docent

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 Drs. D. van den Berg HvA Docent M 0.13 Dr. M. van den Brand CWI HL M 0.13 R. Esmaili HvA Docent M 0.065 Dr. T. Kuipers SIG CTO M 0.13 12-FEB-07

Rol Docent Requirements Engineering Docent Software Evolutie en Software Constructie Docent Software Testen Docent Software Process

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

Tijd ondersteuning

Voorbereiden 8 colleges van 2 uur

32

Geven colleges (inclusief reistijd)

32

Voorbereiden 6 werkcolleges van 2 uur

12

Geven werkcolleges (inclusief reistijd)

24

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

36

BESTURING EN KWALITEITSVERBETERING

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: ● 1e 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 200219 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 2003-2004 2004-2005 2005-2006 2006-2007

Instroom Gehaald Rendement 19 17 89% 15 15 100% 28 (+8) 25 89% 20 (+4)

Nog bezig

WO bachelor 1 0 1

HBO bachelor 17 15 36 20

2 0 1 4

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

2003-2004 2004-2005 2005-2006

HBO HBO HBO OveHBO Technische Informatie Bedrijfsk. rig Hogere Inf. HBO Inf. Inf. kunde Informatica 9 1 0 1 2 6 8 2 0 2 1 2 14 12 4 1 2 4

A2. Gemiddelde eindcijfers De gemiddelde eindcijfers per vak zijn alsvolgt. Tussen haakjes staat de spreiding. Vak Software Evolution Software Architecture Software Testing Requirements Engineering Software Construction Software Process Literatuurstudie Masterproject

2003-2004 7.3 (0,6) 7.3 (0.4) 7.0 (0.6) 7.7 (0.5) 7.6 (0.5) 7.1 (0.9) 7.5 (0.5) 7.4 (0.7)

2004-2005 7.3 (0.7) 7.2 (0.5) 7.5 (0.4) 7.1 (0.6) 7.5 (0.4) 7.4 (0.4) 7.6 (0.6) 7.6 (0.6)

2005-2006 7.5 (0.5) 6.8 (0.3) 7.6 (0.5) 7.1 (0.5) 7.5 (0.6) 7.4 (0.4) 7.4 (0.4)

2006-2007 8.1 (0.6) 6.8 (0.4)

12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering

44

De herkansingen per vak zijn alsvolgt. Vak

2003-2004 1x 2x 3x

Software Evolution Software Architecture Software Testing Requirements Engineering Software Construction Software Process Literatuurstudie Masterproject

19 13 13 19 18 13 19 16

Niet

6 6

3

1

2

1 2 1

Vak Software Evolution Software Architecture Software Testing Requirements Engineering Software Construction Software Process Literatuurstudie Masterproject

2004-2005 1x 2x Niet

2005-2006 1x 2x Niet

15 15 13 11

23 30 28 34

15 16 15 13

2 4

32 33 27 15

1 2

4 2

1 3 1 2 1

10

2

2006-2007 1x 2x

3x

Niet

21 14

(1?) (2?)

6 2

3 1

A3. Studentenevaluaties 2003-2004

2004-200520

2005-200621

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

-

Vak

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

Vak

2003-2004

2004-2005

2005-2006

Voorbereiding Mastersproject

6.5

7.3

7.5

Mastersproject

7.8

-

-

2006-2007

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

2003-2004

1

1

2004-2005

0

0

2005-2006

2

1

Toelichting Paper Software Process

Paper Software Process Paper Software Constructie

A5. Evaluatie door alumni 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 3-6 maanden

85 % 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

0%, 6%

Tijdelijke baan, met uitzicht op vast dienstverband

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

12-FEB-07Appendix A: Kwantitatieve gegevens Master Software Engineering

11%, 22%

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 Overige branches:

6%, 11% •

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 In geringe mate

28 % 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 Minimaal WO Anders

72 %

17 % 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 Programmering / roostering Huisvesting

24 % 12 % 6% 12 %

Werkplekken Administratie

24 % 0%

Overig

Overige verbeterpunten:

24 % •

minder werk in practicum groepjes

•

presenteren, argumenteren

•

Meer betrekken met andere vakgebieden

•

begeleiding

•

opleidingsduur naar 2 jaar met meer inhoud en diepgang

Eindtermen23 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 Enig

Redelijk Groot

Heeft inzicht in de belangrijkste technologische ontwikkelingen en hieraan gerelateerde wetenschappelijke resultaten

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

47%

26%

26%

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

0%

37%

63%

Beheerst methoden en technieken om een softwaresysteem mee te laten evolueren met de veranderde eisen die aan dat systeem worden gesteld

5%

42%

53%

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

11%

11%

79%

Beheerst een scala aan testmethoden en technieken, weet wanneer welke techniek ingezet dient te worden en heeft hiermee ook praktische ervaring opgedaan.

26%

37%

37%

Is in staat richtlijnen op het gebied van softwareconstructie op te stellen, bijvoorbeeld ten aanzien van coding standards, herstructurering, configuratie management en build processen

16%

37%

47%

Is in staat systeemeisen te vertalen in een systeemarchitectuur en afwegingen tussen conflicterende eisen zorgvuldig te maken en te motiveren

0%

42%

58%

Is in staat wensen van systeemgebruikers om te zetten in specifieke requirements, objectmodellen en acceptatietests

11%

37%

53%

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.

16%

53%

32%

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

5%

37%

58%

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.

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% 17 % 0% 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? Voldoende in studie?

Belang 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, 2nd 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 practicum24 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 verbeterpunten25 ● 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

Software requirements Software design

Requirements Engineering Software Architectuur / Software Constructie Software Constructie Software Testen Software Evolutie Software Evolutie / Software Architectuur / Software Proces Software Process

Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality

Mate van overdekking Sterk Afdoende Sterk Sterk Afdoende tot sterk Matig Afdoende tot sterk

Software Proces

Matig tot afdoende

Software Constructie / Softweare Evolutie / hele opleiding Gehele opleiding

Matig tot afdoende 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 Computing Essentials

Komt aan bod in vak Verondersteld als voorkennis

Mathematics & Engineering Essentials Professional Practice Software Modelling & Analysis Software Design

Verondersteld als voorkennis

Software Validation & Verification Software Evolution Software Process Software Quality Software Management

12-FEB-07

Software Proces Software Architectuur/ Requirements Engineering Software Architectuur/ Requirements Engineering/ Software Constructie/ Software Proces Software Testing Software Evolutie Software Proces Gehele opleiding Software Proces/ Gehele opleiding

Mate van overdekking Incidenteel worden tekortkomingen aangevuld Incidenteel worden tekortkomingen aangevuld Redelijk Goed Diverse aspecten van design zijn verspreid over verschillende vakken Redelijk, verificatie wordt nauwelijks behandeld Goed Goed Goed Redelijk

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: Studio: Keuzevakken:

30% 40% 30%

circa 5 maanden circa 6.5 maand 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:0014: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

Vakevaluatie

Aanpassing cursus

Bespreking in OC

Terugkoppeling naar docent

In overleg met OC en Opleidingsdirecteur

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 Onderwijsen 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

betrokken 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