side 49 9 Må ikke forveksles med java.util.date

Transkript

1 6. Evaluering (herunder afprøvning af programmet) Kapitlet indeholder en beskrivelse af teststrategien for afprøvningen af programmet og beskrivelse af de test, som er blevet udført samt resultaterne af de enkelte test. 6.1 Teststrategi Teknisk test af software kan overordnet opdeles i struktural test (white-box test) og i funktionel test (back-box test). Hertil kommer test af programmets brugervenlighed. Formålet med aftestningen er ikke at få bevist produktet er fejlfrit, men styrke troen på programmets anvendelighed. Ved valg af testmetoder er der lagt vægt på, at Aftalekalenderen indeholder en grafisk brugergrænseflade som en vigtig og central komponent i problemstillingen. Hertil kommer, at datoberegningerne er krumtappen i programmet, hvilket gør, at datoberegningerne er udvalgt specielt til aftestning. Den grafiske brugergrænseflade og projektets fokus gør også, at en test af programmets brugervenlighed er et godt valg. Omfattende test er tidskrævende, derfor er valg af metoder og omfang også afhængig af tiden, der er til rådighed til testen. Hvor meget tid der er nok afhænger af hvad produktet skal anvendes til og hvad konsekvensen af en fejl er. Ved valg af strategi har jeg fravalgt ren struktural test af tidsmæssige årsager. Test af denne type kunne være anvendt til f.eks. at teste programmets datastruktur. Testen kunne have testet de forskellige forgreninger, således at de enkelte klassers metoders egnethed (eller samlede komponenter) kunne blive bekræftet. Struktural test giver en høj sikkerhed for, at de testede metoder virker efter forventningerne. Overblik over de udvalgte test: I afsnit 6.2 manuel og maskinel kontrol af datoberegning I afsnit 6.3 funktionstest med særlig fokus på brugergrænsefladen I afsnit 6.4 brugervenlighed (usability test) 6.2 Test af datoberegninger Indledning Beregninger af datoer mv. sker i klassen Date, der ligger i programmets util-pakke 9. Test af datoberegningerne er som udgangspunkt sket ved at sammenligne Aftalekalenderens datoer med den trykte kalender fra Mayland, der som kilde må forventes at have stor troværdighed. Sammenligningen er foregået stikprøvevis for perioden Som stikprøve er der udvalgt februar, august, september samt december og januar. Månederne er udvalgt som repræsentanter for en månedslængde på dage, 30 dage og 31 dage og herudover er årsskiftet udvalgt. Aftestningen af Aftalekalenderen er afgrænset til informationerne, som den grafiske brugergrænseflade viser, nemlig fra mandag til fredag for hver uge. Ugenummeret vises ud fra en 9 Må ikke forveksles med java.util.date side 49

2 beregning, der er baseret på mandagens dato. Resultatet af denne test var, at de beregnede datoer, ugedage og ugenumre var i overensstemmelse med de trykte kalendere. Der blev ikke fundet fejl ved testen. Maskinel kontrol af datoer Ud fra de relativt store forskydninger i ugenummeret omkring årsskiftet og forskydningerne omkring skudår, vil test med flere datoer være at foretrække. Hertil kommer, at der ikke direkte er testet datoer, som falder på en lørdag eller en søndag, samt at ugenumrene kun er testet ud fra mandage. Hvis Date-klassen evt. skulle genbruges i en anden sammenhæng, ville det være rart at vide, at disse områder er testet. For at få en mere omfattende test anvendes en maskinel kontrol. En maskinel kontrol er både hurtigere og sikrere end en manuel kontrol ved stigende datamængder, under forudsætning af et sikkert datagrundlag, og at kontrollen bliver udført korrekt. Ulempen er, at der skal udvikles noget midlertidig kode, som også bør testes. Fordelen ved en manuel kontrol er, at den er mindre tidskrævende at udføre ved små datamængder, og at den erfarne tester kan foretage en løbende evaluering under processen. For at kunne udføre kontrollen skal der være et sammenligningsgrundlag. Sammenligningsgrundlaget blev udarbejdet vha. de indbyggede datofunktioner i MS-Excel. Det færdige grundlag blev herefter importeret som en separat tabel i Aftalekalenderens database. Tabellen dækker følgende perioder: begge år inkl do. Perioderne er valgt ud fra, at de indeholder både årtusindskifte og århundredskifte, hvilket er interessant pga. af skudår. Figur 6-1 I figuren ovenfor ses starten af tabellen, der anvendes som testgrundlag. På nær datoen der er i datoformat, er de øvrige attributter i heltalsformat. Efter beregninger i Excel blev værdierne sammenholdt med papirkalenderne efter samme princip som beskrevet ovenfor. Det viste sig, at ugenumre ikke kunne bruges direkte, idet januar iflg. Excel altid starter med uge 1, hvilket er en anden måde at nummerere ugerne på, end vi anvender i Danmark. Ugenumrene blev tilpasset side 50

3 manuelt, idet der dog hovedsageligt var tale om en forskydning på en uge, hvilket gør, at der kunne rettes for et år pr. arbejdsgang. Kort beskrivelse af kontrollen Ved udførelse af kontrolprogrammet kontrolleres datoen ud fra dag, måned og år. Ud fra datoen beregnes og kontrolleres ugenummeret. Der regnes frem fra datoerne lige før de to perioder (dvs. henholdsvis og ) til testdatoen. Beregningen sker ved at beregne talværdien for startdatoen og tillægge linienummeret. (figur 6-1). Ud fra det beregnede tal dannes et Dateobjekt med metoden fromdaynummer(). Herefter sammenlignes de beregnede datoværdier og ugenummer med tabellens værdier. Ved fejl udskives de fejlbehæftede datoer. Testprogrammet blev kontrolleret ved at indføre nogle fejl i tabellen ved en ekstra kontrolkørsel. Programmet fremgår af kildekoden (test.datotest). Vedr. tabellen Testdato, se Databasefil side 38. Resultat Testen af datoer forløb uden bemærkninger. Testen af ugeberegningen forløb med nogle afgrænsede fejl vedr. uge 1 og uge 52/53, således at ikke alle datoer i årets første og sidste uge gav det rigtige ugenummer. Et eksempel på fejlen er fredag den 2. januar 2004, som programmet beregnede som uge 53 (burde være 1). De øvrige datoer i den samme uge gav det rigtige resultat. Fejlen fremgik ikke af Aftalekalenderen, idet ugenummeret blev beregnet ud fra mandag. Fejlen blev rettet på en time ved at ændre ugeberegningen. Herefter kørte kontrollen igennem uden fejl. Bemærkninger til testberegningerne Testen bygger primært på fremregning af datoerne, hvor metoden fromdaynumber() kaldes med forskellige værdier. Testen kunne forbedres ved også at regne baglæs ud fra datoen i tabellen. Den beregnede dato sammenlignes her med udgangspunktet (dvs. henholdsvis og ). Herved bliver metoden todaynumber() kaldt med forskellige datoer. Endvidere kunne der udbygges med kontrol af ugedagen. Af tidsmæssige årsager er testen ikke blev udbygget på de ovennævnte områder. 6.3 Funktionstest Formål Formålet med funktionstesten er på en systematisk måde at kontrollere programmets funktionalitet for at sikre, at programmet fungerer som forventet og løser opgaven. Der tages udgangspunkt i opgaverne ved udarbejdelsen af en testsuite. Testsuiten bør indeholde input, der dækker både typiske og ekstreme tilfælde samt de resultater, der forventes ( Peter Sestoft, 1998). side 51

4 Afgrænsning Ved valg af testopgaver til denne test er der specielt fokus på den grafiske brugergrænseflade, hvor kalenderen ses med de bookede aktiviteter. Dette skyldes, at netop denne del af opgaven er særlig velegnet til denne form for test på grund af de mere komplekse sammenhænge, der indgår i opbygningen af brugergrænsefladen. Forud for testen ligger udviklerens alm. aftestning samt en brugertest (der ikke må forveksles med testen i afsnit 6.4). Brugertesten er foretaget ved, at brugeren (tandlægen) selv har defineret opgaverne med udgangspunkt i kravspecifikationen. Udvikleren har givet en introduktion af funktionerne, idet brugervejledningen ikke har været færdig på testtidspunktet. Brugertesten forløb uden bemærkninger. Opgaverne, der kan testes på, er selvfølgelig begrænset til de funktioner, der er til rådighed i den nuværende version, hvorved ikke alle funktioner ifølge kravspecifikationen er til rådighed. Testen er foretaget af udvikleren og er foregået på den samme computer, som udviklingen af programmet er foregået på. Hovedpunkter i testen med resultater Testsuiten med de enkelte resultater fremgår bilagene afsnit 9.7. Navigation i kalenderen Målet med denne del er at teste funktionerne bag navigationsknapper. Testen indeholder forskellige kombinationer af brugen af knapperne. Derudover er det undersøgt, om det er muligt at bladre længere end et år frem, hvilket netop er grænsen ved kun at anvende månedsknapperne (se figur afsnit 9.7.). Tilsvarende testes muligheden for at gå tilbage i tiden. Testen forløb uden fejl. Valideringskontrol af museklik på brugergrænsefladen Målet med denne test er at sikre en korrekt beregning/håndtering af museklik, når brugeren klikker på brugergrænsefladen. I denne test er der fokus på klik, der sker uden for områder, hvor der ligger funktionalitet. Hvis denne test afvikles som forventet med korrekt validering, og en test af funktionerne bag ugens 5 søjler giver et korrekt resultat, giver det en øget tiltro til systemets beregninger, når brugeren klikker på brugergrænsefladen. Testen er ikke en ren funktionstest /blackbokstest, idet koden er forsynet med nogle tekster, der udskrives afhængig af, hvilken gren af koden, der bliver nået. Testen forløb uden fejl. Booking i randområderne (udkanten) af ugeoversigten Testen er en grundlæggende test af booking af aktiviteter. Da aktiviteten patientbehandling er en udvidelse af aktivitet, har jeg udvalgt netop denne type til aftestning. I forbindelse med løsning af opgaven skal flere ting observeres som beskrevet under forventet resultat. Opgaven indeholder i begrænset omfang således også patientoprettelse og kontrol af information vedr. aftalte patientbehandlinger. Testen forløb uden fejl. side 52

5 Booking, fokus på korrekt visning af fortsat behandling Et vigtig element i kravspecifikationen er visningen af, at en patient fortsætter behandlingen, hvis patienten umiddelbart efter har tid hos den anden behandler. Denne visning bygger på nogle beregninger, som denne tests mål er at efterprøve. Testen forløb uden fejl. Sletning af aftaler Testens hovedformål er at afprøve sletninger af aftalerne og genskabe dem ved genbooking. Herudover er der forsøgt at slette en patient, hvor der er registreret aftaler, hvilket ikke bør kunne ske. Testen forløb uden fejl. Booking med fokus på min. og max. behandlingstid I forbindelse med opstart af booking (bookingvindue åbnes) beregner systemet en minimum og maximum behandlingstid. Fra brugerens synspunkt ses dette ved at minus og plusknappen ændrer status, hvis et klik på knappen gør, at en grænse kan overskrides. Se evt. figur 4-3 side 34. Funktionen sikrer, at der ikke sker en ubevidst overlapning af aktiviteterne. Resultatet forløb uden fejl på nær den sidste test, hvor resultatet er forkert. (Efterfølgende blev fejlen undersøgt nærmere med tilsvarende test.) Beskrivelse af testfejl: For tandplejeren er der den afsat frokost fra 12:00-13:00. Derudover er der ikke booket andre aktiviteter ind den dag. Ved en booking, der starter kl. 8:00, bør den max. behandlingstid være til kl , hvor der frokost. Systemet beregnede klokkeslættet til kl. 18:00, der er klokkeslættet for dagens afslutning. Fejlen er uheldig, idet brugeren får en falsk sikkerhed mod overlapning og skal derfor rettes. De efterfølgende tests for at komme fejlen nærmere peger på, at hvis dagen for behandleren indeholder mere end to aktiviteter (mere end den igangværende), er beregningen ok. Fejlen forventes at kunne rettes på en ½ dag. Konklusion på funktionstest Resultatet af testen er, at de testede funktioner virker som forventet, dog med en enkelt undtagelse, der kræver en rettelse. Testen kan ikke give nogen garanti for, at der ikke findes andre fejl, men testen øger tilliden til de anvendte funktioner. Af tidsmæssige årsager er testen blevet begrænset. 6.4 Test af Aftalekalenderens brugervenlighed Formål Denne tests formål er at finde brugsproblemer med den nuværende version af Aftalekalenderen. I forbindelse med design af brugergrænsefladen er der anvendt papirprototyper i skitseform og i endelig form, hvilket burde begrænse antallet af alvorlige brugsfejl i den nuværende form. Som de øvrige brugervenlighedstest under design fasen er testen udarbejdet som tænke højt test (Lauesen, 2001). side 53

6 Testen vil ikke kunne afdække alle fejl, men vil give en idé om antallet og typen af fejl. Testen kan opfattes som en stikprøve, hvor de fejl, der er i materialet (programmet), er repræsenteret i stikprøven med en vis sandsynlighed. Afgrænsning Af tidsmæssige og ressourcemæssige årsager er testen afgrænset til kun at omfatte én person. Det optimale antal er omkring 5-6 personer. (Lauesen, 2001). Testopgaverne er lavet ud fra kravspecifikationen med fradrag af den funktionalitet, der ikke er implementeret endnu. Endvidere er der taget udgangspunkt i projektets prioriterede række af usability faktorer, der lægger mere vægt på effektivt at bruge for den erfarne og mindre vægt på let at lære. Dette medfører, at testen starter med (efter indledning hvor formålet og tænke højt test forklares), at testlederen giver en introduktion, hvor der kort vises betjeningen af systemet, uden at der forklares, hvilke arbejdsopgaver, der skal løses. For at få et billede af effektiviteten tælles antallet af museklik, og testlederen spørger ind til løsningen af opgaverne. Endvidere er der fokus på forbedringer i tidsbruget på løsning af en konkret opgave. Testpersonen Den foretrukne testperson til testen ville være en repræsentant for brugergruppen, som ikke har deltaget i udviklingsprocessen. Denne person vil ikke have nogen mening om de fundne løsninger, vha. papirprototyperne, og vil være mere kritisk over for systemet. Det var imidlertid ikke praktisk muligt. Computer der blev anvendt til testen Bærbar pc, men overholder på de øvrige punkter i kravspecifikationen. Testlog Under testen skriver testlederen en testlog. Et resumé af loggen og kommentarer er givet under hvert spørgsmål i punktet Kommentarer til opgaven. Opgave 1 Tema: Bladre i kalenderen og finde en bestemt dato Udgang for løsning af delopgaverne: 6. marts 2003 (Systemdato) find nemmest muligt nedenstående datoer og returner til udgangspunkt efter hver delopgave: 1a: b: c: d: e: f: Kommentarer til opgaven Der blev talt antal museklik på kalenderens navigationsknapper som et mål for, hvor effektivt /hvor hurtigt det er muligt at finde frem til de enkelte datoer i kalenderen. Alle datoer blev nået på 1-2 museklik (der er det mindst mulige) på nær , hvor der blev anvendt 3. Resultat: OK side 54

7 Begrundelsen for at testpersonen skal finde tilbage til dags dato skyldes, at man i det daglige arbejde veksler mellem 2 perioder, nemlig den aktuelle uge og i ugerne et halvår frem. Dvs. at der er meget bladren frem og tilbage. Resultat: Testpersonen løste opgaven med at genfinde dags dato men bemærkede, at det burde være muligt med et enkelt klik at vende tilbage til dags dato. Idéen er medtaget som forbedring a2 i bilaget afsnit 9.6. Opgave 2 Tema: Aflæsning af information Testlederen vælger en forudbestemt uge i aftalekalenderen, hvor der er afsat mange aktiviteter. Hjælp: Farvekodebeskrivelse ( rød betyder tandplejers patientbehandling osv.) Spørgsmål: Hvad sker der i denne uge og hvornår? Start venligst mandag kl. 8:00. Kommentarer til opgaven Formålet med denne opgave var at sikre sig, at kalenderen var forståelig. Denne type opgaver kan tjekkes med en papirprototype men blev gentaget her, fordi den tidligere havde givet problemer omkring aflæsningen af tidspunkterne, og fordi opgaven er helt central. Resultat: OK. Testlederen måtte spørge lidt ind for at få alle oplysninger frem, men så kom svaret prompte. Der mangler følgende funktionalitet : Patientens navn kommer frem ved at højreklikke med musen på en patientbehandling Muligheden for at få markeret den enkelte aftale med en indramning, hvilket som forventet blev bemærket af brugeren. Funktionaliteten er medtaget under use case 2.1 i bilaget afsnit 9.6 Opgave 3 Tema: Booking Spørgsmål: delopgave a: Den 10. december 2003 kl. 8:30-9:00 skal du selv til tandlægen for at få en alm. undersøgelse, og den efterfølgende halve time skal du have renset tænder hos tandplejeren. delopgave b: Du har en ny patient Peter Jensen i telefonen, og han skal til behandling den 10. december 2003 hos tandlægen og tandplejeren. Han ønsker at komme til tidligst muligt. Behandlingstiden skal være 45 min hos tandlægen og 30 min. hos tandplejeren. Gæt selv de evt. manglende oplysninger eller spørg. side 55

8 delopgave c: Der skal den 10. december 2003 fra kl. 8:30 afsættes 15 min til at fjerne tråde på patienten Ole Hansen. Kommentarer til opgaven Delopgave a er lige til at løse, idet der er tale om simpel booking. I delopgave b skal der byttes om på behandlingerne for at få den rigtige løsning, og der mangler cpr. nr. samt behandlingsforkortelser. I delopgave c er der tale om en overbooking. Resultat: OK. Cpr. nr. feltet er formateret ( xxxxxx-xxxx ), hvilket kræver, at markøren sættes først i feltet for at kunne udfylde det korrekt. Testlederen måtte konstatere, at det skal læres, for at brugeren kan gøre det rigtigt. I sidste delopgave gik det fint. Testlederen måtte gentage anvendelsen af shift-tasten i forbindelse med overbooking. Testpersonen havde lidt besvær med at anvende shifttasten på den bærbare computer samtidig med, at der skulle klikkes med musen. Opgave 4 Tema: Ændring af arbejdstid Spørgsmål/arbejdopgave: Den 4. marts 2003 starter tandplejeren sin arbejdsdag kl. 9:00, kontroller og ret Aftalebogen ud fra disse oplysninger. Kommentarer til opgaven Den 4. marts 2003 fra kl. 8:00 9:30 er der i Aftalekalenderen en hvid blok ( fri ) som viser, at tandplejeren normalt begynder sin arbejdsdag kl. 9:30. Hvis systemet havde fuld funktionalitet, kunne blokken ændres, så den kun dækkede tidsintervallet 8:00 9:00. I den nuværende version skal blokken slettes, hvorved perioden bliver grøn for ledig tid, og der skal derefter laves en ny hvid blok, der dækker tidsintervallet 8:00 9:00. Opgaven kræver en god forståelse af systemet og viden om, hvordan det gøres. Opgaven vurderes af testlederen som relativ svær med den korte introduktion. Resultat Efter nogle overvejelser fra testdeltagerens side men uden hjælp, lykkes det at løse opgaven. Det må dog betegnes som ret besværligt at løse opgaven i den nuværende version, hvilket også var forventet. Opgaveløsningen viser en god forståelsen af systemet hos testpersonen, hvilket er vigtigt for korrekt anvendelse af systemet. Opgave 5 Tema: Fri opgave hvor testdeltageren har mulig for at oprette aktivitet og patienter efter eget ønske eller stoppe Kommentarer til opgaven Opgaven bliver givet som en frivillig opgave. Opgaven kan kun forventes at give et resultat på grund af det store forretningskendskab, og at testpersonen nu har et grundlæggende kendskab til side 56

9 systemet. Der er fra testlederens side fokus på arbejdshastigheden og på testdeltagerens bemærkning. Der spørges ind til, hvordan systemet løser testdeltagerens opgave. Testlederen prøver at få et billede af, om det er et system, testpersonen kan lide. Efter testen spørges der direkte, om testpersonen kan lide det. Resultat Der er nu gået 1½ time, siden testen begynde, men testdeltageren ønsker selv at fortsætte med egne opgaver for prøve systemet noget mere. Det er meget tydeligt at arbejdshastigheden vokser, efterhånden som rutinen vokser. Testpersonen nævner søgningen af nye tider som et væsentlig plus i forhold til den manuelle aftalekalender. Testpersonen er ikke helt glad for kombinationen af tastatur og mus, men måske er det kun den bærbare pc s placering af taster, der er grunden til den uhensigtsmæssige betjening. Testlederen mener ikke, at det reelt er et problem, men kan ikke bevise det. Kombinationen af taster anvendes kun ved sletning eller oprettelse af en overbooking. I forbindelse med afprøvningen stod det klart, at når de sidste funktioner i systemet er på plads, skal man ikke kunne vælge en patient på højresiden ved at klikke på en patientbehandling i kalenderen. De to sider skal fungere uafhængigt af hinanden. På venstresiden (kalenderen) kan man med et venstre klik oprette eller rette en booking, med et højreklik kan man få vist indholdet af en enkelt aftale uden mulighed for at rette. I den nuværende version glemmer brugeren ofte, at man allerede har en patient fremme og klikker på venstresiden for at få en ny patient frem, hvilket medfører en fejlmeddelelse. Afslutningsvis udtrykker brugeren tilfredshed med systemet og ser frem til at anvende det, når de sidste funktioner er på plads. Bemærkninger om hastighed (performance) I forbindelse med aftestningen har der ikke været direkte fokus på performancekravene, som er nævnt i kravspecifikationen. Dette skyldes, at programmet fungerer væsentligt hurtigere end forudsat. Selv om ODBC forbindelse er relativ langsom er mængden af data, der overføres, ret beskeden. Det er tydeligt, at brugerne ikke venter mærkbart ved udførelsen af opgaverne. Den største belastning af systemet er i forbindelse med oprettelse af en aktivitet, hvor aktiviteten skrives i databasen, og ugens aktiviteter genindlæses til strukturen, hvilket afvikles umiddelbart uden ventetid. Genindlæsningen kunne ved en mindre ændring reduceres til den aktuelle dag. Træstruktur-designet understøtter denne forbedring, hvilket også var én af ideerne bag designet, således er det kun er en gren og ikke hele træet, der skal udskiftes. Det er min vurdering, at forbedringen bør laves, da metoden, der skal laves, er simpel, og reduktionen i datamængden er på faktor 5 (snit). En performence test vil kræve, at databasen var fyldt med en del data for at give et realistisk billede. Til brug for hurtig at udsøge og sortere posterne er der opbygget indeks for datofeltet og for felterne til registrering af tidspunkterne i aktivitetstabellen. Indeksene gør, at udsøgningen i forbindelse med visning bliver hurtigere, men opdateringerne bliver langsommere, idet indeksene skal opbygges. side 57

10 Ved opdatering af aktiviteterne foretages beregningen af feltet fortsat. I den nuværende version opdateres hele patientbehandlingstabellen, men opdateringen skal begrænses til den aktuelle dags behandlinger. Med et stigende antal poster vurderer jeg, at denne forskel vil være meget markant. De 2 forbedringer er medtaget i afsnit 9.6 som punkt c Konklusion på produktet Med udgangspunkt i de gennemførte tests vurderes Aftalekalenderens funktionalitet ganske positivt. De grafiske brugergrænseflader og de tilhørende funktioner løser generelt deres opgaver ganske godt. Der skal dog laves nogle få layoutmæssige rettelser for at gøre dem færdige. Udviklingen har været tidsmæssig begrænset, men alligevel kan produktet løse de fleste opgaver. Dette gælder både set fra brugernes synspunkt, men også fra et teknisk synspunkt. Aftalekalenderen løser arbejdsopgaverne vedr. navigation og visning af kalenderen, hvilket ligeledes gælder booking af aktiviteter og visning af detaljer vedr. den enkelte patient så som stamoplysninger, fremtidige patientbehandlinger og tidligere patientbehandlinger. Patientoplysningerne kan hentes ved udsøgning. Hertil kommer implementeringen af fortsat behandling som beskrevet i kravspecifikationen. Primært på 2 områder mangler funktionaliteten i forhold til den optimale løsning 10, nemlig flytning af patientbehandlinger (use case 3) og indrapportering/visning af dagens aktiviteter i listeform (dagsoversigten, use case 5). 1. Flytning kan i den nuværende udgave foretages ved at slette en patientbehandling og oprette en ny patientbehandling på rette dag/tidspunkt, men det løser ikke opgaven fuldt ud. Automatisk flytning er væsentlig for klinikken, idet systemet vil kunne forbedre effektiviteten og sikkerheden i arbejdsopgaven væsentligt. 2. Dagsoversigten skal anvendes til indrapportering af dagens undersøgelser og udeblivelser. Desuden kan behandlerne lade øjnene løbe henover navnene for at få et overblik, men allerede under forundersøgelsen blev det vurderet, at det ikke var muligt at få denne del implementeret under projektperioden. Ud fra brugertesten og usability testene vurderes det, at den del, der er lykkedes bedst, er visning og navigationen i kalenderen, hvilket dog også svarer til, hvor hovedvægten af ressourcerne er lagt. Det gælder både grafisk og teknisk design. Brugerne navigerer f.eks. nemt rundt i kalenderen og kan ved brug af højst 2 klik nå de allerfleste datoer. Herefter kommer tilgangen til oplysningerne fra patientsiden, hvilket er nyt i forhold til papirkalenderen. Løsningen er en god hjælp, når der arbejdes med information vedr. den enkelte patient. Som det fremgår af testene er resultatet, at produktet sandsynligvis er ret brugervenligt, vurderet ud fra den prioritering af brugervenlighed, der er foretaget. Produktet er effektivt at bruge, brugerne kan lide systemet, men det kræver nogen indlæring for at kunne anvende det. 10 Mål der rækker ud over projektperioden side 58

11 Uddannelsesbehovet formodes at kunne holdes inden for kravspecifikationens rammer på 2 arbejdsdage. Det vurderes ud fra målgruppen, at en enkelt dags undervisning vil være nok. I afsnit 9.6 findes en oversigt, der sammenholder løsningen med kravspecifikationen, herunder use case beskrivelserne. Desuden indeholder bilaget oplysninger om kendte tekniske mangler og forslag til forbedringer. Den samlede tid, der skal anvendes for at fremstille en endelig version af programmet, er vurderet til ca. 10 dage. Kommentar til fleksibilitet Konstruktionen af programmet er relativ fleksibelt. Fleksibiliteten er ikke direkte testet, men selve konstruktions komponenter giver en god fleksibilitet. Her kan nævnes følgende punkter: Valg af udviklingssproget Java gør, at løsningen i høj grad er platform uafhængig. Forbindelsen til databasen er en JDBC-løsning, hvilket gør, at databasen kan udskiftes med en anden database, hvortil der, for den aktuelle platform, findes en JDBC-driver. En udskiftning af ODBC-JDBC broen til en ren JDBC forbindelse forventes at give en hurtigere løsning. Skærmopløsningen kan ændres, idet komponenterne vil tilpasse sig. Arbejdstiden kan ændres fra de 8:00-18:00 til et andet tidsinterval. Dog ikke over midnat pga. sommertid. 11 Lørdagsåbent/ flere behandlere vil også kræve en ændring i koden. Se kommentarer til figur 3-9 datastruktur for visning af kalender på side Konklusion på processen Udviklingsmetoden, som den er beskrevet i metodeafsnittet, har givet en god styring og struktur under projektet. Metodens styrke har været at bevare fokus på målet samt udnytte de mange muligheder, der lå i projektet. Projektet, der er udviklerens første, har givet viden og forståelse inden for mange området, der har været berørt. Opgaven har involveret en bred vifte af værktøjer/arbejdmetoder for at skabe løsningen. Resultatet skal ses som en samlet proces fra forundersøgelse til konklusion/afslutning efter den sidste test. Under uddannelsen har jeg erhvervet viden i de enkelte fagområder, men kun i mindre grad afprøvet denne viden samlet. Jeg har lært meget af at lave en samlet løsning. Den beslutning, der bliver taget på et hvilket som helst tidspunkt, får betydning for resten af processen. Det gælder både positivt og negativt. Virkningen af beslutningerne undervejs stopper ikke, når produktet er færdigt, men har også stor betydning, når det skal vedligeholdes. Det er svært at udvælge én ting, der har været særlig væsentlig, men udviklingen vha. papirprototyper har ud fra en ressorcemæssig synsvinkel været særdeles effektiv. Desuden har det været utrolig spændende og givtigt at udvikle koden til løsningen. Under uddannelsen løses mindre opgaver i de forskellige områder, men det forøger viden at skabe en samlet løsning, hvor tingene skal virke sammen. Tidsplanen i afsnit 2.6 holdt indtil eksamensperioden startede, herefter måtte det konstateres, at de andre fag krævede en del flere ressourcer, end der var afsat. Hertil kommer, at der er blevet anvendt flere timer til kode og design end reserveret i tidsplanen for at nå den helhed, der er skabt. 11 På forsiden er der anvendt intervallet 9:00-15:00. Kræver kun rettelse i klassen Konstanter. side 59

12 Efter forlængelsen af projektet, blev testfasen udvidet med usability testen for at kunne bedømme brugervenligheden. side 60