MOS eksamen uuuh.docxmadebyfm.dk/.../uploads/2015/05/MOSeksamenuuuh.docx · Web viewMed afsæt i de...

Modellering og Systemudvikling KU - Kommit

Indholdsfortegnelse

Indledning_______________________________________________________________________________2

Spørgsmål 1:_____________________________________________________________________________3

Standardsystemer:__________________________________________________________________3

Udvikling ved ekstern leverandør:______________________________________________________5

Når en organisation selv udvikler sit it-system:____________________________________________6

Spørgsmål 2:______________________________________________________________________________8

De tre typer af systemudviklingsmetoder:________________________________________________8

Vandfaldsmetoden:__________________________________________________________________8

Den iterative metode:________________________________________________________________9

Den agile metode:___________________________________________________________________11

Forskellig metoder til forskellige organisationer:___________________________________________12

Spørgsmål 3:______________________________________________________________________________14

Indledende fase (behovsanalyse):_______________________________________________________15

Kravspecifikationer:___________________________________________________________17

Designfase:________________________________________________________________________18

Testfasen:__________________________________________________________________________19

Implementeringsfase:________________________________________________________________21

Opfølgningsfasen:___________________________________________________________________23

Delkonklusion:______________________________________________________________________24

Spørgsmål 4:______________________________________________________________________________25

Konklusion:_______________________________________________________________________________26

Litteraturliste:_____________________________________________________________________________28

1


Indledning

Følgende eksamensopgave vil indledningsvis analysere hvilke forhold der bør være afgørende for en

organisations valg af it-system. Der vil være særligt være fokus på organisationens behov og struktur, herunder,

volumen og ressourcer. Her vil vi især overveje Stefanou og Lauesens forskellige fokus ved køb af et

standardsystem. Endvidere har Carmen & Tjia (Carmen & Tjia, 2005) og Pedersen et al (Pedersen et al, 2013)

interessante syn på specialudvikling og hvilke forhold, der er forudsætning for at kunne udvikle via en ekstern

leverandør, med særligt fokus på “offshoring”. Dernæst vil vi forholde os til Truex et al’s (Truex et al, 1999) syn

på “emergente” organisationer og stille det overfor Markus et al’s (Markus et al, 2000) syn på menneskers

tilpasningsevne overfor nye systemer.

Med afsæt i de udledte forhold under udviklingen med en ekstern leverandør, vil opgaven analysere hvilke

udfordringer der kan være for en organisation, ved anvendelsen af systemudviklingsmetoderne: vandfald,

iterativ og agil. Opgaven vil især se på hvordan man kan undgå disse komplikationer og hvordan man finde det

bedste systemudviklingsmetode ud fra kundens behov. Til at beskrive disse udfordringer og give et overblik

over hvad de forskellige organisationer har brug for har vi især brugt Hass (Hass, 2008) og Schwaber (Schwaber,

1995) artikler, da de har forskellige holdninger til metoderne. Hass (Hass, 2008) forholder sig mere kritisk til alle

metoderne hvor Schwaber (Schwaber, 1995) har en mere subjektiv tilgang til de agile metoder og især SCRUM.

Opgaven vil også fokusere på Avison & Fitzgeralds (Avison & Fitzgerald, 2006) syn på vandfalds og de iterative

metoders implementering i en organisation, og blive analyseret i forhold til Li (Li, 1990) og Ragunath et al’s

(Ragunath et al, 2010) modstridende synspunkter.

Afslutningsvis vil vi argumentere for vores valg af supplerende litteratur som er dels modsættende og dels

understøttende i forhold til synspunkterne i vores kursuslitteratur. Endvidere vil vi tage højde for

anbefalingerne i vores opgave, med en kritisk analyse af vores litteratursøgningsproces og -valg med en kritisk

analyse.

2


Spørgsmål 1

Følgende afsnit vil analysere hvilke forhold der bør være afgørende for om en organisation vælger enten at

købe et standardsystem, få en ekstern leverandør til at udvikle it-systemet eller vælger at udvikle det internt i

organisationen.

Standardsystemer

SAP er et multinationalt selskab som er frontløber inden for at sælge standardsystemer til virksomheder.

Særligt kendt er deres SAP ERP(Enterprise Resource Planning), som gør det muligt for organisationer via data at

styre og lede alle lag i organisationen (Avison & Fitzgerald, 2006: 184). Vi vil nu se nærmere på hvilke forhold

organisationer skal tage højde for ved køb af disse systemer.

For små-mellemstore organisationer (SME) er dels de økonomiske ressourcer og selve volumen(ansatte,

tekniske kompetencer mv.) ofte et væsentligt forhold der skal tages højde for i udviklingen af it-systemer, som

det fremgår i Howcroft & Lights artikel samt Craig et al’s afhandling:

“SMEs are often resource poor, and resource based theory indicates that they will need different

competences to cope with scarce resources. They may also have to rely more on external

resources and thus a different set of competences are required, particularly externally focused

ones” (Craig et al, 2011: 354).

”Within an SME context, many firms implement packages because they lack technical and

financial resources to develop a system from scratch (Howcroft & Light, 2010: 128).

Her understreges det at særligt SME, sjældent besidder de nødvendige (økonomiske og tekniske) ressourcer til

selv at udvikle it-systemet og dermed i stedet kan vælge at outsource, i form af at købe enten et

standardsystem eller specialudvikle via eksterne leverandøre (Ibid.). Vi tager først udgangspunkt i hvilke

forhold der bør gøre sig gældende for denne størrelse virksomhed (SME), når den skal købe et standardsystem.

Grundet de manglende økonomiske ressourcer og evner til at selv at udvikle et system, er det væsentligt for

SME, at finde det system hvor produktets funktionalitet bedst indfrier organisationens behov (Howcroft &

Light, 2010: 125). I et økonomisk perspektiv, mener Markus et al, at yderligere omkostninger i forbindelse med

udviklingen kan imødegås ved at inddrage brugerne tidligt i processen, således at der ikke skal bruges ekstra

penge på at ændre systemet efterfølgende (Markus et al. 2000: 251).

3


En anden tilgang til at imødegå dette, er ifølge Stefanou, ved at leverandøren laver en behovsanalyse af

organisationen, således at leverandøren kan få indblik i arbejdsgangen, medarbejderne, strukturen, evt.

daværende it-system mv. og derigennem kan give organisationen et mere præcist budget og deadline

(Stefanou, 2001: 211). Fordelen for organisationen ved Stefanous tilgang kan være i sammenligning af

udbydere, med henblik på at skaffe det system som opfylder de væsentligste behov med de lavest mulige

omkostninger (Howcroft & Light, 2010: 137). Ulempen heri, sammenlignet med at inddrage brugerne, kan være

at der efterfølgende vil komme yderligere omkostninger, fordi slutbrugerne i organisationen ikke forstår

systemet, hvilket her underbygges af Howcroft & Light:

”but these “IT imperatives” or fashions usually emerge from persuasive discourse, rather than

based on sound arguments […] This can lead to firms adopting technologies that they do not fully

understand and that do not match their needs” (Howcroft & Light, 2010: 128)

Dette kan være et væsentligt forhold som SME skal tage højde for, fordi det såfremt at de ikke har volumen til

selv at tilpasse og ændre systemet efterfølgende, vil medføre at der skal betales ekstra for at få tilpasset

systemet. For at forebygge at det ikke foregår på disse ”IT imperativers” præmisser, kan det være relevant for

en sådan organisation også at lave en kravspecifikation indledningsvis. Dette med henblik på at sikre, at det i et

så stort omfang som muligt er systemet der tilpasses organisationen og ikke omvendt (Ibid.: 129). Alle

standardsystemer skal nemlig opsættes og tilpasses, eksempelvis således at der bygges skabeloner, makroer,

tilføjelser mv. ovenpå en basissoftware, hvilket kan være en omfattende proces (Avison & Fitzgerald, 2006:

177). I forhold til kravspecifikationen er det derfor væsentligt, at organisationen forholder sig til hvad målet

med selve it-systemet er, for at sikre at det opsættes og tilpasses i forhold til det udspecificerede behov

(Lauesen, 2007: 8). Lauesen fokuserer meget på at en kravspecifikation skal være udførlig, med det formål at

leverandøren har mulighed for at finde de præcise løsninger, som indfrier organisationens behov (Ibid.:9).

Opsamlende spiller volumen i organisationen en rolle for hvorvidt man er nødsaget til at købe et

standardsystem fremfor at specialudvikle. Efterfølgende bør det forretningsmæssige behov være et afgørende

forhold, fordi det giver en nuanceret gennemgang af hvordan systemet skal tilpasses/opsættes. En

kravspecifikation kan her fungere godt som understøttende afsæt. Derigennem kan det undgås at en i forvejen

økonomisk-begrænset organisation skal bruge yderligere penge, fordi det endelige produkt ikke kan bruges

(Stefanou, 2000: 211).

Udvikling ved ekstern leverandør

4


Der kan være en rimelig flydende grænse i henhold til om en organisation skal købe et standardsystem eller bør

udvikle it-systemet via en ekstern leverandør. Blandt de forhold som gør sig gældende i begge situationer, er at

en udførlig kravspecifikation i den indledende fase kan være et vigtigt udgangspunkt (Lauesen, 2007: 9). I

følgende afsnit vil vi derfor forsøge at lægge fokus på hvilke forhold i en organisation, der kan medføre at det

snarere er en fordel at specialudvikle sit it-system via en ekstern leverandør.

Først og fremmest kan det være en nødvendighed rent forretningsmæssigt, hvis organisationens

forretningsområde eksempelvis er så lille at opsætning/tilpasning kan blive meget omfangsrig. Et andet forhold

kan være hvis organisationen har behov for et mere kompliceret/skræddersyet system (Avison & Fitzgerald,

2006: 177). I en sådan situation kan organisationen vælge at specialudvikle systemet sammen med en

leverandør. Keil & Tiwana (Keil & Tiwana, 2006) har lavet en artikel, hvor de sammenholder undersøgelser om

hvad organisationer prioriterer højest i udvælgelsen af it-systemer, for til sidst at ende med en række af de

væsentligste kriterier (Keil & Tiwana, 2006: 237). De udleder bl.a. at et vigtigt forhold er pålideligheden hos

leverandøren, hvormed det særligt indenfor specialudvikling kræver en ledelses- og kommunikationsmæssig

større indsats af organisationen at styre leverandøren, særligt hvis prisen er aftalt efter antal arbejdstimer og

ikke efter en fastsat pris (Ibid.: 245). Årsagen til dette er at udviklingsprocessen ellers kan trække i langdrag,

hvis organisationen ikke har fremlagt de forretningsmæssige behov helt klart til leverandøren. Det kan nemlig

være en god strategi for leverandøren, da de ville tjene en masse ekstra penge på en udskydelse.

I en specialudviklingsproces af et mere kompliceret system, vil det derfor kræve at organisationen er mere

afklarede med sine egne behov, med henblik på at samarbejde med leverandøren i udviklingen af systemet.

Heri kan den fysiske placering af leverandøren også være et væsentligt forhold som organisationen bør

overveje, med henblik på at fremme en mere glidende kommunikation (Ibid.).

Der findes også et andet specialtilfælde kaldet “offshoring”, som vi nu vil kigge lidt nærmere på. Offshoring går

ud på at man outsourcer arbejdet til lande, hvor omkostningerne er mindre end i eget land; eksempelvis i lande

som Kina, Phillipinerne eller Indien. Et forhold som er væsentligt at tage højde for her, er at det på trods af

billigere udvikling, arbejdskraft og samlet pris, kan medføre andre (strukturelle) udfordringer undervejs i

udviklingsprocessen. Blandt andet peger Pedersen et al (Pedersen et al, 2013), på at man skal være

opmærksom på at geografiske, institutionelle og politiske forskelle kan reducere samarbejdsevnen i processen

(Ibid: 5). På den måde kræver det mere af organisationen, såfremt de selv vælger at styre off-shoringen. Det

stiller især krav til en betydelig styringsindsats i organisationen, som kan håndtere de

kommunikationsudfordringer og barriere der kan opstå, når man udvikler på tværs af landegrænser (Ibid.).

5


Hvis organisationen ikke har tilstrækkelige ledelsesevner til at styre denne form for off-shoring, kan den vælge

at gøre det igennem en leverandør, som har en off-shore underleverandør. Da kommunikationen foregår

igennem en tredjepart, giver det så nogle forretningsmæssige udfordringer organisationen skal tage højde for.

De kan risikere at kendskabet til organisationens behov i højere grad bliver tilsidesat, fordi den løbende

kommunikation i udviklingsprocessen er vanskelligere (Ibid.: 10).

Omvendt påpeges det af Carmen & Tjia, at kommunikationsvanskeligheder ikke bør være et lighedstegn med

“offshoring”:

“Companies can benefit from collaborative by investing in a mix: instant messaging, video-

conferencing, high-quality audio-conferencing services [...]” (Carmen & Tjia, 2005: 165).

De ser det som et potentiale snarere end som en udfordring, og at man kan drage yderligere fordele af det

teknologiske udstyr, som sagtens kan understøtte en mere glidende kommunikation.

Det påpeges dog også at det kræver at organisationen besidder de nødvendige teknologiske redskaber (Ibid.).

Dermed giver de Pedersen et al, lidt medhold i at det kræver en større kommunikationsmæssig kapacitet, hvis

man bruger en leverandørs underleverandør. Hvorimod organisationen selv bør have et teknologisk

fundament, for at kunne varetage styringen af en udenlandsk leverandør.

Opsamlende kan det være en nødvendighed for en organisation at specialudvikle, hvis den har behov for et

kompliceret it-system, som et standardsystem ikke kan opsættes til at dække over. Ledelsesmæssigt kræver det

dog en væsentligt større indsats af organisationen, i forbindelse med at styre leverandøren under udviklingen.

Endvidere kan det være en fordel at benytte sig af en noget billigere udvikling via “offshoring”, hvis

organisationen har de teknologiske og kommunikationsmæssige forudsætninger, til at styre leverandøren på

tværs af landegrænser.

Når en organisation selv udvikler sit it-system

“This constant need to change gives rise to a recognition that organizations in the present era are

no longer stable, but are continuously adapting to their shifting environments […] Such

organizations are said to be "emergent”. “ (Truex et al 1999: 117).

Således beskriver Truex et al “emergente” organisationer, dvs. at de snarere end at være stabile bliver udtryk

for et produkt af en løbende social forhandling samt at være i en konstant kontinuerlig udvikling. Dermed

6


mener de endvidere at IT-systemerne er nødt til at understøtte dette, fordi systemer aldrig kan blive fuldendte,

bør være under konstant udvikling og bør være genstand for konstant justering og tilpasning (Ibid.).

Derigennem kan det være en fordel at udvikle systemet selv, fordi man derigennem nemt kan justere,

videreudvikle og vedligeholde sit it-system (Ibid: 121). Det gør samtidig it-systemet unikt, at det kan udvikles

præcist som organisationen ønsker det. Dette både med henblik på at skabe sig selv en konkurrencemæssig

fordel, gøre krav på rettighederne til systemet og/eller få en profit ud af at sælge det videre, såfremt det kan

anvendes af andre virksomheder. Dette er med til at fremhæve de emergente potentialer der ligger i at udvikle

selv.

Dog nuanceres dette indtryk i Grant et al, der understreger at det ikke er hvilke som helst organisationer som

blot ved at være emergent, kan udvikle deres egne it-systemer. Det kræver at man først og fremmest har

volumen til at have sin egen it-afdeling og at det typisk er større organisationer som har denne forudsætning

(Grant et al, 2010: 73). De mener snarere at det skal ses som et udtryk for deres “emergenthed” i

organisationen, som en medvirkende faktor til at selve it-systemerne er nødsaget til at følge med udviklingen

for at understøtte arbejdsgangen (Ibid: 75).

Med hensyn til kravspecifikationer er det en noget anderledes tilgang, når man selv udvikler et it-system.

Organisationen skal være opmærksom på at der som sådan ikke er nogen endegyldig kravliste. For at få det

optimale ud af udviklingspotentialet, må man derfor være dynamisk og klar på at genforhandle

kravspecifikationerne med henblik på at ændre og tilpasse it-systemet, i overensstemmelse med

organisationens udvikling og medarbejdernes behov (Truex et al, 1999: 122). Det er tilgengæld også langt mere

hensigtsmæssigt at udvikle på denne måde hvis det sker “in-house”, fordi der er et stort forretningskendskab

og en nem dialog - da det foregår internt i organisationen. Dog ligger det også implicit at det kræver en stor

ledelsesmæssig kapacitet i selve organisationen, at håndtere en konstant justering og ændring. Særligt i

forbindelse med de konflikter der måtte opstå, lige efter der er sket justeringer i it-systemet. Selvom et

arbejdsmiljø kan være dynamisk og generelt rummer omstillingsparate medarbejdere, så vil det generelt tage

tid for mennesker at tilpasse sig ændringer i it-systemer (Markus et al, 2000: 14). Derfor må man også være

indforstået med det ekstra ledelsesmæssige arbejde det kræver, at få medarbejderne til at trives i et sådant

arbejdsmiljø.

Overordnet set kan det sammenfattes at en organisation bør tage højde for, om den besidder den

tilstrækkelige volumen til at udvikle sit eget it-system. For at det kan betale sig at udvikle et system internt, bør

det være med afsæt i at organisationen er “emergent” og besidder dynamiske omstillingsparate afdelinger og

medarbejdere. Dette med henblik på at systemet hele tiden kan justeres, tilpasses og forbedres.

7


Spørgsmål 2.

De tre typer af systemudviklingsmetoder:

Inden for systemudvikling findes der overordnet tre forskellige typer; vandfald-, iterative- og agile metoder.

Disse tre metoder er en grov opdeling af de systemudviklingsmetoder som man har til rådighed når man

begynder et projekt. Hver af kategorierne har nogle specifikke krav, som gør den enkelte model

hensigtsmæssig til forskellige projekter. Vi vil i nedenstående afsnit beskrive de tre modeller og give nogle

eksempler på deres underkategorier samt deres styrker og svagheder.

Vandfaldsmetoden, som også kaldes den sekventielle metode (Hass, 2008: 3) er en metode som mange større

organisationer gør brug af. Den sekventielle metode bygger på at man arbejder sig frem ad i et stabilt miljø

med stabile krav (Hass, 2008: 3). Man har hele tiden øje for den store helhed af projektet, og ender som regel

altid med at aflevere/implementere projektet, som et stort sammenhængende produkt. Den sekventielle

metode fungerer bedst hvis kunden allerede har en god idé om hvad det endelig produkt skal være og har

fastsat krav til projektet, som regel i form af budget og tidsramme.

Det er vigtigt at kunden har en god forestilling af det endelig produkt, da man med de sekventielle modeller

ikke får meget plads til at ændre på tingene undervejs, da det kan være meget omkostningsfuldt og

tidskrævende.

Grunden til man har fastsatte krav er at man i planlægningsfasen godt kan give meget præcise estimater på en

pris og tidsramme, da man hele tiden arbejder sig fremad i de sekventielle modeller og ikke gentager hver

enkelt fase.

Som det kan ses på modellen nedenfor fra Ken Schwabers artikel ”SCRUM Development Process” (1995) er

dette et eksempel på en vandfalds model:

8


Figur 1

Modellen forløber sekventielt, i det at man ikke gentager faserne. Afhængig af hvilken sekventiel model man

benytter sig af, er det væsentligt at man evaluerer efter hver fase i systemudviklingen. V-modellen, som også

en er sekventiel model benytter sig bl.a. af testes efter hver fase i systemudviklingen.

Som det kan ses på nedenstående figur af en V-model starter man fra venstre mod højre og linje for linje,

ligesom man ville læse en bog (Hass, 2008: 4). Man kan altså ikke gå videre fra ’Requirements’ til ’Design’ før

man har foretaget sig en form for ’Requirements Testing’ (Hass, 2008: 8)

Figur 2

Da man ikke gentager de enkelte faser i den sekventielle metode gør det også processen betydeligt hurtigere

både i de iterative- og agile metoder. På samme måde er den sekventielle metode også betydeligt mindre

omkostningsfuld, da man ikke behøver at bruge ressourcer på konstante ændringer og vende tilbage til

tidligere dele af projektet. Man skal dog tage højde for at kunden skal have en meget detaljeret idé af

produktet da man planlægger det mest af projektforløbet før man går i gang med selve systemudviklingen.

Derfor er den sekventielle metode god til de kunder som har brug for et produkt der ligner noget man måske

allerede kender eller er et form for standardsystem, så man nemt kan fastsætte en tidsramme og et budget på

selve projektet.

Den iterative metode er en metode, som i høj grad, gør brug af gentagelser og dette gør det muligt hurtigt at

foretage ændringer af et produkt, uden at skulle starte helt fra bunden. (Hass, 2008:5). Med den iterative

metode arbejder man hele tiden i cirkelbevægelser ved at lave prototyper af produktet, og dernæst bygge

videre på disse prototyper. Man kan derfor forholdsvis tidligt i udviklingsforløbet have en prototype klar, som

man kan vise frem til kunden. Dette gør den iterative metode velegnet til kunder som ikke helt ved hvad det er

de står og mangler, men har en løs idé om hvad de gerne vil have.

9


En af disse iterative modeller er Barry Boehms ’Spiral Model’ (Boehms, 1998: 7) som kan ses på figuren

nedenfor.

Figur 3

Denne spiral model er en udvikling af vandfaldsmodellen hvor man nærmest bygger ovenpå de tidligere lag

og på den måde hurtigt kan få en prototype på banen som man kan arbejde videre med (Schwaber, 1995: 5).

Hver gang man har været alle faserne igennem laver man risikovurdering af produktet og ser ud fra

prototypen om projektet er på rette spor. Således fortsætter man indtil der ikke længere er nogle risici at

tage højde for, og man ikke længere kan finde nogen umiddelbare problemer med produktet (Hass, 2008:

7).

På mange områder kan man godt se den iterative metode som en videreudvikling på den sekventielle

metode, da man har opbygget den iterative metode på samme principper. Som vi kan se på V-modellen på

figur 2 er princippet det samme for de iterative modeller. Forskellen er blot at V-modellen gentages flere

gange efter hinanden. Dette er illustreret i Hass’ model (Hass, 2008: 15) nedenfor.

10


Figur 4

De iterative modeller er gode til de kunder som endnu ikke helt ved hvad de har brug for, men har nogle

ideer til hvordan det endelig produkt skal være. Man kan nemlig hele tiden tage fat i sine prototyper og vise

dem frem til kunden og få dem til at vurdere om det var det de havde i tankerne. Årsagen til dette er at man

dermed hele tiden kan vende tilbage til sine prototyper, hvilket gør det nemmere at justere og lave

ændringer i produktet undervejs. Den iterative metode er dog en hel del mere tidskrævende og kræver også

et større budget, da man gentager hver enkelt fase op til flere gange og efter hver gentagelse skal udvide sin

prototype.

Den agile metode, minder på mange måder om den iterative metode da man går ud fra de

kravspecifikationer som man gør brug af med den iterative metode. Ligesom i den iterative metode er den

agile metode god til den slags kunder som endnu ikke helt ved hvad det er som de har brug for (Avison &

Fitzgerald, 2006:134). Den agile metode skiller sig ud fra den iterative metode ved at den er mere fleksibel.

Denne fleksibilitet ses især under selve projektudviklingen, da der ikke er nogen grænser for hvordan man

håndterer projektet og hvilken retning selve projektet skal gå i. Dog kræver det den rette kontrol og

organisationen skal også selv være klar på at kunne give projektet meget frie tøjler for at kunne udnytte den

agile metodes potentiale maksimalt (Schwaber, 1995:10). Uden den rette kontrol og fleksibilitet kan den

agile metode hurtigt gå galt, og ende i kaos da det er en meget kompliceret og kompleks

systemudviklingsmetode (Schwaber, 1995: 10). Et eksempel på en agil model er Ken Schwabers SCRUM

model (Ibid.) som kan ses på figuren nedenfor.

Figur 5

11


Med SCRUM arbejder man i mindre hold, som for en opgave som skal løses. Man løser disse opgaver i det

som Schwaber kalder ’Sprints’ (Schwaber, 1995: 10). Det er ikke bestemt på forhånd, hvad der skal ske i

disse sprint og det er derfor vigtigt at der efter en gruppe har afholdt et sprint, laves noget opfølgende

arbejde på det for at vurdere hvordan sprintet er gået. Organisationen kan i princippet selv vælge hvor lang

tid deres sprint vare, men som regel er de mellem en til fire uger (Schwaber, 1995: 14). Disse spring

gentages indtil produktet er færdiggjort, gennemtestet og klar til at blive sat ud i den virkelig verden. I

’Closure’-fasen bliver produktet endnu engang testet igennem og det bliver som regel puttet igennem nogle

’Pre-release’ stadier (Schwaber, 1995:12) for at sikre at produktet er så godt som det kan blive.

Den agile metode har et meget fleksibelt arbejdsmiljø, som sagtens kan ændres hvis der er noget som ikke

fungerer optimalt. Det samme gælder for selve produktet, hvor der er rig mulighed for at vise det frem til

kunden under udviklingen, og de derigennem kan vurdere om projektet er på rette spor eller om projektet

bør ændre kurs. Det er hverken omkostningsfuldt eller tidskrævende at omlægge et projekt med den agile

metode, kontra den sekventielle metode. Dog tager de individuelle projekter længere tid at gøre færdig,

men de bliver i sidste ende også mere omkostningsfulde. Hvis en kunde derfor godt ved hvilket produkt de

har brug for, kan det godt ses som tidsspilde at bruge den agile metode, da der sættes meget stor del af

budgettet og tidsrammen af, til at fange fejl i produktet og lave eventuelle ændringer baseret på kundens

behov.

Forskellige metoder til forskellige organisationer

Hver af systemudviklingsmetoderne har forskellige fordele og svagheder. Derfor er det vigtigt at tage højde

for hvilken slags organisation produktet skal laves til og med hvilke krav. I dette afsnit vil vi især sætte fokus

på hvilke fordele og svagheder de forskellige metoder har, når en organisation skal have en ekstern

leverandør til at udvikle et it-system for sig.

Hvis en organisation vælger en leverandør som bruger den sekventielle metode, bør organisationen så vidt

muligt have en meget detaljeret beskrivelse af it-systemet. Når man gør brug af den sekventielle metode

bliver brugeren ikke inddraget, med undtagelse af de indledende og afsluttende faser. Dette betyder at hvis

kunden får et it-system ud af det som de ikke havde regnet med, kan det blive meget omkostningsfuldt for

organisationen af få ændret hele it-systemet. (Keil & Tiwana, 2006: 237). Hvis organisationen har en god og

detaljeret kravspecifikation af det it-systemet der skal udvikles (Lauesen, 2007: 7), så er den sekventielle

metode et godt valg, da man kan fastsætte et budget og en tidsramme fra starten af, således at det sikres at

aftalerne overholdes, og der ikke sker nogle store ændringer i projektet undervejs. Det kan især være en

12


fordel for organisationer i den offentlige sektor som ofte har meget stramme budgetter og tidsrammer.

Angående ‘offshoring’ (Avison & Fitzgerald, 2006:190) kan den sekventielle model være god, da it-systemet

helst ikke må blive for komplekst. Hvis it-systemet bliver for komplekst bliver det meget svært at kontrollere

både leverandøren og underleverandørene (Avison & Fitzgerald, 2006:190), da man ikke har nogen direkte

kontakt med underleverandørene.

Hvis en organisation vælger en leverandør som benytter sig af den iterative metode, bør organisationen

være klar på at blive inddraget en hel del mere i it-systemet end ved den sekventielle metode.

Organisationen vil formodentlig blive inddraget efter hver cyklus, hvor de ud fra en prototype skal vurdere

om it-systemet er på rette spor. Dette kan selvfølgelig være en fordel for organisationer, som skal have

udviklet et it-system som bygger på et nyt koncept som kan være svært at beskrive under planlægningen.

Fordelen ved at have en leverandør som bruger den iterative metode, er at der er plads til at lave ændringer

under selve systemudviklingsfasen. Det kan spare en organisation for meget store omkostninger, da man

ikke behøver at starte helt forfra med it-systemet hvis der er noget som skal ændres, da det kan klares i

næste iteration. Disse iterationer og ændringer i it-systemet betyder at den iterative metode principielt

tager længere tid end den sekventielle model, da man efter hver cyklus skal lave en opfølgning på it-

systemet og en prototype af it-systemet som skal godkendes. Den iterative metode er fordelagtig for

organisationer, som har plads til lidt mere fleksibilitet i deres budget og tidsramme, men som i sidste ende

også får et it-system ud af projektet som passer dem bedre måske er blevet testet mere igennem, da det har

været de enkelte projektfaser igennem flere gange.

Hvis en organisation vælger en leverandør som benytter sig af den agile metode skal man ligesom i den

iterative metode, være klar på at blive inddraget i flere faser end bare den indledende planlægning.

Organisationen skal også være klar på at give leverandøren frit spil, for at bruge deres egne metoder og lade

dem arbejde i deres eget tempo. Organisationen vil blive inddraget meget og vil under hele forløbet kunne

følge med i it-systemets udvikling. Hvis man vælger en leverandør som arbejder med den agile metode, skal

man være klar på at der ikke kan lægges en fast tidsramme og budget. Selve systemudviklingen kan tage den

tid det nu tager, da man hele tiden kan blive ved med at videreudvikle det. Formentlig vil man også holde

noget alpha/beta-testing for at sikre sig, at it-systemet vil komme til at fungere optimalt i dets endelige

arbejdsmiljø. Dette betyder altså at organisationen ikke kan få et fastslået budget og tidsramme i

planlægningsfasen hvilket kan være problematisk hvis man som organisation har fået et fastsat budget og

tidsramme til rådighed.

13


Opsamlende kan det udledes at det er meget afhængigt af den enkelte organisation, hvilken

systemudviklingsmetode en leverandør bør bruge. Det betyder meget hvad organisationens krav og budget

til leverandøren er samt hvordan de mest effektivt kan bruge disse materialer. Der er fordele ved de tre

forskellige systemudviklingsmetoder, såvel som ulemper. Det er derfor meget vigtigt for organisationen at

sætte sig ind i hvilke systemudviklingsmetoder leverandøren benytter sig af, så de bedst muligt kan

imødekomme hinanden. Konsekvensen af at vælge en systemudviklingsmetode som ikke passer til projektet

kan være katastrofalt for selve produktet, fordi organisationen kan blive nødsaget til at starte helt fra

bunden igen og på den måde have spildt en masse penge, som kunne være brugt anderledes. Den

sekventielle model er rigtig god til at bygge videre på koncepter som allerede eksisterer og til

standardsystemer (Avison & Fitzgerald, 2006: 184). Jo mere man bevæger sig mod et specialudviklet system

jo mere relevant kan det være at bruge de iterative og agile metoder, da de byder en helt anden form for

fleksibilitet end den sekventielle metode. Det kræver dog også at organisationen har de ledermæssige

kompentencer, med henblik på at styre leverandøren, således at de kan håndtere systemudviklingsforløb ud

fra organisationens behov.

Spørgsmål 3.

Når en given organisation vælger at indkøbe et standardsystem, fremfor selv at udvikle et helt nyt system, er

der en række relevante elementer der skal tages højde for. Udover at organisationen overordnet set skal være

bevidste om, hvad formålet med standardsystemet skal være. Skal der indledningsvist gennemgås en

planlægningsfase, hvori organisationen nøje tilrettelægger hvad for et standardsystem de ønsker, så

uforudsete faktorer der kan forårsage at organisationen afslutningsvist står med et ubrugbart produkt ikke

forekommer. Som det fremgår i ’The social shaping of packaged software’ Howcroft & Light (2010) er der en

række retningslinjer, for hvordan en udvælgelse af et standardsystem skal forløbe (Howcroft & Light, 2010:

124). Indledningsvist i udvælgelsesprocessen skal organisationen skabe en forståelse for hvad de har af krav til

det nye system, så organisationen får det bedst mulige udgangspunkt, når det gælder at bestemme den

nødvendige funktionalitet. Dette skal ske for at organisationen i implementeringsfasen, opnår den ’bedste

tilpasning’ til produktet (Ibid.). Den analytiske vinkel på følgende afsnit, vil bestå af en identificering af hvilke

systemudviklingsmetoder, eller elementer heri, der kan være relevant at anvende for en organisation der

vælger at købe et standardsystem.

14


At skabe en forståelse af de krav organisationen har til et standardsystem, har en enorm indflydelse for om det

udviklet system resulterer i succes (Ibid.). Derfor er det en enorm vigtighed for organisationen og udbyderen at

indlede med en behovsanalyse (Ibid:125), hvor organisationen undersøges for hvad, de har af behov der skal

dækkes af systemet. Heri kan organisationen opstille en kravspecifikation (Lauesen, 2007: 1), som i sidste ende

kan mindske de økonomiske udgifter (Markus et al, 2000:), og endvidere mindske chancen for at produktet

bliver ubrugeligt (Sherer, 1993: 261). Med de opstillet kravspecifikationer kan organisationen dernæst indlede

udbuds/designfasen (Ibid: 124), hvor at organisationen præsenteres for en række designs som opfylder de krav

der tidligere er stillet.

Accepteres et af disse designs kan udviklingen af systemet påbegyndes (Ibid:127), her afhænger

organisationens indflydelse i udviklingsfasen af om hvilken systemudviklingsmetode man vælger at anvende.

Når udviklingen af systemet er gennemført, skal standardsystemet testes (Howcroft & Light, 2010:138).

Testningen sker for at sikre at det udviklet system opfylder de kravspecifikationer der tidligere er opstillet, og

for at sikre at det nyudviklet system kan integreres i organisationen (Ibid.). Afslutningsvist påbegyndes

implementeringsfasen (Ibid.), hvor at systemet i overensstemmelse med testresultatet integreres i

organisationen.

Indledende fase (Behovsanalyse)

Følgende afsnit vil indeholde en analyse af hvilke elementer, og hvordan eksempelvis SDLC modellen (Avison &

Fitzgerald, 2006: 31), indledningsvist kan gøre brug af behovsanalysen i planlægningsfasen (Howcroft & Light,

2010: 125). Behovsanalysen bliver ud fra de forskellige typer af systemudviklingsmetoder, benyttet på forskellig

vis. Derudover vil der med en kritisk tilgang undersøges, hvordan den iterative og vandfalds

systemudviklingsmetoderne gør brug kravspecifikationer (Lauesen, 2008: 1). Denne kritiske tilgang vil blive

belyst med udgangspunkt i Ragunath et al. (Ragunath et al. 2010), der kritiserer SDLC modellen for dens

overfladiske tilgang til udvikling af systemer (Ragunath et al. 2010: 112). En kritisk vinkling på den iterative

tilgang, vil tage udgangspunkt i den selvsamme artikel, da Ragunath et al. (Ragunath et al. 2010) stiller sig

kritisk overfor det manglende overlap i faseinddelingen (Ragunath et al. 2010: 114).

“Although the purchase of application packages and ERP systems means that much of the development

work is done externally, it does not mean that there is no systems development work in-house, as the

packages need to be tailored for the company” (Avison & Fitzgerald, 2006: 175).

15


Ovenstående udpluk pointerer at alt udvikling af et standardsystem ikke kun bør foregå eksternt, når en

organisation vælger at købe en færdigudviklet pakkeløsning. For at få tilpasset systemet i organisationen,

kræves det at noget af udviklingen foregår i organisationen (Avison & Fitzgerald, 2006: 175). Endvidere skal

organisationen tage en række forholdsregler i eftertanke, da et køb af et standardsystem kan være en

skræmmende affærer (Ibid: 175). Indledningsvist når en organisation vælger at et nyt system skal købes ind, for

enten at erstatte det gamle, eller for at støtte det gamle system, udføres der en behovsanalyse (Howcroft &

Light, 2010: 125) af udbyderen af standardsystemet. Med analysen undersøges hvilke behov organisationens

medarbejdere har, og i samråd med udbyderen gennemgår man de eventuelle problemer det tidligere system

havde, for derefter at kunne sætte krav til hvad det nye system skal være i stand til (Ibid: 175). Behovsanalysen

skal resultere i en opnåelse af den ‘bedste tilpasning’ (Howcroft & Light, 2010: 124) i implementeringsfasen.

Endvidere skal det resultere i at organisationen skal kunne videregive en samlet kravspecifikation (Lauesen,

2007:1) til udbyderen, så den indledende udvikling af standardsystemet kan igangsættes.

Vælger en organisation eksempelvis at købe et standardsystem med en vandsfalds tilgang (Schwaber, 1995:5),

gennemgår man de respektive problemstillinger med et lineært synspunkt (Ragunath et al. 2010: 113). Her kan

det være relevant at anvende delene ‘forundersøgelse’, ‘systemundersøgelse’ og ‘systemanalyse’ af SDLC

modellen (Avison & Fitzgerald, 2006: 31), for netop at kunne lave en behovsanalyse af de krav organisationen

har til det standard system de ønsker at købe. Med SDLC modellen (Ibid.) fokuseres der på at styrke kontrollen

over systemet ved at opdele komplekse dele af opgaverne, til overskuelige faser (Ragunath et al. 2010: 112).

Denne segmentering af systemet giver udvikleren mulighed, for at gennemgå hver enkelt fase på et mere

struktureret og vellykket plan (Ibid.). Ved brugen af SDLC indledes udviklingen med en ‘ forundersøgelse’

(Avison & Fitzgerald, 2006: 31) af det tidligere system, der eksempelvis skal erstattes af et nyt.

‘Forundersøgelsen’ (Ibid.) der bliver foretaget af en analytiker fra udbyderen af standardsystemet, skal sikre at

det nye system ikke indeholder de samme problemer det tidligere system havde, og derfor undersøger man de

krav systemet havde til formål at opfylde (Ibid.). På baggrund af dette kan organisationen i en analyse,

undersøge alternative løsningsforslag (Ibid.). Under ‘forundersøgelsen’, bliver der sørget for at det system der

skal udvikles er gennemførligt, og at systemet dækker de behov organisationen har. For at sikre dette,

gennemgår analytikeren en række termer (teknisk, menneskeligt, organisation, økonomiske forhold).

Indledningsvist i denne analyse sikres at systemet ligger indenfor de lovgivende rammer, som både kan være

nationale, eller hvis relevant, internationale virksomhedslove (Ibid:32). Endvidere bliver der fokuseret på at

organisationen på et socialt plan, er omstillingsparate i det omfang at de kan acceptere systemet hvis det

16


indeholder store ændringer (Ibid.). Med henblik på det tekniske ved systemet, er det relevant for

organisationen at de kan få støtte af den tilgængelige teknologi, og derfor opsættes der en tilstrækkelig

ekspertise til at bygge det (Ibid.). Til sidst bliver der sikret at systemet økonomisk er overkommeligt, og at der

på et forsvarligt plan bliver fokuseres på de bekostninger standardsystemet har (Ibid.). ‘Forundersøgelsen’

afsluttes med at analytikeren præsenterer en ‘anbefalet løsning’ som dækker de behov organisationen har, og

her kan organisationen så give grønt lys (Ibid.).

Som kendetegn for vandfaldsmodeller, så indledes den næste fase kun når den forrige fase er helt gennemført

(Ragunath et al. 2010: 113). Så idet den ‘anbefalet løsning’ bliver accepteret, kan ‘system undersøgelsen’

indledes, der er mere dybdegående og detaljeret (Ibid.) i sin undersøgelse af systemet, i forhold til den netop

afsluttende ‘forundersøgelse’. I ‘system undersøgelsen’ vil systemudvikleren på et mere detaljeret plan, søge

information angående de funktionelle krav der er blevet stillet i det eksisterende system, og hvordan kravene

til det nye system skal stilles (Avison & Fitzgerald, 2006: 32). Anskaffelsen af disse informationer kan så ske ved

enten at interviewe eller ved at observere de personer der omfattes af systemet, for netop at få indsigt i de

problemer, og behov de har (Ibid.). Med afslutningen af ‘system undersøgelsen’ (Ibid.) kan udvikleren nu

indlede ‘system analysen’ (Ibid: 33) hvor kravene til det nye system kan bestemmes, og en udformning af en

kravspecifikation igangsat (Ibid: 98).

Kravspecifikationer

Ved anvendelsen af SDLC modellen (Ibid. 31) opstilles kravspecifikationen, såfremt de indledende

undersøgelser og behovsanalysen er accepteret. Som Howcroft & Light (Howcroft & Light, 2010) påpeger det,

identificerer kunder almindeligvis nyopståede funktionaliteter under systemudviklingen (Howcroft & Light,

2010: 126). For at undlade at denne faktorer påvirker udviklingen, påkræves det af såvel organisationen, som af

udvikleren, at kravene til standardsystemet skal være fuldstændig indforstået, da justeringer i

vandfaldsmetodens faser kan have omkostningsfulde og tidskrævende konsekvenser for den videre udvikling

(Ragunath et al. 2010: 114). Endvidere er det en vigtighed at der i planlægningsfasen skabes en basisforståelse

for hvilke behov og krav organisationen har til det nye system, så udvikleren nemt kan analysere de specifikke

delelementer standardsystemet skal består af. En svaghed ved SDLC modellen, er den ideelle fremgangsmåde

der bruges (Avison & Fitzgerald, 2006: 41). Avison et al. (Avison & Fitzgerald, 2006) påpeger at top-down

procesgangen er problematisk, da det er nødvendigt at gennemgå serier af iterationer, når organisationen

eksempelvis opdager nye krav eller at en underfaser viser sig at være unødvendige (Ibid.).

17


Sammenlignet med den iterative systemudviklingsmetode, der formuleres organisationens kravspecifikation på

baggrund af gentagne iterationer, hvor udvikleren gennemgår bestemte faser i flere omgange og systemet

leveres ikke før den planlagte iteration er færdig (Hass, 2008: 5). Til en organisation der har en iterative tilgang,

kan det være enormt relevant at der i samarbejde med udvikleren gennemgås en iterativ struktur, hvor

kravsændringer nemt kan tages til efterretning og eventuel forbedres (Ragunath et al. 2010: 114). Denne

fleksibilitet, mindsker modsat den lineære tilgang de økonomiske konsekvenser ved justeringer og fastsættelse

af nye krav (Ibid). Med en iterativ tilgang til købet af et standardsystem, forekommer det at udvikleren i

slutningen af hver iteration producerer et ’subprodukt’ (Hass, 2008: 5). Denne prototype (Ibid.) kan for

organisationen være enorm behjælpeligt, da der visuelt er mulighed for at vide om systemet de får rakt i

hænderne opfylder de kravspecifikationer der er stillet. For en organisation der ikke har nogle konkrete krav til

et standardsystem, kan der med fordel gøres brug af den iterative tilgang. Da organisationen kan blive

præsenteret for et ’subprodukt’, som de med udgangspunkt i kan lave en kravspecifikation. Ragunath et al.

(Ragunath et al. 2010) pointerer dog at problemer vedrørende systemudviklingen kan opstå, hvis alle kravene

ikke er identificeret i den samlet software cyklus (Ragunath et al. 2010: 114).

Designfasen

Følgende afsnit vil fokusere på hvordan fasen design kan være relevant for organisationer der skal købe et

standardsystem. For at få dette belyst, vil der tages udgangspunkt i SDLC modellens design fase (Avison &

Fitzgerald, 2006: 33). Denne lineære tilgang ønskes sammenlignet med RAD modellens design fase (Hass, 2008:

6), der har en iterativ tilgang. Derudover vil der skabes en kritisk vinkling af den iterative vinkel med afsæt i

Coleman & Verbruggen (Coleman & Verbruggen, 1998), der undersøger fordele og ulemper ved anvendelsen af

RAD modellen. Den kritiske vinkling til SDLC modellens designfase (Avison & Fitzgerald, 2006: 33) vil tage afsæt

i Ragunath et al. (Ragunath et al. 2010).

Med en organisation der har en linære tilgang til købet af et standardsystem, vil designfasen i SDLC modellen

være relevant i det omfang, at der på baggrund af de krav og behov der er analyseret i analyse fasen, på

baggrund af dette fastsættes et design (Avison & Fitzgerald, 2006: 33). Udvikleren har her med udgangspunkt i

de identificeret krav og behov, mulighed for at inkorporere det designmæssigt i systemet. I designfasen

fastsættes både det computermæssige og de manuelle dele af systemet (Ibid.). Derfor kræves det at der på et

struktureret plan tages hånd om kravspecifikationen fra udviklerens side, da hensigten ved designet i

18


standardsystemer, er at give organisationen et system der bedst indfrier deres behov. Ragunath et al.

(Ragunath et al. 2010) påpeger at der under udviklingen af et system først bliver produceret et produkt i den

afsluttende fase af udvikling (Ragunath et al. 2010: 114). Hvilket er det problematiske ved den lineære tilgang,

da organisationen ikke får mulighed for at vide om designet passer ind i konceptet, eller om systemet

eksempelvis kan kommunikere med de andre systemer organisationen gør brug af (Avison & Fitzgerald, 2006:

40). Denne infleksibilitet fører i tilfælde til at systemet bliver afvist af organisationen, da nye forslag til designet

ikke kan implementeres.

Modsat denne tilgang har vi den iterative tilgang, hvor især RAD modellens design fase er relevant at benytte

sig af for en organisation der skal indkøbe et standardsystem (Hass, 2008: 6). Den iterative tilgang er mere

fleksibelt, da der her for udvikleren er mulighed for at tage nye designforslag til sig (Ibid.). RAD modellens

design struktur fungerer i iterationer, således at der i form af en prototype gives et designforslag til

organisationen som de skal evaluere på (Ibid: 7). Falder designforslaget ikke i god jord for organisationen, bliver

et nyt design sendt ud, og denne cyklus fortsættes indtil det rette design er produceret (Ibid.). Et princip i den

iterative tilgang er at organisationen aktivt deltager i udviklingen, da de mange iterationer kræver en del

evaluering fra organisationens side (Coleman & Verbruggen, 1998: 108). Coleman & Verbruggen (Coleman &

Verbruggen, 1998) påpeger at RAD projekter kan fejle, hvis organisationens interagere på et begrænset niveau

(Ibid.). Der bliver endvidere nævnt at der under udviklingen af et system med en RAD tilgang, opnår et dårligt

design hvis udviklingen speedes op (Ibid.), dette kan forekomme i tilfælde hvor organisationen ønsker at få

implementeret et produkt hurtigt.

Testfasen

Følgende afsnit præsenterer forslag til, hvordan man bedst muligt kan teste et system, så det opfylder kundens

behov og samtidig implementeres gnidningsfrit.

For at sikre at kundens behov er opfyldt, vil systemtest tage udgangspunkt i disse, og bruge dem som krav for

at systemet fungerer optimalt. Der er forskellige måder på hvordan, man kan gribe test an. Det afhænger i

første omgang af hvilket system organisationen vil implementere, hvilken virksomhed man arbejder med, og

hvilken struktur de ønsker at implementere systemet efter. Analysen vil tage afsæt i SDLC (Avison & Fitzgerald,

2006: 34) og den iterative metode (Schwaber, 1995: 6).

19


Fælles for de to systemudviklingsmodeller er, at de begge inddrager test, på hver sit niveau (Schwaber, 1995:

5). Hvor SDLC-modellen kun tilgår test i den. 5 fase - implementeringen (Avison & Fitzgerald, 2006: 34).

Sammenlignet med den iterative metode, der tester efter hver iteration (Schwaber, 1995: 6). Det har

selvfølgelig både fordele og ulemper, som vil gennemgås nedenfor.

Som udgangspunkt er det risikabelt først at teste et system, lige inden det implementerers, fordi man

potentielt set kan have overset fejl i de første faser, som får betydelig konsekvenser for systemets endelige

funktionalitet (Avison & Fitzgerald, 2006: 38). SDLC’s måde at systemteste på, møder derfor megen kritik. Som

produkt af kritiken er der udviklet en masse kompenserende testmetoder.

En kritiker af den traditionelle SDLC teststruktur er Eldon Y. Li (Li 1990), som mener at testing af systemet skal

starte samtidig med projektet

“Regardless of the type of development process one may adopt, testing should start as soon as a

project is launched”(Eldon, y 1990: 3).

Li foreslår at man påbegynder test af systemet, samtidig med projektet er igangsat, og løbende tester systemet

indtil det implementeres. Således forsikrer man sig imod at opdage fejl til sidst i implementerings fasen. Li’s

tilgang til måden at teste på, minder meget om Hass’ w-model (Hass 2008: 4), som tilbyder en iterativ

teststruktur i SDLC udvikling. Testene fungerer som gatekeepers, der først tillader påbegyndelse af næste fase,

når testen er godkendt og underskrevet af projektlederen (Li 1990: 3). En lignende teststruktur er præsenteret i

Hass’ W-model, som ligeledes angives som iterative teststrukturer i SDLC.

Ved W-modellen lokalisere man først kravet (i denne sammenhæng kundens behov) til fasen, herefter tester

man om fasen opfylder de opgivede krav, hvis fasen opfylder kravene går man videre til næste fase, hvis ikke,

repareres fejlen og iterationen starter forfra. Ved W-modelen afslutter man altså ikke en fase, før man har

testet fasens resultat, og sikret sig at den opfylder virksomhedens krav (Hass 2008: 5). Ligesom man i følge Li(Li

1990) ikke må påbegynde en fase, før den foregående er testet.

“Only when an SDLC phase is completed and signed off can the next phase proceed” (Li 1990: s. 4)

Li præsenterer en model der eksemplificerer hvordan man kan teste et SDLC systemudviklingsprojekt (Ibid: s.

4). Modellen påviser sammenspillet mellem testfaserne og påviser ligeledes hvilke testmetoder der skal bruges,

for hver enkelt fase. Det er især noterbart at Li(Li 1990) bruger test allerede i den indledende fase, for at sikre

20


sig forståelse for organistaionens behov. Resultaterne fra de første behovstests bruges igen i de sidste faser, til

at dokumenterer at man tester de rette behov.

I de sidste faser af SDLC benytter Li module test (Ibid 1990: s. 4) til at teste seperate moduler af systemet.

Specielt denne test findes brugbar i tilpasning af standardsystemer, da man enkeltvis kan teste hver tilføjelse.

Efter module test eksekveres systemtest (Ibid: s. 5), som tester helheden af systemet. Til slut introduceres user

acceptance (Ibid: s. 5), for at sikre, at brugerne tilgår systemet (Denne test vil gennemgås yderligere i næste

sektion).

Li’s (Li 1990) tilgang til systemtest er en blanding af iterativ og lineær, hvor man bruger skabelonen fra den

lineæremodel, og implementerer iterative tests i hver fase. Denne tilgang optimere risikoen for at

implementere et standardsystem, som ikke opfylder organisationens behov.

Li’s (Li 1990) model fungerer som en god skabelon, for virksomheder der har interesse i en lineær

implementering af et tilpasset standardsystem. Det skyldes at før udvikling af tilføjelserne testes det at man

opfylder organisationens behov, og ligeledes bagefter tester at tilføjelserne fungerer i praksis. Ulempen ved

Eldons model er, at man først tilgår brugertest i implementeringsfasen, ligesom man ikke kan garantere nogen

tidsramme, hvis man skulle sidde fast i den samme iteration. Det kan forøge prisen på systemet og samtidig

udskyde leveringsdatoen.

Derfor kan det være tiltalende for mindre organisationer, at vælge den klassiske SDLC sturktur, hvor man tester

inden implementering, og ikke under udviklingen. Det skyldes at mindre organisationer har mindre økonomisk

kapital og muligvis ikke brug for et tilpasset standardsystem. De vil derfor kunne spare penge, ved først at teste

systemet sidst i forløbet, men samtidig løbe en risci for at implementere et system, der ikke opfylder deres

behov.

Implementeringsfase

Implementeringsfasen indtræder efter testfasen. Det primære fokus under implementering jf. lærebogen s. 34,

er oplæring af personale, tilpasning til ældre systemer og fremtidssikring i form af opdateringer. Vi mener der

er flere aspekter i implementeringsfasen, hvor det primære fokus vil ligge på brugerne af systemet, og på at få

dem til acceptere og bruge systemet. Hvis vi tager afsæt i foregående afsnit, har organisationen nu testet

standardsystemet (og dets tilføjelser), og fået bekræftet at systemet er funktionelt og fungerer efter

virksomhedens behov. Nu gælder det for organisationen om at få deres brugere til at acceptere og benytte

systemet. Der er flere udfordringer herunder, og flere måder på hvordan man kan få brugerne til acceptere

21


systemet. Følgende afsnit vil belyse nogle af de udfordringer der findes ved at implementere et nyt system, og

hvordan man kan løse dem.

“...many technochange solutions simply cannot be adopted and used easily or at all, because they conflict

with existing organizational structures, cultures, or practices.” (Markus et al. 2004: 16).

Ifølge Markus et al. (Markus et al. 2004) skal man altså være opmærksom når man implementerer nye IT-

systemer, fordi nye IT-systemer oftest radikalt ændrer organisationens strukturer, kultur og arbejdspraksisser.

Derfor skal man sikre sig brugernes accept af systemet, inden man endeligt implementerer det. Så man undgår

at brugerne afviser systemet, eller ikke bruger det optimalt og derved øger udgiften ved systemet.

En måde hvorpå man kan øge brugernes accept ved det nye system, er ved at lave acceptance test

(Hass 2008: 15), hvor man inddrager brugerne til at teste systemet.

“... the product is expected to be working and it is presented for acceptance” (ibid: 15)

Acceptance testing mindsker risikoen for, at brugerne vil afvise systemet når det bliver implementeret, fordi de

er blevet en integreret del af systemudviklingen og implementeringen. Samtidig får brugerne kendskab til

systemet, og får derved lettere ved at bruge systemet når det endeligt implementeres. Markus præsenterer en

lignende tilgang til brugeraccept af IT-systemer, hvor man via brugertest modultester systemet. Hver modultest

bragtes som en iteration, hvor man først går videre til den næste iteration, når brugerne har accepteret og

godkendt modulet af systemet (Markus et al. 2004: 14). Under brugertestene har man ligeledes mulighed for at

opdage, hvilke problemer/ulemper brugerne ser ved det nye system, og komme disse til livs inden det

implementeres. Fordelen ved modul testene, er at man kan langsomt implementere modulene ind i

virksomheden, og dermed skabe en glidende implementering fra et system til et andet. En ulempe ved denne

form for brugeraccept, er at der ikke stilles nogle garantier for at brugerne er omstillingsparate, og altså ingen

garanti for at brugerne vil adoptere det nye system. Det skyldes at brugerne kan frygte forandring og

omstilling, beskrevet som “resistance to change” (Ibid: 14).

Der findes derfor andre strategier organisationen kan bruge, for at gøre op med resistance to change. En kendt

strategi er the burning platform (Daley 2010: 117). Som presser brugerne til at ændre adfærd, og i vores

tilfælde adoptere et nyt IT-system.

22


“... All the involved parties would align together to move forward, leaving behind the conflicts and self-

interest standing in the path of change” (Daley 2010: 117)

Virksomheden behøver nødvendigvis ikke være på vej mod konkurs, før man benytter the burning platform

strategien, men ideen er at skabe en illusion om, et så ekstremt scenarie at brugerne vil gøre sig

omstillingsparate. Et eksempel herpå kunne f.eks. være en konkurs. Man skaber altså en frygt faktor, der får

alle organisationens brugere til at omstille sig i frygt for - eksempelvis organisations konkurs.

The bruning platform strategi vil ikke virke i en Socialkonstruktivistisk organisation (Howcroft and Light 2010:

123) , der har behov for en implementering der bygger på brugernes valg og fravalg, hvor iterative brugertest

mere vil være brugbare, fordi brugerne skaber fundamentet for systemet.

Hvis organisationen ønsker en lineær og mere rapid implementering, kunne the burning platform strategien

være en mulighed. Her er risikoen selvfølgelig at man skaber et dårligt arbejdsmiljø, og underlægger brugerne

et system, uden at inddrage dem i processen, og dermed ikke kan vide om de finder systemet brugbart.

Tilgengæld opnår man en hurtigt adoption af systemet, og sparer dermed en betydelige mængde resourcer.

Opfølgningsfase

Umiddelbart efter at systemet er implementeret og virksomhedens behov er opfyldt, følger opfølgningsfasen

hvor man fokuserer på vedligeholdelse og opdatering af systemet (Avison & Fitzgerald, 2006: 35). Her er vil

organisationen have forskellige muligheder, afhængigt af deres behov til systemet, og organisationens

arbejdsstruktur.

Organisationer der har implementeret et system udfra en SDLCmetode, vil højest sandsynligt benytter sig af

SDLC til opfølglingsfasen. Dvs, at virksomheden der har leveret standardsystemet, står for opdatering og

support. Ligesom de ud fra deres studier, vil vurdere hvornår organisationen har brug for et nyt system (Avison

& Fitzgerald, 2006: 35).

En organisation hvis organisationsstruktur er mere i bevægelse, og som konstant udvider sig, har i højere grad

brug for en mere iterativ løsning, hvor man konstant arbejder på udvide og forbedre systemet (Schwaber: 7). I

forhold til opfølgningsfasen tages der udgangspunkt i organisationens behov og struktur for derefer at

konkludere hvilken opfølgnings strategi organisationen skal vælge.

23


Delkonklusion

Opsamlende kan det ud fra ovenstående afsnit kan det konkluderes at en udviklingen af et standardsystem

kræver et tæt samarbejde mellem organisation og udvikler (Avison & Fitzgerald, 2006: 175) i den indledende

fase. Derfor er det vigtigt at organisationen sætter nogle præcise krav til de behov de ønsker dækket. Her kan

det være relevant at anvende SDLC modellen (Avison & Fitzgerald, 2006: 33), da udviklingen af et

standardsystem indledes ved at udvikleren laver en række undersøgelser, for at fastsætte de problemer det

tidligere system havde (Ibid). Denne fastsættelse af problemer, giver udvikleren mulighed for at identificerer og

dække organisationens behov og krav (Ibid: 34) i et nyt system. Vælger man eksempelvis at foretage justeringer

med denne lineære tilgang, kan det have omkostningsfulde og tidskrævende konsekvenser (Ragunath et al.

2010: 114). Denne tilgang kan sættes i modsætning til anvendelsen af den iterative tilgang, hvor fleksibiliteten

er med til at give udvikleren mulighed for nemt at kunne foretage justeringer i de iterative faser (Ibid.).

Derudover giver den iterative tilgang, udvikleren mulighed for at udlevere en prototype til organisationen i

designfasen, som de kan evalurere på (Hass, 2008: 7). Ved den iterative tilgang findes der tilgengæld en risiko

for, at sidde fast i en iteration, hvis organisationen ikke er tilfreds med iterationens resultater jf. Li (Li 1990: 4).

Ved implementering af standardsystemer er der præsenteret en iterativ- og lineær tilgang, til at hjælpe

organisationerne implementere et nyt system. Ved den iterativetilgang er ‘user acceptance tests’ (Hass 2008:

15) brugt til skabe accept af det nye system. Ved den lineæretilgang er der præsenteret the burning platform

strategien, der opstiller det “skræmmescenarie” der omstiller brugerne af systemet, til at adoptere det nye

system (Daley 2010: 117). Sidst er der tage højde for lineær og iterativ system opfølgning. Den iterative

opfølglings strategi er perspektiveret til organisationer, som strukturelt er i bevægelse og konstant udvikling,

mens den lineære sættes i sammenspil med organisationer der har en lineær organisationsstruktur, og ikke i

lige så høj grad har brug konstante tilføjelser af systemet.

Det er altså påvist at elementer og strukturer fra både SDLC/vandfaldsmetoden og iterative

systemudviklingsmetode, kan implementeres ved valg, udvikling og implementering af et standardsystem. Som

udgangspunkt skal behovsanalysen danne grobund for, hvilken metode og strategi, der skal anvendes inden

man påbegynder projektet.

24


Spørgsmål 4.

I det følgende afsnit vil vi redegøre for vores litteratursøgningsproces og –valg samt lave en kritisk analyse af

vores supplerende litteratur.

Vores valg af supplerende litteratur til besvarelsen af opgavespørgsmålene, har taget afsæt i en både kritisk og

supplerende vinkling af vores felt. Den supplerende vinkling bruges i opgaven til at supplere kursuslitteraturen,

for at give opgaven et mere nuanceret billede af de modeller vi har anvendt. Hvorimod den kritiske vinkling

kritiserer det inddragede litteratur fra undervisningen, og skaber en modpol til de argumenter der angives i

opgaven. Et eksempel på en kritisk vinkel på kursuslitteratruen er anvendelsen af Ragunath et al. (Ragunath et

al. 2010), der sætter sig kritisk op imod SDLC modellen (Avison & Fitzgerald, 2006: 31). Den kritiske tilgang til

den lineære model bliver argumenteret ved, at der i modellens proces ikke tages hånd om problemer som

‘Ændringshåndtering’, ‘Hændelseshåndtering’, og ‘Udleveringshåndtering’ (Ragunath et al. 2010: 112).

Ragunath et al’s (Ragunath et al, 2010) kritik af SLDC modellen giver os et kritisk indblik i SDLC modellen, som vi

bruger til at vurdere SDLC modellens anvendelse ved valg af standardsystemer.

I vores litteratursøgning indenfor offshoring med en ekstern leverandør, anvendte vi Carmen & Tjia’s tekst

(Carmen & Tjia, 2006) om de kommunikationsmæssige fordele der ligger i at “offshore”, da Avison & Fitzgerald

kun overfladisk beskrev det. For at nuancere Carmen & Tjia’s argument, inddragede vi Pedersen et al’s

(Pedersen et al, 2013) tekst, som pointerede at det ikke var en entydig forudsætning, men at organisationen

bør besidde de teknologiske ressourcer for selv at kunne varetage styringen af en udenlandsk leverandør. På

den måde har vi brugt supplerende litteratur til at gå mere dybdegående ind i hvilke “offshoring”-perspektiver

der er for organisationen.

Det supplerende litteratur er blevet søgt ved at sætte fokus på, at pointere hvilke fordele og ulemper der er

ved de forskellige systemudviklingsmetoder. Derfor har vi fundet det enormt vigtigt, at det supplerende

materiale er af akademisk karakter, netop for at skabe et sagligt udgangspunkt for litteraturen. Vores tilgang til

litteraturen skaber dermed en kritiske vinkling på hele opgaven, og derved også en kritisk vinkling på hvilke

systemudviklingsmetoder der kan være relevant at anvende for en organisation der skal indkøbe et

standardsystem. Dermed ikke forstået som at vores kritiske vinkel er entydig for hvilke fordele/ulemper der er

ved at indkøbe et standardsystem, men at organisationer netop skal forholde sig kritisk til diverse teorier

angående modellering og systemudvikling.

25


Konklusion

Af ovenstående eksamenopgave kan det konkluderes, at der forefindes en række forhold der skal tages højde

for, når en organisation enten selv vælger at købe et standardsystem, få en ekstern leverandør til at udvikle it-

systemet, eller selv vælger at udvikle et it-system. De væsentlige forhold der skal tages højde for i købet af et

standardsystem, er såfremt organisationen ikke har volumen og ressourcer til at specialudvikle, selv at udvikle

eller hvis systemet ikke behøver være så kompliceret. Her er Lauesens (Lauesen, 2007) udførlige

kravspecifikation samt Stefanous (Stefanou, 2001) bud på en behovsanalyse i den indledende fase, et godt bud

på hvordan en økonomisk begrænset SME imødekommer disse forhold.

Forholdene for en organisation som vil specialudvikle sit it-system via en ekstern leverandør, kan adskille sig

ved at organisationen ønsker et mere kompliceret/skræddersyet system eller ved at organisationen har et lille

forretningsområde, som gør at et standardsystem ikke kan opsættes til at imødekomme behovet. Yderligere

har vi brugt Carmen & Tjia (Carmen & Tjia, 2005) og Pedersen et al (Pedersen et al, 2013) til at udlede, at

teknologiske og ledelsesmæssige kompetencer er en forudsætning, for at kunne styre en ekstern leverandør i

udviklingen af et billigere system via offshoring på tværs af landegrænser.

Et afgørende forhold at tage afsæt i når en organisation selv udvikler et it-system, er som Grant et al (Grant et

al, 2010) påpeger det, at organisationen er “emergent” i sin måde at arbejde og drive virksomheden på. På den

måde kan det dynamiske arbejdsmiljø være med til at understøtte at forbedre, tilpasse og vedligeholde et unikt

system. Endvidere påpeges det af Truex et al (Truex et al, 1999), at en nødvendig forudsætning er at

organisationen besidder egen it-afdeling med en stor volumen.

Med analysen af de udfordringer der er ved anvendelsen af de forskellige typer af systemudviklingsmetoder,

når en organisation vælger at få en ekstern leverandør til at udvikle et it-system til sig. Kan vi konkludere at når

man skal have en ekstern leverandør til at udvikle et it-system er det vigtigt at tage højde for de behov som

organisationen har. Der er ikke én metode som er bedre end de andre, men de har hver deres styrker og

svagheder. Hvis organisationen vælger en metode som dækker deres behov på en effektiv måde. Hvis

organisationen har et fastsat budget og tidsramme kan det være relevant at bruge den sekventielle metode

(Hass, 2008:3), da man kan fastsætte både budget og tidsramme i den indledende planlægning. Har

organisationen brug for et specialudviklet it-system bør man kigge mere mod de iterative (Hass, 2008:4) og

26


agile metoder (Avison & Fitzgerald, 2006:134), da der er plads til justeringer af it-systemet og man kan have

mere bruger/kundeinddragelse med ind over hele systemudviklingen.

Ved analysegennemgangen af hvordan de forskellige systemudviklingsmetoder kan være relevante at anvende

for en organisation, der vælger at købe et standardsystem, er vi kommet frem til at udviklingen af et

standardsystem bør indledes med en behovsanalyse, som skal give udvikleren mulighed for at identiificere de

behov og krav organisationen har til det system de ønsker at købe. Denne behovsanalyse skal kunne fungere

som en skabelon for udvikleren, så man efterfølgende kan gå tilbage i en hvilken som helst fase, og fastlægge

en struktureret plan for hvordan resten af projektet skal forløbe.

Den supplerende litteratur er søgt på baggrund af en kritisk vinkling, hvor vi både har søgt at præsentere

kritiske teorier til kursuslitteraturen samtidig med at vi har supplerende litteratur til de teori vi ikke fandt

uddybet nok fra kursuslitteraturen. Det giver opgaven et både kritisk og nuanceret indblik, i de udfordringer og

muligheder en organisation står overfor hvis de ønsker at købe et nyt IT-system.

27


Litteraturliste:

Avison, D. & Fitzgerald, G. (2006). Information Systems Development. McGraw-Hill, London 2006 (4th edition).

Batalden, P., Daley, J., Deyo, R. Edwards, W. “Lessons learned in changing healthcare. Chp. 9: Leading on a Burning Platform." Longwoods publishing corporation (2010): 117-134

Boehm, Barry W. (1988). "A spiral model of software development and enhancement." (1988)

Carmen, E. & Tjia, P.: “Offshoring information technology: sourcing and outsourcing to a global workforce”, Cambridge, 2005, pp. 160-166

Craig, P., Caldeira, M. & Ward, J. “Organizational information systems competences in small and medium-

sized enterprises”, University of Canterbury, New Zealand, ISEG, Portugal c Cranfield University, UK, 2011, pp

353-363

Coleman, Gerry, and Renaat Verbruggen. "A quality software process for rapid application development." Software Quality Management VI. Springer London, 1998. 241-259.

Grant, K., Hackney, R. and Edgar, D. “Strategic Information Systems Management”, Cengage Learning Emea,

2010, pp. 70-75

Hass, Anne Mette Jonassen (2008): Guide to Advanced Software Testing (Artech House, Norwood, 2008, ISBN 1596932856). Side 1-22.

Howcroft, D. & Light, B. (2010): The Social Shaping of Packaged Software Selection. Journal of the Association for Information Systems, 11, 2.

Keil, M. and Tiwana, A. "Relative importance of evaluation criteria for enterprise systems: a conjoint study" Information Systems Journal, (16) 2006, pp 237-262.

Lauesen, Søren: Vejledning til kravskabelon SL-07 (Samfundslitteratur, København, 2007). Findes på www.itu.dk/~slauesen/Papers/KravskabelonSL-07.doc

Li, Eldon Y. "Software testing in a system development process: A life cycle perspective." Journal of Systems Management (1990): 23-31. (S. 10

28


Markus, M.L., and Tanis, C. "The Enterprise System Experience - From Adoption to Success," in: Framing the Domains of IT Research: Glimpsing the Future Through the Past, R.W. Zmud (ed.), Pinnaflex Educational Resources, Cincinnati, 2004, pp. 173-207.

Markus, M.L., Axline, S., Petrie, D., and Tanis, C. "Learning From Adopters' Experiences with ERP: Problems

Encountered and Success Achieved," Journal of Information Technology (15:4) 2000, pp 245-265.

Pedersen, T., Bals, L., Jensen, P. and Larsen, M.: “The offshoring challenge” Springer-verlag London, 2013, pp. 4-14

Ragunath, P. K., Velmourougan, S., Davachelvan, P., Kayalvizhi, S., & Ravimohan, R. "Evolving a new model (SDLC Model-2010) for software development life cycle (SDLC)." International Journal of Computer Science and Network Security (2010): 112-119.

Schwaber, Ken (1995): Scrum Development Process. OOPSLA '95. Workshop on Business Object Design and Implementation. (Springer-Verlag, New York, 1995)

Sherer, S.A. "Purchasing Software Systems: Managing the Risk," Information and Management (24:5) 1993, pp 257-266.

Stefanou, C.J. "A Framework for the Ex-ante Evaluation of ERP Software," European Journal of Information

Systems (10:4) 2001, pp 204-215

Truex, D., Baskerville, R. & Klein, H. (1999): Growing systems in emergent organizations.

Communications of the ACM, 42, 117-123.

29

MOS eksamen uuuh.docxmadebyfm.dk/.../uploads/2015/05/MOSeksamenuuuh.docx · Web viewMed afsæt i de...

Documents

Transcript of MOS eksamen uuuh.docxmadebyfm.dk/.../uploads/2015/05/MOSeksamenuuuh.docx · Web viewMed afsæt i de...