Student To Student. Studentevalueringssystem. Sara Khelifi s John Abrahamsen s148166

Transkript

1 Student To Student Studentevalueringssystem Sara Khelifi s John Abrahamsen s Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

2 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

3 PROSJEKT NR Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Student evaluerings system, Student2student (s2s) PROSJEKTDELTAKERE Sara Khelifi s John Abrahamsen s DATO ANTALL SIDER / BILAG 109 INTERN VEILEDER Emine Göcmenoglu OPPDRAGSGIVER Høgskolen i Oslo, Avdeling for ingeniørutdanning KONTAKTPERSON Thor E.Hasle SAMMENDRAG Oppgaven går ut på å lage et studentevalueringssystem der studenter kan gå inn å evaluere hverandres arbeid. Applikasjonen skal være nettbasert, åpen kildekode og fri for bruk. Det har også blitt gjort en vurdering om det tidligere systemet Mefisto, og om det finnes kommersielle systemer som har den funksjonaliteten oppdragiver ønsker. Peer review går ut på at elever vurderer hverandres oppgaver. Student to student bærer likheter til prinsippet i peer-to-peer, som er klient til klient fildeling på nett, s2s er det samme bare man deler arbeid med retting av skolearbeid og ikke filer. I teorien skal et slikt system lette mengden arbeid som studentassistenter og lærer må gjøre når de skal vurdere elevene sine. Det er blitt utviklet en web-løsning med en backend programmert med PHP, MySQL og Javascript. Dreamweaver har blitt brukt som utviklingsverktøy. 3 STIKKORD Studentevaluering Opensource LAMP Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

4 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

5 Forord Denne sluttrapporten innholder informasjon som har blitt produsert i forbindelse med hovedprosjekt våren 2010 for ingeniøravdelingen i Høgskolen i Oslo. Gruppen har bestått av to studenter fra linjen anvendt datateknologi. Rapporten består av flere delrapporter som kan leses uavhengige av hverandre, for en fullstendig forståelse av hele rapporten burde den leses sammenhengende. Vi gjør oppmerksom på at det kan forekomme gjentagende innhold i rapporten slik at del rapportene kan leses uanvhengige av hverandre. Rapporten innholder prosjektets arbeid, prosessgjenomførelsen og beskrivelse av produktet. Videre vil vi tro at det ikke trengs noe data kunnskaper for å sette seg inn i dette dokumentet, med unntak av produktrapporten. Rapporten er tilgjengelig på prosjektets hjemmeside // og alle del rapportene kan man finne der. Prosjektets dagbok er ikke med i rapporten men er tilgjengelig på prosjektets hjemmeside. Oslo den 29.Mai 2010 Sara Khelifi John Abrahamsen Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

6 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

7 Innhold Rapporten består av følgende delrapporter: Styringsdokumenter: 1. Forprosjekt 2. Kravspesifikasjon 3. Arbeids og Fremdriftsplan Prosess og produktdokumentasjon: 1. Prosessrapport 2. Produktrapport 3. Brukermanual 4. Testrapport Vedlegg: 1. Usecase modell 2. ER-modell 3. Brukernavn og passord for testing 4. CD med applikasjon og kildekode Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

8 Styringsdokumenter Studentevalueringssystem Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

9 Forord Dette er en samling av alle styringsdokumentene gjennom prosjekt perioden. Styringsdokumentene er satt opp i rekkefølge i forhold til perioden de ble levert inn. Dokumentene ble levert inn på følgende datoer: Dokumenter: 1. Statusrapport Prosjektskisse Forprosjekt Prosjektrapport Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

10 Innholdsfortegnelse Forord 9 1 Statusrapport 11 2 Prosjektskisse 12 3 Forprosjektrapport Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Løsninger Analyse av løsninger Konklusjon 16 4 Arbeidsplan 17 5 Fremdriftsplan 20 6 Kravspesifikasjon Innledning Innledning Om bedriften Bakgrunn for prosjektet Forord Forord Systemkrav Funksjonskrav Datalagring Krav Til Design Dokumentasjon 24 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

11 1 Statusrapport Levert Gruppen John og Sara s hovedprosjekt 2010 ( har bestemt seg for å jobbe sammen på hovedprosjektoppgaven. Vi har ikke til nå fastslått en prosjektoppgave som det er lagt frem en skisse av, men vi har kontaktet oppdragsgiver og venter på svar. Oppdragsgiver vi har kontaktet: HiO, Thor E.Hasle Visning av romfordeling HiO, Thor E.Hasle Peer Evaluation HiO Visning av romfordeling: Ingeniørutdanningens ledelse har ytret ønske om å etablere skjermer i hver etasje som viser hvilke rom som brukers av hvem når. Det må da utvikles en applikasjon som leser data fra TimeEdit og som viser disse på en hensiktsmessig måte på en eller flere skjerm per etasje. Hva ønsker vi: Vi ser på disse prosjektene med hensyn til hvilke fordeler vi får ved å velge en oppgave i forhold til en annen. Vi legger stor vekt på veiledning fra oppdragsgiverens side. Vi har enda ikke hatt møte med kontaktpersonen i HiO men vi har sendt en e-post med søknad hvor vi har utrykket vår sterke ønske om å jobbe med deres emne i hovedprosjektet. Vi håper også å komme I kontakt med flere bedrifter etter hvert. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

12 2 Prosjektskisse Sted og dato: Oslo, 4.desember Tittel: Studentevalueringssystem Gruppemedlemmer: John Abrahamsen, Sara Khelifi Oppdragsgiver: Høgskolen I Oslo Pb 4 St. Olavs plass, 0130 Oslo, tlf E-post: tor.krattebol@iu.hio.no Kontaktperson: Thor E.Hasle Epost: thor.hasle@iu.hio.no Tlf: Bedriften: Ingeniørutdanningens ledelse ønsker å forbedre mulighetene for Peer Evaluation (klassefelle vurdering/det at studentene evaluerer hverandres arbeid). For å kunne gjøre slike evalueringer effektive trengs datateknisk utstyr. En mulighet kan være å videreutvikle det allerede eksisterende Mefisto. En annen mulighet er å kjøpe inn ferdig programvare. En siste mulighet er å utvikle noe selv. Oppgaven går ut på å vurdere mulige dataløsninger og evt. implementere disse. Prosjektet: HiO benytter seg ikke av det eksisterende systemet Mefisto, en av årsakene er at brukergrensesnittet er svært dårlig og at det ikke er implementert i fronter gjør det også litt vanskelig. Det er hovedsakelig tre viktige oppgaver som skal løses, en av arbeidsoppgavene vi skal ta for oss er å vurdere om det eksisterende systemet kan brukes eller modifiseres. Den andre oppgaven er å vurdere muligheten for komersielle systemer. Den siste oppgaven er å vinkle prosjektet mot å utvikle en egen løsning som kan tilfredstille oppdragsgiverens krav. Vi har hovedsakelig fokusert på siste oppgave. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

13 3 Forprosjektrapport 3.1 Presentasjon Tittel: Student evalueringssystem, Student-to-student (S2S) Oppgave: Utvikle et evalueringssystem for HiO (Høgskolen i Oslo), der studenter evaluerer hverandre. Periode: 5. januar til 29. Mai Gruppemedlemmer: Sara Khelifi (ANV), John Abrahamsen (ANV) Prosjektgruppe: 41 Veileder: Thor E.Hasle/Emine Göcmenoglu Oppdragsgiver: Høgskolen i Oslo Kontaktperson: Thor E.Hasle 3.2 Sammendrag Prosjektet skal gjennomføres som hovedprosjekt for HiO. Prosjektet undersøker om det kan utvikles et evalueringssytem for HiO der studenter evaluerer hverandres oppgaver. Applikasjonen skal være nettbasert, åpen kildekode og fri for bruk. Hva er Peer review? Peer review går ut på at elever vurderer hverandres oppgaver. Peer review bærer likheter til prinsippet i peer-to-peer, som er klient til klient fildeling på nett, peer review er det samme bare man deler arbeid med retting av skolearbeid og ikke filer. I teorien skal et slikt system lette mengden arbeid som studentassistenter og lærer må gjøre når de skal vurdere elevene sine, slik at man frigjør ressurser. Vi ser for oss en web-løsning uten begrensninger til hvilken platform man måtte bruke. Illustrasjonsfigur for vårt system. 3.3 Om bedriften Høgskolen i Oslo er landets største statlige høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og 18 masterstudier. En så stor utdanningsinstitusjon med så mange studenter krever mye av lærere og studentassistenter så et slikt evaluerings system vil definitivt være med å lette de ansattes hverdag på en positiv måte. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

14 3.4 Dagens situasjon I dag er det veldig ressurskrevende å få gjort vurdering av elevarbeid. Studenter benytter seg av skolens student portal, Fronter, for å levere inn arbeid for vurdering. Ingenting er automatisert, så det er lærere og studentassistenter som får oppgaven med å gå inn på Fronter å vurdere alt arbeid gjort av studenter. Karakterer eller bestått/ikke bestått settes inn sammen med kommentarer på Fronter så studenter kan lese tilbakemeldingen. Fronter er et bra system, men det har ingen funksjon for å muliggjøre "Peer review" som vi beskriver det. Med tanke på hvor mange studenter som studerer på HiO kan man tenke seg til at det er mye ressurser som kan frigjøres ved å kunne designe ett slikt system. Dagens situasjon illustrert Skolen har selv ytret ønske om å kunne lette arbeidsmengden ved å la studenter være delaktig i vurdering av hverandres arbeid. Ingeniøravdelingen har utviklet ett system, kalt Mefisto, som har blitt brukt i mindre grad. Etter samtaler med en av utviklerne kommer det frem at systemet var for vanskelig og tidskrevende å benytte seg av når det ble lansert. Bruken av systemet ble for teknisk avansert for andre enn de som hadde vært med å utviklet det. Systemet har ikke noe grensesnitt og måtte kodes om for hver gang det skulle brukes til noe. Forøvrig var peer review bare en av funksjonene i Mefisto, og ikke den som var "mest utviklet" av de alle. En av ønskene til oppdragsgiveren er at vi skal vurdere om Mefisto kan videreutvikles eller brukes som utgangspunkt for utvikling av en ny applikasjon. Mefisto ble bare brukt i IU-avdelingen på HiO. 3.5 Mål og rammebetingelser De sentrale mål for systemet er hovedsakelig det som kreves for at systemet skal fungere riktig i forhold til miljøet og arbeidsplassen. Systemet bør: gjøre det mulig for studenter å vurdere hverandres arbeid. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

15 gi vurderinger som er troverdige og kan benyttes som at de er riktige, dvs. at det ikke skal være mulighet for fusk. være trygt nok til at man ikke kan bryte seg inn å legge inn falske resultater. holde orden på hvem som har tilgang til å rette oppgaver og at den som har rettet en oppgave ikke har rett til å rette samme oppgave igjen. opprettholde personvernet til den enkelte. være 100% nettbasert. være åpen kildekode og fritt tilgjengelig. Funksjonalitet som kan implementeres er: varsel på /sms når du skal evaluere en oppgave, eller har mottat resultater. Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere applikasjonen. Vi står også fritt til å velge hvilken grad applikasjonen skal være ferdig utviklet. I utgangspunktet tenker vi i arbeidsgruppen at vi må modellere/beskrive systemet 100% og minst lage en proof-of-concept applikasjon. Gruppen planlegger å bruke PHP som programmeringspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web-løsninger. Uansett kan man jo tilpasse applikasjonen relativt enkelt til å benytte annen database programvare. 3.6 Løsninger Når det gjelder denne løsningen har vi flere ting å vurdere. Vi kan benytte oss av en ren webapplikasjon, eller så kan vi lage en "stand-alone" applikasjon. Eller en hybrid hvor de som skal administrere kan benytte en applikasjon. Ett problem som ofte oppstår da er at man ønsker at applikasjonen skal fungere på tvers av forskjellige platformer, og man må så lage flere versjoner. Det mest hensiktsmessige vil derfor å lage en 100% web-basert løsning, fordelen med dette er jo det at man har hele systemet tilgjengelig når som helst og hvor som helst. I tillegg er det enkelte språk vi er bedre kjent med enn andre, og som egner seg godt til å løse oppgaven. Derfor ser vi for oss per i dag at vi kommer til å bruke følgende verktøy/teknologier: Teknologi: PHP Hypertext Preprocessor Utviklingsprogram: Coda (for Mac), Dreamweaver, MySQLWorkbench, RazorSQL, GIMP/Adobe Photoshop (grensesnitt). Database: MySQL (fri programvare) Programmeringspråk: XHTML, CSS, PHP, SQL, Javascript Miljø for testing: Apache, PHP og MySQL driftes på en virtuell Debian Linux maskin fra HiO. Programvare for modellering og planlegging: Microsoft Visio 2007, Microsoft Project Proffesional Analyse av løsninger Vi har valgt å benytte PHP for å lage applikasjonen vår fordi vi har god kunnskap til dette språket og det er veldig utbredt, samt at det er enkelt og greit å programmere med. Det krever heller ingen spesiell programvare for å kodes med. Vi skal bruke Coda for å programmere PHPen vår. MySQL setninger vil bli konstruert i MySQLWorkbench, som også er fritt tilgjengelig. Grafikken vil gjøres i GIMP eller Photoshop. Testing og produksjon av applikasjonen vil gjøres på en virtuell maskin på skolen. Tilgjengelig kun for oss. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

16 3.8 Konklusjon Målet med prosjektet våres er å: Undersøke om peer review er praktisk gjennomførbart. Forenkle hverdagen for de som jobber som lærere og studentassistenter ved å minske "plankekjøringsarbeid". Frigjøre ressurser som kan brukes på andre og mer nyttige saker. Produsere ett open-source bidrag for studentevaluering. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

17 4 Arbeidsplan Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

18 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

19 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

20 5 Fremdriftsplan Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

21 6 Kravspesifikasjon 6.1 Innledning Innledning Vi har kommet frem til at vi vil utvikle vår egen applikasjon for å løse oppdraget. Applikasjonen ble døpt s2s Student to Student. Navnet kommer fra peer to peer fildeling, men at man deler oppgaver og ikke filer. Prosjektet skal gjennomføres som hovedprosjekt for HiO. Prosjektet går ut på å utvikle et evalueringssytem for HiO der studenter evaluerer hverandres oppgaver. Applikasjonen skal være nettbasert, åpen kildekode og fri for bruk. 6.3 Om bedriften Høgskolen i Oslo er landets største statlige høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelorstudier og 18 masterstudier. En så stor utdanningsinstitusjon med så mange studenter krever mye av lærere og studentassistenter så et slikt evaluerings system vil definitivt være med å lette de ansattes hverdag på en positiv måte. 6.4 Bakgrunn for prosjektet I dag er det som påpekt over veldig ressurskrevende å få gjort vurdering av elevarbeid. Studenter benytter seg av skolens student portal, Fronter, for å levere inn arbeid for vurdering. Ingenting er automatisert, så det er lærere og studentassistenter som får oppgaven med å gå inn på Fronter å vurdere alt arbeid gjort av studenter. Karakterer eller bestått/ikke bestått settes inn sammen med kommentarer på Fronter så studenter kan lese tilbakemeldingen. Fronter er et bra system, men det har ingen funksjon for å muliggjøre "peer review" som vi beskriver det. Med tanke på hvor mange studenter som studerer på HiO kan man tenke seg til at det er mye ressurser som kan frigjøres ved å kunne designe ett slikt system. Skolen har selv ytret ønske om å kunne lette arbeidsmengden ved å la studenter være delaktig i vurdering av hverandres arbeid. Ingeniøravdelingen har utviklet ett system, kalt Mefisto, som har blitt brukt i mindre grad. Etter samtaler med samtlige utviklere av Mefisto kommer det frem at systemet var for vanskelig og tidskrevende å benytte seg av når det ble lansert. Bruken av systemet ble for teknisk avansert for andre enn de som hadde vært med å utviklet det. Systemet har ikke noe grensesnitt og måtte kodes om for hver gang det skulle brukes til noe. Forøvrig var peer review bare en av funksjonene i Mefisto, og ikke den som var "mest utviklet" av de alle. En av ønskene til oppdragsgiveren er at vi skal vurdere om Mefisto kan videreutvikles eller brukes som utgangspunkt for utvikling av en ny applikasjon. Mefisto ble bare brukt i IU-avdelingen på HiO. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

22 6.5 Forord Forord Denne kravspesifikasjonen beskriver betingelsene for student to student. Krav til funksjonalitet og rammebetingelser er beskrevet i dette dokumentet. Hovedkravene om funksjonalitet er gitt av Oppdragsgivern, mens hvordan det spesifikt og best mulig skal løses har gruppa styrt selv. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

23 6.6 Systemkrav Funksjonskrav Krav til evalueringssystem 1. Studenter skal kunne rette hverandres arbeid. 2. Studenter skal kunne gi en vurdering og karakter. 3. Systemet bør holde orden på hvem som har tilgang til å rette oppgaver og at den som har rettet en oppgave ikke har rett til å rette samme oppgave igjen. 4. Være nettbasert. Alt gjøres på nettet og ingen klient programvare kreves. 5. Ha en beskyttelse mot utryggheter som sql injections, ved bruk av SSL. motta varsel på e-post når en oblig er rettet Krav til Administrasjon 1. Logge inn/ut Admin skal kunne logge inn og logge ut. 2. Legge til bruker 3. Tildele kurs til lærer 4. Tildele kurs til studentassistent 5. Legge til kurs 6. export/import Import av elevdata fra student databsen. 4. Slette bruker Krav til lærer/studentassistent 1. Logge inn/ut Studentassistenter og lærere skal kunne logge inn. 2. Velge evaluerings type for oppgave godkjent/ikke godkjent eller karakter 3. Laste opp oppgaver 4. Åpne den tildelte oppgaven 5. Se resultater Krav til student 1. Logge inn/ut Logge inn ved bruk av studentnummer og passord som man har fått tildelt av skolen. 2. Laste opp egen oppgave Sende inn oppgave Oppgaven blir sendt til S2S databasen. 3. Se resulateter 4. Åpne den tildelte oppgaven. 5. Vurdere andres arbeid, legge inn kommentar og karakter/godkjent ikke godkjent. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

24 6.6.6 Tekniske krav 1. Teknologi: PHP Hypertext Preprocessor 2. Utviklingsprogram: Coda (for Mac), Dreamweaver, MySQWorkbench, GIMP/Adobe Photoshop (grensesnitt),razor UML 3. Database: MySQL (fri programvare) 4. Programmeringspråk: XHTML, CSS, PHP, SQL, Javascript 5. Miljø for testing: Apache, PHP og MySQL driftes på en virtuell Debian Linux maskin fra HiO. 6. Programvare for modellering og planlegging: Microsoft Visio 2007, Microsoft Project Proffesional Argo UML, Violet UML Datalagring Krav til datalagring 1. Data som sendes/lagres i en Mysql database. 2. Det skal være krav for input validation, slik at det ikke er sårbart for sql injections. 3. Det skal være bygd opp etter normaliserings krav. Dobbelt lagring må ikke forekomme. 6.8 Krav til design Generelle design mål 1. Brukergrensesnittet skal være brukervennlig og enkelt å forstå. 2. Det skal være slik at brukere intuitivt forstår hvordan systemet skal brukes, i stedet for at opplæring eller brukermanualer trengs (men vi vil uansett lage en brukerveiledning). 3. Det skal være mest mulig brukervennlig og universelt utformet slik at de med svekket syn skal klare å navigere i siden. 4. Utskriftsvennlig 5. Mulighet for navigering rundt i siden: Brødsmuler, Frem/tilbake/home knapper. 6. søkefunksjonalitet 7. Mulighet for Engelsk oversettelse til utlandske studenter. 6.9 Dokumentasjon Krav til dokumentasjon Det skal i prosjektperioden bli satt opp en nettside for gruppen, der skal det føres dagbok over hva som blir gjort, hvilke utfordringer vi møter og hvordan disse blir løst. Det ferdige prosjektrapporten skal dokumenteres med: Forprosjekt Prosessrapport Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

25 Produktrapport Kravspsifikasjon Testrapport Brukermanual Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

26 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

27

28 Prosessrapport Studentevalueringssystem

29 1 Forord 1.2 Forord Denne prosessrapporten forteller om gruppens samarbeid og metoder benyttet for hovedprosjektet ved Høgskolen i Oslo avdeling for ingeniørutdanning, anvendt datalinjen, vårsemesteret Medlemmer bak S2S student to student er John Abrahamsen og Sara Khelifi. Rapporten er beregnet for sensor, veileder, oppdragsgiver og andre som har interesse av å sette seg inn i utfordringer, løsninger på disse og arbeidsmetoder i prosjektet. Det blir i rapporten gjort rede for samsvaret mellom sluttproduktet i forhold til kravspesifikasjonen. Det kreves ingen spesiell datakompetanse for å sette seg inn i denne rapporten. Dokumentet er optimalisert for papirutskrift. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

30 Innholdsfortegnelse 1 Forord Forord 29 2 Innledning Om bedriften Dagens situasjon Mål Rammebetingelser 32 3 Planlegging Generelt Fremdriftsplan og arbeidsplan 33 4 Utviklingsprosessen Fasene i prosjektet Kompetansetilegning Programmering Testing Utfordringer i prosjektperioden 38 5 Kravspesifikasjonen Generelt Endringer i Kravspesifikasjonen Kravspesifikasjonens rolle under design og implementasjon Kravspesifikasjonen i dag Avvik 40 6 Oppsummering Produktet Prosessen 41 Kilder 42 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

31 2 Innledning 2.1 Om bedriften Høgskolen i Oslo er landets største statlige høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelor studier og 18 masterstudier. En så stor utdanningsinstitusjon med så mange studenter krever mye av lærere og studentassistenter så et slikt evaluerings system vil definitivt være med å lette de ansattes hverdag på en positiv måte. Foreløpig vil systemet være fokusert på datastudenter og vil ikke omfatte alle avdelinger i Høgskolen i Oslo. 2.2 Dagens situasjon Som situasjonen er i dag så er det veldig ressurskrevende å få gjort vurdering av elevarbeid. Studenter benytter seg av skolens student portal, Fronter, for å levere inn arbeid for vurdering. Ingenting er automatisert, så det er lærere og studentassistenter som får oppgaven med å gå inn på Fronter å vurdere alt arbeid gjort av studenter. Karakterer eller bestått/ikke bestått settes inn sammen med kommentarer på Fronter så studenter kan lese tilbakemeldingen. Fronter er et bra system, men det har ingen funksjon for å muliggjøre "peer review" som vi beskriver det. Med tanke på hvor mange studenter som studerer på HiO kan man tenke seg til at det er mye ressurser som kan frigjøres ved å kunne designe ett slikt system. Figur 1 Dagens Løsning illustrert. Skolen har selv ytret ønske om å kunne lette arbeidsmengden ved å la studenter være delaktig i vurdering av hverandres arbeid. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

32 Figur 2 Ønsket løsning. Ingeniøravdelingen har utviklet ett system, kalt Mefisto, som har blitt brukt i mindre grad. Etter samtaler med samtlige utviklere av Mefisto kommer det frem at systemet var for vanskelig og tidskrevende å benytte seg av når det ble lansert. Bruken av systemet ble for teknisk avansert for andre enn de som hadde vært med å utviklet det. Systemet har ikke noe grensesnitt og måtte kodes om for hver gang det skulle brukes til noe. Forøvrig var peer review bare en av funksjonene i Mefisto, og ikke den som var "mest utviklet" av de alle. En av ønskene til oppdragsgiveren er at vi skal vurdere om Mefisto kan videreutvikles eller brukes som utgangspunkt for utvikling av en ny applikasjon. Mefisto ble bare brukt i IU-avdelingen på HiO. 2.3 Mål De sentrale mål for systemet er hovedsakelig det som kreves for at systemet skal fungere riktig i forhold til miljøet og arbeidsplassen. Systemet bør: gjøre det mulig for studenter å vurdere hverandres arbeid. gi vurderinger som er troverdige og kan benyttes som at de er riktige, dvs. at det ikke skal være mulighet for fusk. være trygt nok til at man ikke kan bryte seg inn å legge inn falske resultater. holde orden på hvem som har tilgang til å rette oppgaver og at den som har rettet en oppgave ikke har rett til å rette samme oppgave igjen. opprettholde personvernet til den enkelte. være 100% nettbasert. være åpen kildekode og fritt tilgjengelig. Funksjonalitet som kan implementeres er: varsel på /sms når du skal evaluere en oppgave, eller har mottat resultater. 2.4 Rammebetingelser Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere applikasjonen. Vi står også fritt til å velge hvilken grad applikasjonen skal være ferdig utviklet. I utgangspunktet tenker vi i arbeidsgruppen at vi må modellere/beskrive systemet 100% og minst lage en proof-of-concept applikasjon. Gruppen planlegger å bruke PHP som programmeringsspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web-løsninger. Uansett kan man jo tilpasse applikasjonen relativt enkelt til å benytte annen database programvare. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

33 3 Planlegging 3.1 Generelt Gruppesammensetning var klar en god stund før prosjektoppgaven, noe som gjorde det enklere å begynne med prosjekt søket. Gruppen har samarbeidet tidligere og vet hvor hver av dem står i forhold til den enkeltes kompetanse nivå. Planleggingen av prosjekt søket startet så fort vi fant et prosjekt som passet en gruppe på to. Vi ble raskt interessert i peer review og tok kontakt med oppdragsgiveren. Dermed fikk vi ansvaret for å utvikle et student evalueringsystem. Vi opprettet etter hvert en blogg side fordi vi fant ut at det er mye enklere og legge ut innlegg som en slags dagbok. Det vil gjøre det lettere for veileder og kontaktperson å følge med. Til å begynne med var det meget viktig og finne ut definisjonen av peer review før man kunne gå videre med å sette opp planlegging av prosjektet. Deretter ble det satt opp flere møter med oppdragsgiveren for å avklare kravene under planleggingsfasen. Dette ble gjort med god kvalitet og minimaliserte behovet for avklaringer senere i prosjektet. Det var hyppige møter med veileder som skulle holde orden på at vi kom oss videre og at vi leverte resultater for hver uke. Det var viktig å finne ut hva det tidligere systemet sto for og hvorfor det ikke er i bruk i dag. Det var også lurt å undersøke om hvilke muligheter det fantes der ute av kommersielle systemer. Dette vil hjelpe oss vurdere om hva som lønner seg best for HiO. Det er begrenset med ressurser derfor var det viktig at systemet skulle være webbasert. Vi satte også fokus på å utvikle ett godt brukergrensesnitt med god brukervennlighet, noe som oppdragsgiveren ytret ønske om. 3.2 Fremdriftsplan og arbeidsplan Fremdriftsplanen ble satt opp tidlig i prosjektet. Sammen med denne ble det også utarbeidet en overordnet arbeidsplan. Begge disse dokumentene har blitt brukt aktivt gjennom hele prosjektgjennomføringen, de finner man under styringsdokumenter i slutt rapporten. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

34 4 Utviklingsprosessen 4.1 Fasene i prosjektet Forprosjekt Vi har vært heldige om samarbeidet med oppdragsgiver, det ble aldri satt noen krav om hvordan vi skulle jobbe og hva slags prosjektstyringsmetode som skulle brukes. Dette ga oss friheten til å gjøre som vi ville i forhold til prosjekt styring. Gruppen besto kun av to medlemmer dermed var det naturlig å følge en iterativ utvikling. Årsaken var at vi ikke trengte noen spesiell styring ettersom oppgavene var relativt lette å fordele. Vi har kommunisert hele veien og samarbeidet tett med faste møter på skolen og jobbet jevnt med å holde hverandre oppdatert. I starten av prosjektet var det veldig viktig å sette seg inn i dagens situasjon og hvordan Mefisto fungerte tidligere derfor var det gjort grundig forarbeid om det i forprosjektet. Det ble gjort et møte med Mark Burgess en tidligere HiO professor, grunder av CFEngine, og utvikler av Mefisto. Møtet var meget informativt og en del ukjent fakta kom frem. Oppdragsgiveren hadde noen funksjonelle krav og et ønske om å undersøke og trekke konklusjoner om hva som lønner seg best i forhold til videreutvikle Mefisto, vurdere et kommersielt system eller skape noe nytt. Så en liten evaluering måtte man komme med, ellers sto vi fritt til å velge hvordan vi skulle løse dette teknisk. Gruppen var enig om at miljø for testingen driftes på en virtuell Debian Linux maskin fra HiO. Teknologien som skal brukes er PHP Hypertext Preprocessor, database Mysql, med en blanding av programmeringsspråk som PHP, SQL og Javascript. Etter samtaler med samtlige lærere så var vi alle enige om at et brukervennlig grensesnitt er et fokus i og med at det forrige systemet ikke hadde noe som helst brukergrensesnitt. Dette er også et noe av det vi har som mål innenfor de rammebetingelser vi har satt opp i kravspesifikasjonen Mefisto Mefisto ble utviklet for ti år siden av Mark Burgess daværende foreleser ved IU avdelingen på Høgskolen i Oslo. En innebygget del av dette systemet var Peer Review der studenter la inn poeng for hver oppgave og systemet tok da en full poengberegning. Programmet ble utviklet med tanke på at det skulle lette hans arbeid for retting av oppgaver. Studenter skulle i grupper gå inn og signere en obligatorisk oppgave, de fikk da et passord og brukernavn og de måtte logge seg inn alle samtidig innen et tidspunkt. Dette fungerte i en tid hvor Fronter ikke eksisterte dermed var det genialt men ganske knotete. Det ble senere utviklet videre av Hårek Haugerud og brukt til flervalgs tester (Multiple choice Test) og dette fungerte helt greit. Problemet var at det ble kun brukt av få, de som forstår seg på PHP programmering, det hadde ikke noe brukergrensesnitt. Mefisto har ikke oppdatert seg siden og ingen har tatt arbeidet videre. Systemet er for komplisert uten noe som helst brukergrensesnitt noe som gjør det vanskelig å jobbe med videre. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

35 Figur 3 Peer Review Løsning Peer Review En fordel med peer review ordningen er at elevene ikke bare skriver egne oppgaver, men lærer også mye av å rette andres arbeid. Studenten for innsyn i hverandres besvarelser og lar dem reflektere over mulige måter å bli bedre på. Dette vil gi studenten en betydelig karakter belønning ved å se andres perspektiver og lære mer i motsetning til den tradisjonelle måten. Denne måten å arbeide på oppfordrer studenter til å revurdere sin egen ytelse basert på hva de har sett. Dette er et viktig fundament for Peer review mener Mark Burgess fra rapporten Security and online student evaluation with large classes (Burgess.M.2003[1]). I følge rapporten av Mark Burgess så var studentene i Høgskolen i Oslo fornøyd med peer review, de var fornøyd med å evaluere hverandres arbeid å bli evaluert av studenter, men noen var skeptiske for å bli vurdert av studenter og viste usikkerheter til å la andre studenter evaluere. Mange tenkte at ikke alle studenter ville være troverdige under evalueringen slik en sensor ville ha vært. Det som undervurderes er at ikke alle studenter forstår at de har opparbeidet seg bedre karakterer. Ved å se på hvordan andre har løst oppgaver og som nevnt ovenfor revurdere sitt ytelse basert på hva de har sett. Dette er også noe av grunnlaget vi har basert utviklingen av s2s på, nemlig å lette foreleserens arbeid, men studenten vil også komme bedre ut av dette i forhold til kunnskaps tilegnelse og opparbeidelse av karakter,altså en vinn - vinn situasjon. 4.2 Kompetansetilegning På Høgskolen i Oslo, avdeling for ingeniører, har studentene hatt fag som MySQL og PHP igjennom faget Databaser og Webprogrammering som kjøres i første og andre året. Disse fagene har hele veien vært meget relevante både til eksamen og andre prosjekt oppgaver derfor har vi hele veien tatt til betraktning disse fagene og prioritert de høyt. Noe som nå kommer til godt bruk med på hovedprosjektet. Oppdragsgiver framsatte ikke krav om hvilken teknologi vi skulle bruke, men det var ingen tvil om at dette Mysql og Php skulle bli tatt i bruk. Dette er verktøyer som i dagens utviklings miljø blir brukt mer og mer sammen i utvikling av databasesystemer. Gruppen satte seg som mål å lære seg bruk av disse på et relativt høyt nivå gjennom utviklingen av systemet, slik at vi tilslutt kunne presentere et kodemessig solid system. Da gruppen kun bestod av to medlemmer, ble det gjort slik at den ene som hadde bedre programmerings kunnskaper var den som sto for programmerings biten, mens det andre gruppe Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

36 medlemmet fokuserte på modellering, design og rapportering. Det ble brukt phpmyadmin for oppsett av databasen. Dette gjorde at systemet ble mer oversiktlig og lettere og utvikle underveis, dessuten nyttig for fremtidige oppdatering/ utvikling. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

37 4.3 Programmering Før vi startet med programmeringen av applikasjonen diskuterte vi og modellerte systemet slik vi ville at det skulle se ut, med tanke på funksjonalitet og utforming. Vi brukte ett program som heter Violet UML for å lage use cases og vi lagde klassediagram i ArgoUML. Når vi hadde fått en oversikt over hvilke funksjoner som skulle være med startet vi med å programmere. I og med at vi var to på gruppen delte vi oss og den ene fikk ansvar for å programmere og den andre fikk ansvar for dokumentasjon av prosessen. Dette var en grei inndelig og vi fikk jobbet bra. Selvfølgelig var begge delaktig i utviklingen, ofte når det kom til beslutninger som måtte tas og spørsmål om grensesnitt. I utgangspunktet hadde vi tenkt at applikasjonen skulle bli en proof-of-concept applikasjon, men etter hvert fikk vi forespørsel fra oppdragsgiver om vi kunne noe som kunne brukes i praksis på skolen. Det ble selvfølgelig en mye større arbeidsmengde, men vi var sikre på at vi skulle klare å komme i mål med applikasjonen og resten av prosjektet. Utviklingen ble delt inn i iterasjoner, hvor vi stadig økte og endret funksjonalitet. Det ble hele tiden gjort evolusjoner av eksisterende funksjoner etter hvert som vi programmerte. Det er lettere å ta små steg om gangen enn å sitte med ett stort uferdig produkt som ikke kan brukes til noe, hvertfall når det er en så liten gruppe som jobber. I og med at det ikke er noe kommersielt produkt som er tilgjengelig har alt som er blitt laget vært basert på egne tanker og ideer. Det er vanskeligere å gjøre det enn når man har eksisterende konkurrenter som settes som mål i forhold til funksjoner, utforming osv. 4.4 Testing Å levere et feilfritt system til oppdragsgiver ligger ganske nært til umulig, det vil alltid dukke opp noe. Derfor er det viktig å dokumentere hva som er testet og hvordan, for å lette arbeidet for de som skal vedlikeholde systemet og finne eventuelle feil. Det første som ble testet, var databasen og sql spørringer. Dette testet vi selv uten å bruke testpersoner. Deretter var det GUI som ble testet. Vi utviklet en papir prototype for å først få et bilde av hvordan vi så for oss at grensesnittet skulle være, deretter ble det testet på vanlige brukere. Vi fikk veldig god tilbakemelding, og selv om det ble lagt stor vekt på programmerings biten av databasen og ramme verket så har det ikke vært så mye tid til testing av GUI. Vi tok godt tak i de få tilbake meldingene vi hadde fått og forbedret så godt vi kunne. Testingen var delt i tre forskjellige deler, Administrator delen, student bruker delen og lærer delen. Gruppen valgte en iterativ uvikling av systemet. Dette innebar at systemet ble ferdigstilt modul for modul. En ny modul ble aldri påbegynt før den sist utviklede modulen viste seg å fungere som forventet. I hovedprosjekt blir det som oftest fokusert på funksjonell testing, og vårt prosjekt var intet unntak. Vi startet med såkalt glass-box testing, hvor man bruker kjennskap til koden for å gå igjennom systemet å kjøre tester. Senere når det ble satt mer fokus på at modulene gjorde det de skulle, brukte vi black-box testing, altså matet systemet med testdata for å teste hvilken tilbakemelding det ga. Her trengs ikke kjennskap til koden. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

38 4.5 Utfordringer i prosjektperioden Utviklingsmiljø Det har oppstått en del faglige og tekniske utfordringer underveis men alt har latt seg løse. Vi føler som gruppe at vi sitter igjen med mye kunnskaper rundt dette prosjektet en det vi gjorde til å begynne med. Før vi startet utviklingen jobbet vi med å få skaffe verktøy for å kunne klare jobben så raskt og smertefritt som mulig. For å lage en web-server som var tilgjengelig overalt valgte vi å benytte oss av en virtuell maskin fra skolen. Denne ble satt opp med Ubuntu. Når vi fikk den fra skolen med brukernavn og passord var det en Ubuntu-klient. Vi satt i gang med å konfigurere den etter vårt behov. Vi fjernet det grafiske grensesnittet og alle de unødvendige tjenestene som kjørtes, satt opp en brannmur osv. Når alt var satt opp slik vi ville så installerte vi Apache med php-modul, MySQL og phpmyadmin. Vi konfigurerte så tilgangsrettigheter på Apache og databasen. Til slutt satt vi med en VM som fungerte veldig bra som server. Vi satt også opp en last overvåker (Munin). På nettsiden benyttet vi oss av en rekke programmer for å gjøre utviklingen enklere. Først og fremst brukte vi Dreamweaver for å designe det grafiske grensesnittet til applikasjonen, samt å ha en plass å få en overordnet bilde over alle moduler av applikasjonen. Dreamweaver fungerer veldig bra til å designe grafiske elementer, det vil si CSS og HTML, men gir lite til ingen hjelp når man skal programmere PHP. For å lage ER-diagrammer brukte vi MySQLWorkbench, som er en videreutvikling av MySQL Front. Denne applikasjonen er veldig hendig ettersom den kan brukes til å administrere databaser og veldig mye annet. Vi brukte den til å lage en spørring som kjørtes for å opprette databasen. Den er derimot ikke så veldig bra til å lage SELECT,INSERT og DELETE spørringer. For å gjøre det brukte vi ett program som heter RazorSQL. Dette var til stor hjelp for å lage en del spørringer, de mest avanserte var noe man måtte gjøre frihånd, men det var veldig kjekt med ett program som fort løste de enkle spørringene som å hente en oppgave. Gruppen fikk tildelt et brukernavn og passord for vm som blir brukt i ingeniøravdelingen, dette ga oss et område å serve domenet vårt på. Vi brukte et gratis domenet fra no-ip.org Optimalisering av GUI GUI er viktig. Det er faktisk det eneste brukerne ser av applikasjonen. Derfor er det viktig at både personer og nettlesere forstår applikasjonen. Vi har jobbet en del med universell utforming i kurset vårt. Derfor bør vi få vist at vi kan utforme med tanke på at det ikke skal være vanskelig får mennesker og forstå. Vi skal utføre tester av grensesnittet vårt og gjøre forbedringer etter de innspillene vi får fra testpersoner. En annen ting er at applikasjonen bør helst fungere i de nettleserne som blir mest brukt. Vi tenker da på Internet Explorer, Firefox, Opera, Safari, Google Chrome. Som nevnt må funksjonaliteten være den samme, men den grafiske fremstillingen bør også være så å si den samme uten for mye avvik fra slik det er tiltenkt å fremstå. En god start for å oppnå dette er å få nettsiden godkjent av W3C XHTML validatoren. Vi kommer til å utføre tester med de forskjellige nettleserne samtidig som vi gjør tester av brukergrensesnittet på mennesker. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

39 5 Kravspesifikasjonen 5.1 Generelt Da kravspesifikasjonen skulle utvikles, kontaktet vi oppdragsgiver for å få høre deres ønsker og eventuelle krav de måtte ha til systemet. Dette, i tillegg til våre tanker og ideer, dannet kravspesifikasjonen. Kravspesifikasjonen skal betraktes som en kontrakt mellom prosjektgruppen og oppdragsgiver, men vi var enige om at den ikke skulle stå i veien om vi fikk nye og bedre ideer etter hvert. 5.2 Endringer i Kravspesifikasjonen Første versjon av kravspesifikasjonen ble skrevet i forprosjektfasen. Denne var basert på ønsker vi fikk fra oppdragsgiver, i tillegg til den funksjonalitet gruppen så for seg systemet hadde ved prosjektslutt. Da vi kom ut i planleggingsfasen, ble det tydeliggjort at kravspesifikasjonen var en smule vag på noen områder og enkelte ønsker fra oppdragsgiver var litt utydelige. Gruppen bestemte seg for at kravspesifikasjonen måtte utbedres og det ble avtalt et møte med veileder der det ble utarbeidet en bedre forklaring på hva en kravspesifikasjon skal innholde. Første versjon av kravspesifikasjonen gikk mest ut på å definere minstekrav til systemets funksjonalitet og tekniske krav. I tillegg til dette, inneholdt andre versjon mer spesifikk funksjonalitet, mer krav til hva systemet skulle kunne levere. Andre versjon var også utvidet en del, siden veileder rettet den første versjonen og fant uklarheter. Gruppen var fornøyd med denne versjonen en stund, men da vårt bilde av systemet etter hvert ble klarere og klarere fant vi ut at det vil bli en del avvik i systemet i forhold til kravspesifikasjonen men dette er nødvendigvis ikke noe negativt. Det var nok av klare krav til hva systemets forskjellige komponenter skulle ha av funksjonalitet. Dette ble den endelige versjonen av kravspesifikasjonen. Vi følte at denne versjonen helt og holdent representerte systemet vi skulle utvikle. 5.3 Kravspesifikasjonens rolle under design og implementasjon Vi fikk etter hvert en veldig oversiktelig kravspesifikasjon, som vi kunne forholde oss til under utviklingen av systemet. Første versjon av GUI(papirprototypen) ble utarbeidet på bakgrunn av kravene satt i kravspesifikasjonen. Da et webbasert GUI skulle utvikles, måtte det gjøres noen forandringer. Disse forandringene må sies å være til de bedre for systemet, og til tross forandringer har gruppen aldri gått mot kravspesifikasjonen under utviklingen. I kravspesifikasjonen er det tydeliggjort hvilken funksjonalitet oppdragsgiver og gruppen har ønsket for systemet, og disse har også hatt stor prioritet under utviklingen. Det har hele tiden blitt arbeidet mot denne under implementasjon av kode til systemet. De mest grunnleggende kravene(som logg inn, registrering, sletting) ble implementert først, deretter det vi fant mest viktig. Dette ble gjort i tilfelle at uansett om gruppen hadde tatt seg vann over hodet tidsmessig, ville oppdragsgiver få den mest grunnleggende funksjonalitet på systemet. Kravspesifikasjonen har under hele prosjektperioden vært en fin huskeliste å forholde seg til. Har det vært spørsmål angående funksjonalitet har vi alltid dobbeltsjekket med kravspesifikasjonen. Uten denne har det villet vært svært vanskelig å få fram det resultatet vi har i dag. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

40 5.4 Kravspesifikasjonen i dag Alle punktene i kravspesifikasjonen er ikke oppfylt grunnet tidsmangel og prioriteringer av de forskjellige funksjonaliteter.vi regner med at det blir noe lavere score på enkelte punkter under evalueringen pga av dette. Tross alt er det ikke alt for mye kode som skal til, for å fullføre smutthullene siden databasen er klargjort for alt i kravspesifikasjonen. 5.5 Avvik Det er en del avvik fra kravspesifikasjonen som nevnt ovenfor ikke ble oppfylt enten i systemet elli GUI Avvik i evalueringssystemet 1. Ha avansert beskyttelse mot utryggheter som sql injections. 2. Motta varsel på e-post når en oblig er rettet Avvik i Administrasjonsdelen 1. Import/eksport av elevdata fra student databsen. 2. Ingen statistikk del Avvik i brukergrensesnitt 1. Utskrift ikke lagt til 2. Oversettelse til engelsk for utlandske studenter ikke lagt til Ikke all funksjonalitet som vi har satt som krav til systemet har blitt løst. Dette kan anses som avvik men vi ser på det som forbedringsmuligheter i fremtiden. De fleste avvik er heller ikke så store, men små endringer som ikke tar så lang tid å sette opp. 6 Oppsummering 6.1 Produktet Vi har utviklet et produkt som har oversteget de mål vi har satt oss til å begynne med, noe vi er meget fornøyd med. I starten så trodde vi aldri at vi skulle få til et fungerende system men kanskje et proof of concept og at rapporten skulle ta en mer faglig vinkling. Dette viste seg til å snu helt om, da vi under prosessen så at det var fullt mulig å lage ett produkt som fungerer. Per dags dato så fungerer det meste av primær funksjonene helt optimalt og har oversteget de krav som ble satt opp i kravspesifikasjonen. Dette systemet er det mest lønnsomme å bruke enn å finne et kommersielt system eller å bruke det ti år gamle Mefisto. Systemet Mefisto har ikke oppdatert seg siden og har ikke noe grensesnitt. Dette kan man se nærmere på under punkt Vi er utrolig fornøyd med å ha fått til backend og et brukergrensesnitt. S2S kan virke for en utenforstående som et enkelt system som kunne ha tatt kortere tid til å bygge opp men det har vært ganske utfordrende til tider og sette opp database og spørringer. Det å finne enklere løsninger til funksjonalitet og problemstillinger har ikke alltid gått så lett, men det er vel noe Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

41 som er ganske vanlig i et prosjekt arbeid. Vi har måttet sette oss inn i nye programmeringsspråk på et dypere nivå enn det vi har gjennomgått i tidligere fag. Å finne nye metodikker og teknologier for å implementere underveis i prosessen har vært ganske stort og omfattende. Og dette krever mye tid i tilegg til å faktisk få det til. Brukergrensesnittet har et gjennomgående enkelt og intuitivt design, men hovedfokuset var å løse de oppgaver som er ment man skal gjøre i et student evaluerings system. Med tanke på tidspresset og fordelingen av både rapport skriving og utviklingen av produktet så har prioriteringene for et brukervennlig og dynamisk brukergrensesnitt fått en del avvik. Oppdragsgiver er veldig fornøyd med utfallet av prosjektet. Han ble ble veldig imponert over at vi var i stand til å lage ett produkt som holdt den standarden den gjorde. Arbeidsgiveren har gitt lite feedback på hva han vil ha i applikasjonen, vi har kun hatt noen få møter med han, men vi har likevel klart å løse hans krav. Det meste har gått mellom veileder. Arbeidsgiveren ble også fornøyd med det grafisk grensesnittet vi hadde utarbeidet. Han ga uttrykk for at denne applikasjonen kunne brukes på en klasse allerede til neste semester i samarbeid med en foreleser for å teste ut systemet. Han anbefalte at vi fortsetter med utviklingen av prosjektet våres selv etter at vi var ferdige, for dette var et produkt som Høgskolen i Oslo og andre kunne være interreserte i. 6.2 Prosessen Samarbeidet gjennom hele prosjekt perioden har gått veldig bra. Gruppen har samarbeidet sammen tidligere opp gjennom de tre årene på høgskolen og kommer godt overens. Gruppen vet hvor man har hverandre både på kompetanse nivå og kapasitets nivå. Hardt arbeid og fokus er mange av de personlige mål som gruppen har til felles. Dette prosjektet skiller seg ut fra andre prosjekter fordi vi har klart å utvikle kode fra bunn av og ikke satt fokus på å forstå tidligere koder eller å implementere ny kode. Vårt system har også et annet formål en å lage en nettbutikk, ett regnskapsystem eller ett nettsted som de fleste andre prosjekter. Student to student er ett etterspurt student evalueringssystem som er genialt, det vil gi lærere rom og tid til mye annet å være en fordel for studenter ved at de lærer av hverandres oppgaver. Dessverre så er det ingen som har hatt ressurser eller tid til å utvikle det videre eller på nytt, og dette ser vi på som ett kupp som har fått anledning til å utvikle dette systemet. Vi føler oss ganske heldige som har fått i oppgave av HiO å utvikle dette systemet. Vi i gruppen føler vi har vokst veldig på den erfaringen vi har opparbeidet oss under prosjektgjennomføringen og de problemene vi har blitt stilt ovenfor og har måttet løse. Vi vil da konkludere med at dette har vært en svært lærerikt prosess for oss. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

42 Kilder Ann-Mari Torvatn, (2006)Hovedprosjekter i data/it dokumentasjonsstandard, Høgskolen i Oslo, avd. for Ingeniørutdanning. Burgess. M (2003) Security and online student evaluation with large classes. Ann-Mari Torvatn, (2001)Kommunikasjon for ingeniører, Tapir Akademisk Forlag. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

43 Prodkutrapport Studentevalueringssystem Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

44 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling v/høgskolen i Oslo. Dette dokumentet er produktrapporten for hovedprosjektet, og skal gi en oversikt over hvordan hele systemet er bygget opp og hvordan det fungerer i praksis. Veiledning for klargjøring og installasjon av systemet er også en del av rapporten. Det forutsette at leseren er kyndig i PHP, HTML og SQL databaser. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

45 Innholdsfortegnelse Forord 44 2 Innledning Om bedriften Dagens situasjon Mål Rammebetingelser 47 3 Teknologier Valg av teknologi Betingelser Beskrivelse av teknologi Krav for bruk av produktet 49 4 Oppbygning og virkemåte Introduksjon Delene Kommunikasjon Brukergrensesnitt og tilgjengelighet 51 5 S2S: Database utforming og datastrukturer Introduksjon Oversikt over alle relasjoner Strukturer 54 6 S2S Funksjoner Støttefunksjoner Hovedfunksjoner Administrative funksjoner 67 7 Sikkerhet Generelt Anonymisering Bruker passord 71 8 Samsvar mellom produkt og kravspesifikasjon 71 9 Videreutvikling 72 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

46 2 Innledning 2.1 Om bedriften Høgskolen i Oslo er landets største statlige høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelor studier og 18 masterstudier. En så stor utdanningsinstitusjon med så mange studenter krever mye av lærere og studentassistenter så et slikt evaluerings system vil definitivt være med å lette de ansattes hverdag på en positiv måte. Foreløpig vil systemet være fokusert på datastudenter og vil ikke omfatte alle avdelinger i Høgskolen i Oslo. 2.2 Dagens situasjon Som situasjonen er i dag så er det veldig ressurskrevende å få gjort vurdering av elevarbeid. Studenter benytter seg av skolens student portal, Fronter, for å levere inn arbeid for vurdering. Ingenting er automatisert, så det er lærere og studentassistenter som får oppgaven med å gå inn på Fronter å vurdere alt arbeid gjort av studenter. Karakterer eller bestått/ikke bestått settes inn sammen med kommentarer på Fronter så studenter kan lese tilbakemeldingen. Fronter er et bra system, men det har ingen funksjon for å muliggjøre "peer review" som vi beskriver det. Med tanke på hvor mange studenter som studerer på HiO kan man tenke seg til at det er mye ressurser som kan frigjøres ved å kunne designe ett slikt system. Figur 1 Dagens Løsning illustrert. Skolen har selv ytret ønske om å kunne lette arbeidsmengden ved å la studenter være delaktig i vurdering av hverandres arbeid. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

47 Figur 2 Ønsket løsning. Ingeniøravdelingen har utviklet ett system, kalt Mefisto, som har blitt brukt i mindre grad. Etter samtaler med samtlige utviklere av Mefisto kommer det frem at systemet var for vanskelig og tidskrevende å benytte seg av når det ble lansert. Bruken av systemet ble for teknisk avansert for andre enn de som hadde vært med å utviklet det. Systemet har ikke noe grensesnitt og måtte kodes om for hver gang det skulle brukes til noe. Forøvrig var peer review bare en av funksjonene i Mefisto, og ikke den som var "mest utviklet" av de alle. En av ønskene til oppdragsgiveren er at vi skal vurdere om Mefisto kan videreutvikles eller brukes som utgangspunkt for utvikling av en ny applikasjon. Mefisto ble bare brukt i IU-avdelingen på HiO. 2.3 Mål De sentrale mål for systemet er hovedsakelig det som kreves for at systemet skal fungere riktig i forhold til miljøet og arbeidsplassen. Systemet bør: gjøre det mulig for studenter å vurdere hverandres arbeid. gi vurderinger som er troverdige og kan benyttes som at de er riktige, dvs. at det ikke skal være mulighet for fusk. være trygt nok til at man ikke kan bryte seg inn å legge inn falske resultater. holde orden på hvem som har tilgang til å rette oppgaver og at den som har rettet en oppgave ikke har rett til å rette samme oppgave igjen. opprettholde personvernet til den enkelte. være 100% nettbasert. være åpen kildekode og fritt tilgjengelig. Funksjonalitet som kan implementeres er: varsel på /sms når du skal evaluere en oppgave, eller har mottat resultater. 2.4 Rammebetingelser Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere applikasjonen. Vi står også fritt til å velge hvilken grad applikasjonen skal være ferdig utviklet. I utgangspunktet tenker vi i arbeidsgruppen at vi må modellere/beskrive systemet 100% og minst lage en proof-of-concept applikasjon. Gruppen planlegger å bruke PHP som programmeringsspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web-løsninger. Uansett kan man jo tilpasse applikasjonen relativt enkelt til å benytte annen database programvare. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

48 3 Teknologier 3.1 Valg av teknologi Når vi begynte med prosjektet og bestemte oss for at vi skulle løse oppdraget ved å lage et eget system viste vi at det kom til å bli nok å sette seg inn i. Det eneste egnede programmeringsspråket vi har vært borti på HiO er PHP. Derfor var valget veldig naturlig for oss at det var dette vi skulle benytte oss av. PHP er også åpent tilgjengelig og kan kjøres på alle plattformer, noe som er ett pluss. Vi valgte å bruke MySQL som database plattform, siden vi har brukt denne plattformen før og i andre prosjekter. Underveis i prosjektet møtte vi på utfordringer som vi brukte tid på å løse, mye på grunn av manglende erfaring med å programmere så store prosjekter. I og med at applikasjonen skulle være nettbasert måtte vi benytte oss av HTML,CSS og litt javascript også. På serversiden brukte vi Debian Linux med Apache 2, PHP og MySQL. Vi brukte Munin for å overvåke forskjellig statistikker. Vi brukte også database administratoren PhpMyAdmin for å sette inn data i databasen. Kombinasjonen av disse tjenereapplikasjonene blir ofte referert til som LAMP (Linux, Apache, Mysql, PHP) og er veldig mye brukt av web utviklere i dag. Ofte pga. det er testet ut og vist seg til å fungere veldig bra over tid. For å utvikle koden brukte vi Adobe Dreamweaver. Ett program som fungerer ganske bra til HTML/CSS, men har sine svakheter når det kommer til å tolke PHP, men vi valgte allikevel å bruke dette programmet. For database planlegging og generering brukte vi MySQLAdministrator, som er ett nytt verktøy. Det fungerer ganske bra for å konstruere ER-modeller og senere lage en fungerende database ut av modellen. For å lage enkle spørringer brukte vi RazorSQL. En applikasjon til Mac som gjør det litt enklere å lagre spørringer og gir ett litt mer oversiktlig bilde av databasen. De mest komplekse spørringer er blitt laget for hånd ettersom det ikke finnes noe program som forstår de spesielle kravene vi hadde til resultater. 3.2 Betingelser Oppdragsgiver ga oss ingen betingelser i forhold til valg av teknologi eller plattform. Det ga oss frihet til å velge den teknologien vi ville benytte selv. Den eneste betingelsen oppdragsgiver ga oss var at applikasjonen skulle være nettbasert og plattform uavhengig. 3.2 Beskrivelse av teknologi PHP PHP er et dynamisk, tolket og løst typet programmeringsspråk hovedsakelig brukt for å utvikle dynamiske nettsider. PHP syntaks ligner på C og Perl. Den vanligste implementasjonen av PHP er en fri og åpen versjon skrevet i C og distribuert av The PHP Group via php.net. 1 1 Wikipedia (fredag 21. mai 2010): Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

49 3.2.2 HTML/CSS HTML og CSS er ryggraden til internett. Det er disse to i sammen som definerer hvordan informasjonen skal fremvises i nettlesere. Utfordringen er ofte å bruke CSS til å skape layout, og la HTML inneholde den informasjonen som skal vises, slik at det er lett å endre på utforming i senere tid MySQL Mysql er et SQL-basert databaseadministrasjonssystem som er lisensiert under GPL. Denne databasetjeneren er veldig mye brukt, som en viktig del av LAMP. Det finnes i dag ulike tjenere til de fleste operativsystemer og det gjør det enklere å igjen kunne flytte tjenere for applikasjoner rundt på forskjellige plattformer utenom å gjøre store endringer i kildekoden. Mysql er også lett å bruke og sette opp, gratis og holder en høy ytelse i forhold til både pris og krav til maskinvare Krav for bruk av produktet Forutsetninger for bruk av S2S dekkes i dette kapitlet Klientside Nettleser som støtter CSS og Javascript. Eksempelvis: Internet Explorer 6, Firefox, Google Chrome, Safari og Opera Internett tilgang Valgfritt operativsystem Serverside Apache2 web tjener, eller annen web- tjener som kan kjøre php script. PHP 4.x eller høyere MySQL database tjener, eller annen SQL database (visse endringer kan kreves av kildekoden). Operativsystem som er kompatibelt med overstående tjenere. 2 Wikipedia (fredag 21. mai 2010): Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

50 4 Oppbygning og virkemåte 4.1 Introduksjon I dette kapitlet går vi gjennom hensikten, og hva applikasjonen vi har programmert fra scratch, kan gjøre. Formålet med applikasjonen, S2S, er å gi ett enkelt system til Høgskolen i Oslo for å kunne utføre peer review av studenter. Peer review bygger på prinsippet om at studenter skal gjøre jobben med å rette hverandres arbeid og sette en vurdering på det. Dette er i stedet for den tradisjonelle måten hvor det er lærer og studentassistenter som tar denne jobben. Det er selvfølgelig mange utfordringer som er knyttet til å få til dette på en ordentlig måte. Utviklere må passe på at personvernet til studentene blir ivaretatt, de må passe på at det ikke blir noe lettere å drive med fusk enn hva som er realiteten i dag. Dette er bare noen av utfordringene som vi har måttet løse underveis. Applikasjonen består av tre deler: Student, lærer/studentassistent og administrator del. De fyller alle forskjellige krav og er tydelig fraskilt. Alle delene er webbasert og er tilgjengelig fra hvilken plass som helst i verden hvor brukere har nettilgang. I utgangspunktet skal alle nettlesere og operativsystemer gi samme brukeropplevelse. Alt dette var en selvfølge når vi designet applikasjonen fra scratch. 4.2 Delene S2S, student 2 student evaluation, består som sagt av tre deler. Student delen er den delen som studenter vil ha tilgang til. Det er denne delen som tar seg av hovedoppgaven til applikasjonen, det å gjøre det mulig for studenter å rette hverandres arbeid Studentdelen Student delen innehar funksjonaliteten for studenter til å laste opp arbeidet sitt, laste ned andres arbeid og sette en vurdering på arbeidet samt undersøke de aggregerte resultater for en oppgave. Virkemåten er slik at en student får vite resultatet av arbeidet først når det er vurdert ett visst antall ganger, dvs. det antall som læreren eller ansvarlig for oppgaven har satt som ett krav under offentliggjøring av oppgaven. Arbeidet som blir lastet opp kan lastes opp som alternativt filformat, det er ikke satt noen begrensninger, bortsett fra eksekverbare filer. Skal studenter laste opp flere filer må disse komprimeres ved hjelp av ett egnet program (for eksempel WinRar 3 eller det åpne og frie alternative 7-Zip 4 ). Av andre funksjonaliteter finnes det en hjelpe del som beskriver bruken av applikasjonen, en funksjon for å vise hvilke kurs studenten er registrert som deltaker i og alle resultater som er oppnådd til dags dato. All den relevante informasjonen vises på hovedsiden Lærer/studentassistentdelen Lærer og studentassistent delen har funksjonalitet for å legge til arbeidsoppgaver til de kursene som er registrert på deres konto. Naturligvis er også redigering eller sletting av registrerte arbeidsoppgaver også tilstede. Læreren laster opp dokument eller en komprimert, på samme måte som studenter gjør dette. Grunnen til dette er at applikasjonen per i dag ikke støtter det å laste opp flere filer til samme arbeidsoppgave. Dette er en funksjonalitet som kan implementeres senere uten 3 Lastes ned fra: 4 Lastes ned fra: Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

51 noen store utfordringer. Av annen funksjonalitet kan lærere få ut forskjellige rapporter. Blant annet hvilke resultater de forskjellige studentene har oppnådd Administratordelen Administratordelen er forbeholdt for de som skal ha ett overordnet ansvar for at applikasjonen skal fungere. Administrator har mulighet til å opprette kurs, gjøre endringer på kurs, slette kurs, legge til brukere, slette brukere, osv. Det er ikke meningen at administrator skal legge til store bruker antall ved hjelp av bruker håndtering innenfor applikasjonen. Det kunne fort tatt meget lang tid og tatt hele poenget med applikasjonen bort. Den jobben kan gjøres lettest ved å lage ett script som putter brukere/studenter direkte inn i databasen! 4.3 Kommunikasjon Kommunikasjonen fra klient til server og omvendt skjer gjennom internett og HTTP protokollen. Det er ingen cookies som blir lagret på klientmaskinen, og applikasjonen fungerer dermed uten cookies. Det er vertsmaskinen som holder rede på hvem som er innlogget ved hjelp av session variabler. Ingen informasjon om aktiviteten på applikasjonen vil bli lagret av nettleseren. I utgangspunktet hadde vi planlagt og implementere applikasjonen ved hjelp av HTTPS, men på grunn av lite tid mot slutten av prosjektet ble vi nødt til å kutte dette og heller la det være noe som kan utvikles videre i neste versjon. Klient Tjener Internett HTTP 4.4 Brukergrensesnitt og tilgjengelighet Vi har prøvd så langt det lar seg gjøre å lage ett grensesnitt som er lett å forstå og intuitivt. Vi har bare tatt med det som er kritisk for applikasjonen, for å unngå at brukere skal rote seg bort i funksjonalitet som det ikke er behov for. Ved å legge alt som er relevant for de aller fleste brukere på første siden de blir møtt av har vi redusert antall klikk ganske kraftig. Ved å lage ett enkelt brukergrensesnitt uten javascript og flash osv. har vi også redusert kravet til maskinvare og programvare hos klient maskinene. Hele grensesnittet er skrevet i HTML og CSS. Vi har også laget nettsiden slik at den kan skaleres ved hjelp av den innebygde zoom-funksjonen i nettleser på mest mulig hensiktsmessig måte. I utgangspunktet er tekst og slike ting ganske så bra tilpasset for det meste av brukermassene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

52 Nettsiden er validert av W3C, både HTML koden og CSS filen er valid. Noe som nok en gang hjelper til på nettleser kompabilitet og unngår at man får se en overraskelse når brukere tester ut med forskjellige nettlesere som ikke er blitt brukt i interne tester. Vi valgte å programmere i W3C HTML standarden: XHTML Transitional 1.0. Dette fordi det er hva vi er vant til, og det er dette som er den standarden som brukes av alle nå. 5 S2S: Database utforming og datastrukturer 5.1 Introduksjon Applikasjonen bruker SQL-setninger til alle sine gjøremål. All programmering er gjort med tanke på at tjeneren skal brukes i ett MySQL-tjener miljø. Det kan gjøres om til å bruke andre SQLkompatible databaser, men det kan tenkes at noen av spørringene benytter funksjoner som er native kun for MySQL. Oppbygningen av databasen ble gjort slik at den fylte opp kravene til BCNF (Boyce-Codd normal form) fra start. Dataene som blir lagret er delt opp logisk, slik at man ikke skal trenge å blande inn for mange forskjellige tabeller for å komme frem til den dataen man ønsker. Det er også tenkt slik at det skal bli så enkelt som mulig å importere data til databasen ved hjelp av utenforstående script når vi satt opp databasen. I denne delen av rapporten vil hele databasens oppbygning og funksjon bli gått gjennom. Funksjonaliteten som dekkes av de ulike tabellene vil bli forklart, og verdier som kan virke kryptiske vil bli gitt en mening. Relasjonen mellom tabellene vil også bli gjennomgått. Målet med denne delen er å gi administrator en forklaring på hvordan han skal behandle informasjon som skal ut eller inn fra databasen. Tabellene er navngitt på engelsk, dette fordi det applikasjonen er en open-source applikasjon. Det hadde appellert til ett mye mindre publikum å videreutvikle applikasjonen hvis det var alt for preget av norske navn, kommentarer osv. i kildekoden. Vi har prøvd å gjøre tabellene og datastrukturene så enkle å forstå som mulig, slik at det skal være lett å sette seg inn for administratorer og videreutviklere. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

53 Alle forklaringene av de ulike tabellene som fortsetter videre inneholder en figur printet ut fra MySQLWorkbench. 5.2 Oversikt over alle relasjoner. Figuren nedenfor viser ER-modellen for databasen slik den så ut etter siste revisjon av applikasjonen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

54 5.3 Strukturer Tabellen user Denne tabellen inneholder som navnet tilsier alle brukere. Informasjon som lagres i tabellen er: ett unikt bruker identifikasjonsnummer, som i utgangspunktet er usynlig og transparent for brukere. Tabellene bør alltid ha en unik primærnøkkel ellers blir det problemer når man skal begynne å registrere store mengder data og senere finne den fram. Fornavn, etternavn, og passord blir også lagret. Passordet blir ikke lagret i klartekst, men i hash formen generet av SHA2 (256-bit). Hva slags brukere det er som er registrert sier tabellen user ingen ting om. Administratorer, lærere, student assistenter og studenter er lagret i samme database, med ingenting som skiller de ut. Videre definisjon av brukerne ligger lagret i andre tabeller som vil bli beskrevet senere. Grunnen til at vi valgte å gjøre det slik er at i enkelte tilfeller kan en lærer kanskje også være student, og i de fleste tilfeller vil en studentassistent også være student. Vi unngår da å måtte dobbel lagre informasjon Tabellen admin Som navnet tilsier blir administrator detaljer lagret i denne tabellen. Tabellen inneholder kun det unike bruker identifikasjonsnummeret lagret i tabellen user. Rad nummer to inneholder hvilket nivå administratoren tilhører. Enn så lenge er denne INT verdien uten funksjon, men det ble planlagt at det skulle være forskjellig nivåer for administrator brukere i startfasen. Jo høyere verdi, desto mer rettigheter Tabellen student Denne tabellen inneholder alle studenters unike identifikasjonsnummer samt students studentnummer. Dvs. det samme som studenten i dag ville logget seg med inn på Fronter. Det er studentnummeret studenter bruker for å logge seg inn i systemet (de kan også benytte adressen sin hvis de foretrekker det). Studentnummer er primærnøkkelen ettersom dette er ett unikt nummer som i utgangspunktet ikke skal ha duplikater. Ved at userid ligger lagret i denne tabellen sier det at brukeren er en student med det og det studentnummeret. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

55 5.3.4 Tabellen teacher_has_course og assistant_has_course teacher_has_course inneholder den unike userid og indentifikasjonsnøkkelen for kurs courseid. Ved å knytte disse sammen skaper man en kobling mellom kurs og bruker og dermed forklarer dette at brukeren er en lærer i det oppførte kurset. Det samme prinsippet blir benyttet i assistant_has_course tabellen. Det foreligger restriksjoner på hva man putter inn i disse tabellene. Restriksjonene er at courseid og userid allerede eksisterer, slik at man unngår at feil informasjon blir lagret i databasen Tabellen course Ulike kurs blir lagret i tabellen course. Her lagres informasjon om kursets kortnavn, fullenavn og beskrivelse. Kurset identifiseres ved hjelp av en unik identifikasjonsnøkkel. Vi kunne i bunn og grunn brukt kortnavnet på kurset, men usikkerhet ved hvorvidt dette vil fortsette å være en unik nøkkel i årene som kommer gjorde at vi valgte å bruke en egen nøkkel. Samme som i bruker databasen syntes ikke denne verdien for brukeren Tabellen user_has_course Inneholder data om hvilke kurs brukere, eller studenter, deltar i. UserID og courseid blir satt sammen for å kunne lage en relasjon mellom disse tabellene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

56 5.3.7 Tabellen task Her lagres alle oppgaver som er lagt til av lærere eller studentassistenter. Tabellen har også en unik primærnøkkel som brukes for å binde den sammen med andre tabeller. CourseID blir lagret her for å kunne vise til hvilket kurs oppgaven tilhører. Title, description er ganske selvforklarende tittel og beskrivelse. Extras er rekken hvor det filnavnet til oppgavens dokument ligger lagret. Denne tekst strengen er av ubegrenset størrelse, for man vet aldri hvor langt filnavn man kan ende opp med. Due er en dato streng som inneholder dato og klokkeslett for når oppgaven har til frist å være levert inn. Angis på den amerikanske metoden (åååå-mm-dd tt:mm:ss). assesmenttype angir hvilke vurderingstype oppgaven skal ha av: karakterbasert eller bestått eller ikke typen. Verdien 1 betyr karakterbasert, mens 2 betyr bestått eller ikke bestått. numberofreviews angir antall vurderinger som kreves før resultatet kan beregnes. I utgangspunktet kan denne verdien være alt mellom 1 og uendelig Tabellen submission Inneholder all data i forhold til innleveringer som er blitt gjort av brukere, med unntak av hvem innleveringen tilhører. En unik primærnøkkel blir brukt også her, den knyttes opp mot hvilken oppgave den tilhører. Filnavn på den opplastede filen blir lagret her, samt kommentar og ett tids stempel for når innleveringen ble gjort Tabellen submission_has_user Denne tabellen knytter innlevering til en bruker eller flere brukere. Tilhører innleveringen flere studenter vil det være flere rekker med samme submissionid, men ulik userid. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

57 Tabellen review Her lagres selve vurderingene av innleveringene til brukere. Et unikt identifikasjonsnummer opprettes også her når det legges til en rekke. SubmissionID lagres for å koble vurdering til innlevering. review er en tallverdi mellom 1 til 6 hvor 6 er høyeste score som kan gis på en innlevering. Vi lagrer vurderinger/karakterer som tallverdier for det er mye lettere å gjøre utregninger av resultat for innlevering når man har med tall i stedet for bokstaver å gjøre. Konvertering til bokstav karakter gjøres i PHP delen av applikasjonen Tabellen review_has_user Inneholder data om hvem som har vurdert og satt karakter på hvilke innleveringer. Det kan være nyttig og kunne se hvilke brukere det er som har gjort hvilke vurderinger. Det lagres reviewid, submissionid og userid i denne tabellen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

58 6 S2S Funksjoner Vi har brukt en del globale funksjoner som blir gjenbrukt i stort sett alle deler av applikasjonen. Dette for å gjøre programmeringer raskere og mer effektiv, og for at utviklerne skal slippe å gå tilbake å endre på mange ulike filer for å gjøre en enkel endring. Vi vil gå gjennom alle de ulike funksjonene/includes vi har lagd nedenfor. Vi vil også gå gjennom de tingene som er viktig for å forstå applikasjonens virkemåte. For hver del vil filens plassering i filsystemet oppgis. All koden som er laget er egenprodusert, med få unntak. Kode som er hentet fra andre plasser vil vi merke og gi en referanse til. 6.1 Støttefunksjoner Konfigurasjonsfil < config.inc.php > Plassering: /etc/config.etc.php Formål: Gi en sentral plassering hvor administratorer kan endre variabler. Kode: <?php ## This is the configuration file for some of the variables in S2S. $mysqluser = "bruker"; $mysqlpassword = "xxx"; $mysqlhost= "localhost"; $mysqldatabase = "s2s"; $errormessage = "Det ser ut som at systemet er nede akkurat nå. Kontakt system administrator."; $temporaryuploaddirectory = "./temp/"; $permanentuploaddirectory = "./file/"; $assesmentarray = array("1" => "Karakter", "2" => "Bestått eller ikke");?> Formålet med denne filen er å kunne forenkle forflytting av applikasjonen. Her fylles den nødvendige informasjonen for å koble seg til databasen som skal brukes. Det kan også skreddersys en generell feilmelding som vil dukke opp hvis systemet skulle bli stoppet av en feil. Her kan administrator for eksempel skrive inn sin adresse eller lignende. Plassering av opplastede filer defineres også i variabler i denne filen. $temporaryuploaddirectory verdien definerer hvor filen skal lagres før den gis ett nytt navn og flyttes til den endelige plasseringen angitt i $temporaryuploaddirectory Database tilkobling < connecttodb() > Plassering: /inc/connecttodb.inc.php Formål: Koble til database. Kode: <?php ## Function to connect to the sql DB of choice. Uses variables from config.inc.php. ## Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

59 ## function connecttodb(){ require( "/var/www/etc/config.inc.php" ); mysql_connect("$mysqlhost", "$mysqluser", "$mysqlpassword") or die(header( "location:./index.php" )); $select = mysql_select_db( $mysqldatabase ) or die( $errormessage ); return $select; }?> Denne funksjonen brukes i nesten alle de ulike sidene i applikasjonen. Den sørger enkelt og greit for å koble til databasen ved eksekvering av funksjonen. Funksjonen tar ingen variabler. Funksjonen henter variablene som er angitt i config.inc.etc, de blir hentet inn ved bruk av require() funksjonen. Dvs. at hvis funksjonen ikke skulle klare å hente variablene vil applikasjonen stoppe. Verdien som kommer fra funksjonen mysql_select_db() blir returnert tilbake til connecttodb() Innloggingsfunksjon for upriviligierte brukere Posisjon: /inc/auth.inc.php Formål: Autentisere brukere oppmot database og åpne en sesjon. Kode: <?php ## Function to authenticate users trying to log in. Sending them back to index.php or back to do another login attempt depending on the outcome of the query. session_start(); require_once( "connecttodb.inc.php" ); $user = $_POST['user']; $password = $_POST['pass']; ## Basic SQL-injection protection. $user = addslashes($user); ## SHA2 one-way hash on password $password = hash('sha256', stripslashes( $password ) ); ## SQL connection establishment. connecttodb(); ## User matching $test1 = " SELECT userid FROM s2s.user WHERE = '$user' AND password = '$password' "; $test2 = " SELECT student.user_userid Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

60 FROM s2s.student student, s2s.user user WHERE student.user_userid = user.userid AND student.studentnr = '$user' AND user.password = '$password' "; $result1 = mysql_query( $test1 ); $result2 = mysql_query( $test2 ); $count1 = mysql_num_rows( $result1 ); $count2 = mysql_num_rows( $result2 ); $userid = mysql_fetch_row( $result1 ); $userid2 = mysql_fetch_row( $result2 ); mysql_close(); if ( $count1 == 1 ) { ## Session variabel set. $_SESSION['loggedInUserID'] = $userid[0]; } if ( $count2 == 1 ) { $_SESSION['loggedInUserID'] = $userid2[0]; } header("location:../index.php");?> Innloggings funksjonen begynner med å starte en session container. Videre kreves funksjonen connecttodb() for å gå videre. POST verdier fra brukerens nettleser blir lagret i midlertidige variabler, hvor symboler som kan tillate sql-injection fjernes. Det er riktignok ikke en fullverdig beskyttelse mot sql angrep, men det gir en hvis form for beskyttelse. Virkemåten til resten av funksjonen er at to spørring kjøres hvor en inneholder adresse og passord, en annen inneholder studentnummer og passord. Hvis en av disse spørringene returnerer med ett resultat med en rekke, som tilsier at brukeren eksisterer og har det oppgitte passordet, vil en av teller variablene få tallet 1 i seg. Det unike brukeridentifikasjons nummeret lagres i en session variabel og brukeren vil bli sendt videre til index.php, som er hovedsiden for applikasjonen. Det er denne session variabelen som sier at brukeren er innlogget. Når den finnes så betyr det for applikasjonen at brukeren er pålogget. Når den ikke eksisterer så betyr det ingen er innlogget Innloggingssjekk < checklogin() > Posisjon: /inc/checklogin.php Formål: Undersøke om brukeren er logget inn. Tilby innlogging hvis ikke. Kode: <?php ## Function to be executed at start of protected areas to send unlogged users back to login schema. session_start(); function checklogin(){ Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

61 }?> if (!isset($_session['loggedinuserid'] )) { header( "location:./login.php" ); } Dette er en funksjon som inkluderes i alle deler av nettsiden hvor det kreves at brukeren skal være logget inn. Det den gjør er enkelt å greit å undersøke om session variabelen som er beskrevet ovenfor faktisk eksisterer. Hvis den ikke eksisterer vil brukeren bli sendt tilbake til login.php, som er innloggingsskjermen til nettsiden. På denne måten vil alle uautoriserte brukere som prøver å gå inn på sider som krever innlogging bli sendt tilbake til start hvor de får mulighet til å logge inn Extras < formatdate() findexts() > Posisjon: /inc/extras.inc.php Formål: Gir en del støttefunksjoner som brukes flere steder. Kode: <?php ## Different functions that are used in different parts. ## Sormat date in the correct fashion. function formatdate($date) { $timestamp = strtotime($date); $converted = date('d.m.y h:m', $timestamp); return $converted; } ## Separates the extension from the rest of the file name and returns it. function findexts ($filename) { $filename = strtolower($filename) ; $exts = split("[/\\.]", $filename) ; $n = count($exts)-1; $exts = $exts[$n]; return $exts; }?> Dette er en samling små funksjoner som benyttes i varierende grad flere ganger av applikasjonen. formatdate() funksjonen omformaterer den amerikanske standarden for tids fremstilling til den norske standarden. Den tar en timestamp streng som input og sender tilbake en tekst streng med dato og tid. Funksjonen findexts() benyttes når brukere laster opp en fil. For å kunne anonymisere filene, og for å unngå at filer med samme navn blir lagret vil fil endingen skilles fra den opplastede filen, slik at applikasjonen kan sette på en random tekststreng som filnavn Tilfeldig streng generator < str_rand() > Posisjon: /inc/randomgenerator.php Formal: Å produsere en tilfeldig streng bestående av alfanumeriske tegn. Hentet fra: Denne funksjonen har vi hentet fra Aidan Lister, som er en profesjonell webutvikler med stor fartstid innenfor PHP programmering. Det den gjør er å generere en alfanumerisk streng av en bestemt Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

62 lengde. Vi så ikke noe behov for å lage vår egen generator når denne fungerte bra for vår applikasjon. 6.2 Hovedfunksjoner Hovedfunksjonene er designet slik at de er en del av php filene i applikasjonen. Dette for at man skal sy i sammen HTML, PHP og CSS til en miks. En del av informasjonen som er nødvendig for de forskjellige funksjonene blir sendt videre ved hjelp av GET variabler, dvs. variabler som overføres ved hjelp av nettleser adressen Login side < login.php > Posisjon: /login.php Formål: Å logge inn uprivilegerte brukere. Dette er den siden brukere som ikke er logget inn vil møte. Målet med den er å logge inn brukere og finne deres unike identifikasjonsnøkkel ved hjelp av rutinen auth.inc.php. Den består ikke av noen PHP kode, med unntak av en tidsstempel som blir skrevet ut for å angi hvilken tid som applikasjonen tar som utgangspunkt for frister Index side < index.php > Posisjon: /index.php Formål: Å gi brukeren ett oversiktlig bilde over situasjonen i forhold til frister, resultater og vurderingsjobber de har. Kode: Kun relevante deler av koden vil bli beskrevet i dette dokumentet ettersom den er for massiv til at det blir hensiktsmessig og ha den fremstilt. Index siden er den delen som studentene vil bruke mesteparten av sin tid på. Her får studentene ett oversiktlig bilde over: hvilke oppgaver som skal leveres og når. hvilke resultater som er blitt oppnådd. innleveringer som kan vurderes. Det som gjør det meste av jobben med å fylle inn data på index siden er selvfølgelig spørringene. Disse er relativt store og kompleks i forhold til hva vi er vant til. De fleste av spørringene inneholder subqueries, dvs. spørring i en spørring. Vi går gjennom de viktigste spørringene under. Spørring for å hente ut oppgaver som skal leveres fra databasen: SELECT course.shortname, course.name, task.title, task.description, task.due, task.coop, task.assessmenttype, task.taskid FROM s2s.user user, s2s.user_has_course user_has_course, Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

63 s2s.course course, s2s.task task WHERE user.userid = user_has_course.user_userid AND user_has_course.course_courseid = course.courseid AND course.courseid = task.course_courseid AND task.taskid NOT IN ( SELECT submission.task_taskid FROM s2s.user user, s2s.user_has_course user_has_course, s2s.task task, s2s.submission_has_user submission_has_user, s2s.submission submission WHERE user.userid = user_has_course.user_userid AND user.userid = submission_has_user.user_userid AND user_has_course.course_courseid = task.course_courseid AND task.taskid = submission.task_taskid AND submission_has_user.submission_submissionid = submission.submissionid AND user.userid = $userid ) AND task.due >= CURRENT_DATE AND user.userid = $userid ORDER BY task.due ASC Det spørringen gjør er å hente ut de rekkene i tabellen task som oppfyller visse krav: studenten har kurset som oppgaven tilhører studenten har ikke levert inn oppgaven tidligere fristen for innlevering har ikke gått ut. Resultatet av spørringen blir fremstilt i en tabell. All relevant informasjon som fag, oppgavetittel, frist, samarbeid og vurderingstype blir listet opp. Er studenten interessert i mer data kan han klikke på forstørrelsesglasset i handlings feltet. Spørring for å hente ut innleveringer som er vurdert nok antall ganger. SELECT COUNT(review.submission_submissionID), course.shortname, course.name, task.title, task.description, AVG(review.review), task.numberofreviews, Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

64 submission.submissionid FROM s2s.user user, s2s.submission_has_user submission_has_user, s2s.submission submission, s2s.review review, s2s.task task, s2s.course course WHERE user.userid = submission_has_user.user_userid AND submission_has_user.submission_submissionid = submission.submissionid AND submission.submissionid = review.submission_submissionid AND submission.task_taskid = task.taskid AND task.course_courseid = course.courseid AND user.userid = '$userid' GROUP BY review.submission_submissionid Sjekken for om innleveringen har nok reviews gjøres i PHP for denne spørringen. Restriksjonene for at innleveringer skal bli listet opp er: oppgaven tilhører studenten som er innlogget. oppgaven er vurdert så mange ganger som er angitt i task.numberofreviews. Dataen som hentes ut ved hjelp av spørringen blir fremstilt i en tabell hvor alle de relevante dataene kommer frem. Hvis studenten er interessert i å lese kommentarer og hver enkelt vurdering kan han klikke på forstørrelsesglasset i feltet for handlinger. Spørringen som henter innleveringer som kan vurderes av studenten er en rimelig stor og kompleks spørring med mange subqueries i seg. Derfor har vi ikke lagt ved denne spørringen i dette dokumentet. Den kan derimot leses i index.php. Det denne spørringen gjør er at den starter med alle innleveringer som er gjort, men vil fortsette med å: fjerne de innleveringene som tilhører kurs studenten ikke deltar i. fjerne de innleveringene som tilhører oppgaver studenten ikke har levert. fjerne de innleveringene som allerede er vurdert så mange ganger som er oppgitt. fjerne de innleveringene studenten allerede har vurdert. fjerne de innleveringene som tilhører studenten selv eller noen han/hun er oppgitt som gruppert med. sortere tilfeldig hvilken rekkefølge innleveringene blir valgt ut fra. gruppere etter hvilken oppgave innleveringen tilhører. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

65 6.2.3 Leveranse av arbeid < submission.php > Posisjon: /submission.php og /submissionprocess.php Argument: taskid (?taskid=x) Mål: Ta i mot innlevering i form av en fil fra en student eller en gruppe og registrere oppgaven som levert på student(e). Kode: Kodedeler vil bli illustrert ved behov. Denne delen av applikasjonen blir referert til fra hovedsiden index.php. Rutinen i submission.php tar i mot ett argument i nettleserfeltet (en GET variabel). En typisk innlevering vil se slik ut Denne informasjonen sendes automatisk når brukerne trykker på linken i handlingsfeltet som vist i bildet ovenfor. Ved å gjøre det på denne måten kan også brukere lagre en link til respektive sider. Brukerne blir møtt av en rekke felt som de fyller inn. Submission vil undersøke om oppgaven er en gruppeoppgave eller en individuell oppgave ved hjelp av en spørring. Hvis oppgaven er en gruppeoppgave vil det bli skrevet ut ett felt for å legge til flere studenter. Studenten bruker da de andre studentenes studentnummer for å legge til ytterligere eiere. Studenten må klikke på legge til for hver gang han legger til ett nummer. For hver gang han klikker legg til vil studentnummeret bli undersøkt for gyldighet, og hvis det er gyldig vil students fornavn og etternavn dukke opp i en tabell når siden blir oppdatert. Er studentnummeret feil vil det ikke bli lagt til. Student velger den filen han vil laste opp og kikker Ferdig. All informasjonen vil bli sendt til submissionprocess.php. Derifra vil innleveringen bli lastet opp og vil legge til data til tabellene submission og submission_has_user Vurdering av arbeid < review.php > Posisjon: /review.php og./reviewprocess.php Argument: taskid (?taskid=x) Mål: Ta i mot vurderinger på innleveringer fra studenter. Review tar i mot vurderinger fra studenter som har vurdert ett arbeid gjort av en annen student. Det fungerer på samme måte som submission ved at det tar ett argument i nettleser feltet. Argumentet blir valgt utifra hvilken link i rette tabellen brukeren klikker på. Nøkkelen som blir videresendt fra index til review er taskid for å unngå at brukere skal kunne få tilgang til hvilken oppgave de vil (som hadde skjedde hvis for eksempel submissionid hadde blitt videresendt.) Review vil regne seg fram til en tilfeldig oblig innenfor den oppgaven som er blitt valgt (taskid). Selvsagt gjør også review de samme sjekkene for at ikke ondsinnede brukere skal kunne rette oppgaver de ikke skal. Visuelt består review av en rekke skjema objekter som fylles ut av brukeren. Når alle feltene er fylt ut vil informasjonen bli sendt til videre i POST variabler til reviewprocess.php. Rutinen i reviewprocess setter alle variablene inn i tabellene review og review_has_user og returnerer en melding til brukeren om at vurderingen er lagt til Detaljert visning for vurdert arbeid < details.php > Posisjon: /details.php Argument: submissionid (?subid=x) Mål: Gi en detaljert visning av resultater for en innlevering. Details gir en mer detaljert oversikt over en innlevering som er vurdert. Brukerne får en oversikt over hver enkelt vurdering (med karakter) og hva slags kommentarer de ulike sensorene har gitt for arbeidet. Det er også en del annen informasjon tilgjengelig på siden som blir generert. Argumentet som blir videresendt fra indeks siden er submissionid. Vi i gruppen vurderte det slik at det ikke er Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

66 noen grunn til å holde tilbake denne unike nøkkelen når en oblig er rettet. Selvfølgelig vil ondsinnede brukere ikke få vist noe annen obliger enn sine egne: Eierskapssjekk fra details.php $subid = addslashes( $_GET['subID'] ); $userid = $_SESSION['loggedInUserID']; ## Check to see if the person requesting the results really is the owner, or the submissionid really exists. $check = " SELECT submission_submissionid FROM s2s.submission_has_user WHERE submission_submissionid = '$subid' AND user_userid = '$userid' "; $count = mysql_num_rows( mysql_query( $check ) ); ## If not, redirecting him to indexpage. if ( $count == 0 ) { header("location:../index.php"); } Visning av registrerte kurs < course.php > Posisjon: /course.php Mål: Gi brukeren en oversikt over hvilke kurs han/hun er registrete som deltaker i. Vi mener det er viktig å ha en side i applikasjonen som kan vise alle de fagene som er registrert på brukeren. På denne måten kan brukerne gå inn å dobbeltsjekke om alt er som det skal for å unngå problemer når kursene starter opp og brukeren ikke får opp de oppgavene som skal dukke opp. Det er en veldig enkel rutine som sjekker hvilke kurs som er registrert på brukeren ved å sjekke om det er rekker som matcher i user og user_has_course. Så enkelt er det å finne hvilke kurs en spesifikk bruker er deltaker i: SELECT course.shortname, course.name, course.description FROM s2s.user_has_course user_has_course, s2s.course course WHERE user_has_course.course_courseid = course.courseid AND user_has_course.user_userid = '$userid'"; Visning av alle resultater < results.php > Posisjon: /results.php Mål: Gi en fullstendig oversikt over alle resultater som er oppnådd. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

67 Results henter alle resultater som studenten har oppnådd, sortert etter dato oppgaven ble levert inn. Funksjonen på forsiden viser kun de nyeste innleveringene for å ikke fylle opp skjermen Utlogging < logout.php > Posisjon: /logout.php Mål: Logge ut bruker. Logout logger ut brukeren enkelt ved at man fjerner det grunnlaget applikasjonen har for å regne brukeren som innlogget, nemlig session variabelen. Hele logout.php: <?php ## Clear all off the session variables, thus logging user off. session_start(); session_destroy(); header( "location:./index.php" );?> Det den gjør er å slette hele sesjonen og viderekoble til index.php som videre vil viderekoble til login.php. På denne måte blir det bekreftet at sesjonen faktisk er blitt destruert, ellers vil brukeren lande på indekssiden som en fortsatt innlogget bruker. 6.3 Administrative funksjoner S2S er delt opp i to admistrative deler. En del som benyttes av lærer og studentassistent og en annen som benyttes av administrator. Delen for lærere og stud.ass. innehar funksjonalitet for å styre de kursene som de er registrert som lærer i. Først og fremst er det funksjonalitet for å legge til/endre/fjerne oppgaver som er viktigst. Det er også muligheter for å skrive ut en liste med resultater fra oppgavene som er blitt levert inn. Vi kom frem til at det lureste vil være at lærere og studentassistenter har de samme rettigheter. Autentiserings funksjonene er de samme som for hoveddelen, med unntak av en liten endring på spørringen som blir brukt. Spørringen i teacher/auth.inc.php gjøres slik at den unike primærnøkkelen også må eksistere i tabellen teacher_has_course, resten av funksjonene er akkurat likedan som i student/hoveddelen Index side < /teacher/index.php > Posisjon: /teacher/index.php Mål: Gi en oversikt over alle kurs læreren/studentassistent har og gi handlingsmuligheter til de. Denne siden henter ut alle kursene som er registret på læreren eller studentassistenten. Den gir mulighet til å klikke seg videre til øvrig funksjonalitet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

68 Illustrasjon fra index siden. Læreren klikker på en av handlingene og blir lenket videre til neste funksjon Legge til/slette/endre oppgave < addtask.php > Posisjon: /teacher/addtask.php Argumenter: courseid (?courseid=x) Mål: Legge til oppgaver for studenter. Hele grunnlaget for systemet er at det skal kunne legges til oppgaver på en enkel og grei måte, slik at alle skal klare dette. Den største svakheten til det systemet som vi vurderte å videreutvikle, Mefisto, var at det lærere måtte kode inn oppgavene sine manuelt. Som følge av dette var det kun visse lærere som var i stand til å betjene systemet. Vi la derfor mye vekt på det at alle skulle klare å benytte seg av lærerdelen. Skjermbilde fra addtask For å forenkle det å velge dato og tid for frist så har vi lagt til en enkel dato velger skrevet i Javascript. Denne velgeren er hentet fra Scriptet er laget av TengYong Ng og utgitt under GNU GPL 3.0. Dvs. at det er fri programvare, som kan benyttes kostnadsfritt så lenge man publiserer eventuelle endringer man måtte foreta på scriptet. Rutinen for opplastning av Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

69 oppgavedokumentet er den samme som finnes i submissionprocess, som er dokumenter i kapittel Vise alle resultater fra en oppgave < showresults.php > Posisjon: /teacher/showresults.php Argument: courseid Mål: Gi læreren en oversikt og mulighet til å printe ut resultater fra en oppgave. Resultat fra kurs blir listet opp her. Det kan brukes til både og visuelt sjekke hvem som har levert, og hvilket resultat som er oppnådd, samt å selv vurdere de oppgavene som ikke er blitt vurdert. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

70 6.3.4 Admindel ( /admin ) Posisjon: /admin/ Mål: Gi administrator verktøy for å gjøre enkle inngrep som går raskere enn å gjøre inngrep direkte i databasen. Administrator delen er kun tilgjengelig for de som har de høyeste rettighetene. Funksjonene innefatter det å håndtere brukere og kurs. Det er ikke beregnet at administrator skal bruke funksjonen for å legge til brukere for ett helt årskull. Dette gjøres mye raskere ved å lage et skreddersydd import script som putter data direkte i databasen. Det er derfor vi har dokumentert datastrukturene såpass nøye. Funksjonalitet i administrator delen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

71 7 Sikkerhet 7.1 Generelt Sikkerheten i applikasjonen er hele veien blitt tatt til ettertanke. Under programmering av systemet har utviklerne tatt hensyn til hva som kan være scenarioer som kan dukke opp fra ondsinnede brukere. Det har blitt vist store hensyn til at den inputen som blir hentet inn fra brukeren går igjennom ett innebgyd sql-injection filter i PHP. Det skal ikke være mulig for brukere å sende eksekverbare kodesnutter til applikasjonen eller databasen. Den største sikkerhets risikoen slik applikasjonen er per i dag er det at den kommuniserer via en usikret kanal, som HTTP er. En midlertidig løsning kan være at brukere tar i bruk VPN som blir tilbudt av skolen for å kommunisere gjennom en kryptert kanal til HiO. Det er i aller høyeste grad viktig å videreutvikle applikasjonen for å støtte HTTPS slik at man får bedre sikring mot eavesdropping. Vi har valgt og ikke la brukerne bytte passord, ettersom dete utgjør en sikkerhetstrussel. Når det er administratorene som har ansvar for å genere passord så blir det ofte valgt mer gjennomtenkte passord enn det brukere kan finne på å bruke. Det er rett og slett noe vi gjorde for å beskytte brukerne mot seg selv! 7.2 Anonymisering Vi har tatt hensyn til at alt det studentene gjør på S2S skal være anonymt og at det ikke skal kunne spores tilbake til eier. Alle navn og unike identifikasjonsnøkler fra tabellene i databasen er ikke synlig for brukerne. 7.3 Bruker passord Brukernes passord blir lagret i databasen user med en-veis hashen SHA2 5 (US Secure Hash Algorithm laget av NSA). Vi begynte med å bruke MD5, men vi ble frarådet å fortsette med denne hashen ettersom det var kjente hull i den og SHA2 (256-bit) skulle vise seg å være ett bedre alternativ. På denne måte slipper man å risikere at brukernes passord kommer på avveie selv om databasen skulle bli kompromittert. Skulle det være ønskelig kan man lett endre til en annen form for hash i senere tid ved å endre på passord variabelen som finnes i auth.inc.php. Vi tenkte i utgangspunktet at vi skulle bruke det passordet som studentene benytter til andre steder også, så det er kritisk at passordene ikke kommer på aveie! En ulempe ved denne måten å løse det på er at administrator kan ikke på noen måte finne et glemt passord hvis det brukes ett individuelt passord for S2S, med mindre det finnes en liste med passord i klartekst. 8 Samsvar mellom produkt og kravspesifikasjon Vi mener at vårt produkt har innfridd generelle forventninger og kravspesifikasjonen i seg selv og vel så det. Den opprinelige planen for prosjektet var å lage et proof-of-concept (en illustrasjons applikasjon) for oppdragsgiver. Etter hvert innså vi, og etter ønske fra arbeidsgiver, at det var fullt mulig å lage ett system som ville blitt veldig modent i forhold til produksjonsbruk, derfor tok vi den avgjørelsen å satse alt på å lage en fungerende applikasjon for oppdragsgiver. 5 Hentet den fra : Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

72 9 Videreutvikling Prosjektet og applikasjonen gir ett godt grunnlag for å kunne videreutvikles. Kildekoden og applikasjonen er open-source og er tilgjengelig for alle på sourcefourge.net ( Så det kan jo være at noen vil plukke opp tråden og fortsette utviklingen vi har startet med. Applikasjonen slik som den er i dag har noen mangler, men kan raskt ferdigstilles av flere studenter som kommer etter oss. Eller så kan eventuelt applikasjonen testes på ett kurs og Høgskolen kan ta imot tilbakemelding på hva som er bra og hva som er dårlig. Ting som står på listen over fremtidige utvikling er: kryptert kommunikasjons kanal, for eksempel HTTPS. flere funksjoner for lærere og studentassistenter. statistikk generering fra databasen. verktøy for universell utforming (kontrast,forstørrelse og lignende.) varslingsystem per e- mail. automatisert anti- fusk system. rutiner for import og eksport av informasjon til og fra databasen. testing av nettsiden på brukere med nedsatt funksjonsevne. støtte for å laste opp flere filer. load testing med egnet verktøy og påfølgende optimalisering av SQL spørringer. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

73 Testrapport Studentevalueringssystem Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

74 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling v/høgskolen i Oslo. Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har funnet. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

75 Innholdsfortegnelse 1 Forord Forord Innledning Testing Testing av selve systemet Administrator Lærer bruker Student bruker Testing av GUI /Brukergrensesnitt Test bruker student Testperson Testperson Testperson Tilbakemeldinger fra testpersoner Test bruker lærer Testperson Testperson Tilbakemeldinger fra testpersoner...82 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

76 2 Innledning 2.1 Testing Å levere et feilfritt system til oppdragsgiver ligger ganske nært til umulig, det vil alltid dukke opp noe. Derfor er det viktig å dokumentere hva som er testet og hvordan, for å lette arbeidet for de som skal vedlikeholde systemet og finne eventuelle feil. Det første som ble testet, var databasen og sql spørringer. Dette testet vi selv uten å bruke testpersoner. Deretter var det GUI som ble testet. Vi utviklet en papir prototype for å først få et bilde av hvordan vi så for oss at grensesnittet skulle være, deretter ble det testet på vanlige brukere. Vi fikk veldig god tilbakemelding, og selv om det ble lagt stor vekt på programmerings biten av databasen og ramme verket så har det ikke vært så mye tid til testing av GUI. Vi tok godt tak i de få tilbake meldingene vi hadde fått og forbedret så godt vi kunne. Testingen var delt i tre forskjellige deler, Administrator delen, student bruker delen og lærer delen. Gruppen valgte en iterativ uvikling av systemet. Dette innebar at systemet ble ferdigstilt modul for modul. En ny modul ble aldri påbegynt før den sist utviklede modulen viste seg å fungere som forventet. I hovedprosjekt blir det som oftest fokusert på funksjonell testing, og vårt prosjekt var intet unntak. Vi startet med såkalt glass-box testing, hvor man bruker kjennskap til koden for å gå igjennom systemet å kjøre tester. Senere når det ble satt mer fokus på at modulene gjorde det de skulle, brukte vi black-box testing, altså matet systemet med testdata for å teste hvilken tilbakemelding det ga. Her trengs ikke kjennskap til koden. 3 Testing av selve systemet Testingen var delt i tre forskjellige deler, Administrator delen, student bruker delen og lærer delen. Gruppen valgte en iterativ uvikling av systemet. Dette innebar at systemet ble ferdigstilt modul for modul. En ny modul ble aldri påbegynt før den sist utviklede modulen viste seg å fungere som forventet. 3.1 Administrator Logg Inn Funksjon Testet Kommentar Logg inn At logg inn fungerte optimalt OK Logge inn med inkorrekt Man for ikke logget inn OK bruker navn og passord Logge inn som admin, student, lærer, studass og ha de riktige rettighetene tildelt. At de forskjellige brukergrupper hadde sine forhåndsbestemte rettigheter både på legge til, slett og vurderings type. OK Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

77 3.1.4 Legge til Bruker Funksjon Testet Kommentar Legge til bruker. Tester om administrator kan OK legge til en bruker, med kurs Slette Bruker Funksjon Testet Kommentar Slette bruker. Slette en bruker og undersøke OK om all data er blitt borte Opprette kurs Funksjon Testet Kommentar Legge til kurs i databasen Trykk på legg til, legge inn fag OK navn, fagkode Slette kurs Funksjon Testet Kommentar Klikke på slett kurs Navigert videre til en tabell med fag listet opp. Kunne klikke på tittel og videre klikke på slett fag. Feil i databasen.feil I spørringene regber med å rette opp feilen før fristen for innlevering av rapport Redigere eksisterende kurs Funksjon Testet Kommentar Redigere kurs Linken redigere kurs er klikk bar. Man kan endre på de forskjellige feltene og klikke på rediger kurs. OK Legge til studentassistent til kurs Funksjon Testet Kommentar Legge til studentassistent til Klikke på de forskjellige OK kurs kurskodene Finner e-post til studentassistent bruker Skrive inn e-posten og at brukeren blir funnet Skal funke men ikke nok test data lagt inn. Feilmelding En feil melding dukker opp hvis man ikke skriver inn e- post OK Legge til lærer til kurs Funksjon Testet Kommentar Legge til lærer til kurs Klikke på de forskjellige OK kurskodene Finner e-post til lærer bruker Skrive inn e-posten og at brukeren blir funnet Skal funke men ikke nok test data lagt inn. Feilmelding En feil melding dukker opp hvis man ikke skriver inn e- post OK Logg ut Funksjon Testet Kommentar Logg ut Logget ut av systemet OK Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

78 3.2.1 Lærer bruker Logg Inn Funksjon Testet Kommentar Logg inn At alt logg inn fungerte OK optimalt Logge inn med inkorrekt bruker navn og passord Man for ikke logget inn OK Legg til oppgave Funksjon Testet Kommentar For opp en tabell Kunne fylle på alle felt OK Kalender for dato Kunne velge dato fra kalender OK Laste opp oppgave Klikke på lat opp, velge fil. Se OK at det blir lagt til i tabellen Vurdering Velge vurderingstype, Bestått, ikke bestått eller karakter OK Redigere oppgave Funksjon Testet Kommentar Redigere oppgave Kunne klikke på forvalgt tittel OK Kunne velge dato fra kalender OK Laste opp oppgave Klikke på lat opp, velge fil. Se OK at det blir lagt til i tabellen Vurdering Velge vurderingstype, OK Bestått, ikke bestått eller karakter Redigere oppgave At man kan klikke på rediger oppgave.en bekretelse dukker opp OK Slett oppgave Funksjon Testet Kommentar For opp en tabell Kunne klikke på tittel OK Vis resultater for oppgave Funksjon Testet Kommentar For opp en tabell Kunne klikke på de forskjellige OK fagene Få opp en tabell med oppgaver innenfor et fag Kunne se resultater med karakter, antall vurderinger, info om student OK Logg ut Funksjon Testet Kommentar Logg ut Logget ut av systemet OK Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

79 3.3 Student bruker Logg inn Funksjon Testet Kommentar Logg inn At alt logg inn fungerte OK optimalt Logge inn med inkorrekt bruker navn og passord Man for ikke logget inn OK Hovedsiden Funksjon Testet Kommentar Oversiktlig tabell over arbeid som skal leveres Kunne se vurderingsformen, fag tittel, oppgave tittel, Fag kode, frist for innlevering og antall personer som kan samarbeide. OK Handlinger under arbeid som skal leveres Oversiktlig tabell over rettet arbeid Oversiktlig tabell over arbeid som skal rettes Kunne klikke på last opp oppgave ikonet og ser på oppgave info ikonet. Rettet arbeid Kunne klikke på ikonet rette. OK OK OK Laste opp oppgave for innlevering Funksjon Testet Kommentar Laste opp oppgave At laste opp funker OK Legge til studenter Skrive student nr og navn og OK trykke på legg til Laste opp oppgave I alle fag At laste opp funker under alle fag OK Linker Funksjon Testet Kommentar Trykke på logo Komme til hovedsiden OK Trykke på de forskjellige linkene Komme til riktig url OK Logg ut Funksjon Testet Kommentar Logg ut Logget ut av systemet OK Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

80 4 Testing av GUI /Brukergrensesnitt For å teste brukergrensesnittet var det nettsiden som vi hadde opprettet underveis som s2s databasen ble satt opp som ble brukt. Som nevnt tidligere i test rapporten, så ble det utviklet en papir prototype for å få et bilde av hvordan vi så for oss at brukergrensesnittet skulle være, men papirprototypen ble ikke testet på testpersonene, vi valgte heller å bruke en reel side når den ble opprettet. Nettsiden var ikke kommet så langt når den ble testet av testpersonene men det var ikke noe vanskeligheter med å forstå hvordan man skulle navigere seg rundt i siden. Det ble forklart hva siden skulle brukes til før de skulle logge inn og deretter prøve seg rundt. Testingen ble fordelt på to brukere, testing av lærer bruker og testing av student bruker 4.1 Test bruker student Testen ble utført på tre studenter fra Høgskolen i Oslo med ulik IT erfaring og data kunnskaper. Testpersonene ble fortalt om hovedprosjektet og litt om hensikten med s2s systemet. Vi var objektive og holdt oss kun til fakta slik at testpersonen ikke ble påvirket av informasjonen eller gruppa. Vi brukte gruppens bærbare Macbook Pro til å utføre testen. Testen gikk utpå at de selv skulle logge inn og navigere rundt i siden og prøve seg på forksjellige arbeidsoppgaver som ble gitt underveis. Selve testen var delt i to faser. Den ene fasen forgikk slik at en person fra gruppen fungerte som Intervjuer. Der skulle vi finne ut litt om alder, kjønn, bakgrunn, hva de tror de vil få ut av en student evalueringssystem og generelt om hva de forventer av et slikt system. Oppgaver som ble gitt: 1. Logge inn 2. Se resultater 3. Rette en oppgave 4. Levere oppgave 5. Se resultater 6. Legge til personer i en oppgave 4.2 Testperson 1 Den første vi testet var en tilfeldig anvendt datateknologi student fra andre klasse, Amin Hamrioui. Personen fikk et passord og brukernavn å logget seg på, det var ingen problem for test personen å navigere rundt i siden. Testpersonen forsto intuitivt hva som skulle gjøres med de forskjellige funksjonene. Og helhetlige viste god data forståelse. Testpersonen fulgte en liste med få instruksjoner som skal vise systemets hovedfunksjonalitet. Å logge på var meget greit, laste opp oppgave var også noe som var godt kjent, vurdere en oppgave var også enkelt. Personen var meget verbal og navigerte ganske raskt gjennom oppgavene. 4.3 Testperson 2 Denne test personen var en kvinnelig student fra SAM avdelingen, Barnevernspedagog. Personen ville være anonym. Test personen spurte underveis om hva som skulle gjøres og trengte noe veiledning under oppgavene. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

81 Personen hadde generelle datakunnskaper men ikke så godt kjent med utvikling og systemer, dermed tok det litt tid for å forstå hva som skulle gjøres. Personen var ganske treg i navigasjonen og løste kun oppgavene uten å navigere spontant. Testpersonen brukte mer tid en de andre testpersonene, men alt i alt forsto hva som skulle gjøres når hun fikk prøvd seg frem. 4.4 Testperson 3 Den siste testpersonen var en mannlig student fra tredje året i Anvendt Datateknologi. Testpersonen var godt kjent med høy programmering og hvordan man bruker datasystemer. Testpersonen var en av de som brukte kortest tid til å sette seg i oppgavene og navigerte ganske dynamisk rundt i systemet. Personen snakket ikke så mye så vi måtte spørre underveis om synsinger og meninger. 4.5 Tilbakemeldinger fra testpersoner Hva er ditt helhetlige inntrykk av s2s? Testperson 1: Hva er ditt helhetlige inntrykk av s2s? Veldig bra system med korte og greie arbeidsoppgaver. Lærerikt og vil gi en student veldig mye tilbake i form av hvordan man velger å svare på en oppgave. Jeg ville vært veldig positiv til systemet i dag. Testperson 2: Bra at dere har fått dette til, kunne vært mer spennende brukergrensesnitt. Lurer på om det vil lette lærerens arbeidsoppgaver og gi mer jobb til studenter. Ikke så begeistret over at man må levere sin egen oblig og mulig fire andres. Men tviler ikke på at man vil oppnå en bedre karakter ut av dette systemet. Testperson 3: Det er vel funksjonalitet som telles her fra et system som er utviklet fra bunn av så det var veldig imponerende. Ganske enkelt å sette seg inn i, kjenner igjen de fleste funksjonene. Greit konsept av s2s, man blir flinkere i å løse oppgaver og lærer mer ved å rette andres obligatoriske arbeid. 4.6 Test bruker lærer Testen ble utført på høgskolelektor for Data Tor Krattebøl og vår egen veileder og master student Emine Gocmenoglu. Testpersonene ble fortalt om hovedprosjektet og litt om hensikten med s2s systemet. Vi var objektive og holdt oss kun til fakta slik at testpersonen ikke ble påvirket av informasjonen eller gruppa. Vi brukte gruppens bærbare Macbook Pro til å utføre testen. Testen gikk utpå at de selv skulle logge inn og navigere rundt i siden og prøve seg på forksjellige arbeidsoppgaver som ble gitt underveis. Oppgaver som ble gitt: 1. Logge inn 2. Se resultater 3. Redigere oppgave Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

82 4. Legge til oppgave 5. Legge til personer i en oppgave 6. Slette oppgave 4.7 Testperson 4 Testpersonen var en mannlig lærer og høyskole lektor ved data avdelingen i Høgskolen i Oslo. Han kan det meste om brukertesting og var veldig obs på at vi hadde noe å skrive med mens vi observerte. Testpersonen brukte relativt kort tid på å navigere rundt i siden. Alt var for det meste ganske opplagt. Brukte tid på å lese tekst forklaringer i siden for å forstå hva vi mente med teksten. Testpersonen kom med ganske konstruktiv kritikk som vi er ganske enig med og det var vel stort sett brukergrensesnitt som ikke var helt i samkjør med de fleste brukervennlige reglene. Brukeren løste alle oppgaver i kort tid og alt var greit. Designet var greit, forsto ikke helt hvorfor vi valgte å sette menyen inni en ramme men syntes at det var greit. 4.7 Testperson 5 Testpersonen var en kvinnelig veileder og masterstudent i ingeniør avdelingen. Hun har godt kjennskap til systemet s2s og ble overasket over systemets backend. Testpersonen fulgte alle instrukser uten noe som helst veiledning. Var veldig rask i navigeringen men stilte en del spørsmål underveis. 4.8 Tilbakemeldinger fra testpersoner Testperson 4: Det er vel funksjonalitet som telles her fra et system som er utviklet fra bunn av så det var veldig imponerende. Ganske enkelt å sette seg inn i, kjenner igjen de fleste funksjonene. All funskjonalitet var ganske opplagt. Forsto ikke helt hvorfor det sto Index Lærer, ville at vi enten bruker ordet home, hjem eller startsiden. Det skulle ha vært lagt til en avbryt knapp under slette og redigere tilfelle man angrer. Alt i alt ganske enkelt, litt kjedlig design. Testperson 4: Greit design. Burde fått til bedre tilleggsfunksjonalitet som for eksempel slette en lærer/ studentassistent knapp til et kurs. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

83 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

84 Brukermanual Studentevalueringssystem Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

85 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre deler beskrivelse for student bruker, lærer og admin bruker. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

86 Innholdsfortegnelse 1 Forord Forord Innledning Om bedriften Mål Rammebetingelser Systemets funksjonalitet Admin- bruker Student bruker Lærer bruker...99 Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

87 3 Innledning 3.1 Om bedriften Høgskolen i Oslo er landets største statlige høgskole med studenter og 1250 tilsatte. HiO har sju avdelinger med 33 bachelor studier og 18 masterstudier. En så stor utdanningsinstitusjon med så mange studenter krever mye av lærere og studentassistenter så et slikt evaluerings system vil definitivt være med å lette de ansattes hverdag på en positiv måte. Foreløpig vil systemet være fokusert på datastudenter og vil ikke omfatte alle avdelinger i Høgskolen i Oslo. 3.2 Mål De sentrale mål for systemet er hovedsakelig det som kreves for at systemet skal fungere riktig i forhold til miljøet og arbeidsplassen. Systemet bør: gjøre det mulig for studenter å vurdere hverandres arbeid. gi vurderinger som er troverdige og kan benyttes som at de er riktige, dvs. at det ikke skal være mulighet for fusk. være trygt nok til at man ikke kan bryte seg inn å legge inn falske resultater. holde orden på hvem som har tilgang til å rette oppgaver og at den som har rettet en oppgave ikke har rett til å rette samme oppgave igjen. opprettholde personvernet til den enkelte. være 100% nettbasert. være åpen kildekode og fritt tilgjengelig. Funksjonalitet som kan implementeres er: varsel på /sms når du skal evaluere en oppgave, eller har mottat resultater. 3.3 Rammebetingelser Gruppen står fritt til å velge hvilket språk vi vil benytte for å programmere applikasjonen. Vi står også fritt til å velge hvilken grad applikasjonen skal være ferdig utviklet. I utgangspunktet tenker vi i arbeidsgruppen at vi må modellere/beskrive systemet 100% og minst lage en proof-of-concept applikasjon. Gruppen planlegger å bruke PHP som programmeringsspråk og MySQL som database verktøy, ettersom det er disse verktøyene vi har mest erfaring med når det gjelder programmering av web-løsninger. Uansett kan man jo tilpasse applikasjonen relativt enkelt til å benytte annen database programvare. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

88 4 Systemets funksjonalitet 4.1 Admin- bruker Administrasjon brukeren skal kunne vedlikeholde systemet. De andre brukerne skal kunne logge inn med brukernavn og passord tildelt av administrator. Figur 1 Logg inn for admin 1.Klikk Logg inn for å komme til startsiden Administrasjon kommer inn på hovedsiden der man kan håndtere både kurs og brukerhåndtering. På hovedsiden kan man velge mellom flere funksjoner hvis man peker med musepekeren under et av funksjonene og klikker vil man bli ført videre til neste handling. Når man peker med musepekeren under f.eks slett kurs vil ordet slettkurs være understreket noe som betyr at det er en link. 2. Klikk på Opprett kurs / Slett Kurs / Rediger eksisterende kurs /Legg til studentaasistent eller Legg til lærer til kurs Figur 1.1 Hovedsiden for admin Opprett kurs Under opprett kurs vil man kunne legge til kurskode under feltet kurskode, kursets tittel og en beskrivelse hvis man ønsker det. Deretter klikker man på legg til. Man vil da få en bekreftelse på at kurs er lagt til og siden navigeres automatisk til hovedsiden igjen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

89 3. Klikk på Legg til Figur 1.2 Opprett kurs Slette kurs Under slette kurs kommer man frem til en tabell med alle kurs. Klikke på valgte kurskode for å navigere videre til valgte kurs å slette. Man vil da få en bekreftelse på at kurs er slettet og siden navigeres automatisk til hovedsiden igjen. Man må være oppmerksom på at hvis man velger å slette ett fag som innholder oppgaver, innleveringer eller vurderinger så vil også disse bli slettet fra databasen. 4. Klikk på kurskode. Figur 1.3 Slette kurs Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

90 4.1.3 Redigere eksisterende kurs Klikker man på redigere eksisterende kurs kommer man til tabell over kurs å redigere. Man klikker da på valgte kurskode. 5. Klikk på kurskode. Figur 1.4 Redigere eksisterende kurs Under rediger eksisterende kurs skal man skrive inn kurskode under feltet kurskode, kurstittel og beskrivelse. Klikke deretter på Rediger kurs. Man vil da få en bekreftelse på at kurs er redigert og siden navigeres automatisk til hovedsiden igjen. 6. Klikk på Rediger kurs. Figur Redigere eksisterende kurs Legg til studentassistent til kurs Klikker man på legg til studentassistent til kurs kommer man til en tabell over kurs med studentassistenter. Man klikker da på valgte kurskode. 7. Klikk på kurskode. Figur 1.5 Legg til studentassistent til kurs Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

91 Videre navigeres man til denne siden hvor man skriver inn på brukeren og klikker på legg til. 8. Skriv inn adressen på felt. 9. Klikk på Legg til. Figur Legg til studentassistent til kurs Legg til lærer til kurs Klikk på legg til lærer til kurs på hovedsiden for å komme videre til tabellen under. En liste over lærere til de forskjellige kurs kommer opp. Klikk på Kurskode. 10. Klikk på kurskode. Figur 1.6 Legg til lærer til kurs Videre navigeres man til denne siden hvor man skriver inn på brukeren og klikker på legg til. 11. Klikk på Legg til. Figur Legg til lærer til kurs Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

92 4.1.6 Logg ut Utlogging skjer automatisk etter en begrenset periode hvis man ikke er aktiv i admin siden. Innlogging siden dukker opp igjen. 4.2 Student bruker Logg Inn Student skal kunne logge inn med brukernavn og passord som man har fått tildelt i starten av skoleåret. 1.Klikk Logg inn for å komme til startsiden Figur 2.1 Logg inn for student bruker Studenten kommer til startsiden der har man flere valg. Oversikten man for opp kommer an på om studenten har noe arbeid som må leveres, arbeid som må rettes eller resultater som skal vises. Man kan trykke på logoen s2s for å også komme tilbake til hovedsiden eller trykke på Hovedsiden under brødsmulene. Menyen er stilt inn øverst horisontalt og innholder alt av funksjonalitet som skal brukes i s2s. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

93 Hovedsiden: Figur 2.2 Hovedsiden for student bruker Leveranse av individuell oppgave 3.Leveranse av oppgave 4. Trykk for å se info om filen Figur 2.3 Leveranse av individuell oppgave Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

94 Hvis man har Arbeid som skal leveres Trykker man på (3.Laste opp oppgave). Har man ingen oppgave å laste opp for å levere inn for man heller ikke dette opp i startsiden. 5. Trykk Bla gjennom for å laste opp. 6. Legge inn kommentar er valgfritt Figur Leveranse av individuell oppgave 7. Trykk ferdig for å sende inn. Ved en vellykket opplastning for du opp dette bilde: Figur Leveranse av individuell oppgave Alt slags filformater støttes foreløpig. Hvis man ikke laster opp noe fil og trykker på 7. Ferdig hvil man få en feil melding Leveranse av gruppe oppgave Samarbeidstype ; 4 studenter. 8.Trykk for Leveranse av oppgave Figur 2.4 Leveranse av gruppe oppgave Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

95 9. Skriv inn studentnummer til samarbeids partnere Figur Leveranse av gruppe oppgave 12. Trykk ferdig for å sende inn. 10. Trykk på Legg til for å legge til studentnummeret som ble tastet inn. 11. skrive inn kommentar under kommentar feltet er valgfritt. Ved en vellykket opplastning for du opp dette bilde: Figur Leveranse av gruppe oppgave Alt slags filformater støttes foreløpig. Hvis man ikke laster opp noe fil og trykker på 12. Ferdig hvil man få en feil melding Se resultater 13. Trykk på Resultater da vil oversikt over alle vurderingene i de forskjellige fag vises. Figur 2.5 Se resultater Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

96 4.2.6 Arbeid som skal rettes 14.Trykk på handling for å komme til neste side. Figur 2.6 Arbeid som skal rettes I hovedsiden står det også arbeid som skal rettes av studenten. Dette har studenten fått tilfeldig tildelt av systemet. 15.Her skal dokumentet være tilgjengelig for nedlastning 17. Velg karakter. 16.Her skrives eventuelle kommentarer inn(valgfritt) Figur 18. Trykk på lever vurdering Arbeid som skal leveres Arbeid som er rettet forsvinner da fra tabellen Arbeid du skal rette fra Hovedsiden. Det vil da se slik ut på bilde under. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

97 Figur Arbeid som skal leveres Arbeid som er rettet ferdig Alt av arbeid som har blitt vurdert legges under arbeid som er rettet ferdig. Man kan også se vurderingen under linken resultater. De forskjellige karakterene vises samt den gjennomsnittlige og endelige karakteren på oppgaven. Den gjennomsnittlige karakteren skal vises under Vurderinger. Figur 2.7 Arbeid som er rettet ferdig Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

98 4.2.7 Registrerte Fag Figur 2.8 Registrertefag 13.Tykk på registrerte fag. for å få oversikt over registrerte fag som studenten er deltager i. Studenten for opp en tabell med liste over fag er registrert med han som deltager. Figur Registrerte fag Menyen Menyen står øverst horisontalt under den sorte linjen. Her har man tilgang til Fronter som fører deg til linken fronter for HiO. Om s2s tar deg videre til linken bloggen project s2s. Og hjelp funksjonen som gir deg en kortfattet tekst om hva som skal gjøres under de forskjellige stedene i siden. Figur 2.9 Meny Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

99 4.2.9 Logg ut Når man logger ut av s2s trykker man på Logg ut under menyen. Man navigeres ut og til innloggingssiden igjen. Figur 2.10 Logg ut 14. Trykk på logg ut for å navigere ut av siden. 4.3 Lærer bruker Logg inn Lærer skal kunne logge inn med e-post og passord som man har fått tildelt av skolen. 1. Klikk på logg inn. Figur 3 Logg inn for lærer Lærer blir navigert inn på hovedsiden. Fag er satt opp i tabeller og i hver tabell er det handlinger man kan gjøre i det faget. For hvert fag kan man legge til oppgave, redigere oppgave, slette oppgave eller vis resultater for oppgave. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

100 2. Klikk på en av de valgte handlingene. Figur 3.1 Hovedsiden for lærer Legg til oppgave Under handlingen Legg til oppgave vil man kunne registrere en oppgave. Skriv inn oppgavetittel på feltet under oppgavetittel. Det er valgfritt om man vil skrive inn oppgave beskrivelse. På feltet frist klikker man på kalender ikonet for så å velge en dato for når fristen for innleveringen av oppgaven skal være. Velg deretter vurderingsform av oppgaven. 3. Skriv inn på oppgavetittel feltet. 4. Skriv i oppgave beskrivelse feltet. 5. Klikk på kalender ikonet. 6.Velg dato og tid.klikk på valgt dato. Figur 3.2 Legg til oppgave Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

101 Kalender tabell vil komme frem. 5. Klikk på kalender ikonet. 6.Velg dato og klikk på valgt dato. 7. Velg vurderingsform Figur Legg til oppgave 8. Klikk på Bla gjennom, og velg fil. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

102 Ved å skrive inn antall vurderinger bestemmer du antall tilfeldige som skal rette oppgaven og gi vurdering. 9. Skriv inn antall vurderinger. 10. Skriv inn antall personer som kan samarbeide om en oppgave. Figur Legg til 11. Klikk på legg til oppgave. oppg. Man vil da få en bekreftelse på at oppgave er lastet opp og siden navigeres automatisk til hovedsiden igjen Rediger Oppgave Handlingen rediger oppgave gir deg mulighet til å redigere en oppgave som allerede er listet opp på en tabell. 12. Klikk på en tittel. Figur 3.3 Rediger oppgave Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

103 Alle felt er nå åpne for endring. Etter å ha klikket rediger oppgave, kommer man til en side med bekreftelse på at oppgave er redigert og siden navigeres automatisk ut til hovedsiden igjen. 13. Klikk på Rediger oppgave. Figur Rediger oppgave 3.4 Slett oppgave Handlingen slett oppgave gir deg mulighet til å slette en oppgave. Alle oppgavene står listet opp i en tabell. 14. Klikk på et tittel til en oppgave du vil slette. Figur 3.4 slett oppgave Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren

104 4.3.5 Vis resultater for oppgave 15. Klikk på tittelen til oppgaven du vil resultatene av. Figur 3.5 Vis resultater for oppgave Resultater for oppgaver innenfor et fag listes opp i en tabell. Figur Vis resultater for oppgave Logg ut Utlogging skjer automatisk etter en begrenset periode hvis man ikke er aktiv i admin siden. Innlogging siden dukker opp igjen. Høgskolen i Oslo Hovedprosjekt i Anvendt datateknologi, våren