Kommunikation är viktigt! Den interna kommunikationen förhindrar miss-förstånd och ser till att alla i gruppen är uppdaterade på hur projektet ligger till. Det leder till en mer produk- tiv grupp som skapar en produkt av högre kvalitet. Kommunikationen med kunden gör att gruppen får återkoppling på det arbete som är utfört och kan planera framtida arbete enligt
E.9. Slutsatser
kundens nuvarande önskemål. Att kommunicera öga mot öga är att betydligt mer effektivt än andra metoder.
Det finns mängder av verktyg som är användbara för att försäkra sig om kvaliteten på ett projekt. Det finns vanligtvis flera alternativ för en viss uppgift och ofta fungerar det som är mest populärt bland andra utvecklare bra. Om inte är det enkelt att prova något annat och hoppas på bättre lycka.
F
Testning i ett mjukvaruprojekt
och dess
påverkan av Per Olin
Den här delen av rapporten är skriven av Per Olin som är gruppens testledare.
F.1
Inledning
Testledaren i ett projektarbete har som uppgift att lägga upp en plan som ser till att produkten testas och uppfyller de krav som ställs på den. Som testledare behöver man analysera vad i ett system som behöver testas, vilket betyder att man behöver ha bra koll på hela systemet. I den här utredningen kommer jag att gå igenom hur vi testade vårt system, samt varför vi valt att använda de metoderna.
F.2
Syfte
Syftet med avsnittet är att gå igenom vad en testledare har för uppgift samt ta fram och diskutera de metoder som använts för att testa ett system och huruvida testplanen följts och varför.
F.3
Frågeställning
• Hur testar man programvara i ett projekt där systemet består av flera enheter? • Hur påverkar tester kvalitén hos slutprodukten?
F.4
Bakgrund
Systemet som ska testas är uppbyggt av tre enheter, Sensorenhet, Backend och Frontend. Sensorenheten har uppgiften att omvandla viktdata från vågar och skicka vidare det till Backend. Backend har uppgiften att vara ett gränssnitt mot databasen som finns i Backend. Backend tar hand om all data som skickas in och ut ur databasen, samt ser till att data är på rätt format. Frontend har uppgiften att presentera data som finns i databasen på ett tydligt och effektivt sätt.
F.5. Teori
Uppbyggnaden av systemet har skett i små grupper för att effektivisera teamets arbete. Efter- som arbetet är uppdelat så blir kunskapen om hur varje enhet fungerar till punkt och pricka fördelad inom teamet.
Sammanställandet av testplanen var en process som jag inte utförde själv. En testplan bör täcka alla aspekter av systemet. Då jag arbetat med Frontend tog jag in hjälp från dem som arbetade på de andra delarna i systemet.
F.5
Teori
För att skriva kod som testar systemet använde vi oss av ramverket Mocha och assertverk- tyget Chai. [31] [32]Mocha är ett ramverk som kan användas vid asynkron testning vilket är användbart vid testning av hemsidor och servrar. Chai är ett verktyg som vi använder oss av för att försäkra oss om att data som skickas in i funktioner är på rätt format. Med hjälp av dessa verktyg kan vi skriva kod som testar hela systemet åt oss och vi får feedback som säger vad som inte fungerar ifall ett fel inträffar.
Produktens kvalitet påverkas av den mängd tid som har spenderats på att bygga den. Genom att följa en testplan och köra tester kontinuerligt under systemets uppbyggnad blir det lättare att hitta fel tidigt. Det blir kostsamt att hitta ett stort fel sent i ett projekt jämfört med att hitta det tidigt. [33]
De metoder som används för att testa systemet är “white box testing” och “black box testing”. White box testing går ut på att testa en enhets interna struktur. Genom att kontrollera sig- nalerna som skickas in i enheten kan man avgöra hur enheten borde behandla insignalerna. På det sättet kan man se ifall den interna strukturen fungerar eller inte, eftersom om en- heten behandlar insignalerna som förväntats så kan man dra slutsatsen att enheten fungerar. Processen fortsätter tills man har testat alla olika vägar i enheten, även kallat “full path cov- erage”. [34]
Black box testing går ut på att testa systemets alla funktioner även kallat “function coverage”. På samma sätt som white box testing skickar man in signaler i enheten och kollar på hur enheten behandlar insignalen. Skillnaden mellan black och white box testing är att i black box testing så testas bara funktionaliteten hos enheten. En annan skillnad mellan black och white box testing är att i black box testing så behöver man inte veta hur enheten fungerar internt. Det räcker att veta vad för signaler man kan skicka in samt hur enheten borde svara på dem.
F.6
Metod
För att se till att de krav som är satta på systemet blivit uppfyllda skrevs en testplan. Testpla- nen består av tester som systemet utsatts för. För att underlätta testning av hela systemet så är det specificerat hur delar ska testas samt vilka delar som måste testas tillsammans. Testerna som valdes är utformade från kraven i kravspecifikationen för att se till så slutprodukten fungerar som lovat.
Systemet utsattes för tester under hela uppbyggnaden. Testningen utfördes i fem faser. Det var två faser som fortlöpte under hela projektets gång, de var fas ett och fas två.
Fas ett gick ut på att testa nyimplementerade funktioner, testningen av funktionerna gjordes enligt white box testing principen. De funktioner som inte uppfyllde sin funktionalitet blev omskrivna och sen testade på nytt.
F.7. Resultat
Fas två gick ut på att integrera den nya funktionen med annan kod för att bilda en enhet. När funktionen hade integrerats med resterande kod, så blev enheten testad enligt black box testing principen. Ifall integrationen misslyckades fick man studera den nya funktionen för att identifiera felet. Efter att felet hade åtgärdats utfördes samma test som tidigare på enheten. Processen upprepades tills enheten fungerade som planerat.
Fas tre utfördes när en hel enhet var klar, även kallad enhetstestning. Enhetstestningen gick ut på att testa hela enheten. För att testa hela enheten testades den enligt white box testing principen. Ifall enheten inte fungerade som planerat, skrevs kod för att laga den enheten. Därefter testades enheten på nytt när felet var åtgärdat.
Fas fyra utfördes när två eller fler enheter var klara, kallad integrationstestning. Integra- tionstestning gick ut på att se ifall enheterna fungerade ihop med varandra. Det gjorde vi genom att koppla ihop enheterna och se på vad för data som skickades emellan dem, samt studera vad enheten som tog emot data gav för svar. Ifall det inte fungerade kontrollerade vi ifall data som skickades var korrekt för att identifiera i vilken enhet som felet låg. Efter felet åtgärdats utfördes integrationstesten på nytt.
Fas fem, den sista fasen gick ut på att testa hela systemet, kallad systemtestning. Systemtestet gjordes enligt black box testing principen. I nuläget hade alla enheter testats, och testet gick ut på att se så all funktionalitet fanns. Ifall det är någon funktionalitet som saknades, imple- menterades den funktionaliteten och sen utfördes testningen på nytt.
F.7
Resultat
Metoden vi använde för att testa systemet gav ett bra resultat. Genom att testa systemet en- hetsvis under dess uppbyggnad gick det snabbt att verifiera ifall enheten fungerade som den skulle. Enhetstesterna utfördes i början av uppbyggnaden, men senare när integrationen av systemet börjat, upphörde enhetstesterna, och därefter utfördes flera systemtester. Eftersom gränssnitten mellan enheterna var väldefinierade så utförde vi inte integrationstest mellan varje enhet.
Resultatet av testningsmetoden gjorde att vi hittade ett par fel i vår kod tidigt under utveck- lingen, eftersom koden testades frekvent enligt fas ett och två. Det gjorde att vi snabbt kunde identifiera felaktigheter i systemet. De två faserna kördes frekvent eftersom bara små delar av kod behövdes testas åt gången, vilket gjorde att man lättare kunde hitta felen.
Testningen av koden vi skrivit var till en början tänkt att göras med Mocha och Chai, men under utvecklingen användes det inte så flitigt som tänkt. Under utvecklingen skrev vi ut- skrifter till konsolen, och därifrån kunde vi verifiera ifall det fungerade som planerat eller inte.
Att ha en testplan, med vad som ska testas nedskrivet, gjorde det lättare att verifiera att systemet fungera som tänkt.
F.8
Diskussion
Metoden som vi använde för att testa systemet fungerade bra, men kan bli förbättrad. Större delar av metoden användes fullt ut, men det var en av faserna som inte utfördes hela tiden. Fas tre gick ut på att testa enheten enligt white box testing principen, men redan i fas ett, när man skrivit en funktion så blir den testad enligt denna princip. I fas två integreras den testade funktionen med resterande kod, då kommer enheten att bestå av fullt testad kod. Att
F.9. Slutsatser
köra fas tre testet därefter känns redundant och ineffektivt då koden redan testats helt och hållet.
Resterande faser gav testandet av systemet ett bra och naturligt flöde. Genom att testa sin kod strax efter den blivit skriven fick man snabbt respons på om det fungerade eller inte. Det gjorde att planeringen av framtida arbetsuppgifter underlättades. Ifall koden fungerade direkt kunde man börja integrationen med resten av systemet, annars visste man var felet i koden var och kunde fixa det.
Om felen identifierats tidigt så blir det bara små delar kod som behöver skrivas om. Vilket gör att det är mer tid över till att utveckla produkten. Det var också av samma anledning som vi inte använde testningsverktygen Mocha eller Chai så mycket, för att spendera mer av vår tid på att utveckla systemet.
Under testningen av systemet användes testplanen som en checklista för vad som återstår att testas. Vissa tester borde ha specificerats mer i testplanen för att underlätta testandet. Testplanen blev inte uppdaterad under projektets gång, vilket gjorde att några tester inte längre var aktuella. Ifall den blivit uppdaterad under projektets gång skulle testerna vara bättre beskrivna och aktuella.
Felen vi hittade i koden blev ofta funna under fas två när enheterna bildades. Eftersom i det steget är första gången man ser hur det fungerar med riktig indata. Under utvecklingen var det inget fel som låg mellan enheterna, vilket är därför vi hade väldefinierade gränssnitt där emellan.
Vi utförde inga kodinspektioner utöver att se till så att koden följde en viss kodstandard. Kodinspektion är en vanlig metod för att hitta fel i koden innan mjukvaran testas. Istället för att köra inspektioner testade vi koden direkt för att se var eventuella fel låg. En fördel med kodinspektioner är att det inte är personen som skrev koden som rättar den. Det skulle ha gjort att gruppen fick en bättre överblick hur varje enhet fungerar.
F.9
Slutsatser
För att testa ett system som består av flera enheter underlättar det att köra tester kontinuerligt och i flera faser. Genom att testa kontinuerligt identifieras fel snabbt. Testning i faser gör det lättare att hitta var felet ligger eftersom det är en mindre mängd kod som testas åt gången. Som det beskrivs i metoden så var det bra att arbeta sig uppåt med testerna, från att testa en funktion till en enhet och tillslut till ett system.
Genom att skriva tester som är utformade från en kravspecifikation kommer systemet att ha uppnått den kvalité som kunden begärt ifall systemet har gått igenom alla tester. Genom att utföra tester frekvent sparar man in tid som kunde ha spenderats senare under ett projekt för att fixa större buggar. Det gör att man har mer tid att lägga på utvecklingen av sin produkt, vilket gör att produktens kvalité ökar.
G
Teamledarens roll och verktyg
inom
projektledning av Michael
Sörsäter
Denna del är skriven av Michael Sörsäter som har haft rollen som teamledare i projektet.
G.1
Inledning
Texten behandlar hur rollen som teamledare kan vara i ett projekt samt hur stor resurs det kan vara med projektverktyg i arbetet.
Rollen som teamledare innebär att leda projektet för att uppnå de mål och finna svar på de frågeställningar som ställts upp. Teamledaren representerar teamet utåt mot beställaren och har ansvar för att en god arbetsmiljö uppehålls.
Skillnaden mellan en teamledare och en projektledare är att en projektledare mer styr projek- tet och har mer kontroll över beslutsfattandet. En teamledare arbetar istället utifrån att hen är en del av teamet men är ytterst ansvarig och ledare för projektet. Om projektet kommer till att ett beslut behöver fattas har teamledaren sista ordet.
Teamledarens arbetsuppgifter kan variera i ansvarsområde, fokus kan ligga på planering, dokumentering och strukturering av arbetsgången. Teamledaren ansvarar även för att kom- munikationen med handledare och examinator sköts.
G.2
Syfte
Syftet med texten är att förklara vad rollen teamledare innebär och berätta hur jag utförde rollen i detta projekt. Jag kommer även diskutera hur viktig rollen som teamledare är och hur pass stor ledarroll en teamledare bör ha i ett sådant här projekt.
G.3
Frågeställning
G.4. Bakgrund
• Kan projektverktyg och specifika arbetsmetoder underlätta organiseringen av ett pro- jekt?
G.4
Bakgrund
I början av projektet skulle vi utse en teamledare och efter det bestämma de övriga rollerna. Jag tog tidigt på mig rollen att organisera de första träffarna och blev sedan föreslagen att vara teamledare. Tillsammans fördelade vi de övriga rollerna på ett så bra sätt som möjligt genom att alla fick lämna in förslag på topp tre roller de önskade ha. Då vissa roller var mer attraktiva än andra fick vissa kompromisser göras men fördelningen av roller blev bra. Vi tilldelade även viceroller för att ha en reserv om någon skulle vara sjuk eller av någon annan anledning ej ha möjlighet att delta.
En teamledare tar ofta på sig uppgifter som att strukturera projektet och delegera uppgifter till de övriga projektmedlemmarna. I början av projektet diskuterades hur upplägget i detta projekt skulle vara och vi kom fram till att vi ska dela på de organisatoriska uppgifterna för att inte behöva lägga alla de uppgifterna på teamledaren. Vid större beslut som ska fattas i projektet fattar vi de besluten tillsammans som grupp.
Tidigt i projektet började vi arbeta med att ta fram en kravspecifikation, projektplan och kvalitetsplan. För att effektivisera dokumentskrivandet delade vi upp oss i mindre grupper och fokuserade tidigt på att få kravspecifikationen klar så vi kunde omfördela resurserna på de andra dokumenten. Då vi var samtliga i gruppen som arbetade med kravspecifikationen gjorde det att vi alla var enade om vad vi skulle göra och hur vi faktiskt skulle göra det, vilket var väldigt bra. Efter det började vi arbetet med de tre iterationerna. Under iterationerna har många beslut om design och prioriteringar behövts göra. Besluten har vi fattat tillsammans och det har varit få tillfällen vi faktiskt varit oense om hur vi ska göra.
G.5
Teori
I projektarbeten finns det många olika typer av ledarroller. Vilken roll som teamledaren tar är viktig för projektets utfall. Det finns ledare som bestämmer när och hur saker ska göras och det finns ledare som mer är en del av teamet och leder arbetet med gemensamt beslutsfat- tande. Dessa kan kallas chef och koordinator respektive. I de projekt där ledaren är koordina- tor ökar deltagandet i beslutsfattandet och även motivationen hos medlemmarna i projektet ökar. Om ett projekt är i behov av snabbt beslutsfattande samt att ledaren inte behöver ha omfattande teknisk kunnighet kan det vara effektivt att ha en mer styrande ledare. [35] För att planera och strukturera ett projekt används ofta olika typer av projektverktyg. I detta projekt har vi använt flertalet verktyg.
“ALPHA State Cards” är ett verktyg för att planera ett projekts olika iterationer men också för att få en överblick över projektets status ur olika aspekter. De olika aspekterna är bland annat behov och möjlighet till att utveckla produkten, de viktiga parterna i projektet, spec- ifiering av krav, hur systemet ska byggas samt hur teamet fungerar att arbeta tillsammans. Under utvecklingsarbetet ska regelbundna synkningar mot planeringen göras för att uppdat- era status och eventuella flaskhalsar. ALPHA State Cards är ett bra verktyg för att tydliggöra stadiet projektet är i. [8]
För att organisera och dela upp arbetet finns ett behov av planeringsverktyg. Ett sådant verktyg är Trello. Vid arbete efter metoden Kanban kan man visualisera de olika kategorierna på ett smidigt sätt i Trello. Man kan även sätta olika märkningar på aktiviteterna för att markera exempelvis prioriteringsnivå samt tilldela olika personer till specifika aktiviteter.
G.6. Metod
Genom att ha olika Kanbanboards för olika iterationer får man en tydlig översikt om vad nästa aktivitet är samt hur arbetsflödet ser ut.
Slack är en chattjänst som har utökad funktionalitet som olika kanaler, kalenderuppda- teringar, uppdateringar om commits till ett git repo och fildelning. Genom att samla kom- munikationen i ett verktyg undviks krångliga mailkonversationer och andra tjänster.
Toggl är ett tidsrapporteringssystem där aktiviteter läggs in med beskrivning och tidsinter- vall. Det går att sammanställa veckovisa rapporter ur Toggl för att skapa tidrapporter.
G.6
Metod
För att ta reda på hur teamledaren ska arbeta för att leda teamet så bra som möjligt ska jag analysera hur min ledarroll har sett ut under projektet samt se på de motgångar och problem teamet stött på under projektets gång. Jag ska även kolla på de fördelar och nackdelar min ledarroll har gett upphov till.
Projektverktygens inverkan på arbetet ska jag undersöka genom att se på de positiva effekter vi fått ut av dem samt vilka eventuella brister eller risker de kan föra med sig.
G.7
Resultat
Under förstudien delade vi upp skrivandet av de olika dokumenten. De rollerna som har haft ett dokument kopplat till sin ansvarsroll har varit ansvariga för det dokumentet. Hur de andra delade upp sig på dokumenten fick teammedlemmarna lämna önskemål om och vi fattade beslut om fördelningen som grupp. Jag ansvarade för att lägga in våra ALPHA:s i Trello och se till att de sedan vid utvärderingarna av iterationerna uppdaterades.
Under projektet har vi ansvar mot kursledningen att tidsrapportera. För att göra detta på ett effektivt sätt använde vi Toggl och vid varje veckoslut exporterade vi en individuell veck- orapport som sammanfogades tillsammans med en veckoplanering. För att sammanställa dessa timmar men också för att visualisera hur arbetet gick framåt skapade jag ett kalkylark med tidssummering, en så kallad “Burn down chart” samt färgkodades de olika medlem- marnas timmar för att visa hur pass bra de olika medlemmarna ligger till tidsmässigt mot planeringen.
I projektet har vi arbetat efter Kanban. För varje iteration har vi lagt in de olika aktiviteter som behövs, vi har även kompletterat med fler aktiviteter allt eftersom vi kommer på fler. För att lättare få en översikt över de olika aktiviteterna har vi tilldelat aktiviteter till vissa personer. Senare i projektet har vi även lagt prioriteringsmärkningar på dem.
G.8
Diskussion
För att arbeta bra i en grupp är det viktigt med en fungerande gruppdynamik och bra kom- munikation. Då vi har fått tillgång till ett kontor i gamla TekNat-biblioteket har det gjort att vi huvudsakligen mötts där och arbetat tillsammans. Det har gjort att kommunikationen är snabb och effektiv vilket gör att arbetet mycket lättare kan fortskrida, det tror jag har varit en bidragande faktor till att det gått bra.
Efter varje iteration hade vi en utvärdering av iterationen och gick då även genom uppnådda ALPHA:s och uppdaterade oss om vad som skulle uppnås i nästa iteration. Det gjorde att vi fick en överblick över hur vi låg till och vad som var önskvärt att ha med i nästa iteration. ALPHA State Cards kan säkert vara ett väldigt bra verktyg men i detta projekt kände vi inte