Study Coach And Learning Environment

Study Coach And Learning Environment for Computer Based Training

Voortgangsrapportage Periode april 2005 t/m juni 2005

Penvoerende instelling: Participerende instellingen:

LUMC, Erasmus MC, UMCU, UMC St Radboud,

Universiteit Leiden Erasmus Universiteit Rotterdam Universiteit van Utrecht Radboud Universiteit Nijmegen

Inhoudsopgave Inhoudsopgave ........................................................................................................................ 2 Samenvatting ........................................................................................................................... 3 Projectdoelstelling................................................................................................................... 3 Voortgang per fase .................................................................................................................. 3 Fase 1 Opstellen leerdoelen boom voor COO materiaal....................................................... 3 Computer Ondersteund Onderwijs classificatie ................................................................................ 4 Technische classificatie .................................................................................................................... 4 Onderwijskundige classificatie .......................................................................................................... 4 Verslag Klankbordgroep.................................................................................................................... 6

Fase 2 Inventariseren en klasseren van COO materiaal....................................................... 6 Fase 3 Functioneel ontwerp studie coach ............................................................................. 6 Fase 4 Technische realisatie studie coach............................................................................ 6 Fase 5 Integratie van LRS.NET met de bestaande ICT infrastructuur .................................. 7 Blackboard® koppeling...................................................................................................................... 7

Fase 6 Inbedding in het onderwijs ......................................................................................... 7 Fase 7 Promotie projectresultaten ......................................................................................... 7 Fase 8 Evaluatie .................................................................................................................... 8 Knelpunten ............................................................................................................................... 8 Standlijnen overzicht............................................................................................................... 9 Kennis disseminatie ................................................................................................................ 9 A-Select dag 25 mei 2005...................................................................................................... 9 SOL Congres Portland Oregon 14-18 juni 2005.................................................................. 11 Kostenoverzicht..................................................................................................................... 12 Declaratie ............................................................................................................................. 14 Bijlagen................................................................................................................................... 15 Bijlage 1: Overzicht onderwijskundige classificaties............................................................ 15 Bijlage 2 Ontwikkelde classificaties ..................................................................................... 23 Bijlage 3 Abstracts SOL congres ......................................................................................... 27 Bijlage 4 Functioneel ontwerp.............................................................................................. 28

2

Samenvatting In het tweede kwartaal is het project voorspoedig voortgezet, voor fase 1 is voor de classificaties gezocht naar een bestaande, bruikbare onderwijskundige classificatie. Uiteindelijk is voor een combinatie van termen uit verschillende classificaties gekozen. In dezelfde fase is een eigen classificatie voor het COO type en de gebruikte techniek ontwikkeld. In fase 3 is begonnen met een uitgebreid functioneel ontwerp dat als basis dient voor de uiteindelijke technische realisatie van de studiecoach. In mei is er een intake review geweest met de projectbegeleider van Surf. Hier zijn de opzet en uitwerking van het project toegelicht en besproken. In het tweede kwartaal zijn er 5 bijeenkomsten geweest van de projectgroep en een bijeenkomst met de klankbordgroep.

Projectdoelstelling Reeds 25 jaar wordt aan de Nederlandse medische universiteiten gebruik gemaakt van Computer Ondersteund Onderwijs (COO). Voor deze onderwijsvorm zijn inmiddels honderden programma’s gemaakt die in het medisch onderwijs (studies geneeskunde en biomedische wetenschappen) ieder hun eigen leerdoel en toepassing hebben. Met COO bedoelen wij in deze, alle denkbare vormen van elektronisch studiemateriaal, variërend van casuïstiek, tutorials, simulaties tot toetsen. Iedere instelling gebruikt hierbij zijn eigen materiaal. Het merendeel hiervan wordt als zelfstudie materiaal aangeboden. Het volgen van dit onderwijs is vaak niet verplicht en wordt niet getoetst. De toegenomen kwaliteit van het COO materiaal, zowel inhoudelijk als technisch, alsook de toegenomen kwantiteit vraagt om een meer structurele plaats in het onderwijs en in de toetsing. Met andere woorden de resultaten van de projecten uit het verleden moeten indalen in de organisatie van het onderwijs. De studies Geneeskunde van de universiteiten in Nederland zijn gebaseerd op het Raamplan 2001. Eén van de belangrijkste uitgangspunten hiervan is het aanleren van de vaardigheden waarmee de arts de gezondheidsproblemen van patiënten kan benaderen en oplossen. Elk COO is bedoeld ter ondersteuning van het aanleren van 1 of meerdere van deze vaardigheden en kunnen omschreven worden als de COO leerdoelen. Binnen het project moet aan de student een eenvoudige en snelle toegang tot (een specifieke selectie van) het COO materiaal geboden worden, waarbij de studie historie van de student in relatie tot de leerdoelen in de tijd automatisch wordt bewaakt. Behalve een longitudinale follow-up van een student over verschillende studiejaren, wordt het hierdoor ook voor de student mogelijk zijn eigen studieprestaties met betrekking tot de verschillende leerdoelen in te zien, voor zover dat gedekt wordt door het aangeboden materiaal. Het systeem zelf kan automatisch studenten van een individueel studieadvies voorzien. De belangrijkste doelstelling van dit project is dus het koppelen van studie-informatie wat betreft het gebruik van COO met de curriculum database en de individuele student. Daarnaast is het belangrijk dat alle deelnemende instellingen de beschikking krijgen over COO materiaal van de zusterfaculteiten. Hoewel in het verleden hier al vaker afspraken over gemaakt zijn (zie bijlage) blijkt het in de praktijk niet altijd eenvoudig om te achterhalen waar welk materiaal zich bevindt en of dit ook geschikt is voor het eigen onderwijs. Door de directe beschikbaarheid van de lessen en de metadata waarin de leerdoelen zijn vastgelegd wordt dit proces vele malen simpeler. Deze ontwikkeling sluit aan op het concept van een LCMS (een Leerobject Content Management Systeem). Verschil hiermee is enerzijds dat de “leerobjecten” bestaan uit grote afgebakende modules en anderzijds dat de te ontwikkelen database slechts de metadata van de lessen bevat en niet de objecten zelf.

Voortgang per fase Fase 1 Opstellen leerdoelen boom voor COO materiaal Fase 1 is afgerond en heeft als resultaat een classificatie opgeleverd waarbinnen 5 onafhankelijke takken worden onderscheiden: curriculum, COO-type, technisch, onderwijskundig en medisch inhoudelijk.

3

Voor het COO-type, de technische en de onderwijskundige takken is door de projectgroep een eigen vocabulaire ontwikkeld, zo veel mogelijk uitgaande van bestaande vocabulaires. Voor het opstellen van de curriculum tak is elk deelnemend instituut zelf verantwoordelijk. Deze classificatie tak dient slechts als instituut afhankelijke aanvulling op de volledige classificatie binnen de andere 4 takken. Voor de medisch inhoudelijke informatie over een les is de MeSH classificatie gekozen. Hierover is in de vorige rapportage reeds gerapporteerd. De informatie over lessen die nodig is voor de zoekmachine en de studiecoach wordt vanaf nu vastgelegd door koppelingen van de les aan de 5 takken van de classificatie en door de metadata die bij de lessen zelf wordt opgeslagen. In deze metadata zijn grofweg 3 verschillende groepen te onderscheiden: algemene-, technische- en contact informatie. Dit resultaat is inmiddels gepresenteerd aan de klankbordgroep.

Computer Ondersteund Onderwijs classificatie Doel van deze classificatie is de beschrijving van de lesvorm van de applicatie. Een onderwijsprogramma kan gekoppeld worden aan meerdere lesvormen, wanneer het een gemengde structuur heeft. Er worden 4 Computer Based Training (CBT) types onderscheiden: 1- Tutorial 2- Simulation 3- Assessment 4- Game De volledige classificatie is in de bijlagen opgenomen.

Technische classificatie De technische classificatie is alleen bedoeld voor onderwijs ontwikkelaars. De classificatie valt in 3 hoofdcategorieën uiteen: 1- Programming Language 2- Operating system 3- Content De volledige classificatie is in de bijlagen opgenomen.

Onderwijskundige classificatie Tijdens een bijeenkomst in Rotterdam is uitgebreid gebrainstormd over een geschikte onderwijskundige classificatie voor computer ondersteund onderwijs. Deze classificatie moet in de praktijk werkbaar en dus niet te uitgebreid zijn, maar toch voldoende onderscheid kunnen maken tussen verschillende typen programma’s. Omdat niet meer expliciet gewerkt wordt met de leerdoelen van de opleiding, is een onderwijskundige classificatie met name van belang om uit de combinatie van een medisch inhoudelijke en een onderwijskundige classificatie het idee van een leerdoelenboom te benaderen. Aanwezig bij de bijeenkomst waren 5 leden van het projectteam en een onderwijskundige van het Erasmus MC. Voorafgaand aan de bijeenkomst is een inventarisatie gemaakt van een aantal onderwijskundige taxonomiëen, Gagné, Bloom, De Block en Romiszowski. Zie hiervoor bijlage 1. Dit overzicht is gebruikt als discussiestuk. De bestaande onderwijskundige taxonomieën zijn erg gedetailleerd en moeilijk te hanteren in de praktijk. Bij het Erasmus MC is met een aantal onderwijskundigen en docenten een poging gewaagd om tentamenvragen te classificeren aan de hand van de taxonomie van Romiszowski. Dit is niet gelukt, doordat de genoemde classificaties te vaag zijn opgesteld en verschillend geïnterpreteerd kunnen worden. Uiteindelijk heeft deze groep ervoor gekozen als enige onderwijskundig label een simpel onderscheid te maken tussen tentamenvragen die basale kennis toetsen en vragen die klinische toepassing toetsen. Voor de onderwijskundige classificatie lijkt een indeling in "kennis" en "toepassing" onvermijdelijk. In de taxonomieën komt deze indeling ook steeds terug, zij het in net wat andere benamingen en uitwerkingen. Besloten is om de tweedeling, op basis van de taxonomie van Romiszowski, op de volgende wijze uit te breiden:

4

1. Kennis verwerven 2. Kennis toepassen 3. Motorische vaardigheden 4. Communicatieve vaardigheden 5. Attitude

} Cognitieve vaardigheden

Voor COO lessen is besloten dat per item steeds aangegeven kan worden hoe sterk het vertegenwoordigd is, door een score op een 4-puntsschaal aan te geven, van 1 (nauwelijks aanwezig) tot 4 (sterk aanwezig). De classificatie bevat weinig termen en op deze wijze kan toch een beter onderscheid gemaakt worden tussen programma’s. Aangezien Romiszowski op hoofdniveau een onderscheid maakt tussen vaardigheden en kennis, is de onderverdeling die wij onder cognitieve vaardigheden gemaakt hebben naar kennis en toepassing niet helemaal in overeenstemming met zijn taxonomie. Wij zijn echter van mening dat het verwerven van kennis in de context van COO-programma wel degelijk gezien kan worden als een cognitieve vaardigheid (immers het verwerven van kennis door de student kan ook als een vaardigheid worden opgevat). De gekozen indeling bevat volgens ons voldoende diepgang om zinvol te gebruiken in het kader van het project en is tegelijkertijd redelijk eenduidig, dus makkelijker voor classificeerders om toe te passen. Raamplan Het Raamplan (Metz JCM, Verbeek-Weel AMM, Huisjes HJ. Raamplan 2001 artsopleiding: bijgestelde eindtermen van de artsopleiding. 2001. Mediagroep Nijmegen) bevat de verplichte eindtermen voor de geneeskunde-opleidingen in Nederland. In de klankbordgroepbijeenkomsten is de wens uitgesproken om de COO-programma’s te classificeren met behulp van dit Raamplan en het eventueel ook onder te brengen in de SCALE classificatie, of in elk geval te proberen een koppeling te maken. Het Raamplan bestaat uit de volgende onderdelen: 1 Algemene Eindtermen 2 Problemenlijst 3 Lijst van vaardigheden 4 Lijst van ziektebeelden De lijsten van vaardigheden en ziektebeelden zijn niet wettelijk verplicht voor de artsopleiding en dienen slechts ter illustratie. Algemene Eindtermen en Problemenlijst zijn wettelijke voorschriften waaraan iedere artsopleiding in Nederland moet voldoen. De Problemenlijst is een opsomming van patiëntklachten geordend in tien disciplines. De lijsten in het Raamplan zijn bestudeerd, waarna we tot de conclusie zijn gekomen dat het Raamplan op zichzelf niet voldoet als classificatie. De Algemene Eindtermen zijn niet heel specifiek gedefinieerd en ook de termen in de Problemenlijst zijn erg ruim opgesteld. Bovendien is het als classificatie zeker niet volledig (zie het verslag in de kwartaalrapportage van april 2005). Wel is nog gekeken naar de mogelijkheid om het Raamplan te koppelen aan classificatie van MeSH, dat als medisch inhoudelijke classificatie wordt gebruikt. Dit stuitte echter op het volgende probleem: de termen in de problemenlijst zijn vooral vanuit het gezichtspunt van een patiënt opgesteld, waarbij klachten centraal staan. De termen zijn vaak algemeen en in spreektaal opgesteld. MeSH is vanuit een wetenschappelijk/medisch gezichtspunt opgesteld. De termen zijn meer wetenschappelijk en veel specifieker. Toekenning is daarom moeilijk voor iemand zonder medische achtergrond. Bovendien kan hetzelfde MeSH-trefwoord op meerdere plaatsen in de boom voorkomen (afhankelijk van de context). Er is bijvoorbeeld een algemene tak ‘Signs and Symptoms’, maar diverse specifieke klachten komen opnieuw terug op andere plekken, gekoppeld aan de anatomie of fysiologie. Op grond van de problemenlijst is vaak niet aan te geven welke context het meest relevant is, waardoor de enige optie is om dan maar alle plaatsen in de boom te koppelen. Tot slot: er is geen één op één relatie tussen klachten en ziekten. Veel klachten zijn enerzijds aspecifiek

5

(kunnen bij meerdere ziekten voorkomen) en anderzijds treden klachten niet bij alle patiënten met de ziekte op. Een directe koppeling tussen MeSH en Raamplan lijkt daarom erg moeilijk. Wel is besloten om vanuit de projectgroep contact te zoeken met de landelijke commissie die het Raamplan opstelt en te overleggen over de wenselijkheid en de mogelijkheden om het Raamplan en MeSH meer met elkaar in overeenstemming te brengen.

Verslag Klankbordgroep De klankbordgroep voor het SCALE project is op 26 mei 2005 voor de tweede keer bij elkaar gekomen. Deze bijeenkomst werd gecombineerd met de vergadering van de COO-werkgroep van de NVMO in Twente. Tijdens de bijeenkomst werd een presentatie verzorgd door de projectgroep over de metadata die bij de lessen opgeslagen zal worden, de gekozen classificatie takken en de invulling hiervan met vocabulaires. Op de takken COO-type, technisch en onderwijskundig, waarvoor door de projectgroep een eigen vocabulaire is ontwikkeld kwamen vanuit de klankbordgroep enige inhoudelijke suggesties ter verbetering, die inmiddels zijn verwerkt. De keuze voor MeSH om de medische inhoud te beschrijven en het weglaten van het Raamplan riep nog wel enige discussie op. Het werd door de klankbordgroep echter, net als door de projectgroep, onwenselijk geacht om het Raamplan en MeSH tegelijk te gebruiken om de medische inhoud te beschrijven, aangezien dit voor overlap en inconsistentie in de classificatie zal zorgen. Een tussenoplossing is om de Raamplan informatie in de curriculum tak te beschrijven, zodat elk instituut zelf kan beslissen over de wenselijkheid hiervan. Naar aanleiding van dit punt wordt nog contact opgenomen met de Raamplan commissie om een eventuele koppeling tussen MeSH en de Raamplantermen te bespreken. De projectgroep zelf heeft hiertoe een poging gewaagd, maar het resultaat was niet bevredigend genoeg om binnen het project te gebruiken.

Fase 2 Inventariseren en klasseren van COO materiaal Deze fase start in juli 2005.

Fase 3 Functioneel ontwerp studie coach Halverwege mei is de eerste versie van het functioneel ontwerp (FO) onder de projectdeelnemers verspreid. In een model voor een FO zijn de aangeleverde gewenste specificaties van alle deelnemende faculteiten en de resultaten uit projectvergaderingen en bijeenkomsten van de klankbordgroep verwerkt. In de daaropvolgende versies heeft de nieuwe functionaliteit middels discussie, aanvullingen, wijzigingen en e-mail feedback, een meer definitieve vorm aangenomen. De nadruk heeft hierbij vooral gelegen op het ontwerpgebied en de benodigde functionaliteit voor SCALE. De onderwijskundige classificatie kreeg haar invulling. De toegang tot LRS.Net direct via e-mail of via een Digitale Leeromgeving is uitgebreid behandeld. De rechten van gebruikersrollen zijn uitgebreid en ook per kenmerk van les vastgesteld in een matrix. Er is gekozen voor een zoekstructuur en deze is gespecificeerd. De werking van de studiecoach is verduidelijkt. Vanuit de manual LRS.Net is de bestaande functionaliteit (gebruikersrollen voor enduser, teacher, administrator en superadministrator) opgenomen om daarmee de nieuwe functionaliteit ten aanzien van LRS.Net te verduidelijken. Vanuit de beschreven functionaliteit voor SCALE zal de technische beschrijving volgen. In het FO zijn follow-up afspraken voor het testen van de nieuwe functionaliteit opgenomen. Zie bijlage 3 voor de voorlopige versie van het functioneel ontwerp dd eind juni 2005

Fase 4 Technische realisatie studie coach Deze fase start in augustus 2005

6

Fase 5 Integratie van LRS.NET met de bestaande ICT infrastructuur Blackboard® koppeling Binnen Blackboard is een building block ontwikkeld, genaamd RichURL. De code hiervoor komt vrij ter beschikking van alle andere Blackboard gebruikers. Het doel van de RichURL extensie is het mogelijk te maken dat een hyperlink vanuit Blackboard naar het LRS.Net informatie over de gebruiker meegeeft op het moment dat deze klikt op de link. Vanuit Blackboard kunnen nu de volgende gebruikersgegevens mee worden gegeven: - uid (uniek gebruikersnummer) - firstname (voornaam) - lastname (achternaam) - mail (emailadres) - studentid (studentnummer) - gender (geslacht) - birthdate (geboortedatum) - courseid (cursusnummer)

Wanneer vanuit Blackboard met behulp van deze mogelijkheid minimaal het email adres van de gebruiker wordt meegegeven, kan LRS.Net de student automatisch inloggen, zonder nogmaals om een username en password te vragen, een zogenaamde single-login. Indien een Blackboard gebruiker nog geen account in LRS.Net heeft, wordt deze automatisch aangemaakt. Daarnaast kunnen extra (statische) parameters en hun waarden toegevoegd worden aan de hyperlink vanuit Blackboard. Deze mogelijkheid is voor het LRS.Net essentieel om 1 les of een groep lessen direct vanuit Blackboard op te kunnen starten. Hiermee wordt voldaan aan de wens van de klankbordgroep dat de LRS.Net lessen via Blackboard benaderd kunnen worden.

Fase 6 Inbedding in het onderwijs Deze fase start in augustus 2006

Fase 7 Promotie projectresultaten Deze fase start in september 2006

7

Fase 8 Evaluatie Deze fase start in september 2006.

Knelpunten Er is tijdens het tweede kwartaal goede voortgang geboekt. Het samenstellen van het functioneel ontwerp is echter complex en het lijkt er op dat het niet helemaal in de gewenste tijd afkomt. Door de vakantieperiode is er wat minder activiteit te verwachten, maar het moet mogelijk zijn om in augustus te beginnen met de opbouw van de technische realisatie, Fase 4. De afspraak is dat hierbij regelmatig door de projectgroepleden wordt getest of er aan de gewenste functionaliteit wordt voldaan. Fase 1 is inmiddels afgerond. Er is een opzet en keuze gemaakt voor benodigde classificaties. In de praktijk moet blijken of deze classificaties voldoende informatie verstrekken om alle gewenste functionaliteit te realiseren. In augustus wordt begonnen met de inventarisatie van het beschikbare COO en de eerste classificatie kan dan op papier plaatsvinden. Kort daarna worden de eerste technische aanpassingen aan LRS.Net verwacht, en kan ook online getest worden. Tijdens het intake review werd als knelpunt naar voren gebracht dat de onderwijsdirecteuren wat weinig betrokken lijken bij het project. Om deze betrokkenheid te versterken worden/zijn de onderwijsdirecteuren van de betrokken instellingen persoonlijk door de deelprojectleiders benaderd en nader geïnformeerd over het project. Daarnaast is via de voorzitter aan de Onderwijs Commissie Geneeskunde/het Discipline overlegorgaan Medische Wetenschappen (OCG DMW) het voorstel gedaan om binnen deze groep (waarin de onderwijsdirecteuren van de UMC’s samenkomen) een presentatie te geven van de doelstellingen en resultaten van het project.

8

Standlijnen overzicht Jan Feb Mrt Apr Mei Juni Juli Aug Sept Okt Nov Dec 2005 2005 2005 2005 2005 2005 2005 2005 2005 2005 2005 2005 Fase 1 Classificatie leerdoelen Fase 2 Inventarisatie COO Fase 3 Functioneel ontwerp Fase 4 Technische realisatie Fase 5 Integratie infrastructuur Fase 6 Inbedding onderwijs Fase 7 Promotie resultaten Fase 8 Evaluatie Jan Feb Mrt Apr Mei Juni Juli Aug Sept Okt Nov Dec 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 2006 Fase 1 Classificatie leerdoelen Fase 2 Inventarisatie COO Fase 3 Functioneel ontwerp Fase 4 Technische realisatie Fase 5 Integratie infrastructuur Fase 6 Inbedding onderwijs Fase 7 Promotie resultaten Fase 8 Evaluatie

Het project is dit kwartaal voor de geplande fasen volgens het standlijnenoverzicht verlopen. Daarnaast is alvast vooruitgewerkt aan de integratie met de bestaande infrastructuur van fase 5, door het in gebruik nemen van de koppeling van LRS.Net aan Blackboard.

Kennis disseminatie A-Select dag 25 mei 2005 A-Select is een door SURFnet aangeboden authenticatievoorziening, die onder andere door Kennisnet zal worden gebruikt in het Entrada-project ter vervanging van het huidige 'Entree'. A-Select voorziet in een decentrale authenticatie, terwijl voor Entree nog een centrale database met gebruikers (authenticatie) en licenties (autorisatie) wordt gebruikt.

9

Momenteel zijn er zo'n 2.5 miljoen gebruikers: alle scholen, onderwijsinspectie, uitgevers plus volwassen educatie. Doel: federatie opzetten met trustrelaties tussen onderwijsinstellingen, bibliotheken en uitgevers. In de toekomst zal A-Select de hele 'content ontwikkeling- en distributie-keten' ondersteunen en wellicht ook een portfolio functie krijgen. Er zal dus meer aan personalisatie gedaan moeten worden en een grotere variatie in gebruikersrollen moeten worden onderscheiden. De nieuwste versie1 van A-Select (1.4.1) zal daarom ook bij autorisatie kunnen helpen, door middel van het versturen van attributen ('identiteit') naar de server die om authenticatie heeft verzocht. De autorisatie zelf geschiedt op de ontvangende server aan de hand van de waarden van de attributen. In deze zin zal A-Select steeds meer gaan lijken op Shibboleth, dat onder andere wordt gebruikt door het AAI project van de Zwitserse organisatie SWITCH. Versie 1.4.1 zal nog geen 'terugtransport' van attributen ondersteunen. Versie 1.4.1 ondersteunt dus wel het scenario waarin een student die op een website van een uitgever een online tijdschrift wil lezen door de onderwijsinstelling wordt geauthenticeerd en door de uitgever wordt geautoriseerd. Het uitgebreidere scenario waarin het feit dat de student een bepaald artikel heeft opgevraagd (en hopelijk gelezen) wordt opgeslagen in een door de onderwijsinstelling beheerde portfolio is nog niet ondersteund. Zorgpunten bij A-Select zijn privacy en sessiemanagement. Als A-Select in verschillende gebieden wordt toegepast kan bij de gebruiker onzekerheid ontstaan over de hoeveelheid en aard van persoonlijke gegevens die aan een applicatie wordt doorgegeven. Dit is vooral een perceptieprobleem van de gebruiker. Het kan zich al voordoen bij de het onafhankelijk aanroepen van losse applicaties. Het probleem wordt versterkt als groepen applicaties (SSOgroepen) worden gemaakt die elkaar zonder directe invloed van de gebruiker aanroepen. Er zit nog een addertje onder het gras: de timeout-regels van A-Select en van applicaties kunnen verschillen, waardoor de gebruiker de indruk kan krijgen dat een A-Select-sessie is beëindigd terwijl alleen maar een applicatie-sessie is beëindigd. Er kan al gedeeltelijk aan de hiervoor geschetste problemen tegemoet worden gekomen door naast single sign-on ook een duidelijke single sign-off aan te bieden. Naast A-Select werd op de A-Selectdag ook het Engelse 'Eduserv Athens' gepresenteerd. Dit is een vergelijkbaar authenticatie-project, met als grote verschil dat er een centrale authenticatiesever wordt gebruikt. Het is grootschalig opgezet en loopt al 10 jaar. Er doen zo'n 2000 organisaties aan mee, waaronder ziekenhuizen, musea, bibliotheken en onderwijsinstellingen. Vanwege de grote verscheidenheid aan toepassingsgebieden waarin een gebruiker van dit systeem zich kan bewegen is er extra aandacht besteed aan privacy ('pseudonimity'). Een gedecentraliseerd authenticatie-model, zoals door A-Select gebruikt, heeft de voorkeur boven een gecentraliseerd model. Bij een recente implementatie van Eduserv Athens in de Verenigde Staten is een iets meer gedecentraliseerde opzet gekozen. Voor het SCALE-project is authenticatie-door-de-onderwijsinstelling interessant, omdat dit een grote beheerslast bij SCALE zelf voorkomt. Het is echter de vraag of de attributenschema's die binnen A-Select of andere projecten ontwikkeld worden toepasbaar zijn in het SCALE project. Het feit dat er naast het internationale eduPerson-schema al een specifiek Zwitsers swissEduPerson-schema en een Fins funetEduPerson-schema zijn ontwikkeld geeft aan dat er wel degelijk behoefte is aan (lokale) variaties van zo'n schema. De discussies over Attribute Release Policies, waarin wordt vastgelegd welke soort attributen tussen verschillende organisaties of verschillende applicaties mogen worden uitgewisseld, spelen ook in het SCALE project. Ervaringen die met A-Select op dit gebied worden opgedaan zullen waardevol zijn voor SCALE. Op technisch vlak is er een onderscheid tussen SCALE en A-Select wat betreft de implementatie van de trustrelatie tussen servers. Bij SCALE is die implementatie zwak

1

ten tijde van de A-selectdag

10

(referrer-based), bij A-Select wordt een sterkere implementatie voorgestaan (PKI voor langlevende trusts en SAML voor kortlevende 'payload'-trusts). Het SCALE-project gaat in eerste instantie uit van de Elektronische Leeromgeving als server voor remote authenticatie. De bestaande A-Select Agent voor BlackBoard 6.0 kan er dus voor zorgen dat SCALE via deze omweg van A-Select gebruik maakt. Het is daarbij wel van belang dat deze Agent tijdig wordt aangepast voor nieuwe BlackBoard-versies en dat vergelijkbare agents beschikbaar komen voor andere ELO's (WebCT!).

SOL Congres Portland Oregon 14-18 juni 2005 Door enkele projectmedewerkers is deelgenomen aan het Slice Of Life congres in Portland, Oregon. Dit congres richt zich volledig op computer ondersteund onderwijs voor het medisch vakgebied. Specifiek voor het SCALE project waren de workshop over metadata en het plenaire discussiepanel "Metadata, Taxonomies, And Cataloging Of Curricula And Their Content", waarin door één van de projectmedewerkers een presentatie werd verzorgd. Tijdens de discussie lag sterk de focus op onderwerpsclassificaties. De daarbij gebruikte taxonomieën worden niet alleen als navigatiestructuur ingezet, maar ook als ondersteuning van free text retrieval. Voor bepaalde taal-taxonomie-combinaties zijn free text indexing en retrieval tools ontwikkeld (bijvoorbeeld de Franstalige SNOMED) Classificaties van moeilijkheid/leerniveau, leerdoel en dergelijke werden in de discussie aangestipt zonder voorbeelden van oplossingen die breed gedragen worden. Er kwamen weinig reacties op het aspect van automatische Coaching. Op dit moment wordt metadata vooral gebruikt voor ondersteuning van object retrieval (zoekmachines) en voor een "harde" koppeling tussen leerobjecten, en nauwelijks voor een het genereren van "zachte" koppelingen. Harde koppelingen worden in de metadata opgenomen, bijvoorbeeld via het IMS "relation" veld, terwijl zachte koppelingen automatische worden gemaakt op grond van (andere) metadata. Daarnaast is in een postersessie de huidige versie van LRS.Net gedemonstreerd. Het congres heeft veel positieve reacties opgeleverd en een flink aantal nieuwe, internationale accounts in het LRS.Net. Zie de bijlagen voor de abstracts.

11

Kostenoverzicht 4

April-05 Begroting

Gerealiseerde kosten

In rapportage periode

t/m rapportage periode

51,500.00 €

2,620.10 €

275.07 €

2,895.17 €

Fase 1 en 2

216,949.14 €

68,088.47 €

10,538.73 €

78,627.21 €

Fase 3 en 4

5,834.05 €

Totaal Materiële kosten

200504 Restant op begroting

48,604.83 €

Gefaseerd personeel 138,321.93 € 116,718.04 €

122,552.09 €

65.39 €

5,768.66 €

Fase 5, 6 en 7

53,827.94 €

0.00 €

0.00 €

0.00 €

53,827.94 €

Fase 8 en Diversen

20,975.68 €

1,067.84 €

353.69 €

1,421.53 €

19,554.15 €

47,687.42 €

6,507.64 €

2,201.26 €

8,708.91 €

38,978.51 €

58,164.62 €

1,956.86 €

552.38 €

2,509.25 €

55,655.37 €

520,156.89 €

77,686.21 €

19,414.73 €

97,100.94 €

423,055.95 €

Projectoverstijgend personeel Projectleiding/Accountantscontrole Kennisdisseminatie/Financieel beheer Personeel inc.overhead

Subsidie Maximaal

309,672.16 €

Restant tot rapportage periode

266,265.18 €

Opgevraagd -t/m voorgaande periode

43,406.98 €

-in rapportage periode

10,945.53 €

-t/m rapportage periode

54,352.51 €

Restant op te vragen

255,319.65 €

12

5

May-05 Begroting




51,500.00 €

2,895.17 €

140.30 €

3,035.47 €

Fase 1 en 2

216,949.14 €

78,627.21 €

11,219.77 €

89,846.97 €

Fase 3 en 4

11,777.69 €

Totaal Materiële kosten


48,464.53 €

Gefaseerd personeel 127,102.17 € 110,774.40 €

122,552.09 €

5,834.05 €

5,943.64 €

Fase 5, 6 en 7

53,827.94 €

0.00 €

0.00 €

0.00 €

53,827.94 €

Fase 8 en Diversen

20,975.68 €

1,421.53 €

369.07 €

1,790.61 €

19,185.08 €

47,687.42 €

8,708.91 €

2,244.34 €

10,953.24 €

36,734.18 €

58,164.62 €

2,509.25 €

1,024.48 €

3,533.72 €

54,630.90 €

520,156.89 €

97,100.94 €

20,801.29 €

117,902.23 €

402,254.66 €


Subsidie Maximaal

309,672.16 €


255,319.65 €


54,352.51 €


11,592.96 €


65,945.47 €


243,726.69 €

13

6

June-05 Begroting





51,500.00 €

3,035.47 €

2,696.13 €

5,731.60 €

45,768.40 €

Fase 1 en 2

216,949.14 €

89,846.97 €

10,342.24 €

100,189.22 €

Fase 3 en 4

18,658.99 €

116,759.92 € 103,893.10 €

Totaal Materiële kosten Gefaseerd personeel

122,552.09 €

11,777.69 €

6,881.30 €

Fase 5, 6 en 7

53,827.94 €

0.00 €

0.00 €

0.00 €

53,827.94 €

Fase 8 en Diversen

20,975.68 €

1,790.61 €

355.09 €

2,145.70 €

18,829.98 €

47,687.42 €

10,953.24 €

2,155.49 €

13,108.73 €

34,578.69 €

58,164.62 €

3,533.72 €

808.16 €

4,341.88 €

53,822.74 €

520,156.89 €

117,902.23 €

20,542.27 €

138,444.51 €

381,712.38 €


Subsidie Maximaal

309,672.16 €


243,726.69 €


65,945.47 €


12,696.95 €


78,642.42 €


231,029.74 €

Declaratie De totale baten voor Scale voor deze projectperiode bedragen €35,235.44 en kunnen worden overgemaakt op rekeningnummer 56.28.96.899 tnv AZL-LUMC Divisie 1 te Leiden onder vermelding van SAPnummer 3101.10.6101.

14

Bijlagen Bijlage 1: Overzicht onderwijskundige classificaties Overzicht gemaakt door M. Doets, deels gebaseerd op een document van dr J Gulmans, Erasmus MC 2003

Inhoudsopgave Formuleren van leerdoelen: taxonomieën Taxonomie van Gagné De kenniskubus Taxonomie van Bloom Taxonomie van De Block Taxonomie van Romiszowski Taxonomie van leeruitkomsten van Jonassen/Tessmer Soorten van kennis Competenties Medische Competenties

Formuleren van leerdoelen: taxonomieën taxis = ordening en nomos = wet een wetmatige ordening, een structurering gebaseerd op een theoretische (en empirisch voor zover mogelijk) basis m.b.t. hoe leerdoelen in werkelijkheid geordend zijn Ééndimensionale: Gagné gedragsdimensie. Tweedimensionale: Merrill gedrags- en een inhoudsdimensie Driedimensionale: De Block, gedrags- en een inhoudsdimensie + transferniveaus

Taxonomie van Gagné http://classweb.gmu.edu/ndabbagh/Resources/Resources2/gagnetax.htm The classification of learning according to Robert Gagné includes five kinds of learned capabilities: intellectual skills, cognitive strategies, verbal information, attitudes, and motor skills. The Gagné taxonomy is perhaps the most popular of the many learning taxonomies in the field of instructional design. Its popularity can be attributed best for its ability to clearly distinguish between abstract and concrete definitions of learning (Seels & Glasgow, 1990). Motor Skills refers to bodily movements involving muscular activity. Examples might be: Starting a car, shooting a target, swinging a golf club. Attitude is an internal state which affects an indiviudal's hoice of action toward some object, person, or event. Examples might be: Choosing to visit an art museum, writing letters in pursuit of a cause. Verbal Information include: 1) Labels and facts refer to naming or making a verbal response to a specific input. The response may be naming or citing a fact or set of facts. The repsonse may be vocal or written. Examples: Naming objects, people, or events. Recalling a person's birthday or hobbies. Stating the capitals of the United States. 2) Bodies of Knowledge refers to recalling a large body of interconnected facts. Example: paraphrasing the menaing of textual materials or stating rules and regulations. Example: Paraphrasing the menaing of textual materials. Stating rules and regulations. Cognitive Strategy is an internal process by which the learner controls his/her own ways of thinking and learning. Example: Engaging in self-testing to decide how much study is needed;

15

knowing what sorts of questions to ask to best define a domain of knowledge; ability to form a mental model of the problem. Intellectual Skills include 1) Discrimination is making different responses to the different members of a particular class. Seeing the essential differences between inputs and responding differently to each. Example: Distinguishing yellow finches from house finches on the basis of markings; having to tell the differences between gauges on an instrument panel. 2) Concrete concept is responding in a single way to all members of a particular class of observable events. Seeing the essential similarity among a class of objects, people, or events, which calls for a single response. Example: Classifying music as jazz, country western, rock, etc.; saying "round upon seeing a manhole cover, a penny, and the moon. 3) Rule using is applying a rule to a given situation or condition by responding to a class of inputs with a class of actions. Relating two or more simpler concepts in the particular manner of a rule. A rule states the relationship among concepts. Examples: It is helpful to think of rules or principles as "if-then" statements. "If a task is a procedure, then use flowcharting to analyze the task." "If you can convert a statement into an 'if-then' statement, then it is a rule or principle." 4) Problem solving is combining lower level rules to solve problems in a situation never encountered by the person solving the problem. May involve generating new rules which receive trial and error use until the one that solves the problem is found. Reference Gagné, R.M. and Briggs, L.J. (1974). Principles of instructional design (2nd ed.). Holt, Rinehart, and Winston. Seels and Glasgow (1990). Exercises in instructional design. Columbus OH: Merrill Publishing Company.

De kenniskubus Jos W.G. Geerligs; http://www.stoas.nl/upload_Onderwijs/3657kenniskubus.pdf

Figuur: De kenniskubus, 64 vormen van kennis

16

A. De productie is vooropgesteld: we combineren ervaringen tot nieuwe ervaring, we zetten ervaringen om in informatie, we combineren informatie tot nieuwe informatie, en/of we zetten informatie om in ervaring B. De productie heeft resultaat: we vinden de waarheid of waarschijnlijkheid (inzicht), we maken werkende plannen en modellen (ontwerpen), we benutten in gemeenschappen selecties van inzichten en ontwerpen (gebruiken) en/of we leren als individu bestaande en nieuwe gebruiken (bekwaamheden) C. De benutting kan gericht zijn op initiatie van een individu in een gebruikersgroep (inwerken), het vernieuwen van de aanpak door een groep (substitueren), het verbeteren van prestaties van een groep (optimaliseren) en/of het veranderen van de aanpak van een groep (innoveren) De dimensies A, B en C met elk vier vormen leveren 64 vormen van kennis op, die als kennistransacties van bedrijven aan de orde kunnen zijn. […] Taxonomieën als die van Bloom (1956) zijn uitwerkingen van een cognitieve taxonomie. Simpson (1967) werkte een psychomotorische taxonomie uit. De Block (1973) maakt een theoretische combinatie van inzichten, houdingen en vaardigheden, maar heeft problemen met de inhoudelijke vulling. De consequentie is dat deze taxonomieën niet gebruikt moeten worden als ordeningsprincipe voor competenties. Alternatieve taxonomieën als die van Romiszowski (1981) en van Kolb (1976) zijn beter omdat zij wel uitgaan van de ‘heelheid van hande-len’, maar het bezwaar tegen het gebruik van deze twee indelingen is dat zij betrekking hebben op het verwerven van competenties en niet op de beschrijving van competentie. Een mogelijke optie is de taxonomie van Olbrich & Pfeiffer (1980); deze geeft een aantal klassen en niveaus voor prestatie en vermogen. De taxonomie van Olbrich & Pfeiffer is bewerkt door Geerligs (1999, pp. 338 - 339). De consequentie van de theorie hierboven is eenvoudig. Het gaat bij competentie in eerste instantie om werkwoorden die bijvoorbeeld zijn ontleend aan de beroepspraktijk: melken van …, rijden met …, onderzoeken van …, reflecteren op …, etc. (Van de Lagemaat, 1986). De werkwoorden krijgen concrete betekenis als er context bij is vermeld, dat is met de voorzetsels al gesuggereerd. Is de context zeer concreet en specifiek dan zou er sprake kunnen zijn van functie-eisen; is de context breed en algemeen dan kan er sprake zijn van brede (beroeps)kwalificaties of van sleutelkwalificaties. Functietraining en sleutelkwalificatie zijn dus twee uitersten van een contextbeschrijving bij een (respectievelijk specifiek of breed) gebruik! Een werkwoord beschrijft een proces en is daarom een veel flexibelere beschrijving van onderwijsdoelen dan een zelfstandig naamwoord dat een uitkomst als leerdoel beschrijft. Block, A. de (1973). Algemene didactiek. Antwerpen: Standaard Wetenschappelijke Uitgeverij. Bloom, B.S. (1956). Taxonomy of Educational Objectives. Handbook I: Cognitive domain. New York: Longmans Green. Geerligs, J.W.G. (1999). Design of Responsive VET. A reconstruction of a systems change in agricultural education. Thesis. Delft: Eburon Kolb, D.A. (1976, 1985). The learning style inventory. Boston, Mass: McBer and Co, 1976. Lagemaat, D. van de (1986). Onderwijzen in Ondernemen. Thesis. Culemborg: Educa-boek. Olbrich, G. & V. Pfeiffer (1980). Lernziehl-stufen: Darstellung und Anwendung eines Hierarchisirungssystems für Lernziele in der beruflichen Bildung. Berichte zur Beruflich-en Bildung 25. Berlin: Bundesinstitut für Berufsbildung. Romiszowski, A.J. (1981). Designing instructional systems. London: Kogan Page, (reprint 1992). Simpson, E.J. (1967). The classification of educational objectives, psychomotor domain. In: Illinois Teacher of Home Economics, volume X, number 4. University of Illinois.

Taxonomie van Bloom Bloom, B.S. (1956). Taxonomy of Educational Objectives. Handbook I: Cognitive domain. New York: Longmans Green.

17

Kennen •

Kennen van feiten

•

Kennen van middelen methoden, processen, etc.

•

Kennen van systemen en structuren Begrijpen

•

....door vertalen en omzetten

• •

.....door interpreteren ......door extrapoleren of interpoleren Toepassen

Analyseren

Synthetiseren Evalueren

De geheugenactiviteit is het hoofdproces Geen inzicht of begrip • Termen, definities, uitdrukkingen, jaartallen, etc. • Werkwijzen, technieken, klassen (bijvoorbeeld: genres, diersoorten), methoden van onderzoek, etc. • Regels, principes, generalisaties, theorieën, structuren, etc. Inzicht verondersteld, wat inhoudt dat men moet kunnen transformeren en gebruiken, maar louter in analoge situaties Of de student begrip heeft, kan men zien op drie niveaus: • ander abstractieniveau, omzetten van b.v. symbolisch naar verbaal, omzetten uit een andere taal, • hoofd- en bijzaken kunnen onderscheiden • consequenties kunnen trekken die niet expliciet gegeven zijn Gebruiken van kennis in nieuwe situaties (b.v. aangeleerde woorden in een gesprek kunnen gebruiken, juiste oplossingsmethode kunnen kiezen en/of gebruiken) Het verduidelijken, in vraag stellen, in samenstellende delen ontleden van de inhoud. De reden kunnen geven waarom iets op een bepaalde manier gedaan is of gebruikt is; redeneren. Denken dat creatief van aard is. De inhoud moet zelf samengesteld worden Kritisch denken, b.v. een boekbespreking maken

Taxonomie van De Block Block, A. de (1973). Algemene didactiek. Antwerpen: Standaard Wetenschappelijke Uitgeverij. Gedragsniveau Inhoudsniveau

Weten, inzien, toepassen, integreren Feiten, begrippen, relaties, structuren, methoden, attitudes

Transferniveau

Dichtbij, medium, veraf Onder transfer wordt verstaan, dat iemand geleerde kennis en vaardigheden in een andere dan de leersituatie kan aanwenden of gebruiken. Naar de mate dat deze andere situatie gelijkt op de leersituatie, spreken we van nabije transfer (near transfer). Omgkeerd, naar de mate dat de nieuwe situatie verschilt van de leersituatie, spreken we van verre transfer (far transfer).

Gedrag • Weten: lerende is zich bewust is van een bepaalde inhoud; reproduceren van feiten • Inzien: een eerste persoonlijke verwerking van de inhoud; logische

Inhoud • Feiten: concrete en unieke gegevens (b.v. namen, plaatsen, symbolen) • Begrippen: abstracties die gemeenschappelijke kenmerken

Transfer Nabij

Medium

18

•

•

verbanden leggen tussen leerinhouden Toepassen: de inhouden gebruiken in een andere situatie dan waarin aangeleerd Integreren: lerende komt spontaan tot het toepassen van inhouden

aangeven •

Relaties: enkelvoudige vaste verbanden tussen inhouden

Ver

•

Structuren: meervoudige geordende relaties zoals in theorieën, modellen, criteria, schema's; geheel van relaties in geordende vorm Methodes: werkwijzen of procedures om problemen op te lossen Attitudes: vrij stabele houdingen, instellingen, gerichtheden van een individu, ze weerspiegelen en waardeoriëntatie

Specifiek niveau: zeer specifiek kennisgebied.

• •

•

Weten

•

Inzien

•

Toepassen

•

Integreren

Cognitief • Herinneren • Opnoemen • Herkennen • Verklaren • Uiteenzetten • Vergelijken • Uitwerken • Evalueren • Ontwerpen • •

Uit zichzelf... Zich indentificeren

Affectief • Vatbaar zijn • Openstaan voor • Gevoelig zijn voor • Onderschrijven • Appreciëren • Empatisch benaderen • •

Vakoverschrijdend niveau: in een aantal vakgebieden. Algemeen niveau: algemeen geldig en overal van toepassing.

Wil

Geboeid zijn door Bewonderen

• • • • • • • • • • • •

Aannemen Goed vinden horen Demonstreren Beproeven Monteren Construeren Modelleren Vaardig gebruik Vkamanschap Demonstreren Spontaan doen

Taxonomie van Romiszowski Romiszowski, A.J. (1981). Designing instructional systems. London: Kogan Page, (reprint 1992). De taxonomie volgens Romiszowski onderscheidt vaardigheden en kennis. Vaardigheden • cognitieve vaardigheden, bijvoorbeeld interpreteren, analyseren, beslissen; • psychomotorische vaardigheden, bijvoorbeeld reflexzonemassage; • interactieve vaardigheden, bijvoorbeeld communiceren met patiënten/cliënten en hun naasten, samenwerken met verschillende disciplines; • reactieve vaardigheden, ook wel attitudevaardigheden, mensen en gebeurtenissen tegemoet treden vanuit een beroepshouding. Op elk van deze vier terreinen kan een onderscheid worden gemaakt in reproductieve en productieve vaardigheden.

19

Bij reproductieve vaardigheden gaat het om routines en beroepsactiviteiten die zijn gebaseerd op handelingsvoorschriften (standaardprocedures). Productieve vaardigheden doen een beroep op de creativiteit en het probleemoplossingsvermogen van de student. Deze heeft wel strategieën en handelingsprincipes geleerd, maar moet die toepassen in nieuwe situaties (nieuwe oplossingen voor nieuwe problemen, nieuwe procedures). Kennis Kennis wordt opgesplitst in feitelijke en begripsmatige kennis: • feitelijke kennis (herkennen en zich herinneren van feiten en handelingsvoorschriften); • begripsmatige kennis (inzicht, handelingsprincipes).

Feitelijke kennis • Concrete feiten •

Verbale, symbolische informatie

•

Systemen van feiten/schema’s

Procedures • • •

Ketens: enkelvoudige stap-voor-stapprocedures Discriminaties: het onderscheiden van informatie Algoritmen

Concepten • •

Weten hoe voort te gaan in specifieke situaties

•

Een recept voor de uitvoering van een procedure

Een categoriseer-regel op basis waarvan objecten processen, gebeurtenissen tot een klasse worden gerekend

Gedefinieerde concepten Conceptsystemen

Principes • • •

Objecten gebeurtenissen, namen, etc. • Concrete associaties • Geobserveerde en herinnerde dingen • Taal • Logica • De meer complexe feitelijke kennis, b.v. morsecode

Regels die een actie sturen of een verandering verklaren

Principes van de natuur Principes van handelingen Regelsystemen

Kennis Feitelijk Begripsmatig • Aanwijzen • Aanvullen • Benoemen • Bschrijven • Herkennen • Categoriseren • Noemen • Classificeren • Onderstrepen • Combineren • Opnoemen • Definiëren • Opsommen • Formuleren • Illustreren • Indelen • Kenschetsen • Omschrijven • Onderscheiden

Vaardigheden Reproduktief • Aflezen • Beproeven • Berekenen • Beslissen • Coderen • Controleren • Lezen • Opzetten • Opzoeken • Raadplegen • Registreren • Samenstellen

Productief • Aantonen • Afleiden • Analyseren • Beoordelen • Bekritiseren • Bewijzen • Combineren • Concluderen • Constateren • Coördineren • Definiëren • Evalueren

20

• • • • • •

Ordenen Samenvatten Selecteren Uiteenzetten Uitleggen Verklaren

• • • • • • • • • •

Toepassen Uitrekenen Vaststellen Vergelijken Voorbereiden Aanbevelen Diensverlenen Goedvinden Instemmen met Meewerken

• • • • • • • • • • • • • • •

Generaliseren Inschatten Lezen Ontwerpen Plannen Rapporteren Relativeren Uitvinden Werk voorbereiden Aanbevelen Aannemen Aanvaarden Dienstverlenen Goedvinden Instemmen

Taxonomie van leeruitkomsten van Jonassen/Tessmer Jonassen, D. H. and Tessmer, M. (1996/97) An outcomes-based taxonomy for instructional systems design, evaluation and research. Training Research Journal, 2, 11-46 Soorten van kennis • Declaratieve kennis: Van belang is het onderscheid tussen declaratieve kennis en procedurele kennis. Het eerste type kennis (declaratieve kennis) representeert de kennis van een object, een gebeurtenis of een idee. Declaratieve kennis van ideeën wordt vaak gekarakteriseerd als schema’s. Schema’s zijn geïdealiseerde constructen, die worden gedefinieerd door attributen die ze overerven van andere schema’s. • Procedurele kennis: procedurele kennis beschrijft hoe lerenden hun declaratieve kennis gebruiken of toepassen. Procedurele kennis beeldt de interrelaties van schema’s zó af, dat er patronen ontstaan die mentale verrichtingen representeren. Declaratieve kennis levert de conceptuele basis voor de procedurele kennis. • Structurele kennis bemiddelt bij de vertaling van declaratieve in procedurele kennis en vergemakkelijkt de toepassing van procedurele kennis. Structurele kennis is de kennis over de vraag hoe concepten binnen een domein gerelateerd zijn. Structurele kennis biedt de conceptuele basis voor het antwoord op de vraag naar het waarom. Het beschrijft hoe de declaratieve kennis is gekoppeld. • Conceptuele kennis wordt gebruikt om procedurele kennis te ontwikkelen teneinde domein-problemen op te lossen. Structurele (conceptuele) kennis betreft de integratie van declaratieve kennis in bruikbare kennisstructuren. Merk op dat structurele kennis ook kan verwijzen naar de kennisstructuur van een individu. “Kenisstructuren” is de term die slaat op georganiseerde netwerken van informatie, die opgeslagen zijn in het semantische of lange termijn geheugen. • Schema’s zijn mentale abstracties die we gebruiken om de wereld te begrijpen. We moeten de slots van een schema vullen met de correcte informatie door schemaselectie of door de overerving van attributen van andere schema’s teneinde structurele en procedurele kennis te verwerven. Structurele kennis wordt opgebouwd met geïnterrelateerde schemata. • Mentale modellen zijn geconstrueerd op een basis van structurele kennis. Terwijl andere structurele kennis-uitkomsten betrekking hebben op onderling verbonden verzamelingen van verbaal of beeldmatige proposities, omvatten mentale modellen vaardigheden als deel van de informatie. Mentale modellen zijn noodzakelijk voor kennis-ampliatie, probleemoplossen en transfer.

21

Competenties

Een inhoudsclassificatiecomponent Een context Vaardigheden om competentie uit te voeren. Kennis nodig om competentie uit te voeren. Persoonlijke eigenschappen Criteria

Er bestaat geen algemeen aanvaarde definitie van competentie. Als u er willekeurige literatuur op na slaat, zult u al gauw tot de ontdekking komen dat iedere auteur er een eigen definitie van competentie op nahoudt. Ditzelfde zult u zien als u verschillende competentiegerichte opleidingen met elkaar vergelijkt, of verschillende competentiekaarten naast elkaar legt. Dit betekent dat u zelf moet bepalen welke definitie van competentie u wilt gaan gebruiken. De onduidelijkheid over competentie kunt u dus als een kans zien om uw eigen visie over competentie en competentiegericht onderwijs vorm te geven. http://www.open.ou.nl/ast/comet The competency modelling toolkit - De toolkit voor het maken van competentiekaarten als basis voor competentiegericht onderwijs Bloom Knowledge

Gagné Verbal information

Comprehension Application Analysis Synthesis Evaluation

Ausubel Rote learning

Anderson Declaritive knowledge

Meaningful learning Intellectual skill Cognitive strategy

Gedragsdimensie Knowledge (kennen)

Procedural knowledge

Merrill Remember verbatim Remember paraphrased Use a generality

Reigeluth Memorize information Understand relationships Apply skills

Find a generality Apply generic skills

Application (toepassen in specifieke situaties)

Relatie met inhoudsdimensie Knowledge of specifics (terminologie, feiten) Knowledge of ways and means of dealing with specifics (classificaties, ordeningen, vergelijkingen, afspraken, …) Knowledge of universals and abstractions in a field (theorieën, veralgemeningen, abstracties, principes, …) Translation (wat men kent wordt anders verwoord, voorgesteld) Interpretation (men gaat voorbij de direct observeerbare aspecten) Extrapolation (uit andere beschikbare kennis wordt nieuwe kennis afgeleid) Application of abstractions (toepassen algemene ideeën, principes, theorieën, regels, …)

Analysis (analyse, opsplitsen van iets in samenstellende ideeën om

Analysis of elements (elementen) Analysis of relationships (relaties)

Comprehension (verstaan)

22

zo de essentie naar voren te halen, te expliciteren)

Analysis of organisational principles (organisatieprincipes)

Synthesis (synthese, samenbrengen om een nieuw geheel te creëren)

Production of a unique communication Production of a plan of a proposed set of operations Production of a set of abstract relations

Evaluation (evaluatie, oordelen uitspreken over de waarde van)

Judgment in terms of internal evidence (eigen criteria) Judgment in terms of external criteria (externe criteria)

Medische Competenties ACGME CORE COMPETENCIES

http://www.som.tulane.edu/acgme-competencies/expected.html Patient Care Residents are expected to provide patient care that is compassionate, appropriate and effective for the promotion of health, prevention of illness, treatment of disease and at the end of life. Medical Knowledge Residents are expected to demonstrate knowledge of established and evolving biomedical, clinical and social sciences, and the application of their knowledge to patient care and the education of others. Practice - Based Learning and Improvement Residents are expected to be able to use scientific evidence and methods to investigate, evaluate, and improve patient care practices. Interpersonal and Communication Skills Residents are expected to demonstrate interpersonal and communication skills that enable them to establish and maintain professional relationships with patients, families, and other members of healthcare teams. Professionalism Residents are expected to demonstrate behaviors that reflect a commitment to continuous professional development, ethical practice, an understanding and sensitivity to diversity and a responsible attitude toward their patients, their profession, and society. Systems-Based Practice Residents are expected to demonstrate both an understanding of the contexts and systems in which health care is provided, and the ability to apply this knowledge to improve and optimize health care. Vergelijk het Raamplan 2001: De vaardighedenlijst kent de volgende indeling: anamnese lichamelijk onderzoek vaardigheden ten behoeve van aanvullende diagnostiek therapeutische vaardigheden communicatie en verslaglegging sociale geneeskunde

Bijlage 2 Ontwikkelde classificaties

23

Classificatie Computer Based Training (CBT) Doel van deze classificatie is de beschrijving van de lesvorm van de applicatie. Deze classificatie is zoekbaar voor docenten en toonbaar voor studenten. Een applicatie kan meerdere lesvormen bevatten. Structuur: CBT Type Tutorial Information Search Reference Simulation Case Static Closed Static Open Dynamic Closed Dynamic Open Process Chart or plot Visual Animation Assessment Explicit Open End Multiple Choice Single answer Multiple answer Drag & Drop Long menu Implicit Game Single user Multi-player

Technical Classification De technische classificatie is alleen bedoeld voor onderwijs ontwikkelaars. De classificatie valt in 3 hoofdcategorieën uiteen: 1. Programming Language: Beschrijft welke programmeertaal of talen in de applicatie gebruikt zijn, met als doel de ontwikkelaar een indruk te geven of zijn of haar instelling de applicatie kan overnemen en aanpassen. 2. Operating System: Geeft aan welk operating system op de server en/of de client verondersteld wordt. 3. Content: Geeft aan wat voor bestanden/standaarden in de applicatie gebruikt worden. Nodig voor distributie en/of voor verdere ontwikkeling. De eerste subtak (Text) bevat formaten die door standaard searchengines geïndexeerd en doorzocht kunnen worden. Technical Programming Language Scripting Client side Javascript VBScript Server side

24

PERL CGI PHP ASP Cold Fusion (CFM) Executable Director Flash Visual Basic VB6 VB.Net Java C# C++ Authorware C Fortran Pascal OS Web Based (ISAPI based) ASP PHP ASP.Net PERL CGI JSP Cold Fusion (CFM) Windows 16 bit 32 bit 64 bit DOS JAVA Macintosh Unix Linux BSD Solaris Content Text ASCII PDF RTF HTML XML PowerPoint PPT Word (DOC) Excel (XLS) Multi Media Picture BMP JPEG GIF PNG TIFF Sound Streaming MP3 ASF WMA

25

Download WAV AU MP3 WMA Animation Animated GIF FLI/FLC Flash Director Authorware Movie Streaming MPEG 1 MPEG 2 MPEG 4 Windows Media Video WMV Quicktime MOV AVI Real ASF Download MPEG 1 MPEG 2 MPEG 4 Windows Media Video WMV Quicktime MOV AVI Real Database Access MDB MySQL SQLServer Oracle

26

Bijlage 3 Abstracts SOL congres CLASSIFICATION OF COMPUTER BASED TRAINING PROGRAMS Andries J.M. de Man1, Peter M. Bloemendaal1, Pieter F. de Vries Robbé2 1 Leiden University Medical Center and 2Radboud University Nijmegen Medical Center, The Netherlands Focus Terminological principles are used to develop an extensive classification for computer based training programs that can be used by all who want to organize CBT material. Problem In a cooperation of several medical faculties we intend to use a common set of Computer Based Training (CBT) programs through the Internet. To enable students as well as teachers to find relevant programs from this collection a set of useful criteria is needed. Method An inventory has been made on relevant types of requests for CBT material from several user groups: students, teachers, curriculum designers and CBT managers. The set of requests was analyzed to model a set of necessary descriptors of CBT material. Furthermore the goal descriptions of CBT material used in our institutions were analyzed to search for possible values for each of the descriptors. As far as values couldn’t be derived from the goal descriptions other documents describing the CBT-programs were used. Results The set of descriptors with their relevant values is the content of the classification of CBT programs. The set contains MeSH for describing medical content and several additional descriptors for skills, competencies, and administrative and technical aspects. This will now be used in a CBT request module as part of an Internet based Lesson Registration Program. This classification also will be used by other medical schools in the Netherlands and can be of use for other institutes internationally.

DISTRIBUTING COMPUTER BASED TRAINING THE EASY WAY WITH THE LESSON REGISTRATION SYSTEM (LRS.Net) Peter M. Bloemendaal, Sylvia Eggermont, Pieter F. de Vries Robbé, Leiden University Medical Center and Radboud University Nijmegen Medical Center, The Netherlands Problem In the last 5 years the distribution of Computer Based Training (CBT) material has shifted to the Internet. This shift necessitated a change in the presentation and monitoring system for CBT material. Method To distribute and monitor the use of CBT a Lesson Registration System was build with Microsoft.Net technology (LRS.Net). This system consists of a central web-server and a database. The database holds three major tables: Lessons, Accounts and Sessions. The lesson table holds information on the lessons and the reference (URL) to the lesson on the Internet. This enables referring to lessons somewhere on the Internet as well as our own lessons. To assure the presence of CBT material of others, each night the LRS.Net system checks all the URLs. Students of our own institution are automatically imported in the Account table periodically. Other (internet) users can create their own account. The use of lessons by users is registered in the Session table. Results LRS.Net has been online since 2004 and has logged all lesson- and student data centrally. It was used by our own students as well as students all over the world. The number of accounts and lessons are still growing prosperously. In 1 year the number of lessons has grown to

27

more than 350, used by more than 5000 users in over 30000 interactive sessions. Because it is an open system, anybody with a valid email address can create his own account. LRS.Net is therefore a source of Medical CBT, interesting for all medical educators in the world.

Bijlage 4 Functioneel ontwerp

Functioneel Ontwerp Studie Coach and Learning Environment voor computer based training Datum

4 augustus 2005

Status

versie 0.6

Formatted: Bullets and Numbering

Inhoudsopgave Versiebeheer en distributie Functioneel Ontwerp Versiebeheer Distributie Samenvatting Ontwerpgebied Inleiding Voorwaarden waaraan systeem moet voldoen Uitgangspunten Kwaliteitseisen Ontwerpbeslissingen Geraadpleegde documentatie Relaties SCALE Omgeving Informatieprocesmodel SCALE Symbolen Data Flow Diagram SCALE DFD niveau 1 DFD niveau 2 Logisch gegevensmodel Entity Relationship Diagram (ERD) Beschrijving per tabel Relatiebeschrijvingen Wijzigingen datamodel bestaande systeem Consequenties van de wijzigingen op het datamodel bestaande systeem Organisatie regels Statusovergangen voor het logisch gegevensmodel Constraints Autorisatiemodel Gebruikersgroepen Rechten Matrix bevoegdheden ten aanzien van het gebruik van actuele waarden Matrix bevoegdheden ten aanzien van het gebruik van metagegevens Matrix processen en tabellen (CRUD matrix) Generieke werking functies en interfaces (styleguide) Aanmelden bij het systeem Applicatievenster Soorten gegevensverzamelingen Algemene werking functies Aanroepen zoekfuncties Algemene werking documenten en overzichten

28

Detail functiebeschrijvingen Functiebeschrijving A Functiebeschrijving B Detail interfacebeschrijvingen GUI Functie A GUI Functie B Configuratie productie omgeving Consequenties bestaande systemen Standaards Functies Gegevensmodel LRS.Net Interfaces LRS.Net Aandachtspunten vervolgtraject Testfase Realisatiefase Implementatiefase Beheer- en onderhoudfase Crossreferences Crossreference van informatieproces(sen) naar functie(s) Crossreference van buffer(s) naar tabel(len) in de database Legenda

Versiebeheer en distributie Functioneel Ontwerp Versiebeheer Versie 0.1 0.2

Datum 2005-05-17 2005-05-26

Auteur MA MA

0.3 0.4 0.5 0.6

2005-06-07 2005-06-08 2005-06-16 2005-06-28

MA MA MA MA

Omschrijving Eerste versie Projectvergadering 19 mei 2005 i.s.m. PVR Tweede versie n.a.v. Projectvergadering 19 mei 2005 en t.b.v. actiepunt20050519-3 Allen: Een ieder geeft in FO aan per punt wat er nog aan moet worden gewijzigd Verwerken opmerkingen allen op fo Projectvergadering 8 juni 2005 opmerkingen gewijzigd. Aanvullingen op FO vanuit Manual LRS 9 juni 2005 e t.b.v. Projectvergadering 1 juli 2005 en 2 Voortgangsrapportage

Distributie Versie 0.1 0.2 0.3 0.4 0.5 0.6

Datum 2005-05-17 2005-05-26 2005-06-07 2005-06-08 2005-06-16 2005-06-28

Aan Allen Allen Allen Allen Allen Allen

Legenda: Alers, M (MA), Bloemendaal, P. (PB), Diepmaat, F. (FD), Doets, M. (MD), Eggermont, S.(SE), Langeveld, V. (VL), Man, A. de (AdM), Projectmedewerkers SCALE (Allen), Oostendorp, T. (TO), Quaak, M. (MQ), Vries Robbé, P. de (PVR)

Samenvatting Begin maart 2005 is een subgroep van het project SCALE gestart met het functioneel ontwerp. In dit ontwerp zijn de gewenste specificaties van alle deelnemende faculteiten opgenomen. De functionaliteit voor SCALE is beschreven middels overleg met COO coördinatoren, ICT medewerkers, onderwijskundigen en studenten van- en overleg tussen de aan het project deelnemende instellingen. SCALE heeft kennis van de COO programma’s enerzijds en de studenten en hun resultaten geboekt met het studiemateriaal anderzijds. In mei 2005 is tijdens de projectvergadering de eerste versie van het functioneel ontwerp aan de projectdeelnemers verstuurd. Het functioneel ontwerp, inclusief de functionele specificaties is

29

voor eind juli 2005 klaar. Vervolgens zal begonnen worden met het ontwikkelen en programmeren van de beschreven specificaties.

Ontwerpgebied In dit hoofdstuk wordt SCALE kort beschreven in relatie tot LRS.Net (een bestaand systeem ontwikkeld door en gebruikt bij het Leids Universitair Centrum) en COO-materiaal dat gebruikt wordt bij de deelnemende instituten. Hierbij wordt aangegeven welke functies SCALE moet ondersteunen. Vervolgens worden de hieruit voortvloeiende werkzaamheden toegelicht.

Inleiding Het Leids Universitair Medisch Centrum (LUMC), Erasmus Universitair Medisch Centrum Rotterdam (Erasmus MC), Universitair Medisch Centrum Utrecht (UMCU) en het Universitair Medisch Centrum St Radboud Nijmegen (UMC St Radboud) werken in 2005 en 2006 in het SCALE project, dat tot doel heeft faciliteiten te ontwikkelen om het tot nu toe in deze instellingen geproduceerde digitale studiemateriaal onder de studenten te kunnen verspreiden, middels een studie coach. Het is een subsidie project van de Stichting SURF. De aanleiding tot het ontwerp van dit systeem is de toegenomen kwantiteit en kwaliteit van het COO, zowel inhoudelijk als technisch aan de Nederlandse medische universiteiten. Voor deze onderwijsvorm zijn in de afgelopen 25 jaar inmiddels honderden programma’s gemaakt die in het medisch onderwijs ieder hun eigen leerdoel en toepassing hebben (alle denkbare vormen van elektronisch studiemateriaal, variërend van casuïstiek, tutorials, simulaties tot toetsen). Iedere instelling gebruikt hierbij zijn eigen materiaal. Het merendeel hiervan wordt als zelfstudie materiaal aangeboden. Het volgen van dit onderwijs is vaak niet verplicht en wordt niet getoetst. Dit vraagt om een meer structurele plaats in het onderwijs en in de toetsing. SCALE heeft kennis van de COO programma’s enerzijds en de studenten en hun resultaten geboekt met het studiemateriaal anderzijds. Hierdoor kan het systeem studenten van advies dienen ten aanzien van behaalde leerdoelen. Daarnaast levert het systeem de mogelijkheid om op een flexibele manier al het COO te bereiken, ook wanneer het gaat om niet zelf geproduceerd materiaal. De studie coach kan gekoppeld worden aan een Digitale Leer Omgeving. Studenten en docenten van de betrokken universiteiten hebben middels deze studie coach op eenvoudige wijze toegang tot zowel individuele als cohort resultaten en kunnen zowel de gevolgde programma’s als de leerdoelen in de tijd vervolgen. Deze resultaten zullen het directe bewijs vormen hoe frequent en op welke wijze dit systeem in de praktijk gebruikt wordt. Het functioneel ontwerp levert een door alle deelnemende instellingen gevalideerd document op met gebruikersspecificaties van de studie coach en vormt de basis voor zowel de technische realisatie van SCALE als ook voor de gebruikersdocumentatie (handleiding). De technische realisatie van de studie coach omvat het programmeren, testen en opleveren van een module binnen LRS.NET van waaruit naast het gebruik van COO door studenten, ook de leerdoelen per student kunnen worden geregistreerd en gevolgd in de tijd. Deze informatie maakt een coachend studie advies aan studenten mogelijk. Naast een studiecoach wordt ook een review systeem aan LRS.NET toegevoegd.

Voorwaarden waaraan systeem moet voldoen Benodigde functionaliteit voor SCALE is:

Gebruikersidentificatie en studentengegevens Accounts in SCALE worden aangemaakt op basis van een geldig e-mailadres. Toegang tot SCALE kan plaatsvinden op 2 manieren: direct (de gebruiker logt in) of indirect (via een ander systeem). Directe toegang ( op basis van mailadres) De gebruiker kan zelf een studentenaccount aanmaken in LRS.Net op basis van een geldig e-mailadres. Na aanmelding krijg je automatisch via de e-mail een password voor de account. Als je al een account hebt kan je dit aangeven en inloggen De studenten en docenten van de betrokken instellingen worden, waar mogelijk, automatisch geïmporteerd in SCALE. Hierbij worden zij automatisch toegevoegd aan de juiste

30

gebruikersgroep, zodat zij toegang krijgen tot de lessen die ter beschikking staan van deze groep. Indirecte toegang (via andere systemen) De koppeling aan de leeromgeving via de studie coach kan direct of indirect via reeds vigerende of in ontwikkeling zijnde systemen: zoals Blackboard, curriculum database programma’s en dergelijke, maar ook studievolgsystemen en portfolio’s. SCALE kan autorisatie geven aan de student als blijkt dat die inlogt via de leeromgeving (bijvoorbeeld Blackboard login en password), zodat de gebruiker niet opnieuw hoeft in te loggen. Bij inloggen via DLO in LRS.Net wordt automatisch een password aangemaakt. Dit account wordt gemailed aan student. Het account binnen LRS is niet gelijk aan login naam van de DLO. Het e-mail account van LRS wordt gekoppeld aan twee groepen: de standaard internetgroep en de groep van de getruste site (bijv. Erasmus). Na het doorgeven van de identificatie kan meteen een COO gestart worden vanuit een DLO. Meerdere studenten moeten tegelijk registreerbaar zijn als zij samen een COO maken (achter één PC).

Gebruikersgroepen Type gebruikers worden onderscheiden om de formele toegang tot functionaliteit te regelen. Lesgroepen zijn bedoeld om het praktische aanbod van lessen te regelen. In een kruistabel wordt per gebruikersrol aangegeven wat de bijbehorende rechten en mogelijkheden zijn van de selectiemogelijkheden voor COO. Gebruikers De volgende gebruikersrollen voor SCALE zijn beschreven: A. Student Deze student-gebruikersrol heet in LRS enduser. Endusers kunnen lessen opstarten die gekoppeld zijn aan de gebruikersgroep waar de enduser bij hoort. Studentresultaten worden gelogd in LRS. De interface van de Enduser start op in de taal zoals die door de student kan worden ingesteld bij de change properties optie (op dit moment is de enige taal van de interface Engels). Dit is een icon op de personal settings banner (onderin scherm). Via deze banner kun je ook terug naar het beginscherm (home), zoeken op titel en onderwerp van les (search), je personal portfolio aanpassen, je paswoord wijzigen (change password) en een logoff icon.. Er is een keuze-optie om lessen in een andere taal te zoeken. Boven dit zoekscherm staat dan hoeveel lessen van die taal online zijn. Lessen zijn onderverdeeld in drie features: Main Department, Category of disease en Body part / organic tract. Aan het einde van een les kan een keer comment worden gegeven (review). Het gemiddelde van alle reviewers samen staat bij selectie van de les erachter. Zie tabel Informatie over lessen in SCALE (3.2.3 III), voor nieuwe functionaliteit. B. Teacher De teacher kan lessen in LRS.Net draaien als student (LRS) en kan ook een overzicht krijgen van recente sessies gedaan in LRS.Net (Show Sessions). De Teacher kan hiermee studentdeelname en prestatie bekijken. Er is een mogelijkheid tot subselecties van studenten, lessen, lessengroepen and periodes. De teacher kan dus de resultaten van een les in de groep waarover hij/zij zelf lesgeeft opvragen. De docent kan lessengroepen klaarzetten; pre-selecties voor studenten.

C. Administrator Per instelling is er een administrator die studenten toegang kan verlenen. Deze rechten worden ook automatisch moeten uitgedeeld, op basis van het e-mail adres. Administrators werken in een groep zodat ze elkaars lessen kunnen overnemen. De administrator kan als student het systeem benaderen (LRS) en ziet alle faciliteit als Teacher (Accounts, Show Sessions). Hij/zij kan contactpersonen (contacts) , dit zijn teachers of andere administrators, voor lessen toevoegen. De administrator heeft beheer over de lessen: add, edit, delete (lessons). Hier kan gezocht worden naar titel of onderwerp van de les, de lesid wordt getoond, Name, Subject, Institution, Verion, Language, Audience, Author, Owner, CBT-type, Contact, Requirements, Description, URL(een lessonID –maar ook een lessengroepID- kunnen automatisch worden gestart), BrokenCheck (of een les nog bereikbaar is via het internet). De les kan online of autoOnline worden gezet. De les kan worden ingedeeld in de features (Main Department, Category of disease en Body part /

31

organic tract). Er kan worden ingedeeld in welke gebruikersgroepen (welke toegangsmogelijkheden) het account thuishoort. En er kan automatisch gechecked worden of de client-computer de benodigde plugins voor desbetreffende les heeft (zo niet, dan kan dit worden gedownload). Verder kan de administrator lesgroepen onderhouden: add, edit, delete (LessonGroups) en hierin lessen wijzigen (Lesson in Group) en kan lessen van een andere administrator uit dezelfde AdminGroup overnemen (Steal lesson). Per instelling is er een administrator die studenten toegang kan verlenen. Deze rechten worden ook automatisch moeten uitgedeeld, op basis van het e-mail adres. Administrators werken in een groep zodat ze elkaars lessen kunnen overnemen. Administrators krijgen rechten om andere accounts teacher rechten te geven. D. Superadministrator De superadministrator kan administrator accounts aanmaken. De superadministrator kan de settings van de account wijzigen. De superadministrator kan wijzigen in welke gebruikersgroep een account zit. De superadministrator heeft toegang tot alle onderdelen van het systeem, kan systeemfouten opsporen. De superadministrator onderhoudt de features en de root van de classificatie. Matrix rechten Gebruikers Student Teacher Administrator Superadministrator Zoeken x x x x Les opstarten x x x x Lesgroep aanmaken x x Gebruikersgroep x aanmaken Users verwijderen x Sessie van jezelf x x x bekijken Sessie van anderen x x bekijken Gebruikersgroepen Naast rollen moeten er ook groepen aangemaakt kunnen worden (door een administrator, bijvoorbeeld door batch import van een lijst studentnummers). Lessen en accounts kunnen gekoppeld worden aan groepen. Een groep bestaat uit een aantal accounts die specifieke rechten hebben. Alle nieuwe vrije aanmeldingen worden automatisch toegevoegd aan de usergroup: Internet users.

Zoek- en Selectiemogelijkheden van lessen Er wordt hier beschreven welke zoeken selectiemethoden het systeem biedt en op welke manieren de gebruiker een les kan bereiken. Zoeken door middel van vrije tekst Het systeem werkt als een Google achtige zoekmachine, waar je na het intypen van een zoekwoorden een lijst met gevonden lessen krijgt, waarbij de beste match bovenaan staat. Er wordt rekening gehouden met synoniemen. De zoekmachine maakt gebruik van de boomstructuur om de lijst met treffers te ordenen en om meer specifieke of meer algemene COO te vinden dan wat door de zoekwoorden wordt uitgedrukt. De plaats in de lijst moet afhankelijk zijn van de naam; bij een hoge score wordt bijvoorbeeld de zoekopdracht direct in de betreffende tak/bladnaam gevonden, hoe verder in de boom, hoe lager de score. Ook het gewicht van de koppeling tussen de les en de boom moet hierin meegenomen worden. Bij het zoekveld is aan te geven waar gezocht moet worden: in alle velden, of alleen in de metadata en/of in de classificaties. Zo moeten er selecties kunnen worden gedefinieerd waaruit gekozen kan worden bijvoorbeeld alle COO over hart in alle faculteiten. Ingang via de ziektecategoriën, vakgebieden en body-parts van het huidige LRS.Net blijft. Gezocht wordt in de takken- en bladerennamen van de boom en de bijbehorende synoniemen. Lessen die in subtakken van gevonden takken voorkomen worden, met een lager gewicht, ook in de zoekresultaten opgenomen. Bedoeling van de zoekmachine is zodanig dat de uitkomst gespecificeerd wordt per doorzochte boom en dat de uitkomst per

32

doorzochte boom de term en het gewicht weergeeft. De gevonden lessen worden gesorteerd in volgorde van belangrijkheid. De zoektermen worden gelogd, zodat superadministrator kan zien wat mist in het systeem, of waar synoniemen toegevoegd moeten worden. Zoeken per gebruikersrol Verschillende gebruikers kunnen via verschillende kenmerken lessen in SCALE vinden:

Legenda x = zoekbaar t = direct getoond in zoekresultaat o = oproepbaar * = Nieuw in SCALE Rubriek

Nr.

Naam

Type

Beschrijving

Algemene informatie bij de les

1 2 3

Name Subject Content description Educational setting description

tekst tekst tekst

Target audience Main Department Body part / Organic tract Language Time

tekst

Naam les Onderwerp les Beschrijving van de inhoud Beschrijving van de studentrol / setting van de les Doelgroep

4

5 6 7 8 9 Technische informatie

10 11 12 13

Conctact informatie

Classificatie takken *

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

Technical description Icon Version Unique number Url BrokenCheck Online AutoOnline Checks Usergroups Institution Author Owner Contact Curriculum Technical Medical COO-type Educational

tekst

vaste lijst getal in minuten tekst niet opzoekbaar datum autonummer

etc

Student

Teacher

xo x xo

xo xo xo

Administrator/ Superadministrator xo xo xo

xo

xo

x x

x

x

x

x

x

o o

o o

o o x

o

o

o

o

o o

o

o o xt x x x x

o o x x x x x

tekst tekst ja/nee ja/nee

tekst tekst tekst xt x x

Toelichting op kenmerken Er komt een vrij tekstveld description waarin de beschrijving van de studentrollen binnen een les en de setting van de les kan worden aangegeven.

33

Voor het gebruik van de COO les wordt aangegeven hoeveel players er zijn. Indien de les runt uitzichzelf wordt hier 0 ingevuld, is het een single-user les dan vul je 1 in en bij multi-user indicatie 2. Inhoud classificaties: A. Curriculum classificatie Het curriculum zal in een hiërarchische structuur worden opgenomen. Hierdoor is het mogelijk lessen aan een bepaald onderdeel van een curriculum te koppelen. B. Technische classificatie De technische classificatie is alleen bedoeld voor onderwijs ontwikkelaars. De classificatie valt in 3 hoofdcategorieën uiteen: • Programming Language: Beschrijft welke programmeertaal of talen in de applicatie gebruikt zijn, met als doel de ontwikkelaar een indruk te geven of zijn of haar instelling de applicatie kan overnemen en aanpassen. • Operating System: Geeft aan welk operating system op de server en/of de client verondersteld wordt. • Content: Geeft aan wat voor bestanden/standaarden in de applicatie gebruikt worden. Nodig voor distributie en/of voor verdere ontwikkeling. De eerste subtak (Text) bevat formaten die door standaard searchengines geïndexeerd en doorzocht kunnen worden. C. Medische inhoudelijke classificatie Voor de medische inhoudelijke classificatie zal gebruik gemaakt worden van de classificatie van Medical Subject Headings (MeSH). D. Classificatie van COO-typen Doel van deze classificatie is de beschrijving van de lesvorm van de applicatie. Deze classificatie is zoekbaar voor docenten en toonbaar voor studenten. Een applicatie kan meerdere lesvormen bevatten. E. Onderwijskundige classificatie De gekozen onderwijskundige indeling is gebaseerd op de taxonomie van Romiszowski: 1 Kennis verwerven 2 Kennis toepassen 3 Motorische vaardigheden 4 Communicatieve vaardigheden 5 Attitude Per les kan worden aangegeven in hoeverre deze onderdelen voorkomen in de COO les, waarbij een aanwezigheids indicatie kan worden aangegeven middels een 4 puntsschaal: 0 niet aanwezig 1 weinig aanwezig 2 matig aanwezig 3 veel aanwezig Taal De interfacetaal voor SCALE is Engels. Een zoekfunctie naar een les vindt plaats in alle talen tegelijk. Synoniemen kunnen van een taligheid worden voorzien. Lessen draaien in de taal waarin ze gemaakt zijn. Taal instelling heeft betrekking op de taal waarin de les door de administrator is opgenomen. Selectieve toegang van materiaal Het opstarten van bepaald COO kan beperkt worden tot gepaalde groepen. In principe zou dit zo weinig mogelijk moeten gebeuren, bijvoorbeeld alleen als gebruik van COO gekoppeld is aan bepaalde licenties. Deze programma's zouden nog wel door andere gebruikers gevonden moeten kunnen worden via SCALE, maar niet opgestart.

Registratie van gegevens per student gevolgde les Het vastleggen van studentgegevens Behalve lessen moeten ook een minimaal aantal studentgegevens in de centrale database worden opgenomen. Dit is noodzakelijk om bij het gebruik van lessen ook de leerdoelen aan

34

personen te koppelen, waardoor een persoongebonden overzicht van de studenten en gevolgde leerdoelen gemaakt kan worden. A. Upload studentgegevens via koppeling Een onderdeel van het project is het onderzoeken van een koppeling met de diverse studentadministratiesystemen. Een dergelijk koppeling hoeft echter niet synchroon te zijn, maar kan ook periodiek (minstens 1 keer per week) plaatsvinden. Er moet binnen dit project gestreefd worden naar een ‘single logon’ voor studenten. Veelal zal authenticatie plaats vinden door een elektronische leeromgeving. Deze authenticatie zal dan door het LRS.Net moeten worden overgenomen om er voor te zorgen dat de student niet twee keer zijn gebruikersgegevens hoeft in te vullen. Dit vergemakkelijkt het gebruik van het systeem door studenten en kan indien gewenst zelfs onzichtbaar plaatsvinden. In het huidige LRS.Net worden elke nacht alle LUMC student accounts automatisch geupdate en toegevoegd aan de usergroep: LUMC users. B. Via e-mail adres student Het risico hierbij is dat er altijd wel studenten zijn die ‘even’ geen account op dit centrale LRS.Net systeem hebben. Hiervoor heeft het systeem de mogelijkheid om een account door gebruikers zelf aan te laten maken, waardoor gebruikers vrijwel direct toch van het systeem gebruik kunnen maken, zonder tussenkomst van een beheerder. Een goede administratieforganisatorische procedure is hier van groot belang. Registratie gegevens per gevolgde les Overzichtslijsten van gebruikte COO in het curriculum moeten op een aantal niveau's weergegeven kunnen worden waarbij het aantal en de benaming afhankelijk is van de betreffende instituut. Registratie van resultaten, duur, score etc. De student krijgt inzage in zijn eigen studeergedrag en van anderen. De teacher en administrator hebben inzage in alle gebruiksgegevens.

Review systeem Het review systeem maakt het voor studenten mogelijk om door hen gevolgde lessen van een beoordeling en commentaar te laten voorzien. De gemiddelde beoordeling zal binnen 1 dag zichtbaar zijn bij diegene die dit COO kiest. Beoordeling door student op inhoud en bruikbaarheid en vrije tekst Na elk gevolgd COO wordt een kort vragenlijstje aangeboden over de gevolgde les. De student kan een beoordeling geven op een 10-puntsschaal en een vrij tekstveld kan invullen voor opmerkingen. Als er al eerder een review is gegeven, kan de student een nieuwe review geven en de oude overschrijven. Opvragen van beoordelingen De gemiddelde beoordelingen uit de reviews, zullen naast de lessen worden getoond waardoor naast de al bestaande leerdoelen, onderwerpen en type COO van een les ook de kwaliteit (beoordeeld door studenten) bekend is voordat de les wordt gevolgd. Docenten kunnen de

beoordelingen van- en commentaren op lessen inzien.

Advisering ten aanzien van COO op basis van individueel behaalde leerdoelen Voor student en teacher is wenselijk dat er aansluiting is op andere lessen. Er wordt informatie gegeven over andere gebruikers in combinatie met de laatst gevolgde eigen lessen, zoals “Gebruikers die deze les volgden, volgden ook les X" of “Gebruikers die deze les hoog waardeerden, waardeerden ook les Y”. De studiecoach geeft de student, nadat hij een bepaalde COO les doorlopen heeft, een overzicht welke andere aan dit onderwerp gerelateerde COO programma's binnen SCALE aanwezig zijn, met een score die de mate van gerelateerdheid aangeeft. Hier kan een onderverdeling gemaakt worden tussen programma's die nadruk leggen op klacht, diagnose, tractus etc. Op basis van de behaalde score geeft de studiecoach een vrijblijvend advies. Daarbij kan een docent die verantwoordelijk is voor de inhoud van een bepaalde COO les, van tevoren aangegeven in SCALE welke andere COO programma's geschikt zijn om als verdere verdieping te dienen. Dit kan uitgesplitst worden naar de hoogte van de scores (bijv

35

studenten met score 0 -10 moeten COO X gaan volgen en studenten 11-20 moeten COO Y gaan volgen). Bij het advies dat een student krijgt van de studiecoach houdt SCALE rekening met de programma’s die deze student al eerder gevolgd heeft en welke nog niet. De student moet zichzelf kunnen volgen in de tijd. Student kan zien hoe hij zijn tijd heeft verdeeld over de verschillende vakgebieden en curriculumonderdelen van zijn eigen instelling.

COO-registratie Het project wordt uitgevoerd door de vier deelnemende instellingen. Voor het inventariseren en klasseren van COO materiaal is iedere instelling zelf verantwoordelijk evenals voor het toegankelijk maken van zijn eigen COO materiaal. Iedere instelling zorgt ervoor dat dit ontsloten kan worden via een gewone webbrowser.

Er moet een contactpersoon voor de COO-registratie worden opgegeven aan SCALE. Invoeren van COO Invoeren van COO materiaal in de centrale nationale database (LRS.Net) Bij het invoeren van COO materiaal in LRS.Net worden de gegevens van het COO (naam, onderwerp, vakgebied, auteur, taal, etc.) in een centrale database vastgelegd. Iedere instelling behoudt rechten om zijn aandeel decentraal te beheren. Op deze wijze kan vanuit één centraal database systeem, dat via het web benaderbaar is, decentraal materiaal gebruikt worden. Het systeem beschikt over een automatisch controle wat betreft de bereikbaarheid van de webpagina. Indien een webpagina enige tijd niet bereikbaar blijkt, wordt deze automatisch geïnactiveerd en krijgt de betreffende beheerder automatisch bericht per eMail. Dit proces levert een overzicht op van al het COO materiaal van de deelnemende instellingen dat via Internet beschikbaar wordt gesteld, geclassificeerd op basis van medisch onderwerp, COO-type, onderwijskundig aspect, technisch formaat. Alle COO applicaties worden via het huidige LRS.NET over het Internet beschikbaar gesteld (de technische realisatie van de classificatie naar onderwijskundige doelen binnen het LRS.NET wordt pas in tweede instantie uitgevoerd). Omzetten COO materiaal naar internet applicaties Alleen omgezet COO materiaal kan worden opgenomen. De orignele COO-lessen kunnen grofweg in drie verschillende categorieën onderscheiden worden: 1. Web gebaseerde applicaties met of zonder gebruik van diverse plug-in’s (hierbij kan ook gedacht worden aan onderdelen uit BlackBoard). 2. ‘Home made’ programmatuur (Windows executables) 3. Andersoortige applicaties (Beveiligde Cd-rom’s, DOS en Windows 3.x applicaties) Het merendeel van het bestaande materiaal valt in de eerste twee categorieën. De instellingen zijn zelf verantwoordelijk voor de publicatie op ‘open’ web servers, waardoor het ook beschikbaar wordt voor de aan het project participerende instellingen. Zowel de omzetting als de publicatie van COO materiaal op web servers zal gebeuren met bestaande middelen en vindt plaats voor de start van het project. Het is goed voorstelbaar dat een aantal ‘lessen’ (de minderheid) niet geschikt zal zijn voor openbare publicatie vanwege auteurs- of privacy (patiënt gegevens) rechten, maar ook kunnen faculteiten hun lesmateriaal niet publiekelijk beschikbaar willen stellen. Deze zullen dan afgeschermd gepubliceerd worden, waarbij ze op basis van authenticatie- of IP gegevens bruikbaar kunnen zijn voor de aan het project deelnemende instellingen. Typeren van COO

Onderhoud classificatie Voor het onderhoud van de classificaties moet de superadministrator takken en bladeren kunnen toevoegen, wijzigen en verwijderen. Toegang tot onderhoud van classificaties gaat op basis van administratorgroepen. Locale extensies, afgezien van de curriculumboom, worden vooralsnog niet toegestaan (zijn gemeenschappelijk vastgesteld). Het is gewenst om een kopie te kunnen maken van een heel curriculum jaar. Ook externe internet gebruikers kunnen curriculums inzien. Vóór het verwijderen van takken of bladeren die daadwerkelijk bij het klasseren van COO-materiaal gebruikt zijn, moeten de contactpersonen van het betreffende materiaal gewaarschuwd worden.

36

Uitgangspunten •

•

SCALE is een uitbreiding van het bestaande LRS.Net. LRS.Net is geschreven met Microsoft Visual Studio.Net en heeft een SQL server database. COO is geen onderdeel van SCALE, maar is decentraal, op diverse plekken op het internet, ondergebracht.

Kwaliteitseisen Kwaliteitseisen vallen uiteen in eisen met betrekking tot de functionaliteit en kwaliteit.

Eisen die gesteld zullen worden aan de classificatie zijn: • Volledigheid. Al het COO moet in de hierachie van classificaties kunnen worden ondergebracht. Het omvat echter nooit alle leerdoelen van het hele curriculum doordat het niet mogelijk is om met COO alle leerdoelen van het medisch curriculum te bestrijken. • Het aantal te onderscheiden leerdoelen moet niet te groot worden. Het beperkt houden van het aantal verschillende leerdoelen bevordert de bruikbaarheid. • De indeling van de leerdoelen moet enigszins overeenkomen met de frequentie van het voorkomen van die leerdoelen in de COO ‘lessen’. • Leerdoelen moeten uniek zijn en niet kunnen worden ondergebracht in andere takken van de hierachie van classificaties. Technische eis: • De volledige studiecoach moet implementeerbaar zijn met het standaard HTML protocol (3.2, RFC 1866).

Ontwerpbeslissingen Ten aanzien van de leerdoelen hebben we geconstateerd dat deze bij de verschillende faculteiten en ook bij de verschillende COO-lessen op zeer diverse wijzen in meer en mindere mate zijn geëxpliciteerd. Dit heeft geleid tot de beslissing om alle COO-programmatuur te typeren volgens een reeks van kenmerken, zoals die in doelstellingen voorkomen. De hierarchie van leerdoelen zal nu tot uitdrukking komen door de hierarchie die in een vijftal classificaties is aangebracht.

Geraadpleegde documentatie Dit functioneel ontwerp zal aanvullingen geven op eerdere functionaliteit zoals die omschreven is in de Manual Lesson Registration System.NET (versie 19 april 2005, zie bijlage). Verdere informatie voor het functioneel ontwerp zijn terug te vinden in het controlling document van dit project en de notulen voor projecten klankboard groep bijeenkomst (terug te vinden via de website: http://www.lumc.nl/scale )

Relaties SCALE Integratie LRS.Net met bestaande ICT infrastructuur SCALE kan aan het einde van het project dienen als portal voor het COO materiaal van de aan het project deelnemende instellingen. SCALE moet geïntegreerd worden in de ICT infrastructuur van de deelnemende instellingen. De studenten kunnen vanuit een elektronische leeromgeving (zoals bijv. Blackboard ® ) een les binnen LRS.Net openen, zonder dat de student LRS.Net ziet, maar met behoud van registratie van lesgebruik met de daarbij behorende leerdoelen. LRS.Net is beschikbaar voor alle studenten en docenten van de aan het project deelnemende instellingen, liefst op basis van een ‘single logon’.

Omgeving In dit hoofdstuk wordt een korte beschrijving van de werkwijze en processen ten aanzien van SCALE bij de aan het project deelnemende instellingen gegeven. Aangegeven wordt welke functies door SCALE worden ondersteund.

37

Ten behoeve van het onderwijs kunnen docenten en blokcoördinatoren geïnformeerd worden over de mogelijkheden die LRS.Net biedt en de verzameling COO die online wordt aangeboden. Dit kan zowel plenair als individueel in de vorm van een demonstratie. COO kan geselecteerd worden aan de hand van de leerdoelen die de docenten nodig achten. Het COO kan worden geroosterd in het onderwijs of als aanvullend lesmateriaal worden aangeboden. De afspraken met het LUMC op het gebied van support / backup / beschikbaarstelling moeten worden vastgelegd in een Service Level Agreement (SLA) tussen LUMC en de andere instellingen. De effecten van SCALE op de deelnemende Medische Faculteiten is hieronder volgens verwachting per faculteit omschreven.

Leiden Effecten op: • De voortgangstoets

Rotterdam Effecten op: • Elektronische zelfstudieopdrachten • Vrije zelfstudie • Voorkennistoetsen • Koppeling met CIS Op dit moment wordt er in de computerzalen van het Erasmus MC een lokale applicatie (COO menu) gebruikt. Op het moment dat het grootste deel van het COO webbased is gemaakt, kan SCALE voor het Erasmus MC de centrale ingang worden voor al het COO materiaal. COO lessen moeten in de toekomst zowel direct in SCALE opstartbaar moeten zijn als indirect via de elektronische leeromgeving Blackboard. In Blackboard zouden de studenten op een link naar een COO-programma kunnen klikken waardoor ze op de achtergrond via SCALE het programma opstarten. Er hoeft dan niet meer ingelogd te worden. Er zou een algemeen, niet instellingsgebonden URL moeten komen voor SCALE. Daarnaast zou er via een eigen URL een instellingsgebonden ingang naar SCALE moeten zijn (bijv. coo.erasmusmc.nl), waarbij per instelling de eigen huisstijl kan worden gebruikt.

Utrecht Effecten op: • Portfolio • Studieloopbaanbegeleiding • Curriculumdatabase Voor een goede inpassing van het project zou dit in Utrecht gekoppeld moeten worden aan de reeds bestaande studiereflectie, portfolio en studieloopbaanbegeleidings onderwijsonderdelen en afgestemd moeten worden op de curriculumdatabase.

Nijmegen Effecten op: • Aanbod aan keuze COO voor docenten • Een aanvulling voor studenten op COO buiten het reguliere curriculum

Informatieprocesmodel SCALE De werkwijze binnen het in dit functionele ontwerp beschreven systeem wordt aan de hand van data flow diagrammen (DFD’s) beschreven.

Symbolen De volgende symbolen worden gebruikt:

38

•

Afsluitprogramma

Hiermee wordt het begin of het einde aangeduid van een programmastroom binnen een diagram.

Informatie Proces

•

Een willekeurige bewerkingsfunctie

•

Gegevensstroom

Data Flow Diagram SCALE Dit contextdiagram geeft een algemene systeembeschrijving. Het schetst de interactie tussen het systeem en de omgeving van het systeem. SCALE URL

LRS

COO Gebruikersgegevens

Advies

Aanvraag selectie + Identificatie

Gebruiker

Figuur 4-1: DFD-niveau 0, Context SCALE

DFD niveau 1 De Data Flow Diagrammen op niveau 1 geven de hoofdprocessen aan van de drie gebruikersgroepen van SCALE.

Student Aanmelden

Advisering COO

Aanmelden

Selectie COO

Draaien COO

Registratie resultaat (incl. groepje)

Review

Afmelden

4-2: DFS-niveau 1, Student

39

Teacher Aanmelden

Selectie COO

Draaien COO

Aanmelden

Selectie COO

Selectie studenten groep

Overzicht resultaten

Aanmelden

Selectie studenten groep

Selectie COO

Overzicht resultaten

Figuur 4-3: DFD-niveau 1, Teacher

Administrator

Aanmelden

Onderhoud COO

Afmelden

Onderhoud account

Onderhoud lesgroep

Onderhoud contactpersoon

Figuur 4-4: DFD-niveau 1, Administrator

40

Superadministrator Aanmelden

Systeemfouten opsporen

Afmelden

Onderhoud features

Onderhoud classificatie

Figuur 4-5: DFD-niveau 1, Superadministrator

DFD niveau 2 De Data Flow Diagrammen op niveau 2 geven de deelprocessen aan.

41

Administrator Aanmelden

Onderhoud COO

Registreren COO

Klasseren COO

Afmelden

Typeren COO

COO toegangs bevoegdheid instellen

Mutatie COO Selectie COO Verwijderen COO

Aanmelden

Onderhoud account

Aanmaken account

Selectie account

Afmelden

Mutatie account

Verwijderen account

Aanmelden

Onderhoud lesgroep

Aanmaken lesgroep

Selectie lesgroep

Afmelden

Mutatie lesgroep

Verwijderen lesgroep

Aanmelden

Onderhoud contactpersoon

Aanmaken contactpersoon Selectie contactpersoon

Afmelden

Mutatie contactpersoon Verwijderen contactpersoon

Figuur 4-6: DFD-niveau 2, Administrator

Logisch gegevensmodel Entity Relationship Diagram (ERD) < Hier nieuw diagram invoegen nadat SCALE in database is geimplementeerd >

42

Beschrijving per tabel < Een beschrijving per tabel invoegen daar waar relevant voor SCALE >

Relatiebeschrijvingen < Koppelingen (relaties tussen tabellen) invoegen voor SCALE >

Wijzigingen datamodel bestaande systeem < Een opsomming van de in het datamodel van LRS.Net door te voeren wijzigingen, inclusief een argumentatie. De uitwerking vindt plaats in hoofdstuk “Consequenties bestaande systemen” >

Consequenties van de wijzigingen op het datamodel bestaande systeem < Een opsomming van alle consequenties van de wijzigingen van het datamodel van LRS.Net; inclusief een argumentatie. De uitwerking vindt plaats in hoofdstuk “Consequenties bestaande systemen” >

Organisatie regels < Beschrijf hier de organisatie regels die gelden voor het logische gegevensmodel. Voorbeeld: In Rotterdam kan een mailadres eindigend op @student.eur.nl automatisch worden herkend als een Erasmus-student account >

Statusovergangen voor het logisch gegevensmodel < Indien gewenst kan hier de verschillende statusovergangen voor het logische gegevensmodel beschreven worden. Om de overgangen vast te leggen kan gebruik gemaakt worden van “statusovergang diagrammen”, eventueel aangevuld met nadere tekstuele toelichtingen. >

Constraints < In dit hoofdstuk worden de controles beschreven, die bij de uitvoering van eerdergenoemde functies moeten worden uitgevoerd. Hierbij wordt onderscheid gemaakt in de condities van uitvoering, de elementaire controles van een rubriek en de samenhangcontroles (tussen rubrieken onderling). Aan iedere constraint wordt een code toegekend, die voor de verwijzingen in dit document wordt gebruikt. Per constraint wordt voorts een beschrijving en een specificatie (in gestructureerde taal) opgenomen.>

Autorisatiemodel Er zijn autorisatie matrices opgenomen in het autorisatiemodel waarin voor de verschillende gebruikersgroepen wordt weergegeven welke rechten aan hen zijn toegekend

Gebruikersgroepen De volgende gebruikersgroepen worden onderkend: • Groep A = Student • Groep B = Docent • Groep C = Administrator • Groep D = Superadministrator

Rechten De volgende rechten worden toegekend: • C = Create • R = Read • U = Update • D = Delete

43

Matrix bevoegdheden ten aanzien van het gebruik van actuele waarden Groep B

Groep C

A

Groep A

Tabellen

CRUD

CRUD

CRUD

Matrix bevoegdheden ten aanzien van het gebruik van metagegevens Groep C

CRUD

CRUD

CRUD

Groep D

Groep B

Domeinen Tabellen Kolommen Sleutels (sorteringen/ indices) Autorisaties op tabellen Nummeruitgifte Tabel triggers Kolom triggers Statistieken database/ systeembelasting

Groep A

Metagegevens

CRUD

Matrix processen en tabellen (CRUD matrix) In de CRUD matrix wordt van ieder informatieproces weergegeven welke tabellen het proces gebruikt en wat de aard is van het gebruik: create, read, update en/ of delete.

Proces 1.3

CRUD

CRUD

CRUD

Proces 1.4

Proces 1.2

Meta: Domeinen Meta: Tabellen Meta: Kolommen Meta: Sleutels (sorteringen/ indices) Meta: Autorisaties op tabellen Meta: Nummeruitgifte Meta: Tabel triggers Meta: Kolom triggers Meta: Statistieken database/ systeembelasting Tabel X Tabel Y

Proces 1.1

Tabellen en/ of metagegevens

CRUD

Proces 1.5

Op de horizontale as staan de processen uit het informatieprocesmodel, op de verticale as de verschillende tabellen uit het logisch gegevensmodel.

CRUD

44

Generieke werking functies en interfaces (styleguide) De styleguide dient ervoor om de hoofdlijnen (de belangrijke onderdelen en hun onderlinge samenhang) van de gebruikersdialoog voor de SCALE applicatie te beschrijven, zodat er vanuit de verschillende in detail beschreven functies en interfaces aan gerefereerd kan worden. De schermen die in dit hoofdstuk zijn opgenomen, dienen als voorbeeld en geven een indicatie hoe de uiteindelijk schermen van de verschillende functies zullen worden.

Aanmelden bij het systeem < Beschrijf hoe de gebruiker(s en/ of –groepen) toegang krijgen tot het systeem. Vermeld eventuele technische instellingen (zoals: register settings, “ini” files en/ of usergroups) die nodig zijn om het één en ander correct te laten werken. Als het van toepassing is, neem dan ook afdrukken op van de feitelijke scherm dialoog. >

Applicatievenster < Beschrijf welk scherm getoond wordt, als het aanmelden is geslaagd. Beschrijf de verschillende elementen van het scherm, uitgewerkt voor: Titelbalk, Menu, Werkbalk, Werkblad, Statusregel en Muiscursor. >

Soorten gegevensverzamelingen < Binnen de applicatie wordt onderscheid gemaakt tussen de volgende soorten gegevensverzamelingen, verschillende detail beschrijvingen van dit ontwerp verwijzen hierna : • Eenvoudige gegevensverzamelingen • Uitgebreide gegevensverzamelingen • Complexe gegevensverzamelingen. >

Algemene werking functies < In deze paragraaf wordt een aantal standaard aspecten beschreven over de algemene werking van de functies binnen de applicatie. In het algemeen zullen de functies binnen de applicatie de twee eerste componenten samen nemen. Hierdoor zullen veel functie uit de volgende twee schermen bestaan:

• •

Selectiescherm (= Selectiecriteria + Selectielijst) Detailscherm. >

Standaard functies < Voor het uitvoeren van handelingen op de verschillende gegevensverzamelingen is per gegevensverzameling een standaard functie gedefinieerd.

• •

Onderhoud op een eenvoudige gegevensverzameling Onderhoud op een complexe gegevensverzameling >

Aanroepen zoekfuncties Zoals eerder beschreven, kan de gebruiker hulp krijgen bij het invullen van een veld met behulp van een zoekfunctie die gestart kan worden met de 'zoek op' -knop (verrekijkertje) rechts op de werkbalk. Een zoekfunctie is een soort selectiescherm.

Algemene werking documenten en overzichten In deze paragraaf wordt een aantal standaard aspecten beschreven over de algemene werking van de documenten en overzichten binnen de applicatie.

Detail functiebeschrijvingen <Werk na de omschrijving van de hoofdstructuur de functionaliteit van elk onderdeel in detail uit: Geeft de applicatie goede defaultwaarden? Geeft ze duidelijke foutmeldingen met suggesties voor een oplossing? Geeft ze de gebruiker een kans om acties ongedaan te maken? Gaat ze soepel om met invoer of moet de gebruiker aan arbitraire eisen voldoen? >

45

De technische specificaties worden hier nader beschreven:

Functiebeschrijving Algemeen Korte omschrijving en doel van de functie. De kenmerken van deze functie zijn: Type Interactief/ Batch/ Ondersteunend Karakter Ad hoc/ Repeterend, Frontoffice/ Backoffice Frequentie Dagelijks/ wekelijks/ maandelijks; aantal per … Piekverwerkingen Moment(en) van piekverwerking/ N.v.t. Classificatie Basis/ Comfort/ Luxe

Condities van uitvoering Alle condities om deze functie te mogen/ kunnen uitvoeren.

Invoer Alle invoer parameters en velden. Verwijzing naar het interface scherm mag. Dit wordt beschreven in hoofdstuk “Detail interface beschrijvingen”.

Controles/ constraints De volgende constraints zijn relevant: de elementaire- en samenhang-controles, die van toepassing zijn op de uitvoering van deze functie. Bestaat uit een verwijzing naar hoofdstuk “Constraints”; gevolgd door het typeafhandeling (Waarschuwing c.q. Blokkade). Dit wordt in de vorm van een tabel weergegeven

Specificaties verwerking Een beschrijving van de verschillende verwerkingsstappen van de functie, eventueel onderbouwd met beslissingstabellen en tekstuele uitleg en/ of voorbeelden. Een en ander beredeneerd vanaf het moment dat de invoer is gevalideerd

Uitvoer Een opsomming van de uitvoerproducten van de functie inclusief een verwijzing naar een interface (scherm, document/ overzicht of bestand), zoals opgenomen in hoofdstuk “Detail interface beschrijvingen”. Tevens de opsomming van de mogelijke sorteringen van de gegevens.

Relaties met andere functies Relaties met andere functies en/ of modules (roept aan/ wordt aangeroepen door); limitatieve opsomming van relaties

Speciale zaken Opsomming van speciale (eventueel op de achtergrond uitgevoerde) acties die bij de functie horen.

Functiebeschrijving Als .

Detail interfacebeschrijvingen In dit hoofdstuk worden specifieke aanvullingen op de styleguide voor de interfaces zoals deze zich presenteren aan de gebruiker beschreven. Voor de interactieve functies zijn dit de GUI’s voor eventuele startschermen, browserschermen en detailschermen. Daarnaast worden ook de andere interfaces beschreven; denk hierbij aan de documenten en overzichten, maar ook aan bestanden in geval van de uitwisseling van gegevens.

GUI beschrijvingen < Een beschrijving van de schermdialoog, zoals deze zich voor de gebruiker afspeelt bij (zoek) functies. Indien de dialoog afwijkend is van de standaard navigatie (styleguide), dan wordt een verloopschema van de dialoog opgenomen. Per scherm een schermafdruk inclusief een gedetailleerde beschrijving van de specifieke scherm-, velden knopkenmerken.

46

Denk hierbij aan sprongmogelijkheden (via menu/ button/ shortcut), defaultwaarden velden en buttons en enabling/ disabling. >

Documenten en overzichten < Beschrijving van het specifieke document, overzichten rubriekkenmerken >

Bestandsinterfaces < Een gedetailleerde beschrijving van de bestanden veldkenmerken. >

Menu interface < Een korte beschrijving van de werking van het menu, hoe deze eruit ziet. Ook of dit een statisch of dynamisch menu is. Of deze alleen via het toetsenbord of ook via de muis te besturen moet zijn. Knoppenbalken, sneltoetsen. >

Koppelingen met andere pakketten

GUI Scherm(en) <printscreen scherm. >.

Beschrijving van de velden Veldnaam

DB-veld

Type

Read only

Omschrijving

Muis en toetsenbord functionaliteit Wat moet met de muis en wat met het toetsenbord ondersteund worden.

Shoot en point functionaliteit Op welke velden is shoot en point functionaliteit nodig. Dit wil zeggen: twee lijsten met gegevens waarvan onderling records uitgewisseld kunnen worden. Ook aangeven naar welke gegevenssoort deze moet.

Help functionaliteit Is er help functionaliteit nodig. Is dit nodig per scherm of per veld.

Messages en berichten

GUI Zie GUI functie A

Configuratie productie omgeving Het doel van dit hoofdstuk is om ervoor te zorgen dat afwijkingen in de standaard configuratie voor de productie omgeving bekend worden. De effecten van de in dit document beschreven wijzingen en/ of aanvullingen van het systeem, kunnen invloed hebben op de configuratie van het systeem tot nu toe. < Bijvoorbeeld: De lange levertijd van apparatuur en/ of programmatuur. • Het beschikbaar hebben van de configuratie tijdens de ontwikkelen de • testfase.>

Consequenties bestaande systemen In dit hoofdstuk worden de consequenties voor het bestaande systeem beschreven. Hierbij wordt onderscheid gemaakt in de gevolgen voor de standaards, de functies en het gegevensmodel. De hier genoemde consequenties nader uitgewerkt in de bestaande systeemdocumentatie.

47

Standaards Functies Gegevensmodel LRS.Net Overzicht versie 19 april 2005:

48

Interfaces LRS.Net Zie Manual LRS.Net (versie 19 april 2005).

Aandachtspunten vervolgtraject De relevante aandachtspunten voor het vervolgtraject worden hier beschreven. Hierbij wordt onderscheid gemaakt tussen de fases: test, realisatie, implementatie en beheer en onderhoud.

Testfase In de periode september t/m november komen er veel nieuwe versies van LRS/SCALE beschikbaar. Alle deelnemende instellingen zullen de nieuwe functionaliteit testen. Afspraak hierover is dat iedereen naar nieuwe versies probeert te kijken op korte termijn en het commentaar terugmailt aan de programmeur. Als je geen tijd hebt op dat moment een versie te testen geef je dat direct aan.

Realisatiefase Implementatiefase < Hoe stap je over naar SCALE en hoe doe je dat per faculteit. Hoe wordt classeren COO materiaal geregeld? >

Beheer- en onderhoudfase

Crossreferences Crossreference van informatieproces(sen) naar functie(s) Proces (nummer en naam)

Functie(s)

Crossreference van buffer(s) naar tabel(len) in de database Buffer (uit de DFD’s)

Database tabel(len)

Legenda COO DFD DLO FO FS GUI LRS.Net SCALE TO

Computer Ondersteunend Onderwijs Data Flow Diagram Digitale Leer Omgeving Functioneel ontwerp Functionele Specificaties Grafische userinterface Lesson Registration System.Net Studie Coach and Learning Environment Technisch Ontwerp

49

Study Coach And Learning Environment

Recommend Documents