Kvalitetssikring av data i FS

Kort om kvalitetssikring av data i FS

Dette notatet er tenkt som et hjelpemiddel for institusjonene om hvordan data i FS kan kvalitetssikres. Data som legges inn i FS, tjener flere formål. Institusjonen trenger selv oversikt over sine aktiviteter, studenter skal på en enkel måte ha tilgang til data om seg selv og om undervisning for eksamen m.m. Videre rapporteres data fra FS til andre systemer og brukes i mange sammenhenger. Viktig her er rapporteringen til DBH (Database for Høgere Utdanning) og rapportering til Lånekassa. I begge disse tilfeller brukes data fra FS i forbindelse med finansiering. Data som rapporteres fra FS til DBH, går inn i departementets finansieringsmodell til institusjonene, og data til lånekassa brukes til å omgjøre lån til stipend for studenter. Data fra FS overføres også til andre systemer som undervisnings­time­plan­leggings­system, og brukes i kunngjøringer om undervisning og eksamen. Det er derfor svært viktig at data i FS har god kvalitet.

For at vi skal få et system med data som har god kvalitet, er det viktig at vi har best mulig opplegg for å hindre at feil oppstår, samtidig som vi må ha gode muligheter til å avsløre feil som likevel finnes i systemet.

Kvalitetssikringen av data foregår på mange ulike måter:

• innebygd i FS (triggere, kodetabeller, logger)
• diagnoserapporter
• dokumentasjon
• arbeidsrutiner, beskrivelser og kontrollrutiner
• enkelt og forståelig regelverk

Konsistent datamodell

Grunnmuren i FS er datamodellen. Den beskriver hvilke data vi har i databasen, og sammenhengen mellom disse data. Den gjennomgangen som ble gjort av aktiviteter som skulle dekkes av FS, den gang vi startet med utviklingen, har vist seg å ha ført til et solid fundament. Nye moduler og andre endringer har vært utført som et løpende arbeid i FS. Det har ført til at FS er et system som er kontinuerlig oppdatert og avspeiler behovene i dagens situasjon.  Når det er gjort endringer i datamodellen, har vi overført data som tidligere er lagt inn i andre tabeller, til den nys strukturen. På denne måten får vi små problemer med historikken på data.

Kontroll av data i databasen

Mange opplysninger i FS blir automatisk kontrollert i databasen. Det er lagt inn en mengde kodetabeller som medfører at når en benytter en verdi for et felt, så må denne verdien være definert på forhånd som en lovlig verdi. Et eksempel er ”Land”. Alle lovlige verdier for land vil være lagt inn i en kodetabell, og andre verdier vil ikke være lovlig. Videre er det lagt inn forretningsregler i basen som ikke kan omgås uansett grensesnitt inn i basen. Et enkelt eksempel på en slik regel er kontrollen på at et gitt fødselsnummer er ”riktig”, det vil si at de to siste sifrene stemmer i henhold til en algoritme for å beregne dem.

FS opererer også med informasjonsbærende identifikator. Alternativt til en slik identifikator er en påkrevd entydig nøkkel. Datasikkerheten blir langt dårligere dersom vi opererer med et løpenummer som identifikator og heller ikke har en påkrevd entydig nøkkel. Et eksempel her er at dersom vi ikke har fødselsnummer som identifikator, eller i det minste krever denne som et påkrevd entydig felt, så ville vi kunne legge inn flere personer med samme fødselsnummer, og få en mengde dubletter i systemet.

Protokoller i databasen

Data i FS brukes i flere sammenhenger. Noen av dataene blir derfor spesielt viktige, og må beskyttes spesielt. Dette gjelder for eksempel eksamensdata. Dette er studentens bekreftelse på hvordan han/hun ligger an i studiet, det er data som inngår i finansieringsmodellen til departementet, det er data som brukes i forbindelse med omgjøring av lån til student, og det er institusjonens data som viser produksjonen ved den enkelte enhet. Slike data har derfor fått en ekstra beskyttelse i systemet. Når behandlingen av en eksamen er ferdig, flyttes alle resultater over til en egen tabell. Denne tabellen er det bare et fåtall personer som skal ha adgang til å kunne endre i.  I tillegg til eksamensresultater, har vi en egen protokoll for deleksamener og kvalifikasjoner.

Roller (i databasen)

Oracle har et eget rollebegrep som er benyttet i FS. Rollene sier hvilke tabeller (og hvilke kolonner i tabellene) og hvilke rapporter og oppdateringsrutiner en bruker har adgang til. Det er i FS utarbeidet en bruk av disse rollene som alle institusjonene forholder seg til. Dermed får institusjonene mindre arbeid internt ved å holde orden på rollebegrepet. Kontroll på radnivå hører ikke med til Oracle’s rollebegrep. Det vil si at når en bruker har tilgang til visse opplysninger, for eksempel om en student, så har vedkommende tilgang til de samme opplysningene for alle studenter. For noen få rutiner er det lagt inn validering på stednivå. Arbeidsgruppen har flere ganger diskutert nødvendigheten av flere kontroller på radnivå, men er kommet til at dette ikke er verd arbeidet. Den største hindringen her er at det er vanskelig (eller umulig) å finne ut hvilke data en bruker skal ha tilgang til. For eksempel hører en student ofte ikke bare til ved ett fakultet eller til ett studieprogram.

For lesetilgang i FS er det kun innført et par roller. Når det gjelder hvem som får oppdatere, så er det innført mange forskjellige roller. Oppdatering i eksamensprotokollen skal bare noen få personer ved institusjonen ha tilgang til.

Logger fra databasen

Endringer i en del tabeller medfører at det blir laget logg i systemet hvem som har utført disse endringene. Dette gjelder for eksempel eksamensprotokolltabellen og emnetabellen.

Diagnoserapporter

Diagnoserapporter er laget i FS som et hjelpemiddel for å avdekke om det er lagret opplysninger i basen som for så vidt ikke er ulovlig, men som bør undersøkes nærmere. Et eksempel på en slik diagnoserapport er kontroll om studentene fyller krav som stilles med hensyn til obligatoriske oppgaver, studierett og så videre. Diagnoserapporter må kjøres aktivt for å få fram opplysninger.

Dokumentasjon (fra utviklingsgruppen)

FS har en omfattende systemdokumentasjon som dokumenterer systemet til bruk for utviklerne.  Det er også utarbeidet omfattende brukerdokumentasjon som beskriver hvordan FS fungerer. I systemet ligger det nå inne mulighet til å beskrive hvert felt i databasen. Brukeren kan få denne beskrivelsen opp i applikasjonen når markøren står på et bestemt felt. Denne muligheten ble innført i FS versjon X.X (tidspunkt), og alle felt som er lagt inn siden den gang, er beskrevet. Det jobbes med å oppdatere beskrivelsen av resten av feltene.

Rutinebeskrivelse

Helt fra utviklingen av FS startet i 1994, har det vært en forutsetning at leverandøren leverer brukerdokumentasjon av systemet, og kundene (institusjonene) lager selv rutinebeskrivelser. Det vil si at det er institusjonenes ansvar å beskrive hvordan de bruker systemet. I praksis er det blitt utarbeidet relativt få rutinebeskrivelser.

Utviklingen når det gjelder bruk av systemet, har i de nærmere 10 årene systemet har vært i bruk, gått i retning av mer og mer ensartet bruk. Dette har sammenheng både med at institusjonene lærer av hverandre, og at mye av dataene i FS overføres til andre systemer. De relevante data må derfor være representert på en ensartet måte i basen.

I løpet av 2005 vil det fra utviklingsgruppens side bli utarbeidet forslag til rutine­beskrivelse for behandlingen av de data som rapporteres til DBH, og som inngår i finansieringsmodellen til departementet (UFD). Institusjonene må tilpasse disse til sin egen virkelighet. For eksempel er det viktig for den enkelte institusjon å spesifisere hvordan oversendelsen av data skal foregå, og hvem som skal godkjenne det endelige resultat.

Det at bruken av FS mer og mer går i retning av en ensartet bruk, har også gjort at muligheten for å ”låne” rutinebeskrivelser av hverandre, er blitt større. På hjemmesiden til FS er det lagt opp et eget område med rutinebeskrivelser fra enkelte institusjoner. På denne måten vil hver institusjon ha et godt utgangspunkt når de skal utarbeide rutinebeskrivelser for et område.

Spesielt er det viktig at institusjonene utarbeider gode rutiner for sikring av brukernavn og passord.

Studentens innsyn

Studenter har tilgang til data i FS via studentweb. Her kan de kontrollere opplysninger om seg selv, og de kan oppdatere opplysningene. Feil i opplysninger som de ikke selv kan oppdateres, kan meldes til institusjonen. Selv om dette er et godt hjelpemiddel for kvalitetssikringen, må en være klar over at studentene i stor grad bare oppdaterer opplysninger når de selv ser nytten av dette. Endring av adresse er for eksempel et område der institusjonene fortsatt har problemer med å få korrekte data.

Levering av data til andre systemer

DBH

Avlevering av data til DBH er allerede nevnt. Spesielt rundt studiepoengproduksjon utarbeides det rutiner for hvordan disse skal kontrolleres.

Lånekassa

Data fra FS leveres til Lånekassa og brukes i omgjøringen av lån til stipend, og for å sende ut gjeldsbrev til studentene. Studenten får via Studentweben en oversikt over hvilke data som er oversendt lånekassa for vedkommende student. På denne måten kan studenten selv følge med i at disse opplysningene er riktige.

E-læringssystemer

Data fra FS leveres til e-læringssystemer via standardiserte grensesnitt. Manglende opplysninger kan derfor også kontrolleres denne veien.

Økonomisystemer

FS forholder seg til to økonomisystemer: Agresso og Oracle Financial. Etter hvert som det blir mer og mer vanlig at studenter må betale for visse tjenester, er det blitt mer fokus på at denne integrasjonen mellom systemer fungerer. I FS er det full reskontro-funksjonalitet. Opplysninger om innbetalinger med mer overføres til økonomi­systemene.

Brukeradministrative system (BAS)

FS er det system som leverer data til de brukeradministrative system for studenter. Når institusjonen har innført et BAS, vil ikke studenten få IT-rettigheter uten å ligge i dette systemet. For å trekke inn slike rettigheter, må derfor data i FS vise om studenten er aktiv og så videre.

Adgangskontrollsystem

Flere institusjoner henter data fra FS og overfører dem til et adgangskontrollsystem. Dette medfører igjen at det blir press på at opplysningene er korrekte.

Studieinformasjonssystemer

Institusjonene legger i stor grad opplysninger om emner, studieprogram, undervisning og så videre ut på nett. Disse data kan hentes fra FS. Utdanning.no vil samle opplysninger om emner og kurs og presentere disse under en felles nasjonal portal. I FS er det laget en rapport med de emne-opplysninger og studieprogramopplysninger som er definert i en standard (CDM – Course Descriprion Metadata).

LIST – ledelsesinformasjonssystem

LIST (LedelsesInformasjon og Statistikk) er et delsystem av FS. Systemet overfører data fra institusjonenes FS-baser til et datavarehus, hvor dataene anonymiseres, forenkles og tilrettelegges på ulike vis. Datagrunnlaget som ligger til grunn for rapporter fra LIST, kan være stort. En analyse av disse data har i flere tilfeller ført til at ”merkelige” ting i FS-produksjonsbasen er funnet. Et eksempel på dette er studiepoengproduksjon som aldri er rapportert til DBH.