Forprojekt nyt studiesystem Behovsanalyse af et nyt ......(LMS). Opgaven omfatter også udarbejdelsen af et økonomisk overslag over de forventede udgifter ved udvik-lingen af de respektive

Forprojekt nyt studiesystem

Behovsanalyse af et nyt studiesystem

2016

Side 2 · Forprojekt nyt studiesystem · Behovsanalyse af et nyt studiesystem

Indholdsfortegnelse

Indholdsfortegnelse ................................................................................................................................................................. 2

Vision .............................................................................................................................................................................................. 4

Proces og metoder .................................................................................................................................................................... 5

Behov .............................................................................................................................................................................................. 9

Fokusområder for det fremtidige arbejde med et nyt studiesystem ................................................................ 13

Funktionelle krav ................................................................................................................................................................... 19

Brugervenligheds krav ......................................................................................................................................................... 20

Tekniske krav ........................................................................................................................................................................... 22

Begrebsmodel .......................................................................................................................................................................... 31

Modulisering af behov .......................................................................................................................................................... 34

Bilag .................................................................................................................................................................................................. 37

Bilag 1: Ordforklaring ........................................................................................................................................................... 37

Bilag 2: Vision........................................................................................................................................................................... 39

Bilag 3: Aktører og behov .................................................................................................................................................... 41

Bilag 4: Integrationer og behov ........................................................................................................................................ 67

Bilag 5: Roller i systemet ..................................................................................................................................................... 81

Bilag 6: Metodebilag .............................................................................................................................................................. 82


Opgave og proces

Den stillede opgave

Erhvervsskolerne har siden midten af 1990’erne anvendt Undervisningsministeriets studieadministra-

tive system EASY-A. Systemet er oprindeligt udviklet som et rent administrativt system, der skulle

sikre, at registrering af elevdata skete på en ensartet og veldokumenteret måde samt sikre et korrekt

grundlag for ministeriets udbetaling af tilskud til skolerne.

Pr. 1. august 2016 er det ikke længere et krav, at erhvervsskolerne benytter EASY-A, idet systemet skal

udfases og skolerne kan anskaffe et system på det frie marked. Pt. er der ingen alternative systemer

der kan dække samtlige uddannelsesområder på erhvervsskolerne.

Danske Erhvervsskoler (DE) og Danske SOSU-skoler har derfor besluttet at nedsætte en projektgruppe

bestående af medlemmer fra de to foreninger til udarbejdelse af en behovsafdækning for den fremti-

dige systemunderstøttelse af såvel de studieadministrative som de studierettede opgaver.

Det er projektgruppens opfattelse, at behovene til et nyt studiesystem bør tage udgangspunkt i et

moduliseret system, som understøtter de studieadministrative og studierettede opgaver med mu-

lighed for integration til andre systemer.

Opgaven, som ønskes løst i forprojektet, er udarbejdelse af en behovsafdækning på et overordnet ni-

veau, men under hensyntagen til- og respekt for det operationelle niveau. Behovsafdækning skal

kunne danne grundlag for udarbejdelse af en egentlig kravspecifikation til brug for en eller flere er-

hvervsskolers udbud af opgaven med at udvikle et nyt studiesystem eller som checkliste ved anskaf-

felse af eksisterende systemer. Behovsafdækning omfatter både en fastholdelse af eksisterende behov

i det nuværende studieadministrative system og en afdækning af nye fremtidige behov til et studiesy-

stem, herunder bl.a. afdækning af behovene for at kunne omfavne Learning Management Systemer

(LMS).

Opgaven omfatter også udarbejdelsen af et økonomisk overslag over de forventede udgifter ved udvik-

lingen af de respektive behovsområder, som grundlag for at der kan udarbejdes et samlet overslag

over udviklingsopgaven.

For yderligere information omkring opgaven henvises til bilag ”Ekstern Oplæg til udarbejdelse af krav-

specifikation_31.07.2015.pdf” som er vedlagt.

Forudsætninger

Projektgruppen har i sit arbejde taget udgangspunkt i, at et/flere studiesystemer som minimum effek-

tivt kan håndtere de processer, som det nuværende EASY-A understøtter.

Behovsafdækningen har taget udgangspunkt i de nuværende lov- og regelsæt på området. Behovsaf-

dækningen har vist, at der er flere områder, hvor der med fordel kunne ske en forenkling,

For nærværende kendes ikke den fremtidige afgrænsning af de nationale systemer, som understøttes

af Undervisningsministeriets Styrelse for It og Læring (STIL), og de markedsgjorte systemer. Der er

derfor områder, hvor projektgruppen har måttet antage den fremtidige systemarkitektur. Antagel-

serne bygger på projektgruppens vurderinger og forventninger til en effektiv opgavefordeling mellem

STIL og markedet. I bilag Bilag 4: Integrationer og behov afsnit UVM/webservice side 68 nævnes de

væsentlige forudsætninger.


Vision

Projektgruppens arbejde tog udgangspunkt i nedenstående vision, som er resultatet af gruppens ar-

bejde på første workshop.

De 2 nedenstående punkter er vurderet af projektgruppen til at være de vigtigste. Hvis man ønsker et

overblik over processen samt alle inputtene til visionerne, så kan man få dette i bilag 2 sidst i denne

rapport.

Disse 2 visioner har været den ”overligger” som har vi har forsøgt at styre efter under processen med

at få behovsafdækket et nyt studiesystem.

1. Beskrive behov til det nødvendige system for en skole, der ikke vil købe 3. parts produkter, og

som er fuldstændigt og dækkende for en mindre skole.

2. Kortlægningen skal holdes på et højt abstraktionsniveau med respekt for de operationelle op-

gaver.


Proces og metoder

I forprojektet har der været fokus på kernen af opgaven; analyse og undersøgelse af alle behov til det

nødvendige studiesystem for en skole, der ikke vil købe 3. parts produkter, og som er fuldstændigt og

dækkende for en mindre skole. Processen har haft et entydigt fokus på at afdække hvilke behov og

ikke hvordan disse behov kunne implementeres. Derfor er der heller ikke blevet produceret f.eks. wi-

reframes eller data model som en del af projektet.

Projektet er udført i et tæt samarbejde med Danske Erhvervsskoler og Danske SOSU-skolers projekt-

gruppe, suppleret af relevante brugere, primært studieadministrative medarbejder, med et dybt kend-

skab til behovene på det operationelle plan.

Forprojektet har været opdelt i 6 gentagelser (iterationer). Hver iteration har været delt i en forståelse

fase (forberedelse til workshop, videns indsamling), analyse fase(workshop) og en konkretisering fase

(efterfølgende opsamling på workshop). Konkretisering har været foretaget af ditmer a/s, og har re-

sulteret i en version af rapporter og behovsmatrix som har kunnet blive vurderet og kvalificeret af

projektgruppen inden næste workshop.

Ud over en grundlæggende opbygning af forståelse og viden, gennem analyse og undersøgelse i pro-

jektgruppen og dennes medlemmer har det været helt essentielt for projektet, at sikre et bredt videns

fundament ved at inddrage relevante fagpersoner løbende i projektet. Denne inddragelse er sket lø-

bende i projektet og specielt i iteration 2, 3 og 5.

Processen har introduceret en række nye metoder for projektgruppen løbende, f.eks. user stories,

disse metoder vil blive forklaret yderligt senere i dette afsnit. Introduktionen har været en lærende og

krævende proces for projektgruppens medlemmer, men den store involveringen fra projektgruppens

medlemmer har medført at, slutproduktet af projektet har opnået den høje kvalitet det har.

Afholdte aktiviteter

Vision opstart workshop - 7. september

Visioner for det nye system samt opstart af identificeringen af relevante opgaver.

Videns indsamling - 17. september

Introduktion til studieadministrationen ved besøg på Rybners i Esbjerg.

Iteration 1 - 1. og 2. oktober

Workshop 1 og 2, fokus på områderne indslusning, optagelse og studieadministration.

Iteration 2 - 19. og 20. oktober

Workshop 3 og 4, fokus på studieadministrationen.

Iteration 3 - 10. og 11. november

Workshop 5 og 6, fokus på områderne studieadministration, praktikadministration og eksamen.

Iteration 4 - 30. november og 1. december

Workshop 7 og 8, fokus på områderne Økonomi og HR, Bygningsdrift og services, gennemførelsesvej-

ledning / støtte og kommunikation.

Iteration 5 - 11. og 12. januar

Workshop 9 og 10, fokus på læring og opsamling.

Iteration 6 - 1. og 2. marts

Workshop 11 og 12 gennemgang og tilpasnings af behovsafdækning og behovsmatrix


Denne rapport sammenfatter de identificerede behov og iagttagelser fra projektgruppen på de overfor

nævnte workshops.

Afklaringsproces – proces for analyse og undersøgelse af behov

Overordnede afklaringsprocesfaser i projektet

De overordnede faser i projektet, har været som vist Error! Reference source not found..

Figur 1– Overordnede faser i projektet

Opstartsmøde og første workshop

Opstartsmødet havde et fokus på at opnå en forventningsafstemning i forhold til den videre afklarings-

proces i projektet og det ønskede resultat.

Første workshop

Den første workshop skulle sikre et solidt fundament at bygge på i forhold til de efterfølgende 5 afkla-

ringsseminarer. Den første workshop behandlede primært disse 2 emner:

— vision

— overordnet gennemgang af processer.

Arbejdet med visionen for et nyt studiesystem tog afsæt i en forståelse af, hvad en god vision er:

— En god vision hjælper med til at prioritere konkrete indsatser

— En god vision giver et pejlemærke, som ‘fremskridt’ kan holdes op imod

— En god vision afspejler de bagvedliggende værdier

Resultatet kan ses i Bilag 2: Vision side 39.

Opstartsmødeog førsteworkshop

6 iterationer (forstå, analyse og

konkretisering) Overlevering


På den første workshop blev metoder som silent brainstorm og dot voting / multi-afstemning bragt i

spil for at afdække visionerne for et fremtidligt studiesystem.

Iterationer – workshops

Som tidligere nævnt har projektet været opdelt i 6 iterationer. Hver iteration har været delt i en forstå-

else fase (forberedelse til workshop, videns indsamling), analyse fase(workshop) og en konkretisering

fase (efterfølgende opsamling på workshop) som det er vist på Figur 2 - overblik over processen for

behovsafdækningen.

Figur 2 - overblik over processen for behovsafdækningen

Forstå-fasen

Denne fase har primært indeholdt aktiviteter omkring forberedelse af workshops(analysefasen), til-

pasning af processen og indsamling af viden om f.eks. eksisterende systemer og arbejdsgange.

Analysefasen – workshopdage

Hver analysefase bestod af to sammenhængende workshop dage. Workshopdagene var en faciliteret

proces af ditmer, hvor man i fællesskab analyserede og undersøgte hvilke behov der knyttede sig til de

udvalgte processer for den specifikke iteration. På workshopdagene skabte ditmer og projektgruppen i

fællesskab et rum hvor vi i fællesskab identificerede, kvalificerede og udfordrede den viden, der blev

bragt i spil for at kunne skabe grundlaget for udviklingen af et nyt studiesystem som afløser for EASY-

A. Et vigtigt input til dette arbejde var blandt andet de visioner der blev skabt på den første workshop.

Udvalgte processer

Det var hensigten, at behovsafdækningen skulle tage udgangspunkt i en række processer, som projekt-

gruppen sammen med STIL i foråret 2015 identificerede, jf. bilag ”Ekstern_Bilag 1_Procesbeskri-

velse_Maj 2015.pdf” som er vedlagt. I løbet af forprojektet er antallet af processer blevet udvidet, da det

har vist sig, at de oprindelige identificerede processer ikke var fyldestgørende, bl.a. manglede flere stu-

dierettede processer.

Hver iteration af afdækningen har behandlet en række udvalgte processen, hvilke kan ses på oversig-

ten over afholdte aktiviteter tidligere i dette afsnit.

For hvert procesområde er behovene identificeret således, at et bredt udvalg af de uddannelser, der

udbydes, er dækket, herunder følgende uddannelser: EUD - GF1, EUD - GF2, EUD – hovedforløb, EUD –


EUX, EUD – EUV, Brobygning, Skolepraktik, Skolehjem, HTX (gymnasium), HHX (gymnasium), STX

(gymnasium), AMU (kursus), IDV (kursus) og Åben uddannelse (kursus).

Behandling af en enkelt proces, f.eks. optagelse

Behovsafdækning for et udvalgt område/proces, har anvendt en metode med inspiration fra bogen

User Story Mapping1, som hedder Think, Write, Explain & Place.

Figur 3 - overblik over processen for behovsafdækning af et enkelt område / proces

Metoden har et udgangspunkt i en dialogbaseret proces, som skitseret på figuren herover. Hvert behov

som igennem dialogen er blevet identificeret er blevet defineret som en user story. Metoden user story

blev valgt, for at skabe et format som er ensartet og muligt at kommunikere præcist omkring.

Konkretiseringsfase

Konkretiseringsfasen blev fortaget primært af ditmer hvor der blev skabt en række ”artefakter”2 som

kunne deles, vurderes og bedømmes af projektgruppen og de involverede interessenter.

1 User Story Mapping, Jeff Patton ISBN:978-1-4919-0490-9 2 Eksempelvis opsamling på brainstorms, user stories mm. F.eks. Behovsmatrix og rapport.


Behov

Alle funktionelle behov er defineret i vedlagte behovsmatrix (Studiesystem_behov.xlsx). Dette afsnit

opsummerer indholdet af behovsmatrixen, fordelt på afsnit og set i forhold til antal af behov, kategori

og hvilke type behov, det enkelte afsnit indeholder.

De definerede funktionelle behov, i behovsmatrixen og som er opsummeret i afsnittet her er essensen

af det fælles arbejde, projektgruppen har udført i dette projekt. Behovsmatrixen indeholder i alt 419

behov og alle behov er beskrevet som user stories. Selve afdækningen er holdt på et højt abstraktions-

niveau, derfor vil behovsanalysens user stories typisk være på et abstraktionsmæssigt højere niveau

end man typisk ser i f.eks. i et udbudsmateriale. Man kan læse mere om user stories i Error! Refer-

ence source not found.Bilag 6 sidst i dette dokument.

Studieadministration (46 behov)

Afsnittet studieadministration indeholder i alt 46 behov fordelt på følgende underkategorier:

Aktivitetsindberetning (7)

Fremmødekontrol og opfølgning (8)

Evaluering (8)

Indberetninger - f.eks. til Danmarks Statistik (1)

AUB (3)

SU (2),

Transport (4)

Ansøgning (1)

Elev (8)

Time opfølgning (1)

Elevdeling (1)

Kommunikation (1)

Elevindberetning (1)

Afsnittet studieadministration dækker over nogle af de mest centrale behov i forhold til de studiead-

ministrative opgaver, herunder f.eks. aktivitetsindberetning og fremmødekontrol. Dette afsnit er ikke

udtømmende for de identificerede behov til de centrale studieadministrative opgaver, da der for at

skabe et fokus og overblik er oprettet følgende afsnit til specifikke centrale studieadministrative opga-

ver/områder:

Udbudsgodkendelse

Grovplanlægning

Tilmelding

Optagelse

Elevtilknytninger

Skemalægning


Eksamen, prøver og eksamensbevis

Disse afsnit bliver gennemgået i det efterfølgende.

Udbudsgodkendelse (5 behov)

Afsnittet udbudsgodkendelse indeholder i alt 5 behov. Behovene i afsnittet vedrører godkendelse fra

UVM af en specifik skole til at udbyde en specifik uddannelse, AMU kursus eller enkelt fag i et givet

tidsrum.

Grovplanlægning (4 behov)

Afsnittet grovplanlægning indeholder i alt 4 behov. Grovplanlægning er skolens mulighed for at kunne

planlægge/budgettere elevforløb og stamhold i f.eks. et grafisk overblik med henblik på belægning. Et

elevforløb består bl.a. af skoleperioder og praktikperioder med datoer.

Tilmelding (18 behov)

Afsnittet tilmelding indeholder i alt 18 behov. Behovene ift. tilmelding vedrører elevernes tilmelding

til f.eks. en uddannelse gennem optagelse.dk. Eleverne modtages i en række indbakker til videre be-

handling i forbindelse med optagelse.

Optagelse (39 behov)

Afsnittet optagelse indeholder i alt 39 behov fordelt på følgende underkategorier:

Afklar optagelse (12)

Indkaldelse (6)

KUU (2)

Opstart (2)

Registrér optagelse (6)

Tilgang og afgang af elever (8)

RKV (3)

Behovene i dette afsnit omhandler selvfølgelig registrér optagelse men også behovene omkring at af-

klare optagelsen, udføre RKV, placere elever fra indbakke på et elevforløb, modtage og oprette kursi-

ster fra virksomheder, indkaldelse og opstart med tilhørende udstedelse af studiekort.

Elevtilknytninger (6 behov)

Dette afsnits 6 behov omhandler elevtilknytninger i forbindelse med at registrere optagelse, som f.eks.

at placere elever i stamhold. Alle behovene er behov, som også eksisterer som løbende aktiviteter.

Skemalægning (36 behov)

Afsnittet skemalægning indeholder i alt 36 behov fordelt på følgende underkategorier:

Skemaplanlægning (19)

Personale (1)

Time-fagfordeling (16)

Afsnittet indeholder behov vedrørende skemaplanlægning med tilhørende behov for, hvad et skema-

planlægningsmodul skal indeholde af forskellige regler. F.eks. at kunne tage højde for de maksimale


undervisningstimer pr. underviser pr. uge. Afsnittets behov vedrører også ressourcehåndteringsbehov

i forbindelse med time-/fagfordeling på en erhvervsskole.

Eksamen, prøver og eksamensbevis (42 behov)

Afsnittet eksamen-prøver og eksamensbevis indeholder i alt 42 behov fordelt på følgende underkate-

gorier:

Censorkorps (3)

Eksamen/Prøver (33)

Eksamensbevis (6)

Behovene i dette afsnit vedrører specifikt de behov, som skal omsættes til behov for at kunne plan-

lægge og afholde eksaminer og prøver, indkalde til censorkorps samt opsætte, producere og distribu-

ere eksamens- og prøvebeviser.

Gennemførelsesvejledningsstøtte (6 behov)

Afsnittet gennemførelsesvejledningsstøtte indeholder i alt 6 behov fordelt på følgende underkatego-

rier:

Statistik (1)

Samtaler/aktiviteter (1)

SPS (4)

Dette afsnit indeholder de studieadministrative behov for at kunne varetage SPS, samtaler og udføre

statistik herunder at kunne sende informationer til ungedatabasen.

Tværgående (39 behov)

Afsnittet tværgående indeholder i alt 38 behov fordelt på følgende underkategorier:

Institutioner (2)

Uddannelsesmodel (18)

Udbud (1)

Kommunikation (3)

Personale (1)

Skemaplanlægning (1)

Lokal uddannelsesplan (1)

Studieadministration (1)

Opkrævning (3)

Eksamen (1)

Aftaler (1)

Arkiv (2)

Censor (2)

Overblik (1)

Revision (1)


Censor (2)

Behovene i afsnittet tværgående er primært behov, som ikke passer ind i en tidsmæssig kronologisk

rækkefølge af studieadministrative opgaver, men som tværtimod kan ske på løst koblede tidspunkter.

Læring (48 behov)

Afsnittet læring indeholder i alt 48 behov fordelt på følgende underkategorier:

Valgfag (8)

Materiale (3)

Læringsforløb (13)

Elev (8)

Generelt (10)

Valg af fag (6)

Læringsafsnittet er en udfoldning af de behov, som knytter sig til de mere læringsrettede opgaver og

områder i et nyt studiesystem til erhvervsskolerne. Behovene er behov, som et LMS typisk løser for en

erhvervsskole.

Skolehjem (23 behov)

Afsnittet skolehjem indeholder i alt 23 behov fordelt på følgende underkategorier:

Skolehjem (21)

Fælles (2)

Dette afsnit dækker de behov, der knytter sig til at have et skolehjem tilknyttet en erhvervsskole.

HR (20 behov)

Afsnittet HR indeholder i alt 20 behov fordelt på følgende underkategorier:

Personale (15)

Tidsregistrering (4)

Medarbejder (1)

Behovene i dette afsnit vedrører personaleadministration med tilhørende ansættelsesforhold og her-

under bl.a. undervisningskompetencer og andre kompetencer. Behovene dækker også muligheder for

at kunne skabe overblik over planlagt fravær for medarbejdere og mulighed for, at medarbejdere kan

tidsregistrere arbejdstid.

Praktikadministration (15 behov)

Dette afsnit indeholder 15 behov vedrørende praktikadministrationen. Behovene er de studieadmini-

strative nære behov, som ikke antages fortsat at skulle løftes af EASY-P i forbindelse med et nyt studie-

system. Projektet har ikke beskæftiget sig specifikt med behovene/funktioner i EASY-P, men antaget,

at den også vil være til stede, når et nyt system skal udvikles/købes.

IT (1 behov)

Behovet i denne kategori omhandler at man skal kunne oprette og vedligeholde udleveret it inventar

så som pc, nøglebrik m.m.


Økonomi (10 behov)

Afsnittet økonomi indeholder i alt 10 behov fordelt på følgende underkategorier:

Forecast (3)

Lønfordeling (6)

Indberetning (1)

Behovene i dette afsnit vedrører de økonomi-administrative behov f.eks. at kunne forecaste på samt-

lige indberetninger og varetage kønsfordeling.

Bygningsdrift og service (15 behov)

Dette afsnit indeholder 15 behov, som vedrører bygning, lokaler og service elementer som f.eks. admi-

nistration af udleverede nøgler.

Rapport, statistik og udtræk (21 behov)

Afsnittet rapport, statistik og udtræk indeholder i alt 21 behov fordelt på følgende underkategorier:

Statistik muligheder (8)

Standardrapport (13)

Behovene i afsnittet vedrører primært opsætning af forskellige rapportskabeloner inden for de oven-

fornævnte kategorier f.eks. udtræksskabeloner til statistik. Afsnittet indeholder også behov som om-

handler specifikke rapporter.

Indberetninger (27 behov)

Afsnittet indberetninger indeholder en oversigt over eksisterende indberetninger (27 i alt) fra EASY-A.

Det må antages, at et fremtidigt studiesystem som minimum skal kunne understøtte samme antal ind-

beretninger.

Fokusområder for det fremtidige arbejde med et nyt studiesystem

Sammenhængende arbejdsgange

Oplægget til forprojektet og visionen for arbejdet i forprojektet, har defineret, at der skulle arbejdes

med en behovsafdækning på et overordnet niveau, samtidigt med en respekt for de operationelle op-

gaver. Denne ramme om arbejdet har betydet, at der ikke eksplicit er blevet arbejdet med at skabe en

beskrivelse af sammenhængende arbejdsgange. Fokus har i højere grad været at skabe en fyldestgø-

rende behovsafdækning (behovsmatrix) for, hvad et studiesystem skal indeholde for en erhvervsskole

af en vilkårlig størrelse. Helt grundlæggende for afdækningen af behov har været udgangspunktet og

præmissen, at et fremtidigt studiesystem skal have sammenhængende og meningsfyldte arbejdsgange

for alle de forskellige brugerroller i studiesystemet og i høj grad for de studieadministrative medarbej-

dere. Det er derfor essentielt, at en fremtidig udviklings- eller købsproces har et højt fokus på at sam-

mensætte behovene til sammenhængende og meningsfyldte arbejdsgange for de forskellige brugerrol-

ler, der er repræsenteret i systemet.


I arbejdet med at konstruere sammenhængende arbejdsgange til studieadministrationen kan der tages

udgangspunkt i følgende overbliksskabende figurer, som også har været anvendt i forprojektets be-

hovsafdækning. Figur 4 viser den kronologiske tidslinje for studieadministrationen og Figur 5 viser,

hvilke løbende aktiviteter studieadministrationen har. Dette er selvfølgelig kun et udpluk af de katego-

rier af behov, som der skal skabes sammenhængende arbejdsgange for men kategorierne nævnt på

Figur 4 - Kronologisk tidslinje for studieadministration og Figur 5 – løbende aktiviteter for stu-

dieadministrationen er nogle af de helt centrale for at lykkes med et mere sammenhængende og ef-

fektivt studiesystem.

Figur 4 - Kronologisk tidslinje for studieadministration


Figur 5 – løbende aktiviteter for studieadministrationen

Der er i forprojektet blevet defineret en række generelle krav, som har indflydelse på arbejdet med

sammenhængende arbejdsgange i et fremtidigt studie system. Se eventuelt afsnittet Funktionelle krav

side 19 og Brugervenligheds krav side 20 for disse krav.

Overbliksskabende visninger

Det er et stort fokuspunkt for projektgruppen, at et fremtidig studiesystem i langt højere grad end man

oplever det i dag, skal have en brugergrænsefalde med en lang række grafiske overbliksskabende vis-

ninger og arbejdsgange. Specielt arbejdsgangene for det studieadministrative personale har dette be-

hov.

Disse visninger i brugergrænsefladen er en nødvendighed, både i forhold til fremsøgning at informati-

oner men også i forbindelse med konkrete arbejdsopgaver, f.eks. skemaplanlægning eller overblik for

opfyldelse af målepinde for elever.

Det er helt essentielt, at man i arbejdet med det fremtidige studiesystem forholder sig til i hvilke områ-

der og arbejdsgange, det vil give en øget værdi og bidrage til opfyldelsen af visionen for studiesyste-

met, at arbejde specifikt med grafiske overbliksskabende visninger samt hvilke enheder (smartphone,

tablet, mfl.), disse områder og arbejdsgange vil skulle vises på.


Et godt eksempel vil f.eks. være i forbindelse med arbejdsgangene omkring skemaplanlægningen, hvor

det er altafgørende, at de rigtige informationer vises på en overskuelig måde for planlæggeren, og gi-

ver lige netop det overblik, som muliggør at man kan få skemaplanlægningen til at gå op.

Skemaplanlægningen er også et godt eksempel på et område, hvor der med fordel kan arbejdes med

interaktionsmuligheder i brugerinterfacet, f.eks. drag’n’drop af skemabrikker således at arbejdsgangen

bliver mere intuitiv for den studieadministrative medarbejder.

Endnu et eksempel kunne være fraværsregistrering, hvor der er et behov for en række samlende over-

bliksvisninger, f.eks. fravær for alle elever på et hold. Samtidigt er der behov for et meget specifikt ar-

bejdsbillede for undervisere, i forbindelse med fraværsregistrering af de enkelte elever. Et arbejdsbil-

lede, som skal være skåret helt skarpt i forhold til denne ene, specifikke opgave og som skal kunne fo-

regå f.eks. på en tablet eller smartphone.

Forprojektets behovsafdækning har identificeret forskellige behov, hvor det er nødvendigt med et

særligt fokus på at skabe grafiske overbliksskabende visninger og arbejdsgange. Arbejdet med et frem-

tidigt studiesystem bør have et stort fokus på at arbejde med disse behov eksplicit i forhold til bruger-

grænsefladen.

Projektgruppen har identificeret følgende behov, som skal have et særligt fokus:

Nr. Behov Behovsuddybning

E8

Som skole kan jeg danne mig et overblik over resultatet af eksa-mensplanlægningen og ændre i dette.

Dette skal understøttes med noget smart grafisk interface (overskueligt). Der skal kunne komme forslag, og man skal kunne se konsekvenser. Vær synligt, når der er opmærk-somhedspunkter.

E21 Som skole kan jeg benytte en eksa-mensplanlægningsmotor, som for-tæller hvilke dage, der skal være prøver i hvilke fag. Eksamensplan-lægningsmotoren giver mig en gra-fisk nem og overskuelig visning.

Input til motoren er: - Censorer og deres kalender - Lokaler - Undervisere (friholdelsesperioder og kompetencer) - Elever (eksamensfag) Der er regler for, hvornår dette må offentliggøres for for-skellige brugergrupper. Lokalet skal være booket til eksamen med en skemabrik, der hedder eksamen.

Tage højde for: - Ekstra forberedelsestid - SPS

- Lærerfritagelse

- Lokalefordeling

- Evt. censor muligheder(EUD) - Nogle eksamner allerede har en dato

G2 Som skole skal man kunne få et grafisk overblik i en kalender vis-ning over belægningen af de en-kelte uddannelser (udbud).

Man skal kunne indsætte elevforløb direkte i kalenderen samt trække dem rundt, såkaldt "drag and drop".


O14 Som skole skal man fra indbakken kunne placere elever på et elevfor-løb og dermed på et eller flere sko-leforløb.

Elevforløbet bliver oprettet som en del af grovplanlægnin-gen/udbudsplanlægningen med tilhørende skoleforløb og/eller praktikforløb. Disse forløb bliver datosat og opret-tet med udgangspunkt i en uddannelsesmodel. Arbejdsgangen "registrerer optagelse" skal kunne fungere på en overskuelig grafisk måde og med mulighed for flere elever på en gang. Se L13

S17 Som skole skal man kunne se en grafisk oversigt over, hvor langt eleven er i forhold til målepinde, og hvilke der har fået karakter.

I arbejdet med at skabe overbliksskabende visninger og arbejdsgange kan følgende grundprincipper

inddrages

Selvforklarende

Systemet skal i vidt omfang være selvforklarende. Dette kan eksempelvis betyde, at farvebrug (rød =

fravær fra aktivitet, grøn = ingen fravær) er forklaret, der hvor de anvendes. Skærmbilleder eller kom-

plekse funktioner, som ikke umiddelbart intuitivt lader sig forklare, understøttes af info-ikoner, eller

”pop-up” tekster, når musen holdes over elementet.

Felter skal suppleres af forklarende tekst om, hvad indholdet bruges til, og knapper skal på tilsvarende

vis have supplerende tekst, som forklarer konsekvensen af et tryk.

Beskyttelse mod utilsigtede handlinger

Brugeren skal/kan beskyttes mod utilsigtede handlinger og fejl ved bl.a. at anvende en af følgende me-

toder

Validering på feltniveau Alle felter skal give sigende og øjeblikkelige tilbagemeldinger ved indtastning af forkerte vær-dier. Brugeren skal have tilbagemeldingerne præsenteret med det samme som en venlig på-mindelse om en mangelfuld indtastning i umiddelbar nærhed af indtastningen, og ikke først som en samlet tilbagemelding, når handlingen forsøges udført ved et tryk på en knap.

Validering mod forretningsregler Systemet skal hjælpe brugeren med ikke at kunne foretage handlinger, som strider mod forret-ningsregler.

Mulighed for at omgøre beslutning om at slette og ”soft delete” Alle steder, hvor brugeren kan ”slette” elementer, sker dette umiddelbart, men brugeren kan straks og – som udgangspunkt - til enhver tid fortryde valget om at ”slette”. Sletninger er skre-vet i citationstegn, da systemet skal understøtte, at data ikke slettes i systemet, men markeres som slettet, og dermed vil det altid i yderste konsekvens være muligt at fremfinde data igen.

Layout og design

Principper

Systemets layout og design bør understøtte den gode brugeroplevelse. Skærmbillederne bør på den

ene side være overskuelige og sætte brugeren i stand til hurtigt at danne sig et overblik, mens de sam-

tidigt skal stille al nødvendig information til rådighed for brugeren, da der ofte er behov for at vise


mange data på samme skærmbillede. Det vil være en kontekstnær afvejning hvilke af disse hensyn, der

vejer tungest. Det er centralt at vide præcis hvilke behov, brugeren har på det tidspunkt i en arbejds-

gang, hvor et givet skærmbillede anvendes, for at vide om det er vigtigere eksempelvis at have mange

informationer til rådighed, eller om få informationer skal bringe brugeren hurtigt videre.

Disse behov skal blandt andet løses ved at benytte et konsistent designsprog, overholde konventioner

for brugerflader og ved at bygge layoutet efter gestaltlovene om menneskelig perception, så korrekt

brug af nærhed, lukkethed, lighed og linjer understøtter brugerens forståelse af skærmbillederne.

Et gennemgående aspekt er ligeledes udnyttelse af fri plads i skærmbilledet (”white space”) til at ad-

skille og indramme elementer i brugerfladen, så brugerens forståelse understøttes.

Navigation

Systemet bør benytte sig af en altid persistent og søgbar navigation i flere niveauer, som gennem kon-

sistente placeringer i alle skærmbilleder gør brugeren i stand til både at navigere og orientere sig.

Implicit informeret

Grundlæggende relevant information for udførelsen af og overblik over opgaver i systemet bør ikke

skulle opsøges særskilt i systemet, men i stedet være til stede, så brugeren pr. automatik har informa-

tionen til rådighed.

Proces ift. overbliksskabende visninger

Uanset hvilke forhåndsbetragtninger og udviklingsmæssige greb en udvikler eller et team gør sig, så

ligger afgørelsen af, om indsatsen er lykkedes – det vil sige – om systemet opfattes som imødekom-

mende og brugervenligt, hos brugerne.

Skal de overbliksskabende elementer eksempelvis virke efter hensigten, kræver det forventeligt en del

iterationer mellem udvikler og bruger. Det vil være ønskeligt, jvf. de udtrykte ønsker til processen, at

brugeren får mulighed for at prøve eksempelvis skemaplanlægningen af i praksis, hvor opsamlede er-

faringer og behov kan integreres ind i den fungerende prototype måske endog samme dag, som de op-

står.


Funktionelle krav

Et nyt studiesystem skal kunne tilbyde at løse de behov som sektoren har i dag, men på en sådan måde

at det understøtter det konstante behov for effektiviseringer. De funktionelle behov beskriver de mere

overordnede behov der skal adresseres for at kunne gøre dette.

Funktionelt krav 1 Selvbetjeningsmuligheder

Systemet skal gøre det muligt for elever og personalet på skolerne selv at foretage registreringer så

som fx fravær.

Funktionelt krav 2 Påmindelser

Systemet skal kunne sende påmindelser ud til brugerne.

Påmindelser kan eksempelvis være i forbindelse med at en deadline for en opgave nærmer sig.

Funktionelt krav 3 Automatisering

Automatisering af fx skemaplanlægning, valgfag, eksamensplanlægning og rapporter.

Funktionelt krav 4 Ens brugergrænseflade og funktionalitet inden for hver af de de-

finerede brugerindgange/brugergrupper

Systemet skal have ens brugergrænseflade og overordnet ens funktionalitet inden for de definerede

brugerindgange.

Funktionelt krav 5 Mobile enheder

Systemet skal kunne anvendes af brugere gennem mobile enheder.

Funktionelt krav 6 Understøttelse af flere sprog

Alle tekster skal kunne vælges til at være på flere sprog og som minimum på dansk og engelsk.

Funktionelt krav 7 Funktionel tilgængelighed

Systemet, skal opfylde WCAG 2.0 tilgængelighedskravene på niveau AA. Systemet skal som minimum

tjekkes med de værktøjer, som tilbydes af Digitaliseringsstyrelsen.

Alternativt skal Leverandøren dokumentere, at Systemet overholder tilgængelighedskravene med

værktøjer, der mindst svarer til samme niveau.

Funktionelt krav 8 Nem skifte mellem skole konti

Systemet skal understøtte at en bruger let kan skifte mellem flere forskellige skoler vedkommende er

tilknyttet. Dette skal man også kunne gøre mellem systemer hvis de samlede erhvervsskoler ender

med flere forskellige studiesystemer.

Funktionelt krav 9 Webbaseret system

Systemet skal være et webbaseret system, og dermed platformsuafhængigt, så de enkelte skoler kan

tilgå Systemet gennem en browser.


Brugervenligheds krav

Det er et overordnet krav og ønske om, at brugergrænsefladen skal være brugervenlig, for alle bru-

gere. Med dette menes bl.a. følgende:

• Korte svartider

• Relevans

• Hjælp til handlinger

• Genkendelighed i ”look & feel”

• Intuitiv og selvhjulpen

• Overskuelighed

• Relevant og tilgængelig information forærende

• Drag’n’drop

• Direkte upload til arkiv3

• Flere sprog

Brugervenlighedskrav 1 Visning af, for brugertypen, relevante data

Systemet skal generelt kun vise de for brugertypen relevante data, så brugerfladen er overskuelig og

ikke byder på flere data end det er nødvendigt.

Brugervenlighedskrav 2 Generelle principper for betjening

Systemet skal kunne håndtere specialtegn, herunder ÆØÅ og præsentere det fejlfrit på alle platforme.

Brugervenlighedskrav 3 Fejlmeddelelser

Fejlmeddelelser (inkl. betjeningsfejl og systemgenerede meddelelser) skal være kontekstrelevante,

handlingsanvisende samt forståelige og anvendelige for brugerne.

Brugervenlighedskrav 4 Moderne teksteditor-funktionalitet

Ved skrivning af tekst skal brugergrænsefladen give adgang til moderne teksteditor-funktionalitet.

Brugervenlighedskrav 5 Museklik

Anvendelse af museklik minimeres.

Brugervenlighedskrav 6 Mouse-over

Systemet skal tilbyde ”mouse-over” med hjælpetekster, f.eks. når der er specifikke krav til udfyldelsen

af et felt. Mouse-over-funktionen skal være en generel funktionalitet i systemet. I mouse-over-teksten

skal der, hvor det er relevant, være mulighed for at medarbejdere kan klikke på et direkte link og her-

fra komme videre til yderligere information eller anden funktionalitet i Systemet.

3 Dette betyder, at filer kan gemmes direkte i systemet uden først at skulle gemmes lokalt.


Brugervenlighedskrav 7 Ensartet og konsistent design

Brugergrænsefladen skal være designet ensartet og logisk, være enkel at manøvrere rundt i samt have

samme konsistens, uanset hvilke sider brugeren tilgår. F.eks. at

a) siderne har samme farve/font

b) en funktion med bestemt navn har samme navn og funktion hele vejen igennem syste-

met

c) datoer har et bestemt format

d) skærmbilleder skal kunne skaleres op/ned

e) kolonner skal kunne udvides/indskrænkes

f) kolonner skal kunne sorteres ved klik på overskriften

Brugervenlighedskrav 8 Udgangspunkt i Kundens design

Alle brugergrænseflader skal tage udgangspunkt i Kundens designmanualer, herunder eventuelle sty-

lesheets (CSS) og HTML-skabeloner.

Brugervenlighedskrav 9 Udgangspunkt i aktuel bedste praksis for selvbetjening

Brugergrænseflader relateret til selvbetjening skal tage udgangspunkt i aktuelle bedste praksis for

selvbetjening, fx digitaliser.dk’s udviklingsvejledning for selvbetjening.

Brugervenlighedskrav 10 Autoudfyldelse fra tidligere indtastninger

Der skal være mulighed for intelligente celler (autofuldførelse), hvor tidligere indtastninger fra medar-

bejderen automatisk foreslås. Systemet skal understøtte typeahead, hvor relevant.

Brugervenlighedskrav 11 Synlige tilbagemeldinger

Systemet skal give medarbejdere synlige og forståelige tilbagemeldinger om, hvad Systemet foretager

sig f.eks. kopiering, overførsel af data. Generelt ved processorforbrug over 5 sekunder skal der altid

være en synlig procesbjælke, der fortæller, hvor langt systemet er i behandlingsprocessen, samt hvor

lang tid der forventes, før processen er færdig. Det skal ydermere være muligt at afbryde processen

midt i det hele.

Brugervenlighedskrav 12 Brugerne skal kunne se forskel på miljøer (produk-

tion, test, undervisning)

Der skal være tydelig forskel på: Produktion-, Test- og Undervisningsmiljø af Systemet.

Brugervenlighedskrav 13 Overskuelighed

Skærmbilleder skal være overskuelige for slutbrugeren. Det skal være muligt at have flere skærmbille-

der åben på samme tid. Systemet skal understøtte flere skærme.

Brugervenlighedskrav 14 Drag’n’drop

Systemet skal kunne understøtte drag’n’drop interaktion på udvalgte arbejdsgange hvor dette vil give

øget brugervenlighed. (f.eks. skemaplanlægning).


Tekniske krav

Generelle arkitekturkrav

I det følgende stilles der et antal tekniske principper og krav. Nedenfor gennemgås disse principper,

hvorefter hvert af disse konkretiseres i form af et antal ikke-funktionelle krav.

Arkitektur krav 1 Løsningen bygges af løst koblede systemkomponenter

Systemet skal bygges af løst koblede systemkomponenter, der i granularitet svarer til en forretnings-

proces. Brugergrænseflade, forretningslogik og infrastruktur adskilles altid.

Arkitektur krav 2 Løsningen er fleksibel

Systemet skal være fleksibel, således at den kan interagere og samarbejde med andre systemer.

Arkitektur krav 3 Anvendelse af redundante data følger vedtagne regler

Redundans er kun tilladt, hvor det giver værdi, og skal i givet fald følge fælles vedtagne principper og

regler.

Arkitektur krav 4 Integration følger vedtagne principper

Når der integreres mellem forskellige løsninger følges fælles vedtagne principper for serviceorienteret

arkitektur (SOA) og reglerne herfor. Funktionalitet bør udstilles som services. Dette inkluderer også

hændelsesadviseringer. Services skal være indkapslet, således at et anvendersystem af en service ikke

skal være bekendt med, hvordan servicen er implementeret, for at anvende den.

Arkitektur krav 5 Hændelsesadvisering

Systemet skal tilbyde mekanismer, hvormed forretningshændelser kan publiceres til andre systemer.

Arkitektur krav 6 Anvend fællesoffentlige standarder

Findes fællesoffentlige standarder på et givet område, skal denne eller disse søges anvendt. I det om-

fang yderligere standarder er relevante, skal de ligeledes søges anvendt.

Arkitektur krav 7 Anvend modne teknologier

Der skal i videst mulig omfang anvendes modne teknologier. Det vil sige, at afprøvede systemkompo-

nenter foretrækkes frem for nyere.

Systemet skal baseres på teknologier, hvor Leverandøren kan redegør for en minimum levetid på 10 år

for de valgte teknologier.

Arkitektur krav 8 Løsningens fleksibilitet

Systemet er fleksibelt opbygget, og vil kunne modificeres med hensyn til design og funktionalitet i takt

med, at efterspørgsel og behov ændres i Systemets livscyklus.

Arkitektur krav 9 Robusthed

Opbygning af Systemet skal sikre en høj robusthed mod tab af data og nedbrud i øvrigt.

Arkitektur krav 10 Løsningens skalerbarhed

Leverandøren skal planlægge og udvikle Systemet således, at Systemet i den efterfølgende drift kan

skaleres, såvel horisontalt som vertikalt til at håndtere et stigende antal Brugere og datamængder

samtidig med, at de aftalte servicemål for driften til enhver tid kan efterkommes.


Arkitektur krav 11 Lagdelt arkitektur med veldefinerede snitflader

Systemet skal være opbygget modulært og i en lagdelt arkitektur med veldefinerede snitflader og løs

kobling mellem lagene, således at det skal være muligt, fx at udskifte brugergrænsefladelaget eller at

udskifte udvalgte forretningskomponenter.

Integrationer

I det følgende stilles der et antal tekniske principper og krav vedr. integrationer.

Integrationer krav 1 Systemet skal understøtte single-signon

Som minimum skal WAYF/ADFS understøttes, men også gerne andre teknologier.

Integrationer krav 2 Kontrakt først

Web Service grænsefladerne konstrueres ud fra ”Kontrakt først” princippet, dvs. at WSDL og XML

Schema filer udarbejdes, inden services implementeres hos MDB og aktører. WSDL og XML Schemaer

udgør i denne sammenhæng ”kontrakten”.

Integrationer krav 3 Servicegrænsefladen

Servicegrænsefladen skal understøtte de udbredte WS* standarder som:

• REST

• WDSL 1.0 & WSDL 2.0

• SOAP

• WS-I Basic Profile

• WS-I Basic Security Profile

• WS-Security

• WS-Signature

• XML Encryption

• WS-Addressing

• WS-Eventing.

eller tilsvarende standarder.

Integrationer krav 4 Overvågning af snitflader

Leverandøren skal tilbyde at overvåge snitflader.


Tekniske krav til brugergrænsefladen

I det følgende stilles der et antal tekniske krav vedr. brugergrænsefladen.

Brugergrænsef. krav 1 Browservalg

Systemet skærmbilleder skal kunne anvendes af: Internet Explorer/Edge, Mozilla Firefox, Safari og

Google Chrome. Systemet skal fremadrettet understøtte gængse browsere i nyeste version og to versi-

oner tilbage.

Brugergrænsef. krav 2 Skærmopløsning

Systemet skærmbilleder skal optimeres til skærmopløsning 1920x1080 og 1366x768 samt 16/32 bit

farver, og være skalerbare til større skærmopløsninger.

Endvidere skal Systemet kunne vises på tablets og smartphones, så Systemet design tilretter sig skær-

mens opløsning (Responsive Web Design), så det er læsbart, uanset om den vises i en lille smartphone

/ iPhone, en lidt større iPad eller tablet computer – eller om den tilgås fra en større computerskærm.

Brugergrænsef. krav 3 Layout mv.

Systemet skærmbilleder skal baseres på XHTML 1.0 eller nyere (eller tilsvarende). Skærmbilledernes

layout skal implementeres med CSS 2.0 eller tilsvarende, hvor alle muligheder i CSS 2.0 skal anvendes.

Skærmbillederne skal kunne gennemgå W3C HTML/XHTML og CSS.

Brugergrænsef. krav 4 Brug af plugins.

Leverandøren skal levere webbaserede funktioner, der som udgangspunkt er fri for applets eller andre

plug-ins.

Kunden vil dog være indstillet på, at særlige funktioner kan kræve gængse plug-ins, for eksempel Java

eller tilsvarende. Download og installering af evt. plugins skal, så vidt muligt, være automatiseret via

Systemet og anvendelsen af plug-ins skal godkendes af kunden.

Brugergrænsef. krav 5 Smart menu tilgang.

Det skal være muligt at søge efter menuer/funktioner (a la Microsoft Dynamic)

Brugergrænsef. krav 6 Touch baseret interaktion

Systemet skal understøtte touch-baseret interaktion.

Skalering og båndbredde

Dette afsnit vil gennemgå kravene til skalering.

Skalering krav 1 Skallering

Systemet skal som minimum kunne skaleres op til [x] samtidige brugere.


Sikkerhed

Dette kapitel vil gennemgå de sikkerhedsmæssige krav til det nye studiesystem.

Studiesystemet er karakteriseret ved at være et System, som:

• skal betjene mange forskellige typer Brugere

• skal kunne tilgås på en sikker måde via internettet

• integrerer til et stort antal andre it-systemer.

Derfor skal mekanismer til beskyttelse af system og data prioriteres meget højt, således at Løsningen

til enhver tid indeholder de korrekte data, og at disse er tilgængelige for de autoriserede Brugere og

kun disse.

Sikkerhed krav 1 Gældende persondatalov

Både i den offentlige og private sektor gælder loven først og fremmest for behandling af personoplys-

ninger, som sker ved hjælp af elektronisk databehandling. Dvs. at loven gælder, når personoplysninger

behandles ved hjælp af computerteknik. Loven gælder også, når personoplysninger sendes over Inter-

nettet. Loven indeholder en række regler om, hvornår man må indsamle, registrere og videregive per-

sonoplysninger osv. Hvilke regler, der skal følges i den enkelte situation, afhænger af oplysningernes

karakter og formålet med databehandlingen. Også andre love end persondataloven kan indeholde reg-

ler om, at en behandling af personoplysninger kan eller skal finde sted.

Persondataloven opdeler personoplysninger i tre typer: Følsomme oplysninger, oplysninger om andre

rent private forhold og almindelige ikke-følsomme oplysninger. Opdelingen findes, fordi der gælder

forskellige betingelser og procedurer for behandling af personoplysninger, afhængig af oplysningernes

følsomhed.

Generelt må personnummeret bruges med henblik på en entydig identifikation, eller som journalnum-

mer i den offentlige sektor. Som udgangspunkt skal enhver behandling af personoplysninger, der fore-

tages for en offentlig Myndighed, anmeldes til Datatilsynet. Der gøres opmærksom på, at Myndighe-

derne skal foretage anmeldelse til Datatilsynet, og at Leverandøren skal medvirke til denne anmel-

delse.

På tilsvarende vis skal bestemmelserne i sikkerhedsbekendtgørelsen overholdes jf. bek 528 af 15. juni

2000.

Systemet skal understøtte, at alle brugere af det nye studiesystem kan behandle personoplysninger i

overensstemmelse med persondataloven og sikkerhedsbekendtgørelsen. Datatilsynets praksis om-

kring behandling af personoplysninger skal følges, og data skal behandles i overensstemmelse med

god databehandlingsskik. Det betyder bl.a., at Leverandøren skal medvirke til sletning og at oplysnin-

ger ikke kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med person-

dataloven.

Sikkerhed krav 2 Adgang til systemet gennem WAYF Single-sign on eller almindelig lo-

gon

Systemet skal kunne understøtte single sign-on gennem Kundens browsere. Dette skal understøttes

ved hjælp af WAYF (www.wayf.dk) . Det skal ikke være obligatorisk for brugerne at tilgå Systemet via

single sign-on, da der vil være nogle af brugerne, som ikke bruger WAYF. Det skal sættes op for den


enkelte skole om brugerne for en pågældende skole får adgang til systemet via single sign on eller gen-

nem et login-vindue i en browser. Leverandørens leverance skal omfatte integrationen af Systemet til

WAYF.

Sikkerhed krav 3 Roller

Det er et krav, at rettigheder i Systemet kan tildeles og differentieres på baggrund af brugerens rolle

og tilhørsforhold i organisationen. En bruger kan have flere roller og tilhørsforhold. Det skal være mu-

ligt at definere via systemet, hvad de forskellige roller skal kunne.

Det skal være muligt at specificere visningsregler på feltniveau baseret på brugere og roller. F.eks. må

personer med hemmelige adresser kun blive vist for visse brugere og roller.

Sikkerhed 4 Sikring af fortrolighed af data som kommunikeres

Kommunikationsinfrastrukturen skal tilbyde kryptering af forbindelserne, da de udvekslede data in-

deholder personfølsomme oplysninger. Denne kryptering kan enten etableres ved SSL eller via VPN

forbindelser over netværket.

Sikkerhed 5 Differentierede indgange

Brugerne skal på baggrund af roller og rettigheder have vist forskellige indgange til systemet. Det skal

desuden være muligt at lave forskellige visninger, på baggrund af organisation, roller og personer.

Sikkerhed 6 Sikker email

Alle e-mails, som sendes fra systemet, skal kunne sendes som sikker e-mail.

Logning og overvågning

Systemet skal overvåges og sikkerhedsrelaterede hændelser skal registreres. Der skal være en logning,

som sikrer, at uønskede forhold konstateres. Overvågningen skal verificere, at sikringsforanstaltnin-

gerne fungerer efter hensigten.

Logning krav 1 Log af alle hændelser og visning af log på brugergrænsefladen

Systemet skal logge alle hændelser i workflowet til brug for senere undersøgelser af et workflow. Sy-

stemet skal således automatisk logge tid og person som har bidraget med data til et flow eller til en

blanket. Loggen skal være tilgængelig på brugergrænsefladen i et revisionsspor.

Logning krav 2 Log

Det er et krav, at der i systemet som minimum forefindes:

• En opfølgningslog

• En administrator- og operatørlog

• En fejllog

Logning krav 3 Forslag til opfølgningslog

Det er et krav, at Leverandøren kommer med forslag til, hvordan opfølgningsloggen kan sammensæt-

tes, og hvordan denne på en sikker måde kan tilgås af systemadministrator. Typiske aktiviteter inklu-

derer:


• Logning, til brug for overvågning af datatilgang, funktionsadskillelse, svartidsbidrag, fejl-

håndtering

• Proaktiv monitorering,

• Udtræk af kontrolrapporter

Logning krav 4. Forslag til fejllog

Det er et krav, at Leveandøren kommer med forslag til, hvordan fejlloggen kan sammensættes, og

hvordan denne på en sikker måde kan tilgås af systemadministrator. Typiske aktiviteter inkluderer:

• logning, til brug for fejlhåndtering

• proaktiv monitorering

Logning krav 5 Sporbarhed for hele transaktionsforløb

Det skal være muligt på baggrund af de genererede logs at følge givne forretningsmæssige transaktio-

ner igennem et eller flere transaktionsforløb.

Logning krav 6 Logning på integrationer til tredjepart

Det skal være muligt at opsamle såvel forretningsmæssige som tekniske logs omkring systemtekniske

grænseflader mod tredjepartssystemer og interessenter, således at det er muligt at overvåge, eller at

følge status på processer og dataflow omkring disse grænseflader.

Andre tekniske krav

Andre krav 1 Løsningen skal kunne driftes hos 3. part

Systemet må ikke være bundet til Leverandørens driftscenter, men skal kunne installeres og driftes

hos Kunden eller 3. Part.

Andre krav 2 Udskrivningsfunktionalitet

Systemet skal indeholde udskrivningsfunktionalitet. Udskrivningsfunktionaliteten skal håndtere føl-

gende:

• Alle sider i brugergrænsefladen skal være i udskrivningsvenligt format

• Alle dokumenter, genereret ud fra en skabelon som stammer fra Systemet skal kunne

udskrives.

• Alle dokumenter, genereret ud fra en skabelon som stammer fra Systemet skal kunne

udskrives til PDF, Officeprodukter eller tilsvarende.

Andre krav 3 Backup/restore

Back-up skal kunne ske under fuld drift uden ude eller nedetid. Leverandøren skal bruge en

Backup/restore strategi som sikrer at data kan sikkerhedskopieres betryggende.

Andre krav 4 Fejlrettelser

Ved fejlrettelse i systemet skal Leverandøren beskrive rutiner til håndtering af fejlagtige data, der er

opstået som følge af fejlen, samt rutiner for dokumentation af rettelsen.


Andre krav 5 Tab af data

It-systemet skal være sikret mod tab og forringelse af data.

Andre krav 6 Hensigtsmæssige arbejdsgange for back-up

Leverandøren skal sikre, at der kan etableres hensigtsmæssige arbejdsgange for back-up, genetable-

ring af data samt datalagring. Det skal være muligt at have sikkerhedsrutiner, der er udformet således,

at genetablering ikke overskrider de kontraktlige aftalte mål for tilgængelighed.

Andre krav 7 Data skal være tilgængelige for andre systemer

Leverandøren skal, når Kunden ønsker det, være behjælpelige med at gøre data tilgængelig for andre

systemer.

Andre krav 8 Maskin kommunikation

Alle netværksforespørgsler skal foregå på maskinnavne og ikke på IP-adresser

Andre krav 9 Veldefinerede rolle

Brugeradministration skal kunne gøres via et overskueligt antal velbeskrevne og veldefinerede profi-

ler/roller.

Andre krav 10 Granuleret og fleksibel rettighedsmodel

Systemet skal tilbyde en granuleret og fleksibel rettighed- og rollemodel. Det skal være muligt at lave

en liste over brugere med roller/rettigheder tilknyttet

Andre krav 11 Brugeroprettelse skal max foretages 1 gang

En bruger skal kun oprettes én gang uanset hvilke roller brugeren skal varetage og skal kunne foreta-

ges af skolen uden at skulle involvere Leverandøren.

Andre krav 12 Muligt at tilgå en testversion og undervisningsversion af systemet

Det skal til enhver tid være muligt at tilgå en testversion og undervisningsversion af systemet for den

enkelte skole med egne data

Andre krav 13 Eksport af data

Alle data skal kunne eksporteres fra systemet i et veldokumenteret format, eventuelt gennem en læse-

adgang direkte til datalageret.

Andre krav 14 Snitflade til forretningsobjekter

Systemet skal tilbyde(læse og skrive) alle centrale forretningsobjekter gennem veldefinerede snitfla-

der. Et forretningsobjekt skal både kunne læses, oprettes og redigeres.

Andre krav 15 Data genbrug

Når oplysninger er indtastet i systemet én gang skal systemet selv huske det og genbruge data i alle

relevante sammenhænge. For bl.a. at undgå dobbelt indtastninger.

Andre krav 16 Online brugervejledning

Der skal være en online brugervejledning til systemet som også skal kunne vedligeholdes af skolerne

selv.


Andre krav 17 Sporbarhed

Systemet skal synliggøre hvem der har foretaget en registrering i hele systemets levetid

Andre krav 18 Kigge-adgang

Det skal være muligt for f.eks. Revisor at få kigge-adgang til hele systemet. Alle indtastningsbilleder i

systemet skal have et redigerings- og et læsningsbillede(readonly), jf. behovene i D13.

Andre krav 19 Navision stats kontoplan

Det skal være muligt at trække på hele Navision Stats kontoplan og samtlige dimensioner for de en-

kelte institutioner. Endvidere skal det være muligt at afgrænse på dele af kontoplanen inden for alle

dimensioner.

Andre krav 20 Rapportskabeloner

Leverandøren skal opsætte 20 standard rapportskabeloner inden ibrugtagning af systemet. Eksempler

på rapportskabeloner er nævnt i behovsmatrix ”Rapport, statistik og udtræk”.

Andre krav 21 Soft delete

Systemet skal sikre, at der kun foretages soft delete.

Andre krav 22 Interaktion med officepakken

Systemet skal kunne Interagere med Office pakken, herunder at tilbyde brevfletnings funktionalitet.

Andre krav 23 Arbejde på mange ad gangen

Alle ændringsmuligheder på enkelte elever skal også kunne gøres på mange på en gang, f.eks via

hold/klasse.

Andre krav 24 Begrænsninger i forhold til uddannelsestyper

Systemet skal designes, således at skoler, som ikke har alle uddannelsestyper, ikke skal kunne se unød-

vendige funktionaliteter.

Andre krav 25 Fleksible visningsbilleder

Systemet skal designes således, at der er en stor fleksibilitet i visningsbilleder, således at der er plads

til en vis form for unikhed pr. skole.

Andre krav 26 Understøtte sammenhængende arbejdsgange

Systemet skal understøtte sammenhængende og kollaborative arbejdsgange.

Andre krav 27 Dokumentation og historik

Alt kommunikation ind og ud af løsningen skal medføre historik og dokumentation af kommunikatio-

nen

Andre krav 28 Sortering og filtrering

Systemet skal understøtte at man altid har mulighed for forskellige sorteringer og filtreringer fx hold,

afdelinger og cpr.nr. i alfabetisk orden.

Andre krav 29 Rolle administration

Det skal være muligt, at systemadministrator i portalen kan oprette, ændre, slette brugere og bruger-

roller og tildele og differentiere rettigheder for de nævnte brugerroller.


Andre krav 30 Kundens mulighed for kode review

Leverandøren skal på Kundens opfordring give mulighed for at Kunden, eller en uvildig part på Kun-

dens anmodning, kan foretage kode review af det samlede system.

Andre krav 31 Arkivpligt

Systemet skal overholde arkiveringspligten, herunder arkivering til Statens Arkiver

Andre krav 32 Breve til eBoks

Alle breve som sendes ud af systemet, skal kunne sendes til e-Boks.

Andre krav 33 Opdateringer af virksomheder fra CVR

Alle virksomheder skal kunne opdateres automatisk eller manuelt med oplysninger fra CVR.


Begrebsmodel

Begrebsmodellen tjener det primære formål at skabe grundlag for et fælles sprogbrug og definere de

forretningsmæssige begreber, som løsningen bygger på. Endvidere danner begrebsmodellen udgangs-

punkt for udarbejdelse af den logiske datamodel for løsningen.

Den udarbejdede begrebsmodel er et udkast, hvorfor det forventes, at Leverandøren i samarbejde med

Kundens product owner arbejder videre og tilpasser og udbygger begrebsmodellen.

Begrebsmodel krav 1 Begrebsmodel udgangspunkt for logisk datamodel

Leverandøren skal tage udgangspunkt i begrebsmodellen ved udarbejdelse af Løsningens logiske data-

model.

Begrebsmodel krav 2 Dokumentation af logisk datamodel

Leverandøren skal dokumentere Løsningens logiske datamodel ved brug af UML notationen eller til-

svarende standardiseret, anerkendt metode.

Begrebsmodel krav 3 Detaljeringsgrad af datamodeldokumentation

Tilbudsgiver skal, inden en accepteret overtagelsesprøve eller ved ophør af formelt samarbejde, detal-

jere dokumentationen for datamodellen, med overordnede beskrivelser af fag- og forretningsspeci-

fikke tabeller, samt tekstbeskrivelser af felter (attributter) som minimum med følgende oplysninger:

- Sigende navn

- Definition/meningsfyldt betydning

- Type, format og størrelse (CHAR 40, NUM 12…)

- Valideringsregel/Udfaldsrum

- Syntaks, der skal kunne genkendes af en databaseadministrator

- Kilde (relation til en person- eller systemaktør, internt modul/funktion, service).

Begrebsmodel krav 4 Fleksibel datamodel

Datamodellen skal designes og implementeres med fokus på høj fleksibilitet og robusthed, da der lø-

bende vil forekomme ændringer til datamodellen i løbet af udviklingsprocessen.

Begrebsmodel krav 5 Robust datamodel

Datamodellen skal designes således, at Løsningen løbende kan opgraderes uden besværlige database-

omlægninger.

Begrebsmodel krav 6 Opdatering af begrebsmodel

I tilfælde af, at Leverandøren og Kunden bliver enige om at foretage ændringer til begrebsmodellen, er

Leverandøren ansvarlig for at begrebsmodellen opdateres, herunder begrebsdefinitioner, samt at Løs-

ningen på alle måder følger den opdaterede begrebsmodel.

Oversigt

Begrebsmodellerne er forsøgt holdt på et overordnet, studieadministrativt niveau og skal derfor ikke

anses som værende udtømmende for et fremtidigt studiesystem. Det er essentielt at en fremtidig ud-


viklings- eller købsproces overholder begrebsmodel krav 1 – 6 og vedligeholder samt udbygger model-

lerne i samarbejder og sammenspil mellem Kunden og Leverandøren så der bibeholdes et fælles bil-

lede af domæne og begreber.

Begrebsmodel relateret til institution/skole

Figur 6 viser identificerede centrale begreber omkring en institution/skole i et studiesystem.

Godkendelse

Institution / SkoleUddannelse

Udbudssted

Afdeling

Lokale fag

UVM fag

SkoleopholdPraktikophold

AMU skolefag

Uddannelsesmodel

Udbudsoversigt

Medarbejder

Bekendtgørelse

Uddannnelses udbud

Klasse/stamhold

Tidsperiode

Niveau

Censor kompetence

Undervisnings kompetence

Uddannelsesniveau

Andre kompetencer

Ansættelseforhold

IT udstyr

Skolekalender

Komptenece register

Prøve

Karakterskala

Målepinde

Rapport skabelon

Mine rapporter

Figur 6 - Begrebsmodel relateret til institution/skole


Begrebsmodel relateret til elev

Figur 7 viser identificerede centrale begreber omkring en elev på en institution/skole i et studiesy-

stem.

Uddannelse kategori

Elev

Fagretning

Skolepraktik

Stamhold

Hold

PraktikopholdSkoleopholdUddannelse Praktiksted

Skole

Uddannelsesaftale

Prøve

Prøveresultat

Fravær

Betaler

Aktivitetsindberetning

Servicekatalog

Værelse

Takstkatalog

Booking

Elevforløb

Figur 7 - Begrebsmodel relateret til elev

Begrebsmodel relateret til registrer optagelse

Begrebsmodelelementer specifikt set i forhold til området optagelse vises i Figur 8.

ElevElevforløb

SkoleforløbPraktikforløb

Klasse/stamhold

HoldLærings-aktivitet

Lokalt fag

Kontaktlærer

Lærer

Undervisnings kompetence

UVM Fag

Figur 8 - Begrebsmodel relateret til registrer optagelse


Modulisering af behov

Introduktion til projektoplægget

Oplægget til dette forprojekt påbegyndte en stillingstagen til, hvad det kunne give mening at tale om

som moduler.

Helt konkret var forestillingen omkring modulisering beskrevet således med figur og tekst:

Udviklingen af nye applikationer tager således udgangspunkt i, at der skabes en fælles platform for

alle skoler, som uanset skolernes størrelse kan anvendes af alle. Det fælles centrale system udbygges

med særlige moduler til de forskellige uddannelsesområder, så der kan skabes ”skoleløsninger” der

tager hensyn til de forskelligheder, der er i skolernes behov for systemunderstøttelse af deres opga-

ver.

Figur 9 - Illustration af sammenhæng mellem datagrundlag, basismodul og øvrige moduler

Som vist i figuren herover tog moduliseringen udgangspunkt i de forskellige uddannelsesretninger, så

som f.eks. EUD og AMU.


Moduliserings proces og resultat

Arbejdet omkring at finde frem til en fornuftig modulopbygning tager afsæt i de behov som er blevet

identificeret i løbet af workshopsene. Denne afhængighed af behovene har også betydet at det har væ-

ret en opgave som først kunne løses sidst i forløbet.

Der har været en enighed om, at det også i fremtiden skal være muligt at benytte 3. parts produkter til

at løse afgrænsede opgaver og have resultatet af disse tæt integreret i et nyt studiesystem, så derfor

har man ønsket at kunne præsentere en behovs opdeling der tilgodeser netop dette.

Det er væsentlig at påpege at de moduler som er fremkommet er projektgruppens forslag til hvordan

man kunne gruppere behovene i logiske klumper, det ændrer ikke ved hvilke behov der er til et nyt

studiesystem, det vil derfor både være muligt og sandsynligt at et nyt studiesystem vil have andre mo-

duler end dem som er forslået her.

Resultatet af projektgruppens arbejde har gjort at den endelige modulisering tager udgangspunkt i

funktionelle grupperinger frem for de enkelte uddannelser. Uddannelsesperspektivet er fastholdt i be-

hovsmatrixen som kolonne afkrydsninger ved de enkelte behov, på denne måde kan man læse hvilke

uddannelser de enkelte behov er relevante for.

Det har afstedkommet flg. moduler:

UVM Fælles: centrale funktioner, som skal være tilstede i et system for at administrere en ungdoms-

og VEU-uddannelse Skemaplanlægning: processer vedr. skemalægningen Time- og aktivitetsplanlægningen Registrering af fremmøde Skolehjem LMS: læringsplatform indeholder samtlige processer for undervisningens gennemførsel Prøver og eksamen Bevisfremstilling Censur Personale Tidsregistrering Lønfordeling Virksomhedskontakt – praktik Lokaleressourcer

Disse moduler er illustreret grafisk herunder for at vise hvordan de passer ind i den oprindelige tanke-

gang.


Figur 10 - Illustration af sammenhæng mellem datagrundlag, basismodul og øvrige moduler


Bilag

Bilag 1: Ordforklaring

Betegnelse Beskrivelse

Aktivitetsindberetningskladde Kladdevisning i systemet som anvendes i forbindelse med indberetning af aktiviteter (årslever)

AMU Arbejdsmarkedsuddannelser.

AUB Arbejdsgivernes Uddannelsesbidrag.

Beregningsfaktor Anvendes til beregning af antal arbejdstimer til lønforde-lingen. Hvis ovenstående eksempel med skemabrikken ”Dansk” fra kl. 8.00 til kl. 8.30 har en beregningsfaktor på 1,5, skal der beregnes lønfordeling for 45 minutter.

CØSA Central Økonomistyrings- og Studieadministrative Sy-stem–tilskudssystem, der udbetaler tilskud til bl.a. EUD-aktivitet.

CØSA-formål Overordnet identifikation af enten en uddannelse, en for-målskonto, eller begge. Bemærk, at en uddannelse for at være entydigt defineret også kræver angivelse af uddan-nelsesversion relateret til en bekendtgørelse.

EASY Administrativt system på erhvervsskolerne.

EUD Erhvervsuddannelse

Faktureringsgrundlagskladde Kladdevisning i systemet som anvendes i forbindelse med opkrævning for aktiviteter, der ikke betales af UVM.

Fællesdatagrundlag For at kunne udveksle data, f.eks. informationer omkring eleven, mellem de forskellige udgaver af studiesystemet i sektoren er et fællesdatagrundlag nødvendigt. Dette er skrevet som fællesdatagrundlag eller eventuelt DUE nogle steder i materialet.

IDV Indtægtsdækket virksomhed IDV-aktiviteter kurser, konsulentbistand, administrative fællesskaber, hotel- og konferencedrift m.v.

Indbakke Indbakke begrebet bruges de steder hvor der ønskes et overblik over nye eller ikke afsluttede aktiviteter. Det er en analogi til mail programmet, hvor der dukker nye items op som man skal kunne få et overblik over samt forholde sig til

Kommunebrev En række elevoplysninger, som sendes elektronisk til det UU-center, som dækker elevens hjemkommune.

Hændelser, der bl.a. kan medføre kommunebrev: - Eleven starter på sin uddannelse. - Eleven er i risiko for at falde fra uddannelsen. - Eleven afbryder uddannelsen.


- Eleven gennemfører uddannelsen.

KUU Kombineret ungdomsuddannelse https://www.ug.dk/uddannelser/andreungdomsuddan-nelser/kombineret-ungdomsuddannelse Kombineret ungdomsuddannelse henvender sig til elever efter 9. eller 10. klasse, men som ikke har forudsætninger for at begynde på en erhvervsuddannelse eller en gymna-sial uddannelse. En tovholderinstitution foretager indberetningen til UVM og følger samme model som andre former for årselevers indberetninger.

Lokalt fag / skole fag Fag, som er blevet oprettet lokalt på en specifik skole, som ikke har en UVM tilknytning.

LUP Lokal uddannelsesplan med en fortolkning af uddannel-sesmodellen med antallet af fag med timer og aktiviteter.

PE Produktionsskolebaseret Erhvervsuddannelse.

Skemabrik Fremgår af elevens skema. Eksempelvis ”Dansk” fra kl. 8.30 til kl. 9.00. Kan også være ”Dansk” fra kl. 8.00 til kl. 10.00. Varigheden af en skemabrik kan være forskellig

Skolehjem servicekatalog En række tilkøbsydelser man kan booke på et skolehjem.

Tilskudsmærke(TM) Kode, der angiver begrundelse for ansøgning om tilskud.

Tilskudsmærkekombina-tion(TMK)

Et sæt af Tilskudsmærker.

Timepris Fastsat timepris pr. arbejdstime

Uddannelsesmodel (UMO) Et sæt stamdata, der definerer uddannelser og fag. Vedli-geholdes af UVM. Findes i flere varianter: Prøverelateret og tilskudsrelateret. Afhængig af varianten medtages for-skellige øvrige relaterede stamdata.

UVM Undervisningsministeriet.

UVM Fag Et bekendtgørelsesfag defineret centralt fra UVM.

XPRS UVM’s centrale system til prøveplanlægning.

ÅU Åben uddannelse.

https://www.ug.dk/uddannelser/andreungdomsuddannelser/kombineret-ungdomsuddannelse

https://www.ug.dk/uddannelser/andreungdomsuddannelser/kombineret-ungdomsuddannelse


Bilag 2: Vision

Arbejdet med visioner tog udgangspunkt i ”hvad er en god vision” og projektgruppens forståelse af

dette. Projektgruppens deltagere fik hver især 10 minutter til at få skrevet deres visioner på gule sed-

ler, hvorefter gruppen i fællesskab præsenterede og grupperede de fremfundne visioner. Resultatet

kan ses herunder.

Under de enkelte grupperinger findes de enkelte udsagn. I det fremadrettede arbejde blev der primært

fokuseret på grupperingerne.

Forprojekt/behovsanalyseprojektet

- ”Vi skal holde det på et højt abstraktionsniveau med respekt for de operationelle opgaver.”

Overordnede visioner for systemet

- Bedre, billigere og mere effektivt system.

- Fastholde og øge understøttelsen af digitaliseringen

- Blive sektorens foretrukne system.

- Et styringsredskab.

- Understøtte optag, elev, hold og eksamen.

Integration

- Levere stamdata til andre systemer.

- Et studiesystem, som sikrer nem integration til eventuelle nye moduler, der udvikles til sekto-ren.

- Integrationsmuligheder til studierettede opgaver.

- Levere data til et fælles datagrundlag.

- Integration til fælles datagrundlag.

- Let, billig og enkel integrations muligheder mellem studiesystemet og andre systemer (mulig-gør fra studiesystemets side af).

- Let at integrere med andre systemer (datamæssigt).

Fælles system

- Vi skal beskrive et system, som er fuldstændigt og dækkende for en mindre skole.

- Vi skal beskrive et fælles studiesystem.

- Systemet skal kunne rumme store og små skoler.

- Vi skal gå efter at dække 80% og ikke 100% opfyldelse af alles behov.

- Behovsbeskrivelse af det nødvendige system for en skole, der ikke vil købe 3. parts produkter.

Brugervenlighed

- Grafisk brugergrænseflade, mere grafik færre menuer.

- Brugervenligt system.

- Enkel indtastning, uanset uddannelsestype.

- Samme medarbejder skal kunne håndtere (næsten) alle arbejdsgange.


- Et studiesystem der er nemt, overskueligt – også for brugere, der ikke bruger systemet dagligt.

- Data registreres kun én gang til videre bearbejdning i systemet.

Enkelt og simpelt

- Simpelt input – simpelt output.

- Vi skal arbejde for en enkelt struktur og enkle arbejdsgange hvor en høj effektivitet er for øje.

- Smidig/lette enkle daglige administrative rutiner.

- Understøtte en forenkling og forbedring af adm. opgaver og arbejdsgange.

Fleksibilitet

- Fleksibelt system herunder mulighed for tilpasning f.eks. i forbindelse med nye lovkrav.

- Et moduliseret system, med en kernefunktionalitet og en række moduler, med mulighed for tilvalg/fravalg.

- Fleksibelt system med mulighed for tilvalg af andre systemer gennem modulisering.

- Fleksibilitet system i forhold til system sammenhæng og data-udveksling.

Brugergrupper

- Let at håndtere flere personalegrupper.

- Alle på skolen skal kunne hente data.

Data ind og ud som bruger af systemet

- Data-udtræk, fleksibel og overskueligt.

- Opsætte rettigheder, datasikkerhed og personopslag.


Bilag 3: Aktører og behov

Dette afsnit er tiltænkt den læser som ønsker at kunne få et overblik over hvilke behov som er knyttet

til bestemte aktørtyper og er en opsamling på de behov som er beskrevet i behovsmatrixen. Der findes

ikke information i dette afsnit som ikke også findes i behovsmatrixen, afsnitte tjener alene det formål

at give læseren en oversigt med udgangspunkt i aktører.

Der er identificeret 10 forskellige aktørtyper som skal kunne agere i et nyt studiesystem:

- Elev/kursist

- UVM

- Skole

- Censor

- System

- Underviser

- Skolehjemsadministration

- Revisor

- Skoleledelse

- Planlægningssystem

Herunder er er der forsøgt at give et overblik over, hvilke behov de enkelte brugergrupper har til et

nyt system.

UVM

TV1 Som UVM skal man kunne oprette og vedligeholde institutionsregister.

TV3 Som UVM skal man kunne oprette og vedligeholde uddannelser med CØSA numre.

TV4 Som UVM skal man kunne oprette og vedligeholde links til bekendtgørelser.

TV5 Som UVM skal man kunne oprette og vedligeholde UVM fag.

TV6 Som UVM skal man kunne oprette og vedligeholde centrale uddannelsesmodeller for de enkelte bekendtgørelser.

TV7 Som UVM skal man kunne oprette og vedligeholde takstkatalog.

TV8 Som UVM skal man kunne oprette og vedligeholde målepinde på UVM fag.

TV9 Som UVM skal man kunne oprette og vedligeholde karakterskala samt definere de prøvetyper der kan være på et UVM fag.

TV10 Som UVM skal man kunne oprette og vedligeholde AMU kurser med FKB numre.

TV15 Som UVM skal man kunne oprette og vedligeholde de karakter/godkendelsesmo-deller, som skal kunne bruges i systemet.

TV19 Som UVM skal man kunne oprette og vedligeholde de indgange der måtte være til GF1, f.eks. de 4 der findes i dag.


TV29 Som UVM skal jeg kunne oprette og vedligeholde centrale frafaldsårsager.

TV33 Som UVM skal jeg oprette/vedligeholde hvilke UVM fag som er prøvefag på de en-kelte uddannelser

I1 Som UVM skal man kunne godkende en skole (organisation) til at køre en uddan-nelse i en given tidsperiode.

I2 Som UVM skal man kunne vedligeholde tidsperioderne for godkendelserne og stoppe en godkendelse vedr. en uddannelse.

I3 Som UVM skal jeg kunne godkende en skole (organisation) til at køre et specifikt AMU kursus i en given tidsperiode.

I4 Som UVM skal man kunne vedligeholde tidsperioderne for godkendelserne og stoppe en godkendelse vedr. et AMU kursus.

I5 Som UVM skal jeg kunne godkende en institution til at kunne køre et enkelt fag, f.eks til åben uddannelse.

Elev / kursist

E16 Som elev skal jeg kunne se min eksamensoversigt samt mine resultater

L2 Som elev skal jeg kunne se mulige valgfag samt vælge hvilke valgfag jeg ønsker

L7 Som elev kan jeg se hvilke valgfag jeg har fået

L19 Som elev kan jeg se en liste over mine læringsrum og tilgå dem enkeltvis

L20 Som elev skal jeg kunne se holdoversigt, dvs. en oversigt over underviserer og andre elever

L21 Som elev skal jeg kunne danne og indgå i lærings-grupper i læringsrummene

L22 Som elev skal jeg kunne se min lektionsplan

L23 Som elev skal jeg kunne tilgå mit skema i lærings-rummet

L26 Som elev skal jeg kunne aflevere en opgave tilknyt-tet en lektion eller en læringsaktivitet

L30 Som elev kan jeg se mine afleverede opgaver/eksa-mener og deres bedømmelser/karakterer

L37 Som elev kan jeg evaluere på et undervisningsfor-løb, både på indhold og undervisere

L43 Som elev skal jeg kunne udfylde en valg af fags for-mular

T6

Som elev på GF1 skal jeg i systemet kunne vælge en uddannelse på GF2. Ansøgningen skal havne i en indbakke


O20 Som elev eller skole skal man kunne lægge billede på elevens profil.

SK11

Som elev eller kursist skal man kunne logge ind og markere, hvorvidt man ønsker skolehjem i sin sko-leperiode.

S14 Som elev skal man kunne registrere sit fravær elek-tronisk.

S15 Som elev skal man kunne se et overblik over sit eget fravær.

SKEMA18 Som elev skal jeg kunne se skema.

GS3

Elever som har angivet eventuelle særlige behov via Optagelse.dk eller som har fået dem identifice-ret under uddannelsen skal vises i en indbakke til håndtering af dette i systemet.

SKEMA14

Som elev eller skole skal man kunne se skemaet med udgangspunkt i eleven, en underviser, et hold m.m.

Underviser

E24 Som underviser har jeg adgang til min prøver/ek-samener hvor jeg kan afgive karakterer

E25

Som underviser kan jeg planlægge hvornår den en-kelte elev har prøvetidspunkt på de enkelte eksa-mensdage

L40 Som underviser eller elev kan jeg oprette og indgå i tværgående dialogfora

SKEMA28 Som underviser skal jeg kunne se min egen opga-veoversigt

SKEMA36 Som underviser skal jeg modtage en revideret op-gaveoversigt med advisering herom

Censor

TV36 Som censor kan jeg angive rådighedsperioder hvor jeg kan udøve censur

E23

Som censor har jeg adgang til min prøver/eksame-ner hvor jeg kan afgive karakterer og frigive resul-tater


Revisor

S3

Som revisor skal man kunne godkende en aktivi-tetsindberetning før eller efter afregning fra mini-steriet.

S31

Som revisor skal man kunne godkende en varig-hedsuafhængig tilskudindberetning før eller efter afregning fra ministeriet.

Skoleledelse

S4

Som skoleledelse skal man kunne godkende en ak-tivitetsindberetning før eller efter afregning fra ministeriet.

S32

Som skoleledelse skal man kunne godkende en va-righedsuafhængig tilskudsindberetning før eller ef-ter afregning fra ministeriet.

Skolehjemsadministration

SK1

Som skolehjemsadministration skal man kunne op-rette og vedligeholde et takstkatalog for værel-serne med pris.

SK2

Som skolehjemsadministration skal man kunne op-rette og vedligeholde værelser og bl.a. markere, hvorvidt det er et enkelt eller dobbelt værelse.

SK3

Som skolehjemsadministration skal man kunne få et overblik over hvilke værelser, der findes samt deres belægning.

SK5

Som skole skal man kunne opsætte på en uddan-nelse, hvorvidt der skal laves automatiske rejse-plans opslag.

SK6 Som skolehjemsadministration skal man kunne op-rette og vedligeholde et servicekatalog med priser.

SK7

Som skolehjemsadministration skal man kunne lave en manuel booking af værelse samt vedlige-holde bookinger.

SK8 Som skolehjemsadministration skal man kunne lave et udtræk med bookinger.

SK9 Som skolehjemsadministration skal man kunne få en belægningsoversigt.

SK10 Som skolehjemsadministration skal man kunne fo-retage en automatisk booking af et værelse til en


elev. Herved skal systemet finde et passende væ-relse til eleven ud fra en række regler.

SK13

Som skolehjemsadministration skal man kunne modtage en elev i sin indbakke, når det er beslut-tet, at denne elev skal have indlogering.

SK14 Som skolehjemsadministration skal man kunne på-sætte en TMK.

SK15 Som skolehjemsadministration skal man kunne an-give, om eleven er til stede på ugebasis.

SK16

Som skolehjemsadministration skal man kunne danne opkrævninger og sende dem til Navision stat.

SK17 Som skolehjemsadministration skal man kunne se, om en regning er blevet betalt.

SK18 Som skolehjemsadministration skal man kunne lave en kreditnota.

SK21 Som skolehjemsadministration skal man kunne lave en opkrævning af tillægsydelser.

Planlægningssystem

SKEMA2 Som planlægningssystem skal jeg kunne tage højde for lokaletilgængelighed

SKEMA3 Som planlægningssystem skal jeg kunne tage højde for knappe ressourcer

SKEMA4 Som planlægningssystem skal jeg kunne tage højde for timeplaner

SKEMA5 Som planlægningssystem skal jeg kunne tage højde for sammenhængende lektioner

SKEMA6 Som planlægningssystem skal jeg kunne tage højde for friholdelsestidspunkter

SKEMA7

Som planlægningssystem skal jeg kunne tage højde for de maksimale undervisningstimer pr. undervi-ser pr uge

SKEMA8 Som planlægningssystem skal jeg kunne tage højde for antal klokketimer pr uge for eleven

SKEMA9 Som planlægningssystem skal jeg kunne tage højde for undervisernes forskellige kompetencer

SKEMA10

Som planlægningssystem skal jeg kunne tage højde for, hvor stor en del af uddannelsesplanen, der skal planlægges


SKEMA11

Som planlægningssystem skal jeg kunne tage højde for at en elev, lokale eller lærer ikke dobbelt-bookes.

SKEMA12 Som planlægningssystem skal jeg kunne tage højde for skemablokerende aftaler/aktiviteter

SKEMA20

Som planlægningssystem skal jeg kunne håndtere at man i en periode har behov for at skemalægge ekstra undervisningstimer på et enkelt fag

SKEMA23

Som planlægningssystem skal jeg kunne hente den enkelte undervisers normtimer og evt. aldersre-duktion

SKEMA27

Som planlægningssystem skal jeg kunne danne en opgaveoversigt pr. underviser for den planlagte pe-riode/normperiode

Skole

TV2 Som skole skal man kunne oprette en afdeling på kladdeniveau, som UVM skal godkende.

TV11

Som skole skal man kunne oprette en kladde for udbudssteder knyttet til de enkelte uddannelser, som UVM skal godkende.

TV12 Som skole kan man kunne oprette og redigere lo-kale fag.

TV13 Som skole kan man kunne oprette og redigere må-lepinde på lokale fag.

TV14

Som skole skal man kunne oprette og vedligeholde karakterskala samt definere de prøvetyper, der kan være på et lokalt fag.

TV16 Som skole skal man kunne oprette og vedligeholde skolekalendere med fridage, helligdage og ferie.

TV17

Som skole kan man kunne oprette og vedligeholde skabeloner til kommunikation f.eks. e-mail, sms og Word.

TV18

Som skole skal man kunne oprette og redigere et kompetenceregister, således at medarbejderne kan få tilknyttet fast definerede kompetencer.

TV20

Som skole skal man kunne oprette og redigere timeplaner, og disse skal tilknyttes på forskellige niveauer i systemet.


TV21

Som skole skal man kunne oprette en lokal uddan-nelsesmodel, som er en implementering af en be-stemt bekendtgørelse.

TV22 Som skole skal man kunne danne et kommune-brev, som sendes til tilbagemelding.dk.

TV23

Som skole skal man kunne kommunikere med ele-ver, forældre, værger, arbejdsgiver m.m fra syste-met.

TV24 Som skole skal man kunne oprette og redigere ge-byrtyper til brug ved opkrævning.

TV25 Som skole skal man kunne lave en opkrævning og sende den til Navision stat.

TV26 Som skole skal man kunne lave en kreditnota og sende den til Navision stat.

TV27 Som skole skal man kunne sende en arbejdsgiver-plan til arbejdsgiveren.

TV28

Som skole skal man kunne oprette fælles/individu-elle aftaler og aktiviteter til elever og medarbej-dere.

TV30 Som skole skal jeg kunne fremsøge en elev eller underviser for at se deres skema og hvor de er

TV31 Som skole skal man kunne gemme dokumenter og filer til arkiv i stedet for at printe dem.

TV34

Som skole kan jeg oprette/vedligeholde hvilke lo-kale fag som er prøvefag på de enkelte uddannel-ser

TV35 Som skole kan jeg oprette/vedligeholde et censor-kartotek

TV37 Som skole skal jeg kunne underopdele centrale fra-faldsårsager samt redigere disse

TV38 Som skole skal jeg kunne oprette og vedligeholde en eller flere fælles arkivstrukturer

E1

Som skole finder jeg frem til og vedligeholder hvilke undervisere der kan indgå i et skriftligt cen-sorkorps for et skoleår

E2 Som skole indeberetter jeg censorpulje/censor kompetencer

E3 Som skole kan jeg oprette/redigere lærerfrihol-delse og sende disse til XPRS

E4 Som skole kan jeg i min indbakke se udtrukne eksa-mensfag fra XPRS


E5

Som skole henter jeg udtræk af prøvefag fra XPRS samt censorfag for flerfaglige prøver som ender i en indbakke

E6

Som skole skal jeg kunne danne et udtræk til ele-ven af de fag, som eleven skal til eksamen i på bag-grund af Undervisningsministeriets udtræk

E7 Som skole opretter jeg prøvehold/eksamenshold til de enkelte eksamensfag

E8 Som skole kan jeg danne mig et overblik over resul-tatet af eksamensplanlægningen og ændre i dette

E9 Som skole indsender jeg min prøveplan til XPRS så-ledes at der kan påsættes censorer

E10

Som skole indsender jeg prøveplaner for studieret-ningsprojekt (SRP) og større skriftelige opgaver (SSO) til XPRS således at der kan påsættes censorer

E11 Som skole henter jeg udtræk af censortildeling fra XPRS på egne og eksterne undervisere.

E12

Som skole skal jeg kunne hent et udtræk af censor-planer med følgende oversigt: - Hvilke af egne undervisere skal være censor på andre skoler - Hvilke eksterne censorer er knyttet til skolens ek-samensfag

E13

Som skole skal jeg kunne sende information vedr. eksamensbegivenhed til den skole som leverer den eksterne censor

E14 Som skole skal jeg kunne bede om en erstatnings-censor

E15 Som skole kan jeg offentliggøre eksamensplaner til underviser og elever

E17 Som skole kan jeg se et overblik over lokaler brugt til eksamen

E18 Som skole overfører jeg realiserede prøveplaner for skriftlige og mundtlige prøver til XPRS

E19 Som skole kan jeg i min indbakke se prøver/eksam-ner som ikke er planlagt

E20 Som skole skal jeg kunne udvælge fag til at indgå i egne interne prøver(f.eks. årsprøver)

E21

Som skole kan jeg benytte en eksamensplanlæg-ningsmotor som fortæller hvilke dage der skal være prøver i hvilke fag. Eksamensplanlægnings-motor giver mig en grafisk nem og overskuelig vis-ning.


E22

Som skole skal jeg kunne se eksamensbelastningen for alle undervisere på en uddannelse(CØSA num-mer)

E26 Som skole kan jeg hente karakterer og evt. opgaver fra netprøver.dk

E27 Som skole skal man kunne aflyse en eksamen

E28 Som skole skal man kunne flytte en eksamen

E29 Som skole kan jeg oprette eksamensbevisskabelo-ner

E30 Som skole skal jeg kunne danne eksamensbeviser på forskellige niveauer (uddannelse,hold, elev)

E31 Som skole kan jeg sende eksamensbeviser til eksa-mensdatabasen

E32 Som skole kan jeg sende eksamensbeviser til ele-vens e-Boks og gensende

E34

Som skole skal jeg kunne få et overblik over om elever overholder uddannelsesmodellen inden der dannes eksamensbevis

E35 Som skole skal jeg kunne sende pensumlister/un-dervisningsbeskrivelser til censor

E36 Som skole skal jeg kunne identificere om en elev er færdig med skoleforløb.

E37

Som skole skal jeg efter afsluttet GF2/EUV kunne stille færdiggjorte elever til rådighed for EASY-P via integration

E38

Som skole skal jeg have mulighed for at sætte ny beskikket censor som erstatning for forhindret cen-sor

E39 Som skole skal jeg kunne danne eksamensbevi-ser/prøvebeviser fra tidligere uddannelsesmodeller

E40 Som skole skal jeg kunne genudskrive/ genfrem-sende eksamensbeviser til elever

E41 Som skole skal jeg kunne hente eksterne skabelo-ner til deltagerbeviser på AMU

E42

Som skole skal jeg kunne hente eksterne skabelo-ner til eksamensbeviser på Åben Uddannelse, her-under enkeltfag

L1 Som skole skal jeg kunne udbyde valgfag i en given periode for udvalgte hold


L3

Som skole kan jeg danne mig et overblik over hvor-dan elever fordeler sig på valgfag efter de har øn-sket.

L4

Som skole kan jeg lave et valgfagstjek således at man kan danne sig et overblik over hvorvidt elever opfylder valgfagskrav.

L5 Som skole kan jeg acceptere en valgfagsfordeling samt danne hold til eleverne

L6

Som skole benytter jeg en valgfagsfordelingsmotor for at kunne give det mest optimale udfald som ho-norerer de fleste elevers ønsker

L9 Som skole skal jeg kunne oprette en struktureret materialebase

L10 Som skole skal jeg kunne tilføje og vedligeholde indhold i materialebasen

L11

Som skole kan jeg opbygge en pensumliste for en læringsaktivitet ved at tilføje indhold fra materiale-basen

L12 Som skole kan man oprette og vedligeholde en lek-tionsplan baseret på pensumlisten

L13 Som skole kan jeg oprette læringsrum for lærings-aktiviteter og tilknytte hold samt lektionsplan

L14 Som skole skal jeg kunne tilpasse lektionsplanen for den enkelte læringsaktivitet i læringsrummet

L16 Som skole skal jeg kunne åbne læringsrummet for elever på holdet

L17 Som skole skal jeg kunne tilknytte en eller flere un-dervisere til læringsrummet

L18

Som skole skal jeg kunne danne mig et overblik over kolliderende større opgaver ( i forhold til lekti-onsplaner og hold) og få hjælp til at afhjælpe opga-vetrængslen

L25

Som skole skal jeg kunne dato- og tidssætte speci-fikke opgaver og læringsmaterialer med visnings-dato i læringsrumet

L27 Som skole skal jeg kunne oprette og vedligeholde en dato og tidspunkt for aflevering af en opgave

L28 Som skole skal jeg kunne tilknytte en fremlæggel-sesform til en enkelt opgave

L29 Som skole skal jeg kunne bedømme en opgave og en evt. fremlæggelse


L31 Som skole knytter jeg målepinde til indholdet i ma-terialebasen

L32

Som skole knytter jeg målepinde til lektionsplanen, således at afholdelse af lektioner og godkendelse af opgaver medfører fremdrift på målepindene

L34

Som skole skal jeg kunne udsende manuelle og au-tomatiske beskeder og advarsler i forbindelse med bl.a opgaveaflevering

L35 Som skole kan jeg se om den enkelte elev har åb-net materialet i læringsrummet

L36 Som skole skal jeg kunne se en oversigt over hvilke elever der mangler at aflevere hvilke opgaver

L41

Som skole skal jeg kunne tilknytte et eller flere fag til en læringsaktivitet som eleverne kan vælge imellem f.eks. Til AT, SRO, SSO og SRP

L42 Som skole kan jeg udsende en formular til eleverne til valg af fag

L44 Som skole skal man kunne behandle elevens valg af fag, herunder afvise og godkende

L46

Som skole kan jeg danne mig et overblik over hvor-dan elever fordeler sig på valg af fag efter de har ønsket.

G1 Som skole skal man kunne oprette elevforløb (ud-bud) for de enkelte uddannelser.

G2

Som skole skal man kunne få et grafisk overblik i en kalendervisning over belægningen af de enkelte uddannelser (udbud).

G3 Som skole skal man kunne oprette 1..n antal stam-hold på et enkelt elevforløb.

T4 Som skole skal man kunne manuelt tilmelde en elev, som derefter havner i en indbakke.

T5 Som skole skal man kunne sende en ansøgning til-bage til Optagelse.dk med en ny skole på.

T9 Som skole skal man kunne sende en ansøgning til-bage til brobygning.net.

T11 Som skole skal man kunne sende en ansøgning til-bage til efteruddannelse.dk.

T14 Som skole skal man kunne oprette en ansøgning til IDV fra en enkelt eller flere kursister.

T15 Som skole afstemmer jeg det forventede antal klasser med regionen


T16

Som skole deltager jeg i et fordelingsmøde i forde-lingsudvalget med henblik på at afstemme hvem der optager hvem

O3

Som skole skal man kunne afklare, om en elev kan optages direkte på udannelsen (GF1, GF2, EUX, EUV og gymnasiale uddannelser) på baggrund af karakterer. Hvis dette er muligt, skal eleven sendes til en ny indbakke, ellers skal der tilbydes prøver og samtale. Der gennemføres optagelsesprøver og ud-stedes prøvebeviser på samme måde som ved øv-rige prøver.

O7 Som skole skal man kunne afklare, om en elev kan optages direkte på GF2 på baggrund af karakterer.

O9 Som skole skal man kunne markere, at en elev øn-sker skolepraktik.

O10 Som skole skal man kunne markere og se, om en AMU kursist opfylder krav til bl.a. beståede kurser.

O11 Som skole skal man kunne tilføje ekstra dokumen-tation fra en kursist.

O12 Som skole skal man kunne se, om betaler af kurset skylder i forvejen.

O13 Som skole skal man kunne se, om eleven skylder i forvejen.

O14

Som skole skal man fra indbakken kunne placere elever på et elevforløb og dermed på et eller flere skoleforløb

O15 Som skole skal man kunne modtage elever, som skal i skolepraktik, i en indbakke

O16 Som skole skal man kunne oprette praktikforløb med tilhørende uddannelsesaftaler.

O17 Som skole skal man kunne tilknytte en elev til et praktikforløb.

O18

Som skole skal man kunne opsætte, om der skal udsendes en indkaldelse af elever automatisk x dage før studiestart.

O21 Som skole kan man udstede studiekort.

O22

Som skole skal man kunne få et overblik over opta-gede elever, og om de er korrekt oprettet i andre systemer(UNI-LOGIN), således at man kan sende information om login, m.m. til eleverne i indkaldel-sen.


O23

Som skole skal man for hver enkelt uddannelse/af-deling kunne opsætte, hvorvidt man anvender indi-viduelle samtaler, infomøder og/eller breve

O24 Som skole skal man kunne indkalde elever til sam-taler og infomøder.

O25 Som skole skal man kunne se en elektronisk proto-kol (overbliksbillede).

O26

Som skole skal man kunne sende et tro-og-love do-kument ud til eleverne, som de skal underskrive elektronisk.

O27

Som skole skal man kunne overføre en elev til en anden skole, hvilket betyder, at der oprettes en kopi af eleven og dennes data. Ved overførsel mel-lem flere forskellige studiesystemer, skal dette håndteres via det fælles datagrundlag.

O28 Som skole skal jeg i en indbakke kunne modtage en overført elev fra en anden skole.

O29 Som skole skal man kunne udmelde en elev og an-give frafaldsårsag per specifik dato

O30 Som skole skal man kunne sætte et elevforløb (og dermed en elev) på orlov.

O32 Som skole skal man kunne starte en process for en elevs frivillige udmeldelse.

O33

Som skole modtager jeg en liste med navn og cpr nummer fra en virksomhed og opretter disse kursi-ster og holdplacerer dem

O34 Som skole skal man kunne opkræve deltagerbeta-ling for elever og kursister

O35 Som skole skal jeg kunne importere/eksportere data fra KUU-portalen.

O36 Som skole skal jeg kunne indtaste KUU forløbspla-ner direkte fra UU.

O37

Som skole skal jeg kunne tildele eleven forskellige personer med forskellige roller, fx. Kontaktperson (studievejledere)

O38 Som skole skal jeg kunne lave og sende RKV bevis til eleven

O39 Som skole skal man kunne oprette et RKV forløb på lige fod med andre uddannelser

O40 Som skole skal jeg kunne registrere hvorvidt eleven opfylder §16-kravene om 28-klasseloftet.


SK12

Som skole er man forpligtiget til at tilbyde indloge-ring, først via skolehjem men ellers på vandrehjem eller hotel.

SK19 Som skole skal jeg kunne sende et velkomstbrev, der beskriver mulighed for skolehjem.

SK20

Som skole skal man på en uddannelse kunne mar-kere, hvorvidt man ønsker at tilbyde hjælp til eks-tern booking, såfremt der ikke er plads på skole-hjemmet.

SK23 Som skole skal man kunne indberette skolehjems-bidrag til AUB på elever med uddannelsesaftaler.

S1

Som skole skal man kunne oprette en aktivitetsind-beretningskladde (med beregningsgrundlag) med kontrolliste over, om eleverne/kursisterne er kor-rekt registreret, og/eller om regler er overtrådt.

S2 Som skole skal man kunne lave en eksport af aktivi-tetsindberetningskladden til CØSA systemet.

S5

Som skole skal man kun lave en faktureringsgrund-lagskladde med faktureringsgrundlag på de aktivi-teter, som ikke afregnes med UVM.

S6 Som skole skal man kunne sende en godkendt fak-tureringsgrundlagskladde til Navision.

S7

Som skole skal man kunne sende en fakturerings-grundlagskladde eller aktivitetsindberetnings-kladde til STILs beregningsmotor og få et resultat retur.

S8 Som skole skal man på en uddannelse kunne mar-kere, hvilket fraværs detaljeringsgrad der ønskes.

S9

Som skole skal man kunne registrere fravær/tilste-deværelse på en elev med en fraværstype samt en bemærkning.

S12

Som skole skal jeg på en uddannelse kunne op-sætte, om der skal sendes e-mail, sms eller brev ved fravær.

S13 Som skole skal man på en uddannelse kunne op-sætte, om eleven elektronisk må angive fravær.

S16 Som skole skal man kunne udfylde/afvinge måle-pinde ved opnåede færdigheder.

S17

Som skole skal man kunne se en grafisk oversigt over, hvor langt eleven er i forhold til målepinde, og hvilke elever har fået karakter.

S20 Som skole skal man kunne angive en karakter på et fag eller en prøve på en elev.


S22 Som skole skal man kunne markere, om et uddan-nelsesforløb er bestået.

S26

Som skole skal man kunne se i sin AUB indbakke, hvem der skal kigges på i forhold til transportrefu-sion samt beregne transportrefusion for disse sko-leforløb.

S27

Som skole skal man kunne sende indberetning til AUB med antal skoledage samt evt. transportudgif-ter, der skal refunderes.

S29

Som skole skal man kunne oprette en varigheds-uafhængig tilskudsindberetningskladde (med be-regningsgrundlag) med kontrolliste over, om ele-verne er korrekt registreret og/eller om regler er overtrådt.

S30 Som skole skal man kunne lave en eksport af varig-hedsuafhængig tilskud til CØSA systemet.

S34

Som skole skal man kunne oprette en manuel an-søgning for samtlige uddannelsestyper for en elev eller en kursist.

S36 Som skole skal man kunne oprette og vedligeholde elever og kursister.

S37 Som skole skal jeg på en elev kunne se dennes ud-dannelser.

S38

Som skole skal man kunne på den enkelte elev se status, udlån, fravær, historik, kontaktperson, kommunikation, noter, filer, aktiviteter og revision på de enkelt uddannelsesforløb samt samlet.

S39 Som skole skal man på en elev kunne se og vedlige-holde et filarkiv.

S40

Som skole skal man på en elev kunne se, oprette og vedligeholde interne og eksterne noter og på-mindelser.

S42 Som skole kan jeg oprette/vedligeholde et register over elev samtale/aktivitetstyper

S43 Som skole kan jeg oprette en samtale/aktivitet på en enkelt elev

S44

Som skole kan jeg danne mig et overblik over an-tallet af tilbudte timer på læringsaktiviteter og fag i forhold til det fastsatte timeantal i uddannelses-modellen (bekendtgørelsen)

S45 Som skole kan jeg dele et elevforløb med en anden skole, fx i forbindelse med skolepraktik


SKEMA1 Som skole skal man kunne skemaplanlægge loka-ler, elever og undervisere.

SKEMA15 Som skole skal man kunne skemaplanlægge en-kelte timer.

SKEMA19 Som skole skal man kunne angive undervisningsfrie tidspunkter for den enkelte medarbejder.

SKEMA21 Som skole skal jeg kunne opsætte en planlægnings-periode

SKEMA22

Som skole skal jeg kunne danne et overblik over medarbejder pr. afdeling/ansvarsområde kombine-ret med afdelingens/områdets aktiviteter

SKEMA24 Som skole skal jeg have mulighed for at fordele den enkelte underviser på aktiviteter

SKEMA25 Som skole skal jeg have mulighed for at opgøre den enkelte undervisers fordeling på aktiviteter

SKEMA26 Som skole skal jeg have mulighed for at opsætte øvrige aktiviteter end undervisning

SKEMA29 Som skole skal jeg kunne opsætte ferie, særlige fe-riedage, afspadsering m.m. pr. undervisere

SKEMA30

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente data til time-fagfordeling og aflevere resultatet som input til skemaplanlæg-ningen

SKEMA31 Som skole skal jeg kunne opsætte mål for konfron-tationstimer/procent

SKEMA32 Som skole skal jeg kunne håndtere ud- og indlån af undervisere mellem afdelinger og skoler

SKEMA33 Som skole skal jeg kunne tilknytte timelærere

SKEMA34

Som skole skal jeg kunne danne et overblik over af-delingens samlede timebudget i forhold til ressour-cer

SKEMA35 Som skole skal jeg kunne opdatere time-fagforde-lingen løbende

ET1

Som skole skal man kunne placere elever i én klasse/stamhold fra indbakken. Det er ikke tvun-get.

ET2

Som skole skal man kunne rette start- og slut-dato på elevforløb, skoleforløb og praktikforløb på hver enkelt elev.

ET3

Som skole skal man kunne oprette læringsaktivite-ter, som består af et eller flere lokale fag og/eller UVM fag.


ET4

Som skole skal man kunne oprette et eller flere hold, som er tilknyttet til en eller flere læringsakti-viteter og/eller et eller flere fag.

ET5 Som skole skal man kunne tilknytte elever til et el-ler flere hold.

ET6

Som skole skal man kunne angive merit på en en-kelt elev på henholdsvis fag, målepinde, skolefor-løb, praktikforløb, elevforløb.

HR1

Som skole skal man kunne oprette og vedligeholde medarbejdere samt markere hvorvidt man er un-derviser.

HR2 Som skole skal man kunne oprette og vedligeholde ansættelsesforhold på en medarbejder.

HR3

Som skole skal man kunne oprette og vedligeholde antal omsorgsdage, ferie/fridage, alderstillæg og belastningstillæg på personalet.

HR4 Som skole skal man kunne angive en medarbejders uddannelsesniveau.

HR5 Som skole skal man kunne angive en medarbejders undervisningskompetencer.

HR6 Som skole skal man kunne angive en medarbejders censor-kompetencer.

HR7 Som skole skal man kunne angive en medarbejders andre kompetencer.

HR8 Som system skal jeg tilbyde data om personale, så-ledes at andre systemer kan gøre brug af disse.

HR9 Som system overfører jeg personaleoprettelse og -ændringer til SLS og Silkeborg Løn.

HR10

Som skole skal man kunne få et overblik over sine underviseres planlagte fravær så som barsel, ferie, kurser, andre aktiviteter m.m.

HR11 Som skole skal man kunne få et overblik over sine underviseres ikke planlagte fravær, f.eks sygdom

HR12

Som system tilbyder jeg snitflade til andre syste-mer, der indeholder oplysninger om underviseres planlagte fravær så som ferie, kurser, barsel, syg-dom m.v.

HR13

Som system tilbyder jeg snitflade til andre syste-mer, der registrerer sygdomsfravær og ferie (f.eks. SLS-FRAV)

HR14 Som medarbejder skal jeg kunne opdatere min in-dividuelle kompetencer


HR15 Som skole skal jeg kunne afslutte en medarbejders ansættelsesforhold

HR16

Som skole skal jeg kunne opsætte forskellige kate-gorier til at registrere medarbejdernes tid til fx un-dervisning, ferie og kompetenceudvikling.

HR17 Som skole skal jeg kunne registrere medarbejder-nes tidsforbrug på forskellige kategorier.

HR18

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente data til tidsregisteringen og aflevere data tilbage til systemet som registre-ret tid

HR19

Som system tilbyder jeg en snitflade således at re-gistreret tid kan sendes til og modtages fra andre systemer

HR20 Som skole skal man på en medarbejdere kunne se og vedligeholde et filarkiv.

P1

Som skole kan jeg benytte et CRM lignende system i det nye system til at oprette og vedligeholde akti-viteter på praktiksteder

P2 Som skole kan jeg se en oversigt over praktikplads-opsøgende aktiviteter (hvem, hvad og hvornår)

P3 Som skole kan jeg lave lokale aktiviteter/kampag-ner målrettet udvalgte brancher.

P4

Som skole skal jeg kunne danne mig et overblik over kommende aktiviteter/kampagner på virk-somhederne

P5

Som skole skal jeg kunne udtrække en liste af rele-vante virksomheder i forhold til bestemte kriterier, f.eks i forhold til kampagner på enkelte uddannel-ser

P8

Som skole kan jeg benytte et CRM lignende system i det nye system til at oprette og vedligeholde akti-viteter på virksomheder

P9 Som skole skal jeg kunne registrere virksomheds-besøg

P10 Som skole skal jeg kunne registrere opfølgningsak-tiviteter i forhold til virksomhederne

P11 Som skole skal jeg kunne udtrække relevante typer af aktiviteter fordelt på virksomheder

P12 Som skole skal jeg kunne registrere resultatet af virksomhedsbesøget


P15 Som skole skal jeg kunne forkalkulere IDV-aktivite-ter.

IT1 Som skole skal man kunne oprette og vedligeholde udleveret it-udstyr så som pc, nøglebrik m.m.

GS1 Som skole sender jeg data vedr. elever og deres uddannelse og beskæftigelse til ungedatabasen.

GS2 Som skole skal jeg kunne oprette samtaler/aktivite-ter omhandlende gennemførelsesvejledning/støtte

GS4

Som skole skal jeg kunne danne mig et overblik over hvilke elever der skal have foretaget en SPS-screeningen og planlægge disse.

GS6

Som skole skal jeg kunne indberette afholdte om-kostninger(timer, indkøb af udstyr mm.) til UVM og modtage refusion.

Ø1

Som skole kan jeg på samtlige indberetninger ar-bejde med forecasts således at man løbende kan få et økonomisk overblik

Ø2 Som skole registrerer jeg et antal arbejdstimer på hold/aktivitet via skemabrik

Ø3 Som skole kan jeg angive en default beregningsfak-tor samt ændre den pr skemabrik

Ø4 Som skole kan jeg angive en default timepris samt ændre den pr skemabrik

Ø5 Som skole skal jeg kunne lave en lønfordelingskør-sel samt afgrænse den på et datointerval

Ø6 Som skole kan jeg se en fejll og hvis lønfordelings-kørslen er fejlet

Ø7 Som skole kan jeg danne en kladde af en lønforde-lingskørsel og sende den navision stat

Ø8 Som skole kan jeg importere og vise et forecast for AUB præmietræk

Ø9 Som skole kan jeg sende indberetningsresultater samt indberetningskladder til Navison Stat

Ø10 Som skole kan jeg oprette budgetmodeller for en periode

B1 Som skole kan jeg oprette/redigere lokaler

B2 Som skole skal jeg kunne oprette/vedligeholde en lokaleudstyrsliste

B3 Som skole skal jeg kunne oprette/vedligeholde en lokalekategori


B4 Som skole kan jeg tilknytte en eller flere lokalean-svarlige for et enkelt lokale

B5 Som skole kan jeg oprette/redigere oplysninger om bygninger

B6 Som skole skal jeg kunne oprette/redigere vedlige-holdelsesplaner for en bygning og lokaler

B7 Som skole skal jeg kunne oprette/redigere vedlige-holdestyper

B8 Som skole skal jeg kunne planlægge vedligeholdel-sesaktiviteter for et budgetår

B9 Som skole skal jeg kunne oprette/vedligeholde ser-viceaftaler/kontrakter

B10 Som skole skal jeg kunne oprette/vedligeholde nøglesystemer

B11 Som skole kan jeg oprette/vedligeholde rengø-ringstyper

B12 Som skole skal jeg kunne booke et lokale i et tids-rum

B13 Som skole skal jeg kunne få et overblik over lokale- og bygningsbelægning for en given periode

B14 Som skole kan jeg oprette/redigere etager i mine bygninger

B15 Som skole skal jeg kunne markere en vedligehol-delseaktivitet som værende udskudt eller udført

RP1 Som skole skal man kunne oprette nye lokale ud-træksskabeloner i systemet.

RP2 Som systemadministrator skal man kunne oprette centrale udtræksskabeloner.

RP3 Som skole skal man kunne benytte en udtræksska-belon til at få et udtræk som er periodeafgrænset.

RP4

Som skole skal man kunne benytte en udtræksska-belon og bestemme, om man vil have resultatet i Excel eller se det i systemet.

RP6

Som skole ansat skal det være muligt at have "mine udtræk" som værende de favorit udtræk man har.

RP7 Som skole skal man kunne oprette nye lokale rap-portskabeloner i systemet.

RP8 Som systemadministrator skal man kunne oprette centrale rapportskabeloner.


RP9

Som skole kan jeg få en oversigt over fordelt løn, brudt ned på aktiviteter og medarbejdere (ansvar og formål og andre dimensioner)

RP10

Som skole kan jeg få en oversigt over realiserede årselever med CØSA nummer, ansvar og andre di-mensioner, inkl. andre rekvirenter så som jobcen-ter

RP11 Som skole kan jeg få et forecast for indberettede årselever, både realiseret og forventet

RP12 Som skole kan jeg se en oversigt over tilmeldin-ger/optag

RP13

Som skole skal man kunne lave et fag og timeud-træk i forhold til lokale uddannelsesplaner, som vi-ser, at der er timer, eleven ikke har fået, da ved-kommende er startet senere.

RP14 Som skole skal jeg kunne se en oversigt over fra-vær pr. elev/hold/uddannelse/klasse

RP15 Som skole skal jeg kunne se en oversigt over elever pr. klasse

RP16 Som skole skal jeg kunne se en oversigt over med-arbejderes restferie m.m.

RP17 Som skole skal jeg kunne se en oversigt over med-arbejderes sygefravær

RP18 Som skole skal jeg kunne se en oversigt over be-lægning af de enkelte lokaler.

RP19 Som skole skal jeg kunne se en oversigt over ele-vernes karakterer/prøveresultater

RP20 Som skole skal jeg kunne se en oversigt over ele-vernes eksamener pr. elev, lærer, censor og lokale.

RP21 Som skole skal jeg kunne se en oversigt over med-arbejdernes kompetencer.

SKEMA14

Som elev eller skole skal man kunne se skemaet med udgangspunkt i eleven, en underviser, et hold m.m.

System

TV32

Som system skal jeg gemme brugervenlig historik med begivenheder og hvilken bruger der har ud-ført handlingen der medførte begivenheden.


TV39

Som system skal jeg kunne omsætte udenlandske karakterer samt beregne gennemsnit med væg-tede karakterer.

L8

Som system skal jeg kunne få en advarsel hvis en elev får/har ønsket et valgfag på et niveau hvor eleven allerede har en bestået prøve på et andet niveau.Ligeledes skal der være en advarsel ved øn-ske om meritfag og hvis eleven ønsker samme fag flere gange.

L15

Som system skal jeg kunne koble skemabrikker med læringsrummet og evt. tilhørende lektions-plan

L24

Som system tilbyder jeg en app til eleverne og un-derviserne således at alle deres behov fra lærings-området kan opfyldes via denne

L33 Som system skal jeg kunne integrere til systemer som kan udføre plagiatkontrol

L38

Som system tilbyder jeg en snitflade således at evalueringer kan udføres i andre systemer men af-leveres til dette

L39

Som system opretter jeg automatisk et dialogfo-rum til et læringsrum hvor alle parter kan skrive og læse i

L45 Som system skal man kunne afsende besked om godkendte og afviste valg af ønsker om fag.

L47 Som system tilbyder jeg en snitflade således at alt data relateret til læring kan kan hentes i systemet

L48

Som system tilbyder jeg en snitflade således at data relateret til læring kan afleveres til systemet fra et 3.parts system

G4

Som system tilbyder jeg alle udbud, således at an-dre systemer kan trække information om hvornår der er elevforløb.

T1

Som system modtager eller henter jeg vurdering af grundskoleelevers uddannelsesparathed fra Opta-gelse.dk.

T2 Som system overfører jeg mine udbud til Opta-gelse.dk.

T3 Efter eleven har ansøgt på Optagelse.dk modtager jeg som system ansøgningen i en indbakke

T7

Som system modtager eller henter jeg uddannel-sesaftaler fra Easy-P og får derved tilmeldt eleven. Tilmeldelsen skal havne i en indbakke.


T8

Som elev skal man kunne ansøge i brobygning.net og få ansøgningen overført til systemet i en ind-bakke.

T10

Som kursist skal jeg kunne ansøge i efteruddan-nelse.dk om optag på AMU kursus og få ansøgnin-gen overført til systemet i en indbakke.

T12

Som system tilbyder jeg AMU udbud, således at andre systemer kan trække på disse, f.eks. Efterud-dannelse.dk

T13 Som system tilbyder jeg en snitflade, således at an-søgninger fra andre systemer havner i en indbakke.

T17

Som system laver jeg en opkrævning og en udlig-ning i navision stat hvis jeg modtager en ansøgning hvor der er betalt

T18

Som system overfører jeg alle dokumenter samt ansøgning om optagelse af elever fra Optagelse.dk og efteruddannelse.dk til elevens filarkiv

O1

Som system afviser jeg en ansøger til GF1, hvis vedkomne tidligere har søgt GF1 (uanset skole) og ikke frameldt før startdato

O2

Som system modtager jeg løbende ændringer om karakterer, hvilket ændrer status på eleven i ind-bakken.

O4

Som system tilbyder jeg en snitflade, således at an-dre systemer kan aflevere niveau og prøveresulta-ter til systemet.

O6 Som system afviser jeg en ansøger til GF2, hvis ele-ven allerede har brugt 3 forsøg.

O8 Som system sender jeg alle optagede elever til det fælles datagrundlag.

O19

Som system sender jeg oplysninger om en elev til EMU.dk ved optagelse og modtager et UNI-login retur.

O31 Som system skal man kunne overføre elevstatus ændringer til Easy-P.

SK4

Som system markerer jeg automatisk en ansøg-ning, efter at den er endt i indbakken, hvis der er mere end 5 kvarter mellem skole og hjem.

SK22

Som system tilbyder jeg en snitflade, således at hele bookingen og værelses håndteringen kan fo-retages i et andet system og nøjes med at levere resultatet.


S10 Som system tilbyder jeg en snitflade, som andre sy-stemer kan benytte til fraværsregistrering.

S11 Som system skal jeg kunne identificere frafaldstru-ede elever og se dem i en særlig indbakke.

S18 Som system tilbyder jeg en snitflade, således at målepinde status kan afleveres fra andre systemer.

S19

Som system skal jeg kunne informere relevante personer ved manglende udfyldelse af målepinde og karakterer.

S21 Som system sender jeg karakterdata til det fælles datagrundlag.

S23

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente uddannelsesforløb samt deres status.

S24 Som system overfører jeg hold og kursister til vis-kvalitet.dk, således at de kan logge ind der.

S25 Som system skal man kunne overføre alt relevant data til det fælles datagrundlag.

S28

Som system overfører jeg automatisk oplysninger om eleven til US2000 efter optagelsen er foreta-get.

S33 Som system ajourfører jeg US2000, når elevers sta-tus ændrer sig.

S35 Som system ajourfører jeg AUB, når elevers status ændrer sig.

S41 Som system skal jeg tilbyde data om elever, såle-des at andre systemer kan gøre brug af dette

S46 Som system skal jeg kunne levere data til indberet-ning af 28-klasseloftet

SKEMA13

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente data til skemaplanlægning og aflevere resultat af skemaplanlægning tilbage til systemet som skemabrikker.

SKEMA16

Som system tilbyder jeg en snitflade, således at skemabrikker kan sendes til og modtages fra andre systemer.

SKEMA17

Som system tilbyder jeg en snitflade, således jeg kan aflevere skemabrikker samt andre aftaler til Exchange (Outlook).

P6

Som system skal jeg kunne foreslå den mest opti-male rute for kundebesøg ud fra en liste af virk-somheder


P7 Som system kan jeg oprette aktiviteter i outlook

P13

Som system skal jeg kunne foreslå den mest opti-male rute for kundebesøg ud fra en liste af virk-somheder


GS5 Som system skal jeg kunne modtage tildelt bevil-ling for en elev på baggrund af en SPS-screeningen

RP5

Som system tillader jeg, at min udtræksskabelon kan bruges som datakilde fra Excel, og derved be-høver jeg ikke åbne systemet for at få data opdate-ret.

IND1 AER indberetning

IND2 Afsendelse af kommunebreve

IND3 Censorindberetning

IND4 Eksamensindberetning

IND5 Elever til prøve

IND6 Elevindberetning

IND7 Indberetning af kursisthistorik

IND8 Indberetning af prøveplan

IND9 Indberetning Danmarks Statistik AMU

IND10 Indberetning til Danmarks Statistik, Alm.

IND11 Indberetning til Danmarks Statistik, ÅU

IND12 Indberetning til www.efteruddannelse.dk

IND13 Indberetning årselever AMU

IND14 Indberetning Årselever Skolepraktik

IND15 Indberetning Årselevsbidrag fuldtid

IND16 Indberetning årselevsbidrag Åbenudd.

IND17 Kvalifikationsindberetning

IND18 Realiseret prøveplan mundtlig

IND19 Realiseret prøveplan skriftlig

IND20 Skolehjemsårselevs indberetning

IND21 Tilskudsindberetning AMU

IND22 Tilskudsindberetning AMU - lånte godkendelser

IND23 Tilskudsindberetning, ÅU

IND24 XPRS-censorkompetencer

IND25 XPRS-lærefriholdelse


IND26 AUB skolehjem

IND27 28-klasseloftet


Bilag 4: Integrationer og behov

Dette afsnit er tiltænkt den læser, som ønsker at kunne få et overblik over hvilke behov som er knyttet

til bestemte integrationer og er en opsamling på de behov, som er beskrevet i behovsmatrixen. Der fin-

des ikke information i dette afsnit, som ikke også findes i behovsmatrixen, afsnitte tjener alene det for-

mål at give læseren en oversigt med udgangspunkt i de behandlede integrationer.

I arbejdet med at identificere behov til nyt studiesystem har vi identificeret flg. integrationsbehov:

Uvm/webservice

Tilbagemelding.dk

E-boks

Mail

Navision stat

Exchange

XPRS

Mobil app

netprøver.dk

easy-p

mobil app

plagiatkontrol system

optagelse.dk

Nemlogin

brobygning.net

efteruddannelse.dk

skolens hjemmeside

rkv-værktøj fra stil

emu.dk

US2000

Kuu-portalen

rejseplan.dk

cøsa

viskablitet.dk

aub/aer

skemaplanlægning

ungedatabasen

sls

silkeborg løn


excel

uu

danmarks statistik

ny uvm-praktikportal (elevplan + easy-p)

Herunder er er der forsøgt at give et overblik over hvilke behov der er forbundet med de enkelte inte-

grationer.

UVM/webservice

I arbejdet med behovsafdækningen af et nyt studiesystem, er der blevet defineret en række forudsæt-

ninger (beskrevet som behov) som skal løftes fra centralt sted. Mange af forudsætningerne kan ikke

opfyldes via eksisterende systemer eller integrationer og skal derfor indgå som en del af et fremtidigt

projekt.

Følgende behov er disse forudsætninger.

TV1 Som UVM skal man kunne oprette og vedligeholde institutionsregister.

TV2 Som skole skal man kunne oprette en afdeling på kladdeniveau, som UVM skal godkende.

TV3 Som UVM skal man kunne oprette og vedligeholde uddannelser med CØSA numre.

TV4 Som UVM skal man kunne oprette og vedligeholde links til bekendtgørelser.

TV5 Som UVM skal man kunne oprette og vedligeholde UVM fag.

TV6

Som UVM skal man kunne oprette og vedligeholde centrale uddannelsesmodeller for de enkelte be-kendtgørelser.

TV7 Som UVM skal man kunne oprette og vedligeholde takstkatalog.

TV8 Som UVM skal man kunne oprette og vedligeholde målepinde på UVM fag.

TV9

Som UVM skal man kunne oprette og vedligeholde karakterskala samt definere de prøvetyper der kan være på et UVM fag.

TV10 Som UVM skal man kunne oprette og vedligeholde AMU kurser med FKB numre.

TV11

Som skole skal man kunne oprette en kladde for udbudssteder knyttet til de enkelte uddannelser, som UVM skal godkende.

TV15

Som UVM skal man kunne oprette og vedligeholde de karakter/godkendelsesmodeller, som skal kunne bruges i systemet.


TV19

Som UVM skal man kunne oprette og vedligeholde de indgange der måtte være til GF1, f.eks. de 4 der findes i dag.

TV29 Som UVM skal jeg kunne oprette og vedligeholde centrale frafaldsårsager.

TV33

Som UVM skal jeg oprette/vedligeholde hvilke UVM fag som er prøvefag på de enkelte uddannel-ser

E31 Som skole kan jeg sende eksamensbeviser til eksa-mensdatabasen

E39 Som skole skal jeg kunne danne eksamensbevi-ser/prøvebeviser fra tidligere uddannelsesmodeller

O1

Som system afviser jeg en ansøger til GF1, hvis vedkomne tidligere har søgt GF1 (uanset skole) og ikke frameldt før startdato

O8 Som system sender jeg alle optagede elever til det fælles datagrundlag.

O27

Som skole skal man kunne overføre en elev til en anden skole, hvilket betyder, at der oprettes en kopi af eleven og dennes data. Ved overførsel mel-lem flere forskellige studiesystemer, skal dette håndteres via det fælles datagrundlag.

O28 Som skole skal jeg i en indbakke kunne modtage en overført elev fra en anden skole.

S1

Som skole skal man kunne oprette en aktivitetsind-beretningskladde (med beregningsgrundlag) med kontrolliste over, om eleverne/kursisterne er kor-rekt registreret, og/eller om regler er overtrådt.

S7

Som skole skal man kunne sende en fakturerings-grundlagskladde eller aktivitetsindberetnings-kladde til STILs beregningsmotor og få et resultat retur.

S21 Som system sender jeg karakterdata til det fælles datagrundlag.

S25 Som system skal man kunne overføre alt relevant data til det fælles datagrundlag.

S29

Som skole skal man kunne oprette en varigheds-uafhængig tilskudsindberetningskladde (med be-regningsgrundlag) med kontrolliste over, om ele-verne er korrekt registreret og/eller om regler er overtrådt.


Ø1

Som skole kan jeg på samtlige indberetninger ar-bejde med forecasts således at man løbende kan få et økonomisk overblik

IND3 Censorindberetning

IND4 Eksamensindberetning

IND13 Indberetning årselever AMU

IND14 Indberetning Årselever Skolepraktik

IND15 Indberetning Årselevsbidrag fuldtid

IND16 Indberetning årselevsbidrag Åbenudd.

IND20 Skolehjemsårselevs indberetning

IND21 Tilskudsindberetning AMU

IND22 Tilskudsindberetning AMU - lånte godkendelser

IND23 Tilskudsindberetning, ÅU

Tilbagemelding.dk

TV22 Som skole skal man kunne danne et kommune-brev, som sendes til tilbagemelding.dk.

Ny uvm-praktikportal (elevplan + easy-p)


E-boks

TV23



E32 Som skole kan jeg sende eksamensbeviser til ele-vens e-Boks og gensende

E40 Som skole skal jeg kunne genudskrive/ genfrem-sende eksamensbeviser til elever


O3

Som skole skal man kunne afklare, om en elev kan optages direkte på udannelsen (GF1, GF2, EUX, EUV og gymnasiale uddannelser) på baggrund af karakterer. Hvis dette er muligt, skal eleven sendes


til en ny indbakke, ellers skal der tilbydes prøver og samtale. Der gennemføres optagelsesprøver og ud-stedes prøvebeviser på samme måde som ved øv-rige prøver.

O18



O33

Som skole modtager jeg en liste med navn og cpr nummer fra en virksomhed og opretter disse kursi-ster og holdplacerer dem

O38 Som skole skal jeg kunne lave og sende RKV bevis til eleven

S12

Som skole skal jeg på en uddannelse kunne op-sætte, om der skal sendes e-mail, sms eller brev ved fravær.

Mail

TV23


O18




Sms

TV23


O18





Navision stat

TV24 Som skole skal man kunne oprette og redigere ge-byrtyper til brug ved opkrævning.

TV25 Som skole skal man kunne lave en opkrævning og sende den til Navision stat.

TV26 Som skole skal man kunne lave en kreditnota og sende den til Navision stat.

T17

Som system laver jeg en opkrævning og en udlig-ning i navision stat hvis jeg modtager en ansøgning hvor der er betalt

T18

Som system overfører jeg alle dokumenter samt ansøgning om optagelse af elever fra Optagelse.dk og efteruddannelse.dk til elevens filarkiv

O12 Som skole skal man kunne se, om betaler af kurset skylder i forvejen.

O13 Som skole skal man kunne se, om eleven skylder i forvejen.

O34 Som skole skal man kunne opkræve deltagerbeta-ling for elever og kursister

SK16

Som skolehjemsadministration skal man kunne danne opkrævninger og sende dem til Navision stat.

SK17 Som skolehjemsadministration skal man kunne se, om en regning er blevet betalt.

SK18 Som skolehjemsadministration skal man kunne lave en kreditnota.

SK21 Som skolehjemsadministration skal man kunne lave en opkrævning af tillægsydelser.

S6 Som skole skal man kunne sende en godkendt fak-tureringsgrundlagskladde til Navision.

Ø7 Som skole kan jeg danne en kladde af en lønforde-lingskørsel og sende den navision stat

Ø9 Som skole kan jeg sende indberetningsresultater samt indberetningskladder til Navison Stat


Exchange

TV28

Som skole skal man kunne oprette fælles/individu-elle aftaler og aktiviteter til elever og medarbej-dere.

SKEMA17

Som system tilbyder jeg en snitflade, således jeg kan aflevere skemabrikker samt andre aftaler til Exchange (Outlook).

SKEMA28 Som underviser skal jeg kunne se min egen opga-veoversigt


XPRS

E2 Som skole indeberetter jeg censorpulje/censor kompetencer

E3 Som skole kan jeg oprette/redigere lærerfrihol-delse og sende disse til XPRS

E4 Som skole kan jeg i min indbakke se udtrukne eksa-mensfag fra XPRS

E5

Som skole henter jeg udtræk af prøvefag fra XPRS samt censorfag for flerfaglige prøver som ender i en indbakke

E6

Som skole skal jeg kunne danne et udtræk til ele-ven af de fag, som eleven skal til eksamen i på bag-grund af Undervisningsministeriets udtræk

E9 Som skole indsender jeg min prøveplan til XPRS så-ledes at der kan påsættes censorer

E10

Som skole indsender jeg prøveplaner for studieret-ningsprojekt (SRP) og større skriftelige opgaver (SSO) til XPRS således at der kan påsættes censorer

E11 Som skole henter jeg udtræk af censortildeling fra XPRS på egne og eksterne undervisere.

E12

Som skole skal jeg kunne hent et udtræk af censor-planer med følgende oversigt: - Hvilke af egne undervisere skal være censor på andre skoler - Hvilke eksterne censorer er knyttet til skolens ek-samensfag

E14 Som skole skal jeg kunne bede om en erstatnings-censor

E18 Som skole overfører jeg realiserede prøveplaner for skriftlige og mundtlige prøver til XPRS

IND5 Elever til prøve


IND8 Indberetning af prøveplan

IND18 Realiseret prøveplan mundtlig

IND19 Realiseret prøveplan skriftlig

IND24 XPRS-censorkompetencer

IND25 XPRS-lærefriholdelse

netprøver.dk

E26 Som skole kan jeg hente karakterer og evt. opgaver fra netprøver.dk

easy-p


E37

Som skole skal jeg efter afsluttet GF2/EUV kunne stille færdiggjorte elever til rådighed for EASY-P via integration

T7

Som system modtager eller henter jeg uddannel-sesaftaler fra Easy-P og får derved tilmeldt eleven. Tilmeldelsen skal havne i en indbakke.

O31 Som system skal man kunne overføre elevstatus ændringer til Easy-P.

P1



IND6 Elevindberetning

IND17 Kvalifikationsindberetning

mobil app

L24

Som system tilbyder jeg en app til eleverne og un-derviserne således at alle deres behov fra lærings-området kan opfyldes via denne

plagiatkontrol system

L33 Som system skal jeg kunne integrere til systemer som kan udføre plagiatkontrol


api/snitflade

L38

Som system tilbyder jeg en snitflade således at evalueringer kan udføres i andre systemer men af-leveres til dette

L47 Som system tilbyder jeg en snitflade således at alt data relateret til læring kan kan hentes i systemet

L48

Som system tilbyder jeg en snitflade således at data relateret til læring kan afleveres til systemet fra et 3.parts system

G4

Som system tilbyder jeg alle udbud, således at an-dre systemer kan trække information om hvornår der er elevforløb.

T12

Som system tilbyder jeg AMU udbud, således at andre systemer kan trække på disse, f.eks. Efterud-dannelse.dk


O4

Som system tilbyder jeg en snitflade, således at an-dre systemer kan aflevere niveau og prøveresulta-ter til systemet.

SK22

Som system tilbyder jeg en snitflade, således at hele bookingen og værelses håndteringen kan fo-retages i et andet system og nøjes med at levere resultatet.

S10 Som system tilbyder jeg en snitflade, som andre sy-stemer kan benytte til fraværsregistrering.

S18 Som system tilbyder jeg en snitflade, således at målepinde status kan afleveres fra andre systemer.

S23

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente uddannelsesforløb samt deres status.

S41 Som system skal jeg tilbyde data om elever, såle-des at andre systemer kan gøre brug af dette

SKEMA13

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente data til skemaplanlægning og aflevere resultat af skemaplanlægning tilbage til systemet som skemabrikker.

SKEMA16

Som system tilbyder jeg en snitflade, således at skemabrikker kan sendes til og modtages fra andre systemer.

HR8 Som system skal jeg tilbyde data om personale, så-ledes at andre systemer kan gøre brug af disse.


HR12

Som system tilbyder jeg snitflade til andre syste-mer, der indeholder oplysninger om underviseres planlagte fravær så som ferie, kurser, barsel, syg-dom m.v.

HR13

Som system tilbyder jeg snitflade til andre syste-mer, der registrerer sygdomsfravær og ferie (f.eks. SLS-FRAV)

HR18

Som system tilbyder jeg en snitflade, således at an-dre systemer kan hente data til tidsregisteringen og aflevere data tilbage til systemet som registre-ret tid

HR19

Som system tilbyder jeg en snitflade således at re-gistreret tid kan sendes til og modtages fra andre systemer

optagelse.dk

TV16 Som skole skal man kunne oprette og vedligeholde skolekalendere med fridage, helligdage og ferie.

T1

Som system modtager eller henter jeg vurdering af grundskoleelevers uddannelsesparathed fra Opta-gelse.dk.

T2 Som system overfører jeg mine udbud til Opta-gelse.dk.

T3 Efter eleven har ansøgt på Optagelse.dk modtager jeg som system ansøgningen i en indbakke


O2

Som system modtager jeg løbende ændringer om karakterer, hvilket ændrer status på eleven i ind-bakken.

Nemlogin

T6

Som elev på GF1 skal jeg i systemet kunne vælge en uddannelse på GF2. Ansøgningen skal havne i en indbakke

SK11

Som elev eller kursist skal man kunne logge ind og markere, hvorvidt man ønsker skolehjem i sin sko-leperiode.


brobygning.net

T8

Som elev skal man kunne ansøge i brobygning.net og få ansøgningen overført til systemet i en ind-bakke.

T9 Som skole skal man kunne sende en ansøgning til-bage til brobygning.net.

efteruddannelse.dk

T10

Som kursist skal jeg kunne ansøge i efteruddan-nelse.dk om optag på AMU kursus og få ansøgnin-gen overført til systemet i en indbakke.

T11 Som skole skal man kunne sende en ansøgning til-bage til efteruddannelse.dk.

IND7 Indberetning af kursisthistorik

IND12 Indberetning til www.efteruddannelse.dk

CRM


P1


P8

Som skole kan jeg benytte et CRM lignende system i det nye system til at oprette og vedligeholde akti-viteter på virksomheder

Skolens hjemmeside


RKV-værktøj fra stil

O7 Som skole skal man kunne afklare, om en elev kan optages direkte på GF2 på baggrund af karakterer.

http://www.efteruddannelse.dk/


emu.dk

O19

Som system sender jeg oplysninger om en elev til EMU.dk ved optagelse og modtager et UNI-login retur.

US2000

O30 Som skole skal man kunne sætte et elevforløb (og dermed en elev) på orlov.

S28

Som system overfører jeg automatisk oplysninger om eleven til US2000 efter optagelsen er foreta-get.

S33 Som system ajourfører jeg US2000, når elevers sta-tus ændrer sig.

GS5 Som system skal jeg kunne modtage tildelt bevil-ling for en elev på baggrund af en SPS-screeningen

GS6

Som skole skal jeg kunne indberette afholdte om-kostninger(timer, indkøb af udstyr mm.) til UVM og modtage refusion.

Kuu-portalen



rejseplan.dk

SK4

Som system markerer jeg automatisk en ansøg-ning, efter at den er endt i indbakken, hvis der er mere end 5 kvarter mellem skole og hjem.

SK5

Som skole skal man kunne opsætte på en uddan-nelse, hvorvidt der skal laves automatiske rejse-plans opslag.

S26

Som skole skal man kunne se i sin AUB indbakke, hvem der skal kigges på i forhold til transportrefu-sion samt beregne transportrefusion for disse sko-leforløb.


cøsa

S2 Som skole skal man kunne lave en eksport af aktivi-tetsindberetningskladden til CØSA systemet.

S30 Som skole skal man kunne lave en eksport af varig-hedsuafhængig tilskud til CØSA systemet.

viskablitet.dk

S24 Som system overfører jeg hold og kursister til vis-kvalitet.dk, således at de kan logge ind der.

aub/aer

S27

Som skole skal man kunne sende indberetning til AUB med antal skoledage samt evt. transportudgif-ter, der skal refunderes.

S35 Som system ajourfører jeg AUB, når elevers status ændrer sig.

IND1 AER indberetning

IND26 AUB skolehjem

skemaplanlægning

HR16 Som skole skal jeg kunne opsætte forskellige ka-tegorier til at registrere medarbejdernes tid til fx undervisning, ferie og kompetenceudvikling.

HR17 Som skole skal jeg kunne registrere medarbej-dernes tid på forskellige kategorier.

ungedatabasen

GS1 Som skole sender jeg data vedr. elever og deres uddannelse og beskæftigelse til ungedatabasen.

sls

HR3





silkeborg løn

HR3




excel


uu



IND2 Afsendelse af kommunebreve

danmarks statistik

IND9 Indberetning Danmarks Statistik AMU

IND10 Indberetning til Danmarks Statistik, Alm.

IND11 Indberetning til Danmarks Statistik, ÅU


Bilag 5: Roller i systemet

Nr Rolle/brugergruppe Adgang kigge Adgang redigere

1 Ekstern: Arbejdsgivere

2 Ekstern: Elever

3 Ekstern: Leverandør

4 Ekstern: Revisor

5 Underviser

6 Studiesekretær

7 Systemadministrator

8 Superbruger

9 Eksamensplanlægger

10 Skemalægger

11 Administrativ leder

12 Pædagogisk leder

13 Praktikkonsulenter

14 Revisor

15 Økonomimedarbejder

16 Lønmedarbejder

17 It-medarbejder

18 Receptionist

19 Pedel

20 Opkrævere

21 Skolehjem

22 HR-medarbejder

23 Praktikadministrative medarbejdere

Tabel 1 - kilde projektgruppen


Bilag 6: Metodebilag

Begrebet User Story

I softwareudvikling og produkthåndtering, er en user story4 en beskrivelse, der består af en eller flere

sætninger i det dagligdags- eller forretningssprog som slutbrugeren anvender, der beskriver hvad en

bruger gør eller har brug for at gøre som en del af hans eller hendes jobfunktion. User stories bruges i

agile softwareudvikling som grundlag for at definere funktionaliteten for et forretningssystem og for

at lette kravstyring.5

Opbygningen af en user story beskriver hvem brugeren er, hvad brugeren gerne vil opnå og hvad der

motivere vedkomne. Derudover kan der til hver User Story være tilknyttet en række noter, som kan

uddybe User Story’en med fx tekniske krav, begrænsninger og forudsætninger. User stories skrives

typisk i formatet

”Som en ___, vil jeg gerne ___, for at ___.”

Eller

”Som en ___, kan jeg ___, for at ___.”

For eksempel

” Som [skole] skal man kunne afklare, om en elev kan optages direkte på uddannelsen (GF1, GF2, EUX,

EUV og gymnasiale uddannelser) på baggrund af karakterer.”

Det er blevet fravalgt at medtage motivationselementet af user stories i forprojektet da dette punkt

typisk vil være indlysende i denne slags fagsystemer.

4 User stories opstod med Extreme Programming (XP) 5 Kilde: http://en.wikipedia.org/wiki/User_story

Documents

Forprojekt nyt studiesystem Behovsanalyse af et nyt ......(LMS). Opgaven omfatter også udarbejdelsen af et økonomisk overslag over de forventede udgifter ved udvik-lingen af de respektive