få kommunikationen att fungera. C är dessutom ett snabbare och mer hårdvarunära språk jämfört med Python vilket passade bättre för vår produkt.
6.1.2
Värde för kunden
Produkten anses av kunden utge värde för den utsedda uppgiften, men det fanns önskvärda funktionaliteter som ej kunde implementeras under den tid som var given för utveckling av produkten. Dessa skulle troligtvis göra produkten mer behändig och tillföra ett större värde för kunden. De kom i form av prio 2-krav samt övriga funktioner som aldrig sattes i kravspecifikationen men diskuterades som potentiella uppgifter att påbörja ifall tid fanns över. Bland dessa fanns exempelvis att kunna ändra videoströmningsinställningar från användargränssnittet, för att kunna få en slät videoström vid dålig uppkoppling eller en extra bra bild vid bra uppkoppling, lagra video, för att träna upp nya anställda, eller att utveckla AI-bildbehandling för att lättare kunna identifiera fartyg och potentiellt olika skador i fartygen.
Kunden har alltid haft planer på att vidareutveckla den produkt som togs fram. En sådan vidareutveckling skulle vara att implementera AI som känner igen olika typer av objekt i en video. Detta skulle göra produkten väldigt kraftfull genom att snabbare kunna få en överblick av vad som finns på olycksplatsen. Annan vidareutveckling skulle vara att kunna bestämma i användargränssnittet vilken upplösning videor skulle skickas i eller sätta på och stänga av videoströmningen från drönarna. Som nämnt i avsnitt 6.1.1 är det i nuläget komplicerat att få en kommunikation från servern till drönarna. Detta försvårar för kunden att vidareutveckla produkten. Ett sätt att få ut mer värde i produkten hade varit att hålla vidareutveckling i åtanke under fler av de designbeslut som togs under projektets gång.
6.2
Metod
Här diskuteras gruppens metoder under projektet.
6.2.1
Arbetsmetod
Gruppens arbetsmetod (se avsnitt 4.1) var väldigt simpel och enkel att förstå, men gav struktur till gruppen under arbetets gång. De veckovisa mötena gav regelbunden återkoppling till vad alla andra i gruppen åstadkommit och vilka problem som uppstått, även när gruppen var uppdelad och jobbade på helt olika håll. Detta ledde till att gruppen fortfarande kände sig samlad och medveten om allt som hände i projektet. Att alla aktiviteter skrevs upp i ett kanbanbräde i GitLab säkerställde även att inget glömdes bort. I de fall då kort blev kvar efter en sprint hade det kunnat finnas en risk i att aktiviteter sköts upp sprint efter sprint, men det skedde aldrig under arbetet. Om en aktivitet skjutits upp till en senare sprint var det istället oftast den aktiviteten som fick mest fokus vilket gjorde att den blev slutförd. Att gruppen tilldelade aktiviteter till specifika personer hjälpte med att se till att ingen aktivitet blev bortglömd eller bortvald för att den kändes jobbig eller tråkig att arbeta med. Detta hjälpte även gruppens samförstånd om vad uppgiften innebar samt skapade struktur då alla visste vad alla andra jobbade med.
På grund av osäkerhet om vad kanbanbrädets aktiviteter faktiskt innebar fanns en risk att gruppmedlemmar kunde börja jobba på samma saker alternativt anta att andra jobbade på dem. Detta undveks genom att kommunicera men det hade fortfarande kunnat hända att en grupps arbete tvingades stanna av i väntan på svar. Detta kanske skulle ha kunnat undvikas med bättre hantering av kanbankorten, men detta var inget som upplevdes som ett problem under detta projekt då alla svarade snabbt på meddelanden.
Genom att tidigt ta upp vilka kommunikationskanaler som skulle användas, samt regler om hur ofta dessa skulle läsas, fick gruppen tidigt en bra kommunikation. Just kommunikation har i vissa av gruppmedlemmarnas tidigare projekt upplevts som bristande,
6.2. Metod
vilket lett till att arbetet blivit ineffektivt och tappat i kvalitet. Gruppens sprintmöten har även haft en bra struktur i arbetet jämfört med dessa tidigare projekt, vilket även det lett till en bättre kommunikation inom gruppen. Denna kommunikation skulle kunna vara en bidragande faktor i att det var enkelt att jobba självständigt. Det fanns ofta mycket att göra som inte berodde på andra i gruppens arbete, och genom att hålla god kommunikation blev det enklare för gruppmedlemmar att välja att jobba med dessa delar då alla visste vad som berodde på vad och inte råkade börja jobba på samma område som någon annan av misstag.
6.2.2
Roller
Rollerna kan ha bidragit till att gruppen hade lättare att dela upp uppgifter inom projektet, vilket gjort det lättare att arbeta parallellt. Rollerna i gruppen hade stor påverkan på arbetet i början men började tappa inflytande under projektets gång. Mycket av det tidiga rollsdefinierande arbetet hade med tidiga beslut, dokument och uppsättning av Git att göra, och då detta blev avklarat försvann en del av rollens inverkan. Detta lär ske naturligt i de flesta projektgrupper när arbetet blir mer fokuserat på utveckling och de specifika ansvarsrollernas arbetsuppgifter blir avklarade och medlemmarna går mer mot att bli utvecklare. Den roll som hade störst påverkan och var mest ihärdig var troligtvis teamledaren som höll i möten och hade kommunikation med examinatorn.
Vissa av rollernas bortfall kan varit på grund av glömska och ostrukturerat arbete men kan även ha grund i kraven satta av Linköpings universitet eller Airpelago. Ett exempel är att det var teamledaren och inte dokumentansvarig som skulle lämna in alla dokument, vilket gjorde det mer omständigt för denne att kontrollera att dokumentmallar följdes. Ett annat exempel är att Airpelago hade krav på hur arkitekturen i produkten skulle se ut, vilket tog bort stor beslutsfattning från gruppens arkitekt. De kan också ha bortfallit naturligt då vissa roller har obalanserad makt över tid, då exempelvis arkitekten inte kan ta beslut om att ändra arkitekturen sent i projektet. Detta eftersom en stor omstrukturering troligtvis skulle skapa onödigt mycket extra arbete och är inte nödvändigt, såvida inte projektet stöter på stora problem med sin nuvarande arkitektur. Liknande har gruppen inte känt något behov av att hålla en nära kontakt med kunden under arbetets gång, utan kontaktat denne vid behov. Detta då stor del av arbetet handlat om att utbilda gruppen.
På grund av att rollerna föll i glömska under projektets gång har de inte upplevts som så användbara som de kanske kunnat vara. Vid större projekt skulle det potentiellt gå att dela upp ytterligare så att de som får större ansvarsområden får mindre utvecklingsroll och därmed säkerställa rollernas kontinuerliga påverkan.
6.2.3
Versionshantering
Versionshanteringen har mestadels fungerat bra. Vid ett antal tillfällen bröts det tänkta arbetsflödet vid hanteringen av dokumenten, då det kändes lättare att spara grenar även efter att de slagits samman med huvudgrenen. Detta eftersom gruppen visste att det skulle komma återkoppling på det som skrivits, även om arbetsflödet egentligen sa att dessa skulle tas bort när de var redo att integreras. Detta kan till viss del även bero på att det varit lite otydligt exakt vad reglerna för arbetsflödet var. Det hade troligtvis varit tydligare om konfigurationsansvarig i gruppen tidigare bestämt exakt hur arbetsflödet skulle se ut och stämt av med gruppen att alla var okej med att följa det flödet. Vid ett fåtal gånger har gruppen stött på problem med Git, så som att grenar inte kunde knuffas upp till den centrala katalogen eller att en sammanslagning fått konflikter som tagit tid att lösa, men alla problem löstes relativt snabbt.
6.2. Metod
6.2.4
Systemanatomi
Systemanatomin användes inte så flitigt som tänkt. Detta kan till stor del förklaras med att arbetsupplägget och planeringen för projektet var enkelt nog att det gick att se de kommande utvecklingsstegen utan att behöva stämma av med systemanatomin. Systemanatomin följdes ändå till viss del omedvetet då gruppen delades upp i tre grupper och jobbade utefter de tre färger i systemanatomin som kan ses i figur I i appendix IV. Systemanatomin följdes inte så att gruppen jobbade med att implementera de olika blocken från botten och upp då arbetet delades upp och jobbades på parallellt. Oftast gick arbetet med blocken dock från botten och upp inom de åtskilda delarna, men inte alltid då det visade sig att ett block inte byggde på ett annat block riktigt så mycket som förväntat och därför kunde utvecklingsordningen ändras. Då tiden var knapp prioriterades saker som ansågs viktigare för helhetsintrycket av produkten, vilket är varför inte alla block implementerades och varför övriga block inte implementerades i rätt ordning.
6.2.5
Granskning
Granskningen av dokument har fungerat bra i gruppen, men i början var det lite otydligt hur noggranna granskningarna skulle vara. Det hände då att gruppmedlemmar valde att inte åtgärda alla kommentarer från granskningarna. Mot slutet av projektet var gruppen mer eniga om hur noggranna granskningarna skulle vara. Det hade troligtvis underlättat om gruppen tidigt klargjort hur ingående granskningen skulle vara gällande exempelvis språkbruk och formuleringar, samt hur viktigt det var att ändra kommentarer om detta och inte bara korrigera kommentarer gällande innehåll.
Även granskningen av kod har fungerat bra, även om det ibland varit oklart om granskaren ska vara någon som inte är insatt alls i koden, eller om granskningar kan göras av samma personer som varit med och skrivit koden. Vid ett fåtal tillfällen har granskningar därför skett lite senare än nödvändigt då oklarheter uppstod om vilka som kunde sättas på att granska vilka delar av koden. Ett tydligare beslut om detta hade kunnat bestämmas i början av projektet.
6.2.6
Testning
Testningen började ganska sent in i projektets gång. Detta berodde delvis på de arkitektsval som gjorde att det redan från början var svårt att få någon sorts kod att fungera samt att det var relativt nya språk och bibliotek vilket orsakade svårigheter att förstå hur test skulle utformas. Att testledaren var oerfaren med dessa nya språk och bibliotek samt själva testledarrollen bidrog också till detta.
6.2.7
Källor
Källorna innehåller delvis föreläsningsmaterial från en professor i mjukvaruutveckling på Linköpings universitet. Detta anses som tillförlitlig information då universitetet är ett högt uppsatt lärosäte där professorn forskar inom ämnet.
Sjöfartsverket är en svensk myndighet som är ansvariga för tillgänglighet, framkomlighet och säkerhet till sjöss, där bland annat sjö- och flygräddning inom svenskt område. Eftersom sjöfartsverket är en statlig myndighet bör statistiken stämma. Det är dock viktigt att hålla i åtanke att statistiken kommer från deras egna hemsida samt att de har egenintresse av att försköna siffrorna för att få verksamheten att verka mer kompetent. Detta skulle gynna verksamheten i form av mer bidrag och förtroende. En del av källorna innehåller information om de olika bibliotek och program som används. En stor del av dessa kommer från de företag som utvecklat produkten vilket gör de tillförlitliga angående produkten. Det är dock företag som går med vinst och därför har att tjäna på att göra reklam och skönmåla dessa produkter.