Ontwerpen en ontwikkelen van multimedia

(het Methoden & Technieken-project)

Door Rik Min

In deze tekst komen de volgende begrippen voor: multimedia, courseware, educatieve software, leermiddelen, instructiemiddelen, ontwerpen, ontwikkelen, top-down, bottum-up, software-engineering, rapid prototyping, evolutionair ontwerpen, technologie, methodologie, methoden, technieken en instrumentatietechnologie.

Inleiding

De wereld van de informatie- en communicatietechnologie (IT en/of ICT) is enorm in beweging; en dientengevolge ook de wereld van de educatieve instrumentatietechnologie (ISM). Een vloedgolf van nieuwe technieken en nieuwe media komt op ons af; niet alleen op de consument, ook en vooral op de ontwerper van multimedia en de onderzoeker. De ontwerper wordt heen en weer geslingerd tussen verschillende min of meer wetenschappelijke opvattingen over het ontwerpen en ontwikkelen van multimediale software. Daarom dient een ontwerper - en zeker een aankomend ontwerper - een bepaald houvast te hebben aangaande essentiele basisbegrippen.

Binnen het op zich zeer brede vakgebied van de instrumentatietechnologie is het een komen en gaan van methoden, technieken, theorieen, concepten, ontwerp-richtlijnen, plannen van aanpak en filosofieen over hoe interactieve educatieve software moet worden ontworpen en er voor de gebruiker uit moet zien; en met welke tools een en ander moet worden gerealiseerd (Tannenbaum: T: 409-412). Dit wetenschapsgebied loopt van ergonomie en de kennis van human factors en interfaces tot zuivere computerkunde en van programmeertechnieken tot mediakeuze-onderzoek.

Er worden door de afdeling ISM een groot aantal theoretische vakken verzorgd, inclusief een groot aantal praktica op het gebied van multimedia en software-engineering. Daarbij worden zowel algemene ontwerpmethodes onderwezen als nieuwe methoden en technieken aan de orde gesteld. Zo werken wij het meeste samen met de afdeling IST; vooral als het de toegepaste methode van onderwijs of de instructie component die bij een multimediale leeromgeving hoort betreft.

Over het ontwerpen van volwaardige interactieve programmatuur, en in het bijzonder over educatieve software en multi- en hypermediale-produkten (T: p.437), bestaat een groot aantal subjectieve meningen tegenover slechts een klein aantal empirisch onderbouwde, objectieve theorieen. De afdeling ISM (voorheen 'vakgroep ISM') heeft de opdracht om enerzijds in het onderwijs van de faculteit aandacht te schenken aan deze veelheid van meningen over ontwerpen en anderzijds de taak een samenhangend curriculum van met name practica te ontwerpen en te onderhouden.

In de leestekst komt aan de orde welke aspecten bij respectievelijk de ontwerp-fase zowel als bij de ontwikkel-fase van een produkt aan de orde komen. In een enkel geval zal de ontwikkel-fase gelijk vallen met de ontwerp-fase (bij de rapid prototyping ontwerp-methode), maar in de meeste ontwerp-modellen die hier aan de orde komen dienen deze fases strikt gescheiden te worden.

De leestekst moet na bestudering van de stof een indruk geven hoe instrumentatieproblemen binnen de onderwijskunde (op micro-niveau) moeten worden aangepakt en kunnen worden opgelost. Oplossingen op micro-niveau moeten altijd in het licht van problemen en context op een andere niveau worden gezien.

Soorten educatieve multimediale producten

Binnen de instrumentatietechnologie ligt de nadruk op de hedendaagse moderne leermiddelen en met name de leermiddelentechnologie. Binnen de leermiddelentechnologie spelen software engineerings methoden (T: p.391) en high tech informatie- en communicatietechnieken een overheersende rol. Typische produkten, welke binnen het vakgebied van de instrumentatietechnologie bestudeerd, onderzocht, beschreven en in haar onderwijs - in volgorde van ancienniteit - aan de orde komen, zijn:

Tot de traditionele leermiddelen kun je boeken, spelletjes, practicum-opstellingen, etc. rekenen; tot de traditionele instructiemiddelen opdrachtformulieren, bepaalde type lesboeken, handleidingen, etc. Tot de audiovisuele instructiemiddelen worden videofilms, instructie-tapes, sheets, wandplaten, etc. gerekend. Instructiemiddelen zijn (meestal) niet interactief en soms digitaal; derhalve zijn het one-way-media. Digitale leermiddelen zijn computer-based en interactief. Dat zijn dus two-way-media.
Tot de digitale leermiddelen worden gerekend: electronische leeromgevingen (in het algemeen), moderne instructiemiddelen, courseware, educatieve spelen, drill and practice, simulaties, onderwijskundige WEB-sites, help-systemen, testsystemen, video-conferencing systemen (kortom computer ondersteund onderwijs in de ruimste zin van het woord). Deze indeling van leermiddelen en media die in het onderwijs een rol spelen is in het eerste jaar uitgebreid aan de orde gekomen. De termen educatieve software en digitale leermiddelen zijn feitelijk synoniem.

Er zijn allerlei termen voor leer- en instructiemiddelen en er zijn allerlei subtiele verschillen tussen de termen; maar ook accenten-verschillen. Elke term heeft zijn onderwijskundige en didactische voor- en nadelen. We noemen hier een paar belangrijke oudere, wetenschappelijke termen en wat nieuwere:

Karakteristieke produkten, welke momenteel binnen een vakgebied als de instrumentatietechnologie bestudeerd, onderzocht, beschreven en in het haar toebedeelde onderwijs aan de orde komen, zijn: interactieve leermiddelen in de gedaante van electronische, beeldschermgeorienteerde leeromgevingen, zoals de twee belangrijkste van dit moment: de stand alone leermiddelen (CD-i, CD.rom) en de on-line leermiddelen op het world wide web.
Altijd is het aan het begin van elk ontwerp- of ontwikkel-traject nodig goed in de gaten te houden welke soort software men aan het maken is. Wetenschappelijk gezien heeft elke soort educatieve software zijn eigen specifieke onderwijskundige of didactische mogelijkheden.

Door de komst van het web is er een verschuiving opgetreden van 'computer based' naar web-based'. Er zijn allerlei (specifieke) soorten educatieve software. Elke soort educatieve software werkt anders en heeft zijn bijzondere onderwijskundige voor- en nadelen, maar elke soort heeft ook zijn eigen specifieke manier van ontwikkelen; dat is voor ontwerpers en ontwikkelaars nog het aller belangrijkste. We noemen hier de belangrijkste soorten en hoe ze in het algemeen ontwikkeld worden. Hier volgen een paar soorten en de manier waarop ze meestal ontwikkeld worden:

Als Toegepast Onderwijskundige (TO-er) dient men al deze namen voor de verschillende soorten educatieve software te kennen en ook steeds te onderscheiden. Elke naam of elke soort dekt toch meestal iets anders.

In dit artikel zullen we zoveel mogelijk de algemene term educatieve software gebruiken. Die term is haast per definitie multimediaal en hypermediaal (en interactief, electronisch en digitaal). In dit artikel is alles wat we aan educatieve software beogen web-based.

Web-based software of courseware

Web-based software of courseware ziet er altijd uit als een web-site. Web-sites zijn er echter in allerlei soorten en maten. Opvallend zijn de enorme kwaliteits verschillen. Ook is er een enorm verschil tussen een site die publiek toegankelijk is - en commercieel moet zijn - versus sites die specifiek in het onderwijs of bij een enkele vak gebruikt worden. De meeste web-sites op het world wide web zijn geen courseware. Wanneer is nu een web-site courseware en wanneer is een web-site eigenlijk geen courseware. En wanneer spreken we van een echt (digitaal) leermiddel?
Om deze spraakverwarring kort te sluiten, introduceren we daarom hier het begrip orde. We spreken van '1e orde courseware' en '2e orde courseware' (en zelfs van '0e orde courseware'). We moeten web-sites dus altijd didactisch en onderwijskundig de maat nemen. We dienen een soort rangorde, een niveau of een orde aan web-sites te geven. We onderscheiden derhalve in dit artikel drie verschillende ordes van (web-based) courseware: Al deze soorten courseware en web-sites komen in het vak van Kommers en Min, "Multimedia-ontwerp en -productie", aan de orde. Bij de opdrachten van Min ligt het accent op 2e orde courseware met interactieve applets en scripts; bij die van Kommers meer op 1e orde courseware met veel video.

Ontwerpen in relatie tot Wetenschap

Ontwerpen wordt binnen de software-engineeringswereld niet als zodanig als een wetenschap gezien maar als 'ingenieurskunde' ('ontwikkelkunde' of 'engineering'). Techniek en het toepassen van techniek zijn het resultaat van vele soorten ervaringen. Ook ervaringen uit wetenschappelijk onderzoek horen hierbij. Ontwerpen op zichzelf kan daarom beter geen wetenschap worden genoemd. Tenzij je aangeeft onder welke condities ontwerpen wetenschap is. We moeten ons realiseren dat ontwerpen voor een heel groot deel een subjectief gebeuren is. De uiteindelijke vorm of de gekozen oplossing is namelijk direct afhankelijk of onderhevig aan smaak, mode en subjectieve inschattingen. Ontwerpen heeft wel veel - maar niet alles - met wetenschap te maken. Immers elk produkt, hoe bescheiden soms ook, bevat kennis die door wetenschappers (en anderen) is verzameld. De wetenschap der techniek wordt technologie genoemd. Technologie is dus wel een wetenschap.

De beste definitie van ontwerpen - in dit verband - is:

Het ontwerpen van onderdelen van een groter geheel is de minst subjectieve bezigheid. In een totaalontwerp komen sommige oplossingen volkomen rationeel tot stand. Die objectief tot stand gekomen oplossingen zijn over het algemeen gebaseerd op resultaten van (wetenschappelijk) empirisch onderzoek aan de hand van prototypen. Maar vaak ook ingegeven door marktmechanismen, in de zin dat een produkt niet 'loopt' als het publiek een produkt eenvoudig (nog) niet koopt.

Er bestaat een groot aantal meningen en interessante definities van of over ontwerpen; ongeveer gelijkluidend als bovenstaande, definitie. Hier volgen er enkele:

Binnen de instrumentatietechnologie worden al deze definities geaccepteerd. Ze overlappen elkaar ook grotendeels. Projectleiders die geintegreerde multimediale produkten moeten ontwerpen en ontwikkelen, dienen het besef te hebben dat tekst, geluid en bewegend beeld zo ieder hun eigen conventies, wetmatigheden en ontwerp-aanpak kennen. De kunst voor de projectleider is al deze visies en oplossingen zo zorgvuldig mogelijk op elkaar af te stemmen.

Volgens Plomp (1992) kunnen problemen waarvoor oplossingen moeten worden ontwikkeld, worden ingedeeld in weet-, kies- of maak-problemen. Ontwerpen is echter duidelijk produktgericht en onderscheidt zich van andere sociaal wetenschappelijke activiteiten. Immers de sociale wetenschap is een discipline die onderzoek doet om weet- en kies-problemen op te lossen. Kunstenaars en sommige vormgevers beoefenen het ontwerpen echter als vrije kunst. Het ontwerpen van multimediale produkten vereist in de praktijk een combinatie van inhoudelijke kennis (aangaande de 'content'; T: p.420), wetenschappelijke kennis (aangaande 'methoden en technieken'), technische kennis (aangaande 'tools'), creativiteit (slim zijn) en ambacht (handig zijn) tegelijkertijd.

Benaderingswijzen / Invalshoeken

Er bestaan in onze optiek tenminste drie soorten benaderingen of invalshoeken bij het ontwerpen en ontwikkelen van edicatieve software:

a. Top-down benadering. Deze benadering legt het primaat op het totaalontwerp. De onderdelen dienen later, afzonderlijk ingevuld te worden. De aanhangers van deze benadering gaan er van uit dat daar dan geen problemen meer bij kunnen optreden. De details rekent men niet tot het probleemgebied. Het overall-ontwerp is het enige aan te pakken probleem. De voordelen zijn evident. Een nadeel is dat studenten vaak met standaard-oplossingen komen en soms opmerkelijk weinig creativiteit tonen. Dat nadeel is - om allerlei redenen - bij de bottom-up aanpak minder. (Een voorbeeld van deze benaderingswijze is de manier van denken die bij de OKT-vakken en bij dit vak 'MMOP' aan de orde komt/is.)

b. Bottom-up benadering. Deze benadering legt het accent op onderzoek naar nieuwe methoden en technieken om te ontdekken of die een bijdrage kunnen leveren aan het geheel. Met deze gegevens kan een ervaren ontwerper dan ten alle tijden produkten, bijvoorbeeld programmatuur, ontwerpen waarbij de nieuwe technieken direct kunnen worden ingezet. Deze benadering kan dus veel sneller anticiperen op nieuwe technieken dan de voorgaande benadering. De details rekent men expliciet tot het probleemgebied. Het overall ontwerp is verder een kwestie van goed teamwork. De voordelen van deze onderwijsaanpak is dat - door de ruime keus van methoden en technieken die hij heeft leren toepassen - de student veel soorten keuzes kan maken in zijn uiteindelijke produkt-ontwerp. (Een voorbeeld van deze benaderingswijze en manier van denken kwam voor bij het inmiddels afgeschafte ISM-vak 'multimedia programmeren', waar practicumopdrachten met javascript moesten worden opgelost.)

c. De specialisatiebenadering. Deze benadering legt het accent op de vormgeving van zowel het geheel als van specifieke details (los te koppelen van het construeren van de eindoplossing). De vormgeving van de afzonderlijke onderdelen is bij deze benadering doorslaggevend. Het gaat de ontwerper in deze benadering primair om de figuren, de teksten en de (video)beelden. Evenals dat gebeurt bij universitaire vormgeversopleidingen en bij grootschalige filmprodukties. Hierbij zijn alle functies in het produktieproces consequent en duidelijk gescheiden. Technieken en programmeermethoden rekent men in de vormgeverswereld nu eenmaal niet tot het probleemgebied. Deze duidelijke scheiding tussen vormgeving en het programmeren is in het geval van interactieve multimedia zeer logisch en legitiem. De programmeur en de instrumentatietechnoloog kunnen en mogen dus het constructieprobleem geheel naar eigen inzicht oplossen, maar de vormgever heeft het laatste woord. Rapid prototyping speelt in deze benaderingswijze een grote rol. Hiermee kunnen vormgevers en programmeurs (maar ook andere betrokkenen) beter (en met name in het vroegste stadium) met elkaar communiceren. (Een voorbeeld van deze benaderingswijze en manier van denken kwam voor in de voormalige ISM-vakken 'ISM 1' en 'Mediakunde' van Min, Schmitz en Jonker.)

Een voorbeeld van deze derde benaderingswijze is de manier van denken die bij het maken van films en televisieprogramma's aan de orde is en tegenwoordig ook bij grootschalige multimedia producties, zoals bij het ontwerpen en ontwikkelen van CD-rom's en CD-i's, waarbij zeer veel verschillende disiplines betrokken zijn. Op het web zie je deze ontwikkeling nu ook.

Methoden en Technieken

Binnen de instrumentatietechnologie spelen de begrippen methodologie en 'methoden en technieken' een grote rol. Het ene begrip heeft veel te maken met de top-down benaderingswijze en het andere begrip meer met de bottom-up benadering. Onder technieken worden in deze verhandeling bepaalde opties of nieuwigheden in bepaalde gereedschappen, systemen of hardware verstaan. Ook technische nieuwigheden worden technieken genoemd; bijvoorbeeld moderne audiovisuele presentatietechnieken. (Tools of gereedschappen worden in deze tekst voor het gemak tot de technieken gerekend.) Onder methoden verstaan we expliciete kennis en zaken die te maken hebben met het realiseren van software en het integreren van losse, statische multimediale componenten in een geheel: dus hoe en met welk systeem een totaalprodukt gemaakt wordt. Dus bijvoorbeeld door gebruik te maken van een specifieke auteurstaal (T: p.359), een specifiek hogere programmeertaal of een specifieke soort editor e.d.

Als de keuze van de methode of een ontwerp-systeem vastligt komt - in deze benaderingswijze - de methodologie aan de orde: hoe men - gegeven een bepaalde ontwerp-methode - dan verder handelt. Er dient dus duidelijk onderscheid te worden gemaakt tussen de beide begrippen methode en methodologie.
Een methode of een 'ontwerp-methode' is altijd (veel) meer dan een 'techniek'. En 'methodologie' is meer dan een methode: waardevrijer. In ieder geval is de methodologie (van het ontwerpen) altijd algemener en onafhankelijker dan de gebruikte methode (in de realisatie fase), laat staan ten opzichte van de hele specifieke en in wezen - voor een universitaire studie - onbelangrijke technieken, zoals een programmeur in de programmeer-fase tegenkomt. Derhalve kunnen de volgende definities, voor een beter begrip aangaande deze benaderingswijze, een steun zijn:

Methoden en technieken ontstaan als het ware van onderop; zij worden over het algemeen op een haast autonome manier (d.w.z. 'oncontroleerbaar') gegenereerd door de industrie, maar ook door de wetenschap zelf. De technologie en de methodologie zijn de wetenschapsgebieden die dit in kaart brengen, analyseren en synthetiseren.

Wat is nu het verschil tussen methoden en methodologie? In het Nederlands taalgebruik (en binnen de instrumentatietechnologie) heeft het woord methodologie twee betekenissen. De eerste betekenis is die van beschrijving, verklaring en waardebepaling. Daarnaast wordt het woord vaak gebruikt ter aanduiding van een bepaalde methode. Hier volgen enkele definities. De eerste is van algemene aard:

Een tweede definitie is nog:

Maar de beste en wetenschappelijk best omschreven definitie gaat uit van de overeenkomst tussen de twee fundamenteel verschillende woorden 'techniek' en 'technologie', namelijk zoals technologie de 'leer (of de wetenschap) der technieken' is, geldt naar analogie daarvan de definitie:

Het Ontwerp- en Ontwikkelproces

Elke ontwerper dient bij de constructie van courseware, bij de afzonderlijke TO-vakken, onderscheid te maken tussen de ontwerp- en ontwikkelfase, incl. 'het programmeren'. De ontwerpfase dient goed te worden uitgewerkt. Men dient voldoende onderscheid te maken tussen het functioneel en het technisch ontwerp. Vaak ontbeert men de technische kennis en middelen om een goed en systematisch ontwerp te kunnen maken. Daarom is het noodzakelijk dat ontwerpers in spe in het begin van hun opleiding kennis maken met tools en technieken en dus ook met programmeer-technieken. Een dergelijke basiskennis is een redelijke garantie dat men inzicht verkrijgt in de veelheid van oplossingen, zodat een ontwerp later ook werkelijk kan worden gerealiseerd.

Bij het ontwerpen en ontwikkelen van lineaire produkten zoals film of video en in zekere zin ook bij tutorials en interactieve video, speelt van oudsher het maken van een goed script een grote rol. Omdat bij het construeren van audiovisuele middelen een langere traditie bestaat, is ook de technische component daarbij beter uitgekristaliseerd. Dit in tegenstelling tot het ontwikkelen van veel soorten interactieve (educatieve) software, daarbij wordt bij het ontwerpen vaak meer de nadruk gelegd op de structuur van de software, stroomdiagrammen (met het systeem 'Flowcharter'), dan op de inhoud of de 'verhaallijn'. Maar desondanks wordt hierbij elke frame, elk beeld en natuurlijk ook het geheel, systematisch ontworpen. Maar ondanks alle theorievorming op dat punt is er bij dit type produkt nog steeds een grote mate van bottom-up benadering. De rapid prototyping-methode heeft dat in de hand gewerkt.

Desondanks dient een multimedia-produkt in principe op dezelfde manier ontworpen te worden als elk ander audiovisueel produkt. Dat bij het maken van AV-materiaal meer aandacht wordt gegeven aan een systematische benadering wordt echter ook veroorzaakt door het feit dat de produktie van het audiovisuele leermateriaal een kostbare aangelegenheid is, zeker als in een laat stadium veranderingen zouden moeten worden aangebracht. Daardoor wenst men het risico op dergelijke ingrepen te minimaliseren. Nu er echter nieuwe (multimediale) tools zijn gekomen, waardoor de hanteerbaarheid en manipuleerbaarheid van audiovisuele toepassingen zeer sterk is toegenomen, stijgt het risico dat ook in deze sector systematisch en vooraf ontwerpen minder belangrijk zal worden geacht. Onder het mom van 'rapid prototyping' gaat men als ontwerper snel op de tour van 'programmeren'. Studenten moet daarom geleerd worden later bij hun afstuderen en/of hun latere beroepspraktijk, de nodige terughoudendheid te betrachten ten aanzien van directe praktische activiteiten ten koste van een planmatig ontwerp. Wij laten hier een paar methoden de revue passeren.

Top down ontwerpen

De methode die De Diana en Min in hun vak 'Courseware Engineering' toepastten is ontwikkeld door De Diana. Je begint met de ontwikkeling van een ruw versie van een product (prototypes) en vult stap voor stap - en in overleg met de opdrachtgever - de ontbrekende onderdelen in. Met NetObject Fusion mag en kun je ook zo werken. De voortdurende aanpassingen van de opzet en de inhoud zijn de kenmerken van deze methode of werkwijze.

Deze methode met 6 stappen kan meestal zeer succesvol bij het ontwikkelen van 1e orde courseware en web-sites in het algemeen worden toegepast. Maar er zijn nog andere methoden of modellen, zoals het rapid prototype-model en het W.J. Zwart-model.

Rapid prototyping

In figuur 1 staan de handelingen die plaatsvinden als rapid prototyping wordt toegepast op onderwijskundig ontwerpen. De tijd verloopt van links naar rechts en er is dan te zien dat de verschillende handelingen elkaar in de tijd overlappen: er is sprake van parallelle processen.



Figuur 1: Het 'rapid prototyping'-model van Tripp & Bichelmeyer uit 1990

De methode van rapid prototyping is bijzonder geliefd geworden door de opkomst van HyperCard-achtige systemen (T: p.410), zoals HyperCard, maar ook door VisualBasic en de komst van WYSIWYG auteurs-systemen. In de meest eenvoudige vorm komt rapid prototyping ook voor bij tekstverwerken, d.w.z. het op een moderne manier schrijven en opmaken van een boek of artikel. Je begint met een 'outline' en vult later stap voor stap - en in overleg met anderen - de ontbrekende onderdelen in. Met NetObject Fusion mag en kun je ook zo werken. De voortdurende aanpassingen van de opzet en de inhoud zijn de kenmerken van deze methode of werkwijze.
Het evolutionair ontwikkelen van produkten heeft deze zienswijze geheel tot zich genomen (Tolido, 1996). Het evolutionair ontwikkelen van produkten is in de software wereld ontstaan uit de rapid prototyping methode en inmiddels een niet weg te denken methode om het gewenste produkt te krijgen. Zie hiervoor het boek van Tolido: "Evolutionair ontwikkelen van informatiesystemen", Uitgeverij Academic Service, 1996. Een bedrijf dat deze methode toepast, zet (meestal snel) een product in de markt als versie 1.0; weet daarmee een markt te veroveren, en bouwt en ontwikkelt daarna op een rustige manier stap voor stap betere versies: versie 2.0, 3.0, etc. Men werkt dus niet met een echte, complete voorstudie of duidelijke onderzoeksvraag of ontwikkel-opdracht, maar meer het idee van dat een aanbod een vraag creeert.

Het W.J. Zwart-model

Binnen de afdeling instrumentatietechnologie wordt veelvuldig gewerkt met het zogenaamde W.J. Zwart-model (Zwart, 1988). Dit model beschrijft een andere aanpak dan zomaar een voor een de fases uit het OKT-model: vooronderzoek, ontwerp, constructie, evaluatie, revisie en implementatie. Bij het OKT-model worden deze fasen in principe sequentieel doorlopen. Bij dit model niet. Iedere fase levert een (aantal) produkt(en) op waarmee in de volgende fase verder gewerkt kan worden. Onderzoek wijst derhalve uit welke vervolg-oplossing mogelijk is. Men werkt van prototype naar prototype en uiteindelijk naar het meest optimale eindproduct. De prototypen worden gebruikt om een methode of techniek te testen, d.w.z. een (kleinschalig) performance-onderzoek. Cruciaal bij deze methode is dat de ontwerpfase een blauwdruk oplevert, waarmee in de constructiefase de oplossing geproduceerd kan worden.

Het OKT-model gaat er - ten onrechte - vanuit dat in de ontwerpfase de methoden en technieken die in de constructiefase gebruikt moeten worden zomaar voorspelbare output opleveren. Laat staan dat daar literatuur over is. Niets is minder waar in deze sector. Min en van Schaik Zilessen stelden in 1988 al, dat "indien er nieuwe methoden en technieken worden gebruikt een ontwerp nooit helemaal van te voren 'uitgetekend' kan worden"; "het eindproduct hangt af van bevindingen in tussentijdse prototypisch onderzoek". "In de educatieve softare-engineering schiet het OKT-model als methode tekort".
De beste aanpak voor educatieve software-problemen is daarom het werken via het W.J. Zwart-model, een echte onderwijskundige ingenieurs-aanpak: een mengvorm van het OKT-model, rapid prototyping en evolutionair denken en werken (via prototypes, performance-onderzoek en steeds - later - nieuwe versies uit te geven).


Figuur 2 Het J.W. Zwart model.

Bij het W.J. Zwart-model worden niet alle fasen streng mechanisch een voor een doorlopen. Bij het W.J. Zwart-model kan men vanuit elke fase terecht komen in een andere fase. Er zijn ontwerpers die van mening zijn dat het OKT-model voldoende vrijheidsgraden heeft om het op de manier te gebruiken waar Zwart en anderen een pleidooi voor houden, maar de verdienste van het W.J. Zwart-model is dat het bijvoorbeeld expliciet aangeeft dat men verder moet kijken dan de fase waarin men verkeert en dat men de problemen van verderop gelegen fasen al vast moet inventariseren (en op een stapel - een 'stack' - moet leggen) en dat men, op rustige momenten in een project, alvast oplossingen moet zoeken en/of moet zien uit te testen. De uitvinders van dit model waarschuwen hiermee impliciet dat software ontwikkelaars altijd te maken krijgen met onverwachte gebeurtenissen (bijvoorbeeld het bestellen van materialen, tools, insprekers, etc.). Planningsdeskundigen waarschuwen hier altijd al voor. Zorg dat er bij een project - in het planningstraject - zo min mogelijke 'kritische paden' (momenten) zijn.

Deze overwegingen, opvattingen en voorbeeld van projecten waarbij het OKT-model niet goed werkte, hebben geleid tot een (laten we maar zeggen) variant van het OKT-model, zodat ontwerpers bij instrumentatietechnologische opdrachten en wellicht in meer algemene zin voor het oplossen van instrumentatie-technologische problemen en beter handvat hebben om problemen op te lossen en voor te blijven. Het proces is schematisch weergegeven in figuur 2. Rechts ziet de lezer de stapel 'problemen' - die fase na fase - ontdekt worden en - gaande de rit en binnen de gestelde projecttijd - opgelost dienen te worden. De volgorde van oplossen doet er in principe (dan) niet veel (meer) toe.

Na het 'normale' vooronderzoek bestaat het model uit een cyclische middenfase. Daarin zijn de fasen ontwerp en constructie uitgebreid met een testprocedure. Tevens moet er in deze fase onderzoek gedaan worden om een aantal problemen op te kunnen lossen. Het vooronderzoek levert o.a. als tussenprodukt een lijst met problemen, die nog niet opgelost zijn en waarvoor ook geen bestaande oplossing voor handen is. In de cyclische middenfase vinden de volgende zaken plaats:

In de cyclische middenfase wordt voor het produktie-gedeelte gebruik gemaakt van een bepaalde werkwijze die in de volgende paragraaf beschreven wordt. Dit levert een prototype van de computersimulatie en wellicht als nevenprodukt mogelijk een aantal ontwerpprincipes en/of methodieken. In evaluatie/revisie-fase wordt het eindprodukt van de cyclische middenfase, een eerste prototype, formatief geevalueerd. Bij de implementatie wordt het normale OKT-model gevolgd.

Het W.J. Zwart-model kan het best gebruikt worden als er nog helemaal niets vast staat aangaande het systeem waarmee het product gebouwd moet gaan worden en de opdrachtgever het beste van het beste en de nieuwste technieken wil. In dat soort gevallen dient er nog in de ontwerpfase onderzoek gedaan te worden naar de 'performance' van die nieuwe technieken, d.w.z. kan de opdracht uberhaupt wel met die nieuwe techniek uitgevoerd worden. (Heeft deze techniek wel voldoende 'power': is de performance voldoende?) Er moet dan een (klein) pilot onderzoek gedaan worden naar de performance van zowel de tool als het product. Is de tool onhandig of is het product te traag, dan moet u die methode of techniek - vooralsnog - vermijden. Net zo lang tot dat collega-onderzoekers of de literatuur u vertellen dat de tijd er wel rijp voor is.

In zijn - alternatief - model volgt, na het vooronderzoek, een cyclische middenfase. Daarin zijn de fasen ontwerp en constructie uitgebreid met een testprocedure. In die fase moet er al (performance-) onderzoek gedaan worden om een aantal problemen te kunnen voorspellen en op te lossen. Het vooronderzoek levert onder andere als tussenprodukt een lijst met problemen, die nog niet opgelost zijn en waarvoor ook geen bestaande oplossing voorhanden is. Die zetten we dan (voorlopig) op de stack; tot we er wat mee kunnen; tot de tijd rijp is of tot we iemand daarvoor (eventueel) kunnen inhuren.

Systemen, Tools of Talen?

Er zijn drie fundamenteel verschillende manieren om multimediale producten, educatieve IT producten en/of courseware te maken. Bij het ontwerp van een educatief multimediaal product dient men van tevoren - bij het ontwerpen ervan - goed na te denken waarmee het product uiteindelijk gemaakt moet worden. Deze methode c.q. manier bepaalt wat kan of niet kan. Die eenvoudige gedachte is voor sommige ontwerpers niet vanzelfsprekend.
Deze drie fundamenteel verschillende manieren om educatieve software te maken zijn:

Er zijn ontwerpers die het realiseren van courseware geheel aan anderen overlaten en noemen het reele ontwikkelen dan ook nog vaak denigrerend coderen. Toen er alleen nog maar in Fortran, Pascal, C en Cobal werd geprogrammeerd lag dat in zekere zin voor de hand. Tegenwoordig zijn er honderden manieren om software en met name educatieve software te ontwikkelen en te realiseren. Voor elke type software is er vaak wel een aparte methode, een aparte techniek of een aparte tool. Er zijn wel dertig soorten educatieve software, courseware of COO. Elke soort komt anders tot stand.
Wat is de juiste methode om een (educatief) multimediaal product te ontwikkelen en/of te programmeren? Dat is een hele wetenschap. Het ene multimediale product komt op en geheel andere wijze tot stand als een andere. Om daar iets zinnigs over te zeggen zijn in de loop der jaren hele studies gemaakt.

Je moet dus precies weten wat voor soort educatieve software, courseware of COO je wilt maken of welk type software de klant wil. En dat hangt weer af van het budget en de tijd die je voor een project hebt. Als je gewone 'platte' courseware wilt maken kun je volstaan met een auteursomgeving, maar wil je een simulatie maken dan ontkom je er niet aan om minstens bepaalde onderdelen te programmeren in een hogere programmeertaal. Soms ontkom je er zelfs niet aan om alles in een hogere programmeertaal te programmeren.

Als vuistregel kun je nemen dat 80 procent van alle educatieve software gemaakt wordt met auteurssystemen of auteurstalen en de rest met hogere programmeertalen. Maar de leukste en de effectiefste onderdelen van educatieve software vaak met hogere programmeertalen zijn gemaakt. Dat komt voor bij 'drill and practice', 'simulaties' en dergelijken. Misschien zijn de 80 procent effectiefste stukken software wel met hogere programmeertalen gemaakt. Professionals grijpen vaak terug op hogere programmeertalen. Deze methode is onlosmakelijk verbonden aan de methode om met losse componenten te werken en in dimensies te (leren) denken.

Aparte Dimensies, Aparte Componenten: Apart Ontwikkelen

Er zijn bij multimediale producten altijd, vier of vijf (of soms zelfs zes) dimensies te onderscheiden. Wij onderscheiden: tekst, beeld, geluid, animatie, video en - wat ons betreft - ook nog als zesde en aparte soort: kleine, losse, interactieve elementen ('applets'). Elke dimensie heeft zijn eigen specifieke onderdelen (tekststrings, plaatjes, foto's, muziekjes, filmpjes, applets, etc.) en eigen specifieke tools om dat soort onderdelen te maken (tekst-editors, grafische bitmapped editors, video-editors, java-tools, etc.). (Zie ook de opmerkingen die bij de specialisten-benaderingswijze - elders in dit stuk - zijn gemaakt.) De zes dimensies met hun manier van maken zijn:

Deze methode komt erop neer dat je de losse componenten van een product goed moet kennen en apart moet kunnen maken.

Elk onderdeel en elke dimensie van een multimediaal product moet op een andere manier worden ontwikkeld. Daarna moeten ale onderdelen tot een geheel worden gesmeed. Daar zijn weer andere methoden, technieken of systemen voor.

Soorten tools

De verschillende soorten ontwikkel- of programmeer-tools (-gereedschappen, of -systemen) zijn in allerlei combinaties mogelijk en ook vaak zeer wenselijk. Elke soort educatieve software heeft zijn eigen methodologische aanpak nodig. We zullen er hier een aantal soorten educatieve software en bijbehorende specifieke, kenmerkende ontwikkelmethode de revu laten passeren, t.w.:

Kwesties, die in het hoofd van de ontwikkelaar c.q. ontwerper altijd moeten opkomen, zijn: kan of moet ik een interpreter gebruiken? Kan of moet ik mijn software compileren? Moet ik voor dit onderdeel niet een hele goede performance hebben? (d.w.z. is de 'power' van mijn systyeem of de toekomstige applicatie uiteindelijk wel voldoende voor wat ik wil?) Moet ik voor een bepaald onderdeel snelle respons-tijden nastreven? (Of is dat niet nodig?) Hoe maak je beeld, graphics, graphs (T: p.429) of achtergronden dynamisch? Hoe programmeer je een goed mogelijkheid voor 'file-I/O' (file-input/output)? Etc. Dat zijn allemaal vragen die bepalen of een ontwerp haalbaar is of niet. Ervaring en inzicht spelen hierbij een grote rol.

Implementatie & Evaluatie

Studenten bij de afdeling ISM maken over het algemeen geen eindprodukten, maar meer prototypes om inzicht in bepaalde methoden en technieken te verkrijgen. Wetenschapers maken ook vaak geen eindproducten, maar juist alleen maar prototypen. In dat soort gevallen zijn de werkzaamheden meestal voltooid bij een interne evaluatie en eventuele revisie, van het prototype.

Te dikwijls wordt bij evaluatie gedacht dat evaluatie slechts op het einde, bij een geheel voltooid produkt kan gebeuren. Vaak ontbreekt de tijd (of het geld) om zorgvuldig te evalueren. Meestal is zelfs een evaluatie op het einde overbodig, omdat de mogelijke resultaten van de evaluatie, wegens gebrek aan tijd en middelen, toch niet meer geimplementeerd zullen worden. Aangezien de afdeling ISM haar specifieke ontwerp-karakter wil behouden en benadrukken is het wel logisch dat het ontwikkeltraject vaak extra lang is en het evaluatie-traject vaak relatief kort. Dat hoeft bij student-werk op zich geen probleem te zijn, omdat studenten tijdens hun studie relatief vaak evaluaties moeten doen. Daarbij speelt bij evaluatie van educatieve software ook nog mee dat de ontwerper of de ontwikkelaar zelf, niet de juiste persoon is om een echt onafhankelijke evaluatie-studie, van zijn eigen produkt, te leiden.

Er ontstaat momenteel een nieuwe trend, waarbij een deel van de constructie-activiteit verschuift naar de eindgebruiker. De huidige eindprodukten zullen dan als 'halfprodukten' worden opgeleverd, waarmee de eindgebruiker - de leerkracht of de trainer - als een 'second author' het halfprodukt kan aanvullen of instellen tot een 'definitief' eindprodukt dat aansluit bij zijn eigen inzichten. Een ander alternatief is dat eindprodukten eerder als aparte 'objecten' (kleine op zich zelf staande produkten met een zeer specifieke doelgerichte doelstelling) beschikbaar komen, waarmee de eindgebruiker dergelijke 'objecten' kan bundelen tot een bij zijn inzichten aansluitend eindprodukt. Produktie van multimedia is ten opzichte van film en video relatief nieuw en er is nog steeds weinig ervaring beschikbaar voor commercieel toepasbare ontwerp-modellen.

Men merkt vooralsnog dat op vele fronten een zeer sterke interesse ontstaat voor hergebruik of het aanpasbaar maken van bestaand produkten. Men kan dan bestaande multimedia componenten (her-) gebruiken in moderne multimedia. Als een dergelijke trend zich doorzet, dan zal dat ook consequenties hebben voor de ontwerpmodellen.

In de praktijk is er een algemene trend om de diverse fasen binnen een OKT-benadering, zo zelfstandig mogelijk te maken. Het doel daarbij is de fase af te sluiten met een duidelijk resultaat wat input moet zijn voor de volgende fase. Wegens de moeilijkheden die men ervaart om tot definitieve specificaties te komen, is deze benadering enkel acceptabel als er voor de doelgroep voldoende mogelijkheden zijn de specificaties te confronteren met een voorlopig produkt, waarna zeer snel en in die fase revisie kan volgen.

Alhoewel een strak projectmanagement nodig is, wordt dat door deelnemers in het proces niet steeds gewaardeerd. Dit betekent dat men ernaar moet streven dat een strak projectmanagement zich vooral bezighoudt met het bewaken van de globale opzet van een project. Het projectmanagement stelt randvoorwaarden en kwaliteitseisen vast voor de verschillende fasen. Binnen elke fase zijn de uitvoerders zelf verantwoordelijk. Zij beginnen met een bepaalde input, krijgen middelen, kwaliteitseisen en tijd toegewezen voor de uitvoering, en leveren een door de doelgroep geaccepteerde output.

Karakteristieke Ervaringen en voorlopige Conclusies

De aard van het constructieproces (bijvoorbeeld het ontbreken van definitieve specificaties) en de aard van het produkt (meestal met een meervoudige doelstelling), hebben als gevolg dat een lineaire opeenvolging van constructiefasen, zoals het OKT-model lijkt voor te schrijven, bij de constructie van media, niet volstaat. Als ontwerpers dit beseffen kan het OKT-model best een handvat zijn om een project te starten. Het heeft immers zijn kwaliteiten. Maar met name het op leren knippen van grote problemen in kleinere (en dus meestal oplosbaardere) problemen is meer de verdiensten van het W.J. Zwart-model.

De typische activiteit voor een student die afstudeert bij de afdeling ISM, is het maken van (interactieve) multimedia-produkten. Afstudeeropdrachten binnen de instrumentatietechnologie zijn meestal afkomstig van een externe opdrachtgever of sluiten direkt aan bij lopende onderzoeksprojecten van de afdeling. De uitvoering ervan volgt in principe een traject waarbij de keuze, het ontwerp, de ontwikkeling, de implementatie en de evaluatie van een beoogd produkt aan de orde komen, althans van het prototype van dat produkt. In grote lijnen loopt dit traject parallel met het OKT-model. Bij dit type projecten is het echter noodzakelijk de mogelijkheden en onmogelijkheden van de 'gereedschappen' te kennen. Dus niet alleen de voor- en nadelen van een bepaalde oplossing of tool, maar veel specifieker. Kent men die 'weerbarstigheden' niet, dan kan men ook bijna geen goed ontwerp maken. Daarom is het TO curriculum afwisselend zowel gevuld met 'methoden en technieken'-vakken (waar je meestal bottum-up moet leren werken en waar je spelenderwijs de performance van een tool leert kennen), zowel als met 'methodologie'-vakken (waar je met name top-down en OKT-achtig leren denken en werken).

Ervaringen met afstudeeropdrachten maken duidelijk dat het OKT-model in de praktijk niet steeds gevolgd wordt (of kan worden), maar vanaf het begin geoperationaliseerd moet worden, conform de vereisten van de probleem-context. Er zijn binnen de afdeling ISM in de loop der jaren een aantal explicietere modellen ontdekt en ontwikkeld. Het W.J. Zwart-model is daar een voorbeeld van. W.J. Zwart heeft in zijn onderzoek toendertijd heel expliciet aan de orde gesteld dat het OKT-model op een bepaalde manier moet worden geinterpreteerd (meer dynamisch), zodat het past bij de meest voorkomende afstudeeropdrachten van de afdeling ISM, met name bij engineerings-achtige opdrachten, waarbij nieuwe gereedschappen in het geding zijn.

De problemen waarnaar Zwart verwijst zijn vooral van technische aard. Door zijn suggestie om de ontwerp- en constructiefase cyclisch te doorlopen kan voortdurend aandacht worden gegeven aan het oplossen van de deelproblemen binnen die fase, en kan met de invloed van de gekozen oplossingen op het uiteindelijke produkt in een vroeg stadium rekening worden gehouden. Vooraleer meer in detail in te gaan op de problemen die ISM-studenten ervaren bij de uitvoering van hun opdracht, zullen we eerst nagaan hoe men in de praktijk interactieve media construeert.

Praktijkopdrachten (en dus ook afstudeeropdrachten) op het gebied van de instrumentatietechnologie worden vaak door een bedrijf of een andere externe organisatie verstrekt. In dat soort situaties is er meestal geen echte keuze ten aanzien van het medium. De opdrachtgever heeft een duidelijk idee over wat gemaakt moet worden en de ontwerper (of afstudeerder) kan het daar vanuit zijn positie nauwelijks mee oneens zijn. De consequentie is echter dat de zorgvuldige analyse van de randvoorwaarden en de openheid waarmee een onderwijskundig verantwoorde oplossing voor het gestelde onderwijskundige probleem gezocht kan worden, ontbreken. Daarbij blijkt ook keer op keer dat de opdrachtgever aan een vooral onderwijskundig georienteerd vooronderzoek geen behoefte heeft. Dit leidt tot de situatie dat een student dikwijls nauwelijks in staat is de door hem op dit punt verworven theoretische kennis praktisch toe te passen. Hoe kan men deze impasse doorbreken? Het is onwaarschijnlijk dat de opdrachtgevers van mening zullen veranderen. Daarom moet men zoeken naar oplossingen die ook voor de opdrachtgever aantrekkelijk zijn. Men kan stellen dat opdrachtgevers, in plaats van zorgvuldige onderwijskundige analyses, meer behoefte hebben aan praktische voorbeelden: bestaande mediapakketten die illustreren hoe de beoogde oplossing eruit zou kunnen zien. Vermoedelijk heeft men dergelijk voorbeeld al gezien, dan wel erover gelezen, waardoor de conclusie ontstaat om 'iets dergelijks' te laten maken als oplossing voor een bestaand probleem.

Conclusies

Uit de bundeling van ervaringen, analyses en toekomstverwachtingen ten aanzien van de evolutie van de media, wordt geconcludeerd dat vooral ISM-studenten zich ook met de technische uitvoering binnen een project zullen bemoeien. Er wordt daarom in het bijzonder van ISM-studenten verlangd dat ze een sterke ingenieursverwantschap voelen.

Ter bevordering van de over-all ontwerp-aspecten en de technische uitvoerings-aspecten zou het OKT-model, ook in relatie tot wat in de praktijk van media ontwikkeling gebeurt, een meer modulaire opbouw moeten krijgen. Daarbij zou elke fase uit het model, via een cyclisch proces van formatieve evaluatie en revisie, tot een stabieler tussenprodukt moeten leiden. Het Rapid Prototyping-model en het W.J. Zwart-model zijn daarom binnen het vakgebied van de leermiddelentechnologie de meest reele ontwerp-modellen.

Referenties en Literatuur

Diana, I. De, J. de Goeijen, J .Wetterling en R. Min (1999/2000). Courseware Engineering. Reader en web-site. Toegepaste Onderwijskunde; Universiteit Twente (online beschikbaar op internet).

Kommers, P.A.M., R. Verleur, B. Reimerink en P. Verhagen (1999/2000). Lineaire en Hypermedia. Reader. Toegepaste Onderwijskunde; Universiteit Twente.

Min, F.B.M. en J. de Goeijen (1998/1999). Multimedia programmeren; methoden en technieken. Faculteit Toegepaste Onderwijskunde, Universtiteit Twente. Enschede (online beschikbaar op internet)

Moonen, J. (1991). Toegepast onderwijskundigen: Architecten of Ingenieurs. In 'De onderwijskundige ontwerper'. Red.: S. Dijkstra, H. Kramer en J. Pieters. Liber Amicorum prf. E. Warries. Swets & Zeitlinger ISBN 90 265 1161 2.

Plomp, Tj., A. Feteris, J. Pieters en W. Tomic (red), (1992). Ontwerpen van onderwijs en trainingen. Uitgeverij Lemma. ISBN 90-5189-104-0

Procee, H. (1997). De nieuwe ingenieur; over techniekfilosofie en professioneel handelen. Boom Amsterdam.

Verhagen, P. W., N. Pals en N. van der Woert (1986). Interactieve video als videoprogramma: toepassing en vormgeving.In Verhagen, P.W., en B.J. Wielinga (1986) Media in het onderwijs. Vereniging voor Onderwijsresearch. Proceedings ORD, Swets & Zeitinger BV. Lisse.

Zwart, W.J. (1988). Flowsim: een computersimulatieprogramma voor het Waterloopkundig Laboratorium. Universiteit Twente, Faculteit Toegepaste Onderwijskunde (doktoraalverslag).