Projektplan; Mötesbokaren Informatik B, Systemutvecklingsprojekt V.1.2 [120215] Projektmedlemmar: Per Gerdin & Petter Källström
1.0 Unik identifiering & versionshantering av projektplanen... 4 2.0 Översikt... 5 2.1 Projektöversikt... 5 2.2 Målbild... 5 2.3 Nytta för verksamheten... 5 2.4 Avgränsningar... 5 3.0 Organisation... 5 3.1 Projektmedlemmar... 5 3.2 Kontaktperson... 6 3.3 Uppdragsgivare/verksamhetsbeskrivning... 6 3.4 Arbetsmiljö... 6 3.5 Rollbeskrivning och ansvarsområden... 6 4.0 Problem & målbeskrivning... 6 4.1 Problemformulering... 6 4.2 Mål och syfte... 7 4.3 Slutmål och krav... 7 5.0 Leverabler... 7 5.1 Tidslinje... 8 6.0 Genomförande & tidplan... 9 6.1 Product Backlog... 9 6.2 Preliminära Sprint Backlogs... 9 6.3 UI- prototyp med grundläggande händelseflöde i webbapplikation... 9 6.3.1 Översikt - grundläggande användarflöde... 9 7.0 Resursanalys... 10 7.1 Preliminär tidsuppskattning... 10 7.2 Utrustning... 10 7.3 Verktyg och programvaror... 10 7.4 Litteratur... 10 7.5 Tidigare förvärvad utbildning inom projektgruppen... 11 8.0 Kvalitetskriterier... 11 8.1 Översikt... 12 8.1.1 Funktionalitet... 12 8.1.2 Användbarhet... 12 8.1.3 Tillförlitlighet... 12 8.1.4 Underhållbarhet... 12 8.1.5 Effektivitet... 13 8.2 Övriga åtgärder för säkrad kvalité... 13 8.3 Testning... 13 9.0 Riskanalys... 14 10.0 Kunskapsfördjupning... 15 10.1 Tilltänkta områden för kunskapsfördjupning... 15 2
11.0 Källförteckning... 16 11.1 Webblänkar... 16 12.0 Bilagor... 16 12.1 Bilaga 01 Product Backlog... 17 12.2 Bilaga 02 ER- Diagram... 19 12.2.1 Förtydligande av ER- diagram/databas- schema... 19 12.3 Bilaga 03 Databas- schema... 21 12.4 Bilaga 04 Grundläggande användningsflöde/ui- prototyp... 22 3
1.0 Unik identifiering & versionshantering av projektplanen Version Datum Ändring i projektplansdokument 0.1 2012-01- 18 Skapande av dokument. 0.2 2012-01- 23 Inledande målsättning, projektbeskrivning 0.3 2012-01- 25 Testning & kvalitetssäkring 0.4 2012-01- 26 Resursanalys, kunskapsfördjupning 0.5 2012-01- 30 Leverabler, riskanalys, Product Backlog v.0.2 0.6 2012-02- 06 ER- diagram och databas- schema 1.0 2012-02- 07 UI- prototyp med grundläggande användarflöde 1.1 2012-02- 12 Åtgärdsplan och reviderad riskanalys 1.2 2012-02- 15 Utökad tidsplan, analys/design- material i bilaga, justeringar 4
2.0 Översikt 2.1 Projektöversikt Projektet innefattar utveckling av en webbaserad tjänst utvecklad i ASP.NET och HTML/CSS med eventuellt JavaScript för bokning av sammanträden om anställningar och befordran inom KTH. Idag används tjänsten Doodle.com, men det finns en önskan och ett behov av en egen optimerad tjänst med liknande funktionalitet för särskilda möten. 2.2 Målbild Högsta prioritet är en fungerande webbtjänst för hantering av mötesförfrågningar enligt projektöversikt ovan (2.1). Ett högprioriterat mål är att tjänsten skall, enligt uppdragsgivarens önskemål, ha bättre och mer anpassad funktionalitet i mötesbokningens senare skeden än vad som upplevts med Doodle.com. Mötesbokaren bör också vara enkel att administrera (lägga till/ta bort användare etc.) så mycket som möjligt via ett webbgränssnitt för personer utan kunskaper om webbutveckling. Tjänsten skall följa Kungliga tekniska högskolans övergripande form och design och ha den funktionalitet som önskas. Om målen uppnås till fullo kan KTH ha för intresse att använda Mötesbokaren även för andra institutioner inom skolan förutom den nu aktuella gällande projektet. 2.3 Nytta för verksamheten Om de mål som sätts upp uppnås kommer Mötesbokaren innebära att tid sparas i och med bland annat fördefinierade mallar anpassade för projektbeställaren. Flera steg onödiga steg kommer att undanröjas i jämförelse med Doodle.com och vissa andra önskade kommer att läggas till. Slutprocessen i mötesbokningarna som upplevts som ofullständiga tidigare kommer att fungera bättre. Större enhetlighet kommer att uppnås med en egen tjänst istället för en kommersiell tjänst, vilket varit ett av incitamenten till projektidén från KTH:s sida. 2.4 Avgränsningar Webbtjänsten kommer inledningsvis enbart att omfatta den specifika institution på KTH som beställt projektet, men projektet bör utvecklas med tanke på att eventuell användning för andra inom KTH ska vara möjligt att implementera i efterhand utan att stöta på för stora hinder. Mötesbokaren skall ha obligatorisk inloggning, men det kommer vara avgränsat på så vis att det inte kommer vara kopplat till skolans egna system och lagrade användaruppgifter. 3.0 Organisation Produktägare: Kungliga Tekniska Högskolan, Universitetsförvaltningen, gruppen för lärartillsättningar. 3.1 Projektmedlemmar Per Gerdin 070-4942345 pegge88@yahoo.se 5
Petter Källström 076-7856122 pttr.kallstrom@gmail.com 3.2 Kontaktperson Johan Gerdin Kungl. Tekniska högskolan Universitetsförvaltningen Personalavdelningen/Lärartillsättningar jgerdin@kth.se 3.3 Uppdragsgivare/verksamhetsbeskrivning Den centrala tjänsteförslagsnämnden har till uppgift att handlägga ärenden som gäller befordran av lektor till professor samt befordran av biträdande lektor till lektor. I denna nämnd ingår även lärartillsättningar inom Skolan för teknikvetenskaplig kommunikation och lärande. Studenterna har rätt att vara representerade med tre ledamöter i respektive tjänsteförslagsnämnd. 1 3.4 Arbetsmiljö Vi har valt att arbeta till stor del med SCRUM som utvecklingsmetod, dels för att utvecklingsgruppen har viss erfarenhet av SCRUM samt att vi är en liten grupp och SCRUM som agil metodik kan användas med fördel under utvecklingen. Angående arbetsplats, så kommer vi att försöka jobba tillsammans fyra gånger i veckan på universitetsområdet. Utöver det så kommer det vara en del arbete på distans, med dagliga Skype- möten (daily scrum) när gruppen inte ses på plats 2. 3.5 Rollbeskrivning och ansvarsområden Product Owner - Kungliga Tekniska Högskolan, kontaktperson Johan Gerdin. Scrum Master - Ett gemensamt ansvarsområde som kommer att roteras inom gruppen. Team members - Per Gerdin, Petter Källström 4.0 Problem & målbeskrivning 4.1 Problemformulering Gruppen för lärartillsättningar vid KTH är i behov av en webbaserad bokningstjänst för sammanträden. De anser att den nuvarande lösningen innehåller för många onödiga steg i användarflödet och har definierat vad de istället önskar och hur funktionalitet bör implementeras (se 4.2 Mål och syfte). Mötena görs i dag med webbtjänsten Doodle.com. Tjänsten är gratis och fungerar förhållandevis väl. Den är dock för grundläggande och innehar inte all önskad funktionalitet. 1 http://www.kth.se/om/organisation/kths- fakultetsrad/centrala- tjansteforslagsnamnden- ctfn- 1.3736 2 http://en.wikipedia.org/wiki/scrum_(development) 6
4.2 Mål och syfte Syftet med Mötesbokaren är att den ska ge ett professionellt intryck. Mötesbokaren ska inneha standardiserade meddelanden, i jämförelse med en gratistjänst där varje handläggare formulerar sina meddelanden på sitt eget sätt. Det nya projektet ska underlätta arbetet för mötesbokningar genom att ta bort onödiga steg samt lägga till funktionalitet anpassad för processen och därmed effektivisera arbetsgången för personalen. I förhållande till Doodle och dagens hantering har föreliggande förslag på en mötesbokare följande fördelar: Handläggaren kommer att använda sig av förinställda textmallar på svenska och engelska. Det är tidsbesparande och leder till enhetlighet. Det kommer också finnas förinställda e- postlistor för att handläggaren effektivt ska kunna få ut mötesförfrågningarna. Handläggaren använder i dag Doodle, Outlook och fysiska anteckningar för att producera förslag på nämndsammansättning. Mötesbokaren innehåller samtliga steg som handläggaren gör från det att en mötesförfrågan ska skickas ut till det att allt är klart för utskick av kallelsen. På så sätt slipper handläggaren använda flera olika verktyg, i stället görs allt i ett och samma verktyg. Mötesbokaren håller koll på följande moment: utskick av förfrågan om mötestider, sammanställning av svaren och möjlighet att lämna förslag på nämnd till ordförande, lokalbokning samt möjlighet att skicka påminnelse. 4.3 Slutmål och krav Efter möte med Johan Gerdin, vår kontaktperson på KTH, har ett större antal mål/krav samlats ihop (se 6.1) med hjälp av produktägarens beställningsdokument samt insamling under mötet. Slutmålet är en intern webbtjänst för hantering av mötesförfrågningar inom verksamheten som ska vara integrerad med Kungliga Tekniska Högskolans webbplats och ha specifik funktionalitet för mötesplanering anpassat för gruppen för lärartillsättningar. Slutmålet innefattar att högprioriterade krav (se bilaga 01 för krav och prioritet samlat) som samlats in fungerar i överlämnad produkt. 5.0 Leverabler Leverabel Leverans Mottagare Tidigt utkast av projektplan 120131 Opponentgrupp, Handledare ÖU Kravspecifikation (första version, del av projektplan) 120202 Johan Gerdin, KTH ER- diagram (databasmodell, del av projektplan) 120210 Handledare 7
Databas- schema (del av projektplan) 120210 Handledare Fullständig projektplan 120210 Handledare Fullständig projektplan 120213 Johan Gerdin, KTH UI- protoyp av Mötesbokaren 120309 Johan Gerdin, KTH Tidig alfatestversion av Mötesbokaren 120326 Johan Gerdin, KTH Delleverans av Mötesbokaren 120411 Handledare, ÖU Betatestversion av Mötesbokaren 120411 Johan Gerdin, KTH Programkod, systemdokumentation samt färdig körbar version av Mötesbokaren 120522 Johan Gerdin, KTH Programkod, systemdokumentation samt färdig körbar version av Mötesbokaren 120522 Handledare, ÖU 5.1 Tidslinje 8
6.0 Genomförande & tidplan 6.1 Product Backlog Projektets Product Backlog innefattar samtliga krav och den funktionalitet som ska implementeras. Kraven är prioriterade på en sifferskala där 1 är av högsta prioritet. Dokumentet kan komma att ändras och fyllas på med krav under utvecklingens gång. Product Backlogen finns som Bilaga 01. 6.2 Preliminära Sprint Backlogs I vår sprint backlog kommer vi att plocka ut de olika delar som vi kommer behandla under de olika sprintarna från vår product backlog. Än så länge finns inte en grovskiss på alla sprintar, men vi kommer veckovis sammanställa en sprint backlog utififrån product backloggen att arbeta efter. 6.3 UI- prototyp med grundläggande händelseflöde i webbapplikation UI- prototyp är en preliminär grovskiss på hur Mötesbokaren ska fungera från projektskapande till lokalbokning för bestämt möte. Den innehåller inga steg vid felaktig inmatning utan visar hur det ska se ut om alla steg utförs korrekt. Den kan komma att ändras i viss mån, men är i stort sett vad vår kontaktperson på KTH önskat i stora drag. Se bilaga 04 för händelseförloppet i bilder samt mer specificerad process- information. 6.3.1 Översikt - grundläggande användarflöde DEL 1. Skapande av projekt (förfrågan om mötesdagar) Steg 1 Inloggning Steg 2 Välj Skapa projekt eller Öppna projekt Steg 3 Skapa projekt Steg 4 Förslag på datum för sammanträde Steg 5 Mötesförfrågan, förslag på text Steg 6 Välj mottagare Steg 7 Förhandsgranskning av utskick Steg 8 Projekt skapas/mötesförslag skickas ut DEL 2. Mottagarsvar och sammanställning av svar Steg 8 Mottagaren väljer tider via en länk i e- postutskicket Steg 9 Handläggare kan se svar via öppnat befintligt projekt Steg 10 Handläggare väljer preliminära deltagare för möte DEL 3. Förslag på nämnd, kallelse till möte och lokalbokning Steg 11 Ordförande väljer ledamöter, skickar till handläggare Steg 12 Handläggare skickar ut preliminär kallelse Steg 13 Handläggare skickat ut e- post för lokalbokning 9
7.0 Resursanalys 7.1 Preliminär tidsuppskattning Vi räknar med den tid som finns från och med vecka 7, måndagen den 13 februari och till och med vecka 21, måndagen den 21 maj. Vidare uppskattar vi att ett medel på cirka 35 timmar i veckan per person i gruppen finns till förfogande efter att vi räknat bort handledning, slack- tid, eventuellt sjukdom och särskilda helgdagar (påsk). 70 h/vecka vilket innebär att 910 timmar finns att disponera. De första tre veckorna innefattar tid för att planera ytterligare och förvärva ny kunskap för att kunna slutföra projektet. I projektets product backlog (se bilaga 01) finns en grov tidsuppskattning för olika delar som behöver betas av under utvecklingen. Notera att tiderna ibland är stora i och med att vi anser att vissa delar kräver att samtliga projektmedlemmar bör arbeta på samma uppgift. Vidare så kan tidsuppskattning skilja sig kraftigt åt i efterhand samt att flera delmål kan komma att läggas till i loggen under tiden, särskilt i ett tidigt skede (kunskapsfördjupning, inledande programmering). 7.2 Utrustning Tillgång till personliga datorer under utvecklingen är nödvändigt och samtliga projektinvolverade har tillgång till utrustningen. Internetanslutning för kommunikation och tillgång till onlinebaserad schemaplanering via telefon/3g- nätet. 7.3 Verktyg och programvaror Microsoft Visual Studio 2010 Microsoft SQL Server 2008 R2 Ordbehandlare (Word, Google Docs) Kalkylbehandlare (Excel, Google Docs) Bildredigerare (Gimp, Photoshop CS) HTML/CSS- redigerare (Coda, Notepad++) Versionshantering (Google Code, TortoiseVSN) Kommunikation (Skype, e- post, telefon) Övrig fildelning (Dropbox) Komplimenterande kodgranskning (Sonar) UML- modellering (OmniGraffle, Umbrello) Webbläsare för testning (Google Chrome, Mozilla FireFox, Internet Explorer, Safari, mobila webbläsare Android/iOS). 7.4 Litteratur Schwaber Ken & Beedle Mike (2002), Agile Software Development with Scrum, by Prentice Hall. Lunell Hans (2003), Fyra rundor med RUP, av Studentlitteratur AB Lund. Eriksson Ulf (2004 / 2008), Test och kvalitetssäkring av IT- system, av Studentlitteratur AB Lund. Syverson Bryan & Murach Joel (2008), SQL Server 2008 for developers, by Mike Murach & Associates Inc. Duckett Jon (2008), Web Programming with HTML, XHTML, and CSS, Wiley Publishing Inc. Liberty & Hurwitz (2008), Programming ASP.NET 3.5, O reily 10
Dhillon (2007), Principles of information systems security, Wiley Liberty & Xie (2008), Programmering c# 3.0, O Reily W3Schools (http://www.w3schools.com/) 7.5 Tidigare förvärvad utbildning inom projektgruppen Objektorienterad programmering med C# Databashantering med SQL Server Klientprogrammering för webbsystem, HTML/CSS/JavaScript Interaktionsdesign Agil utvecklingsmetodik och praktik (SCRUM/XP) Webbsystem med.net Objektorienterad analys & design med RUP Informations- och IT- säkerhet Test & kvalitetssäkring 8.0 Kvalitetskriterier Kavalitetskriterie Mätmetod Kommentar Funktionalitet Acceptanstester För att säkehetsställa att alla mål är uppnådda från kundens kravspecifikation, så kommer vi att applicera acceptanstester med handhavandefelshantering vid prototyp- och sluttester. Användbarhet Användningstester Produktägaren har gett oss riktlinjer att följa en viss design av gränssnittet. Där enkelhet är ett nyckelord. Men under uppbyggnaden, så kommer han få kontinuerliga utskick där han kan gå igenom förändringar och lämna sin feedback angående designen. För att han ska få ett system som han och hans kollegor ska trivas med. Tillförlitlighet Simulering & vid acceptanstesternas handhavandefelshantering Under utvecklingen så kommer systemet testas kontinuerligt, för att fånga upp buggar och fel i koden. Som kan göra så att systemet kraschar etc. Olika redskap som vi kommer att använda oss av finns under rubriken 8.4. 11
Underhållbarhet Kodgranskning Att ha en kodstandard & bra och tydlig kodkommentering. Så att det blir lättare att sätta in sig i koden, för systemförvaltaren. Effektivitet Scenario Man kollar responstiden vid olika handhavanden i systemet. Som tex att lägga till projekt. 8.1 Översikt Under projektarbetet syftar vi på att validera och verifiera utvecklingen för att säkra de kvalitetskriterier som är relevanta för Mötesbokaren. ISO 9126- standard blir den huvudsakliga utgångsvinkeln. Den här delen av projektplanen innehåller de kriterier och applicerbara tester för att under senare utvecklingsfaser avgöra om projektet når upp till de önskvärda kriterierna/kraven. 8.1.1 Funktionalitet Mål för funktionalitet är ändamålsenlighet där högprioriterade krav ska implementeras. Noggrannhet för att implementerade funktioner ska fungera enligt produktägarens kravspecifikation. Tester är planerade under iterationsfaserna samt avstämning/testning med produktägaren vid iterationsstadier där ny relevant funktionalitet implementerats. Säkerhet för att undvika obehörig tillgång till funktionalitet och minimera risk för sabotage. Säkerhetskrav avser valideringen vid extern input, säker lösenordshantering, åtgärder för motverka SQL- injektion. Eventuell samverkan med andra applikationer eftersträvas. Implementation av en WCF Service för att möjliggöra detta. 8.1.2 Användbarhet Syftar på begriplighet, körbarhet och lärbarhet i form av webbtjänsten ska vara enkel att hantera och lära sig. Arbetsflödet ska vara logiskt. Målgruppen sträcker sig i ett åldersspann från cirka 25-70 år med varierande datorvana. Enkelt och intuitivt är ett krav. Målen är att följa de önskemål som satts upp tillsammans med produktägaren. Användbarheten ska testas när en större justering gjorts. Tjänstens formgivning ska följa Kungliga tekniska högskolans design riktlinjer och en tidig version av tjänstens gränssnitt kommer att stämmas av med produktägaren. Vidare söker vi att följa grundläggande riktlinjer för god praktik inom interaktionsdesign och vedertagna och rådande designregler. 8.1.3 Tillförlitlighet För att leverera kvalitativ tillförlitlighet ska feltolerans hanteras på så vis att tjänsten ska ha god validering samt hantera databas- transaktioner på ett säkert sätt 3. 8.1.4 Underhållbarhet För att säkra kvalitet gällande underhållbarhet är störst fokus i det här specifika projektet föränderlighet. I den mån det är möjligt ska relevant funktionalitet brytas ut egna klasser/klassbibliotek. En tre- lagersarkitektur med datalager, logiklager och databaslager ska 3 http://en.wikipedia.org/wiki/acid 12
implementeras för att underlätta vidare utveckling i ett senare skede. Implementation av WCF Service- funktionalitet för att kunna åskådliggöra webbapplikationen utåt. Lämplig kommentering, standardiserad notation ska användas. 8.1.5 Effektivitet Effektivitet för att kvalitetssäkra tjänsten gällande resursutnyttjande så ska de projekt handläggaren skapar lagras i en databas. Slutförda projekt ska raderas i efterhand för att spara resurser och inte spara irrelevant data. Lösningen på problemet är inte ännu klargjort dock. För att effektivisera svarstider finns ett krav med lägre prioritet att lagra sakkunniga och använda Ajax för snabb åtkomst till dessa vid mötesbokningar. 8.2 Övriga åtgärder för säkrad kvalité Vi syftar att föra utvecklingsprojektet framåt och säkra kvalité genom att upprätthålla en kontinuerlig dialog med produktägaren/kontaktpersonen för projektet. Kravspecifikationen dokumenteras i användarfall, för processöverskådlighet vid programmatisk implementation, och user stories med olika prioritet, för att kunna arbeta iterativt enligt SCRUM i sprintar veckovis. Vidare finns en överenskommelse av ett gemensamt språkbruk för att sätta namn på funktioner etc och kontinuerlig dokumentation/kommentering vid kodblock dels för att underlätta utvecklingen och öka förståelsen för eventuella utomstående. Relevanta visuella modeller/diagram ska upprättas innan konstruktionsfasen inleds. Verktyget Sonar kommer att testas för att granska kod. 8.3 Testning Inledningsvis ska projektets insamlade krav granskas och diskuteras inom utvecklingsgruppen. Vid iterationsintervaller ska ett regressionstest utföras för att fånga upp eventuella oönskade bieffekter#. Informella och formella statiska tester ska göras av skriven kod kontinuerligt tillsammans i utvecklingsgruppen och stämmas av med projektplanens krav och användarfall. Finns det behov att utvärdera specifika krav på nytt är det möjligt att föra en dialog med produktägaren via e- post/skype/telefon. Dynamiska tester för ska göras för att verifiera kodlogik när funktionalitet för validering skrivits för relevanta kontroller. Tillståndstester ska göras när funktionalitet för inloggning implementeras, likaså när administratörsfunktionalitet implementerats. För att säkerställa användbarhet ska webbtjänsten testas (icke- funktionell testning) av produktägaren (och eventuella kollegor/framtida användare) när en tidig version färdigställs och likaså med jämna mellanrum. Upplevelser och åsikter samlas in och eventuella justeringar kan ske i kravspecifikationen. Vid felmeddelande eller andra oönskade fel ska det noteras/loggas ifall det inte blir löst efter att det upptäckts. 13
För att verifiera och testa CSS/(X)HTML/JavaScript används följande: http://jigsaw.w3.org/css- validator http://validator.w3.org http://getfirebug.com 9.0 Riskanalys nr Område/risk Sannolikhet (1-5) Påverkan (1-5) Upplevd risk Åtgärd 01 Kunskapsbrist 4 3 12 Gruppen tittar tidigt på grundläggande design och analys för att se lösningar för viktiga krav som sedan blir en stor del av kunskapsfördjupningen. 02 Bristfällig/ofullständig planering 03 Felaktig tidsuppskattning 3 3 9 Tidiga versioner av analys- dokument skapas för att kunna göra en mer korrekt planering. 3 3 9 Svårt att motverka, men tidsuppskattning görs i överkant för säkerhetsskull även vid mindre implementationer. Product backloggen uppdateras frekvent. 04 Sjukdom 3 2 6 Vid sjukdom kommer Skype- möten användas och arbete hemifrån görs i den mån det är möjligt. 05 Projektmedlem lämnar gruppen 3 4 12 Projektet planeras i den mån att det ska vara möjligt för även två personer att kunna klara av prioriterad funktionalitet. 06 Tekniska problem 2 2 4 Samtliga projektmedlemmar har tillgång till sekundär utrustning ifall det är nödvändigt. 07 Mjukvaruproblem 2 3 6 Inledande installation och tester görs i planeringsfas för att undvika tidsförlust i senare iterationer. 14
08 Felaktiga krav 2 4 8 Återkommande Skype- möten med kontaktperson kommer ske där viktiga krav gås igenom igen för att säkerställa riktigheten. Åtgärdsplan grundat på upplevd risk(sannolikhet * Påverkan): Låg (1-5) - Ska ses över vid mån av tid, alt ignorera risken. Medel (6-10) - Ska ses över under projektet gång. Hög (11-15) - Ska ses över så tidigt som möjligt. Extremt hög (16-25) - Ska ses över så tidigt som möjligt, samt att ha en reserv plan. 10.0 Kunskapsfördjupning För att slutföra projektet finns det ett behov av att fördjupad och specifikt inriktad kunskap inom vissa områden. Det kan det också vara en fördel att uppdatera och/eller damma av viss kunskap inom gruppen. Främst handlar det om att åter gå igenom SCRUM som metodik. Gruppmedlemmarna har i vissa avseenden olika kunskap sen tidigare och vi ska försöka att lära varandra i den mån det är möjligt. Utvecklingsgruppen har tidigare erfarenhet av ASP.NET (websystem med.net- kurs), men inte gällande alla de aspekter som behöver behandlas i att skapa Mötesbokaren. Att hantera automatiskt skapande av dynamiska webbdokument beroende på viss data är något vi inte tidigare praktiserat. En mer ingående förståelse för att skriva säker inloggning känns också som relevant kunskap att ta in. En del element inom projektet (exempelvis inloggning) är också menat att ha skrivas från grunden och inte användas via färdiga moduler, vilket kräver en del fördjupning. CSS/HTML- formatering i e- postmeddelanden med hantering av hyperlänkar är också något gruppen inte ha tidigare erfarenhet. En av de sekundära kraven är också att koppla tider mot kalender- applikationer vilket också är ny kunskap som behöver läsas in. Mer avancerad hantering av webbformulär är också ett område som behöver täckas då webbtjänsten t.ex. ska ha funktionalitet för att redigera e- post på sidan med automatiskt html- formatering. 10.1 Tilltänkta områden för kunskapsfördjupning SCRUM Fördjupning i ASP.NET Test & Kvalitetssäkring Datasäkerhet/kryptering Dynamiskt skapande av unika aspx- sidor i ASP.NET Tidsbaserad automatisering/triggers HTML/CSS i epostutskick Gcal/iCal- support (eventuellt) Scalability 15
11.0 Källförteckning 11.1 Webblänkar http://www.kth.se/om/organisation/kths- fakultetsrad/centrala- tjansteforslagsnamnden- ctfn- 1.3736 http://en.wikipedia.org/wiki/scrum_(development) http://en.wikipedia.org/wiki/regression_testing http://www.sonarsource.org http://en.wikipedia.org/wiki/acid 12.0 Bilagor ID Dokument 01 Product Backlog 02 ER- diagram 03 Databas- schema 04 UI- prototyp/användarflöde 16
12.1 Bilaga 01 Product Backlog 17
18
12.2 Bilaga 02 ER- Diagram 12.2.1 Förtydligande av ER- diagram/databas- schema Attributet type i tabellen Project innehåller de ärendetyper som en handläggare/projektskapare kan välja. Ärendetyperna har olika rubriker samt olika mallar. Varje variant av ärende, rubrik och mall för e- postutskicket har ett unikt ID. Mallarna finns sparade i XML- filer och hämtas därifrån. Type- attributet har för uppgift att hålla reda på vilken typ av ärende och rubrik som är aktuell för specifikt projekt. Type- attributet i participant - tabellen håller reda på vilken typ av deltagare det handlar om. Dessa kan vara ordförande, sakkunniga och nämndemän i dagsläget. Vi har valt att använda ett attribut för att hålla reda på detta istället för att använda ärvda tabeller då de i övrigt inte i skiljer sig i åt i data som behöver lagras. UniqueStr- attributet är ett längre slumpmässigt genererad sträng som skapas för varje inbjuden mötesdeltagare innan inbjudan skickas. Strängen är unik för varje deltagare. Syftet är att verifiera deltagaren via data i maillänken för att lösa eventuella problem med att deltagaren skulle kunna skriva sitt namn och e- post fel vid svarande av vilka tider som passar denne. Strängen raderas efter att deltagaren givit sitt svar på vilka tider som passar. Är deltagaren inbjuden till två möten kan strängen användas för båda möten. Observera att den här funktionaliteten är av sekundär prioritet, då utvecklingsgruppen inte ännu helt löst eventuella problem som kan uppstå. En annan lösning ifall tiden inte räcker till är att hämta en deltagarlista via databasen för aktuellt möte där deltagare får välja sitt namn i rullgardinsmeny på sidan dit maillänken leder dom till (se GUI- prototyp, bilaga 04 för mer tydlighet). 19
Attributet Accepted vid Chooses- relationen (som blir en egen tabell av primära nycklar från AppointmentTime och Participant) är där deltagarens svar på vilka tider som passar lagras. Comment - attributet i samma tabell/relation är den eventuella kommentar som den inbjudne deltagaren kan lämna. ProjectOwner är de handläggare som skapar projekt/möten och är de enda som ska behöva login- uppgifter. En (eller flera) av dessa ska också ha administrativa rättigheter. Attributet FinalInvite håller reda på de deltagarna som handläggare och ordförande väljer att bjuda in till den tid som i slutänden väljs som mötestid. Detta för att produktägaren bett om att kunna spara den listan med deltagare innan det skickas ut en inbjudan till den bokade tiden. 20
12.3 Bilaga 03 Databas- schema 21
12.4 Bilaga 04 Grundläggande användningsflöde/ui- prototyp 22
23
24
25
26
27
28
29
30
31
32
33
34
35
36