High Hopes - Low Code En fallstudie om effekter av Low-code hos en statlig myndighet

High Hopes - Low Code

En fallstudie om effekter av Low-code hos en statlig myndighet

Alexander Elmgren

Joel Tingman

Systemvetenskap, kandidat 2020

I

Förord

II

Sammanfattning

Digitalisering i samhället sker snabbt och frågan är inte om, utan när och hur det skall genomföras. Low-code är ett allt mer populärt sätt att bygga mjukvara på. Istället för att skriva koden för hand så låter Low-code användaren dra nytta av grafiska gränssnitt och färdiga komponenter, med intentionen att öka produktiviteten inom mjukvaruutveckling.

Denna fallstudie, vars kontext är Kronofogdemyndigheten, har undersökt vilka effekter som Low-code har på en statlig myndighets mjukvaruutvecklingsarbete. Med hjälp av semistrukturerade intervjuer identifierades ett antal av myndighetens behov. Dessa behov fick fungera som utgångspunkt i utvecklandet av en prototyp och skapandet av ett antal testfall som utfördes i en betaversion av Low-code verktyget WebRatio. Prototypen och testfallen visades upp för intressenter på Kronofogden som fick värdera hur väl verktyget WebRatio i synnerhet och Low-code i allmänhet uppfyller deras behov.

III

Abstract

The digitalization of today’s society is ongoing at full speed, and the question is not if, but how it will be done. Low-code is an increasingly popular way of building software. Instead of writing code by hand, Low-code allows the user to utilize graphical user interfaces and ready-to-use components, with the intention to increase productivity in the area of software development. This case study whose context is Kronofogdemyndigheten has researched which effects Low-code has on a state-owned organizations software development.

Utilizing semi-structured interviews, some of the organization's requirements were identified. These requirements formed the basis for the development of a prototype and a few test cases. The prototype and the test cases were created in a beta version of a Low-code tool, WebRatio. They were then demonstrated and explained to stakeholders at Kronofogden that evaluated to what extent WebRatio in particular and Low-code in general can fulfill their requirements.

IV

Innehållsförteckning

3.2.1 Design science research methodology 6

3.2.2 Behovsdriven utveckling 6

3.3 Semistrukturerad intervju 7

3.3.1 Insamling av behov 8

3.3.2 Uppvisning och utvärdering av prototyp och testfall 9

3.4 Prototyp och testfall 10

3.4.1 Prototyparbete 10 3.4.2 Testfall 11 3.5 Litteraturstudie 12 3.6 Analysmetoder 13 3.7 Forskningskvalité 14 3.8 Etiska överväganden 15 4. Teori 16 4.1 Programmering 16 4.2 Low-code utveckling 17

4.2.1 Low-code och No-code 17

4.2.2 För- och nackdelar med Low-code 18

4.3 Digitalisering och förändringsarbete 20

4.3.1 Sverige och offentlig sektor 21

5. Resultat & Analys 22

V

5.1.1 Utvecklingsarbete 22

5.1.2 Funktionalitet 24

5.1.3 Kod 25

5.2 Prototyp och testfall 25

5.2.1 Testfall 31

5.3 Resultat och analys av utvärderingsintervju 35

6. Diskussion 40

7. Slutsats 43

7.1 Vidare forskning 44

8. Referenser 45

9. Bilaga 50

9.1 Testfall 1 - Skapa “required”-validering 50

9.2 Testfall 2 - Find Model Problems 56

9.3 Testfall 3 - CSS 59

1

1. Introduktion

Under de senaste åren så har den svenska offentliga sektorn satsat hårt på digitalisering. Bland annat finns den nyligen grundade myndigheten för digital förvaltning som ansvarar för att stötta och främja den offentliga sektorns resa mot digitalisering. En myndighet som enligt civilministern Ardalan Shekarabi spelar en central roll för att ta tillvara på de besparingar och de positiva effekter digitaliseringen bidrar till (Regeringskansliet, 2017).

Dock så riktas en del kritik mot digitaliseringsarbetet, en rapport från digital förvaltning beskriver hur den offentliga sektorn inte uppfyller den nivå av digital mognad som regeringens målsättning innebär. Digital mognad innebär: “En organisations förmåga att tillgodogöra sig nyttorna med digitalisering.” (Digital förvaltning, 2020). Johan Stahre, professor på Chalmers Universitet, blir intervjuad om ämnet “digitalisering” i en podcast och definierar begreppet på följande vis: “How you should use a new technology in order to be more productive, safer, and more creative” (Chalmers University of Technology, 2018).

2

Det finns dock vissa aspekter med Low-code som potentiellt kan ställa till med problem. Exempelvis vid val av plattform - Finns den funktionalitet som efterfrågas? Vissa plattformar stödjer användning av extern kod och skript för att på så vis öka flexibiliteten, men det är något som måste undersökas innan man väljer plattform (Waren, 2018). Förutom utvecklingsverktygets funktionalitet, så kan olika plattformar erbjuda olika kvalité på utbildningsresurser i form av dokumentation eller exempelvis bilder och instruktionsvideor (Taulli, 2019). Gartner rapporterar att av alla stora organisationer så kommer 75% av dessa att använda så kallade Low-code verktyg vid apputveckling och extern digitalisering innan 2024 (Vincent, Iijima, Driver, Wong & Natis, 2019). Innan dess uppskattas denna typ av verktyg utgöra 65% av den totala applikationsutvecklingen. Den ökande efterfrågan på mjukvara och en brist på duktiga utvecklare gör också Low-code till ett intressant alternativ.

Samtidigt så fanns det en utbredd oro bland utvecklare. En uppsats från 2016 visade att utvecklare som inte ännu testat Low-code var oroliga för att det skulle vara bristande inom en rad aspekter (Baldwin & Kopkin, 2016). Till exempel så såg de risken att det skulle kunna vara svårt att hitta motsvarigheten mellan det visuella och manuella perspektivet, de var även rädda för att koden som genereras skulle vara svår att läsa och förstå.

3

2. Syfte

Syftet med denna rapport är att utvärdera och testa vilka effekter Low-code får hos en statlig myndighet. Detta för att öka kunskapen hos myndigheter såväl som andra intressenter och fungera som stöd för beslutssprocesser inom mjukvaruutvecklingsområdet. Som en del i detta syfte har en prototyp utvecklats och senare utvärderats genom testfall, för att bidra till ökad förståelse.

2.1 Avgränsningar

Denna studie har valt att fokusera på en statlig myndighet. Typen av mjukvaruutvecklingsarbete denna studie fokuserar på avgränsas till frontendutveckling. Fokus har varit på Low-code som driftsätts på lokal server och inte i molnet.

4

3. Metod

Detta kapitel beskriver de utgångspunkter som funnits, metodval som gjorts och utförts. I slutet av kapitlet så reflekteras det även över denna process utifrån etiska och självkritiska aspekter.

En studie kan ha en kvalitativ eller kvantitativ ansats. Valet beror på vad studien ska beskriva, det vill säga studiens problemställning. En kvantitativ design syftar till att få bredd i arbetet medans en kvalitativ design lämpar sig bättre om du vill undersöka något på djupet (Jacobsen, 2017).

Vid val av undersökningsdesign så bör det avgöras huruvida studien är ute efter att generalisera statistiskt eller teoretiskt. Statistik generalisering handlar om att kunna dra slutsatser över den population som undersökts medans teoretisk generalisering fokuserar på att dra slutsatser om hur saker hänger ihop och göra uttalanden om lagbundenheter som råder. Att om X görs så kommer det få konsekvens Y (Jacobsen, 2017).

I detta arbete studerades ett specifikt fenomen avgränsat i tid och rum. Arbetet utfördes med kvalitativa intervjuer för att gå på djupet och skapa en djupare förståelse. Denna typ av arbete stämmer bra överens med beskrivningen för fallstudier. Det är också en undersökningsdesign som ämnar komma fram till en teoretisk generalisering, det vill säga skapa något som grundar för ny teoribildning vilket är vad studien ämnat att göra (Jacobsen, 2017).

Då arbetet främst utgick från empiri så kan det anses vara induktivt med en relativt öppen datainsamling. Då studien använde sig av semi-strukturerade intervjuer snarare än exempelvis enkäter (Jacobsen, 2017). Ett induktivt tillvägagångssätt har som mål att tillåta att undersökningsdata härleds från rådata utan dom begränsningar som ett mer strukturerat undersökningssätt innebär (Thomas, 2003).

3.1 Forskningsmiljö

5

Detta examensarbete utfördes på initiativ av Kronofogden och fallstudiens specifika kontext är Kronofogdens IT-avdelning i Sundbyberg. Idag består Kronofogdens IT-miljö till stor del av programmeringsspråket Java som är ett av de mest populära språken idag (TIOBE, 2020). De använder även ramverket Angular som också är ett av de mer populära alternativen utvecklat av Google (SD Times, 2019).

Ett specifikt verktyg har varit i fokus då de uppfyller de tekniska kraven och grundläggande behov som fanns definierade innan studien, verktyget heter WebRatio (WebRatio, 2020). Versionen av verktyget som användes i denna studie var en betaversion och har uppdaterats under studiens gång. Vid en redogörelse av krav på verktyget så beskrevs följande av personal på Kronofogden, en systemanalytiker och en IT-arkitekt. En viktig faktor till valet var att WebRatio genererar Java-kod och inte körbar kod som direkt går att köra på servern. Anledningen till att detta är viktigt är för att man ska kunna påbörja ett projekt i WebRatio och sedan ta all den koden och arbeta vidare på den i ett annat verktyg eller i en kod-editor. En annan viktig faktor var att det inte var molnbaserat som många andra Low-code verktyg är, när datan ligger i molnet så finns det en del säkerhetsrisker som Kronofogden i detta fall inte är villiga att riskera. Den sista faktorn var att WebRatio tillät användning av utomstående verktyg för att utföra olika aktiviteter relaterat till utvecklingen. Vissa andra leverantörer har en struktur som innebär att man är tvingad att använda deras testverktyg som exempel, för att det ska gå att testa det man skapat. Det var något som Kronofogden ville undvika då de redan har flera verktyg som de gillar och vill fortsätta att använda.

3.2 Forskningsstrategi

Datainsamlingen har genomförts uppdelad i tre distinkta men sammanhängande steg. Några moment bygger på resultatet av andra steg, dessa steg utförts till viss del parallellt med varandra.

1. Insamling av behov

a. Inledande intervju med Kronofogden och insamling av generella behov b. Text-analys och kategorisering av data

2. Prototyp och testarbete

6

3. Utvärdering av resultatet

a. Presentera resultat till Kronofogden. Samla in deras åsikter och tankar om prototypen och resultaten av testfallen.

b. Analys och kategorisering av data

3.2.1 Design science research methodology

Design science research methodology (DSRM) är en forskningsmetod, vars kärna är att designa och utveckla en artefakt, och delar många likheter med denna studie (Peffers, Tuunanen, Rothenberger, & Chatterjee, 2007). Processen för DSRM kan ses som uppdelad upp i sex aktiviteter. De första två aktiviteterna handlar om att definiera problemet och sätta upp mål för arbetet. Detta finns likheter i dessa med steg ett (insamling av behov) i denna studie. Vid beskrivning av aktivitet tre i DSRM - skapande av en artefakt, beskrivs:

“Conceptually, a design research artifact can be any designed object in which a research contribution is embedded in the design. This activity includes determining the artifact’s desired functionality and its architecture and then creating the actual artifact. “. - (Peffers et al, 2007).

Denna beskrivning av aktivitet 3 i DSRM kan liknas med hur vi i denna studie designar och bygger en prototyp i steg två, grundat i de insamlade behoven och med ett vetenskapligt syfte. Aktivitet fyra och fem är demonstration respektive utvärdering. Dessa två aktiviteter påminner om steg tre (utvärdering av resultatet) i denna studie, där resultatet demonstreras och utvärderas. Sista aktiviteten i DSRM handlar om kommunikation av resultatet av forskningsarbetet, vilket denna rapport i sig har syftet att åstadkomma (Peffers et al, 2007).

3.2.2 Behovsdriven utveckling

7

1. Samla in (behov) 2. Analysera (behov) 3. Utveckla

4. Införa

5. Förvalta och följa upp.

Figur 1: Baserat på ESamverkansprogrammet (u.å).

Denna studie skulle kunna tolkas som en kompletterande delprocess i steg 1 och 2 men med tyngdpunkten i steg 3, se figur 1 ovan. Detta då de centrala delarna av detta arbete går ut på att utveckla en prototyp som sedan testas mot behov som samlats in och därefter analyseras av intressenterna (ESamverkansprogrammet, u.å).

3.3 Semistrukturerad intervju

8

3.3.1 Insamling av behov

Två semistrukturerade intervjuer utfördes med målet att samla in behov gällande mjukvaruutveckling med fokus på frontend. Båda intervjuerna utfördes via videomöte och intervju 1 pågick i drygt 90 minuter medans intervju 2 pågick i cirka 60 minuter.

Med målet att skapa så bra förståelse som möjligt, så bestämdes det att urvalet fick bestå av en systemanalytiker och en IT-arkitekt - de var initiativtagarna till detta projekt och även de mest pålästa på myndigheten vad gäller Low-code. Systemanalytikern har även arbetat med att samla in och sammanställa behov hos intressenter och framtida användare på myndigheten. Detta leder till att studien på ett tidseffektivt sätt kan få en mer nyanserad bild av behoven på ett bredare plan än om intervjun hade varit med någon annan.

Vid semistrukturerade intervjuer nämner Bryman (2012) att det är bra att ställa sig själv frågan “Vad behöver jag veta för att kunna besvara de forskarfrågor som jag är intresserad av?”. Så målet blir att samla in information om de områden du är intresserad av att veta mer om, från perspektivet av den som intervjuas.

Vårt arbete är i linje med ett antal råd som Bryman (2012) ger vid förberedelser av intervjuguiden, exempelvis att skapa ett antal temaområden och ett antal intervjufrågor som inte är allt för specifika men ändå ser till att svaret du får på något sätt hjälper att besvara syftet med arbetet. Då våra intervjuer handlar om behov inom systemutveckling så togs vid formuleringen av våra intervjufrågor inspiration från exempel på olika kravkategorier som Görling (2009) tar upp nedan:

● Funktionskrav

○ Vanligaste typen av krav. Saker som artefakten ska kunna göra. ● Dokumentationskrav

○ Exempelvis “driftintruktioner för att kunna outsourca drift och underhåll av applikationer till driftparner i enlighet med ITIL/ITSM”.

● Kvalitetskrav

○ Exempelvis krav på användarvänlighet. ● Flexibilitetskrav

○ Krav som berör exempelvis anpassningsbarhet och möjlighet till att göra ändringar. ● Prestandakrav

9 ● Portabilitetskrav

○ Exempelvis “programkoden bör skrivas i Java för att kunna användas på olika plattformar och bygga vidare på våra standardbibliotek för transaktionshantering”. ● Säkerhetskrav

○ Exempelvis hur kommunikation behöver ske eller hur känsliga data ska lagras på ett säkert sätt.

När specifika behov analyserades så startade arbetet med att kategorisera dem på en generell nivå. Varje behov kräver tid i förberedelse och genomförande av test för det behovet, samt tid för presentation och analys av resultatet. Vid analys och konkretisering av behoven så gjordes en uppskattning kring vilka behov som det hade fokuserats mest på under intervjuerna samt hur väl det ansågs att tester för det behovet kunde genomföras.

3.3.2 Uppvisning och utvärdering av prototyp och testfall

Prototypen och testfallen presenterades för samma personer som tidigare var involverade i studien och som då fick möjligheten att tycka till om dessa. På så sätt säkerställdes att potentiella användare, som arbetar aktivt med och har god erfarenhet av mjukvaruutveckling, fick ta del av resultatet och uttrycka sina åsikter om det. Detta omfattande material presenterades och diskuterades med respondenterna vid tre olika tillfällen.

Under samtliga intervjutillfällen så var respondenterna samma personer som vid behovsintervjuerna. Syftet med denna utvärderingsintervju var att samla in tankar och åsikter från samma personer som det samlats in behov från på en så detaljerad nivå som möjligt. Detta då dessa personer har tillräckligt bra koll på behoven för att kunna sätta in resultatet i ett meningsfullt sammanhang.

Utvärderingsintervjuerna bestod av fyra typer av aktiviteter 1. Uppvisning och värdering av behov

2. Uppvisning av testfall

10

Vid uppvisning och värdering av behoven (1) så lades fokus på ett behov i taget och respondenterna fick ange ett värde mellan 1–10 som fick representera hur pass hög prioritet det behovet har i förhållande till alla andra behov. I uppvisning av testfall (2) så presenterades stegen för hur testfallen utfördes och vad resultatet av testfallet blev. I uppvisning av prototyp (3) så presenteras även där slutresultatet och arbetsprocessen för att komma fram till det resultatet. Semistrukturerade frågor (4) ställdes till respondenterna för att väcka diskussion och få svar relaterade till de behov som undersöks i denna studie. De ställdes i samband med att ett testfall eller en del av prototyparbetet demonstrerades och i regel behandlades ett behov i taget.

3.4 Prototyp och testfall

Under3–4 veckors tid genomgicks en utbildning i Low-code verktyget med en anställd på företaget WebRatio. Det var tre pass per vecka där varje session var uppdelad i ett teoretiskt pass på 2-3 timmar och ett praktisk pass på ytterligare 2-4 timmar. Utbildningen fungerade som en praktisk introduktion till Low-code och bidrog till en ökad förståelse för hur en fungerande prototyp kan utvecklas i ett Low-code verktyg. En anledning till att lägga ner tid på utbildning är även för att öka sannolikheten att verktyget på ett korrekt sätt kan undersökas och att dess kapacitet klargörs utan att missa några viktiga delar. Arbetet med prototypen var tänkt att reflektera ett antal behov. Men då alla behov inte kunde relateras till prototypen så valdes det att även planera och utföra testfall.

3.4.1 Prototyparbete

Att bygga prototyper kan göras med många olika syften i åtanke. Exempelvis så kan prototyper användas för att demonstrera och utvärdera en ny design eller så kan prototyper också vara ett sätt att få något mer konkret att titta på och en tydligare bild av den tänkta produkten. I många agila arbetsmetoder så kan även prototyper spela en central roll för det fortsatta arbetet vid varje iteration där målet är att uppnå korta releaser med körbar kod (Görling, 2009).

11

Vid ett möte med våra kontaktpersoner på Kronofogden summerades prototypens tänkta grundläggande funktioner och avgränsningar. För att projektet skulle få en praktisk förankring så fick den prototyp som byggdes inspireras av ett planerat framtida projekt - digitalisering av en blankett som används av brottsoffer i syfte av att ansöka om utbetalning av skadestånd. Blanketten finns tillgänglig på Kronofogdens hemsida (Kronofogden, u.å).

Processen

Arbetet med prototypen inleddes med att noga gå igenom blanketten som prototypen baseras på och ett flödesschema över prototypen ritades upp. Utifrån blanketten och flödesschemat gjordes en mockup för webbsidans tänkta grafiska utformning tillsammans med en datamodell i ritverktyget diagrams.net.

Nästa steg innebar att implementera denna datamodell i WebRatio’s backend. Detta tillåter WebRatio’s frontend-komponenter att tilldelas till en av dessa bakomliggande tabeller och begränsas till att visa just de kolumner och data som den tabellen har. De bakomliggande tabellerna är i sin tur en representation av en databas, i detta fall en MySQL databas som höll i nödvändig information för att prototypen skulle kunna göra det den var ämnad för.

Därefter modellerades interaktioner och flödet mellan webbapplikationens frontend-komponenter i WebRatio, detta tillåter knappar och andra former av event att få sin effekt. Logiken bakom vad som ska ske vid ett visst knapptryck skapas också i detta skede, till exempel möjligheten att lägga till fler rader i en lista eller att bli tagen till en specifik sida beroende på din relation till ett objekt. Den visuella delen som i WebRatio kallas för “Layout” designades med några av WebRatios standard-widgets, här så väljer man widgets beroende på sina behov, hur man vill strukturera datat och vill att sidan ska se ut. Största fokus låg dock i att gå djupare in i vad som är möjligt i form av funktionalitet.

3.4.2 Testfall

12

Processen inleds med att identifiera ett eller flera behov att undersöka. Nästa steg var att komma på hur studien på bästa sätt, både i relation till effektivitet och utfall, kan undersöka detta behov. I flera fall så hade testfallet kunnat bli bättre om de utförts på ett mer utförligt sätt för att ge resultaten mer grund att stå på. Nästa steg var att planera processen för testfallet, definiera ett förväntat resultat och sedan till sist utföra testfallet. För inspiration utgick studien främst från Eriksson (2008), som går igenom strukturen kring hur ett testfall bör se ut och vad det bör innehålla. Vissa delar ansågs vara mer eller mindre intressanta att dela med oss utav i just vårt fall. Nedan är ett exempel på en process för att skapa ett testfall.

1. Skapa ett ID bara baserat på numrering.

2. Bestäm och ange vilka eller vilket behov testfallet berör. 3. Beskriv vad testfallet ämnar besvara och vad som är målet.

4. Bestäm vilka steg som måste följas för att utföra testfallet på rätt sätt. 5. Ange vilket förväntat resultat som finns.

6. Ange resultat efter slutförande.

3.5 Litteraturstudie

En litteraturstudie utfördes med syfte att fånga upp vad som skrivs och sägs inom arbetets teoretiska referensram (Jacobsen, 2017). Sökningar gjordes på både svenska och engelska där de engelska sökningarna var mest fruktbara. Därför var merparten av sökningarna på just engelska. Universitetsbibliotekets sökfunktion, google scholar och google sök användes för att hitta material. Förutom våra sökningar så undersöktes även de källor som andra arbeten refererat till. Vid sökningar på Low-code hittades, förutom vetenskapliga rapporter och artiklar, även blogginlägg, populärvetenskapliga artiklar och uppsatser.

Söktermer som användes var: code, Pros and cons of code, code development,

13

3.6 Analysmetoder

Analysen av behovsintervjuerna tog inspiration från Jacobsens beskrivning för hur en bra analys bör genomföras (Jacobsen, 2017). De faser vi genomgick i vårt analysarbete var:

● Dokumentera ● Utforska

● Systematisera och kategorisera

Dokumentera är en fas som innebär att beskriva materialet man fått in genom intervjuerna. Detta

gjordes genom att lyssna igenom intervjuerna och transkribera innehållet för att underlätta vidare analys.

Utforska innebär att kolla igenom den framtagna datan, forskaren söker här efter förhållanden som

finns i innehållet. I detta fall så kombinerades steget med Systematisera och Kategorisera som innebär att reducera onödig information som alltid följer med när man jobbar med kvalitativa data och ta fram olika teman och kategorier utifrån ett antal kriterier som är relevanta.

14

3.7 Forskningskvalité

Denna studie har strävat efter transparens, tydlighet och öppenhet så mycket som möjligt kring vad som utförts och de eventuella oklarheter eller svagheter som finns med i valda strategier och metoder. En öppenhet och tydlighet kring vilka val som gjorts under arbetsprocessen är ett fundament för att bedöma studiens riktighet och därmed om arbetet är möjligt att repetera (Jacobsen, 2017).

I vårt arbete har fokus varit att eftersträva en tydlig och sammanhängande struktur för att undvika osäkerheter kring vad som gjorts och vilka resultat de bidragit till.

Studiens empiri gällande behov samlades in under två semistrukturerade intervjuer, som beskrivs i 3.3.1, med sammanlagt två respondenter. Samma två personer var även respondenter i utvärderingsintervjun som beskrivs i 3.3.2. Forskarnas egna åsikter och värderingar togs inte hänsyn till. Materialet som demonstrerades för respondenterna i denna utvärderingsintervju bestod av det resultat som visas upp senare i kapitel 5. Upplägget för vilket resultat som testades och visades samt på vilket sätt som detta gjordes bestämdes av forskarna själva. Detta var en utmanande aspekt av studien, att på ett så bra sätt som möjligt visa upp vårt resultat för två personer som inte är insatta i verktyget eller var delaktiga i framtagandet av prototypen - mer än att specificera behoven av funktionalitet.

15

3.8 Etiska överväganden

16

4. Teori

I detta kapitel så redovisas den teori och de koncept som är relevanta för studiens vetenskapliga område.

4.1 Programmering

I sin korthet kan programmering definieras som aktiviteten att skriva program, där ett program förenklat kan ses som en lista med instruktioner för en dator att utföra. Programmeringsspråk är något som är nödvändigt att använda vid aktiviteten programmering, då en dator inte skulle förstå om du försökte skriva instruktionerna på exempelvis svenska eller engelska. Ofta är ett programmeringsspråk ett sätt att uttrycka sig i text enligt ett antal strikta regler (Van Toll, Egges, Fokker, 2019).

Programmering spelar en central roll i mjukvaruutveckling som är en växande industri. Enligt en prognos från Industry Research (2018) så kommer marknaden för mjukvaruutveckling öka med ungefär 11.72% genomsnittligen varje år mellan 2016 och 2022. Detta leder till ett stort behov av effektiva arbetssätt och kompetenta utvecklare, som delvis redovisats tidigare och som en rapport bekräftar genom sin enkätundersökning hos företag i branschen (Coding Sans, 2020). Rapporten skickar ut en enkät till 703 utvecklare från 81 länder och visar på många utmaningar som branschen idag står inför, exempelvis kapacitetsbrist, dvs. en brist i hur effektivt man kan hantera en stor arbetsbelastning. Andra utmaningar som tas upp är delande av kunskap mellan anställda och anställande av kompetenta utvecklare.

17

4.2 Low-code utveckling

En Low-code plattform möjliggör utveckling av mjukvara med minimalt skrivande av kod. Målet är att flera olika typer av användare ska kunna arbeta inom utveckling genom att på ett snabbt och enkelt sätt skapa applikationer. Mer erfarna användare kan i plattformarna skapa mjukvara med betydligt mindre kodande, medans användare utan erfarenhet kommer behöva spendera mindre tid på att lära sig innan dom kan börja utveckla (Silva, Vieira, Campos, Couto & Ribeiro, 2020). Till skillnad från kod skriven för hand så bygger Low-code utveckling på användandet av grafiska användargränssnitt. Användare av Low-code verktyg kan både vara programmerare eller icke-programmerare, men ställer ofta krav på en grundläggande förståelse för programmering och mjukvarudesign (Bloomberg, 2020). Low-code har en stark koppling till begrepp som 4GL, Rapid Application Development (RAD) och Visuell programmering. Exempel på världsomspännande Low-code verktyg är Appian, Salesforce, Google App Maker och Microsoft Powerapps (Waszkowski, 2019).

Det finns olika typer av Low-code verktyg. Den första typen är verktyg som genererar kod där det som producerats kan köras helt separerat från utvecklingsverktyget. Precis som om den vore skriven för hand. Sedan finns det en annan typ av verktyg som brukar kallas “modell-drivna” Low-code verktyg. I denna typ av verktyg kan den konstruerade artefakten endast köras så länge plattformen levererar sin tjänst och användaren kör artefakten i plattformens verktyg. Ofta är denna typ av plattformar molnbaserade (Bloomberg, 2020).

4.2.1 Low-code och No-code

18

skillnad mellan dessa begrepp i sättet att arbeta med verktygen men också den primära målgruppen för verktyget. En översiktlig jämförelse kan ses nedan i tabell 1. Om målgruppen kan sägas vara professionella utvecklare snarare än personer som inte har någon erfarenhet av programmering, då är det snarare ett Low-code verktyg än ett No-code verktyg. Likaså, om ett verktyg endast riktar sig mot personer som inte kan skriva kod då är det sannolikt ett No-code verktyg (Bloomberg, 2020).

Tabell 1. Tabellen nedan är en jämförande sammanställning mellan Low-code och No-code. Manuell programmering är med som jämförelse.

Low-code No-code Manuell

Programmering Primär Målgrupp Utvecklare Icke-utvecklare Utvecklare

Sekundär Målgrupp Icke-utvecklare Utvecklare -

Krav på / möjlighet till manuell programmering

Låg Ingen Hög

Flexibilitet Mellan Låg Hög

4.2.2 För- och nackdelar med Low-code

Systemutveckling med Low-code verktyg kräver nästan ingen utbildning för att ändå kunna användas effektivt och utveckla applikationer upp till 10 gånger så snabbt än med traditionella programmeringsspråk (Richardson & Rymer, 2016). Outsystems presenterar i en rapport några punkter som Low-code möjliggör och som på ett positivt sätt påverkar utvecklingsarbetet (Outsystems, 2019):

● Utvecklare har möjligheten att välja mellan flera olika språk när det kommer till manuell programmering inom Low-code. Det gör Low-code intressant för en betydligt större del utvecklare då det kan anpassas till utvecklare oberoende av vilket programmeringsspråk man kommer ifrån.

● Low-code kan tillåta ett IT-avdelning att hålla koll inom systemet på vad alla utvecklare gör, detta för att ingen ska påbörja en funktion de vill göra utan godkännande.

19

icke-programmeringsuppdrag som säkerhet, integration och testing att göra det på samma plattform för att centralisera aspekter och tillåta samarbete över gränserna.

● Low-code förbättrar möjligheterna för “B2C”, alltså “Business to Customer”. Detta genom att involvera inbyggda möjligheter i Low-code för AI och Maskininlärning för väl fungerande kommunikationsmedel mellan kund och företag.

En mätning i samma rapport säger att 45% av mobila applikationer tog över fem månader att utveckla och för webbapplikationer så låg det på 39%. Rapporten innehåller också information från dessa respondenter kring hur deras arbetssätt skiljer sig från företag som inte använder Low-code. I relation till föregående mätning så visar rapporten att de företag som använder Low-code har 11% högre sannolikhet att färdigställa webbapplikationer inom 4 månader än företag som inte använde det. Samma mätning gällande mobilapplikationer visade en 15% ökad sannolikhet åt samma håll, vilket följer samma linje från utvecklarnas perspektiv (Outsystems, 2019).

Rapporten tar även upp negativa aspekter som de tillfrågade respondenterna nämnde, till exempel så är många oroade över inlåsning, dvs att man är bunden till Low-code utan möjligheten att använda utomstående verktyg som man gillar. Utöver detta så är flexibilitet, skalbarhet och säkerhet ämnen av oro för organisationer som inte valt att använda Low-code (Outsystems, 2019). Även en annan artikel stödjer den oron om skalbarhet, vilket enligt artikeln är nödvändigt för att Low-code plattformar ska kunna användas i större projekt (Tisi et al., 2019).

20

1. Risken att inte kunna integrera med dina existerande system.

2. Risken att komponenterna inte är tillräckligt anpassningsbara för att uppfylla dina behov. Annars blir du istället tvungen att anpassa din verksamhet för att plattformens kapacitet ska räcka till.

En annan artikel från Joe Stangarone, VD på MRC som är ett Low-code företag bekräftar den negativa aspekten kring anpassningsbarhet som Fallouh tar upp men nämner även en aspekt som Outsystems tog upp. Risken för inlåsning till en specifik plattform, vilket kan innebära att man inte kan förändra applikationen utanför plattformen eller att koden är så invecklad och dåligt strukturerad att det är svårt att förstå den (Stangarone, 2019). En tredje artikel av Andrew Zola, IT-journalist, stödjer båda punkterna Fallouh nämner men också det som Stangarone och Outsystems tar upp med risken att bli låst till en plattform (Zola, 2017).

4.3 Digitalisering och förändringsarbete

Digitalisering inom IT definieras enligt International Data Groups Ordlista som “övergång till användning och lagring av information i digital form i organisationer och samhälle” (International Data Group, 2020). Organisationer som väljer att ta tillvara på möjligheterna antar också utmaningarna med digitaliseringsarbetet. Detta gör de för att förbättra deras förmåga att dela information, kommunicera, koordinera och interagera (Greeven & Williams, 2017).

Om digitalisering innebär en övergång från något till något annat, så innebär detta att en förändring måste ske. Att planera och studera sådant förändringsarbete är av stor nytta för organisationen av många anledningar. Exempelvis gör det organisationer mer stabila och skapar en förbättrad kultur hos de anställda. Att utföra en förändring innefattas ofta av fyra grundläggande steg (Hashim, 2013):

● Bedöm behoven för förändring ● Initiera förändringen

● Implementera förändring

21

I en rapport om utmaningar med digitalisering så intervjuades seniora digitaliserings-konsulter och frågan ställdes hur digitaliseringsprocessen manifesteras hos företag. Proof-of-concept-prototyper togs upp som ett sätt för företag att initiera digitaliseringsarbete. Ett annat tillvägagångssätt för att prova på nya idéer är att företag går samman i innovationsprojekt för att dela på risken och den ekonomiska kostnaden. (Henriette, Feki & Boughzala, 2016).

I organisationers digitaliseringsarbete, så upplevs det av vissa att komplexiteten och mängden arbete som krävs för att utveckla och underhålla systemen är ett växande problem. Samtidigt så förändras marknaden runt omkring organisationerna som sätter krav på anpassningsförmåga, att på ett snabbt och flexibelt sätt uppfylla nya krav som dyker upp (Sanchis, García-Perales, Fraile & Poler, 2019). I strävan att lösa problem som dessa, så undersöks det bland annat kring sätt att konstruera mjukvaruapplikationer utan användning av traditionell hand-kodning och programmering. Denna typ av undersökning har pågått under en längre tid och tidiga produkter av det här arbetet, som RAD- och 4GL-verktyg som nämnts tidigare, har blivit användbara för att motverka denna typ av problematik. Dessa blev dock aldrig någon dominerande kraft inom mjukvaruutveckling. Idag så finns det en ny generation av verktyg som kallas Low-code plattformar som jobbar för att motverka denna typ av problem (Tisi et al, 2019).

4.3.1 Sverige och offentlig sektor

Inom offentlig sektors mjukvaruutvecklingsarbete så finns ofta behov som andra sektioner inte har och ställs inför unika utmaningar. Vid införskaffande av IT-tjänster kan det därför var svårt att hitta leverantörer som är gångbara för offentliga verksamheter. I en rapport om digitaliseringen hos svenska myndigheter så framgick det bland annat att 39.2% av myndigheter utvecklar mjukvara internt och där många har IT-avdelningar som i storlek kan jämföras med stora företag (Borg, Olsson, Franke & Assar, 2018).

22

5. Resultat & Analys

I detta kapitel presenteras allt resultat av denna undersökning och de analyser som gjorts utifrån resultatet. Kapitlet är uppdelat i tre delar där den första delen behandlar resultatet och analysen från intervjun som utfördes för insamling av behov. I den andra delen redovisas resultatet från byggandet av en prototyp samt testfall. I den tredje delen av detta kapitel så finns resultat och analyser från intervjun som utfördes med syfte att samla in synpunkter på och värderingar av prototypen och Low-code som sätt att arbeta.

5.1 Behov inom mjukvaruutveckling

De inledande intervjuerna skapade förutsättningar för vidare analys. Den empiriska data som ligger till grund för kategorierna presenteras i detta kapitel, se avsnitten nedan, och tillvägagångssättet beskrivs i kapitel 3.6. Kategorierna bestod av tre olika behovsområden;

● Utvecklingsarbete

○ Behov som behandlar utvecklingsarbetet på något sätt. ● Funktionalitet

○ Behov som kan kopplas till specifik funktionalitet. ● Kod

○ Behov som berör strukturen och kvalitén av koden.

5.1.1 Utvecklingsarbete

23

“Komplexiteten och den mängd kunskap som måste finnas för att kunna producera en färdig lösning som verksamheten kan utnyttja”.

I samma anda så uttrycker R1 att det absolut mest centrala, för att lösa dagens problematik, är att

“snabba på och förenkla” processen för front-end utveckling. Processen idag är väldigt

tidskrävande och problem är vanligt förekommande. Starkt kopplat till detta så tog R1 upp bristen på utvecklare med rätt kompetens i allmänhet och utvecklare med kunskaper i Angular i synnerhet. R1 uttryckte följande; ”Utvecklarna fastnar i tekniska strunt-problem”.

Detta är något som enligt R1 kan stå i vägen för utvecklarnas ambitioner att känna att deras arbete gör faktisk affärsnytta i verksamheten snarare än buggfixar. Exempel på problem som uppstår kan vara att en komponent i en webbapplikation får olika beteenden beroende på vilken webbläsare som används. R1 la självmant fokus på dokumentation under intervjun, något som belyses som väldigt viktigt för att Kronofogden ska kunna standardisera och förenkla sin utvecklingsprocess. Ett önskemål var att tjänsten ska kunna leverera dokumentation kring “meta-data”, det vill säga data kring till exempel min-/maxvärden i ett fält eller olika restriktioner. Detta för att man i andra skeden än i tjänsten ska veta hur dessa fält och funktioner fungerar.

Vi kan genom detta analysera och se följande uttryckta behov:

Behov 1: Effektivisera utvecklingsarbetet.

Med effektivisering menas att öka hastigheten som mjukvara utvecklas. Med utvecklingsarbete så menas allt arbete som innefattas i mjukvaruutvecklingsprocessen.

Behov 2: Minska tekniska problem.

Minska antal fel som uppstår under utvecklingsarbetet i förhållande till hur det ser ut idag.

Behov 3: Minska behovet av Angular-kompetens.

24

5.1.2 Funktionalitet

Vid en fråga om behov kring design av gränssnitt så förklarar R1 att myndigheten behöver något som tillåter design och användning av egna komponenter, med ändamålet att förändra både funktionalitet och design. Det bör också gå att anpassa de komponenter som används så att de inte är begränsade till ett antal specifika komponenter eller ett specifikt utseende. R1 uttryckte specifikt ett behov i form av att upprätta valideringar av input och även kunna bygga egna.

Ett funktionellt behov som R1 belyste var att kunna bygga sidor med dynamiskt innehåll som anpassas beroende på vem användaren är och vilka handlingar som den utför. R1 tog upp som ett exempel att kunna anpassa vilka inmatningsfält som ska synas beroende på om de är relevanta för just denna användares åldersgrupp - om vissa fält är relevanta för den specifika åldersgruppen och inte andra.

Vi kan genom detta analysera och se följande uttryckta behov:

Behov 4: Upprätta valideringar för input.

Detta behov innefattar en kontroll som skapas så att en typ av input följer vissa regler innan det skickas in eller sparas, till exempel så kan man kräva 10 siffror i fältet där man ska fylla i sitt telefonnummer.

Behov 5: Skapa egna valideringar.

Möjligheten att kunna skapa egna valideringar som inte redan finns i WebRatio.

Behov 6: Dynamisk anpassning av sidinnehåll

Att förändringar kan ske på sidan utan att sidan måste laddas om. Exempelvis kunna lägga till nya rader i en lista eller att ett input-fält visas eller tas bort beroende på användarens roll eller handlingar.

Behov 7: Skapa egna komponenter.

Detta behov syftar på att kunna skapa helt egna komponenter av kod som används som byggstenar i utvecklingsprocessen av mjukvara i Low-code verktyget.

Behov 8: Modifiera befintliga komponenter.

25

Behov 9: CSS och visuell anpassning.

Möjligheten att förändra webbgränssnittet visuellt och kunna anpassa det till hur man vill att det ska se ut med hjälp av CSS.

5.1.3 Kod

R1 belyser vikten av strukturerad kod, och syftar på att underhåll av koden även utanför Low-code verktyget är nödvändigt. Man måste kunna förstå vad som gör vad i koden och att det är väl uppdelat, att det inte är “ful-kod” som R1 kallar det. Det finns också önskemål i relation till detta att koden kan generera kommentarer i källkoden som beskriver vad det är.

Vi kan genom detta analysera och se följande uttryckta behov:

Behov 10: Läsbar källkod

Läsbar källkod räknas i denna studie som kod som är skriven i ett programmeringsspråk och strukturerat på ett sätt så att det går att följa kodens logik.

5.2 Prototyp och testfall

Prototypen byggdes helt och hållet med utvecklingsverktyget WebRatio och resulterade i en webbapplikation beståendes av 4 sidor. Resultaten är proof-of-concept för hur en produkt enligt en uppdragsbeskrivning kan tänkas se ut och hur den kan byggas i ett Low-code verktyg.

Sida 1 - Logga in (BankId-simulering)

● Möjlighet att välja en användare som du vill simulera att vara inloggad som i en dropdown. ● Logga in - vilket i denna applikation betyder att gå vidare till nästa sida, “mina

ansökningar”, med all nödvändig information om användaren.

26

På figur 2 syns sidans uppbyggnad. Rektangeln i figur 2 till höger är sid-komponenten som innehåller en formulär-komponent. Hexagonen under sid-komponenten är en logik-komponent som innehåller bland annat ett databasanrop som hämtar nödvändiga uppgifter för användaren som valdes.

Figur 2: Till vänster syns inloggningssidan vid körning och till höger syns dess representation i modellerings-språket i Low-code verktyget WebRatio. Pilarna till höger representerar olika typer av navigationsflöden mellan komponenter, särskiljbara efter färg och utseende.

Sida 2 - Mina ansökningar

● Möjlighet att se alla ansökningar som användaren har påbörjat men inte ännu slutfört och skickat in i en lista.

● Möjlighet att se alla ansökningar som är slutförda och inskickade i en lista.

● Möjlighet att påbörja skapandet av en ny ansökan. Detta val tar användaren vidare till sida 3.

27

Till höger i figur 3 syns alla komponenter som bygger upp sidan. Två list-komponenter, en komponent som håller i informationen om användaren och sedan en generisk vy-komponent (param person_id) som endast är till för att fånga upp och skicka vidare användarens id-nummer till informations-komponenten.

Figur 3: Till vänster syns hur sidan ser ut vid körning och till höger syns dess representation i modellerings-språket i Low-code verktyget WebRatio.

Denna sida är ett exempel på hur behov 6 - kunna dynamiskt anpassa en sidas innehåll - kan tillämpas på så sätt att informationen som syns på denna sida presenteras annorlunda beroende på vem du är inloggad som. Användaren kan exempelvis endast se sina egna ansökningar och sin egen information och ingen annans.

Sida 3 - Sökande eller ombud

● Göra ett val mellan att skapa en ansökan som ombud eller som sökande. Detta val tar användaren vidare till sida 4.

28

Figur 4: På denna sida väljer den inloggade användaren ifall den vill skapa en ansökan i form av sökande eller ombud.

Sida 4 - Skapa & redigera ansökan

● Se information om sig själv, automatiskt ifyllt från databasen. (Simulering BankId) ● Möjlighet att fylla i nödvändig information för ansökan.

● Möjlighet att ange obegränsat antal skadeståndsskyldiga (liables) och betalningstillfällen (payments).

● Vid refresh så sparas den information som användaren har angett. ● Vid submit av ansökan så tas användaren vidare till Sida 5

Till vänster i figur 5 så syns hur en del av sidan ser ut vid körning och till höger hur hela sidan är uppbyggd. Till höger i figur 5 så kan det konstateras att det är en sid-komponent med ett flertal formulär-komponenter och två list-komponenter. En generisk vy-komponent används för att fånga inkommande parametrar vid laddning av sidan.

29

Figur 5: Till vänster syns hur sidan för att skapa och redigera ansökningar ser ut vid körning och till höger syns dess representation i modellerings-språket i Low-code verktyget WebRatio.

Detta är den centrala sidan för prototypen och visar på hur behov 4 - kunna upprätta valideringar för input kan uppfyllas. Detta då i formulär-komponenterna, som syns figur 5 till höger, går det att lägga till valideringar för varje fält du upprättar. Exempelvis upprättades en “required-validering” (att detta fält måste fyllas i) för alla fält som kräver ifyllnad. Denna funktionalitet exemplifieras nedan i figur 6 där det syns att formuläret uppmanar användaren att fylla i båda input-fälten efter det att “add”-knappen har klickats på med input-fälten tomma.

30

31

5.2.1 Testfall

Testfallen skapades som ett sätt att komplettera de behov som prototypen inte berörde. Nedan visas testfallen utan bilder. För fullständiga testfall med detaljerad beskrivning, se bilaga. En specifik bilaga-referens som anger vilken sida just det testfallet ligger finns för varje testfall. Analysen av dessa testfall redovisas sedan i kapitel 5.3.

Tabell 2. Testfall 1 - Skapa “required”-validering

ID 1

Behovsreferens 4

Beskrivning Detta testfall är till för att undersöka möjligheten att skapa en “required”-validering för ett formulär.

Process 1. Skapa en formulär-komponent. 2. Lägg till ett inputfält.

3. Lägg till en “required”-validering för inputfältet. 4. Prova submitta formuläret med fältet tomt.

Förväntat resultat: Ett formulär med input-fält som krävs för att få submittas. Vid försök så

ska användaren nekas, om fältet är tomt.

Resultat En valideringsregel (exempelvis “required”) kan läggas till för ett inputfält och kräver således att användaren anger ett värde i det fältet.

32

Tabell 3. Testfall 2 - Find Model Problems

ID 2

Behovsreferens 2

Beskrivning Detta testfall undersöker effekten av en funktion i WebRatio vars syfte är att ge feedback när funktionen körs om man som användare har missat något viktigt. Funktionen ska ge tillbaka “error” och en beskrivning när något stort är fel som stoppar kompilering, och när det är en mindre miss eller ett förslag på en inställning så kommer det upp som “warning”.

Process 1. Skapa två tomma sidor.

2. Lägg till två komponenter i dessa och koppla den ena sidan till den andra för navigation.

3. Kör “Find Model Problems”.

4. Åtgärda problemen och kör funktionen igen.

Förväntat resultat: Funktionen bör hitta 4 error och ge tillbaka dessa som errors i en lista

som måste åtgärdas innan programmet kan kompileras. Efter det åtgärdas och funktionen körs igen så bör det ge tillbaka 1 error och 4 varningar.

Resultat Funktionen återgav errors och varningar enligt förväntad sekvens.

33

Tabell 4. Testfall 3 - CSS

Testfall 3 - CSS

ID 3

Behovsreferens 9

Beskrivning Målet för detta testfall var att se vad som gick att ändra och inte. WebRatio erbjuder en integration med ett CSS dokument där man fritt får referera och göra förändringar till existerande komponenter.

Process 1. Importera en “Web Style”.

2. Öppna tillhörande CSS-fil i WebRatio.

3. Skapa referenser till komponenterna du vill ändra. 4. Gör förändringarna.

5. Iterera mellan steg 3 och 4.

Förväntat resultat: Allt ska gå att ändra på utseendemässigt. Resultat Saker som gick att ändra på:

1. Storlek på text, kort och knapp. 2. Font på text

3. Färg på kort, knappar, banners osv. 4. Placering av kort, text i de flesta fall.

Saker som inte gick att ändra på:

1. Flytta “Sign in” texten

2. Ändra färg på responseffekten när man trycker på Username eller Password som båda var satt till blå som standard.

34

Tabell 5. Testfall 4 - Kommentar för varje komponent

ID 4

Behovsreferens 1

Beskrivning Detta testfall ämnade att på en komponent i WebRatio lämna en kommentar. Denna funktion har som syfte att på ett enkelt sätt lämna kommentarer till sig själv eller till medarbetare kring en inställning eller liknande.

Process 1. Välj en komponent 2. Lägg till en kommentar 3. Läs kommentaren

Förväntat resultat: En kommentar skapas och sparas i en komponent.

Resultat En kommentar lades till i en sid-komponent och kunde läsas när muspekaren hålls över komponenten eller vid nedre delen av verktygets vy efter komponenten valts.

35

5.3 Resultat och analys av utvärderingsintervju

Figur 7: Figuren visar hur respondenterna prioriterade de olika behoven i förhållande till verksamhetens samtliga behov. (1-10, låg till hög prioritet)

Detta kapitel tar upp resultatet och analysen från intervju med Kronofogden med syftet att få deras åsikter, tankar och värderingar om resultatet från arbetet med prototypen och de utförda testfallen. Ovan i figur 7 syns hur respondenterna under utvärderingsintervjun värderade de olika behoven i förhållande till Kronofogdens samtliga behov inom mjukvaruutveckling. Alla 10 behoven som identifierades från behovsintervjuerna i 5.1 ansågs av respondenterna att vara av medelhög till hög prioritet. Detta kan ses som en verifiering av att behovsinsamlingen lyckades få med behov av betydelse som respondenterna kan relatera till.

36

Behov 1: Effektivisera utvecklingsarbetet

Efter en demonstration kring hur en del av prototypen byggts upp var färdig, så ställdes en fråga kring effektivitet. Respondent 1 (R1) svarade att det som visades upp såg väldigt bra ut och att det är många av dessa aspekter som tar lång tid idag. Bidragande aspekter som ökar hastigheten är sättet att arbeta med bland annat datakopplingar och att man har färdiga komponenter som utför olika uppgifter vilket innebär att man ej behöver skapa dessa. Detta beskriver även Richardson & Rymer (2016) och Outsystems (2019) genom att belysa hur Low-code verktyg kan ge en ökad effektivitet i utvecklingsarbetet.

R1 nämner också att det tillåter en kravanalytiker som bygger prototyper att själv modifiera utseendet av prototypen till en högre grad än idag. Idag så måste mer kommunikation ske mellan kravanalytiker och utvecklare där utvecklaren måste få feedback från en kravanalytiker om något i en prototyp måste ändras. Detta faller till viss del in i det Richardson & Rymer rapporterar kring att Low-code verktyg kräver nästan ingen utbildning för att ändå kunna användas effektivt (Richardson & Rymer, 2016). Det leder i detta fall till att en kravanalytiker kan jobba på prototypen utan större problem. Ett senare konstaterande innefattar dock att man ändå i nuläget nog måste ha med sig en utvecklare för att sköta vissa logiska inställningar som inte är helt uppenbara för någon utan utbildning i verktyget.

Respondent 2 (R2), IT-arkitekt på Kronofogden, håller med om att det ser bra ut, men nämner att ett verktyg där man kan bygga på det visuella först och sedan ha utvecklare beröra det logiska efteråt hade varit optimalt, “Börja med ‘What You See Is What You Get’-biten” - R2. R1 håller med om att det hade varit det bästa. “Men det här är absolut ett steg i rätt riktning” - R1.

En följdfråga tog upp om de ansåg att något stack ut som extra bra eller dåligt av det de nu sett. R1 tog upp att det ser generellt väldigt bra ut men att det kan vara så att det finns saker man inte kan göra när man gör en applikation på det här sättet. Då vill man ha möjligheten att lägga till egen kod. Detta är en linje som tas upp av flera artiklar, de beskriver hur anpassningsförmågan kan bli ett problem när man använder en Low-code plattform (Richardson & Rymer, 2015; Fallouh, 2017; Stangarone, 2019; Zola, 2017).

37

det av båda respondenterna att det borde vara något som är relativt lätt men också värdefullt för tillverkaren att implementera. Särskilt med tanke på det som den nuvarande designen och funktionaliteten av verktyget redan innefattar.

Behov 2: Minska tekniska problem

Efter demonstrationen av hur prototypen byggdes så ställdes en fråga kring hur respondenterna ser på hur detta sätt att arbeta löser deras tekniska problem. R2 säger att det beror på till hur stor grad verktyget erbjuder existerande funktionalitet som uppfyller deras behov. Ju större grad det finns funktionalitet de kan använda sig utav ju mindre tekniska problem blir det från egna komponenter, förutsatt att verktyget är buggfritt.

R1 håller med och tillägger att om de skapar egna komponenter så är de själva ansvariga för att det fungerar, men om det är komponenter som fler använder så blir det fler som testar en produkt. “Då

hittar du fler buggar och bygger en bättre produkt” - R1.

Vid genomgång av testfall 2, som testar användningen av en felsökningsfunktion hos verktyget som kallas “find model problem”, så poängterade båda respondenterna att detta är en typ av funktionalitet som är väldigt användbar i arbetet mot att minska tekniska fel som kan uppstå under utvecklingsarbetet. R1 påpekar att “Ja, som utvecklare älskar jag ju sånt där, för då undviker jag

att missa grejer. Absolut.”.

Just denna funktionalitet som uppvisades jämfördes med hur de arbetar idag och hur exempelvis Javas kompilator fungerar med att ge varningar om något gjorts fel. Men R1 tog upp poängen att “find model problem”-funktionaliteten “ligger ett snäpp högre”, det vill säga höjer nivån på felsökningen än hos exempelvis en java-kompilator. Istället för att belysa kompileringsfel så är det större fokus på fel i modelleringen, “bra att ha saker” och hur det hela hänger ihop. R1 anser att en funktionalitet som “find model problem” är ett nödvändigt villkor för användandet av verktyget, för annars finns en risk att utvecklaren lämnas frågande om vad som gick fel vid körning om något gick fel. R2 instämmer och kallar denna funktionalitet för en “hygienfaktor”.

Behov 3: Minska behovet av Angular-kompetens

38

utvecklare som vet hur man bygger upp sidor i Angular “som blir bra och inte trasslig kod” -R1. De har flera exempel där resultatet inte blivit så bra för att man valt fel teknik. “Så att det här

minskar ju det beroendet” -R1. Detta kan relateras till det som Richardson & Rymer nämner kring

att Low-code kan användas på ett effektivt sätt även utan utbildning, i detta fall utan att kunna Angular (Richardson & Rymer, 2016).

Behov 4: Upprätta valideringar för input-fält

Efter uppvisning av testfall 1 så svarade R1 att det verkar finnas potential men att det saknades några viktiga punkter, till frågan om det uppfyller deras behov kring valideringar så svarade R1:

“Till viss del, det va ju det där med att bygga egna validatorer”

Det R1 syftar på är det starkt kopplade behov 5 - skapa egna valideringar. Denna respons faller återigen i linje med artiklarna om risken för begränsad anpassningsbarhet, olika plattformar har olika ramar för funktionalitet (Richardson & Rymer, 2015; Fallouh, 2017; Stangarone, 2019; Zola, 2017). Om inte möjligheten finns att skapa egna komponenter så är man bunden till vad just den Low-code plattform man valt erbjuder för funktionalitet.

R1 påpekade även att det såg väldigt lovande ut med den nuvarande möjligheten att skapa validering baserat på reguljära uttryck. R1 oroade sig samtidigt för risken att få prestandaproblem vid användning av långa reguljära uttryck, då detta var något som R1 ansåg var vanligt förekommande.

Behov 6: Dynamisk anpassning av sidinnehåll

Uppvisningen av prototypen visade på hur innehållet på sidan för ansökan ser olika ut beroende på om du är sökande eller ombud. Utöver det visades även hur listan för skadeståndsskyldiga uppdateras dynamiskt i runtime, utan att sidan behövde laddas om. R1 påpekade en möjlig problematik gällande hur mycket av prototypens sidor som kan anpassas dynamiskt. Till exempel så diskuterades det om det skulle gå att ändra ett input-fält mellan två olika lägen i runtime baserat på användarens handlingar. Men denna funktionalitet stöds ej av verktyget.

R1 lade även till ett annat exempel på dynamiskt innehåll: “Man kan ju tänka sig att man har en

39

Denna typ av dynamisk funktionalitet var dock inte implementerad i prototypen i dagsläget och svaret på frågan ifall det är möjligt är oklar. Med hänvisning till föregående citat så lade R1 även till: “Det skulle inte funka i våra externa tjänster om det inte gick att göra detta som vi pratat om”. Detta gör denna typ av dynamiskt innehåll viktigt att ta reda på om det stöds i verktyget eller inte.

Behov 9: CSS och visuell anpassning

Då resultatet från testfall 3 visade att några av komponenterna gick att anpassa med CSS medans andra inte gick, så gjorde R1 en jämförelse mellan användning av elementhus och att låta en arkitekt rita ett hus och bygga den från grunden. Med elementhus så förloras en del av anpassningsförmågan men det innebär också ett lägre pris, medans om man anlitar en arkitekt så blir det precis tvärtom. Även om det finns en begränsning i form av visuell anpassning i WebRatio så kan det alltså vara en förbättring i arbetsprocessen om det medför tillräckliga besparingar. Precis som med behov 1 och 4 så belystes här en brist med möjligheten att anpassa det man skapar (Richardson & Rymer, 2015; Fallouh, 2017; Stangarone, 2019; Zola, 2017).

Behov 10: Läsbar källkod

40

6. Diskussion

Resultatet av denna studie kan visa på vis positivt inverkan på effektiviteten avseende tekniska problem som kan reduceras och behovet av Angular-kompetens minskas. Verktyget erbjuder ett antal färdiga komponenter vilket innebär att användaren själv ej behöver skapa dessa. Detta leder till reduktion av tekniska problem då komponenterna med större sannolikhet är buggfria och redo att användas. Det innebär också mindre arbete i Angular och att mindre generell programmeringskunskap krävs i mjukvaruutvecklingsarbetet.

En viktig aspekt var förmågan att kunna skapa ett formulär med validerade inputfält. Detta kunde göras, men är starkt kopplat till behov 5 - att kunna skapa egna valideringar. När valideringar som kan upprättas finns i ett begränsat utbud, så hänger det faktiska värdet på hur väl de kan uppfylla det specifika uppdragets behov. Detta faktum understryker vikten av förmågan att kunna skapa egna valideringar. Att kunna anpassa befintliga komponenters visuella utseende med CSS var en uppskattad funktionalitet. Det konstaterades att det gick att göra i en något begränsad omfattning. Detta var dock något som respondenterna i studien tyckte var en avvägning som kan vara värd att göra med hänsyn till de potentiella vinsterna i effektivitet.

I en annan studie så tas det upp farhågor och förväntningar på Low-code från perspektivet av professionella utvecklare som hade liten till ingen erfarenhet av att arbeta med Low-code (Baldwin & Kopkin, 2016). De nämner till exempel att två av deras respondenter gillade idén av automatiskt genererad kod då det skulle minska mängden fel orsakade av mänsklig faktor. Det är något som respondenterna i vår studie höll med om. Om komponenter redan är skapade så undviker de många tekniska problem då det jobbet redan är gjort, dock så hänger det på att verktyget erbjuder komponenter till en tillräcklig nivå för att uppfylla behoven. Ett annat ämne de tar upp handlar om att koden kan bli svår att läsa och förstå enligt en av deras respondenter. Detta går dock i en annan riktning i jämförelse men vår studies resultat, då en av respondenterna kallar källkoden för “snygg

och välformaterad”-R1.

41

förbättras i framtiden om verktyget inför stöd till användaren att skapa egna valideringar och komponenter. Det går också att tänka sig att verktyget utökar det befintliga utbudet, detta alternativ gör det dock mer svårbedömt huruvida det i ett senare skede kommer att uppfylla Kronofogdens behov. Detta då det i slutändan, med ett sådant tillvägagångssätt, ligger helt på leverantören att avgöra vilka typer av komponenter och valideringar som införs.

Respondenterna identifierade en förbättringsmöjlighet i hur arbetsflödet såg ut i verktyget. De hade gärna sett att det går att göra det visuella arbetet först - mer separerat från den bakomliggande logiken. Detta hade gjort det lättare att i verktyget snabbt ta fram en prototyp att visa upp. Men denna typ av arbetsflöde är svårt att uppnå i verktyget, då det ofta krävs förberedelser i den bakomliggande logiken innan artefakten kan köras. Detta varierar beroende på vilka komponenter som används.

För två av behoven, behov 6 (Dynamiskt innehåll) och behov 10 (Läsbar kod) så fanns det begränsat material för respondenterna att utgå ifrån i jämförelse med de övriga behoven som testades. Den typ av dynamisk funktionalitet som visades upp stämde inte helt överens med behovet. En mer exakt definition av vilken typ av dynamiskt innehåll som efterfrågas hade troligtvis varit bra att klargöra vid behovsinsamlingen. Det uppkom även spekulationer kring om den form av dynamiskt innehåll som visades upp krävde en backend för att fungera, vilket gör det till en mindre attraktiv lösning. Kring behov 10 så kunde respondenterna ge en ytlig bedömning kring hur några sektioner av källkoden såg ut. Men att värdera källkoden på djupet var svårt för respondenterna, vilket innebär att behovet behöver undersökas ytterligare av bedömare med tillräcklig kompetens inom området.

Verktyget WebRatio som användes i vår studie var en betaversion. Detta var något som hade en påverkan på utbudet av funktionalitet men också hur snabbt och enkelt vi kunde arbeta i verktyget. Detta då användargränssnittet och funktioner många gånger var halvfärdiga eller inte helt fungerande. Dock så bör man tänka på att även ett officiellt färdigställt verktyg även det kan ha problem i användarupplevelsen och funktionaliteter.

42

Vid presentation av prototypen och testfallen för respondenterna så kan vi konstatera att det ofta innefattade något som kan liknas med en snabbkurs i verktyget, innan vi kunde samla in deras åsikter om det som visades upp. Det upplevdes av oss att denna del av arbetet underlättades med det faktum att arbetet i verktyget sker med grafiska modeller, vilket stöds av teorin att visuella gränssnitt kan underlätta förståelsen för programmering (Tharp, 1984). Hela prototypen som byggdes kunde visas upp med en relativt komprimerad modell, vilket är underlättade vid beskrivning av hur olika delar hänger samman. Dock hade denna aspekt en baksida i det att när mer djupt tekniskt bakomliggande frågor dök upp, så var det svårare för oss att svara på, då arbetet skedde isolerat från koden som producerades i bakgrunden.

43

7. Slutsats

Syftet med denna studie var att undersöka vilka effekter som Low-code får hos en statlig myndighet genom utvecklande och utvärdering av en prototyp och testfall. Denna studie bidrar till ökad förståelse och en nyanserad bild av vad implementering av Low-code innebär i praktiken för en statlig myndighet. Efter att ha identifierat ett antal behov och kopplat dessa till aspekter av ett specifikt Low-code verktyg så har ett antal effekter hittats.

Resultaten visar tendenser på att utvecklingsarbetet vid programmering kan effektiviseras då tillvägagångssättet och andelen manuell programmering minskar samt användning av färdiga komponenter kan skynda på arbetet. Det förändrade arbetssättet kan potentiellt leda till minskat beroenden av andra verktyg och/eller manuella processer. I arbetet som utförs i ett Low-code verktyg, så ses en möjlighet till att exempelvis systemdokumentation kan ske mer automatiskt än om utvecklingen ägde rum i en text-editor. Då utvecklingen sker i grafiska modeller, vilket är lättare att ta till sig än kod, så skulle kommunikation gällande utvecklingsarbetet kunna antas ske enklare med personer utan programmeringskunskap och därmed undvika potentiella missförstånd. Studien pekar på att respondenterna upplever ett minskat antal tekniska problem på grund av det ändrade arbetssättet och att verktyget har funktioner som hjälper användaren att hitta eventuella problem. Beroendet av Angular-kompetens verkar minska, men då koden som genereras är i bland annat Angular så försvinner det inte helt, särskilt inte om avsikten är att kunna skapa eller felsöka egna komponenter i framtiden.

Förmågan att upprätta valideringar för input-fält är konstaterad men dess praktiska värde bygger på att utbudet av valideringstyper stämmer överens med vad verksamheten efterfrågar. Vad gäller anpassning av valideringar och komponenter så blir slutsatsen att en statlig myndighet som Kronofogden idag skulle bli begränsad vid användning av verktyget WebRatio.