Projektdefinition · Web viewDetta dokument är en projektdefinition (Eklund, 2010) för...

KTH ICT Studentprojekt

DoorNoteProjektdefinition

Abstract

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

Date Version Author Description21/03/2017 1.0 Jesper Bergman Ett första försök

28/03/2017 1.1 Erik Droh Ett andra likaså

<Konfidentialitet, -, ingen>

KTH ICT Studentprojekt ProjektdefinitionDoorNote Version <1.1>

Innehållsförteckning

1 Introduktion............................................................................................................31.1 Dokumentets syfte..........................................................................................31.2 Dokumentets omfattning................................................................................31.3 Dokumentöversikt..........................................................................................3

2 Projektöversikt – bakgrund, syfte och mål.............................................................42.1 Bakgrund........................................................................................................42.2 Syfte...............................................................................................................42.3 Mål.................................................................................................................42.4 Funktionella krav - användningsfallsmodell..................................................4

3 Organisation...........................................................................................................53.1 Personer i projektet.........................................................................................53.2 Möten.............................................................................................................53.3 Arbetsplats......................................................................................................53.4 Arbetsutrustning.............................................................................................5

3.4.1 Github.....................................................................................................6

4 Projektets olika mål................................................................................................74.1 Uppgiftsägaren...............................................................................................74.2 Kursmål och examensmål..............................................................................7

4.2.1 Vetenskaplighet......................................................................................74.3 Hållbarhetsaspekter........................................................................................74.4 Etik, jämställdhet och likabehandling (JML).................................................7

5 Fas-, tids- och arbetsplan........................................................................................9

6 Intressenter...........................................................................................................10

7 Riskanalys............................................................................................................117.1 Riskanalys....................................................................................................117.2 Riskbedömning.............................................................................................11

8 Förändringsplan....................................................................................................12

9 Kostnadsplan........................................................................................................13

10 Dokumentplan......................................................................................................14

11 Rapport- och granskningsplan..............................................................................15

Appendix A - Referenser..............................................................................................16

<Konfidentialitet, -, ingen>document.docx Sida 2 av 16


1 Introduktion

1.1 Dokumentets syfteDetta dokuments syfte är att vara grunden till och sammanfatta ett projekt som kommer att genomföras i kursen II1302 KTH – Kista VT2017.

1.2 Dokumentets omfattningDetta dokument behandlar följande:

Översikt för projektets mål, omfattning och genomförande.

Detta dokument behandlar inte följande:

Tekniskt tillvägagångssätt Arkitektur Detaljer om tekniska specifikationer så som kod eller hårdvaruval.

1.3 DokumentöversiktDetta dokument innehåller följande delar:

Projekt- eller uppgiftsbeskrivning – detta görs översiktligt och sammanfattande

Organisation – hur arbetet och samarbete skall organiseras

Projektmål – vilka är huvudintressenternas 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?

Rapport- och granskningsplan – syfte och tider för rapportering och granskning.

Referenser – detaljerad referenslista.



2 Projektöversikt – bakgrund, syfte och målDetta kapitel ger en översikt av projektet.

2.1 BakgrundDetta projekt genomförs i kursen Projekt och Projektmetoder II1302. Kursens syfte är att utveckla och fördjupa kunskaper inom projektmetodik och tillvägagångsätt. Produkten som vi ska utveckla är liten skärm som användaren ska kunna placera i eller utanför sitt kontor för att sedan kunna informera sina kollegor om var man är. T.ex. om man är på möte eller semester. Skärmen ska kunna uppdateras från var som helst i världen via en webbapplikation där användaren fyller i ett meddelande som sedan visas på skärmen som hör till användarens konto.

2.2 SyfteSyftet med detta projekt är att framställa en produkt enligt en kunds önskemål och kravspecifikation samt att lära sig arbeta med agila arbetsmetoder i grupp.

2.3 MålMålet med projektet är att i en grupp försöka framställa en produkt som består av en hårdvaru- och en mjukvarudel. Produkten ska kunna användas av anställda på företag som köper in teknologin så att dessa personer enkelt kan kommunicera med kollegor vart de befinner sig om de inte är på kontoret.

2.4 Funktionella krav - användningsfallsmodellGrundkraven kan sammanfattas med en bild, se Figur 2. Det finns utförligare beskrivningar samt utbyggnad av användningsfall, men för dessa rekommenderas att läsa den korrekta kravdokumentationen. Här ges endast en överskådlig vy.

Figur 2: Use case diagram som visar användarens interaktion med systemet och deltagare



3 Organisation

3.1 Personer i projektetPerson Kontaktinformatio

n och beskrivningRoller

Erik Droh [email protected] Projektledare

Jesper Bergman [email protected] Kund och kravansavarig, Utvecklingsansvarig (Mjukvara)

Johnny Sada [email protected] Utvecklingsansvarig (Hårdvara), arbetsmiljö, hållbarhet, etik och moral.

Axel Blomkvist [email protected] Arkitekt, Testansvarig

3.2 MötenMöten utförs i form av standup första 15 minutrarna av arbetspassen. Under sin standup så berättar man kortfattat vad man ska göra under dagen, vad status för något är som man arbetat med under en längre tid eller om man stött på några problem som gör det svårt för någon att fortsätta enligt tidsplan. På så sätt får alla i gruppen en bra förståelse för hur alla ligger till, individuell arbetsbörda och om man måste försöka hitta en lösning på ett problem som någon stött på.

Vi har även veckoavslutsmöten då vi i detalj går igenom vad som ska göras nästa vecka, precisa arbetstider och potentiella hinder som kan uppkomma som vi bör lösa så fort som möjligt. Varje sprint planeras även under ett sprintuppstartsmöte där vi tillsammans går igenom vad som ska göras under en sprint och vad målet med sprinten är så att alla har samma syn på vad som ska levereras i slutet av sprint perioden.

3.3 Arbetsplats Under inplanerade arbetspass så används Elektrums grupprum. Vi är väl förberedda och bokar alltid upp grupprum inför våra inplanerade arbetspass. Individuellt arbete sker även hemifrån. Arbete som utförs hemifrån koordineras genom kommunikation i Facebook Messenger och projektöversikt via Trello.

3.4 ArbetsutrustningFör att få en bra överblick över projektet används en whiteboard-tavla med en Scrum struktur. Tavlan har två olika sidor där ena sidan främst är för det interna teamet och andra sidan används för att visa kund eller andra externa intressenter. Då en risk för oss är att tavlan blir saboterad så upprätthåller vi även en digital backupversion av tavlans sprint backlog och status för olika delar i nuvarande sprinten i Trello. Utöver utrustning för att visualisering av projektet så används egna datorer för att utveckla produkten. Övrig dokumentation så som Projektdefinition lagras i Google Drive där vi enkelt kan dela dokument i gruppen. Slutligen så kommer vi även att skriva


mailto:[email protected]





blogginlägg1 efter varje dag då vi aktivt arbetar tillsammans på plats. För kommunikation använder vi Facebook Messenger.

Figur 2: Dispositionen av projekttavlan, framsida till vänster och baksida till höger

3.4.1 GithubFör versionshantering använder vi GitHub. Eftersom projektet består av två grundpelare som är hårdvaru- och mjukvarurelaterat så delar vi upp vår repository i två delar. Dessa är; webbapplikation och display. De utvecklingsansvariga för varje del i projektet ser till att sin branch sköts korrekt enligt regler nedan. De arbetsflöde vi kommer att följa är:

1. Skapa branch för enskilt område per sprint. T.ex. Sprint #1 – Webbapp.2. Commits görs enligt sprint backlog med matchande namn och beskrivning till backlogen så att

man enkelt kan se historik på vad som gjorts och varför.3. När alla ändringar och funktionalitet är skapad för specifik sprint diskuterar man koden

tillsammans i respektive utvecklingsområde. Förbättringar kan se i detta stadie. 4. När allt ser ut som det ska så mergar både Webbapp och Display branch - sprint #X till master

och släpper en sprint release.

Figur 3: Illustration av Github workflow

1 https://projektmetoder.wordpress.com


https://projektmetoder.wordpress.com/


4 Projektets olika målVilka är de olika intressenternas mål med projektet?

4.1 UppgiftsägarenVi slutet av projektets gång så är en fullt fungerande produkt inte ett krav. Vi ska dock arbeta mot och sträva efter att försöka uppfylla det. Vid varje sprint finns krav att produkten och projektet ska utvecklas. Vi har som metod att försöka angripa de svåra och stora problemen först tillsammans, de hinder som kan kännas som svåröverkomliga. Om vi lägger fokus på dessa och lyckas lösa dem så har vi sedan tid över för att göra de enklare uppgifterna på egen tid hemma eller i grupp. Genom iterativ planering i form av sprintar enligt Scrum-metoden så kommer vi närmare uppgiftsägarens vision vecka för vecka.

4.2 Kursmål och examensmålDels skulle projektformen i kursen kunna likna den i examensarbetet, eftersom båda löper över en tidsperiod om två månader. Examensarbetet sker förvisso på heltid till skillnad från kursen men huvudmomenten och iterativ, inkrementell utveckling kan nog kunna att tillämpas framgångsrikt i båda grenar.

Gällande vetenskaplighet och referenser liknar de båda projekten varandra, det gäller att hitta stöd i befintlig forskning och/eller litteratur för sina teser och fortskridanden. Kursrapporten kommer i någon mån innehålla samma formella struktur även om exa-mensjobbsuppsatsen blir mer utförlig.

4.2.1 VetenskaplighetVärdera projektets vetenskaplighet/ingenjörsmässighet, använd rapport från LTH (Lunds Tekniska Högskola) som källa/referens (Andersson & Ekholm, 2002).

Kursrapporten är vetenskaplig i kvalitativ bemärkelse, både resultat och slutsatser kan komma att hjälpa exempelvis framtida studenter men även bidra till vetenskaplig forskning gällande projektform i allmänhet.

Så länge kursrapporten konsekvent refererar till befintlig forskning som styrker åsikter och moment finns det vetenskapliga dimensioner i den, något som också gäller genomgående i examensarbetet.

4.3 HållbarhetsaspekterKopplat till projektgenomförande

Försök att arbeta digitalt istället för att använda fysiska resurser.

Kopplat till produkt/tjänst som utvecklas dess användning och avveckling

Minska energiförbrukning för produkten genom att hårdvara går in i ”sleep mode” under tider då den inte används.

4.4 Etik, jämställdhet och likabehandling (JML)Kopplat till projektgenomförande



Johnny fyll i

Kopplat till produkt som utvecklas och dess användning

Johnny fyll i



5 Fas-, tids- och arbetsplanProjektet pågår under en tidsperiod om cirka åtta arbetsveckor och en tentavecka. Under tenta veckan färdigställs rapport och bilagor. De åtta arbetsveckorna innefattar 200 arbetstimmar per projektmedlem vilket leder till ungefär 22 timmar per vecka under hela perioden. Projektet grundar sig i en agil projektmetod som bygger på sprintar och iterationer där varje sprint är två veckor lång. Av de 200 inplanerade timmarna blir ca 140–150 timmar effektiv tid vilket avrundar till ungefär 19 timmar per person i veckan.

Tidsrapportering sker individuellt i ett delat Google Excel-dokument där projektmedlemmar anger nominell-, planerad-, arbetad- och effektivuppgiftstid. I slutet av varje vecka går vi tillsammans igenom tidsplaneringen för att se om någon tar på sig för mycket eller för lite ansvar gentemot övriga personer. Detta för att minska risken av att någon tar över projektet som tas upp i kapitel 7 om riskanalys.

Figur 4. Schema över projektets gång och tidsplanering



6 IntressenterLista 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

Grupp 3 Erik, Jesper, Axel, Johnny

DoorNote Avsluta projekt och färdig produkt enligt kundspecifikation.

Examinator

Anders Sjögren

Att projektmedlemmar ska lära sig agila projektmetoder och applicera detta i ett projekt.

Samtliga dokument under rubriken dokumentplan i detta dokument med tyngdpunkten på kursrapport.



7 RiskanalysNedan beskrivs identifierade risker.

7.1 RiskanalysID Risk Förebyggande åtgärd Åtgärder vid riskutfall

R1

Någon blir sjuk Uppgifter som ej kräver närvaro.

Skype/facebook för kommunikation

R2

Trådlös kommunikation mot display funkar inte

Små experiment för att se hur det fungerar.

Använda trådbunden kommunkation

R3

Interna konflikter Bra kommunikation, högt i tak. Veckoreflektion.

Ta in Anders Sjögren

R4

Någon tar över stora delar av arbetet

Bra fördelning av arbetsuppgifter och att alla har samma syn på projektplan.

Timeout

R5

Whiteboard saboteras Föra digitala anteckningar parallellt.

Återställa tavlan enligt digitala anteckningar.

7.2 RiskbedömningHög sannolikhet

Liten påverkan R2 Stor påverkan

R1 R5

R3 R4

Låg sannolikhet



8 FörändringsplanFörändringar i projektet gäller om kunden/beställaren vill ändra i befintlig specifikation. Förändringar innefattar ytterligare funktionalitet, ombyggnad av någon befintlig funktionalitet eller att något tas bort. Från kund/beställare tar kundansvarig emot feedback och försöker få en så bra bild av vad kund efterfrågar. Därefter meddelar kundansvarig övriga medlemmar i teamet om förändringar som planeras in i sprint backlog vid nästa sprint möte. Om det behövs skapas nya ”user stories” som satisfierar och ger bra inblick i nya potentiella scenarion.



9 KostnadsplanVilka kostnader finns i projektet? Vem betalar vad? Licenser?

Typ Användningsområde Pris Finansiär

Raspberry Pi KTH

Display komponenter

KTH

Utvecklingstimmar Project group 3

Whiteboard tavla KTH

Batterier Project group 3

Serverkostnader Project group 3



10 DokumentplanVilka dokument skall användas, underhållas, granskas och levereras? När skall detta ske och för vilka?

Namn Tid Ansvarig Beskrivning

Produktvision Före projektstart

Erik Dokument för att sammanställa en enhetlig vision för produkten.

Kravdokumentation

Före projektstart

Jesper Dokumentation som sammastället kundens krav innan arbete börjar.

Projektdefinition Före projektstart

Alla Dokumentation som sammanställer hur vi arbetar i projektet.

Arkitektur Före och under sprintutförande

Axel Beskriver projektets uppbyggnad i olika abstraktionsnivåer.

Tidsrapportering Varje dag Alla Individuell tidsrapportering.

Blogg Varje dag Jesper https://projektmetoder.wordpress.com/

Product Backlog Inför varje sprint

Jesper Funktionalitet som ska implementeras i projektet.

Digital Backup Slutet av varje vecka

Erik För digital backup av whiteboard i Trello.



11 Rapport- och granskningsplanUnder denna rubrik följer typ, datum och beskrivning för olika typer rapportering och granskning. Exempelvis för olika sprint releaser eller rapportskrivning

Typ Datum Beskrivning



Appendix A - ReferenserAndersson, 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.


Projektdefinition · Web viewDetta dokument är en projektdefinition (Eklund, 2010) för...

Documents

Transcript of Projektdefinition · Web viewDetta dokument är en projektdefinition (Eklund, 2010) för...