Prosess- dokumentasjon

Transkript

1 Prosess- dokumentasjon

2 Forord Prosessdokumentasjonen viser hvordan arbeidet med hovedprosjektet er utført. Dokumentet vil gi en beskrivelse av hvordan vi har jobbet, hvilke arbeidsmetoder vi har benyttet oss av, hvilke rammebetingelser vi har hatt, verktøy vi har benyttet oss av, utfordringer og problemer, samt løsninger på disse problemene. Det er ikke nødvendig med IT-kompetanse for å forstå denne rapporten og dokumentet er optimalisert for papirutskrift. 6

3 Innholdsfortegnelse Forord... 6 Innledning Presentasjon av oppdragsgiver Problemstilling Dagens situasjon Mål Rammebetingelser Prosjektmetodikk Planlegging Generelt Fremdriftsplan og arbeidsfordeling Risikoanalyse Utforming Hvordan har vi forholdt oss til den Utviklingsprosessen Faser i prosjektet Prosjektstart Forprosjekt Kompetansetilegning Implementasjon Testing Utfordringer Virtuelle maskiner Hvordan deklarere variable i php-filene? Problemer med databasen Kvaliteten på prosjektet Brukervennlighet Teknologi Kravspesifikasjoner Generelt Utfordringer

4 3. Oppsummering Avslutning Oppsummering Hva kunne vi gjort annerledes? Produktets framtid

5 Innledning 1. Presentasjon av oppdragsgiver Reidar Kvadsheim er ansatt som førsteamanuensis ved Avdeling for Ingeniørutdanning, Høgskolen i Oslo. Han har graden mag.art. i sosiologi samt graden dr. philos. fra Universitetet i Oslo med et avhandlingstema hovedsaklig innenfor psykologi. Hans forskningsinteresser omfatter blant annet studier av handlingsvalg, læringsprosesser og nettbaserte automatiske systemer for læringsstøtte. 2. Problemstilling Skrevet av Reidar Kvadsheim (oversatt fra engelsk) Sett at du blir konfrontert med et sett handlingsalternativer. Hvilket alternativ vil du velge? Mer generelt, hva bestemmer styrken på din interesse for de forskjellige handlingsalternativene, og hva bestemmer din motivasjon for valget? Som forsker trenger jeg å ha muligheten til å endre størrelsen på de faktorene som påvirker hvilket alternativ mennesker velger. Videre må jeg observere om disse endringene varierer i samsvar med deres valg. For å konkludere med at disse faktorene faktisk forårsaker de observerte variasjonene i menneskers oppførsel, må jeg hindre variasjoner i andre faktorer som også kan påvirke oppførselen. Dette betyr at jeg må ha muligheten til gjennomføre et eksperiment der deltakerne blir satt i en enkel, delvis kunstig verden. I denne verdenen er alle relevante erfaringer hos deltakerne kontrollert av forskeren i en tilstrekkelig lang tidsperiode. Programmet som presenteres i denne rapporten har blitt laget for at jeg skal kunne opprette slike kontrollerte, eksperimentelle verdener. Deltakerne sitter foran en dataskjerm og blir bedt om å velge én av tre målfigurer, som er plassert langs den øvre kanten av skjermen. Deretter må han prøve og nå målet ved å forflytte seg med en pil. Denne pilen har sin startposisjon i midten av den nederste kanten på skjermen og kan forflyttes i flere steg mot målet. Når jeg konfigurerer et nytt eksperiment, må jeg blant annet ha muligheten til å bestemme antall steg pilen må flyttes for å nå målet, hvor 9

6 hurtig deltakeren må foreta et steg etter det foregående og hvor mange poeng det er mulig å tjene hvis han først velger og deretter treffer et gitt alternativt mål. Ved å la forskjellige grupper av deltakere foreta valg under forskjellige forhold, har jeg muligheten til å få svar på spørsmål som: Vil en person som bruker mye tid på å treffe et gitt mål ha større sannsynlighet for å velge dette målet ved senere anledninger? Mer generelt, har størrelsen på en tidligere investering i et gitt mål innflytelse på hvor attraktivt dette målet er for personen i senere valgsituasjoner? Anta at en deltaker har blitt instruert til å bevege seg mot et gitt mål ( forced choice ), mens en annen deltaker har valgt det samme målet av fri vilje ( free choice ). Er det større sannsynlighet for at den første personen velger det samme målet frivillig i et senere tilfelle? Mer generelt, vil friheten til å velge i en gitt situasjon påvirke valget i en annen tilsvarende situasjon? Hvis dette er tilfellet, vil friheten øke eller minke handlingsmotivasjonen? Den nåværende programversjonen er basert på resultatene til to foregående hovedprosjektgrupper, våren 2007 og Det ligger forholdsvis begrensede forskningsmuligheter i de tidligere versjonene av programmet. I tillegg har min praktiske erfaring som bruker av programmet gjort det ønskelig med en forbedret versjon. Spesielt trenger jeg å kunne: konfigurere eksperimentene på en mer effektiv og forskervennlig måte, som krever mindre tid og minsker sjanser for feil. kjøre eksperimenter med flere deltakergrupper, og flere eksperimentelle betingelser. videreutvikle eksisterende programversjon på en enkel måte ved å bygge videre på en eksisterende generell, velfungerende og godt dokumentert plattform. En stor utfordring for denne prosjektgruppen har vært å overvinne eller redusere begrensningene i de tidligere versjonene av programmet og dokumentasjonen. Det har vært behov for å kunne skille mellom flere enn to grupper av forsøkspersoner og flere enn ti lengder på veien fra start til mål i spillet. Videre har det vært ønskelig å 10

7 kunne bruke flere enn seks ulike målfigurer i gjennomføringen av et spill. I tillegg bør det være enkelt å hente nye målfigurer fra vilkårlige mapper eller fra kilder på nettet, og legge dem i biblioteket av målfigurer. Dessuten har det vært behov for et enklere og mer oversiktlig grafisk grensesnitt, slik at konfigureringen blir lettere og foreta. For øvrig savnes det bedre dokumentasjon av to slag: dokumentasjon i forhold til den som skal konfigurere spillet og kjøre eksperimenter med det i forskning, og dokumentasjon i forhold til fagfolk på datasiden som skal drifte og videreutvikle programmet. For prosjektgruppen har den største utfordringen likevel ikke vært å gjennomføre disse forbedringene i forhold til tidligere, men i det hele tatt å få programmet til å fungere. 3. Dagens situasjon I dette prosjektet skal vi jobbe med en tredje versjon av spillet FigureGame, som skal benyttes i psykologiske eksperimenter. Oppgaven har blitt gitt som hovedprosjekt både våren 2007 og 2008, men ingen av disse gruppene kom i mål med et tilfredsstillende produkt. Den første gruppen kom fram til et program som fungerte i noen grad, men det var upålitelig, ustabilt og hadde funksjonsproblemer som fortsatt ikke er løst. Versjonen hadde også tre andre hovedmangler: spillet er begrenset til to grupper og seks figurer, konfigurasjonsdelen er svært tungvint for brukeren og dokumentasjonen er utilstrekkelig. Den andre gruppen kom ikke helt fram til et fungerende spill, men hadde gode ideer for enklere konfigurasjon av spillet. Vår oppgave med FigureGame 3.0 blir derfor å videreutvikle spillet og forbedre konfigurasjonsmetoden i henhold til kravspesifikasjonene. I tillegg skal dokumentasjonen forbedres slik at det blir enklere å vedlikeholde og drifte programmet i fremtiden. Selve spillet, FigureGame 3.0, fungerer ved at en testperson må flytte en pil mot en målfigur. Dette skal utføres ved hjelp av pilene på Figur 1: Spillevindu tastaturet. Disse bevegelsene bør skje uten feil og personen får belønning i form av poeng når målet er nådd. Formålet med hver runde i spillet kan variere på noen runder kan testpersonen få beskjed om å bevege seg mot 11

8 et definert mål, mens på andre runder kan det være aktuelt å bevege seg mot et valgfritt mål. En deltaker bør i så fall velge å bevege seg mot den figuren som gir flest poeng (poengene er gitt over figurene). En testperson vil også møte på en del spørsmål, som er viktige i eksperimentet. Før spillet starter, må han svare på noen få private spørsmål, som alder, kjønn, syn og hørsel, og når spillet er fullført får deltakeren noen spørsmål om hvordan testen ble oppfattet underveis. Vårt hovedproblem er å endre på konfigurasjonssiden, som benyttes for å administrere spillet. Denne siden skal styre alle rundene i et spill, blant annet antall steg fram til målfiguren, lengden på pauser, hvilke figurer som skal benyttes, kommentarer til deltakerne og så videre. FigureGame 3.0 er knyttet til en database, slik at all data fra en gjennomføring av spillet blir lagret og kan hentes ut igjen ved en senere anledning. Den første prosjektgruppen hentet ut all data til et Excel-ark og dette har vi bevart. 4. Mål I prosjektavtalen signerte vi følgende mål for prosjektet: Vi skal sette oss inn i og videreutvikle et allerede eksisterende program. Programmet fungerer, men har store begrensninger. Vårt mål er derfor å utvikle et program som tilfredsstiller oppdragsgivers ønsker. Underveis i prosjektet ble det nødvendig å omformulere målet. Vår oppgave har hele tiden vært å videreutvikle et program som allerede eksisterer, men vi har hatt en del problemer som har hindret oss i dette. Et nytt delmål har derfor vært å få spillet til å fungere før vi har kunnet jobbe med de opprinnelige oppgavene. 5. Rammebetingelser Vi har blitt tildelt en Virtuell Maskin fra Høgskolen i Oslo. Denne maskinen er satt opp med Linux/UNIX-operativsystem med Debian som programvaredistributør, Apachewebserver, Java og MySQL. Annet software og utviklingsverktøy kan installeres ved behov siden vi har administrasjonsrettigheter til maskinen. Videre har vi valgt å jobbe på den samme plattformen, som den første prosjektgruppen opprinnelig valgte (gruppe to valgte derimot å gå helt bort fra denne plattformen, men kom ikke fram til et program som fungerte). Dette innebærer at vi har benyttet oss av Java og PHP som utviklingsspråk og MySQL for databasen. 12

9 6. Prosjektmetodikk Høgskolen i Oslo legger opp til bruk av Fossefallsmodellen for prosjektgjennomføring, der noen krav til leveranse ble gitt oss allerede før prosjektstart. Det betyr at vi har hatt tidsfrister å forholde oss til underveis i prosjektet. Vi har holdt oss innenfor disse fristene, men utover dette benyttes ikke Fossefallsmodellen videre for prosjektgjennomføring. Prosjektgruppen har heller valgt å jobbe i SCRUM i kombinasjon med extreme Programming (XP). Disse er for oss mer smidige og effektive metoder. SCRUM baserer seg på at gruppen er selvdrevet og har fullmakter til selv å definere mål for utviklingen av programvare. Vi har fått en liste over ønsker til hva som skal implementeres, men vi jobber ikke ut fra spesifikasjoner eller en detaljert arbeidsplan. Siden vi jobber i SCRUM vil prosjektet gjennomføres i mindre iterasjoner/faser, som normalt vil ha en lengde på en til fire uker. I forkant av hver iterasjon vil vi ha et møte der vi avgjør hva som må implementeres, og i etterkant av hver iterasjon vil vi teste programmets funksjonalitet. SCRUM tillater også hyppigere møtevirksomhet med oppdragsgiver og dette er viktig for oss. Vi ønsker fortløpende tilbakemeldinger om utviklingene i programmet. XP er en lettvektsprosess som er meget adaptiv. Dette gjør at det blir lettere å gå tilbake i arbeidet for å gjøre endringer. Det blir lettere å styre utviklingen, prosessen blir mer smidig og fleksibel og det er lettere å implementere nye krav. En viktig side ved XP er kontinuerlig kommunikasjon, så det er viktig for oss å ha en god dialog med oppdragsgiver. 13

10 Planlegging 1. Generelt Planleggingen av prosjektgjennomføringen ble hovedsakelig basert på en liste over ønsket funksjonalitet fra oppdragsgiver. Det var ikke krav til at alle punktene på denne listen skulle implementeres i den nye versjonen av programmet, men den ble allikevel et utgangspunkt for formuleringen av kravspesifikasjonen. Vi har også brukt denne listen som utgangspunkt for planleggingen av prosjektets fremdrift. 2. Fremdriftsplan og arbeidsfordeling Tidlig i prosjektet fikk vi, i samarbeid med oppdragsgiver, utarbeidet en kravspesifikasjon. Denne spesifikasjonen inneholdt noen ønsker til hvordan programmet kunne videreutvikles, men totalt sett fikk vi relativt frie tøyler og åpent rom for innspill og nye forslag. Reidar Kvadsheims ønsker ble uansett en basis for hvordan vi skulle sette opp en prosjektplan og hvilke oppgaver vi skulle prioritere framfor andre. Vi fikk formulert en plan over milepæler relativt tidlig i prosessen og et samsvarende ansvarskart, men måtte halvveis gjennom prosessen gå helt bort fra denne og formulere dokumentene på nytt. Grunnen til dette er at prosjektgruppen fikk en del problemer i forhold til den virtuelle maskinen vi jobbet på, som forplantet seg videre til de filene vi jobbet med og videre til databasen. Disse problemene vil bli beskrevet grundigere senere i dette dokumentet. Problemene førte til at vi mistet en del verdifull tid i forhold til de oppgavene vi hadde definert, så milepælene ble forskjøvet og noen oppgaver måtte vike for at vi skulle få den nye maskinen og spillet til å fungere slik det hadde gjort i utgangspunktet. Når dette er sagt, så har programmeringen av oppdragsgivers ønsker og testingen av kode gått fint for oss når vi endelig har hatt muligheten til å jobbe med disse oppgavene. Det ble også mer realistisk å forholde seg til milepælsplanen og ansvarskartet etter at de ble editert. Begge dokumentene er lagt med som vedlegg til rapporten. 14

11 3. Risikoanalyse 3.1 Utforming Ved prosjektstart satte vi opp en grundig gjennomtenkt liste over eventuelle risikoer som kunne oppstå for oss underveis i gjennomføringen, samt mulige tiltak vi kunne iverksette for å unngå risikoene. Grunnen til at vi gjorde dette var for å være forberedt på mulige hindringer, og for hele tiden å ha en plan vi kunne forholde oss til ved eventuelle problemer. Vi tok også en vurdering over hvor stor sannsynlighet det var for at de forskjellige risikoene ville oppstå og hvor store konsekvenser de ville få. Konsekvensene er rangert fra 1 til 10, der en risiko med konsekvens 1 utgjør små problemer for prosjektgjennomføringen og 10 kan føre til store problemer. Vurderingen av både sannsynlighet og konsekvens er basert på et gjennomsnitt av alle gruppemedlemmenes meninger. Mulige risikoer Sannsynlighet (i prosent) Konsekvens Rangering (sann * kons) Tiltak Feilprioritering av tid 20.00% Holde interne tidsfrister / milepæler Sykdom 20.00% Spise sunt, mosjon, vitaminer, kjærlighet og omsorg Frafall av gruppemedlemmer Konflikter innad i gruppen Dårlig faglig kompetanse Mangel på kommunikasjon 1.00% Sosiale tiltak, bække hverandre opp 5.00% Kommunikasjon og forståelse 23.00% Lesing og oppgaveløsing 10.00% Ta initiativ og ansvar Tap av fokus 7.00% Da må vi inn i tenkeboksen Manglende evne til å finne kilder 3.00% Oversikt over hvor kildene befinner seg, og hvilke som er nødvendige Tap av arbeid 8.00% Backup Oppdragsgiver trekker seg 1.00% Holde arbeidsgiver underrettet om hvor vi befinner oss i prosjektet. God kommunikasjon. Tabell 1: Risikoanalyse 15

12 3.2 Hvordan har vi forholdt oss til den Vår gruppe har i denne omgangen heldigvis fått erfare at risikoanalysen ble mer grundig enn nødvendig. Vi har ikke hatt altfor mange hindringer underveis i forhold til analysen, som har begrenset muligheten til å få prosjektet i mål. Vi har riktignok hatt en del sykdom innad i gruppen, men det har ikke ført til nevneverdige hindringer i gjennomføringen. Det har muligens gjort oss enda mer målrettet og fokusert på arbeidsoppgavene. I tillegg har det oppstått en risiko, som vi ikke har vurdert i det hele tatt. Vi har satt feilprioritering som en mulig risiko, men dette ble ikke tilfelle for oss. I vår prosjektgjennomføring blir det mer aktuelt å si at tap av tid har vært en større hindring. Oppdragsgiveren vår ga oss tidlig beskjed om at vi måtte jobbe på en kopi av det eksisterende programmet, for at han ikke skulle tape noe av det som fungerte og all data han hadde samlet inn under tidligere eksperimenter. Vi fikk derfor tildelt en kopi av maskinen hans, men denne kopien fikk vi tildelt en måned senere enn planlagt på grunn av mangel på ip-adresser. I tillegg viste det seg at den opprinnelige maskinen var infisert, og dette problemet kom med videre på vår virtuelle maskin. Det gikk derfor ikke mange dagene før maskinen vår ble sperret, og tap av enda mer tid ble en trussel for oss. Vi måtte også bruke mye tid på å få programmet til å fungere igjen, og dette hadde vi ikke regnet som en av våre arbeidsoppgaver. På et tidspunkt ble det aktuelt å revurdere prosjektets mål, for vi ble usikre på om vi klarte å ta igjen den tiden vi tapte. 16

13 Utviklingsprosessen 1. Faser i prosjektet 1.1 Prosjektstart Prosjektgruppen kom i kontakt med oppdragsgiver, Reidar Kvadsheim, på slutten av året Vi var i utgangspunktet interessert i et helt annet prosjekt, der oppgaven besto i å utvikle en prototype av et system for læringsstøtte. I løpet av studiene har vi i faget Statistikk brukt et system, som automatisk har gitt tilbakemeldinger på innleveringsoppgaver. Siden vi allerede hadde jobbet med et system for læringsstøtte, så tenkte vi at det kunne være interessant å utvikle et liknende system. Prosjektet ble imidlertid trukket tilbake og trolig utsatt til en senere anledning. Da dette ble bestemt kom Reidar til oss med forslag om en annen oppgave. Han hadde et program, som han benyttet til å utføre psykologiske eksperimenter. Dette programmet hadde vært gitt som hovedprosjekt to ganger tidligere, men det fungerte ikke optimalt. Vi fikk derfor rapporten fra den siste gruppen slik at vi kunne sette oss inn i oppgaven og vurdere om vi ønsket å jobbe videre med programmet. For gruppen var denne oppgaven både spennende og utfordrende. Vi syntes den virket spennende fordi programmet faktisk skulle bli benyttet i praksis, og utfordrende fordi vi skulle ta opp arbeidet der noen andre slapp før oss. I tillegg ble det nødvendig med tilegning av kunnskaper innenfor områder der ingen av oss hadde mye erfaring. Dette gjaldt spesielt scripting i PHP (PHP Hypertext Preprocessor). 1.2 Forprosjekt Den første måneden av prosjektperioden ble benyttet til å få en bedre oversikt over hvilket arbeid vi sto ovenfor og bygge opp et grunnlag for prosjektgjennomføringen. Vi hadde tilgang til to rapporter fra tidligere prosjektgjennomføringer og to versjoner av programmet, som kunne hjelpe oss med å komme i gang. Da vi arbeidet med formuleringen av forprosjektsrapporten, trodde hele gruppen at FigureGame 2.0 var den versjonen som fungerte og som vi skulle jobbe videre med. Rapporten deres inneholdt også bilder av et forenklet 17

14 brukergrensesnitt, som oppdragsgiveren vår var veldig positivt innstilt til. Et av problemene fra FigureGame 1.0 var nettopp det at konfigurasjonssiden var lang og komplisert, og den andre prosjektgruppen kom med flere gode ideer for en forenklet side. Etter en stund viste det seg riktignok at dette programmet overhodet ikke fungerte og at vi ville bruke altfor mye tid på å forstå både tankegangen deres og programmet i sin helhet. I tillegg hadde vi problemer med å kjøre JSP-filene deres fra NetBeans, så vi fikk ikke sett på konfigureringsforslaget deres. Dermed valgte vi å tenke forenklet konfigurasjon, men med den første versjonen av programmet som utgangspunkt. Videre i denne perioden benyttet vi også mye av tiden til å opprette en plan, for hvordan vi skulle gjennomføre prosjektet. Noen av disse dokumentene består blant annet av prosjektavtalen mellom prosjektgruppen og oppdragsgiveren vår, risikoanalyse, fremdriftsplan og kravspesifikasjoner. Alle disse dokumentene er lagt med som vedlegg til denne rapporten. 1.3 Kompetansetilegning Vi har benyttet oss av flere metoder for å tilegne oss den kunnskapen som har vært nødvendig for å forstå programmet, hvordan det er bygd opp og hvilken hensikt det har. Reidar Kvadsheim har vært en nyttig kilde til informasjon om programmets funksjon i virkeligheten. Han ga oss, på et tidlig tidspunkt, en grundig innføring i hvordan spillet skal gjennomføres og hvordan det skal konfigureres. Han har også gitt oss innsikt i hvorfor han har tatt initiativ til å utvikle programmet, hva han ville oppnå med det og hvorfor det har vært et viktig ledd for forskningen om beslutningsprosesser. Videre har oppdragsgiver vært en nyttig kilde ved videre programmering. Siden det er han som skal administrere programmet i framtiden, har det vært viktig for oss å få tilbakemeldinger og synspunkter om hvordan utviklingen passer hans behov. Videre har den største jobbet på dette området vært å bli kjent med tankegangen til våre forgjengere, forstå hvordan de har bygd opp programmet og hvilke funksjoner alle filene har hatt. For å kunne gjøre dette har vi benyttet oss av både sluttrapporten deres og selve programkoden. Den tiden vi satte av til å lese kode og få forståelse for den, viste seg å være altfor kort. Det har ikke vært mulig å 18

15 forstå hele programmet på et par uker, men det har vært en prosess som har pågått underveis i hele prosjektgjennomføringen. Da vi påtok oss denne oppgaven, hadde heller ingen av oss kunnskaper innen verken PHP-scripting, XML eller funksjonen til et DOM-dokument. Dette er områder vi har fått forståelse for underveis ettersom vi har sett hvordan de fungerer for programmet. Det skal også sies at det ikke har vært en enkel prosess å bli kjent med programmet. Dokumentasjonen i den eksisterende koden og produktdokumentasjonen ga generelt for lite informasjon til at videreutviklingen av programmet kunne gå problemfritt. Dokumentasjon med hensyn på fremtidig videreutvikling har derfor blitt et viktig ledd blant våre oppgaver. 1.4 Implementasjon For å kunne implementere noen av de funksjonene som er oppgitt i kravspesifikasjonen, ble det først nødvendig å forstå hvordan systemet ble bygd opp av den første prosjektgruppen. Dette innebar blant annet å få en forståelse for systemarkitekturen, som er vist i figuren under. Figur 2: Systemarkitektur Figuren viser at en bruker er koblet til en webserver, som laster opp Java-appletet. Før dette skjer har administratoren konfigurert XML-filen slik at spillets oppsett er definert. Brukeren kjører et program som kontakter databasen etter hver fase i spillet Helt fra begynnelsen av prosessen har det vært klart ut i fra kravspesifikasjonen hvilke funksjoner vi skulle implementere i programmet. En del av forstudiet besto derfor av mye kodelesing for å få forståelse av hvordan alle filene hang sammen og hvor alle endringene måtte skje. 19

16 Mye av implementeringen har blitt utført i filene config.php og parser.java. Det ligger en fullstendig beskrivelse av alle filene vi har jobbet med i produktrapporten. 1.5 Testing Testing av programmet og koden har blitt utført kontinuerlig under hele prosessen. Hver eneste fullførte funksjon har blitt grundig testet, spesielt ved at vi har skrevet flere feilmeldinger i koden, ved å prøvekonfigurere og gjennomføre en spillerunde. Feilmeldingene har vist oss hvor de eventuelle problemene har oppstått. Den største programmeringsutfordringen vi har hatt i dette prosjektet har riktignok vært å utvide programmet fra fire undergrupper til 27. Denne algoritmen ble såpass stor at det ble nødvendig å ta den ut av programkoden og teste den for seg selv i Eclipse. Videre fikk vi muligheten til å samle en gruppe bestående av 20 studenter på en av skolens datalaber, for å gjennomføre en testrunde. Dette ga oss muligheten til å få oversikt over hvordan systemet oppførte seg ved større testgrupper, serverens håndtering av datatrafikk og kommunikasjonen til og fra databasen. Vi opplevde at alt dette fungerte tilfredsstillende. En mer utfyllende testrapport finnes lenger bak i dette dokumentet. 2. Utfordringer 2.1 Virtuelle maskiner Da vi begynte arbeidet med prosjektet i januar, var det meningen at vi skulle motta en kloning av oppdragsgivers maskin. Han ønsket naturligvis ikke at vi skulle jobbe med originalfilene. Vi ba derfor om å få tildelt en virtuell maskin med en kopi av Reidars maskin. På denne måten ville vi ha administrasjonsrettigheter på den maskinen vi jobbet på, og det ville heller ikke bli noen problemer med den fungerende programversjonen som Reidar hadde. Det var i utgangspunktet meningen at vi skulle få klonen like over nyttår, men vi fikk den ikke før i begynnelsen av februar. Vi fikk beskjed om at årsaken til dette var mangel på ip-adresser på skolens nettverk. Da vi omsider mottok den virtuelle maskinen, så viste det seg at den var infisert. Dette visste ikke gruppen noe om før den plutselig, uten forvarsel, ble tatt ned etter to ukers arbeid. Det viste seg at oppdragsgivers maskin var infisert og del av et 20

17 botnett, og dette problemet forplantet seg videre til vår kopi. Et botnett er et nettverk av datamaskiner, der disse er infisert av virus eller trojanere. I slutten av februar mottok vi derfor en tom virtuell maskin, og vi måtte kopiere alle filene fra de tidligere programversjonene over manuelt. Dette burde, i utgangspunktet, ikke være noe problem, men da vi skulle teste programmet, viste det seg at ingenting fungerte lenger. Vi visste heller ikke årsaken til dette, så vi sjekket om det var noe galt med databasen, vi installerte alle tenkelige biblioteker i tilfelle vi manglet noen og vi leste gjennom alle filene i programmet, for å se om noe hadde endret seg underveis i kopieringen. 2.2 Hvordan deklarere variable i php-filene? Et av hovedproblemene som oppsto da programmet ikke fungerte var tomme variable i alle php-filene. I disse filene er det en form som kaller på de nødvendige variablene. Funksjonen til en form på en nettside er at den tillater en bruker å oppgi data, som senere sendes videre til serveren for behandling. Problemet oppsto dermed i kallet på disse variablene. Det som skjedde var at idet de gjorde kall på seg selv, så mistet de verdiene sine, og dermed måtte alle deklareres på nytt og dette måtte gjøres i alle php-filene. Et eksempel på noen av variablene er: $shorttrack = $_POST[ shorttrack ]; $mediumtrack = $_POST[ mediumtrack ]; $longtrack = $_POST[ longtrack ]; Videre hadde vi flere problemer med de dynamiske variablene, der én variabel er satt sammen av tre varierende variable. I følgende for-løkke fra config.php har vi: for( $i = 0; $i < count(${$roundabout}); $i++ ){ for( $j = 0; $j < count(${$roundabout}[$i]->phase); $j++ ) der $roundabout skifter mellom training, treatment og test, mens $i og $j teller fra tallet 0 og oppover. Hovedproblemet for oss i denne sammenhengen var å finne ut av hvordan vi skulle forstå koden, slik at vi kunne deklarere en variabel som er satt sammen av flere andre dynamiske. Dette ble løst på følgende måte: ${$roundabout.$i. _phase.$j. _timefirst } = $_POST[$roundabout.$i. _phase.$j. _timefirst ]; 21

18 2.3 Problemer med databasen Etter hvert som vi begynte å få kontroll over problemene med alle php-filene, så viste det seg også at databasen ikke fungerte optimalt. Et av problemene besto blant annet av at programmets administrator ikke hadde muligheten til å hente ut data fra tidligere eksperimenter fra databasen. Dette skulle i utgangspunktet være mulig å gjøre fra siden: Figur 3: Henter data fra databasen På denne siden skal det være mulig for administratoren å taste inn en til/fra-dato, for å få all data fra databasen skrevet ut i et Excel-ark. Dette ga riktignok en feilmelding, som vi rettet på samme måte som alle de andre variablene i php-filen data.php. Når denne funksjonen fungerte igjen, så viste det seg at det ble problematisk å hente ut data fra større tidsintervaller. Grunnen til dette var at gruppen før oss ikke hadde tildelt scriptet noe spesifikt minne, så det fikk kun et standardminne på 8MB. Dette løste vi ved å tildele scriptet et minne på 100MB, slik at det ble mulig å hente ut data fra en periode på opp til et halvt år av gangen. Videre opplevde vi at spillet stoppet etter én runde. Selv om spillet var konfigurert slik at det skulle gjennomføres 15 runder, så skjedde ikke dette. Grunnen var at databasen kun lyttet på hva som skjedde lokalt på maskinen (localhost). For å få databasen til å kunne ta imot forespørsler fra appletet måtte vi derfor gjøre endringer i konfigurasjonssiden for mysql /etc/mysql/my.cnf der: bind-address = ble endret til bind-address =

19 Videre har vi også valgt å sette opp en ny database, som er tilpasset de endringene vi har gjort i programmet. Dette er nærmere forklart i produktrapporten. 3. Kvaliteten på prosjektet 3.1 Brukervennlighet Sett fra en testpersons side, så er brukervennligheten til programmet meget enkel. Dette var et av ønskene til oppdragsgiveren da han la fram sine tanker om spillets funksjonalitet for den første prosjektgruppen. Hensikten er at alle testpersonene skal ha alle mulige forutsetninger for å komme i mål uten komplikasjoner. Derfor skal også spillet være så enkelt som overhodet mulig. Konfigurasjonssiden, der administratoren av spillet skal lage et oppsett for et eksperiment, er derimot mye mer komplisert. Siden er lang og har ekstremt mange faktorer som kan stilles inn. Siden krever nøye planlegging og at administratoren har tungen rett i munnen. Som en følge av at spillet benyttes i psykologiske eksperimenter, er det helt kritisk at han vet hva han driver med når programmet konfigureres. Derfor er det laget en grundig brukerveiledning, som forklarer alle de konfigurerbare feltene i programmet. Dette er også delvis gjort etter ønske fra Reidar Kvadsheim, for det kan være lett å glemme hvordan alle faktorene henger sammen hvis det går lang tid mellom hvert eksperiment. Videre kan det nevnes at vi har, gjennom kontinuerlig testing av programmet, kommet fram til et sluttprodukt, som er meget robust. Det håndterer mye datatrafikk og fungere etter oppdragsgivers nåværende ønsker. 3.2 Teknologi Når det gjelder kvaliteten til prosjektet, så kan det nevnes også her at vår gruppe ikke har valgt hvilken teknologi vi skulle benytte oss av. Vi har valgt å jobbe videre med den teknologien som allerede eksisterte fra den første prosjektgruppen uten å ta en grundig vurdering av deres valg. Det er to grunner til dette: for det første fikk vi så mange utfordringer i prosjektgjennomføringen at det programmeringsarbeidet vi skulle begynt med i februar kom i gang først i april. Disse utfordringene var meget tidkrevende og er beskrevet over. Siden vi ble forsinket i arbeidet vårt, ble det ganske naturlig for oss å jobbe videre med det som allerede eksisterte framfor å starte helt på nytt ved å sette oss inn i annen og ukjent teknologi. 23

20 For det andre, så ser vi at ny teknologi kunne gitt oppdragsgiveren vår mye og krevende arbeid med å sette seg inn i programmet helt på nytt. I dag kjenner han godt til den teknologien som eksisterer og hvordan den fungerer, så vi så på dette som et viktig punkt for ikke å gjøre endringer på dette området. 24

21 Kravspesifikasjoner 1. Generelt Kravspesifikasjonen er utformet i samarbeid med oppdragsgiver, Reidar Kvadsheim, og skal være en beskrivelse på de kravene han har til spillet FigureGame 3.0. Siden Reidar ikke har lagt fram noen spesifikke detaljer over hvordan programmet skal fungere, er denne listen basert på ønsker til modifikasjon av tidligere versjoner. Utover dette fikk vi muligheten til å vurdere selv hvordan programmet skulle videreutvikles, hvilke verktøy vi skulle benytte oss av, hvilken plattform og arbeidsmetode vi skulle bruke og så videre. Den kravspesifikasjonen vi utformet er dermed som følger: Programmet skal ha minimum 3x3x3 = 27 undergrupper, men helst et antall k x m x n = N, som oppdragsgiver kan bestemme selv. En undergruppe er en konfigurerbar mal for hvordan spillet skal gjennomføres. Foreløpig finnes det kun to grupper med to undergrupper i spillet, altså fire undergrupper totalt. I løpet av et spill skal det vises tre figurer på skjermen til enhver tid. I programmet fins det et figurbibliotek som skal utvides. Vi skal også endre antallet figurer som brukes under en gjennomføring fra 6 til minimum 9. Oppdragsgiveren skal ha muligheten til å konfigurere dette antallet selv. Det fins fortsatt bare to varigheter på handlingene i et spill. Disse er long og short. Vi skal også lage en medium varighet for handlingene, men det bør helst være mulig å konfigurere et fritt antall. Endre oppsettet for hvordan et spill konfigureres. Oppdragsgiveren ønsker en mer automatisk metode, som overfører innstillingene fra en gruppe til en annen. Forbedring av dokumentasjon i programkoden. Vi skal lage en demo som kan vises før spillet starter. Denne demoen skal vise hvordan spillet fungerer og være mer forklarende enn dagens tekstforklaring. Spillet foregår i et relativt lite vindu. Vi skal derfor gjøre det mulig å endre på denne størrelsen slik at oppløsningen blir større. Siden denne listen ble basert på foreløpige ønsker, ble vi enige om at uforutsette situasjoner kunne gjøre det naturlig å komme med endringer til kravspesifikasjonene. 25

22 Vi ble også enige om at eventuelle endringer skulle gjøres i samarbeid mellom oppdragsgiver og prosjektgruppen. 2. Utfordringer På et tidspunkt i prosjektet trodde vi at det ville være nødvendig å reformulere både prosjektets mål og kravspesifikasjonen. På grunn av de utfordringene som oppsto underveis (se avsnittet om Utfordringer under kapittelet Utviklingsprosessen over), så trodde vi at det ville bli en umulig oppgave å oppfylle alle ønskene til oppdragsgiver. Vi brukte såpass mye tid på å få programmet til å fungere igjen etter at den virtuelle maskinen ble tatt ned, og vi fikk tildelt en tom maskin. Her oppsto en del utfordringer og det virket som om én feil forplantet seg videre fra fil til fil og videre til databasen. Dermed trodde vi på et tidspunkt at prosjektets mål måtte bli å få programmet til å fungere igjen, slik at Reidar kunne utføre eksperimentene sine. Programmet ville riktignok ha de samme begrensningene som tidligere, så dette var ikke en ønskelig situasjon for noen av partene. Vi ble derfor enige om at vi skulle jobbe videre med å få programmet til å fungere, og deretter ta for oss det vi hadde tid til fra en prioriteringsliste over oppdragsgiverens ønsker til funksjonalitet. Det endte med at vi rakk hele ønskelisten bortsett fra å lage en demo, som viser hvordan spillet skal gjennomføres. Denne demoen skulle i utgangspunktet erstatte dagens lange tekstforklaring. I tillegg måtte vi se bort ifra oppgaven med å endre størrelsen på spillevinduet, der det var meningen at vi skulle gjøre oppløsningen større. 3. Oppsummering Som en oppsummering på kravspesifikasjonen, så er vi godt fornøyde med at vi har klart å løse de største problemene til oppdragsgiveren; altså å øke antall undergrupper fra 4 til 27, forenkle konfigureringen, innføre en medium-lang spillebane, legge til flere figurer, samt forbedre all dokumentasjon for forenklet videreutvikling. Vi ser også at utfordringene vi har hatt underveis har lagt et stort lokk over utviklingen. Den tiden vi brukte på uforutsette problemer, skulle vi gjerne ha brukt på å jobbe videre utover kravspesifikasjonen. Vi skulle mer enn gjerne ha jobbet mer for å endre grafikken og å forbedre brukergrensesnittet for konfigureringen betraktelig. Selv om vi fikk forenklet dette noe, så kunne vi gjort mye mer på denne siden for at den skulle vært enda enklere, og for at oppdragsgiveren skulle kunne bruke enda mindre tid på å sette opp et spill. 26

23 Avslutning 1. Oppsummering For vår prosjektgruppe har denne prosessen vært ekstremt lærerik, noe frustrerende, men mest av alt interessant og morsom. Da vi startet med arbeidet i begynnelsen av januar var vi en gruppe med motiverte personer. Vi var spent på hvordan denne oppgaven skulle utvikle seg. I tillegg var det helt nytt for oss å være med på videreutviklingen av et program som faktisk benyttes i praksis som en del av forskning. Gjennom studiene har vi benyttet oss mye av Java som programmeringsspråk og vi har også fått en ganske god innføring i MySQL. PHP og XML derimot har ingen av oss hatt så mye om i løpet av studiet, så en av utfordringene for oss ble derfor å tilegne oss nok kunnskaper om disse for å forstå programmet. Vi har også lært at det kan være vanskeligere enn antatt å forstå hvordan andre utviklere før oss har tenkt og at videreutvikling av et eksisterende program kan være veldig utfordrende. Det skal også sies at vi ser nødvendigheten av god dokumentasjon både i rapporter og i selve programkoden. I perioder føler vi at dette arbeidet ikke har vært fullstedig fra de to tidligere gruppene, og det har vært en utfordring å forstå sammenhengen i programmet og tankegangen til våre forgjengere. Selv om vi har hatt en kravspesifikasjon å forholde oss til og selv om vi har fullført de fleste av disse oppgavene, så har vårt hovedarbeid ligget i å få programmet til å fungere. Vi har brukt enormt mye tid på å lese gjennom programkoden og oppdatere den til dagens standard. Dette gjelder spesielt alle php-filene der alle variablene måtte deklareres på nytt. I tillegg måtte vi sette opp en ny database for at den skulle samsvare med videreutviklingen i vår programkode 2. Hva kunne vi gjort annerledes? Det er alltid faktorer som kan gjøres annerledes i en prosjektprosess. Halvveis gjennom prosjektet kom vi til et veiskille, der det ble nødvendig for oss å foreta et valg. Belastningen med å få programmet til å fungere ble såpass stor og tidkrevende at vi måtte velge mellom å fortsette med dette eller å starte helt på nytt. I ettertid ser vi at det beste for oss trolig var å jobbe videre på den nåværende versjonen av programmet. Hadde vi derimot visst om alle komplikasjonene på forhånd, ville vi mest sannsynlig 27

24 valgt å skrive alt på nytt helt fra begynnelsen av. Siden vårt arbeidsvalg har ført til stor innsikt både i php-scripting og xml, så kan vi beskjedent anta at resultatet hadde blitt veldig annerledes hvis vi hadde skrevet all kode selv. Våre kunnskaper hadde muligens ikke strukket langt nok til å lage et like bra program, som det vi har i dag. 3. Produktets framtid Produktet vi leverer har stort potensial for videreutvikling og endringer og det er i grunn ingen begrensninger for hva som kan gjøres med det. Så lenge utviklere arbeider med programmet, vil det hele tiden være rom for nye ideer. Reidar Kvadsheim vil også trolig komme med flere ønsker til utvidet funksjonalitet etter at han har jobbet en stund med den nåværende programversjonen og blitt godt kjent med den. Vi har likevel gjort oss noen meninger om hvilke endringer som kan utføres i nær fremtid: Appletet kan videreutvikles med tiden slik at det blir mer moderne og mer morsomt å gjennomføre et spill. En del av dette innebærer også at figurbiblioteket kan utvides slik at det inneholder 3D-figurer i flere farger og figurer som er i bevegelse. Vi har arbeidet litt med å forenkle det brukergrensesnittet som er rettet mot administratoren av programmet. Dette innebærer blant annet å minimere scrollingen ved å legge deler av konfigurasjonssiden inn i minimeringsfunksjoner. Dette kan absolutt videreutvikles i fremtiden, slik at siden blir mer oversiktlig og brukervennlig. Databasen kan bygges opp på nytt slik at forholdene mellom tabellene blir mer oversiktlige og for å unngå redundans. I dag foregår dataoverføringen fra databasen til et excel-ark. Dette fører til et dokument som består av 4640 kolonner med data per person som gjennomfører spillet. Dette er ekstremt store mengder data, så i fremtiden bør det finnes en enklere måte å bearbeide disse på. Hvis det skal lages en ny versjon av programmet, så bør all koden skrives på nytt. Grunnen til dette er at den gamle koden er uoversiktlig, tungvindt og vanskelig å forstå. I tillegg kan det være et mål for fremtiden å få konfigurasjonssiden W3C-godkjent. En demo kan også gi bedre oversikt over spillereglene for fremtidige testpersoner. 28