Uppsala universitet
Institutionen för informatik och media
Förord
Denna C-Uppsats skrevs vid Uppsala Universitet på kandidatprogrammet i Systemvetenskap. Vi vill tacka Peter Hammar som var vår kontaktperson på FOI samt Jenny Eriksson
Abstrakt
Skrivandet av rapporter är en väldigt viktig del i många samhällssektorer. Detta genomförs för det mesta manuellt idag. Att kunna automatisera rapportgenereringen har länge varit ett mål då utvecklandet av en sådan lösning skulle spara mycket tid och resurser. Frågan om hur en infrastruktur för automatiserad rapportgenerering kan se ut är väldigt aktuell både för forskning och för organisationer. Försvarsmakten är inget undantag, idag skriver de rapporter manuellt när de använder sig av ett simuleringssystem för fiktiva strider som de senare använder sig av för träning av personal. För att undersöka hur en infrastruktur för automatiserad rapportgenerering kan se ut har vi samarbetat med Totalförsvarets
forskningsinstitut (FOI). Det vi presenterar i uppsatsen är en informationsinfrastrukturmodell. Modellen är framtagen ur ett designperspektiv och behandlar en informationsinfrastruktur som är till stöd för ett simuleringssystem. Modellen är utvecklad på så sätt att den tar hänsyn till både den praktiska- och forskningsrelaterade synvinkeln. Med hjälp av krav som samlades in via intervjuer och samtal med FOI, Försvarsmakten och en expert inom området
informationsinfrastruktur så tog vi de praktiska aspekterna vid utvecklandet av modellen i beaktande. De forskningsrelaterade aspekterna för utvecklandet av modellen beaktas genom tidigare studier och metoder för att ge modellen en akademisk grund.
Nyckelord: Informationsmodell, Infrastruktur, Infrastrukturmodell, Rapportgenerator, Designprinciper, Designperspektiv, Simuleringssystem, Interoperabilitet, FOI,
Abstract
Writing reports is very important in many functions of society and is mostly done manually today. To be able to automate the generation of reports has for a long time been a challenge, and a solution would save time and resources. The question of how an infrastructure of an automated report generator could be designed is very relevant for both research and practice. The Swedish Armed Forces is no exception, currently they write reports manually when they use their simulation system for fictional battles which they later on use for training of
personnel. We have cooperated with the Swedish Defence Research Agency (FOI) to study this question. In this study, we present an information infrastructure model. The model is based upon a design perspective and concerns an information infrastructure that supports a simulation system. The model takes into account both practical and research related
perspectives. With the help of requirements that were gathered via interviews and discussions with FOI, Swedish Armed Forces and an expert within the field of information infrastructure, we took into account practical related aspects in the development of the model. The research related aspects are taken into account by using other studies and methods.
1. Inledning 1
1.1 Bakgrund 1
1.2 Problemformulering 2
1.3 Syfte och forskningsfråga 3
1.4 Kunskapsprodukt 4 1.5 Avgränsning 4 1.6 Disposition 4 2. Metod 6 2.1 Forskningsparadigm 6 2.2 Forskningsstrategi 6
2.2.1 Design science research cycles 6
2.2.2 Typer av IT-artefakt 7 2.2.3 Utvecklingsprocess 8 2.3 Datainsamling 8 2.3.1 Intervjuer 8 2.3.2 Diskussionssamtal 9 2.3.2 Litteraturstudie 10 2.3.3 Dokument 11 2.4 Dataanalysmetod 11 3. Teoretisk ram 13 3.1 Interoperabilitet 13 3.2 Designprinciper 13
3.3 Jämförelse av Interoperabilitet och Designprinciperna. 14
4. Resultat och empiri 16
4.1 Första cykelresultatet av informationsmodellen 16
4.2 Empiri 18
4.2.1 Intervju med Owen Eriksson 18
4.2.2 Intervju med Peter Hammar 19
4.2.3 Anteckningar från diskussioner 19
4.3 Andra cykeln av informationsmodellen 20
4.4 Slutliga informationsmodellen 22
4.4.1 Förklaring av entiteterna i slutliga modellen 23
4.4.2 Use Case på ett exempelscenario 24
5. Analys 26
5.2 Jämförelse av modellen mot kravsammanställningen 28
5.2.1 Jämförelse mellan kraven och litteraturen 29
6. Diskussion 31
6.1 Informationsmodell 31
6.1.1 Designval 31
6.1.2 Implementering 32
6.2 Begränsningar och svårigheter med den kommande implementeringen 33
6.2.1 Databaser i Kunskapsbasen 33
6.2.2 Svårigheter med att skapa en visualiseringsmodell för staten 33
7. Slutsats 34
Källförteckning 36
Bilaga 1. Begreppslista över databaserna i kunskapsbasen 38
Bilaga 2. Exempel på rapport 40
1. Inledning
Enligt Reiter och Dale (2000) är rapportgenerering i form av naturligt språk ett intressant område inom forskning men även en växande trend inom industrin med många sektorer som kan använda sig av denna kunskap. Med naturligt språk så syftas det på förståelig text som människan enkelt kan tolka (Reiter & Dale, 2000).
Informationsinfrastruktur definieras av Hanseth och Lyytinen (2010) som en öppen, heterogen installerad bas av IT-komponenter bland användargrupper som är baserade på öppna och/eller standardiserade interfaces. Informationsinfrastrukturer som används av en eller flera användargrupper erbjuder resurser som kan delas av dessa användargrupper för att leverera och använda informationstjänster. Själva definitionen som Hanseth och Lyytinen (2010) presenterar skiljer sig från den traditionella definitionen av ett informationssystem där artefakten ofta ses som en specifik applikation som utvecklats för att tjäna ett specifikt syfte. Existensen av en informationsinfrastruktur har inte ett specifikt syfte utan bara uttrycker en generell ide om vad den kan tillföra till användargrupper. Enligt IBM (2004) bidrar
modellering med möjligheten att visualisera stora system och kommunicera val av design innan man tar risker med teknisk implementering.
Med öppen installerad bas menar Hanseth och Lyytinen (2010) att nya IT-komponenter enkelt ska kunna läggas till och att informationsinfrastrukturen bygger på öppna standarder. Med heterogen menas det att IT-komponenterna kan vara utvecklade med olika tekniker och dataformat men ändå samverka. Den heterogena basen anses öka med tiden då nya
komponenter läggs till. Den installerade basen avser den befintliga användar- och IT-komponentbasen som informationsinfrastrukturen är baserad på.
Eftersom att Hanseth och Lyytinen (2010) beskriver informationsinfrastruktur som en heterogen installerad bas av IT-komponenter bland användare och modellering enligt IBM (2004) anses vara ett bra sätt att visualisera system så har vi kombinerat dessa två för att skapa en informationsinfrastruktursmodell över automatisk rapportgenerering i form av naturligt språk då det är ett intressant och växande område för forskning (Reiter & Dale, 2000).
1.1 Bakgrund
form av tid och pengar utan att förlora autenciteten i rapporterna (Hammar, 2017).
Rapportgeneratorn skall automatiskt skapa textuella rapporter när något sker i simuleringen, och uttrycka dessa med relevant information som formuleras så att det ser ut som om en människa har skrivit rapporten (Hammar, 2017).
Figur 1. Nulägesbild på händelseförlopp vid övning
Hittills har FOI skapat en demonstrator som visar att det är möjligt att producera textuella rapporter utifrån data som genererats från simuleringssystemet. Denna prototyp är dock bara i förstadiet och en typ av “proof of concept”, och behöver arbetas vidare på. Hur vi använde prototypen redovisar vi i kapitel 5.1.
1.2 Problemformulering
Uppsatsen behandlar ett område inom en stor informationsinfrastruktur där målet är att visa hur man med hjälp av designforskning kan skapa en informationsinfrastruktursmodell för ett rapportgenereringssystem som kan skicka ut rapporter i naturligt språk. Se bilaga 2 för ett exempel på en rapport som ska kunna skapas.
För att kunna omvandla den kod som skickas ut från simulatorn till naturligt språk så behövdes det en kunskapsbas med tillgång till en stor mängd information.
data som skickas ut från simulatorn är information om en plats där man i så fall kan matcha denna information mot en databas och få ut koordinater, orter eller dylikt.
Problemet var att identifiera vilka olika entiteter som är nödvändiga för
informationsinfrastrukturen, samt hur kommunikationen mellan dessa entiteter ska ske för att kunna extrahera informationen som behövs från kunskapsbasen och skapa rapporter som liknar mänskligt språk. Utmaning var att kunna validera modellen från både ett forsknings och praktiskt perspektiv och detta gjordes med hjälp av kraven vi samlade in och litteraturen som hittades samt via en intervju med en expert inom informationsinfrastruktur.
Figur 2. Framtidsbild på händelseförlopp vid övning
1.3 Syfte och forskningsfråga
Vår frågeställning är:
- Hur kan modellen av en informationsinfrastruktur se ut för ett
rapportgenereringssystem som stöd för ett simuleringssystem ur ett designperspektiv? Detta undersöks med hjälp av ett praktiskt exempel i samarbete med svenska
informationsinfrastruktur ur ett designperspektiv (Hanseth & Lyytinen, 2010) men att det inte finns forskning inom dessa tre områden tillsammans vilket gör att det finns ett forskningshål där vi undersöker informationsinfrastruktursmodellering för rapportgenerering som stöd till ett simuleringssystem. Dessutom finns behovet av en sådan lösning för FOI vilket bidrar till att motivera det praktiska behovet för frågan.
Denna uppsats kan även användas av andra individer och organisationer som vill utveckla en liknande infrastruktur.
1.4 Kunskapsprodukt
För att kunna svara på forskningsfrågan så har vi utvecklat en kunskapsprodukt med hjälp av forskningsstrategin som vi har redovisat i 2.2. Kunskapsprodukten som uppsatsen kommer bidra med är en informationsmodell över informationsinfrastrukturen som ska kunna användas av FOI och för framtida forskning inom området. Kunskapsprodukten togs fram med hjälp av tre olika designcykler som presenteras i avsnitt 2.1.1.
1.5 Avgränsning
Uppsatsen behandlar endast modellering av informationsinfrastrukturen, vi har inte utfört en implementering av den. Dessutom så har vi endast fokuserat på de entiteter som har en relation till rapportgeneratorn, inte på alla olika entiteter som är relaterade till
simuleringssystemet i övrigt. Detta betyder att om FOI vill implementera vår kunskapsprodukt så måste de ta hänsyn till övriga system som interagerar med
infrastrukturen. De entiteter som vi fokuserat på listar vi i 5.5.1. Vi har även bortsett helt från ekonomiska och politiska aspekter under designen av informationsinfrastruktursmodellen. Detta leder till att vår forskningsfråga inte påverkas av dessa aspekter vilket i sin tur leder till vårt resultat inte är komplett om dessa två aspekter är nödvändiga.
1.6 Disposition
Uppsatsen är indelad i avsnitten inledning (1), metod (2), teori (3), empiri och resultat (4), analys (5), diskussion (6) och slutsats (7).
2. Metod
I detta kapitel presenterar vi vår forskningsstrategi samt vår forskningsparadigm. Vi kommer därefter redogöra för den metod för datainsamling och dataanalys som vi använt.
2.1 Forskningsparadigm
Paradigmen interpretativism definieras:
“Interpretive research in IS and computing is concerned with understanding the social context of an information system: the social processes by which it is developed and construed by people and through which it influences, and is influenced by, its social setting.” (Oates, 2006, p. 292).
Vi valde interpretivismen då Oates (2006) beskriver den som en forskningsparadigm som utgår från en subjektiv sanning, vilket vi gjorde. En annan anledning till att vi valde interpretativismen är för att den handlar om att förklara, identifiera och utforska hur alla faktorer är relaterade till varandra vilket stämmer väl överens med det vi har gjort.
2.2 Forskningsstrategi
Genom den utvecklingsprocess vi följt i uppsatsen får vi fram vår kunskapsprodukt som blir vår IT-artefakt och eftersom Design and Creation har som mål att ta fram en IT-artefakt (Oates, 2006) så valde vi att utgå från den strategin.
2.2.1 Design science research cycles
Under vårt arbete har vi valt att utgå från Hevner (2007) modell “Design science research cycles”.
Denna modell är en visualisering av hur design science processen bör gå till och vårt arbete är uppdelat i dess tre olika cykler:
- Relevance cycle - Rigor cycle - Design cycle
Relevance cycle: I denna cykel så undersöks vad för verklighetsbehov som finns med arbetet. Vilka krav som ställs på den slutliga produkten och hur produkten kommer att appliceras.
Rigor cycle: Här studeras metod och val av den teoretiska basen för arbetet. Att arbetet ska bygga på forskning och studier men även att det ska bidra till framtida forskning och forskningsvärlden.
Design cycle: Under Designcykeln så byggs själva produkten i en iterativ process. Krav från det praktiska perspektivet adderas till den teoretiska basen för att kunna nå ett resultat. Validering sker även här.
2.2.2 Typer av IT-artefakt
Design and Creation har flera typer av IT-artefakter enligt March och Smith (1995) Konstruktioner (Constructs)
Koncepten eller vokabulären som används i en specifik IT-relaterad domän. T.ex. entiteter, objekt eller informationsflöde.
Modeller (Models)
Kombinationen av constructs som representerar en situation och används för att underlätta problemförståelse och lösningsutveckling. T.ex. Data flow diagram, Use case eller Storyboard.
Metoder (Methods)
Guidelines till modellen som skapas och den utvecklingsprocess som ska följas för att lösa problem genom IT. Det inkluderas formella, matematiska
algoritmer, kommersiella och publicerade metodologier som Soft Systems Methodology av Checkland & Scholes (1990) eller Information Engineering av Martin (1989). Organisationers “in-house” procedursmanualer och informella beskrivningar av praktisk mening som är härledda från erfarenhet. Instansieringar (Instantiations)
Ett fungerande system som demonstrerar att constructs, models, methods, idéer, genrer och teorier kan implementeras i ett databaserat system.
Vi har använt oss av två av dessa punkter; Konstruktioner och Modeller. För att kunna skapa en modell så behöver vi använda oss av Konstruktioner där vi fastslår entiteterna och
2.2.3 Utvecklingsprocess
Design and Creation processen är oftast problemlösande och iterativ. Vaishnavi & Kuechler (2004) säger att det finns fem stycken steg att följa.
Awareness - Identifieringen och utformandet av själva problemet, vad är det man vill undersöka. Denna kunskap kan tillhandahållas genom att man t.ex. läser studier om ett visst ämne och identifierar ett behov att utveckla det eller att man får ett uppdrag av en klient som uttrycker ett behov att något nytt eller vidareutvecklat.
Suggestion - Är själva hoppet mellan att ha en ide om vad man vill studera till att ha en plan på hur man ska tackla frågan.
Development - I denna fas implementeras den preliminära designen för IT-artefakten. Denna process ser annorlunda ut beroende på vilken typ av IT-artefakt det är man vill få fram. Evaluation - Examinering på den IT-artefakt man fått fram där man uppskattar dess värde samt hur den skiljer sig gentemot hur ens förväntningar på den var.
Conclusion - Detta är det sista steget där man befäster de resultat man kommit fram till och försöker “knyta ihop säcken”. Viktigt att identifiera om det är sådant som fortfarande är oklart även efter en studie och som i så fall kan forskas vidare på vid annat tillfälle.
Dessa steg är riktlinjer och det är viktigt att förstå att man inte ska följa dom nitiskt och i tur och ordning. Utan detta är en iterativ process där flera av stegen kan överlappa varandra. T.ex. så kan man ha haft en preliminär idé om vad som ska göras, men efter att ha försökt översätta det till ett riktigt problem inser man att det inte är möjligt. Då får man gå tillbaka ett steg och hitta ett annat sätt att formulera problemet.
2.3 Datainsamling
Datainsamlingen skedde med hjälp av intervjuer, diskussionsamtal och litteratur. Metoden rapporteras här nedan.
2.3.1 Intervjuer
Informationen vi vill få ut är väldigt detaljerad och teknisk i form av krav, därför är just valet av intervjuer en bra datainsamlingsmetod (Oates, 2006). Oates definierar intervjuer som ett speciellt typ av samtal mellan två eller fler personer. Intervjuaren har ofta en agenda med samtalet, de vill få ut information från den andra personen. Samtalet är då inte chansartat utan intervjuaren styr konversationen åt det hållet den vill att de ska gå.
Oates (2006) skriver:
semi-structured[...] interviews allows interviewees to ‘speak their minds’ and so are used where the primary purpose is ‘discovery’, rather than ‘checking’. They are therefore used for in-depth investigations, especially those aimed at exploring personal accounts and feelings. (Oates, 2006, p. 188)
Vi valde att spara intervjuerna, antingen med ljudinspelning eller videoinspelning. Därefter så transkriberade vi dessa intervjuer och använde de svar vi fick till vår uppsats.
Vi genomförde två intervjuer, den första med Peter Hammar, ansvarig forskare för hela projektet på FOI. Vi valde att intervju honom för att kunna få ut synpunkter och krav på vad modelleringen ska innehålla, samt vilka entiteter och objekt som ska ingå i infrastrukturen. Vår andra intervju skedde med Owen Eriksson som har lång erfarenhet inom
Informationsinfrastruktur och har publicerat flera studier kring ämnet (Eriksson 2010, 2013, 2015). Han är även Universitetslektor vid Uppsala Universitet.
För denna intervju så användes informationen vi fick från honom för en evaluering och validering av vår modell vilket även ledde till nya krav. Vilket i sin tur innebär att intervjun med honom blir en del av Relevance- och Designcykeln i vår designprocess.
Enligt Oates (2006) är Intervjuer en av datainsamlingsmetoderna som kan kombineras med utvecklingsprocessen i Design and Creation. I vårt fall så är intervjuerna en del av
Relevancecykeln men även en del av designcykeln
2.3.2 Diskussionssamtal
Utöver intervjuer har vi deltagit i ostrukturerade diskussionssamtal om krav som finns utöver dem vi fick ut under våra intervjuer samt krav som uppdaterats under arbetets gång med vår kontaktperson på FOI Peter Hammar och Peter Lindskog. Vi tog anteckningar som
dokumentation för att senare kunna använda dessa under utvecklingsprocessen för utförandet av kunskapsprodukterna. Viktiga delar som berördes under dessa samtal var bland annat olika typer krav som de ställde på modellen samt exempel på vad för information som behöver finnas i kunskapsbasen. Dessa diskussionssamtal går även dem under Relevancecykeln. Peter Lindskog är Utvecklingsofficer inom Ledningsträningssystem samt teknikledare på Försvarsmakten. Vi hade detta samtal under en dag då vi var på försvarsmaktens
militäranläggning i Enköping. Det är Peter Lindskog som är kontaktperson för
uppdragsgivaren för projektet åt FOI, vilket gör honom till en intressant person att samtala med då han har djup förståelse för projektet. Det som gör att andra personer inte är lika intressanta att samtala med inom försvarsmakten utöver Peter Lindskog är för att han är den personen med mest kunskap om den del av projektet som rör just rapportgenerering. Vilket leder att det är Peter Lindskogs ord som väger tyngst i och med att han är
2.3.2 Litteraturstudie
En litteraturstudie utfördes för att hitta information om det nuvarande läget när det gäller rapportgenerering, kommunikation mellan olika system och för analys om hur
informationsmodellering bör se ut i dagsläget.
En litteraturstudie är en datainsamlingsmetod som i stor utsträckning används inom
akademisk forskning som ett hjälpmedel för att skapa en bild av vad som har gjorts och vad för något som fortfarande finns kvar att göra inom ett visst ämnesområde (Oates, 2006). Det finns även fler anledningar till att göra en litteraturstudie, det kan även användas för att hitta metoder och strategier som kan utnyttjas (Oates, 2006). Detta var fallet för oss.
Sökstrategi
Vi började litteraturstudien med att söka efter definitioner av begrepp som är viktiga för uppsatsen som Informationsinfrastruktur, Rapportgenerator, Simuleringssystem och Krav vilket gav en helhetsbild över vad som skulle komma att bli uppsatsens ämnesområde och vilka begrepp som va intressanta att ta med i ett senare skede av studien. Efter att ha gjort detta sökte vi efter tidigare forskning inom informationsinfrastruktur och rapportgenerering och metoder för hur man går tillväga när man forskar inom informationssystem. Den
forskningen vi hittade identifierade ett antal teorier och tillvägagångssätt som blev uppsatsens teoretiska bas samt metod, dessa teoretiska ramverk finns redovisade i kapitel 3.
Avslutningsvis kollade vi efter tidigare forskning inom informationsinfrastruktur som hade ett praktiskt exempel, forskningen finns redovisad i 3.1.
De databaser vi sökte i när vi utförde vår litteraturstudie var Web of science, AISeL, Google scholar och även Googles sökmotor som användes för att hitta blogginlägg och dylikt. De källor som vi har studerat och hittat i databaserna och som senare har använts för vår uppsats har granskats noggrant och källkritiskt för att säkerställa att det är trovärdiga källor genom att vi endast använde oss av erkända författare, tidskrifter, förlag och hemsidor.
Motivering av teoretiska basen
Efter att ha sökt på de begrepp som var intressanta för uppsatsen så hittade vi i ett stort antal studier. De flesta av dessa studier var inte relevanta för vår frågeställning då de inte hade ett designperspektiv eller ett verkligt exempel på utveckling inom informationsinfrastruktur. Vid närmare undersökning av studierna smalnade vi av dessa till fyra intressanta studier som var relevanta för vår frågeställning. Vilka vi valde och inte valde redovisas här nedan.
I Inscribing behaviour in information infrastructure standards av Hanseth och Monteiro (1997) så förklarar de hur processen ser ut för att producera standarder för
informationsinfrastrukturer. Detta tyckte vi var väldigt intressant eftersom standarder är väldigt viktigt vid skapandet av informationsinfrastrukturer. Vi valde dock bort denna studie eftersom det kom fram under arbetets gång att FOI redan använder sig av en standard och detta leder till att processen för producerandet av en sådan standard inte var lika relevant för oss.
Forskarna Hayashi och Sueyoshi (1994) tar upp hur informationsstrukturen har utvecklats i länderna USA och Japan i sin artikel Information Infrastructure Development: International Comparison Between The United States And Japan. De förklarar hur de två länderna arbetat för att bygga information highways som de kallar det i respektive länder. Vi trodde att denna uppsats skulle vara intressant för oss men de exempel som de tar upp är alldeles för
i artikeln. Detta ledde till att vi inte valde att använda artikeln som en del av vår teoretiska bas för uppsatsen.
Till slut valde vi att grunda vårt arbete i två studier; Theorizing about the Design of
Information Infrastructures: Design Kernel Theories and Principles av Hanseth och Lyytinen (2010) och Preconditions for public sector e-infrastructure development av Eriksson och Goldkuhl (2013).
Hanseth och Lyytinen (2010) har en tydlig och väldefinierad bild av vad
informationsinfrastruktur är för något och de förklarar även hur konceptet kan appliceras i verkligheten vilket passar oss väl då det är något som vi också ville göra. Utöver det så skriver de om fem designprinciper som vi identifierade som väldigt relevanta för vårt arbete då dessa designprinciper ska agera som guidelines för hur man bör implementera en
informationsinfrastruktur. I deras exempel så visar de ett misslyckat försök till utveckling för en EDI infrastruktur för norsk sjukvård och visar på vad som händer när man inte följer designprinciperna vilket ska ge designprinciperna en typ av validitet.
I studien av Eriksson och Goldkuhl (2013) så designar och implementerar de en stor infrastruktur som använder sig av konceptet interoperabilitet. Vår bedömning var att
konceptet är väldigt relevant för arbetet då de har ett liknande projekt där de behöver hämta information från flera olika källor för att sedan sammanställa denna information i ett och samma format. Förklaring av studien finns i kapitel 3.1.
Dessa två utgjorde därmed den teoretiska basen i Rigorcykeln.
2.3.3 Dokument
Under vårt uppsatsarbete använde vi oss av dokument som FOI själva tillhandahöll för att få en bättre förståelse för vad som tidigare gjorts i projektet. Oates (2006) beskriver två olika typer av dokument. Found Documents och Researcher-generated Documents, där Found Documents innebär dokument som redan existerade inom organisationen och Researcher-generated Documents är dokument som bara tas fram för den uppgiften man arbetar med. Vi har använt oss av dokument som redan funnits inom försvaret sen tidigare i form av rapporter på tidigare faser i samma projekt. Dessa dokument är då Found Documents. Dessa har använts av oss för att vi ska förstå bakgrunden av projektet samt till vår första cykel av modellen vilket gör att dem är en del av Relevancecykeln.
2.4 Dataanalysmetod
Det viktiga för analys av intervjuer är att kunna ta ut de viktiga teman och idéerna från vad personerna säger (Oates 2006).
Ett sätt att förbereda intervjuerna inför analys är via transkribering (Oates 2006). Efter att vi utförde intervjuerna så sammanställde vi dem samma dag, vi skrev ner vad som hade spelats in och valde bort det som var irrelevant till våra frågor. Detta då det hjälper en att kunna analysera vad som har sagts. Transkriberingen lästes igenom noggrant, de mest centrala temana valdes och kategoriserades sedan i en iterativ process (Oates 2006).
Den insamlade litteraturen kan också räknas som kvalitativ då informationen som extraherades från litteraturen är detaljerad (Oates 2006).
Intervjuerna ingick bl.a. i Relevance cykeln från Hevners (2007) modell då de gav oss en bild av verklighetsbehovet i form av nya krav för modellen som vi efter att ha transkriberat
3. Teoretisk ram
Här presenterar vi den teoretiska ramen vi har valt att utgå ifrån vid skrivandet av uppsatsen
3.1 Interoperabilitet
Eriksson och Goldkuhl (2013) tar fram en modell över en infrastruktur som använder sig av konceptet interoperabilitet. I ett praktiskt problem de undersöker för socialtjänsten vill de förenkla flödet av information mellan olika myndigheter. Där har handläggaren på
socialkontoren skyldighet att kontrollera huruvida den bidragssökande redan har ekonomiskt stöd från andra myndigheter. Processen tog innan Eriksson och Goldkuhls e-tjänst väldigt lång tid eftersom handläggarna fick vänta i långa telefonköer för att kunna få ut
informationen som de behöver.
I studien kollar Eriksson och Goldkuhl på hur försäkringskassan ska kunna kommunicera med olika myndigheter för att få ut informationen de behöver genom att skapa en e-tjänst. I deras modell så använder de huvudsakligen tre koncept för att ansluta olika system med varandra.
● Gateways: En entitet som tillåter två eller flera system att integreras med varandra. ● Adapters: En adapter är ett system som översätter informationen av olika format.
T.ex. mellan två protokoller eller språk.
● System-to-system tjänster: Systemen använder sig av loose coupling genom att skicka standardiserade meddelanden till varandra.
3.2 Designprinciper
Hanseth och Lyytinen (2010) presenterar fem designprinciper för utvecklingen av en Informationsinfrastruktur som hanterar problem som uppstår angående dynamisk
komplexitet. De beskriver dynamisk komplexitet som en ökad heterogenitet, ökad mängd av relationer och ökad oförutsägbara interaktionsbeteenden mellan de olika komponenterna inom informationsinfrastrukturen.
Enligt Hanseth och Lyytinen (2010) så ingår två delproblem inom dynamisk komplexitet: bootstrap- och skalbarhetproblemen.
“(1) the bootstrap problem: IIs need to meet directly early users’ needs in order to be initiated; and (2) the adaptability problem: local designs need to recognize II’s unbounded scale and functional uncertainty” (Hanseth & Lyytinen, 2010, p. 1). Bootstrapproblemet beskrivs som utmaningen att få en bas av användare för att kunna börja använda informationsinfrastrukturen. Skalbarhetsproblemet, som beskrivs som “the
1. Initalt designa för direkt användbarhet (Design initially for direct usefulness)
Informationsinfrastrukturen ska designas på så sätt att den huvudsakliga användargruppen direkt kan börja använda infrastrukturen. Man bör anpassa infrastrukturen till dem
användarna oavsett storlek på gruppen. Denna princip är väldigt viktig om det inte redan finns en existerande bas av användare. Infrastrukturen ska vara simpel och så billig som möjlig för de första användarna.
2. Bygga på redan existerande installerade baser (Build upon existing installed bases) Designa IT komponenter så de inte är beroende av nya understödjande infrastrukturer. Bygga gateways för att implementera dem i den redan existerande infrastrukturen. Dessutom ska man använda sig av redan etablerade tekniska lösningar (Hanseth & Lyytinen, 2010). 3. Expandera installerade baser med övertygande inskrivningstaktikter (Expand installed base with persuasive enrollment tactics)
Författarna använder sig av frasen “users before functionality”. Här ska fokuset vara
användarna och försöka att öka antalet av användarna men även att göra dem så engagerade som möjligt. Infrastrukturen får ökad värde av antalet användare och inte funktioner.
4. Göra IT kapaciteten så simpel som möjligt (Make the IT capability as simple as possible) Hanseth och Lyytinen (2010) anser att man ska använda sig av enkla arkitekturprinciper under den initiala designfasen. De resonerar så att det i senare faser är lättare att förändra något litet och mindre komplext än att ändra något stort och komplicerat. Systemen ska ha enkla funktioner och vara separata istället för ett system med flera funktioner.
5. Modularisera informationsinfrastrukturen (Modularize the information infrastructure ) Organisera infrastrukturen i olika moduler, alltså dela upp infrastrukturen i separata
applikationer, tjänster, transportsystem och sub-infrastrukturer. Försöka nå en sådan “loose coupling” som möjligt. Viktigt att använda sig av gateways mellan olika entiteter i
infrastrukturen.
Dessa fem principer som Hanseth och Lyytinen (2010) presenterar är menade för att lösa problemen med bootstrapping och skalbarhet. Bootstrapproblemet som författarna presenterar är inte fullt relevant för vår uppsats men de flesta av principer som används för att lösa detta problem anser vi fortfarande vara relevanta för oss. Det för att huvudsyftet med Hanseth och Lyytinens (2010) uppsats är att visa vad man bör tänka på när man utvecklar en
informationsinfrastruktur vilket är bra för oss då vi vill göra just detta.
Med hjälp av dessa designprinciper och kraven vi samlar in under projektets gång så
designades en informationsinfrastrukturmodell som presenterades som vår kunskapsprodukt
3.3 Jämförelse av Interoperabilitet och Designprinciperna.
I Eriksson och Goldkuhl (2013) studie så utgår de, likt oss, ur ett informationsinfrastrukturellt perspektiv. Deras koncept Interoperabilitet använder de för att kunna kommunicera bland olika myndigheter som använder sig av olika format på information. De tre komponenter som Interoperabilitet använder sig av är till för att kunna modularisera e-tjänsten.
4. Resultat och empiri
I detta kapitel presenteras resultatet från de två cyklerna som har gått igenom design and creation processen i form av stegen awereness, suggestion, development, evaluation och conclusion som förtydligades i kapitel 2.2.3. Vi utgick även från Hanseth och Lyytinens (2010) och Eriksson och Goldkuhl (2013). Utöver detta har vi använt oss av den empiri som vi samlat in via olika källor som intervjuer och diskussioner och samtal för att skapa våra modeller. Vi har med hjälp av dessa skapat en sammanställning av de krav som vi har fått för att skapa modellen. Vi följer även i detta kapitel Hevners (2007) modell där vi både designar och evaluerar (Designcykeln) samt får in nya krav (Relevancecykeln).
4.1 Första cykelresultatet av informationsmodellen
I det första cykelresultatet utgick vi först och främst utifrån den bakgrundsinformation vi fick av projektet i form av en rapport skriven av FOI samt ett första inspirationsmöte med vår kontaktperson på FOI Peter Hammar där han förklarade den övergripande visionen han hade för systemet. Därefter bad han oss komma med ett förslag på hur det skulle kunna se ut. Under den första cykeln utgick vi från de fem steg i Design och creation processen som Vaishnavi & Kuechler (2004) tagit fram och som vi beskrivit i kapitel 2.2.3.
Awareness
I det första steget awareness så försökte vi bestämma vad det var för problem som skulle undersökas. Det gjorde vi främst genom att utgå från den bakgrundsbeskrivning vi fått av FOI för projektet och genom ett första inspirationsmöte med vår kontaktperson på FOI Peter Hammar.
Suggestion
Under steget suggestion försökte vi hitta ett sätt att föra över de ideer som som fanns till en konkret modell. Vi utförde en litteraturstudie där vi fann Hanseth och Lyytinens “Design Theory for dynamic complexity in information infrastructures: The case of building the internet (2010) och Goldkuhl och Erikssons Preconditions for public sector e-infrastructure development (2013). Hanseth och Lyytinen beskrev ett antal designprinciper som man bör följa när man utvecklar en informationsinfrastruktur. Designprinciperna beskrivs i kapitel 3.2. I Goldkuhl och Erikssons (2013) artikel skriver de väldigt mycket om interoperabilitet med hjälp av system-to-system tjänster vilket genomsyrar vår modell. De presenterade även en modell där de använde sig av en gateway och adapters för att kommunicera med flera olika system på samma gång vilket togs i beaktning vid utvecklandet av vår modell.
Development
I denna fas använde vi oss av den samlade informationen vi fått från FOI om
Evaluation
Efter att ha skapat vår modell ville vi först ha feedback från vår kontaktperson på FOI som är Peter Hammar samt av uppdragsgivaren för projektet Peter Lindskog i form av intervjuer. Då vi haft möjligheten att utveckla modellen med fria händer ville vi se vad för krav det fanns som vi missat genom att bara ha bakgrundsinformationen. Den kunskapsprodukt vi
presenterar i denna uppsats är vår informationsmodell och därför ville vi ha den validerad av en person som är kunnig inom ämnet. Vi fick universitetslektorn och experten inom ämnet informationsinfrastruktur Owen Eriksson att ställa upp på en intervju för att ge sina tankar om modellen.
Conclusion
Då vi fick mycket feedback på vår modell av olika parter insåg vi att vi kommer att behöva göra en till iterering av alla stegen för att kunna skapa en modell som är implementerbar samt grundad i forskning. Efter intervjuerna och andra diskussioner och då krav definierar ett konsistent språkbruk som kan användas av utvecklare, användare och testare (Microsoft, 2017) så kommer vi även presentera en kravsammanställning som stöd för modellen. Kravsammanställningen finns presenterad i bilaga 3.
Vi har även lagt till en begreppslista på de databaserna som ska rapportgeneratorn ska ha tillgång till och exempel på attribut som dessa databaser innehåller, begreppslistan finns i bilaga 1.
4.2 Empiri
I detta kapitel presenterar vi en sammanställning av de två intervjuerna vi har utfört med Owen Eriksson och Peter Hammar. Utöver intervjuerna så presenteras en sammanställning av diskussionen med Peter Lindskog. Valet av dessa personer motiveras i avsnitt 2.3.1. Intervjun med Owen Eriksson utfördes den 18/04/2017. Peter Hammar intervjuades den 05/04/2017 medan diskussionen med Peter Lindskog ägde rum den 20/04/2017.
Intervjun med Peter Hammar och Peter Lindskog utfördes för att samla in krav för det praktiska perspektivet som ingår i Relevance cykeln medan intervjun med Owen Eriksson utfördes för att validera första iterering av informationsmodellen och därmed ingår i Design cycel. Dessa olika cykler förklaras i 2.1.1. Informationen som härleddes från intervjuerna finns samlade i kravform som presenteras i bilaga 3.
4.2.1 Intervju med Owen Eriksson
Målet med intervjun var att Owen skulle få validera det första utkastet vi skapade för vår modell. Vi valde att utföra denna intervju då vi i vårt sista steg av vår utvecklingsprocess i första cykeln av modellen insåg att vi ville ha en validering på modellen så att vi kunde få tillgång till ytterligare krav. Detta gjorde att Owen med sin breda erfarenhet inom ämnet skulle kunna se om han tyckte vårt förslag skulle kunna implementeras i teorin samt att han skulle kunna komma med synpunkter på förbättringar.
Figur 4, avsnitt 4.1 representerar det första utkastet av modellen som vi visade Owen samt en figur av modellen för hur rapportgeneratorn ser ut i nuläget.
Owen ansåg att det var bra att vi frikopplat kunskapsservicen från rapportgeneratorn då det leder till att systemet har en ökad modularisering som är bra vid ändringar i systemet i
framtiden då man bara behöver ändra det som behöver det som ska ändras då de olika delarna inte är beroende av varandra.
En annan synpunkt som Owen hade var att han tyckte att vår adapter förmodligen skulle behöva vara flera adapters och att dessa adapters då var kopplade till en databas var. Detta leder också till att varje gång en databas läggs till så skulle en ny adapter behöva skapas. Angående hur man skulle veta vilken data som skulle skickas till vilken databas så tyckte Owen att det va multifrågan som skulle ha “intelligensen” och på något sätt veta till vilken adapter den ska skicka datan vid varje fråga.
Owen tyckte också att vår lagringsdatabas som vi hade istället skulle vara en logg som bara skulle logga den information som skickats från databaserna och en stor fråga tyckte han då var huruvida loggningssystemet skulle gå via rapportgeneratorn eller via multifrågan. Han poängterade dock att om kopplingen skedde mellan adaptern-loggen-rapportgeneratorn så skulle det vara bra för statistiska bearbetningar och det skulle även vara enklare att utföra SQL queries på loggningssystemet.
4.2.2 Intervju med Peter Hammar
Intervjun med Peter Hammar ägde rum med målet att samla in krav på hur
informationsmodellen ska se ut, samt att få en bättre förståelse om alla entiteter och deras funktioner och relationer i infrastrukturen.
Angående HLA federationen förklarade Peter att den kan ses som “informationsbussen” i infrastrukturen. HLA är den infrastruktur som kopplar ihop flera modeller och simuleringar i samma system. Alla system som är i behov av att utbyta information med andra federater är anslutna till HLA federationen. Detta för att ha en infrastruktur med flera små system istället för ett stort system då det bidrar med interoperabilitet samt återanvändning. HLA
federationen använder dessutom sig av en språkstandard.
Peter beskrev den nuvarande rapportgeneratorn som en prototyp. Många funktioner är tillgodosedda men de flesta är hårdkodade. Istället för moduliserade databaser använder den sig av textfiler som den parsear. Dessutom sparas inte informationen efter runtime.
Om kunskapsbasen ska vara ansluten till HLA federationen så måste den följa standarderna som HLA federationen kräver. Om kunskapsservicen endast är ansluten till
Rapportgeneratorn så är användandet av ett format för kommunikation helt fritt.
Säkerheten på kommunikationen beror på om vi väljer att ansluta kunskapsservicen till HLA federationen eller endast till rapportgeneratorn. Om den är ansluten till HLA federationen så måste den följa standardiserade säkerhetsprotokoll. FOI använder ett sig av ett stängt nätverk och det finns redan restriktioner på att använda deras nätverk.
Enligt Peter Hammar ska det även finnas en databas som lagrar alla rapporter, den ska vara sökbar. Det ska vara möjligt att extrahera tidigare rapporter då det bidrar till skapandet av nya rapporter.
4.2.3 Anteckningar från diskussioner
Anteckningarna som skrevs ner under projektets gång används som ytterligare krav på
informationsmodellen utöver litteraturen och intervjuerna. Dessa anteckningar utfördes under diskussioner med Peter Lindskog och Peter Hammar.
Enligt Peter Lindskog ska en person kunna editera rapporterna innan de går vidare till externa system. Vidare ska lagringsdatabasen även innehålla rapporter som kommer externt från andra system.
Peter Lindskog gav även förslag på databaser och attribut som dessa databaser bör innehålla. Exemplet på databaserna han listade va en Geodatabas som exempelvis kunde innehålla koordinater. En personaldatabas som kan innehålla olika beteenden och en Time and unit conversion databas med Km/h som attribut. Alla databaser och dess attribut som Peter Lindskog har nämnt listar vi i Bilaga 1.
Efter att ha brainstormat tillsammans med Peter Hammar om på vilket sätt man skulle veta vilken information man skulle få ut ur kunskapsbasen så att den verkar mest realistisk kom vi fram till att det vore smidigast att ställa in en nivå av beskrivning på den information man ville få ut. Så exempelvis om kunskapsservicen fick information från simulatorn att en soldat upptäckt ett fordon som färdades i en viss hastighet så skulle beskrivningen kunna vara mer eller mindre detaljerad. T.ex. om nivån är inställd på den lägsta beskrivningsgraden skulle det från databasen extraheras svaret “Fordon som färdas snabbt” medans om nivån istället skulle vara inställd på den högsta beskrivningsnivån så skulle svaret kunna vara “Fordon färdas i ca 50 km/h i riktning österut”.
Vi kom även fram till att Kunskapsservicen ska ha tillgång till tidigare rapporter för att kunna använda dessa vid skapandet av nya rapporter och att redigerade rapporter i rapportgränsnittet ska bli uppdaterade i historiklagringen
4.3 Andra cykeln av informationsmodellen
Under den andra cykeln fortsatte vi att utgå från de fem stegen inom Design och creation som Vaishnavi & Kuechler (2004) presenterat. Till denna cykel fortsatte vi att använda oss av teorierna samt bakgrundsfaktan men vi fick även utgå från de nya kraven som uppkom genom våra intervjuer med Peter Hammar, Peter Lindskog och Owen Eriksson. Dessa krav har vi listat i vår kravsammanställning i bilaga 3.
Awareness
I det första steget hade vi redan en bild av vad som var problemet sen tidigare men tack vare de diskussioner och intervjuer vi hade med Peter Lindskog och Peter Hammar fick vi en ännu tydligare bild av vad de hade för krav på modellen. Owen Eriksson gav oss feedback och validering av modellen som vi också behövde ta hänsyn till när vi skulle göra den nya versionen.
Suggestion
I detta steg så utgick vi mycket från de vi redan tagit upp i första cykeln för modellen. Det vi var tvungna att lägga till är hur vi skulle ändra i vår modell för att uppfylla de krav vi fått fram genom våra intervjuer.
Development
I den andra cykeln av informationsmodellen utgick vi från den feedback och nya krav som ställdes av Peter Hammar, Peter Lindskog samt Owen Eriksson i form av intervjuer och samtal. De kraven vi utgick ifrån samt de tidigare kraven vi fått har vi listat i vår
kravsammanställning som kan ses i bilaga 3. Evaluation
Conclusion
Slutsatsen för den andra cykeln av vår modell blev att vi insåg att vi ville kunna visa hur vi tänker att modellen ska fungera samt visa på att de krav vi har utgått från är uppfyllda. Därför gjorde vi en tabell där vi visar på hur väl modellen uppfyller vår kravsammanställning samt de designprinciper som vi skulle följa när vi skapade modellen. Vi bestämde oss även för att skapa ett “Use case scenario” där läsaren kan följa ett händelseförlopp där det börjar med att simulatorn reagerar på ett event i simulationen och skickar ut det till rapportgeneratorn tills dess att rapporten skickas vidare till de övade, detta “use case” är skapat med ett
4.4.1 Förklaring av entiteterna i slutliga modellen
Simulationssystem är programmet som simulerar konflikter och skickar ut datapaket i kodform på event och statusuppdateringar om olika objekt i simuleringssystemet. Datapaket som skickas ut är riktat till HLA Federationen.
HLA-federation är det systemet som kopplar samman alla system så att de kan kommunicera med varandra. High level architecture (HLA) beskriver den “strukturella uppbyggnaden hos det programsystem och den infrastruktur som krävs för att olika typer av modeller ska kunna kopplas ihop i gemensamma simuleringar för att kunna samverka med varandra samt kunna återanvändas som komponenter i framtida gemensamma simuleringsstudier och övningar” (Holm, 2007). Enligt Dahmann (1998) så är HLA även ett arkitekturkoncept för
återanvändning och interoperabilitet. När en mängd modeller samverkar med varandra efter HLA standarden för ett specifikt syfte så kallas det för en HLA federation (Holm, 2007). Historiklagring är den databas som ska spara de tidigare rapporterna. Både de som genererats av rapportgeneratorn samt de rapporter som inkommer från andra rapportsystem.
Historiklagringen kommer även att spara metadata från ännu ej skapade rapporter. Det är även möjligt att utföra queries på historiklagringen för att få ut tidigare rapporter.
Historiklagringen är även en databas i kunskapsbasen som kan användas av Kunskapsservicen precis som de andra databaserna.
Rapportgränssnitt är entiteten som tar emot rapporter som skapats i de olika rapportsystemen. En människa ska kunna interagera med detta system för att välja när rapporter ska skickas vidare till de övade samt kunna redigera innehållet om det anses nödvändigt. Dessutom så är det möjligt att extrahera tidigare rapporter direkt från historiklagringen. Det är även i
rapportgränssnittet som all mänsklig interaktion sker. Det är här man konfigurerar vilken nivå av beskrivning på datan man vill ha samt antal rapporter som ska skapas under t.ex. en
timme.
Rapportgeneratorn är entiteten som innehåller Rapportpumpen, Kunskapsservicen,
Adaptrarna och Kunskapsbasen. Entiteten tar emot simulationsdatan från HLA Federationen, omvandlar denna data till mänskligt språk och skickar sedan tillbaka informationen i form av en rapport till HLA Federationen.
Rapportpumpen är det yttre systemet i Rapportgeneratorn, den har direkt kommunikation med HLA Federationen men även en relation till Kunskapsservicen. När rapportpumpen får tillbaka informationen från Kunskapsservicen så skapas rapporterna som sedan skickas ut till HLA Federationen.
Kunskapsservice är det systemet där datan från simuleringen först omvandlas till ett standardiserat språk som t.ex. XML för att därefter skicka vidare datan i form av en multifråga till kunskapsbasen. Här finns även information om routingen av frågorna, dvs. vilken databas varje fråga berör. Även vilken beskrivningsnivå på informationen man vill få ut ställs in här samt antal rapporter som ska skapas. Allt detta styrs via det gemensamma gränsnittet som finns i Rapportgränssnittet.
Adaptrarna omvandlar frågorna från kunskapsservicen till databasspecifik språk för att kunna kommunicera med Kunskapsbasen. När informationen är extraherad så omvandlas den
Kunskapsbas är det samlade namnet för alla databaser som innehåller den informationen som är relevant att extrahera för de frågor som ställs av kunskapsservicen. De olika databaserna i kunskapsbasen måste innehålla information för att t.ex. förstå att ett mekaniserat kompani består av stridsvagnar, och att en stridsvagn är ett bandgående fordon som därför har ett visst ljud och kan färdas med en viss hastighet, samt att det är rimligt att fienden vill belägra en stad. Den information som måste tillgängliggöras innefattar militär verksamhet (t.ex. fientliga förbands position och aktivitet), beskrivning av vilka militära enheter och förband som ingår, samt vilken utrustning (fordon, vapen) dessa har men också beskrivning av utrustningen i sig. Därtill behövs övergripande förståelse för den geografiska, politiska och samhälleliga ram den militära operationen agerar inom, t.ex. vilka aktörer (stater, myndigheter, gerillagrupper, etc.) som finns, vad som karaktäriserar dem och hur de förhåller sig till varandra. Andra exempel är städer eller flygplatser som militären skyddar eller måste förhålla sig till. En lista med mer exempel på databaser och objekt i Kunskapsbasen finns i Bilaga 1.
4.4.2 Use Case på ett exempelscenario
Med hjälp av ett exempelscenario så har vi illustrerat hur händelseförloppet kan se ut i infrastrukturen. Exempelscenariot fungerar som ett förtydligande för användningen av modellen. Vi utgick från numreringen i modellen för att beskriva de olika stegen. Användare: Administratör eller liknande på försvaret som styr övningen Förutsättningar:
● Nivån på beskrivning av information måste vara inställt via gränssnittet
● Antal rapporter som skapas för en viss tidsperiod måste vara inställt via gränssnittet.
● Routingen för de databaser som ska användas måste vara konfigurerat via gränssnittet.
Händelseförlopp:
1. Det sker en händelse i simulatorn och Geodata samt
Equipmentdata skickas ut i kodform från simulatorn till HLA federationen.
2. Kunskapsservicen tar emot datan i kodform via HLA federationen och omvandlar det till XML.
3. Den Geodatan samt Equipmentdatan som skickas in till Kunskapsservicen får sin tagg på vilken nivå av beskrivning som ska extraheras ur databaserna och görs därefter om till två frågor som routas vidare till korrekt databasadapter.
databasen så att rätt information utvinns. Informationen som vi fick i detta exempel är ortnamn och vapentyp.
5. Informationen som utvunnits från kunskapsdatabasen skickas vidare till rapportpumpen som skapar en rapport samt omvandlar rapporten till HLA standard.
6. Rapporten som har skapats skickas tillbaka in till HLA federationen.
7. Historiklagringen lyssnar på HLA federationen efter vår nyskapade rapport och sparar denna i sin databas för senare användning.
8. Rapportgränsnittet lyssnar på HLA federationen efter den nyskapade rapporten och tar emot den.
9. Efter att en användare fått ta till sig av rapporten i
rapportgränssnittet så redigerar användaren rapporten lite så att den bättre passar det nuvarande läget i övningen baserat på tidigare rapporter som användaren extraherat från
5. Analys
I detta avsnitt så jämförs kunskapsprodukten, d.v.s. informationsinfrastrukturmodell som resulterade från den andra cykeln i kapitel 4.4 med designprinciperna (3.2) och
kravsammanställningen (bilaga 3).
Dessa jämförelser utförs för att se hur väl modellen uppfyller de designprinciper och krav som vi utgått ifrån och om dessa krav och designprinciper inte uppfylls, motiverar vi till varför de inte gör det.
5.1 Jämförelse av modellen mot Designprinciperna (Hanseth & Lyytinen,
2010)
I detta kapitel gör vi en jämförelse av vår slutgiltiga modell mot de designprinciper som presenteras av Hanseth och Lyytinen (2010) för att se hur väl vår modell uppfyller dessa principer.
Designprincip Efterföljs principen?
Design initially for direct usefulness Nej
Build upon existing installed bases Ja
Expand installed base with persuasive
enrollment tactics Nej
Make the IT capability as simple as possible Ja Modularize the information infrastructure Ja Tabell 1. Jämförelse av modellen mot Designprinciperna
I och med att vi har skapat vår modell så uppfyllde vi tre stycken av de fem övergripande designprinciperna som Hanseth och Lyytinen (2010) presenterat. Vi kommer i detta avsnitt förklara på vilket sätt vi uppfyller tre av dem och varför vi inte uppfyllde de andra.
Design initially for direct usefulness är enligt Hanseth och Lyytinen den första designprincipen som man bör följa. Enligt dem så bör man direkt identifiera en liten
ut till fler användare. Men för att detta ska fungera måste man redan ha en tydlig användarbas som inte kommer att förändras.
Hanseth och Lyytinen beskriver Build upon existing installed bases som att bygga vidare på den underliggande infrastrukturen som redan existerar och inte använda sig av nyskapade lösningar. Detta är en designprincip som vi har följt då vi utgick från en tidigare prototyp samt att vi har använt oss av HLA-konceptet som redan finns inom organisationen för att kommunicera med andra system. Vi ger även förslag om att använda redan existerande transportprotokoll som XML. De använder återigen internet som ett exempel där TCP/IP kommunikationen som användes i början av internet skickades över de redan existerande telefonkommunikationerna som fanns för att sedan utvecklas till mer avancerade metoder. De finns ett antal fördelar med detta då det bidrar till att det krävs mindre resurser och tid samt att man kan undvika att hamna i diverse fallgropar. Det bidrar också till en ökad
modularisering då användandet av standardiserade transportprotokoll gör att system kan kommunicera med varandra lättare. Nackdelen med att göra detta är att du hela tiden måste förhålla dig till den den existerande installerade basen och på så sätt riskera att man ibland kan bli begränsad och vilja skicka en viss typ av data som inte stöds av redan existerande tekniker. Den prototypen som FOI redan hade skapat som en demonstrator användas här som installerad bas.
Expand installed base with persuasive enrollment tactics är också en designprincip som vi inte har fokuserat på så mycket. Vi har valt att inte göra de till stor del för att den är en vidareutveckling på den första designprincipen “Design initially for direct usefulness” och inte relevant för oss. Där utgår man från den användargrupp som identifierades i det steget och fortsätter att öka sin användarbas och sätter användarna före funktionaliteten i systemet vilket inte är vårt mål med modellen.
Med Make the IT capability as simple as possible menar Hanseth och Lyytinen på att det är lättare att ändra på något som är simpelt än något som är komplext. Det är en designprincip som vi utgått ifrån när vi skapat modellen då vi använder oss av tidigare använda
5.2 Jämförelse av modellen mot kravsammanställningen
I tabellen nedan så använder vi oss av kravsammanställningen som togs fram och presenteras i bilaga 3 för att se om vår slutliga modell uppfyller dessa krav. Dessa krav är samlade med hjälp av intervjuer och diskussioner och var till grund inför andra cykeln.
Krav Efterföljs kravet? Kommentar
Rapportgeneratorn ska vara ansluten till HLA
federationen
Ja Hela Rapportgeneratorn är ansluten till HLA
federationen via Rapportpumpen Om databaserna är direkt
anslutna till HLA
federationen så måste de följa HLA standarder
Ja Endast historikdatabasen är ansluten till HLA
federationen, och den följer HLA standarder. De andra databaserna är inte direkt anslutna.
En databas som lagrar alla rapporter
Ja Historiklagringen
Databasen som lagrar alla
rapporter ska vara sökbar Ja Via rapportgränssnittet kan en användare söka på historiklagringen.
Kunna ställa in vilken nivå av beskrivning som
rapporten ska skicka ut
Ja Detta kan man göra via det gemensamma gränsnitt som styrs via rapportgränsnittet. Frikoppla kunskapsservicen
från rapportpumpen Ja Den är frikopplad för ökad modularisering i systemet. Flera adapters istället för en Ja Varje adapter tar hand om
den specifika databasen den är ansluten till.
Multifrågan ska göra routingen till databaserna
Ja Varje fråga som kan ställas ska komma med
headerinformation/metadata om vilken databas den ska söka i. Databaserna och routingen bestäms via rapportgränsnittet. Rapportgeneratorn ska vara
Begreppslista som förklarar objekten och dess attribut i databaserna.
Ja Finns i bilaga 1.
En person ska kunna editera rapporterna innan de
skickas vidare i infrastrukturen
Ja Detta sker i
rapportgränsnittet.
Historiklagringen ska även kunna innehålla rapporter som kommer från externa system
Ja Eftersom rapporterna som ska sparas i historiklagringen går via HLA federationen så uppfylls detta.
Det ska finnas ett enda gränssnitt för konfigurera rapportgeneratorn.
Ja All användarinteraktion sker i ett gemensamt gränsnitt via rapportgränsnittet.
Kunskapsservicen ska även ha tillgång till tidigare rapport för att kunna
använda dessa vid skapandet av nya rapporter.
Ja Dessa uppfylls eftersom historiklagringen även används som en databas i kunskapsbasen eftersom den är direkt ansluten till
kunskapsservicen via en adapter.
Redigerade rapporter i rapportgränsittet ska bli uppdaterade i
historiklagringen
Ja Detta sker per automatik när användaren har redigerat klart rapporter i
rapportgränsnittet. Rapportgeneratorn ska
kunna fungera i ett stängt nätverk
Ja Det säkerställs via routingen och adaptrarna
Kunskapsbasen ska ha möjlighet att innehålla databaser som ligger ute på internet
Ja Det säkerställs via routingen och adaptrarna
Tabell 1. Jämförelse av modellen mot Kravsammanställningen
5.2.1 Jämförelse mellan kraven och litteraturen
De krav vi har samlat in och använt för att komma fram till modellen har även relationer till litteraturen som vi valde för arbetet.
Vi har även tagit hänsyn till Eriksson och Goldkuhls (2013) tre koncept vid utvecklandet av vår första cykel av informationsmodellen; Gateways, Adapters och System-to-systemtjänster. Dessa koncept är till för att skapa en interoperabel modell, därför så ingår dessa per
automatik i Hanseth och Lyytinens (2010) designprincip Modularize the information infrastructure.
I principen Build upon existing installed bases så ingår ett antal av våra krav, närmare bestämt de kraven som begär att systemen vara kopplade till HLA federationen. HLA federationen är en plattform som redan finns på FOI sedan tidigare och som används som standard för simulationssystem i hela organisationen. Utöver kraven relaterade till HLA federationen så finns det också ett krav som beskriver att historiklagringen ska kunna lagra rapporter från externa system, detta eftersom det redan nu finns ett rapportgenereringssystem som skickar in redan skriptade rapporter. Ett annat krav begär att det ska finnas en
begreppslista på objekten och attributen i databaserna som ingår i kunskapsbasen eftersom det redan sedan tidigare finns en bestämd information som rapporterna behöver kunna hantera.
De krav som ingår i principen Make the IT capability as simple as possible är bl.a. kravet som handlar om att ställa in nivå av beskrivning av rapporterna. Kravet löste vi genom att ha ett gemensamt gränsnitt som kontrollerar alla olika konfigurationer i rapportgeneratorn istället för en mer avancerad lösning som randomiserande av den information som man får ut eller en typ av AI lösning som bestämmer vad för nivå av beskrivningar som ska finnas. De andra kraven som ingår i denna designprincip är kraven som bestämmer vilka relationer historiklagringen ska ha. Vi valde att göra en direkt koppling mellan historiklagringen och andra entiteter istället för att ansluta historiklagringen med hjälp av gateways och adapters för att hålla infrastrukturen kring entiteten simpel.
Modularize the information infrastructure är principen som handlar om att ha system isärkopplade och där kommunikationen ska ske med hjälp av meddelanden. Här så ingår kraven angående adapters, routingen och frikopplingen mellan kunskapsservicen och
rapportpumpen. Även kravet om att rapportgeneratorn ska fungera utan eller med anslutning till internet hamnar här eftersom beroendet av anslutning till internet försvinner, och med det så blir infrastrukturen mer modulariserad.
Utöver de krav som hamnar i kategorierna för dessa tre designprinciper så finns det två som inte hamnar i någon av dessa kategorier. Dessa två krav går inte i konflikt med de andra kraven eller de tre designprinciperna, därför tog vi hänsyn till dessa krav när vi utförde modellen. Ett av kraven är kravet som handlar om att en person ska kunna redigera rapporterna innan de skickas vidare till externa system. Det andra kravet är att
6. Diskussion
I uppsatsen har vi utgått från ett designperspektiv som är baserat i forskning vilket leder till att det resultat vi presenterat är av forskningsvärde, det går att utveckla resultatet vidare då det har en akademisk grund vilket leder till en spårbarhet för resultatet. Detta till skillnad från om vi hade utfört ett direkt konsultuppdrag för en organisation. Det skulle då leda till att vi inte hade behövt dokumentera och motivera de val vi gjort för att nå vårt resultat, detta betyder att vi skulle ha sparat tid men att det inte skulle existera någon spårbarhet för resultatet.
För vår Designprocess så använde vi oss av Design and Creation. Vi följde Vaishnavi & Kuechlers (2004) utvecklingsprocess som beskrev fem stycken steg som skulle leda till en produkt. De fem stegen följdes iterativt av oss i två cykler som ledde till vår slutliga modell. Fördelen med utvecklingsprocessen för oss var att vi hade tydliga steg som vi kunde följa. En annan fördel med att följa processen var att vi tydligt dokumenterade cyklarna vilket leder till en ökad spårbarhet för modellen
6.1 Informationsmodell
I detta kapitel diskuterar vi några komponenter i informationsmodellen som vi tycker är relevanta för diskussion. Vi inleder med att diskutera de designval som vi gjort i modellen och försöker förtydliga varför vissa entiteter är kopplade som de är. Vidare så fortsätter vi med att ta upp framtida implementering av modellen.
6.1.1 Designval
Under skapandet av modellen så hade vi litteratur att utgå från och fick tillsammans med de krav vi samlat in utgå från tidigare teorier och metoder ur litteraturen. Vi använde oss av Hanseth och Lyytinens (2010) fem designprinciper för att forma modellen. Multifrågan i kunskapsservicen fick vi inspiration från av Eriksson och Goldkuhls (2010) artikel Preconditions for public sector e-infrastructure development. Den slutgiltiga modellen presenteras i avsnitt 4.4. De designval vi tar upp i detta kapitel tar vi upp eftersom att vi anser att de behöver mer tydliggörande och de val vi gjort för dem har bestämts ur både
forskningförankrade guidelines och ur en praktisk synvinkel. Gränssnittet och Historiklagringen har bestämts ur ett praktisk perspektiv och Interoperabilitet ur ett forskningsperspektiv.
Gränssnittet
Vid utvecklingsprocessen av modellen så har det under våra samtal med Peter Hammar kommit fram att det ska vara helst ska vara så lite mänsklig kontakt som möjligt, men att det ändå ska vara möjligt för en människa att interagera med systemet och kunna redigera rapporter samt ställa in nivån av beskrivning och bestämma routingen för multifrågan. Det fick oss att tänka att det vore bäst med ett gemensamt gränssnitt som är kopplat till
Historiklagringen
Under designprocessen av modellen så var en av de svårare delarna med designen
placeringen av historiklagringen. Den utvecklades till en mycket viktigare entitet än vad vi hade föreställt oss när vi samlade in kraven. Vår initiala tanke var att den endast skulle agera som en databas för lagring av tidigare rapporter men efter en mer noggrann analys så visade det sig att den behövde uppfylla flera roller. I vår slutliga modell så är den ansluten till tre olika entiteter och efter flera diskussioner mellan oss så kom vi fram till att detta är det bästa sättet att designa den på, även om infrastrukturen inte blir så modulariserad som vi tänkt oss. Den fungerar som en databas där alla rapporter sparas, en databas som är sökbar genom rapportgränsnittet för att redigera andra rapporter och även en databas som ligger inom kunskapsbasen för skapandet av nya rapporter.
Interoperabilitet
Anledningen till att vi använder oss av adaptrar är för att varje databas inom kunskapsbasen kan använda sig av ett databasspecifikt språk. För att kunskapsservicen ska kunna
kommunicera med dessa databaser så finns det två alternativ, antingen så måste man skriva om alla databaser till ett och samma språk eller skapa adaptrar som översätter frågorna till de specifika språken. Vi valde den andra lösningen eftersom det sparas mycket tid och resurser genom att inte skriva om varje databas. Dessutom så kan man addera nya databaser på ett simpelt och modulariserat sätt genom att endast skriva en ny adapter för varje ny databas och konfigurera routingen i vår kunskapsservice som blir en typ av gateway för informationen. Vi valde även att placera adaptrar där information skickas in och ut från rapportgeneratorn eftersom rapporterna då kan skapas med ett standardiserat språk och informationen i sin tur skickas i form av standardiserade meddelanden i t.ex. XML som inte har några förutbestämda funktioner. Anledningen till att vi gör detta är för att vi inte vet om HLA standarden har stödet och funktionerna för att skapa rapporter och även att skicka multifrågor.
Med hjälp av adaptrar, gateways och våra standardiserade meddelanden så blev modellen och infrastrukturen mycket mer modulariserad och interoperabel eftersom modellen då följer de tre komponenter som finns i konceptet Interoperabilitet som presenterat av Eriksson och Goldkuhl (2010) i kapitel 3.1.
6.1.2 Implementering
En implementering av modellen blir nästa steg i projektet. Som hjälp för detta så finns det i uppsatsen och bilagor en kravsammanställning (Bilaga 3), ett “Use Case” (4.4.2) för ett exempelscenario och en begreppslista på objekten i databaserna (Bilaga 1) som ligger i kunskapsbasen som kompletterar modellen.
