Dokumentstatus

System för
tidrapportering och tidplanering
Preliminär specifikation
12 mars 2002
Version 2
1
Sammanfattning
Detta är en preliminär specifikation för 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ösningsförslag samt produktion av systemet. Uppdragsgivare är
Henrik Artman, studierektor för IP-lab.
IP-lab är en avdelning på NADA med ca 20 doktorander. Totalt på NADA finns ca 100
doktorander. Bakgrund till uppdraget är studierektorns problem att ha översikt och statistik
över doktorandernas institutionstjänstgöring. Idag sker doktorandernas tidsrapportering
manuellt och i slutet av året. Planeringen är för studierektorn okänd vilket stoppar möjligheten
att arbeta proaktivt. Olika avdelningar inom NADA har delvis olika rutiner och filosofier för
doktorandernas planering och rapportering, dessutom skiljer det sig mellan olika lärare, kurser
och doktorander.
Det lösningsförslag, iteration nr 2 av 4, som presenteras i dokumentet bygger på inmatning av
aktiviteter som kopplas till respektive kurs. Aktiviteter består av aktuellt moment (tex
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 grupper:
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 databas (PostgreSQL), logik (Java-servletts) och presentation/interaktion (JSPsidor).
Projektgruppen består av 7 personer med olika roller i projektet. Deadline för projektet i dess
helhet är v18. Totalt har cirka 350 timmar lagts ned på förstudie, lösningsförslag samt
specifikation. Senaste version av projektdokumentationen finns tillgänglig via
www.nada.kth.se/projects/proj02/sytt.
2
1
DOKUMENTSTATUS ................................................................................................................... 5
1.1
1.2
SPECIFIKATIONENS SYFTE OCH MÅLGRUPP ........................................................................... 5
VERSIONER OCH FÖRÄNDRINGAR........................................................................................... 5
VERSION DATUM KOMMENTAR ..................................................................................................... 5
2
PROJEKTSTRUKTUR ................................................................................................................. 6
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
3
PROJEKTRAMAR ...................................................................................................................... 6
PROJEKTGRUPP ........................................................................................................................ 6
REFERENSGRUPP...................................................................................................................... 7
RESURSER ................................................................................................................................. 7
PRIORITERING .......................................................................................................................... 7
ÄNDRINGSHANTERING ............................................................................................................. 8
PROJEKTAVSLUT ...................................................................................................................... 8
PROJEKTGRUPPENS ÄGANDERÄTT ......................................................................................... 8
PROBLEMBESKRIVNING .......................................................................................................... 9
3.1
3.2
3.3
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.5
4
BAKGRUND ............................................................................................................................... 9
SYFTE ...................................................................................................................................... 10
MÅL ........................................................................................................................................ 10
KRAV OCH AVGRÄNSNINGAR ................................................................................................ 10
FUNKTIONSKRAV ............................................................................................................. 10
SYSTEMKRAV ................................................................................................................... 11
DATORMILJÖ .................................................................................................................... 11
AVGRÄNSNINGAR ............................................................................................................ 12
ANVÄNDARE .................................................................................................................... 12
LÖSNINGSFÖRSLAG ................................................................................................................ 14
4.1
4.2
4.2.1
4.2.2
4.2.3
4.2.4
4.2.5
4.3
4.4
4.4.1
4.4.2
4.4.3
4.5
4.5.1
4.5.2
4.5.3
ÖVERSIKT ............................................................................................................................... 14
TEKNISKT LÖSNINGSFÖRSLAG .............................................................................................. 14
GENERELLT ...................................................................................................................... 14
DESIGNPARAMETRAR FÖR VAL AV TEKNISK LÖSNING .................................................... 14
VAL AV TEKNISK LÖSNING .............................................................................................. 15
DATASTRUKTUR .............................................................................................................. 15
VAL AV TEKNISK PLATTFORM ......................................................................................... 16
”PROOF OF CONCEPT” .......................................................................................................... 17
ALTERNATIVA LÖSNINGAR.................................................................................................... 17
FÖRÄNDRADE RUTINER ................................................................................................... 17
EXCEL .............................................................................................................................. 17
FÄRDIG DATABASLÖSNING .............................................................................................. 17
SKISS AV ANVÄNDARGRÄNSSNITTET .................................................................................... 18
FUNKTIONSBESKRIVNING AV DOKTORANDSIDORNA ....................................................... 18
FUNKTIONSBESKRIVNING FÖR LÄRARE ........................................................................... 21
FUNKTIONSBESKRIVNING FÖR STUDIEREKTOR................................................................ 23
3
5
PROJEKTPLAN ........................................................................................................................... 28
5.1
5.2
5.3
5.4
5.4.1
5.4.2
5.4.3
5.5
5.6
6
6.1
6.2
7
7.1
7.2
7.3
7.4
ÖVERSIKT ............................................................................................................................... 28
PROJEKTETS FASER ............................................................................................................... 28
DESIGN AV ANVÄNDARGRÄNSSNITT ..................................................................................... 29
DOKUMENTATION .................................................................................................................. 30
ANVÄNDARDOKUMENTATION ......................................................................................... 30
SYSTEMDOKUMENTATION ............................................................................................... 30
PROJEKTDOKUMENTATION .............................................................................................. 30
SYSTEMUTVECKLING ............................................................................................................. 31
PROJEKTAVSLUT & PRESENTATION ..................................................................................... 31
RISKANALYS .............................................................................................................................. 32
IDENTIFIERADE RISKOMRÅDEN ............................................................................................ 32
GENOMGÅNG AV RISKOMRÅDEN FÖR PROJEKTET .............................................................. 32
BILAGOR...................................................................................................................................... 34
BILAGA 1 - RESURSFÖRDELNING (ARBETSTID) ................................................................... 34
BILAGA 2 – DETALJPLANERING AV AKTIVITETER ............................................................... 35
BILAGA 3 – FÖRSLAG TILL DATASTRUKTUR ........................................................................ 36
BILAGA 4 SKISSER AV ANVÄNDARGRÄNSSNITT (PROTOTYP 1) ........................................... 40
4
1 Dokumentstatus
1.1
Specifikationens syfte och målgrupp
Detta dokument är en preliminär specifikation för System för Tidrapportering och
Tidplanering, nedan kallat SYTT. Avsikten är att tydliggöra projektets bakgrund, syfte och
avgränsningar liksom presentera vårt lösningsförslag tillsammans med projektplan och
riskanalys.
Specifikationen är skriven för två olika målgrupper, uppdragsgivare/beställare samt internt för
projektgruppen. Målet är att alla ska få samma bild av projektet. Mer specifikt är detta
dokument uppdragsgivarens möjlighet att se, och bevis på, att projektgruppen förstår
problematiken samt hur det föreslagna systemet fungerar, vilka problem det löser och vilka
förväntningar som är rimliga. Det åligger beställaren att uppmärksamma projektledaren på
eventuella synpunkter.
Internt för projektgruppen fyller den preliminära specifikationen två syften, dels att sätta sig
in i problematiken och utforma ett lösningsförslag, dels som underlag för ett fortsatt arbete.
En specifikation är ett levande dokument i den meningen att ändringar kommer ske under
arbetets gång. Den preliminära specifikation kommer, efter godkännande av beställaren, att
förändras och utökas för att till slut nå status av slutgiltig specifikation. När sedan beställare
och projektledning är överens om att innehållet i denna är korrekt kommer specifikationen att
låsas, det vill säga alla förändringar därefter klassas som ändringar med tillhörande process
för ändringshantering.
Senaste version av specifikationen och övriga projektdokument finns tillgängliga på
www.nada.kth.se/projects/proj02/sytt/.
1.2
Versioner och förändringar
Version
2
1
Datum
12 mars
8 mars
Kommentar
Uppdaterad datastruktur (bilaga 3)
Preliminär specifikation
5
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 är 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 är att definiera problem och mål samt att ansvara för,
och utvärdera, effekten av systemets användning. Han har befogenhet att besluta om
projektets avslutande liksom att begära ändringar.
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. Han har
befogenhet att styra projektets inriktning, mål samt att hantera relationen till uppdragsgivaren.
Till vilken grad projektet lyckas med sin uppgift avgörs av två olika instanser, där
uppdragsgivarens utvärdering och uppföljning är den för oss 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) med uppgift att skapa förutsättningar för projektgruppen att nå sina mål.
Han ansvarar för att planera och följa upp projektgruppens arbete samt att projektet
genomförs inom ramarna för tid och resurser.
Dokumentation & Administration
MariAnne Ygberg (MY) med ansvar för dokumentationens utformning och innehåll samt att
nödvändig information och resurser finns tillgänglig(a) under projektets gång.
Användare/Gränssnitt
Kerstin Lindbergson (KL) och Magnus Schylström (MS) med 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) med ansvar för systemets inre struktur och uppbyggnad.
6
2.3
Referensgrupp
Referensgruppen är rådgivande avseende systemets funktionella innehåll samt kommande
användning. De ger råd och förslag till systemets utformning inom ramen för
kravbeskrivning. Deras deltagande ger 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 antas varje projektmedlem arbeta
motsvarande fyra heltidsveckor. Totalt förfogar alltså projektet över cirka 1100 timmar,
fördelat på 7 personer á160 timmar. Av dessa har den 8 mars ca 350 timmar utnyttjats.
Projektgruppen har tillgång till utvecklingsmiljö i UNIX genom Nadas terminalsalar. Macdatorer finns tillgängliga för arbete med grafisk design och dokumentation. En projektplats
finns tillgänglig under afs/nada.kth.se/misc/projects/proj02/sytt med tillhörande webbplats
www.nada.kth.se/projects/proj02/sytt.
2.5
Prioritering
Den första fasen av detta projekt har haft formen av förstudie som sedan har utvidgats till ett
lösningsförslag för utformning av ett tidrapporteringssystem. Uppdragsgivarens krav är att
projektet ska ta fram en prototyp för sådant system. Projektet har som mål att skapa en
funktionell prototyp som uppfyller så stor del av kravspecifikationen som möjligt. Detta
måste dock ske inom ramarna för de begränsade resurser i form av tidsperiod och antal
timmar som finns.
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 beskrivits tidigare. Då både
resurser och tidsperiod är låsta kommer vi tvingas anpassa kraven på funktionalitet för att att
inte ha orimliga förväntningar på projektets resultat.
Funktioner
Resurser
Tid
En prioritering av prototypens funktioner kommer att ske i samråd med uppdragsgivaren
under vecka 11 och 12 då systemdesignen färdigställts. Innan dess är det svårt att uppskatta
resursbehovet för de olika ingående delarna. Det är projektledarens ansvar att projektet håller
sig till denna prioritering samt att, tillsammans med uppdragsgivaren och övriga
7
projektmedlemmar, säkerställa att förväntningarna är rimliga i förhållande till tillgängliga
resurser.
2.6
Ändringshantering
Allt sedan starten av projektet har det funnits kontinuerliga kontakter med uppdragsgivaren.
Detta kommer att fortsätta under hela projektets varaktighet. Det är endast uppdragsgivaren
som har befogenhet att begära ändringar i specifikationen. Alla ändringar skall gå genom
projektledaren som har rätt att neka, alternativt föreslå reduceringar i funktonaliteten för att
kompensera den ökande arbetsbördan.
Meningen med att låsa specifikationen är att undvika sena förändringar som omintetgör redan
nedlagt arbete eller på annat sätt stör projektplanen. Då detta projekt går inom ramen för en
kurs, med en kompetent uppdragsgivare och i avsaknad av faktisk affärsrelation finns inget
behov av formaliserad ändringshantering. Skulle sådant behov uppstå är det projektledarens
ansvar att upprätta rutiner kring detta.
Till att börja med kommer ingen formell process för ändringshantering finnas internt inom
projektgruppen. Det är projektledarens ansvar att upprätta sådan vid behov.
2.7
Projektavslut
Projektet avslutas i samband med kursens slut, innan dess ska ett antal delmål uppnåtts. Det
första delmålet är denna specifikation. Nästa delmål är färdigställandet av specifikationen
vilket består av systemdesign (logik, informationsflöden och datastruktur) och användartest,
vilket beräknas vara klart i början av v12. Därefter sker produktion, testning samt
dokumentation som avslutas i och med en förhandspresentation av projektet under v18.
Slutpresentation hålls i början av 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 fungerande och driftbart system, sker
utanför kursen, tex som sommararbete för någon gruppmedlem.
2.8
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.
8
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 i olika former och i olika roller. Den indelning som finns är; föreläsningar, övningar,
laborationer, kursassistent, handledning, examensarbete, 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.
9
3.2
Syfte
Projektet har 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 historik och statistik innebär att planeringen avsevärt försvåras.
3.3
Mål
Projektet har till mål att lösa de nuvarande rapporteringsproblemen genom att utarbeta ett
tidrapporteringssystem för doktorander på IP-lab. Detta ska inte vara ett rent kontrollsystem,
utan det ska även finnas för att hjälpa doktoranderna planera och redovisa sitt arbete. Det nya
systemet ska ge doktorander, lärare och studierektorer en översikt över det arbete
doktoranderna bedriver.
Tidrapporteringssystemet ska inte vara en kompromiss mellan dagens olika system, utan de
blivande användarna ska övertygas av systemets funktonalitet.
3.4
3.4.1
Krav och avgränsningar
Funktionskrav
Följande krav på projektet har identifierats ur den ursprungliga uppdragsspecifikationen och
intervjuer med uppdragsgivare och referensgrupp:
1. Doktoranderna ska enkelt kunna rapportera timmar.
2. Doktoranderna ska kunna planera timmar.
3. Doktoranderna ska ha översikt över sin arbetsinsats totalt och per kurs.
4. Doktoranderna ska kunna se hur många och vilka timmar han/hon arbetade föregående
år
5. Lärarna ska ha översikt över hur många timmar varje doktorand lagt ned på
hans/hennes kurs.
6. Lärarna ska kunna planera in timmar åt doktoranderna på hans/hennes kurs.
7. Studierektorerna ska ha översikt över doktorandernas totala arbetsinsats.
8. Studierektorerna ska ha översikt över doktorandens arbetsinsats per kurs.
9. Studierektorerna ska ha översikt över totala antalet doktorandtimmar per kurs.
10. Studierektorerna ska kunna se statistik över vad som hänt föregående år.
11. Studierektorerna ska ha ett administrativt gränssnitt med möjlighet att redigera
samtliga uppgifter.
10
12. Lärare och doktorander ska kunna ge önskemål om kurser de vill få eller ge.
13. Det ska vara möjligt att exportera uppgifter till Excel för vidare redigering.
Förtydligande av ovanstående punkter
De flesta av ovanstående punkter är som sagt identifierade direkt ur specifikationen, medan en
del har lagts till eller modifierats. De beslut och ställningstagande som har tagits förklaras
nedan.
Punkt 6:
Under intervju med referensgruppen framgick att det på vissa avdelningar fanns intresse för
lärarna att kunna planera in doktorandernas arbetsinsats på sina kurser. För att systemet ska
vara flexibelt för en eventuell utökad användning till fler avdelningar än IP-lab, har därför
denna möjlighet lagts till.
Punkt 12:
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 som
berörs närmare under Avgränsningar. 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 har vi funnit att intresset för en sådan funktionalitet är i det
närmaste obetydligt. Det krav som återstår är att det ska finnas möjlighet för lärare och
doktorander att lägga in önskemål om aktiviteter man önskar få respektive ge. Till detta ska
en enkel sökfunktion implementeras.
3.4.2
Systemkrav
Utöver ovanstående funktionskrav ställs följande systemkrav:
 Databasen ska vara applikationsoberoende.
 Tyngdvikten av arbetet ska skötas av servern.
 Designen ska vara väl dokumenterad utifrån både premisser och övervägningar vid
design.
 Det finns inga krav ställda på grafisk utformning.
 Systemet ska kunna hantera samtliga tidigare år.
 Systemet ska vara webbaserat.
 Tillträde till systemet ska ske genom ett inloggningsförfarande för att förhindra
obehörigas intrång.
3.4.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 ska vara webbaserat ställs inga specifika krav på klientprogramvaror.
Serverprogramvara bör vara av standardtyp och ej innebära nya licenskostnader för
Nada.
Inga speciella krav på hastighet ställs, 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.
11


3.4.4
Nadas personal använder Mac, Unix och/eller PC. Systemet bör 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.
Avgränsningar
Enligt förklaring under 2.5 Resurser och 2.6 Prioritering begränsas projektet av tillgängliga
resurser. Utöver detta sker en avgränsning enligt följande punkter:
1. Det färdiga resultatet av detta projekt ska vara en fungerande prototyp, inte en
driftfärdig lösning.
2. Systemet är inte ett bokningssystem.
3. Systemet är inte ett meddelandesystem.
4. Systemet ska inte innefatta rapportering för lärare, gästföreläsare eller studenter, utan
riktar sig enbart till doktorander.
5. Detta är ett fristående system.
6. Systemet är anpassat till IP-lab, men med övriga Nadas rutiner i åtanke.
7. Den grafiska utformningen av doktorandernas historiksida kommer att vara enkel, för
redigering kan export ske.
Förtydligande av ovanstående punkter
Punkt 2:
Detta är nära kopplat till punkt tolv under Funktionskrav. Ursprungligen fanns förslaget om
en bokningsmöjlighet baserat på lärarnas och doktorandernas föreläsningsönskemål. Systemet
skulle kunna matcha dessa önskemål och sedan skulle databasen uppdateras efter acceptans av
lärare respektive doktorand. Efter intervjuer med referensgruppen förefaller det inte troligt att
systemet skulle användas till bokning och vidare diskussion med uppdragsgivaren ledde till
att bokningsmöjligheten uteslöts.
Punkt 5:
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.
Punkt 6:
Henrik Artman på IP-lab är vår uppdragsgivare och tidrapporteringssystemet kommer att vara
anpassat till hans avdelning. Dock har prototypen utarbetas för att i en framtid även kunna
implementeras på övriga Nada.
3.4.5
Användare
De presumtiva användarna till vårt system 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 upplever vi att det
finns 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.
12
Gemensamt för alla grupperna ä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 bör
behöva tas 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.
Vi gjorde bedömningen att vi, för att få doktoranderna, lärarna och studierektorerna på nada
att använda vårt system i viss mån måste anpassa systemet, 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 bör emellertid göras 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 har det framkommit att en av de viktigaste aspekterna för doktorander är att det
snabbt går att rapportera in timmar till systemet. Vi har därför lagt till genvägar, för 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. Det är därmed viktigt att systemet är
kompatibelt med den teknik som är tillgänglig på nada.
13
4 Lösningsförslag
4.1
Översikt
Den förstudie som delvis presenterats ovan har bildat underlag för ett lösningsförslag.
Förslaget är utformat utifrån uppdragsgivarens förväntningar och krav, främst gällande
användarsidan.
Det beskrivna lösningsförslaget (prototypen) är en andra iteration av systemet, under vecka 11
kommer den att genomgå ytterligare användartester. (En mer utförlig beskrivning över de
olika faserna i systemets utveckling ges i avsnitt 5 – Projektplan.)
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.
4.2
4.2.1
Tekniskt lösningsförslag
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.
4.2.2
Designparametrar för val av teknisk lösning
Beställarens önskemål.
Beställaren vill se ett tidsplanerings- och rapporteringssystem som
man kan nå via webbgränssnitt.
Systemets funktion.
Mängden av samt karaktären på den information som skall
behandlas i applikationen är sådan att det verkar 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) är önskvärt. De strikta tidsramarna gör att
produktionen måste utföras som ett antal parallella processer.
14
4.2.3
Val av teknisk lösning
Utifrån ovan beskrivna parametrar har vi format ett förslag till teknisk lösning enligt
nedanstående konceptuella 3-lager modell.
Presentation/Interaktion
Logik
Datalagring
JSP-sidor
Java Servlets
SQL
Den föreslagna lösningen bygger på utnyttjandet av en ensam databas för lagring av data.
Dataåtkomst sköts av logikkomponenterna. All presentation och interaktion kommer att ske i
presentationslagret som utbyter data med logikkomponenterna. En sådan lösning tillåter
parallell utveckling av komponenter, oberoende av övriga komponenter. Detta förutsätter att
den grundläggande systemdesignen är väl utformad och att specifikationen eller designen inte
behöver genomgå större förändringar under kodningsfasen. Det är även viktigt att
utformningen av gränssnitt mellan de olika komponenterna specificeras ordentligt, samt att
rutinerna för ändringshantering följs av projektets medlemmar.
Det kommer att skapas en JSP-sida per användarsida, dock kommer vissa JSP-sidor att
genereras från en och samma servlett. Det kommer även att skapas ett antal specifika servletts
som genererar vanligt återkommande element i gränssnittet, exempel på detta är drop-downmenyer.
4.2.4
Datastruktur
En skiss över datastrukturen finns bland bilagorna. Denna kommer specificeras under vecka
11, för mer information se avsnitt 5 Projektplan.
15
4.2.5
Val av teknisk plattform
Under utvecklingsfasen körs alla program på de klienter som finns i KTH:s datasalar.
Om det blir aktuellt att installera lösningen permanent hos systemgruppen är en överflyttning
till deras system en relativt smärtfri process.
PostgreSQL 7.0 är den modell och version av databasmotor vi använder.
Vi kommunicerar med databasen via jdbc.
Tomcat 4.0 är den version av webbserver vi använder under utvecklingen. Tomcat klarar att
hantera både JSP- och Servletteknologi. Eventuellt byts denna teknik mot användning av
Apache med Tomcat-plugin, beroende av vad systemgruppen önskar.
För kompilering och exekvering av javakod används jdk 1.3.0.
16
4.3
”Proof Of Concept”
Den föreslagna och konceptuellt beskrivna tekniska lösningen är, om inte standard,
åtminstone ett beprövat sätt att bygga webbapplikationer. För att bekräfta att den föreslagna
tekniska plattformen fungerar, samt att projektgruppen besitter nödvändig kompetens, har ett
”proof-of-concept” genomförts. Den ovan beskrivna plattformen sattes upp och vi har
bekräftat att den fungerar, så till vida att vi kan skriva till, och läsa från, en databas via
servlets som utnyttjar möjligheterna i jdbc.
Under testerna har många frågetecken rätats ut, men även några nya uppstått. Den arkitektur
som valts känns än så länge bra. Nästa steg är att testa lösningen med hantering av inloggning
samt fullt utnyttjande av JSP-funktionaliten.
4.4
Alternativa lösningar
Det lösningsförslag 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 ett problem
som mycket väl kan lösas med andra metoder.
Den föreslagna lösningen är utarbetad med viss beaktning av att genomföra ett projekt från
start till slut. Hade motsvarande förstudie gjorts av debiterande konsulter skulle resultatet bli
ett annat, då en avvägning av kostnad relativt effekt ständigt måste göras.
Problemen som systemet löser skulle kanske kunna minskas eller lösas med hjälp av följande
alternativa lösningar.
4.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.
4.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, tex fungerar det inte å 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.
4.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.
17
4.5
4.5.1
Skiss av användargränssnittet
Funktionsbeskrivning av doktorandsidorna
Överst på varje doktorandsida, undantaget pop-up fönstren, finns en meny där doktoranden
kan välja vilken av sina sidor de vill se genom att trycka på länkar till ; startsidan,
historiksidan, resurssidan, mina uppgifter-sidan, de kan även välja att logga ut från systemet,
genom att trycka på länken ”logga ut”.
Undantaget startsidan, har doktorandsidorna längst ner (gäller ej pop-up fönstren) en länk,
”till startsidan” ,som tar doktoranden tillbaka till dennes startsida.
Längst upp till vänster på varje pop-up fönster finns en länk/knapp för att stänga fönstret.
Startsidan (figur 1)
Under menyraden ligger ett fält där doktoranden kan skriva in privata anteckningar (dessa
kommer därmed inte vara åtkomliga för andra användare). Anteckningarna sparas genom att
doktoranden trycker på ”spara” -knappen. Till höger om detta ligger en statusbar, som visar
hur många av doktorandens totala timmar instutitionstjänst under läsåret som är
Genomförda(grönt fält), Planerade(blått fält) respektive Kvar att göra(rött fält).
Nästföljande fält visar doktorandens kurser för det aktuella läsåret, doktoranden har här även
möjlighet att välja att titta på ett annat läsår i drop-down menyn Byt läsår. Varje kurs anges
med en kod (doktoranden får själva välja om kurskod eller förkortning för kursnamnet ska
anges här. Återkommer till detta på doktorand sidan ”Mina uppgifter) och med kursnamn.
Koden är en länk till doktorandens kurssida. Framför varje kurs kod och kursnamn finns en
pil som i normalt läge pekar åt höger, klickar användaren på denna expanderas kursen (den
tidigare nämnda pilen pekar då neråt), så att användaren kan se hur mycket tid de har planerat
och genomfört på respektive moment inom varje kurs, exempelvis föreläsning, övning. Längst
ner i listan på kurser finns ett exempel på en expanderad kurs.
Längst ner på sidan finns en ”addera aktivitet”- knapp. Om användaren klickar på denna
dyker ett pop-up fönster upp, där användaren kan lägga till genomförda och planerade
aktiviteter.
Addera aktivitet från start, pop-up fönster (figur 2)
Under rubriken finns en drop-down meny där användaren kan välja inom vilken kurs
aktiviteten utfördes. Under ligger en drop-down meny där användaren får välja moment
(föreläsning, övning etc.), och skriva in hur många timmar som ska registreras som
lektionstid. I de fall då detta är relevant räknar systemet ut hur många förberedelsetimmar
som är standard till det angivna antalet lektionstimmar. Användaren har här möjlighet att
ändra, och ange fler förberedelsetimmar än de som standarden ger, vilket markeras på lärarnas
och studierektorernas kurssidor. Det är sedan upp till dem att agera om antalet timmar är
felaktigt. Systemet räknar ut det totala antalet timmar och anger detta. Doktoranden får efter
detta ange ett datum eller datumintervall för aktiviteten/aktiviteterna. Användaren får med
hjälp av radioknappar välja om det är en planerad eller genomförd aktivitet som ska läggas
till.
18
Användaren har även möjlighet att skriva in en beskrivning av aktiviteten, vilken kommer
ligga publikt. Detta är inte obligatoriskt, vilket markeras genom att detta inmatningsfält inte är
markerat med en stjärna som anger att uppgiften är obligatorisk, vilket alla de andra
aktiviteterna är. För att genomföra adderingen av aktivitet har användaren två knappar: dels
”Addera!” för att addera aktiviteten och sedan komma tillbaka till samma pop-up fönster och
ha möjlighet att addera fler aktiviteter, dels ”Addera och stäng” för att addera aktiviteten och
stänga pop-up fönstret.
Addera aktivitet från kurs, pop-up fönster (figur 3)
Användaren får med hjälp av radioknappar välja om det är en planerad eller genomförd
aktivitet som ska läggas till. Under ligger en drop-down meny där användaren får välja
moment (föreläsning, övning etc.), och skriva in hur många timmar som ska registreras som
lektionstid. I de fall då detta är relevant räknar systemet ut hur många förberedelsetimmar
som är standard till det angivna antalet lektionstimmar. Användaren har här möjlighet att
ändra, och ange fler förberedelsetimmar än de som standarden ger, vilket markeras på lärarnas
och studierektorernas kurssidor. Det är sedan upp till dem att agera om antalet timmar är
felaktigt. Systemet räknar ut det totala antalet timmar och anger detta. Doktoranden får efter
detta ange ett datum eller datumintervall för aktiviteten/aktiviteterna.
Användaren har även möjlighet att skriva in en beskrivning av aktiviteten, vilken kommer
ligga publikt. Detta är inte obligatoriskt, vilket markeras genom att detta inmatningsfält inte är
markerat med en stjärna som anger att uppgiften är obligatorisk, vilket alla de andra
aktiviteterna är. För att genomföra adderingen av aktivitet har användaren två knappar: dels
”Addera!” för att addera aktiviteten och sedan komma tillbaka till samma pop-up fönster och
ha möjlighet att addera fler aktiviteter, dels ”Addera och stäng” för att addera aktiviteten och
stänga pop-up fönstret.
Ändra en inlagd aktivitet, pop-up fönster (figur 4)
De uppgifter som tidigare lagts in om aktiviteten är synliga, men användaren ges möjlighet att
skriva över dessa. Användaren kan mata in hur många timmar som ska registreras som
lektionstid. I de fall då detta är relevant räknar systemet ut hur många förberedelsetimmar
som är standard till det angivna antalet lektionstimmar. Användaren har här möjlighet att
ändra, och ange fler förberedelsetimmar än de som standarden ger, vilket markeras på lärarnas
och studierektorernas kurssidor. Det är sedan upp till dem att agera om antalet timmar är
felaktigt. Systemet räknar ut det totala antalet timmar och anger detta. Doktoranden anger ett
datum eller datumintervall för aktiviteten/aktiviteterna.
Användaren har möjlighet att skriva in en beskrivning av aktiviteten, vilken kommer ligga
publikt. Detta är inte obligatoriskt, vilket markeras genom att detta inmatningsfält inte är
markerat med en stjärna som anger att uppgiften är obligatorisk, vilket alla de andra
aktiviteterna är. För att genomföra adderingen av aktivitet har användaren två knappar: dels
”Spara!” för att spara ändringar och stänga pop-up fönstret, dels ”Avbryt!” för att stänga popup fönstret utan att spara eventuella ändringar.
Överför aktivitet från planerad till genomförd, pop-up fönster (figur 5)
De uppgifter som tidigare lagts in om aktiviteten är synliga, men användaren ges möjlighet att
skriva över dessa. Användaren kan skriva in hur många timmar som ska registreras som
lektionstid. I de fall då detta är relevant räknar systemet ut hur många förberedelsetimmar
som är standard till det angivna antalet lektionstimmar. Användaren har här möjlighet att
ändra, och ange fler förberedelsetimmar än de som standarden ger, vilket markeras på lärarnas
19
och studierektorernas kurssidor. Det är sedan upp till dem att agera om antalet timmar är
felaktigt. Systemet räknar ut det totala antalet timmar och anger detta. Doktoranden får ange
ett datum eller datumintervall för aktiviteten/aktiviteterna. När användaren klickar på
”Överför” –knappen överförs aktiviteten från att vara planerad till att vara genomförd och
eventuella ändringar i antal timmar, datumperiod sparas.
Doktorandens kurssida (figur 6)
På denna sida finns mail-to länkar kopplade till den kursansvariga läraren, samt
kursassistenten.
Användaren har möjlighet att välja vilken kursomgång som ska visas i en drop-down meny.
Det finns ett fält där doktoranden kan lägga in egna kommentarer om kursen och välja om
dessa ska vara privata (bara tillgängliga för doktoranden) eller offentliga (tillgängliga för
studierektor och lärare).
Användaren kan se vilka moment som är planerade respektive genomförda för kursen under
valt läsår. De lektions-, förberedelse- och totala antal timmar doktoranden lagt ner på kursen
anges i normalt läge per moment. Man kan välja att expandera ett moment, för att se på antal
timmar för alla aktiviteter inom ett moment, genom att trycka på pilen till vänster om
kursnamnet. Denna ändras då från att peka till höger till att peka nedåt, på de expanderade
aktiviteterna.
Användaren har möjlighet att ändra eller radera genomförda aktiviteter. Trycker användaren
på ”Radera” -knappen, så tas aktiviteten bort, trycker användaren på ”Ändra” –knappen, så
öppnas pop-up fönstret ”Ändra en inlagd aktivitet”.
Vad det gäller planerade aktiviteter har användare även möjlighet att överföra planerade
aktiviteter till genomförda. När användaren trycker på ”Genomförd” –knappen, så öppnas
pop-up fönstret ”Överför aktivitet från planerad till genomförd”.
Längst ner på sidan finns en ”addera aktivitet” -knapp. Om användaren klickar på denna
dyker ett pop-up fönstret ”Addera aktivitet från kurs”.
Mina uppgifter (figur 7)
På denna sida har doktoranden möjlighet att skriva in och ändra sina personliga uppgifter och
inställningar. Doktoranden får med radio-knappar välja om man vill ha ett ”påminnelsemejl”.
Denna funktion skickar ut ett mejl, med direktlänk till systemet, när användaren inte lagt in
några timmar på ca: två veckor. ”Påminnelsemejl” är även en länk till en hjälp-text som
förklarar vad ett påminnelsemejl är. Doktoranden kan här även välja om kursens kurskod eller
en förkortning av kursnamnet ska anges på dennes sidor. Knappen ”spara ändringar” sparar de
värden som doktoranden matat in.
Doktoranden kan på denna sida välja ett läsår med drop-down meny och se hur deras totala
antal timmar instutitionstjänstgöring för det valda läsåret har räknats ut.
Doktoranden har möjlighet att ändra sitt löseord genom att skriva in det nya lösenordet, samt
verifiera bytet genom att skriva in sitt gamla lösenord. ”Byt!”- knappen genomför byte av
lösenord.
20
Resurser (figur 8)
Denna sida består av två separata funktioner: Doktoranden kan göra ett inlägg eller titta på
vad andra lagt in.
Beskriva ett inlägg
Doktoranden väljer mellan kategorier av ämnen (t.ex. datalogi) i en drop-down meny och
lägger in ett sista datum för inlägget. Vid detta datum tas inlägget bort från listan på erbjudna
resurser. Doktoranden lägger in en rubrik för sitt inlägg och eventuellt en beskrivning. Den
inloggade doktorandens mejladress läggs in av systemet i rutan kontaktperson, men
doktoranden kan ändra detta fält. Ett klick på ”Spara!”- knappen gör att inlägget sparas som
ett erbjudande.
Visa resurser
Doktoranden väljer mellan kategorier av ämnen (t.ex. datalogi) i en drop-down meny och
väljer med radioknappar om de vill se förfrågningar, erbjudanden eller om de vill se både och.
Deras träffar inom ämnesområdet och typ av inlägg kommer upp som rubriker med länkar till
en beskrivning av respektive inlägg.
Historik (figur 9)
Denna sida samlar doktorandens gru- tjänstgöringstimmar per kurs under varje läsår denne
tjänstgjort på nada. Doktoranden kan med ”Skriv ut” – knappen välja att skriva ut sidan direkt
och/eller att exportera sidan till Excel för redigering genom att rycka på knappen ”Exportera
till Excel”.
4.5.2
Funktionsbeskrivning för lärare
Överst på varje lärarsida, med undantag för pop-up fönstret för att lägga in planerade timmar
för doktorander, finns en meny där läraren kan välja antingen resurs sidan, mina uppgifter
eller startsidan de även kan välja att logga ut från systemet genom att trycka på länken ”logga
ut”. Längst ner på varje sida finns också en länk för att komma tillbaka till startsidan,
undantagna är själva startsidan och pop-up fönstret.
Startsidan (figur 10)
Under menyraden anges lärarens namn och e-postadress, som är ändringsbar.
 Dina kurser, här visas lärarens egna kurser(dvs de som läraren är kursansvarig för)
för det aktuella läsåret, läraren har även möjlighet att välja att titta på ett annat läsår i
drop-down menyn med läsår. Varje kurs anges med en kod (antingen visas kurskod
eller förkortning av kursnamnet. Läraren väljer detta själv på ”Mina uppgifter” sidan)
och med kursnamn. Koden är en länk till lärarens kurssida.
 Visa andra kurser, genom att klicka på ”visa kurs” kan läraren titta på andra kursers
doktorandinsatser som läraren själv inte är kursansvarig för.
 Visa doktorand, genom att klicka på ”visa doktorand” kommer läraren till lärarnas
doktorandsida.
Lärarens kurssida (figur 11)
På denna sida anges namnet på den kursansvariga läraren, samt namnet på kursassistenten, det
finns även mailto länkar kopplade till respektive persons email adress.
Läraren har möjlighet att välja vilken kursomgång som ska visas från en drop-down meny.
21
Det finns ett fält där läraren kan lägga in egna kommentarer som kopplas till kursen. En tabell
som hämtar sina värden från databasen visar doktorandernas planerade och genomförda
insatser på den aktuella kursen.
Läraren kan se vilka moment som är planerade respektive genomförda för kursen under valt
läsår. De lektions-, förberedelse- och totala antal timmar doktoranden lagt ner på kursen anges
i normalt läge per moment. Man kan välja att expandera ett moment, för att se på antal timmar
för alla aktiviteter inom ett moment, genom att trycka på pilen till vänster om kursnamnet.
Denna ändras då från att peka till höger till att peka nedåt, på de expanderade aktiviteterna.
Om en doktorand har lagt in timmar under genomförda aktiviteter som överskrider den
normala förberedelsetiden så visas dessa med röd text för att uppmärksamma läraren. Genom
att trycka på bocken för att avmarkera så ändras färgen tillbaka till svart.
Läraren har möjlighet att ändra eller radera planerade aktiviteter. Trycker läraren på ”Radera”
-knappen, så tas aktiviteten bort, vid tryck på ”Ändra” –knappen, så dyker ett popup-fönster
upp (Detta behandlas vidare i stycket ”Ändra aktivitet”).
Längre ned på sidan finns en ”planera doktorandernas aktiviteter”- knapp. Om läraren klickar
på denna dyker ett popup fönster upp, där läraren kan lägga till planerade aktiviteter för en
doktorand.
Underst på sidan finns snabblänkar för att komma till sidor för lärarens andra kurser, som
denne är kursansvarig på, samt en länk tillbaka till startsidan
Lärarens doktorandsida (figur 12)
Under menyraden anges doktorandens namn, e-post(mailto-länk), avdelning och handledare.
Till höger om detta ligger en statusbar, som visar hur många av doktorandens totala timmar
instutitionstjänst under läsåret som är Genomförda(grönt fält), Planerade(blått fält) respektive
Kvar att göra(rött fält). Detta anges även i textform i en ruta under statusbaren, där antalet
genomförda och planerade timmar subtraheras från doktorandens totala timmar
instutitionstjänst under läsåret för att få fram hur många timmar doktoranden har kvar att göra
detta läsår. Informationen hämtas från databasen
Doktorandens kurser för det aktuella läsåret visas med kurskod eller förkortning för
kursnamnet samt med kursnamn. Koden är en länk till lärarens kurssida. I kolumnerna till
höger om kursnamnet anges doktorandens genomförda och planerade timmar per kurs. Alla
kursers timmar summeras längst ner för att ge totalt antal timmar. Framför varje kurs kod och
kursnamn finns en pil som i normalt läge pekar åt höger, klickar användaren på denna
expanderas kursen (den tidigare nämnda pilen pekar då neråt), så att användaren kan se hur
mycket tid de har planerat och genomfört på respektive moment inom varje kurs, exempelvis
föreläsning, övning. Längst ner i listan på kurser finns ett exempel på en expanderad kurs.
Läraren har även möjlighet att välja att titta på ett annat läsår i drop-down menyn Byt läsår.
Mina uppgifter (figur 13)
På denna sida har läraren möjlighet att skriva in och ändra sina personliga uppgifter och
inställningar. läraren får med radio-knappar välja om denne vill visa kursens kurskod eller en
förkortning av kursnamnet ska anges på dennes sidor. Knappen ”spara ändringar” sparar de
värden som läraren matat in.
22
Läraren har möjlighet att ändra sitt löseord genom att skriva in det nya lösenordet, samt
verifiera bytet genom att skriva in sitt gamla lösenord. ”Byt!”- knappen genomför byte av
lösenord.
Sök Resurser (figur 14)
Denna sida består av två separata funktioner: Läraren kan göra ett inlägg eller titta på vad
andra lagt in.
Beskriva ett inlägg
Läraren väljer mellan kategorier av ämnen (t.ex. datalogi, numme) i en drop-down meny och
lägger in ett sista datum för inlägget. Vid detta datum tas inlägget bort från listan på
efterfrågade resurser. Läraren lägger in en rubrik för sitt inlägg och eventuellt en beskrivning.
Den inloggade lärarens email adress läggs in av systemet i rutan kontaktperson, men läraren
kan ändra detta fält. Ett klick på ”Spara!”- knappen gör att inlägget sparas som en förfrågan.
Visa resurser
Läraren väljer mellan kategorier av ämnen (t.ex. datalogi) i en drop-down meny och väljer
med radioknappar om de vill se förfrågningar, erbjudanden eller om de vill se både och. Deras
träffar inom ämnesområdet och typ av inlägg kommer upp som rubriker med länkar till en
beskrivning av respektive inlägg.
Planera doktorand aktiviteter (figur 15)
Längst upp till höger finns en länk/knapp för att stänga fönstret.
Läraren väljer vilken doktorand som han vill planera för samt vilken typ av moment ur en
drop-down meny. och skriver in hur många timmar som ska registreras som lektionstid. I de
fall då detta är relevant räknar systemet ut hur många förberedelsetimmar som är standard till
det angivna antalet lektionstimmar. Användaren har här möjlighet att ändra, och ange fler
förberedelsetimmar än de som standarden ger, vilket markeras på lärarnas och
studierektorernas kurssidor. Det är sedan upp till dem att agera om antalet timmar är felaktigt.
Systemet räknar ut det totala antalet timmar och anger detta. Användaren får efter detta ange
ett datum eller datumintervall för aktiviteten/aktiviteterna. Användaren har även möjlighet att
skriva in en beskrivning av aktiviteten, vilken kommer ligga publikt. Detta är inte
obligatoriskt, vilket markeras genom att detta inmatningsfält inte är markerat med en stjärna
som anger att uppgiften är obligatorisk, vilket alla de andra aktiviteterna är. För att genomföra
adderingen av aktivitet har användaren två knappar: dels ”Addera!” för att addera aktiviteten
och sedan komma tillbaka till samma popup fönster och ha möjlighet att addera fler
aktiviteter, dels ”Addera och stäng” för att addera aktiviteten och stänga popup fönstret.
4.5.3
Funktionsbeskrivning för studierektor
Överst på varje studierektorsida, undantaget popup fönstren, finns en meny där studierektorn
kan välja vilken av sina sidor de vill se genom att trycka på länkar till; Startsidan, Användar administrationssidan, Kurs-administrationssidan, Variabelsidan, Exportsidan och
Resurssidan. Studierektorn kan även välja att logga ut från systemet, genom att trycka på
länken ”logga ut”.
Undantaget startsidan, har Studierektorns sidor längst ner (gäller ej popup-fönstren) en länk,
”till startsidan” ,som tar användaren tillbaka till dennes startsida.
23
Startsidan (figur 16)
På denna sida ligger följande funktioner:



Användaren kan välja att söka lärare genom att välja lärarens namn i en drop-down
meny eller genom att skriva in namnet i textrutan och trycka på ”Sök!” –knappen,
varpå systemet söker efter namnet i listan på lärare. När en matchning sker slussas
användaren vidare till en sida med information om den valda läraren (Studierektorns
lärarsida).
Användaren kan söka efter en doktorand på precis samma sätt som efter en lärare, vid
matchning visas användaren en sida med information om den valda doktoranden
(Studierektorns doktorandsida).
Användaren kan söka efter en kurs, genom att ange läsår i en drop-down meny.
Därefter väljer användaren antingen kursnamnet i en drop-down meny eller anger
kursens kurskod eller förkortning (t.ex. ”proj” för programutvecklings projekt) och
klickar på ”visa kurs!”- knappen, varpå systemet söker efter kurskoden/förkortningen i
listan på kurskoden/förkortningen. När en matchning sker slussas användaren vidare
till en sida med information om den valda kursen (Studierektorns kurssida).
Det finns även genvägar, länkar till studierektorns administrationssidor.:
 Klickar användaren på länken ”Lägg till ny användare” visas Användaradministrationssidan, som behandlas nedan i stycket med samma namn.
 Användaren kan skriva in ett användarID i textrutan och trycka på ”Gå!” –knappen.
Detta länkar användaren till en Användar-administrationssida, där alla uppgifter om
den valda användaren visas.
 Användaren kan välja att exportera allt varvid man länkas till studierektorns
Exportsida.
Studierektorns lärarsida (figur 17)
I anslutning till uppgifterna om läraren ligger knappen ”Ändra uppgifter”, ett klick på denna
kopplar användaren till Användar-administrationssida, där alla uppgifter om den valda läraren
visas.
Användaren kan välja vilket läsår man vill titta på genom att välja i en drop-down meny, där
det nuvarande läsåret står som default värde.
Efter detta val visas kurserna för det aktuella läsåret. Dessas koder är länkar som tar
användaren till Studierektorns lärare-kurssida för den aktuella läraren och kursen.
Användaren kan välja att låta systemet visa en annan lärare genom att välja lärarens namn i en
drop-down meny eller genom att skriva in namnet i textrutan och trycka på ”Sök!” –knappen,
varpå systemet söker efter namnet i listan på lärare. När en matchning sker slussas
användaren vidare till Studierektorns lärarsida med denna lärares uppgifter.
Studierektorns lärare-kurssida (figur 18)
Högst upp på denna sida intill lärarens personuppgifter ligger en ”Ändra” –knapp, Ett klick på
denna länkar användaren till sidan Administrering av kurs för den aktuella kursen.
Användaren har möjlighet att bli länkade till Studierektorns doktorandsida för de doktorander
som arbetar på kursen genom att klicka på deras namn.
24
I de fall det finns en beskrivning knuten till en aktivitet, kan användaren se hela denna genom
att klicka på ”mer!” –länken.
Användaren kan även se Studierektorns lärare-kurssida för de andra kurserna en lärare är
kursansvarig för genom att klicka på kursens kod.
Studierektorns doktorandsida (figur 19)
I anslutning till uppgifterna om doktoranden ligger knappen ”Ändra uppgifter”, ett klick på
denna kopplar användaren till Användar-administrationssida, där alla uppgifter om den valda
doktoranden visas.
Användaren har ett fält för att lägga in privata kommentarer om den aktuella doktoranden.
Användaren har möjlighet att ändra de siffror som anges för den aktuella doktorandens andel
gru (grundutbildning) arbetstid, föräldraledighet och övrig ledighet. Ett klick på ”Spara
ändringar!” –knappen sparar de nya uppgifter användaren lagt in.
Statusbaren visar hur stor andel av doktorandens totala timmar institutionstjänstgöring som är
genomförda (grön färg), planerade (blå färg) samt som återstår (röd färg).
Användaren kan välja läsår i en drop-down meny. Systemet visar då de kurser där
doktoranden har registrerat planerade eller genomförda timmar under läsåret. Kurskoden är en
länk, som tar användaren till Studierektorn doktorand-kurssida för aktuell doktorand och kurs.
Pilen till vänster om kursnamnet pekar i normalt läge åt höger, klickar användaren på detta
expanderas kursen, varpå pilen pekar neråt och varje moment som doktoranden bokfört
timmar inom visas.
Studierektorn doktorand-kurssida (figur 20)
 I anslutning till uppgifterna om doktoranden finns en ”Ändra” –knapp, Ett klick på
denna länkar användaren till sidan Administrering av kurs för den aktuella kursen.
 I textfälten kan användaren lägga in privat information och kommentarer, som lagras i
systemet när användaren klickar på ”Spara!” -knappen.
 Användaren kan välja att radera en aktivitet en doktorand lagt in genom att trycka på
”radera” –ikonen (soptunnan). Aktiviteten tas då helt bort ur systemet.
 Användaren ändrar doktorandens inlagda aktiviteter genom att trycka på ”ändra” –
ikonen. Detta genererar ett popup-fönster, där användaren kan ändra uppgifterna
angivna för aktiviteten.
 Användaren har möjlighet att flytta planerade aktiviteter till genomförda aktiviteter
genom att trycka på ”genomförd” ikonen.
 Klickar användaren på knappen ”Planera doktorandernas aktiviteter” kommer popupfönstret ”addera aktiviteter” (samma som för lärare), där användaren kan lägga till
aktiviteter för den aktuella doktoranden och kursen.
Studierektor variabler (figur 21)
Användaren har här möjlighet att välja vilka olika alternativ användare ska ha att välja bland
vad det gäller avdelning, befattning, moment och ämnesindelning.
Ett klick på ”radera” –ikonen (soptunnan) medför att alternativet raderas från listan på
möjliga alternativ.
25
Användaren har möjlighet att ändra texten i textfälten och kan med ett klick på ”Spara!” –
knappen spara de ändringar man gjort. Längst ner i varje lista över alternativ finns ett tomt
fält där användaren kan skriva in ett nytt alternativ som ska vara valbart. ”Lägg till” –knappen
lägger till detta alternativ till listan.
Vad det gäller variabler som hur många dagar ett år har etc. så kan användaren i textfältet
skriva in variabelvärdet och spara detta värde i systemet genom att trycka på ”Spara!” –
knappen.
Användaren har möjlighet att, genom inmatning i textfält, ange vilket varningsmeddelande
som ska visas då en doktorand angett fler förberedelsetimmar än standard, samt hur
påminnelsetexten i påminnelsemejlet ska se ut. (Påminnelsemejl skickas ut, till en doktorand
som har valt att ha denna funktion, när det har gått ett antal veckor utan att doktoranden har
registrerat några genomförda eller planerade timmar i systemet.)
Kurs administration (figur 22)
Användaren anger önskat kursår i en drop-down meny.
Användaren kan välja att ändra en kurs, genom att ange önskat kursår i en drop-down meny
och sedan antingen välja kursnamnet i en drop-down meny eller ange kursens kurskod eller
förkortning i textrutan och klicka på ”visa kurs!”- knappen, varpå systemet söker efter
kurskoden/förkortningen i listan på kurskoden/förkortningen. När en matchning sker visas
den aktuella kursen i fältet nedanför och användaren har då möjlighet att ändra alla variabler
för kursen utom läsåret och kurskoden (ska ändras till kursförkortningen då denna är den
unika identifikationssymbolen). Dessa ändringar behandlas i nästa stycke.
Användaren kan även välja att skapa en ny kurs, genom att ange önskat kursår i en drop-down
meny och sedan ange kursens kurskod. När användaren sedan klickar på ”Ny kurs!” –
knappen, så kommer den nya kursens uppgifter upp i fältet under. Läsår och kurskod är då
redan definierade, medan de övriga fälten är tomma. Som kursnamn visas ”ny kurs” tills
användaren anger vad kursen ska heta. Användaren väljer sedan ämnes område, ansvarig
lärare och kursassistent i drop-down menyer. Klickar användaren på ”Ändra/Spara” –knappen
sparas uppgifterna användaren matat in, klickar användaren på ”Radera kursen!” –knappen tas
kursen bort ur systemet.
”Generera nytt år” –knappen, lägger till ett nytt läsår till systemet, med kurser och
information från föregående år.
Användaradministration (figur 23)
Användaren (studierektorn ) kan söka på en annan användare genom att mata in antingen
dennes namn eller användarnamn i textfälten med samma namn. Ett klick på ”Sök användare”
–knappen medför att informationen kopplad till denna användare dyker upp i fältet nedanför.
Användaren (studierektorn) kan lägga till en användare i systemet genom att mata in
användarnamn och lösenord, samt välja vilken kategori av användare den nya användaren ska
tillhöra. Den nya användaren läggs in i systemet när ”Skapa användare” –knappen trycks in.
Då kommer den nya användarens uppgifter upp i fältet under. Användarnamn och lösenord är
då redan definierade, medan de övriga fälten är tomma.
26
Användaren (studierektorn) kan mata in eller ändra den aktuella användarens uppgifter genom
inmatning i textfälten (Namn/Epost, Andel Gru, Föräldraledighet, Övrig ledighet) ,val i dropdown menyerna (Användarkategori, Handledare, Startår, Slutår) och genom radioknappar
välja om användaren ska få påminnelsemejl och om användaren ska se kursernas kurskod
eller förkortning. Denna inmatning sparas när användaren klickar på ”Ändra/Spara!” –
knappen.
Användaren (studierektorn) kan radera den aktuella användaren genom att trycka på ”Radera
användare” –knappen, varmed användaren tas bort ur systemet.
27
5 Projektplan
5.1
Översikt
Projektplanen bygger på tillgängliga resurser (antal timmar), tidsramar satta av kursen samt
det lösningsförslag som presenterats ovan. Projektet har utfört första delen av sitt arbete i och
med överlämning av denna specifikation. Innan produktion kan startas återstår två moment,
för det första korrigeringar utifrån diskussion med uppdragsgivaren och referensgrupp samt
användartester. För det andra, systemdesign med tillhörande specifikation av datastruktur,
komponenter och informationsflöde.
När specifikationen preciserats och fastställts påbörjas produktion. Parallellt med detta
kommer lösningen kontinuerligt att testas och dokumenteras. Arbetet med testning och
bugghantering liksom dokumentation intensifieras mot slutet.
En grov uppskattning över projektets olika delar ses nedan. Antalet timmar som satts för
systemutvecklingen utgår ifrån tillgängliga resurser reducerat med vad övriga aktiviteter
kräver. Anledningen till detta är att det, beroende på ambitionsnivå, finns fler funktioner än
projektet har resurser att klara av inom kursens ram.
Aktivitet
Timmar
Förstudie & Specifikation 350
Dokumentation
100
Systemutveckling
450
Presentation & Projektavslut 80
Reserv & Övrigt
120
Aktiviteter
Användargränssnitt
Användartest av prototyp
Systemutveckling
Antal h
v11
Kommentar
utfört
timuppskattning i bilaga
systemdesign, kodning och testning
timuppskattning i bilaga
v12
v13
v14
v15
v16
v17
v18
25
450
Systemdesign & datastruktur
Logikdesign/informationsflöde
Sätta upp databas
Programmera gränssnitt (html)
Programmera gränssnitt (jsp/java)
Logik/Servletts
Sluttest & buggfix
Produktionsavslutning
Dokumentation
Användarhandledning
40
Systemdokumentation
30
Projektdokumentation
Övrigt
30
Presentation & Projektavslut
Summa planerat
5.2
tom v20
60
635
Projektets faser
Vecka 6 – 7
Uppstart av projekt.
Första skiss av lösning.
28
Vecka 8 – 9
Användarintervjuer och infosamlande. Förbättra lösningsförslag.
Undersöka tekniken
Vecka 10
Prototyp och funktionsbeskrivningar klara
Proof-of-concept (tekniklösning) klart
Specifikation klar fredag
Vecka 11
Datastruktur och dataflöde.
Användartest, utvärdering och förbättring av prototyp.
Fastställande av specifikation.
Vecka12-15
Kodning/produktion
v16 Slutproduktion, testning, dokumentera
v17 Sammanställa dokumentation
v18 DEADLINE, skapa presentation
v20 SLUT
(Beskrivning av arbetet vecka 6-10 finns i dokumentet Projektstatus 20 februari 2002.)
5.3
Design av användargränssnitt
En stor del av arbetet med utformning av systemets gränssnitt är utfört i och med det
lösningsförslag som presenterats. Under projektets gång kommer systemet, och därmed
användargränssnittet, att genomgå följande iterationer:
1. Lösningsförslag/skiss (idénivå, klar v7)
2. Prototyp på papper & Beskrivning av alla funktioner(klart torsdag v10)
3. Prototyp 2 (användartest & korrigeringar v11)
4. Färdig lösning (slutversion v18)
Användartest och ytterligare arbete med de förändringar som upptäcks beräknas ta 25 timmar
under vecka 11. (Uppskattningen gäller under förutsättning att testerna inte visar på allvarliga,
grundläggande felaktigheter.)
För fortsatt arbete med användargränssnitt, det vill säga kodning och testning under
produktionsfasen, se planering av Systemutveckling nedan.
29
5.4
Dokumentation
Dokumentation är, av två anledningar, en viktig del i detta projekt. För det första, så vill
kursansvarig träna projektgrupperna i att dokumentera samt att dokumentationen får
presentera gruppens prestation. För det andra, och nog så viktiga, är dokumentationen det
resultat som uppdragsgivaren har att utgå ifrån om han vill låta utveckla prototypen till en
färdig lösning att implementeras på Nada.
Dokumentationen ska färdigställas i två versioner, en anpassad för webben och en anpassad
för papper. Dokumentationsansvarig (MY) ansvarar för utformning och sammanställning,
dock kommer alla projektmedlemmar att dokumentera de delar av systemet som de varit
engagerade i.
Sammanlagd tidsåtgång för utpräglat dokumentationsarbete blir cirka 100 timmar, utöver
detta ingår dokumentering som en del i det övriga arbetet.
5.4.1
Användardokumentation
Användardokumentationen skrivs till stor del av användargruppen och
dokumentationsansvarig. Varje sida i gränssnittet beskrivs och dokumenteras. Målet är att
HTML-versionen av användarhandledningen för doktorander och lärare ska finnas
tillgängliga från respektive sida i systemet. Studierektors användarhandledning kommer också
göras tillgänglig från systemet, men inte anpassas i samma utsträckning som för doktorand
och lärare.
Dokumentationen påbörjas så tidigt som möjligt, dock senast under vecka 15 och färdigställs
under vecka 16.
Beräknad tidsåtgång är 40 timmar, inklusive att skapa HTML-version. (Se bilaga för
detaljplan)
5.4.2
Systemdokumentation
Systemdokumentationen skrivs till stor del av teknikgruppen. Arbetet med att dokumentera
systemet påbörjas under arbetet med systemdesign under vecka 11. Kodkomponenter
kommenteras löpande. Logikbeskrivning görs under vecka 11-12, men färdigställs till
dokumentationen under vecka 16 och 17.
Beräknad tidsåtgång är 30 timmar. (Se bilaga för detaljplan)
5.4.3
Projektdokumentation
Projektdokumentationen skrivs till huvudsak av projektledaren och dokumentationsansvarig.
Arbetet sker löpande med kraftsamling under vecka 16 och 17. Samtidigt kommer även en
webbsida utformas för att presentera projektet.
Beräknad tidsåtgång är 30 timmar, inklusive skapandet av webbplats för projektpresentation.
(Se bilaga för detaljplanering)
30
5.5
Systemutveckling
Systemutveckling används som samlingsnamn för ett antal olika aktiviteter såsom
 Specificering av systemdesign och datastruktur
 Sätta upp databasserver
 Programmera logikkomponenter (servletts)
 Programmera gränssnittet, dels HTML dels koppla till logiken med Java/JSP
 Bugghantering
 Acceptanstest
 Produktionsavslutning och kodrensning
Under hela systemutvecklingsfasen, vecka 11-17, kommer kontinuerlig bugghantering och
testning att ske. Dokumentation av systemlösningen sker under vecka 11-12 då
systemdesignen bestäms. Kommentering av kodkomponenter sker i samband med kodningen,
och all dokumentation sammanställs i slutet av projektet. (Se systemdokumentation ovan)
Tidplanen för systemutvecklingen begränsas av tillgängliga resurser liksom tillgänglig
deadlines för kursen. En mer detaljerad tidsplanering för all systemutveckling kommer att
göras under vecka 11-12 med systemdesignen och prioriteringen av funktioner som underlag.
Aktivitet
Systemdesign & datastruktur
Logikdesign/informationsflöde
Sätta upp databas
Programmera gränssnitt (html)
Programmera gränssnitt (jsp/java)
Logik/Servletts
Sluttest & buggfix
Produktionsavslutning
Tid
1 vecka
1vecka
1-2 veckor
2-3 veckor
3 veckor
3 veckor
1 vecka
2 dagar
Antal
3 pers
3 pers
en person
2 pers
2 pers
3 pers
5 pers
3 pers
Period
v11
v12
v12 (v13)
v12-14
v13-15
v12-15
v16
v17
Grovplanering:
5.6
Projektavslut & presentation
Under vecka 18-20 kommer två presentationer inom kursens ram att hållas, den första är en
förhandsvisning och den andra blir slutpresentationen. Eventuellt tillkommer, utöver detta,
presentation för uppdragsgivaren mfl. Vid presentationerna kommer alla projektmedlemmar
att delta. Arbetsfördelning görs senare.
Beräknad tidsåtgång är 60 timmar (se bilaga). Projektledaren ansvarar för arbetsdelning och
resultat.
31
6 Riskanalys
6.1
Identifierade riskområden
Genom diskussion har ett antal riskområden identifierats för projektet. Dessa områden har
analyserats för att finna hur hög sannolikheten är att problemet ska 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 har undersökts och diskuterats.
Riskområde
1.Tekniklplattformens stabilitet
2.Kunskap/kompetens inom gruppen
3.Datastruktur
4.Ändringshantering/kodkommentarer
5.Arbetsdelning/ansvar
6.Gruppindividernas frånvaro
7.Tolkning av användarbehov
8.Ojämn arbetsbelastning
9.Förlust av data/kod
-misstag
-systemfel
10.Hög arbetsbörda
6.2
Sannolikhet
H
L
M
M
M
H
L
H
Effekt
L
M
H
M
H
M
M
L
H
L
M
L
H
M
Genomgång av riskområden för projektet
Teknikplattformens stabilitet
Det är svårt att idag veta om den valda teknikplattformen är stabil och pålitlig. På grund av
tidigare erfarenheter av arbete med Tomcat beräknas sannolikheten för att problem ska
inträffa vara hög, men det förefaller troligt att systemgruppen kommer att erbjuda en stabil
plattform.
Kunskap/kompetens inom gruppen
Saknad kunskap kan leda till tidsförseningar, men efter en kunskapsinventeringen beräknar vi
att gruppen innehar eller kan tillägna den kompetens som är nödvändig.
Datastruktur
Sannolikheten att problem ska uppstå med datastrukturen betraktas som medel och effekten
av detta skulle vara avsevärd, vilket innebär att det är viktigt att försöka förhindra detta. I
dagens läge har projektgruppen en utförlig bild av hur systemet ska utformas och utvecklas,
vilket minskar risken för att synvinklar och tankegångar överses. Det har även betydelse att
skaffa sig en bra bild av den befintliga kompetensen.
Ändringshantering/kodkommentarer
Efter att specifikationen låses, vilket kommer att ske efter användartester i vecka 11, finns
ingen risk för externa krav på ändringar. Anledningen till detta är dels att Henrik Artman,
uppdragsgivaren, har givit projektgruppen relativt fria händer att utforma systemet, dels att
32
feedbacken från honom hittills varit positiv. Dock kommer interna ändringskrav att ställes
under produktionsfasen. För att hantera detta och det övriga samarbetet mellan
gruppmedlemmar ska det finns en lista över förslag till ändringar, en lista för olösta
kodningsproblem och en lista med önskade funktionaliteter, där både förslag och idéer
presenteras.
Arbetsdelning/ansvar
En oklar arbetsfördelning kommer att leda till avsevärda problem, framför allt för
tidsplaneringen, eftersom en osäkerhet om ansvarsområden kommer att leda till att deadlines
inte kan hållas. Det föreligger en risk att detta kommer att ske eftersom olika ansvarsområden
delvis är integrerade. För att motverka detta ska en ännu tydligare uppdelning av ansvar än
den nuvarande utarbetas under vecka 11 av projektledaren. Regelbundna statusrapporter är av
yttersta vikt då det är möjligt att en omfördelning av ansvaret behöver ske.
Gruppindividernas frånvaro
För att motverka att gruppindividers frånvaro leder till förseningar ska samtliga medlemmar
göra en bedömning om möjligheterna att hålla tidsplanen och i god tid rapportera om detta
inte är möjligt så att åtgärder kan vidtas. Det är av stor betydelse att detta sker löpande under
projektets gång.
Tolkning av användarbehov
I och med att användarintervjuer och användartester har, eller kommer att, genomföras
betraktas risken för att användarnas behov misstolkats som begränsad.
Ojämn arbetsbelastning
Då ansvarområdena har olika omfattningsgrad föreligger risken att arbetsbelastningen blir
ojämn. Detta kommer delvis kontrolleras genom en regelbunden timrapportering, men
beroende på gruppindividernas ansvar för olika faser i projektet kommer medlemmarna inte
ligga på en jämn nivå förrän i slutskedet. Det ankommer därför på individen att rapportera till
projektledaren huruvida han/hon arbetar för mycket eller för litet.
Förlust av data/kod
Förlust av data eller kod kan dels ske genom misstag, dels genom systemfel. Båda dessa
varianter avhjälps delvis genom att regelbundet spara kopior på kod och data. Per-Henrik
Stenlund ansvarar dels för detta, dels för att kontrollera hur känsligt systemet är.
Hög arbetsbörda
Under 2.6 Prioritering beskrivs de begränsade resurser som finns för detta projekt. Systemet
kommer att bli relativt komplext, varför risken finns att resurserna inte räcker till. Det är då
viktigt att prioritering och nedskalning sker.
33
7 Bilagor
7.1
Bilaga 1 - Resursfördelning (arbetstid)
Resursfördelning (arbetstid)
Max tillgängligt
Genomförda aktiviteter
Detaljplanerade aktiviteter
Max resurser att fördela
Genomförda aktiviteter
Aktivitet
Förstudie & uppstart
Prototyp & lösningsförslag
Proof-of-concept
Prel specifikation
Summa använda resurser
Detaljplanerade aktiviteter
Aktivitet
Användartest utifrån prototyp 1
Användarhandledning
Systemdokumentaton
Projektdokumentation
Presentationer & projektavslut
Planerat resursb ehov
1100
-350
-185
565
systemutveckling + reservtid
Timmar
40
190
30
90
350
Timmar
25
40
30
30
60
185
cirka
Period
v11
v15-17
v11-12,v16-17
v16-17
v18-20
34
7.2
Bilaga 2 – Detaljplanering av aktiviteter
Användartest utifrån prototyp
Aktivitet
Timmar
Förberedelser
6
Tester
10
Utvärdering/efterarb
5
Justeringar gränssnitt
4
Summa:
25
Användarhandledning
Aktivitet
Inledning/generellt
Doktorand
Lärare
Studierektor
HTML-version
Skapa mallsidor
Summa
Systemdokumentation
Aktivitet
Allmän beskrivning
Systemskiss
Driftsdokumentation
Datastruktur
Logisk beskrivning
Sammanställning
Summa
Timmar
3
7
5
10
10
5
40
Timmar
3
1
3
3
15
5
30
Projektdokumentation & Sammanställning
Aktivitet
Timmar
Skriva texterna
15
Skapa webbsidor
10
Sammanställning
5
Summa
30
Presentation & Projektavslut
Aktivitet
Förbereda förhandsvisn
Förhandsvisning
Skapa slutpresentation
Genomgång inf presentation
Slutpresentation
Utvärdering
Sammanställa utv.
Summa:
Timmar
5
7
10
7
14
11
6
60
Kommentar
2 pers
2 pers x 5 intervjuer
Kommentar
5 unika sidor á 1,5 tim
2 unika + 2 lika sidor
7 unika, 3 lika sidor
20 sidor á 30 min
för systemets html-version
Kommentar
Översiktligt
inkl använda programvaror
moduler & informationsdiagram
layout och html
Kommentar
för hela projektet
all dokomentation
Kommentar
Hela gruppen, 1 tim
Hela gruppen, 1 tim
Hela gruppen, 2 tim
Hela gruppen, 1,5 tim
35
7.3
Bilaga 3 – Förslag till datastruktur
Förändringar och tillägg kommer att ske vecka 11.
Lärare & studierektor
Fält
Status
Användarnamn
Unik ident. för
doktorand/läare/studiere.
Namn
Data
Lösenord
Data
Epost-adress
Data
Avdelning
Referens
Val av
Data (ja/nej)
kurskod/förkortning
Egna kurser
Lista med referenser
Studierektoraccess
Boolean
Handledning
Lista med referenser
Aktiv
Data (boolean)
Resurs
Doktorand
Fält
Användarnamn
Namn
Lösenord
Epost-adress
Avdelning
Befattning
Val av
kurskod/förkortning
Val om
påminnelsemejl
Arbetsberäkning
Handledare
Inlagda aktiviteter
Privat kom.. från
studierek.
Aktiv
Resurs
Lista med referenser
Status
Unik ident. för
alla användare
Data
Data
Data
Referens
Referns
Data (ja/nej)
Koppling
Avdelning
Kurs
Doktorand
Resurs
Koppling
Avdelning
Befattning
Data (ja/nej)
Lista med
referenser
Referens
Lista med
referenser
Data (Text)
Ä
Ä
Ä
Ä
Ä
Ä
Ä
Ä
Ä
*/auto
*
*
*
Auto(aktiv
default)
Ä
Ä
Ä
Ä
Ä
Ä
Ä
Ä
*/auto
*
*
Ä
Arbetsberäkning
Lärare, studierektor
Aktivitet
Ä
Ä
Ä
Data (boolean)
Lista med
referenser
Ä
Ä
Resurs
36
Ä
Auto(aktiv
default)
Kurs
Fält
Förkortning
Status
Unik
identifikator
Data
Data
Data
Koppling
Referens
Referens
Referens
Lista med
referenser
Data (Text)
Lista med
referenser
Ämne
Lärare
Doktorand
Aktivitet
Ä
Ä
Ä
Ä
Kurskommentar
Ä
Ä
Moment
Fält
ID
Namn
Förberedelsetimmar
Varningsgräns
Status
Unik identifikator
Data
Data
Data
Koppling
Aktivitet
Fält
ID
Beskrivning
Omfattning
Förberedselse
Ev Summa
Datum1
Datum2
Genomförd/Planerad
Moment
Inlagd av
Status
Unik identifikator
Data (text)
Data (numeriskt)
Data (numeriskt)
Data (numeriskt)
Data (tid/datum)
Data (tid/datum)
Data (Boolean)
Referens
Referens
Koppling
Kurs
Referens
Moment
Lärare,
doktorand
Kurs
Doktorand
Referens
Doktorand
Markerad
Data(Boolean)
Namn
Årtal
Bokstavsdel av
förkortning
Ämne
Ansvarig lärare
Kursassistent
Aktiviteter
Beskrivning/kursinfo
Kommentarer
Ä
*/auto
*
Ä
Ä
Ä
Ä
Ä
Ä
Ä
*
Auto(från
foreg. år)
*/auto
Auto(Tilldelas)
*
*
*/auto
Auto(tilldelas)
Ä
Ä
Ä
37
Ä
Ä
Ä
Ä
Auto(Beroende
på vem lagt in)
? Ska
*/Auto(Beronde
kanske bli
på varifrån
ändringsbar adderat)
Auto(Beroende
på vem lagt in)
Ä
Auto(Beroende
på vem lagt in)
Arbetsberäkning
Fält
ID
Status
Koppling
Unik identifikator
Läsår
Referens
Andel GRU
Data
Ä
Läsår
Ä
Föräldraledighet
Data
Övrig ledighet
Data
Timmar från förgående år Data beräknad,
hur hantera sena
ändringar?
Studierektorkommentar
Data (Text)
Ä
Ä
Auto(från
föreg. år)
Ä
Befattning
Fält
ID
Namn
Status
Unik identifikator
Data
Koppling
Avdelning
Fält
ID
Namn
Status
Unik identifikator
Data
Koppling
Ämne
Fält
ID
Namn
Status
Unik identifikator
Data
Koppling
Resurs
Fält
ID
*/auto
Auto
(tilldelas)
Auto(beroende
på när skapas)
Auto(sätts till
10%)
Ä
*/auto
Auto(Tilldelas)
*
Ä
Ä
*/auto
Auto(tilldelas)
*
Ä
Ä
*/auto
Auto(tilldelas)
*
Ä
Koppling
Namn
Status
Unik
identifikator
Data
Ämne
Annan kontaktperson
Referens
Referens
Skapad av
Referens
Ämne
Studierektor,
lärare, doktorand
Studierektor,
lärare, doktorand
Deadline
Erbjuden/Efterfrågad
Data
Data (Boolean)
Ä
Ska
kunna
ändras
Dito
Dito
Auto(Beroende
på id inloggad)
Dito
Dito
38
*/auto
Auto(tilldelas)
Läsår
Fält
Läsår
Timmar per dag
Status
Unik identifikator
(numeriskt tex
0102, 0203, osv)
Data (numeriskt)
Koppling
Ä
*/auto
Auto(nästa år)
Ä
Auto(föregående
års)
Auto(föregående
års)
Auto(föregående
års)
Auto(Default
false)
Auto(föregående
års)
Dagar per år.
Behövs kanske ej?
Arbetstimmar per
år
Redigerbar
Data (numeriskt)
Ä
Data (numeriskt)
Ä
Data (boolean)
Ä
Kurslistan
Lista med
referenser
Kurs
Ä
Kurskommentar
Fält
ID
DoktorandID
Status
Unik identifikator
referens
Koppling
Ä
KursID
Referens
Kurs
Text
Publik/Privat
Data (Text)
Data (boolean)
Doktorand
Ä
Ä
39
*/auto
Auto(Tilldelas)
Auto(Beroende
på id inloggad)
Auto(Beroende
på gällande
kurs)
7.4
Bilaga 4 Skisser av användargränssnitt (prototyp 1)
Figur 1.
40
Figur 2.
Figur 3.
41
Figur 4.
Figur 5.
42
Figur 6.
43
Figur 7.
44
Figur 8.
45
Figur 9.
46
Figur 10.
47
Figur 11.
48
Figur 12.
49
Figur 13.
50
Figur 14.
51
Figur 15.
Figur 16.
52
Figur 17.
53
Figur 18.
54
Figur 19.
55
Figur 20.
56
Figur 21.
57
Figur 22.
58
Figur 23.
59