Bijlage 4 Programma van Eisen Zuyd kiest bewust voor het op sommige aspecten vrij specifiek uitwerken van functionele en niet-functionele eisen. De reden hiervan is dat de verwachte Inschrijvers de noodzakelijke processen allemaal kunnen mogelijk maken met hun kern-lms. Het komt echter aan op de uitvoering, op de wijze waarop human-interaction design plaats vindt. In onderstaand overzicht worden ten behoeve van de leesbaarheid alleen de termen gebruikers, student, docent en functioneel beheerder genoemd. In werkelijkheid kan een docent, bijvoorbeeld, meerdere rollen hebben die bepaalde specifieke functies binnen het kern-lms kunnen uitvoeren. Hierover wordt bij de inrichting van het kern-lms beslist. De functionele eisen worden binnen het kern-lms uitgevoerd, of via applicaties van derden die volledig geïntegreerd zijn met het kern-lms (gegevensintegratie, systeemintegratie, visuele integratie). Dus niet via een workaround. Ter illustratie: het is uiteraard mogelijk om mededelingen uit een ruimte te kopiëren en in een emailbericht te plakken om dit bericht vervolgens te sturen via Outlook. Een dergelijke workaround is echter niet de bedoeling van onderstaande eisen. Veel functionele eisen gezamenlijk vormen echter een bepaald werkproces (zoals het organiseren van peer feedback). Als er een strijdigheid is tussen niet-functionele eisen en functionele eisen, dan prevaleren de functionele eisen. Niet-functionele eisen Prijs en facturatie 1. Zuyd geeft een minimale licentieomvang af van 9.000 gebruikers per kwartaal. Ongeacht het gebruik/werkelijk aantal actieve gebruikers. 2. Het aantal licenties wordt gebaseerd op het aantal gebruikers (uitsluitend studenten (voltijd plus deeltijd), medewerkers, deelnemers contractactiviteiten) dat binnen één kwartaal tenminste tweemaal is ingelogd voor de gebruiksduur van 5 aaneengesloten minuten. 3. Bovenstaande opsomming is limitatief, o.a. gebruikers die via een gastaccount inloggen tellen niet mee in de bepaling van de licentieprijs. Het is Zuyd toegestaan om gastaccounts te verstrekken aan niet-studenten (inclusief deelnemers contractactiviteiten) en aan nietmedewerkers, maar aan derden die bijvoorbeeld eenmalig fungeren als gastdocent of die werkzaam zijn bij een stagebedrijf en uit hoofde van deze werkzaamheden toegang nodig hebben tot het kern-lms. 4. De licentieprijs die de inschrijver aanbiedt betreft een all-in jaartarief per licentie. Er kan, na implementatie, niet meer dan het aantal afgenomen licenties vermenigvuldigd met de licentieprijs in rekening worden gebracht. 5. Uitzondering hierop vormen kosten die de Opdrachtnemer moet maken door toedoen van Zuyd. Voor dergelijke opdrachten wordt bij inschrijving een uurtarief opgegeven. Kosten in dit kader worden uitsluitend verrekend middels een openboek calculatie. 6. Het plafondbedrag ( 1.000.000 ex BTW) is gebaseerd op de implementatiekosten ( max 100.000 ex BTW), de licentiekosten bij 16.500 gebruikers per jaar gedurende 3 jaar, ongeacht opslagcapaciteit en dataverkeer. 7. De licentiekosten per kwartaal worden bepaald door de jaarlicentieprijs te delen door 4 kwartalen. Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 1 van 8
8. Facturatie vindt per kwartaal plaats. Verrekening vindt plaats op basis van het minimaal aantal licenties (9.000 stuks) plus het aantal additioneel aantal licenties dat het voorgaande kwartaal is afgenomen. 9. Een licentie (gebruiker) kan automatisch aan een door Zuyd aangegeven kostendrager worden toekend. 10. Betaling van de Implementatiekosten geschiedt in drie termijnen: 30% bij opdrachtverstrekking na de eerste proof of concept, 60% na het voldoende afronden van de laatste acceptatietest en 10% één maand na de livegang op 20 augustus 2018 bij gebleken stabiliteit van het systeem c.f. de uptime-garantie van 99,6%. Aangepaste eisen o.b.v. nota van inlichtingen: 1. Zuyd neemt conform nota van inlichtingen een campuslicentie af. 2. Zuyd betaalt de campuslicentie per kwartaal. Het kwartaalbedrag wordt berekend door het jaarlicentiebedrag te delen door 4. Facturatie voor het betreffende kwartaal vindt aan het begin van het kwartaal plaatst. 3. Het eerste kwartaal start op 1 September 2018 en eindigt op 30 november 2018. 4. De opdrachtnemer is gerechtigd de licentiekosten vanaf de volledige ingebruikname, cf. aanbestedingsplanning per 20 augustus 2018, additioneel in rekening te brengen in kwartaal 1. 5. Voor de periode 1 maart 2018 tot 20 augustus 2018 is de opdrachtnemer onder voorbehoud van een succesvolle acceptatietest gerecht om maximaal 7.500 exclusief BTW in rekening te brengen voor het gebruik en de inrichting van het Kern-LMS. 6. De campuslicentie betreft een all-in prijs. Het is niet mogelijk om Zuyd andere kosten (zoals service, onderhoud of storage) in rekening te brengen dan de licentieprijs waarmee de opdrachtnemer heeft ingeschreven. 7. De plafondtarieven zijn ongewijzigd gehandhaafd op 100.000 exclusief BTW voor het implementatietraject en 300.000 exclusief BTW per jaar aan licentiekosten (startend in kwartaal 1). 8. Betaling van de Implementatiekosten geschiedt in drie termijnen: 30% bij opdrachtverstrekking na de eerste proof of concept, 60% na het voldoende afronden van de laatste acceptatietest en 10% één maand na de livegang op 20 augustus 2018 bij gebleken stabiliteit van het systeem c.f. de uptime-garantie van 99,6%. Deskundigheid personeel 11. De bij de implementatie betrokken consultants van de Opdrachtnemer beschikken over aantoonbare kennis en ervaring met ICT binnen het hoger onderwijs. Technische eisen 12. Het kern-lms ondersteunt minimaal de volgende door SURF geadviseerde standaarden/specificaties: SAML/VOOT, LIS, OOAPI, XAPI, LTI. Deze standaarden/specificaties zorgen voor het kunnen uitwisselen van data en het kunnen integreren van functionaliteiten. NVI vraag 24 13. Het kern-lms kan worden gekoppeld aan het studentadministratiesysteem van Zuyd, aan het IDM-systeem van Zuyd en het kan worden geïntegreerd met het systeem voor originaliteitscheck van Zuyd (Ephorus). 14. Het kern-lms is Smartphone Apps OAUTH 2.0 compliant. NVI vraag 25, 54 15. Eventueel database verkeer dat niet via https gaat, verloopt door VPN tunnel (IPSEC) 16. Voldoet aan ISO 27001, NVI vraag 5 en 53. 17. Client verbindingen via HTTPS TLS 1.2 18. 100 % service based Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 2 van 8
19. JSON of SOAP interfaces 20. Een open en goed gedocumenteerde plugin interface die beschikbaar is voor derden. 21. Op het gebied van toegankelijkheid worden de volgende specificaties ondersteund: EN 301 549 en WCAG 2.0. NVI vraag 69 22. Ten behoeve van de uitwisselbaarheid van het digitale portfolio wordt de NEN NTA 2035 standaard ondersteund. NVI vraag 26. 23. Functioneel beheerders zijn in staat om de configuratie van het kern-lms zelfstandig aan te passen. Dat betekent onder meer dat zij in staat zijn te bepalen welke bestandstypen geupload kunnen worden en wat de bestandsgrootte van te uploaden bestanden is. Het kern-lms stelt hier geen beperkingen aan. Ook kunnen zij instellen welke gebruikers welk type notificaties ontvangen. NVI vraag 27 24. In geval van twijfel over de betrouwbaarheid van de uptimegarantie zoals vermeld in de management rapportage behoudt Zuyd zich het recht voor om de bereikbaarheid van het LMS-systeem te monitoren, bijvoorbeeld via een onafhankelijke performance test. De Opdrachtnemer verleent hier alle noodzakelijke medewerking aan. Indien blijkt dat de twijfel gegrond is, zij de kosten van de performance test voor rekening van de Opdrachtnemer. NVI Vraag 6 Accessibility en security 25. Het kern-lms is SAML 2.0 compliant. Om gebruik te maken van de DLO en van de functies die met de DLO zijn gekoppeld, krijgen gebruikers geautoriseerde toegang via SURFConext. 26. Studenten en personen met een gastaccount zijn niet in staat om artefacten te creëren waarin een script is verwerkt (zoals een video van YouTube die via iframe wordt geembed). 27. Opdrachtnemer draagt zorg voor dagelijkse back-up en is in staat onderdelen van de database van het kern-lms op verzoek van de applicatiemanager te restoren (en niet de volledige inhoud van de database). 28. Gebruikers kunnen binnen de DLO verschillende rollen met bijbehorende rechten hebben. 29. Het niveau waarop een gebruiker toegang heeft tot de DLO en ruimtes binnen de DLO wordt bepaald op basis van de inschrijving in studentinformatiesysteem (Osiris). Functioneel beheerders kunnen het toegangsniveau aanpassen. 30. Opdrachtgever heeft toegang tot de data in de database van het kern-lms ten behoeve van het toepassen van learning analytics. Beschikbaarheid 31. 7 dagen per week, 24 uur per dag 32. Een verstoring binnen de categorie 1 of 2 mag niet langer duren dan 2 uur en verstoring binnen de categorie 3 en 4 niet langer dan 4 uur. Zie bijlage 7. 33. Gegarandeerde beschikbaarheid van 99,6 % op jaarbasis op werkdagen tussen 7 en 22 uur. 34. Beschikbaarheid tweedelijns helpdesk: op werkdagen tussen 7.30 en 19 uur (CET). NVI vraag 8 35. Het aanmaken van ruimtes via de DLO gebeurt zo veel mogelijk automatisch, op basis van de inrichting van studentinformatiesysteem (Osiris). Daarnaast kunnen ook door functioneel beheerders handmatig ruimtes worden aangemaakt, voor zo ver deze geen equivalent in studentinformatiesysteem (Osiris) hebben. 36. De inrichting van ruimtes gebeurt op basis van templates die de eigenaren van ruimtes kunnen aanpassen. Deze templates bevatten ook functionaliteiten die voor leren kunnen worden gebruikt. Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 3 van 8
37. Gebruikersaccounts moeten gereactiveerd kunnen worden als gebruikers zich opnieuw inschrijven voor een cursus, nadat men een tijd uitgeschreven is geweest (met name van belang voor Zuyd Professional). 38. De toegang tot een ruimte wordt verkregen: o o geautomatiseerd via inschrijvingen in studentinformatiesysteem (Osiris) door handmatige actie functioneel beheerders, voor zover dit niet via studentinformatiesysteem (Osiris) is geregeld. Onderhoud 39. Alleen na overleg met de Opdrachtgever. NVI vraag 28 40. Onderhoudswerkzaamheden worden aangekondigd en zijn vermeld ten tijde van het onderhoud binnen de applicatie. NVI vraag 29 41. Het moet mogelijk zijn de inhoud van het bestaande kern-lms te importeren in het kern- LMS dat wordt aanbesteed, waarna deze inhoud gelezen, aangepast en op onderdelen verwijderd kan worden. Onder inhoud verstaan we items, subitems, de structuur van een ruimte en artefacten die door een docent aan (sub)items zijn toegevoegd. NVI vraag 7 Usability en portability 42. Het kern-lms kan volledig worden gebruikt op mobiele devices zoals een smartphone of tablet. De applicatie geeft veilig toegang tot data. Studenten hoeven niet telkens in te loggen, en kunnen notificaties gepusht krijgen zonder dat de applicatie geopend is. Toepassingen die door andere gebruikers zoals een functioneel beheerder of docentworden gebruikt, hoeven niet persé via een mobiel device te worden gebruikt. Wel zal het kern-lms volledig responsive moeten zijn (dat wil zeggen dat het kern-lms zichzelf aanpast aan de schermgrootte). 43. Gebruikers hoeven geen plug-ins of uitvoerbare bestanden te installeren om bepaalde functionaliteiten te kunnen gebruiken. 44. Het is mogelijk om bepaalde functionaliteiten op het niveau van een opleiding en/of ruimte te activeren of te de-activeren (denk aan het digitale portfolio). 45. Er is sprake van een consequent gebruik van termen, knoppen en pictogrammen. 46. De look and feel van het kern-lms is aangepast aan de huisstijl van Zuyd. NVI vraag 30, 56 47. Een proces binnen het kern-lms kan maar op één manier worden uitgevoerd (bijvoorbeeld het aanmaken van een opdracht of formatieve toets). Dat wil zeggen: functies zijn maar eenmaal in het menu ondergebracht. 48. Het systeem geeft feedback die de gebruiker zelfstandig in staat stelt vergissingen zelfstandig te herstellen. Functionele eisen Organiseren van leren 49. Gebruikers kunnen kiezen tussen een Nederlandstalige en Engelstalige interface (inclusief helpfunctie). 50. De gebruiker moet binnen het kern-lms beschikken over een persoonlijke landingspagina waar hij of zij in één oogopslag ziet welke taken hij/zij binnen verschillende ruimtes moet afhandelen, en welke nieuwe informatie er voor hem/haar beschikbaar is (zoals beoordelingen). 51. De gebruiker moet binnen een ruimte beschikken over een persoonlijke landingspagina waar hij of zij in één oogopslag ziet welke taken hij of zij binnen de ruimte moet afhandelen en welke nieuwe informatie er voor hem/haar beschikbaar is (zoals beoordelingen). Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 4 van 8
52. De gebruiker moet informatie kunnen zoeken binnen alle ruimtes en fora, waar hij of zij toegang toe heeft. Communiceren 53. Een docent moet mededelingen mbt de ruimte kunnen publiceren. 54. Een docent moet een groep studenten kunnen selecteren en hen een bericht sturen. 55. Een gebruiker moet notificaties kunnen ontvangen bij wijzigingen binnen de DLO. 56. Een gebruiker moet zelf kunnen aangeven in welke frequentie hij deze notificaties wil ontvangen (minimale opties: geen, onmiddellijk, dagelijks). 57. Een gebruiker moet zelf kunnen aangeven of hij deze notificaties ook gepusht wil krijgen naar zijn mobiele device. NVI vraag 31, 27, 55 58. Een docent moet dringende notificaties altijd direct kunnen versturen, ook al heeft een student een andere voorkeur aangegeven. Samenwerken 59. Een gebruiker moet eenmalig zijn profielgegevens (minimaal: foto, e-mailadres en mobiel nummer) kunnen invoeren en deze in alle ruimten kunnen gebruiken. 60. Een gebruiker moet aan kunnen geven wie welke profielgegevens over hem/haar mag bekijken (bijv. zelf, iedereen, gebruikers in dezelfde ruimte). 61. Een docent moet opdrachten kunnen gebruiken waarbij studenten elkaar kwantitatieve en kwalitatieve feedback kunnen geven. 62. Een docent moet studenten binnen een ruimte automatisch aan elkaar kunnen koppelen voor peer feedback, maar dit ook handmatig kunnen corrigeren. 63. De feedback moet zowel open kunnen worden ingevoerd alsook op basis van vooraf gedefinieerde eigenschappen zoals veel gegeven feedback- met daarin te stellen minimum- en maximumscores. 64. Docent moet kunnen aangeven wie feedback geeft en hoeveel personen er minimaal feedback moeten geven. 65. Toekennen van feedback aan een student moet geautomatiseerd alsook handmatig kunnen. 66. Een docent moet het proces van peer feedback kunnen monitoren. 67. Een student moet andere gebruikers (inclusief anderen buiten Zuyd, zoals opdrachtgevers) kunnen uitnodigen om feedback te geven op een artefact dat hij of zij heeft gemaakt. 68. Een gebruiker moet een portfolio kunnen samenstellen op basis van verschillende artefacten dat zicht biedt op de persoonlijke ontwikkeling. 69. Een gebruiker moet dit portfolio op een veilige manier kunnen delen met anderen (ook buiten Zuyd), waarbij deze anderen feedback kunnen geven op dit portfolio. 70. Een gebruiker moet artefacten kunnen delen met anderen (ook buiten Zuyd), waarbij deze anderen feedback kunnen geven op dit artefact of het artefact kunnen bewerken als de gebruiker daar toestemming voor geeft. Dit kan via een gedeelde link of via uitnodiging via email. De gebruiker kan daarbij aangeven of de ander het artefact mag bekijken en/of becommentariëren en/of bewerken. NVI vraag 33: Deze eis hebben we geherformuleerd: Een gebruiker moet artefacten kunnen delen met anderen (ook buiten Zuyd), waarbij deze anderen feedback kunnen geven op dit artefact of het artefact kunnen bewerken als de gebruiker daar toestemming voor geeft. 71. Een docent moet binnen een ruimte subruimtes kunnen inrichten waar hij of zij groepen studenten en eventueel externen buiten Zuyd- toegang toe geeft om met elkaar samen te werken. 72. Een docent (met een specifieke rol binnen het kern-lms) moet externen buiten Zuyd toegang kunnen geven tot ruimtes, zonder dat zij een account hebben bij Zuyd. Dit kan bijvoorbeeld via een gedeelde link of via uitnodiging via email. De docent kan daarbij Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 5 van 8
aangeven of de ander bijdragen alleen mag bekijken en/of becommentariëren en/of bewerken en/of zelf artefacten mag creëren en/of uploaden. NVI vraag 34,35 73. Een externe moet activiteiten kunnen uitvoeren binnen een ruimte, indien een docent hem of haar daar toestemming toe heeft gegeven. Onder activiteiten verstaan we in dit geval: bijdragen bekijken en/of becommentariëren en/of bewerken en/of zelf artefacten mag creëren en/of uploaden. Om een activiteit uit te kunnen voeren, moet de externe zijn of haar naam en mailadres achterlaten. NVI vraag 36, 34, 58 74. Een docent studenten tijd- en plaatsonafhankelijk van gedachten kunnen laten wisselen. Daarbij moet de docent een onderscheid kunnen maken tussen het geven van beknopte bijdragen of het schrijven van meer reflectieve bijdragen. NVI vraag 37: De eis moet luiden: Een docent is in staat studenten tijd- en plaatsonafhankelijk van gedachten te laten wisselen. Daarbij moet de docent een onderscheid kunnen maken tussen het geven van beknopte bijdragen of het schrijven van meer reflectieve bijdragen. Toetsen 75. Een docent moet toetsen kunnen ontwikkelen waarmee studenten en de docent zicht kan krijgen op de voortgang van studenten. 76. Een docent moet toetsen en toetsvragen binnen het kern-lms eenvoudig kunnen kopiëren, bewerken en in verschillende ruimtes kunnen hergebruiken. NVI vraag 59,60. 77. Docenten moeten in staat zijn om gezamenlijk te werken aan toetsvragen en toetsen. 78. Een docent moet toetsen kunnen exporteren om daarna in een andere applicatie te kunnen importeren. NVI vraag 61 79. Een docent moet in staat zijn om verschillende typen toetsvragen te creëren (minimaal meerkeuze, Likert-schaal, open vraag). 80. Een docent moet in staat zijn kwalitatieve feedback toe te voegen aan toetsvragen en aan de toets als geheel. 81. Een docent moet in staat zijn aan te geven wanneer feedback bij toetsen wordt getoond (na beantwoording van een vraag en/of na het maken van een toets). 82. Een docent moet in staat zijn een toets te publiceren zodat een student deze kan maken. Inleveren en beoordelen van opdrachten 83. Een docent moet opdrachten kunnen creëren die studenten kunnen insturen. Daarbij moet de docent kunnen bepalen of het gaat om een individuele opdracht of groepsopdracht. 84. Een docent moet kunnen aangeven of een opdracht een bepaalde deadline heeft (of niet). 85. Een docent moet aan kunnen geven hoe de opdracht beoordeeld wordt (voldaan/niet voldaan, voldoende/onvoldoende, cijfer). 86. Een student moet een opdracht als concept kunnen inleveren, zodat de docent deze kan reviewen zonder er een oordeel aan te geven. 87. Een docent moet uitwerkingen van opdrachten individueel en collectief via een integratie met Ephorus kunnen controleren op originaliteit. 88. Een docent moet de uitkomsten van de originaliteitscheck via Ephorus kunnen terugkoppelen naar de student. 89. Een docent moet schriftelijke feedback kunnen geven op ingeleverde individuele opdrachten. 90. Een docent moet schriftelijke feedback kunnen geven op ingeleverde groepsopdrachten. 91. Een docent moet groepsopdrachten kunnen beoordelen waarbij het oordeel aan individuele studenten wordt toegekend. 92. Een docent moet de beoordeling en de feedback terug kunnen koppelen naar de individuele student. 93. Een docent moet een analytische beoordelingsschaal kunnen gebruiken die meer zegt dan slechts een enkel cijfer (maar ook: wat ging goed, wat minder goed). Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 6 van 8
94. Een docent moet ingeleverde opdrachten snel terug kunnen zoeken. NVI vraag 62 95. Een docent moet ervoor kunnen kiezen dat een oordeel van een opdracht geëxporteerd kan worden zodat het kan worden ingelezen in het studentinformatiesysteem (Osiris). 96. Een student moet een portfolio kunnen samenstellen met bewijsmaterialen en inleveren zodat het beoordeeld wordt door een of meer docenten. NVI vraag 63, 64 97. Een docent moet een versie van een portfolio, die een student heeft ingezonden ter beoordeling, kunnen bevriezen zodat deze versie niet meer kan worden aangepast. NVI vraag 63 98. Een docent moet een versie van een portfolio van feedback kunnen voorzien (ook op onderdelen) en er een oordeel aan kunnen hangen. NVI vraag 63 99. Een student moet een niet-ingezonden versie van een portfolio kunnen verwijderen. NVI vraag 63 Onderwijsprocesbegeleiding 100. De ontwikkeling van (deel)competenties kan ook zichtbaar worden gemaakt. NVI vraag 65 101. Een docent moet de voortgang van studenten kunnen monitoren, en zelf selecteren welke data hij of zij wil monitoren (individueel, groepsgewijs). Te monitoren data betreffen in ieder geval: ontwikkeling (deel)competenties, uitslagen van formatieve toetsen, beoordelingen van opdrachten, overschreden deadlines. 102. Een student moet zijn of haar studievoortgang binnen een ruimte in één oogopslag kunnen zien. 103. Een student moet een persoonlijk ontwikkelingsplan kunnen opstellen en delen met anderen. NVI vraag 66 104. Een student moet aan kunnen geven wanneer hij of zij een notificatie wil ontvangen over naderende deadlines van taken. NVI vraag 38, 32 105. Een student moet automatisch een notificatie ontvangen als hij of zij een deadline dreigt te overschrijden. NVI vraag 38, 32 106. Een docent moet aankunnen geven wanneer hij of zij een notificatie wil ontvangen over zijn studenten, indien deze deadlines overschrijden. NVI vraag 39 107. Een docent moet automatisch een notificatie ontvangen als één van zijn of haar studenten een deadline heeft overschreden. NVI vraag 39 Leermaterialen ontwikkelen, beheren en delen 108. Een docent moet een structuur van een ruimte kunnen maken met items en subitems binnen een cursus, op basis van een template. 109. Een docent moet diverse vormen van content toegankelijk kunnen maken binnen de ruimte. In ieder geval: opgemaakte tekst, afbeeldingen, embedded video, embedded code (bijv. van Slideshare), formules, koppelingen met roosters). 110. De gebruikte editor benadert zoveel mogelijk de mogelijkheden van een standaard tekstverwerker (zoals Word). NVI vraag 67 111. Een docent moet artefacten binnen een cursus kunnen vervangen door een nieuwe versie, zonder dat de verwijzingen aangepast hoeven te worden. 112. Een docent moet artefacten in een centrale databank binnen het kern-lms op kunnen slaan die hij of zij in diverse ruimtes kan gebruiken. 113. De docent is in staat om artefacten te selecteren en batchgewijs te exporteren zodat deze buiten het kern-lms kunnen worden hergebruikt. NVI vraag 68 114. Een docent moet verschillende typen leeractiviteiten kunnen gebruiken binnen de ruimte (in elk geval: leerstof, SCORM-Package, IMS-pakket, inleveropdrachten, formatieve toetsen, opdrachten met peer feedback, asynchrone discussies). 115. Een docent moet items op basis van een datum zichtbaar kunnen maken. Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 7 van 8
116. Een docent moet items op verschillende manieren kunnen laten afronden (op basis van een oordeel, op basis van afvinken door de docent). 117. Een docent is in staat om een ruimte of (sub)items binnen die ruimte publiek toegankelijk te maken zodat deze ruimte of (sub)items zonder in te loggen bestudeerd kunnen worden. NVI vraag 10, 4, 40. Learning analytics 118. Een docent moet het gedrag van studenten (individueel en groepsgewijs) binnen de DLO visueel kunnen maken en analyseren. De Inschrijver geeft aan welk studentgedrag geanalyseerd kan worden. Te denken valt aan: uitslagen van formatieve toetsen, beoordelingen van opdrachten, afgeronde items, laatste keer ingelogd, overschreden deadlines, discussiebijdragen, aantal keren ingelogd, tijd ingelogd. Randvoorwaarden De aangeboden oplossing dient te voldoen aan de volgende randvoorwaarden: Er kan een koppeling gerealiseerd moeten worden met Osiris (en andere binnen het hoger onderwijs gebruikte vergelijkbare studentinformatiesystemen), met het IDM-systeem van Zuyd en met SURFConext. De koppeling is gericht op het kunnen gebruiken van gegevens van deze bronsystemen binnen het kern-lms. Er kan een koppeling gerealiseerd worden met Ephorus/de Originaliteitscheck van Turn It In zodat een instuuropdracht gecontroleerd kan worden op plagiaat. De gebruiker blijft hiervoor binnen het kern-lms. De Inschrijver verklaart te voldoen aan het juridisch normenkader cloudservices hoger onderwijs. Dit normenkader biedt richtlijnen over vertrouwelijkheid, privacy, eigendom en beschikbaarheid van gegevens. De Inschrijver is bereid zonder voorbehoud de bewerkersovereenkomst van Zuyd te ondertekenen. Opslag van data vindt gegarandeerd in Europa plaats. Docenten zijn in staat na een dagdeel instructie het kern-lms zelfstandig te gebruiken voor het ontwikkelen, beheren en delen van leermaterialen, voor communiceren, samenwerken, inleveren en beoordelen van opdrachten, toetsen en onderwijsprocesbegeleiding. Bijlage 4/ Programma van Eisen / refnr. Zuyd.2017.1.LMS/ mei 2017 Pagina 8 van 8