Forprojekt nyt studiesystem. Behovsanalyse af et nyt studiesystem

Transkript

1 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 2016

2 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 Funktionelle krav Brugervenligheds krav Tekniske krav Begrebsmodel Modulisering af behov Bilag Bilag 1: Ordforklaring Bilag 2: Vision Bilag 3: Aktører og behov Bilag 4: Integrationer og behov Bilag 5: Roller i systemet Bilag 6: Metodebilag... 82

3 Side 3 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Opgave og proces Den stillede opgave Erhvervsskolerne har siden midten af 1990 erne anvendt Undervisningsministeriets studieadministrative 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 fremtidige 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 mulighed for integration til andre systemer. Opgaven, som ønskes løst i forprojektet, er udarbejdelse af en behovsafdækning på et overordnet niveau, 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 erhvervsskolers udbud af opgaven med at udvikle et nyt studiesystem eller som checkliste ved anskaffelse 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 studiesystem, 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 udviklingen 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 kravspecifikation_ pdf som er vedlagt. Forudsætninger Projektgruppen har i sit arbejde taget udgangspunkt i, at et/flere studiesystemer som minimum effektivt 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. Behovsafdæ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. Antagelserne 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.

4 Side 4 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Vision Projektgruppens arbejde tog udgangspunkt i nedenstående vision, som er resultatet af gruppens arbejde 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 opgaver.

5 Side 5 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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. wireframes eller data model som en del af projektet. Projektet er udført i et tæt samarbejde med Danske Erhvervsskoler og Danske SOSU-skolers projektgruppe, suppleret af relevante brugere, primært studieadministrative medarbejder, med et dybt kendskab 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 resulteret 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 projektgruppen 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 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 og 20. oktober Workshop 3 og 4, fokus på studieadministrationen. Iteration og 11. november Workshop 5 og 6, fokus på områderne studieadministration, praktikadministration og eksamen. Iteration november og 1. december Workshop 7 og 8, fokus på områderne Økonomi og HR, Bygningsdrift og services, gennemførelsesvejledning / støtte og kommunikation. Iteration 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

6 Side 6 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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.. Opstartsmøde og første workshop 6 iterationer (forstå, analyse og konkretisering) Overlevering 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 afklaringsproces 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 afklaringsseminarer. 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.

7 Side 7 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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), tilpasning 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 projektgruppen sammen med STIL i foråret 2015 identificerede, jf. bilag Ekstern_Bilag 1_Procesbeskrivelse_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 studierettede processer. Hver iteration af afdækningen har behandlet en række udvalgte processen, hvilke kan ses på oversigten 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

8 Side 8 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 Mapping 1, 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: Eksempelvis opsamling på brainstorms, user stories mm. F.eks. Behovsmatrix og rapport.

9 Side 9 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 abstraktionsniveau, 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! Reference 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 studieadministrative 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 opgaver/områder: Udbudsgodkendelse Grovplanlægning Tilmelding Optagelse Elevtilknytninger Skemalægning

10 Side 10 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 behandling 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 afklare optagelsen, udføre RKV, placere elever fra indbakke på et elevforløb, modtage og oprette kursister 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 skemaplanlægningsmodul skal indeholde af forskellige regler. F.eks. at kunne tage højde for de maksimale

11 Side 11 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 underkategorier: 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 planlægge og afholde eksaminer og prøver, indkalde til censorkorps samt opsætte, producere og distribuere eksamens- og prøvebeviser. Gennemførelsesvejledningsstøtte (6 behov) Afsnittet gennemførelsesvejledningsstøtte indeholder i alt 6 behov fordelt på følgende underkategorier: 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)

12 Side 12 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 herunder 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 studieadministrative nære behov, som ikke antages fortsat at skulle løftes af EASY-P i forbindelse med et nyt studiesystem. 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.

13 Side 13 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Ø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å samtlige 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. administration 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 ovenfornævnte kategorier f.eks. udtræksskabeloner til statistik. Afsnittet indeholder også behov som omhandler 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 indberetninger. 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 opgaver. 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 medarbejdere. Det er derfor essentielt, at en fremtidig udviklings- eller købsproces har et højt fokus på at sammensætte behovene til sammenhængende og meningsfyldte arbejdsgange for de forskellige brugerroller, der er repræsenteret i systemet.

14 Side 14 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 behovsafdæ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 kategorier 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 studieadministrationen er nogle af de helt centrale for at lykkes med et mere sammenhængende og effektivt studiesystem. Figur 4 - Kronologisk tidslinje for studieadministration

15 Side 15 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 visninger og arbejdsgange. Specielt arbejdsgangene for det studieadministrative personale har dette behov. Disse visninger i brugergrænsefladen er en nødvendighed, både i forhold til fremsøgning at informationer 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 studiesystemet, at arbejde specifikt med grafiske overbliksskabende visninger samt hvilke enheder (smartphone, tablet, mfl.), disse områder og arbejdsgange vil skulle vises på.

16 Side 16 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 giver 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 overbliksvisninger, f.eks. fravær for alle elever på et hold. Samtidigt er der behov for et meget specifikt arbejdsbillede for undervisere, i forbindelse med fraværsregistrering af de enkelte elever. Et arbejdsbillede, som skal være skåret helt skarpt i forhold til denne ene, specifikke opgave og som skal kunne foregå 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 fremtidigt studiesystem bør have et stort fokus på at arbejde med disse behov eksplicit i forhold til brugergrænsefladen. Projektgruppen har identificeret følgende behov, som skal have et særligt fokus: 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- Nr. Behov Behovsuddybning E8 Som skole kan jeg danne mig et overblik over resultatet af eksamensplanlægningen og ændre i dette. somhedspunkter. E21 Som skole kan jeg benytte en eksamensplanlægningsmotor, som fortæller hvilke dage, der skal være prøver i hvilke fag. Eksamensplanlægningsmotoren giver mig en grafisk 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 forskellige 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 visning over belægningen af de enkelte uddannelser (udbud). Man skal kunne indsætte elevforløb direkte i kalenderen samt trække dem rundt, såkaldt "drag and drop".

17 Side 17 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem O14 S17 Som skole skal man fra indbakken kunne placere elever på et elevforløb og dermed på et eller flere skoleforløb. 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. Elevforløbet bliver oprettet som en del af grovplanlægningen/udbudsplanlægningen med tilhørende skoleforløb og/eller praktikforløb. Disse forløb bliver datosat og oprettet 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 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 komplekse 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 metoder Validering på feltniveau Alle felter skal give sigende og øjeblikkelige tilbagemeldinger ved indtastning af forkerte værdier. 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 forretningsregler. 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 skrevet 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 samtidigt skal stille al nødvendig information til rådighed for brugeren, da der ofte er behov for at vise

18 Side 18 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 arbejdsgang, 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 adskille 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 konsistente 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 informationen 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ødekommende 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 erfaringer og behov kan integreres ind i den fungerende prototype måske endog samme dag, som de opstår.

19 Side 19 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 definerede 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.

20 Side 20 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Brugervenligheds krav Det er et overordnet krav og ønske om, at brugergrænsefladen skal være brugervenlig, for alle brugere. 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 arkiv 3 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 herfra 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.

21 Side 21 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 systemet 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 stylesheets (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 medarbejderen 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. Brugerne skal kunne se forskel på miljøer (produk- Brugervenlighedskrav 12 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ærmbilleder å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).

22 Side 22 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 forretningsproces. 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 omfang 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 systemkomponenter 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.

23 Side 23 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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.

24 Side 24 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 versioner 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ærmens 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.

25 Side 25 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 personoplysninger, 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 Internettet. Loven indeholder en række regler om, hvornår man må indsamle, registrere og videregive personoplysninger 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 regler 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 journalnummer i den offentlige sektor. Som udgangspunkt skal enhver behandling af personoplysninger, der foretages for en offentlig Myndighed, anmeldes til Datatilsynet. Der gøres opmærksom på, at Myndighederne skal foretage anmeldelse til Datatilsynet, og at Leverandøren skal medvirke til denne anmeldelse. På tilsvarende vis skal bestemmelserne i sikkerhedsbekendtgørelsen overholdes jf. bek 528 af 15. juni Systemet skal understøtte, at alle brugere af det nye studiesystem kan behandle personoplysninger i overensstemmelse med persondataloven og sikkerhedsbekendtgørelsen. Datatilsynets praksis omkring 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 oplysninger ikke kommer til uvedkommendes kendskab, misbruges eller i øvrigt behandles i strid med persondataloven. Sikkerhed krav 2 Adgang til systemet gennem WAYF Single-sign on eller almindelig logon Systemet skal kunne understøtte single sign-on gennem Kundens browsere. Dette skal understøttes ved hjælp af WAYF ( 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

26 Side 26 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem enkelte skole om brugerne for en pågældende skole får adgang til systemet via single sign on eller gennem 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 muligt 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 indeholder 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 Alle s, som sendes fra systemet, skal kunne sendes som sikker . 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 sikringsforanstaltningerne 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. Systemet 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ættes, og hvordan denne på en sikker måde kan tilgås af systemadministrator. Typiske aktiviteter inkluderer:

27 Side 27 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Logning, til brug for overvågning af datatilgang, funktionsadskillelse, svartidsbidrag, fejlhå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 transaktioner 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ølgende: 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.

28 Side 28 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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, genetablering 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 profiler/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 foretages 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æseadgang direkte til datalageret. Andre krav 14 Snitflade til forretningsobjekter Systemet skal tilbyde(læse og skrive) alle centrale forretningsobjekter gennem veldefinerede snitflader. 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.

29 Side 29 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 enkelte 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ødvendige 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 kommunikationen 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 brugerroller og tildele og differentiere rettigheder for de nævnte brugerroller.

30 Side 30 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Andre krav 30 Kundens mulighed for kode review Leverandøren skal på Kundens opfordring give mulighed for at Kunden, eller en uvildig part på Kundens 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.

31 Side 31 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 udgangspunkt 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 datamodel. Begrebsmodel krav 2 Dokumentation af logisk datamodel Leverandøren skal dokumentere Løsningens logiske datamodel ved brug af UML notationen eller tilsvarende standardiseret, anerkendt metode. Begrebsmodel krav 3 Detaljeringsgrad af datamodeldokumentation Tilbudsgiver skal, inden en accepteret overtagelsesprøve eller ved ophør af formelt samarbejde, detaljere dokumentationen for datamodellen, med overordnede beskrivelser af fag- og forretningsspecifikke 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 databaseomlæ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øsningen 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-

32 Side 32 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem viklings- eller købsproces overholder begrebsmodel krav 1 6 og vedligeholder samt udbygger modellerne i samarbejder og sammenspil mellem Kunden og Leverandøren så der bibeholdes et fælles billede af domæne og begreber. Begrebsmodel relateret til institution/skole Figur 6 viser identificerede centrale begreber omkring en institution/skole i et studiesystem. Klasse/stamhold Skolekalender Udbudsoversigt Prøve Bekendtgørelse Uddannnelses udbud Praktikophold Skoleophold Karakterskala Uddannelsesmodel Udbudssted Målepinde Uddannelse Institution / Skole Afdeling Lokale fag AMU skolefag UVM fag Rapport skabelon Medarbejder IT udstyr Niveau Mine rapporter Uddannelsesniveau Tidsperiode Godkendelse Andre kompetencer Ansættelseforhold Undervisnings kompetence Censor kompetence Komptenece register Figur 6 - Begrebsmodel relateret til institution/skole

33 Side 33 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Skole Skolepraktik Uddannelse Skoleophold Praktikophold Praktiksted Hold Fagretning Elev Stamhold Elevforløb Uddannelse kategori Servicekatalog Booking Prøve Betaler Værelse Uddannelsesaftale Prøveresultat Fravær Takstkatalog Aktivitetsindberetning Figur 7 - Begrebsmodel relateret til elev Begrebsmodel relateret til registrer optagelse Begrebsmodelelementer specifikt set i forhold til området optagelse vises i Figur 8. Kontaktlærer Elevforløb Elev Klasse/ stamhold Praktikforløb Skoleforløb Lærer Hold Begrebsmodel relateret til elev Figur 7 viser identificerede centrale begreber omkring en elev på en institution/skole i et studiesystem. Læringsaktivitet Undervisnings kompetence Lokalt fag UVM Fag Figur 8 - Begrebsmodel relateret til registrer optagelse

34 Side 34 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 opgaver. 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.

35 Side 35 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem 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 moduler 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 behovsmatrixen 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 ungdomsog 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 tankegang.

36 Side 36 Forprojekt nyt studiesystem Behovsanalyse af et nyt studiesystem Figur 10 - Illustration af sammenhæng mellem datagrundlag, basismodul og øvrige moduler