BoBo Projects - et projektstyringssystem DAT1 PROJEKT 2008 GRUPPE D101A INSTITUT FOR DATALOGI AALBORG UNIVERSITET DEN 19. DECEMBER 2008
Titel: BoBo Projects Tema: Udvikling af programmel Projektperiode: DAT1, efterår 2008 Projektgruppe: d101a Deltagere: Institut for Datalogi Aalborg Universitet Selma Lagerlöfs Vej 300 9220 Aalborg Ø Telefon +45 9940 9940 Fax +45 9940 9798 http://cs.aau.dk 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.
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.
Indhold Indhold III Studierapport 1 1 Indledning 3 2 Erfaringer 5 2.1 Analyse.................................... 5 2.2 Design..................................... 6 2.3 Programmering................................ 7 2.4 Test...................................... 9 2.5 Usabilityevaluering.............................. 9 3 Opsummering 13 Bilag 15 I Analysedokument 17 4 Opgaven 19 4.1 Formål..................................... 19 4.2 Systemdefinition............................... 19 4.3 Omgivelser.................................. 20 4.4 Problemområde................................ 21 4.5 Anvendelsesområde.............................. 21 5 Problemområde 23 5.1 Klynger.................................... 23 5.2 Struktur.................................... 23 5.3 Klasser.................................... 25 5.4 Hændelser................................... 25 6 Anvendelsesområde 31 6.1 Brug...................................... 31 6.2 Funktioner................................... 35 III
INDHOLD 6.3 Brugergrænsefladen.............................. 37 7 Videre udvikling 41 7.1 Den tekniske platform............................. 41 7.2 Anbefalinger................................. 41 7.3 Strategi.................................... 41 7.4 Udviklingsøkonomi.............................. 41 II Designdokument 43 8 Opgaven 45 8.1 Formål..................................... 45 8.2 Rettelser til analysen............................. 45 8.3 Kvalitetsmål.................................. 45 9 Teknisk platform 47 9.1 Udstyr..................................... 47 9.2 Basisprogrammel............................... 47 9.3 Systemgrænseflade.............................. 47 9.4 Designsprog.................................. 47 10 Arkitektur 49 10.1 Designkriterier og arkitektoniske krav.................... 49 10.2 Generiske design beslutninger........................ 49 10.3 Komponent arkitektur............................. 50 10.4 Eksemplariske design............................. 50 11 Komponenter 53 11.1 Modelkomponent............................... 53 11.2 Funktionskomponent............................. 57 11.3 Systemgrænsefladekomponent........................ 58 11.4 Brugergrænsefladekomponent........................ 58 11.5 Teknisk platform komponent......................... 61 12 Programmering 63 12.1 SVN kommandoer.............................. 63 12.2 Slet Opgave.................................. 64 12.3 Serializable.................................. 64 12.4 Eksempel................................... 64 13 Usabilityevalueringsplan 67 13.1 Formål..................................... 67 13.2 Hovedspørgsmål............................... 67 13.3 Brugerprofil.................................. 67 13.4 Deltagere og roller.............................. 67 13.5 Evalueringsmetode.............................. 68 IV INDHOLD
13.6 Opgaveliste.................................. 68 13.7 Lokalitet og udstyr.............................. 69 13.8 Dataopsamling................................ 69 14 Testplan 71 III Programmering 73 15 Programmering 75 15.1 Udviklingsmiljø................................ 75 15.2 Programbeskrivelse.............................. 75 15.3 Driftsmiljø................................... 76 15.4 Dokumentation................................ 76 IV Test & Evaluering 77 16 Test 79 17 Usabilityevaluering 81 17.1 Opgaver.................................... 81 17.2 Identificerede problemer........................... 82 17.3 Problemfordeling............................... 85 17.4 Interviewguide................................ 85 17.5 Interviewreferat: Testperson 1........................ 85 17.6 Interviewreferat: Testperson 2........................ 86 Litteratur 89
Studierapport
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
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
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. 2.1.1 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. 2.1.2 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
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. 2.1.3 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
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å. 2.3.1 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
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. 2.3.2 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. 8 2. Erfaringer
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 67. 2.5.1 Æ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
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. 2.5.2 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 84. 2.5.3 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 10 2. Erfaringer
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 2.5.3 på forrige side) stemmer fuldstændigt overens med vores mål for brug beskrevet i analysedokumentets afsnit 6.3.1 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
2.5 Usabilityevaluering 12 2. Erfaringer
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
Bilag
Del I Analysedokument 17
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
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 20 4. Opgaven
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 23. 4.5 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
4.5 Anvendelsesområde 22 4. Opgaven
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. 5.2.1 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 5.2.3 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
5.2 Struktur Figur 5.2: Klassediagram 5.2.2 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. 5.2.3 Projektelement og Ressource Både Projektelement og Ressource er abstrakte klasser. De eksisterer alene for at andre klasser kan nedarve deres egenskaber. 5.2.4 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. 24 5. Problemområde
5.3 Klasser 5.2.5 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. 5.4.1 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
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 5.4.2 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. 5.4.3 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 26 5. Problemområde
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. 5.4.4 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
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. 28 5. Problemområde
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
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. 30 5. Problemområde
6 Anvendelsesområde 6.1 Brug 6.1.1 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
6.1 Brug denne aktørs rolle er projektadministrativ, og derfor tilhører disse brugsmønstre projektmedlemmet. 6.1.2 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 32 6. Anvendelsesområde
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. 6.1.3 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. 6.1.4 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