Linköpings universitetSE–581 83 Linköping

013-28 10 00 , www.liu.se

Linköpings universitet | Institutionen för datavetenskapExamensarbete på grundnivå, 15hp | Datateknik

2016 | LIU-IDA/LITH-EX-G--16/040--SE

Simuleringsmiljö för mobilanätverkSimulation environment for mobile networks

Jonatan Branting, Martin Byhlin, Niklas Erhard Olsson,August Fundin, Rasmus Johns, Martin Lundberg,Hanna Müller, Adam Nyberg, Niklas Pettersson

Handledare : Lena BuffoniExaminator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 årfrån publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstakakopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och förundervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva dettatillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. Föratt garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och admin-istrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman iden omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sättsamt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sam-manhang som är kränkande för upphovsmannenslitterära eller konstnärliga anseende elleregenart. För ytterligare information om Linköping University Electronic Press se förlagetshemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet – or its possible replacement– for a period of 25 years starting from the date of publication barring exceptional circum-stances. The online availability of the document implies permanent permission for anyone toread, to download, or to print out single copies for his/hers own use and to use it unchangedfor non-commercial research and educational purpose. Subsequent transfers of copyrightcannot revoke this permission. All other uses of the document are conditional upon the con-sent of the copyright owner. The publisher has taken technical and administrative measuresto assure authenticity, security and accessibility. According to intellectual property law theauthor has the right to be mentioned when his/her work is accessed as described above andto be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of documentintegrity, please refer to its www home page: http://www.ep.liu.se/.

c© Jonatan Branting, Martin Byhlin, Niklas Erhard Olsson,August Fundin, Rasmus Johns, Martin Lundberg,Hanna Müller, Adam Nyberg, Niklas Pettersson

SammanfattningDenna rapport innefattar det arbete som nio studenter från kursen TDDD96:Kandidatprojekt i programvaruutveckling vid Linköpings universitet ägnat sig åtunder vårterminen 2016. Projektet genomfördes med målsättningen att utvecklaett grafiskt användargränssnitt som skulle visualisera simuleringar av teledata-trafik i 2G-miljöer. Arbetet har varit en lärande process som omfattat gruppdy-namik, nya tekniska utmaningar och ett undersökande av hur utvecklingen i ettprojekt går från en beställning till en önskvärd leverans. Gruppen har arbetati korta intervaller med täta möten och prioriteringslistor med aktiviteter. Re-sultatet hittills är en prototyp med interaktiv simulering via uppkoppling motkundens servrar som bådar gott för fortsatt utveckling.

i

TillkännagivandenStort tack till de fina människorna på Ericsson! Rickard som låtit sig bli inter-vjuad kring beställarens behov och som lagt ner åtskilliga timmar på att följavårt arbete och komma med viktig input. Tack även till Björn som specificeratoch kompletterat samma input!

All denna möda hade varit lönlös om det inte hade varit för vår vägvisare ochbeskyddare, Lena Buffoni, som i egenskap av gruppens handledare hållit arbetetpå en stadig kurs under hela VT16, tack!

ii

Innehåll1 Inledning 1

1.1 Motivering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.5 Definitioner, akronymer och förkortningar . . . . . . . . . . . . . 2

2 Bakgrund 32.1 Projektgruppens bakgrund . . . . . . . . . . . . . . . . . . . . . . 4

3 Teori 53.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.1.1 Aktiviteter . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.2 Roller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.1.3 Artefakter . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.2 Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Semat Kernel ALPHA . . . . . . . . . . . . . . . . . . . . . . . . 63.4 GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.4.1 Nätverksarkitektur . . . . . . . . . . . . . . . . . . . . . . 73.4.2 GSM-simuleringar . . . . . . . . . . . . . . . . . . . . . . 8

3.5 Model View Controller (MVC) . . . . . . . . . . . . . . . . . . . 83.6 Python, Pyside och Qt . . . . . . . . . . . . . . . . . . . . . . . . 83.7 Tester och verktyg för testning . . . . . . . . . . . . . . . . . . . 10

4 Metod 114.1 Frågeställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2 Datainsamling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.3 Utvecklingsmetodik . . . . . . . . . . . . . . . . . . . . . . . . . . 134.4 Utvecklings- och organisatorisk miljö . . . . . . . . . . . . . . . . 144.5 Metod för att fånga erfarenheter . . . . . . . . . . . . . . . . . . 15

5 Resultat 165.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1.1 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . 165.1.2 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.1.3 Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.4 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.5 Connection . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.6 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2 Gemensamma erfarenheter och lärdomar . . . . . . . . . . . . . . 185.2.1 Python och Qt . . . . . . . . . . . . . . . . . . . . . . . . 185.2.2 Kundkontakt . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.3 SEMAT Kernel ALPHA:s . . . . . . . . . . . . . . . . . . 195.2.4 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.3 Översikt över individuella bidrag . . . . . . . . . . . . . . . . . . 20

iii

6 Diskussion 216.1 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

6.1.1 Systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.1.2 Kundkontakt . . . . . . . . . . . . . . . . . . . . . . . . . 226.1.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.1.4 SEMAT Kernel ALPHA’s . . . . . . . . . . . . . . . . . . 246.1.5 Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.2 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.3 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . 25

7 Slutsatser 277.1 Hur har Honeycomb implementerats så att ett värde skapats åt

kunden? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.2 Vilka tekniska erfarenheter har gruppen fått från projektet? . . . 277.3 Vilket stöd har gruppen fått genom att använda SEMAT Kernel

ALPHA:s? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277.4 Hur presterade gruppen med Scrum som arbetsmetod? . . . . . . 27

A Python för prototyputveckling 28

B Utvecklandet av ett grafiskt gränssnitt 33

C Kanbankung eller Scrummästare? 38

D Teamledarens roll i mjukvaruutveckling 46

E En analys av kodgranskningar 51

F En analys av tester 60

G Är LATEX ett lämpligt verktyg för projektgrupper 70

H Designmönstret MVC 81

I Val av utvecklingsmiljö vid mjukvaruutveckling 86

Referenser 93

Bilagor 98

J Utskrift från körning av enhets- och integrationstester medpy.test 98

K Svar från stora enkäten 100

iv

Figurer1 Mobila användare per nätverksteknologi. Grafen är genererad

med hjälp av Ericssons Traffic Exploration [3] . . . . . . . . . . 32 Översikt av GSM-nätverkets arkitektur . . . . . . . . . . . . . . . 73 Cellstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Hur PySide kopplar Python med Qt . . . . . . . . . . . . . . . . 95 Honeycomb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 MVC-arkitekturen . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Scrums process, [24] . . . . . . . . . . . . . . . . . . . . . . . . . 398 Grupp 8 burn-down diagram . . . . . . . . . . . . . . . . . . . . 419 Gruppens totala antal commits, iteration två . . . . . . . . . . . 4210 Gruppens totala antal commits, iteration tre . . . . . . . . . . . 4311 Gruppens granskningsprocess . . . . . . . . . . . . . . . . . . . . 5412 Har du genomfört en kodgranskning? . . . . . . . . . . . . . . . . 5713 Vad tittar du efter när du granskar kod? . . . . . . . . . . . . . . 5714 Hur snabbt granskar du kod? . . . . . . . . . . . . . . . . . . . . 5815 Har du granskat och godkänt kod som du känt dig osäker på? . . 5816 Har du sett till att eventuella buggar/problem i kod du godkänt

dokumenterats? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5817 Tror du att granskningsprocessen inom gruppen fungerat bättre

om själva kodgranskningarna skedde efter ett protokoll? . . . . . 5918 Hade du orkat följa en sådan checklista? . . . . . . . . . . . . . . 5919 Tror du att gruppens totala output blivit bättre om gruppen til-

satte en grupp som efter varje iteration granskade hela projekt-koden? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

20 Hur mycket kunskap hade du om tester innan projektet började? 6621 Hur många enhetstester har du skrivit under projektets gång? . . 6622 Hur många integrationstester har du skrivit under projektets gång? 6623 Hur många timmar har du totalt lagt ned på att skriva tester

(förutom acceptanstester) under projektets gång? . . . . . . . . . 6724 Med hur många minuters mellanrum i genomsnitt kör du test-

programmet py.test medan du programmerar? . . . . . . . . . . . 6725 Hur stor andel merge requests kontroller du med py.test innan du

godkänner dem? . . . . . . . . . . . . . . . . . . . . . . . . . . . 6726 Vad har varit det största problemet med att skriva tester för dig? 6827 Vad skulle fått dig att skriva fler tester? . . . . . . . . . . . . . . 6828 Vad kunde testledaren ha gjort för att motivera dig till att skriva

fler tester? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6929 Headerformatering från kvalitetsplan . . . . . . . . . . . . . . . . 7330 Headerformatering från Arkitekturdokument . . . . . . . . . . . 7331 Footerformatering från projektplanen . . . . . . . . . . . . . . . . 7332 Footerformatering från alla dokumentens titelsida . . . . . . . . . 7433 Footerformatering från Kvalitetsplanen . . . . . . . . . . . . . . . 7434 Gruppmedlemmarnas erfarenhet av LATEX . . . . . . . . . . . . . 7735 Fördelar med Google Documents enligt gruppens medlemmar . . 7736 Fördelar med ShareLaTeX enligt gruppens medlemmar . . . . . . 7837 Nackdelar med Google Documents enligt gruppens medlemmar . 7838 Nackdelar med ShareLaTeX enligt gruppens medlemmar . . . . . 7939 Gruppmedlemmars uppskattade kunskapsnivå . . . . . . . . . . . 79

v

40 Gruppmedlemmars uppskattning av hur mycket tid de spenderatoch använt ShareLaTeX . . . . . . . . . . . . . . . . . . . . . . . 80

41 Gruppmedlemmars verktygspreferenser för framtida projekt . . . 8042 MVC arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8243 Multitier arkitektur . . . . . . . . . . . . . . . . . . . . . . . . . 8344 Översikt av filer vid ett pågående projekt . . . . . . . . . . . . . 9145 Gruppens upplevelse av kund . . . . . . . . . . . . . . . . . . . . 10046 Gruppens syn på kundens påverkan på resultatet . . . . . . . . . 10047 Gruppens syn på effekten av kundens påverkan . . . . . . . . . . 10148 Gruppens syn på en, teoretisk, större involvering av kund . . . . 10149 Gruppens syn på kundens vision . . . . . . . . . . . . . . . . . . 10250 Gruppens syn på spenderad tid för efterforsnkingar . . . . . . . . 10251 Gruppens syn på relationen till kund . . . . . . . . . . . . . . . . 10252 Gruppens syn på skapat värde för kund . . . . . . . . . . . . . . 10353 Gruppens syn på MVCs begränsning . . . . . . . . . . . . . . . . 10354 Gruppens syn på effekten av MVCs begränsning . . . . . . . . . 10355 Gruppens syn på ett, teoretisk, förslag för att använda MVC . . 10456 Gruppens syn på upptagna kunskaper om GSM . . . . . . . . . . 10457 Gruppens syn på hur lämpligt PySide var att använda . . . . . . 10458 Gruppens förståelse av MVC-arkiteturen . . . . . . . . . . . . . . 10559 Gruppens syn på möjligheter för vidareutveckling av Honeycomb 10560 Gruppens syn på valet av att använda Python . . . . . . . . . . . 10561 Gruppens tekniska erfarenheter ifrån projektet . . . . . . . . . . 10662 Gruppens användning av SEMAT för vägledning . . . . . . . . . 10663 Gruppens överblick av projektet vid använding av SEMAT . . . 10764 Gruppens prioritering vid använding av SEMAT . . . . . . . . . 10765 Gruppens upplevda stöd från använding av SEMAT . . . . . . . 10766 Gruppens tankar om SEMAT . . . . . . . . . . . . . . . . . . . . 10867 Gruppens syn på högre använding av SEMAT . . . . . . . . . . . 10868 Gruppens syn på nyttan av att använda Stand-ups . . . . . . . . 10869 Gruppens läsning av gjorda Stand-ups . . . . . . . . . . . . . . . 10970 Gruppens syn på för- och nackdelar av att använda Stand-ups

online . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10971 Gruppens syn på anpassningsförmågan i de olika iterationerna . 11072 Gruppens syn på resultatet av att använda scrum . . . . . . . . . 11073 Gruppens syn på förutsättningarna i projektet . . . . . . . . . . 11074 Gruppens syn på den gemensamma standarden . . . . . . . . . . 11175 Gruppens syn på förståelsen i projektet . . . . . . . . . . . . . . 11176 Gruppens syn på prestationen då scrum användes . . . . . . . . . 111

Tabeller1 Definitioner, akronymer och förkortningar . . . . . . . . . . . . . 22 MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 843 N-tier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844 Utvärdering av utvecklingsmiljöer . . . . . . . . . . . . . . . . . . 90

vi

1 InledningUnder kursens gång har projektgruppen arbetat med att ta fram applikationenHoneycomb utefter en kunds önskemål och krav. Honeycomb är en produkt somhjälper kunden att visualisera simuleringar i GSM-nätverk.

1.1 MotiveringGruppen har tagit del av många lärorika erfarenheter som, genom att de do-kumenteras, även kan komma att vara lärorika för andra som ska genomföraliknande projekt.

1.2 SyfteSyftet med rapporten är att ge läsaren en överskådlig förståelse för systemet somimplementerats. Rapporten avser dessutom att dokumentera gruppens lärdomaroch erfarenheter från ett projektarbete, i en grupp på nio personer, som medhjälp av agila arbetsmetoder arbetat tillsammans för att skapa ett system somlöser ett verkligt problem för en riktig kund. Rapporten kommer ta upp gruppensmed- och motgångar tillsammans med några intressanta frågeställningar.

1.3 Frågeställning1. Hur har Honeycomb implementerats så att ett värde skapats åt kunden?

2. Vilka tekniska erfarenheter har gruppen fått från projektet?

3. Vilket stöd har gruppen fått genom att använda SEMAT Kernel ALP-HA:s?

4. Hur presterade gruppen med Scrum som arbetsmetod?

1.4 AvgränsningarRapporten kommer att behandla projektets utvecklingsfaser och slutproduktvilket gör att specifika saker, som t.ex. implementations- och systemdetaljer,inte kommer nämnas.

Målgruppen för rapporten är studenter, handledare och examinatorer vid kursenTDDD96: Kandidatprojekt i programvaruutveckling vid Linköpings universitet.

1

1.5 Definitioner, akronymer och förkortningarI tabell 1 så definieras de akronymer och förkortningar som används i rapporten.

Tabell 1: Definitioner, akronymer och förkortningar

Term DefinitionBSC Base Station ControllerBTS Base Tranciever StationETSI European Telecommunication Standards InstituteGSM Global System for Mobile communicationGUI Graphical User InterfaceIMEI International Mobile Equipment IdentityIMSI International Mobile Subscriber IdentityLTE Long Term EvolutionMS Mobile StationMSC Mobile service Swiching CenterMVC Model View ControllerSIM Subscriber Identity ModuleTSS Test and Simulation Solution

2

2 BakgrundEricsson är världsledande inom kommunikationsteknologi och ca 40% av värl-dens mobiltrafik går via nätverk som levereras av Ericsson. Med mer än enmiljard användare varje dag är Ericssons nätverk bland de mest använda [1].GSM är en standard som utvecklats av European Telecommunication StandardsInstitute (ETSI) för att beskriva protokoll för en andra generations (2G) digita-la mobilnät. Mer än 85% av världens befolkning täcks av GSM-nätverk. Totaltfinns det omkring 4 miljarder användare [2]. I figur 1 kan man avläsa Erics-sons utvärdering av trender och prognoser för mobila nätverk. GSM kommersannolikt att ha en vital roll även efter 2020 [3].

Figur 1: Mobila användare per nätverksteknologi. Grafen är genererad med hjälp avEricssons Traffic Exploration [3]

På Ericsson finns idag ett behov av att kunna genomföra tester på dessa mobilanätverk vilket med stor sannolikhet även är fallet i framtiden också. Tidigarehar Ericsson använt ett program där man grafiskt kunde utföra simuleringar påGSM-nätverk men efter ett antal ändringar i arbetsmetodiken upptäcktes detatt de verktyg man tidigare hade använt inte längre var brukbara. De utvecklaresom ägnar sig åt att testa GSM-nätverk är istället tvungna att genomföra tes-terna via diverse script. Detta leder till mindre flexibilitet när man ville ändrapå olika variabler och beteenden i simuleringen, exempelvis om man vill ge-nomföra samtal inom ett visst område. Detta gör att testerna tar lång tid attstarta och att de är komplicerade att genomföra. Ericsson behöver därför en nyskrivbordsapplikation där man enkelt kan testa olika specialfall.

3

2.1 Projektgruppens bakgrundProjektgruppen består av sju datateknologer och två mjukvaruteknologer. Allaläser kursen TDDD96:Kandidatprojekt i programvaruutveckling vid Linköpingsuniversitet. Det huvudsakliga kursmomentet är att utveckla en produkt åt enutomstående beställare, vilket är en ny upplevelse för alla i projektgruppen.Alla projektmedlemmar har erfarenhet av att arbeta i projekt som är av merinformell karaktär, fortfarande med en beställare men då i form av kursansvarig.

4

3 TeoriI detta avsnitt finns teori kring de teknologier, processer och modeller som ärrelevanta för att förstå innehållet i rapporten.

3.1 ScrumScrum är en agil, empirisk metodik som är en väldigt vanlig arbetsmetod inomde flesta projektarbetena. Den hjälper till att bryta ned komplexa problem tillmindre utförbara uppgifter och är förlåtande till plötsliga förändringar. Scrumtillåter projektet att vara anpassningsbart och kan snabbt ändra riktning efternya förutsättningar eller om problem uppstår under projektets gång. Det iterati-va tillvägagångssättet som kännetecknar Scrum försäkrar att gruppen levererarprodukter med hög kvalitet genom att efter varje iteration ha en produktver-sion att visa upp och ta emot kritik på, justera dessa ändringar enligt kundensönskemål för att efter nästa iteration släppa en ny förbättrad version. Scrumär applicerbart på i stort sett alla processer men används främst inom mjuk-varubranschen. Det är mycket viktigt för alla typer av empirisk processtyrningatt processen genomsyras av transparens, granskning och anpassning. För attuppnå detta måste alla i projektgruppen ha en gemensam standard på arbetetför att ha samma förståelse för det man ser. Vidare måste man granska scrumar-tefakter och processerna för att kunna upptäcka oönskade avvikningar. Dettagör att arbetet kan anpassas när det upptäcks att vissa avvikelser i arbetet nåttoacceptabla nivåer [4].

3.1.1 Aktiviteter

Det som gör Scrum lämpad för processer med föränderliga eller snabbt framväx-ande krav är dess iterativa natur. Man arbetar i omgångar som kallas sprintarsom varar i allt från en till fyra veckor. Som inledning i varje sprint bör scrumtea-met ha ett möte där man tillsammans bestämmer vilka aktiviteter som teamettror sig klara av i kommande sprint. Dessa aktiviteter utgör sedan sprintensproduktbacklog och under själva sprinten så tillkommer det inga saker i denna.Varje dag i en sprint inleds med ett så kallat dagligt scrummöte som idealt hållskring 15 minuter långt. Detta möte ska alla i scrumteamet närvara vid. Syftetmed det dagliga scrummötet är att informera varandra om vad man gjort för-gående dag, vad dagens agenda är samt att identifiera möjliga hinder som kanstoppa arbetet. I slutet av varje sprint hålls en utvärdering av sprinten.[5]

3.1.2 Roller

Scrumteamet består av tre huvudsakliga roller scrummästare, utvecklingsteametoch produktägaren.

ScrummästareScrummästarens roll är att se till att arbetet för alla i teamet går smidigt, det ären roll som tjänar de andra i teamet. En scrummästare coachar utvecklingstea-met till självorganisering och försöker underlätta arbetet genom att undanröjaeventuella hinder som uppstått för gruppmedlemmarna. Scrummästaren hjälperäven produktägaren att organisera och tolka backloggen och om det behövs ävenpåminna utvecklingsteamet om att skriva tydliga poster i backloggen.

5

UtvecklingsteametDet är utvecklingsteamet som gör själva arbetet och det är bara de som fårbidra till de inkrementella framstegen för produkten. Rekommenderad storlekär 3 till 9 personer.

ProduktägarenProduktägaren bär det yttersta ansvaret för backloggen även om det är möjligtatt denna person låter andra i teamet utföra uppgifterna att skriva och granskabackloggen.

3.1.3 Artefakter

Det finns ett antal artefakter i Scrum som syftar till att ge arbetet transpa-rens och underlättar för utvärdering och anpassning. Naturligtvis hör självaprodukten som teamet utvecklar den viktigaste artefakten men det finns ävenscrumspecifika artefakter.

ProduktbackloggDetta är ett dynamiskt dokument som växer fram allt eftersom förståelsen förprodukten ökar och eventuellt ändras. Här listas alla de egenskaper, funktioner,förbättringar och förändringar som finns för produkten. I början kommer pro-duktbackloggen bara att beskriva de krav som är bäst förstådda för att underprojektets gång utvecklas och förfinas. Till slut är produktbackloggen en kom-plett lista över krav på produkten. Utvecklingsteamet bör bara arbeta utifråndetta dokument och det är produktägaren som bär ansvaret för att produkt-backloggen sköts och prioriteras.

SprintbackloggInför varje sprint väljs ett antal poster ut från produktbackloggen som skallingå och slutföras under kommande iteration. Dessa poster sätts ihop till ensprintbacklogg och utgör en slags prognos för vad som kommer att finnas medi nästa inkrementering av produkten.

3.2 KanbanTill skillnad från Scrum och det iterationsdrivna arbetssättet med tydliga fe-atures som enligt målsättning ska vara klara i slutet av iterationerna så harKanban ett annat tillvägagångssätt till progressionen. Under rubrik C.3.3 finnsen mer utförlig utläggning om just Kanban.

3.3 Semat Kernel ALPHASEMAT, akronym för Software Engineering Method and Theory, grundades 2009och är således en relativt ny metod inom mjukvaruutveckling. Alpha State Cardsär ett hjälpmedel för att följa denna metod, nämligen att följa upp ett projektsstatus och planera nästa steg. Akronymen ALPHA står för Abstract-Level, Pro-gress, Health, Attribute. Dessa parametrar sägs, av grundarna till Alpha StateCards, vara de viktigaste att mäta för att bevaka och förbättra arbetsprocessen.Korten är indelade i tre områden: Customer, Solution och Endeavor [6].

6

3.4 GSMGSM är ett andra generations (2G) digitalt mobilnät utvecklat av EuropeanTelecommunication Standards Institute (ETSI). Det är en globalt accepteradstandard för digital mobilkommunikation. GSM la grunden för nyare nätverks-modeller och kom att leda till fjärde generationen (4G) mobilnät, LTE ochLTE-advanced [7].

3.4.1 Nätverksarkitektur

Ett GSM-nätverk består av ett antal enheter. De som berörs i detta projekt finnsillustrerade i figur 2 där man även kan avläsa hur dessa enheter interagerar medvarandra. Nätverket består av tre huvudkomponenter som i sin tur kan delasupp i ännu mindre delar. Det tre huvudkomponenterna är Mobile Station, BaseStation System och Network Subsystem [8].

Figur 2: Översikt av GSM-nätverkets arkitektur

Mobile Station (MS)Den minsta enheten i nätverket är Mobile Station (MS). MS utgörs av en mo-bilenhet och ett SIM-kort som gör att användaren ständigt har tillgång till detjänster som är betalda för oavsett vilken telefon som används. SIM-kortet äralltså ett redskap för att autentisera användaren och innehåller en IMSI-kod.Den mobila hårdvara som används kan identifieras med hjälp av IMEI vilket ärsom ett slags serienummer som bestäms av mobiltillverkarna [8].

Base Station System (BSS)BSS:er ansvarar för alla radio-relaterade funktioner och består av två kompo-nenter, Base Transciever Station (BTS) och Base Station Controller (BSC).BTS:er innehåller radiomottagare och ansvarar bland annat för att upprätthål-la gränssnittet mellan MS och BTS. En cell i figur 3 definieras av dessa BTS:er[8]. En BSC kontrollerar en eller flera BTS:ers resurser och är kopplingen mellanMS och MSC.

7

Network Subsystem (NSS)I NSS finns ett antal komponenter där huvudkomponenten är en så kalladMobileSwitching Centre (MSC). Det är MSC som kopplar samtal mellan olika enheteroch hanterar diverse funktionalitet som behövs för att hantera mobilenheter.Exempelvis registrering, autentisering och att uppdatera platser [8].

Figur 3: Cellstruktur

3.4.2 GSM-simuleringar

För att testa GSM-nätverket utförs simuleringar hos kunden med hjälp av Testand Simulation Solution (TSS).

Test and Simulation Solution (TSS)TSS:erna innehåller en hel testsimulering. Olika TSS:er är helt separata frånvarandra. En TSS innehåller allt som en simulering kan behöva, t.ex. BTS:er,MS:er och information om samtal.

3.5 Model View Controller (MVC)MVC är ett designmönster som kan används vid utvecklandet av grafiska appli-kationer. Under rubrik H.3.1 står mer teori om MVC.

3.6 Python, Pyside och QtPython, skapat under 1980-talet av Guido van Rossum, är ett högnivåprogram-meringsspråk som används i stor utsträckning av industrier, universitet och pri-

8

vatpersoner. Python är även ett multiplattform-språk, tillgängligt i ett flertalolika versioner, som kontinuerligt uppdateras och förfinas i linje med framtidenskrav på mjukvara [9].

PySide är ett paket vars syfte är att möjliggöra användandet av paket ochklasser från Qt-biblioteket i program skrivna med språket Python. Paketet ärav typen öppen källkod vilket lämpar sig väl för i princip alla typer av projekt.Den senaste versionen av PySide, version 1.2.4, stödjer ramverket Qt 4.8 fullt utoch släpptes den 14 Oktober, 2015. Se figur 4 för hur PySide används av Pythonsom en bindning mellan språket och paketen, samt klasserna, tillgängliga i Qt[10].

Figur 4: Hur PySide kopplar Python med Qt

Qt är ett ramverk för att skapa applikationer för bland annat Windows, OS Xoch Linux. Ramverket syftar till att utvidga språk, specifikt C++, med hjälp aven rad olika funktioner och bibliotek. Ramverket skapades av Trolltech, men ägsidag av Digia, och finns tillgängligt som både kommersiell och fri programvara[11].

Qt Designer är ett grafiskt program som används för att bygga GUI:s. I pro-grammet kan man dra och släppa olika komponenter och med hjälp av olikaplatshållare kan dessa komponenter smidigt placeras ut. Programmet genererarsedan en XML-fil som representerar GUI:t. Komponenterna som man kan väljabland är färdiga klasser och paket som finns i Qt-biblioteket [12].

9

3.7 Tester och verktyg för testningDe olika typer av tester som använts i projektet är:

• Enhetstester

• Integrationstester

• Systemtester

• Acceptanstester

• Regressionstester

• Användbarhetstester

De verktyg som använts för testning är:

• pytest

• pytest-cov

Under rubrik F.3.1 och rubrik F.3.2 finns det teori om de tester och testverktygsom använts i projektet.

10

4 MetodProjektarbetet utfördes i olika faser, med förstudie, utvecklingsfas och redovis-ningsfas. Utvecklingsfasen realiserades i iterationer: sprintar på 3-4 veckor sompåbörjades genom att mål för iterationen bestämdes och avslutades med endemonstration över arbetet som utförts under iterationen. Projektgruppen togalltså del av en agil arbetsmetod.

4.1 FrågeställningarFrågeställningarna som den här rapporten behandlar valdes av två skäl. Detförsta skälet var att vår examinator satte hårda riktlinjer på vilka frågor man vartvungen att ha med, vilket gav oss tre frågeställningar. Den sista frågeställningenkom från ett intresse av att undersöka hur väl Scrum fungerat för gruppen.

4.2 DatainsamlingFör att kunna besvara frågeställningarna tog gruppen fram en enkät som grup-pens alla medlemmar anonymt fick besvara. Varje enskild fråga i enkäten riktadesig mot en specifik del av frågeställningen och avsåg att utgöra underlag för justden frågan. Frågorna ställdes i slutet av iteration tre när produkten och pro-jektet i stort sett var slutfört. Frågorna grundar sig i gruppens erfarenheterkring kundrelationen, tekniker som använts för projektet och arbetsmetoden isin helhet. De frågor som ställdes var:

• Har du upplevt kunden som en individ eller ett företag?

• Gav kundens medverkan som helhet en positiv eller negativ effekt på Ho-neycomb?

• Tror du att resultatet hade förändrats om fler personer på kundens sidavar involverade, eller om kontaktpersonen på Ericsson fungerade mer somvårt analysmedium (ja/nej)? På vilket sätt hade det varit annorlunda?

• Tror du att vårt resultat hade förbättras om kunden själv haft en tydligarevision?

• Tycker du att gruppen lade en rimlig mängd tid på att göra efterforsk-ningar av kundens önskemål och behov?

• Hur upplevde du gruppens kundrelation?

• Tycker du att gruppens resultat skapat värde åt kunden? Varför/varförinte?

• Kände du dig någonsin begränsad av MVC-arkitekturen, när du skulleimplementera en funktion?

• Om ja, var det bra att begränsningarna fanns där, sett till resultatet?

• Föreställ dig att du åkte tillbaka i tiden till när arkitekturen lades ochingen annan föreslog MVC, utan alla pratade om ett annat designmönster.Hade du då tagit upp MVC för diskussion?

11

• Upplever du att du fått en klarare bild av vad GSM är och hur det fun-gerar?

• Upplever du att PySide lämpat sig bra för detta projekt?

• Hur pass bra förståelse anser du att du har av MVC-arkitekturen?

• Tror du att Ericsson enkelt kan vidareutveckla Honeycomb efter leverans?

• Vad tycker du om att Python valdes som språk i detta projekt?

• Prata fritt om dina tekniska erfarenheter från PUM-en!

• Hur ofta under projektets gång använde du SEMAT Kernel ALPHA:s föratt på något sätt vägleda dig i ett val?

• Har Semat ALPHAS gett dig en tydligare överblick av hur långt arbeteti projektet kommit?

• Har Semat ALPHAS hjälpt dig identifiera vilket arbete som borde priori-teras eller vad som borde adresseras i gruppen?

• Upplevde du att du eller gruppen fick stöd från Semat ALPHAS?

• Beskriv kortfattat dina tankar om Semat ALPHAS.

• Tror du att en högre grad av användning av Semat ALPHAS hade givitmer stöd till gruppen?

• Känner du att gruppen drog nytta av dagliga standup-möten?

• Läste du protokollen från de dagliga standup-mötena?

• Vilka för- och nackdelar såg du med att ha dagliga standup-mötena online?Vilka för- och nackdelar tror du gruppen erfarit om vi träffats och gjortdagliga standup-mötena tillsammans?

• Hur tycker du gruppens anpassningsförmåga förändrades i Scrum jämförtmed tidigare, och senare iterationer?

• Tycker du att arbetet som utfördes med Scrum som arbetsmetod gavhögkvalitativa resultat?

• Upplevde du att alla i gruppen arbetade efter samma förutsättningar?

• Upplevde du att alla i gruppen hade samma förståelse kring projektet?

• Jämfört med övriga iterationer i projektarbetet - hur anser du att gruppenpresterade med Scrum?

12

4.3 UtvecklingsmetodikFörstudien påbörjades med planering och förberedelser inför resten av projek-tet. Rollerna teamledare, arkitekt, utvecklingsledare, testledare, specialist, ana-lysansvarig, kvalitetssamordnare, dokumentansvarig och konfigurationsansvarigtillsattes där vardera gruppmedlem fick ett huvudansvar inom något av des-sa områden. Intervjuer hölls med intressenter för att ta reda på deras behov,projektplanen skrevs, arbetsmetoden diskuterades och arbetsmiljön bestämdes.Systemet som levererades till kunden utvecklades i Python1 med hjälp av ram-verket PySide2. Projektgruppen enades kring en målsättning för varje iterationoch definierade aktiviteter som behövde slutföras för att nå dit. Dessa aktivite-ter bröts ned i mindre aktioner, skrevs ned på kort och lades i en prioritetslistai arbetsverktyget Trello3 som lät aktivitetsflödet kontrolleras enligt Kanban-paradigmet [13]. Under iteration ett hölls två sittande möten varje vecka däraktiviteter följdes upp och problem och framsteg diskuterades tillsammans medannan viktig information. Utöver det var det eget arbete under veckan, vilketofta utfördes i mindre grupper. Iterationen avslutades med en demonstrationför kunden och handledaren som gav feedback på systemet vilket omformulera-des till nya aktioner att ta tag i. Arbetsflödet för en utvecklare återges enligtnedanstående algoritm vilket alltså krävde att GitLab4, Trello och valfri texte-ditor eller IDE användes.

1. Gruppmedlem ställer sig som ansvarig för en aktion i Trello och flyttartillhörande kort ifrån en ”att-göra-lista” till ”under-utveckling-listan”.

2. En ny branch skapas utifrån master på GitLab.

3. Ny kod implementeras så att aktionen uppfylls.

4. En merge-request för skapad branch läggs upp. Kortet i Trello flyttas tillen ”granskningslista”.

5. Gruppmedlemmen granskar en annan utvecklares merge-request och gerfeedback på denna. Om koden inte anses vara komplett flyttas kortet re-laterat till granskad branch tillbaka till ”under-utveckling”.

6. Om en egen merge-request blivit granskad och godkänd så ser man till attkoden finns tillgänglig på master genom att acceptera merge-requesten.Kortet flyttas till sist över till en lista med färdiga aktioner.

7. Gå till steg 1.

Under iteration två anammade gruppen den agila arbetsmetoden Scrum menmed små anpassningar. Den huvudsakliga anpassningen var de dagliga mötenasom hölls varje dag skriftligen i projektgruppens kommunikations-kanal, slack5.Annars följdes det som kännetecknar just utvecklingsmetodiken Scrum väl. Dekrav som skulle uppnås innan den andra iterationen var slut delades in i kom-pletta funktioner som skulle färdigställas. En tydlig brist med att hålla de korta

1https://www.python.org/about2https://wiki.qt.io/Category:LanguageBindings::PySide3https://trello.com/about4https://about.gitlab.com/5https://slack.com/is

13

dagliga mötena via skrift och enbart med scrummästaren själv var att man intepå ett enkelt sätt kunde diskutera de problem som uppstod för olika grupp-medlemmar. För att undvika det problemet ändrades de individuella skriftligamötena till att hållas i en gemensam kanal i verktyget slack så att alla kundeta del av informationen. I övrigt var övergången till Scrum väldigt friktionsfrieftersom arbetssättet liknade arbetsmetoden som gruppen jobbade efter underden första iterationen. Projektet var även, redan från början, tydligt indelat iiterationer med längder motsvarande längden för en iteration i Scrum. Mycketav förarbetet under den första iterationen handlade om att planera vad systemetskulle klara av och vilka krav som skulle uppnås under varje iteration.

Arbetsflödet för administrativt arbete var snarlikt arbetsflödet för en utvecklareoch beskrivs nedan.

1. Gruppmedlem ställer sig som ansvarig för ett avsnitt i ett dokument genomatt ta ett aktionskort i Trello och flyttar tillhörande kort ifrån en ”att-göra-lista” till ”under-utveckling-listan”.

2. Text som behövs för att uppfylla aktionen författas.

3. Kortet i trello flyttas till en ”granskningslista”. Ligger det en annan personskort i denna lista korrekturläses tillhörande text.

4. Feedback på läst text lämnas. Har texten tydliga brister läggs kortet tillba-ka i ”under-utveckling”. Om texten behöver en enkel justering görs dennajustering av korrekturläsaren.

5. När texten är justerad, eller om den redan från början ansågs färdig, läggskortet för tillhörande text i en lista med färdiga aktioner.

6. Gå till steg 1.

4.4 Utvecklings- och organisatorisk miljöDen fysiska miljö som projektmedlemmarna verkade i utgick inte ifrån en fastpunkt. I stort sett alla sittande möten skedde i olika grupprum på Linköpingsuniversitet men det förekom även möten utanför skolan eller på cafeterior. Närgruppen utvecklade programmet existerade all nödvändig utrustning digitalt.Detta innebar att om medlemmen hade en dator med internetuppkoppling såkunde personen utveckla ifrån hemmet, såväl som offentliga lokaler. Ofta be-drevs eget arbete hemifrån och då diskuterades den framtagna lösningen senaremed projektgruppen. Ett annat vanligt arbetssätt för gruppen var parprogram-mering.

Programmet utvecklades i Python tillsammans med Qt Designer. Eftersom Qtframförallt är avsett att användas till C++, men Honeycomb skrevs i Python,var paketet PySide nödvändigt för att få detta att fungera. Utvecklare i projektetvalde själva utvecklingsmiljö, men all kod testkördes med testverktyget pytest.

14

4.5 Metod för att fånga erfarenheterGruppen utvecklades enormt under projektet och tog del av flera sätt att tavara på och utvinna erfarenheter. Gruppdynamik, upplägg för kursen och mål igruppen gavs på initiala föreläsningar och diskuterades sedan på möten i grupp.Alla nya verktyg och arbetsmetoder som introducerades under projekttiden fickdefinierade uppgifter som gruppen gemensamt gick igenom på interna ”skolor”.När uppgiften var avklarad av samtliga ansågs nya erfarenheter utlärda. Var-je vecka träffades projektgruppen och handledaren vid ett sittande möte därfeedback på gruppens arbete lämnades, eller tips och värdefulla tankeställning-ar gavs. Ur dessa fick gruppen en mer gedigen översikt på projektet. Det höllsockså intervjuer och utfrågningar av beställare som gav djupare förståelse försystemet som skulle utvecklas samt de behov som gruppen behövde tillgodose.Utifrån detta skapades en kravspecifikation som gav ett bra underlag när måloch test specificerades. Under pågående utveckling skedde mycket korrekturläs-ning av andras kod, eftersom metoden krävde detta vid merge-requests. Dettavar mycket meriterande och gav god insikt i Python.

15

5 ResultatI detta kapitel sammanställs alla resultat som gruppen uppnått i projektarbetet.Figur 5 visar hur Honeycomb ser ut för användaren.

Figur 5: Honeycomb

5.1 SystembeskrivningSystemet är uppbyggt efter MVC-arkitekturen. I appendix H.3.1 finns mer in-formation angående MVC. Mot MVC-strukturen har ett system vid namn Con-nection, som använts för att ansluta sig till kundens servrar, knutits. Figur 6visar MVC-arkitekturen.

5.1.1 Controllers

Controllers har ett övergripande ansvar att binda ihop de andra komponenterna.Vårt system består av fyra olika controllers.

• MainController.py är den controller som initierar alla andra controllersoch den som startar programmet. Det är även MainController.py somkommunicerar med Connection.

• TSSController.py hanterar all data som ligger i systemet.

• GraphicsController.py är ansvarig för att veta hur data från TSSControl-ler.py ska ritas ut i programmet.

• PopupController.py används vid ritning av popupfönster.

5.1.2 Models

I systemet har models två syften. Models används för att definiera alla data-strukturer och i vissa fall även för att utgöra ett gränssnitt till sin struktur.Dessa gränssnitt finns i de fall där datastrukturen är komplex och är till för attgöra användningen av strukturen enklare.

16

Figur 6: MVC-arkitekturen

5.1.3 Actions

I filen actions.py finns alla användarinteraktioner med programmet definierade.Syftet med actions.py är att binda interaktioner med programmet till funktioneri controllers och på så sätt är actions.py som en brygga in i systemet frånanvändaren.

5.1.4 Views

Alla filer som används för att definiera hur gränssnittet ska se ut är skapademed hjälp av Qt Designer och är en variant av XML. För att använda filerna iprogrammet måste de kompileras till Python-filer.

5.1.5 Connection

Connection-delen av vårt program är uppdelad i följande moduler, som ansvararför olika delar.

• _commands.py hanterar olika kommandon som kan skickas till kundensservrar. Detta inkluderar olika “connect-funktioner” samt wrappers för attskicka egendefinierade kommandon till kundens servrar.

• _connection.py sköter själva kommunikationen med kundens servrar.Detta inkluderar funktioner för att starta nya kommunikationskanaler,att skicka kommandon i form av oformaterad text till kundens servrar ochatt vänta på svar i form av reguljära uttryck.

• _parser.py formaterar den data som returneras från _connection.py iform av Python ”dictionaries” som senare lätt kan användas utav resten

17

av programmet.

• helper.py är modulen som resten av programmet pratar med och sköterden asynkrona exekveringen av diverse kommandon.

Connection-delen är uppbyggd på detta sätt eftersom systemets kommunika-tion med kundens servrar är relativt invecklat. Programmet måste ansluta sigvia SSH6 och emulera en så kallad terminal, eller kommandotolk, för att kun-na kommunicera med kundens servrar. Detta beror på att kundens system äruppbyggt av flera nivåer, som alla startar sin egen ”sub-terminal”.

Helper.py ger också användaren av metoden möjligheten att skicka in en såkallad ”subfunktion” som kör på datan som returnerats. Detta används bådeför att placera datan på rätt ställe i programmet, och för att köra ett nyttkommando som beror på resultatet av det tidigare kommandot.

5.1.6 Tester

Under projektets gång har enhets-, regression-, system-, integrations- och accep-tanstester skrivits. Även ett användbarhetstest har utförts. Totalt finns det 61st. automatiska tester och 20 st. acceptanstester. Mer information om de testersom skrivits finns under rubrik F.5.1.

5.2 Gemensamma erfarenheter och lärdomarI den här delen av rapporten finns information om vad gruppen lärt sig ochutvecklats inom. Resultaten och statistiken kommer ifrån den tidigare nämndaenkäten som alla gruppmedlemmar svarade på efter iteration tre.

5.2.1 Python och Qt

Idag är alla i gruppen mer bevandrade i både Qt och Python. De som tidigarekände sig något osäkra på Python har blivit betydligt mer bekväma i skorna,medan de som redan var rutinerade istället utvecklats inom fält som kodstan-darder, Qt och inbyggda Python-bibliotek.

5.2.2 Kundkontakt

Ingen i gruppen hade någon erfarenhet sedan tidigare av att hantera kunder pådet sätt som vi fick erfara i detta projekt. Under förberedelsefasen som pågickunder de inledande fyra veckorna av projektet ansträngde projektgruppen sigmycket för att försöka ta reda på vad kunden önskade för produkt så snabbt sommöjligt. Det kände vi att vi lyckades ganska bra med. Det blev inte några storaändringar i kravspecifikationen under projektets nästkommande veckor. På sinhöjd placerades några krav i fel iteration samt att några ursprungliga use-caseändrades lite. Under återstående iteration två och tre sköttes kundkontakt viamail och ett antal möten.

Alla i gruppen har upplevt att kontakten vi har haft med kunden har varit per-sonlig, vilket är mycket positivt. Det har dock också lett till att gruppen upplevt

6https://sv.wikipedia.org/wiki/Secure_Shell

18

att vi arbetat med en individs vision av produkten snarare än ett företags vi-sion. Detta styrks av att åtta personer i gruppen upplever att vi hade kunnatleverera mer värde åt kunden om fler personer från kundens sida hade varitinvolverade i processen. Sju av gruppens nio medlemmar upplevde att kundenförmedlat en stark vision av vad de ville ha och att den produkt som är framta-gen är starkt influerad av vad kunden efterfrågat. Samtidigt tycker de också atten tydligare vision hos kunden kunde ha förbättrat slutprodukten. Sju personerupplevde också att kundens medverkan haft en positiv effekt på produkten. Trepersoner i gruppen tyckte att gruppens ansträngningar att efterforska kundensbehov och önskemål var bristfälliga och att gruppen borde ha lagt mer tid pådet. Fem personer i gruppen upplevde att kundkontakten, hur projektgruppenhanterade kunden och hur kunden hanterade projektgruppen, var bra.

5.2.3 SEMAT Kernel ALPHA:s

En kort översikt av gruppens datainsamling avslöjar att större delen av gruppenvarken följt någon teori kring The SEMAT Kernel eller använt sig framgångsriktav korten Alpha State Cards. I gruppen finns det enbart två personer som allsanvänt sig av korten, och det är bara ”sällan”. I övrigt har sex aldrig rört democh en vet inte vad det är. Av de två personerna som faktiskt tittat närmarepå SEMAT har båda upplevt att det funnits stöd att hämta. En upplevde attkorten gav vägledning kring vad som borde få mer fokus och en fick en tydligareöverblick av projektet. Det låga användandet speglar sig också i gruppens tankarkring SEMAT: bara en person tror att det hade gynnat gruppen att fördjupa sigmer eller att i högre grad använda korten. Två är osäkra på om en frekventareanvändning hade hjälpt gruppen medan resterande sex inte tror att det tillförtnågonting. Dessa resultat baseras alltjämt på en grupp av nio personer där fyrainte alls bemödat sig med att titta närmare på vad detta rör sig om, men ävenom urvalet skulle begränsats till kvarvarande fem har ingen tydlig nytta kunnatidentifieras. För att se datat i detalj, se bilaga bifogad längst bak i rapporten.

5.2.4 Scrum

Anammandet av Scrum medförde främst en tydlig struktur och ordning. Grup-pen hade alltjämt en klar överblick över vad som skulle göras och vad som hadeslutförts. Ett flertal i gruppen tyckte även att det var bra att enkelt kunna följaprogressionen av projektet genom att på ett överskådligt sätt se vad andra gjor-de och skulle göra därnäst och samtidigt få sina egna problem sedda. Featuresblev klara och höll hög kvalité, gruppmedlemmarna tog sig an en feature och sågtill att den blev klar. Majoriteten av gruppen tyckte att produktiviteten överlagvar bättre än under den första iterationen. Delar av gruppen upplevde dock attdet var svårt att ta egna initiativ eller att fixa andra mindre saker som intefanns med i backloggen. En feature kunde vara relativt stor och kunde egent-ligen ha brutits ned i fler mindre delar, detta medförde att om man fastnadepå en feature man tagit sig an fanns det risk för att känna sig väldigt impro-duktiv. Många upplevde också en förhöjd sammanhållning och gruppdynamikunder iteration två. Somliga tyckte att de dagliga mötena ibland kunde varajobbiga och förmodligen gjordes en snedvriden poänguppskattning av arbetetsom skulle utföras. Sammanfattningsvis har, i det stora hela, tillämpningen avScrum mestadels haft positiva effekter på projektet och gruppen.

19

5.3 Översikt över individuella bidragDe individuella bidragen, placerade sist i denna rapport, tar upp följande:

• Python för prototyputveckling undersöker vare sig Python lämpar sig somprogrammeringsspråk vid prototyputveckling av ett nytt program utaven ny, oerfaren grupp utvecklare. Undersökningen är skriven av gruppenskonfigurationsansvarig, Jonatan Branting.

• Utvecklandet av ett grafiskt gränssnitt undersöker verktygen som gruppenvalde att använda till utvecklandet av det grafiska gränssnittet. Undersök-ningen är skriven av gruppens specialist, Martin Byhlin.

• Kanbankung eller Scrummästare utreder, genom experiment under pro-jektets gång, huvudsakligen vilken arbetsmetod som är att föredra i kur-sens projektarbete för grupp 8. Efter analysering av resultat och vidarediskussion om vilka begränsningar experimentet innehar kommer förfat-taren fram till att Scrum är det självklara valet. Utredningen är skrivenav gruppens utvecklingsledare, Niklas Erhard Olsson.

• Teamledarens roll i mjukvaruutveckling undersöker hur teamledaren passatin och fungerat i projektarbetet. Undersökningen är skriven av gruppensteamledare, August Fundin.

• En analys av kodgranskningar undersöker hur gruppens kodgranskningargått till samt vad, vid en eventuell förändring, man skulle kunna gjort an-norlunda. Analysen är skriven av gruppens kvalitetssamordnare, RasmusJohns.

• En analys av tester beskriver och analyserar testningen i projektet, medmålet att avgöra vilken typ av tester som varit viktigast. Analysen ärskriven av gruppens testledare, Martin Lundberg.

• Är LATEX ett lämpligt verktyg för projektgrupper? I denna del undersökshur lämpliga de verktyg projektgruppen valt att använda för dokumen-tation är. Vilka fördelar och nackdelar finns med verktygen samt vilkalärdomar projektgruppen fått från detta projekt. Utredningen är skrivenav gruppens analysansvarig, Hanna Müller.

• Designmönstret MVC undersöker hur MVC fungerar, vilka problem somkan uppstå och några alternativ som finns. Undersökningen är skriven avgruppens arkitekt, Adam Nyberg.

• Val av utvecklingsmiljö vid mjukvaruutveckling är en utredning som syftartill att redovisa vilka olika faktorer, allt från krav till erfarenhet, som kanvägleda utvecklare då ett val av utvecklingsmiljö ska genomföras. Utred-ningen är skriven av gruppens dokumentansvarig, Niklas Pettersson.

20

6 DiskussionI detta avsnitt av rapporten tolkas och förklaras resultaten mer ingående. Re-sultatens vikt och konsekvenser lyfts upp samtidigt som gruppen försöker sesamband och verkan i resultaten. Även metoden lyfts för diskussion och slutli-gen diskuteras miljö-, etik- och samhällsaspekter av projektarbetet.

6.1 ResultatResultaten visar att med valda arbetsmetoder och implementationssätt har ettprogram skapats som kan vara av värde för kunden. Gruppmedlemmarna harerhållit varierande tekniska erfarenheter så som att arbeta med versionshante-ring, med ramverket PyQt och testdrivet. Med Scrum som arbetsmetod pekarresultaten mot både positiva och negativa upplevelser. Det passade inte allamed dagliga möten, men sammanhållningen i gruppen ökade. Resultaten vi-sar i övrigt inget tydligt samband mellan användandet av SEMAT och förhöjtkvalitativt arbete i gruppen.

6.1.1 Systemet

Det huvudsakliga målet och filosofin var att arkitekturen skulle vara enkel ochlätt att förstå. På så sätt var det tänkt att det skulle bli enkelt för nya utvecklareatt vidareutveckla och underhålla systemet. Valet att använda MVC motivera-des av att kundens möjlighet till vidareutveckling av programkoden skulle varaoptimal. Kunden krävde också lättläst och strukturerad kod i den bemärkelsenatt anställda på kundens företag skulle kunna sätta sig in i hur programmetfungerar utan större bekymmer. Gruppen diskuterade och kom fram till att ettvälkänt arkitekturmönster vore väldigt passande och, då tidigare erfarenheterfrån detta mönster fanns, tog därför beslutet att använda MVC.En stor fördel med att dela upp projektet med hjälp av ett MVC-mönster, föross utvecklare, har varit att flera gruppmedlemmar kunnat arbeta parallellt påolika features utan några krockar. Ett exempel på detta är att en del av gruppenunder en period bytte ut all grafik för telefonerna samtidigt som en annan delav gruppen utvecklade telefonmodellerna och sättet de sattes ut på. Med andraord arbetade en del av gruppen på View, medan övriga i gruppen jobbade medModels och Controllers.

En annan användning av MVC-mönstret som vi upptäckte var produktkodenssammanhållning. Med ett så starkt designmönster, som MVC utgör, är detsvårt som utvecklare att trampa snett och avvika från sättet gruppen utveck-lar produkten. Om man i vårt system vill lägga till ett nytt UI-element medny funktionalitet är det extremt svårt att inte göra det på rätt sätt: UI-filenimplementeras bara på ett ställe och kan bara ändras på ett ställe; controllersinitialiserar funktionaliteten av UI-element via en funktion som hämtar all sininformation från actions; funktionaliteten som actions knyter upp sig mot måsteligga i en controller. För att lyckas bryta mot det här mönstret krävs det attutvecklaren som försöker begå ett misstag återimplementerar en ny struktur avliknande komplexitet.

21

Stundtals har gruppen dock känt sig begränsad av MVC-mönstret. Gruppenstår splittrad gällande frågan om dessa begränsningar varit bra eller dåliga mensett till resultatet borde det betraktas som positivt.

Arkitekturen är enkel att bygga vidare på och eftersom systemet är modulärt ärdet också enkelt att ändra vissa egenskaper utan att systemet på en större skalapåverkas. Detta var viktigt för kunden, både eftersom det inte gick att förväntasig ett program som lever upp till alla av kundens förväntningar på tilldeladekurstimmar och eftersom programmet på detta sätt kan få längre livslängd. Detfinns dock en rätt brant inlärningskurva för en ny individ som vill sätta in sigi hela systemet. Utan vägledning kan utvecklare som inte redan har god vanaav Qt-ramverket lätt tappa bort sig i koden, även fast den är strukturerad.Anledningen till detta är att koden är väldigt omfattande och att implementeraen ny feature kräver förändringar i många olika filer, varav flera komponenterär renodlade Qt-filer.

6.1.2 Kundkontakt

Som tidigare presenterat i resultat så anser gruppen att kunden hade en starkvision om hur produkten skulle se ut och fungera. Detta gav gruppen en bragrund att stå på och gjorde så att arbetet enkelt kunde fortgå. Det bör ocksånoteras att när gruppen väl hade frågor kring problem som uppstått, eller kundeuppstå, så var kunden oftast snabb på att ge svar vilket även det gynnadegruppens arbetsprocess.

Då gruppen upplevde kunden som en individ och inte ett företag, som det fak-tiskt var, så skapade detta en miljö där gruppen återgående tvekade vid im-plementation när ett designbeslut var tvunget att tas. Hade gruppen upplevtkundrelationen som ett företags vision så hade kanske detta hindrats. Då grup-pen försökt tagit upp dessa problem genom inbokade möten, som tyvärr kundenvalde att ställa in i sista stund, så lämnades gruppen svarslösa inför vissa pro-blem. När väl ett möte, som tidigare blivit inställt, genomfördes så föreslogkunden ändringar och tog upp problem som, enligt gruppen, kom alldeles försent. Dessa ändringsförslag kunde grunda sig i att kunden hade mindre bra kollpå detaljer kring vad vi som grupp skulle kunnat ha gjort för att förenkla ettproblem. I slutet av iteration ett föreslog gruppen att kunden skulle förse grup-pen, eller en individ i gruppen, med en dator som var kopplad till kunden såatt funktionalitet och uppkoppling mot kunden kunde testas. Kunden gick medpå detta men det visade sig att det inte var så enkelt att göra verklighet avförslaget. Det slutade dock med att förslaget gick igenom men att det tog långtid. Det stora företaget vi jobbade mot medförde att det kunde ta lång tid föratt få igenom sådana förslag vilket gjorde att vi så sent som i iteration tre kundefå tillgång och testa produkten mot deras servrar.

Inför framtida kundkontakter har vi lärt oss att planera extraherandet av kravvilket sköttes via intervjuer med representant hos kunden. Prata med kundenmycket. Informera att vi kan behöva kontakta dem ofta, inte via mail utanvia möten. Ha kundkontrakt. Kom på tidigt vad det är vi behöver från demså att inte saker kommer i sista sekunden som med datorn som de försåg ossmed. Man måste trycka på om det är något man behöver som är avgörande för

22

resultatet. Om teamet behöver en dator eller någon annan form av access föratt kunna testa systemet så måste det verkligen trycka på om det inte händernågonting. Någon form av risk för kunden skulle förmodligen bidra till att bådaparter aktivt kämpar för att nå ett bra resultat och hjälpa teamet att slutföraprojektet med ett så gott resultat som möjligt. Det ligger då i båda partersintresse att röja undan hinder för teamet. Denna risk skulle kunna vara, somtidigare påpekat, ett kundkontrakt där krav ställs på kunden och inte enbartoss, men det skulle även kunna vara en ekonomisk risk i form av betalning.

6.1.3 Scrum

Så, var kommer den förhöjda känslan av struktur och ordning ifrån? Under denförsta iterationen var det mycket dokument som skulle skrivas, krav att samlain från kunden och arkitekturen för projektet skulle läggas. Iteration ett var enuppstart av projektet med många lösa trådar och kan ha medfört känslan avmindre produktivitet eftersom faktiskt arbete på produkten inte påbörjats än-nu. En starkt bidragande orsak till en tydligare struktur och ordning i iterationtvå kontra iteration ett kan ha varit att vi på ett tydligt sätt bestämde tillsam-mans vad programmet skulle kunna utföra efter iterationen och att vi samtidigtföljde upp progressionen under tiden. Vikten av att mäta framstegen och attåterkoppla för att se hur vi låg till och om vi skulle nå de satta målen innan ite-rationens slut har varit av största betydelse för att med säkerhet kunna levereranågonting av värde till kunden vid slutet av iterationen. Trots att poängen vigav varje feature självklart var en aning fel bidrog de till en övergripande bildöver hur vi låg till och om vi behövde jobba hårdare eller inte.

Att varje dag presentera progressionen, gruppens produktivitet och vad allagjort och kommer göra härnäst kan ha bildat bättre sammanhållning i grup-pen och en vi-känsla som tidigare inte funnits. Det var vi, tillsammans, somskapade detta och alla fick visa vad de bidragit med till projektet varje dag.Att varje dag presentera för varandra vad man gjort under dagen och vad manska ta sig an nästa dag gav många av gruppmedlemmarna en positiv press somledde till att mycket arbete blev gjort. Det är en form av åtagande, ett sortslöfte till gruppen som definitivt gynnat det individuella ansvarstagandet för he-la projektet. En annan bidragande faktor kan också givetvis varit att gruppentog något steg på gruppdynamiksstegen. Gruppmedlemmarna blev under itera-tion två tryggare med varandra och lyckades kanske hitta sina roller i gänget.Inlärningenströskeln av PyQt hade de flesta kommit över och arkitekturen varlagd när iteration två påbörjades. Med grunden lagd för projektet och med in-satta gruppmedlemmar utrustade med grundläggande kunskaper om hur mananvänder PyQt med Python, kunde gruppen med enkelhet modifiera och utökaett redan fungerande GUI från första iterationen. Detta bidrog med stor san-nolikhet till en ökad känsla av produktivitet, en känsla av att det mesta flötpå.

I och med att vi körde våra dagliga scrummöten på nätet, via webbverktygetslack, kunde vi inte tillsammans diskutera igenom eventuella problem som ha-de uppstått för projektmedlemmarna. Vi tappade således tillfället att diskuteraigenom problemen i gruppen och få ett direkt utbyte av kunskap mellan varand-ra. Att dela upp stora features i mycket mindre delar eller att teamet arbetat

23

tillsammans på en hel feature tills den färdigställts hade möjligen gynnat pro-duktiviteten en aning.

6.1.4 SEMAT Kernel ALPHA’s

I resultatet går det utläsa att intresset för SEMAT har varit lågt. Många såginte nyttan i att använda sig av det och det fanns en känsla av att det var på-tvingat, vilket begränsade motivationen att titta närmare på vad SEMAT var.Uppenbarligen så gav dock inte många i gruppen Alpha State-korten en ärligchans. Bara två gjorde ett försök till att hitta ett användningsområde, vilketbåda också gjorde. Sett till detta har alltså SEMAT inte påverkat gruppen sär-skilt mycket, varken positivt eller negativt. Tre bekände att de skulle vilja hagett detta större utrymme i gruppen, men tog inte initiativ till detta. Hade ettliknande arbete utförts hade det antagligen inte funnits något incitament förgruppen att lyfta SEMAT ännu en gång, även om det finns aspekter i resultatetsom tyder på att efterforskningarna av SEMAT varit bristfälliga. Detta berorpå att en övervägande del av gruppen ansåg att gruppens dokumentation, kom-munikation och arbetsmetodik redan var mer än tillräcklig då det täcker alltfrån ALPHA:

• Dagliga scrummöten och tät kommunikation har täckt Abstract-Level.

• Milstolpar och Scrum/Kanban board har täckt Progress.

• Kommunikationen i gruppen har täckt Health.

• Kod- och dokumentgranskningar och möten har täckt Attribute.

Påståendet att gruppens kommunikation, utan SEMAT-guidning, i sig är till-räcklig för att identifiera ALPHA kan anses vara arrogant. Däremot har om-fattningen på projektet inte varit så pass stor att det upplevts att ytterligareparametrar behövts vägas in.

6.1.5 Tester

Vid starten av projektet lades nästan ingen tanke på tester vilket innebar attkoden som skrevs inte skrevs för att kunna testas. Det som hände var att våramodels blev smala och våra controllers blev feta. Det gjorde att det var väldigtsvårt att skriva tester då vi äntligen började med det i iteration två, vilket ärett välkänt problem med feta controllers [14].

En bra fördelning av enhets-, integrations- och systemtester ska likna en pyramidmed cirka 70 % enhetstester, 20 % integrationstester och 10 % systemtester [15].Eftersom våra controllers varit mycket feta har detta varit svårt att uppnå dåcontrollers inte bör enhetstestas så lite som möjligt om ens alls [16]. Iställetär det models som ska enhetstestas men de har varit så smala att det knapptfunnits något att testa.

De viktigaste lärdomarna från det här projektet för framtiden är att verkligense till att lägga fokus på testning från början på ett nytt projekt. Ett exempel äratt från början skriva koden med tanken att funktionerna ska enhetstestas. Då

24

kommer kodstrukuren att bli bättre vilket kommer göra det enklare att fortsättaskriva tester under hela projektet.

Även då mer kunde önskas av testerna så skapar de värde för kunden genom attde:

• Genom acceptanstesterna visar vad som fungerar och inte fungerar i pro-grammet utifrån kravspecifikationen.

• Genom systemtesterna visar att krav från kravspecifikationen är uppfyllda.

• Ökar chansen att de delar av programmet som är testade fungerar som deska.

• Om kunden vill fortsätta utvecklingen av programmet kan användas förregressionstestning, alltså för att säkerställa att allt som fungerade tidigarefortfarande fungerar.

6.2 MetodEftersom att vi valde att analysera vår erfarenhetsfångst via en anonym en-kät uppstod det inte några särskilt omfattande diskussioner innan vi skrev vårrapport. Metoden vi valde att använda var förmodligen relativt obeprövad ochannorlunda gentemot hur grupper traditionellt sett pratar ihop sig innan deproducerar sin rapport, men vi tyckte att det var en bra metod; en anonym en-kät tog det bästa från två sidor och förenade dem. Från den traditionella sidantog vi diskussionerna, eftersom att vi tillsammans valde enkätfrågor och såledesockså vilka ämnen som var viktiga för gruppen. Vi förenade det med fördelarnamed ett anonymt och skriftligt system: alla får en chans att komma till tals närdet är anonymt och folk tenderar att förmedla mer utförlig information när detär skriftligt.

Det är möjligt att vi fått en mer sammanhängande rapport om vi diskuteratoss fram till vartenda textstycke, istället för ovanstående metod. Det hade dockvarit svårt under sådana diskussioner att låta alla komma till tals på sammasätt som vår omfattande enkät gjorde.

6.3 Arbetet i ett vidare sammanhangEn av våra huvudtankar bakom projektet, för att kunna skapa värde åt kunden,var att utveckla vår programvara med syftet att ersätta den som tidigare an-vänts. Genom programvaran som vi utvecklat hoppades vi på att förbättra derasarbetsprocess när det kommer till testning av GSM-nätverk. Om programvaranblir till tillräckligt stor hjälp, så medföljer att arbetsförhållandena för kundenäven kan förbättras.

Att kunna simulera GSM-nätverk för att göra tester medför ekonomiska bespa-ringar eftersom det behövs en stor mängd hårdvara för att efterlikna verklighe-ten i en testmiljö. Om testen görs i implementerad hårdvara, i det existerandeGSM-nätet, skapas problemet att testare behöver resa runt mycket och det kandessutom medföra störningar på nätet mot slutanvändare. Alltså är inte värdet

25

bara rent ekonomiskt men det besparar även miljön, eftersom hårdvara inte be-höver produceras och anställda kan jobba ifrån kontoret utan bilresor. Dessutomslipper slutanvändaren av GSM störas av utförda tester. Med den nya program-varan så kan testningen av GSM effektiviseras. Då den globala användningenav GSM är stor så finns det många användare som kommer kunna bli positivtpåverkade av detta.

26

7 SlutsatserI den här sektionen presenteras rapportens slutsatser.

7.1 Hur har Honeycomb implementerats så att ett värdeskapats åt kunden?

Vi tror att prototypen som vi lämnat över till kunden kommer att fungera somett komplement till deras nuvarande simuleringsmiljö. Det kan därför hävdasatt värde har skapats för kunden. Då vi även stött på en del problem, både tek-niska och arbetsrelaterade, så kan kunden ta lärdom av det till framtida projektliknande detta. I ett vidare perspektiv, som tidigare beskrivet under diskussion,så kan förhoppnings Honeycomb hjälpa kundens anställda vid körningar av testför deras simuleringsmiljöer.

7.2 Vilka tekniska erfarenheter har gruppen fått från pro-jektet?

Gruppen har blivit mer kunnig inom Python. Hela gruppen har dessutom lärtsig, från grunden, att utveckla grafiska användargränssnitt och Qt-ramverket.Flera gruppmedlemmar har också blivit mer bekanta med designmönster, tillexempel MVC. Med tanke på att versionshanteringsprogrammet Git har använtsflitigt under utvecklingen så har gruppmedlemmarna även fått kunskaper kringdetta. I avseende till hur kunnande gruppen var under första iterationen, jämförtmed under den sista iterationen, så är det en markant skillnad.

7.3 Vilket stöd har gruppen fått genom att använda SE-MAT Kernel ALPHA:s?

Gruppen har inte fått något märkbart stöd från SEMAT Kernal ALPHA. Detär dock möjligt att det finns stöd att finna hos systemet, men det är inget somgruppen gjort en ansträngning för att finna.

7.4 Hur presterade gruppen med Scrum som arbetsme-tod?

I och med att hela kursen varit uppbyggd kring iterationer kan vi främst draslutsatser om den struktur och ordning som Scrums artefakter bidrog med un-der iteration två. Vi kan fastställa att gruppen presterat mycket bra med hjälpav ramverket och dess komponenter. I jämförelse med iteration ett blev det enmärkbar skillnad i vad vi lyckades producera tillsammans trots att andra variab-ler också kan ha bidragit till detta, som exempelvis inlärningskurvan av PySide.Majoriteten av gruppen har samma känsla: många av Scrums artefakter bidrogstarkt till en betryggande ordning och säkerhet i att vi skulle kunna levereranågonting innan iterationens slut. Mycket tack vare att vi spårade progressionenunder tiden.

27

A Python för prototyputvecklingEn utredning skriven av Jonatan Branting, konfigurationsansvarig i Grupp 8 ikursen TDDD96, vid Linköpings universitet.

A.1 InledningValet av programmeringsspråk är en av de viktigaste beslut som kan tas i börjanav ett projekt. Fel programmeringsspråk kan leda till buggar, förseningar ochgenerellt sämre kodkvalitet. Det finns tyvärr inte heller något programmerings-språk som passar i alla lägen. Därför är det viktigt att kunna identifiera vilketspråk som skulle passa bäst för det givna projektet. Att utveckla en prototyp avett program medför ytterligare krav på språket; det måste vara lätt och snabbtatt testa nya idéer och koncept. Utöver det måste språket ha en relativt låginträdeströskel, så teamet kan komma igång med utveckling på kortast möjligatid.

A.1.1 Syfte

Syftet är att undersöka vare sig Python lämpar sig som programmeringsspråkvid prototyputveckling av ett nytt program utav en ny, oerfaren grupp utveck-lare.

A.1.2 Frågeställning

Frågeställningen som utredningen avser att behandla är följande:

• Var Python rätt val som programmeringsspråk för vårt kandidatsprojekt?

A.2 BakgrundNär vi valde programmeringsspråk för projektet enades gruppen bakom pro-grammeringsspråket Python, med motiveringen att alla hade tidigare använtspråket, och att det "kändessom ett bra språk för vårt ändamål; att utvecklaen prototyp av en front-end för kundens simulatormiljö för 2g-nätverk på enrelativt kort tid (Tre månader).

A.3 TeoriOlika programmeringsspråk är designade för olika ändamål. Utöver det så harolika programmeringsspråk olika höga s.k. inträdeströsklar, d.v.s. hur svårt ellerhur mycket kompetens som krävs för att ett programmeringsspråk ska varaeffektivt att använda. Denna tröskel vill vi hålla så låg som möjligt, för att gemöjligheten för hela gruppen att bidra så enkelt som möjligt.

A.4 MetodFör att ta reda på ifall Python lämpar sig som programmeringsspråk vid Pro-totyputveckling har nedan följande kriterier identifierats. Jag kommer att tittapå valet av språk och dessa kriterier ifrån perspektivet av ett oerfaret team.:

28

1. Ej verbost. Då vi har begränsad tid vill vi kunna fokusera på att skrivakod som faktiskt gör någonting. Att skriva rad efter rad av boilerplate-kodär inte produktivt och tar viktig tid och koncentration ifrån den faktiskauppgiften.

2. Tillgängliga bibliotek för att underlätta lösningen av problem som kommeratt bearbetas. Då vårt program bygger på ett par mer komplexa system(UI- och SSH-ramverk, m.fl.), vill vi gärna utnyttja kod som redan ärskriven. Att återuppfinna hjulet är ej att eftertrakta.

3. Kraftfullt standardbibliotek. Om stöd för funktioner följer med standard-biblioteket kan vi räkna med bättre stöd än från tredjepartsbibliotek, ochsparar oss viktig tid från att leta reda på bibliotek.

4. Lätt att skriva och förstå kod. Då vi snabbt vill komma igång och vårgrupp är relativt oerfaren (Gentemot den genomsnittlige programmera-ren), måste barriären för att bidra till projektet vara så låg som möjligt.Alltså vill vi att det ska vara lätt att skriva kod, samt förstå kod andrahar skrivit. Att lära utav varandra är också väldigt viktigt, vilket tydligoch klar syntax underlättar med.

5. Lätt att sätta upp en utvecklingsmiljö för språket. Då vi har en tämligenstrikt tidsbegränsning måste det gå snabbt att komma igång. Att få igångutvecklingsmiljöerna är då väldigt viktig då allt annat hänger på att dettafungerar.

6. Det måste vara lätt att testa nya ändringar. Då vi kommer att itereramycket är det viktigt att båda kunna testa hur nya ändringar kommer attpåverka resten av programmet, samt att kunna hitta buggar och annatsom lätt kan introduceras när en grupp oerfarna programmera slår sigsamman.

Denna lista är ett resultat av min egen erfarenhet, samt [17], där Patrick Kiefer,Uwe Schmitt och Julia A. Vorholt skriver att t. ex C++ ej är optimalt då ”Alt-hough such frameworks [written in e.g. C++] have a rapid application run time,the testing of new workflows and concepts is cumbersome because programmingrequirements are high, and edit-compile cycles are slow”.

Vi visste att vi från början ville komma igång så snabbt som möjligt, och attprestanda inte skulle vara något problem. Vi ville kunna börja programmera såsnabbt som möjligt, då tiden var väldigt begränsad. Att kunna testa program-met samt tillhörande ändringar lätt var också någonting vi dömde som väldigtviktigt. Om detta tar för lång tid är det svårt att hitta och fixa buggar, samtgör det svårare att testa nya idéer, någonting som förstås är väldigt viktigt inomprototyputveckling.

A.5 ResultatFör att komma fram till följande resultat har jag analyserat både mina egnaerfarenheter och tankar, samt flera olika artiklar som tar upp liknande fråge-ställningar.

29

1. Är Python verbost? I vår erfarenhet, nej. Dynamisk typning, kombineratmed list-comprehensions", decoratorsöch andra syntastiska godbitar göratt Python håller sig väldigt "kortskrivet".

def run_in_thread(func):"""Runs the decorated function in a separate thread."""def wrapper(*a, **kw):

t = Thread(target=func, args=a, kwargs=kw)t.start()return t

return wrapper

class Connection():def __init__(self, hostname, username, password):

self.ssh = paramiko.SSHClient()self.ssh.connect(hostname, 22, username, password)

@run_in_threaddef exec_command(self, command, output):

output.append(self.ssh.exec_command(command))

if __name__ == ’__main__’:connection = Connection(hostname, username, password)output = [] # Will contain the results of the executed command.connection.exec_command("<insert command here>", output)

För att skriva en modul för att koppla upp sig via SSH till given server ochexekvera kommandon asynkront är ovanstående kod det ända som behövs.Till skillnad från många andra imperativa språk kan man uttrycka sigväldigt kort och samtidigt åstadkomma väldigt mycket. Detta är dessutomen väldigt utökbar bas, och liknande kod används för back-end":en i vårtprojekt.

Detta stöds också av Jon McLoone i en undersökning av antalet raderkod som krävs för olika uppgifter [18], där Python hamnar näst först ieffektivitet i klassen imperativa programmeringsspråk, och kräver nästanhälften så mycket kod för ”en stor uppgift” som exempelvis C++. Härser vi dock också att funktionella språk är mycket mindre verbosa än allaimperativa språk, och kan i vissa fall vara 8-9x mindre verbosa.

2. Finns bibliotek tillgängliga för att underlätta lösningen av problem somkommer att bearbetas? I vår erfarenhet, ja. Under vår förstudie stötte vipå mängder av UI-, SSH-, och grafikrenderingsbibliotek, dock med olikagrad av stöd. Detta är föga förvånande då Python är ett oerhört populärtprogrammeringsspråk.

3. Är standardbiblioteket kraftfullt? I vår erfarenhet, ja. Det märktes väldigttydligt när stränghantering kom in i bilden då vi var tvungna att bearbetatext vi hämtade hem från Ericssons servrar. Alla funktioner man kan tän-kas behöva då man ska hantera en generell textsträng finns tillgängliga.Detta var otroligt smidigt och gav oss möjligheten att lägga viktig tid på

30

andra saker. Utöver det var det dessutom mycket lättare att komma framtill hur vi skulle hantera en viss output på bästa sätt.

def print_func(func):"""Prints the decorated function with supplied arguments."""def wrapper(*args, **kwargs):

print("Function:", func)print("Args:", args, kwargs)return func(*args, **kwargs)

return wrapper

@print_funcdef keep_above_number(list, number):

"""Example of (very) simple list comprehensions that returns a listof all elements in ’list’ that are greater than ’number’."""

return [x for x in list if x > number]

if __name__ == ’__main__’:list = [4, 7, 2, 5, 1, 6]number = 4print("Output:", keep_above_number(list, number))

# Returns the output:Function: <function keep_above_number at 0x00000000023BBD90>Args: ([4, 7, 2, 5, 1, 6], 4) {}Output: [7, 5, 6]

Ovanstående kodsnutt visar på s.k.k list comprehensions och decorators.

4. Är det lätt att sätta upp en utvecklingsmiljö för språket? Nej, inte i vårerfarenhet. Nedan följer en lista av problem vi stötte på.

(a) Mängder av olika lösningar för s.k. virtual environments, olika versio-ner av Python som är kopplade till olika versioner av bibliotek skaparförvirring och osäkerhet. Detta är dock någonting som blir mindre avett problem ju mer erfaret teamet bakom projektet är.

(b) Det dök det upp mängder av fel under installationen av olika biblio-tek. Detta berodde i de flesta fall på nedanstående punkt.

(c) Windows kräver en väldigt precis version av Microsoft Visual C++Compiler, som måste kopplad till den versionen Python var kompile-rad på. Problem uppstår också då vi ska kompilera paket åt Pythonför OS X, då xcode måste vara installerat. Detta är dock ganskasmärtfritt då vilken version det är inte alls är lika strikt som i Win-dows.

(d) För att få PySide samt Paramiko att installeras på Windows be-hövde vi jaga rätt på binärfiler för de system vi ville installera enutvecklingsmiljö på. Dessa var ej distribuerade officiellt, vilket ska-par problem då vi ej vet vem som har distribuerat dessa binärfiler.Kan vi verkligen lite på att dessa binärfiler är rena från exempelvisvirus, bakdörrar eller annan skadlig kod?

31

5. Är det lätt att testa nya ändringar? I vår erfarenhet, ja. Språket behöverej att kompileras, så det går väldigt lätt att bara köra igång programmetefter en snabb ändring. Utöver det finns det mängder av lösningar förautomatiserade testning någonting vi inte använde oss av fullt ut, mennär projekt växer är detta någonting som skall ses som väldigt attraktivt.

De ovanstående punkterna förstärks av Diane Garey och Steve Lang som skri-ver att, ”Given its [Python] minimalist development philosophy, clear syntax,flexible programming approaches and large standard library, Python provides ahigh productivity development language for any domain expert, including ex-perts in HPC. It allows for fast prototyping, much like MATLAB and similartools, making it useful for research projects and ad hoc development. As an opensource language, though, Python allows users to avoid the cost of purchasinga commercial tool and eliminates the need to learn a proprietary prototypinglanguage.” [19].

A.6 DiskussionPython lyckas att kryssa i många av de rutor som är nödvändiga för att pro-grammeringsspråket ska vara ett bra val för oss. Vi stötte dock på flera problemdå utvecklingsmiljön skulle sättas upp för olika platformar. Detta kan sätta käp-par i hjulen tidigt för nya, oerfarna grupper, men kan även medföra problemnär det blir tid att distribuera programmet.

I det stora hela lämpar sig dig Python riktigt bra för prototyputveckling. Kod gårsnabbt att skriva, är lätt att testa och det finns mängder av verktyg och biblioteksom ska underlätta för utvecklingen av program. Värt att tänka på är att stödetför Windows ej är optimalt; att sätta upp en fungerande utvecklingsmiljö kandra ut på tiden.

I vårt fall tjänade Python oss väl. Under utvecklingen av vårt program var vitvungna att hantera strängar och mönster på väldigt många olika sätt då vikommunicerade med Ericssons servrar. Då Pythons standardbibliotek i dettafallet är väldigt kraftfullt kunde vi fokusera på själva algoritmerna och sträng-hanteringen istället för att behöva återuppfinna hjulet och skriva stränghante-ringsfunktionerna själva. Detta lät oss få igång en fungerande prototyp relativtsnabbt, vilket i sin tur lät oss börja iterera tidigt.

A.7 SlutsatserAv min egen erfarenhet, samt resultaten, att döma, ser vi tydligt att svaret påfrågeställningen är ja, Python var rätt språk för vårt projekt. Python uppfyllernästan alla kriterier, och passar således väldigt bra för utveckling av prototyper.Dock kan det vara en utmaning att få igång utvecklingsmiljöerna, vilket innebäratt en bra konfigurationsansvarig är ett måste.

32

B Utvecklandet av ett grafiskt gränssnittEn utredning skriven av Martin Byhlin, specialist i Grupp 8 i kursen TDDD96,vid Linköpings universitet.

B.1 InledningI den här utredningen undersöks verktygen som användes till att konstrueraGUI under projektet. Flera faktorer tas hänsyn till, bland annat inlärningstidoch kodgenerering. Verktygen som användes under projektet och som undersöksär Qt Designer och PySide.

B.1.1 Syfte

Syftet med den här utredningen är att undersöka hur väl gruppens val av verktygtill utvecklandet av GUI fungerade, och hur väl gruppen lyckades använda demtill att uppnå det de ville.

B.1.2 Frågeställning

Frågeställningen som utredningen avser att behandla är följande:

• Hur väl fungerade vårt val av GUI-byggande verktyg?

• Hur väl lyckades gruppen uppfylla de visioner som både gruppmedlemmaroch kunden hade om gränssnittet?

B.2 BakgrundTill det här projektet valde vi att använda oss av verktyg som skulle underlättautvecklandet. Tanken var den att om vi gjorde ett bra val av verktyg så skulleprogrammet kunna bli väl strukturerad och se modernt ut. Ett mål var även attgruppen inte skulle behöva lägga mycket tid på de grafiska delarna, och fokusistället kunde primärt läggas på att utveckla bakgrundsfunktionalitet.

Gruppen valde att skriva i programmeringsspråket Python tillsammans medramverket Qt4, bindningspaketet PySide och GUI-byggaren Qt Designer. Dessavar besluten som vi tänkte passade in bäst för det här projektet, och det kanvara intressant att se just hur bra det fungerade i praktiken, och om det är värtatt faktiskt använda dem.

B.3 TeoriQt är ett ramverk som används till att implementera GUI. I projektet användesversionen Qt4, som hade en licens som gjorde att vi kunde använda det, somQt5 ej hade.

I den här rapporten tas Qt Designer upp, vilket är ett GUI-byggande programsom innehåller hjälpmedel för assistera användaren på olika vis [12]. Exempelpå dessa hjälpmedel är möjligheten att placera objekt i GUI genom drag medmusen, och att kunna se och ändra objekts egenskaper i en lista. Det GUI somman bygger i Qt Designer lagras i en XML-fil.

33

Vid sidan om Qt Designer finns bindningspaketet PySide [11, 10]. PySide använ-des för att koppla ihop Python med Qt, vilket tillåter användaren att användadelar av Qt, som klasser och paket, i Python-program. I PySide finns det även ettskript som kan skriva om XML-filen från Qt Designer till en körbar Python-fil.

Resultat från ett användbarhetstest tas upp för att analysera kommentarer frånen framtida användare. I ett användbarhetstest testas ett program genom att enanvändare får uppgifter som den ska lösa [20]. Användaren ombeds tänka högtoch förklara hur den tänker när den ska utföra de givna uppgifterna. Kommen-tarer och åsikter insamlas utav personen som håller i testet.

B.4 MetodDen här utredningen utfördes främst genom insamling och analys av data, varavett flertal olika data kom i fokus.

En form av data som var av intresse var hur väl verktygen fungerat för grupp-medlemmarna. För att ta reda på detta fick gruppmedlemmar besvara frågori en enkät om hur verktygen har fungerat för dem, som i deras inlärningstid,svårigheter som uppstått, och vad de tycker kunde gjorts annorlunda. Genomdetta kunde åsikter bland gruppen enkelt samlas in och sammanställas.

För att mäta den ökade effektiviteten vid användningen av verktygen utfördestester för detta. I dessa testerna jämfördes tiden som krävdes för att arbeta iQt Designer med rader kod som genererades, både direkt från Qt Designer, ochfrån PySide-skriptet.

För att få åsikter från en mer betydande källa så granskades även kommentarerinsamlade från ett tidigare utfört användbarhetstest [21]. Detta test utfördesunder iteration 2 av projektet och hade endast en deltagare, detta på grundav att fler deltagare ej ville delta. Den enstaka deltagaren var en potentiellframtida användare av programmet, vilket gjorde hans åsikter extra värdefullaoch intressanta för den här utredningen.

B.5 ResultatHär nedan presenteras resultaten från de olika undersökningarna som utförtstill den här utredningen.

B.5.1 Enkät

Sammanställning av resultat från enkäten som gruppmedlemmar fick besvara.Enkäten bestod i majoritet av frågor där man fick förklara sitt svar med eg-na ord. Följande svar är sammanfattningar av samtliga svar från en faktiskaenkäten.

Har du arbetat med Qt Designer under projektet?62.5% av gruppen har använt Qt Designer under projektet.

34

Hur finner du funktionaliteten i Qt Designer? Vad är bra och vad ärinte så bra?Det var inte så invecklat att påbörja, smidigt att man lätt med några knapptryckkan få ett GUI ungefär som man vill och det är även inte så knepigt att justerautseende. Dock så ser både Qt Designer och de GUI som man bygger stela utoch estetiskt trista. De känns väldigt statiska och omoderna.

Uppskattat, hur många timmar skulle du säga att det tog tills dukände dig insatt i Qt Designer och PySide?Mellan 8 och 15 timmar i medelvärde.

Hur väl överstämmer programmet som vi tagit fram med den visionsom du hade tidigare i projektet?De flesta tycker att det vi fått fram stämmer överens med det som de siktademot. Blev lite begränsade utav stelheten i Qt Designer och Qt4.

Anser du att vi valde bra verktyg för just det här projektet?De flesta är någorlunda nöjda, men skulle velat ha något modernare, som Qt5eller PyQt.

Om du kunde förändra EN grej, vad som helst, med verktygen: Vadskulle det vara?Det skulle varit skönt med mer modernisering av verktygen, ännu en gång Qt5eller PyQt.

B.5.2 Effektivitetstest

Sammanställning av tester som utfördes för att undersöka ökning i effektivitetdå man använder Qt Designer och det nämnda PySide-skriptet [22]. Testernautfördes av en person som har arbetat Qt Designer en stor del av projektet,och då är insatt i det. I testerna jämförs tiden det tar att implementera UI i QtDesigner mot antalet rader som genereras, i både XML-filen och i Python-filen.Med XML-kod menas koden som genereras direkt av Qt Designer, och medPython-kod menas den som genereras då man kör PySide:s inbyggda skript föratt generera körbar Python-kod.

Uppgift 1:Lägger till en knapp i ett redan existerande gränssnitt. Knappen ska bestå aven ikon och ha en fixerad storlek. Den ska även vara kryssbar.Resultat:Qt Designer: 53 sekunder.XML-kod: 29 rader. 33 rader/minut.Python-kod: 11 rader. 12 rader/minut.

Uppgift 2:Skapa ett helt nytt fönster med en egen titel. Inuti fönstret ska det finnas ettredigerbart textfält och två knappar. De två knapparna är ”Cancel” och ”OK”.Resultat:Qt Designer: 1 minut och 15 sekunder.

35

XML-kod: 67 rader. 54 rader/minut.Python-kod: 28 rader. 22 rader/minut.

Uppgift 3:Skapa ett helt nytt fönster. I detta fönster ska det finnas en checklista med fyraalternativ, ett icke-redigerbart textfält, och två knappar som säger ”Cancel” och”OK”. Kryssrutorna och textfältet ska ha en redigerad text.Resultat:Qt Designer: 1 minut och 47 sekunder.XML-kod: 102 rader. 57 rader/minut.Python-kod: 46 rader. 25 rader/minut.

B.5.3 Användbarhetstest

Sammanställning av resultat från ett användbarhetstest utfört av projektetstestledare efter iteration 2 av projektet. Endast ett test utfördes och endastresultat relaterade till den här utredningen tas upp.

Vad tyckte användaren om programmets design?Användaren tyckte att programmet såg bra ut. Designen kändes standard, ochden påminde om andra program som användaren använder på jobbet.

B.6 DiskussionI enkäten ses att den generella åsikten i gruppen är den att funktionaliteten i QtDesigner och Qt4 känns omodern. Dock så visade kommentarer från användarei användbarhetstestet att utseendet faktiskt liknar de verktyg som framtidaanvändare redan är vana vid. Vilket är viktigast: att programmet efterliknarmoderna standarder, eller det är någonting som användaren är van vid ochredan känner sig bekväm med?

Från testet i effektivitet kan slutsatsen dras att Qt Designer kan vara ett väldigteffektivt verktyg att använda när man har lärt sig att använda det. Från enkätenkan det då betraktas att de flesta gruppmedlemmar kände att de hade lärt sigQt Designer efter 8 till 15 timmar av att använda och läsa om det. Så även omvidareutveckling av programmet väntar i framtiden så kan nästa utvalda personkomma igång inom en kortare tid.

Men är det värt att vidareutveckla vårt program, implementerat som det ärgenom Qt4? Den uppföljande versionen till Qt4, Qt5, har mer möjligheter, menhar licenser som kan göra den mindre attraktiv att använda, vilket hjälper tillatt göra Qt4 till ett okej val. Qt4 må anses bland gruppen att vara stelt och omo-dernt, men det har även mycket potentiell funktionalitet som vi under projektetinte valde att testa i vårt program. En programmerare med mer erfarenhet vidQt skulle kunna använda ramverket på vis som vår grupp inte kan, då vi ej harden nödvändiga kunskapen eller erfarenhet till det ännu.

Hade vi valt att använda verktygen som vi gjorde om vi vetat vad vi vet nuredan i början av projektet? Slutprodukten blev någonting som vi ändå är nöjdamed, och ramverket som vi använder är stabilt och har många möjligheter. Så

36

antagligen skulle nog beslutet bli det samma även då, förutom några skillnadervi säkert skulle gjort i vår design där vi märkt av att saker inte fungerat så somdet var tänkt.

B.7 SlutsatsMed de flesta faktorer inräknade så fungerade vårt val av verktyg bra. Denstörsta begränsningen vi hade vid valet av verktyg var licenser som ej passadein, vilket ej kunde ha gjorts annorlunda i vilket fall som helst. Verktygen var inteför komplicerade att använda till ett projekt med så kort livslängd, då det integick så lång tid tills vi kunde börja implementera funktionalitet till programmetsGUI.

Vi lyckades använda verktygen på ett sådant sätt att vi kände oss bekväma medslutresultatet, samtidigt som kunden även ansåg att programmet var väl gjort.

37

C Kanbankung eller Scrummästare?En utredning skriven av Niklas Erhard Olsson, utvecklingsledare i Grupp 8 ikursen TDDD96 vid Linköpings universitet.

C.1 InledningScrummästare eller Kanbankung, det är frågan. För grupp åttas projektarbetei årets upplaga av PUMen, vilken typ av agil metod är att föredra? Under tvåskilda iterationer ska grupp åtta anamma de två utvecklingsmetoderna Scrumoch Kanban till fullo och utvärdera effekterna av dessa. Dyker det upp någrasvårigheter med någon av metoderna beroende på vilka arbetsuppgifter projek-tet för nuvarande har? Blir vi mer effektiva? Vad blir effekten av att anammadessa metoder? Det här är ett experiment som delar med sig av många lärorikalärdomar för förstagångsanvändare av de olika metoderna.

C.1.1 Syfte

Syftet med experimentet är att få erfarenhet av både Scrum och Kanban ipraktiken. Att få chansen att ta del av värdefulla lärdomar inom respektivemetod och kunna redogöra för när en av metoderna är att föredra över denandra. På köpet inbringar förhoppningsvis metoderna struktur och tydlighet ivad som ska göras härnäst.

C.1.2 Frågeställning

Frågeställningen som utredningen avser att behandla är följande:

• För ett projektarbete med 9 gruppmedlemmar i kursen TDDD96, vilkenagil utvecklingsmetod av Scrum och Kanban är att föredra?

• Kan vi följa Scrum exakt enligt modellen eller kommer vi behöva göraanpassningar?

• Under olika iterationer, beroende på hur långt gånget projektarbetet äroch hur arbetsuppgifterna under en iteration ser ut, kan man ha någonfördel av att helt byta agil metod?

• Blir gruppen effektivare med hjälp av en tydlig och beprövad arbetsmetodjämfört med att inte ha någon speciellt definierad arbetsmetod?

C.2 BakgrundI kursen TDDD96, kandidatprojekt i programvaruutveckling föll lotten som ut-vecklingsledare på mig. Vi har tillsammans i gruppen pratat om att anammaScrum som ett ramverk för utvecklingsprocessen under iteration 2. Utvecklingenoch arbetsuppgifterna för iteration 3 kommer, på förhand, skilja sig en del fråniteration 2. Under iteration 3 kommer vi nämligen jobba mer med förfining avredan befintliga features, refaktorering och att fixa eventuella buggar. Under ensådan löpande process kan det på förhand verka lämpligare att använda Kanban

38

som ramverk för utvecklingen istället för Scrum.

C.3 TeoriNedan följer relevant teori för att hänga med i vidare diskussion.

C.3.1 Agil

Med agil i kontexten av arbetsmetoder inom programvara syftar man på iterati-va utvecklingsmetoder. Utvecklingsmetoder som genom ett upprepande arbets-sätt lägger till ytterligare funktionalitet eller förfinar existerande programvara.Agila utvecklingsmetoder har många fördelar för parterna och gör det möjligt förprojekt att anpassa sig efter snabba förändringar under utvecklingens gång.[23]

C.3.2 Scrum

Inom IT-branschen är Scrum en välkänd och välbeprövad agil arbetsmetod.Den mest använda utvecklingsmetoden som fungerar i egenskap av ett ramverkför en process eller ett projekt [23]. Med ramverk menas att Scrum har ettpar tillämpningar man måste följa för att kalla arbetsmetoden för just Scrum.Typiskt för Scrum är att man har följande roller och beståndsdelar men detär väldigt vanligt att man modifierar dessa på något sätt som passar projektetbättre. [24]

Figur 7: Scrums process, [24]

ProduktägareI Scrum bär produktägaren det yttersta ansvaret för backloggen även om det ärmöjligt att denna person låter andra i teamet utföra uppgifterna att skriva ochgranska backloggen.

ScrummästareScrummästarens roll är att se till att arbetet för alla i teamet går smidigt, det ären roll som tjänar de andra i teamet. En scrummästare coachar utvecklingstea-met till självorganisering och försöker underlätta arbetet genom att undanröjaeventuella hinder som uppstått för gruppmedlemmarna. Scrumästaren hjälperäven produktägaren att organisera och tolka backloggen och om det behövs ävenpåminna utvecklingsteamet om att skriva tydliga poster i backloggen.

39

UtvecklingsteamInom Scrum är det utvecklingsteamet som gör själva arbetet och det är bara desom får bidra till den inkrementella förändringen på produkten. Rekommende-rad storlek är 3 till 9 personer.

Beståndsdelar

• ProduktbackloggDetta är ett dynamiskt dokument som växer fram allt eftersom förståelsenför produkten ökar och eventuellt ändras. Här listas alla de egenskaper,funktioner, förbättringar och förändringar som finns för produkten. I bör-jan kommer produktbackloggen bara att beskriva de krav som är bästförstådda för att under projektets gång utvecklas och förfinas. Till slut ärproduktbackloggen en komplett lista över krav på produkten. Utvecklings-teamet bör bara arbeta utifrån detta dokument och det är produktägarensom bär ansvaret för att produktbackloggen sköts och prioriteras.

• SprintbackloggInför varje sprint väljs ett antal poster ut från produktbackloggen som skallingå och slutföras under kommande iteration. Dessa poster sätts ihop tillen sprintbacklogg och utgör en slags prognos för vad som kommer attfinnas med i nästa inkrementering av produkten.

• SprintArbetet och uppgifterna från produktbackloggen delas in i sprintar. Ensprints längd varierar mellan 1-4 veckor beroende på projekt och vad ut-vecklingsteamet föredrar. Inför sprintarna lägger man upp en planeringoch fastslår vad som ska göras klart innan den aktuella sprintens slut.Dagliga möten hålls och man mäter framstegen ofta med hjälp av ettprogressdiagram.

• Dagligt scrummöteDe dagliga scrummötet är tänkt som ett kort möte på maximalt 15 minutervars syfte är att uppdatera gruppen om helheten av projektprogressionen.Eventuella hinder som uppstått hos gruppmedlemmar kan diskuteras ochundanröjas. Vanligen ställs tre frågor på formen:

– Vad har du gjort sedan föregående möte?– Vad ska du göra till nästa möte?– Finns det något som hindrar dig?

• Burn-down diagramBurn-down diagrammen hjälper att visualisera och förutsäga hur mycketåterstående arbete det är kvar under sprinten. Dess huvudsyfte är att,så tidigt som möjligt, upptäcka om teamet ligger före eller långt efteri schemat så det finns möjlighet att åtgärda detta. Denna uppdaterasdagligen och kan även fungera som en motivationshöjare för teamet. IScrum är dock burn-down diagram inget som är fastställt. Teamet fåranvända sig av vilken metod som helst för att följa progressionen. [25]

• SprintutvärderingEn sprintutvärdering hålls i slutet av varje sprint där man granskar det

40

Figur 8: Grupp 8 burn-down diagram

framtagna resultatet. Speciellt vill man veta vad som blev och inte blevklart under sprinten.

C.3.3 Kanban

Till skillnad från Scrum och det iterationsdrivna arbetssättet med tydliga featu-res som enligt målsättning ska vara klara i slutet av iterationerna så har Kanbanett annat tillvägagångssätt till progressionen. Man kan se Kanban mer som eninkrementell pågående process av förändring. Kanban har en backlog med dehögst prioriterade uppgifterna högst upp. Prioriteringen sköts av produktägarensom är fri att göra välvalda omprioriteringar. Förändringar utanför de påbörjadeuppgifterna påverkar inte teamet eller den nuvarande progressionen. I Kanbanfinns ingen anledning till att ha fasta längder på iterationer eftersom att så längelistan på saker att göra är prioriterad av produktägaren så garanteras maximaltvärde tillbaka från teamet.[13]

C.4 MetodUnder projektets gång anammar vi ett av ramverken under varsin iteration ochutvärderar effekterna av de båda arbetsmetoderna i slutet av respektive itera-tion. Var och en i gruppen kommer svara på några välvalda förbestämda frågorom hur personen i fråga upplever metoden. Var och en av gruppmedlemmarnakommer få berätta hur denne upplevde förändringarna i praktiken. En jämfö-relse görs mellan antal timmar gruppen har arbetet under en iteration och hurmånga commits detta resulterade i.Tillsammans diskuterar vi och beslutar om att anpassa metoden efter gruppensspecifika behov eller inte. Anpassningen sker för att gynna gruppens effektivitetoch projektets framfart.

Vi använde oss av en tavla i webbverktyget Trello för att organisera uppgifteri samtliga iterationer. En bidragande faktor till den tydliga överblicken var de,något modifierade, dagliga mötena som lades upp för alla att se varje dag igruppens kanal i slack.

41

Det här experimentet har några fallgropar. Projektet är från början byggt kringiterationer, vilket redan är väldigt mycket vad Scrum går ut på. För att testahur bra Kanban passar till mjukvaruutveckling hade vi egentligen behövt göraom samma projekt helt utan iterationer för att få ett representativt resultat.Istället blir det svårt att skilja på Kanban och Scrum eftersom att vi, i bådapraktikerna, kommer att arbeta med hjälp av tavlor för att hantera och visua-lisera vårt arbetsflöde.

C.5 ResultatC.5.1 Scrum

Anammandet av Scrum medförde främst en tydlig struktur och ordning. Grup-pen hade alltjämt en klar överblick över vad som skulle göras och vad som hadeslutförts. Ett flertal i gruppen tyckte även att det var bra att enkelt kunna följaprogressionen av projektet genom att på ett överskådligt sätt se vad andra gjor-de och skulle göra därnäst och samtidigt få sina egna problem sedda. Featuresblev klara och höll hög kvalité, gruppmedlemmarna tog sig an en feature ochsåg till att den blev klar. Majoriteten av gruppen tyckte att produktiviteten varöverlag bättre än under iteration 1. Delar av gruppen upplevde dock att det varsvårt att ta egna initiativ eller att fixa andra mindre saker som inte fanns med ibackloggen. En feature kunde vara relativt stor och kunde egentligen ha brutitsned i fler mindre delar, detta medförde att om man fastnade på en feature mantagit sig an fanns det risk för att känna sig väldigt improduktiv.

Många upplevde också en förhöjd sammanhållning och gruppdynamik underiteration 2. Somliga tyckte att de dagliga mötena ibland kunde vara jobbiga ochsjälvklart gjorde vi en snedvriden poänguppskattning av arbetet.

Sammanfattningsvis har, i det stora hela, tillämpningen av Scrum mestadelshaft positiva effekter på projektet och gruppen. Tilläggas skall att gruppen harunder denna period gjort 220 stycken commits till källkoden och arbetat 655timmar tillsammans, detta motsvarar ungefär 0.34 commits/timme.

Figur 9: Gruppens totala antal commits, iteration två

C.5.2 Kanban

Under iteration tre använde gruppen Kanban som huvudsaklig arbetsmetod.Alla i gruppen har upplevt Kanban-experimentet som lyckat. Alla medlemmar

42

säger att Kanban har fungerat bra och närmare 90% anser även att experimen-tet har varit realistiskt. Den tydligaste skillnaden och förbättringen har varitatt våra uppgifter varit uppdelade i mindre delar än tidigare. Uppgifterna harinte varit tvungna att vara bundna till en speciell feature som under iterationtvå. Gruppen har upplevt detta positivt och lätt att komma igång och göranågonting. Arbetet upplevdes friare och en person nämnde också att det blevmindre slöseri på tidsuppskattningar varje dag.

Överlag tappade gruppen en del av den tydliga strukturen som Scrum medfördeoch ett flertal gruppmedlemmar saknade de dagliga mötena som hölls under ite-ration två. Tilläggas skall att gruppen har under denna period gjort 260 styckenbidragande förändringar till källkoden och arbetat 895 timmar tillsammans ochmotsvarar ungefär 0.29 commits/timme. Alltså aningen färre än under iterationtvå som hade 0.34 commits/timme.

Figur 10: Gruppens totala antal commits, iteration tre

C.6 DiskussionSå, var kommer den förhöjda känslan av struktur och ordning ifrån? Underden första iterationen var det mycket dokument som skulle skrivas, krav attsamla in från kunden och arkitekturen för projektet skulle läggas. Iterationett var en uppstart av projektet med många lösa trådar och kan ha medförtkänslan av mindre produktivitet eftersom faktiskt arbete på produkten intepåbörjats ännu. En starkt bidragande orsak till en tydligare struktur och ordningi iteration två kontra iteration ett kan ha varit att vi på ett tydligt sätt bestämdetillsammans vad programmet skulle kunna utföra efter iterationen och att visamtidigt följde upp progressionen under tiden. Vikten av att mäta framstegenoch att återkoppla för att se hur vi ligger till och om vi kommer nå de sattamålen innan iterationens slut har varit av största betydelse för att med säkerhetkunna leverera någonting av värde till kunden vid slutet av iterationen. Trotsatt poängen vi gav varje feature självklart var en aning fel bidrog de till enövergripande bild över hur vi låg till och om vi måste jobba hårdare eller inte.

Att varje dag presentera progressionen, gruppens produktivitet och vad allagjort och kommer göra härnäst kan ha bildat bättre sammanhållning i gruppenoch en vi-känsla som tidigare inte funnits. Det är vi, tillsammans, som skapardetta och alla får visa vad de har bidragit med till projektet varje dag. Att varjedag presentera för varandra vad man gjort under dagen och vad man ska ta sig

43

an nästa dag gav många av gruppmedlemmarna en positiv press som ledde tillatt mycket arbete blev gjort. Det är en form av åtagande, ett sorts löfte tillgruppen som definitivt gynnat det individuella ansvarstagandet för hela projek-tet. En annan bidragande faktor kan också givetvis vara att gruppen tagit någotsteg på gruppdynamiksstegen. Gruppen har under iteration två blivit tryggaremed varandra och lyckades kanske hitta sin roll i gänget. Inlärningenströskelnav PyQt hade de flesta kommit över och arkitekturen var lagd när iterationtvå påbörjades. Med grunden lagd för projektet och med insatta gruppmedlem-mar utrustade med grundläggande kunskaper om hur man använder PyQt medPython, kunde gruppen med enkelhet modifiera och utöka ett redan fungeran-de GUI från första iterationen. Detta bidrog med stor sannolikhet till en ökadkänsla av produktivitet, att det mesta flöt på.

Under iteration tre upplevde 80% av gruppen att arbetet gick lättare främst pågrund av att uppgifterna var i mindre delar men att mycket av den strukturenScrum medförde försvann. Att Kanban i sig skulle vara orsaken till detta ärsvår att tro. Om vi hade delat upp våra features i iteration två i mindre delarhade detta också kunnat bidra till att det varit lättare att ta på sig uppgifter.Om gruppen har varit mer produktiv med Kanban än med Scrum är ocksåsvår att svara på men faktum är att scrumperioden faktiskt resulterade i flercommits/timme än vad Kanban gjorde.Under iteration två, trots att gruppen kunde tycka att det var jobbigt att tasig an en hel feature så jobbade man flitigt på och fick väldigt mycket gjort.Fokuset var lagt på en större uppgift som man arbetade på tills man ansåg sigvara klar.

Så var kommer den förhöjda känslan av produktivitet ifrån egentligen? Grup-pen har känt sig generellt mer effektiv i den tredje och sista iterationen. Detkan bero på att medlemmarna vid det här laget har djup förståelse över kod-basen men också att den stora arkitekturen var lagd. Medlemmarna behövdenu alltså inte uppfinna hjulet igen för att skapa en liknande knapp som gjortstidigare och detta kan ha upplevts lättsamt och enkelt att få saker gjorda. Detkan också bero på att när man fastnade på ett problem i scrumperioden kundeman lätt känna sig improduktiv och detta kan ha bidragit till att medlemmar-na upplevde att man var någorlunda mer effektiv med Kanban. I och med attvi körde våra dagliga scrummöten på nätet kunde vi inte tillsammans diskute-ra igenom eventuella problem som hade uppstått för projektmedlemmarna. Vitappade således tillfället att diskutera igenom problemen i gruppen och direktfå utbyte av kunskap mellan varandra och inte heller undanröja de problemsom dykt upp för individuella medlemmar och de kan således ha suttit fast medett problem längre än nödvändigt. Detta har troligtvis bidragit till känslan avimproduktivitet. Att dela upp stora features i mycket mindre delar eller att tea-met arbetar tillsammans på en hel feature tills den är klar hade möjligen ocksågynnat produktiviteten en aning.

Känslan av att gruppen varit med produktiv under iteration tre kan också, medstor sannolikhet, bero på att vi har fler commits och gruppen har jobbat mångafler timmar under denna period. Faktum är att vi har fått väldigt mycket gjortunder iteration tre, mer än under iteration två, men vi har samtidigt ocksåjobbat 240 timmar mer i iteration tre.

44

Vilken metod är då att föredra för projektarbete på denna form? Jag tyckeratt det hela är en aning missvisande med att många tycker att det var bättremed Kanban. I och med att vi redan arbetar i iterationer blir det svårt att göraett utförligt experiment över en såhär kort tid. Hela arbetsmetoden överlag ikursen är stämmer redan mycket väl in på Scrum, exclusive Scrums artefakter.Om vi istället hade t.ex. använt Kanban i ett helt projekt från början till slut isex månader, med en enda stor backlog och ett arbetsflöde som flyter på, hadevi inte kunnat mäta progressionen och inte heller garantera några features tillolika versioner, det hade också varit svårt att säga var en version slutar och enannan börjar. Det hade varit svårt att få någon struktur på utvecklandet medtydliga leveranser av färdiga versioner. Charles Bradley går till och med så långtsom att säga att med enbart Kanban som utvecklingsmetod, hade vi inte hafttillräckligt med verktyg för att utveckla programvara i överhuvudtaget[26].

Finns det då någon fördel med att byta metod? Som vi vet föredrog mångaKanban i vårt utvecklande mot slutet. Det sättet vi använde Kanban passaderätt bra till finjusteringar och små förändringar som vi hade i iteration tre. Ingastora nya features skulle byggas utan det handlade mer om att successivt för-bättra produkten genom finslipning av små saker. Då passade Kanban väldigtbra för den pågående processen som egentligen aldrig tar slut. Det går alltid attförbättra eller ändra något till det bättre.

C.7 SlutsatserÄr Scrum att föredra framför Kanban? Ja! Iterationerna är extremt viktiga föratt säkerställa leverans av olika versioner. Det är väldigt fördelaktigt att haett sätt att mäta och estimera progressionen för att garantera att vi har någotkunden vill ha vid given deadline. Dessutom har man ett annat fokus och entydligare plan över vilka funktioner man ska lägga fokus på.

När det gäller förfiningsarbete av slutprodukten kan det mycket väl passa attbyta metod och arbeta mer med ett pågående flyt enligt Kanban.

Gruppen blev märkbart effektivare och fick bättre sammanhållning med en be-prövad arbetsmetod kontra ingen definierad arbetsmetod. Det visar sig ocksåatt man mycket enkelt kan anamma Scrum i detta projekt nästan enligt in-struktionsböckerna. Vi behövde enbart anpassa de dagliga mötena genom atthålla dessa online via webbverktyget slack. Detta på grund utav att vi gick olikautbildningar och det var svårt att få ihop ett fungerande schema där alla kundedelta.

45

D Teamledarens roll i mjukvaruutvecklingEn utredning skriven av August Fundin, teamledare i Grupp 8, i kursen TDDD96vid Linköpings universitet.

D.1 InledningDenna studie behandlar hur min roll som teamledare fungerat och upplevts avden grupp jag arbetat tillsammans med i samband med kursen TDDD96. Detvar inte helt lätt att förhålla sig till denna roll, eftersom jag inte hade tidigareerfarenheter av att ha en ledarroll. Studien är till intresse för den som finnersig i en liknande situation som min, som innehavare av en ledarroll i ett mindreprojekt. Under kursens gång använde gruppen varierade arbetsmetoder vilketgav flertalet intressanta perspektiv på rollen. Frågeställningar som uppkom un-der arbetet var bland andra: När lämpade det sig att styra med järnhand?Vilka är de elementära kvaliteter en teamledare ska behärska och vilka bestårom arbetsmetoden som tillämpas aktivt exkluderar en person med framträdan-de ledarroll? Studiens resultat visade sig intressanta på grund av att oavsettarbetsmetod så var det samma attribut hela projektet igenom som värderadeshögt. Att gruppen hade någon som samordnade möten och samlingar, och attledaren lät gruppen agera mycket på fri hand.

D.1.1 Syfte

Studien har gjorts i syfte att utröna hur medlemmarna i gruppen uppfattadevad jag som teamledare tillfört i kursens projektarbete samt hur jag, i egenskapav teamledare, kunnat verka på ett effektivt sätt inom projektet. Utredningenger en reflektion kring rollen i det sammanhang som gruppen verkat i - ettprojektarbete med fokus på mjukvaruutveckling. Förhoppningen var att studienskulle kunna användas som redskap för kommande projekt.

D.1.2 Frågeställning

Frågan som studien fokuserar på att besvara är alltså som följer:

• Hur fungerade rollen som teamledare i projektet när gruppmedlemmar-na arbetade efter de olika arbetsmetoderna SCRUM, Kanban och utandefinierad arbetsmetod?

D.2 BakgrundI kursen TDDD96, kandidatprojekt i programvaruutveckling, delades deltagan-de studenter in i mindre grupper. I Grupp 8 tillsattes jag som teamledare i engrupp på totalt nio personer. Rollen var en helt ny erfarenhet för mig. Underprojektets gång förväntades jag, av studieanvisningarna, huvudsakliga ansvarmåluppfyllnad, att processer följs och coachning av gruppen. Rollen motive-rades även med att någon skulle bära ansvaret, ha sista ordet i diskussioneroch vara gruppens ansikte utåt7. Vidare fick teamledaren också ansvara förprojektledningen, alltså projektplan, möten med mera8. Ur ett perspektiv är

7https://www.ida.liu.se/~TDDD96/info/rollerdokument2016-01-21.pdf8https://www.ida.liu.se/~TDDD96/info/praktiskprojektledning2016-01-22.pdf

46

rollen självklar, en enkel ställning att ta är att ställa sig bakom filosofin att“det klart att en ansvarig ledare behövs för att upprätthålla ordning”. Rollenfick ändå anledning att undersökas när det visade sig att tillsätta en teamle-dare inte är standardförfarande i de olika arbetsmetoderna gruppen tillämpat.Projektet som skulle genomföras var utveckling av en mjukvara på beställningav ett större företag. Totalt förväntades gruppen lägga 400 timmar per personpå utvecklingsarbetet samt rapportskrivning. Övriga roller inom gruppen varföljande: arkitekt, konfigurationsansvarig, kvalitetssamordnare, analysansvarig,utvecklingsledare, testledare, dokumentansvarig och specialist.

D.3 TeoriSyftet med en ledare är att säkerställa ett ledarskap. Det vill säga att se tillatt alla i gruppen delar samma vision, att framsteg och resultat uppnås, attgruppen arbetar som en kollektiv enhet och att alla gruppmedlemmar upp-märksammas [27]. Initialt då gruppen arbetade utan definierad arbetsmetod,allt skedde ad-hoc, ifrågasattes inte rollerna som föreslogs i studieanvisningar-na och teamledaren fick då en naturlig plats i gruppen. Teamledaren är dockinte automatisk inkluderad i ett team som använder Scrum som arbetsmetod9.Kanban kommer inte med satta roller alls utan där så appliceras de roller somkrävs eller redan finns [13]. När det talas om rollen teamledare åsyftas oftast enperson vars huvuduppgift är att bära ansvaret för en grupps resultat [28]. Exaktvilka ansvarsområden en teamledare har varierar alltjämt mellan olika organi-sationer10. I kursen har rollen dock beskrivits snarare som en koordinator medadministrativa uppgifter, vilket överensstämmer med synen av en teamledare en-ligt författaren Sara Pope som skrivit Team Leader Workbook [29]. Principielltmenar Pope att en teamledares uppgift är att säkerställa att samtliga grupp-medlemmar är införstådda i gruppens mål och håller gruppen fokuserad på dettamål. Därutöver ska teamledaren ansvara för möten och övervaka arbetsflödet.Det finns däremot rapporter som visar på att prestationen och välmåendet i engrupp kan begränsas av att en person innehar rollen som en typisk ledare ochatt när ett mjukvaruprojekt ska genomföras kan andra metoder, som Scrum,lämpa sig bättre [30].

D.4 MetodDetta kapitel beskriver studiens metod och hur insamlingen av material ska gö-ras. Fenomenet som undersöks är hur teamledaren uppfattas i grupparbetet ochdärför har jag valt att använda mig av en fenomenografisk metod enligt professorMichael Uljens [31]. Med detta perspektiv analyseras olika gruppmedlemmarsuppfattning kring samma aspekter i ämnet, enligt fenomenografins arbetsord-ning. Sammanfattat består arbetsordningen av att först välja ut ett fenomenoch därefter flera aspekter kring det valda fenomenet. Sedan görs insamlingarav data kring individers uppfattningar av fenomenet och därefter kan en ana-lys av materialet påbörjas. Sista steget i arbetsordningen är att få analysen attresultera i beskrivningskategorier. Med utgångspunkt i teorin både formulerasdatainsamlingen och analyseras materialet, och likheter samt skillnader kringhur gruppmedlemmarna upplevt teamledarens insats identifieras. Efter att resul-

9Se 3.1.210https://en.wikipedia.org/wiki/Team_leader

47

taten är sammanställda sker kategoriseringen i innebördsmässigt skilda avsnitt.I diskussionen sammanfattas kategorierna, då resultaten av materialet ska tolkas[31]. De aspekter jag har valt att titta på är kontextualiserade i frågeställningarsom alla gruppmedlemmar anonymt fått svara på och analysen presenterar jagi resultatdelen av studien.

D.4.1 Material

Jag har valt att göra datainsamlingen med hjälp av enkätundersökningar. Dentypen av undersökning gav mig snabba svar där kategorisering enkelt kundegöras efter flervalsalternativ i enkäten. På grund av att frågeställningen spe-cifikt inriktar sig på gruppmedlemmarnas uppfattning kring hur teamledarenpåverkat det egna projektet, är utredningen också begränsad till att undersökajust den egna gruppen. Därför begränsas urvalet av enkätdeltagare till grupp-medlemmarna i Grupp 8. Grupp 8 är ett homogent team på det sätt att denbestår av nio stycken datateknolog-studenter i ungefär samma ålder. Däremotkan urvalet anses vara heterogent i det avseende att alla har förhållit sig tillteamledaren och projektarbetet på olika sätt, i egenskap av de olika roller somgruppmedlemmarna haft. De frågor som enkäten innehöll baserades på den te-ori kring ämnet som valts till studien. Framförallt Popes tolkningar av vad enteamledare bör ha för åtaganden och kvaliteter var centrala i konstruktionenav frågorna eftersom den efterliknade kursens projicering av åtaganden samtkvaliteter på teamledaren.Frågorna samtliga gruppmedlemmar svarat på i enkäten är följande:

• Tyckte du gruppen hade ett tydligt ledarskap under iteration ett?

• Tyckte du gruppen hade ett tydligt ledarskap under iteration två?

• Tyckte du gruppen hade ett tydligt ledarskap under iteration tre?

• Anser du att någon annan i gruppen tagit över rollen som ledare undernågot tillfälle? Hade det några konsekvenser?

• Upplever du att alla i gruppen delar samma vision med Honeycomb?

• Upplever du att gruppen arbetar som en kollektiv enhet?

• Känner du att dina åsikter uppmärksammas?

• Utifrån vad du anser att en teamledare bör göra / bör vara, hur braupplever du att teamledaren har presterat? Gradera svaret på en skala 1till 5, där 1 är “mycket dåligt” och 5 är “mycket bra”.

D.5 ResultatI detta kapitel sammanställs svaren på enkäten. Sammanställningarna är uppde-lade efter kategorier som jag delade in aspekterna i. Kategorierna som jag valdei detta fall blev “tydligt ledarskap”, “trygghet i gruppen” och “sammanhållningi gruppen”.

48

D.5.1 Tydligt ledarskap

Sammanställt ansåg alla utom en i urvalet att gruppen hade en tydlig ledareunder iteration ett. Det kan antas att då denna iteration innebar arbete utannågon specifik arbetsmetod var behovet av en ledare större. Samt att en leda-re är viktigare i uppstarten av ett projekt. Den entydiga upplevelsen ändradesdäremot under iteration två där gruppen blev mer splittrad. Utvecklingsledarenvar under denna iteration utsedd Scrummaster11. Fyra ansåg att gruppen hadeett fortsatt tydligt ledarskap. Tre personer tyckte att det var något otydligt, attScrummaster, som var ansvarig för dagliga standups och att överse att arbetetgick framåt under detta arbetssätt, kunde anses vara ledaren. Åsikten att grup-pen var mer självgående framkom även. En person tyckte inte gruppen hade etttydligt ledarskap. I iteration tre tyckte fem personer att ledarskapet var tydligtoch tre personer tyckte inte det. Samtliga upplevde att teamledaren har levtupp till deras egna bild av hur en teamledare ska vara. Åsikterna går alltså isärkring huruvida ledarskapet framträtt tydligt eller ej men samtidigt menar allapå att teamledaren presterat bra. Jag vill lyfta fram ett specifikt svar kring den-na aspekt, från en person som förklarar sin upplevelse genom att motivera attledarskapet har varit bra, just eftersom det varit ett svagt ledarskap. Gruppenhar varit kapabel att fatta egna beslut och har inte varit i behov av en auktoritärledare. Upplevelsen av att teamledaren var mer framträdande initialt visar påatt gruppen med tiden mognat till att bli mer självstyrande.

D.5.2 Trygghet i gruppen

När det kommer till upplevelsen att någon tagit över rollen som ledare, frånteamledaren, i projektet anser sex personer att det hänt någon gång under pro-jektets gång. En tyckte att Scrummaster och teamledaren delade ledarrollenunder iteration två och fem menar att det hänt sporadiskt i samband med, ex-empelvis, en genomgång av ett verktyg. Två personer upplevde dock aldrig attnågon annan i gruppen tog sig an rollen som ledare. Oavsett vad gruppmedlem-marna har upplevt i fråga kring vem som varit ledare har det ingen upplevt någranegativa konsekvenser i ledarroll-bytet. Snarare har det upplevts som positivt,att gruppen kompletterat eller inspirerat varandra. Alla gruppmedlemmar harockså upplevt att deras åsikter har uppmärksammats, vilket vidare tyder på attgruppmedlemmarna känts sig trygga i gruppen.

D.5.3 Sammanhållning i gruppen

När det gäller upplevelsen av hur gruppen arbetar tillsammans tyckte fem perso-ner att gruppen arbetar som en enhet och två personer tyckte att gruppen oftastgör det. En person har upplevt sig ensam i sitt arbete men har svårt att utvär-dera om gruppen som helhet arbetat med bra sammanhållning eller inte. Dennadiskrepans har uppstått eftersom gruppen jobbat på olika geografiska platser el-ler använt verktyg på ett sätt som upplevts avvikande ifrån beslutad standard.Den vision som gruppmedlemmarna haft av det utvecklade programmet går isärnågot. Två upplevde att olika gruppmedlemmar hade tydligt isärgående visio-ner, två tyckte att gruppen huvudsakligen hade samma vision och fyra tyckte

11Se 3.1

49

att visionen har varit en gemensam nämnare i gruppen. Upplevelsen har varitatt gruppen, i stort, arbetat med bra sammanhållning men att vi jobbat motolika mål.

D.6 DiskussionSom resultatet visar så upplevde alla att teamledaren gjort bra ifrån sig, samti-digt som ledarskapet i gruppen inte alltid var så framträdande. Jag upplevde attjag var tvungen att mycket mer efterliknande den arketypen av en teamledaresom Pope advocerar. När Scrum applicerades som metod så försvann mycket an-svar från mina axlar och gruppens ledarskap blev otydligare. Trots detta ökadeinte osäkerheten i gruppen och känslan av ett enhetligt team där allas åsikterrespekterades fanns kvar. Det är viktigt att uppmärksamma upplevelsen attgruppmedlemmar hade avvikande visioner sinsemellan men att teamledaren än-då får gott omdöme. Antingen beror det på att medlemmarna inte föreställersig att det är på teamledarens ansvar att framhålla en gemensam vision eller såberor det på att uppgiften i sig var för otydlig och kundkontakten för sporadiskför att det skulle varit möjligt12. Med Scrum som arbetsmetod höll sig gruppentillräckligt anpassningsbar för att arbeta runt detta problem, eftersom en avstyrkorna med Scrum är att det huvudsakliga målet för ett helt projekt intebehöver vara tydligt för alla13.

D.7 SlutsatserSvaren på min frågeställning redovisas i följande slutsatser. De slutsatser somkan dras av resultaten är att rollen som teamledare var viktig i uppstartenav projektet samt när gruppen arbetade utan specifik arbetsmetod. Det haräven framkommit att det finns delade meningar inom gruppen angående vaden teamledare har för ansvar och roll. Där, bland annat, vissa ansåg att denmer administrativa rollen var det centrala och andra tolkade rollen teamledaresom någon auktoritär som inte var nödvändig i sammanhanget. När arbetet välkommit igång är teamledarens roll som just ledare inte lika aktuell.

Angående trygghet i gruppen kan slutsatsen dras att alla gruppmedlemmarupplevt att dem och deras åsikter fått uppmärksammas. Vilket tyder på att enmindre auktoritär ledarroll är att föredra om målet är att samtliga gruppmed-lemmar ska kunna komma till tals. Att ledarrollen fått skifta i olika situationerhar upplevts som positivt vilket antas bero på att en tydlig ansvarsfördelninggör gruppmedlemmarna mer engagerade i sitt eget och övriga medlemmars ar-bete. Angående sammanhållning i gruppen kan slutsatsen dras att det är svårtatt hålla samma vision inom gruppen när gruppmedlemmar inte befinner sigpå samma plats geografiskt. Samt om någon eller några av gruppmedlemmarnaväljer att frångå det arbetssätt som var överenskommet.

12Se 6.1.213https://www.ida.liu.se/~TDDD96/info/kravhantering2016-02-03.pdf

50

E En analys av kodgranskningarEn utredning skriven av Rasmus Johns, kvalitetssamordnare i Grupp 8 i kursenTDDD96, vid Linköpings universitet.

E.1 InledningDå ett nytt utvecklingsteam sätts ihop behöver många pusselbitar falla på plats.En av de mest centrala bitarna i det här pusslet är kodgranskningar. Utan kod-granskningar kommer kvaliteten i projektkoden, och således produkten, dras-tiskt sjunka. Då en arbetsgrupp initialt etablerar sin arbetsprocess är det därförviktigt att granskningar står i fokus.

Det finns idag flera olika sätt att genomföra kodgranskningar. Utbudet av meto-der växer dessutom konstant och man måste som nytt utvecklingsteam i dagensenorma IT-industri omsorgsfullt välja hur man granskar sin kod.

E.1.1 Syfte

Den här texten avser att undersöka hur en ny sammansatt grupp kan granskavarandras kod för att optimera gruppens output. Texten ska lyfta fram svårig-heterna som ett nytt arbetsteam ställs inför då de ska initiera deras gransk-ningsprocess.

E.1.2 Frågeställning

Frågeställningen som texten avser att behandla är följande:

• Hur kan ett nytt arbetsteam inom mjukvaruutveckling bilda en gedigengranskningsprocess?

• Hur bra var granskningsprocessen som vi valde att implementera?

• Hur hade vi förändrat vår kodgranskningsprocess om vi fick chansen attgöra om projektet?

E.2 BakgrundDå kandidatprojektet i kursen TDDD96, Kandidatprojekt i programvaruutveck-ling, startade splittrades kursens deltagare slumpat in i grupper om åtta till niostudenter. Dessa grupper skulle välja en av många projektuppgifter att ägna400 timmar per deltagare åt.

Eftersom att deltagarna, internt i gruppen, var främlingar för varandra föll detsig naturligt att gemensamt skapa en god arbetsprocess i början av projektet.Projektet var trots allt relativt stort och tidsbudgeten tillät gruppen att allokeratid åt förarbete.

Ett arbetsområde som ägnades mycket uppmärksamhet blev kodgranskningar.Gruppen ville redan från början upprätta en god granskningsvana som lyftesvagheter i gruppens arbete, samtidigt som ingen i gruppen skulle behöva kännasig mer trampat på tårna än nödvändigt.

51

E.3 TeoriI det här avsnittet presenteras nödvändig teori för att förstå texten.

E.3.1 Kodgranskningar

Kodgranskningar är ett sätt för arbetsteam att få flera personer att godkännaett stycke kod, istället för att bara utvecklaren, som på något vis lämnar in sinkod, själv godkänt det. Generellt sett delas kodgranskningar upp i två kategorier:formella granskningar och lättviktsgranskningar.

Formella granskningar är den mer traditionella metoden. Metoden involverarflera granskare och flera faser. Vanligtvis träffas en grupp utvecklare vid enserie tillfällen för att tillsammans gå igenom kod rad för rad. Det tillhör inteovanligheten att koden gås igenom på pappersform. Det är en detaljerad processsom ska utföras med omsorg.

Det andra alternativet är lättviktsgranskningar. Dessa granskningar är oftastmer integrerade i själva arbetsprocessen än formella granskningar. Exempel påolika slags lättviktsgranskningar är:

• Parprogrammering. Två utvecklare sitter tillsammans vid en dator ochskriver kod tillsammans. På så sätt granskas allt som skrivs med ytterligareett par ögon.

• Över-axeln. Personen som skrivit koden går igenom sin kod för en arbets-ledare som läser allt över axeln.

• Mailutskick. Systemet som koden skrivs på mailar automatiskt ut kodför-ändringar varje gång någon tillför en kontribution till källkoden.

• Granskning med hjälp av verktyg. Utvecklare och granskare använder bådatvå ett verktyg som underlättar en granskningsprocess som kan utföras pådistans [32].

E.3.2 Git och Gitlab

Git är ett versionhanteringssystem som också hjälper utvecklare att, på ettsmidigt sätt, granska kod. Systemet har utvecklats efter kraven: snabbhet, da-taintegritet och stöd för arbetsprocesser som inte är linjära [33]. Git bygger tillstor del på att man har en mästergren som man grenar ut från, vilket betyderatt man gör ett litet utskott på den stora grenen där man själv kan jobba i fred.När man anser sig vara klar med sitt utskott kan man då sammanfoga det medmästergrenen. På så vis kan flera personer arbeta på en gren och tillsammansbygga en större produkt.

Gitlab är ett online-verktyg som kan användas för att hantera Git-grenar.

52

E.4 MetodFrågeställningens valdes för att på ett analytiskt sätt undersöka vår gransk-ningsprocess och reflektera över hur vi kunnat göra saker annorlunda.

För att kunna besvara ämnena som frågeställningen berör kommer eget reflek-terande kring gruppens arbetsprocess stå i fokus. Gruppens medlemmar hardessutom svarat på en enkät som berör gruppens granskningsvanor.

Endast gruppmedlemmar ombads svara på enkäten eftersom att gruppen, somen enhet, följt samma arbetsprocess. För att kunna analysera arbetsproces-sen, och resan som gruppen gjort med den över de senaste månaderna, fickgruppmedlemmarna svara på några specifika frågor som behandlar just den härarbetsprocessen.

E.5 ResultatI det här avsnittet presenteras all fakta för att kunna diskutera frågeställningen.

E.5.1 Våra anledningar till att granska kod

Det finns flera anledningar för en grupp att granska sig själv. Fördelarna somlockade vår grupp att bygga en god granskningsprocess kunde summeras tillnågra få punkter:

• Arbetet håller högre kvalitet. Så snart en granskningsfas inrättats i engrupps arbetsprocess kommer åtminstone ett par extra ögon kontrolle-ra allt som skapas. Det får en direkt verkan på arbetet, då chansen atteventuella fel uppmärksammas ökar. Arbetet kan dessutom hålla en högrekvalitet av indirekta skäl, så som att personen vars arbete ska granskas ärmedveten om att så snart arbetet är ”färdigt” ska det granskas. Eftersomatt ingen tycker om att visa upp halvdant arbete kan man tänka sig attarbetet som i slutändan skickas till granskaren håller en högre kvalitet änom granskaren inte fanns med i arbetsprocessen.

• Gruppens arbete blir enhetligt. Då flera kreativa utvecklare tillsammansskapar en produkt, genom att separat utveckla flera delar av produktenparallellt, finns en direkt risk att de olika delarna av produkten utvecklaspå vilt olika sätt. Genom att tvinga gruppen granska sitt eget arbete fårvarje utvecklare en överblick över produktens struktur, vilket ger utveck-laren en chans att anpassa sitt sätt att skriva kod.

För att förstå granskningars potential kan man utgå från det här exemplet, sombaserats på riktig data: antag att kostnaden att åtgärda en defekt i program-koden under designfasen är en tidsenhet. Kostnaden, relativt sett till dennakostnad, att reparera den här defekten efter en release är då 100 tidsenheter[34].

Antalet defekter som beräknas upptäckas med hjälp av kodgranskningar skiljersig mellan studier. Somliga undersökningar menar att 70-90% upptäcks, medan

53

andra undersökningar pekar mot att det inte uppdagas i närheten av så mångadefekter som man kan ledas att tro [35, 36]. Det tycks dock råda en akademiskkonsensus om att granskningar upptäcker defekter.

E.5.2 Hur vi granskade kod

Verktyget vi valde att använda för att granska kod var Git. Förloppet för attföra in nytt arbete på mästergrenen ansåg vi skulle vara följande:

En utvecklare skriver färdigt sin kod, skapar testfall för den och läggen tillden. Efter att man lagt till sin kod gör man en sammanfogningsbegäran motmästergrenen. Då detta sker får alla övriga gruppmedlemmar en notis – varpåde kan granska den nya koden. När någon granskat koden lämnar granskarensin feedback till utvecklaren. Utvecklaren får då en notis och kan omforma dennya koden efter granskarens feedback. Har granskaren istället lämnat en tummeupp får utvecklaren sammanfoga sin kod med mästergrenen. Händelseförloppetfinns illustrerat i figur 11.

Figur 11: Gruppens granskningsprocess

Vi valde att inte ha några granskningsmöten. Granskningsmöten har historisktsett utgjort en hörnsten i granskningsprocessen. Roger S. Pressman, mjukvaruin-genjör och författare, föreslår att granskningsmöten, där granskare tillsammans

54

går igenom ett större stycke kod, är ett effektivt sätt att hitta defekter i kod[34].

E.5.3 Granskningars inverkan kontra tidsåtgång

Granskningar kommer dock till ett pris: de är tidskrävande. Exakt hur myc-ket tid varje granskning tar är svårt att säga och det finns inte många studiergjorda inom området. Den mest pålitliga och omfattande studien gjorde Smart-Bear, ett företag som utvecklar verktyg för att förbättra kvalitetsprocessen inommjukvaruuteckling, hos Cisco. De undersökte vilken hastighet som är lämpligatt granska kod. De kom fram till att 300-500 rader per timme var optimalt,och utvecklare som granskade kod snabbare än så fann klart färre buggar. Deupptäckte också att utvecklare som fick friheten att granska som de ville kundegranska samma typ av fil flera gånger och göra det i vilt olika hastigheter [35].

Då utvecklarna i vår grupp granskade kod skedde det på helt olika sätt: bådevad granskarna letade efter och i vilken hastighet de letade skiljde sig väsentligt(se figur 13 och 14). Hastigheten de granskade kod med skiljde sig mellan 180-3000 rader per timme. Endast en person i gruppen ansåg sig ligga under de 400raderna per timme, som Smartbear föreslår är optimalt.

E.6 DiskussionDet är svårt att ge ett rakt svar på hur en grupp på bästa vis kan skapa engedigen granskningsprocess. Man kan trots allt se, i en så pass homogen gruppsom vår, att inte ens alla var eniga om vad som hade varit bäst för gruppen,vilket figur 19 visar. Utifrån våra erfarenheter kan man dock tänka sig att enlista med punkter som granskarna kan följa är ett väldigt kraftigt verktyg attimplementera i sin arbetsprocess – särskilt med tanke på hur snabbt en sådanlista kan sättas ihop.

Granskningsprocessen som vi implementerade fungerade väldigt bra för oss. Denvar dock inte utan brister. Enkäten som gruppmedlemmarna svarade på visaratt även om förloppet för granskningsprocessen är väldigt specificerat, som vårvar, är det ingen garanti för att själva granskningen sker på ett visst sätt. Ivår grupp granskade trots allt alla kod med helt olika hastigheter och de letadedessutom efter olika saker i sin granskning: en person fokuserade helt på att letasyntaxfel, medan en annan enbart läste kommentarer och testkörde den.

Att folk i gruppen granskade kod på olika sätt hade inte behövt vara fel, om allagranskade all kod. I vårt fall, där det räckte med att en person granskade ochgodkände en bit kod för att den skulle sammanfogas med mästergrenen, hademan kanske velat ha mer enighet. I och med att olika granskare sökte efter olikasaker under sina granskningar fanns det ingen garanti att koden uppfyller enviss standard, då standarden testas på olika sätt av olika granskare.

Faktumet att alla i vår grupp, enligt den visserligen lilla forskningen som finnsinom området, granskar kod alldeles för fort indikerar att en mer formell gransk-ningsprocess möjligtvis skulle vara mer gynnsam. Det här påståendet stärks avenkäten gruppmedlemmarna fick svara på, då alla gruppens medlemmar ansåg

55

att en checklista, som de kan bocka av när de granskar ett stycke kod, hadeförbättrat deras granskningar (se figur 17). Alla gruppens medlemmar svaradeockså att de hade följt en sådan checklista och att de inte hade ignorerat den(se figur 18).

Den uppmärksamma läsaren kan ha lagt märke till att granskarens feedbackinte bearbetas eller dokumenteras i vår process. Den finns visserligen kvar påGitlab, men den läses nödvändigtvis inte av fler än granskaren och utvecklaren.

Det är möjligt att vår grupp hade kunnat öka sin produktivitet med hjälp avgranskningsmöten, som Roger S. Pressman föreslår. Sådana möten hade kunnatetablera en mer formell granskningsprocess, vilket man kan tänka sig skulle led-saga gruppen att göra noggrannare granskningar. Det är trots allt inte svårt atttänka sig att, precis som granskningar får kodaren att lämna in mer omsorgsfulltarbete, granskningsmöten får granskaren att granska noggrannare.

Huruvida gruppen gynnats av så pass formella granskningar som Pressman fö-reslår är dock svårt att säga. Personligen tror jag inte att möten som i sig självautgör en granskning hade hjälp oss; istället tror jag att möten där medlemmarnadelat med sig av sina granskningar och vad de hittat hade kunnat vara gynn-samt för gruppens arbetsprocess. På så vis hade kunskapen gruppen utvann vidvarje granskning nått fler än bara granskaren och utvecklaren.

E.7 SlutsatserDet uppstår flera utmaningar när en ny grupp inom mjukvaruuteckling skagranska sitt eget arbete. Vilka problem gruppen drabbas av tycks i första handvara ett resultat av hur mycket frihet granskarna får: för mycket frihet kan ledatill otydligheter gällande granskningens kvalitet, medan för lite frihet iställetleder till mycket overhead och oproduktiva processer. Från vår erfarenhet lig-ger balansen mellan de två extrempunkterna: läget där gruppen granskar sitteget arbete vid valfri tidpunkt, men efter någorlunda specificerade riktlinjer, tillexempel en checklista som granskarna kan följa under deras granskningar.

56

E.8 Figurappendix för individuell del E

Figur 12: Har du genomfört en kodgranskning?

Figur 13: Vad tittar du efter när du granskar kod?

57

Figur 14: Hur snabbt granskar du kod?

Figur 15: Har du granskat och godkänt kod som du känt dig osäker på?

Figur 16: Har du sett till att eventuella buggar/problem i kod du godkänt dokumente-rats?

58

Figur 17: Tror du att granskningsprocessen inom gruppen fungerat bättre om självakodgranskningarna skedde efter ett protokoll?

Figur 18: Hade du orkat följa en sådan checklista?

Figur 19: Tror du att gruppens totala output blivit bättre om gruppen tilsatte en gruppsom efter varje iteration granskade hela projektkoden?

59

F En analys av testerEn utredning skriven av Martin Lundberg, testansvarig i Grupp 8 i kursenTDDD96, vid Linköpings universitet.

F.1 InledningDe flesta agila utvecklare skriver tester för sin kod [37], men är alla tester värdalika mycket? Om man har ont om tid i ett projekt - vilket är regel snarare änundantag - och måste ställa olika typer av tester mot varandra, vilken typ börman välja? Även för de utvecklare som inte skriver tester för sin kod kan detvara intressant att veta vilken typ som är viktigast så att de får möjligheten attlära sig den typen först.

F.1.1 Syfte

Målet med den här rapporten är att beskriva och utvärdera testningen somutförts i projektet. Målet är även att utifrån den informationen ta reda på hurman får utvecklare som är ovana med tester att skriva tester.

F.1.2 Frågeställning

De frågeställningar som texten behandlar är:

• Vilken typ av tester har varit viktigast för vårt projekt?

• Hur får man utvecklare som är ovana med tester att skriva dem?

• Hur hade vi ändrat vår testning om vi fick chansen att göra om projektet?

F.2 BakgrundVid starten av kursen TDDD96, Kandidatprojekt i programvaruutveckling, be-stämdes projektets 9 medlemmar slumpmässigt. För de flesta av projektmed-lemmarna var nästan alla de andra medlemmarna främlingar. En av de förstasakerna gruppen gjorde var att tilldela varje medlem en roll som de skulle haunder projektets gång. Jag blev utsedd till projektets testledare och fick därmedhuvudansvaret för allt som hade med testning att göra.

F.3 TeoriFör att förstå utredningen presenteras här teorin för de olika tester och testpro-gram som använts i projektet .

F.3.1 Tester

De olika typer av tester som använts i projektet är:

• Enhetstester: Testar att individuella enheter av kod fungerar som de äravsedda att göra. En enhet är en så liten bit som möjligt av mjukvaran. Ivårt projekt har en enhet definierats som en funktion som inte tillkallar enannan funktion. Enhetstester skrivs med kod och körs automatiskt medhjälp av ett testprogram [38].

60

• Integrationstester: Testar att enheter fungerar tillsammans som de ska. Ivårt projekt har integrationstester varit tester som testar att flera funk-tioner fungerar tillsammans. Integrationstester skrivs med kod och körsautomatiskt med hjälp av ett testprogram [39].

• Systemtester: Testar att programmet uppfyller de krav som är specificera-de i kravspecifikationen. Systemtester skrivs med kod och körs automatisktmed hjälp av ett testprogram [40].

• Acceptanstester: Testar att programmet uppfyller de krav som är speci-ficerade i kravspecifikationen och bedömer om programmet är klart förleverans. Acceptanstester skrivs med text och utförs manuellt, antingenav utvecklarna eller kunden [41].

• Regressionstester: Testar att tidigare buggar inte har återkommit. Skrivsmed kod efter att en bugg upptäckts för att försöka återupprepa buggenoch säkerställa att den inte är kvar. Regressionstester körs automatisktmed hjälp av ett testprogram [42].

• Användbarhetstester: Testar hur lättanvänt och intuitivt programmet ärför en användare som är tänkt att använda slutprodukten [20].

F.3.2 Verktyg för testning

De verktyg som använts för testning är:

• pytest: Ett verktyg för att testa kod skriven med python. Man skrivertestfunktioner och kör dem via pytest genom att skriva ett kommando i enterminal. När testerna körts klart visas ett resultat i terminalen. Resultatetvisar hur många tester som lyckades och hur många som misslyckades. Förde tester som misslyckats står det var och varför det misslyckades [43].

• pytest-cov: Ett tillägg till pytest som gör det möjligt att se hur mycketav koden för ett projekt som är täckt av tester. Det går även att se vilkarader i koden som inte är täckt av tester [44].

F.4 MetodFör att besvara frågeställningarna har jag undersökt hur testningen genomfördesunder projektets gång samt tagit fram en enkät om testning i projektet som allaprojektmedlemmar svarade på.

F.4.1 Förstudien

Under förstudien, tiden innan iteration ett, skapades den första versionen avtestplanen. I den skrevs de första acceptanstesterna och saker som hur testerskulle vara utformade och vilket program som skulle användas för testning. Detbestämdes också att alla skulle skriva tester för den kod man skrev, vilket ärvanligt förekommande för agila projekt [45].

61

F.4.2 Iteration ett

Under iteration ett skrevs nästan inga tester. Det var på grund av att mestfokus låg på utvecklandet av GUI:t och för att alla projektmedlemmar var förosäkra på hur man skrev tester. Jag höll i en kort testskola efter halva iteratio-nen där alla projektmedlemmar installerade pytest och skrev ett väldigt enkeltenhetstest.

F.4.3 Iteration två

Under iteration två skrevs de flesta enhets- och integrationstesterna. Det varmest jag som skrev tester, nästan alltid på kod som jag inte skrivit. Ibland skrevandra projektmedlemmar tester för funktioner som de precis implementerat. Islutet av iteration två genomförde jag det enda användbarhetstestet. Deltaga-ren var anställd på Ericsson och hade liknande arbetsuppgifter som kundenskontaktperson. Strukturen på testet var att deltagaren först fick svara på någ-ra introducerande frågor, sedan lösa en uppgift och samtidigt tänka högt, ochslutligen svara på avslutande frågor. I slutet av iteration två skaffade jag äventillägget pytest-cov till pytest vilket gjorde att jag kunde se hur mycket ochvilken del av koden som täcktes av olika tester.

F.4.4 Iteration tre

Under iteration tre användes arbetssättet Kanban och ett virtuellt Kanban-board. Information om Kanban finns att läsa under rubrik C.3.3. För att få pro-jektmedlemmarna att skriva fler tester fanns det en kolumn i Kanban-boardetkallad testning. Där lades tickets för funktioner som precis hade implementerats.Det här gjorde att fler projektmedlemmar oftare skrev tester för sina funktioner.Sammantaget under iteration tre skrevs några fler enhets- och integrationstesteroch jag skrev även systemtesterna och regressionstestet. Systemtesterna testa-de varsitt krav i kravspecifikationen och regressionstestet var för en bugg somuppkom i mitten av iterationen. I slutet av iteration tre svarade alla projekt-medlemmar på en enkät skapad av mig om hur de upplevt testningen underprojektet.

F.5 ResultatI detta avsnitt presenteras de resultat som erhållits för att kunna besvara frå-geställningarna.

F.5.1 Tester

Under projektets gång har enhets-, regression-, system-, integrations- och accep-tanstester skrivits. Även ett användbarhetstest har utförts. Enhets-, regressions-,system- och integrationstesterna har skrivits som kod för att kunna köras auto-matiskt med testprogrammet pytest, medan acceptanstesterna har skrivits medtext för att utföras manuellt.

Totalt finns det 61 st automatiska tester och 20 st acceptanstester. Det är svårtatt avgöra var gränsen går mellan våra enhetstester och integrationstester vilketgör det svårt att säga hur fördelningen är dem emellan. Det finns hur som helst

62

56 st enhets- och integrationstester och de täcker tillsammans 78 % av koden, sebilaga J. Av de testerna testar 5 st funktioner i models, 4 st testar funktioner iview och 47 st testar funktioner i controllers. Totalt upptäcktes 29 buggar, utavdem upptäcktes ungefär 5 av enhets- och integrationstesterna. De var de endatesterna som upptäckte buggar. Resten upptäcktes manuellt genom att användaprogrammet.

F.5.2 Enkät om testning

Här visas en sammanfattning av resultatet från enkäten om testning. Det full-ständiga resultatet finns i slutet av min individuella del under rubrik F.8.

Tid lagd på tester och antal skrivna testerFigur 21 - 23 visar att alla utom en av projektmedlemmarna lade ned mindreän 8h på att skriva tester vilket är ca 2 % av den minimala tid man skulle ĺäggapå projektet - 360h. Projektmedlemmarna skrev i genomsnitt fler enhetstesterän integrationstester.

Användning av pytestFigur 24 och 25 handlar om hur flitigt projektmedlemmarna använde pytest.Svaren visar att många knappt använde pytest alls medan de programmeradeoch inte heller innan de godkände merge requests.

Problem med att skriva tester och förslag till lösningarFigur 26 - 28 visar att de största problemen med att skriva tester enligt pro-jektmedlemmarna var att det var svårt och kändes onödigt. De anser att mertid skulle fått dem att skriva fler tester. Flera projektmedlemmar tycker ävenatt något som kunde hjälpt dem skriva tester är om testledaren haft mer testex-empel tidigare och hållit i testskolan tidigare.

F.6 DiskussionNedan diskuteras de resultat som erhållits för att besvara frågeställningarna.

F.6.1 Tester i projektet

Enligt Google ska fördelningen av enhets-, integrations- och systemtester liknaen pyramid med cirka 70 % enhetstester, 20 % integrationstester och 10 %systemtester [15]. Det är svårt att avgöra om vi uppnått det eftersom det är svårtatt bestämma var gränsen går mellan våra enhetstester och integrationstester.Anledningen till det är att våra controllers är väldigt feta och funktionerna i demi hög grad beror på varandra. Om models istället innehållit mer logik uppdelati mindre funktioner hade det varit enklare att skriva enhetstester och skilja påenhetstester och integrationstester.

De tester som upptäckte flest buggar var enhets- och integrationstesterna, mendet beror förmodligen på att det fanns överlägset flest av de testerna. Anledning-en till att det inte går att veta exakt hur många buggar som testerna upptäckteär att det inte dokumenterades på något sätt.

63

F.6.2 Enkät om testning

Här diskuteras svaren på enkäten om testning.

Tid lagd på tester och antal skrivna testerAlla utom en av projektmedlemmarna lade ned mindre än 2,5 % av sin tidpå tester under projektets gång. Det är enligt mig alldeles för lite för att vetaom koden fungerar som den ska, vilket är syftet med testning. Det visar attgruppen och testledaren misslyckats med att integrera testning som en centraldel av utvecklandeprocessen. Att projektmedlemmarna skrev fler enhetstesterän integrationstester antyder att de är enklare att skriva för utvecklare som ärovana med tester.

Användning av pytestAtt många av projektmedlemmarna knappt använde pytest alls medan de pro-grammerade och inte heller innan de godkände merge requests är synd eftersomdet innebar att det ofta blev test-errors på mastern. Varje gång behövde då enny branch skapas för att fixa problemet vilket ödslade tid.

Problem med att skriva tester och förslag till lösningarI svaren på de tre sista frågorna finns enligt mig det viktigaste man kan ta medsig från enkäten: varför projektmedlemmarna skrev så lite tester och vad somkunde fått dem att skriva fler. De tycker att testning kändes svårt och onödigtoch att testledaren borde haft mer textexempel tidigare och hållit i testskolantidigare. Jag håller med om det och vill även tillägga att testning borde tagitsupp på varje möte och varit en del av vårt Trello-board ända från iteration ett.Anledningen till att jag som testledare inte hade fler testexempel tidigare ellerhöll i testskolan tidigare var att även jag var helt obekant med tester i börjanav projektet.

F.7 SlutsatserDe viktigaste typerna av tester för vårt projekt har varit enhets- och integra-tionstester eftersom det är de som har använts mest och hittat flest buggar. Föratt kunna dra en bättre slutsats skulle fler tester av alla olika typer behövtsskrivas.

Om vi fick chansen att göra om projektet skulle vi se till att lägga fokus påtestning från början. Ett exempel är att från början skriva koden med tankenatt funktionerna ska enhetstestas. Då kommer kodstrukuren att bli bättre vilketkommer göra det enklare att fortsätta skriva tester under hela projektet. Entanke kan även vara att dokumentera alla buggar som upptäcks av tester för attöka motivationen till att skriva tester.

En annan fördel med att lägga fokus på testning i början av projektet är attdet gör det enklare för utvecklare som är ovana med tester att skriva tester.Testledaren har ett stort ansvar att se till att testningen utförs, t.ex. genom attta upp det på möten eller införa en regel att varje funktion som skrivs måstetestas innan det får mergeas med master.

64

65

F.8 Figurappendix för individuell del F

Figur 20: Hur mycket kunskap hade du om tester innan projektet började?

Figur 21: Hur många enhetstester har du skrivit under projektets gång?

Figur 22: Hur många integrationstester har du skrivit under projektets gång?

66

Figur 23: Hur många timmar har du totalt lagt ned på att skriva tester (förutomacceptanstester) under projektets gång?

Figur 24: Med hur många minuters mellanrum i genomsnitt kör du testprogrammetpy.test medan du programmerar?

Figur 25: Hur stor andel merge requests kontroller du med py.test innan du godkännerdem?

67

Figur 26: Vad har varit det största problemet med att skriva tester för dig?

Figur 27: Vad skulle fått dig att skriva fler tester?

68

Figur 28: Vad kunde testledaren ha gjort för att motivera dig till att skriva fler tester?

69

G Är LATEX ett lämpligt verktyg för projektgrup-per

En utredning skriven av Hanna Müller, analysansvarig i Grupp 8 i kursenTDDD96, vid Linköpings universitet.

G.1 InledningOavsett vilken utvecklingsmetodik som projektgrupper väljer att använda kom-mer dokumentation att spela en betydande roll för produktens framgång [46].Projektgrupper förväntas ofta tillhandahålla dokument långt innan gruppenbörjar med att bygga själva produkten. Det kan röra sig om allt från kontrakt tilldiverse designdokument, specifikationer och beskrivningar. Dokumenten hjälperalla involverade att få en klar bild över hur projektet ska genomföras. Välar-betade dokument minskar riskerna för fel och bidrar till ökad effektivitet i allafaser av ett projekt [46]. I större projektgrupper där flera medlemmar bidrar tilldokumentationen är risken överhängande att dokumenten upplevs som osam-manhängande eftersom alla har olika smak och preferenser när det kommer tilldokumentutformning. Även om en viss standard bestäms gemensamt blir det lättatt dokumentutformningen upplevs som inkonsekvent. Det ger en oprofessionelloch slarvig bild för utomstående. Det är viktigt att projektgrupper presenterarprojektet och dess dokumentation på ett professionellt sätt för att bli tagnapå allvar. För att undvika bristfällig dokumentation är det betydelsefullt atteftertanke ägnas kring val av de verktyg som ska användas vid dokumentering.

G.1.1 Syfte

Rapporten tjänar till att redogöra för de lärdomar som projektgruppen gjortkring val av verktyg för den dokumentering som gruppen hade krav på sig atttillhandahålla.

G.1.2 Frågeställning

Frågeställningarna som texten avser att behandla är följande:

• Vilka är fördelarna och nackdelarna med att använda LATEX jämfört medGoogle Documents?

• Är den inlärningskurva som krävs för att lära sig använda LATEX rimlig ijämförelse med mer intuitiva WYSIWYG-ordbehandlare?

• Vilka ändringar i val av dokumentationsverktyg skulle jag ha föreslagitom vi gjorde om projektet?

G.2 BakgrundProjektet inleddes under våren 2016 som en del i kursen TDDD96. I projekt-gruppen ingick nio personer som alla tilldelades olika ansvarsområden. Underprojektets gång fanns det krav på att ett antal dokument skulle skrivas. Allavar överens om att använda ett verktyg som stödde att flera personer kunde

70

redigera dokumenten samtidigt, det stod mellan LATEX och Google Documents.I förstudien valde projektgruppen att använda Google Documents, där även vissversionshantering finns. När arbetet med att skriva denna rapport inleddes villeflera i gruppen istället övergå till att arbeta i LATEX. Följden blev att det arbetetmed de återstående dokumenten fortsatte med hjälp av ShareLaTeX.

G.3 TeoriDet finns ett flertal verktyg att välja bland när det kommer till att förberedadokument. I detta avsnitt finns information om LATEX, ShareLaTeX och GoogleDocuments. Varav de två sist nämna verktygen var de som användes i dettaprojekt.

G.3.1 LATEX

LATEX är ett system som används för att underlätta vid beredning av dokumentoch bygger på typsättningsystemet TEX från 1978 [47][48]. /TeX skapades ILATEX skriver användaren oredigerad text, vilket innebär att den text använda-ren skriver inte gör något anspråk på att representera det slutgiltiga resultatet.Användaren får istället beskriva innebörden av texten och använda olika marke-ringar för att utforma dokumentet, vilket senare formateras av LATEX [48]. Dettatillvägagångssätt skiljer sig avsevärt från ordbehandlare där textens slutgiltigaformatering visas direkt på skärmen under tiden användaren skriver, vilket oftarefereras till som “what you see is what you get” (WYSIWYG). Målet med LATEXär att tillåta författaren av dokumentet tänka så lite som möjligt på layout ochistället fokusera på textens innehåll [49].

ShareLaTeXShareLatex är en webbaserad editor för LATEX som syftar till att underlätta försina användare. Användaren slipper installera något som helst program på sindator. Applikationen finns som gratisvariant och som betalvariant. I gratisver-sionen har användaren möjlighet att skapa privata och publika projekt, stav-ningskontroll, realtidssamarbete mellan projektmedlemmar och kompilering tillPDF direkt i applikationen. Som betalande användare får användaren även möj-lighet att spåra ändringar och att synkronisera med både Dropbox och GitHub[50].

G.3.2 Google Documents

Google Documents är en fri webbaserad ordbehandlare som tillhandahålls avGoogle. En användare loggar in med sitt Google-konto och får möjlighet attskapa och redigera dokument online. Flera användare kan komma åt dokumentoch redigera dessa i realtid. I dokumentet markeras de olika användarna meden markör för att indikera var i dokumentet var och en skriver. Det finns ävenmöjlighet att lämna kommentarer i dokumentet för att underlätta diskussio-ner mellan användarna [51]. Google Documents är en ordbehandlare i stil medMicrosoft Word fast med färre funktioner.

G.4 MetodFör att besvara frågeställningarna har projektgruppen arbetat med olika verk-

71

tyg i de olika faserna projektet genomgått, dvs. förstudie, iteration 1, iteration2 och iteration 3. I förstudien sköttes all dokumentation med hjälp av Goog-le Documents och filerna sparades gemensamt på Google Drive. När arbetetmed kandidatrapporten skulle inledas togs beslutet att använda verktyget Sha-reLaTeX framför Google Documents. Ett beslut som togs med hänsyn till denbegränsade kunskap gruppmedlemmarna hade gällande LATEX (endast fem avprojektdeltagarna hade tidigare använt sig av LATEX) samt det faktum att detendast fanns ett dokument kvar att färdigställa. Hade vi haft fler dokument attgöra klart hade vi möjligtvis valt bort ShareLaTeX och använt LATEX. För attupptäcka inkonsekvenser mellan de olika dokumenten så kommer dokument somskrivs av olika personer men med samma verktyg jämföras. Det vill säga att dedokument som skrivits med hjälp av Google Documents jämförs med varandraoch i detta dokument, som skrivits med hjälp av ShareLaTeX, jämförs de indi-viduella delarna med varandra.

För att fånga upp projektmedlemmarnas åsikter har en enkät sammanställtsmed frågor som är avsedda att få fram data angående erfarenheter och åsik-ter kring de verktyg som använts i projektet. Eftersom frågeställningarna rörerfarenheter i detta projekt kommer endast projektmedlemmarna att delta ienkätundersökningen. Utöver det kommer jag att visa på exempel från doku-menten för att styrka mina åsikter i avsnittet Diskussion. Frågorna samtligagruppmedlemmar svarat på i enkäten är följande:

• Har du använt LATEX i något sammanhang innan du använde det i dettaprojektet?

• Vilka fördelar upplever du med Google Documents?

• Vilka fördelar upplever du med ShareLaTeX?

• Vilka nackdelar upplever du med Google Documents?

• Vilka nackdelar upplever du med ShareLaTeX?

• Hur skulle du uppskatta din kunskapsnivå när det kommer till LATEX?

• Hur många timmar har du uppskattningsvis använd ShareLaTeX i dettaprojekt?

• Om du skulle välja ett verktyg för dokumentation i ett framtida projekt,vad skulle du sannolikt välja?

G.5 ResultatI detta avsnitt presenteras de resultat som undersökningarna i detta projekt harlett till.

G.5.1 Dokumentformatering

De dokument som projektgruppen har producerat med hjälp av Google Docu-ments (projektplan, kravspecifikation, kvalitetsplan, testplan och arkitekturdo-

72

kument) har rent stilmässigt varierat mycket. I projektet har olika roller an-svarat för olika dokument, exempelvis har gruppens analysansvarige ansvaratför kravspecifikationen och testansvarig för testplanen. Utöver detta utsågs endokumentansvarig som varit aktiv i utformandet av alla dokumenten. Trots an-strängningar för att få dokumenten att likna varandra finns det många problemsom gör att dokumenten är oenhetliga. Exempelvis förekommer olika storle-kar på bildkommentarerna under figurer i dokumenten som skrivits med hjälpav Google Documents. Denna inkonsekvens återfinns inte bara mellan de olikadokumenten utan även mellan olika bildkommentarer i samma dokument. Ettannat exempel är att datumet i sidhuvudet i de olika dokumenten som skrivitsmed hjälp av Google Documents, har olika utformning. I figur 29 och 30 finnsde två olika versioner som förkommer bland de olika dokumenten. Datumen ärinkonsekvent placerade i jämförelse med linjen som markerar sidhuvudets slut.

Figur 29: Headerformatering från kvalitetsplan

Figur 30: Headerformatering från Arkitekturdokument

Det finns även problem när en tittar på dessa dokuments sidfötter. I figur 31visas en sidfot som finns i bland annat projektplanen och figur 32 visar hurtitelsidans sidfot ser ut på alla de dokument som skrivits i Google Documents.Det tredje exemplet på en sidfot som förekommer finns att beskåda i figur 33.Det finns alltså tre olika typer av sidfötter förekommande i de dokument somskrevs i inledningsfasen.

Figur 31: Footerformatering från projektplanen

73

Figur 32: Footerformatering från alla dokumentens titelsida

Figur 33: Footerformatering från Kvalitetsplanen

Vid granskning av de individuella delarna i detta dokument, som skrivits medhjälp av ShareLaTeX, upptäcktes inga skillnader i utformning.

G.5.2 Användarupplevelser

I gruppen hade fem personer använt LATEX innan det förekom som verktyg idetta projekt, se figur 34. Projektmedlemmarna upplevde både för- och nack-delar med de båda verktygen. Många av gruppens medlemmar upplevde attGoogle Documents starkaste sidor var att det fanns möjlighet att se ändringar irealtid så att man enkelt kan jobba flera stycken på samma dokument samt attdet är intuitivt att använda, se figur 35. Ingen speciell träning krävdes för attanvända Google Documents. ShareLaTeX upplevdes av de flesta i gruppen somsvårare att använda än Google Documents men sju personer nämnde i enkätenatt de tyckte att det var mer flexibelt när det gällde formatering samt att detupplevdes lättare att hålla en enhetlig formatering, se figur 38. Trots att fleraav projektets medlemmar lagt ner över 20 timmar på att arbeta med dokumenti LATEX upplever alla att de fortfarande är nybörjare och amatörer, se figur 39och figur 40.

I figur 41 kan man se att en person tycker att Google Documents är det bästaalternativet och skulle använda det i framtiden också. Resterande tycker attLATEX (olika val av editor) skulle vara det bästa alternativet.

G.6 DiskussionEfter att för första gången använd Google Documents i detta projektet uppleverjag precis som resterande medlemmar i gruppen att, även om Google Documentsär mycket intuitivt och lättanvänt så väger nackdelar som begränsande doku-mentutformning tungt. Flera gruppmedlemmar verkade vara frustrerade överatt dokumenten som skrevs med hjälp av Google Documents blir så fula trotsansträngningarna att få dom enhetliga och snygga. De positiva egenskaper somnämns i samband med Google Documents är att det är lätt för flera användareatt skriva samtidigt på samma dokument, att det är lätt och gratis att använda.Om man som användare prioriterar att ha multipel editering i realtid så finns

74

samma funktionalitet i gratisvarianten av ShareLaTex. Däremot är det svårtatt komma ifrån att LATEX är svårare att lära sig eftersom det är textbaserat.En ny användare måste aktivt söka upp information om hur ens de enklastesakerna genomförs. I de allra flesta ordbehandlare visas istället funktionalitetoch verktyg ofta grafiskt vilket gör det intuitivt och lätt för nya användare attfinna den funktion de söker. Jag upplevde trots detta att mindre tid lades nerpå att formatera denna rapport än de andra dokumenten som skrevs med hjälpav Google Documents. I denna rapport lade en person ner mycket tid på attformatera dokumentet och de andra använde de standarder som denna personhade lagt som ramverk.

Om man som användare prioriterar spårning av ändringar kan man heller in-te motivera ett val av Google Documents framför LATEX. Möjligheten finns juatt använda LATEX lokalt och ha en gemensam lagring på valfritt webbhotell förmjukvaruutvecklingsprojekt, då finns möjligheten att hålla översikt på ändrings-historik och i en mycket noggrannare form än vad Google Documents erbjuder.I fall en projektgrupp väljer att använda LATEX lokalt och ha gemensam lagringav filer via ett webbhotell kommer användarna inte att kunna se redigering avdokumentet i realtid. Då kan det vara nödvändigt att ha en lista med aktivitetersom gruppmedlemmarna kan utgå ifrån när de skriver på dokument. Detta ärviktigt för att undvika att flera arbetar på samma del samtidigt men att kommapå och skriva ner aktiviteter kommer även att innebära ett ytterligare momentför projektgruppen.

Flera gruppmedlemmar nämnde att kompileringen i ShareLaTeX var ett pro-blem, den var långsam och tyckte det var bättre med Google Documents därman kunde se ändringar direkt. I detta fall är det viktigt att komma ihåg attShareLaTeX inte är den enda editorn för LATEX. En användare av LATEX kanvälja fritt vilken editor som passar just dom och använda en separat pdf-läsareför att reducera kompileringstiden.

G.7 SlutsatserFördelarna med LATEX utifrån de förutsättningar och de behov denna projekt-grupp har haft är främst förenkligen av uniform dokumentutformning. Vilketvar ett stort problem när Google Documents användes. Det finns bara en fördelsom är värd att framhålla när det kommer till Google Documents och det är attingen speciell kunskap krävs för att använda det eftersom det är intuitivt ochliknar verktyg som så många är van vid.

Jag anser att alla som återkommande ägnar sig åt att skriva dokument bör tasig tiden att lära sig LATEX eftersom det underlättar så mycket. Jag kan inte seLATEX:s inlärningskurva som en så stor nackdel att det bör hindra någon frånatt lära sig det. När en användare väl vant sig vid det sättet att skriva dokumentpå så finns det inte längre några argument för att använda Google Documentsframför LATEX. I enkäten som besvarades av projektmedlemmarna ser vi att ba-ra en i gruppen skulle använda sig av Google Documents igen i ett liknandeprojekt, medan resten skulle använda Latex med viss variation i valet av editor.Detta gör att jag drar slutsatsen att den inlärningskurva som förknippas medLATEX är värd besväret enligt projektmedlemmarna också.

75

I framtiden kommer jag att förespråka LATEX. Jag anser att ShareLaTeX ärlämplig för mindre arbeten och rapporter eftersom det var snabbt och lätt attsätta upp ett dokument. För arbeten i storlek med detta projekt kommer jagatt ge rådet att använda LATEX lokalt. Varje projektmedlem får välja editor självoch så har vi en gemensam förvaringsplats för dokumenten. Jag kommer inteatt råda någon att använda Google Documents till någon typ av arbete.

76

G.8 Figurappendix för individuell del G

Figur 34: Gruppmedlemmarnas erfarenhet av LATEX

Figur 35: Fördelar med Google Documents enligt gruppens medlemmar

77

Figur 36: Fördelar med ShareLaTeX enligt gruppens medlemmar

Figur 37: Nackdelar med Google Documents enligt gruppens medlemmar

78

Figur 38: Nackdelar med ShareLaTeX enligt gruppens medlemmar

Figur 39: Gruppmedlemmars uppskattade kunskapsnivå

79

Figur 40: Gruppmedlemmars uppskattning av hur mycket tid de spenderat och använtShareLaTeX

Figur 41: Gruppmedlemmars verktygspreferenser för framtida projekt

80

H Designmönstret MVCEn utredning skriven av Adam Nyberg, arkitekt i Grupp 8 i kursen TDDD96,vid Linköpings universitet.

H.1 InledningVid ett mjukvaruprojekt är det viktigt att skapa en bra struktur på mjukvaran.Detta gäller framförallt vid större grupper av människor eftersom strukturenpåverkar viktiga egenskaper så som utvecklingshastighet, underhållbarhet ochtestning.

Det finns flera olika väl etablerade arkitekturer man kan använda sig av när manska strukturera sin mjukvara. Den här utredningen gör en teoretisk jämförelsemellan några av alternativen och reflekterar över lärdomar av att använda sigav arkitekturen MVC.

H.1.1 Syfte

Syftet med den här utredningen är att undersöka ifall MVC är en lämpligt arki-tektur att använda sig av i projekt som liknar detta. Andra typer av arkitekturerkommer även undersökas och jämföras.

H.1.2 Frågeställning

De frågeställningar som den här utredningen tar upp är följande.1. Finns det något alternativ till MVC och vad har de för nackdelar och

fördelar?

2. Vad hade vi, med hänseende på arkitekturen, gjort annorlunda om pro-jektet hade gjorts om igen?

H.2 BakgrundI kursen TDDD96 Kandidatprojekt i programvaruutveckling valdes jag till ar-kitekt och tog då beslutet att använda arkitekturen MVC. Detta gjordes för attjag tidigare haft positiva erfarenheter av att använda MVC. Det är dock möjligtatt en annat arkitektur hade varit mer passande och det ska denna utredningenbesvara.

H.3 TeoriUnder denna rubrik beskrivs all teori och termer så att läsaren ska förstå restenav utredningen.

H.3.1 MVC

I detta mjukvaruprojekt har vi utgått från arkitekturen MVC (Model ViewController) när vi designade mjukvarans struktur [52].

81

MVC är en väl etablerat arkitektur som används vid mjukvaruutveckling avgrafiska gränssnitt [53]. Arkitekturen använder sig av tre olika koncept. Dessa ärdatastrukturer och logik (Models), grafiska komponenter (Views) och kontroller(Controllers).

Models används för att definiera hur data ska modifieras och dess datastruktu-rer. Konceptet Views ansvarar för den grafiska representationen av programmet.Controllers är själva navet i systemet. Det är Controllers som binder ihop sy-stemets data med dess grafiska representation. I figur 42 visas en översikt överMVC.

Figur 42: MVC arkitektur

H.3.2 Multitier arkitektur

Multitier arkitektur eller även kallat N-tier arkitektur bygger på att man struk-turerar sitt system i olika lager. Dessa lager har då separata ansvarsområden.Ett lager ska då maximalt kommunicera med två andra lager. På så sätt blirdet enkelt att byta ut ett lager vid behov.

Ett exempel på hur multitier kan ses i figur 43. Figuren innehåller tre olika lagersom har ansvar för olika delar av systemet. På grund av att det är olika lageroch hur de kommunicerar så kan datalagret bytas ut utan att ändringar i dengrafiska representationen behöver göras.

H.4 MetodFörst gjordes en teoretisk jämförelse mellan olika alternativ för hur man struk-turerar mjukvaran för en grafisk applikation. Detta gjordes genom att jämföraolika generella fördelar och nackdelar men även genom att sätta dessa för- ochnackdelar i relation till vårt projekt.

Utöver den teoretiska jämförelsen så noterades även problem som uppstod un-der projektets gång. När problem uppstod så diskuterades en lösning fram med

82

Figur 43: Multitier arkitektur

berörda personer i gruppen. Det gjordes även en utvärdering efter varje iterationdär projektgruppen tog upp problem relaterat till arkitekturen.

H.5 ResultatResultatet i den här utredningen är uppdelat i två olika delar. Först behandlasden teoretiska jämförelsen och sedan tas problem som har uppstått upp.

H.5.1 Teoretisk jämförelse

I den här teoretiska jämförelsen kommer fördelar och nackdelar för de olika ar-kitekturerna att presenteras. I tabell 2 och 3 presenteras fördelar och nackdelarför arkitekturen MVC respektive N-tier. [54]

H.5.2 Problem som uppstod

Vid förfrågning av gruppen framkom några generella problem. Till exempel varett vanligt problem att när man skulle implementera en ny del av applikationenså behövde man ändra på många ställen i koden.

Här listas alla problem som var relaterat till arkitekturen som uppstod underprojektets gång.

83

Tabell 2: MVC

Fördelar NackdelarArkitekturen har tydligt uppdeladeansvarsområden

Dataflödet i arkitekturen är kom-plext

Enkelt att göra unit tests för model-lerna

Affärslogik läggs enkelt i controllersvilket går emot de uppdelade an-svarsområdena

Views kan ändras utan att modeller-na eller controllers behöver ändras

Arkitekturen har en hög inlärnings-kurva

Gruppen hade tidigare erfarenhet

Tabell 3: N-tier

Fördelar NackdelarArkitekturen har tydligt uppdeladeansvarsområden

Vissa problem är svåra att begränsatill lager vilket gör att vissa beroen-den mellan olika lager kan uppkom-ma

Arkitekturen har enkelt och tydligtdataflöde

Eventuell överbryggning av lagerminskar modulariteten

Olika lager har enbart beroende avsina närmaste grannar

Om lagren är separerade med enbrygga som är seg kan prestandanbli lidande

1. När modulen som kommunicerar med kundens system skulle implemente-ras så var det svårt att bestämma hur den skulle passa in i arkitekturen.Efter diskussioner inom gruppen kom vi fram till att den modulen intepassade in i varken controllers, views eller models så modulen byggdesutanför MVC med en koppling till controllers.

2. Våra controllers innehåller mycket affärslogik och det går emot paradigmetatt controllers ska vara så minimala som möjligt.

H.6 DiskussionVal av arkitektur i ett mjukvaruprojekt är inte helt lätt att göra. Det är mångaparametrar som måste tas hänsyn till och varje projekt är annorlunda. Detbidrar till att det finns många olika varianter på arkitekturer. I vissa fall är detväldigt tydligt att avgöra om en arkitektur passar till ett projekt men det ärofta svårt att säga vilken arkitektur som är den bästa. Det finns dock ett antalvedertagna arkitekturer som är väl testade och mycket använda.

Vi valde att använda oss av arkitekturen MVC som grund när vi designadevårt system. Anledningarna till det valet var bland annat på grund av att folk igruppen hade tidigare erfarenhet av MVC. Det gjorde att uppstarten av arbetetgick mycket snabbare än om vi hade börjat utan förkunskaper. Det gjorde ävenatt utvärderingen av fördelar och nackdelar gick snabbt. En annan anledning

84

till varför vi valde MVC var för att det uppfyllde många av de krav vi hade påarkitekturen. Vi valde även att utvärdera arkitekturen N-tier. Det var ingen igruppen som hade någon erfarenhet av N-tier så det var direkt en parametersom lutade till MVCs fördel. Eftersom vi strävade efter att ha en så simpelarkitektur som möjligt så var det en fördel för N-tier på grund av att N-tier ärenklare uppbyggd.

Vid implementationen av MVC uppkom en del problem som vi ej hade resursereller tillräcklig kommunikation för att lösa. Ett av dessa problem är att enanvändaraktivitet i programmet aktiverar flera olika controllers som gör olikasaker med den aktiviteten. Det är inte bra eftersom det gör programmet mindremodulärt. Allt eftersom projektet fortlöpte så placerades mer och mer logik icontrollers i stället för models. Det kan bero på att arkitekten inte lyckadesmed att tydligt kommunicera hur programmet skulle struktureras. Möjlighetenfanns att omstrukturera systemet när vi upptäckte problemen men beslutet togsatt det inte var en prioritet över att få klart de funktioner som hade planerats.Till exempel hade man kunnat refaktorera koden så att problemen löstes ochsedan vara mer uppmärksamma på kod som bryter mot designmönstret vidkodgranskningarna.

H.7 SlutsatserNär man tar resultatet av den här utredningen i bejakande kan man kommafram till en slutsats för båda frågeställningarna i utredningen.

H.7.1 Finns det något alternativ till MVC och vad har de för nack-delar och fördelar?

Den här utredningen har tydligt presenterat i både teoridelen och resultatdelenatt det finns alternativ till MVC. Till exempel tas N-tier upp som ett alternativ iteoridelen. Utöver det presenteras fördelar och nackdelar i tabellen 3 i resultatet.

H.7.2 Vad hade vi, med hänseende på arkitekturen, gjort annorlun-da om projektet hade gjorts om igen?

Över lag så blev arkitekturen lyckad även om det finns vissa problem och lär-domar att dra. I nästa projekt borde arkitekten tydligare kommunicera arki-tekturen. Det är även viktigt att fokusera på att bygga systemet så enkelt sommöjligt för att fler ska kunna bidra i projektet.

85

I Val av utvecklingsmiljö vid mjukvaruutvecklingEn utredning skriven av Niklas Pettersson, dokumentansvarig i Grupp 8 i kursenTDDD96, vid Linköpings universitet.

I.1 InledningMjukvaruutveckling har upp till nutid nästan alltid handlat om kunskaper inomprogrammeringsspråk och kreativitet hos individer. Då utveckling, likt nästanallt annat i världen, görs bäst i grupper och med hjälp utav mer kunnandepersoner så har val av utvecklingsmiljöer och programmeringsverktyg, likt gener,ärvts vidare till nyblivande programmerare. Dessa ärvda val har visat sig varanäst intill religiösa då möten med individer som gjort helt annorlunda val avutvecklingsmiljöer ansetts främmande [55].

När ett val av utvecklingsmiljö sker så väljer utvecklaren ett verktyg i vilkethen ska presentera sina kunskaper och kreativa sidor för en kommande framtid.Detta val spelar en stor roll för den personliga utvecklingen samt slutproduktoch bör därför noggrant granskas så att ett felaktigt val inte görs [56].

I.1.1 Syfte

Utredningen syftar till att jämföra underliggande faktorer till hur ett val avutvecklingsmiljö går till. Dessa faktorer kommer sedan att värderas och reflek-teras över för att tillslut övergå till en slutsats om vilka faktorer som, baseratpå insamlad data, är viktigast.

I.1.2 Frågeställningar

Frågeställningen som utredningen avser att behandla är följande:• Vilka olika faktorer vid val av utvecklingsmiljö finns det som kan klassas

som nyckelfaktorer?

• Hur påverkar erfarenhet, storlek på projekt och kunskaper valet av ut-vecklingsmiljö?

I.2 BakgrundUnder första iterationen av projektet, i kursen TDDD96, så stod gruppmed-lemmarna inför ett val av utvecklingsmiljö som enligt några av dem tillsynessåg ut att vara ett väldigt enkelt val. Detta val skulle inte bara spegla deraspreferenser vad gäller estetik, utan även kunskap och tidigare erfarenheter inomprogrammering.

I tidigare kurser så har även liknande val gjorts, men då oftast med hjälp utavrekommendationer från universitetet och examinator. Det har då noterats attvissa studenter ter sig till samma utvecklingsmiljö väldigt ofta och att detta valförsvarats väldigt kraftigt.

86

I.3 TeoriNedan följer några stycken av information angående de viktiga teoridelar somutredningen senare kommer ta upp.

I.3.1 Refaktorisering

Refaktorisering, eller omstrukturering av kod, är en process där utvecklarenförsöker förbättra kvalitén på koden genom att strukturera om kodens placering.Genom detta kan en utvecklare åstadkomma mer lättläst kod och kod som ärlättare att underhålla samt vidareutveckla. Efter en refaktorisering ska kodensfunktionalitet inte förändras utan programmet ska fungera likadant som innan.Detta gör att refaktorisering med fördel görs stegvis och med små delar av kod[57].

I.3.2 Versionshantering

Versionshantering är när utveckling av kod sker med hjälp av ett system somkänner till förändringar i kod och kan återställa filer, eller delar av filer, tilltidigare versioner [58].

I.3.3 Inspektion av kod - inbyggda inspektioner

Vid inspektering av kod, vanligtvis kallat Code Inspections, så granskas kodenmed avseende på olika apsekter som t.ex. stavfel, felskrivningar och generellkvalité av kod. Vid dessa inspektioner så får utvecklaren ofta återkoppling ochtips på hur eventuella förbättringar skulle kunna se ut. Oftast följer dessa tipsnågon form av standard, t.ex. PEP8 för programmeringsspråket Python [59, 60].

I.3.4 Integrated Development Enviroment

Ordet IDE är en förkortning för Integrated Development Enviroment och betyderintegrerad utvecklingsmiljö. Vanligtvis innehåller en IDE en textredigerare, enkompilator och en debugger samt några extra funktioner som underlättar vidprogrammering. Dessa utvecklingsmiljöer tillgodoser oftast en utvecklare medbåde testnings-möjligheter och omstrukturering av kod på ett väldigt enkelt ocheffektivt sätt för att underlätta kodskrivandet för användaren [61].

I.3.5 Text editor

En text editor, eller textredigerare på svenska, är en typ av program gjort förskrivandet och redigering av text (i detta fall kod). En text editor har i många fallinga fler inbyggda funktioner än ett vanligt ordbehandlingsprogram, vilket göratt utveckling av kod oftast kombineras med en kompilator och debugger i formav ett terminalfönster. Undantag där en text editor har valbar funktionalitetsom liknar en IDE finns givetvis, men dessa tenderar till att i slutändan intetillgodose en utvecklare med samma funktionalitet som en IDE [62].

87

I.4 MetodDå användning av IDE’s tidigare har skett så kan erfarenheter, och kunskapersom kom fram utav det, jämföras mot nya sådana som tillförs gruppen ochindivider i detta projekt då ännu ett byte av har skett. Dessa jämförelser kansedan korsrefereras med vad publicerade artiklar och tidskrifter sagt i frågankring val av utvecklingsmiljöer samt vilka faktorer som kan spela in. En enkät,angående deras preferenser vid val av utvecklingsmiljö, kommer att skickas tillgruppmedlemmarna. Där kommer data samlas in som t.ex. faktorer vid valet,hur många alternativ de egentligen valde mellan, och hur nöjda de är med sittval.

Under första iterationen av projektet kommer utveckling av kod, för endast ut-redaren, att ske med hjälp utav en text editor vid namn Atom [63]. Därefter,under den andra iterationen, kommer ett byte ske till en IDE, närmare bestämtPyCharm [64]. Detta byte kommer förhoppningsvis att generera både positivaoch negativa egenskaper vad gäller utvecklandet vilket kan noteras och sedananvändas som grund i resultat och slutsatser. Under sista iterationen, den tred-je av dem, så kommer utveckling ske i valbar utvecklingsmiljö. Valet av denutvecklingsmiljön kommer helt och hållet bygga på vad som, under tidigareiterationer, visat sig bäst lämpat och vilka faktorer som ansetts vara viktigaför projektet. Processen för att utvärdera och välja utvecklingsmiljö för sistaiterationen kommer att följa nedanstående steg [65].

1. Skapa utvärderingsplan.

2. Definera faktorer och krav.

3. Genomför utvärdering.

4. Gör ett val.

5. Presentera valet.

Anledningen till dessa byten av utvecklingsmiljö var att preferenser för utveck-lingsmiljöer ändrades under projektets gång. Första valet, Atom, var ett in-fluerat val som enbart byggde på vetskapen av att utvecklingsmiljön såg braut och att det var en känd utgivare som skapat utvecklingsmiljön. Det andravalet, PyCharm, grundade sig på enkla preferenser i form av vilken utgivarenav utvecklingsmiljön var och ett antal faktorer. Dessa faktorer var vetskapenav att utvecklingsmiljön hade tillgång till inspektering av kod och testnings-möjligheter inbyggt direkt i programmet.

88

I.5 ResultatUnder iteration 3 genomfördes en undersökning i projektgruppen angående de-ras val av utvecklingsmiljö. Denna undersökning gjordes genom att gruppmed-lemmarna fick svara på en enkät med fyra olika frågor; tre stycken flervals-frågoroch en där gruppmedlemmen, kortfattat, fick utvärdera sin tid spenderad medden utvecklingsmiljö som de själva valt. Enkätens resultat var enligt följande:

Fanns det några faktorer som gjorde ditt val enklare?• Ja (87,5 %).

• Nej (12,5 %).

Markera de faktorer som förenklade, eller som spelade större roll för, ditt val.Markera inte faktorer som är eventuella tillägg som INTE finns med i standard-versionen av utvecklingsmiljön.

• Styling av editor (37,5 %).

• Hjälpmedel för testning (12,5 %).

• Inspektering av kod (25 %).

• Automatiskt komplettering av kod (50 %).

• Hjälpmedel för versionshantering (12,5 %).

• Refaktorisering av kod (75 %).

• Tydlig översikt av alla filer (62,5 %).

• Debugging och körning av kod (25 %).

• Varningar direkt när du skriver fel (50 %).

• Annan: Van vid miljön (12,5 %), grupptryck (25 %), indentering (12,5 %),rekommendationer (25 %), välkänt program (12,5 %).

Är du nöjd med din nuvarande utvecklingsmiljö? Skriv (kortfattat) vad du gil-lar/saknar. (Svaren är sammanfattade och sorterade på svarsfrekvensen)

• Gillar: Översikten för filer, fel visas tydligt, utseende, simpelt utan onö-diga funktioner, starttiden, enkel ihopkoppling med tillägg, sökfunktion,flertalet öppna filer, navigering mellan filer, automatisk komplettering, re-faktorisering, bra snabbkommandon.

• Saknar: Startar långsamt, krångliga snabbkommando, refaktorisering.

Tror du att det hade varit bättre om du följt en mall eller punktlista när dugjorde ditt val, dvs noga granskat vad de olika utvecklingsmiljöerna faktiskt erbjödgenom någon strukturerad process?

• Ja (25 %).

• Nej (75 %).

• Gjorde något liknande vid mitt val (0 %).

89

Vid val av utvecklingsmiljö inför den sista iterationen skapades en simpel ut-värdering för att säkerställa att ett genomtänkt val gjorts. Denna utvärderinggenererade följande resultat:

1. Utvärderingsplan skapad

2. Viktiga faktorer och krav: Översikt av filer, refaktorisering, inspekteringav kod, sökfunktion bland funktioner och variabler, automatisk komplet-tering, ingen kostnad (finns gratisversion).

3. Utvärdering genomförd (se Tabell 4).

4. Val av utvecklingsmiljö gjort.

5. Enligt Tabell 4 så uppfyller PyCharm kraven ifrån utvärderingen och detär även den utvecklingsmiljön som är vald efter utvärderingen.

Tabell 4: Utvärdering av utvecklingsmiljöer

Faktorer Atom PyCharm Komodo IDLEÖversikt av filer Ja Ja Ja NejRefaktorisering Nej Ja Ja NejInspektering av kod Nej Ja Ja NejInbyggd sökfunktion Ja Ja Ja JaAutomatisk komplettering Nej Ja Ja JaKostnad (gratisversion finns) Ja Ja Nej Ja

För att hitta nyckelfaktorer vid val av utvecklingsmiljöer så kan man antingenvälja att granska de faktorer som, enligt ovanstående resultat ifrån enkätun-dersökningen, styr ens val eller de faktorer som i slutändan gör en utvecklarenöjd med sitt val. Enligt tidigare undersökningar så hävdas det dock att ettföretag, eller projektgrupp, gynnas av att genomgå en process vid utvärderingav deras olika möjligheter då ett val ska göras [65]. Tanken med detta är atttidigt upptäcka för- och nackdelar med de olika valen samt att influenser ochfaktorer, som kanske inte vore lika logiska att använda sig av vanligtvis, kommertill kännedom. Man kan även hävda att en nybörjare inom programmering fallerinom ramarna av utvecklare som borde genomgå en liknande process som ovanvid sitt val istället för att fråga andra, kunnigare, utvecklare då dessa tenderartill att vara väldigt passionerade och opartiska angående sina val och preferenser[55].

Vid utveckling av mjukvara vid t.ex. stora företag så är faktorer och influenservid ett val väldigt annorlunda gentemot när en ensam programmerare ska väljaut en ny utvecklingsmiljö [56, 65]. Detta beror på att krav på t.ex. testningsmöj-ligheter, inbyggda verktyg för att åstadkomma en bra test-miljö, direkt infinnersig vid storskaliga utvecklingsprojekt. Även politiska och affärsmässiga faktorerkan vara viktiga att ta i aktning.

90

I.6 DiskussionVid betraktande av resultatet, som presenterats tidigare i utredningen, så kanett antal viktiga observationer dykas djupare i. Det faktum att faktorer somtestning, versionhantering och debugging samt körning av kod inte alls verkadevara en viktig faktor, för dem som svarat på enkäten, tyder på en viss diskrepans.En utvecklingsmiljö, speciellt en IDE, har i princip i syfte att tillgodose dessafunktioner till en utvecklare till skillnad ifrån en text editor. Detta kan dockbero på att testning och versionshantering skett på ett annat sätt än inbyggt ien utvecklingsmiljö vilket bör visas på resultatet i enkäten. I detta fall, i dennaprojektgrupp, var det en liknande situation som rådde. Testning skedde medhjälp utav ett separat verktyg och samma gällde för versionshanteringen. Dåindivider, som svarade på enkäten, kanske visste om detta innan så var denfaktorn inte lika viktig, rent sagt utav obetydlig, i deras val.

Det bör även noteras att en tydlig översikt för sitt projekt, likt figur 44, varen väldigt viktig faktor enligt enkäten. Då en utvecklare har bra översikt ochtydligt ser sina filer, klasser och kataloger samtidigt som de programmerar kande både navigera mellan flera filer och granska koden, som är skriven i de olikafilerna, väldigt enkelt. Dock bör det tilläggas, baserat på observationer vid denegna utredningen kring val av utvecklingsmiljö och tidigare erfarenhet visar, attnästintill alla IDE’s och text editor’s tillgodoser en utvecklare med en tydligöversikt likt figur 44.

Figur 44: Översikt av filer vid ett pågående projekt

Samma verkar också råda då det gäller refaktorisering. Enligt enkäten så tyckte75 % att detta var en viktig faktor vid deras val. Det verkar dock inte som

91

att detta återspeglas i vad som senare gjort utvecklaren nöjd med sin utveck-lingsmiljö vilket är en aning konstigt. Det baseras förmodligen på att gruppeninte sysslat med så mycket refaktorisering såvida det inte skett på eget bevåg.Vanligtvis brukar man ha en period där gruppen dedikerar tid till att enbartrefaktorisera för att öka kvalitén på produkten som skapas.

I.7 SlutsatserI och med det resultat som presenterats, och vilka faktorer som enkätsvarandehar angett, så bör refaktorisering av kod och att utvecklingsmiljön ger en tydligöversikt över filer anses som nyckelfaktorer vid val av utvecklingsmiljö. Dettatorde betyda att en IDE är att föredra framför en text editor eftersom majo-riteten av text editorer inte har refaktorisering inbyggt. Förmodligen är dettanågot som går att lösa med hjälp av något tillägg i utvecklingsmiljö vilket fåren text editor att bete sig likadant som en IDE.

Vidare bör även sägas att baserat på tidigare erfarenheter, och hur stort ettprojekt är, så varierar faktorerna. Det nämndes tidigare att t.ex. företag harmycket högre krav på sina utvecklingsmiljöer än vad en ensam programmerarehar. Betydelsen av detta är alltså att ju mer erfaren en programmerare är ochju mer kvalitets- och testningskontroller som utvecklaren kommer arbeta med,desto fler och hårdare krav kommer utvecklaren ställa på sin utvecklingsmiljö.

Det verkar som om ett val av utvecklingsmiljö inte alltid granskas innan detgörs. Sett till resultatet och diskussionen, tidigare presenterat i utredningen, såanses det inte nödvändigt att göra valet till en mera noggrann process. Frågan ärom det på grund utav att en utvecklare inte har så höga krav, eller att det ansesonödigt då de flesta utvecklingsmiljöer är så pass snarlika, eller att det berorpå att utvecklaren ofta väljer den utvecklingsmiljö som är mest känd (användav andra). Det verkar dock, baserat på den egna utredning av valet, som attdet beror på att många utvecklingsmiljöer är väldigt likadana och att valet avutvecklingsmiljö i slutändan inte spelar någon större roll. Utvecklingsmiljöernaerbjuder nästan samma sak och de är garanterat suberba att använda nästanallihop. Det viktiga är att välja en som man själv känner sig nöjd med [55].

92

Referenser[1] Ericsson. Company facts - Ericsson. 2015. url: http://www.ericsson.

com/se/thecompany/company_facts (hämtad 2016-02-19).[2] Ericsson. Ericsson GSM Radio Access Network. url: http : / / www .

ericsson.com/ourportfolio/products/gsm-radio-access-network?nav=productcatagory006%7Cfgb_101_0517 (hämtad 2016-02-26).

[3] -. Ericsson Traffic Exploration. url: http://www.ericsson.com/TET/trafficView/loadBasicEditor.ericsson (hämtad 2016-05-26).

[4] K. Sutherland J. Schwaber. Scrumguiden. 2013. url: http : / / www .scrumguides.org/docs/scrumguide/v1/Scrum-Guide-SE.pdf (hämtad2016-05-06).

[5] M. Cohn. Scrum methodology and project management. url: https://www.mountaingoatsoftware.com/agile/scrum (hämtad 2016-05-06).

[6] I. Jacobson. ALPHA State Cards | Agile Software Development. url:https : / / www . ivarjacobson . com / alphastatecards (hämtad2016-05-23).

[7] GSM:Global System for Mobile communications. url: http : / / www .4gamericas.org/en/resources/technology-education/gsm/ (häm-tad 2016-05-06).

[8] J. Scourias. Overview of GSM:The Global System for Mobile. Tekn. rap-port. University of Waterloo, mars 1996. url: http://www.quut.com/berlin/gsm/js-intro.html.

[9] Python. About python. url: https://www.python.org/about/ (hämtad2016-04-18).

[10] Qt. LanguageBindings - PySide. url: https://wiki.qt.io/Category:LanguageBindings::PySide (hämtad 2016-04-18).

[11] Qt. About Qt. url: https://wiki.qt.io/About_Qt (hämtad 2016-04-18).[12] Qt Designer. Qt Designer Manual. url: http://doc.qt.io/qt-4.8/

designer-manual.html (hämtad 2016-04-18).[13] D. Radigan. A brief introduction to kanban. url: https : / / www .

atlassian.com/agile/kanban (hämtad 2016-04-21).[14] Peipman. G. Why to avoid fat controllers. 31 maj 2015. url: http :

//gunnarpeipman.com/2015/05/why-to-avoid-fat-controllers/(hämtad 2016-05-11).

[15] Wacker. M. You should unit test your controller, NOT! 16 juni 2013. url:http://googletesting.blogspot.se/2015/04/just- say- no- to-more-end-to-end-tests.html (hämtad 2016-05-11).

[16] Tibi. A. Just Say No to More End-to-End Tests. 22 april 2015. url:http://www.adamtibi.net/06-2013/you-should-unit-test-your-controller-not (hämtad 2016-05-11).

[17] P. Kiefer, U. Schmitt och J.A. Vorholt. eMZed: an open source frameworkin Python for rapid and interactive development of LC/MS data analysisworkflows. 2013. url: https://bioinformatics.oxfordjournals.org/content/early/2013/03/04/bioinformatics.btt080.full (hämtad2016-05-10).

93

[18] J. McLoone. Code Length Measured in 14 Languages. 2012. url: http://blog.wolfram.com/2012/11/14/code-length-measured-in-14-languages/ (hämtad 2016-05-10).

[19] D. Garey och S. Lang. High Performance Development with Python. 2008.url: http://www.scientificcomputing.com/articles/2008/11/high-performance-development-python (hämtad 2016-05-10).

[20] M. Arvola. Interaktionsdesign och UX. Studentlitteratur, 2014. Kap. 4.isbn: 978-91-44-09764-0. url: https://www.studentlitteratur.se/#9789144097640/Interaktionsdesign+och+UX/.

[21] Heuristic Evaluation. url: http : / / www . usabilityfirst . com /usability-methods/heuristic-evaluation/ (hämtad 2016-05-08).

[22] Emily Esposito. How to Calculate Productivity at All Levels: Employee,Organization, and Software. 9 dec. 2015. url: https://www.smartsheet.com/blog/how-calculate-productivity-all-levels-organization-employee-and-software (hämtad 2016-05-08).

[23] Company:CPRIME. What is agile? What is Scrum? url: https://www.cprime.com/resources/what- is- agile- what- is- scrum/ (hämtad2016-04-21).

[24] Scrum process image. 2016. url: https://commons.wikimedia.org/wiki/File:Scrum_process.svg (hämtad 2016-05-26).

[25] H. Kniberg. Kanban vs Scrum: How to make the most of both. 2009. url:https://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf (hämtad2016-04-20).

[26] C. Bradley. Kanban vs. Scrum: Kanban is NOT for Software Develop-ment, but Scrum is! 2013. url: https://scrumcrazy.wordpress.com/2013/02/04/kanban- vs- scrum- kanban- is- not- for- software-development-but-scrum-is/ (hämtad 2016-04-21).

[27] J. Scouller. The Three Levels of Leadership: How to Develop Your Lea-dership Presence, Knowhow and Skill. Management Books 2000 Ltd, 2011.isbn: 978-1852526818.

[28] Flavius S, tef. Team Leaders and Scrum Masters. 2013. url: http : / /mozaicworks.com/blog/team-leaders-and-scrum-masters (hämtad2016-04-21).

[29] S. Pope. Team Leader Workbook. HRD Press, Inc., 2008. isbn: 1599961334.url: https : / / books . google . se / books / about / Team _ Leader _Workbook.html?id=SM9uW41eKB4C&redir_esc=y.

[30] F. Ciccozzi. Introducing SCRUM into a Distributed SoftwareDevelopmentCourse. 2015. url: https://www.researchgate.net/publication/282152168 _ Introducing _ SCRUM _ into _ a _ Distributed _ Software _Development_Course (hämtad 2016-05-09).

[31] M. Uljens. Fenomenografi: forskning om uppfattningar. Lund: Studentlit-teratur, 1989. isbn: 91-44-29061-6.

[32] T. Huston. What is Code Review? url: https://smartbear.com/learn/code-review/what-is-code-review/ (hämtad 2016-05-05).

94

[33] L. Torvalds. Re: Kernel SCM saga.. 2005. url: http://marc.info/?l=linux-kernel&m=111288700902396 (hämtad 2016-05-09).

[34] R. Pressman. Software Engineering, a Practitioner’s Approach. 1982. url:http://mylibrary.carsu.edu.ph:8081/xmlui/bitstream/handle/123456789 / 215 / softwareengineering - pressman - 100829093911 -phpapp01.pdf (hämtad 2016-04-19).

[35] J. Cohen. 11 proven practices for more effective, efficient peer code review.2011. url: http://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ (hämtad 2016-04-20).

[36] A. Bacchelli och C. Bird. Expectations, Outcomes, and Challenges ofModern Code Review. 2013. url: http://sback.it/publications/icse2013.pdf (hämtad 2016-04-20).

[37] S.W. Ambler. Results from the November 2012 Agile Testing Survey. 2012.url: http://www.ambysoft.com/surveys/agileTesting201211.html(hämtad 2016-05-11).

[38] Unit testing. 4 jan. 2011. url: http://softwaretestingfundamentals.com/unit-testing/ (hämtad 2016-05-07).

[39] Integration testing. 3 jan. 2011. url: http : / /softwaretestingfundamentals.com/integration-testing/ (hämtad2016-05-07).

[40] System testing. 2 jan. 2011. url: http : / /softwaretestingfundamentals . com / system - testing/ (hämtad2016-05-09).

[41] Acceptance testing. 1 jan. 2011. url: http : / /softwaretestingfundamentals . com / acceptance - testing/ (häm-tad 2016-05-09).

[42] Regression testing. url: http : / / stackoverflow . com / questions /520064 / what - is - unit - test - integration - test - smoke - test -regression-test (hämtad 2016-05-09).

[43] pytest: helps you write better programs. url: http : / / pytest . org /latest/ (hämtad 2016-05-11).

[44] Pytest plugin for measuring coverage. url: https://pypi.python.org/pypi/pytest-cov/ (hämtad 2016-05-11).

[45] E. Hendrickson. ”Agile Testing - Nine Principles and Six Concrete Practi-ces for Testing on Agile Teams”. I: Quality Tree Software (11 aug. 2008),s. 6. url: http://testobsessed.com/wp-content/uploads/2011/04/AgileTestingOverview.pdf (hämtad 2016-05-10).

[46] D.L. Parnas. ”Precise Documentation: The Key to Better Software”. I:The Future of Software Engineering. Utg. av S Nanz. Springer Berlin Hei-delberg, 2011, s. 125–148.

[47] T. Oetiker. The Not So Short Introduction To LATEX 2ε. Free SoftwareFoundation, 2015. url: https://tobi.oetiker.ch/lshort/lshort.pdf.

[48] What are TeX and its friends? url: https://www.ctan.org/tex/(hämtad 2016-05-02).

95

[49] An introduction to LATEX. 2015. url: https://latex- project.org/intro.html (hämtad 2016-05-02).

[50] ShareLaTeX for Universities. url: https : / / www . sharelatex . com /university?ref=footer (hämtad 2016-05-11).

[51] Google Announces Google Docs & Spreadsheets. 2006-10-11. url: http://googlepress.blogspot.se/2006/10/google-announces-google-docs_11.html (hämtad 2016-05-11).

[52] I. Sarker och K. Zinnah. MVC Architecture Driven Design and Implemen-tation of Java Framework for Developing Desktop Application. 2014. url:http://www.sersc.org/journals/IJHIT/vol7_no5_2014/29.pdf(hämtad 2016-04-19).

[53] A. Karagkasidis. Developing GUI Applications: Architectu-ral Patterns Revisited. url: http : / / hillside . net /europlop / europlop2008 / submission / shepherd . cgi ? token =b9eff7c0e276092cf1925d6ba5be405a7518d9c2 & action = download &label=1209978492_10 (hämtad 2016-04-20).

[54] M Fowler. Patterns of Enterprise Application Architecture. Addison Wes-ley, 2002. isbn: 0321127420.

[55] J. O’dell. A Beginner’s Guide to Integrated Development Environments.2010. url: http : / / mashable . com / 2010 / 10 / 06 / ide - guide /#hO0kYOVCFuqR (hämtad 2016-04-21).

[56] J. Cogswell. Choosing an IDE That’s Right for You. 2015. url: http://insights.dice.com/2015/05/19/choosing-an-ide-right-for-you/ (hämtad 2016-04-21).

[57] M. Rouse. What is refactoring? 2006. url: http : / / searchsoa .techtarget.com/definition/refactoring (hämtad 2016-05-01).

[58] Git. Getting started - About version control. url: https://git- scm.com/book/en/v2/Getting-Started-About-Version-Control (hämtad2016-05-01).

[59] Jetbrains. Code Inspection. url: https://www.jetbrains.com/help/pycharm/2016.1/code-inspection.html (hämtad 2016-05-02).

[60] G. van Rossum, B. Warsaw och N. Coghlan. PEP8 - Style Guide ForPython Code. 2013-08-01. url: https://www.python.org/dev/peps/pep-0008/ (hämtad 2016-05-02).

[61] M. Rouse. What is integrated development environment? 2007. url:http : / / searchsoftwarequality . techtarget . com / definition /integrated-development-environment (hämtad 2016-05-23).

[62] A. Henry. Five Best Text Editors. 2014. url: http://lifehacker.com/five-best-text-editors-1564907215 (hämtad 2016-05-23).

[63] Atom. A hackable text editor for the 21st Century. url: https://atom.io/ (hämtad 2016-04-21).

[64] PyCharm. Python IDE for Professional Developers. url: https://www.jetbrains.com/pycharm/ (hämtad 2016-04-21).

96

[65] J. Odrowski. A Process for Evaluating and Selecting a Development En-vironment. url: http://www.cs.upc.edu/events/mpec/articles/odrowski.pdf (hämtad 2016-04-21).

97

J Utskrift från körning av enhets- och integra-tionstester med py.test

======================= test session starts =======================platform linux -- Python 3.4.3, pytest -2.9.1 ,

py -1.4.31 , pluggy -0.3.1rootdir: /home/projects/tddd96/tests , inifile:plugins: cov -2.2.1collected 70 items

tests/test_GraphicsController.py .............................................

tests/test_MainWindow.py ..tests/test_PopupController.py .............tests/test_TG_Cell.py .tests/test_TSSController.py ..tests/test_calls.py ...tests/test_connection.py .tests/test_menubar.py ...---------- coverage: platform linux , python 3.4.3-final -0 ---------Name Stmts Miss Cover-------------------------------------------------------------------actions.py 26 1 96%assets/AssetsManager.py 52 10 81%connection/__init__.py 0 0 100%connection/_commands.py 58 58 0%connection/_connection.py 61 42 31%connection/_parser.py 23 23 0%connection/helper.py 124 124 0%controllers/GraphicsController.py 330 79 76%controllers/MainController.py 89 19 79%controllers/PopupController.py 252 74 71%controllers/TSSController.py 170 45 74%controllers/__init__.py 0 0 100%main.py 13 13 0%models/__init__.py 0 0 100%models/basemodel.py 5 0 100%models/calls.py 17 2 88%models/cell.py 15 1 93%models/log.py 25 3 88%models/path_handler.py 57 37 35%models/phone_config.py 10 0 100%models/phones.py 62 12 81%models/towers.py 25 3 88%models/tss.py 16 0 100%views/MainWindow.py 340 26 92%views/__init__.py 0 0 100%views/mainUI.py 439 0 100%views/map/MapGraphicsView.py 68 23 66%views/map/__init__.py 0 0 100%views/ui/__init__.py 0 0 100%views/ui/popups/__init__.py 0 0 100%views/ui/popups/consol_ui.py 15 15 0%views/ui/popups/create_phone_config_popup.py 32 11 66%views/ui/popups/create_phone_config_popup_ui.py 123 0 100%views/ui/popups/help/about/about.py 7 3 57%views/ui/popups/help/about/about_ui.py 23 19 17%views/ui/popups/help/manual/manual.py 29 1 97%views/ui/popups/help/manual/manual_ui.py 34 0 100%views/ui/popups/log_ui.py 40 0 100%views/ui/popups/log_window.py 9 0 100%

98

views/ui/popups/path/path_popup.py 31 6 81%views/ui/popups/path/path_popup_ui.py 59 0 100%views/ui/popups/path/path_save_popup.py 10 0 100%views/ui/popups/path/path_save_popup_ui.py 30 0 100%views/ui/popups/phone_popup.py 9 0 100%views/ui/popups/phone_popup_ui.py 114 0 100%views/ui/popups/prompt_popup.py 16 0 100%views/ui/popups/prompt_ui.py 59 0 100%-------------------------------------------------------------------TOTAL 2917 650 78%==================== 70 passed in 4.40 seconds ====================

99

K Svar från stora enkäten

Figur 45: Gruppens upplevelse av kund

Figur 46: Gruppens syn på kundens påverkan på resultatet

100

Figur 47: Gruppens syn på effekten av kundens påverkan

Figur 48: Gruppens syn på en, teoretisk, större involvering av kund

101

Figur 49: Gruppens syn på kundens vision

Figur 50: Gruppens syn på spenderad tid för efterforsnkingar

Figur 51: Gruppens syn på relationen till kund

102

Figur 52: Gruppens syn på skapat värde för kund

Figur 53: Gruppens syn på MVCs begränsning

Figur 54: Gruppens syn på effekten av MVCs begränsning

103

Figur 55: Gruppens syn på ett, teoretisk, förslag för att använda MVC

Figur 56: Gruppens syn på upptagna kunskaper om GSM

Figur 57: Gruppens syn på hur lämpligt PySide var att använda

104

Figur 58: Gruppens förståelse av MVC-arkiteturen

Figur 59: Gruppens syn på möjligheter för vidareutveckling av Honeycomb

Figur 60: Gruppens syn på valet av att använda Python

105

Figur 61: Gruppens tekniska erfarenheter ifrån projektet

Figur 62: Gruppens användning av SEMAT för vägledning

106

Figur 63: Gruppens överblick av projektet vid använding av SEMAT

Figur 64: Gruppens prioritering vid använding av SEMAT

Figur 65: Gruppens upplevda stöd från använding av SEMAT

107

Figur 66: Gruppens tankar om SEMAT

Figur 67: Gruppens syn på högre använding av SEMAT

Figur 68: Gruppens syn på nyttan av att använda Stand-ups

108

Figur 69: Gruppens läsning av gjorda Stand-ups

Figur 70: Gruppens syn på för- och nackdelar av att använda Stand-ups online

109

Figur 71: Gruppens syn på anpassningsförmågan i de olika iterationerna

Figur 72: Gruppens syn på resultatet av att använda scrum

Figur 73: Gruppens syn på förutsättningarna i projektet

110

Figur 74: Gruppens syn på den gemensamma standarden

Figur 75: Gruppens syn på förståelsen i projektet

Figur 76: Gruppens syn på prestationen då scrum användes

111