BoBo Projects. - et projektstyringssystem

Transkript

1 BoBo Projects - et projektstyringssystem DAT1 PROJEKT 2008 GRUPPE D101A INSTITUT FOR DATALOGI AALBORG UNIVERSITET DEN 19. DECEMBER 2008

2

3 Titel: BoBo Projects Tema: Udvikling af programmel Projektperiode: DAT1, efterår 2008 Projektgruppe: d101a Deltagere: Institut for Datalogi Aalborg Universitet Selma Lagerlöfs Vej Aalborg Ø Telefon Fax Synopsis: Bo Hedegaard Andersen Peter Schmidt Freiberg Michael Garde Jimmy Merrild Krag Vejleder: Andreas Munk-Madsen Denne rapport er dokumentationen for et semesterprojekt på DAT1 (3. semester) ved Aalborg Universitet, og dokumenterer udviklingsprocessen af et projektstyringssystem, hvis målgruppe er semestergrupper på Institut for Datalogi. Rapporten starter med en evaluering og erfaringsopsamling af projektprocessen, og indeholder derudover de udviklingsdokumenter der er udformet (analysedokument og designdokument), beskrivelser af processen omkring disse, samt beskrivelser af processer og resultater for programmering, test og useability-evaluering af programmet BoBo Projects. Oplagstal: 6 Sidetal: 90 Bilagsantal: 4 Afsluttet: 19. december 2008 Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4

5 Forord Denne rapport er overordnet i tre dele. Første del som starter på side 1 rummer studierapporten for dette projekt, og er en diskussion og refleksion af projektets forløb, samt de erfaringer vi har gjort os i semesterets forskellige faser. Anden del som starter på side 15 rummer studierapportens bilag, hvilket består af dokumentationen for projektets analyseog designfase, samt en kort introduktion til Programmering, Test og Evaluering. Sidste del af rapporten er det vedlagte digitale materiale som blandt andet rummer kildekode, test og dokumentation af kildekoden. Læsevejledning Der vil igennem rapporten fremtræde kildehenvisninger, og disse vil være samlet i en kildeliste bagerst i rapporten. Der er i rapporten anvendt kildehenvisning efter Harvardmetoden (Bryant, 2007), så i teksten refereres en kilde med (Efternavn, År). Denne henvisning fører til kildelisten, hvor bøger er angivet med forfatter, titel, udgave og forlag, mens Internetsider er angivet med forfatter, titel og dato og url. Figurer og tabeller er nummereret i henhold til kapitel, dvs. den første figur i kapitel 7 har nummer 7.1, den anden, nummer 7.2 osv. Forklarende tekst til figurer og tabeller findes under de givne figurer og tabeller.

6

7 Indhold Indhold III Studierapport 1 1 Indledning 3 2 Erfaringer Analyse Design Programmering Test Usabilityevaluering Opsummering 13 Bilag 15 I Analysedokument 17 4 Opgaven Formål Systemdefinition Omgivelser Problemområde Anvendelsesområde Problemområde Klynger Struktur Klasser Hændelser Anvendelsesområde Brug Funktioner III

8 INDHOLD 6.3 Brugergrænsefladen Videre udvikling Den tekniske platform Anbefalinger Strategi Udviklingsøkonomi II Designdokument 43 8 Opgaven Formål Rettelser til analysen Kvalitetsmål Teknisk platform Udstyr Basisprogrammel Systemgrænseflade Designsprog Arkitektur Designkriterier og arkitektoniske krav Generiske design beslutninger Komponent arkitektur Eksemplariske design Komponenter Modelkomponent Funktionskomponent Systemgrænsefladekomponent Brugergrænsefladekomponent Teknisk platform komponent Programmering SVN kommandoer Slet Opgave Serializable Eksempel Usabilityevalueringsplan Formål Hovedspørgsmål Brugerprofil Deltagere og roller Evalueringsmetode IV INDHOLD

9 13.6 Opgaveliste Lokalitet og udstyr Dataopsamling Testplan 71 III Programmering Programmering Udviklingsmiljø Programbeskrivelse Driftsmiljø Dokumentation IV Test & Evaluering Test Usabilityevaluering Opgaver Identificerede problemer Problemfordeling Interviewguide Interviewreferat: Testperson Interviewreferat: Testperson Litteratur 89

10

11 Studierapport

12

13 1 Indledning Denne rapport er dokumentationen for et semesterprojekt på DAT1 (3. semester) ved Aalborg Universitet. Under semestertemaet Udvikling af programmel, har det jf. (Studienævn for Naturvidenskab, 2008) været vores opgave, at opnå en solid viden om datalogiens grundlæggende principper, hvilket underbygges af kurser i Systemanalyse og Design, Algoritmik og Datastrukturer, Objektorienteret programmering, samt Design, Implementering og Evaluering af Brugergrænseflader. Førstenævnte tre skal give værktøjer til udvikling og implementering i forbindelse med programudvikling, hvor sidstnævnte har til formål at levere de nødvendige principper for usability og evaluering af dette. Under semestertemaet blev der stillet en række projektforslag for udvikling af administrative systemer, hvoraf forslaget omhandlende projektstyring blev udvalgt. Denne rapport dokumenterer således en systemudviklingsprocess for et administrationssystem, der mere afgrænset har til formål at fungere som en hjælp til administration af et semesterprojekt for projektgrupper ved Institut for Datalogi v. Aalborg Universitet. Formålet med systemet er at begrænse det administrative arbejde ved et semesterprojekt, og dermed give projektgrupperne mere tid til selve projektarbejdet. For at efterleve deadline for analysen startede vi således systemudviklingen med en analyseproces, hvor fokus blev lagt på at undersøge og analysere de potentielle brugere og det problem, som systemet forventer at skulle løse. Deraf blev produceret et analysedokument som dokumentation for det udførte arbejde (se Bilag s. 19). Kulminationen af analyseprocessen blev et review af analysedokumentet. Den efterfølgende designproces blev udført på samme vis som i analysefasen, men hvor der i stedet blev lagt vægt på at designe et system med henblik på en egentlig implementering (se Bilag s. 45). I projektets sidste fase har fokus lagt på implementeringen af det pågældende system, samt relevante tests og usabilitevalueringer. På figur 1.1 på den følgende side kan det ses hvad tid de forskellige faser startede og sluttede, samt andre milepæle i projektforløbet. 3

14 6. sep. - Start af analysefase 7. okt. - Deadline for aflevering af analysedokument 7. okt. - Start af designfase 9. okt. - Review af analysedokument 10. okt. - Start på korrektur af analysedokument 22. okt. - Start af programmeringsfase 27. okt. - Slut på korrektur af analysedokument 10. nov. - Deadline for aflevering af designdokument 13. nov. - Review af designdokument 14. nov. - Start på korrektur af designdokument 15. nov. - Slut på korrektur af designdokument 30. nov. - Kodestop for programmeringfase 1. dec. - Start på studierapport 4. dec. - Usabilitytest af BoBo Projects 18. dec. - Rapport sendes til tryk 19. dec - Deadline for aflevering af rapport Figur 1.1: Tidslinje for projektforløb 4 1. Indledning

15 2 Erfaringer De følgende afsnit rummer hver en diskussion samt reflektion over de erfaringer, vi har gjort os i forbindelse med udviklingen af BoBo Projects. 2.1 Analyse Den endelige standard til analysedokumentet kom to uger inden vi skulle aflevere til review, og det var først der, vi fik overblik over hvad analysedokumentet skulle indholde. Det er klart, at det er utopi at tro på at man kan få optimale betingelser ved start af et projekt. Dette er vi nu klar over til en anden gang Forvirring omkring begreber At få hul på analysens emner har for os været en af de største udfordringer, idet vi ikke har haft ordentlig forståelse for, hvad disse gik ud på. Eksemplerne i (Mathiassen et al., 2001,Del VII) hjalp ikke meget på forståelsen af analysens mange begreber, og gav ofte mere anledning til forvirring end det gavnede. Vi havde eksempelvis misforstået ideen med en aktørtabel, idet vi troede en aktør var en person, og ikke en rolle en person kunne påtage sig. Dette fandt vi ikke tydeligt nok beskrevet i eksemplerne i bogen, hvor de forskellige aktører lige så godt kunne have været forskellige personer, og ikke forskellige roller. Reviewet hjalp dog betydeligt med at klarlægge mange af begreberne, så selv om der efterfølgende var mange rettelser, var disse overkommelige og lærerige. Der gik omtrent to uger med rettelser af analysedokumentet, hvilket hovedsageligt var misforståelser af begreberne, samt mangler UML tegneprogram Det har ikke været let at finde et UML tegneprogram, der er nemt at bruge, overholder standarden fra (Mathiassen et al., 2001) nogenlunde, og kan tegne de diagrammer, som vi havde brug for, til fulde. Microsoft Visio (Microsoft Corporation, 2008a) blev afprøvet, men da der er en begrænsning på, hvor mange pile der kan gå til og fra de forskellige hændelser og klasser m.m., uden de lægger sig oveni hinanden, og derved bliver grimme og uoverskuelige, blev Visio fravalgt. Violet (Horstmann and Pellegrin, 2008), et java baseret UML tegneprogram, blev også afprøvet, men også her var der problemer. Violet kan lave nogle pæne klassediagrammer, der ganske nemt kan opstilles pænt, men ligesom med Visio lægger sig let oveni hinanden, og derfor blev også Violet forkastet. 5

16 2.2 Design Til sidst fandt vi Visual Paradigm (Visual Paradigm International, 2008), der dog ikke var gratis, men havde en gratis version med begrænset fuktionalitet. Denne begrænsning var dog ikke større end, at vi sagtens kunne tegne vores diagrammer, så de blev pæne og overskuelige. På trods af manglende funktionalitet, mindre fejl og mangler ved programmet, blev det i sidste ende (måske af mangel på bedre konkurrence) Visual Paradigm vi anvendte til at tegne vores UML diagrammer Hvornår er det færdig? Man kan hele tiden ændre på klassediagrammet, som hænger sammen med mange andre ting, som så lige skal ændres lidt, og så videre. Det gode spørgsmål er så hvornår man skal sige stop: Et godt udgangspunkt for hvornår analysen er god nok, er når der er sammenhæng mellem de forskellige dele, ingenting der modsiger noget andet, og der ikke er store åbenlyse fejl, der skal rettes, men det blot er småting og finpusning, der er tilbage. Visse ting har vi dog erfaret er nødvendige for at analysen er bare nogenlunde færdig. Dette er et par gode og gennemtænkte brugsmønstre, da disse anvendes meget især i designfasen, men også andre steder i analysen. 2.2 Design I begyndelsen af designfasen indså vi hurtigt at vi manglede gode brugsmønstre fra analysen, hvilket i vores situation var nødvendigt for at identificere kravene til systemet. Vi kunne derfor ikke gå i gang med designfasen før analysefasen var tilpas sammenhængende og komplet. Blandt andet sekvensdiagrammet var en større udfordring, især fordi vi ikke havde modtaget undervisning i hvordan disse laves. Det viste sig imidlertid at sekvensdiagrammer illustrerer hvordan koden udføres, for et specifikt brugsmønster, men da vores brugsmønstre ikke var udførlige nok, besværliggjorde det udformningen af disse sekvensdiagram. Brugergrænsefladen var ikke helt ligetil at designe, uden et klart overblik over hvad det var brugeren skulle kunne gøre de forskellige steder, men systemets hovedside blev dog designet, og de resterende sider blev skitserede på tavlerne i grupperummet, hvilket vi erfarede i reviewet var ganske udmærket. Også i designfasen var de mange forskellige begreber i OOA&D bogen (Mathiassen et al., 2001) svære at gennemskue, især da der også var nogle, der gik igen i DEB, men som ikke nødvendigvis havde samme betydning. Der herskede eksempelvis en del forvirring omkring tabel 8.1 på side 46 Prioriteringstabellen for designkriterier og tabel 6.6 på side 38 Prioriteringstabellen for usability og user experience. Skemaerne ligner ved et første øjekast hinanden, men forskellen i hvad de beskriver er dog markant større end det umiddelbart ser ud til. Den førstnævnte handler om hvilke prioriteringer, vi har i forbindelse med den tekniske side af systemdesignet, mens den anden tabel er vores prioritering af hvilke af brugerens oplevelser med systemet, der skal have høj eller lav prioritet. Prioriteringstabellerne var for hele gruppen et rigtig godt udgangspunkt for hvilke elementer af systemudvikling vi skulle lægge vægt på, og hvilke vi med god samvittighed kunne nedprioritere. At de to tabeller så 6 2. Erfaringer

17 2.3 Programmering skabte forvirring var uheldigt, men efter review af designdokumentet stod forskellen rimelig klar. 2.3 Programmering BoBo Projects blev, som bestemt i afsnit 7.1 på side 41, udviklet i programmeringssproget C# (C Sharp). Trods muligheden for at implementere systemet i andre sprog som C++ eller JAVA, faldt valget på C# naturligt, da dette også er samme sprog, som vi har modtaget undervisning i, i forbindelse med kurset i Objekt-orienteret programmering. C# giver mulighed for at implementere standalone- såvel som webapplikationer, og vi overvejede i begyndelsen af projektperioden at udvikle systemet som en webapplikation, idet denne løsning umiddelbart ville gøre systemet mere tilgængeligt. Vi fravalgte dog denne løsning igen, da vi frygtede at implementeringen blev for kompleks, og fokuserede i stedet på at lave en standalone applikation; hvilket vi også blev rådet til af undervisere såvel som vejleder. Det primære argument for denne beslutning var at bestræbe os på at udvikle systemet på nemmeste vis. C# tilbyder dette på fin vis, med muligheden for at bygge brugergrænseflader med Windows Forms (Microsoft Corporation, 2008c), som man kender det fra andre WYSIWYG 1 programmer. Brug af Windows Forms var dog både på godt og ondt. F.eks. var det svært at overskue og administrere den kode, som automatisk blev genereret, og administrering af brugergrænsefladens design var heller ikke så nemt som først antaget. Det var dog nemt at arbejde med i det omfang vi havde behov for det. Skulle valget af programmeringssprog være faldet på C++ eller Java, havde implementering af brugergrænsefladen formentligt taget meget mere tid, idet ingen af disse sprog har en tilsvarende nem måde at implementere brugergrænseflader på Implementering En mindre ændring i arkitekturen (se figur 10.1 på side 50), blev foretaget da programmeringsfasen gik i gang. Det viste sig unødvendigt, at modelkomponenten skulle have kontakt til den tekniske platform. Vi har i stedet ladet Funktionskomponenten overtage ansvaret for denne, primært fordi der ikke er nogle krav til, at Modelkomponenten skal kunne gemme databasen, i stedet foregår al kommunikation til den Tekniske platform via Funktionskomponenten. Generelt har det været lige til at implementere skallen af brugergrænsefladen og klasserne fra designfasen. Implementering af brugergrænsefladens funktionaliteter skulle dog vise sig at være knap så let at udføre, og krævede alternative løsninger, som ikke var, eller måske ikke bør være, forudset i designet. En af de større udfordringer, var relationen mellem objekter af typerne Opgave og Aftale abstraktion og Ressource. Vi havde oprindeligt i designfasen bestemt at relationerne skulle være lokale lister i hver opgave, aftale og ressource (se figur 11.1 på side 54), men da vi startede med at programmere, fandt vi ud af at det var bedre at implementeret en liste af par, der blev gemt i projekt-klassen. for 1 What You See Is What You Get - En populær betegnelse for programmer hvor det man ser er det man får, og den bagvedliggende kode istedet skjules for brugeren. 2. Erfaringer 7

18 2.3 Programmering at sørge for at kun én liste af relationer eksisterer. Fordelen er derved, at man kan søge på relationer uden det er nødvendigt at bruge rekursive algoritmer eller lignende for at finde alle relationer. Vi løb dog ind i en større udfordring, i forbindelse med implementeringen af Initialization-klassen. Da en instans af Inititalization, har reference til Project-instansen var det nødvendigt at kunne tilgå Initialization fra brugergrænsefladekomponenten, når data i Modelkomponenten skulle tilgåes. At sende instansen af Initialization med som argumenter, til brugergrænsefladens forskellige klasser, var ikke en mulighed med Windows Forms. Som vi så det, havde vi valget mellem at gøre Initialization static, eller at lave den til en Singleton (Nørmark, 2008). At gøre klassen static blev hurtigt udlukket da, det viste sig næsten umuligt uden en omfattende omstrukturering af koden. Valget faldt derfor på en løsning, som omfattede at lave Initialization til en Singleton, hvilket sikrer, at der kun kan laves én unik instans af Initialization, for på denne måde at sørge for, at det altid er den samme instans, vi får fat i. Enkelte ting blev ikke implementeret i BoBo Projects, primært af tidsmæssige årsager. Kommentarsystemet er ikke blevet implementeret i brugergrænsefladen, men modelkomponenten understøtter det. Se afsnittet om test ( 2.4 på modstående side) hvor dette omtales. Påmindelsesfunktionaliteten på Aftale blev ligeledes ikke implementeret, dog gemmes påmindelsesdatoen, hvis en sådan bliver tilføjet. Der mangler blot mulighed for at indtaste den i brugergrænsefladen, samt et varslingssystem for dens udløb. Todo-listen blev heller ikke implementeret. Vi fandt den unødvendig, da den information man kunne anbringe i en todo-liste, kunne findes i tidstabellen på forsiden, og i opgavelisterne. Vi havde et kursus i DIEB, hvor vi lærte at lave grafisk brugergrænseflader med Windows Forms. Et af kursusgangene handlede om DataGridView, samt DataBinding, hvilket er features til at binde data sammen med tabeller i brugergrænseflader. Vi kunne se, at DataGridView muligvis var noget, vi kunne bruge i systemet, så da vi lavede skallen af den grafisk brugergrænseflade gjorde vi plads til DataGridView. Det viste sig dog at DataGridView skulle blive mere besværligt at implementere end forventet. Vi brugte en del tid på at få det til at virke efter hensigten, men vi måtte opgive og vi fokuserede i stedet på at bruge de mere simple ListBox e. I forbindelse med at få vist en grafisk udgave af tidsplanen, blev DataGridView dog anvendt. Vi har dog ikke anvendt databinding, da denne er en speciel genereret fremstilling som ikke kunne udføres tilfredsstillende med DataBinding Dokumentation Den digitale dokumentation af BoBo Projects findes i mappen Documentation på det digitale materiale, og rummer beskrivelser af systemets klasser og funktioner, i en overskuelig html udgave. Kildekoden for BoBo Projects, i form af et Visual C# Express project, er også at finde på det vedlagte digitale materiale, i mappen Source code Erfaringer

19 2.4 Test 2.4 Test I starten af programmeringsfasen indså vi hurtigt, at den sparsomme tid vi havde til rådighed gjorde, at den planlagte testdrevne programmering måtte nedprioriteres kraftigt. Vi havde ellers planlagt at fremgangsmåden beskrevet i afsnit 14 på side 71 ville være interessant at prøve, men alene at sætte sig ind i hvordan man laver effektive tests, udover selve udformning af testen, tog for meget tid. Vi fokuserede derfor i højere grad på at få programmet færdigt nok til at kunne gennemføre usability test, hvilket viste sig at være en god ide, idet vi kun lige nåede at blive færdige til usability evalueringen. I stedet blev et mindre antal tests udført på klasserne ProjectElement, XML og Relations. Disse viste sig effektive, da en test af disse klasser ikke kan undgå at gøre brug af nogle af de andre klasse, og derfor blev en del mangler og fejl afsløret i programmet, inden disse skulle anvendes i programmeringen af den grafiske brugerflade (GUI). Især testen af XMLklassen, der tester at data i modelkomponenten kan gemmes og hentes korrekt, afslørede en væsentlig mangel i vores opsætning af DataContractSerializer, i forhold til behandlingen af relationer. Derudover er testen af ProjectElement også interessant, idet den tester om implementeringen af kommentarsystemet virker efter hensigten - hvilket den gør. Dette interessant fordi muligheden for at behandle kommentarer, netop er en af de funktionaliteter, som ikke blev implementeret i den grafiske brugerflade, men testen viser at modelkomponenten virker efter hensigten. Kildekoden for de pågældende tests er at finde i det vedlagte digitale materiale, i mappen Test under Source code. Desuden kan testen også findes i kildekodedokumentationen. Testene kan køres ved at åbne den kompilerede udgave af BoBo Projects (BoBoProjects.exe findes i det digitale materiale i mappen Bin) i NUnit (Poole et al., 2008). 2.5 Usabilityevaluering Usabilityevalueringen er inspireret af IDA-metoden (Kjeldskov et al., 2004), og følger derfor filosofien om at koncentrere sig om at finde de væsentligste problemer en bruger oplever, indenfor en meget kort testperiode - helst én dag. Dette har vist sig et klogt valg, da vores tid har været meget sparsom. Planen for usabilityevalueringen er at finde i designdokumentets afsnit 13 på side Ændringer Disse ting gør vores evaluering forskellig fra IDA. Vi har optaget processen på video, for at kunne se den igennem bagefter. Denne video kan findes i det digitale materiale i mappen Useability evaluation. Efter testen har vi har interviewet testpersonerne (Se bilagene 17.4 på side 85, 17.5 på side 85 og 17.6 på side 86). 2. Erfaringer 9

20 2.5 Usabilityevaluering Facilitatoren har i kraft af sin rolle som interviewer, været i stand til at komme med input til analysen. Det at dataloggerne sad ude af syne for testpersonerne, er valgt konsekvent udfra, at vi gerne ville undgå at testpersonerne følte sig overvåget. Samtidig har dataloggerne kunnet følge bedre med i hvad der skete på testpersonens skærm, da de ikke skulle kigge over skuldrene. Det var i Usability lab muligt at følge hvad tespersonen foretog sig, på skærme i det lokale dataloggerne sad i. Testen er blevet optaget på video, da vi havde muligheden, og tænkte at vi kunne kigge den igennem efter flere problemer senere. Det har vi dog ikke haft behov for. Et andet formål med videoen, har været at kunne kigge tilbage og afklare hvad der skete i en given situation, og bekræfte hvis der opstår tvivl om noget. Det efterfølgende interview, er blevet indført, for at give testpersonerne en mulighed for at give deres indtryk af testen, og komme med deres bud på fejl. Interviewerens spørgsmål og besvarelserne kan findes i bilagene 17.4 på side 85, 17.5 på side 85 og 17.6 på side 86 respektivt. Interviewene har givet et godt indblik i testpersonernes syn på, hvilke problemer der er mest markante i programmet, og har vist sig at være en god ide. Selvom interviewene kan give et fingerpeg til de vigtigste problemer, så er det dog ikke sikkert, at man finder alle på denne måde. Problem 10 i tabel 17.1 på side 84 er et fint eksempel herpå, og viser hvordan en fejl i systemet som opdages af dataloggerne, ikke blev opdaget af testpersonerne. Interviewene er en god ide, men det er dog nok en god ide hvis facilitatorrollen, og interviewrollen bliver skildt ad, da det som facilitator godt kan være udfordrende at holde fokus, når denne samtidig har sit eget input til problemerne. Det er dog stadig vigtigt at intervieweren ikke er tilskuer til nogle af testsessionerne Udførsel Den endelige rollefordeling i evalueringen kom til at se sådan ud: Testleder Datalogger Datalogger Facilitator / interviewer B. H. Andersen M. Garde P. Freiberg J. M. Krag Evalueringen afslørede 15 problemer i BoBo Projects. Resultaterne af vores evaluering kan ses i tabel 17.1 på side Forløb Vores opgavesæt fra designdokumentet (se afsnit 13.6 på side 68) svarede ikke helt til, hvad der var implementeret i programmet ved kodestop, så vi blev nødt til at lave dem om, så de passede til den implementerede funktionalitet. Formålet med at lave to opgavesæt, er at opgavesæt 2 arbejder videre på de data, der er blevet indført i systemet i forbindelse med opgavesæt 1. På den måde testes brugerens oplevelse Erfaringer

21 2.5 Usabilityevaluering i en anden brugsmæssig situation i test 2, fremfor at lade ham teste de samme områder af igen. Dette spiller godt sammen med IDA, da man kan komme bredere rundt, og berøre flere områder i programmet. I vores test udførte Testperson 1 opgavesæt 1, og Testperson 2 udførte opgavesæt 2. Opgavesættene kan findes i bilag 17.1 på side 81. Inden vi gik i usability-lab for at evaluere programmet med testpersoner, gik vi opgaverne igennem, og udførte dem selv for at være sikre på, at de kunne udføres uden at programmet gik ned. I forbindelse med dette fandt vi en del kritiske fejl i programmet, som blev rettet inden den egentlige test. Vi kunne selvfølgelig have ladet være med at rette dem med vilje, for at se om brugeren stødte på disse problemer, men det ville ikke give mening, at brugeren skulle stoppe op flere gange i løbet af testen fordi programmet crashede. Til gengæld har vi ladet et enkelt alvorlig problem være i programmet, nemlig problem nummer 14. Dette problem blev slet ikke opdaget af testpersonerne, da det så ud til at de nærmest forventede at programmet behandlede dataen korrekt. Dette er nok grundet at programmet ikke gav noget feedback på forkert input, men bare ændrede feltet til nærmeste korrekte. Fejl nr 2 i tabel 17.1 på side 84, er et fint eksempel på hvordan alvorlige fejl, som ikke blev fundet inden testen, blev registreres af begge testpersoner. Begge brugere registrerede denne fejl, men den var ikke blevet opdaget inden testen. Interessant var også Testperson 1 s sidste kommentar fra interviewet (se afsnit 17.5 på side 85), hvor han udtaler: Programmet så kedeligt ud, men det er jo projektstyring. Det skal jo være kedeligt for at være godt. Det er i hvert fald tydeligt at det er meningen at det skal være funktionelt, og det synes jeg er fint. Denne kommentar (se på forrige side) stemmer fuldstændigt overens med vores mål for brug beskrevet i analysedokumentets afsnit på side 37, hvor der netop fokuseres på, at systemet skal være effektivt fremfor underholdende og sjovt. Det var vores forventning, da evalueringsplanen (se afsnit 13 på side 67) blev udformet, at vi skulle udbedre de fundne usability fejl, men tidspres har dog gjort at vi måtte helt fravælge at udføre dette. Desuden blev testen først udført efter kodestop, og ikke en uge før som forventet, idet programmet ikke var tilstrækkeligt færdigt til, at testen kunne udføres. Vi ville desuden have testet kommenteringssytemet, men da vi allerede i programmeringsfasen fravalgte at implementere denne feature, måtte vi også udelade den fra testen. 2. Erfaringer 11

22 2.5 Usabilityevaluering Erfaringer

23 3 Opsummering Dette semesterprojekt har været præget af udfordringer af forskellig art. Vi har, som tidligere beskrevet, haft store problemer med at forstå nogle af de helt banale begreber og metoder i analyse såvel som design. Det har været en udfordring, som vi efter bedste evne har taget op, selvom det ikke altid var nemt at finde klare svar på de spørgsmål, vi havde. Vi har igennem analyse-, og designfasen anvendt de metoder og teorier, som vi har fået stillet til rådighed, og har arbejdet udfra den objektorienterede tankegang. Vi har således identificeret klasser og hændelser, som i designet blev viderearbejdet til en plan for implementeringen af et softwaresystem med klasser, funktioner og attributter, der dermed kunne implementeres i C#. I programmeringsfasen viste designet sig ganske implementerbart. Vi kunne implementere model-, og funktionskomponenterne samt den tekniske platform, uden at det var nødvendigt at foretage større ændringer i det oprindelige design. Under programmeringen stødte vi på en del uforudsete ting, og man kunne argumentere for, at det var designmæssige mangler, eller at det var løsninger, som måtte udtænkes i programmeringsfasen. Det var, som vi så det, grænsetilfælde, som kun understreger at vi ikke kan forudse alt. I denne sammenhæng er det en erfaring, som forhåbentlig kan give et større overblik, over designet af brugergrænsefladen, i næste systemudviklingsprojekt. Usabilitytesten gik over al forventning. Testen viste at systemet kunne køre i en brugssammenhæng, og i betragtning af at testen blev udført på kun én dag fik vi registreret 15 usabilityfejl - en ganske respektabel mængde fejl. Som optakt til testen fandt vi kritiske fejl, og selve testen viste, at der var alvorlige fejl, som vi selv havde fuldstændigt overset. At vi valgte at interviewe testpersonerne efterfølgende gav yderligere input til usabilitytesten, og disses kommentarer gav et indblik i brugernes oplevelse med BoBo Projects. Udgangspunktet for test af BoBo Projects var, at vi ville have lavet testdreven udvikling, men dette blev i stedet nedprioriteret på grund af tidspres. Vi fik dog testet nogle klasser, og fandt en række fejl som formentlig ville have voldt os problemer senere i programmeringsfasen. At vi fandt dem tidligt betød også, at vi havde god tid til, at få dem rettet inden kodestop. Tidspres har netop været en af de ting som har præget dette semester. Hvad der ligger til grund kan være flere ting, men at vi kun har været 4 i denne gruppe bærer nok det meste af ansvaret. Derudover har de mange rettelser, vi løbende har måttet lave, ikke mindst efter review af analysedokumentet, også gjort at meget af den tid som vi skulle have brugt på designfasen, i stedet er gået til rettelser. Produktet af dette semesterprojekt er således blevet en rapport med dokumentation af systemudviklingsprocessen for projektstyringssystemet BoBo Projects. Derudover er der også blevet udviklet et program, der trods nogle mangler kan køre, og ikke mindst anvendes i en brugssammenhæng, uden systemet bryder ned som følge af kritiske fejl. 13

24

25 Bilag

26

27 Del I Analysedokument 17

28

29 4 Opgaven Den følgende tekst er en analyse, som danner grundlag for udviklingen af et system til administration af et semesterprojekt. Denne analyse ligger således forud for en egentlig implementation af et projektmanagementsystem og lægger derfor i højere grad sit fokus på de kommende brugere og deres behov for at administrere projektarbejdet. Analysens indhold benytter Objekt Orienteret Analyse & Design (OOA&D) som beskrevet i (Mathiassen et al., 2001). Til arbejdstitel for projektet har vi valgt BoBo Projects. 4.1 Formål Til projektstyring findes en række forskellige produkter (Wikipedia, 2008), men vi vil bestræbe os på at udvikle et system til at lette det administrative arbejde, i forbindelse med projektarbejde, for grupper indenfor Aalborg Universitets Institut for Datalogi - Computer Science (CS). Systemet skal således give den studerende mere tid til studiets andre aktiviteter, fremfor at bruge tid på rod i projektplanlægningen. Det mindre administrative arbejde skal således give de relevante grupper mere tid til at lægge deres fokus på semesteropgaven. Der refereres til disse grupper som CS-grupper i resten af dokumentet. 4.2 Systemdefinition Et administrativt lukket projektplanlægningssystem til at hjælpe grupper på CS med håndtering af opgaver, litteratur, dokumenter m.m. i forbindelse med et semesterprojekt. Systemet bliver udviklet i forbindelse med et semesterprojekt på CS, og er derfor underlagt en stram tidsplan, og af denne grund fokuseres der mest på funktionalitet frem for brugervenlighed. Det forventes derfor at brugere af systemet er øvede IT brugere, hvilket fint stemmer overens med målgruppen; grupper på CS. Systemets database bliver i XML, da en tekstbaseret database kan håndteres v.h.a. CS-institutets versionsstyring 1. Der vil blive lagt vægt på at information er nemt tilgængeligt og at systemets administrative funktionaliteter gør det attraktivt at bruge. Da der er mulighed for, at internationale studerende kunne drage nytte af systemet, vil systemets brugergrænseflade blive på engelsk. Systemdefinitionen er samlet i BATOFF-kriterier på figur 4.1 på den følgende side. 1 Versionsstyring er en praktisk måde at håndtere tekstbaserede filer på, ved at gemme dem på en central server, som alle brugere kan tilgå. Versionsstyring sørger for at flette filerne sammen, hvis der er ændringer, i det brugeren har, i forhold til det, der ligger på serveren. Dermed kan flere brugere arbejde på forskellige steder i den samme fil uden det giver problemer. 19

30 4.3 Omgivelser Betingelser Anvendelsesområde Teknologi Objekter Funktionalitet Filosofi Stram udviklingstidsplan, øvede IT brugere Projektgrupper på Institut for Datalogi Standalone med XML-database - mulighed for versionsstyring Opgave, dokument, litteratur, person, aftale Støtter projektplanlægning Projektadministrationsværktøj der følger projektet fra start til slut Figur 4.1: BATOFF-kriterier 4.3 Omgivelser Figur 4.2 viser et antal gruppemedlemmer der har problemer med kordinering og planlægning af et semesterprojekt og hvor et centralt program kan anvendes til denne planlægning. Billedet kunne også være en illustration af at et gruppemedlem, som gerne vil vide, hvem der er i gang med en bestemt opgave, hvor programmet så kan hjælpe gruppemedlemmet med information om dette, samt om der er nogle opgaver, der ikke er taget endnu. Systemet løser således disse problemer ved at samle det administrative arbejde centralt, hvilket dermed hjælper en projektgruppe med koordinering, planlægning og kommunikation i forbindelse med deres semesterprojekt. Koordinering/ planlægning Centralisering Central Bobo Koordinering, planlægning og kommunikation Figur 4.2: Rigt billede Opgaven

31 4.4 Problemområde 4.4 Problemområde Systemets hovedopgave vil blive at holde styr på relationerne mellem opgaver og ressourcer. Det skal både være muligt for en opgave at bruge flere ressourcer, og for en ressource at være tildelt til flere opgaver. Udover det, er opgaven det vigtigste element, i systemet, da et projekt i bund og grund er en opgave, der kan inddeles i underopgaver. En dybere analyse af problemområdet gennemgås i kapitel 5 på side Anvendelsesområde BoBo Projects skal hovedsagligt kunne give brugeren oversigt over opgaver og aftaler i projektforløbet, på en simpel og overskuelig måde, med mulighed for at oprette, ændre og slette opgaver, samt at prioritere dem og tilknytte brugere og andre ressourcer. Derudover skal brugeren kunne administrere litteratur tilknyttet projektet og evt. tilknyttet specifikke opgaver. Det skal være muligt at få overblik over eksterne kontakter, og andre gruppemedlemmer, samt at have adgang til centrale dokumenter, som f.eks. samarbejdsaftaler eller logbog. Brugeren skal desuden kunne kommentere alt relevant i programmet, lige fra opgaver til andre brugere. I kapitel 6 på side 31 undersøges anvendelsesområdet i dybere grad. 4. Opgaven 21

32 4.5 Anvendelsesområde Opgaven

33 5 Problemområde 5.1 Klynger Vi beskriver her to klynger i systemet, som vist på figur 5.1. Person-klyngen står for al information omkring personer i systemet. I Ressource-klyngen er alle de klasser, som nedarver fra Ressource, herunder er også Person-klyngen. Figur 5.1: Klyngestruktur 5.2 Struktur Dette afsnit indeholder uddybende beskrivelser til klassediagrammet, der findes på figur 5.2 på den følgende side Person og Bruger Der er to slags personer i systemet, Person og Bruger. En person af Person-typen indeholder kontaktinformation, samt muligheden for at få tilføjet kommentarer. Meget af dette nedarves fra Projektelement og Ressource som beskrives i afsnit på næste side. En person af Bruger-typen indeholder det samme som en af Person-typen, samt information om logon til systemet. Brugere af systemet har muligvis ikke brug for at kommentere hinanden, men det er et spørgsmål om at implementere det eller ikke implementere det i brugergrænsefladen. 23

34 5.2 Struktur Figur 5.2: Klassediagram Opgave aggregerer sig selv I og med at Opgave aggregerer sig selv, bliver det muligt at skabe underopgaver til opgaverne. Systemet kunne f.eks. indeholde en opgave der hedder Superprojekt. Superprojekt kan så have underopgaver, som Planlæg struktur, Implementer klasser og Implementer GUI. Man kunne argumentere for at dette kunne laves i et samlingsmønster, med forskellige opgavetyper. F.eks. kunne der være mulighed for at lave en simpel opgave, og en opgave der kan indeholde andre opgaver. Dette er dog blevet omgået ved at sige at en opgave blot skal kunne have 0 eller flere andre underopgaver. Dette gør at man ikke behøver at tage hensyn til om man skal have underopgaver, eller ej, når man opretter en opgave Projektelement og Ressource Både Projektelement og Ressource er abstrakte klasser. De eksisterer alene for at andre klasser kan nedarve deres egenskaber Projektelement Et Projektelement-objekt indeholder en beskrivelse, samt muligheden for at pege på et antal kommentarer til objektet. Disse egenskaber nedarver klasserne Opgave, Agreement og Ressource Problemområde

35 5.3 Klasser Ressource Samler Person, Litteratur og Dokument under et, og står for de fælles operationer der er på disse klasser. 5.3 Klasser Da der kan være nogle af klasserne, der har samme hændelser i programmet, beskrives de enkelte klasser med ord, for at få et bedre overblik. Disse beskrivelser findes i tabel 5.1. Klasse Projektelement* Kommentar Opgave Ressource* Aftale Person Bruger Litteratur Dokument Indhold Navn, en beskrivelse, og en liste af kommentarer. Kommentarerne der peges på af Projektelements liste. Opgaver i projektet. De ting der er fælles for alle ressourcer, der kan komme i brug ifb. med en opgave. Planlagte begivenheder, som f.eks. deadlines eller møder. Personer, som har noget at gøre med projekt. Brugere i systemet. De kilder der er relevante for projektet. Forskellige dokumenter, som eksempelvis logbog, note, samarbejde osv. Tabel 5.1: Beskrivelse af de enkelte klasser. * = abstrakte klasser. 5.4 Hændelser Ved at lave tilstandsdiagrammer for klasserne fra afsnit 5.3 blev hændelserne, som illustreret i tabel 5.2 på side 29 identificeret. De relevante tilstandsdiagrammer gennemgåes i de følgende afsnit Opgave Tilstandsdiagrammet for klassen Opgave på figur 5.3 illlustrerer forløbet for en opgave. En opgave påtænkes som udgangspunkt, og er derfor ikke indskrevet i systemet. Den eksisterer blot som en ide eller tanke. Hvis den indskrives i systemet er det et krav at opgaven har et navn, hvilket er illustreret med skildvagten [navn]. Sker dette befinder opgaven sig i en vedtaget tilstand, hvor en lang række af muligheder for administrering af opgaven bliver tilgængelig. Opgaven kan til hver en tid, fjernes. 5. Problemområde 25

36 5.4 Hændelser Ide fåes Opgave vedtages [navn] Påtænkt Opgave opgives Kommentar noteres Vedtaget Tidsperiode fastsættes Planlagt Opgave tages af planen Dokument tildeles Person tildeles Opgave prioriteres Underordnet opgave påtænkes Opgave Overordnet opgave fjernes Opgave fjernes Opgave igangsættes Opgave stoppes Igangsat Opgave færdiggøres færdig Litteratur tildeles Tidsperiode ændres Figur 5.3: Tilstandsdiagram for opgave Projektelement Eksistens ophøres Kommenterbart objekt tilbliver Eksisterer Beskrives Beskrevet Eksistens ophøres Kommentar noteres Kommentar noteres Figur 5.4: Tilstandsdiagram for projektelement Projektelement-klassens (se figur 5.4) formål er at sørge for at alle klasser, som er projektelementer, har mulighed for at få et navn, en beskrivelse og ikke mindst at være kommentérbare Aftale Tidsperiode ændres Aftale ønskes Aftale glemmes Ønsket Aftale glemmes Aftale vedtages Vedtaget Tidsperiode fastsættes [påmindelse] Tidsperiode fastsættes Påmindelse aktiveres Fastsat m. påmindelse Fastsat Påmindelse deaktiveres Aftale afholdes Aftale afholdes Kommentar noteres Afholdt Dokument tilføjes Slettes Tidsperiode ændres Litteratur tildeles Person tildeles Dokument tildeles Kommentar noteres Figur 5.5: Tilstandsdiagram for aftale Problemområde

37 5.4 Hændelser Aftale-klassen (se figur 5.5 på forrige side) har overordnet to tilstande den kan befinde sig i. Den kan enten være i ikke-planlagt tilstand, hvor aftalen er enten ønsket eller afholdt, eller også kan en aftale være i en vedtaget tilstand. I den vedtagede tilstand er det muligt at fastsætte eller fjerne en påmindelse, og relevante ressourcer kan tildeles. Det er også i denne tilstand muligt at fastsætte en tidsperiode. Når en aftale er afholdt, går den ud af den vedtagede tilstand, og befinder sig nu kun i en tilstand, hvor den kan kommenteres. En aftale kan til en hver tid slettes Person Kontaktoplysninger ændres Person har relation til projektet Eksisterer Person registreres [Navn] Registreret Omdøbes Kommentar noteres Person fjernes Figur 5.6: Tilstandsdiagram for person Klassen Person (se figur 5.6) er en ganske triviel klasse. Med det samme en person har tilknytning til et projekt, vil denne eksistere i sammenhæng med dette projekt, men personen er dog først registreret, når et navn er givet. Når en person er registreret, er det her muligt at ændre relevant kontaktinformation samt at kommentere på denne. Tilstandsdiagrammer for klasserne Litteratur, Bruger, Dokument er bevidst udeladt her, idet de til forveksling minder om tilstandsdiagrammet for Person (5.6). Ligeledes er også tilstandsdiagrammet for klassen Ressource udeladt her, da også denne må betragtes som triviel. Hændelser Opgave Projektelement Kommentar Klasser Aftale Ressource Person Litteratur Ide fåes + + Kommentar noteres * * + * * * Litteratur tildeles * * Dokument tildeles * * Opgave færdiggøres + Opgave igangsættes * Opgave opgives * Fortsættes på næste side. Bruger Dokument 5. Problemområde 27

38 5.4 Hændelser Opgave Projektelement Kommentar Aftale Ressource Person Litteratur Bruger Dokument Opgave prioriteres * Opgave stoppes * Opgave tages af planen * Opgave vedtages * Opgave fjernes + Overordnet opgave fjernes + Underordnet opgave påtænkes * Person tildeles * * Tidsperiode fastsættes * * Tidsperiode ændres * * Tilhørende objekt beskrives + Kommenterbart objekt tilbliver + Objekt ophører sin eksistens + Kommentar haves + Kommentar fjernes + Kommentar ændres * Aftale ønskes + Aftale vedtages * Aftale afholdes + Aftale glemmes * Påmindelse aktiveres * Påmindelse deaktiveres * Aftale slettes + Ressource oprettes + Ressource omdøbes * Ressource fjernes + Fortsættes på næste side Problemområde

39 5.4 Hændelser Opgave Projektelement Kommentar Aftale Ressource Person Litteratur Bruger Dokument Kontaktoplysn. ændres * * Person fjernes + Person får relation til projektet + Person omdøbes * Person registreres + Kildeinfo ændres * Litteratur fjernes + Litteratur omdøbes * Litteratur opdages + Litteratur registreres + Bruger ekskluderes + Bruger bliver medlem af gruppen + Bruger omdøbes * Bruger registreres + Brugeroplysn. ændres * Dokument skrives + Dokument ændres * Dokument slettes + Type ændres * Tabel 5.2: Hændelsestabel som beskriver hvilke hændelser der kan forkomme på hvilke klasser. Et + indikerer at en hændelse kan ske nul eller én gang, mens en * indikerer at hændelsen kan forekomme nul eller flere gange. Hændelsestabelen, på figur 5.2, viser hvilke hændelser der kan ske på hvilke klasser. F.eks. kan hændelsen Opgave færdiggøres kun forekomme nul eller én gang på klassen Opgave, mens hændelsen Tidsperiode fastsættes kan forekomme nul eller flere gange på såvel Opgave som Aftale klasserne. Det er dog med hændelsestabellen ikke muligt at få et overblik over rækkefølgen af hændel- 5. Problemområde 29

40 5.4 Hændelser serne. F.eks. kan det ikke ses, om det er muligt, at hændelsen Dokument slettes kan ske før hændelse Dokument skrives. Intuitivt giver dette hændelsesforløb naturligvis ikke mening Problemområde

41 6 Anvendelsesområde 6.1 Brug Oversigt Der blev identificeret to aktører; projektleder og projektmedlem, og 15 brugsmønstre. Aktørernes brugsmønstre er illustreret på figur 6.1. Aktør Brugsmønstre Projektleder Projektmedlem Opstart projekt Opgaveplanlægning Aftaleplanlægning Brugeradministration Overvåg tidsplan Hent opgave Hent aftale Hent litteraturinformation Hent personoplysning Hent dokument Litteraturadministration Personadministration Dokumentadministration Ændrer egne brugeroplysning Kommentering Figur 6.1: Aktørtabel som illustrerer aktørerne projektleder og projektmedlem og deres respektive brugsmønstre. Det er vigtigt for forståelsen af tabellen at bemærke, at en projektleder og et projektmedlem er to forskellige roller, og ikke nødvendigvis to forskellige personer der anvender systemet. Aktørerne kan således godt være én og samme person i anvendelsesområdet. Det betyder at der skelnes imellem, om en person i anvendelsesområdet laver administrativt arbejde, eller om denne arbejder på det relevante projekt. Det er projektlederens opgave at sørge for få startet projektet i systemet og planlægge opgaver, mens det er projektmedlemmets rolle at hente opgaver, dokumenter osv. Administration af litteratur og dokumenter ses dog ikke som opgaver der hører til projektlederens rolle, da 31

42 6.1 Brug denne aktørs rolle er projektadministrativ, og derfor tilhører disse brugsmønstre projektmedlemmet Aktører Aktørerne Projektleder og Projektmedlem er beskrevet i figur 6.2. Projektleder Formål: En person der planlægger, tildeler og følger op på opgaver. Beskæftiger sig også med at holde styr på aftaler. Karakteristik: Arbejdet udføres af et gruppemedlem i en gruppe på CS. Eksempler: Gruppen er blevet enige om en opgave, der skal udføres, i forbindelse med projektet. Denne opgave indføres nu af projektlederen, og der sættes tid og ressourcer på. Projektmedlem Formål: Et gruppemedlem der udfører de opgaver, vedkomne er blevet tildelt, samt opdaterer relevante dokumenter, litteratur og kontakter. Karakteristik: Arbejdet udføres af et gruppemedlem i en gruppe på CS. Eksempler: En opgave er dukket op i et gruppemedlems todoliste, og vedkomne går i gang med opgaven. Han kommenterer opgaven i forbindelse med dette, og tilføjer kontakter, litteratur og dokumenter. Figur 6.2: Aktørspecifikationer for Projektleder og Projektmedlem. Persona Som et eksempel på aktøren projekmedlem gives følgende persona. Se evt. også fig 6.3 på modstående side: Søren er opvokset i et villakvarter i Vejle, og har gået i folkeskolen og på gymnasiet i samme by. Søren er intereseret i computere, men han har ikke matematik A fra gymnasiet, så derfor er han startet på informatik, i stedet for f.eks. datalogi eller softwareingeniør. Han synes selv at han er lidt af et rodehoved, og til tider lidt distræt, så han har ikke altid lige meget styr på, hvad der skal gøres i forbindelse med projektarbejde. Han har derfor en forhåbning om, at projektplanlægningssystemet kan hjælpe ham med at få bedre kontrol over semestret. Det er hans forhåbning at systemet kan bruges til at tildele sig selv og andre Anvendelsesområde

43 6.1 Brug Navn Alder Beskæftigelse Personlighed Mål Søren Frederiksen 22 år Læser informatik på 1. semmester Arbejder som telefonsælger hos Nordjyske Distræt, rodehoved At få struktur på projektet Figur 6.3: Persona for Søren Frederiksen forskellige opgaver, hvilket samtidigt også gerne må give ham overblik over, hvad de andre i gruppen foretager sig. Han håber desuden at systemet kan hjælpe med at holde styr på hvornår deadlines nærmer sig, da disse ofter sniger sig op på ham. Søren har ingen erfaring med andre planlægningssystemer, men er ved godt mod, hvad angår at lære et Scenarier Her beskrives to tænkte scenarier i forbindelse med brug af BoBo Projects. I forbindelse med opstart af nyt projekt har Peter et ønske om at få organiseret projektforløbet. Samarbejdsaftalen for gruppen nedskrives og gemmes som et dokument i systemet. Vigtige opgaver og tidsperioderne for disse indskrives, og opgaverne inddeles i mindre opgaver, således at det bliver mere overskueligt hvad der skal laves og hvornår. Efterhånden som gruppen får overblik over de opgaver der skal laves, noteres disse i systemet. I systemets todo-liste bliver opgaverne listet, så det er nemt at overskue hvad der mangler at blive lavet og under hver opgave er det muligt at se hvem der er på en specifik opgave. Peter finder noget litteratur, i form af en hjemmeside, som virker meget relevant for gruppens projekt, og tilføjer dette til systemets litteraturliste. Hans har i forbindelse med sit projekt på DAT1 besluttet at anvende projektstyringsprogrammet BoBo Projects. Han har lovet at skrive samarbejdsaftalen ind, og åbner derfor programmet. Han præsenteres for forsiden hvor tidsplan giver et grafisk overblik over opgaverne, som dog ikke indeholder meget endnu, og navigerer til fanebladet Dokumenter, hvor han tilføjer et nyt dokument, og skriver aftalen ind. Hans trykker Gem, og går nu videre til litteraturlisten, hvor han har set at Jørgen har tilføjet en URL, men han har lavet en stavefejl, som Hans vil rette. Han vælger litteraturpunktet, og trykker rediger, retter fejlen og gemmer Brugsmønstre Da muligheden for at administrere opgaver, dokumenter m.m. skal være lige tilgængeligt, hvorend man befinder sig i systemet vælges en fanebladsstruktur. I afsnit 6.3 på side 37 om 6. Anvendelsesområde 33

44 6.1 Brug brugergrænsefladen gennemgåes designet af systemet, men nævnes her for at overskueliggøre brugen af systemet. Til fordel for en systemstruktur baseret på menuer, vil fanebladene gøre det nemt for en bruger at skifte imellem de forskellige vinduer. Det vil også gøre det nemt, uanset hvor denne befinder sig at lukke programmet. Dog skal der være den undtagelse, at hvis brugeren uheldigvis kommer til at lukke programmet, mens denne var i gang med at redigere elementer i systemet, skal systemet bede brugeren om at bekræfte handlingen. Hvis ikke brugeren foretager sig noget vigtigt, lukker programmet blot. Således sikrer systemet også, at data ikke går tabt. Når programmet åbnes, præsenteres brugeren, efter login, for en forside, hvori i tidsplanen vises. Fra dette vindue af, er det muligt at navigere videre til en fanerne; opgaver, dokumenter, personer, litteraturliste og todoliste. Det er således muligt for brugeren at skifte fra systemets nuværende vindue og om til en af de andre vindue, uanset hvor brugeren befinder sig i systemet. Ønskes et mere detaljeret udkast til systemet henvises læseren til figur 6.5 på side 37. Opgaveplanlægning Naviger til oversigt over opgaver Klik Tilføj opgave Klik på en opgave Vis oversigt over opgaver Klik Annuller Vis opgave-dialog Klik Rediger opgave Opgave valgt Klik Gem [Navn] Rediger felt(er) Klik Tilføj opgave Naviger væk Figur 6.4: Diagram for brugsmønsteret Opgaveplanlægning. Diagrammet på figur 6.4 giver en illustration af brugsmønsteret for Opgaveplanlægning. Planlægning af opgaver starter ved at navigere til opgaveoversigten. Ønsker man at tilføje en opgave klikkes der på Tilføj opgave, og systemet vil vise en Opgave-dialog, hvilket giver mulighed for at redigere oplysningerne for den nye opgave. Afsluttes der med Gem eller Annuller foretager systemet den relevante handling hvorpå man returneres til oversigten over opgaver. Her er der også mulighed for at vælge en allerede eksisterende opgaver, som man kan vælge at redigere ved at trykke Rediger opgave. Systemet viser igen Opgavedialogboksen, med oplysninger om den valgte opgave, og fremgangsmåden er den samme som før. Det er muligt at navigere væk, hvilket vil afslutte brugsmønsteret for opgaveplanlægning. Det fremgår dog ikke af diagrammet, men systemet vil her advare brugeren, hvis denne har glemt at gemme sine ændringer Anvendelsesområde

45 6.2 Funktioner 6.2 Funktioner Brugeren vil, straks efter at have åbnet programmet blive præsenteret for en hovedside for systemet. Her præsenteres en grafisk tidsplan, som giver overblik over brugerens opgaver såvel som gruppens. Det vil også her være muligt at administrere opgaverne. Fra hovedsiden vil der være nem tilgang til systemets andre hovedområder; Todo-liste, Dokumenter, Litteratur og Personer. Ligeledes vil det fra hvert hovedområde være muligt nemt at tilgå andre hovedområder. Under Todo-listen vil brugeren få præsenteret en liste over opgaver, som er sorteret efter prioritet og deadline. Her har brugeren også mulighed for at sorterer efter andet, samt at administrere opgaverne. Under Dokumenter vil en oversigt blive vist. Igen er det muligt at få sorteret dokumenterne efter navn, type, dato m.m.. Her vil det være muligt for brugeren at administrere dokumenterne ved at tilføje, redigere og slette de enkelte dokumenter. Litteratur-listen giver brugeren et overblik over al litteratur tilføjet. Brugeren har her mulighed for at få sorteret listen efter navn, type, dato osv. Personer er området hvor brugeren kan administrere sine oplysninger, andre brugere og kontakter tilknyttet projektet. Listen kan ligeledes sorteres efter navn og type Komplet funktionsliste Hændelser Kompleksitet Type Noter kommentar Simpel Opdater Tildel litteratur Simpel Opdater Tildel dokument Simpel Opdater Marker opgave som færdig Simpel Opdater Marker opgave som igangsæt Simpel Opdater Prioriter opgave Simpel Opdater Stop opgave Simpel Opdater Tag opgave af planen Simpel Opdater Vedtag opgave Simpel Opdater Fjern opgave Middel Opdater Tildel Person Simpel Opdater Fastsæt tidsperiode Simpel Opdater Ændre tridsperiode Simpel Opdater Beskriv tilhørende objekt Simpel Opdater Kommentar fjernes Simpel Opdater Fortsættes på næste side. 6. Anvendelsesområde 35

46 6.2 Funktioner Hændelser Kompleksitet Type Vedtag aftale Simpel Opdater Afhold aftale Simpel Opdater Glem aftale Simpel Opdater Akriver påmindelse Simpel Opdater Deaktiver påmindelse Simpel Opdater Slet aftale Simpel Opdater Opret ressource Simpel Opdater Omdøb ressource Simpel Opdater Fjern ressource Simpel Opdater Ændre kontaktoplys Simpel Opdater Fjern person Simpel Opdater Omdøb person Simpel Opdater Registrer person Simpel Opdater Ændre kildeinfo Simpel Opdater Fjern litteratur Simpel Opdater Omdøb litteratur Simpel Opdater Registrer litteratur Simpel Opdater Ekskluder bruger Simpel Opdater Omdøb bruger Simpel Opdater Registrer bruger Simpel Opdater Ændre brugeroplys Simpel Opdater Skriv dokument Simpel Opdater Ændre dokument Simpel Opdater Slet dokument Simpel Opdater Ændre type Simpel Opdater Tabel 6.1: Tabel over funktioner tilknyttet de forskellige klasser i programmet, med angivelse af type samt kompleksitet Anvendelsesområde

47 6.3 Brugergrænsefladen Specifikation af funktioner Fjern opgave er en rekursiv funktion som skal fjerne en opgave og samtlige underopgaver. Når en overordnet opgave bliver fjernet, kalder denne således Fjern opgave på sine underopgaver osv. 6.3 Brugergrænsefladen Figur 6.5: Et håndtegnet udkast til hvordan brugergrænsefladen til BoBo Projects kunne se ud. Målgruppen for systemet er studerende på CS, og da disse studerende kan være af anden etnisk herkomst, er det nødvendigt, at programmet, også for dem, er forståeligt. Derfor laves brugergrænsefladen i første omgang på engelsk, da engelsk må betragtes som det mest internationale sprog. Brugergrænsefladen, som skitseret i figur 6.5, vil blive bygget op i et enkelt vindue, hvor man navigerer rundt via faneblade. Hvert faneblad skal repræsentere et hovedområde i programmet. Med dette design undgås det, at der bliver mange vinduer, der åbner og lukker i programmet Mål for brug Skemaet på figur 6.6 på næste side illustrerer en prioritering af elementer i såvel usability som user experience. Skemaet afspejler, hvilke ting vi mener er vigtige for, at programmet bliver en brugsmæssig success. Generelt kan man sige, at det er vigtigt, at brugeren får 6. Anvendelsesområde 37

48 6.3 Brugergrænsefladen en oplevelse af, at programmet er effektivt. Derfor er det også irellevant, at systemet er underholdende og sjovt. Det er næsten et krav, at det er ingen af delene, da det kunne fjerne fokus fra formålet med systemet. Usability Experience Effectiveness Efficiency Safety Utility Learnability Memorability Satisfying Enjoyable Fun Entertaining Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Emotionally fulfilling Meget vigtig Vigtig Mindre vigtig Irrelevant Figur 6.6: Skema for prioritering af usability og user experience i forbindelse med brug af BoBo Projects Begrebsmæssig model Som udgangspunkt udforsker brugeren systemet, for derefter at finde relevant information, eller finde mulighed for at redigere eller tilføje information. Kommer brugeren til at lukke programmet på et uhensigtsmæssigt tidspunkt vil en kort konversation mellem systemet og brugeren afklare denne sag. Systemet kan instrueres til at fremvise informationen efter brugerens ønsker Interaktionsform Overordnet er systemet opdelt i faneblade. Navigation mellem hovedområderne foregår således ved brugeren udvælger hvilket område denne ønsker at arbejde på. Derefter kan brugeren vælge specialiseringer inden for hvert område, hvor programmet benytter skemaudfyldelelse til input af data understøttet af dialoger Anvendelsesområde

49 6.3 Brugergrænsefladen Generel interaktionsmodel Efter analyse af en række interaktionsrum blev følgende interaktioner mellem systemet og brugeren identificeret: Login Tjek login Vælg hovedområde Tilføj diverse ting Gem Opdater liste Rediger diverse ting Gem Opdater liste Kommenter diverse Gem Opdater liste Slet diverse ting Bekræft sletning Gem Opdater liste Vis diverse ting Sorter diverse ting Luk Bekræft lukning (Vil du gemme?) Gem 6. Anvendelsesområde 39

50 6.3 Brugergrænsefladen Anvendelsesområde

51 7 Videre udvikling 7.1 Den tekniske platform Systemet udvikles som stand-alone PC-applikation med grafisk brugerflade på Windows og programmeres i C# med Windows Forms som grænseflade-framework. De mest almindelige input værktøjer, som mus og tastatur, anvendes ved brug af programmet. Data gemmes i XML format, da XML er i clear-text, og derfor nemt kan versionstyres og deles via Subversion eller lignende. 7.2 Anbefalinger Systemets nytte og realiserbarhed Generelle koncepter i brugergrænsefladen har været diskuteret, og sat op mod klassediagrammerne. Systemet anses for at have et forholdsvis højt ambitionsniveau, både tidsmæssigt og teknisk, da vi er i en læreproces, og ingen af os har stor erfaring med udvikling af større systemer. Hovedsageligt regner vi med at lave en solid grundprogrammering, så systemet nemt kan udvides senere. Vi forudser ikke at støde ind i større udfordringer, end man ellers kunne forvente af en læreprocess. 7.3 Strategi Den primære fokus i udviklingen vil være opgaverne, først i form af Todo-listen, og senere i form af en grafisk tidslinie med repræsentation af de enkelte opgavers tidsrammer, sekundært vil programmet blive udbygget, med tilknytning af brugere til opgaver, tilknytning af kommentarer, og tilknytning af andre ressourcer. 7.4 Udviklingsøkonomi Udviklingsarbejde vil begynde d. 22. oktober, og vil slutte den 1. december, hvor programmet vil være færdigt. Vi vil ikke gøre mere ved det, da projektperiodens fokus må lægges over på rapportskrivning og test af programmet. Da BoBo Projects er et studieprojekt, kommer udviklingsarbejde ikke til at koste noget økonomisk, men som minimum vil der nok blive brugt 7-8 timer, om dagen på programmet, fra hvert gruppemedlem. Det er ca. 37 timer om ugen. Så hvis der bliver brugt ca. 5 uger på programmet. hvoraf de to sidste uger vil blive brugt udelukkende til programmering. Vi forventer dog at bruge en del flere timer, alt efter hvad studiet giver plads til. 41

52 7.4 Udviklingsøkonomi Videre udvikling

53 Del II Designdokument 43

54

55 8 Opgaven 8.1 Formål Det designede system skal lette det administrative i projektarbejdet, så tiden ikke spildes med rod i projektplanlægningen. Blandt andet for at give den enkelte studerende mere tid til studiets andre aktiviteter. Programmet skal hjælpe grupperne til at holde styr på forskellige projektelementer som opgaver, kontaktpersoner og litteratur. 8.2 Rettelser til analysen Der er foretaget en del rettelser i analysedokumentet. Til at starte med er alle klassenavnene blevet omskrevet fra engelsk til dansk. Dels for at disse ikke ligner kildekode for meget, men også for at de bedre kan relateres til problem- og anvendelsesområdet, hvilket også gør dokumentet nemmere at læse. En klasse som før hed Comment_holder hedder nu Projektelement, da navnet Kommentarholder ikke er dækkende for, hvad klassen gør. Klassediagrammet har også fået slettet klassen Påmindelse, da vi er kommet frem til, at én påmindelse er nok for hver aftale, og påmindelsen derfor er sat på Aftale som attribut i stedet for en aggregeret klasse. Til review af analysedokument d. 9. oktober 2008 måtte vi indse, at vi havde misforstået hvad en aktørtabel er. Det var derfor nødvendigt at revurdere aktørerne og de tilhørende brugsmønstre. Det resulterede i, at er der nu to reelle aktører: Projektleder og Projektmedlem. Ligesom aktørerne måtte vi også efter review revurdere vores hændelser, som nu i højere grad afspejler problemområdet. Vi har også uddybet funktionslisten, som nu er mere udførlig og detaljeret. 8.3 Kvalitetsmål For design af arkitekturen, har vi opsat følgende prioriteringstabel (se tabel 8.1 på den følgende side). Det er her vigtigt at understrege, at denne tabel ikke skal forveksles med tabellen for prioritering af usability fra analysen, da disse to tabeller afspejler to vidt forskellige områder. Tabel 8.1 giver et overblik over prioriteringer af det tekniske design, og afspejler også driftsmæssige krav. Der er for designfasen lagt vægt på, at systemet skal være brugbart og korrekt, fremfor at systemet eksempelvis er sikkert eller fleksibelt. Argumentet ligger i en af dette projekts delopgaver, hvilket består i at programmere en velfungerende softwareløsning, som realiserer det overordnede design (Studienævn for Naturvidenskab, 2008). Det er derfor ikke afgørende, at systemet eksempelvis er fleksibelt og sikkert, men det er i stedet vigtigere at fokusere på, at systemudviklingen kan realiseres, i form af et program. 45

56 8.3 Kvalitetsmål Kriterium Brugbart Meget Vigtig Vigtigt Mindre vigtigt Irrelevant Trivielt opfyldt Sikkert Effektivt Korrekt Pålidelig Vedligeholdbart Testbart Fleksibelt Forståeligt Genbrugbart Flytbart Integrerbart Yderligere kriterier: - Persistens Figur 8.1: Prioriteringstabel for designkriterier Opgaven

57 9 Teknisk platform 9.1 Udstyr BoBo Projects skal køre på en x86-baseret PC med tastatur og mus som input. Maskinen skal have Windows XP eller Windows Vista, med Microsoft.NET 3.5, og det anbefales, at Tortoise SVN er installeret, hvis man ønsker at benytte systemets SVN feature. 9.2 Basisprogrammel Vi planlægger at lave systemet i Microsoft Visual C# 2008 Express Edition. Til brugergrænsefladen bruger vi Windows Forms, og til at gemme data fra gang til gang bruges.net framework Serializable feature, hvilket giver mulighed for at gemme systemets nuværende tilstand i en XML fil. 9.3 Systemgrænseflade Der er ingen andre programmer der skal forespørge BoBo Projects direkte. Der anvendes dog SVN til at gemme og hente data fra en server over internettet. 9.4 Designsprog Vi har anvendt UML som designsprog, og overvejende fulgt (Mathiassen et al., 2001). 47

58 9.4 Designsprog Teknisk platform

59 10.1 Designkriterier og arkitektoniske krav 10 Arkitektur Et af kravene til systemet er, at det skal hjælpe CS-studerende med planlægningen af deres projektarbejde. Dette kan til dels opnås ved, at systemet anvender de systemer, studerende på CS allerede benytter. I forbindelse med udformningen af en semesterrapport benytter størstedelen af grupperne på CS servere til versionskontrol. Et krav for at filer kan versionsstyres er, at de kun bestå af klartekst (plain-text). Det vil formodentligt være en større hjælp for de studerende, hvis systemet kunne drage nytte af disse servere, ved eksempelvis at lagre sine data i tekst filer, som dermed kan versionstyres. Til at lagre data kan anvendes Extensible Markup Language (XML), som er er et meget flexibelt format, der blandt andet kan bruges til at organisere data i klartekst. XML er en simpel måde at lagre data på, og idet at XML er klartekst understøttes versionsstyring umiddelbart. Selve implementeringen i.net Framework er ganske ligetil ved brug af Serializable Generiske design beslutninger Da Microsoft.NET Framework anvendes som udviklingsmiljø falder valget på Windows Forms til udvikling af brugergrænsefladen kun naturligt. Systemet designes med overordnede faneblade. Herunder benyttes User Controls til at modellere brugergrænsefladens mindre komponenter. For at sikre at systemets objekter bibeholder deres data, når det lukkes, benyttes C#s Serializable feature,. Ved at benytte serialisering er det muligt at gemme data fra programmet uden at afsætte yderligere tid til implementering af klasser, som skal håndtere organisering og lagring af disse data. Serializable stiller dog det krav at alle klasser som skal være persistente, får defineret at de skal være Serializable. Desuden skal systemet, udover at gemme når det lukker, også periodisk sørge for at gemme dataen, så denne ikke går tabt i tilfælde af et systemnedbrud. I C# implementeres metoder i XML-klassen som, ved hjælp af IO klassen FileStream, skal sørge for gemme objekter i en XML-fil. I afsnittet om programmering (se afsnit 12.3 på side 64) gives et eksempel på, hvordan serialisering kan implementeres. Der vedtages derudover følgende generelle krav til kildekoden: Én klasse per fil En klasses navn er det samme som dens filnavn. Komponenter tildeles hver sin undermappe. Klasser har stort forbogstav. Efterfølgende ord med stort forbogstav. Metoder har stort forbogstav. Efterfølgende ord med stort forbogstav. Variabler har lille forbogstav. Efterfølgende ord med stort forbogstav. Al kode inkl. klasser, metoder, variabler, kommentarer osv skrives på engelsk. 49

60 10.3 Komponent arkitektur Systemets brugergrænseflade skrives på engelsk Komponent arkitektur Brugergrænseflade Funktioner Model Teknisk platform Figur 10.1: Komponent diagram Systemets komponentdiagram, illusteret på figur 10.1, giver et overblik over grundarkitekturen for BoBo Projects. Den lagdelte arkitektur fra (Mathiassen et al., 2001) anvendes og består af en brugergrænsefladekomponent, en funktionskomponent, en modelkomponent og en komponent for den tekniske platform. Sidstnævnte har ansvaret for administration og opdatering af XML databasen, og giver Model- og Funktionskomponenten en grænseflade til databasen. Modelkomponenten indkapsler data, og giver brugergrænsefladekomponenten og funktionskomponenten mulighed for at tilgå disse. Funktionskomponentens ansvar er, at give brugergrænsefladekomponenten funktionaliteter, som ikke hører til i én klasse i modelkomponenten - f.eks. sortering af lister m.m. Brugergrænsefladekomponentens ansvar bliver at præsentere data grafisk Eksemplariske design Sekvensdiagrammet på figur 10.2 på næste side illustrerer interaktionen mellem objekterne i brugsmønsteret for Opgaveplanlægning fra analysen (se figur 6.4 på side 34). Projektlederen initiere brugsmønsteret, når denne beder om at få vist opgaveoversigten, hvor sekvensdiagrammet viser de kald, som systemet foretager på baggrund af projektlederens valg i brugergrænsefladen. Som det også er gældende i brugsmønsteret, er der et krav til, at en opgave som minimum skal have et navn. Dette er illustreret ved Navn!= Ø, som er sat efter GemOpgave(). Diagrammet giver også en illustration af de funktioner, som ikke er synlige for brugergrænsefladen. Når brugeren eksempelvis opretter en opgave, er det ikke synligt for denne, at opgaven bliver tilføjet til en liste i klassen Projekt, hvis opgaven er en hovedopgave, og ikke er en underopgave til en anden opgave. Var dette istedet tilfældet, vil den nye opgave blive tilføjet til en liste af underopgaver i Opgave-klassen Arkitektur

61 10.4 Eksemplariske design Brugergrænseflade Model:Projekt Model:Opgave Teknisk Platform Projektleder 1: HentOpgaveOversigt() 2: HentOpgaveListe() 3: TilføjOpgave() 4: OpretOpgave(), Navn!=Ø 5: GemOpgave(), Navn!=Ø 6: GemDatabase 7: HentOpgaveListe() 8: TilføjOpgave(ValgtOpgave) 9: GemOpgaveData, Navn!=Ø 10: OpretUnderOpgave(), Navn!=Ø 12: HentOpgaveOversigt() 11: GemDatabase 13: RedigerOpgave(ValgtOpgave) 15: GemOpgave(), Navn!=Ø 18: SletOpgave(ValgtOpgave) 19: SletOpgave(ValgtOpgave) 14: HentOpgaveData(ValgtOpgave) 16: GemOpgave(), Navn!=Ø 17: GemDatabase loop [Underopgaveliste!= Ø] 20: SletOpgave(Underopgave) 21: GemDatabase Figur 10.2: Sekvensdiagram for brugsmønsteret Opgaveplanlægning 10. Arkitektur 51

62 10.4 Eksemplariske design Arkitektur

63 11 Komponenter 11.1 Modelkomponent Modelkomponenten er illustreret på figur 11.1 på næste side Struktur Projekt-klassen fungerer som en overklasse for klassediagrammets andre klasser, det er denne der sørger for at oprette instanser af de underliggende klasser, og fjerne dem igen. En af fordelen ved dette er, at når objekterne skal gemmes i XML kan vi nøjes med at serialisere Projekt-objektet, da dette så vil tage de underliggende objekter med. Projektelementet indeholder primært evnen til at kunne kommentere på de klasser, der nedarver fra den. Dette er vist ved aggregeringen til Kommentar klassen, der så igen aggregerer til den bruger, der har skrevet kommentaren for at holde styr på, hvem der har skrevet hvad. Relationen mellem Opgave og aftale abstraktion og Ressource videreføres til hhv. Aftale og Opgave, og Dokument, Person, Bruger og Litteratur, for at holde styr på hvilke ressourcer, der er knyttet til hvilke aftaler og opgaver, og hvilke opgaver og aftaler de enkelte ressourcer er knyttet til Klasser Projekt Ansvar og formål Attributter Slet Opgave Overordnet projekt klasse, som alle opgaver, aftaler mm. er tilknyttet. Det er denne klasse der sørger for at oprette instanser af de andre klasser. Denne funktion står for at slette en given opgave, men før denne slettes, skal funktionen kalde sig selv rekursivt på samtlige underopgaver tilknyttet opgaven. 53

64 11.1 Modelkomponent Modelkomponent 1 Projekt +OpretAftale() +OpretBruger() +OpretDokument() +OpretLitteratur() +OpretOpgave() +OpretPerson() +SletAftale() +SletBruger() +SletDokument() +SletLitteratur() +SletOpgave() +SletPerson() +HentAftaleListe() +HentBrugerListe() +HentDokumentListe() +HentLitteraturListe() +HentOpgaveListe() +HentPersonListe() 1 * Projektelement #navn #beskrivelse #beskrivelsedato +Prop Beskrivelse() +Prop Navn() +SletKommentar() +OpretKommentar() +Prop BeskrivelsesDato() Kommentar -tekst -oprettelsesdato * +Prop Tekst() +Prop OprettelsesDato() * 1 "Opgave og aftale abstraktion"* #startdato #slutdato +Prop SlutDato() +Prop StartDato() +FjernBruger() +FjernDokument() +FjernLitteratur() +FjernPerson() +TilføjBruger() +TilføjDokument() +TilføjLitteratur() +TilføjPerson() * Ressource #oprettelsesdato * Af mangel på bedre navn. * * Opgave -igangsatdato -færdigdato -prioritet +GemOpgaveData() +OpretUnderopgave() +Prop FærdigDato() +Prop IgangsatDato() +Prop Prioritet() +SletAftale() +TilføjAftale() Aftale -afholdtdato -påmindelsesdato * +Prop AfholdtDato() +Prop PåmindelsesDato() 1 -Prop OprettelsesDato() 1 Bruger -brugernavn -password +Prop brugernavn() +Prop password() Prop; betyder at dette er en Hent / Sæt funktion. En property i C#. En Hent / Sæt funktion, opererer på attributen af samme navn. Person -adresse -andenkontaktinformation -andetwebsite -by -fastnetnr -land -mobilnr -MSNId -postnr -primær -sekundær -skypeid -website +Prop Adresse() +Prop AndenKontaktinformation() +Prop AndetWebsite() +Prop By() +Prop Fastnetnr() +Prop Land() +Prop Mobilnr() +Prop msnid() +Prop postnr() +Prop Primær () +Prop Sekundær () +Prop SkypeId() +Prop Website() Litteratur -bind -forfatter -hvordanudgivet -journal -litteraturinfo -nummer -sider -skole -titel -type -udgave -udgivelsesdata -udgiver -url +Prop BeskrivelseDato() +Prop Bind() +Prop Forfatter() +Prop HvordanUdgivet() +Prop Journal() +Prop Litteraturinfo() +Prop Navn() +Prop Nummer() +Prop OprettelsesDato() +Prop Sider() +Prop Skole() +Prop Titel() +Prop Type() +Prop Udgave() +Prop UdgivelsesData() +Prop Udgiver() +Prop Url() Dokument -type -tekst -sidstredigeretdato +Prop SidstRedigeretDato() +Prop Tekst() +Prop Type() Figur 11.1: Klassediagram for modelkomponenten Projektelement Ansvar og formål Indeholder en række attributter og funktioner, som skal bruges i både Opgave, Aftale og Ressource. Primært Tilføj/Slet kommentar funktionerne og Beskrivelses attributten Attributter Navn Beskrivelse Beskrivelses dato Komponenter

65 11.1 Modelkomponent Opgave og aftale abstraktion * Ansvar og formål Indeholder en række attributter og funktioner som skal bruges i både Opgave og Aftale. For at undgå at skrive funktionerne to gange, placeres de i en superklasse, som Opgave og Aftale kan nedarve fra. *Navnet ikke særligt godt, men vi har ikke kunnet finde et bedre Attributter Bruger liste Start dato slut dato Ressource Ansvar og formål Attributter Indeholder attributter og funktioner som er fælles for Dokument, Litteratur og Person Oprettelsesdato Tilstandsdiagram til beskrivelse af klassens adfærdsmønster. Tilstandsdiagrammerne er en videreudvikling af tilstandsdiagrammerne fra analysen (se afsnit 5.4 på side 25), og er for størstedelen af klasserne trivielle, med undtagelse af Aftale og Opgave, der beskrives herunder. Aftale Når en aftale først bliver oprettet i systemet, vil der ikke være fastsat en start eller slut dato til den endnu, og den står blot som vedtaget, indtil en dato fastsættes. Idet datoen fastsættes, kan man vælge at aktivere påmindelsen, der vil minde brugeren om aftalen. Dette kan også gøres senere, og hvis den er aktiveret, kan den deaktiveres igen. Så længe aftalen endnu ikke er afholdt, vil tidsperioden kunne ændres. sideløbende med dette vil man på et hvilket som helst ovenstående stadie kunne tildele litteratur, dokumenter og personer til aftalen, samt kommentere den. Når først aftalen er afholdt, kan man kun tilføje dokumenter og kommentere aftalen. Aftalen kan på et hvilket som helst tidspunkt slettes. Opgave Opgaven ligner i grove træk aftalen meget, idet den kan deles op i to processer, den ene, hvor der blot kan tilføjes litteratur, dokumenter og personer, samt prioritere opgaven, ændre tidsperioden, notere kommentarer og vedtage underopgaver, sideløbende med dette kan man i den anden process fastsætte en tidsperiode, sætte opgaven i gang, stoppe den igen, og tage den af planen. Når opgaven færdiggøres i den sidste process, stopper den første også, og opgaven når nu et stadie hvor den kun kan kommenteres. Uafhængig af hvilket stadie opgaven er i, kan den altid slettes. 11. Komponenter 55

66 11.1 Modelkomponent Aftale vedtages Slet aftale Vedtaget* Litteratur tildeles Tidsperiode ændres Fastsat Tidsperiode fastsættes Påmindelse deaktiveres Påmindelse aktiveres Tidsperiode fastsættes [påmindelse] Aftale afholdes Fastsat m. påmindelse Aftale afholdes Kommentar noteres Tidsperiode ændres Dokument tildeles [Aftale afholdt] Aftale Person Tildeles Afholdt Dokument tilføjes Kommentar noteres Figur 11.2: Tilstandsdiagram for Aftale Opgave vedtages Opgave vedtaget Opgave tages af planen Tidsperiode ændres Kommentar noteres Litteratur tildeles Opgave sættes i gang Tidsperiode fastsættes Opgave planlagt Opgave igangsat Opgave stoppes Underopgave vedtages Opgave Dokument tildeles Opgave prioriteres Person tildeles Opgave færdiggøres [Opgave færdiggøres] Slet Opgave færdig Kommenter opgave Figur 11.3: Tilstandsdiagram for Opgave Komponenter

67 11.2 Funktionskomponent 11.2 Funktionskomponent Struktur Funktionskomponenten indholder fire klasser (se figur 11.4). Funktioner som Lav Todoliste og Lav Tidsplan ligger i denne komponent, da de er funktioner der opererer på på modelkomponenten. Konfigurations-klassen indeholder konfigurationsoplysninger, og dækker behovet for at gemme hver enkelt brugers individuelle konfigurationsoplysninger, som eksempelvis; sti til XML-databasen, sti til TortoiseSVN m.m. Det er således muligt at gemme data som kan være unik fra bruger til bruger. Klassen Initialisering bruges af systemet når dette startes. Funktionskomponent Initialisering +Opret nyt Projekt() +Slet Projekt() +Hent ProjektData() +Gem ProjektData() Tidsplan +Lav Tidsplan() Todoliste +Lav Todo-liste() Config-klasse -svncheckoutsti -tortoisesvnsti -defaultuser +Sæt SVNCheckoutSti() +Hent SVNCheckoutSti() +Sæt TortoiseSVNSti() +HentTortoiseSVNSti() +Sæt DefaultUser() +Hent DefaultUser() Figur 11.4: Klassediagram for funktionskomponenten Klasser Todo-liste Ansvar og formål Lav Todo-liste Formålet med klassen er at lave en todo-liste udfra listen af opgaver i Projekt-klassen. Denne funktion skal lave en todo-liste ud fra forskellige kriterier (deadline dato, prioritet, tilknyttede bruger etc.). Den nøjagtige specifikation af denne funktion er ikke veldefineret. 11. Komponenter 57

68 11.3 Systemgrænsefladekomponent Tidsplan Ansvar og formål Lav Tidsplan Denne klasse skal lave en tidsplan, så denne kan vises i brugergrænsefladen. Denne funktion skal lave og returnere en tidsplan, som brugergrænsefladefunktionen VisGrafiskTidsplan() kan bruge til at vise tidsplanen. Den nøjagtige specifikation af denne funktion er ikke veldefineret. Config Ansvar og formål Formålet med denne klasse er, at indholde data om, hvor SVN klienten ligger på brugerens system, hvor brugeren har sit SVN checkout bibliotek samt sti til TortoiseSVN. Attributter Tortoise dir SVN checkout dir Default user Initialisering Ansvar og formål Denne klasse skal kunne oprettet et Projekt-objekt, samt at slette det. Klassen skal også kunne hente og gemme Projekt-klassen Systemgrænsefladekomponent Systemet har ingen grænseflade til andre systemer, men skal dog selv understøtte versionsstyring via Subversion Brugergrænsefladekomponent På grund af tidspres i forbindelse med udformningen af dette designdokument, er dette afsnit blevet nedprioriteret, og følger derfor ikke designdokumentstandarden Præsentationsmodel Som beskrevet i afsnit 9.2 benytter brugergrænsefladen Windows Forms, som er et klassebibliotek i.net framework, der rummer funktionalitet til at tegne basale windows elementer som f.eks. knapper, faneblade, datagrids m.m. De mange trivielle klasser som laves ved brug af Windows Forms er bevidst udeladt fra komponentdiagrammet for overskuelighe Komponenter

69 11.4 Brugergrænsefladekomponent +VisGrafiskTidsplan(LavTidsplan()) Brugergrænseflade ProjektForside Dokumenter Kontakter Litteratur Opgaver Figur 11.5: Brugergrænsefladekomponent med klasser for hvert faneblad i systemet. dens skyld. Der refereres til (Microsoft Corporation, 2008c) for yderligere dokumentation om Windows Forms Programming. De fem klasser illustreret i brugergrænsefladediagrammet på figur 11.5 giver et overblik over de klasser, som administrerer fanebladene i systemet. Ved implementering af brugergrænsefladen anvendes User Controls til at gruppere mindre Controls som knapper, tekstboks o.l. Det bliver således nemmere at ændre brugergrænsefladen under programmeringsfasen såfremt behovet opstår. Relevante User Controls tilføjes til deres respektive klasser i brugergrænsfladediagrammet. Den eneste ikke-trivielle operation i brugergrænsefladen er VisGrafiskTidsplan(), som har til formål at tegne en tidsplan grafisk. Selve tidsplanen genereres af funktionen LavTidplan(), som ligger i Funktionskomponenten (se figur 11.4 på side 57). Inspirationen til tidsplanen kommer fra Gantt-kort (Nelson, 1999), men bliver dog en forsimplet udgave. I korte træk skal den blot vise en plan i vandrette grafer, uden nogen former for pile eller mærkater inde i grafen. Mærkater vil blive placeret i første kolonne Interaktionselementer Som det ses på figur 11.6 består programmet overordnet af fem faneblade: Project, Task, Contacts, Literature og Documents. Under Project, som kommer frem som forsiden af programmet, finder vi den grafiske tidsplan, samt muligheden for hurtigt at tilføje en opgave. Der ud over er der også en simpel oversigt af de vigtigste punkter fra Todo-listen, og en liste over de seneste kommentarer. I Tasks fanebladet (se figur 11.7 på næste side) bliver brugeren præsenteret for en liste af opgaver med tilhørende prioritet og deadline, hvor brugeren kan vælge mellem at se alle opgaver, eller kun dem hvor brugeren selv er tilknyttet. Det er under denne fane at brugeren får mulighed for at oprette nye opgaver, med lidt flere muligheder end dem der er givet under tidsplanen på forsiden. Der er desuden mulighed for her at redigere allerede eksisterende opgaver. Litterature fanebladet (se figur 11.7 på den følgende side) viser ligeledes en liste over litteratur, tilføjet til projektet, og giver mulighed for at redigere eksisterende litteratur, samt oprette ny litteratur. Contacts fanebladet (se 11.8 på næste side) præsenterer brugeren for en liste, hvor han kan 11. Komponenter 59

70 11.4 Brugergrænsefladekomponent Figur 11.6: Forside for BoBo Projects Figur 11.7: Fanebladene Tasks og Litterature vælge at se enten brugere eller kontaktpersoner, og har også her mulighed for at oprette eller redigere både brugere og kontakter. Document fanebladet (se 11.8) viser ligeledes en liste over dokumenter, tilføjet til projektet, og giver mulighed for at redigere eksisterende, samt oprette nye. Figur 11.8: Fanebladene Documents og Contacts Komponenter

71 11.5 Teknisk platform komponent 11.5 Teknisk platform komponent Struktur Komponenten Teknisk Platform rummer XML og SVN kommandoer, som er klasser, der har til opgave at kommunikere uden for systemets område. XML klassens opgave er at sørge for persistens i programmet ved at gemme og hente databasen, mens SVN kommandoer klassen skal stå for at sende kommandoer til TortoiseSVN om, at et repository enten skal opdateres eller synkroniseres. +Filnavn XML +GemDatabase() +HentDatabase() Teknisk platform komponent SVN kommandoer +Commit() +Update() Figur 11.9: Komponent for systemets tekniske platform Klasser XML Ansvar og formål Attributter Gem Database() Hent Database() XML-klassens opgaver er at gemme eller hente de data, der er bestemt som værende Serialisérbare. Filnavn Gemmer serialisérbar data i en XML-fil Henter data fra en XML-fil, givet ved filnavn, og gemmer det i serialisérbare objekter 11. Komponenter 61

72 11.5 Teknisk platform komponent SVN Kommandoer Ansvar og formål SVN Kommandoer er en feature-klasse, som står for at opdatere og committe databasen fra og til et SubVersion repository. Dette gøres via TortoiseSVN. Attributter Commit() Update() Sender en kommando til TortoiseSVN om, at et givent repository skal opdateres og committes Sender en kommando til TortoiseSVN om, at et givent repository skal opdateres Komponenter

73 12 Programmering 12.1 SVN kommandoer Koden for at opdatere SVN er rimelig simpel, idet den blot kalder TortoiseSVN fra kommandolinien, med stien til TortoiseSVN gemt i variablen svnpath, med argumentet /command:update der fortæller TortoiseSVN at den skal opdatere. path: og den efterfølgende variabel fortæller hvilken mappe TortoiseSVN skal opdatere, og for at få dette til at virke skal argumentet /notempfile med, da TortoiseSVNs standardinstilling ellers vil overskrive kommandolinie argumentet. Det sidste argument /closeonend:2 lukker automatisk TortoiseSVN når den er færdig, hvis der ikke opstår konflikter eller fejl. Koden for at committe er tilsvarende, med den eneste forskel på første argument, der nu er :/command:commit. 1 using System; 2 3 namespace BoBo_Project 4 { 5 class SVN 6 { 7 public static void Update(string updatepath, string svnpath) 8 { 9 System. Diagnostics.ProcessStartInfo updater = new System. Diagnostics.ProcessStartInfo("\"" + svnpath + "\\ bin \\ TortoiseProc.exe \""); 10 updater.arguments = "/ command: update / path :\"" + updatepath + "\" / notempfile / closeonend :2"; 11 System. Diagnostics. Process updateprocess = System. Diagnostics. Process.Start( updater); 12 updateprocess.waitforexit(); 13 } public static void Commit(string commitpath, string svnpath) 16 { 17 System. Diagnostics.ProcessStartInfo committer = new System. Diagnostics.ProcessStartInfo("\"" + svnpath + "\\ bin \\ TortoiseProc.exe \""); 18 committer.arguments = "/ command: commit / path :\""+ commitpath + "\" / notempfile / closeonend :2"; 19 System. Diagnostics. Process commitprocess = System. Diagnostics. Process.Start( committer ); 20 commitprocess.waitforexit(); 21 } 22 } 23 } 63

74 12.2 Slet Opgave 12.2 Slet Opgave Den nedenstående pseudokode illustrerer en rekursiv algoritme for sletning af en opgaves underopgaver og aftaler. DeleteTask tager som input en opgave (Task), og for hver underopgave kalder DeleteTask så sig selv, med denne underopgaver som input. Det betyder, at når en opgave slettes, så slettes også alle dens underopgaver samt alle relationer til denne bliver også fjernet. Eventuelle aftaler som er listet i Task, bliver desuden også slettet og aftalens relationer bliver ligeledes fjernet. Det er ikke denne metodes ansvar at slette den opgave som metoden bliver kaldt med. Dette ansvar overlades til den metode hvor kaldet til DeleteTask() kommer fra. 1 DeleteTask ( Task) 2 foreach agreement in agreementlist 3 RemoveRelations ( agreement ) 4 5 agreementlist = nil 6 7 RemoveRelations (this Task) 8 foreach subtask in subtasklist 9 DeleteTask ( subtask) subtasklist = nil 12 agreementlist = nil Listing 12.1: Pseudokode for sletning af en opgave Serializable Det har i forbindelse med test af Serializable vist sig besværligt at serialisere lister af objekter. Dette kunne blive et stort problem, da klassen Projekt eksempelvis skal have en række af forskellige lister som skal rumme objekter af Opgave, Aftale osv. Desuden viste det sig også at Serializable ikke gemmer referencer af objekter, men gemmer i stedet et objekts data under hver liste. Dette er et problem da der kan refereres til et objekt fra flere lister. Dette kunne f.eks. være et dokument som er tilknyttet både Projekt og Opgave. Med Serializable vil dokumentet eksistere som to identiske instanser i såvel Opgave som Projekt. For at få gemt systemets data anvendes i stedet DataContractSerializer, som er en feature, der blev implementeret med.net Framework 3.0. Med DataContractSerializer er det muligt både at serialisere lister af objekter, hvor dubletter af objekter i XML bliver refereret til via unikke ID Eksempel Vi giver her et eksempel på hvordan DataContractSerializer kan implementeres i C#: Nedstående kode viser hvordan selve filhåndteringen kan implementeres. Metoden Write- Object (linje 1) tager som input et objekt, hvilket kunne være en instans af klassen Projekt, og et filnavn. DataContractSerializer gemmer derefter det serialiserede objekt i en XML-fil Programmering

75 12.4 Eksempel Metoden ReadObject (linje 10) ligner WriteObject dog med den primære forskel, at denne metode returnerer det deserialiserede objekt, som bliver hentet fra den givne XML-fil. 1 public static void WriteObject (object obj, string filename, System. Type type) 2 { 3 using ( FileStream writer = new FileStream ( filename, FileMode. Create)) 4 { 5 DataContractSerializer ser = new DataContractSerializer ( type, null, int.maxvalue, false, true / p r e s e r v e O b j e c t R e f e r e n c e s /, null); 6 ser. WriteObject ( writer, obj); 7 } 8 } 9 10 public static object ReadObject (object obj, string filename, System. Type type) 11 { 12 using ( FileStream fs = new FileStream ( filename, FileMode. Open)) 13 { 14 XmlDictionaryReader reader = XmlDictionaryReader. CreateTextReader (fs, new XmlDictionaryReaderQuotas ()); 15 DataContractSerializer ser = new DataContractSerializer ( type); 16 return ser. ReadObject ( reader, true); 17 } 18 } Listing 12.2: Implementering af filhåndtering i forbindelse med brug af DataContractSerializer Anvendelse Nedenstående kode giver et eksempel på hvordan en serialiserbar klasse defineres. Dette eksempel skal således ikke blandes sammen med modelkomponentens klasser, idet klasserne i dette eksempel blot er lavet for at illustrere, hvordan DataContractSerializer kan anvendes. Der er i dette eksempel lavet to klasser: Klassen PersonList har, som navnet antyder, en liste (personlist, linje 5) som indholder objekter af typen Person. Til klassen hører også en metode Add, som giver mulighed for at tilføje personer til listen. Linje 1 definerer at denne klasse er serialiserbar, og linje 4 at personlist skal serialiseres. Klassen Person er en simpel klasse som blot kan rumme et navn. Det er værd at bemærke at properties i C# også kan serialiseres i stil med personlist fra før. 1 [ DataContract ( Name = " Personlist ")] 2 public class PersonList 3 { 4 [ DataMember (Name = "list")] 5 private List <Person > personlist = new List <Person >(); 6 7 public void Add( Person person) 8 { 9 personlist. Add( person); 10 } 11 } [ DataContract ( Name = " Person")] 14 public class Person 15 { 16 public Person(string Name) 17 { 12. Programmering 65

76 12.4 Eksempel 18 this. Name = Name; 19 } [ DataMember ()] 22 public string Name { get; set; } 23 } Listing 12.3: Eksempel-klasser til brug i forbindelse med DataContractSerializer. Med filhåndteringen og eksempel-klasserne på plads, kan vi sikkert eksekvere nedestående kode, som opretter tre personer, tilføjer dem til listen, og gemmer dem i filen: personlist.xml. Bemærk at p1 tilføjes til personlist to gange. 1 Person p1 = new Person(" Søren"), 2 p2 = new Person(" Peter"), 3 p3 = new Person(" Jonas"); 4 5 PersonList plist = new PersonList (); 6 plist. Add( p1); plist. Add( p2); plist. Add( p3); plist. Add( p1); 7 8 FileManagement. WriteObject ( plist, " personlist. xml", typeof( PersonList )); Listing 12.4: Programkode til illustration af eksempel. Ovenstående kode resulterer i følgende output: 1 <Personlist z:id="1" xmlns=" http: // schemas. datacontract. org /2004/07/ DataContractSerializerTest " xmlns:i=" http: // www. w3. org /2001/ XMLSchema - instance " xmlns:z=" http: // schemas. microsoft. com /2003/10/ Serialization /" > 2 <list z:id="2" z:size="4" > 3 <Person z:id="3" > 4 <Name z:id="4" >Søren </ Name > 5 </ Person ><Person z:id="5" > 6 <Name z:id="6" >Peter </ Name > 7 </ Person ><Person z:id="7" > 8 <Name z:id="8" >Jonas </ Name > 9 </Person > 10 <Person z:ref="3" i:nil=" true"/ > 11 </list > 12 </ Personlist > Listing 12.5: personlist.xml Linje 10 i 12.5 illustrerer, at DataContractSerializer laver referencer til andre objekter, når det registreres at multible referencer opstår. Her er lavet en reference til Person med Id 3 (linje 3-5) Programmering

77 13 Usabilityevalueringsplan Den følgende evalueringsplan bygger på principperne for Instant Data Analysis (IDA) (Kjeldskov et al., 2004) Formål Evalueringen af BoBo Projects vil blive en formativ evaluering med fokus på en validering af systemet. Det er således blevet planlagt at evaluering af systemet foretages en uge før et aftalt kodestop. Det forventes dermed, at den sidste uge af kodefasen kan benyttes til at foretage relevante ændringer af systemet på baggrund af denne evaluering Hovedspørgsmål Kan systemet fungere i en brugssammenhæng, og indfrier systemet de krav, vi har stillet til et projektstyringssystem? Herunder vil være test af de basale funktionaliteter, som administration af opgaver, tildeling af ressourcer, overvågning af tidsplan m.m. Et sekundært spørgsmål vil være til systemets mindre vigtige funktionaliteter, så som kommentering, ændring af egne brugeroplysninger, opstart af projekt m.m Brugerprofil Målgruppen for systemet er som tidligere beskrevet medlemmer af projektgrupper på CS. Derfor er det kun naturligt at udvælge testpersoner fra denne målgruppe. Det vil dog lagt vægt på, at det er personer, der ikke har særligt godt kendskab til usability, for at sikre testens realisme, og som har lidt kendskab til andre projektstyringssystemer, men ingen kendskab til BoBo Projects Deltagere og roller Deltagere i evalueringen er naturligvis de fire projektmedlemmer fra udviklingsteamet, samt 1-2 testpersoner. Af de fire projektmedlemmer vælges roller som beskrevet i (Kjeldskov et al., 2004), nærmere bestemt; facilitator, én til to dataloggers og en testmonitor. Testpersonerne er de testpersoner som skal udføre testen på systemet. 67

78 13.5 Evalueringsmetode 13.5 Evalueringsmetode Som allerede nævnt anvendes Instant Data Analysis, som bygger på at teste systemet på én dag Opgaveliste Testpersonerne får til opgave at teste nogle af de essentielle funktionaliteter i systemet. Herunder vil der blive fokuseret på at testpersonen får testet, om det er muligt at oprette opgaver, aftaler, litteratur, dokumenter, personer. Det følgende er udkast til de opgaver, der skal anvendes ved vores test. Den endelige udgave af opgavesættene kan ses i afsnit 17.1 på side 81. Ting skrevet i firkantede parenteser er ting, der kan ændre sig efter hvordan testen bliver udført. Det kan f.eks. være, at hvis testpersonen skal logge på med et bestemt brugernavn, så skrives dette [brugernavn1], men brugernavnet er ikke endeligt besluttet. Det bliver lavet specifikt til testpersonen. Tallet betyder dog at f.eks. [brugernavn1], og [brugernavn2] ikke kan være det samme. Dette skyldes at vi planlægger at afholde testen som 2 efterfølgende teste men på samme opsætning Opgavesæt 1 Du har lige oprettet projektet [projektnavn] for din projektgruppe. Lige nu er der ikke planlagt nogle opgaver på projektet, og der er kun én bruger, nemlig dig. Dit brugernavn er [brugernavn1], og din kode er [kode1]. Herunder kommer en række opgaver, hvor du bl.a. skal anvende disse til at udføre forskellige opgaver på systemet. 1. Log på systemet. 2. Noget af det første i skal have lavet i forbindelse med jeres projekt er en tidsplan. Opret en opgave ved navn "Lav tidsplan". Sæt tidspunktet for opgavens starttid til [tid1] og sluttiden til [tid2]. 3. I har aftalt et vejledermøde [vejledermødetid]. Tilføj denne aftale til projektet. 4. For at resten af din gruppe kan anvende systemet, skal de hver have en bruger i systemet. Opret brugerne [brugernavn2] og [brugernavn3]. Begge skal have koden [kode2]. 5. Jeres vejleder hedder [vejledernavn], har telefonnummer [vejledertelefon] og mailadressen [vejledermail]. Opret jeres vejleder som en kontaktperson i systemet. 6. Du har fundet en god bog, som i kan bruge som kilde i jeres projekt. Bogen hedder [titel], og er skrevet af [forfatter]. Bogen er [udgave], er udgivet i [år] på forlaget [forlag] og har ISBN [ISBN]. Tilføj bogen til projektets literaturliste Usabilityevalueringsplan

79 13.7 Lokalitet og udstyr Opgavesæt 2 Projektet [projektnavn] er blevet oprettet for din projektgruppe. Dit brugernavn er [brugernavn2], og din kode er til at starte med [kode2]. Herunder kommer en række opgaver, hvor du skal udføre forskellige opgaver på systemet. 1. Log på systemet. 2. Skift din adgangskode til noget du selv vælger. 3. Opret en opgave ved navn "Vejledermøder". Sæt datoen for opgavens start til [dato1] og slutdatoen til [dato2]. 4. Du har brug for at spørge jeres vejleder om noget angående projektet. Find hans telefonnummer i systemet. 5. Du vil være sikker på, at du har den nyeste information i systemet. Brug funktionen til at opdatere via SVN for at få de nyeste ændringer. 6. I har aftalt, at du skal være med til at fastsætte tidsplan for jeres projekt. Find opgaven "Lav tidsplan"og tilføj dig selv til opgaven. 7. Du er kommet i tanke om, at i skal huske at maile jeres tidsplan til jeres vejleder. Skriv en kommentar om dette til opgaven "Lav tidsplan" Lokalitet og udstyr Såfremt det er muligt, anvendes Institut for Datalogis Usability Lab, som er et laboratorie der rummer de nødvendige faciliteter til forskellige former for systemtest: Kameraer med mulighed for at optage testen, flere rum med én-vejs glas så dataloggeren ikke forstyrrer testen, mikrofoner m.m. Hvis det ikke er muligt at låne dette lokale anvendes i stedet et grupperum. Dette begrænser dog muligheden for at optage testen, og dataloggeren bliver desuden nødt til at befinde sig i samme rum som testmonitoren og testpersonen Dataopsamling Den primære kilde til dataopsamling bliver dataloggerens notater fra selve testen. Efter testen sætter facilitatoren, dataloggeren og testmonitoren sig sammen og brainstormer usabilityproblemer. Her vil testmonitoren have mulighed for at bidrage med, hvad han har observeret under testen. Produktet af denne brainstorm bliver en liste over usabilityproblemer. 13. Usabilityevalueringsplan 69

80 13.8 Dataopsamling Usabilityevalueringsplan

81 14 Testplan Vi anvender nunit (Poole et al., 2008) som test-framework, og tester løbende vores klasser, da vi har valgt at lave testdreven udvikling, i hvert fald på alle klasser i modelkomponenten. Om resten af klasserne skal udvikles på samme måde, besluttes senere i udviklingsforløbet. Med inspiration fra (The Code Project, 2003) 1 udvikler vi testdrevent efter opskriften: 1. Skriv en test. 2. Skriv et outline af de funktioner du har tænkt dig at lave, for at koden kan kompilere. 3. Kør testen. Den skulle gerne fejle. 4. Implementer koden der får testen til at bestå. 5. Kør testen. Den skulle gerne bestå. Hvis den ikke består, gå et skridt tilbage og prøv igen. Det er selvfølgelig ikke lige meget hvilken rækkefølge klasserne bliver udviklet i, da de fleste klasser er afhængige af andre. Selvfølgelig kan nogle elementer af en klasse udvikles uden at de abstrakte klassers egenskaber nedarves, men de definerede metoder i de abstrakte klasser er nødt til at blive testet inden de underliggende klasser kan skrives. Selvfølgelig kunne man teste metoderne fra de abstrakte klasser, i en af de underliggende, men det er mere overskueligt hvis man kun skal teste de ting man kan se direkte i en klasse når man læser den. I funktionskomponenten anvender vi hovedsageligt blacbox-test, da mange af funktionerne bygger på ting, vi har importeret fra andre biblioteker. Serializeable har f.eks. hentet ting fra andre biblioteker, og derfor er vi nødt til at lave blackbox-test her. Det kan dog ikke udelukkes at det vil give mening at køre whitebox-test på noget af det. 1 The Code Project er en side, som primært bruges til vidensudveksling blandt programmører verden over. Vi har ladet os inspirere af denne kilde, da den fremlagte metode synes at være et godt udgangspunkt. 71

82 Testplan

83 Del III Programmering 73

84

85 15 Programmering 15.1 Udviklingsmiljø Vi har anvendt Microsoft Visual C# Express 2008 version SP med.net Framework version 3.5 SP1, og programmet er skrevet i C#. For at få bedre struktur i koden, har vi valgt at inddele den i mapper, en for hver komponent, samt en til test, og en indeholdende små kodestumper, som vi kunne genbruge rundt om i programmet. Under brugergrænseflade mappen er der igen undermapper, en til hver fane, og en til brugergrænseflade elementer, der bruges flere steder. Denne mappestruktur kan ses på figur I mapperne ligger hver klasse i sin egen fil, så det er nemt at finde dem. Vi har desuden kodet jævnfør vores designprincipper som beskrivet i afsnit 10.2 på side 49. BoBoProjects Functions GUI AgreementcControls CommonControls ContactsControls DocumentControls LiteratureControls ProjectControls TaskControls Model Snippets Technical Test Figur 15.1: Mappestruktur i koden 15.2 Programbeskrivelse Når brugeren anvender programmet, foregår der en del bag scenen, som brugeren aldrig ser. Idet programmet åbnes, tjekker det om config filen findes på computeren, hvilket er en fil som BoBo Projects gemmer Configuration klassens variabler i. Findes denne ikke, oprettes mappen hvori den gemmes, og config wizarden popper op. Når brugeren har indtastet dataen, og trykket OK, gemmes config filen, og programmet forsøger at loade projektdataen. I det tilfælde at projektfilen ikke eksisterer på det specificerede sted, oprettes en ny projekt data fil. Så længe programmet kører vil det autosave hvert 3. minut, samt når brugeren lukker programmet. 75

86 15.3 Driftsmiljø 15.3 Driftsmiljø BoBo Projects er udviklet under.net Framework version 3.5 SP1, og kræver derfor dette for at køre (Microsoft Corporation, 2008b). Udover dette kræves det at TortoiseSVN er installeret for at udnytte programmets SVN features, men det er dog ikke et krav for grundlæggende brug og test af BoBo Projects Dokumentation Kildekoden for BoBo Projects dokumenteres ved hjælp af Doxygen (Heesch, 2008), som udfra en bestemt kommentarnotation, der manuelt udføres i selve kildekoden, kan generere dokumentation på overskuelig vis, i eksempelvis html. Denne digitale dokumentation af BoBo Projects findes i mappen Documentation på det digitale materiale, og rummer beskrivelser af systemets klasser og funktioner, i en overskuelig html udgave Programmering

87 Del IV Test & Evaluering 77

88

89 16 Test Udgangspunktet for test af BoBo Projects er beskrevet i afsnit 14 på side 71. Der afviges dog fra at benytte testdreven udvikling, og der foretages i stedet unit-tests på udvalgte klasser. Følgende klasser vælges til blackbox-test v.h.a. nunit (Poole et al., 2008); ProjectElement, XML og Relations. Der testes, om det er muligt at lave og slette relationer imellem Task og Document. Derudover testes om der muligt at tilføje navn og beskrivelse til klasser, der nedarver fra ProjectElement, og kommentarsystemet vil blive testet i denne sammenhæng. Test af XML-klassen skal sikre, at den nødvendige persistens opnåes ved at kontrollere, om systemet gemmer og henter som forventet. Den mest avencerede test gennemføres her, og omhandler Relations-klassen. Her oprettes relationer, som skal gemmes i en XML fil, hvorfra dataen herefter hentes og sammenligninges med den forventede data. Der udføres ingen formel white box tests på systemet. Kildekoden for de pågældende tests er at finde på det vedlagte digitale materiale, i mappen Test under Source code. 79

90 Test

91 17 Usabilityevaluering Dette kapitel er dokumentationen for usabilitytest af BoBo Projects, foretaget torsdag d. 4. december 2008 i Usability Lab på Institut for Datalogi v. Aalborg Universitet. Testen blev udført som beskrevet i evalueringsplanen fra afsnit 13 på side 67, dog med den undtagelse, at testen blev optaget, hvilket ikke er nødvendigt, hvis IDA-metodens fremgangsmåde skal følges. Vi har arbejdet med følgende alvorlighedsgrader for de fundne problemer: Kritisk Alvorlig Kosmetisk Programmet dør Der tabes arbejde Irriterende, men ikke noget der har større betydning 17.1 Opgaver Opgaverne i dette afsnit følger hovedsagligt opgaveudkastene fra afsnit 13.6 på side 68, hvor der dog er foretaget ændringer, så testpersonerne ikke skal udføre opgaver, der ikke er mulige i BoBo Projects Opgavesæt 1 Du har lige oprettet et nyt projekt for din projektetgruppe. Lige nu er der kun én bruger, nemlig dig. Dit brugernavn er mike. Herunder kommer en række opgaver, hvor du skal udføre forskellige opgaver på systemet. 1. Tilføj og telefonnummer til din egen bruger. 2. I skal lave et analysedokument i forbindelse med jeres projekt. Opret en opgave ved navn Analysedokument. Sæt tidspunktet for opgavens starttid til fredag d. 5. december 2008, kl. 8:30 og sluttiden til mandag d. 12. januar 2009, kl. 12:00. Sæt prioriteten til I har aftalt et vejledermøde onsdag d. 10. december 2008, kl. 13:00-14:00. Tilføj denne aftale til projektet. 4. For at resten af din gruppe kan anvende systemet, skal de hver have en bruger i systemet. Opret brugerne torben og lasse, og tilføj dem til opgaven Analysedokument. 5. Jeres vejleder hedder Sebastian Gunnarson, har telefonnummer og mail-adressen [email protected]. Opret jeres vejleder som en kontaktperson i systemet. 6. Du har fundet en god bog, som i kan bruge som kilde i jeres projekt. Bogen hedder Obvious mathematics and its applications, og er skrevet af Kenneth H. Borge. Bogen er 3. udgave, er udgivet i 2007 på forlaget Sølverdal og har ISBN: Tilføj bogen til projektets literaturliste. 81

92 17.2 Identificerede problemer Opgavesæt 2 Der er oprettet et projekt for din projektgruppe. Dit brugernavn er torben. Herunder kommer en række opgaver du skal udføre på systemet. 1. Tilføj telefonnummer og til din egen bruger. 2. I skal lave et analysedokument i forbindelse med jeres projekt. Denne opgave er allerede med i jeres planlægning. Når I er færdige med jeres analysedokument, skal I lave et designdokument. Opret en opgave ved navn Designdokument. Sæt tidspunktet for opgavens starttid til torsdag d. 15. januar 2009, kl. 8:00 og sluttiden til mandag d. 16. februar 2009, kl. 12:00. Sæt prioriteten til Jeres vejleder hedder Sebastian Gunnarson. Du har brug for at spørge jeres vejleder om noget angående projektet. Find hans telefonnummer i systemet. 4. I har aftalt at lasse, mike og dig selv, skal lave analysedokument. Find opgaven Analysedokument kontroller om brugerne er tilføjet til opgaven. 5. Bogen Obvious mathematics and its applications skal bruges i forbindelse med analysedokumentet. Tilføj bogen til opgaven Analysedokument. 6. I har aftalt et vejledermøde i forbindelse med jeres projekt. Tilføj alle brugere, samt jeres vejleder til denne aftale Identificerede problemer Følgende problemer blev identificeret i forbindelse med usabilitytesten. Et X indikerer at fejlen blev registreret under den givne testpersons usabilitytest. En * indikerer at dette problem er nævnt i testpersonens interview. # Beskrivelse Alvorlighedsgrad Testperson 1 Testperson 2 1 Navnene på fanerne er misvisende. Der var bl.a. problemer med at finde Users, og tvivl om Agreements var en aftale. 2 Ingen feedback når man gemmer. Når man gemmer er der ikke noget i brugerinterfacet der angiver om der er blevet gemt eller ej. Der er dog en hvis form for feedback når man opretter et nyt element, da denne dukker op i listen når man gemmer. Kosmetisk X* X* Alvorlig X* X* Usabilityevaluering

93 17.2 Identificerede problemer # Beskrivelse Alvorlighedsgrad Testperson 1 Testperson 2 3 Når man laver en ny Task og gemmer, kommer den frem i All tasks, men den skifter ikke over til All tasks, selvom brugeren ikke har tilføjet sig selv til opgaven. 4 Tvivl om login-situation. Der er ikke noget i brugerinterfacet der indikerer hvilken bruger man er logget på med. 5 Der er tvivl om felternes brug i Literature. Brugeren havde svært ved at finde ud af hvor ISBN skulle være, og gættede (forkert) på hvor det skulle være. Interviewet afslørede at han heller ikke var klar over at felterne i Literature repræsenterede BiBTeX-felter, da det ikke stod i interfacet. Der var også tvivl om Edition-feltet. 6 Brugeren var i tvivl om han havde oprettet Tasks rigtigt, da han så Add new task på forsiden. 7 Brugeren dobbeltklikkede på tidslinjen for en Task i Timetable, og forventede at programmet ville springe til Tasks-fanen, men det skete ikke. 8 Ingen brugere brugte værktøjslinjen. Testperson 2 sagde i interviewet: Der er inkonsistens mellem et skærmbilledes funktionalitet, og det man rent faktisk kan. F.eks. knapperne i værktøjslinien virker som om de hører til hvert enkelt faneblad, men de er bare genveje. De skiftede ikke når man skiftede faneblad. 9 Brugeren opdagede ikke at han lavede en ny Task da han skulle tilføje brugere til den. 10 Tiden skifter automatisk til noget forkert. Starttiden bliver sat til sluttiden når man ændrer sluttiden. Brugerne opdagede ikke dette. Kosmetisk X Alvorlig X Alvorlig X* Kosmetisk X* Kosmetisk X Kosmetisk X X* Alvorlig X Alvorlig X X 17. Usabilityevaluering 83

94 17.2 Identificerede problemer # Beskrivelse Alvorlighedsgrad Testperson 1 Testperson 2 11 Save-knappen i vinduerne til at tilføje brugere og ressourcer i Task og Agreement var forvirrende. Brugerne troede at det blev gemt når de klikkede på Save i dette vindue, og de derfor ikke behøvede at klikke Save i den Task eller Agreement de arbejde med. 12 Brugeren kunne ikke finde vejledermødet. Han var nødt til at se alle tabs igennem for at finde det. Foreslog Appointment i stedet for Agreement. Testperson 1 nævner i interviewet: Agreement havde jeg svært ved at gennemskue. Man kunne måske lidt for meget. Den må gerne være mere specifik. 13 Tvivl om værktøjslinjens brug Testperson 2 nævner i interviewet at værktøjsliniens placering får den til at virke som om den hører til hver enkelt fane, og derfor har forskellig funktionalitet efter hvilken fane man befinder sig på. Alvorlig X* X Kosmetisk * X Kosmetisk X* 14 Under Tasks: Startdatoen blev automatisk sat til slutdatoen, når man valgte en startdato der tidsmæssigt lå efter slutdatoen. Slutdatoen under blev automatisk sat til startdatoen, når man valgte en slutdato der tidsmæssigt lå før startdatoen. Ingen af testpersonerne opdagede dette. 15 sec:opgavesaet Windows Forms fejl Testperson 2 nævner i interviewet: Da jeg skulle tilføje brugere til vejledermødet: Når der blev checket en bruger, og man valgte at checke næste blev den bruger man trykkede på ikke checked, men den tidligere bruger afchecket igen, dette var dog ikke hver gang. Muligvis fejl i windows forms. Det kan evt. være fordi maskinen ikke havde.net Framework 3.5, men 3.0 som højeste version. Alvorlig Kosmetisk X* Usabilityevaluering

95 17.3 Problemfordeling 17.3 Problemfordeling Kritisk 0 Alvorlig 7 Kosmetisk 8 Total 15 Identificeret i interview 9 Ikke identificeret i interview 6 Total Interviewguide Hver testperson blev efter testen stillet følgende spørgsmål: 1. Hvad synes du overordnet om systemet? 2. Vil det være en system, som kun bruges under projektet på CS. 3. Var der nogle features du manglede? 4. Var der nogle features som du synes var for meget? 5. Oplevede du fejl ved systemet? 6. I så fald: Hvad var de(n) største? 7. Hvad synes du om selve testen? - Var den realistisk? 8. Har du ellers nogle bemærkninger? 17.5 Interviewreferat: Testperson 1 Testperson: Testperson 1 Studieretning: Datalog (Dat1) 1. Svært at få overblik. Så potentiale i det. 2. Det tror jeg helt klart. Når man lige har gennemskuet det, tror jeg det kunne være brugbart. Især tidsplanen på forsiden var sej. 3. Nej, jeg vil mene der er sådan cirka alt det man skal bruge i et projekt. 4. Agreement havde jeg svært ved at gennemskue. Man kunne måske lidt for meget. Den må gerne være mere specifik. Det var måske lidt malplaceret med at kunne tilføje opgaver fra forsiden. Tænkte først over det senere da jeg fik øje på den. 17. Usabilityevaluering 85

96 17.6 Interviewreferat: Testperson 2 5. Testperson 1: Ja, men der var dog ikke nogen exceptions. Det var træls at der ikke skete noget i GUI når man trykkede save. Da jeg havde tilføjet brugere til en opgave, troede jeg også det var ok at jeg bare havde trykke save, og at jeg ikke skulle trykke save bagefter også. På et tidspunkt gik jeg ind under Task-tabben først, og troede det var en ny opgave der var der var gjort klar til, men opdagede at der i toppen stod Edit item, så kiggede efter en New-knap, og fandt og brugte den. Tror der ville komme en exception hvis han ikke havde trykke new. Litteratur: Kunne ikke finde felt til ISBN. Skrev den i Literature Information. Jimmy: Den skulle have været i Number da felterne er taget fra BiBTeX. Testperson 1: Kunne godt have brugt lidt hjælp til at placere info. Jimmy: Kunne det have hjulpet at der stod at det var BiBTeX-felter. Testperson 1: Ja måske, men det ville hjulpet bedre med at der var forskellige formularer for hver type litteratur. Fanebladet Contacts indeholder både brugere og kontakter, så derfor kunne den godt hedde f.eks. Persons i stedet, men det kan man jo nok vænne sig til. 6. At der ikke sker noget når man trykker save. 7. Ja. Kunne godt tænke mig at have haft en opgave hvor jeg skulle kigge på tidsplanen på forsiden, for den så sej ud. Ellers var det rigtigt godt. 8. Programmet så kedeligt ud, men det er jo projektstyring. Det skal jo være kedeligt for at være godt. Det er i hvert fald tydeligt at det er meningen at det skal være funktionelt, og det synes jeg er fint Interviewreferat: Testperson 2 Testperson: Testperson 2 Studieretning: Softwareingeniør (SW5) 1. Umiddelbart ser det fint ud selvom der er lidt fejl. 2. Det kunne det godt, hvis folk har disciplinen til at bruge det, for ligeså snart bare en enkelt bog bliver udeladt fra systemet, så bliver det et problem. 3. Ja. Manglede at kunne komme over til Task-fanen når jeg dobbeltklikkede på en task i Timetable. Respons når jeg trykkede på save. Man havde ikke følelsen af at der skete noget overhovedet. 4. Nej. Ikke af dem jeg prøvede. 5. Ja. Da jeg skulle tilføje brugere til vejledermødet: Når der blev checket en bruger, og man valgte at checke næste blev den bruger man trykkede på ikke checked, men den tidligere bruger afchecket igen, dette var dog ikke hver gang. Muligvis fejl i windows forms. Der er inkonsistens mellem et skærmbilledes funktionalitet, og det man rent faktisk kan. F.eks. knapperne i værktøjslinien virker som om de hører til hvert enkelt faneblad, men de er bare genveje. De skiftede ikke når man skiftede faneblad Usabilityevaluering

97 17.6 Interviewreferat: Testperson 2 6. Inkonsistens 7. Umiddelbart ja. Ville bare gerne have oprettet vejledermødet selv i stedet for kun at tilføje brugere. Havde følelsen af at "Hvorfor tilføjede man ikke det i første omgang?". 8. Næh. 17. Usabilityevaluering 87

98

99 Litteratur Bryant, Stephen Bryant. How to do Your Referencing Using the Harvard System, URL [Online; accessed 10-December-2008]. Heesch, Dimitri van Heesch. Doxygen - Source code documentation generator tool, URL [Online; accessed 10-December-2008]. Horstmann og Pellegrin, Cay S. Horstmann og Alexandre de Pellegrin. Violet UML Editor, URL [Online; accessed 11-December-2008]. Kjeldskov, Skov, og Stage, J. Kjeldskov, M. B. Skov, og J Stage. Instant Data Analysis: Evaluating Usability in a Day. Proceedings of NordiCHI 2004, pages , pdf&coll=portal&dl=acm&cfid= &cftoken= Mathiassen, Munk-Madsen, Nielsen, og Stage, Lars Mathiassen, Andreas Munk-Madsen, Peter Axel Nielsen, og Jan Stage. Objekt Orienteret Analyse & Design. ISBN: , 3. udgave. marko, Microsoft Corporation, 2008a. Microsoft Corporation. Microsoft Office Visio 2007, 2008a. URL [Online; accessed 11-December-2008]. Microsoft Corporation, 2008b. Microsoft Corporation. Microsoft.NET Framework 3.5 system Requirements, 2008b. URL FD-AE52-4E35-B D977D32A6&displaylang=en#Requirements. [Online; accessed 14-December-2008]. Microsoft Corporation, 2008c. Microsoft Corporation. Windows Forms Programming, 2008c. URL [Online; accessed 5-November-2008]. Nelson, R. Ryan Nelson. Gantt and PERT Charts, URL [Online; accessed 13-November-2008]. 89

100 LITTERATUR Nørmark, Kurt Nørmark. The Singleton pattern, URL themes-patterns-techniques-sect.html#more-classes_singleton_title_1. [Online; accessed 15-December-2008]. Poole, Cansdale, og Feldman, Charlie Poole, Jamie Cansdale, og Gary Feldman. nunit - Unit-testing framework for all.net languages, URL [Online; accessed 10-December-2008]. Studienævn for Naturvidenskab, Studienævn for Naturvidenskab. Studieordning for Bacheloruddannelsen i Datalogi, URL f08/datbachkand_sept2007_sept2008.html. [Online; accessed 10-December-2008]. The Code Project, The Code Project. Test-Driven Development in.net, URL http: // [Online; accessed 9-November-2008]. Visual Paradigm International, Visual Paradigm International. Visual Paradigm for UML 6.4 Enterprise Edition, URL [Online; accessed 11-December-2008]. Wikipedia, Wikipedia. List of project management software Wikipedia, The Free Encyclopedia, URL of_project_management_software&oldid= [Online; accessed 2-October-2008]. 90 LITTERATUR