Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Transkript

1 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Prosessdokumentasjon Høgskolen i Oslo Student: Martin Oppegaard Gruppe: Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting AS Kontaktpersoner: Vegard Hartmann Steffen Holthe

2

3 PROSJEKTNR Studieprogram: Ingeniørfag, Data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT I DATA HOVEDPROSJEKTETS TITTEL Open Exam System PROSJEKTDELTAKERE Martin Oppegaard (s129190) DATO 25. mai 2007 ANTALL SIDER / BILAG 61 INTERN VEILEDER Eva Vihovde OPPDRAGSGIVER Bekk Consulting AS KONTAKTPERSONER Vegard Hartmann Steffen Holthe SAMMENDRAG Open Exam System (OES) er et åpent system for å lage og utføre flervalgstester for å sertifisere ansatte internt i en bedrift. Systemet kan importere og eksportere testene til og fra formatet IMS QTI [IMS Question and Test Interoperability Specification], slik at de kan utveksles med andre systemer. OES er en webapplikasjon utviklet i Java med rammeverket Rife. Systemet har to roller administrator og kandidat. Administrator kan lage emner som testene og spørsmålene sorteres under, lage nye og endre gamle tester og spørsmål, og importere og eksportere tester. Spørsmålene lages før testen, og hvert spørsmål kan brukes i flere tester. Dette gjør systemet fleksibelt, og det minsker arbeidsoppgaven til administrator. OES har respons-betingelser som kandidatens svar sjekkes mot for å bli behandlet. Det kan være en betingelse for hvert svaralternativ, noe som gjør spørsmålene veldig fleksible. Fleksibilitet går også igjen når det kommer til tilfeldig rokkering av svaralternativer. Testlager kan eksplisitt velge om hvert svaralternativ skal vises i tilfeldig rekkefølge til eller ikke. Spørsmålene kan også vises i tilfeldig rekkefølge. Dette er veldig bra hvis flere kandidater sitter i nærheten av hverandre med mulighet for kikking, ved at kandidatene får en «unik» eksamen. Nøkkelord er flervalgstest, Rife, QTI, fleksibilitet.

4 1 Sammendrag Open Exam System ble gjennomført som et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniør-utdanning. Hovedprosjektet er kronen på verket av tre års utdannelse, hvor studenten skal nyttiggjøre seg av all kunnskapen han har tilegnet seg i løpet av disse tre år, og forberede studenten på arbeidslivet. Open Exam System er et system for å sertifisere de ansatte inad i en bedrift. Systemet kan lage flervalgstester, lar kandidaten ta testen, og kan importere og eksportere tester til formatet IMS QTI. Tidlig i prosjektperioden lagde gruppen en arbeidsplan som var veldig nyttig da gruppen gikk i oppløsning ved at jeg ble presset til å arbeide raskt for å bli ferdig. Oppløsningen av gruppen skjedde offisielt ganske sent i implementasjonsfasen, men siden den fungerte dårlig i hele denne fasen førte det ikke med seg noen store ulemper for meg, siden jeg hadde jobbet for to i hele denne perioden. Det ble tidlig lagt ned mye arbeid i å definere kravene som brukerhistorier med akseptansekrav. Dette var en veldig god strategi, for jeg hadde da konkrete mål å jobbe mot med klare «mål-streker» som sa når funksjonaliteten var ferdig. Systemdokumentasjonen beskriver prosessen prosjektet gikk gjennom fra gruppedannelse og valg av prosjekt, til det ferdige resultatet. Resultatet av prosjektet er et system som har oppfylt kravene oppdragsgiver stilte, og har et stort potensiale for videre utvikling ettersom mye arbeid ble lagt ned i utformingen av databasen hjertet i systemet. Både oppdragsgiver og jeg er fornøyd med resultatet. iv

5 2 Forord Forordet er en introduksjon til dokumentet som gir leseren en ramme å forholde seg til. 2.1 Hensikt Hensikten med prosessdokumentasjonen er å gi en beskrivelse av prosessen som har ført frem til prosjektets endelige resultat. Jeg vil ta for meg utviklingsmetode, alle fasene i prosjektutførelsen fra gruppedannelse til det ferdige resultatet, problemer og hvordan de er løst og hvordan det har vært å arbeide alene. 2.2 Lesere Prosessdokumentasjonen er hovedsakelig skrevet for sensor og prosjektets veileder, men de ansatte hos BEKK vil også kunne ha nytte av dokumentet, spesielt kapittelet om problemer og hvordan de er løst. Dokumentet kan også være nyttig lesning for studenter eller andre som skal utføre et liknende prosjekt. Det er forbeholdt at leseren har kunnskaper om Java og webapplikasjoner. 2.3 Organisering av dokumentet For at leseren skal få best mulig inntrykk av resultatet, anbefales det det at dette dokumentet blir lest i sammenheng med brukermanualen, kravspesifikasjonen og produktdokumentasjonen. Dokumentet starter med et sammendrag av prosjektet, etterfulgt av innledningen som beskriver bedriften og situasjonen som førte til at bedriften ønsket dette prosjektet, samt prosjektets mål og rammebetingelser. Neste del gir leseren en introduksjon til systemet, med en overordnet beskrivelse av hva systemet gjør, supplert med skjermbilder. Deretter kommer jeg inn på planleggingen av prosjektet, og hvordan jeg har jobbet. Til slutt går jeg inn på implementasjonsfasen, hvordan gruppen fungerte og til slutt spesielle problemer jeg har hatt, og hvordan disse ble løst. Som avslutning ser jeg på hvordan resultatet avviker med kravspesifikasjonen, og prosjektet oppsummeres sammen med en konklusjon. Bakerst i dokumentet er det tillegg, som består av prosjektdagboken med ukentlige statusrapporter, detaljert subversion-logg som supplement til dagboken, og til slutt en ordliste. Prosessdokumentasjonen er optimalisert for papirutskrift. v

6

7 3 Innholdsfortegnelse 1 Sammendrag...iv 2 Forord...v 2.1 Hensikt...v 2.2 Lesere...v 2.3 Organisering av dokumentet...v 3 Innholdsfortegnelse Innledning Om bedriften Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Beskrivelse av systemet Administrator Kandidater Planlegging og arbeidsmetode Gruppeopprettelse og prosjektvalg Forprosjekt Lære å bruke utviklingsmiljøet Arbeide med subversion Prosjektdagbok Utviklingsprosessen Arbeide som en gruppe Arbeide alene Implementasjon Database Elementer Testing med JUnit Utfordringer og løsninger Database Skrive ut spørsmål og svaralternativer Ta test Lage spørsmål Beregne resultat Import og eksport Forskjell mellom produkt og kravspesifikasjon Avslutning Oppsummering Konklusjon...19 Appendiks...20 A Skjermbilder...20 B Prosjektdagbok med statusrapporter

8 C Subversion-log

9 4 Innledning Dette kapittelet omhandler bedriften, dagens situasjon som har ført frem til ønsket om dette systemet, og avslutter med mål og rammebetingelser for prosjektet. 4.1 Om bedriften BEKK er et norsk konsulentselskap som leverer utviklings- og rådgivningstjenester innenfor teknologi, ledelse og brukerkvalitet/design. Disse områdene dekker tjenester som management consulting, utvikling og integrasjon, kundehåndteringssystemer, portal- og selvbetjeningsløsninger, og applikasjonsforvaltning. Blant BEKKs teknologipartnere står selskaper som IMB, Microsoft og Oracle. Bekk har kundeforhold med store norske konsern. BBS, DnB NOR, Statoil og Telenor er eksempler. Selskapet har over 150 ansatte, solid økonomi og Norges fremste virksomheter som oppdragsgivere. Bekk ble etablert i 2000, er et av landets raskest voksende bedrifter, og har hatt overskudd i alle kvartaler i selskapets historie. Årsomsetningen er på ca. 175 millioner NOK. 4.2 Dagens situasjon BEKK ønsker seg et system for å kunne teste sine egne konsulenter i kunnskap som det ellers ikke finnes sertifiseringer for. På den måten vil medarbeidere kunne dokumentere for firmaet at de innehar en bestemt kompetanse. Det finnes enkelte kommersielle produkter på markedet, men ingen enkle open source systemer. BEKK er opptatt av open source, og ønsker at systemet skal være fritt tilgjengelig etter endt oppdrag. 4.3 Mål og rammebetingelser Mål Systemet er utviklet som et Open Source-prosjekt. Det vil si at systemet ikke er avhengig av lukket programvare for å kunne kjøre, og skulle så godt det lar seg gjøre bli utviklet med fri programvare. For informasjon om fri programvare (GNU [Gnu is Not Unix] sin definisjon) henviser jeg til Gnu.org/philosophy 1 og The Free Software Definition. 2 BEKK sine krav for prosjektet er at det skal kunne lage flervalgstester, utføre testene, ta vare på resultatene, og kunne importere og eksportere tester til og fra formatet IMS QTI. BEKK vil også at systemet skal kunne lage statistikk over hvem som har tatt tester og resultatet de fikk. Hovedfunksjonaliteten er at det skal være mulig å lage, utføre, og ta vare på resultater fra flervalgstester, importere og eksportere tester til/fra formatet IMS-QTI, samt vise statistikk over resultater med hensyn på enkelttester og testtakere. Systemet er lagt opp slik at det med enkelthet kan utvikles videre av andre i fremtiden

10 4.3.2 Rammebetingelser Brukergrensesnittet skal være tilgjengelig via en nettleser. Det er ikke vektlagt at det skal være «fancy,» men informasjonen skal presenteres på en oversiktlig måte. BEKK benytter seg av Testdrevet Utvikling en agil utviklingsmetode, så det er ønskelig at dette er metoden prosjektet skal utvikles med. Til slutt er det et krav om at systemets krav skal skrives som brukerhistorier med akseptansekriterier. Se kravspesifikasjonen for detaljert beskrivelse av dette. 5 Beskrivelse av systemet I dette kapittelet gir jeg en overordnet beskrivelse av systemet og dets funksjonalitet. For en mer detaljert beskrivelse henvender jeg leseren til brukerveiledningen og kravspesifikasjonen. Jeg har tatt med dette kapittelet så leseren kan få en bedre forståelse av arbeidet som ligger bak, ved å se skjermbilder av det ferdige resultatet. Systemet er en webapplikasjon som arbeider mot en database. Det har to roller: Administrator og Kandidat. Dette kapittelet er derfor delt i to delkapitler ett for hver av rollene. Illustrasjon 5.1: Hendelsesdiagram 4

11 Hendelsesdiagrammet viser programmets flyt, sett fra brukerens perspektiv. Eksempel: for å endre en test må du først logge inn og velge testen fra testlisten. Illustrasjon 5.2: Forside Illustrasjon 5.2 viser den første siden du møter når du besøker siden. 5.1 Administrator Administrator kan 1. Opprette og endre emner som spørsmål og tester organiseres under. Se illustrasjon for skjermbilde av siden som behandler emner. 5

12 2. Lage og endre spørsmål. Et spørsmål består av Tittel. Beskrivelse. Spørsmål. Maks fem svaralternativer. Illustrasjon 5.1.1: Skjermbilde av subjecteditor Innstillinger for shuffle, som er svaralternativer i tilfeldig rekkefølge. Poeng for riktig svar, galt svar, ubesvart og eventuelt pass. Se illustrasjon for skjermbilde av testeditoren. I nedrykkslisten subject velger du emnet spørsmålet skal listes under. Alle emnene som ligger i databasen blir lagt i listen av systemet. I avskryssningsboken rett under spørsmålet, shuffle, velger du om svaralternativene til spørsmålet skal være i tilfeldig rekkefølge eller ikke. Dette er «hovedbyteren» til spørsmålet, og må være på for at de øvrige shuffle-boksene skal ha noen effekt. Disse må krysses av for hvert svaralternativ som skal være i tilfeldig rekkefølge. Svaralternativene som ikke blir avkrysset blir plassert til slutt. Avkryssningsboksen pass/skip velger om svaralternativ E skal være «vet ikke,» og gi et eget resultat, eller ikke. Til slutt velges hvilke poeng til de forskjellige valgene kandidaten har. 6

13 Illustrasjon 5.1.2: Skjermbilde av spørsmålseditoren 7

14 3. Opprette og endre tester: Illustrasjon 5.1.3: Testeditor med spørsmål Tittel og beskrivelse. Tiden kandidaten har på å fullføre, eller ikke tid i det hele tatt. Maks poengsum. Hvor mange forsøk kandidaten har. Ett eller uendelig mange. Overstyre spørsmålenes shuffle-verdier. Spørsmålene i tilfeldig rekkefølge eller ikke. 8

15 Aktivere eller deaktivere testen. Legge til og fjerne spørsmål. Skjermbilde viser testeditoren som viser en test med et spørsmål. Skjermbilde viser siden hvor man legger spørsmål til en test. 4. Eksportere tester til QTI. 5. Importere tester fra QTI. Ved å skrive en test for hånd og importere den, kan mer detaljerte/avanserte tester enn spørsmålseditoren kan lage lages. 5.2 Kandidater Kandidater kan 1. Ta eksamen. Illustrasjon viser det første skjermbilde kandidaten møter når han logger inn. Illustrasjonene og viser skjermbilder av en pågående eksamen og når den ble levert inn. «Open Exam System» i illustrasjon er testens tittel. Illustrasjon 5.1.4: Legger spørsmål til testen Illustrasjon 5.2.1: Kandidatens første skjermbilde 9

16 Illustrasjon 5.2.2: Startet eksamen Illustrasjon 5.2.3: Besvart eksamen 10

17 6 Planlegging og arbeidsmetode Dette kapittelet omhandler gruppens opprettelse og valg av prosjekt frem til 6.1 Gruppeopprettelse og prosjektvalg I god tid før prosjektet måtte være bestemt hadde jeg og Ole bestem at vi skulle gjøre hovedprosjektet sammen. Da dagen for første leveranse kom hadde vi ikke bestemt oss for et prosjekt enda, men vi hadde noen tanker om hva vi kunne tenke oss å jobbe med. Ole hadde lyst til å lage et flervalgstestprogram, men vi ventet med å kontakte noen firmaer til det var kommet inn flere prosjektforslag til HiO. På dette tidspunktet var vi i kontakt med og vurderte å ta med et tredje gruppemedlem, men vi kom frem til at to personer er passe. Det kom flere prosjektforslag etter hvert, og vi tok kontakt med to selskaper som førte til et møte med kontaktpersonene for hvert prosjekt. Møtene førte til at vi bestemte oss for å gå for BEKK sitt prosjekt. 6.2 Forprosjekt Vi hadde stor frihet til å sette krav og funksjonalitet utover kravene til BEKK. I tillegg til kravene som allerede var bestemt ble vi enige om at systemet skal ha to roller - testtaker og testlager -, en test skal være tidsstyrt, og man får kun ett forsøk. Det første vi gjorde var å finne på et navn til systemet. Blant forslagene var OESIC - Open Exam System for Internal Certification, som summerer opp greit hva systemet er for, men er litt langt. Etter konsultasjon med Vegard gikk vi til slutt for navnet Open Exam System. Den største jobben frem til innleveringen av forprosjektrapporten var å spesifisere resten av kravene til systemet. De skulle skrives på formen Som <rolle> Skal jeg kunne <krav> Slik at <forretningsverdi> Dette er en fin måte å skrive krav på. En negativ side er at det er litt slitsomt og tar tid å skrive, men oversikten man får etterpå gjør opp for det. Videre spesifiserte vi akseptansekrav for kravene. Akseptansekrav gjør det enkelt å se om et krav er ferdig eller ikke. Akseptansekrav skrives på formen Gitt av jeg er en <rolle> som <har utført aktivitet> Når jeg <utfører aktivitet> Så skal <resultat> Fordelen med akseptansekrav er at det er lett å se når et krav er ferdig, så man kan komme seg videre til neste punkt. En annen fordel er at både utvikler og kunde vet med sikkerhet hva som skal gjøres og om det er ferdig eller ikke. BEKK opprettet en wiki til oss som ble mye brukt i forprosjektperioden Der skrev vi kravspesifikasjonen og lastet opp de første versjonene av databasemodellen og arkitekturdiagrammer. På samme tidspunkt som wikien ble opprettet fikk vi også et Subversion-repository på serveren til BEKK. Versjonskontrollverktøy er ekstremt nyttig i systemutvikling, uavhengig av antall utviklere. Ikke bare samler man all koden på et sentralt sted, 11

18 men flere utviklere kan jobbe på samme fil. Hvis man skal presentere implementerte krav til kunden i løpet av utviklingen kan man lage en «branche,» så man er sikker på at man har en kopi som virker samtidig som man fortsetter å skrive på «current.» Det er også lett å gå tilbake til tidligere versjoner av koden hvis det er nødvendig. Teknologi er et viktig valg som får konsekvenser for prosjektet og prosjektgjennomføringen. Det ble veldig tidlig fastslått at det var Java vi skulle bruke. Java er mye brukt, noe som vil gjøre prosjektet mer attraktivt å videreutvikle etterpå. Videre var det nytt for oss begge å bruke et rammeverk, så det var en utfordring. Vi kom frem til å bruke følge utviklingsmiljø. IDE: Eclipse Plugin-er til Eclipse: Tomcatplugin, Sublicpse Rammeverk: Rife Applikasjonsserver: Tomcat Automatisere byggeprosessen: Ant Testrammeverk: JUnit Database: PostgreSQL Eclipse er et bra IDE med mange brukere. Det finnes også mange plugin-er til Eclipse, og vi brukte noen av disse hyppig. 6.3 Lære å bruke utviklingsmiljøet Det var en prøvelse å komme i gang med Eclipse-Rife-Tomcat. Jeg har aldri brukt Java til webprogrammering før, så det tok en stund før jeg fant ut av hvilke kataloger som brukes til hva osv. Jeg brukte flere forsøk på å laget en katalogstruktur som kunne brukes, men det største problemet var å få tomcat til å kjøre. Rife har ferdige eksempler som jeg fikk til å virke uten problemer, men jeg fikk det ikke til å samarbeide med Eclipse. Jeg prøvde flere metoder, blant annet å kopieer hele Tomcat-installasjonen til en underkatalog i prosjektet slik at prosjektet kunne bli kjørt på «vanlig» måte, men med Tomcat. Det var ikke vellykket, og det var ikke før Ole fant en plugin til Eclipse Tomcatplugin at jeg kom skikkelig i gang. Tomcatplugin lar Eclipse starte og stoppe Tomcat, og gjør at prosjektene du har åpnet i Eclipse blir lastet inn. 6.4 Arbeide med subversion Subversion har vært veldig nyttig å bruke, selv om Ole aldri sjekket inn noe kode. Med subversion har jeg sluppet å tenke på backup, da alle filene lagres hos BEKK (og BEKK helt sikkert har backuprutiner), og jeg har fått jobbet med prosjektet på flere datamaskiner. Jeg har brukt en plugin til Eclipse kalt Subclipse, som lar utvikleren bruke subversion direkte i Eclipse. Dette gjør at subversion aldri er i veien når jeg jobber, og det er veldig enkelt å hente oppdateringer og å laste opp endringene jeg har gjort. 6.5 Prosjektdagbok Eva anbefalte oss å føre en prosjektdagbok gjennom hele prosjektet. Dessverre gikk 12

19 den litt i glemmeboken, og er derfor ikke så fullstendig som den kunne ha blitt. Midt i prosjektperioden førte vi opp alt av betydning som hadde skjedd til da, og utover førte jeg noen punkter, men da det ble mer og mer klart at Ole ikke ville fullføre stoppet jeg med dagboken. I stedet for dagbok har jeg sendt ukentlige statusrapporter til Steffen og Vegard, og vil supplere dagboken med disse. I tillegg til dagboken og statusrapportene legger jeg ved subversion-loggen, slik at det kommer bedre frem hvor mye som er gjort. Denne loggen viser alle datoer kode ble sjekket inn, pluss en melding om hva som er gjort. 7 Utviklingsprosessen Dette kapittelet handler om samarbeidet i gruppen og hvordan det var å arbeide alene. Dette inkluderer hvordan arbeidet med implementasjonen av systemet har vært, spesielle problemer jeg har hatt og hvordan jeg løste de. 7.1 Arbeide som en gruppe Fra gruppedannelsen og frem til implementasjonen skulle begynne fungerte gruppen bra. Vi kommuniserte via MSN, og diskuterte hvordan problemer skulle løses. Ole hadde erfaring med Java og webprogrammering fra før, og var den som hadde mest styring på hva som måtte gjøres for å komme i gang. Siden Ole fra begynnelsen hadde tenkt på å lage et system for flervalgstester hadde han mange ideér om hvilke funksjoner og roller systemet burde ha. Da vi skulle begynne med å implementere kravene fikk Ole problemer med pc-en sin, og fra det punktet ble han hengende mer og mer etter. Etter hvert ble han også helt borte, og det var ganske frustrerende å ikke vite hva som skjedde, spesielt ettersom han heller ikke sjekket inn kode. I begynnelsen av april tok jeg kontakt med Eva, og vi (Eva, Ole og jeg) hadde et møte hvor vi diskuterte om Ole skulle fortsette eller ikke. Vi ble enige om at det fortsatt var mulig for han å bidra med både kode og dokumentasjon hvis han sto på skikkelig frem til slutten. Dessverre ble det ikke mer enn ord, så etter påske tok jeg på meg ansvaret for å ferdigstille prosjektet alene. Det var en lettelse å endelig få litt «stabilitet,» og vite hva jeg kunne forvente, selv om jeg helst ville hatt et gruppemedlem til. 7.2 Arbeide alene Det har vært mye å gjøre alene, og gjennom hele implementasjonsfasen har jeg jobbet for to. Det verste med å være alene var at jeg ikke hadde noen som kunne se over koden, slik at jeg måtte bruker mere tid på å oppdage og rette opp dårlige algoritmer og stygg kode. Dette slo ut i designet av databasen, hvor jeg tok noen dårlige valg og ikke leste skikkelig hva som sto på skjermen slik at modellen ble feil. Databasemodellen ble imidlertid rettet uten store komplikasjoner. I tillegg til å mangle en å diskutere koden med, var det å måtte skrive all dokumentasjonen selv ikke noe jeg så frem til. Da det ble klart at Ole ikke ville fortsette fjernet BEKK og jeg noen av de minst viktige kravene slik at jeg kunne bli ferdig. 13

20 7.3 Implementasjon Database Det første steget i implementeringsfasen var å lage en databasemodell. Jeg tenkte at det første som må implementeres er importering og eksportering av QTI-filer, for da blir det lett å legge inn testdata i databasen, og fokus kan så rettes mot selve hoveddelen av et flervalgstestsystem; å kunne ta en test. Ettersom utviklingen gikk ble de gjort små og store endringer på modellen. Dette pågikk gjennom hele implementasjonsfasen Elementer Hver side i systemet er et element som kommuniserer med databasen og gir data til mal-motoren (template engine). Elementet kan også generere skjema tomt eller med data fra en bønne -, og motta data fra skjemaet etterpå. Etter at første utkast til databasemodellen var ferdig, startet jeg å skrive elementene. Det var elementet for å importere en test jeg startet på først. Da jeg hadde funnet ut hvordan man laster opp en xml-fil og parser den (en enkelt xml-fil fra en tutorial), ble det slik at Ole skulle fortsette og gjøre det ferdig, og jeg begynte på eksportelementet. Disse to elementene jobber tett mot databasen, så jeg gjorde ikke eksport-elementet helt ferdig før jeg gikk videre, ettersom det var noen deler av databasemodellen som jeg ikke hadde noen klar løsning på. I denne perioden av utviklingen var jeg ikke helt komfortabel med Rife, og mye tid ble brukt til å slå opp i dokumentasjon. BEKK ville gjerne ha implementert import av QTI-filer, så det endte med at jeg måtte gjøre ferdig det helt mot slutten Testing med JUnit BEKK ønsket at prosjektet skulle utvikles med den smidige utviklingsmetoden Testdrevet Utvikling. Ved smidig utvikling jobbes det i korte iterasjoner, og ved iterasjonslutt skal en del være ferdig. Komponenter skal også være fullstendig ferdige før man går over til neste. I Testdrevet Utvikling lager man klassens tester før man lager selve klassen, og så mye som mulig skal ha Junit-tester. Dette gikk dessverre ikke helt som planlagt. For det første utviklet jeg ikke veldig smidig, og for det andre laget jeg ikke nok JUnit-tester. Da Ole fikk pc-problemer glemte jeg alt som het smidighet, og jobbet raskt for at vi ikke skulle henge for mye etter skjemaet. Det førte til at f.eks eksportøren ikke ble fullstendig ferdig før helt til slutt. Jeg tenkte at det var bedre å bli ferdig med så mye som mulig i stedet for å knote med småting. Når det kommer til JUnit startet jeg med å lage tester for backend-klassene og for å hente data fra databasen. Det viste seg etterhvert at Rife har et eget system for å teste alt mulig rart med JUnit. Man kan teste alt fra at variabler har riktig verdi til å simulere klikking på lenker og teste at man kommer til riktig side. Da jeg ble klar over dette vurderte jeg situasjonen slik at det ikke ville være nok tid til å sette seg inn i det. 14

21 7.4 Utfordringer og løsninger I dette kapittelet går jeg inn på utfordringer og hvordan de ble løst Database Den første utfordringen, og forsåvidt den største, ettersom hele systemet hviler på databasen, var å modellere den. Siden systemet skal kunne eksportere og importere tester i formatet QTI, var det naturlig å modellere databasen etter spesifikasjonen til QTI. Jeg valgte versjon 1.2 Lite. I ettertid kan man diskutere hvorvidt det å modellere en database etter et filformat er det beste, men da QTI har all funksjonalitet prosjektet skal ha var det til stor hjelp å ha en godt utviklet modell å se på. Da tiden kom for å implementere de forskjellige kravene så jeg for alvor nytten av denne strategien. Den beste egenskapen til Open Exam System er at databasen har store muligheter for å lage «avanserte» tester, og delsystemet for å ta en test er skrevet slik at disse mulighetene kan bli tatt i bruk med en gang. Det som ved første øyekast er et system som begrenser seg til tester med 5 svaralternativer osv, kan gjøre mye mer hvis du ser under overflaten. Det er nemlig grensesnittet for å lage spørsmål som er begrensningen. Jeg valgte å gjøre det slik fordi tiden begynte å bli knapp. Hvis du lager en test manuelt i QTI, og importerer den, kan du lage avanserte tester. Noen eksempler på dette er ubegrensede svaralternativer som kan grupperes. Disse gruppene kan da ha forskjellige poeng-startverdier. Spørsmåls-editoren lager én gruppen med poeng-startverdi lik null. Videre kan hvert spørsmål ha en egen response condition, slik at hvert spørsmål kan gi forskjellig score. For flere eksempler på utvidet funksjonalitet og forslag til videre utvikling henvender jeg leseren til produktdokumentasjonen Skrive ut spørsmål og svaralternativer Den neste utfordringen var å finne ut hvordan spørsmål og svar kan skrives ut og være i en tilfeldig rekkefølge (som bestemmes av diverse attributter i databasen). Det letteste hadde vært å skrive ut spørsmålene med tilhørende svaralternativer etter hverandre på én side. For å få tilfeldig rekkefølge kunne spørsmålene bli hentet i forveien og lagt i en liste, som kunne blitt stokket om, eller lagret midlertidig i databasen. Det var allerede bestemt at spørsmålene skulle bli skrevet ut på hver sin side, så det gikk ikke å gå for den enkleste løsningen. Et forslag til videre utvikling er å kunne velge om spørsmålene skal være på samme side, eller være én pr. side. Som følge av løsningen på dette problemet er det ikke mye kode som skal til for å få til dette. Min løsning ble å lage egne klasser (struct-klassene se produktdokumentasjonen) som holder spørsmålene og svaralternativene, samt deres id-er, og lage en liste med den «øverste» av disse klassene, slik at det ble en datastruktur. Denne listen har en liste med svaralternativer lenger nede i hierarkiet, og begge blir stokket om hvis testen og spørsmålene sier at spørsmålene og/eller svaralternativene skal være i tilfeldig rekkefølge. Når det kommer til selve presentasjonen av et spørsmål skjer dette i en løkke, som ved hjelp av Continuations (se produktdokumentasjonen) går helt til brukeren leverer inn testen. Hvilket spørsmål som skal vises bestemmes av en teller som oppdateres når brukeren klikker på knappene for frem og tilbake. Telleren blir oppdatert slik at 15

22 spørsmålene blir presentert i en «sirkel» hvis man velger spørsmål samme vei, flere ganger enn testen har spørsmål. Med andre ord vises første spørsmål igjen hvis man er på siste spørsmål og går til «neste spørsmål.» Siden dette elementet bruker continuations vil alle variable, inkludert datastrukturen med spørsmålene, lagres i minnet når programmet kommer til pause-instruksjonen. Dette gjør at spørsmålene og svaralternativene holder rekkefølgen gjennom hele eksamen, og det er ikke nødvendig å lagre noe midlertidig til databasen Ta test Da jeg var kommet halvveis med elementet som skriver ut spørsmålene slo det meg at en eksamen ikke bare er å skrive ut masse spørsmål, men den må også ha en start og en slutt. Jeg delte problemet opp i tre mindre problemer: starte eksamen; vise spørsmål; avslutte eksamen. Det er programmeringsteknisk ikke nødvendig ha en slik oppdeling, men det er bra for å vedlikeholde og videreutvikle systemet. StartExam er elementet som starter en eksamen. Det vil si at det blir satt inn en ny rad i tabellen exam, og den gjelder, dvs. at eksamenen pågår, helt til attributtet for poengsum får en verdi. I praksis gjelder en eksamen til brukeren leverer den inn, eller systemet leverer den inn automatisk hvis brukeren bruker for lang tid. Det går ikke å fortsette på en eksamen etter at nettleseren lukkes, men det er ingenting som gjør at det ikke kan implementeres i fremtiden. Når eksamen blir innlevert sørger elementet HandinExam for at databasen blir oppdatert med tiden brukeren brukte, og poengsummen han fikk. Dette blir også skrevet ut til brukeren. Hvis han har brukt for lang tid vil han få beskjed om det Lage spørsmål Da turen kom til test-editoren måtte jeg bestemme meg for hvor avanserte spørsmål den skulle kunne lage. Et av kravene jeg lagde sa at spørsmål skulle ha et fast antall svaralternativer, slik at oppgaven ikke skulle bli for stor. Jeg vurderte fem som et bra nummer. Da kan man ha fire svaralternativer og ett alternativ for «vet ikke.» Jeg valgte så fire respons-betingelser så brukeren får stor frihet til å bestemme utslagene til kandidatens handlinger. Spørsmålet kan gi poeng for riktig svar, galt svar, ubesvart og «vet ikke.» Brukeren kan også velge om det siste svaralternativet skal være «vet ikke,» med tilhørende responsbehandling, eller om det skal være et vanlig svaralternativ. Siden et spørsmål består av data fra mange forskjellige tabeller laget jeg en egen bønne for skjemaet. Dette objektet holder all data fra skjemaet når brukeren lagrer spørsmålet. En egen transaksjonsklasse brukes for å sette dataene inn i databasen i riktige tabeller Beregne resultat Jeg brukte et par forsøk på å få poengberegningsalgoritmen til å virke. Jeg laget tester som passerte, men så viste det seg at jeg ikke hadde lagt inn god nok data i databasen å teste med. Løsningen ble å gå gjennom algoritmen, og jeg fant fort ut at logikken var feil. Ettersom et en resprocessing (spørsmåls-editoren bruker kun én) (du kan se på resprocessing som en gruppe respons-betingelser. Se siste avsnitt i kapittel 7.4.1) kan ha flere tester som tester et svaralternativ eksplisitt, må alle respons-betingelsene sorteres før de kan brukes. Hvis ikke kan situasjoner som dette skje: Tenk deg at du svarer «vet ikke» på et spørsmål, noe som skal gi la oss si 0 poeng. Respons-testene er ikke sortert, så testen som tester at IKKE riktig svar er 16

23 svar kommer før testen som tester om «vet ikke» er svart. Resultatet blir at du får helt gal poengsum. For detaljer rundt algoritmen og hvordan resultat-testene sorteres henvendes leseren til produktdokumentasjonen. Det tok ikke lang tid å forbedre algoritmen, men det viser at man må ha hodet på rett sted når man utvikler algoritmer. Denne feilen kunne også lett ha vært unngått hvis jeg hadde hatt en partner Import og eksport Elementene jeg skriver om i dette kapittelet er xml/qti-elementer. Eksportøren kaller en metode som lager et qti-element, for deretter å kalle en metode som lager et nytt qti-element ett trinn lenger ned i hierarkiet. Den største utfordringen med eksportøren var å lage material-elementer. Material-elementer holder tekst. Dette er spørsmålstekst, svaralternativstekst osv. Material kan holde mer enn bare tekst (OES støtter bare tekst) og er bygget opp slik at material bare en et hovedelement som holder andre elementer. OES støtter mattext og matemtext, som er vanlig og uthevet tekst. Utfordringen var å lage riktige mat*text-elementer av en tekststreng på formatet «Dette er [em]uthevet[/em] tekst.» Siden jeg bruker DOM for å lage xml gikk det ikke å bare bytte ut [em] med <matemtext> som vanlig tekst med regexp, men jeg måtte lage en metode som splitter teksten på riktig bbkode ([em] eller [/em]) og lager riktig xml-element. Resultatet ble en rekursiv metode som splitter [em] og [/em] annenhver gang. Metoden split i klassen String får argumenter slik at den returnerer en array med to elementer: en med teksten som det skal lages et nytt xml-element med, og en med resten av teksten. Metoden kaller så seg selv med den resterende teksten, som blir splittet på neste bbkode. Den største utfordringen med importøren var å rekke å bli ferdig med den. Jeg var ikke veldig fornøyd med å måtte gjøre denne delen når Ole hadde drivet med den helt fra start. Han hadde ikke laget noe kode jeg kunne bruke, men det var ikke spesielt vanskelig å bli ferdig. Løsningen min kunne godt ha vært mer elegant, men på dette tidspunktet var det om å gjøre å bli ferdig. Jeg valgte å lage noen ekstrafelter i bønnene slik at jeg kan bruke de til å lage en datastruktur som senere blir satt inn i databasen. Jeg passet på å lage konstranter i MetaData-klassene slik at disse feltene ikke blir prøvd satt inn i databasen av Rife. Jeg valgte denne løsningen fordi all databasekode ligger i en egen klasse, og strukturen holder fint orden på relasjonene til de blir satt inn i databasen og får sin egen id. 8 Forskjell mellom produkt og kravspesifikasjon Da det ble klart at Ole ikke ville fortsette ble statistikk og brukerbehandling tatt bort slik at jeg kunne bli ferdig med resten. Sett bort fra dette er det noen småting som ble gjort annerledes enn det står i kravspekken. Det finnes ingen liste over spørsmålene i en test når man tar den. Man velger spørsmål kun med knappene forrige- og neste spørsmål. Poeng blir kun regnet ut når eksamen blir levert inn. (Men det går an at et eget system regner ut poeng hvis en eksamen ikke er levert inn i ettertid) Når man tar en test blir ikke svarene lagret midlertidig, men de blir lagret 17

24 permanent. Dette gjør at man i ettertid kan se hva kandidaten svarte. Ettersom brukerbehandling ble tatt bort finnes det ingen «min side.» Det er ingen separat test-del-side, men administrator har en meny med alle valg. Det er ikke et neste->neste-grensesnitt for å lage tester, men det er en side for å lage test, en for å lage spørsmål, og en hvor man velger hvilke spørsmål som skal legges til testen. Når jeg lager en test blir ikke adressen til testen skrevet ut. Det er veldig enkelt å legge til det, men BEKK sa at det ikke er nødvendig. Tidlig i implementasjonsfasen fant jeg ut at å gruppere spørsmål og tester etter emner er en god idé. Dette er ikke et krav som står i kravspesifikasjonen. 9 Avslutning Dette kapittelet gir en oppsummering av prosjektet og hva jeg har lært, før det hele konkluderes. 9.1 Oppsummering Jeg har gjennom hele prosjektperioden jobbet jevnt og trutt. Ettersom gruppen skar seg relativt raskt har jeg jobbet for to gjennom hele implementasjonsfasen, også når det kommer til skriving av dokumentasjon. Under implementasjonsfasen var det frustrerende å ikke vite hva som skjedde, men straks det ble avklart at jeg skulle gjøre prosjektet ferdig alene ble det mye bedre. Det var første gang på flere måneder at jeg hadde full kontroll over det jeg måtte gjøre og hva som sto igjen, og det gav meg helt klart en frihetsfølelse. Jeg har hatt god nytte av det jeg har lært på HIO, spesielt modellering av databaser. Dette prosjektet har introdusert meg til en, for meg, ny måte å lage webapplikasjoner på - å bruke et rammeverk. Jeg har prøvd meg på testdreven utvikling, og har fått en forståelse for hva det er, og hvorfor det er så smart. Når det kommer til å arbeide i en gruppe, har jeg lært at for at et prosjekt skal bli vellykket må det være en leder-skikkelse som tar ansvar for at oppgavene blir gjort. Det ville være en stor fordel for gruppen om vi hadde jobbet sammen på et kontor enn hver for oss uten daglig kontakt. Jeg skrev statusrapporter til BEKK hver uke, men det er ikke bra for gruppen hvis en person ikke er tilgjengelig for å komme med innspill. Store prosjekter krever god planlegging og gode tidsestimater. Det var veldig lurt å lage brukerhistorier med akseptansekriterier, for da var det klinkende klart hvilken funksjonalitet som skulle implementeres, og når den var ferdig. I ettertid ser jeg at de godt kunne ha vært enda mer detaljerte, men de gjorde jobben. I starten av prosjektet laget jeg en arbeidsplan som også fungerte tilfredsstillende. Jeg hadde overestimert tiden det ville ta å bli ferdig med komponentene, men da jeg var den eneste som kodet ble estimatene ganske ok. Alle kravene unntatt statistikk og brukerbehandling er møtt, og jeg er sikker på at BEKK er fornøyd med resultatet. Ettersom jeg la ned mye arbeid i modelleringen av 18

25 databasen, har systemet et stort potensiale for videre utvikling. Databasen er derfor den delen jeg er mest stolt av, og spesielt hvordan kandidatens svar behandles med respons-betingelser, og hvor stor frihet brukeren har til å lage tester. Del-systemet som lar kandidaten ta eksamen er jeg også veldig fornøyd med, siden den er veldig generell, og ikke har noen begrensninger for antall svaralternativer, svaralternativgrupper, respons-behandling og -betingelser. 9.2 Konklusjon Dette prosjektet har vært veldig lærerikt og utfordrende. Ikke bare når det kommer til teknologi og gruppesammarbeid, men den store arbeidsmengden har vært en vekker etter tre år, uten de alt for store utfordringene, som jeg ikke vil være foruten. Oppgaven krevde at jeg måtte lære meg ny teknologi og utviklingsmetode, noe som var veldig krevende å gjøre alene, men jeg føler at jeg taklet det bra, og fikk mye igjen for strevet, i form av erfaring og disiplin. Det gikk med mye tid til å lære seg å bruke Rife, ikke minst når det kommer til å finne frem i dokumentasjonen. Det krevde stå-på-vilje, og høy motivasjon, for å komme i mål med prosjektet, og resultatet er virkelig en passende avslutning på tre års utdannelse, og komplementerer plattformen jeg har for å ta steget ut i arbeidslivet eller høyere utdannelse. Jeg mener jeg har oppnådd målene jeg satt meg for prosjektet, jeg har tilegnet meg nye kunnskaper og erfaringer, og har lært mye av arbeidsprosessen. 19

26 Appendiks Under følger tillegg til rapporten. Det er skjermbilder, prosjektdagbok med statusrapporter og subversion-log. A Skjermbilder Dette vedlegget inneholder alle skjermbildene av systemet, pluss noen ekstra, som er brukt i rapporten. Det anbefales å lese brukerveiledningen for å sette bildene i sammenheng med systemet. Skjermbilde A.1: Velkomstbilde 20

27 Skjermbilde A.3: Logg ut Skjermbilde A.2: Innloggingsskjema Skjermbilde A.4: Første skjermbilde til administrator 21

28 Skjermbilde A.5: Subjecteditor Skjermbilde A.7: Liste med emner Skjermbilde A.6: Endrer et emne 22

29 Skjermbilde A.8: Skjema for spørsmål 23

30 Skjermbilde A.9: Opprette test Skjermbilde A.10: Emner i nedrykksliste 24

31 Skjermbilde A.11: Testeditor med feilmeldinger Skjermbilde A.12: Aktiveringsknapp Skjermbilde A.13: Deaktiveringsknapp 25

32 Skjermbilde A.14: Spørsmål er lagt til testen 26

33 Skjermbilde A.15: Velg eksamen Skjermbilde A.16: Startet eksamen 27

34 Skjermbilde A.17: Besvart eksamen 28

35 B Prosjektdagbok med statusrapporter Dette kapittelet omhandler prosjektdagboken og de ukentlige statusrapportene jeg skrev til BEKK. B.1 1. november 2006 Søker prosjekt. Tilstede: Martin, Ole I dag søkte vi på prosjektet Open source sertifiseringsystem utlyst av BEKK Consulting AS. Vi fikk tilbud om å ta oppgaven med én gang, men Vegard foreslo å ha et møte først. Dato blir bestemt i løpet av uken. B november 2006 Første møte hos BEKK. Tilstede: Martin, Ole, og Vegard Gikk igjennom oppgaven, og litt hva BEKK ønsket med den. Vegard sa litt om testdreven utvikling og bruk av Junit. Vi hadde ikke vært borti noe av det fra før. Vegard sendte oss en mail etter møte med linker til nyttig info etterpå. B november 2006 Utveksling av mail.. Vi har funnet noen forslag til navn på systemet, og har smått begynt å se på krav. Vegard sender tilbakemelding, og endelige navnet blir «Open Exam System». B.4 3. desember 2006 Utveksling av mail Mail fra Vegard. Vegard sender påloggingsinfo for wiki, og repository hvor vi kan ha koden vår. B desember 2006 Møte hos BEKK Tilstede: Martin, Ole, Vegard, og Steffen Vegard skal reise bort en stund, og vi får møte Steffen som skal være kontakten vår i mens. Alle fire diskuterte litt valg av teknologi, og vi ble blant annet anbefalt å ta en titt på rammeverket Rife. Vi ble også enige om leveransene vi skulle levere i løpet av våren: Tidsplan Kravspekk Designdokument 29

36 Spike/Poc Testtaker-del Admin-del Akseptansetest Sluttrapport Presentasjon Frist for tidsplan, og utkast til kravspekk og designdokument ble satt til 11. januar slik at Vegard fikk sett på det før han måtte dra. B januar Utveksling av mail (avtalte dokumenter som vedlegg) B januar 2007 Første møte hos veileder Tilstede: Martin, Ole, og Eva Vi ble informert om masse rart.. Så på skolen sitt mpc-system, og fikk verdifull input. Avtalte ukentlige møter med veileder tirsdager kl Neste uke hopper vi over. B.8 Statusrapport uke 4 Planlagte oppgaver forrige uke: Utdype kravspesifikasjon. Bli kjent med Eclipse/Tomcat/Rife. Spesifisere domenemodell. Gjennomførte oppgaver forrige uke: Utdypning av kravspesifikasjon, Testing med Eclipse/Tomcat/Rife. Laget forslag til databasemodell. Begynt på forprosjektrapporten. Planlagte oppgaver neste uke: Jobbe videre med Rife. Det skal være klart til å begynne på spike. Sette oss litt mer inn i Ant og JUnit. Gjøre ferdig forprosjektet. Spesifisere domenemodell. Kommentarer: Å komme i gang med eclipse-tomcat-rife har tatt lenger tid enn først antatt, men når vi først vet hva vi holder på med vil det gå på skinner. 30

37 Domenemodellen ble ikke gjort som planlagt, for vi er litt usikre på hvordan den bør være. Møter/huskeliste: Hadde første møte med Eva på tirsdag Neste møte med Eva blir tirsdag Foreslår at vi har møte med Steffen tirsdag 6. etter at vi har vært hos Eva, eller onsdag 7. B.9 Statusrapport uke 5 Planlagte oppgaver forrige uke: Jobbe videre med Rife. Det skal være klart til å begynne med spike. Sette oss litt mer inn i Ant og JUnit. Gjøre ferdig forprosjektet. Spesifisere domenemodell. Utførte oppgaver forrige uke: Satt oss mer inn i Rife, Ant, JUnit. Gjort ferdig forprosjektet. Laget et forslag til domenemodell. Planlagte oppgaver neste uke: Kombinere alle teknologiene og lage en testapplikasjon for å sjekke at alt er klart til å begynne på selve utviklingen. Rette på/utvide domenemodellen. Kommentarer: Domenemodellen bør muligens spesifiseres ytterligere. Vi satser på å ha den helt klar til utviklingen starter om en uke. Møter/huskeliste: Førstkommende møte med Eva blir tirsdag Vi skal også ha møte med Steffen tirsdag 6. etter at vi har vært hos Eva, eller onsdag 7. B februar 2007 Møte hos veileder Tilstede: Martin, Ole, og Eva Forprosjektrapporten er for tynn, men inntrykket av arbeidet så langt ble rettet opp da vi viste dokumentene vi har opprettet på wikien. Fikk informasjon om hva som skal være med i kravspesifikasjonen. Det er viktig med figurer! B februar 2007 Møte hos Ole Tilstede: Martin, Ole, og Steffen 31

38 Gikk igjennom status av prosjektet. Problemer vi har hatt, og planen fremover. Tok også en kikk på risikoanalyse. B.12 Statusrapport uke 6 Planlagte oppgaver forrige uke: Lage en testapplikasjon. Rette på/utvide domenemodell. Gjennomførte oppgaver forrige uke: Har laget en spike som henter radene fra en tabell i en database med id mindre eller lik en input-verdi. Begynt på kravspesifikasjon-dokumentet som skal være ferdig mandag før kl. 16. Planlagte oppgaver neste uke: Lage en klasse/bibliotek for å importere qti-filer. Kommentarer: Mangler å joine to tabeller for at testapplikasjonen skal være «ferdig.» Det er ikke akkurat overflod av dokumentasjon på sidene til Rife. Møter/huskeliste: Hadde andre møte med Eva på tirsdag Neste møte med Eva blir tirsdag Hadde møte med Steffen onsdag B februar 2007 Møte hos veileder Tilstede: Martin, Ole, og Eva B februar 2007 Skrevet om databasemodell Tilstede: Martin Har oppdatert databasemodellen mye den siste uke. Skrevet om den i produktrapporten. Det er ikke ferdig. B februar 2007 Eksportering av QTI-filer Tilstede: Martin Eksportering av qti er ferdig for nå. Mangler å kunne laste ned filen med browseren, og har ikke testen klassen stort. Testingen starter når Ole har laget Qti-importøren, så vi enkelt kan legge tester i databasen. B.16 Statusrapport uke 8 32

39 Planlagte oppgaver forrige uke: Importere QTI. Eksportere QTI. Gjennomførte oppgaver forrige uke: Eksportere QTI. Importere QTI?? Kommentarer: Eksportere QTI: Ganske ferdig. Mangler noen småting og å kunne laste ned filen med nettleser, men det er ikke så farlig akkurat nå. Det viktigste med import og eksport av QTI var å modellere databasen, og det har vi klart ganske bra. Har justert småting ofte de siste dagene, så den er nok ikke 100% ferdig. Importere QTI: Aner ikke. Har ikke hørt fra Ole siden torsdag. Vet at han har begynt, men hvor langt han har kommet vet jeg ikke. Møter/huskeliste: Møte med Eva på tirsdag. B februar 2007 «Databasemanager» Tilstede: Martin Har laget en DbManager som utvider rife-klassen DbQueryManager. Inneholder metoder for å hente ut data fra databasen, f.eks getitems(int idquest..) henter alle Item-er fra db. B mars 2007 Flytdiagram for «ta test.» Tilstede: Martin Har laget et flytdiagram med elementene som trengs for å ta en test. Har med flowlink-er, datalink-er og elementer. B.19 Statusrapport uke 9 Planlagte oppgaver forrige uke: Importere QTI. Starte på testgrensesnittet: skrive ut spørsmål og svaralternativer. Gjennomførte oppgaver forrige uke: Skrive ut spørsmål og svaralternativer. Startet på «ta test.» Laget flytdiagram og tenkt litt på hvordan det må være. Importere QTI: Planlagte oppgaver neste uke: 33

40 Fortsette på «ta test.» Implementere grunnfunksjonalitet i elementene vi har satt opp. Importering av QTI. Kommentarer: Ole: PCen min har vært ustabil en stund, og klikka rett før helga for en uke siden. Nye pc-deler er bestilt, og ankom fredag før helga. Installerte Vista 64-bit, som jeg gav opp nå på søndag på grunn av drivermangel og trøbbel med programvare. Installerer XP igjen. På grunn av en del trøbbel med datamaskinen henger jeg en del etter, og har heller ikke hatt like hyppig kontakt med Martin som jeg pleier (bare utvekslet noen sms om statusen). Import-delen har heller ikke blitt testen med resten av systemet enda, og er nok en del mer arbeid der. Det beregnes vel at vi får opp en liten test som legges ut på nett som man kan prøve selv om ikke så alt for lenge. Møter/huskeliste: Møte med Eva på tirsdag. B mars 2007 Møte hos veileder Tilstede: Martin og Eva Møtet gikk ikke helt som planlagt, for Ole forsov seg. Martin og Eva ble enige om at vi skal vise frem hva vi har gjort hittil, på neste møte. B mars 2007 StartExam Tilstede: Martin Viktig funksjonalitet for å ta en eksamen som mangler: svar lagres i databasen og poengsum kalkuleres etter innlevert test. «Ta test» har følgende funksjonalitet: TestList: liste over tester. Hvordan man velger en test må vi komme tilbake til. F.eks kan en bruker ha en liste over aktive tester han er meldt opp til, men det tror jeg det ikke blir tid til. Alternativer er liste over alle aktive tester: vil ikke være så mange aktive tester i starten at det gjør noe om oppmelding ikke er implementert. Få en adresse til en test, f.eks fra e-post.. Hvertfall, man trykker på en test i listen for å starte eksamen. StartExam: legger en ny rad til Exam-tabellen og sender id-en videre til DisplayItem. StartExam skal etter hvert gi beskjed om man ikke får lov til å ta eksamen, f.eks fordi man har gjort det før. DisplayItem: Samler sammen spørsmål og svaralternativer, og viser ett og ett spørsmål m/svar. Har knapp for neste og forrige spørsmål, samt innlevering. Viktig funksjonalitet som mangler er tilfeldiggjøring av spørsmål og svaralternativer. Lagre svarene i db etter hvert spørsmål. Tiden som gjenstår.. 34

41 B mars 2007 Fikk en epost fra Steffen i dag, hvor han sier at han ikke har fått statusrapport for uke 8 med innspill fra Ole, pluss rapportene for uke 9 og 10. Han lurer på hva som har skjedd, og ønsker å ha et møte med oss sammen med Vegard for å gå gjennom hva vi har gjort. Dette er svaret jeg sendte: «Det ser ut til at vi har gått pa en smell. Vi skrev rapporten for uke 9, men begge trodde at den andre sendte den. Legger den ved nå. Ole skrev om problemene han hadde, så det er mulig det også gjelder for uke 8. Ang. uke 10, så venter jeg på innspill fra Ole. Jeg håper å få sendt den i løpet av dagen. Ola har fortsatt pcproblemer, så vi ligger litt etter.» B.23 Statusrapport uke 10 Planlagte oppgaver forrige uke Importering QTI Fortsette på «ta test.» Implementere grunnfunksjonalitet i elementene vi har satt opp. Gjennomførte oppgaver forrige uke Fortsatt på «ta test.» Planlagte oppgaver neste uke Må komme i gang og skrive mye på sluttdokumentasjonen. Ta test: Kun 1 eller uendelig mange ganger. Beregne poengsum. Spørsmål/svaralternativer i tilfeldig rekkefølge. Tidsbegrensning. Importere qti? Kommentar: Martin er litt demotivert av hvordan prosjektet går, så han har ikke fått gitt 100% i uke 10. Møter/huskeliste: Møte med Eva på tirsdag. Foreslår møte med Steffen og Vegard tirsdag etter møtet med Eva, eller onsdag. Klokkeslett kan vi komme tilbake til. Kommentar i ettertid: Jeg fikk ikke innspill på denne rapporten av Ole. B mars 2007 StartExam osv Tilstede: Martin Ta test 1 eller uendelig mange ganger. Beregner poengsum. Tidsbegrensning. Spørsmål og svar i tilfeldig rekkefølge. 35

42 B mars 2007 Databasemodell Tilstede: Martin Oppdatert dbmodell mhp. views og autentisering. Ellers har jeg gjort mange små forandringer hele tiden. B mars 2007 Skrevet mail til Vegard om at jeg mangler innspill fra Ole om hva han har gjort, til statusrapporten. Jeg og Ole kommuniserer dårlig i helgene. B.27 Statusrapport uke 11 Planlagte oppgaver forrige uke: Komme i gang og skrive mye på sluttdokumentasjonen. Ta test: kun 1 eller uendelig mange forsøk. Beregne poengsum. Spørsmål og svaralternativer i tilfeldig rekkefølge. Tidsbegrensning. Gjennomførte oppgaver forrige uke: Ta test: kun 1 eller uendelig mange forsøk. Beregne poengsum. Spørsmål og svaralternativer i tilfeldig rekkefølge. Tidsbegrensning. Planlagte oppgaver neste uke: Sluttdokumentasjon. Fikse db mhp. views. Autentisering. Kommentarer: Møter/huskeliste: Møte med Vegard og Steffen på onsdag. Møte med Eva tirsdag. B mars 2007 Møtet med Eva ble avlyst, for Eva skulle på seminar. Ole informerte meg i seneste laget. B mars 2007 Ole møtte ikke på møtet med BEKK, enda jeg sendte han sms i går kveld og minte han på det. Ole sier han hadde glemt møtet, og hadde derfor ikke på vekkerklokken. Etter møtet sendte Vegard en epost med punkter vi må ta tak i: «Etter møtet i dag har jeg følgende oppfølgingspunkter som dere må ta tak i: 1. På møtet var det kun Martin som stilte. Dersom Ole ikke ønsker å fortsette må dette avklares så fort som mulig. 2. Ole har ikke sjekket inn kode i subversion på lenge. Det er viktig at 36