Systemudviklingsmetoder & Webapplikationer

Systemudviklingsmetoder & Webapplikationer - et studie af Extreme Programming Speciale af: Rasmus Jørgensen Tim Priergaard Rasmussen Kristian Fischer Vejledere: Peter H. Carstensen Lars B. Pedersen IT-højskolen i København 1. november 2002 - i -

Systemudviklingsmetoder & Webapplikationer et studie af Extreme Programming Copyright 2002 R. Jørgensen, K. S. Fischer & T. P. Rasmussen IT University of Copenhagen Forside illustration - Planning Game for denne afhandling One many may hit the mark, another blunder; but heed not these distinctions. Only from the alliance of the one, working with and through the other, are great things born. Antoine de Saint-Exupery 1900-1944 - ii -

1 Abstract Through the past 30 years, numerous methods have been developed in the effort to cope with the increasing number of demands in the development of IT systems. Contemporary research has identified a need for developing new practices compared to the traditional waterfall approaches and heavy processed methods. These new practices and demands become particularly relevant when developing advanced web applications (AWAs). With the coming of The Agile Alliance, powerful and versatile methods have emerged into the world of software development. These agile processes emphasise on a number of key concepts: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contact negotiation and responding to change over following a plan. Especially the agile method Extreme Programming (XP) appears to have attained considerable recognition. The current thesis examines XP s ability to stand up to the number of demands discussed in the literature and found through our empirical studies in three Danish IT-companies when developing advanced web applications (AWAs). Our findings suggest that XP - in many ways - meets the demands of AWA development today. We have, however, found that XP still needs some features before all demands discussed in the literature and found through empirical studies are met. These features are discussed and solutions are offered in a modified version of XP, which we name XP #. The features among others include a need for a more detailed recipe when the development team consists of qualifications not related to XP programming, e.g. web designers and user interface experts. The XP cookbook is short of a few recipes and consequently, the team is left to its own devices and experience. The thesis concludes that XP and agile methods in general are an improvement when developing AWAs compared to traditional waterfall approaches and heavy processed methods. - iii -

Indholdsfortegnelse 1 Abstract i 2 Forord 1 3 Indledning 2 4 Læsevejledning 6 5 Genstandsfelt 8 6 Definitioner og afgrænsning 31 7 Extreme Programming (XP) 39 8 Metode 48 9 Analyse 64 10 XP # 99 11 Konklusion 109 12 Perspektivering 112 13 Litteraturliste 120 - iv -

Detaljeret Indholdsfortegnelse 1 Abstract i 2 Forord 1 3 Indledning 2 4 Læsevejledning 6 4.1 Hvad kendetegner generelt en indkøbstur? 6 4.2 Hvad kendetegner vores indkøbstur? 6 4.3 Afhandlingens opbygning 7 5 Genstandsfelt 8 5.1 Webapplikationer 8 5.1.1 Først-til-marked 10 5.1.2 Flydende og foranderlige krav 10 5.1.3 Udvikling af prototyper 11 5.1.4 Hyppige udgivelser 11 5.1.5 Paralleludvikling 11 5.1.6 Fast arkitektur 12 5.1.7 Tidlig kodning 12 5.1.8 Kvalitetsforhandling 13 5.1.9 Gode medarbejdere 13 5.1.10 Opsummering 13 5.2 Systemudvikling 14 5.3 Systemudviklingsmetoder og -modeller 17 5.3.1 Vandfaldsmodellen 5.3.2 RAD 20 22 5.3.3 Spiralmodellen 23 5.3.4 RUP 25 5.3.5 ASD 28 5.3.6 XP 29 5.3.7 Opsummering 30 6 Definitioner og afgrænsning 31 6.1 Problemformulering 31 6.2 Definition af nyetablerede systemudviklingsmetoder 32 6.2.1 Valg af XP som case 32 6.3 Definition af det rette valg 34 6.4 Definition af udvikling 35 6.5 Definition af avancerede webapplikationer 35 6.5.1 WIS Web Information Systems 36 6.5.2 IWA Interactive Web Applications 6.5.3 AWA er Avancerede Webapplikationer 36 37 6.6 Opsummering 38 7 Extreme Programming (XP) 39 7.1 Programmering i XP 40 7.2 Udviklerholdet i XP 40 - v -

7.3 Processer i XP 40 7.4 Dogmer i XP 40 7.4.1 Planning Game 40 7.4.2 Hyppige releases, korte iterationer 41 7.4.3 Metafor 41 7.4.4 Enkelt design 41 7.4.5 Refaktorering 42 7.4.6 Parprogrammering 42 7.4.7 Test 42 7.4.8 Fælles kodeejerskab 43 7.4.9 Løbende systemintegration 43 7.4.10 37 timers arbejdsuge 43 7.4.11 Kundetilstedeværelse 44 7.4.12 Kodestandarder 44 7.5 Fire værdier 44 7.6 Procesoverblik 45 Opsummering 47 8 Metode 48 8.1 Vidensproduktion 48 8.2 Hermeneutik 50 8.3 Forskningsdesign 51 8.4 Empirisk dataindsamling 54 8.4.1 Primær empiri 56 8.4.2 Sekundær empiri 58 8.5 Behandling af datagrundlaget 58 8.6 Kvaliteten af forskningen 60 8.6.1 Re liabilitet vurdering af projektets pålidelighed 8.6.2 Validitet vurdering af projektets gyldighed. 60 62 9 Analyse 64 9.1 Introduktion til analyse 64 9.2 Datamatrix 64 9.3 Empirisk identifikation af problemområder 65 9.3.1 Test 67 9.3.2 Kompetencediversitet 71 9.3.3 Projekter vs. Standardsoftware 74 9.3.4 Implementering af XP 76 9.3.5 Kundetilstedeværelse 82 9.3.6 Slutbrugere 84 9.3.7 Estimater - Fixed Scope kontrakter vs. Flexible Scope kontrakter 87 9.3.8 Resterende temaer 91 9.4 Analyseopsummering 93 9.4.1 Generelle betragtninger 95 10 XP # 99 10.1 Udvidelse af XP 99 10.2 Interaktionsdogmet det trettende dogme 103 10.3 Gyldigheden af XP # 108 - vi -

11 Konklusion 109 12 Perspektivering 112 12.1 Fremtidsperspektiver 112 12.2 Refleksion 112 12.2.1 Teoretisk vs. praktisk speciale 12.2.2 Datagrundlag 112 113 12.2.3 Interviewguides 12.2.4 Forskningsdesign 113 113 12.3 XP som arbejdsproces 114 12.3.1 Planning Game 115 12.3.2 Kunden er altid tilstede 117 12.3.3 Korte iterationer, hyppige releases 117 12.3.4 Metafor 117 12.3.5 Enkelt design 118 12.3.6 Parprogrammering 118 12.3.7 Kode-kommunisme, fælles dokumentejerskab 118 12.3.8 Kontinuerlig integration 118 12.3.9 Kodestandard 118 12.3.10 Automatiske tests 118 12.3.11 Refaktorering 118 12.3.12 37 timers arbejdsuge 119 12.4 Opsumme ring 119 13 Litteraturliste 120 13.1 Primær litteratur 120 13.2 Sekundær litteratur 125 - vii -

2 Forord Denne afhandling afspejler seks måneders specialearbejde på kandidatuddannelsen ved IThøjskolen i København under linien Tværfaglig IT Udvikling. Vores interesse for at beskæftige os med systemudviklingsteori og webapplikationer udspringer af to tidligere projekter omhandlende udarbejdelsen og programmeringen af større applikationer til Internettet. I disse forløb har vi dels erfaret at det er svært at formulere kravene, begrænse kravene og strukturere processen, og dels at det stress dette medfører er dybt problematisk under selve programmeringen, men også i forhold til de endelige produkter. Vi har derfor ønsket at lære og forstå de værktøjer man kan gøre brug af for at afhjælpe disse problemer, men samtidigt også gøre os klart om der er særlige hensyn at tage når der netop udvikles webapplikationer. Specialet udspringer altså af vores erfaringer, erkendelser og interesser opstået gennem vores uddannelsesforløb på IT-højskolen. Udgangspunktet er derfor ideelt i en betragtning af, at et speciale skal afspejle en syntese af ens videnskabelige formåen og samtidigt være nærværende og relevant for os som studerende og for det genstandsfelt, der er i søgelyset. Vi har ikke tidligere arbejdet indenfor så litteratur- og teoritungt et felt, og det har været en konstant udfordring at overskue de mange forskellige data og input. Vi ville dog aldrig være kommet så langt foruden følgende personer som vi ønsker at rette en stor tak til. Vores informanter: Ole Rasmussen og Thim Otskov på Intentia ecommerce, Morten Sørensen på Speakanet og Torben W. Graversen på Accentures sundhed.dk for beredvilligt at stille deres viden til rådighed. Vores vejledere: Peter H. Carstensen for at være god til vejlede os i at forstå den proces det er at udvikle en videnskabelig afhandling samt at hjælpe os videre med at tænke over forskningsdesign og struktur. Lars Bogetoft Pedersen for at gennemlæse og kommentere vores skriftlige fremstilling samt provokere til nye ideer og indgangsvinkler. God fornøjelse! Tim Priergaard Rasmussen, Kristian Suomala Fischer & Rasmus Jørgensen - 1 -

3 Indledning AFSNITTET GIVER ET OVERORDNET INDBLIK I SPECIALETS FOKUS OG BESKRIVER HVILKE MÅL, DER ØNSKES OPNÅET GENNEM SPECIALEARBEJDET. Software er en stadig voksende del af vores hverdag og dens betydning giver grobund for mange spekulationer omkring måden hvorpå softwaren skal udvikles (MacCormack 2001). Alene i Danmark har vi set talrige eksempler på softwareprojekter i millionklassen, der har været forsinkede, har overskredet budgettet eller ikke levet op til brugernes og kundernes forventninger. Tag for eksempel de meget omdiskuterede offentlige projekter Amanda, EASY og VUE, der alle overskred budgettet med mellem 10 og 100%, og overskred leveringstiderne med op til fire år. En arbejdsgruppe bestående af en række personer med særlig indsigt i problemstillingen (Teknologirådet 2001:1) blev i 2000 nedsat for at finde frem til hvorfor det var gået så galt for projekterne. En af deres konklusioner var bl.a. at der i mange tilfælde har været mangel på en metode for projektstyring (Teknologirådet 2001) 1. Ydermere påpeger forskellige forskere at omkring 60 procent af dagens softwareprojekter kører uden en etableret systemudviklingsmetode (Astels et al. 2002). Når virksomheder skal udvikle et softwaresystem, er det vigtigt at der er tænkt over hvilken systemudviklingsmetode der skal bruges til projektet, om den er relevant, og at denne metode bliver fulgt (Korsaa et al. 2001). Med softwareapplikationernes konstante videreudvikling er det hensigtsmæssigt at systemudviklingsmetoderne følger med i samme tempo (MacCormack 2001, Baskerville et al. 2001). Som effekt af dette er der siden den første metode kom frem for mere end 30 år siden, dukket et væld af systemudviklingsmetoder op - nogle mere succesfulde end andre (Korsaa et al. 2001). Formålet med systemudviklingsmetoder kan siges bl.a. at være at producere et kvalitetsmæssigt bedre produkt hurtigere (Korsaa et al. 2001). Under begrebet kvalitet gemmer sig en række parametre, f.eks. om systemet lever op til kundens forventninger eller om systemet lever op til kravspecifikationen m.v. som man må gøre sig klart når man begynder at udvikle systemer 2. Kravet om et hurtigt udviklet og kvalitetsmæssigt godt produkt har fået mange softwarevirksomheder til at begynde at udvikle Internetbaserede produkter på Internet Tid (eng: Internet Speed), hvilket vil sige at produkterne til Internettet udvikles ligeså hurtigt som Internettet udvikler sig (MacCormack 2001, Baskerville et al. 2001). Udviklingen af webapplikationer er således udsat for et konstant tidspres og til stadighed stigende kvalitetskrav fra rekvirenterne om at udnytte de nyeste teknologier 1 Eksemplerne er udelukkende offentlige projekter. Det hænger ikke nødvendigvis sammen med at de er mere fejlslagne end ikke-offentlige, men primært at de offentlige er mest dokumenterede. 2 I afsnit 5.1.8 vil vi komme nærmere ind på kvalitetsbegrebet. - 2 -

(Carstensen et al. 2001, Baskerville et al. 2001). Således vil mange af de klassiske systemudviklingsmetoder ikke være tilstrækkelige i udviklingen af webapplikationer (Baskerville et al. 2001). Der er herigennem opstået et behov for nytænkning indenfor systemudvikling i virksomheder som udvikler webapplikationer. Dette behov er efterhånden blevet åbenlyst flere steder, og flere modeller og metoder, der mener at tilbyde varen i form af nyskabende systemudviklingsmetoder og redskaber, er efterhånden dukket op i et utal af varianter (f.eks. XP, ASD og RUP). Mange af disse metoder er dog så nye, at der endnu ikke foreligger tilstrækkeligt med empirisk materiale til at underbygge disse metoders effekt på det realiserede produkt (MacCormack 2001). Der er stor forskel på om man udvikler livskritiske 3 systemer til hospitaler eller systemer til internethandel. Livskritiske systemer må ikke indeholde fejl, mens det i andre systemer ikke nødvendigvis er livstruende, at der findes fejl. Når man derfor snakker om at systemudviklingsmetoder ikke er tilstrækkelige i udviklingen af softwareprodukter, er det vigtigt bl.a. at definere hvilken form for system man snakker om. I denne afhandling ønsker vi at tage udgangspunkt i applikationer til Internettet. I de seneste år har udviklingen af applikationer til Internettet bevæget sig fra at være simple samlinger af HTML-sider til større interaktive webapplikationer (Isakowitz et al. 1998). Med udviklingen af teknologier og anvendelsen af disse, bliver webapplikationer ikke blot applikationer der informerer, men avancerede systemer, hvor brugerne i højere grad har indflydelse på indholdet samt stiller krav til funktionalitet og design. Desuden er udviklingen af disse systemer blevet forretningskritiske, i den forstand at applikationerne ikke udelukkende udvikles til at effektivisere og teknologisere, men samtidigt implementeres for at varetage marketingselementer eksempelvis ved at formidle producentens varemærke. Dette har på det seneste skabt fokus indenfor feltet systemudvikling af webapplikationer. Hastigheden hvormed webapplikationer har udviklet sig og etableret sig i IT-industrien har som nævnt bevirket at systemudviklingsmetoderne indenfor dette område ikke i tilstrækkeligt grad er taget op til overvejelse og refleksion i de sammenhænge, hvor der udvikles avancerede systemer til Internettet. 3 Her mener vi at man kan dø som følge af en fejl i systemet. Systemer til Internethandel kan ligeledes være livskritiske, men udelukkende set i forhold til at virksomheden i værste fald må lukke. - 3 -

På baggrund af ovenstående finder vi det derfor spændende at undersøge: Hvorvidt nyetablerede systemudviklingsmetoder er det rette valg ved udvikling af avancerede webapplikationer (AWA er)? For at besvare denne meget overordnede problematik er det nødvendigt først at gøre sig klart hvad vi mener med begreberne nyetablerede systemudviklingsmetoder, det rette valg, udvikling og avancerede webapplikationer (AWA er). Vi vil i et særskilt afsnit (jf. 6 Definitioner og afgrænsning) uddybende argumentere for vores definition af disse begreber. Den skitserede problematik lægger op til en meget bred og omfattende undersøgelse, såfremt vi skulle undersøge alle de af os definerede nyetablerede systemudviklingsmetoder. Derfor vælger vi at fokusere på en specifik systemudviklingsmetode, Extreme Programming (XP). Vi vælger XP som systemudviklingsmetode, da den som metode bl.a. inddrager mange af de best practices, man ser i andre metoder, men som ikke før er blevet samlet og brugt i så ekstrem grad. Umiddelbart ser XP også mest lovende ud, når bl.a. udviklingshastigheden er en kritisk faktor. XP var desuden en af de første af nu mange systemudviklingsmetoder, der går under betegnelsen adrætte metoder (AgileAlliance 2002). Man har erkendt at kravene til et givent produkt ændrer sig løbende og der herigennem skabes et behov for være adræt/smidig, således at man hurtigt og let kan ændre i produktet så det opfylder nye krav og behov. Vi vil i et særskilt afsnit (jf. 6.2.1 Valg af XP som case) argumentere for vores valg af XP som case samt udforske XP (jf. 7 Extreme Programming) som metode udfra den omfattende litteratur. Udover at forholde os til litteraturen, vil vi undersøge om XP er det rette valg ved udviklingen af AWA er, ved at interviewe tre personer i to systemudviklingshuse, der udvikler AWA er ved hjælp af XP. De to huse benytter sig af XP på to forskellige grundlag, idet det ene udvikler standardprodukter (produktudvikling) mens det andet udvikler innovative produkter (projektudvikling). Derudover interviewer vi en person i en tredje virksomhed, der udvikler AWA er, men ikke bruger XP som metode. Vi sammenholder interviewene med hinanden og litteraturen, og igennem en omfattende analyse vil vi kommentere vores konklusioner og bidrage med nogle forslag til forbedring af XP. Vores konklusioner i forhold til XP sættes i kontekst med vores overordnede problemformulering og vi konkluderer om nyetablerede systemudviklingsmetoder er det rette valg ved udvikling af AWA er, velvidende at vi naturligvis kun kan give forsigtige bud på konklusioner, idet vi kun arbejder udfra en enkel metode, et begrænset antal undersøgelser samt litteraturen. Vi mener dog stadig at vi kan diskutere nogle tendenser for AWA-udvikling i forhold til etablerede og især nyetablerede systemudviklingsmetoder. - 4 -

Vi har valgt at udarbejde specialet ved hjælp af XP s principper, hvilket vi vil beskrive i perspektiveringen (jf. 12 Perspektivering). Dette afsnit vil ligeledes beskrive og diskutere vores læringsmål indgående samt vurdere hvad vi har gjort godt og hvad vi kunne have gjort bedre. Afhandlingen giver et godt indblik i problematikken omkring udviklingen af stadig mere avancerede webapplikationer i et hastigt voksende marked, hvor parametre som økonomi, tid og opfyldelse af behov har enorm betydning og fokus. Vores mål med specialet er at tilegne os viden indenfor et omfattende, men yderst interessant område, som vi alle tre finder inspirerende og herigennem give vores bidrag til forskningen på området. Desuden omfatter vores læringsmål at tilegne os viden og benytte denne i forhold til indsamlet empiri via interviews og danne konklusioner på denne baggrund, samt at kunne samarbejde med andre i pressede og stressede situationer i seks måneder og alligevel få et godt resultat ud af anstrengelserne. - 5 -

4 Læsevejledning AFSNITTET BESKRIVER AFHANDLINGENS OPBYGNING VED HJÆLP AF EN METAFOR. Som nævnt i indledningen har vi i den sidste periode af nærværende specialearbejde forsøgt at arbejde indenfor XP s principper. Det betyder at vi har tilpasset XP s 12 dogmer til den situation at skrive en afhandling som denne. Et af de 12 dogmer kaldes Metafor og indebærer at man i udviklingsprocessen kommunikerer om teknikker og opgaver udfra en abstrakt, men repræsentativ tanke. Vi har gennem arbejdet med denne afhandling arbejdet udfra metaforen Indkøbstur i et supermarked, og vi vil med følgende læsevejledning gennemgå de enkelte afsnits indhold udfra denne tanke. For at forstå metaforen må vi først beskrive, hvad der kendetegner en indkøbstur. 4.1 Hvad kendetegner generelt en indkøbstur? En typisk indkøbstur kan forløbe på to overordnede faconer. 1) Man kan have en indkøbsseddel med, gå ind i supermarkedet og købe de ting der står på denne. Måske vil man falde over varer der ikke står på indkøbslisten, måske ikke. Eller 2) man kan gå ind i supermarkedet med en helt overordnet ide om hvad man har lyst til og derefter lade sig inspirere af supermarkedets varesortiment. Derudover kan man principielt set sige at enhver indkøbstur i supermarkedet følger disse elementer: Man vælger en vogn eller en kurv. Man vælger de varer man har brug for. Man vælger måske også varer man ikke har brug for, men som ser interessante ud. Man fortryder måske enkelte varer og sætter dem på plads. Man går til kassen og betaler når man er færdig. Man kommer hjem og sorterer varerne. 4.2 Hvad kendetegner vores indkøbstur? Vi vælger en vogn vi vil gerne lære så meget som muligt. Vi vælger de varer vi ved vi har brug for systemudviklingsteori og -metoder. Vi lader os inspirere af varer der ser særligt interessante ud adrætte metoder og webapplikationer. Vi overvejer om vi har brug for og råd nok til alle varerne og sætter enkelte tilbage på hylden med andre ord vi afgrænser indholdet af undersøgelsen. - 6 -

Vi går til kassen og kommer materialet i indkøbsposer - vi reflekterer over vores metode og forskningsdesign. Vi tager hjem og sorterer varerne vi analyserer og undersøger sammenhænge i materialet. 4.3 Afhandlingens opbygning Vi har så vidt muligt forsøgt at afspejle denne afhandlings opbygning udfra ovenstående betragtning. Det betyder at: Afsnit 5 - Genstandsfeltet afspejler indkøbsvognen med et udvalg af webapplikationer og systemudviklingsteori og -metoder. Afsnittet behandler desuden de tilgange vi har fundet mest interessante at tage med til videre behandling. Afsnit 6 - Definitioner og afgrænsning afspejler varerne der sættes tilbage på hylderne ved de til- og fravalg vi har foretaget for at begrænse omfanget af undersøgelsen. Afsnit 7 - Extreme Programming afspejler en enkelt vare i indkøbsvognen for at give læseren indblik i den praksis systemudviklingsmetoden foreskriver. Afsnit 8 - Metode afspejler hvordan vi har tænkt os at vælge varerne, pakke dem, sortere og bearbejde dem. Det vil sige de metodiske overvejelser vi har gjort os i forbindelse med undersøgelsen, hvilket forskningsdesign vi er gået ud fra og hvilket datagrundlag vi har arbejdet med. Afsnit 9 - Analyse afspejler den måde hvorpå vi sorterer varerne - datamaterialet og ser en sammenhæng mellem dem. Derudover går vi et skridt videre end metaforen Indkøbstur i et supermarked foreskriver, idet vi også tilbereder og sorterer en del af de varer vi har hjembragt; Afsnit 10 XP # afspejler denne tilberedning ved at give nogle retningslinier og forslag til hvorledes XP kan tilpasses så den i større udstrækning imødekommer de problematikker vi afdækker. Afsnit 11 Konklusion afspejler den færdige menu ved at fremstille de væsentligste pointer og delkonklusioner i en samlet kontekst. Afsnit 12 Perspektivering afspejler vores egen vurdering af menuens sammensætning og smag ved at reflektere over det samlede specialearbejde. - 7 -

5 Genstandsfelt SKITSERER DE OVERORDNEDE PROBLEMATIKKER ADRESSERET I FORSKNINGEN PT. INDENFOR WEBAPPLIKATIONER OG SYSTEMUDVIKLINGSMETODER. Vi vil i dette afsnit beskrive genstandsfeltet og derved tegne landkortet 4 op for webapplikationer og systemudviklingsmetoder. Vi vil præcisere hvor vi selv befinder os på landkortet og derved gøre det klart hvilket udgangspunkt og hvilken forforståelse vi medtager i den videre undersøgelse. Vi starter med at se på webapplikationer som helhed og opridser de særlige vilkår, der eksisterer for disse og hvilke krav disse vilkår stiller til systemudviklingsmetoderne på et overordnet niveau. Dernæst vil vi se på begrebet systemudvikling samt systemudviklingsmetoder med udgangspunkt i overordnede modeller. 5.1 Webapplikationer Som nævnt i indledningen er der de seneste år sket en udvikling af applikationer til Internettet fra forholdsvis simple HTML-baserede sider til større interaktive webløsninger (Carstensen et al. 2001). Dette hænger naturligvis sammen med den teknologiske udvikling, men endnu vigtigere at webapplikationer bliver brugt til at tilfredsstille en række forretningskritiske elementer. Med udviklingen af teknologien og anvendelsen af disse systemer, går de traditionelle informationssystemer baseret på Internetteknologier fra at være formidlingsbaseret til at være avancerede systemer, hvor brugerne i højere grad har indflydelse på indholdet og den måde applikationen er opbygget. Udviklingen indenfor disse systemer er gået fra at være baseret på formidling til at varetage forretningskritiske elementer, hvilket blandt andet indbefatter marketingselementer, onlinehandel og business-to-business relationer (Earl et al. 2001, Carstensen et al. 2000, Baskerville et al. 2001). Dette har som nævnt i indledningen skabt et forskningsområde indenfor feltet systemudvikling af webapplikationer. Hastigheden hvormed teknologien udvikler sig kombineret med et stigende behov for at implementere applikationerne tilsvarende hurtigt (Internet Tid) har bevirket fokus på hvorledes systemudviklingsmetoder tager højde for ændrede vilkår for udviklingsprocessen. Forskningen på området er divergerende i deres betragtninger af webapplikationer som software, idet fokus blandt andet ligger på de interaktive relationer, de forretningsrelaterede 4 En metafor anvendt gennem afhandlingen (jf. 7.4.3 Metafor) - 8 -

relationer, de samarbejdsmedierende relationer m.fl. Vi har derfor fundet det relevant at afgrænse tilgangen ved at definere vores egen forståelse af applikationer til Internettet. Dette gør vi i et særskilt afsnit (jf. 6.5.3 AWA er Avancerede Webapplikationer). Dog er forskningen enig i at udviklingen af disse applikationer stiller nogle ændrede forudsætninger til systemudviklingsmetoderne når kravene til sådanne applikationer skal imødekommes. Gennem vores interview erfarede vi, at det er tydeligt at den udvikling der er sket inden for softwareudvikling inden for de sidste par år har medført at en række af de systemudviklingsmetoder, der før blev anvendt ikke er optimale for udviklingen af disse nye applikationer. (Carstensen et al. 2000:9). Udover den teknologiske udvikling, hastigheden af denne, Internettets stigende udbredelse og virksomhedernes forretningsmæssige argumenter for at anvende webløsninger til varetagelse af Intranet samt marketing og online-handel på Internettet, finder vi det dog vanskeligt præcist at identificere hvorfor der opstår nye krav til udviklingsprocessen. Hvorfor opstår disse særlige vilkår når der udvikles webapplikationer? Dette spørgsmål søger den eksisterende litteratur på området at tilgå, men pt. tager litteraturen afsæt i empiriske studier, hvor det i højere grad afdækkes hvordan der udvikles software til Internettet og i mindre grad hvorfor udviklingen ser sådan ud (Earl et al. 2001, Carstensen et al. 2000, Carstensen et al. 2001, Bødker et al. 2002, Baskerville et al. 2001, Isakowitz et al. 1998). Denne afhandling søger blandt andet at uddybe udgangspunktet for hvorfor disse vilkår opstår, samt at afdække i hvilken udstrækning de identificerede vilkår er relevante ved udvikling af større webapplikationer i forhold til nyere systemudviklingsmetoder. Vi finder det derfor interessant at tage udgangspunkt i de nuværende undersøgelser og gøre rede for hvilke vilkår vi finder, er relevante at medtage i det videre forskningsarbejde. Dette vil vi gøre i det følgende, hvor vi tager udgangspunkt i to artikler: Baskerville & Pries-Heje: emethodology: Towards a systems development methodology for e- business and e-commerce applications fra Georgia State University 2001. Earl & Khan: E-Commerce Is Changing the Face of IT fra MIT SLOAN Management Review 2001. De to artikler tager begge udgangspunkt i de ændrede vilkår for udviklingen af webapplikationer. Hvor Earl & Khan (2001) identificerer en ændret praksis, går Baskerville & Pries-Heje (2001) skridtet videre og opstiller en række krav til systemudviklingsmetoder for at imødekomme denne praksis. Vi finder at artiklerne på en række områder - 9 -

komplementerer hinanden på en måde der gør det relevant netop at fokusere på disse to kilder. Desuden giver artiklerne i en vis udstrækning argumenter for vilkårenes udgangspunkt. Argumenter vi finder interessante at efterprøve i dette specialearbejde. Vilkårene er: Først-til-marked Flydende og foranderlige krav Udvikling af prototyper Hyppige udgivelser Paralleludvikling Fast arkitektur Tidlig kodning Kvalitetsforhandling Gode medarbejdere 5.1.1 Først-til-marked Med udviklingen indenfor Internetteknologier og et stigende behov fra virksomheders side til at tage aktivt del i kommunikationen på Internettet, bliver det vigtigt for webudviklingsvirksomheder at være først på markedet idet alternativet er ikke at komme på markedet overhovedet We prefer to be imperfect and be there, rather than be perfect and not there. (Earl et al. 2001).. Tiden fra koncept til udgivelse er blevet faktoren, der afgør om ITvirksomheden har succes på webområdet. Tidsfaktoren er ikke unik for udvikling af webapplikationer, men i undersøgelser af udviklingsprocessen er det synliggjort hvor centralt et element tiden er i de systemudviklingsmetoder, der er fremkommet indenfor de sidste par år (Baskerville et al. 2001). 5.1.2 Flydende og foranderlige krav Vandfaldmodellerne eller rettere metoderne afledt af ideen om nøjagtigt at kunne beskrive detaljerede krav til applikationen og derefter programmere den tilsigtede applikation kommer til kort i mange webudviklingsprojekter 5. Problematikken hænger nøje sammen med Først-til-marked kravet. Når udviklingen går stærkt, efterspørgslen er stor og systemerne samtidigt er forretningskritiske, er det centralt som webudviklingshus at kunne tilpasse sig hurtigt og effektivt for at minimere omkostningerne. Dermed ikke sagt at virksomheden skal være teknologidrevet, men at visioner, ideer og dermed detaljer omkring design og planlægning af udviklingsforløbet ændrer sig mere konstant indenfor webteknologiområdet end for andre områder af software (Earl et al. 2001). 5 Vi vil i afsnit 5.3 uddybende beskrive vandfaldsmodeltankegangen. - 10 -

The requirements specification[...]has traditionally been the heart of systems methodology. However, Internet speed methodology accepts a starting point in which the goals, and consequently the specific strategies, are permitted to persist in near or full ambiguity. (Baskerville et al. 2001). Ovenstående beskriver dermed et stigende behov for at kunne tilpasse sig ændrede vilkår og at starte udviklingen på et mere usikkert grundlag. Det betyder ikke nødvendigvis at alt flyder indenfor udvikling af webapplikationer, men at webudviklingprocessens udgangspunkt er mere konceptuel end beskrevet i diverse dokumenter (Earl et al. 2001). 5.1.3 Udvikling af prototyper Når kravene er flydende eller flertydige er det vigtigt at anvende redskaber eller teknikker til at visualisere og afklare kravene til at danne en fælles forståelse af en given funktionalitet i systemet. Her viser det sig at udvikling af delvist funktionelle prototyper kan hjælpe med til at visualisere den konceptuelle forståelse og begynde designfasen (Baskerville et al. 2001, Earl et al. 2001). 5.1.4 Hyppige udgivelser De flydende krav bliver ikke udelukkende formuleret i den konceptuelle opstartsfase. Når man arbejder med at udvikle webapplikationer ændrer kravene sig løbende gennem udviklingsprocessen. Kunden bliver enten klogere og mere afklaret gennem processen. Webudviklingshusene kan dermed havne i en situation, hvor applikationen konstant ændres samtidigt med at kunden naturligvis ønsker et fremtidssikret produkt på den teknologiske side. Det bliver derfor i højere grad nødvendigt at frigive udgivelser hurtigere og at sørge for at disse frigivelser efterfølges af hyppige opdateringer (Earl et al. 2001). These maturing product cycles characterize major Internet software development in which competition demands significant product and feature changes every few months. (Baskerville et al. 2001). Udover den teknologiske udvikling og kundens ændrede krav gennem udviklingsprocessen skitseres der ligeledes et konkurrencemæssigt krav i udviklingsprocessen. Ved løbende at tilpasse sig kundens ændrede krav og forudsætningerne for disse i form af den teknologiske udvikling, kan man holde fast i markedsandelene og derved undgå en del af tidspresset under udviklingsprocessen. 5.1.5 Paralleludvikling Når udgivelsers tidscyklus skal være minimal, er det nødvendigt med sideløbende at varetage forskellige faser i udviklingsprocessen. Det vil sige at arbejdet skal organiseres på en måde hvor flere forskellige aktiviteter foregår samtidigt. - 11 -

The method [waterfall] is formal and logical; it provides a rigid structure and suggests review points for project planning and control. But in the e-it world, our respondents contended, it is too linear, doesn t appeal to creative designers, takes too long and can t cope with continuous ideas and change. (Earl et al. 2001:68). I praksis betyder det at det er nødvendigt at planlægge, redefinere og redesigne parallelt med at der programmeres, testes og refaktoreres. Det betyder at ændringer i funktionalitet eller design kan implementeres mere effektivt i efterfølgende versioner end det vil være tilfældet med en vandfaldstilgang, der ses som langsom og rigid (Baskerville et al. 2001). 5.1.6 Fast arkitektur Med ovenstående krav til et parallelt udviklingsforløb in mente er det hensigtsmæssigt med et framework for at opdele arbejdet. Her identificerer både Earl et al. (2001) samt Baskerville et al. (2001) den traditionelle trelagsarkitektur. Denne består typisk af et databaselag, et forretningslogisklag og et brugergrænsefladelag. Dynamik Brugergrænseflade Usikkerhed Forretnings logik Transaktionslag Robusthed Datalagring & dataprocessering Stabilitet Figur 1. Opdeling af udviklingsprocessen kan følge arkitekturen for generelle IT-systemer. Figuren illustrerer at jo tættere man kommer de dynamiske elementer desto mere uklart bliver det, hvorledes man imødekommer kundernes/brugernes krav. Desuden illustrerer figuren at jo længere man bevæger sig mod fundamentet for systemet desto mere robust virker det. Dette fremkommer som et delresultat af at der er lag i systemet, der er nemmere at teste og vedligeholde foruden at der traditionelt set anvendes flere ressourcer på disse back-end dele (Earl et al. 2001). Man kan passende fordele arbejdsgangene efter ovenstående arkitektur, men skal holde sig for øje at det kræver et højt kommunikationsniveau, da alle dele er indbyrdes afhængige. Fordelingen af arbejdet på denne måde indbefatter derfor jævnlig revidering og planlægning af forløbet (Earl et al. 2001). 5.1.7 Tidlig kodning Den korte tidsramme for at udvikle nye produkter eller versioner bevirker at man bliver nødt til at starte programmeringen tidligt i forløbet. Hvis man starter tidligt bliver det - 12 -