Dokumentstatus

System för
tidrapportering och tidplanering
Projektdokumentation
3 maj
2002
Sammanfattning
Detta är projektdokumentationen till projektet System för Tidrapportering & Tidplanering
(SYTT). Arbetet utförs inom ramarna för kursen 2D1954 Programutvecklingsprojekt vid
Institutionen för Numerisk Analys och Datalogi (NADA) vid Kungl. Tekniska Högskolan.
Projektet omfattar förstudie, lösningsbeskrivning samt utveckling, testning och
dokumentation av systemet. Uppdragsgivare är Henrik Artman, studierektor för IP-lab.
Projektgruppen består av 7 personer med olika roller i projektet.
Systemet är ämnat för IP-lab som är en avdelning på NADA där c:a 20 av Nadas totala c:a
100 doktorander arbetar. Bakgrund till uppdraget är studierektorns problem att ha översikt
och statistik över doktorandernas institutionstjänstgöring, vilket förhindrar proaktivt arbete.
Idag sker doktorandernas tidsrapportering manuellt och i slutet av året. Avdelningarna inom
NADA har olika rutiner för doktorandernas planering och rapportering, dessutom skiljer sig
rutinerna mellan olika lärare, kurser och doktorander.
Den lösningsbeskrivning, iteration nr fyra, som presenteras i dokumentet bygger på inmatning
av aktiviteter som kopplas till respektive kurs. Aktiviteter består av aktuellt moment (t.ex.
föreläsning, övning, laboration, handledning), datum eller datumperiod, ev. beskrivning samt
antal nedlagda timmar. Aktiviteter kan ha status av genomförd eller planerad, där de senare
enkelt kan överföras när de har genomförts. Systemet klarar av obegränsat antal år.
Användarna av systemet är indelade i tre roller beroende på användningsområde:
Doktorand planera/genomföra aktiviteter, översikt över nedlagt/planerat arbete, historik
Lärare
Se och planera aktiviteter för sina egna kurser, se doktoranders beläggning
Studierektor Administratör, översikt över doktorander och kurser, statistik, export av data
Den tekniska lösningen kan konceptuellt beskrivas som en trelagers webbapplikation, med
separation av datalagring (PostgreSQL), affärslogik (Java-servletts) och
presentation/interaktion (JSP-sidor).
Projektet har drivits som ett professionellt projekt med användarcentrerat fokus. Regelbunden
kontakt med användare och uppdragsgivare har varit central för att arbeta fram ett flexibelt
system som tillgodoser användarnas behov. Genom intervjuer, användartester och gruppens
arbete har lösningen genomgått fyra olika iterationssteg, från skissförslag till körbar prototyp.
Tidrapportering och projektavstämningar har skett kontinuerligt både internt inom gruppen
och externt med uppdragsgivaren. Beslut och beslutsunderlag har varit tillgängliga för
projektets medlemmar genom den löpande dokumentationen.
En noggrann genomgång av tänkbara risker tidigt i projektet resulterade i att många problem
har kunnat undvikas. Gruppens ambitionsnivå har dock lett till att arbetsbördan har varit
genomgående hög. Till följd av kursens ramar och projektets omfattning sattes en
prioriteringsordning i samråd med uppdragsgivaren. I utvecklingsfasen prioriterades bland
annat export-funktionaliteten bort.
Ett antal alternativa lösningar för att skapa en bra process för tidrapporteringen och
tidplaneringen har presenterats. För den framtagna lösningen har ett par olika
utvecklingsmöjligheter skisserats; implementation på övriga Nada, utöka målgruppen till att
inkludera laborationsassistenter och gästföreläsare eller att omvandla systemet till ett sök- och
bokningssystem för lärare och doktorander.
1
Innehållsförteckning
1
DOKUMENTSTATUS ................................................................................................................... 4
2
PROJEKTSTRUKTUR ................................................................................................................. 5
2.1
2.2
2.3
2.4
2.5
2.6
3
PROJEKTRAMAR ...................................................................................................................... 5
PROJEKTGRUPP ........................................................................................................................ 5
REFERENSGRUPP...................................................................................................................... 6
RESURSER ................................................................................................................................. 6
PROJEKTAVSLUT ...................................................................................................................... 6
PROJEKTGRUPPENS ÄGANDERÄTT ......................................................................................... 6
PROBLEMBESKRIVNING .......................................................................................................... 7
3.1
3.2
3.3
4
BAKGRUND ............................................................................................................................... 7
SYFTE ........................................................................................................................................ 8
ANVÄNDARE ............................................................................................................................. 8
PROJEKTHISTORIK ................................................................................................................... 9
4.1
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.3
4.4
4.5
4.6
4.7
5
LÖSNINGSBESKRIVNING ....................................................................................................... 15
5.1
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.3
5.3.1
5.3.2
6
ÖVERSIKT ................................................................................................................................. 9
ARBETSPRINCIPER ................................................................................................................... 9
ANVÄNDARCENTRERAT ..................................................................................................... 9
PROJEKTETS ARBETSFORM ................................................................................................ 9
RESURSTÄNKANDE .......................................................................................................... 10
DOKUMENTATION ............................................................................................................ 10
UTVECKLING .......................................................................................................................... 10
HISTORIK ................................................................................................................................ 10
EXTERNA MÖTEN ................................................................................................................... 13
PRIORITERING ........................................................................................................................ 14
RISK- OCH AVVIKELSEANALYS ............................................................................................. 14
ÖVERSIKT ............................................................................................................................... 15
TEKNISK LÖSNINGSBESKRIVNING......................................................................................... 15
GENERELLT ...................................................................................................................... 15
DATORMILJÖ .................................................................................................................... 15
DESIGNPARAMETRAR FÖR TEKNISK LÖSNING ................................................................. 15
TEKNISK LÖSNING............................................................................................................ 16
TEKNISK PLATTFORM....................................................................................................... 17
FUNKTIONSBESKRIVNING ...................................................................................................... 18
INLEDNING ....................................................................................................................... 18
ANVÄNDARGRÄNSSNITT .................................................................................................. 22
FRAMTIDA UTVECKLINGSMÖJLIGHETER ...................................................................... 29
2
6.1
6.2
6.2.1
6.2.2
6.2.3
6.2.4
6.3
6.4
6.4.1
6.4.2
6.4.3
INLEDNING.............................................................................................................................. 29
EJ IMPLEMENTERAD FUNKTIONALITET ............................................................................... 29
HJÄLPFUNKTIONALITET ................................................................................................... 29
EXPORT ............................................................................................................................ 29
HISTORIK ......................................................................................................................... 30
RESURS ............................................................................................................................ 31
UTVECKLINGSFÖRSLAG ........................................................................................................ 32
ALTERNATIVA LÖSNINGAR.................................................................................................... 32
FÖRÄNDRADE RUTINER ................................................................................................... 32
EXCEL .............................................................................................................................. 32
FÄRDIG DATABASLÖSNING .............................................................................................. 33
3
1 Dokumentstatus
Detta dokument är projektdokumentationen för System för Tidrapportering och Tidplanering,
nedan kallat SYTT.
Den totala dokumentationen är indelad i tre delar; användardokumentation,
systemdokumentation och projektdokumentation. Användardokumentationen är en
beskrivning och dokumentation av varje sida i gränssnittet och riktar sig till systemets
framtida användare. Systemdokumentationen beskriver hur systemet är uppbyggt tekniskt sett
och riktar sig till vidareutvecklare av systemet. Detta dokument utgör projektdokumentation
och är en heltäckande presentation av projektet.
Prototypen som presenteras i och med denna dokumentation är den 4:e iterationen och är en
körbar prototyp av systemet i sin helhet. Arbetet med att ta fram prototypen har varit
användarcentrerat i den mån att stor tyngdvikt har lagts på intervjuer och användartester. I den
körbara prototypen ingår ej all utvecklad funktionalitet, de delar som har utlämnats p.g.a.
resursbrist finns angivna i 6 Framtida utvecklingsmöjligheter.
Senaste version av detta dokument samt övrig projektdokumentation finns tillgänglig från
www.nada.kth.se/projects/proj02/sytt
Version
1.0
3 maj 2002
Dokumentets skapande
© Rättigheterna till detta dokument och tillhörande bilagor tillhör projektgruppen för SYTT.
4
2 Projektstruktur
2.1
Projektramar
Detta projekt sker inom ramen för kursen 2D1954 Programutvecklingsprojekt, 4p, våren
2002. Kursen ges av Institutionen för Numerisk Analys och Datalogi (NADA) vid Kungl.
Tekniska Högskolan (KTH) med Lars Kjelldahl, [email protected], som lärare och
kursansvarig. Lärarens roll i projektet har varit som övervakare och resurs i allmänna
projektfrågor, med befogenhet att gripa in om projektet riskerar att misslyckas.
Uppdragsgivare är Henrik Artman, studierektor vid IP-lab (NADA), [email protected].
Uppdragsgivarens roll i detta projekt var att definiera problem och mål samt att ansvara för,
och utvärdera, effekten av systemets användning.
Projektägare (i och med rollen som projektledare) är Petter Halman, [email protected],
med ansvar att säkerställa att projektet motsvarar uppdragsgivarens förväntningar. Hans
befogenhet har varit att styra projektets inriktning, mål samt att hantera relationen till
uppdragsgivaren.
Till vilken grad projektet lyckats med sin uppgift avgörs av två olika instanser, där
uppdragsgivarens utvärdering och uppföljning är den för projektgruppen primära. Projektet
kommer även bedömas ur ett kursperspektiv av en utvärderingskommitté, med befogenhet att
kräva kompletterande arbete innan gruppen godkännes på kursen.
2.2
Projektgrupp
Projektledare
Petter Hallman (PH) har innehaft uppgiften att skapa förutsättningar för projektgruppen att nå
sina mål. Han ansvarade för att planera och följa upp projektgruppens arbete samt att
projektet genomfördes inom ramarna för tid och resurser.
Dokumentation & Administration
MariAnne Ygberg (MY) har innehaft ansvar för dokumentationens utformning och innehåll
samt att nödvändig information och resurser funnits tillgänglig(a) under projektets gång.
Användare/Gränssnitt
Kerstin Lindbergson (KL) och Magnus Schylström (MS) har innehaft ansvar för
användarstudier samt utformning och programmering av gränssnitt.
Teknik
Matherey Bracamonte Nunez (MBN), Per-Henrik Stenlund (PHS) och Tham Ngoc Minh
(TNM) har innehaft ansvar för systemets inre struktur och uppbyggnad.
5
2.3
Referensgrupp
Referensgruppen har varit rådgivande avseende systemets funktionella innehåll samt
kommande användning. De gav råd och förslag till systemets utformning inom ramen för
kravbeskrivning. Deras deltagande gav dessutom en successivt förankring för projektet på
NADA.
Medlemmar:
Ann Lantz, lärare
Viggo Kann, studierektor
Maria Normark, doktorand
Anders Hedman, doktorand
Serafim Dahl, lärare
2.4
Resurser
Då projektet är en del i en kurs omfattande 4 högskolepoäng antogs varje projektmedlem
arbeta motsvarande fyra heltidsveckor. Totalt förfogade alltså projektet över cirka 1100
timmar, fördelat på 7 personer á160 timmar. Den 3 maj har drygt1200 timmar utnyttjats, då
kvarstår presentation av projekt och viss finslipning.
Projektgruppen har haft tillgång till utvecklingsmiljö i UNIX genom Nadas terminalsalar.
Mac-datorer fanns tillgängliga för arbete med grafisk design och dokumentation. En
projektplats fanns tillgänglig under afs/nada.kth.se/misc/projects/proj02/sytt med tillhörande
webbplats www.nada.kth.se/projects/proj02/sytt.
2.5
Projektavslut
Projektet avslutas i samband med kursens slut, innan dess ska ett antal delmål uppnåtts. Det
första delmålet var inlämnandet av den preliminära specifikationen. Därefter följde
färdigställandet av specifikationen vilket bestod av systemdesign (logik, informationsflöden
och datastruktur) och användartest. Nästa steg var produktion, testning samt dokumentation
som avslutas i och med en förhandspresentation av projektet den 3 maj. Slutpresentation hålls
den 7 maj. Projektet avslutas efter att dessa presentationer och en utvärdering har genomförts.
En eventuell fortsättning, i syfte att färdigställa ett driftbart system, sker utanför kursen, t.ex.
som sommararbete för någon gruppmedlem.
2.6
Projektgruppens äganderätt
Allt resultat från projektet, exempelvis skisser, systemdesign, källkod och dokumentation,
tillhör projektgruppen. Nada har rätt att, för icke-kommersiellt bruk, använda och
vidareutveckla systemet. Projektmedlemmarna har envar rätt att, på valfritt sätt, efter
projektets slut använda resultatet så som de önskar. Detta gäller projektet i sin helhet, om
annat inte tydligt uttrycks.
6
3 Problembeskrivning
3.1
Bakgrund
NADA
Uppdragsgivare är Henrik Artman på IP-lab (The Interaction and Presentation Laboratory), en
avdelning på institutionen för numerisk analys och datalogi vid KTH, Nada. Nada ansvarar
för forskning och undervisning vid KTH och Stockholms universitet (SU) i de akademiska
ämnena datalogi, människa-datorinteraktion, numerisk analys, medieteknik och grafisk
produktion. På Nada arbetar bland andra studierektorer, lärare och doktorander. Totalt finns
det c:a 100 doktorander, varav c:a 20 arbetar på IP-lab.
Doktorandernas arbetssituation
Nadas doktorander har en undervisningsplikt på 10-20% av sin arbetstid. Undervisningen kan
bedrivas under olika former och i olika roller. Den indelning som finns är; föreläsningar,
övningar, laborationer, kursassistent, handledning, tentamensrättning och övrigt. För dessa
moment finns standardförberedelsetid angiven, t.ex. 2 förberedelsetimmar per
föreläsningstimme. Det finns ingen begränsning av hur många kurser en doktorand medverkar
i eller av hur många doktorander som medverkar i varje kurs.
Tidrapportering och planering
Ansvaret för planeringen av undervisningen är uppdelat. Det är vanligen den kursansvarige
som kontaktar en doktorand med en förfrågan om undervisningshjälp. Studierektorn ansvarar
för bemanning och överblick.
Den tid doktoranderna arbetar ska rapporteras in till administrationen, vilket sker manuellt
genom pappersblanketter, som doktoranderna själva ansvarar för att sammanställa korrekt. I
dagens läge har IP-lab och resterande Nada avsevärt olika rutiner gällande doktorandernas
tidrapportering.
På IP-lab redovisar doktoranderna sin tid till administratör i slutet av läsåret. Eventuellt
notifieras studierektorn. Ofta resulterar sammanställningen i ett underskott för doktoranderna.
I dagens läge sker ingen kontroll av det som doktoranderna rapporterar, då lärarna inte tar
någon aktiv del i denna process. Datumangivelser redovisas inte, även om intresse för detta
kan finnas i framtiden.
På resten av Nada är kravet på kontroll och planering större. I början av terminen planerar
lärarna sina kurser gällande timmar och datum, efter att ha diskuterat med doktoranderna.
Lärarna anger dessutom vilken förberedelsetid de olika momenten får ta, om det avviker från
standardförberedelsetiden. Om doktoranderna använder sig av mer tid räknas denna inte som
arbetstid. Doktoranderna har även planeringssamtal med studierektorn för att strukturera den
kommande terminen. Doktorandernas timrapporter sammanställs i slutet av året av
studierektorn.
Om doktoranderna inte fullgör sin arbetsplikt adderas underskottet till nästa års arbetstimmar.
Motsvarande gäller för de fall då doktoranden överskrider de antal timmar som krävs, då
subtraheras nästa års timmar med överskottet.
7
3.2
Syfte
Projektet hade till syfte att lösa de problem som finns i dagens process för tidrapportering på
IP-lab.
Huvudproblem:
 Alla doktorandens timmar blir inte redovisade, vilket leder till frustration hos
doktoranden. Orsaken till problemet torde vara att redovisningsmetoden är bristfällig.
Doktoranderna skriver inte ned alla sina timmar omedelbart och glömmer sedan bort
hur många timmar hon/han har lagt ned. Doktoranden har heller inte möjlighet att se
en översikt över sina timmar.
 Det finns ingen kontroll på doktorandens arbetsinsats, studierektorn vet inte vilka
timmar som redovisas och först i efterhand uppmärksammas eventuellt
över/underutnyttjande av doktoranderna.
 Det saknas även möjlighet att se en översikt över doktorandernas arbetsinsats per kurs.
 Då allt sker manuellt blir det en omfattande mängd pappersarbete, speciellt för
studierektorn.
 Avsaknaden av statistik innebär att planeringen avsevärt försvåras.
3.3
Användare
De presumtiva användarna till systemet kan indelas i tre kategorier: doktorander,
lärare/handledare och studierektorer. Användningen av systemet kommer skilja sig från
individ till individ, men efter åtskilliga intervjuer av presumtiva användare identifierades en
viss konsensus inom de olika kategorierna av användare, trots individuella skillnader.
Användarna är inom gruppen relativt eniga om vilka funktioner och behörigheter man har
behov av.
Gemensamt för de olika användarrollerna är att de kan antas ha god kunskap om datorer och
vara relativt erfarna användare av system med webbaserade gränssnitt, varför ingen särskild
hänsyn har tagits till mindre datorvana användare.
Intervjuer av användare gav intrycket att den tidsrapportering som görs idag skiljer sig
mycket åt mellan de olika avdelningarna på Nada. På vissa avdelningar var det studierektorn
som tillsammans med doktoranden bestämde hur dennes instutitionstjänstgöring skulle läggas
upp över året, varefter studierektorn la in dessa timmar åt doktoranden. Det kunde också vara
så att lärare planerade timmar för doktoranderna och sedan rapporterade genomförda
doktorandtimmar till studierektorn vid kursens slut. Ett tredje sätt var att doktoranden själv la
in sina planerade och genomförda timmar. Intervjuerna gav intrycket att doktorandernas
redovisning av timmar gjordes med låg frekvens och att många doktorander även missade
timmar, eftersom de glömde att rapportera dem. Ett av syftena med vårt system är att råda bot
på detta problem.
För att få doktoranderna, lärarna och studierektorerna på Nada att använda
tidrapporteringssystemet var det till viss mån tvunget att anpassas, så att det är flexibelt nog
att tillåta att doktorandernas instutitionstjänstgöringstimmar rapporteras enligt den praxis som
finns på respektive avdelning idag. Systemet har emellertid gjorts mer lättöverskådligt och
lättanvänt än nuvarande tidsrapporteringssystem för att på så sätt främja användningen av det.
Under intervjuerna framkom det att en av de viktigaste aspekterna för doktorander är att det
8
snabbt går att rapportera in timmar till systemet. Som följd av detta har genvägar lagts till, för
att möjliggöra snabb inmatning av tjänstgjorda timmar.
En typisk användningssituation är en anställd som, när man sitter framför datorn på sitt rum,
passar på att rapportera in timmar till systemet.
4 Projekthistorik
4.1
Översikt
Projektet har drivits som ett professionellt projekt med speciellt användarcentrerat fokus.
Genom hela processen har förbrukningen av resurser planerats och rapporteras. Regelbunden
kontakt med användare och uppdragsgivare har varit central för att arbeta fram ett system som
tillgodoser användarnas behov. Under projektet har dokumentation kontinuerligt skett,
eftersom beslut och beslutsunderlag ska vara tillgängliga för projektets medlemmar och i och
med projektdokumentationen, användarhandledningen och systemdokumentation även för
utomstående. Genom intervjuer, användartester och gruppens arbete har lösningen genomgått
fyra olika iterationssteg, från skissförslag till körbar prototyp. Kursens ramar gav en
resursbegränsning vilket innebar att en del funktioner bortprioriteras till
implementeringssteget i systemet. En noggrann genomgång av tänkbara risker i ett tidigt
skede i projektet ledde till att många problem har kunnat undvikas. Gruppens ambitionsnivå
har dock lett till att arbetsbördan har varit genomgående hög, vilket tillsammans med sjukdom
varit orsak till att tidsplanen förskjutits. Effekten av detta har kunnat begränsas av de två
buffertveckor som var inplanerade i slutet.
4.2
4.2.1
Arbetsprinciper
Användarcentrerat
En viktig del i detta projekt var att fastställa arbetssättet idag och behovet av olika funktioner i
ett tidrapporteringssystem. Då systemets fortlevande beror på användarnas framtida
uppfattning, betraktades förstudie och användartester som centrala i projektet.
Uppdragsgivarens inställning tolkades som att huvudproblematiken var att ta fram ett system
och ett användargränssnitt som kan användas som stöd för att förbättra doktorandernas tidsoch planeringsprocess. Det färdiga systemet ska vara så pass attraktivt att användarna
övertygas om dess överlägsenhet, det ska inte vara ett kompromissystem mellan de olika
arbetsätten idag.
4.2.2
Projektets arbetsform
Detta projekt har inneburit en möjlighet att få en närmare kontakt med verkligheten, att lära
sig hur man arbetar ute på företag. För att ta vara på denna möjlighet har projektet drivits på
ett sätt som liknar ett professionellt arbetssätt, endast med de begränsningar som är
oundvikliga då projektet ligger inom ramarna för en kurs.
Projektet har drivits på traditionellt vis, med projektledare, arbetsgrupper och
ansvarsfördelning. Upprepade iterationer av systemet hr skett, där förbättringar skett efter
bl.a. användartester. Projektet har strukturerats genom olika styrdokument. Mer ovanliga
projektformer, som PPS och extreme programmig har inte använts.
9
4.2.3
Resurstänkande
Tidigt i projektet introducerades fokus på resurser. Kontinuerligt under projektet har
medlemmarna rapporterat sitt arbete, både gällande tid och gällande område. Tidrapportering
har haft till syfte att kunna fördela resurser så att ingen person får för hög arbetsbörda. En
tidsplan arbetades fram i och med den preliminära specifikationen, där hänsyn togs till det
totala antalet tillgängliga timmar, redan förbrukade timmar och gruppmedlemmarnas
möjlighet att arbeta under våren.
4.2.4
Dokumentation
Dokumentationen får en speciell vikt för ett projekt av detta slag. Detta beror dels p.g.a. dess
användarcentrerade natur, dels på att dokumentationen är det resultat som uppdragsgivaren
har att utgå ifrån om han vill låta utveckla den körbara prototypen till en färdig lösning att
implementeras på Nada. Till följd av detta har projektets medlemmar kontinuerligt
dokumenterat viktiga faser, beslut och möten. Dokumentationen har även betydelse för
projektets medlemmar, eftersom det är viktigt att de skilda grupper som medlemmarna har
delats in har en gemensam bild av användargränssnitt och funktionalitet.
4.3
Utveckling
Under projektet har systemet, och därmed användargränssnittet, genomgått följande
iterationer:
1. Lösningsförslag/skiss (idénivå)
Den första skissen arbetades fram efter intervju med uppdragsgivare och ide- och
arbetsmöte inom gruppen.
2. Prototyp 1
Ett urval ur de tre olika användargrupperna intervjuades varefter ett komplett
användargränssnitt på papper tillsammans med en beskrivning av funktionaliteten
presenterades för uppdragsgivaren i den preliminära specifikationen.
3. Prototyp 2
Användartest genomfördes varefter funktionaliteten och användargränssnittets design
fastställdes. Systemdesign för hela systemet togs fram.
4. Prototyp 3
En körbar prototyp av det färdiga systemet har tagits fram, med vissa
gränssnittsförbättringar.
4.4
Historik
Som tidigare beskrivet under 4.2.3 Resurstänkande har projektgruppens medlemmar
kontinuerligt rapporterat arbetsuppgifter och tid. I denna avdelning har hur projektet bedrivits
följts upp, hur mycket och vilket arbete som har genomförts under olika perioder och hur
mycket resurser olika faser av projektet har tagit. Den tidsplan som togs fram i och med den
preliminära specifikationen har blivit förskjuten av orsaker som nämns i 4.7 Risk- och
avvikelseanalys, men effekterna av detta har kunnat begränsas eftersom tidsplanen medvetet
var planerad för ett högt tempo med två buffertveckor inlagda i slutet. Resursförbrukningen
har i stort följt planen.
10
Resursförbrukning per projektfas
Antalet timmar per fas i projektet hr beräknats för att kunna följa upp hur väl den beräknade
resursförbrukningen stämde. Planeringen stämde mycket bra för samtliga områden förutom
programmeringen, som där förbrukningen översteg den planerade.
Förstudie & Specifikation
Användartester
Dokumentation
Systemutveckling
Systemdesign
Användargränssnitt/test (html och jsp)
Logikprogrammering/test (databas och servlets)
Presentation & Projektavslut
Övrigt
350
25
100
70
235
430
45
25
Veckoöversikt
Aktiviteter
Förstudie
Uppstart
Intervjuer
Design & Lösningsskiss
Antal h
v6
110
v7
v8
v9
v10
160
Första skiss
Prototyp nr 1
Proof-of-concept (tekniklösning)
Dokumentation
80
Prel. Specifikation
Summa planerat
350
Vecka 6 – 7
Uppstart av projekt.
Första skiss av lösning.
Resursförbrukning c:a 55 timmar
Vecka 8 – 10
Användarintervjuer och informationsinsamlande. Förbättring av lösningsförslag till prototyp1.
Proof-of-concept (tekniklösning) och funktionsbeskrivningar klara.
Dokumentation specifikationen.
Resursförbrukning c:a 255 h.
11
Aktiviteter
Användargränssnitt
Användartest av prototyp
Systemdesign
Antal h
v11
v12
v13
v14
v15
v16
25
70
Systemdesign & datastruktur
Logikdesign/informationsflöde
Användargränssnitt
235
Programmera gränssnitt (html)
Programmera gränssnitt (jsp/java)
Teknikutveckling
430
Sätta upp databas
Logik/Servletts
Sluttest & buggfix
Produktionsavslutning
Dokumentation
Användarhandledning
30
Systemdokumentation
30
Projektdokumentation
Övrigt
40
Presentation & Projektavslut
45
Avstämning
25
Summa planerat
930
Vecka 11
Systemdesign.
Datastruktur och dataflöde.
Användartest, utvärdering och förbättring av prototyp=> prototyp 2
Fastställande av specifikation.
Påbörjad htmlkodning.
Resursförbrukning c:a 75 h.
Vecka12-14
Kodning/produktion
Html färdigställdes.
Kodning av databas och javascript.
Påbörjad servlet- och jspkodning.
Resursförbrukning c:a 170 h.
Vecka 15
Kodning av databas javascript och servlets.
Påbörjad slutdokumentation, användarhandledning.
Resursförbrukning c:a 75 h.
Vecka 16
Kodning av jsp och servlets.
Användardokumentationen slutfördes och projektdokumentationen påbörjades.
Resursförbrukning c:a 120 h.
Vecka 17
Kodning jsp och servlets.
Systemdokumentationen färdigställdes.
Projektdokumentation.
12
v17
v18
v19
Resursförbrukning c:a 195
Vecka 18 DEADLINE, skapa presentation
Testning av systemet.
Skapa presentation
Finslip på dokumentation.
Förhandsvisning av projektet.
Resursförbrukning c:a 310 h
Vecka 19
Slutpresentation
Utvärdering
4.5
Externa möten
Under projektets gång har, förutom de interna mötena inom gruppen, en rad externa intervjuer
genomförts. Listan nedan anger detaljer för intervjuerna och uppgifter om i vilket skede i
projektet de skett.
Datum & person
Befattning Ämne
Underlag till första skissen
7/2 Henrik Artman
Studierektor
Första mötet med uppdragsgivare
Underlag för prototyp 1
20/2 Viggo Kann
22/2 Henrik Artman
26/2 Jonas Sjöberg
26/2 Maria Normark
27/2 Minna Räsänen
27/2 Serafim Dahl
27/2 Henrik Eriksson
1/3 Anders Hedman
6/3 Ann Lantz
Studierektor
Studierektor
Doktorand
Doktorand
Doktorand
Lärare
Lärare
Doktorand
Lärare
Genomgång systemskisser, NADAs rutiner, arbetssätt
Genomgång systemskisser, NADAs rutiner
Genomgång systemskisser, arbetssätt, funktionalitet
Genomgång systemskisser, arbetssätt, funktionalitet
Genomgång systemskisser, arbetssätt, funktionalitet
Genomgång systemskisser, arbetssätt, funktionalitet
Genomgång systemskisser, arbetssätt, funktionalitet
Genomgång systemskisser, arbetssätt, funktionalitet
Genomgång systemskisser, arbetssätt, funktionalitet
Underlag för prototyp 2
6/3 Henrik Artman
8/3 Viggo Kann
11/3 Anders Hedman
11/3 Maria Normark
11/3 Henrik Eriksson
13/3 Eva-Lotta Salnäs
13/3 Ann Lantz
Studierektor
Studierektor
Doktorand
Doktorand
Lärare
Doktorand
Lärare
Genomgång prototyp 1 arbetssätt på Nada
Genomgång prototyp 1, allmänt om systemet
Användartest/intervju prototyp 1
Användartest/intervju prototyp 1
Användartest/intervju prototyp 1
Användartest/intervju prototyp 1
Användartest/intervju prototyp 1
15/3 Henrik Artman
22/3 Lars Kjelldahl
17/4 Ola Knutsson
18/4 Kerstin Severinson
22/4 Henrik Artman
Studierektor
Kursansvarig
Doktorand
Professor
Studierektor
Genomgång av prel. spec. Prioritering
Statusmöte
Diskussion om dokumentation
Presentation av systemet och projektet
Statusrapport, genomgång av projektets sista 2 v.
13
4.6
Prioritering
Projektet har haft som mål att skapa en funktionell prototyp som uppfyller så stor del av
kravspecifikationen som möjligt. Detta var dock begränsat av de resurser i form av tidsperiod
och antal timmar som fanns.
Prioritering i projektet handlar om förhållandet mellan tid, funktionalitet och tillgängliga
resurser. Tidsperioden sätts av kurskraven, med projektpresentation första veckan i maj. De
tillgängliga resurserna bestäms av kursens omfattning, vilket beskrivs i 2.4 Resurser. Då både
resurser och tidsperiod är låsta har kraven på funktionalitet anpassats för att inte ha orimliga
förväntningar på projektets resultat.
Funktioner
Resurser
Tid
Efter systemdesignens färdigställande prioriterades funktioner i samarbete med
uppdragsgivaren. På grund av att teknikansvarigas sjukdom samföll med projektledarens
frånvaro kommer prototypen vara lite längre från driftsklar än planerat, men den kommer att
uppfylla uppdragsgivarens krav, d.v.s. en körbar prototyp där buggar är tillåtna.
4.7
Risk- och avvikelseanalys
I och med den preliminära specifikationen identifierades ett antal riskområden för projektet.
Dessa områden diskuterades i projektgruppen för att finna hur hög sannolikheten var att
problemet skulle inträffa och vilken effekt det i sådana fall skulle ha på projektet. Förslag på
lösningar och sätt att eliminera, eller åtminstone reducera, riskerna undersöktes och
diskuterades.
Merparten av de identifierade problemen har inte drabbat projektet, till stor del beroende på
att åtgärder för att förhindra dess uppkomst sattes in på ett tidigt stadium. Arbetsfördelning,
datastruktur och ändringshantering betraktades t.ex. kunna leda till problem för projektets
utförande, men en väl planerad projektstruktur innebar att detta kunde undvikas.
Arbetsfördelningen definierades tydligt och för att områden inte skulle försummas har
kontakterna mellan projektledaren och de olika grupperna samt dessa sinsemellan varit
intensiv. En detaljerad systemdesign utvecklades vilket underlättade frågor rörande
datastrukturen och ändringshanteringen.
Farhågorna om för hög arbetsbörda har visat sig befogade, vilket beror på den höga
ambitionsnivå projektgruppen har haft. Detta tillsammans med att teknikansvarigs sjukdom
sammanföll med projektledarens frånvaro har lett till att viss funktionalitet inte har kunnat
implementeras i systemet.
14
5 Lösningsbeskrivning
5.1
Översikt
Det beskrivna lösningsförslaget (prototypen) är en fjärde och för projektgruppen sista
iteration av systemet. Eventuell utökad funktionalitet finns beskriven nedan i avsnitt 6
Framtida utvecklingsmöjligheter.
Den tekniska lösningen har valts utifrån ett antal parametrar där de tre avgörande var typ av
system, projektgruppens kompetens samt flexibilitet i utveckling och drift. Lösningen bygger
på en tre-lagersmodell av presentation, logik och datalagring.
Prototypen erbjuder olika funktionalitet för de tre olika användarrollerna, doktorander, lärare
och studierektorer. Doktoranden kan rapportera, planera och få en översikt av sina timmar
totalt och per kurs. Läraren kan få en översikt över doktorandernas arbetsinsats på
hans/hennes kurser och planera doktorandtimmar. Studierektorn har samma funktionalitet
som läraren i de fall hon/han undervisar, men administrerar även hela systemet. Den
viktigaste aspekten för studierektorn är att han/hon får en heltäckande översikt över
doktorandernas arbete på avdelningen.
5.2
5.2.1
Teknisk lösningsbeskrivning
Generellt
Att i mjukvaruutvecklingsprojekt göra riktiga teknikval kan ibland vara skillnaden mellan att
ro projektet i hamn eller att fastna någonstans på vägen. Teknikvalet har inte bara att göra
med att hitta optimal teknik/prestanda, utan beror även av designparametrar som
gruppmedlemmarnas kunskapsområde, beställarens önskemål och kostnader förknippade med
olika val.
5.2.2






5.2.3

Datormiljö
Systemdrift sköts av Nada/Systemgruppen vilka har kompetens och utrustning för de
flesta standardlösningar. Traditionellt använder NADA mycket Unix-baserade system
och programvaror.
Då systemet är webbaserat ställs inga specifika krav på klientprogramvaror.
Serverprogramvara är av standardtyp och innebär ej nya licenskostnader för Nada.
Inga speciella krav på hastighet ställdes, annat än det rent användarmässigt bör gå
snabbt att ladda sidor. Då systemet mestadels används från NADAs datorer är
internetanslutningens kapacitet och driftsäkerhet inget problem.
Nadas personal använder Mac, Unix och/eller PC. Systemet bör i framtiden fungera
för de vanliga webbläsarna (Netscape & Internet Explorer) i rimligt nya versioner.
Med tanke på att systemet varken innehåller känslig eller kritisk information är kraven
på säkerhet låga och kraven på driftsäkerhet normala.
Designparametrar för teknisk lösning
Beställarens önskemål.
Beställaren vill se ett tidsplanerings- och rapporteringssystem som man kan nå via
webbgränssnitt.
15

Systemets funktion.
Mängden av, samt karaktären på, den information som skall behandlas i applikationen
är sådan att det var lämpligt att använda en databas för lagring.
Tillgängliga plattformar.
Det finns i princip två plattformar som systemgruppen på Nada
tillhandahåller/rekommenderar vilka båda utnyttjar PostgreSQL som databasmotor.
Den ena bygger på PHP för att klara programlogiken, i den andra används Java (JSP
och/eller Servlets).
Tillgänglig kompetens.
Projektets medlemmar har alla kännedom om utveckling i Java. Viss erfarenhet av
utveckling av webbapplikationer med Java servletts och JSP finns även inom gruppen.
PHP kunskaperna är begränsade.
Organisation.
Möjlighet att fördela programmeringsarbetet i ”front-end” (presentation) respektive
”back-end” (logik/datalagring) var önskvärt. De strikta tidsramarna medförde att
produktionen var tvungen att utföras som ett antal parallella processer.



5.2.4
Teknisk lösning
Den tekniska lösningen är indelad enligt nedanstående konceptuella 3-lager modell.
Presentation/Interaktion
Logik
Datalagring
JSP-sidor
Java Servlets
SQL
Lösningen bygger på utnyttjandet av en ensam databas för lagring av data. Dataåtkomst sköts
av logikkomponenterna. All presentation och interaktion sker i presentationslagret som
utbyter data med logikkomponenterna. För att kunna använda sig av en parallell utveckling av
komponenter, oberoende av övriga komponenter, utvecklades en grundläggande, väl utformad
systemdesign. I denna specificeras även utformningen av gränssnitt mellan de olika
komponenterna.
Det finns i stort sett en JSP-sida per användarsida, dock genereras vissa JSP-sidor från en och
samma servlett. Det finns ett antal specifika servletts som genererar vanligt återkommande
element i gränssnittet, exempel på detta är drop-down-menyer.
16
5.2.5
Teknisk plattform
Den tekniska plattformen som använts under utvecklingen bygger på fria programvaror som
redan idag används vid NADA. Detta med avsikten att underlätta implementation och
driftsättning. Den avdelning vid NADA som skulle ansvara för en eventuell drift är
Systemgruppen, vilka själva använder en liknande plattform.
Då alla komponenter utformats enligt standardförfarande är systemet i princip
plattformsoberoende.
PostgreSQL 7.0 har använts som databasmotor. Kommunikationen med databasen sker via
JDBC 2.0 vilket finns tillgängligt från och med JDK 1.2. Tomcat 4.0 har använts som
webbserver då den klarar både JSP- och Servlet-teknologi.
Logik- och presentationskomponenter bygger på Java 2 Platform Enterprise Edition (J2EE).
För kompilering och exekvering av javakod används J2EE SDK 1.3 och Java 2 Platform SDK
1.3.1.
17
5.3
5.3.1
Funktionsbeskrivning
Inledning
Projektet har lett fram till ett tidrapporteringssystem för doktorandernas Gru-tjänst (Gru står
för grundutbildning) med utvidgad funktionalitet för planering och administration.
Tidrapporteringssystem har olika användningsområden för olika användargrupper, vilka
utgörs av doktorander, lärare och studierektorer. Det finns planeringsmöjligheter, men
systemet är ej utformat som ett meddelandesystem eller bokningssystem. Det är därför viktigt
att kommunikation mellan lärare och doktorand sker innan timmar planeras. Systemet ger en
överblick över doktorandernas arbetsinsats under såväl innevarande år som tidigare år,
användaren kan välja att se uppgifter för ett annat läsår. För att betona den skilda
funktionaliteten för olika användare beskrivs de var för sig.
18
Doktorand
En doktorand kan med detta system regelbundet rapportera sin arbetsinsats inom
grundutbildningen, vilket innebär att systemet ersätter den tidigare manuella processen för
rapportering av doktorandernas arbete. Doktoranden rapporterar hur många timmar, vilken
arbetsuppgift och inom ramarna för vilken kurs arbetat har utförts. På samma sätt som
doktoranderna rapporterar sitt arbete går det också att planera arbete för att få en bättre
överblick över hur arbetsbördan är fördelad under terminen och veta var luckor finns.
Doktoranden kan se hur mycket han/hon arbetat, hur mycket som är planerat och hur mycket
som är kvar att göra utifrån sitt tjänståtagande. Systemet är flexibelt uppbyggt så det finns
inget krav på att redovisning av en timme måste föregås av planering av denna timme, vilket
innebär att planeringsdelen är helt frivillig. Flexibiliteten hos tidrapporteringssystemet medför
även att det finns flera olika sätt att redovisa sina timmar.
Sitemap
Denna sitemap beskriver hur sidorna i gränssnittet förhåller sig till varandra. De rutor som är
streckade står för sidor som inte är implementerade i dagens system.
Inloggning
Startsida
Historik
Pop-up
Addera
aktivitet
Pop-up
Ändra aktivitet
Kurs
Mina uppgifter
Pop-up
Pop-up
Add. aktivitet
från kurs
19
Överför
aktivitet
Resurs
Lärare
För lärarna är detta inte ett rapporteringssystem utan erbjuder en möjlighet att få en överblick
över doktorandernas arbetsinsats på en kurs. Läraren kan enkelt se vad som hänt hittills och, i
den mån planering skett, vad som kommer att ske framöver. Det doktoranderna planerat
markeras med en stjärna på lärarens sida för att uppmärksamma honom/henne. Läraren kan
även planera in timmar för doktoranden.
Sitemap
Denna sitemap beskriver hur sidorna i gränssnittet förhåller sig till varandra. De rutor som är
streckade står för sidor som inte är implementerade i dagens system.
Inloggning
Startsida
Resurs
Doktorand
Mina uppgifter
Kurs
Pop-up
Plan. aktivitet
för doktorand
20
Studierektor
I många fall är en studierektor även lärare varför beskrivningen ovan kan gälla för
honom/henne också. Utöver detta sköter studierektorn den administrativa sidan av systemet.
Studierektorn kan skapa och redigera användare, kurser och läsår. Tidsrapporteringssystemet
ger studierektorn en överblick över samtliga doktoranders arbete.
Sitemap
Denna sitemap beskriver hur sidorna i gränssnittet förhåller sig till varandra. De rutor som är
streckade står för sidor som inte är implementerade i dagens system.
Inloggning
Startsida
Resurs
Läsårsadm
Användaradm
Kurs-adm
Doktorand
Kurs
Doktorand
Pop-up
Plan. Akt.
För dokt.
21
Lärare
Kurs
Variabler
5.3.2
Användargränssnitt
Ett antal sidor ur gränssnittet har valts ut för att på ett tydligt sätt åskadliggöra
tidrapporteringssystemet. Först presenteras ett förtydligande av några för systemet centrala
termer.
Moment
De olika arbetsuppgifter en doktorand kan utföra kallas moment. Dessa moment består av:
föreläsning, övning, handledning, kursassistent, laboratorieassistent, tentamensrättning eller
övrigt.
Aktivitet
En aktivitet är en enskild arbetsinsats, d.v.s. exempelvis ett specifikt föreläsnings- eller
handledningstillfälle.
Lektionstid
Den tid som inte inbegriper planering kallas lektionstid. Om en doktorand t.ex. ger en
föreläsning på två timmar och har planerat denna i fyra timmar är lektionstiden två timmar.
Förberedelsetid
Till vissa moment finns en standardförberedelsetid per timme. För varje lektionstimme av en
föreläsning får doktoranden t.ex. två förberedelsetimmar. Vissa moment har ingen
förberedelsetid, för att t.ex. arbeta som laborationsassistent en timme ges ingen
förberedelsetid.
22
Doktorand startsida
På doktorandens startsida kan han/hon få en överblick över sin arbetsinsats inom Gru,
grundutbildningen. Det går snabbt och enkelt att se hur stor andel av den totala arbetstiden
som är genomförd, planerad respektive kvar att göra. De kurser som doktoranden har arbetat
inom eller har planerat att arbeta inom presenteras med information om hur många timmar
som är genomförda och planerade. Genom att trycka på pilen som föregår kursen kan
doktoranden se vilka moment de angivna timmarna är fördelade. Från denna sida kan
doktoranden komma till respektive kurssida, ett popup-fönster för planera eller rapportera
aktiviteter samt till en sida som presenterar de personliga uppgifter som finns lagrade om
doktoranden.
23
Doktorand kurssida
För varje kurs som doktoranden har deltagit i undervisning av finns det en speciell kurssida.
På denna kurssida presenteras allmän information om kursen och om hur många timmar som
finns planerade och genomförda för varje moment. Genom att expandera respektive moment
kan doktoranden även se vilka aktiviteter momentet är fördelat. Timuppgifterna presenteras
totalt och uppdelat på lektionstid och förberedelsetid. De planerade aktiviteterna kan
överföras till genomförda. Från denna sida kan doktoranden även komma till startsidan,
popup-fönster för planera, rapportera, ändra och överföra aktiviteter från planerade till
genomförda, samt till en sida där de personliga uppgifter som finns lagrade om doktoranden
kan redigeras.
24
Lärarens startsida
På lärarens startsida presenteras de kurser som han/hon är ansvarig för och de eventuella
doktorander han/hon handleder. Kurserna är länkade till respektive kurssida och
doktoranderna är på motsvarande sätt länkade till respektive doktorandsida. Det är möjligt att
söka efter andra kurser än de läraren är ansvarig för. Genom att söka efter en specifik
doktorand kan läraren även få uppgifter om doktorandens arbetsinsats totalt och per kurs.
Även läraren kan länkas vidare till en sida där de personliga uppgifter som finns lagrade om
han/henne kan redigeras.
Lärare kurssida
På en lärares kurssida presenteras information om doktorandernas arbetsinsats på aktuell
kurs, både den totala arbetstiden och uppdelad på planerade och genomförda timmar.
Timmarna redovisas per moment, men det är möjligt för läraren att expandera ett moment och
se timmarna presenterade per aktivitet. Läraren kan även ange information om kursen eller
läsa information som studierektorn angivet. Läraren kan planera in doktorandernas arbete för
att kunna planera sin kurs, men detta är inte ett bokningssystem så kommunikation med
doktoranderna behöver ske. Det finns möjlighet för läraren att länkas vidare till kurssidorna
för det andra kurserna han/hon är ansvarig för, till startsidan och till en sida som presenterar
hans/hennes personliga uppgifter.
25
26
Studierektor startsida
Studierektorn kan från sin startsida länkas vidare till sina övriga sidor; Användar-adm. (en
sida där användare kan redigeras och skapas), Kurs-adm. (en sida kurser kan redigeras och
skapas), Läsårs-adm. (en sida där du redigera läsår), Variabler (en sida där han/hon kan
redigera globala variabler för tidsrapporteringssystemet). Genom att söka på en kurs, en
doktorand eller en lärare får studierektorn tillgång till sidor som presenterar all information
inom systemet och möjliggör för honom/henne att få en översikt över doktorandernas arbete. I
de fall studierektorn även har undervisning presenteras de kurser han/hon är ansvarig för på
samma sätt som för läraren.
27
Addera aktivitet
Addera aktivitet är ett exempel på ett popup-fönster. Dessa finns för att användarna ska kunna
addera och redigera uppgifter om aktiviteter, medan de har en annan sida i bakgrunden, t.ex.
kurssida. I dessa fönster anger användaren all relevant information om en specifik aktivitet.
Vid adderingen uppdateras automatiskt den underliggande sidan.
28
6 Framtida utvecklingsmöjligheter
6.1
Inledning
Tonvikten i detta projekt lades på att genomföra en grundlig förstudie och genom upprepade
iterationer arbeta fram ett komplett lösningsförslag som på ett tillfredställande sätt tillgodoser
användarnas behov. Som tidigare beskrivit i Prioritering under Projekthistorik innebar de
begränsade resurser som projektgruppen har att samtliga funktioner ej kunde implementeras. I
dagens läge är prototypen optimerad för Internet Explorer på Mac, en framtida anpassning till
andra webbläsare är att önska.
I och med arbetet med att ta fram prototypen uppstod en mängd idéer, dels om en framtida
utveckling och utvidgning av systemet, dels om alternativa lösningsförslag.
6.2
Ej implementerad funktionalitet
Funktionaliteten som presenteras har genomgått användartest, men är ej fullt utvecklad i
systemdesignen.
6.2.1
Hjälpfunktionalitet
Användarhandledningen är utformad för att kunna delas upp och användas som s.k.
”ballonhelp” till användargränssnittet. Varje sida i gränssnittet är presenterad var för sig. All
funktionalitet som finns beskrivs på ett kortfattat och enkelt sätt i punktform vilket innebär att
det är enkelt att placera varje textavsnitt i en s.k. balloon som dyker upp vid aktuell funktion.
6.2.2
Export
I den ursprungliga prototypen fanns, förutom doktorandernas exportmöjligheter av statistik
(se nedan), även möjlighet för övriga användare att exportera uppgifter från system till ett
excelark för att underlätta administration.
29
6.2.3
Historik
För att doktoranden ska ha möjlighet att få en sammanställning över sina grutjänstgöringstimmar per kurs under varje läsår denna tjänstgjort på Nada togs en historiksida
fram. Designen är enkel, om doktoranden har några särskilda önskemål om framställningen av
statistiken kan han/hon välja att exportera till Excel för redigering.
30
6.2.4
Resurs
För att lärare och doktorander ska kunna ge önskemål om aktiviteter (t.ex. föreläsningar eller
övningar) de vill få eller ge arbetades en resurssida fram, med två separata funktioner:
Användaren kan göra ett inlägg eller titta på vad andra lagt in.
Om användaren är doktorand kan inlägget t.ex. bestå av en föreläsning han/hon önskar ge.
Doktoranden beskriver denna föreläsning, anger vilket ämne den hör till och anger hur länge
förfrågan ska finnas på listan över erbjudna resurser. En lärares inlägg kan t.ex. vara en
förfrågan om någon kan vara handledare på hans/hennes kurs. Inläggen visas i listform för
användaren efter denna angivet om han/hon vill se förfrågningar eller erbjudanden inom ett
specifikt ämne.
31
6.3
Utvecklingsförslag
Henrik Artman på IP-lab är uppdragsgivare och tidrapporteringssystemet är avsett för hans
avdelning. Dock inkluderade förstudien även rutinerna på övriga Nada med följd att
prototypen är anpassad för att i en framtid även kunna implementeras på hela institutionen.
Om systemet slår väl ut kan det i en framtid anpassas för t.ex. gästföreläsare och studenter
vars arbetstid också redovisas timmässigt. I användarstudien framkom att en del lärare är
intresserade av ett liknande system, men det skulle krävas omfattande förändringar eftersom
deras arbetstid inte redovisas per timme.
I dagens läge är ingen koppling till något annat system planerad, men i framtiden finns
möjligheten att koppla denna prototyp till laborationsrapporteringssystemet Tid, eftersom
systemen innehåller ungefär samma uppgifter.
Tidrapporteringssystemet är inte ett bokningssystem eller ett meddelandesystem. Om
planeringsdelen används regelbundet skulle en sådan funktionalitet kunna vara önskvärd.
I den ursprungliga projektidén var en relativt komplicerad kompetensfunktionalitet beskriven.
Förslaget innebar dels att varje enskild lärare och doktorand skulle kunna placera önskemål
om föreläsningar man ville ge eller få, dels fanns en önskan om bokningsmöjlighet. Det var
även föreslaget att doktoranderna skulle kunna ange en kompetensprofil med nyckelord så att
sökning på kompetens skulle kunna ske. Efter intervjuer med berörda parter visade det sig att
intresset för en sådan funktionalitet var i det närmaste obetydligt, varför den sökning efter
resurs som presenteras under Ej implementerad funktionalitet istället togs fram. Det är
givetvis möjlig att utöka denna sökning om intresset för en lösning enligt ovan skulle öka och
då alternativt koppla samman den med en bokningsmöjlighet.
6.4
Alternativa lösningar
Den prototyp som utarbetats innebär en skräddarsydd lösning för doktoranders
tidsrapportering vid NADA. Syftet är att underlätta tidrapportering, ge alla anställda en
överblick över doktorandinsatser samt ge studierektor utökade möjligheter att agera proaktivt
vad gäller doktorandernas undervisningsplikt. Det är en kompetent lösning för problemet,
men det finns alternativa lösningar.
6.4.1
Förändrade rutiner
Ett av syftena med att skapa ett system är att få till stånd en förändring av arbetssätt och
rutiner. En sådan förändring kan mycket väl genomföras utan system, även om det kan
underlätta att låta förändringen vara inbyggd i det nya systemet. Det är inte motiverat att
bygga ett så stort och komplext system om den egentliga anledningen är att systemet ska
agera murbräcka i ett försök att förändra befintliga rutiner.
6.4.2
Excel
Excelfiler kan numera distribueras och delas över nätverk, dock är det en lösning som ställer
specifika krav på programvaror och operativsystem, t.ex. fungerar det inte på Unix som
används av flera anställda vid Nada. En lösning kan vara att skapa mallsidor i Excel som
sedan fylls i av doktorander och/eller lärare och returneras till studierektor.
32
6.4.3
Färdig databaslösning
Det kan mycket väl gå att sätta upp en databas som FileMaker Pro eller MS Access för att låta
doktorander rapportera nedlagda timmar. Dessa applikationer är enkla att sätta upp, har
färdiga gränssnitt som kan anpassas och kan förses med inloggningsförfarande. Nackdel är
den minskade funktonaliteten samt att det inte säkert går att anpassa en lösning bra till alla
OS. Fördelar är den mindre arbetsinsats som krävs och därmed ökad flexibilitet att förändra
eller byta system.
33