Preliminär specifikation

Transkript

1 System för tidrapportering och tidplanering Preliminär specifikation 8 mars 2002 Version 1 1

2 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 2

3 1 DOKUMENTSTATUS 5 2 PROJEKTSTRUKTUR PROJEKTRAMAR PROJEKTGRUPP REFERENSGRUPP RESURSER PRIORITERING ÄNDRINGSHANTERING PROJEKTAVSLUT PROJEKTGRUPPENS ÄGANDERÄTT 8 3 PROBLEMBESKRIVNING BAKGRUND SYFTE MÅL KRAV OCH AVGRÄNSNINGAR FUNKTIONSKRAV SYSTEMKRAV DATORMILJÖ AVGRÄNSNINGAR ANVÄNDARE 12 4 LÖSNINGSFÖRSLAG ÖVERSIKT TEKNISKT LÖSNINGSFÖRSLAG GENERELLT DESIGNPARAMETRAR FÖR VAL AV TEKNISK LÖSNING VAL AV TEKNISK LÖSNING DATASTRUKTUR VAL AV TEKNISK PLATTFORM PROOF OF CONCEPT ALTERNATIVA LÖSNINGAR FÖRÄNDRADE RUTINER EXCEL FÄRDIG DATABASLÖSNING SKISS AV ANVÄNDARGRÄNSSNITTET FUNKTIONSBESKRIVNING AV DOKTORANDSIDORNA FUNKTIONSBESKRIVNING FÖR LÄRARE FUNKTIONSBESKRIVNING FÖR STUDIEREKTOR 23 5 PROJEKTPLAN ÖVERSIKT PROJEKTETS FASER DESIGN AV ANVÄNDARGRÄNSSNITT 29 3

4 5.4 DOKUMENTATION ANVÄNDARDOKUMENTATION SYSTEMDOKUMENTATION PROJEKTDOKUMENTATION SYSTEMUTVECKLING PROJEKTAVSLUT & PRESENTATION 31 6 RISKANALYS IDENTIFIERADE RISKOMRÅDEN GENOMGÅNG AV RISKOMRÅDEN FÖR PROJEKTET 32 7 BILAGOR 34 BILAGA 1 - RESURSFÖRDELNING (ARBETSTID) BILAGA 2 DETALJPLANERING AV AKTIVITETER BILAGA 3 FÖRSLAG TILL DATASTRUKTUR BILAGA 3 SKISSER AV ANVÄNDARGRÄNSSNITT (PROTOTYP 1) 39 4

5 1 Dokumentstatus 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å 5

6 2 Projektstruktur 2.1 Projektramar Detta projekt sker inom ramen för kursen 2D1954 Programutvecklingsprojekt, 4p, våren Kursen ges av Institutionen för Numerisk Analys och Datalogi (NADA) vid Kungl. Tekniska Högskolan (KTH) med Lars Kjelldahl, 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), artman@nada.kth.se. 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, petter@lector.kth.se, 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

7 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 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 Tid Resurser 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 7

8 sig till denna prioritering samt att, tillsammans med uppdragsgivaren och övriga 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

9 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

10 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 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. 10

11 11. Studierektorerna ska ha ett administrativt gränssnitt med möjlighet att redigera samtliga uppgifter. 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 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 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. 11

12 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. 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 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. 12

13 Användarna är inom gruppen relativt eniga om vilka funktioner och behörigheter man har behov av. 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

14 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 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 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

15 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 JSP-sidor Logik Java Servlets Datalagring 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 Datastruktur En skiss över datastrukturen finns bland bilagorna. Denna kommer specificeras under vecka 11, för mer information se avsnitt 5 Projektplan. 15

16 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

17 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 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 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 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

18 4.5 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

19 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

20 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

21 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 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 adress. Läraren har möjlighet att välja vilken kursomgång som ska visas från en drop-down meny. 21

22 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

23 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 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 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

24 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

25 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

26 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

27 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

28 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 Kommentar Förstudie & Specifikation 350 utfört Dokumentation 100 timuppskattning i bilaga Systemutveckling 450 systemdesign, kodning och testning Presentation & Projektavslut80 timuppskattning i bilaga Reserv & Övrigt 120 Aktiviteter Antal h v11 Användargränssnitt Användartest av prototyp 25 Systemutveckling 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 30 Övrigt Presentation & Projektavslut 60 v12 v13 v14 v15 v16 v17 v18 tom v20 Summa planerat

29 5.2 Projektets faser Vecka 6 7 Uppstart av projekt. Första skiss av lösning. 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

30 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 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) 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) 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

31 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 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 med systemdesignen och prioriteringen av funktioner som underlag. Aktivitet Tid Antal Period Systemdesign & datastruktur 1 vecka 3 pers v11 Logikdesign/informationsflöde 1vecka 3 pers v12 Sätta upp databas 1-2 veckor en person v12 (v13) Programmera gränssnitt (html) 2-3 veckor 2 pers v12-14 Programmera gränssnitt (jsp/java) 3 veckor 2 pers v13-15 Logik/Servletts 3 veckor 3 pers v12-15 Sluttest & buggfix 1 vecka 5 pers v16 Produktionsavslutning 2 dagar 3 pers v17 Grovplanering: 5.6 Projektavslut & presentation Under vecka 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

32 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 Sannolikhet Effekt 1.Tekniklplattformens stabilitet H L 2.Kunskap/kompetens inom gruppen L M 3.Datastruktur M H 4.Ändringshantering/kodkommentarer M M 5.Arbetsdelning/ansvar M H 6.Gruppindividernas frånvaro H M 7.Tolkning av användarbehov L M 8.Ojämn arbetsbelastning H L 9.Förlust av data/kod -misstag H L -systemfel L H 10.Hög arbetsbörda M M 6.2 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

33 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

34 7 Bilagor 7.1 Bilaga 1 - Resursfördelning (arbetstid) Resursfördelning (arbetstid) Max tillgängligt 1100 Genomförda aktiviteter -350 Detaljplanerade aktiviteter -185 Max resurser att fördela 565 systemutveckling + reservtid Genomförda aktiviteter Aktivitet Timmar Förstudie & uppstart 40 Prototyp & lösningsförslag 190 Proof-of-concept 30 Prel specifikation 90 Summa använda resurser 350 cirka Detaljplanerade aktiviteter Aktivitet Timmar Period Användartest utifrån prototyp 1 25 v11 Användarhandledning 40 v15-17 Systemdokumentaton 30 v11-12,v16-17 Projektdokumentation 30 v16-17 Presentationer & projektavslut 60 v18-20 Planerat resursbehov

35 7.2 Bilaga 2 Detaljplanering av aktiviteter Användartest utifrån prototyp Aktivitet Timmar Kommentar Förberedelser 6 2 pers Tester 10 2 pers x 5 intervjuer Utvärdering/efterarb 5 Justeringar gränssnitt 4 Summa: 25 Användarhandledning Aktivitet Timmar Kommentar Inledning/generellt 3 Doktorand 7 5 unika sidor á 1,5 tim Lärare 5 2 unika + 2 lika sidor Studierektor 10 7 unika, 3 lika sidor HTML-version sidor á 30 min Skapa mallsidor 5 för systemets html-version Summa 40 Systemdokumentation Aktivitet Timmar Kommentar Allmän beskrivning 3 Systemskiss 1 Översiktligt Driftsdokumentation 3 inkl använda programvaror Datastruktur 3 Logisk beskrivning 15 moduler & informationsdiagram Sammanställning 5 layout och html Summa 30 Projektdokumentation & Sammanställning Aktivitet Timmar Kommentar Skriva texterna 15 Skapa webbsidor 10 för hela projektet Sammanställning 5 all dokomentation Summa 30 Presentation & Projektavslut Aktivitet Timmar Kommentar Förbereda förhandsvisn 5 Förhandsvisning 7 Hela gruppen, 1 tim Skapa slutpresentation 10 Genomgång inf presentation 7 Hela gruppen, 1 tim Slutpresentation 14 Hela gruppen, 2 tim Utvärdering 11 Hela gruppen, 1,5 tim Sammanställa utv. 6 Summa: 60 35

36 7.3 Bilaga 3 Förslag till datastruktur Förändringar och tillägg kommer att ske vecka 11. Lärare Fält Status Koppling Användarnamn Unik identifikator Namn Data Lösenord Data Epost-adress Data Avdelning Referens Avdelning Val av kurskod/förkortning Data (ja/nej) Egna kurser Lista med referenser Kurs Doktorand Fält Status Koppling Användarnamn Unik identifikator Namn Data Lösenord Data Epost-adress Data Avdelning Referens Avdelning Befattning Referns Befattning Val av kurskod/förkortning Data (ja/nej) Val om påminnelsemejl Data (ja/nej) Arbetsberäkning Lista med referenser Arbetsberäkning Handledare Referens Lärare, studierektor Inlagda aktiviteter Lista med referenser Aktivitet Studierektor Fält Status Koppling Användarnamn Unik identifikator Namn Data Lösenord Data Epost-adress Data Avdelning Referens Avdelning Val av kurskod/förkortning Data (ja/nej) Egna kurser Lista med referenser Kurs Möjligen kommer lärare och studierektor vara samma, då behövs ett fält med uppgifter om befattning till för att ange vilka sidor som ska vara tillgängliga. 36

37 Kurs Fält Status Koppling Förkortning Unik identifikator Namn Data Årtal Data Bokstavsdel av förkortning Data Ämne Referens Ämne Ansvarig lärare Referens Lärare Kursassistent Referens Doktorand Aktiviteter Lista med referenser Aktivitet Moment Fält Status Koppling ID Unik identifikator Namn Data Förberedelsetimmar Data Varningsgräns Data Aktivitet Fält Status Koppling ID Unik identifikator Namn Data Moment Referens Moment Inlagd av Referens Lärare, doktorand Kurs Referens Kurs Doktorand Referens Doktorand Arbetsberäkning Fält Status Koppling ID Unik identifikator Årtal Data Andel GRU Data Föräldraledighet Data Övrig ledighet Data Timmar från förgående år Referens Befattning Fält Status Koppling ID Unik identifikator Namn Data 37

38 Avdelning Fält Status Koppling ID Unik identifikator Namn Data Ämne Fält Status Koppling ID Unik identifikator Namn Data Resurs Fält Status Koppling ID Unik identifikator Namn Data Ämne Referens Ämne Annan kontaktperson Referens Studierektor, lärare, doktorand Skapad av Referens Studierektor, lärare, doktorand 38

39 7.4 Bilaga 3 Skisser av användargränssnitt (prototyp 1) Figur 1. 39