Bygga bygglov med ARCH : Att vidareutveckla ett verktyg för husritningar

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 15hp | Datateknik

21 | LIU-IDA/LITH-EX-G--21/031--SE

Bygga bygglov med ARCH, att

vi-dareutveckla ett verktyg för

hus-ritningar

Building a building permit

–

a report about the development of the constructional drawing

platform ARCH

Adina Andersson

Albin Dunby

Leon Ericsson

Pontus Jönrup

Ludvig Erlander Klein

Samuel Knutsson

Hampus Rosenquist

Simon Russom Tsehaie

Handledare : Christoffer Holm Examinator : Kristian Sandahl

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/. © Adina Andersson Albin Dunby Leon Ericsson Pontus Jönrup Ludvig Erlander Klein Samuel Knutsson Hampus Rosenquist Simon Russom Tsehaie

Sammanfattning

Denna rapport behandlar erfarenheterna och resultaten från åtta studenter och deras utfö-rande av projektet ARCH våren 2021. ARCH är en plattform skapad av startup-företaget Buildility med målet att förenkla skapandeprocessen av bygglov i Sverige för gemene man. Projektgruppen vidareutvecklade på en redan existerande bas genom att skapa ytterliga-re funktionalitet, så som lagerhantering och bildimportering. Målet med projektet var att föra vidare utvecklingen av från kundens konceptbevis till att skapa en minsta gångbara produkt för att säkerställa framtida testning kan drivas framåt av kunden.

Jämnsmed arbetet på denna rapport har samtliga medlemmar producerat individuella rap-porter med tema run produktionen av produkten som behandlas i denna rapport.

Abstract

This report recounts the experiences and results of the eight students working on the pro-ject ARCH during spring 2021. ARCH is a platform built by the startup company Buildility with the purpose of making the process of composing building permits from start to finish easier for the everyday person. The project group improved on an already existing base by adding functionality such as layer management and image import. The goal was to further the development of the proof-of-concept by Buildility and ensure that future testing can be made by the customer by achieving a minimum viable product.

Alongside the work made on the project, all members of the group have also produced individual reports themed around the production of the product.

Tillkännagivanden

Projektgruppen tackar Daniel Femerström, Jennie Blom Kall och Jonas Ekskog från Buildility. Tack för all hjälp och allt stöd vi fått i projektet och för den fantastiska erfarenheten ni gav oss. Vi riktar även ett stort tack till gruppens handledare Christoffer Holm. Tack för alla givande diskussioner och för din vägledning. Ett slutligt tack till medlemmarna inom projektgruppen, tack för ett gott samarbete i vått och torrt.

Innehåll

2.2 Gruppens tidigare erfarenheter . . . 5

3 Teori 7 3.1 Programmeringsspråk och bibliotek . . . 7

3.1.1 C# . . . 7

3.1.2 JavaScript . . . 7

3.1.3 React . . . 7

3.1.4 Konva.js / React-konva . . . 7

3.1.5 Entity Framework Core . . . 8

3.1.6 Bootstrap 4 / React-bootstrap . . . 8 3.2 Arbetsmetodik . . . 8 3.2.1 Scrum . . . 8 3.2.2 Kanbanbräde . . . 8 3.2.3 Trello . . . 8 3.3 Verktyg . . . 8

3.3.1 Microsoft Azure DevOps . . . 8

3.3.2 ASP .NET Core . . . 9

4 Metod 10 4.1 Utvecklingsmetod . . . 10

4.1.1 Roller . . . 10

4.1.2 Projektidentitet . . . 11

4.1.4 Process . . . 11 4.2 Verktyg . . . 12 4.2.1 Trello . . . 12 4.2.2 Google Drive . . . 12 4.2.3 Microsoft Teams . . . 12 4.2.4 Azure DevOps . . . 13 4.3 Kvalitet . . . 13 4.3.1 Mätning av process . . . 13 4.3.2 Dokumentation av process . . . 13 4.4 Testning . . . 13 4.5 Versionshantering . . . 14 4.6 Värde för kund . . . 14 4.6.1 Kundkontrakt . . . 14 4.6.2 Demonstration . . . 14 4.7 Systemanatomi . . . 14 4.8 Metod för erfarenhetsfångst . . . 15 4.9 Sprintar . . . 15 5 Resultat 17 5.1 Systembeskrivning . . . 17 5.1.1 Projektvy . . . 17 5.1.1.1 Duplicera ritning . . . 17 5.1.2 Designvy . . . 18 5.1.2.1 Rum . . . 18 5.1.2.2 Axellås . . . 18 5.1.2.3 Dörr och fönsterstorlek . . . 19

5.1.2.4 Hantering av dörrar och fönster i hörn . . . 19

5.1.2.5 Mått . . . 19 5.1.2.6 Lager . . . 19 5.1.2.7 Importera bakgrundsbild . . . 19 5.1.3 Sammanställningsvy . . . 20 5.1.4 Minneshantering . . . 20 5.2 Processbeskrivning . . . 20 5.2.1 Utvärdering . . . 20 5.2.2 Förbättringar . . . 21 5.2.3 Kvalitetskrav . . . 22 5.2.4 Sprintar . . . 22 5.3 Gemensamma erfarenheter . . . 23 5.3.1 Gruppkontrakt . . . 23 5.3.2 Existerande kodbas . . . 23 5.3.3 Distansläge . . . 23 5.3.4 Arbetsprocess . . . 24 5.4 Systemanatomi . . . 24

5.5 Översikt över individuella bidrag . . . 24

5.5.1 Adina Andersson - Specialisering inom team, effektiviserande eller sammanhållningsdödare? . . . 25

5.5.2 Albin Dunby - Virtual Realitys roll som hjälpmedel i byggbranschen . . 25

5.5.3 Leon Ericsson - Koordination av kandidatgrupp på distans som team-ledare . . . 25

5.5.4 Pontus Jönrup - En beskrivande fallstudie av kandidatarbetet med stort engagemang från kund . . . 25 5.5.5 Ludvig Erlander Klein - Iterativ utveckling och dess för- och nackdelar . 25

5.5.6 Samuel Knutsson - Hur kan Azure DevOps underlätta ett

mjukvaruut-vecklingsprojekt? . . . 25

5.5.7 Hampus Rosenquist - Användaridentifiering med hjälp av Javascript . . 25

5.5.8 Simon Russom Tsehaie - Jämförelse av funktionella komponenter och klasskomponenter i React . . . 26 6 Diskussion 27 6.1 Resultatreflektion . . . 27 6.1.1 Alternativa implementationer . . . 27 6.1.2 Processutvärdering . . . 28 6.2 Metod . . . 28 6.2.1 Källkritik . . . 28 6.2.2 Utvecklingmetod . . . 29 6.2.3 Utvärdering av systemanatomin . . . 29 6.2.4 För framtiden? . . . 30 6.3 Förutsättningar . . . 30

6.4 Arbetet i ett vidare sammanhang . . . 31

6.4.1 Miljömässigt . . . 31 6.4.2 Tillgänglighetsmässigt . . . 31 6.4.3 Individmässigt . . . 31 6.4.4 Ekonomiskt . . . 31 6.4.5 Tekniskt . . . 31 7 Slutsatser 33 7.1 Hur kan systemet ARCH implementeras så att man skapar värde för kunden? . 33 7.2 Vilka erfarenheter kan dokumenteras från programvaruprojekt ARCH som kan vara intressanta för framtida projekt? . . . 33

7.3 Vilket stöd kan man få genom att skapa och följa upp en systemanatomi? . . . 33

7.4 Hur påverkas implementationsarbetet när gruppen ärver en färdig kodbas från kunden? . . . 34

A Specialisering inom team, effektiviserande eller sammanhållningsdödare? -Adina Andersson 35 A.1 Introduktion . . . 35 A.1.1 Syfte . . . 35 A.1.2 Frågeställning . . . 35 A.1.3 Bakgrund . . . 36 A.2 Teori . . . 36 A.2.1 Specialisering . . . 36 A.2.2 Sammanhållning . . . 36 A.2.3 Effektivitet . . . 37 A.3 Metod . . . 37 A.3.1 Intervjuutförande . . . 38 A.3.2 Samtyckesblankett . . . 39 A.4 Resultat . . . 39

A.4.1 Effektivitet och vi-känsla . . . 40

A.4.2 Faktorer . . . 40

A.4.3 Ytterligare faktorer . . . 42

A.4.4 Övriga kommentarer . . . 43

A.5 Diskussion . . . 43

A.5.1 Källkritik . . . 43

A.5.2 Metod . . . 43

A.5.4 Specialisering . . . 45

A.6 Slutsatser . . . 46

A.6.1 Hur upplevdes påverkan på effektiviteten i teamet till följd av speciali-sering? . . . 46

A.6.2 Vilka faktorer kan identifieras som gynnsamma respektive ogynnsam-ma för gruppens effektivitet och vi-känsla? . . . 46

A.6.3 Skiljer sig påverkan av specialisering i gruppen eller skiljer sig de iden-tifierade effektivitetsfaktorerna från vad som finns dokumenterat i and-ra publikationer? . . . 46

B Virtual Realitys roll som hjälpmedel i byggbranschen - Albin Dunby 47 B.1 Introduktion . . . 47 B.1.1 Syfte . . . 47 B.1.2 Frågeställning . . . 47 B.2 Teori . . . 47 B.2.1 Virtual Reality . . . 48 B.2.2 BIM . . . 48 B.3 Metod . . . 48 B.4 Resultat . . . 48

B.4.1 Virtual Reality tekniker . . . 48

B.4.2 Branscher . . . 49 B.4.2.1 Fastighetsbranschen . . . 49 B.4.2.2 Byggbranschen . . . 50 B.5 Diskussion . . . 51 B.5.1 Metod . . . 51 B.5.2 Resultat . . . 51 B.6 Slutsatser . . . 52

C Användaridentifiering med hjälp av Javascript - Hampus Rosenquist 53 C.1 Introduktion . . . 53 C.1.1 Syfte . . . 53 C.1.2 Frågeställning . . . 53 C.1.3 Avgränsningar . . . 54 C.2 Teori . . . 54 C.2.1 Digitala fingeravtryck . . . 54 C.2.1.1 Användningsområden . . . 54 C.2.1.2 Identifiering . . . 55 C.2.2 Javascript . . . 55 C.3 Metod . . . 55 C.3.1 Litteratursökningar . . . 55 C.4 Resultat . . . 56 C.4.1 Fingeravtryckstekniker . . . 56 C.4.1.1 Webbläsarspecifikt . . . 56 C.4.1.2 Canvas . . . 57 C.4.1.3 Javascriptmotor . . . 57 C.4.1.4 Webbläsaröverskridande . . . 57

C.4.2 Identifiering och åtgärder . . . 58

C.5 Diskussion . . . 59

C.6 Slutsatser . . . 60

D Koordination av kandidatgrupp på distans som teamledare - Leon Ericsson 61 D.1 Introduktion . . . 61

D.1.2 Frågeställning . . . 61 D.1.3 Avgränsningar . . . 61 D.2 Bakgrund . . . 62 D.3 Teori . . . 62 D.3.1 Utvecklingsmodeller . . . 62 D.3.2 Vattenfall . . . 62 D.3.3 Iterativ . . . 63 D.3.4 Agil . . . 63 D.4 Metod . . . 63 D.4.1 Enkät . . . 63

D.4.1.1 Enkät till teamledare . . . 64

D.4.1.2 Enkät till övriga gruppmedlemmar . . . 65

D.4.2 Litteraturstudie . . . 65

D.5 Resultat . . . 65

D.5.1 Enkät . . . 66

D.5.1.1 Enkät till teamledare . . . 66

D.5.1.2 Enkät till övriga gruppmedlemmar . . . 67

D.5.2 Litteraturstudie . . . 69

D.6 Diskussion . . . 70

D.6.1 Metod . . . 70

D.6.2 Resultat . . . 70

D.7 Slutsatser . . . 71

E Iterativ utveckling och dess för- och nackdelar - Ludvig Erlander Klein 72 E.1 Introduktion . . . 72

E.1.1 Syfte . . . 72

E.1.2 Frågeställning . . . 72

E.2 Bakgrund . . . 72

E.3 Teori . . . 73

E.3.1 Den iterativa arbetsprocessen . . . 73

E.3.1.1 Fördelar med den iterativa arbetsprocessen . . . 73

E.3.1.2 Nackdelar med den iterativa arbetsprocessen . . . 74

E.3.2 LIPS-modellen . . . 74

E.3.2.1 Projektplanen . . . 75

E.4 Metod . . . 75

E.5 Resultat . . . 75

E.5.1 Arbetsprocessen i PUM . . . 75

E.5.2 Analys av mötestiden under PUM . . . 76

E.5.3 Andel tid lagd på möten jämfört med effektiv utvecklingstid under ut-vecklingsfasen för KMM jämfört med PUM . . . 76

E.6 Diskussion . . . 76

E.6.1 Resultat . . . 77

E.6.1.1 Fördelar som kunde observeras eller ej observeras . . . 77

E.6.1.2 Nackdelar som kunde observeras eller ej observeras . . . 79

E.6.1.3 Analys av mötestiden under PUM . . . 80

E.6.1.4 Hur mycket tid lade vi på möten jämfört med ett litet projekt genomfört med V-modellen? . . . 80

E.6.2 Metod . . . 80

E.7 Slutsatser . . . 81

F En beskrivande fallstudie av kandidatarbetet med stort engagemang från kund -Pontus Jönrup 82 F.1 Introduktion . . . 82

F.1.1 Syfte . . . 82 F.1.2 Frågeställning . . . 82 F.2 Bakgrund . . . 82 F.3 Teori . . . 83 F.3.1 Fallstudie . . . 83 F.3.2 Kravspecifikation . . . 83 F.3.3 Projektplan . . . 83 F.3.4 Agilt arbetssätt . . . 84 F.4 Metod . . . 84 F.4.1 Fallstudie . . . 84 F.4.2 Triangulering av data . . . 84

F.4.3 Enkät till projektgruppen . . . 84

F.4.3.1 Inledande frågor . . . 85

F.4.3.2 Frågeställningsspecifika frågor . . . 85

F.4.4 Litteraturstudie . . . 86

F.5 Resultat . . . 86

F.5.1 Enkät till gruppen . . . 86

F.5.2 Litteraturstudie . . . 88 F.6 Diskussion . . . 89 F.6.1 Källkritik . . . 89 F.6.2 Metod . . . 89 F.6.3 Resultat . . . 89 F.6.4 Svårigheter . . . 89 F.7 Slutsatser . . . 90

F.7.1 Hur har arbetet med konsulterna påverkat kravspecifikationen som togs fram till projektet? . . . 90

F.7.2 Hur har arbetet med konsulterna påverkat projektplanen som togs fram till projektet? . . . 90

F.7.3 Hur har arbetet med konsulterna påverkat arbetsmetodiken och pro-cessen som togs fram till projektet? . . . 90

G Hur kan Azure DevOps underlätta ett mjukvaruutvecklingsprojekt? -Samuel Knutsson 91 G.1 Introduktion . . . 91 G.1.1 Syfte . . . 91 G.1.2 Frågeställning . . . 91 G.1.3 Avgränsningar . . . 91 G.2 Bakgrund . . . 91 G.3 Teori . . . 92 G.3.1 Agil systemutveckling . . . 92 G.3.2 Continuous integration . . . 92 G.3.3 Continuous delivery . . . 92 G.3.4 Azure DevOps . . . 92 G.4 Metod . . . 93 G.5 Resultat . . . 93

G.5.1 Continuous integration & Continuous Delivery . . . 93

G.5.2 Agil systemutveckling . . . 94

G.5.3 Azure DevOps . . . 94

G.5.4 Vår användning av Azure DevOps . . . 94

G.6 Diskussion . . . 94

G.6.1 Metod . . . 94

G.6.2 Resultat . . . 95

H Jämförelse av funktionella komponenter och klasskomponenter i React

-Simon Tsehaie Russom 97

H.1 Introduktion . . . 97 H.1.1 Syfte . . . 97 H.1.2 Frågeställning . . . 97 H.1.3 Litteratur . . . 97 H.2 Teori . . . 98 H.2.1 React . . . 98 H.2.2 React-komponenter . . . 98

H.2.3 React-tillstånd (eng. React states) . . . 98

H.2.4 Props . . . 98

H.2.5 React livscykelfunktioner (eng. React lifecycle functions) . . . 98

H.2.6 Hooks . . . 98 H.3 Metod . . . 98 H.3.1 Kodläsbarhetstest. . . 99 H.3.2 Prestandatest . . . 99 H.4 Resultat . . . 101 H.4.1 Kodläsbarhetstest . . . 101 H.4.2 Prestandatest . . . 101 H.5 Diskussion . . . 103 H.6 Slutsatser . . . 104

H.6.1 Finns det signifikant läsbarhetsskillnad mellan klass- och funktionella komponenter? . . . 104 H.6.2 Hur skulle användningen av klass komponenter påverka vårt projekt? . 104

Figurer

5.1 Designvyn hos systemet ARCH. . . 18

5.2 Systemanatomi . . . 24

D.1 Diagram som visar vattenfallsmodellen i ett utvecklingsprojekt. . . 62

D.2 Diagram som visar en iterativ modell i ett utvecklingsprojekt. . . 63

E.1 Diagram som visar LIPS-modellens olika faser. Djupet speglar vilken detaljnivå arbetet är på, där djupare är högre detaljnivå. . . 74

E.2 Stapeldiagram som visar hur mycket tid som lades på möten per person med bara gruppen, med kunden och med handledaren under projektets gång. . . 76

E.3 Stapeldiagram av procentuell andel som möten respektive effektiv utveckling som utgjorde utvecklingsfasen för projekten KMM respektive PUM. . . 77

H.1 Funktionell komponent som ska användas vid prestandatestet . . . 100

H.2 Klasskomponent som ska användas vid prestandatestet. . . 100

H.3 Summan av tiden deltagaren tog att gå igenom varenda komponent . . . 101

Tabeller

4.1 Gruppens roller och dess fördelning. . . 11

H.1 Fråga - 2. . . 102

H.2 Fråga - 2. . . 102

H.3 Fråga - 3. . . 102

1

Introduktion

1.1

Motivering

Vad skiljer husdrömmar från verkligheten? Tillgänglighet. Husmarknaden är otillgänglig för många i nuläget. Antingen är husen för dyra eller så är de helt enkelt inte anpassade för sina potentiella köpare. Varför inte bygga om och göra rätt då? Många hus väntar bara på en liten ombyggnation för att bli helt rätt, men bävan för den omständiga bygglovsprocessen gör att denna idé ofta rinner ut i sanden. Svaret på den omöjliga frågan måste då vara att lösa tillgängligheten, något som projektet ARCH ämnar till. Gemene man saknar verktygen och vägledningen till att söka och nå upp till ett godkänt bygglov själva, men med plattformen vi i projektgruppen är med och utvecklar kommer kunskapen nå ner till de som drömmer och de som vill skapa. Genom att skapa en plattform med alla hjälpmedel för att klara av moderna bygglovskrav kommer processen från dröm till verklighet inte längre bero på tillgänglighet, och det här projektet är ett steg mot den framtiden.

1.2

Syfte

Syftet med denna rapport är att dokumentera de erfarenheter vi i kandidatprojektgrupp 4 (2021) samlat på oss under arbetet med projektet ARCH. Detta utförs genom att beskriva de arbetsprocesser gruppen följt, värdet gruppen skapat för kunden Buildility samt genom gemensamma och individuella djupdykningar i ämnen som varit viktiga för projektet. Målet är inte bara att sammanställa och bevara gruppens erfarenheter för den egna framtiden, utan också för att lägga en grund och ett exempel för framtida projektgrupper i kandidatkursen TDDD96.

1.3

Frågeställning

1. Hur kan systemet ARCH implementeras så att man skapar värde för kunden?

2. Vilka erfarenheter kan dokumenteras från programvaruprojektet ARCH som kan vara intressanta för framtida projekt?

1.4. Avgränsningar

4. Hur påverkas implementationsarbetet när gruppen ärver en färdig kodbas från kun-den?

1.4

Avgränsningar

Den naturliga avgränsningen som vi alla drabbades av under våren 2021 var den rådande pandemin som svepte över jorden. Självklart drabbade detta även oss och samtliga delar av projektet hanterades därför på distans utan möjlighet att träffas fysiskt under arbetet. En annan uppenbar avgränsning är de 3200 timmar som gruppen ska lägga inom loppet av projektet. I detta ska allt från utbildning, utveckling och rapportskrivande räknas in, det vill säga att tiden lätt kan dra iväg om man inte är varsam med sin planering.

Mer specifikt för detta projekt är att det är en fortsättning på ett tidigare projekt och därför finns även en etablerad grund och struktur som måste följas av oss som ska vidareutveckla projektet. Detta leder till en viss avgränsning i hur projektet utförs och hanteras, då standar-der redan är satta sedan tidigare.

Som gästutvecklare hos företaget Buildility har vi inte heller full tillgång till alla funktioner inom företagets plattform i Microsoft Azure eller Microsoft Teams. Många av dessa funk-tioner är inte applicerbara inom ramen av projektet men vi anser att detta ändå är värt att nämna.

Det förväntas inte heller att vi som projektgrupp ska avsluta projektet och uppnå samtliga mål för produkten. Målet är snarare att vidareutveckla och bistå med goda idéer för nytän-kande framsteg.

1.5

Kontext

Projektarbetet utförs inom ramarna för kursen TDDD96, “Kandidatprojekt i programvaruut-veckling”, på Linköpings universitet. Således följer projektet de mål och inlämningar som för-väntas av kursen och ett mål på 400 timmars arbete sattes per person för projektet. Eftersom antalet timmar var en avgränsning inom projektet blev prioritering och planering också vik-tiga aspekter. Utöver det sattes även en deadline för kursens och projektets avslut den 25 maj 2021. Minimikravet på de dokument som skapades är samtliga dokument i följande lista:

• Projektplan • Kravspecifikation • Kvalitetsplan • Systemanatomi • Arkitekturdokument • Testplan • Statusrapport • Utvärdering • Veckorapporter

1.6. Ordlista

1.6

Ordlista

Ord Beskrivning

API Applikationsprogrammeringsgränssnitt

(eng: Application programming interface)

ARCH Projektet som skapats av företaget

Buildility. Gruppens mål är att vidareutveckla denna.

ASP .NET Core Ett ramverk som fokuserar på

cross-platform-utveckling av molntjänster.

Bootstrap 4/React-bootstrap Ett kodbibliotek som underlättar skapandet av grafiska

användargränssnitt.

Buildility Företaget som äger projektet ARCH.

Kund till gruppen.

C# Ett objektorienterat programspråk

utvecklat av Microsoft.

CSS Stilmall (eng: Cascading style sheets) är

ett språk som beskriver

presentationsstilen för ett dokument. Entity Framework Core Ett verktyg för att hämta och spara

data från databaser.

Git Mjukvara som underlättar

versionshantering.

Google Drive Ett system för lagring och

synkronisering av filer online.

JavaScript Ett skriptspråk som bland annat kan

användas för att skapa interaktivitet på webbsidor.

Kanbanbräde En teknik som används för att hantera

och organisera uppgifter.

Kanvas En kanvas är i detta fallet den

designduk i webbapplikationen som 2D-ritningsverktyget Konva.js ritar på. Konva.js/React-konva Ett ramverk för att utöka JavaScripts

2D-ritnings funktioner.

Microsoft Azure En tjänst som tillhandahåller cloud computing, verktyg och ramverk.

Microsoft Teams En applikation för gruppmöten och

informationsdelning.

MVP Minsta livskraftiga produkt (eng:

Minimal viable product).

React Ett bibliotek till JavaScript för arbete

med gränssnitt.

SCRUM Ett ramverk för agil

produktutveckling.

SPA En ”Single Page Application” är en

applikation vars gränssnitt är begränsat till fönstrets storlek.

Three.js Ett bibliotek till JavaScript för att

skapa och representera 3D-objekt.

2

Bakgrund

Denna sektion behandlar kundens och projektgruppens tidigare erfarenheter och bakgrund.

2.1

Kundens bakgrund och syfte

Buildilitys projektförslag lade grunden till projektet och gick ut på att vidareutveckla en webbapplikation för att underlätta bygglovsprocessen i Sverige. Som bakgrund till Buildili-tys vision beskrevs följande scenario:

Förra året fick byggnämnder runt om i Sverige in över 200.000 ansökningar gällande ombyggnation, nybyggnation eller tillbyggnation. Dessa ansökningar höll en extremt hög varians i kvalitet. Vissa personer valde att försöka skissa sina idéer lite lätt på ett papper medan andra sänkte tid och pengar i CAD-liknande verktyg eller professionell hjälp. Processen kostar idag både tid och pengar för pri-vatpersoner såväl som handläggare. Det är den här problemställningen som gett liv till Buildility och deras plattform ARCH.

Kundens vision är att Buildility ARCH blir en samlingsplats för all kunskap och kompe-tens som en oerfaren fastighetsägare kan behöva under en bygglovsprocess. ARCH ska leda och underlätta fastighetsägaren genom hela processen, från planlösning till offert. Buildility påbörjade ett samarbete med företaget Combitech år 2020 och två konsulter hyrdes in från Combitech för att ta del av vidareutvecklingen hos Buildility. Kunden såg dock möjlighe-ten att få ytterligare insikter och perspektiv och anmälde därför projektet till kandidatkursen TDDD96 för att låta studenter vara en del av utvecklingsteamet och vidareutvecklingen. Både utvecklarna på Combitech och kunden fanns till förfogande för projektmedlemmarna under projektets gång.

2.2

Gruppens tidigare erfarenheter

Projektgruppen bestod av åtta medlemmar som studerade civilingenjörsutbildningar vid Linköpings Universitet, både från civilingenjörsprogrammet i datateknik och civilingenjörs-programmet i mjukvaruteknik. Samtliga i gruppen hade sedan tidigare genomfört projekt av jämförbar struktur men det hade aldrig tidigare ställts så höga krav på robusthet och

skalbar-2.2. Gruppens tidigare erfarenheter

het. Eftersom projektet skulle återlämnas till kunden, och sedan integreras och vidareutveck-las tillsammans med kundens källkod efter projektets slut, var det stora krav på att koden som skapats i projektet skulle sträva efter att hålla källkodens standard. Få i gruppen hade tidigare erfarenhet av webbprogrammering eller de programmeringsspråk och ramverk som använts. Majoriteten av gruppmedlemmarna hade aldrig tidigare fulländat en arbetsprocess eller följt en tydlig process genom ett helt projekt, detta blev därmed ett tydligt mål för grup-pen.

3

Teori

Detta kapitel ligger som grund för det arbete som utförts i projektet och går således igenom termer, koncept och produkter som projektgruppen använt sig av under projektet.

3.1

Programmeringsspråk och bibliotek

Följande sektion beskriver de programmeringsspråk och bibliotek som använts under pro-jektets gång.

3.1.1

C#

C# är ett objektorienterat programspråk utvecklat av Microsoft med syftet att vara enkelt och modernt, samt en del av .NET-plattformen. Språket är baserat på C++ och liknar Java [1]. C# är det språk som används med ramverket ASP .NET Core som valdes till utveckling av backend i detta projekt tack vare dess fördelar som diskuteras i 3.3.2.

3.1.2

JavaScript

JavaScript är ett skriptspråk som vanligtvis inbäddas i HTML-sidor och exekveras i en webb-läsares JavaScript-motor. Det används bland annat för att skapa interaktiva hemsidor. Det är även vanligt att använda tredjeparts-JavaScript-bibliotek som t ex React, Angular och JQue-ry. Samtliga exempelbibliotek användes i projektet sedan innan projektgrupppens grundande [2].

3.1.3

React

React är ett JavaScript-bibliotek som förenklar skapandet av webbgränssnitt [3].

3.1.4

Konva.js / React-konva

Konva.js är ett JavaScript-bibliotek som används för att skapa 2D-vyn för planritningsverkty-get i detta projekt. Biblioteket ämnar att underlätta ritning av figurer, animationer, lager och händelse hantering [4].

3.2. Arbetsmetodik

3.1.5

Entity Framework Core

Entity Framework Core är ett objekt-relationellt mappningsverktyg som konverterar data-bastabeller till klasser, tabellrader till objekt, samt celler till objekt-attribut. Detta är en vä-sentlig del av Microsofts .NET-ramverk som automatiserar kopplingen mellan C#-koden och databasen [5].

3.1.6

Bootstrap 4 / React-bootstrap

Bootstrap är ett ramverk som förenklar utvecklingen av hemsidors design genom att genere-ra en enhetlig design som även anpassar sig till klientens skärmyta automatiskt. Detta görs genom CSS och eventuellt JavaScript. React-bootstrap ersätter Bootstrap JavaScript där varje komponent skrivits om som en React-komponent [6].

3.2

Arbetsmetodik

Arbetsmetodikerna som nämns nedan användes av projektgruppen för att främja arbetets effektivitet. Deras mål och användningsområden beskrivs i följande sektion.

3.2.1

Scrum

Scrum är ett ramverk som implementerar kortare iterationer av till exempel kodimplementa-tioner, så kallade sprintar. Sprintar är oftast tidsbestämda och sätts in i ett sprintschema som till slut leder till en färdig produkt. Scrum använder sig även av småmöten kallade ”Daglig Scrum” som går ut på att det ska hållas ett kort möte där man går igenom dagens aktiviteter under en relativt kort tid. Sådana möten kan också kallas ”Stå upp”-möten för just den an-ledningen att alla i teamet ska stå upp och inte dra ut på tiden i onödan. Utöver dessa möten och sprintar tar även ramverket hand om dokumentation med hjälp av till exempel product backlog och sprint backlog. Detta gör det lättare att hålla koll på hur individerna ligger till i projektet samt vad som gjorts för framtida referens [7][8].

3.2.2

Kanbanbräde

Ett kanbanbräde är ett verktyg för att implementera Kanban-metoden, vars syfte är hantera och förbättra arbetet inom en grupp. Detta fysiska eller virtuella bräde utgörs av en upp-sättning kolumner med plats för kort som föreställer papperslappar. Varje kort motsvarar en uppgift och dess position i kanbanbrädet motsvarar dess status. Valet av kolumner anpassas till gruppen och projektet [9].

3.2.3

Trello

Trello är huvudsakligen ett planeringsverktyg i molnet som ser mycket likt ut ett Kanbanbrä-de. Eftersom Trello är ett program istället för ett fysiskt bräde kan det spara mycket informa-tion på varje kort vilket, gör det lättare att dela upp ett arbetsflöde i mindre delar, samt att se vad som finns kvar att göra [10].

3.3

Verktyg

I denna sektion beskrivs verktygen som användes.

3.3.1

Microsoft Azure DevOps

DevOps presenteras i dagsläget som en kombination av utvecklingskulturella principer, pro-cesser och verktyg som riktar sig mot att förenkla utvecklingen av produkter för företag. Ett

3.3. Verktyg

företag kan till exempel förbättra sammanhållningen mellan team, hantera buggar längs med utvecklingsprocessen samt öka kundnöjdheten på ett smidigare sätt med hjälp av DevOps olika funktionaliteter [11][12].

3.3.2

ASP .NET Core

ASP.NET Core är en ombyggnation av ASP.NET och är ett mer modulärt ramverk eftersom det är öppen källkod samt är kompatibelt med macOS, Linux och Windows. Det nya ramver-ket strävar även efter att bli det ledande molnutrymmet som tillåter till exempel utveckling av mobil backend, webbapplikationer och tjänster [13][14].

4

Metod

En uppställning metoder har använts för att besvara frågeställningarna, driva utvecklingsar-betet och uppnå resultat. Detta kapitel syftar till att gå igenom dessa metoder och beskriva hur de har använts.

4.1

Utvecklingsmetod

Sektionen beskriver roller och metoder som applicerats under projektets gång för att upp-muntra till god utveckling.

4.1.1

Roller

I början av projektet tilldelades varje gruppmedlem en projektroll med ett tillhörande an-svarsområde. Medlemmarna ses i första hand som utvecklare men rollerna underlättar för-delningen av övriga arbetsmoment.

Teamledare

Teamledaren var gruppens representant utåt och hade ett större ansvar för gruppens målupp-fyllnad. Tilldelning av arbetsuppgifter föll inte under teamledarens ansvar, men hen hade sista ordet om situationen krävde det. Teamledaren agerade coach, snarare än projektledare.

Analysansvarig

Analysansvarig var mellanhanden mellan kunden och gruppen vilket betydde att hen for-mulerade kundens behov, dokumenterade dessa i en kravspecifikation och förmedlade kon-tinuerligt kundens åsikter till gruppen.

Arkitekt

Arkitekten ansvarade för att en stabil arkitektur fastställdes, samt identifikation av kompo-nenter och gränssnitt. Arkitekten förväntades kommunicera bärande idéer, som exempelvis övergripande teknikval.

4.1. Utvecklingsmetod

Tabell 4.1: Gruppens roller och dess fördelning.

Andersson, Adina Dokumentansvarig adian611@student.liu.se Dunby, Albin Testledare albdu638@student.liu.se Ericsson, Leon Teamledare leoer843@student.liu.se Jönrup, Pontus Analysansvarig ponjo823@student.liu.se Erlander Klein, Ludvig Arkitekt ludkl571@student.liu.se Knutsson, Samuel Konfigurationsansvarig samkn228@student.liu.se Rosenquist, Hampus Kvalitetssamordnare hamro777@student.liu.se Russom Tsehaie, Simon Utvecklingsledare simru247@student.liu.se

Utvecklingsledare

Utvecklingsledaren hade större ansvar för att leda utvecklingsarbetet framåt. Hen ansvarade för detaljerad design och beslut berörande utvecklingsmiljön, samt att produkten skapades enligt kravspecifikationen. Hen ansvarade även för utbildningen, och skrev en utbildnings-plan.

Testledare

Testledaren verifierade systemets funktionalitet genom exekvering och ansvarade för att skri-va en testplan och testrapport. Testledaren ansskri-varade även för att dessa testplaner följdes.

Kvalitetssamordnare

Kvalitetssamordnare ansvarade för systemets genomgående kvalitet, samt verifiering av att kvalitetskrav uppfyllts. Ansvaret för dessa områden bar hen tillsammans med testledaren. Kvalitetssamordnaren ansvarade för kvalitetsplanen, åtog sig initiativ- och uppföljningsan-svar samt tog vara på gruppens erfarenheter.

Dokumentansvarig

Dokumentansvarig hade huvudansvaret över dokumentmallar, ändringsrutiner och leveran-ser samt att dokumenten höll rätt standard och uppfyllde kraven.

Konfigurationsansvarig

Konfigurationsansvarig tog ansvar för utvecklingsarbetets versionshantering. Även under-hållning av versionshanteringsverktygen hamnade under hens ansvar, vilket inkluderade att överse att övriga gruppmedlemmar använde verktygen korrekt.

4.1.2

Projektidentitet

Gruppens roller, som definieras under 3.1.1, fördelades enligt tabell 4.1.

4.1.3

Gruppkontrakt

Strax efter projektidentiteten utformats skrevs ett gemensamt gruppkontrakt med syftet att sammanfoga gruppen bakom ett antal huvudprinciper. Den diskussion och de beslut som fat-tades kring gruppkontraktet gav förståelse och samhörighet, något som var speciellt viktigt tidigt i projektet då gruppens medlemmar var relativt obekanta med varandra.

4.1.4

Process

I projektet användes en agil arbetsprocess som togs fram tidigt i projektet och var starkt in-spirerat av Scrum . Då många i gruppen inte hade större erfarenhet av att arbeta enligt en

4.2. Verktyg

agil arbetsprocess kändes det befogat att ackommodera en existerande metod efter våra be-hov. Den iterativa processen Scrum valdes som grunden för gruppens arbetsprocess då det resulterar i kontinuerliga leveranser i form av sprintar, och passade väl in med den fortlöpan-de kommunikation projektgruppen ville upprätta med kunfortlöpan-den. Metofortlöpan-der som sprint backlog och stå-upp-möten användes utförligt under projektets gång. Buildility var måna om ett gott resultat och var engagerade i utvecklingsarbetet vilket underlättades av att ofta kunna pre-sentera ny funktionalitet.

Projektet delades upp i sprintar med en veckas omfång som kulminerade i ett veckomöte varje fredagseftermiddag. Teamet jobbade ständigt från en backlog som sattes upp utefter de aktiviteter som tagits fram i projektplanen. Backloggen uppdaterades ständigt av gruppmed-lemmarna under projektets gång. Varje sprint utvärderades i slutet på veckan tillsammans med att nästa sprint planerades genom att identifiera de aktiviteter som gruppen ville imple-mentera härnäst. Dagliga stå-upp-möten hölls för att bibehålla den kontinuerliga kommuni-kationen i gruppen, samt ge utrymme för eventuella frågor som uppstod under utvecklingen. För att visualisera den här processen och mäta arbetsflödet användes ett kanbanbräde i Trel-lo. Teamets Scrum-roller valdes inte officiellt utefter de roller definierade under 4.1.1 även om det i praktiken blev så. Det vill säga teamledaren agerade i rollen som Scrum-mästare medan analysansvarig agerade produktägare.

4.2

Verktyg

Följande sektion behandlar användningen av projektets verktyg.

4.2.1

Trello

I verktyget Trello skapades ett kanbanbräde för att visualisera flödet av aktiviteter och tillhan-dahålla projektets backlog. Brädet delades upp i kolumnerna Backlog, Design, To-Do, Doing, Testing and Review och slutligen Done. Varje kort bestod av en titel, en beskrivning, etiketter och medlemmar. Etiketterna användes under förstudien för att beteckna kategorin på akti-viteten men dessa övergick under implementationsfasen till att indikera relativ storlek på aktiviteten med hjälp av benämningarna XS, S, M, L och XL. Gruppens medlemmar var en-skilt ansvariga för att uppdatera kanbanbrädet med nya kort samt förflyttning av egna kort genom brädan. När ett kort nått Testing and Review bestämdes det att minst en medlem som inte deltagit i kortets tidigare utförande, skulle åta sig uppgiften att agera inspektör av upp-giften. Ansågs alla krav för uppgiften vara uppfyllda ansågs uppgiften vara klar och flyttades då till kolumnen Done för arkivering. Trello som verktyg utvärderades efter varje sprint med en enkät som skickades ut av kvalitetsansvarig.

4.2.2

Google Drive

För att samla gruppens interna dokument såsom projektplan, gruppkontrakt, kravspecifi-kation, mötesprotokoll m.m. skapades en gemensam Google Drive-mapp. Här delades alla dokument som inte föll under sekretessbeläggningen i kontraktet som medlemmarna skri-vit på med kunden. Google Drive ansågs vara det smidigaste sättet att dela dokument. Det erbjuder även möjligheten att samskriva över nätet vilket var extra viktigt under distansläget.

4.2.3

Microsoft Teams

Gruppen hade ett Team på plattformen Microsoft Teams där även gruppens handledare hade tillgång. Plattformen användes för de dagliga stå-upp-mötena, veckomötena och handledar-mötena. Microsoft Teams valdes på grund av medlemmarnas bekanthet med programmet.

4.3. Kvalitet

Kunden tillhandahöll även ett Team åt projektgruppen där det publicerades den redan ex-isterande dokumentationen kring ARCH. Det var även i detta Team som kundmöten hölls och frågor ställdes till konsulterna.

4.2.4

Azure DevOps

Azure DevOps användes av konsulterna som arbetat på ARCH fram till projektgruppen tog över utvecklingen. Gruppen blev inbjudna till ARCH projektet på Azure DevOps och fick på så sätt tillgång till den backlog som kunden och konsulterna satt upp samt projektets repotsi-torie. Gruppen valde dock att inte använda sig av backlog-funktionaliteten på Azure DevOps under projektet då bekantskapen med verktyget Trello var högre och ansågs erbjuda funk-tionalitet som behövdes. Det är under detta vektyg som så kallade pull-requests och merge-requests utfördes.

4.3

Kvalitet

Dokumentationsstandard granskades av kvalitetssamordnare och dokumentansvarig för att hålla en konsekvent och hög standard på de producerade dokumenten. Själva innehållet i dokumenten granskades av samtliga i gruppen innan inlämningar.

Under utvecklingsarbetet har en kodstandard följts. För att upprätthålla en konsekvent kod-struktur och format valde gruppen att följa den kodstandard som den redan existerande ko-den följer. Gruppen har valt att lägga till korta kommentarer i ko-den kod som tillförts när det bedömts underlätta läsbarheten. I syfte att forma koden till denna standard har kodgransk-ning genomförts med hjälp av Azures code review-funktion.

En annan kvalitetssäkrande åtgärd var, i linje med en agil arbetsmetod, en nära kontakt med kunden. Detta tog formen av dels korta frågor som ställdes kontinuerligt, dels presentatio-ner av utvecklingens status varannan vecka för kunden. Under dessa möten diskuterades eventuella problem, designval och utvecklingsbeslut. Kunden tilldelades även åtkomst till dokumentation som gruppen producerade kontinuerligt för att ge ytterligare insyn i grup-pens arbete.

4.3.1

Mätning av process

Gruppens kanbanbräde på Trello, som valdes till gruppens process i fokus, granskades i slutet av varje vecka med hjälp av två olika mått. Dels summerades antalet aktiviteter som skett under respektive vecka, där en aktivitet motsvarar en förändring som gjorts på någon uppgift i Trello, såsom tillagda medlemmar, kommentarer eller förflyttning av en uppgift på brädet. Detta mätvärde motsvarade således hur aktivt kanbanbrädet uppdaterats.

Den andra mätningen tog formen av en enkät som beskrivet i 4.8. Eventuella synpunkter som uppdagades diskuterades sedan muntligt inom gruppen.

4.3.2

Dokumentation av process

Processen dokumenterades i kvalitetsplanen.

4.4

Testning

För testning använde vi oss av kontinuerlig enhetstestning. De verktyg som användes var xUnit i Visual Studio och Jest i Visual Studio Code. När vi skrev dessa så fokuserade vi på fyra punkter. De skulle testa positiva och negativa fall, skrivas efter att koden var skriven,

4.5. Versionshantering

granskas av någon annan gruppmedlem innan de godkänns och täckning för koden skulle vara minst 70 %.

4.5

Versionshantering

För versionshantering använde gruppen sig av Git med repositorium i Microsoft Azure De-vOps. Stor vikt lades i att den kod som skrivits skulle vara av hög standard. För att underlätta en hög kvalité använde gruppen sig av Microsoft Azures code review-funktion. Kodgransk-ningen gick ut på att gruppmedlemmar granskade och validerade kod producerad av andra gruppmedlemmar innan koden laddades upp till repositoriet. Detta möjliggjorde att andra gruppmedlemmar kunde säkerställa att nyproducerad kod höll eftersträvad kvalité och gav medlemmar möjligheten att erbjuda med förslag på förbättringar. Det var också ett verktyg för att hitta logiska fel i implementerad kod.

För projektet valde gruppen att använda feature-branches som struktur i projektets reposito-rium. För varje ny feature skapades en ny branch där den implementationen av ny feature utfördes. Detta innebar att flera features kunde arbetas på parallellt utan att möjliga krockar skedde under implementationen. Det var också gynnsamt som utvecklare att kunna se struk-turen mellan tillagd kod i en viss branch och vilken feature som hörde till.

4.6

Värde för kund

Projektets huvudsakliga syfte var alltid att skapa en produkt som kunden såg värde i och kunde fortsätta utveckla utan någon avsevärd tröskel. För att uppnå detta mål och besvara frågeställningen 1, “Hur kan systemet ARCH implementeras så att man skapar värde för kunden?”, har vissa metoder utnyttjats som beskrivs i detta kapitel.

4.6.1

Kundkontrakt

Analysansvarig har under hela projektets gång ansvarat för en kontinuerlig dialog med kun-den för att förmedla gruppens utvecklingsarbete samt återkoppla kunkun-dens behov till grup-pen. I projektets förstudie innebar det här ansvaret att analysansvarig tillsammans med ar-kitekten definierade den kravspecifikation som gruppen arbetat utefter. Under implementa-tionsfasen så övergick det här ansvaret i att ständigt hålla kunden informerad kring gruppens utveckling något som utfördes genom att kunden fick ta del av gruppens veckorapporter. Det här arbetet var av stor vikt för att förhindra felsteg och felprioriteringar.

4.6.2

Demonstration

Under implementationsfasen utfördes även en demonstration för kunden med jämna mellan-rum på två veckor i samband med gruppens veckomöten. Under dessa möten så presenterade gruppen översiktligt vad de arbetat med och demonstrerade detta på ARCH webbplattform. Det här utfördes för att få feedback och visa värdet av utvecklingen.

4.7

Systemanatomi

Systemanatomin togs fram mot slutet av förstudiefasen i syftet att få en överblick av sy-stemets interna beroenden. Målet med systemanatomin var att skapa en lättförståelig re-presentation över systemet under utveckling. Anatomin togs fram genom ett gemensamt brainstorming-möte där alla medlemmarna deltog. Processen började med att individuellt

4.8. Metod för erfarenhetsfångst

komma fram med idéer och sedan sammanställa och koppla ihop det som tagits fram. Dis-kussion gav ett resultat som renskrevs av projektledaren.

4.8

Metod för erfarenhetsfångst

Sprint retrospectives har genomförts, där varje sprint utvärderades med målet att dokumen-tera och ta lärdom av gruppens erfarenheter. Under dessa utvärderingar fick alla i gruppen besvara följande frågor:

• "Hur har Trello påverkat ditt arbetsflöde under veckan? Där 3 är neutralt. Reflektera över om det sparat/kostat dig tid, samt hjälpt dig hålla ordning/skapat förvirring." • Finns det något du önskar gjordes annorlunda i Trello?"

• "Har du upplevt någon förvirring kring uppgifters status i Trello?" • "Övriga kommentarer? Behöver inte handla om Trello."

Verktygen som gruppen använde under utvecklingen utvärderas alltså också under dessa möten vilket gav oss möjlighet till direkt anpassning. Vi var även tydliga med att arbets-processen ständigt utvärderas och vid behov kan ändras. Detta arbete skedde i linje med frågeställning 2,“Vilka erfarenheter kan dokumenteras från programvaruprojekt ARCH som kan vara intressanta för framtida projekt?”.

4.9

Sprintar

Utvecklingsarbetet delades upp i sprintar med en veckas längd. Nedan finns sprintarna så som de planerades att utföras i projektet.

Sprint 1 - v.13

• Implementera ändring av dörrstorlek • Implementera ändring av fönsterstorlek • Implementera måttvisning

• Halvtidsseminarium

Sprint 2 - v.14

• Implementera måttvisning • Implementera skal-ändring

• Implementera möjlighet att lägga till rumsbeteckning i 2D-vyn • Areauträkning av rum och hela huset

Sprint 3 - v.15

• Implementera lager i vyn

• Implementera möjligheten att importera eget lager i 2D-vyn från en PDF eller bild • Implementera möjlig begränsning med utritning av en vägg till x-axeln eller y-axeln

4.9. Sprintar

Sprint 4 - v.16

• Inlämning 3 - Mån (19/4)

• Implementera enkel redigering av ritningen innan konvertering till PDF ska vara till-gänglig

• Implementera rådgivande bubblor för nya användare

Sprint 5 - v.17

• Implementera konvertering av enkel planritning till PDF • Duplicera existerande ritningar i ett projekt

• Implementera ångring

Sprint 6 - v.18

• Skriv manual

• Säkerställ att det finns stöd för Chrome, Edge, Safari och Mozilla • Implementera insättning och redigering av trappor av olika storlekar • Inlämning 4

Sprint 7 - v.19

• Implementera manual

• Implementera insättning och redigering av tak av olika storlek • Utvidga projektmenyer

5

Resultat

I detta kapitel beskrivs de resultat som uppnåddes från metoden.

5.1

Systembeskrivning

Systemet som gruppen har vidareutvecklat är en distribuerad webbapplikation bestående av en frontend, backend, databas och ett webb-API. Systemet möjliggör för användaren att teck-na planritningar som enkelt kan konverteras till PDF-format och skickas med i en eventuell bygglovsansökan. Systemet hade innan projektets början en begränsad funktionalitet vilket gruppen vidareutvecklade enligt den kravspecifikation som satts upp. Målet med projektet har varit att producera en MVP som kunden själv kan använda och utan större bekymmer forsätta utveckling av. Den delen av systemet som gruppen fokuserat på är designvyn för planritning i 2D. Funktionerna som implementerats har i stor utsträckning varit fristående från varandra och har krävt arbete både i frontend såväl som backend. Backenden är applika-tionens huvudmodul och innehåller därmed systemets logik. Det är även denna del av ap-plikationen som tillhandahåller programmets funktioner. Backend ansvarar slutligen för att modellera planritnings-domänen som lagras i databasen. Applikationens logik och funktio-nalitet tillhandahålls för auktoriserade användare genom ett webb-API. Frontendens huvud-funktion är att förse användaren med ett grafiskt rittverktyg som manifesteras i form av den tidigarenämnda designvyn. Detta avsnitt kommer i detalj redogöra de verktyg och funktio-ner som gruppen introducerat i design-, projekt- och sammansättningsvyn.

5.1.1

Projektvy

I projektvyn samlas länkarna till de dokument som berör användarens byggprojekt. Här hit-tas ritningen, ansökan och eventuella bilagor som kan redigeras, delas, kopieras eller raderas.

5.1.1.1 Duplicera ritning

Om användaren vill duplicera en specifik ritning görs detta genom att klicka på pappersiko-nen ”Kopiera ritning” i projektvyn på den ritning man som användare vill kopiera. Backenden genererar och sparar undan kopian som den sedan returnerar som ett nytt dokument i pro-jektvyn.

5.1. Systembeskrivning

5.1.2

Designvy

Designvyn syns i figur 5.1 bygger på en kanvas, verktygspanel och inspektörpanel. På kan-vasen visas planritningen som användaren arbetar på. Allt som visas på planritningen mo-delleras av backenden och lagras i applikationens databas. Verktygspanelen är placerad till vänster i designvyn och tillhandahåller de olika verktyg som användaren kan utnyttja. Pane-len är uppdelad i generella verktyg, inställningsverktyg, placeringsverktyg och väggverktyg. Kommande delkapitel beskriver dessa verktyg i mer detalj. Inspektörpanelen är unik till var-je verktyg, vissa är utan panelen, andra är helt beroende av den. I panelen tillhandahålls exempelvis fält för att ange namn på rum eller storlek på fönster.

Figur 5.1: Designvyn hos systemet ARCH.

5.1.2.1 Rum

Rumsverkyget ger användaren möjlighet att definiera rum och ytterväggar i planritningen. Verktyget används genom att markera ut punkter på planritningen i form av det rum som önskas, verktyget indikerar det ritade rummet med punkter och sammankopplade linjer. När användaren är färdig med att markera rummet används inspektörpanelen för att ange ett namn och skapa rummet. Ritningen visar nu det nya rummet med en transparent figur, mitt i figuren står rummets namn och area. Att beräkna arean på en polygon var inte trivialt, speciellt med tanke på att punkterna användaren placerar ofta sitter i planritningens väggar vilket inte får räknas med i rumsarean. Problemet löstes genom att iterera genom det punkter som definierades i en vägg och flytta dem till väggarnas insida för att sedan beräkna arean på nytt. För att ta reda på ritningens bruttoarea markeras istället planritningens ytterväggar och klickar på ”Sätt ytterväggar” knappen i inspektörpanelen. Nu visas designens bruttoarea på kanvasen.

5.1.2.2 Axellås

Ritning av väggar förenklas av två tangentbordskommandon. Genom att hålla in skifttangen-ten låses utritningen till x-axeln och y-axeln. Om man istället utgår från en vägg kan det vara användbart att låsa utritningen till en 90 graders vinkel, med hjälp av kontrolltangenten kan man uppnå detta. Låsningen var en funktionalitet som krävde en del trigonometriskt arbete speciellt när den sökta axeln är ortogonal mot en lutande vägg men efter det uppstod inga betydande komplikationer.

5.1. Systembeskrivning

5.1.2.3 Dörr och fönsterstorlek

När man ska placera nya väggenheter som dörrar eller fönster kan man med hjälp av inspek-törpanelen bestämma enheternas bredd. Det går även att ändra bredden på existerande väg-genheter genom att markera en eller flera i ritningen. Den angivna bredden kommer skickas in såvida det inte finns någon typ av begränsning på väggen, i detta fall kommer enheterna ändras till den största möjliga bredd. Verifieringen av den angivna bredden var den tyngsta delen av aktiviteten, problemet angreps genom att iterera över de väggar som påverkades av storleksändringen och markera ut ett antal fixerade punkter som inte fick överskridas. En-heternas storleksändring kontrollerades sedan mot de fixerade punkterna för att återge den största tillåtna storleksförändringen.

5.1.2.4 Hantering av dörrar och fönster i hörn

När en dörr eller ett fönster är placerad på en vägg finns det möjlighet att dra detta objekt längs med väggen för att byta dess position. Vid projektstart stannade inte dessa objekt vid en anslutande vägg utan lade sig istället ovanpå hörnet som var ihopkopplat. Denna bug löstes, och oberoende av vinkel så stannar nu fönstret så fort den kommer i kontakt med den anslutande väggen.

5.1.2.5 Mått

Detaljerade mått är en väsentlighet hos alla ritningar och det var en av de viktigaste funk-tionerna kunden efterfrågade. Implementationen är tvådelad, i första hand finns en mått-inställning längst upp i verktygspanelen som växlar designvyn mellan att vissa och inte visa mått. Med denna inställning visas mått för hela väggar samt de dörrar och fönster på rit-ningen. Den andra delen av implementationen sker oberoende av om måttverktyget är valt. Genom att markera en vägg, ett fönster eller dörr på ritningen ritas andra mått ut, nämligen för väggar ritas det ut mått för alla vägg-segment, och för fönster och dörrar ritas det ut både måtten till fönstret och dörren men också måttet för fönstret och dörren självt.

5.1.2.6 Lager

Lagerfunktionalitet skapades för att hantera byggnationer som sträcker sig över flera våning-ar eller så kallade lager. Sedan tidigvåning-are bestod ett projekts design i designvyn av en lista av våningar som i sin tur äger resterande objekt som representeras i kanvasen. För att implemen-tera lager användes denna list-struktur. Detta säkerställer både att relationer och ordning mellan lager hålls intakt samt att våningens tillhörande objekt och deras beroenden stängs inne i sin rätta kontext. Detta innebär att lagren har funktionalitet för att skifta plats mellan varandra utan att objekt lägre ner i strukturen korrumperas eller att strukturen i sig självt påverkas. För att byta mellan dessa lager väljs önskat lager i inspektörpanelen. Fortsättnings-vis är funktionerna ”lägga till våning” och ”ta bort våning” i sin helhet handlingen av att skapa respektive ta bort ett våningsobjekt. Således måste alltså varje våning ha ansvaret för de undre objektens existens och borttagning när dessa handlingar träder i kraft. Det går även att flytta lager, genom att klicka på en uppåt respektive nedåt-pil för att flytta lagret uppåt eller nedåt i listan. Ännu en funktionalitet som hör till lager är möjligheten att se flera lager samtidigt. Genom att klicka på en liten ruta som ligger bredvid lager-ikonen görs detta lager ”synligt”, vilket innebär att om man har något annat lager markerat så kommer det andra lagret synas genomskinligt.

5.1.2.7 Importera bakgrundsbild

Vid utbyggnad utgår bygglovsansökningsprocessen ofta från en inskannad planritning i form av en bild eller PDF. Det är således önskvärt att digitalisera denna ritning i planritningsverk-tyget för att sedan kunna rita utbyggnationen. Därför implementerades funktionalitet för att

5.2. Processbeskrivning

möjliggöra importering av bakgrundsbilder i planritningsvertyget. När den inskannade rit-ningen ligger i förgrunden är det enkelt att placera ut väggar, fönster och dörrar på korrekt plats med bilden som mall. Bildfunktionen tillåter användaren finjustera storleken på bilden genom att enkelt dra, alternativt skriva in exakta mått. Detta hjälper användaren skala bilden, så att mått överensstämmer. Även rotering av bild är implementerat, vilket är viktigt då en inskannad ritning ofta är sned. För att underlätta processen ytterligare kan bilders genom-skinlighet justeras, samt gömmas temporärt med en kryssruta.

5.1.3

Sammanställningsvy

När planritningen anses vara färdig är sammanställningsvyn det nästa steget i bygglovspro-cessen. Genom en popup-ruta väljer användaren de mått som ska visas för respektive våning i ritningen, när detta val är gjort hamnar användaren på den nya vyn. Vyn består precis som designvyn av en kanvas men i detta fall består kanvasen av planritningens våningar. An-vändaren får fritt placera våningarna på ett utmarkerat ark på så sätt som hen vill att den slutgiltiga PDF:en ska se ut. Användaren kan använda pilverktyget får att placera ut pilar på kanvasen för att förtydliga ansökan. Sista steget är att generera en PDF av arket vilket enkelt görs med ett knapptryck i verktygspanelen.

5.1.4

Minneshantering

Under projektet förekom en hel del buggar av till synes oförklarliga anledningar. Efter sök-ning genom koden hittades en del minnesläckor i databashanteringen som skapade problem för slutanvändaren, som till exempel när en användare ville skapa ett rum vid namn ”Bad-rum” och inte lyckades eftersom ett gammalt rum vid namn ”Bad”Bad-rum” redan fanns i databa-sen men som inte var synlig för användaren. Ett annat problem förekom när användaren ville radera ett helt projekt för att börja om från början. Ifrån användarens perspektiv såg det ut som allting fungerade som det skulle när projektet raderades men i själva verket låg all data om det projektet kvar i databasen utan någon form av möjlighet att rensa bort det vid ett sena-re tillfälle. Fortsättningen av minneshantering blev även en hög prioritet efter upptäckandet av de första minnesläckorna för att behålla stabiliteten av programmet.

5.2

Processbeskrivning

Denna sektion bryter ner processerna som användes under projektets gång, syftet är att få en bättre bild av hur arbetet utfördes.

5.2.1

Utvärdering

Här tas resultat från alla utvärderingsmetoder upp och visualiseras med grafer.

Enkät

Resultatet från frågan ”Hur har Trello påverkat ditt arbetsflöde under veckan?” presenteras som ett snitt av gruppens svar nedanför där 5 indikerade en mycket positiv påverkan och 1 en mycket negativ påverkan.

5.2. Processbeskrivning 6 8 10 12 14 16 18 0 1 2 3 4 5 Vecka Betyg Enkät Mätning

Antalet förändringar som skedde i kanbanbrädet per vecka presenteras nedanför. Föränd-ringar definieras enligt Trello som en förflyttning, redigering eller arkivering av ett kort på brädet. 6 8 10 12 14 16 18 0 20 40 60 80 100 120 Vecka Antal Aktiviteter

5.2.2

Förbättringar

Efter kvalitetssamordnaren diskuterade utvärderingsresultaten med coacherna halvvägs in i projektet under vecka 13, bestämdes det att gruppen behöver fokusera på att dela upp upp-gifter i kanbanbrädet i mindre deluppupp-gifter samt göra en ansträngning att uppdatera mer frekvent. Detta diskuterades med hela gruppen under ett möte där gruppen kom överens om att göra en gemensam insats för att försöka använda kanbanbrädet i större utsträckning och dela upp uppgifter i mindre delar.

Under de efterföljande veckorna kunde en ökning i betyget för kanbanbrädets användbarhet skådas i enkätundersökningen som presenterat i 5.2.1. Huruvida detta främst berodde på processförbättringen eller att gruppen blev mer erfaren med verktyget allt eftersom är svårt att avgöra.

5.2. Processbeskrivning

5.2.3

Kvalitetskrav

De tre kvalitetskrav som fanns var prestationskrav på mjukvaran. Dessa testades av testle-daren och kvalitetssamordnaren genom manuella tester. Krav 3.1 och 3.3 konstaterades vara uppfyllt efter att ha navigerat runt i hela användargränsnittet och uteslutande erhållit en re-sponstid kortare än 1 sekund, samt en kortare kommunikationstid mellan frontend och bac-kend än 5 sekunder. Krav 3.2 kunde verifieras genom att gå igenom bacbac-kendkoden vi tillfört till projektet och konstatera att inga beräkningar av högre tidskomplexitet än N2förekom, där N är antalet komponenter.

5.2.4

Sprintar

Sprintarna som utfördes under projektets gång var planerade att ske varje vecka med viss överlappning för att se till att implementationer blev implementerade utan buggar eller död kod. Viss justering i prioritet skedde tillsammans med kunden för att främja kundens önske-mål, resultatet var följande uppsättning sprintar.

Sprint 1 - v.13

Implementering av ”ändring av dörr- och fönsterstorlek” blev inte färdigställt innan sprin-tens slut, även måttsättningen tog lite längre tid och fortsattes in i veckan efter. En stor an-ledning till att det tog längre tid än väntat var då var första gången som gruppen program-merade direkt i ARCH efter att ha lagt ett antal veckor på inlärning av de nya systemen och kodspråken. Det var även påskvecka vilket gjorde att ett antal gruppmedlemmar hade annat planerat. Sprinten innebar även halvtidsseminariumet vilket utfördes i sin helhet.

Sprint 2 - v.14

Det som var kvarliggande från dörr- och fönsterimplementationen samt måttimplementatio-nen blev klart i denna sprint. Implementation av rum, rumsarea samt rumsbeteckning på-börjades men även detta blev inte helt klart på grund av det kvarliggande implementationen från den tidigare sprinten.

Sprint 3 - v.15

Under sprint 3 påbörjades implementation av ”lager/våningar” samt möjligheten att begrän-sa utritning av en vägg till x-axeln eller y-axeln. Under veckan blev rumsimplementationen till större del klar förutom lite mindre buggfixar samt att begränsningen av väggarna blev klara. Utöver implementationerna lades även mycket tid på inlämning 3 och komplettering av de dokument som skulle lämnas in i kandidatkursen till veckan efter.

Sprint 4 - v.16

Sprint 4 var veckan för inlämning 3 inom kandidatkursen och därav lades mycket tid på att färdigställa och skriva vidare på gruppens individuella delar för möjligheten till ytterligare kommentarer inför sista inlämningen. I implementationsväg slutfördes arbetet med rum och lager samt att gruppen sammanfogade alla implementationer av projektet än så länge för att lägga i release-branchen och försäkra att allting fungerade som det skulle. Implementationen av rådgivande bubblor för användare var en av de krav som bortprioriterades av kunden för att påbörja andra delar istället samt att redigering av ritning blev flyttad till nästkommande vecka.

5.3. Gemensamma erfarenheter

Sprint 5 - v.17

Sprint 5 inleddes med att se över de småbuggar som fanns kvar i release-branchen och att påbörja implementationen med redigering av ritning. Att infoga bakgrundsbilder på planrit-ningen var en aktivitet som blev färdig under denna sprint, denna aktivitet hade sett mycket arbete då den var högst efterfrågad av kunden.

Sprint 6 - v.18

Sprint 6 var fylld med dokumentation då den förväntades avslutas med ett första utkast på kandidatrapporten. Utöver detta arbetade ett team vidare med redigeringsvyn som påbörja-des under sprint 5. Vyn krävde mycket diskussion med kunden och konsulterna, strukturen ändrades omgående och flertal designbeslut togs.

Sprint 7 - v.19

Sprint 7 låg efter inlämning av denna kandidatrapport, därmed utgick gruppen ifrån de upp-gifter som finns beskrivna under sektion 4.9.

5.3

Gemensamma erfarenheter

Här dokumenteras de erfarenheter gruppen samlat på sig som kan utnyttjas i framtida pro-jekt.

5.3.1

Gruppkontrakt

Gruppen utformade tidigt ett gruppkontrakt, vilket i efterhand konstaterats av gruppen som klarläggande. Pontus Jönrup delade med sig av tidigare kunskap och frågeställningar kring gruppkontrakt vilket sedan utvecklades tillsammans inom gruppen till ett färdigställt kon-trakt som förtydligade förväntningarna på varje enskild gruppmedlem och gav en grund som senare kom att uppskattats av gruppen. Erfarenheten av att utveckla kontraktet var lärorik och många punkter som lätt glöms bort eller försummas upptäcktes vara vital för gruppen och hur arbetsprocessen skulle komma att utvecklas.

5.3.2

Existerande kodbas

Till skillnad från andra projektgrupper under dessa former hade denna grupp tillgång till kundens fullständiga kodbas, vilket tydligt förändrade fördelningen av arbete. Gruppen ha-de mindre fokus på att lösa arkitekturella problem då ett kodskelett redan var på plats och istället övergått till ett fokus på att förstå den existerande koden och strukturen. I början av projektet upplevdes detta som en svårighet då frågor runt kod ofta krävde externa svar. Allt eftersom att gruppen blev mer bekväm med utvecklingsspråken blev den existerande kodbasen ett stöd som gjorde implementeringen effektivare och mer lärorik. I slutändan re-sulterade det även i att den produkt vi levererade var stabilare samt att vi som utvecklare mognade snabbare.

5.3.3

Distansläge

Som tidigare nämnt i 1.4 är det värt att nämna det rådande distansläget som en värdefull erfa-renhet. Gruppen kan komma överens om att samtliga saknar fysiska möten men att projektet är väl genomförbart även under dessa omständigheter. Många upplever svårigheter med di-sciplin och arbetseffektivitet när de sitter i en hemmamiljö. Lätt att bli distraherad och många använder tid till saker som inte skulle varit tillåtet på en normal arbetsplats. Det upplevs även att det är svårare att ställa mindre frågor eller be om mindre råd när arbete utförs på distans,

5.4. Systemanatomi

i jämförelse med att sitta flera i gruppen på samma plats även om samtliga har separata ar-beten. Med det sagt upplever även samtliga i gruppen att möten har varit mer givande och effektiva under dessa förutsättningar. Det är enklare att bestämma möten och det är enklare att utnyttja tiden eftersom det inte finns någon tidspress i samband med förflyttning mellan aktiviteter.

5.3.4

Arbetsprocess

Gruppen noterar att arbetsprocessen fungerat bra och är väl anpassad för gruppen. Samtliga gruppmedlemmar hade hög närvaro på både morgonmötena och veckomötena. Arbetspro-cessen har gett medlemmarna tydlig koll på resterande gruppens aktiviteter, problem och frågeställningar. När gruppen inte heller kan träffas fysiskt anser gruppmedlemmarna att ar-betsprocessen hjälpt med sammanhållningen och gett en “vi”-känsla trots omständigheterna. Dock har gruppen haft vissa problem med kontinuerlig användning av verktyget Trello un-der perioun-der med stora uppgifter utan tydliga sätt att bryta ner dem. Målsättningen har trots detta lyckats då uppdelningar av aktiviteter utförts på schemalagda möten.

5.4

Systemanatomi

Mot slutet av projektets förstudiefas skapades en systemanatomi. För att generera anatomin delade vi in systemet i skikt, det översta skiket var systemets tjänster, under det finner man användargränsnittet följt av serverns funktioner och till sist ett kommunikationsskikt. Syste-manatomin ses i figur 5.2.

Figur 5.2: Systemanatomi

5.5

Översikt över individuella bidrag

5.5. Översikt över individuella bidrag

5.5.1

Adina Andersson - Specialisering inom team, effektiviserande eller

sammanhållningsdödare?

I dagens arbetsklimat sker specialiseringar inom samtliga yrkesgrupper men hur påverkar specialisering ett team som började på tillsammans på liknande grunder? Målet med texten var att utforska huruvida specialisering inom mindre gruppers effektivitet och sammanhåll-ning påverkas när gruppen splittras i mindre, specialiserade team. Vinner alla eller förlorar gruppen?

5.5.2

Albin Dunby - Virtual Realitys roll som hjälpmedel i byggbranschen

Det är inte alltid lätt att förstå hur en ritning ska tolkas speciellt om man inte är insatt. Även om man är insatt så kan ritningar på papper vara tvetydiga om det inte gjorts på rätt sätt. Något som ser bra ut på ritning ser inte alltid lika bra ut i verkligheten. Kan Virtual Reality lösa dessa problem?

5.5.3

Leon Ericsson - Koordination av kandidatgrupp på distans som teamledare

Att arbeta på distans är helt annorlunda från det studenter är vana vid och det sätter högre krav än vanligt på en kandidatgrupps medlemmar. Hur kan teamledare anpassa sig efter den här omställning för att fortfarande lyckas genomföra ett kandidatarbete på hög nivå och vilka erfarenheter kan dras från vår upplevelse?

5.5.4

Pontus Jönrup - En beskrivande fallstudie av kandidatarbetet med stort

engagemang från kund

Kandidatarbetet är någonting som många studenter i Mjukvaruteknik- och Datatekniska ut-bildningar gör innan de tar examen. En sak som inte är lika vanlig är att företaget i fråga hyrde in konsulter som hjälp till gruppen vilket leder till syftet med studien, att lyfta de skill-nader som kan uppstå med möjligheten till direkt feedback.

5.5.5

Ludvig Erlander Klein - Iterativ utveckling och dess för- och nackdelar

Iterativ utveckling har i teorin många fördelar, och en del nackdelar, men hur ser det faktiskt ut i praktiken? Projektet som denna rapport behandlar genomfördes med en version av en iterativ arbetsprocess, och denna fallstudie ska undersöka hur denna arbetsprocess imple-menterades och vilka teoretiska fördelar och nackdelar som kunde observeras i projektet i praktiken.

5.5.6

Samuel Knutsson - Hur kan Azure DevOps underlätta ett

mjukvaruutvecklingsprojekt?

Vid start av ett mjukvarutvecklingsprojekt är det många beslut som ska tas. Ett av dessa beslut som till stor del kan forma projektets arbetsprocess är val av plattform. Under detta projekt användes Azure DevOps och därmed besvaras frågan: Vad gör Azure DevOps till en populär plattform för mjukvaruutveckling?

5.5.7

Hampus Rosenquist - Användaridentifiering med hjälp av Javascript

Webbläsare lämnar spår som en webbserver kan välja att analysera, vilket bildar ett digitalt fingeravtryck. Javascript medför en väsentlig ökning av dessa spår, men hur mycket? Samt hur sannolikt är det att användaren kan identifieras? Kan användaren vidta åtgärder för att minska denna sannolikhet?