Open of gesloten?

Methoden en technieken voor het realiseren van leeromgevingen

AFSTUDEERVERSLAG
in het kader van de opleiding Toegepaste Onderwijskunde aan de Universiteit Twente

(ZEER RUWE EINDVERSIE - WORDT NOG AAN GEWERKT)

Soila Gomez-Vries
Afdeling Instrumentatietechnologie
Enschede, December 2002

Begeleidingscommissie:
Dr. Ir. F.B.M. Min en Dr. I.P. De Diana
Universiteit Twente, Faculteit der Toegepaste Onderwijskunde, vakgroep ISM

Samenvatting

Bij de Faculteit Toegepaste Onderwijskunde van de Universiteit Twente is men al vijftien jaar bezig met onderzoek naar methoden en technieken, met name bij de vakgroep/afdeling educatieve instrumentatietechnologie. Er ontbrak een goed overzicht in methoden en technieken op het gebied van de educatieve software (en courseware); vooral aangaande webtechnologieën. Het probleem geeft aan dat er geen duidelijkheid bestaat over het gebruik van bepaalde termen binnen het realiseren van omgevingen, en leeromgevingen in het bijzonder. De afstudeeropdracht “Open of gesloten? Methoden en technieken voor het realiseren van leeromgevingen” wil een aanzet geven voor het leggen van een gefundeerde basis voor het gebruik van termen binnen de software wereld. Tevens wordt er in dit project de voor- en nadelen van verschillende methoden en technieken weergeven, als een bijdrage ter bevordering bij het ontwikkelen van leeromgevingen. Het project wordt uitgevoerd door een onderzoeksteam en is in vier fasen verdeeld, namelijk: het literatuuronderzoek; de expert interviews; het instrumentenonderzoek en het onderzoek in het veld. Het gehele traject van het project wordt in dit onderzoeksteam constant overwogen, besproken en bediscussieerd. Verder zijn er tijdens het onderzoek deskundigen op het gebied van software engineering en het maken van leeromgevingen benaderd. De verschillende instrumenten zijn onderzocht en specialisten op bepaalde instrumenten zijn geïnterviewd in de vorm van één-op-één formatieve evaluatie. Ontwerpers en ontwikkelaars zijn geënquêteerd om een beeld te krijgen van het veld. Uiteindelijk worden conclusies getrokken van de uitgevoerde onderzoeken en de bevindingen. Aanbevelingen worden gegeven voor eventuele toekomstige onderzoek op dit gebied.

Abstract

Over the last fifteen years, researches are taking place on methods and techniques at the Faculty of Education Science and Technology of the University of Twente, especially in the section of educational instrumentation technology. A good overview on methods and techniques in the field of educational software (and courseware) is lacking; particularly concerning web technology. The problem shows that there is no clarity on the use of certain terms in the making of websites, and specific educational websites. This thesis: “Open or closed? Methods and techniques for the making of educational websites”, wants to initiate a fundamental base for the use of terms in the software world. At the same time, the advantages and disadvantages of different methods and techniques will be arranged as a contribution for the development of educational websites. This project is conducted by a research team en consists of four phases: the research of literature, expert interviews, research on the instruments and research in the field. The research team constantly considers, consults and debates the whole process of the project. During the research, experts on software engineering and experts in making educational websites were approached. Research on different instruments was conducted and specialists on certain instruments were interviewed in the form of one-on-one formative evaluation. A questionnaire was sent to designers and developers to get a better impression of the field. Finally, conclusions are drawn from the researches done and from the results. Recommendations are given for possible future research in this area.

Voorwoord

Na een spannende periode is het afstudeerverslag eindelijk klaar. Spannend, omdat het einde van de studie eindelijk zo dicht bij lijkt te zijn, maar de eisen er niet minder op worden. Een periode van hard werken, vele discussies, frustrerende momenten, maar vooral heerlijke ontspannende werksfeer. Een periode van beproeving en drukte. Terwijl de familie aan de andere kant van de oceaan ongeduldig wordt, knarsen mijn hersenen verder en ratelt de keyboard van mijn computer non-stop door. Het is zo ver. De juiste woorden zijn meestal moeilijk te vinden, maar dat maakt het gevoel van waardering en dank alleen maar groter. Ik heb dan ook een waslijst van personen die op de één of ander manier mij bij stonden, de één deed dat met een bemoedigend woord, de ander met een zegenend gebaar en een ander weer in gebed. Aan allen wil ik een woord van dank uitbrengen. Mijn begeleiders Rik Min en Italo De Diana ben ik zeer dankbaar voor hun inzet, de samenwerking en het geduld dat zij hebben weten op te brengen met mij. Mijn medestudenten voor hun bemoedigende woorden en vertrouwen dat ik het zal redden. Er zijn ook zeer speciale personen die ik bij naam wil noemen, zonder hen zou ik deze studie nooit hebben afgerond. Victor, mijn man, en Thiago, mijn zoon, die mij voor zes maanden de vrijheid hebben gegeven om in Nederland mijn afstudeerproject te kunnen uitvoeren. Mijn vader Mario die ons op een speciale manier steunt en mijn broer Robert die altijd klaar staat om te helpen. Mijn broeders en zusters van de gemeente Saron, Rudy en Selma Petersen, Kezia en Ferry Switsma en de liefste tante van allemaal Tante Rebecca Feyearts. Last but not least Nick Maduro.

Inleiding

In het kader van de afstudeeropdracht ter afronding van de opleiding Toegepaste Onderwijskunde aan de Universiteit Twente, bij de vakgroep Instrumentatietechnologie, is deze doctoraalproject uitgevoerd. De afstudeeropdracht “Open of gesloten? Methoden en technieken voor het realiseren van leeromgevingen” is een inhuis-opdracht bij de faculteit Toegepaste Onderwijskunde uitgevoerd. Deze opdracht is in de vorm gedaan van een studie naar methode en technieken voor het realiseren van leeromgevingen, waarbij onderzoek gedaan is naar verschillende terminologie onder ontwerpers en ontwikkelaars. Men is bij de Faculteit Toegepaste Onderwijskunde al vijftien jaar bezig met onderzoek naar methoden en technieken, met name bij de vakgroep/afdeling educatieve instrumentatietechnologie. Vooral Min is zeer actief op dat gebied. Reeds in 1987 publiceerde hij een boek over methoden en technieken op het gebied van computersimulatie (Min, 1987); in 1996 ook nog (Min, 1996); en in de periode 1992 - 2002 publiceerde hij veel over methoden en technieken voor het ontwikkelen van educatieve software op zijn internetsite (Min, 2002). Hij beschrijft daar allerlei methoden voor het ontwerpen en ontwikkelen van software; en met name animatietechnieken en grafische technieken zoals die voor komen in simulatieomgevingen en drill and practice programmatuur. Er ontbrak nog een goed overzicht in methoden en technieken op het gebied van de educatieve software (en courseware); vooral aangaande webtechnologieën. Dit doctoraalverslag wil hierin voorzien. Dit project wil een aanzet geven voor het leggen van een gefundeerde basis voor het gebruik van termen binnen de software wereld. Tevens wil men de voor- en nadelen van verschillende methoden en technieken weergeven, als een bijdrage ter bevordering bij het ontwikkelen van leeromgevingen. Het project is in vier fasen verdeeld, namelijk:

Het project wordt uitgevoerd door een onderzoeksteam, bestaande uit dhr. Min, dhr. De Diana en mw. Gomez-Vries. In het verslag wordt naar deze mensen gerefereerd met het persoonlijke voornaamwoord wij. Het gehele traject van het project wordt in dit onderzoeksteam constant overwogen, besproken en bediscussieerd.

Verder zijn er tijdens het onderzoek deskundigen op het gebied van software engineering en het maken van leeromgevingen benaderd. De verschillende instrumenten zijn onderzocht en specialisten op bepaalde instrumenten zijn geïnterviewd in de vorm van één-op-één formatieve evaluatie. Ontwerpers en ontwikkelaars zijn geënquêteerd om een beeld te krijgen van het veld. Het verslag dat voor u ligt is het resultaat van ongeveer zes maanden onderzoek. Het eerste hoofdstuk van het verslag is een introductie op de opdracht, de opdrachtgever en de probleemstelling. De werkhypothese en de aanpak van de opdracht worden hierin beschreven. In hoofdstuk twee wordt het vooronderzoek in de vorm van een literatuuronderzoek behandeld. Aan de hand van kernwoorden worden de verschillende definities bestudeerd en weergegeven. Conclusies worden getrokken en de probleemanalyse wordt beschreven. Vanuit de literatuur wordt een definitielijst samengesteld. Hoofdstuk drie is een weergave van de expert interviews die hebben plaatsgenomen. De experts zijn benaderd om hun mening te geven over bestaande termen en om gehanteerde definities te beschrijven. Vanuit de interviews wordt een begrippenlijst gemaakt die duidelijkheid moet verschaffen over de termen die gebruikt worden bij het realiseren van omgevingen. Het vierde hoofdstuk geeft een waardering van de karakteristieken van de geselecteerde instrumenten die door de meeste geïnterviewden en geënquêteerden worden gebruikt. Een interessante tabel met de verschillende talen en tools is het resultaat van dit onderzoek. Hoofdstuk vijf beschrijft de enquête die heeft plaatsgevonden onder ontwerpers en ontwikkelaars van software- en leeromgevingen. Het veld wordt benaderd om hun mening te geven over de methoden en technieken die zij gebruiken bij het ontwikkelen van software- en leeromgevingen. In hoofdstuk zes worden conclusies getrokken van de uitgevoerde onderzoeken en de bevindingen. Aanbevelingen worden gegeven voor eventuele toekomstige onderzoek.

Hoofdstuk 1: Introductie

1.1 De opdracht
In het kader van het afstudeerproject “Open of gesloten? Methoden en technieken voor het realiseren van leeromgevingen” zijn er studies gedaan om te onderzoeken welke definities aan de verschillende termen gegeven worden; welke methoden en technieken gebruikt worden voor het maken van leeromgevingen door verschillende mensen; welke factoren een rol spelen onder de ontwerpers en ontwikkelaars, om uiteindelijk te komen tot begripsverduidelijking.

1.2 De opdrachtgever
De Universiteit Twente, Faculteit Toegepaste Onderwijskunde, afdeling Instrumentatietechnologie is de opdrachtgever voor dit project. Toegepaste Onderwijskunde is een veelzijdige opleiding waarin je te maken krijgt met alle facetten van organiseren, ontwerpen, concretiseren, uitvoeren en verbeteren van training en scholing. Het vakgebied van de instrumentatietechnologie (ISM) bestudeert de presentatie- en interactievormen met media en telematica bij kennisoverdracht en ondersteuning voor leren en werktaken. Het doel van instrumentatietechnologie is theorievorming en ontwerpkennis over de keuze, het ontwerpen, de ontwikkeling, de implementatie, het gebruik en de evaluatie van educatieve instrumentatie voor werkondersteuning. Naast bijdragen aan theorievorming draagt het vakgebied ook bij aan het versterken van de te gebruiken methodologie en technologie. Dit project staat onder leiding van dr.ir. F.B.M. Min en dr. I.P. De Diana, beiden universitair docent binnen de vakgroep ISM.

1.3 De probleemstelling
Voorafgaand aan de formulering van de probleemstelling wordt het probleem eerst geanalyseerd. Volgens Swanborn (1999) is de probleemanalyse een fase die voorafgaat aan elk evaluatieonderzoek, waarin de definitie van het probleem, de herkomst van het probleem, het draagvlak voor het probleem en de aanverwante vragen worden gesteld en beantwoord, en tenslotte wordt de vertaling van het probleem in een probleemstelling voor wetenschappelijk onderzoek omgezet. De probleemstelling is de zo precies mogelijk geformuleerde vraag waarop het onderzoek het antwoord moet leveren. Het probleem is dat er geen duidelijkheid bestaat over en bij het gebruiken van bepaalde termen binnen het realiseren van omgevingen, specifiek leeromgevingen. Het is een feit dat er verschillende methoden en technieken gebruikt worden met hetzelfde doel: het maken van leeromgevingen. Maar welke methoden en welke technieken, is niet duidelijk. Er worden ook verschillende invullingen aan deze termen gegeven. De definities en beschrijvingen van deze invullingen zijn niet duidelijk en de keuze voor een bepaalde methode of techniek ook niet. Het blijkt dat er zowel open als gesloten systemen bestaan, maar wat er onder verstaan wordt is voor elk discipline anders. Leeromgevingen worden door verschillende mensen gemaakt, aan de ene kant door professionele ontwikkelaars en aan de andere kant door wetenschappelijke ontwikkelaars. Of er een verschil bestaat in het ontwikkelen bij deze twee typen ontwikkelaars is onduidelijk. De vraag naar leeromgevingen is groeiende, en dus de vraag naar ontwikkelaars. Om deze ontwikkelaars op te leiden is duidelijkheid en uniformiteit voor het gebruik van bepaalde termen een vereiste. De docenten willen de studenten zo goed mogelijk kunnen informeren op dit gebied. Vanuit de hierboven beschreven punten is er een probleemstelling geformuleerd, die luidt: “Welke methoden en technieken leiden tot open en welke tot gesloten software architecturen?” Hierbij beschouwt men een leeromgeving als een software architectuur. De probleemstelling is in de subvragen onderverdeeld:

1.4 De werkhypothese
Naast de probleemstelling is er in de eerste fase, tijdens het proces van interviewen, een werkhypothese samengesteld om discussie uit te lokken. De werkhypothese is meegenomen in de verschillende fases van het onderzoek. De werkhypothese luidt als volgt: “Alle web-based producten kunnen in principe worden gemaakt met HTML, Java of JavaScript”.

1.5 De aanpak
De opdracht of het project wordt uitgevoerd door het onderzoeksteam. Dit onderzoeksteam komt wekelijks bijeen om de gang van zaken van het project te bespreken. Daar waar nodig wordt het proces bijgestuurd en verder ingevuld. Het gehele traject van het project wordt in dit onderzoeksteam constant overwogen, besproken en bediscussieerd. De opdracht is onderverdeeld in vier fases van onderzoek. In de eerste fase heeft er een literatuuronderzoek plaatsgevonden. In deze fase worden de verschillende definities aan de hand van kernwoorden uit de literatuur verzameld en bestudeerd. De meest relevante definities of omschrijvingen van de gekozen termen zijn in een definitielijst als bijlage 2 in het afstudeerverslag opgenomen. Vanuit de bevindingen is fase twee opgezet. In fase twee zijn er experts interviews afgenomen. Deskundigen op het gebied van software architectuur c.q. leeromgevingen zijn benaderd om de probleemstelling te onderzoeken. Voor deze interviews is een vragenlijst gehanteerd. Aan de hand van de resultaten uit de expert interviews is een instrumenten onderzoek ingesteld. In de derde fase van de opdracht is er een instrumenten analyse uitgevoerd, met aaneensluitend een formatieve evaluatie onder specialisten van geselecteerde instrumenten. Het doel is een validatie van de karakteristieken van de instrumenten. Fase vier bestaat uit een enquête onder de ontwerpers en ontwikkelaars. Questionnaires zijn het veld ingestuurd, om de mening van deze ontwerpers en ontwikkelaars te peilen.

Hoofdstuk 2: Definities

2.1 Inleiding
Dit hoofdstuk is een weergave van het literatuuronderzoek. Het literatuuronderzoek heeft als doel informatie te verzamelen over het onderwerp van dit afstudeerproject, maar vooral voor wat betreft de termen die van belang zijn binnen deze opdracht. Het literatuuronderzoek is het vooronderzoek van dit afstudeerproject en het heeft in de eerste fase van deze doctoraalopdracht plaatsgevonden. In deze fase heeft er een oriëntatie plaatsgevonden zoals Plomp et al. (1992) dit beschrijven in hun boek, namelijk: de vooronderzoeksfase begint met een oriëntatie van het probleem en het verzamelen van informatie met als doel te komen tot een analyse van het probleem, de context en de behoeften (Plomp et al., 1992). Tijdens de oriëntatie van het probleem, waarbij er uitgegaan wordt van het probleem zijnde onduidelijkheid bij het gebruiken van bepaalde termen binnen het realiseren van leeromgevingen, zijn er kernwoorden gekozen die in deze opdracht van belang zijn bij het zoeken en verzamelen van informatie. De informatie verkregen door de kernwoorden zal duidelijkheid moeten verschaffen over bestaande definities. De kernwoorden die gebruikt zijn tijdens het vooronderzoek zijn in deze volgorde gehanteerd:

Wij hebben de term software architecturen als uitgangspunt genomen, met de gedachte informatie te zoeken vanuit een groot veelomvattend geheel, een software architectuur. Van daaruit zoekt men verder naar informatie over een kleiner geheel, een leeromgeving. Wij gaan ervan uit dat software architecturen veel verschillende soorten omgevingen kunnen omvatten, onder andere leeromgevingen. Daar men vooral geïnteresseerd is in leeromgevingen, wil men het onderzoek daar naar toe leiden. Vervolgens zal men zich oriënteren op de methoden en technieken die gebruikt worden voor het realiseren van leeromgevingen. Als laatste wordt informatie verzameld over de ontwerpers en ontwikkelaars van leeromgevingen. Door deze lijn te volgen verzamelt men de nodige informatie omtrent het probleem, c.q. de probleemstelling, met als doel te komen tot verduidelijking van het probleem.


Alle begrippen die we in dit onderzoek zijn tegengekomen zijn te herleiden tot de drie belangrijkste basisbegrippen: 1. ontwikkelen (in dit verband beter dan ontwerpen), 2. methode (beter dan tool); en 3. resultaat (beter dan cd-i of web-pagina); onder het motto: om een resultaat te bereiken gebrik je een methode om iets te ontwikkelen. Voorbeelden: Ontwerpen is daarmee te herleiden tot ontwikkelen; het begrip instrument of tool is te herleiden tot het begrip methode; en een open systeem (als internet) is te herleiden in de richting van het begrip resultaat (of product).

Het verzamelen van informatie vindt plaats zowel in universiteitsbibliotheken als op Internet. De analyse van het probleem zal leiden tot duidelijkheid in de vorm van een definitielijst.

2.2 De verschillende definities
Er is veel geschreven en er is veel onderzocht, door verschillende auteurs, naar definities voor veel gebruikte termen in de wereld van software. Toch blijkt dat er geen standaard, universeel geaccepteerde definitie bestaat over de term software architectuur.

2.2.1 Software architectuur
In de website van Carnegie Mellon Software Engineering Institute (2002) meldt men dat software architectuur een gebied is dat in de kinderschoenen staat, ook al zijn de wortels diep geschoten in software engineering. Alhoewel er aan de ene kant geen standaard definitie voor de term bestaat, zijn er aan de andere kant veel beschrijvingen voor deze term. Zo heeft Carnegie Mellon Software Engineering Institute, een federaal centrum voor onderzoek en ontwikkeling dat onder toezicht staat van Carnegie Mellon University in de Verenigde Staten, in hun website een aparte pagina gemaakt voor definities voor de term ‘software architecture’. Deze pagina hebben zij weer onderverdeeld in ‘Textbook Definitions’, ‘Classic Definitions’, ‘Bibliographic Definitions’ en ‘Visitors Definitions’. Uit elke onderverdeling is er één definitie gekozen, die net iets anders is en toch in relatie staat tot de andere definities en van belang blijkt voor dit onderzoek. In de lijst ‘Textbook Definitions’ is de definitie van Jazayeri, Ran en van der Linden (2000) het meest opvallende: ‘Software architecture is a set of concepts and design decisions about the structure and texture of software that must be made prior to concurrent engineering to enable effective satisfaction of architecturally significant explicit functional and quality requirements and implicit requirements of the product family, the problem, and the solution domains.’ Jazayeri et al. leggen deze term uit aan de hand van wat er in hun ogen in een software architectuur moet komen. Zo leggen zij de nadruk op de begrip- en ontwerpbesluiten voor de structuur en samenstelling van de software. Deze omschrijving geeft weer dat er vooral veel aan planning moet gebeuren voordat er een software architectuur opgezet kan worden. Onder ‘Classic Definitions’ is er gekozen voor de definitie van Garlan en Perry (1995): ‘Software architecture is the structure of the components of program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.’ Garlan en Perry gaan er vanuit dat een software architectuur een structuur is met componenten van een programma of een systeem. De definitielijst onder ‘Bibliographic Definitions’ heeft een interessante definitie, namelijk die van Kruchten (1998): ‘Software architecture deals with the design and implementation of the high-level structure of the software. It is the result of assembling a certain number of architectural elements in some well-chosen forms to satisfy the major functionality and performance requirements such as scalability and availability.’ Kruchten geeft meer inhoud aan de definitie van een software architectuur, namelijk hij vindt dat zowel het ontwerp als implementatie van de structuur van de software ertoe behoort. Verder noemt hij er expliciet bij dat de structuur op hoog niveau is. Van de ‘Visitors Definitions’ is de volgende definitie van belang bevonden, omdat de auteur een software architect is: ‘Software Architecture enables us to clearly define various components and their interactions in the context of a whole system. It also is a tool to discover, predict and address issues related to performance, deployment, and maintenance and product evolution. Rather than being a fixed blueprint for a system, Software Architecture is a fluid process that works as a feedback loop, constantly evolving and optimizing with the solution and changing with business needs’ (Dutta, 2002). Dutta noemt software architectuur een geheel, een systeem, maar ook een tool. Verder heeft hij het over een vloeibaar proces te vergelijken met een feedback loop. In dezelfde lijst blijkt dat ook een Nederlander een poging heeft gewaagd om een definitie van de term te geven: ‘A software architecture is a comprehensive system description defining how the requirements of the user are reconciled into an operational system. User requirements include functional as well as non-functional requirements such as e.g. performance, capacity, scalability, availability, confidentiality, integrity and costs. In general, a decomposition of the system into multiple cooperating components is necessary to establish the feasibility of the architecture, evaluate the compliance to the requirements, and determine the costs’ Boogaards (2002). Kort samengevat noemt hij een software architectuur een veelomvattende systeembeschrijving. Bredemeyer (2002) heeft in haar website ‘The Architecture Discipline’ software architectuur beschreven als volgt: ‘Software architecture is the high-level structure of a software system. It is an overall view of the solution to a problem; the high-level design of modular components and how they interact; a foundation that one can build on to solve a problem (e.g. rules, policies, attributes, etc.); an efficient method to meet a fixed set of well-defined attributes.’ Bredemeyer heeft het over een hoog niveau structuur. Verder noemt Bredemeyer software architectuur het systeem, welke beschouwd kan worden als een geheel vanwege het hoge niveau van abstractie, welke een overzicht geeft van de oplossing op het probleem.

2.2.2 Leeromgeving
Voor de term leeromgevingen zijn er ook verschillende definities in de literatuur terug te vinden. De definities die een rol spelen in deze opdracht zijn computer-based leeromgevingen. Mendelsohn (1996) geeft de volgende definitie voor een leeromgeving: ‘A learning environment is a society of agents for which we specified: a. the role distribution over agents (coach, tutor, experts); b. protocols of communication among agents (global- and local-interaction mode, repair, conflicts, etc.).’ Mendelsohn vult de term leeromgeving heel praktisch in, met rolverdeling over de vertegenwoordigers en de protocollen van communicatie tussen de vertegenwoordigers. Salomon (1991) beschrijft een leeromgeving als: ‘A composite of constituent factors: physical setting, set of agreed on behaviors, consensually held expectations and understandings, particular tasks, around pre-specified contents for explicitly stated goals that are guided by a person who has been given the responsibility over that setting, its participants, and activities. In other words: a learning environment is first and foremost a system that consists of interrelated components that joint affect learning in interaction with (but separately from) relevant individual and cultural differences.’ Salomon geeft een heel gedetailleerde omschrijving van de term leeromgeving. Samenvattend heeft hij het over een samenstelling van vormende factoren en een systeem met componenten die leren in interactie veroorzaken. Wilson (1995) geeft de volgende inhoud aan leeromgeving: ‘A learning environment contains: the learner and a setting or "space" wherein the learner acts, using tools and devices, collecting and interpreting information, interacting perhaps with others, etc.’ Wilson beschrijft de inhoud van een leeromgeving, waarbij hij de lerende en een ruimte als de inhoud van een leeromgeving ziet.

2.2.3 Methoden en technieken
Definities voor de termen methode(n) zijn eerst in het algemeen bekeken, en daarom uit woordenboeken en een encyclopedie gehaald. De definitie in het Complete Nederlandse woordenboek luidt: een methode is een welbedachte manier van handelen om een zeker doel te bereiken; een leerwijze, een leerboek; wijze van handelen bij een wetenschappelijk onderzoek (Bookman, 1999). Van Dale (1999) zegt bijna hetzelfde als het Complete Nederlandse Woordenboek: vaste, weldoordachte manier van handelen om een bepaald doel te bereiken. Webster (1986) heeft het over ‘A procedure or process for attaining an object.’ De Grote Winkler Prins Encyclopedie (1975) beschrijft een methode als volgt: in het algemeen de wijze waarop, of de regels volgens welke men te werk gaat om een bepaald doel te bereiken. In de literatuur is een korte definitie van methoden gegeven door Plomp et al. (1992), zij hebben het over werkvormen. Nijhof et al. (1995) hebben het specifiek over curriculum en definiëren methoden als producten op het microniveau, zoals curriculummateriaal, onderwijsleermateriaal, lesmateriaal, leergang, leerboek, schoolboek, leermiddel. Verder is er in de literatuur gezocht naar methoden meer gespecificeerd op het gebied van software. De volgende definities is gevonden. Een methode hierbinnen dit definitiegebied, is een manier om software en met name educatieve software te ontwikkelen en te realiseren (Min, 2000).

De term technieken wordt door het Complete Nederlandse Woordenboek gedefinieerd als bewerkingen of verrichtingen die nodig zijn om in een bepaalde tak van kunst, nijverheid en dergelijke iets tot stand te brengen; het geheel van verrichtingen van de toegepaste exacte wetenschappen (Bookman, 1999). Van Dale (1999) geeft verschillende definities voor de term technieken, maar wij hebben voor de meest toepasselijke definitie in dit onderzoek gekozen en dat is technische hulpmiddelen. ‘Technique is the way in which technically details are treated the manner in which a creative artist use the technical elements of his art to express himself’ (Webster, 1986). Uit de literatuur is een omschrijving van technieken gevonden, van Wieringa et al. (1998): ‘Techniques for representing properties of software, e.g. natural languages, formal languages and diagram techniques.’ Verder wordt het begrip techniek door Min (2000) onderverdeeld in drie soorten technieken: presentatie-, acceptatie- en communicatietechniek. Met presentatietechnieken bedoelt Min ook wel outputtechnieken, met acceptatietechnieken ook wel inputtechnieken en met communicatietechnieken de (interne) communicatie tussen een programma, een bestand en/of een model.

2.2.4 Open en gesloten systemen
De termen open en gesloten systemen werden tijdens deze studie telkens weer ter discussie gesteld. In de literatuur is gezocht naar uitleg en verduidelijking van deze termen en de volgende definities zijn gevonden. Kramer & de Smit (1991) beschrijven open systemen als open als er een verzameling entiteiten bestaat die niet tot het systeem behoort, maar die de toestand van het systeem beïnvloedt respectievelijk wordt beïnvloed door de toestand van het systeem. Gesloten systemen hebben volgens hen geen wisselwerking met de omgeving, doordat hij de relaties die er zijn tussen systeem en omgeving buiten beschouwing laat. Zij halen in hun boek Bertahanffy (1956) aan, die gesloten systemen omschrijft: ‘Closed systems are systems which are considered to be isolated from the environment.’ De term open geeft aan dat er beïnvloeding van buitenaf op het systeem plaats kan vinden, terwijl gesloten aangeeft dat er geen beïnvloeding van buitenaf is. Beïnvloeding van buitenaf wijst op de omgeving van het systeem, dat er buiten het systeem ligt. Kramer en de Smit hebben het over systemen in het algemeen, zoals auto’s, ecologische systemen, de mens als systeem, etc. Wanneer wij het over systemen hebben, bedoelen wij software systemen. Systemen kunnen refereren naar de software architecturen, maar ook naar de leeromgevingen. Systemen kunnen ook netwerksystemen zijn, zoals het internet als systeem ten opzichte van CDI of iMode als systeem. Het internet is bij uitstek een open systeem. (Voor discussie over open en gesloten tools: zie elders in dit verslag.)

2.2.5 Ontwerpers en ontwikkelaars
Volgens het Complete Nederlandse Woordenboek is een ontwerper iemand die een ontwerp (plan) maakt. Terwijl een ontwikkelaar een projectontwikkelaar kan zijn; iemand die iets maakt of laat uitgroeien tot een eindvorm. Een wetenschappelijke ontwikkelaar is iemand die ontwikkelt door studievormen, kennis bijbrengen; iemand die een theorie uitwerkt of iemand die een thema beknopt uiteenzet (Bookman, 1999). Van Dale (1999) geeft aan de term ontwerper de definitie iemand die iets ontwerpt; hij die de vorm van industriële producten ontwerpt is een ontwerper. Van Dale geeft geen definitie voor een ontwikkelaar in de zin van projecten. Webster (1986) heeft het over een ontwerper/ ’designer’ wanneer ‘One who conceives plans.’ Terwijl een ontwikkelaar een ‘developer’ is, ‘a person who develops something habitually or as an occupation’. Plomp et al. (1992) hebben het over iemand die zich richt op problemen in de huidige werkelijkheid en de oplossing op relatief korte termijn dient te bereiken, wanneer zij het over een ontwerper hebben. Zij gebruiken de term ontwikkelaar niet. Nijhof et al. (1995) schrijven: het ontwerpen is in wezen niets anders dan het concreet vormgeven aan een idee. Het vormgeven aan een idee kan een plan wezen. Aangezien we het hebben over software architecturen, is er gekeken naar de architect als ontwerper/ontwikkelaar. Ontwikkelen is het concreet vorm geven van een ontwerp. Een architect wordt door Webster (1986) als volgt beschreven: ‘a person who designs buildings and advises in their construction; a person who designs and guides a plan or undertaking.’ Als we de definities voor ontwerper en ontwikkelaar zoals gegeven in het Complete Nederlandse Woordenboek hanteren, dan is een architect volgens Webster, zowel een ontwerper als een ontwikkelaar. Het blijkt dat er definities bestaan voor de term software architect. Deze wordt door Barbacci (1998) als volgt beschreven: ‘The software architect is more likely to be trained in an engineering or science school and is usually familiar with one or more of the technologies (e.g., security, communications, storage, operating systems) used to build the system.’ Barbacci maakt een onderscheid in de opleiding die de architect heeft gevolgd. Bredemeyer & Malan (1999) schrijven over de rol van een software architect: ‘a simplistic view of the role is that architects create architectures, and their responsibilities encompass all that is involved in doing so. This would include articulating the architectural vision, conceptualizing and experimenting with alternative architectural approaches, creating models and component and interface specification documents, and validating the architecture against requirements and assumptions.’ In de ogen van Bredemeyer en Malan is een architect niet alleen een ontwerper en een ontwikkelaar, maar ook de projectleider. In de praktijk worden de ontwerpers en ontwikkelaars onderverdeeld in aan de ene kant professionele en aan de andere kant wetenschappelijke ontwerpers of ontwikkelaars. Professioneel betekent aan een beroep eigen, terwijl wetenschappelijk betekent volgens en/of betreffende de wetenschap. De literatuur spreekt over een professional wanneer het iemand is die iets beroepshalve doet en over een wetenschapper wanneer het iemand betreft die een bepaalde tak van wetenschap beoefent (Bookman, 1999). Uitgaande van de eerder genoemde definities, is een professionele ontwerper dan iemand die beroepshalve ontwerpt, beroepshalve een plan maakt. Een professionele ontwikkelaar zou dan iemand zijn die beroepshalve een projectontwikkelaar is; iemand die beroepshalve iets maakt of laat uitgroeien tot een eindvorm. Een wetenschappelijke ontwikkelaar is iemand die beroepshalve ontwikkelt door studievormen, kennis bijbrengen; iemand die beroepshalve een theorie uitwerkt of iemand die beroepshalve een thema beknopt uiteenzet.

2.3 Probleemanalyse
Een waslijst aan betekenissen voor wat betreft de term software architecturen en toch geen standaard definitie. Uit de literatuur blijkt wel dat software architecturen de ruggengraat vormen voor het maken van succesvolle software systemen. Elk van de eerder genoemde auteurs ziet software architectuur vanuit hun specialistisch oogpunt. Er zijn kleine verschillen en overeenkomsten in de definities. Zo noemen de meeste auteurs software architecturen structuren. Jazayeri et al. (2000) leggen de nadruk op de begrip- en onwerpbesluiten voor de structuur en samenstelling van de software. Garlan en Perry echter leggen meer nadruk op de componenten van een programma of een systeem. Kruchten (1998) noemt er expliciet bij dat de structuur op hoog niveau is, terwijl hij de nadruk legt op het ontwerpen en implementeren ervan. Bredemeyer (2002) heeft het over een structuur met een hoge niveau van abstractie. Dutta (2002) noemt software architectuur een geheel, een systeem, maar ook een tool, terwijl Boogaards (2002) het over een veelomvattende systeembeschrijving heeft. Samenvattend kan genoteerd worden dat de definities die zijn beschreven wel overeenkomen met de uitgangspunt van dit onderzoek. Men is namelijk uitgegaan van het standpunt dat software architectuur een groot veelomvattend geheel is en dit wordt door verschillende auteurs als zodanig gedefinieerd.

De term leeromgevingen wordt door de auteurs heel praktisch en toch heel verschillend ingevuld. Mendelsohn (1996) heeft het over de rolverdeling over de vertegenwoordigers en de protocollen van communicatie tussen de vertegenwoordigers, waarbij hij meer de technische kant bekijkt. Salomon (1991) daarentegen heeft het over de samenstelling van factoren en componenten, waarbij hij het proces van het leren als hoofdzaak beschouwd. Wilson (1995) vult de leeromgeving in als een omgeving met een lerende en een ruimte waarin die lerende kan handelen. Deze bevindingen zouden samen een totale omschrijving kunnen geven van de term leeromgeving; de een vult de rolverdeling van de gebruikers vanuit de technische kant in; de ander beschrijft meer de inhoudelijke kant en als laatste worden de gedragscodes van de gebruiker en de ruimte als belangrijk beschreven. Een voorbeeld van een leeromgeving is TeleTOP. TeleTOP wordt omschreven als een webgebaseerde platform dat veel cursusmanagement-mogelijkheden biedt voor docenten, onderwijzers, studenten en leerlingen. TeleTOP is een elektronische werk- en leeromgeving.

Voor wat betreft de termen ontwerpers en ontwikkelaars is men tot de ontdekking gekomen dat als men alleen de definities vanuit de woordenboeken in acht neemt, dat men dan zou kunnen concluderen dat ontwerpers in de beginfase van een project zitten, namelijk bij het ontwerpen van een plan. En de ontwikkelaars zitten in de fase van ontwikkelen, waarbij het plan ontworpen door de ontwerper(s), wordt uitgevoerd. Plomp et al. (1992) gaan uit van problemen met instructies, en richten zich dan ook specifiek op instructieontwerpers. In deze opdracht komt deze omschrijving te kort, daar de ontwerpers hier niet specifiek en alleen over instructies gaan. Nijhof et al. (1995) bevestigen wat er aan beschrijving in de woordenboeken is gevonden, namelijk dat ontwerpen het vormgeven is van een idee, een plan. Het verschil tussen een ontwerper en een ontwikkelaar zit in het plannen maken en plannen uitvoeren. Een ontwerper plant, terwijl een ontwikkelaar die plannen (gemaakt door de ontwerper) uitvoert.

2.4 Conclusie
Het doel van een probleemoriëntatie is een globaal inzicht te krijgen in de aard en omvang van het probleem en in de noodzaak van een onderwijskundige oplossing (Plomp, 1992; Romiszowski, 1981). Het probleem, zoals in hoofdstuk één beschreven, geeft aan dat er geen duidelijkheid bestaat over het gebruik van bepaalde termen binnen het realiseren van omgevingen, en leeromgevingen in het bijzonder. Aan de hand van dit literatuuronderzoek hebben we met behulp van bepaalde kernwoorden definities gevonden die tot duidelijkheid kunnen leiden. Van de gevonden en gekozen definities is een definitielijst gemaakt.1 Het is echter de vraag in hoeverre deze definities herkenbaar zijn voor de makers van leeromgevingen en in welke mate zij gehanteerd worden in het veld. Om deze vraag te kunnen beantwoorden is er in fase twee van deze opdracht, een onderzoek ingesteld in de vorm van expert interviews. Hier wordt in hoofdstuk drie verder op ingegaan.

Hoofdstuk 3: Begripsvorming

3.1 Inleiding
Hoofdstuk drie biedt een beschrijving van het onderzoek dat in fase twee heeft plaatsgevonden. Fase twee is opgezet vanuit de resultaten uit het literatuuronderzoek, in de vorm van expert interviews. Deze fase van het onderzoek richt zich op de experts op het gebied van het maken van software in het algemeen, en leeromgevingen specifiek. De interviews zijn aan de hand van de probleemstelling voorbereid: “Welke methoden en technieken leiden tot open en welke tot gesloten software architecturen?” Deze probleemstelling is onderverdeeld in verschillende categorieën, die in vier vraagstellingen worden weergegeven. Elke vraagstelling is weer onderverdeeld in subvragen die opgenomen zijn in een vragenlijst.

3.2 Expert interviews
Om de probleemstelling te kunnen uitwerken is er gekozen voor het afnemen van experts interviews, omdat de nadruk ligt op de explorerende en voorbereidende functie. Een gunstige omstandigheid tijdens zo’n interview is dat er direct contact is met de geïnterviewde, dit ondersteunt de samenwerking. Verder kan zo’n gesprek flexibel zijn, welke de mogelijkheid tot diepgang biedt (Nieveen, 1996).

3.2.1. De methode
De deelnemers aan de eerste ronde van dit onderzoek zijn deskundigen. De onderzoeker gaat er van uit dat de mensen in staat en bereid zijn om betrouwbare informatie te geven. Volgens Swanborn (1999) is deze assumptie terecht bij individuele ondervraging.

3.2.2. Het doel
Het doel van de expert interviews is om duidelijkheid te scheppen in verschillende algemene termen om te komen tot begripsvorming. Wij hebben daarom een vragenlijst annex een begrippenlijst opgesteld. Met de verschillende termen wordt gerefereerd naar:

Het accent ligt echter vooral op de termen ‘open’ en ‘gesloten’ met relatie tot software architecturen. De algemene termen die onderzocht worden zijn:

De term ontwerper is hier bewust niet onderzocht, omdat het accent binnen deze opdracht meer op het realiseren (het maken, het uitvoeren) van omgevingen valt. Aan de hand van de verkregen data zullen fasen drie en vier opgezet worden.

3.2.3. De respondenten
De respondenten zijn experts of deskundigen te noemen op het gebied van het maken van software in het algemeen en leeromgevingen in het bijzonder. Volgens Swanborn (1999) wordt met expert of deskundige verstaan wetenschappers met specifieke kennis op het terrein in kwestie; zij zijn vertegenwoordigers van allerlei actorgroepen; of zij zijn vertegenwoordigers van de doelgroepen. De deskundigen, in dit gedeelte van het onderzoek, zijn voorgeselecteerde personen. Zij zijn uitgekozen aan de hand van hun kennis en/of werkervaring op het gebied van software architectuur, c.q. leeromgevingen. De respondenten zijn voor de interview uitgenodigd. In totaal zijn er zeven experts benaderd en alle zeven respondenten hebben meegewerkt aan deze fase van het onderzoek. De participanten zijn:

3.2.4. De procedure
De experts zijn persoonlijk, telefonisch of via e-mail benaderd en uitgenodigd voor een gesprek, met als doel een interview. Het doel van de interviews is tijdens de telefonische benadering kort weergegeven en het belang van participatie van de expert is duidelijk benadrukt. Het interview bestaat uit een individueel gesprek dat gevoerd is met de expert, aan de hand van een vragenlijst. De vragenlijst is niet van te voren aan de expert voorgelegd. Het onderzoek heeft plaatsgevonden in de maanden augustus tot en met oktober 2002. Na verzameling van de informatie verkregen door de interviews, wordt de data verwerkt en bestudeerd. De verkregen data wordt voor de invulling van de volgende fase gebruikt.

3.2.5. De instrumenten
Wij hebben gebruik gemaakt van een vragenlijst bestaande uit 24 open vragen. De vragen zijn onderverdeeld in de categorieën “Open en gesloten architecturen”, “Factoren die een rol spelen bij het kiezen voor een methode/techniek”, “De ontwikkelaars” , “Methoden en een technieken”. De vragenlijst is gebruikt tijdens de interviews. De vragen worden door de interviewer gesteld, en indien nodig nader uitgelegd, waarop de expert de kans heeft om de vragen te beantwoorden. Het interview is in de meeste gevallen opgenomen op een cassetterecorder. Van elk interview is een verslag gemaakt.

3.2.6. De resultaten
Open en gesloten software architecturen
De term software architectuur wordt door verschillende auteurs vanuit verschillende oogpunten bekeken en uitgelegd. Voor dit onderzoek zijn de definities, beschreven in het vooronderzoek, gehanteerd. Van belang zijn de definities die het meest in relatie staan met de probleemstelling en die het meest recent zijn. Hiervoor heeft men de volgende twee definities genomen. Ten eerste is dat de definitie van de invloedrijke auteurs op het gebied van software architectuur Garlan en Perry (1995). Zij beschrijven software architectuur als volgt: ‘Software architecture is the structure of the components of program/system, their interrelationships, and principles and guidelines governing their design and evolution over time.’ Ten tweede geeft de definitie Bredemeyer (2002) een meer praktische beschrijving van het woord: ‘Software architecture is the high-level structure of a software system. It is an overall view of the solution to a problem; the high-level design of modular components and how they interact; a foundation that one can build on to solve a problem (e.g. rules, policies, attributes, etc.); an efficient method to meet a fixed set of well-defined attributes.’ Vanuit de expert interviews zijn de volgende definities over open en gesloten software architecturen naar voren gekomen:

Aksit vertelt dat de termen open en gesloten systemen voor verschillende mensen verschillende betekenissen hebben. In communicatiesystemen betekent dat, dat communicatie protocollen (of lagen) geproduceerd kunnen worden door verschillende bedrijven. Met open verstaat hij implementatie binnen een bedrijf, maar de protocollen zijn niet echt open. Daar betekent het dat implementatie gemaakt kan worden door verschillende bedrijven. Volgens Aksit is de term ‘open’ moeilijk te definiëren, op het moment dat je iets definieert wordt het gesloten. Dus open is niet of moeilijk te definiëren. Aksit probeert software architectuur zo te ontwerpen dat het kan evolueren. Software architectuur die kan evolueren is een open systeem. Als software architectuur niet kan evolueren, als het niet kan veranderen, dan is het niet open maar een gesloten systeem. Een gesloten systeem is een systeem met één requirement, het heeft beperkte mogelijkheden om te evolueren.

Volgens Min geeft een open systeem de vrijheid om alles te doen, om alle tools te gebruiken, om objecten zoals applets van andere tools te gebruiken, zoveel als de ontwerper wil. Een open systeem is een systeem waar je met verschillende gesloten systemen op in kan werken. Je kan een open systeem vergelijken met een Meccano doos of Lego met oneindig veel onderdelen. Je kan eindeloos doorgaan en blijven toevoegen. Een voorbeeld van een open systeem is het Internet. Een editor is bijvoorbeeld een gesloten systeem. Een editor is ook een voorbeeld van een tool. Je gebruikt het net zolang totdat je programma klaar is. Met een gesloten systeem kan je per definitie nooit buiten de grenzen gaan, behalve professionals. Professionals kunnen bijvoorbeeld met Photoshop op bitniveau de file eventueel nog editen, met een speciale resource-editor. Voorbeelden van gesloten systemen zijn AuthorWare en Fusion (de oude versie).

De Diana denkt aan product-architecturen als er gesproken wordt over educatieve software. Voor hem kunnen product-architecturen leeromgevingen zijn of interactieve leermiddelen. Open architecturen zijn architecturen waarbij materialen gecombineerd kunnen worden die uit verschillende bronnen komen, zonder een speciale vertaalslag te hoeven maken. Gesloten architecturen zijn typisch voor producten die uit één bron komen, dus die uit één systeem worden gemaakt. Deze producten moeten worden aangepast aan materiaal uit andere bronnen om gebruikt te kunnen worden. Als voorbeeld van een open systeem noemt De Diana Fusion en voor een gesloten systeem AuthorWare. Fusion leidt tot een open systeem.

De Vries vindt dat de termen open en gesloten op verschillende dimensies betrekking kunnen hebben, internet en intranet bijvoorbeeld. Hij zou een gesloten omgeving in een tutorial zien en een open omgeving in een exploratieve omgeving. Architectuur is de mate waarin bijvoorbeeld de gebruikers (dit zou ook een dimensie kunnen zijn) in staat worden gesteld om bepaalde typische verschijningen of typische objecten binnen zo’n omgeving aan te passen of toe te voegen. Met andere woorden de mate van de mogelijkheden voor de gebruikers.

Winnips verstaat onder open daar waar de bron is vrijgegeven, zodat iedereen daar software van kan ontwikkelen. Een programmeertaal kan je eerder open noemen. Java is open, omdat je er zelf in kan programmeren en je kan altijd toevoegen. JavaScript netzo. Met AuthorWare kan je de broncode weggeven en het open maken. Bij gesloten is de bron ervan niet vrijgegeven, zodat de software gekocht moet worden. Het is ook mogelijk dat de vaststaande regels van de fabrikanten gesloten is. Flash bijvoorbeeld is gesloten, omdat de software van Macromedia nodig is om Flash te kunnen gebruiken. Bij een open tool zijn er meerdere editors, terwijl een gesloten tool een gesloten standaard heeft met één editor.

Zwart maakt het verschil in open en gesloten systemen in een plan. Een plan dat duidelijk en helder aangeeft wat het ontwerpen gaat kosten aan tijd, geld en mensen is in zijn ogen een gesloten plan. Een open plan is een plan waar nog allerlei dingen aan veranderd kunnen worden, bijvoorbeeld de kosten aan krachten kunnen hoger/lager uitvallen, afhankelijk van de wensen van de opdrachtgever.

Volgens van de Heide heeft een open educatieve software architectuur uitbreidingsmogelijkheden, terwijl een gesloten architectuur dit niet heeft. In een open architectuur kan je aan alle kanten uitbreiden, vanuit invloed op onderwijs, met interactie, parameters, etc. Gesloten educatieve software architectuur zijn structuren die voorgedefinieerd zijn. Deze hebben een vaste set aan mogelijkheden voor uitvoer. Zij hebben zeer beperkte uitbreidingsmogelijkheden. Een gesloten architectuur kan je afstemmen op vormen van onderwijs, zoals tutorials, maar interactie is beperkt.

Methoden en technieken
In dit onderzoek richt men zich op het maken van leeromgevingen. De methoden en technieken die daarbij gebruikt worden zijn van belang. De geïnterviewde experts hebben hun meningen hierover.

Aksit gebruikt de termen methode of techniek liever niet, want techniek is geen goed gedefinieerd woord. Techniek kan een oplossingstechniek zijn, het kan een proces- gerelateerde techniek zijn, maar het kan ook techniek zijn om bijvoorbeeld een probleem te analyseren, een probleem op te lossen, of techniek is een proces. Dus eigenlijk kan je alles uitdrukken onder de term techniek. Techniek refereert naar oplossingskennis. Aksit maakt een verschil tussen methode en techniek als volgt:
Een methode is een probleem oplossend proces, waar requirements worden omgezet naar problemen en problemen naar oplossingen, op een systematische manier totdat het product gerealiseerd wordt. Om dit te doen moeten de problemen opgelost worden. Daarvoor heb je oplossingstechnieken nodig. Het hele proces is een techniek, een procesachtige techniek. Methode is voor hem een proces waarin de technieken worden gebruikt. Maar een methode kan ook een techniek zijn, bijvoorbeeld een synthesetechniek om een probleem op te lossen. Dit is dus een methode en een metatechniek. Dan gaat het over de kennis om een probleem op te lossen. Een analyse-synthese is een techniek maar tegelijkertijd ook een methode.
Kennis om een methode op te lossen is een techniek.

Afhankelijk van het niveau van beschrijving, worden de termen anders gedefinieerd. Want een proces dat beschreven wordt is data. Kortom definieert Aksit een methode als een proces, waarin er stappen en artefacten worden onderscheiden om te kunnen moduleren. Terwijl kennis over een methode een techniek is.

Min geeft de volgende definities aan de termen methode, technieken en tools:
Een methode is op meta niveau, iets wat je gebruikt om iets te maken. Een methode is vaak een programmeertaal bijvoorbeeld JavaScript of ActionScript (in Flash), Fusion of AuthorWare. Een tool is een methode, bijvoorbeeld als de tool AuthorWare gebruikt wordt om iets te maken. Techniek is meer iets op micro niveau. Een techniek is een optie in een tool, bijvoorbeeld ‘cut and paste’. Een techniek binnen een programmeertaal is bijvoorbeeld een ‘if’ - statement.

De Diana vindt dat zowel methode als techniek worden gebruikt om dingen te maken. Techniek is een lager abstractie niveau dan methode. Methode is een handelingsvoorschrift. Het is niet duidelijk of er een methode of techniek is voor open of gesloten systemen. De methoden (van hogere orde) voor open systemen zijn ook open, dit betekent dat er flexibiliteit is in de methode. De techniek kan in deze best gesloten zijn. De techniek is minder abstract. Bij een methode kan je techniek inzetten, maar andersom niet. Een techniek pas je toe binnen een methode.

De Vries zou de volgende definitie geven voor een methode:een set van methode fragmenten en aanwijzingen voor het gebruik en aanwijzingen voor de situaties waarbinnen je het kan gebruiken. Hij gaat echter uit van het feit dat één methode niet bestaat. Een definitie voor technieken zou hij als volgt formuleren: technieken zijn de tools of methodefragmenten.

Winnips onderscheidt tools in harde of zachte tools. Harde tools zijn dan software en zachte tools zijn technieken. Technieken zijn manieren van werken, technieken zijn ingebakken in een tool. Methode ligt boven de techniek. Techniek is een stukje van de methode. Een methode is een ontwerpaanpak, bijvoorbeeld prototype benadering of instrumentele benadering. De manier waarop je ontwerpstappen ordent.

Zwart geeft niet duidelijk aan wat in zijn ogen een methode, wat een techniek is. Hij heeft het over tools. Hij zegt dat een open tool een tool is waarin er geprogrammeerd kan worden, met de hand gewerkt kan worden. Hij geeft verder de voorkeur aan technieken waar er zelf geprogrammeerd kan worden.

Van de Heide geeft geen duidelijke definitie van de termen. Hij noemt een editor zoals DreamWeaver een tool om te ontwikkelen en een methode kan een auteurstaal zijn. Verder weidt hij over de termen niet uit. In onderstaande tabel worden voorbeelden van methoden en technieken voor open en/of gesloten systemen onderverdeeld, volgens de experts.

Tabel 1: Methoden, technieken en tools
Zie elders.

Professionele en wetenschappelijke ontwikkelaars
Uitgaande van de literatuur worden de ontwikkelaars in twee typen verdeeld, de professionele ontwikkelaar en de wetenschappelijke ontwikkelaar. De experts geven de volgende invullingen aan deze termen.

Aksit vertelt dat bedrijven meestal voor een methode kiezen op basis van ‘hypes’, of doordat bepaalde publicaties ‘in de mode’ zijn. Maar de bedrijven komen naar de universiteit toe om de tekortkomingen te weten te komen. Een commercieel bedrijf heeft andere belangen dan een universiteit. Het belang van een bedrijf is om producten te verkopen. Zolang er geen concurrentie is hoeven zij niet over problemen te praten, zij verkopen door. De universiteit heeft een ‘industrial laboratory’ (bedrijfsleven) aanpak:

De universiteit geeft ook cursussen aan de bedrijven om hen te informeren over de methoden, populaire methoden (commercieel) en de tekortkomingen.

Min is van mening dat een professional, die heel snel iets moet maken een gesloten systeem zal gebruiken voor het ontwikkelen. Vaak zien de producten er dan wel allemaal hetzelfde uit, zie bijvoorbeeld Internet. Professionals hoeven geen revolutionaire dingen te doen om geld te verdienen bij een bedrijf. Maar een wetenschapper op de universiteit moet uitvinden, hij moet nieuwe dingen doen. Nieuwe dingen maken en onderzoeken. De wetenschapper is niet geïnteresseerd in tools, hij is meer geïnteresseerd in ontdekken, ontwerpen en maken, met het doel om grenzen te verleggen. Onderdelen van tools kunnen wel gebruikt worden om grenzen te verleggen. Vaak leiden de onderzoeken van wetenschappers en van bedrijven die ook aan onderzoek doen, wel weer tot gesloten systemen. Gesloten systemen ontstaan door wetenschappers of door bedrijven die vernieuwen, waardoor een ander bedrijf uiteindelijk een tool, een gesloten systeem heeft gemaakt, bijvoorbeeld Taiga, Fusion, AuthorWare. De wetenschapper gaat te werk wanneer er een probleem is, waar niemand uit kan komen. De wetenschapper gaat dit onderzoeken en een oplossing voor dit probleem zoeken. De Diana maakt een onderscheid in de profielen van ontwikkelaars:

Bedrijven hebben vaak omvangrijke ontwikkelteams en werken vaak met vaste methoden. Zij hebben te maken met productie-eenheid. Wetenschappelijke ontwikkelaars zijn kleinschalig bezig en werken met open systemen. Het meest open systeem die te bedenken is, is één wetenschapper die eigen product zelf maakt (dit is de extreme kant). Een ideale situatie zou zijn dat er meer aan de grootschalige kant gewerkt wordt, bijvoorbeeld courseware engineering met vaste methoden, vaste handelingen en bepaalde technieken. Volgens De Diana zijn open producten heel aantrekkelijk, wanneer ze te combineren zijn met een goede methode. Verder is De Diana van mening dat de ontwikkelaars in drie categorieën getypeerd kunnen worden:

Hierin zijn weer drie dimensies te onderscheiden, namelijk professionele ontwikkelaars versus beginners; wetenschappers versus praktische ontwikkelaars; en software ontwikkelaars versus vormgevers.

De Vries is van mening dat er een enorm verschil bestaat in het ontwikkelen in een bedrijf of in een universiteit. Het verschil is dat universiteiten moeten ontwikkelen in de zin van ‘proof of concept’, terwijl een bedrijf meer productgericht ontwikkelt. Als een bedrijf een Resource and Development (R&D) afdeling heeft, dan lijkt de ontwikkeling op het werk op die van het werk wat er binnen een universiteit wordt gedaan. Een ander verschil tussen een bedrijf en een universiteit is dat bij bedrijven concurrentie een grote rol speelt en dat een bedrijf uiteindelijk winst moet maken. In een universiteit spelen de resources (bronnen) een rol. Resource and Development zijn de primaire taken binnen een universiteit.

Volgens Winnips ligt het vooral aan de voorkeuren en eigenschappen van de ontwerper, welke methoden en technieken er uiteindelijk gekozen worden voor het realiseren van omgevingen. De type ontwerper kan verschillend gecategoriseerd worden, namelijk: pragmatisch, communicatief of technisch. Er zijn ook verschillen tussen ontwerpers die wetenschappelijk ingesteld zijn en aan de andere kant die zich meer op de praktijk richten. Een professionele ontwikkelaar zal gericht zijn op de klant. Hij/zij zal technieken hergebruiken, rekening houden met geld, samenwerken met veel mensen aan een product. Terwijl een wetenschappelijke ontwikkelaar in kleine clubjes met minder specialisten ontwerpt, minder aandacht schenkend aan de vormgeving, meer innovatief bezig zijn, met onderzoeksprototypes vernieuwend bezig zijn, meer liefde om te ontwerpen.

Zwart is ervan overtuigd dat er een verschil bestaat tussen professionele en wetenschappelijke ontwerpers. Professionele ontwikkelaars zijn afhankelijk van budget, tijd en de opdrachtgever voor het ontwikkelen van een product. Zij werken zuiver commercieel. Hun doel is het maken van een product waar de opdrachtgever blij mee is. Terwijl een wetenschappelijke ontwikkelaar als doel heeft iets onderzoeken om te bewijzen dat het waar is, dat het goed is en wat het beste is. Het verschil zit het in het doel.

Van de Heide ziet het verschil tussen een professionele ontwikkelaar en een wetenschappelijke ontwikkelaar in de factoren die een rol spelen bij het ontwikkelen. Een professional is namelijk gericht op de veiligheid tegen inbraak, snelheid om product op de markt te brengen, om de ontwikkelingskosten in bedwang te houden. Hij/zij moet letten op de concurrentie, wat leveringdatum (eerst op de markt) betreft, maar ook de prijs (wie kan goedkoper leveren), en de ondersteuning bij het eindproduct. Een wetenschappelijke ontwikkelaar echter heeft met andere factoren te maken. Hij/zij is gericht op de uiteindelijke mogelijkheden. Het doel van het onderzoek is voor hem/haar van belang, de ontwikkelingstijd op korte termijn of op lange termijn. De continuïteit van het product speelt ook een rol. Een wetenschappelijke ontwikkelaar kiest vaak voor methoden en technieken die bekend zijn, zoals PASCAL.

3.3 Analyse van de deskundigen Een zevental deskundigen op het gebied van het realiseren van leeromgevingen zijn geïnterviewd en hebben hun mening geuit. Elk expert heeft zijn eigen deskundigheid en geeft advies vanuit zijn kennis van zaken en vanuit zijn ervaring. De meeste experts hebben een duidelijke mening over de probleemstelling in zijn algemeenheid, sommigen zelfs heel specifiek. De punten waarop de experts het met elkaar eens zijn, wat betreft software architecturen, worden hier opgesomd:

  • Open software architecturen hebben de mogelijkheid om veranderingen aan te brengen, in de vorm van toevoegingen, correcties, vernieuwingen, etc. Men heeft meer vrijheid om te ontwikkelen met de vrije hand en de aansluiting op andere systemen is mogelijk.
  • Gesloten architecturen hebben beperkingen, maar zijn tevens aantrekkelijk gezien factoren als tijd, kosten en expertise. Daarnaast is het makkelijker te gebruiken voor het ontwikkelen en er is minder software nodig.

    Samenvattend geeft men in een tabel de uitspraken van de experts weer in de vorm van de voor- en nadelen van open en gesloten software architecturen.

    Tabel2: Software architecturen: open versus gesloten
    Zie elders.

    Voor wat betreft de termen methoden en technieken vertellen de experts het volgende:

    Voor de duidelijkheid worden de methoden, technieken en/of tools die gebruikt worden om software architecturen, c.q. leeromgevingen te maken vanaf dit punt in het onderzoek als instrumenten betiteld. De resultaten van de expert interviews in verband met de instrumenten, hebben onder andere geleid tot het samenstellen van onderstaand tabel. Deze tabel geeft weer of een instrument tot een open, gesloten of zowel open als gesloten software architectuur behoort.

    Tabel 3: Instrumenten zoals door experts is weergegeven
    Zie elders

    Over de professionele en wetenschappelijke ontwikkelaars zijn de experts het in grote lijnen met elkaar eens. Ontwikkelaars verschillen onderling van elkaar, afhankelijk van het werk wat zij moeten verrichten. Zowel professionals als wetenschappers zijn sterk afhankelijk van hun baas. Professionals zijn meer gericht op de commercie, terwijl de wetenschappers zich meer op de wetenschap van de methoden en technieken, de methodologie, richten. In onderstaande tabel wordt een samenvatting gegeven van de uitgangspunten van de ontwikkelaars, onderverdeeld in bedrijven aan de ene kant en universiteiten aan de andere kant, volgens de experts.

    Tabel 4:
    zie elders.

    3.4 Conclusie
    De term software architectuur wordt niet door iedere expert als zodanig gebruikt en daardoor ook niet gedefinieerd. De ene expert gebruikt de term software architecturen, de andere software systemen en weer een andere gebruikt de term omgevingen waar het eigenlijk om dezelfde beschrijving gaat. Volgens de literatuur is een architectuur echter van een hoger niveau dan een omgeving. Een omgeving kan in een architectuur zitten, terwijl andersom niet mogelijk is. Ook de termen methoden en technieken worden naar eigen invulling gebruikt en geïnterpreteerd. De term tools wordt door de een gebruikt voor methoden en door de ander voor technieken. De meeste overeenkomsten zijn te vinden in de beschrijvingen van de professionele en wetenschappelijke ontwikkelaars. Het verschil in gebruik van termen zit ook in de expertise van de deskundige. Een software engineer spreekt eerder over software architecturen, terwijl een onderwijskundige het eerder over een leeromgeving heeft. Afhankelijk van de expertise verschillen de definities van de onderzochte termen.

    Hoofdstuk 4: Instrumentenonderzoek

    4.1 Inleiding
    In dit hoofdstuk was het in eerste instantie de bedoeling om een productenonderzoek uit te voeren met als doel een productevaluatie. Met de producten wordt bedoeld educatieve software dat wil zeggen de uitkomst van arbeid, een realisatie van producten die gemaakt zijn met de door ons onderzochte methoden en technieken. We gaan er bij deze studie vanuit dat er slechts drie fundamenteel verschillende methoden zijn om educatieve software te maken, namelijk met auteurssystemen, met auteurstalen en met hogere programmeertalen. Op deze drie ontwikkelmethoden zijn alle hier beschreven methoden, technieken en tools terug te voeren. Het begrip productevaluatie wordt door Swanborn (1999) beschreven als een vlag die uiteenlopende ladingen kan dekken: ladingen die betrekking hebben op een fysiek product of verleende dienst, op een project of programma of op welk type interventie dan ook. In de industrie wordt de term gebruikt voor onderzoek in zowel de plan- en de procesevaluatie en in wat wij eigenlijk productevaluatie noemen. Gezien het verloop van het onderzoek en de beschikbare tijd hebben wij ons echter moeten beperken tot het onderzoeken van auteurssystemen, auteurstalen en programmeertalen. Voor de duidelijkheid hebben wij gekozen voor de term instrumenten als overkoepelende term voor de auteurssystemen, auteurstalen en programmeertalen. In deze derde fase wordt een analyse gemaakt van de instrumenten die gebruikt worden door de ontwikkelaars. Er wordt gekeken naar de eigenschappen en de kenmerken van deze instrumenten. De instrumenten zullen op een aantal van tevoren bepaalde criteria vergelijkend beoordeeld worden. De onderzoekers beperken zich tot vergelijkend onderzoek, met als uiteindelijk doel een waardering van de karakteristieken van de instrumenten. De verwachting in deze fase van het onderzoek is dat de hypothese: “Alle web-based producten kunnen in principe worden gemaakt met HTML, Java en/of JavaScript”, niet helemaal gehanteerd kan worden, want er zijn tegenwoordig veel meer instrumenten op de markt.

    4.2 De aanpak De web-based producten worden gemaakt met één of meerdere instrumenten. Er wordt tegenwoordig zoveel geproduceerd, dat het niet meer overzichtelijk is. Multimedia bedrijven over de hele wereld doen er van alles aan om de concurrentie aan te kunnen. Allerlei producten en instrumenten worden op de markt gebracht. Het is dan ook niet verwonderlijk dat er geen duidelijkheid bestaat in welk instrument het beste gebruikt kan worden om te ontwikkelen. Daar het aantal van instrumenten groot is heeft men een selectie gemaakt onder de auteurstalen, programmeertalen en tools. Voor de selectie heeft men de resultaten van de expert interviews gebruikt. De meest gebruikte instrumenten blijken HTML, DHTML, SGML, XML, Java, JavaScript, AuthorWare, Flash, DreamWeaver, Director en Fusion te zijn. Deze instrumenten worden uiteindelijk gerangschikt naar:

    Aan de hand van deze vragen worden de kenmerken, overeenkomsten en verschillen van deze instrumenten in kaart5 gebracht.

    4.3 De instrumenten
    In deze gedeelte van de opdracht worden de instrumenten vanuit de literatuur beschreven en volgens de eerder genoemde rangschikking onderverdeeld in open tools, gesloten tools en zowel open als gesloten tools.

    4.3.1 Open tools (voor open en gesloten systemen)
    Onder open tools verstaat men tools waarbij de ontwerper alle vrijheid heft om te ontwerpen. Met open systemen geeft men aan dat het systeem toegankelijk is voor iedereen, dat het systeem kan evolueren, dat er veranderingen aan te brengen zijn, etc. Met gesloten systemen refereert men naar architecturen met enerzijds beperkingen, maar met anderzijds aantrekkelijke factoren voor de ontwikkeling zoals tijd, kosten en expertise. Een omschrijving van de geselecteerde instrumenten wordt hier in het kort gegeven.

    HTML staat voor HyperText Markup Language. HTML is een verzameling internationaal afgesproken Engelstalige codes. HTML is geen programmeertaal, maar gewoon een set codes die op de PC ingetikt wordt om van een bestand een webpagina te maken. Vrijwel alle webpagina’s ter wereld worden gemaakt met HTML. HTML bestaat uit codes die in een tekstverwerker toegevoegd kunnen worden aan de tekst. Dit heet in HTML-jargon het verrijken (to mark up) van de tekst. Met HTML kan een webpagina net zo mooi gemaakt worden als gewenst, maar hoe de pagina er in de browser van een ander precies uitziet, kan niet helemaal zelf bepaald worden. Elke browser vertaalt de HTML-codes op zijn eigen wijze (Kamperbeek, 1998).

    DHTML staat voor Dynamic HTML. ‘DHTML is the marriage of several Web technologies, expanded to accommodate a new way of thinking about Web page design: style sheets, a scripting language and a document object model to tie it all together’ (Mudry, 1998).

    SGML staat voor Standard Generalized Markup Language (SGML) en is een internationale standaard voor documentatie. SGML is echter zeer omvangrijk, met name voor het web (Eckstein, 2000). SGML is ‘an international standard for the definition of device-independent, system-independent methods of representing texts in electronic form. It is an international standard for the description of marked-up electronic text. SGML is a metalanguage, a markup language’ (ISO, 1986).

    XML staat voor Extensible Markup Language en is een standaard voor het verwerken van documenten. XML is in feite een vereenvoudigde vorm van SGML. De ontwikkeling van XML is gestart toen men de taal SGML geschikter wilde maken voor het web. XML is een metataal waarmee men zelf document-markups kan maken. Met XML kan men gemakkelijk tags maken en deze aan eigen behoeften aanpassen (Eckstein, 2000).

    Java is ‘A simple, object-oriented, distributed, interpreted, robust, secure, architectural neutral, portable, high-performance, multithreaded, and dynamic language’ Internet related technologies (2000). De programmeertaal Java wordt onder meer toegepast voor het koppelen van een website aan gegevens in legacy-hardware (Hillenius, 2002).

    JavaScript is een scripttaal, die flitsende webpagina’s binnen ieders bereik brengt. JavaScript wordt gebruikt als onderdeel van HTML. JavaScript is speciaal ontwikkeld voor gebruik op het World Wide Web. Het is geen moeilijke programmeertaal, maar een gemakkelijk te leren scripttaal. JavaScript wordt gewoon in je eigen tekstverwerker ingetikt. JavaScript wordt binnen een HTML-pagina tussen speciale script-tags gebruikt. In feite wordt met behulp van JavaScript statische HTML-pagina’s dynamisch en interactief gemaakt (Kamperbeek, 1997). JavaScript is alleen niet geschikt voor dynamische visualisatie.

    4.3.2 Gesloten tools (voor open en gesloten systemen) Gesloten tools zijn instrumenten die kunnen gebruikt worden om producten te maken die in een open systeem draaien, maar ze kunnen ook gebruikt worden om producten te maken die in een gesloten systeem draaien.

    AuthorWare is ‘a multimedia authoring software for interactive learning and it is used world wide to create applications for both business and education’ (Macromedia,1993). AuthorWare geeft de mogelijkheid om oefeningen en applicaties te maken, zonder speciale technische know how. Het is ontworpen om interactieve en training applicaties te ontwikkelen. Macromedia (1993) noemt drie voordelen van AuthorWare in het maken van interactieve leer applicaties:

    In het tijdschrift Macworld schrijft men dat ‘AuthorWare is originally designed to enable educators to create interactive, educational courseware’ (Macworld,1996).

    Flash (oude versie) is een tool die onder de naam van FutureSplash eerst verkrijgbaar was als plug-in. Het is een editor voor het maken van website objecten (Tappel, 2000).

    DreamWeaver is een professionele editor c.q. tool van Macromedia, voor het ontwerpen en coördineren van websites. Volgens van den Anker, de Graaf, & Poppink (2000) is DreamWeaver in de professionele kringen één van de meest gebruikte WYSIWYG6-editors, waarbij de nadruk op het visuele aspect ligt en niet op de platte HTML. Het pakket biedt een enorme hoeveelheid functionaliteit en naadloze koppeling met andere populaire Macromedia software. Daar staat tegenover dat het een nogal steile leercurve kent; het duurt een tijdje voordat er efficiënt mee gewerkt kan worden. Tappel (2000) zegt hierover dat DreamWeaver de mogelijkheid heeft om aan te geven in welke browser en welke versie de website geschikt moet zijn. Een nadeel is dat voor de beginnende gebruiker de omgang met de Interface enige tijd en gewenning kost. Dit komt door de vele vensters en palets die binnen DreamWeaver gebruikt kunnen worden.

    Director is een animatie editor of een tool voor het maken van animaties. Drie belangrijke aanvullingen van versie 2.0 ten opzichte van versie 1.0.1 waren: de mogelijkheid om een document interactief te maken; het gebruik van 24-bit kleur; de mogelijkheid om externe video- en audioapparatuur aan te sturen (Stonehouse, 1990).

    4.3.3 Zowel open als gesloten tools (voor zowel open als gesloten systemen).
    Open tools zijn instrumenten waarvan de bron is vrijgegeven, terwijl bij de gesloten dit niet het geval is. Deze instrumenten kunnen gebruikt worden om producten te maken die in zowel een open systeem als in een gesloten systeem draaien.

    Fusion is een pakket dat is ontworpen om een hele website in één keer te ontwerpen en te publiceren op het Web (van den Anker, de Graaf, & Poppink (2000). ‘It is a powerful Web site building tool that helps you design and build full-featured, professional Web sites, without knowing HTML, the HyperText Markup Language used to display pages on the Web. When you preview or publish a site, Fusion automatically generates the HTML code your Web browser needs to diplay pages’ (NetObjects, INC., 1998). Deze laatste versie van Fusion ondersteunt Cascading Style Sheets en heeft een verbeterde tekst-editor aan boord, maar de focus ligt op WYSIWYG. In die zin is Fusion één van de best doordachte pakketten, met een heldere interface die vooral is gericht op het plannen en organiseren van een complete website zonder HTML-diploma (van den Anker, de Graaf, & Poppink (2000).

    Flash (nieuwe versie) is een interactief opmaak programma. Met Flash kan compacte multimedia voor toepassing op het Internet gemaakt worden. Verder geeft Flash de volgende mogelijkheden: realisatie van interactiviteit in een website; realisatie van vriendelijke gebruikersinterfaces in een website; en realisatie van dynamische/ interactieve animaties in een website (op een relatief simpele manier animaties maken). Het voordeel van deze tool is dat er gewerkt wordt met vectorgebaseerde afbeeldingen, waardoor er een enorme tijd en bandbreedtebesparing ontstaat. De Flash movies hebben relatief weinig ruimte nodig en zijn daardoor uitstekend geschikt voor het internet (Tappel, 2000).

    Director, de nieuwe versie, is de versie waarin Macromedia zich richt op de behoeften van de ontwikkelaars van multimedia met daarin de taal ActionScript. Hierdoor is deze tool heel open en transparant geworden. ‘Director 5.0 streamlines numerous aspects of the production process. Director 5.0 is the best available program for complex, performance-sensitive projects involving animations. This authoring legend retains its steep learning curve but it is the best choice for performance-sensitive, animation-oriented, cross-platform productions’ (Macworld, 1996).

    4.4 Het vergelijkend onderzoek
    De instrumenten worden volgens de eerder genoemde rangschikking naast elkaar gezet in een tabel om met elkaar vergeleken te worden. Vele discussies zijn gevoerd bij deze rangschikking, daar men het niet altijd met elkaar eens is over het wel of niet open zijn van een bepaald instrument. Uiteindelijk heeft men besloten om de onderverdeling in categorieën als volgt te rangschikken:

    Men heeft gedurende dit onderzoek gebruikt gemaakt van een eigen ontworpen tabel (tabel 5 Instrumenten7) om de gegevens en bevindingen van elk instrument te inventariseren. In de eerste kolom van de tabel zijn de onderzoeksvragen opgenomen. In de volgende kolommen zijn de instrumenten opgenomen, onderverdeeld in de drie verschillende categorieën. Uiteindelijk zijn er drie sheets gemaakt die een overzicht geven van de instrumenten.

    4.4.1 De inventarisatie
    De inventarisatie van de eigenschappen en kenmerken van de instrumenten is aan de hand van literatuur en in samenwerking met Min geschied. Voor deze inventarisatie is tabel 5 Instrumenten gebruikt, ter beoordeling van de verschillende instrumenten. Deze tabel bestaat uit drie sheets:

    Op alle sheets zijn in de eerste kolom de onderzoeksvragen verwerkt. Met de vraag ‘wat is het?’ wordt het instrument beschreven in de vorm van een auteurstaal of programmeertaal of tool. Voor de vraag ‘wat kan je ermee maken?’ heeft men gekozen om de volgende opties te beoordelen: game/simulatie; drill & practice; en gewone courseware/tutorials. Met de vraag ‘wat zijn de technische mogelijkheden van het instrument?’ richt men zich op animatie, simulatie, video, audio, interactie en koppeling aan database. ‘Welk uiteindelijk product oftewel resultaat is met dit instrument te bereiken?’ is een vraag waarmee men de mogelijkheden als eindproduct van een bepaald instrument wil toetsen in de vorm van een les, toets, spel, presentatie, gewone courseware en diversen. De vraag ‘Wat zijn de eigenschappen en kenmerken van het instrument?’ oogt de snelheid van het ontwikkelen binnen het instrument te inventariseren; de snelheid van het eindproduct; de bruikbaarheid voor het ontwikkelen; de effectiviteit voor het ontwikkelen; de moeilijkheidsgraad bij het ontwikkelen en of het instrument eenzijdig of meerzijdig te noemen is. ‘Wat is de specialiteit van het instrument?’ is de vraag die moet aangeven waarvoor een bepaald instrument het best is.

    Tijdens het proces van inventarisatie is men geconfronteerd met een programmeur die ervan overtuigd is dat men de instrumenten het best in twee categorieën kan laten vallen, namelijk talen en tools. Na onderlinge discussie is men tot de conclusie gekomen dat de instrumenten inderdaad het best onderverdeeld kunnen worden in die twee categorieën. HTML, DHTML, SGML, XML, Java en JavaScript vallen dan onder de categorie talen en de rest onder de categorie tools. Door dit besluit heeft men de tabel instrumenten moeten reviseren. Uiteindelijk heeft de gereviseerde tabel de volgende rangschikking:

  • Talen (voor open en gesloten systemen);
  • Gesloten tools (voor open en gesloten systemen);
  • Zowel open als gesloten tools (voor zowel open als gesloten systemen). Hierbij worden auteurstalen en programmeertalen onder talen ondergebracht. De term systemen kan zowel als software architecturen als leeromgevingen worden geïnterpreteerd. De uitgangspunt van de programmeur is aangenomen en als zodanig in deze fase verder verwerkt. Voor de beoordeling van de eigenschappen en kenmerken heeft men besloten om met plusjes en minnetjes te werken. Eén plus geeft aan dat het instrument matig werkt; twee plusjes geven aan dat het goed werkt; en drie plusjes geven aan dat het heel goed werkt; één min geeft aan dat het slecht werkt. Gedurende de inventarisatie is men tegen het probleem aangelopen dat bepaalde instrumenten technische mogelijkheden hebben om zelf bijvoorbeeld een video en/of audio te maken, terwijl andere instrumenten deze kunnen draaien als video en/of audio erin gehangen worden. Hiervoor heeft men de beoordeling tussen haakjes geplaatst. Eén plus tussen haakjes geeft aan dat het instrument matig kan werken met het inhangen van video/audio; twee plusjes tussen haakjes geven aan dat het goed kan werken; drie plusjes tussen haakjes geven aan dat het heel goed werkt in combinatie met Java en/of JavaScript; één min tussen haakjes geeft aan dat het slecht werkt bij het inhangen van video en/of audio. De beoordelingen van de instrumenten zijn in tabel 6 Inventarisatie8 samengebracht.

    4.4.2 Formatieve evaluatie
    Volgens Swanborn (1999) is een evaluatieonderzoek een praktijkgericht wetenschappelijk onderzoek, bestaande uit advisering over de opzet; begeleiding tijdens de uitvoering en vooral het evalueren van de effecten van een interventie in het maatschappelijk leven. In deze fase zijn de instrumenten geëvalueerd met de hulp van specialisten. Er is besloten om een formatieve evaluatie uit te voeren, in de vorm van één-op-één interviews. ‘Formative evaluation is a checking process during and at the end of the development of instructional materials. It ensures that the instructional materials accomplish what they were intended to accomplish, are effective, and are error-free’ (Leshin, Pollock, Reigeluth, 1992). In dit geval gaat het niet om instructie materiaal, maar om de instrumenten die gebruikt kunnen worden voor het maken van onder andere instructie materialen. Er is gekozen voor een formatieve evaluatie vanwege de mogelijkheid om tijdens het proces verbeteringen en revisies aan te brengen. De formatieve evaluatie is op de instrumenten gericht en is van essentieel belang in dit onderzoek. ‘A formative evaluation focuses on the equipment, on the skills of the users, the place where the tool is to be used’ (Nieveen, 1996). De tabel ‘Inventarisatie’ wil men als startpunt gebruiken voor de evaluatie met de specialisten op het gebied van de verschillende instrumenten.

    4.4.3 Eén-op-één formatieve evaluatie interviews
    Nieveen (1996) stelt voor dat bij het interviewen van experts, deskundigen of specialisten, men verschillende personen kan benaderen om hun mening te geven over het materiaal dat men wil evalueren. Voor deze interviews heeft men een lijst samengesteld van personen die in dit onderzoek als specialisten worden beschouwd voor een bepaald instrument. De specialisten zijn:

    Voor HTML en DHTML is geen specialist benaderd. De over-all specialist heeft zijn mening hierover gegeven.

    Voor de opzet van de één-op-één formatieve evaluatie interviews heeft men de aanwijzingen van Leshin et al (1992) gevolgd om een goed plan op te zetten. Zo vertellen Leshin et al dat voor een succesvolle één-op-één formatieve interview men een volgende stappenplan kan doorlopen, waarbij men eerst minstens drie personen van verschillende vaardigheden selecteert. Dan maakt men de concepten van het eindproduct klaar en men gaat aan tafel zitten met één persoon. Men stelt de vragen terwijl deze persoon het materiaal bekijkt (Leshin, Pollock, Reigeluth, 1992). Voor deze interview zijn de specialisten geselecteerd op basis van hun deskundigheid. De specialisten zijn persoonlijk benaderd en uitgenodigd voor een gesprek. Van de zes geselecteerde specialisten zijn er 5 benaderd voor specifieke talen/tools. De over-all specialist is benaderd om het geheel te beoordelen. De concepten van het eindproduct zijn in dit geval drie sheets van tabellen met de verschillende instrumenten oftewel talen en tools voor open en gesloten systemen. Daar men rekening wil houden met de beschikbare tijd van de specialist heeft men een vragenlijst9 in elkaar gezet die samen met de tabel gebruikt wordt tijdens het interview. Nieveen (1996) adviseert om tijdens het interview gebruik te maken van een interview schema, waarbij men vragen stelt of onderwerpen aansnijdt over bestaande instrumenten. Ter voorbereiding op het gesprek met de specialisten heeft men aparte tabellen gemaakt van de tabel Inventarisatie. Men heeft besloten om aan elke specialist alleen dat gedeelte van de tabel over zijn specialiteit te presenteren, rekening houdend met mogelijke beïnvloeding van de beoordeling van de andere instrumenten. De specialist zal aan het begin van het gesprek in het kort geïnformeerd worden over voorgaande fasen van de opdracht, zodat het interview soepeler kan verlopen. De interviewer maakt notities van de commentaren en aanbevelingen van de specialist voor eventuele revisies. Aan het eind van het gesprek zal de specialist een totaal overzicht van de tabel te zien krijgen, met de mogelijkheid hierop te reageren.

    4.4.3 Resultaten van de één-op-één formatieve evaluatie
    Als laatste stap vergelijkt men de input revisies. Reviseer de materialen op basis van de commentaren van die persoon en evalueer de observaties gemaakt tijdens het gesprek (Leshin, Pollock, Reigeluth, 1992). De commentaren en aanbevelingen van de specialisten zijn genoteerd en bestudeerd. De aanbevolen beoordelingen zijn opgenomen in de tabel 5: Validatie op pagina 40. In deze tabel zijn de beoordelingen van de inventarisatie naast die van de specialisten geplaatst. Op deze manier is er een duidelijk overzicht van de overeenkomsten en verschillen in de beoordeling aan de ene kant vanuit de literatuur en in samenwerking met dhr. Min en aan de andere kant vanuit de specialisten.

    De specialisten In dit onderdeel zullen de bevindingen van de specialisten genoteerd worden, met accent op de verschillen met de inventarisatie beoordeling.

  • Wat is het instrument?
  • Wat kan ermee gemaakt worden en hoe goed lukt dat met het instrument?
  • Wat zijn de technische mogelijkheden van het instrument? (voor wat betreft animatie, simulatie, video, interactie en koppeling aan database)
  • Welk uiteindelijk product oftewel resultaat is met dit instrument te bereiken?
  • Wat zijn de eigenschappen en kenmerken van het instrument? (in de zin van snelheid, bruikbaarheid en effectiviteit)
  • Wat is de specialiteit van het instrument?

    Sikken, beschouwd als Java specialist, merkt op dat Java alles kan, maar vooral bekend is geworden door de applets. Tegenwoordig is Java aantrekkelijk voor de integratie met andere systemen en de service site, oftewel de achterkant van de site. Hier wordt de grootste aandacht aan gegeven. Verder heeft Java het voordeel dat er een grote reeks van platform beschikbaar is. Voor wat betreft de tabel met beoordelingen, bij de vraag ‘wat kan je ermee maken?’ vertelt Sikken dat Java ook zowel drill & practice als gewone courseware/tutorial heel goed kan maken. Hij geeft hier drie plusjes voor. Met de technische mogelijkheden is hij het eens met de beoordeling bij animatie en simulatie. Maar bij video en audio zou hij als matig beoordelen, omdat genereren lastiger is. Wat interactie en koppeling aan database betreft vindt hij dat dit heel goed te verwezenlijken is. Sikken kan zich vinden in de beoordelingen in verband met de resultaten. Hij merkt op dat Java goed is voor het maken van bepaalde onderdelen. Een les is wel mogelijk, maar het is te veel werk. Java kan spelletjes maken maar de ‘pure performance’ is van minder kwaliteit. Op de item diversen meent Sikken dat Java voor zowel simpele als complexe omgevingen goed gebruikt kan worden. Voor het onderdeel eigenschappen/kenmerken vindt Sikken het terecht om de snelheid van ontwikkelen als slecht te beoordelen. Een programmeur kan wel snel ontwikkelen in Java. De snelheid van het product zou hij goed willen noemen. Verder vindt hij Java vrij eenvoudig en meerzijdig. Als specialiteit zou hij de achterkant van de webservers noemen en de applicaties. Als slotopmerking vermeldde Sikken dat Java een effectieve tool is maar het kan complex worden. Bij een ontwerper die minder ervaring heeft is het complex.

    Jonker, JavaScript specialist, vertelt dat JavaScript een objectgeoriënteerde taal is die op een simpele manier is geschreven, dus relatief snel toe te passen. Het is goed om buttons aan te sturen en simpele navigatie, maar verder niet. JavaScript is voor specialisten makkelijk mee te werken, het heeft echter een beperking, namelijk het kan niet met grafische objecten werken. Hij is het eens met de beoordelingen bij het onderdeel ‘wat kan je ermee maken?’ Voor wat betreft de technische mogelijkheden merkt Jonker op dat JavaScript noch animaties noch simulaties kan maken. Animaties kunnen er wel in gehangen worden en dan zou hij het als matig beoordelen. Verder kan JavaScript interacteren, maar gericht op pop-up menu’s, berekeningen, datum, vragen. Hij zou hier met goed beoordelen. De koppeling aan database vindt hij matig. De resultaten zou hij anders beoordelen, namelijk matig voor les; bij toets slecht en goed om in te hangen; en slecht in spel. Bij item diversen merkt hij nadrukkelijk op dat JavaScript absoluut niet goed is voor games. Bi het onderdeel eigenschappen en kenmerken is Jonker het eens dat de snelheid voor het ontwikkelen slecht is en ook de snelheid van het eindproduct. De bruikbaarheid vindt hij echter goed. Verder is JavaScript moeilijk en eenzijdig. Als slotopmerking had Jonker het over het doel waarvoor JavaScript gemaakt is, toepasbaar binnen zijn grenzen, is best een breed gebied voor de internetgebruiker.

    Reimerink wordt beschouwd als specialist in AuthorWare, DreamWeaver, Flash MX en Director 5.0. De bevindingen zullen per tool worden opgenomen, beginnend met AuthorWare, vervolgens DreamWeaver, Flash MX en Director 5.0.

    Reimerink noemt AuthorWare een auteurssysteem. Het is volgens hem goed voor het maken van web applicaties. De beoordelingen voor de items game/simulatie; drill & practice; en gewone courseware/tutorial vindt hij terecht. Wat de technische mogelijkheden betreft zou hij matig beoordelen zowel in animatie als simulatie. Hij is het eens met de beoordeling voor video, audio en interactie. Koppeling aan database zou hij als goed beoordelen. De resultaten is hij mee eens in geval van les, toets, presentatie en gewone courseware. Bij spel vindt hij het matig, afhankelijk van de moeilijkheidsgraad van het spel. Hij merkt verder op dat voor presentaties betere en goedkopere instrumenten beschikbaar zijn, als voorbeeld noemt hij PowerPoint. Bij de eigenschappen en kenmerken zou hij de snelheid van ontwikkelen, de snelheid van het eindproduct, de bruikbaarheid van het product en de effectiviteit voor het ontwikkelen met goed beoordelen. Bij de item moeilijkheid is hij van mening dat AuthorWare een lage drempel heeft.

    Wat kan je met DreamWeaver maken? Reimerink is het eens dat DreamWeaver goed is voor het maken van websites. Hij vindt het slecht voor het maken van game/simulatie en goed om die in te hangen. Met de beoordeling voor drill & practice en gewone courseware/tutorial is hij het eens. Bij de technische mogelijkheden is hij het eens met de beoordeling voor wat betreft animatie en simulatie, maar voor zowel video als audio zou hij deze als slecht beoordelen met goede mogelijkheid om in te hangen. Slecht, omdat het tijdrovend is via het Web. De koppeling aan database zou hij als goed beoordelen. Hij is het eens bij de resultaten in geval van les en toets. Maar spel beoordeelt hij met slecht en matig om in te hangen; presentatie met matig en goed om in te hangen; en gewone courseware met goed en heel goed in te hangen. Bij item diversen zou hij toevoegen dat DreamWeaver goed is voor verwerking van zowel statische als dynamische informatie. Verder is hij het met het de gegevens van de tabel eens. Als slotopmerking zegt Reimerink dat het grote verschil tussen AuthorWare en DreamWeaver is dat er een browser nodig is om de files van DreamWeaver af te spelen, terwijl bij AuthorWare een extra plug-in nodig is.

    Reimerink vertelt over Fusion dat het een concurrent is van DreamWeaver. Hij is het eens dat het een editor is, een auteurssysteem, een opmaakprogramma en je kan er websites mee maken. De items game/simulatie zou hij met slecht en goed in te hangen beoordelen; drill & practice met matig; en gewone courseware/tutorial met goed. Bij de technische mogelijkheden zou hij animatie, simulatie, video en audio als slecht en matig in te hangen beoordelen. Met de beoordeling van interactie en koppeling aan database is hij het eens. De resultaten les, toets en spel zou hij beoordelen als slecht en matig in te hangen. Presentatie vindt hij goed, en gewone courseware matig. De eigenschappen en kenmerken beoordeelt hij met goed in geval van de snelheid van ontwikkelen, de snelheid van het eindproduct, de bruikbaarheid van het product en de effectiviteit voor het ontwikkelen. Hij is het eens dat Fusion makkelijk en eenzijdig is. Tot slot merkt hij op dat zowel DreamWeaver als Fusion voor web-based producten altijd een browser nodig hebben.

    Reimerink is het eens dat Flash (nieuwe versie) een opmaakprogramma is en een multimedia tool. Het kan intelligente website objecten maken. Voor de beoordeling van game/simulatie zou Reimerink matig geven. Drill & practice zou hij met goed beoordelen en gewone courseware/tutorial ook met goed. Bij de technische mogelijkheden zou hij animatie als goed beoordelen en simulatie als matig. Video en audio geeft hij de beoordeling slecht geven met goed in te hangen. Zowel interactie als koppeling aan database beoordeelt hij als goed. De resultaten les, toets, spel, presentatie en gewone courseware geeft hij goed als beoordeling. Hij is het eens met de item diversen. Bij de eigenschappen en kenmerken zou hij de snelheid van ontwikkelen, de snelheid van het eindproduct, de bruikbaarheid van het product en de effectiviteit voor het ontwikkelen met goed beoordelen. Bij de item moeilijkheid en eenzijdig is hij het eens. De specialiteit klopt.

    Voor de beschrijving van wat Director is en wat het kan maken kan Reimerink zich in vinden. Game/simulatie geeft hij de beoordeling matig. Drill & practice en gewone courseware/tutorial vindt hij goed. Bij de technische mogelijkheden vindt hij animatie en simulatie matig. De items video en audio beoordeelt hij als slecht en goed in te hangen. Interactie en koppeling aan database beoordeelt hij als goed. Hij vindt de resultaten goed bij de items les, toets, spel, presentatie en gewone courseware. Diversen is volgens hem goed ingevuld. Bij de eigenschappen en kenmerken beoordeelt hij de snelheid van ontwikkelen met matig. De snelheid van het eindproduct, de bruikbaarheid van het product en de effectiviteit voor het ontwikkelen beoordeelt hij met goed. Hij is het verder eens met de tabel.

    Kommers vertelt dat SGML een tussenstap is tussen opmaaktalen voor visuele effect van documenten zowel op papier als digitaal. SGML wordt nu haast niet meer gebruikt, het is een museumstuk. SGML is historisch van belang, maar meer niet. Toch wordt SGML in stand gehouden door onder andere uitgeverijen, die met zo min mogelijke kosten, opleiding en risico te maken willen hebben. Kommers is het eens met de beoordeling van de meeste vragen in de tabel. Alleen bij de eigenschappen en kenmerken vindt hij dat de item snelheid voor het ontwikkelen en de snelheid van het eindproduct met erg slecht beoordeeld moet worden. De bruikbaarheid is goed, maar alleen voor enkele traditionele uitgeverijen. Wat de effectiviteit betreft vindt hij het vertragend. SGML is verder zeer moeilijk en te veelzijdig. Hij is het eens dat SGML vooral voor het opmaken van documenten is.

    Winnips als specialist van de instrumenten Flash en Director (beiden oude versies), merkt op dat als je weinig tijd hebt om te ontwikkelen, dat je dan Flash moet gebruiken, terwijl Director beter is als je op of voor CD-Rom ontwikkeld. Winnips is het eens dat Flash een tool is, een editor c.q. animatie-editor voor WWW voegt hij er aan toe. Hij is het eens dat je er website objecten mee kan maken. De item game/simulatie zou hij als goed beoordelen. Gewone courseware/tutorial beoordeelt hij met matig. Met de technische mogelijkheden is hij het eens. Bij de resultaten beoordeelt hij presentaties met heel goed, de rest gaat hij mee akkoord. Met de eigenschappen en kenmerken is hij het ook met de beoordeling eens. Hij voegt er aan toe dat de snelheid van het ontwikkelen bij iemand met ervaring heel goed beoordeeld moet worden. De bruikbaarheid is door de programmeertaal die erbij zit makkelijker dan een programmeertaal. Verder vertelt Winnips dat Flash een voordeel heeft, namelijk dat het vector-based graphics is, waardoor het weinig ruimte nodig heeft en er dus weinig tijd nodig is voor het downloaden. Met Flash zijn er simpele animaties en interacties mogelijk.

    Director is qua tool mooier dan Flash. Director is met Flash te vergelijken, alleen heeft Director pixel based graphics, wat meer ruimte in beslag neemt. Verder is Director gericht op CD-Rom. Wat betreft het onderdeel wat kan je er mee maken? Is Winnips het eens met de beoordeling in de tabel. Alleen denkt hij dat alles afhankelijk is van de factor tijd. Met de technische mogelijkheden gaat hij akkoord, alleen de item interactie beoordeelt hij als heel goed en de koppeling aan database met goed. Verder vindt hij dat Director complexer is in animaties vergeleken bij Flash. De resultaten beoordeelt hij net als in de tabel, alleen de item presentatie wil hij veranderen in heel goed. Bij de eigenschappen en kenmerken beoordeelt hij de snelheid van het ontwikkelen met heel goed, en de snelheid van het eindproduct met goed. Hij vindt Director redelijk makkelijk en eenzijdig. Bij specialiteit zou hij toevoegen aan professionele animaties voor CD-Rom producten. Als laatste opmerking vertelt Winnips dat de interactie bij Director meer mogelijkheden biedt dan bij Flash. Flash heeft minder mogelijkheden voor spel.

    De bevindingen van alle specialisten in is tabel Validatie samengebracht met de inventarisatie van de eigenschappen en kenmerken van de instrumenten.

    Tabel 5:
    5.1. Talen: zoals HTML, XML, etc.
    5.2. Gesloten tools: zoals Fusion, ....
    5.3. Zowel open als gesloten tools, zoals ...

    Zie elders.

    Samenvattend kan men het volgende opmerken over de talen:

    4.5 Conclusie
    Duidelijkheid lijkt een moeilijk te bereiken doel. Niet alleen termen worden verschillend gebruikt en geïnterpreteerd, maar ook talen en tools worden verschillend gebruikt. Het is sterk afhankelijk van de persoon die de taal of tool hanteert, hoe hij de beoordeling van het instrument invult. De specialisten zijn meestal ook alleen op een afgebakend terrein bezig en hebben geen overzicht van het totale beeld. Men blijft ook vaak in eigen specialisme steken en/of hangen. Dit maakt het vergelijkend onderzoeken moeilijk. Daarnaast is er een wedstrijd gaande tussen de vele multimedia bedrijven die steeds weer nieuwe of vernieuwde instrumenten op de markt brengen. Uit dit onderzoek blijkt dat een vernieuwde versie van een instrument niet noodzakelijkerwijs beter is. Een belangrijk punt is ook dat de gebruikers van de instrumenten het vaak niet voor het zeggen hebben bij het kiezen voor een instrument. Met de gebruiker refereert men hier naar de ontwerpers en ontwikkelaars. Die zijn vaak in dienst van een bedrijf of universiteit. De keuze voor een bepaald instrument hoeft niet altijd te vallen op de beste. Factoren die hierbij een rol spelen zijn budget en tijd.

    Hoofdstuk 5: Het veld

    5.1 Inleiding
    Hoofdstuk vijf beschrijft fase vier van het onderzoek naar methoden en technieken voor het realiseren van leeromgevingen. In deze fase is er een enquête11 opgesteld. Een enquête is een onderzoek door ondervraging van een groep personen naar bestaande meningen, gewoonten, enz. (Bookman, 1999). Men heeft voor een enquête gekozen omdat men in een enquête meer informatie kan verkrijgen en men kan op een relatief goedkope wijze veel deelnemers benaderen.

    5.2 Enquêtes voor ontwerpers en ontwikkelaars De enquête is samengesteld uit de gegevens die uit het literatuuronderzoek en expert interviews zijn verkregen. Men richt zich op ontwerpers en ontwikkelaars van software architecturen en leeromgevingen. Daar er nog steeds onduidelijkheid bestaat in verband met de termen ontwerper en ontwikkelaar, wordt de term ontwerper nogmaals erbij gehaald. Men gaat ervan uit dat de ontwerpers en ontwikkelaars betrouwbare informatie kunnen verschaffen.

    5.2.1 De methode
    Via de enquête wil men de mening van de ontwerpers en ontwikkelaars peilen voor wat betreft bepaalde termen die er gebruikt worden in het veld bij het maken van software architectuur c.q. leeromgeving. ‘By asking experts to fill in a questionnaire, you can gather information about their opinions and ideas about the material’ (Nieveen, 1996). 5.2.2 Het doel
    Het doel van deze enquête is een aanzet geven tot begripsverduidelijking. Men verwacht dat met de resultaten van deze enquête de begrippenlijst die in fase twee is opgesteld, uitgebreid kan worden. Verder verwacht men een peiling onder de ontwerpers en ontwikkelaars van de gebruikte methoden en technieken, of tools.

    5.2.3 De respondenten
    De respondenten zijn ontwerpers en ontwikkelaars van software architecturen c.q. leeromgevingen. De respondenten zijn geselecteerd aan de hand van hun werkveld.

    5.2.4 De procedure
    De deelnemers aan de enquête zijn via de post benaderd. Zij hebben een enquête formulier opgestuurd gekregen met de vraag tot deelname aan het onderzoek. Bij de enquêteformulieren is een begeleidende brief met informatie over het waarom van het onderzoek, het doel ervan en uitleg over het invullen van de formulieren. Een retour envelop is bij de formulieren toegevoegd, om terugzending van de enquête te vergemakkelijken. De enquête bestaat uit een questionnaire12. Het onderzoek heeft in de maanden oktober-november 2002 plaatsgevonden. Na verzameling van de informatie verkregen door de ingevulde questionnaires, wordt de data verwerkt en bestudeerd. Verkregen data zal voor de aanvulling van de begrippenlijst gebruikt worden.

    5.2.5 De instrumenten
    De enquête bestaat uit een questionnaire onderverdeeld in zeven categorieën bestaande uit 17 vragen met aan te kruisen antwoorden, in de vorm van 5-puntenschaal. De questionnaire is samengesteld aan de hand van de verkregen data uit de expert interviews, die in de tweede fase van het onderzoek heeft plaatsgevonden. In totaal zijn er 27 questionnaires uitgestuurd, waarvan 9 terug zijn ontvangen. De verkregen data heeft men in de vorm van een tabel13 samengevat.

    5.2.6 De resultaten
    Van de 27 enquêtes die uitgestuurd zijn hebben wij 9 terugontvangen. Vier personen hebben via een e-mail aangegeven dat zij niet aan enquêtes meedoen. De ingevulde questionnaires vormt ? deel van het totaal verstuurde enquêtes en dus niet genoeg om een valide conclusie te trekken. Men wil daarom de verkregen data als aandachtspunten noteren.

    Algemeen
    Van de negen ontvangen enquêtes zijn er twee anoniem ingeleverd. Men houdt de identiteit van de deelnemers geheim. Van de negen noemen drie zich ontwikkelaar, twee ontwerper en vier noemen zich zowel ontwikkelaar als ontwerper. Vijf deelnemers werken liever in open systemen, twee in gesloten systemen, één in allebei en één heeft hier geen antwoord gegeven. Er is één respondent die alleen algemene software maakt, vier maken educatieve software en vier maken zowel algemene als educatieve software.

    Definities
    Op de vraag wat een open software architectuur betekent heeft het merendeel voor de twee volgende definities gekozen:

  • 1. een systeem dat kan evolueren
  • 2. een architectuur met uitbreidingsmogelijkheden.

    De omschrijvingen die het minst kloppen zijn volgens de respondenten: Dat er implementatie binnen een bedrijf mogelijk is, maar dat de protocollen niet echt open zijn; een systeem die de vrijheid geeft om alles te doen; een systeem waar verschillende gesloten systemen op in kan werken.

    Een gesloten architectuur is volgens de meerderheid van de respondenten: Een systeem met één requirement en beperkte mogelijkheden om te evolueren. Volgens de meerderheid is de definitie dat de bron niet vrijgegeven is, dus de software moet gekocht worden niet juist.

    De meerderheid staat neutraal tegenover de definitie voor een methode, waarbij een methode wordt beschreven als een probleemoplossend proces, waar requirements worden omgezet naar problemen en problemen naar oplossingen op een systematische manier, totdat het product gerealiseerd wordt. De beschrijving dat een methode een ontwerpaanpak is, bijvoorbeeld een prototype benadering, wordt door de vijf respondenten afgewezen.

    De meerderheid vindt dat een techniek een optie in een tool is, waarbij de tool een methode is. Een techniek is niet kennis om methode op te lossen, en ook niet een tool of een methode fragment.

    Vijf van de deelnemers vinden dat een professionele ontwikkelaar iemand is die kiest voor methoden en technieken die bekend zijn. Vier van de deelnemers kiezen voor de technieken die keer op keer worden herbruikt. De omschrijvingen dat een professionele ontwikkelaar afhankelijk is van de opdrachtgever/klant en dat hij/zij snel moet zijn om een product op de markt te brengen, worden door vier deelnemers als neutraal getoetst. De beschrijving dat een professionele ontwikkelaar kiest voor methoden en technieken op basis van hypes wordt afgewezen door vijf deelnemers.

    Vijf van de deelnemers kiezen voor de omschrijving ‘een wetenschappelijke ontwikkelaar vindt het doel van het onderzoek van belang’. Vier zijn het gedeeltelijk eens met de volgende beschrijvingen: een wetenschappelijke ontwikkelaar is iemand die ontwikkelt ten behoeve van de wetenschap en een wetenschappelijke ontwikkelaar is vernieuwend bezig.

    Methoden en technieken
    Voor wat betreft de methoden en technieken die open en/of gesloten zijn is het volgende genoteerd: De meerderheid vindt dat HTML en DHTML technieken zijn die gesloten zijn; XML is een techniek die open is. SGML wordt door de helft als een techniek en open gezien, en door twee deelnemers als methode en gesloten beschouwd. Java en JavaScript wordt door de meerderheid als een techniek en open gezien. ActionScript wordt als techniek gezien, maar drie deelnemers vinden het open en drie gesloten. Fusion en AuthorWare worden door drie deelnemers als methode en door drie anderen als techniek gezien. Drie vinden dat Fusion open is, terwijl andere drie het gesloten vinden. AuthorWare wordt door vijf deelnemers als gesloten gezien. Vier respondenten beschouwen Flash als een techniek, terwijl drie het als een methode beschouwen. Vijf respondenten noemen het gesloten. Vier deelnemers vinden DreamWeaver een methode, terwijl drie het een techniek noemen. Vijf deelnemers beschouwen DreamWeaver als gesloten. Director en Toolbox worden allebei door drie deelnemers als een methode, en door drie als techniek gezien, terwijl zes deelnemers vinden dat zij gesloten zijn. De helft van de deelnemers vinden Notepad, Editpad en Textpad methoden, terwijl de andere helft deze als technieken zien. Vier deelnemers vinden Notepad gesloten, terwijl vier het juist open zien. Drie deelnemers vinden zowel Editpad als Textpad gesloten, terwijl drie anderen het open vinden.

    Alle deelnemers op één na gebruiken HMTL. Java en DreamWeaver worden door zes van de deelnemers gebruikt. Flash en Notepad worden door vijf deelnemers gebruikt. XML wordt door vier deelnemers gebruikt. Actionscript, AuthorWare, Editpad en Textpad worden door drie deelnemers gebruikt. DHMTL, JavaScript, Director, Toolbox worden door twee deelnemers gebruikt. SGML wordt door niemand gebruikt.

    De voordelen van software architecturen
    Vijf van de deelnemers zijn het eens dat de voordelen van open software architecturen de mogelijkheid om toe te voegen bieden. Vier deelnemers zijn het er mee eens dat open software architecturen de mogelijkheid tot veranderen bieden; mogelijkheden om te experimenteren en uitbreidingsmogelijkheden. Vier deelnemers zijn het gedeeltelijk mee eens dat open software architecturen vrijgegeven bronnen hebben. Vijf van de deelnemers zijn er het gedeeltelijk mee oneens dat open software architecturen kostenbesparend zijn door evolutie van het product; en dat open software architecturen goedkoper zijn in het ontwikkelen. Vier deelnemers staan neutraal tegenover de uitspraak dat open software architecturen van tevoren mooi te bedenken zijn en dat open software architecturen flexibiliteit bieden in gebruik van methoden en technieken.

    Vier deelnemers zijn het gedeeltelijk eens dat het voordeel van gesloten software architecturen is dat zowel professionals als amateurs het kunnen gebruiken. Vier deelnemers staan neutraal tegenover de uitspraak dat gesloten software architecturen minder tijd vergen in het ontwerpen van producten en dat in gesloten software architecturen minder software nodig is voor het ontwikkelen van producten.

    De nadelen van software architecturen
    Vijf deelnemers staan neutraal tegenover de uitspraak dat een nadeel bij open software architecturen is dat een systeem traag kan worden; en doordat de bron is vrijgegeven iedereen erin kan (zowel gewenst als ongewenst). Vier deelnemers staan neutraal tegenover de uitspraak dat bij open software architecturen het ontwerpen meer tijd vergt en dat open architecturen complex zijn voor het ontwerpen.

    Vier deelnemers vinden dat de nadelen van gesloten software architecturen zijn dat er meer vaststaat. Vijf deelnemers staan neutraal tegenover de uitspraak dat een nadeel bij gesloten software architecturen is dat er niet telkens geïmplementeerd kan worden; dat er starheid is in de manier van werken; dat de producten gekocht moeten worden. Vier deelnemers staan neutraal tegenover de uitspraak dat bij gesloten software architecturen het product niet stopgezet kan worden en dat maakt het ontwerpen moeilijker; complex zijn voor het ontwerpen; de toekomst van het product moeilijk in te schatten is; voor het analyseren extra tijd nodig is.

    Stellingen Voor wat betreft de lijst met stellingen hebben zeven van de deelnemers van de enquête duidelijk laten merken dat zij het oneens zijn met de stelling ‘professionals kunnen bij gesloten producten toch inbreken’. Vijf deelnemers zijn het gedeeltelijk eens met de stellingen ‘methoden en technieken moeten goed gedocumenteerd zijn’; ‘de uitwisselbaarheid in de praktijk is een leuk idee, maar het functioneert niet altijd’; ‘een ideale situatie in het ontwerpen is een situatie waarin het doel is leuke dingen doen tegen betaling.’ Vier deelnemers zijn het gedeeltelijk eens met de stellingen: ‘uiteindelijk is het de baas die de keuzes maakt’; ‘een ideale situatie zou zijn dat er meer aan de grootschalige kant gewerkt wordt, bijvoorbeeld courseware engineering met vaste methoden, vaste handelingen en bepaalde technieken.’

    Tabel 6: Samengevatte resultaten van de enquête

    Cijfers geven aantal mensen aan die voor een bepaald item gekozen hebben. Een - geeft aan dat item niet gekozen is. Vetgedrukte cijfers steken het meest uit.

    5.4 Conclusie
    Zoals in de inleiding van dit hoofdstuk al is aangegeven zijn er niet genoeg enquêtes ingevuld om geldige conclusies te trekken. De punten genoteerd onder de paragraaf resultaten bevelen wij aan als aandachtspunten voor een eventueel vervolgonderzoek. We kunnen echter wel stellen dat bijna iedereen talen en tools als methoden voor het ontwikkelen van omgevingen zien.

    Hoofdstuk 6: Conclusies en aanbevelingen

    6.1 Inleiding
    In dit hoofdstuk worden er conclusies getrokken en aanbevelingen gegeven over de uitgevoerde onderzoeken, de onderzochte termen, de kenmerken en het gebruik van de instrumenten. Het hoofdstuk is onderverdeeld in empirisch onderzoek, terminologie, de kenmerken van de instrumenten en het gebruik van de instrumenten.

    6.2 Empirisch onderzoek
    Deze afstudeeropdracht omvat verschillende onderzoeken, namelijk een literatuuronderzoek, een onderzoek onder de experts (expert interviews), een instrumentenonderzoek en een onderzoek in het veld (enquête). Deze onderzoeken hebben in de periode vanaf juni tot en met december 2002 plaatsgevonden. Het afstudeerverslag geeft een duidelijke beschrijving van deze onderzoeken. De conclusie is dat een empirisch onderzoek naar methoden en technieken voor het realiseren van leeromgevingen is uitgevoerd met als resultaat een duidelijke beschrijving van het proces.

    6.3 Terminologie
    Het probleem in deze opdracht, zoals in hoofdstuk één beschreven, geeft aan dat er geen duidelijkheid bestaat over het gebruik van bepaalde termen binnen het realiseren van omgevingen en leeromgevingen in het bijzonder. Duidelijkheid lijkt een moeilijk te bereiken doel. Wij hebben getracht om aan de hand van een literatuuronderzoek duidelijkheid te krijgen in termen die gebruikt worden voor het maken van omgevingen. De resultaten van dit onderzoek hebben geleid tot een definitielijst van termen die voor dit onderzoek als kernwoorden gekozen zijn. De definitielijst moet echter niet gezien worden als een vaststaande lijst, daar de wereld van software architecturen constant aan het veranderen is, in evolutie verkeert. De lijst kan altijd uitgebreid worden. Verder geeft deze definitielijst aan dat er verschillende definities bestaan van de onderzochte kernwoorden. En toch zijn er velen die met hetzelfde probleem van onduidelijkheid kampen als wij. De term software architectuur bijvoorbeeld wordt niet door iedereen herkend. De ene gebruikt de term software architecturen, de andere heeft het over software systemen, en weer een andere gebruikt de term omgevingen, terwijl zij allemaal hetzelfde bedoelen. Het komen tot standaardisering van termen zou misschien onduidelijkheid uit de weg kunnen ruimen. Waarschijnlijk niet voor altijd, gezien de snelle evolutie. Aan de hand van expert interviews zijn de termen in deze opdracht verder onderzocht. Dit heeft geleid tot het formuleren van een begrippenlijst. Net als de definitielijst moet deze begrippenlijst niet als een vaststaande lijst worden beschouwd, maar een lijst die aangevuld kan worden door andere experts op het gebied van software engineering. Deze lijst wil een aanzet geven voor het inventariseren van begrippen die gehanteerd worden in het maken van software en omgevingen om te komen tot begripsvorming. In de beschrijvingen kan men overeenkomsten vinden met vaak een klein detail dat net een verschil inbrengt. Volgens de literatuur heeft het te maken met de vooropleiding die iemand heeft gehad welke definities hij/zij hanteert. Het bedrijf waar iemand werkzaam is heeft ook invloed hierop. Het verschil in gebruik van termen zit ook in de expertise van de deskundige. Zo heeft een software engineer het eerder over software architecturen, terwijl een informaticus het over applicatie heeft. Een onderwijskundige aan de andere kant heeft het eerder over een leeromgeving. In de expert interviews zijn de verschillen duidelijk te merken. Min is bijvoorbeeld iemand die zich tot doel stelt moeilijke termen tot de kern van de zaak terug te brengen. Zo vindt hij TeleTOP een editor; een instrument vindt hij een methode; en een tool of een taal vindt hij een methode voor het realiseren van een product. Terwijl de Vries beschrijvingen voor termen heeft die verschillend interpreteerbaar blijven. De begrippenlijst geeft een indruk van begrippen, maar het is niet compleet. Er zijn meer experts op het gebied van maken van leeromgevingen, die hun meningen hierover zouden kunnen geven. Daar deze opdracht in een afgebakende periode heeft plaatsgevonden, was het niet haalbaar om meer experts te interviewen.

    6.4 De kenmerken van de instrumenten
    Tijdens het instrumentenonderzoek zijn de eigenschappen en kenmerken van de instrumenten bekeken, met als doel een waardering van de karakteristieken van die instrumenten. Het is echter sterk afhankelijk van de persoon die de taal of tools hanteert, hoe hij de beoordeling van het instrument invult. De specialisten van bepaalde instrumenten zijn vaak bezig op een eigen gebied en met een specifieke taal of tool. Dit is aan de ene kant positief in de zin dat die specialist deskundig is voor wat betreft dat bepaald instrument. Aan de andere kant verliest die specialist weer het geheel van aanbod aan instrumenten uit beeld. Door gebrek aan tijd en geld worden specialisten vaak gebonden aan een speciaal instrument. De instrumenten die zijn onderzocht, zijn door de experts aangegeven. Niet alle instrumenten zijn onderzocht, er zijn veel meer instrumenten op de markt. De onderzochte instrumenten zijn niet altijd de beste voor het maken van een bepaalde omgeving, of voor het maken van elementen en/of objecten voor die bepaalde omgeving. Zij worden echter gebruikt omdat het bedrijf dat zo besloten heeft, of omdat de ontwikkelaar vaardig is met dat bepaalde instrument, of omdat het goedkoper is, enz. Er is geen all-around instrument die voor alles gebruikt kan worden, voor bijvoorbeeld zowel animaties, simulaties, toetsen, courseware, etc. Een instrument die makkelijk te hanteren is, snel werkt en goedkoop is. De situatie nu is dat er in combinatie gewerkt wordt. Een auteurstaal in combinatie met een opmaaktaal, in combinatie met één of meerdere tools. Of een tool die een eigen scripttaal heeft en een auteurstaal achter de schermen heeft zitten. Wij komen tot de conclusie dat HTML in elke leeromgeving op het web een belangrijke rol speelt. Maar omdat HTML geen rekenen en tekenen ondersteunt, is de scripttaal JavaScript zo belangrijk. Maar ook JavaScript kent beperkingen. Het kan bijvoorbeeld niet goed omgaan met tekenen en dus niet met dynamische visualisaties, animaties en simulaties. Daarom is Java voor educatieve toepassingen zo belangrijk geworden. Maar ook Flash en DHTML spelen in meer of mindere mate, en meestal als alternatief voor Java, een grote rol. De keuze voor Flash, Java of DHTML wordt bepaald door de kosten, de tijd en hoe de rest van de software is opgebouwd.

    6.5 Het gebruik van de instrumenten
    Het onderzoek in het veld heeft weinig response gegeven, waardoor er geen geldige conclusies getrokken kan worden. De resultaten geven echter wel weer dat de meerderheid van de respondenten talen en tools als methoden zien en gebruiken voor het ontwikkelen van omgevingen. Net zoals de termen worden ook talen en tools verschillend gebruikt en geïnterpreteerd. De persoon die een instrument gebruikt is weer afhankelijk van waar hij werkt, voor wie hij werkt en wat het eindresultaat moet zijn. Een ontwerper houdt zich eerder bezig met het ontwerpen van een idee, een plan. Hiervoor gebruikt hij/zij instrumenten die door het bedrijf gebruikt worden, of waar hij/zij vaardiger in is. Gaat het echter om iemand die op de universiteit bezig is met een bepaald onderzoek is de mogelijkheid groot dat die persoon gaat experimenteren met nieuwe instrumenten.

    6.6 Eindconclusie
    Het ontwerpen van plannen, het ontwikkelen van instrumenten, het produceren van steeds meer producten maakt het niet makkelijker voor degenen die een houvast zoeken in vastgestelde definities en beschrijvingen. Elke ontwerper wil zijn/haar eigen termen gebruiken om de uniekheid ervan te bewijzen en conserveren. Er zijn vele multimedia bedrijven die steeds weer nieuwe of vernieuwde instrumenten produceren. Uit dit onderzoek blijkt dat een nieuwe instrument of een vernieuwde versie van een instrument niet noodzakelijkerwijs beter is dan wat er momenteel in gebruik is. De probleemstelling “Welke methoden en technieken leiden tot open en welke tot gesloten software architecturen?” is onderzocht en de conclusie die hier getrokken kan worden is dat daar er geen duidelijkheid bestaat over de termen methoden en technieken, kan deze vraag niet geheel beantwoordt worden. Ook het verschil tussen open en gesloten wordt nog in discussie gesteld. Men gebruikt methoden en technieken en tools voor wat wij in deze opdracht instrumenten hebben genoemd. Duidelijkheid is er echter niet. De werkhypothese “Alle web-based producten kunnen in principe worden gemaakt met HTML, Java of JavaScript”, wordt niet helemaal gehandhaafd, omdat er tegenwoordig veel meer instrumenten op de markt zijn die sneller, goedkoper en soms zelfs makkelijker zijn in gebruik. Maar lang niet altijd beter en betrouwbaarder volgens Min.

    Referenties

    Anker, G. van den, Graaf, R. de & Poppink, B. (2000). Wat u ziet is vaak wat u krijgt! Computer! Totaal. (4)

    Barbacci, M.(1998). Are Software Architects Like Building Architects? SEI Interactive 9 Available online: http://www.sei.cmu.edu/interactive/Columns/The_Architect/1998/September/Architect.sept98.htm http://interactive.sei.cmu.edu/news@sei/columns/the_architect/1998/September/architect-sep98.pdf

    Barker, J. & Tucker, R.N. (1990). The Interactive Learning Revolutions; Multimedia in Education and Training. Kogan page Ltd., London, England.

    Bookman (1999). Het Complete Nederlandse Woordenboek. Nieuwe officiële spelling. Hermans Muntinga Publishing, Amsterdam/Hoorn, Nederland.

    Bredemeyer,D. (2002). Definitions of Software Architecture. Available online: http://www.bredemeyer.com/definiti.htm

    Bredemeyer Consulting (2002). What is Software Architecture? Available online: http://www.bredemeyer.com/whatis.htm

    Bredemeyer, D. & Malan, R. (1999). Role of the Software Architect. Available online: http://www.bredemeyer.com/role.pdf

    Carnegie Mellon University (2002). Software Architecture and the Architecture Tradeoff Analysis Initiative. The Software Engineering Institute. Available online: http://www.sei.cmu.edu/ata/ata_init.html

    Eckstein, R. (2000). XML. Kort en krachtig. O’Reilly & Associates, Inc. Academic Service, Schoonhoven, Nederland.

    England, E. and Finny, A. (1999). Managing Multimedia; Project Management for Interactive Media. Addison Wesley, Pearson Education Limited. Edinburgh, England.

    Garland, D. & Perry, D. (1995). Software Architecture. IEEE Transactions on software Engineering. (4)

    Hillenius, G. (2002). Java Knoopt eindjes aan elkaar. Computable (4). Available online: www.computable.nl

    Internet Related Technologies (2002). Java Applets in Education. Available online: http://tech.irt.org/articles/js151/

    ISO (1986). Information processing – Text and office systems – Standard Generalized Markup Language (SGML). International Organization for Standardization, ISO 8879

    Jazayeri, M., Ran, A. & Linden, F. van der (2000). Software architecture for Product Families: Principles and Practice. Available online: http://www.sei.cmu.edu/ata/ata_init.html

    Kamperbeek, J. (1997). Basishandleiding JavaScript. De mooiste web-pagina’s in 20 minuten! JAVASCRIPT. Bijleveld Press, Utrecht, Nederland.

    Kamperbeek, J. (1998). Basishandleiding HTML & Internet. Maak je eigen web-pagina in 20 minuten! HTML.Bijleveld Press, Utrecht, Nederland.

    Kramer, N.J.T.A. & de Smit, J. (1991). Systeemdenken. Stenfert Kroese Uitgevers. Leiden/Antwerpen, Nederland/België.

    Kruchten, P., Booch, G. & Reitman, R. (1998). The Rational Unified Process. An Introduction. Addison-Wessley-Longman, Cambridge, United Kingdom.

    Leshin, C.B., Pollock, J., Reigeluth, C.M. (1992). Instructional Design Strategies and Tactics New Jersey, U.S.A.: Educational Technology Publications, Inc.

    Macromedia (1993). AuthorWare Working Model. The Premier Authoring Tool for Interactive Learning. Macromedia, Inc., California, U.S.A.

    Macworld (1996). The anatomy of authoring I. Importing and managing media. Macworld MW LAB, August 1996.

    Mendelsohn, P. (1996). Mapping Models of Cognitive Development to Design Principles of Learning Environments. Lawrence Erlbaum Associates, Inc. Publishers. New Jersey, U.S.A.

    Min, F.B.M., (1987). Computersimlatie als leermiddel; een inleiding in methoden en technieken. Academic Service B.V., Schoonhoven, Nederland

    Min, F.B.M. (1996). Simulation Technology and Parallellism in Learning Environment. Academic Book Center. De Lier, Nederland

    Min, F.B.M. (2000). Multimediale leermiddelen; methoden en technieken in relatie tot effectieve en efficiente leer-, werk- en doe-omgevingen (en met name onderzocht en beproeft bij computersimulatie). Universiteit Twente, Enschede; Nederland. Available online: http://projects.edte.utwente.nl/boekNL/index.html

    Min, F.B.M., (2002). Multimediale leermiddelen; het ontwerpen en ontwikkelen van leer-, werk- & doe-omgevingen. Inzichten, Concepten, Methoden en Technieken; interactief, dynamisch boek op internet. Universiteit Twente, Enschede, Nederland. Available online: http://projects.edte.utwente.nl/pi/Teksten/OntwerpenMMOP.html

    Mudry, R.J. (1998). The DHTML companion. Where is DHTML headed? Plan for the next steps in Web page interactivity. Prentice-Hall, Inc. New Jersey, U.S.A.

    NetObjects, INC., (1998). NetObjects Fusion. Building Business Web sites. California, U.S.A.

    Nieveen, N. (1996). Cascade (Computer Software). Enschede: Universiteit Twente.

    Nijhof, W.J., Franssen, H.A.M., Hoeben, W.Th.J.G., Wolbert, R.G.M. (1995). Handboek Curriculum: Modellen, Theorieën, Technologieën. Den Haag, Nederland: Swets & Zeitlinger bv.

    Plomp, T.J., Feteris, A., Pieters, J.M. & Tomic, W. (1992). Ontwerpen van onderwijs en trainingen. Utrecht, Nederland: Uitgeverij LEMMA B.V. Romiszowski, A.J. (1981). Designing Instructional Systems; Decision making in course planning and curriculum design. Londen, Engeland: Kogan Page/New York, USA: Nichols Publishing.

    Salomon, G. (1991). Studying Novel Learning Environments as Patterns of Change.

    Stonehouse (1990). MacroMind Director 2.0. Stonehouse nieuws (3)

    Sudipto, G., Jagadish, H.V., Koudas, N., Srivastava, D., Yu, T. (2002). Approximate XML Joins. ACM SIGMOD '2002 June 4­6, Madison,Wisconsin, USA.

    Swanborn, P.G. (1999). Evalueren. Uitgeverij Boom, Amsterdam, Nederland.

    Tappel, M. (2000). DreamWeaver. Available online: http://www.Dreamweaver/Dreamweaver_main.htm

    Tappel, M. (2000). Flash. Available online: http://www. Flash/Flash_main.htm

    Van Dale, (1999). Van Dale Goot Woordenboek der Nederlandse Taal. Van Dale Lexigrafie B.V. Utrecht/Antwerpen, Nederland/België.

    Webster (1986). Webster’s Third New International Dictionary. Merriam-Webster Inc. Publishers, Massachusetts, U.S.A. Webster Dictionary Available online: http://www.m-w.com/

    Wilson, B. G. (1995). Metaphors for instruction: Why we talk about learning environments. Educational Technology, 35 (5), 25-30. Available online: http://www.cudenver.edu/~bwilson

    Geraadpleegde Literatuur

    Alessi, S.M. & Trollip, S.R. (2001). Multimedia for learning. Methods and Development. Paerson Education Company, U.S.A.

    Aurum, A., Petersson, H. & Wohlin, C, (2002). State-of-the-art: software inspections after 25 years. Software Testing, Verification and Reliability (in press).

    Barker, P. (1987). Author Languages for CAL. Macmillan Education LTD,, London, ENGLAND.

    Bredemeyer Consulting (2001). How: The Software Architecting Process. Available online: http://www.bredemeyer.com/howto.htm

    Bredemeyer Consulting (2001). The role of the Software Architect. Available online: http://www.bredemeyer.com/who.htm

    Bredemeyer Consulting (2001). Why Create Software Architectures. Available online: http://www.bredemeyer.com/why.htm

    Bredemeyer, D. (2001). Software Architecture in Context. Available online: http://www.bredemeyer.com/where.htm

    Bredemeyer, D. & Malan, R. (2001). Defining Non-Functional Requirements. Available online: http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF

    Carnegie Mellon Software Engineering Institute (2002). How Do You Define Software Architecture? Available online: http://www.sei.cmu.edu/architecture/definitions.html

    Dix, A., Finlay, J., Abowd, G. & Beale, R. (1998). Human-computer interaction. Pearson Education Ltd., Essex, England.

    Dool, P.C. van den, Merrienboer, J.J.G. van, Oel, G.J. van, Schie, J.P. van, Simons, R.P.J. (2000). Op zoek naar kristallisatie van ICT in het Onderwijs. Voorstel voor accenten in researchprogramma’s en kennismanagement. Available online: http://www.observetory.com/PROO-trendanalyse/site/reviewtekst-v5.htm

    Dool, P.C. van den, Merrienboer, J.J.G. van, Oel, G.J. van, Schie, J.P. van, Simons, R.P.J. (2000). Op zoek naar een digitale didactische gereedschapskist. Spannende toepassingen van ICT als een cognitief hulpmiddel in leren en onderwijzen. Reviewstudie in opdrachte van NWO/PROO  

    Editorial (2002). Formal methods and testing. Software Testing, Verification and Reliability 12, pp. 69-70

    Ibrahim, B. & Franklin, S.D. (1995). WWW'95: Advanced Educational Uses of the World-Wide. Available online: http://www.igd.fhg.de/archive/1995_www95/papers/89/paper.html

    Joosten, S. & Ferreira Pires, L. (2002). Tools en technieken. Maandblad voor de informatievoorziening: Informatie 44: pp. 28-31

    Horst zur, A., Böse, J. & Voß , S. (2002). General Proceeding to Install Passenger Information Systems in the Supply Area of Public. CASPT

    Kamthan, P. (1999). JAVA applets in education. Available online: http://tech.irt.org/articles/js151/

    Kamthan, P. (1998). Intranets in Education Available online: http://tech.irt.org/articles/js137/

    Kearney, M., Treagust, D.F., Yeo, S. & Zadnik, M.G. (2001). Student and Teacher Perceptions of the Use of Multimedia Supported Predict–Observe–Explain Tasks to Probe Understanding. Research in Science Education 31: pp. 589–615

    Liu, M., Jones, C. & Hemstreet, S. (1998). Interactive Multimedia Design and Production Processes. Journal of Research on Computing in Education 30 (3), pp 254-280.

    Min, F.B.M. (1998). Ontwerpen; in het bijzonder het ontwerpen van multimedia producten. Universiteit Twente, Enschede; Nederland. Available online: http://to-www.edte.utwente.nl/TO/ism/course/pro/ontwerpenMM.htm

    Min, F.B.M. (2001). Wat zijn multimediale leeromgevingen? Available online: http://to-www.edte.utwente.nl/TO/ism/course/pro/Sheets/hc2a.html

    Mishra. A. (2002). Scalability in Communication Networks. IEEE Network, July 2002

    Moll, W. (2002). Nationale E-learning Congres, 25 – 26 februari 2002. Available online: http://www.oro.hva.nl/kenniscentrum/leeromgeving/documenten/ lomg_verslag_elearning_feb2002_2.doc

    Monaco, F.J. & Gonzaga, A. (2002). Remote Device Command and Resource Sharing over the Internet: A New Approach Based on a Distributed Layered Architecture. IEEE Transactions on Computers, Vol. 51, No. 7, pp 787-793

    NIPO Interactive (2002). Nederland met internetgebruik in wereldtop. Available online: http://www.nipo.nl/sub_content.asp?id=c001&file=persvannipo\ger2002.htm

    Palmer, J. (2002). Designing for Web Site Usability. IT Systems Perspective, Computer, pp 102-103.

    Passig, D. & Levin, H. (2001). Interaction between Gender, Age, and Multimedia Interface Design. Education and Information Technologies 6:4, pp. 241–250.

    Rijksuniversiteit Groningen (2002). Onderwijskunde: de Specialisaties. Available online: http://www.ppsw.rug.nl/~pedok/tillek/specialisatie.htm

    Sankar, C.S. & Raju, P.K. (2001). Use of Multi-Media Courseware to Teach Real-World Decision Making Skills. Information Technology and Management 2, pp. 443–457

    Stein, S.J., Mcrobbie, M.J. & Ginns, I.S.(2001). Authentic Program Planning in Technology Education. International Journal of Technology and Design Education 11, pp. 239–261

    Stevens, G.H. & Stevens, E.F. (1995). Designing electronic Performances Support Tools. Improving workplace performance with Hypertext, Hypermedia and Multimedia. Educational Technology Publications, New Jersey, U.S.A.

    Strauss, R. (1997). Managing Multimedia Projects. Butterworth-Neinemann, U.S.A.

    Sun Sup So, Sung Deok Cha, Shimeall, T.J. & Yong Rae Kwon (2002). An empirical evaluation of six methods to detect faults in software. Software Testing, Verification and Reliability (in press)

    TeleTOP, Universiteit Twente, available online: http://www.utwente.nl

    Wilson, R.L. & Weiser, M. (2001). Adoption of Asynchronous Learning Tools by Traditional Full-Time Students: A Pilot Study. Information Technology and Management 2, 363–375

    Enschede. In ruwe vorm, vanuit een full text-bestand, op internet gezet door R.M. op 20 dec. 2002.