SÄKRARE DRIFTSÄTTNING : En kvalitativ studie över vilken roll en testmiljö spelar inför driftsättning av informationssysstem i en produktionsmiljö.

Örebro universitet

Handledare: Kai Wistrand Examinator: Johan Aderud HT2013/2014-01-09

H T 2 0 1 3 / 2 0 1 4 - 0 1 - 0 9

SÄKRARE

DRIFTSÄTTNING

En kvalitativ studie över vilken roll en testmiljö spelar inför driftsättning av informationssysstem i en produktionsmiljö.

Behar Sopjani 890307 Arvid Waldner 870818

Förord

Den här uppsatsen är avsedd som en mera generell introduktion på driftsättning av informationssystem. Den är skriven för personer som vill ha en övergripande insikt om driftsättning inom systemutveckling. Även om delar av arbetet kan förstås utan förkunskaper inom informatik, förutsätts att läsaren är bekant med informatik och systemutveckling. Själva idén om att skriva om ämnet driftsättning kom vi på efter att ha brainstormat fram olika förslag. Vi valde driftsättningen just på grund av att vi läst systemutveckling enligt RUP. Driftsättning var någonting som vi aldrig gick in på under utbildningen, vilket fick oss att vilja veta mer om ämnet.

Vi vill passa på att tacka alla som på något sätt är inblandade i uppsatsen, utan er hade det inte varit möjligt att genomföra denna uppsats.

Vi vill börja med att tacka vår handledare Kai Wistrand för att ha lärt oss konsten av att utföra ett självständigt arbete och hjälpt oss stärka vår förtroende kring uppsatsskrivande.

Tack till Fredrik Galistel och Johan Svensson på Transportstyrelsen för att ha bidragit med respondenter för denna uppsats. Vi vill tacka respondenterna Sven Cederteg, Carl-Gustav Nordström och Mikael Börjesson från Transportstyrelsen för ert deltagande som respondenter. Tack till Richard Ericsson och Murat Alp från Sigma IT-Services för att ha möjliggjort ett praktiskt deltagande på en driftsättning i testmiljö hos Sigma IT-Services samt att ha bidragit med en respondenter för uppsatsen.

Vi vill även tacka Marcus Mattson som noggrant kollat igenom vår uppsats och gett oss konstruktiv feedback.

Abstract

Introduction: When an information system is considered finished, be it in development or

management, it is to be released into a production environment and be made available for the end users. To do this, a step-by-step planned release process should be made via a series of activities. One important part of this process is to release the information system into a testing environment prior to being released into a production environment.

Purpose: The purpose of this C-level essay is to investigate the importance of a testing

environment prior to release to a production environment during release from a professional and real-life perspective, broken down into two main questions: “Why is a testing

environment used during release?”, “What are the pros and cons of a testing environment during release?”

Method: In this study we used an inductive approach together with a qualitative inception to

collect data from 4 semi-structured interviews with working professionals who had experiences with the release of information systems.

Result & Conclusion: The 4 interviewed professionals all claimed that a testing environment

have substantial importance during the release into a production environment, partially because of the impact it has on user acceptance and out of technical security reasons. A testing environment is apparently valued based on to which extent it is similar to a production environment in order to gain an understanding regarding how the information system will act when released into an actual production environment. However, this does not imply that if the informations system works to satisfaction in a testing environment, that it is then guaranteed to work without disruption in a production environment.

Suggestions to further research: We would like to see more of this kind of research and

into this field, but with more interviews to increase the extent at which the study’s

conclusions can be generalized. Another point of interest that one of the interviewees took up was automated release, which was a previously unknown concept for us that deserves further investigation.

Key words: Release, Testing Environment, Production Environment, User Acceptance Test,

Sammanfattning

Inledning: När ett informationssystem betraktas som färdigutvecklat eller färdigförvaltat,

skall det driftsättas i en produktionsmiljö för att göras tillgängligt för slutanvändare. För att det skall kunna göras tillgängligt för slutanvändarna, bör en stegvis planerad

driftsättningsprocess med en serie aktiviteter genomföras. En viktig delprocess i en

driftsättningsprocess är att driftsätta informationssystemet i en testmiljö, innan det driftsätts i produktionsmiljö.

Syfte: Syftet med denna C-uppsats var att utreda vilken roll en testmiljö spelar inför

driftsättning av informationssysstem i en produktionsmiljö utifrån yrkesverksammas perspektiv.. Syftet bröts även ned till två frågeställningar: Varför används en testmiljö vid driftsättning? Vad är för-och nackdelar med en testmiljö vid driftsättning?

Metod: I denna studie tillämpades ett induktivt angreppssätt med en kvalitativ ansats.

Datainsamlingen gjordes med hjälp av semistruktuerade intervjuer. 4 yrkesverksamma med erfarenheter utav driftsättning intervjuades.

Resultat & Slutsats: De yrkesverksamma menade att en testmiljö har en väsentlig betydelse

för en produktionsmiljö vid en driftsättning utav användaracceptansskäl och av tekniska trygghetsskäl. En testmiljös betydelse värderades också utefter hur produktionslik den är för att veta hur informationssystemet kommer att bete sig vid tester när det väl produktionssätts. Däremot menade de yrkesverksamma att det ofta finns skillnader mellan testmiljöer och produktionsmiljöer. Det innebär att om informationssystemet fungerar tillfredsställande i en testmiljö, så är det inte en garanti att det kommer att fungera utan störningar i

produktionsmiljön.

Förslag till fortsatt forskning: Vi hade gärna sett mer utav denna typ av forskning, fast med

fler respondenter för att öka studiens generaliserbarhet. En annan intressant sak som en av respondenterna tog upp är automatiserad driftsättning. Ett, för oss, helt nytt begrepp inom driftsättning som är absolut värt att skriva ett arbete om.

Nyckelord: Driftsättning, Testmiljö, Produktionsmiljö, Användaracceptanstest, Prestanda,

Innehållsförteckning

2.2 Driftsättning och aktiviteter ... 6

2.3 Testmiljö ... 8

2.4 Produktionsmiljö ... 9

2.5 Teknisk- och social systemimplementation ... 9

2.5.1 Tekniska systemimplementationsstrategier ... 9 2.5.2 Användaracceptans ...10 2.6 Förstudier ...10 3 Metod ...11 3.1 Datainsamling ...11 3.1.1 Diskussion om datainsamlingen ...12 3.1.2 Litteraturstudier ...12 3.1.3 Genomförande av intervjuer ...13 3.2 Urval ...14 3.3 Analys ...15

3.3.1 Analys av den empiriska datan ...15

3.5 Validitet, reliabilitet och generaliserbarhet ...17

3.6 Etiska överväganden ...18

4 Resultat ...19

4.1 Resultat av empiri ...19

4.1.1 Varför används testmiljö vid driftsättning? ...19

4.1.2 Vad är för- och nackdelar med testmiljö vid driftsättning? ...20

5.1 Varför används testmiljö vid driftsättning? ...24

5.1.1Richard Eriksson IT-Tekniker, SIGMA IT-Services ...24

5.1.2 Sven Cederteg, Driftsättningsansvarig/Konsult Transportstyrelsen ...25

5.1.3 Carl-Gustav Nordström, Arkitekt/Systemutvecklare och Mikael Börjesson, IT-Förvaltningsledare Transportstyrelsen...25

5.2 Vad är för- och nackdelar med testmiljö vid driftsättning? ...26

5.2.1 Rickard Eriksson, IT-Tekniker SIGMA IT-Services ...26

5.2.2 Sven Cederteg, Driftsättningsansvarig/Konsult Transportstyrelsen ...27

5.2.3 Carl-Gustav Nordström, Arkitekt/Systemutvecklare och Mikael Börjesson, IT-Förvaltningsledare Transportstyrelsen...28

5.3 Diskussion ...30

5.3.1 Varför används testmiljö vid driftsättning i produktionsmiljö? ...30

5.3.2 Vad är för- och nackdelar med testmiljö vid driftsättning? ...30

6 Slutsats ...32

7 Diskussion om förslag på vidare studier ...33

8 Källförteckning/Referenslista ...34

9 Bilagor ...36

9.1 Intervjufrågor ...36

9.2 Intervjuer ...37

9.2.1 Transkriberad intervju med Rickard Eriksson, SIGMA IT Services: 11 december 2013 ...37

9.2.2 Transkriberad intervju med Sven Cederteg, Transportstyrelsen: 12 december 2013 ...49

9.2.3 Transkriberad intervju med Carl-Gustav Nordström och Mikael Börjesson, Transportstyrelsen: 12 december 2013 ...62

9.2.4 Transkribering av deltagande observation med Murat Alp på Sigma IT-Services: 13 november ...75

Figurförteckning

Begreppslista

Driftsättning – ”Driftsättning svarar för planering, konfigurering, test, distribution och

installation av all hårdvara och mjukvara som ingår i en driftsättning. Processen ska säkra att endast godkänd mjukvara och hårdvara implementeras i produktionsmiljön. Innehållet i varje driftsättning ska vara hanterat, testat och produktionssatt som en enhet.” (Arvidson, 2012, s. 3).

Driftsättningsprocess – Se Driftsättning.

Implementering – Betyder krast att man utplacerar mjukvara/tar mjukvara i drift. Man

tillgängliggör för slutanvändare (Wikipedia, 2013b).

Implementera – När vi nämner ordet implementera menar vi när man utför en implementering. Driftsätta – När vi nämner ordet driftsätta, menar vi när man utför en implementering.

Deployment – Är driftsättning på engelska (Nationalencyklopedin.se, 2014 ).

Informationssystem – ”Ett informationssystem definieras ofta som ett system med IT-stöd

som samlar in, lagrar, bearbetar och distribuerar information om en domän och därigenom stödjer kommunikation och arbete inom och mellan organisationer” (Wikipedia, 2013c).

Sigma IT-Services – Ett IT-tjänsteföretag som finns på ett tjugotal orter i Sverige och i totalt

sex länder. Sigma utvecklar IT-tjänster åt deras kunder som fungerar som verksamhetsstöd

(Sigma, 2014).

Transportstyrelsen – ”Transportstyrelsen (TS) är en svensk statlig förvaltningsmyndighet,

som sorterar under näringsdepartementet och har till huvuduppgift att svara för regelgivning, tillståndsprövning och tillsyn inom transportområdet.” (Wikipedia, 2013a).

Miljö – Beskrivs som en kontrollerad och ofta repeterbar uppsättning av konfigurationer, som

är avsedda att agera som en avgränsad enhet för operativa sammanhang, för att utföra och kontrollera ett informationssystems funktioner eller aktiviteter. (International Foundation For Information Technology, 2009c).

Produktionsmiljö –”Den miljö som innehåller den skarpa instansen av tjänsten.” (Arvidson,

2012, s. 20).

Testmiljö – Ett vagt definierat begrepp för en avgränsad miljö som är speciellt framtagen för

tester utav ett informationssystems integretation, användaracceptans, prestanda etc. (International Foundation For Information Technology, 2009b).

Prestanda – Är ett mått på hur effektivt en dator eller ett informationssystem utför sina

fördefinerade instruktioner. Det som oftast mäts är den mängd arbete som krävs för en dator eller ett informationssystem för att utföra en samling av uppgifter i relation till tid och andra resurser (Wikipedia, 2013d).

Systemintegration – Begreppet beskriver flera fristående system som kopplas ihop för att

samspela och fungera tillsammans (Wikipedia, 2013e).

Användaracceptanstest – En typ av tester utav ett informationssystem och/eller en mjukvara

som utförs av riktiga användare. Syftet är att användarna skall få verifiera ifall ett informationssystem och/eller en mjukvara uppfyller deras krav (Christensson, 2012a).

Slutanvändare – De personer som använder ett utvecklat eller förvaltat informationssystem.

Slutanvändare kan även benämnas som användare, och det är för just dessa informationssystem utvecklas för (Christensson, 2012b).

1 Inledning

Tänk dig att du arbetar på ett IT-företag som är involverat i ett projekt där någon form av informationssystem skall utvecklas åt en kund. Du dras då in i en systemutvecklingsprocess som innefattar kravinsamling, analys, planering, design och konstruktion av ett informationssystem. Efter en viss tid kommer man till en tidpunkt i systemutvecklingsprocessen där man betraktar sitt informationssystem som i stora drag färdigkonstruerat. Då börjar du känna att ni närmar er skedet att leverera detta utvecklade informationssystem till kunden.

Slutmålet är att detta informationssystem som du har varit med om att utveckla skall implementeras i den kontext där slutanvändarna verkar, vilket kan vara på exempelvis kundens kontor. Informationssystemet skall fungera rent tekniskt utan tekniska komplikationer och slutanvändarna skall känna att de får ut en produktiv nytta av informationssystemet.

Att göra ett utvecklat informationssystem tillgängligt för slutanvändare och kund, brukar benämnas som driftsättning eller systemimplementation (Beynon-Davies, 2002). Det kan betraktas som en egen fas eller en egen process som ofta sker i slutet av systemutvecklingsprojekt. Denna process kan vara uppdelad i delprocesser och varje delprocess kan bestå av ett visst antal aktiviteter. En av dessa delprocesser kan ofta vara att driftsätta ett informationssystem i en testmiljö innan det driftsätts och levereras till den kontext där slutanvändarna verkar (Arvidson, 2012). Vad just en testmiljö är och vilken betydelse den har för en driftsättningsprocess kommer denna rapport att behandla.

1.1 Bakgrund

Yu, Han, Schneider, Hine och Versteeg (2012), menar att det är ofta problematiskt att driftsätta informationssystem i en heterogen produktionsmiljö där många olika delsystem skall samverka och fungera tillsammans. Eftersom att test och kvalitetssäkring innebär ofta att tester utförs på ett utvecklat informationssystems prestanda, så är det inte rekommenderat att utföra dessa typer av tester i en ”skarp” produktionsmiljö. Att utföra prestandatester på ett informationssystem i en heterogen produktionsmiljö är ofta problematiskt på grund av att det finns många delsystem som berörs. Dessutom är ofta dessa delsystem även vitt spridda geografiskt (Yu, Han, Schneider, Hine & Versteeg, 2012).

Många gånger när man pratar om att driftsätta informationssystem, så kan det handla om att ersätta ett äldre system i en produktionsmiljö med ett förvaltat och omarbetat informationssystem. Med tanke på att driftsättning är en process som går ut på att göra ett informationssystem tillgängligt för användare, betraktas dess avslut, d.v.s. att implementera (driftsätta) detta i en produktionsmiljö hos användarna som en av de absolut mest kritiska faserna. När ett omarbetat och förvaltat informationssystem skall införas i en produktionsmiljö där ett befintligt system fortfarande körs av användarna, vill man undvika att störningar sker i det befintliga systemet. Man eftersträvar med andra ord att övergång mellan ett befintligt

system och det omarbetade/förvaltade informationssystemet skall ske med så få tekniska störningar som möjligt (Khan, Nisar, Munir, Anwar & Ali, 2012).

Driftsättning som ämnesområde är ett mycket brett och omfattande område som även kan relateras till och knytas an till andra områden inom systemutveckling och systemutvecklingsprocessen. I slutändan så handlar det om att göra ett utvecklat informationssystem tillgängligt för slutanvändare. För att ett informationssystem skall kunna införas och driftsättas i en verksamhet, så menar Beynon-Davies (2002) att vissa praktiska aktiviteter krävs. Dessa aktiviteter kan vara av både teknisk och social karaktär då bägge delarna spelar roll för en lyckad driftsättning. De tekniska aktiviteterna som krävs för en lyckad driftsättning och implementation av ett informationssystem, är anskaffning av den mjuk- och hårdvara som krävs, datakonvertering, installationer och tester (Beynon-Davies, 2002).

Tester inom driftsättning är något som ses som centralt och viktigt eftersom att man vill försäkra sig om att det informationssystem som har utvecklats kommer att fungera hos användarna och i den kontext där de verkar, vilket brukar benämnas som produktionsmiljö. Även om det krävs tester i produktionsmiljön också för att försäkra sig att allt fungerar väl på plats i den kontext där slutanvändarna verkar, så uppfyller separata tester i en testmiljö en kvalitetsaspekt (Arvidson, 2012).

1.2 Syfte

Syftet med undersökningen är att ta fram vilken roll en testmiljö spelar inför driftsättning av informationssysstem i en produktionsmiljö utifrån yrkesverksammas perspektiv.

Vi vill få reda på hur yrkesverksamma resonerar om varför en testmiljö används vid en driftsättning av informationssystem.

Dessutom vill vi även få reda på hur yrkesverksamma upplever nytta eller nackdelar med en testmiljö för en driftsättning i produktionsmiljö rörande tekniska och mänskliga aspekter.

1.3 Frågeställning

1. Vilken roll spelar en testmiljö inför driftsättning av informationssysstem i en produktionsmiljö utifrån yrkesverksammas perspektiv?

a. Varför används testmiljö vid driftsättning?

1.4 Analys av frågeställning

Huvudfrågan för undersökningen är ”Vilken roll spelar en testmiljö inför driftsättning av informationssysstem i en produktionsmiljö utifrån yrkesverksammas perspektiv?”.

För att kunna besvara huvudfrågan måste man dela upp frågan och ämnet i underfrågor. Genom det kan man säkerställa att hela huvudfrågans problemområde besvaras.

”Varför används testmiljö vid driftsättning?”

Med denna delfråga försöker vi ta reda på orsak och anledning till varför man har en testmiljö enligt yrkesverksammas perspektiv. Vi tror att det måste grunda sig i någonting som har lett till det valet man gjort av att anskaffa sig en testmiljö. Den grund försöker vi ta reda på ifall det kan vara att förebygga problem, eller ifall deras arbetssätt som de infört tidigare säger att man ska ha det som exempel.

”Vad är för- och nackdelar med en testmiljö vid driftsättning?”

Med denna delfråga försöker vi ta reda på hur yrkesverksamma resonerar om vad en testmiljö medför vid en driftsättning. Vi vill få reda på vilka fördelar som kan uppnås vid användande av en testmiljö i driftsättning utifrån rent tekniska aspekter, men även sociala (mänskliga) aspekter. Dessutom vill vi även få reda på om ett användande av en testmiljö även medför nackdelar, eller brister vid en driftsättning.

1.5 Avgränsning

Vår avgränsning inom ämnet driftsättning, är att ta reda påvilken roll en testmiljö spelar inför driftsättning av informationssysstem i en produktionsmiljö utifrån yrkesverksammas

perspektiv. Vi tittar på vilken roll en testmiljö har när man genomför en driftsättning. Vi vill framhäva vilka fördelar och nackdelar en testmiljö medför. Motiveringen till denna

avgränsning är att vi upplevde att det saknades studier och forskning som behandlade en testmiljös roll under en driftsättningsprocess. Med detta i fokus så finns det delar inom driftsättning vi kommer att beröra väldigt lite eller inte alls. Det finns saker som vår avgränsning inte kommer att beröra. Vi kommer inte att:

 Gå in på att utforska driftsättningsprocessen i något större djup mer än att bara förklara att den finns.

 Gå igenom plandriven eller agil driftsättning.

 Skilja på driftsättning inom nyutveckling eller förvaltning av informationssystem.  Gå in på tekniska lösningar eller lösningsförslag på driftsättning gällande testmiljöers

roll.

1.6 Disposition

Den första delen av rapporten bestod av en inledning med en presentation av vårt ämnesområde, syfte, frågeställning och vår avgränsning.

Den andra delen (perspektiv/teori), består av en redogörelse för vår inskaffade teorikunskap om själva ämnesområdet driftsättning och redogör för vårt perspektiv.

Den tredje delen (metod), presenterar vårt metodiska tillvägagångssätt för att beskriva hur vi utförde våra empiriska studier.

Den fjärde delen (resulat & analys), redogör för hur vi har filtrerat och analyserat den insamlade empirin som också kommer att presenteras.

I den femte delen (Diskussion), kommer vi att diskutera och argumentera kring resultaten som vi fick fram av den empiriska undersökningen i förhållande till den teorigrund vi har anskaffat oss.

Slutligen i den sjätte delen (slutsats), så kommer vi att presentera våra dragna slutsatser utav den utförda undersökningen.

Medföljande rådata i form av transkriberade intervjuer och förstudier finns bifogade som bilagor till denna C-uppsats.

1.7 Intressenter

Vi tror att de största intressenterna för vår C-uppsats är personer på IT-företag/Konsultföretag som arbetar ofta med driftsättning av informationssystem. Det kan vara driftsättningsansvariga och driftsättningstekniker som kan vara två av dessa intressenter exempelvis. Dessutom så betraktar vi även vår C-uppsats som ett bidrag till informatikforskningen då vi bidrar med ett perspektiv på driftsättning. Vi tror att denna C-uppsats kan ge ett bidrag till det nuvarande kunskapsläget rörande driftsättning och testmiljöers inverkan på en driftsättning utifrån yrkesverksammas perspektiv.

Vi studenter som kommer att skriva själva C-uppsatsen och utveckla den kunskap som vi åtar oss att få fram, beräknar inte med någon som helst extern finansiering av vårt uppsatsarbete. Allt arbete med kunskapsutvecklingen kommer att ske med investering av vår egen energi, tid och ekonomi.

2 Teori

Forskningen som vi har kommit i kontakt med har på olika sätt behandlat utmaningar med att driftsätta och implementera informationssystem utifrån ett brett antal olika perspektiv på skilda abstraktionsnivåer. Driftsättning är också ett ämnesområde inom informatiksammanhang som relaterar till andra områden, som systemutveckling och implementering exempelvis. Detta måste man ta i beakt när man ska ta fram vilken roll en testmiljö spelar inför driftsättning av informationssysstem i en produktionsmiljö.

Enligt (2012), Lunell (2003) och International Foundation for Information Technology (2009a), så kan driftsättning ses som en form av process som innefattar olika typer av delprocesser. Dessa delprocesser innefattar i sin tur praktiska aktiviteter. Målen med denna process är att ett utvecklat informationssystem skall kunna göras tillgängligt för slutanvändare i ”skarp” produktionsmiljö. Man vill eftersträva att informationssystemet är kvalitetssäkrad och förebygga att tekniska komplikationer och risker skall uppstå i produktionsmiljö.

För att ta reda på hur det utvecklade informationssystemet beter sig och verkar innan det driftsätts i produktionsmiljö, så driftsätter man det utvecklade informationssystemet i en så kallad testmiljö. Att driftsätta ett informationssystem i en testmiljö kan ses som en delprocess. Om denna testmiljö eller testmiljöer finns tillgängliga är inte alltid givet (Arvidson, 2012), men vi förstår det som att uppfyller ett eller flera syften och ger möjlighet för driftsättarna att utsätta informationssystemet för olika typer av tester. Vi ser det som att en eller flera testmiljöer finns till för att på bästa vis förbereda ett utvecklat informationssystem inför en driftsättning i produktion.

Det är just vilken roll en testmiljö spelar inför driftsättning av informationssysstem i en produktionsmiljö vårt perspektiv vill uppmärksamma. Särskilt hur det betraktas ur de yrkesverksammas perspektiv. Vid driftsättning av informationssystem så bör man inte bara ta hänsyn till värdet av att tekniska detaljer fungerar, men även också av att sociala och mänskliga faktorer tas hänsyn till (Beynon-Davies, 2002). Med det menas att en driftsättningsprocess innefattar både teknisk systemimplementation och social systemimplementation. En eller flera testmiljöer kan hjälpa till att pröva ett informationssystems tekniska funktionalitet, och hur användarna upplever att informationssystemet fungerar vid användning (International Foundation for Information Technology, 2009a).

Att utföra en driftsättning av ett informationssystem direkt i en produktionsmiljö, utan att utfört tester innan i en testmiljö avråds på grund av att risker för att störningar i produktionsmiljön kan uppstå. Även om en verksamhet eller kund efterfrågar vad de betraktar som mindre ändringar utav deras informationsystem, så skall inte det omarbetade och förvaltade informationssystemet som innehåller dessa ändringar driftsättas direkt i produktionsmiljön utan att det har genomgått tester i en testmiljö innan (Lindén & Jansson, 2013).

2.1 Driftsättning

När man talar om driftsättning, så är inte begreppet alltid helt självklart med vad det egentligen innebär och betyder. Definitionerna kan skilja sig någorlunda, och kan även vara kontextberoende och perspektivberoende i sin betydelse. Ofta beskrivs driftsättning som en form av process av olika aktiviteter som sträcker sig under en mer eller mindre given tidsperiod. Enligt Lunell (2003), så betraktas driftsättning (Deployment) som en disciplin inom systemutvecklingsmetoden Rational Unified Process. Denna disciplin är en målmedveten process som påbörjas i etableringsfasen av ett systemutvecklingsprojekt. Bland det första som görs då är att utforma en övergripande driftsättningsplan för hur driftsättningen av det utvecklade informationssystemet skall gå till. Driftsättningsplanen revideras och detaljeras ju mer projektet närmar sig sitt slut. Arbetet med själva driftsättningen av ett utvecklat informationssystem ökar som allra mest under slutet av konstruktionsfasen och överlämningsfasen. Syftet med driftsättning är enligt Lunell (2003) att göra ett utvecklat informationssystem tillgängligt för användarna.

Driftsättning har även denna definition av Sven Arvidson på IT-avdelningen, Uppsala Universitet:

”Driftsättning svarar för planering, konfigurering, test, distribution och installation av all hårdvara och mjukvara som ingår i en driftsättning. Processen ska säkra att endast godkänd mjukvara och hårdvara implementeras i produktionsmiljön. Innehållet i varje driftsättning ska vara hanterat, testat och produktionssatt som en enhet.” (Arvidson, 2012, s. 3).

2.2 Driftsättning och aktiviteter

Arvidsons definition har vissa likheter med Lunells definition. Båda författarna beskriver driftsättning som en process med en serie av praktiska aktiviteter och uppgifter som syftar till att göra ett informationssystem eller mjukvara tillgänglig för användare.

Arvidson (2012), delar även upp en hel driftsättningsprocess i flera delprocesser: förplanering av driftsättning, detaljplanering av driftsättning, driftsättning i testmiljö, driftsättning i produktionsmiljö och uppföljning av driftsättning. Alla dessa delprocesser har en rad aktiviteter och uppgifter som utförs av personer med olika roller som ansvarar för aktiviteterna. De roller som ofta finns representerade är driftsättningsansvariga och driftsättningstekniker som ansvarar för flertalet av aktiviteterna som förekommer i de olika delprocesserna (Arvidson, 2012).

Figur 1. Delprocesser i Driftsättning. Modifierad efter ”Processbeskrivning - Driftsättning”, av S. Arvidson, 2012, sid 4.

Att planera för en driftsättning är viktigt då en driftsättning ofta innebär tekniska risker och utmaningar. Lunell (2003) menar att vanligt förekommande tekniska problem vid driftsättning av ett informationssystem nära inpå slutleveransen är integrationsproblem, vilket innebär att informationssystemets olika delar inte fungerar tillsammans. Andra tekniska komplikationer som kan uppstå är också att informationssystemets delar inte kommunicerar med varandra, och att de även tolkar och representerar data på olika sätt (Lunell, 2003).

Lunell (2003) menar att problemen uppstår ofta på grund av att viktiga krav från beställaren har missuppfattats. Det är på grund av dessa anledningar som Rational Unified Process har en plandriven driftsättning för att eliminera dessa risker.

Rational Unified Process har även andra principer och arbetssätt som syftar till att tekniska komplikationer och problem inte skall uppkomma sent i systemutvecklingsprocessen och vid driftsättningen. Dessa principer är ett iterativt arbetssätt, konfigurationshantering, riskfokusering, driftsättningsplan, driftsättningsmodell, kravhantering, inkrementell integration, feature baserad utveckling och produktgodkännandeplan (Lunell, 2003).

När man pratar om driftsättning, så pratar man ofta om att driftsätta en mjukvara eller ett informationssystem i en viss miljö som exempelvis en testmiljö eller i en produktionsmiljö. Arvidson (2012) nämner denna handling som en händelse och delprocess i själva driftsättningsprocessen. För att ett informationssystem eller mjukvara ska kunna göras tillgänglig för användarna och beställarna, så skall det genomgå en lyckad driftsättning i produktionsmiljö.

2.3 Testmiljö

Begreppet är problematiskt att definiera och kan både betyda och innefatta olika saker beroende på vem man frågar. Det kan ses som ett samlingsbegrepp, eller delas in i specifika nischer. Testmiljö är ett samlingsbegrepp som har använts av Arvidson (2012), för att utföra och utsätta en utvecklad mjukvara eller ett informationssystem för olika typer av tester. Dock så menar International Foundation for Information Technology (2009a) att det även går att prata om specifika typer av olika testmiljöer.

Enligt International Foundation for Information Technology (2009a), så kan man tala om följande typer av testmiljöer: Integrationstestmiljö, prestandatestmiljö och användaracceptansmiljö.

En integrationstestmiljö är en speciellt framtagen och avgränsad miljö med syfte att utföra systemintegrationstester på ett utvecklat informationssystem eller mjukvara. Med det menas att man vill pröva hur väl den utvecklade mjukvaran eller informationssystemet samverkar och fungerar tillsammans med andra delsystem som kommer att finnas i produktionsmiljön (International Foundation for Information Technology, 2009a).

En Prestandatestmiljö är en speciellt framtagen och avgränsad miljö med syfte att utsätta ett utvecklat informationssystem eller mjukvara för prestandatester. Man vill mäta prestandan hos ett utvecklat informationssystem eller mjukvara efter olika kriterier och krav på vad det skall klara av. Att prestandatester utförs i en avgränsad miljö som denna gör att man minskar riskerna med att informationssystemet eller mjukvaran stöter på svåra komplikationer med dess prestanda hos slutanvändarna i produktionsmiljö (International Foundation for Information Technology, 2009a).

En användaracceptansmiljö är en speciellt framtagen och avgränsad miljö med syfte att utföra användaracceptans tester. Med detta menas att användare får möjlighet att själva testanvända ett utvecklat informationssystem eller mjukvara innan det levereras till produktionsmiljö. Användarna testar ifall informationssystemet eller mjukvaran uppfyller de funktionella krav som användarna kräver. Användarna kan även efter olika tester begära att nya ändringar görs på informationssystemet eller mjukvaran. Känner sig användarna nöjda efter testerna, ger de sitt godkännande för att informationssystemet eller mjukvaran ska levereras till produktionsmiljön och slutanvändarna (International Foundation for Information Technology, 2009a).

Murat Alp (Personlig kommunikation, Bilaga 9.2.4, sid. 80, 2013), menar även att testmiljö kan innefatta och ha ett utbildningssyfte för användare. Det kan även göras parallellt med sin utbildning att användarna även testar funktionerna och bekräftar sitt godkännande för att vilja ha det i produktion, eller krav på att ändringar skall göras (likt en användaracceptansmiljö). Alp (Personlig kommunikation, Bilaga 9.2.4, sid. 80, 2013) menar att det inte är optimalt att en testmiljö används för både utbildning av användare, och för användaracceptanstestning. Men det kan hända att det görs i alla fall.

2.4 Produktionsmiljö

Med produktionsmiljö menas med den kontext där slutanvändarna verkar och använder ett system (Arvidson, 2012).

Begreppet produktionsmiljö används mest av utvecklare för att beskriva den miljö där mjukvara och andra produkter sätts i drift för avsedd användning av slutanvändare. Det kan betraktas som en realtidsmiljö där program körs och hårdvaru uppställningar är installerade som en verksamhet eller organisation förlitar sig på i sina dagliga rutiner (Janssen, 2013).

2.5 Teknisk- och social systemimplementation

Systemimplementering är ett begrepp som kan relateras till driftsättningsprocess. Systemimplementering involverar, likt driftsättning, att leverera och införa ett informationssystem till den kontext där användarna skall använda systemet (Beynon-Davies, 2002).

Vid en systemimplementation in i en verksamhet, måste man ta hänsyn till både tekniska och sociala aspekter. Enligt Beynon-Davies (2002), så skall en implementation av ett system innefatta en teknisk systemimplementation, och en social systemimplementation.

En teknisk systemimplementation innebär de aktiviteter och förberedelser som krävs för att implementera ett system i en verksamhet. Dessa aktiviteter innefattar att anskaffa mjukvara, anskaffa hårdvara, dataomvandling och överföring av data, installation av hård – och mjukvara, tester och slutligen introduktion/leverans till verksamheten och användarna (Beynon-Davies, 2002).

En social systemimplementation innebär de aktiviteter och förberedelser som krävs för att användarna i verksamheten skall vara väl förberedda och utbildade i hur man använder det nya systemet. Aktiviteterna i en social systemimplementation är att samla ihop en grupp representabla användare från verksamheten, utbilda användarna i hur man använder systemet och utvärdera användaracceptans (Beynon-Davies, 2002).

2.5.1 Tekniska systemimplementationsstrategier

Det finns forskning som har närmare tekniskt perspektiv med fokus på verkliga fall och experiment. Vi tog del av en vetenskaplig artikel där en studie utfördes som ett experiment på en driftsättning av nyutvecklat informationssystem som skulle ersätta ett befintligt arvssystem i en homogen produktionsmiljö. Forskarna utvärderade tre olika strategier för att driftsätta ett nyutvecklat informationssystem i en produktionsmiljö där ett befintligt arvssystem körs (Khan, Nisar, Munir, Anwar & Ali, 2012).

 En vybaserad strategi som förser en illusion av det befintliga arvssystemet.

 En strategi som tillhandahåller data från det omarbetade systemet till det befintliga arvssystemet.

 En strategi där det omarbetade systemet rensopar det befintliga arvssystemet (Khan, Nisar, Munir, Anwar & Ali, 2012).

Forskarna var intresserade av att se vilken av dessa driftsättningsstrategier som var mest effektiv och som orsakade minst störningar i produktionsmiljön. Att en övergång skulle ha så få störningar som möjligt var på grund av att användare skulle kunna fortsätta att använda det befintliga systemet även under driftsättningen av det nya informationssystemet. På det viset bedömde de vilken av dessa driftsättningsstrategier som bidrog till en mjuk övergång från det befintliga arvssystemet, till det nyutvecklade informationsystemet (Khan, Nisar, Munir, Anwar & Ali, 2012). Det som ofta författarna ofta återkom till i sin forskning var att när man skall driftsätta ett nytt informationssystem som skall ersätta ett äldre befintligt arvssystem i en produktionsmiljö, så är migrering av data en högprioriterad aktivitet. Migrering och överföring av data från ett äldre befintligt arvssystem till ett nytt utvecklat informationssystem är mycket viktigt då man inte vill riskera att viktig data skall gå förlorad vid byte av system (Khan, Nisar, Munir, Anwar & Ali, 2012).

2.5.2 Användaracceptans

Att uppnå acceptans hos användarna vid en implementering och/eller driftsättning av ett system in i en verksamhet är mycket viktigt att eftersträva. Enligt Thaung (2010), så är brist på användaracceptans hos användarna ett uppmärksammat problem som förekommer vid en social systemimplementation. Thaung (2010) menar att i fall där ett system skall implementeras in i en verksamhet som inte har något befintligt arvssystem, är acceptansen hos användarna hög. Däremot då ett äldre system på en verksamhet skall ersättas med något nyare, så visar sig en brist på användaracceptans hos användarna ofta i form av skepsis, då de inte förstår varför ett system skall bytas ut och vilken produktiv nytta det nya systemet kommer att ha för dem i deras arbete. Användaracceptansen hos användare styrs av användarnas inställning och vilja till förändringar (Thaung, 2010).

2.6 Förstudier

Observation handlar om att iaktta vad andra gör i en viss kontext. Vi använde oss av deltagande observation som innebär att man får vara med och iaktta en viss situation där man som forskare försöker att notera allt vi uppfattar (Oates, 2006). Det bör understrykas att detta inte var en strukturerad och utförligt planerad observation. Vi fick sitta bredvid Murat Alp, medan han satt och utförde en driftsättning i testmiljö. Han förklarade för oss hur han arbetade och vad han gjorde, medan vi fick ställa frågor spontant allteftersom de uppkom. Hela denna diskussion under observationen spelades in på ljud och transkriberades efteråt. Allt som sades under observationen som pågick under finns i en bilaga till denna C-uppsats.

3 Metod

För att få in rätt data till vårt uppsatsskrivande, använde vi oss utav en surveyundersökning. Som Oates (2006) nämner, innebär inte surveyundersökning direkt att man genomför en enkätundersökning, utan survey översätts till svenska som undersökning. Undersökningarna vi genomförde var i form av intervjuer i en kvalitativ data analys (Oates, 2006).

Vi ansåg att en kvalitativ ansats var mest lämpligt att angripa problemområdet driftsättning på med tanke på att vi bedömde det som svårt göra något mätbart inom området. Vårt syfte och frågeställning gick ut på att skaffa mera djupgående kunskaper om vilken roll testmiljöer spelar inför driftsättning av informationssysstem i en produktionsmiljö utifrån yrkesverksammas perspektiv. Därför menar vi att en kvalitativ metod passade denna undersökning mycket bättre.

3.1 Datainsamling

Vår utredning baserades på kvalitativ data. Enligt Oates (2006), är kvalitativ data att betrakta som ”mjuka data”, d.v.s. icke-numerisk data som kan omfatta inspelade intervjuer med respondenter, dokument, och observationer exempelvis.

Oates (2006) menar att intervjuer kan användas av en forskare för att få in detaljerad information från en viss respondent med hjälp av frågor. Intervjuerna kan vara strukturerade, semistrukturerade eller ostrukturerade.

Våra intervjuer var semistrukturerade eftersom att det tillät våra respondenter att uttrycka sig mera fritt och öppet i sina svar så att vi hade möjlighet att få ut så pass mycket information som möjligt från respondenterna (Oates, 2006).

Våra intervjuer skedde vid personliga möten på respondenternas arbetsplats och spelades in med bandspelare parallellt med att vi även förde anteckningar. De inspelade intervjuerna transkriberades efter själva intervjutillfället. Anledningen till att vi transkriberade intervjuerna var just för att det är enklare att analysera muntlig data som har omvandlats till skriven text form, och för att inte riskera att glömma bort viktig data som förmedlades av respondenten vid intervjun (Oates, 2006).

Teoriinsamlingen för denna studie gjordes inte enbart genom litteraturstudier och att söka efter vetenskapliga artiklar via olika databaser, utan även via en deltagande observation och intervju vid en faktisk driftsättning i testmiljö på SIGMA IT Services i Örebro den 14 november 2013.

3.1.1

Diskussion om datainsamlingen

Vi hade svårt att se hur vårt syfte skulle kunna besvaras med en kvantitativ ansats. Vi bedömde att det hade varit problematiskt att utforma en enkät som skulle passa för undersökningens syfte med tanke på den begränsade teoretiska förståelse vi hade att utgå ifrån. Däremot så hade den andra frågeställningen möjligtvis kunnat besvaras med hjälp av en kvantitativ ansats. Det hade gett oss möjligheten att ”lista upp” alla de för – och nackdelar en testmiljö medför vid en driftsättning och få en större överskådlighet.

I överlag bedömde vi att vårt syfte på bästa sätt skulle kunna besvaras med en kvalitativ ansats genom semistrukturerade intervjuer. Vi ville ge respondenterna möjlighet att utrycka sig fritt utifrån deras erfarenheter och samtidigt göra intervjun flexibel. Däremot är intervjuer inte helt problemfria att genomföra som datainsamlingsmetod. Det är svårare att uppnå konsekvens och objektivitet med intervjuer då kontexten för själva intervjutillfällena och forskarna kan påverka vilken data som framkommer (Oates, 2006). Dessutom är intervjuer även tidskrävande och kan kräva många respondenter för att öka generaliserbarheten (Oates, 2006).

3.1.2 Litteraturstudier

För denna uppsats har vi använt oss av litteraturstudier för att sätta in oss och lära oss mer om själva ämnesområdet. Teori-avsnittet är ett resultat utav våra litteraturstudier. Våra litteraturstudier baserades på vetenskapliga artiklar, kurslitteratur och internetkällor.

Sökningen efter vetenskapliga artiklar som behandlade vårt ämnesområde gjordes via Örebro universitetsbibliotekets databaser. Dessa databaser som vi genomförde våra sökningar i var Scopus, Summon, Diva och ACM-Digital Library. Vi använde oss även av Google Schoolar för just detta ändamål.

När vi sökte efter internetkällor så använde vi oss främst av internetbaserade sökverktyget Google. Dessa nyckelord användes mest för vår informationssökning:

“Information System Deployment”, “Deployment Information System”, “SCRUM Deployment”, “RUP Deployment”, “Deployment SCRUM”, “Deployment RUP”, "Deployment methods", "methods deployment", "transition rup", "Deployment methods scrum", "Deployment methods rup", "Deployment developer" , "development deployment", "deploy rup", "deploy scrum", “Produktionsmiljö”, “Testmiljö”, “Test environment”, “User Acceptance Test Environment”.

Alla artiklar som innehöll våra nyckelord och refererade till vårt ämnesområde i abstracten valde vi att samla på oss. Efter läsning av de artiklar vi hade samlat på oss, så började vi att kategorisa dessa utefter hur intressanta och relevanta vi bedömde dem vara gentemot vår avgränsning för ämnesområdet. De artiklar som inte visade sig vara tillräckligt relevanta, eller

utgick från perspektiv som vi bedömde som tekniskt svårbegripliga, kategoriserade vi som orelevanta för vår forskning. De artiklar som vi valde fram var just de som kändes mest intressanta och relevanta för forskning, där våra nyckelord är ofta och vanligt förekommande i artikelns innehåll.

3.1.3 Genomförande av intervjuer

Intervjuerna inleddes med inledande frågor till respondenterna där vi ville få reda på hur de själva utifrån deras yrkesverksamma perspektiv såg på driftsättning, vilka miljöer som är inblandade i en driftsättningsprocess och hur de såg på utmaningar rörande driftsättning. Dessa frågor ställde vi för att dels ”värma upp” respondenterna, men också för att kontrollera hur vårt teoretiska perspektiv om driftsättning och om berörda miljöer såg ut i jämförelse med deras perspektiv. Frågorna var av grundläggande karaktär för att vi skulle försäkra oss om att både vi och respondenterna pratade ”samma språk” runt ämnesområdet. Dock så bedömde vi även att respondenterna skulle kunna nämna saker som besvarar vår frågeställning och vårt syfte här också. Såhär såg de inledande frågorna ut med eventuella följdfrågor för att hjälpa respondenterna att uttrycka sig mera utförligt ifall vi kände att det behövdes:

Vad är driftsättning för dig?

a. Hur går en driftsättning till?

Vad finner ni problematiskt med driftsättning? a. Varför?

Vad är driftsättningsmiljö för er?

b. Finns det olika typer av miljöer? c. Vad är syftet med att ha dessa miljöer?

d. Finner ni det problematiskt med flera miljöer?

Efteråt ställdes våra avsedda huvudfrågor som var mer inriktade på att besvara vårt syfte och frågeställningar. Fråga nummer 1, 2 och 3 använde vi oss av som hjälp för att besvara frågeställningarna ”Varför används en testmiljö vid driftsättning?” och ”vad är för – och nackdelar med testmiljö vid driftsättning?”. Fråga nummer 2 och 3 var utformade utefter vår teoretiska förståelse om att en testmiljö kan lösa såväl tekniska som sociala (mänskliga) problem, och togs med för att de kunde relateras till frågeställningen ”vad är för- och nackdelar med testmiljö vid driftsättning?”. De frågorna såg vi även som en möjlighet att få respondenterna att uttrycka sig mera utförligt för att få mer empiriskt material att kunna analysera.

1. Vilken betydelse har testmiljö för er i driftsättning? a. Hur värderar ni testmiljön för driftsättning? b. Vad anser ni är fördelarna med testmiljö? c. Vad anser ni är nackdelarna med testmiljö?

2. Vilka tekniska problem tycker ni att testmiljö löser inom driftsättning? a. På vilket sätt då?

b. Vilka anser du är de största problemen?

3. Vilka sociala problem tycker ni att testmiljö löser inom driftsättning? a. På vilket sätt då?

b. Vilka anser du är de största problemen?

Eftersom intervjuerna var semistrukturerade, så ställdes inte frågorna alltid i just denna bestämda ordning. Alla följdfrågor ställdes inte heller beroende på hur utförligt respondenterna uttryckte sig.

 Intervju med Richard Eriksson IT-Tekniker, på SIGMA IT Services genomfördes onsdag 11 december 2013, 17.00 - 17.40 i Örebro.

 Intervju med Sven Cederkvist Driftsättningsansvarig/Konsult på Transportstyrelsen, genomfördes torsdag 12 december 2013, 09.00 - 09.45 i Örebro.

 Gruppintervju med Carl-Gustav, IT-Arkitekt/Systemutvecklare och Mikael Börjesson, IT-Förvaltningsledare, på Transportstyrelsen, genomfördes torsdag 12 december 2013, 09.50 – 10.30 i Örebro.

Vi hade hoppats på att intervjua Carl-Gustav och Mikael Börjesson var för sig, men dessvärre var inte det möjligt på grund av bristande tid från deras sida, så fick vi intervjua dem bägge två vid samma tillfälle. Under intervjun var Carl-Gustav mer delaktig i intervjuerna men Mikael Börjesson kunde komma med kompletterande svar på vissa frågor. Det fanns ingen motsägelse mellan Carl-Gustav och Mikael.

3.2 Urval

I vårt urval av respondenter kan vi se samband mellan alla dessa personer. Detta samband är att alla dessa personer jobbar inom förvaltning av informationssystem. Dessa personer berör driftsättning utav informationssystem på något sätt i daglig basis. Dessa personer jobbar med varierande roller inom driftsättning. Vi ansåg att dessa personer tillsammans med dess varierande bakgrund och erfarenheter var relevanta som intervjupersoner. Dessa personers yrkessamma roller var: Driftsättningsansvarig (Sven Cederteg, Transportstyrelsen), IT-arkitekt (Carl-Gustav Nordström, Transportstyrelsen), IT-förvaltningsledare (Mikael Börjesson, Transportstyrelsen) och IT-Tekniker (Richard Eriksson, SIGMA IT Services).

3.3 Analys

Med tanke på att utredningens data baserades på kvalitativa data, så var en kvalitativ ansats och analys en naturlig följd för oss.

Oates (2006) menar att det finns två olika angreppssätt på hur man kan analysera insamlad data. Dessa två sätt är ett deduktivt angreppssätt, och ett induktivt angreppssätt. Med ett deduktivt angreppssätt innebär det att en forskare använder sig av anskaffad teori eller skapat sig en egen teori som skall prövas och utvärderas gentemot insamlad empiridata. Med ett induktivt angreppssätt innebär det att en forskare analyserar insamlad data med ett öppet sinne och som ett ”blankt blad” där denne försöker att ta till sig datan, upptäcka mönster och dela in dessa mönster i olika kategorier (Oates, 2006).

Med tanke på att vi har gett oss in från början i ett brett och problematiskt greppbart ämnesområde som driftsättning, så upplevde vi det svårt att försöka att utforma en egen tolkad teori i syfte att pröva och jämföra denna mot empirisk data som samlats in via intervjuer (vilket ett deduktivt angreppssätt skulle innebära). Vår teorinsamling hjälpte oss att försöka bilda en teoriförståelse som vårt perspektiv grundade sig på inför den empiriska datainsamlingen. Men anledningen till att vår dataanalys utgick ifrån ett induktivt angreppssätt, är för att våra frågeställningar och syfte hade en mer utforskande karaktär som ville ta reda på kunskap i form av ett ”vad, hur, varför, och när”-perspektiv från yrkesverksamma.

När den empiriska datan analyserades, så gjordes det i förhållande till vår anskaffade teori. Även om vi använde oss utav ett induktivt angreppssätt, ansåg vi att det var viktigt att kunna aknyta till och att argumentera kring hur förhållandet mellan vår anskaffade teori och empiri förhåller sig till varandra.

3.3.1 Analys av den empiriska datan

Oates (2006) menar att det finns svårigheter med kvalitativ analys då det inte finns lika utförliga och bestämda regler att förhålla sig till och följa som vid kvantitativa undersökningar. Det innebär alltid forskaren måste tolka de data som har samlats in. Den kvalitativa data-analysen som genomfördes i denna studie följde Oates (2006) rekommendationer i två steg: Dataförberedelse och dataanalys.

Dataförberedelse-fasen innebar att våra intervjuer med respondenterna transkriberades ordagrannt för att göra den muntliga datan lättare för oss att analysera (Oates, 2006). Dennna empiriska data i form av transkriberade intervjuer med samtliga respondenter, finns i sin helhet bifogade som bilagor till denna undersökning.

Vid analysen av datan så började vi först med att läsa igenom hela de transkriberade intervjuerna, vilket Oates (2006) rekommenderar för att skapa en helhetstolkning utav det som sades under intervjuerna. Efter det så började vi att sålla bort de segment som vi inte kände hade vikt eller större betydelse för undersökningen. Sedan så försökte vi att identifiera och

upptäcka de segment i datan som vi bedömde besvarade undersökningens syfte och frågeställningar (Oates, 2006).

För att filtrera och katetorisera fram de segment som vi bedömde svarade bäst på undersökningens syfte och frågeställningar, försökte vi i första hand att titta på och analysera hur respondenterna hade svarat på de intervjufrågor som var direkt relaterade till en viss frågeställning. Om svaren från de första huvudfrågorna uppfattades som vaga, så analyserade vi hur de hade svarat på de följdfrågor som var relaterade till huvudfrågan. Om inte de heller gav tillräckligt utförliga svar, hade vi som sista utgångspunkt att titta på hur de hade svarat på våra inledande frågor, eller på andra spontana frågor under intervjuerna för att upptäcka ifall respondenterna hade nämnt något svar där som kunde relateras till som svar på undersökningens frågeställningar. Dessa segment som analyserades var olika blockcitat av respondenternas svar som gavs under intervjuerna. Blockcitaten som svar togs ut i sin helhet utan att kortas ned.

Senare tittade vi närmare på dessa segment i form av blockcitat, och kategoriserade dessa efter respektive frågeställning och respondent. På detta vis strukturerades även vår resultatdel, med en efterföljande och mer djupgående analys av dessa citat i relation till vår teoretiska förståelse som har presenterats i vårt teoriavsnitt. Vi lade vikt på att tolka respondenternas svar gentemot vår teoretiska förståelse. Det gjordes främst med hjälp av jämförelser, d.v.s att söka efter likheter och skillnader mellan empirin och den teoretiska förståelsen.

Dessa var frågeställningarna med dess relaterade huvudintervjufrågor som hjälpte oss att kategorisera segmenten av den empiriska datan:

 Varför används en testmiljö vid driftsättning? 1. Vilken betydelse har testmiljö för er i driftsättning?

a. Hur värderar ni testmiljön för driftsättning? b. Vad anser ni är fördelarna med testmiljö? c. Vad anser ni är nackdelarna med testmiljö? d.

2. Vilka tekniska problem tycker ni att testmiljö löser inom driftsättning? a. På vilket sätt då?

b. Vilka anser du är de största problemen? c.

3. Vilka sociala problem tycker ni att testmiljö löser inom driftsättning? a. På vilket sätt då?

b. Vilka anser du är de största problemen?

 Vad är för & nackdelar med testmiljö vid driftsättning?

a. På vilket sätt då?

b. Vilka anser du är de största problemen?

3. Vilka sociala problem tycker ni att testmiljö löser inom driftsättning? a. På vilket sätt då?

b. Vilka anser du är de största problemen?

Vi valde att använda oss av denna typ av analysmetod eftersom att den gav oss möjligheten att upptäcka de segment ur den empiriska datan som bäst kunde besvara undersökningens syfte och frågeställningar. Den passade även in i vårt induktiva angreppssätt och hjälpte oss att kunna både jämföra och diskutera respondenternas svar i relation till vår teoretiska förståelse som var grundad på vår litteraturstudie.

3.5 Validitet, reliabilitet och generaliserbarhet

Vi ser att det fanns brister med vår undersökning rörande dess generaliserbarhet. Även om vårt urval bestod av yrkesverksamma personer som har erfarenheter utav driftsättningar av informationssystem, så var de få till antalet. Egentligen hade vi från början räknat med att intervjua minst 4 respondenter var för sig, men dessvärre fick vi intervjua två respondenter vid samma tillfälle. På sätt och vis gav det oss en mindre förväntad intervju, och i sin stora helhet även mindre antal svar att kunna jämföra med varandra. Därmed fick vi dela in resultatet, analysen och diskussionen utefter tre intervjutillfällen. Om möjligheter hade funnits att intervjua fler respondenter hade våra resultat kunnat vara mer generaliserbara. I takt med att vi hade haft fler respondenter hade även undersökningens yttre validitet kunnat höjas. Vad som var dock värt att notera, var just att vi upptäckte likartade mönster i respondenternas svar trots att de var så pass få till antalet. Även om intervjustudien var begränsad i sitt omfång, så gav analyserna svar som var intressanta i förhållande till vårt syfte och man kunde se denna undersökning utvecklas och ”växa fram”.

Avdic (2011) beskriver att en undersöknings reliabilitet styrs av hur många slumpmässiga fel som kan finnas i en undersökning. Ju färre slumpmässiga fel i en undersökning, desto högre reliabilitet. Dock så nämner Avdic (2011) att det är mycket svårare att uppnå en hög reliabilitet i en kvalitativ undersökning, gentemot en kvantitativ. Denna vetskap bidrar givetvis till viss kritik emot denna studie med tanke på att kvalitativa interjvuer som datainsamlingsmetod kan skilja sig någorlunda i resultatutfall beroende på forskarens erfarenhet och kontexten som intervjuerna genomförs i (Oates, 2006). Dock så menar Avdic (2011) att reliabiliteten i en kvalitativ studie inte har en lika stark och betydande roll som hos en kvantitativ studie.

3.6 Etiska överväganden

Enligt Oates (2006), så har respondenterna, d.v.s. de personer vi intervjuade sina rättigheter för deltagande. Dessa rättigheter är att respondenter får själva bestämma om de ville vara med i undersökningen eller inte. Respondenterna har även rätt att dra sig ur och avbryta sin medverkan när som helst, till och med under själva intervjutillfället. Respondenterna har även rätt till att få information om vad deras medverkande skall bidra till i studien, och dessutom har även respondenterna rätt till anonymitet. Sedan har även respondenten rätt till sekretess. För att hantera dessa etiska överväganden, har vi bifogat våra intervjufrågor tillsammans med ett email till samtliga respondenter som har gett ett samtycke till att ställa upp på intervjuer med oss. Inledande information om studien och även syftet med vad studien skulle generera fram har också framförts till de inblandade. Detta bedömde vi som mycket viktigt då respondenterna fick möjlighet att förbereda sig inför intervjuerna.

De data som samlades in i form av inspelade ljudfiler från respondenterna transkriberades och slutligen bearbetades för att presenteras i C-uppsatsen. De inspelade ljudfilerna var bara tillgängliga för oss som författare. Råmaterialet spreds inte till personer som inte på något sätt var involverat i utredningsarbetet.

Vid beakting av respondentens rätt till anonymitet, så publicerade vi inte respondenternas namn eller arbetsplats utan att de gav oss tillåtelse och samtycke för att göra det.

4 Resultat

4.1 Resultat av empiri

Svaren har strukturerats efter varje respondent med de citat som vi bedömmer svarar bäst på frågeställningarna och syftet. Genom att redovisa citat vi vill visa en så obehandlad rådata som möjligt som dessutom är läsbar.

4.1.1 Varför används testmiljö vid driftsättning?

4.1.1.1 Richard Eriksson, IT-Tekniker, SIGMA IT-Services

“Ja, det är den säkerhet man har, det är det enda sättet man har att verifiera driftsättningen

kommer att bli korrekt. Till 90 procent kan man i alla fall verifiera att saker och ting ser korrekt ut om man har ordentliga testmiljöer, så det är väldigt viktigt att ha det.” Richard Eriksson. ”Ja, testmiljöer som är så lika produktionsmiljö som möjligt och som har samma saker som produktionsmiljö har, samma typer av integration så att man kan vara så nära som möjligt och vara säker på att det man bygger faktiskt kommer att lira i produktion. Det är den enda chansen att ha ordentliga testmiljöer egentligen. Att ta reda på det.” Richard Eriksson.

”Testmiljön är ju då som sagt för användartester och den ska ju förhoppningsvis vara en exakt

kopia av typ produktion i bästa fall. I den miljö släpper man in användare för att göra schemalagda tester under driftsättningfasen så att dom kan okeja att allt funkar som det ska från ett användarperspektiv. Så där har man en mycket öppnare miljö som är mindre känslig. Där har man användare som gör tester och så produktionsmiljön som är i skarp drift och bara får ändras under schemalagda releasefönster egentligen.” Richard Eriksson.

4.1.1.2 Sven Cederteg, Driftsättningsansvarig/Konsult Transportstyrelsen

4.1.1.3 Carl-Gustav Nordström, IT-Arkitekt/Systemutvecklare och Mikael

Börjesson, IT-Förvaltningsledare Transportstyrelsen

”Den har ju stor betydelse om PT-miljön är likvärdig med prod-miljön. Då är det ju ett stort värde. Om den inte är det så är det ju en lägre betydelse.” Carl-Gustav Nordström.

”Men det finns väl en funktion till egentligen, och det är ju att driftleverantören provar att produktionssätta. Så det är ju ett värde för dem så att säga. Då kan ju dem se att de installationsbeskrivningar vi lämnar fungerar för dem när de testar att installera det en gång.” Mikael Börjesson.

”Ja för att annars så skulle de ju installera första gången i produktionsmiljön. Och det har de

ju inte hittat om det skulle visa sig att det är något fel i installationsbeskrivningarna, att de är otydliga eller någonting. De får ju så att säga öva sig att installera en gång. Det är ju tanken med det. Eller en av tankarna med det.” Mikael Börjesson.

4.1.2 Vad är för- och nackdelar med testmiljö vid driftsättning?

4.1.2.1 Richard Eriksson, IT-Tekniker SIGMA IT-Services

Fördelar:

”Ja det är att man vet att det funkar oftast. Det är liksom den klara grejen att att man vet att till 90 procent så kommer det här att funka när man väl driftsätter. Sen kan det som sagt skilja sig i miljöerna. Hade man inte haft en testmiljö så hade ju varje deploy varit ett osäkerhetsmoment liksom.” Rickard Ericsson.

”Ja, det är ju det främsta att alla har en gemensam. Det sociala problemet är ju oftast

kommunikationen med användaren. Testmiljön är ett guldläge att ta reda på hur kraven egentligen ser ut. Det är egentligen oftast jag använder en testmiljön för att ta reda på om jag har förstått kraven. För att när man har utvecklat så kan man ha flera testfaser, där man tror är en enkel driftsättning visar sig vara att man får backa och göra om. Så testmiljön bidrar ju till att man kan kommunicera. Man kan låta användaren logga in i en ganska säker miljö där dom inte kan förstöra någonting och sen testa dom saker som du har gjort.” Rickard Ericsson ”Rent tekniska problem är ju de att man slipper släppa in användare för test i produktionsmiljön, t.ex. man slipper ha ofärdig kod i produktionsmiljön för testning och sådana här grejer. Har man en separerad testmiljö så behöver man egentligen aldrig blanda pågående utveckling med driftsatt produktion. Det ska man aldrig göra, och nu händer det ändå i många fall, men man ska aldrig göra det egentligen. Som motto så ska man egentligen aldrig blanda saker som är under utveckling med sådant som är utvecklat. Ett säkert recept på att någonting går ner och krashar är att blanda sådant som man checkar.” Rickard Ericsson.

Nackdelar:

”Största orsaken till fel är att produktionsmiljön, även om man tror det, inte replikerar testmiljön fullt ut eller tvärtom.” Rickard Ericsson.

”Ja det är om man har, det som kan hända är ju att man får en splittring. Just på devmiljösidan

har om man t.ex. applicerar som många kunder gör och man tycker att det är väldigt bra med virtuella maskiner, så delar man ut virtuella maskiner till alla utvecklare med en avbild på testmiljön eller vad de nu än är med alla saker uppe då. Problemet med dem här är att dels är dem separerade från test och oftast körs på lokal dator. Så det blir inte riktigt samma sak för att man inte har samma databaskopplingar. Så man kan ändå inte garantera att saker och ting verkligen kommer att funka, eftersom att man bara kan testa med textfiler eller dummydata. Utöver det så har du problemet med att om jag har 20 utvecklare och så får var och en en egen virtuell maskin, hur ser jag till att alla har sina grejjer synkroniserade? Det är ett jätteproblem med just virtuella devmiljöer, för då kan man ju utföra massa ändringar i den virtuella maskin som sen inte synkroniseras. Helt plötsligt är min maskin annorlunda från någon annans och det kan orsaka problem längre fram. Då är det viktigt att man har ett versionshanteringssystem som går utöver den virtuella maskinen så att man måste checka in sina ändringar från sin virtuella maskin i ett centralt system någonstans, och inte bara ha dom lokalt i sin virtuella maskin.” Rickard Ericsson.

4.1.2.2 Sven Cederteg, Driftsättningsansvarig/Konsult Transportstyrelsen

”Alla fel som har med kommunikationer att göra och som har med onödigt långa driftstopp i

produktionssättningen. Alla sådana saker” tvättar” man ju bort om man har en sådan produktionslik testmiljö som möjligt. Ju större skillnaden blir, ju längre blir driftstoppet och ju större blir riskerna.” Sven Cederteg.

”Testmiljön löser ju allting som har med verksamhetens krav att göra. För det kan man ju testa

av i funktionalitet till 100 % i dem miljöerna som finns. Det finns ju funktioner som gör att man ser hur webbsidan ser ut, man ser att det blir sparat, man ser att flödet får ett dokument där det går bra så att den har olika statusar när det går igenom ett ärendehanteringssystem. Så gör man ändringen så kan man se att alltihop det där lirar i testmiljö. Den svåra delen är ju när man kommer med nya saker, eller när man har gjort stora ändringar som gör att man måste ta hänsyn till kringliggande delar som brandväggar, rättigheter, nya användare, nya users och alltihop det här. Det blir ju ett riskmoment, för då är det ju olika mellan miljöer.” Sven Cederteg.

”Så är det ju, alltså alla krav går ju att lösa tekniskt. Men det är ju inte alltid så praktiskt tillämpbart för användaren att jobba med dem. Det kan ju försämra användarens arbetsmiljö i och med att man har gjort en felaktig lösning. Och det är ju det som testmiljöer ska ta bort också. Att man ska kunna följa från kravet via implementationen till det som du då nämner acceptanstester, så att man tar kravet som kunden har och så tittar man på acceptanstestet.