INOM
EXAMENSARBETE DATATEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2016,
Prototyp för identifiering av teknisk skuld inom Product Lifecycle Management
CHRISTIAN GAUFFIN MARCUS JONSSON
KTH
SKOLAN FÖR INFORMATIONS- OCH KOMMUNIKATIONSTEKNIK
ABSTRACT
Technical debt is a well known term within software development, but has not yet been imple- mented outside of software development. Because of this, there is no knowledge whether that is possible or not. This thesis investigates how technical debt can be extended to and be iden- tified within a software system for handling Product Lifecycle Management. The purpose of the thesis is to present a prototype, called the ITS-prototype, which shows that it is possible to identify technical debt within Product Lifecycle Management. The thesis has qualitative characteristics and were conducted as a case study. In order to verify that the implementation is correct, two evaluation criterias were established. The first criteria, measuring the degree of coverage, saying that the ITS-prototype should be able to identify 100% of the technical debt defined by each rule. The second criteria consists of an interview with a technical expert on Product Lifecycle Management where the prototype’s underlying method is evaluated.
The ITS-prototype together with the results of the evaluation shows that technical debt is possible to be implemented and identified in a software system for handling Product Life- cycle Management. The rule-driven implementation that is used, has shown effective and the authors suggests that the development of the ITS-prototype continues in order to better use conveniences that exist within a Product Lifecycle Management-system.
Keywords: quality, rules, static analysis, quantification
ABSTRACT
Teknisk skuld är ett vedertaget begrepp inom mjukvaruutveckling men har ännu inte imple- menterats utanför mjukvara. Således finns det ingen kunskap om huruvida det är praktiskt möjligt att göra detta eller inte. I detta arbete undersöktes om konceptet teknisk skuld kan implementeras i ett mjukvarusystem för hantering av Product Lifecycle Management. Syftet med arbetet är att visa att teknisk skuld kan implementeras inom Product Lifecycle Ma- nagement genom att presentera en prototyp för identifiering av teknisk skuld inom Product Lifecycle Management, kallad ITS-prototypen. Arbetet är av kvalitativ karaktär och genom- fördes som en fallstudie. För att verifiera att implementationen är korrekt upprättades två ut- värderingskriterier. Det första mäter prototypens täckningsgrad och säger att ITS-prototypen ska kunna identifiera 100% teknisk skuld definierad av varje regel. Det andra kriteriet består av en utvärderingsintervju med en teknisk expert på Product Lifecycle Management, där prototypens underliggande metod utvärderas. ITS-prototypen tillsammans med resultaten av utvärderingen visar att teknisk skuld är möjlig att implementera i ett mjukvarusystem för hantering av Product Lifecycle Management. Den regeldrivna implementation som använts i ITS-prototypen är effektiv och författarna föreslår att utvecklandet av prototypen fortsätter för att bättre kunna nyttja fördelar i ett PLM-system.
Nyckelord: kvalitet, regler, statisk analys, kvantifiering
Innehåll
1 Introduktion ... 1
1.1 Bakgrund ... 1
1.2 Problem ... 2
1.3 Frågeställning ... 2
1.4 Syfte... 2
1.5 Mål ... 3
1.6 Fördelar, etik och hållbarhet ... 3
1.7 Metoder ... 3
1.8 Uppdraget ... 4
1.9 Målgrupp... 4
1.10 Avgränsningar ... 4
1.11 Disposition ... 5
2 Utökad bakgrund ... 7
2.1 Produktkvalitet ... 7
2.2 Teknisk skuld ... 8
2.2.1 Typer av teknisk skuld ... 9
2.2.2 Teknisk skuld utanför mjukvara... 10
2.2.3 Kategorier för teknisk skuld i PLM ... 10
2.2.4 Kvantifiering av teknisk skuld och ränta... 11
2.3 Product Lifecycle Management ... 13
2.4 Statisk kod analys... 14
2.4.1 Regler ... 14
2.4.2 Statisk kodanalys för identifiering av teknisk skuld... 14
2.5 TechniaTranscat... 15
2.5.1 3DExperience ... 15
2.5.2 TechniaTranscat’s databasmodell ... 15
2.6 Bakgrundens återkoppling i arbetet ... 16
3 Metod ... 17
3.1 Forskningsstrategi ... 17
3.2 Forskningsfaser ... 18
3.2.1 Fas 1: Litteraturstudie ... 18
3.2.2 Fas 2: Modellering... 19
3.2.3 Fas 3: Implementation ... 19
3.2.4 Fas 4: Testning ... 19
3.2.5 Fas 5: Utvärdering ... 19
3.3 Forskningstyp ... 20
3.3.1 Kvalitativ forskning ... 20
3.3.2 Induktiv slutledning... 21
3.3.3 Den kvalitativa forskningsprocessen ... 21
3.3.4 Lämplighet för kvantitativ forskning ... 22
3.4 Fallstudie ... 23
3.5 Utvärderingskriterier ... 23
3.6 Forskningsinstrument... 24
3.7 Urvalsmetod ... 25
3.8 Erfarenheter ... 25
4 ITS-prototypen ... 27
4.1 Kravspecifikation ... 27
4.2 Regelstruktur ... 27
4.2.1 Regeltypen RULE ... 29
4.2.2 Regeltypen Single Rule ... 29
4.2.3 Regeltypen Super Rule... 29
4.2.4 Regelmetoder ... 30
4.3 Implementerade regler ... 30
4.4 Arkitektur för ITS-prototypen ... 31
4.4.1 Hantering av regler... 31
4.4.2 Motorn ... 32
4.5 Kvantifiering ... 33
4.6 Persistering av en teknisk skuld ... 34
5 Utvärdering av ITS-prototypen... 35
5.1 Resultat från utvärderingskriteriet täckningsgrad ... 35
5.2 Resultat från utvärderingsintervju ... 36
6 Diskussion ... 39
6.1 Utvärderingen av ITS-prototypen ... 39
6.2 Kvantifiering ... 40
6.3 Kvalitet ... 40
6.4 Etik ... 41
6.5 Validitetshot... 41
7 Slutsats ... 43
7.1 Arbetets bidrag till forskningen ... 43
7.2 Framtida arbete ... 43
7.3 Slutord ... 44
Referenser... 45
Appendix A: Generell regelmetod ... 47
1 Introduktion
I dagens produktdrivna samhälle är det många företag som vill kontrollera utveckling av och få överblick över sina produkter och dess komponenter. En strategi kallad Product Lifecycle Management (PLM) (Siemens PLM, 2016) har blivit allt mer använd för detta ändamål. I strategin innefattas ofta ett mjukvarusystem som ger användare möjligheten att lagra all information rörande produkterna (Saaksvuori & Immonen, 2008, s. 18).
I mjukvarusystem för hantering av PLM hanteras olika produkters, tillsammans med dess beståndsdelar, livscykler. Det innebär att information om produktens alla stadier lagras i systemet, från första tanke till dess att produkten pensioneras och går i graven (Stark, 2015;
Saaksvuori & Immonen, 2008). Det är i princip obegränsat vilka kategorier av produkter som kan behandlas i ett mjukvarusystem för hantering av PLM. Det kan vara allt ifrån produkter med ett fåtal komponenter som drycker, kemiska komponenter eller kläder, till produkter bestående av betydligt fler komponenter som flygplan eller bilar (Stark, 2015, s. 24).
1.1 Bakgrund
På en marknad med allt hårdare konkurrens blir det viktigare för företag att kunna leverera produkter av hög kvalitet (Bergman & Klefsjö, 2001, s. 9). Inom befintliga mjukvarusystem för hantering av PLM finns det dock ingen utarbetad strategi för att identifiera låg kvalitet i form av defekter och brister för produkter som behandlas i systemet. Inom mjukvara kan brister i mjukvarans kvalitet representeras av begreppet teknisk skuld (Wolff & Johann, 2015). Teknisk skuld beskrivs i The wycach portfolio management system (Cunningham, 1992) som en metafor till monetär skuld inom finansvärlden, där en låntagare får en tillfällig fördel i form av pengar, men förbinds till att i framtiden återbetala denna fördel.
Teknisk skuld har utvecklats till ett välanvänt koncept inom mjukvaruvärlden där det används för att representera bristande kvalitet som icke-optimala mjukvarulösningar eller brister i mjukvaran. En teknisk skuld kan till exempel kan vara onödigt komplexa kodstycken, dålig systemarkitektur eller bristande testning av koden (Li, Avgeriou & Liang, 2015). Till skillnad från den monetära skulden, vars värde består av pengar, har teknisk skuld ett värde i form av den tid det tar göra om mjukvaran till att bestå av optimala mjukvarulösningar och vara fri från brister.
När mjukvara försatt i skuld ska utökas, sker det utifrån en redan icke-optimal lösning, vilket leder till att ny funktionalitet blir svårare att implementera och också den icke-optimal (Wolff
& Johann, 2015; Hinsen, 2015). Det resulterar i mjukvara som det finns buggar i, har väldigt långsam körningstid eller som har andra problem. Det kan dock finnas vissa specifika tillfällen
då det, liksom att det för ett företag kan vara strategiskt rätt att utöka kassan genom att låna pengar av en bank, kan vara fördelaktigt att försätta mjukvara i en begränsad teknisk skuld (Ampatzoglou, Ampatzoglou, Chatzigeorgiou & Avgeriou, 2015; Hinsen, 2015; Lim, Taksande & Seaman, 2012). Fördelar ett företag kan få genom att göra det kan vara ett tidigare leveransdatum eller att vara först ut på marknaden med en ny funktion (Hinsen, 2015; Lim m. fl., 2012). Trots att det vid vissa tillfällen kan vara fördelaktigt med teknisk skuld är det oftast inte fallet, och företag kan vinna på att övervaka och underhålla den tekniska skulden. Företag kan vinna tid genom att undvika framtida potentiella fällor som stor komplexitet, dålig prestanda eller svår underhållbarhet eller få ökade intäkter genom nöjdare kunder. (Lim m. fl., 2012)
Konceptet teknisk skuld finns ännu endast applicerat inom mjukvaruvärlden. Företag som använder mjukvarusystem för hantering av PLM har insett värdet i att utöka konceptet teknisk skuld till att innefatta området PLM och har visat intresse för mjukvara som stödjer detta. Teoretiska undersökningar har kommit fram till att konceptet är lika applicerbart på områden utanför som inom mjukvaruvärlden (Hinsen, 2015) och Hansson och Hognesius (2015) ger konkreta förslag på hur teknisk skuld kan implementeras i mjukvarusystem för hantering av PLM.
1.2 Problem
Problemet är att teknisk skuld ännu inte har implementerats utanför mjukvaruvärlden, och det finns således ingen kunskap om huruvida det är praktiskt möjligt att göra detta i ett mjukvarusystem för hantering av PLM.
1.3 Frågeställning
Kan konceptet teknisk skuld implementeras i ett mjukvarusystem för hantering av PLM?
1.4 Syfte
Syftet med arbetet är att visa att teknisk skuld kan implementeras inom Product Life- cycle Management genom att presentera ITS-prototypen (Identifiering av Teknisk Skuld- prototypen), en prototyp som visar att det är möjligt att identifiera teknisk skuld i ett mjukvarusystem för hantering av PLM.
1.5 Mål
Målet med projektet är ge en ökad förståelse för och större kunskap om vad konceptet teknisk skuld kan användas till. Genom att visa att teknisk skuld kan implementeras i ett mjukvarusystem för hantering av PLM visas implicit att det är möjligt att utöka konceptet till att innefatta ytterligare områden utanför mjukvara, vilket öppnar upp området för fortsatt forskning.
1.6 Fördelar, etik och hållbarhet
En av fördelarna med att spåra teknisk skuld, som tidigare varit osynlig men ändock all- tid funnits genom produkters livscykler, i ett mjukvarusystem för hantering av PLM är att användare av systemet kan spara in arbete och onödig produktion. Det leder till högre mar- ginaler, lägre produktionskostnader och mindre spill. Om skulden som ackumuleras under hela produktens livscykel i systemet övervakas samt underhålls kan den hållas på en nivå som företaget anser godtagbar, vilket kan påverka företagets ekonomi positivt.
Användarna av mjukvarusystem för hantering av PLM är många, och utvecklar produkter inom områden som innefattar allt från skepp till kläder och dylikt. Genom att spåra tek- nisk skuld relaterad till användning av material och delkomponenter kan onödig produktion undvikas och svinn minskas, vilket ger en positiv påverkan på miljön.
1.7 Metoder
Det här arbetet har utförts med en kvalitativ forskningsmetod och en induktiv ansats. Pro- jektet utfördes i form av en fallstudie där ett specifikt fall valdes ut för området. Det fall som valdes ut att studeras i studien var hur teknisk skuld kan implementeras i TechniaTranscat’s mjukvarusystem för hantering av PLM. Valet av en kvalitativ forskningsmetod passade väl i och med att endast ett fall valdes ut (Thurén, 2007, s. 112) samt att det var en mjukva- rulösning som skulle utvecklas (Håkansson, 2013). Arbetet var induktivt då det utgick ifrån empirisk information där generella slutledningar drogs (Backman, 2008, s. 54). För att få struktur på arbetet delades projektet upp i fem forskningsfaser. Den inledande fasen bestod i en litteraturstudie, som under arbetets gång utökades vid behov. För evaluering av ITS- prototypen användes två utvärderingskriterier. Det första för att verifiera att teknisk skuld faktiskt identifieras och det andra för den metod som ligger till grund för implementationen av ITS-prototypen.
1.8 Uppdraget
Projektet utförs på uppdrag av företaget TechniaTranscat (TechniaTranscat, 2016), vilka tillhandahåller ett mjukvarusystem för hantering av PLM. I systemet hanteras produkter av olika slag, allt från lyftkranar till kläder. All information om produkten och dess hela livscykel är möjlig att lagra i systemet. För TechniaTranscats kunder är kvalitet och framför allt möjlighet att spåra bristande kvalitet av hög prioritet. TechniaTranscat är därför intresserade av att introducera konceptet teknisk skuld i systemet för att identifiera och visualisera var brister finns samt hur mycket tid som behöver läggas ned på att åtgärda dessa.
1.9 Målgrupp
Den huvudsakliga målgruppen för detta arbete är den del av industrin som arbetar med PLM eftersom teknisk skuld är ett nytt koncept inom området som kan användas för att spåra defekter i produkter. Främst berörs de företag som tillhandahåller mjukvarusystem för hantering av PLM och i synnerhet företaget TechniaTranscat vilket är företaget arbetet utfördes på. I och med att prototypen som utvecklas är anpassad till TechniaTranscats system drar de fördelar av detta på grund av att de får grunden till, och nyckeldelarna av, ett nytt verktyg.
En annan målgrupp för detta arbete är de inom forskningsvärlden som har intresse för kon- ceptet teknisk skuld i och med att arbetet öppnar upp för att undersöka andra områden teknisk skuld kan utökas till och implementeras i.
1.10 Avgränsningar
Detta arbete avgränsas till att endast beröra hur teknisk skuld kan identifieras, kvantifieras och visualiseras i ett av TechniaTranscats mjukvarusystem för hantering av PLM. Två olika databaser kommer användas för att testa och evaluera prototypen. Den ena är en testdata- bas framtagen enbart för detta projektet och den andra är en kunddatabas, vars företag av sekretesskäl inte kommer nämnas vid namn. Kunddatabasen innehåller data från produkt- framtagning. Testdatabasen innehåller inte data hämtad från en verklig databas, utan är endast skapad för ändamålet att testa prototypen.
En handfull regler för att identifiera teknisk skuld kommer att implementeras. Dessa regler ska endast beröra teknisk skuld som är möjlig att finna i databaserna. Anledningen till att arbetet avgränsas till endast ett mjukvarusystem för hantering av PLM är att examensarbetet utförs på företaget TechniaTranscat som tillhandahåller gällande system. Antalet implementerade
regler kommer sig av arbetets begränsade tidsomfattning. För identifiering och visualisering av teknisk skuld utvecklas ITS-prototypen, som består av två delar; en regelsamling och en regelmotor. Regelmotorn ska applicera reglerna på relevanta databasobjekt för att identifiera teknisk skuld. En datamodell för persistering av funnen teknisk skuld ska skapas. En lämplig metod för kvantifiering av teknisk skuld ska upprättas.
1.11 Disposition
I detta delkapitel presenteras den övergripande strukturen för arbetet, samt vad varje kapitel behandlar.
I kapitel Utökad bakgrund presenteras relevant information för problemet rapporten be- handlar. Där ges definitioner på vad kvalitet anses vara för produkter, vad teknisk skuld är inom området mjukvaruutveckling och utförd forskning på vad teknisk skuld kan vara ut- anför mjukvara. Vidare ges definitioner på vad PLM är och används till. Avslutningsvis ges information relaterad till det angreppssätt med vilket problemet angreps, en kort presenta- tion av företaget där arbetet ägde rum samt hur all denna information har varit viktigt i arbetets utförande.
I kapitel Metod presenteras de vetenskapliga metoder som använts i arbetet. Här presen- teras de forskingsfaser arbetet utförs med, vilken forskningsstrategi, forskningsinstrument och forskningsmetod som använts. I kapitlet presenteras också de utvärderingskriterier, med vilka den slutgiltiga versionen av ITS-prototypen utvärderades. Slutligen listas författarnas erfarenhet från det utförde arbetet.
I kapitel ITS-prototypenpresenteras ITS-prototypen tillsammans med de metoder och stra- tegier som ligger till grund för prototypen. Här redovisas också datamodellen för och de regler som implementerats. Avslutningsvis visas hur prototypen sparar och kvantifierar tek- nisk skuld.
I kapitel Utvärdering av ITS-prototypen redovisas resultaten från utvärderingen av ITS- prototypen.
I kapitel Diskussion framförs diskussioner kring resultaten av utvärderingen av ITS- prototypen, den metod som använts för kvantifiering av teknisk skuld och prototypens på- verkan på produktkvalitet. Här presenteras de hot som finns mot validiteten i arbetet.
I kapitel Slutsats ges de slutgiltiga reflektionerna kring arbetet. Här ges arbetets bidrag till forskningen samt avslutningsvis ger förslag för framtida forskning.
2 Utökad bakgrund
I det här kapitlet presenteras all relevant bakgrundsinformation detta arbete. Delkapitel 2.1 ger information rörande vad kvalitet är och varför det är viktigt för produktutveckling. I delkapitel 2.2 introduceras begreppet teknisk skuld, vad det är inom mjukvara, hur den kan kvantifieras och vilka typer som finns. Vidare presenteras den forskning som gjorts kring vad begreppet är utanför mjukvara. I delkapitel 2.3 presenteras sedan vad Product Lifecycle Management är och vad en produkts livscykel består av. Sedan presenteras statisk kodanalys i delkapitel 2.4, information om företaget ges i delkapitel 2.5 och avslutningsvis beskrivs hur informationen given i detta kapitel återkopplas i arbetet i delkapitel 2.6.
2.1 Produktkvalitet
Produkters kvalitet är viktigt för företags fortlevnad då användare av produkter i dagens konkurrenskraftiga samhälle kräver hög kvalitet (Bergman & Klefsjö, 2001, s. 9). Det finns många definitioner på vad kvalitet är. Juran och Godfrey (1999) presenterar två definitioner med olika synsätt på kvalitet. Den första bygger på produktens högsta kvalitetsnivå och den andra bygger på produktens lägsta kvalitetsnivå.
Den första definitionen Juran och Godfrey ger säger att kvalitet innebär de egenskaper hos en produkt som uppfyller kundens behov och därför också tillfredsställer kunden. När kvalitet av denna definition ökar för en produkt är det resultatet av ett försök att få upp försäljningen av produkten. Med denna definition medför hög kvalitet främst en högre intäkt för företaget.
Kostnader knutna till att höja produktens kvalitet med avseende på detta synsätt kan ses som kostnader för att höja produktens högsta kvalitetsnivå i och med att dessa kostnader resulterar i nya funktioner som kan uppfylla ytterligare behov hos kunden. (Juran & Godfrey, 1999, s. 7)
Juran och Godfrey’s andra definition säger att kvalitet innebär avsaknad av brister. Att en produkt inte har några brister innebär att omarbetningar inte är nödvändiga. Produkten kommer heller inte att ha några fel som upptäcks när den nyttjas av kunder, vilket innebär lägre kostnader kopplade till missnöjda kunder, såsom klagomål och icke tillfredsställda kun- der. Med denna definition medför hög kvalitet främst lägre kostnader för företaget. Kostnader knutna till att höja produktens kvalitet med avseende på detta synsätt kan ses som kostna- der för att höja produktens lägsta kvalitetsnivå, då kostnader då resulterar i färre brister hos produkten. (Juran & Godfrey, 1999, s. 8)
Enligt Juran och Godfrey (1999) krävs det större investeringar av ett företag för att förbättra produktens kvalitet utifrån deras första definition av hög kvalitet. Det är därför fördelaktigt
för ett företag att förbättra produktens kvalitet enligt den andra definitionen, alltså att försöka eliminera låg kvalitet hos produkten och på så sätt höja produktens lägsta kvalitets- nivå.
Bergman och Klefsjö (2001) definierar kostnaden av låg kvalitet som kostnaden av att produ- cera varor av låg kvalitet. Denna kostnad kan vara svår att upptäcka från företagets synvinkel då det främst rör sig om indirekta kostnader som uppstår först när produkten når marknaden.
Exempel på sådana kostnader kan vara att en produkts design måste göras om på grund av klagomål från kunder. (Bergman & Klefsjö, 2001, s. 64-65). En annan definition av kostnad för låg kvalitet är kostnaderna som skulle försvinna om produkten inte innehöll några brister (Juran & Godfrey, 1999, s. 10-11). Enligt båda dessa definitioner är kostnaden för låg kvalitet knutet till produktens lägsta kvalitetsnivå.
2.2 Teknisk skuld
Begreppet teknisk skuld introducerades av Cunningham (1992), som beskriver konceptet som:
”Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite”1. Den tekniska skuld koden försätts i är en metafor till den skuld en person försätter sig i då pengar lånas i bankvärlden. Samma tankesätt gällande skuldsättning appliceras med metaforen teknisk skuld på applikationer eller program som skrivits i kod som inte är optimal eller följer de standarder som satts.
Till skillnad från en skuld inom den finansiella världen, finns det inget skrivet kontrakt mellan två parter för teknisk skuld. Programmeraren måste istället själv identifiera när denne försätter koden i skuld, och ingår då i ett kontrakt med ”sitt framtida själv” (Hinsen, 2015).
En oerfaren programmerare kan lätt missa de tillfällen denne försätter koden i skuld med en sub-optimal lösning, och endast se till den kortsiktiga vinsten och därav missa den långsiktiga påverkan.
När en applikation försatts i teknisk skuld tillkommer en ränta (Cunningham, 1992). Räntan är det extra arbete som behöver läggas ned på att till exempel fixa buggar eller implementera ny funktionalitet (Hinsen, 2015) och består alltså i det extra arbete som genereras då koden är sub-optimal, jämfört med arbetet det hade krävt utifrån optimalt skriven kod. Den tekniska skulden ackumuleras genom alla stadier av ett projekt, vilket leder till att den bör övervakas och hanteras kontinuerligt genom alla stadier (Kruchten, Nord & Ozkaya, 2012).
1 ”Att lansera kod för fösta gången, kan liknas med att försättas i skuld. En liten skuld skyndar på utveck- lingen så länge det snabbt betalas tillbaka med en omskrivning”
Likt en finansiell skuld, behöver en teknisk skuld inte nödvändigtvis vara en dålig sak (Hinsen, 2015). Olika orsaker kan justifiera att sätta applikationen i skuld, och det kan i vissa fall till och med vara önskvärt att göra så (Ampatzoglou m. fl., 2015; Hinsen, 2015; Lim m. fl., 2012). Orsaker till att göra det kan vara till exempel inom ett väldigt konkurrenskraftigt område kan det vara värt att ta programmeringsgenvägar i syfte att vara först ut med en produkt, vilket kan ge en stor vinst fram i tiden (Hinsen, 2015). Däremot är det till skillnad från bankvärden orealistiskt att förvänta sig att betala tillbaka all skuld koden försätts i (Ampatzoglou m. fl., 2015). Det gäller dock att vara försiktig med att försätta koden i för stor skuld då utvecklingstakten kommer att minska (Zazworka, Shaw, Shull & Seaman, 2011).
Det är därför viktigt att fortskridande genom utvecklingen hålla koll på, samt underhålla skulden så att den inte växer utom kontroll.
2.2.1 Typer av teknisk skuld
Teknisk skuld kan manifesteras på många olika vis, det kan tillexempel vara en programme- rare som, för att tillfälligt spara tid, inte skriver tester för en nyskriven metod. I och med att metoden inte testas på ett korrekt sätt försätter programmeraren koden i skuld, som måste betalas tillbaka i form av tiden det i framtiden tar att skriva de tester som tillfälligt förbisågs.
Det finns ingen standardiserad klassifiering av teknisk skuld men många har föreslagits. Li m. fl. (2015) har gjort följande klassifiering av de olika typerna:
• Kravskuld innefattar diskrepansen mellan kravspecifikationen och den faktiska syste- mimplementationen. Denna typ av skuld finns om systemimplementations inte uppfyller kravspecifikationen.
• Arkitekturell skuld orsakas av arkitekturella beslut som orsakar brister i den interna kvaliteten. Om klasser får för många beroenden uppstår denna typ av teknisk skuld.
• Designskuld innefattar de tekniska genvägar som tas i den detaljerade designen.
• Kodskuld innefattar sub-optimalt skriven kod som bryter bästa kodpraxis eller regler för hur kod ska skrivas. Exempel på denna typ av teknisk skuld är duplicerad kod och väldigt komplex kod.
• Testskuld innefattar genvägar tagna i testningen, till exempel uteblivna tester.
• Driftsättningsskuld innefattar brister i ett mjukvarusystem, dess byggsystem eller i dess byggprocess. Om driftsättningsprocessen är allt för krånglig uppstår driftsätt- ningsskuld.
• Dokumentationsskuld innefattar otillräcklig, oavslutad eller utdaterad dokumenta- tion i alla aspekter av utvecklingen. Denna typ av skuld finns om koden inte har till-
räckligt med kommentarer.
• Infrastrukturell skuld innefattar icke-optimalt konfigurerade utvecklingsrelaterade artefakter, till exempel processer, teknologier och hjälpmedel.
• Versionshanteringsskuld innefattar de problem som finns i versionshanteringen av kod. Till exempel kan ett projekt ha för många versionsgrenar aktiva samtidigt.
• Defektskuld innefattar defekter, buggar och felaktigheter i systemet.
Det arbete, vilket detta projekt bygger på, utfört av Hansson och Hognesius (2015) bygger på denna klassificering och den mappning de gjorde utgick därifrån. Därmed kommer även detta arbete baseras i denna klassificering.
2.2.2 Teknisk skuld utanför mjukvara
Konceptet teknisk skuld har ännu inte implementerats utanför mjukvara. Hinsen (2015, s.
105) föreslår att det lika väl går att applicera på andra områden. De intervjuer Hansson och Hognesius (2015) genomfört, visar på att sub-optimala lösningar strategiskt används även inom PLM, i produkters livscykler. De manifesteras te.x. i att medvetet välja ett icke optimalt material eller design för att minska tiden till lansering.
För att spåra teknisk skuld inom ett PLM-system kan en uppsättning regler specificeras (Hansson & Hognesius, 2015), på ett liknande sätt som regler används för att statiskt analy- sera kod, vilket beskrivs i kapitel 2.4.
2.2.3 Kategorier för teknisk skuld i PLM
Figur 1: Mappning av teknisk skuld - problemområden och kategorier inom mjukvara Arbetet Hansson och Hognesius (2015) genomförde föreslår en korrelation mellan problem- områden och typer av teknisk skuld. Som kan ses i Figur 1 föreslås att problem inom support,
transport och paketering, och produktion kan ses som infrastrukturell teknisk skuld. Problem med den fysiska produkten kan relateras till kodrelaterad och defekt teknisk skuld. Problem med den produktrelaterade informationen kan jämföras med dokumentationsrelaterad tek- nisk skuld. Problem rörande design och krav kan kopplas till kravrelaterad och designrela- terad teknisk skuld. Problem med förordningar kan anses orsakas av kravrelaterad teknisk skuld. Hansson och Hognesius (2015) ger följande exempel på problem som kan uppstå inom de olika områdena under en produkts livscykel:
Fysiska produkteninnefattar problem som till exempel läckande packningar på grund av för mycket slipning under produktion eller ett mönsterkort som fattar eld av överhettning.
Support innefattar alla problem kopplade till support rörande produkten.
Transport och paketering innefattar problem som exempelvis kan vara logistik och pack- ning av produkter när lager inte kan ta emot inkommande leveranser, eller material som inte är korrekt placerat på hyllor, och därav skapar problem när det materialet ska hämtas.
Produktioninnefattar alla problem som är kopplade till förverkligandet av produkten, vilket kan vara till exempel att en viss komponent har slutat tillverkats, eller att en leverantör har gått i konkurs.
Produktrelaterad informationinnefattar problem kopplade till all information för produk- ten. Till exempel fel i manualen, som leder till att manualen måste skrivas om och på nytt skrivas ut.
Design och krav innefattar alla problem där produkten uppfyller alla krav, men ändå inte fungerar korrekt.
Förordningarberör problem som externa krav på produkten som till exempel att manualen måste finnas på ett visst antal språk, eller att viss dokumentation kring produkten måste finnas.
2.2.4 Kvantifiering av teknisk skuld och ränta
Hansson och Hognesius (2015) föreslår att den metod Nugroho, Visser och Kuipers (2011) beskriver ska ligga till grund för kvantifiering av teknisk skuld utanför mjukvara. Nugroho m. fl. (2011) definierar teknisk skuld som diskrepansen mellan den ideala kvaliteten och den aktuella kvaliteten.
Som tidigare nämnts i denna rapport, kan det vara fördelaktigt att inte betala hela den tekniska skulden. Företaget kan istället besluta sig för att lägga sin målkvalitetsnivå lägre än den idéella kvalitetsnivån. Kostnaden för arbetet att uppnå företagets önskade kvalitet
benämns Repair Effort (RE). För att beräkna Repair Effort används två faktorer, Rework Fraction (RF) och Rebuild Value (RV) (Nugroho m. fl., 2011).
• Rework Fraction är en uppskattning av hur stor andel av de befintliga kodraderna som måste ändras för att förbättra mjukvarans kvalitet till en högre nivå.
• Rebuild Valueär ett uppskattat värde på hur lång tid det tar att bygga om ett specifikt system med hjälp av en viss teknologi. Det räknas ut med formeln RV = SS ∗ TF, där SS står för System Size och innebär storleken på produkten som ska förbättras och TF står för Technology Factor och innebär produktiviteten på det verktyg som används för att förbättra produkten.
Nugroho m. fl. (2011) definierar räntan för den tekniska skulden som ”[...] the difference in maintenance effort between a particular quality level and the ideal level”. För att uppskatta underhållsarbetet används formeln ME = MF ∗ RV/QF (Nugroho m. fl., 2011).
• Maintenance Effort (ME) är det underhållsarbete som årligen utförs på koden.
• Maintenance Fraction (MF) är delen av systemets kodrader i procent som årligen ändras i underhållsarbetet.
• Rebuild Value (RV) har samma definition som angetts ovan.
• Quality Factor (QF) motsvarar kvalitetsnivån. Ju högra kvalitet ett system har, desto mindre arbete går åt för att underhålla systemet. Detta värde räknas ut med formeln QF = 2((Qualitylevel−3)/2)
Seaman och Guo (2011) förespråkar ett annat sätt att kvantifiera teknisk skuld och dess ränta. Enligt deras arbete listas den tekniska skulden med följande egenskaper:
• Beskrivning.En kort beskrivning av vad den tekniska skulden består i, varför den bör åtgärdas och var den finns.
• Kostnad. En uppskattad kostnad för att åtgärda den tekniska skulden.
• Räntekostnad. Den kostnad som uppstår om den tekniska skulden orsakar problem.
• Sannolikhet. Sannolikheten att den tekniska skulden kommer att orsaka problem.
Listan med tekniska skulder kan hela tiden uppdateras. De olika måtten som ska specificeras (kostnad, räntekostnad och sannolikhet) tilldelas något av värdena låg, medium eller hög.
För att tilldela måtten värden kan systemets historiska data användas. Finns inte eller visar sig denna data vara bristfällig kan ett expertutlåtande istället användas.
Figur 2: En produkts livscykel (Axis Technologies PLM, 2016)
2.3 Product Lifecycle Management
Product Lifecycle Management (PLM) är ett systematiskt, kontrollerat koncept för framtag- ning samt underhåll av produkter och relaterad information (Seaman & Guo, 2011). I PLM ingår arbete för att på ett effektivt sätt underhålla ett företags produkter genom hela dess livscykler (Stark, 2015, s. 1). Det kan beskrivas som ett koncept vilket beskriver helhetsbil- den av produkter och är framtaget för att underhålla en produkt under hela dess livscykel (Seaman & Guo, 2011).
En produkts livscykel fortskrider från den första tanken av produkten och hela vägen fram till dess produkten pensioneras och avvecklas. Figur 2 illustrerar de olika stadierna en produkt går igenom under dess livscykel. Dess livscykel börjar i designstadiet, där produktens initiala design utvecklas, därifrån går produkten in i tillverkningsstadiet för att sedan distribueras till kunder. När produkten har distribuerats börjar stadiet för kunden, där support och liknande kommer in, och när produkten inte längre är aktuell går den in i dess sista stadium och pensioneras.
Till PLM kommer oftast ett mjukvarusystem som ger användare möjligheten att lagra och ta hand om information rörande produkter som behandlas i systemet (Saaksvuori & Immonen, 2008), vilket i denna rapport benämns PLM-system. I systemet hanteras produkter genom hela dess livscykler och all information relaterad till produkten finns där. Information som
behandlas i ett PLM-system kan vara dokument, Bill of Materials (BOM)2, analysresultat, testspecifikationer, miljöbetingad komponentinformation, kvalitetsstandarder, ingenjörsrela- terade krav och mycket mer (Seaman & Guo, 2011).
2.4 Statisk kod analys
Statisk analys av kod beskrivs av Emanuelsson och Nilsson (2008, s. 7) som ”Automatic met- hods to reason about runtime properties of program code without actually executing it.”3. En statisk-kod-analysator analyserar alltså koden i dess statiska tillstånd, och inte vid körning.
Chess och West (2007, s. 21) drar paralleller mellan statisk kodanalys och ett rättstavnings- program, båda förhindrar att välkända varianter av misstag går förbi oupptäckta.
Verktyg som används till statisk analys, måste ha en korrekt uppsättning med regler som specificerar fel att söka efter. Vad som är en korrekt uppsättning regler beror på i vilket syfte koden analyseras (Chess & West, 2007, s. 40).
2.4.1 Regler
Att använda en regeldriven statisk analys har givit många bra resultat (Prahofer, Angerer, Ramler, Lacheiner & Grillenberger, 2012). En regel definierar en teknisk skuld och specifi- cerar ett specifikt problem som ska sökas efter vid analys (Chess & West, 2007, s. 32) och kan definieras att upptäcka underliga mönster i koden, vilka kan antyda möjliga problem (Prahofer m. fl., 2012). En regel för att analysera Java-kod kan till exempel specificeras att leta efter tomma try/catch/finally block, död kod, duplicerad kod eller annat.
2.4.2 Statisk kodanalys för identifiering av teknisk skuld
Verktyg för statisk kodanalys som har tillägg för att analysera teknisk skuld har på senare tid fått en ökad uppmärksamhet (Nord, Ozkaya, Kruchten & Gonzalez-Rojas, 2012). Som tidigare nämnts refererar statisk kodanalys till kontroll av koden i dess statiska tillstånd, i ett försök att hitta dåliga mönster eller anomalier i koden. En typ av mönster som kan
2 En Bill Of Materials innefattar de delkomponenter produkten består av (Saaksvuori & Immonen, 2008, s.
330)”Automatiska metoder som resonerar kring egenskaper programkod har vid körning, utan att faktisk exekvera koden”
undersökas, är sådana som indikerar dåliga programmeringsprinciper och designbeslut. Så- dana mönster skapar problem med underhåll under tiden projektet fortgår, då de gör koden svårare att förstå, mer komplex och svårare att ändra och kan därför ses som teknisk skuld (Seaman & Guo, 2011).
2.5 TechniaTranscat
TechniaTranscat är ett IT-företag med ett kontor beläget i Kista. Företaget grundades 1994, har över 420 anställda och är idag en av de ledande europeiska leverantörerna av PLM- lösningar. PLM-lösningarna de erbjuder används för skapande och underhåll av produktin- formation genom produktens hela livscykel, från produktplanering, utveckling och design till produktion, försäljning, utbildning och support. Företaget har kontor bland annat Fin- land, Tyskland, Indien, Norge och USA. Det PLM-system detta arbete kommer att beröra är TechniaTranscat’s PLM-system 3DExperience.
2.5.1 3DExperience
TechniaTranscat tillhandahåller ett PLM-system, vars grund är utvecklad av Dassault Sys- téms, kallat 3DExperience (TechniaTranscat 3DExperience, 2016). Baserat på den befintliga grunden skräddarsyr TechniaTranscat lösningar utefter kundens specifika önskemål och be- hov. Exempel på funktionalitet som TechniaTranscat lägger till basprodukten är filhantering, grafisk rapportering och grid browser för aggregering av data. I 3DExperience kan kunden skapa konceptuella produktdefinitioner som sedan kan återanvändas över en serie produk- ter.
2.5.2 TechniaTranscat’s databasmodell
3DExperience använder en objektrelaterad databas, ovanpå SQL server, för att lagra da- ta. I databasen finns det för det här arbetet huvudsakligen två relevanta typer av objekt.
Affärsobjekt som representerar objekt i databasen kopplade till produkten och relationer som representerar en förbindelse mellan två objekt. En relation har två ändar och kan finnas mel- lan ett objekt eller en relation och ett objekt eller en relation. Varje relation kan identifieras unikt med ett id och databasobjekt kan identifieras unikt antingen med ett id eller med type, name och revision tillsammans. Till databasen används ett frågespråk som benämns MQL (Matrix Query Language).
2.6 Bakgrundens återkoppling i arbetet
Konceptet teknisk skuld är väl använt inom mjukvaruvärlden, där undersökningar gjorts kring vilka kategorier den kan delas in i och hur den kvantifieras. Konceptet är däremot begränsat till och endast applicerat inom mjukvara, men teoretiskt arbete har gjort som säger att konceptet kan utökas till att innefatta även PLM. Genom att utöka teknisk skuld till att innefatta PLM kan kvalitetsbrister i produkterna som behandlas i systemet identifieras och elimineras, vilket kan ge en överlag bättre kvalitet. Genom att använda teknisk skuld till att identifiera kvalitetsbrister kan produktens kvalitet höjas och större vinster kan göras. Detta arbete behandlar en praktiskt implementation av en prototyp, ITS-prototypen, för att finna teknisk skuld i TechnicaTranscat’s PLM-system 3DExperience. Den bakomliggande strategin till prototypen kommer från mjukvaruvärldens regeldrivna statiska kodanalys, vilket där är ett tillvägagångssätt att identifiera teknisk skuld i kod.
3 Metod
I det här kapitlet redovisas det för vilka forskningsmetoder som använts under projektets genomförande. Först presenteras projektets översiktliga forskningsstrategi i delkapitel 3.1.
Delkapitel 3.2 redovisar de forskningsfaser med vilka projektet genomfördes, delkapitel 3.3 redovisar för vilken typ av forskning som genomförts och varför. Forskningsmetoden som användes för arbetet redovisas i delkapitel 3.4. Därefter tas de evalueringskriterier med vilka ITS-prototypen utvärderas med upp i delkapitel 3.5. I delkapitel 3.6 och 3.7 redovisas de forskningsinstrument och urvalsmetoder som används för arbetet.
3.1 Forskningsstrategi
Forskningsstrategin som har använts i detta arbete kan ses i Figur 3. Som synes är stra- tegin baserad på den kvalitativa forskningsprocessen, vilken styrs av induktiv slutledning.
Forskningsstrategin består av följande delar: forskningsmetoder, forskningsfaser, forsknings- instrument, intervjuobjekt och validitetshot.
Figur 3: Överblick över projektets forskningsstrategi
Figur 4: De forskningsfaser projektet genomgick
3.2 Forskningsfaser
Projektet genomfördes huvudsakligen i de fem faser som illustreras i Figur 4: litteraturstu- die, modellering, implementation, validering och utvärdering. Resultatet av litteraturstudien kom att ligga till grund för inriktningen på det övriga arbetet. De tre nästkommande faserna utfördes iterativt i en cykel för att ständigt utveckla ITS-prototypen. Den första fasen, lit- teraturstudien, fortgick under hela arbetet och utökas vid behov med ytterligare litteratur.
Vid sidan av arbetet i de olika faserna ägde rapportskrivandet rum. Rapporten utökades och fylldes på med relevant text under hela arbetets gång.
3.2.1 Fas 1: Litteraturstudie
Målet med litteraturstudien var att samla in befintlig kunskap samt att upptäcka eventuella existerande brister i litteraturen (Backman, 2008, s. 24). Under litteraturstudien samlades all områdesrelevant information in och bearbetades för att ta ut bakgrundsfakta för att kunna besvara frågeställningen. Kontinuerligt gavs en bättre inblick i bakgrunden till området som undersöktes, vilket gjorde att frågeställningen effektivt kunde utvecklas och besvaras.
Arbetes litteraturstudie inleddes med att arbetet utfört av Hansson och Hognesius (2015) studerades. Därefter konsulterades många av de källor som refereras till i det arbetet. För att finna ytterligare litteratur konsulterades en mängd institutioner. Exempel på dessa är KTH Kista:s fysiska bibliotek, ACM (ACM Digital Library, 2016), IEEE (IEEE Xplor, 2016), Springer (Springer, 2016) och Google Scholar (Google Scholar, 2016). För att finna informa- tion relevant för arbetet användes olika söksträngar som till exempel; teknisk skuld, kvanti- fiering av teknisk skuld, statisk kodanalys, regeldriven statisk kod analys, Product Lifecycle Management och påbyggda versioner av dem.
3.2.2 Fas 2: Modellering
När arbetet gick in i fasen för modellering hade tillräckligt med bakgrundsinformation samlats in för att arbetet med att besvara frågeställningen kunde inledas. Utifrån de krav som ställts av beställaren, samt bakgrundsinformation och relaterat arbete inleddes en första iteration av modellering. Syftet med modelleringsfasen var att skapa en översiktlig struktur för ITS- prototypen, vilken skulle implementeras i nästa fas av arbetet. Modelleringen utfördes genom skapandet av diverse klassdiagram och flödesdiagram, vilka beskriver hur exekvering av den praktiska implementationen ska ske.
3.2.3 Fas 3: Implementation
I arbetets tredje fas, implementation, omsattes de teoretiska modellerna till praktik. När modeller och diagram för en tänkt implementation var klara, skulle dessa översättas till kod och implementeras i ITS-prototypen. Tanken med modellerna och diagrammen var inte att de ska vara heltäckande och korrekta i detalj, vilket innebar att det i denna fas kunde komma att upptäckas brister på eller förbättringar kunde läggas till de ursprungliga modellerna. Nya tankar och idéer kom att uppstå vartefter implementationen genomfördes. Var det triviala saker eller grundläggande fel rättades dessa till och implementerades med en gång. Var det större brister i modellerna togs de med till nästa iteration.
3.2.4 Fas 4: Testning
Testningsfasen hade till syfte att testa och utvärdera de nya funktionaliteter som lags till under implementationsfasen. Testningen bestod i att kontrollera de nyligen tillagda funktio- nerna, att dessa uppfyllde den tänkta funktionaliteten och att de levererade korrekta resultat.
Om mindre buggar eller fel upptäcktes i detta stadiet rättades dessa till direkt. Upptäcktes större fel togs dessa med till nästa iteration.
3.2.5 Fas 5: Utvärdering
Efter alla iterationer genom faserna för modellering, implementation och testning hade ge- nomförts var ITS-prototypen framtagen. I fasen för utvärdering utvärderades det utförda ar- betet för att ta reda på hur väl prototypen lever upp till sitt syfte, samt hur ITS-prototypen i framtiden kan utökas och förbättras till en komplett fungerande produkt. Under utvärde- ringen drogs slutsatserna för arbetet och frågeställningen besvarades. Utvärderingen skedde
genom en körning mot databaserna där antalet funna fel jämfördes med antalet existerande fel samt genom en semi-strukturerad intervju med en expert inom PLM.
3.3 Forskningstyp
I detta kapitel presenteras och motiveras valet av forskningsstrategi som användes. I delka- pitel 3.3.1 presenteras kvalitativ forskning och hur det användes i detta arbete. Delkapitel 3.3.2 presenterar induktiv slutledning, och anpassningsbarheten tillsammans med kvalitativ forskning. I delkapitel 3.3.3 presenteras den kvalitativa forskningsprocessen och hur den ap- plicerades i det genomförda arbetet. Avslutningsvis argumenteras det för varför kvantitativ forskning inte var passande för arbetet i delkapitel 3.3.4.
3.3.1 Kvalitativ forskning
Detta arbete utfördes enligt metoden för kvalitativ forskning, vilket innebar att författar- na skapade en förståelse för innebörder, åsikter och beteenden (Håkansson, 2013) för att utveckla ITS-prototypen. Inom den kvalitativa metoden ges enskilda fall som studeras stor vikt (Thurén, 2007, s. 112), vilket även är fallet med det genomförda arbetet. En begränsad del av området valdes ut att studeras och de slutsatser som drogs rörde dessa fall, men är representativa och kan även ges viss tyngd för hela området.
En begränsad mängd av de skulder som kan påträffas inom Product Lifecycle Management valdes ut att ingå i arbetet och de slutsatser som drogs rör dessa enstaka fall, men slutsatserna kan även ges viss tyngd när det gäller hela området Product Lifecycle Management. De regler som studerades var inte hämtade ur en objektiv kontext. I och med att reglerna skapades ut- ifrån den befintliga databasen kan kontexten istället sägas vara subjektiv utifrån författarnas och företagets perspektiv, vilket överensstämmer med den kvalitativa forskningen (Backman, 2008).
Författarna utvecklade ITS-prototypen parallellt med evaluering och testning. Det kan därför sägas att författarna har befunnit sig väldigt nära det som studerades och varit en del av denna metod, vilket är fallet inom den kvalitativa metoden (Backman, 2008). Backman (2008) skriver att forskarna ska finnas nära det som ska studeras och också kan ingå som en del i metoden inom den kvalitativa forskningen. Då författarna utvecklade ITS-prototypen och kontinuerligt evaluerade och testade ny-implementerad funktionalitet utifrån dess tilltänkta funktionalitet, var så fallet i detta arbete.
Figur 5: Den kvalitativa forskningsprocessen
3.3.2 Induktiv slutledning
Frågeställningen för arbetet är på formen ”hur kan...” och arbetet utgick ifrån relevant empi- risk information, vilket är startpunkten för induktiv slutledning (Backman, 2008, s. 54). Då forskningen utförs med ett kvalitativt synsätt ges oftast en induktiv slutledning (Backman, 2008, s. 54). Utifrån den insamlade empiriska fakta som togs fram under litteratursökningen bildades allmänna och generella slutsatser som ledde arbetet framåt och gav ett mer konkret tillvägagångssätt att besvara problemformuleringen.
3.3.3 Den kvalitativa forskningsprocessen
De olika momenten i den kvalitativa forskningsprocessen är flexibla och kan varieras. De olika momenten pågår ofta samtidigt och kan därför många gånger vara svåra att särskilja. I stora drag kan den kvalitativa forskningsprocessen delas upp i följande åtta moment: fråga, litteraturgranskning, val av analysenhet, problemformulering, observation, analys, tolkning och illustreras i Figur 5. (Backman, 2008, s. 56-62)
Vissa av de åtta momenten för kvalitativ forskning fortgår genom hela arbetet, och resterade kan kan delas in i de forskningsfaser detta projekt utfördes med. I den första fasen för
projektet, litteraturstudien, ingick tydligt de två första momenten för kvalitativ forskning;
fråga och litteraturgranskning. Dessa två moment består i att inleda arbetet med en fråga, vanligtvis på formen ”Hur...?” eller ”Varför...?” (Backman, 2008) och studera områdesrelevant litteratur för att ge en översikt över den tidigare kunskap som existerar inom området. Vidare drogs även gränser för vad arbetet ska innefatta och det specifika fall som berördes i arbetet bestämdes, vilket ingår i momentet val av analysenhet (Backman, 2008).
Vartefter avgränsningen blev tydligare och litteraturgranskningen fortgick, förfinades och specificerades problemformuleringen, vilket är ett av momenten för kvalitativ forskning. Då rapporten ska innehålla en omfattande bakgrund där den insamlade informationen från lit- teraturstudien ingår, inleddes också momentet rapporteringi den första fasen.
När arbetet gick in i faserna modellering, implementation och testning, vilka utfördes itera- tivt, inleddes nästkommande moment för kvalitativ forskning vilket är observation. Backman beskriver observation som en komplicerad process då verkligheten avläses och forskarna som genomför studien själva utgör instrumentet. Den utförda observationen genomfördes delta- gande ute på företaget för vilket uppdraget utförs.
Efter implementationen av ITS-prototypen påbörjades fasen för testning där arbetet också gick in i momentet analys, där insamlad data organiseras och struktureras för att skapa en helhetsbild med orsaksmekanismer (Backman, 2008). Testresultaten granskades och bedöm- des, och låg till grund för nästa iteration samt utvärderingen.
När prototypen blivit implementerad och testad gick projektet in i fasen utvärdering, vilken är den sista. I detta stadiet av arbetet genomförs det sista momentet av kvalitativ forskning, tolkning. I samband med att utvärderingen avslutades slutfördes också rapporteringen. In- samlad data tolkades för att ge en förståelse för vad arbetet har resulterat i (Backman, 2008) och resultaten redovisades i form av denna rapport.
3.3.4 Lämplighet för kvantitativ forskning
Kvantitativ forskning har som mål att analysera matematisk och statistisk data för att be- svara ett problem (Oates, 2006). Kvantitativ forskning lämpar sig bäst när forskningens mål är att bevisa en hypotes (Oates, 2006), vilket inte är fallet med detta arbete. Här syftar problemformuleringen istället till att utforska konceptet teknisk skuld och finna ett sätt att implementera konceptet inom ett område utanför mjukvara. Ett kvantitativt synsätt passar därför inte in på arbetets karaktär.
3.4 Fallstudie
Fallstudie innebär att forskaren tar del av en mindre del av det förlopp som ska studeras (Ejvegård, 1993, s. 35-36) (Oates, 2006, s. 141). Denna del studeras, utvärderas och får representera hela förloppet. Denna metod är ett bra angreppssätt då studieobjekten är särskilt komplexa (Backman, 2008, s. 55). En fallstudie begränsar inte forskarna till att välja ut endast ett fall, utan det går lika bra att använda flera fall i forskningen (Backman, 2008, s.
55) (Oates, 2006, s. 144).
Arbetets frågeställning består i hur teknisk skuld kan utökas till att appliceras på produkt- hanteringsstrategin PLM. PLM är en väldigt omfattande strategi och många olika mjuk- varusystem existerar för ändamålet. I detta arbete begränsas arbetet till enbart systemet 3DExperience som blir representativ för hela strategin. Inom området kan en stor mängd fall i form av regler, representativa för teknisk skuld, implementeras. För detta arbete skul- le arbetsbördan att implementera alla dessa bli för stor. Därför begränsas arbetet till att implementera enbart en begränsad mängd typiska fall som får representera det stora hela (Oates, 2006, s. 144). Eftersom detta arbete begränsats till att endast beröra ett system, och där i en handfull fall i form av regler är valet att utföra forskningen i form av en fallstudie logiskt.
Nackdelar med fallstudie är att en mindre del av ett förlopp aldrig till fullo kommer att kunna representera hela förloppet. Slutsatserna i ett arbete som utförts med en fallstudie ska därför mer ses som indicier (Ejvegård, 1993, s. 35-36). Det kan också vara svårt att veta exakt var gränserna för fallet ska dras (Ejvegård, 1993, s. 55).
3.5 Utvärderingskriterier
För att evaluera ITS-prototypen användes två utvärderingskriterier. Det första kriteriet, ut- värdering av täckningsgrad, utvärderar ITS-prototypens täckningsgrad genom en testkörning mot två databaser. Den ena databasen är en testdatabas med ett antal planterade fel, som direkt bryter mot de regler som implementerats och den andra är en kunddatabas med verklig data. För att få korrekta resultat, används frågor mot kunddatabasen som räknar databas- objekt som bryter mot varje regel, som sedan jämförs med antalet regelbrott ITS-prototypen identifierar. Testdatabasen innehåller ett förutbestämt antal regelbrott som resultatet av en körning kan jämföras med. Det är således möjligt att med exakthet bestämma hur stor del av den tekniska skulden prototypen identifierar, och evalueringskriteriet för utvärderingen av täckningsgrad är att ITS-prototypen ska identifiera 100 % av den tekniska skulden för varje regel. För testdatabasen är felen planterade enbart i syfte att bryta mot reglerna, vilket
resulterar i att om ITS-prototypen kan hitta ett av dem för en regel, ska den även hitta resten. I kunddatabasen kan alla regelbrott identifieras med specifika databasfrågor och om prototypen kan hitta ett fel, utifrån en regel, kan den även hitta resterande. Därför är det rimligt att ställa kravet att ITS-prototypen:s täckningsgrad för de regler som implementerats i systemet ska vara 100 %.
Det andra utvärderingskriteriet, utvärderingsintervjun, har till syfte att utvärdera den me- tod som ligger till grund för implementationen av ITS-prototypen. För att visa att strategin bakom prototypen kan användas för att identifiera teknisk skuld i 3DExperience och utökas till att upptäcka teknisk skuld av mer avancerad karaktär, intervjuades en expert på PLM från TechniaTranscat. Utvärderingsintervjun skedde i samband med att ITS-prototypen de- monstrerades internt på företaget. Intervjun var semi-strukturerad och frågorna som ställdes under intervjun finns listade i Tabell 1. Målsättningen med detta utvärderingskriterium var att ta reda på huruvida den strategi som ligger till grund för prototypen fungerar för att hitta teknisk skuld i PLM-system.
Tabell 1: Frågor till utvärderingsintervjun Intervjufrågor
Använder ITS-prototypen strategin som finns bakom statisk kodanalys?
Representerar de implementerade reglerna de tekniska skulder som formulerades av företaget i samband med kravspecifikationen?
Fungerar ITS-prototypen och reglerna tillsammans?
Är ITS-prototypen kapabel till att identifiera teknisk skuld?
3.6 Forskningsinstrument
De forskningsinstrument som använts i detta arbete är litteraturstudie, intervjuer med tek- nisk expert på TechniaTrascat och utvärderingskriteriet. Litteraturstudien var essentiell för arbetet då det var nödvändigt för författarna att sätta sig tillräckligt djupt in i koncep- tet teknisk skuld inom mjukvara för att kunna applicera konceptet på ett område utanför mjukvara.
Fortlöpande med arbetet gjordes ostrukturerade intervjuer med en konsult på företaget Te- chniaTranscat. Dessa skedde spontant då en fråga eller problem uppstod i arbetet och följde därför inte några specifika frågor eller mallar. De spelades heller inte in utan resulterade endast i anteckningar. Ostrukturerade intervjuer ger den intervjuade möjlighet att tala fritt och används vanligtvis när syftet med intervjun är att utforska ett ämne (Oates, 2006, s.
188). Intervjuerna gjordes för att ge författarna större inblick i PLM och företagets PLM-
system. Syftet var att utforska området och ostrukturerade intervjuer valdes därför. De ut- värderingskriterier som används för att utvärdera ITS-prototypen är fastslagna i samråd med författarnas handledare på TechniaTranscat. Kriterierna finns specificerade i delkapitel 3.5.
3.7 Urvalsmetod
Intervjuobjektet valdes ut med hjälp av urvalsmetoden Subjektivt urval (Oates, 2006, s. 98).
Denna metod går ut på att hitta de eller det intervjuobjekt som har störst chans att besvara forskarnas frågeställning.
3.8 Erfarenheter
Under genomförandet av detta arbete stötte författarna på några problem som komplicerade arbetet. För det första skedde implementationen av ITS-prototypen i ett befintligt system, med ett stort API (Application Programming Interface) och en stor kodbas. Integreringen av prototypen gjorde att kunskap kring funktionaliteter i systemet först behövdes införskaffas, vilket var tidskrävande och nödvändigt innan utvecklingens början. Ett annat problem som dök upp under arbetet var författarnas begränsade kunskap kring användning av versions- hanteringssystemet Git. De bristande kunskaperna i användningen gjorde att mycket tid gick åt till att sätta samman kod skriven på olika datorer där konflikter existerade. Om mer kun- skap hade funnits kring systemet, eller bättre förberedande studier hade utförts hade detta problem kunnat undvikas.
4 ITS-prototypen
I detta kapitel presenteras ITS-prototypen. Inledningsvis presenteras kravspecifikation från TechniaTranscat i delkapitel 4.1. Sedan presenteras hur de regler som definierar teknisk skuld har strukturerats i delkapitel 4.2. I delkapitlet 4.4 beskrivs arkitekturen för ITS-prototypen närmare. Delkapitel 4.5 tar upp hur teknisk skuld kvantifieras i arbetet och i delkapitel 4.6 beskrivs hur identifierad teknisk skuld sparas i databasen.
4.1 Kravspecifikation
TechniaTranscat tillhandahöll följande kravspecifikation för framtagandet av ITS- prototypen:
• Formulera ett detaljerat koncept för teknisk skuld i PLM.
• Definiera en datamodell i 3DExperience.
– Definiera en datamodell för regler gällande teknisk skuld.
– Definiera en datamodell för att lagra resultatet av identifierad teknisk skuld i 3DExperience.
• Utveckla en motor i Java som hittar skuld utefter definierade regler.
• Implementera en begränsad mängd regler som verifierar lösningen.
4.2 Regelstruktur
Vid statisk kodanalys traverseras och undersöks kod i sitt statiska tillstånd utifrån en mängd regler, där ett fel har upptäckts om koden bryter mot en eller flera regler. En databas kan även den ses som en statisk entitet, vilken kan analyseras efter samma principer som används i statisk kodanalys. I statisk kodanalys undersöks kodstrukturen, i ITS-prototypen undersöks istället databasstrukturen, databasobjekt och dess relationer i databasen. Liksom det, för att identifiera brister och felaktigheter i statisk kod används regler, används regler för att identifiera teknisk skuld i databasen. Om ett databasobjekt eller dess relationer bryter mot någon regel har en teknisk skuld identifierats.
Att låta alla regler som skapas appliceras på alla objekt i databasen skulle vara ineffektivt, då vissa regler enbart är relevanta att appliceras på vissa typer av objekt i databasen. De regler som skapas för ITS-prototypen ska därför specificera vilka databasobjekt den ska appliceras på. Logiken som kontrollerar att en regel efterföljs definieras i en Java-metod som sedan
Figur 6: Databasmodell för regler
refereras till i regeln. Varje databasobjekt som specificerats i regeln kontrolleras sedan med den metod regeln refererar till.
Kontrollen av aktuella databasobjekt sker genom att objektets id skickas som parameter till den metod som ska identifiera teknisk skuld. För att veta vilken metod som är kopplad till vilken regel ska metodens namn och det kvalificerade namnet på den klass metoden finns i specificeras i regeln. För att kunna anpassa metoderna ytterligare innehåller regeln även en parameterlista, vilken skickas till metoden tillsammans en referens till databasobjektet.
Regeln innehåller även information om kvantifiering av den tekniska skulden, vilket tas upp i delkapitel 4.5
Om fler än en regel ska appliceras på en samling databasobjekt är det fördelaktigt att inte behöva specificera sökkriterierna för dessa databasobjekt flera gånger då detta kan vara en felkälla och tidsödande. Av denna anledning skapades två typer av regler, Single Rule och Super Rule. Dessa två regeltyper innehåller båda information om vilka databasobjekt som ska kontrolleras i databasen. Därför skapades en abstrakt superklass innehållande sökkriterier, RULE, som båda regeltyperna ärver av. Single Rule innehåller också information om metoden som ska appliceras på sökresultatet och kvantifieringen av den tekniska skulden kopplad till regeln. Super Rule innehåller referenser till en eller flera Single Rule. En Super Rule innehåller alltså en mängd Single Rules som ska appliceras på samma mängd databasobjekt.
Databasmodellen för en regelsamlingen beskådas i Figur 6.
4.2.1 Regeltypen RULE
RULEdefinierades som en abstrakt klass vilken alla typer av regler ärver av. IRULEdefinieras fyra attribut relevanta för att en regel ska kunna specificera en sökning i databasen. De attri- buten är type, name, revision och where. Type, name och revision används för att identifiera objekt i databasen och where används till att sätta ytterligare begränsningar på de objekt som hämtas. Till exempel kan det specificeras att enbart objekt där ett specifikt attribut har ett visst värde ska undersökas. Med dessa attribut kan en fråga mot databasen gene- rera allt mellan noll och många resultat. Till exempel om type=”Documents”, name=”*”, revision=”*” och where=”” kommer ett resultat med alla dokument i hela databasen leve- reras i och med att ”*” innebär ”alla”. Är det däremot definierat som type=”Documents”, name=”*’, revision=”2.0” och where=”” kommer det resultera i alla dokument med revision 2.0.
4.2.2 Regeltypen Single Rule
En Single Rule består utöver attributen ärvda från RULE av attributenQualifiedClassName- ContainingMethodToRun, MethodToRun, MethodParams, SeverityLevel ochTimeQuantification. QualifiedClassNameContainingMethodToRun innehåller det kvalificerade klassnamnet till den Java-klass där metoden som ska appliceras på de objekt regeln berör finns och i MethodTo- Run finns namnet på metoden. Dessa två är nödvändiga för att dynamiskt kunna identifiera och anropa metoden med Java Reflection (Using Java Reflection, 1998). I MethodParams definieras de parametrar metoden tar emot, vilka kan vara en jämförelseoperator, en siffra att jämföra med och namnet på det fält i objektet som ska jämföras. SeverityLevel har, som kan ses i Figur 6, fyra möjliga värden: low, medium, high, critical. De har till uppgift att visa hur allvarligt ett regelbrott mot just denna regel är. TimeQuantification är den uppskattade tid det tar att arbeta bort den tekniska skulden.
4.2.3 Regeltypen Super Rule
En Super Rule ärver, likt en Single Rule, av den abstrakta klassen RULE för att ge reglerna uniformitet. Det innebär att en Super Rule, förutom sitt unika id superRuleId, endast be- står av attributen Type, name, revision, where. Syftet att ha en regel av typen Super Rule är att det ska kunna innehålla en samling Single Rules som ska appliceras på samma mängd databasobjekt i databasen. Det underlättar underhåll samt strukturering av regler i syste- met, genom att det är lättare att få en överblick över vilka regler som appliceras på vilka databasobjekt.
4.2.4 Regelmetoder
Varje regel måste ha en metod kopplad till sig, metoderna kan skrivas på många olika vis och antingen vara generella för vissa ändamål eller mer specifika för andra. Syftet med en regelmetod är att en regels logik ska finnas där. En regelmetods uppgift är att den ska undersöka om ett specifikt databasobjekt bryter mot den regel metoden ingår i. Varje metod måste därför ha en parameter som specificerar det relevanta databasobjektet. För uniformitet bestämdes att databasobjektet alltid ska vara den första parametern i listan, och det sedan är upp till varje metod och regel vad de efterkommande parametrarna är.
En generell metod som kan användas till många olika regler är till exempel en jämförel- semetod, vars implementation kan beskådas i Appendix A, som tar emot fyra parametrar;
businessObject, compLength, compOperator och compField. compField specificerar vilket attribut eller vilken egenskap i databasobjektet som ska jämföras, compOperator specificerar vilken operator som ska användas för jämförelsen, till exempel < eller >, och compLength är storleken mot vilken compField ska jämföras med. Om compField är av typen integer jämförs dessa direkt, men om den däremot är en sträng jämförs istället strängens längd. Metoden kan användas till många ändamål, exempelvis för att kontrollera att ett pris är högre än ett specifikt belopp eller att en beskrivning för ett databasobjekt existerar.
Det finns även mer regelspecifika metoder, vilket ofta är nödvändigt då traversering av un- derliggande databasobjekt krävs. Ett exempel på ett sådant fall är en metod som kontrollerar en huvudkomponents underliggande relationer. En huvudkomponent består av flera under- liggande komponenter. Mellan huvudkomponenten och vardera av de underliggande kom- ponenterna existerar relationer, vilka har ett så kallat Find Number. Om de relationer som går ifrån huvudkomponenten inte har unika Find Numbers existerar en teknisk skuld för huvudkomponenten. Regelmetoden för att kontrollera detta har då till uppgift att utifrån huvudkomponenten undersöka de underliggande relationerna och kontrollera om värdena på Find Number är unika.
4.3 Implementerade regler
För att visa på prototypens generiska förmåga implementerades ett antal olika regler. Varje regel kontrollerar olika saker och om regeln bryts existerar en teknisk skuld av typen regeln definierar i systemet. Några exempel på regler som implementerats i ITS-prototypen följer nedan.
Fält i stora bokstäver.Denna regel kontrollerar om ett angivet fälts specificerade information är skriven i endast stora bokstäver. Till exempel beskrivningen för ett databasobjekt vara
skrivet med stora bokstäver i 3DExperience, och om så inte fallet finns det en teknisk skuld för det databasobjektet.
Antal tecken för fält. Denna regel kontrollerar antalet tecken informationen i ett angivet fält består av. Regelmetoden tar emot information om vilket fält som ska kontrolleras, vilken jämförelse som ska göras och mot vilken siffra jämförelsen ska göras. Teknisk skuld har identifierats om antalet tecken i fältet inte går igenom kontrollen metoden utför.
Kontroll av datatyp för fält.I vissa fall är det viktigt att datan i ett fält är av en viss datatyp, till exempel en textsträng eller en siffra. Ett visst tillfälle för detta är om en komponent har ett attribut för en måttenhet som har värdet ”each”, vilket innebär att dess attribut för kvantitet måste vara av typen Integer, alltså ett heltal.
Unika fält för underliggande relationer. Denna regel kontrollerar att ett visst attribut för alla underliggande relationer av en viss typ från ett databasobjekt är unika. Är så inte fallet har en teknisk skuld identifierats för databasobjektet.
Tomma fält i underliggande relationer. Den implementerade regeln av denna typ kon- trollerar ett specifikt attribut på en möjlig underliggande relation. Det specifika fallet som kontrolleras är om en komponent har delkomponenter, och därmed relationer som går mel- lan komponenten och delkomponenterna, så måste denna relation ha ett värde på attributet
”Find Number”, vilket är ett attribut som identifierar just den relationen.
4.4 Arkitektur för ITS-prototypen
I detta kapitel beskrivs arkitekturen för ITS-prototypen. I delkapitel 4.4.1 beskrivs hur proto- typen hanterar regler. Hur prototypen applicerar reglerna på databasobjekt beskrivs i kapitel 4.4.2.
4.4.1 Hantering av regler
ITS-prototypens regelhantering sker primärt i tre olika klasser. Den ena klassen hanterar allting som berör Single Rules, den andra tar hand om allting relevant för Super Rules och den sista, som i detta arbete benämns regelhanteraren, används som ett lager mellan de två tidigare nämnda typerna och regelmotorn. De klasser som finns för Single Rules och Super Rules har till uppgift, utöver att läsa in reglerna från databasen, att omvandla dem till Javaobjekt. Varje regel representeras i Java av ett så kallat Data Transfer Object (DTO), där all relevant information för en regel sparas och kan hämtas.
