Et værktøj til historiestuderende

Transkript

1 Et værktøj til historiestuderende - refleksioner 3. delaflevering i Programmering og Systemudvikling Institut for Informations- og Medievidenskab Aarhus Universitet 3. december 2004 Vejleder: Ole Vedel Villumsen Afleveret af gruppe 2.5: Peter Vahlstrup, , peter@vahlstrup.com Solveig Sannem MacGregor Mønsted, , sol@moensted.net Frank Sørensen, , fsorens@imv.au.dk

2 Indhold 1 Introduktion Objektorientering Hvorfor objektorienteret programmering? Real world apprehension The representational gap Problematisering af formaliseringen Det positivistiske/mekanistiske paradigme Behovet for et nyt paradigme Det refleksivistiske paradigme Opsummering Agil softwareudvikling en metodologi The Agile Manifesto Proces og metode Unified Process - en konkretisering af agil udvikling Contextual Design og opsummering Vores eget projekt Refaktorering Præsentation af system Reaktion fra brugerne Interview med U1 og U2 uge Opsamling på vores interviews Hvor skal vi hen nu? Teori og praksis Agil metodologi forståelse, forandring og kontekst Litteratur Side 2 / 33

3 1 Introduktion Vores projekt går kort sagt ud på, at vi vil lave et system, der kan gøre det lettere for historiesturende at organisere deres noter, opgaver m.m. på en nem og ikke tidskrævende måde. Denne opgave er den sidste i en serie af tre. I de to første afleveringer har vi beskrevet vores udviklingsproces fra starten af inception-fasen og frem til den tredje iteration i elaboration-fasen. Vi vil indlede opgaven med en redegørelse for, hvad det egentlig vil sige, at programmere objektorienteret. Herunder en gennemgang af, hvilke antagelser omkring menneskets begrebsapparat, der udgør grundlaget for objektorientering i det hele taget. Derefter vil vi beskrive den agile metodologi. Først på et generelt plan, og derefter konkretiseret i Larmans beskrivelse af Unified Proces 1 og Beyer & Holzblatts Contextual Design 2, som er de to metoder, vi har brugt i udviklingsprocessen. Efter denne forholdsvis teoretiske del, vil vi runde vores proces af og fortælle, hvad vi har nået i den tredje og sidste iteration, der markerer den sidste milepæl, vi når inden afsluttende deadline. Ud over forløbet af tredje iteration vil vi fortælle om de problemer, der er opstået, og hvordan vi har tænkt os at håndtere dem og gribe næste del af udviklingsprocessen an. Denne næste iteration, som vi planlægger, er dog fiktiv, da vores proces slutter med denne opgave. I denne del vil vi også præsentere programmet ved hjælp af screen-dumps og forklarende tekst. I den sidste del af opgaven vil vi trække linjer fra det teoretiske fundament for objektorientering og vores begrebsopfattelse til den måde, vi har arbejdet på i vores proces. 1 Larman 2002, 2 Beyer og Holtzblatt 1998 Side 3 / 33

4 2 Objektorientering I denne del af opgaven vil vi give en nærmere gennemgang af, hvad det generelt vil sige at arbejde objektorienteret og mere specifikt, hvad objektorienteret programmering er. Vi vil holde os til den grundlæggende opfattelse, som man finder hos formuleret af de norske opfindere Kristen Nygaard og Ole Johan-Dahl, og folk som Ole Lehrmann Madsen fra Daimi ved Aarhus Universitet. Vi vil også redegøre for, at det at arbejde objektorienteret går betydeligt længere tilbage end 1960 erne, hvor Simula-sprogene blev opfundet. 2.1 Hvorfor objektorienteret programmering? Hvad vil det i det hele taget sige at programmere og udvikle systemer? Vores umiddelbare svar på dette spørgsmål, er, at udover den tekniske udfordring i at udtrykke sig i et programmeringssprog, så har en meget stor del af arbejdet i vores projekt bestået i at diskutere med hinanden og med vores brugere, hvordan de centrale begreber i den historiestuderendes arbejdsområde (domæne) skulle opfattes: Dette gælder både, når vi taler om domain-modellens konceptuelle klasser sammen med brugerne, og når vi internt snakker om omsætning af domain-klasserne til design-klasser i javakoden og koblingen til javas API-klasser og vores egne pure fabrication klasser. Der har været divergerende opfattelser både internt i vores gruppe, men også i forhold til vores brugere og de to brugere imellem. De divergerende opfattelser har yderligere ændret sig over tid, men heldigvis i retning af stadig større overensstemmelse. På basis af disse overvejelser vil vi tilslutte os det synspunkt, som fremsættes af bl.a. Ole Lehrmann Madsen et al.: At programmere er at forstå. 3 De uddyber dette yderligere: [...] one important aspect of program development is to understand, describe and communicate about phenomena and concepts of the application domain. Object-oriented programming has turned out to be particularly well suited for doing this. 4 Objektorienteret programmering blev startet i 1960 erne i Norge på Norwegian Computing Center, Oslo. De første objektorienterede programmeringssprog var Simula I, der blev brugt til simulationer, herefter efterfulgt af Simula 67. Objektorienteret programmering blev introduceret som et alternativ til f.eks. procedurel programmering (i f.eks. programmeringssproget C), og som navnet Simula antyder, er essensen af objektorienteret programmering af lave en simulation eller en model af et udsnit af virkeligheden. Forskellen på de to måder at programmere på beskrives af Madsen et al. således: 3 Madsen et al. 1993, s. 3 4 Madsen et al. 1993, s. 2 Side 4 / 33

5 Procedural programming. A program execution is regarded as a (partially ordered) sequence of procecure call manipulating variables. 5 Object-oriented programming. A program execution is regarded as a physical model, simulating the behavior of either a real or imaginary part of the world. 6 Når vi har benyttet den objektorienterede tilgang til opbygning af vores system, så har vi altså forsøgt at skabe en model af en lille del af virkeligheden ved at omsætte denne del i koncepter, som kan repræsenteres i et computerbaseret system. Mellem modellen og virkeligheden forsøger vi at tilstræbe en form for struktur-lighed, som består i, at virkelighedens begreber og deres relation til hinanden kan findes tilsvarende i systemets model. En af de væsentligste fordele ved objektorienteret programmering kan vi altså sammenfatte til, at det i højere grad følger vores egen (menneskelige) måde at tænke og opfatte begreber på. Det er den fordel, som Madsen et al. betegner som real world apprehension: [...] object-orientation is closer to our own natural perception of the real world.. 7 Overfor dette kan man sige, at den procedurelle programmerings sekventielle række af procedurekald i højere grad finder sted på maskinens præmisser. Uden at tage yderligere stilling til fordele og ulemper ved procedurel programmering, vil vi fortsætte denne analyse med at uddybe, med hvilken begrundelse man kan sige, at en objektorienteret model er forholdsvis tæt på vores opfattelse af den virkelige verden, og hvilke fordele og ulemper der kan være ved benytte en sådan model som grundlag for systemudvikling. 2.2 Real world apprehension Vi vil her gennem en række centrale begreber prøve at vise, at objektorienteret programmering har en strukturel lighed med den måde, vi almindeligvis opfatter virkelighedens begreber på Formalisering og abstraktion Når man vil lave en model af virkeligheden må der nødvendigvis finde en formalisering sted. Hvad ligger der i begrebet formalisering? Vi mener, at begrebet kommer fra Aristoteles ( f.kr.) 8. At begrebet går tilbage til Antikken (og sandsynligvis også endnu længere) er med til at underbygge, at det at arbejde med formelle modeller af virkeligheden falder os meget naturligt. 5 Madsen et al. 1993, s Madsen et al. 1993, s Madsen et al. 1993, s. 2 8 Stigen 1983, s. 115 Side 5 / 33

6 I de konkrete fysiske, iagttagelige fænomener (ting) skelner Aristoteles mellem stof og form. Stoffet er det konkrete fysiske materiale, som en given genstand består af, hvorimod formen er i en immateriel dimension, som findes i genstanden, som gør at vi mennesker genkender genstanden, som en bestemt kategori af genstande: F.eks. hvorfor en vase er en vase og ikke en krukke. Alle fænomener består, ifølge Aristoteles, både af individuelt stof og individuel form. Den individuelle form fra enkeltfænomen til enkeltfænomen kan vi imidlertid samle som almene former, som gør, at vi igen kan genkende enkeltfænomenerne. Når vi danner almene former, altså begreber, bruger vi vores evne til abstraktion, som illustreret i Figur 1 herunder: Person A Stof Form Person B Stof Form Abstraktion Begrebet menneske Person C Stof Form Figur 1 Aristotelisk abstraktion Klasser og nedarvning Tæt forbundet med brugen af abstraktion ser vi også, at brugen af klasse-begrebet kan spores tilbage til Aristoteles. Ifølge Aristoteles har alle ting egenskaber/attributter, som ikke kan eksistere uafhængigt af tingene. De væsentligste egenskaber er substans egenskaber, som er de formgivende egenskaber. Disse er essentielle for, at fænomenet kan eksistere og i det hele taget være det, som det er. Ud fra formen kan man via abstraktion bestemme art og slægt. F.eks. kan man slutte sig til: Sokrates er et menneske. Og videre, hvis man spørger, hvad et menneske er, kan man slægtsbestemme begrebet mennesket: Et menneske er et levende væsen. Visuelt kan det fremstilles som i Figur 2 herunder: Side 6 / 33

7 Levende væsen Menneske Sokrates Figur 2 Aristotelisk klassifikation af enkeltfænomenet Sokrates Det betyder, at man via abstraktion kan slutte sig fra det specifikke til det generelle Helheder og dele Et andet væsentligt koncept i den moderne objektorientering er at klasser ofte er sammensatte størrelser. Man vil oftest kunne analysere sig frem til, at et fænomen består af mindre dele, som så igen kan bestå af mindre dele. En væsentlig metode til at analysere virkeligheden for helheder og dele den består af, finder man bl.a. formuleret hos oplysningsfilosoffen René Descartes ( ). Hans metode til analyse 9 er vist i Figur 3: Enkle indlysende sandheder B Analyse Syntese A C Sammensat (uoverskueligt) problem Sammensat (men overskueligt) ikke længere problem Figur 3 Den cartesianske metode Alle fænomener vil ved første iagttagelse forekomme at være sammensatte og uoverskuelige. Men via opsplitning i enkeltdele (analyse) kan man få ny viden om det oprindelige fænomen. Når man har analyseret sig frem, hvilke dele enkeltfænomenet består af, vil det stadig forekomme at være sammensat, men ikke længere uoverskueligt. Den metode vi bruger til vores objektorienterede analyse, kan på flere punkter sættes lig den metode som Descartes i sin tid foreskrev, da vi ligesom Desacartes benytter os af et princip, som går ud på at analysere fænomenerne for, hvilke enkeltdele disse består af, og måske yderligere: Hvilke enkeltdele består enkeltdelene af? Resultatet af en sådan analyse skriver vi ind i vores diagrammer, så som domain-modellen og DCD erne. Syntesen 9 Stigen 1983, s. 386 Side 7 / 33

8 opstår, når vi bruger diagrammerne, som de briller vi betragter domænet igennem. Det er denne forholdsvis lange tradition, som gør, at både vi som designere og udviklere såvel som kunderne kan tale med om den model, som softwaresystemet indeholder netop fordi modellen i systemet har en strukturlighed med den måde, som vi almindeligvis har opfattet verden i lang tid før den objektorienterede programmering blev opfundet Sammenfatning Mange af grundprincipperne i objektorientering grundlægges i Simula-sprogene fra 1960 erne. 10 Her introduceres bl.a. betegnelserne klasser, underklasser og objekter. Den lange begrebsanalytiske tradition, som objektorienteringen bygger på, vil vi sammenfatte til flg. hovedsynspunkter: Enkeltfænomener kan artsbestemmes og slægtsbestemmes ud fra et hierarkisk opbygget klassifikationssystem. Enkeltfænomener kan navngives under fælles betegnelser, på grundlag af, at de har fælles attributter. Hermed har man betydningen af et koncept, hvilket vil sige en abstrakt, generaliseret idé, som dækker en række enkeltfænomener fra den virkelige verden. Dette er meget centralt, da vores domain-model netop består af konceptuelle klasser. Vi bruger i stor stil en analytisk metode, som sætter os i stand til at se, hvordan helheder består af underdele, som ligeledes kan bestå af underdele. 2.3 The representational gap Vil vil afslutte vores afsnit med at beskrive den generelle udfordring, som man står over for, når man vil lave en model af et udsnit af virkeligheden på en computer. Med introduktionen af objektorienterede programmeringssprog i 1960 erne gør Nygaard og Dahl det muligt ved hjælp af en maskine at repræsentere udsnit af virkeligheden i modeller, som er beskrevet i et algoritme-baseret sprog. Dette har i høj grad været med til at mindske det skel, der består imellem fænomenerne i verden og den model som skal repræsentere denne i det formellem algoritmebaserede sprog (representational gap). En algoritme skal her forstås som: An algorithm is an ordered set of unambiguous executable steps, defining a terminating process Brookshear 2003, s. 157, figur 4.1. I 7. udgave er der trykfejl, så det brugte citat er det, der rigtigt skulle have stået, jf. Brandorff Side 8 / 33

9 Til sin hjælp i programmeringssproget har man kontrolstrukturerne sekvens, forgrening og gentagelse. Dermed kan man konstruere algoritmer, med præcise sæt af regler for, hvordan (dele af) programmet skal opføre sig i bestemte tilstande. Den store fordel ved at repræsentere virkeligheden i et algoritme-baseret sprog, er at de fænomener, som navneordene i dagligsproget betegner, kan behandles af en von Neumann-maskine, hvilket kort sagt vil sige en maskine, der udfører seriel behandling af logisk repræsenterede symboler. Det medfører, at man som programmør er nødt til at udtrykke sig på en måde, som er utvetydig (unambiguous), for ellers vil maskinen ikke kunne behandle de symboler, som man opbygger. Ved udgangen af dette afsnit om objektorientering, vil vi rejse spørgsmålet, om det kan lade sig gøre at beskrive virkelighedens fænomener på en måde, som er fuldstændig utvetydig, og hvis ja, hvordan gør man det så på den bedste måde? Vi oplever, at der er forskellige grundlæggende holdninger til svaret på dette spørgsmål, og dem vil vi forsøge at redegøre for i det næste afsnit af opgaven. Dette er også med henblik på at indkredse, hvilket syn vi selv har på, hvordan man bedst arbejder med at formalisere udsnit af virkeligheden. Side 9 / 33

10 3 Problematisering af formaliseringen Der er bred enighed om, at objektorienteret programmering kræver en formalisering af koncepterne i applikationsdomænet for, at man kan lave en model, der kan behandles af en computer. Samtidig er der også udbredt enighed om, at jo mindre springet fra virkelighed til model (representional gap) er, jo større er sandsynligheden for, at der kommer et velfungerende system ud af udviklingsarbejdet. Dette henviser til real world apprehension-fordelen ved objektorientering. Til gengæld oplever vi grundlæggende uenighed omkring, hvordan dette spring gøres så lille som muligt, altså hvordan man får den mest velfungerende struktur-lighed mellem koncepterne i applikationsdomænet og model-klasserne. Vi oplever to paradigmer, som leverer hvert sit sæt af retningslinjer for, hvordan man på bedst mulig måde konstruerer disse formelle modeller, altså hvordan man konkret praktiserer brugen af objektorientering i en systemudviklingsproces. Et positivistisk/mekanistisk paradigme, inden for hvilket man er tilhængere af en grundig analyse og herefter betragter implementeringen som forholdsvis uproblematisk. Her mener man, at man endegyldigt kan analysere sig frem til, hvilke essentielle attributter og opførsler (behaviors) et fænomen har. Et refleksivistisk/pragmatisk paradigme, inden for hvilket man mener, at brugen af formelle modeller kan være problematisk, fordi der er et ontologisk problem (eller en udfordring) i at formalisere et givent applikationsdomæne. At man vil aldrig kunne lave en endegyldig fyldestgørende analyse. Som også med den generelle begrebsanalyse har hvert af disse paradigmer rødder, som går betydeligt længere tilbage end 1960 erne. Med en vis generalisering, kan man sige, at mekanisterne foretrækker en vandfaldsmodel med en grundig indledende analyse og en derefter forudsigelig arbejdsproces, hvorimod refleksivisterne vælger en tilgang til systemudvikling, som bygger på hyppig evaluering af arbejdsprocessen med partshavere i et projekt. Dette giver en adaptiv arbejdsproces. Vi mener selv, at vi arbejder ud fra det refleksivistiske paradigme. 3.1 Det positivistiske/mekanistiske paradigme Den positivistiske retning er grundlagt af en række naturvidenskabsfolk og teoretikere i slutningen af 1800-tallet, især Auguste Comte ( ) og Ernst Mach ( ). De bidrager til at formulere et ideal for videnskaben, som består i at udforme de mest økonomiske og eksakte beskrivelser af det givne. Dette betyder, at erkendelsen skal være baseret på omhyggelig registrering (helst via kvantitative metoder) og ordning af Side 10 / 33

11 erfaringsgivne data. Derudfra vil man kunne slutte sig til lovmæssigheder, som sammenfatter konstante sammenhænge imellem fænomenerne. 12 Dette muliggør forudsigelse og dermed kontrol af naturens og samfundets fænomener, sådan at der kan indrettes et velordnet, rationelt samfundsliv, bl.a. baseret på teknologisk-industriel produktion. 13 Man kan bruge den cartesianske metode (Figur 3, s. 7) til at analyse alle fænomener med, også abstrakte fænomener. Ved (dygtig) brug af streng formel logik vil man være i stand til at lave en fyldestgørende analyse af, hvilke enkeltdele et fænomen består af. Den positivistiske/mekanistiske retning får stor medvind, fordi brugen af disse metoder bliver et væsentlig grundlag for den anden industrielle revolution, som finder sted i starten af 1900-tallet. De positivistiske idealer, blev bl.a. omsat til praksis af den amerikanske ingeniør Frederick W. Taylor, som var manden bag indretningen af samlebåndsproduktionen på Ford-fabrikkerne i starten af 1900-tallet. Han og andre tilhængere af det positivistiske/mekanistiske ideal var dermed med til at grundlægge begreber som scientific management og taylorisme, som har været det gældende princip for indretningen af industrielle arbejdspladser langt op i 1900-tallet. Den tayloristiske indretning af arbejdspladsen bygger på den antagelse at man via minutiøs, omhyggelig og metodisk indsamling af data fra arbejdssituationen kan slutte sig frem til, hvordan arbejdet ideelt set bør indrettes, hvis det skal være så effektivt som muligt. 14 I nyere tid mener vi at kunne se, at det er positivistiske/mekanistiske principper, der ligger til grund for brugen af vandfaldsmodellen inden for udviklingen af softwaresystemer. Vandfaldsmodellen bygger på den grundantagelse, at man ud fra af omhyggeligt indsamlede data fra arbejdsdomænet forholdsvis objektivt kan regne sig frem til, hvordan et givent system skal designes for, at det passer ind i domænet. 3.2 Behovet for et nyt paradigme Vandfaldsmodellen har været den almindeligt udbredte tilgang til systemudvikling i mange år. Her er den illustreret: Fase 1: Analyse Fase 2: Design 12 Lübke et al. 1983, s Lübke et al. 1983, s Se f.eks. Chandler 1977, ss Fase 3: Implementering Fase 4: Test Fase 5: Ibrugtagning Figur 4 Vandfaldsmodellen Side 11 / 33

12 Princippet er, at først bruger man den cartesianske metode til at analysere et udsnit af virkeligheden for helheder og dele. Derefter repræsenterer man disse sprogligt, først uformelt og herefter gradvist mere formelt, så modellen til sidst er repræsenteret fyldestgørende på computeren. Problemet med denne måde at organisere udviklingsprocessen på, er at den i praksis ofte resulterer i mislykkede projekter, hvor hovedproblemet kan sammenfattes til, at de forskellige parthavere projekterne har divergerende opfattelser af, hvordan applikationsdomænet skal repræsenteres. I praksis har det ofte haft den konsekvens, at kunderne enten ikke får, hvad de forventer, eller udviklerne må bruge store ressourcer på at lave rettelser, fordi det, de allerede havde lavet, var ubrugeligt eller blev forkastet. Inden for de senere år er man derfor i større grad gået over til at bruge adaptive modeller for udvikling af softwaresystemer frem for vandfaldsmodellen. Den adaptive arbejdsproces tager udgangspunkt i, at begreberne ikke så let eller slet ikke lader sig bestemme entydigt. Tilhængerne af vandfaldsmodellen vil hævde, at det gør de, og at mislykkede projekter kan forklares ved, at udviklerne blot ikke har foretaget en tilstrækkelig dygtig eller grundig analyse af applikationsdomænet. Men, som antydet tidligere, er vi ikke enige i denne anskuelse, da vi ikke mener, at det er muligt at lave en så perfekt analyse, som det kræves. Begrundelsen for dette finder vi primært i den strukturalistiske sprogforskning og udviklingen inden for kvalitativ forskning, som finder sted op gennem 1900-tallet, og som danner grundlag for det refleksivistiske paradigme 3.3 Det refleksivistiske paradigme Det refleksive paradigme udspringer af en humanistisk tradition, hvor man lægger vægt på kvalitative analyse-metoder. Her spiller fænomenernes kontekst en central rolle. Dette ser vi formuleret både inden for den refleksive kvalitative forskning og i den strukturalistiske sprogvidenskab Refleksivitet Det refleksive paradigme 15 bygger på, at når vi vil undersøge fænomener, som har med mennesker at gøre, så er det meget svært (eller umuligt) at foretage en objektiv analyse. I stedet bliver man løbende nødt til at bevæge sig ud og lave feltarbejde. Det vil sige, at der lægges vægt på at opleve fænomenerne i deres kontekst, men samtidig, så må vi selv forholde os til det at indgå som en del af denne kontekst. Dette er en central præmis for brugen af kvalitative metoder, frem for at følge en streng metode, der bygger på forudsigelighed og det at analysere tingene på en objektiv måde fra sidelinjen. Vi er altså 15 Flick 2002, s. 6 Side 12 / 33

13 bevidste om vores egen manglende evne til at foretage en perfekt/objektiv analyse ud fra et én gang indhentet sæt af data. Så derfor vælger vi i stedet at gøre stor brug af feltarbejde og tilbagevenden til felten, frem for at sidde derhjemme og analysere via deduktive metoder og forestillinger. I stedet kommer vi med mange udkast og evaluerer disse løbende ved at tage dem med ud i marken igen og prøve dem af i konteksten. Det betyder, at vi tager det som et grundvilkår, at vi ikke kan lave en perfekt analyse Strukturalistisk sprogforskning Den schweiziske sprogforsker Ferdinand de Saussure ( ) er grundlægger af den strukturalistiske sprogforskning. I Saussures forklaring er ordene ikke entydige symboler, men snarere beholdere, som kan have et arbitrært indhold. Det sproglige tegn, som f.eks. kan være et bestemt ord, kan afbilledes således: Indhold Udtryk Figur 5 Det strukturalistiske tegnbegreb Inden for strukturalismen skelner man mellem det sproglige tegns udtryk og indhold. 16 Tegnets udtryk er oftest dets navn, altså f.eks. ordet Træ. Indholdet er den semantiske betydning af ordet. Når man taler om, at forholdet mellem udtryk og indhold er arbitrært, så betyder det, at den opfattelse som en sprogbruger har af ordet Træ kan være en ganske anden, end den, som en anden bruger af samme sprog har af ordet. Men grunden til at dagligsproget ikke flyder, og at vi trods alt kan forstå hinanden, er at indholdsdelen er forholdsvist fastlagt ved konvention blandt brugerne af et givent sprog. Men vi må dog hæfte os ved at forholdet mellem et ords udtryk og dets indhold er arbitrært og at det afhænger af konteksten. Dette leder os frem til at konstatere, at indholdet af dagligsproget ikke problemfrit lader sig formalisere. Det skyldes, at de dele, som det består af (tegnene/ordene), ikke er semantisk entydige. 3.4 Opsummering Vi har forsøgt at vise, at man kan forklare mange problemstillinger i systemudviklingsprocessen ud fra divergerende forståelser af, hvordan koncepter i applikationsdomænet skal repræsenteres i en fysisk model på computeren. Når ordenes semantiske betydning ikke ligger fast, men snarere er genstand for stadig forandring, så er 16 Se f.eks. Brügger og Vigsø 2002, s. 16 Side 13 / 33

14 fejltagelser i behovsanalysen til et software-system nærmest uundgåelige. Hvis man tager konsekvensen af de problemstillinger, som vi her har vist, så må det nødvendigvis afspejle sig i arbejdsprocessen for systemudvikling. Hvis man ikke kan analysere virkeligheden fyldestgørende og entydigt for hvilke koncepter, den indeholder, så mener vi, at man må vælge en mere pragmatisk (adaptiv) tilgang til systemudvikling, end den man kender i den forudsigelige arbejdsproces fra vandfaldsmodellen. Det må være en tilgang, der bygger på det grundvilkår, at parthaveres opfattelser af centrale koncepter er forskellige og desuden, at opfattelserne løbende ændrer sig. Vi siger ikke dermed, at man ikke kan eller skal analysere fænomenerne logisk, men blot, at det er hensigtsmæssigt at være bevidst om, at der er grænser for, hvor langt man kan komme via ren logisk analyse. Vi er snarere tilhængere af at inddrage synspunkter fra så mange af et projekts partshavere som muligt som den væsentligste kilde til indsigt i applikationsdomænets fænomener. Side 14 / 33

15 4 Agil softwareudvikling en metodologi Vi har nu talt for, at systemudviklingsprocessen bør vær adaptiv, frem for forudsigelig (predictive). Dette mindsker representational gap, men det er samtidig også med til at effektivisere systemudviklingsprocessen. Dette ser vi konkretiseret i den systemudviklings-metodologi, som hedder Agile Software Development. Bag metodologien står en række fremtrædende udviklere med baggrund i forskellige traditioner, bl.a. Extreme Programming (XP) og Feature Driven Development. De mødtes i 2001 og dannede The Agile Alliance. Ved dette møde samlede de hovedprincipperne for agil softwareudvikling i et dokument, som de valgte at kalde The Agile Manifesto The Agile Manifesto Manifestet indeholder fire hovedprincipper, som vi her vil gennemgå: Individer og interaktion fremfor processer og værktøj. Deltagerne i softwareudviklingsprocessen betragtes som individuelle personer, frem for blot de formelle roller, som de udfylder. Der lægges desuden vægt på vigtigheden af interaktion, fordi det er i diskussionen mellem mennesker, at man opdager nye løsninger og problemer/fejl i gamle løsninger. Fungerende software fremfor omfattende dokumentation. Det er vigtigt, at få noget kode, der kan afvikles, sådan at det løbende kan testes. Diagrammer og dokumenter er en hjælp til udviklerne, der sætter dem i stand til løbende at reflektere over systemet. Kundesamarbejde fremfor kontraktforhandlinger. Har lægges der vægt på samarbejde og et højt kommunikationsniveau mellem udviklere og kunder/brugere, frem for et skarpt skel mellem disse. At reagere på forandring fremfor at følge en plan. Planer kan være gode, men man de må ikke forhindre, at man kan reagere fleksibelt på, hvis kravene til et system ændrer sig. Det foreslås derfor, at man ikke lægger lange detaljerede planer, men i steder f.eks. bruger time-boxing, altså intervaller af måske 2-4 ugers længde. Dette sikrer, at man løbende får produceret en fungerende udgave af softwaren. I principperne bag manifestet 18 forklares det yderligere, at den højeste prioritet er at stille kunden tilfreds. Derfor skal forandring imødekommes og udnyttes med henblik på at tilfredstille kundens ønsker. I denne forbindelse er det af central betydning, at man løbende reflekterer over sin egen arbejdsproces og foretager nødvendige justeringer på Side 15 / 33

16 denne, hvor det er nødvendigt. Side 16 / 33

17 5 Proces og metode 5.1 Unified Process - en konkretisering af agil udvikling Craig Larman giver igennem Unified Proces en konkret metode til at arbejde med de principper som det agile manifest består af. UP er en iterativ metode, konstrueret til objektorienterede programmeringssprog, der består af de fire faser: inception, elaboration, construction og transition. Hver af disse faser er baseret på hvilke aktiviteter der vil forekomme mest af inden for den specifikke fase. Der vil f.eks. i construction-fasen være hyppigst aktivitet inden for implementeringsrelaterede aktiviteter, hvorimod de overordnede modeleringsrelaterede aktiviteter gerne skulle ligge på et lavere niveau, da den største del af disse gerne skulle have fundet sted i elaboration-fasen. Inden for hver fase bliver der alt efter projektets omfang foretaget en række iterationer. En iteration i UP kan ses som et miniprojekt, da der i hver iteration vil være arbejde inden for de fleste af de discipliner, der hører sig til et softwareudviklingsprojekt. Med discipliner menes der f.eks. design af system, implementering, testning m.m. Alt efter hvor man befinder sig i projektet vil det variere, hvor meget der bliver udført inden for de forskellige discipliner, men der vil i en iteration altid forekomme aktivitet inden for de fleste discipliner. Denne sideløbende aktivitet i iterationer inden for de forskellige discipliner er det, der kan betragtes som kernen i UP, heraf også navnet, unified, der repræsenterer foreningen af de sideløbende aktiviteter, der kendetegner processen. Nedenstående giver et eksempel på, hvordan forskellige discipliner gentages i større eller mindre omfang i de forskellige faser. Eksemplet er fra vores eget projekt: Discipliner Bruger-interview Work modelling Behovsanalyse Domain modelling Mock-ups Implementering Test Inception Elaboration 6. sep 27. sep 18. okt 8. nov 29. nov Figur 6 Brugen af discipliner og time-boxing i vores eget projekt Side 17 / 33

18 Der skal tidligt i processen fastsættes en tidsramme for hvor lange iterationerne i de forskellige faser skal være. Dette er med til at underbygge ideen om, at hver iteration kan ses som et miniprojekt i projektet, og derfor skal også miniprojektet have en deadline for, hvornår den pågældende iteration skal være færdig. Ved begyndelsen af hver iteration bør der sættes tid af til at reflektere over den foregående iteration og rette eventuelle fejl, der måtte forekomme. Dette kun f.eks. være modificering af diagrammer, der skal ændres på grund af ny viden om det omhandlende domæne. Et andet eksempel kan være refaktorering af kode, der grundet projektets udvikling ikke længere har den rette funktionalitet. Ved at arbejde iterativt sørger man for en fleksibel arbejdsgang, der tager højde for tilføjelse af ændringer foråsaget af de foregående iterationer, eller ændringer fra brugerens side. Med dette i mente omhandler den iterative proces altså ikke kun om selve udviklingsteamet men også brugerne af systemet. Der skal altså løbende være kontakt med kunden så denne kan blive involveret i og kan tage stilling til de ændringer og problemer, der måtte opstå under udviklingen af systemet. Dette foregår ved hjælp af usecases, som efter hver iteration evalueres, så de fortsat passer på brugeren. I UP foreskrives der, at det allerede i den tidlige del af processen er vigtigt at få afklaret evt. risikofaktorer forbundet med kernen af systemet og desuden få designet en rimelig fast arkitektur for denne. Dvs. at det er vigtigt, så hurtigt som muligt, at få implementeret og testet afgørende elementer i systemet så man ikke på et senere tidspunkt løber ind i uventede problemer, der kan føre til omfattende ændringer af kernestrukturen. Her spiller de førnævnte use-cases også en stor rolle, da højrisikoafklaring også handler om brugerinput fordi nogle af brugerens ønsker kan være afgørende i forhold til udformningen og udviklingen af systemet. Endvidere lægges der vægt på hyppig testning af kode igennem hele processen for derigennem at foregribe eventuelle uoverensstemmelser før de bliver fatale for systemet. Udover den struktur af processen som UP tilbyder, indeholder metoden også en stor beholdning af artefakter i form af modeller og diagrammer, der bruges i iterationerne til at analysere de forskellige problemstillinger. Ved hjælp af disse artefakter kan man gradvist nærme sig et færdigt produkt. Der er en mangfoldighed af artefakter og det er derfor op til det enkelte udviklingshold, hvilke og i hvilken udstrækning man vælger af benytte sig af artefakterne Contextual Design og opsummering Contextual Design 20 (CD) består af række værktøjer og retningslinier, som systemudviklere kan bruge til at få en større indsigt i den arbejdsgang, som brugeren har. 19 Larman 2002, ss Beyer og Holtzblatt 1998 Side 18 / 33

19 En del af den teoretiske baggrund for CD er en kvalitativ tilgang til undersøgelse af brugerens arbejdsområde. Retningslinjerne i CD er, at man som udvikler igen og igen skal opsøge brugeren og foretage fortsatte analyser af arbejdsområdet for at sikre sig at man ikke har glemt noget vigtigt i foregående møde med kunden. På denne måde skal brugeren også holdes ajour med udviklingen af systemet. I retningslinierne for agil softwareudvikling bliver der lagt stor vægt på samarbejdet med systemets brugere. I afsnittet om UP redegør vi for brugerkontakten, som use-cases bygger på, men UP giver ikke retningslinier for, hvordan man skal kontakte kunden og hvordan man bearbejder al den information, som man får i mødet med kunden. Her har vi valgt at bruge CD, der netop handler om denne del af brugerkontakten. CD tilbyder værktøj til kommunikationen med brugeren helt fra begyndelsen med contextual inquiry og videre frem i forløbet og beskriver, hvilke metoder, der er gode i forhold til bl.a. interview, rollefordelinger i interviewteamet. Desuden omfatter bogen en lang række modeller og vejledninger til, hvordan man skal behandle alle de oplysninger, man får i kontakten med kunden. Ved at benytte UP og CD sammen har vi fundet godt fundament til at understøtte det refleksivistiske paradigme om, at sproget ikke uden videre lader sig formalisere og hermed grundlaget for OOAD. Derudover synes vi, at syntesen af UP og CD gør os i stand til at følge principperne for agil software udvikling omkring iterationer, brugerkontakt og tilpasningsdygtighed. Side 19 / 33

20 6 Vores eget projekt Som beskrevet i vores tidligere rapporter har vi i vores systemudviklingprojekt valgt lave et system til studerende ved historisk institut. Hvad dette system skal indeholde/kunne har vi i kontinuerlig proces udarbejdet i fællesskab med de kommende brugere af systemet. Vores vision, som er blevet til igennem denne proces, lyder som nævnt i introduktionen: Vi vil lave et system der kan gøre det lettere for historiesturende at organisere deres noter, opgaver m.m. på en nem og ikke tidskrævende måde. Vi fandt på baggrund af vores brugerinterviews frem til at det vil være hensigtsmæssigt at kunne tilkoble et antal emneord 21 til diverse filer så de herigennem kan struktureres ud fra emneområder m.m. Det skal desuden være muligt at tilføje en beskrivende tekst 22 til en fil som sammen med emneordene kan bruges til at lave en søgning i filsystemet. I første iteration af elaborations-fasen modellerede vi kernekoncepter af programmet via use-cases og UML-diagrammer, for derigennem at få et overblik og en fælles forståelse af vores system og desuden med henblik på at kunne præsentere et antal papir-mockups af de forskellige hovedelementer i systemet for vores brugere. Vi begyndte desuden i slutningen af anden interation at implementere et af grundelementer i vores system, som beror på koblingen af emneord til brugerens filer i filsystemet. Vi er i skrivende stund ved at afslutte vores tredje iteration i elaborationsfasen. Vi har i denne iteration taget hånd om de problemstillinger omkring vores design, der opstod i slutningen af vores foregående iteration. Vi har desuden arbejdet videre med vores udvikling af systemet og holdt møder med vores brugere for at få feedback på den del af systemet, der på nuværende tidspunkt kan repræsenteres via et bruger-interface. Vi vil i følgende afsnit uddybende gennemgå vores tredje iteration i elaborationsfasen og behandle ovenstående emner i denne. 21 Den tekniske betegnelse for et emne vil igennem denne opgave være Topic, da dette refererer til Topic-klassen i vores model 22 Den tekniske betegnelse for en beskrivende tekst vil igennem denne opgave være MetaText, da dette referere til MetaText-klassen i vores model Side 20 / 33