Trace-analysverktyg : Statisk och dynamisk analys av mjukvara

109  Download (0)

Full text

(1)

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

2021 | LIU-IDA/LITH-EX-G--2021/029--SE

Trace-analysverktyg: Statisk och

dynamisk analys av mjukvara

Trace analysis tool: Static and dynamic software analysis

Sebastian Broman

Erik Halvarsson

Victor Lells

Abedalhkeem Najeeb

Niklas Samuelsson

Isak Stenström

Christian Sundkvist

William Vedin

Handledare : Henrik Henriksson Examinator : Kristian Sandahl

(2)

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum 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 kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ 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 sammanhang som är kränkande för upphovsman-nens litterä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 circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, 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 consent 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 University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Sebastian Broman Erik Halvarsson Victor Lells Abedalhkeem Najeeb Niklas Samuelsson Isak Stenström Christian Sundkvist William Vedin

(3)

Sammanfattning

Rapporten beskriver ett projekt som utförts i kursen TDDD96 - Kandidatprojekt i pro-gramvaruutveckling vid Linköpings universitet. Projektet gick ut på att utveckla ett verktyg för att analysera och visualisera programkod åt Saab Aeronautics.

Verktyget analyserar disassembly-filer av ett program för att visualiera olika vägar exe-kveringen kan ta genom ett program, och körningsloggar för att visualisera ett anropsträd över programmet. Verktyget är tänkt att användas för att hjälpa till vid analys av mjukvara genom att visualisera flödet genom koden.

Rapporten beskriver både den tekniska aspekten av projektet och dess resultat, och den arbetsmetodik som använts under projektet. Rapporten diskuterar även de erfarenhe-ter som kan dokumenerfarenhe-teras från projektet. En av de viktigaste erfarenheerfarenhe-terna man kan ta med sig från detta projekt är vikten av kommunikation inom projektgruppen, speciellt för ett projekt som genomförs på distans. Det är också viktigt att ha bra kommunikation och kontinuerlig kontakt med kunden för att se till att det som utvecklas faktiskt är det som kunden efterfrågat.

Rapporten inkluderar även en individuell del som varje projektmedlem skrivit. Dessa individuella delar djupdyker inom begränsade områden relaterat till projektet.

(4)

Tillkännagivanden

Vi vill ge alla de personer och organisationer som varit involverade under projektet ett stort tack.

Ett speciellt tack vill vi ge till våra kontakter på Saab, Daniel Nordgren och Anderas Sten-berg. Det var deras stöd och engagemang som gjorde att projektet gick att genomföra. Vi skulle vilja tacka vår handledare Henrik Henriksson. Kvaliteten på denna rapport skulle in-te varit densamma utan hans feedback. Vi skulle även vilja tacka alla opponenin-ter; och de personer som svarat på enkäter och intervjuer.

(5)

Innehåll

Sammanfattning iii Författarens tack iv Innehåll v Figurer viii Tabeller viii 1 Introduktion 1 1.1 Motivering . . . 1 1.2 Syfte . . . 1 1.3 Frågeställning . . . 1 1.4 Avgränsningar . . . 2 1.5 Kontext . . . 2 2 Bakgrund 3 2.1 Kundens bakgrund och syfte . . . 3

2.2 Kundens vision . . . 3

2.3 Kundens krav . . . 4

2.4 Gruppens tidigare erfarenheter . . . 4

2.5 Liknande lösningar . . . 5

3 Teori 6 3.1 Assemblerinstruktioner och maskinkod . . . 6

3.2 PowerPC™ . . . 6

3.3 Körningslogg . . . 8

3.4 Disassembly-fil . . . 8

3.5 QEMU . . . 8

3.6 GNU Binutils och disassemblering . . . 9

3.7 Worst Case Resource Usage . . . 9

3.8 Python . . . 10

3.9 Kontinuerlig integrering (Continuous Integration) . . . 10

3.10 Parprogrammering . . . 10

3.11 Scrum . . . 10

4 Metod 11 4.1 Utvecklingsmetod . . . 11

4.2 Metod för att fånga erfarenheter . . . 15

4.3 BPSA:s värde för kunden . . . 17

4.4 Framtagning och uppföljning av systemanatomi . . . 17

(6)

5 Resultat 18

5.1 Systembeskrivning . . . 18

5.2 Kundvärde . . . 22

5.3 Potentiella vidareutvecklingar av BPSA . . . 22

5.4 Processbeskrivning . . . 23

5.5 Gemensamma erfarenheter . . . 24

5.6 Översikt över individuella bidrag . . . 27

6 Diskussion 29 6.1 Resultat . . . 29

6.2 Metod . . . 32

6.3 Arbetet i ett vidare sammanhang . . . 33

7 Slutsatser 34 7.1 Hur kan BPSA implementeras så att man skapar värde för kunden? . . . 34

7.2 Vilka erfarenheter kan dokumenteras från detta projekt som kan vara intres-santa för framtida projekt? . . . 34

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 35

7.4 Hur kan BPSA vidareutvecklas? . . . 35

A Visuell analys av programkod av Sebastian Broman 36 A.1 Introduktion . . . 36 A.2 Bakgrund . . . 36 A.3 Teori . . . 37 A.4 Metod . . . 38 A.5 Resultat . . . 40 A.6 Diskussion . . . 42 A.7 Slutsatser . . . 44

B Kontinuerlig Integrering i mindre och korta projekt av Erik Halvarsson 45 B.1 Introduktion . . . 45 B.2 Teori . . . 46 B.3 Metod . . . 47 B.4 Resultat . . . 48 B.5 Diskussion . . . 50 B.6 Slutsatser . . . 51

C En jämförelse av centraliserade och distribuerade versionshanteringssystem av Victor Lells 52 C.1 Introduktion . . . 52 C.2 Teori . . . 53 C.3 Metod . . . 56 C.4 Resultat . . . 57 C.5 Diskussion . . . 58 C.6 Slutsatser . . . 60

D Genomförande av ett projekt på distans av Abedalhkeem Najeeb 61 D.1 Introduktion . . . 61 D.2 Teori . . . 62 D.3 Metod . . . 63 D.4 Resultat . . . 63 D.5 Diskussion . . . 66 D.6 Slutsatser . . . 67

(7)

E Modern kodgranskning i ett litet projekt av Niklas Samuelsson 69 E.1 Introduktion . . . 69 E.2 Bakgrund . . . 69 E.3 Teori . . . 70 E.4 Metod . . . 70 E.5 Resultat . . . 71 E.6 Diskussion . . . 72 E.7 Slutsatser . . . 73

F Generalisering av assembleranalys till andra instruktionsuppsättningar av Isak Stenström 74 F.1 Introduktion . . . 74 F.2 Teori . . . 75 F.3 Metod . . . 78 F.4 Resultat . . . 79 F.5 Diskussion . . . 80 F.6 Slutsatser . . . 81

G Etiskt ansvar i produktutveckling av Christian Sundkvist 82 G.1 Introduktion . . . 82 G.2 Bakgrund . . . 82 G.3 Teori . . . 83 G.4 Metod . . . 83 G.5 Resultat . . . 84 G.6 Diskussion . . . 86 G.7 Slutsatser . . . 87

H Parprogrammering på distans av William Vedin 88 H.1 Introduktion . . . 88 H.2 Bakgrund . . . 89 H.3 Teori . . . 89 H.4 Metod . . . 89 H.5 Resultat . . . 90 H.6 Diskussion . . . 93 H.7 Slutsatser . . . 94 Litteratur 95

(8)

Figurer

2.1 Trädvy . . . 4

3.1 Utdrag från körningslogg . . . 8

3.2 Utdrag från disassembly-fil . . . 9

5.1 En övergripande bild på systemet . . . 19

5.2 En övergripande systemanatomi . . . 20

5.3 Skärmbild BPSA: Nuvarande . . . 22

5.4 Skärmbild BPSA: Tidig . . . 25

5.5 Skärmbild BPSA: Senare . . . 25

A.1 Exempelprogram . . . 39

A.2 Graf över kodvägar . . . 41

A.3 Graf över funktionsanrop . . . 41

A.4 Flödesdiagram över run_test . . . 42

D.1 Enkätens resultat av de olika aspekterna i distansarbete . . . 64

D.2 Enkätens resultat angående arbetstider . . . 64

D.3 Enkätens resultat angående planerade arbetstimmar . . . 65

D.4 Fyra grafer angående matvanor . . . 66

Tabeller

3.1 Hoppinstruktioner som finns i PowerPC - E500 . . . 7

3.2 Hoppvillkor som finns i PowerPC - E500 . . . 7

5.1 Data över aktiviteter . . . 23

5.2 Resultat av sprintenkät . . . 23

A.1 Riktmärken för cyklomatisk komplexitet . . . 38

A.2 Tabell över cyklomatisk komplexitet per funktion . . . 40

C.1 Versionshanteringssystem: Openhub Repositories . . . 57

(9)

1

Introduktion

I detta avsnitt beskrivs syftet med verktyget som utvecklats, vilket har namngetts till BPSA (Basic PowerPC System Analysis), och de frågeställningar som behandlats.

1.1

Motivering

Att verifiera om mjukvara fungerar korrekt kan vara en komplicerad och tidskrävande pro-cess. Verktyget som utvecklats av projektgruppen våren 2021 är designat för att minska mängden mänskligt arbete som krävs för att analysera programkod. Verktyget räknar funk-tionsanrop, minnesallokering samt instruktioner på funktionsnivå och försöker avgöra om kodsegment tar konstant eller variabel tid, allokerar minne eller gör funktionsanrop. Bestäl-lare och kund för produkten som utvecklats är Saab Aeronautics som tidigare gjort analysen för hand.

1.2

Syfte

Syftet med den här rapporten är att ge läsaren en överskådlig förståelse kring vad det kan-didatprojekt som utförts handlar om, utvecklingen och framtagande av produkten, verktyg och arbetsmetoder som används samt projektets slutresultat. Syftet är även att besvara de forskningsfrågor som ställts i avsnitt 1.3.

1.3

Frågeställning

1. Hur kan BPSA implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från detta projekt som kan vara intressanta för framtida projekt?

3. Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? 4. Hur kan BPSA vidareutvecklas?

(10)

1.4. Avgränsningar

1.4

Avgränsningar

Projektet utfördes under våren 2021, och på grund av rådande pandemi avgränsades arbets-gången till att i största mån ske på distans snarare än i person. Detta gällde även majoriteten av den kommunikation mot kund som skett under projektets gång.

1.5

Kontext

Projektet som beskrivs i denna rapport genomfördes av åtta studenter som en del av kursen TDDD96 – Kandidatprojekt i programvaruutveckling vid Linköpings universitet. Varje per-son hade en tidsbudget på 400 timmar, alltså en total tidsbudget på 3200 timmar. Tidsbudge-ten innefattar både individuellt och gemensamt skrivande av kandidatrapport, projektplan, kravspecifikation, arkitekturdokument, kvalitetsplan, testplan, testrapport och utförandet av projektet i sin helhet.

Det var upp till vardera student att lägga upp en tidsplan över vårterminen med hänsyn till övriga kurser studenten läst parallellt med projektet. Tidsplaneringen har varierat mellan de olika projektmedlemmarna och fördelningen av högskolepoäng mellan perioderna var olika beroende på vilken inriktning av civilingenjör studenterna läste. Flera av projektmed-lemmarna uttryckte svårigheter med att lägga ner den planerade tiden i kombination med andra kurser samt att det i vissa fall var stressigt att försöka följa en tidsplanering. En an-ledning till det skulle kunna vara att arbetet har skett på distans och det kan vara svårt att urskilja vilken tid som ska skrivas ner i tidrapporten.

I början av kursen fick gruppen välja mellan ett flertal förutbestämda projekt. Gruppen behövde göra en topp-fem-lista över de projekt som de helst ville arbeta med för att sedan bli tilldelade ett av dessa fem av kursens examinator. Valen gjordes baserat på en kort projekt-beskrivning av varje projekt. Den beskrev vilken institution eller vilket företag som lagt fram projektet, vilka arbetsuppgifter studenter skulle få ta på sig och vilka mål projektet hade.

(11)

2

Bakgrund

I detta avsnitt beskrivs kunden, dess bakgrund och behovet av produkten. Utöver detta be-skrivs gruppens tidigare kunskaper och erfarenheter från tidigare projekt.

2.1

Kundens bakgrund och syfte

Projektets kund var Saab-enheten Aeronautics, som arbetar med konfigurering av avionik-system. Då det är ett arbetsområde där mjukvarufel kan få katastrofala konsekvenser krävs det att deras produkter upprätthåller högsta uppdragskritiska nivå. För att säkerställa detta är det således intressant att studera Worst Case Resource Usage för samtliga kodsegment som körs, för att säkerställa att koden är rätt skriven och gör exakt det som efterfrågas. Detta är ett arbete som tidigare gjorts av sakkunniga för hand, och det är detta manuella arbete som projektet ämnar att underlätta och potentiellt ersätta.

Den mjukvara som analyseras är assemblerkod kompilerad för en PowerPC-processor. Analysen görs dels på en körningslogg av mjukvaran som genereras genom att köra ran i en virtuell maskin, och dels på en disassemblerad variant av den kompilerade mjukva-ran.

2.2

Kundens vision

Kundens vision var ett gränssnitt för att tillgängliggöra data om hur ett visst kodsegment agerat under körning givet ett antal körningar. Exakt hur det skulle realiseras lämnades till projektgruppen. Frågor som kunden önskade få besvarade med produktens hjälp var:

• Är exekveringstiden av ett kodsegment variabel? • Hur många iterationer körde varje loop?

(12)

2.3. Kundens krav

2.3

Kundens krav

För att projektet skulle leva upp till kundens vision ställdes ett antal viktiga krav på produk-ten:

• Verktyget ska visualisera möjliga vägar genom koden som en trädvy, se figur 2.1. • Verktyget ska visualisera alla funktionsanrop i en körning som en trädvy.

• Verktyget ska tydligt kunna illustrera olika attribut en bit kod har vid körning, till ex-empel:

Vad är variansen hos en funktions instruktionsantal mellan olika funktionsanrop? Tar ett segment/en kodrad på någon slags minnesresurs?

Har ett segment/en kodrad ej körts?

• Man ska kunna lägga till egna attribut till analysverktyget och manuellt applicera dessa på kodsegment.

• Verktyget ska kunna spara och ladda en analys till/från en fil.

Figur 2.1: Trädvy

2.4

Gruppens tidigare erfarenheter

Projektgruppen bestod av åtta medlemmar, där fyra studerade Civilingenjör i mjukvarutek-nik och fyra studerade Civilingenjör i datatekmjukvarutek-nik vid Linköpings universitet. Medlemmarna hade under sina tidigare studieår samlat på sig olika erfarenheter inom mjukvaruutveckling. Medlemmarna hade även arbetat i projekt som innehållit dokumentskrivning och arbete i större grupper. Utifrån dessa erfarenheter och kunskap från kurser i programutvecklingsme-todik sattes en del riktlinjer för att strukturera projektets arbetsgång och för att underlätta kommunikation och distribution av arbetsuppgifter. Några av de viktigare riktlinjer gruppen satte upp var att alla medlemmar skulle reagera på meddelanden som rörde beslut där en överenskommelse inom gruppen var nödvändig, eller meddelanden som innehöll informa-tion som hela gruppen behövde vara medveten om. Det ansågs viktigt för gruppen att alla medlemmar reagerade på viktiga meddelanden så att det kunde bekräftas att informationen hade nått alla, vilket var särskilt viktigt när alla arbetade på distans.

(13)

2.5. Liknande lösningar

2.5

Liknande lösningar

Det finns gratisprogramvaror för förståelse av programkod som exempelvis GPROF som finns i GNU Binutils, ett profileringsverktyg för att se hur funktioner har anropats [1]. Erics-son har verktyget CodeCompass, ett verktyg för kodförståelse av stora mjukvarusystem med flera olika diagram [2]. Det finns också andra verktyg med sluten källkod som exempelvis aiT WCET [3] eller RapiTime [4] för att analysera värsta exekveringstiden. BPSA försöker inte er-sätta eller konkurrera med någon av dessa programvaror utan fungerar som ett specialiserat verktyg anpassat för Saabs arbetsmetod.

(14)

3

Teori

3.1

Assemblerinstruktioner och maskinkod

Assemblerinstruktion är en representation av maskinkod i en mer mänskligt läsbar form de-signat för en viss processortyp. En processor kan inte exekvera en assemblerinstruktion direkt utan den måste assembleras ner till maskinkod vilket är en binär sekvens. Assemblerinstruk-tioner används istället för maskinkod för att maskinkoden är för obskyr för att programmera med [5]. I rapporten används instruktion synonymt med assemblerinstruktion.

3.2

PowerPC™

PowerPC är en mikroprocessor-arkitektur som gemensamt utvecklades av Apple, IBM och Motorola på 90-talet. PowerPC är en RISC-arkitektur (Reduced Instruction Set Computing), vilket innebär att processorns samtliga instruktioner är relativt korta och enkla. Den version av instruktionsuppsättningen som används i projektet är Power ISA v.2.03 [6].

Vid funktionsanrop skriver processorn automatiskt returadressen till ett länkregister (eng. link register). För att göra flera funktionsanrop djupare behöver det som ligger på länkregistret flyttas för att inte bli överskrivet vid nästa funktionsanrop. Räkneregistret (eng. count register) är ett speciellt register för hoppinstruktioner (eng. branch instructions) och kan minskas auto-matiskt vid några hoppinstruktioner. [7]

Uppsättningen av instruktioner i PowerPC är uppbyggt på så sätt att alla läsinstruktioner (eng. load instructions) börjar på l, skrivinstruktioner (eng. store instructions) börjar på st och hoppinstruktioner börjar på b. [8]

Enligt IBM:s dokumentation för PowerPC-instruktionsuppsättningen finns olika format på hoppinstruktioner. Formaten finns i tabell 3.1 där xx i tabellen är något av villkoren i tabell 3.2. Det är möjligt att xx är tom. I det fallet hoppar instruktionen ovillkorligt. Instruk-tionerna markerade med * kan endast ha villkoren markerade med *. [9]

(15)

3.2. PowerPC™

Format Förklaring

bxx Hoppar en given mängd steg relativt nuvarande adress om xx är sant. bxxa Hoppar absolut till en given adress om xx är sant.

bxxl Hoppar en given mängd steg relativt nuvarande adress och sätter adressen på instruktionen efter nuvarande instruktionen på länkregistret om xx är sant. bxxla Hoppar absolut till en given adress och sätter adressen på instruktionen efter

nuvarande instruktionen på länkregistret om xx är sant. bxxlr Hoppar till adressen på länkregistret om xx är sant.

bxxlrl Hoppar till adressen på länkregistret och sätter adressen på instruktionen efter nuvarande instruktionen på länkregistret om xx är sant [8].

bxxctr Hoppar till adressen på räkneregistret om xx är sant.

bxxctrl Hoppar till adressen på räkneregistret och sätter adressen på instruktionen efter nuvarande instruktionen på länkregistret om xx är sant.

bdnxx* Har två varianter beroende på indata antingen minskar räkneregistret och hoppar till en given adress om räkneregistret inte är noll och xx är sant, el-ler minskar räkneregistret och hoppar till en given adress om räkneregistret inte är noll och xx inte är sant.

bdzxx* Har två varianter beroende på indata antingen minskar räkneregistret och hoppar till en given adress om räkneregistret är noll och xx är sant, eller mins-kar räkneregistret och hoppar till en given adress om räkneregistret är noll och xxinte är sant.

Tabell 3.1: Hoppinstruktioner som finns i PowerPC - E500

Villkor Förklaring eq Equals.* ne Not equals.*

le Less than or equals.* lt Less than.*

gt Greater than.* so Summary overflow.* ge Greater than or equals.* ns Not summary overflow.* nl Not less than.

ng Not greater than.

nu Not unordered (after floating-point comparison). un Unordered (after floating-point comparison). nz Not zero.

z Zero.

(16)

3.3. Körningslogg

3.3

Körningslogg

En körningslogg är en fil som listar vilka delar av funktioner som exekverats vid en kör-ning av ett program, i den ordkör-ning de exekverats. Första gången en del av en funktion dyker upp i loggen visar den de assemblerinstruktioner som utgör den delen av programmet. Fi-gur 3.1 visar ett utdrag från en körningslogg. I utdraget går det att se att delar av funktionerna function_under_test, f1 och f2 körs. Trace 0 : 0 x6063b340 [00000000/10000 a60 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b4c0 [00000000/10000 a70 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b6c0 [00000000/100009 a8/0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b8c0 [00000000/1000067 c /0 x6000 ] f 2 Trace 0 : 0 x6063a040 [00000000/1000061 c /0 x6000 ] f 1 Trace 0 : 0 x6063bac0 [00000000/100006 d0/0 x6000 ] f 2 Trace 0 : 0 x6063bcc0 [00000000/10000 a10 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b4c0 [00000000/10000 a70 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b6c0 [00000000/100009 a8/0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b8c0 [00000000/1000067 c /0 x6000 ] f 2 Trace 0 : 0 x6063a040 [00000000/1000061 c /0 x6000 ] f 1 Trace 0 : 0 x6063bac0 [00000000/100006 d0/0 x6000 ] f 2 Trace 0 : 0 x6063bcc0 [00000000/10000 a10 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b4c0 [00000000/10000 a70 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b6c0 [00000000/100009 a8/0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063b8c0 [00000000/1000067 c /0 x6000 ] f 2 Trace 0 : 0 x6063a040 [00000000/1000061 c /0 x6000 ] f 1 Trace 0 : 0 x6063bac0 [00000000/100006 d0/0 x6000 ] f 2 Trace 0 : 0 x6063bcc0 [00000000/10000 a10 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x 6 06 3 b f 40 [00000000/10000 aa4 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6 0 63 c0 c 0 [00000000/10000 ac0 /0 x6000 ] f u n c t i o n _ u n d e r _ t e s t Trace 0 : 0 x6063c300 [00000000/10000 bc4 /0 x6000 ] r u n _ t e s t

Figur 3.1: Utdrag från körningslogg

3.4

Disassembly-fil

En disassembly-fil är en representation av en kompilerad exekverbar fil som innehåller filens instruktioner på ett läsbart format. Figur 3.2 visar ett utdrag från en disassembly-fil. I utdraget syns en del av funktionen f2, de assemblerinstruktioner funktionen utgör och minnesplatsen för varje instruktion.

3.5

QEMU

QEMU är programvara som används för emulering och virtualisering av hård- och mjukvara. QEMU har en funktion som heter User Space Emulation vilket låter QEMU köra program-vara kompilerad för en processorarkitektur på en annan processorarkitektur. Det innebär att PowerPC-instruktioner kan köras på en x86-processor. I User Space Emulation kan QEMU logga vilka assemblerinstruktioner som körs på processorn och vilka funktioner de tillhör. Det är denna körningslogg som trace-analysatorn analyserar. [10]

(17)

3.6. GNU Binutils och disassemblering 1000067 c <f2 > : 1000067 c : 94 21 f f e0 stwu r1 , − 3 2 ( r 1 ) 1 0 0 0 0 6 8 0 : 7 c 08 02 a6 mf l r r 0 1 0 0 0 0 6 8 4 : 90 01 00 24 stw r0 , 3 6 ( r 1 ) 1 0 0 0 0 6 8 8 : 93 81 00 10 stw r28 , 1 6 ( r 1 ) 1000068 c : 93 a1 00 14 stw r29 , 2 0 ( r 1 ) 1 0 0 0 0 6 9 0 : 93 e1 00 1 c stw r31 , 2 8 ( r 1 ) 1 0 0 0 0 6 9 4 : 7 c 3 f 0b 78 mr r31 , r 1 1 0 0 0 0 6 9 8 : 90 7 f 00 0 c stw r3 , 1 2 ( r 3 1 ) 1000069 c : 90 9 f 00 08 stw r4 , 8 ( r 3 1 ) 100006 a0 : 3d 40 10 0b l i s r10 , 4 1 0 7 100006 a4 : 39 4 a 10 b0 addi r10 , r10 , 4 2 7 2 100006 a8 : 81 6 a 00 04 lwz r11 , 4 ( r 1 0 ) 100006 ac : 81 4 a 00 00 lwz r10 , 0 ( r 1 0 ) 100006 b0 : 31 2b 00 01 addic r9 , r11 , 1 100006 b4 : 7d 0 a 01 94 addze r8 , r 1 0 100006 b8 : 3d 40 10 0b l i s r10 , 4 1 0 7 100006 bc : 39 4 a 10 b0 addi r10 , r10 , 4 2 7 2 100006 c0 : 91 0 a 00 00 stw r8 , 0 ( r 1 0 ) 100006 c4 : 91 2 a 00 04 stw r9 , 4 ( r 1 0 ) 100006 c8 : 80 7 f 00 0 c lwz r3 , 1 2 ( r 3 1 ) 100006 c c : 4b f f f f 51 b l 1000061 c <f1 > 100006 d0 : 7 c 68 1b 78 mr r8 , r 3 100006 d4 : 3d 20 10 0b l i s r9 , 4 1 0 7 Figur 3.2: Utdrag från disassembly-fil

3.6

GNU Binutils och disassemblering

GNU Binutils är en samling av program för att hantera binärfiler. Flera av programmen kan översätta maskinkod till och från assemblerkod [11].

• objdump [12] kan visa information om objektfiler. Med -d flaggan kan objdump disas-semblera en exekverbar fil till en disassembly-fil med de assemblerinstruktioner som programmet kör.

• addr2line [13] kan hämta vilken fil och kodrad som en adress i ett kompilerat program motsvarar.

3.7

Worst Case Resource Usage

Worst Case Resource Usage är inom datavetenskap en term för att beskriva högsta möjliga användandet av en resurs hos en algoritm, kodblock eller ett system. Vanligt är att den åsyf-tade resursen är tid, men även minnesresurser eller antal instruktioner som ska köras kan avses. I projektet avser Worst Case Resource Usage det maximala antalet instruktioner. [14]

(18)

3.8. Python

3.8

Python

Under projektet användes Python 3.8.5 [15]. Utöver grundbiblioteket användes PEP-8 och ett antal Python-verktyg:

• PEP-8 – En kodstandard för Python [16].

• Black – En kodformatterare för Python som följer PEP-8. Den har mycket små konfigu-rationsmöjligheter, vilket resulterar i att all kod som formaterats med Black ser likadan ut oavsett vem som skrivit den [17].

• Flake8 – En kodkontrollerare för Python som följer PEP-8. Den har relativt stora kon-figurationsmöjligheter så att man enkelt kan kombinera den med en kodformatterare som Black [18].

• TkInter – Pythons standard GUI (Graphical User Interface) paket [19].

3.9

Kontinuerlig integrering (Continuous Integration)

Kontinuerlig integrering är ett arbetssätt som genom att integrera små kodbitar till applika-tionens kodbas vill framhäva fel tidigt och minska slösad arbetstid.

Kontinuerlig integration kräver inte automatiserade tester men förknippas starkt med det. Vanligtvis verifieras varje integration genom att automatiskt bygga och testa kodbasen, vilket borde tillåta bättre detektion av buggar. [20]

3.9.1

GitLab Pipelines

GitLab Pipelines är GitLabs version av automatiserad byggning och testning av kod för att underlätta implementation av kontinuerlig integration.

3.10

Parprogrammering

Parprogrammering är ett system som dikterar att två programmerare ska sitta och arbeta på samma kod samtidigt. Syftet med detta är att öka kodkvalitén dels genom att lösningar på problem kan diskuteras, dels att misstag kan upptäckas. [21]

Mer om parprogrammering finns i kapitel H.

3.11

Scrum

Scrum är en arbetsmetodik för att utveckla, leverera och uppehålla stora komplexa mjukvaru-projekt [22]. Det finns flera aspekter i Scrum som används för att iterativt och stegvis utveckla mjukvaruprojekt samt att minimera onödig dokumentation. Det inkluderar följande aspek-ter;

• Standup – Ett kort möte där alla medlemmar berättar var de ligger i sitt arbete. I renod-lad Scrum är en daglig standup standard,

• Sprint – En förutbestämt indelad tidsperiod, på vanligtvis två veckor, där aktiviteter utförs,

• Backlogg – En lista över aktiviteter som ska utföras under en sprint,

• Planeringsmöte – Ett möte i början av en sprint där aktiviteter inför sprinten definieras och läggs till i backlogg,

• Retrospective – Ett möte i slutet av varje sprint där den gångna sprinten utvärderas i syfte att förbättra processen till nästa sprint. [23]

(19)

4

Metod

I detta avsnitt beskrivs hur projektets arbete strukturerats, hur erfarenheter dokumenterats och samlats in och hur produktens kundevärde har utvärderats.

4.1

Utvecklingsmetod

Nedan beskrivs hur olika utvecklingsmetoder använts under projektet gång för att säkerställa hög kvalitet på produkten som utvecklats. I projektet användes olika grupproller för att sä-kerhetsställa att BPSA utvecklas enligt vissa kriterier respektive roll ansvarade för, och detta gjordes så att värdet för kunden kunde maximeras. Dokumenten användes för att kunna re-dovisa vilka kriterier som existerade och hur de skulle implementeras under projektets gång. Arbetsmetoden, versionshantering, kod- och dokumentkvalitet, gruppmöte och utvecklings-verktyg användes för att iterativt och effektivt kunna implementera de olika kriterierna som definierades av projektmedlemmarna i dokumenten.

4.1.1

Grupproller

I projektet hade projektgruppen blivit tilldelade roller i syfte att förbättra samarbetet i grup-pen och utförandet av projektet.

Analysansvarig

Analysansvarig hade som ansvar att undersöka, kommunicera och formulera kundens verk-liga behov. Dessa behov skulle sedan förmedlas till resterande projektmedlemmar och do-kumenteras som kundkrav i projektets kravspecifikation. Analysansvarig hade mest kontakt med teamledaren och arkitekten.

Arkitekt

Arkitekten ansvarade för att projektet skulle ha en stabil arkitektur och identifierade dess komponenter och gränssnitt. Arkitekten hade huvudansvar för de teknikval som gjorts. Vid konflikter om tekniska frågor hade arkitekten det näst sista ordet, då efter teamledaren. Ar-kitekten är även ansvarig för framtagande av systemanatomin

(20)

4.1. Utvecklingsmetod

Dokumentansvarig

Dokumentansvarig ansvarade för att alla dokumentmallar, logotyper, ändringsrutiner och deadlines följes. Stora delar av dess arbete skulle samordnas med kvalitetssamordnare och konfigurationsansvarig.

Konfigurationsansvarig

Konfigurationsansvarig skulle bestämma vilka arbetsprodukter som skulle versionshanteras, på vilket sätt detta skulle ske och säkerställde att det också skedde på korrekt sätt. Om pro-jektet skulle sammanställas till en utgåva skulle den konfigurationsansvarige bestämma vilka arbetsprodukter som ingick i denna.

Kvalitetssamordnare

Kvalitetssamordnaren var huvudansvarig för att säkerhetsställa kvalitet men var inte ensam i att utföra arbete så att det blev kvalitativt. Huvudsakliga uppgifter var att utbilda, planera och resonera över kvalitet som sedan sammanställdes i en kvalitetsplan.

Teamledare

Teamledaren var den som knöt tillsammans laget och som förde arbetet framåt. Teamledaren coachade, ansvarade för arbetsmiljö, representerade projektet och hade sista ordet när det behövdes. Teamledaren hade huvudansvaret för projektplanen.

Testledare

Testledaren var främst ansvarig för systemets status, hur verifiering och validering av pro-jektet skulle skötas samt att testa kvalitetskraven. Testledaren hade även huvudansvar för testplanen och testrapporter.

Utvecklingsledare

Utvecklingsledaren ansvarade främst för vilken utvecklingsmiljö som skulle användas, hur tester organiserades och ansvarade även för detaljer i utvecklingsdesignen.

4.1.2

Dokument

Under projektets gång skapades ett antal dokument för att hjälpa att uppnå och redovisa projektets mål.

Arkitekturdokument

Arkitekturdokumentet var en form av systemöversikt som beskrev de tänkta användarna, krav och begränsningar som kunde resultera i en realisering av systemet. Det skulle finnas välgrundade motiveringar till val - och det som förkastats - i relation till komponenter, gräns-snitt, vyer och lösningar.

Gruppkontrakt

Gruppkontraktet var ett avtal mellan alla projektmedlemmarna om hur deras agerande mot varandra inom ett personligt och arbetsmässigt sätt skulle hanteras och tillåtas.

(21)

4.1. Utvecklingsmetod

Kravspecifikation

Kravspecifikationen beskrev alla de krav som kunden och projektgruppen definierat och de-ras prioriteringsordning. Speciellt fokus skulle läggas på att separera kundkrav från tekniska krav, funktionella och icke-funktionella krav.

Kvalitetsplan

Kvalitetsplanen beskrev de processer som skulle användas för statisk kontroll av arbetspro-dukter, processer och resurser. Kvalitetsplanen beskrev även hur samarbete, kommunikation, beslut och utvärdering skulle ske för att bidra till ett kvalitativt projekt.

Kundkontrakt

Kundkontraktet beskrev vilken äganderätt, finansiell ersättning och hur eventuell sekretess-belagd information skulle hanteras. Det definierade även hur tvister om kontraktet skulle hanteras. Detta kontrakt skrevs på av kunden Saab och alla projektmedlemmar.

Projektplan

Projektplanen beskrev projektets bakgrund, avgränsningar, syfte och arbetsmetod. Vidare beskrev den i detalj hur projektet organiserades, så som vilken roll varje person hade, vil-ken kunskap som fanns, vilvil-ken träning som behövdes och hur kommunikationen i projektet skulle gå till. Tid, resurser och riskhantering inkluderades även i projektplanen.

Systemanatomi

En systemanatomi är en riktad acyklisk graf som visar funktionella beroenden för ett system. Systemanatomin hjälper till med att ge en översikt över projektet och de delar som behöver implementeras. Projektets systemanatomi kan ses i figur 5.2.

Testplan

Testplanen beskrev vad som skulle testas i projektet. Detta inkluderade funktionstester, an-vändbarhetstester och deras olika nivåer. I testplanen beskrevs även testprocessen som inklu-derade vilka metoder, system och typer av test som skulle utföras.

Testrapport

Testrapporten beskrev vilka tester som körts och deras utfall. Den beskrev också den data, de avvikelser och de åtgärder som resulterat från de tidigare körda testerna och deras utfall. Tidrapporter

Tidrapporten redovisade all den tid som projektmedlemmarna hade lagt vid olika arbetstill-fällen så att den bestämda tidsplaneringen i avsnitt 1.5 följdes och att arbetet inte avvek från planeringen.

4.1.3

Arbetsmetod

Under utvecklingens gång användes arbetsmetoden Scrum, med en del modifikationer för att bättre passa projektgruppens förutsättningar. Scrum valdes för att iterativt och systematiskt kunna planera, beskriva, utveckla och redovisa projektet. Detta var viktigt för att maximera det värde som kunde skapas för kunden. Eftersom kommunikation med kunden om deras krav pågick kontinuerligt kunde den iterativa arbetsmetoden minska slösad utvecklingstid och anpassa utvecklingen till uppdaterade krav.

(22)

4.1. Utvecklingsmetod

Standups

Eftersom projektet inte skedde på heltid hölls standups inte varje dag utan två gånger i vec-kan. I och med olika scheman upplevdes det också svårt att bestämma fasta mötestider var-je vecka på förhand. Istället skedde standup-möten i skriftlig form. Trots den annorlunda formen på standupsen vad förhoppningen att de skulle öka medvetenheten om vad andra arbetade med inom projektgruppen. Det gav även möjlighet till att identifiera problem som medlemmarna upplevde just då, och därefter anpassa processen. Frågorna som ställdes är inspirerade av de vanliga som används i Scrum.

Varje måndag och torsdag innan klockan 12:00 skulle varje projektmedlem svara på föl-jande tre frågor:

1. Vad har jag gjort sen senast? 2. Vad ska jag göra till nästa standup? 3. Vad har jag för problem?

Sprints

Projektet delades upp i sex sprints. Varje sprint bestod av två kalenderveckor. Under början av varje sprint gjordes även mätningar för att i slutet av sprinten kunna utvärderas under sprintens retrospective. Information hur en retrospective gick till finns i avsnitt 4.2.3.

Planeringsmöte

I början av varje sprint höll gruppen ett planeringsmöte. Vid planeringsmötet bestämdes vil-ka uppgifter som skulle arbetas med under sprinten. Dessa räknades till antalet och placeras i sprintens backlogg.

Backlogg

Backloggen innehöll de aktiviteter som skulle göras under en sprint, men som ännu inte var avklarade. Allt eftersom sprinten fortgick och uppgifter genomfördes blev backloggen korta-re och kortakorta-re. Under varje sprint mättes backloggens storlek och hur många av aktiviteterna som klarades av under sprinten.

4.1.4

Versionshantering

I projektet användes Git för att versionshantera kod och dokument. Versionshantering an-sågs som ett viktigt verktyg för att säkerställa att alla ändringarna som gjordes skulle kunna granskas innan deras implementation och att ändringarna efter deras implementation alltid var reversibla och överskådliga. Granskning ansåg gruppen skulle öka kundvärde och att ar-betet var reversibelt och överskådligt ansåg gruppen skulle främja enklare vidareutveckling. I projektet användes två typer av Git-grenar med olika funktioner:

• En enskild huvud-gren som höll den senaste fungerande versionen av produkten. • Flera funktionalitetsgrenar som utgick från huvud-grenen. Där implementerades ny

funktionalitet som sedan integrerades med huvud-grenen. Innan integration granska-des och godkängranska-des grenen av projektgruppen.

(23)

4.2. Metod för att fånga erfarenheter

Kod- och Dokumentgranskning

För att granska kod och dokument användes Merge Requests i GitLab. När arbetet på en gren var färdigt skickades en förfrågan till övriga projektmedlemmar att integrera den med huvud-grenen. Väl bekräftad av två övriga projektmedlemmar integrerades den nya grenen med huvud-grenen.

4.1.5

Kod- och Dokumentkvalitet

Black och Flake8 användes i automatiska testningar för att garantera att koden hade rätt for-mat enligt PEP8 standard i Python3. Kunden hade uttryckt att vid potentiell vidareutveckling kommer verktygen Black och Flake8 användas. För att förenkla potentiell vidareutveckling valdes då också att koden skulle granskas med samma verktyg och krav.

All kod och alla dokument som skrevs granskades också som beskrivet i avsnitt 4.1.4. Granskningen utfördes för att minska risken för felaktiga uppgifter och funktioner i doku-ment respektive kod. Att hitta dessa fel tidigt ansågs viktigt för att minska behovet av tidkrä-vande korrigeringar senare i projektet och för att kunna fokusera på att implementera mer värde för kunden.

4.1.6

Gruppmöte

Gruppmöten användes för att diskutera olika ändringar eller beslut som antingen berörde hela gruppen eller där den ansvariga rollen inte ansåg att dess expertis inom området var tillräcklig för att ta beslutet. Information om relevanta ändringar från externa/interna aktörer som ansågs större än vad som kunde beskrivas i ett gruppmeddelande diskuterades även vid dessa möten.

4.1.7

Utvecklingsverktyg

Projektet hade inga krav på utvecklingsverktyg, utan var istället ett val varje enskild person i projektgruppen gjorde själva. Ett rekommenderat verktyg i projektet var Visual Studio Co-de [24] med tilläggsprogrammet Live Share [25]. Detta tilläggsprogram använCo-des av gruppen för att kunna arbeta på kod parallellt och att dessa ändringar uppdaterades direkt.

4.2

Metod för att fånga erfarenheter

En viktig aspekt av projektet var att hitta och dokumentera lärdomar som kunde dras från de erfarenheter gruppen hade under projektets gång. För att fånga erfarenheter tillämpande gruppen flera olika metoder. På det sättet kunde risken för att erfarenheter skulle gå förgång-na utan att dokumenteras minimeras.

4.2.1

Möten

Varje vecka höll gruppen tillsammans ett möte med handledare där handledaren uppdate-rades om hur arbetet gick och vad som skulle göras till nästa möte. Under handledarmötet fördes ett mötesprotokoll för att senare kunna följa upp vad som sagts på ett möte. På detta sätt uppdaterades också de projektmedlemmar som råkat missa ett möte.

4.2.2

Standups

Hur gruppen arbetade med standups beskrivs närmare i kapitel 4.1.3. Resultatet av dessa standups dokumenterades i en kanal på Microsoft Teams så att det var möjligt att gå tillbaka och läsa om vad som gjorts under projektets gång, och extrahera lärdomar när erfarenheter kring projektet skulle samlas in.

(24)

4.2. Metod för att fånga erfarenheter

4.2.3

Retrospective

Det viktigaste tillfället för att fånga erfarenheter var de retrospective-möten som hölls i slutet av varje sprint. Under dessa diskuterades gruppens erfarenheter från den senaste sprinten och konkreta förslag för att förbättra det framtida arbetet togs fram.

Diskussionerna under retrospective-möten utgick från tre frågor: 1. Vad har fungerat bra denna sprint?

2. Vad har fungerat dåligt denna sprint? 3. Vad kan förbättras till nästa sprint?

Diskussionen föregicks med att medlemmarna fick besvara en sprintenkät om hur den föregående sprinten gått, vilken finns beskriven i 4.2.4.

Andelen av uppgifterna som lades på backloggen och blivit färdigställda mättes för att på framtida planeringsmöten kunna uppskatta tidsåtgången bättre.

4.2.4

Sprintenkät

I samband med retrospective-mötet gjordes även en enkät för att få fler mätvärden till varje sprint. Varje projektmedlem fick på en skala mellan 1–5 besvara hur mycket den håller med om fem påståenden, där 1 betydde att de inte höll med alls och 5 betydde att de höll med helt. Utifrån medelvärdena på dessa kunde trender kring kvalitén på gruppens sprintplanering upptäckas. De fem påståendena som ställdes och analyserades var följande:

1. Jag känner att denna sprint var väl planerad.

2. Det fanns alltid något för mig att göra under denna sprint. 3. Aktiviteterna jag utförde denna sprint var tydligt definierade. 4. Aktiviteterna var lagom stora denna sprint.

5. Jag är nöjd med de aktiviteter jag tilldelades.

Enkäten gav även tillfälle för gruppens medlemmar att svara på de tre retrospective-frågorna i skriftligt format för att försäkra att alla hade möjlighet att komma till tals och att ingenting glömdes bort.

4.2.5

Reflektion

Vid slutet av projektet delades en reflektionsenkät ut med fem frågor och ett påstående för varje projektmedlem att besvara.

1. Vilken är den viktigaste erfarenheten du tar med dig från projektet? 2. Vilka lärdomar tar du med dig från projektet?

3. Är du nöjd med arbetsmetodiken vi använt under projektet? Vad hade kunnat göras annorlunda?

4. Om du skulle göra om projektet, vad hade du gjort annorlunda? 5. Jag är nöjd med det vi utvecklat.

6. Är det något mer du vill nämna om projektet?

Reflektionsenkätens syfte var att skapa en bild av de erfarenheter projektmedlemmarna kunde ta med sig från projektet och vad de hade velat göra annorlunda. Enkätsvaren lästes sedan igenom och deras budskap sammanfattades.

(25)

4.3. BPSA:s värde för kunden

4.3

BPSA:s värde för kunden

För att förstå hur BPSA kunde skapa värde för kunden hölls ett demonstration av produkten och kunden frågades i slutet av projektet ett antal frågor. Dessa frågor var:

• Fungerar verktyget?

• Vad tycker ni om verktyget?

• Är verktyget användbart i ert arbete?

• Var i ert arbeta kan verktyget användas, och vad kommer det användas till? Svaren på dessa frågor antecknades och sammanställdes.

4.4

Framtagning och uppföljning av systemanatomi

En systemanatomi togs tidigt fram av projektgruppen genom att diskutera olika sätt som pro-jektet skulle kunna genomföras. Genom propro-jektet användes systemanatomin för att skapa en gemensam bild inom gruppen för hur projektet skulle utvecklas. Systemanatomin uppda-terades genom projektet när nya designbeslut gjordes så att det alltid fanns en uppdaterad systemanatomi att använda i utvecklingsarbetet.

4.5

Vidareutveckling av BPSA

Potentiella vägar för vidareutveckling av BPSA kommer från två källor: • Önskemål från kund av funktioner som inte implementerats i BPSA. • Idéer från projektgruppen.

(26)

5

Resultat

I det här kapitlet beskrivs projektets resultat. Resultatet består av en systembeskrivning, en processbeskrivning av den aktuella processen, vad projektet har för värde för kunden, de gemensamma erfarenheter som fåtts samt en översikt över de individuella bidragen.

5.1

Systembeskrivning

Systemet är byggt för att analysera disassembly-filer och körningsloggar som producerats vid körning av kundens mjukvara. Systemet visas i figur 5.1. I systemet finns tre potentiella källor för en analys, de kan väljas med hjälp av kommandoradsargument. Dessa källor är:

• En körningslogg som analyseras av trace-analysatorn.

• En disassembly-fil som analyseras av disassembly-analysatorn. • En JSON-fil med en sparad analys som läses in av analysspararen. Analysen skickas till någon eller flera av:

• Visualiseraren som visar analysen i ett grafiskt gränssnitt. • Analysspararen som sparar analysen till en JSON-fil. • Text genom att analysen skrivs ut till terminalen.

Vart analysen skickas väljs också med hjälp av kommandoradsargument.

5.1.1

Systemanatomi

Systemanatomin som togs fram för projektet visas i figur 5.2. Systemanatomin ändrades mi-nimalt under projektet då systemets arkitektur inte ändrats nämnvärt. Systemanatomin var till stor nytta i projektets början då det fick projektgruppen att tänka igenom systemets kon-struktion innan arbetet började. Under utvecklingen av projektet var systemanatomin av be-gränsad användning.

(27)

5.1. Systembeskrivning

Körningslogg

Trace-analysator

Analyssparare

Grafiskt gränssnitt

Disassembly-fil

Disassembly-analysator

JSON

Figur 5.1: En övergripande bild på systemet

5.1.2

Datastruktur

Den data som skickas mellan komponenterna är i en trädformad datastruktur. Trädet har en rotnod och varje nod kan ha ett godtyckligt antal undernoder, men endast en övernod. Vilken data som trädet representerar och vilken data som sparas i trädet beror på om trädet gene-rerats av trace-analysatorn, som beskrivs i 5.1.3, eller disassembly-analysatorn, som beskrivs i 5.1.4. För ett träd från trace-analysatorn representerar varje nod ett funktionsanrop, och för ett träd från disassembly-analysatorn representerar varje nod en delning i det potentiella programflödet.

Trädet har metoder för att skapa loopar i trädet. Loopar skapas genom att rekursivt itere-ra över trädet och identifieitere-ra noder eller grupper med noder som upprepas efter vaitere-randitere-ra. När en loop är identifierad skapas en ny nod under vilken en uppsättning av de upprepade instruktionerna placeras. Resterande av de upprepade noderna raderas, och i den nya noden uppdateras nodens loopräknare som visar hur många gånger som instruktionerna upprepa-des.

Trädet har även metoder för att slå ihop olika, men liknande, träd. Träd liknar varandra om den enda skillnaden mellan dem är att dess loopar upprepas olika många gånger. Träd slås ihop genom att rekursivt iterera genom dem och uppdatera looparnas loopräknare. Varje nod har en hög och en låg loopräknare som används för att visa variansen för loopen mellan olika körningar. När hela trädet har itererats över raderas det andra trädet.

(28)

5.1. Systembeskrivning Trace-fil-parser Tkinter-fönster som visualiseringen körs i Beräkna data: Program- exekverings-flödesschema Beräkna data: Antalet intressanta instruktioner använda Beräkna data: Program-exekveringsträd Beräkna data: Annan intressant data från trace-fil Objektfils-parser Visualiera data Spara / ladda analys från fil

Figur 5.2: En övergripande systemanatomi

5.1.3

Trace-analysator

Trace-analysatorns syfte är att tolka och analysera en körningslogg genererad från QEMU av programmet. Från körningsloggen skapar trace-analysatorn ett träd som visar programmets exekvering. Det sker genom att analysera hoppinstruktioner som modifierar länkregistret i processorn. Med dessa kan man avgöra om ett funktionsanrop har skett eller om program-met har returnerat från en funktion. För villkorliga hopp jämförs adressen för nästa instruk-tion som exekveras med den adress som skulle exekveras om hoppet inte görs. Om dessa är lika kan man vara tillräckligt säker på att ett hopp inte gjorts, annars har ett hopp gjorts. Ut-ifrån analysen skapas ett träd där varje nod är ett funktionsanrop. Alla funktionsanrop som funktionen gör sparas som undernoder till funktionens nod.

Trace-analysatorn sparar även antalet instruktioner och läs- och skrivinstruktioner som varje funktion har exekverat och sparar det i trädet. Med hjälp av detta kan man enkelt beräk-na det totala antalet instruktioner som ett funktionsanrop ger upphov till genom att rekursivt summera nodens instruktioner med alla undernoders instruktioner.

5.1.4

Disassembly-analysator

Disassembly-analysatorn skapar ett träd över alla möjliga vägar genom att den analyserar en disassembly-fil. Filen är genererad av GNU Binutils objdump från ett kompilerat program. Från analysen skapas ett träd där varje nod motsvarar varje gång som programmets exekve-ring kan gå åt två olika håll. Detta görs genom att se alla villkorliga hopp i programmet som potentiella delningspunkter. Vissa hoppinstruktioner hoppar till en adress som ligger i räk-neregistret vilket gör att analysatorn inte kan veta vart programmet skulle hoppat. För den sortens instruktioner markeras det i noden att funktionsanropets hoppadress är okänd.

(29)

5.1. Systembeskrivning

Denna komponent sparar också antalet instruktioner och läs- och skrivinstruktioner som skulle köras för varje väg genom trädet. Dessa sparas i varje nod i datastrukturen som be-skrivs i 5.1.2.

5.1.5

Instruktionstolkare

Instruktionstolkaren tolkar och kategoriserar assemblerinstruktionerna så att resten av syste-met enkelt kan veta typen av varje assemblerinstruktion. För att göra detta har instruktions-tolkaren listor med alla olika instruktioner den kan stöta på. Dessa listor är uppdelade på ett sådant sätt att man kan bestämma en instruktions typ genom att kolla om den förekommer i en viss uppsättning av listorna.

För de instruktioner som har en hoppadress finns hoppadressen ofta på olika platser i dess argument. Instruktionstolkaren har logik som extraherar hoppadressen från instruktionens argument, baserat på instruktionens typ.

5.1.6

Gränssnitt

Gränssnittets syfte är att visualisera all den data som de två analysatorerna genererar. Kom-ponenten byggs med hjälp av biblioteket Tkinter, och visualiseringen av träden efterliknas den design som används i navigationspanelen i Utforskaren i Windows 10. Figur 5.3 visar hur slutprodukten ser ut. Figuren är uppdelad i fyra delkomponenter:

A) I menyn finns det möjlighet att spara en pågående analys, ändra vilka attribut som syns i Stack tree-komponenten, återställa analysen till startläget, eller stänga ned hela gränssnittet.

B) Stack tree-komponenten är en interaktiv visualisering av hur olika kodsegment hör ihop, och deras data. Kunden hade önskemål om att det skulle gå att helt ta bort speci-fika rader, sätta egna nya attribut på rader och att kunna sätta en ny rad som rot. Öns-kemålen är implementerat med en hjälp-meny som dyker upp då man höger-klickar på en rad. Färgen på en rad är på kundens önskemål baserad på hur den förväntas hoppa. C) På ovansidan till höger finns en informationsruta som uppdateras med vilken rad som är markerad i Stack tree-komponenten. Den ger en sammanfattning av den information som kunden vill kunna se.

D) Nere till höger finns information om vad för instruktioner eller kodrader som den val-da raden i Stack tree-komponenten representerar. Där kan man se vad en rad gör för operationer, och i vilken ordning. Det går att byta mellan att se assemblerinstruktioner eller kodrader genom att högerklicka på rutan.

5.1.7

Analyssparare

Analysspararens syfte är att spara den analys man gjort till en fil. Den kan också läsa in en tidigare sparad fil så att man kan fortsätta visualiseringen av analysen. Analysen sparas i formatet JSON. Då en sparad analys i JSON-format blir stor så komprimeras den för att spara utrymme.

(30)

5.2. Kundvärde

Figur 5.3: En skärmbild på gränssnittet i det nuvarande stadiet

5.2

Kundvärde

Det kundvärde som BPSA bidrar har beskrivits av kunden med:

• Verktyget verkar fungera enligt deras förväntningar men kunden konstaterar att fram-tida vidareutveckling kan behövas. Kunden anser att arbete som utförts är bra och till-fredsställande speciellt inom den tidsgräns som existerade.

• Kunden uppskattar att genomgång av programkod och relaterade processer kommer att bli snabbare.

• Billigare och mindre komplext än andra alternativ. Kommersiella verktyg har funktionalitet- och korrekthetskrav som måste uppnås, och kunden vill bibehålla det individuella ansvaret för granskaren men göra deras arbete enklare.

• Kunden får full kontroll över källkoden.

5.3

Potentiella vidareutvecklingar av BPSA

De potentiella vidareutvecklingar av BPSA som identifierats är:

• Ett önskemål om funktionalitet från kunden som saknas är förmågan att identifiera om en loop alltid körde ett visst antal iterationer.

• Ytterligare ett önskemål var att BPSA också skulle visa vilka delar av ett program som inte har exekverat under en körning.

• Verktyget är skrivet i Python, ett högnivåspråk som inte alltid är speciellt effektivt eller snabbt. Verktyget eller delar av verktyget skulle kunna skrivas om i ett mer effektivt språk och då kunna hantera större analyser.

• En annan potentiell vidareutveckling är att modifiera BPSA så att det fungerar med andra instruktionsuppsättningar. Detta skulle utöka verktygets användningsområde till system med andra processorarkitekturer. En djupare analys om hur krävande det skulle vara finns i kapitel F.

(31)

5.4. Processbeskrivning

5.4

Processbeskrivning

Här beskrivs resultatet från utvecklingsprocessen, dess förbättringar och kvalitetskrav.

5.4.1

Standup

Från de standups som genomförts kan man genomgående se att projektmedlemmarnas svar på frågan ”Vad har jag för problem?” har varit relaterade till att det är svårt att lägga den tid som krävs på kandidatarbetet i kombination med andra kurser.

5.4.2

Backlogg

Backloggens storlek för de olika sprintarna och hur många av dessa aktiviteter som avklarats finns i tabell 5.1

Mått Sprint 2 Sprint 3 Sprint 4 Sprint 5

Antal planerade aktiviteter 11 23 26 15

Antal avklarade aktiviteter 11 22 24 14

Procent avklarade aktiviteter 100% 95,65% 92,31% 93,33% Tabell 5.1: Data över aktiviteter

Backloggen som sattes upp för den andra sprinten tog slut efter två dagar vilket gjorde att ett extra planeringsmöte behövde hållas för att utöka backloggen. Gruppen hade överesti-merat mängden arbete som aktiviteterna i den första backloggen innebar och underestiöveresti-merat sin egen arbetshastighet. Genom att analysera tidigare sprints fick gruppen en uppfattning av tidsåtgången vid olika aktiviteter vilket gjorde det enklare att planera in lagom många aktiviteter.

5.4.3

Sprintenkät

Resultatet från sprintenkäterna i varje sprint kan ses i tabell 5.2.

Enkätfråga Sprint 2 Sprint 3 Sprint 4 Sprint 5

Jag känner att denna sprint var väl planerad. 2,86 4,13 Ò 4,00 Ó 3,75 Ó Det fanns alltid något för mig att göra under

denna sprint.

3,57 4,25 Ò 4,38 Ò 4,50 Ò

Aktiviteterna jag utförde denna sprint var tydligt definierade.

4,00 4,13 Ò 4,38 Ò 4,50 Ò

Aktiviteterna var lagom stora denna sprint. 2,86 3,88 Ò 4,25 Ò 4,50 Ò Jag är nöjd med de aktiviteter jag tilldelades. 3,86 4,38 Ò 4,38 4,63 Ò

Tabell 5.2: Resultat av sprintenkät

5.4.4

Processförbättringar

Efter sprint två blev det tydligt att gruppen hade lagt för lite tid på att planera sprinten. Detta speglades i sprintenkäten vilket gjorde att det blev föremål för diskussion. Gruppen bestämde därmed att göra en tydlig, om än simpel, processförbättring i det faktum att mer tid skulle läggas på att planera sprintarna därefter.

(32)

5.5. Gemensamma erfarenheter

Detta gjordes genom att schemalägga ett möte på minst en timme i början av varje sprint där alla gruppmedlemmar samarbetade med att skapa arbetsuppgifter för sprintens backlogg med tydliga beskrivningar. Detta ledde till att det inte behövdes schemalägga extramöten i mitten av sprinten så som det gjordes för sprint två.

Något som inte var en processförbättring, men som ändå gjorde att gruppens arbetspro-cess blev bättre var att gruppen fick en ökad förståelse av kundens önskemål. Detta gjorde det enklare att planera den framtida utvecklingen vilket gjorde att arbetet flöt på bättre.

5.4.5

Kvalitetskrav

Kvalitetskraven satte tydliga mål kring kod-struktur, det skulle följa black och flake8, samt dokumentation, då alla funktioner skulle ha en docstring. Utvecklingen utgick från dessa krav vilket resulterade i läsbar och väldokumenterad kod; vilket var speciellt viktigt eftersom kunden Saab uttryckt att de vill vidareutveckla BPSA.

Att i genomsnitt 70% av uppgifterna under en sprint skulle genomföras nåddes med god marginal då minst 90% av uppgifterna klarades vid varje sprint. Kravet sattes upp tidigt i projektet, innan gruppens medlemmar hade någon vidare förståelse till hur det skulle vara att arbeta med SCRUM i ett projekt av denna storlek. SCRUM har redan krav på att varje sprint ska vara välplanerad och att alla uppgifter som inplanerats i en sprint ska genomföras. Detta gjorde att kravet i slutändan inte fyllde någon större funktion.

Det sista kvalitetskravet var att minst 60% av koden skulle testas med automatiska tester. Detta kom senare att modifieras till att exkludera det grafiska gränssnittet, men även detta krav nåddes med god marginal.

5.5

Gemensamma erfarenheter

Detta projekt är det största och mest seriösa mjukvaruprojekt som projektmedlemmarna varit med i. Detta har bidragit till att projektmedlemmarna har fått många nya erfarenheter.

5.5.1

Tidigare grafisk prototyp

Att tidigt ta fram en prototyp som man kan visa för kunden gör att man tidigt fångar even-tuella missförstånd om hur produktens design och funktion ska vara.

Gruppen tog i ett tidigt skede fram en grafisk prototyp på hur de tänkte att gränssnittet skulle kunna fungera. Det visade sig att det inte varit riktigt samma sak som kunden hade tänkt sig vilket ledde till att projektgruppen fick en tydligare bild över vad de faktiskt ville ha. Figur 5.4 visar ett första utkast av gränssnittet och figur 5.5 visar en senare version.

5.5.2

Planering av sprints

En lärdom man kan dra från avsnitt 5.4.2 är att man bör se till att det finns saker att göra även om backloggen tar slut. Man skulle till exempel kunna göra detta genom att sätta upp några preliminära aktiviteter för nästa sprint som man kan börja på tidigare om tillfället finns.

5.5.3

Reflektionsenkät

Detta avsnitt sammanfattar projektmedlemmarnas svar på reflektionsenkäten. Erfarenheter och lärdomar

Projektgruppen upplevde generellt att arbetet med en strikt tidsplanering var en viktig er-farenhet. En strikt tidsplanering upplevdes ge en bättre översikt av arbetet. I enkätsvaren beskrev en gruppmedlem att de tog med sig lärdomen av att börja arbeta i tid, så att mäng-den arbete inte blev orimligt mycket mot slutet.

(33)

5.5. Gemensamma erfarenheter

Figur 5.4: En skärmbild på gränssnittet i ett tidigt stadie

Figur 5.5: En skärmbild på gränssnittet i ett senare stadie

Kommunikation nämndes i många av gruppens enkätsvar. Omställningen till arbete i en, för gruppen, relativt stor arbetsgrupp upplevdes som en viktig erfarenhet, och även att det då blev ännu viktigare med bra kommunikation i gruppen. Planeringen som krävdes för att få åtta personer att arbeta effektivt på ett projekt framgick också som nytt för gruppen. Faktiskt arbete med arbetssätt och verktyg som kontinuerlig integration, GitLab och Scrum upplevde gruppmedlemmar som bra. Flera enkätsvar belyste också vikten av kontinuerlig kommunikation med kunden för att försäkra sig om att produkten som utvecklades var den som faktiskt efterfrågades. Distansarbetets påverkan nämndes också i flera enkätsvar. Kom-munikation och planering upplevdes som svårare som följd av distansarbetet, och

(34)

teambuil-5.5. Gemensamma erfarenheter

dingaktiviteter så som kickoffs upplevdes som viktigare än vanligt just för att främja kom-munikationen inom gruppen.

Vad hade kunnat göras annorlunda?

Gällande arbetsmetodik upplevde gruppen att Scrum-varianten som användes hade kunnat justeras. En projektmedlem upplevde att valet av att ha skriftliga Scrum standups istället för muntliga under projektet nog var ett misstag. Gruppmedlemmen ansåg att syftet med att ha standups försvann då det inte riktigt blev någon återkoppling från gruppen, åtminstone inte på samma sätt som en muntlig standup hade gett. Även beslutet att ha sprints om två veckor snarare än kortare om en vecka upplevdes som ett felaktigt beslut, eftersom veckornas arbets-fördelning varierade. Detta ledde till att medlemmarna under vissa sprints fokuserade helt på dokumentskrivande första veckan och utveckling på den andra, vilket gjorde planering och utvärdering av sprints blev svårare.

Pappersprototyper nämns också i enkäterna som en förbättringspunkt, då för att under-lätta kommunikationen med kund. Detta verktyg hade kunnat användas för att försäkra att projektgruppens bild på produkten var den samma som kunden hade.

För att förbättra kommunikationen nämns användandet av en gemensam kalender. Pro-jektmedlemmen menade att den gemensamma kalendern skulle tillåta gruppmedlemmarna att skriva upp när de planerade arbeta, och att detta skulle underlätta planeringen av gemen-samt arbete.

Hur nöjda är projektmedlemmarna med arbetet?

På påståendet ”Jag är nöjd med det vi har utvecklat.” fick projektmedlemmarna svara hur mycket de höll med på en skala 1–10 där 1 är ”Jag håller inte med alls” och 10 är ”Jag håller helt med”. I genomsnitt svarade gruppen 8,00.

(35)

5.6. Översikt över individuella bidrag

5.6

Översikt över individuella bidrag

Denna del ger en kort översikt över de individuella bidragen i rapporten.

5.6.1

Visuell analys av programkod av Sebastian Broman

En undersökning om hur anropsgrafer och flödesdiagram kan användas som visuella hjälp-medel för analys av programkod och egenskaper hos graferna. Undersökningen tar upp hur sparade analyser genererade från BPSA kan användas för att rita en anropsgraf, ett flödes-schema och en kombinerad graf över vilka vägar ett program har kört. De olika graferna genereras utifrån ett exempelprogram och presenteras. Från flödesscheman över varje funk-tion räknas cyklomatisk komplexitet ut, från anropsgrafen räknas maxdjupet ut och andra egenskaper hos graferna tillsammans med hur de kan användas diskuteras.

5.6.2

Kontinuerlig integration i mindre och korta projekt av Erik Halvarsson

Den här rapporten är en undersökning om hur användning av kontinuerlig integrering har påverkat projektet och projektmedlemmarnas produktivitet. I rapporten presenteras den ut-vecklingsmetod som kallas Kontinuerlig Integrering (eng. Continuous Integration), och några av de verktyg som krävs för att göra metoden möjlig. Rapporten undersöker intervjuer med resterande projektmedlemmar och jämför dem med resultat från tidigare litteraturstudier re-laterade till användning av kontinuerlig integrering i mindre projekt.

5.6.3

En jämförelse av centraliserade och decentraliserade

versionshanteringssystem av Victor Lells

Denna rapport är en undersökning om hur och varför versionshanteringsmarkanaden ser ut som det gör i dagsläget. I rapporten presenteras tekniska och socialhistoriska aspekter av versionshanteringssytem, olika typer av versionshanteringssytem och en jämförelse mellan dem. Rapporten tar den teori som presenterats och statistik från användningsfördelningen i versionshanteringsmarknaden, och utifrån detta analyserars kopplingarna där emellan. Slut-satsen av rapporten beskriver hur de decentraliserade versionshanteringssystem dominerar den öppna källkodsmarknaden, och detta beror bland annat på hur väl dessa projekt passar ett decentraliserat arbetsflöde.

5.6.4

Genomförande av ett projekt på distans av Abedalhkeem Najeeb

Den här rapporten är en undersökning om hur projektmedlemmars arbetstider och matva-nor blir vid distansarbete, hur projektsgruppen använder kommunikationsverktygen Zoom, Microsoft Teams och Discord, och vilka för- och nackdelarna är då man jobbar med ett pro-jekt på distans. Rapporten använder sig av en enkät som skickats ut till studenter som jobbar med samma projekttyp. Enkätdata analyseras med hjälp av grafer och jämförs med andra litteraturstudier som är relaterade till den här undersökningen.

5.6.5

Modern kodgranskning i ett litet projekt av Niklas Samuelsson

En undersökning av vad som bidrar till en effektiv kodgranskning i moderna mjukvarupro-jekt. Vidare presenteras hur projektgruppen har arbetat med kodgranskning och rapporten undersöker även hur lärdomarna om effektiv kodgranskning skulle kunna användas av pro-jektgruppen för att förbättra sin kodgranskningsprocess vid fortsatt arbete. Rapporten base-ras på en litteraturstudie av akademiska källor. Det finnes att granskare som är väl bekanta med kontexten till koden samt ett högre antal granskare är de två viktigaste faktorerna för effektiv kodgranskning.

(36)

5.6. Översikt över individuella bidrag

5.6.6

Generalisering av assembleranalys till andra instruktionsuppsättningar av

Isak Stenström

En undersökning av skillnaderna mellan olika instruktionsuppsättningar, med avseende på de instruktioner som påverkar BPSA:s funktion. Rapporten undersöker även möjligheten att modifiera BPSA för att hantera andra instruktionsuppsättningar. För någon av de instruk-tionsuppsättningar där det anses möjligt genomförs dessa modifikationer. De instruktions-uppsättningar som undersöks är ARM, RISC-V och x86. Undersökningen ger att det är möj-ligt att modifiera BPSA för att fungera med ARM och RISC-V, och modifikationen genomförs för ARM. Undersökningen ger även att BPSA tillåter enkelt byte av instruktionsuppsättning men att det skulle kunna utvecklas vidare för att göra det ännu enklare.

5.6.7

Etiskt ansvar i produktutveckling av Christian Sundkvist

En undersökning om studenters tankar kring ansvar inom produktutveckling, specifikt an-passad till den produkt de utvecklat i kursen TDDD96 – Kandidatprojekt i programvaruut-veckling vid Linköpings universitet. Undersökningen tar upp frågor om etikens roll i val av projekt både i nu- och framtiden för studenterna, om de känner sig etiskt ansvariga för den produkt de utvecklat i kursen och ifall det finns några områden inom produktutveckling som de ej tycker är etiskt försvarbara. Resultatet visar att etiken har olika betydelse från person till person och från produkt till produkt, där det ofta handlar om en etisk gråzon där andra aspekter väger in.

5.6.8

Parprogrammering på distans av William Vedin

En undersökning av parprogrammering som arbetssätt vid arbete på distans. Undersökning-en ser över gUndersökning-enerell uppfattning kring ämnet och projektgruppUndersökning-ens erfarUndersökning-enhet av det vid fram-tagandet av produkten som utvecklats. I undersökningen behandlas en kvalitativ enkätstudie på gruppens erfarenhet kring parprogrammeringen som använts under projektets gång. Det-ta innefatDet-tar både programmering med skärmdelning via discord där en person skrivit och navigerat i koden och den andra personen tittat på och kommit med förslag, och simultant programmerande vid Live Share.

(37)

6

Diskussion

Detta kapitel tolkar resultatet och utvärderar projektets och rapportens arbetssätt och meto-der.

6.1

Resultat

I detta avsnitt diskuteras projektets resultat, vad som skulle kunna gjorts annorlunda och vilka lärdomar man kan ta med sig i framtiden.

6.1.1

Alternativa implementationssätt

En alternativ implementation projektgruppen var inne på var att ha en alternativ vy av pro-grammet som är mer likt en nodgraf. Där skulle användaren få en mer överblicklig vy över hur programflödet ser ut. Denna implementation förkastades då det inte var det kunden var ute efter. En undersökning om hur en sådan implementation skulle fungera finns i kapitel A. Istället för att använda sig av objdump för att skapa en disassembly av programmet ha-de ha-det förmodligen gått att implementera ha-den ha-delen av programmet genom att analysera C och C++ kod direkt. Detta förkastades då det verkade betydligt mer komplicerat att tolka alla kodrader. För att få koden i assembler hade programmet också kunnat kompilerats med -Sflaggan i GCC för att generera assemblerkod av programkoden, nackdelen hade då va-rit att assemblerraderna inte haft en minnesadress där de var sparade vilket hade försvårat implementationen. En ytterligare nackdel med detta hade också varit att BPSA endast hade fungerat med program som kompileras med en viss kompilator och inga andra.

Figure

Updating...

References

Related subjects :