Linköpings universitet
Linköpings universitet | Institutionen för datavetenskap
Examensarbete på grundnivå, 15hp | Datateknik
2016 | LIU-IDA/LITH-EX-G--16/040--SE
Simuleringsmiljö för mobila
nätverk
Simulation 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 Buffoni Examinator : Kristian Sandahl
Upphovsrätt
Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under 25 år frå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 enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att 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 i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt 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 eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida 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 to read, to download, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot 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 measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping Uni-versity Electronic Press and its procedures for publication and for assurance of document integrity, 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,
Sammanfattning
Denna rapport innefattar det arbete som nio studenter från kursen TDDD96: Kandidatprojekt i programvaruutveckling vid Linköpings universitet ägnat sig åt under vårterminen 2016. Projektet genomfördes med målsättningen att utveckla ett 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 ett projekt går från en beställning till en önskvärd leverans. Gruppen har arbetat i korta intervaller med täta möten och prioriteringslistor med aktiviteter. Re-sultatet hittills är en prototyp med interaktiv simulering via uppkoppling mot kundens servrar som bådar gott för fortsatt utveckling.
Tillkännagivanden
Stort 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ölja vårt arbete och komma med viktig input. Tack även till Björn som specificerat och kompletterat samma input!
All denna möda hade varit lönlös om det inte hade varit för vår vägvisare och beskyddare, Lena Buffoni, som i egenskap av gruppens handledare hållit arbetet på en stadig kurs under hela VT16, tack!
Innehåll
1 Inledning 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 1 1.4 Avgränsningar . . . 11.5 Definitioner, akronymer och förkortningar . . . 2
2 Bakgrund 3 2.1 Projektgruppens bakgrund . . . 4 3 Teori 5 3.1 Scrum . . . 5 3.1.1 Aktiviteter . . . 5 3.1.2 Roller . . . 5 3.1.3 Artefakter . . . 6 3.2 Kanban . . . 6
3.3 Semat Kernel ALPHA . . . 6
3.4 GSM . . . 7
3.4.1 Nätverksarkitektur . . . 7
3.4.2 GSM-simuleringar . . . 8
3.5 Model View Controller (MVC) . . . 8
3.6 Python, Pyside och Qt . . . 8
3.7 Tester och verktyg för testning . . . 10
4 Metod 11 4.1 Frågeställningar . . . 11
4.2 Datainsamling . . . 11
4.3 Utvecklingsmetodik . . . 13
4.4 Utvecklings- och organisatorisk miljö . . . 14
4.5 Metod för att fånga erfarenheter . . . 15
5 Resultat 16 5.1 Systembeskrivning . . . 16 5.1.1 Controllers . . . 16 5.1.2 Models . . . 16 5.1.3 Actions . . . 17 5.1.4 Views . . . 17 5.1.5 Connection . . . 17 5.1.6 Tester . . . 18
5.2 Gemensamma erfarenheter och lärdomar . . . 18
5.2.1 Python och Qt . . . 18
5.2.2 Kundkontakt . . . 18
5.2.3 SEMAT Kernel ALPHA:s . . . 19
5.2.4 Scrum . . . 19
6 Diskussion 21
6.1 Resultat . . . 21
6.1.1 Systemet . . . 21
6.1.2 Kundkontakt . . . 22
6.1.3 Scrum . . . 23
6.1.4 SEMAT Kernel ALPHA’s . . . 24
6.1.5 Tester . . . 24
6.2 Metod . . . 25
6.3 Arbetet i ett vidare sammanhang . . . 25
7 Slutsatser 27 7.1 Hur har Honeycomb implementerats så att ett värde skapats åt kunden? . . . 27
7.2 Vilka tekniska erfarenheter har gruppen fått från projektet? . . . 27
7.3 Vilket stöd har gruppen fått genom att använda SEMAT Kernel ALPHA:s? . . . 27
7.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 med
py.test 98
Figurer
1 Mobila användare per nätverksteknologi. Grafen är genererad
med hjälp av Ericssons Traffic Exploration [3] . . . 3
2 Översikt av GSM-nätverkets arkitektur . . . 7
3 Cellstruktur . . . 8
4 Hur PySide kopplar Python med Qt . . . 9
5 Honeycomb . . . 16
6 MVC-arkitekturen . . . 17
7 Scrums process, [24] . . . 39
8 Grupp 8 burn-down diagram . . . 41
9 Gruppens totala antal commits, iteration två . . . 42
10 Gruppens totala antal commits, iteration tre . . . 43
11 Gruppens granskningsprocess . . . 54
12 Har du genomfört en kodgranskning? . . . 57
13 Vad tittar du efter när du granskar kod? . . . 57
14 Hur snabbt granskar du kod? . . . 58
15 Har du granskat och godkänt kod som du känt dig osäker på? . . 58
16 Har du sett till att eventuella buggar/problem i kod du godkänt dokumenterats? . . . 58
17 Tror du att granskningsprocessen inom gruppen fungerat bättre om själva kodgranskningarna skedde efter ett protokoll? . . . 59
18 Hade du orkat följa en sådan checklista? . . . 59
19 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? 66 21 Hur många enhetstester har du skrivit under projektets gång? . . 66
22 Hur många integrationstester har du skrivit under projektets gång? 66 23 Hur många timmar har du totalt lagt ned på att skriva tester (förutom acceptanstester) under projektets gång? . . . 67
24 Med hur många minuters mellanrum i genomsnitt kör du test-programmet py.test medan du programmerar? . . . 67
25 Hur stor andel merge requests kontroller du med py.test innan du godkänner dem? . . . 67
26 Vad har varit det största problemet med att skriva tester för dig? 68 27 Vad skulle fått dig att skriva fler tester? . . . 68
28 Vad kunde testledaren ha gjort för att motivera dig till att skriva fler tester? . . . 69
29 Headerformatering från kvalitetsplan . . . 73
30 Headerformatering från Arkitekturdokument . . . 73
31 Footerformatering från projektplanen . . . 73
32 Footerformatering från alla dokumentens titelsida . . . 74
33 Footerformatering från Kvalitetsplanen . . . 74
34 Gruppmedlemmarnas erfarenhet av LATEX . . . 77
35 Fördelar med Google Documents enligt gruppens medlemmar . . 77
36 Fördelar med ShareLaTeX enligt gruppens medlemmar . . . 78
37 Nackdelar med Google Documents enligt gruppens medlemmar . 78 38 Nackdelar med ShareLaTeX enligt gruppens medlemmar . . . 79
40 Gruppmedlemmars uppskattning av hur mycket tid de spenderat
och använt ShareLaTeX . . . 80
41 Gruppmedlemmars verktygspreferenser för framtida projekt . . . 80
42 MVC arkitektur . . . 82
43 Multitier arkitektur . . . 83
44 Översikt av filer vid ett pågående projekt . . . 91
45 Gruppens upplevelse av kund . . . 100
46 Gruppens syn på kundens påverkan på resultatet . . . 100
47 Gruppens syn på effekten av kundens påverkan . . . 101
48 Gruppens syn på en, teoretisk, större involvering av kund . . . . 101
49 Gruppens syn på kundens vision . . . 102
50 Gruppens syn på spenderad tid för efterforsnkingar . . . 102
51 Gruppens syn på relationen till kund . . . 102
52 Gruppens syn på skapat värde för kund . . . 103
53 Gruppens syn på MVCs begränsning . . . 103
54 Gruppens syn på effekten av MVCs begränsning . . . 103
55 Gruppens syn på ett, teoretisk, förslag för att använda MVC . . 104
56 Gruppens syn på upptagna kunskaper om GSM . . . 104
57 Gruppens syn på hur lämpligt PySide var att använda . . . 104
58 Gruppens förståelse av MVC-arkiteturen . . . 105
59 Gruppens syn på möjligheter för vidareutveckling av Honeycomb 105 60 Gruppens syn på valet av att använda Python . . . 105
61 Gruppens tekniska erfarenheter ifrån projektet . . . 106
62 Gruppens användning av SEMAT för vägledning . . . 106
63 Gruppens överblick av projektet vid använding av SEMAT . . . 107
64 Gruppens prioritering vid använding av SEMAT . . . 107
65 Gruppens upplevda stöd från använding av SEMAT . . . 107
66 Gruppens tankar om SEMAT . . . 108
67 Gruppens syn på högre använding av SEMAT . . . 108
68 Gruppens syn på nyttan av att använda Stand-ups . . . 108
69 Gruppens läsning av gjorda Stand-ups . . . 109
70 Gruppens syn på för- och nackdelar av att använda Stand-ups online . . . 109
71 Gruppens syn på anpassningsförmågan i de olika iterationerna . 110 72 Gruppens syn på resultatet av att använda scrum . . . 110
73 Gruppens syn på förutsättningarna i projektet . . . 110
74 Gruppens syn på den gemensamma standarden . . . 111
75 Gruppens syn på förståelsen i projektet . . . 111
76 Gruppens syn på prestationen då scrum användes . . . 111
Tabeller
1 Definitioner, akronymer och förkortningar . . . 22 MVC . . . 84
3 N-tier . . . 84
1
Inledning
Under kursens gång har projektgruppen arbetat med att ta fram applikationen Honeycomb utefter en kunds önskemål och krav. Honeycomb är en produkt som hjälper kunden att visualisera simuleringar i GSM-nätverk.
1.1
Motivering
Gruppen 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öra liknande projekt.
1.2
Syfte
Syftet med rapporten är att ge läsaren en överskådlig förståelse för systemet som implementerats. Rapporten avser dessutom att dokumentera gruppens lärdomar och erfarenheter från ett projektarbete, i en grupp på nio personer, som med hjälp av agila arbetsmetoder arbetat tillsammans för att skapa ett system som löser ett verkligt problem för en riktig kund. Rapporten kommer ta upp gruppens med- och motgångar tillsammans med några intressanta frågeställningar.
1.3
Frågeställning
1. 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änsningar
Rapporten kommer att behandla projektets utvecklingsfaser och slutprodukt vilket 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 kursen TDDD96: Kandidatprojekt i programvaruutveckling vid Linköpings universitet.
1.5
Definitioner, akronymer och förkortningar
I tabell 1 så definieras de akronymer och förkortningar som används i rapporten.
Tabell 1: Definitioner, akronymer och förkortningar Term Definition
BSC Base Station Controller BTS Base Tranciever Station
ETSI European Telecommunication Standards Institute GSM Global System for Mobile communication
GUI Graphical User Interface
IMEI International Mobile Equipment Identity IMSI International Mobile Subscriber Identity LTE Long Term Evolution
MS Mobile Station
MSC Mobile service Swiching Center MVC Model View Controller
SIM Subscriber Identity Module TSS Test and Simulation Solution
2
Bakgrund
Ericsson ä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 en miljard användare varje dag är Ericssons nätverk bland de mest använda [1]. GSM är en standard som utvecklats av European Telecommunication Standards Institute (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. Totalt finns 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 kommer sannolikt att ha en vital roll även efter 2020 [3].
Figur 1: Mobila användare per nätverksteknologi. Grafen är genererad med hjälp av Ericssons Traffic Exploration [3]
På Ericsson finns idag ett behov av att kunna genomföra tester på dessa mobila nätverk vilket med stor sannolikhet även är fallet i framtiden också. Tidigare har 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 det att de verktyg man tidigare hade använt inte längre var brukbara. De utvecklare som ä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 ändra på 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 att starta och att de är komplicerade att genomföra. Ericsson behöver därför en ny skrivbordsapplikation där man enkelt kan testa olika specialfall.
2.1
Projektgruppens bakgrund
Projektgruppen består av sju datateknologer och två mjukvaruteknologer. Alla läser kursen TDDD96:Kandidatprojekt i programvaruutveckling vid Linköpings universitet. Det huvudsakliga kursmomentet är att utveckla en produkt åt en utomstå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 mer informell karaktär, fortfarande med en beställare men då i form av kursansvarig.
3
Teori
I detta avsnitt finns teori kring de teknologier, processer och modeller som är relevanta för att förstå innehållet i rapporten.
3.1
Scrum
Scrum är en agil, empirisk metodik som är en väldigt vanlig arbetsmetod inom de flesta projektarbetena. Den hjälper till att bryta ned komplexa problem till mindre utförbara uppgifter och är förlåtande till plötsliga förändringar. Scrum tillåter projektet att vara anpassningsbart och kan snabbt ändra riktning efter nya 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 levererar produkter 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 processtyrning att processen genomsyras av transparens, granskning och anpassning. För att uppnå detta måste alla i projektgruppen ha en gemensam standard på arbetet fö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. Detta gör att arbetet kan anpassas när det upptäcks att vissa avvikelser i arbetet nått oacceptabla 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 sprintar som 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 teascrumtea-met tror sig klara av i kommande sprint. Dessa aktiviteter utgör sedan sprintens produktbacklog 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ålls kring 15 minuter långt. Detta möte ska alla i scrumteamet närvara vid. Syftet med 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 kan stoppa 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, utvecklingsteamet och produktägaren.
Scrummästare
Scrummästarens roll är att se till att arbetet för alla i teamet går smidigt, det är en 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öja eventuella hinder som uppstått för gruppmedlemmarna. Scrummästaren hjälper även produktägaren att organisera och tolka backloggen och om det behövs även påminna utvecklingsteamet om att skriva tydliga poster i backloggen.
Utvecklingsteamet
Det är utvecklingsteamet som gör själva arbetet och det är bara de som får bidra till de inkrementella framstegen för produkten. Rekommenderad storlek är 3 till 9 personer.
Produktägaren
Produktägaren bär det yttersta ansvaret för backloggen även om det är möjligt att denna person låter andra i teamet utföra uppgifterna att skriva och granska backloggen.
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älva produkten som teamet utvecklar den viktigaste artefakten men det finns även scrumspecifika artefakter.
Produktbacklogg
Detta är ett dynamiskt dokument som växer fram allt eftersom förståelsen fö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örjan kommer pro-duktbackloggen bara att beskriva de krav som är bäst förstådda för att under projektets gång utvecklas och förfinas. Till slut är produktbackloggen en kom-plett lista över krav på produkten. Utvecklingsteamet bör bara arbeta utifrån detta dokument och det är produktägaren som bär ansvaret för att produkt-backloggen sköts och prioriteras.
Sprintbacklogg
Inför varje sprint väljs ett antal poster ut från produktbackloggen som skall ingå och slutföras under kommande iteration. Dessa poster sätts ihop till en sprintbacklogg och utgör en slags prognos för vad som kommer att finnas med i nästa inkrementering av produkten.
3.2
Kanban
Till 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å har Kanban ett annat tillvägagångssätt till progressionen. Under rubrik C.3.3 finns en mer utförlig utläggning om just Kanban.
3.3
Semat Kernel ALPHA
SEMAT, akronym för Software Engineering Method and Theory, grundades 2009 och ä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 projekts status 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 State Cards, 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].
3.4
GSM
GSM är ett andra generations (2G) digitalt mobilnät utvecklat av European Telecommunication Standards Institute (ETSI). Det är en globalt accepterad standard 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 och LTE-advanced [7].
3.4.1 Nätverksarkitektur
Ett GSM-nätverk består av ett antal enheter. De som berörs i detta projekt finns illustrerade i figur 2 där man även kan avläsa hur dessa enheter interagerar med varandra. Nätverket består av tre huvudkomponenter som i sin tur kan delas upp i ännu mindre delar. Det tre huvudkomponenterna är Mobile Station, Base Station 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 de tjänster som är betalda för oavsett vilken telefon som används. SIM-kortet är alltså 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 är som 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 melupprätthål-lan 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 mellan MS och MSC.
Network Subsystem (NSS)
I NSS finns ett antal komponenter där huvudkomponenten är en så kallad Mobile Switching Centre (MSC). Det är MSC som kopplar samtal mellan olika enheter och 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 Test and Simulation Solution (TSS).
Test and Simulation Solution (TSS)
TSS:erna innehåller en hel testsimulering. Olika TSS:er är helt separata från varandra. 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 Qt
Python, 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-vatpersoner. Python är även ett multiplattform-språk, tillgängligt i ett flertal olika versioner, som kontinuerligt uppdateras och förfinas i linje med framtidens krav på mjukvara [9].
PySide är ett paket vars syfte är att möjliggöra användandet av paket och klasser från Qt-biblioteket i program skrivna med språket Python. Paketet är av 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 ut och släpptes den 14 Oktober, 2015. Se figur 4 för hur PySide används av Python som 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 X och Linux. Ramverket syftar till att utvidga språk, specifikt C++, med hjälp av en rad olika funktioner och bibliotek. Ramverket skapades av Trolltech, men ägs idag 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 olika platshållare kan dessa komponenter smidigt placeras ut. Programmet genererar sedan en XML-fil som representerar GUI:t. Komponenterna som man kan välja bland är färdiga klasser och paket som finns i Qt-biblioteket [12].
3.7
Tester och verktyg för testning
De 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 testverktyg som använts i projektet.
4
Metod
Projektarbetet utfördes i olika faser, med förstudie, utvecklingsfas och redovis-ningsfas. Utvecklingsfasen realiserades i iterationer: sprintar på 3-4 veckor som påbörjades genom att mål för iterationen bestämdes och avslutades med en demonstration över arbetet som utförts under iterationen. Projektgruppen tog alltså del av en agil arbetsmetod.
4.1
Frågeställningar
Frågeställningarna som den här rapporten behandlar valdes av två skäl. Det första skälet var att vår examinator satte hårda riktlinjer på vilka frågor man var tvungen att ha med, vilket gav oss tre frågeställningar. Den sista frågeställningen kom från ett intresse av att undersöka hur väl Scrum fungerat för gruppen.
4.2
Datainsamling
Fö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 riktade sig mot en specifik del av frågeställningen och avsåg att utgöra underlag för just den 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 erfarenheter kring kundrelationen, tekniker som använts för projektet och arbetsmetoden i sin 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 sida var involverade, eller om kontaktpersonen på Ericsson fungerade mer som vå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 tydligare
vision?
• 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ör inte?
• Kände du dig någonsin begränsad av MVC-arkitekturen, när du skulle implementera 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 och
ingen annan föreslog MVC, utan alla pratade om ett annat designmönster. Hade du då tagit upp MVC för diskussion?
• 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ör att på något sätt vägleda dig i ett val?
• Har Semat ALPHAS gett dig en tydligare överblick av hur långt arbetet i 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 givit mer 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 gjort dagliga standup-mötena tillsammans?
• Hur tycker du gruppens anpassningsförmåga förändrades i Scrum jämfört med tidigare, och senare iterationer?
• Tycker du att arbetet som utfördes med Scrum som arbetsmetod gav hö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 gruppen
4.3
Utvecklingsmetodik
Fö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 konfigurationsansvarig tillsattes 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 Python1med hjälp av ram-verket PySide2. Projektgruppen enades kring en målsättning för varje iteration
och 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 prioritetslista i arbetsverktyget Trello3 som lät aktivitetsflödet kontrolleras enligt
Kanban-paradigmet [13]. Under iteration ett hölls två sittande möten varje vecka där aktiviteter följdes upp och problem och framsteg diskuterades tillsammans med annan viktig information. Utöver det var det eget arbete under veckan, vilket ofta utfördes i mindre grupper. Iterationen avslutades med en demonstration fö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 enligt nedanstå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 flyttar tillhö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 till en ”granskningslista”.
5. Gruppmedlemmen granskar en annan utvecklares merge-request och ger feedback 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 att koden 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 men med små anpassningar. Den huvudsakliga anpassningen var de dagliga mötena som hölls varje dag skriftligen i projektgruppens kommunikations-kanal, slack5.
Annars följdes det som kännetecknar just utvecklingsmetodiken Scrum väl. De krav 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/about 2 https://wiki.qt.io/Category:LanguageBindings::PySide 3https://trello.com/about 4https://about.gitlab.com/ 5https://slack.com/is
dagliga mötena via skrift och enbart med scrummästaren själv var att man inte på ett enkelt sätt kunde diskutera de problem som uppstod för olika grupp-medlemmar. För att undvika det problemet ändrades de individuella skriftliga mötena till att hållas i en gemensam kanal i verktyget slack så att alla kunde ta del av informationen. I övrigt var övergången till Scrum väldigt friktionsfri eftersom arbetssättet liknade arbetsmetoden som gruppen jobbade efter under den första iterationen. Projektet var även, redan från början, tydligt indelat i iterationer med längder motsvarande längden för en iteration i Scrum. Mycket av förarbetet under den första iterationen handlade om att planera vad systemet skulle 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 utvecklare och beskrivs nedan.
1. Gruppmedlem ställer sig som ansvarig för ett avsnitt i ett dokument genom att 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 persons kort 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 denna justering av korrekturläsaren.
5. När texten är justerad, eller om den redan från början ansågs färdig, läggs kortet 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 fast punkt. I stort sett alla sittande möten skedde i olika grupprum på Linköpings universitet men det förekom även möten utanför skolan eller på cafeterior. När gruppen 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 senare med projektgruppen. Ett annat vanligt arbetssätt för gruppen var parprogram-mering.
Programmet utvecklades i Python tillsammans med Qt Designer. Eftersom Qt framfö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 projektet valde själva utvecklingsmiljö, men all kod testkördes med testverktyget pytest.
4.5
Metod för att fånga erfarenheter
Gruppen utvecklades enormt under projektet och tog del av flera sätt att ta vara på och utvinna erfarenheter. Gruppdynamik, upplägg för kursen och mål i gruppen gavs på initiala föreläsningar och diskuterades sedan på möten i grupp. Alla nya verktyg och arbetsmetoder som introducerades under projekttiden fick definierade 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 proVar-jektgruppen och handledaren vid ett sittande möte där feedback 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ölls också intervjuer och utfrågningar av beställare som gav djupare förståelse för systemet 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ål och test specificerades. Under pågående utveckling skedde mycket korrekturläs-ning av andras kod, eftersom metoden krävde detta vid merge-requests. Detta var mycket meriterande och gav god insikt i Python.
5
Resultat
I 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
Systembeskrivning
Systemet ä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 6 visar 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 controllers och den som startar programmet. Det är även MainController.py som kommunicerar 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 att göra användningen av strukturen enklare.
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 funktioner i controllers och på så sätt är actions.py som en brygga in i systemet från användaren.
5.1.4 Views
Alla filer som används för att definiera hur gränssnittet ska se ut är skapade med hjälp av Qt Designer och är en variant av XML. För att använda filerna i programmet måste de kompileras till Python-filer.
5.1.5 Connection
Connection-delen av vårt program är uppdelad i följande moduler, som ansvarar för olika delar.
• _commands.py hanterar olika kommandon som kan skickas till kundens servrar. Detta inkluderar olika “connect-funktioner” samt wrappers för att skicka 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 och att vänta på svar i form av reguljära uttryck.
• _parser.py formaterar den data som returneras från _connection.py i form av Python ”dictionaries” som senare lätt kan användas utav resten
av programmet.
• helper.py är modulen som resten av programmet pratar med och sköter den 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 sig via SSH6 och emulera en så kallad terminal, eller kommandotolk, för att
kun-na kommunicera med kundens servrar. Detta beror på att kundens system är uppbyggt 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åde för att placera datan på rätt ställe i programmet, och för att köra ett nytt kommando 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 61 st. automatiska tester och 20 st. acceptanstester. Mer information om de tester som skrivits finns under rubrik F.5.1.
5.2
Gemensamma erfarenheter och lärdomar
I den här delen av rapporten finns information om vad gruppen lärt sig och utvecklats inom. Resultaten och statistiken kommer ifrån den tidigare nämnda enkä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 tidigare kä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ågick under de inledande fyra veckorna av projektet ansträngde projektgruppen sig mycket för att försöka ta reda på vad kunden önskade för produkt så snabbt som mö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å sin hö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 via mail 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
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 kunnat leverera mer värde åt kunden om fler personer från kundens sida hade varit involverade i processen. Sju av gruppens nio medlemmar upplevde att kunden fö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å att en tydligare vision hos kunden kunde ha förbättrat slutprodukten. Sju personer upplevde också att kundens medverkan haft en positiv effekt på produkten. Tre personer i gruppen tyckte att gruppens ansträngningar att efterforska kundens behov och önskemål var bristfälliga och att gruppen borde ha lagt mer tid på det. Fem personer i gruppen upplevde att kundkontakten, hur projektgruppen hanterade 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 gruppen varken följt någon teori kring The SEMAT Kernel eller använt sig framgångsrikt av korten Alpha State Cards. I gruppen finns det enbart två personer som alls använt sig av korten, och det är bara ”sällan”. I övrigt har sex aldrig rört dem och en vet inte vad det är. Av de två personerna som faktiskt tittat närmare på SEMAT har båda upplevt att det funnits stöd att hämta. En upplevde att korten 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 tankar kring SEMAT: bara en person tror att det hade gynnat gruppen att fördjupa sig mer eller att i högre grad använda korten. Två är osäkra på om en frekventare användning hade hjälpt gruppen medan resterande sex inte tror att det tillfört någonting. Dessa resultat baseras alltjämt på en grupp av nio personer där fyra inte alls bemödat sig med att titta närmare på vad detta rör sig om, men även om urvalet skulle begränsats till kvarvarande fem har ingen tydlig nytta kunnat identifieras. 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 hade slutförts. Ett flertal i gruppen tyckte även att det var bra att enkelt kunna följa progressionen 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. Features blev klara och höll hög kvalité, gruppmedlemmarna tog sig an en feature och såg till att den blev klar. Majoriteten av gruppen tyckte att produktiviteten överlag var bättre än under den första iterationen. Delar av gruppen upplevde dock att det var svårt att ta egna initiativ eller att fixa andra mindre saker som inte fanns 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 fastnade på 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 gruppdynamik under iteration två. Somliga tyckte att de dagliga mötena ibland kunde vara jobbiga och förmodligen gjordes en snedvriden poänguppskattning av arbetet som skulle utföras. Sammanfattningsvis har, i det stora hela, tillämpningen av Scrum mestadels haft positiva effekter på projektet och gruppen.
5.3
Översikt över individuella bidrag
De individuella bidragen, placerade sist i denna rapport, tar upp följande: • Python för prototyputveckling undersöker vare sig Python lämpar sig som
programmeringsspråk vid prototyputveckling av ett nytt program utav en ny, oerfaren grupp utvecklare. Undersökningen är skriven av gruppens konfigurationsansvarig, Jonatan Branting.
• Utvecklandet av ett grafiskt gränssnitt undersöker verktygen som gruppen valde 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 vidare diskussion om vilka begränsningar experimentet innehar kommer förfat-taren fram till att Scrum är det självklara valet. Utredningen är skriven av gruppens utvecklingsledare, Niklas Erhard Olsson.
• Teamledarens roll i mjukvaruutveckling undersöker hur teamledaren passat in och fungerat i projektarbetet. Undersökningen är skriven av gruppens teamledare, August Fundin.
• En analys av kodgranskningar undersöker hur gruppens kodgranskningar gått till samt vad, vid en eventuell förändring, man skulle kunna gjort an-norlunda. Analysen är skriven av gruppens kvalitetssamordnare, Rasmus Johns.
• En analys av tester beskriver och analyserar testningen i projektet, med målet att avgöra vilken typ av tester som varit viktigast. Analysen är skriven av gruppens testledare, Martin Lundberg.
• Är LATEX ett lämpligt verktyg för projektgrupper? I denna del undersöks
hur lämpliga de verktyg projektgruppen valt att använda för dokumen-tation är. Vilka fördelar och nackdelar finns med verktygen samt vilka lärdomar projektgruppen fått från detta projekt. Utredningen är skriven av gruppens analysansvarig, Hanna Müller.
• Designmönstret MVC undersöker hur MVC fungerar, vilka problem som kan uppstå och några alternativ som finns. Undersökningen är skriven av gruppens arkitekt, Adam Nyberg.
• Val av utvecklingsmiljö vid mjukvaruutveckling är en utredning som syftar till att redovisa vilka olika faktorer, allt från krav till erfarenhet, som kan vägleda utvecklare då ett val av utvecklingsmiljö ska genomföras. Utred-ningen är skriven av gruppens dokumentansvarig, Niklas Pettersson.
6
Diskussion
I 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 se samband och verkan i resultaten. Även metoden lyfts för diskussion och slutli-gen diskuteras miljö-, etik- och samhällsaspekter av projektarbetet.
6.1
Resultat
Resultaten visar att med valda arbetsmetoder och implementationssätt har ett program skapats som kan vara av värde för kunden. Gruppmedlemmarna har erhållit varierande tekniska erfarenheter så som att arbeta med versionshante-ring, med ramverket PyQt och testdrivet. Med Scrum som arbetsmetod pekar resultaten mot både positiva och negativa upplevelser. Det passade inte alla med 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öjt kvalitativt arbete i gruppen.
6.1.1 Systemet
Det huvudsakliga målet och filosofin var att arkitekturen skulle vara enkel och lätt att förstå. På så sätt var det tänkt att det skulle bli enkelt för nya utvecklare att vidareutveckla och underhålla systemet. Valet att använda MVC motivera-des av att kundens möjlighet till vidareutveckling av programkoden skulle vara optimal. Kunden krävde också lättläst och strukturerad kod i den bemärkelsen att anställda på kundens företag skulle kunna sätta sig in i hur programmet fungerar utan större bekymmer. Gruppen diskuterade och kom fram till att ett välkänt arkitekturmönster vore väldigt passande och, då tidigare erfarenheter frå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ör oss 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 gruppen under en period bytte ut all grafik för telefonerna samtidigt som en annan del av gruppen utvecklade telefonmodellerna och sättet de sattes ut på. Med andra ord arbetade en del av gruppen på View, medan övriga i gruppen jobbade med Models och Controllers.
En annan användning av MVC-mönstret som vi upptäckte var produktkodens sammanhållning. Med ett så starkt designmönster, som MVC utgör, är det svå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 med ny funktionalitet är det extremt svårt att inte göra det på rätt sätt: UI-filen implementeras bara på ett ställe och kan bara ändras på ett ställe; controllers initialiserar funktionaliteten av UI-element via en funktion som hämtar all sin information från actions; funktionaliteten som actions knyter upp sig mot måste ligga i en controller. För att lyckas bryta mot det här mönstret krävs det att utvecklaren som försöker begå ett misstag återimplementerar en ny struktur av liknande komplexitet.
Stundtals har gruppen dock känt sig begränsad av MVC-mönstret. Gruppen står splittrad gällande frågan om dessa begränsningar varit bra eller dåliga men sett till resultatet borde det betraktas som positivt.
Arkitekturen är enkel att bygga vidare på och eftersom systemet är modulärt är det också enkelt att ändra vissa egenskaper utan att systemet på en större skala påverkas. Detta var viktigt för kunden, både eftersom det inte gick att förvänta sig ett program som lever upp till alla av kundens förväntningar på tilldelade kurstimmar och eftersom programmet på detta sätt kan få längre livslängd. Det finns dock en rätt brant inlärningskurva för en ny individ som vill sätta in sig i hela systemet. Utan vägledning kan utvecklare som inte redan har god vana av 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 implementera en 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 stark vision om hur produkten skulle se ut och fungera. Detta gav gruppen en bra grund 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 kunde uppstå, så var kunden oftast snabb på att ge svar vilket även det gynnade gruppens 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 upplevt kundrelationen 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 kunden valde 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öreslog kunden ändringar och tog upp problem som, enligt gruppen, kom alldeles för sent. Dessa ändringsförslag kunde grunda sig i att kunden hade mindre bra koll på detaljer kring vad vi som grupp skulle kunnat ha gjort för att förenkla ett problem. I slutet av iteration ett föreslog gruppen att kunden skulle förse grup-pen, eller en individ i grupgrup-pen, med en dator som var kopplad till kunden så att funktionalitet och uppkoppling mot kunden kunde testas. Kunden gick med på detta men det visade sig att det inte var så enkelt att göra verklighet av förslaget. Det slutade dock med att förslaget gick igenom men att det tog lång tid. Det stora företaget vi jobbade mot medförde att det kunde ta lång tid för att få igenom sådana förslag vilket gjorde att vi så sent som i iteration tre kunde få tillgång och testa produkten mot deras servrar.
Inför framtida kundkontakter har vi lärt oss att planera extraherandet av krav vilket sköttes via intervjuer med representant hos kunden. Prata med kunden mycket. Informera att vi kan behöva kontakta dem ofta, inte via mail utan via möten. Ha kundkontrakt. Kom på tidigt vad det är vi behöver från dem så att inte saker kommer i sista sekunden som med datorn som de försåg oss med. Man måste trycka på om det är något man behöver som är avgörande för
resultatet. Om teamet behöver en dator eller någon annan form av access för att kunna testa systemet så måste det verkligen trycka på om det inte händer någonting. Någon form av risk för kunden skulle förmodligen bidra till att båda parter aktivt kämpar för att nå ett bra resultat och hjälpa teamet att slutföra projektet med ett så gott resultat som möjligt. Det ligger då i båda parters intresse att röja undan hinder för teamet. Denna risk skulle kunna vara, som tidigare påpekat, ett kundkontrakt där krav ställs på kunden och inte enbart oss, 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 den första iterationen var det mycket dokument som skulle skrivas, krav att samla in från kunden och arkitekturen för projektet skulle läggas. Iteration ett var en uppstart av projektet med många lösa trådar och kan ha medfört känslan av mindre produktivitet eftersom faktiskt arbete på produkten inte påbörjats än-nu. En starkt bidragande orsak till en tydligare struktur och ordning i iteration två 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 samtidigt fö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 leverera någonting av värde till kunden vid slutet av iterationen. Trots att 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 behövde jobba hårdare eller inte.
Att varje dag presentera progressionen, gruppens produktivitet och vad alla gjort 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, som skapade 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 man ska ta sig an nästa dag gav många av gruppmedlemmarna en positiv press som ledde till att mycket arbete blev gjort. Det är en form av åtagande, ett sorts löfte till gruppen som definitivt gynnat det individuella ansvarstagandet för he-la projektet. En annan bidragande faktor kan också givetvis varit att gruppen tog 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 var lagd 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 man använder PyQt med Python, kunde gruppen med enkelhet modifiera och utöka ett 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öt på.
I och med att vi körde våra dagliga scrummöten på nätet, via webbverktyget slack, kunde vi inte tillsammans diskutera igenom eventuella problem som ha-de uppstått för projektmedlemmarna. Vi tappaha-de såleha-des tillfället att diskutera igenom 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
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åg inte 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 ärlig chans. Bara två gjorde ett försök till att hitta ett användningsområde, vilket bå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 ha gett detta större utrymme i gruppen, men tog inte initiativ till detta. Hade ett liknande arbete utförts hade det antagligen inte funnits något incitament för gruppen att lyfta SEMAT ännu en gång, även om det finns aspekter i resultatet som tyder på att efterforskningarna av SEMAT varit bristfälliga. Detta beror på 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 allt frå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 ytterligare parametrar behövts vägas in.
6.1.5 Tester
Vid starten av projektet lades nästan ingen tanke på tester vilket innebar att koden som skrevs inte skrevs för att kunna testas. Det som hände var att våra models blev smala och våra controllers blev feta. Det gjorde att det var väldigt svårt att skriva tester då vi äntligen började med det i iteration två, vilket är ett välkänt problem med feta controllers [14].
En bra fördelning av enhets-, integrations- och systemtester ska likna en pyramid med 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 knappt funnits något att testa.
De viktigaste lärdomarna från det här projektet för framtiden är att verkligen se till att lägga fokus på testning från början på ett nytt projekt. Ett exempel är att från början skriva koden med tanken att funktionerna ska enhetstestas. Då
kommer kodstrukuren att bli bättre vilket kommer göra det enklare att fortsätta skriva tester under hela projektet.
Även då mer kunde önskas av testerna så skapar de värde för kunden genom att de:
• 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 de
ska.
• Om kunden vill fortsätta utvecklingen av programmet kan användas för regressionstestning, alltså för att säkerställa att allt som fungerade tidigare fortfarande fungerar.
6.2
Metod
Eftersom 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år rapport. Metoden vi valde att använda var förmodligen relativt obeprövad och annorlunda gentemot hur grupper traditionellt sett pratar ihop sig innan de producerar 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 sidan tog vi diskussionerna, eftersom att vi tillsammans valde enkätfrågor och således också vilka ämnen som var viktiga för gruppen. Vi förenade det med fördelarna med ett anonymt och skriftligt system: alla får en chans att komma till tals när det ä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 diskuterat oss fram till vartenda textstycke, istället för ovanstående metod. Det hade dock varit svårt under sådana diskussioner att låta alla komma till tals på samma sätt som vår omfattande enkät gjorde.
6.3
Arbetet i ett vidare sammanhang
En 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 deras arbetsprocess när det kommer till testning av GSM-nätverk. Om programvaran blir 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 tesverklighe-ten görs i implementerad hårdvara, i det existerande GSM-nätet, skapas problemet att testare behöver resa runt mycket och det kan dessutom medföra störningar på nätet mot slutanvändare. Alltså är inte värdet
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. Dessutom slipper 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ändningen av GSM är stor så finns det många användare som kommer kunna bli positivt påverkade av detta.
7
Slutsatser
I den här sektionen presenteras rapportens slutsatser.
7.1
Hur har Honeycomb implementerats så att ett värde
skapats åt kunden?
Vi tror att prototypen som vi lämnat över till kunden kommer att fungera som ett komplement till deras nuvarande simuleringsmiljö. Det kan därför hävdas att 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 projekt liknande detta. I ett vidare perspektiv, som tidigare beskrivet under diskussion, så kan förhoppnings Honeycomb hjälpa kundens anställda vid körningar av test fö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ärt sig, från grunden, att utveckla grafiska användargränssnitt och Qt-ramverket. Flera gruppmedlemmar har också blivit mer bekanta med designmönster, till exempel MVC. Med tanke på att versionshanteringsprogrammet Git har använts flitigt under utvecklingen så har gruppmedlemmarna även fått kunskaper kring detta. I avseende till hur kunnande gruppen var under första iterationen, jämfört med 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 som gruppen 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 dra slutsatser 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älp av ramverket och dess komponenter. I jämförelse med iteration ett blev det en mä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 bidrog starkt till en betryggande ordning och säkerhet i att vi skulle kunna leverera någonting innan iterationens slut. Mycket tack vare att vi spårade progressionen under tiden.
A
Python för prototyputveckling
En utredning skriven av Jonatan Branting, konfigurationsansvarig i Grupp 8 i kursen TDDD96, vid Linköpings universitet.
A.1
Inledning
Valet av programmeringsspråk är en av de viktigaste beslut som kan tas i början av ett projekt. Fel programmeringsspråk kan leda till buggar, förseningar och generellt 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 vilket språk som skulle passa bäst för det givna projektet. Att utveckla en prototyp av ett program medför ytterligare krav på språket; det måste vara lätt och snabbt att testa nya idéer och koncept. Utöver det måste språket ha en relativt låg inträdeströskel, så teamet kan komma igång med utveckling på kortast möjliga tid.
A.1.1 Syfte
Syftet är att undersöka vare sig Python lämpar sig som programmeringsspråk vid 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
Bakgrund
När vi valde programmeringsspråk för projektet enades gruppen bakom pro-grammeringsspråket Python, med motiveringen att alla hade tidigare använt språket, och att det "kändessom ett bra språk för vårt ändamål; att utveckla en prototyp av en front-end för kundens simulatormiljö för 2g-nätverk på en relativt kort tid (Tre månader).
A.3
Teori
Olika programmeringsspråk är designade för olika ändamål. Utöver det så har olika programmeringsspråk olika höga s.k. inträdeströsklar, d.v.s. hur svårt eller hur mycket kompetens som krävs för att ett programmeringsspråk ska vara effektivt att använda. Denna tröskel vill vi hålla så låg som möjligt, för att ge möjligheten för hela gruppen att bidra så enkelt som möjligt.
A.4
Metod
Fö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 titta på valet av språk och dessa kriterier ifrån perspektivet av ett oerfaret team.:
1. Ej verbost. Då vi har begränsad tid vill vi kunna fokusera på att skriva kod 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 faktiska uppgiften.
2. Tillgängliga bibliotek för att underlätta lösningen av problem som kommer att 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 är skriven. 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, och sparar 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år grupp ä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 andra har skrivit. Att lära utav varandra är också väldigt viktigt, vilket tydlig och klar syntax underlättar med.
5. Lätt att sätta upp en utvecklingsmiljö för språket. Då vi har en tämligen strikt tidsbegränsning måste det gå snabbt att komma igång. Att få igång utvecklingsmiljöerna är då väldigt viktig då allt annat hänger på att detta fungerar.
6. Det måste vara lätt att testa nya ändringar. Då vi kommer att iterera mycket är det viktigt att båda kunna testa hur nya ändringar kommer att påverka resten av programmet, samt att kunna hitta buggar och annat som lätt kan introduceras när en grupp oerfarna programmera slår sig samman.
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 programming requirements 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 att prestanda 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äldigt viktigt. Om detta tar för lång tid är det svårt att hitta och fixa buggar, samt gör det svårare att testa nya idéer, någonting som förstås är väldigt viktigt inom prototyputveckling.
A.5
Resultat
För att komma fram till följande resultat har jag analyserat både mina egna erfarenheter och tankar, samt flera olika artiklar som tar upp liknande fråge-ställningar.
