Testmetod

I metoden för att utföra prestandatesten finns flera brister i förutsättningarna för rättvisande resultat. Den mest uppenbara är att BCP är ett självständigt C++-program medan de övriga lösningsmetoderna integrerats i det av projektgruppen utvecklade Kotlinprogrammet. Detta skulle kunna vara en bidragande faktor till dess höga prestanda då C++-koden kompileras direkt till maskinkod och Kotlinprogrammet körts via en JVM där JIT-kompilering sker [84], vilket innebär att delar av programmet inte kompileras till maskinkod förrän de faktiskt be- hövs under körning. Då lösningsmetodernas körtid i värsta fallen skiljs med en faktor>6000 anses dock inte detta kunna redogöra för hela skillnaden och resultatets betydelse är därmed inte påverkad.

Även JVM:n i sig ger upphov till en del problem vid prestandatestning, bland annat ge- nom JIT-kompileringen. Trots dessa observerades inga signifikanta variationer i resultatet från de tre testiterationerna där ordningen på test och lösningsmetoder ändrades. Därför an- ses samtliga testresultat vara rättvisande, detta hade dock kunnat sägas med större säkerhet om ett verktyg för prestandatestning anpassat för JVM:n såsom JMH [51] hade nyttjats.

E.7. Slutsatser

E.6.4

Källkritik

I huvudsak har artiklar publicerade i vetenskapliga tidskrifter använts, samtliga av dessa referentgranskar sina artiklar. De är även alla listade som reputerliga i JournalGuide, en da- tabas för tidskrifter framtagen av Research Square vilket är en grupp av bland annat forskare, veteraner inom publicering och mjukvaruutvecklare [85]. I JournalGuide verifieras tidskrif- ters trovärdighet utgående från vilka citeringsdatabaser de är listade i, Research Square gör alltså ingen egen bedömning av tidskriften utan samlar omdömet från många oberoende or- ganisationer som arbetar med forskningsbedömnings [86]. Utifrån detta anses de i denna undersökning använda tidskrifterna vara trovärdiga.

Även fyra böcker har använts som källor, av dessa är två mycket väl citerade med 61 669 respektive 4 637 enligt Google Scholar, dessa anses därför vara så vedertagna att deras tro- värdighet inte står i tvivel. De övriga två är författade av professorer inom optimeringslära och ämnade att användas som kurslitteratur, vilket de görs vid bland annat Linköpings uni- versitet och Kungliga Tekniska högskolan. Med anledning av detta anses även dessa vara trovärdiga.

E.7

Slutsatser

I detta avsnitt presenteras slutsatser gällande ställda frågeställningar som baserats på det uppnådda resultatet och diskussionen kring detta.

1. Vilka typer av metoder finns för att lösa BPP och hur fungerar dessa? Det finns en

mängd olika sätt att lösa BPP till optimalitet med varierande effektivitet. Objektbaserad, hinkbaserad och kolumngenererande trädsökning är exempel på lösningsmetoder vilka har studerats i detalj. Samtliga fungerar genom att på olika sätt förgrena sökningen av lösnings- mängden och kapa grenar för att kunna effektivisera sökandet, strategierna för detta är an- passade efter BPP. Även generella metoder som använder trädsökning, exempelvis ojAlgo eller det proprietära alternativet CPELX kan med goda resultat användas för vissa proble- minstanser.

2. Hade någon av de undersökta metoderna kunnat appliceras i det utförda projektet? En

objektbaserad algoritm, HMTS, speciellt utvecklad för Ionbonds användningsfall har med framgång lyckats implementeras, vilket direkt visat på metodens tillämpbarhet. Även CPLEX har integrerats i det av projektgruppen utvecklade programmet. BCP, vilket är en kolumnge- nerande algoritm, har dock bedömts som så komplex att projektgruppen inte hade kunnat implementera denna inom projektets tidsbudget.

3. Hur jämför sig de undersökta metoderna mot varandra? HMTS, BCP, CPLEX och den i

projektet valda lösningen ojAlgo har jämförts i prestandatest utformade för att spegla de svå- rare instanserna som kan uppkomma i programmets avsedda användningsfall. Trots brister i testernas utförande anses resultatet vara tillförlitligt och utifrån detta har slutsatser angå- ende lösningsmetodernas effektivitet dragits. De simplaste lösningarna som heuristiker och ojAlgo presterar bra, men utklassas av de mer komplexa. Högre tidseffektivitet och i vissa fall ökad lösningskvalitet gör att dessa definitivt skulle skapa ytterligare värde för kunden. Av dessa är BCP överlägsen, vilket överensstämmer med tidigare konsensus. De lösningar som lyckats appliceras i projektet visar båda upp mycket bra prestanda i Ionbonds användnings- fall, för att säga vilken som är bäst lämpad för projektet krävs vidare undersökning av verklig användardata. Faktum att CPLEX är en proprietär lösning och därmed en kostnadsdrivare, talar dock för användning av HMTS.

F

Värdet av beskrivande

versionsinformation i mindre

projekt av Axel Nordanskog

F.1

Introduktion

I stora projekt med långa livscykler är det viktigt att dokumentera förändringar i sin kodbas från version till version. En potentiell fördel med det är att lösningar som gåtts ifrån, och inte bör försökas på igen, dokumenteras. En annan är att det kan bli lättare att identifiera när skadliga ändringar gjorts vilket i sin tur underlättar avlusning (engelska: debugging).

Speciellt bör dessa fördelar uppnås enklare med mer beskrivande dokumentation av ver- sioner, härmed benämnt versionsinformation. Frågan är dock hur värdefullt versionsinforma- tion är för mindre projekt som vårt och om dess värde väger upp för tidskostnaden att skriva den.

Som versionsinformation räknas i detta bidrag incheckningsmeddelanden (engelska: commit messages) och granskningsunderlag. Ett granskningsunderlag är i sin tur definierat som en beskrivning av de förändringar som gjorts på en gren.

F.1.1

Syfte

Syftet med detta bidrag är att undersöka värdet av beskrivande versionsinformation i vårt projekt. Med det avses versionsinformation genom vilken kan avläsas vilka förändringar som gjorts.

Bidraget beskriver hur vi har jobbat med versionsinformation och vilken effekt den har haft. Avslutningsvis vägs denna effekt mot den tid som krävts för att uppnå den. Effekten av incheckningsmeddelanden kopplas också till hur de skrivits.

F.1.2

Frågeställningar

Följande frågeställningar behandlas i detta bidrag:

1. Vilken effekt hade versionsinformation i projektet? Vad fick projektgruppen ut av

skrivna incheckningsmeddelanden respektive granskningsunderlag?

2. Vad var tidskostnaden för skrivande av versionsinformation? Hur mycket tid krävdes

3. Hur var incheckningsmeddelandena skrivna? Var de konsekvent formaterade och be- skrev de vad som ändrats samt varför och hur ändringar gjorts?

F.2

Bakgrund

Utvecklingsarbetet utfördes framför allt under fem enveckorssprintar och endast två utgåvor släpptes till kund. Redan innan det inleddes uppskattades arbetet ta fyra till fem veckor med maximalt lika många utgåvor. Versionshistoriken och speciellt utgåvehistoriken uppskatta- des därför vara enkla att hålla reda på och frågan om versionsinformations värde i ett så litet projekt uppstod. Med vår begränsade tidstillgång i åtanke var det även intressant att väga ett eventuellt värde mot den tid som krävts för att uppnå det.

Inga utgåvebeskrivningar skrevs under projektets gång eftersom de upplevdes som över- flödiga. Däremot skrevs incheckningsmeddelanden och granskningsunderlag. Resonemang- en bakom varför dessa skrevs och varför deras värden undersöktes ges nedan.

Incheckningsmeddelanden Trots att antalet utgåvor skulle bli få uppskattades antalet in-

checkningar kunna bli många. Det skulle därför hypotetiskt bli svårt att identifiera med vilken incheckning ett fel introducerats, om inte beskrivande incheckningsmeddelanden skrevs. Det skulle tvinga en till att gå igenom incheckningar, kodrad för kodrad, för att fast- ställa vilka ändringar som gjorts. Det var inte säkert att den nämnda strategin för debug- ging skulle komma att användas i projektet men den visade tecken på att ett värde, utöver övning inför framtiden, skulle kunna ges projektgruppen. Incheckningsmeddelanden skrevs för samtliga incheckningar när de lades till i Git-historiken med undantag för återställningar (engelska: reversion) och sammanfogningar (engelska: merges) vars incheckningsmeddelan- den genererades automatiskt.

Granskningsunderlag En beskrivning av utfört arbete skrevs efter näst intill var avslu-

tad Scrum-aktivitet. I princip var aktivitet var nämligen kopplad till en utvecklingsgren på Git och dessa grenar granskades innan de integrerades till master-grenen. För att ge under- lag inför dessa granskningar lämnades dessa beskrivningar som kommentarer på Scrum- aktiviteterna på Trello eller i vissa fall som inlägg i gruppens Slack-kanal för gransknings- begäran. Att var sprint tilldelades en egen permanent ”klar”-kolumn på projektets Scrum- tavla på Trello gav även en bild av när funktionalitet lagts till. Gruppen använde på så sätt projektets Scrum-tavla och granskningsunderlag snarare än utgåvebeskrivningar för att hålla reda på produktförändringar över tid.