2. Metode. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Aftalekalenderprojektet. Indledning

Transkript

1 2. Metode Indledning Projektet er udført med flg. faser: Foranalyse (uden iterationer) Analyse (udarbejdelse af kravspecifikation afsnit 9.1, herunder use case beskrivelser afsnit 9.2) Design af skærmbilleder vha. prototyping E/R modellering af databasen Objektorienteret design af programmet Konstruktion Test Idriftssættelse note: fra analysefasen til test er der flere gennemløb I dette kapitel gennemgås de væsentligste beslutninger, der er truffet med metodevalg for projektets gennemførelse. Inden metoden for udviklingsprocessen endelig kunne fastlægges, blev der foretaget en forundersøgelse. Projektets beskedne størrelse og forventninger gjorde, at forundersøgelsen blev lavet med udgangspunkt i MUST-metoden, Metode til forundersøgelse i Systemudvikling og Teori herom ( Bødker m.fl., 2000). Dvs. at der blev taget udgangspunkt i den eksisterende organisation, og at løsningen skulle skabes ved at ændre i organisationens forretningsgange og indpasse løsningen igennem brugerinvolvering. Alternativ kunne være en BPR-analyse, hvor alt kan ændres, men som ud fra et ressourcemæssig synspunkt og deltagernes opfattelse ikke er aktuel her. Det konkrete resultat af forundersøgelsen blev en kort målformulering og interessentanalyse. Formålet med interessentanalysen var at få udpeget de forskellige interessenter og få belyst deres andel af projektet. En projektsucces forudsætter bl.a., at der kan skabes en fælles opfattelse af løsningen interessenterne imellem. 2.1 Interessentanalyse Interessenterne i projektet er vist i nedenstående figur: Tandlægen Tandplejeren Aftalekalenderprojektet Klinikassistent 1 Klinikassistent 2 Patient Udvikleren/ projektleder 6

2 Interessenter De primære brugere er klinikassistenterne, idet de anvender alle systemets funktioner. Det er denne gruppe, der primært foretager booking, hvorimod behandlerne mere er brugere af output i form af overblik fra systemet. Der vil dog være et behov for at afstemme et design med begge grupper. Med hensyn til integration med de øvrige systemer er der en fælles interesse. Der tænkes her primært på afgrænsningen til Datodontsystemet (se termer side 1). På det strategiske niveau er det kun tandlægen, der har interesse i at se systemet på lidt længere sigt i forskellige mulige sammenhænge med klinikkens øvrige systemer. Patienterne er indirekte brugere af systemet, men deres interesser dækkes primært gennem klinikassistenterne. Hvis der var tale om at lave booking over Internettet, ville gruppen have egne krav. Udvikleren er taget med som en deltager i projektet, idet han stiller begrænsede ressourcer til rådighed og samtidig stiller krav om at få stillet ressourcer til rådighed i forbindelse med brugerinvolvering. Baseret på foranalysens resultater blev der udarbejdet en SWOT-analyse. Målet med analysen var at få afdækket de styrker, svagheder, muligheder og trusler som projektet lagde op til: Interne faktorer: Styrker: Spændende alsidigt projekt. Giver mulighed for at anvende store dele af det tillærte og tilføje ny viden. F.eks. koordinere viden om database design og objektorienteret design. Relativ nemt at kontakte brugere i forbindelse med projektet og udvikleren kender organisationen godt fra løsning af administrative opgaver. Engagerede brugere god timing i forhold til internt projekt, se Aftalekalenderen på side 3 afsnit 1.1. Svagheder: Mit første projekt - manglende erfaring. Opsamling af teknisk viden kan være resourcekrævende, og der er risiko for at gå i en forkert retning ved valg af teknologiske løsninger. Eksterne faktorer: Muligheder: Gode muligheder for råd og vejledning undervejs i projektet. Trusler: Ved uddannelsesprojekter er der altid stor risiko ved ressourceestimering. Hardware nedbrud og softwaremæssige fejl 2.2 Valg af model SWOT-analysen peger mod anvendelsen af en forretningsorienteret udviklingsmodel, der bygger på brugerinddragelse, og hvor metoden indeholder iterationer. Dette skyldes hovedsagelig styrkerne, der muliggør brugerinddragelse. DSDM Dynamic Systems Development Method (Vinje, 2000) har netop disse egenskaber, og der tages derfor udgangspunkt i denne metode. 7

3 Metoden er faseopdelt og indeholder følgende faser: Business Study Functional Model Iteration Design and Build Iteration Implementation Modellens faser gennemføres flere gange med stigende detaljeringsgrad. Der er behov for at anvende prototyping i samarbejdet med brugerne i designfasen og i forbindelse med udviklingen af den tekniske side til design af komponenterne. DSDM er en metodestandard, der er baseret på Rapid Application Development (RAD). Metoden anvender time boxing til at styre projektet, hvilket er i god overensstemmelse med den afgrænsede projektperiode. Modellen må af hensyn til projektets størrelse betragtes som retningsgivende, men giver et godt udgangspunkt for planlægningen og styringen af projektet. Kravspecifikationen er den fælles ramme og er et værktøj til at sikre den fælles forståelse ( se afsnit 9.1, Kravspecifikation) Anvendelse af use case beskrivelser, der indgår i kravspecifikationen er et centralt element i OOA. Et alternativt værktøj er UML s use case diagrammer. Udgangspunktet er interview med de enkelte brugere. Udarbejdelsen af use case beskrivelser er et vigtigt værktøj til en fælles forståelse imellem udvikler og bruger men også brugere imellem, når en arbejdsproces skal fastlægges, idet en arbejdsopgave kan løses på forskellige måder. Endvidere er use case beskrivelserne vigtige til udarbejdelsen af brugertest. Dette skyldes, at der fortsat er en mindre risiko for at have en forskellig opfattelse af indholdet, brugerne og udvikleren imellem. Hertil kommer risikoen for at en arbejdsopgave (der måske er selvfølgelig for brugerne) glemmes. Den sidste risiko minimeres bedst ved at observere under arbejdssituationen og lade brugerne beskrive forskellige hændelser med det nuværende system. Use case beskrivelserne skal ændres og suppleres med nye use case beskrivelser, når grænsefladerne til de øvrige systemer evt. ændres. Disse nye use case beskrivelser udarbejdes f.eks. af udvikleren og godkendes af de relevante/berørte brugere 2.3 Anvendelse og udarbejdelse af prototyper Som udgangspunkt anvendes der to typer af prototyper (Hughes and Cotterell, 2002): Throw-away prototypes, midlertige prototyper til afprøvning af forskellige idéer Evolutionary prototypes, prototyper der løbende forbedres igennem test og redesign som vist i nedenstående figur (Roger S. Pressman, 2000) 8

4 listen to customer build/revise mock-up customer test-drives mock-up Fordele og ulemper ved brug af prototyper En prototype i skitseform kan anvendes til at undersøge, hvordan brugeren opfatter brugergrænsefladen og til at få en diskussion om brugergrænsefladen. Den færdige prototype, der indeholder skærmbilledernes funktioner, kan anvendes til usabilitytest. Herved kan brugsproblemer blive afdækket. Brugergrænsefladen kan på denne måde udvikles ved at eksperimentere sig frem til et brugbart resultat. Ofte er det nødvendigt at kassere den første prototype, men jo mindre tid der er anvendt til at lave skitsen, jo nemmere er det for udvikleren at kassere den. Den største fordel er de gode resultater, der kan opnås ved at anvende prototyper på trods af den begrænsede ressourceanvendelse, der skal til at lave prototypen (Søren Lauesen, 2001). Anvendelse af prototyper har en positiv indflydelse på samarbejdet, idet reaktionstiden fra idé til ny test kan formindskes. Herved kan udviklingstiden og dermed ressourceforbruget til udvikling formindskes. En ulempe ved prototyping er, at brugerne kan få en forkert opfattelse af, hvor langt projektet er i processen. Ved prototype i endelig form, eks. udarbejdet vha. MS-Excel vil brugerne ofte kunne få en opfattelse af, at udviklingen er længere fremme end den reelt er pga. af den måde, som resultatet præsenteres på. En anden ulempe ved denne udviklingsform kan være, at den tekniske side er underrepræsenteret, således at en løsning, der bliver fundet sammen med brugerne i forbindelse med test af prototypen, viser sig at blive for kompliceret at implementere. Med stigende erfaring hos udvikleren, vil denne ulempe antagelig kunne reduceres. En vigtig parameter ved brugervenlighed er effektivitet, hvilket er prioriteret i kravspecifikationen. Effektivitet er imidlertidig svær helt at bedømme ved prototyper, ikke mindst ved anvendelsen af papirprototyper. F.eks. må gode svartider tilvejebringes ved f.eks. at designe en hurtig algoritme eller ved valget af databasesystem og databasens struktur. Udviklingen af brugergrænsefladen ved hjælp af prototyping har et resultatdrevent udgangspunkt og tager sit udgangspunkt i anvendelsesområdet. 9

5 2.4 Databasedesign Design af databasen vil ske ved E/R-modellering (Richard T. Watson, 2002), der er en grafisk tilgang til at modellere og normalisere databasen. Udgangspunktet for modelleringen er de skærmbilleder, der er resultatet af prototypingen med brugerne. Fokus skifter fra anvendelsesområdet til problemområdet, og der bliver tale om en datadreven proces. Ved vha. DDL (Data definition language) beskrives/oprettes de enkelte entiteter og relationer i databasen. Til design af programmets struktur anvendes objektorienteret design og analyse pga. det valgte programmeringssprog (Java). Den objektorienterede tilgang sikrer et sammenhængende forløb som beskrevet i f.eks. 4+1 view 2. De objektorienterende sprog sikre bl.a. anvendelse af genbrug gennem nedarvning, komposition og indkapsling. Endvidere er polymorfi en vigtig egenskab. 2.5 Udviklingsmiljø Til udvikling af systemet blev der anvendt en standard editor (jedit version 4.0.3, hvilket var indarbejdet værktøj i forbindelse med mindre programmeringsopgaver. Til brug for projektet blev der installeret den nyeste version af værktøjet på en pc, der skulle anvendes til udviklingen. Efter aftestning af installationen blev der lavet en tilsvarende installation på en bærbar pc, der kunne agere som backup og testmaskine. I forbindelse med udviklingen var der behov for versionsstyring, men da projektet startede var denne viden begrænset. Der blev etableret et simpelt mappesystem, hvor versionerne blev angivet med måned-dag-løb. nr. Desuden blev der til hver version udarbejdet en tekstfil, der indeholdt få linier om ændringer siden sidste version, den efterfølgende udvikling og evt. bemærkninger til den aktuelle version. Der blev løbende lavet backup over en ekstern server til sikring af kildeteksten. Det ville være bedre at anvende et standardværktøj som f.eks. CVS til versionsstyringen, men viden om brugen af værktøjet blev først etableret senere i forbindelse med VOP-kurset. Endvidere kunne udviklingen være blevet forbedret med testværktøjet JUnit til løbende under udviklingen at teste de enkelte komponenter og deres sammenhænge. Til brug for systemudviklingen (styring og dokumentation) kunne der med fordel være anvendt en form for CASE-værktøj (Computer Aided System Engineering). Værktøjet kunne evt. understøtte udviklingsmetoden samt det objektorienterede design. Der har dog ikke været anvendt et sådant værktøj. I forbindelse med konstruktionen kunne et værktøj af typen Integrated Development Enviroment måske være anvendt for af den vej hurtigere at generere f.eks. brugergrænsefladekomponenterne og databaseadgangen. Anvendelsen af et sådant værktøj har reelt ikke været overvejet bl.a. pga. projektets idegrundlag. Det ville måske have været hurtigere at udvikle, men også langt mindre interessant, og det er tvivlsomt, om der kunne konstrueres en lige så fleksibel løsning. 2 Philippe Kruchen, The 4+1 View of Architecture, IEEE Software, 12(6) Nov

6 Under projektet blev der ikke ændret i udviklingmiljøet, på trods af kendskabet til bedre værktøjer, fordi kontinuiteten ønskedes bevaret. Den simple versionsstyring var kun mulig pga. projekts størrelse og de få udviklere. 2.6 Tidsplan Efter at kravspecifikationen var udarbejdet blev der regnet på, hvor meget tid der var til rådighed til at gennemføre resten af projektet. Beregningen var ikke helt simpel, idet der skulle tages højde for andre opgaver. Ved siden af dette projekt følges 2 andre fag, som kræver deres andel af det totale antal timer. Timeforbruget til de andre fag forventes at variere over perioden. Der blev således taget højde for, hvornår skoleugerne og eksamen mv. falder. Den totale tidsramme for projektperioden (marts-juli) blev beregnet til 585 timer. Herefter blev der beregnet estimater på de enkelte aktiviteter: Test & rette (aftestning og fejlrettelse), skrive rapporten, Adm. (planlægning og lave aftaler mv.), reserve & tryk og læse artikler mv. Kode og design var den sværeste aktivitet at estimere, hvilket skyldes, at der ikke er noget erfaringsgrundlag for udviklerens programmeringsproduktivitet. Hertil kommer at hovedparten af løsningerne skal udvikles i forbindelse med projektet. Tiden, der kan anvendes til kode og design, blev beregnet residualt til 210 timer, hvilket blev udgangspunktet for time boxing. Timer ugenumre antal timer i alt til kode & design Figur 2-1 Tidsplan for aftalekalenderen 11