Teknologi, Kunst og Design Høgskolen i Oslo og Akershus, Våren Marius Skalstad. Guro Asbjørnsen. Eigil Johansen

Størrelse: px
Begynne med side:

Download "Teknologi, Kunst og Design Høgskolen i Oslo og Akershus, Våren 2015. Marius Skalstad. Guro Asbjørnsen. Eigil Johansen"

Transkript

1 Teknologi, Kunst og Design Høgskolen i Oslo og Akershus, Våren 2015 Sted: Høgskolen i Oslo og Akershus, Oslo Tittel: Oslo vaksineklikk Nettsted for timebestilling ved Oslo vaksineklinikk Prosjektmedlemmer: Ester Jansson Marius Skalstad Guro Asbjørnsen Eigil Johansen Oppdragsgiver: Dr. Mohammed Usman Akram Kontaktperson: Dr. Mohammed Usman Akram 1

2 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. Telefon: TILGJENGELIGHET Telefaks: Begrenset HOVEDPROSJEKTETS TITTEL BACHELORPROSJEKT DATO Oslo vaksineklinikk Nettsted for timebestilling ved Oslo vaksineklinikk PROSJEKTDELTAKERE Ester Jansson s Guro Asbjørnsen s Marius Skalstad s Eigil Johansen s OPPDRAGSGIVER Dr. Mohammed Usman Akram ANTALL SIDER / BILAG 99 INTERN VEILEDER Thor Hasle KONTAKTPERSON Dr. Akram SAMMENDRAG Oslo vaksineklinikk er nettsted utviklet for å bestille time for vaksinering og et forum for informasjon om vaksine- og reiseråd. Sentrale funksjoner på dette nettstedet er: Mulighet for bestilling av time Formidling av informasjon om vaksiner Diskusjonsforum Tilgjengelig for bruk på alle plattformer Lagt til rette for videreutvikling 3 Stikkord Databaser Vaksineklinikk PHP 2

3 Forord Denne rapporten dokumenterer et arbeid der fire studenter fra Høgskolen i Oslo og Akershus har samarbeidet om et hovedprosjekt som en avslutning av bachelorløpet. I denne prosessen har vi benyttet oss av de erfaringene vi har fått gjennom vår bachelorutdanning ved HiOA. Oppgaven har blitt relativt omfattende for å kunne være ett produkt som kan lanseres for allmenn bruk. Med denne rapporten ønsker vi å gi oversikt og en bedre beskrivelse av arbeidet vi har gjort vårt siste semester ved Høgskolen i Oslo og Akershus. Rapportens målgruppe er i hovedsak produktets interessenter, veileder og sensorer. Dette dokumentet er i hovedsak ment for sensorene og oppdragsgiveren vår. Rapporten vil også være til hjelp for personer som skal videreutvikle systemet vi har lagd. På grunn av dette, vil denne dokumentasjonen kreve noe bakgrunnskompetanse innen webutvikling. Det vil også være gitt en ordliste over de ordene som kan være vanskelig å forstå. Ferdigstillelsen av dette prosjektet ville ikke vært mulig uten vår veileder Thor Hasle. Han har vært til stor hjelp og har bidratt med å holde oss på rett kurs med svært gode innspill og tips. Vi har vært svært heldige når det gjelder veileder og han har vært en stor bidragsyter i å holde gruppens motivasjon oppe, spesielt når vi følte vi ikke kom noen vei. På grunn av dette har vi fått et klarere perspektiv når det gjelder oppgaven, og våre evner. Vår oppdragsgiver Dr. Akram har vært svært entusiastisk ovenfor vårt prosjekt. Han har kommet med svært mange gode ideer gjennom hele prosjektet. Han skal ha mye av æren for å ha kommet på ideen. Han har under hele prosjektet gitt oss mye selvstendighet og kreativ frihet til å forme produktets struktur etter den visjonen som han først tenkte seg. Vi vil med dette takke dere begge for muligheten vi fikk for å gjøre dette prosjektet og vi setter utrolig pris på all støtten vi har mottatt. 3

4 Innholdsliste BACHELORPROSJEKT... 2 Forord... 3 Sammendrag... 7 Del 1 - Presentasjon Om gruppen Oppgaven Oppdragsgiver Veileder Mål Prosess Del 2 Produktdokumentasjon Rammebetingelser Kravspesifikasjon Pålitelighet Sikkerhet Brukervennlighet Benyttede dataspråk HTML CSS PHP JavaScript SQL Nettstedet Forsiden Timebestilling Vaksinekart Fakturasystem

5 2.3.5 Betaling Diskusjonsforum Administrasjonssiden Mindre, men viktige funksjoner Sentrale funksjoner Brukertyper Sikkerhet Teknisk arkitektur Design og universell utforming Tekst og lesbarhet Bilder Språkvalg Fargevalg Kontraster Gestaltlovene Layout Lyd Universell Utforming WCAG Del 3 Prosessdokumentasjon Mål Bakgrunn for prosjektet Kravspesifikasjon Metode og Planlegging Produktutvikling Arbeidsteknikker Gruppearbeid Gruppens kommunikasjon Verktøy

6 3.6.1 Dropbox Facebook Google Dokumenter Bootstrap Netbeans PhpMyAdmin XAMPP Produkttesting Formål med brukertest Hvilket deler av programmet skal testes? Metode og organisering Resultat Konklusjon Videre utvikling Del 4 - Avslutning Læreutbytte Læreutbytte prosess Læreutbytte produkt Læreutbytte dokumentasjon Kunne vi gjort noe annerledes? Fremtidsutsikter for produktet Oppsummering og konklusjon Del 5 - Kilder Del 6 - Vedlegg

7 Sammendrag Under dette prosjektet, har gruppen utviklet et nettsted hvor brukere skal kunne bestille time for vaksinering. Oppdragsgiver ønsket seg et animert verdenskart hvor brukeren skulle kunne få opp informasjon om et bestemt reisemål, og et forum hvor brukere skulle kunne stille eller lese andre sine spørsmål. Gruppen bestemte seg tidlig for å arbeide etter prosessmodellen scrum, og fant en applikasjon med navn Projectplace, hvor vi kunne delegere oppgaver oss i mellom. Gruppen har delt filer i Dropbox og kommunisert over Facebook. Målet gruppen satte seg før arbeidet startet, var å skape et intuitivt og enkelt nettsted som var oversiktlig. Oppdragsgiveren ønsket det så enkelt som mulig, med minst mulig klikk for å nå ut til flest brukere. Det ferdigstilte produktet er et nettsted der kunder kan bestille time til vaksinering eller en annen type helsesjekk. Brukere kan nytte seg av et diskusjonsforum for reise- og helserelaterte spørsmål og svar. Dette forumet er også en måte å få direkte kontakt med legen på klinikken. Nettstedet har også ett vaksinekart der brukere kan klikke seg fram til informasjon om hvilke vaksiner de trenger til reisemålet sitt. I produktet er det også levert en administrasjonsside for enkelt å holde oversikt over diskusjonsforumet og brukere av nettstedet. Produktet kan nås midlertidig på 7

8 Del 1 - Presentasjon 1.1 Om gruppen Gruppe 21 består av Marius Skalstad, Guro Asbjørnsen, Eigil Johansen og Ester Jansson. Guro, Eigil og Ester går Anvendt Datateknologi og Marius går Dataingeniør. Gruppen er alle tredjeårsstudenter ved Høgskolen i Oslo og Akershus. Gruppen jobber svært godt sammen. Hvert gruppemedlem har forskjellige egenskaper og ulike interessepunkter. Dette har bidratt til at det har vært svært enkelt å fordele ansvar mellom gruppemedlemmene og gitt gruppen et bredt kunnskapsområde. 1.2 Oppgaven Oppdragsgiver gav gruppen i oppgave å lage et nettsted til en vaksineklinikk som han ønsker å realisere i løpet av høsten På dette nettstedet ønsker oppdragsgiveren å ha ulike funksjoner implementert. Gruppen fikk nevnt i oppgavebeskrivelsen at det bør være linker til råd for ulike vaksiner avhengig av hvilket land brukeren skal reise til. Muligens kan man lage en animasjon av en globus hvor man trykker på en verdensdel. Deretter skal man komme til informasjon om hvilke vaksiner man behøver for reisen. I sluttproduktet skal det følge med et diskusjonsforum hvor brukere kan legge ut spørsmål som kan besvares. Oppdragsgiver ønsker en layout som er brukervennlig for pasienter, et innebygd system for faktura og at sikkerheten er opp til en viss standard slik at opplysninger ikke kommer på avveie. 8

9 Videre ville oppdragsgiver at gruppen skulle trekke inspirasjon fra Reiseklinikken 1, selv om det nettstedet er veldig uoversiktlig, så skal mye av innholdet være det samme på sluttproduktet Oppdragsgiver Oppdragsgiveren og kontaktperson er en lege ved navn, Mohammed Usman Akram. Han jobber som turnuslege ved Skien sykehus og var ferdig utdannet ved Universitet i Oslo, UiO, i Han ønsker å etablere et vaksinekontor som han vil gå over til når han er ferdig med den siste praktiske delen av utdanningen sin. Det er her gruppens oppgave kommer inn Veileder Gruppens veileder i dette prosjektet er Thor E. Hasle 2. Han er førstelektor på Institutt for informasjonsteknologi på HiOA. Han har skrevet en rekke fagbøker blant annet om systemutvikling og nettverksadministrasjon. I tillegg har han gode kunnskaper om datasikkerhet og IT-tjenester, da han foreleser i dette Mål Målet med denne oppgaven er å konstruere et nettbasert system som gruppens oppdragsgiver kan benytte seg av uten hindringer og som han selv kan tilpasse dersom det blir behov for dette

10 1.3 Prosess Utviklingsprosessen begynte med en planleggingsfase. I denne fasen fastsatte gruppen hvilke krav man hadde for prosjektet, teknologi man ønsket å bruke og hvilken arbeidsmetodikk gruppen følte var mest fordelaktig å benytte. Sammen kom gruppen raskt frem til at man ønsket å benytte et rammeverk og deretter tilpasse den slik at den ville fungere optimalt for nettstedet og de funksjoner gruppen selv legger til. Som arbeidsmetode valgte gruppen å bruke scrum, som er en smidig prosessmodell som egner seg godt til denne type oppgaver. Dette rammeverket er laget med hensikt for å utvikle større informasjonssystemer. Gruppen brukte derfor litt tid på å sette seg inn i denne arbeidsmetoden. Etter at gruppen hadde kommet frem til type arbeidsmetode, satte gruppen seg ned for å planlegge hvor mange sprinter gruppen skulle ha, som er en stor del av prosessmodellen til scrum. Gruppen begynte å benytte seg av et nettbasert hjelpemiddel kalt Projectplace, som er et hjelpemiddel hvor man legger opp oppgaver som skal gjøres, den som vil ta den oppgaven velger den og oppgaven blir lagt i midten og blir markert som Arbeides med, når denne oppgaven er fullført, fullfører man oppgaven i applikasjonen og oppgaven blir vist som fullført. Etterhvert som utviklingen i prosjektet kom lengre, kom gruppen frem til at scrum ikke var helt den rette prosessen og gruppen valgte heller å fordele arbeidet best mulig mellom medlemmer og deres kompetanse. Gruppen endte opp med å jobbe i en tilpasset type av scrum. Gruppen fikk en deadline til rett etter påskeferien, og denne fristen forholdet gruppen seg til. Rett før påskeferien hadde gruppen kommet relativt langt, men på grunn av flere ekstra funksjoner gitt av oppdragiver, ble fristen utsatt til slutten av mai, som var ved samme tid som gruppens dokumentasjon måtte være ferdigstilt. Gruppen satte av omtrent en måned for å fullføre sluttdokumentasjonen. 10

11 De aller fleste funksjonene oppdragsgiveren ønsket ble implementert i produktet. Det var et par funksjoner som ble svært vanskelige å implementere, men etter et par diskusjoner kom gruppen frem til optimale løsninger og alternativer. Det har også blitt lagt til et par ekstra funksjoner som er fordelaktige å ha med. Gjennom dette prosjektet har gruppen hatt et godt samarbeid både med hverandre og med oppdragsgiver. Gruppen har hatt møter jevnlig en til to dager i uken under prosjektperioden. I løpet av denne prosjektperioden har gruppen opplevd at man har fått bedre erfaring med teknologi som er relevante i bransjen i dag. Gruppen har arbeidet med scrum som prosessmodell, og lært hvordan det er å jobbe med et større prosjekt og hva de forskjellige fasene innebærer. Etter endt prosjekt står gruppen igjen med et nettsted de er stolte av å ha utviklet, som vil være til hjelp for de reiselystne som ønsker å vite mer om de forskjellige vaksinene de bør ta før man reiser til destinasjonen sin. 11

12 Del 2 Produktdokumentasjon I dette avsnittet vil gruppen ta for seg selve produktet slik det er i skrivende stund. 2.1 Rammebetingelser Kravspesifikasjon Dette punktet beskriver de viktigste kravene for løsningen. For den komplette kravspesifikasjon, se vedlegg 1. Hovedkravene i denne løsningen er: 1. Animert kart med informasjon om reisemål 2. Diskusjonsforum for spørsmål 3. Bestilling for vaksinering 4. Innebygd system for faktura Hovedkrav for brukertypene: 1. Administrator: Skal ha tilgang til brukerenes historie, kunne sette tilganger til andre brukere, han skal også ha forummoderasjon. Med forummoderasjon menes det at administrator har mulighet til å slette støtende innhold og kunne stenge brukere ut av forumet. 2. Kunde: Tilgang til egen historie og bruker, skal også ha skrive- og lesetilgang på forumet. 3. Informasjonssøker: Har kun lesetilgang til nettstedet. Utvidet informasjon om brukertyper finnes i kapittel 2.4, om brukertyper. 12

13 2.1.2 Pålitelighet Produktet er laget for å bestille time til vaksinering og for å innhente informasjon om reisevaksiner og reisedestinasjoner. Derfor er det viktig at produktet ser ordentlig og respektabel ut. Dette er for at potensielle kunder skal føle at det er trygt å benytte seg av innholdet i produktet Sikkerhet Dette nettstedet må ha et system som er sikkert. Systemet skal ha en sikkerhet rundt registrering og innlogging av brukere, samt ved håndtering av sensitiv informasjon som blir lagret. Derfor vil brukernes passord hashes i database med hashen SHA-256 og samtlige brukere skal ha et tilfeldig salt på åtte tegn som er lagt til på hashen. Henviser til forklaring av sikkerhet i avsnitt Betalingen skal skje via en ekstern leverandør, PayPal, som har sine egne sikkerhetstiltak. Oppdragsgiveren til gruppen har bestemt seg for å separere journalsystemet sitt og produktet, så sikkerhetsaspektet med hva som ble gjort til gitt besøk trenger ikke å bli implementert i løsningen Brukervennlighet Brukervennlighet sammenlignes ofte i form av hvor lett det er å lære seg systemet, og hvor lett det er å huske hvordan det brukes. Et system som man kan bruke med lite trening, oppfattes oftere som lettere enn et system som krever mye opplæring. Det optimale er at det ikke er behov for noe som helst form for opplæring. Dette kommer ofte an på systemet og er derfor av og til uunngåelig. En bruker vil lett kjenne seg igjen i et brukervennlig system, selv om det går lang tid mellom hver gang systemet brukes. 13

14 Produktet gruppen har skapt, skal fungere på en slik måte at man ikke skal trenge opplæring for å kunne bruke det. Oppsettet gruppen har laget er bygget på en struktur som er lett å kjenne igjen fra andre liknende nettsteder, noe som er viktig for nye brukere, og gjør det lettere for alle. Administrasjonssiden er laget slik at en bruker, uten store forkunnskaper, skal kunne gjøre avanserte handlinger. Brukeren skal ikke måtte kunne språk for databasehåndtering for å gjøre endringer i databasen. Systemet skal være mobilvennlig og skal kunne brukes på alle mobile plattformer. For at Dr. Akram og brukere skal kunne kjøre systemet må en ha tilgang til en nettleser. Internet Explorer 8 eller lavere har vist seg å være relativt problematisk i utformingen gruppen har gitt nettstedet. Grunnet at Internet Explorer har en markedsandel på bare åtte prosent (w3schools, Browser stats, Udatert )og de fleste brukere av denne nettleseren har nyeste versjon av programvaren, valgte gruppen å ikke bruke tid på å tilpasse for bruk her. 2.2 Benyttede dataspråk HTML Produktet gruppen har skapt er et nettsted og derfor er all kode nettbasert. Nettstedet har blitt bygget på HTML som rammeverk, som gir strukturen til siden CSS CSS er et språk som er brukt for å gi design, størrelse og plassering til de eksisterende HTML-elementene på nettsiden. For eksempel hvis bakgrunnen skal være hvit eller svart, så er dette definert i CSS-koden. 14

15 2.2.3 PHP PHP er et dynamisk kodespråk som gjør at nettstedet får fungerende funksjonalitet. PHP står for kommunikasjonen mellom klient og server. Det vil si at hvis man for eksempel skal gjøre en handling på nettsiden som krever interaksjon med databasen, så er det PHP som står for dette JavaScript JavaScript er et kodespråk som tilfører dynamiske elementer til nettsiden. For eksempel i dette produktet har gruppen benyttet JavaScript til vaksinekartet og i registreringsskjemaet slik at poststed skal oppdateres automatisk når bruker skriver inn postnummer SQL SQL står for Structured Query Language, og er et programmeringspråk for databaser. Det brukes for å kommunisere og gjøre operasjoner med relasjonsdatabaser. I dette produktet har gruppen brukt SQL sammen med PHP for å gjøre disse operasjonene. 2.3 Nettstedet Forsiden Den første siden man møter når man kommer til nettstedet er forsiden. Forsiden til vaksineklinikken består av en navigasjonsbar med vaksinekartet som hovedinnhold, da dette er funksjonen både gruppe og oppdragsgiver ville fokusere på. 15

16 2.3.2 Timebestilling En av funksjonene oppdragsgiveren ønsket at gruppen skulle ha med på nettstedet var en funksjon for timebestilling. Denne funksjonen er en stor del av nettstedet ettersom det er der kunden går for å bestille time til vaksinering. Gruppen strevde en del med denne delen av oppgaven på grunn av spesifiseringen innenfor funksjonen for timebestilling. Det var ønsket at man skulle velge bolker av tid, hvor man skrev hvilke vaksiner man ønsket å ta i denne timen. Ettersom at gruppen ikke har god nok kompetanse og god nok tid til å lage et bookingsystem fra bunnen av, ble det bestemt at man skulle finne en ferdig løsning som kunne benyttes. Gruppen vurderte flere forskjellige alternative bookingløsninger. Mange av disse alternativene kostet flere tusen kroner og var derfor ikke mulige for gruppen å velge. Gruppen prøvde først og fremst å finne en bookingløsning som var gratis eller som kun krevde et engangsbeløp. Mange av de gruppen fant var slike at man måtte betale ett abonnement, noe som var uaktuelt for dette prosjektet. Til slutt kom gruppen frem til et script som heter Time Slots Booking Calendar som er skrevet av PHPJabbers. Her trengte oppdragsgiver kun å betale en engangsum for å få tilgang. Etter mye frem og tilbake med betaling, overføring av penger og riktig navn på transaksjonen, gikk betalingen gjennom og gruppen kunne begynne med å implementere scriptet på nettstedet. Programmet kom med en stor mangel ved at det ikke er mulig å bruke samme database for kunder, som det allerede er blitt opprettet til forumet. Dette programmet gav tilgang til kildekode, men det er noe gruppen ikke har satt seg inn i, det ble sendt mail til StivaSoft, eierene av PHPJabbers, om en mulig løsning, men dette krevde en ekstra betaling til dem. Gruppen kom frem til en løsning som krever at brukere skriver inn samme epost-adresse ved utsjekking som det dem er logget inn med under bestillingen. 16

17 2.3.3 Vaksinekart Oppdragsgiver ønsket en animert globus eller en animasjon av et verdenskart. Hensikten med dette er at brukere skal kunne få informasjon om hvilke vaksiner de har behov for, før de skal reise til et nytt land. Skal de for eksempel til Ghana i Afrika, kan de enkelt kunne navigere seg dit ved hjelp av det animerte verdenskartet på forsiden. Først ved å trykke på kontinentet Afrika på kartet og så bestemme Ghana som land fra en liste. Da vil de få opp all nyttig informasjon om reisemålet i henhold til vaksiner og helse. Denne informasjonen hentet gruppen fra Norsk Elektronisk Legehåndbok 3, NEL, etter ønske fra oppdragsgiver. Vaksinekartet er hentet fra Winston Wolf (CSS & JQuery Clickable map, versjon ), og er en lisensfri kode som gruppen ikke trengte egne rettigheter for å implementere. Gruppen ønsket å implementere sitt eget kart, og har dermed endret kartet i Adobe Photoshop CC (Photoshop, Udatert), slik at de fikk det kartet de mente brukerene fikk best utbytte av. Siden vaksinekartet er en stor del av oppgaven, har gruppen naturligvis brukt lang tid på å finne det beste resultatet. Gruppen endte opp med dagens utgave og er veldig fornøyd med hvordan det ser ut, dens funksjon og hvordan kartet knytter sammen alle undersider med informasjon. Figur 1: Forsiden til Oslo vaksineklinikk med vaksinekartet

18 2.3.4 Fakturasystem I oppgaven gruppen fikk utdelt fra oppdragsgiver, var et av kravene å integrere et fakturasystem. Hensikten med dette, er at kunden selv skal kunne bestemme om han vil betale med kort eller om faktura på epost er foretrukket. De aller fleste fakturasystemene koster penger, men oppdragsgiver ønsket ikke å investere i et slikt system. Gruppen bestemte seg raskt for å finne en løsning som var gratis og som oppfylte oppdragsgiverens krav. Her igjen fant gruppen løsningen i PHPJabbers sitt script, bookingkalenderen som ble implementert i løsningen har ett innebygd fakturasystem med støtte for alle betalingsformer som oppdragsgiver ønsker. Det innbygde fakturasystemet gir også støtte for epost- og SMS-varsling for oppkommende timer Betaling I følge kravspesifikasjonene gruppen fikk av oppdragsgiver, ønsket han å ha en betalingsfunksjon på nettstedet, slik at man kunne betale for timen før man blir vaksinert. Gruppen følte at dette var en funksjon som svært få ville benytte seg av, ettersom at det er sjeldent man betaler før man mottar en tjeneste av denne typen. Til slutt kom gruppen frem til at funksjonen beholdes, men legger til at man kan velge å betale når man er ferdig hos vaksineklinikken. Som betalingsfunksjon valgte grupen å benytte seg av PayPal, da dette er en veldig utbredt betalingsmåte over nett. Den vil ikke kreve at man anskaffer seg sertifikater fra banker og vil gjøre at brukere føler seg mer sikker i betalingen, fordi det er en kjent betalingsmåte. Gruppen vil også ta med kontant, giro og bankkort som betalingsform og føler at vi når så godt som mulig ut til potensielle kunder med disse fire formene for betaling. 18

19 2.3.6 Diskusjonsforum Diskusjonsforumet er en av hovedfunksjonene til nettstedet. Et diskusjonsforum er en elektronisk måte der brukere kan kommunisere med hverandre. Det er for eksempel brukt til å spørre om hjelp eller råd fra andre brukere som kanskje har en løsning på problemet (Feerst & Stewart, 2007). Det finnes mange ferdige maler på forum man kan benytte, men til dette prosjektet valgte gruppen å utvikle sitt eget forum fra bunnen av. Grunnen til dette er at hvis man programmerer noe selv har man full kontroll over koden. Dette krever mer tid og arbeid, men samtidig får man det akkurat som man vil. Diskusjonsforumet gruppen har utviklet er laget så enkelt som mulig. Det vil si at det skal være enkelt å forstå og å bruke. Det skal derfor ikke være nødvendig med noen opplæring for å kunne bruke det. Brukerne av forumet er personer som søker etter råd og erfaringer fra andre personer angående for eksempel reise- og vaksineråd, eller som har direkte spørsmål til legen på vaksineklinikken. Oppbygningen til forumet Forumet er delt inn i kategorier, emner og meldinger. Kategoriene er det kun administrator som kan opprette, slette og redigere. En kategori kan bestå av mange emner og et emne kan bestå av mange meldinger. Forsiden av forumet kan ses på figur 2 og viser hvordan kategoriene er satt opp med dens nyeste emne i kolonnen Figur 2: Forsiden til forumet som viser alle kategorier og deres nyeste emne. til høyre. Under alle kategoriene er det en knapp for opprettelse av nytt emne. 19

20 Trykker man seg inn på en kategori kommer man videre til en liste med emnene som er opprettet i den respektive kategorien. De nyeste emnene kommer først i listen med datoen ved opprettelse i kolonnen til høyre. Under emnene er det en knapp for opprettelse av et nytt emne i kategorien. Brukeren må være innlogget for å kunne opprette ett nytt emne. Figur 3: Emner i kategori reiseråd. Der det nyeste emnet står øverst. Trykker man seg inn på et emne kommer informasjonen opp i to kolonner. Brukernavn, dato og tid meldingen ble opprettet til venstre og selve meldingen i kolonnen til høyre. Under meldingen finner man en link som heter Rediger. Trykker man på den kan man redigere meldingen, hvis man for eksempel skrev noe feil. En bruker som ikke har opprettet meldingen, får feilmelding hvis han eller hun prøver å redigere andres meldinger. Også her må man være innlogget for å skrive og redigere meldinger. Figur 4: Meldinger i emnet. Her kan brukere besvare andre brukere. 20

21 Forumet er bygget opp av fire tabeller i en relasjonsdatabase. Disse tabellene er knyttet til hverandre med forskjellige nøkler. Tabellene er en bruker-, en kategori-, en emne- og en meldingstabell, der alle tabellene har en primærnøkkel. I figur 5 er det vist et ER-diagram som viser relasjonene mellom disse tabellene. Her ser man hvordan forumet henger sammen der alle id er er primærnøkler og fremmednøkler er entiteter som ender med _by, for eksempel så er topic_by fremmednøkkel i topics og henviser til user_id i users tabellen, på denne måten kan en se hvem som har laget emnet i forumet. Figur 5: ER-diagram over databasen for forumet. Blokkere brukere Som nevnt må en bruker være innlogget for å kunne skrive i forumet. En stor grunn til det er at administrator skal kunne ha mulighet til å blokkere brukere fra å skrive forumet. Blokkerte brukere vil fortsatt ha lesetilgang. Grunnen til å kunne blokkere brukere er hvis enkelte brukere, etter gjentatte advarsler fra administrator, nekter å oppføre seg ordentlig i forumet. Dette kan for eksempel være ved å skrive upassende meldinger eller ved å spre spam. Denne funksjonen er veldig viktig, da det bidrar til å stenge ute brukere som skaper et dårlig miljø i forumet. For å kunne blokkere brukere trenger administrator bare å endre brukernivået i brukertabellen i databasen. Dette gjøres enkelt via administrasjonssiden. 21

22 Henviser til brukermanualen til administrasjonssiden som er lagt ved i vedlegg 6 for å se hvordan man blokkerer brukere. For videre utvikling av forumet, kan det for eksempel bli lagt til regler, slik at brukere er mer informert og vet hvordan man skal oppføre seg og konsekvensene hvis man ikke gjør det Administrasjonssiden Administrasjonssiden er et slags publiseringssystem for diskusjonsforumet på nettstedet. Den lar administrator legge ut, endre og slette informasjon på forumet. Det er også mulighet for å administrere brukere og se timehistorikken til pasientene på vaksineklinikken. Tabeller med informasjonen blir hentet fra databasen og listes ut på administrasjonssiden. Administrator kan enkelt gå inn i tabellen og endre informasjonen slik at det lagres i databasen. Hvis for eksempel navnet til en kategori i forumet endres på administrasjonssiden, vil det vises med en gang i forumet på nettstedet. Hele systemet er beskyttet med en innloggingsfunksjon. Dette er den samme som innlogging for nettstedet. Forskjellen er at det er kun de brukere med administrator tilgang som kan aksessere administrasjonssiden. Dette gjøres ved å bruke PHP-postfunksjon mot et PHP-script som validerer brukeren ved hjelp av en session-variabel på hver eneste nettside. Denne session-variabelen settes kun etter at administrator har gjennomført en vellykket innlogging. Henviser til brukermanualen for administrasjonssiden under vedlegg 6 for mer forklaring av systemets funksjonalitet. 22

23 2.3.8 Mindre, men viktige funksjoner Registrer deg Før en bruker kan logge seg inn må han/hun registrere seg som en ny bruker. Dette gjøres som følger: 1. Bruker trykker på Registrer deg til høyre i menyen. 2. Så må brukeren fylle ut informasjon i et HTML-skjema. Informasjonen som kreves ved opprettelse er fullt navn, brukernavn til forumet, telefon, epostadresse, adresse, postnummer, ønsket passord og fødselsdato. Poststed blir fylt ut automatisk når brukeren taster inn postnummer. 3. Når all informasjon er fylt ut og brukeren har trykket på knappen, valideres feltene og sjekker om alle tegn er korrekte. Dette gjøres ved hjelp av RegEx, som er beskrevet mer i avsnitt om sikkerhet. I tillegg sjekkes det om brukeren allerede er registrert. Dette gjøres ved hjelp av SQL-spørring mot databasen som sjekker om e-postadressen eksisterer ved en annen brukerkonto. 4. Hvis alt stemmer skrives informasjonen inn i databasen ved at PHP sender informasjonen ved hjelp av postvariabler og en SQL-kommando skriver inn denne informasjonen i brukertabellen i databasen. 5. Brukeren får så en melding at han eller hun er registrert og kan logge inn. 6. Hvis noen felter er skrevet med ukorrekte tegn eller brukernavnet eller e- postadressen allerede eksisterer, vil brukeren få feilmeldinger på hva som må endres. Figur 6: Registreringsskjema for opprettelse av bruker ved Oslo vaksineklinikk. 23

24 Logge inn For at en bruker skal kunne delta i diskusjonsforumet og kunne bestille en time til vaksinering, må en bruker være registrert og logget inn. Innloggingen skjer som følger: 1. Bruker må trykke på Logg inn til høyre i menyen. 2. Bruker skriver inn e- postadresse og passord i innloggingfeltene og trykker på logg inn. 3. PHP-kode sender SQLspørringer til databasen og sjekker om den innskrevne informasjonen stemmer overens med det som er lagret i databasen. Figur 7: Logg inn vindu ved Oslo vaksineklinikk. 4. Hvis dette stemmer blir session opprettet og brukeren er logget inn. 5. Hvis dette ikke stemmer, får brukeren en feilmelding på at informasjonen ikke stemmer. 24

25 Glemt passord Hvis brukeren ikke får logget inn, kan det være fordi brukeren ikke husker passordet sitt. Derfor er denne funksjonen lagt til, slik at brukere kan få et nytt passord. Prosessen for å nullstille passorder går som følger: 1. For å komme til denne funksjonen må bruker trykke på Logg inn i menyen. Der er det en link hvor det står Glemt passord?. 2. Denne linken tar Figur 8: Glemt passord, der brukeren kan få ett nytt passord på mail. brukeren til en side hvor man kan skrive inn e-postadressen sin. 3. PHP-kode sender SQL-spørringer til databasen og sjekker om e- postadressen eksisterer. 4. Hvis den eksisterer lages et nytt passord til brukeren. Dette gjøres ved å kutte den første delen av e-postadressen, legge den sammen med en streng av tilfeldige tall, kryptere det i hashalgoritmen SHA-256 og legge det til med et salt. Henviser til forklaring om hashing av passord i avsnitt Det nye passordet erstatter ikke det gamle passordet, og kan ikke brukes enda, men lagres som et midlertidig passord i brukertabellen i databasen. 5. Det sendes så en e-post til den eksisterende e-postadressen. Her legges det ved passordet og en link. Brukeren er nødt til å trykke på linken for å tilbakestille passordet. 6. Når brukeren trykker på linken vil det eksisterende passordet bli erstattet med det midlertidige passordet som brukeren fikk tilsendt. 7. Brukeren kan nå logge inn med det nye passordet. 25

26 Endre passord Hvis brukeren vil endre passordet sitt, kan det gjøres via denne funksjonen: 1. Brukeren må trykke på sitt brukernavn øverst til høyre i menyen for å komme til profilsiden sin. 2. Der får brukeren tre valg. Endre brukerdetaljer, endre passord og se tidligere vaksiner på Helsenorge sine hjemmesider Trykker brukeren på endre passord, vil det komme opp en ny side med tre felter for å fylle ut data. Et for det nåværende passordet, et for det nye og et for å gjenta det nye passordet. 4. Når brukeren har fylt ut alle tre feltene, vil PHP-kode sende SQLspørringer til databasen. Disse spørringene sjekker om det nåværende passordet til brukeren stemmer overens med det som er skrevet inn. 5. Stemmer det vil det nye passordet og det gjentatte nye passordet sjekkes med RegEx om det inneholder alle nødvendige tegn. Henviser til avsnitt for mer forklaring av RegEx. 6. Hvis alle nødvendige tegn er skrevet inn, sjekkes det om de to passordene er like. Hvis de ikke er like, vil bruker få feilmelding på dette. 7. Er de like vil det nye passordet bli kryptert og lagt til sammen med brukerens salt. Det sendes så en SQL-kommando til databasen ved hjelp av PHP-kode, hvor det gamle passordet blir oppdatert med det nye. 8. Brukeren får tilbakemelding på at passordet er oppdatert og kan begynne å bruke det som sitt nye passord. Figur 9: Endre passord. Her kan brukeren endre passordet fra profilsiden sin

27 Endre brukerinformasjon Hvis brukeren vil endre noe av informasjonen om seg selv, kan brukeren gjøre dette via denne funksjonen på denne måten: 1. Først må brukeren trykke på brukernavnet sitt i menyen. 2. Brukeren får da tre valg hvor det første valget er å endre brukerinformasjon. 3. Brukeren kommer nå til et skjema som likner på det skjemaet brukeren brukte for å registrere seg. Forskjellen er at informasjonen allerede er fylt ut og passordfeltene er borte. Informasjonen blir hentet fra brukertabellen i databasen ved hjelp av SQLspørringer og sessionvariabelen til brukeren. 4. Ved å skrive i skjemaet kan brukeren endre det han/hun vil endre og trykke på lagre endringer. 5. Valideringen er den samme som på registreringen som nevnt tidligere. Eneste forskjellen med SQL-kommandoene er at brukerinformasjonen blir oppdatert i databasen. Figur 10: Endre brukerinformasjon. Brukere kan endre sine opplysninger via profilsiden sin. 27

28 2.4 Sentrale funksjoner Det finnes flere sentrale funksjoner i denne nettløsningen som blir beskrevet i punktene under Brukertyper Dette nettstedet gruppen lager vil kun ha tre forskjellige brukertyper. Disse er Administrator, Kunder og Informasjonssøkere. Sluttbrukerene i denne løsningen er kundene. Det er disse forskjellige brukere fordi det er kun disse tre typene som vil dra nytte i et nettsted av denne typen og innhold. Det vil også være tre forskjellige nivåer av tilgang avhengig av hvilken rettigheter som er knyttet til brukeren og om en i det hele tatt er logget inn. Henviser til vedlegg 5 om bruksmønstre for en fullstendig oversikt over hva de forskjellige brukertypene kan gjøre i systemet. Administrator Administrator på nettstedet vil være oppdragsgiver, det vil si legen på vaksineklinikken. Han skal ha mest mulig tilgang. Grunnen til dette er at han vil kunne administrere dagen sin ut i fra timebestillinger kunder har sendt inn til vaksineklinikken. Han vil kunne se en historie over pasienter og varer som er brukt. Videre vil administrator ha tilgang til å endre brukere i systemet og deres rolle og hva de har tilgang til. Han vil også ha tilgang til moderasjon av diskusjonsforumet. Til slutt skal gruppen legge ved en brukermanual slik at oppdragsgiver eller en annen med administrator tilgang kan se hvordan kildekoden er bygget opp, hva som er hva og kan enkelt oppdatere innholdet til nettstedet. Kunder Kundene, som er brukerene av dette nettstedet skal først og fremst ha tilgang til å bestille time og kunne legge ut spørsmål og svar på diskusjonsforumet. Kunder 28

29 skal også ha tilgang til sine tidligere timer som en form for kvittering og oversikt over tidligere besøk ved klinikken. Informasjonssøkere Informasjonssøkere er de som ønsker informasjon om vaksinering før de bestemmer seg. Disse vil ha samme muligheter som kunder, men de vil ikke kunne bestille time til vaksinasjon, men vil kun ha tilgang til vaksinekartet og lesetilgang til diskusjonsforum for å innhente informasjon. Disse vil ikke benytte seg av muligheten til å logge inn Sikkerhet Ettersom nettstedet har en innloggingsfunksjon og en registreringsfunksjon, der informasjon blir lagret og hentet fra en database, er det svært viktig med sikkerhet på nettsiden. Det blir gitt sensitiv informasjon som må beskyttes fra personer som ikke skal ha tilgang til denne informasjonen. Passordet brukerene lager på nettstedet må ha minst en liten bokstav, en stor bokstav, et tall og være på minst seks tegn. Dette er for å gjøre passordet mer sikkert og ikke gjøre det så lett å gjette for andre. For å gjøre dette er regulære uttrykk, RegEx, blitt benyttet. RegEx står for Regular Expression og er i gruppens løsning blitt implementert i PHP koden. RegEx står for servervalideringen og sjekker at alle felter som skal fylles ut er skrevet med korrekte tegn. Passordet blir kryptert med hashalgoritmen SHA-256. Hashing er en enveiskryptering og man kan derfor ikke dekryptere passordet for å finne ut av hva det er. SHA-256 vil si at passordet vil bli gjort om til en streng på 256 tegn. For å gjøre passordet enda mer sikkert er det lagt til et salt på passordet. Hver bruker får sitt eget salt, som er en streng på åtte tilfeldige tall. Det er viktig at passordet blir lagt til sammen med et salt, fordi det forhindrer ordbokangrep og 29

30 rainbow table-angrep. Rainbow table er en forhåndsberegnet tabell som reverserer hashfunksjoner, altså krypterte passord. Når brukerene skal legge inn eller hente noe fra databasen, er det viktig at databasen er sikret mot SQL-injection. SQL-injection er en teknikk der ondsinnede brukere kan injisere SQL-kommandoer inn i en SQL-erklæring via en informasjonsboks på nettstedet. SQL-injection-kommandoer kan endre SQLsetninger og sette sikkerheten til nettstedet i fare (w3schools, SQL injection, Udatert). For å forhindre SQL-injection er det benyttet en PHP funskjon som heter mysqli_real_escape_string(). Den fjerner spesielle tegn i en string til bruk i en SQL-erklæring (w3schools, Udatert) Brukergrensesnitt Oslo vaksineklinikk er et nettsted der en bruker ved hjelp av et sett med funksjoner kan bestille time. Det vil også være mulig for brukeren å finne frem informasjon innenfor vaksiner enten det er angående ferie eller en spesiell type arbeidsstilling, se tidligere timer og være aktiv på et diskusjonsforum tilhørende nettstedet. Et godt brukergrensesnitt kjennetegnes ved å ha en god sikkerhet, god funksjonalitet, tilgang til systemet, være effektivt og appellerende (Sandnes, 2011). Et sikkert datasystem skal beskytte informasjon som finnes på dette nettstedet mot feilaktig tilgang. Det skal også være vanskelig å slette informasjon ved et uhell. Et prinsipp for brukervennlighet som er lurt å følge, er at de fleste operasjonene man foretar seg bør være reversible, det vil si at man skal ha muligheten til å angre og tilbakestille systemtilstanden, slik at man har foretatt seg en endring man ikke er fornøyd med skal det være mulig å gå tilbake. Gruppen sitt produkt er svært sikkert i forhold til innlogging og beskyttelse av data. Ser man på sikkerheten i forhold til brukervennlighet i grensesnittet ser 30

31 man det finnes muligheter for å reversere endringer. Kvaliteten på datasystemer måles i stor del ut ifra hvor godt funksjonaliteten til datasystemet samsvarer med hva brukerene ønsker å oppnå (Sandnes, 2011). Det er derfor viktig at det i et godt datasystem, finnes funksjonalitet som gir god støtte til brukerene. Gruppens produkt gir god støtte rundt brukerens behov når det gjelder informasjon om vaksiner og bestilling av timer. Det er ikke kun tilstrekkelig at funksjonaliteten er implementert, men brukere må også ha tilgang til et godt brukergrensesnitt. Dette må gjøres på en slik måte at en bruker kan lokalisere og bruke funksjonaliteten. Et av de mest vanlige problemene i brukergrensesnitt er at hovedfunksjonene ligger så godt skjult at brukerne ikke finner de (Sandnes, 2011). Eksempler på dette kan være at man ikke finner tilbakeknappen eller lagreknappen, noe som ødelegger hensikten i oppgaven brukeren ønsker å utføre. Gjennom produktet gruppen har skapt ser man at funksjonaliteten til nettstedet ikke er skjult. Man forstår godt og man klarer å lokalisere hovedfunksjonene til produktet på en såpass god måte at man forstår hvordan det skal benyttes. Mangel på synlighet er for mange et av de mer vanlige problemene man kan ha i et brukergrensesnitt. Dette kommer ofte av at man ikke finner knappene man skal trykke på, eller at brukeren ikke ser hva man skal gjøre på nettstedet. Et godt brukergrensesnitt gjør alle handlinger synlige (Sandnes, 2011). På nettstedet gruppen har utviklet er de aller fleste handlinger synlige. Man ser hvor man skal trykke for bestille en vaksine og man er klar over hva man skal gjøre for å finne frem til prislisten. For å se på hvor effektiv gruppens nettsted er, må man først se litt på hva som gjør et nettsted mer eller mindre effektivt. Effektivitet er et mål på hvor mye arbeid brukeren får utført, og et mål på hvor raskt brukerne utfører en oppgave eller hvor mange oppgaver brukeren greier å utføre innen en gitt tidsfrist (Sandnes, 2011). For eksempel er det vanlig å se på ord per minutt for å måle 31

32 hvor effektive noen er til å bruke et tastatur. Et annet eksempel er å se på hvor lang tid det tar å bestille flybillett på nettstedet til et flyselskap. Siden produktet gruppen har skapt er et nettsted, hvor bestilling av time er i fokus, vil det være åpenbart å se på hvor lang tid det vil ta å bestille en time for vaksinasjon. Disse resultatene vil komme i kapittel 3.7 som handler om produkttesting. En viktig faktor for brukergrensesnittet er at det har en god appell og at brukeren blir engasjert (Sandnes, 2011). I tillegg til dette skal systemet også være brukervennlig, og det skal heller ikke være kjedelig å benytte seg av. Appell kan gjenspeile seg i et godt førsteinntrykk, man skal føle en viss glede eller opplysning når man kommer inn på nettstedet. I tillegg vil et godt system også ha vedvarende appell over tid, for man skal ikke bli lei av utseendet. Produktet gruppen har skapt er estetisk appellerende. Det er blitt benyttet et fint og moderne design på nettstedet som gjør at det for noen personer mer behagelig å benytte seg av, i motsetning til noen andre nettsteder med samme funksjon Teknisk arkitektur Nettstedet er hovedsaklig skrevet i PHP, HTML, CSS og javascript. Nettstedet er utviklet med rammeverket Bootstrap. Gruppen ble tidlig enige om å bruke rammeverket til Bootstrap. Grunnen til dette er at Bootstrap er gratis og med åpen kildekode, rammeverket med verktøy er laget for hjemmesider uten at utforming og gjennomføring av produktet blir alt for lett. Man kan for eksempel benytte deg av ferdiglagde knapper, former eller bokser. Dette rammeverket er videre forklart i avsnitt i prosessrapporten. Vaksinekartet inneholder HTML, CSS og JQuery. Bookingsystemet gruppen har benyttet seg av er hentet fra PHPJabbers sitt nettsted (Time Slots Booking Calendar, Udatert) og er skrevet i PHP. 32

33 2.5 Design og universell utforming Det er viktig at produktet gruppen har skapt har et estetisk appellerende design. Når det kommer til nettstedets design, fikk ikke gruppen noen spesifikke krav, annet enn at det var ønsket å ha en form for globus eller kart over de forskjellige landene eller kontinentene i verden. Der kunne brukere trykke på for å finne frem hvilke vaksiner og informasjon de eventuelt trenger i forhold til hvilken destinasjon de ønsker å dra til. Gruppen fikk ikke noen retningslinjer i starten, på hvordan dette skulle se ut. Noe annet enn ønsket om vaksinekartet fikk ikke gruppen så mye mer å gå på, bortsett fra at det var ønskelig at nettstedet ble utformet så moderne og tidløst ut som mulig. Gruppen satte derfor opp flere designmuligheter i form av forslag og skisser, som de da ble enige om. Til slutt ble det klart at det var to forslag som skulle presenteres for oppdragsgiver. Ut i fra disse to forslagene, valgte oppdragsgiver ut hvilket han likte best. Forslaget som ble valgt, var et template laget ved hjelp av bootstrap, som er et rammeverk som er synlig for brukere. Bruk av templates og valgt rammeverk er beskrevet mer i del tre av rapporten Tekst og lesbarhet Tekst brukes generelt til både aktivt drive brukergrensesnittet og i selve innholdet via informativ tekst på nettstedet. Tekst knyttet til brukergrensenittet kan være trykkknapper, radioknapper, markering av felter, ikoner og hyperlenker. Den informative teksten brukes i selve innholdet til nettsiden. Gruppen har tatt bevisste designvalg knyttet til formatering av tekst, valg av skrifttype, tekststørrelse og fargevalg på tekst for å bidra til bedre lesbarheten og brukeropplevelsen. Teksten gruppen har benyttet seg av, ble valgt for å framheve lesbarheten til nettstedet, noe som igjen vil forbedre den universelle utformingen til nettstedet 33

34 gruppen har skapt. Leseferdigheter kjennetegnes ofte ved at man ikke leser de individuelle bokstavene, men ordene i sin helhet (Sandnes, 2011). Det er spesielt høydesignaturen på et ord som gjør dem gjenkjennelige. Det at noen bokstaver går opp eller ned gir ordene en unik topp og bunn signatur, noe som gjør at man kjenner igjen ordet kjappere. Mennesker har også en tendens til å bruke bokstavene på begynnelsen og mot slutten av et ord til gjenkjenning i følge Sandnes (Sandnes, 2011). Bokstavene midt inni ordet er mindre viktige i gjennkjenningsprosessen. Det er derfor lettere å kjenne igjen ord som er skrevet med små bokstaver enn ord som er skrevet med store bokstaver, dette er fordi alle de store bokstavene har samme høyde. Ved lesning av ord som er skrevet med store bokstaver må hvert ord leses bokstav for bokstav, noe som gjør at leseprosessen dermed går mye tregere. Gruppen har derfor tatt en beslutning hvor all brødtekst skal skrives med små bokstaver. Store bokstaver i brødtekst har i dataverdenen også blitt et uttrykk for å skrike eller si noe veldig høyt (Sandnes, 2011), noe gruppen ikke ønsker å gjøre med sin tekst. Figur 11: Ett eksempel på hvilken tekst som er brukt ved nettstedet. 34

35 Teksten gruppen har benyttet seg av på nettstedet må være tilstrekkelig stor for at brukeren skal kunne lese den. Hvor stor teksten faktisk blir for brukeren, vil avhenge av flere faktorer, blant annet størrelsen på skjermen som brukes, avstanden mellom brukeren og skjermen og konfigurasjoner i operativsystemet (Sandnes, 2011). I tillegg vil brukerens syn tilsi hva som er den laveste grensen for hva som er leselig. Disse faktorene er utenfor gruppens kontroll. Brukeren må i mange tilfeller selv gjøre lokale tilpasninger. Disse kan gjøres på hovedsaklig tre nivårer, i operativsystemet, i applikasjonen og i selve innholdet Bilder Det har blitt benyttet flere forskjellige bilder på nettstedet. Bildene har blitt benyttet på nettsiden av flere forskjellige grunner. I hovedsak har gruppen valgt å bruke bilder for å fjerne større hvite felt på nettsiden. Ettersom at nettstedet er laget for formidling av informasjon om vaksiner for reise følte gruppen det var passende å benytte seg av bilder av de forskjellige reisemålene. Gruppen har for eksempel valgt å legge et bilde av noe som er typisk for den verdendelen i bakgrunn på hvert kontinent der en kan velge landet man skal reise til. Figur 12: Bilde av siden for kontinentet Asia 35

36 I figur 12 ser man hvordan gruppen har brukt et bilde av en panda på siden for Asia, grunnen til at vi benyttet dette bilde er fordi pandaer er noe som kun finnes i Asia. På samme måte har gruppen lagt bakgrunnsbilder av det man ofte assosierer landet man velger etter at en har valgt kontinent. Figur 13: bilde av siden med informasjon om Mexico I figur 13 ser man hvordan gruppen har benyttet seg av et bilde som kjennetegner landet man har valgt. Grunnen til at gruppen valgte palmer for Mexico, er på grunn av at man ofte assosierer varme og palmer med Mexico. Figur 14: Bilde av forsiden. For forsiden har gruppen valgt å benytte seg av et bilde av vann. Grunnen til at dette motivet ble valgt var i hovedsak på grunn av vaksinekartet. Siden det er et kart med de forskjellige kontinentene, tenkte gruppen at det kunne vært fint å illustrere havet med et bilde av vann. Det samme bildet er brukt på de fleste andre undersidene av nettstedet da dette hjelper å knyte sammen de resterende delene. 36

37 2.5.3 Språkvalg Oppdragsgiver ønsket norsk som eneste språk til nettstedet, da han regner med å få kun norsktalende besøkende til klinikken sin. Klinikken til oppdragsgiveren er hovedsaklig rettet mot osloborgere og han føler det blir tilstrekkelig med det ene språket. Utbyttet ved å legge til engelsk til produktet vil ikke være så stort da nasjonalspråket er såpass viktig for innbyggerne Fargevalg Farger har en egen betyding i forskjellige kulturer, hvordan man opplever farger er også svært personavhengig (Sandnes, 2011). Hva fargen betyr finnes det ingen fullstendig enighet om. For eksempel er det vanlig for nordmenn å assosiere fargen hvit med renhet, godhet, klarhet og en ny start, mens i andre land som for eksempel i Kina og Japan assosieres det ofte med død. En av de fargene som har få forskjellige assosiasjoner er fargen blå. Gruppen valgte først å bruke fargen blå i headeren og footeren fordi dette er en farge mange forskjellige kulturer ofte assosiere med ro og helbredelse. Først ble det valgt en lysere blå farge som mange ofte assosierer med helse, helbredelse, ro og forståelse. Dette følte gruppen var en bra assosiasjon i forhold til hva nettsidens hovedbudskap er. Gruppen måtte etter en stund endre denne fargen til svart ettersom at oppdragsgiver ikke følte at blå fungerte for han. Svart er en nøytral farge som står i stil til resten av siden, den er mildt gjennomsiktig. Sluttresultatet ble som vist i figur 15. Figur 15: bilde av forside med navigasjonsmeny. 37

38 2.5.5 Kontraster Kontrast er svært viktig for å identifisere elementer som er visuelle, spesielt tekst. Det finnes tre typer kontraster, disse er: Fargekontrast, metningskontrast og lyshetskontrast. Eller en kombinasjon av disse. Fargene rød og grønt utgjør en fargekontrast, en mettet rød og en umettet rød utgjør en metningskontrast mens mørkerød og lyserød utgjør en lyshetskontrast. Lyst signal rødt og grumsemørkt grønt utgjør alle tre (Sandnes, 2011). Det er lurt å bruke kombinasjonskontraster, men det er mest fordelsaktig å benytte seg av metning-og lyshets-kontraster enn fargekontraster. Gruppen har derfor benyttet seg av lyshetskontraster på nettstedet. Et eksempel på dette er teksten i navigasjonsmenyen. Når man setter musepekeren over en av menypunktene ser man at det menypunktet man har valgt blir lysere enn det den var når man ikke har musepekeren over teksten. Figur 16: Meny med lyshetskontrast og fargekontrast. For WCAG 2.0- retningslinjene for nivå en, anbefaler en at vanlig brødtekst ikke benytter fargekontrast. Mer om dette kommer under punktet for universell utforming. Eksperter strides om hvorvidt det er lettere å lese mørk tekst på lys bakgrunn eller lys tekst på mørk bakgrunn (Sandnes, 2011). For mange personer vil mørk tekst på lys bakgrunn være lettere å lese enn lys på mørk bakgrunn, men en andel mennesker vil også foretrekke lys tekst på mørk bakgrunn. Det kan også oppstå en forstyrrende glødeeffekt med negativ skrift og veldig sterk kontrast, der de lyse partiene smitter over på de mørke og gjør teksten vanskelig å lese (Sandnes, 2011). Gruppen har vurdert hvordan man kan gjøre dette på en måte som gjør det lettere for alle å lese. Gruppen har derfor satt mørk tekst på lys bakgrunn ved 38

39 brødteksten for at den forstyrrende glødeeffekten ikke skal bli overhengende stor Gestaltlovene Gestaltlovene som også blir kalt lovene om form, er et resultat av gestaltteorien, som tar for seg hvordan mennesker tolker helhetlige visuelle inntrykk (Sandnes, 2011). Gestaltlovene hjelper oss å forstå hvilken effekt en visuell utforming vil ha på en bruker. Ved å utnytte gestaltlovene øker sjansene for at den visuelle utformingen vil fungere som forventet og ønsket. Det finnes i alt syv lover som tilhører gestaltteorien, disse er lov om forgrunn og bakgrunn, lov om nærhet, lov om likhet, lov om sammenkoblinger, lov om symmetri, lov om kontiuitet og loven om lukkelse. I denne dokumentasjonen vil gruppen bare gjennomgå de lovene som er relevante for dette prosjektet. Loven om nærhet: Når man ser klynger av mennesker generelt, antar man at de er mennesker som står nær hverandre, eller at de er venner eller relaterte til hverandre på en eller annen måte. På samme måte er loven om nærhet et av de meste brukte i grafisk design (Sandnes, 2011). Nærhetsloven sier at vi grupperer elementer som er nær hverandre. Luft bidrar til at vi kan gruppere informasjon enten vertikalt eller horisontalt (Sandnes, 2011). Dette har gruppen tenkt en del på når det gjelder oppsettet av nettsiden. Ved å se på nærhetsloven i forhold til produktet gruppen har skapt, ser man at relevant informasjon har blitt gruppert sammen. Slik som innlogging og registrering er lengst til høyre, mens menyens lenker er gruppert lengst til venstre. Dette har blitt gjort for å skape distanse mellom de to gruppene. Figur 17: Menyelementer er gruppert så de henger i hop. Loven om likhet: 39

40 I design av brukergrensesnitt brukes likhet til å signalisere at elementer hører til i samme gruppe, gjerne sammen med nærhetsloven (Sandnes, 2011). Gjennom dette sammarbeidet med lovene har gruppen sørget for at lenkene i menyen, ser like ut, dette bidrar til å få frem likeheten, slik at grupperingen blir bedre. Effektive nettsider kjennetegnes ofte ved en tydelig og fast struktur (Sandnes, 2011). Ofte er det et hodefelt som viser logo og generell informasjon, en fast meny på venstreside, ekstra informasjon på høyreside, hovedinformasjon på midten og en bunntekst på bunnen. Gruppen sitt oppsett er litt annerledes ettersom at det ikke har den faste menyen på venstre side, ved siden av hovedinformasjonen. Figur 18: Alle elementer har fått en fast struktur. Gruppen har den faste menyen i toppen, ved hodefeltet. Bruk av likhet fremhever struktur. På nettstedet ser alle hyperlenkene ut som hyperlenker, på denne måten har gruppen ungått å benytte flere visuelle utforminger av hyperlenker samtidig på samme nettsted, noen som ville bidratt til forvirring og kaos. Alle menyelementer av samme type har også fått lik utforming, noe som har bidratt til at det er lettere å kjenne igjen og gruppere. Overskriftene har en gjennkjennbar struktur på samme måte som brødteksten gruppen har benyttet seg av. Fast plassering av elementer på forskjellige sider er også en form for likhet som gruppen har benyttet seg av. 40

41 Loven om Kontinuitet: Kontinuitetsloven kan bidra til å fremheve struktur i en visuell fremstilling (Sandnes, 2011). Denne loven har vært svært viktig for gruppen å følge. Elementer som ikke er koblet sammen, men som er i flukt med hverandre ved at de følger usynlige linjer oppfattes som en gruppe. Ved å organisere elementer langs usynlige linjer vil observatøren oppfatte disse linjene selv om de egentlig ikke eksisterer (Sandnes, 2011). Et eksempel på dette er menylinjen til nettstedet gruppen har skapt. Denne er laget på en slik måte at den følger en usynlig linje. Figur 19: Menypunktene er gruppert etter hensikt, og har da blitt lagt på en linje som får nettstedet til å se ryddig ut. Kontinuitet bidrar til at nettstedets grafiske design ser ryddigere ut, slik at det fremstår mer strukturert. Venstrejustering av tekst er vanlig i den vestlige delen av verden (Sandnes, 2011). Dette kommer av at de menneskene som bor i den vestlige verden leser fra venstre mot høyre, derfor er all tekst benyttet på dette nettstedet skrevet med venstrejustering. Høyrejustering har ikke blitt benyttet, selv ikke for å oppnå spesielle visuelle effekter. Gruppen har vært forsiktige med sentrering av tekst, fordi sentreringen gjør at vi mistet kontinuitet. Sentrering av tekst har kun blitt brukt i overskrifter og der det forøvrig ser mer estetisk riktig ut, når det er stor forskjell på setningslengdene (Sandnes, 2011). 41

42 2.5.6 Layout Produktet gruppen har utviklet er et nettsted med en flytende layout. Nettsteder med denne type layout prøver å utnytte nettleserbredden dynamisk på en optimal måte og kan fungere på veldig små skjermer, skjermer med lav oppløsning, skjermer med vanlig oppløsning og brede skjermer med høy oppløsning (Sandnes, 2011). Noe som gjør at produktet gruppen har utviklet fungerer for de aller fleste skjermer. Nettsteder med flytende layout vil alltid prøve å utnytte hele den tilgjengelige skjermbredden uten å overskride den horisontale bredden. Dersom bredden er tilstrekkelig stor, kan en eller flere kolonner introduseres avhengig av hvordan nettsiden er strukturert (Sandnes, 2011). Figur 20: Bilde av forsiden i normal skjermstørrelse. I figur 20 ser man hvordan layouten på forsiden er når man bruker en skjerm med normal størrelse og oppløsning. I bildet nedenfor ser man hvordan nettsiden ser ut når man bruker en skjerm som er mindre. Da forsvinner den vanlige menyen og blir erstattet med et ikon for menyen hvor man skal trykke for å se menypunktene. 42

43 Figur 21: Forsiden, liten skjerm. Figur 22: Forsiden, liten skjerm med menyen nede. I figur 22 ser man forsiden, i liten skjermstørrelse med menyen dratt ned. I figur 23, ser man hvordan nettstedet ser ut på smarttelefoner og mobile enheter. Et av kraven gruppen fikk var at nettstedet skulle være mobilvennelig. Slik at man kan bruke nettstedet på tvers av platformer. Menyer, innhold, supplerende informasjon og så videre har derfor blitt organisert i forskjellige kolonner. Gruppens produkt er av denne grunn også veldig mobilvennlig, siden den kan tilpasses de aller fleste skjermer. Figur 23: Oslo vaksineklinikk vist på mobil enhet. 43

44 2.5.7 Lyd Det vil ikke være noen lydkomponenter på nettstedet. Det finnes flere grunner til dette. En av hovedgrunnene til dette er at det var svært vanskelig å legge disse komponentene inn. Det at gruppen valgte å ikke ha med lydkomponenter på nettstedet, påvirker nettstedets universelle utforming ved at produktet ikke vil oppnå høyeste nivå ved WCAG sine retningslinjer, dette er nærmere forklart i avsnittet om WCAG Universell Utforming Ifølge diskriminerings- og tilgjengelighetsloven 11 må alle nye IKT-løsninger som er rettet mot allmennheten være universelt utformet. Derfor har gruppen arbeidet spesifikt for å få til dette. Universell utforming er en prosess for å øke tilgjengeligheten til produkter. I begrepet universell utforming ligger det at man designer for alle målgrupper samtidig via en hovedløsning (Sandnes, 2011). Med dette mener man at en hovedløsning fungerer for de fleste i motsetning til å ha flere forskjellige løsninger for å dekke alle kunder uavhengig funksjonsevne. Det finnes to ulike definisjonener på universell utforming, den ene lyder slik: Universell utforming er utforming av produkter og omgivelser på en slik måte at de kan brukes av alle mennesker, i så stor utstrekning som mulig uten behov for tilpassing og en spesiell utforming (Sandnes, 2011). Definisjonen nevnt ovenfor er også knyttet til de syv grunnprinsippene for universell utforming (Sandnes, 2011). Disse er som følger: 44

45 1. Enkel og intuitiv i bruk 2. Forståelig informasjon 3. Toleranse for feil 4. Like muligheter for alle 5. Fleksible i bruk 6. Lav fysisk anstrengelse 7. Størrelse og plass for tilgang og bruk. Ser man på disse prinsippene i forhold til gruppens produkt ser man at produktet tildels følger de fleste av prinsippene. Produktet er enkel og intuitiv i bruk, utformingen til produktet er lett og forstå uten hensyn til brukerens erfaring og kunnskap. Produktet har forståelig informasjon som gjør at produktet kommuniserer informasjon til brukeren på en effektiv måte, uten mange forstyrrelser. Figur 24: Forsiden. På figur 24 ser man at det ikke finnes mange forstyrrende elementer på nettstedet. Man ser også at nettstedet kun kommuniserer nødvendig informasjon til brukeren. 45

46 Produktet har en stor toleranse for feil og utformingen er tilpasset slik at farer og skader som kan gi ugunstige konsekvenser er minimert. Utformingen til produktet gir like muligheter for de fleste. Produktet er brukbart og tilgjengelig for personer med ulike ferdigheter. Man kan bruke produktet med lav fyskisk anstrengelse, og det kan brukes med minimum besvær. Produktet har også størrelse og plass for tilgang og bruk, slik at systemet kan brukes uavhengig av brukerens størrelse, kroppstilling og mobilitet. Gjennom denne måten for evaluering ser man at produktet gruppen har skapt, følger de fleste av de syv prinsippene for universell utforming gitt av The Center for universal Design, North Carolina State University (University, 1997). Den andre dimensjonen man har, er utformet i forhold til IKT i lovtekster, og kommer fra forskrift og diskriminering- og tilgjengelighetsloven og lyder slik Med universell utforming menes utforming eller tilrettelegging av hovedløsning i de fysiske forholdene, herunder informasjons og kommunikasjonsteknologi, IKT, slik at virksomhetens alminnelige funksjon kan benyttes av flest mulig (Sandnes, 2011) WCAG WCAG er en samling retningslinjer for universell utforming og tilgjengelighet laget W3C. Når disse rettningslinjene følges vil innholdet gjøres langt mer tilgjengelig for brukere med nedsatt funksjonsevne og vil bli generelt mye mer brukervennlig. WCAG beregnes i nivå for samsvar hvor A er laveste nivå og AAA høyeste nivå av samsvar. For at nettstedet skal oppnå en grad må samtlige kriterier for nivået oppnås samt krav for eventuelle nivåer i graden som står lavere. 46

47 Helt siden første juli 2011 har det vært et krav at norske nettsteder er tilstrekkelig utformet for tilgjengelighet (Lovdata, Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne, 2008) og ett av kravene som blir nevnt er at nettstedet må ha middels oppnåelse, AA, i rettningslinjene som blir nevnt i WCAG2.0 (Lovdata, Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger, 2013). WCAG har blitt implementert i utformingen ved å ha med tilstrekkelige forklaringer til elementer på nettstedet. Mange elementer er satt opp så de støtter hverandre for å gi en bedre sammensetting av innholdet til siden. Innhold som brukeren er interessert i kommer i rekkefølge, mens de største delene av produktet, timebestilling, forum og informasjon, er alle tilgjengelige fra forsiden. Farge er et hjelpemiddel som blir benyttet i kartet, her har gruppen lagt ved en tekst som kommer opp sammen med fargen til kontinentet brukeren flyter over med pekeren. Farger blir ellers brukt aktivt gjennom sider ved å ytterligere vise at linker er linker og knapper er knapper. Kontrastforholdene som blir krevd ved Figur 25: Minimumsverdier på kontrastforhold. WCAG utifra netlab sin utviklerguide som vist i figur 25 mener at dagens løsninger er på ett nivå godt over minstekravet til visibilitet (Netlab, Udatert). Da tastaturnavigering er fullstendig mulig på nettstedet uten tidsberegning på noen deler av nettstedet så har gruppen klart å oppnå et nivå AA på produktet samtidig som gruppen har rørt ved en del AAA-kriterier, som i kontrastforhold. For å nå helt opp til nivå AAA så må det implementeres alternativer for innhold, som lyd og video, samt tegnspråk og en ordliste for uvanlige ord. Punkter 47

48 gruppen har vært ekstra nøye på er forslag ved feil, gode titler og bilder av tekst siden disse er de enkleste punktene å kunne gjøre en god utforming ved. 48

49 Del 3 Prosessdokumentasjon I denne delen vil gruppen gi en nærmere beskrivelse på hvordan produktet har blitt til. 3.1 Mål Målet for produktet har vært å skape et brukervennlig nettsted for informasjon med god oversikt og mulighet for kunder til å enklere bestille, overvåke og se hvilke vaksiner og legetimer som er bestilt eller allerede har blitt utført ved Oslo vaksineklinikk. Ønsket til oppdragsgiver var at produktet skulle tilby en så god informasjon at kundene selv skal vite hvilken vaksine som trengs til deres reisemål og hvilken type legesjekk som trengs ved utsjekking. Målet for prosjektet har vært å skape ett nettsted som skal kunne bygge opp under vaksinekontoret til oppdragsgiveren. Det skal være en plattform som skal føre kunden frem til dette vaksinekontoret i stedet for andre alternativer og skal med dette gjøre Oslo vaksineklinikk konkurransedyktig mot andre vaksinekontor. 3.2 Bakgrunn for prosjektet Oppdragsgiveren skal starte en vaksineklinikk og trenger en plattform for å vise hvor klinikken holder til og et godt system for å bygge opp under forretningen. Oppdragsgiver ønsker ett nettsted der kunder enkelt kan bestille timer til vaksinering og helsesjekk samt en enkel måte å finne fram all relevant informasjon. 3.3 Kravspesifikasjon Gruppen fikk en kravspesifikasjon som innholdt innebygd fakturasystem, et diskusjonsforum for at kunder kan sende inn spørsmål, en funksjon der kunder kan opprette bruker til nettstedet og en god oppbygning på nevnte diskusjonsforum er prioriterte funksjoner. 49

50 Ønskede funksjoner fra oppdragsgiver var forskjellige betalingsmetoder enn bare faktura, en historikk for kunder som kan fungere som kvitteringer og ett kontaktskjema for direkte kontakt med klinikken. Ekstra funksjoner er å tilby kunden å endre eller slette egen informasjon, mulighet for systemet å automatisk sende påminnelser per epost eller telefon og en egen side for ofte stilte spørsmål. Av de ikke-funksjonelle kravene som ble stilt i oppgaven er brukervennlighet og estetikk satt veldig høyt da oppdragsgiver ønsker et godt og tidløst design som fungerer uavhengig av plattform. Etterfulgt i prioriteten blir sikkerhet og pålitelighet satt, da det er muligens noe sensitiv data som blir lagret i systemet, historie om bestillinger til kundene, og at systemet selvsagt skal gi kunder en følelse av at dette er et legitimt firma. Til slutt så ville oppdragsgiver at produktet skal være så responsivt som mulig, da nettstedet skal fungere uavhengig av plattform og brukere vil kunne aksessere sidene fra mobil eller nettbrett, så vil det også si at mobilt nett er i bruk. Det vil da være fordelaktig å gjøre hva en kan for å få lave lastetider på innhold. For en komplett oversikt over krav henvises det til kravspesifikasjonen i vedlegg 1. Samsvar mellom kravspesifikasjon og ferdig produkt Punkter i kravspesifikasjonen som ikke er levert med produktet er lydfunksjon for synsnedsatte, dette er fordi gruppen ikke følte det så relevant til nettstedet og ingen i gruppen har særlig erfaring med skjermlesere og hvordan dette fungerer med nettsteder. Gruppen har heller ikke lagt ved ett kontaktskjema siden dette vil kunne ta en del trafikk vekk fra diskusjonsforumet. Ofte stilte spørsmål er også satt til diskusjonsforumet av samme grunn som nevnt over. Det siste punktet som ikke ble 50

51 implementert er vaksinehistorikk da gruppen føler dette er godt dekt med det eksterne systemet til helsenorge 5 som er linket til fra profilsiden til brukeren. 3.4 Metode og Planlegging I dette prosjektet benyttet gruppen seg av flere forskjellige metoder for gjennomføringen av produktet. Som en utviklingsprosess startet gruppen med scrum, men etter en stund falt denne prosessmodellen bort og gruppen jobbet uten bruk av en prosessmodell. Etter hvert jobbet gruppen plandrevet, ved at gruppen lagde en plan for hva som skulle bli gjort og fullførte dette etter behov. Til fremdriftsplanen ble det laget en gant-tabell for hvordan arbeidet til gruppen skulle deles opp over tid. Henviser til fremdriftsplanen under vedlegg Produktutvikling Bruk av templates I stedet for å programmere et nettsted helt fra bunnen av, valgte gruppen å benytte seg av templates for designet av nettstedet. Templates er et annet ord for maler, og gjør det enklere å begynne å utvikle et nettsted når man har noe å starte med. Fordeler med bruk av templates 1. Raskere designresultat: Et raskere designresultat vil si at i løpet av kortere tid vil man få et bedre designresultat, enn hvis man hadde måttet begynt helt fra bunnen av. Grunnen til dette er at malen er et avansert designet rammeverk. Trenger man for eksempel en knapp, så er det mange ferdiglagde knapper man kan benytte

52 2. Lavere kostnad og tidsbruk: Ved å bruke templates vil arbeidstiden gå ned fordi man ikke trenger å kode fra bunnen av. Hvis man hadde tatt seg betalt for arbeidet, ville kostnadene gått ned på grunn av at det trengs mindre arbeidstimer. 3. Gode løsninger: Siden det er mye kode i templates, kan koden brukes overalt i systemet. For eksempel kan man bruke samme design på tabeller eller skjemaer, slik at det er gjenkjennelig for brukere gjennom hele systemet. Templates hjelper også for å finne gode løsninger på designproblemer. 4. Mer tid til brukervennlighet: Ved at bruk av templates er tidsbesparende, siden designproblemene blir løst, gjør det at tiden kan bli brukt til å gjøre nettstedet ekstra brukervennlig. Dette er et av de største kravene produktet har, da det skal være mest mulig universelt utformet. Gjenbruk av templates var veldig nyttig for utviklingen av systemet. Ingen på gruppen hadde noe særlig erfaring med webutvikling fra før av, så det å sette seg inn i bruk av templates var veldig lærerikt og gjorde at nettstedet fikk et design gruppen er veldig fornøyd med. Bruken av templates gav også mer tid til å kunne fokusere på funksjonaliteten til systemet. Ulemper med bruk av templates 1. Mye kode å sette seg inn i: Før gruppen kunne begynne å benytte templates til utviklingen, var det viktig å få kunnskap om koden. Siden ingen på gruppen hadde brukt dette før, tok det litt tid å sette seg inn i det. 52

53 2. Ubrukelig kode må fjernes: For at koden til systemet skal se bra ut og siden systemet skal jobbes med videre, er det veldig viktig at ubrukelig kode fjernes helt. Som nevnt i forrige punkt er det da viktig at man har satt seg inn i koden, slik at man vet hvilken kode man ikke skal bruke. Rammeverket Bootstrap Bootstrap er et rammeverk bestående av flere programmeringsspråk. De vanligste er HTML, CSS og JavaScript. Dette rammeverket tilbyr mange funksjoner og ferdigkode, som man kan implementere i sitt eget eksisterende nettsted. Det er ikke funksjonell kode. Dette vil si at det er kun kode for design og det er ikke ferdiglaget kode for for eksempel samhandling med en database. Grunnen til valget av dette rammeverket, var at det gav et solid fundament og noe å bygge videre på. Bootstrap tilbyr i tillegg en administrasjonsside, noe som passer perfekt til prosjektets formål. Etter møtet med oppdragsgiver, var det dette rammeverket som valget falt på. En annen god grunn for at gruppen valgte Bootstrap var på grunn av gridsystemet den tilbyr. Grid brukes for å lage nettsidelayout ved hjelp av rader og kolonner for nettstedets innhold. Dette gjør at nettstedet blir responsivt og vil gjøre at innholdet skallerer riktig, slik at det gjøres brukervennlig på alle enheter (Bootstrap, Versjon 3.3.4). Det tok litt tid å begynne å bruke Bootstrap, da det er veldig mye kode og funksjoner som ikke er nødvendige til det formålet en har. Først måtte gruppen fjerne all unødvendig kode fra rammeverket til nettstedet og administrasjonssiden. Dette var en tidkrevende prosess, men resultatet ble veldig mye bedre enn hvis gruppen skulle kodet det helt selv fra bunnen av. 53

54 Da all koden var ryddet opp, kunne gruppen begynne å legge inn funksjonskode, slik at systemet kan samhandle med databasene. Dette var det mest krevende under hele prosjektet, da gruppen måtte konstruere all kode selv slik at det var perfekt til produktets formål. Database Gruppen startet utviklingen med å designe og sette opp databaser. Denne prosessen startet med at alle tabeller som kunne være relevante til prosjektet ble skrevet ned, slik at gruppen fikk en viss oversikt for å kunne sette sammen en database. Det neste steget var å utelukke de overflødige tabellene og sette sammen et ER-diagram, slik at man kunne se relasjonene mellom tabellene. Dette ER-digrammet er vist i figur fem. Etter at designet og oppsettet av databasen så korrekt ut, ble tabellene fylt inn i phpmyadmin som er en administrasjonsside for å enkelt opprette databaser. Der ble også relasjonene mellom tabellene satt opp. En typisk database vil se ut som for eksempel i tabellen vist i figur 26 som viser hvordan brukertabellen er satt opp. Her ser man hvilke opplysninger en bruker av nettstedet må oppgi og hvilke felter som blir automatisk satt som, for eksempel bruker id det vil si user_id i tabellen. Denne brukes for å identifisere brukere. Figur 26: Databasetabell over brukere. 54

55 3.5 Arbeidsteknikker Gruppearbeid Ny Arbeidsmetode Gruppen har fått erfart hvordan det er å jobbe i et team, samtidig som man må levere fra seg et godt produkt slik at oppdragsgiveren blir fornøyd. Størrelsen på dette prosjektet, kontra andre prosjekter, er stor. Man får hele tiden nye oppgaver som skal bli gjort, og det er vanskelig å estimere tid samt den egentlige størrelsen på prosjektet. I tillegg skal dette prosjektet ut på nett og benyttes av ordentlige kunder. Det har vært et stort ansvar gruppen har hatt, men veldig lærerikt og utrolig spennende. Arbeidsforhold Arbeidsforholdet i gruppen har fungert utmerket. Hvert gruppemedlem har forskjellige egenskaper og ulike interessepunkter, og dette har bidratt til at det har vært svært enkelt å fordele ansvar. Litt sykdom og fravær på grunn av jobb har det vært, men dette har ikke påvirket prosjektet i negativ forstand. Henviser til risikoplan i vedlegg 2 for en komplett plan over hva som har blitt gjort om noe skulle skje. Gruppen har under hele prosjektet holdt kontakten gjennom Facebook. Filer har blitt delt over Google Dokumenter og Dropbox. Jobb og arbeid Alle gruppemedlemmene har hatt deltidsjobb ved siden av bachelorprosjektet. Gruppen har hatt en god dialog, og har vært forståelsesfulle og fleksible hvis noen plutselig måtte dra for å jobbe eller ikke kunne ta fri, for å møte. Gruppen har hele veien sett alternative løsninger og hjulpet hverandre med ting som har vært utfordrende. Løsninger Gruppen ble enige om gruppemøter omtrent en uke i forveien, så medlemmene enkelt kunne planlegge uken med jobb- og bachelorarbeid. Gruppemedlemmene har hele tiden hatt arbeidsoppgaver og arbeidsfordelingen har vært ganske likt. 55

56 3.5.2 Gruppens kommunikasjon Gruppens kommunikasjon har vært god i løpet av hele prosjektet. Under dette prosjektet har gruppen lagt opp tiden slik at medlemmene jobbet mest hver for seg, men møtte hverandre en til to ganger i uka for å blant annet holde hverandre oppdaterte. Da ble det også planlagt videre arbeid og hva som måtte bli gjort til neste gruppemøte. De dagene det ikke var gruppemøte, holdt medlemmene kontakten via Facebook. Henviser til avsnitt om Facebook. Gruppemøtene var minst en gang i uka og møte med veileder var rundt hver andre uke eller etter behov når gruppen følte de trengte noe ekstra veiledning. Da det var få møter i uka, var det viktig at gruppen fikk så mye ut av møtene som mulig. På gruppemøtene fortalte gruppemedlemmene hva de hadde gjort siden forrige møte, om de hadde støtt på noen problemer og hva de skulle gjøre videre. Fordeling av oppgaver på gruppemøtene var veldig viktig for fremgangen til prosjektet. Derfor var gruppen strenge på at alle alltid skulle ha noe å gjøre til neste møte. Kommunikasjon med oppdragsgiver Gruppen møtte oppdragsgiver kun en gang i løpet av prosjektet. Grunnen til at det ble bare denne ene gangen var på grunn av oppdragsgivers arbeidssituasjon og at han bodde langt unna. På dette møtet fikk gruppen nok informasjon til å kunne sette i gang planleggingen og starte arbeidet med produktet. Gruppen har hatt tilnærmet full kontroll til å utforme produktet slik de ønsket selv, da oppdragsgiver mente gruppen har bedre kompetanse enn han når det kommer til utforming. Likevel har det vært viktig for medlemmene i gruppen å høre oppdragsgivers synspunkter og meninger under utviklingen. For eksempel om ulike funksjoner, design og fargevalg. Denne kommunikasjonen ble gjort over telefon og epost. 56

57 Et av gruppemedlemmene ble satt som kontaktperson og fungerte som bindeleddet mellom gruppen og oppdragsgiver. Det var ikke alltid oppdragsgiver var tilgjengelig. Da måtte gruppen bare ta et valg for å kunne fortsette fremgangen i prosjektet. Kommunikasjon med veileder Gruppen har møtt veileder Thor Hasle omtrent annen hver uke. På møtene har gruppen fått vist veileder utviklingen i prosjektet og diskutert videre hva som måtte gjøres. Det var på disse møtene gruppen fikk Thor sine synspunkter om bruk av templates og tok en endelig avgjørelse på å lage et utkast med dette fram til møte med oppdragsgiveren. Ett av disse utkastene er vist i vedlegg Verktøy I dette prosjektet har gruppen benyttet seg av forskjellige programvarer for styringsdokumenter og utvikling av nettstedet. For å ha en enkel måte gruppen kunne kommunisere med hverandre på, ble det opprettet en felles innboks for alle medlemmer av gruppen på Facebook. Det ble også benyttet verktøy som Dropbox, slik at gruppemedlemmene kunne dele filer med hverandre og Google Dokumenter for å kunne jobbe på samme tekst dokumenter samtidig. 57

58 3.6.1 Dropbox Dropbox er et filarkiv som vises på enheten din men ligger lagret på nett, noe som gjør at man kan aksessere filer mellom forskjellige enheter og brukere. Dette kan gjøres ved å for eksempel lage en mappe gruppemedlemmene har tilgang til, i denne mappen kan man redigere og laste opp filer man vil dele med resten av gruppen. Dropbox var veldig viktig for dette prosjektet, da gruppemedlemmene kunne jobbe og redigere de samme filene, selv om de ikke måtte sitte fysisk tilstedet sammen og jobbe. Gruppemedlemmene har hatt gode erfaringer med programmet, og det har blitt brukt i omtrent alle tidligere gruppeprosjekter på studiet på Høgskolen i Oslo og Akershus. Dette gav gruppen mulighet til å kunne dele prosjektet i mapper og undermapper, slik at alle kunne jobbe med sitt, og samtidig hadde alle oversikt over hverandres arbeid Facebook Facebook er et sosialt nettsted hvor brukere kan opprette sin egen profil. Profilen kan inneholde personlig informasjon og brukeren bestemmer selv hvor synlig profilen skal være. Her kan man legge til venner og få venneforespørsel fra andre brukere. Brukere kan skrive status oppdateringer og laste opp bilder som de vil dele med vennene sine. Facebook har blitt brukt under hele studietiden på Høgskolen i Oslo og Akershus. Den viktigste funksjonen gruppen har benyttet seg av, er muligheten til å sende meldinger med flere personer samtidig over Facebook. Ved å skrive til hverandre gjennom en felles innboks for meldinger, har det vært enkelt å kommunisere med hverandre og å avtale gruppemøter. 58

59 3.6.3 Google Dokumenter For å skrive styringsdokumentene og sluttrapporten har gruppen benyttet seg av Google Dokumenter. Dette er en kontorpakke, ganske lik Windows Office, forskjellen er at det er nettbasert og gratis å bruke. Grunnen til at gruppen benyttet seg av dette, var at alle gruppemedlemmene kunne redigere dokumentene samtidig og kunne få tilgang til dokumentene på alle ønskede enheter Bootstrap Produktet er bygget opp via et rammeverk fra Bootstrap. Dette rammeverket er brukt til både nettstedet og administrasjonssiden. Bootstrap inneholder HTMLog CSS-baserte templates på for eksempel tabeller, knapper og skjemaer Netbeans Produktet er skrevet i NetBeans. NetBeans er en utviklingsplattfrom som er ett av de aller mest utbredte programmene for utvikling. Dette programmet støtter blant annet HTML5, PHP, C/C++ og Java. I dette prosjektet har gruppen benyttet seg av dette utviklerprogrammet fordi det er enkelt og støtter Bootstrap sitt rammeverk PhpMyAdmin PhpMyAdmin er ett program som følger med XAMPP og er tilgjengelig via localhost. Dette er ett verktøy hvor en kan opprette og holde styr på databaser. Gruppen brukte PhpMyAdmin aktivt under opprettelsen av brukere og ved administrasjonssiden. 59

60 3.6.8 XAMPP XAMPP er en åpen kildekode og gratis nettserver-program, bestående av Apache, HTTP og MySQL - database skrevet i PHP. Gruppen har brukt XAMPP for å sjekke endringer i arbeidet uten å overføre filer frem og tilbake fungerende server. XAMPP fungerer slik at du kopierer inn ditt prosjekt i en htdocs-mappe, og dermed kan siden kjøres fra localhost. En har også tilgang til FileZilla, overføring av filer til server, og phpmyadmin. 3.7 Produkttesting Formål med brukertest Test på Administrator Brukertesten skal avdekke om designet og oppsettet av administrasjonssiden er tilstrekkelig og brukervennlig, slik at brukeren effektivt kan bruke systemet og om han har forståelsen av funksjonene på systemet. Til denne testen vil det kun være en testpersonen, og det er gruppens oppdragsgiver som skal være den enste administratoren på nettstedet. Testen skal også avdekke eventuelle feil og mangler med systemet. Test på brukere Brukertesten av nettstedet skal avdekke eventuelle svakheter ved brukervennligheten, gjennkjenbarheten og forståeligheten. Den skal også avdekke om eventuelle feil eller mangler ved nettstedet og potensielle forbedringer Hvilket deler av programmet skal testes? Både administrasjonssiden og nettstedet skal testes. Hos nettstedet er det de viktigste funksjonene som bestillingsystemet, diskusjonsforumet og innlogging 60

61 som skal testes. Mens administrasjonssiden skal teste om bruker klarer å redigere, slette og opprette i databasen. Administrasjonssiden Testpersonen får teste administrasjonssiden ved å logge inn i systemet med en bruker som har administrator rettigheter. Når dette er gjort får han i oppgave å finne frem til en funksjon og bruke denne på en spesifikk måte. På denne måten vil administratoren få testet systemets design og brukevennlighet. Han vil også få en god forståelse av systemets funksjonalitet. Nettstedet Testpersonene skal teste de viktigste funksjonene til nettstedet. Det vil si bookingsystemet, diskusjonsforumet og innhenting av informasjon om hvilke vaksiner man trenger til reisemålet. De får også et scenario de skal benytte under brukertesten Metode og organisering Administrasjonssiden Testpersonen skal få disse oppgavene å gjennomføre: 1. Logge inn med brukernavn og passord, og komme seg til administrasjonssiden. 2. Se timehistorikken til en bruker som heter Bruker Brukersen. 3. Legge til en kategori i diskusjonsforumet. 4. Endre navnet til kategorien som ble opprettet. 5. Slette kategorien som ble opprettet. 6. Blokkere en bruker som heter Bruker Brukersen i diskusjonsforumet. 61

62 Nettstedet Testpersonene skal få noen oppgaver de må gjennomføre. Det er utviklet et scenario testpersonene skal benytte seg av. Scenariet er at de skal reise på ferie til Brasil og er interessert i å vaksinere seg før reisen. 1. De skal logge inn med brukernavn og passord som blir gitt til dem. 2. De skal finne ut hvilke vaksiner de trenger for å reise til Brasil. 3. Så skal de finne prisen til disse vaksinene. 4. Deretter skal de opprette et emne i diskusjonsforumet under kategorien Reiseråd, hvor de skal spørre om reisetips til Brasil. 5. Til slutt skal de bestille en time for vaksiner ved Oslo vaksineklinikk. Under testen blir testpersonene bedt om å tenke høyt. Testpersonene forteller da høyt hva de gjør, mens de utfører oppgavene. Under testen skal det være en observatør og en testleder. Observatøren noterer seg det testpersonen gjør og sier. Mens testlederen forklarer og er med på gjennomføringen av brukertesten. Etter brukertesten skal det gjennomføres et kort intervju, slik at man kan få vite deres brukeropplevelse av tjenesten. Det skal ikke testes flere enn fem personer, men de samme personene skal testes flere ganger gjennom utviklingen av produktet Resultat Administrasjonssiden Da oppdragsgiver måtte avlyse brukertesten på grunn av jobb, måtte oppdragsgiver teste administrasjonssiden via TeamViewer 6 som er et skjermdelingsprogram som lot både gruppen og oppdragsgiver se på samme nettside samtidig

63 Oppdragsgiver fikk prøvet ut funksjonene og hadde god forståelse for hvordan man kunne redigere i databasen. Han skjønte også hvordan han kunne legge til kategorier og emner. Han var fornøyd med designet og brukervennligheten til siden. Nettstedet Resultatene var i alt veldig bra. Alle testpersonene klarte å gjennomføre oppgavene de ble gitt. Det var noen som hadde innvendinger eller tips til forbedringer. Innlogging Noen av testpersonene skjønte ikke at de hadde logget inn på grunn av for dårlig tilbakemelding. Men etter å ha trykket på innloggingsknappen igjen og fikk tilbakemelding på at de var logget inn, kom de seg videre. Det var også en bruker som slet litt med størrelsen på teksten til nettstedet. Vaksinekartet og vaksineinformasjon Bruk av vaksinekartet fungerte veldig bra for alle testpersonene. Derfra fant nesten alle frem til landet de skulle finne vaksineinformasjon hos, men det var en testperson som trykket på flagget til landet og ikke linken dens. Når de var kommet frem til landet, brukte flere av testpersonene lang tid på å finne ut av hvilke vaksiner de trengte. De lurte også på betydningen av boosterdose og hva den gjaldt. Det var også noen av testpersonene som lurte på hvorfor de skulle vite hva slags vaksiner de skulle ta, de tenkte at dette var noe legen burde vite. Prisliste Alle brukerene klarte å finne prisene for vaksinene de trengte. Flertallet likte oppsettet til prislista og fant fort ut hva det kostet for vaksinene. En testperson likte ikke oppsettet og syntes det var uoversiktlig. 63

64 Forumet Alle testpersonene klarte å legge til et emne i Reiseråd -kategorien. Når emnet var opprettet skjønte ikke enkelte at de kunne trykke på linken for å se emnet de hadde opprettet. Ellers fant de forumet enkelt og brukervennlig. En tilbakeknapp gjorde at brukeren måtte bekrefte nytt sending av skjema, og nettsiden fikk feilmelding. Timebestilling Brukerene likte måten en bestiller time på og hadde ingen store innvendinger på denne. De likte oppsettet og syntes det var enkelt å bruke. Noen testpersoner fant ut av knappen med forklaringer til kalenderen for timebestillingen, mens andre leste teksten under kalenderen for å finne ut når de kunne bestille time. Etter det var det enkelt å bestille timen for testpersonene. Når timen var bestilt, lurte en bruker på hvor han får informasjonen om bestillingen, siden det ikke var noen tilbakemelding på det. Tiden fra timebestillingen var gjennomført til brukeren ble sendt tilbake til forsiden var også litt kort Konklusjon Som en konklusjon på brukertesting så gruppen at nettstedets funksjon fungerte bra, de aller fleste testpersonene klarte å utføre oppgavene de hadde fått. Administrasjonssiden Forholdene til brukertesten med oppdragsgiver var ikke optimale, da brukertesten skjedde over nettet. For å få testet administrasjonssiden godt nok måtte oppdragsgiver vært til stedet. Tatt dette i betraktning konkluderer gruppen med at administrasjonssiden er brukervennlig nok, siden oppdragsgiver klarte å bruke funksjonene uten noe særlig veiledning fra gruppemedlemmene. For å kunne jobbe mer effektivt med systemet og å unngå å gjøre feil, anbefaler 64

65 gruppen ham å lese brukermanualen for administrasjonssiden som en innføring til systemet. Nettstedet Ut i fra brukertesten fremstod nettstedets design og brukervennlighet på en god måte. Det som var av småproblemer som for eksempel tilbakemelding på innloggingen og enkelte andre tilbakemeldinger, er nå rettet opp. Når en bruker logger seg inn vil han nå automatisk bli ført til forsiden. Vanskeligheten med å finne ut av hvilke vaksiner man trengte til reisedestinasjonen sin bør endres. Dette er ikke noe gruppen kommer til å endre på nå. Dett er på grunn av oppdragsgivers ønske om å bruke standardteksten fra NEL, men gruppen skal anbefale han i å endre denne teksten slik at den blir mer forståelig for brukere. 3.8 Videre utvikling Nettstedet gruppen har laget, er laget slik at det skal være lett å videreutvikle nettstedet dersom dette skal være ønskelig eller informasjon endrer seg. På grunn av tidsmangel var det et par ting gruppen ikke fikk mulighet til å legge inn, dette er oppgaver som kan bli gjort i etterkant dersom ønskelig for oppdragsgiver. De mest essensielle tingene oppdragsgiver kan legge til er en slags handlekurv til bookingsystemet, hvor brukere kan velge med seg vaksiner og produkter som blir tilbudt ved klinikken. En sammenkobling av session-variablene av databasene til brukere og til bookingen så man ikke lenger er nødt til å skrive inn informasjon ved utsjekking. Som nevnt i brukertestingen så hadde en litt mer oversiktlig prisliste vært ønskelig. 65

66 Del 4 - Avslutning 4.1 Læreutbytte Fra starten av og underveis i prosessen har gruppen fått erfart at det er mye som skal gjøres og ikke minst læres under en bacheloroppgave. Du får en oppgave av en arbeidsgiver som stiller visse krav, du skal jobbe strukturert over en lengre periode og du skal i tillegg tilegne deg mye ny informasjon. Gruppen har dermed hatt enormt læringsutbytte av oppgaven, lært mye nytt og erfart hvordan det er å arbeide i ett team over en lengre periode Læreutbytte prosess Det er første gang gruppen arbeider med et så stort prosjekt sammen og med vanskelighetsgraden så høy som den var. For å skape en god progresjon i arbeidet, startet vi tidlig med skisser, en milepælsplan og en kravspesifikasjon som har vært våre bærebjelker i prosessen. Med god hjelp fra vår veileder har gruppen hele tiden holdt motivasjonen oppe og jobbet jevnt og trutt. Nye arbeidsoppgaver har blitt fordelt hver uke, slik at prosjektet fikk den progresjonen vi ønsket Læreutbytte produkt Sluttproduktet gruppen nå gir fra seg er basert på ulike programmeringsspråk og teknologier. Gjennom tre år ved Høgskolen i Oslo og Akershus har gruppen tilegnet seg kunnskap, som har kommet godt med i arbeidet. Men er det noe gruppen har erfart, så dukker det alltid opp utfordringer og problemer når du arbeider med teknologi. Alt fra feil i programmer til å lære seg et helt nytt programmeringsspråk. 66

67 Siden ingen av gruppemedlemmene hadde brukt Bootstrap tidligere, måtte gruppen sette seg ned å finne ut av hvordan rammeverket fungerer. Etter timer med gjennomgang av kode og instruksjoner, fant vi ut at dette kunne passe gruppen utmerket. Bruken av Bootstrap er noe gruppen ikke angrer på, det har vært en lærerik og fin prosess. Oppdragsgiveren hadde sine krav for oppgaven, og gruppen føler de har klart å gjennomføre disse på en fin måte Læreutbytte dokumentasjon Gruppen startet tidlig med å notere ned ting som skulle være med i dokumentasjonen. I følge vår veileder, var dokumentasjonen en stor del av arbeidet med en bachelor oppgave og gruppen har brukt mye tid på å skrive. Etter hvert møte, har gruppen skrevet rapport og oppdatert prosjektsiden. Slik at alle gruppemedlemmene enkelt kunne se hva som var gått gjennom eller arbeidsoppgaver hadde blitt tildelt. Under hele prosessen har gruppen brukt dokumentasjonen som et hjelpemiddel for å kunne utføre arbeidet av produktet. Alt fra bruk av fremdriftsplan, use-case diagrammer til det å lage en brukermanual har gruppen latt seg inspirere av bruken av dokumentasjon. Gruppen har lært veldig mye gjennom først å utarbeide produktet for siden å dokumentere det i rapporten. 67

68 4.2 Kunne vi gjort noe annerledes? Gruppen er strålende fornøyd med det produktet vi leverer fra oss og hvordan samarbeidet i løpet av semesteret har vært, men naturligvis er det ting gruppen også kunne gjort annerledes og bedre. I starten gikk det mye tid til planlegging, og gruppen måtte bli enige om en del ting før arbeidet kunne starte. I ettertid har gruppen erfart at kravspesifikasjon og fasen før prosjektet virkelig starter opp er viktig, og dette burde blitt gjort raskere. Underveis i arbeidet har det dukket opp utfordringer som jobb, sykdom, mangel på tid og andre innleveringer på skolen. Dette er utfordringer som er vanskelig å unngå. Gruppen kunne vært mer strenge mot de eller dem som vært syke/borte og gitt dem mer arbeid, men behandlingen har vært lik mot alle og gruppen føler de har taklet utfordringen på en eksemplarisk måte. Sluttfasen av arbeidet har vært hektisk og lærerikt. Gruppemedlemmene har hatt ulike valgfag og arbeidstider, så det har vært litt problematisk å finne møtetider for gruppen. Selv om gruppen ikke alltid har hatt tid til møter, har gruppemedlemmene funnet sin rolle, og gjort sitt beste for at dette produktet skulle bli ferdig. 68

69 4.3 Fremtidsutsikter for produktet Produktet skal nå administreres videre av oppdragsgiver, som har lite kunnskap om webutvikling eller design. Likevel føler gruppen at de har skrevet en god manual og vært flinke til å kommentere kode, slik at oppdragsgiver enkelt burde kunne drive denne siden videre. Ved en senere anledning kan det være at oppdragsgiver vil endre eller ta bort funksjonalitet gruppen har implementert. Gruppen vil derfor gi en egen brukermanual for siden, slik at oppdragsgiver vet hva han skal gjøre. Eventuelle land eller annen kode som ikke er ferdigutviklet enda, skal fullføres av oppdragsgiveren selv. Grunnen til dette er at gruppen ikke ser noe læringsutbytte ved å kopiere tekst fra alle verdens land og inn på siden. Dette ville tatt mye tid, og arbeidet med å fullføre siden ville stagnert. 4.4 Oppsummering og konklusjon Gruppen startet prosjektet med forventninger om at vi skulle lære mye nytt og at alle måtte arbeide hardt for at bacheloroppgaven skulle bli en realitet. Gruppen var inneforstått med at det kunne dukke opp problemer underveis, men at disse måtte håndteres når de oppstod, og gjøre det beste ut av situasjonen. Dette er første gang gruppen arbeider tett med en oppdragsgiver i et prosjekt. Så dette har uten tvil vært det mest utfordrende og spennende arbeidet i tiden på Høgskolen i Oslo og Akershus. Gruppen sitter igjen med positive minner, med tanke på hvordan prosjektet er blitt løst. Oppdragsgiver er fornøyd med sluttproduktet, og gruppen må si seg fornøyd med det produktet som er levert. 69

70 Prosjektet har gått over all forventning i forhold til ambisjoner gruppen satte seg. Selv med problemer underveis, har gruppen hele tiden hatt fokus på å finne løsninger og heller fokusere på arbeidsoppgaver. Gruppen har blitt kjent med hverandre på en ny måte. Lært hverandre å samarbeide og finne gode relevante løsninger på teknologiske problemer. Gruppen er like gode venner nå, som da prosjektet startet. Basert på den positive opplevelsen med dette arbeidet, alt gruppen har lært og det fine sluttproduktet, vil gruppen si seg meget fornøyd med innsatsen dette semesteret. Gruppen vil gjerne takke veileder og oppdragsgiver, for måten de har hjulpet og veiledet oss gjennom tider gruppen kanskje hadde stagnert litt. Gruppen tar med seg all erfaring og læring fra Høgskolen i Oslo og Akershus, ut i arbeidslivet og føler at skolen har gitt oss tilstrekkelig med kunnskap slik at utfordringer som dukker opp, ikke skal være noe problem. 70

71 Del 5 - Kilder 1. Bootstrap. (Versjon 3.3.4). CSS. Hentet Februar 2015, fra 2. CSS & jquery Clickable map. (Versjon ). Hentet fra 3. Datatilsynet. (udatert). Hva er personvern. Hentet Mai 6, 2015, fra 4. Feerst, E., & Stewart, D. (2007). What is an "internet forum"? Hentet Mai 06, 2015, fra 5. Invoice Manager. (Udatert). Hentet fra 6. Lovdata. (2008). Lov om forbud mot diskriminering på grunn av nedsatt funksjonsevne. Hentet April 2015, fra 7. Lovdata. (2013). Forskrift om universell utforming av informasjons- og kommunikasjonsteknologiske (IKT)-løsninger. Hentet April 2015, fra 8. Netlab. (Udatert). Knotrast (minimum). Hentet Mai 2015, fra 9. Photoshop. (Udatert). Hentet fra Sandnes, F. E. (2011). Universell Utforming av IKT Systemer. Universitetsforlaget. 11. Time Slots Booking Calendar. (Udatert). Hentet fra 71

72 12. University, N. C. (1997). The Principles of Universal Design. Hentet April 2015, fra w3schools. (Udatert). Browser stats. Hentet April 2015, fra w3schools. (Udatert). PHP mysqli_real_escape_string() Function. Hentet Mars 2015, fra w3schools. (Udatert). SQL injection. Hentet Mars 2015, fra 72

73 Del 6 - Vedlegg 1. Kravspesifikasjon 2. Risikoplan 3. Fremdriftsplan 4. Skisser 5. Bruksmønstre 6. Brukermanual for administrasjonsside 73

74 Vedlegg 1 Kravspesifikasjon Prioritert funksjonalitet: Systemet skal kunne: 1. Ha et innebygd faktura system, slik at kunden kan betale vaksinen med faktura. 2. Ha et diskusjonsforum, der kunden sender inn spørsmål de lurer på og legen kan svare. 3. Ha et loginsystem for å kunne bestille vaksiner og delta i diskusjonsforumet. 4. Kategorier på forumet, slik at kunder lett kan finne hva andre har spurt etter. Legen skal være admin, slik at han kan endre/slette meldinger der. 5. Ha en lyd-funksjon for synshemmede. 6. Vaksinekart slik at brukere kan finne vaksineinformasjon om reisemålet sitt. 7. Være generelt universelt utformet. Ønsket funksjonalitet: Systemet bør kunne: 1. Ha en annen betalingsmetode enn faktura. For eksempel Pay Pal. 2. La brukere kunne se vaksinehistorikk. 3. Ha et eget kontakt meg skjema, hvor kundene får direkte kontakt med legen. Eventuell tilleggsfunksjonalitet Systemet kan eventuelt kunne: 1. La kunde endre kontoinformasjon 2. Få SMS/Epost påminnelse om vaksinetime. 3. Ha en FAQ side hvor kunden kan se ofte stilte spørsmål. 1

75 Vedlegg 1 Kravspesifikasjon Ikke-funksjonelle krav Produktkrav Brukervennlighet 1. Nettstedet skal følge retningslinjer og krav til universell utforming. 2. Språket på nettstedet skal være på norsk bokmål. 3. Nettstedet skal ikke inneholde vanskelige fremmedord og fagspråk. Effektivitetskrav 1. Nettstedet skal kunne kjøres i alle typer nettlesere og lastes inn innen normal hastighet. (Rundt 1 sekund) Pålitelighetskrav 1. Data skal lagres trygt i en database. 2. All informasjon på nettstedet skal være tilgjengelig og oppdatert. 3. Sikkerhet ved bestilling av vaksiner. Estetiske krav 1. Oppsettet skal gjøre det lett å finne frem. Ikke mer enn tre museklikk. 2. Gjennomgående farge/farger i hele nettstedet. Rammekrav 1. Nettstedet skal fungere på alle nettlesere og på alle enheter. Dvs. PC, Mac, Iphone, android og nettbrett osv. 2. Programmeringspråkene HTML5, CSS, PHP, javascript og MYSQL skal brukes. 3. Template skal brukes. 2

76 Vedlegg 2 Risikoplan Det er en del som kan gå galt på grunn av uforutsigbare årsaker i et prosjekt. Disse årsakene kan dukke opp når en minst venter det, så da er det best å være forberedt på hva en kan gjøre for å motvirke eller tilintetgjøre problemet. Derfor må vi ha risikoer planlagt i en risikostyring tidlig i prosjektet så alle gruppemedlemmer er inneforstått med hva som må gjøres om noe uventet skulle skje. Utover risikostyringen er det viktig at både gruppemedlemmer, intern veileder og prosjektgiver sier ifra om en skal reise på ferie, jobb eller er sykemeldte så arbeidet kan tilpasses rundt dette. Årsaker vi er forberedte på å møte er: Sykdom, uenigheter, tekniske problemer/tap av data, tidsproblemer, forsinkelser, jobb/reise, dårlig motviasjon, ulike fagkunnskaper, tap av gruppemedlemmer, kommunikasjonsproblemer og endriger av krav til sluttprodukt. Datatilsynet nevner i deres veiledning i risiko at konsekvensen skal rangeres i fire ulike grader som følger: K=1, liten konsekvens. K=2, moderat konsekvens. K=3, stor konsekvens. K=4, katastrofal konsekvens. Videre er det sagt at sannsynligheten for at hendelsene kan inntreffe skal også rangeres som konsekvensvurderingen blir rangert. gradene for sannsynligheten er som følger: S=1, lav sannsynlighet for at hendelsen inntreffer. S=2, moderat sannsynlighet for at hendelsen inntreffer. S=3, høy sannsynlighet for at hendelsen inntreffer. S=4, svært høy sannsynlighet for at hendelsen inntreffer. 1

77 Vedlegg 2 Risikoplan Risiko Konsekvens Strategi Sannsynlighet og konsekvens Sykdom Gruppemedlem kan komme forsinket eller ikke være tilstedet på møte eller få arbeidet under sykdomsperioden. Jobbe hjemme om mulig og kommunisere med gruppen via nett/telefon. Starte alltid med oppgaver som har høyest prioritet. S=4, K=2 Uenighet Arbeider kan stoppe opp. Prøve å løse problemet og få god stemning tilbake til gruppen. S=1, K=2 Tekniske problemer/tap av data Arbeid som er gjort må enten letes fram eller må gjøres på nytt. Prioriter det viktigste arbeidet og jobbe effektivt for å få tatt igjen det tapte. Også sørge for man har flere kopier av dataene slik at om noen mister data, kan en annen finne det igjen. S=1, K=3 Tidsproblemer Må jobbes sene kvelder. Fordel det resterende arbeidet best mulig og jobb effektivt sammen. S=1, K=2 Forsinkelser Går utover gruppemedlemmet som er forsinket, siden resten av medlemmene starter arbeidet selv. Si ifra til gruppe, begynne å jobbe uten resterende medlemmer. S=3, K=1 Jobb/reise Dårlig planlegging vil gjøre gruppemøter og videre arbeid litt problematisk. Sørge for at alle har en ide av hva som skal bli gjort, slik at en kan tilpasse tiden og unngå problemet. S=4, K=1 2

78 Vedlegg 2 Risikoplan Dårlig motivasjon Vedkommende jobber ikke like godt og produktet kan være av lavere kvalitet. Holde kommunikasjonen i gang og motivere hverandre. S=1, K=2 Ulike fagkunnskaper Oppgaver må omfordeles. Lære av hverandre og fordele punkter strategisk blandt gruppemedlemmer. S=3, K=1 Tap av gruppemedlem En stor del arbeid må omfordeles på resterende medlemmer. Møte med gjenværende gruppemedlemmer og fordele arbeidet som har blitt ledig. S=1, K=3 Kommunikasjonspr oblemer Arbeid kan stoppe opp om det kommunikasjonen er kritisk for videre utvikling av prosjektet. Legge igjen mail/telefonsvar og få gjort så mye som mulig i løpet av de møtene vi får. S=2, K=3 Endringer i krav Produktet må forandres på. Se på nåværende punkter og endre til å tilfredstille krav. S=2, K=3 3

79 Vedlegg 3 Fremdriftsplan Fremdriftsplan i gant diagram 1

80 Vedlegg 4 Skisser Nettstedskart 1

81 Vedlegg 4 Skisser 2

82 Vedlegg 4 Skisser 3

83 Vedlegg 5 Bruksmønstre Use Case diagram 1

84 Vedlegg 5 Bruksmønstre 2

85 Vedlegg 5 Bruksmønstre 3

86 Vedlegg 6 Brukermanual for Administrasjonsside Brukermanual Oslo vaksineklinikks administrasjonsside 1

87 Vedlegg 6 Brukermanual for Administrasjonsside 1. Forord 1.1 Produktet Produktet i denne brukermanualen er en administrasjonsside som lar brukeren administrere databasen til Oslo vaksineklinikks nettsted. Her kan administrator legge til, endre og slette i databasen. I tillegg til dette er formålet med administrasjonssiden å være brukervennlig og enkel å bruke. I denne brukermanualen er brukernavn og passord standardbrukeren oslovaksineklinikk@gmail.com med Admin123 som passord. Til produktet hører også med nevnt gmail-konto, med brukernavn oslovaksineklinikk@gmail.com og passord, Gruppe21. Denne kontoen er brukt for registreringer og kund Brukeren Forkunnskaper Administrator er den som skal være ansvarlig for styring og oversikt av nettstedet. Denne administratoren behøver ikke å ha store kunnskaper innen data og IT, da produktet er selvforklarende og enkel i bruk. Produktet er spesiallaget for å kunne brukes uten store forkunnskaper, men generell datakunnskap er en fordel Opplæring Selv om produktet ikke krever store forkunnskaper, anbefales det noe opplæring for å kunne jobbe effektivt med det. Denne opplæringen kan skaffes fra en av produktets utviklere eller lese og teste i samarbeid med denne brukerveiledningen. 2

88 Vedlegg 6 Brukermanual for Administrasjonsside 1.3 Generelt om brukermanualen Om brukermanualen Denne brukermanualen er til administratoren av systemet, slik at det enkelt kan slås opp i dokumentasjonen for å finne svar på eventuelle problemer eller spørsmål som måtte oppstå. Denne skal fungere som en guide som skal hjelpe administrator med å nå sitt mål Hva brukermanualen skal brukes til Brukermanualen skal forklare trinn for trinn funksjonene til systemet. Dette gjør at brukeren får en enkel opplæring av systemet og kan begynne å bruke det så raskt som mulig. 3

89 Vedlegg 6 Brukermanual for Administrasjonsside Innholdsfortegnelse 1. Forord Produktet Brukeren Forkunnskaper Opplæring Generelt om brukermanualen Om brukermanualen Hva brukermanualen skal brukes til Innledning Hva er hensikten med programmet? Hva gjør programmet? Veiledning for bruk av programmet Åpne og aksessere administrasjonssiden Prosedyre for administrasjon av diskusjonsforumet Legge til en kategori i diskusjonsforumet Rediger en kategori i diskusjonsforumet Fjerne en kategori i diskusjonsforumet Legge til et emne i en kategori i diskusjonsforumet Rediger et emne i diskusjonsforumet Fjerne et emne i diskusjonsforumet Redigere en melding i diskusjonsforumet Fjerne en melding i diskusjonsforumet Blokkere brukere fra diskusjonsforumet Prosedyre for administrasjon av brukere Redigere en bruker Slette en bruker Gjør en vanlig bruker til administrator Prosedyre for timehistorikk

90 Vedlegg 6 Brukermanual for Administrasjonsside Se timehistorikken til en valgt bruker Bookingsystem Innledning Programmet er en administrasjonsside som lar administrator se og styre innholdet i diskusjonsforumet på Oslo vaksineklinikk sitt nettsted. Det vil si at denne siden er et brukervennlig publiseringssystem som lar brukeren administrere uten å måtte kunne noen som helst form for programmeringskode. 3.1 Hva er hensikten med programmet? Da dette er en løsning utviklet for en oppdragsgiver uten noen kunnskaper om webprogrammering eller kode, ville en ren programmeringsløsning, som det utviklerene har benyttet seg av, ikke være tilstrekkelig. Denne administrasjonssiden lar brukeren administrere diskusjonsforumet, uten å måtte se datakode. 3.2 Hva gjør programmet? Programmet tar for seg flere funksjoner. Det fungerer som en bakendeløsning for diskusjonsforumet på nettstedet. Administrator kan da uten å kunne programmeringskode, endre, legge til og slette i forumet. Han kan også administrere brukere og ha mulighet til å blokkere disse fra å skrive forumet. I tillegg vil det være mulig å se timehistorikken til de som har bestilt time hos Oslo vaksineklinikk. 5

91 Vedlegg 6 Brukermanual for Administrasjonsside 4. Veiledning for bruk av programmet 4.1 Åpne og aksessere administrasjonssiden Denne rutinen lar deg finne frem til nettstedet og logge inn. 1. Gå til forsiden til Oslo vaksineklinikks nettsted og klikk Logg inn. 2. Du vil da få opp innloggingen likt figur 1 nedenfor. 3. Logg inn med brukernavn og passord. 4. Etter å ha tastet rett brukernavn og passord må du trykke på linken Admin helt nederst på siden til venstre. Figur 1: Logg inn-funksjon med e-post- og passordfelt. 4.2 Prosedyre for administrasjon av diskusjonsforumet Legge til en kategori i diskusjonsforumet Forumet er delt opp i kategorier, emner og meldinger. Kategoriene er det kun administrator som kan opprette, endre og slette. 1. Gå til Diskusjonsforum i venstremenyen og klikk på Kategori som vist i figur Klikk så på Legg til ny kategori under tabellen. 3. Skjemaet som vist i figur 3 vil dukke opp. Så skriver du inn kategorinavnet og en beskrivelse av kategorien hvis det er ønsket. Figur 2: Dropdownmenyen til diskusjonsforum 6

92 Vedlegg 6 Brukermanual for Administrasjonsside 4. Klikk så på Legg til kategori og du vil få en bekreftelse på om den ble lagt til. 5. Gå så tilbake til Kategori og sjekk om den ble lagt til. Figur 3: Skjemaet for å opprette en ny kategori Rediger en kategori i diskusjonsforumet 1. Gå til Diskusjonsforum i venstremenyen og klikk på Kategori som vist tidligere figur For å redigere, klikker du på den kolonnen til den kategorien du vil redigere. 3. Cellene i kolonnen vil da åpne seg slik at du kan endre innholdet i dem som vist i figur Når innholdet er endret, trykker du hvor som helst på siden utenfor tabellen. Cellene vil lukke seg og innholdet blir da lagret. Figur 4: Figuren viser hvordan cellene i tabellen åpner seg slik at man kan redigere i dem. 7

93 Vedlegg 6 Brukermanual for Administrasjonsside Fjerne en kategori i diskusjonsforumet 1. Gå til Diskusjonsforum i venstremenyen og klikk på Kategori. 2. I tabellen helt til høyre er det en rad som det står Slett som vist i figur Finn kolonnen til kategorien du vil slette og trykk på X i denne raden. 4. Det kommer så opp en pop-opp-boks som spør om du er helt sikker på at du vil slette denne kategorien. 5. NB! Alle emner og deres meldinger i kategorien vil også bli slettet. Det er ikke mulig å angre. 6. Trykker du OK vil kategorien bli slettet. 7. Hvis kategorien ikke blir slettet er det fordi den må inneholde minst ett emne og en melding. Legg til et emne i kategorien med tilsvarende melding beskrevet i neste avsnitt og prøv igjen. Figur 5: Dropdownmenyen til diskusjonsforum Figur 6: Viser raden "Slett" for kategoritabellen Legge til et emne i en kategori i diskusjonsforumet 1. Gå til Diskusjonsforum i venstremenyen og klikk på Emne som vist i figur Klikk på Legg til et nytt emne over tabellen. 3. Skriv inn tittel og velg den kategorien du vil legge til emnet i fra rullegardinlista som vist i figur Skriv ønsket melding og trykk på Opprett. 5. Du vil da få opp en bekreftelse på at emnet ble lagt til. Figur 7: Pop-opp-boksen med advarsel om hva som skjer hvis man trykker "OK". Figur 8: Dropdownmenyen til diskusjonsforum 8

94 Vedlegg 6 Brukermanual for Administrasjonsside Rediger et emne i diskusjonsforumet 1. Gå til Diskusjonsforum i venstremenyen og klikk på Emne som vist i tidligere figur For å redigere klikker du på den raden til det emne du vil redigere. 3. Cellene i kolonnen vil da åpne seg slik at du kan endre innholdet i dem som vist i figur 10. Figur 9: Skjemaet for å opprette emne. 4. Når innholdet er endret, trykker du hvor som helst på siden utenfor tabellen. Cellene vil da lukke seg og innholdet blir lagret. Figur 10: Viser hvordan cellene i tabellen åpner seg for redigering Fjerne et emne i diskusjonsforumet 1. Gå til Diskusjonsforum i venstremenyen og klikk på Emne som vist i figur I tabellen helt til høyre er det en rad som det står Slett. 3. Finn kolonnen til emnet du vil slette og trykk på X i raden Slett som vist i figur Det kommer så opp en pop-opp-boks som spør om du er helt sikker på at du vil slette dette emnet som vist i figur 12. Figur 11: Viser raden "Slett". 9

95 Vedlegg 6 Brukermanual for Administrasjonsside NB! Alle meldingene i emnet vil også bli slettet hvis du trykker OK. Det er ikke mulig å angre. 5. Trykker du Ok vil emnet bli slettet. 6. Hvis emnet ikke slettes, er det fordi emnet må minst inneholde en melding. Legg til en melding i forumet og prøv igjen. Dette må gjøres via nettstedet og ikke administrasjonssiden. Figur 12: Pop-opp-boksen som gir advarsel når du trykker "Slett" Redigere en melding i diskusjonsforumet 1. Gå til Diskusjonsforum i venstremenyen og klikk på Melding som vist i figur Velg så kategorien meldingen befinner seg i og trykk Velg som vist i figur Du kommer så til en side for å velge kategoriens emne der meldingen befinner seg i og trykk Velg. Se figur Nå kommer du til en tabell. For å redigere klikker du på den kolonnen til det meldingen du vil redigere. 5. Cellene i kolonnen vil da åpne seg slik at du kan endre innholdet i dem, slik som det er vist i figur Når innholdet er endret, trykker du hvor som helst på siden utenfor tabellen. Cellene vil da lukke seg og innholdet blir lagret. Figur 13: Dropdown-menyen til diskusjonsforum. Figur 14: Valg av kategorien som meldingen befinner seg i. Figur 15: Valg av emnet meldingen befinner seg i. 10

96 Vedlegg 6 Brukermanual for Administrasjonsside Figur 16: Viser hvordan cellene i kolonnen åpner seg for å redigere etter man har trykket på den Fjerne en melding i diskusjonsforumet 1. Følg punkt 1-3 i avsnitt I tabellen helt til høyre er det en rad som det står Slett som vist i figur Finn kolonnen til kategorien du vil slette og trykk på X. 4. Det kommer så opp en pop-opp-boks som spør om du er helt sikker på at du vil slette denne meldingen som vist i figur 18. NB! Trykker du OK vil den bli slettet for godt. Det går ikke an å angre. 5. Trykker du OK vil kategorien bli slettet. Figur 17: Viser raden "Slett" helt til høyre i tabellen Blokkere brukere fra diskusjonsforumet 1. Gå til Brukere i venstremenyen som vist i figur Se etter raden Nivå nest sist til høyre som i figur Finn brukeren du vil blokkere og endre nivået til 3. Dette gjør du ved å følge prosedyren som i avsnitt Figur 18: Pop-opp-boksen som gir advarsel når du trykker "Slett". Figur 19: Brukere i venstremenyen. 4. Brukeren kan nå ikke skrive i forumet, og har kun lesetilgang. Figur 20: Viser hvor raden "Nivå" er. 11

97 Vedlegg 6 Brukermanual for Administrasjonsside 4.3 Prosedyre for administrasjon av brukere Redigere en bruker 1. Gå til Brukere i venstremenyen som vist i figur For å redigere klikker du på den kolonnen til den brukeren du vil redigere. 3. Cellene i kolonnen vil da åpne seg slik at du kan endre innholdet i dem som vist i ffigur 22. Blir Figur 21: Brukere i menyen. kolonnen veldig lang når du trykker på den er det lurt å bruke tabulatortasten for å navigere mellom cellene. 4. Når innholdet er endret, trykker du hvor som helst på siden utenfor tabellen. Cellene vil da lukke seg og innholdet blir lagret. NB! Det kan ikke endres på passordene til brukere. Dette må brukere gjøre selv på sin egen profilside. Figur 21: Viser hvordan cellene åpner seg så man kan redigere Slette en bruker 1. Gå til Brukere i venstremenyen som vist i figur I tabellen helt til høyre er det en rad som det står Slett som vist i figur Finn kolonnen til brukeren du vil slette og trykk på X. 4. Det kommer så opp en pop-opp-boks som spør om du er helt sikker på at du vil slette denne brukeren. NB! Trykker du OK vil den bli slettet for godt. Det går ikke an å angre. 5. Trykker du OK vil brukeren bli slettet. Figur 22: Viser raden "Slett". 12

98 Vedlegg 6 Brukermanual for Administrasjonsside Gjør en vanlig bruker til administrator 1. Gå til Brukere i venstremenyen. 2. Se etter raden Nivå nest sist til høyre som vist i figur Endre nivåtallet til brukeren til 1, ved å følge prosedyren slik som i Brukeren er nå oppgradert til administrator og har full tilgang til administrasjonssiden. Figur 23: Viser raden "Nivå". Figur 24: Hvordan brukertabellen ser ut. 4.4 Prosedyre for timehistorikk Brukere som har booket time(r) hos Oslo vaksineklinikk kan du få sett timehistorikken til. Denne tabellen kan man ikke redigere. Henviser til avsnitt 5 om bookingsystemet for hvordan man kan administrere timer Se timehistorikken til en valgt bruker 1. Klikk på Timehistorikk i venstremenyen som vist i figur En rullegardinliste med brukerens etternavn først vil komme opp som i figur 26. Lista er sortert alfabetisk. 3. Velg brukeren du ønsker å se timehistorikken til i rullegardinlista og trykk på Velg. 4. Brukerens id, navn, e-post, telefonnummer, timedato, start- og sluttid for timen hos Oslo vaksineklinikk vil listes ut i tabellen slik som i figur 27 nedenfor. Figur 25: Viser hvor Timehistorikk er i menyen. Figur 26: Rullegardinlisa hvor man kan velge brukeren man vil se timehistorikken til. 13

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Brukerveiledning. Madison Møbler Nettbutikk

Brukerveiledning. Madison Møbler Nettbutikk Brukerveiledning Madison Møbler Nettbutikk 1 1. Forord 1.1 Produktet Produktet er i denne manualen nettbutikken www.madison-mobler.no. Dette er en nettbutikk som skal gi brukerne mulighet til å handle

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113)

Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren Camilla Kaasi(s188070) Roza Moustafa(s188113) Forprosjektrapport Gruppe 14 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus, våren 2015 Sted: Høgskolen i Oslo og Akershus Dato: 23.01.2015 Tittel: Gruppemedlemmer: Oppgave: Oppdragsgiver:

Detaljer

Brukerveiledning. Madison Møbler Administrasjonsside

Brukerveiledning. Madison Møbler Administrasjonsside Brukerveiledning Madison Møbler Administrasjonsside 1 1. Forord 1.1 Produktet Produktet blir konstruert som et nytt produkt da kunde/bruker ikke har noe eksisterende løsning, derfor er dette den nåværende

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

SiteGen CMS. Innføringsmanual

SiteGen CMS. Innføringsmanual SiteGen CMS Innføringsmanual Copyright Barlind Solutions AS 2008 Hva er SiteGen CMS? SiteGen CMS er et såkalt content-management-system; eller med litt andre ord et publiseringssystem. Det kan brukes til

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON CHARITY DOCTORS KRAVSPESIFIKASJON Hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo våren 2011 Gruppe 13 Muleha Nhonzi Harlem Tambwe Mufoncol Ruban Amuthalingam Page 1 of 6 1 Innledning 1.1 Innledning

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

Systemadministrasjon i KF Infoserie en brukerveiledning for lokale administratorer

Systemadministrasjon i KF Infoserie en brukerveiledning for lokale administratorer Systemadministrasjon i KF Infoserie en brukerveiledning for lokale administratorer Dette er en brukerveiledning til systemadministrasjon i KF Infoserie. Her gjennomgår vi de forskjellige funksjonene som

Detaljer

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus,

Gruppe 44. Bachelorprosjekt ved Institutt for informasjonsteknologi, våren Høgskolen i Oslo og Akershus, Bachelorprosjekt ved Institutt for informasjonsteknologi, våren 2017 Høgskolen i Oslo og Akershus, 19.01.2017 Gruppe 44 Håkon Andre Sylte Garnes, Tobias Hallèn, Gaurab J. Gurung Forprosjektrapport Presentasjon

Detaljer

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 2 - revidert 10.02.2010 AESTON. Side 1

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 2 - revidert 10.02.2010 AESTON. Side 1 Brukerveiledning Kom i gang publiseringsverktøy versjon 2 - revidert 10.02.2010 AESTON Side 1 Velkommen som bruker av Kameleon Introduksjon Kameleon er et publiseringsverktøy (Content Management system

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Gruppe Forprosjekt. Gruppe 15

Gruppe Forprosjekt. Gruppe 15 Forprosjekt Gruppe 15 Marius Ylven Westgaard - s236797 - Anvendt Datateknologi Lise Janbu Eide - s236361 - Dataingeniør Lavanja Jeyenthiran - s236346 - Dataingeniør Kristian Pedersen - s236728 - Anvendt

Detaljer

Bachelorprosjekt i informasjonsteknologi, vår 2017

Bachelorprosjekt i informasjonsteknologi, vår 2017 Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

Detaljer

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS Skjemaer med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 10 Informasjonsteknologi 1 og 2 Skjemaer på nettsider I denne leksjonen skal vi se litt nærmere på bruk av skjemaer på nettsider. Du har sett

Detaljer

HOVEDPROSJEKT I DATA VÅR 2011

HOVEDPROSJEKT I DATA VÅR 2011 PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA

Detaljer

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007.

HOVEDPROSJEKT. Telefon: Telefaks: Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo. 25.mai 2007. PROSJEKT NR. 2007-16 TILGJENGELIGHET Åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL DATO Panther

Detaljer

Forprosjektrapport. Gruppe Januar 2016

Forprosjektrapport. Gruppe Januar 2016 Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning

Detaljer

MedAxess WinMed Brukermanual

MedAxess WinMed Brukermanual MedAxess WinMed Brukermanual Side 1 av 14 1 Innhold 1 INNHOLD... 2 2 VELKOMMEN... 3 2.1 KRAV... 3 2.1.1 Programvare... 3 2.1.2 Helsenett... 3 3 KOMME I GANG MED MEDAXESS... 3 3.1 HVA BESTÅR MEDAXESS AV?...

Detaljer

Vedlegg LMC intranett

Vedlegg LMC intranett Vedlegg LMC intranett H12D02 Jarl-Håvard Holen Ole-Martin Larsen Fredrik Sethne-Andersen André Ritari Vedlegg 1 Resultater av kortsortering. Kortsortering Bruker 1, Salg: Kortsortering Bruker 2, Teknisk:

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

Entobutikk 3.TESTRAPPORT VÅR 2011

Entobutikk 3.TESTRAPPORT VÅR 2011 3.TESTRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne testrapport er skrevet i forbindelse med vårt hovedprosjekt ved Høgskolen i Oslo, ingeniørutdanning, våren 2011. Rapporten beskriver testingen av hele

Detaljer

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet

Produktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode

Detaljer

WordPress. Brukerveiledning. Kjære kunde. Innlogging:

WordPress. Brukerveiledning. Kjære kunde. Innlogging: Brukerveiledning WordPress Sist oppdatert: 26.02.2014 Kjære kunde Her er en liten guide for å hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging - s.1 Kontrollpanel

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Brukermanual Wateachu

Brukermanual Wateachu Brukermanual Wateachu Dette er en kortfattet innføring i Wateachu og de viktigste funksjonene i webapplikasjonen. Wateachu er veldig enkel å bruke og krever lite forklaring på forhånd. Elevenes brukergrensesnitt

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de

Detaljer

Brukerveiledning WordPress. Innlogging:

Brukerveiledning WordPress. Innlogging: Brukerveiledning WordPress Her er en liten guide for hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging Lage en side Lage et innlegg Innlogging: For å logge

Detaljer

Generell brukerveiledning for Elevportalen

Generell brukerveiledning for Elevportalen Generell brukerveiledning for Elevportalen Denne elevportalen er best egnet i nettleseren Internett Explorer. Dersom du opplever kompatibilitets-problemer kan det skyldes at du bruker en annen nettleser.

Detaljer

DinVikar - Bruker Manual

DinVikar - Bruker Manual DinVikar - Bruker Manual Utvikliet av Fosen-Utvikling AS I samarbeid med Alvens AS Skrevet av: Jonas Kirkemyr Innhold 1 Introduksjon................................................... 4 I Systemet 2 Systemet......................................................

Detaljer

Brukermanual For app.minmemoria.no

Brukermanual For app.minmemoria.no Brukermanual For app.minmemoria.no For videomanual: søk etter MinMemoria App på www.youtube.com Velkommen! Memoria er en digital minnebok og en plattform for sosial kommunikasjon mellom familier, helsepersonell

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 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

Detaljer

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg

Forprosjektrapport. Presentasjon. Oslo, den 29. Januar Gorm Eirik Svendsen Nicolai Mellbye Marius Auerdahl Per Gustav Løwenborg Forprosjektrapport Presentasjon Tittel Bakerman AS Website Oppgave Utvikle ett websted for Bakerman AS der hvor de kan promotere seg selv og kommunisere med kundene sine. Periode 4. Januar 2010 til 17.

Detaljer

BRUKERMANUAL. Deviations and Reporting

BRUKERMANUAL. Deviations and Reporting BRUKERMANUAL Deviations and Reporting Forord Dette er brukermanual for CEMAsys Immediate Reporting applikasjon som er laget for iphone og Android telefoner. CEMAsys Immediate Reporting er en applikasjon

Detaljer

Avtale om bruk av autentiseringsløsning Bilag 1b: Brukerveiledning for sluttbrukere av MinID versjon 2.1

Avtale om bruk av autentiseringsløsning Bilag 1b: Brukerveiledning for sluttbrukere av MinID versjon 2.1 Avtale om bruk av autentiseringsløsning Bilag 1b: Brukerveiledning for sluttbrukere av MinID versjon 2.1 Versjon 5. mai 2009 Side 1 av 47 Bruksområde for dette dokumentet: - Å hjelpe innbyggere med å registrere

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

Online booking i Extensor

Online booking i Extensor Online booking i Extensor Når det kommer til online booking har vårt fokus vært på å lage ett system som skal være så enkelt som mulig. Både for de behandlerne som skal forholde seg til det, og kanskje

Detaljer

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 7 - revidert 29.01.2014. Gevir IT Drift AS Webside: www.gevir.no.

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 7 - revidert 29.01.2014. Gevir IT Drift AS Webside: www.gevir.no. Brukerveiledning Kom i gang publiseringsverktøy versjon 7 - revidert 29.01.2014 Gevir IT Drift AS Webside: www.gevir.no Side 1 Velkommen som bruker av Kameleon Introduksjon Kameleon er et publiseringsverktøy

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen.

Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. 1 Sammendrag Dette dokumentet er en produktrapport for vårt avsluttende hovedprosjekt våren 2008 ved høgskolen i Oslo, for ingeniør - avdelingen. Vår oppdragsgiver, ABTF hadde et ønske om en større web

Detaljer

Brukermanual. Itpays W3 Publish. Sette opp, logge inn og komme i gang. Redigert den 23. mai 2005. http://www.itpays.no/produkter/publisering/

Brukermanual. Itpays W3 Publish. Sette opp, logge inn og komme i gang. Redigert den 23. mai 2005. http://www.itpays.no/produkter/publisering/ Brukermanual Itpays W3 Publish Sette opp, logge inn og komme i gang Redigert den 23. mai 2005 http://www.itpays.no/produkter/publisering/ Innholdsoversikt: 1 Generelt om Itpays w3 publish Side 3 2 Sette

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Vedlikeholde nettstedet i Joomla 2.5 +

Vedlikeholde nettstedet i Joomla 2.5 + Vedlikeholde nettstedet i Joomla 2.5 + Innlogging: Klikk deg inn på din nettside. I menyen på ditt nettsted vil det være en link til logg inn eller adm. Klikk på denne og logg inn med det brukernavnet

Detaljer

BRUKERMANUAL FOR NETTINTRO CMS Dette dokumentet er skrevet for Nettintro CMS versjon 1.9.0, og kan derfor avvike noe fra nåværende versjon.

BRUKERMANUAL FOR NETTINTRO CMS Dette dokumentet er skrevet for Nettintro CMS versjon 1.9.0, og kan derfor avvike noe fra nåværende versjon. BRUKERMANUAL FOR NETTINTRO CMS Dette dokumentet er skrevet for Nettintro CMS versjon 1.9.0, og kan derfor avvike noe fra nåværende versjon. Denne brukermanualen vil gi deg en innføring i hvordan man bruker

Detaljer

PBL Barnehageweb. Brukerveiledning

PBL Barnehageweb. Brukerveiledning PBL Barnehageweb Brukerveiledning 1 1. Innledning Gratulerer med valget av nye PBL Barnehageweb! Med PBL Barnehageweb skal det være enkelt å lage en brukervennlig, moderne og profesjonell nettside for

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann

Detaljer

Det er viktig at all informasjon om overnattingsstedet er korrekt utfylt. Klikk på?-ikonene for å få hjelp til felter som ikke er selvforklarende.

Det er viktig at all informasjon om overnattingsstedet er korrekt utfylt. Klikk på?-ikonene for å få hjelp til felter som ikke er selvforklarende. Brukermanual Webside for innlogging: www.easynetbooking.com/login Hjemmeside: Nyttige tips Denne brukermanualen gir en grunnleggende forklaring av systemet. Et nyttig tips for å få detaljert hjelp er å

Detaljer

Næringsregner på PC n versjon 1.1.0

Næringsregner på PC n versjon 1.1.0 Laget av Innhold: Introduksjon 2 Næringsregner på PC n 2 Næringstabell 2 Statistikk 2 Hvem passer programmet for? 2 Bruk av programmet 3 Innlogging av forskjellige brukere 3 Hovedprogramet har 3 felt 4

Detaljer

CharityDoctors. Brukermanuel

CharityDoctors. Brukermanuel CharityDoctors Side 2 1. FORORD Dette er en brukerdokumentasjon som ble skrevet i forbindelse med vår hovedprosjekt ved Høgskolen i Oslo våren 2011. Dokumentet beskriver bruk av Charity Doctors bestilling

Detaljer

BRUKERVEILEDNING TIL MAGNORMOEN INDUSTRIOMRÅDE OG GAUSTADVEGEN INDUSTRIOMRÅDES HJEMMESIDER:

BRUKERVEILEDNING TIL MAGNORMOEN INDUSTRIOMRÅDE OG GAUSTADVEGEN INDUSTRIOMRÅDES HJEMMESIDER: BRUKERVEILEDNING TIL MAGNORMOEN INDUSTRIOMRÅDE OG GAUSTADVEGEN INDUSTRIOMRÅDES HJEMMESIDER: http://www.magnormoen.no/ og http://www.gaustadvegen.no/ Utarbeidet av Solveig Hem Sørli og Arne Sørli Side 1

Detaljer

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

Detaljer

Brukerveiledning for hjemmesider

Brukerveiledning for hjemmesider Hegra Idrettslag Brukerveiledning for hjemmesider En kort innføring for bidragsytere på www.hegrail.no Ivar Friheim 2009-05-18 Innhold Innledning... 3 Nyheter... 3 Sider... 3 Kalenderinnslag... 3 Pålogging...

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA

CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA CabinWeb BRUKERDOKUMENTASJON ET SYSTEM UTVIKLET AV DELFI DATA Sist oppdatert 18.02.2010 INNHOLD INNHOLD... 1 HVA ER CABINWEB... 2 HVA KAN DU BRUKE CABINWEB TIL?... 3 HVA ER NYTT I CABINWEB VERSJON 2.0...

Detaljer

Produktinformasjon WIPS publiseringsløsning

Produktinformasjon WIPS publiseringsløsning Enkel og effektiv publisering på på nett! Produktinformasjon WIPS publiseringsløsning WIPS publiseringsløsninger - Oversikt WIPS Start Standard PRO PRO med intranett Fleksibel forside * * * * 1 stk designmal

Detaljer

Nettside24 Brukerveiledning Nettside24 Brukerveiledning

Nettside24 Brukerveiledning Nettside24 Brukerveiledning Nettside24 Brukerveiledning Nettside24 Brukerveiledning 1 av 14 Oversikt over brukerveiledningen. 2. Oversikt. 3. Logge inn på nettsiden. 4. Redigere innholdet på undersidene. 5. Redigere innholdet i blokkene.

Detaljer

Studentdrevet innovasjon

Studentdrevet innovasjon Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold

Detaljer

Brukerhåndbok CabinWeb Bruker

Brukerhåndbok CabinWeb Bruker Brukerhåndbok CabinWeb Bruker Applikasjon: CabinWeb Laget av: Delfi Data AS (www.delfi.no) Versjon 1.11 Dato 06.11.2006 Historie 1.1 Revisjon utgave 1.11 Lagt til Kartmodul Innledning CabinWeb er et system

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

Side 1. Sniggabo CMS brukermanual rev. 2

Side 1. Sniggabo CMS brukermanual rev. 2 Side 1 Sniggabo CMS brukermanual rev. 2 INNHOLDSFORTEGNELSE Logg inn... 3 Menylinje... 3 Artikkelliste... 4 Ny artikkel... 5 Aktiviteter... 8 Rediger aktivitet... 9 Dokumenter... 9 Nytt dokument... 10

Detaljer

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Hovedprosjekt 2008 av Audun M. Solheim, student HIST/BAIN, audun@c2i.net Oppdragsgiver:Bjørg Minnesjord Solheim, bjorg@midt-svartdal.no

Detaljer

2 Innholdsfortegnelse

2 Innholdsfortegnelse Kravspesifikasjon 1 Forord Kravspesifikasjonen er ment å sees i sammenheng med gruppas forventninger til sitt eget sluttprodukt. Den er altså like mye våre egne krav som krav stilt av arbeidsgiver. Vi

Detaljer

Brukerguide for www.altadykkerklubb.com

Brukerguide for www.altadykkerklubb.com Brukerguide for www.altadykkerklubb.com Utgitt første gang: 27/09-07 Sist oppdatert: 23/03-09 1 Innledning Dette er den nye siden til Alta Dykkerklubb! Den er blitt laget over et system som gjør det mulig

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey

Mamut Open Services. Mamut Kunnskapsserie. Kom i gang med Mamut Online Survey Mamut Open Services Mamut Kunnskapsserie Kom i gang med Mamut Online Survey Kom i gang med Mamut Online Survey Innhold MAMUT ONLINE SURVEY... 1 KOM I GANG MED MAMUT ONLINE SURVEY... 3 MAMUT-BRUKERE: OPPRETT

Detaljer

Kravspesifikasjon Gruppe nr ABTF

Kravspesifikasjon Gruppe nr ABTF 1 Presentasjon Tittel: Web-løsning for ABTF Utvikle en Web-løsning helt fra bunnen av, samt med en Oppgave: plattform som gir underviseren muligheten til å veilede og følge opp sine elever gjennom kurset.

Detaljer

Retningslinjer for etwinning-verktøy

Retningslinjer for etwinning-verktøy Retningslinjer for etwinning-verktøy Registrer deg til etwinning Første trinn: opplysninger om registrator Andre trinn: samarbeidspreferanser Tredje trinn: opplysninger om skolen Fjerde trinn: skolens

Detaljer

TESTRAPPORT - PRODSYS

TESTRAPPORT - PRODSYS TESTRAPPORT - PRODSYS PRODSYS-DATASYSTEM FOR ÅS PRODUKSJONSLAB AS GRUPPE 12 CHRISTOPHER CONRADI STEFFEN DIEDRICHSEN ROMAN KOVALENKO INFORMASJONSTEKNOLOGI, INGENIØRUTDANNINGEN, HØYSKOLEN I OSLO 1. FORORD

Detaljer

Brukerdokumentasjon... 2. 1.1 Logg inn... 2. 1.2 Ny bruker... 3. 1.3 Hovedmeny... 6. 1.4 Oppdrag... 8. 1.4.1 Oppdragsgiver... 8

Brukerdokumentasjon... 2. 1.1 Logg inn... 2. 1.2 Ny bruker... 3. 1.3 Hovedmeny... 6. 1.4 Oppdrag... 8. 1.4.1 Oppdragsgiver... 8 Innhold Brukerdokumentasjon... 2 1.1 Logg inn... 2 1.2 Ny bruker... 3 1.3 Hovedmeny... 6 1.4 Oppdrag... 8 1.4.1 Oppdragsgiver... 8 1.4.2 Opprett oppdrag... 9 1.4.3 Slett oppdrag... 19 1.4.4 Hjelper...

Detaljer

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish.

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish. Brukermanual - Joomla Bonefish brukermanual - Joomla Gratulerer med ny nettside fra Bonefish. Du er nå blitt eier og administrator for din egen nettside, noe som gir deg visse forpliktelser ovenfor din

Detaljer

Brukermanual. www.bygdekvinnelaget.no

Brukermanual. www.bygdekvinnelaget.no Brukermanual www.bygdekvinnelaget.no Viktige endringer Nye Bygdekvinnelaget.no er lagt opp på en måte der brukere og redaktører står for innhold, mens systemet i enda større grad en tidligere står for

Detaljer

infotorg Enkel brukermanual

infotorg Enkel brukermanual infotorg Enkel brukermanual Innhold Innledning... 3 Logg inn... 3 Feilmelding... 3 Sperret bruker / Glemt passord... 4 Bytt passord... 5 Innstillinger og oppstartsregister... 5 Søk og Svar... 6 Velg tjeneste/register...

Detaljer

Publiseringsløsning for internettsider

Publiseringsløsning for internettsider Publiseringsløsning for internettsider Hva er Edit? Edit er et verktøy for publisering og vedlikehold av nettsider. Tidligere har det å vedlikeholde en nettside vært en tungvinn prosess, men nå kan alle

Detaljer

Veiledning til Grønt Flagg søknadsportal

Veiledning til Grønt Flagg søknadsportal Veiledning til Grønt Flagg søknadsportal Registrering av bruker: Registrer deg som bruker i FEE Norway sin søknadsportal fra http://soknad.fee.no. Dette må gjøres for å få tilsendt brukernavn og passord,

Detaljer

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING

RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING RUTEPLANLEGGINGSSYSTEM BRUKERVEILEDNING Prosjekt 18 Jørgen Mobekk Sørensen Morten Evje Tor Andreas Baakind Anders Gabrielsen Side 1 1 FORORD Dette dokumentet er brukerveiledningen, og skal være en veiledning

Detaljer

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016 Forprosjektrapport Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016 1.0 Presentasjon 2.0 Sammendrag 3.0 Dagens situasjon 4.0 Mål og rammebetingelser 5.0 Løsninger/alternativer 6.0 Analyse

Detaljer

Så hva er affiliate markedsføring?

Så hva er affiliate markedsføring? Så hva er affiliate markedsføring? Affiliate markedsføring er en internettbasert markedsføring hvor Altshop belønner deg for hver kunde som du rekrutterer til Altshop. Vi vil ta godt hånd om dem for deg

Detaljer

IST Skole Vurdering - Foresatt

IST Skole Vurdering - Foresatt IST Skole Vurdering - Foresatt Velkommen til en ny skole! IST tar nå steget fra kun å levere programvare til å forenkle og utvikle alle skolens funksjoner. Våre løsninger tar hånd om prosessene fra den

Detaljer

DIFI VEILEDNING I BRUK AV AVANT WEBVERKTØY FOR MEDARBEIDERUNDERSØKELSER I STATLIG SEKTOR

DIFI VEILEDNING I BRUK AV AVANT WEBVERKTØY FOR MEDARBEIDERUNDERSØKELSER I STATLIG SEKTOR DIFI VEILEDNING I BRUK AV AVANT WEBVERKTØY FOR MEDARBEIDERUNDERSØKELSER I STATLIG SEKTOR Innhold 1. Innlogging i systemet... 3 2. Forsiden av portalen... 3 3. Redigere spørreskjema... 4 3.1 Spørsmål skal

Detaljer