it.ucl.dkit.ucl.dk/lmstender/009 - bilag 2 kravspecifikation.docx · web viewdette dokument...

Kravspecifikation for LMS til UCL, UCSJ, UCS, VIA og UCC Bilag 2 til ”Contract regarding procurement of LMS.”

INDHOLD

INDHOLD...........................................................................................................................................1Vejledning.........................................................................................................................................3

Minimumskrav, optioner og ønsker...................................................................................................................3Begreber og definitioner....................................................................................................................................3

1. Drift/hosting..................................................................................................................................51.1 Ekstern hosting (sky/cloud/SaaS).................................................................................................................5

2. Kompatible klienter/browsere......................................................................................................63. Persondata og sikkerhed...............................................................................................................7

3.1 Persondata...................................................................................................................................................73.2 Stedfortræder..............................................................................................................................................73.3 IT-sikkerhed..................................................................................................................................................7

4. Driftsikkerhed & Support...............................................................................................................84.1 Driftssikkerhed.............................................................................................................................................84.2 Teknisk support fra leverandører.................................................................................................................84.3 Partnerskab og samarbejde med leverandører............................................................................................8

5. Brugerstyring...............................................................................................................................105.1 Bruger autentification................................................................................................................................105.2 Roller (overordnede roller)........................................................................................................................105.3 Brugerdata.................................................................................................................................................10

6. Data fra uddannelsesmoduler, fag og kurser..............................................................................127. Kerne-data integration................................................................................................................138. Anden data integration...............................................................................................................149. Integration med eksterne partnere.............................................................................................1510. API.............................................................................................................................................1611. Dokumentation.........................................................................................................................1712. Logning......................................................................................................................................1813. Dataflytning fra det nuværende LMS-system til det valgte LMS-system...................................1914. Gæste-adgang til systemet........................................................................................................2015. Roadmap...................................................................................................................................2116. Tekst, sprog, tegn og formler....................................................................................................22

16.1 Sprog........................................................................................................................................................2216.2 Teksteditor...............................................................................................................................................22

17. Support for brugere...................................................................................................................2418. Brugervenlige system- og handlingsmeddelelser......................................................................2519. Brugergrænseflade....................................................................................................................26

19.0 Startsiden.................................................................................................................................................2619.1 Tilgængelighed.........................................................................................................................................2619.2 Markering af meddelelser, notifikationer, nyheder og deadlines.............................................................2619.3 Søgefunktion............................................................................................................................................27

20. Opbygning, branding, menu og funktioner...............................................................................2921. Styring af roller i rum.................................................................................................................31

Side 1 af 59


22. Optimeret workflow..................................................................................................................3223. Asynkron kommunikation.........................................................................................................33

23.1 Diskussionsforum.....................................................................................................................................3323.2 E-mail.......................................................................................................................................................3423.3 Voice-mail................................................................................................................................................3423.4 Blogs.........................................................................................................................................................3423.5 Logbog (studie/lærings-logbog)...............................................................................................................3623.6 Wiki..........................................................................................................................................................3623.7 Meddelelser.............................................................................................................................................3723.8 SMS..........................................................................................................................................................38

24. Synkron kommunikation...........................................................................................................3924.1 Webkonferencesystem............................................................................................................................3924.2 Synkron skrivning i samme dokument......................................................................................................39

25. Grupperum................................................................................................................................4026. Kursus-administration...............................................................................................................41

26.1 Administration af kursusrummet.............................................................................................................4126.2 Statistik....................................................................................................................................................42

27. Portfolio – gruppe og individuel................................................................................................4328. Test- og evalueringsværktøjer, samt survey funktion...............................................................44

28.1 Tests.........................................................................................................................................................4428.2 System til digital eksamen........................................................................................................................4628.3 Spørgeskema (Survey)..............................................................................................................................47

29. Håndtering af filer, fildeling m.m...............................................................................................4929.1 Filarkiv og fildeling...................................................................................................................................4929.2 Upload og præsentation af materiale......................................................................................................5029.3 Personlig kopi af filer m.m........................................................................................................................50

30. Opgaver.....................................................................................................................................5130.1 Opgaveafleveringsfunktion......................................................................................................................5130.2 Plagiattjek................................................................................................................................................5230.3 Evaluering og feedback............................................................................................................................53

31. Eksport af data ved udtræden/ophør........................................................................................5432. Data om gennemførte studieaktiviteter og studiefremdrift......................................................5433. Håndtering af korte kurser........................................................................................................5534. Brugervenlighed og ’usability’...................................................................................................55

Side 2 af 59


Vejledning

Dette dokument LMS-KRAVSPEC er bilag til kontrakt vedrørende anskaffelse af Learning Management System (LMS) til håndtering af online studieaktiviteter hos UCL og med option for UCSJ, UCS, VIA og UCC til at anskaffe LMS på tilsvarende vilkår. Kontrakten er indgået efter afholdelse af EU-udbud.

Tilbudsgiver skal besvare og uddybe nærværende bilag, hvor det er tilkendegivet, at Tilbudsgiver skal udfylde med en beskrivelse.

Ordregivers behov er klassificeret i kategorier benævnt som følger:

Minimumskrav, optioner og ønsker

[MK]=MinimumsKravTilbudsgiver skal markere, om kravet er opfyldt eller ej (ja/nej). Kravet kan kræve en supplerende beskrivelse af, hvordan kravet opfyldes.

Markering af ”Ja”:[MK Ja] eller[MK Ja/Nej] eller[MK Ja/Nej]

Markering af ”Nej”:[MK Nej] eller[MK Ja/Nej] eller[MK Ja/Nej]

[Ø]=Ønske og [ØHP]=Ønske Højt PrioriteretKan opfyldes og fremstår som konkurrenceparameter i tilbudssammenligningen.

Beskrivelse: …Hvis et krav eller et ønske efterfølges af ”Beskrivelse: …”, skal tilbudsgiveren kortfattet, men fyldestgørende beskrive, hvordan kravet eller ønsket opfyldes af tilbuddet. Det er ikke tilladt at linke til manualer eller andet materiale - der vil kun blive taget hensyn til teksten i det udfyldte bilag. Beskrivelserne indgår i evalueringen af de kvalitative krav om "Funktionalitet" og "Brugervenlighed", jf. beskrivelserne herom i Udbudsbetingelserne.

Ordregiver betragter manglende besvarelse af MK, Ø og ØHP, som om disse ikke er opfyldt.

Begreber og definitioner

RumVed ’Rum’ forstås et afgrænset område i LMS’et hvor læringsobjekter, dokumenter, og collaborative værktøjer kan gøres tilgængelige for deltagere. Der er rettighedsstyring (medlemmer / ikke medlemmer) og mulighed for forskellige roller i rummet.

KursusrumVed ’Kursusrum’ forstås et rum, der er knyttet til et bestemt kursus/fag/modul/hold. Der er rettighedsstyring (medlemmer / ikke medlemmer) og mulighed for forskellige roller i kursusrummet. Der er i princippet den samme funktionalitet i et kursusrum som i et andet Rum.

Side 3 af 59


GrupperumVed ’Grupperum’ forstås et rum, der er knyttet til en gruppe af studerende, og som måske, måske ikke findes integreret i et andet rum/kursusrum. Grupperummet understøtter samarbejde imellem studerende eller brugere med andre roller. I et Grupperum er der ikke nødvendigvis samme funktionalitet som i et andet rum.

Administrator i et rumVed ’Administrator i et rum’ forstås den eller de personer, som har fuld kontrol i rummet. Det kan være underviser og/eller kursussekretær i et kursusrum, eller den/de person(er) som har oprettet og administrerer et kursusrum eller grupperum.

Side 4 af 59


1. Drift/hosting

1.1 Ekstern hosting (sky/cloud/SaaS)1. [MK Ja/Nej] Ordregiver ønsker et tilbud på løsningen hostet, driftet og leveret af

tilbudsgiver som en sky/cloud/SaaS-service. Det er tilladt hér, at supplere med at henvise til, eller vedlægge, tilbudsgivers generelle vilkår for Sky/Cloud-services dækkende for den tilbudte LMS-løsning.Beskrivelse: …

Side 5 af 59


2. Kompatible klienter/browsere

Systemets brugergrænseflade skal være fuldt tilgængelig gennem internet browsere.

1. [MK Ja/Nej] Systemet skal kunne afvikles i de til enhver tid mest gængse browsere. Som minimum Firefox og Chrome, herunder den til enhver tid nyeste udgave, og minimum 2 versioner bagud. Kravet gælder for alle funktioner væsentlige for almindeligere brugeres anvendelse af LMS-systemet, dvs. fx ikke nødvendigvis for administratorer af LMS-systemet.

2. [MK Ja/Nej] Systemets hovedfunktioner skal kunne betjenes på en brugervenlig måde på mobile enheder, dvs. designet til små skærme, fx smartphones og tablets. Kravet gælder for LMS-systemets hovedfunktioner for almindeligere brugeres anvendelse af LMS-systemet, dvs. fx ikke nødvendigvis for administratorer af LMS-systemet.

3. [MK Ja/Nej] Systemet skal understøtte alle gængse filformater på Windows og MacOSX, herunder video- og lyd-formater.

4. [MK Ja/Nej] Systemet skal omfatte en web-app og/eller en app til mindst iOS og Android, hvor LMS-systemets hovedfunktioner for almindelige brugere er tilgængelige.

5. [MK Ja/Nej] Der skal være mulighed for at afvikle streaming video og lyd direkte i LMS-systemet.

6. [ØHP] Systemet kan yderligere afvikles i MS Internet Explorer, MS Edge og Safari, herunder den til enhver tid nyeste udgave, og minimum 2 versioner bagud. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

7. [ØHP] Det ønskes, at brugerinterface til mobile platforme (små skærme) som minimum viser notifikationer og i størst mulig grad viser nyheder, indhold og funktionalitet i rum og skemaoplysninger. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, herunder hvilken funktionalitet der kan vises.Beskrivelse: …

Side 6 af 59


3. Persondata og sikkerhed

3.1 Persondata1. [MK Ja/Nej] Systemets håndtering af persondata skal, mindst indtil maj 2018, leve op til

kravene i Persondataloven.2. [MK Ja/Nej] Systemets håndtering af persondata skal, senest fra maj 2018, leve op til

kravene i EU’s Persondataforordning.

3.2 Stedfortræder1. [ØHP] Systemets skal indeholde en funktion, der gør det muligt for en bruger at give

en stedfortræder adgang til sin brugerkonto. Tilbudsgiver bedes beskrive, hvordan denne funktion virker og er implementeret i systemet.Beskrivelse: …

3.3 IT-sikkerhedFor at kunne opfylde de generelle sikkerhedskrav for IT-systemer hos Ordregiver skal følgende krav opfyldes.

1. [MK Ja/Nej] Systemet skal understøtte SSL protokollen.

2. [MK Ja/Nej] Systemet skal have en log-ud facilitet, samt sikre automatisk log-ud, når browser lukkes.

3. [MK Ja/Nej] Der skal være mulighed for at begrænse en sessions levetid.4. [MK Ja/Nej] Udbyderen skal, minimum en gang om året, teste det kørende systems

sikkerhedsniveau, og oplyse om resultatet heraf og reagere med fejlrettelser inden for rimelig tid.

Side 7 af 59


4. Driftsikkerhed & Support

4.1 DriftssikkerhedOrdregiver og dets brugere er afhængige af, at LMS systemet altid er til rådighed.

1. [MK Ja/Nej] Der skal foreligge dokumentation af driftssikkerhed (herunder oppetid, antal samtidige brugere m.m.). Herunder skal der være referencer på oppetid for LMS-systemet hos andre større uddannelsesinstitutioner, der matcher Ordregiver i størrelse og kompleksitet.

2. [MK Ja/Nej] Systemet skal være skalérbart og skal kunne håndtere mindst 5000 samtidige brugere, dvs. samtidige log-in-sessioner.

3. [MK Ja/Nej] Leverandøren skal tilbyde døgnbemandet support funktion, der sikrer en hurtig respons ved eksempelvis systemnedbrud eller andre kritiske situationer.

4. [MK Ja/Nej] Der skal være beskrevet en procedure for backup og restore inkl. den underliggende tidsbestemte backupcyklus og hvilke dele af backup’en, der kan genetableres for sig. Det skal desuden være muligt fra backup’en, på en enkelt måde, at genskabe data i et rum (uanset rumtype), fx hvis en bruger er kommet til at slette indholdet ved en fejl.

5. [MK Ja/Nej] Der skal være beskrevet en procedure for håndtering og installation af sikkerheds- og vedligeholdelsesopdateringer.

4.2 Teknisk support fra leverandørerMed teknisk support forstås service og faciliteter, som leverandør stiller til rådighed til henholdsvis administratorer og brugere.

1. [MK Ja/Nej] Leverandørernes teknikere skal have mulighed for at logge på systemet og arbejde med problemløsning online.

2. [MK Ja/Nej] Vidensbase med løsninger på forskellige tekniske problemer skal være tilgængelig.

4.3 Partnerskab og samarbejde med leverandørerOrdregiver ønsker, at tilbudsgiver engagerer sig i et partnerskab og samarbejde med Ordregiver ang. den tilbudte LMS-løsning, herunder dialog og hjælp som leverandøren yder til Ordregiver med henblik på at optimere Ordregivers udbytte af LMS-løsningen.

1. [ØHP] Information, ”Roadmap” og ændringsstyring: Ordregiver ønsker at modtage periodiske informationer om kommende nyheder og ændringer i den tilbudte LMS-løsning. Tilbudsgiver bedes beskrive, hvordan ønsket opfyldes.Beskrivelse: …

2. [ØHP] Kompetenceudvikling: Ordregiver ønsker at tilbudsgiver tilbyder deltagelse i kompetenceudviklingsaktiviteter for top-level-administratorer og superbrugere, evt. med en

Side 8 af 59


certificering for LMS-løsningen. Tilbudsgiver bedes beskrive, hvordan ønsket opfyldes.Beskrivelse: …

3. [Ø] Brugergrupper: Ordregiver ønsker at deltage i den tilbudte LMS-løsnings nationale og evt. internationale brugergrupper. Tilbudsgiver bedes beskrive, hvordan ønsket opfyldes.Beskrivelse: …

4. [Ø] Indflydelse: Ordregiver ønsker afholdelse af årlige/periodiske møder hos Ordregiver, hvor tilbudsgiver stiller informationer til rådighed om tilbudsgivers planer for videreudvikling af LMS-løsningen, herunder kommende nye features og funktioner, som Ordregiver kan være med til at påvirke. Tilbudsgiver bedes beskrive, hvordan ønsket opfyldes.Beskrivelse: …

5. [Ø] Netværk og videndeling: Ordregiver ønsker et årligt ledermøde, hvor det drøftes, hvordan tilbudsgiver kan give Ordregiver mulighed for at netværke med andre nationale og internationale brugerinstitutioner af LMS-løsningen, og e-læring generelt. Tilbudsgiver bedes beskrive, hvordan ønsket opfyldes.Beskrivelse: …

Side 9 af 59


5. Brugerstyring

5.1 Bruger autentificationOrdregiver arbejder med en central styring af data om brugerne (Identity Management), herunder også login proceduren, hvorfor det er vigtigt, at systemet understøtter nedenstående krav.

1. [MK Ja/Nej] Systemet skal, som den primære autentificationsmekanisme, tillade ekstern bruger-autentification, herunder:a: Autentification mod LDAP (Lightweight Directory Access Protocol) eller AD (Active Directory).b: SAML2.

2. [MK Ja/Nej] Det skal samtidigt være muligt at falde tilbage til autentification via systemets egen brugerdatabase (sekundær fall-back mekanisme).

3. [MK Ja/Nej] Systemet skal tillade brugergodkendelse med WAYF teknologi, der formidler single sign-on til institutionens øvrige web tjenester.

5.2 Roller (overordnede roller)Ordregiver består af forskellige uddannelser og driver campusser på flere lokationer. Der er derfor behov for at kunne målrette information fx på baggrund af roller og/eller grupper.

1. [MK Ja/Nej] Systemet skal kunne knytte én primær rolle til en bruger, samt min. 100 sekundære roller. Eksempelvis skal en studerende kunne have den primære rolle: STUDERENDE.

2. [MK Ja/Nej] Sekundære roller: (en studerende skal fx kunne have disse roller: <uddannelse>, <lokation>, <hold>, ...). Rollerne skal styre en differentieret adgang til systemets forskellige dele. Samme bruger skal desuden kunne have flere <uddannelse> og <lokation> og det skal kunne angives, hvilken der er den primære.

3. [ØHP] Ordregiver ønsker at kunne tilpasse roller på alle niveauer. Det er vigtigt, at Ordregiver på systemet har mulighed for at tilpasse, samt bygge nye roller (fri sammensætning af rettigheder) for:a: Kursus-roller (rettighedssæt på kursusrum-niveau)b: Administrator-roller (rettighedssæt på administrator/system niveau)c: Institutions-roller (visning af indhold baseret på brugertype)Tilbudsgiver bedes beskrive mulighederne for fleksible roller.Beskrivelse: …

5.3 BrugerdataBrugerdata er erfaringsmæssigt et centralt element af systemet. Nedenstående krav er vigtige for Ordregiver, bl.a. for at sikre det nødvendige dataflow fra datakilde-systemer til LMS.

1. [MK Ja/Nej] Systemet skal som minimum kunne opbevare følgende brugerdata, der alle skal kunne ændres via den tilhørende automatiske brugervedligeholdelse: a: Ekstern person ID (unik fælles nøgle fx til brug for andre af Ordregivers systemer).

Side 10 af 59


b: E-mail-adressec: Adgangskoded: Brugernavne: Fornavn, Mellemnavn, Efternavnf: Primær rolle (fx studerende eller underviser) g: System rolle (fx administrator eller alm. bruger)

2. [MK Ja/Nej] Systemadministrator skal manuelt eller via den automatiske opdatering af brugere kunne bestemme, om de skal have status tilgængelig/utilgængelig.

3. [MK Ja/Nej] Der skal være mulighed for at klassificere brugere som værende deaktiveret i systemet, uden at de fysisk er slettet fra databasen.

4. [MK Ja/Nej] Redigering af brugerdata fra GUI (Graphical User Interface) skal kunne styres af systemadministrator, således at brugere kun kan redigere felter defineret af systemadministrator.

5. [ØHP] Systemet skal kunne opbevare følgende brugerdata, der alle skal kunne ændres via den tilhørende automatiske brugervedligeholdelse: a: Telefonnummer b: Foto/portræt c: Grupperingsnøgle. Nøgle til at definere og identificere særlige grupper af brugere.Tilbudsgiver bedes beskrive mulighederne for dette.Beskrivelse: …

6. [ØHP] Ordregiver ønsker, at det er muligt for brugerne at redigere de dele af brugernes egen profil, som administratorerne giver adgang til, fx foto/portræt. Tilbudsgiver bedes beskrive mulighederne for dette.Beskrivelse: …

Side 11 af 59


6. Data fra uddannelsesmoduler, fag og kurser

”Kursusdata” i dette dokument, dækker over data knyttet til et uddannelsesmodul, et fag eller et kursus – altså et afgrænset sammenhængende uddannelsesforløb, undervisningsforløb, projektforløb eller læringsforløb.

Kursusdata er erfaringsmæssigt et centralt element af et LMS. Nedenstående krav er vigtige for Ordregiver, bl.a. for at sikre det nødvendige dataflow fra datakilde systemer til LMS.

1. [MK Ja/Nej] Systemet skal som minimum kunne opbevare følgende kursusdata, som alle skal kunne ændres via den tilhørende automatiske kursusdata-vedligeholdelse:a: Kursus IDb: Kursus titelc: Kursusbeskrivelse (modulplan)d: Grupperingsnøgle der kan definere og identificere grupperinger af kursusrum (fx. alle kurser på en given uddannelse, et givent modul eller givet semester).

2. [MK Ja/Nej] Systemadministrator skal manuelt og via den automatiske opdatering af kursusrum kunne bestemme, om de (kursusrummene) skal have status tilgængelig eller utilgængelig.

3. [MK Ja/Nej] Kursusadministrator skal manuelt kunne arkivere kursusrum.4. [MK Ja/Nej] Der skal være mulighed for at klassificere kursusrum som værende deaktiveret

i systemet, uden at de fysisk er slettet fra databasen.5. [MK Ja/Nej] Kursusdata skal kunne hentes/læses af eksterne systemer (fx et eksternt

skemasystem, et kursuskatalog eller til print) via et API og/eller en webservice.6. [ØHP] Systemet skal (desuden) kunne opbevare følgende kursusdata, som optimalt

skal kunne ændres via den tilhørende automatiske kursusdata-vedligeholdelse:e: Kursusbeskrivelse (modulplan) som HTMLf: Datoer for kursus-start og -slut. Tilbudsgiver bedes beskrive mulighederne for dette.Beskrivelse: …

7. [ØHP] Ordregiver ønsker, at et kommende system skal tilbyde en mulighed for at samlæse/sammenknytte flere kursusrum til et fælles kursusrum. Tilbudsgiver bedes beskrive mulighederne for dette.Beskrivelse: …

8. [ØHP] Manuel og automatiseret procedure til arkivering/eksport af kursusrum, samt en manuel og automatiseret procedure til indlæsning/import af disse arkiverede kursusrum. Denne procedure skal være til rådighed for systemadministrator. Tilbudsgiver bedes beskrive mulighederne for dette.Beskrivelse: …

Side 12 af 59


7. Kerne-data integration

Kernedata i LMS vil primært komme fra Ordregivers studieadministrative system (SIS), der løbende skal kunne overføre data til LMS.

1. [MK Ja/Nej] Et kommende system skal understøtte automatiserede indlæsningsprocedurer af stamdata (typisk data fra SIS). Systemet skal kunne modtage data i standardformater fx XML eller flade filer (txt-filer). Det skal også være muligt at indlæse og ændre data via et API eller en webservice.

2. [MK Ja/Nej] Fra SIS (og andre eksterne datakilder) skal det som minimum være muligt at indlæse følgende data: a: Brugerdatab: Kursusdatac: Kursus-katalog tilknytningerd: Sekundære roller

3. [MK Ja/Nej] Data integrations metoden skal være præcist dokumenteret. Beskriv hvordan denne er dokumenteret og henvis til denne dokumentation.Beskrivelse: …

4. [ØHP] Systemet skal indeholde rutiner til sikring mod indlæsning af invalide data. Tilbudsgiver bedes beskrive muligheden for dette.Beskrivelse: …

5. [ØHP] Fra SIS (og andre eksterne datakilder) skal det være muligt at indlæse følgende data: a: Bruger-kursus tilknytninger (tilmeldinger)b: Kursus katalogerTilbudsgiver bedes beskrive muligheden for dette.Beskrivelse: …

6. [ØHP] Ordregiver ønsker, at et kommende LMS System sikrer mulighed for at lade SIS være ejer af centrale data, således at denne type data kun kan ændres via SIS. Tilbudsgiver bedes beskrive muligheden for dette.Beskrivelse: …

7. [ØHP] Ordregiver ønsker, at der kan foretages en gruppe-inddeling på kurser baseret på fx SIS data (underhold/holdopdeling). Tilbudsgiver bedes beskrive mulighederne for at oprette grupper på baggrund af SIS data.Beskrivelse: …

8. [ØHP] Skemaintegration: Ordregiver ønsker, at et kommende LMS system har et skema modul, der kan modtage skema-data og automatisk indlæse og vise dette fra det studieadministrative system eller en anden datakilde (fx TimeEdit). Der ønskes visninger for brugere (personlige skemaer) og brugergrupper (fx grupper og hold) med mulighed for link til supplerende data/filer, fx uddannelsesplaner, modulplaner. Tilbudsgiver bedes beskrive muligheder for skemaintegration.Beskrivelse: …

Side 13 af 59


8. Anden data integration

Ordregiver råder over mange forskellige datakilder, hvor flere er relevante at integrere i et LMS.

1. [MK Ja/Nej] Integration (indlejring) af eksterne datakilder/websider. LMS systemet skal kunne integrere eksterne webparts, portlets, RSS feeds mm.

2. [MK Ja/Nej] Ordregiver ønsker, at systemet skal kunne give brugeren mulighed for at knytte relevante kursusrums filstruktur på brugerens computer (fx som netværksdrev), således at brugeren kan publicere eller opdatere filer i et kursus ved blot at ’kopiere en fil’ til netværksdrevet. Tilbudsgiver bedes beskrive mulighederne for ovenstående.Beskrivelse: …

3. [ØHP] Kalenderintegration: Ordregiver ønsker, at LMS systemets indbyggede kalender skal kunne opsættes til at udveksle data med fx Outlook / Exchange og Ordregivers skemalægningssystem (TimeEdit). Tilbudsgiver bedes beskrive mulighederne for dette.Beskrivelse: …

Side 14 af 59


9. Integration med eksterne partnere

Integration med eksterne partnere omhandler integration og samarbejde med software uden for LMS’ets platform. Ordregiver ønsker stor mulighed for at kunne integrere relevant eksternt software direkte i LMS’et, således at brugerne oplever en så stor grad af sammenhæng som mulig. Det er Ordregivers udgangspunkt, at eksisterende og udbredte tjenester/programmer bør kunne integreres direkte, frem for at LMS-leverandøren stiller en ny lignende funktion til rådighed.

1. [MK Ja/Nej] LMS’et skal understøtte følgende internationale standarder:a: IMS Learning Tools Interoperability (LTI), som beskrevet her: http://www.imsglobal.org/toolsinteroperability2.cfmb: SCORM: Sharable Content Object Reference Model.

2. [MK Ja/Nej] LMS’et skal indeholde integration til videoplatformen Kaltura3. [ØHP] Ordregiver ønsker mulighed for at kunne integrere med sociale medier og

tjenester. (fx G Suite/Google Docs, Office365,Facebook, YouTube o.lign.) i LMS’et. Tilbudsgiver bedes oplyse hvilke, der kan integreres til og på hvilken måde.Beskrivelse: …

4. [Ø] LMS’et skal understøtte følgende internationale standard:a: Import and Export of Common Cartridge, incl. pakker af material, læringsobjekter m.m. fra forlag.

Beskrivelse: …

Side 15 af 59

http://www.imsglobal.org/toolsinteroperability2.cfm


10. API

Behovet for at kunne udvikle Ordregiver tilpasset funktionalitet i et LMS system har vist sig at være stort. Muligheden for selv at kunne tilføje funktionalitet til et LMS er særdeles vigtig.

1. [MK Ja/Nej] Der skal foreligge et åbent veldokumenteret API til systemet, der muliggør udvikling af egne systemudvidelser og dermed tilføje ny funktionalitet til systemet.

2. [MK Ja/Nej] Der skal være mulighed for igennem dette API at tilgå (læse, skrive, modificere og slette) alle væsentlig data (kursus data, brugerdata, indholdsdata m.m.).

3. [MK Ja/Nej] Leverandøren skal løbende holde Ordregiver opdateret om ændringer ift. API’et.

4. [ØHP] Ordregiver ønsker, at systemudvidelser via API skal kunne installeres dynamisk på et kørende system. Tilbudsgiver bedes beskrive muligheden for dette.Beskrivelse: …

5. [Ø] Ordregiver ønsker, at der til LMS systemet hører et veldokumenteret database skema, der giver Ordregiver en god forståelse af systemets database. Og samtidigt giver Ordregiver mulighed for at lade eksterne systemer læse data fra systemets database, hvis nødvendigt. Tilbudsgiver bedes beskrive, om og hvordan disse informationer er tilgængelige.Beskrivelse: …

Side 16 af 59


11. Dokumentation

1. [MK Ja/Nej] Der skal foreligge følgende dokumentation for systemet:a. Systemdokumentationb. Installationsvejledning c. Driftsvejledninger d. Brugervejledninger på både dansk og engelsk.e. Dokumentation af dataintegrationf. Dokumentation af APIAl dokumentation skal løbende holdes opdateret af leverandøren.

Side 17 af 59


12. Logning

Enhver handling på systemet skal kunne spores til brugeren eller maskinen/device.

1. [MK Ja/Nej] Af sikkerhedsmæssige årsager skal enhver handling (http request) på systemet kunne spores i en log, med henvisning til tidsstempel, ip-nummer og brugernavn.

2. [MK Ja/Nej] Brugerhandlinger (før databaseevents) skal logges i en tabel med tidsstempel, brugernavn og eventoplysninger.

3. [MK Ja/Nej] Der skal være indbygget rotation af logfiler, der kan justeres af system administrator efter behov.

4. [MK Ja/Nej] For at kunne fejlsøge i tilfælde af fx driftsproblemer, skal der være mulighed for at øge graden af logning.

5. [MK Ja/Nej] LMS’et skal give brugerne mulighed for på en let måde at se en oversigt over hvilke typer af data om brugerne og brugernes adfærd, der logges/registreres i LMS-systemet.

6. [ØHP] Systemets logfiler skal overholde et gængs standardformat, fx SYSLOG, Windows Event. Tilbudsgiver bedes beskrive, hvilke(t) logfilformat(er) løsningen tilbyder.Beskrivelse: …

7. [ØHP] Ordregiver ønsker, at systemadministrator skal have mulighed for se, hvem der er online nu og her. Tilbudsgiver bedes beskrive muligheden for dette.Beskrivelse: …

Side 18 af 59


13. Dataflytning fra det nuværende LMS-system til det valgte LMS-system

Ordregiver bruger (for visse professionshøjskolers vedkommende) et andet LMS-system i dag. Dette afsnit omhandler mulighederne for, at data fra andre LMS-systemer kan indlæses i det tilbudte LMS-system (uanset arten af det nuværende LMS-system).

Import fra det nuværende system forstås af Ordregiver således, at et evt. skift fra andet LMS, kan foregå så gnidningsløst for både brugere og administration som muligt, og at brugerne af systemet ikke oplever tab af vigtige data eller funktioner, hvad enten den er kursusrelateret, personlig eller administrativ.

1. [ØHP] Ordregiver ønsker at brugere, rum, og tilhørende relationer (herunder tilknyttede filer, tests, diskussionsfora) kan importeres til det valgte system ud fra et foruddefineret dataformat. Tilbudsgiver bedes beskrive, hvordan dette håndteres og henvise til relevant dokumentation.Beskrivelse: …

2. [ØHP] Ordregiver ønsker, at bruger- og kursusmateriale (herunder filer og portfolier), skal kunne importeres til det tilbudte LMS-system. Tilbudsgiver bedes beskrive, hvordan denne overførsel kan foregå.Beskrivelse: …

3. [ØHP] Hjælp, rådgivning og assistance til import af data fra nuværende LMS-platform. Tilbudsgiver bedes beskrive, hvordan denne ydelse kan leveres og på hvilke vilkår, herunder økonomiske.Beskrivelse: …

4. [Ø] Ordregiver ønsker, at eksisterende wikis, blogs og logbøger (i kurser-/grupperum) kan importeres til det valgte system ud fra et foruddefineret dataformat. Tilbudsgiver bedes beskrive, hvordan denne overførsel kan foregå.Beskrivelse: …

Side 19 af 59


14. Gæste-adgang til systemet

Som udgangspunkt ønsker Ordregiver et LMS som et lukket system, men ønsker mulighed for at kunne åbne for adgangen til specifikke dele af systemet udefra.

1. [MK Ja/Nej] Adgang til systemet skal være baseret på brugernavn og adgangskode, men det skal også være muligt at give anonym adgang til udvalgte dele af systemets rum, hvor brugeridentifikation er irrelevant, fx potentielle studerende.

Side 20 af 59


15. Roadmap

En Roadmap skal indikere, hvilke større udviklinger og deraf følgende ændringer/konsekvenser som systemet påtænkes at gennemgå i de kommende år. Ordregiver ønsker størst mulig grad af indsigt i og åbenhed omkring de udviklingsplaner, leverandøren har for systemet.

1. [MK Ja/Nej] Et løbende roadmap, der indikerer de større opgraderinger, udviklinger og forbedringer, som systemet tænkes at gennemgå set fra nuværende tidspunkt.

2. [MK Ja/Nej] Tilbudsgiver tilbyder løbende orientering om udviklingsplaner via sin hjemmeside, nyhedsmail og/eller konferencer.

Side 21 af 59


16. Tekst, sprog, tegn og formler

16.1 SprogOrdregivers forskellige uddannelser og internationale studerende og undervisere stiller krav om fleksibilitet i forhold til sprog i LMS’et.

1. [MK Ja/Nej] Brugerne skal som minimum kunne vælge/skifte mellem Dansk og Engelsk sprog i alt tekst i LMS’ets brugerflader, både på web og i apps og evt. klienter. Systemet skal huske indstillingen for den enkelte bruger - kan evt. være en del af brugerprofilen.

2. [ØHP] Brugerne skal kunne vælge Tysk sprog i alt tekst i LMS’ets brugerflader, både på web og i apps og evt. klienter. Systemet skal huske indstillingen for den enkelte bruger - kan evt. være en del af brugerprofilen.Beskrivelse: …

3. [ØHP] Ordregiver ønsker, at systemadministrator skal kunne til-/fravælge tilgængelige sprogpakker. Desuden skal den enkelte bruger kunne vælge imellem sprogpakker. Således at ved valg af fx dansk vises al tekst i LMS’et incl. systemmeddelser (men ikke tekst indtastet af en bruger) på dansk. Leverandøren bedes beskrive hvilke sprogpakker, der findes, hvorledes de administreres af systemadministrator hhv. bruger, og hvorledes valg/skift af sprog er udført i LMS’et.Beskrivelse: …

16.2 TeksteditorMange steder i LMS’et (fx som indhold, i wiki, blog og discussion board, m.m.) er det nødvendigt at kunne skrive formateret tekst og indlejre/embedde medier i en fleksibel WYSIWYG-teksteditor.

1. [MK Ja/Nej] Teksteditor skal give mulighed for tekstformatering, incl. fed, kursiv, understreg, forskellig font, forskellig fontstørrelse, forskellig skriftfarve, punktopstilling, tekstjustering m.m.

2. [MK Ja/Nej] Teksteditor skal give mulighed for indsættelse af links, både til andre elementer i LMS’et, og til eksterne links. Links til elementer i samme rum skal man kunne browse sig til.

3. [MK Ja/Nej] Det skal være muligt at indsætte/vedhæfte en eller flere filer.

4. [MK Ja/Nej] Der skal være et udvalg af emoticons.5. [MK Ja/Nej] Teksteditor skal understøtte indsættelse og visning af billedfiler i

gængse webformater (gif, .jpg, png og tilsvarende), herunder give brugeren mulighed for at vælge billedets placering, visningsstørrelse og tekstomløb. Billederne skal kunne hentes både fra nettet, rummet og egen computer.

6. [MK Ja/Nej] Mulighed for at tilrette størrelsen på tekstboksen under skrivning, og evt. vælge Full Screen visning, således at man kan overskue en længere tekst.

7. [MK Ja/Nej] Mulighed for HTML-redigering.

Side 22 af 59


8. [MK Ja/Nej] Teksteditor skal kunne understøtte og håndtere gængse internationale sprog, (incl. arabisk og nordiske karakterer/tegn). Disse tegn skal kunne indtastes og præsenteres vha. LMS’et. Tilbudsgiver bedes beskrive hvilke standarder, der understøttes.Beskrivelse: …

9. [MK Ja/Nej] Teksteditor skal indeholde formeleditor med gængse naturfaglige/matematiske tegn og formler.

10. [MK Ja/Nej] Mulighed for at indlejre video- og lydfiler (i gængse filformater og fra gængse videoportaler som Youtube, Vimeo, o.lign.). Tilbudsgiveren bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

11. [MK Ja/Nej] Mulighed for stavekontrol (minimum dansk og engelsk). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, og på hvilke sprog stavekontrol er muligt.Beskrivelse: …

12. [ØHP] Det ønskes, at teksteditor findes i samme form og med samme funktionalitet overalt i LMS’et hvor en bruger kan indtaste tekst (som feedbackværktøj for undervisere, på indholds-sider, i digitale tests, blogs, wikis og diskussionsforum m.m.), dog gerne i en reduceret form ved menuoverskrifter, titler på læringsobjekter m.m. Tilbudsgiveren bedes beskrive de forskellige versioner af teksteditor, der findes i systemet.Beskrivelse: …

13. [ØHP] Mulighed for at indsætte tabeller, med brugerdefinerede kolonner/rækker.Beskrivelse: …

14. [ØHP] Mulighed for at paste ind fra MS-Word og andre tekstbehandlings- eller præsentationsprogrammer samt regneark. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, og hvorledes overflødige formateringskoder fjernes fra den tekst, der pastes ind.Beskrivelse: …

Side 23 af 59


17. Support for brugere

Ordregiver ønsker et supportsystem vedr. LMS’et, der gør det muligt og støtter op om, at Ordregiver og dets brugere kan videreudvikle, supplere og personalisere det.

1. [MK Ja/Nej] Der findes engelsksprogede vejledninger målrettet brugerne til alle dele af LMS’et.

2. [MK Ja/Nej] Tilbudsgiver skal stille online support forum til rådighed for brugere af LMS-systemet, modereret af tilbudsgiver.

3. [Ø] Ordregiver ønsker en startpakke bestående af vejledninger til målgrupperne: Undervisere og studerende. Med startpakke forstås, at materialet introducerer nye brugere på et sådant niveau, at vedkommende kan komme i gang med at bruge LMS’et. Materialet skal bestå af åbne filer (fx MS Word), således at Ordregiver kan målrette det til egne brugere, udbygge det, og oversætte det efter behov. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

4. [Ø] Ordregiver ønsker adgang til videovejledninger på nettet i brugen af LMS’ets kernefunktioner – med speak som minimum på engelsk, dertil gerne dansk.

Beskrivelse: …

5. [Ø] Der ønskes en kontekstafhængig hjælp-funktion integreret i LMS’et. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

Side 24 af 59


18. Brugervenlige system- og handlingsmeddelelser

System- og handlingsmeddelelser er meddelelser fra LMS’et til brugeren, der orienterer brugeren om udfaldet af en handling, anviser næste trin og hjælp.

1. [MK Ja/Nej] System- og handlingsmeddelelser skal være skrevet i et letforståeligt sprog på dansk.

2. [MK Ja/Nej] System- og handlingsmeddelelser skal, såfremt der er tale om en brugerfejl, give anvisninger til brugeren om, hvad der er galt, og evt. hvad brugeren skal gøre for at løse problemet.

3. [Ø] Mulighed for at meddelelser som fx "Kontakt din systemadministrator" kan tilpasses med konkrete kontakt oplysninger på de lokale systemadministratorer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

4. [Ø] Det ønskes, at særlig funktionalitet, der kræver, at en browsers standardopsætning ændres for at virke, tilbyder selvinstruerende opsætningsguider. Guiderne skal som minimum kunne hjælpe den almindelige bruger (fx studerende eller underviser) med at sætte sin browser op til at kunne afvikle funktionaliteten. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

5. [Ø] Det ønskes, at særlig funktionalitet, der kræver tilføjelsesprogrammer eller browser-plugins for at virke, tilbyder selvinstruerende opsætningsguider, således at den almindelige bruger (fx studerende eller undervisere) hjælpes med at sætte sin computer og browser op til at kunne afvikle funktionaliteten. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

6. [Ø] Der ønskes opsætningsguider til de mest udbredte browsere på markedet (MS Internet Explorer, MS Edge, Mozilla Firefox, Apple Safari, Google Chrome eller tilsvarende). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

Side 25 af 59


19. Brugergrænseflade

19.0 StartsidenLMS’ets startside skal sikre, at brugeren kan skabe sig et overblik over de rum (herunder kursusrum/grupperum), meddelelser, nyheder, notifikationer, aktiviteter mm., der er relevante for den enkelte bruger.

1. [MK Ja/Nej] LMS’et skal indeholde en personlig, konfigurérbar startside, der giver mulighed for at vise:a: Alle de rum, brugeren er tilknyttet. a1: Aktuelle kursusrum/forløb a2: Tidligere kursusrum/forløbb: Nyheder, beskeder og notifikationer på rum- og systemniveau (se punkt 19.2)c: Brugerens aftaler og deadlines, der er oprettet i LMS’et (se punkt 19.2)

2. [MK Ja/Nej] Det skal være muligt for systemadministratorer/redaktører at lægge faste elementer ud på startsiden, der ikke kan fravælges eller skjules af brugeren. Disse elementer skal kunne differentieres ud fra brugerens roller.

3. [ØHP] Det ønskes, at brugere (med rollen studerende, underviser, instruktør m.fl.) kan sortere og administrere synligheden på Startsiden af de rum mm., de har adgang til. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

19.1 Tilgængelighed1. [MK Ja/Nej] LMS’et skal være designet efter principperne om responsive web design for at

øge læsbarhed og funktionalitet på skærme med forskellige opløsninger og side-højde-forhold.

2. [MK Ja/Nej] LMS’ets tilgængelighed skal give brugere med funktionsnedsættelser mulighed for at bruge systemet.

3. [Ø] Det ønskes, at LMS’et overholder Web Accessibility Guidelines (WCAG 2.0) på niveau AA. Se evt. mere her: http://www.w3.org/WAI/ . Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

19.2 Markering af meddelelser, notifikationer, nyheder og deadlinesVed nyheder forstås nye (endnu ikke set af brugeren) beskeder, informationer, indlæg (diskussionsfora, blogs, wikis), materialer/filer (se punkt 29), indkomne besvarelser (for instruktør/underviser), nye brugere mm. på system- og rum niveau, samt nye deadlines (afleveringsfrister for opgaver, tests, peer review eller tilsvarende).

1. [MK Ja/Nej] LMS’et skal kunne vise en oversigt over nyheder.

2. [ØHP] Det ønskes, at nyheder og deadlines i LMS’et markeres med flag eller tilsvarende, og at markeringen som minimum bevares, indtil brugeren har åbnet dokumentet

Side 26 af 59

http://www.w3.org/WAI/


eller markeret indlægget/nyheden som læst, eller indtil deadline er overskredet eller den tilhørende aktivitet er gennemført. Disse elementer skal kunne differentieres ud fra brugerens roller. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

3. [ØHP] Det ønskes, at deadlines for opgaveaflevering kan udløse remindere (i form af en nyhed/notifikation defineret af afsender og/eller modtager) ved nærmere fastsat tidsinterval forud for afleveringsfristen. Tilbudsgiveren bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

4. [ØHP] Mulighed for at kunne abonnere på rum og diskussionsfora. Ved abonnere forstås, at brugeren får besked pr. e-mail, når der er nyheder, med link til det/de nye indlæg. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

5. [ØHP] Mulighed for at kunne abonnere på materialer/filer fra et rum. Ved abonnere forstås, at brugeren får besked pr. e-mail når der er nye materialer/filer, med link til det/den nye materiale/fil. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

6. [ØHP] Mulighed for at kunne abonnere på blogs. Ved abonnere forstås, at brugeren får besked pr. e-mail, når der er nyheder med link til det/de nye poster. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

7. [ØHP] Mulighed for at kunne abonnere på wiki’er. Ved abonnere forstås, at brugeren får besked pr. e-mail, når der er nyheder med link til den/de nye sider. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: …

8. [Ø] Det ønskes i øvrigt, at den enkelte bruger kan vælge imellem forskellige måder at modtage notifikationer om nyhederne på. Eksempelvis i en mail (gerne med mulighed for en daglig ’opsamlingsmail’), via RSS feed, SMS, som push notifications i en app, i et socialt medium, eller andetsteds. Tilbudsgiver bedes beskrive, hvilke muligheder der er for at modtage notifikationer vedr. forskellige typer af nyheder. Beskrivelse: …

19.3 SøgefunktionLMS’et skal indeholde en søgefunktion, der hjælper brugeren med at fremfinde rum, filer/dokumenter, opslag, informationer mm.

1. [MK Ja/Nej] LMS’et skal indeholde søgefunktioner (simpel, udvidet og avanceret) som i få trin kan fremsøge rum.

2. [MK Ja/Nej] LMS’et skal kunne give en konfigurérbar oversigt over samtlige synlige udbudte rum i LMS’et. Oversigten skal kunne begrænses på <grupperingsnøgle>.

3. [MK Ja/Nej] Det ønskes, at LMS’et indeholder søgefunktion, hvormed den enkelte bruger kan fremsøge indhold i de enkelte rum, som vedkommende selv har læserettighed til, inkl. filer, læringsobjekter, tests, indhold genereret af brugerne, beskeder og tilsvarende.

Side 27 af 59


4. [Ø] Det ønskes, at LMS’et indeholder søgefunktion til at fremsøge grupperum (dvs. de grupperum, som den aktuelle bruger har adgang til). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 28 af 59


20. Opbygning, branding, menu og funktioner

1. [MK Ja/Nej] LMS’et skal give mulighed for valg mellem flere ’kursusskabeloner’ (både default- og brugerdefinerede skabeloner) som udgangspunkt for masse-oprettelse af rum. Kursusskabelonen skal give mulighed for at definere farvevalg, grafisk layout, menustruktur, tilgængelig funktionalitet, samt tilføje indhold og links til alle rum, der oprettes ud fra kursusskabelonen.

2. [MK Ja/Nej] LMS’et skal, uanset brug af kursusskabelon ved oprettelse af rummet, give administrator eller underviser i rummet mulighed for, via den grafiske brugergrænseflade, at tilrette sit eget rum mht. farve, knapper, logo og ikoner.

3. [MK Ja/Nej] Der skal desuden være nem mulighed for (på systemadministratorniveau) at differentiere tilgængeligheden af funktionalitet for forskellige brugergrupper, på tværs af kursusskabeloner.

4. [ØHP] Der skal være mulighed for individuel branding af uddannelser/afdelinger via farvevalg og grafisk layout samt differentieret visning af elementer, på de sider der ikke er en del af rum (startsiden, og tilsvarende sider).Beskrivelse: …

5. [ØHP] Mulighed for (på rumsniveau) at vælge mellem forskellige typer af visninger som fx knapmenu eller træstruktur. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

6. [ØHP] Det ønskes, at brugere (uanset læringsrolle) kan sætte bogmærke ved ethvert indholdselement i et rum, sådan at brugeren let kan finde tilbage. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

7. [ØHP] Brugere skal, uanset deres rolle, have mulighed for at oprette/redigere en personlig profil, med mulighed for at præsentere sig selv fagligt og socialt (og inkl. foto/portræt), ved interaktion med andre profiler. Profilbillede skal optræde i kollaborative værktøjer, som fx blogs og diskussionsfora. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

8. [ØHP] Mulighed for at navigere via browserens ’back’ eller ’forward’ funktion. Således at man til enhver tid kan komme til et vilkårligt sted i LMS’et ved få klik. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

9. [ØHP] Mulighed for at kopiere et helt rum eller dele af en struktur (fx opsætning og indhold, eller opsætning og dele af indhold) til et nyt rum. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

10. [Ø] Det ønskes, at det visuelle design fremmer intuitiv brug af LMS’et vha. konsekvent brug af ikoner og symboler. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

Side 29 af 59


11. [Ø] Mulighed for at arkivere et helt rum som en fil, der på et senere tidspunkt kan importeres i LMS’et igen til et rum. Tilbudsgiver bedes beskrive, hvorledes ønsket opfyldes.Beskrivelse: …

Side 30 af 59


21. Styring af roller i rum

Konfigurering og styring af roller og adgang til funktionalitet i LMS’et.

1. [MK Ja/Nej] Rolletildeling på de ikke-administrative roller skal kunne ske på kursusrumsniveau, dvs. en slutbruger kan være studerende i ét kursusrum, men underviser i et andet.

2. [MK Ja/Nej] Brugere med rollen ”Underviser” skal med et enkelt klik kunne se det samme, og have de samme rettigheder og muligheder, som brugere med rollen ”studerende” i et givent rum.

3. [MK Ja/Nej] Det ønskes, at det for systemadministrator er enkelt at skabe sig overblik over, hvilke personer der besidder de administrative roller. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

4. [MK Ja/Nej] Mulighed for at systemadministrator fra LMS’et kan kommunikere udelukkende med de administrative roller i LMS’et hhv. i det enkelte rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

5. [MK Ja/Nej] Mulighed for at tildele anonym direkte adgang med læserettigheder til et rum uden login (gæsteadgang).

6. [ØHP] Det ønskes, at styring af redigeringsrettigheder kan foregå på både dokumentniveau og rumniveau. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [ØHP] Mulighed for at tildele rettigheder til at administrere en gruppe, uden at give adgang til alle grupper. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

8. [ØHP] Mulighed for at tildele rettigheder til at uploade materiale i et kursusrum, uden at give rettigheder til at redigere i eksisterende materiale i kursusrummet. Tilbudsgiveren bedes beskrive hvordan ønsket imødekommes. Beskrivelse: ...

9. [Ø] Mulighed for at den enkelte bruger (uanset læringsrolle) i et givent rum kan vælge at kommunikere med én type læringsrolle, fx udelukkende med undervisere eller udelukkende med studerende. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

Side 31 af 59


22. Optimeret workflow

Ordregivers forståelse af funktionalitet: Ved workflow forstås de trin, brugeren skal gennemføre under anvendelsen af LMS’ets forskellige funktioner og værktøjer.

1. [ØHP] Det ønskes, at workflows er optimerede mht. antal klik, og er intuitivt og logisk for brugeren. Tilbudsgiver bedes beskrive, hvorledes ønsket imødekommes.Beskrivelse: ...

2. [ØHP] Mulighed for at default-settings for formularer i systemet (fx formular til oprettelse af test, formular til upload af fil) kan defineres af systemadministrator. Således at forskellige default-settings kan anvendes på forskellige uddannelser og andre organisatoriske enheder i Ordregiver. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

3. [ØHP] Wizards som (via eksempler og kortfattede vejledningstekster) guider brugeren igennem komplekse processer med flere trin, hvor masse commit ikke er muligt eller relevant, fx opsætning af peer assessment. Tilbudsgiveren bedes beskrive hvordan, og for hvilken funktionalitet, ønsket imødekommes. Beskrivelse: ...

4. [ØHP] Mulighed for at have flere vinduer, faner, bokse åbne samtidig, således at brugeren kan udføre parallelle processer. Tilbudsgiveren bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

5. [Ø] Mulighed for ’masse commit’, dvs. at man får en formular på skærmen, hvor man kan foretage forskellige valg og udfylde punkter, og først til slut i formularen gemmer/submitter. Dette skal ses som modsætning til en række forskellige trin i en procedure, hvor man foretager et valg ad gangen, submitter og fortsætter. Tilbudsgiveren bedes beskrive hvordan, og for hvilken funktionalitet, ønsket imødekommes. Beskrivelse: ...

6. [Ø] Mulighed for at funktioner kan grupperes af systemadministrator. Således at der fx kun findes ét workflow (én formular) til opgaveaflevering, hvor brugeren (underviser) har mulighed for at til/fravælge fx kvittering, kommentarer, plagiattjek, gruppeaflevering og tilsvarende funktionalitet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

Side 32 af 59


23. Asynkron kommunikation

23.1 DiskussionsforumDiskussionsfora er et værktøj til asynkron kommunikation, hvor indlæggene optræder i diskussionstråde, og hvor det er muligt at se hinandens bidrag samt respondere på andres bidrag.

1. [MK Ja/Nej] Administrator eller underviser i et rum skal selv kunne oprette og tilknytte diskussionsfora til rummet.

2. [MK Ja/Nej] Administrator eller underviser i et rum skal selv kunne oprette og tilknytte diskussionsfora til grupperum i rummet.

3. [MK Ja/Nej] Diskussionsfora skal indeholde mulighed for filudveksling (dokumenter, lyd, billede, video).

4. [MK Ja/Nej] Diskussionsfora skal indeholde en teksteditor, der opfylder krav fra punkt 16.2.

5. [ØHP] Administrator eller underviser i et rum skal kunne få statistik på antal indlæg pr. fora og pr. studerende.

Beskrivelse: …

6. [ØHP] Mulighed for at administrator eller underviser i et rum kan give tilladelse til at studerende kan oprette diskussionsfora og sætte indstillinger herfor. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

7. [Ø] Administrator eller underviser i et rum skal kunne til-/frakoble mulighed for anonyme indlæg.Beskrivelse: …

8. [Ø] Det skal være muligt at indstille start- og sluttidspunkt for bidrag i diskussionsfora.

Beskrivelse: …

9. [Ø] Mulighed for at brugere med alle roller kan få vist, hvem der har læst (åbnet) deres indlæg. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

10. [Ø] Mulighed for at anvende samme diskussionsforum i flere kursusrum/rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

11. [Ø] Mulighed for printvenlig udskrift af indhold i diskussionsfora. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: …

12. [Ø] Mulighed for at indstille start- og sluttidspunkt, dels for oprettelse og redigering af indlæg og dels for hvornår indlæg kan læses/åbnes. Beskrivelse: ...

Side 33 af 59


23.2 E-mailLMS’et skal understøtte afsendelse og modtagelse af emails i LMS’ets indbyggede mailsystem og i et eksternt mailsystem, fx MS-Exchange/Outlook.

1. [MK Ja/Nej] Brugeren skal kunne afsende e-mails (med vedhæftede filer samt interne og eksterne links) fra rummet til afgrænsede grupper (enkeltpersoner, grupperum, personer med samme læringsrolle (ex. studerende, underviser, instruktør), som er tilknyttet det pågældende rum.

2. [MK Ja/Nej] Brugeren skal kunne afsende e-mails med vedhæftede filer samt interne og eksterne links, til ekstern mailserver.

3. [MK Ja/Nej] Afsenderen skal kunne få kvittering for afsendt e-mail eller automatisk selv modtage den afsendte e-mail.

4. [ØHP] Mulighed for at sende til ’kursus-e-mail’ direkte fra Outlook (eller tilsvarende system), så der kan sendes til alle deltagere i et rum, alle brugere med en bestemt rolle, eller tilsvarende, uden at logge på LMS’systemet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

5. [Ø] Det ønskes, at afsender manuelt kan tilføje modtagere, der ikke er oprettet i LMS’et. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

6. [Ø] Mulighed for, fra LMS’et, at vælge en ’noreply’ afsender, så der ikke kan svares. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

23.3 Voice-mailMed ’voice-mail’ forstås et værktøj, der gør det muligt for brugere at udveksle lydfiler med stemmeoptagelser.

1. [Ø] Modtageren skal kunne afspille modtagne filer med stemmeoptagelser direkte i LMS’et.Beskrivelse: …

2. [Ø] Mulighed for at brugeren kan lave stemmeoptagelser online, og afsende eller dele filerne fra rummet til afgrænsede grupper (enkeltpersoner, grupperum, brugere med samme læringsrolle (ex. studerende, instruktør) som er tilknyttet det pågældende rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

23.4 BlogsBlogs er websider, hvor brugeren kan skrive indlæg, og kommentarer på andres indlæg.

Indlæggene dateres og sorteres efter dato. LMS’et placerer det nyeste blogindlæg øverst.

Side 34 af 59


1. [ØHP] LMS’et skal indeholde eller give mulighed for at integrere blogfunktion. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

2. [ØHP] Det skal være muligt at sætte adgangsrettigheder for blogs og rettigheder mht. at redigere, slette og læse indlæg samt kommentarer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

3. [ØHP] Det skal være muligt for flere brugere at være medlem af en blog og kunne skrive indlæg til denne. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

4. [ØHP] Bloggen skal indeholde en teksteditor, der opfylder krav fra 16.2. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

5. [ØHP] Det skal være muligt at sætte indeksering af indlæg til uger hhv. måneder. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

6. [ØHP] Det skal være muligt at sætte adgangsrettigheder for blogs og rettigheder mht. at redigere, slette og læse indlæg samt kommentarer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [ØHP] Mulighed for at abonnere på blogs. Ved abonnere forstås, at brugeren får besked pr. e-mail eller via RSS-feed når der er nye indlæg i bloggen, med link til det/de nye indlæg. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

8. [Ø] Mulighed for at blogs kan oprettes af brugere på alle niveauer, både indenfor et rum, i grupperum og uafhængigt af rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

9. [Ø] Mulighed for at vælge start- og sluttidspunkt, dels for skrivning af indlæg og kommentarer i bloggen, og dels for læsning. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

10. [Ø] Mulighed for printvenlig udskrift af indhold fra bloggen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

11. [Ø] Mulighed for at en bruger kan oprette forskellige kategorier/emner i bloggen, således at brugeren kan skrive om flere emner i samme blog. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: …

12. [Ø] Mulighed for at brugeren kan føje tags til de enkelte blogindlæg. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: …

Side 35 af 59


13. [Ø] Mulighed for at foretage søgninger i blogs baseret på de indtastede tags. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: …

14. [Ø] Mulighed for at gøre en blog synlig uden login. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

23.5 Logbog (studie/lærings-logbog)Logbog er websider, hvor brugeren kan skrive indlæg og kommentarer på egne indlæg, og administrator eller underviser i rummet kan skrive kommentarer. Indlæggene dateres og sorteres efter dato med det nyeste indlæg øverst.

1. [MK Ja/Nej] LMS’et skal indeholde eller give mulighed for, at studerende kan føre en personlig logbog, hvor underviser kan læse og skrive kommentarer.

2. [MK Ja/Nej] Bloggen skal indeholde en teksteditor der opfylder krav fra 16.2.

3. [MK Ja/Nej] Mulighed for at tilknytte Rubriks (jfr: https://en.wikipedia.org/wiki/Rubric_(academic) ).

4. [Ø] Mulighed for at logbøger kan oprettes af brugere på alle niveauer, både indenfor et rum, i grupperum og uafhængigt af rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

5. [Ø] Mulighed for printvenlig udskrift af indhold fra logbøger/Logbøger. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

6. [Ø] Mulighed for at brugeren kan tilføje tags til de enkelte indlæg. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [Ø] Mulighed for at foretage søgninger i logbøger baseret på de indtastede tags. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

8. [Ø] Mulighed for oprettelser og redigering af faner i logbøger. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

23.6 WikiEn wiki er et værktøj, der tillader brugeren at oprette og redigere websider samt indlejre multimedieindhold i form af både lyd, billede, video, tekst og tilsvarende

1. [ØHP] LMS’et skal indeholde eller give mulighed for at integrere en wikifunktion.Beskrivelse: …

2. [ØHP] Det skal være muligt at sætte adgangsrettigheder for wikier samt rettigheder mht. hvem der kan oprette, slette og redigere sider i wikien.

Side 36 af 59

https://en.wikipedia.org/wiki/Rubric_(academic)


Beskrivelse: …

3. [ØHP] Det skal være muligt for flere brugere at være medlem af en wiki og kunne oprette og redigere i wikisider.Beskrivelse: …

4. [ØHP] Wikien skal indeholde en teksteditor der opfylder krav fra 16.2.Beskrivelse: …

5. [ØHP] Mulighed for at indstille start- og sluttidspunkt dels for oprettelse og redigering af sider og dels for læsning. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

6. [ØHP] Mulighed for at tilknytte Rubrics. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [Ø] Mulighed for at Wiki’er kan oprettes af brugere på alle niveauer, både indenfor et rum, i grupperum og uafhængigt af rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

8. [Ø] Der ønskes ‘Save as draft’ (lock for editing) vs. ‘Submit’ funktionalitet – således at den studerende gives mulighed for at arbejde med og færdiggøre en wiki-side, før den gøres tilgængelig for kommentering og evaluering (af underviser) – og for evt. redigering af andre kursusdeltagere. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

9. [Ø] Mulighed for printvenlig udskrift af indhold i wikien. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

10. [Ø] Mulighed for at wikier kan eksporteres i følgende formater: Html, et andet rum i samme LMS, en pdf og Word fil. Tilbudsgiveren bedes beskrive, hvorledes og i hvilke filformater wikien kan eksporteres, og hvorledes den herefter kan publiceres.Beskrivelse: …

11. [Ø] Mulighed for at Wikier kan gøres synlige uden login til LMS. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

23.7 Meddelelser Meddelelser muliggør synlig information til platformens brugere centralt samt i det enkelte rum.

1. [MK Ja/Nej] Meddelelser skal indeholde en teksteditor, der opfylder krav fra 16.2.2. [MK Ja/Nej] Meddelelser skal kunne publiceres for brugerne alle relevante steder i LMS’et,

også på forsiden og undersider direkte under forsiden.3. [MK Ja/Nej] Administration, redigering og publicering/udsendelse af meddelelser skal

kunne styres af brugerrettigheder.4. [MK Ja/Nej] Mulighed for at oprette en meddelelse i det enkelte kursusrum eller rum.

Side 37 af 59


5. [MK Ja/Nej] Mulighed for at sætte start- og slutdato for synliggørelse af en meddelelse.6. [MK Ja/Nej] Mulighed for at oprette samme meddelelse i flere rum i en arbejdsgang.

7. [MK Ja/Nej] Mulighed for at meddelelser også kan udsendes som mail.8. [ØHP] Mulighed for at adressere meddelelser til forskellige brugergrupper (fx alle

brugere, studerende, undervisere, vejledere, medarbejdere, studieadministration, uddannelse, uddannelsessted, lokation, afdeling, kursusrum, grupperum). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

23.8 SMSSMS-værktøj muliggør afsendelse af sms-beskeder.

1. [ØHP] Der skal findes eller kunne integreres et modul, hvorved underviser eller administrator i et rum kan afsende sms-besked fra rummet til enkeltpersoner og grupperum, som er tilknyttet det pågældende rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

2. [ØHP] Studerende, der ikke har oplyst mobiltelefonnummer, skal kunne modtage beskeden som e-mail. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

3. [ØHP] Ordregiver ønsker at LMS-systemet kan udsende SMS’er på vegne af et af Ordregivers -mobilnummer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 38 af 59


24. Synkron kommunikation

24.1 Webkonferencesystem Ved Webkonferencesystem forstås et softwareprogram til udveksling af tale, billede, tekst, video mm. i realtid.

1. [ØHP] Ordregiver ønsker at LMS’et kan integreres med et webkonferencesystem (fx Adobe Connect eller tilsvarende) via API. Tilbudsgiver bedes beskrive, hvilke webkonferencesystemer der kan integreres med, og hvorledes de respektive integrationer er udført.Beskrivelse: …

24.2 Synkron skrivning i samme dokument Fildeling online med mulighed for at flere personer samtidigt kan skrive i dokumentet.

1. [MK Ja/Nej] Ordregiver ønsker, at der i LMS’et findes eller kan integreres et modul (WordOnline, GoogleDocs eller tilsvarende), der giver mulighed for at dele en fil (fx en wordfil, eller tilsvarende filtype), så flere brugere synkront kan skrive og gemme i dokumentet uden at overskrive hinandens arbejde. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

Side 39 af 59


25. Grupperum

Ved ’Grupperum’ forstås et rum der er knyttet til en gruppe af studerende, og som måske, måske ikke findes integreret i et andet rum eller kursusrum. Grupperummet understøtter samarbejde imellem studerende.

1. [MK Ja/Nej] LMS’et skal tilbyde grupperum med adgang til asynkrone kommunikationsværktøjer (inkl. send e-mail, blog, diskussionsforum).

2. [MK Ja/Nej] Grupperum skal indeholde mulighed for fildeling og håndtering af fælles dokumenter.

3. [MK Ja/Nej] Grupperum skal indeholde mulighed for fælles logbog.4. [MK Ja/Nej] Mulighed for at den studerende kan få et samlet overblik over alle sine

gruppetilknytninger og kan tilgå grupperne direkte fra deres startside.5. [ØHP] Det ønskes, at grupperum indeholder synkrone kommunikationsværktøjer (fx

webkonference, værktøj til synkrone skriveprocesser). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, herunder hvilke synkrone kommunikationsværktøjer der findes.Beskrivelse: …

6. [ØHP] Det ønskes, at grupperum indeholder wiki-værktøj. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

7. [ØHP] Mulighed for at brugere (uanset lærings- eller systemrolle) kan oprette grupperum som en selvstændig enhed i LMS’et. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

8. [ØHP] Mulighed for at administrator eller underviser i et rum kan tillade, at brugere med rollen studerende (eller tilsvarende underordnet rolle) selv opretter grupperum i det enkelte rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

9. [ØHP] Det ønskes, at den/de der ejer grupperummet selv kan sætte indstillinger på grupperummets faciliteter, samt administrere adgang og rettigheder til grupperummet. Såfremt grupperummet findes integreret i et kursusrum, ønskes det, at undervisere i kursusrummet pr. default har adgang. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

10. [ØHP] Det skal være muligt at sætte indstillinger på et grupperum, således at brugere (studerende og/eller undervisere) selv kan melde sig ind i grupperummet, og selv kan forlade grupperummet igen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

Side 40 af 59


26. Kursus-administration

26.1 Administration af kursusrummetAdministrative funktioner knyttet til hvert rum, som giver den enkelte bruger overblik over aktiviteter, undervisere og studerende i det aktuelle rum.

1. [MK Ja/Nej] Der skal være en kalenderfunktion til brug for notering af begivenheder, aktiviteter, opgaver og deadlines.

2. [MK Ja/Nej] LMS’et skal muliggøre en kalender til hvert rum samt en privat kalender, og den enkelte bruger skal kunne se alle poster fra samtlige rums kalendere samlet i brugerens kalender.

3. [MK Ja/Nej] LMS’et skal muliggøre visning af rummets deltagerliste (gerne med billeder af brugerne), hvor brugere med alle roller i rummet vises. Alle rummets bruge skal ha’ denne mulighed.

4. [ØHP] LMS’et skal muliggøre eksport (valg mellem mindst regneark-fil og PDF-fil) og download af rummets deltagerliste med rum-titel/navn som overskrift, aktuel dato, og hvor brugere med alle roller i rummet er oplistet. Evt. med valg af hvilke brugerdata-felter (fx navn, studienummer, e-mail, telefonnummer, foto) der skal medtages. Alle rummets bruge skal ha’ denne mulighed. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

5. [ØHP] Mulighed for at brugeren kan importere skemaoplysninger fra eksternt system (TimeEdit eller tilsvarende) til LMS’ets kalender, via RSS feed eller tilsvarende. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, og hvilke eksterne systemer der kan integreres med.Beskrivelse: …

6. [ØHP] Mulighed for at abonnere på LMS kalendere i eksterne kalendere fx i MS Outlook Calender, Apple Calender eller Google Calender. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [Ø] Mulighed for påmindelse om frister for aktiviteter og deadlines, der er lagt i kalenderen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, og hvilke frister der kan påmindes om. Beskrivelse: ...

8. [Ø] Der ønskes direkte adgang fra deltagerliste til profilside (se punkt 20.9). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

9. [Ø] Mulighed for at opslag i et rums kalender kan målrettes grupper (hvor en gruppe forstås som brugerne i et grupperum). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 41 af 59


26.2 StatistikStatistik over brugen af LMS’et og logning af aktiviteter.

1. [MK Ja/Nej] Underviser eller administrator i et rum skal have mulighed for at få statistik over hver enkelt brugers aktivitet i rummet. Tilbudsgiver bedes beskrive, hvorledes kravet er opfyldt.

2. [MK Ja/Nej] Underviser eller administrator i et rum skal have mulighed for at få statistik på enkelte elementer i rummet.

3. [MK Ja/Nej] Systemadministrator skal have mulighed for at få en oversigt over alle online brugere.

4. [MK Ja/Nej] Log af alle brugeres aktiviteter og af hvem, der foretager ændringer i enkelte rum, skal være tilgængelig for systemadministrator.

5. [MK Ja/Nej] Log af al aktivitet i LMS-et (på institutionsniveau, afdelingsniveau, uddannelsesniveau og tilsvarende niveauer) skal være tilgængeligt via API, således at det er muligt at lave statistiske analyser af sammenhænge i datamaterialet. Tilbudsgiver bedes beskrive, hvorledes kravet er opfyldt. Beskrivelse: ...

6. [ØHP] Studerende skal have mulighed for at få statistik over sin egen aktivitet i kurset (logon, view af filer, afleveringer og anden aktivitet), sammenlignet med de øvrige studerende på holdet. Tilbudsgiver bedes beskrive, hvorledes kravet er opfyldt.Beskrivelse: …

7. [ØHP] Underviser skal have mulighed for at følge op på enkelte studerende via e-mail eller tilsvarende, som er integreret med statistikvisningen. Tilbudsgiver bedes beskrive, hvorledes kravet er opfyldt. Beskrivelse: ...

8. [Ø] Mulighed for at underviser såvel som studerende kan få vist en grafisk fremstilling af det statistiske materiale i et givent rum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes, og hvilke data der kan vises grafisk fremstilling af. Beskrivelse: ...

Side 42 af 59


27. Portfolio – gruppe og individuel

Portfolio er en ’mappe’ til samling af dokumenter, video-, lyd- og billedfiler mm., der dokumenterer en læringsproces.

1. [MK Ja/Nej] LMS’et skal tilbyde oprettelse af personlig portfolio uafhængigt af rum.

2. [MK Ja/Nej] En bruger skal (uanset sin rolle) kunne give andre, også personer, der ikke er oprettet i LMS’et, adgang til sin portfolio.

3. [MK Ja/Nej] En bruger skal (uanset sin rolle) kunne give andre brugere adgang til at kommentere sin portfolio.

4. [MK Ja/Nej] Systemadministrator skal have mulighed for at kunne oprette skabeloner.5. [MK Ja/Nej] Det skal være muligt at eksportere portfolien, så en bruger kan tage den med

sig, når vedkommende forlader proffessionshøjskolen.6. [MK Ja/Nej] Brugeren skal kunne uploade indhold til portfolioen i form af både tekst, lyd-

og videofiler, billeder eller tilsvarende. Billeder, lyd og video skal kunne embeddes/indlejres.7. [ØHP] Mulighed for at oprette en gruppe-portfolio, indeholdende tilsvarende

funktionalitet som i en personlig portfolio. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

8. [ØHP] Mulighed for, på administratorniveau, at låse en portfolio for redigering i en periode, fx i forbindelse med eksaminer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

9. [ØHP] Det ønskes, at portfolien kan anvendes til opbevaring og visning af resultater fra tests, projekter, kursusforløb mm. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

10. [Ø] Brugeren skal selv kunne tilrette portfoliens design og layout med billede, tekst og farvevalg. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

11. [Ø] Mulighed for at lave hierarkier af sider/undersider i portfolioen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

12. [Ø] Mulighed for at importere filer fra en mobil enhed til portfolien. Tilbudsgiveren bedes beskrive hvordan ønsket imødekommes.Beskrivelse: …

13. [Ø] Det ønskes, at en bruger (uanset sin rolle) kan give andre brugere adgang til at kommentere sin portfolios forskellige elementer/sider/undersider. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

Side 43 af 59


14. [Ø] Mulighed for at en studerende kan submitte en portfolio som en assignment i et kursusrum, således at den kan gøres til genstand for bedømmelse.

Beskrivelse: …

28. Test- og evalueringsværktøjer, samt survey funktion

28.1 TestsTests er en metode til formativ og summativ feedback og bedømmelse af de studerendes udbytte og viden samt af undervisningen.

1. [MK Ja/Nej] En underviser eller administrator i et læringsrum skal kunne koble tests og evalueringer til aktiviteterne i de enkelte læringsrum og studieforløb.

2. [MK Ja/Nej] LMS’et skal som minimum tilbyde følgende testtyper "multiple choice", "multiple answers", "fill-in-the-blank", sandt-falsk, "Hot spots" (fx udpege område på billede som korrekt svar), "Matching", "Ordering" og essay/kortsvar.

3. [MK Ja/Nej] LMS’et skal indeholde automatisk retning af spørgsmål af typen:"multiple choice", "multiple answers", "fill-in-the-blank", sand-falsk,"Hot spots" (fx udpege område på billede som korrekt svar),"Matching", "Ordering" og kortsvar.Testbesvarelserne skal kunne "scores" af LMS’et, og det skal være muligt at indføre en vægtning opgaverne i mellem.

4. [MK Ja/Nej] Mulighed for at oprette spørgsmål hvor både spørgsmålsteksten og svarmulighederne indeholder matematiske formler, billeder, grafik, video, lydklip, herunder fastholdelse af side-højde-forholdet på billeder, samt evt. mulighed for link til eksterne mediekilder.

5. [MK Ja/Nej] Der skal være auto-save funktion, således at testdeltagerens besvarelse (incl. alle markeringer i spørgsmål, samt teksten som skrives i essay eller kortsvarsspørgsmål) gemmes løbende.

6. [MK Ja/Nej] Det skal være muligt at vælge at give automatisk feedback (dvs. det skal også være muligt ikke at give feedback automatisk), med mulighed for links. Der skal kunne gives forskellig feedback afhængig af, om spørgsmålet er besvaret korrekt eller forkert.

7. [MK Ja/Nej] En underviser eller administrator i et læringsrum skal kunne oprette spørgsmåls-banker til genbrug af egne spørgsmål.

8. [MK Ja/Nej] LMS’et skal kunne randomisere spørgsmål i en test og svaralternativerne i multiple-choice- og multiple-answer-spørgsmål.

9. [MK Ja/Nej] Mulighed for at oprette banker af spørgsmål indenfor fag/uddannelse og styre adgangen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

Side 44 af 59


10. [MK Ja/Nej] Det skal være muligt at lave tests, der består af spørgsmål, der udtrækkes tilfældigt fra en eller flere spørgsmålsbanker.

11. [MK Ja/Nej] Det skal være muligt at sætte en tidsbegrænsning på tilgængeligheden af en test/evaluering/eksamen. Det skal kunne sættes med startdato og klokkeslæt til slutdato og klokkeslæt.

12. [MK Ja/Nej] Det skal være muligt at sætte den maksimale tid en testdeltager må anvende på gennemførelsen af hele testen. Det skal kunne sættes med intervaller af 5 minutters varighed til principielt - uendeligt.

13. [MK Ja/Nej] Det skal være muligt at vælge, om en testdeltager kun må tage testen en gang eller om testdeltageren må tage testen flere gange.Det skal være muligt at gennemtvinge, at en testdeltager skal gennemføre testen, efter den er åben – testen må i dette tilfælde ikke kunne lukkes og så startes op igen.Det omvendte skal også være muligt: Testen skal kunne sættes op således at en testdeltager kan lukke testen og LMS systemet ned og genoptage testen efter fornyet login.

14. [MK Ja/Nej] Der skal kunne laves statistik over besvarelserne, således at det er muligt at danne sig et indtryk af hvilke spørgsmål, der volder problemer.

15. [MK Ja/Nej] Det skal være muligt og vises tydeligt, hvor mange minutter der er tilbage af en test.

16. [ØHP] Det skal være muligt, at den studerende kan få at vide, hvor mange procent af opgaverne, de har svaret korrektBeskrivelse: …

17. [ØHP] Testresultater skal automatisk kunne opsamles og lagres i en ’logbog`.Beskrivelse: …

18. [ØHP] Mulighed for at vælge, at testdeltageren kan aflevere sin besvarelse til et spørgsmål i form af matematisk formel, billede, video, lydklip eller anden filtype. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

19. [ØHP] Mulighed for, efter et hold studerende har gennemført en test, at fjerne spørgsmål, således at de studerendes points automatisk opdateres til at afspejle den nye situation. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

20. [ØHP] Mulighed for, efter et hold studerende har gennemført en test, at ændre scoring og rigtig/forkert svarmulighed, således at de studerendes points automatisk opdateres til at afspejle den nye situation. Tilbudsgiveren bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

21. [ØHP] Mulighed for at eksportere testspørgsmål i formater, der er kompatible med andre læringssystemer. Beskrivelse: ...

Side 45 af 59


22. [ØHP] Mulighed for at underviser kan vælge flere forskellige indstillinger for feedback funktion og indhold. Det ønskes, at feedback kan omfatte de studerendes egne besvarelser med angivelse af korrekt/forkert svar, points, samt et eventuelt feedback. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

23. [ØHP] Mulighed for at testresultater inkl. bedømmeres kommentarer kan eksporteres i et format, der gør dem egnet til videre bearbejdning, fx i et regneark, uden at det eksporterede resultat indeholder uhensigtsmæssige kontrol- eller formateringskoder. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

24. [ØHP] Mulighed for at testspørgsmål kan skrives uden for LMS’et i en almindelig teksteditor og efterfølgende importeres til LMS’et. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

25. [Ø] Det skal være muligt at vælge, hvordan testen skal præsenteres for testdeltageren. Alle spørgsmål vises på en gang eller spørgsmål vises et ad gangen.

Beskrivelse: …

26. [Ø] Mulighed for, i forbindelse med Calculated Numeric-spørgsmål:a. at anvende dansk decimalkomma (som i 1,0) såvel som amerikansk decimal.b. at anvende præfiks: fx mm, km, ml etc.Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

27. [Ø] Mulighed for at spørgsmål fra eksterne testbanker (fra forlag eller tilsvarende) kan importeres til LMS’et. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

28. [Ø] Mulighed for gruppe-aflevering. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

28.2 System til digital eksamenFunktionalitet der gør det muligt at gennemføre en test uden adgang til internet eller til filer og applikationer på computeren.

1. [ØHP] Mulighed for at en studerende kan gennemføre en eksamen uden adgang til filer eller applikationer og uden adgang til internet på computeren, via integration med eksternt system (fx WiseFlow). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

2. [Ø] Mulighed for at en studerende kan gennemføre en test med adgang til filer og applikationer på computeren uden samtidig adgang til internet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 46 af 59


28.3 Spørgeskema (Survey)Survey er funktionalitet til indhentning af strukturerede- og ustrukturerede data fra brugere af et rum til videre bearbejdning og analyse.

1. [MK Ja/Nej] En underviser eller administrator i et rum skal kunne koble surveys til aktiviteterne i de enkelte rum og studieforløb.

2. [MK Ja/Nej] LMS’et skal tilbyde følgende spørgsmålstyper "multiple choice", "multiple answers", "fill-in-the-blank", "Hot spots" (fx udpege område på billede som korrekt svar), "Matching", "Ordering", ”Opinion Scale/Likert” (agree–disagree) kortsvar og fritekstsvar.

3. [MK Ja/Nej] En underviser eller administrator i et rum skal kunne oprette egne spørgsmålsbanker til genbrug af egne spørgsmål.

4. [MK Ja/Nej] Det skal være muligt at sætte en tidsbegrænsning på tilgængeligheden til et survey. Det skal kunne sættes med startdato til slutdato.

5. [MK Ja/Nej] Det skal være muligt at vælge, om en respondent kun må besvare surveyet én gang eller om respondenten må besvare surveyet flere gange. Det skal være muligt at sætte en max antal gange surveyet må tages af den samme respondent.

6. [MK Ja/Nej] Survey skal kunne gennemføres med anonyme respondenter. Det vil sige, at det ikke er muligt at føre den enkelte besvarelse tilbage til en bestemt respondent.

7. [MK Ja/Nej] Surveyresultater skal automatisk kunne opsamles og lagres.8. [MK Ja/Nej] Surveyresultater skal kunne eksporteres i et format, der gør dem egnet til

videre bearbejdning i fx et regneark.9. [MK Ja/Nej] Der skal kunne laves statistik over den enkelte besvarelse og summariske

statistikker over alle besvarelser som helhed.10. [ØHP] Mulighed for at kunne lave forgreninger afhængig af tidligere svar. Tilbudsgiver

bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

11. [Ø] Mulighed for at oprette spørgsmål hvor både spørgsmålsteksten og svarmulighederne kan indeholde billeder, video, lydklip og andre vedhæftede filer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

12. [Ø] Mulighed for at sende automatiske påmindelser pr. e-mail til de respondenter, som inden for en given tidsramme ikke har besvaret surveyet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

13. [Ø] Mulighed for at vælge hvordan surveyet skal præsenteres for respondenten, dvs. om alle spørgsmål vises på en gang eller spørgsmål vises et ad gangen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

14. [Ø] Mulighed for at vælge at respondenten kan aflevere sin besvarelse til et spørgsmål i form af et billede, video, lydklip eller anden vedhæftet fil. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 47 af 59


15. [Ø] Mulighed for at oprette spørgsmåls-banker indenfor fag/uddannelse og importere herfra. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

16. [Ø] Mulighed for at oprette spørgsmåls-banker på system-niveau og anvende direkte i et kursusrum uden import. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

17. [Ø] Mulighed for at eksportere spørgsmål i formater, der er kompatible med andre LMS systemer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

18. [Ø] Mulighed for at underviser eller administrator i et rum kan anvende adaptive funktioner som automatisk valg af spørgsmål baseret på foregående svar. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

19. [Ø] Mulighed for at underviser eller administrator i et rum kan importere spørgsmål fra eksterne spørgsmålsbanker. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

20. [Ø] Mulighed for at spørgsmål kan skrives uden for LMS’et i en almindelig teksteditor og efterfølgende importeres til LMS’et. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

21. [Ø] Det ønskes, at surveys kan hente og integrere data fra enkelte kursusrum, og fra de studerendes, såvel som undervisers, log-on tid og tidsforbrug i kursusrummet. Log-on tiden bør kunne integreres i en automatisk genereret evalueringsrapport, således at man kan danne sig et indtryk af, om det er aktive, deltagende studerende der evaluerer, og i hvor høj grad underviser bruger platformen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 48 af 59


29. Håndtering af filer, fildeling m.m.

29.1 Filarkiv og fildelingFil-delings værktøjer understøtter muligheden for at uploade og downloade filer, såsom tekst, video, lyd og billeder, til eget og fælles brug samt styring af fælles dokumenter.

1. [MK Ja/Nej] LMS’et skal muliggøre rettighedsstyring af filer.

2. [MK Ja/Nej] Brugere skal kunne uploade flere filer ad gangen.3. [MK Ja/Nej] LMS’et skal muliggøre versionsstyring af filer.

4. [MK Ja/Nej] Der skal være mulighed for fildeling i tilknytning til et rum, således at alle brugere i rummet uanset rolle kan uploade filer til deling.

5. [MK Ja/Nej] Gængse dokumenttyper på Windows og Mac (billeder, Office-dokumenter og PDF-filer) skal kunne vises i browseren uden behov for at downloade først.

6. [ØHP] Brugere skal kunne uploade/downloade filer til/fra private mapper. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [ØHP] Brugere skal kunne uploade/downloade filer til/fra fælles mapper. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

8. [ØHP] Fil- og mappehåndtering, download/upload (også af hele mapper), skal kunne udføres som ’drag-and-drop’. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

9. [ØHP] Filarkivet skal tilbyde brugeren en publiceringsmulighed, hvor brugerne kan vælge at få tilgængeliggjort en PDF-version af filen via et genereret link – og denne funktion kan/skal været bundet til en brugerrettighed. LMS-systemet skal kunne konvertere gængse filer til PDF-kopi/version, og generere et link til PDF-filen, som brugeren kan kopiere og bruge videre, så ikke-registrerede brugere kan åbne/downloade PDF-filen med linket.

Beskrivelse: …

10. [ØHP] Det ønskes, at LMS’et kan håndtere ’pakkede filer’. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

11. [ØHP] Mulighed for, via kursusskabelon, at stille et fildelingssted (se punkt 29.1.6) til rådighed som standard ved masseoprettelse af kursusrum. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

12. [Ø] Mulighed for at uploade filer via netværksdrev (se punkt 8.3). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 49 af 59


13. [Ø] Mulighed for at sætte rettigheder på en fil så kun én bruger kan redigere den ad gangen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

14. [Ø] Mulighed for at sætte rettigheder på en fil så flere brugere kan redigere den samtidig. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

29.2 Upload og præsentation af materiale.1. [MK Ja/Nej] Administrator eller underviser i et rum skal kunne uploade filer,

såsom tekst, video, lyd og billeder, således at de præsenteres på sider i rummet, og kan downloades af brugere, som er tilknyttet rummet.

2. [ØHP] Mulighed for at brugere med enhver rolle, som er tilknyttet et rum, kan uploade filer, således at de præsenteres på sider i rummet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

3. [ØHP] Mulighed for versionsstyring af filer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

4. [ØHP] Mulighed for samtidig upload af flere filer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

5. [ØHP] Det ønskes, at LMS’et kan håndtere ’pakkede filer’. Tilbudsgiveren bedes beskrive hvordan ønsket imødekommes, og hvordan pakkede filer kan præsenteres i kursusrummet. Beskrivelse: ...

6. [Ø] Mulighed for rettighedsstyring af filer. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [Ø] Mulighed for at sætte rettigheder på en fil så kun én bruger kan redigere den ad gangen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes. Beskrivelse: ...

8. [Ø] Mulighed for at sætte rettigheder på en fil så flere brugere kan redigere den samtidig. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

29.3 Personlig kopi af filer m.m.1. [ØHP] Brugerne skal til enhver tid, og på en let måde, kunne tage en lokal kopi af sin

brugerprofil og samtlige tilhørende personlige dokumenter, filer og tilhørende data, pakket i en mappestruktur som en ZIP- eller RAR-fil.Beskrivelse: ...

Side 50 af 59


Side 51 af 59


30. Opgaver

30.1 OpgaveafleveringsfunktionUnderviser i et kursusrum skal have mulighed for at uploade en opgaveformulering som fil, og de studerende skal kunne hente opgaveformuleringen og aflevere opgavebesvarelser via opgaveafleveringsværktøjet.

1. [MK Ja/Nej] Underviser skal kunne uploade en eller flere filer med opgaveformuleringen, samtidig med at afleveringsstedet oprettes.

2. [MK Ja/Nej] Den studerende skal kunne uploade flere filer ad gangen ved opgaveaflevering.3. [MK Ja/Nej] Der skal kunne defineres tidspunkt, hvor opgaveformuleringens filer frigives og

hvornår besvarelsen skal være afleveret.4. [ØHP] Administrator eller underviser skal let kunne gøre de studerendes afleveringer

synlige for rummets øvrige studerende. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

5. [ØHP] Mulighed for gruppeafleveringer knyttet til Grupper værktøjet, hvor de (én eller flere) afleverede filer betragtes som den samlede gruppes aflevering. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

6. [ØHP] Mulighed for at lave forskudte afleveringstidspunkter for specifikke studerende. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [ØHP] Mulighed for at den studerende, som en del af afleveringsprocessen, kan tvinges til at åbne sin(e) afleverede fil(er) og bekræfte, at det afleverede er i orden. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

8. [ØHP] Det ønskes, at LMS’et kan vise og sende kvittering for aflevering til de studerende. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

9. [ØHP] Mulighed for at sætte begrænsning på hvilke(t) filformat(er) der kan afleveres i. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

10. [Ø] Mulighed for at opsætte kursusrummet således at opgaverne er anonyme for opgaverettere. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

11. [Ø] Mulighed for at kunne vælge en opsætning således at der kun kan afleveres, hvis brugeren er koblet op på bestemte netværk. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 52 af 59


12. [Ø] Mulighed for at gøre aflevering betinget af tilmelding til eksamen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

13. [Ø] Mulighed for at sætte begrænsning på størrelse og antal af uploadede fil(er). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

14. [Ø] Mulighed for at logge hvorfra en opgave er afleveret (internt/eksternt ip-segment). Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

30.2 PlagiattjekAfleverede opgaver skal kunne tjekkes for plagiering.

1. [MK Ja/Nej] LMS’et skal give mulighed for plagiattjek, via integration med gængse anti-plagiatsystemer. Tilbudsgiver bedes beskrive, hvilke plagiatsystemer der kan integreres med, og evt. hvilket plagiatsystem der indgår i tilbuddet.Beskrivelse: …

2. [MK Ja/Nej] Systemet skal kunne generere en rapport for hver fil, der er tjekket for plagiat.a: Der skal være reference til evt. matchende kilder, gerne i form af links.b: Rapporten skal indeholde en angivelse af, hvor mange procent der matcher med fundne kilder.Tilbudsgiver bedes beskrive, hvorledes der refereres til matchende kilder, og hvilke litteraturdatabaser der kan tjekkes imod.Beskrivelse: …

3. [MK Ja/Nej] Det skal være muligt at fravælge lagring i database ved plagiattjek af specifikke opgaver, da der kan være tale om fortrolige opgaver, der ikke må kunne genfindes.

4. [ØHP] Det skal være muligt at fravælge en kilde, der er identificeret ved første plagiattjek af en opgave og køre plagiattjek igen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommesBeskrivelse: ...

5. [ØHP] Det ønskes, at databehandlingen skal overholde EU's regler om Safe Habour. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommesBeskrivelse: ...

6. [ØHP] Det ønskes, at plagiattjek er en integreret del af workflowet omkring opgaveaflevering og feedback, således at brugeren samtidig har mulighed for at vælge plagiattjek fra ved opsætningen af en given opgaveaflevering. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommesBeskrivelse: ...

7. [ØHP] Mulighed for at genfinde kilder, der allerede eksisterer i Ordregivers database med links eller filnavn, således at man ved et match kan få vist originalkilden. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommesBeskrivelse: ...

Side 53 af 59


8. [ØHP] Mulighed for at tjekke imod yderligere databaser som Ordregiver har adgang til, inkl. Ordregivers biblioteks litteraturdatabase, og opgavedatabaser fra andre danske uddannelsesinstitutioner. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

9. [Ø] Mulighed for at sammenligne opgaver der submittes hos Ordregiver med leverandørens opgavedatabase. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

10. [Ø] Mulighed for, når afleveringsstedet oprettes, at angive den maximale filstørrelse. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

11. [Ø] Mulighed for at give studerende i et kursusrum adgang til at benytte plagiattjek-værktøjet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

30.3 Evaluering og feedbackSom en integreret del af workflowet skal det være muligt at give feedback og karakterer på opgaver og tests.

1. [MK Ja/Nej] Det skal være muligt i LMS’et at give individuel karakter og feedback på enkelte aktiviteter i et kursus.

2. [MK Ja/Nej] Der skal være mulighed for at give feedback på afleverede opgaver (inkl. tests) ved annotering direkte på opgaven, uden at bedømmeren har behov for at gemme opgaven lokalt på computer/tablet/device.

3. [MK Ja/Nej] Det skal være muligt at give differentieret feedback på en opgave i form af flere delkarakterer/feedback i samme opgave ud fra brugerdefinerede kriterier (Rubriks).

4. [MK Ja/Nej] LMS’et skal indeholde et værktøj, der giver en oversigt over karakterer og feedback i et kursus, med links til enkelte besvarelser.

5. [MK Ja/Nej] LMS’et skal kunne fremstille vægtet gennemsnit af flere karakterer i et kursus, ud fra brugerdefinerede settings.

6. [ØHP] Det ønskes, at karakterer, feedback og andre data vedr. bedømmelse af opgaver er tilgængelig via åbent API (fx til SIS), således at de automatisk kan overføres til et andet system. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

7. [ØHP] Mulighed for opsætning af kursusrummet således at flere kan rette den samme opgavebesvarelse, uden at de kan se hinandens feedback. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

8. [ØHP] Mulighed for opsætning af kursusrummet, således at opgavebesvarelserne er anonyme for opgaverettere. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommesBeskrivelse: ...

9. [ØHP] Mulighed for tilbagemelding på afleverede gruppe-projekter direkte til gruppen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

Side 54 af 59


10. [ØHP] Ordregiver ønsker, at undervisere kan gøre opgavebesvarelser/afleveringer til genstand for peer-review blandt udvalgte studerende, evt. et hold. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

11. [Ø] Mulighed for at give feedback i form af video som en integreret del af workflowet. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

12. [Ø] Mulighed for tilretning af LMS’et, således at karakterer kan indtastes og godkendes via Nem ID. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: ...

13. [Ø] Mulighed for at opdele en samling af opgavebesvarelser på flere bedømmere på en nem måde. Hvis flere opgaverettere parallelt retter de samme opgaver, skal opdelingen kunne være overlappende. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

31. Eksport af data ved udtræden/ophør

1. [ØHP] Ordregiver ønsker, at det er muligt at eksportere data om brugere, rumstruktur og andre af kundens data, dokumenter og indhold i LMS-systemet – fx i tilfælde af udtræden/ophør af kontrakten. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommesBeskrivelse: ...

32. Data om gennemførte studieaktiviteter og studiefremdrift

Ordregiver ønsker at studerende, undervisere og ledelse, på en nem måde, kan tilgå opsamlede/registrerede data om gennemførte studieaktiviteter, studiefremdrift og analyser heraf, fx ”Learning Analytics” og ”Predictive Analytics”.

1. [ØHP] LMS’et skal give mulighed for opsamling og registrering af data om studiefremdrift. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

2. [ØHP] LMS’et skal give mulighed for visning af data om studiefremdrift i oversigtsform, tabeller, grafisk og som rapporter. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

3. [ØHP] LMS’et skal kunne præsentere data om studiefremdrift skræddersyet til bl.a. disse målgrupper: Studerende/kursister, undervisere, studievejledere og ledelsen. Tilbudsgiver bedes beskrive, hvordan ønsket imødekommes.Beskrivelse: …

4. [ØHP] LMS’et skal give brugerne mulighed for på en let måde at se en oversigt over hvilke typer af data om brugerne og brugernes handlinger, transaktioner og aktiviteter som LMS-systemet logger/registrer. Tilbudsgiver bedes beskrive, hvordan ønsket

Side 55 af 59


imødekommes.Beskrivelse: …

33. Håndtering af korte kurser

Foruden længerevarende grunduddannelser og efter- videreuddannelser, afvikler Ordregiver flere hundrede kortere kurser hver år - kurser der varer fra nogle få timer til flere dage, og evt. med flere kursusgange.

Ordregiver ønsker at disse kurser kan håndteres/administreres i den tilbudte LMS-løsning.

Følgende opgavefaser indgår (inkl. styring af de tilhørende brugerroller og –rettigheder):

1. [Ø] Oprettelse af kurser med de nødvendige metadata.2. [Ø] Redigering af kursusbeskrivelser, evt. ud fra (redigérbare) skabeloner.

3. [Ø] Online publicering/markedsføring af udbudte kurser inkl. kursusbeskrivelser. Disse informationer skal også kunne publiceres på andre sites.

4. [Ø] Online tilmelding med tilmeldingsperiode, inkl. deltagerdata og betalingsoplysninger.

5. [Ø] Oprettelse af deltagerlister og udsendelse af bekræftelsesmails til deltagere, deltageres arbejdsgiver/chef og undervisere/kursusinstruktører.

6. [Ø] Online adgang til kursusmaterialer.7. [Ø] Gennemførelse af kursus (evt. som blended learning, dvs. med

kursusdeltagerne som brugere på LMS’et).8. [Ø] Gennemførelse af online-evaluering af kurset.

9. [Ø] Generering kursusbeviser, og udsendelse af mail med kursusbeviser til brugerne.

10. [Ø] Generering af faktura-grundlag, og overførelse af faktura-data til Ordregivers økonomisystem.

11. [ØHP] Udtræk af data om kurserne til statistikker, opfølgning m.m.Tilbudsgiver bedes samlet beskrive, hvordan ovenstående ønsker 33.1-33.11 imødekommes.Beskrivelse: ...

34. Brugervenlighed og ’usability’

Brugervenlighed og ’usability’ betyder i denne sammenhæng, at LMS-systemet er designet, så det i så stor udstrækning som muligt lever op til følgende krav til brugervenlighed for anvendelse af systemet, herunder brugergrænseflader og skærmbilleder:

Enkelhed, konsistens, opdagelighed, struktur, klarhed, kontrol, brugssignalering, tolerance og ergonomi, jf. også beskrivelserne i udbudsbetingelserne.

Side 56 af 59


1. [MK Ja/Nej] Tilbudsgiver skal, ved en on-site og real-time demonstration hos UCL i Odense, demonstrere nedenstående brugersituationer og funktion/workflow i det tilbudte LMS. Demonstrationen vil være grundlag for Ordregivers vurdering og evaluering af det tilbudte LMS’ brugervenlighed og ’usability’, og vil indgå som del af evalueringen af tilbuddet, jfr. udbudsbetingelserne.

Forudsætning for demonstration af nedenstående brugerscenarier er, at brugeren er logget ind og står på sin startside.

2. Tilpasning af startsideBrugeren ønsker en startside med hurtig adgang til:

1. Skema2. De vigtigste rum og dokumenter efter eget valg3. Nyheder og notifikationer fra rum valgt af brugeren med tilføjelse af links, foto,

indlejring af videoStudieadministrationen ønsker mulighed for at sende:

1. Nyheder og notifikationer, som ikke kan fravælges af brugeren og som er synlig i en nyheds/notifikationsoversigt i en angivet periode

Demonstrer ved opsætning af startside og indlægning af forskellige typer af nyheder og notifikationer, hvordan dette kan udføres.

3. Tilpasning af rumforsiderDer ønskes en rumforside med hurtig adgang til:

1. Senest oprettede eller opdaterede dokumenter/elementer2. Hurtig adgang til dokumenter/elementer udvalgt af brugere3. Nyheder og notifikationer med markering af nye/ulæste elementer4. Mulighed for adgang til websider, synkrone og asynkrone samarbejdsværktøjer, foto,

indlejring af videoDemonstrer ved opsætning af rumforside og indlægning af de forskellige elementer, hvordan dette kan udføres.

4. DokumenthåndteringBrugeren ønsker at:

1. Oprette en ny mappe2. Oprette et nyt dokument, som skal redigeres i MS-Word3. Tilpasse dokument, så tre andre brugere har adgang til at redigere i det

Demonstrer, hvordan ovenstående kan udføres.Efter oprettelse redigeres dokumentet i:

Side 57 af 59


4. Google Chrome browseren.5. Firefox browseren.

Demonstrer, hvordan ovenstående kan udføres.Brugeren ønsker at arbejde videre på et MS-Office dokument, som lige nu findes i brugerens pc/dropbox/google drev.

6. Upload fra de nævnte dokumentplaceringer og rediger dokumentet i LMS’et.Demonstrer, hvordan ovenstående kan udføres.

5. SøgningDemonstrer hvilke muligheder, der er for at søge efter dokumenter, nyheder, notifikationer, forumindlæg mm. Følgende søgninger skal indgå:

1. Søgning bredt i den del af installationen brugeren har adgang til evt. med anvendelse af filtre.

2. Søgning i afgrænset område.3. Søgning på navn eller andre parametre f.eks. dato for oprettelse, ejers navn, etc.

6. PortfolioDemonstrer portfolio-funktionen. Herunder mulighed for at:

1. Søge/filtrere i portfolio.2. Tilføje elementer som video og lydfiler.3. Henvise til eksterne elementer f.eks. websider/blog/wiki.4. Eksportere portfolioen i et standardformat.5. Åbne portfolioen for eksterne brugere.

7. EvalueringDemonstrer evalueringsfunktionen, herunder:

1. Oprettelse af evalueringsskema med brug forskellige spørgsmålstyper.2. Anvendelse af foto/video i spørgsmål.3. Anvendelse af matematiske og andre specialtegn.4. Automatisk rettelse og tilbagemelding til den studerende.5. Deling af spørgsmål i spørgsmålsbank.6. Statistik på besvarelserne.

8. Tilpasning til /Smartphone/iPad/Tablet i AppDemonstrer hvordan nyheder og notifikationer vises på små skærme, med særligt henblik på:

1. Opmærksomhed

Side 58 af 59


2. Læsbarhed 3. Mulighed for oprettelse af nye nyheder og notifikationer

Demonstrer mulighederne på små skærme for:4. Dokumenthåndtering.5. Gennemføre evaluering og modtage tilbagemelding på evaluering.

9. Udskrivning/eksport af deltagerlister Demonstrer muligheden for at:

1. Generere deltagerlister fra rum ud fra forskellige udvalgskriterier/filtre.2. Udskrive/eksportere disse lister til viderebearbejdning.

<slut>

Side 59 af 59

it.ucl.dkit.ucl.dk/lmstender/009 - bilag 2 kravspecifikation.docx · web viewdette dokument...

Documents