Nedan följer en kort sammanfattning av gruppmedlemmarnas individuella bidrag.
A Fredrik Bergstrand: JavaScript-ramverks effekt på underhållbarhet
Rapporten behandlar hur användandet av ett JavaScript-ramverk påverkat systemets underhållbarhet. Detta undersöks genom att med hjälp av komplexitetsmätningar jäm- föra systemet i den här rapporten med andra system vilka utvecklats med hjälp av ett
5.6. Översikt över individuella bidrag
ramverk. Undersökningen visar att användningen av ramverk bidrar till en mindre komplex kodbas. Slutsatsen dras att detta kan ge en generellt bättre underhållbarhet beroende på vilken typ av underhåll eller vidareutveckling av systemet som sker i framtiden.
B Kimberley French: Värdet av en prototyp
Denna del undersöker hur prototyper används i framtagingen av ett mjukvarusystem, vilka för- och nackdelar som finns samt vilka processer som är lämpliga för att arbeta fram en prototyp. Undersökningen är baserad på en enkät som besvarats av projekt- grupper i kursen TDDD96 Kandidatprojekt i programvaruutveckling. Resultatet visar på att gruppmedlemmarna tycker att den tid som lagts på prototypningsarbete är väl investerad och att prototypen har underlättat för produktens utveckling.
C Rebecka Geijer Michaeli: Daily Scrum virtuellt via textbaserat verktyg
Rapporten presenterar teori kring daily Scrum-möten, och möten som hålls virtuellt. Teorin jämförs mot de virtuella, textbaserade daily Scrum-möten som detta projekt tillämpat. Dessutom presenteras insamlade erfarenheter från gruppens medlemmar om daily Scrum-mötena. Bland dessa framträder värdet i att anpassa frekvensen av daily Scrum-möten efter hur mycket tid projektmedlemmarna lägger på projektet.
D Eric Henziger: En utvärdering av parprogrammering och kodgranskning
Rapporten visar på positiva effekter från parprogrammering och kodgranskning med avseende på både kodkvalitet och samarbetet inom gruppen. Även några negativa ef- fekter framkom som bland annat berörde inflexibilitet hos parprogrammering och obe- hag med att ge kritik vid kodgranskning.
E Oscar Johansson: Enhetstestningens påverkan på programmeringsprocessen
Rapporten utreder hur tidpunkt för skrivade av enhetstester påverkar programmer- ingsprocessen, med avseende på tidsåtgång, resultat och underlättande av lösning. För att utreda detta anordnades en datainsamling där deltagare fick lösa uppgifter med tre olika förhållningssätt till enhetstestning. Rapporten visar att olika förhållningssätt påverkar programmeringsprocessen på många olika vis.
F Robert Kumpulainen: Effekten av en branching model i ett litet utvecklingsprojekt
Rapporten analyserar huruvida valet av greningsmodell är associerat med en ökad mängd felaktig kod. Undersökningen visade att ytterligare metoder krävs för att hantera de datamängder som uppstår vid analys av ett mjukvaruprojekts utveckling- shistorik. Den av rapporten tillämpade datainsamlingsmetoden producerade inte data från vilken konklusioner kunde dras.
G Erik Rönmark: Kvalitetssäkrande processer och produktkvalitet i ett litet utveck-
lingsprojekt
Rapporten utreder hur projektgruppens sätt att göra utvärderingar, användartest och kodgranskning påverkade produktkvaliteten. Denna undersökning genomförs genom att gå igenom producerad dokumentation och söka igenom statistik från Git. Rapporten visar att gruppens kvalitetsäkrande processer faktiskt påverkade produktkvaliteten positivt.
H Kristoffer Tennivaara: Metoder och processer för grafiska användargränssnitt
Rapporten utreder vad olika sätt att fatta designbeslut på har för effekt på använd- barheten på produkten. Den undersöker också vilka processer och metoder som lämpar sig bäst för att ta fram ett användargränssnitt med så hög användbarhet som möjligt i ett småskaligt projekt.
5.6. Översikt över individuella bidrag
I Victor Tranell: Kravhantering med Scrum
Rapporten utreder vilka effekter den agila utvecklingsmetodiken Scrum får på kravhantering. En litteraturstudie samt en projektstudie visar att agil kravhantering passar mycket bra för små projekt.
6
Diskussion
Här diskuteras olika delar av innehållet i rapporten. Inledningsvis behandlas de resultat som erhållits ur slutprodukten och projektarbetet. Därefter tas den metod som använts för att samla in erfarenheter upp, och till sist sätts arbetet in i ett vidare sammanhang.
6.1
Resultat
Här diskuteras de resultat som presenterats i avsnitt 5. Diskussionen inleds med att gränss- nittsdesignen behandlas. Därefter berörs den valda implementationen. Sedan tas produktens värde för kunden upp. Gruppens redovisade erfarenheter diskuteras och avslutningsvis be- handlas SEMAT kernel alphas.
6.1.1
Gränssnittsdesign
Då handlingsinviter bidrar till att ge användaren information om vilka delar av systemet det går att interagera med [5] går det att argumentera för att dessa gör systemet mer använd- bart. Enhetlig formgivning i systemets olika delar kan exempelvis bidra till att användaren snabbare förstår hur ett nytt verktyg ska användas. Interaktionsmekanismer som drag and drop har använts för att göra det lätt för användaren att lära sig använda systemet. Det är inte säkert att drag and drop alltid är den effektivaste metoden för att interagera med ett system. Däremot är metoden lätt att förstå och tillämpa jämfört med andra mekanismer, såsom kommandorads-interface eller komplicerade kortkommandon. Beslutet att använda dessa mekanismer baserades på att systemet inte är ett verktyg som studenterna ska kunna bli experter inom eller med vars hjälp kunna lösa problemet så snabbt som möjligt. Det ansågs viktigare att tillhandahålla ett system som det är lätt att påbörja arbetet i.
Ett antal av de beslut som togs angående gränssnittsdesignen kan anses ha försämrat pro- duktens användbarhet, exempelvis att presentera mer information än vad som är nödvändigt för att dekryptera en text. Systemet gör heller inte några ansträngningar för att tala om för användaren vilka verktyg som fungerar bra att använda tillsammans. Detta är exempel på beslut som kanske sett annorlunda ut om systemet inte tillkommit i utbildningssyfte. Tanken var att studenterna själva skulle bli tvungna att tänka efter och förstå principerna för att kunna utföra laborationen. Alla verktyg görs tillgängliga direkt, men inga tips ges gällande vilka som är lämpliga att använda.
6.1. Resultat
6.1.2
Implementation
Det finns ett stort antal implementationer som kunde övervägts. I och med att systemet på kundens önskemål skulle utvecklas som en webbapplikation minskade valfriheten något. Det finns ett antal olika verktyg som generellt används för webbutveckling, där de vanligaste är HTML, CSS och JavaScript. Det är möjligt att systemet sett radikalt annorlunda ut om kravet på att systemet skulle vara en webbapplikation inte existerat. Dels för att det ger tillgång till en annan uppsättning verktyg, men också för att projektmedlemmarna hade begränsad erfarenhet av webbutveckling vid projektets start.
Betraktas olika implementationer ur ett webbutvecklingsperspektiv dyker frågan om JavaScript-ramverk ganska snabbt upp. Valet att inte använda ett sådant vid utvecklingen av systemet kan ifrågasättas. Hur detta påverkat systemet undersöks djupare i individuell del A. JavaScript har också stöd för prototypbaserad objektorientering. Det hade varit möjligt att implementera en mer objektorienterad lösning än den nuvarande. En sådan lösning kunde lett till mer inkapslad funktionalitet, men kanske också mer arbete som eventuellt inte bidragit till en förbättring av underhållbarheten eller minskad komplexitet hos mjukvaran. Detta på grund av mjukvarans relativt begränsade omfattning.
Projektet följde ett antal konventioner som växte fram under projektets gång. Konven- tioner är dock inget som påtvingas av språket eller systemet i sig, vilket innebär att framtida utvecklare bör vara insatta i dessa för att enkelt kunna vidareutveckla systemet. Hur lätt det är att vidareutveckla systemet beror alltså till stor del på hur väl utvecklingskonventionerna förmedlas vidare. Eftersom mjukvaran publicerats som ett projekt med öppen källkod finns en risk att dessa konventioner förbises och med tiden dör ut. Detta då ett potentiellt stort antal utvecklare kan bidra till projektet, och risken finns att nya utvecklares snabba lösningar på problem inte alltid följer de etablerade konventionerna. När de lösningarna sedan orsakar nya problem löses dessa på samma sätt, istället för att den egentliga orsaken till problemet identifieras.
6.1.3
Värde för kunden
Här diskuteras systemets värde för kunden. Ett av de större målen med projektet var att kunden skulle få en tillfredställande produkt framtagen. Kunden önskade ett system som dels var mer lättanvänt än det tidigare, och som dessutom var underhållbart med möjlighet till vidareutveckling i framtiden. Värdet av systemet beroende på hur det brukas av kunden tas upp. Därefter behandlas de beslut som tagits för att skapa värde för kunden.
Värde beroende på användning
I avsnitt 5.3 beskrevs ett antal attribut hos systemet som är av värde för kunden, men för att produkten ska uppnå sitt fulla värde återstår att systemet tas i aktivt bruk. Det krävs exempelvis också att någon form av vidareutveckling eller underhåll av systemet sker för att systemets underhållbarhet ska ha ett faktiskt värde för kunden.
Att systemet inte tagits i bruk än i skrivande stund innebär däremot inte att det helt saknar värde ur kundens perspektiv. Även om systemet aldrig tas i bruk kan kunden ha kommit till viktiga insikter gällande vad de vill ha ut av ett nytt system. Kunden har också erhållit en ny referenspunkt, utöver det gamla systemet Enigma 1.2, som kan användas för att beskriva eventuella önskemål med ett helt nytt system.
6.1. Resultat
Öppen källkod
När projektet avslutades publicerades projektet på GitHub under öppen källkod. Därmed kan alla som hittar buggar fixa dem och sedan göra en merge request. Allt eftersom tiden går kommer fler och fler buggfixar och refaktoreringar utföras. Kunden får därmed också fortsatt granskning av systemets kodbas vilket förhoppningsvis bidrar till systemets livslängd. Det är också den öppna källkoden som möjliggör framtida utveckling av kunden eller utvecklare anlitade av kunden, i motsats till proprietär programvara.
Dokumentation
Fördelen med teknisk dokumentation är att flytande text och bilder gör sig bättre än kod för att på ett snabbt sätt beskriva komplexa system på ett övergripande sätt.
Problemet med att ha teknisk dokumentation som förklarar vad koden gör är att doku- mentationen ofta inte underhålls i samma takt som kodbasen utvecklas. Detta leder till att dokumentationen hamnar efter och därmed kan informationen bli inaktuell. Inaktuell teknisk dokumentation kan vara missvisande och bidra till mer förvirring än förklaring. Syftet med att JSDoc används som dokumentation är att låta nya utvecklare sätta sig in i systemet på ett effektivt sätt, och att underlätta vidareutveckling. Anledningen till att JSDoc använts är att chansen är större att en utvecklare uppdaterar de kommentarer som ligger i ko- den i anknytning till funktionaliteten än att denne öppnar ett annat dokument och beskriver förändringar där.
Kodkvalitet
I och med att parprogrammering och kodgranskning har använts kan man argumentera för att kvaliteten på koden är hög. Som nämns i avsnitt 4.5.2 fokuserade dessa på att öka kodens läsbarhet. Kodgranskning i samband med parprogrammering gjorde att minst tre personer har läst och godkänt den kod som skrivits, vilket ökar chansen att koden är läsbar. Läsbar kod medför att det blir lättare för nya utvecklare att förstå hur systemet fungerar.
Att kodbasen följer etablerade standarder bidrar till kvaliteten eftersom dessa standarder är något många utvecklare känner till och har en vana att arbeta med. Det låter nya utvecklare fokusera på innehållet och dess betydelse istället för att lägga tid på att bekanta sig med dess utformning.
Webbapplikation
Då systemet utvecklats som en webbapplikation är det till stor del plattformsoberoende vilket bidrar till en större frihet för studenterna som läser kursen. Det blir möjligt att enkelt arbeta med laborationen både från en egen dator och ISY:s datorsystem. Arbete från andra platser har tidigare förutsatt att studenten är bekväm med att använda en SSH-klient [26], exempelvis OpenSSH [27], för att ansluta till ISY. Nu kan alla med webbläsarvana arbeta från valfri plats.
Ytterligare en fördel med webbapplikationer är att systemet kan anpassas till andra hård- varuplattformar än stationära och bärbara datorer. Det går att tänka sig att applikationen anpassas till exempelvis surfplattor eller mobiltelefoner också. Detta är betydligt svårare med en systemapplikation.
Laborationsassistenter behöver inte ge lika mycket teknisk hjälp som innan, utan kan fokusera på laborationsinnehållet istället för miljön. Detta dels eftersom det inte var en helt
6.1. Resultat
enkel process att starta det gamla systemet, men också eftersom Knekt presenterar tillgänglig funktionalitet på ett mer överskådligt sätt.
6.1.4
Erfarenheter
Problem som uppmärksammades under iterationsutvärderingarna diskuterades på plats och man försökte att gemensamt hitta en lösning. Frågan skulle sedan komma att tas upp under nästa utvärdering för att se om det skett en förbättring eller om ytterligare åtgärder krävdes. Detta gjorde det enkelt att se om förbättringsförslagen fick önskad effekt. Nedan följer några exempel:
• Ett område som tydligt går att följa i utvärderingarna är vilket system för tidrappor- teringen som användes. Initialt användes Trello, där flera anmärkte i utvärderingen för förstudien att det var krångligt att använda. I sammanställningen av förbättringsförslag framgår att gruppen ämnade byta till kalkylark på Google Drive. I utvärderingen för it- erationen efteråt går det att läsa från flera personer i gruppen att nya tidrapporteringen fungerar väldigt bra.
• Måenderundorna är en punkt som omnämns ofta och med positiva ordalag i utvärderingarna. Förutom en person som tycker de tar för mycket mötestid är alla odelat positivt inställda till dem.
• I utvärderingen av iteration 1 önskades en andra kickoff. Det lades till under förbät- tringsförslag, genomfördes och prisades i nästa utvärdering.
Konsekvenserna av utvärderingarna kan tänkas vara många. Bland annat bidrog det till en bättre sammanhållning bland projektmedlemmarna – när problem uppmärksammades och hela gruppen involverades i att åtgärda dessa upplevdes det som att alla arbetade gemen- samt. Många gånger hade medlemmarna liknande erfarenheter kring punkterna vilket kan ha bidragit till en känsla av samhörighet till gruppen. Detta kan dock haft motsatt effekt för de med en annan erfarenhet, om de upplever att “alla andra” haft andra tankar kring en fråga. Det är då möjligt att den medlem som haft en avvikande åsikt känt sig isolerad och kanske undvikit att ta upp sin syn på saken. Det kan också tänkas att en medlem känt sig personligt ansvarig för en företeelse som de andra medlemmarna upplevt som negativt, vilket ytterligare bidragit till en känsla av att vara utanför gemenskapen. Det har inte upp- märksammats något sådant fall, men det kan bero på de anledningar som tagits upp här. I och med att projektgruppen redan under förstudien diskuterade de erfarenheter som kom- mit från tidigare projektarbeten kunde det tidigt fastställas vad som borde undvikas eller vad som var önskvärt gällande arbetsmetod, gruppdynamik, verktyg, utveckling etc. Ett område där det tydligt framgår att gruppen lyssnat på varandras åsikter är utveckling, där alla önskemål uppfylldes och alla tidigare problem förhindrades.
6.1.5
SEMAT kernel alphas
I början lade gruppen lång tid på genomgångarna av alla SEMAT kernel alphas, med ut- förliga diskussioner kring varje tillstånd och huruvida det uppnåtts eller när under projektet det skulle uppnås. Under de senare genomgångsmötena gick det klart fortare. Det kan tänkas bero på att gruppmedlemmarna mot slutet hade betydligt bättre koll på projektet och hur det låg till, och därför snabbare kunde avgöra vilka tillstånd som uppnåtts och vilka som inte uppnåtts. Det kan också tolkas som att gruppmedlemmarna mot slutet kände mindre behov av att utförligt prata igenom alla tillstånd, då de redan upplevde sig ha koll på projektet.