Project Definition
(This document is in Swedish)
|
Detta dokument är en projektdefinition (Eklund, 2010) för studentprojekt eller examensarbete vid KTH ICT. En projektdefinition är inte en projektplan utan föregår ofta en sådan. Projektdefinitionen kan vid behov utvecklas till en projektplan. För examensarbetet är det lämpligt att projektdefinitionen fungera som ”överenskommelse” mellan projektets huvudintressenter vilka oftast är ett företag, studenten som gör arbetet och akademin varifrån studenten kommer. Förändras projektet i något viktigt avseende så uppdateras och förankras projektdefinitionen. |
|---|
Dokumentversion, senaste överst
| Datum | Version | Författare | Beskrivning |
|---|---|---|---|
| 2022-03-22 | <1.0> | Philip Hägg, Ville Vik, Fredrik Janetzky, Casper | Första utkast av projektdefinitionen |
| 2022-04-05 | <1.1> | PH, FJ, VV | Andra utkasten under iteration 2 |
| 2022-05-24 | <1.2> | Casper, Fredrik J, Fredrik L, Daniel, Philip | Slut versionen inför iteration 5 |
Dokumentet syftar till att definiera det projekt som studenterna ska genomföra i grupp inom kursen II1302 Projekt och projektmetoder.
Detta dokument behandlar följande:
- Projektet, organisation och de uppgifter som är kopplade till detta.
- Projektets mål och en tidsplan över hur genomförandet ska lyckas inom utsatt tid.
- Intressenter för projektet.
- Plan för dokument och projektmedlemmarnas utbildningsbehov och plan för det.
- Kostnader, krisplan och riskanalys.
Detta dokument behandlar inte följande:
- Uppdateringar av arbetet under de olika iterationerna.
- Vid eventuella problem som tagits upp i riskanalysen infaller, resultatet om lösningarna fungerar som tänkt eller inte.
- Genomgång av slutförd produkt.
Detta dokument innehåller följande delar: (Eklund, 2010)
- Projekt- eller uppgiftsbeskrivning – detta görs översiktligt och sammanfattande
- Organisation – hur arbetet och samarbete skall organiseras
- Projektmål – vilka är huvud intressenternas syfte/mål med projektet? Varför är man med i detta projekt?
- Fas- och tidsplan – arbetsvolym, projektets varaktighet, översiktlig fas och tidsindelning, flexibilitet i ”projekttriangeln”- projektåtagande (resurser/kostnad-varaktighet(tid)-funktionalitet)
- Intressenter – vilka är projektets intressenter, deras förväntningar och ambition att uppfylla dessa förväntningar och hur.
- Riskanalys – riskidentifiering och åtgärder. Hur hanteras eventuell sekretess och konfidentialitet mm?
- Förändringsplan – hur hanteras och meddelas viktiga förändringar i projektet?
- Kostnader – vilka kostnader finns i projektet? Vem betalar vad? Licenser?
- Dokumentplan – vilka dokument skall användas, underhållas och levereras?
- Utbildningsplan – behov av förstudie, inläsning, utbildning.
- Rapport- och granskningsplan – syfte och tider för rapportering och granskning.
- Referenser – detaljerad referenslista enligt APA, Vancouver eller annat (APA kan vara bra så länge man skriver för man ser författaren och förstår då vilken källa det handlar om medans Vancouver ger ett nummer som inte säger något)
- Projektöversikt – bakgrund, syfte och mål
Detta kapitel ger en översikt av projektet.
Inom kursen II1302 skulle ett mindre it projekt genomföras. Där gruppmedlemmarna skulle ta sig an olika roller som finns inom en projektgrupp och utföra ett sorts rollspel för att illustrera en verklig uppgift som en uppdragsgivare hade gett.
Gruppens uppdrag syftar till att skapa en tjänst som kan förutspå vädret den rullande 7 dagarna. Detta genomförs med hjälp av historisk data insamlad av gruppen som analyseras med hjälp av maskininlärning. Detta ska presenteras i ett gränssnitt på internet för användare att kunna se vädret och dess förutsägelser.
Går det att förutspå vädret med hjälp av statistik och diverse olika faktorer eller är det endast slumpen som avgör?
Genom det här projektet önskar gruppen att kunna skapa en applikation som kan förutspå vädret på ett bra sätt. Fördjupningen i området önskar gruppen att kunna applicera kunskapen på likartade projekt framöver.
Att förutspå väder är något som ofta har många olika variabler som lufttryck, luftfuktighet, vind och temperatur bland annat. Gruppen tror att genom att ta hänsyn till så många olika variabler som möjligt genom en lokalt uppbyggd prototyp ska vi kunna jämföra den datan med historisk data hur vädret kommer se ut inom den närmsta tiden.
Många områden inom projektet är nya för alla gruppmedlemmar som “machine learning” till exempel. Detta ha lett till ett väckt ett intresse för medlemmarna att utforska och fördjupa sig i nya kunskaper.
Slutmålet är att genom gott samarbete inom projektgruppen åstadkomma så liten felmarginal på vädret den kommande veckan med hjälp av maskininlärning. Dessutom strävar gruppen att få ihop en bra applikation som är skalbar, användarvänlig och kan användas till många olika saker.
Genom att jämföra med kända väderleksstationer som yr.no, smhi.se med mera så kommer vi få en bra jämförelse med våra förutsägelser om de stämmer överens med kända utövare inom området. Självklart kommer vi även få en klar bild över det faktiska vädret de kommande dagarna genom att “kolla ut”.
Genom våra jämförelser har vi förhoppningar att självklart komma så nära ett exakt resultat av förutsägelser som möjligt med viss reservation på lite felmarginaler då det är ett mindre skolprojekt.
Funktionella och användningsfallsmodell beskrivs i nedan use case diagram. Användaren kommer att ansluta till tjänsten och kunna se väder över ett visst tidsintervall, som denna ska kunna korrigera själv. Systemet kommer att vara anslutet via azure som hub och hosting plattform. Här kommer hemsidan att hämta sin data och visa upp den för användaren. Till Azure kommer även en IoT enhet vara ansluten och skicka insamlad data till systemet. Systemet kommer att använda maskininlärning för att göra estimeringar av vädret som kommer att presenteras för användaren.
| Must have | Should have | Could have | Would have |
|---|---|---|---|
| Kunna visa väder i ett webbgränssnitt | Ändra tidsintervall | Kunna söka på olika platser för att kolla aktuellt väder | Jämföra maskininlärning ens resultat med statistiska metoder |
| Kunna mäta av vädret från prototyp (IoT) | Användarvänlig hemsida som ger mer än bara visa vädret | Login för att spara favoritplatser | Mobilapplikation |
| Kunna visa förutsägelser i webbgränssnittet | |||
-
Organisation
| Person | Beskrivning | Kontaktinformation |
|---|---|---|
| Casper Kristiansson | Projektledare (Leadership), Projektledare (Management) | [email protected] |
| Daniel Chouster | Hållbarhetsansvarig, Arbetsmiljöansvarig | [email protected] |
| Philip Hägg | Testansvarig | [email protected] |
| Fredrik Janetzky | Arkitekt | [email protected] |
| Fredrik Lundström | Konstruktions- och utvecklingsansvarig | [email protected] |
| Ville Vik | Kund- och kravansvarig | [email protected] |
Projektgruppen går gemensamt igenom vilka uppgifter som ska genomföras i början av varje iteration. Under varje iteration samlas även gruppen vid flertalet tillfällen och avstämmer att allt går enligt plan.
Vi genomför både fysiska och digitala träffar där vi arbetar med projektet. De fysiska träffarna äger rum i electrum som är en del av KTH i Kista, där gruppen har blivit tilldelad rum där projektet genomförs.
Gruppen kommer använda sig av en del elektronik som kommer att köpas inom ramen av den budget som är satt av examinator. Det kan tillkomma eventuell övrig utrustning kopplad till detta, som lödkolv och anslutningsanordningar. Övrig utrustning beskrivs närmare i punkt 3.6.
Huvudsakliga kommunikationskanalen är en Discord-kanal där den mesta informationen samt uppdateringar kring projektarbetet delas. Vid akuta situationer kan messenger eller telefonnummer användas.
Gruppens kommunikationskanal för uppgiften och dess utförande kommer att äga rum på canvas. Genom tjänsten lucidchart kommer gruppen att använda sig av den mall för arbetstavlan som de blivit tilldelade. Lucidchart kommer samtidigt att användas som primärt modelleringsverktyg till de lösningar som skapas av gruppen. Google drive och tillhörande tjänster kommer att användas som lagringsplats för gruppens dokumentation och Gantt schema. För att göra tjänsten tillgänglig använder gruppen tjänsten Azure. Genom tjänsten Github kommer gruppen att samla och upprätthålla den kod som skapas i samband med projektet.
-
Projektets olika mål
Väder-appen går att utveckla inkrementellt med ytterligare funktioner men det finns en grund som måste vara färdig för att kunna användas. Användningsområdena är möjliga att utvecklas inkrementellt utefter projektet med hänsyn till kundens förväntningar men där vissa användningsområden måste uppfyllas.
Målen och dess examination finns tillgänlig på kursens hemsida [1].
Inom kursen II1302 ska vi genomföra ett mindre IT projekt med inriktning på IOT. Syftet med projektet är att påvisa att vi kan arbeta i grupp och samarbeta med varandra. Gruppen arbetar efter tydliga ramar inom kursen och dess examensmål. Projektet demonstreras löpande och kommer att examineras av kursens examinator.
- Gruppdynamik, ledarskap och kommunikation i praktiskt arbete i projektgrupp om 3-8 personer.
- Teoretisk och praktisk projektmetodik enligt etablerad vetenskap och praxis.
- Praktisk utveckling, i grupp, av en IT-prototyp med kravspecifikation, arkitektur, design, programmering/konstruktion, implementation och test.
- Projektekonomi i form av budgetering, planering, utvärdering samt tidrapportering av arbetet.
- Skriftligt systemdokumentation, planering dokumentation samt rapportskrivning.
- Vid behov ingår analys av hållbarhetsaspekter och arbetsmiljö.
Efter godkänd kurs ska studenten, för små IT-projekt, kunna
- föreslå och redogöra för en lämplig, anpassad och till stor del beprövad projektmetod
- ur någon ledningsroll ange och med evidens, genom koppling till erfarenhet från genomfört projekt, motivera metodens styrkor och svagheter
- bidra med idéer och systemutvecklingsarbete
- utifrån någon ledningsroll praktiskt föreslå, planera, organisera, leda och följa upp projektgruppens arbete
- anta ett socialt inkluderande, uppmuntrande och ansvarsfullt förhållningssätt till projektgruppen
- förhålla sig till samhälleliga målsättningar, gällande t ex hållbarhet, vilka är relevanta för projektet samt utvecklad produkt och produktanvändning.
Genom att genomföra projektet med en lyckas slutprodukt så kommer en ökad erfarenhet inom projekthantering att fås. Med tanke på projektets utformning kommer även erfarenhet och kunskap ges inom maskininlärning och problemhantering.
Genom att ta sig an en uppgift, hitta en lösning till problemet samt genomföra lösningen för att få fram en slutprodukt går man genom nästan alla uppgifter en ingenjör ska kunna behandla.
- Projektgruppen har format projektet så att många befintliga delar som redan finns inom skolan kan återanvändas.
- Projektgruppen strävar efter att färdigställa en produkt som kan byggas på i framtiden vilket gör att mycket kan användas av framtida utvecklare.
Gruppen gör inte skillnad på medlemmarnas olikheter och mångfald, utan istället drar nytta av dessa. Under projektets gång kommer alla medlemmar komma till tals där alla åsikter är lika viktiga. Slutprodukten av projektet är inriktad till alla användare där ingen utesluts från användandet av produkten.
- Projektet strävar efter att göra minimal påverkan på miljön.
- Ingen produktion kommer ske i framtiden av produkten vilket medför till att inga utsläpp kan beräknas.
- Gruppmedlemmarna får en jämn arbetsbelastning genomgående i projektet för att undvika en stressig miljö.
- Genom projektet används inte några farliga produkter eller metoder som kan innebära att någon person eller djur kommer till skada. Detta gör att gruppen inte har några specifika riktlinjer för användandet av sådana produkter eller metoder. Gruppen har valt att använda sig av sunt förnuft.
- Det tillämpas god dynamik och en vänlig kultur i gruppen vilket bidrar till en öppenhet och att alla får komma till tals.
Till vårt förfogande har vi studentlicenser till vissa tjänster vi använder under projektets gång. Dessa är kopplade till arbetstavlan med lucidchart samt moln-aspekten med Azure. Dessa licenser är distribuerade av KTH. Allt arbete som skapas av gruppen är dess samlade intellektuella egendom och är upphovsrättsskyddad.
-
Fas-, tids- och arbetsplan
Enligt befintliga kurskrav ska det arbetas minst 16 timmar per vecka på projektet varav minimum 8 timmar ska ske i samlad grupp inne på Electrum, kista.
Arbetet ska vara så jämnt uppdelat som möjligt. Det ska skrivas minimum 300 rader kod per person.
Gruppen planlägger måndagsmöten inför varje iteration där veckans arbete planeras och delas upp. Utöver de planerade grupp timmarna är det upp till varje gruppmedlem om man vill gå djupare och lägga ned fler timmar inom ett specifikt område.
Varje gruppmedlem har tagit på sig ett ansvarsområde vilket medför att man har specifika dokument som man har ansvar över att färdigställa.
Nedan är ett urklipp ur Gantt-schemat som används som iterationsplanering samt tidrapportering för gruppmedlemmarna. Iterationerna är två veckor långa med ett visst antal deadlines samt ett sprintdemo i slutet av varje iteration.
Lista vilka som är projektets intressenter, deras förväntningar och ambition att uppfylla dessa förväntningar och hur.
| Intressent | Namn | Förväntningar | Uppfyllande av förväntningar |
|---|---|---|---|
| Examinator | Håkan Olsson | Att projektet blir färdigt och att gruppen har lärt sig av lärandemålen | Förväntningarna kommer att uppfyllas genom att gruppen arbetar flitigt och metodiskt för att slutföra det utefter de mål som sätts på gruppen. |
| Projektledare | Casper Kristiansson | Att projektet ledaren ska kunna leda gruppen, planera, organiser och utvärdera. | Förväntningarna kommer uppfyllas genom att projektledaren kommer med hjälp av grupp medlemarn göra beslut. Det är även viktigt att projektledaren är organiserade och planerar väl för vad som ska kontinuerligt göras i gruppen. Det är väldigt viktigt att grupp ledaren lyssnar vad de andra grupp medlemarna vill. Genom att uppfylla alla dessa förväntningar kommer gruppen kunna utföra projektet på ett väl strukturerat och bra sätt. |
| Testansvarig | Philip Hägg | Uppsättning av teststrategi och en plan för hur applikationen,m hårdvaran, dokument och utbildning ska testas. | Genom att komma överens med gruppen om hur applikationen ska testas och göra en plan och strategi utefter gruppens preferenser. Genom en god planering förväntas testningen fungera på ett smidigt sätt genom hela projektet. |
| Kravansvarig | Ville vik | Representerar och speglar rättigheter, skyldigheter och åsikter hos andra intressenter. |
Förväntningarna kommer uppfyllas med en empatisk förmåga kunna representera och spegla de olika åsikterna, rättigheterna och skyldigheter som finns hos de andra intressenterna. Detta kommer leda till att kraven uppnås. |
| Arkitekt | Fredrik Janetzky | Sätta upp en bra arkitekturell struktur över mjukvaran samt projektet i helhet. Kunna ta sig an de olika intressenternas behov och omvandla dem till en enhetlig uppsättning av krav. |
Genom att med gruppen komma överens över vilka olika delar/komponenter som behövs inom projektet så gäller det att förstå situation, sammanhang och begrepp komma upp med en arkitektur över projektet. Genom att att applicera logiskt tänkande och slutsatser kommer dessa förväntningar uppnås. |
| Miljö - och Hållbarhetsansvarig | Daniel Chouster | Säkerställer att JML-aspekter och god arbetsmiljö eftersträvas. Även en plan för detta arbete. Är även ansvarig för att programvaran blir hållbar. |
Förväntningarna kommer att uppfyllas med tanke på den hållbarhetsplan som lämnas in i slutet av projektet. Hållbarhetsansvarig har sett till att gruppen följer hållbarhetsplanen och upprättat goda arbetsförhållanden. Hållbarhetsansvarig har även rensat koden och sett till att den är enkel, tydlig och återanvändbar. |
| Utvecklingsansvarig | Fredrik Lundström | Förväntas lägga upp en plan för utveckling och funktionalitet. | Genom att sätta upp en bra plan och design tillsammans med gruppen. |
| Övriga grupper i kursen | Ett väl genomfört projekt samt bakgrund till alla val och metoder | Sprintdemo på slutet av varje iteration där gruppen går igenom vad som har skett under iterationen. |
- Riskanalys
Nedan beskrivs identifierade risker.
Risklista
| ID | Risk | Förebyggande åtgärd | Åtgärder vid riskutfall |
|---|---|---|---|
| R1 | Dålig kommunikation | Se till att planera upp möten, se till att gruppen träffas/samlas. Berätta och lyssna på de andra. | Samlas i projektgruppen och diskutera med varandra vart problemet ligger. |
| R2 | Arbetsbördan blir för stor vilket medför att projektet inte slutförs. | Genom kontinuerlig kommunikation ser man till att alla medlemmar sköter sina ansvarsområden. | Se till att man hjälper vid behov där det behövs. I värsta fall omstrukturera för att färdigställa “must” krav. |
| R3 | Bristfällig planering | Använda beprövade metodik för att genomföra projektet och göra rimliga antaganden av tidsåtgång | Genom en god planering och att förutspå utgången tidigt. Allt eftersom kommer arbetet bli mer konkret och därefter göra en plan med goda uppföljning procedurer. |
| R4 | Frånvarande gruppmedlemmar | Se till att meddela eventuellt förhinder. | De andra medlemmarna får väga upp för den/de saknade medlemmarna. |
| R5 | Bristfällig kompetens/erfarenhet inom området | Se till att göra de nödvändiga efterforskningarna. Kolla med de andra projektmedlemmarna om någon besitter kunskapen | Kolla med examinator om råd alternativt hitta en lättare lösning. |
- Kostnadsplan
Varje grupp har tilldelats en summa om 500 svenska kronor som kan användas vid eventuella inköp av hårdvara. Vid nuvarande utkast <1.1> verkar det som att alla delar kan tillhandahållas i skolan, det vill säga att inga pengar kommer nyttjas.
Examinatorn har befäst att pengarna inte får användas av diverse onlinetjänster som licenser/moln då skolan redan har licenser hos olika tjänster som eleverna har tillgång till.
- Dokumentplan
| Dokument | Levereras |
|---|---|
| Projektdefinition | Iteration 2, Iteration 5 |
| Visionsdokument | Iteration 2, Iteration 5 |
| Game ScoreCard | Varje iteration |
| Iterationsdokument | Varje iteration |
| Arbetstavla | Uppdateras hela tiden |
| Hållbarhetsbeskrivning | Iteration 5 |
| Testdokument | Iteration 5 |
| Arkitekturbeskrivning | Iteration 5 |
| Komponentbeskrivning | Iteration 5 |
| Slutrapport | Iteration 5 |
| Lessons learned | Iteration 5 |
- Utbildningsplan
Då projektet delas upp mellan de olika gruppmedlemmarna så kommer lite olika inläsnings studier att ske beroende på vad varje gruppmedlem är ansvarig över.
Gruppen i helhet strävar att hjälpa och utbilda varandra inom diverse områden där en länk möjligen har svårare och en annan har lättare. Detta kommer förhoppningsvis medföra att projektet kommer rulla på under varje iteration.
Varje gruppmedlem behöver dock göra en del inläsning på olika programmeringsspråk som kommer användas inom projektet, gruppmedlemmarna har en del förstudier inom det här från tidigare kurser.
Appendix A - Referenser
[1] Royal Institute of Technology, “II1302 Projekt och projektmetoder” https://www.kth.se/student/kurser/kurs/II1302/?l=sv (accessed Maj 23, 2022)
Andersson, N., & Ekholm, A. (2002). Vetenskaplighet - Utvärdering av tre implementeringsprojekt inom IT Bygg & Fastighet 2002.
Eklund, S. (2010). Arbeta i projekt: individen, gruppen, ledaren: Studentlitteratur.
Kniberg, H. (2014). Scrum and XP from the Trenches - How we do Scrum: InfoQ