4.4.1
Litteraturstudie
Syftet med litteraturstudien av användningsområdet för en ASIC var att identifiera nuvaran- de användningsområden för en ASIC, verktyg för utbildning inom konstruktion och design av en ASIC och även att för vilka metoder som program som B-ASIC kan underlätta i utbild- ning på avancerad nivå, exempelvis vidare studier angående konstruktion och design av en ASIC vid ett universitet.
Den litteratur som studien syftade att studera var Considerations of Teaching Digital ASIC De- sign [36] av Puhm A., Rössler P. Vidare utvärderades B-ASIC utifrån de kriterium som Puhm et al. lyfter i sin artikel för undervisning av digital ASIC design.
Utöver undervisning sökte även litteraturstudien att undersöka andra områden som en ASIC kan användas i och har använts i, detta då undersökningen sökte att besvara om B-ASIC kan vara ett lämpligt verktyg i den fortsatta utvecklingen av ASIC inom området.
4.4.2
Intervju
För att vidare undersöka B-ASIC och dess relevans för utbildning och användning genom- fördes en intervju med den kund som produkten B-ASIC är skapad för. Intervjun syftade på att undersöka vilka användningsområden som kunden ser för design av en ASIC genom di- gitala verktyg, vilken framtid B-ASIC innefattar i området för digital design av en ASIC samt vilka problem som digital design av en ASIC har.
Syftet med intervjun var att undersöka hur relevant en produkt som B-ASIC är och i vilken mån en sådan produkt kan användas i syftet att utbilda och använda produkten inom rele- vanta områden.
Intervjun genomfördes enbart på kunden för projektet B-ASIC. Intervjun genomfördes på distans genom ett formulär med frågor som kunden svarar på. Frågorna var av kvalitativ grad, det vill säga av undersökande karaktär, då svaren som söktes av kunden var åsikter och tankar kring området för konstruktion, design och användning av en ASIC. Frågorna var därmed konstruerade i syfte att uppmana till utvecklade svar med egna teorier och åsikter om respektive område. Frågor och svar sammanställs i Tabell 5.5.
4.5
Utvecklingsmetodik
Utvecklingsmetodiken genom projektets gång beskrivs nedan.
4.5.1
Dokument
Dokumentskrivningen genomfördes genom att respektive medlem i projektgruppen hade ansvar för att skriva de dokument som var anknutna till dess projektspecifika roll. De med- lemmar som inte hade något dokument anknutet till sin roll, hjälpte till att skriva på de andra medlemmarnas dokument. Fördelningen av dokument återges i Tabell 4.1. När ett dokument var färdigt granskades dokumentet av en annan medlem och eventuella åtgärder genom- fördes av dokumentets ansvarige. De olika dokumenten var levande under utvecklingen av produkten, i den mån att de uppdaterades vid behov.
4.5. Utvecklingsmetodik
Tabell 4.1: Dokument och dess respektive ansvarige. Beskrivningar av rollerna återges i Kapi- tel 4.5.8. Dokument Ansvarig Projektplan Utvecklingsansvarig Kravspecifikation Analysansvarig Kvalitetsplan Kvalitetssamordnare Testplan Testansvarig Testrapport Testansvarig Arkitekturbeskrivning Arkitekt
De olika dokumenten togs fram för att hjälpa projektgruppen att dokumentera arbetspro- cessen, kraven för produkten, projektgruppens kvalitetsprocess, projektgruppens process för tester och verifiering av krav samt produkten B-ASIC:s arkitektur.
4.5.1.1 Projektplan
En projektplan togs fram för att beskriva arbetsprocessen som projektgruppen arbetade efter. Projektets rollbeskrivningar återges i projektplanen tillsammans med milstolpar, tidsbegräns- ningar och risker. Projektplanen var ämnad att hjälpa projektgruppen att planera för vad som ska skulle genomföras under respektive iteration.
4.5.1.2 Kravspecifikation
En kravspecifikation togs fram för att definiera kraven för produkten. Respektive krav be- stämdes av kunden tillsammans med projektets analysansvarige. Kraven sammanställdes i en kravspecifikation där kraven ordnades efter en prioritetsordning. Kravspecifikationen fungerade som en specifikation av vad produkten ska innehålla och hur den skulle se ut, och fungerade därmed som en form av checklista som beskriver det projektet var tänkt att implementera.
4.5.1.3 Kvalitetsplan
En kvalitetsplan togs fram för att säkerställa att kvaliteten på produkten når upp till de för- väntningarna kunden önskar och för att projektgruppen skulle ha en kännedom över önskad kvalitet. Kvalitetsplanen tog bland annat upp vilka metoder projektgruppen använde för att mäta kvalitet. Kvalitetsplanen skulle hjälpa projektgruppen att upprätthålla en god kvalitet med hjälp av olika metriker vid till exempel kodgranskning och dokumentgranskning. Kva- litetsplanen tog dessutom upp hur länkning mellan krav, tester och de issue som skulle hjälpa projektgruppen att få en kännedom om vilka krav som har uppfyllts eller inte.
4.5.1.4 Testplan
En testplan togs fram för att kunna testa produktens funktionalitet. Testplanen definierade hur projektgruppen testar ett issue samt hur systemtesterna genomfördes. Testplanen var äm- nad att hjälpa projektgruppen att skriva tester genom att beskriva hur funktionalitet skulle testas samt tillvägagångssättet för att skapa tester.
4.5. Utvecklingsmetodik
4.5.1.5 Testrapporten
Testrapporten togs fram i syfte att sammanställa resultaten från testningen efter varje itera- tion av utveckling.
4.5.1.6 Arkitekturbeskrivning
En arkitekturbeskrivning togs fram för att beskriva hur systemets arkitektur är uppbyggd. Arkitekturbeskrivningen beskrev olika designbeslut för hur koden skulle struktureras. Vida- re beskrev den även systemets UML-klassdiagram, systemanatomi och arkitektuella ram- verk. Arkitekturbeskrivningen ämnade att hjälpa projektgruppen att implementera funk- tionalitet hos produkten. Klassdiagrammet beskrev vilka klasser som skulle implementeras samt dess attributer och metoder. Systemanatomin beskrev vidare vilka beroenden mellan de abstrakta funktionerna som projektgruppen måste ta hänsyn till vid implementation.
4.5.2
Arbetsmetod
Projektgruppen arbetade i tre iterationer. Under den första iterationen var fokuset att im- plementera de grundläggande funktionaliteterna av biblioteket med underliggande struktur samt att parallellt implementera GUI:ts grundläggande funktionalitet. I iteration två var fo- kuset att koppla samman GUI:t med den underliggande strukturen och fortsätta utveckla funktionalitet till biblioteket. I iteration tre var fokuset att fortsatt utveckla funktioner vid behov samt förbättra existerande funktionalitet.
Den arbetsprocess som projektgruppen arbetade enligt i iteration ett var Scrum-processen. Den metodik som kännetecknar Scrum var att projektgruppen arbetade under Sprints. En Sprint genomfördes under två veckor. Innan Sprintens start genomförde projektgruppen en Sprint-planning. Den innehöll de issue som projektgruppen tänkt implementera under Sprin- ten. Flera issue lades till på ett Scrum-bräde och tilldelades gruppmedlemmar. Under itera- tionen hade projektgruppen möte på måndagar, onsdagar och fredagar där de besvarade på frågorna:
• Vad har jag gjort sedan föregående Scrum-möte som hjälpte projektgruppen att nå vårt Sprint-mål?
• Vad ska jag göra idag och till nästa möte för att projektgruppen ska nå sitt Sprint-mål? • Vet du om några problem som förhindrar att projektgruppen inte når sitt Sprint-mål?
Vid slutet av en Sprint genomförde projektgruppen en Sprint-review samt en Sprint- retrospective. I Sprint-retrospective diskuterade projektgruppen positiva och negativa erfa- renheter som påträffats under Sprinten. I Sprint-review gick projektgruppen igenom projekt- gruppens product backlog och diskuterade om ett issue skulle fortsätta arbetas på i en senare Sprint eller inte.
4.5. Utvecklingsmetodik
Varje issue under projektet beskrevs som enligt Figur 4.1. Varje issue innehöll följande infor- mation:
• En beskrivning som beskriver vad som ska implementeras och hur det ska fungera. • En lista av länkade krav.
• Potentiella problem med ett issue.
• En lista över andra issue som måste implementeras innan ett specifikt issue.
• En numrerad lista över krav som beskriver exakt hur det som ska implementeras ska fungera.
• En kommentar med övrig info som kan vara användbar för utvecklaren.
• Ifall ett issue togs fram under iteration två eller tre inkluderar den även en lista över användarberättelser (eng. user-story).
Figur 4.1: Exempel av ett issue som använts i projektet.
Under iteration två och tre skedde utvecklingen enligt Kanban-principen och inga Sprints genomfördes. Ett kontinuerligt arbete på ett prioriterat issue användes istället. Under iteration två använde projektgruppen sig av statusmöten för att stämma av utvecklingens status och se över risker för att identifiera problem som kunde uppstå under iteration två och tre. Iteration två introducerade även testdriven utveckling för all utveckling av funktionalitet.
Figur 4.2 visar hur projektgruppens Kanban-bräde som användes under utvecklingen såg ut. En vidare beskrivning av Kanban-brädet finns i avsnitt F.3.1.3.
4.5. Utvecklingsmetodik
Figur 4.2: Projektgruppens Kanban-bräde med de olika issue som behövs göras. De olika kolumnerna i bilden representerar de olika stadierna ett issue kan befinna sig i.
4.5.3
Versionshantering
Koden som projektgruppen skriver versionshanterades med Git. Metodiken med versions- hanteringen var enligt git-arbetsflödet som beskrivs i 3.3.4.
4.5.4
Kodstilguide
Koden som projektgruppen producerade under projektet följer den kodstilsguide som be- stämts innan dess att utveckling påbörjats. Denna guide involverade diverse definitioner för att minska på stilskillnader i kodbasen.
4.5.5
Kodgranskning
Kodgranskningen genomfördes genom att all kod som var ämnad att genomföra en merge till master branch granskades av minst två projektmedlemmar innan merge. Projektmedlemmar som granskade koden följde följande granskningslista:
• Att koden inte ger några felmeddelanden. Detta verifieras för att se till att koden kan köras.
• Att koden inte ger några varningsmeddelanden. Detta verifieras för att se till att koden inte har några kvalitetsbrister som kan automatiskt detekteras.
• Att alla funktioner som behöver det har en funktionskommentar som beskriver even- tuella parametrar, hur den behandlar parametrarna och vad den returnerar. Detta veri- fieras för att se till att koden är väldokumenterad.
• Att koden är läsbar. Detta innebär att det inte ska vara några tvivel om vad som står i koden och att den följer projektgruppens interna regler kring skrivandet av kod. Detta verifieras för att se till att koden ska vara enkel att vidareutveckla.
4.5. Utvecklingsmetodik
• Att varje modul har en kommentar som beskriver dess syfte. Detta verifieras för att se till att koden är väldokumenterad.
• Att varje kodrad inte innehåller fler än 121 tecken. Detta verifieras för att se till att koden är läsbar.
• Att effektiva och passande datastrukturer och algoritmer har använts. Detta verifieras för att se till att koden har god prestanda.
• Att koden är testad och att testerna verifierar rätt funktionalitet. Detta verifieras för att se till att koden ska hålla en så hög standard som möjligt.
Kodgranskningen var ämnad att hjälpa projektgruppen att upprätthålla en hög kodstandard. Att utföra kodgranskningar ökade även förståelsen för kodbasen för de projektmedlemmar som granskade implementationen.
4.5.6
Utvecklingsverktyg
Det utvecklingsverktyg som projektgruppen använde sig av var GitLab. GitLab användes som versionshanteringsverktyg samt i syfte att representera utvecklingsflödet för projektet. Flera issue representerades i ett Scrum/Kanban-bräde i GitLab. Projektmedlemmar kunde sedan välja ett issue och skapa en egen branch. Denna branch användes sedan för all utveckling av den implementationen, detta bidrog att risken för diverse problem med versionshantering minskade.
4.5.7
Testning
Projektgruppen använde sig av testramverket Pytest för att testa implementationen.
För varje issue ansvarade utvecklaren för att skriva tester som grundligt testade funktionali- teten hos implementationen. Testerna var implementerade på ett sådant sätt att funktionali- teten verifierades och att olika typer av indata gav korrekt resultat.
Testerna implementerades i en specifik testmapp i biblioteket B-ASIC.
Testerna för det grafiska gränssnittet genomfördes manuellt då projektgruppen ansåg att test- ning med testramverk ämnade för grafiska gränssnitt var utanför projektets omfattning. De manuella testerna beskrev ett scenario som testaren sedan genomförde för att verifiera funk- tionaliteten hos det grafiska gränssnittet.
Testerna publicerades tillsammans med implementationen och genomgick kodgranskning för att verifiera att testerna var korrekt genomförda.
Vidare använde sig projektgruppen av acceptanstester för att verifiera funktionaliteten hos B-ASIC tillsammans med kunden.
4.5. Utvecklingsmetodik
4.5.8
Grupproller
Rollerna och dess ansvarsområden var fördelade över alla projektmedlemmar. De roller som projektgruppen utformades av är följande:
• Teamledare: Angus Lothian Teamledarens ansvar var att leda projektgruppens arbete genom att tillhandahålla information och vägleda vid beslut. Vidare hade teamledaren även ansvar att vägleda möten och andra sammankomster som projektgruppen tar del av under projektets gång.
• Analysansvarig: Adam Jakobsson Analysansvariges ansvar var att tillhandahålla kon- takten med beställaren, och vidare hade den analysansvariga medlemmen ansvar för kravspecifikationen och dess framställning. Frågor till beställaren gick via den här med- lemmen.
• Arkitekt: Ivar Härnqvist Arkitektens ansvar var att bestämma den övergripande systemdesignen med ett arkitekturdokument. Vidare behövde även arkitekten föreslå tekniker som borde användas i projektet.
• Konfigurationsansvarig: Felix Goding Konfigurationsansvariges ansvar var att tillhan- dahålla och underhålla de systemen projektgruppen använde under utvecklingsfasen av projektet. Exempelvis versionshanteringssystemet.
• Kvalitetssamordnare: Rasmus Karlsson Kvalitetssamordnarens ansvar var att se till att kvaliteten hos projektet efterlevs, detta genom att definiera en kvalitetsplan.
• Testledare: Kevin Scott Testledarens ansvar var att bestämma hur produkten skulle tes- tas sådant att kvaliteten hos produkten garanterades. Testledaren garanterade detta ge- nom att organisera bland annat acceptanstester med flera. Testledaren ansvarade även för att testrapporten och testplanen planerades och genomfördes.
• Utvecklingsledare: Jacob Wahlman Utvecklingsledarens ansvar var att bestämma vil- ken utvecklingsmiljö projektet skulle använda sig av och design av miljön. Vidare hade även utvecklingsledaren ansvar att se till att alla medlemmar på ett enkelt vis kunde arbeta med att utveckla produkten, bland annat via processer som Scrum och Kanban- bräden.
• Dokumentansvarig: Arvid Westerlund Dokumentansvariges ansvar var att se till att all dokumentation som producerades under projektets gång var väl genomförd och struk- turerad. Dokumentansvarige tog fram mallar för dokument samt en logotyp för projek- tet. Dokumentansvarige hade även ansvar för att leveranser av dokument skedde.
5
Resultat
Detta kapitel tar upp de resultat projektgruppen kom fram till.
5.1
Systembeskrivning
Detta avsnitt beskriver hur systemet för produkten B-ASIC är uppbyggt på en hög abstrak- tionsnivå.
5.1.1
Översikt över systemet
Produkten B-ASIC är ett system som består av två större komponenter, ett bibliotek med den faktiska implementationen av produkten samt ett grafiskt gränssnitt som använder sig av biblioteket till sin funktionalitet.
5.1.1.1 Bibliotek
Biblioteket är implementerat i Python med garanterat stöd för version 3.6 eller högre. Biblio- teket har dessutom en mindre del implementerat i C++ för funktionalitet som ställer krav på prestanda. Vidare använder sig biblioteket av moduler som NumPy för diverse beräkningar vid simulering av bland annat signalflödesgrafer och pybind11 för koppling mellan Python och C++.
Biblioteket som utvecklats används för att representera operationer, operationsträd, signal- flödesgrafer, prioritetsgrafer och scheman. Dessa strukturer är konstruerade baserat på en existerande struktur; för att skapa ett operationsträd kopplas en eller flera operationer till varandra, för att skapa en signalflödesgraf används ett operationsträd, för att generera en prioritetsgraf krävs en signalflödesgraf och slutligen för ett schema krävs en prioritetsgraf. Genom denna typ av implementation på strukturerna bibehåller vi existerande funktionalitet
5.1. Systembeskrivning
och krav på strukturer genom arv, vilket gör att det är mycket enkelt att vidare implementera en ny struktur som är baserad på samma eller liknande funktionalitet.
Biblioteket är utvecklat på sådant sätt att dokumentation och tydlighet har varit ett fokusom- råde för att möjliggöra enkel vidareutveckling av produkten.
Biblioteket går att använda separat från det grafiska gränssnittet genom att använda en god- tycklig Python-interpretator med stöd för version 3.6 eller högre genom att importera biblio- teket som en modul.
5.1.1.2 Grafiskt gränssnitt
Det grafiska gränssnittet är implementerat i Python med garanterat stöd för version 3.6 eller högre och själva gränssnittet är implementerat med modulen PySide2 som är en Python- baserad variant av det grafiska utvecklingsverktyget Qt. Vidare använder sig gränssnittet av modulen Matplotlib för att återge resultat från exempelvis simuleringar.
Det grafiska gränssnittet som utvecklats används för att implementera en grafisk representa- tion av funktionaliteten i biblioteket. Det grafiska gränssnittet kan exempelvis användas för att skapa operationer, operationsträd och signalflödesgrafer och även representera dessa gra- fiskt. Ett additionsträd går att se i Figur 5.1. Vidare går det även att simulera dessa grafer för att få en viss utdata givet en indata till exempelvis signalflödesgrafer. Simuleringen kan även återges i form av en graf med hjälp av modulen Matplotlib i Python.
Det grafiska gränssnittet levereras tillsammans med biblioteket och ska gå att använda givet att installationskraven är uppfyllda.