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.
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 generell uppfattning kring ämnet och projektgruppens erfarenhet 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 innefattar 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.
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 det förmodligen gått att implementera den 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.
6.1. Resultat
6.1.2
Projektets arbetsmetod
Överlag har projektets arbetsmetod fungerat bra. Dock finns det några brister i arbetsmeto- den:
• Att endast ha standups skriftligt gjorde att det blev korta svar och det bildades ingen diskussion kring problem som uppstått eller vad som ska arbetas vidare på.
• Under andra halvan av vårterminen lade gruppen betydligt mer tid på projektet och det hade varit möjligt att istället ha en sprintlängd på en vecka istället för två. Det skulle underlättat planeringen av sprintsen då färre aktiviteter hade behövts planeras från början. Många saker som utfördes under en sprint var saker som gruppen kommit på under arbetet, istället för aktiviteter från backloggen.
Alternativa arbetsmetoder
En alternativ arbetsmetodik som skulle passat projektet relativt bra är Vattenfallsmetoden. Det är en sekvensiell arbetsmetodik som är naturligt och intuitivt sätt att arbeta med projekt. Det skulle passa projektet bra då projektet har en tydlig och begränsad tidsutbredning och projektets krav är relativt väl definierade i början av projektet, då kunden var väl medvet- na om vad de ville ha. Vattenfallsmetoden är en dokumenttung arbetsmetodik vilket skulle passa med det stora antal dokument som projektet krävde. Något i Vattenfallsmetoden som inte skulle fungerat bra för projektet är integrationsmetoden, som är att man först utveck- lar alla delar och att man sedan integrerar. Detta skulle inte fungerat för projektet då det är svårt att verifiera att den komponent man skrivit fungerar som den ska utan att ha de andra komponenterna.
Projektgruppen är nöjda med att en modifierad variant av Scrum valdes som arbetsmeto- dik. Det har gett medlemmarna erfarenhet av att arbeta i en ny arbetsmetodik som kommer vara värdefull för en framtida mjukvaruutvecklingskarriär. Scrum var även ett bra val då dess flexibilitet hjälpte gruppen anpassa sig när det visade sig att kundens önskemål tolkats fel.
6.1.3
Vad återstår för att kunden ska få ut fullt värde av produkten?
Kunden ville att BPSA skulle identifiera om en loop alltid kör ett visst antal iterationer, vil- ket är något som saknas. Verktyget kan bara avgöra om en loop alltid har kört samma antal iterationer vid flera olika körningar. För att kunna veta om en loop alltid kör samma antal ite- rationer behöver verktyget förmodligen hålla koll på konstanter i programkod, vilket BPSA inte gör hittills.
BPSA skulle kunna bidra med mer värde för kunden om det kunde kombinera informa- tionen mellan disassembly-analysatorn och trace-analysatorn. Trace-analysatorn visar endast vad som faktiskt har körts medan disassembly-analysatorn visar alla vägar programmet skul- le kunna köra. BPSA skulle då kunna kombinera informationen för att visa vilka vägar som aldrig körs och eventuellt varför. Just nu kan BPSA endast visualisera informationen separat och kräver då att användaren av programmet letar reda på vilka vägar som inte körts. Vidareutveckling av produkten
De enda som vet exakt hur bra verktyget är och i vilken riktning det skulle kunna vidareut- vecklas är kunden. Det finns troligtvis andra sätt, än de som beskrevs ovan, att vidareutveckla verktyget på ett sådant sätt att det passar bättre in i kundens arbetsprocess.
6.1. Resultat
6.1.4
Uppföljning av en systemanatomi
Systemanatomin var ett effektivt verktyg för att få alla gruppens medlemmar att tänka till över projektets konstruktion tidigt. Att systemanatomin användes minimalt under utveck- lingen av projektet beror troligtvis på att den var så liten att den enkelt kunde memoreras. Detta gjorde att gruppens medlemmar inte behövde aktivt använda sig av systemanatomin för att få en överblick över projektet. Att systemanatomin inte ändrades bidrog till detta då den bild av projektet som gruppmedlemmarna hade i början av projektet fortfarande var korrekt i slutet.
För ett annat, mer komplext, system så skulle förmodligen en systemanatomi bidra under systemets utveckling genom att ge en samlad bild över systemets arkitektur och de beroen- den som systemet har.
6.1.5
Viktigaste lärdomarna inför framtiden
Under projektet har projektgruppen fått flera olika nya erfarenheter och lärdomar, några ex- empel är:
• Specifika tekniska kunskaper:
– Avancerad programmering i Python.
– Avancerad användning av Git och Merge Requests.
– Hur man arbetar enligt kontinuerlig integration tillsammans med GitLab Pipeli- nes.
• Mjukvaruutveckling i medelstora grupper. • Mjukvaruutveckling i Scrum.
• Kundkommunikation och att tolka kundens krav. • Individuella erfarenheter utifrån varje persons roll. Planering av projekttid
Projektmedlemmarna har haft eget ansvar att planera sin tid och sätta upp en tidsplan som stämmer överens med de 400 timmar som varje person skulle lägga på kursen. Sedan var det upp till projektmedlemmarna att försöka följa tidsplanen och samtidigt koordinera arbetet med de andra projektmedlemmarna.
Hade arbetet skett mer på plats på universitetet hade det varit tydligt att tiden en pro- jektmedlem spenderat på universitetet med projektet trots att det inte varit effektiv tid hade gått att skriva ner. När en projektmedlem istället suttit själv hemma och läst på en stund om delar av projektet, hanterat merge-requests, svara på mail, svara på standups och annat kan det vara svårt att veta exakt hur mycket tid som lagts ner då det är några tiotal minuter vid olika tillfällen.
Kommunikation inom gruppen
Trots att studenterna läser samma program kände studenterna inte varandra särskilt väl. Ar- betet började direkt på distans och kommunikationen i gruppen var bristfällig. Projektmed- lemmarna uttryckte att det var svårt att våga ställa frågor till varandra om saker man inte förstår. Inledningsvis handlade all kommunikation i gruppen om projektet vilket gjorde det svårt att faktiskt lära känna varandra. Vid pauser ville projektmedlemmarna inte sitta kvar och lära känna varandra utan ville istället komma ifrån datorn en stund. I början av projek- tet anordnades en virtuell kickoff där alla projektmedlemmar spelade spel online tillsammans