Online Mannskapsbørs

Størrelse: px
Begynne med side:

Download "Online Mannskapsbørs"

Transkript

1 Gruppe 28 Hovedprosjekt 2011 Online Mannskapsbørs Gaute Kramvik Kristoffer Upsahl Lars Martin Kjos

2 2

3 PROSJEKT NR TILGJENGELIGHET Åpen Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Nadacore Sailing Galore DATO 31. mai 2011 ANTALL SIDER / BILAG 106 PROSJEKTDELTAKERE Gaute Kramvik Kristoffer Upsahl Lars Martin Kjos INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Kongelig norsk seilforening - KNS KONTAKTPERSON Per Bøymo SAMMENDRAG Denne oppgaven er en utviklingsoppgave, hvor det har blitt laget en mannskapsbørs på nett. Oppgradet ble gitt av Kongelig Norsk Seilforening, og gruppemedlemmene går har gått på bachelorstudiet Anvendt Datateknologi. Mannskapsbørsen ligger på domenet og inneholder all funksjonalitet som trengs for at seilere skal kunne finne sammen, og delta i regattaer i regi av KNS. 3 STIKKORD Mannskapsbørs KNS Regatta 3

4 4

5 Forord Dette er et prosjekt som ikke var forhåndsdefinert som et oppgaveforslag, og det vi sto dermed mye friere en hva mange andre grupper gjorde i selve utviklingsprosessen. Det var denne gruppen som tok kontakt med arbeidsgiveren, og vi vil gjerne få takke Kongelig Norsk Seilforening som takket ja til forespørselen vår om å få jobbe for dem. De har gjennom hele denne prossesen vært klar på at vi som gruppe fikk kjøre vårt eget løp, og kom kun med enkelte krav innledningsvis, krav som vi som utviklingsgruppe ikke hadde noen problemer med å stille oss bak. Vi vil også få takke vår veileder, Kirsten Ribu, for viktig støtte og veiledning underveis. 5

6 6

7 Innholdsfortegnelse 1. Innledning Oppgavedefinisjon Oppdragsgiver Gruppen Bakgrunn Teori Kost Nettsiden Drift Nytte Kravspesifikasjonen Funksjonelle Krav Ikke-funksjonelle Usability Begrensinger Framgangsmåte, planlegging og metode Systemutviklingsmetode Roller Sprint Verktøy Ulemper ved NadaSCRUM Utstyr Hardware Software Resultater Prototyping Testing A/B Resultat fra A/B Eyetracker Testpanel Scenario Optimalisering av databasen

8 6. Evaluering Sammenligning Dagens løsning Ny løsning Tilbakemelding Brukeres tilbakemelding Oppdragsgivers tilbakemelding Konklusjon Arbeidsverktøy IRC Prosjektdagbok docs.google.com Videre arbeid Teknisk spesifikasjon Database og tabelloversikt LAMP MySQL PHP Database Databasestruktur Fremmednøkler Tabeller Grensesnitt og kodeforklaring Kodestandard Sikkerhet Pålitelighet, robusthet og ytelse Include Grensenitt Forside index.php Top.php Regattaoversikt.php Venstremeny Mine båter Slett båt Mine påmeldinger og mine forespørsler Meldinger Meldingsfunksjon Use cases

9 9. Brukerveiledning Betingelser Funksjonalitet Registrering Hovedsiden Registrere en båt Din båt Registrere båten din for regatta Registrere deg som mannskap Finne og melde deg på en regatta Sende meldinger Administrasjonsfunksjoner Brukeradministrasjon Opprette ny regatta Redigere regatta Båtoversikt Vedlegg UML-diagram Ordliste Eksempel på kildekode minbat.php - En viktig del av mannskapsbørsen Risikoanalyse Kilder Nett Lærebøker

10 10

11 1. Innledning Denne rapporten består av to hoveddeler, hvorav del 1 er hoveddelen av rapporten, og del 2 er brukerveiledningen. 1.1 Oppgavedefinisjon Dette er en utviklingsoppgave, og vi skal lage en fullverdig mannskapsbørs for Kongelig Norsk Seilforening. Mannskapsbørsen skal ligge på domenet og utfylle alle krav spesifisert i kravspesifikasjonen. En mannskapsbørs har vi valgt å definere som et sted seilere kan møtes for å finne båter å seile på. 1.2 Oppdragsgiver Oppdragsgiveren for dette hovedprosjektet har vært Kongelig Norsk Seilforening, heretter skrevet KNS. KNS ble stiftet i 1883, og er landets suverent største seilforening, med over 4000 medlemmer. De er også størst på regattaarrangementer i Norge, og har ansvaret for å arrangere norgesmesterskap for en rekke båttyper. KNS har i dag outsourcet drift av IT-avdeling til firmaet Intility AS, men har en person som står som IT-ansvarlig internt, og til web bruker de Idiums plattform. Prosjektet og domenet, med alle dets rettigheter, blir overgitt til KNS 1. juni

12 1.3 Gruppen Denne oppgaven har blitt til gjennom et samarbeid mellom tre studenter; Kristoffer Upsahl, Lars Martin Kjos og Gaute Kramvik. Vi går alle på Anvendt Datateknologi ved høyskolen i Oslo, og har arbeidet sammen på flere mindre prosjekter tidligere. 2. Bakgrunn Per dags dato er det om lag 100 registrerte seilforeninger i Norge, og mange av dem har egne mannskapsbørser. Flesteparten av disse er veldig enkle bulletin boards eller forum, og mangler all den funksjonaliteten mannskapsbors.com kan stille med. Det er dermed ingen sider som direkte kan sammenlignes med dette prosjektet, utenom rent konseptuelt. For typiske eksempler på hvordan dagens løsninger ser ut, kan vi ta en titt på dagens mannskapsbørs i bruk på kns.no, og en tematisk lignende fra Grandfjord Seilforening. Dagens mannskapsbørs på kns.no 12

13 Mannskapsbørs for Gandsfjord Seilforening Dette er også sider som ikke har noen form for varig registrering av personalia, eller personlige meldinger, så all informasjon, det være seg telefonnummer eller adresser, ligger i klartekst for alle som måtte være interessert i å lese dette. Med mannskapsbørsen skal brukerne få muligheten til å registrere seg som mannskap og/eller båteier, og komme i kontakt med mannskap eller båt å seile med. Mannskapsbørsen skal sammen med informasjon om regattaer i regi av KNS, gi oversikt over båteiere som mangler mannskap og mannskap som mangler båt slik at disse på en enkel måte kan komme i kontakt. 2.1 Teori Til dette prosjektet har vi benyttet oss mye av XHTML, php, databaseoppbygging, MySQL og javascript til selve utviklingen. Her har vi måttet sette oss inn i mange ukjente funksjoner og muligheter. Dette gjelder særlig på programmeringsbiten i PHP og javascript. Med grunnlaget i programmering fra faget web-prosjekt, web- 13

14 programmering og operativsystemer hadde vi noen solide knagger å henge ny lærdom på. Vi måtte også lese oss opp på databaser og databasestruktur. Til selve prosjektplanleggingen og prosjektstyringen har vi vært gjennom teori fra faget økonomi og ledelse og systemutvikling. Av systemutvikling har vi også lært å lage use-case diagrammer og UML-modeller. Gruppen har også måttet sette seg noe inn i interaksjonen mellom seilforeningen og deres medlemmer, samt hvordan planlegging og utføring av regatta og påmelding til disse fungerer. Dette for å bedre forstå brukermassens forutsetninger og behov fra en mannskapsbørs. 2.2 Kost Nettsiden Det er veldig lite direkte kostnader knyttet til drift av prosjektet. Domenet er registrert hos one.com, opprettelsesavgiften er på 100 kroner, årlig domeneavgift er på 100 kroner, og leien av webhotell er per dags dato 10 kroner i måneden. Denne leien inkluderer 3GB lagringsplass, og om KNS på et senere tidspunkt trenger mer lagringsplass, vil en dobling av leien til 20 kroner per måned gi dem 10GB lagringsplass. Mengden lagringsplass kan også utvides videre om behovet for dette skulle oppstå. Opprettelseskostnad: Årlig domeneavgift: Leie av webhotell: Sum: 100 kroner 100 kroner 120 kroner 320 kroner Vi ser altså at selve nettsiden har en førsteårskostnad på 320 kroner, og en årlig kostnad på 220 kroner etter dette. Vi kan ta høyde for at KNS ønsker mer lagringsplass etter hvert, så om man anslår at de etter to år velger å oppgradere til 10GB lagringsplass på webhotellet, vil vi få følgende utgiftstabell: 14

15 År Utgift Kostnad 1 Opprettelse 100 kroner 1 Domeneavgift 100 kroner 1 Leie 120 kroner 2 Domeneavgift 100 kroner 2 Leie 120 kroner 3 Domeneavgift 100 kroner 3 Leie 240 kroner 4 Domeneavgift 100 kroner 4 Leie 240 kroner 5 Domeneavgift 100 kroner 5 Leie 240 kroner Sum 1560 kroner Dette er et omtrentlig anslag av kostnadene, men det finnes en del potensielle variasjoner. Dagens domene er registrert som.com, og om KNS ønsker å registrere mannskapsbørsen som et.no-domene, blir det nye 100 kroner i oppstartsavgifter, pluss 115 kroner i årsavgift. Leie av web-hotell er den samme uansett hvilken type domene det er snakk om Drift Det er veldig vanskelig å anslå hva drift av mannskapsbors.com kommer til å koste, hvis vi skal måle i timepris til IT-ansvarlig x antall timer brukt på nettstedet. Det vil ikke bli ansatt ekstra personell for å drifte siden, så når prosjektet er overlevert er det KNS sin IT-ansvarlig som vil inneha ansvaret for drift av siden. Dette er en oppgave som på sikt er planlagt å overføre til frivillige arbeidere Nytte Mannskapsbørsen vi lager gir ikke en direkte gevinst i kroner og øre, noe som gjør det vanskelig å måle en konkret nytteeffekt. Det vi vet er at det er et stort behov for en slik tjeneste blant seilforeningens medlemmer. Vi vet også at KNS får en del henvendelser på epost og telefon som omhandler nettopp hjelp til å finne mannskap 15

16 eller båt å seile med. Arbeidet med dette er en direkte kostnad for seilforeningens ansatte i form av tid. Og alt dette arbeidet kan gjøres ved hjelp av egeninnsats og det rette hjelpemiddelet. I tillegg til å lette dette arbeidet, vil mannskapsbørsen forhåpentligvis utvide seilforeningens tjenester og øke medlemmenes tilfredshet. 16

17 3. Kravspesifikasjonen Mannskapsbors.com skal være en webportal for seilere som ønsker å komme i kontakt med andre seilere, og har dermed en rekke behov som må imøtekommes for at målgruppen skal være interessert i å benytte seg av den. Først og fremst må den være en klar forbedring i forhold til dagens løsning, slik at besøkene på vil benytte seg av plattformen vi tilbyr. Deretter må løsningen være brukervennlig nok til at brukermassen ikke støter på startproblemer når presentert for den nye løsningen. Registrering Prosjektet vårt skal ligge på nett, under domenet mannskapsbors.com. Siden skal være en portal, hvor brukere må registrere seg for å få tilgang til systemet. Registrering skal foregå gjennom epost, og brukere må opprette et passord når de registrerer seg. Brukervennlighet og universell utforming Nettsiden skal være universell utformet med tanke på fargevalg, og koden skal være tilpasset svaksynte lesere med tanke på tekstlesere ala Jaws. Funksjonalitet Krav for funksjonalitet har vi valgt å dele inn i funksjonelle og ikke-funksjonelle krav. 3.1 Funksjonelle Krav Brukere må kunne registrere seg som båteier og/eller mannskap. Brukere må kunne registrere seg som mannskap for å komme i kontakt med båteiere, båteiere må kunne registrere seg som båteier for å komme i kontakt med mannskap. En båteier kan også være mannskap på en annen båt og motsatt. 17

18 Brukere må kunne registrere båten sin Brukere som har registrert seg på mannskapsbørsen må kunne registrere båt(er) for å komme i kontakt med mannskap Oversikt over båter med ledige plasser. Mannskapsbørsen må ha oversikt over båter som mangler mannskap å seile med. Oversikt over mannskap som ønsker å være med og seile. Mannskapsbørsen må ha oversikt over mannskap som mangler båt, men ønsker å seile. Oversikt over regattaer. Mannskapsbørsen må ha oversikt over regattaer som båteiere og mannskap kan seile på. Brukere kan kunne sende private meldinger til hverandre Mannskapsbørsen må gi brukere mulighet til å kommunisere med hverandre i form av private meldinger. Administrasjonsverktøy for administrator Mannskapsbørsen må kunne administreres i en egen administrasjonsmeny som kun er tilgjengelig for administrator. Brukere skal kunne lage egne profiler for båter og mannskap. Brukere må kunne lagre informasjon om seg selv og sin(e) båt(er). Denne informasjonen skal være tilgjengelig for andre brukere i form av en profilside. Brukerprofilene må inneholde muligheter for å vise informasjon om: Navn Bilde Bosted Erfaring Generell info 18

19 Båtprofilene må inneholde muligheter for å vise informasjon om: Modell Fot Seilnummer Skipper Forening Bilde Regattaer båten deltar i 3.2 Ikke-funksjonelle Nettsiden skal fungere og oppleves likt i alle nyere nettlesere. Nettsiden skal fungere i alle nyere nettlesere. Siden skal også oppleves så likt som mulig i alle nyere nettlesere. Grensesnittet skal være universelt utformet Mannskapsbørsen skal kunne brukes av alle slags brukere, også brukere med eventuelle funksjonsnedsettelser. Database Databasen skal være MySQL5. Administrering All funksjonalitet skal være web-basert, og all administrasjon av siden skal være mulig å gjøre på nett. Det skal være en egen admin-side, hvor admin skal kunne opprette og slette regattaer, samt endre eller slette bruker. Det skal også være muligheter for å slette profilbilder til mannskap eller båter. Sikkerhet Alle passord skal være hashede, og sensitiv informasjon skal aldri sendes i klartekst. Selve databasen skal beskyttes for SQL-injection i alle ledd. Det skal også 19

20 være funksjonalitet for å endre passord, eller få et nytt passord sendt på epost om det eksisterende har blitt glemt. 3.3 Usability Oppdragsgiver har hele tiden vært veldig klar på at gruppen fikk stå fritt til å utføre oppdraget på det vis vi selv ønsket, innenfor de rammer vi i felleskap hadde blitt enige om. Under det første møtet vårt, ble det klart at de hadde få funksjonelle eller visuelle krav til oppgaven, kun krav i forhold til brukervennlighet og usability. Mange i målgruppen vår er ikke å regne som eksperter i bruk av webapplikasjoner, så det var et overordnet mål at ferdig produkt skulle være så enkelt som mulig i bruk. Det må også følge med en inngående tutorial over de aktuelle funksjonene, dette for at det skal være så lett som mulig, for nye brukere å sette seg inn i systemet. Det var også et krav fra KNS sin side at vedlikehold og administrering skulle være så enkelt som mulig, og da gjennom en standard nettleser framfor egen programvare. 3.4 Begrensinger Man kan ikke melde seg på regattaer som KNS, og det er viktig å påpeke at man på ingen måte fysisk og tellende er påmeldt KNS sine regattaer, selv om man er påmeldt via siden vår. Deltakelse i regattaer koster som regel penger, og påmeldingsinformasjon finnes som lenker i regattainformasjonen på alle sidene. Det foreligger heller ikke en engelsk utgave av siden, all den tid dette ville ha medført for mye arbeid. Begge begrensningspunktene våre er gode forslag for framtidlig arbeid, og bør implementeres ved en senere anledning. 20

21 4. Framgangsmåte, planlegging og metode Etter at gruppen tok kontakt med Per Bøymo i KNS, tok det bare et par dager før vi inngikk en muntlig avtale om prosjektet, og fastsatte et tidspunkt for et planleggingsmøte. Før dette møtet lagde gruppen en presentasjon om hva vi så for oss at vi kunne lage for dem, og stilte så med et førsteutkast til kravspesifikasjon for produktet. Hele prosjektet var på dette tidspunktet veldig åpent, og vi ønsket at KNS skulle komme med innspill, ønsker og krav om hva de forventet fra vår side. I løpet av det første møtet ble gruppen, i samarbeid med representant fra KNS, enige om hvilken løsning som skulle leveres, og hva slags funksjonalitet denne skulle ha. KNS hadde muligheten til å revidere kravspesifikasjonen, og la til et par punkter vi ikke hadde tenkt på da vi skisserte løsningen for første gang. Det ble også diskutert rundt hvordan prosessen og kommunikasjonen mellom KNS og gruppen vår skulle finne sted, og vi ble enige om at kontakt skulle opprettholdes gjennom Gaute, som representant for Nadacore. Vi ble også enige om at etter at avtalekontrakten var signert, skulle gruppen styre seg selv fram til leveranse. Målet var å kunne stille med en betaversjon av produktet vårt 1. mai, for deretter ha en måned til å utføre eventuelle endringer fram til endelig leveranse av ferdig produkt, 31. mai. Etter første mai skulle KNS stille med personell for en testgruppe, og dermed ha innspill på hvordan selve testingsprosessen foregikk. 21

22 4.1 Systemutviklingsmetode Under gjennomføringen av dette prosjektet har vi benyttet vår egenutviklede Scrum-variant; døpt NadaSCRUM. Gruppens medlemmer har jobbet sammen på en rekke prosjekter og oppgaver siden begynnelsen av studiet, og har etter hvert utviklet en særegen arbeidsmetodikk vi har utbedret og tatt med oss gjennom studiet. NadaSCRUM er en agil metode, som i hovedtrekk er en forenklet og nedstrippet utgave av scrum. Gruppen består av 3 medlemmer, og det er Gaute som fungerer som Scrum master, mens Kristoffer og Lars Martin utgjør resten av laget. Selv om vi på papiret opererer med ulike roller, har vi en veldig kollektivistisk arbeidsmetode, hvor rollene flyter veldig over i hverandre. NadaSCRUM er iterasjonsbasert, og tid til disposisjon blir delt inn i sprinter, hvor innholdet blir hentet fra produktets backlog. Lengden på hver sprint kan variere med mengden arbeid som skal utføres i løpet av gjeldende periode, og varierer fra et par dager, til 2 uker. Dette er mye kortere sprinter enn vanlig Scrum, men det er lengder som med tiden har blitt tilpasset vårt arbeidsmønster. Et gjennomgangstrekk ved vår metode, er bruken av kollektive bestemmelser når stilt ovenfor en utfordring. Gruppen favoriserer å jobbe med felles problemer som en enhet, og har derfor valgt å samles i grupperom eller hjemme hos et gruppemedlem, som regel Gaute, for å jobbe samlet. Vi har hatt en svært liten grad av individuell arbeidsmengde, og arbeid blir kryssjekket av andre medlemmer ved utgangen av hver sprint Roller Scrum master har hatt en veldig nedtonet rolle i forhold til standard metode, og har kun hatt et overordnet ansvar for oppsett og vedlikehold av Scrumtavle, samt ledelse av møter. Under vår daglige Scrum har master teknisk sett et lederansvar, men i NadaSCRUM er det forventet at gruppen kommer fram til løsninger som et kollektiv. Det er masteren som har ansvar for å sette opp sprinter, men lengden og hva de skal inneholde, blir fastsatt i felleskap. 22

23 Teamet, hvor scrum master også er med, opptrer som en selvstyrende enhet. Hvert medlem har individuelle oppgaver som skal utføres i løpet av sprinten, men disse oppgavene blir løst i felleskap av gruppen, og står dermed solidarisk ansvarlig for levert arbeid. Produkteier har vært nesten fraværende i selve arbeidsprosessen. Det har kun vært et fåtall møter hvor produkteier har stilt med representanter, noe som var helt i tråd med hva som ble avtalt ved inngangen til prosjektet. Føringene for prosjektet ble fastsatt før selve arbeidet ble iverksatt, og gruppen har stått fritt til å kunne styre seg selv innenfor de fastsatte rammene Sprint Hver sprint kan variere i lengde, men startes hver gang med et planleggingsmøte. I dette møtet blir målet for sprinten satt, og for de gangene målet er en bestemt funksjonalitet, lager et bestemt antall stories som skal gjennomføres av personas for at et ønsket utfall skal oppnås. Målene blir satt av gruppen som kollektiv, og ved sprintens ende måles resultatet opp mot kravet som ble satt i begynnelsen. Dette er mål som ikke kan endres under sprintens varighet, og om de ikke blir utført i henhold til planen, må dette tas til etterretning når neste sprint skal planlegges Verktøy Høyskolen i Oslo har en notorisk mangel på ledige grupperom. Det har derfor vært vanskelig å finne et fast tilholdssted, og vi har dermed operert med et virtuelt verktøy for å kunne jobbe på ønsket måte. Vi kjøpte ved prosjektets begynnelse en egen underside på og har dermed hatt lett tilgang til tavle og backlog uavhengig av fysisk lokalitet Ulemper ved NadaSCRUM Selv om NadaSCRUM er en arbeidsmetode som passer vår gruppe veldig godt, har den en rekke ulemper med tanke på om den skulle ha blitt overført til en større scene. Det største og mest åpenbare problemet med vår metode, er at den langt i fra passer for alle. Arbeidsmetoden krever en veldig spesifikk gruppedynamikk som kan være vanskelig å innføre på kort varsel, og da særlig i større grupper hvor medlemmer ikke er kjent fra før av. Kollektivistisk arbeidsmetodikk krever at medlemmene er godt kjent med hverandres sterke og svake sider, og dermed 23

24 sømløst kan tilpasse arbeidsoppgaver til hva som skal gjøres og hvem som kan gjøre hva. 4.2 Utstyr Hardware Gjennom dette prosjektet har vi i all hovedsak jobbet med og på våre private datamaskiner. Fra skolen sin side har vi fått bruke en eye-tracker, lokalisert i Høyskolens interaksjonslaboratorium. Denne har vært benyttet til testingsformål for å kartlegge hvordan brukere som ikke hadde besøkt siden før ville reagere på plassering av informasjon Software Som studenter har vi vært begrenset til å bruke programvare som enten er gitt gratis av skolen, eller er tilgjengelig gratis på nett. Siden et gruppemedlem bruker Linux, har vi også prøvd å holde oss på et nivå hvor mesteparten av programvaren vår er open source. MySQL Workbench For design av databasen brukte vi MySQL Workbench 5.2, og har vært veldig fornøyd med dette. For behandling på nett har vi brukt phpmyadmin. Tobii-Studio Høyskolens maskin tilkoblet eye-trackeren kom med programmet Tobii-Studio installert, og som eneste tilgjengelige program på en maskin uten studentrettigheter, var det dette vi måtte bruke. Programmet var lett å sette seg inn i, og selv om det til tider var litt for krevende for maskinen det var installert på, fikk vi utført nesten alle tester uten problemer. Vi støtte på enkelte begrensninger da maskinen kun hadde Internet Explorer 7 installert, Tobii-Studio fungerer ikke optimalt med Firefox, og ingen hadde rettigheter til å oppgradere Internet Explorer. Dia v0.97 For å lage UML-diagrammer, benyttet vi oss av programmet Dia. Det er et program som til tider ble opplevd som ustabilt, men er veldig lite ressurskrevende og lett å jobbe med. Programmet har et veldig snevert utvalg av implementert 24

25 funksjonalitet, men siden det dekker alle våre behov når det kommer til diagramkonstruksjon. Editorer Gruppemedlemmene har forskjellige preferanser på hvilken editor som brukes, og vi har gjennom dette prosjektet brukt Aptana, gedit, Notepad++ og Coda, gjerne om hverandre. MediaWiki For journalføring i løpet av produksjonsprosessen har vi benyttet oss av MediaWiki, som ble opprettet på prosjekthjemmesiden vår. Operativsystemer Samtlige gruppemedlemmer bruker hvert sitt operativsystem, noe som har ført til at programvaren vår har måtte være tilgjengelig til alle plattformer. Kristoffer: Windows 7. Lars Martin: Mac OSX, Snow Leopard Gaute: CrunchBang Linux. Cloud Vi har benyttet oss av flere nettbasert programvare igjennom dette prosjektet, hovedsaklig Scrumy og DropBox. Scrumy er betalingsvare, og koster $7 per måned for Pro-versjon, mens vi har klart oss med gratisversjonen av DropBox. Prosjektets dokumenter har blitt skrevet i sin helhet i Google Docs, og redigert i Microsoft Word. 25

26 5. Resultater Når vi skrev kravspesifikasjonen satt vi oss to mål. For det første måtte den dekke de funksjonelle og ikke funksjonelle kravene til en tenkt mannskapsbørs. Siden det ikke fantes noen direkte konkurrerende løsning, måtte vi definere disse kravene ut fra egne preferanser og i samarbeid med KNS. Mål nummer to med kravspesifikasjonen var at denne måtte definere krav som vi med vår bakgrunn og utdanning hadde praktisk mulighet til å løse. Vi mener vi har løst oppgaven slik den er definert i kravspesifikasjon. Mannskapsbørsen dekker de behovene som vi i samarbeid med KNS har identifisert. Alle de funksjonelle så vel som de ikke-funksjonelle kravene er oppfylt, med noen små justeringer underveis. 5.1 Prototyping Prototyping på papir I løpet av utviklingsprosessen vår har prototyping hatt en sentral rolle, og har vært et viktig element i alle faser av prosjektet. Fra begynnelsen av prosjektet ble det 26

27 prototypet på papir, hvor modeller, designforslag og funksjonalitet ble klekket ut og tegnet ned. Prototyper blir fortløpende vurdert, og det vi anså som vellykket, ble med videre til neste prototype. Dette er en form for evolusjonær prototyping som vi har god erfaring med fra tidligere prosjekter, og det er også en arbeidsform som passer godt inn i den samarbeidsformen vi hadde med KNS. Fra KNS sin side hadde vi svært få føringer og fastsatte rammer for prosjektet, og vi sto dermed fritt til å kunne sette sammen et vidt spekter av ulike typer løsninger, før vi kom fram til den rette modellen vi valgte å gå videre med. Planleggingsmodell 27

28 5.2 Testing A/B Ønsker man å unngå uenighet i gruppen om hvordan noe skal sees ut, fungerer en A/B-test veldig godt som bestemmelsesmiddel. Testen går veldig enkelt ut på å sette to ulike versjoner av noe opp mot hverandre, og la en uavhengig gruppe velge. Vi har valgt å benytte denne metoden til testing av prototyper også, i stedet for å velge mellom statiske skjermbilder. På denne måten kunne vi få umiddelbar tilbakemelding angående funksjonalitet vi ønsket å teste ut, og fikk også testet ut hva som fungerte kontra hva som ikke fungerte. For vår del har vi valgt å benytte oss av studentmassen på HiO når tester skulle gjennomføres, og da har det rett og slett blitt benyttet klassisk innkastingsteknikk for å skaffe deltakere Resultat fra A/B Mannskapsbørsen vår hadde helt til siste test-sesjon to ulike funksjoner for kommunikasjon brukere i mellom. Vi hadde sidens egen meldingsfunksjon, samt muligheten til å sende epost til den adressen brukere var registrert på. Begge funksjonene var representert ved egne knapper, og tilbakemeldingen vi fikk var at det var unødvendig med epostfunksjonalitet når det allerede forelå en meldingstjeneste som fungerte tilfredsstillende. Brukernes e-postadresse og telefonnummer ligger uansett tilgjengelig på profilsiden, og dersom brukerne trenger å komme i direkte kontakt med hverandre kan dette dermed gjøres helt utenom mannskapsbørsen Eyetracker Vi har benyttet oss av en eye-tracker for deler av testingen, og målet med dette har vært å analysere hvordan brukere navigerte på siden vår. Tesen vår var at det ville være mulig å finne ut om linkene våre og informasjonen i de ulike informasjonsboksene sto på best mulig måte, målt etter hvor mye tid brukeren brukte for å finne fram til den informasjonen eller funksjonen han eller hun var ute etter. 28

29 Måten vi testet dette på, var å sette opp ulike scenarier, og så bruke programmet Tobii-Studio til å gjøre opptak og analyse av hendelsesforløpet. Dermed kunne vi lage et nøyaktig gazeplot eller heatmap over testbrukerens øyebevegelser Testpanel Testingen foregikk på interaksjonslaboratoriet så vi fikk derfor studenter ved høyskolen til å stille som testpersoner. Hver testsesjon varte ikke i mer enn 15 minutter, og belønning til testerne ble enten Twist, eller sjokoladekake bakt av Kristoffers mamma. Vi hadde test-sesjoner over to ulike dager, så det var umulig for oss å bruke det samme panelet hver gang Scenario Vårt første scenario var at en allerede innlogget bruker skulle registrere båten sin for en bestemt regatta. Testbruker 1 Her ser vi at testpersonen begynner ved overskriften, registrerer linknavn øverst, og deretter leser hva som står på knappene i informasjonsboksen i midten. Overskriftene i de to underboksene blir også registrert, men siden de var tomme for 29

30 denne brukeren, var det ikke så mye mer å se på. Testpersonen går så rett til menyen, og leser seg nedover til hun kommer til rett link, og trykker så på denne. Testbruker 2 I test nummer 2 ser vi at testpersonen leser gjennom all informasjon på siden. Han begynner med overskriften, fortsetter med topplenker, leser så igjennom all tekst og lenketekst i hovedinformasjonsvinduet i midten, og går til slutt igjennom lenkene og finner det riktige alternativet. Testbruker 3 30

31 Testbruker 3 hoppet rett til hovedinformasjonsvinduet, og skumleser seg nedover og igjennom linkene inne i rammen. Underboksene blir sett over, men ikke finlest, og blikket hoppet rett til menyen, hvor det ikke tar lang tid før rett link blir oppdaget og trykket på. Samleoversikt over testbruker 1, 2 og 3 Samlet sett så ser vi at tendensen er klar; testbrukere begynner oppe i venstre hjørne, og jobber seg systematisk gjennom sidene. Tendensen er at brukere leser fra venstre mot høyere, men hopper litt fram og tilbake inn i mellom. Vi ser at mesteparten av tiden gikk med på å lese igjennom menyen, noe som også var intensjonen med layouten. 31

32 Heatmap med bruker 1, 2 og 3 Som vi ser ut i fra heatmapet, ligger hovedtyngden på venstre side av siden. Informasjonen ellers på siden blir gjennomgått, om en ikke så grundig, og vi ser igjen at fokuset til brukeren ligger der vi ønsker det skal ligge. Vi hadde også tester som involverte leting i regattaoversikten, men der støtte vi på problemer med maskinen eye-trackeren var koblet til. Tobii-Studio fungerte ikke tilfredsstillende med Internet Explorer 7, og det var umulig å få oppgradert til nyeste versjon, og vi har dermed ikke fått screenshot av bilder hvor scrolling hadde blitt tatt i bruk. Dette medfører at sider, som for eksempel, regattaoversikten, ikke har blitt med i selve analysen. Noe som selvfølgelig er synd, all den tid dette kunne ha vært interessant informasjon å studere. 5.3 Optimalisering av databasen Vi optimaliserte tiden spørringer til databasen tar ved å indeksere de viktigste feltene i tabellene. Eksempel: I brukertabellen er det lagt til indeks på epost, så databasen har til enhver tid epostadressene sortert alfabetisk. Uten dette hadde databasen gått gjennom alle epostadressene helt til den fant den riktige hver gang en bruker logger inn 32

33 6. Evaluering Først og fremst er dette en klar kursendring fra eksisterende løsning. I dag fungerer ikke mannskapsbørsen til KNS som ønsket, og de som jobber i KNS må i dag bruke tid på å selv ta kontakt med seilere i miljøet som de vet har ledig plass på båter, eller mangler båt å seile på. Dette er selvfølgelig en ekstrabelastning på tilgjengelige ressurser, og en ekstra unødvendig sådan når det allerede foreligger en løsning som skal ta for seg besøkende på kns.no som ønsker å benytte seg av en mannskapsbørs. Seilforeningen sitter i dag med en løsning som ikke fungerer godt nok. På den ene siden er det en enkel løsning, som ikke koster nevneverdig å vedlikeholde eller å drifte. På den andre siden fungerer den svært dårlig, og verken seilforeningen eller mannskapsbørsens brukere syns den tilfredsstiller deres behov. Det er også et poeng at KNS er Norges største seilforening, med flest medlemmer, flest båter og flest regattaer i egen regi, og bør derfor også være den første som setter sammen en velfungerende mannskapsbørs. Det viktigste for foreningens del, rent bortsett fra at løsningen vi leverer faktisk fungerer, er at medlemmene deres faktisk ønsker å benytte seg av nettsiden, noe de i liten grad gjør i dag. Vi mener at vår løsning et er stort steg i riktig retning, og vi tror at dette er en løsning som brukermassen kommer til å bli godt fornøyd med, særlig når vi sammenligner med den løsningen som blir erstattet. 6.1 Sammenligning En teknisk sammenligning mellom mannskapsbors.com og dagens mannskapsbørs på kns.no er ikke enkelt, all den tid de to ulike systemene er veldig ulike Dagens løsning Hovedfordelen med dagens løsning er at den er veldig kjapp. Man trenger ikke å registrere seg noen steder for å poste innlegg, og det er veldig uformelt og uforpliktende. Et standard board, som dagens løsning er, er også lett å komme i gang med for en førstegangsbruker, med veldig få valgmuligheter brukeren kan rote 33

34 seg bort i. Det er også lett å administrere, hvor den eneste oppgaven administrator har er å slette spam, eller endre/slette gamle innlegg. Det er også en rekke ulemper med dagens system. Det er for det første vanskelig å skille de ulike brukerne fra hverandre. Det er ingen registrering, så alle kan velge å representere seg selv ved eget navn, kallenavn, båtnavn, epost, telefonnummer eller hva man måtte ønske. Dette fører til at det ikke finnes en rød tråd med tanke på hvordan brukerne framstår, og det kan dermed oppleves forvirrende med tanke på hvem man egentlig skriver til. Det er heller ikke noe avgrensning i kategorier, og det er ofte brukere som legger innlegg om helt andre ting midt i en tråd hvor en person leter etter mannskap. Det er også utstrakt bruk av kidnapping av tråder, hvor et multiplum av brukere poster egne telefonnummer og informasjon i andres tråder. Dette er nok ikke ondskapsfullt ment, men det er ofte vanskelig for brukere å finne ut om de svarer andre brukere, lager en egen tråd eller hvem de egentlig svarer. Vi ser også at alt av epostadresser og telefonnummer ligger usensurert på nett, og kan lett bli sniffet opp av spambots. 34

35 En tråd på dagens mannskapsbørs Ny løsning. Den største ulempen er at siden vår representerer et hopp i tilkrevd kunnskapsnivå for å kunne bruke siden. Fra vår side er det lagt opp til at den siden skal være så enkel og intuitiv som over hodet mulig, men det er uansett et sprang fra dagens løsning. 35

36 Det vil også være en distinkt mangel på brukere i begynnelsen. Vi vet at det er et stort behov for løsningen vår, men det kan godt tenkes at terskelen for å registrere seg heves, når brukere ser at det er få medlemmer fra før av. Dette er et problem vi ser kan slå ut negativt for oss, så det blir møtt ved å sende ut informasjonsepost gjennom seilforeningens medlemsregister om informasjon om hva som har blitt gjort. Dagens brukere av mannskapsbørsen blir også kontaktet og gjort oppmerksom på den nye siden. Dette gjør vi fordi at de brukerne som allerede benytter dagens løsning, vil være mest positiv til å prøve ut ny løsning. 6.2 Tilbakemelding Brukeres tilbakemelding. Brukeres tilbakemeldinger har variert gjennom hele prosjektet. Vi har jobbet aktivt med evolusjonær prototyping, og har alltid endret funksjonalitet og brukergrensesnitt med utgangspunkt i de tilbakemeldinger vi har fått fra testpaneler. Etter at produktet ble ferdigstilt, har vi ikke fått testet det opp mot nye brukere. 1 juni vil mannskapsbors.com gå live, og etter dette vil det bli lettere å få tilbakemelding fra et stort antall unike førstegangsbrukere. Vi kommer til å fungere som support ut året, og vil også være forpliktet til å utføre eventuelle endringer hvis tilbakemeldingen viser at vi har glemt enkelte punkter som senere viser seg å inneha stor nytteverdi, eller hvis implementert funksjonalitet viser seg å være overflødig eller feilkonstruert Oppdragsgivers tilbakemelding. Gruppen har, som tidligere nevnt, fått veldig frie tøyler fra oppdragsgiver. Etter å ha laget et forslag til funksjonalitet, hadde vi et møte med Per Bøymo i KNS. I møtet kom han med forslag og innvendinger, og vi ble enige om hvordan mannskapsbørsen skulle være. Det ble også enighet om at vi skulle ha en betaversjon klar til 1. mai, som vi kunne presentere for oppdragsgiver, slik at de kunne komme med eventuelle innvendinger. Møtet ble avholdt den 3. mai. KNS stilte med 2 representanter som ble presentert for løsningen så langt samt våre tanker om videre utvikling. Vi fikk mange ærlige 36

37 tilbakemeldinger, og følte at det var et nyttig møte. Følgende er tilbakemeldinger fra KNS. Opprette FAQ og tutorial-side Det må sendes meldinger/varsler til brukere med informasjon om påmeldinger og forespørsler. Rydde i og skjule overflødige menyer. Endre til mer logiske navn på lenker, menyer og headere. Mulighet til å søke i brukere for å gjøre disse til administrator. Sørge for at brukere som er påmeldt en båt for beskjed dersom båten blir slettet. Fjerne/skjule regattaer som er avsluttet. Tilbakemeldingene fra KNS ble skrevet ned under møtet og arbeidet med disse ble startet allerede samme dag. Noen av tilbakemeldingene gikk på ting vi allerede hadde planlagt, men ikke rukket å gjennomføre til møtet, mens andre tilbakemeldinger gikk på ting vi ikke hadde tenkt på i det hele tatt. Møtet var således veldig nyttig for både oss og for oppdragsgiver. Siden prosjektet ikke var et oppdrag skissert av KNS, og det var vi selv som kom til KNS med idéen, kunne tilbakemeldingene deres også betraktes som tilbakemeldinger fra brukergruppen så vel som fra oppdragsgiver. KNS har hele veien gitt råd og veiledning i forhold til våre forslag, og har latt oss utforme siden ut fra vår kravspesifikasjon, med de endringene de har ønsket. 37

38 7. Konklusjon Dette har vært en unik erfaring for oss, og det har vært første gangen for mye av det vi har gjort. Selve gruppedynamikken og interne prosesser var allerede innarbeidet før selve prosjektarbeidet ble påbegynt, men vi fikk likevel anledning til å tilpasse enkelte rutiner for dette prosjektet, siden størrelsen og omfanget var noe mer omfattende en hva vi var vant med fra før av. Selve ferdigstillingen av rapporten har, som vanlig, blitt preget av en distinkt mangel på tid. Dette er på mange måter et signaturtrekk for gruppen, og vi hevder selv at dette kun et er uttrykk for at vi jobber best under press, herunder tidspress. Det ferdige prosjektet har vi etter hvert blitt godt fornøyd med. Vi synes selv at vi har gjennomført oppdraget godt i henhold til kravspesifikasjonen vi ble enige om i begynnelsen av prosjektet, kun med et par mindre endringer underveis som prosjektet skred fram. Vi ser fram til at mannskapsbørsen vår blir kjent i seilmiljøet, og håper at den kan føre til at flere blir med på regattaer hvor de tidligere kanskje ikke hadde blitt med. Resultatet fra brukertest og møte med KNS taler også for at oppdraget har blitt gjennomført på en tilfredsstillende måte. Kravspesifikasjonen har blitt til gjennom et samarbeid mellom gruppen og seilforeningens representant, som også var tilstede da løsningen ble presentert. Utover små justeringer i ettertid av siste møte med KNS, samt noe fjerning av unødvendig/overflødige menyer og funksjoner, har mannskapsbørsen blitt levert slik både gruppen og seilforeningen ønsket. Siden gruppen har jobbet sammen på lignende, dog mindre prosjekter tidligere, var vi godt kjent med hverandre og felles arbeidsmetodikk. Vi har stort sett vært enige om alle viktige beslutninger, og alle føler at de har blitt hørt. Men det finnes alltid rom for forbedring. Og gruppen som til tross for at vi har godt kjent med frister og krav, har sluttfasen av prosjektet vært preget av noe mangel på tid. Dette er gode erfaringer vi må fortsette å arbeide med, og ta med oss videre. 38

39 7.1 Arbeidsverktøy IRC For kommunikasjon internt i gruppen hvor ett gruppemedlem ikke var til stede, har vi i all hovedsak benyttet oss av protokollen IRC. Dette er et verktøy vi har benyttet oss av i gjennom samtlige prosjekter vi har vært involvert i, og har for oss blitt et naturlig tillegg til arbeidsprosessene Prosjektdagbok Helt i begynnelsen av prosjektet etablerte vi en egen prosjektwiki med MediaWiki, og intensjonen var å holde denne oppdatert med endringer og nyvinninger, og benytte den som prosjektdagbok med oversikt over generell prosjektprogresjon. Wikien kommer med veldig omfattende installasjons- og oppsettsdokumentasjon, og var veldig enkel å sette opp, selv med sine mange konfigurasjonsmuligheter. Selv om en wiki åpenbart kan være et godt hjelpemiddel, har det vært veldig lite brukt i løpet av dette prosjektet. Hovedsaklig er dette fordi vi mener vi får lite ut av arbeidet med en wiki sammenlignet med arbeidsmengde som må legges inn i den for at resultatet skal kunne være brukbart til noe konstruktivt docs.google.com Prosjektet har blitt skrevet i et fellesdokument, delt på Google Docs. Alle gruppemedlemmer har tilgang til felles dokumenter, og editerer de samme dokumentene samtidig. Det eneste vi har å utsette på google docs er mangelen på syntax-highlighting for kode, noe som hadde ført til at vi kunne ha brukt det til nesten absolutt alt. 39

40 7.2 Videre arbeid Prosjektet blir overlevert 1. juni, og det vil holdes et møte med KNS mandag 6. juni, hvor vi vil gi opplæring i bruk av administrasjonsverktøy, generell forklaring av kodeoppbygning, gjennomgang av brukermanual og overrekkelse av domenet. Vi har også en skriftlig avtale om å stille opp som support ut året, noe som hovedsaklig innebærer å utføre eventuelle endringer i struktur eller funksjonalitet. Vi kommer ikke til å opptre som moderatorer på siden, og all administrering vil utføres av personell hos KNS. 40

41 8. Teknisk spesifikasjon Mannskapsbors.com kan enkelt sett forklares som et todelt system. I bunnen ligger databasen, hvor all informasjon lagres og systematiseres. Over denne ligger grensesnittet, som sørger for enkel tilgang til innholdet i databasen. Begge delene ligger på et webhotell hostet av one.com, og er tilgjengelig på nett med hvilken som helst nettleser. For å forklare systemets oppbygning og funksjonalitet, har vi satt opp en trepunkts dokumentasjonsmodell for systemet i helhet. Dette har vi gjort med tanke på at leseren lettest mulig skal kunne oppnå en tilstrekkelig grad av systemforståelse til å kunne forstå og administrere systemet, foreta endringer i koden for å endre grensesnitt eller legge til/slette funksjonalitet. Dokumentasjonsstandard 1. Database og tabelloversikt Hvordan databasen er bygd opp. 2. Grensesnitt og kodeforklaring Generell oversikt over koden. 3.UML-diagram og use cases. Use cases for alle essensielle funksjoner 8.1. Database og tabelloversikt Masse bilder av grensesnittet, og forklaringer til disse, eller bare tekst? Kanskje vi skal ha screenshots av hva som skjer under use-cases? LAMP LAMP er et akronym og står i vårt tilfelle for operativsystemet Linux, webserveren Apache, databaseadministrasjonssystemet MySQL og scriptspråket PHP. Andre skriptspråk som Perl eller Python kan også inngå i LAMP. Denne samlingen av open source programvare benyttes ofte sammen for å drive websider og servere. 41

42 Disse programmene er svært populære siden de er gratis og kan brukes av alle Linux distribusjoner. Dette var utgangspunktet vårt da vi begynte å se oss om etter et sted å hoste Mannskapsbørsen. Valget falt på one.com, hovedsaklig på grunn av prisen. De var billigere enn konkurrentene. Den eneste ulempen er at MySQL-databasen deres ikke støtter databasemotoren InnoDB, som er nødvendig for å kunne bruke fremmednøkler i tabellene. Dette ble løst ved å passe på at koden vår tar hensyn til at mange av primærnøklene også finnes som fremmednøkler i andre tabeller. Eksempel: Hvis en båt slettes, sjekkes det først om det er noen påmeldte brukere, og til hvilke regattaer den er påmeldt. Deretter slettes det i rekkefølgen: påmeldte brukere, påmeldte regattaer og til slutt båt. Påmeldte brukere lagres i et array som brukes til å sende dem en melding om at båten ikke lenger finnes i databasen. Webserveren hos one.com kjører Apache på en Linux server MySQL one.com tilbyr også en MySQL-database som vi har valgt å bruke. For å administrere databasen benyttes open source verktøyet phpmyadmin, et webbasert administrasjonsverktøy for MySQL-databaser laget i PHP. Ved å logge inn på dbadmin.one.com kan man enkelt endre databasen uten å måtte installere egne programmer først. Dette gjør det enkelt for KNS ansatte å endre ting i databasen om det skulle være behov for det. Databasen er MySQL versjon a PHP Mannskapsbørsen er for det meste kodet i PHP og HTML. Ved hjelp av PHP-kode hentes informasjon fra databasen som vises på siden i HTML. one.com bruker PHP versjon

43 8.2 Database Databaseoversikt Databasestruktur Databasen består av 13 tabeller laget i databasehåndteringssystemet MySQL. I bildet over vises en oversikt over tabellene med navn på alle feltene. Alle tabellene har en unik id som primærnøkkel. I mange tabeller har vi også valgt å gjøre noen felter unike, som for eksempel i bruker-tabellen der samme epostadresse ikke kan brukes av flere brukere Fremmednøkler I mange av tabellene er feltene primærnøkler fra andre tabeller. Siden one.com ikke støtter fremmednøkler har vi ikke kunnet lagre det i databasen. Vi har derimot valgt å navngi alle fremmednøkler med navn fra tabellen de er hentet fra. I tabellen baat er feltet bruker_id henter fra tabellen bruker. 43

44 Med støtte for fremmednøkler blir du hindret fra å slette felter som også brukes i andre tabeller. I vårt tilfelle ville det hindret oss fra å slette brukere som har registrert en båt. Båten må slettes før brukeren. Siden databasen ikke tar hensyn til dette måtte vi tenkte på dette da vi skrev koden Tabeller De fleste tabellene våre er bygd opp på samme måte, med en id som er primærnøkkel, noen fremmednøkler(i de fleste tilfeller bruker_id, baat_id og regatta_id) og til slutt noen felter som er unike for den enkelte tabell. Vi har valgt ut noen tabeller som trenger nærmere forklaring for å kunne forstås. Tabellen mannskap inneholder mannskap og hvilke regattaer de vil delta i, mens regattaregistrering har oversikt over hvilke båter som deltar i hvilke regattaer og hvor mange ledige plasser det er ombord. Disse tabellene brukes i regatta.php for å gi en oversikt over tilgjengelige båter og mannskap. Når bruker finner en båt/mannskap han vil invitere velger han send forespørsel og det blir lagt til en ny linje i tabellen bruker_soker_baat. Tabellen inneholder søknader fra mannskap om å delta på en båt i en bestemt regatta. Når en bruker søker om å delta på en båt settes feltet ok_mannskap = 1, og når båteier godtar forespørselen settes ok_eier = 1. Da er mannskapet påmeldt til den båten og vises i båtoversikten til båteier. Hvis båteier svarer nei på forespørselen settes ok_eier = 2 og søknaden regnes som avslått. Vi hadde også en tabell for båter som søkte mannskap, men fant ut at vi kunne slå sammen tabellen med bruker_soker_baat. Når en båteier sender en forespørsel til mannskap settes ok_eier = 1 og siden ok_mannskap = 0 vet vi at det er båteier som har sendt forespørselen. Resten er likt som i eksemplet over. 44

45 Tabellene turseilas og turseilas_paameldinger fungerer på samme måte som henholdsvis mannskap og bruker_soker_baat. turseilas er for de som vil seile utenom regattaer. 8.3 Grensesnitt og kodeforklaring. Systemet består av en MySQL-server, hvor informasjon skrives og hentes med PHP5, og serveren er versjon a-24+lenny5-log. JavaScript Kodestandard Mannskapsbors.com har kode skrevet i MySQL5, PHP5, HTML og JavaScript, og all kode følger W3Cs standarder. Kommentarer til koden i PHP er skrevet inn ved bruk av dobbel slash (//) for enkeltlinjer, eller slash stjerne (/* utkommentert */) for flere linjer Sikkerhet Det viktigste sikkerhetstiltaket er gjennomgående beskyttelse mot SQL-injection. Det har vi gjort ved å implementere beskyttelse i kildekoden hver eneste gang vi skriver informasjon til databasen ved bruk at et input-felt. // Beskyttelse mot MySQL injection $brukernavn = stripslashes($brukernavn); $passord = stripslashes($passord); $brukernavn = mysql_real_escape_string($brukernavn); $passord = mysql_real_escape_string($passord); Vi har også gjennomgående bruk av sessions for å unngå at sider kan bli vist av brukere som ikke har registrert seg, og har laget en logginsjekk for å sende de som ikke har logget seg inn med registrert bruker til forsiden, hvor de kan enten logge inn eller registrere seg som bruker. 45

46 <?php include "top.php"; include "include/connect.php"; if (!$_SESSION["loggetInn"]) { include "logginnsjekk.php"; } else (...) Backup er et sikkerhetsmoment vi slipper å ta oss av, siden one.com tar backup av sine servere hver dag, og vi er dermed sikret fra leverandøren sin side. Hvis vi klarer å gjøre uopprettelig skade på koden, eller inntrenger klarer å utnytte et smutthull og dermed kompromittere koden, vil vi dermed kunne få opprettet alt arbeidet til et tidspunkt før skaden inntraff. Vi vil også få en detaljert oversikt over hva som gikk galt, slik at det kan unngås neste gang. Virus og spam blir også tatt ansvar for av one.com, og det er et ferdiginstallert filter for bruk av webmail Pålitelighet, robusthet og ytelse Pålitelighet er et moment som er svært viktig for både oss og oppdragsgiver. Besøkende skal oppleve siden som robust og med rask responstid, og dette er hovedsakelig et moment som må tas hånd om i databasen. Vi har derfor tatt høyde for at den må kunne skalere med et voksende antall brukere. Under stresstestingen av databasen ble det antatt et svært høyt antall samtidige brukere, og vi så at mannskapsbørsen fungerte som forventet selv med høy belastning. Vi har også hatt testpaneler som har prøvd ut de ulike aspektene ved implementert funksjonalitet, og rensket bort de feilmeldinger og bugs som var i koden. Hvis lansert produkt blir preget av stadige feilmeldinger og dårlig affordance, er dette elementer som vil føre til at brukeren sitter igjen med en følelse av utilstrekkelighet fra vår side, som utviklere av systemet. 46

47 8.3.4 Include Include-mappen er en mappe som inneholder php-filer som blir inkludert og brukt i flere av sidene på mannskapsbørsen. Eksempler på dette er connect.php og disconnect.php som blir inkludert i alle filer som skal snakke med databasen. Disse filene tar seg av opp- og nedkobling til databasen. Include brukes for å unngå å måtte skrive den samme kodesnutten gang på gang i mange forskjellige filer og det gjør kodingen mer effektiv og oversiktlig. En annen stor fordel med include er at man for eksempel kan legge menyer og funksjoner inn i egne filer og inkludere disse der man ønsker. På den måten slipper man å gjøre om alle undersidene som tilhører nettstedet om man skal gjøre endringer i disse. Connect-utf8.php gjør det samme som connect.php (kobler seg til databasen), men denne definerer at kommunikasjonen skal foregå med utf8-tegnsett, dette fordi javascript-biblioteket jquery brukt i noen filer krever at dette blir satt. Function-filene inneholder kodesnutter til funksjoner som blir brukt i flere av sidene på mannskapsbørsen. Når disse blir inkludert i de filene hvor funksjonen blir brukt, kan man gjøre et kall på funksjonen fremfor å skrive hele koden på nytt. Funksjonene våre har relativt selvforklarende navn. function.ifie.php setter et eget stilark til gamle versjoner av Internet Explorer, som ikke støtter nye funksjoner i CSS. Function.lastopp.php er en funksjon som tar seg av opplasting av bilde. Function.meldinger.php tar seg av meldingssystemet på mannskapsbørsen. Functions.navn.php inneholder flere funksjoner for å hente båtnavn, brukernavn eller regattanavn fra databasen når vi kun er kjent med en unik identifikator for disse. Inc.glemtPassord.php og Inc.resetGlemtPassord brukes når brukere skal få nullstilt/laget nytt passord. Logginnsjekk.php brukes i alle filene på mannskapsbørsen, dersom man ikke er logget inn på siden, blir denne inkludert. Den ber brukeren om å logge seg inn for å se den forespurte siden. Loggut.php sletter loggetinn-session, og fjerner brukeren fra påloggede brukere-tabellen (som administratorene har tilgang til). Når loggetinn-session slettes må man logge seg inn for å få tilgang til mannskapsbørsen. 47

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

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

Innstallasjon og oppsett av Wordpress

Innstallasjon og oppsett av Wordpress Del 1 - Installasjon og oppsett Innstallasjon og oppsett av Wordpress Wordpress har blitt en veldig populær publiseringsplattform for websider. Uten særlige tekniske ferdigheter kan man sette opp profesjonelle

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

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

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

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

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

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

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

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

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

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

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

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

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

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 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

4.5 Kravspesifikasjon

4.5 Kravspesifikasjon 4.5 Kravspesifikasjon 4.5.1 Funksjonalitet og systembeskrivelse Webapplikasjonen har tre overordnede funksjoner; Opprett Spotify arrangement, Opprett SoundCloud arrangement og Bli med på arrangement. Brukere(kalt

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

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

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

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

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

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

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

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

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

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

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

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

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

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23

Prosessrapport. Utvikling av moduler til CMS for bonefish.no. Gruppe 08-23 Utvikling av moduler til CMS for bonefish.no Gruppe 08-23 Prosessrapport for hovedprosjektet utvikling av moduler til CMS for bonefish.no ved Høgskolen i Oslo, avdeling for Ingeniørutdanning våren 2008.

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

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

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

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

Brukerveiledning for nedlastning og installasjon av Office 2013. Av Roar Nubdal, fagprøve IKT-servicefag, juni 2014

Brukerveiledning for nedlastning og installasjon av Office 2013. Av Roar Nubdal, fagprøve IKT-servicefag, juni 2014 Brukerveiledning for nedlastning og installasjon av Office 2013 Av Roar Nubdal, fagprøve IKT-servicefag, juni 2014 1 Innhold Brukerveiledning for nedlastning og installasjon av Office 2013... 1 Info...

Detaljer

ThinkPage CMS 2.0. Hurtigveiledning. Av ThinkPage AS

ThinkPage CMS 2.0. Hurtigveiledning. Av ThinkPage AS ThinkPage CMS 2.0 Hurtigveiledning Av ThinkPage AS ThinkPage CMS 2 Forord Dette er en midlertidig brukerveiledning tar for seg de viktigste basisfunksjonene i ThinkPage CMS og gir brukeren nødvendig innføring

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

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive,

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive, 1. Last ned og installer XAMPP. 2. Sjekk at alt fungerer. 3. MySQL. Vi begynner med databaseserveren, MySQL. Gå til DOS klarmelding eller ledetekst (finnes under tilbehør på startmenyen om du ikke som

Detaljer

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

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

F O R P RO S J E K T R A P P O R T

F O R P RO S J E K T R A P P O R T A V D E L I N G F O R I N G E N I Ø R U T D A N N I N G F O R P RO S J E K T R A P P O R T Dato for levering: 01.02.2008 Versjon Nr. 1,72 Gruppe: 08-18 Webside: http://student.iu.hio.no/~s135462/hovedprosjekt/

Detaljer

Brukerdokumentasjon for LabOra portal - forfattere

Brukerdokumentasjon for LabOra portal - forfattere Brukerdokumentasjon for LabOra portal - forfattere Skin: Dnnbest-Grey-Skin1024 Skin: Metro7 Custom LabOra web-portal er et web-basert publiseringsprogram for publisering av informasjon på hjemmesider.

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

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

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

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

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

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

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

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

Tjenestebeskrivelse Webhotelltjenester

Tjenestebeskrivelse Webhotelltjenester Tjenestebeskrivelse Webhotelltjenester Sist endret: 2004-12-01 Innholdsfortegnelse 1 INTRODUKSJON... 3 1.1 GENERELT... 3 1.2 NYTTEVERDI WEBHOTELLTJENESTER FRA TELENOR... 3 2 FUNKSJONALITET... 4 2.1 INNHOLD

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

Forprosjektrapport. Høgskolen i Oslo Våren 2007-02-02. Dr.Klikk. Gruppe 25. Håkon Drange s130167 Lars Hetland s127681

Forprosjektrapport. Høgskolen i Oslo Våren 2007-02-02. Dr.Klikk. Gruppe 25. Håkon Drange s130167 Lars Hetland s127681 Forprosjektrapport Høgskolen i Oslo Våren 2007-02-02 Dr.Klikk Gruppe 25 Håkon Drange s130167 Lars Hetland s127681 Innholdsfortegnelse PRESENTASJON... 2 SAMMENDRAG... 2 OM BEDRIFTEN... 2 DAGENS SITUASJON...

Detaljer

Kjøre Wordpress på OSX

Kjøre Wordpress på OSX Kjøre Wordpress på OSX Alt etter hva du ønsker å bruke Webserveren til er det flere måter å gjøre dette på. Ønsker du kun en side som skal dele sider du lager manuelt, med PHP, GD etc eller med server

Detaljer

WEBUTVIKLING OBLIG 4. Installasjon

WEBUTVIKLING OBLIG 4. Installasjon WEBUTVIKLING OBLIG 4 Installasjon 1. Jeg lastet ned MAMP gratis fra www.mamp.info og installerte på maskinen. Trykker så på Start Server og ser at det fungerer når Apache Server og MySQL Server lyser grønt.

Detaljer

Styringsdokumenter. Forord

Styringsdokumenter. Forord 8 Styringsdokumenter Forord Dette er en samling av samtlige styringsdokumenter gjennom hele prosjektperioden. Styringsdokumentene er satt opp i rekkefølge i forhold til leveringsfrister Dokumentene ble

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

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

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

WordPress startguide

WordPress startguide WordPress startguide INNLEDNING... 2 BLOGGINNLEGG... 3 HVORDAN LEGGE TIL ET BLOGGINNLEGG:... 4 UNDERSIDER... 5 HVORDAN LAGE EN NY SIDE... 6 LAST OPP BILDER/VIDEO... 7 KOMMENTARER PÅ INNLEGG... 8 UTSEENDE...

Detaljer

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

HOVEDPROSJEKT. Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. 2008-18 Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Åpen HOVEDPROSJEKT Telefon: 22 45 32 00 Telefaks: 22 45 32 05

Detaljer

Analyse av Web- medier, Lenker. Oppgaven jeg her skal presentere har tatt utgangspunkter et gruppearbeid vi fikk utlevert. Dette lyder som følgende :

Analyse av Web- medier, Lenker. Oppgaven jeg her skal presentere har tatt utgangspunkter et gruppearbeid vi fikk utlevert. Dette lyder som følgende : Arbeidskrav 2- Atle Remi Olsen Analyse av Web- medier, Lenker. Kapittel 1- Innledning. Oppgaven jeg her skal presentere har tatt utgangspunkter et gruppearbeid vi fikk utlevert. Dette lyder som følgende

Detaljer

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS GRUPPE 15 Kenneth Ådalen Vegard Gulbrandsen Kien Trung Nguyen Dataingeniørutdanningen, Høgskolen i Oslo Våren 2009 2 S i d e FORORD I dette dokumentet tar

Detaljer

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

Detaljer

Informasjonsportalen

Informasjonsportalen Brukermanual Informasjonsportalen Aksjeservice versjon 2.0 Aksjeservice AS Kolbergveien 20 3121 Tønsberg / Munkedamsveien 68 0270 Oslo Forord Aksjeservice er en løsningsleverandør for ikke-børsnoterte

Detaljer

Windows eller Linux. i MinButikk

Windows eller Linux. i MinButikk Windows eller Linux i MinButikk Windows eller Linux Scenario Jeg har startet matbutikken MinButikk og er medlem av ToppKjeden Kjeden har ingen krav til personalsystem så jeg kan fritt velge system selv.

Detaljer

Brukerdokumentasjon for Installatør i bruk av. Elektronisk behandling av rettemeldinger

Brukerdokumentasjon for Installatør i bruk av. Elektronisk behandling av rettemeldinger Brukerdokumentasjon for Installatør i bruk av Elektronisk behandling av rettemeldinger Versjon 1.10 04.09.13 Side 1 av 18 Innholdsfortegnelse INNHOLDSFORTEGNELSE... 2 BRUKERDOKUMENTASJON FOR ELEKTRONISK

Detaljer

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Prosessrapport Prosjekt nr. 2007-11 SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen Prosjekt nr. 2007-11 Prosessrapport Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen, s130182 Espen Skaarer, s123590 Dato: 25.mai 2007 Antall sider: 11 Intern veileder: Kjetil

Detaljer

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

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

Brukermanual for nettpublisering. frivilligsentral.no

Brukermanual for nettpublisering. frivilligsentral.no Brukermanual for nettpublisering frivilligsentral.no Innholdsfortegnelse Introduksjon 3 1 - Innlogging 4 1.1 - Logge inn 4 1.1 - Logge ut 4 2 - Grensesnitt 5 2.1 - Menyfelt 5 2.2-3 - Opprette, lagre og

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

Få din egen hjemmeside

Få din egen hjemmeside I dette avsnittet lærer du å bygge din egen hjemmeside legge til tekst og bilder lage din egen design legge en bakgrunn på hjemmesiden I neste nummer får du hjelp til å bygge en større hjemmeside til en

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

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON... 03 VEDLEGG 2

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

https://nhh.itslearning.com/

https://nhh.itslearning.com/ e-læringssystemet https://nhh.itslearning.com/ Sist oppdatert 08.09.2009 10:07 1 1. Hva er It s Learning? It's Learning er et e-læringssystem hvor du finner elektronisk informasjon om alle våre kurs/studier,

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

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

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Kom i gang. Nå er det enklere en noensinne å redigere hjemmesiden din med Plone CMS. 17. mars 2010

Kom i gang. Nå er det enklere en noensinne å redigere hjemmesiden din med Plone CMS. 17. mars 2010 Kom i gang Nå er det enklere en noensinne å redigere hjemmesiden din med Plone CMS. 17. mars 2010 Innholdsfortegnelse Introduksjon til Bedrift Online 4 Web-basert publiseringsverktøy 4 Hva du trenger 4

Detaljer

WWW.POLARPRODUKSJON.NO

WWW.POLARPRODUKSJON.NO GUIDE RSHL.NO Av Fredrik Mediå Oppgraderingen av nettstedet RSHL.NO har ført til at det kan oppstå en del spørsmål og forvirringer rundt hvordan forskjellige elementer fungerer. Denne guiden skal fungere

Detaljer

Kravspesifikasjon. Vedlegg A

Kravspesifikasjon. Vedlegg A Vedlegg A Kravspesifikasjon Dette dokumentet beskriver krav til applikasjonen som skal designes i prosjektet Nettverksbasert applikasjonsovervåking. Det beskrives her både krav til selve applikasjonen

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

Brukerhåndbok for drift hos Kirkedata AS. Denne håndboken er utarbeidet av

Brukerhåndbok for drift hos Kirkedata AS. Denne håndboken er utarbeidet av Brukerhåndbok for drift hos Kirkedata AS Denne håndboken er utarbeidet av Oppdatert: 18. desember 2012 Innhold Innhold Innledning... 3 Oppsett av PC... 3 Windows XP... 3 Windows Vista og Windows 7... 3

Detaljer

Samarbeidsløsning for FHS, Teknisk info

Samarbeidsløsning for FHS, Teknisk info Samarbeidsløsning for FHS, Teknisk info 1. Kontorstøtte Samarbeidsløsningen som FHS-kontorene har etterspurt må forholde seg til kontorstøttesystemer, e-post, kalender og kontakter. Dette har egentlig

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

Kravspesifikasjon. IT-infrastruktur. Kravspesifikasjon. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008

Kravspesifikasjon. IT-infrastruktur. Kravspesifikasjon. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008 IT-infrastruktur Kravspesifikasjon Mathias Hagen Balagumar Rajaratnam Høgskolen i Oslo Avdeling for Ingeniører 23. mai 2008 Høgskolen i Oslo Hovedprosjekt i data, 2008 Gruppe 8 side 2 PROSJEKT NR. 08-08

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

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer