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

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

PROSJEKTNR. 07-12 Studieprogram: Ingeniørfag, Data Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Cort Adelers gate 30, Oslo TILGJENGELIGHET Åpen Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA HOVEDPROSJEKTETS TITTEL Open Exam System PROSJEKTDELTAKERE Martin Oppegaard (s129190) DATO 25. mai 2007 ANTALL SIDER / BILAG 28 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 responsbehandlingen veldig fleksibel. 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.

1 Innholdsfortegnelse 1 Innholdsfortegnelse...4 2 Forord...5 2.1 Hensikt...5 2.2 Lesere...5 2.3 Organisering av dokumentet...5 3 Hensikten med prosjektet...5 3.1 Om bedriften...5 3.2 Dagens situasjon...6 4 Systembeskrivelse...6 4.1 Arkitekturdiagram...6 4.2 Kort om systemet...7 4.3 Hendelsesdiagram...7 4.4 Databasemodell...9 4.4.1 Bilde...9 4.4.2 Generelt...10 4.4.3 Oversikt over tabellene...10 4.5 Teknologier i bruk...16 5 Rammekrav...19 5.1 Krav til funksjonalitet...19 5.2 Krav til utviklingsmetode...19 5.3 Krav til design...19 5.4 Krav til sikkerhet...19 5.5 Krav til dokumentasjon...19 6 Bruk av smidig metode og test-drevet utvikling...21 Appendiks...22 A Brukerhistorier og akseptansekriterier...22 B Risikoanalyse...28 Side 4

2 Forord 2.1 Hensikt Kravspesifikasjonen er et dokument som beskriver kravene til systemet. Dokumentet er utarbeidet i samarbeid med arbeidsgiver sine krav, og vil fungere som en slags avtale på hva systemet skal inneholde. Kravspesifikasjonen vil kunne endres underveis i samarbeid med arbeidsgiver. Kravspesifikasjon spilte en stor rolle i starten av prosjektet i forbindelse med modellering av databasen. Jeg henviser til prosessdokumentasjonen for beskrivelse av hele prosessen. Kravspesifikasjonens hensikt er å fungere som et styringsdokument under implementasjonsfasen. 2.2 Lesere Kravspesifikasjonen henvender seg primært til gruppen og arbeidsgiver, men også sensor og veileder vil ha nytte av dokumentet for å vurdere prosjektet. Ved å sammenlikne kravspesifikasjonen og det ferdige resultatet vil de få et bedre grunnlag å vurdere prosjektet på. Det forutsettes at leseren har god datateknisk kunnskap og er kjent med generelle datatekniske ord og uttrykk. 2.3 Organisering av dokumentet Først skriver jeg om dagens situasjon og beskrivelsen av systemet. Det omfatter arkitekturen, teknologier bak, prgrammets flyt, og den ferdige databasemodellen. Deretter kommer rammekrav. Til slutt i dokumentet er det et appendiks med brukerhistorier og akseptansekrav, og risikoanalyse. Brukerhistoriene beskriver systemets funksjonelle krav, og hvilke kriterier som bestemmer når de er ferdige. Kravspesifikasjonen er optimalisert for papirutskrift. 3 Hensikten med prosjektet Dette er en liten introduksjon om bedriften og dagens situasjon som har ført frem til ønsket om dette prosjektet. For beskrivelse av prosjektet, se kapittel 4. 3.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 Side 5

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. 3.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 Systembeskrivelse BEKK har ikke noe system for intern sertifisering fra før. Så det systemet vi skal utvikle vil derfor ikke ta over for noe eldre, men heller innføres som et helt nytt tiltak for bedriften. Tanken bak utviklingen av OES (Open Exam System) er at BEKK skal kunne bedre oversikten over kunnskapen til sine ansatte og samtidig få en måte å formalisere den på (f.eks. i form av interne sertifiseringer). Bruksområdene vil kunne være flere. Om bedriften f.eks. har et kurs, så kan de etter kurset kjøre en test for å sjekke om de ansatte fikk med seg relevant informasjon på kurset. De kan bruke det for sertifisering slik at man er nødt til å bestå en viss test før man kan si at man innehar kompetansen sertifiseringen tilsier. Om ønskelig så kan man så bruke denne informasjonen til å plukke ut riktige mennesker til riktig jobb. Systemet vil hovedsaklig bestå av en webapplikasjon som kjører i en med en database i bakhånd. Brukeren vil kunne koble til applikasjonen gjennom en standard nettleser over HTTP (Hyper Text Transfer Protocol) som er standardprotokollen for overføring av nettsider. Dette gjør applikasjonen plattformuavhengig samtidig som man slipper ekstra installasjon på klientsiden. Webapplikasjonen vil gjøre bruk av MVC-rammeverk (Model-View-Controller) for å skille logikk og design. JDBC (Java Database Connectivity) sørger for kommunikasjon mellom databasen og webapplikasjonen gjennom en JDBC-driver for den aktuelle databasen. 4.1 Arkitekturdiagram Arkitekturdiagrammet viser relasjonene mellom de forskjellige delene i en webapplikasjon som bruker Rife. Side 6

Illustrasjon 4.1: Arkitekturdiagram 4.2 Kort om systemet OES skal bli et system hvor man skal kunne lage, administrere, og ta flervalgstester. Det skal være en enkel applikasjon som skal ta hånd om alt i forbindelse med brukere og tester. Det vil også bli mulig å importere og eksportere tester i det standardiserte XML-formatet IMS QTI (extensible Markup Language)(IMS Question & Test Interoperability). Systemet vil få to roller. En administrator-rolle som har muligheten til å lage og administrere brukere og tester, og en bruker-rolle som kun vil kunne ta tester. For begge rollene vil det være statistikk tilgjengelig for å gi en oversiktlig tilbakemelding på utfallet av testene. 4.3 Hendelsesdiagram Hendelsesdiagrammet viser hvordan flyten i programmet går. Eksempel: for å endre en test må du først logge inn og velge testen fra testlisten. Side 7

Illustrasjon 4.2: Hendelsesdiagram Side 8

4.4 Databasemodell 4.4.1 Bilde Bildet ble så stort at jeg delte det i to. Se appendiks C for mer detaljerte bilder. Illustrasjon 4.3: Databasemodell - sammenslått 1/2 Side 9

Illustrasjon 4.4: Databasemodell - sammenslått 2/2 4.4.2 Generelt Alle tabeller har en surrogatnøkkel som primærnøkkel. 4.4.3 Oversikt over tabellene authuser: Tabellen Rife bruker til å slå opp brukernavn og passord. userid: 64 bit integer. Brukerens id. login: Det unike brukernavnet til brukeren. passwd: Brukerens passord. authentication: Brukes av Rife til aktive sesjoner. authid: Sessjonens id. userid: Fremmednøkkel til authuser. hostip: Brukerens ip. sessstart: Når en sesjon ble startet. Er indeksert for raskt oppslag ved fjerning av sesjoner. remembered: Slipper å logge seg inn på nytt når sesjonen timer ut. Side 10

authrole: Brukerroller/grupper som brukes av Rife til å begrense tilgang til sider. Rollene brukes også til å begrense hvem som har tilgang til å se feedback og objectives. roleid: Rollens id. name: Navnet på rollen. Administrator, Candidate og All er installert. authrolelink: Intersection-tabell mellom authrole og authuser. En bruker kan høre til flere grupper. Auth-tabellene følger ikke navnkonvensjonen fordi OES bruker Rife sine ferdige klasser for autentisering. exam: Utførte eller pågående eksamener. examid: Eksamenens id. authuser_userid: Fremmednøkkel til authuser. questestinterop_idquestestinterop: Fremmednøkkel til questestinterop. date: Når eksamenen ble startet. score: Poengsummen kandidaten fikk. time: Hvor lang tid kandidaten brukte. account: Tilleggsdata for brukere. idaccount: Kontoens id. authuser_userid: Fremmednøkkel til authuser. name: Brukerens navn. surname: Brukerens etternavn. company: Firmaet hvor brukeren er ansatt. position: Hvilken stilling brukeren har hos firmaet. dateofbirth: Brukerens fødselsdag. email: Brukerens unike epostadresse. questestinterop: Navnet på kjerneelementet i en qti-fil. Questestinterop er altså en test. Spørsmålene i OES kan brukes i flere tester, men det er ikke sikkert at hver test ønsker å bruke spørsmålets rshuffle-verdi (om svaralternativene skal presenteres i tilfeldig rekkefølge eller ikke), så Shuffle_override overkjører rshuffle på testnivå. idquestestinterop: Testens id. subject_idsubject: Fremmednøkkel til subject. state: Hvilken tilstand testen er i. Aktiv/inaktiv. title: Testens tittel. Side 11

date_created: Datoen testen ble opprettet. date_modified: Datoen testen ble endret. time: Hvor lang tid kandidaten har på seg til å fullføre eksamen i millisekunder. attempts: Om kandidaten kan ta testen en eller uendelig mange ganger. shuffle_override: Overkjør spørsmålene sine shuffle-instillinger. itiem_shuffle: Om spørsmålene blir vist i tilfeldig rekkefølge eller ikke. totalscore: Maksimal poengsum kandidaten kan få. subject: Tester og spørsmål hører til et emne. idsubject: Emnets id. subject: Navnet til emnet. code: Emnets unike kode. item: Item inneholder alt et spørsmål trenger, som presentasjon av spørsmålet, mål med spørsmålet, svaralternativer, resultatprosessering, feedback og resultattester. En test kan inneholde flere item, og hvert item kan inneholde flere mål, resultatprosessorer og feedback. Ident er globalt unik, og er derfor en alternativ nøkkel. IMS anbefaler at man bruker en navnekonvensjon for å sikre at identiteten til et item er unik. Item er mange-til-mange med questesinterop så et spørsmål kan brukes i flere tester. Ettersom det brukes en intersection-tabell, med [questestinteropid, itemid] som primærnøkkel, kan et spørsmål kun brukes én gang i samme test. iditem: Item-en sin id. presentation_idpresentation: Fremmednøkkel til presentation. ident: Item-en sin globalt unike identifiserer. label: Beskrivelse av item. title: Item-en sin tittel. questestinterop_has_item: Intersection-tabell for questestinterop og item. Denne tabellen brukes for å koble spørsmål (item) til tester (questesinterop). presentation: Spørsmål med overskrift. idpresentation: Presentasjonens id. subject_idsubject: Fremmednøkkel til subject. material_idmaterial: Fremmednøkkel til material-raden med spørsmålsteksten. label: Beskrivelse av spørsmålet. Side 12

response_lid: Tabell med opsjoner til svaralternativer. Hvert spørsmål kan ha flere response_lid som igjen kan ha flere svaralternativer. Rcardinality, rtiming, min- og maxnumber har bare lov til å ha én forhåndsbestemt verdi. De er med for kompatibilitet med QTI, og det gjør det lettere å implementere mer av spesifikasjonen senere. Shuffle_choise bestemmer om svaralternativene kan være i tilfeldig rekkefølge eller ikke. idresponselid: Response_lid-ens id. presentasjon_idpresentation: Fremmednøkkel til presentation: ident: Identifikator. rcardinality: Hvor mange svar fra brukeren. OES implementerer kunn ett svar, så Rcardinality er fast «Single.» shuffle_choise: Om svaralternativene kan være i tilfeldig rekkefølge eller ikke. Nei overstyrer ja i answer.rshuffle. minnumber: Minst antall svar fra brukeren. Fast til 1. maxnumber: Maks antall svar fra brukeren. Fast til 1. rtiming: Om spørsmålet går på tid eller ikke. Denne har ikke noe med om testen går på tid eller ikke, som bestemmes av questestinterop. Fast til No. answer: Et svaralternativ. Answer tilsvarer response_label i qti. Ident er unik blant svaralternativene i tilhørende response_lid, så attributtene [response_lid_idresponselid, ident] utgjør er sammensatt alternativ nøkkel. Labelrefid spesifiseres i qti som en valgfri merkelapp som kan bruks til å identifisere nøkkeldeler. Rshuffle bestemmer om svaralternativet skal presenteres i tilfeldig rekkefølge. Et spørsmål kan da f.eks ha x svaralternativer i tilfeldig rekkefølge etterfulgt av «vet ikke» som alltid er nederst. Siden spørsmålene i OES skal være uavhengige av test, kan hver test overstyre rshuffle i svaralternativene, og velge om alle svaralternativer skal være i tilfeldig rekkefølge eller ikke. Dette medfører at også svaralternativer med rshuffle satt til nei vil bli i tilfeldig rekkefølge hvis testen overstyrer. idanswer: Svaralternativets id. material_idmaterial: Fremmednøkkel til material-raden som har svarteksten. response_lid_idresponse_lid: Fremmednøkkel til response_lid. ident: Identifikator for svaralternativet. Vil normalt være A, B, C, D osv. labelrefid: Merkelapp som kan brukes til å identifisere NØKKELFEATURES: Kun med for kompabilitet med QTI. rshuffle: Sier om svaralternativet skal være i tilfeldig rekkefølge eller ikke. respcondition: Respons-tester med relasjon til et svaralternativ som setter poeng avhengig av om testen slår til eller ikke. Testene er varequal, varequal + notvarequal(true) og unanswered. Varequal slår til hvis man har valgt svaralternativet til den aktuelle respcondition. Notvarequal slår til hvis man har valgt annet alternativ enn svaralternativet til den aktuelle respcondition. Unanswered trenger ingen relasjon til svaralternativ. Unanswered er ikke det samme som «vet ikke,» men hvis testtaker Side 13

har hoppet helt over spørsmålet/ikke rakk å levere i tide. Feedbacktype og action er med for kompabilitet. Varname er hvilken variabel som skal bli satt med value poeng. OES bruker den ikke, men den er med for kompabilitet med QTI. idrespcondition: Respcondition sin id. answer_idanswer: Fremmednøkkel til answer. title: Tittel. F.eks «Riktig svar» eller «Galt svar.» varname: Hvilken variabel som poenget skal legges til. OES støtter kun «SCORE,» men navnet er irrelevant. value: Poenget som legges til hvis testen slår til. feedbacktype: Sier hvordan feedback brukeren skal få. OES implementerer ikke feedback nå, men databasen er klar for «response.» conditiontest: Hvilken type test. Varequal eller unasnwered. notconditiontest: True eller false. True sjekker om kandidaten har svar et annet svar enn svaret answer_idanswer peker til, hvis conditiontest er varequal. Notconditiontest gjelder ikke hvis conditiontest er unanswered. action: Handlingen som skal gjøres mot Varname. Denne er fast til «Set.» resprocessing_idresprocessing: Fremmednøkkel til resprocessing. resprocessing: Opsjoner til- og er en «kappe» for respcondition. idresprocessing: Resprocessing sin id. item_iditem: Fremmednøkkel til item. varname: Navnet på variablen poeng blir satt til. Oes støtter bare «SCORE,» hvis navn er irrelevant. Er med for kompabilitet med qti og for videre utvikling. vartype: Hvilken type varname er. Oes støtter bare «Integer,» men den er med for videre utvikling. defaultval: Startverdien til resprocessingen. Poengsummen til respcondition-ene som hører til resprocessing-en blir lagt til denne verdien. exam_has_presentation: Assosiasjonstabell mellom Exam og Presentation. Primærnøkkel er (examid, presentationid) og har en attributt answerid som er en fremmednøkkel til Answer. Når en eksamen starter blir tabellen fylt opp med rader for hvert spørsmål, slik at det er mulig å sjekke om spørsmål er ubesvart. Hvis besvart er answerid en relasjon til svaret til det aktuelle spørsmålet til den aktuelle testen. feedback: Tilbakemelding til brukeren relatert til respcondition. Foreløpig ikke implementert. idfeedback: Feedback sin id. idrespcondition: Hvilken respcondition raden hører til. material_idmaterial: Fremmednøkkel til material hvor material-teksten er. Side 14

ident: Identifikator. title: Tittel. feedback_has_authrole: Hvilke grupper som kan se tilbakemeldingen. Foreløpig ikke implementert annet enn at databasen er klar. material: Tekst som skal vises, som f.eks et spørsmål. idmaterial: Material sin id. mimetype: Mimetypen til material. Er med med tanke på fremtidig utvikling. Man kan f.eks ha et png-bilde hvis mimetype er image/png, eller html, xml osv. material: Selve materialet. objective: Målet med spørsmålet. Foreløpig ikke implementert. idobjective: Målets id. material_idmaterial: Fremmednøkkel til material hvor selve teksten står. item_iditem: Fremmednøkkel til item. objective_has_authrole: Hvilke grupper som kan se målet. Side 15

4.5 Teknologier i bruk Webapplikasjonen vil hovedsaklig bestå av programmeringsspråket Java (1.5), rammeverket Rife, og markeringspråket HTML (Hyper Text Markup Language). Disse teknologiene utgjør selve kjernen av kildekoden som skal skrives. De fleste resterende teknologiene vil være støttespillere som ikke nødvendigvis er helt låst. Det er valgt å kun bruke fri teknologi og programvare for utviklingen av OES. Dette har med ønske om å eliminere unødvendige utviklingskostnader og at OES selv skal utvikles som fri programvare tilgjengelig under open source lisensen GPL (GNU General Public License). Det har blitt laget en testapplikasjon (Spike) som tester samarbeidet mellom alle nødvendige teknologier OES skal gjøre bruk av. Testen ble vellykket, og valgt teknologi som listes opp her vil derfor være endelig så fremt ikke uforutsette problemer oppstår. Utviklingsspråk: Java (1.5) Java er et populært språk som er totalt plattformuavhengig og vil kjøre på så og si alt av maskinvare. Det er godt egnet til å utvikle webapplikasjoner med, og det finnes mengder med verktøy for det. Java har stått sentralt i programmeringsfag ved universiteter og høgskoler de siste årene, og det er derfor noe de fleste av den yngre it-garde har kjennskap til. Det vil være relevant for senere videreutvikling at OES utvikles i et språk som er vidt utbredt slik at mange vil ha muligheten til å bidra. Rammeverk: Rife Det var BEKK som tipset om rammeverket Rife. Dette er et lettvekts rammeverk som skiller helt mellom logikk og design ved hjelp av HTML-kommentarer. Rife har en «full stakk.» Det vil si at Rife inneholder de fleste egenskaper man trenger for å lage en dynamisk databasedrevet webapplikasjon. Etter en nærmere undersøkelse av rammeverket ble det klart at dette måtte prøves. (Rife støtter Java 1.4 og 1.5) Oversikt over hvilke komponenter Rife inneholder. Kilde: www.rifers.org Presentasjon: HTML og CSS (Cascading Style Sheets) Designet vil gjøres ved hjelp av HTML-templates, og layouten til disse vil styres av sentrale CSS filer. Side 16

IDE: Eclipse (3.2) Eclipse er et populært open source utviklingsverktøy. Det er et slags rammeverk for utvikling, og kommer som standard med Java Development Tools. Det kan derimot ta hundrevis av andre plugins for å takle alle mulige forskjellige språk og funksjoner. Ekstra plugins til Eclipse for utviklingen av OES: Subclipse Plugin for bruk av versjonskontroll programmet Subversion. Forenkler bruk av Subversion drastisk ved å gi støtte for det direkte fra menyene i Eclipse. Sysdeo Eclipse Tomcat Plugin v3.2 Gjør det mulig å styre Tomcat rett fra Eclipse. Applikasjonsserver: Apache Tomcat (5.5) Dette er servlet containeren hvor webapplikasjonen vil kjøres fra under utvikling. Det er finnes flere andre alternativer til Tomcat, både som er gratis, og som koster penger. Valget her havnet på Tomcat pga det er ett av de anerkjente gratis mulighetene på markedet. Brukeren vil selv kunne velge å kjøre applikasjonen på en annen server. Testrammeverk: JUnit JUnit er et rammeverk for å skrive unit tester til Java kode i Java. Bruk av JUnit hører sammen med bruken av TDD (Test-Driven Development) som inngår som en del av utviklingsmetoden til smidig metode (Se kapittel 6). DBMS: PostgreSQL Det er ønskelig at OES skal støtte så mange databaser som mulig. Filosofien er at brukeren selv burde kunne velge hvilken DBMS som skal brukes. Det vil derfor så langt som mulig brukes standardisert SQL (Structured Query Langugage). Automatisere byggeprosessen: Ant Ant er et av de mest brukte byggeverktøyene for å automatisere bygging av Javaprosjekter. Det ble derimot ikke brukt under utviklingen av test-applikasjonen, og det er på dette tidspunktet usikkert om det vil bli brukt i forbindelse med utviklingen av OES. Det er likevel sannsynlig at det vil bli inkludert en støtte for det slik at OES kan bygges med Ant når systemet er ferdig. Versjonskontroll: SVN (Subversion) BEKK har opprettet et svn «repository» hos seg som vi gjør bruk av. Her legger vi alle filene vi arbeider med. Den holder så styr på alle endringene vi gjør og integrerer dem sømløst etterhvert som vi laster dem opp. Dette gjør at vi uten problem kan sitte å jobbe på de samme filene samtidig uten å trenge å være redd for at endringer skal gå tapt. Det er også en ekstra sikkerhet mot data tap (f.eks. Disk-krasj). Import/Export format: IMS QTI XML-format IMS QTI er et xml-format som er laget for kunne å beskrive elektroniske tester. Det fine med å bruke en slik standard er at testfilene vil kunne være kompatible med andre testsystemer som støtter den samme standarden. Side 17

I OES vil vil kun avgrenset del av standarden støttes. Akkurat hva som vil støttes og ikke støttes er ikke klart enda, og det vil bli definert i et eget vedlegg på et senere tidspunkt. Mer info om formatet kan finnes på nettadressen http://www.imsglobal.org/question/ Side 18

5 Rammekrav 5.1 Krav til funksjonalitet Applikasjonen skal brukes internt i BEKK, men den skal utvikles som open source, og vil mest sannsynlig bli tatt i bruk mange andre steder også. Det vil bli fokusert mye på funksjonalitet fremfor at brukergrensesnittet skal se «fancy» ut. Det viktigste er at systemet fungerer slik det skal med de grunnleggende kravene oppfylt. Systemet skal være plattformuavhengig, og brukeren skal kun trenge å taste inn en adresse (URL) i nettleseren sin for å få tilgang. Systemet blir så presentert i nettleseren formatert med standard HTML. Dette gjør at man slipper installasjon, og alle problemene/driftkostnadene det ville medført. Applikasjonen skal ha muligheten for å lage tester, administrere tester, og ta tester. Det skal også være mulig å importere og eksportere tester ved hjelp av et standardisert xml-format (IMS QTI). Brukerpålogging med to forskjellige roller ønskes også. For utdypet krav til funksjonalitetet, se vedlegg A med brukerhistorier og akseptansekriterier. 5.2 Krav til utviklingsmetode BEKK har valgt at prosjektet skal benytte seg av smidig metode i gjennomføring. Dette er en metode BEKK bruker mye selv, og som de synes er en bra måte å gjennomføre prosjekter på. For mer informasjon om utviklingsmetoden som vil brukes se kapittel 6 om Smidig metode og test-drevet utvikling. 5.3 Krav til design Det er ikke noe særlig krav til design annet enn at det skal være enkelt å bruke. Det er lite fokus på denne delen, og vi vil gjøre det så enkelt som mulig. 5.4 Krav til sikkerhet Det er et lavt krav til sikkerhet på denne applikasjonen, og vi har fått beskjed om å ikke fokusere på det. Det er likevel ønsket å ha to roller hvor den ene er begrenset til kun å ta tester og kunne se sine egne resultater. 5.5 Krav til dokumentasjon Vi følger høgskolens dokument standard som er satt av Mari Torvatn. Dette fordi det er et krav fra høgskolens side, og fordi det er en standard som brukes av mange i arbeidslivet. Dokumenter og informasjon om prosjektet legges på et webområde hos høgskolen. BEKK ønsker at vi også bruker en wiki de har opprettet for prosjektet til å legge inn dokumentasjon om systemet der. En wiki er en webside som gjør det mulig for brukere å enkelt legge til, fjerne, eller endre tilgjengelig innhold direkte via en nettleser. Denne siden vil de fortsette å bruke i etterkant som dokumentasjon for systemet, og den vil oppdateres ytterligere i takt med videre utvikling etter at Side 19

prosjektet vårt er ferdig. Dette medfører at vi legger ut en del info dobbelt. Side 20

6 Bruk av smidig metode og test-drevet utvikling Smidig metode vil si at det arbeides i korte iterasjoner, og med tett kontakt med kunden. I forbindelse med smidig programmering gjør vi bruk av en del utviklingsmåter. Skrive brukerhistorier definert på formen Som <rolle> Skal jeg kunne <funksjonalitet> Slik at <forretningsverdi> Skrive akseptansekriterier for hver brukerhistorie, på formen Gitt at jeg er en <rolle> som har <gjort et eller annet> Når jeg <handling> Så <resultat> Skrive enhetstester med JUnit for alle klasser (test-drevet utvikling) (Testene bør skrives før klassen) Levere ny funksjonalitet for hver iterasjon i henhold til tidsplanen Se http://www.agilemanifesto.org/principles.html for prinsipper bak smidig utvikling. Side 21

Appendiks A Brukerhistorier og akseptansekriterier Dette kapittelet beskriver alle kravene til systemets funksjonalitet, skrevet som brukerhistorier med akseptansekrav. Hvert underkapittel tar for seg en rolle. A.1 Testtaker Velge test Som testtaker Skal jeg få presentert tester på en oversiktlig måte Slik at jeg ikke har mulighet til å velge feil test. Gitt at jeg er en testtaker som har fulgt en link til en test Når jeg har logget inn Så får jeg tilgang til å ta testen. Ta test Som testtaker Skal jeg kunne ta en test Slik at jeg får verifisert at jeg har gitt kompetanse. Gitt at jeg er en testtaker som har logget inn Når jeg har valgt test Så skal jeg få presentert ett spørsmål, og en liste med linker til resten av spørsmålene, og en neste-link, slik at hvert spørsmål er på sin egen side Gitt at jeg er en testtaker som har logget inn og valgt test Når jeg har valgt et svaralternativ på alle spørsmålene og trykket "lever besvarelse" Så skal besvarelsen lagres i databasen. Gitt at jeg er en testtaker som går inn på en test Når jeg ikke leverer inn testen Så skal det registreres at jeg har tatt testen, og jeg skal få poeng for spørsmålene jeg har besvart Svaralternativer Som testtaker Skal jeg kunne svare på svaralternativ Slik at jeg kan verifisere at jeg har kunnskap innenfor et gitt emne. Gitt at jeg er en testtaker som tar en test Når jeg skal svare på et spørsmål Så skal jeg få forskjellige alternativer i tilfeldig rekkefølge å velge mellom. Gitt at jeg er en testtaker som tar en test og har valgt et svaralternativ Side 22

Når jeg går videre til neste spørsmål Så skal svaret lagres midlertidig, slik at jeg kan gå tilbake til spørsmålet og endre svar, før jeg leverer inn svaret. Få resultat Som testtaker Skal jeg kunne få se resultatet etter endt test Slik at jeg kan se hvor bra jeg gjorde det. Gitt at jeg er en testtaker som har valgt test Når jeg har valgt et svaralternativ på alle spørsmålene og trykket "lever besvarelse" Så skal jeg få poengsummen skrevet til skjermen. Tidsbegrensning Som testtaker Skal jeg kunne se hvor lang tid jeg har igjen av testen Slik at jeg kan beregne tidsbruken. Gitt at jeg er en testtaker som tar en test Når? alltid SÅ skal det være en klokke som teller ned så jeg ser hvor lang tid det er igjen til en hver tid Gitt at jeg er en testtaker som tar en test Når jeg ikke har levert innen tidsfristen Så skal jeg få en beskjed om at tiden er ute. Logge inn Som testtaker Skal jeg kunne logge inn Slik at min identitet blir verifisert og jeg får tilgang til testene. Gitt at jeg er en testtaker som skal logge inn Når jeg logger inn Så skal brukernavn og passord sjekkes mot en database Gitt at jeg er en testtaker som skal logge inn Når brukernavn og passord ikke matcher databasen Så skal jeg få en beskjed som sier at brukernavn og/eller passord er feil Gitt at jeg er en testtaker som skal logge inn Når brukernavn og passord matcher databasen Så er min identitet verifisert og jeg får tilgang til å se statistikk og ta tester Gitt at jeg er en testtaker som har logget inn Når jeg har fulgt en link til en test Så skal jeg få tilgang til å ta testen Side 23

Gitt at jeg er en testtaker som har logget inn Når jeg har logget inn fra hovedsiden Så skal jeg komme til "min side" Logge ut Som testtaker Skal jeg kunne logge ut, Slik at andre ikke skal kunne misbruke kontoen min. Gitt at jeg er en testtaker som har logget inn Når jeg velger "logg ut" Så skal sesjonvariable og cookies slettes og jeg blir logget ut A.2 Administrator Gitt at jeg er en administrator som har logget inn Når jeg trykker "test-del" Så skal jeg få en en meny med valgene "lag-, oppdater-, fjern-, importer-, eksporter test" samt "testliste" Gitt at jeg er en administrator som har valg "test-del" Når jeg trykker på "testliste" Så skal jeg få en liste over alle testene i systemet med linker videre til teststatistikk. Importere fra QTI Skal jeg kunne importere en test fra en fil i formatet IMS QTI Slik at den blir lagret i databasen og testtaker kan ta den. Gitt at jeg er en administrator som har valgt "test-del" Når jeg trykker på "importer test" Så skal innholdet lastes inn i de riktige tabellene i databasen Eksportere fra QTI Skal jeg kunne eksportere en test fra databasen til en fil i formatet IMS QTI Slik at testen kan utveksles med andre systemer. Gitt at jeg er en administrator som har valgt test Når jeg trykker på "eksporter test" Så skal testens data kopieres fra databasen til en fil i formatet IMS QTI. Statistikk Skal jeg kunne velge en test og få en oversikt over hvilke personer som har tatt testen, samt poengsummen personen fikk Side 24

Slik at jeg får vite hvilke personer som har (ikke)har verifisert seg på området testen definerer Gitt at jeg er en administrator som har valgt en test Når jeg trykker vis personer som har tatt testen Så skal det skrives ut en liste over personer, som en lenke til info om personen, og poengsummen han fikk. Statistikk Skal jeg kunne velge en testtaker og få en oversikt over hvilke tester personen har tatt, samt poengsummen personen fikk Slik at jeg får vite hvilke områder personen er internsertifisert. Gitt at jeg er en administrator som har logget inn Når jeg velger en bruker Så skal jeg få en liste over alle testene brukeren har tatt, og poengsummen han fikk. Statistikk Skal jeg kunne velge en test fra listen med tester som er lagt inn i systemet Slik at jeg kan få utdypende info om testen. Gitt at jeg er en administrator som har logget inn Når jeg velger en test for å få informasjon om den Så skal jeg få url-en til testen, gjennomsnittscore, hvilke spørsmål den har, antall tatt. Tidsbegrensning Skal jeg kunne bestemme hvor lang tid en person kan bruke på en test, Slik at verifiseringen nøyaktig etter testslutt. Gitt at jeg er en administrator Når jeg lager en test Så skal jeg kunne skrive inn hvor lang tid man kan bruke på en test Gitt at jeg er en testtaker som tar en test Når tiden har gått ut før jeg har levert besvarelsen Så skal de spørsmålene jeg har svart på telle Antallsbegrensning Skal jeg kunne velge om en test kan taes én eller uendelig mange ganger Slik at man får eksamener og test-tester. Gitt at jeg er en testtaker som tar en test som er antallsbegrenset Side 25

Når jeg har levert besvarelsen Så skal det bli registrert at jeg har tatt testen så jeg ikke kan ta den på nytt. Lage spørsmål Skal jeg kunne lage spørsmål Slik at jeg kan velge hvilke spørsmål en test skal inneholde og så spørsmålene kan brukes om igjen. Gitt at jeg er en administrator som har logget inn Når jeg har laget et spørsmål med svaralternativer Så skal spørsmålet lagres i databasen så jeg kan bruke det i en test. Svaralternativer Skal jeg kunne lage maks et fast antall svaralternativer til hvert spørsmål Slik at omfanget til oppgaven ikke blir for stort. Gitt at jeg er en administrator som har logget inn Når jeg lager en test Så skal jeg kunne skrive inn fem svaralternativer. Det er kun webgrensesnittet som begrenser hvor mange svaralternativer man kan lage. Lage test Skal jeg kunne lage en ny test ved å fylle inn et form. Ferdige spørsmål velges fra databasen, eller nye opprettes ved å trykke "nytt spørsmål." Slik at testtaker kan ta den. Gitt at jeg er en administrator som skal lage en test Når jeg velger "ny test" Så skal jeg få et neste->neste->neste-> grensesnitt. Første side har en form med navn osv. Side to kan ha et grensesnitt for å legge til spørsmål. Velge spørsmål Skal jeg kunne velge hvilke spørsmål fra databasen den nye testen skal ha Slik at samme spørsmål kan brukes flere ganger i forskjellige tester. Få adresse til test Skal jeg få en "public" URL til testen etter at den er opprettet Slik at testtakere kan ta den uten å få informasjon om hvilke tester som er lagt inn (som man får ved å velge test fra en liste). Side 26

Gitt at jeg er en administrator som har lager en test Når jeg har lagret testen Så skal jeg få en adresse til testen, som jeg kan gi til testtakere, skrevet ut til skjermen Oppdatere test Skal jeg kunne oppdatere/slette eksisterende tester Slik at testene kan vedlikeholdes. Opprette bruker Skal jeg kunne opprette brukere Slik at nye ansatte ta test. Slette bruker Skal jeg kunne slette brukere Slik at bare ansatte/aktive brukere har tilgang. Side 27

B Risikoanalyse Side 28