Prosjektrapport. System for administrasjon av stipendiater i organisert PhD-utdanning Gruppe 9, TDT4290 Kundestyrt Prosjekt

Transkript

1 Gruppe 9, TDT4290 Kundestyrt Prosjekt System for administrasjon av stipendiater i organisert PhD-utdanning Prosjektrapport NTNU Norges teknisk-naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap

2 ii Prosjektrapport

3 Innledning Forord Denne prosjektrapporten er et resultat av gruppe 9 sitt arbeid med faget TDT4290 Kundestyrt prosjekt høsten Prosjektgruppen består av seks studenter i fjerde årskurs ved Institutt for datateknikk og informasjonsvitenskap (IDI) ved Norges teknisk-naturvitenskapelige universitet (NTNU). Oppdragsgiver for oppgaven er Fakultetet for informatikk, matematikk og elektronikk (IME) ved Tore Jørgensen. IME-fakultetet har ca 160 stipendiater i organisert PhD-utdanning, og ønsker derfor et automatisert administrativt verktøy med webgrensesnitt som integrerer alle administrative rutiner i forbindelse med PhD-utdanningen. Kunden ønsker også å presentere IME-fakultetets faggrupper og forskningsmiljø på Internett, med stor vekt på grafisk utforming. Prosjektet har resultert i en prototyp for å demonstrere den funksjonalitet prosjektgruppen mener et slikt administrativt system bør ha. Prosjektet kan danne grunnlaget for videre utvikling av prototypen til et fullverdig system for administrasjon av PhD-utdanningen. Trondheim, 11. november 2003 Erik Harg Carl-Henrik Wolf Lund Mette Hesjedal Ida Hveding Huse Frode Hauso Håvard Sjøvoll Prosjektrapport iii

4 Innledning iv Prosjektrapport

5 Innledning Sammendrag På oppdrag fra Fakultetet for informasjonsteknologi, matematikk og elektroteknikk (IME), har vi utarbeidet en prototyp som illustrerer automatiseringen av en av fakultetets administrative prosesser i forbindelse med PhD-utdanningen. Bakgrunnen for prosjektet var at IME ønsket seg et verktøy med webgrensesnitt som integrerer alle administrative rutiner, fra kunngjøring av stillinger til presentasjon av PhD-studenter og deres arbeider på Internett. Prosjektgruppen har utarbeidet en forstudie hvor dagens metoder på fakultetet er beskrevet. Både presentasjonen av de faglige aktivitetene og de administrative rutinene er behandlet. I samråd med kunden ble prosjektet i forstudien begrenset til videre kun å omhandle den administrative delen. De ulike administrative prosesser har blitt analysert. Utifra kundens ønske om en funksjonell prototyp, avgrenset vi arbeidet i kravspesifikasjonen til å omfatte en av de administrative prosessene, opptak til PhD-program. Denne prosessen ble valgt siden den er illustrerende også for de øvrige administrative prosessene. Utviklingen av prototypen, kalt CuraWeb, er beskrevet i kravspesifikasjonen, konstruksjonsspesifikasjonen, og implementasjonsrapporten. Hjelp til bruk av systemet er beskrevet i systemdokumentasjonen. Prosjektdirektivet inneholder planen for prosjektet, og vi har utarbeidet en prosjektevaluering som oppsummerer hvilke erfaringer prosjektgruppen har gjort seg. Prosjektrapport v

6 Innledning vi Prosjektrapport

7 Innholdsfortegnelse Innholdsfortegnelse 1 Prosjektdirektiv Forstudie Kravspesifikasjon Konstruksjon Implementasjon Systemdokumentasjon Prosjektevaluering Prosjektrapport vii

8 Innholdsfortegnelse viii Prosjektrapport

9 Gruppe 9, TDT4290 Kundestyrt Prosjekt System for administrasjon av stipendiater i organisert PhD-utdanning Prosjektdirektiv

10 ii Prosjektdirektiv

11 Innholdsfortegnelse Innholdsfortegnelse 1 Innledning Prosjektmandat Prosjektnavn Oppdragsgiver Bakgrunn Effektmål Effektmål Resultatmål Prosjektets omfang Rammebetingelser Økonomi Tid Prosjektplan Faser Prosjektledelse Forelesninger og egenlæring Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testing Presentasjon og demonstrasjon Fasenes estimerte arbeidsbelastning Milepæler Prosjektorganisering Personer i gruppen Organisering av gruppen Organisatoriske rutiner Møter Timelister Maler og standarder Fasedokumenter Møteinnkallinger Møtereferater Statusrapporter Katalogstruktur Navngivning av filer Versjonskontroll Prosjektoppfølging Prosjektmøter Intern rapportering...16 Prosjektdirektiv iii

12 Innholdsfortegnelse 6.3 Statusrapportering Risikohåndtering Kvalitetssikring Kvalitetskrav innad i gruppen Kvalitetskrav i forhold til veileder Kvalitetskrav i forhold til kunde Risikoanalyse...18 Vedlegg A: Revidert Gantt-diagram...19 Vedlegg B: Opprinnelig Gantt-diagram...20 Vedlegg C: Interessenter...21 Vedlegg D: Mal for møtereferat...22 Vedlegg E: Timeliste...23 iv Prosjektdirektiv

13 Figuroversikt Figuroversikt FIGUR 3-1 Vannfallsmodellen...6 FIGUR 4-1 Organisasjonskart for gruppen...11 FIGUR A-1 Revidert Gantt-diagram...19 FIGUR B-1 Opprinnelig Gantt-diagram...20 FIGUR D-1 Mal for møtereferater...22 FIGUR E-1 Eksempel på ukesrapport på timeliste...23 Prosjektdirektiv v

14 Figuroversikt vi Prosjektdirektiv

15 Tabelloversikt Tabelloversikt TABELL 3-1 Arbeidsbelastningen...10 TABELL 8-1 Risikotabell...18 TABELL C-1 Kunden...21 TABELL C-2 Veiledere...21 TABELL C-3 Prosjektgruppen...21 Prosjektdirektiv vii

16 Tabelloversikt viii Prosjektdirektiv

17 Innledning 1 Innledning Prosjektdirektivet regulerer den administrative delen av prosjektet. Det vil klargjøre oppgavens bakgrunn og mål, samt prosjektets faser og milepæler. Kapittel 2 omhandler prosjektets oppgave, mål og rammebetingelse. I kapittel 3 tar vi for oss de ulike fasene vi har delt prosjektet inn i, hva hver enkelt fase vil inneholde og hva formålet er med dem. Prosjektets organisering og ansvarsforhold kartlegges i kapittel 4 og i kapittel 5 kommer en oversikt over hvilke maler og standarder vi har valgt å bruke. Kapittel 6 omhandler de rutiner vi har satt for oppfølging og rapportering underveis i prosjektet. Til slutt har vi et kapittel som sier litt om hvordan vi har tenkt å kvalitetssikre prosessen i prosjektet. Prosjektdirektiv 1

18 Prosjektmandat 2 Prosjektmandat Prosjektmandatet tar for seg bakgrunnsinformasjon knyttet til prosjektet. 2.1 Prosjektnavn Vi har valgt å kalle prosjektet vårt CuraWeb. Cura betyr administrasjon på latinsk. Systemet som skal utvikles skal automatisere administrasjonen av PhD-studenter ved IME-fakultetet. 2.2 Oppdragsgiver Fakultet for informasjonsteknologi, matematikk og elektroteknikk (IME-fakultetet) ved Norges teknisk-naturvitenskapelige universitet (NTNU). 2.3 Bakgrunn Fakultetet for informasjonsteknologi, matematikk og elektronikk har en god faglig situasjon, på enkelte områder i verdensklasse, men føler ikke at det er samsvar mellom det faglige nivået og profileringen av forskningen. Det er særlig på dr.gradsnivå hvor dette er et problem. IME ser behov for en bedre profilering for dermed å rekruttere kandidater med tilsvarende faglige kvaliteter. IME ønsker også å utnytte mulighetene i et automatisert system for å forenkle prosessene med administrasjon av dr.gradsstudier, rekruttering (herunder søking, behandling av søknad og tilsetting) og informasjon om nåværende PhD-studenter. Det eksisterende system for administrasjon av stipendiater i organisert doktorgradsutdanning ved IME-fakultetet på NTNU fremgår av Disse sidene tar for seg hvordan doktorgradsprosessen generelt forløper, regler og forskrifter for doktorgradsutdanningen, samt søknadsskjemaer som må fylles ut og sendes pr post. I tillegg til informasjon om doktorgradsprosessen, gir sidene en oversikt over alle doktorgradstudenter ved IME-fakultetet pr dags dato og tidligere doktorgradstudenter ved samme fakultet, se henholdsvis Nye dr.studenter og Avlagte grader i menysystemet på hjemmesiden. Informasjonen om de forskjellige doktorgradstudentene inneholder kun studentens navn, arbeidstittel for avhandling og hovedveileder. Kunngjøring av stillinger foregår i dag på Det er ønskelig at dette integreres i det nye systemet for å oppnå et fullautomatisert system. Vi finner en del svakheter ved bruk av eksisterende system. Systemet har ikke god nok struktur, og det er vanskelig å finne relevant informasjon. Samme type informasjon gjengis ofte flere steder, noe som har ført til inkonsistens mellom de forskjellige utgavene. 2.4 Effektmål Gjennom prosjektet har vi sett behov for å dele opp målene til prosjekt i to kategorier. Overordnede mål er de målene som ble satt til prosjektet da oppgaven ble gitt. Siden omfanget av oppgaven etter dette har blitt kraftig redusert, til kun å implementere en prototyp av det overordnede systemet, har vi sett oss nødt til å lage nye mål som er dekkende for de endelige avgrensningene. 2 Prosjektdirektiv

19 Prosjektmandat Effektmål Med effektmål menes den effekten som skal oppnås. Effektmål for overordnet system: Presentasjonen av PhD-utdanningen og forskningen ved IME-fakultetet skal være av meget høy grafisk og innholdsmessig kvalitet Systemet skal være med på å øke antall søkere til PhD-program ved fakultetet Prosessen fra utlysning til uteksaminering skal være så effektivisert som mulig, kostnadsreduksjonen i forbindelse med administrativt arbeid ved fakultet skal være minst 50% Driften av systemet skal være lite arbeidskrevende og meget pålitelig Effektmål for prototyp: Demonstrere mulighetene, som ligger i dagens teknologi, til å kunne automatisere de administrative prosessene Resultatmål Med resultatmål menes de leveransene som prosjektet skal overlevere til kunden og brukerne. Resultatmål for overordnet system: Utvikle et websystem for håndtering av PhD-studenter, fra rekrutteringsfasen til tilsettingsog presentasjonsfasen. Systemet skal realiseres som et "fullautomatisert" databasert administrativt verktøy med webgrensesnitt Resultatmål for prototyp: Utvikle en prototyp på en web-applikasjon for håndtering av opptaksprosessen til et PhDprogram 2.5 Prosjektets omfang Det er lagt vekt på at dette prosjektet kan sees på som et forprosjekt til en større satsing på et elektronisk saksbehandlingssystem for IME. Det er dermed viktig at forstudiet og kravspesifikasjonen blir vektlagt større tyngde enn senere faser som f.eks. implementasjonsfasen. Kunden er opptatt av at det endelige resultatet skal være en prototyp som kan brukes som en demonstrator når prosjektet skal videreføres. Kun en del av systemet skal implementeres i prototypen, og det skal vise hvilken funksjonalitet systemet kan ha. 2.6 Rammebetingelser Med rammebetingelser menes de faktorene som begrenser oss i prosjektarbeidet. Disse betingelsene er listet opp her: Verktøy Systemet som skal implementeres skal kjøre hos IME-fakultetet i ettertid. Valg av verktøy må derfor passe med de standardene de har der. Krav fra kunden Systemet skal integrere alle administrative rutiner Systemet skal gi en presentasjon av doktorgradsstudentene ved fakultetet og deres arbeider på Internett Ressurser Prosjektdirektiv 3

20 Prosjektmandat Gruppens medlemmer To veiledere, én hoved- og én hjelpeveileder Kunden Kontorstøtte Maskiner på NTNU Programvare 2.7 Økonomi Prosjektets økonomi er antall timer gruppen har til rådighet: 1860 timer (310 timer * 6 personer). 2.8 Tid Preleveranse av forstudie og kravspesifikasjon er 23.oktober Prosjektet avsluttes 13. november med innlevering av skriftlig rapport samt en presentasjon av arbeidet 4 Prosjektdirektiv

21 Prosjektplan 3 Prosjektplan Vi har delt prosjektet inn i ni faser, der hver fase har sitt hovedfokus i forhold til hvor langt vi har kommet i prosjektgjennomføringen. De ulike fasene har hver sine oppgaver som skal bli gjort innenfor tidsrommet satt av til fasen. Fasene vil følge kronologisk etter hverandre i tid, men med overlappinger. Hvordan prosjektet er lagt opp i forhold til de forskjellige fasene kommer frem i Gantt-diagrammet i vedlegg A. To av fasene, Prosjektledelse og Forelesninger og egenlæring vil ikke være tidsavgrenset på linje med de andre fasene. Disse inneholder arbeidsoppgaver som utføres gjennom hele prosjektets levetid, og vil på den måten inngå i alle de andre fasene. 3.1 Faser Her følger en beskrivelse av oppgaver som skal utføres i de forskjellige fasene og formålet med disse. De ulike fasene av prosjektet er: Prosjektledelse Forelesninger og egenlæring Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testing Presentasjon og demonstrasjon De syv siste fasene vil, som nevnt, følge etter hverandre i tid med mulighet for iterasjoner i hver fase. Vi følger den såkalte vannfallsmodellen, en lineær modell der alle fasene kommer etter hverandre i sekvens, se figur 3-1 på side 6. Prosjektdirektiv 5

22 Prosjektplan FIGUR 3-1 Vannfallsmodellen Planlegging Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testing Presentasjon og demo Prosjektledelse Som nevnt i innledningen til dette kapitlet vil denne fasen strekke seg gjennom hele prosjekttiden. Man vil ha prosjektstyring og ledelse gjennom hele prosjektet, og en valgt prosjektleder vil ha sitt verv og dets tilhørende oppgaver. Formål med fasen: En tilfredsstillende administrativ gjennomføring av prosjektet Oppgaver: Velge prosjektleder Fordele ansvar Prosjektstyring Forelesninger og egenlæring I likhet med fasen Prosjektledelse vil denne fasen gå gjennom hele levetiden til prosjektet. Hovedvekten på egenlæringen vil nok forekomme i starten av prosjekttiden, både fordi de fleste forelesningene er lagt i startfasen, men også fordi behovet for egenlæring vil være størst ved prosjektets oppstart. Formål med fasen: At gruppemedlemmene skal tilegne seg relevant kunnskap som skal brukes i prosjektet 6 Prosjektdirektiv

23 Prosjektplan Oppgaver: Møte opp på oppsatte og relevante forelesninger i faget Sette seg inn i aktuelle verktøy gruppen har valgt å bruke Skaffe seg relevant informasjon rundt oppgavens tema Planlegging I planleggingsfasen planlegges den administrative biten av prosjektet. Det er også i denne fasen at gruppen blir kjent, og det brukes tid på å få frem gruppemedlemmenes ambisjoner og mål. De administrative delene som settes er bl.a. tidsplan, en del standarder og maler som skal brukes og generelle valg av verktøy. Dette dokumentet, prosjektdirektivet, som blir til i denne fasen, skal være et dynamisk dokument og kan endres gjennom hele prosjektet. Fasedokument: Prosjektdirektiv Oppgaver: Fordele roller Definere maler og standarder Administrative forberedelser Valg av administrative verktøy Planlegge neste fase Forstudie I denne fasen er det viktig at gruppen får en god forståelse av problemet og oppgaven. Her skal problemstillingen beskrives, og som bakgrunn for dette presenteres dagens situasjon, ønsket situasjon, krav og alternativer for en ny løsning. Denne fasen avsluttes med at det gjøres et valg av løsning. Fasedokument: Fasedokument fra forstudie Oppgaver: Forstå problemstillingen Definere oppgaven Beskrive dagens system Finne frem til flere mulige løsninger og vurdere disse Velge løsning, begrunne valget Valg av utviklingsverktøy Planlegge neste fase Kravspesifikasjon Her skal de funksjonelle- og ikke-funksjonelle kravene til systemet beskrives. Det er viktig at det er sporbarhet tilbake til de forretningsmessige kravene som blir satt i forstudiet. Før kravene detaljeres vil det bli satt opp en overordnet programvarerkitektur for å få oversikt over systemet. Det er også i denne fasen at en overordnet testplan utarbeides. Prosjektdirektiv 7

24 Prosjektplan Fasedokument: Kravspesifikasjon Oppgaver: Lage en overordnet programvarearkitektur Definere krav til systemet, funksjonelle og ikke-funksjonelle Komplettere beskrivelse av problemer og mål Prototyping av skjermbilder Overordnet testplan Konstruksjon I konstruksjonsfasen skal vi komme frem til en realiserbar spesifikasjon av systemet og dets krav med en detaljert beskrivelse av den teknologien som skal brukes. Implementasjonsfasen skal planlegges og det er mulig det blir en del pseudokode i denne fasen for å beskrive enkelte løsninger. Fasedokument: Konstruksjonsdokumentasjon Oppgaver: Fastlegging av overordnet struktur og delstrukturer for systemet Komplettere funksjonell beskrivelse Databasemodell Programskjelett Plan for hver enkelt test som skal gjennomføres Detaljerte testspesifikasjoner for hver test Implementasjon I implementasjonsfasen implementeres all kode til systemet. I tillegg skal koden dokumenteres på et slikt vis at kunden klarer å bruke denne videre. Fasedokument: Implementasjon Dokumentasjon Oppgaver: Implementere system ved hjelp av valgt teknologi Dokumentere kode Gi en beskrivelse av systemets muligheter og begrensninger Beskrive systemets funksjonalitet Dokumentere avvik i forhold til planleggingen Planlegge neste fase 8 Prosjektdirektiv

25 Prosjektplan Testing De testene som gjennomføres i testfasen skal være planlagt i de tidligere fasene. Inkludert i testene er retting av feil, restesting og dokumentasjon av testene. Fasedokument: Testdokumentasjon Oppgaver: Gjennomføre testene Retting av feil Retesting Dokumentasjon av testene Bruker- og installasjonsveiledning Planlegge neste fase Presentasjon og demonstrasjon I denne siste fasen av prosjektet skal sluttproduktet presenteres for kunde, sensor, veiledere og eventuelt andre interesserte. Presentasjonen deles i to ca like store deler; en presentasjonsdel og en demonstrasjonsdel. Presentasjonen må planlegges nøye og demonstrasjonen bør være testet grundig på forhånd. Fasedokument: Gjennomføre en praktisk demonstrasjon av systemet, vise mulig funksjonalitet. Oppgaver: Planlegging av presentasjon Installasjon og klargjøring for demonstrasjon Presentere oppgaven og prosjektgjennomføringen Presentere prototypen Prosjektdirektiv 9

26 Prosjektplan 3.2 Fasenes estimerte arbeidsbelastning TABELL 3-1 Arbeidsbelastningen Faser Arbeidsbelastning Prosjektledelse 10 % Forelesninger og egenlæring 10 % Planlegging 7 % Forstudium 15 % Kravspesifikasjon 20 % Konstruksjon 15 % Programmering og dokumentasjon 13 % Prosjektvurdering 5 % Presentasjon og demo 5 % Forklaring til tabell 3-1: Arbeidsbelastningen i prosent slik vi ser for oss at den vil bli fordelt over de ni fasene Arbeidsbelastningen i prosjektet vil bli fordelt over fasene som vist i tabell 3-1. Det er tatt utgangspunkt i fordelingen slik den normalt har fordelt seg i faget tidligere, da gruppen ikke har erfaring til å kunne sette opp noe annet. Det kan tenkes at denne prosentfordelingen må endres utover i prosjekttiden. 3.3 Milepæler For å sikre at prosjektet holder tidsrammene, har prosjektgruppen satt opp interne milepæler. De milepælene som ble satt opp ved prosjektstart har blitt revidert i løpet av prosjekttiden. Dette var noe gruppen var klar over da den første planen ble satt opp, grunnet gruppens begrensede erfaring med prosjekt på denne størrelsen. I tillegg var oppgaven omfattende og noe upresis slik at det viste seg at vi kom til å trenge mer tid på fasene tidlig i prosjektet. Både det nye og det gamle Gantt-diagrammene er lagt ved, i henholdsvis vedlegg A og vedlegg B. 10 Prosjektdirektiv

27 Prosjektorganisering 4 Prosjektorganisering I dette kapitlet kommer en kort oversikt over hvordan gruppen er organisert og hvilke organisatoriske rutiner vi har innad i gruppen. 4.1 Personer i gruppen Organisasjonen i dette prosjektet er de seks gruppemedlemmene. Alle går fjerde året på linjen datateknikk ved NTNU i trondheim og tar faget kundestyrt prosjekt høsten Gruppen består av: Håvard Sjøvoll Mette Hesjedal Ida Hveding Huse Carl Henrik Lund Erik Harg Frode Hauso For ytterlig informasjon om gruppemedlemmene og andre interessenter som kunde og veiledere, se vedlegg C. 4.2 Organisering av gruppen Vi har valgt en relativt flat organisasjonstruktur der alle gruppemedlemmene har like stort ansvar for det endelige resultatet. Alle er blitt tildelt ulike roller med sitt ansvarsområde, hvorav en er prosjektleder, se figur 4-1. Som leder for prosjektet vil denne rollen ha et hovedansvar for fremgang og progresjon i prosjektet. De ulike rollene fordelt på gruppemedlemmene ser slik ut: Prosjektleder: Erik Kundekontakt: Ida Veilederkontakt: Mette Dokumentansvarlig: Håvard Databaseansvarlig: Carl Testansvarlig: Frode FIGUR 4-1 Organisasjonskart for gruppen Prosjektleder Kundekontakt Veilederkontakt Dokumentansvarlig Testansvarlig Databaseansvarlig Prosjektdirektiv 11

28 Prosjektorganisering 4.3 Organisatoriske rutiner Møter Gruppen har sammen satt opp noen rutiner som følges ukentlig. Dette går på møter og timerapportering. 1. Møteforløp Ved alle møter er det i utganspunktet prosjektleder som leder møtene. Dette gjelder både de interne møtene, kundemøtene og veiledermøtene. Dersom prosjektleder ikke er tilstede, vil en av de andre i gruppen være stedfortreder. Unntaksvis kan andre i gruppen lede et møtet dersom denne har bedre grunnlag og utgangspunkt enn lederen til dette. 2. Møtetidspunkter Interne møter Veiledermøter: onsdag kl i D2-151 i Realfagsbygget Kundemøter: mandag kl i rom 313 i Gamle Fysikk 3. Møteinnkallelser Møteinnkallelse blir sendt per e-post til alle som skal delta på møte senest klokken siste arbeidsdag før møtet. Innkallelsen skal inneholde tid og sted for møtet, samt agenda Timelister Det blir hver uke ført antall timer hver person har jobbet. Se øvrig informasjon om intern rapportering i kapittel Prosjektdirektiv

29 Maler og standarder 5 Maler og standarder Her følger en oversikt over de maler og standarder gruppen har blitt enige om å bruke gjennom prosjektprosessen. Eksempler på maler finnes i vedlegg A. 5.1 Fasedokumenter Fasedokumentene skal i oppsett følge en felles mal i FrameMaker. Standardoppsettet innebærer alle deler av dokumentene som forside, innholdsfortegnelse, 5.2 Møteinnkallinger Alle møteinnkallinger skal sendes ut via e-post før kl 12 siste virkedag før møtet. Innkallelsen skal inneholde tid, sted og agenda for møtet, samt vedlegg som er relevante for møtedeltakerne å ha forberedt før møtet. Standard oppsett for agenda til veiledermøte: Godkjenning av dagsorden Godkjenning av møtereferat fra forrige veiledermøter Kommentarer til vedlagt møtereferat fra siste kundemøte Godkjenning av vedlagt statusrapport Gjennomgang/godkjenning av vedlagte fasedokumenter Eventuelt Agenda for kundemøtene vil variere og det er derfor ikke tatt med noe standard oppsett for dette. 5.3 Møtereferater Alle møtereferater følger en standard mal i word, se vedlegg A. Det er i det følgende satt bestemte standarder for referater fra henholdsvis kunde og veiledermøtene. 5.4 Statusrapporter Statusrapporten skal legges ut på fellesområdet på BSCW før kl 12 dagen før møtet med veilederne, og veilederne skal godkjenne statusrapporten på møtet.. Rapporten blir skrevet av prosjektleder. Prosjektdirektiv 13

30 Maler og standarder Mal for strukturen på statusrapporten: Oppsummering Utført arbeid Dokumenter Møter Aktiviteter TROKK; Tid - Risiko - Omfang - Kostnad - Kvalitet Problemer Planlagt arbeid Møter Aktiviteter 5.5 Katalogstruktur Det er viktig at dokumentene som ligger på gruppens område på BSCW er plassert i kataloger på en forståelig og hensiktsmessig måte. Katalogstrukturen på gruppens område på BSCW ser slik ut: Kalender Administrativt Møtereferat Kunde Veileder Intern Prosjektdirektiv Forstudie Kravspesifikasjon Konstruksjon Implementasjon Testdokument Grafikk, diagrammer ol Sosialt Katalogene til hver av fasene er delt inn i Forside, Innhold og Vedlegg. 5.6 Navngivning av filer Filer skal navngis med liten forbokstav og understrek _ som skille mellom flere ord i et navn. Da BSCW tar seg av versjonskontroll og historien til dokumentene, trenger navnet på filen kun være beskrivende i forhold til innholdet. Når det gjelder navn på figurer og bilder har vi satt en standard på dette; figurer i begynner med figure_ og bilder begynner med img_. Eksempel: 14 Prosjektdirektiv

31 Maler og standarder figure_prosessflyt_phd.ai figure_prosessflyt_stipendiat.ai img_skjermdump_ime.gif img_skjermdump_idi.gif Navn på møtereferatene skal inneholde dato da møtet ble holdt, og hva slags møte det har vært. Standard navngining på disse: år-mnd-dag_<møtetype>.<dokumenttype> Eksempel: _veileder.pdf _vunde.pdf 5.7 Versjonskontroll Som samarbeidsverktøy og versjonskontroll av dokumenter har gruppen valgt på bruke Basic Support for Cooperative Work (BSCW). Det vil si at all lagring av rapporter, referater, dokumentasjon og andre aktuelle dokumenter blir gjort her. Hvem som har lagret eller gjort endringer på et dokument, og også datoen for hendelsen, vil bli registrert i BSCW. For å bruke versjonskontrollen i BSCW velger man Version på filen, og man får her muligheten til å legge til informasjon om hvilken versjon det dreier seg om, og hvilke endringer en har gjort. For å endre en fil i BSCW må man låse filen for så å endre før man legger ut den reviderte versjonen og frigjør igjen dokumentet. Brukermodus må være satt til Advanced eller Expert for å kunne låse dokumenter. Når det gjelder versjonskontroll under implementasjonsfasen mener vi at BSCW ikke egner seg like godt. Det skal derfor sette opp en Concurrent Versions System-server (CVS-server), og benytte oss av denne. Prosjektdirektiv 15

32 Prosjektoppfølging 6 Prosjektoppfølging Vi vil her beskrive rutiner for oppfølging av fremdriften i prosjektet. Dette går på ukentlige rutiner som interne møter, intern rapportering, statusrapportering og risikohåndtering. 6.1 Prosjektmøter Det er satt opp faste møtetider hver uke, der gruppen møtes i P15-bygget, og det blir vurdert i forkant av møtet hvorvidt det trengs et felles oppsummerings- og statusmøte, eller om jobbing i fellesskap er å foretrekke. 6.2 Intern rapportering Det lages hver uke en timeliste der alle på gruppen skriver inn det antall timer de har brukt siste den foregående uke. Dette skjemaet blir brukt til å lage en ukesrapport hver uke der vi summerer opp hvor mye tid gruppen har brukt på de ulike fasene. I vedlegg E er det lagt ved et eksempel på en slik ukesrapport. Dette kan dermed brukes til å vurdere tidplanen som er satt opp, og evt hjelpe til å endre på arbeidsmetoder dersom vi oppdager at det blir brukt mye tid på mindre viktige deler av prosjektet. Det lages hver uke en fremdriftsrapport som i utgangspunktet er en rapport til veiledermøtene. Denne rapporten er nyttig også for gruppen, og vi ser her spesielt etter om oppsatte milepæler for den foregående perioden er nådd. Dette er en viktig indikator på fremdriften i arbeidet. 6.3 Statusrapportering Det skal hver uke skrives en statusrapport som sendes til veilederne i møteinnkallingen før kl 12 hver tirsdag, dagen før veiledermøtene hver onsdag. Denne rapporten inneholder i korte trekk hva som har skjedd den foregående uken, og følger malen beskrevet i kapittel Risikohåndtering I statusrapporten som blir skrevet til veiledermøtene hver uke blir potensielle risikoer vurdert. Det blir satt inn preventive tiltak for å forhindre at risikoer skal inntreffe, og en ser også på om tidligere oppsatte risikoer kan ha inntruffet. Dersom et problem har oppstått vil dette håndteres på best mulig måte, og gruppen vil også vurdere om det er en risiko som faktisk har inntruffet eller om det noe uforutsett som har skjedd. I begge tilfeller må det settes inn tiltak for å løse problemet samt å unngå at det samme kan inntreffe igjen. 16 Prosjektdirektiv

33 Kvalitetssikring 7 Kvalitetssikring Vi har i dette kapitlet med interne rutiner og rutiner og krav det stilles til prosjektgruppen i forhold til kunde og veiledere. Dette er for å sikre en god kvalitet på dokumenter og produktet, i tillegg til at det vil forenkle prosjektadministrasjonen. 7.1 Kvalitetskrav innad i gruppen Referater fra alle møter blir lagt ut på BSCW før kl 12 dagen etter møtet, referent er kundekontakt ved kundemøter, veilederkontakt ved veiledermøter og varierer på de interne møtene. Dersom det ikke kommer noen tilbakemeldinger innen 24 timer etter dette ansees referatet som godkjent. Når det gjelder godkjenning av fasedokumenter vil det i tiden like før en fase avsluttes utnevnes en person som hovedansvarlig for fullføring av fasedokumentet. Dette vil gjøres på bakgrunn av hvem som har best innsikt og oversikt over fasedokumentet som helhet, samt en person som ikke står med noe spesielt ansvar i forbindelse med oppstart av neste fase. 7.2 Kvalitetskrav i forhold til veileder Hoved- og hjelpeveileder får tilsendt referat fra forrige veiledermøte ved neste møteinnkallelse, og referatet blir gjennomgått og kommentert i møtet. Dersom det har vært kundemøte i tiden mellom to veiledermøter, vil også referatet fra kundemøte bli sendt sammen med møteinnkallelsen. I innkallelesen skal det også legges ved statusrapport, timeliste for foregående uke, samt de dokumenter gruppen ønsker tilbakemeldinger på. 7.3 Kvalitetskrav i forhold til kunde Kunden får tilsendt referatet per e-post innen 24 timer etter at møtet ble holdt. Før dette har referatet blitt godkjent av resten av gruppemedlemmene, referent er kundekontakten. Kommentarer fra kunden blir sendt til referent innen rimelig tid etter utsendelse av referatet, og referatet blir dermed lagt ut på BSCW. Prosjektdirektiv 17

34 Risikoanalyse 8 Risikoanalyse Hensikten med risikoanalysen er å tidlig kunne identifisere hvilke mulige problemer vi står ovenfor i prosjektet og dermed kunne minimalisere sannsynligheten for at de inntreffer. Vi har i risikoanalysen vurdert preventive tiltak for de risikofaktorene vi har sett som mulige kan inntreffe. Vi har også prøvd å vurdere om risikofaktorene har høy (H), lav (L) eller middels (M) sannsynlighet for å inntreffe, og hvor stor effekt det vil ha hvis de faktisk inntreffer. TABELL 8-1 Risikotabell Risikofaktor Sannsynlig Effekt Preventive tiltak Gruppemedlemmer stiller ikke opp M H Snakke om forventninger, ambisjoner og mål, bli godt kjent Sykdom M M C-vitaminer Feil fokus M M Hyppig internmøter, grundig føring av timer Manglende koordinering L M Hyppige internmøter der koordinering vektlegges Utilstrekkelig forståelse av oppgaven Uklarheter, konflikter innad i gruppen Misforståelser mellom kunden og gruppen M H God dialog med kunde og veiledere L M Sosial omgang i startfasen, åpenhet er viktig H H Ha grundig kommunikasjon med kunden, møte forberedt til kundemøter, spørre mye Kunden endrer krav underveis M H Ha hyppige kundemøter Kundens mål svarer ikke med gruppens budsjett Vanskelig å vurdere omfanget tidlig pga liten prosjekterfaring Gruppen behersker ikke nødvendig verktøy el Gruppen har vanskeligheter med å tilegne seg kunnskap om nye verktøy H M Være klare på omfang, evt bruke veiledere til hjelp for å se omfang H H Bruke veilederne, modellere mye tidlig, bruke tid på tidlige faser M H Velge verktøy gruppen har kjennskap til M H Begynne egenlæring tidlig i prosessen 18 Prosjektdirektiv

35 Vedlegg A: Revidert Gantt-diagram Det reviderte Gantt-diagrammet er vist i figur A-1. FIGUR A-1 Revidert Gantt-diagram Prosjektdirektiv 19

36 Vedlegg B: Opprinnelig Gantt-diagram Vedlegg B: Opprinnelig Gantt-diagram Det opprinnelige Gantt-diagrammet er vist i figur B-1. FIGUR B-1 Opprinnelig Gantt-diagram 20 Prosjektdirektiv

37 Vedlegg C: Interessenter Vedlegg C: Interessenter I dette vedlegget finnes personlig informasjon om interessentene i prosjektet, kunden, veilederne og prosjektgruppen. TABELL C-1 Kunden Navn E-post Telefon Tore Jørgensen tore.r.jorgensen@ime.ntnu.no Gudrun Sjøvold gudrun.sjovold TABELL C-2 Veiledere Navn E-post Telefon Per Trygve Myhrer pertm@idi.ntnu.no Einar Hartvig Olsen einarhar@stud.ntnu.no TABELL C-3 Prosjektgruppen Navn E-post Telefon Ida Hveding Huse idahvedi@stud.ntnu.no Håvard Sjøvoll sjovoll@orakel.ntnu.no Erik Harg harg@idi.ntnu.no Mette Hesjedal hesjedal@idi.ntnu.no Carl-Henrik Wolf Lund carlhenr@stud.ntnu.no Frode Hauso hauso@stud.ntnu.no Prosjektdirektiv 21

38 Vedlegg D: Mal for møtereferat Vedlegg D: Mal for møtereferat FIGUR D-1 Mal for møtereferater 22 Prosjektdirektiv

39 Vedlegg E: Timeliste Vedlegg E: Timeliste FIGUR E-1 Eksempel på ukesrapport på timeliste Prosjektdirektiv 23

40 Vedlegg E: Timeliste 24 Prosjektdirektiv

41 Gruppe 9, TDT4290 Kundestyrt Prosjekt System for administrasjon av stipendiater i organisert PhD-utdanning Forstudie

42 ii Forstudie

43 Sammendrag Fakultet for informasjonsteknologi, matematikk og elektroteknikk ved NTNU vil forbedre presentasjonen av PhD-studiet og administrere sine PhD-studenter mer effektivt. I denne forstudien har vi beskrevet dagens metoder for dette arbeidet, samt en skisse av ønsker og en presentasjon av overordnet funksjonalitet for et elektronisk system for å utføre disse oppgavene. En forståelse for hele det administrative arbeidet har blitt vektlagt. Ulike løsninger for systemet har blitt vurdert, og valg av arkitektur og teknologisk plattform har blitt gjort for et web-basert saksbehandlingssystem. Vi har presentert to mulige videreføringer av dette arbeidet; både utvikling av en demonstrator på kort sikt, og en full implementasjon på lengre sikt. Forstudie iii

44 iv Forstudie

45 Innholdsfortegnelse Innholdsfortegnelse 1 Innledning Bakgrunn NTNU Organisasjonsstruktur IME-fakultetet Organisasjonsstruktur PhD-utdanningen Forskjellen mellom en stipendiat og en PhD-student ved NTNU Informasjons- og kommunikasjonsteknologi Elektronisk saksbehandling Dagens situasjon Beskrivelse av dagens administrative system Tilsetting av stipendiater Administrasjon av PhD-studiet Opptak Søknad om å endre fag under opplæringsdelen Søknad om endring av eksamenstidspunkt under opplæringsdelen Innlevering av årlig fremdriftsrapport Søknad om permisjon/forlenget studietid Avslutning Dagens presentasjonsdel Beskrivelse Evaluering Eksisterende løsninger Presentasjondel Administrasjonsdel Ønsket situasjon Beskrivelse av ønsket løsning Presentasjonsdel Administrasjonsdel Brukergrupper Felles Studentdatasystem Teknologiønsker SMS - Short Message Service Videoteknologi Forretningsmessige krav Omfang Prosesser og funksjonalitet Administrative prosesser Presentasjonsdelen Generelle krav Modellering av systemet Alternative løsninger Evalueringskriterier...62 Forstudie v

46 Innholdsfortegnelse 6.2 Generelt om elektronisk saksbehandling Skanning av dokumenter Web-applikasjon Distribusjon av data i form av CD-ROM Vurdering ESB-løsninger Applikasjonsarkitektur Ulike arkitekturer Pipe and filter arkitektur Objektorientert arkitektur Lag-inndelt arkitektur Sammenligning av hovedalternativene for applikasjonsarkitektur Alternative databasearkitekturer Sentralisert database Distribuert database Ekstern database Sammenligning av databasemodellene Tekniske løsninger PHP JSP Perl/cgi Python ASP MySQL PostgreSQL Oracle Språk og databaser Språk og webtjenere Oppsummering Evaluering av arkitekturer og tekniske løsninger Evaluering av arkitekturer Vurdering av alternativene for databasearkitektur Vurdering av tekniske alternativer Konklusjon Navn Vurderinger og anbefalinger Oppgave og omfang Databaseløsninger Applikasjon - arkitektur og teknikk Bruk av FS Veien videre...86 Litteratur...89 Vedlegg A: Ordliste...91 Vedlegg B: Tematisk satningsområde IKT...94 Vedlegg C: Felles Studentdatasystem...96 vi Forstudie

47 Figuroversikt Figuroversikt FIGUR 2-1 Organisasjonskart...26 FIGUR 2-2 Organisasjonskart over IME-fakultetet...27 FIGUR 3-1 Oversikt over det manuelle, papirbaserte systemet til IME...31 FIGUR 3-2 Tre separate manuelle arkiver...33 FIGUR 3-3 Flytdiagram over tilsettingsprosessen...36 FIGUR 3-4 Flytdiagram over generell saksgang i de administrative prosessene38 FIGUR 3-5 Kontrollflyt ved opptak på PhD-program...39 FIGUR 3-6 Avslutningsprosessen overordnet...42 FIGUR 3-7 Prosessen videre vurdering i figur 3-6 på side 42 dekomponert 43 FIGUR 3-8 Startside for PhD-informasjon på IME...44 FIGUR 3-9 Dagens manuelle skjemaer...46 FIGUR 5-1 Overordnet modell av systemet...58 FIGUR 5-2 Dekomponering av figur 5-1, vindu # FIGUR 5-3 Dekomponering av figur 5-1, vindu # FIGUR 5-4 Dekomponering av figur 5-1, vindu # FIGUR 5-5 Dekomponering av figur 5-1, vindu # FIGUR 6-1 ESB ved NTNU...64 FIGUR 6-2 Oversikt over de ulike applikasjonsdelene...67 FIGUR 6-3 Oversikt over delsystemene i en Pipe and filter -arkitektur...68 FIGUR 6-4 Oversikt over delsystemene i en objekt orientert arkitektur...68 FIGUR 6-5 Én-, to og tre-lags arkitektur...69 FIGUR 6-6 Sentralisert database...72 FIGUR 6-7 Distribuert database...73 FIGUR C-1 FS som infrastruktur for andre systemer...98 Forstudie vii

48 Figuroversikt viii Forstudie

49 Tabelloversikt Tabelloversikt TABELL 5-1 Oversikt over tilsettingsprosessen...55 TABELL 5-2 Oversikt over de administrative prosessene...55 TABELL 5-3 Oversikt over presentasjonsdel...57 TABELL 6-1 Evalueringskriterier...62 TABELL 6-2 Sammenligning av databasemodellene...73 TABELL 6-3 Sentrale egenskaper ved ulike programmeringsspråk...78 TABELL 6-4 Sentrale egenskaper ved ulike databasesystemer...78 TABELL 6-5 Lagdelte arkitekturer...79 TABELL 6-6 Vurdering ut fra evalueringskriteriene i tabell 6-1 på side TABELL 6-7 Sammenliknende vurdering av programmeringsspråk...83 TABELL 6-8 Sammenliknende vurdering av databasesystemer...84 Forstudie ix

50 Tabelloversikt x Forstudie

51 Innledning 1 Innledning Dette er forstudien til gruppe 9 i TDT4290 Kundestyrt prosjekt ved Institutt for datateknikk og informasjonsvitenskap ved NTNU. Prosjektets mål er å utvikle et system for administrasjon av stipendiater i organisert doktorgradsutdanning ved Fakultet for informasjonsteknologi, matematikk og elektroteknikk (IME). I denne rapporten vil vi først forklare bakgrunnen for prosjektoppgaven og se på situasjonen slik den er i dag. Denne oversikten vil innebære en modellering av arbeidsprosesser og rutiner ved IME-fakultetet i dag. Dernest vil vi kort beskrive andre eksisterende løsninger. Vi vil deretter forsøke å gi et bilde av kundens ønsker for systemet, og de krav og målsettinger dette gir. Dette vil ikke innebære en evaluering og forbedring av de aktuelle prosessene, men vil derimot fokusere på hvordan dagens arbeid kan automatiseres. Dette gjøres etter retningslinjer fra kunden. Vi vil så kartlegge de løsningsalternativene vi vurderer som aktuelle. Disse vil bli evaluert i henhold til kriterier satt opp på grunnlag av kundens ønsker og krav. Til slutt vil det vurderes hvilket løsningsalternativ som best tilfresstiller kriteriene vi har lagt til grunn.utover de tekniske alternativene vil dette valget også gjenspeile eventuelle avgrensninger av oppgaven for det videre arbeidet. Sentrale begreper er forklart i vedlegg A. Forstudie 25

52 Bakgrunn 2 Bakgrunn Oppdragsgiver for dette prosjektet, Fakultet for informasjonsteknologi, matematikk og elektronikk (IME), er ett av de syv fakultetene ved Norges teknisk-naturvitenskapelige universitet (NTNU). For å kunne forstå kundens problem bedre, gir vi en kort innføring i NTNUs struktur, IME-fakultetets forskning og philosophiae doctor-utdanningen (PhDutdanningen). Informasjons- og kommunikasjonsteknologi (IKT) er ett av NTNUs satsingsområder og viktig for kvalitetsnivået på datasystemene ved universitetet. Derfor vil vi ta for oss IKT og elektronisk saksbehandling til slutt i dette kapitlet. 2.1 NTNU NTNU ble opprettet og omdøpt i 1996, som en videreføring av Universitetet i Trondheim (UNiT), som bestod av Norges Tekniske Høyskole (NTH) og Den Allmenvitenskaplige Høgskolen (AVH). Universitetet består av syv fakulteter som igjen består av totalt 53 institutter, og rundt 3500 ansatte. Ca studenter studerer ved universitetet, og om lag halvparten av disse studentene er innenfor teknisk-naturvitenskapelige fag. NTNU uteksaminerer årlig om lag 2250 kandidater til høyere grader, profesjonsgrader og PhD-grader. Finansielt har NTNU sponsor- og samarbeidsavtaler med norsk og internasjonalt næringsliv og et årlig budsjett på ca. 2,8 milliarder kroner (NTNU, 2003) Organisasjonsstruktur NTNUs organisasjonsstruktur er vist i figur 2-1 på side 26. I tillegg til de syv fakultetene består NTNU blant annet av en Teknisk avdeling, en Økonomiavdeling og en Studieavdeling som har ansvar for hele universitetet. For dette prosjektet står Studieavdelingen sentralt fordi behandlingen av en PhD-søknad ved IME-fakultetet avhenger av denne avdelingen. Studieavdelingen består av Ledelse og stab Seksjon for fakultetsservice Seksjon for studentservice Seksjon for fjernundervisning, etter- og videreutdanning Internasjonal seksjon FIGUR 2-1 Organisasjonskart 26 Forstudie

53 Bakgrunn Studieavdelingen er en serviceavdeling overfor søkere, studenter, ferdige kandidater og fakultet/fagavdelinger. En del av denne servicen innebærer ansvar og brukerstøtte for blant annet Felles Studentsystem (FS), se vedlegg C. Det er Studieavdelingen sentralt ved NTNU som håndterer innleggelsen av nye studenter og ansatte i FS. Internasjonal seksjon godkjenner blant annet utdanningsbakgrunnen til utenlandske PhD-søkere, se kapittel 2.3 for nærmere informasjon om PhD-utdanningen. 2.2 IME-fakultetet IME-fakultetet ved NTNU har ansvar for forskning og undervisning i datateknikk og informasjonsvitenskap, elektronikk, energi og miljø, kommunikasjonsteknologi, matematikk, statistikk og teknisk kybernetikk. Fakultetet tilbyr en rekke studier innen teknologiske fag og realfag. Fullført og bestått studium innenfor teknologiutdanningen fører frem til graden Master i teknologi, som tilsvarer tittelen Sivilingeniør, mens fullført og bestått studium i realfag fører frem til graden Bachelor i vitenskap på lavere nivå og til graden Master i vitenskap på høyere nivå (IME, 2003). IME-fakultetets forskning skal være på et internasjonalt anerkjent nivå med faglige forbindelser til utenlandske universitet og institusjoner. Utvalg for forskning og forskerutdanning er et strategisk organ for utvikling av fakultetets forskning, og dette utvalget har ansvar for PhD-utdanningen. PhD-studentene er den viktigste ressursen i forskningen; de er et virkemiddel for NTNUs internasjonale samarbeid (IME, 2003) Organisasjonsstruktur Organisasjonstrukturen til fakultetet er vist i figur 2-2 på side 27. FIGUR 2-2 Organisasjonskart over IME-fakultetet Forstudie 27

54 Bakgrunn I likhet med NTNU sentralt, har IME-fakultetet en studieavdeling. Denne studieavdelingen er blant annet ansvarlig for det administrative ved PhD-prosessen, fra opptak til levert avhandling. De ansatte ved denne avdelingen har tilgang til FS og et manuelt arkiv over alle PhD-studentene. Studieavdelingen samarbeider tett med personalavdelingen i forbindelse med PhD-håndteringen. Personalavdelingen er ansvarlig for det administrative i forbindelse med alle ansatte ved IME-fakultetet, deriblant stipendiatene. Forskjellen mellom stipendiat og PhDstudent er forklart nærmere i kapittel PhD-utdanningen PhD-utdanningen fører frem til graden PhD. Formålet er å utdanne selvstendige forskere på internasjonalt nivå i samarbeid med nasjonale og internasjonale forskningsmiljøer. Finansiering av PhD-utdanningen skjer vanligvis ved tilstetting i en stipendiatstilling (Forskrift for PhD-utdanningen ved NTNU, 2003). PhD-utdanningen er normert til 3 års fulltidsstudium der minst ett av årene må skje ved NTNU. Maksimal studietid for PhD-utdanningen er 6 år fra opptak til innlevering av avhandlingen. Utdanningen består av en opplæringsdel og en forskningsdel som omfatter: Forskningsdel Gjennomføring av et selvstendig forskningsarbeid (PhD-prosjektet) i samarbeid med andre forskere Utarbeidelse av en PhD-avhandling på grunnlag av PhD-prosjektet Deltakelse i aktive forskermiljøer både nasjonalt og internasjonalt Faglig formidling, inkludert vitenskapelig publisering av PhD-prosjektet Opplæringsdel Opplæringsdelen skal ha et samlet omfang på minst 30 studiepoeng (der minst 20 av studiepoengene må være fra PhD-fag), tilsvarende et halvt års fulltidsstudium. PhD-studenten må få karakteren B eller bedre i emnene. I løpet av utdanningen, skal PhD-studenten årlig levere skriftlige rapporter til fakultetet om fremdrift i henhold til planen for utdanningen. For å kunne begynne på en PhD-utdanning ved NTNU, må følgende krav være tilfredsstilt: Mastergrad eller tilsvarende utdanning som er godkjent av fakultetet. Kandidatens utdanning må være relevant i forhold til PhD-programmet ved fakultetet. For nærmere beskrivelse av et PhD-program, se vedlegg A. Veid gjennomsnittskarakter de to siste årene av studiet lik B eller bedre. For gammel karakterskala, må gjennomsnittskarakteren de to siste årene av studiet være lik 2,5 eller bedre. Søkere med svakere karakterbakgrunn kan tas opp på PhD-program hvis det legges frem dokumentasjon på at søker er kvalifisert Forskjellen mellom en stipendiat og en PhD-student ved NTNU Vi vil her se kort på ulike begreper tilknyttet PhD-studiet og PhD-studenter. En stipendiat er ansatt, mens en PhD-student studerer ved et PhD-program på NTNU. PhDstudenter har mulighet til å finansiere sitt studium ved å være ansatt i en stipendiatstilling. Enkelte PhD-studenter er ikke stipendiater, men får studiet finansiert av en bedrift eller forskningsinstitusjon utenfor NTNU. Det finnes også stipendiatstillinger for ferdigutdannede PhDer, såkalte PostDoc-stipendiat, men disse vil vi ikke gå nærmere inn på her. 28 Forstudie

55 Bakgrunn Årsaken til at begrepene ofte kan blandes sammen, er at en PhD-student som oftest først ansettes i en stipendiatstilling, før han/hun søker opptak til et PhD-program. De fleste stipendiatstillingene har som krav at en slik søknad må være godkjent innen 6 måneder etter at studenten er tilsatt som stipendiat. 2.4 Informasjons- og kommunikasjonsteknologi NTNU satser på fagområdet Informasjons- og kommunikasjonsteknologi (IKT), og det er derfor viktig for kunden at vår systemløsning skal reflektere NTNUs ønskede kvalitetsnivå på dette området. IME-fakultetet står naturlig nok for en stor del av IKT-forskningen ved universitetet, og IKT er derfor en sentral del av fakultetets faglige profil. Vi ser at det er viktig å legge vekt på dette i og med at systemet vi skal lage skal presentere forskningen ved fakultetet. Forskningen må presenteres slik at fakultetet lettere kan rekruttere dyktige forskere og i større grad få oppmerksomhet fra potensielle finansieringskilder. Det er også fagmiljøenes ansvar å bidra til at erfaringene som kommer ut av IKT-prosjekter, blir tilgjengelige for hele universitetet. For å få innsikt i hva IKT innebærer og hva dette fokuset betyr for vårt prosjekt, har vi valgt å presentere hovedtrekkene i satsningsområdet i vedlegg B Elektronisk saksbehandling Et element innen IKT er elektronisk saksbehandling (ESB). Elektronisk saksbehandling er saksbehandling som utføres med støtte av informasjonsteknologi (IT). Støtten kan blant annet bestå av verktøy for å produsere elektroniske dokumenter, skanne papirdokumenter, dele dokumenter mellom saksbehandlere som har behov for å samarbeide, utveksle dokumenter, automatisk oppfølging av tidsfrister og elektronisk flyt av dokumenter i virksomhet. IT-støtten skal være gjennomgående i organisering og gjennomføring av saksbehandlingsprosessen, fra saken mottas og registreres til den avslutter. For mer informasjon om generell saksbehandling, se vedlegg B. Den elektroniske saksbehandlingen kan omfatte alt fra et lite utvalg funksjoner til en komplett elektronisk løsning for hele saksbehandlingsprosessen. Et saksbehandlingssystem kan omfatte enkle journalføringssystemer som gir støtte til registrering av all korrespondanse, mer omfattende dokumenthåndteringssystemer som fokuserer på dokumentet gjennom dets livssyklus eller et arbeidsflytsystem for selve saksbehandlingsprosessen (Statens generelle kravspesifikasjon, 1997). Forstudie 29

56 Dagens situasjon 3 Dagens situasjon Dette kapitlet vil gi en beskrivelse av dagens situasjon for å kunne sette leseren inn i problemstillingen som ligger til grunn for prosjektet. Vi vil beskrive nåværende system ved å gi en systembeskrivelse av prosessene som inngår i administrasjondelen oversikt over og evaluering av dagens presentasjonsdel For å kunne sette situasjonen i perspektiv vil vi deretter gjennomgå eksisterende løsninger som blir benyttet av andre, både ved de øvrige fakultetene ved NTNU og ved andre universiteter. 3.1 Beskrivelse av dagens administrative system Dagens system er preget av manuell saksbehandling, se figur 3-1 på side 31. Maler og dokumenter produseres elektronisk, men flyter manuelt i form av fysiske dokumenter mellom aktørene. De manuelle arkivene er en sentral del av den manuelle saksbehandling, og er en av de viktigste grunnene til at systemet er tungvint. Generelle ulemper ved manuelle arkiver: behovet for tidkrevende manuell distribusjon reell risiko for at dokumenter forsvinner dårligere muligheter for gjenbruk tungvint å loggføre aktiviteter fjern og treg tilgang til dokumenter Saksbehandling foregår hovedsaklig på institutt- og fakultetsnivå. De fleste manuelle prosesser er innom forskjellige ledd på disse to nivåene. IME-fakultetet har en studieavdeling og en personalavdeling. Studieavdelingen tar seg av saker som gjelder PhD-studiet, mens personalavdelingen har ansvaret for de ansatte på fakultet, deriblant stipendiatene. Studieavdelingen registrerer opplysninger om studentene i FS, mens personalavdelingen har en personaldatabase som inneholder alt som har med ansettelsesforholdene å gjøre. Instituttet tar seg av detaljsaker for PhD-studenter tilknyttet det aktuelle instituttet. Som oftest vil en person først søke stipendiatstilling hos fakultetet, deretter opptak til PhD-studiet og deretter være involvert i diverse administrative rutiner, før han/hun levererer og får godkjent sin avhandling. 30 Forstudie

57 Dagens situasjon FIGUR 3-1 Oversikt over det manuelle, papirbaserte systemet til IME Forklaring til figur 3-1: Figuren er hentet fra NTNU sin prosjektpresentasjon av ESB, (ESB (I), 2003). Forstudie 31

58 Dagens situasjon Studieavdelingen: ansvarlig for det administrative ved PhD-studiet, fra opptak til levert avhandling har 8 ansatte har arkiv over alle PhD-studentene har tilgang til FS har ikke tilgang til personaldatabasen Personalavdelingen: ansvarlig for det administrative vedrørende alle ansatte ved IME, deriblant stipendiatene har 6 ansatte har arkiv over alle IME-ansatte har tilgang til personaldatabasen har ikke tilgang til FS Dagens system er bygd opp slik at en PhD-student med stipendiatstilling ligger lagret i tre forskjellige manuelle arkiv. Arkivene er fordelt slik at ett befinner seg hos instituttet, ett hos personalavdelingen på fakultetet og ett på studieavdelingen på fakultetet. For nærmere beskrivelse se figur 3-2 på side Forstudie

59 Dagens situasjon FIGUR 3-2 Tre separate manuelle arkiver Institutt Arkiv over de PhD-studenter som tilhører dette instituttet IME-fakultetet Personalavdeling Arkiv over alle IME-ansatte Studieavdeling Arkiv over alle PhD-studentene Forklaring til figur 3-2: Her ser vi hvordan fakultet både har arkivert personalinformasjon og studentinformasjon. Denne informasjonen er overlappende for de som er tilsatt som stipendiater. Instittutet har ofte lagret overlappende og ofte mer utfyllende informasjon i forhold til det man finner på fakultetsnivå Forstudie 33

60 Dagens situasjon Svakheter og ulemper ved å ha tre separate arkiv i systemet: Fører til lang saksbehandlingstid grunnet ressurs- og tidkrevende dokumentflyt mellom avdelingene Hindrer/vanskeliggjør et samspill mellom de forskjellige administrative prosessene Fare for inkonsistens Dårlig tilgjengelighet for de aktuelle aktørene Dårlig lagringsstruktur og mye dobbeltlagring Eksistensen til de tre arkivene gjør at opplysninger må registreres flere ganger. Dette øker arbeidsmengden for både interne og eksterne aktører. For eksempel må en søker til en stipendiatstilling først sende opplysninger, som ved eventuell ansettelse, lagres hos personalavdelingen. Søkeren må deretter gjenta de samme opplysningene ovenfor studieavdelingen. Dette skaper unødvendig arbeid både for søker og for de to avdelinger som manuelt må registrere nesten identisk informasjon. Alle PhD-studenter, og i praksis alle stipendiater, ligger etter godkjent opptak til studiet lagret i FS. Det er studieavdelingen sentralt ved NTNU som må autorisere nye studenter i FS. De legger inn grunnleggende personlige opplysninger som personnummer, studienummer et cetera. Derfor må studieavdelingen ved fakultetet etter å ha mottatt personalia fra en person, sende en e-post til FS-gruppen sentralt for å få registrert denne personen. Deretter kan studieavdelingen ved fakultetet overta administrasjonen av persondataene. Alle administrative prosesser og rutiner kjennetegnes ved at de følger fakultetets kvalitetsikringssystem. Dette systemet går i hovedtrekk ut på at alle saker skal gjennom alle deler av organisasjonen før en beslutning blir tatt. En noe forenklet og generell saksgang: 1. Instituttet, eller en form for komité på instituttnivå, utarbeider en innstilling 2. Denne innstilingen tas videre til fakultetsnivå hvor den blir behandlet 3. Fakultetet anmoder et utvalg om å ta en beslutning For nærmere beskrivelse av alle prosesser se kapittel 3.2 og kapittel Forstudie

61 Dagens situasjon 3.2 Tilsetting av stipendiater Her går vi gjennom hva som skjer i dagens system når en søker blir tilsatt i stipendiatstilling ved IME-fakultetet på NTNU. Tilsettingsprosessen foregår stegvis som følger: 1. Instituttet sender brev til fakultetet med informasjon om utlysningen. 2. Fakultetet lager annonse ut fra standard utlysningstekst, minimum 14 dagers søknadsfrist. 3. Fakultetet annonserer i Nettopp, aviser og tidsskrifter samt på IMEs websider. 4. Fakultetet mottar søknader pr brev eller mail. 5. Fakultetet registrerer i mottaksprotokoll. 6. Fakultetet lager adresseliste over søkerne. 7. Fakultetet bekrefter mottak av søknader pr brev. 8. Fakultetet lager søkerliste, som kun på forespørsel distribueres til søkerne. 9. Fakultetet sender brev til instituttet sammen med søknader, søkerliste, kunngjøringstekst og retningslinjer for ansettelse av stipendiater. 10.Institutt gjør utvelgelse og intervju. 11.Rådgivende komité ved instituttet lager innstilling som godkjennes av instituttleder. 12.Instituttet sender innstillingen fra fakultetet. 13.Fakultetet lager saksfremlegg til tilsettingsutvalget på vegne av fakultetsdirektøren. 14.Tilsettingsutvalget behandler saken. 15.Tilsettingsutvalget sender protokoll til fakultetet ved saksbehandler. 16.Fakultetet sender tilbudsbrev med arbeidsavtale til kandidaten. 17.Fakultetet sender kopi av aksptert arbeidsavtale, eventuelt negativt svar, til instituttet. 18.Instituttet tar over og følger opp kandidaten, avtaler tiltredelse et cetera. 19.Instituttet via fakultetet sender melding til lønnsavdelingen. 20.Fakultetet sender ut "avslagsbrev" til de øvrige søkerne. I figur 3-3 på side 36 vises kontrollflyten for tilsettingsprosessen ved hjelp av et flytdiagram. Forstudie 35

62 Dagens situasjon FIGUR 3-3 Flytdiagram over tilsettingsprosessen Forklaring til figur 3-3: Figuren viser kontrollflyt for tilsettingsprosessen 36 Forstudie

63 Dagens situasjon 3.3 Administrasjon av PhD-studiet I dette avsnittet tar vi for oss de viktigste prosessene som finner sted etter at en person er tilsatt i stipendiatstilling. Dette vil i praksis være innlevering av fremdriftsrapport og forskjellige former for søknader, blant annet om opptak til PhD-program, endring av fag under opplæringsdel og permisjon/forlenget studietid. Likhetstrekkene i saksgangen til disse prosessene er illustrert i figur 3-4 på side Opptak Opptak av student til PhD-program skjer på følgende måte: 1. Stipendiat utarbeider søknad med vedlegg 2. Hovedveileder påtegner søknaden 3. En gruppe personer ved instituttet, ofte kun FU-medlem fra instituttet, vurderer søknad 4. FU-medlem fra instituttet påtegner søknad 5. Instituttleder vurderer søknad 6. Instituttleder påtegner søknad 7. Fakultetsadministrasjonen kontrollerer opplysninger i søknaden 8. Hvis søker er utenlandsk går søknaden til internasjonal seksjon 9. Forskingsutvalget behandler søknaden og fatter et vedtak. Dersom søknaden ikke blir godkjent vil utvalget komme med endringsforslag 10.Fakultetsadministrasjonen mottar vedtak fra Forskningsutvalget 11.Fakultetsadministrasjon sender opptaksbrev og avtaletekst til stipendiat. Kopi av opptaksbrevet sendes til institutt og hovedveileder 12.Fakultetsadministrasjonen registrerer tilgjengelige data i FS I figur 3-5 på side 39 vises kontrollflyten for opptak på PhD-program ved hjelp av et flytdiagram Søknad om å endre fag under opplæringsdelen En PhD-student kan søke om å endre emner fra opplæringsdelen. Dette kan for eksempel være fordi PhD-studentens arbeid og/eller oppgave har utviklet seg i en annen retning enn først antatt. Søkeprosessen for å endre fag under opplæringsdel er som følger: 1. Stipendiat og hovedveileder utarbeider søknad om endring av opplæringsdelen 2. Søknaden sendes til instituttet 3. Instituttet påtegner søknaden og sender den til fakultetet 4. Fakultet sender den til Forskningsutvalget 5. Leder av forskningsutvalget avgjør om søknaden skal godkjennes eller ikke 6. Opplysninger lagres i FS 7. Stipendiaten får svar på søknaden Søknad om endring av eksamenstidspunkt under opplæringsdelen Det er mulig å levere søknad for endring av dato på eksamen under opplæringsdel. 1. PhD-student fyller ut søknad. 2. Institutt mottar og påtegner søknad. 3. Fakultet mottar og behandler søknad. Forstudie 37

64 Dagens situasjon FIGUR 3-4 Flytdiagram over generell saksgang i de administrative prosessene Forklaring til figur 3-4: Figuren viser likhetstrekk ved måten administrative saker blir behandlet. FU - forskningsutvalget ved IME-fakultetet - er nærmere forklart i vedlegg A. 38 Forstudie

65 Dagens situasjon FIGUR 3-5 Kontrollflyt ved opptak på PhD-program Forklaring til figur 3-5: Figuren viser hvordan stipendiater ved IME-fakultetet blir tatt opp på PhD-program Forstudie 39

66 Dagens situasjon 4. PhD-student mottar svar via instituttet Innlevering av årlig fremdriftsrapport Hvert år må PhD-studenter levere fremdriftsrapport for å vise progresjonen i arbeidet sitt. I spesielle tilfeller vil ad-hoc tiltak være nødvendig, dette er ikke tatt med i påfølgende liste. 1. PhD-student og veileder utarbeider hver sin fremdriftsrapport. 2. Institutt mottar og påtegner fremdriftsrapportene. 3. Fakultet mottar og gjennomgår rapportene, innhold tas til etteretning Søknad om permisjon/forlenget studietid En PhD-student kan søke om permisjon fra studiet og fra stilling. 1. Stipendiat utarbeider søknad sammen med hovedveileder 2. Stipendiat sender en søknad til arbeidsgiver(ime-fakultet for stipendiater) for permisjon fra stilling 3. Stipendiat sender søknad om permisjon fra studiet til insituttet 4. Instituttet anbefaler/anbefaler ikke 5. Søknaden sendes videre til fakultetet (forskningsutvalget og fakultetsadministrasjonen) 6. Leder av forskningsutvalget behandler saken og sender svar til søkeren Avslutning Her vil prosessen for avslutningen av PhD-studiet bli gjennomgått. Prosessen starter ved at en PhD-student sender søknad om å få avhandlingen bedømt, og vil i normaltilfellet ende med at PhD-studenten får tildelt graden philosophiae doctor (PhD). Avslutningsprosessen til PhD-studiet er en del av kvalitetssikringen IME-fakultetet har på sine forskerutdanninger. IME-fakultetet skriver følgende på dagens nettsider: Formelle forhold og frister ved avslutningen av studiet skal sikre at utdanningen ved NTNU holder anerkjent internasjonal kvalitet. De skal også bidra til at hvert enkelt doktorgradsarbeid blir kjent i allmennheten og i det internasjonale fagmiljø på feltet. Avslutning av PhD-studiet i normaltilfellet: 1. PhD-student sender søknad om bedømmelse av avhandling til instituttet 2. Instituttet sender brev til fakultetet med søknad og forslag til bedømmelseskomite 3. Fakultetet mottar brev med vedlagt søknad og oppnevner bedømmelseskomite 4. Institutt sender avhandlingen til bedømmelseskomitéen 5. Bedømmelseskomitéen avgir felles begrunnet innstilling som oversendes fakultetet og PhD-studenten 6. Fakultetet mottar innstilling fra bedømmelseskomite og slutter seg til vedtaket. 7. Bedømmelseskomiteen bestemmer tema for prøveforelesning 8. Bedømmelseskomiteen vurderer og godkjenner prøveforelesningen 9. PhD-student forsvarer avhandlingen i en offentlig disputas 10.Bedømmelseskomite sender begrunnet innberetning til fakultetet med vurdering av prøveforelesning, avhandling og forsvar av avhandling 11.Fakultetet avgjør etter tilrådning fra bedømmelseskomiteen om PhD-studenten skal tildeles graden philosophiae doctor (PhD) 40 Forstudie

67 Dagens situasjon Avslutningen av PhD-studiet følger i de fleste tilfeller punktlisten ovenfor. I enkelte tilfeller kan deler av avslutningsprosessen bli underkjent. I figur 3-6 på side 42 ser vi kontrollflyten både når fakultet/institutt/bedømmelseskomite godkjenner og når de ikke godkjenner PhDstudentens arbeider. En av prosessene i denne er videre dekomponert i figur 3-7 på side 43. Forstudie 41

68 Dagens situasjon FIGUR 3-6 Avslutningsprosessen overordnet Forklaring til figur 3-6: Modellert kontrollflyt av avslutningsprosessen 42 Forstudie

69 Dagens situasjon FIGUR 3-7 Prosessen videre vurdering i figur 3-6 på side 42 dekomponert Forklaring til figur 3-7: Figuren viser kontrollflyten i tilfellet hvor bedømmelseskomitéen ikke avgir en enstemmig innstilling til kandidatens avhandling. Forstudie 43

70 Dagens situasjon 3.4 Dagens presentasjonsdel Vi vil her i korte trekk beskrive hvordan IME-fakultetet presenterer PhD-utdanningen sin i dag. Deretter vil vi vurdere dette, hovedsaklig ut fra kriterier for brukervennlighet Beskrivelse Den eksisterende presentasjonen av stipendiater i organisert PhD-utdanning ved IME-fakultetet på NTNU fremgår av (IME (III), 2003) hvor startsiden vises i figur 3-8 på side 44. Disse sidene tar for seg hvordan doktorgradsprosessen generelt forløper, regler og forskrifter for doktorgradsutdanningen, samt søknadsskjemaer som må fylles ut og sendes pr post. Dagens presentasjon følger NTNU sin standard for nettsider, noe en ny presentasjon også må. FIGUR 3-8 Startside for PhD-informasjon på IME Forklaring til figur 3-8: Informasjon om PhD-studier ved IME-fakultetet (IME (III), 2003). 44 Forstudie

71 Dagens situasjon Evaluering IME-fakultetet sine nåværende websider for rekruttering av stipendiater viser hva som møter potensielle søkere. En potensiell søker har følgende valg for videre navigering: 1. Studiehåndbøker 2. Start 3. Gjennomføring 4. Avslutning 5. Etter studiet 6. Forskerskolen 7. Nye dr.studenter 8. Avlagte grader 9. Finansieringskilder 10.Lover og regler 11.Skjema Store deler av dagens presentasjon går ut på å informere om hvordan PhD-prosessen forløper. Som vist i figur 3-8 på side 44 finnes det fra startsiden lenker til nettsider om start, gjennomføring og avslutning av studiet. Disse nettsidene inneholder mye informasjon uten at det finnes en god flyt i forklaringen av de forskjellige prosessene. Lenker forekommer her ofte innimellom annen informasjon og gir referanser til forskjellige forskrifter,søknader og lignende. Samme lenker brukes ofte flere steder og medfører en rotete struktur som gjør det vanskelig å navigere seg til den mest relevante informasjonen. Det er vanskelig å se ut fra menyen på startsiden hvor forskjellig informasjon befinner seg. I figur 3-9 på side 46 vises det hvordan IME-fakultetet har forsøkt å samle alle relevante dokumenter og gjort dem digitale. Her brukes en matrise til å representere forskjellige digitale dokumenter i forskjellige formater til nedlasting. Noen av dokumentene er også tilgjengelige på engelsk/nynorsk. Mange av disse skjemaene er også referert med lenker andre steder i presentasjonen. Informasjonen om de forskjellige doktorgradstudentene inneholder kun studentens navn, arbeidstittel for avhandling og hovedveileder. Presentasjonsformen er en liste, noe som gjør det vanskelig å identifisere personer og fagområder. Det finnes mange svakheter med hvordan IME-fakultetet presenterer PhD-studiet. Systemet har ikke god nok struktur, og det er vanskelig å finne relevant informasjon. Samme type informasjon gjengis ofte flere steder, noe som har ført til inkonsistens. Hovedproblemene med dagens system for presentasjon er: Vanskelig å se ut fra startsiden hvor relevant informasjon befinner seg Samme type informasjon gjengis flere steder, medfører mer kompleks navigering enn nødvendig Dokumenter er ikke oppdaterte med nyeste revisjon Lenker er ikke oppdatert, døde lenker Lite vekt på presentasjon av dagens PhD-studenter og avlagte avhandlinger Forstudie 45

72 Dagens situasjon FIGUR 3-9 Dagens manuelle skjemaer Forklaring til figur 3-9: Dagens manuelle skjemaer (IME (III), 2003) 46 Forstudie

73 Dagens situasjon 3.5 Eksisterende løsninger Vi vil her presentere benyttede løsninger for å presentere PhD-studier og administrere PhDstudenter ved andre institusjoner Presentasjondel Andre universiteter har tatt i bruk ulike løsninger for å presentere PhD-studiene sine. De fleste har som fellestrekk at informasjonen presenteres i form av mer eller mindre avanserte HTMLdokumenter. Løsningene skiller seg lite fra hverandre. Det blir gjort mye bruk av enkle menysystemer hvor man kan navigere seg frem til sider hvor PhD-program og PhD-studenter blir presentert. Enkelte universiteter har vært mer kreative og bruker blant annet følgende i sin presentasjon: Guidet tur over universitetsområde som inneholder bilder og tekst Bildeserier 360 graders panoramabilde over universitetsområde Virtuell tur hvor video brukes ved presentasjon av universitet/fagmiljø Lydklipp med nyheter fra universitetsmiljøet/studenters uttalelser om forskjellige tema Administrasjonsdel Vi vil her se på ulike implementerte løsninger for administrasjonsdelen. Flertallet av universiteter og fakulteter har ikke engang elektroniske søknader. Derimot tilbyr nær sagt alle søknadsskjemaer som kan lastes ned og skrives ut. De universiteter som har elektroniske søknadsskjemaer ser ut til å ha et system som gjør at disse er direkte koblet opp imot saksbehandlingssystemet. Hvis søknadene mottas manuelt, må en saksbehandler registrere søknadene i systemet. Det finnes en rekke saksbehandlingssystemer på markedet. Disse systemene er mer eller mindre komplekse. For eksempel benytter Universitetet i Tromsø seg av systemet DocuLive for å håndtere elektronisk saksbehandling (UiT DocuLive, 2003), gjennom blant annet å administrere organisasjonens dokumenter. Gjennom DocuLive registreres og fulltekstlagres arkivverdige dokumenter i en database for hele universitetet. Brukerne/ansatte har dermed, gjennom systemets søkefunksjoner, tilgang til hele universitetets arkiv/journal fra egen PC. Et annet populært verktøy er Kontor Med Kontor 2000 er IBM en av markedslederne innen løsninger som ivaretar kvalitetssikring ifm. den administrative produksjonsprosess innen offentlig sektor i Norge (Kontor2000, 2003). Kontor 2000 er en komplett løsning for dokument/arkiv, saksbehandling og utvalgsbehandling som tilfredsstiller den offentlige standard for EDB-baserte sak/arkivsystemer. Cirka halvparten av landets fylkeskommuner bruker dette systemet som dokument/arkivsystem. De fleste av disse store systemene er bygget opp modulært. Byggeklossprinsippet gir mulighet for at den enkelte organisasjon kan plukke ut de deler av systemet som man ser størst nytte av. Uansett hvordan man setter sammen systemet, hvilke moduler man velger å kjøpe / ta i bruk utover "basis-pakken", så får man da et sett med samspillende fagapplikasjoner som vil støtte opp om organisasjonens virksomhet. En modul som ville være viktig i et system for administrasjon av PhD-studenter og stipendiater, er en modul som støtter saksgang. De fleste prosessene er knyttet til en standardisert og forhåndsdefinert dokumentflyt. Ved å implementere en modul for saksgang, øker muligheten til å styre og få oversikt over saksbehandlingen i organisasjonen. Modulen blir Forstudie 47

74 Dagens situasjon et viktig hjelpemiddel for å oppnå målsettingen om å frigjøre ressurser fra rent administrativt rutinearbeid til fokus på serviceorienterte oppgaver. Kontor 2000 inneholder en egen modul for saksgang. Ifølge (Kontor2000, 2003) tilbyr modulen følgende funksjonalitet: Støtte til effektiv og korrekt saksbehandling Milepæler som er avhengige av hverandre Dokumentregistreringer kan knyttes til de enkelte milepæler Saker vises i saksbehandlers innkurv Enkelt å endre en saksgang Saksmaler De systemene som vi nå har beskrevet, brukes i større eller mindre grad rundt omkring i det offentlige Norge. En av hovedutfordringene ved å få til en maksimal utnyttelse av systemene ligger i at informasjon kun skal legges inn en gang. Hvis en ekstern aktør, for eksempel i en søknadsprosess, legger inn sine opplysninger direkte eller via en portal til systemet, vil en første saksbehandler i den aktuelle organisasjonen slippe å manuelt legge inn opplysningene i saksbehandlingssystemet. For administrasjon av PhD-studier og stipendiatstillinger vil det være aktuelt å lage elektroniske skjemaer på web som sikrer denne effektiviseringen. 48 Forstudie

75 Ønsket situasjon 4 Ønsket situasjon IME har en god faglig situasjon, på enkelte områder i verdensklasse, men føler ikke at det er samsvar mellom det faglige nivået og profileringen av forskningen. Det er særlig på dr.gradsnivå hvor dette er et problem. IME ser behov for en bedre profilering for å rekruttere kandidater med tilsvarende faglige kvaliteter. IME ønsker også å utnytte mulighetene i et automatisert system for å forenkle prosessene rundt administrasjon av dr.gradsstudier. I det følgende kommer en beskrivelse av hvordan IME ser for seg systemet med sine ønsker og mål for hvordan det skal fungere. Vi vil også belyse hvilke brukergrupper som er aktuelle, da det er disse gruppene som setter en standard for kravene som stilles til funksjonalitet og brukervennlighet. Til slutt vil vi se på utfordringer og muligheter knyttet til systemets integrasjon med andre informasjonssystemer og spesielle teknologiske ønsker. 4.1 Beskrivelse av ønsket løsning På samme måte som i kapittel 3 der dagens situasjon blir beskrevet i to deler; presentasjonsdelen og den administrative delen, vil kundens ønsker også bli gjenomgått i én presentasjons- og én administrasjonsdel Presentasjonsdel IME ønsker å presentere forskningsarbeidet og PhD-studentene på Internet, på norsk og engelsk, med høy grafisk og innholdsmessig kvalitet. Det er viktig for kunden at profileringen av IME-fakultetet og PhD-studiet hos dem fremstår som seriøs og profesjonell, samtidig som presentasjonen skal være fengende og interessant for aktuelle søkere. På denne måten håper fakultetet på å få økt antall aktuelle søkere og lettere få knyttet til seg dyktige forskere. Det er et ønske at den faglige aktiviteten i utdanningen skal bli mer synlig for et internasjonalt fagmiljø, noe som er viktig for fakultetet. Per i dag er 50 % av de nåværende stipendiatene fra utlandet. Kunden er opptatt av å lettere kunne danne seg et inntrykk av utenlandske studenter ut fra søknaden, og det vil derfor bli aktuelt å analysere muligheten for bruk av nye teknologiske verktøy og virkemidler i forhold til hva som finnes der i dag. En mulighet de ser for seg er bruk av video på nettsidene. Dette er både for å kunne legge ut en mer levende fremstilling av byen Trondheim med universitetet som arbeidsplass, men også legge video som en del av søknadene som kommer inn Administrasjonsdel Kunden ønsker seg et elektronisk saksbehandlingssystem (ESB) som erstatning for det manuelle, arkivbaserte systemet som finnes i dag. Et saksbehandlingssystem er, slik det er definert av Statskonsult i deres Elektronisk saksbehandling - Statens generelle kravspesifikasjon, -en prosess som utføres for å behandle saker på vegne av en virksomhet og som leder fra til en autorisert beslutning. Prosessen kan bestå av følgende aktiviteter: mottak og klargjøring av en sak, innsamlig av informasjon, vurdering, avgjørelse/vedtak, ekspedering av vedtaksdokumenter (SGK, 2003). Det er mange fordeler ved å velge å legge om til elektronisk saksbehandling. De viktigste av disse er: Økt effektivitet gjennom forenkling av arbeidsoppgaver og tids- og ressursbesparelser Kvalitetssikring Klarhet i ansvar for rutiner og prosesser Forstudie 49

76 Ønsket situasjon Ved å automatisere de prosessene som finnes ved fakultetet, og gjøre all saksbehandling elektronisk vil alle fordelene listet ovenfor kunne gjøre seg gjeldende. Innføring av ESB i vårt tilfelle vil kunne forenkle arbeidssituasjonen til de ansatte ved studie- og personalavdelingen ved IME-fakultetet. Dette henger igjen sammen med punktet om tidsbesparelse, da en slik forenkling av den daglige arbeidssituasjonen til IME-ansatte vil føre til en stor tidsparelse for dem. Tidsbesparing er selvsagt ressursbesparende for fakultetet, en vil kunne benytte ressursene til de som sitter med administrative oppgaver på andre områder. Kunden anser besparingspotensialet innen administrasjon av PhD-studenter til minst 50%. I dette inngår å integrere alle administrative rutiner og automatisere disse så mye som mulig, noe som vil virke effektiviserende på fakultetets administrative arbeid og derigjennom senke behandlingstiden. Det er her viktig å få til et samspill mellom hovedprosessene i systemet, hovedsakelig tilsetting- og doktorgradsprosessen. Det er også et mål at driften av systemet skal være lite arbeidskrevende, noe som også fører til økt effektivitet. Et elektronisk saksbehandlingssystem vil være med på å sikre kvaliteten på prosessene som foregår. Det vil også sikre gangen i saksbehandlingen, og at de riktige personene får den korrekte tilgangen til de dokumentene de skal. Alle hendelser og operasjoner som gjøres bør bli logget slik at en alltid kan gå tilbake og se hvem som har gjort hva i løpet av en saksgang. Denne sikkerheten i saksgangen vil hjelpe til å gi klarhet i ansvar for rutiner og prosesser. 4.2 Brukergrupper Det er viktig å analysere hvilke brukergrupper som er aktuelle. Disse vil være med på å sette rammebetingelser for hvordan systemet skal utformes og hvilke behov man skal vektlegge. Hvem som skal bruke ulike deler av systemet vil også bestemme hvilket brukergrensesnitt en bør velge, et valg som bør tas etter en vurdering av de ulike brukergruppenes erfaring med databehandling og elektroniske systemer, eventuelt også hvilke ønsker de måtte ha. Administrasjonsgruppen: Ansatte ved IME-fakultetet: Denne gruppen vil i hovedsak være delt i to hovedgrupper; studieavdelingen og personalavdelingen. Studieavdelingen tar seg av det administrative rundt søke- og tilsettingsprosessen, mens personalavdelingen sitter på all informasjon som er lagret om de ansatte ved fakultetet. Studieavdelingen har tilgang til Felles Studentdatasystem (FS), og kan legge inn og endre informasjon her, noe personalavdelingen ikke har mulighet til. Det er de ansatte ved fakultetet som utgjør brukergruppen som skal benytte seg mest av den administrative delen av systemet. Det er derfor viktig å se på deres arbeidsrutiner og behov slik de er i dag, og dermed legge til rette for at de samme behovene blir dekket, men med en effektivisering og forenkling av rutinene. Med tanke på brukergrensesnittet til denne gruppen bør det være enkelt og intuitivt med god oversikt over hva den enkelte har tilgang til og bruk for. Det er viktig å ta i betrakting at denne brukergruppen mest sannsynlig vil være den som bruker systemet mest, og dermed etter en tid bli godt kjent med det. Det vil da være aktuelt å lage enkelte snarveier for rutinerte brukerne som ønsker enda mer effektive måter å jobbe på. Ansatte ved instituttene: Det er her de faglige vurderinger og innstillinger gjøres, men alle beslutninger og kommunikasjonen ut til studentene foregår via fakultetet. Hvordan denne gruppen påvirker modelleringen av systemet vil i stor grad være det samme som for de ansatte ved IME-fakultetet. Forskjellen ligger i at disse brukerne nok ikke vil benytte seg av systemet like hyppig, og det vil derfor sette noe større krav til intiutivitet i systemet. 50 Forstudie

77 Ønsket situasjon Veiledere: Veilederne trenger tilgang til systemet for å legge inn og lese fremdriftsrapporter, gi uttalelse om studenter ol. Denne brukergruppen vil som oftest være ansatt ved instituttene, og ha de samme kravene og ønskene til systemet som de andre ansatte ved instituttene. Søkere til stipendiatstillinger (for nærmere forklaring av begrep se vedlegg A): Denne gruppen skal ha tilgang til oversiktelig informasjon via Internet, og kunne logge seg på for å levere søknad og senere følge med på saksgangen. Søkere til PhD-program (for nærmere forklaring av begrep se vedlegg A): Publikum: Disse kan være allerede tilsatte til stipendiatstillinger, eventuelt helt utenifra (mao på lik linje med søkere til stipendiatstillinger). Publikum er brukere av Internet som er ute etter informasjon vedrørende IMEfakultetet sin forskning. 4.3 Felles Studentdatasystem Kunden ønsker å ha et elektronisk saksbehandlingssystem integrert med Felles Studentdatasystem (FS). FS er beskrevet nærmere i vedlegg C. For å kunne integrere FS og systemet, gjennom å lage et grensesnitt mot FS, må vi se på forskjellige forhold ved de to systemene (FS, 2003): Deling av informasjon Noe informasjon behøves i begge systemene Informasjonen skal bare legges inn ett sted Informasjonen oppdateres i ett system, men må reflekteres i begge Informasjon må overføres mellom de to systemene All informasjonen må eies av kun ett av systemene Kvaliteten på informasjonen Informasjonen må finnes i minst ett av systemene Informasjonen må være korrekt Oversikt over hvor informasjonen brukes kreves Konsistente begrep i de to systemene er nødvendig I tillegg må man ta hensyn til at FS er integrert med andre systemer som blant annet Samordna Opptak og Lånekassen. Sikkerheten ved bruk av FS er også et viktig aspekt som må tas med i betraktning ved integrering mot FS. 4.4 Teknologiønsker Kunden har gjennom diskusjon kommet inn på ulike teknologiske løsninger som er ønsket implementert i et ferdig produkt. Vi har valgt å se nærmere på to av disse løsningene. Disse vil bli presentert og diskutert i dette kapitlet SMS - Short Message Service Bruk av SMS-tjenester i web-baserte applikasjoner har i tråd med utviklingen og tilgjengligheten blitt mer og mer vanlig. Dette er spesielt nyttig i applikasjoner hvor viktig informasjon skal ut til brukerne og hvor epost viser seg å ikke være tilstrekkelig. Eksempler på Forstudie 51

78 Ønsket situasjon dette kan være værvarsling, nyheter, aksjekurser, sportsresultater eller lignende. Et fellestrekk for disse tjenestene er at de alle representerer viktig informasjon for brukeren som ønskes mottatt også når brukeren ikke har en epost- eller nettleser tilgjengelig. Dette kan også være gjeldende for brukere av systemet vårt. Eksempler på slike tjenester kan være: Varsling om nye stipendiatstillinger til interesserte søkere Varsling om ny saksinformasjon til saksbehandlere Varsling av viktige datoer, tidsfrister eller lignende Svar på søknader Vi ser av eksemplene at informasjonsflyten med SMS i hovedsak går én vei, fra systemet til brukerene. Dette skyldes at inndataene ofte vil være mer omfattende og at en SMS-melding på 160 tegn ikke vil være tilstrekkelig for å fylle dette behovet. Implementasjon av SMS som en delløsning av systemet vil nødvendigvis ikke være noe stort problem, hverken teknisk eller økonomisk. Det finnes i dag flere eksisterende løsninger som kan benyttes og som er underlagt GPL - Gnu Public License. Et eksempel på dette er Gnokii (Gnokii, 2003). Gnokii kommuniserer med en mobiltelefon som er tilkoblet datamaskinen og benytter denne for å sende og motta SMS-meldinger. Løsningen baseres på en mysqldatabase og vil være enkel å implementere i systemet. Det er også mulig å opprette koblinger direkte mot mobiloperatører gjennom CPA-avtaler (Content Provider Access). Disse avtalene gir et HTTP-grensesnitt mot operatøren og tillater sending og mottak av for eksempel SMS. Det som skiller disse avtalene fra andre løsninger er at de ofte gir større teknologisk fleksibilitet, men til gjengjeld er de svært dyre i drift. De blir eksempelvis ofte benyttet i kommersielle tilfeller hvor systemet skal ha mulighet til å fakturere kunden for utsendelse av meldinger. Slik fakturering vil ikke være mulig med GPL-løsningen beskrevet i forrige avsnitt Videoteknologi Levering av video over nettet er blitt relativt vanlig, og mange websider inneholder i dag større eller mindre videoklipp. Denne teknologien er spesielt nyttig i web-applikasjoner der en ønsker å gi et virkelighetsnært bilde av en situasjon eller et sted. Eksempler på steder video blir brukt hyppig på Internet i dag er: Presentasjon av områder, bygninger, byer og arbeidsplasser Nyhetssendinger 360-graders visning av eiendom og bolig I alle tilfellene er det viktig for de som presenterer noe at det gir leseren et realistisk og virkelig bilde av situasjonen. Da video først ble tilgjengelig over nettet foregikk det meste ved at man lastet ned et antall filer og lagret disse på maskinen. I dag tilbyr de fleste web-sider heller videostrøm enn nedlasting av filer. Det som skjer da er at videofilmene ikke blir lagret på harddisk, men blir sendt til maskinens nettleser, i likhet med måten annet materiale fra websider blir behandlet på. Fordelen med dette er at en ikke trenger å vente på at hele filen er lastet ned, men kan begynne å se innholdet mens den er på vei til nettleseren. Man vil fortsatt ha behov for et hjelpeprogram, men disse er ofte integrert i nettlesere, eksempelvis Netscape Navigator, Opera og Internet Explorer. For å kunne vise video på Internet, må man i tillegg legge filene på en videoserver. En videoserver er enkelt sagt en kraftig datamaskin man legger videofiler på. Disse filene er som regel i formatene Real Video, QuickTime eller Windows Media Video. Kvaliteten på videofiler man kan se er i hovedsak avhengig av hvor stor båndbredde man er koplet opp med hvis man benytter videostrømmer, eventuelt hvor lenge 52 Forstudie

79 Ønsket situasjon man ønsker å vente dersom man laster ned videofilen. I tillegg vil hastigheten på videoserveren kunne være begrensende på antall samtidige brukere. Vi vil senere diskutere disse aspektene for å kunne vurdere muligheten for å støtte videoteknologi. Kunden ser for seg bruk av video på websidene i to ulike situasjoner: Presentasjon av Trondheim og NTNU som arbeidssted med en guidet tur i byen og på universitetet. Innsending av video sammen med søknaden med en presentasjon av søkeren. I det første tilfellet vil hensikten med å legge ut en slik presentasjon av byen og universitetet være å gi et bedre bilde av hva som venter en som ønsker å søke på en stipendiat- eller PhDstilling. Dette er spesielt viktig for søkere som bor langt unna Trondheim, for eksempel søkere fra utlandet. Teknisk sett vil dette ikke være noe problem. Videoen kan legges ut i det formatet en ønsker og tilrettelegges de mest vanlige nettleserne. I det andre tilfellet der en åpner for at søkere skal kunne sende inn en video av seg selv med i søknaden vil det være et større behov for tilpassing av formatet. Søkerne vil kunne sende inn videoer i ulike formater, og utfordingen blir å finne en måte å håndtere dem på og konvertere dem til et format som gjør dem lett tilgjengelig for de aktuelle mottakerne. Forstudie 53

80 Forretningsmessige krav 5 Forretningsmessige krav De ønsker som ble fremsatt i forrige kapittel vil gjennom de påfølgende avsnitt bli konkretisert. Vårt mål er her å komme frem til en oversikt over hvilken funksjonalitet det ønskede systemet skal ha, og derigjennom på et overordnet nivå vurdere hvordan IME-fakultetets ønsker kan tilfredsstilles. I kapittel 5.3 har vi forsøkt å illustrere disse kravene på en enkel og intuitiv måte. I kapittel 6 vil vi bruke disse kravene for å komme frem til alternative løsninger vi kan benytte. 5.1 Omfang Gjennom den påfølgende diskusjonen vil vi gi en oversikt over hva IME-fakultetet ønsker i form av overordnet funksjonalitet i det planlagte systemet. Dette omfatter blant annet arbeidsoppgaver og hvilke situasjoner systemet skal støtte. Det er i hovedsak to ulike behov som skal dekkes: Fakultetets arbeid for å administrere PhDstudenter og søkere til dette studiet, samt presentasjon av studentene, deres arbeider og fagmiljø på Internet. Systemet som ønskes utviklet skal gi støtte for å utføre de administrative oppgavene knyttet til behandling av PhD-studenter. En maksimal andel av administrative rutiner tilknyttet dette arbeidet søkes støttet, men enkelte rutiner vil det ikke være naturlig å inkludere støtte for. Som vi kan se av tabell 5-1 på side 55 og tabell 5-2 på side 55 kan disse rutinene deles opp i to hovedprosesser: Tilsetting og Administrasjon. Utover de administrative oppgavene skal også et rammeverk for den utadvendte presentasjonen av fakultetets stipendiater og PhD-studenter, samt deres pågående arbeid, utarbeides. En oversikt over delene i denne funksjonaliteten er gjengitt i tabell 5-3 på side 57. En nærmere beskrivelse og forklaring av tabellene nevnt ovenfor blir forklart i påfølgende kapittel Prosesser og funksjonalitet Her vil vi i nærmere detalj utdype de arbeidsprosessene som vil være en del av det ønskede systemet. Vi vil dessuten se på hvordan presentasjonen av PhD-utdanningen kan forbedres og integreres bedre med den administrative siden. Til slutt vil generelle krav til et fremtidig system omtales Administrative prosesser Som tabell 5-1 på side 55 og tabell 5-2 på side 55 viser, omfatter begrepet Administrative prosesser de fleste aspekter rundt tilsettingen og oppfølging av en stipendiat/phd-student. Disse aspektene er fra kundens synspunkt viktige å få implementert i en eventuell teknisk løsning, da mange av disse i hovedsak består av rutinemessige oppgaver og således har et stort arbeidsbesparende potensiale for kunden. De av prosessene som mer eller mindre er preget av ad-hoc-løsninger, vil følgelig ikke være like lett å implementere i en eventuell løsning. Vi vil likevel tilstrebe, i den grad det er mulig, å støtte disse prosessene. Dette gjelder eksemplevis behandling av klager, hvor utfallet av en klage ikke alltid resulterer i samme saksgang. 54 Forstudie

81 Forretningsmessige krav TABELL 5-1 Oversikt over tilsettingsprosessen Prosess Tilsettingsprosess Send utlysnings-info Lag annonse Behandling av søknad Motta søknad Lag adresseliste Lag søkerliste Bekreft mottak av søknader Send brev til instituttet Ansettelse Lag vurdering Intervju Lag innstilling Send innstilling Lag saksfremlegg Behandling av saken Send tilbudsbrev Motta bekreftelse på tilbud Send kopi av svar fra søker Send avslagsbrev TABELL 5-2 Oversikt over de administrative prosessene Prosess Administrasjonsprosess Opptak Søknad /godkjenning av PhD-program Opplæringsdel Søknad om å endre fag under opplæringsdelen Endring av eksamenstidspunkt Gjennomføring Innlevering av årlig fremdriftsrapport Søknad om permisjon Søknad om forlenget studietid Avslutning Søknad om å få avhandling bedømt og forslag til komitè Oppnevning av bedømmelseskomitè Tidlige praktiske forberedelser Forstudie 55

82 Forretningsmessige krav TABELL 5-2 Oversikt over de administrative prosessene Prosess Avtale tidspunkt med komiteen Reservere rom for disputas Reservere hotellrom for tilsreisende og liknende. Instillingsprosess Avlegging av innstilling fra bedømmelseskomiteen. PhD-kandidat gjør merknader til innstillingen Fakultetet behandler saken. Omarbeiding for ny bedømmelse Opplysning om disputasen Lage og sende pressemelding om disputasen Oppslag og annonsering Prøveforelesning og disputas Utsending av sensurskjema Vitnemål og diplom Klage Kandidater reg. sin avhandling i UMIs internasjonale database Presentasjonsdelen Som beskrevet i kapittel 4 ønsker kunden å styrke presentasjonen av fagmiljøene, forskningsarbeidet og PhD-studentene ved fakultetet. Løsningen skal være tilgjengelig via Internet og skal ha en høy grafisk og innholdsmessig kvalitet. Vi vil implementere dette som en del av den helhetlige løsningen, hvor mye av informasjonen som skal presenteres allerede ligger tilgjengelig, noe som vil sikre konsistente data. Denne presentasjonsdelen vil også være en naturlig inngangsportal for noen av de administrative prosessene som også skal implementeres, eksempelvis innsending av søknader til stipendiatstillinger. Under utviklingen skal brukervennlighet, struktur og design særlig vektlegges. Produktet vil være en del av fakultetets og universitetets markedsføring og må derfor være intuitivt og imøtekommende. Det er også viktig at løsningen blir presentert ikke bare på norsk, men også engelsk. En oversikt over elementer som skal presenteres er listet opp i tabell 5-3 på side Forstudie

83 Forretningsmessige krav TABELL 5-3 Oversikt over presentasjonsdel Elementer som skal presenteres PhD-studentene og deres fagområde, publikasjoner og artikler De ulike fagmiljøene ved fakultetet Prosjekt- og forskningsaktiviteter som PhD-studentene er involvert i Om PhD-studiet og hvilke muligheter som tilbys stipendiater Lover og retningslinjer for stipendiater og PhD-studiet Om fakultetet, satsningsområde og forskningsfelt Generelle krav Generelt for produktet kunden ønsker implementert finnes en del krav som må imøtekommes. Stabilitet og lite administrasjon er svært sentralt, og vil være avgjørende for at løsningen kan tas i bruk. Store administrasjonskostnader vil redusere gevinsten som oppnås ved å automatisere prosesser som i dag gjøres manuelt. Det er også et krav at data knyttet til den enkelte stipendiat/phd-student kun skal legges inn i systemet èn gang. For de øvrige prosessene skal denne informasjonen være tilgjengelig via et sentralt lager. Den informasjonen som av hensyn til personvern og praktiske årsaker ikke kan være en del av løsningens sentrale lager, skal hentes fra FS, se vedlegg C. Autentisering og brukerhåndtering skal skje gjennom Innsida, se vedlegg A, som tilbyr et generelt autentiseringsgrensesnitt for brukere ved NTNU. 5.3 Modellering av systemet Vi har i dette avsnittet valgt å illustrere de kravene som tidligere er nevnt i dette avsnittet. Modelleringen er gjort i den hensikt å illustrere overordnet funksjonalitet og krav, og vil således være mer et verktøy for forståelse enn en fullstendig modell. Vi ser i figur 5-1 en overordnet modell av CuraWeb, mens de ulike funksjonelle enhetene vi der markerer med nummer 1-4 er videre vist i mer detalj i figur 5-2, figur 5-3, figur 5-4 og figur 5-5. Forstudie 57

84 Forretningsmessige krav FIGUR 5-1 Overordnet modell av systemet Forklaring til figur 5-1: Fig. viser systemet som en helhet og er dekomponert i figur 5-2, figur 5-3, figur 5-4, og figur 5-5. FIGUR 5-2 Dekomponering av figur 5-1, vindu #1 Forklaring til figur 5-2: Viser deler av søkers initielle interaksjon med systemet. 58 Forstudie

85 Forretningsmessige krav FIGUR 5-3 Dekomponering av figur 5-1, vindu #2 Forklaring til figur 5-3: Viser ulike instansers interaksjon med systemet i forbindelse med stipendiaters søknadsprosess. Forstudie 59

86 Forretningsmessige krav FIGUR 5-4 Dekomponering av figur 5-1, vindu #3 Forklaring til figur 5-4: Viser ulike instansers interaksjon med systemet i forbindelse med en PhD-søknad. 60 Forstudie

87 Forretningsmessige krav FIGUR 5-5 Dekomponering av figur 5-1, vindu #4 Forklaring til figur 5-5: Viser en PhD-students interaksjon med systemet, og hvilke andre instanser som er involvert. Forstudie 61

88 Alternative løsninger 6 Alternative løsninger For å kunne oppnå den ønskede funksjonaliteten i systemet, på den mest hensiktsmessige måten og med størst tilfredstillelse av kundens ønsker, vil vi i dette kapitlet presentere og vurdere alternative måter å løse de utfordringene vi har gjennomgått i tidligere kapitler. I kapittel 6.1 vil vi etablere et sett med evalueringskriterier, som senere vil bli benyttet til å sammenlikne ulike alternativer. Kriteriene vil benyttes for å evaluere både de overordnede alternativene, og de arkitektoniske og tekniske mulighetene. En oversikt over området elektronisk saksbehandling, samt ulike måter å strukturere slike systemer på gis i kapittel 6.2. I kapittel 6.3 vurderer vi så disse mulighetene. Applikasjonsarkitekturer og databasearkitekturer presenteres på bakgrunn av denne innledende vurderingen. Dette er tema i henholdsvis kapittel 6.4 og kapittel 6.5. Tekniske løsninger blir lagt frem i kapittel 6.6, igjen med bakgrunn i vurderingen fra kapittel 6.3. Ulike arkitekturer vurderes sammen med alternative tekniske plattformer, herunder databaseløsninger og utviklingsplattform, i kapittel Evalueringskriterier For å kunne tilfredsstille de forretningsmessige kravene til systemet og for å kunne dekke kundens behov, trenger vi en rekke kriterier som kan brukes for å evaluere mulige løsninger. Evalueringskriteriene skal danne grunnlaget for hvilke løsninger som skal forkastes eller beholdes. Hvert evalueringskriterium består av et krav, en beskrivelse, en begrunnelse og en viktighetsgrad. Kriteriene våre er listet opp etter synkende viktighet i tabell 6-1 på side62. TABELL 6-1 Evalueringskriterier Krav Beskrivelse Begrunnelse Viktighet Teknologisk dekning Integrasjon Pris Portabilitet Brukervennlighet Kundens preferanse Teknologien som velges, må ha nødvendig funksjonalitet for å dekke produktets behov. Tekniske delløsninger må kunne integreres med andre delløsninger. Hvorvidt det er knyttet direkte kostnader til produktet. Teknologien som velges i presentasjonsdelen, må kunne brukes over alt i verden. Systemet må være intuitivt for bruker, dvs. enkelt å forstå og lett å bruke. Kundens ønsker og krav skal tilfredsstilles i den grad det er mulig. Produktet er avhengig av en fungerende implementasjon. Viktig for at system som helhet skal fungere tilfredsstillende. Kunde ønsker ikke merkostnader i forbindelse med tjener-programvare eller i forbindelse med utviklingen av systemet. Mange av PhD-søkerne til IME-fakultetet er utenlandske. Systemet skal brukes av personer med både teknisk og ikke-teknisk bakgrunn Systemløsningene skal i etterkant tilpasses/installeres på kundens systemer. Stor Stor Stor Stor Stor Stor 62 Forstudie

89 Alternative løsninger TABELL 6-1 Evalueringskriterier Krav Beskrivelse Begrunnelse Viktighet Vedlikehold Gjenbruk Pålitelighet Teknologien skal være enkel å vedlikeholde. Opplæringsbehov Skalerbarhet Gruppens preferanse Tilgjengelige løsninger som kan gjenbrukes bør benyttes. Teknologien som velges, må sikre systemets pålitelighet. I hvilken grad teknologien er kjent for gruppens medlemmer. Hele eller deler av systemet må kunne utvides. Gruppens preferanser vedrørende valg av teknologi basert på tidligere kunnskap og erfaringer. Vedlikehold er viktig dersom produktet skal videreutvikles. Utifra stort tidspress og sunn fornuft ser vi ikke poenget i å finne opp hjulet på nytt. Pålitelighet er viktig overfor både kunde og bruker. Stort tidspress gir lite rom for opplæring utover det som er strengt tatt nødvendig. Kjent teknologi er foretrukket. Viktig for at systemet skal fungere tilfredsstillende over tid. Gruppens tidligere erfaringer bør vektlegges. Middels Middels Middels Middels Liten Liten 6.2 Generelt om elektronisk saksbehandling Elektronisk saksbebehandling (ESB) gir mulighet for forenkling og effektivisering av manuell saksbehandling. NTNU definerer ESB som følger: Gjennomgående IT-støtte til organisering og gjennomføring av saksbehandlingsprosessen. Dette gjelder hele prosessen fra saken mottas og registreres til den avsluttes, herunder saksforberedelse og utferdigelse av eventuelt vedtak. (ESB (II), 2003) Flere offentlige institusjoner har utarbeidet egne program for ESB. NTNU bruker mye ressurser på å innføre ESB som alternativ til dagens saksbehandlingsprosess (ESB Direktørmøte, 2003), se forøvrig kapittel Ved innføring av ESB legges blant annet vekt på å oppnå følgende (ESB Kollegienotat, 2003): Elektronisk tilgang til alle dokumenter Større mulighet for gjenbruk av eksisterende dokumenter Reduksjon av antall manuelle arbeidsoppgaver knyttet til dokumentbehandlingen Forenklet søking og gjennfinning av dokumenter Full elektronisk saksbehandling forutsetter: Elektronisk arkiv Elektronisk signatur Elektronisk forsendelse av dokumenter Alternative løsninger for elektronisk saksbehandling: Skanning av dokumenter Forstudie 63

90 Alternative løsninger Web-applikasjon Distribusjon av data i form av CD-ROM Skanning av dokumenter Én ESB-løsning har som hovedidé å skanne alle inkommne dokumenter slik at disse finnes i digital form. Dokumentene kan deretter lagres og distribueres elektronisk. NTNU har i sitt program for ESB sett på muligheten for en slik løsning med skanning av dokumenter som deretter lagres i et elektronisk arkiv (ESB Prosjektdefinisjon, 2003). Saksbehandlere kan hente ut dokumenter via NTNUs intranett, se figur 6-1 på side 64. FIGUR 6-1 ESB ved NTNU Forklaring til figur 6-1: Figuren er hentet fra presentasjon av NTNU sitt ESB-prosjekt, (ESB (II), 2003). ESB ved skanning av dokumenter har følgende egenskaper: Data lagres som dokumenter, vanskelig å presentere informasjonen i andre sammenhenger og formater Noen grad av dobbeltlagring av informasjon Liten mulighet for å effektivt endre data i lagret dokument Mulighet for å differensiere adgangsnivået til lagret informasjon Store kostnader ved innføring av systemet 64 Forstudie