(HS-IDA-EA-00-409)
Anders Johansson (a97andjo@student.his.se) Institutionen för datavetenskap
Högskolan i Skövde, Box 408 S-54128 Skövde, SWEDEN
Examensarbete på det dataekonomiska programmet under vårterminen 2000.
Examensrapport inlämnad av Anders Johansson till Högskolan i Skövde, för Kandidatexamen (B.Sc.) vid Institutionen för Datavetenskap.
2000-06-09
Härmed intygas att allt material i denna rapport, vilket inte är mitt eget, har blivit tydligt identifierat och att inget material är inkluderat som tidigare använts för erhållande av annan examen.
Anders Johansson (a97andjo@student.his.se)
Nyckelord: Systemutveckling, UML, datamodellering, processorienterade tekniker.
Sammanfattning
En central del i ett systemutvecklingsprojekt är de tekniker som används för att strukturera organisationer och informationen i dessa. I flera årtionden har traditionella tekniker utvecklats. Exempel på tekniker som anses traditionella är ER-modellering och dataflödesdiagram. Idag används objektorienterade programspråk mer och mer för att implementera databaser. Det har dock inte funnits stöd för att analysera ett system objektorienterat förrän i början på 1990-talet. De tekniker och metoder som utvecklades då hade flera olika inriktningar och begreppsförvirringen var stor. 1997 kom en standard för objektorienterad modellering i form av Unified Modeling Language (UML). I och med denna standard försökte man klargöra vilka begrepp som skulle gälla och vilken typ av notation som kunde användas. Arbetet försöker att visa vad som kan ersätta de traditionella teknikerna med objektorienterade metoder och tekniker. Koncentrationen har lagts på att analysera vilka tekniker som används i de två första faserna av livscykelmodellen, förändringsanalys och systemering. Resultatet blev att en fullständig ersättning för de traditionella teknikerna inte finns i UML i livscykelmodellens två första faser.
Innehållsförteckning
1
Bakgrund ...1
2
Introduktion ...3
2.1 Systemutveckling ... 3 2.2 Funktionsorienterat synsätt... 4 2.2.1 Dataflödesdiagram ... 4 2.3 Dataorienterat synsätt ... 6 2.3.1 Datamodellering... 6 2.4 Objektorienterat synsätt... 72.4.1 Objekt och klass ... 8
2.4.2 Objektorienterade relationer ... 9
2.5 Unified Modeling Language (UML) ... 10
2.6 Generella arbetssätt för systemutveckling... 11
2.7 Systemutvecklingens hjälpmedel ... 12 2.8 Livscykelmodell ... 14 2.8.1 Förändringsanalys ... 15 2.8.2 Systemering... 16 2.8.3 Realisering ... 17 2.8.4 Implementering ... 17
2.8.5 Förvaltning och drift ... 18
2.8.6 Avveckling... 18
3
Problembeskrivning ...19
3.1 Problemställning... 19 3.2 Avgränsning ... 20 3.3 Förväntat resultat ... 204
Metod ...21
4.1 Litteraturstudie ... 22 4.2 Fallstudie ... 23 4.3 Intervju ... 23 4.4 Val av metod ... 245
Genomförande ...26
5.1 Litteraturstudie ... 26 5.2 Fallstudie ... 275.3 Intervjuer ... 27
6
Materialredovisning ...28
6.1 Förändringsanalys ... 28 6.2 Verksamhetsanalys ... 28 6.2.1 Traditionellt arbetssätt ... 28 6.2.2 Objektorienterat arbetssätt ... 29 6.3 Informationsanalys ... 29 6.3.1 Traditionellt arbetssätt ... 29 6.3.2 Objektorienterat synsätt ... 31 6.4 Fallstudie ... 36 6.4.1 Förstudie ... 37 6.4.2 Konceptuell kartläggning... 39 6.4.3 Funktionell utformning ... 417
Analys ...43
7.1 Förändringsanalys ... 43 7.2 Verksamhetsanalys ... 43 7.3 Informationsanalys ... 438
Resultat och slutsats ...47
8.1 Traditionell utveckling ... 47 8.1.1 Förändringsanalys ... 47 8.1.2 Analysfas i systemering ... 47 8.2 Objektorienterad utveckling ... 48 8.2.1 Förändringsanalys ... 48 8.2.2 Analysfas av systemering ... 48 8.3 Slutsatser ... 48
8.4 Förslag till framtida arbete ... 49
9
Diskussion...50
9.1 Arbetsprocessen... 50 9.1.1 Val av metod ... 51 9.2 Systemutveckling ... 51 9.2.1 Utvecklingsmodeller ... 51 9.2.2 Traditionella tekniker... 52 9.2.3 Objektorienterat synsätt ... 52Referenser...58
Bilaga 1
1 Bakgrund
Enligt Mathiassen et al. (1998) är systemutveckling en process som handlar om att utveckla ett datasystem som blir ett effektivt redskap för användarna i deras arbetsuppgifter. Ett lyckat systemutvecklingsprojekt innebär därmed att på bästa möjliga sätt undersöka hur dagens arbetssituation ser ut, och vad det finns för behov hos användarna av det nya datasystemet (Mathiassen et al., 1998). Dagens arbetssituation och önskemålen ligger sedan till grund för ett informationssystem som gör att användarnas arbetssituation i det nya systemet förbättras i jämförelse med den nuvarande arbetssituationen.
Systemutveckling har funnits i flera årtionden och detta har gjort att det har blivit en gradvis utveckling av processen. I början på sextiotalet var ett av problemen att användarna och de som skulle utveckla informationssystemen inte kunde kommunicera på ett bra sätt så att de förstod varandra (Mathiassen et al., 1998). Detta kunde medföra att användarna fick ett system som de inte var tillfredsställda med, eller att systemet blev försenat och kostade mer pengar än budgeterat (Mathiassen et al., 1998). I slutet på sextiotalet gjordes försök att underlätta systemutvecklingen genom att utveckla olika modeller och metoder. Detta gjordes för att få systemutvecklingen tillförlitlig, så att projekt blev klara i tid och att de utförde vad de var förväntade att göra (Andersen, 1994). Det blev dessutom en utveckling på antalet deltagare som var engagerade i ett projekt ökade, för att ha möjlighet att tillfredsställa både användare och de som utvecklade systemen (Mathiassen et al., 1998).
Utvecklingen har fortsatt och idag har de flesta företag någon form av datasystem och databehandling i sin verksamhet. Det finns olika typer av system att köpa på marknaden som till exempel standardsystem och expertsystem. Ett standardsystem har en mängd fördefinierade funktioner inlagda och de är lika för alla som köper systemet (Andersen, 1994). Denna typ av system har utvecklats för att passa många olika typer av verksamheter, som till exempel ett system för tillverkande industrier (Andersen, 1994). Ett expertsystem är ett informationssystem som är framtaget för att agera som en expert och kunna göra utlåtanden för den specifika domänen som den är anpassad för, som till exempel ett system som läkare kan använda för att ställa diagnos (Avison & Fitzgerald, 1995).
Utvecklingen har också fortsatt i form av att det har utvecklats flera olika typer av synsätt på hur man ska utveckla ett informationssystem (Andersen, 1994). Mathiassen et al. (1998) skriver att ett av de första synsätten var funktionsorienterat. Detta innebar att systemet byggdes upp kring de olika funktioner som ett företag har i sin verksamhet. Ett av de senaste synsätten som har utvecklats är objektorienterat synsätt på systemutvecklingen (Mathiassen et al., 1998). Det innebär att utvecklingen av systemet koncentreras kring de olika objekten i företaget, som till exempel personer, bilar och leksaker. Mer om de olika synsätten tas upp i kapitel 2.
Det förekommer att flera företag idag arbetar med flera olika synsätt som gör att det blir en stor variation på hur ett systemutvecklingsprojekt kan utföras. De vanligaste synsätten som används är de så kallade traditionella angreppssätten, som till exempel
funktionsorienterat synsätt (Mathiassen et al. 1998). Ett av de företag som arbetar med systemutveckling på ett traditionellt vis är IBS Konsult AB. Objektorienterad systemutveckling är ett av de senaste synsätten att arbeta med systemutveckling. Detta synsätt är intressant för företag, men de arbetar i de allra flesta fall fortfarande med de traditionella synsätten för att de är beprövade och fungerar. Uppsatsen har som syfte att undersöka huruvida det går att anpassa traditionell systemutveckling till objektorienterad systemutveckling.
2 Introduktion
Detta kapitel har för avsikt att ge en introduktion till ämnet systemutveckling. I kapitlet kommer systemutvecklingens historia att beskrivas och dessutom kommer centrala begrepp för systemutveckling att förklaras.
2.1 Systemutveckling
Systemutveckling är enligt Andersen (1998) en utveckling av informationssystem där systemet behandlar information. Andersen anser också att det finns vissa karakteristiska egenskaper hos ett informationssystem. Egenskaperna är enligt Andersen:
• att systemet är en mänsklig konstruktion
• att systemet är knutet till en viss arbetsuppgift
• att systemet förmedlar information
• att systemet tar emot information
• att systemet behandlar information
• att behandlingen kan vara både manuell och maskinell
Enligt Mathiassen et al. (1998) är systemutveckling en process för att utveckla ett informationssystem som underlättar användarnas arbetsuppgifter och behandling av information. Mathiassen et al. skriver att systemet ska bli ett användbart redskap för användarna i deras dagliga arbetsuppgifter, som till exempel ett boklånesystem på biblioteket eller ett biljettbokningssystem för flygresor.
Ur historiskt perspektiv har systemutveckling existerat sedan i mitten på femtiotalet. Under femtiotalet och fram till slutet på sextiotalet fanns det ingen accepterad metod vilket gjorde att många system som producerades blev svåra att hantera för användarna (Avison & Fitzgerald, 1995). Svårigheten låg i att det inte fanns tillräckligt med dokumentation och riktlinjer om hur systemet fungerade, till exempel hur rapporter och dokument skulle produceras (Avison & Fitzgerald, 1995). Enligt Avison och Fitzgerald hade systemutveckling inte blivit tillräckligt förfinad utan att systemen som producerades var framtagna av programmerare och användare. Enligt författarna såg framtagningsprocessen för ett system såg oftast ut enligt följande:
Användare Programmerare Dator
Ett av problemen enligt Avison och Fitzgerald (1995) var att kommunikationen mellan användare och programmerare inte fungerade. Avison och Fitzgerald skriver att ett av de största problemen i kommunikationen var att programmerarna inte förstod användarnas krav och användarna inte hade programmerarnas expertkunskap. I och
beräknat. Utvecklingen fortsatte och fler personer blev involverade i systemutvecklingen vilket gjorde att kommunikationen förbättrades. Avison och Fitzgerald (1995) beskriver processen på följande sätt:
Användare Systemutvecklare Programmerare Förvaltare
Här syns en tydlig förändring mot föregående utvecklingsprocess. Här visar Avison och Fitzgerald (1995) att kommunikationen mellan användare och programmerare har försvunnit. Istället har en systemutvecklare som har erfarenhet av att kommunicera med användare tagits till hjälp för att översätta användarnas krav på systemet till programmerarna. Detta utvecklades till att i de flesta fall blev användarna tillfredsställda med hur systemen fungerade och även att programmerarna fick en kravspecifikation som gjorde att de kunde konstruera bästa möjliga system (Avison & Fitzgerald, 1995).
Efter hand som kommunikationen mellan användare och systemutvecklare hade förbättrats kom det ytterligare hjälpmedel för utveckling av system. National Computing Centre (NCC) i Storbritannien publicerade i slutet av sextiotalet en modell som vanligtvis kallas för livscykelmodellen, vilken tas upp i kapitel 2.8 (Fagerström, 1999). Den antogs av många företag under sjuttiotalet och blev även kallad vattenfallsmodellen (Avison & Fitzgerald, 1995). Genom systemutvecklingens historia har det utvecklats olika synsätt på hur den ska bedrivas. En närmare beskrivning av de olika synsätten ges nedan.
2.2 Funktionsorienterat synsätt
Ett av de första synsätten som utvecklades var funktionsorienterat (Andersen, 1994). Detta angreppssätt var fokuserat på att identifiera funktioner, det vill säga arbetet i systemutvecklingen var uppbyggt kring att lokalisera de olika arbetsuppgifterna i ett företag (Mathiassen et al., 1998). Sedan undersöktes vilka typer av tekniska lösningar som skulle kunna vara aktuella för att få ett effektivt datasystem (Mathiassen et al., 1998). Mathiassen et al. skriver också att synsättet inte intresserar sig för till exempel anställda i sig i ett företag, utan koncentrerar sig på data de ger upphov till, och den behandling av dessa data de anställda utför.
2.2.1 Dataflödesdiagram
Tekniker enligt denna princip är en instans av funktionsorienterat tankesätt. En av de tekniker som används med avseende på processer är dataflödesdiagram, andra är till exempel funktionell nedbrytning och strukturerat språk (Avison & Fitzgerald, 1995). Ett gemensamt drag för dessa tekniker är att de försöker hitta centrala processer för att sedan bryta ned dessa i delprocesser.
Avison och Fitzgerald (1995) skriver att dataflödesdiagram inte ska utnyttjas som den mest betydande beskrivningstekniken i en systemutvecklingsprocess, utan ska helst användas tillsammans med en annan beskrivningsteknik som till exempel
datamodellering (se kapitel 2.3.1). De två nämnda teknikerna kompletterar varandra men var för sig är det inte möjligt att utveckla ett fullständigt system som tillfredsställer användarna (Avison & Fitzgerald, 1995). Dataflödesdiagram beskriver företagets verksamhet och tar fram kraven för det nya datasystemet och datamodellering strukturerar upp informationen i datasystemet vilket gör att dessa två tekniker kompletterar varandra (Avison & Fitzgerald, 1995). Dataflödesdiagram är ett grafiskt hjälpmedel vilket och kan användas som dokumentation och dessutom som hjälpmedel för att främja kommunikationen mellan till exempel användare och systemerare (Avison & Fitzgerald, 1995). Ett dataflöde kan beskrivas som en kanal där det flödar en mängd information med ett innehåll som vi har kunskap om (Andersen, 1994). Författaren skriver också att en process gör sedan om denna inkommande information till utgående information och samtidigt som detta sker sparas informationen ned på en fil. Denna beskrivning redogör i stort sett för vad som är nödvändigt i form av notation för ett dataflödesdiagram.
I dataflödesdiagram finns det två notationer som har blivit erkända, DeMarco samt Gane och Sarson (Andersen, 1994). Grundtanken i de båda teknikerna är densamma, men det är hur notationen ska uttryckas grafiskt som skiljer sig. Notationen för de båda författarna visas i figur 1.
DeMarco Gane & Sarson
Datakälla/ Bestämmelseort
Process
Dataflöde
Fil, Dataförvaring
Figur 1: Notation för dataflödesdiagram
I fortsättningen kommer DeMarcos notation vara den som används för att visa hur ett dataflödesdiagram kommer att se ut. Ett exempel på ett dataflödesdiagram kan vara bokningssystem (se figur 2).
Bokningsinfo Bokning
Bokningssystem
Bekräftelse
Figur 2: Exempel på dataflödesdiagram
Figur 2 beskriver hur en kund skickar ett dataflöde i form av bokningsinfo. Informationen omvandlas i en process till en bokning och bokningen registreras sedan i ett bokningssystem. När bokningen är registrerad skickas sedan en bekräftelse till kund.
2.3 Dataorienterat
synsätt
Mathiassen et al. (1998) skriver att utvecklingen ledde till att ett dataorienterat synsätt skapades och blev en komplettering till funktionsorienterat angreppssätt, detta för att de som utvecklade systemen behövde ett sätt att strukturera informationen och inte bara verksamheten. Enligt Andersen (1994) är det i detta synsätt intressant att hålla reda på förhållandena inom och utanför företaget och detta görs med hjälp av modellering, det vill säga man försöker avbilda verksamheten med hjälp av en modell som byggs upp av entiteter och relationer. Idén med att beskriva en verksamhet med dataorienterat synsätt är att försöka beskriva hur informationsbehovet ska täckas idag och i framtiden, samt att informationssystemet ska ge information om de entiteter som finns i och utanför verksamheten (Andersen, 1994). Ett bra exempel på ett dataorienterat synsätt är datamodellering i form av en Entitet-Relationsmodell (Avison & Fitzgerald, 1995).
2.3.1 Datamodellering
En datamodell kan beskrivas som en modell av data, vilken kan beskriva flera olika saker som till exempel en databas, information eller verkligheten (Sundgren, 1992). Enligt Sundgren finns det flera olika skäl till varför modellering kan användas, som till exempel att datamodellen ska underlätta kommunikationen mellan databaskonstruktörer och användare eller att modellen ska underlätta omorganisation och underhåll av databasen. 1976 kom ett genombrott i modelleringen då ”The Entity-Relationship Model” presenterades för första gången (Andersen, 1994). Entitets-Relationsmodellen skapades av P. Chen och han gjorde med denna modell ett försök att få ett gemensamt synsätt på hur modellering skulle genomföras (Chen, 1976). Entitets-Relationsmodellen (ER-modell) beskriver hur en konceptuell modell kan skapas och dessutom skapade den en enighet om hur modellering skulle bedrivas (Andersen, 1994). En ER-modell ger företagsledningen en uppfattning om hur deras verksamhet är uppbyggd och dessutom kan den ge en möjlighet att lösa verkliga problem som är svåra att hitta en lösning till (Avison & Fitzgerald, 1995).
De begrepp som används i ER-modellering är entitet, attribut och relation. Notationen är tagen från Andersen (1994) och Avison och Fitzgerald (1995). Relationer kan representeras på flera olika sätt beroende på vilken typ av relation det är. De olika begreppen representeras grafiskt och notationen kan ses i figur 3.
1-1 relation, en till en relation 1-M relation, en till många relation M-N relation, många till många relation
Figur 3: Entitet, attribut och relationer
En entitet kan vara till exempel en person eller en bil och mellan en person och en bil är relationen att bilen ägs av en person och personen äger en bil (se figur 4). En person kan äga flera bilar och en bil kan bara ha en ägare. Attributen beskriver och identifierar ägaren med namn och personnummer. Bilen beskrivs av färg och registreringsnummer. Genom att registrera information om respektive entitet, det vill säga lagra informationen som data får man ett dataorienterat synsätt (Andersen, 1994).
Äger/ägs av
Figur 4: Exempel på ER-modell
2.4 Objektorienterat
synsätt
Ett av de senaste synsätten på systemutveckling kallas objektorientering. Detta synsätt är en utveckling av dataorienterat synsätt (Mathiassen et al., 1998). Objektorienterad systemutveckling kännetecknas av att den är iterativ och en kombination av top-down och bottom-up tänkande (Fagerström, 1992). Den iterativa processen kännetecknas av att samma aktiviteter utförs gång på gång på olika detaljnivå och inom olika delar av
Entitet Attribut Person Bil Namn Regnr Färg Pnr
en verksamhet (Fagerström, 1992). Top-down och bottom-up tänkandet presenteras mer utförligt i kapitel 2.6.
2.4.1 Objekt och klass
Det objektorienterade synsättet har som utgångspunkt objekt som samarbetar med varandra. Ett objekt kan till exempel vara en person eller ett flygplan. Enligt den nya standarden för objektorienterad modellering (Unified Modeling Language, UML) så beskrivs ett objekt på följande sätt:
”An object is an item we can talk about and manipulate. An object exists
in the real world (or more precisely, our understanding of the real world).” (Eriksson & Penker, 1998, sid 65)
Ett objekt behöver alltså inte bara vara konkreta ting i omgivningen utan det kan också vara abstrakta ting. Ett exempel på ett abstrakt objekt kan vara en speciell klass som aldrig får en instans av något objekt, som till exempel en klass fordon kan delas in i bil och MC. Detta medför att alla objekt instansieras till bil eller MC och inte fordon. I Mathiassen et al. (1998) - som är skriven med UML som grund för deras systemutvecklingsmetod - kan man hitta följande definition av ett objekt:
”Objekt: en helhet med identitet, tillstånd och beteende.”
(Mathiassen et al., 1998, sid19)
I denna definition finns beteende med. Detta utgör en väsentlig skillnad mot entitet (se delkapitel 2.3.1) som är en statisk enhet som bara kan lagra information, medan däremot ett objekt kan dessutom ta emot meddelande och efter en viss tid exekvera kod (Fagerström, 1999). Ett objekt har ett eller flera attribut kopplade till sig. Attribut innehåller information om objekt som till exempel vilken färg det har, och detta medför att i attributen finns det möjlighet att representera vilket tillstånd ett objekt har (Fagerström, 1999).
I ett systemutvecklingsprojekt kan flera olika objekt tänka sig att det förekomma. När detta händer försöker man hitta de objekt som har ett gemensamt mönster och ett gemensamt beteende (Fagerström, 1999). När egenskaperna mellan objekt förefaller att vara gemensamma beskrivs detta som en klass, det vill säga en samling av objekt med liknande egenskaper. Mathiassen et al. (1998) beskriver en klass på följande sätt:
”Klass: en beskrivning av en mängd objekt med samma struktur, beteendemönster och attribut.” (Mathiassen et al., 1998, sid 19)
Klasser och objekt är grundstenarna i objektorienterad modellering och för att beskriva hur klasser är kopplade till varandra används relationer (Mathiassen et
al., 1998). En närmare beskrivning av några olika typer av relationer som kan förbinda de olika klasserna presenteras nedan.
2.4.2 Objektorienterade relationer
Objektorienterad modellering använder sig av flera olika typer av relationer som till exempel arv, association, aggregat (Fagerström, 1999). Arv är en av de viktigaste relationerna i objektorientering och arv sker mellan olika klasser. I denna typ av relation förutsätts det att de involverade klasserna är över- och underordnade (Mathiassen et al., 1998). Ett arv från en klass till en annan medför att attribut och metoder ärvs med samma utseende som den klass den ärver ifrån (Fagerström, 1999). Klasserna modelleras som över- och underordnade vilket medför att arv kan bara ske från en överordnad till en underordnad klass (Mathiassen et al., 1998). Ett annat ord för arv är generalisering och denna relation kan definieras enligt följande:
”Generalisering: en struktur i vilken en generell klass (superklassen)
beskriver egenskaper och beteendemönster som är gemensamma för ett antal speciella klasser (subklasserna) och går i arv till dessa.”
(Mathiassen et al., 1998, sid 97)
I en relation som association kan ett eller flera objekt vara inblandade. De inblandade objekten förutsätts här att vara sidordnade (Mathiassen et al., 1998). Detta innebär att det inte finns någon hierarki som i arvsrelationen, utan klasserna är likvärdiga (Mathiassen et al., 1998). Ett vanligt sätt att beskriva relationen är att objekten ”känner till” varandra (Mathiassen et al., 1998).
”En association är en strukturell, permanent, dubbelriktad koppling mellan objekt (dvs objekten kommer ihåg kopplingen mellan metodanrop).” (Fagerström, 1999, sid. 39)
Aggregat kan bestå av två eller flera objekt och på liknande sätt som arv finns här över- och underordnade objekt (Mathiassen et al., 1998). Relationen kan beskrivas med att ett underordnat objekt ”ingår-i”, eller att ett överordnat objekt ”består-av” (Mathiassen et al., 1998).
”Ett aggregat är en association mellan ett objekt (en helhet) och ett antal andra objekt (delar). Delobjektens livslängd beror på helhetens livslängd, om helheten tas bort måste även delobjekten tas bort.”
(Fagerström, 1999, sid 41)
De relationer som har presenterats ovan är de tre mest fundamentala relationerna för objektorienterat synsätt. Med hjälp av klasser och relationerna mellan dessa finns det möjlighet att modellera ett företags informationsstruktur.
2.5 Unified Modeling Language (UML)
I början av 1990-talet existerade det många olika inriktningar på hur man skulle bedriva en objektorienterad systemutveckling (Rational University, Rational Software Corporation, 1 Mars 2000). I början av nittiotalet utkristalliserades tre huvudinriktningar (Rational University, Rational Software Corporation, 1 Mars 2000). En av inriktningarna stod Dr. Ivar Jacobsen bakom, och han är en av dem som har arbetat med objektorienterad systemutveckling en längre tid (Rational University, Rational Software Corporation, 1 Mars 2000). Han startade företaget Objectory som utvecklade en produkt (Objectory) som stöd för objektorienterad systemutveckling.
En annan inriktning stod Grady Booch bakom. Han utvecklade Booch-metoden vilken understödjer objektorienterad systemutveckling från analys till design (Rational University, Rational Software Corporation, 1 Mars 2000). Denna metod tog tillvara på de fördelar som finns med objektorientering, som till exempel återanvändning och gjorde det ekonomiskt försvarbart att börja arbeta på detta sätt (Rational University, Rational Software Corporation, 1 Mars 2000).
Den sista av de tre huvudinriktningarna skapades av Dr. James Rumbaugh. Han var huvudansvarig för utvecklingen av en utvecklingsmodell som heter Object Modeling Technique (OMT) (Rational University, Rational Software Corporation, 1 Mars 2000). Dr. Rumbaugh har utvecklat flera verktyg i OMT för att underlätta användandet av denna utvecklingsmodell, och han har dessutom försöka att hitta fler verktyg och metoder för att underlätta objektorienterad systemutveckling (Rational University, Rational Software Corporation, 1 Mars 2000).
I mitten på nittiotalet blev det plötsligt en förändring. De tre huvudinriktningarnas skapare gick samman och började samarbeta i Rational Software Corporation vilket ledde till att Unified Modeling Language (UML) skapades. UML blev antagen som standard (1997) för objektorienterat modelleringsspråk av Object Management Group (OMG) som är standardorganet för objektorientering (Rational University, Rational Software Corporation, 1 Mars 2000). Denna standard accepterades direkt av erkända företag som IBM och Microsoft (Rational University, Rational Software Corporation, 1 Mars 2000).
Unified Modeling Language (UML) är en omfattande standard, i form av olika diagram, vilket gör det svårt att applicera hela standarden på ett systemutvecklingsprojekt (Fagerström, 1999). Fagerström skriver att istället får vissa delar väljas som anses vara relevanta i det systemutvecklingsprojekt som man arbetar med. UML omfattar grundläggande begrepp och notation som tidigare hade varit definierade på olika sätt i olika metoder (Fagerström, 1999). I och med UML har definitioner blivit gemensamma för hela det objektorienterade synsättet (Mathiassen et al., 1998).
Målet med UML är bland annat att underlätta för de företag som framställer mjukvara (Rational Software Corporation, 1999). Genom att modellera i UML fås en ritning över hur ett program ska se ut och att det har en korrekt struktur (Rational Software
Corporation, 1999). Modelleringen ger också en möjlighet att automatisera processen med framtagande av mjukvara genom att UML innehåller möjligheten att arbeta med samma typ av modellering oberoende av plattform och programspråk (Rational Software Corporation, 1999). UML består av olika komponenter som till exempel olika typer av diagram vilka gör det möjligt att visualisera ett komplext system (Rational Software Corporation, 1999).
Unified Modeling Language har möjlighet att beskriva ett system statiskt och dynamiskt (Rational Software Corporation, 1999). Den statiska beskrivningen sker genom att använda sig av klassdiagram (Rational Software Corporation, 1999). Diagrammet beskriver vilka objekt som ska existera i ett system och vilka detaljer dessa ska ha (Rational Software Corporation, 1999). Den dynamiska beskrivningen sker genom att använda sig av tillståndsdiagram och interaktionsdiagram (Rational Software Corporation, 1999). Ett interaktionsdiagram kan till exempel vara ett sekvensdiagram eller ett samspelsdiagram (Rational Software Corporation, 1999). Interaktionsdiagram har som uppgift att visa hur olika objekt interagerar med varandra (Rational Software Corporation, 1999). Den dynamiska modelleringen beskrivs närmare i kapitel 9.2.3.
2.6 Generella arbetssätt för systemutveckling
Det finns flera olika sätt att angripa ett projekt i systemutveckling. Ett av de synsätt som används i de flesta utvecklingsprocesser kallas top-down (Fagerström, 1999). Detta angreppssätt börjar med att man definierar ett överordnat problem för att sedan bryta ner detta till delproblem som i sin tur bryts ner i delproblem osv. Fagerström (1999) skriver också att en av de positiva effekterna med detta synsätt är att man får en överblick över systemet men en av svagheterna som är väsentlig för objektorienterad systemutveckling är att återanvändning av komponenter försvåras. Återanvändningen försvåras ju längre arbetet fortsätter för att de komponenter som ska användas igen är svåra att hela tiden hålla tillgängliga i systemutvecklingen (Fagerström, 1999). Figur 5 visar hur en top-down metod kan fungera. Det börjar med att man hittar ett centralt problem för att sedan bryta ned detta i delproblem, och så fortsätter det tills problemen har blivit tillräckligt små för att kunna hanteras i systemutvecklingsprojektet. Ett exempel på en typisk top-down metod är till exempel funktionell nedbrytning där man hittar en central funktion och bryter ner den i delfunktioner (Fagerström, 1999).
Ett annat synsätt för att angripa en utvecklingsprocess är att använda sig av bottom-up metoder. I detta synsätt använder man sig av omvänd teknik från top-down, det vill säga man angriper problemet genom att hitta enskilda komponenter för att sedan bygga ihop dessa till ett färdigt system (Fagerström, 1999). Fagerström skriver också att en av styrkorna i detta synsätt är att återanvändning är mycket förenklad, men när systemet utvecklas är det svårt att få en helhetsbild. Ett exempel på denna typ av angreppssätt är objektorientering.
Top-Down Bottom-Up
Figur 5: Arbetssätt för systemutveckling
Figur 5 beskriver hur top-down respektive bottom-up metoder fungerar. Som beskrivet ovan finns det rena top-down eller bottom-up metoder. En möjlighet är att kombinera dessa två metoder för att erhålla en bra systemöversikt och dessutom göra det lättare att återanvända komponenter i systemet (Mathiassen et al., 1998). Objektorienterat synsätt är exempel på ett kombinerat arbetssätt (Mathiassen et al., 1998). Objektorienterat angreppssätt kan således presenteras som antingen en kombinerad eller bottom-up metod.
2.7 Systemutvecklingens
hjälpmedel
I ett systemutvecklingsprojekt finns det i många fall flera olika hjälpmedel som används. Hjälpmedel som innefattar hela systemutvecklingen är modell, metod, teknik och verktyg (Andersen, 1994). Begreppen återfinns idag i många företag, däribland IBS Konsult AB.
Figur 6: Systemutvecklingens hjälpmedel Modell
Metod Teknik
I figur 6 beskrivs hur systemutvecklingens olika hjälpmedel är sammanbundna. En modell är ett ramverk för hur systemutvecklingen ska gå till (Andersen, 1994). Författaren skriver att metoden har en mer detaljerad beskrivning om hur man ska gå till väga. Teknikerna är hjälpmedel för att kunna realisera metodens teorier (Andersen, 1994). Verktygen är till för att praktiskt kunna förverkliga de olika teknikerna (Andersen, 1994).
Ett medel för att få en framgångsrik systemutveckling kan vara att ha metoder att applicera på en genomarbetad modell (Mathiassen et al., 1998). Modeller beskriver i stora drag vem som ska utföra ett arbete och även vilket arbete som ska utföras (Andersen, 1994). I en modell finns det begrepp som till exempel faser, metodsteg, problemområden och alla dessa uttryck är olika benämningar för de delar som en modell kan innehålla (Andersen, 1994). Han skriver att en modell kan ses som ett ramverk för ett systemutvecklingsprojekt. En av de modeller som är och har varit betydelsefull för systemutvecklingen är livscykelmodellen (Avison & Fitzgerald, 1995). Modeller för systemutveckling har utvecklats men de flesta av dessa har grundkoncepten från livscykelmodellen kvar i sin modell, vilket gör att den finns på ett eller annat sätt närvarande i många olika systemutvecklingsmodeller (Lewis, 1994). Livscykelmodellen beskriver hur ett projekt för systemutveckling kan fortlöpa och hur ett systems ”liv” kan se ut (Andersen, 1994). Den beskriver dessutom hur arbetsuppgifterna är fördelade och vem som ska deltaga i de olika faserna för modellen (Andersen, 1994). Den beskrivs närmare i delkapitel 2.8.
En metod är en detaljerad beskrivning för hur det är möjligt att lösa ett visst problem (Andersen, 1994). Det finns idag en mängd olika metoder och dessa är inriktade på hur man ska lösa en specifik problemtyp (Andersen, 1994). Han skriver också att den största skillnaden mellan en modell och en metod är att metoder är mer detaljerade och inte så generella som en modell. De inriktningar som har utvecklats finns representerade av olika metoder som har arbetats fram, som till exempel Ethics, ISAC, STRADIS. Ethics (Effective Technical and Human Implementation of Computer-Based Systems) skapades av E. Mumford 1995 och är en människoorienterad utvecklingsmetod där användarna ska vara i centrum (Avison & Fitzgerald, 1995). För att denna metod ska fungera är det viktigt att informationssystemet utvecklas i nära samband med ett företags organisation och systemets användare (Avison & Fitzgerald, 1995). ISAC skapades av en forskningsgrupp vid Kungliga Tekniska Högskolan och Stockholms Universitet 1971 (Avison & Fitzgerald, 1995). ISAC är en förkortning som betyder Information Systems Work and Analysis of Changes (Avison & Fitzgerald, 1995). I metoden ligger tyngdpunkten på att försöka hitta användarnas problem och föreslå olika angreppssätt för att lösa problemen (Avison & Fitzgerald, 1995). STRADIS (Structured Systems Analysis) skapades av Gane och Sarson 1979 och har som viktigaste del att arbeta med funktionell nedbrytning i form av dataflödesdiagram (Avison & Fitzgerald, 1995). Enligt Andersen (1994) kan man karakterisera en metod enligt följande:
• Vilken typ av problem som metoden ska appliceras på
• Vad det är för beskrivningstekniker som ska användas, samt hur dessa ska användas
I en metod kan det finnas en eller flera beskrivningstekniker och teknikerna har för det mesta tydliga regler för hur symboler och text får användas (Andersen, 1994). Enligt Andersen finns det olika krav man kan ställa på en teknik som till exempel hur lätt det är att lära sig tekniken eller hur lätt det är att ändra och reproducera tekniken. Han säger också att en teknik ska vara möjlig att applicera på flera olika typer av verksamheter och dessutom vara lättläst. Tekniken bör ge medarbetarna en bra bild av verksamheten de försöker utforma ett system för (Andersen, 1994). Det har utvecklats många olika tekniker som till exempel rika bilder, entitetsmodellering, (Avison & Fitzgerald, 1995). Rika bilder ger en överblick av organisationen på ett sådant sätt att den fungerar som en karikatyr av verksamheten (Avison & Fitzgerald, 1995). Entitetsmodellering däremot är till för att analysera data i verksamheten och är oftast kopplade till dataorienterade metoder (Avison & Fitzgerald, 1995). Ett annat ord för denna typ av modellering är datamodellering. De tekniker som är beskrivna ovan är grafiska, vilka ger fördelen att det är lättare att få en överblick av vad man håller på med, samt att medarbetare får det lättare att sätta sig in problemet (Andersen, 1994).
En nackdel med dessa tekniker är att när ett system blir stort och komplext försvinner överskådligheten (Andersen, 1994).
Modeller, metoder och tekniker har många regler för hur man ska gå till väga men för att kunna presentera något konkret behövs ett verktyg (Andersen, 1994). I dagens systemutveckling finns det metoder som förutsätter att utvecklarna har tillgång till vissa datorstödda verktyg vilka går under benämningen CASE verktyg (Computer Aided Systems Engineering) (Avison & Fitzgerald, 1995). Det finns flera fördelar med CASE verktyg som till exempel att det underlättar beskrivningsarbetet, beskrivningarna blir mer strukturerade och att det underlättar möjligheten att angripa mer omfattande problem (Andersen, 1994). Nackdelen med CASE verktyg är att de kan vara dyra att köpa in (Andersen, 1994).
2.8 Livscykelmodell
Enligt Andersen (1994) är livscykelmodellen ett exempel på hur informationssystems ”liv” kan följas, det vill säga den följer hur systemet går igenom de olika faserna som finns för att utveckla ett system tills det att systemet inte längre är tillräckligt för att kunna hantera informationen i verksamheten och avvecklas. Fördelar med denna modell är att det finns möjlighet för kunden att följa hur arbetet utvecklas och att det håller tidsplanen (Avison & Fitzgerald, 1995). En nackdel med livscykelmodellen är till exempel att modellen inte är flexibel, det vill säga att när en fas officiellt är avslutad är det svårt eller omöjligt att gå tillbaka och förändra i föregående fas (Avison & Fitzgerald, 1995). Enligt Andersen (1994) och Avison och Fitzgerald (1995) består livscykelmodellen av följande delar som beskrivs i figur 7.
Figur 7: Livscykelmodellen
I livscykelmodellen finns det klara skillnader mellan systemutveckling och systemering (Andersen, 1994). Många användare och systemutvecklare använder dessa två ord som synonymer men enligt livscykelmodellen så är det skillnad mellan dessa uttryck (Andersen, 1994). Systemutveckling innefattar systemering, realisering och implementering och som kan ses i figur 8 (Andersen,1994). Systemering beskrivs närmare i delkapitel 2.8.2.
Figur 8: Systemutvecklingens komponenter
För att kunna få en större förståelse för vad som utförs i de olika delarna i livscykelmodellen följer en mer detaljerad beskrivning av de enskilda faserna.
2.8.1 Förändringsanalys
I denna första fas undersöks det nuvarande systemet, vilka krav det systemet hade på sig när det utvecklades, vilka problem det var att tillmötesgå kraven och vilka nya krav som har tillkommit (Avison & Fitzgerald, 1995). När de nya kraven kommer fram måste det undersökas att de inte bryter mot någon policy inom företaget, att de skulle fungera i organisationen och socialt hos användarna samt att kraven ska vara ekonomiskt försvarbara och tekniskt genomförbara (Avison & Fitzgerald, 1995).
Det är två saker som står i centrum i denna fas, verksamhetens problem och möjligheter (Andersen, 1994). Andersen säger att de olika arbetsuppgifterna är att beskriva nuläget, önskad situation och förändringsbehov. Här är det fördelaktigt med
Förändrings-analys Systemering Realisering
Implemen-tering Förvaltning/ drift Avveckling Systemering Systemutveckling Implementering Realisering
kunskap om nuläget och önskemålen som finns för förbättringar (Andersen, 1994). Experterna har kunskap om hur man skall strukturera informationen som kommer in på ett sätt så att de inblandande får en översikt ( Andersen, 1994).
Förändringsbehov kan vara en utveckling av systemet eller framtagning av en ny organisation. Andersen (1994) understryker hur viktigt det är för experterna att vara uppmärksamma och skilja mellan systemkrav och organisationskrav. Vidare skriver Andersen (1994) att i förändringsanalysen kan det uppkomma krav och problem som ett nytt system inte kan lösa, utan att det behövs en organisationsförändring. PSO-utveckling, vilket står för person-, system- och organisationsPSO-utveckling, blir följden av att systemutvecklarna uppmärksammar att det måste ske en utveckling av organisationen och personerna i verksamheten samtidigt som en systemutveckling sker (Andersen, 1994). En PSO-utveckling ger en grund för att användarna får en större nytta av systemet, det vill säga systemet gör att användarnas arbetsuppgifter underlättas och inte blir så komplexa (Andersen, 1994). När förändringsanalysen avslutas har man kommit till en beslutspunkt (Avison & Fitzgerald, 1995). Beslutet som fattas ska bestämma om ett nytt system ska utvecklas eller ej (Avison & Fitzgerald, 1995). Om ett nytt system ska införas, tar nästa fas vid, nämligen systemeringen.
2.8.2 Systemering
Denna fas i modellen består av två delar, analys och utformning. Denna uppdelning beskrivs i figur 9.
Figur 9: Systemeringens två faser
I figur 9 visas det hur analysen kan delas upp i verksamhetsanalys och informationsanalys (Andersen, 1994). I verksamhetsanalysen utreds vilket stöd som det nya systemet ska ge verksamheten (Andersen, 1994). Författaren skriver att här analyseras hur systemet ska göra det lättare för medarbetarna att utföra sina uppgifter. I denna fas är det viktigt att både systemerare och representanter för användarna finns närvarande (Andersen, 1994). Verksamhetsanalysen kan beskrivas med grafiska tekniker som dataflödesdiagram för att få en överblick över organisationen (Avison & Fitzgerald, 1995) I informationsanalysen identifieras vilken data som
Systemering Analys Verksamhets-analys Informations-analys Utformning Principiellt val Konkret val
informationssystemet ska innehålla och det görs genom ett samarbete mellan användare och systemerare (Andersen, 1994). Denna analys kan göras med olika typer av diagram som till exempel ER-modellen som visar hur informationen ska vara strukturerad i verksamheten (Avison & Fitzgerald, 1995).
Analysen är den viktigaste delen av hela systemutvecklingsprojektet och resultatet från denna fas i systemeringen är kravspecifikationen (Andersen, 1994). Kravspecifikationen är ett dokument som ska klargöra vilka behov och krav som ställs av företaget på det nya systemet (Andersen, 1994). Om analysen blir undermålig är det svårt att lyckas med ett systemutvecklingsprojekt, för att det som inte kommer fram under analysen kommer heller inte med i kravspecifikationen som ligger till grund för det nya systemet (Andersen, 1994).
Nästa fas i systemeringen är utformning av systemet. Grunden till utformningen är kravspecifikationen. Utformningen består av två delar, principiellt val och konkret val av teknisk lösning (Andersen, 1994). När den principiella tekniska lösningen ska väljas är det viktigt att välja den mest ändamålsenliga lösningen för att bästa möjliga resultat uppnås (Andersen, 1994). När det gäller att göra det konkreta valet är det viktigt att se över sin arsenal av verktyg och se om något passar eller så får man införskaffa ett verktyg som passar (Andersen, 1994). I utformningen av systemet är det systemerare och programmerare som samarbetar (Andersen, 1994). Enligt Avison och Fitzgerald (1995) är det också viktigt att se på de problem som det gamla systemet hade och varför de uppstod.
2.8.3 Realisering
I realiseringen ska det nya informationssystemet utarbetas och systemet skapas med hjälp av programmerare som skapar ADB program (Automatisk Data Behandling) (Andersen, 1994). Det är viktigt att programmerarna dessutom beskriver hur deras tekniska lösning ser ut i någon form av dokumentation, för att det ska vara möjligt att se hur systemet är strukturerat (Andersen, 1994). Här är det också viktigt att försöka vara systematisk i programmeringen så att rätt delprogram görs vid rätt tidpunkt för att realiseringen ska förlöpa på ett så problemfritt sätt som möjligt (Avison & Fitzgerald, 1995).
2.8.4 Implementering
I denna fas startas hela det nya systemet. Här är det viktigt att användare, systemerare och programmerare samarbetar, för om det blir några problem så finns det möjlighet att analysera dem från olika synvinklar (Andersen, 1994). I och med att det är ett nytt system blir det också nya rutiner som användarna ska lära sig och de får lära sig rutinerna genom utbildning och anvisningar från systemerare/systemutvecklare (Andersen, 1994). I och med denna fas så tar systemutvecklingen slut. En viktig del i denna fas är kvalitetskontroll (Avison & Fitzgerald, 1995). Kontrollen ska vara så noggrann att både programmerare, systemutvecklare och användare är nöjda (Avison & Fitzgerald, 1995).
2.8.5 Förvaltning och drift
Under denna fas är syftet att underhålla systemet så det fungerar problemfritt för alla användare (Andersen, 1994). Om det måste göras större förändringar får man gå tillbaka till fas ett och gå igenom hela livscykeln igen, det vill säga när en förändring ska ske så är det upp till förvaltaren att avgöra om det är nödvändigt att gå igenom hela livscykeln på nytt (Andersen, 1994). Denna bedömning är individuell och får göras från fall till fall. När en förändring har skett är det hela tiden viktigt att försöka ha en uppdaterad dokumentation som stämmer med hur systemet verkligen ser ut (Andersen, 1994).
2.8.6 Avveckling
Ett informationssystem kan inte förvaltas och förändras i all evighet (Avison & Fitzgerald, 1995). När förändringarna blir för stora och kommer för ofta avvecklas det gamla systemet och ett nytt system tar vid (Andersen, 1994). Om ett äldre system är i en ständig förändring får verksamhetsledningen avväga om det är lönsamt att ha kvar systemet och undersöka ifall användarna är tillfredsställda (Andersen, 1994). Om inte, kan ett nytt system vara en lösning (Andersen, 1994). Ifall ledningen bestämmer sig för att utveckla ett nytt system sker en avveckling av det gamla systemet när det nya är redo att ta vid.
3 Problembeskrivning
I många år har de traditionella synsätten på systemutveckling dominerat marknaden och idag har marknaden störst antal systemutvecklingsmetoder enligt de äldre och traditionella synsätten (Mathiassen et al., 1998). En bidragande orsak till detta kan vara att i över tjugo år har verktyg utvecklats för att hjälpa till med systemutveckling enligt ett funktions- och dataorienterat synsätt. Det existerar idag verktyg som stödjer den traditionella systemutvecklingsprocessen från analys till design. Objektorienterade verktyg för systemutveckling har först och främst utvecklats under nittiotalet vilket gör att de inte har nått fram till samma förmåga som de äldre synsättens verktyg har.
I och med att de äldre synsätten är beprövade och till synes fungerar på ett tillfredsställande sätt, så har objektorienterad systemutveckling hamnat i skymundan. Enligt Karlander (1998) var det i början på nittiotalet många som hade förutspått att det objektorienterade synsättet skulle bli ett arbetssätt som skulle bli allmänt vedertaget innan år 2000. Detta har inte hänt och de flesta håller kvar vid de synsätt som är gamla och beprövade (Karlander, 1998).
Ett annat problem som har gjort det svårt för objektorientering att hävda sig är att det inte har funnits någon accepterad standard som har kunnat användas. De traditionella synsätten fick en modell som de kunde följa vilket gjorde det möjligt för angreppssätten att utvecklas (se delkapitel 2.1). Objektorienterade modelleringsspråk fick inte en standard förrän i slutet på nittiotalet och detta har gjort att objektorientering inte har blivit ett synsätt som företagen har accepterat till fullo (se delkapitel 2.1).
Ur det traditionella synsättet på systemutveckling kan till exempel datamodellering och dataflödesdiagram användas som beskrivningstekniker för att modellera ett företag. Den traditionella modelleringen i form av ER-modellen går ej att använda i ett objektorienterat synsätt för att den inte kan beskriva detaljrikedomen i det objektorienterade synsättet, i stället får UML användas som beskrivningsteknik (Mathiassen et al., 1998). UML är ett modelleringsspråk för objektorienterad systemutveckling (Mathiassen et al., 1998). Det objektorienterade angreppssättet är en utveckling av dataorienterade synsättet för hur ett informationssystem kan utvecklas (Mathiassen et al.,1998).
3.1 Problemställning
För de faser som ingår i livscykelmodellen (förändringsanalys, systemering (analys och utformning), realisering, implementering, förvaltning/drift och avveckling) undersöks det om det är möjligt att med hjälp av objektorienterade tekniker och begrepp ersätta de traditionella tekniker som är funktions- och dataorienterade. De tekniker som kan anses som traditionella är till exempel dataflödesdiagram och datamodellering enligt ER-modellen. Arbetet kommer att försöka svara på följande fråga:
Kan objektorienterad modellering i form av UML ersätta traditionella tekniker i livscykelmodellens olika faser?
Det centrala i uppsatsen kommer alltså att vara att undersöka om det är möjligt att ersätta de traditionella teknikerna med UML för att på så sätt få ett modelleringsspråk enligt det objektorienterade synsättet. Den objektorienterade modelleringen kommer att implementeras med UML, för att detta notationssätt gäller idag som standard för modellering inom objektorienterat synsätt.
3.2 Avgränsning
Detta arbete begränsas till att göra en jämförelse av förändringsanalys och analysdelen av systemeringen. I livscykelmodellen förekommer även realisering, implementering, förvaltning/drift och avveckling. Realisering och implementering ingår i systemutveckling, men för att arbetet ska vara möjligt att realisera inom tidsramarna görs en begränsning till de första två problemområdena vilka är förändringsanalys och systemeringens första delfas i livscykelmodellen. Förvaltning/drift är oftast en repetition av livscykeln vilket gör att denna del inte är väsentlig för detta arbete och avveckling är ett specifikt problemområde i sig som inte är likt något av de tidigare problemområdena i livscykeln och är därför ointressant för detta arbete. Inom systemutvecklingen förekommer det flera olika modeller men detta arbete har avgränsat sig till att använda den traditionella livscykelmodellen som grund. Med den traditionella livscykelmodellen avses den modell som utvecklades av NCC i Storbritannien 1969 (Daniels & Yeates, 1971).
Det finns en mängd olika metoder och tekniker som har utvecklats i det traditionella perspektivet. Dataflödesdiagram och ER-modell är de två teknikerna som kommer att representera det traditionella synsättet i detta arbete. I objektorienterad modellering med UML som grund är det bara den statiska modelleringen som är intressant för denna jämförelse. En begränsning kommer också att göras i fallstudien där de tre första faserna är aktuella i detta arbete.
3.3 Förväntat
resultat
Detta arbete kommer att påvisa hur det är möjligt att översätta förändringsanalys och systemering enligt ett data- och funktionsorienterat synsätt till ett objektorienterat synsätt med livscykelmodellen som utgångspunkt. Denna ersättning av traditionella tekniker ska realiseras med UML som modelleringsteknik för det objektorienterade tankesättet. Det är också viktigt att försöka utveckla ett objektorienterat arbetssätt för hur analysfasen ska fungera, det vill säga vad är viktigt att koncentrera sig på när man utvecklar ett informationssystem enligt ett objektorienterat synsätt.
4 Metod
Med arbetets problemställning som grund fanns det möjlighet att använda flera olika metoder. Metodvalet är en förklaring av hur det preciserade problemet löses med hjälp av ett empiriskt tillvägagångssätt (Backman, 1998). Vidare skriver Backman att metodsektionen på ett detaljerat sätt beskriver metoden för att replikation och evaluering ska vara möjligt. Replikation innebär att undersökning ska vara möjlig att göra om under exakt samma förhållanden och evalueringen gör det möjligt att kunna värdera det empiriska förfarandet (Backman, 1998).
Under flera århundraden har processen för forskning utvecklats och detta har gjort att flera olika inriktningar på forskningsprocessen kan användas (Andersen, 1994). En av de första inriktningarna som utvecklades heter empirism. Detta synsätt hävdar att all kunskap bygger på observationer av verkligheten (Andersen, 1994). Positivismen har sin föregångare i empirismen och de båda synsätten har flera punkter som är lika, till exempel att de båda metoderna bygger på iakttagelser från verkligheten (Andersen, 1994). Positivismen skapades med fysiken som förebild av en fransk sociolog vid namn Auguste Comte (Patel & Davidsson, 1994). Synsättet var ett försök att skapa en vetenskaplig metodologi som var lika för alla vetenskaper och detta skulle resultera i att alla vetenskaper skulle vara uppbyggda på ett och samma sätt, detta brukar kallas vetenskaplig monism (Patel & Davidsson, 1994). Från positivismen utvecklades den logiska positivismen (Andersen, 1994). Detta synsätt på forskningen ville få fram en enhetlig vetenskap som skulle utgå från det innehåll man fick från erfarenheten vid direkta observationer (Andersen, 1994). Angreppssättet skulle utvecklas med hjälp av den formella logiken (Andersen, 1994).
Ett synsätt som anses vara motsatsen till positivismen är hermeneutik (Patel & Davidsson, 1994). Hermeneutik har utvecklats under flera århundraden, och till en början var den en metod för att tolka bibeltexter för att under nittonhundratalet utvecklas till att bli en existentiell filosofi med grund i mänsklighetens existens (Patel & Davidsson, 1994). Detta kan jämföras med positivismens synsätt där allt utgår från fysiken eller logiken. Skillnaderna mellan positivismen och hermeneutiken finns på flera olika plan. Några av de viktigaste skillnaderna är att positivismen försöker göra en supermetodologi och försöker vara objektiv men hermeneutiken är mer uppbyggd på förståelse och den blir subjektiv utifrån forskarens egen uppfattning (Patel & Davidsson, 1994). Denna subjektivitet kommer ifrån forskarens egen världsuppfattning och med den som utgångspunkt försöker forskaren tolka de olika iakttagelser som görs i observationen (Patel & Davidsson, 1994).
En forskningsprocess kan även klassificeras med hjälp av begreppen kvantitativ eller kvalitativ. Kvalitativt och kvantitativt synsätt är inte varandras motsatser utan det är snarare två synsätt som har gemensamma kännetecken som till exempel att utgångspunkten är att ett fenomen studeras (Andersen, 1994). Det kvalitativa angreppssättet på forskningen är en undersökning av fenomen som består av en unik sammansättning av egenskaper eller kvaliteter (Andersen, 1994). På grund av att egenskaperna eller kvaliteterna inte kan mätas på ett objektivt sätt utgör detta en skillnad mot ett kvantitativt synsätt (Andersen, 1994). Man kan här se en koppling
observationen ger (Andersen, 1994). Kvantitativt synsätt utmärks med att det som ska studeras ska vara mätbart och resultatet ska sedan presenteras numeriskt (Andersen, 1994). Här kan man se en klar koppling till positivismen och den logiska positivismen som har sina utgångspunkter i logiken och fysiken där allt är mätbart (Andersen, 1994).
En undersökning kan göras med den ena eller den andra metoden, kvantitativt eller kvalitativt. Det finns flera avgörande faktorer som bestämmer vilken metodik som ska användas. Valet kan göras med följande faktorer (Andersen, 1994):
• Vilket ämne som ska undersökas.
• Hur undersökningsämnet uppfattas.
• Vilket syfte undersökningen har.
Med dessa tre punkter i åtanke ska denna undersökning genomföras med hjälp av de tekniker som är mest lämpliga för den problemställning som finns.
Innan en metod väljs bör man ha i åtanke vilken form av undersökning som ska göras. Det existerar flera olika inriktningar på hur ett arbete kan planeras. En undersökning kan vara explorativ, deskriptiv eller hypotesprövande (Patel & Davidsson, 1994). En explorativ undersökning försöker att undersöka ett problemområde så noggrant som möjligt och med denna information försöka svara på så många frågor som möjligt inom problemområdet (Patel & Davidsson, 1994). En deskriptiv undersökning försöker att beskriva förhållande som finns i nutid eller har funnits i dåtid (Patel & Davidsson, 1994). Om undersökningen har som mål att bli omfattande och man utvecklar egna teorier kallas den hypotesprövande (Patel & Davidsson, 1994). Detta innebär att det finns flera typer av undersökningsmetoder att välja emellan.
• Litteraturstudie
• Fallstudie
• Intervju
4.1 Litteraturstudie
En litteraturstudie är en sökning av information i olika typer av dokument (Patel & Davidsson, 1994). Informationen som söks kan hittas i flera olika former, till exempel litteratur, statistik och register, audiovisuellt material eller material från institutioner (Andersen, 1994). Litteraturen kan vara till exempel skönlitteratur eller facklitteratur, statistik, register eller audiovisuellt material (Patel & Davidsson, 1994). Register finns i form av till exempel kundregister eller medlemsförteckningar, audiovisuellt material kan vara till exempel band, film eller material från institutioner finns i form av till exempel diarier eller protokoll (Patel & Davidsson, 1994).
Patel och Davidsson (1994) betonar att alla dokument inte är offentliga och detta gör att problemställningen kanske måste revideras för att kunna besvara de frågeställningar som har ställts i sin problemställning. Fördelarna med en litteraturstudie är att det är en snabb och billig teknik att besvara frågeställningar (Andersen, 1994). En svaghet som finns hos litteraturstudier är att materialet som används är styrt, det vill säga materialet är redan fastlagt (Andersen, 1994).
4.2 Fallstudie
En fallstudie är en undersökning av ett speciellt fenomen i sin realistiska miljö (Backman, 1998). Studien kan utföras på en eller flera individer där en individ kan vara en organisation eller en situation (Patel & Davidsson, 1994). Fallstudien är ett bra medel för att undersöka processer eller förändringar (Patel & Davidsson, 1994). I fallstudien ska det dessutom undersökas om det finns några generaliseringar som kan göras av resultatet och det beror på vilken typ av fall som ligger till grund för studien (Patel & Davidsson, 1994). En fallstudie kan vara av olika typer, deskriptiv eller explorativ (Backman, 1998). En deskriptiv fallstudie är beskrivande, den beskriver ett fenomen som har uppkommit, och en explorativ studie är undersökande, den undersöker om fenomenet som uppkommit är sant (Backman, 1998).
4.3 Intervju
Denna typ av undersökning kan beskrivas som ett samtal där intervjuaren skaffar sig information från respondenten (Andersen, 1994). En intervju kan genomföras på flera olika sätt men de två vanligaste är att en person utför intervjun vid ett personligt möte eller genom telefonsamtal (Patel & Davidsson, 1994). En intervjuare måste klargöra syftet med intervjun och få respondenten att känna att hans/hennes roll är viktig (Patel & Davidsson, 1994). En sak som är viktig att förklara är huruvida respondentens bidrag är anonymt, konfidentiellt eller om undersökningen blir en offentlig handling där dennas uppgifter och svar finns med (Patel & Davidsson, 1994). Skillnaden mellan anonymt och konfidentiellt är att på en anonym intervju finns det ingen möjlighet att spåra vem som har svarat vad, men i en konfidentiell intervju finns det nummer och liknande för att hålla reda på att alla är intervjuade (Patel & Davidsson, 1994).
Det finns flera olika faktorer som en intervju kan byggas upp kring. Standardisering är en av dessa och den bedöms på om frågorna i intervjun är planerade eller ej (Patel & Davidsson, 1994). Intervjun kan ha en hög grad av standardisering vilket gör att alla frågor är planerade i förväg. Ett annat mått som används är hur strukturerad en intervju är (Patel & Davidsson, 1994). Struktureringen bedöms av hur frågorna är formulerade, det vill säga är frågorna öppna eller finns det bara fasta svarsalternativ (Patel & Davidsson, 1994).
En intervju utformas med en inledning, mittendel och en avslutning (Patel & Davidsson, 1994). I inledningen ställs frågor om individens bakgrund som det behövs information om och i avslutningen ställs det även frågor om det finns ytterligare kommentarer eller någon form av tillägg (Patel & Davidsson, 1994). Mellan de
ovanstående delarna av intervjun kommer de frågor som är relaterade till problemet (Patel & Davidsson, 1994). Frågorna i en intervju kan ordnas på olika sätt och de sätt som existerar är tratt-teknik eller omvänd tratt-teknik (Patel & Davidsson, 1994). Tratt-tekniken går ut på att först ställa de stora generella frågorna för att sedan gå över till de mer specifika och i den omvända tekniken gör man tvärtom (Patel & Davidsson, 1994). När det gäller frågorna i en intervju är det viktigt att ställa frågor som respondenten förstår och har möjligheter att besvara på ett bra sätt (Andersen, 1994). Det är också viktigt att tänka på att inte ha för långa frågor, ledande frågor, negationer eller dubbelfrågor (Patel & Davidsson, 1994).
4.4 Val av metod
I problemställningen står det att är avsikten att göra en jämförelse mellan traditionella och objektorienterade synsätt. Detta innebär att arbetet kommer att bli en verbal analys av det problem som är specificerat och vilket gör att arbetet får en kvalitativ inriktning.
Utifrån arbetets problemställning har uppsatsen utvecklats enligt ett positivistiskt tankesätt, det vill säga att utifrån de traditionella tekniker som presenteras i arbetet försöka hitta ett arbetssätt som använder sig av objektorienterade tekniker. En annan aspekt på varför detta arbete är positivistiskt inriktat är att inom detta område som ska undersökas finns det inte utrymme för fria tolkningar, utan de tekniker som presenteras har sin grund i datalogi som är uppbyggt från den formella logiken. Problemställningen indikerar att det är en hypotes som ska falsifieras, det vill säga: Finns det objektorienterade tekniker som kan ersätta de traditionella fullt ut?
I problemställningen står det att en jämförelse av traditionella och objektorienterade tekniker ska göras vilket innebär att arbetet får även en deskriptiv inriktning. Med hjälp av den deskriptiva inriktningen och hypotesen som existerar har arbetet valt att baseras på litteraturstudie, fallstudie och intervjuer.
• Första delen i uppsatsen består av en litteraturstudie för att klargöra begrepp och förhållanden mellan de olika förfaringssätt som existerar för att utveckla ett informationssystem. Studien syftar också till att ge en kunskapsbas så att en korrekt jämförelse kan göras.
• Fallstudie och intervju kommer att användas för att få en realisering av litteraturstudien. Fallstudien kommer att ske i samarbete med ett företag som arbetar professionellt med att utveckla informationssystem. Deras utvecklingsmodell kommer att ligga till grund för fallstudien och i samband med studien kommer även intervjuer göras med systemutvecklingsansvariga på företaget.
Denna kombination av metoder gör det möjligt för undersökningen bli genomförd på flera olika sätt, men arbetet blir deskriptivt där man undersöker dagsläget i problemområdet som har specificerats och hypotesprövande där det undersöks om problemställningen kan falsifieras.
Intervjun kommer att vara ostrukturerad och något standardiserad. Det kommer att vara öppna frågor som utgår ifrån företagets utvecklingsmodell. Frågorna kan på så sätt förberedas med modellen och litteraturstudien som utgångspunkt vilket gör att intervjuerna kommer att vara uppbyggda med basfrågor och följdfrågor. Basfrågorna kommer att bestå av frågor som grundar sig i litteraturstudien och företagets utvecklingsmodell vilket gör att de blir standardiserade. Följdfrågorna blir de som uppkommer vid diskussion runt basfrågorna och de blir ostandardiserade.
För att kunna strukturera uppsatsens genomförande kommer det att finnas flera olika arbetssteg som kommer att följas. Arbetsstegen ska hjälpa till att besvara problemställningen och stegen är följande:
• För att kunna göra en jämförelse av traditionell och objektorienterad systemutveckling är en litteraturstudie gjord. Studien bestod i att undersöka om det finns ersättning för de tekniker som används i en traditionell utveckling med objektorienterade metoder och tekniker.
• En fallstudie har använts för att stärka de slutsatser som dras i litteraturstudien. Studien är genomförd på ett företag som idag använder sig av traditionella tekniker men är intresserade att se vad som krävs för att kunna börja utveckla system objektorienterat från förändringsanalys till implementation.
• Intervjuer är kopplade till fallstudien för att ge förklaring till de notationer som används i företagets traditionella tekniker. Intervjun har även försökt att utreda vilka begrepp som används i företaget för att kunna koppla dessa till litteraturen. Intervjuernas respondenter är idag ansvariga för systemutvecklingen på företaget.
5 Genomförande
I detta avsnitt av uppsatsen är syftet att redogöra hur litteraturstudien är genomförd och vilket fenomen som fallstudien har undersökt. Det kommer också att redogöras för hur intervjuerna har strukturerats och vilka respondenter som har valts.
5.1 Litteraturstudie
För att kunna hitta litteratur har en omfattande litteratursökning gjorts. I sökningen har Internet och bibliotek använts för att kunna hitta den litteratur som har varit av intresse för arbetet. Sökningen av litteratur för traditionella tekniker har inneburit att mycket litteratur har letats upp för att genomgås och utvärderas. I utvärderingen har det varit värdefullt att ur den traditionella synvinkeln hitta litteratur som ger dels en överblick av traditionell systemutveckling, samt en djupare inblick i flera olika traditionella metoder och tekniker att utveckla system. Inom det objektorienterade synsättet var det svårare att hitta litteratur om ett gemensamt synsätt för systemutveckling. Skälet till detta kan vara att den standard för objektorienterad modellering som arbetet grundar sig på (UML) blev erkänd 1997. Detta medförde att det fanns endast ett fåtal böcker att välja emellan. En kort introduktion till den litteratur som har varit central för arbetet ges nedan.
Andersen (1994) Systemutveckling – principer, metoder och tekniker är en bok som
uppfyller ovanstående krav på en systemutvecklingsbok med traditionellt synsätt. Den tar upp livscykelmodellen på ett grundläggande sätt samt att den förklarar de olika traditionella teknikerna. Andersen har tjugo års erfarenhet inom systemutveckling både från undervisning och från praktisk erfarenhet (Andersen, 1994).
Avison och Fitzgerald (1995) Information Systems Development: Methodologies, Techniques and Tools är en bok som kompletterar Andersen (1994) väldigt bra för att
de traditionella arbetssätten förklaras med en annan infallsvinkel gentemot Andersen (1994). Boken förklarar på ett bra sätt de metoder och tekniker som är aktuella för arbetet. Båda författarna är professorer i informationssystem och undervisar vid universitet i England. Avison undervisar vid Southampton University och Fitzgerald undervisar vid Birkbeck College, University of London (Avison & Fitzgerald, 1995).
Eriksson och Penker (1998) UML Toolkit fungerar som en uppslagsbok för
notationen i UML och den är en av de få böcker som finns i objektorienterad systemutveckling med UML som grund. Eriksson har lång praktisk erfarenhet av objektorienterad utveckling och har dessutom skrivit flera böcker i ämnet som till exempel ”Objektorienterad programutveckling i C++” och ”Programutveckling för Windows och Windows NT” (Eriksson & Penker, 1996). Penker har arbetat som projektledare och utvecklingschef i objektorientering samt har dessutom skrivit boken ”Praktikfall av objektorienterad systemutveckling” (Eriksson & Penker, 1996).
Mathiassen et al. (1998) Objektorienterad analys och design beskriver metodstegen
Mathiassen är professor i datalogi vid Aalborgs universitet och är verksam som konsult i IT frågor (Mathiassen et al., 1998). Munk-Madsen är verksam som konsult och undervisar dessutom i systemutveckling (Mathiassen et al., 1998). Han har också skrivit boken ”Strategisk projektledning” (Mathiassen et al., 1998). Nielsen är lektor i datalogi vid Aalborgs universitet och är bland annat medförfattare till en mängd vetenskapliga artiklar och böcker (Mathiassen et al., 1998). Stage är lektor i datalogi vid Aalborgs universitet och forskar om metoder för analys och design inom systemutveckling.
5.2 Fallstudie
För att få en verklighetsanknytning till det som undersöktes i litteraturstudien var fallstudie ett naturligt val. Ett företag kontaktades för att se om det var möjligt att se hur deras systemutveckling bedrivs. Företaget utvecklar sina system genom att använda sig av traditionella tekniker. Fallstudien har företagets systemutvecklingsmodell som grund och det visade sig att flera av de traditionella tekniker som existerar används i deras modell.
5.3 Intervjuer
För att intervjuerna skulle vara genomförbara krävdes först en noggrann genomgång av företagets utvecklingsmodell för att se en möjlig koppling till litteraturen. Intervjuerna var relativt enkla att genomföra i och med att företagets utvecklingsmodell och litteraturstudien var utgångspunkten. Frågorna formulerades på ett sådant sätt att de gav svar på de oklarheter som fanns i modellen och för att kunna göra det möjligt att se en koppling till litteraturstudien. Med detta som utgångspunkt blev intervjuerna en blandning av de olika sätten att strukturera en intervju. Intervjuerna påbörjades i ostrukturerat och standardiserat sätt för att övergå till en öppen diskussion. Valet av respondent för intervjuerna var ganska enkelt, för det fanns bara en person som var utvecklingsansvarig på det aktuella företaget. Med denna respondent gjordes sedan en intervju med de förutsättningar som har förklarats ovan.
