Problem – Orsak – Konsekvens (POK)-Modellen för mjukvaruutvecklingsprojekt ANGELINA MALLO

KTH ROYAL INSTITUTE OF TECHNOLOGY I N F O R MA T I O N A N D C O M MU N I C A T I O N T E C H N O L O G Y

Abstract

Det blir allt vanligare att arbeta i projekt och därmed finns alltfler mjukvaruutvecklingsmetoder eller ramverk att applicera till projektet. Det är dock fortfarande inte ovanligt att man arbetar metodlöst, vilket kan leda till att oberäknade problem uppstår. En arbetsmetod eller ett metodramverk formar projektet så att man på bästa skall kunna undvika problem samt vara medveten om problem som skulle kunna uppstå.

Syftet med den här studien är att ta fram en modell som identifierar problem och dess orsaker och konsekvenser som uppstår i ett mjukvaruutvecklingsprojekt med hjälp av ramverk. Ramverken som används i den här studien är Essence – Kernel and Languages for Software Engineering Methods och Self-Governance Developer Framework. Målet är att den här modellen skall användas av personer inom mjukvaruutveckling för projekt eller forskning.

Studien är av kvalitativ natur med induktiv ansats. Det utfördes ett mjukvaruprojekt där teamet arbetade metodlöst och identifierade problem från en uppföljning som gjordes aktivt under projektets arbetsgång. Resultatet av studien är en modell som innebär att man skall kunna hitta orsaker samt konsekvenser till uppstådda problem inom projektet. Modellen som har tagits fram heter Problem-Orsak-Konsekvens-modellen och förkortas POK-modellen.

Nyckelord: Mjukvaruprojekt, projektmetoder, mjukvaruutvecklingsproblem, projektramverk, mjukvaruutveckling.

Abstract

It is becoming more common to work in projects and therefor there are more and more software development methods to apply for the project. However, it is still not unusual to be working ad hoc, which can lead to uncalculated problems. A method or a framework shapes the project so that problems can be avoided in best possible way. It also helps developers to be aware of the problem that could arise. Despite this, there is no compilation of “anticipated problems” when working ad hoc.

The purpose of this study is to produce a model to identify problems, root cause of problems and consequences of the problems that can occur when working in a software development project with the help from frameworks. The frameworks used in this study are Essence – Kernel and Languages for Software Engineering Methods and Self-Governance Developer Framework. The goal is that the model is used in software development environments for projects or research.

The study is of qualitative nature with inductive approach. A software project was performed where the team worked without a method and identified problems from a follow-up that was active during the workflow of the project. The result of the study is a model, which should be able to find the source to occurred problems as well as consequence within the project.

Keywords: Software projects, project methods, software development problems, project frameworks, software development.

INNEHÅLLSFÖRTECKNING

1 INTRODUKTION.................................................................................................31.1 BAKGRUND..............................................................................................................31.2 PROBLEM.................................................................................................................41.3 FORSKNINGSINSTRUMENT......................................................................................21.4 SYFTE.......................................................................................................................41.5 MÅL.........................................................................................................................41.6 FORSKNINGSMETOD................................................................................................41.7 AVGRÄNSNINGAR....................................................................................................21.8 MÅLGRUPP..............................................................................................................21.9 DISPOSITION............................................................................................................3

2 MJUKVARUUTVECKLINGSPROJEKT.........................................................52.1 MJUKVARUUTVECKLINGSMETODER/RAMVERK.....................................................52.2 METODER/RAMVERK..............................................................................................52.3 VARFÖR BEHÖVS METODER OCH RAMVERK...........................................................62.4 ESSENCE - KÄRNA OCH SPRÅK FÖR PROGRAMUTVECKLINGSMETODER...............7

2.4.1 Essence Kernel..................................................................................................72.5 SELF-GOVERNANCE DEVELOPER (SGD) FRAMEWORK.........................................82.6 MJUKVARUUTVECKLING.........................................................................................9

Problem som finns inom mjukvaruutveckling.....Fel!Bokmärketärintedefinierat.Oproduktiv arbetsmiljö..............................................................................................10Ineffektiv projektledning............................................................................................10Brist på intresse från aktörer....................................................................................10Kommunikation...........................................................................................................10Dålig schemaläggning................................................................................................10

3 METOD.................................................................................................................133.1 FORSKNINGSTYPER...............................................................................................13

3.1.1 Kvalitativ forskning.......................................................................................133.1.2 Induktivt resonemang...................................................................................143.1.3 Datainsamling................................................................................................14

3.2 FASER....................................................................................................................143.2.1 Genomförande av projekt.............................................................................143.2.2 Aktiv uppföljning av projektet......................................................................153.2.3 Litteraturstudie..............................................................................................153.2.4 Problemidentifiering......................................................................................153.2.5 Matchning mot valda ramverk (SGD, Kernel Essence)...........................16

4 FÖRSTUDIE................................................FEL!BOKMÄRKETÄRINTEDEFINIERAT.4.1 FÖRETAGET, ERICSSON.........................................................................................174.2 PRODUKT SOM UTVECKLATS.................................................................................17

4.2.1 Krav på produkten.........................................................................................174.2.2 Syfte med produkten......................................................................................18

4.3 ARBETSPROCESS....................................................................................................19

5 PROJEKTPROBLEM........................................................................................21FEL VAL AV PROGRAMMERINGSSPRÅK..............................................................................21BRIST PÅ PLANERING.........................................................................................................22INGEN UPPDELNING AV ARBETSUPPGIFTER......................................................................22FÖR LITE INVOLVERING AV HANDLEDARE.........................................................................22DÅLIG KOMMUNIKATION I GRUPPEN.................................................................................23

INGEN DOKUMENTATION ELLER DESIGN ATT UTGÅ IFRÅN...............................................23

6 AKTIVITETER FRÅN ESSENCE, SGD.........................................................256.1 SGD RAMVERK......................................................................................................256.2 KERNEL ESSENCE..................................................................................................28

6.2.1 Stakeholder......................................................................................................286.2.2 Opportunity.....................................................................................................306.2.3 Requirements..................................................................................................326.2.4 Software System.............................................................................................346.2.5 Team.................................................................................................................366.2.6 Work.................................................................................................................386.2.7 Way of working..............................................................................................40

7 MATCHNING AV PROBLEM OCH AKTIVITETER...................................437.1 FEL VAL AV PROGRAMMERINGSSPRÅK..................................................................437.2 BRIST PÅ PLANERING............................................................................................447.3 UPPDELNING AV ARBETSUPPGIFTER....................................................................447.4 FÅ DISKUSSIONER MED HANDLEDARE..................................................................447.5 DÅLIG KOMMUNIKATION......................................................................................457.6 INGEN DESIGN ELLER DOKUMENTATION ATT UTGÅ IFRÅN..................................45

8 RESULTAT...........................................................................................................478.1 ÖVERSIKT AV ORSAK-PROBLEM-KONSEKVENS-MODELLEN...............................478.2 PROBLEM-ORSAKER-KONSEKVENSER.................................................................478.3 TILLÄMPNING AV POK-MODELLEN......................................................................50

9 SLUTSATSER OCH DISKUSSION................................................................519.1 DISKUSSION...........................................................................................................519.2 STUDIENS BIDRAG TILL FORTSATT RELATERAT ARBETE......................................529.3 FÖRDELAR, ETIK OCH HÅLLBARHET.......................................................................39.4 RELATERAT ARBETE..............................................................................................10

10 LITTERATURFÖRTECKNING...............FEL!BOKMÄRKETÄRINTEDEFINIERAT.

1

TABELLFÖRTECKNING

Tabell 1 Kravspecifikation från intressenterna för projektet. .......................... 18Tabell 2: Består av identifierade problem samt konsekvens. ........................... 21Tabell 3: Utförda aktiviteter i SGD Pre-Work Activities. ................................. 25Tabell 4: Utförda aktiviteter i SGD Work Activities. ........................................ 26Tabell 5. Utförda aktiviteter för Stakeholders .................................................. 29Tabell 6. Utförda aktiviteter för Opportunity .................................................. 30Tabell 7. Utförda aktiviteter i Requirements .................................................... 32Tabell 8. Utförda aktiviteter i Software System ............................................... 34Tabell 9. Utförda aktiviteter i Team .................................................................. 36Tabell 10. Utförda aktiviteter i Work ............................................................... 38Tabell 11. Utförda aktiviteter i Way-of-working ............................................. 40

FIGURFÖRTECKNING

Figur 1. Vattenfallsmetoden [11] ......................................................................... 6Figur 2. Områdena i Kernel Essence och hur de interagerar............................................................................................................................... 8Figur 3. Processen för SGD och vilka aktiviteter som ingår i respektive område............................................................................................................................... 9Figur 4. Överblick över hela forskningsstrategin. ............................................ 13Figur 5. Forskningsfaserna i utredningen. ....................................................... 15Figur 6. Orsaker för problem #1 ....................................................................... 43Figur 7. Orsaker för problem #2 ....................................................................... 44Figur 8. Orsaker för problem #3 ....................................................................... 45Figur 9. Orsaker för problem #5 ....................................................................... 45Figur 10. Orsaker för problem #6 ..................................................................... 46Figur 11. Representation för modellen Problem-Orsak-Konsekvens. .............. 47Figur 12. Sammanfattning av problem #1 ....................................................... 48Figur 13. Sammanfattning av problem #2 ....................................................... 48Figur 14. Sammanfattning av problem #3 ........................................................ 49Figur 15. Sammanfattning av problem #5 ........................................................ 49Figur 16. Sammanfattning av problem #6 ........................................................ 50

2

3

1 Introduktion

När man arbetar inom projekt i mjukvaruutveckling är det vanligt att man arbetar utifrån en metod som är lämplig för projektet. Det är dock också vanligt att man arbetar ad hoc, vilket innebär att man arbetar spontant och improviserat [1]. Det finns också ramverk med principer och arbetssätt som skall fungera som ett stöd för mjukvaruutvecklingsprojektet. [2] Syftet med ramverk är att förenkla samt effektivisera processen för systemutvecklare genom att ge utvecklarna de grundelement som menas vara viktigast och som skall fokuseras på oavsett vilken fas hen befinner sig i; analys, design och implementation. [3] Inom ett mjukvaruutvecklingsprojekt ingår flera områden som kan ske som en följd av varandra. Kravhanteringen, kan ses som en fastställning av intressenternas mål av produkten samt en specificering av dessa. Mjukvarudesign handlar om processen att designa en lösning utifrån kravhanteringen. Implementation handlar om processen att implementera den framtagna lösningen utifrån designen. Programvarutestning omfattar ett antal olika tester för att kunna utvärdera resultatet. Programvarukvalitet avser hur väl lösningen uppfyller de funktionella kraven. Programvaruunderhåll gäller hur man skall kunna underhålla en programvara på ett effektivt sätt [4]. Alla dessa områden ingår i ett mjukvaruutvecklingsprojekt. Eftersom det är flera områden och varje område behöver behandlas ordentligt och utförligt kan det underlätta med en metod eller ett ramverk som tydligare hänvisar till hur man skall ta sig igenom respektive område. Det allra första stadiet i ett mjukvaruutvecklingsprojekt är egentligen utvecklingsmetodiken, d.v.s. strukturen som väljs för utvecklingsprocessen. Att arbeta efter ett ramverk/metod eller ad hoc är ett val utvecklingsteamet bör besluta om tidigt i processen. Ett mjukvaruutvecklingsprojekt kommer ta sig igenom de olika mjukvaruutvecklingsstadierna kan man anta att teamet kommer stöta på problem, förr eller senare. Fördelen med att arbeta efter ett ramverk är att man har en bättre överblick över projektet och därmed kan teamet vara medvetna om eventuella problem. Det negativa med att arbeta ad hoc, det vill säga att man inte följer en vald arbetsmetod kan leda till oväntade problem. Det kan vara problem som rör mjukvaran (design, implementering, kod) men även vara problem som rör projektet och arbetsgruppen (planering, tidsestimering, roller).

1.1 Bakgrund Att problem uppstår i ett projekt är inte ovanligt. Problem kommer med all sannolikhet att uppstå oavsett om man arbetar efter en metod eller ad hoc. Om man däremot arbetar mot en metod eller ett ramverk vet man bättre vilka problem man skall förvänta sig. Med ad hoc sker arbetet improviserat, så det kan vara svårt att se steg längre fram i arbetet och det blir därmed svårt att förutse vilka problem som kan tänkas uppstå. Genom att vara medveten om

4

vilka problem som kan uppstå kan man också ha lättare för att undvika dessa, även om man arbetar ad hoc eller utifrån någon annan lämplig arbetsmetod.

1.2 Problem Idag finns det inga modeller som hjälper till att identifiera problem och dess orsaker samt konsekvenser. Med anledning att det inte finns en sådan modell uppstår problemet och därmed syftet för studien. Problemformuleringen för studien blir därmed: Är det möjligt att ta fram en modell som hjälper till att identifiera problem, orsakerna och konsekvenserna inom mjukvaruutvecklingsprojekt?

1.3 Syfte Syftet med den här studien är att presentera en modell som skall kunna identifiera orsaker och konsekvenser till problem som uppstått i ett ad hoc projekt inom mjukvaruutveckling. Med en sådan modell skall det underlätta för bl. a. projektledare, chefer, team att kunna ta reda på varför problem har uppstått i projektet för att kunna undvika problemen i framtida projekt.

1.4 Mål Målet med den här studien är att ta fram en modell för identifiering av orsaker till problem. Den här modellen skall kunna användas av projektgrupper, metodansvariga och praktiker för att själva kunna ta fram orsakerna till problem som uppkommit eller i syfte att forska om problem, orsaker till problem samt metoder och ramverk.

1.5 Uppdrag I den här studien utfördes ett mjukvaruutvecklingsprojekt på Ericsson i Beirut, Libanon. Projektet utfördes av studenter i syfte att ta fram en applikation för att mäta nedladdningshastigheten för stora filer. För studien användes projektet i syfte att ta identifiera problem ur ett metodlöst projekt.

1.6 Forskningsmetod En kvantitativ metod är en metod där vikten läggs på insamlandet och analysen av data. Denna metoden analyserar siffror och frågorna är oftast statistiska eller matematiska termer. En kvalitativ metod är en metod där vikten läggs på kvaliteten av det insamlade materialet. Denna metoden fokuserar på ord och tolkning. Här är det även relevant förstå en helhet. [5] Av ovanstående anledningar dras slutsatsen att denna utredning är av kvalitativ natur. Eftersom utredningen utforskar ett område som är relativt outforskat på ett nära håll faller det in under kvalitativ forskning och därmed aktionsforskning. Denna rapport är en kvalitativ forskningsrapport där ändamålet är att ta reda på problem som uppstår under mjukvaruutvecklingsprojekt, för att kunna ta fram en modell. Det har gjorts genom en förstudie, som innebär ett aktivt

2

deltagande i ett mjukvaruutvecklingsprojekt, vilket har utförts genom forskningsfaserna; (1) Genomförande av projekt, (2) Aktiv uppföljning av projekt, (3) Litteraturstudie, (4) Identifiera problem, (5) Matchning mot ramverk. [5] (Forskningsinstrumenten för studien är: den aktiva uppföljningen av projektet dvs dagboksskrivandet och valda ramverk. Utredningen faller också in under kategorin induktivt resonemang eftersom man försöker förstå en helhet utifrån resultatet. [6])

1.7 Forskningsinstrument För den här studien kommer Self-Goveranance Developer (SGD) Framework [7] och Essence Kernel [8] att användas. Dessa två ramverk används för att identifiera vilka aktiviteter som utförts i projektet och som stöd för att bestämma orsaker till uppkommande problem. Dagbok som skrivits som en aktiv uppföljning av projektet används för att gå tillbaka och identifiera problem samt händelser från projektet.

1.8 Avgränsningar Studien kommer att avgränsas gällande antalet projekt som utförts samt antalet ramverk som skall användas. Avgränsningarna i respektive område beskrivs mer utförligt nedan. Utredningen är endast baserat på ett projekt. För bättre analys, resultat och trovärdighet hade det varit bättre med minst två olika projekt men denna utredning kunde inte ha den utsträckningen. Det här projektet som utförts är ett relativt kort och litet projekt. Studien utsträcker sig endast så långt att det endast valts två ramverk att jämföra identifierade problem mot. De ramverken som valts är Essence [8] och Self-Governance Developer (SGD) Framework. [7] Båda ramverken beskrivs utförligt i kap. 2. Här har det alltså gjorts en avgränsning på hur många och vilka arbetsmetoder/ramverk som skall väljas att jämföra med. Dessa två ramverk valdes eftersom man i efterhand enkelt med hjälp av tabeller kan analysera vilka aktiviteter som faktiskt utförts eller inte under projektet. Detta var viktigt eftersom en jämförelse skulle ske. Utan tabeller som enkelt visar vad som gjorts och inte gjorts hade det varit svårare att visa samband mellan problem och valt ramverk. Observera att Post-Work aktiviteterna har inte tagits med i denna utredning p.g.a. inte relevanta för studiens mål som främst handlar om att ta reda på orsaker till problem som uppkommit i projektet.

1.9 Målgrupp Målgruppen för denna studie är personer inom IT, dvs. främst systemutvecklare, men även chefer och projektledare. Den här studien är också relevant för forskare som forskar inom områdena projektmetoder och projektproblem i mjukvaruutveckling.

3

1.10 Fördelar, etik och hållbarhet Fördelen med den här studien är främst att få personer som skall utföra ett mjukvaruutvecklingsprojekt att vara medvetna om vilka problem de kan undvika genom att använda sig av ett ramverk som stöd för utvecklingen. Teamet som arbetar som utvecklare kan utvinna tid på så sätt att de undviker problem antingen genom att vara medvetna om problem som kan uppstå eller även välja att använda ett ramverk alternativ metod. En annan fördel med den här studien är att vid valet att arbeta metodlöst kan man på ett relativt enkelt sätt hitta orsaker till problem för att vid framtida projekt vara medveten om orsakerna. Hållbar utveckling är ett gemensamt uttryck för ekologisk hållbarhet, social hållbarhet samt ekonomisk hållbarhet [9]. Inom företag är det viktigt med ekonomisk hållbarhet och tidsbesparing kan mycket väl bidra till besparing av pengar samt förbättring av företagets ekonomi. Genom att vara medveten om orsakerna till problemen kan vid framtida projekt inom företaget ha bättre koll och spara tid. Genom tidsbesparing samt ekonomisk besparing kan företaget fokusera mer på den ekologiska hållbarheten samt den sociala hållbarheten, t.ex. välmående bland anställda och trygg gemenskap på företaget.

1.11 Disposition Följande kapitel ger en översikt över studien och beskriver sammanfattat vad varje kapitel innehåller. Kapitel 2. Utökad bakgrund: Detta kapitel innehåller den bakgrundsinformation som är nödvändig för att förstå arbetet och problemet. Kapitel 3. Forskningsmetod: Detta kapitel beskriver forskningsmetoden som har använts samt beskrivning av forskningens olika faser. Kapitel 4. Projektbeskrivning: Detta kapitel handlar om projektet och en djupare projektbeskrivning. Personer, företaget, produkt, syfte med produkt samt arbetsmetod beskrivs utförligt. Kapitel 5. Framtagna problem: Detta kapitel omfattar problemen som uppstod under projektet. Problemen presenteras och beskrivs utförligt. Ges även en beskrivning på hur problemet hanterades under projektet. Kapitel 6. Ramverk: Detta kapitel innehåller resultat från respektive ramverk. Här jämförts utförandet av projektet med ramverken. Kapitel 7. Analys: Detta kapitel handlar om att hitta ett samband mellan identifierade problem samt resultat av ramverk (SGD, Essence). Kapitel 8. Resultat: Detta kapitel presenterar resultatet av studien. Modellen som är resultatet presenteras och beskrivs.

4

Kapitel 9. Diskussion: Detta kapitel omfattar slutsatser samt diskussioner för studien som helhet.

5

2 Mjukvaruutvecklingsprojekt

Detta kapitel ger den teoretiska bakgrunden som är nödvändig för att förstå resterande kapitel i arbetet. De områden som omfattar den teoretiska bakgrunden är: Vad är en metod (2.1), Vilka metoder som finns idag (2.2), Varför vi skall ha en metod (2.3), Beskrivning av Kernel Essence (2.4) och Self-Governance Developer SGD (2.5) eftersom dessa två ramverk används som forskningsinstrument i studien, Mjukvaruutveckling (2.6) samt problem inom mjukvaruutveckling (2.7).

2.1 Mjukvaruutvecklingsmetoder/ramverk En metod är en komposition av praxis. Metoder är dynamiska och skall stödja “dag-till-dag” aktiviteter, det vill säga, de vardagliga aktiviteterna. En metod är inte bara en beskrivning av vad som förväntas göras, men också en beskrivning av vad som faktiskt har gjorts. [8] En metod skall bestämma arbetsgången och hur arbetet skall gå till. Man skall kunna upprepa metoden med samma förväntade resultat. En metod kan bestå av t.ex. verktyg, modeller, specifika roller som skall forma denna metod och underlätta arbetet. Ett ramverks syfte är att effektivisera arbetet för utvecklarna genom att lägga tyngd på de grundelement som anses vara viktigast och som ska läggas mest fokus på. Ett ramverk ska ge utvecklingsteamet ett gemensamt synsätt på projektet och kunna arbeta utifrån samma grund. [3, 2]

2.2 Metoder/ramverk Idag kan man dela upp metoder i så kallade tungviktiga metoder och lättviktiga metoder. Som tungviktig metod räknas t.ex. vattenfallsmetoden in medan en lättviktig metod kan vara agil. Dessa är två kända metoder som finns idag och används inom mjukvaruutvecklingen. Vattenfallsmodellen har funnits sedan en lång tid tillbaka och var en modell som fick bort ett flertal problem som funnits tidigare. Att beräkna tid och kostnad för utvecklingen blev mycket lättare. Utvecklingsprocessen för vattenfallsmetoden flödar likt ett vattenfall (därav namnet) det vill säga uppifrån och ned, från ett steg till nästa [10]. Se figur 1 för bättre representation av flödet för modellen. Vattenfallsmetoden kan dock medföra ett antal risker. Detta är en metod som inte är särskild flexibel. Det innebär att vid eventuella problem eller ändringar är det svårt att gå tillbaka och reparera. Ett vanligt problem med vattenfallsmetoden är att testning sker i slutet av projektet. Det betyder att om t.ex. ett fel skulle upptäckas skulle det medföra så kallad ”backtracking” som innebär att man går tillbaka till avklarade faser för att reparera buggen. Detta kostar både tid och pengar. [11]

6

Figur 1. Vattenfallsmetoden [12] En agil arbetsmetod skiljer sig från vattenfallsmetoden på så sätt att den är mer lättrörlig. Medan vattenfallsmetoden består av steg i en viss ordning så är ett agilt arbetssätt mer av en uppsättning värderingar, attityder och principer. Dessa punkter utgör en agil metod: Individer och samspel, Användbart resultat, Kundsamarbete, Anpassning till förändring. [13] [14] Dessa punkter kommer från ”Manifest för Agil systemutveckling”. Det är dessa delar som värdesätts i ett systemutvecklingsprojekt. I den här manifestationen finns 12 principer som utgör det agila manifestet; ” Välkomna förändrade krav, även sent under utvecklingen. Agila metoder utnyttjar förändring till kundens konkurrensfördel.” Denna punkt är ett exempel på den agila metoden. Förändringar längs utvecklingsprocessen innebär inte ytterligare tid och kostnad. Att kunna ta emot förändringar och problem är en del av arbetsmetoden, oavsett i vilket stadie de sker i. [14] Scrum är ett exempel på ett agilt ramverk som används för att utveckla och underhålla produkter. Med Scrum ska fördelningen av roller och arbetsuppgifter förenklas men samtidigt hålla fokus på levererad affärsnytta. Förutom rollerna består Scrum av ett antal beståndsdelar i form av obligatoriska möten och dokument. Tanken med Scrum är att projektgrupper skall kunna applicera processer från ramverket för att kunna förenkla och effektivisera arbetet. [15] [16]

2.3 Varför behövs metoder och ramverk En metod är som ett verktyg för hur arbetet skall fortskrida. Metoden skall kunna ge en tydlig bild av vad arbetet skall leda till samtidigt som den skall effektivisera arbetet. Man skall, eller bör använda sig av en metod för att veta

7

vad man skall förvänta sig av arbetet man lägger tid, arbetskraft, energi och resurser på. Om man anpassar sitt arbete efter en arbetsmetod får man ett strukturerat arbete där man vet vad som är nästa steg i arbetet. En metod hjälper gruppen att få en bättre överblick över hela arbetet. Det kan också reducera antalet problem eller upptäcka problem i tidigt stadie då man förhåller sig till en planering för arbetet. [17]

2.4 Essence - Kärna och Språk för Programutvecklingsmetoder Essence är en standard inom mjukvaruutveckling, som består av Kärnan och Språk. Kärnan, består av en gemensam grund för hur man definierar metoder för mjukvaruutveckling. Kärnan skall kunna hjälpa personer i syfte att utföra ett projekt kunna jämföra metoder och fatta bättre beslut gällande deras utveckling. Kärnan är en avskalad, lätt uppsättning av väsentliga ting som fångar essensen av effektiva, skalbar programvaruteknik i en praxis på ett oberoende sätt. Språk, handlar om att metoder, praktiker och Essence kärnan är definierade i Essence språket. Syftet är att få metoder synliga och användbara för utvecklare. [8] Följande termer finns beskrivna i det originella dokumentet för Essence. Relationen mellan dessa termer framgår tydligt i figur 2. ALPHA: Abstract-Level Progress Health Attribute. En viktig del inom programvaruteknik för bedömning av de framsteg som gjorts. Stakeholders (Intressenter): Personer, grupper eller organisationer som påverkar eller blir påverkade av ett mjukvarusystem. Opportunity (Möjlighet): Omständigheter som gör det lämpligt att utveckla eller förändra ett programvarusystem. Requirements (Krav): Vad systemet skall kunna göra för att möta möjligheten samt tillfredsställa intressenterna. Software System (Programvarusystem): Ett system som består av programvara, hårdvara och data som ger oss dess primära värde vid exekvering av programmet. Team (Arbetslag): En grupp som är aktivt engagerade i utvecklingen, av underhåll, leverans och/eller stöd för en specifik mjukvara Work (Arbete): Aktivitet som involverar mental eller fysisk ansträngning i syfte att nå ett resultat. Way-of-working (Hur man arbetar): Ett skräddarsytt sätt att arbeta och använda verktyg som används av arbetslaget för att guida och stödja arbetet.

2.4.1 Essence Kernel Kernel är organiserat i tre separata områden, där varje område fokuserar på en särskild aspekt av programvaruteknik. Se figur 2 för bildlig representation. Customer (kunden), Solution (lösningen) och Endeavor (strävan) är dessa tre relevanta aspekter. [8] I området gällande kunden, måste teamet som skall arbeta med produkten förstå intressenterna samt möjligheten för utvecklandet av produkten

8

Figur 2. Områdena i Kernel Essence och hur de interagerar. adresseras. Därmed är alltså ALPHA-korten Stakeholders samt Opportunity inkluderade i detta område. I nästa område gällande lösningen, måste teamet skapa en gemensam förståelse för kraven och utifrån det genomföra utvecklingen. De skall implementera, testa, distribuera samt stödja ett programvarusystem som uppfyller de kraven. ALPHA-korten för detta område är Requirements och Software System. I det sista området, strävan, handlar det främst om teamet och hur ett sätt att arbeta skall bildas samt om självaste arbete. I detta område finns tre ALPHA-kort vilka är Team, Work och Way-of-working.

2.5 Self-Governance Developer (SGD) Framework SGD Ramverket består av generella aktiviteter som kan väljas av mjukvaruutvecklare i en implementeringsprocess där testning ingår. Målet är att stödja utvecklare i deras dagliga arbete genom att assistera dem i att övervaka och kontrollera deras egna uppgifter. Målgruppen för detta ramverk är mjukvaruutvecklare vars huvudsakliga uppgift är att skriva, kompilera och testa kod. [7] I figur 3 framgår de olika delarna av SGD samt hur de är uppdelade. De olika aktiviteterna som visas i figur 3 beskrivs mer utförligt. Pre-Work Preliminary Activities (Preliminära Aktiviteter): Aktiviteter som skall genomföras innan implementering och testning. Ger utvecklarna de resurser som behövs för att utföra kvalitetsarbete.

9

Figur 3. Processen för SGD och vilka aktiviteter som ingår i respektive område. Planning Activities (Planering): stöd för att formulera initialt och löpande utvecklingsplaner. Aktiviteterna handlar bland annat om att granska nödvändiga dokument samt bestämma och planera arbetet. Work Preparatory Activities (Förberedande Aktiviteter): omfattar de aktiviteter som krävs för att förbereda genomförandet av arbetet. De hjälper utvecklare att bli redo för att skriva enhets testnings kod. Verksamheten hanterar låg-level design, enhet (utvecklare) testfall design, stubbar och drivrutiner och testmiljön. Coding Activities (Kodning): hanterar kod produktion inklusive att skriva/skriv om kod och kompilering. Testing Activities (Testverksamhet): aktiviteter som skall underlätta att koden uppfyller de angivna kvalitetsmålen. Evaluative Activities (Evaluering): behandlar utvärderingen av testresultat och bestämma nästa steg. Bör genomföras direkt efter enhetstest-verksamheten och innan nästa serie av genomföranden. Debugging Activities (Debugging Aktiviteter): hjälpmedel för att identifiera källorna till de fel som har upptäckts under sammanställning och testverksamheten. [7]

2.6 Mjukvaruutvecklingsproblem Mjukvaruutveckling och programvaruutveckling kan beskrivas som “tillämpningen av en systematisk, disciplinerad och mätbar metod för utvecklandet, användandet och underhållet av programvara” [18]. Problem som finns inom mjukvaruutvecklingen och som anses vara vanligt förekommande kommer att tas upp. Detta är problem som inte är relaterade till projekt som utförs men som anses vara uppmärksammade inom mjukvaruutvecklingsprojekt. Problemen som tas upp nedan är generella problem och är därmed inte anknutna till ett specifikt projekt eller arbetsområde.

10

Oproduktiv arbetsmiljö Arbetsmiljön är en faktor som påverkar produktiviteten för arbetsteamet. Till exempel kan en för hög ljudnivå eller för trång arbetsplats påverka både koncentrationen och motivationen för de anställda. Det är viktigt för de anställda att känna sig bekväma i deras arbetsplats för att kunna uppnå hög produktivitet. [19]

Ineffektiv projektledning Hur projektledaren väljer att leda sitt team kan påverka de anställda oerhört mycket. Projektledarens attityd gentemot arbetskultur och arbetsmoral ses av de anställda och implementerar samma eller liknande attityd. Därför är det viktigt att projektledaren har en positiv ställning och leder teamet med starka ledande egenskaper. [19]

Brist på intresse från aktörer Genom att aktörerna för projektet visar intresse och är aktiva i utvecklandet av produkten eller applikationen är det större sannolikhet att projektet blir lyckat. De måste vara lika hängivna till projektet som utvecklarna är. Det är viktigt för utvecklarna att se att intresset för produkten finns där från aktörerna vilket motiverar de ännu mer och ger högre produktivitet samt bättre resultat. [19]

Kommunikation Kommunikation inom teamet är ett vanligt problem som förekommer i denna typ av utvecklingsprojekt. Brist på kommunikation kan leda till problem som missade deadlines, förfrågningar av kunden och även dåligt utvecklade produkter som inte möter kundens behöv. [20]

Dålig schemaläggning Vissa team har problem med att ha en realistisk schemaläggning för uppdelade uppgifter. De kan vara oerhört utmanande för teamet men det kan också vara orealistiska tidsgränser. Om inte funktioner får den tillräckliga tid de behöver för implementering, testning och därmed koda om kommer problemen bara bli större i framtiden. [20] [21]

2.7 Relaterat arbete I en undersökning ”Developer’s time spent in a software project using the SGD Framework" av Ciesluk undersöker han hur tidsresurser spenderas som en individuell utvecklare i ett mjukvaruprojekt. Målet med Ciesluks undersökning var att tillhandhålla en bas för relevanta modeller som handskas med tidsplanering. Resultatet av undersökningen handlar om att redovisa hur mycket och var tidsresurserna spenderades för den utvecklaren som studerades under projektets gång. [22] Detta arbete är relevant för det här arbetet eftersom hur och var tidsresurser spenderas kan mycket väl vara en bidragande faktor till problem som uppstår i

11

mjukvaruprojekt. Projektets forskningsinstrument är dessutom SGD Framework, vilket även i denna utredning är ett av forskningsinstrumenten. Undersökningen visar att mest tids läggs på kodningsaktiviteter för den här utvecklaren som har studerats. Resultatet för den här studien visar att 11,75 timmar lagts på t.ex. preparatory activities, (se tabell 4) som handlar om förberedelse för kodningen medan 58,75 timmar lagts på kodningsaktiviteterna. I det projektet som utfördes på Ericsson lades i princip ingen tid alls på föreberedandet av kodningen ledde till problemet med ingen design att utgå ifrån. Genom att tidsfördela ordentligt kan man undvika ett sådant problem och spara tid.

12

13

3 Metod

Det här kapitlet handlar om metoden för studien. I det första delkapitlet (3.1) diskuteras forskningstyper och vilken forskningstyp som den här studien tillhör. I nästa delkapitel (3.2) framgår vilka forskningsfaser utredningen går igenom samt en beskrivning av varje fas. I det sista kapitlet (3.3) framgår utvärderingskriterierna.

3.1 Forskningstyper Varje forskning man gör tillhör en viss typ av forskning. Nedan kommer det nämnas och beskrivas vilka forskningstyper detta arbete tillhör och varför. Kvalitativ forskning, Aktionsforskning samt Induktivt resonemang är de olika forskningstyperna som kommer diskuteras.

3.1.1 Kvalitativ forskning Denna undersökning kan man säga är av kvalitativ natur. En kvalitativ undersökning handlar om att utforska eller undersöka ett relativt outforskat och ostrukturerat område. Syftet med undersökningen är att få en fördjupad förståelse för området. I en kvalitativ innebär det också att forskningsprocessens olika faser flyter in i varandra samt är parallella. I nästa kapitel kommer alla forskningsfaser beskrivas mer utförligt och därmed bekräfta att även denna punkt konfirmerar att detta är en forskning av kvalitativ typ. [5] [23]

Figur 4. Överblick över hela forskningsstrategin.

14

3.1.1.1 Aktionsforskning Eftersom metoden action research inkluderas i kvalitativ forskning är det en metod som används för denna undersökning. Action Research eller aktionsforskning kan beskrivas som att ha en direkt och omedelbar påverkan på forskningsområdet. I vårt fall handlar vår undersökning om att ta reda på problem som uppstår i ett utvecklingsprojekt. Genom att utföra projektet själva och dokumentera händelser innebär det att vi är både nära och har ett direkt förhållande till undersökningens syfte. [5]

3.1.2 Induktivt resonemang Induktivt resonemang innebär att man försöker hitta ett mönster genom flera observationer för att kunna förstå helheten eller med andra ord, formulera en generalisering. I vår undersökning försöker vi utifrån problemen som vi identifierat förstå en helhet och t.o.m. försöka generalisera problemen. Ta reda på om de uppstått p.g.a. specifika anledningar. [6]

3.1.3 Datainsamling Det finns ett flertal olika metoder för datainsamling, några exempel är intervjuer, observationer, enkäter och etnografisk metod [24]. I den här utredningen har det främst gjorts en observation i form av aktivt deltagande i ett mjukvaruutvecklingsprojekt. Det här projektet som kommer att beskrivas (kap 4) utfördes först och främst i syfte att utveckla en mjukvara som anställda på Ericsson kommer att använda i syfte att förenkla deras arbete hos deras kunder. Jag, som aktivt deltagande i detta projekt kommer även att använda projektet i syfte att identifiera problem för att kunna besvara min frågeställning som är en del av en studie på mitt universitet. För denna studie gällande att ta reda på om det går att hitta orsaker till uppkomna problem med hjälp av ramverk, är detta projekt en förstudie.

3.2 Faser Forskningsprocessen bestod av följande processer: genomförande av projekt, dagboksskrivande (aktiv uppföljning av projekt), litteraturstudie, problemidentifiering samt matchning av problem mot utvalda ramverk.

3.2.1 Genomförande av projekt Denna fas handlar om att genomföra projektet som vi fått i anmodan att utföra. Genomförandet av projektet skedde som ett ad-hoc projekt, dvs ingen arbetsmetod följdes. Det valdes att inte följa någon arbetsmetod och av naturliga skäl utdelades inte några specifika roller. Eftersom det bara var tre personer i projektet, kunde alla medverkande i arbetet, arbeta med det som fanns tillgängligt. Genomförandet av projektet handlade om att implementera ett mjukvarusystem som handlar om att mäta hastigheten för nedladdning av stora filer efter given kravspecifikation. Denna fas anses vara förstudien som gjorts för utredningen.

15

Figur 5. Forskningsfaserna i utredningen.

3.2.2 Aktiv uppföljning av projektet Under hela projektets gång skulle det skrivas dagbok för att dokumentera viktiga händelser. Bland annat beslut, konflikter, problem, lösningar skulle dokumenteras för att man vid projektets avslut skall kunna gå tillbaka och hitta relevant information tillgänglig. Detta tillstånd skedde parallellt med genomförandet av projektet. Vissa dagar skedde inga framsteg så då blev skrivandet glest medan andra dagar kunde beskrivas mer utförligt och detaljer tagits med.

3.2.3 Litteraturstudie I den här undersökningen/studien om problem som uppstår under ett ad-hoc projekt visade sig litteraturen (artiklar) vara begränsad. Området visade sig alltså vara förhållandevis outforskat. Mer specifikt är det området kring vilka problem som kan uppstå i ett metodlöst projekt som var outforskat. Syftet var att hitta litteratur som kunde konfirmera problemen som uppstod. Med en till källa blir undersökningen mycket mer trovärdig. Eftersom litteraturen då var begränsad gjordes istället en till matchning mot SGD. För att hitta litteratur användes databaser som IEEE Xplore, ACM och John Wiley & Sons. Sökord som användes kunde vara t.ex. problems IT project development, common mistakes software development, software development problems.

3.2.4 Problemidentifiering För att kunna identifiera problem användes dagboken. I efterhand användes dagboken för att gå igenom den och plocka upp de problem som uppstod och

16

dokumentera de som problem. Vissa problem var väldigt självklara medan andra problem inte alls var det och fick plockas ut från sammanhanget. Det viktiga var att identifiera problem som uppstod i anknytning till projektets struktur/metod och de tekniska problemen som hade en påverkan på hela projektets struktur. För att en händelse ur dagboken skulle identifieras som ett problem skulle det vara relaterat till projektets metod och struktur. Om det var ett tekniskt problem, skulle det kollas hur det påverkades av metoden/strukturen och därmed avgöra om det är ett problem som kan tas med i utredningen eller inte.

3.2.5 Matchning mot valda ramverk (SGD, Kernel Essence) Problemen som identifierats som problem skulle i denna fas jämföras med SGD och Kernel Essence i syfte att försöka hitta en relation mellan problemen och aktiviteter som utförts eller inte utförts i respektive metod/ramverk. Denna fas kan egentligen delas upp i två separata faser trots att båda faserna handlar om ramverken. Den första fasen handlade om att ta reda på vilka utföranden som kan göras för varje ramverk och samtidigt jämföra med dagboken om de har utförts eller inte. Den andra fasen handlar om att analysera resultatet av den tidigare fasen för att fastställa om det finns något samband med att aktiviteter inte utförts och problem som har uppstått. Därmed kan man också analysera om man hade kunnat undvika vissa problem genom att använda sig av en metod alternativt ett ramverk för projekt inom mjukvaruutveckling. Här är syftet att hitta en orsak till problemen och därefter kunna avgöra om detta är ett problem som uppstår oavsett eller om problemet hade kunnat undkommas.

3.3 Utvärderingskriterier Som utvärderingskriterier används ramverkens respektive aktiviteter. För varje tillstånd utvärderas aktiviteterna gentemot dagboken för att ta reda på om aktiviteten har utförts eller inte, eller i vissa fall, delvis utförts. Vid delvis utförd handlar det om att aktiviteten består av mer än en aktivitet och därmed har inte alla utförts eller om att aktiviteten endast utförts vid vissa tillfällen.

17

4 Uppdrag – Projekt

I det här kapitlet presenteras projektet som utförts mer ingående. I kap 4.1 framgår kort information om företag. I kap 4.2 diskuteras produkten, dvs mjukvaran som implementeras, hur den skall fungera samt syftet för den. I det sista kapitlet (4.3) beskrivs arbetsmetoden. Det här kapitlet är väsentligt eftersom det ger en inblick över hur projektet har gått till, vad det är för mjukvara som har utvecklats och hur arbetsteamet har gått tillväga för att utveckla den. Det är även relevant att förstå projektet och få en beskrivning för att kunna förstå hur och varför problemen som uppstått har uppstått. Projekt som har utförts refereras som Ericssonprojektet i fortsättningen för att kunna skilja på allmänna projekt och det specifika utförda projektet.

4.1 Företaget, Ericsson Ericsson är ett världsledande företag gällande kommunikationsteknik och tillhandahåller utrustning, programvara och tjänster för att möjliggöra kommunikationen. Det svenska företaget grundades år 1876 av Lars Magnus Ericsson men har etablerat sig över hela världen. Huvudkontoret finns dock i Kista, Stockholm. [25] Den 31 mars 2016 rapporterade Ericsson i deras kvartalsrapport att de hade 115 300 anställda inom företaget. [26] Undersökningen, dvs genomförandet av projektet skedde i Beirut, Libanon där Ericsson har ett av sina kontor. Projektet utfördes som en del av deras “Internship Program - Software Development” där studenter får möjlighet att engagera sig i ett specifikt projekt under en tio veckors period för att utveckla sina kunskaper inom mjukvaruutveckling i en verklig arbetsmiljö.

4.2 Produkt som utvecklats Användaren som använder applikationen ska kunna ansluta till en FTP (File Transfer Protocol) Server och därefter få tillgång till filerna på den servern och därmed kunna ladda ned valda filer. FTP är ett nätverksprotokoll som används för överföring av filer mellan en server och en klient. FTP är ett protokoll som förlitar på TCP (Transmission Control Protocol) för att förse en pålitlig dataström mellan klient och server. Alternativt kan UDP (User Datagram Protocol) användas istället för TCP. [27] Användaren interagerar genom ett användargränssnitt, där resultaten importeras och visas även i form av en graf.

4.2.1 Krav på produkten I tabell 1 beskrivs kravspecifikationen. I tabellen framgår funktionalitet, en kommentar samt prioritet för varje krav för projektet. Denna tabellen var given av intressenterna vid projektets start.

18

Tabell 1 Kravspecifikation från intressenterna för projektet.

Funktionalitet Kommentar Prioritet

FTPKlient Möjligheten att ansluta till en specific FTPServer -IP-adress -Användarnamn/Lösenord -Portnummer(standard21)

Grund-funktionalitet

FTPFil-nedladdning MöjlighetenattkunnaladdaneddenfilfrånFTP-Servern:- Sökväg för filen & namn på FTP-servern(statiskellerkonfiguerbar) -Downloadtobufferonlywithoutsavingondisk

Grund-funktionalitet

Indikeringavhastigheten

Möjligheten att kunna mäta och indikeradatahastighetenirealtid - Enhet (Mb/s, MB/s, kb/s, kB/s – statiskellerkonfiguerbar) -Digitalindikation(siffror)ellermätare

Grund-funktionalitet

Multitrådadellersegmenterad

FTPNedladdning

Möjligheten att tvinganedladdningshastigheten att nå maximalavärdetgenomattantingen:- Ladda ned flera filer samtidigt från FTPserver(multitrådning) -Delauppensinglefiltillflerasmåfiler,medvarsin anslutning och ladda ned demsamtidigt(segmenterad) - Antalet samverkande sessioner (antingenstatiskellerkonfiguerbart)

Ytterligarefunktionalitet (Lågprioritet)

UDPKlient Möjlighet att skapa en eller flera UDPströmmaravspecifikbandbreddiställetförattladdanedmedFTP

Ytterligarefunktionalitet (Lågprioritet)

4.2.2 Syfte med produkten Applikationen skapades i syfte att ha en mätare för bandbredden av Ericssons egna noder. Denna applikation skiljer sig från andra hastighetsmätare eftersom den inte kräver något specifikt program på servern när mätningen skall ske. Andra hastighetsmätare kan också vara baserade på algoritmer vilket kan innebära ett manipulerat resultat och kommer därmed inte att ge den exakta hastigheten för nedladdningen.

19

4.3 Arbetsprocess Teamet för detta projekt bestod av tre studenter. Under projektet valde vi att utföra projektet metodlöst, dvs. ad hoc. Vi hade inga specifika roller eller arbetsuppgifter tilldelade. Mellan oss i teamet skedde arbetet gemensamt. Man hade alltså inget ansvar för ett visst område, utan man hjälptes alltid åt och höll en överblick över projektets helhet. Det här arbetssättet kom det överens om i början av projektet då erfarenheterna mellan projektmedlemmarna låg på ungefär samma grundliga nivå och ingen person ville ta ansvar över något specifikt område. Det var alltså lämpligast att kunna förflytta sig mellan olika arbetsuppgifter i det här fallet. Projektgruppen bestod som tidigare nämnt av tre studenter i samma ålder. Trots att arbetet utfördes på ett stort och respekterat företag som Ericsson, var arbetsmiljön i gruppen väldigt avslappnad och bekväm trots nya bekantskaper. Mellan gruppen fanns ingen speciell struktur som följdes och inte heller under arbetsdagarna. Varje morgon innan arbetet sattes igång inleddes dagen med ett kort informellt möte där det diskuterades planering för dagen. Vad som behövde göras, vem som tar sig an vad och hur lång tid det kan beräknas ta. Detta informella morgonmöte var återkommande under hela arbetstiden. Handledning för projektet sköttes av två utvecklare som arbetade på Ericsson. Det är dessa två utvecklare som har utformat kraven på mjukvaran och även dessa två tillsammans med deras team som skall använda den. De fanns tillgängliga för oss på plats för eventuella frågor eller problem som kunde dyka upp men också via Skype ifall de inte befann sig på kontoret. Handledarna hade inga krav eller önskemål på mjukvaran förutom kravspecifikationen. De hade inte heller åsikter angående hur arbetet skulle gå till. Deras enda önskan var handledarmöten med mellanrum för att kunna kontrollera att arbetet gick rätt till. När problem uppstod diskuterades oftast vad nästa steg skulle bli och hur det kunde lösas på smidigast sätt. Detta gjordes mellan gruppen och vid de tillfällena problemet uppstod. Det var inga möten för sådana här typer av diskussioner, utan det skedde informellt och på plats. Det var viktigt att försöka lösa problemen så snart som möjligt för att undvika att förlora arbetstid. Den tid som förlorades p.g.a. problem ett (se tabell 2) som medförde förkortad arbetstid för hela projektet. I princip alla problem som beskrivs mer utförligt i kapitel fem, löstes internt i gruppen. Under projektets gång dokumenterades viktiga händelser i form av dagbok för att i kommande tiden kunna gå tillbaka och komma ihåg detaljerade händelser. Det var mest fokus på att dokumentera händelser som berodde på metoder, team och projekt. Resterande gruppmedlemmar hade ingen påverkan på dagboken förutom att de var medvetna om att den skrevs. Detta är på grund av att dagboken är en del av den här utredningen och inte en del av mjukvaruutvecklingen, vilket var det enda avseendet de var deltagande i.

20

21

5 Projektproblem

I det här kapitlet presenteras problem från Ericssonprojektet. Problem som har identifierats ifrån den aktiva uppföljningen som gjordes under projektets gång. Det är sex olika problem som uppstått under projektet som även är relevanta för studiens syfte. Dessa problem kan ses som resultatet av förstudien som beskrivs i kapitel 4. I kapitel 5.1 kommer en översikt av problem att presenteras och i kapitel 5.2-5.7 kommer varje problem beskrivas ingående.

5.1 Översikt av projektproblemen I tabell 2 ges en sammanfattning av problemen som har tagits med. Som tidigare nämnt är det här problemen som uppstått under Ericssonprojektet (se kap 4 för beskrivning av projektet). Under projektet uppstod även andra problem, t.ex. kodning och andra mindre problem. Det är således ett flertal andra problem som uppkommit av olika allvarlighetsgrad. Det är dock bara problem som verkligen påverkat projektet som tagits med och som kan bidra till studien.

5.2 Fel val av programmeringsspråk Vid projektets start valdes Java som programmeringsspråk utan någon större tanke på att jämföra vilka andra språk som kan vara lämpliga eftersom de flesta hade mest erfarenhet av Java. Java är dessutom ett stort och kraftfullt språk med mycket dokumentation. Ett par veckor in i projektet, efter ett flertal försök till att hitta en lösning till problemet insågs att det inte skulle vara möjligt. Funktioner som skulle implementeras kunde inte hanteras på ett vidare bra sätt

Tabell 2: Består av identifierade problem samt konsekvens.

ID Problem Konsekvens

1 Fel val av programmeringsspråk Förlorad arbetstid, mycket omarbete

2 Brist på planering Ingen struktur på projektet, ingen tidsuppfattning i teamet.

3 Ingen uppdelning av arbetsuppgifter Låg effektivitet samt produktivitet

4 För lite involvering av handledare Handledare kan ha åsikter som bör tas hänsyn till

5 Dålig kommunikation i teamet Låg effektivitet, påverkad arbetsmiljö

6 Ingen dokumentation/design att utgå ifrån

Fastnade i projektet, inget ordentligt flyt, omarbete.

22

i Java eller i tillhörande bibliotek. Den enda lösningen som ansågs vara lämplig var att börja om implementeringen i ett annat programmeringsspråk. Detta innebar förlorad tid eftersom ett antal andra funktioner redan programmerats och fungerat utan några problem. Vid val av ett nytt programmeringsspråk togs flera olika språk till hänsyn och jämfördes med varandra och även med Java för att inte göra om samma misstag igen och återigen förlora tid utav projektet. Det språk som valdes andra gången blev Python, vilket fungerade bra och samtliga funktioner kunde tillslut implementeras.

5.3 Brist på planering När projektet sattes igång gjordes ingen planering, varken en kortsiktig eller långsiktig planering. Arbetet var improviserat och spontant. Kravspecifikationen blev utgångspunkten för projektet och det var även där arbetet började. Detta ledde dock till ett ostrukturerat projekt. Ordningen av funktionerna som skulle implementeras styrdes av prioriteten given av intressenterna. Däremot fanns ingen tidsuppfattning gällande funktionerna. Istället för att uppskatta arbetstid för samtliga funktioner och försöka hålla denna tid så gott de gick, arbetades det bara på utan någon planering. Det gjorde det svårt att veta hur mycket tid som egentligen lagts ned på respektive uppgift. Planering i ett arbete är en grundsten och i brist på den är det inte märkvärdigt om många fler problem uppstår.

5.4 Ingen uppdelning av arbetsuppgifter I projektet utdelades inga roller. Det var således ingen person som hade ansvar för ett bestämt område. Detta ledde till att det inte blev någon ordentlig uppdelning av arbetsuppgifterna mellan teamet. I situationer där en större uppgift kunde delas upp i mindre deluppgifter för att dela upp arbetet, jobbade istället samtliga personer med ett och samma problem. Detta innebar att fler än en person arbetade med precis samma uppgift vid samma tidpunkt. Slutsatsen av detta arbetssätt var förlorad arbetstid samt låg produktivitet och effektivitet. Efter det första problemet med byte av programmeringsspråk, fanns inte något utrymme för mer förlorad tid. Det här löstes genom att faktiskt dela upp ett större hinder till flera små och individuellt ta sig an varsitt hinder. Om det var något mer avancerat kunde två personer arbeta med ett problem för att få hjälp av varandra.

5.5 För lite involvering av handledare Ett problem som uppstod handlar om ett tillfälle då vi utgått från ett av kraven från kravspecifikationen och tolkade det på ett annat sätt än det som egentligen syftades. I det här fallet hade handledarnas perspektiv varit viktigt för projektets riktning. Tid hade lagts på att försöka lösa ett problem som egentligen inte var ett problem. Handledarna finns där för att sådana situationer inte skall uppstå. På grund av det här problemet, sågs det alltid till att avstämma med handledare när det handlade om saker som kunde tolkas eller göras på mer än ett sätt.

23

5.6 Dålig kommunikation i gruppen Brist på kommunikation inom projektgruppen var inte ovanligt. Specifika händelser som när en av projektmedlemmarna valda att ta med sig arbetet hem efter avslutad arbetstid för att fortsätta arbetet hemifrån. Detta inträffade ett flertal gånger. Eftersom personen i fråga arbetade på flera olika uppgifter, alltså förutom sina egna ledde det till förvirring nästföljande dag för resterande personer. Arbetet fortsätter inte där det slutade och ändringar har gjorts man inte är medveten om eller har fått information om. Om större ändringar har skett som man inte informerats om, är det inte lätt att ta sig vidare i arbetet. Eftersom den här personen ansåg det vara viktigt att arbeta hemifrån i brist på tid blev lösningen att få uppdateringarna samma kväll så resterande personer kunde ha möjlighet att gå igenom eventuella ändringar och därmed hamna i fas inför nästkommande arbetsdag.

5.7 Ingen dokumentation eller design att utgå ifrån I det här projektet gjordes ingen design för mjukvaran innan implementationen sattes igång. Det fanns sålunda varken någon design eller dokumentation att utgå ifrån. Att börja programmera var det första steget i utvecklingen av mjukvaran. På grund av detta kunde projektet många gånger inte fortsätta. Utan någon design eller dokumentation var inte nästa steg alltid givet. Det var även svårt att få flera funktioner att samarbeta i ett program. Lösningen på det här problemet var ett antal gånger att gå tillbaka ett par steg och göra om. I vissa situationer kunde det räcka med att man pausar projektet, designar projektets tillstånd och försöker hitta en lösning för att därefter implementera upptäckt lösning. Med hjälp av ordentlig dokumentering som inkluderar bl.a. design av mjukvaran hade man kunnat utgå helt ifrån den under implementeringsfasen och undkommit sådana problem samt sparat arbetstid.

24

25

6 Aktiviteter från Essence, SGD

I det här kapitlet presenteras vilka aktiviteter som har utförts i varje ramverk, SGD och Kernel Essence. Eftersom Ericssonprojektet utfördes metodlöst, är en del av studien att i efterhand gå igenom respektive ramverks aktiviteter för att ta reda på vilka aktiviteter som genomförts omedvetet och vilka som uteblivits. Kapitel 6.1 presenterar resultatet av jämförelsen av Ericssonprojektet och SGD ramverket. Kapitel 6.2 presenterar resultatet av jämförelsen av Ericssonprojektet och Kernel Essence. Resultaten av jämförelserna presenteras i form av tabeller.

6.1 SGD ramverk I det här kapitlet finns resultat och sammanfattning av SGD resultatet. I tabellerna nedan framförs vilka aktiviteter som utförts. Plustecknet (+) innebär att aktiviteten genomförts, minustecknet (-) innebär att aktiviteten inte genomförts och bokstaven D menar att den delvis utförts. I tabell 3 presenteras resultatet för Pre-Work aktiviteterna, som består av preliminära aktiviteter och planerade aktiviteter. I tabell 4 presenteras Work aktiviteterna, som består av förberedande aktiviteter, kodningsaktiviteter, testningsaktiviteter, evalueringsaktiviteter och buggningsaktiviteter.

Tabell 3: Utförda aktiviteter i SGD Pre-Work Activities.

SGD PRE-WORK ACTIVITIES SGD PRE-WORK: PRELIMINARY ACTIVITIES

PR-1: Review and agree on the overall or part of the project plan - PR-2: Revise and ensure that the technology to be used is tested and understood

D

PR-3: Revise and understand any appropriate internal (organizational) and external standards

-

PR-4: Learn/relearn the organization’s implementation and unit (developer) testing way of work

-

PR-5: Review and revise your personal implementation and unit (developer’s) testing way of working

-

PR-6: Sign your personal Service Level Agreement (Work Contract) - SGD PRE-WORK: PLANNING ACTIVITIES

PL-1: Review the requirements or the units to be developed + PL-2: Prepare and/or review the design specification for the units to be developed

-

PL-3: Resolve unclear questions and uncertainties + PL-4: Determine and document your implementation and unit (developer) testing goals

-

PL-5: Determine your implementation and unit (developer) testing strategy/strategies

D

PL-6: Determine appropriate implementation and unit (developer) testing practices

-

PL-7: Identify standards to be used for meeting your goals -

26

PL-8: Set your own personal deadlines to be met during your implementation and unit (developer) testing work

+

PL-9: Estimate effort and resources required for carrying out your work

-

PL-10: Schedule your work D PL-11: Review your implementation and unit (developer) testing plan to ensure that it is realistic and achievable

-

PL-12: Identify risks related to your plan - PL-13: Plan for managing any identified risks -

Tabell 4: Utförda aktiviteter i SGD Work Activities.

SGD WORK ACTIVITIES SGD WORK: PREPARATORY ACTIVITIES

P-1: Prepare and/or review the low-level designs of the code to be written or changed

-

P-2: Prepare (make) impact analysis of the low-level designs - P-3: Determine the types of unit (developer) test cases and their order D P-4: Create and/or revise your unit (developer) test case base. - P-5: Revise the existing unit (developer) regression test base, if relevant

-

P-6: Create or modify stubs and drivers, if required - P-7: Prepare your unit (developer) testing environment and check whether it is appropriate for your work

-

SGD PRE-WORK: CODING ACTIVITIES C-1: Write/rewrite your code + C-2: Compile/recompile your code as required + C-3: Make notes on your compilation errors, if necessary + C-4: Make notes on your defects +

SGD WORK: TESTING ACTIVITIES T-1: Check whether the unit (developer) test case base meet the given requirements and design

-

T-2: Check whether the unit (developer) regression test base meets the given requirements and design

-

T-3: Remedy requirements problems in your unit (developer) regression and/or test cases, if any.

-

T-4: Perform dynamic testing by executing code + T-5: Perform static (human) testing by reviewing your code + T-6: Record/write down test results +

SGD WORK: EVALUATE ACTIVITIES E-1: Analyze your unit (developer) testing results + E-2: Depending on the unit (developer) testing results, determine your next step(s)

+

SGD WORK: DEBUGGING ACTIVITIES D-1: Identify the source(s) of an error + D-2: Determine solution(s) for eliminating the sources of error(s) +

27

6.1.1 Sammanfattning för SGD I det här kapitlet finns en sammanfattning för varje område av aktiviteter. Som det framgår i tabell 3 och 4 är det sju olika typer av aktiviteter där varje typ har som minst två aktiviteter och som mest 13.

6.1.1.1 Preliminary Activities Preliminary Activities handlar om aktiviteter som skall vara förberedande för projektet. I tabellen ovan kan man se att av sex aktiviteter, utfördes en delvis medan resten inte utfördes alls. Teknologin som användes första gången var programmeringsspråket Java. Detta språk behärskades av samtliga projektmedlemmar. Däremot testades inte ifall språket skulle vara passande för denna implementationen och därför är denna aktivitet endast markerad som delvis utförd. Resterande aktiviteter utfördes alltså inte. Det gjordes därmed inte så mycket förberedelse för projektet.

6.1.1.2 Planning Activities Planning Activities handlar om aktiviteter som skall ha ett planeringssyfte för projektet. I tabellen ovan kan man se att åtta aktiviteter inte har utförts, vilket lämnar tre utförda punkter samt två punkter som delvis utförda. Kravspecifikationen samt frågor som berör den hanterades tidigt i projektet eftersom den är grunden för hela utvecklingen. Aktiviteter gällande identifiering av risker, förberedelse av design, testning, dokument har inte utförts alls. Prioriteringen var alltså kraven samt hur vi själva skulle arbeta, som t.ex. att sätta egna deadlines för att förenkla arbetet för oss.

6.1.1.3 Preparatory Activities Preparatory Activities handlar om aktiviteter som skall ha ett förberedande syfte och ingår även i Work Activities. Preparatory Activities består av sju aktiviteter varav en aktivitet delvis utfördes och resterande inte. Testfallen utfördes i den ordning prioriteringen angavs i kravspecifikationen. Resterande aktiviteter handlar om design av koden, analys av koden, skriva testfall, regressionstester samt testmiljöer, inga av nämnda områden förbereddes.

6.1.1.4 Coding Activities Coding Activities handlar om aktiviteter som berör kodningen för projektet. Coding Activities består av fyra aktiviteter varav alla har utförts. Den här processen upprepades ett flertal gånger. Det fanns alltid exekveringsfel som behövde åtgärdas och därefter påbörja processen på nytt igen. Det kunde vissa gånger ta flera omgångar innan problemet blivit löst.

6.1.1.5 Testing Activities Testing Activities handlar om aktiviteter som berör testningen för projektet. Testing Activities består av sex aktiviteter varav hälften utfördes och hälften inte. För vårt fall var det relevant med dynamisk testning, där vi exekverar koden och utifrån resultatet av exekveringen kan avgöra hur vi skall fortsätta. Oavsett resultat, dokumenteras resultatet i syfte att hålla koll på ändringar som görs i koden samt hålla ordning på vilka ändringar som medför vilka nya resultat.

28

6.1.1.6 Evaluate Activities Evaluate Activities handlar om att utvärdera resultaten och därmed kunna avgöra hur nästa steg skall ske. Detta stadie består av två aktiviteter och de har båda utförts.

6.1.1.7 Debugging Activities Debugging Activities handlar om att felsöka efter problem, hitta orsaken samt bestämma hur man skall gå tillväga för att eliminera problemet. Består av två aktiviteter som båda utfördes. Detta är en process som sker varje gång man får problem i koden.

6.2 Kernel Essence I det här delkapitlet presenteras resultatet och en sammanfattning för Kernel Essence. I varje delkapitel för de olika områdena inom ramverket presenteras tabellerna samt en sammanfattning. De olika områdena är Stakeholders (6.2.1), Opportunity (6.2.2), Requirements (6.2.3), Software System (6.2.4), Team (6.2.5), Work (6.2.6), Way-of-working (6.2.7). Plustecknet (+) innebär att aktiviteten genomförts, minustecknet (-) innebär att aktiviteten inte genomförts och bokstaven D menar att den delvis utförts. Följande symbolen gäller för alla tabeller.

6.2.1 Stakeholders Stakeholders även intressenter, är det första av sju områden som har jämförts med Ericssonprojektet. Tabellen 5 visar resultatet av jämförelsen för dem olika tillstånden. I det här kapitlet sammanfattas även tabellen, se kap. 6.2.1.1.

6.2.1.1 Sammanfattning av Stakeholders Recognized (1/6): Recognized består av tre aktiviteter som handlar om att identifiera intressenterna. Vid detta stadie var aktörerna representerade, däremot inte vilka ansvarsområden de skulle ha. Represented (2/6): Represented består av fyra aktiviteter varav alla har checkats av. Dessa handlar om att de intressenter som skall representera resterande intressenter har kommit överens med oss om deras roll i projektet. Dessa representanter är alltså handledarna för projektet. De hade inga invändningar gällande hur teamet valt att arbeta, så länge mjukvaran blev färdig enligt deras krav. Involved (3/6): Involved handlar intressenternas involvering i projektet och består av tre möjliga utföranden. I detta fall har alla utförts. Från handledarnas sida var deras involvering väldigt bra och de fanns tillgängliga för frågor och diskussioner när det behövdes. In Agreement (4/6): In Agreement handlar om att representanterna (handledarna) skall vara i ömsesidig förståelse med projektmedlemmarna. Alla punkter har utförts. Detta är eftersom kontakten med handledarna alltid var bra och vi kunde kommunicera utan några problem.

29

Satisfied for Deployment (5/6): Representanterna fungerade som en brygga mellan utvecklare och intressenter. De kom med feedback från övriga intressenter. Efter avslutat projekt ansåg representanterna att mjukvaran var i ett tillstånd att användas. Satiesfied in Use (6/6): Detta handlar om intressenterna använder sig av systemet vilket det inte finns någon information om och därför kan vi inte heller veta om systemet möter deras förväntningar. Den enda respons angående systemet var vid en kort demonstration som gjordes för representanterna där deras feedback var väldigt positiv.

Tabell 5. Utförda aktiviteter för Stakeholders

STAKEHOLDERS RECOGNIZED (1/6)

REC-1: All the different groups of stakeholders that are, or will be affected by the development and operation of the software are identified

+

REC-2: There is agreement in the stakeholder groups to be represented. At a minimum, the stakeholder groups that fund, use, support, and maintain the system have been considered.

+

REC-3: The responsibilities of the stakeholder representatives have been defined.

-

REPRESENTED (2/6) REP-1: The stakeholder representatives have agreed to take on their responsibilities

+

REP-2: The stakeholder representatives are authorized to carry out their responsibilities

+

REP-3: The collaborative approach among the stakeholder representatives has been agreed

+

REP-4: The stakeholder representatives support and respect the team’s way of working

+

INVOLVED (3/6) IN-1: The stakeholder representatives assist the team in accordance with their responsibilities

+

IN-2: The stakeholder representatives provide feedback and take part in the decision making in a timely manner

+

IN-3: The stakeholder representatives promptly communicate changes that are relevant for their stakeholder groups

+

IN AGREEMENT (4/6) IA-1: The stakeholder representatives have agreed upon their minimal expectations for the next deployment of the new system

+

IA-2: The stakeholder representatives are happy with their involvement in the work

+

IA-3: The stakeholder representatives agree that their input is valued by the team and treated with respect

+

IA-4: The stakeholder representatives support and respect the team’s way of working

+

30

6.2.2 Opportunity Opportunity även möjligheten, är det andra av sju områden som har jämförts med Ericssonprojektet. Tabell 6 visar resultatet av jämförelsen för dem olika tillstånden.

Tabell 6. Utförda aktiviteter för Opportunity

IA-5: The team members agree that their input is valued by the stakeholder representatives and treated with respect

+

IA-6: The stakeholder representatives agree with how their different priorities and perspectives are being balanced to provide a clear direction for the team

+

SATISFIED FOR DEPLOYMENT (5/6) SD-1: The stakeholder representatives provide feedback on the system from their stakeholder group perspective

+

SD-2: The stakeholder representatives confirm that they agree that the new system is ready for deployment

+

SATISFIED IN USE (6/6) SU-1: Stakeholders are using the new system and providing feedback on their experiences

-

SU-2: The stakeholders confirm that the new system meets their expectations

-

OPPORTUNITY IDENTIFIED(1/6)

ID-1: An idea for a way of improving current ways of working, increasing market share, or applying a new or innovative software system has been identified

+

ID-2: At least one of the stakeholders wishes to make an investment in better understanding the opportunity and the

-

ID-3: The other stakeholders who share the opportunity have been identified

-

SOLUTION NEEDED (2/6) SN-1: The stakeholders in the opportunity and the proposed solution have been identified

+

SN-2: The stakeholder’s needs that generate the opportunity have been established

+

SN-3: Any underlying problems and their root causes have been identified

+

SN-4: It has been confirmed that a software-based solution is needed + SN-5: At least one software-based solution has been proposed +

VALUE ESTABLISHED (3/6) VE-1: The value of addressing the opportunity has been quantified either in absolute terms or in returns or savings per time period

-

VE-2: The impact of the solution on the stakeholders is understood +

31

6.2.2.1 Sammanfattning av Opportunity Identified (1/6): En möjlighet för att förbättra det dåvarande systemet identifierades och det är den punkten som checkats av. En av punkterna i detta stadie handlar om intressenters önskan att investera i möjligheten, vilket inte var relevant för oss. För oss var intressenten Ericsson som företag, som representerades av handledarna. Solution Needed (2/6): I detta tillstånd har samtliga checkpunkter utförts. De handlar främst om att vara överens om att ett problem finns och en lösning skall tas fram. Det handlar även om att ta fram ett förslag för en lösning till problemet. Value Establish (3/6): I detta tillstånd finns fem punkter varav det är endast en som markerats som utebliven. Det ingick inte i projektet att beräkna avkastningen eller besparingar per tidsperiod. Som studenter som skulle utveckla denna mjukvara ingick det inte att göra sådana beräkningar. Det var förstått vilket värde mjukvaran skulle ha för de som skall använda den och även vilka kriterier som den ska dömas ifrån.

VE-3: The value that the software systems offer to the stakeholders that fund and use the software system is understood

+

VE-4: The success criteria by which the deployment of the software system is to be judged are clear

+

VE-5: The desired outcomes required of the solution are clear and quantified

+

VIABLE (4/6) VI-1: A solution has been outlined - VI-2: The indications are that the solution can be developed and deployed within constraints

+

VI-3: The risks associated with the solution are acceptable and manageable

-

VI-4: The indicative costs of the solution are less than the anticipated value of the opportunity

-

VI-5: The reasons for the development of a software-based solution are understood by all members of the team

+

VI-6: The pursuit of the opportunity is viable - ADDRESSED (5/6)

AD-1: A usable system that demonstrably addresses the opportunity is available

+

AD-2: The stakeholders agree that the available solution is worth deploying

-

AD-3: The stakeholders are satisfied that the solution produced addresses the opportunity

D

BENEFIT ACCRUED (6/6) BA-1: The solution has started to accrue benefits for the stakeholders - BA-2: The return-on-investment profile is at least as good as anticipated

-

32

Viable (4/6): I det här tillståndet finns sex checkpunkter, varav två stycken har gjorts. De som har utförts handlar om att det finns indikationer på att en lösning kan utvecklas och sättas i bruk samt att anledningen till utvecklandet är förstådd av samtliga medlemmar i teamet. Addressed (5/6): Adressed består endast av tre checkpunkter. Det användbara systemet motsvarar kraven som var givna samt adresserar möjligheten. Om intressenterna anser att systemet skall sättas i bruk har vi ingen information om idag. Den sista punkter handlar om intressenterna är nöjda med resultatet. Denna är delvis utförd eftersom vi endast visade upp mjukvaran för representanterna. Benefit Accrued (6/6): Projektet är inte ett sådant som kan ge fördelar förrän det är satt i bruk, vilket vi inte har någon information om. Avkastningen för projektet är inte relevant. Detta innebär alltså att ingen av punkterna för detta tillstånd utfördes i projektet.

6.2.3 Requirements Requirements, även kraven, är det tredje av sju områden som har jämförts med Ericssonprojektet. Tabell 7 visar resultatet av jämförelsen för dem olika tillstånden.

Tabell 7. Utförda aktiviteter i Requirements

REQUIREMENTS CONCEIVED(1/6)

CD-1: The initial set of stakeholders agrees that a system is to be produced

+

CD-2: The stakeholders that will use the new system are identified + CD-3: The stakeholders that will fund the initial work on the new system are identified

+

CD-4: There is clear opportunity for the new system to address + BOUNDED (2/6)

B-1: The stakeholders involved in developing the new system are identified

+

B-2: The stakeholders agree on the purpose of the new system + B-3: It is clear what success is for the new system + B-4: The stakeholders have a shared understanding of the extent of the proposed solution

+

B-5: The way the requirements will be described is agreed upon +

B-6: The mechanisms for managing the requirements are in place +

B-7: The prioritization scheme is clear + B-8: Constraints are identified and considered + B-9: Assumptions are clearly stated D

COHERENT (3/6) CT-1: The requirements are captured and shared with the team and the stakeholders

-

33

6.2.3.1 Sammanfattning av Requirements Conceived (1/6): Av fyra punkter har alla checkats av. Dessa handlar om att komma överens om att ett system skall tas fram, om att identifiera intressenterna som skall använda mjukvaran och om att det finns ett tydligt tillfälle att ta fram det nya systemet. Bounded (2/6): Även i detta tillstånd som består av nio checkpunkter har en punkt delvis gjorts och resterande utförts helt. Dessa handlar generellt om intressenterna, syftet och målet med utvecklandet av mjukvaran, kravspecifikationen och prioriterar gällande den. Antaganden från teamets håll

CT-2: The origin of the requirements is clear + CT-3: The rationale behind the requirements is clear + CT-4: Conflicting requirements are identified and attended to + CT-5: The requirements communicate the essential characteristics of the system to be delivered

-

CT-6: The most important usage scenarios for the system can be explained

+

CT-7: The priority of the requirements is clear + CT-8: The impact of implementing the requirements is understood + CT-9: The team understands what must be delivered and agrees to deliver it

+

ACCEPTABLE (4/6) A-1: The stakeholders accept that the requirements describe an acceptable solution

+

A-2: The rate of change to the agreed requirements is relatively low and under control

+

A-3: The value provided by implementing the requirements is clear + A-4: The parts of the opportunity satisfied by the requirements are clear

+

A-5: The requirements are testable + ADDRESSED (5/6)

AD-1: Enough of the requirements are addressed for the resulting system to be acceptable to the stakeholders

+

AD-2: The stakeholders accept the requirements as accurately reflecting what the system does and does not do

+

AD-3: The set of requirement items implemented provide clear value to the stakeholders

+

AD-4: The system implementing the requirements is accepted by the stakeholders as worth making operational

-

FULFILLED (6/6) FU-1: The stakeholders accept the requirements as accurately capturing what they require to fully satisfy the need for a new system

+

FU-2: There are no outstanding requirement items preventing the system from being accepted as fully satisfying the requirements

+

FU-3: The system is accepted by stakeholders as fully satisfying the requirements

+

34

gjordes och reddes ut med handledare (även kallade representanter), dock inte gällande allt. Coherent (3/6): Detta tillstånd handlar om kraven och om teamet har förstått dem, dvs sammanhängandet mellan krav och team. I det här stadiet kunde alla checkpunkter utföras. Det fanns inga oklarheter och det var väldigt tydligt vad som skulle göras. Acceptable (4/6): Acceptable handlar bl.a. om att hur kraven formats skall accepteras av intressenterna. Eftersom vi fick en given kravspecifikation var denna punkt redan uppfylld. Resterande punkter har också utförts. Addressed (5/6): Addressed består av fyra checkpunkter där endast en inte har utförts. Denna handlar om intressenternas åsikt angående att sätta systemet i bruk. Detta fick vi ingen information om. Fulfilled (6/6): Fulfilled handlar om att kraven är uppfyllda eller inte. I det här tillståndet har alla checkpunkter utförts. Systemet var accepterat av representanterna för intressenterna.

6.2.4 Software System Software System, även mjukvarusystem är det fjärde av sju områden som har jämförts med Ericssonprojektet. Tabell 8 visar resultatet av jämförelsen för dom olika tillstånden.

Tabell 8. Utförda aktiviteter i Software System

SOFTWARE SYSTEM ARCHITECTURE SELECTED (1/6)

AS-1: The criteria to be used when selecting the architecture have been agreed on

-

AS-2: Hardware platforms have been identified - AS-3: Programming languages and technologies to be used have been selected

+

AS-4: System boundary is known + AS-5: Significant decisions about the organizations of the system has been made

-

AS-6: Buy, build and reuse decisions have been made - AS-7: Key technical risks agreed to -

DEMONSTRABLE (2/6) DE-1: Key architectural characteristics have been demonstrated - DE-2: The system can be exercised and its performance can be measured

-

DE-3: Critical hardware configurations have been demonstrated - DE-4: Critical interfaces have been demonstrated -

DE-5: The integration with existing systems has been demonstrated -

DE-6: The relevant stakeholders agree that the demonstrated architecture is appropriate

-

USABLE (3/6)

35

6.2.4.1 Sammanfattning av Software System Architecture Selected (1/6): Det här tillståndet handlar i stort sett om att välja en arkitektur för systemet som skall utvecklas. Det är mycket i detta tillstånd som inte har utförts p.g.a. inte mycket tid lades på att förbereda för utvecklandet. De punkter som däremot har gjorts handlar om att ha valt programmeringsspråk samt kännedom av systemets gränser. Demonstrable (2/6): I detta tillstånd har ingen av checkpunkterna utförts. Som det nämndes tidigare lades det inte tid på att förbereda för utvecklandet och därför kan ingen av aktiviteterna i det här tillståndet markeras som utförda. Usable (3/6): I detta tillstånd handlar det om hur användbart systemet är. Systemets funktioner testades och klarade testerna, intressenternas representanter kunde använda sig av systemet och var accepterat. Att systemet är fullt dokumenterat har delvis gjorts. Detta eftersom det inte gjordes någon design från någon början. Däremot var vi noggranna med att kommentera koden för att framtida utvecklare skall kunna ha full förståelse ifall någon vidareutveckling skall ske. Ready (4/6): Det här tillståndet handlar om hur redo systemet är för att användas. Representanterna ansåg systemet vara färdigt och redo att sättas i bruk. Den dokumentation samt installation som är nödvändig för att förstå och använda systemet är given.

U-1: The system can be operated by stakeholders who use it + U-2: The functionality provided by the system has been tested + U-3: The performance of the system is acceptable to the stakeholders + U-4: Defect levels are acceptable to the stakeholders + U-5: The system is fully documented D

U-6: Release content is known - U-7: The added value provided by the system is clear +

READY (4/6) RE-1: Installation and other user documentation are available + RE-2: The stakeholder representatives accept the system as fit-for-purpose

+

RE-3: The stakeholder representatives want to make the system operational

+

RE-4: Operational support is in place - OPERATIONAL (5/6)

OP-1: The system has been made available to the stakeholders intended to use it

-

OP-2: At least one example of the system is fully operational + OP-3: The system is fully supported to the agreed service levels +

RETIRED (6/6) RE-1: The system has been replaced or discontinued - RE-2: The system is no longer supported - RE-3: There are no “official” stakeholders who still use the system - RE-4: Updates to the system will no longer be produced -

36

Operational (5/6): Det här tillståndet handlar om systemet är operativt eller inte. Vid projektets slut fanns en färdig version som kunde användas. Denna visades senare för resterande representanter, dock var vi inte närvarande eftersom praktiken hade avslutats. Retired (6/6): I detta tillstånd har inga checkpunkter utförts. Eftersom vi lämnade en klar version av systemet har vi ingen information om det har hunnit bli ersatt osv.

6.2.5 Team Team, även arbetsgrupp, är det femte av sju områden som har jämförts med Ericssonprojektet. Tabell 9 visar resultaten av jämförelsen för dem olika tillstånden.

Tabell 9. Utförda aktiviteter i Team

TEAM SEEDED (1/5)

SE-1: The team mission has been defined in terms of the opportunities and outcomes

+

SE-2: Constraints on the team’s operation are known + SE-3: Mechanisms to grow the team are in place + SE-4: The composition of the team is defined + SE-5: Any constraints on where and how the work is carried out are defined

+

SE-6: The team’s responsibilities are outlined + SE-7: The level of team commitment is clear + SE-8: Required competencies are defined + SE-9: The team size is determined + SE-10: Governance rules are defined + SE-11: Leadership model is selected -

FORMED (2/5) F-1: Individual responsibilities are understood - F-2: Enough team members have been recruited to enable the work to progress

+

F-3: Every team member understands how the team is organized and what their individual role is

-

F-4: All team members understand how to perform their work - F-5: The team members have met and are beginning to know each other

+

F-6: The team members understand their responsibilities and how they align with their competencies

+

F-7: Team members are accepting work + F-8: Any external collaborators (organizations, teams and individuals) are identified

+

F-9: Team communication mechanisms have been defined + F-10: Each team members know each other +

COLLABORATING (3/5) CO-1: The team is working as one cohesive unit D

37

6.2.5.1 Sammanfattning av Team Seeded (1/5): I tillståndet Seeded har de flesta punkter kunnats markera som utförda, vilket lämnar kvar en punkt markerad som icke utförd. Det valdes ingen ledarskapsmodell för arbetslaget p.g.a. det inte ansågs finnas behov för det. Många av de utförda punkterna handlar bl.a. om teamet, storleken på teamet, ansvarsområden och teamets syfte. Formed (2/5): I det här tillståndet har även här de flesta aktiviteter utförts. De tre punkter som inte utförts handlar om att varje medlem förstår hur teamet är organiserat och vad den individuella rollen är. Den andra punkten handlar om att varje medlem skall förstå hur den skall utföra sitt arbete. Den tredje innebär att varje person förstår sina egna ansvarsområden. Detta utfördes inte heller eftersom det inte skedde en direkt uppdelning av arbetet och därmed fick man inte ansvar över ett specifikt område. Collaborating (3/5): Detta tillstånd består av totalt fyra checkpunkter, där två har utförts helt medan två endast delvis utförts. De som delvis blivit utförda handlar om att teamet fungerar som en enhet, detta varierade och därför anses det vara delvis. Den andra delvis utföra handlar om kommunikationen inom teamet, vilket också varierade mycket. Performing (4/5): I detta tillstånd mäts hur väl teamet arbetar med dem ansvarsområden samt uppgifter de fått. Effektiviteten i arbetet var inte hög och backning i arbetet gick inte att undvika. Adjourned (5/5): Efter avslutat arbete och inlämning av system hade teamet inte längre några ansvarområden att ta sig an. Teamet var därför inte tillgängligt för arbete med andra team. Inga ytterligare ansträngningar gjordes av teamet efter överlämnat system.

CO-2: Communication within the team is open and honest D CO-3: The team is focused on achieving the team mission + CO-4: The team members know each other +

PERFORMING (4/5) P-1: The team consistently meet its commitments + P-2: The team continuously adapts to the changing context + P-3: The team identifies and addresses problem without outside help + P-4: Effective progress is being achieved with minimal avoidable backtracking and reworking

-

P-5: Wasted work and the potential for wasted work are continuously eliminated

-

ADJOURNED (5/5) A-1: The team’s responsibilities have been handed over or fulfilled + A-2: The team members are available for assignment to other teams - A-3: No further effort is being put in by the team to complete the mission

-

38

6.2.6 Work Work, även arbete, är det sjätte av sju områden som har jämförts med Ericssonprojektet. Tabell 10 visar resultatet av jämförelsen för dem olika tillstånden.

Tabell 10. Utförda aktiviteter i Work

WORK INITIATED (1/6)

IN-1: The result required of the work being initiated is clear -

IN-2: Any constraints on the work’s performance are clearly identified + IN-3: The stakeholders that will fund the work are known + IN-4: The initiator of the work is clearly identified + IN-5: The stakeholders that will accept the results are known +

IN-6: The source of funding is clear + IN-7: The priority of the work is clear +

PREPARED (2/6) PR-1: Commitment is made + PR-2: Cost and effort of the work is estimated - PR-3: Resource availability is understood + PR-4: Governance policies and procedures are clear +

PR-5: Risk exposure is understood -

PR-6: Acceptance criteria are defined and agreed with client +

PR-7: The work is broken down sufficiently for productive work to start -

PR-8: Tasks have been identified and prioritized by the team and stakeholders

+

PR-9: A credible plan is in place -

PR-10: Funding to start the work is in place -

PR-11: The team or at least some of the team members are ready to start the work

+

PR-12: Integration and delivery points are defined +

STARTED (3/6) ST-1: Development work has been started + ST-2: Work progress is monitored + ST-3: The work is being broken down into actionable work items with clear definitions of done

-

ST-4: Team members are accepting and progressing tasks + UNDER CONTROL (4/6)

UC-1: Tasks are being completed + UC-2: Unplanned work is under control +

39

6.2.6.1 Sammanfattning av Work Initiated (1/6): Det här tillståndet handlar om att arbetet skall inledas. Arbetet som bör ha gjorts innan arbetet inleddes gjordes inte. Detta är den enda aktivitet som inte har utförts i detta tillstånd. Prepared (2/6): Detta tillstånd handlar om förberedandet för arbetet. Tillståndet består av 12 checkpunkter där sju har utförts och resterande inte. Kostnad och ansträngning för arbetet beräknades inte. Det gjordes ingen sådan beräkning för projektet. Arbetet delades inte upp i beståndsdelar och det gjordes ingen trolig plan för projektet. De förberedelser som var mest relevanta gjordes inte. Flest aktiviteter som inte utfördes finns under detta tillståndet. Eftersom det inte skedde mycket planering kring projektet skedde inte heller så mycket förberedelse och därav inte fler utförda aktiviteter. Started (3/6): Detta tillstånd handlar om projektets start. Detta tillstånd består av fyra checkpunkter där alla har utförts förutom en. Den punkten som handlar om att bryta ned arbetet i mindre delar där varje del skall ha sitt syfte har inte utförts eftersom det inte skedde en ordentlig uppdelning av arbetet där varje del hade ett klart syfte. Under Control (4/6): I det här tillståndet finns checkpunkter som innebär att uppgifter blir färdiga samt att riskerna är under kontroll. Checkpunkter som berör dessa områden är genomförda. Estimeringar för att reflektera teamets ansträngningar samt mätningar för att visa framsteg genomfördes inte. Det uttrycktes inte ett sådant behov av representanterna. Concluded (5/6): I detta tillstånd bestående av tre checkpunkter har samtliga genomförts. Handlar främst om att ett resultat har uppnåtts som intressenterna har accepterat.

UC-3: Risks are under control as the impact if they occur and the likelihood of them occurring have been reduced to acceptable levels

+

UC-4: Estimates are revised to reflect the team’s performance - UC-5: Measures are available to show progress and velocity - UC-6: Re-work is under control + UC-7: Tasks are consistently completed on time and within their estimates

+

CONCLUDED (5/6) CO-1: All outstanding tasks are administrative housekeeping or related to preparing the next piece of work

+

CO-2: Work results have been achieved + CO-3: The stakeholders have accepted the resulting software system +

CLOSED (6/6) CL-1: Lesson learned have been itemized, recorded and discussed - CL-2: Metrics have been made available - CL-3: Everything has been achieved + CL-4: The budget has been reconciled and closed - CL-5: The team has been released + CL-6: There are no outstanding, uncompleted tasks +

40

Closed (6/6): Vid detta tillstånd hade allt som behövt genomföras avslutats och teamet har inte längre något ansvar eller uppgifter att utföra. Tre checkpunkter har dock lämnats ogenomförda; Eftersom vi inte hade någon kontroll över budgeten var det inte relevant för oss att genomföra denna punkt som behandlar det. De andra handlar om att diskutera projektet samt vad man lärts sig. Efter avslutat projekt gick samtliga medlemmar skilda vägar och det fanns inget tillfälle att utföra denna punkt.

6.2.7 Way-of-working Way-of-working, även arbetssätt, är det sjunde och sista områden som har jämförts med Ericssonprojektet. Tabell 11 visar resultatet av jämförelsen för dem olika tillstånden.

Tabell 11. Utförda aktiviteter i Way-of-working

WAY-OF-WORKING PRINCIPLES ESTABLISHED (1/6)

PE-1: Principles and constraints are committed to by the team D

PE-2: Principles and constraints are agreed to by the stakeholders + PE-3: The tool of needs of the work and its stakeholders are agreed + PE-4: A recommendation for the approach to be taken is available - PE-5: The context within which the team will operate is understood +

PE-6: The constraints that apply to the selection, acquisition, and use of practices and tools are known

-

FOUNDATION ESTABLISHED (2/6) FE-1: The key practices and tools that form the foundation of the way-of-working are selected

+

FE-2: Enough practices for work to start are agreed by the team - FE-3: All non-negotiable practices and tools have been identified - FE-4: The gaps that exist between the practices and the tools that are needed and the practices and tools that are available have been analyzed and understood

-

FE-5: The capability gaps that exist between what is needed to execute the desired way of working and the capability levels of the team have been analyzed and understood

+

FE-6: The selected practices and tools have been integrated to form a usable way-of-working

+

IN USE (3/6) IU-1: The practices and tools are being used to do real work + IU-2: The use of the practices and tools selected are regularly inspected - IU-3: The practices and the tools are being adapted to the team’s context

+

IU-4: The use of the practices and tools is supported by the team + IU-5: Procedures are in place to handle feedback on the team’s way-of-working

-

41

6.2.7.1 Sammanfattning av Way-of-working Principles Established (1/6): I det här tillståndet, handlar de om att principer och begränsningar har kommit överens om av intressenterna, om verktygen som behövs för arbetet samt gällande sammanhanget arbetet skall ske under. De två punkter som inte utförts handlar om att ha en rekommendation tillgänglig för tillvägagångssättet och om begränsningar för praxis och verktyg. En sådan begränsning gjordes ej eftersom det inte var nödvändigt. Foundation Established (2/6): I detta tillstånd finns sex aktiviteter och här har hälften utförts. Det fanns inget “gap” mellan de verktyg och praxis som fanns tillgängliga och de som behövdes, eftersom det fanns inget som riktigt behövdes, utan vi kunde själva avgöra hur vi ville göra och vad vi ville använda. Vi bestämde ingen praxis att gå efter utan vi arbetade så som det passade, vilket också är ett arbetssätt. In Use (3/6): Detta tillstånd handlar om att checka om de verktyg och praxis som bestämts tidigare faktiskt används. Det skedde ingen kontroll ifall de användes eftersom vilka verktyg som användes var vårt val och intressenterna inte hade något intresse av att styra det valet. In Place (4/6): Det här tillståndet består av tre checkpunkter där alla har utförts. De handlar om att teamet använder sig av de verktyg och praxis samt att samtliga skall ha tillgång till ovanstående. Working Well (5/6): Det här tillståndet handlar om hur väl det fungerar. Eftersom samtliga checkpunkter är genomförda kan man anta att det fungerade bra. Retired (6/6): Vid avslutat projekt diskuteras inte “lesson learned” inom teamet. Däremot kan denna utredning ses som denna checkpunkt eftersom den diskuterar problem som uppstått i detta projekt.

IU-6: The practices and tools support team communication and collaboration

+

IN PLACE (4/6) IP-1: The practices and tools are being used by the whole team to perform their work

+

IP-2: All team members have access to the practices and tools required to do their work

+

IP-3: The whole team is involved in the inspection and adaption of the way-of-working

+

WORKING WELL (5/6) W-1: Team members are making progress as planned by using and adapting the way-of-working to suit their current context

+

W-2: The team naturally applies the practices without thinking about them

+

W-3: The tools naturally support the way the team works + W-4: The team continually tunes their use of the practices and tools +

RETIRED (6/6) R-1: The team’s way-of-working is no longer being used + R-2: Lesson learned are shared for future use -

42

43

7 Matchning av problem och aktiviteter

Det här kapitlet handlar om att presentera ett samband mellan beskrivna problem och resultat utifrån ramverken (kap 6). För varje identifierat problem kommer det presenteras ett samband till något utav ramverken SGD Framework och Kernel Essence. Kapitel 7.1 - 7.6 presenteras orsaker och samband för varje problem som har tagits med i studien. Problemen som är inkluderade i den här studien kommer från Ericssonprojektet och är beskrivna i kapitel 5.

7.1 Fel val av programmeringsspråk För det här problemet kunde tre orsaker identifieras ifrån de två ramverken som använts. I Kernel Essence hittades två av dessa tre. Den första aktiviteten handlar om att arbetet sker i en effektiv process med minimalt omarbete, (P-4 i tabell 18). Denna aktivitet utfördes inte och på grund av det var vi tvungna att arbeta om väldigt mycket. Den andra aktiviteten från Kernel Essence handlar om att förstå och analysera gapet mellan de verktyg som behövs och de som kommer att användas (FE-4 i tabell 24). Denna aktivitet är en viktig orsak för problemet vid fel val av programmeringsspråk eftersom vi inte analyserade tillräckligt om det var det mest lämpade språket för det som vi behövde implementera. Gapet mellan vår erfarenhet av java och den faktiska implementeringen var oväntad och ledde oss till problemet. Genom att vi inte gjorde en sådan ordentlig analys ledde det oss till problemet att språket vi hade valt inte var lämpligt och en mängd arbete behövde göras om i ett nytt programmeringsspråk samt att arbetstid gick till spillo. Den sista orsaken som identifierades för det här problemet kommer ifrån SGD och handlar om att man skall vara säker att den teknologin man skall använda har testats och är förstådd (PR-2 i tabell 3). Denna aktivitet och FE-4 är parallella men kommer ifrån olika ramverk.

Figur 6. Orsaker för problem #1

44

Figur 7. Orsaker för problem #2

7.2 Brist på planering Bristen i planeringen var ett problem som var återkommande i projektet. För det här problemet identifierades två orsaker, en aktivitet från respektive ramverk som inte utfördes. Från SGD finns aktiviteten som innebär att man skall schemalägga arbetet (PL-10 i tabell 3). Den andra orsaken kommer ifrån Kernel Essence och handlar om att ha en trovärdig planering på plats (PR-9 i tabell 20). Ingen av dessa aktiviteter gjordes och har därmed identifierats som orsaker för problemet. Det gjordes ingen planering överhuvudtaget för projektet.

7.3 Ingen uppdelning av arbetsuppgifter Att det inte skedde en ordentlig uppdelning av arbetsuppgifterna har spårats till tre orsaker, där alla tre kommer ifrån Kernel Essence. Från ramverket SGD hittades det inte något samband mellan detta problem och aktiviteterna som tillhör ramverket. Den första aktiviteten från Kernel Essence handlar om att varje medlem i teamet förstår hur teamet är organiserat och vad den individuella rollen är (F-3 i tabell 17). Den här punkten utfördes då inte och är därmed en orsak till det här problemet. Nästa aktivitet (F-4 i tabell 17) kommer ifrån samma område och samma tillstånd i Kernel Essence. Aktiviteterna som nämnts hittills är båda ifrån Team och från tillståndet Formed. Den tredje och sista aktiviteten från Kernel Essence handlar om att bryta ned arbetet för att man skall börja arbeta (PR-7 i tabell 20). Den här aktiviteten var en viktig orsak för problemet eftersom det blev svårt att dela upp arbetsuppgifterna mellan teamet eftersom det inte brutits ned i mindre delproblem som lättare kan delas upp.

7.4 För lite involvering av handledare Handledare för projektet fanns där vid behov från teamets sida. I början av projektet var vi i teamet dåliga på att inkludera dem. Vi lärde oss i efterhand att det är bättre att fråga en gång för mycket, än att anta och sedan riskera att ha fel. I Kernel Essence finns aktiviteter som handlar om att representanterna för intressenterna skall förse med feedback och ta del av beslut i tid (IN-2 i tabell 6). Däremot finns inga aktiviteter som handlar om hur teamet skall involvera

45

Figur 8. Orsaker för problem #3

representanterna från deras sida. För det här problemet kunde därför inte några orsaker identifieras trots ramverkens inverkan.

7.5 Dålig kommunikation Ett annat problem som förekom mellan gruppen i Ericssonprojektet var den dåliga kommunikationen. För det här problemet har två orsaker identifierats, där båda är ifrån Kernel Essence. Den första aktiviteten handlar om att teamet skall arbeta som en enhet (CO-1 i tabell 18) och den andra handlar om att kommunikationen är öppen och ärlig (CO-2 i tabell 18). Båda aktiviteter kommer ifrån samma tillstånd Collaborating från området Team. Dessa två uppfylldes inte helt under projektet och ledde till att det var bristningar i kommunikationen. I tabell 18 har dessa aktiviteter markerats som delvis utförda. Det beror på att kommunikationen i teamet kunde variera, vid vissa tillfällen funkade det bättre än andra.

7.6 Ingen design eller dokumentation att utgå ifrån Det här problemet handlar om att det inte fanns någon design/dokumentation att grunda implementeringen på. För det här problemet har det identifierats orsaker både från Kernel Essence och SGD.

Figur 9. Orsaker för problem #5

46

Figur 10. Orsaker för problem #6

I Kernel Essence finns området Software System, där tillstånden Architecture Selected och Demonstrable ingår, som just handlar om att ta fram en design att grunda sig på. I dessa tillstånd finns aktiviteter som berör problemet som inte har blivit uppfyllda. I Demonstrable (tabell 14) t.ex. är det inga aktiviteter som har markerats som uppfyllda. I SGD kunde en orsak identifieras till varför det inte fanns någon design eller dokumentation. Denna aktivitet handlar om just att förbereda en låg-level design för koden som ska skrivas (P-1 i tabell 4). Denna aktivitet utfördes inte och därmed konstaterats vara en orsak till problemet. Det lades inte tid på att designa en arkitektur för systemet.

47

8 Resultat

I det här kapitlet som behandlar resultatet av studien presenteras modellen som har tagits fram. I kapitel 8.1 kommer en översikt av Problem-Orsak-Konsekvens(POK)-modellen att presenteras med en sammanfattning och bildlig presentation. I Kapitel 8.2 presenteras de problem där man har kunnat identifiera både orsaker samt konsekvenser utifrån modellen. Problemen som tas upp i 8.2 behandlas i kapitel 5 samt 7 och kommer ifrån Ericssonprojektet.

8.1 Översikt av Problem-Orsak-Konsekvens-Modellen Modellen som har tagits fram handlar om att identifiera problem och därefter konsekvenserna och till sist orsaker, bildlig representation ses i figur 6. Denna modell är anpassad till projekt i mjukvaruutvecklingsområdet där ramverk har använts som verktyg för att kunna identifiera orsakerna till problemen. I framtagning för denna modell användes SGD och Kernel Essence men tanken är att man skall kunna utveckla denna med andra metoder, modeller eller ramverk. Problem-Orsak-Konsekvens-modellen kommer att refereras som POK-modellen.

Figur 11. Representation för modellen Problem-Orsak-Konsekvens.

8.2 Problem-Orsaker-Konsekvenser I det här delkapitlet kommer problemen som tagits upp i kapitel 5 sammanfattas tillsammans med orsaker och konsekvenser för problemen.

48

Figur 12. Sammanfattning av problem #1

Problemen som tas med här är de problem där det har varit möjligt att identifiera både orsaker och konsekvenser och uppfyller modellen i fig. 11. För fullständig beskrivning av varje problem, se tabell 2. Problem: Fel val av programmeringsspråk I det här problemet om fel val av programmeringsspråk var konsekvensen att mycket arbetstid gick förlorad och teamet var tvungna att gå tillbaka i projektet för att börja om med ett nytt programmeringsspråk. Orsaken för detta problem var att det inte utfördes en ordentlig planering för projektet. Det gjordes inte tillräckligt med undersökning kring programmeringsspråket och de krav som skulle implementeras i språket. I figur 12 kan en sammanfattning av POK-modellen anpassat till det här problemet visas. Problem: Brist på planering Konsekvensen för bristen av planering var främst att det inte fanns en ordentlig struktur av arbetet inom projektet. Det var svårt att förutse nästkommande steg och även oväntade problem dök upp. Det ledde till att det inte fanns någon översikt över projektet som helhet. Orsakerna för detta problem är att det inte gjordes en långsiktig planering för projektet från början. Det gjordes inte heller någon schemaläggning och dessa anledningar ledde oss till problemet. I figur 13 visas en sammanfattning av problemet, konsekvenserna och orsakerna. Problem: Ingen uppdelning av arbetsuppgifter Följden av detta problem var låg effektivitet eftersom det inte var tydligt hur arbetet skulle göras. Arbetsuppgifterna överlappade mellan medlemmarna i

Figur 13. Sammanfattning av problem #2

49

Figur 14. Sammanfattning av problem #3

teamet och effektiviteten försämrades. Orsakerna för detta var främst att arbetet från början inte brutits ned i flera mindre problem och därför blev det svårt att dela upp arbetsuppgifterna mellan oss. Det delades inte heller ut några specifika roller för respektive medlem vilket gjorde det svårt att veta vem som skulle göra vilken uppgift eller del av projektet. I figur 14 visas sammanfattningen för det här problemet. Problem: Dålig kommunikation i teamet Med dålig kommunikation i teamet var effektiviteten inte hög och det påverkade även hur teamet arbetade tillsammans. Arbetet flöt inte alltid på som en fungerande enhet. Orsaken för den dåliga kommunikationen var att kommunikationen inte var tillräckligt öppen. Om någon från teamet utförde en handling som inte uppskattades av resterande medlemmar var det svårt att säga till med detsamma. Se figur 15 för sammanfattning. Problem: Ingen dokumentation eller design att utgå ifrån Vid brist på design för implementeringen är det svårt att få ett arbete som flyter på. Konsekvensen för detta blir att man kommer till en punkt i arbetet då man inte vet hur man skall fortsätta eftersom det inte finns någon design som arbetet har grundat sig på. Det stannar ofta till i projektet och man får komma på en lösning där man befinner sig. Detta är arbetstid som kanske hade kunnat effektiviserats om man gjort rätt från början. Orsaken för detta problem är att det inte lades tid på att ta fram en design som kunde följt med genom projektet. Se figur 16 för detta problemet.

Figur 15. Sammanfattning av problem #5

50

Figur 16. Sammanfattning av problem #6

8.3 Tillämpning av POK-modellen Den här studien har grundat sig på ett mjukvaruutvecklingsprojekt där resultatet av studien var den här modellen. Modellen som har tagits fram har därmed inte tillämpats på något annat projekt än det som utförts från början. Syftet med POK-modellen är att kunna tillämpa den vid projekt som har utförts metodlöst för att kunna identifiera orsakerna till problemen som har uppstått. POK-modellen är för den här studien begränsad till ett projekt med två ramverk för mjukvaruutveckling, dock är tanken att den skall kunna utvecklas med fler projekt samt metoder och ramverk som verktyg.

51

9 Slutsatser och diskussion

Många projektgrupper som skall sätta igång ett projekt väljer idag en arbetsmetod eller ett ramverk som skall stödja deras arbete under utvecklingens gång. Att arbeta metodlöst är inte lika vanligt som det en gång varit men alternativet lever ännu kvar. Den här modellen som tagits fram har baserats på ett projekt som utförts metodlöst i syfte att ta fram problem som skall användas för studien. Modellen gjordes alltså utefter insamlade data från ett projekt som är relaterat till mjukvaruutveckling på ett välkänt It-företag, Ericsson. I och med framtagandet av modellen kan även frågeställningen besvaras, det är möjligt att hitta orsaker till problem som uppkommit i ett metodlöst mjukvaruutvecklingsprojekt med hjälp av ramverk. Modellen har inte tillämpats på något annat projekt inom mjukvaruutvecklingen eftersom studien inte kunde ha den utsträckningen. Det är bristen för denna studie. Det visade sig dock att dem flesta problem som uppkommer i ett metodlöst projekt har en orsak som kan verifieras i ett ramverk.

9.1 Diskussion Vid framtagning av modellen användes som tidigare nämnt två ramverk, SGD och Kernel Essence. I processen att ta fram orsakerna för respektive problem kunde man dra slutsatsen att Kernel Essence är ett ramverk som täcker fler problem än vad SGD gör. Det vill säga, hade en projektgrupp använts sig av SGD som ramverk i deras mjukvaruutvecklingsprojekt kunde med stor sannolikhet problem som t.ex. brist på planering ha uppstått. Kernel Essence är ett bredare ramverk som täcker alla områden som problem har uppstått i. Användningen av Kernel Essence kan innebära ett antal färre problem än vid användningen av SGD. I Kernel Essence finns totalt 209 antal aktiviteter om man summerar ihop alla aktiviteter från tabellerna i kapitel 6. Av alla dessa 209 har vi i Ericssonprojektet kunnat utföra 141 aktiviteter helt, 6 stycken delvis utförda, vilket lämnar kvar 62 stycken som inte har genomförts. I SGD finns totalt 40 olika aktiviteter från tabellerna i kapitel 6. Av dessa 40 har vi i Ericssonprojektet kunnat utföra 14 helt, 4 delvis, vilket lämnar 22 aktiviteter ogenomförda. Ifrån Kernel Essence kan man dra slutsatsen att trots att hela 147 aktiviteter har utförts, finns ändå utrymme för att projektproblem skall kunna uppstå. Kernel Essence är ett relativt stort ramverk och täcker många områden av ett mjukvaruutvecklingsprojekt. Ifrån SGD har ungefär hälften av aktiviteterna genomförts. Skillnaden på Kernel Essence och SGD är dock att Kernel är mer täckande och större. Det här visar att trots att man lyckats utföra ett visst antal aktiviteter så kommer det alltid finnas utrymme för problem.

52

9.2 Studiens bidrag till fortsatt relaterat arbete Den här studien ger en modell för att ta fram orsaker för problem som uppstått i mjukvaruutvecklingsprojekt med hjälp av ramverken SGD och Kernel Essence. Modellen kan användas för att ta reda på det är möjligt att göra samma sak med andra metoder och ramverk och därmed utvidga modellen. Studien har alltså kommit fram till att utifrån detta specifika projekt som utförts så är Kernel Essence ett bredare ramverk än SGD som täcker fler problem. Ett intressant område kan vara två projekt som utförs med respektive ramverk för att sedan jämföra vilka för- och nackdelar som uppstått i respektive projekt och på så sätt kan en bättre jämförelse mellan ramverken ske. Denna typ av fortsatt studie skulle även kunna indikera för vilka typ av projekt inom mjukvaruutveckling som varje ramverk kan anpassas bäst till.

53

10 Litteraturförteckning

[1] ”it-ord.idg.se,” [Online]. Available: https://it-ord.idg.se/ord/ad-hoc/.

[Använd 1 03 2017]. [2] ”www.agilesweden.com,” [Online]. Available:

http://www.agilesweden.com/doc/agile.pdf. [Använd 12 04 2017]. [3] M. Klich, ”Ramverk för metod/verktygsval i systemutveckling,” 2006. [4] ”www.slideshare.net,” 22 09 2013. [Online]. Available:

https://www.slideshare.net/RiantSoft123/6-basic-steps-of-software-development-process. [Använd 12 04 2017].

[5] A. Bryman, Samhällsvetenskapliga metoder, Liber, 2008. [6] J. Brzezinski, ”Induktiva och deduktiva resonemang,” Chalmers

Universitet, Göteborg. [7] M. Kajko-Mattsson och G. Jeppesen, ”Self-Governance Developer

Framework,” 2017. [8] ”SEMAT,” 2015. [Online]. Available: Semat.org. [9] ”kth.se,” 19 01 2017. [Online]. Available:

https://www.kth.se/om/miljo-hallbar-utveckling/utbildning-miljo-hallbar-utveckling/verktygslada/sustainable-development/hallbar-utveckling-1.350579. [Använd 26 04 2017].

[10] E. Engwall och B. Jacobsen, ”Agil systemutveckling - en jämförelse mellan den agila och traditionella projektledaren,” 2007.

[11] ”TheAgileProject.com,” [Online]. Available: https://theagileproject.wordpress.com/vattenfallsmodellen/. [Använd 20 03 2017].

[12] ”Wikipedia.com,” 28 03 2015. [Online]. Available: https://sv.wikipedia.org/wiki/Vattenfallsmodellen. [Använd 01 05 2017].

[13] M. Nyman, ”Agila Metoder - Radikal revolution eller en enkel revolution?,” http://www.wenell.se/wp-content/uploads/2016/09/agile-radikal- -eller-enkel-evolution-mats-nyman-2010.pdf, 2010.

[14] Beck, Kent, ”Agile Manifesto,” 2001. [Online]. Available: http://agilemanifesto.org/iso/sv/manifesto.html. [Använd 2017].

[15] K. Schwaber och J. Sutherland, The Scrum Guide TM, http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-se.pdf, 2013.

[16] M. Pihel och C. Bartelius, ”Hantering av problem i agil systemutveckling - en fallstudie av CGI,” 2013.

[17] S. Bohari, Varför behövs en projektmetod, http://www.advectas.se/varfor-behovs-en-projektmetod/, 2016.

[18] ”IEEE Standard Glossary of Software Engineering Terminology,” 1990.

54

[19] ”Zeepedia.com,” [Online]. Available: http://www.zeepedia.com/read.php?problems_in_software_projects_process-_related_problems_software_project_management&b=18&c=11. [Använd 15 02 2017].

[20] ”ibeta.com,” 15 12 2015. [Online]. Available: http://www.ibeta.com/3-common-issues-with-the-software-development-process/. [Använd 03 2017].

[21] ”Unifaceinfo.com,” 22 10 2013. [Online]. Available: http://unifaceinfo.com/the-6-most-common-problems-in-software-development/. [Använd 04 04 2017].

[22] S. Ciesluk, ”Developer's time spent in a software project using the SGD Framework,” 2016.

[23] G. Eklund, Forskningsmetodik - Kvalitativa metoder, Åbo Akademi. [24] ”www.cse.chalmers.se,” 16 10 2002. [Online]. Available:

http://www.cse.chalmers.se/research/group/idc/ituniv/kurser/02/mdi/datainsamling.pdf. [Använd 26 04 2017].

[25] Ericsson, ”About us,” 2016. [Online]. Available: https://www.ericsson.com/about-us.

[26] Ericsson, ”Första kvartalet 2016,” 2016. [Online]. Available: http://www.ericsson.com/res/investors/docs/q-reports/2016/03month16-sv.pdf .

[27] ”Epsdomains,” [Online]. Available: Epsdomains.se. [28] D. Avison, Information Systems Development: Methodologies,

Techniques and Tools, vol. 4th ed., London: McGrac Hill Higher Education, 2006.

[29] M. Klich, ”Ramverk för metod/verktygsval i systemutveckling,” 2006.

1

Bilaga A Denna bilaga består av dagboken som skrevs under projektets gång. Den är skriven ur mitt perspektiv och hur jag som aktiv medlem i projektet upplevde arbetsprocessen. Detta appendix har använts som grund när problemen har lyfts fram. 21 Juni 2016 (tisdag) Seg start, mailat mina projektvänner men inte fått något svar ännu. Tanken är att vi ska mötas och planera upplägget för projektet samt bestämma verktyg som ska användas och så vidare innan vi sätter igång med implementeringen av själva projektet. 22 juni 2016 (onsdag) Kan inte ens få svar på mitt mail.. Bra start.. Vill kunna kommunicera med dem 2 jag skall jobba med, men utan kommunikation från båda hållen lär det bli svårt. Känner att jag vill sätta igång med saker och så vidare och se om de har gjort någonting utan mig, för det innebär då att jag ligger efter och det hade jag inte alls räknat med. 23 juni 2016 (torsdag) Idag träffades vi första gången. Vi fick en introduktion av Samer och Kamal, som handlade om nedladdningshastighetsverktyg och hur detta verktyg ska skilja sig från vad som finns tillgängligt redan nu. Kraven gicks igenom lite snabbt sedan fick vi mer tid till att prata med varandra och berätta mer om våra erfarenheter osv. Vi gick igenom kraven för projektet och beslutade om verktyg och språk: java och eclipse. Vi kom fram till att java har ett bibliotek som kan användas och då slipper vi skriva vissa saker själva. Detta kom vi fram till genom research. Vi fick även tips att använda ett visst verktyg för klient server som underlättar saker, så det laddades ned direkt. FileZilla är ett verktyg som används för FTP client och servrar. Det är väldigt simpelt att ladda ner och konfigurera, vilket gjordes idag med hjälp av en youtube tutorial. 24 juni 2016 (fredag) Eftersom det är Ramadan innebär det att fredagar i princip är lediga. Ingenting jag hade räknat med, men det är väl sådant som uppstår. För att inte slösa någon tid bestämde vi i alla fall att vi skulle göra lite research på kommunikation via FTP för att få mer förståelse samt även kolla mer på verktygen vi bestämt oss för att använda. Inget gemensamt arbete alls idag, men kommande vecka lär det bli mer. Jobbiga är att vi inte planerat så mycket framåt. När vi träffas på måndag lär vi inte riktigt veta exakt vad vi ska göra eller vad som är bäst att fortsätta arbeta på. En sådan planering kanske måste göras och även försöka planera in hur lång tid varje deluppgift skulle behöva. 27 juni 2016 (måndag) Idag lyckades vi arbeta tillsammans och få mycket gjort. Vi lyckades bocka av några av kraven från listan. Vi jobbade hela tiden gemensamt och när vi fastnade på någonting, t.ex. Hur vi ska lyckas läsa utan att spara på disken (fortfarande inte helt löst) diskuterade vi alternativen tillsammans och arbetade utifrån det. Ett problem vi stötte på var att ingen av oss hade arbetat med gui:n tidigare, vilket innebar att vi alla måste sätta oss in i det och lära oss för att sedan kunna fortsätta med uppgiften.

2

Eftersom att göra att interface är en del av uppgiften vill vi göra det i takt med implementationen av mätaren eftersom det blir lättare än att spara det till allra sist, ansåg vi. Imorgon kommer därför spenderas med att lära oss antingen javaFX eller Java Swing, vi har inte riktigt beslutat ännu om vilket av dem som är lämpligast för oss. 28 juni 2016 (tisdag) Idag gjorde vi som vi bestämde igår och använde dagen till att först ta reda på om vi skulle använda JavaFX eller JavaSwing. Det blev tillslut FX. Därefter letades efter exempel osv för att sätta sig in i språket ordentligt. Det är trots allt ett helt nytt språk som ska läras in och eftersom vi inte vill börja arbeta med det utan att kunna någonting kommer det kanske krävas 1-2 dagar ytterligare för att lära sig så mycket som möjligt. Vi kommer att lära oss språket individuellt eftersom alla har olika inlärningssätt osv. 4 juli 2016 (måndag) Resten av förra veckan spenderades individuellt. Vi arbetade alltså var för sig med att lära oss det nya språket. Ett möte med ansvariga för projektet bokades in den 4:e för att gå igenom det vi gjort hittills i projektet och för att veta om vi är på rätt spår. Vi kände att vi ville få bekräftelse av någon på det gjorda arbetet för att vi inte ska arbeta för långt och sedan behöva gå tillbaka. Vilket var precis det som hände. Vi hade räknat med att vi skulle behöva göra en check på att hela filen blivit “nedladdad” men tydligen var det oviktigt. Då kunde vi stryka det. Men detta insåg vi senare, detta kunde vi sparat tid på genom att bara fråga någon av handledarna.. Enligt kraven ska vi kunna göra en nedladdning utan att spara själva filen, detta var dock lite otydligt hur det skulle hanteras så vi kunde fråga om det. Det visade också sig att vårt program hittills inte kunde hantera gigantiska filer då datorn programmet körs på inte skulle kunna klara av minneshanteringen pga för stort. Nu måste vi därför tänka om och se hur vi ska lösa detta. Denna vecka innebär 4 dagars ledighet, därför kommer vi även denna vecka jobba enskilt men fortfarande kommunicera via mail/telefon osv. Vi ska försöka tänka om och kanske ta en annan approach på det här med att “retreiva” men inte spara filen. Förhoppningsvis från och med måndag ska vi kunna jobba som vanligt 5 dagar i veckan med vanliga arbetstider. Högtiden Ramadan har kommit i vägen för oss och vi har liksom inte förväntas jobba lediga dagar och därför har vi då jobbat enskilt eller inget alls. 11 juli 2016 (måndag) Idag hade vi som en introduktionsstart eftersom resterande praktikanter/trainees anslöt. Vi har alltså sedan förra måndagen inte jobbat någonting eftersom det var ledigt och idag försvann tiden åt föreläsningar osv. Imorgon, tisdag kommer vi kunna fortsätta med arbetet och ta åt oss de punkter och förslag vi fick förra gången. Idag hade vi diskussion om att eventuellt byta språk (java

3

till pyton), vilket kan slöa ner oss eftersom ingen av oss 3 kan det språket, men som kan va till nytta för uppgiften. Det återstår att se om vi kan hitta något bättre bibliotek eller bättre lösning i Java, annars blir det att lära sig Pyton. Det var inget som vi hade räknat med. 12 juli 2016 (tisdag) Vi är så fast man kan bli. Vi hittar inte rätt funktioner som vi vill ha i något språk och istället för att fokusera på ett språk och utgå från det så blir det att vi föreslår nya språk hela tiden och går igenom lite lätt. Vi lägger inte alls rätt fokus på rätt plats och det har gjort det oerhört svårt att fortsätta. Efter så många dagar är vi fortfarande i en research-process vilket inte alls är bra eftersom det känns som att 1. Vi inte gjort någonting nyttigt, 2. Vi har så mycket kvar och vi inte kommer hinna. 13 juli 2016 (onsdag) Denna dag såg precis ut som gårdagen. Vi bestämde i alla fall idag att imorgon innan vi sätter igång ska vi ha bestämt vilket språk vi ska använda och gå djupt in i det istället för att hålla en översikt över flera språk och inte engagera sig tillräckligt. Vi försöker dela upp researchen, men det blir ändå att vi avbryter varandra för att helt enkelt diskutera med någon om den information man hittar. Här borde vi egentligen frågat någon av våra handledare om hjälp, men de hade sagt sedan tidigare att de helst inte vill få frågor angående programmeringen eftersom det inte är deras område riktigt. Därför undvek vi helst det. 14 juli 2016 (torsdag) Vi bestämde till slut att Python fick duga för detta och fortsätta med det. Java kunde vi inte gå tillbaka till eftersom vi kände att vi utforskat tillräckligt inom de biblioteken och de verktyg som fanns och det fanns helt enkelt inget effektivt sätt att ladda ned filen utan att spara och samtidigt mäta tiden för allting. Vi hade idag även ett litet kort minimöte med den ansvariga för projektet där vi gick igenom hur vi tänkt och så hittills och främst under den senaste veckan. Den här veckan har inte känts så effektiv eftersom mycket tid gått till research osv, så förhoppningsvis blir nästa vecka mycket enklare. Vi har dessutom inte haft någon tydlig uppgift för var och en, och därför har mycket tid slösats bort. Våra personligheter har gått ihop väldigt bra, vi lyssnar på varandra när det behövs och det känns som (i alla fall för mig) att den som vill prata känner att den kan göra det. Vi diskuterar mycket vilket jag tycker är bra, på så sätt håller man varandra uppdaterade och in the loop. 15 juli 2016 (fredag) SJUK 18 juli 2016 (måndag) Mål för veckan att påbörja en ordentlig testningsfas. Det har blivit ibland att kanske en person tar sig an en uppgift och de två resterande blir vilsna i vad som skall göras näst. Det är också en person som gärna tar jobbet med sig hem och kommer hem dagen efter med saker utförda. Vet inte vad jag tycker om det, visst det sparar tid men det drar också från att jobba i själva projektet med gruppen. Sånt som vi kanske skulle gjort i grupp gör den personen hemma ensam och kommer sedan dagen efter och förklarar för resten. Ibland har jag uppskattat det, men det har också hänt lite för ofta. 19 juli 2016 (tisdag) SJUK

4

20 juli 2016 (Onsdag) Kraven klara och testningsfas är igång. Vi måste också få våra funktioner att fungera som ett program. Hittills har vi bara tänkt på att klara av att skriva alla funktioner som finns i kravlistan. Exceptionhandling och sånt där existerar inte ännu överhuvudtaget och vi måste kolla vilka miljöer applikationen fungerar i. 21 juli (Torsdag) Vi hade ingen riktig plan för testningsfasen märkte vi. Vi har väl egentligen inte haft en plan för någonting överhuvudtaget men det har löst sig hittills så detta lär väl också göra det. Vi skrev upp alla saker som skulle testas och började så istället. De absolut viktigaste kraven först och därefter mindre relevanta funktioner. 22 juli (Fredag) Separata funktioner fungerar, problemet blir nu att sätta ihop det till ett fungerande program. Svårt utan en modellering över programmet. 1 augusti 2016 (Måndag) Varit riktigt dålig på att skriva dagbok.. I slutet av förra veckan ägnades mycket tid till att lösa GUI problemet. Det fungerade inte att ladda ner alla “importeringar” som de ska, men det löstes till slut. Idag har jag och Hamdan ägnat tid åt att börja koda för GUI medan Ali har skrivit exceptionshandling. Det blev enklast att dela upp det så för att spara tid. Eftersom det ska finnas en graf i gui:t fick Hamdan ta den delen, medan jag skulle sköta resten av alla inmatningar, textfält osv osv. Tanken är att vi sedan skall slå ihop koden och få det till ett fungerade GUI tillsammans med koden för alla funktioner. 3 Augusti 2016 (Onsdag) Dålig programmeringsteknik: testa alla metoder/lösningar en efter en för att se vad som funkar. Det tar tid, det skapar en irritation i gruppen eftersom det känts som att inget fungerar och det står bara still. Vi vill ha en graf som visar hastigheten, men vi lyckas inte kombinera grafen tillsammans med knappar och textfält i GUI:t vilket skapar stora problem. 5 Augusti 2016 (Fredag) Här kämpas det fortfarande med 1. Att få all kod att fungera ihop. 2. Få ihop grafen med resterande delar av gui:et. Inget går bra. Tur att veckan är över och vi kan börja med ny energi nästa måndag. 8 Augusti 2016 (Måndag) Nu skulle det vara passande att ha haft mer dokumentation att utgå ifrån. Eftersom vi inte riktigt hade designat systemet från starten har vi fått göra det lite lätt nu. För att koden ska fungera ihop, (alla funktioner som skrevs var för sig från början) hade det varit bra att haft något “tänk” från start. Nu improviserar vi så gott vi kan och försöker ändå. 10 Augusti 2016 (Onsdag)

5

Ytterst stel stämning bland oss i gruppen när saker och ting inte fungerar som de ska och det är inte lång tid kvar till deadline. När man testat flera lösningar men ingenting fungerar uppstår en frustration i gruppen, som alla hanterar på olika sätt. En i vår grupp blir t.ex. Väldigt irriterad och väljer ibland att inte svara när man talar till honom. Jag försöker hålla humöret uppe och kan tycka att allt går att lösa, och att en paus inte skadar eftersom man kommer tillbaka med nytt tänk. Det är som sagt väldigt olika och idag märktes det av tydligt. Jag börjar känna att jag bara vill bli klar med projektet för stressen/pressen att bli färdiga känns av. Stämningen i gruppen har senaste veckan och även slutet på förra veckan förändrats sedan innan just pga detta. 12 Augusti 2016 (fredag) Det går sakta men säkert framåt. Vi har sagt åt oss själva att sluta stressa så mycket för det kommer lösa sig alltihopa.

1

TRITA -ICT-EX-2017:166

www.kth.se