Digitalt verktyg för kollaborativ idégenerering

Digitalt verktyg för kollaborativ idégenerering

Jämförelse mellan klassisk webbprogrammering och implementering mot molnplattform

Moa Nygård

VT2021 DT099G Datateknik GR (C), Examensarbete 15 hp

Huvudområde: Datateknik

Poäng: 15 hp

Termin/År: 6, 2021

Handledare: Magnus Eriksson

Examinator: Patrik Österberg

Utbildningsprogram: Civilingenjör i datateknik 300 hp

Digitalt verktyg för kollaborativ idégenerering – Jämförelse mellan

klassisk webbprogrammering och implementering mot molnplattform

Moa Nygård 2021-08-27

Based on the Mid Sweden University template for technical reports, written by Magnus Eriksson, Kenneth Berg and Mårten Sjöström.

ii

Sammanfattning Den här studien har genomförts i samarbete med Statens tjänste-

pensionsverk (SPV). Myndigheten hanterar tjänstepensioner för de som

är, eller har varit, statligt anställda. Studiens syfte var att utveckla ett

användbart hjälpmedel för kollaborativ idégenerering samt att jämföra

en implementation med traditionell webbprogrammering mot att skapa

ett tillägg till en molnplattform. Metoder som användes i projektet var

intervjuer med medarbetare på myndigheten, utveckling av en webb-

sida med HTML, CSS, JavaScript och PHP och utveckling av ett tillägg

mot en molnplattform. Den framtagna prototypen av idégenererings-

verktyget testades i två omgångar med användbarhetstest. Resultatet

visar att den framtagna prototypen ur ett användbarhetsperspektiv

lyckades med målet att vara enkel att komma i gång med och lätt att

använda. Viss förbättringspotential fanns med ännu tydligare beskriv-

ningar och att säkra upp att användaren inte ska kunna använda

verktyget fel. Under projektet uppkom det även svårigheter att imple-

mentera mot molnplattformen då kommunikationen med databasen

inte lyckades implementeras. Så slutsatsen är att det kan vara enklare att

programmera med mer traditionell webbprogrammering för en ut-

vecklare som inte är van vid molnplattformen. Däremot kan det vara

mer effektivt för ett företag att integrera applikationen mot en redan

befintlig plattform för att kunna samla data på en plats.

Nyckelord: Människa-dator-interaktion, JavaScript, HTML, molntjänst,

webbprogrammering, Brainstorming, idégenerering.





iii

Abstract This study has been carried out in collaboration with Statens tjänste-

pensionsverk (The National Government Employee Pensions Board,

SPV). The government agency handles occupational pensions for those

who is, or has been, a government employee. The purpose of this study

was to develop a useful tool for collaborative idea generation and

compare an implementation with traditional web programming against

developing an extension for a cloud platform. The methods used in the

project were interviews with employees at the company, development

of a web page with HTML, CSS, JavaScript and PHP and development

of an extension for a cloud platform. The idea generation prototype

developed was tested in two usability tests. The result shows that the

produced prototype reached the goal of being simple to use and easy to

get started with seen from a usability perspective. There was also some

potential for improvement with even clearer descriptions and less risk

for the user to use the tool incorrectly. During the project some difficul-

ties with developing against the cloud platform occurred leading to the

database communication not being implemented. The conclusion is that

it can be easier to program with more traditional web programming for

a developer who is not used to the cloud platform. However, for a

company it can be more effective to integrate the application to an

already existing platform to be able to save data in one place.

Keywords: Human-computer interaction, cloud computing, web

programming, Brainstorming, idea generation.





iv

Förord Så var det då dags att slutföra min andra kandidatuppsats för det här

året.

Jag vill återigen passa på att tacka medarbetarna på SPV för deras

hjälpsamhet. Framför allt vill jag rikta ett tack till Jonas Christiansson,

Kristina Pellkvist och Linda Johansson Bäck från utvecklings-

avdelningen för bra stöd och intressanta samtal. Även ett tack till Tomas

Hellström som ställt upp och svarat på de frågor jag haft under arbetets

gång. Er uppmuntran och positiva attityd har varit väldigt uppskattad.

Jag vill även rikta ett tack till Magnus Eriksson, handledare på Mittuni-

versitetet, som funnits med under hela projektet och kommit med goda

råd och lugnat mig då jag känt att jag inte haft läget under kontroll.

Slutligen så vill jag uttrycka min uppskattning till min familj som stått

ut med mig under våren/sommaren och som alltid finns där och stöttar.

Moa Nygård

2021-08-27





v

Innehåll

Sammanfattning .............................................................................................. ii

Abstract ............................................................................................................ iii

Förord ............................................................................................................... iv

Terminologi .................................................................................................... vii

Förkortningar och akronymer ...................................................................... vii

1 Inledning ................................................................................................. 9

1.1 Bakgrund och problemmotivering ................................................... 9

1.2 Om SPV .............................................................................................. 10

1.3 Övergripande syfte ........................................................................... 10

1.4 Avgränsningar ................................................................................... 10

1.5 Konkreta och verifierbara mål ........................................................ 10

1.6 Översikt .............................................................................................. 11

2 Teori ........................................................................................................ 12

2.1 Övergripande om innovation .......................................................... 12

2.2 Metoder för idégenerering ............................................................... 12

2.2.1 Brainstorming 13

2.2.2 Brainwriting 13

2.2.3 Analogier 14

2.2.4 Mindmapping 14

2.2.5 Sex tänkande hattar 15

2.2.6 S.C.A.M.P.E.R 16

2.2.7 Tvärtom brainstorming 16

2.3 Molntjänster ....................................................................................... 17

2.3.1 Servicemodeller 17

2.3.2 Distributionsmodeller 18

2.4 Microsoft Azure................................................................................. 19

2.4.1 Azure DevOps 19

2.5 Personuppgiftsbehandling .............................................................. 19

2.6 Schrems I och II ................................................................................. 20

2.7 Asynchronous JavaScript and XML (AJAX) ................................. 21

2.8 Användbarhetsmål ........................................................................... 22

2.9 Designprinciper ................................................................................. 22

2.10 Fallbeskrivning .................................................................................. 23

3 Metod ...................................................................................................... 25

3.1 Förstudie ............................................................................................. 25





vi

3.1.1 Litteraturgenomgång 25

3.1.2 Intervju 25

3.2 Konstruktionsmetod ......................................................................... 26

3.2.1 Val av implementeringsmetod traditionell programmering 26

3.2.2 Val av molnplattform 27

3.3 Datainsamling .................................................................................... 27

3.3.1 Användbarhetstester 27

4 Konstruktion ......................................................................................... 29

4.1 Kravspecifikation .............................................................................. 29

4.2 Traditionell webbprogrammering .................................................. 30

4.2.1 Databas traditionell webbprogrammering 37

4.3 Utveckling av tillägg till molnplattform ........................................ 38

4.4 Ändringar gjorda till följd av användbarhetstest ......................... 40

4.5 Framtida utvecklingsbehov ............................................................. 42

5 Resultat .................................................................................................. 43

5.1 Användbarhetstester ........................................................................ 43

5.1.1 Första användbarhetstestet 43

5.1.2 Andra användbarhetstestet 44

5.2 Prototyp .............................................................................................. 44

5.3 Jämförelse traditionell programmering och molnplattform ....... 46

5.4 Fördelar och nackdelar med konstruktionsmetoderna ............... 48

6 Diskussion ............................................................................................. 49

6.1 Rekommendationer till företaget .................................................... 51

6.2 Förslag till fortsatt forskning ........................................................... 51

6.3 Etiska och samhälleliga aspekter .................................................... 51

Källförteckning .............................................................................................. 53

Bilaga A ............................................................................................................ 57

Intervjuunderlag ............................................................................................ 57

Bilaga B ............................................................................................................ 59

Prototyp från Marvel App ............................................................................ 59

Bilaga C ............................................................................................................ 62

Underlag för användbarhetstest .................................................................. 62





vii

Terminologi

Förkortningar och akronymer

AJAX Asynchronous JavaScript and XML. En samling av webbut-

vecklingstekniker på klient-sidan för att skapa asynkrona

webbapplikationer.

CSS Cascade Style Sheet. Språk för presentation av innehåll på

webben med hjälp av stilmallar.

DOM Document Object Model. En modell av en HTML sida som

skapas av webbläsaren.

EU/EES Europeiska unionen/Europeiska ekonomiska samarbets-

området.

GDPR General Data Protection Regulation. Dataskyddsför-

ordningen. Reglerar behandlingen av personuppgifter och

flödet av dessa inom EU.

HTML HyperText Markup Language. Ett märkspråk för hypertext

som används på webben.

IaaS Infrastructure as a Service. Servicemodell inom området

molntjänster där infrastruktur tillhandahålls som en tjänst.

IT Informationsteknologi. Ett gemensamt begrepp för tekniska

möjligheter som skapats genom framsteg inom datorteknik

och telekommunikation.

JS JavaScript. Skriptspråk som används för att skapa dynamiskt

innehåll för webben.

JSON JavaScript Object Notation. Textbaserat format för att utbyta

data.

On-prem. On-premises. IT-system som körs på en bestämd hårdvara

och plats. Motsats till molnet.





viii

PaaS Platform as a Service. Servicemodell inom området moln-

tjänster där en datorplattform och programvarusystem till-

handahålls som en tjänst.

PHP Hypertext preprocessor. Skriptspråk som kan användas på

webbservrar för att hantera dynamiskt innehåll på webben.

SaaS Software as a Service. Servicemodell inom området moln-

tjänster där en datorplattform och programvarusystem till-

handahålls som en tjänst.

SDK Software Development Kit. Uppsättning verktyg som

möjliggör för utveckling mot exempelvis en molnplattform.

SQL Structured Query Language, standardiserat programspråk för

att hantera och kommunicera med relationsdatabaser.

URL Uniform Resource Locator. Teckensträng som identifierar en

resurs på internet. Webbadress.

XAMPP Apache, MariaDB, PHP, Perl. Öppen programvara (eng.

open-source) för plattform till webbserverlösningar. Bestå-

ende av Apache http server, MariaDB databas och är kompa-

tibel med bland annat PHP.

XMLHttpRequest JavaScript objekt som utför asynkron kommunikation med

servern.





9

1 Inledning Detta kapitel introducerar rapportens bakgrund och ger en problem-

motivering i kapitel 1.1. En kort beskrivning av företaget som arbetet

utförs i samarbete med följer sedan i kapitel 1.2. Arbetets övergripande

syfte och avgränsningar presenteras i 1.3 respektive 1.4. I kapitel 1.5

definieras konkreta mål för projektet med stöd av fyra delmål. Slutligen

ges en översikt till resterande delar av rapporten i kapitel 1.6.

1.1 Bakgrund och problemmotivering

Innovation har kommit att bli en allt viktigare faktor för att behålla

konkurrenskraften på en alltmer global marknad [1]. I en verksamhet är

det därför viktigt att hela tiden utvecklas och förbättra sig för att nå upp

till sina kunders förväntningar. Offentlig sektor är inget undantag, utan

de behöver också arbeta med innovation för att kunna uppfylla sina

uppdrag och utvecklas [2]. På Statens tjänstepensionsverk (SPV) arbetar

de för att få innovation som en naturlig del av myndighetens verksam-

het. I en innovationsprocess är idéer och idégenerering en viktig del. Det

är vid detta stadie nya innovationer föds. För att öka kreativiteten och

generera förslag på förbättringar eller nya produkter finns det olika

metoder som kan användas under idégenereringsprocessen. Tradition-

ellt har sådana metoder nyttjats under fysiska workshopar där en grupp

medarbetare träffas och tar fram idéer med stöd av metoderna. Vid

dessa möten har post-it-lappar, whiteboardtavlor och vanligt papper

ofta används för att skriva upp uppkomna idéer och förslag. Men i

dagens digitala samhälle är det inte alltid medarbetare sitter på samma

ort och arbetar eller, som under covid-19 pandemin som pågick då

denna rapport skrevs, att människor arbetar hemifrån i stor ut-

sträckning. Detta leder till att fysiska träffar inte kan ske och därför

uppkommer ett behov av att kunna utföra idégenerering på distans och

därmed digitalt.

I dag är det vanligt att myndigheter och företag såväl som enskilda

personer använder sig av molntjänster (eng. cloud computing). Moln-

tjänster innebär att till exempel databaslagring, servrar och delning av

material kan ske via en leverantör som tillhandahåller dessa tjänster

över internet [3]. Gartner förutspår att utgifterna från slutanvändare för

molntjänster kommer att öka med 18 % under år 2021 delvis som en





10

följd av covid-19 och ökad digitalisering i samhället [4]. Då ett digitalt

verktyg ska utvecklas för webben finns det därför möjlighet att utveckla

det mot en molnplattform. Men frågan är om det i fallet med ett digitalt

verktyg för idégenerering är molntjänster som är bästa alternativet, eller

om det är bättre att skapa en fristående webbsida med traditionell

webbprogrammering. Den här studien undersöker just den frågan.

1.2 Om SPV

SPV hanterar och arbetar med tjänstepension för alla som är eller har

varit anställda inom statlig verksamhet. De har över 1 100 000 kunder

och är en av Sveriges största leverantörer av pensionstjänster. Deras

kontor ligger i Sundsvall och där arbetar cirka 250 anställda [5].

1.3 Övergripande syfte

Syftet med projektet är att framarbeta ett användbart, tekniskt hjälp-

medel i form av digitaliserade metoder för idégenerering som kan

användas på till exempel workshops. Vidare är syftet att ge kunskap om

hur utvecklingen för detta skiljer sig åt mellan traditionell webb-

programmering och att utveckla mot en molnplattform.

1.4 Avgränsningar

Ursprungligen var målet att implementera två till tre olika metoder,

men på grund av projektets begränsade tid implementerades endast en

metod i slutändan. Verktyget saknar även stöd för realtidsuppdatering

för flera användare, utan uppdateras endast för en enskild person eller

vid omladdning av webbsidan. Slutligen har inloggningen för den

traditionella sidan ingen kryptering för lösenord. Detta uteslöts då det

inte har någon inverkan på själva användbarheten av verktyget och då

implementeringen mot molnplattform vilar på molnplattsformens egna

konton och därför inte blir likvärdiga att jämföra.

1.5 Konkreta och verifierbara mål

Målet med projektet var att utveckla och utvärdera en användbar

webbapplikation för idégenerering som kan stötta verksamheter i deras

innovationsarbete. Undersökningen hade vidare som mål att jämföra

vilket av implementationerna traditionell webbprogrammering eller

programmering mot molnplattform som lämpar sig bäst för implemen-

tering av ett sådant verktyg. För att konkretisera målet definierades

följande fyra delmål:





11

M1: Hur ska ett verktyg för idégenerering skapas för att tillföra värde

inom organisationen? Ta fram en prototyp och konceptuell beskrivning

av produkten utifrån en kravlista som framarbetas i samråd med

anställda på företaget.

M2: Hur användbart är verktyget och i vilken mån förväntas det tillföra

värde till företaget?

M3: Jämförelse mellan att programmera en fristående webbsida eller

mot en molnplattform sett till komplexitet (antal kodrader), tidsåtgång

för implementation och hur tillgänglig information och hjälp det finns

att hitta som stöd vid utvecklingen.

M4: Vilka för och nackdelar identifierades med att utveckla mot en

molnplattform kontra en fristående webbsida med traditionell webb-

programmering? Sammanställning av för- och nackdelar i tabellform.

1.6 Översikt

Kommande delar av rapporten disponeras enligt följande: Kapitel 2

beskriver de teorier och forskning som är viktigt för att få en djupare

förståelse för resterande av rapporten. I kapitel 3 presenteras metoder

som använts för datainsamling och konstruktion. Kapitel 4 redogör för

konstruktionen av webbapplikationen dels som fristående applikation,

dels som en integration till en molnplattform. Kapitlet fördjupar sig i

tekniska detaljer kopplat till utvecklingen. Resultat från användbarhets-

tester, jämförelse av implementationsmetoderna och dess för- och

nackdelar presenteras i kapitel 5. Slutligen återfinns ett diskussions-

kapitel i kapitel 6 där resultat och metod diskuteras tillsammans med

rekommendationer till företaget och etiska överväganden samt att

förslag till vidare forskning föreslås.





12

2 Teori Kapitlet behandlar teori som ligger till grund för arbetet. Inledningsvis i

kapitel 2.1 ges en kort introduktion till begreppet innovation följt av en

redogörelse för några olika idégenereringsmetoder i kapitel 2.2. Därefter

följer en introduktion till molntjänster generellt i kapitel 2.3 och Micro-

soft Azure specifikt i kapitel 2.4. I kapitel 2.5-2.6 diskuteras personupp-

giftsbehandling och datasäkerhet kopplat till Schrems I och Schrems II.

Vidare i kapitel 2.7 presenteras AJAX följt av användbarhetsmål och

principer i kapitel 2.8-2.9. Slutligen ges en fallbeskrivning av SPV där en

mer detaljerad nulägesbeskrivning av företagets aktuella arbetssätt

presenteras i kapitel 2.10.

2.1 Övergripande om innovation

Nationalencyklepedin [6] definierar innovation som ”förlopp genom

vilket nya idéer, beteenden och tillvägagångssätt vinner insteg i ett

samhälle och sedan sprids där.”

Inom innovationsprocessen kan idéhantering (eng. idea management) ses

som en delprocess som ska arbeta för effektiv idégenerering samt

utvärdering och urval av dessa. Idéhantering tillhandahåller idéerna

som är själva stommen i innovationsprocessen och kan även öka kreati-

viteten hos medarbetarna. Några viktiga faktorer för att lyckas i

idéhanteringsfasen som belyses av Gerlach och Brem [7] är bland annat

att gärna bygga vidare på redan befintliga idéer och även att det är

viktigt för anställda att träna på att generera idéer för att öka dess

kvalitet. De lyfter även vikten av att samarbeta med andra och

inspireras av varandra internt [7].

Det är viktigt att tänka på att innovationsprocessen aldrig är starkare än

sin svagaste länk. En redan från början dålig idé kommer fortfarande

vara dålig hur väl den än implementeras. Även avsaknad av pengar, tid

och IT-infrastruktur bedöms kunna vara ett hinder för innovations-

arbete inom offentlig sektor [8].

2.2 Metoder för idégenerering

Olika metoder för idégenerering kan användas för att erhålla lösningar

på problem och generera förslag på nya produkter eller arbetsmetoder.





13

Att dela med sig av idéer i grupper är vanligt förekommande i

organisationer, men är inte alltid optimalt på grund av vissa sociala

faktorer som kan ha en negativ inverkan på processen. Vid

brainstorming i grupp finns risk för produktivitetsblockering (eng.

production blocking) eftersom endast en person kan tala åt gången, det

kan finnas tendenser till att lyssna mer på och påverkas av grupp-

deltagare med hög status eller expertis och en del personer kan vara

rädda för att bli kritiserade då de framför sina idéer och hålls därför

tillbaka. För att förbättra idégenereringsprocessen kan fokus vara på

utmanade mål, återkoppling och kvantitet, men utan risk för att

bedömas negativt av andra deltagare. Storleken på gruppen kan även

spela in där det vid muntliga idégenereringstillfällen inte bör delta för

många deltagare för att alla ska kunna komma till tals. Det får heller inte

vara för få deltagare så att det saknas tillräckligt med expertis i gruppen

vilket leder till att små grupper ibland anses vara mindre innovativa.

Att använda elektroniska och skriftliga metoder har visat sig fungera

bra för idégenerering i grupp [9].

Nedan följer en genomgång av ett antal olika idégenereringsmetoder.

2.2.1 Brainstorming

En vanlig metod som ofta används i olika situationer är Brainstorming.

Då samlas en grupp människor för att tillsammans komma på många

förslag på lösningar till ett fördefinierat problem. Brainstorming genom-

förs traditionellt muntligt med en facilitator som antecknar de idéer som

kommer fram. Metoden utvecklades av Alex F. Osborn och bygger

ursprungligen på fyra regler som lyder:

• Förslagen ska inte kritiseras, varken av dig själv eller andra.

• Satsa på stor kvantitet av idéer snarare än kvalitet.

• Deltagarna uppmuntras att bygga vidare på varandras idéer.

• Vilda och överdrivna idéer uppmuntras.

Reglerna är till för att öka kreativiteten i gruppen och för att deltagarna

inte ska bli hämmade. Tanken är att deltagarna ska bli stimulerade av

att höra varandras idéer och därför är det viktigt med ett tillåtande

klimat för att alla ska våga framföra sina förslag [10].

2.2.2 Brainwriting

Definiera ett problemområde och låt sedan alla deltagare arbeta enskilt

med att ta fram så många idéer som möjligt. Idéerna i Brainwriting





14

antecknas av respektive deltagare. Kvantiteten är viktigare än kvaliteten

i detta fall så idéerna behöver inte vara färdigutvecklade. Detta steg

pågår i ungefär 10-15 minuter. Låt därefter deltagarna skicka vidare sina

idéer till en annan person och bygg vidare på varandras förslag i

ungefär tio minuter. Detta kan sedan upprepas tills alla har byggt vidare

på varandras idéer. I slutet kommer idéerna ha hunnit bli relativt

genomarbetade då flera personer tillsammans har bidragit till idéerna

och på så sätt kunnat vidareutveckla dem [11].

2.2.3 Analogier

Denna metod kan användas för idégenerering men även för att vidare-

utveckla ett förslag som redan är framtaget. Övningen handlar om att se

på ett problem eller en idé utifrån olika metaforer eller analogier. Syftet

med metaforerna och analogierna är att öppna tänkandet för nya

kreativa tankar. Olika ”perspektivkort” behövs som under övningen

presenteras för deltagarna. Det finns oändligt med metaforer eller

analogier att använda, endast fantasin sätter gränserna. Några exempel

kan vara:

• Tidsresan: hur skulle problemet lösas om det fanns oändligt

mycket eller lite med tid?

• En DNA molekyl: består av flera sammanflätade spiraler vilket

kanske kan beskriva dellösningar som tillsammans kan bilda en

helhet.

Som facilitator för övningen gäller det att byta metafor eller analogi då

idéerna börjar sina för att bibehålla kreativiteten i gruppen [10].

2.2.4 Mindmapping

Metoden utgår från ett problemområde eller en fråga som ska lösas.

Denna fråga placeras centralt och därefter börjar brainstormingen. Olika

lösningar eller koncept som kan associeras till grundfrågan kopplas

samman till ursprungsproblemet så som Figur 2.1 visar. Metoden ger en

grafisk översikt av resultatet från övningen. I metoden kan även bilder

ritas snarare än att bara använda text för de associerade elementen.

Mindmapping kan användas för att visualisera kopplingar mellan

koncept och idéer och fungerar att använda både i grupp och enskilt

[12].





15

Figur 2.1 Exempel på mindmap. (Egen illustration).

2.2.5 Sex tänkande hattar

Edward De Bonos sex tänkande hattar (eng. Six thinking hats) är en

ytterligare metod som kan användas för att öka kreativiteten i en grupp

och för att ta fram välgrundade förslag. Tanken är att deltagarna ska ”ta

på sig” olika hattar under sessionen. De olika hattarna står för olika

perspektiv att se på problemet eller lösningen med. Syftet med övningen

är bland annat att tänka igenom problem på ett systematiskt sätt, skapa

kreativa och resultatorienterade möten samt tänka bortom de uppen-

bara lösningarna.

Figur 2.2 De sex tänkande hattarna. (Egen illustration).

Varje hatt har en egen betydelse vilket visas i Figur 2.2, där en hatt

betyder att du ska vara så positiv som möjligt och bara se möjligheterna

i idén medan en annan hatt ska tvärtom bara tänka på eventuella

problem, och en tredje hatt ska se på problemet ur ett känsloperspektiv.

Under övningen kan deltagarna turas om att bära de olika hattarna och

undertiden diskutera idéer och lösningar som framkommit utifrån

respektive perspektiv [10].





16

2.2.6 S.C.A.M.P.E.R

Metoden är framtagen av Bob Eberle på 1970-talet och utgår från sju

olika frågor som används under en brainstorming-session.

S.C.A.M.P.E.R är en förkortning för:

Ersätta (eng. substitute) – Finns det något som kan bytas ut eller ändras

i produkten/processen/tjänsten/problemet? Antingen helt eller delvis.

Kombinera (eng. combine) – Finns det möjligheter att kombinera en

eller flera delar av produkten?

Anpassa (eng. adapt) – På vilket sätt kan produkten anpassas för att bli

mer effektiv eller flexibel? Till exempel genom att addera något eller

förändra något.

Modifiera (eng. modify) – Kan du förändra produkten eller problemet

på något sätt för att få ett bättre resultat?

Annat användande (eng. put to another use) – Kan produkten användas

för något annat ändamål eller användas på ett annorlunda sätt?

Eliminera (eng. eliminate) – Finns det något som kan tas bort eller för-

enklas?

Tvärtom (eng. reverse) – Finns det en möjlighet att arrangera om

komponenter på något sätt för att få bättre resultat?

Under en session gås alla de olika bokstäverna igenom i turordning för

att deltagarna ska se problemet ur flera olika perspektiv. Målet är att få

deltagarna att förstå problemet på ett nytt sätt och därmed kunna

komma på nya innovativa lösningar. Metoden kan fungera bra även på

problem där stiltje har uppstått i arbetet med att lösa dem och kan även

kombineras med Brainwriting som beskrevs i kapitel 2.2.2 [13].

2.2.7 Tvärtom brainstorming

I Tvärtom brainstorming (eng. Reverse Brainstorming) så identifieras ett

problem och i stället för att försöka hitta lösningar till det ska deltagarna

försöka hitta faktorer som kan orsaka problemet eller som gör det värre.

Då olika idéer på hur problemet kan uppkomma har samlats in så är

nästa steg att försöka lösa de nya problemen. Då de nya problemen har

blivit lösta ska gruppen utvärdera lösningarna och på så sätt försöka

hitta en lösning till det ursprungliga problemet. Människor har ofta





17

lättare att hitta problem än lösningar vilket utnyttjas med den här

metoden [14].

2.3 Molntjänster

I någon form kan uttrycket molntjänster härledas till då datorsystem

tidsdelade (eng. time-shared) datorresurser och applikationer och är

alltså inget som dykt upp över en natt. Uttrycket molntjänst myntades

som en beskrivning av vad som händer när applikationer och tjänster

flyttas till internet ”molnet”. Idag finns det ett stort utbud av tjänster

och applikationer som erbjuds via molnet på olika molnplattformar och

i många fall är det enda som krävs en enhet med internetuppkoppling

för att komma åt molntjänsterna [15]. Figur 2.3 visar sambandet mellan

en molntjänst och de enheter som är kopplade till denna. Genom

molntjänsten så kan databaser, servrar och personhanterade enheter till

exempel datorer och smarttelefoner kommunicera med varandra.

Figur 2.3 Olika sorters enheter kan interagera med varandra genom molntjänsten då

alla är kopplade till internet. (Egen illustration).

2.3.1 Servicemodeller

Det finns olika servicemodeller för hur molntjänster kan distribueras

beroende på affärsmodell och vilka krav som ställs. Dessa illustreras i

Figur 2.4 och presenteras mer djupgående nedan:





18

Figur 2.4 Olika typer av servicemodeller. Källa: Egen illustration inspirerad av [15].

• Mjukvara som en tjänst (eng. Software as a Service, SaaS), inne-

bär att verksamheten betalar för att få tillgång till en applikation

eller tjänst som tillhandahålls via molnet [15].

• Plattform som en tjänst (eng. Platform as a Service, PaaS), ger

verksamheten tillgång till en plattform som möjliggör att de kan

distribuera egna mjukvaruprogram och applikationer i molnet. I

detta fall tillhandahålls operativsystem och nätverk via leveran-

tören och det kan även finnas begräsningar i vilka applikationer

som kan distribueras [15].

• Infrastruktur som en tjänst (eng. Infrastructure as a Service,

IaaS), i denna modell hanterar verksamheten allt ifrån operativ-

system och applikationer till lagring, men leverantören ansvarar

för själva infrastrukturen för molnet [15].

2.3.2 Distributionsmodeller

Utöver de olika servicemodellerna som presenterades ovan i kapitel

2.3.1 så finns det olika distributionsmodeller som är anpassade för olika

krav från verksamheten.

• Privat moln (eng. Private Cloud), ett moln som distribueras och

underhålls hos ett specifikt företag eller verksamhet. Driften kan

ske internt eller med tredje part on-prem. vilket betyder att det

körs på en bestämd hårdvara och plats [15].





19

• Samhällsmoln (eng. Community Cloud), delas av flera olika

verksamheter som har gemensamma intressen. Driften kan även

här ske internt eller med tredje part. Fördelarna med ett samhälls-

moln är att flera aktörer kan dela på kostnaderna för molnet [15].

• Publikt moln (eng. Public Cloud), är tillgängligt för alla via en

molntjänstleverantör. Det medför att användare med enkla medel

kan utveckla och distribuera molntjänster för en låg kostnad jäm-

fört med många andra distribueringsalternativ [15].

• Hybridmoln (eng. Hybrid Cloud), är en blandning av olika moln-

typer som integrerats för att kunna flytta data mellan ingående

moln. Hybridmoln kan användas inom en verksamhet för att be-

hålla vissa data internt i det privata molnet samtidigt som tjänster

erbjuds via ett publikt moln [15].

2.4 Microsoft Azure

Azure är en molnplattform som tillhandahålls av Microsoft med över

200 produkter och molntjänster [16]. Sett till den totala spenderingen på

molntjänster i världen innehar Microsoft Azure 19% av marknaden i

april 2021. Och Azure växer hela tiden. Det senaste kvartalet meddelade

de en inkomstökning med 50% enligt Stalcup [17].

2.4.1 Azure DevOps

DevOps är ett verktyg för planering och utveckling och är en av de

tjänster som finns tillgänglig via Microsoft Azure. Azure DevOps

tillhandahåller bland annat tavlor (eng. boards) för planering, lagrings-

platser (eng. repos) för filhantering och lagring av utvecklingsprojekt och

pipelines för kontinuerlig integration och för till exempel versions-

hantering [18]. Azure DevOps kan köras både i molnet via Azure

DevOps Services och on-prem. Som Azure DevOps Server [19].

2.5 Personuppgiftsbehandling

Vid behandling av personuppgifter finns det reglerat hur dessa ska

hanteras i dataskyddsförordningen (GDPR). De grundläggande prin-

ciper som ska gälla vid behandling av personuppgifter är bland annat:

• Det måste finnas stöd i dataskyddsförordningen för att få be-

handla personuppgifter.





20

• Personuppgifter får endast samlas in för specifika och berättigade

ändamål, och inte fler uppgifter än nödvändigt får samlas in.

• När personuppgifterna inte längre behövs ska dessa raderas.

• Personuppgifterna ska skyddas så att de inte försvinner eller att

obehöriga får tillgång till dem.

Verksamheter måste därför se till att åtgärder som brandväggar, krypte-

ring och anti-virusskydd finns för att skydda personuppgifterna som

hanteras. Även organisatoriska säkerhetsåtgärder i form av interna

rutiner och riktlinjer för hantering av personuppgifter behöver ses över

[20].

Myndigheter är skyldiga att följa fler regelverk då de hanterar person-

uppgifter i sin verksamhet. Främst GDPR, särskild registerförfattning

och den kompletterade dataskyddslagen (kompletterar EU:s data-

skyddsförordning) [21].

Om personuppgifter blir tillgängliga i ett land som ligger utanför

EU/EES-området kallas det för överföring till tredje land. Att lagra

personuppgifter i en molntjänst, eller en server som är baserad i ett land

utanför EU/EES innebär en överföring till tredje land. Eftersom länder

utanför EU/EES-området inte behöver följa dataskyddsförordningen så

finns ingen garanti att personuppgifterna och den personliga integrite-

ten skyddas i samma utsträckning som inom EU/EES. Därför regleras

överföringen av data till dessa länder i dataskyddsförordningen [22].

2.6 Schrems I och II

Tidigare fanns ett avtal som kallades ”Safe Harbour” som gjorde det

möjligt att föra över data över atlanten mellan Europa och USA. Men

efter ett mål i EU-domstolen efter en anmälan gjord av advokaten och

aktivisten Maximilian Schrems slog domstolen fast att avtalet var

ogiltig. Domen kom att kallas Schrems I och grundar sig på att företag i

Europa inte har rätt att överföra personuppgifter till USA då deras

massövervakningssystem står i strid med EU:s datalagar [23].

Senare efter Schrems I domen kom ett nytt handelsavtal ”Privacy

Shield” som ersatte det tidigare. Företag i USA kunde då anmäla sig om

de uppfyllde kraven i avtalet. Något som Maximilian Schrems ansåg

vara i princip likadant som det första avtalet. På grund av Schrems

stoppades även detta avtal då det inte ansågs ge ett tillräckligt bra





21

skydd för personuppgifter då dessa överförs till USA. Denna dom kom

att benämnas som Schrems II. Domen meddelades av EU-domstolen så

sent som i juli 2020 och det är därför inte helt klart vilka konsekvenser

den kommer att få [23]. I dagsläget finns inga liknande avtal att tillgå.

2.7 Asynchronous JavaScript and XML (AJAX)

Ibland är det önskvärt att kunna läsa eller skicka data mellan en webb-

sida och en server efter att en sida är laddad utan att behöva uppdatera

den igen. Detta kan åstadkommas genom AJAX [24]. För att skicka

förfrågningar till servern använder AJAX sig av ett inbyggt objekt vid

namn XMLHttpRequest som webbsidan skickar till servern. Servern

skickar sedan ett svar som webbläsaren med hjälp av JavaScript (JS) och

document object model (DOM) kan visa på sidan utan att behöva ladda

om den. Flödet illustreras i Figur 2.5.

Figur 2.5 Processen för ett AJAX anrop. Källa: [24].

AJAX kan användas för att skapa interaktiva webbsidor, men fungerar

inte fristående utan måste kombineras med andra tekniker. JS-

funktioner används för att hantera händelser på en webbsida. Denna

kan då utföra ett AJAX-anrop. Därefter kan XMLHttpRequest-objektet

interagera asynkront med servern. Slutligen utnyttjas DOM, som är ett

API för att kunna manipulera HTML-sidan, för att kunna presentera och

ändra webbsidan då servern har skickat ett svar [25].





22

2.8 Användbarhetsmål

Sharp et al. [26] presenterar sex delmål för att uppnå användbarhet i en

produkt. Genom att sikta på att uppfylla dessa mål säkerställs det att

interaktionen med en produkt är enkel att lära sig, effektiv att använda

och därmed blir trevlig att använda för användarna. Nedan introduce-

ras de sex delmålen med en kortfattad förklaring:

Effektivitet (eng. effectivness) – Gör systemet det den är avsedd att

göra?

Produktivitet (eng. efficency) – Hur snabbt kan användaren utföra sina

uppgifter då användaren väl lärt sig att använda produkten?

Säkerhet (eng. safety) – Finns det säkerhetsåtgärder som förhindrar att

användaren gör fel och hamnar i oönskade situationer?

Nytta (eng. utility) – Finns de funktioner som behövs för att användaren

ska kunna uppfylla sitt mål? Är produkten funktionell?

Lärbarhet (eng. learnability) – Är produkten utformad på ett sätt som

gör att det går att lära sig att använda den bara genom att testa sig fram?

Minnesvärdhet (eng. memorability) – Hur lätt är det att minnas pro-

duktens utformning och funktioner mellan gångerna som den används?

2.9 Designprinciper

För att bistå interaktionsdesigners i framtagandet av produkter för en

god användarupplevelse finns det vissa designprinciper som bör följas.

Följande designprinciper är framtagna för att designern ska tänka på

olika aspekter vid designandet av gränssnittet. Principerna bygger på en

blandning av teoretisk kunskap, erfarenhet och sunt förnuft enligt Sharp

et al. [26].

Synlighet (eng. visibility) – Gör gränssnittet det tydligt för användaren

vilka funktioner som ska användas? Är dessa tillräckligt synliga för att

användaren ska hitta dem enkelt?

Återkoppling (eng. feedback) – Ges relevant återkoppling för att hjälpa

användaren att interagera med produkten? Återkoppling kan ske

verbalt, taktilt, visuellt auditivt eller en kombination av dessa.





23

Begränsningar (eng. constraints) – Finns det begräsningar som gör att

användaren förstår vid vilka situationer som olika funktioner kan/ska

eller inte kan/ska användas?

Konsekventhet (eng. consistency) – Är gränssnittet konsekvent utformat

så att användarna förstår hur olika objekt ska hanteras och att dessa

hanteras likadant i hela gränssnittet?

Affordans (eng. affordance) – Är det tydligt för användaren hur olika

objekt ska hanteras i gränssnittet? Finns det ledtrådar i utformningen

som vittnat om hur interaktionen med objektet ska gå till?

2.10 Fallbeskrivning

SPV har de senaste åren börjat arbeta mer strukturellt med innovation

inom verksamheten. Utvecklingsavdelningen har det största ansvaret

för arbetet och avdelningen har funnits i ca två år. I dagsläget finns inte

några fastställda rutiner för innovationsarbetet. De har en innovations-

process som de löst utgår ifrån som visas i Figur 2.6. SPV har som

interna mål att långsiktigt ha nöjda och trygga kunder och att arbeta

effektivt och hållbart. För att bli mer effektiva önskar de undersöka

möjligheten till att effektivisera sin innovationsprocess.

Figur 2.6 Målbild för innovationsprocessen på SPV. Källa: [27].

Eftersom alla anställda inom företaget har placering i Sundsvall har det

(tidigare) inte funnits något behov av digitala verktyg som stöd vid till

exempel workshops. De har i stället kunna boka in ett fysiskt möte där

post-it-lappar, papper och whiteboardtavlor har varit de hjälpmedel

som använts. Nu under covid-19 pandemin har däremot de anställda i

den mån det är möjligt ombetts att arbeta hemifrån, vilket leder till ett





24

nytt behov av digitala stöd. Även efter pandemin förväntas hemarbete

bli mer vanligt än tidigare enligt SPV:s generaldirektör Maria Humla.

Enligt medarbetare på utvecklingsavdelningen så saknar SPV i dagslä-

get digitala verktyg som stöd i idégenereringsprocessen.

På SPV används plattformen Microsoft Azure DevOps för planering och

utveckling inom vissa delar av verksamheten. Microsoft Azure är i

grund och botten en molntjänst men SPV kör den on-prem. på servrar i

Sverige då de är en myndighet och behöver hålla sina data inom

Europa. Så av datasäkerhetsskäl använder de det inte som en molntjänst

i dess kanske mer vanliga bemärkelse.





25

3 Metod I följande kapitel redogörs det för de metoder som använts under

projektets gång. Inledningsvis presenteras de ingående moment som

genomfördes under projektets förstudie i kapitel 3.1. Därefter redogörs

det för hur konstruktionsarbetet gått till i kapitel 3.2. Slutligen presente-

ras de metoder för datainsamling som användes i projektet i kapitel 3.3.

3.1 Förstudie

3.1.1 Litteraturgenomgång

Projektet inleddes med en litteraturgenomgång som genomfördes för att

få en bredare teoretisk grund att stå på. Bland annat användes data-

baserna Primo och Google Scholar för att hitta forskningsrapporter och

vetenskapliga artiklar. Även böcker inom ämnet innovation och idé-

generering lästes. Vissa källor som beskriver metoder för idégenerering,

webbprogrammering och molntjänster är webbsidor på internet och

dessa hittades genom sökmotorn Google. Från den inledande litteratur-

genomgången erhölls olika metoder att använda vid idégenerering där

tre av metoderna senare bedömdes mest lämpade för att implementeras

digitalt. Metoderna valdes med utgångspunkt i att de ska vara smidiga

att använda digitalt, flexibla och att de inte skulle vara för lika varandra

utan alla ska bidra med något unikt till metodpoolen. Utifrån metoderna

som presenterades i kapitel 2.2 valdes Brainstorming, Brainwriting och

Analogier ut som metoder till det digitala idégenereringsverktyget som

skapades i projektet. Enligt Michinov [28] så ledde Brainstorming som

genomfördes elektroniskt till fler förslag och färre redundanta idéer än

fysisk Brainwriting. Detta tyder på ett ökat fokus på redan uppkomna

idéer då deltagarna kan se varandras förslag i realtid på en skärm [28].

Dessa insikter gjorde att Brainstorming var den metod som till slut

implanterades i projektet, då tidsbrist gjorde att endast en metod skulle

hinnas med och då prioriterades elektronisk Brainstorming.

3.1.2 Intervju

I förstudiefasen hölls även möten med anställda på SPV och en intervju

via Skype med tre av medarbetarna på utvecklingsavdelningen, för att

författaren skulle kunna bilda sig en bättre uppfattning om behovet av

digitalt stöd samt att få en inblick i verksamheten. Intervjuunderlaget

som användes vid intervjun finns presenterat i Bilaga A. I intervjun





26

framkom det att myndigheten i dagsläget saknar digitala verktyg som

stöd till innovation och idégenerering samt att det finns ett behov för

det.

3.2 Konstruktionsmetod

Under själva konstruktionsfasen skedde arbetet agilt med åter-

kommande möten med representanter från myndigheten som agerade

användare. Det övergripande tillvägagångssättet visas i Figur 3.1.

Utvecklingen började med att ta fram en kravlista efter samtal med

fallföretaget. Kravlistan utformades med stöd av ”user stories”. Ett

exempel på en sådan är:

Som en deltagare vill jag kunna flytta runt/gruppera förslag för att få en

tydligare överblick.

Därefter designades en interaktiv prototyp i Marvel App [29] som är ett

webbaserat prototypverktyg. Den första prototypen återfinns i Bilaga B.

Figur 3.1 Projektets genomförande under konstruktionsfasen. (Egen illustration).

Med inspiration från den framtagna prototypen utvecklades därefter

webbsidan med traditionell webbprogrammering. Denna färdigställdes

helt och testades därefter med ett första användbarhetstest. Utifrån

testresultatet gjordes lite förändringar av gränssnittet vilket resulterade i

den slutgiltiga prototypen, som även den genomgick ett användbarhets-

test. Därefter började implementationen mot molnplattformen. Eftersom

utseendet för de båda implementationerna ser exakt likadana ut så

testades endast ena implementationen med användarna. En utförligare

beskrivning av konstruktionsarbetet finns att läsa i kapitel 4.

3.2.1 Val av implementeringsmetod traditionell programmering

För den dynamiska webbsidan som konstruerades med traditionell

webbprogrammering användes HTML, CSS och JS för front end. Kom-

munikationen med databasen skedde med hjälp av PHP. För back end





27

är PHP fortfarande ett vanligt språk. Enligt W3Tech [30] använder ca

79% av alla de webbsidor vars programmeringsspråk på serversidan är

känt sig av PHP. Bland annat WordPress och Wikipedia är programme-

rade med PHP [30]. Valet av dessa språk kan även ses som ett bekväm-

lighetsval då författaren själv har en del förkunskaper i dessa språk. På

grund av projektets tidsplan var det därför lämpligt att inte utgå från ett

helt nytt programmeringsspråk och på så vis undvika ytterligare

inlärningstid.

3.2.2 Val av molnplattform

Största anledningen till att valet föll på Microsoft Azure är för att

fallföretaget i sin verksamhet använder Azure DevOps och på så vis

hade det varit fördelaktigt att utveckla webbapplikationen mot ett på

SPV redan befintligt verktyg. Men som diskuteras i kapitel 2.4 så är det

även en av de största molntjänstleverantörerna och de växer fortfarande

vilket gör det aktuellt att utveckla mot just den molnplattformen.

Språken som användes för utvecklingen mot molnplattform var även

här HTML, CSS och JS.

3.3 Datainsamling

Den färdiga prototypen som tagits fram under projektet utvärderades

genom användbarhetstester för att kunna svara på problem M1 och M2.

För de andra delmålen M3 och M4 utvärderades mer tekniska detaljer

sett till de olika implementationsmetoderna. Så som hur lätt eller svårt

det varit att utveckla med traditionell webbprogrammering respektive

mot molnplattformen, hur komplex koden blev sett till antal kodrader

och hur lång tid utvecklingen tagit. Resultaten sammanställdes och

återfinns i kapitel 5.3.

3.3.1 Användbarhetstester

Vid de två användbarhetstesterna som genomfördes så deltog fem

personer vid varje test, vilket enligt Nielsen [31] är tillräckligt för att få

fram de flesta insikterna. Därefter kommer många av de kommande

observationerna vara upprepningar från tidigare test och de nya insikter

som framkommer är inte värt mödan av att anordna fler tester [31].

Deltagarna var mellan 19–58 år och ingen av dem hade tidigare sett

webbapplikationen som testades. Olika personer deltog vid de olika

testen för att de helt skulle sakna vana av att använda hemsidan då

kriterierna bland annat handlade om hur enkel de ansåg att hemsidan

var att använda.





28

För utvärderingen av användbarhetskriterier i problem M2 används de

kriterier som presenterades i kapitel 2.8. Eftersom huvudfokus för

idégenereringsverktyget var att det skulle vara användbart så valdes det

att genomföra kvalitativa användbarhetstester. Under användbarhets-

testerna fick deltagarna instruktioner av testledaren om olika uppgifter

de skulle genomföra. Efter att alla uppgifter var utförda fick deltagarna

svara på några korta frågor för att utvärdera deras upplevelse kopplat

till några av de viktigaste användarupplevelsemålen som var:

• Lärbarhet

• Effektivitet/Produktivitet

• Enkel att använda och lätt att förstå

I Bilaga C återfinns det mer detaljerade underlaget som användes för

testerna inklusive de avslutande frågorna som ställdes.

Användbarhetstesterna genomfördes digitalt, via Skype och ett över

Zoom, på grund av den rådande covid-19 pandemin. Deltagarna fick

fjärrstyra testledarens dator eftersom webbsidan återfanns lokalt på

dennes localhost. Detta gjorde att det inte gick att se exakt hur del-

tagarna agerade då de skrev på tangentbordet men det som iakttogs var

hur väl de navigerade på webbsidan samt att det var möjligt att se deras

ansiktsuttryck någorlunda tydligt. Resultatet från användbarhets-

testerna presenteras i kapitel 5.1.





29

4 Konstruktion I följande kapitel presenteras konstruktionen som utförts i projektet. I

kapitel 4.1 redovisas den kravspecifikation som legat till grund för

implementeringen. Därefter följer en presentation av respektive imple-

menteringsmetod i kapitel 4.2 och kapitel 4.3. Vidare i kapitel 4.4

beskrivs de ändringar som gjorts i prototypen efter första användbar-

hetstestet. Avslutningsvis diskuteras framtida behov till utveckling i

kapitel 4.5.

I projektet utvecklades två separata webbapplikationer, ena som en

fristående webbsida med traditionell webbprogrammering och den

andra utvecklades som ett tillägg (eng. extension) till molnplattformen

Microsoft Azure DevOps. Kravspecifikationen för det digitala verktyget

var gemensam för de båda implementationsmetoderna likaså var även

designen. Detta kunde åstadkommas genom att använda gemensam

CSS och samma typer av HTML-element på de två webbplatserna.

4.1 Kravspecifikation

Inför utvecklingen av webbapplikationen och för att kunna besvara

fråga M1 togs en kravspecifikation fram i samråd med medarbetare på

SPV. Kravspecifikationen är gemensam för de båda implementationerna

som gjordes i projektet. De krav som framkom presenteras i Tabell 4.1.





30

Tabell 4.1 Kravlista för det digitala idégenereringsverktyget.

Funktionskrav Prioritet (Skall/Bör/Trevligt att ha)

Skriva nya idéer Skall

Se andras idéer Skall

Kunna gruppera idéer Skall

Ha tillgång till en timer i metoderna Skall

Få information om hur övningen går till Skall

Kunna betygsätta idéer Bör

Kunna spara resultatet efter att övningen

är genomförd

Bör

Kunna välja och ändra en bild till min

avatar

Trevligt att ha

För implementationen togs även tre användbarhetsmål fram och dessa

var:

• Applikationen ska vara enkel att använda och komma i gång

med.

• Den ska vara lätt att förstå.

• Den ska kännas kreativ.

Dessa användbarhetsmål har funnits i åtanke då applikationen ut-

vecklades tillsammans med de användbarhetsmål och designprinciper

som presenterades i kapitel 2.8–2.9.

4.2 Traditionell webbprogrammering

För den traditionella webbprogrammeringen användes XAMPP för att

få tillgång till en Apache server och en MySQL-databas. Objekt-

orienterad PHP, vilket är ett språk som är kompatibelt med XAMPP,

användes i projektet.

För den fristående webbsidan skapades en enkel ”logga in”-sida och

möjligheten att skapa en användare. Då användaren besöker webb-

platsen är det första användaren ser inloggningsrutan som visas i Figur

4.1.





31

Figur 4.1 Inloggningssida för idégenereringsverktyget för webbsidan skapad med

traditionell webbprogrammering.

Om användaren saknar inloggningsuppgifter kan en ny användare

skapas i formuläret som visas i Figur 4.2. I denna applikation kopplas

användaren mot en organisation och kommer således endast kunna se

idéer framtagna av andra personer inom samma organisation. Då

användaren klickar på registrera kommer formulärets värden skickas

med metoden POST för att parametrarna inte ska skickas synliga i URL-

adressen.

Figur 4.2 Formulär för att skapa en ny användare.





32

Då användaren har loggat in landar de på en startsida där de olika

idégenereringsmetoderna presenteras i en meny med bilder. Överst på

sidan hälsas även användaren välkommen där användarnamnet hämtas

från databasen med hjälp av PHP-kod.

Figur 4.3 Huvudmeny för idégenereringsverktyget.

Då användaren klickar på någon av metoderna dyker rutan som visas i

Figur 4.4 upp. Där finns en beskrivning till hur metoden går till och

användaren har även möjlighet att skriva in rubriken till dagens ämne

för idégenereringen och en mer detaljerad beskrivning till ämnet om så

önskas.

Figur 4.4 För att starta en metod fyller användaren först i formuläret om

samtalsämne som ska beröras under idégenereringen.





33

Ämnet och beskrivningen skickas då formuläret skickas in och hanteras

av ett PHP-script som lagrar ämne och beskrivning i databasen via ett

objekt av klassen ”method”. Då användaren startar vald idé-

genereringsmetod skickas denne till nästa sida som är Brainstorming i

det här fallet. Layouten för brainstorming-sidan illustreras i Figur 4.5.

Figur 4.5 Layout för Brainstormingsidan. (Egen illustration).

Användaren skriver in sina idéer i inmatningsfältet längst ner till

vänster på sidan. Då idén skickas hanterar PHP den inmatade texten

och uppdaterar databasen genom att skapa ett nytt objekt av klassen

”idea”. Idén visas därefter i rutan för alla inkomna idéer tillsammans

med andra idéer som inkommit under pågående session.

Figur 4.6 PHP-kod som kontrollerar och hanterar inkomna idéer om dessa finns.

Då användaren klickar på submit-knappen för sin idé så hanteras

formuläret på den aktuella sidan genom ett PHP-script som övervakar

om knappen ”sendIdea” har blivit klickad på. Om så är fallet kommer

scriptet i Figur 4.6 se om någon idé har angivits och i så fall använda

värdet från formuläret för att lagra en ny idé i databasen. Figur 4.7





34

illustrerar hur verktyget ser ut då ett par idéer har publicerats under

Brainstomingövningen. Mina egna idéer visas till vänster i rutan och har

en raderaknapp kopplad till sig som gör att idéer kan raderas från

databasen efter att de har skapats. I det högra fältet visas istället alla

inkomna idéer, både mina egna och andras, i tidsföljd.

Figur 4.7 Skärmdump av Brainstormingsidan då idéer har sparats.

Då idégenereringen är färdig kan användaren gå vidare till gruppe-

ringssteget genom att klicka på knappen ”Börja gruppera” uppe i högra

hörnet. Då landar användaren på sidan som visas i Figur 4.8.

Figur 4.8 Grupperingssidan innan några kategorier har angetts.





35

Det är därefter användarna som väljer kategorier som kan användas

som rubrik då inkomna idéer ska grupperas. I Figur 4.9 visas ett ex-

empel på hur grupperingssidan ser ut då en kategori har lagts till.

Figur 4.9 Grupperingssida med en tillagd kategori.

Vid skapandet av kategorier används ”Asynchronous JavaScript and

XML” (AJAX) som gör att sidan kan uppdateras utan att hela sidan

behöver laddas om. Genom att skapa ett nytt XMLHttpRequest-objekt

som i exemplet i Figur 4.10 så kan objektet kommunicera asynkront med

servern och således uppdatera berörda delar av sidan.

Figur 4.10 Exempel på en funktion som använder AJAX.

Då en eller flera kategorier har skapats är nästa steg att gruppera

idéerna utifrån dessa. På grupperingssidan så görs idéerna flyttbara





36

genom att HTML-elementets ”draggable”-attribut sätts till true för

idéerna. Användaren skapar kategorier där idéerna kan släppas för att

sortera idéerna. Då en ny kategori läggs till definieras en ”onDrop()”-

funktion som hanterar vad som händer då ett objekt släpps inom

området. I detta fall kommer den nyligen flyttade idén att kopplas ihop

med kategorin i databasen. Som standard har idéerna ett nullvärde för

attributet ”category” vid skapandet, men då idén släpps på en kategori i

detta steg ändras ”category”-värdet till aktuell kategoris id.

Figur 4.11 Flödesschema för dra-och-släpp för idéer då de ska grupperas.

Idéerna kan flyttas runt mellan kategorierna hur som helst. Flödet för

dra-och-släpp funktionen visas i Figur 4.11. Om användaren raderar en

kategori som har idéer kopplade till sig kommer dessa att åter hamna i

”Inkomna förslag”-fältet. I databasen återställs även ”category” till dess

nullvärde. I Figur 4.12 visas det hur sidan för gruppering ser ut då några

idéer har blivit grupperade.





37

Figur 4.12 Ögonblicksbild från sidan för gruppering av idéer.

4.2.1 Databas traditionell webbprogrammering

I Figur 4.13 visas ett UML-diagram över projektets databas och entite-

ternas inbördes relationer till varandra.

Figur 4.13 UML-diagram över relationsdatabasen för den traditionella

webbprogrammeringen.

Databasen som används i projektet för den traditionella webbprogram-

meringen består av fyra entiteter. ”Users”, ”method”, ”category” och

”idea”. ”Method” skapades för att kunna hålla isär idéer för olika

idégenereringsmetoder. Då slutligen endast en metod implementerades

så hade inte denna entitet behövts. Men den möjliggör att fler metoder

kan läggas till i framtiden. ”Users” hanterar användarna som skapas på





38

webbplatsen och ser till att rätt person endast får tillgång det de är

behöriga för och inte hela databasen. Syftet med webbapplikationen är

att skapa nya idéer och dessa lagras i entiteten ”idea”. Attributet ”ra-

ting” används inte i nuläget men skapades då tanken från början var att

hinna implementera ett röstningssystem för idéer. Slutligen finns

entiteten ”category” som används då användarna grupperar idéer i

kategorier. Vid gruppering kommer idéerna få en koppling till den

kategori som de blir tilldelade, men som standard har dessa ett null-

värde och är således inledningsvis okategoriserade.

4.3 Utveckling av tillägg till molnplattform

För att göra den andra implementationen skapades först ett gratiskonto

på Microsoft för att bli ägare till en egen organisation. Tillägget testades

på denna organisations Azure-tavlor sida. Utvecklingen skedde i Visual

Studio 2019. För att utveckla ett tillägg behöver även nodeJS installeras

på datorn. Slutligen krävs ett ”extension packaging tool” (TFX) som

installerades med hjälp av kommandotolken och kommandot [32]:

npm install -g tfx-cli

Då applikationen i det här fallet utvecklas som ett tillägg mot molnplatt-

formen Azure DevOps krävs en JSON manifestfil. I manifestet beskrivs

grundläggande information om tillägget till exempel vilka filer som

används av manifestet och vem som publicerat den och vilka bidrag

som tillägget gör. En del av denna information visas sedan på Market-

place där ägare av organisationer kan installera tillägget till DevOps

[32].

Då applikationens filer är skapade paketeras dessa i en .vsix-fil som

därefter kan laddas upp och publiceras på Marketplace. I projektet

behölls tillägget privat men delades med den organisationen som

skapades för projektet. Därefter kunde sedan tillägget laddas ner till

organisationens Azure DevOps. Figur 4.14 visar hur menyraden ser ut i

Azure DevOps och där Idea är tillägget som skapats och laddats ner

under projektet.





39

Figur 4.14 Menyrad i Azure DevOps med det installerade tillägget ”Idea” installerat.

Visuellt så är applikationen identisk med den tidigare presenterade

versionen skapad med traditionell webbprogrammering. Däremot visar

Figur 4.15 hur det ser ut för tillägget då applikationen är integrerad i

Azure DevOps. Längst högerkanten syns menyn från DevOps och även

längs övre delen tillkommer element från Azure.

Figur 4.15 Projektets tillägg som körs från Azure DevOps.

Sett till funktionaliteten för utvecklingen mot molnplattformen så

används ingen egen inloggning som i den första implementationen.

Utan i det här fallet använder användarna den vanliga inloggningen till

Azure DevOps. På startsidan där användaren hälsas välkommen med

namn så nyttjas ett mjukvaruutvecklings kit (eng. Software Development

Kit, SDK) som möjliggör kommunikation med molnplattformen och att





40

få tillgång till innehåll från den aktuella sidan. I detta fall användes

kommandot:

VSS.getWebContext().user.name;

För att kunna hälsa användaren välkommen med rätt användarnamn.

Samma princip används även vid skapandet av idéer där samma

kommando används för att namnge vems idé det var.

I projektet önskades kunna kommunicera med databasen från Azure

men efter mycket försök så lyckades detta fortfarande inte. Så i stället

skapades en lösning där idéerna sparades med hjälp av SessionStorage

och därav endast fanns tillgänglig för aktuell session och så länge

sessionen varade. Med andra ord så lagras inkomna idéer inte i Azure

DevOps vilket medför att det inte är möjligt för flera personer att se

samma inkomna idéer. I prototypen är det därför endast möjligt att en

ensam person genomför idégenereringen och efter sessionen avslutats

så kommer resultatet inte finnas kvar längre.

4.4 Ändringar gjorda till följd av användbarhetstest

Efter att det första användbarhetstestet genomförts framkom en del

otydligheter som påverkade användbarheten för idégenererings-

verktyget. Därför gjordes en del mindre ändringar av designen efter

detta test. Området för de gemensamma idéerna utökades till att om-

fatta 50% av sidan som i Figur 4.16 visar. Jämfört med tidigare som visas

i Figur 4.17 då området var mycket mindre och de egna idéernas om-

råde tog upp mest yta. Förändringen gjordes för att ge mer utrymme åt

användarna att ta inspiration av varandras idéer.





41

Figur 4.16 Uppdaterad idégenereringsyta där gemensamma idéer tar större plats.

Figur 4.17 Ursprunglig idégenereringsyta med fokus på egna idéer.

Vid ett av användbarhetstesten försökte deltagaren att skriva in en ny

idé direkt efter att den föregående skickats i väg. Det var vid det tillfället

inte möjligt då användaren först blev tvungen att klicka i formuläret för

att det skulle återfå fokus på sidan. Därför gjordes en ändring så att

formuläret automatiskt hade fokus då sidan laddades genom att an-

vända attributet ”autofokus” på det aktuella HTML-elementet. Det är

däremot inte möjligt att använda samma attribut på Azure tilläggets

implementering då det är blockerat på grund av att webbapplikationen





42

finns integrerad som en del av Azures vanliga sida. Figur 4.18 visar det

felmeddelande som framkom då autofokus försökte implementeras. På

grund av detta skiljer sig sidorna en aning mellan de olika implemente-

ringarna.

Figur 4.18 Felmeddelande då autofokus försökte implementeras på Azure DevOps

tillägget.

I övrigt var det endast förtydligande ”placeholder”-texter som infördes för att

det skulle bli tydligare för användarna att veta vart de skulle skriva in sina

idéer och vad de olika formulären skulle innehålla. Ett exempel på text som

infördes är ”Skriv din idé här…” som visas i Figur 4.19.

Figur 4.19 Uppdaterad version av inmatningsfältet med inkluderad hjälptext.

4.5 Framtida utvecklingsbehov

Den framtagna prototypen har en del förbättringspotential som på

grund av begränsad tid inte har hunnits med under projektets gång.

Främst handlar det om att implementera stöd för uppdatering i realtid

då flera användare använder verktyget samtidigt. En del kvarstående

brister sett till användbarheten och enkelheten att förstå verktyget finns

också, bland annat hade det varit önskvärt att applikationen gav tips till

användaren ifall användaren försöker använda verktyget på fel sätt och

att det tydligare skulle framkomma vad som förväntas av användaren i

varje steg samt att det skulle varit enklare att hitta till ”Gruppera

knappen”. Även möjligheten att spara ner resultatet av Brainstormingen

saknas i aktuell prototyp. Som tidigare nämnts lyckades inte implemen-

teringen mot Azure DevOps att få åtkomst till databasen för molnplatt-

formen vilket såklart är ett problem som behöver lösas i en eventuell

framtida utveckling av prototypen. Slutligen har prototypen en del

estetisk förbättringspotential för att göra den mer fin att titta på och

förhoppningsvis kännas mer kreativ. För konstruktionen riktad mot

Azure DevOps skulle mer fördelar kunna uppnås genom att utnyttja de

befintliga team och grupper som användarorganisationen redan har på

DevOps. Till exempel skulle det kunna vara möjligt att direkt skapa nya

uppgifter på Azure-tavlor utifrån de behov som framkommit under

idégenereringen.





43

5 Resultat I detta kapitel presenteras de resultat som framkommit under projektet.

I kapitel 5.1 presenteras resultaten från de genomförda användbarhets-

testerna. Därefter redogörs det för de funktioner som återfinns i den

framtagna prototypen i kapitel 5.2. Slutligen återfinns en jämförelse

mellan de olika implementationsmetoderna samt att deras för- och

nackdelar presenteras i kapitel 5.3-5.4.

5.1 Användbarhetstester

Under projektets gång genomfördes två användbarhetstester på den

sidan som togs fram med klassisk webbprogrammering. Användaren

fick uppgifter att utföra på hemsidan under testet och efteråt svarade

deltagarna på några frågor rörande deras upplevelse av det digitala

verktyget. Frågorna ställdes muntligt av testledaren och återfinns i

Bilaga C. Resultatet från dessa presenteras nedan i Tabell 5.1 och Tabell

5.2. I skalan 1-5 motsvaras 1 av svår/inte effektiv medan 5 är en-

kel/effektiv beroende på frågans utformning.

5.1.1 Första användbarhetstestet

Tabell 5.1 Resultat från första användbarhetstestet.

Användbarhetstest 1

Fråga P1 P2 P3 P4 P5 Snitt Kommentar

Enkelhet att

använda

4 4 4 4 4 4,0 (Lagg vid användbarhets-

test) Försökte skriva idéer

under beskrivning

Lära sig verktyget 3 5 3 5 5 4,2 Ingen hjälp till inlärning.

Instruktioner saknas.

Förstå knappar,

formulärlayout

3 4 3 5 3 3,6 Gruppera, högst upp till

höger svårt att hitta, förslag:

meny. Svårt att förstå att det

ska skrivas i formuläret

Effektivitet 5 5 5 5 4 4,8 Enkelt, effektivt





44

Behov som identifierats utifrån återkopplingen från deltagarna samt

från de iakttagelser som gjordes under användbarhetstestet:

• Göra att fokus direkt hamnar i skrivrutan vid start och efter att en

idé har skickats.

• Förifylld text “Skriv din idé här” i formulär där idéer ska fyllas i.

• Döp knappen till ”Starta” i stället för ”Spara” efter att samtals-

ämne och beskrivning fyllts i och det är dags att starta sessionen.

• Gör det möjligt att ändra rubrik på kategoriseringen.

• Instruktionstext/varningstext då de försöker flytta idéer redan på

Brainstormingsidan

• Tydliggöra knappen gruppera, alternativt hur man kan gruppera

direkt på Brainstormingsidan.

• Mer plats för alla idéer i stället för att största delen ska vara mina

egna idéer.

5.1.2 Andra användbarhetstestet

Tabell 5.2 Resultat från andra användbarhetstestet.

Användbarhetstest 2

Fråga P6 P7 P8 P9 P10 Snitt Kommentar

Enkelhet att

använda

5 5 4 4 4 4,4

Lära sig verktyget 4 5 4 5 4 4,4

Förstå knappar,

formulärlayout

5 5 4 4 3 4,2

Effektivitet 5 5 5 5 4 4,8

5.2 Prototyp

De funktioner som finns implementerade i respektive prototyp finns

sammanfattade i Tabell 5.3.





45

Tabell 5.3 Funktioner som finns tillgänglig i den framtagna prototypen.

Funktion Traditionell Molnplattform

Skapa ny användare ✓ -

Logga in ✓ -

Välja Brainstorming ✓ ✓

Fylla i samtalsämne och

beskrivning ✓ ✓

Skriva nya idéer ✓ ✓

Timer ✓ -

Se sina tidigare idéer ✓ ✓

Radera sina idéer ✓ ✓

Se alla idéer från personer

från företaget. ✓ ✓

Skapa kategorier för

gruppering. ✓ ✓

Radera kategorier för

gruppering. ✓ ✓

Gruppera inkomna idéer i

kategorier. ✓ ✓

Flytta idéerna mellan olika

kategorier. ✓ ✓

Det motsvarar inte alla de krav som togs fram i kravlistan. Nedan i

Tabell 5.4 ges en genomgång av status för varje krav från krav-

specifikationen i kapitel 4.1 med kommentarer.





46

Tabell 5.4 Sammanställning av implementerade funktioner jämfört med

kravspecifikationen.

Funktionskrav Prioritet

(Skall/Bör/

Trevligt

att ha)

Implementerat? Kommentar

Skriva nya idéer Skall Ja

Se andras idéer Skall Ja I praktiken saknas funktion-

aliteten för att det ska

fungera med flera användare.

Kunna gruppera

idéer

Skall Ja

Ha tillgång till en

timer i metoderna

Skall Ja och nej Visuellt finns en timer på en

av implementationerna men

den har begränsad funktion-

alitet.

Få information om

hur övningen går till

Skall Ja och nej En övergripande beskrivning

finns då metoden väljs. Men

under genomförandet saknas

vidare information.

Kunna betygsätta

idéer

Bör Nej Förberett i databasen för

traditionell webb-

programmering men inte

implementerat.

Kunna spara

resultatet efter att

övningen är genom-

förd

Bör Nej

Kunna välja och

ändra en bild till min

avatar

Trevligt att

ha

Nej Inte aktuellt för Azure

DevOps då molnplattfor-

mens användarprofiler

används.

5.3 Jämförelse traditionell programmering och molnplattform

För de olika konstruktionerna användes samma språk i form av HTML,

CSS och JS. Konstruktionerna hade i stort sett gemensam HTML- och





47

CSS-kod. Nedan följer en jämförelse av de punkter som svarar för M3 av

projektets uppsatta mål.

Tid för förberedelse och installation av programvaror:

Traditionell: 0,5 timmar

Molnplattform: 0,5 timmar

Tiden räknas från nedladdning av programvaror till att en enkel ”hello

world” webbsida kunnat publiceras. I fallet med traditionell webb-

programmering kördes webbsidan lokalt på localhost. För moln-

plattformen hade ett tillägg publicerats och laddats ner till Azure

DevOps på organisationen som skapats för projektet. Det fanns en

tydlig steg-för-stegguide att följa genom Microsofts egna dokument för

att publicera sitt första tillägg, vilket gjorde att det gick relativt snabbt

att komma i gång.

Tid för utveckling:

Traditionell: 35,5 timmar

Molnplattform: 37,5 timmar

Aningen mer tid spenderades på implementationen för moln-

plattformen. Notera att tiden då innebär att kommunikationen med

databasen fortfarande inte fungerar efter 37,5 timmar. Då moln-

plattformens konstruktion genomfördes efter den traditionella gick

mindre tid åt att fundera över designen och funktionaliteten i den andra

konstruktionen. Uppskattningsvis tjänades ca 5-8 timmar in tack vare att

designen redan var färdig då tillägget mot molnplattformen implemen-

terades.

Komplexitet i form av antal kodrader:

Traditionell: ≈ 830 rader (1020 inkl. inloggning)

Molnplattform: ≈ 820 rader (965 inkl. molnplattform specifika filer)

Beroende på vad som inkluderas skiljer sig antalet kodrader något

mellan de olika konstruktionerna. Sett till endast funktionaliteten

krävdes ca 830 egenskrivna rader för den traditionella varianten medan

molnplattformen krävde ca 820. Däremot hade molnplattformens

konstruktion ca 965 rader om automatgenererade filer samt manifestet





48

inkluderades. För den traditionella sidan tillkom ytterligare rader om

hänsyn tas till att en separat inloggning krävdes, då är antalet ca 1020.

Möjlighet till hjälp och stöd vid utveckling:

Traditionell: Mycket, olika källor

Molnplattform: Endast Microsoft egna

För utvecklingen mot molnplattformen fanns mest Microsofts egna

guider att tillgå. Dessa var ibland förenklade och svåra att följa som

nybörjare. Guiderna innehåller i regel endast de enklaste exemplen

vilket gör det svårt att gå vidare med mer avancerad programmering.

Däremot i den traditionella webbprogrammeringen så fanns det väldigt

många olika källor att hämta information från. Flertalet foruminlägg,

bloggar och guider var behjälpliga i utvecklingen av den traditionella

webbprogrammeringssidan.

5.4 Fördelar och nackdelar med konstruktionsmetoderna

Under konstruktionsarbetet framkom både en del fördelar och nack-

delar med respektive konstruktionsmetod vilka presenteras i Tabell 5.5

Tabell 5.5 Sammanställning av för- och nackdelar med de två implementations-

metoderna som använts i projektet.

Traditionell Molnplattform

Fö

rdel

ar

+ Mycket hjälp på internet.

+ Möjlighet att kontrollera hela databasen

själv.

+ Möjlighet att samla idéer i ett redan befintligt

verktyg.

+ Kunna utnyttja befintliga team och använ-

darprofiler.

+ Slippa underhåll av databaser.

Nac

kd

elar

- Behöver ett eget system för användare

och inloggningar med mera.

- Behov av en egen server och databas.

- Svårt att lära sig hur data kan lagras vid

utveckling av tillägg till molnplattformen.

- Inte så utförliga guider från Microsoft.

- Vissa begränsningar till exempel att

autofokus inte kunde användas och att det var

svårt som nybörjare att kommunicera med

databasen.





49

6 Diskussion I det avslutande kapitlet diskuteras resultatet kopplat till projektets syfte

och mål. Rekommendationer till fallföretaget återfinns i kapitel 6.1.

Därefter ges förslag på fortsatt forskning i kapitel 6.2 och avslutningsvis

diskuteras etiska och samhälleliga aspekter i kapitel 6.3.

Syftet med projektet var att utveckla ett användbart tekniskt hjälpmedel

för idégenerering samt att göra en jämförelse mellan att implementera

detta med traditionell webbprogrammering mot att skapa den mot en

molnplattform. Projektet har resulterat i en prototyp av ett digitalt

idégenereringsverktyg som har utvärderats med användbarhetstester.

Vidare har en sammanställning av jämförelser mellan de två implemen-

tationsmetoder som användes gjorts.

Som svar på M1 och M2 finns den prototyp som presenterades i kapitel

4. I användbarhetstesterna framkom det även att de medarbetare som

deltog från SPV ansåg att verktyget var användbart för idégenerering.

Prototypen uppnådde även målet om att vara enkelt att förstå. Däremot

hade vissa tillägg kunnat göra att användbarheten ökade ytterligare då

främst genom att bättre guida användaren under tiden själva genomfö-

randet av idégenereringen. Designprincipen om begränsningar skulle ha

kunnat följas bättre till exempel genom att visuellt visa att användaren

inte kan flytta idéer på sidan för Brainstorming. Målet kan inte sägas

vara helt uppnått då en av prototyperna inte lyckades med att intera-

gera med molnplattformens databas för lagring. Därav kan inte denna

prototyp ses som helt färdig.

Något som kan ha påverkat användbarhetstesterna var att deltagarna

inte fick möjlighet att testa verktyget i samarbete med andra. Om detta

hade genomförts hade det troligtvis varit enklare för deltagarna att

förstå varför processen med idégenereringen är uppbyggd så som den

är. Detta kan ha bidragit till att vissa av deltagarna hade lite svårigheter

med att förstå att de behövde klicka på ”Börja gruppera” för att avsluta

själva idégenereringssteget innan de kunde sortera idéerna. En annan

aspekt att ha i åtanke då det handlar om användbarhetstesten är att det

kan vara osäkert att dra för starka slutsatser kring kvantitativa data från

endast 5-10 personer. Det verkade förekomma olika personlighetstyper

där några av deltagarna var mer benägna att lägga sig någonstans i





50

mitten av skalan medan andra deltagare tenderade att mer använda

ytterligheter. Då det var olika deltagare vid de två olika användbarhets-

testen så kan detta ses som en möjlig felkälla.

På delmål M3 och M4 framkom det en del skillnader samt för- och

nackdelar mellan de olika implementationsmetoderna. Av de resultat

som framkommit i arbetet med de två implementationerna så kan

slutsatsen dras att det verkar vara mer komplicerat att utveckla mot en

molnplattform än fristående webbsida då utvecklaren inte är van vid

aktuell molnplattform sedan tidigare. Det visade sig vara svårare att lära

sig att utveckla tillägg mot molnplattformen än att programmera

fristående med traditionell webbprogrammering. Svårigheterna låg

främst i att dokumentationen var mindre utförlig och att det fanns

mindre extern hjälp att hitta för utveckling mot molnplattformen. En

anledning kan vara att den traditionella webbprogrammeringen har

funnits längre och att den har ett bredare användningsområde. För

utvecklingen mot molnplattform kan det tänkas att det mestadels är

Microsofts egna anställda som utvecklar tillägg vilket medför att de

redan har kunskap om att programmera mot plattformen. Om inte

annat kan de enkelt hitta den kunskapen inom organisationen. Då kan

det vara svårare som utomstående att hitta någon med expertis inom

området då det inte är lika vanligt som den traditionella webb-

programmeringen. Så som utvecklare var det enklare att använda

traditionell programmering i detta projekt. En fördel däremot, ifall

utvecklingen mot molnplattformen hade fungerat i projektet, är att

utvecklaren slipper hantera databasen och tillhandahålla en server att

driva webbsidan på, då denna kan köras direkt i molnplattformen. Med

tanke på att tillägget hade en bristfällig databas som inte utnyttjade

molnplattformen så är det även svårt att dra några slutsatser av antalet

kodrader som krävdes för de två implementeringarna.

För företagets del så är den största vinningen i att ha applikationen

integrerad i den befintliga molntjänsten att de har möjlighet att samla

idéer i ett verktyg som redan är i användning inom företaget. Däremot i

fallföretagets fall så är det inte alla medarbetare som använder Azure

DevOps vilket kan vara en nackdel. Men beroende i vilka sammanhang

idégenereringsverktyget ska användas så kanske det inte är nödvändigt

att exakt alla anställda har tillgång till det.





51

6.1 Rekommendationer till företaget

Förhoppningen är att SPV ska kunna ta med sig en del lärdomar från

detta projekt dels från delar som återfinns i teorin i kapitel 2, dels från

försöket att implementera med två olika metoder. De olika idé-

genereringsmetoderna som presenteras i kapitel 2 kan vara intressanta

för verksamheten och kan ge inspiration till framtida workshops.

Möjligheten att använda sig av eller utveckla egna tillägg till den

befintliga molnplattformen kan vara av intresse, även om det inte är i

samma ändamål som projektet. Däremot rekommenderar jag inte att

försöka sig på en implementering mot molnplattformen om kunskaper

kring implementeringen saknas hos utvecklaren, då dokumentationen

för utveckling av tillägg inte är lika utbredd som för information som

rör mer traditionell webbprogrammering. I övrigt så gäller det att väga

för och nackdelar då fristående applikationer kan vara att föredra i vissa

lägen medan integrerade tillägg i molnplattformen är att föredra i

andra. Där krävs en bedömning från fall till fall.

6.2 Förslag till fortsatt forskning

Vid en vidareutveckling av projektet skulle främst de punkter som

återfinns i kapitel 4.5 behöva åtgärdas för att göra applikationen an-

vändbar. En jämförelse mellan svarstider och prestanda mellan de olika

implementationsmetoderna hade även varit intressant för att ytterligare

kunna jämföra de två implementationsmetoderna. I detta projekt

gjordes ingen jämförelse av prestanda då applikationen kördes från

localhost och därmed hade resultatet varit ointressant att jämföra med

implementationen som var mot molnplattformen.

6.3 Etiska och samhälleliga aspekter

Vid utvecklandet av ett verktyg som potentiellt kan lagra känslig

information så är det viktigt med datasäkerhet. För att företag ska

kunna använda verktyget till att utveckla nya idéer och eventuellt då

även skriva affärshemligheter är det viktigt att informationen som

lagras i applikationen inte kan läcka ut. Då det handlar om en myndig-

het finns även tydliga krav på hur data får hanteras och lagras. Däremot

så bör inte personuppgifter från kunder och anställda och så vidare

nödvändigtvis behöva lagras i ett idégenereringsverktyg som det som

utvecklades i projektet. För den fristående webbapplikationen behöver

däremot GDPR tas i beaktande då användaren behöver skapa ett konto

på sidan.





52

En ytterligare aspekt att ta i beaktande är hur idéhanteringen ser ut på

företaget. I vissa företag kanske det till exempel utlyses ett pris till den

som kommer på en bra idé. I dessa fall kan det vara viktigt att det är

tydligt vem det är som föreslår vilken idé. Medan å andra sidan kan

vissa människor tycka att det är obehagligt att skriva ut idéer inför alla

där det tydligt står att idéen är deras. Detta skulle potentiellt kunna

hämma andelen idéer som inkommer och få människor att känna sig

utpekade om deras idé inte tas emot väl. Så här krävs en avvägning

utifrån hur företagssituationen ser ut hur verktyget bör utformas. Men i

det stora hela kan verktyget möjliggöra att idégenerering utförs på

distans vilket gör att det inte är ett måste att samla deltagarna på samma

ställe. Vissa personer kanske dessutom lättare kan framföra sina idéer

då de slipper tala högt inför grupp så det finns både möjliga för- och

nackdelar.





53

Källförteckning [1] Arenhardt D.L, Eugênio de O.S, Glauco O.R. ”Importance of

Innovation for European SMEs: Perception of Experts”. Di-

mensión Empresarial. Vol. 16, nr. 2. Sida. 21-37; 2018. [Citerad 31

mars 2021]. Hämtad från: https://search-proquest-

com.proxybib.miun.se/docview/2437125801?pq-origsite=primo

[2] OECD. 2020, “The public sector innovation lifecycle: A device to

assist teams and organisations in developing a more sophistica-

ted approach to public sector innovation” [Internet]. OECD Wor-

king Papers on Public Governance, no. 37, OECD Publishing, Pa-

ris. [Citerad 31 mars 2021]. DOI: 10.1787/0d1bf7e7-en. Hämtad

från: https://www.oecd.org/innovation/the-public-sector-

innovation-lifecycle-0d1bf7e7-en.htm

[3] Johanna Lundeberg, internetstiftelsen. U. år. ”Molntjänster”.

[Citerad 11 juni 2021]. Hämtad från:

https://internetstiftelsen.se/guide/anvandarvillkoren/molntjanster

/ Klicka på Kunskap -> Rapporter och guider -> Användarvillko-

ren som ingen läser -> Molntjänster

[4] Gartner. ”Gartner Forecasts Worldwide Public Cloud End-User

Spending to Grow 18% in 2021”. Pressmeddelande 17 november

2020. [Citerad: 16 juni 2021]. Hämtad från:

https://www.gartner.com/en/newsroom/press-releases/2020-11-

17-gartner-forecasts-worldwide-public-cloud-end-user-spending-

to-grow-18-percent-in-2021

[5] Statens tjänstepensionsverk (SPV). U. år. ”Om SPV”. [Citerad 27

januari 2021]. Hämtad från: https://www.spv.se/om-spv/

[6] Nationalencyklopedin. ”Innovation”. [Citerad: 2021-04-12].

Hämtad från: https://www-ne-

se.proxybib.miun.se/uppslagsverk/encyklopedi/l%C3%A5ng/inn

ovation

[7] Gerlach S, Brem A. Idea management revisited: A review of the

literature and guide for implementation. International Journal of

Innovation Studies, vol. 1, Issue 2, Pages 144-161; 2017. ISSN

https://search-proquest-com.proxybib.miun.se/docview/2437125801?pq-origsite=primo

https://search-proquest-com.proxybib.miun.se/docview/2437125801?pq-origsite=primo

https://www.oecd.org/innovation/the-public-sector-innovation-lifecycle-0d1bf7e7-en.htm

https://www.oecd.org/innovation/the-public-sector-innovation-lifecycle-0d1bf7e7-en.htm

https://internetstiftelsen.se/guide/anvandarvillkoren/molntjanster/

https://internetstiftelsen.se/guide/anvandarvillkoren/molntjanster/

https://www.gartner.com/en/newsroom/press-releases/2020-11-17-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-grow-18-percent-in-2021



https://www.spv.se/om-spv/

https://www-ne-se.proxybib.miun.se/uppslagsverk/encyklopedi/l%C3%A5ng/innovation







54

2096-2487. [Citerad 26 april 2021]. DOI: 10.1016/j.ijis.2017.10.004.

Hämtad från:

https://www.sciencedirect.com/science/article/pii/S2096248717300

048

[8] Cinar E, Trott P, Simms C. A systematic review of barriers to

public sector innovation process. Public Management Review,

21:2, 264-290. 2019. DOI: 10.1080/14719037.2018.1473477. [Citerad

8 april 2021]. Hämtad från: https://www-tandfonline-

com.proxybib.miun.se/doi/full/10.1080/14719037.2018.1473477

[9] Paulus P, Dickson J, Korde R, Cohen-Meitar R, Carmeli A. 2016.

”Getting the Most out of Brainstorming Groups. In Open Inno-

vation: Academic and Practical Perspectives on the Journey from

Idea to Market”. Oxford University Press. [Citerad: 8 april 2021].

Hämtad från: https://oxford-universitypressscholarship-

com.proxybib.miun.se/view/10.1093/acprof:oso/9780199374441.00

1.0001/acprof-9780199374441-chapter-3

[10] Wikberg Nilsson Å, Ericson Å, Törlind P. 2015. ”Design: process

och metod”. Upplaga 1:1. Studentlitteratur.

[11] Innovationsguiden. U. år. ”Metodmallar”. [Citerad: 16 februari

2021]. Hämtad från:

https://innovationsguiden.se/metodmallar_ta-fram-ideer/

[12] Miro. U. år. ”Mind Map Template”. [Citerad: 16 februari 2021].

Hämtad från: https://miro.com/templates/mind-map/

[13] Miro. U. år. ”S.C.A.M.P.E.R Template”. [Citerad: 16 februari

2021]. Hämtad från: https://miro.com/templates/scamper/

[14] Miro. U. år. ”Reverse Brainstorming Template”. [Citerad: 16

februari 2021]. Hämtad från: https://miro.com/templates/reverse-

brainstorming/

[15] Dialogic. 2017. ”Introduction to Cloud Computing”. [Citerad 11

juni 2021]. Hämtad från:

https://www.dialogic.com/~/media/products/docs/whitepapers/1

2023-cloud-computing-wp.pdf

[16] Microsoft. U. år. ”Vad är Azure?”. [Citerad 8 juni 2021]. Hämtad

från: https://azure.microsoft.com/sv-se/overview/what-is-azure/



https://www-tandfonline-com.proxybib.miun.se/doi/full/10.1080/14719037.2018.1473477

https://www-tandfonline-com.proxybib.miun.se/doi/full/10.1080/14719037.2018.1473477

https://oxford-universitypressscholarship-com.proxybib.miun.se/view/10.1093/acprof:oso/9780199374441.001.0001/acprof-9780199374441-chapter-3



https://innovationsguiden.se/metodmallar_ta-fram-ideer/

https://miro.com/templates/mind-map/

https://miro.com/templates/scamper/

https://miro.com/templates/reverse-brainstorming/

https://miro.com/templates/reverse-brainstorming/

https://www.dialogic.com/~/media/products/docs/whitepapers/12023-cloud-computing-wp.pdf

https://www.dialogic.com/~/media/products/docs/whitepapers/12023-cloud-computing-wp.pdf

https://azure.microsoft.com/sv-se/overview/what-is-azure/





55

[17] Stalcup K. 2021. ”AWS vs Azure vs Google Cloud Market Share

2021: What the Latest Data Shows”. [Citerad: 16 juni 2021]. Häm-

tad från: https://www.parkmycloud.com/blog/aws-vs-azure-vs-

google-cloud-market-share/

[18] Microsoft. U. år. ”Azure DevOps”. [Citerad: 23 juni 2021]. Häm-

tad från: https://azure.microsoft.com/sv-se/services/devops/

[19] Microsoft. 2021. ”Compare Azure DevOps Services with Azure

DevOps Server”. [Citerad: 28 juni 2021]. Hämtad från:

https://docs.microsoft.com/en-us/azure/devops/user-guide/about-

azure-devops-services-tfs?view=azure-devops

[20] Integritetsskyddsmyndigheten. 2021. ”Grundläggande princi-

per”. [Citerad: 8 juni 2021]. Hämtad från:

https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-

gdpr/grundlaggande-principer/

[21] Integritetsskyddsmyndigheten. 2021. ”Behandling av person-

uppgifter hos myndigheter”. [Citerad: 8 juni 2021]. Hämtad från:

https://www.imy.se/verksamhet/dataskydd/dataskydd-pa-olika-

omraden/myndighet/

[22] Integritetsskyddsmyndigheten. 2021. ”Överföring till tredje

land”. [Citerad: 8 juni 2021]. Hämtad från:

https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-

gdpr/overforing-till-tredje-land/

[23] Peter Ottsjö. 2021. ”Här är allt du behöver veta om Schrems II –

domen alla företag bävar för”. Ny teknik. [Citerad 8 juni 2021].

Hämtad från: https://www.nyteknik.se/special/har-ar-allt-du-

behover-veta-om-schrems-ii-domen-alla-foretag-bavar-for-

7015637

[24] W3Shools. U. år. ”AJAX Introduction”. [Citerad: 11 juni 2021].

Hämtad från: https://www.w3schools.com/js/js_ajax_intro.asp

[25] Tutorials Point. U. år. ”AJAX - Technologies”. [Citerad: 23 juni

2021]. Hämtad från:

https://www.tutorialspoint.com/ajax/ajax_technology.htm

https://www.parkmycloud.com/blog/aws-vs-azure-vs-google-cloud-market-share/

https://www.parkmycloud.com/blog/aws-vs-azure-vs-google-cloud-market-share/

https://azure.microsoft.com/sv-se/services/devops/

https://docs.microsoft.com/en-us/azure/devops/user-guide/about-azure-devops-services-tfs?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/user-guide/about-azure-devops-services-tfs?view=azure-devops

https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/grundlaggande-principer/

https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/grundlaggande-principer/

https://www.imy.se/verksamhet/dataskydd/dataskydd-pa-olika-omraden/myndighet/

https://www.imy.se/verksamhet/dataskydd/dataskydd-pa-olika-omraden/myndighet/

https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/overforing-till-tredje-land/

https://www.imy.se/verksamhet/dataskydd/det-har-galler-enligt-gdpr/overforing-till-tredje-land/

https://www.nyteknik.se/special/har-ar-allt-du-behover-veta-om-schrems-ii-domen-alla-foretag-bavar-for-7015637



https://www.w3schools.com/js/js_ajax_intro.asp





56

[26] Sharp H, Preece J, Rogers Y. ”Interaction Design: beyond human-

computer interaction”. Upplaga: 5. Förlagsort: Indianapolis, IN.

Förlag: Wiley. Publiceringsår: 2019

[27] Statens tjänstepensionsverk (SPV). 2020. ”Exjobb – Automatisera

kreativitet”. [Powerpointpresentation].

[28] Michinov N. 2012. ”Electronic Brainstorming and Brainwriting”. J

Appl Soc Psychol, 42: E222-E243. [Citerad: 8 februari 2021]. Häm-

tad från: https://doi-org.proxybib.miun.se/10.1111/j.1559-

1816.2012.01024.x

[29] Marvel App. https://marvelapp.com/

[30] W3Techs. ”Usage statistics of PHP for websites”. [Citerad: 16 juni

2021]. Hämtad från: https://w3techs.com/technologies/details/pl-

php

[31] Nielsen J. 2000. ”Why You Only Need to Test with 5 Users”.

[Citerad: 18 maj 2021]. Hämtad från:

https://www.nngroup.com/articles/why-you-only-need-to-test-

with-5-users/

[32] Microsoft. 2021. ”Develop a web extension”. [Citerad: 7 augusti

2021]. Hämtad från: https://docs.microsoft.com/en-

us/azure/devops/extend/get-started/node?view=azure-devops

https://doi-org.proxybib.miun.se/10.1111/j.1559-1816.2012.01024.x

https://doi-org.proxybib.miun.se/10.1111/j.1559-1816.2012.01024.x

https://marvelapp.com/

https://w3techs.com/technologies/details/pl-php

https://w3techs.com/technologies/details/pl-php

https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/

https://docs.microsoft.com/en-us/azure/devops/extend/get-started/node?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/extend/get-started/node?view=azure-devops





57

Bilaga A

Intervjuunderlag Den här intervjun är en del av mitt självständiga arbete på kandidatnivå på Mittuni-

versitetet i Sundsvall inom datateknik och industriell ekonomi. Rapporten kommer att

publiceras offentligt efter färdigställande av studien. Syftet med intervjun är att göra

en kartläggning över nuläget av innovationsarbetet på SPV. Ert deltagande är

frivilligt och ni kan när som helst välja att avsluta intervjun eller att inte svara på

någon av frågorna. Svaren kommer endast att användas i forskningssyfte och behand-

las konfidentiellt. Intervjun beräknas ta ca 30-40 min. Är det okej om jag spelar in

intervjun?

Bakgrundsinformation om respondenter: Avdelning:

Roll:

Hur länge har du arbetat på SPV?

Övergripande om innovation på SPV

Hur definierar SPV innovation?

Finns det någon person/avdelning som är (huvudansvarig för innovat-

ionsarbetet? Vem/vilken?

Sker arbetet med innovation på flera avdelningar inom SPV? I så fall

vilka och finns det i så fall några kopplingar mellan dessa avdelningars

innovationsarbete?

Finns det något gemensamt arbetssätt för innovation på SPV eller är

innovationsarbetet olika inom olika delar av organisationen?

Vad är utvecklingsavdelningens roll i innovationsarbetet?

Arbetar SPV på olika sätt med innovation beroende på om innovationen

är mot externa kunder dvs, utveckling av tjänster/produkter eller om

det är riktat mot intern verksamhetsutveckling till exempel effektivisera

arbetsmetoder?

På vilket sätt ska Ni arbeta/arbetar Ni agilt på SPV med innovation?

Arbetar Ni och/eller SPV i övrigt efter någon särskild metod/process

idag? Eller finns det någon metod ni försöker följa? (Ex. den som

presenterades i PP:n)





58

Datainsamling och metoder:

Vilka metoder/verktyg används inom verksamheten idag i arbetet med

innovation? Olika typer av brainstorming? Metoder som används på

workshops med mera.

Hur har det gått med innovation under Corona?

Har ni haft någon digital workshop?

Finns det något sätt att samla (spontana) idéer från verksamheten i

dagsläget? Idélåda? Utvärderingar? Varför/Varför inte? Har det funnits

förut?

Finns det andra typer av input som kommer internt, externt från kunder

eller via omvärldsbevakning som skulle kunna/används i innovations-

processen idag?

Samlar ni in information från kunder och deras upplevelser? (Ex,

kundtjänst, hemsida)

Slutna frågor:

Hur mäter ni innovation på SPV?

Kan du nämna tre innovationer som SPV tagit fram det senaste året?

Om du kommer på en ny idé hur går du till väga för att lägga fram den?

Hur fås återkoppling på föreslagna idéer?

Finns det tydliga mål inom organisationen kopplat till innovation?

Känner du att du har möjlighet att vara innovativ i din tjänst?

Finns det inplanerad tid för innovation i din tjänst/grupp?

Bedriver SPV innovationsarbete med utomstående aktörer? Hur ofta

sker innovation i samarbete med utomstående aktörer i så fall?





59

Bilaga B

Prototyp från Marvel App





60





61





62

Bilaga C

Underlag för användbarhetstest Uppgifter:

Skapa en användare och logga in

1. Börja en Brainstorming session där du skriver tre till fem idéer 2. Radera en eller flera idéer 3. Gruppera nu dina idéer utifrån tre till fem passande kategorier 4. Radera en av kategorierna

Frågor: Skala 1–5 där 1 är väldigt svår och 5 är väldigt enkel hur enkel eller svår upplevde du att applikationen var att använda?

Skala 1–5 där 1 är väldigt svårt och 5 är väldigt enkelt hur enkel eller svårt upplevde du att det var att lära sig verktyget bara genom att använda det?

Skala 1–5 där 1 är väldigt svårt och 5 är väldigt enkelt hur enkel eller svårt upplevde du att det var att förstå och hitta knappar, formulär och hitta på sidan?

Skala 1–5 där 1 är inte effektiv alls och 5 är mycket effektiv hur effektiv upplevde du att sidan var för att utföra idégenerering?

Finns det några funktioner som du anser saknas?

Skulle det här verktyget kunna vara användbart för er på SPV så som det ser ut just nu?

Skulle ett liknande verktyg kunna vara användbart?

Ser du några fördelar/nackdelar med att ha det som fristående eller att koppla mot Azure Boards?

Övrigt?

Date post:	12-Feb-2022
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Digitalt verktyg för kollaborativ idégenerering

Documents