Het zelf ontwikkelen van elektronische leerobjecten

1. Inleiding

In deze bijdrage vertel ik docenten wat er

komt kijken bij het zelf ontwikkelen van

elektronische leerobjecten als ondersteu-

ning bij of misschien wel vervanging van de

eigen colleges. Ook voor onderwijsbesturen

kan deze informatie van belang zijn. Zij kun-

nen immers de ontwikkelingen door docen-

ten stimuleren en sturen.

Elektronische leerobjecten bestaan in vele

soorten en maten. Een afbeelding die via

het Internet aan studenten wordt aangebo-

den, is op te vatten als een elektronisch leer-

object. Maar de webpagina waarin deze

met toelichting en al is opgenomen, is óók

een elektronisch leerobject. Het gaat dus

om een genest begrip. Ook een complete

elektronische diapresentatie, een op zichzelf

staand elektronisch college, een interactieve

simulatie of een complete elektronische cur-

sus zijn leerobjecten. Ik noem ze elektro-

nisch wanneer moderne informatie- en

communicatietechnologie bij het "consume-

ren" van deze leerobjecten wordt toegepast.

Ik concentreer me hier op het tot stand

brengen van elektronische leerobjecten tot

aan het kaliber van een elektronische cursus.

Dat zijn namelijk projecten die nog te over-

zien zijn voor een individuele docent of een

kleine werkgroep. Ik ga hier niet in op het

ontwikkelen van een complete elektronische

leeromgeving waarbinnen elektronische

leerobjecten worden aangeboden, ook niet

op geautomatiseerde individuele studie-

plan- en volg-sy stemen, noch op het ont-

wikkelen van complete elektronische curri-

cula.

In de navolgende paragrafen sta ik eerst stil

bij het innoveren van het onderwijs met

behulp van ICT. Dat kan zowel via spontane

initiatieven van docenten als via een

gestuurde actie vanuit bijvoorbeeld een

onderwijsbestuur plaatsvinden. V ervolgens

wijs ik op het belang van een projectmatige

aanpak van de ontwikkeling van elektroni-

sche leerobjecten. V oor de meest eenvoudi-

ge leerobjecten is dat wat overdreven, maar

zelfs al bij het ontwikkelen van een elektro-

nische diapresentatie kan deze benadering

van pas komen. Binnen een ontwikkelpro-

ject onderscheid ik de volgende fasen:

• definitiefase,

• ontwerpfase,

• realisatiefase,

• invoeringsfase.

Al die fasen komen verder aan bod. Ik ein-

dig met een uitleiding waarin ik stil sta bij de

verdere levensloop van een eenmaal ontwik-

keld elektronisch leerobject.

Bij het samenstellen van deze bijdrage heb

ik geput uit mijn onderzoeks- en praktijker-

varing en heel specifiek uit mijn ervaring als

adviseur en begeleider van de 14

RechtenOnline-projecten uit 2003.

2. Innoveren met ICT

Innoveren met ICT begint in het academisch

onderwijs, net als in veel andere organisa-

ties, vaak van onderop (bottom-up). Op een

gegeven moment vindt dan een omslag

plaats en gaat de innovatie verder als een

proces dat vanuit de top wordt aangestuurd

(top-dow n).

2.1 Bottom-up

Individuele docenten beschikken over een

zekere autonomie als het om de invulling

van hun eigen colleges gaat. Ze delen ook

hun eigen tijd in en beschikken soms zelfs

over een zeker budget of weten een subsi-

die te verwerven. Een docent die enthou-

siast is over elektronisch leren vindt dan

altijd wel mogelijkheden om hier op een

bescheiden wijze mee te experimenteren.

Een organisatie die vooral innoveert via ver-

spreide initiatieven van onderop verkeert in

het bottom-up stadium.

Bottom-up innoveren met ICT is voor een

onderwijsorganisatie een goede zaak. Op

verschillende plaatsen in de organisatie

wordt nieuwe kennis en ervaring opgedaan

tegen relatief lage kosten en lage risico's.

153

Het zelf ontwikkelen

van elektronische leerobjecten

Pieter van der Hijden15

Het onderwijsbestuur is daar soms nauwe-lijks bij betrokken. Het is bezig met anderezaken of heeft over elektronisch leren noggeen duidelijke mening. Het kan echter ookbewust voor deze aanpak kiezen en dit pro-ces juist koesteren. L aat die duizend bloe-men maar bloeien.De individuele docent heeft tijdens het bot-

tom-up stadium veel vrijheid. Als hij/zij een

bepaald college vakinhoudelijk gezien oporde heeft, kan alle energie gestopt wordenin het ontwikkelen van elektronische leerob-jecten. De docent gaat zelf met een auteur-programma aan de slag en kan daarbij nieu-we talenten ontwikkelen als grafischontwerper, fotograaf, beeldbewerker, enz.De ervaring leert dat dit wel steeds meer(vrije) tijd kost!

154

HOOF DSTU K 15 | DEEL 5

voor docenten

• Realiseer je dat je vakinhoudelijke endidactische kennis é n je enthousiasme overelektronisch leren je sterkste punten zijn.• Onderken ook je minder sterke punten enzoek daar hulp bij.• Kijk goed rond en probeer te leren vanwat er in de wereld al allemaal op dit gebiedgebeurt.• Zie je activiteiten vooral als een experi-ment waar veel van geleerd kan worden(door de docent zelf, door de organisatie);het is normaal dat niet alle experimentenslagen. Zorg dat je ervaringen ook de restvan de organisatie bereiken.• Onderhoud open contacten met naastecollega's, specialistische diensten van deeigen instelling (onderwijskunde, ICT), pro-jectleiders van vergelijkbare projecten, hetonderwijsbestuur; communiceer óók overmoeilijkheden en tegenvallers.• Doe niet alles in je eentje, maar richt eengroep op; maak je resultaten niet teveel vanje persoon afhankelijk.• Doe niet teveel nieuwe dingen tegelijk(nieuw type hardware, nieuw platform,nieuwe auteurstaal, nieuw didactisch con-cept, nieuw vakgebied).• Ook al ga je het nieuwe leerobject zelftoepassen, zie het toch steeds als een pro-duct dat je weliswaar zelf ontwikkelt, maardat daarna overgedragen wordt aan eenander.• Organiseer het werk als een project.

voor onderwijsbestuur

• Juich innovaties door docenten toe, maarbenadruk dat het om kleine experimenten,pilots, proeftuinen en dergelijke gaat.• Bevorder dat experimenten op een cen-traal punt worden aangemeld en publiceerregelmatig een overzicht van lopende expe-rimenten.• Organiseer de beschikbaarheid van vrijblij-vend advies op het gebied van projectmatigwerken en ICT.• Organiseer uitwisseling van ervaringentussen de experimenten onderling en metde rest van de organisatie.• Stel metadata vast om elektronische leer-objecten te beschrijven en publiceer eencatalogus van elektronische leerobjecten diegereed zijn voor gebruik. • Organiseer óók de discussie over onder-wijsvernieuwing in het algemeen (dus bre-der dan alleen de toevallige verzamelingexperimenten en dieper dan alleen de inzetvan ICT).

Tips voor tijdens het bottom-up stadium

2.2 Omslag

Vroeg of laat komt er een omslag en gaathet onderwijsbestuur zich meer met elektro-nisch leren bemoeien. De aanleiding daar-toe kan zowel positief als negatief zijn. Tweemogelijke scenario's:

• P ositieve aanleiding - Mede dankzij deexperimenten heeft de organisatie het nodi-ge geleerd op het gebied van elektronischleren. De visie van het onderwijsbestuur opelektronisch leren begint vorm te krijgen.Het bestuur zet een bepaalde koers uit enwil uiteraard dat alle activiteiten op ditgebied daar op aansluiten. Die koers zaloverigens eerder een ontwikkelrichting zijn,dan een gedetailleerde blauwdruk. Voor datlaatste is zowel de wereld van het onderwijsen van het elektronisch leren als die van deICT te veel in beweging en nog te weinigvoorspelbaar.• Negatieve aanleiding - Niet alle duizendbloemen bloeien even goed. Sommige ver-welken, bijvoorbeeld omdat het beherenervan niet goed geregeld is. Studentenkomen met kritiek omdat het aanbod aanelektronische leerobjecten zo een lappende-ken is. De vraag komt op of de organisatoevan al die inspanningen wel zo veel wijzer isgeworden.

De omslag is herkenbaar aan het feit dat hetonderwijsbestuur een duidelijker positiekiest en richting geeft aan het verdere ver-loop van het innoveren met ICT. De organi-satie verkeert qua innovatie nu in het top-

down stadium.

2.3 Top-d ow n

Het onderwijsbestuur gaat het innoverenaanpakken. Een mogelijk scenario hierbij is:• Uitgangspunten voor de rol die elektro-nisch leren binnen het curriculum moet krij-gen liggen vast.• Er komt een model voor het ontwikkelenvan nieuwe elektronische leerobjecten en erworden kwaliteitseisen gesteld.• Niet alleen de docenten, maar ook ande-re disciplines zullen een rol gaan spelen(onderwijskundige, grafisch ontwerper, inter-actieve mediadeskundige, systeemontwer-per, programmeur).• Er wordt een standaard afgesproken voorde te gebruiken computerprogramma's.• Er wordt gewerkt aan een infrastructuurvoor het gebruiken, ondersteunen en on-derhouden van de leerobjecten.• Verantwoordelijkheden en bevoegdhedenworden in kaart gebracht en geldstromengeregeld.• Het innoveren wordt centraal en planma-tig aangepakt en wordt steeds meer eenonderdeel van de reguliere bedrijfsvoering.

De individuele docent heeft in het top-down

stadium minder vrijheid dan voorheen. Ervindt van bovenaf meer sturing plaats en erkomen ook andere disciplines aan tafel.Tegelijkertijd wordt de ondersteuning beter,hoeft iemand niet meer in zijn/haar eentjeaan te modderen en gaat de organisatie alsgeheel wat efficië nter om met haar tijd.

155

DEEL 5 | HOOFDSTUK 15

3. Projectmatig werken

Het zelf ontwikkelen van elektronische leer-objecten is voor docenten vaak een onbe-kende activiteit en vrijwel altijd een uiterstcomplexe zaak. Je moet met een groot aan-tal factoren rekening houden zoals materie-kennis (het vakgebied), didactiek, mens-computer interactie, visuele vormgeving,eventueel ook animatie-, video- en audio-techniek en las t-but-not-leas t computerpro-grammatuur. Bovendien veranderen detechnische mogelijkheden waar je bij staat.Een enkel individu zal zelden al deze terrei-nen voldoende beheersen. W at betekent ditvoor onze aanpak?Om verder te komen dan een interessanteleerervaring (voor de docent) en op eenzeker moment een elektronisch leerobject tekunnen opleveren waar studenten mee kun-nen werken zijn méér deskundighedennodig dan doorgaans in één persoon te vin-den zijn. Ook is een georganiseerde maniervan samenwerken gewenst.

3.1 Deskundigheid

De docent die een elektronisch leerobjectwil ontwikkelen doet er goed aan een lijstjeop te stellen van de benodigde deskundig-heden om vervolgens na te gaan waar dezedeskundigheid vandaan moet komen. Insommige deskundigheden kan hij/zij zelfvoorzien. Voor andere kan wellicht eenberoep gedaan worden op directe collega'sof collega's van specialistische diensten(onderwijskunde, ICT) uit de eigen onder-wijsinstelling. Ook hoort het intern of externuitbesteden van werkzaamheden tot demogelijkheden. Voor dat laatste zal betaaldmoeten worden. Daar staat echter tegen-over dat er dan ook hardere eisen gesteldkunnen worden aan deze leveranciers. Hetuitbesteden van dit soort werkzaamheden isoverigens ook weer een vak apart. Dat is duswéér iets om op het lijstje van benodigdedeskundigheden te zetten! Hetzelfde geldtook voor het organiseren van dit geheel.

156

HOOFDSTUK 15 | DEEL 5

Tips voor tijdens het top-down stadium

voor docenten

• Realiseer je dat de ontwikkeling van elek-tronisch leren in een ander stadium verkeertdan voorheen;• Concentreer je op het meest waardevollevan je eigen kennis en inzichten op hetgebied van elektronisch leren en tracht datin te brengen in de nieuwe organisatiebredeinitiatieven;• W ees bereid afstand te doen van je eigenelektronische leerobjecten, je eigen favorieteauteurprogrammna, enz. Ze hadden een tij-delijke functie en hebben hun tijd gehad;• Realiseer je dat zodra innoveren een regu-lier proces geworden is er weer andere ter-reinen opdoemen waarop het bottom-upinnoveren weer starten kan.

voor onderwijsbestuur

• Betrek alle belanghebbenden bij het totstand komen van een gedeelde visie op e-learning en communiceer die naar allebetrokkenen;• Ontwikkel een kader voor een implemen-tatietraject dat rekening houdt met zoweltechnische as organisatorische aspecten.• Maak duidelijk volgens welke procedurede organisatie beslist welke elektronischeleerobjecten ontwikkeld worden en waar detaken en bevoegdheden liggen voor die ont-wikkeling;• Maak duidelijk hoe de ontwikkelde elek-tronische leerobjecten ingezet kunnen gaanworden en hoe beheer, gebruikersonder-steuning en onderhoud geregeld zijn.• G eef innoveren van leermateriaal een per-manente plaats in de organisatie. Maak dui-delijk hoe de individuele docenten daaraankunnen bijdragen. W aardeer dat.

3.2 Organisatie

Het ontwikkelen van een elektronisch leer-object is geen routineklus waarvoor een vastrecept bestaat. Daarvoor is het te uniek ente complex. Dat betekent echter niet dat dedocent en degenen die hem/haar bijstaannu maar improviserend te werk moetengaan. Het gevaar bestaat dat je dan voort-durend in kringetjes ronddraait omdat nueenmaal alles met alles samenhangt. Dedenkprocessen en/of discussies die dat ople-vert kunnen voor de groep heel interessantzijn, maar ze leiden zelden tot concreteresultaten. Ik pleit daarom hier voor eenorganisatie van het werk in de vorm van eentijdelijke organisatievorm gericht op hetbereiken van een concreet resultaat metbehulp van een beperkte hoeveelheid tijd,menskracht en geld: een project. Doorgaans is die organisatievorm eengroep, i.c. een projectgroep, maar ook alsde docent alles in zijn/haar eentje blijftdoen, valt er nog projectmatig te werken.

Kenmerken van projectmatig werken zijn:• Er is een "opdrachtgever" met wie ook opgezette tijden gecommuniceerd wordt. Ook

als een docent geheel op eigen initiatief ietsonderneemt is het verstandig om bijvoor-beeld de leerstoelhouder als opdrachtgeverte beschouwen en deze op de hoogte tehouden en bij bepaalde keuzes te betrek-ken.• De "opdracht" bestaat uit een afgebaken-de taak die in een bepaalde periode en meteen bepaalde inzet aan menskracht en gelduitgevoerd moet worden. Ook voor de indi-viduele docent is het goed om helder voorogen te hebben w·t het resultaat vanzijn/haar inspanning moet zijn (kwaliteitsei-sen) en hoeveel tijd (en budget) er maximaalmee gemoeid mag zijn.• Om de complexiteit van het werk han-teerbaar te houden, wordt het werk opge-splitst in bepaalde fasen die achter elkaarworden afgewerkt. Tijdens elke fase wordenbepaalde weloverwogen keuzes gemaakt.Daarop wordt later in principe niet meerteruggekomen (gepasseerde stations).• Aan het begin van iedere fase wordtgedetailleerd vastgelegd uit welke activitei-ten de fase bestaat en waar die uiteindelijkin zullen resulteren.• Aan het einde van elke fase worden de

157


Hulpmiddel om benodigde en beschikbare deskundigheid in kaart te brengen

Deskundigheid In hoeverre nodig? W ie gaat deze desk undigheid inbrengen?

Docent Collega's Specialisten Extern

Materiekennis ............................................. .......................... .......................... .......................... ......................

Vakdidactiek ............................................. .......................... .......................... .......................... ......................

Mens-computer interactie ............................................. .......................... .......................... .......................... ......................

Grafische vormgeving ............................................. .......................... .......................... .......................... ......................

Animaties ............................................. .......................... .......................... .......................... ......................

Audio/Video ............................................. .......................... .......................... .......................... ......................

Programmatuur ............................................. .......................... .......................... .......................... ......................

Uitbesteden ............................................. .......................... .......................... .......................... ......................

Organisatie ............................................. .......................... .......................... .......................... ......................

resultaten gedocumenteerd en besprokenmet de opdrachtgever. Dit kan tot bijstellin-gen in het verdere verloop van het projectleiden.

3.3 Fasering

De fase-indeling die ik hier hanteer is: initia-tieffase, definitiefase, ontwerpfase, realisa-tiefase, invoeringsfase en de gebruik- enbeheerfase. De initiatieffase wordt niet tothet eigenlijke project gerekend. Deze faseomvat namelijk de voorbereidende werk-zaamheden die leiden tot het project. Ookde gebruiken beheerfase wordt niet tot heteigenlijke project gerekend. Het beheren enonderhouden van het ontwikkelde leerob-ject is geen tijdelijke activiteit, maar meereen vaste taak voor bepaalde medewerkers.In de uitleiding van deze bijdrage kom ikdaar nog op terug. Het eigenlijke projectbestaat zodoende uit een definitiefase, ont-werpfase, realisatiefase, invoeringsfase. Detijdverhouding tussen die fasen is globaal1:2:4:1.In de praktijk komt het ook voor dat ont-werp- en realisatiefase elkaar een aantalmalen beurtelings afwisselen. Die aanpakkan echter gemakkelijk leiden tot uitlopen inde tijd of inleveren in kwaliteit. Ik ga hierkortheidshalve niet verder op in. Overigenszijn niet in elke fase alle deskundighedeneven hard nodig. Wel is in alle fasen iemandnodig die het project coördineert: de pro-jectleider.

3.4 Projectleiding

Een docent die het initiatief neemt voor hetontwikkelen van elektronische leerobjectenzal doorgaans zelf willen optreden als pro-jectleider. Dat vraagt om enkele extra activi-teiten:

• formeren van een projectgroep, zorgendat de projectgroep een team wordt;opstarten van het project, bijvoorbeeld doormiddel van een goed voorbereide "kick-off"-meeting;• identificeren van alle belanghebbenden("stakeholders") bij het project en bepalenwaarover, wanneer en hoe met deze betrok-kenen gecommuniceerd moet worden;mogelijke belanghebbenden zijn de "op-drachtgever", het onderwijsbestuur, naaste

collega's, administratie, studenten, project-leiders van soortgelijke projecten, eventueleleveranciers;• opstellen van plannen voor de voortgang,de kwaliteit, de inzet van menskracht en debesteding van het budget; informeren vanalle betrokkenen over de plannen;• volgen van de voortgang; bewaken vankwaliteit, inzet, budgetuitputting en derge-lijke;• coördineren van werkzaamheden bijvoor-beeld via een periodiek projectgroepoverleg;• uitbesteden van werkzaamheden aaninterne of externe instanties (opstellen spe-cificaties, werven en selecteren van leveran-ciers, calculeren werkzaamheden, opstellencontract, beoordelen resultaten, oplossengeschillen);• afronden van de ene projectfase en over-gaan op de volgende.

Ook projectleiden is een vak apart. Dedocent/initiatiefnemer doet er daarom goedaan zich vóór de start van het project af tevragen of hij/zij de rol van projectleider kanen wil vervullen. Misschien kan dat welbeter iemand anders doen. De docent kanzich dan concentreren op de eigen sterkepunten, bijvoorbeeld vakinhoudelijk en vak-didactisch. Een overzicht van de werkzaam-heden per projectfase, is weergegeven in detabel op de uitslaande flap aan de voorkantvan dit boek.

4. Definitiefase

De eerste fase in het ontwikkelen van eenelektronisch leerobject is de definitiefase. Indeze fase moet duidelijk worden wat hetaan te pakken "probleem" is en in welke rich-ting een "oplossing" ontwikkeld gaat wor-den.Het is heel verleidelijk om de definitiefasemaar over te slaan. Een nieuwe project-groep wil graag de handen uit de mouwensteken, geen tijd verliezen aan schijnbare trivialiteiten, het veelbelovende auteurpro-gramma snel aanschaffen of een program-meur contracteren en aan het programme-ren slaan. Later in het project kan dan echterveel tijd en geld verloren gaan als blijkt datniet iedere projectdeelnemer vanaf de startop dezelfde lijn zat, als steeds weer dezelf-de discussies terugkomen, als blijkt dat net

158


de verkeerde hulpmiddelen zijn aangeschaftof een minder gelukkige keuze gemaakt isbij het inhuren van derden. De tijd die meninvesteert in een definitiestudie zal zichzelfzeker terug verdienen.

4.1 Planning

Zoals iedere fase, hoort ook de definitiefasete beginnen met het opstellen van een plan-ning waarin de activiteiten staan die tijdensdeze fase moeten worden uitgevoerd. Kortsamengevat gaat het daarbij om:

• uitwerken van de doelstelling• aangeven kennisdomein en onderwijs-kundige uitgangspunten• bedenken van globale oplossingsrichtin-gen• kiezen van één bepaalde oplossingsrich-ting• formuleren metadata• afronden van de definitiefase

4.2 Projectdoelstelling

Bij het uitwerken van de doelstelling van hetontwikkelproject gaat het om het beant-woorden van de volgende vragen: Om welkleerobject gaat het (welk curriculum, welkecursus, welk college of welk onderdeel vaneen college)? Voor welke doelgroep is ditbestemd (voorkennis, opleidingsniveau)?Hoe vindt dit onderwijs op dit momentplaats? Wat zou anders en beter kunnen?Wat heeft ICT daarbij te bieden? Hoe gaathet verbeterde onderwijs in zijn werk? Watzijn zodoende de belangrijkste doelen voorhet ontwikkelen van de nieuwe elektroni-sche leerobjecten? Concrete antwoorden opdeze vragen zijn richtinggevend bij de vol-gende fase en maken het aan het einde vanhet project gemakkelijker om het resultaatervan te evalueren.

4.3 Uitgangspunten

Het aangeven van het kennisdomein leidttot het precies aangeven van wat wél enwat niet tot de vakinhoud behoort, zodatdit later in het project geen discussiepuntmeer hoeft te zijn.De onderwijskundige uitgangspunten zijnde resultaten van een bezinning op de leer-

doelen, de leerstijl(en) die het elektronischeleerobject moet ondersteunen, de leerroutesdoor het kennisdomein die daar bij horen,de moeilijkheidsgraad en de tijd die eendoorsnee student voor het werken met hetleermateriaal nodig heeft.

4.4 Oplossingsrichting

Doelstelling, domein en didactiek kunnensamen gezien worden als de omschrijvingvan het "probleem". Bij dit probleem hoorteen passende oplossingsrichting gevondente worden. Die bestaat uit de antwoordenop twee vragen:

1. Wat voor een soort product gaan wemaken?2. Welke technische oplossing kiezen wedaarvoor?

Het product dat we willen gaan makenbeschrijven we in termen van aggregatie-niveau, type leerobject, interactiegraad enmediagebruik:

• Het aggregatieniveau geeft aan hoe com-plex het elektronisch leerobject gaat wor-den. Hebben we het over een complete cur-sus, een college, een onderdeel van eencollege of over een stukje daaruit dat verderniet meer (zinvol) op te delen is, een "ato-mair" leerobject?• Het type leerobject duidt op de functievan het leerobject binnen het onderwijs: ishet een presentatie, een experiment, eensimulatie, een zelftoets, een toets?• De interactiegraad geeft aan hoe intensiefde communicatie tussen gebruiker en leer-object gaat verlopen. Is de gebruiker daarinactief of passief? • Met het mediagebruik geven we aanwelke soorten media we binnen het elektro-nische leerobject willen gaan gebruiken, bij-voorbeeld geschreven woord, commentaar-stem, foto, schema, grafiek, tabel, animatie,video.

159


Als duidelijk is, wat voor een product wewillen maken, zijn er ook op technischgebied nog een groot aantal keuzes temaken. Gaat de gebruiker een aparte com-puterapplicatie gebruiken of werkt hij/zijmet een "web browser"? Distribueren we deapplicatie op CD-ROM, is deze te downlo-aden vanaf het Internet, of vindt een sessiedeels op een server plaats (en alle mengvor-men die daarbij mogelijk zijn)? Voor eenoverzicht van verschillende mogelijke tech-nische oplossingsrichtingen verwijs ik graagnaar het schema op de uitslaande flap ach-terop dit boek.Met dit alles hangt ook de vraag naar deontwikkelomgeving samen. Daarmee be-doelen we de programmatuur (auteurpro-gramma, programmeertaal) die gebruiktwordt bij het realiseren van het elektroni-sche leerobject.Leveranciers van ontwikkelomgevingen we-ten hun product vaak goed te verkopen. Zegeven een indrukwekkende demonstratie endoen de suggestie dat een docent die nooitheeft leren programmeren, dat met h˙ nproduct binnen de kortste keren voor elkaarkrijgt. Het is immers nog slechts een kwestie

van knippen en plakken en klikken gewor-den. Ik wil hier tegen waarschuwen. Het iszeker positief als een docent een ontwikkel-omgeving zelf wat gaat verkennen. Hij/zijkan daardoor een indruk krijgen van de"look & feel" en van de mogelijkheden vandat product. Het leren doorgronden en effi-ciënt kunnen toepassen van alle functionali-teit van een auteurprogramma is echter eentijdrovend proces, zeker als iemand nooiteerder programmeerervaring heeft opge-daan. Het voordeel van het interactievegebruikersinterface boven het rechtstreeksschrijven van programmacode is ook maarbeperkt. Weliswaar hoeft men de gramma-ticaregels van de programmeertaal nietmeer te kennen, maar de speciale maniervan denken die aan het programmerenvooraf gaat, zal men wel degelijk moetenkunnen beheersen. Een docent zal er vaakgoed aan doen hiervoor iemand met de juis-te kennis en ervaring in te schakelen.Bij de keuze van een ontwikkelomgeving ishet verstandig niet op eerste indrukken af tegaan, maar hulp te vragen van een deskun-dige die eens kritisch "onder de motorkap"wil kijken.

160


Aggregatieniveaus van elektronische leerobjecten

Niveau Omschrijving V oorbeeld

1 Atomair leerobject Afbeelding van een schema2 Onderdeel van een college Webpagina met tekst en afbeeldingen3 College Complete "les" voor zelfstudie4 Cursus Complete cursus

161


Kritische vragen bij het beoordelen van ontwikkelomgeving X

Vraag Commentaar

4. Hoe is de reputatievan X in de vakpers?

Er bestaan duizenden ontwikkelomgevingen die ongetwijfeldelk een schare trouwe aanhangers hebben. Belangrijk is dat erenige "evidence" is dat X een betrouwbaar product is.

5. Zijn er binnenNederland genoeg leve-ranciers te vinden die Xkunnen ondersteunen?

Afhankelijkheid van een enkele (buitenlandse) leverancier isongewenst. Beter is het als meerdere leveranciers in de naasteomgeving diensten op basis van X kunnen verlenen (bijv.coachen tijdens het programmeren, dan wel de programme-ring geheel overnemen).

6. Wat zijn de kostenvoor het ontwikkelenmet behulp van X?

De eenmalige aanschafkosten van een ontwikkelomgeving zijnvaak nog te overzien. Veel groter zijn doorgaans de kosten(tijd en geld) om mensen met een ontwikkelomgeving te lerenwerken.

3. Is X in staat om tekst-bestanden in te lezen enweg te schrijven en zo jaw·t voor tekst (plat ofXML)?

Vanwege de omvang van sommige elektronische leerobjectenen de vaste patronen die daarbinnen te onderkennen zijn, ishet vaak efficiënter om te werken naar een "data driven"oplossing. Daarbij wordt veel informatie die in de applicatiegebruikt wordt en mogelijk ook een deel van de besturingautomatisch uit tekstbestanden of een database gehaald (tij-dens het ontwikkelen en misschien ook tijdens het lateregebruik). Het alternatief is dat een programmeur alle tekstenéén voor één met knippen en plakken in de applicatie moetopnemen. Extra voordeel van de aanpak via tekstbestanden:deze aanpak maakt het voor mensen die niet vertrouwd zijnmet X, maar wél met een tekstverwerker, mogelijk om tekstente actualiseren. XML-teksten (een standaard voor tekstgestructureerd met labels) hebben bovendien het voordeel datze voor de programmatuur waarmee ze ingelezen wordenveel informatiever kunnen zijn dan platte teksten.

2. Werkt X op basis vaneen programmeertaalwaar de gebruiker van X,i.c. de programmeur,toegang toe heeft?

Veel ontwikkelomgevingen werken via een grafische gebrui-kersinterface. De gebruiker bouwt al knippend, plakkend enklikkend een applicatie op. Dat lijkt mooi, maar in de praktijkkun je vroeg of laat problemen tegenkomen die op dezemanier niet op te lossen zijn. Je hebt dan toegang tot de lees-bare broncode van je eigen applicatie nodig, zodat jedesnoods met een eenvoudige tekstverwerker aanpassingenkunt plegen of repeterende acties efficiënter kunt programme-ren. Niet alle ontwikkelomgevingen bieden die mogelijkheid.

1. Is met X het beoogdeproduct te realiseren?

Een ontwikkelomgeving is doorgaans gericht op een bepaaldtype toepassingen. Een product om toetsen te ontwikkelen isdaarom minder geschikt om groepssimulaties te maken. Ga afop documentatie van de leverancier, verwijzingen naar voor-beeldprojecten en eigen waarneming van de ervaringen vanandere gebruikers van deze ontwikkelomgeving.

Doorgaans zal de initiatiefnemer al eenbepaalde oplossingsrichting in gedachtenhebben. Toch is het goed om daar niet tesnel voor te kiezen, maar eerst in kaart tebrengen welke oplossingsrichtingen nogméér in aanmerking komen en dan vervol-gens van elk de voor- en nadelen af tewegen. Alle voor- en nadelen zijn te herlei-den tot criteria en een bijbehorende score(bijvoorbeeld --, -, +-, +, ++). Door ge-wichten aan de criteria toe te kennen en descores in getallen te vertalen, kan een genu-anceerde eindscore per alternatief berekendworden.

Om scherp te krijgen wat de beoogdemeerwaarden van het te ontwikkelen elek-tronische leerobject is, zou één van de"alternatieven" de huidige situatie kunnenzijn en een ander alternatief de verbeterdesituatie maar dan zonder gebruik te makenvan ICT.

162


Hulpmiddel voor het beoordelen van alternatieven

Criterium Gewicht [%] Alternatief-1: ... Alternatief-2: ... Alternatief-3: ...

Toelichting Score Gewogen Toelichting Score Gewogen Toelichting Score Gewogen

score score score

1. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

2. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

3. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

4. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

5. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

6. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

7. .......... .......... .......... .......... .......... .......... .......... .......... .......... ..........

Totaal: 100 % Totaal: .......... Totaal: .......... Totaal: ..........

7. Zijn de met X ontwik-kelde producten vrij tegebruiken?

Soms hoort bij een ontwikkelomgeving ook een productieom-geving van dezelfde producent. Dat betekent dat je om hetontwikkelde elektronische leerobject daadwerkelijk te kunnengebruiken nog wat extra programmatuur nodig hebt en daar-voor moet betalen, vaak afhankelijk van de oplage!

4.5 Metadata

Metatadata zijn data over data ofwel debeschrijvende gegevens van ons elektro-nisch leerobject in wording. Ze zijn nodigom t.z.t. het leerobject in een productenca-talogus op te kunnen nemen of in zoekma-chines. De internationale standaard (IMS)op dit gebied is nogal uitgebreid. Rechten-Online-projecten beperken zich daarom toteen subset daarvan.Het is een goede zaak om al tijdens dedefinitiefase de metadata van het te ontwik-kelen leerobject zo goed mogelijk vast teleggen. Niet alleen schept dat duidelijkheidbinnen de projectgroep, het zal blijken datook anderen tijdens het project voortdurendom nadere informatie vragen. Vaak kan danvolstaan worden met een beknopte samen-vatting van het op te leveren product in devorm van de voorlopige metadata.

4.6 Afronding

De definitiefase eindigt met het opstellenvan een globale planning en begroting (tijd

en geld) voor de rest van het project. Verderwordt een rapport samengesteld waarin allewerk uit de definitiefase gedocumenteerdwordt op een wijze die ook voor buiten-staanders begrijpelijk is. Ook de metadataliggen daarin vast. Dit rapport is niet alleenbedoeld voor het archief. Het vormt de basisvoor overleg met de opdrachtgever en hetvertrekpunt voor alle projectdeelnemers bijde werkzaamheden in de volgende fase vanhet project: de ontwerpfase. De resultatenvan de definitiefase zijn daarmee gefixeerd.Alleen in extreme gevallen komen we daarlater nog op terug.

5. Ontwerpfase

Na de definitiefase volgt de ontwerpfase. Deresultaten van de definitiefase gelden hierbijals een gegeven. Het gaat er nu om eenconcept (samenhangend idee, grondvorm)voor het elektronische leerobject te ontwer-pen. Vervolgens wordt dit concept tot indetail uitgewerkt. Dit leidt tot een specifica-tie die zo gedetailleerd is dat degenen die

163


het leerobject moeten gaan realiseren daar-mee uit de voeten kunnen.Ook bij deze fase doet zich de verleidingvoor om haar maar over te slaan. De aange-schafte ontwikkelomgeving (lees: hetauteurprogramma) werkt toch zó gemakke-lijk dat we meteen kunnen gaan beginnenmet programmeren? Vergeet het maar. Jemoet vrij kunnen nadenken over de grond-vorm van het te ontwikkelen leerobject enop dat moment niet te veel last hebben van(je perceptie van) de mogelijkheden van deontwikkelomgeving. Bovendien is het nogmaar de vraag of de gebruikte ontwikke-lomgeving de mogelijkheid heeft om eensystematische wijziging met een kleineingreep integraal door te voeren.

5.1 Planning

De ontwerpfase begint met het opstellenvan een planning waarin de volgende activi-teiten centraal staan:

• Conceptualiseren• Specificeren - globaal• Systeem• Proces

• Specificeren - details• Functionaliteit• Inhoud• Vormgeving• Techniek

5.2 Conceptualiseren

Het conceptualiseren is een creatief procesdat leidt tot een concept (grondvorm,samenhangend idee, basisfilosofie) voor hette ontwikkelen leerobject. Het kennisdo-mein en het leertraject (kaart en routes) zijnin het concept terug te vinden. Het isbelangrijk om niet het eerste idee meteenals het beste te zien. Via creatieve technie-ken en bij voorkeur met meerdere personenzijn alternatieve concepten te bedenken(divergeren). Uiteindelijk valt dan uit dealternatieven een keuze te maken die hetmeest past bij de eisen die voortvloeien uitde definitiefase (convergeren). Dit conceptmoet niet in alleen in woorden op papierkomen, maar liefst ook visueel. De op-drachtgever moet het kunnen toetsen.Centraal in een concept staat vaak eenmetafoor, een beeld uit een andere situatie

dat gebruikt wordt om het nieuwe conceptinzichtelijk te maken. Voorbeelden vanmetaforen zijn:

• een stad met daarin burgers, bedrijven enbestuurders waar je rond kunt wandelen,informatie verzamelen, communiceren endiensten laten verlenen;• een bibliotheek waar veel informatie in opte zoeken is;• een boek met een hiërarchisch geordendeinhoud plus een aantal handige alfabetischgeordende registers om snel langs diverseingangen bij bepaalde informatie te kunnenkomen;• een huis met verschillende ruimten die elkeen eigen functie hebben;• een voertuig waarmee men op reis kangaan;• een storyboard dat een schets geeft vanopeenvolgende scè nes;• een boom met takken, vertakkingen enblaadjes waarin je je steeds volgens dezetakken van blaadje naar blaadje kunt bege-ven;• een matrix als een verzameling cellen dietweedimensionaal gerangschikt is en vanwaaruit je steeds vier kanten op kunt, óf eenkubus met driedimensionale rangschikkingen zes bewegingsrichtingen;• een landkaart van het kennisdomein enverbindingen om van het ene onderdeelnaar het andere te gaan.

Een concept hoeft beslist niet volledignieuw en nooit vertoond zijn. Het kan heelacceptabel zijn om een bestaand conceptdat elders succesvol is gebleken over tenemen. Het ontwikkelen van een elektro-nisch leerobject blijft ook zonder een nieuwen oorspronkelijk concept al complexgenoeg. Soms wordt ook een bestaand con-cept wat verder opgerekt en uitgebreid.Soms weet iemand een nieuw concept tecreëren door het beste van twee bestaandeconcepten (mogelijk uit heel verschillendetoepassingen) te combineren.

Als voorbeeld beschrijf ik hier hoe hetopstellen van een concept voor een groeps-simulatie kan verlopen:1. Inventariseren van de actoren (individu-en, groeperingen, instanties, organisaties),

164


procedures, mechanismen en causale ver-banden die in de te simuleren werkelijkheideen rol spelen.2. Reduceren van de complexiteit. Het gaater niet om de werkelijkheid tot in de kleinstedetails na te bootsen in een simulatie. Desimulatie dient immers een bepaald leer-doel. Het gaat erom die elementen uit dewerkelijkheid in de simulatie te behoudendie relevant zijn voor het realiseren van datleerdoel.3. Uitwerken van de actoren:a. Wat zal hun uitgangsituatie zijn bij destart van een simulatiesessie?b. Wat is hun handelingenrepertoire in rela-tie tot de overige actoren?c. Wat is de meest gunstige en de meestongunstige uitkomst van de simulatie voorde betreffende actor?d. Over welke informatie moet actor kun-nen beschikken en waar moet die vandaankomen? 4. Visualiseren van de stand van zaken. Hetspeelbord bij klassieke gezelschapsspelengeeft tijdens een spelsessie voortdurend deactuele stand van zaken aan. Ook bij hetconceptualiseren van een simulatie helpt het

om een speelbord te ontwerpen. Wat zoudaarop gevisualiseerd moeten zijn? Welkdeel van dat speelbord is voor welke actorzichtbaar? 5. Rollen toekennen. Als we op deze wijzete weten zijn gekomen uit welke compo-nenten onze microwereld bestaat, kunnenwe bedenken hoe het gedrag van elke actorgesimuleerd gaat worden. Wordt het eenrol voor een individuele student of voor eenklein studententeam? Wordt de rol gespeelddoor een docent (niet om daar zelf zo veelvan te leren, maar omdat dat het niet zinvolis als studenten deze spelen)? ” f wordt deactor gerepresenteerd door een algoritme,een stukje computerprogramma, dat zijngedrag volledig voorschrijft?6. Facilitator. Het is tenslotte heel gebruike-lijk dat een docent als facilitator optreedt tij-dens een simulatiesessie. Vanuit deze spe-ciale rol kan hij/zij bij de start misschien welvoor een bepaalde uitgangssituatie enopdracht kiezen en tijdens de sessie het ver-loop van de sessie beïnvloeden door al danniet voorbereide "events" te laten plaatsvin-den. Ook zorgt de facilitator voor briefingen debriefing van de deelnemers.

165


7. Procesbeschrijving. Nadat bovenstaandestappen hebben geleid tot een systeemcon-cept van de simulatie, wordt het conceptverder afgerond met een procesbeschrij-ving, de volgorde van handelingen die bin-nen de simulatiesessie mogelijk is.

Het kan geen kwaad om bij het conceptu-aliseren van een ander elektronisch leerob-ject dan een groepssimulatie, bijvoorbeeldeen elektronisch leerboek, toch eens te pro-beren volgend bovenstaande procedure tewerk te gaan. Het nadenken over het wer-ken met een elektronisch boek als een sessieof "experience" in een microwereld levertmisschien wel een veel interessanter elektro-nisch leerobject op dan de metafoor van hetpapieren boek.

5.3 Specificeren - globaal

Het concept wordt verder uitgewerkt in devorm van specificaties. Degenen die wetenwat het nieuwe leerobject moet bevattenstellen de specificaties op. Degenen die hetobject of onderdelen daarvan gaan realise-ren maken daar gebruik van. De indelingvan de specificaties en het gewenste detail-niveau, hangen uiteraard ook van de ont-vangende partij af. Een volslagen buiten-staander aan wie een taak wordt uitbesteedheeft meer instructies nodig dan een naastecollega.Een bruikbare indeling bestaat uit hetbeschrijven van het te ontwikkelen leerob-ject vanuit twee gezichtspunten: systeem enproces. De beschrijving als systeem is sta-tisch en beschrijft het leerobject als een ver-zameling functies plus een globale visie opde vormgeving. De beschrijving als proces isdynamisch en beschrijft hoe een sessie methet leerobject gaat verlopen, de volgordewaarin de functies aangeroepen kunnenworden en de condities die bepalend zijnvoor die volgorde.De systeembeschrijving somt de primaire(op leren gerichte) en de secundaire (onder-steunende) functies van het leerobject op.Een hiërarchische indeling van de primairefuncties is handig om het overzicht te bewa-ren en om gemakkelijk te kunnen nagaan ofde beschrijving compleet is. Voorbeeldenvan secundaire functies zijn de mogelijkheidom automatisch een logboek bij te houden,

de diverse navigatiemogelijkheden (ook via"site map" en zoekfunctie) en het help-sys-teem.De procesbeschrijving geeft aan hoe eensessie met het leerobject verloopt. Welke"flow" wordt gevolgd? Welke conditiesbepalen de afloop? Wat ligt in de handenvan de gebruiker en wat wordt bepaalddoor het leerobject? Voor onderdelen vande procesbeschrijving kan gebruik gemaaktworden van stroomschema's. Als dezeslechts uit de drie basisvormen concatena-tie, selectie en iteratie worden opgebouwd(eventueel genest), voorkomt men dat hetstroomschema op een onontwarbaar bordspaghetti gaat lijken.

Basisvormen voor gestructureerde

stroomschema's

5.4 Specificeren - details

De functies van het leerobject dienen steedsverder gedetailleerd te worden. Op eenzeker moment wordt dan het niveau bereiktvan atomaire leerobjecten: een videofrag-ment om te bekijken, een vragenlijstje om inte vullen, een tekst om te lezen, enzovoort.Van deze leerobjecten dient nu de inhoudverder gespecificeerd te worden. Is het eenbestaand videofragment? Zo ja, welk dan enwaar is het te vinden? Zo nee, schrijf daneen script met alle noodzakelijke aanwijzin-gen voor degene die dat fragment moetgaan maken. Uiteindelijk wordt elke "scène"uit onze productie beschreven en ontstaateen compleet "draaiboek" aan de handwaarvan de losse onderdelen van het elek-tronische leerobject gemaakt kunnen wor-den.Ook de grafische vormgeving van het leer-object dient steeds verder gedetailleerd aan-gegeven te worden. Hetzelfde geldt voor de

166


Concatenatie Selectie Iteratie

167


programmatuur en de te gebruiken gege-vensstructuren, bijvoorbeeld een database.

5.5 Afronding

De ontwerpfase eindigt met een controle ofhet resultaat voldoet aan de uitkomsten vande definitiefase. Op grond van de nu meergedetailleerde inzichten wordt de globaleplanning en begroting (tijd en geld) voor derest van het project opnieuw bekeken. Allewerk uit deze fase wordt vervolgens gedo-cumenteerd in een rapport op een wijze dieook voor buitenstaanders begrijpelijk is.Doorgaans zal dit rapport enkele volumi-neuze bijlagen bevatten met daarin alle spe-cificaties van het te ontwikkelen leerobject.Dit rapport is een belangrijk hulpmiddel bijde communicatie met zowel de opdracht-gevers als met degenen die het leerobjectgaan maken. Voor de opdrachtgever is dithet laatste moment waarop deze nog kaningrijpen, vóór de tijdrovende realisatiedaadwerkelijk begint. Vergeleken met hetbouwen van een huis vormen het rapporten zijn bijlagen het complete bestek waar-mee de bouwers aan de slag gaan.

6. Realisatiefase

Na de ontwerpfase volgt de realisatiefase.Nu kan het "bouwen" van het elektronischleerobject (eindelijk) beginnen. Het gaatdaarbij niet alleen om het programmeren,maar ook om het produceren of verwervenvan inhoudelijk materiaal ("content") en hetvervaardigen of bewerken van allerlei com-ponenten zoals plaatjes, animaties, video-fragmenten. Uiteindelijk worden al dezeonderdelen geïntegreerd in het uiteindelijkeproduct. Dit zal vervolgens uitvoerig getestmoeten worden, zowel door de project-groep als door buitenstaanders, bijvoor-beeld representanten van de toekomstigegebruikers.

6.1 Planning

Ook de realisatiefase start met het opstellenvan een planning. De belangrijkste activitei-ten die daarin vermeld worden zijn:

• Inrichten ontwikkelomgeving• Creëren of verwerven van de verschillendecomponenten• content (beeld, geluid, videomateriaal, tekst)

• programmatuur• vormgeving

• Integreren van de componenten• Testen• Systeemtest• Acceptatietest

6.2 Ontwikkelomgeving

Al tijdens de definitiefase heb ik stilgestaanbij de keuze voor een bepaalde ontwikke-lomgeving. Die ontwikkelomgeving zal tij-dens de realisatiefase operationeel moetenzijn. Niet alleen betekent dit dat debetreffende programmatuur geïnstalleerd isen naar behoren werkt, maar ook dat ermensen zijn opgeleid om ermee te werken.Feitelijk kan een en ander al tijdens de ont-werpfase worden voorbereid.

6.3 Componenten

De ontwerpfase resulteert in detailspecifica-tie van alle te realiseren componenten of hetnu om inhoudelijke informatie, audiovisuele"assets" of stukjes programmacode gaat.Deze specificatie is om te zetten in een was-lijst per componentensoort. Niet alles hoeftgecreëerd te worden. Sommige beelden ofgeluidsfragmenten bevinden zich wellicht inhet archief en zijn zo te gebruiken. Anderezaken zijn tegen relatief geringe kostenelders aan te schaffen, maar hebben mis-schien in huis nog een nabewerking nodig.Tot slot is er materiaal nodig dat nog moetworden gecreëerd.Een belangrijk aandachtspunt bij hetgebruik van beelden geluidsmateriaal vanderden zijn de rechten die daar op kunnenrusten. Het kan een zeer tijdrovende kluszijn om dat allemaal precies uit te zoeken eneen dure zaak om de publicatierechten offi-cieel te verwerven. Sneller en goedkoperwerkt het als men gebruik maakt van rech-tenvrij materiaal (bijvoorbeeld verzamel-CD'smet beeldmateriaal) of met materiaal datmen zelf heeft laten vervaardigen en waar-op men zelf de rechten heeft.

6.4 Integreren

Wanneer de verschillende componentenbeschikbaar komen en stukvoorstuk nage-gaan is of ze aan de gestelde specificatiesvoldoen, kunnen ze geïntegreerd worden inhet elektronische leerobject.

6.5 Testen

Het elektronische leerobject is niet af voor-dat dit uitvoerig getest is en alle aangetrof-fen ongerechtigheden verholpen zijn. Ikonderscheid twee verschillende testen: desysteemtest en de acceptatietest. De eersttest is een interne aangelegenheid. De testmaakt gebruik van alle kennis over de inter-ne details van het systeem en wordt uitge-voerd door de projectgroep. Belangrijk isdat het product voldoet aan de specificatieszoals opgesteld in de ontwerpfase én de uit-komsten uit de definitiefase. De tweede testis de acceptatietest. Dit is een externe testwaarbij (representanten van toekomstige)gebruikers het systeem op de proef stellen.Een principieel nadeel van alle vormen vantesten is dat ze weliswaar de aanwezigheidvan tekortkomingen kunnen illustreren,maar de afwezigheid ervan nooit kunnenaantonen. Voor alle vormen van testen geldtook dat er niets te testen valt als niet vantevoren duidelijke normen worden vastge-steld waaraan de testresultaten moeten vol-doen. Bij die normen wordt met verschillen-de gezichtspunten rekening gehouden: nietalleen dat van de opdrachtgever of de toe-komstige gebruikers, maar bijvoorbeeld ookdat van de toekomstige beheerders.Het uitvoeren van een test is op zichzelf aleen klein project. Belangrijk is ook hier eengoede planning. Degenen die de tests uit-voeren moeten exact weten wat zij moetendoen, wat de correcte respons van het leer-object hoort te zijn en wat zij moeten doenals dit anders reageert. Documenteren van

de testresultaten is erg belangrijk. Niet zozeer om later aan anderen te kunnen bewij-zen dat de tests hebben plaatsgevonden,maar wel om exact te weten hoe de testsverlopen zijn en om na systeemaanpassin-gen bepaalde tests weer te kunnen herha-len. Het is handig om hiervoor een formulierte gebruiken.

6.6 Afronding

Als alle testen zijn afgerond en eventuelecorrecties ook correct zijn uitgevoerd kaneen stamkopie gemaakt worden van hetnieuwe leerobject. Dat is een CD ROM ofDVD waar de distributieversie van het nieu-we leerobject op staat inclusief een read-

me.txt bestand met nadere uitleg en eenpapieren "inlay " voor in het CD-doosje. Derealisatiefase leidt verder tot een rapportmet de broncode van de programmatuur enalle gebruikte componenten als belangrijk-ste (elektronische) bijlagen. Voor deopdrachtgever is van belang dat dit rapportverslag doet van de wijze waarop de accep-tatietest is uitgevoerd. Aan de hand hiervankan de opdrachtgever besluiten dat het ont-wikkelde product in gebruik genomen magworden. Die stap wordt gezet binnen deinvoeringsfase.

7. Invoeringsfase

De realisatiefase eindigt met de opleveringvan een stamkopie van het elektronischeleerobject. Tijdens de invoeringsfase wordtal het nodige gedaan om dit product effec-tief en efficiënt in te zetten.

7.1 Planning

Ook voor de laatste fase van het project ont-komen we niet aan het maken van een plan-ning met in dit geval als belangrijkste activi-teiten:

168


Hulpmiddel voor het registreren van testplan en testlogboek

Testplan Testlogboek

# Datum Wie? Wat? Hoe? Wanneer OK? Datum Wie? Resultaat? OK? Follow-up?

1 ......... ......... ......... ......... ......... ......... ......... ......... ......... .........

2 ......... ......... ......... ......... ......... ......... ......... ......... ......... .........

3 ......... ......... ......... ......... ......... ......... ......... ......... ......... .........

• Inrichten van de productieomgeving• Opstellen handleidingen en verzorgen vantrainingen• Reproduceren en distribueren• Overdragen van het beheer

7.2 Productieomgeving

De productieomgeving is de programma-tuur die nodig is om ons leerobject produc-tief in te kunnen zetten. Deze productieom-geving bevindt zich soms gedeeltelijk op eencentrale computer die bijvoorbeeld via hetInternet toegankelijk is ("server") én gedeel-telijk op de apparatuur van de gebruiker("client"). In andere gevallen bevindt die pro-ductieomgeving zich geheel op de appara-tuur van de gebruiker. Dit laatste is bijvoor-beeld het geval als we een leerobject via eenCD-ROM distribueren.Het inrichten van de productieomgeving opeen centrale computer kan bijvoorbeeldbestaan uit het inrichten van een "web ser-

ver" en een database. Op de apparatuur vande gebruiker is de productieomgeving somsal aanwezig, bijvoorbeeld in de vorm vaneen "web browser". Soms is het echter nodigdat de gebruiker niet alleen ons elektronischleerobject op zijn/haar apparatuur instal-leert, maar ook aanvullende programma-tuur om het vertonen van het leerobjectmogelijk te maken. Het zal duidelijk zijn datde procedure om dit te doen voor degebruiker zo simpel mogelijk moet zijn enbestand moet zijn tegen allerlei variaties inapparatuur waar gebruikers mee werken.

7.3 Handleidingen en trainingen

Voor veel elektronische leerobjecten is hetgewenst dat er een handleiding komt, elek-tronisch dan wel op papier. Het gaat daarbijom verschillende doelgroepen: studenten,docenten in de rol van begeleider, docentendie het leerobject moeten kunnen aanpas-sen, mogelijk ook administratieve functiona-rissen en zeker ook degenen die het elektro-nische leerobject gaan beheren.Behalve handleidingen kunnen ook trainin-gen nodig zijn. Het ligt aan de complexiteitvan de taak in hoeverre studenten, c.q.docenten, c.q. beheerders daar behoefteaan hebben. Als goede handleidingen eentraining overbodig kunnen maken is dat deste beter. Je voorkomt daarmee dat een trai-

ning op gezette tijden weer herhaald moetworden in verband met personele wisselin-gen.

7.4 Reproduceren en distribueren

De stamkopie van het elektronische leerob-ject zal verder gereproduceerd moeten wor-den. Dat gebeurt misschien in enkelvoud inde vorm van een enkele kopie op een web-site, maar misschien ook in de vorm van velekopieën op CD ROM. Als voor deze laatstevorm van distributie gekozen is, betekentdat ook nog een flinke verzendoperatie.

7.5 Overdragen van het beheer

Als dan uiteindelijk alles gereed is om hetnieuwe product daadwerkelijk vrij te gevenen de projectdocumentatie opgeschoonden aangevuld is, kan het in beheer genomenworden. Door wie? Daar kom ik in de uitlei-ding op terug.

7.6 Afronding

De invoeringsfase leidt tot een rapport(je)dat verslag doet van alle werkzaamheden.Het beschrijft onder meer de overdracht vanalle projectdocumentatie van de tijdelijkeorganisatie, i.c. de projectgroep, aan destaande organisatie. Als er sprake is geweestvan een formele relatie met een opdracht-gever, kan de opdrachtgever aan de handvan dit verslag de projectgroep déchargeverlenen en kan de projectgroep groep ont-bonden worden.

8. Uitleiding

In deze bijdrage heb ik laten zien wat erkomt kijken bij het zelf op projectmatigewijze ontwikkelen van elektronische leerob-jecten. Tijdens de definitiefase wordt hetprobleem afgebakend en een didactische entechnische oplossingsrichting gekozen. Deontwerpfase resulteert in gedetailleerdespecificaties voor het te ontwikkelen leerob-ject. Tijdens de realisatiefase wordt datdaadwerkelijk gebouwd. De invoeringsfaseleidt tot de overdracht van het ontwikkeldeproduct. Het ontwikkelproject is dan afge-rond.Als het elektronische leerobject eenmaalklaar voor gebruik is, zal het ook beheerd enonderhouden moeten worden. De "content"moet immers actueel blijven. De techniek

169


vraagt af en toe om aanpassingen. De func-tionaliteit moet soms aangepakt worden,soms curatief ("bugs"), soms preventief(nieuwe gebruikerswensen). Het is de vraagwie deze taken allemaal op zich gaatnemen.Op het gebied van beheer en onderhoudmaakt het veel uit of een onderwijsorgani-satie qua innoveren met ICT in het bottom-

up of in het top-down stadium verkeert. Inhet bottom-up stadium is er op het gebiedvan beheer en onderhoud nagenoeg nietsgeregeld. De docent die zelf een elektro-nisch leerobject ontwikkeld is wat dit betreftdus op zichzelf aangewezen. Het beherenen onderhouden van een dergelijk productis echter weer een heel andere bezigheiddan het ontwikkelen ervan. Het komt in de

praktijk dan ook regelmatig voor dat docen-ten hier minder interesse in hebben en/ofminder goed in zijn. Het product zal dangeen lang leven beschoren zijn.In het top-down stadium is het gebruikelijkdat er vorderingen gemaakt worden op hetgebied van het beheren en onderhoudenvan de elektronische leerobjecten. Dedocent die het product ontwikkeld heeftbemoeit zich misschien wel nog met hetactualiseren van de "content", maar hoefthet product niet technisch aan de praat tehouden of allerlei gebruikersondersteuning(helpdesk) te bieden. Dat laatste doet deelseen ICT-afdeling, deels een afdeling onder-wijs, óf het gebeurt door een nieuwe com-binatie van beide: de interne of externeEducational Service Provider (ESP).

170


Het zelf ontwikkelen van elektronische leerobjecten

Education

Transcript of Het zelf ontwikkelen van elektronische leerobjecten