Meglerhuset Bjerke AS

Størrelse: px
Begynne med side:

Download "Meglerhuset Bjerke AS"

Transkript

1 2014 Hovedprosjekt 2014 Gruppe 20 Meglerhuset Bjerke AS [Torbjørn Gjøn Snorre Duun Strømsborg Matias Pettersen] 1

2 2

3 FORORD Dette dokumentet beskriver hovedprosjektet «Meglerhuset Bjerke» og omfatter all sluttdokumentasjon samt relevante styringsdokumenter utformet i forbindelse med hovedprosjekt i bachelorstudiet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Sluttrapporten består av fire delrapporter: - Prosessdokumentasjon Beskriver hvordan prosessen har foregått - Kravspesifikasjon Beskriver kravene til systemet som er utviklet - Produktdokumentasjon Beskriver produktet og hvordan det er bygget opp - Brukermanual Beskriver for sluttbruker hvordan løsningen skal brukes Løsningen som er laget er en nettside og en administrasjonsside utviklet for Meglerhuset Bjerke AS. Løsningen er tilpasset for bruk på PC, nettbrett og mobil. en og andre relevante dokumenter ligger også tilgjengelig på prosjektets hjemmeside. en er skrevet ved hjelp av Microsoft Word 2013 og er optimalisert for trykket version. 3

4 Takk til Vi vil takke Mona Bjerke ved Meglerhuset Bjerke for å ha gitt oss muligheten til å utvikle vårt hovedprosjekt i samarbeid med hennes bedrift. Vi vil også takke vår veileder, Andre Lincoln Read, for å ha gitt oss gode råd og god veiledning gjennom hele prosjektet. Vi vil spesielt takke vår Lars Henrik Nordli for god hjelp til utvikling av administrasjonssiden i en kritisk sluttfase av prosjektet. 4

5 Innholdsliste Prosessdokumentasjon...6 Kravspesifikasjon...58 Produktdokumentasjon..73 Brukerdokumentasjon

6 2014 Hovedprosjekt 2014 Gruppe 20 Prosessdokumentasjon Meglerhuset Bjerke AS [Torbjørn Gjøn Snorre Duun Strømsborg Matias Pettersen] 6

7 1 Forord Dette er prosessdokumentasjonen vi har laget for vårt hovedprosjekt. I dette dokumentet blir det beskrevet hvordan vi jobbet med utviklingen, valg vi har tatt, problemer som har oppstått, metodikker, arbeidsmetoder og verktøy vi har brukt. Prosessdokumentasjonen er ment for sensor og veileder, men kan også være interessant for oppdragsgiver. I dette dokumentet er språket ganske enkelt, og det er ment at en kan lese dette uten å kunne noe spesielt om teknologi eller utvikling fra før. 7

8 Innholdsliste 1 Forord Innledning Gruppen Ansvarsområder Om Bedriften Bakgrunn for oppgaven Mål og rammebetingelser Planlegging og metode Valg av oppgave Planleggingsfasen Risikohåndtering Verktøy og teknologier Wordpress Notepad Ontime Twitter Bootstrap Hvorfor Bootstrap Photoshop Filezilla Dropbox PRO ISP Kunnskap Kommunikasjon I gruppen Med oppdragsgiver Med veileder Dokumentasjon Dokumentasjonsstandard

9 3.8.2 Styringsdokumenter Samarbeidsavtale Risikoplan og SWOT-analyse Prosjektskisse Prosjektdagbok Forprosjektrapport Arbeid og fremdriftsplan Skisse av layout Prosessdokumentasjon Produktdokumentasjon Testdokumentasjon Brukerdokumentasjon Kravspesifikasjon Om utviklingsprosessen Valg av systemutviklingsmodell Smidig utvikling Scrum Design Fargevalg Kontraster Ikke-boks struktur Designteknikker Papirskisser Kvalitativ spørreundersøkelse Designprinsipp Consistency Familiarity Affordance Navigation Flexebility Style

10 4.3 Utfordringer Joomla Utfordring Løsning Hva kunne vi gjort annerledes Scrum og ontime Utfordring Løsning Hva kunne vi gjort annerledes Pubilsering i wordpress Utfordring Løsning Hva kunne vi gjort annerledes Testing Funksjonstesting Brukertest av design Kravspesifikasjonen og dens rolle Utarbeidelse av kravspesifikasjonen Endring av versjon Samsvar med kravspesifikasjon Avvik fra kravspesifikasjon Ikke-oppfylte krav Krav som burde vært med Konklusjon Referanser Vedlegg Styringsdokumenter Konkurrenter Hvem er konkurrentene i: Hedmark/Oppland? Oslo? Utenlandske?

11 9.3 Hva gjør konkurrentene? Hva er forskjellene mellom hver konkurrent? Eiendomsmegler Aktiv Krogsveen Obos Eie Sem-Johnsen Foss & Co Wahl Eiendom AkershusEiendom NE HomeEiendom Konklusjon: Prosjektskisse Rutiner Skisser Prototyper

12 2 Innledning 2.1 Gruppen Gruppen bak dette hovedprosjektet består av Torbjørn Gjøn, Matias Pettersen og Snorre Duun Strømsborg. Alle på gruppen har gått i samme klasse på bachelorstudiet Anvendt Datateknologi ved Høgskolen i Oslo og Akershus. Vi har siden starten av tredje semester samarbeidet ved alle gruppeprosjekter og så det som naturlig for oss at vi også skulle skrive bacheloroppgave sammen. Vi følte at vi gikk inn i oppgaven med tilnærmet like forutsetninger og kunnskapsnivå og at dette dannet en god plattform for et godt samarbeid med hovedprosjektet, samtidig som vi har hver våre styrker som vi kan utnytte i arbeidet med utformingen av prosjektet Ansvarsområder Vi har hatt hver våre overordnede ansvarsområder gjennom prosjektets fremgang. Torbjørn har hatt et overordnet ansvar for design av siden. Han har utarbeidet skisser, prototyper og utført brukertester. Design var et område som var veldig i fokus i starten på prosjektet, og etter hvert som designet kom på plass, gikk han over til å skrive dokumentasjon. Matias har hatt et overordnet ansvar for koding og styling av siden med CSS. Han fungerte også som prosjektleder, da han hadde kontakt med oppdragsgiver og var Scrum-master. Snorre har hatt et overordnet ansvar for administrasjonsbiten rundt prosjektet samt dokumentasjonen. Han hadde også ansvar for publisering på prosjektnettsiden og prosjektdagbok. 2.2 Om Bedriften Meglerhuset Bjerke AS er et frittstående eiendomsmeglerfirma etablert i Daglig leder er Mona Bjerke. De selger hovedsakelig boligeiendommer, men deres tjenester omfatter også salg av fritids-, 12

13 landbruks- og næringseiendommer. Meglerhusets hovedkontor er lokalisert sentralt i Elverum og har fem ansatte, hvorav to er meglere. 2.3 Bakgrunn for oppgaven Meglerhuset Bjerke har i dag en nettside, men denne er ifølge oppdragsgiver utdatert og de ønsker noe nytt. Dagens nettside er ikke tilstrekkelig sett mot konkurrentene, og det generelle nivået som er forventet av nettsider til seriøse bedrifter i dag. Slik det er i dag er alle annonser plassert på Finn.no og om man ønsker å kjøpe en bolig blir man dirigert direkte dit fra hjemmesiden. Dette er ikke vanlig praksis blant andre eiendomsmeglerfirmaer. Daglig leder Mona Bjerke ønsket at vi skulle gjøre noe med denne problemstillingen. Visjonen er at Meglerhuset Bjerke skal få en nettside som fremstår som moderne og er konkurransedyktig i det markedet de konkurrerer i. Meglerhuset Bjerke er en bedrift i vekst, og ønsker ekspandere på mange fronter, blant annet på nett. Vår oppgave er å løse dette, slik at Meglerhuset Bjerke med stolthet kan henvise kunder til nettsiden for en god opplevelse. Vi tok på oss å designe og lage en helt ny løsning fra bunnen. 2.4 Mål og rammebetingelser Målet med oppgaven vår, er å lage en helt ny nettportal for Meglerhuset Bjerke. Løsningen vi lager kan deles opp i to deler. 1. For brukere: Brukere skal kunne finne all nødvendig informasjon på nettsiden om kjøp og salg av bolig. Brukere skal også kunne lese om Meglerhuset Bjerke, og få en god oversikt over hva de tilbyr av tjenester, og kunne finne prospekter på kjøp siden. 2. For Meglerhuset: Meglerhuset skal ha mulighet til å kunne redigere på informasjon på siden, dette vil si både den statiske teksten og prospekter som skal legges ut på nettsiden. Første del skal inneholde: Bilder 13

14 Informasjon Meny Prospekter Bildeshow Kontaktinformasjon Målet med siden er at Meglerhuset Bjerke skal ha en konkurransedyktig løsning på nett. Her skal de kunne promotere seg selv og hva de tilbyr på en effektiv og god måte. Siden skal være skalerbar, slik at brukere skal kunne besøke siden via alt fra en telefon til store skjermer. Siden skal også fungere uten problemer i de vanligste nettleserene som; Chrome, Firefox, Opera og Explorer. Andre del skal inneholde: Administrator skal kunne legge til, endre eller slette prospekter. Legge til prospektbilder 3 Planlegging og metode 3.1 Valg av oppgave Høsten 2013 bestemte vi oss for å danne en gruppe bestående av de tre undertegnede i dette hovedprosjektet. Vi hadde samarbeidet godt siden høsten 2012(3. semester), og følte det naturlig å jobbe samme. Vi kjenner hverandre godt og har samarbeidet godt ved tidligere prosjekter. Vi ble etter litt diskusjon innad i gruppen enige om at vi ønsker å utvikle en nettside, for det var noe alle på gruppen kunne tenkte seg å gjøre. Å jobbe med HTML, CSS var vi kjent med fra tidligere fag, og alle hadde en god opplevelse med å utvikle nettside. Vi fant og ut at ved å lage en nettside ville vi få brukt mye av det vi har lært fra mange fag vi har hatt på skolen. Det var mer appellerende enn å starte på noe vi ikke kunne så mye om, og måtte tilegne oss masse ny kunnskap. 14

15 Etter vi hadde blitt enige om type oppgave, startet gruppen å bruke egne kanaler (nettverk) for å finne en potensiell oppdragsgiver. Vi kom i kontakt med Meglerhuset Bjerke gjennom Matias, og valgte å gå for et samarbeid med Mona Bjerke, daglig leder for Meglerhuset AS. Ideen hun presenterte for oss var i tråd med det vi selv så etter i en oppgave. Vi valgte å lage en nettside for henne da vi fikk mye frihet, og vi fikk gjøre oppgaven på våre premisser. Det at hun lot noen studenter utvikle en så stor del av bedriften tok vi også som en tillitserklæring, og vi fikk for første gang i løpet av vår tid på skolen følelsen av å gjøre noe på "ekte". Dette er et produkt som er planlagt og settes ut i drift, og ikke legges på is. Vi ble motiverte av dette, og i løpet av kort tid var avtalen et faktum. 3.2 Planleggingsfasen Planleggingen av prosjektet startet allerede i høst da vi måtte finne utav hva vi ville gjøre, og hvem vi ville gjøre det for. Grunnen til vi måtte starte med prosjektet allerede i høst, var at skolen kunne sikre seg om at alle hadde en gruppe, og en oppgave å starte på når vårsemesteret startet i januar. Det var også fint for oss, da vi visste hva som ventet oss i hovedprosjektet, og vi kunne forberede oss faglig og mentalt på hva som ventet. Vi brukte ikke lang tid på å finne ut hva vi ville gjøre, Matias satt oss raskt i kontakt med Meglerhuset Bjerke for å høre om muligheten for å utvikle en ny nettside for dem. Etter vi hadde fått til en avtale med oppdragsgiver, laget vi en statusrapport som beskrev hva vi hadde fått på plass innen Etter dette fulgte en prosjektskisse som ble en beskrivelse av hva vi ville gjøre, og skolen skulle bruke dette dokumentet for å godkjenne oppgaven som vi ønsket. Da prosjektskissen var godkjent, startet vi med å utarbeide en forprosjektrapport. Dette var noe vi brukte mye tid på, og vi fokuserte på å gjøre den bra, slik at vi hadde gode styringsdokumenter til hovedprosjektet. Dette er viktig for vår del, da vi ikke har erfaring med prosjekter av så stor skala. Det gir også veileder en oversikt over hvordan vi har planlagt prosjektet, og han fikk da mulighet til å komme med innspill og tips. 15

16 Metoden vi valgte ble Scrum, da vi ville jobbe på en smidig måte. Scrum er veldig i vinden for tiden, og mange IT-bedrifter jobber med denne metoden. Vi valgte også anvende en designmetode som heter "Brukersentrert Design", det setter brukeren i fokus under hele utviklingsprosessen. Når en jobber med denne metoden er det viktig å få tilbakemelding fra brukere, og alltid ta brukerens behov og tilbakemeldinger i betraktning under utviklingen. Vi brukte nok for mye tid i starten på planlegging, og skulle ha kommet raskere i gang med arbeidet. Vi ville være sikre på at det vi valgte var korrekt i henhold til det vi skulle gjøre. Dette har vist seg i ettertid som en dårlig idé, da vi har hatt store problemer med administrasjonsbiten. Vi valgte først å gå for jomla, for å bytte til WordPress senere, for å så lage en løsning med php og MySQL. Dette måtte vi få hjelp til av noen venner, da kompetansen innad i gruppen var ikke god nok. Vi laget også en prosjektside som vi lastet opp på skolen sin server. Denne siden er et hjelpemiddel for veileder og oppdragsgiver. Siden er en enkel løsning som er utviklet med Bootstrap, HTML og php. Denne siden fungerte også som en øvingsside der vi fikk testet Bootstrap, og vi fikk en oppfriskning i webutvikling. Da det var lenge siden vi hadde gjort noe lignende. På grunnlag av at vi ikke legger ut noe sensitiv informasjon om Meglerhuset, så var det ikke nødvendig med innlogging eller annen sikkerhet på prosjektsiden. 3.3 Risikohåndtering I starten av prosjektet laget vi en risikoplan og en samarbeidsavtale for prosjektet. Dette ble laget for at alle på gruppen skal ha en felles forståelse av hva som er forventet av hver enkel medlem, og det gir også generelle spilleregler for gruppen. Risikoplanen er et dokument som beskriver mulige risikoer som kan oppstå i løpet av prosjektet, hvordan det vil påvirke prosjektet,tiltak mot risiko, og løsning hvis risiko oppstod. 16

17 Alle større prosjekt har en riskikoplan som tar høyde for uforutsette hendelser, og vårt prosjekt er ikke noe unntak. Siden vi ikke tar betalt, er økonomi ikke noe vi trenger å ta med som en faktor. Vi har kun tatt høyde for de vanligste risikoene vi som studenter kan møte på. Det finnes flere risikoer enn det vi har tatt med, men vi anser de som lite sannsynlig. 3.4 Verktøy og teknologier I planleggingsfasen måtte vi finne ut hvilke programmer vi skulle bruke for å utføre oppgaven på en effektiv og god måte. Valg av verktøy kan være utfordrende, da vi ikke alltid visste hva som var det beste alternativet. Vi gjorde mye research for å finne de programmene som kunne fungere godt for oss. Vi ville unngå å bytte programmer i prosjektet, da de kan være tidkrevende å sette seg inn i. Så vi laget en liste over programmer som vi ville bruke. I slutten av prosjektet kom vi opp i en situasjon angående publisering av prospekter på siden via Wordpress, og dette har vist seg å være prosjektets største utfordring. 3.5 Wordpress Vi har i vår oppgave sett på Wordpress som publiseringsverktøy. Wordpress er et Open source verktøy, noe som betyr at folk over hele verden kan jobbe med det og utvikle det videre. Det er i tillegg gratis å bruke. Vi valgte å se på Wordpress utifra anbefalinger fra venner og egen research rundt Wordpress. Programmet er veldig utbredt, og veldig mange nettsider bruker deres funksjoner på sine nettsider. Derfor tenkte vi at vi ville alltid finne hjelp og råd om vi lurte på noe om programmet. Det installeres på en webhost, og vi laget en egen template på Wordpress slik at siden vi utviklet kan brukes sammen med WP. 17

18 For å få brukt WP til å publisere for oss måtte vi installere en plugin og valget falt på en plugin som heter Types. Denne pluginen gjør at vi kan lage egne publiseringstekstbokser som kjører output på nettsiden vi har laget ved hjelp av php i koden som kaller på kodeord satt i WP. 18

19 3.5.1 Notepad++ Notepad++ er en gratis teksteditor. Den er enkel i bruk og har syntaksmerking, noe som gjør kodingen mer oversiktlig Ontime Ontime er et scrum-verktøy som hjelper oss å holde rede på sprintene våre. Programmet er utviklet av Axosoft og selskapet ble grunnlagt i Vi har brukt det til å opprette sprinter og legge inn arbeidsoppgaver, samt følge med på burndown chart. Arbeidsoppgavene har vi rangert etter poeng hvor ett poeng er tiltenkt å være én time. Arbeidsoppgavene som legges inn legges som en "new request" og brukeren som oppgaven er gitt til velger å "approve" den, eller legge den rett inn i "in progress". Når man er ferdig med oppgaven settes oppgaven til "completed" slik at alle i gruppa kan se at arbeidsoppgaven er løst, og følge progresjonen. Figur 1: Ontime 19

20 3.5.3 Twitter Bootstrap 3 Figur 2; Bootstrap Twitter Bootstrap 3.0 er et gratis front-end rammeverk for å lage websider og webapplikasjoner. Rammeverket består av HTML og CSS-baserte design templates for interaksjonskomponenter og grid-systemer. Per mars 2014 er Twitter Bootstrap 3.0 det mest populære prosjektet ved GitHub og har vært det siden februar Hvorfor Bootstrap Slik vi ser det idag kan man ikke bruke lang tid på å finne hjulet opp på nytt. Derfor bestemte vi oss for å bruke et rammeverk som ville gjøre prosessen mer effektivt. Vi går inn i biblioteket, finner "blueprintsene" til hjulet og lager vår egen nettside basert på det Photoshop Figur 3: Photoshop I utviklingen av prototyper tok vi i bruk bilderedigeringsprogrammet Adobe Photoshop. Torbjørn hadde erfaring med dette programmet fra tidligere, og det er en enkel og rask måte å få produsert detaljerte skisser som kan brukertestes. Det som er praktisk med photoshop er at de forskjellige elementene er delt opp i layers, så etter wireframen er satt, er det bare å endre fargene på de forskjellige elementene. Prototypene som ble utviklet kunne vises til oppdragsgiver slik at hun fikk mulighet å komme med innspill, og endringer kunne gjøres raskt. 20

21 3.5.5 Filezilla Filezilla er en gratis Open Source FTP(File Transfer Protocol)-program. Programmet er brukt til å laste opp filer fra datamaskinen til et webhotell. Figur 4: Filezilla Dropbox Figur 5: Dropbox Dropbox (opprettet i 2007) er et skylagringsprogram som lar deg lagre dokumenter, bilder og video. Disse kan aksesseres hvor enn du er i verden så lenge du har tilgang til internett eller hvis du har gjort de tilgjengelige offline på din enhet. Alle mapper kan deles og brukes av flere slik at man kan aksessere hverandres arbeid i et gruppeprosjekt PRO ISP Figur 6: PRO ISP PRO ISP ble etablert i 2002 og leverer tjenester innen webhotell, domener, virituell privat server(vps) og SSL sertifikater. Et webhotell lagrer og publiserer? filene vi har generert i utviklingsprosessen og gjør at de blir tilgjengelige på internett. Vår oppdragsgiver har webhotell hos PRO ISP allerede, og dette abonnementet dekker våre krav til et webhotell. 3.6 Kunnskap 21

22 Etter en rask gjennomgang av ulike språk ble vi enige om å primært bruke HTML, CSS, PHP og Javascript i all hovedsak. HTML og CSS lærte vi i kurset Web-prosjekt første semester, PHP og Javascript lærte vi i kursene Grunnleggende Programmering og Webprogrammering. IDa det var lenge siden vi hadde brukt disse språkene aktivt, måtte vi bruke litt tid på gjenoppfriskning. Dette ble blant annet gjort gjennom å lage prosjektnettsiden fra bunn. samråd med veileder ble vi enige om å bruke eksisterende rammeverk som hjelp til å utvikle siden vår. Valgene falt på Bootstrap 3 og Joomla, men sistnevnte ble senere byttet ut med Wordpress, som igjen ble byttet ut med en egen løsning som vi fikk på plass helt i slutten av prosjektet. 3.7 Kommunikasjon Figur 7: Kommunikasjon 22

23 3.7.1 I gruppen Vi ble tidlig enige om at vi skulle ha møter flere ganger i uken og jobbe jevnlig med prosjektet. To av gruppemedlemmene har tatt to kurs ved siden av hovedprosjektet, sistemann har tatt ett kurs ved siden av. Dette er blitt ihensyntatt med tanke på møtetidspunkter. Vi har hatt møter 2-3 ganger i uken, i tillegg har det foregått arbeid med hovedprosjektet på individuell basis. Når vi ikke har møttes har gruppen hovedsaklig holdt kontakt gjennom Facebook, men SMS og telefon er også blitt benyttet i mindre grad, her har vi oppdatert hverandre med informasjon og avklart eventuelle spørsmål eller usikkerhetsmomenter som ikke er blitt avklart på møter. Dropbox er blitt brukt til å lagre våre dokumenter og har bidratt til at alle aktører til enhver tid kan se hva som er gjort Med oppdragsgiver Mona Bjerke har vært vår kontaktperson hos Meglerhuset AS. Hun er daglig leder i bedriften og har vært vår kontakt hele veien. Bjerke ga oss på første møte relativt frie tøyler når det gjaldt utviklingen av nettsiden, men hadde noen absolutte krav. Kontakten med oppdragsgiver har i all hovedsak foregått på telefon og via e-post da kontoret hennes er lokalisert i Elverum. Det har gjort at kommunikasjonen ble tatt over telefon eller e- post isteden for et møte. Vi synes dette har vært en god måte å løse avstandsutfordringen på, samtidig som vi fra starten av har vært klar over krav og ønsker fra oppdragsgiver slik at hyppig kommunikasjon ikke har vært nødvendig til enhver tid. 23

24 3.7.3 Med veileder André Lincoln Read har vært vår veileder gjennom hovedprosjektet. Vi har gjennomført møter hver tirsdag med noen få unntak. I disse møtene har vi pratet om fremgangen i prosjektet, utfordringer vi har støtt på og fått svar på spørsmål vi har hatt. Muligheten for veiledning har vært en stor trygghet for oss som gruppe og den har hjulpet oss med å finne motivasjon og inspirasjon til videre utvikling av prosjektet. 3.8 Dokumentasjon Dokumentasjon har vært en viktig del av prosjektet helt siden vi startet. For å hjelpe med å holde styr på alt som skal gjøres og hvordan vi skal gjøre det. De første dokumentene vi laget var: - Samarbeidsavtale - Risikoplan - Prosjektskisse - Kravspesifikasjon - Arbeidsplan - Fremdriftsplan - Forprosjektrapport Da vi hadde laget disse, fikk vi en god oversikt over prosjektet i sin helhet. Det var disse styringsdokumentene vi forholdt oss til Dokumentasjonsstandard Under utviklingen av dokumentasjon av hovedprosjektet har vi forholdt oss til "Dokumentasjonsstandard for bachelor-prosjekter for Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus". Dette er en dokumentstandard vi har fått henvist fra skolen og det er da naturlig at vi forholder oss til denne i utviklingen av vår dokumentasjon. 24

25 3.8.2 Styringsdokumenter Styringsdokumentene ble utviklet helt i begynnelsen av prosjektet og ble opprettet i den hensikt å legge et godt grunnlag for fremdriften av prosjektet. Endringer i dokumentene har forekommet, men de har gitt oss et godt utgangspunkt og bidratt til å holde kursen i prosjektet Samarbeidsavtale Et dokument som der det står hva som er forventet av gruppemedlemmene. Her forplikter vi oss til å bidra i prosjektet Risikoplan og SWOT-analyse Risikoplanen er et styringsdokument som inneholder risikoer i forhold til prosjektet. Vi diskuterte innad i gruppen om hvilke fiaskoer vi kunne møte på, og utarbeidet en risikoplan som var aktuell for oss. I risikoplanen står også tiltak som skal settes i gang hvis vi opplever noe går galt i prosjektet. SWOT- og risikoanalyse ble utviklet for å få en oversikt over styrker og svakheter, samt eventuelle situasjoner som kan oppstå under utformingen av prosjektet. SWOT står for Strengths (styrker), Weaknesses (svakheter), Opportunities (muligheter) og Threats (trusler). I SWOT-delen listet vi opp styrker, svakheter, muligheter og trusler for prosjektet og dette ga oss en oversikt over hva vi måtte være litt ekstra oppmerksomme på, spesielt eventuelle svakheter og trusler. Risikoanalysen ble utviklet med ønske om å å bli klar over mulige risikoer knyttet til prosjektet og hva som kunne være hindringer på veien samt hvordan vi skulle forholde oss til disse hindringene som kunne oppstå. 25

26 Prosjektskisse Prosjektskissen var det første dokumentet vi opprettet. Det inneholder informasjon om gruppemedlemmene, oppdragsgiver, prosjektets plass i oppdragsgivers virksomhet, en rask beskrivelse av prosjektet og noen enkle krav vi så for oss den gangen Prosjektdagbok Prosjektdagboken har bidratt til at vi har kunnet gå tilbake og se hva som er blitt gjort etterhvert som prosjektet har gått fremover. Her har vi kunnet se hva som har fungert godt og hva som har vært av utfordringer som vi har møtt. Prosjektdagboken har vært meget nyttig i utformingen av sluttdokumentasjonen, fordi vi har dokumentert prosessen gjennom hele prosjektet, og det kommer godt med når vi skriver prosessdokumentasjonen Forprosjektrapport Forprosjektrapporten er et dokument som viser hvilken kurs vi har staket ut for prosjektet, og har således vært viktig for oss med tanke på at vi tidlig måtte ta valg og avgjørelser som gjorde at vi kom igang med prosjektet i fornuftig tid. I dette dokumentet har vi med arbeidsmetode, mål og rammebetingelser og hovedtrekk i løsningen Arbeid og fremdriftsplan Etter utarbeidelsen av de andre dokumentene, spesielt forprosjektrapporten, følte vi at vi hadde et godt bilde av omfanget av oppgaven vi hadde tatt på oss. Dermed kunne vi utarbeide en arbeids- og fremdriftsplan. Disse dokumentene ble utviklet med ønske om å kunne planlegge arbeidet og sette frister for når ting skulle være ferdigstilt. Dokumentene var viktige for oss, men samtidig erfarte vi at vi ikke hadde jobbet med et prosjekt av et slikt omfang før og at planlegging på denne måten var en utfordring. Vi kan i etterpåklokskapens lys si at tiden ikke ble disponert helt i henhold til arbeids- og fremdriftsplanen, samtidig som dette har gitt oss nyttig lærdom rundt å planlegge og utvikle et prosjekt av dette omfanget. 26

27 Skisse av layout Vi startet prosessen med å utarbeide skisser til layout tidlig. Taktikken vi gikk for var å lage mange skisser, for å så brukerteste dem. Etter brukertesten gikk vi videre med de skissene som kom best ut i brukertesten, dette kalles brukersentret design. Vi skisset hovedsakelig på papir, og brukte teknikker vi hadde lært i faget "Prototyping" første semester ved skolen. Etter vi var fornøyd med layouten startet vi å digitalisere den i photoshop. Der testet vi hvilke farger vi skulle bruke på siden, dette ble også gjort med brukertester. Her kunne vi enkelt endre på farger, og kjapt produsere mange forskjellige prototyper med den samme layouten en er dokumenter som skal bli laget i slutten av prosjektet der vi skriver om oppgaven. Noe av dokumentene er blitt jobbet på i løpet av prosjektet for å minske noe av skriveoppgavene helt i slutten, men det meste er skrevet etter produktet var klart. en er veldig viktig, da sensor skal gå gjennom denne. Dette er et dokument som er stykket opp i fire deler som til slutt utgjør sluttdokumentasjonen. Vi har forklart mer om de individuelle delene i de neste punktene Prosessdokumentasjon Vi har utarbeidet en prosessdokumentasjon som beskriver hvordan prosessen å jobbe med prosjektet fra start til slutt. Utformingen av dokumentet skjedde hovedsakelig på slutten, men vi har mye gode notater underveis i prosjektet som blir brukt når vi skriver om prosessen. I dette dokumentet beskriver hvordan vi har jobbet, hvilke verktøy vi har brukt, arbeidsmetoder, utfordringer og løsninger. 27

28 Produktdokumentasjon I dette dokumentet beskriver vi selve produktet, forklarer systemet, slik at en eventuell videreutvikling av nettsiden er lite problematisk. Dokumentet er ment for utviklere, og er ment til hjelp for videreutvikling. I dokumentet beskriver vi funksjoner på siden, og hvordan elementer henger sammen Testdokumentasjon Når en skal utføre tester, er det viktig å dokumentere dette. Tester som kan gjennomføres i et slikt prosjekt er hovedsakelig brukertesting, feiltesting av kode, og funksjonstesting. Denne dokumentasjonen er først og fremst ment for de som skal drifte systemet. Vi har foretatt en del brukertesting i forhold til design. Grunnet lite tester utenom det, har vi valgt å gå bort fra å ha en egen testdokumentasjon. Derfor har vi valgt å lage et eget kapittel i prosessdokumentasjonen om dette Brukerdokumentasjon Brukerdokumentsjonen er et viktig dokument for sluttbruker, spesielt for den som skal fungere som administrator. I dette dokumentet beskrives det hvordan man tar i bruk løsningen som er blitt utviklet og hva man må være oppmerksom på ved bruk av systemet. Dokumentasjonen er skrevet på en slik måte at man skal kunne forstå den om man har grunnleggende datakunnskaper Kravspesifikasjon Kravspesifikasjonen er et dokument som er utviklet for å vise krav til systemet. Her kan man finne alle kravene systemet oppfyller, samt krav som av en eller annen årsak ikke er oppfylt. 28

29 4 Om utviklingsprosessen 4.1 Valg av systemutviklingsmodell Vi ønsket oss tidlig en systemutviklingsmodell som ikke må gjennomføres på en måte der alt er planlagt på forhånd og endringer er problematiske. Vi har liten erfaring med å utvikle nettsider fra før av, så en modell med ufravikelige krav og klare faser ville kunne være til hinder for en god utvikling av prosjektet. Vårt valg falt på en metode der man kan utvikle i iterasjoner og med mulighet for å gå tilbake og endre på ting som er gjort eller ønskes gjort annerledes. I utgangspunktet skal man levere et nytt produkt til oppdragsgiver etter hver endte syklus(sprint), men i praksis så var vi ikke i dialog med oppdragsgiver etter hver syklus da dette ikke var nødvendig for hverken henne eller oss med de rammene vi var gitt. Vi så for oss muligheten for at kravspesifikasjonen kunne endres underveis enten fra oppdragsgivers side eller fra vår egen side. Dette underbygget vårt ønske om en smidig utviklingsmodell Smidig utvikling Smidig utvikling er en systemutviklingsmodell. Denne står i sterk kontrast til den mere tradisjonelle fossefallsmodellen hvor arbeidet gjennomføres i distinkte faser og hvor resultatet av én fase er grunnlag for arbeidet i neste fase. Når én fase er utført må man fortsette fremover. I smidig utvikling er det annerledes, her har man mulighet til å endre krav underveis. Kontrakt med oppdragsgiver/kunde er essensielt. Kunden inkluderes og deltar i utviklingen ved at vedkommende får nye prototyper av prosjektet i slutten av hver sprint og forteller hva han/hun er fornøyd med samt mindre fornøyd med som må endres. Prosjektet styres dermed i den retningen kunden ønsker og gjør samtidig at krav kan endres gjennom prosjektet. En sprint har i vårt tilfelle vart i to uker av gangen. Smidig utvikling vektlegger dermed utvikling av krav og løsninger underveis Scrum 29

30 "Scrum er basert på empirisk prosesskontrollteori, eller empirisme. Empirisme baserer seg på at kunnskap kommer fra erfaring og beslutninger baseres på det som er kjent." Scrum og prosessen rundt kan oppsummeres med noen enkle punkter: Det lages en prioritert liste over alt som gruppen skal gjøre. Dette er en liste over aktiviteter eller en liste over funksjoner som systemet skal inneholde. Gruppen oppretter en sprint som kan vare opptil 30 dager, i vårt tilfelle har sprintene vart 14 dager. Her innhenter man arbeid som gruppa anslagsvis antar er oppgaver for 14 dager og legger de til i sprinten. En sprint er en gitt periode hvor gruppa jobber med arbeidet som er lagt til i sprintloggen. Man kan ofte bruke et scrum-verktøy for å holde orden og oversikt over sprintloggen og arbeidsoppgavene som skal utføres/er utførte. Scrum master er en rolle som tildeles en person i gruppa. Vedkommende har ansvar for sprintene og de daglige scrummøtene som skal gjennomføres. Han har også ansvaret for at eventuelle hindringer som kommer frem under scrummøtene fjernes eller ordnes. Det skal forekomme daglige scrummøter der man prater raskt om hva som er status i prosjektet og om eventuelle hindringer i prosjektet. Etter endt sprint skal man levere en ny version av produktet til produkteier(oppdragsgiver) som gir tilbakemelding og kommer med forslag til eventuelle forandringer og utbedringer. 4.2 Design Fargevalg Å velge gode farger og fargekombinasjoner til en nettside er essensielt. Farger har viktige oppgaver; Tjene estetiske funksjoner Tydeligjøre bruks-, sikkerhets- og signalfunksjoner Understreke formvirkninger Farger gir også mennesker assosiasjoner, så her gjelder det å prøve litt forskjellig, og komme opp med et passende design som er bra, og på samme tid representerer bedriften. Dette krever ofte mye tålmodighet, eksperimentering og helst minimalt med gjetting. Vi har allerede fått fått krav fra oppdragsgiver om 30

31 hvordan hun tenker siden skal se ut med tre farger; Svart, gull og hvit. Og med dette utgangspunktet kom vi opp med 6 mulige fargekombinasjoner til siden som var i henhold til kravene vi har fra oppdragsgiver. Måten vi gjorde dette på var å få inspirasjon fra andre meglersider, være kreative og bruke kravene som var satt. Vi fikk skissene digitalisert inn i photoshop, og jobbet derfra med å sette inn farger, og gjøre skissene om til en prototype Kontraster Kontrast er forskjellen mellom to eller flere elementer. Ved å bruke kontraster effektivt og riktig klarer vi å fange brukerens oppmerksomhet der vi vil. Noe vi har gjort med å gå for masse kontraster med hvit og svart tema. Det er lite forstyrrende elementer, slik at teksten blir fremhevet sterkt, og vi formidler budskapet som sider vil gi på en effektiv måte. Elementene vi har laget står i forhold til hverandre, og ting skal ikke stikke seg ut slik at en får følelsen av at det ikke passer inn Ikke-boks struktur Vi har valgt å ikke bruke bokser som rammer inn innholdet på siden, men heller gå for en åpen stil med "usynlige" bokser som en ikke ser, men vi gir brukeren inntrykk av at det er usynlige bokser som rammer inn informasjonen. Vi har strippet siden for så mye unødvendig grafikk som vi klarte, og har endt opp med et simplistisk og strømlinjet rammeverk. Vi oppdaget helt i slutten av prosjektet at nettsiden bygger på de samme prinsippene som "www.nytimes.com", og det er veldig mange likheter mellom sidene. Dette ser vi på som noe positivt da det er en av de mest brukte sidene på internet, og det er lagt ned mye arbeid i å utarbeide den siden. Vi mener vi har gått for en "tidløs" løsning, så siden kan være som den er i mange år fremmover uten at Monabjerke AS føler de må endre på nettsiden for å henge med konkurentene i utarbeiding av design på sin nettside. 31

32 4.2.4 Designteknikker Vi har valgt oss ut litt forskjellige designteknikker i prosessen med å designe nettsiden. Vi har brukt lowfidelity og high-fidelety skisser i arbeidet med utviklingen av nettsiden Papirskisser I utviklingen av papirskisser er det viktig å få fram hva som er hovedtrekkene ved layouten. Å lage en papirprototype har mange fordeler når vi jobber med brukersentrert design, da vi får produsert mange prototyper på kort tid, og det går kjapt å brukerteste prototypene. Det er og en fordel å kunne endre skissene på kort tid, for å gi plass til utbedring av hver enkelt skisse. Papirprototyping er en veldig vanlig metode å bruke i brukersentrert design da en hele tiden kan få tilbakemelding fra brukere om hva de liker og ikke liker. Vi bruker denne metoden slik at vi allerede i et tidlig stadie kan utvikle siden slik at den blir mest mulig brukervennlig Kvalitativ spørreundersøkelse Kvalitative metoder brukes for å undersøke menneskers opplevelse og erfaringer. Dette er det vi har vært ute etter i våre undersøkelser. Vi har brukt denne metoden i alle våre undersøkelser, som har bestått av små intervjuer med rangeringer av skissene og prototypene Designprinsipp Design er et begrep som dekker mye mer enn bare fine fonter og tøffe farger. Det er hvordan brukeren oppfatter og får bruke nettsiden. Don Norman som har skrevet boken "The Design of Everyday Things" (Norman 1998) beskriver design prinsipper som retningslinjer til et godt design. Disse prinsippene kan brukes til å evaluere og kritisere prototype ideèr. Vi har brukt disse prinsippene aktivt da vi kom opp med vårt design, og har følgt denne ganske slavisk for å gjøre brukeropplevelsen best mulig for de besøkende. I listen som ligger under har vi listet opp noen av prinsippene, og hvordan vi har utformet siden opp mot disse. 32

33 Consistency Vi har valgt å designe siden på en klassisk måte, slik at brukerene kunne kjenne igjen hvordan siden fungerer Familiarity Vi har tatt utgangspunkt i andre eiendomsmeglersider, og laget navigasjon og informasjonen på noenlunde samme vis, slik at brukerene får en følelse av at dette er noe de har kjennskap til fra før. Det gjør det enkelt for brukerene å navigere seg raskt rundt på siden uten å lære seg noe nytt Affordance Affordance betyr å designe noe slik at det ikke er tvil om hva det er. Dette er noe vi har tatt høyde for, og tatt i betraktning når vi har utviklet nettsiden. Eks. Knapper ser ut som knapper, og det er ikke noe tvil om hva som skjer når du utfører en handling Navigation Gi brukeren mulighet til å bevege seg rundt på siden med god kontroll på hvor han befinner seg. Dette innebærer en god globalmeny som forteller en på hvilken side en er på Flexebility At brukeren kan endre på instillinger slik som han selv ønsker. Å ha en fleksibel side er viktig i henhold til Unviersell Utforming, da en må kunne endre på skriftstørrelse og på noen farger. Vi har og laget siden skalerbar, slik at brukere kan besøke siden på både datamaskinen sin og på telefonen, og ha en god opplevelse uansett hva de bruker Style Designet bør være stiligt og attraktivt. Dette mener vi at vi har klart å gjøre gjennom flere runder med brukertesting av forsjellige skisser og prototyper. Det er veldig viktig i dag at brukere føler de ikke er på en gammel og utdatert side. 33

34 4.3 Utfordringer Her vil vil skrive om utfordringer vi har møtt underveis i prosjektet, hvordan vi har valgt å løse disse og hva vi har lært av utfordringene Joomla Utfordring Joomla er et content management system og er open source. Et CMS er et system som er brukt for å administrere nettsider og er hyppig brukt av blant annet selskaper som skal markedsføre noe. Meglerhuset brukte i sin forrige version av nettsiden (den vi skal erstatte) Joomla som publiseringsverktøy, så vi fant det naturlig og i utgangspunktet velge dette også. Når vi derimot skulle starte med prosjektet for fullt etter planleggingsfasen fant vi ut av Joomla ikke helt var det vi var ute etter. Vi oppfattet programmet som tungt å bruke og tungt å sette seg inn i. I tillegg har vi pratet med bekjentskaper som har erfaring med å utvikle nettsider som varmt anbefalte oss å bruke Wordpress som publiseringsverktøy istedenfor Joomla Løsning Rådene fra våre bekjentskaper sammen med egne erfaringer gjorde at vi tok et valg om å bytte publiseringsverktøy fra Joomla til Wordpress. Wordpress er et verktøy vi har noe erfaring med fra tidligere, da personen som var ansvarlig for administrasjonsdelen av prosjektet har benyttet dette tidligere i andre prosjekter av mindre skala. Erfaringen var at dette var et verktøy som er brukervennlig og overkommelig å sette seg inn i når vi nå skulle bruke dets mere avanserte funksjoner enn når det brukes som en blogg. 34

35 Hva kunne vi gjort annerledes Vi ser i ettertid at vi kunne tatt en vurdering på valg av publiseringsverktøy tidligere. Publisering var en viktig del av vårt prosjekt, og det ville vært en fordel for oss om vi hadde kartlagt mulighetene våre bedre på et tidligere stadie i prosjektet. Vi kunne brukt internett bedre som verktøy for å finne informasjon, samt brukt eget nettverk for å lytte til andres erfaringer Scrum og ontime Utfordring Vi har under fremdriften av prosjektet hatt noen utfordringer rundt bruk av scrum som metode og herunder bruken av scrum-verktøyet Ontime. I begynnelsen av prosjektet estimerte vi våre arbeidsoppgaver på tid(hele timer). Vi erfarte at det var for utfordrende å estimere korrekt, så vi valgte å se på alternative metoder for estimering. Etter forslag fra veileder forsøkte vi planning poker, også kalt scrum poker. Ved bruk av denne metoden noterer hver person i gruppa ned et tall på en lapp alt etter hvor mye tid vi tror det vil ta å gjennomføre en oppgave. Vi brukte tallene 1,2,3,5,8,13,20. Deretter diskuterte vi oss frem til en tid vi ble enige om ut i fra tallene vi hadde skrevet opp. Vi opplevde igjen at dette var en vanskelig måte å estimere på, da vi følte at vi ikke traff godt nok på estimeringen Løsning Med utgangspunkt i overnevnte utfordringer begynne å bruke story points. Vi gikk bort fra å bruke tid, men nå estimerte vi isteden oppgavene med poeng etter hvor store vi følte de var. I en sprint på to uker skulle vi gjennomføre 180 story points og la til oppgaver tilsvarende dette. Denne metoden følte vi at passet oss mye bedre og at vi fikk en bedre samt mere reell estimering. Dette ble metoden vi valgte å bruke ut prosjektet med stort hell føler vi selv. I tillegg til utfordringer rundt estimering så møtte vi også utfordringer rundt størrelsen på arbeidsoppgavene vi tildelte hverandre. I begynnelsen hadde vi store oppgaver som med datidens estimeringssystem krevde mye estimert tid, samtidig som de ofte viste seg å ta enda lengre tid enn det vi estimerte. I tillegg opplevde vi at veldig 35

36 store oppgaver kunne fremstå som demotiverende da man ganske sjelden fikk huket av en oppgave som ferdig. Vi valgte å ha en annen tilnærming til oppgavene vi fordelte. Vi brøt disse i mye større grad til mindre oppgaver og fikk dermed også en følelse av å ha bedre progresjon i prosjektarbeidet i større grad enn tidligere. Dette økte også motivasjonen og mestringsfølelsen rundt prosjektutviklingen Hva kunne vi gjort annerledes Da vi har begrenset med erfaring med prosjekter av denne størrelsen fra tidligere så var det utfordrende for oss å se at dette ville bli en utfordring fra begynnelsen av. Vi kunne brukt internett i større grad for å lese om utfordringer rundt Scrum og estimering, men samtidig tror vi at dette ville hatt begrenset effekt. Dette mener vi fordi utfordringer som dette kan det være like greit å erfare, for så å ta en avgjørelse på bytte av metode om det ikke fungerer godt. Det er blitt en nyttig erfaring for oss, og noe vi vil ta med oss videre når vi skal arbeide med prosjekter senere Pubilsering i wordpress Utfordring Fire dager før innlevering av prosjektet møtte vi en uventet utfordring i forhold til publisering i Wordpress. Vi hadde tidligere i arbeidet med Wordpress opprettet tekstbokser for input og tilegnet disse et variabelnavn for så å kalle på variablene ved hjelp av PHP for å få output fra tekstboksene på nettsiden. Utfordringen oppsto ved linking mellom kjøpssiden og prospektsiden. Informasjon fra tekstboksene som er opprettet skal legges ut på begge sider, men vi hadde problemer med å linke disse sidene sammen. Denne utfordringen var av en slik karakter at vi ikke kunne overse den. Etter å ha forsøkt å få fikset dette uten hell måtte vi søke alternative løsninger. 36

37 Løsning Løsningen vi endte opp med var å hente inn ekstern hjelp. Ved hjelp av vårt kontaktnettverk kom vi i kontakt med en studiekollega som ønsket å hjelpe oss. Han bisto sterkt i utviklingen av en forenklet administrasjonsside som ble laget fra bunn. Denne løsningen ble en suksess og gjør at administrator kan legge ut sine prospekter og fjerne disse, noe som igjen gjør at siden er funksjonell for oppdragsgiver Hva kunne vi gjort annerledes I ettertid er det klart for oss at dette både kunne og burde vært håndtert på en bedre måte. Når vi byttet fra Joomla til Wordpress burde vi satt oss ned tidlig etter byttet og sett at vi klarte å gjennomføre alle oppgavene vi skulle som var knyttet til publisering i Wordpress. Dette ble ikke gjort, og en vital del ble dessverre glemt. Dette førte igjen til at vi fikk en stor utfordring på slutten av prosjektet som vi gjerne skulle vært foruten. 5 Testing Testing er en viktig del av systemutvikling, og arbeid med prosjekter. Det finnes flere type tester en kan utføre på vårt prosjekt. Vi har hovedsakelig brukt funksjonstesting og brukertesting. Under utformingen av designet brukte vi brukertesting aktivt i henhold til "brukersentret design". Brukertesting handler om å få tilbakemeldinger fra brukere, og ta de med i betraktningen for å utvikle et best mulig produkt. Dette er lurt fordi vi utvikler et produkt som skal brukes av kunder, og da er det veldig naturlig å bruke dem som en ressurs i utviklingsprosessen. 5.1 Funksjonstesting Vi testet konstant nettsiden for feil og mangler under utviklingen. Dette er en viktig del av utviklingsprosessen, da vi vil ha en side som fungerer optimalt. Måten vi har gått frem på er at vi har testet enkelt-funksjoner etter vi har implementert dem på siden. Hvis vi oppdaget en feil, så fokuserte vi på å fikse det med en gang, før vi kunne fortsette til neste 37

38 oppgave. Måten vi testet funksjonene var at Matias ga beskjed til de andre på gruppen at en funksjon var klar, så satte vi oss ned og testet den i plenum. Det var ønskelig å utføre flere tester, spesielt på slutten av prosjektet. Vi hadde laget scenarioer på forhånd, men grunnet de store problemene med publiseringsfunksjonen på siden strakk ikke tiden til, da vi måtte fokusere på å løse problemet. 5.2 Brukertest av design Etter vi hadde sett rundt på konkurrenter og gjort en vurdering på hvordan vi kunne tenkt oss å lage den nye siden til meglerhuset bjerke. Vi kom opp med seks skisser som vi brukertestet og fikk tilbakemelding på. Måten vi gjennomførte brukertesten var etter en rangeringsordning med samtale og kommentarer. Skissene var low-fidelity og helt enkle, så vi fokuserte på hva brukerene syntes om det generelle designet, og hva de la vekt på hos en eiendomsmeglerside. Etter vi hadde utført første brukertest, gjorde vi en analyse av resultatene, og gikk gjennom de tilbakemeldingene vi hadde fått. Vi laget nye skisser basert på første brukertest, og brukertestet dem på ny. Det å jobbe med brukersentrert design har fungert veldig bra for oss, og har vært gode bidrag i det endelige produktet. 6 Kravspesifikasjonen og dens rolle Her vil vi ta for oss utvikling av kravspesifikasjonen, endringer som er gjort, samsvar mellom produkt og kravspesifikasjon og eventuelle avvik fra kravspesifikasjonen. Kravspesifikasjonen har vært veldig viktig for oss under utviklingen av prosjektet, da denne har lagt føringene for hvordan sluttproduktet er blitt. 38

39 6.1 Utarbeidelse av kravspesifikasjonen Arbeidet med kravspesifikasjonen ble påbegynt tidlig i prosjektet. Et kravspesifikasjon ble produsert og publisert i forprosjektrapporten. Denne ble noe utvidet og redigert i tiden etterpå etter dialog med oppdragsgiver og vi endte opp med en kravspesifikasjon som ble et rammeverk for prosjektet og utviklingen kunne begynne Endring av versjon Kravspesifikasjonen har gjennomgått endringer siden forprosjektrapporten og prosessen omtalt i punktet over. Elementer er blitt lagt til og noen er fjernet. I utviklingsprosessen har vi vært i dialog med oppdragsgiver en rekke ganger og oppdragsgiver har hatt sine ønsker rundt design og innhold som har gjort at kravspesifikasjonen har endret seg underveis. Dialogen med oppdragsgiver samt utfordringer vi har møtt under utviklingen av prosjektet har gjort at vi har landet på en endelig kravspesifikasjon Samsvar med kravspesifikasjon Produktet vårt sammenliknet med kravspesifikasjonen viser at vi i stor grad har lykkes med å utvikle produktet oppdragsgiver ønsket. 6.2 Avvik fra kravspesifikasjon Ikke-oppfylte krav Det finnes krav i den opprinnelige kravspesifikasjonen som burde eller kunne vært med i den endelige kravspesifikasjonen. Disse kravene listes opp under Krav som burde vært med - Systemet skal kunne endre eller slette informasjon på siden - Systemet skal ha en søkemotor hvor verdier som lokalitet, pris, areal, ant rom kan søkes etter 39

40 Krav som kunne vært med - Systemet skal gjøre det slik at administrator bare trenger å legge ut prospektene én gang for publisering på nettside og finn.no - Systemet kan dele prospekter på sosiale medier som Facebook - Systemet skal være klart til å ekspandere med en egen avdelingsside for Oslo 7 Konklusjon Prosjektet har vært meget utfordrende og spennende for oss. Vi har fått prøve oss i et prosjekt som er av et mye større omfang enn noen av oss tidligere har vært borte i. Det å få bruke kunnskapen vi har tilegnet oss gjennom tre år på HiOA har vært givende, men samtidig utfordrende. Vi har oppdaget nytten av å bruke ulike diagrammer, prototyper, systemutviklingsmetoder og ulike designprinsipper. Vi har fått erfare at det er utfordrende å estimere tidsbruk og omfang av arbeidsoppgaver, noe som har gjort vi ikke alltid har klart å fullføre sprintene våre til tiden. Dette har vært en nyttig erfaring for oss og det viser at det som kan virke enkelt i teorien kan være mer utfordrende å gjennomføre i praksis. Da vi startet på prosjektet hadde vi de største rammene klare, men det var samtidig en del løse tråder som måtte samles. Gjennom å utarbeide en arbeids- og fremdriftsplan hadde vi en tanke om tidsbruk, men denne måtte fravikes i løpet av prosjektets fremgang. Allikevel føler vi at vi klarte å tilpasse oss etter hvert ved å ta i bruk andre estimeringsmetoder, noe som gjorde at vi i større grad klarte å holde satte frister. Vi har fått mange nye erfaringer gjennom prosjektet, og om vi hadde startet på nytt er det nok noen ting vi ville gjort annerledes. Vi ville blant annet brukt litt mindre tid på planlegging og tidsestimering i starten. Samtidig ville vi gjort bedre research rundt publiseringsverktøy allerede fra starten. Samtidig er vi fornøyde med valgene vi tok rundt bruken av Twitter Bootstrap og den generelle progresjonen i prosjektet. Alt i alt er vi godt fornøyde med prosjektet vi leverer videre til oppdragsgiver og vi håper og tror at det vil være nyttig for Meglerhuset Bjerke i mange år fremover. 40

41 8 Referanser https://wordpress.org/about/ https://filezilla-project.org/client_features.php https://www.dropbox.com/about https://www.scrum.org/portals/0/documents/scrum%20guides/scrum%20guide%20- %20NO.pdf#zoom=

42 9 Vedlegg Her har vi lagt ved diverse dokumenter som er relevante. 9.1 Styringsdokumenter Arbeidsplan Frist: Hva: Beskrivelse: Statusrapport. En beskrivelse om hva vi har gjort for å få tak i oppdragsgiver frem til denne datoen, samt informasjon om gruppen Prosjektskisse. Beskrivelse av prosjektet vi har valgt. Skolen skal godkjenne prosjektet ut fra dette Forprosjekt. Et prosjektstyringsdokument der vi definerer prosjektet, setter rammer, og planlegger arbeid fremmover Analyse av eksisterende nettside. Analyser den nettsiden de bruker i dag, hva er bra, hva er dårlig. Brukerundersøkelse o.l utført Sitemap Lage struktur for informasjon på nettsiden. Finne ut hva vi skal ha med på siden av informasjon, og hvordan vi vil skal organiseres Skisser/ Wireframes. Komme med skisser som viser hvordan vi tenker at siden skal se ut. Brukerundersøkelse o.l utført Prototype. Utarbeide en avansert prototype i photoshop som gir gode retningslinjer hvordan designet skal være, slik at vi kan komme igang med programering av siden Første utkast av nettsiden. Skal kunne gjenkjennes fra prototypen (i første omgang konsentrere oss om fundamentet) Andre utkast av nettsiden. Fundamentet skal være ferdig og implementeringen av interne funksjoner skal settes igang. 42

43 Implementere interne funksjoner. Interne funksjoner som søkefunksjon, visning av prospekter o.l Første versjon av administratorsiden ferdigstilt Andre versjon av administratorsiden ferdig. Skal kunne legge inn noe informasjon på hovedsiden via admin-siden. Administratorsiden skal være oppe å gå, skal fungere optimalt Tredjeparts-systemer implementert. Tredjeparts-systemer fungerer i nettsiden All implementering ferdig. Alt av funksjonalitet skal være ferdigstilt, og siden skal fungere Testing. Ulike metoder for testing skal være utført Prosjektrapport levert. Ferdigstilt og legges ut både på gruppenettsiden og i papir-form Presentasjon av prosjektet. Vi skal presentere prosjektet. 9.2 Konkurrenter Hvem er konkurrentene i: Hedmark/Oppland Oslo

44 Utenlandske Hva gjør konkurrentene? Hva er forskjellene mellom hver konkurrent? 44

45 9.3.1 Eiendomsmegler1 Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Annet Bolig, nybygg, fritid, tomt og næring. - God skalering. Gir ulik design etter ulik oppløsning for å passe til andre plattformer. Et pluss da det krever to ulike design som brukes ulikt. - Nettsiden er brutt opp i linjer som går over hele skjermen og ikke "bokser" med klarering på sidene. Bruker skjermen til hva den er verdt. - Sentrale funksjoner som kjøp, salg og meglere er sentralt og kommer tydelig frem. Norge Disse driver ikke med utleie, bare kjøp og salg av mange type leiligheter. Absolutt et forbildet for en god nettside Aktiv Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Annet Tilbyr tjenester innen salg og kjøp av bolig og fritidseiendom, verdivurdering, utleievirksomhet, prosjektmegling og næringsmegling. Norge Endrer design for ulike plattform ettersom det er ulike behov. Menyen er fast til toppen. Følger deg når du scroller. Dog litt dårlige meny-valg. Jevn flyt av informasjon nedover på et skjermbidet og ikke i dybden av nettsiden. God skalering, men dårligere enn eiendomsmegler1. Tanken bak designet og struktur er god, men dårlig gjennomført. Mangler noe i designet som gjør det fullkomment og Krogsveen Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Bolig, fritid, næring, nybygg og tomt. Norge Skalerer og endrer design. Ikke optimal skalering. Tydelig hvilken funksjoner som nettsiden vil at brukeren skal utnytte. Finne megler, verdivurdering og søk eiendom. God visning av leiligheter på forsiden. Skalerer seg og fra javascript til enklere visning ved lavere oppløsning. 45

46 Annet Selve designet er fint, funksjonene funker så som så Obos Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Annet Kjøp og salg av boliger. Nybygg og annet. Skalerer seg ikke, men har egen applikasjon til andre plattformer. Mer oversiktlig og ryddig. Har veldig mye informasjon på nettsiden. Klare skiller mellom tekstvinduer, bakgrunn og menyer. Myk kontrast og klare symboler/knapper. Norge, ikke hedmark. Litt feil å se mot dem da de retter seg mot medlemmer og frister med forkjøpsrett, men grunnprinsippene er de samme Eie Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Annet Kjøp, salg, leie av boliger, fritid, nybygg Oslo Veldig scriptete. Sitter igjen med en falsk følelse.som om jeg har kjøpt meg en "Khanel"-veske til ,- istedenfor en ekte "Chanel"- veske. Veldig mange menyvalg. Veldig mørkt design. Føler at det er veldig tidlig 2000-design og at det ikke er en nettside å hente inspirasjon fra Sem-Johnsen Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Boliger, fritid, nybygg og tomter. Oslo Stilfull nettside. Enkel, men med grunnleggende gode funksjoner. Bestill prospekter og last ned budskjema-funksjon!!! Menyen låser seg fast på toppen av vinduet ved scrolling. 46

47 Annet Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Annet Enkel og grei meglernettside. God inspirasjonskilde. Bolig, fritid. Salg, kjøp og leie Oslo Mye informasjon på samme side, all informasjon på samme side slik at man må scrolle. Ser litt kladdette ut, men det er godt tenkt. Veldig mørkt design. Kan hente inspirasjon fra denne siden, men heller unngå de "feil" vi finner Foss & Co Hvem Hvor ligger fokus: Hva skiller seg ut Boliger, fritid og tomt. Ryddig nettside Det virker som det er veldig mye informasjon på nettsiden, men det viser seg at det bare er mye informasjon på forsiden. Og at det egentlig ikke ligger så mye ekstra informasjon i "bakgrunn". Alt er tilgjengelig foran brukeren av funksjoner. Negativt at det kan bli litt mye. Hvor holder de til Annet Oslo og omegn Ryddig nettside som viser litt for mye informasjon på index. Designet er godt og symbolikk og funksjoner er logiske Wahl Eiendom Hvem Hvor ligger fokus: Hva skiller seg ut Kontorlokaler, næringseiendommer og boliger. Ryddig nettside Helt greit design. Hvor holder de til Oslo og omegn 47

48 Annet Helt grei nettside, men lite informasjon. Er bygd litt opp på at det skal være mye informasjon, uten at de trenger det AkershusEiendom Hvem Hvor ligger fokus: Hva skiller seg ut Næringseiendommer All informasjon på samme side, scroller seg nedover. Hashtagger som menyvalg. Veldig stor meny/banner, selve informasjonen kommer ikke godt nok fram. Veldig bra søkefunksjon med eiendommene!!! Hvor holder de til Annet Akershus Informasjon på samme side. Scroller nedover for informasjon og ikke inn i hierarkiet. Flat struktur kan man kalle det NE Hvem Hvor ligger fokus: Hva skiller seg ut Hvor holder de til Annet Lokaler til salg og leie. Norge Menyene holder seg på høyresiden. Gir mer bokfølelse. Mye tekst inne på nettsiden som er koblet til lokale menyer. Globale menyene er overordnet og gode. Få globale menyer.!!! Er kanskje ikke et eiendomsmegler-firma, men arbeider med temaet og er derfor aktuell for oss. Generelt en enkel nettside, men ryddig og funker til sitt formål. Heller ikke utdatert eller stygg i design HomeEiendom Hvem Hvor ligger fokus: Hva skiller seg ut Boliger, fritid, hytter, næring o.l Fint design med scrolling nedover på samme side. Søksfunksjonen er på egen del av nettsiden. 48

49 Ingen skalering. Hvor holder de til Annet Oslo, Bergen En fin inspirasjonskilde til hvordan man kan skape en nettside med informasjon på samme side. Det er ikke veldig mye informasjon der, bare det mest interessante som omhandler kjøp, salg og megler. 9.4 Konklusjon: Det er ikke mange som driver så bredt som det Meglerhuset gjør mtp tjenester innen megling. De fleste holder seg til salg og ikke utleie, noen driver bare med næring o.l. Utifra konkurrentenes nettside er det en klar oppfattning av at det er tre funksjoner som er svært sentrale: Kjøpe eiendom Selge eiendom Finne megler Her kan det også legges til utleie eller andre tjenester hvis det finnes nødvendig. Disse funksjonene er hva en bruker som går inn på en eiendomsmeglernettsider vil utnytte. Kjøpe eiendom har gallerivisning av prospektene slik at dette funker som en "windowshopping" for de som bare vil titte. Selve designet er veldig variert, både kvalitetsmessig og stilmessig. Man har de klassiske nettsiden med dyp struktur, ofte slik at man må trykke seg både 3 og 4 ganger for å komme inn til en viss informasjon. Du har også en moderne og mer trendy design hvor man har flat struktur og man utnytter plassen nedover i stedet, ved å scrolle. Dette gjør at man ikke mister oversikten da man vha hash-funksjon som gjør at du aldri loader nettsiden på nytt, men blir "dyttet" ned til menyvalget. Det er og noen sider som har kombinert de to over da dem ikke har like mye informasjon å formidle og det ikke er nyttig å bruke denne teknikken. 49

50 9.5 Prosjektskisse Hovedprosjekt i anvendt datateknologi våren 2014 Prosjektskisse Oslo Gruppe 20 Gruppemedlemmer: Navn Studentnummer Telefonnummer Matias Pettersen S Snorre Duun Strømsborg s mail.com Torbjørn Gjøn s Meglerhusets "rinnovasjon" (renovasjon og innovasjon) Oppdragsgiver Meglerhuset Bjerke A/S - Navn Stilling Telefonnummer Mona Bjerke Daglig Leder / Megler Kort presentasjon av oppdragsgiver Meglerhuset Bjerke AS (tidligere Mona Bjerke AS) er et frittstående eiendomsmeglerfirma etablert i De selger hovedsakelig boligeiendommer, men deres tjenester omfatter også salg av fritids-, landbruks- og næringseiendommer. Hovedkontoret er i Elverum. Hovedsaklig går det i eiendommer i Hedmark og Oslo, men også ellers i landet, samt utlandet. Prosjektets plass i oppdragsgivers virksomhet Meglerhuset Bjerke AS har ytret et ønske om å forbedre den nåværende siden. Nettsiden står svært sentralt i virksomheten og oppdragsgiver ønsker en større utnyttelse av nettsiden. Det blir nesten daglig lagt ut eiendommer på nettsiden. Beskrivelse av prosjektet Vi har planer om å renovere nettsiden til Meglerhuset Bjerke AS samtidig som vi vil ta en nærmere titt på muligheten til innovasjon innenfor markedsføring over web. Slik nettsiden er idag representerer den ikke Meglerhuset AS på en god måte. Meglerhuset har også planer om å få flere avdelinger, så å finne en 50

51 god måte å presentere alle avdelingene sammen og hver for seg er viktig. Vi vil også se på problemer i bransjen som kan gjøres bedre, ved at innvandrere sliter med å få leid leiligheter pga sitt navn o.l. Krav Selvom ikke alle kravene er satt, har vi sett for oss noen krav til nettsiden: Ha et godt design, god gjennomføring av brukertesting og prototyping av design. Universelt ufromet. God visualisering av alle prospekter med mulighet for filtrering. Lage en administrasjonsdel, hvor bedriften selv kan legge ut, redigere eller fjerne innhold på en enkel måte. Interaksjon mellom nettside og sosiale medier. 10 Rutiner Her kommer rutiner som må følges av hver enkelt gruppemedlem. OnTime SCRUM(https://meglerhuset.ontimenow.com/ ) Dette er retningslinjer for softwaret OnTime SCRUM 1. Før du starter en arbeidsoppgave(user story) må dette oppdateres i softwaret OnTime SCRUM. Pass på følgende: 1. Ta alltid arbeidsoppgave fra den siste sprint-releasen. 2. Oppdater nye arbeidsoppgaver(user story) til approved/rejected. 3. Starter man på en arbeidsoppgave, oppdater den til "in progress". 1. Pass på at du fyller inn brukte timer etter du er ferdig med arbeidsøkten. Rutiner for selve arbeidsmetoden SCRUM. 1. På starten av hver samling skal følgende punkter gås fort igjennom (maks 5 min) 1. Hva har du gjort siden sist gang? 2. Hva skal du gjøre idag? 3. Er det møtt på noen hindringer? Hvis det er møtt på noe hindringer skal det avtales møte med SCRUM-master og de som er innblandet slik at problemet blir håndtert med full fokus på problemet. 2. Sprinten varer i 2 uker. Tirsdag startet den første sprinten. Før sprinten avsluttes skal følgende gjøres i ish denne rekkefølgen: Del 1: Hva vil bli levert i denne Sprinten? 1. Sprint backlog: Opprette Sprint kø til neste sprint. Hvilket arbeidsoppgaver(user story) skal gjøres. Prioriteringsliste av dette. Felles forståelse av hva som skal gjøres i sprinten. 51

52 (http://en.wikipedia.org/wiki/planning_poker) 2. Sprint mål: Lage utkast til Sprintmålet. Sprintmålet er hovedformålet med sprinten og vil gi teamet en god veiledning. Del 2: Hvilket arbeid er nødvendig for å lage dette inkrementet? 3. Sprint backlogen brytes opp: Hvordan skal vi realisere dette i et "ferdig" produktinkrement. Arbeidet for de første dagene av Sprinten brytes opp i små enheter, ideelt sett èn dag eller mindre. Selvorganisert hva arbeid som gjøres, så lenge det er planlagt gjennom hele sprinten. 4. Forklare selvorganisering: Slutten av møtet går til å forklare hva som er planlagt å bli gjort gjennom hele sprinten fra hver enkel gruppemedlem. Del 3: Evaluering av forrige sprint. 5. Sprint review: Demonstrere inkrementet som er blitt laget til interessenter. 6. Sprintrefleksjon: Erfaringer, hva har vi lært av det vi har gjort? Hva kan gjøres bedre? Estimering: Arbeid som varer 1 dag skal deles opp i: 1,2,4, 8 timer. Arbeid som varer lenger blir delt opp i: 2 dager, 3 dager, 5 dager og 10 dager. Arbeid som varer lenger blir delt opp i: 1 mnd, 2 mnd, 3 mnd og 6 mnd. 52

53 11 Skisser Figur 8: Skisse Figur 1 9: Skisse 2 53

54 Figur 10: Skisse 3 54

55 12 Prototyper 55

56 56

57 57

58 58

59 2014 Hovedprosjekt 2014 Gruppe 20 Kravspesifikasjon Meglerhuset Bjerke AS [Torbjørn Gjøn Snorre Duun Strømsborg Matias Pettersen] 59

60 1 Presentasjon 3.1 Innledning Dette er et prosjekt som er utviklet ved Høgskolen i Oslo og Akershus ved avdelingen Teknologi, Kunst og Design, studiet Anvendt Datateknologi. Prosjektet er utviklet i samarbeid med Meglerhuset Bjerke. Prosjektet har gått ut på å utvikle en brukernettside og en administrasjonsnettside for bedriften. Brukernettsiden skal inneholde informasjon om bedriften, om salgsmuligheter, visning av prospekter og kontaktinformasjon. Administrasjonssiden skal gi mulighet for å legge ut nye prospekter på brukernettsiden, samt deaktivere disse og legge til bilder til prospektene. 1.2 Om bedriften Meglerhuset Bjerke A/S er et frittstående eiendomsmeglerfirma som ble etablert i De tilbyr tjenester som omfatter utleie, salg og kjøp for kunder av fritids-, landbruks- og næringseiendommer i hele Norge, i tillegg til noen eiendommer i utlandet. 1.3 Situasjonen ved oppstart Meglerhuset Bjerke har en nettside som de opplever som utdatert og de trenger noe nytt. Deres oppdragsmengde tilsier at blir det lagt ut 8-10 nye eiendomsobjekter hver måned. Disse objektene blir ikke lagt ut på den eksisterende nettsiden, det linkes kun rett til finn.no når man ønsker å se på boliger. 1.4 Hensikten med produktet Hensikten med å utvikle produktet er at Meglerhuset Bjerke har ambisjoner om å øke sin markedsandel, og de ønsker hjelp til å utvikle en ny nettside som legger godt grunnlag for økt kundemasse. De ønsker å fremstå som profesjonelle og konkurransedyktige, og en god nettside er et viktig for å markedsføre bedriften på en god måte. 60

61 2 Forord Denne kravspesifikasjonen beskriver de endelige betingelsene for prosjektet. Noen hovedkrav er gitt av Meglerhuset Bjerke, men mange av kravene er blitt utformet av prosjektgruppen. Disse ble først utformet i forprosjektrapporten, og senere endret noe underveis i prosjektarbeidet. 61

62 Innholdsfortegnelse 1 Presentasjon Innledning Om bedriften Situasjonen ved oppstart Hensikten med produktet Forord Hvordan kravspesifikasjonen er organisert Funksjonelle krav brukernettsiden Systemet skal på forsiden kunne vise informasjon om følgende Systemet skal på salgssiden kunne vise informasjon om følgende Systemet skal på kjøpssiden kunne vise informasjon om følgende Systemet skal på prospektsiden kunne vise informasjon om følgende Systemet skal på siden "om oss" kunne vise informasjon om følgende Ikke-funksjonelle krav brukernettsiden Produktkrav Organisasjonelle krav Eksterne krav Funksjonelle krav administrasjonssiden Systemet skal på "Legg til prospekt"siden kunne vise følgende inputfelter Systemet skal på "Deaktiver prospekt" siden kunne vise følgende informasjon Systemet skal på "Last opp bilder" siden kunne vise følgende informasjon Ikke-funksjonelle krav administrasjonssiden Produktkrav: Organisasjonelle krav Ikke-oppfylte krav Krav som burde vært med Krav som kunne vært med Sikkerhet Krav til dokumentasjon

63 3 Hvordan kravspesifikasjonen er organisert Kravspesifikasjonen er organisert med funksjonelle og ikke-funksjonelle krav, og underkategorier til de ikke-funksjonelle kravene. Både de funksjonelle og ikke-funksjonelle kravene til brukersiden blir presentert før kravene til administrasjonssiden preseneteres i denne delen av rapporten. 3.1 Funksjonelle krav brukernettsiden - Systemet skal kunne presentere alle prospekter på kjøpssiden - Systemet skal kunne ha et bildegalleri på kjøpssiden - Systemet skal kunne vise kontaktinformasjon på alle sider - Systemet skal kunne ha en link til bedriftens Facebookside på alle sider - Systemet skal kunne ha en "bread crumbs" som viser hvor du er. - Systemet skal kunne linke til prospektet på finn.no fra prospektsiden - Systemet skal kunne øke skriftstørrelsen - Systemet skal kunne dele prospekter på Facebook Systemet skal på forsiden kunne vise informasjon om følgende - Kort informasjon om Meglerhuset Bjerke - Verdivurdering - Kontaktinformasjon - Salg - Kjøp - Medarbeidere Systemet skal på salgssiden kunne vise informasjon om følgende - Kort om Meglerhuset Bjerke - Hvorfor velge Meglerhuset Bjerke - Verdivurdering - Våre tanker rundt bolighandel 63

64 3.1.3 Systemet skal på kjøpssiden kunne vise informasjon om følgende - Adresse på prospektet - Prisantydning på prospektet - Antall kvadratmeter - Type bolig - Eieform - Antall rom - Antall soverom - Bilder av prospektet Systemet skal på prospektsiden kunne vise informasjon om følgende - Navn på området/by boligen ligger i - Kort beskrivelse av området - Kontaktlink - Meglers navn - Meglers telefonnummer - Meglers mobilnummer - Meglers faxnummer - Meglers e-postadresse - Bilde av megler - Adresse - Pris - Antall kvadratmeter - Boligtype - Type eierskap - Antall rom - Antall soverom - Prisdetaljer - Omkostninger 64

65 - Areal og byggeår - Fasiliteter - Beliggenhet og adkomst - Nærområdet - Type, eierform og byggeår - Bygninger og byggemåte - Antall rom (evt senger) - Arealer og fordeling pr etasje - Møblering / utstyr - Standard - Oppvarming - Parkering - Areal og eierform (opplysninger om eventuelt feste) - Tomt og hage - Vei, vann og avløp - Tinglyste rettigheter og servitutter - Prisantydning - Takst / tilstandsrapport - Energiforbruk og energimerking - Forsikring - Kommunale avgifter - Leieinntekter - Oppgjør - Eierskifteforsikring - Arealangivelser i salgsoppgaven - Andre opplysninger - Budgivning - Overtakelse - Solgt som den er - Lov om hvitvasking 65

66 3.1.5 Systemet skal på siden "om oss" kunne vise informasjon om følgende - Om oss - Tilgjengelighet - Forståelse - Medarbeidere - Telefonnummer - E-post adresse - Link til Facebook 3.2 Ikke-funksjonelle krav brukernettsiden Siden skal tilfredsstille en rekke ikke-funksjonelle krav. Disse kravene er listet opp i ulike kategorier Produktkrav - Systemet skal skalere til ulike plattformer - PC, nettbrett, mobil - Språket skal være norsk - Logoen skal vises på alle sider - Systemet skal ha gjenkjennelige farger etter ønske fra oppdragsgiver; svart, gull og hvitt - Siden skal være selvforklarende i bruk - Knappene skal være plassert horisontalt i en global meny - Tegnkoding skal være satt til UTF - Footer skal være konstant - Header skal bli mindre når man blar nedover på siden - Systemet skal kun laste innholdet i wrapper, resten skal være konstant - Systemet skal aldri ha mer enn tre lag totalt i hierarkiet. 66

67 3.2.2 Organisasjonelle krav - Det skal føres logg over hva som er blitt gjort - Det ferdige produktet skal dokumenteres gjennom følgende dokumenter: - Prosessrapport - Produktdokumentasjon - Kravspesifikasjon - Brukerdokumentasjon Eksterne krav Siden skal følge $14 i diskriminerirngs- og tilgjengelighetsloven (universell utforming) Ikke-tekstlig innhold - Alt ikke-tekstlig innhold som presenteres for brukeren, har et tekstalternativ som har samme formål(f.eks. beskrive et bilde med tekst) Meningsfylt rekkefølge - Når rekkefølgen som innholdet presenteres i, påvirker meningsinnholdet, kan en korrekt leserekkefølge bestemmes programmeringsmessig Bruk av farge - Farge blir ikke benyttet som det eneste visuelle virkemiddelet for å formidle informasjon, angi en handling, be om respons eller skille ut et visuelt element Kontrast (minimum) - Den visuelle presentasjonen av tekst og bilder av tekst har et kontrastforhold på minst 4.5:1, unntatt i noen få tilfeller Endring av tekststørrelse - Med unntak av teksting og bilder av tekst kan tekst forstørres opp til 200 % uten bruk av kompenserende teknologi og uten at innhold eller funksjonalitet går tapt Tastatur - All funksjonalitet i innholdet kan betjenes via et tastaturgrensesnitt uten at det er behov for tidsberegning av de enkelte tastetrykkene, unntatt hvis den underliggende funksjonen krever inndata som er avhengige av rekkefølgen på brukerens bevegelser, og ikke bare av sluttpunktene Ingen tastaturfelle - Hvis tastaturfokus kan flyttes til en av komponentene på siden ved hjelp av et tastaturgrensesnitt, kan fokus flyttes fra den aktuelle komponenten bare ved hjelp av tastaturgrensesnittet. Hvis det er behov for noe annet enn standard pil- eller tabulatortaster eller 67

68 andre standardmetoder for navigering, får brukeren informasjon om hvilken metode som må benyttes for å flytte fokus Terskelverdi på maksimalt tre glimt - Websider har ikke innhold som glimter mer enn tre ganger i løpet av ett sekund, eller glimt er innenfor terskelverdiene for generelle glimt og røde glimt Sidetitler - Websider har titler som beskriver den aktuelle sidens emne eller formål Fokusrekkefølge - Hvis en webside kan navigeres sekvensielt og navigeringssekvensen påvirker betydning eller betjening, får fokuserbare komponenter fokus i en rekkefølge som ivaretar betydningen og betjeningen Formål med lenke (i kontekst) - Formålet med hver lenke kan fastslås ut fra bare selve lenken eller ut fra lenketeksten kombinert med programmeringsmessig bestemt lenkekontekst Flere måter - Det finnes mer enn én måte å finne frem til en webside på innenfor et sett av websider. Unntaket er hvis websiden utgjør resultatet av, eller et trinn i, en prosess Synlig fokus - Tastaturbetjente brukergrensesnitt har en betjeningsmodus der fokusindikatoren for tastaturet er synlig Fokus - Når en komponent kommer i fokus, medfører det ikke kontekstendring Konsekvent navigering - Navigeringsmekanismer som gjentas på flere websider innenfor et sett av websider, opptrer i samme relative rekkefølge hver gang de gjentas, med mindre brukeren selv foretar en endring Konsekvent identifikasjon - Komponenter som har samme funksjonalitet innenfor en samling av websider, identifiseres på en konsekvent måte. 68

69 3.3 Funksjonelle krav administrasjonssiden -Systemet skal gi informasjon om hvilken side man er På Systemet skal på "Legg til prospekt"siden kunne vise følgende inputfelter - Tittel - Visningsdato - Verditakst - Lånetakst - Kommunale avgifter - Omkostninger - Bruttoareal - Bruksareal - Tomt - Byggeår - Eierskifteforsikring - Energimerking - Primærrom - Boligtype - Eieform - Antall rom - Soverom - Gateadresse - Postnummer - Poststed - Tilleggsinformasjon - Megler - Finn.no-lenke - Opplastningsknapp 69

70 3.3.2 Systemet skal på "Deaktiver prospekt" siden kunne vise følgende informasjon - Alle prospekter som er lagt ut - En knapp for å deaktivere et prospekt Systemet skal på "Last opp bilder" siden kunne vise følgende informasjon - Meny med alle prospekter - Knapp for å laste opp bilde - Tekstboks - Opplastningsknapp 3.4 Ikke-funksjonelle krav administrasjonssiden Administrasjonssiden skal tilfredsstille en rekke ikke-funksjonelle krav. Disse kravene er listet opp i ulike kategorier Produktkrav: - Administrator skal kunne legge til et prospekt - Administrator skal kunne skjule et prospekt(deaktivere) - Administrator skal kunne legge ut bilde til prospektet - Systemet skal ha samme design som brukernettsiden - Språket skal være norsk - Knappene skal være plassert i en horisontal meny - Systemet skal ved tekst vise at du er på administrasjonssiden av systemet - Data skal lagres i en MS-SQL-database - Kun personer med korrekt brukernavn og passord skal kunne aksessere administrasjonssiden - Det skal stå forklarende tekst i alle inputfelter - Systemet skal vise en loginknapp til administrasjonssiden i footer 70

71 3.4.2 Organisasjonelle krav - Administrasjonssiden skal være programmert i HTML og objektorientert PHP - Siden skal styles med CSS 3.5 Ikke-oppfylte krav Det finnes krav i den opprinnelige kravspesifikasjonen som burde eller kunne vært med i den endelige kravspesifikasjonen. Disse kravene listes opp under Krav som burde vært med - Systemet skal kunne endre eller slette informasjon på siden - Systemet skal ha en søkemotor hvor verdier som lokalitet, pris, areal, ant rom kan søkes etter Krav som kunne vært med - Systemet skal gjøre det slik at administrator bare trenger å legge ut prospektene èn gang for publisering på nettside og finn.no - Systemet kan dele prospekter på sosiale medier som Facebook - Systemet skal være klart til å ekspandere med en egen avdelingsside for Oslo 3.6 Sikkerhet Det kreves innlogging til administrasjonssiden. Dette kreves for at ikke uvedkommende skal kunne opprette, endre eller slette prospekter. Produktet lagres på et webhotell hos Pro ISP. Her trenger man brukernavn og passord for å logge inn, slik at ikke uvedkommende får tilgang til webhotellet og da også koden som er blitt konstruert for å lage produktet. 71

72 3.7 Krav til dokumentasjon Det skal føres logg over hva som er blitt gjort. Her skal også utfordringer vi har støtt på underveis beskrives. Hvordan vi har løst utfordringene, eller hvordan vi har tenkt til å løse disse skal også beskrives her. Dette er gjort i prosjektdagboken vi har ført igjennom prosjektet. Det ferdige prosjektet skal dokumenteres gjennom følgende dokumenter: - Prosessrapport - Produktdokumentasjon - Kravspesifikasjon - Brukermanual 72

73 73

74 2014 Hovedprosjekt 2014 Gruppe 20 Produktdokumentasjon Meglerhuset Bjerke AS [Torbjørn Gjøn Snorre Duun Strømsborg Matias Pettersen] 74

75 1 Forord Produktdokumentasjonen er tiltenkt de som skal vedlikeholde, videreutvikle og oppdatere nettsiden. Produktdokumentasjonen gir en dypere beskrivelse av nettsiden generelt, oppbygning av koder og enkelt elementer. Denne rapporten er skrevet for utviklere og datakyndige, derfor trenger man generelle kunnskaper om HTML, CSS, JavaScript og PHP for å få fullt utbytte av rapporten. 75

76 Innholdsliste 1 Forord Beskrivelse av teknologi og rammeverk Språk HTML CSS PHP Javascript jquery Bootstrap Responsive design Scaffolding/Grid-systemet Hvordan har vi brukt Twitter Bootstrap 3.0? Beskrivelse av nettsiden Forsiden Navigasjon Navigasjonsmeny Knapper Breadcrumbs Customized fontsize Skalering Footer Salg- og Kontakt-siden Kjøp-siden Rammeverket for søkefunksjonen Visning av flere prospekter Prospekt-siden Nøkkelinformasjon til hvert prospekt Carousel/Galleri

77 3.6.3 Liste av tekst Oppbygning av kode Generell oppbygning Kommentering Index.php PHP-include Navigasjon Hoover Fra nettleser til mobil-plattform Javascript for logo Carousel Carousel-controller Carousel-caption Jumbotron Breadcrumb Font-size Content-left Knapper Fixed nøkkelinformasjon til prospekt.php Fixed nøkkelinformasjon til prospekt.php mobilversjon Kontakt oss Administrasjonssiden Om administrasjonssiden Sider og mapper tilknyttet administrasjonssiden Adminpanel.php Deaktiver-prospekt.php Nytt-prospekt.php Takelogin.php Upload-images.php vis-prospekt.php Mappen «Klasse» Mappen «Funksjoner»

78 5.3 Generell informajson KILDER: VEDLEGG: Vedlegg 1 - Use Case diagram for løsning Vedlegg 2 - Aktivitetsdiagram opprett prospekt Vedlegg 3 - Aktivitetsdiagram Se detaljert prospekt Vedlegg 4 - Aktivitetsdiagram last opp bildet Vedlegg 5 - Aktivitetsdiagram deaktiver prospekt Vedlegg 6 - Aktivitetsdiagram logg inn til administrasjon Vedlegg 7 ER-doagram for database

79 2 Beskrivelse av teknologi og rammeverk 2.1 Språk HTML5 HTML5 brukes for å strukturere og presentere innholdet for The World Wide Web og er en kjerne teknologi av internett. Fra desember 2012 er HTML5 en candidate recommendation of the World Wide Web Consortium(W3C). Dette betyr at W3C anerkjenner HTML5 som en standard CSS3 Cascading Style Sheets er et stilark brukt for å beskrive designet og formatet av HTML-dokumenter. Stilarket kan lenkes til uttallige dokumenter, som er en av fordelene til CSS. CSS3 inneholder det gamle CSS-spesifikasjonene, samtidig som den inkluderer mange nye moduler PHP PHP er et dynamisk, tolket og løst typet programmeringsspråk hovedsakelig brukt for å utvikle dynamiske nettsider Javascript JavaScript brukes for å tilføre dynamiske elementer til nettsider. Det blir vanligvis brukt for å tillate implementering av klientskripting for å interagere med brukeren, kontrollere nettleser o.l. 79

80 2.1.5 jquery jquery er et JavaScript-bibliotek utviklet for å forenkle klientskripting av HTML og er det mest populære biblioteket i bruk. Jquery syntaksen er laget for å gjøre det lettere å navigere et dokument, behandle hendelser, opprette animasjoner o.l. Det er også mulig for utviklere å lage programvareutvidelser til i biblioteket. 2.2 Bootstrap Twitter Bootstrap 3.0 er et gratis front-end rammeverk for å lage websider og webapplikasjoner. Rammeverket består av HTML og CSS-baserte design templates for interaksjonskomponententer og grid-systemer som nettsiden er bygget opp på. Per mars 2014 er Twitter Bootstrap 3.0 det mest populære prosjektet ved GitHub og har vært det siden februar For å bruke Twitter Bootstrap må man laste ned Bootstrap CSS stylesheet og inkludere disse i HTMLfilen. Det samme gjelder hvis man vil bruke JavaScript-komponentene, referere i HTML-dokumentet sammen med jquery biblioteket Responsive design Siden Twitter Bootstrap 2.0 har den støttet responsivt design, det vil si at nettsiden justerer seg dynamisk etter hvilken enhet som brukes (PC, tablet eller smarttelefon). Med tanke på at Bootstrap er open source og tilgjengelig på GitHub blir utviklerene oppmuntret til å legge ut sine bidrag til rammeverket. Dermed får man et stort kvalitetssikret bibliotek med basiskoder. Dette sparer mye tid, det gjør at produktet og hvordan produktet skal se ut er fokuset Scaffolding/Grid-systemet Den største endringen fra Bootstrap 2 til bootstrap 3 er måten gridsystemet var bygget opp på. Bootstrap 2 var rettet mot to forskjelige nettleser-oppløsning, desktop og så mobil. Med Bootstrap 3 bygger man 80

81 først layouten med mobil-størrelsen først, for så å lage forskjellige grid-systemer basert på nettleserens oppløsning. Bootstrap 3 grid systemet har fire klasser: XS, extra small(telefoner, mindre enn 768px) SM, small devices (tablets, 768x og oppover) MD, medium devices (desktops, 992 px og oppover) LG, large devices (store desktops, 1200px og oppover) Ved hjelp av disse klassene kan man kontrollere layouten til nettsiden i henhold til hvilket enhet som brukes til nettsiden. Det er viktig å huske at rekken alltid må opp i 12. Det vil si at du kan ha: MD-4, MD-4, MD-4 = 12 MD-2, MD-6, MD-4 = 12 Eller hvis man ikke vil bruke hele rekken med innhold kan man bruke offset-innstilling som f.eks.: MD-4, MD-4, MD-OFFSET-4 = 12 MD-2, MD-4, MD-OFFSET-6 = Hvordan har vi brukt Twitter Bootstrap 3.0? Slik vi har brukt det har det for det meste hjulpet oss med å posisjonere og kontrollere elementene i nettsiden på en effektiv måte. Ved hjelp av grid-systemet og det responsive designet har vi kunnet ha riktig bredde på alle plattformer vi forventer at nettsiden skal brukes til. Verktøyet lager 4 forskjellige oppløsninger basert på disse enhetene; mobiltelefon, portrait and landscape som betyr hvordan mobilen står da det er forskjellig bredde og høyde, tablets og PC'er med både lav og høy oppløsning. For oss er dette nyttig å bruke, da det skaper tilgjengelighet for nettsiden vår på en enkel og god måte. Twitter bootstrap er også blitt brukt til en rekke funksjoner som: 81

82 Jumbotron (punkt 4.1) Carousel (galleriene) (punkt 4.6.3) Knapper (punkt 4.2.2) Breadcrumbs (punkt 4.2.3) Navigasjonsmeny med dropdown i mobil-størrelse (ipunkt 4.2.5) Opprettelse av rammene til søkefunksjonen (punkt 4.5.1) 3 Beskrivelse av nettsiden 3.1 Forsiden Forsiden er det første brukeren ser når man kommer inn på nettsiden. Her skal alt av informasjon være tilgjengelig. Forsiden skal fungere som en portal hvor all informasjon er "litt" tilgjengelig med mulighet til å navigere seg til mer informasjon ved hjelp av knapper og navigasjonsmeny. Siden er bygget opp med en "jumbotron" på toppen av siden, se figur 1. Dette er for å ha en god "topp" på hver side. En stor tittel med beskrivende tekst for å få forståelse av hva som er på siden og hvor man er. Fra forsiden har du både navigasjonsmenyen som er tilgjengelig til enhver tid samtidig som du har knapper som lenker deg til andre undersider. Hensikten er å ha så mye som mulig tilgjengelig på forsiden. Tilgjengelighet er et nøkkelbegrep for hva som er hensikten med forsiden. Smakebit av prospekter (3-galleri) Kontaktinformasjon m/ facebook-lenke Knapper til alle undersidene (utenom prospekt.php som bare er tilgjengelig via kjop.php) * Knapper til alle undersider er også representert i navigasjonsmenyen. Sett fra brukerens perspektiv har vi tenkt oss ut mulige hensikter som igjen reflekterer hvordan forsiden er bygget opp; 82

83 Brukeren er ute etter å vindu-shoppe etter boliger, derav representert på forsiden: gallerivisning og lenke-knapp til kjop.php Brukeren er ute etter å komme i kontakt med en megler, derav representert på forsiden: kontaktinformasjon og lenke-knapper til omoss.php Figur11: Jumbotron 3.2 Navigasjon Navigasjonsmeny Navigasjonsmenyen er en global meny som brukes til å: Navigere seg rundt på nettsiden Vise logoen Legge til "verktøy" for brukeren, som i dette eksempelet er å endre font-størrelse. Menyen er laget slik at når brukeren scroller seg ned til innholdet av siden, vil logoen justeres fra figur 2 til figur 3. Dette er for å få innholdet av nettsiden bedre fram, da logoen og navigasjonen sammen krever mye plass. Hensikten er å skape oversikt for brukeren i form av at det blir mer skjermplass for innhold. 83

84 Navigasjonsmenyen er dynamisk på to måter: 1. Den justerer seg til å bli mindre eller større i henhold til hvor brukeren har scrollet seg på nettsiden. Er brukeren på toppen, vil hele logoen vises. Scroller brukeren seg litt ned fra toppen vil den bli fixed til toppen slik som den er vist i figur Hvert menyvalg, ved hoover, blir omvendt farge. Altså fra svart bakgrunn med hvit-tekst -> Hoover: hvit bakgrunn med svart tekst. Dette blir gjort gjennom en 'transition' som gjør at overgangen mellom fargene er mer dynamisk. Punkt 2 sin hensikt er å tydelig gi tilbakemelding på hva som holdes over. Dette er til en viss grad blitt konsekvent brukt gjennom nettsiden, men ikke på samme måte da kontrastene er litt ulike i knappene som finnes i innholdet kontra navigasjonsmenyen. Figur 12: Hel logo Figur 13: Justert logo Figur 14: Dynamisk interaksjon ved hoover Knapper Konsekvent gjennom hele nettsiden har vi lagt til mange knapper slik at man skal ha et godt alternativ til navigasjonsmenyen. Dette er for å skape tilgjengelighet for brukeren, og sørge for at det ikke skal være noe problem å komme til "riktig" side hvor informasjonen man søker etter er tilgjengelig. Derfor er det plassert knapper på alle undersider som lenker til alle undersider. 84

85 Vi har laget knappene slik at den er dynamisk i forhold til om den er aktiv eller ikke. Dette gir brukeren til enhver tid tilbakemelding på hva som skjer. Figur 15: Lenke-knapp Figur 16: Aktiv-lenke knapp Breadcrumbs Breadcrumbs navigasjon er et veldig godt hjelpemiddel til å hjelpe brukeren med å finne fram på nettsiden. Den forteller brukeren hvor på nettsiden man er, og hvilken vei man har tatt for å komme til det spesifikke innhold. Som man kan se i figur 7, kan man stegvis gå tilbake de skrittene man har tatt. I forhold til brukervennlighet kan breadcrumbs redusere antall klikk brukeren trenger for å finne fram til ønsket informasjon. Selvom vi ikke har så mange undersider, og det er vanskelig å gå seg "vill", blir det også et visuelt verktøy brukeren har for å holde oversikt. Figur 17: Breadcrumbs 85

86 3.2.4 Customized fontsize Customized fontsize er et tilpassningsverktøy for brukeren som har spesielle behov. Funksjonens mål er å forstørre teksten i 3 størrelser. aa er 16 px aa er 32 px AA er 48px I henhold til universell utforming skal en bruker ha mulighet til å forstørre tekst til 200% av original størrelse uten at innhold eller funksjonalitet skal gå tapt. (http://uu.difi.no/veiledning/suksesskriterier/144-endring-av-tekstst%c3%b8rrelse) Hensikten er å få gjort nettsiden tilgjengjelig for en større brukergruppe. Denne funksjonen er rettet mot de med nedsatt synsevne og lignende. Figur 18: Customized fonsize Skalering Nettsiden skal fungere på ulike plattformer / oppløsninger, derfor må det forandres i layouten for å få alt på plass da oppløsningen blir lav. Dette blir gjort ved at vi har tatt i bruk en bootstrap template av navigasjonsmenyen og tilpasset den nettsiden vår. Hvis nettsiden får vite at enheten som blir brukt er mindre enn 768px blir mobilnavigasjonen forandrer den seg fra figur 2 til figur 9. Dette er mer eller mindre en standardmåte å vise menyen på for mobile enheter som har lav oppløsning. Vi ser det som hensiktsmessig å lage det på denne måten da vi kan anta at brukeren gjenkjenner symbolet for dropdown-menyen. 86

87 Menyvalgene er horisontale istedenfor vertikale Menyvalgene er representert via et 'glyphicon' som er mer eller mindre standard for dropdownmenyer. Hvert menyvalg har lik hoover/active-stil som den "vanlige" menyen. Figur 19: Navigasjon I mobilstørrelse Figur 20: Navigasjon I mobilstørrelse med dropdown Figur 21: Dropdown med hoover over menyvalg 87

88 3.3 Footer Footeren er en standard footer som er representert på hver underside med følgende innhold: Kontaktinformasjon Facebook-logo med lenke til facebook-siden til Meglerhuset Bjerke Back to top-knapp Hensikten med footeren er tilgjengelighet av vital informasjon. Det skal være enkelt å finne informasjon for å komme i kontakt med Meglerhuset. Facebook-logoen er representert slik at brukeren skal komme i kontakt med de sosiale mediene som brukes av Meglerhuset. Back to top-knappen er laget for de som bruker tastaturet for å gå igjennom nettsiden, eventuelt for normale brukere som ikke vil scrolle seg til toppen. Trykker du på knappen, sendes du til toppen av siden. Figur 22: Footer 3.4 Salg- og Kontakt-siden Salg og kontakt-siden er to undersider som fungerer som rene informasjons-sider. Her finnes det ikke mange funksjoner annet enn intern lenking. Hensikten med sidene er å ha mer detaljert informasjon tilgjengelig og "selge" Meglerhuset til brukerene. Som med alt annet har vi et fokus på at brukeren alltid skal kunne finne informasjonen den trenger fort. Figur 13 viser 'Kontakt oss'-element, dette elementet blir brukt både på kontakt-siden og forsiden. Og skal presentere måter man kan komme i kontakt med Meglerhuset på. 88

89 Figur 23: Kontakt-oss boks 3.5 Kjøp-siden Kjøp-siden er undersiden hvor man skal kunne se på alle prospektene samlet under èn side. Den er bygget opp ved å ha en søkefunksjon, som ikke er funksjonell i skrivende stund, og deretter kommer prospektene på løpende bånd slik den er fremstilt i figur 15. Hvert prospekt bruker hele bredden med en info-boks m/ lenke til en mer detaljert framvisning av prospektet Rammeverket for søkefunksjonen Selvom søkefunksjonen ikke fungerer, har vi bestemt oss for å la den bli et rammeverk slik at det er mulig å legge til en søkefunksjon for prospektene i senere tid. Den er lagt opp etter forskjellige verdier prospekter som legges ut av Meglerhuset har og som gjør at prospektene kan snevres inn logisk. 89

90 Type prospekt (næringsbygg, enebolig, leilighet, tomt) Pris (til fra) Størrelse (til fra) Søk etter ord Figur 24: Rammeverk for søkefunksjon Visning av flere prospekter Under søkefeltet kommer alle prospektene på rader, hvor ett prospekt blir vist per rad. Hvert prospekt inneholder: Galleri med bilder fra prospektet Tittel med adresse på prospekt Nøkkeldetaljer for prospektet Knapp som lenker til detaljert prospekt Hvert prospekt blir vist med disse punktene som standardvisning avskilt med en markert horisontal linje. De nyeste prospektene blir lagt ut på toppen, og de eldste nederst. Hensikten er å gi bruker en enkel presentasjon av flere prospekter, samtidig som muligheten for å trykke seg til en mer detaljert presentasjon av prospektet ligger framme godt synlig. 90

91 Figur 25: Visning av flere prospekter, per prospekt 3.6 Prospekt-siden Prospekt-siden er en unik side for hvert prospekt som blir lagt ut. Prospekt-siden presenterer følgende for hvert prospekt som blir lagt ut: En jumbotron for introduksjon av prospektet Galleri med bilder fra prospektet 2x tabeller med nøkkelinformasjon for hvert prospekt som er fixed position. En liste over andre detaljer, mange punkter. Hensikten med siden er å få presentert viktig informasjon om hvert prospekt til brukeren. Nøkkelinformasjonen er alltid tilgjengelig i feltet til høyre for alle andre elementer, mens brukeren kan scrolle seg ned på mer detaljer om feks bygninger og byggemåte(ref: til listen for detaljer) Nøkkelinformasjon til hvert prospekt Nøkkelinformasjon er generell, men viktig informasjon om hvert prospekt hvor hensikten er at mens brukeren kan lese gjennom detaljene, skal nøkkelinformasjonen alltid være tilgjengelig. Dette er ordnet ved at de to tabellene man kan se i figur 16 bruker en bestemt rekke og har position: fixed med fast margin til topp. 91

92 I mobilversjon vil denne nøkkelinformasjonen ikke være tilgjengelig når brukeren scroller seg gjennom innhold, men plasseres på toppen. Figur 26: Fixed nøkkelinformasjon til prospekt.php Carousel/Galleri Carousel er et ferdig rammeverk for bildefremvisning fra Twitter Bootstrap 3 som er blitt tilpasset nettsiden. Den er delt opp i 3 forskjellige versjoner: 1. Forside- carousel med 3 bilder per "visning". 3X3 bilder. 2. Detaljert prospekt har en carousel med tekst-boks. 92

93 Alle er bygget opp på samme måte, men det er små forskjeller som: Størrelsene på bildene som vises. Punkt 2 har interaksjonsmuligheter med carousel. Punkt 2 har egendefinerte detaljer per bildet. Det har ikke punkt 1. Hensikten med disse forskjellene er følgende: 1. Forside-carouselen er et visuelt hjelpemiddel for å vise hva slags nettside Meglerhuset er. Det er også en "smakebit" for hva av prospekter som finnes. 2. Prospekt-carouselen er "hoved"-carouselen som inneholder alle bilder fra prospektet + beskrivende tekst til hvert bildet. Figur 27: Galleri til prospekt 93

94 I prospekt-carouselen kan brukeren interagere med carouselen ved å selv kunne gå til neste bilde eller tilbake. For å gjøre opplevelsen mer dynamisk og hjemmesiden mer konsistent valgte vi å lage samme hoover effekt som knappene har, ved at fargen endrer seg til orange ved hoover. Meningen er å gi brukeren tilbakemelding for at det skjer noe og at knappen gjør noe. Figur 28: Knapp til galleri ved hoover Liste av tekst Listen av tekst som vises under carousel og ned til footer er punkter over detaljert informasjon for prospektet som er representert. Disse detaljene er lovpålagt og hentet fra finn.no et eksempel er: Disse punktene er faste og vil for hvert prospekt bli lagt ut fra administrator 94

95 4 Oppbygning av kode 4.1 Generell oppbygning Kommentering Kommenteringen gjort i CSS er skrevet over for hvilken underside det gjelder, eller hvilken funksjon det gjelder. For eksempel: /* CSS gjelder Carousel */ Kommenteringen i HTML har vært spesielt mye brukt på avsluttende tagger som har egen klasse. Ellers er det kommentert på hva en "bit" av koden gjør. For eksempel: <div class="row"> </div> <!-- row ferdig --> Kommenteringen i javascript er hva scriptet gjør helhetlig, pseudokoder og hva deler av scriptet gjør. For eksempel: // Funksjon for å skjule logo ved scroling Index.php Index er siden som dukker opp hver gang noen skriver inn lenken monabjerke.no men i realiteten er det forside.php brukeren ser. Indexen includer dermed forside.php, som man kan lese nærmere om i punkt Det index.php inneholder er: meta-tags Lenking til diverse CSS Lenking til scripter (se figur 19) Andre egne scripter plassert nederst i index.php Indexen fungerer som et kontrollpanel som henter inn nødvendig informasjon og skifter ut innhold i body-tagen ved hjelp av php-include. Brukeren er aldri direkte knyttet til index, men index knytter sammen alt for brukeren. 95

96 Figur 29: Script lenking PHP-include PHP-include er en kode-metode som inkluderer filer inn i "hoved"-siden slik at kodene blir mer oppstykket og oversiktelig. I realiteten så vil det si at etter at feks footer.php har blitt inkludert, vil de kodene som er i footer.php bli implementert der include-setningen er. Resultatet blir at flere koder hentet fra forskjellige steder blir implementert til èn stor kode hvor deler av koden kan utskiftes. For eksempel; Man har index.php, header.php, footer.php og forside.php som aktive "koder". Skal brukeren inn på kjop.php så endres bare forside.php hvor inneholdet skifter. Man beholder header, footer og index. Hensikt for bruk: 1. Holder oversikten over kodene som brukes, blir mer logisk oppstykket feks header.php, footer.php, index.php. 2. Endringer blir gjort ett sted som gjelder alle sidene, feks header.php,trenger bare å endres ett sted, men vil gi utslag på alle sider. 96

97 Figur 30: PHP-include Pseudoskode: Hvis $page ikke finnes, include forside.php. Ellers include id?=$page.php. Første linje finner ut om det er noe id som kan settes inn i $page-variabelen, finnes det ikke noe blir variabelen tom. Hvis variabelen er tom blir forside.php inkludert. Hvis det finnes en id, som feks i navigasjonsbaren referer vi til feks "?id=kjop". Setningen finner id=kjop og inkluderer derfor $page.php som i vårt eksempel er kjop.php Figur 31: PHP-include eksempel 4.2 Navigasjon Navigasjonen er basert på bootstrap sine navigasjonsklasse, men er kraftig modifisert både i CSS og i implementering av javascript Hoover Border-radius gjør at "kantene" på hvert menyvalg blir avrundet, dette ser penere ut enn om de skulle vært firkantet. Når menyvalgene ikke er aktive har de fått hvit tekst, med svart bakgrunn. Blir den aktiv så skifter den farge på teksten til svart og bakgrunnen hvit. Dette gjøres ved hjelp av transition. 97

98 Tekstfargen(ref: color) bruker 0.2 sekunder på å skiftes til motsatt farge, bakgrunnen bruker 1 sekund. Dette kan justeres alt ettersom hvordan man vil ha det i tid. -o-, -ms-, -moz- og -webkit- er lagt til for å få funksjonaliteten tilgjengelig på forskjellige nettlesere. Figur 32: Hoover CSS Fra nettleser til mobil-plattform I figur 23 kan man se funksjonen som sørger for at overgangen og endringen av menyvisningen blir gjort. Toggle Icon: Funksjonen endrer meny-symbolet til glyphicon-align-justify(som man finner i bootstrap sin icon-database) og plasserer menyvalgene i en collapse-menyvisning. Collapse navbar on click of.anchor: Sjekker om vinduet hvor innholdet blir vist er liten nok til at navigasjonsbaren skal endre seg til navigasjonsbar for mobil. Og hvis den finner ut at det er for liten nok plass vil den fjerne og legge til klasse i #nav-collapse. 98

99 Figur 33: Skalering javascript Javascript for logo Funksjonen for å skjule scrolling er basert på javascript som lagrer scrollemengde. Den fungerer slik stegvis: 1. Alltid skjul logo. 2. Finne ut hvor mye av vinduet som er scrollet, lagre dette. 3. Hvis scrollelengde er mer eller lik navbar sin høyde, så viser den logoen. 4. Hvis ikke, skjules logoen som i punkt 1. Seksjonen under sørger for at navbar aldri blir overlappet av body eller anchortarget ved at den dynamisk setter padding mot navbar. 99

100 Figur 34: Javascript for å skjule logo 4.3 Carousel Carouselen, eller galleriet, er basert på bootstrap sin Carousel-class. Koden er kraftig modifisert og blitt brukt på ulike måter. Carousel blir brukt på forside.php og i hvert detaljerte prospekt. Bildene er koblet opp mot hvert prospekt og blir "hentet ut av databasen" og satt inn i carouselene. Carouselen har en javascript-del som sørger for å gi et tidsintervall på når bildene skal slide til neste bildet. I tillegg sikrer denne at overgangen skjer på en dynamisk måte ved at den "slides" og ikke loades på nytt. 100

101 Figur 35: Javascript for Carousel-timer Carousel-controller I detaljerte prospekter kan brukeren selv bruke knapper for å navigere seg til neste eller forrige bildet. Dette er også klasser som er hentet fra bootstrap sitt rammeverk, og er blitt modifisert med CSS i ettertid. Symbolene som viser navigeringen er også hentet ut fra icon-databasen til bootstrap. Data-slide er variabelen som sørger for at neste eller forrige bildet blir hentet og hvert bildet blir presentert i henhold til den nummeriske rekkefølge som er satt for data-slide. Feks: <ol class="carousel-indicators"> <li data-target="#mycarousel" data-slide-to="0" class="active"></li> <li data-target="#mycarousel" data-slide-to="1"></li> <li data-target="#mycarousel" data-slide-to="2"></li> </ol> Koden i eksempelet er hentet fra øverste del av kodesnutten til hver "carousel", knappene er dog bare på detaljerte prospekter. Dette er fordi vi har fjernet navigasjonsmuligheten til forside-carouselen. Figur 36: HTML-kode for carousel-controller 101

102 CSSen sørger for 3 ting: 1. Posisjonerer navigasjonsknappene midt på carouselen. 2. Legger til hoover-effekt, ved at ikonet skifter farge til orange. 3. Setter standard-settings i idle-status. Figur 37: Carousel-controller CSS Carousel-caption Carousel-caption er et tekstvindu som kommer foran bildet i carouselen. Dette er en class fra bootstrap rammeverket, men som er modifisert via CSS. For hvert bildet som blir presentert i carouselen, må det være en "div class carousel-caption". 102

103 Figur 38: HTML-kode for carousel-caption CSS koden gjør 2 ting: 1. Den sørger for at tekstvinduet er transparent slik at man kan se bildet i bakgrunn. Dette er gjort med opacity funksjonen som man selv kan endre på i henhold til hvor transparent tekstvinduet skal være. Det er også sørget for at opacityen er kompatibel med så mange nettlesere som mulig. Det settes også bakgrunnsfarge svart her. 2. Selve teksten blir sentrert og gitt margin. Figur 39: CSS-kode for carousel-caption 4.4 Jumbotron Jumbotron er en klasse fra bootstrap sitt rammeverk som vi har brukt konsekvent i toppen av nettsider som en fin innføring til undersidene. Den er ikke tungt modifisert da vi har brukt den mer til hvordan elementene opptrer mot hverandre. Vi så det mer hensiktsmessig å bruke jumbotron enn å lage eget gridsystem som gjør samme nytte. 103

104 Figur 40: HTML-kode for jumbotron 4.5 Breadcrumb Breadcrum er en klasse fra bootstrap sitt rammeverk som har ferdig CSS-kode til. Det er lagt til en annen klasse som heter pull-left og det denne gjør er at den dytter elementet til venstre i elementet den er plassert i. Denne kodesnutten er plassert på hver underside og er statisk. Figur 41: HTML-kode for breadcrumb CSS-koden som vi har endret på er for å sette riktig fargekombinasjon på breadcrumben. Figur 42: CSS-kode for breadcrumb 104

105 4.6 Font-size Font-size er plassert i headeren og er alltid tilgjengelig. Ved hjelp av klassen pull-right blir elementet plassert helt til høyre i elementet den er plassert i. HTML-koden viser til klasser som hentes fra index.php og javascriptet som ligger der. Figur 43: HTML-kode Font-size Javascriptet til font-sizen er en enkel og rett fram koder hvor man på kodelinje 151 kan sette hvilken id'er eller klasser som skal justeres. Var min og var max er størrelsen fontene skal endres til. Figur 44: Øverste del av Font-size javascript Videre kommer hver klasse. FontReset FontSizeMinus FontSizePlus 105

106 Hver klasse-funksjon gjør det samme: Endrer på størrelsen av valgte verdier som finnes i bjerke.css. Figur 45: Videre kode av Font-size javascript 4.7 Content-left Content-left er brukt for å lage skillevegg mellom tekstbokser. Dette er for å skape dynamikk i nettsiden og gjøre det klart at elementene ikke direkte hører sammen. Sammen med <hr class="featurette-divider">, som man finner mellom hver rad i HTML-koden, deler det opp nettsiden. 106

107 Figur 46: CSS-kode for content-left 4.8 Knapper Knappene er basert på klasse fra bootstrap rammeverket, men er kraftig modifisert. HTML-koden lenker til klassene som finnes i bootstrap-rammeverket. Hvor en del CSS er fastsatt. Figur 47: HTML-kode for knapper CSS'en blir videre modifisert, hovedsaklig i fargene. Vi har brukt CSSmatic.com for å få en gradvis fargeendring som matcher logoens farger. Border-radius er blitt brukt for å få avrundede kanter. Ved hoover og når knappen blir brukt endrer fargen seg til orange og teksten endrer seg til hvit tekst. Figur 48: CSS-kode for knapper 107

108 4.9 Fixed nøkkelinformasjon til prospekt.php Fixed nøkkelinformasjon til hvert prospekt er basert på panel-klassen til bootstraps rammeverk og modifisert etterpå. Den lister ut informasjon hentet fra databasen og setter det inn i listen. Figur 49: HTML-kode for nøkkelinformasjon Begge boksene er plassert i flere wrappers for å få plasseringen av elementet korrekt. Den er ikke veldig dynamisk, men fast helt til man kommer til mobil-oppløsning(mindre enn 850px i bredde). 1. #Wrapper holder begge boksene på plass, med transition for dynamikkens skyld. 2. #sidebar-wrapper Posisjonerer begge boksene slik det er ønkselig. Setter Z-index for at ingen andre elementer skal gå over diven. Setter bakgrunnsfarge. 3. #page-content-wrapper Div tag hvor resten av elementene som ikke er fixed ligger. 4..sidebar-nav Klassen ligger i en UL-tag for å få listet innholdet. 108

109 Figur 50: CSS-kode for nøkkelinformasjon 109

110 4.10 Fixed nøkkelinformasjon til prospekt.php mobilversjon Blir bredden mindre enn 850px så posisjoneres nøkkelinformasjonen øverst på prospekt.php. Grunnen til at det er 850px og ikke 768px som er standard er fordi nøkkelinformasjons-elementene har en bredde som legger seg over andre elementer ved 768px, den trenger mer klaring for å ikke bli forstyrrende på andre elementer. Figur 51: CSS-kode for hva som skjer når det nedskaleres 4.11 Kontakt oss Kontakt oss-elementet er et element som er brukt både på forside.php og i omoss.php. Elementet er basert på jumbotron-klassen fra bootstrap sitt rammeverk pga av hvordan layouten blir. Den er ikke veldig modifisert og inneholder blant annet en facebook knapp som lenker til facebook-siden til Meglerhuset via a href. Verdt å legge merke til er target=" blank" som gjør at en ny fane blir åpnet når man trykker på lenken. 110

111 Figur 52: HTML-kode for Kontakt oss 5 Administrasjonssiden 5.1 Om administrasjonssiden For å kunne legge ut prospekter på nettsiden, samt administrere disse, måtte det opprettes en database. Databasen består av en tabell av prospekter, brukere og bilder. Disse tabellenes innhold og relasjoner kan sees i Vedlegg 7. For å hente ut og legge til prospekter gjennom nettstedet var det nødvendig å opprette en administrasjonsside. Dette panelet er kun ment for de som skal ha mulighet til å opprette, endre, deaktivere og eventuelt slette prospekter. 5.2 Sider og mapper tilknyttet administrasjonssiden Adminpanel.php - adminpanel.php Overnevte administratorpanel som krever innlogging av en administrator og inneholder de valg man kan gjøre Deaktiver-prospekt.php - deaktiver-prospekt.php En side for å deaktivere prospekter som for eksempel er ugyldige eller solgt Nytt-prospekt.php - nytt-prospekt.php En side for å opprette et nytt prospekt. Dette innebærer kun å legge inn tekstlig informasjon, bilder lastes opp på en annen side Takelogin.php - takelogin.php En side som kreves for å sjekke innloggingen til administratorpanelet. 111

112 5.2.5 Upload-images.php - upload-images.php En side for å laste opp flere bilder. Dette er en reaksjon på kompleksiteten ved å legge til en fungerende funksjon for å laste opp flere bilder samtidig under opprettelse av prospekt. Derfor ble det å legge til et bilde på et prospekt flyttet hit vis-prospekt.php - vis-prospekt.php Viser et enkeltprospekt, enten via direktelenke eller ved å klikke seg videre fra oversikten over alle prospektene Mappen «Klasse» - mappen «klasse» - Her ligger de klasser som henter og legger inn informasjon til databasen. Disse klassene speiler databasetabellene «Prospekt», «Bilde» og «Bruker» Mappen «Funksjoner» - mappen «funksjoner» - Her ligger det funksjoner som hovedsakelig står for tilkobling mot databasen, herunder brukernavn, tjener, passord og likenende. I tillegg ligger det her en kodesnutt til innlogging. 5.3 Generell informajson Ved å kreve passord på opprettelse og deaktivering av prospekter har vi sikret siden mot ondsinnede brukere. Det er imidlertid ikke lagt inn støtte for å endre et prospekt, heller ikke totat sletting. Ideelt ville også administratorbiten ligget et annet sted enn på nettstedet, men dette var noe vi ikke fikk til innenfor våre rammer. Databasen blir aksessert med MySQL og PHP som mellomlag. PHP bruker også til å presentere dataen som blir hentet fra databasen. 6 KILDER: https://github.com/search?q=stars%3a%3e1&s=stars&type=repositories Ref punkt

113 RESSURSER: - Stackoverflow.com - Wikipedia.com - w3schools.com - CSSmatic.com - Getbootstrap.com 113

114 7 VEDLEGG: 7.1 Vedlegg 1 - Use Case diagram for løsning 114

115 7.2 Vedlegg 2 - Aktivitetsdiagram opprett prospekt 115

116 7.3 Vedlegg 3 - Aktivitetsdiagram Se detaljert prospekt 116

117 7.4 Vedlegg 4 - Aktivitetsdiagram last opp bildet 117

118 7.5 Vedlegg 5 - Aktivitetsdiagram deaktiver prospekt 118

119 7.6 Vedlegg 6 - Aktivitetsdiagram logg inn til administrasjon 119

120 Vedlegg 7 ER-doagram for database 120

121 121

122 2014 Hovedprosjekt 2014 Gruppe 20 Brukerdokumentasjon Meglerhuset Bjerke AS [Torbjørn Gjøn Snorre Duun Strømsborg Matias Pettersen] 122

123 Forord Dette er brukerdokumentasjonen for brukernettsiden og administrasjonssiden til Meglerhuset Bjerke. Brukernettsiden er siden hvor potensielle kunder er inne for å finne boliger, salgsinformasjon, kontaktinformasjon og liknende. Administratorsiden er siden hvor administrator administrerer prospektene tilhørende Meglerhuset. Brukerdokumentasjonen er først og fremst beregnet på administrator av nettsiden, men det er også punkter som beskriver hvordan man tar i bruk brukernettsiden. Brukernettsiden er ment å være selvforklarende i bruk, så det er ikke nødvendig med en utfyllende rapport om hvordan denne skal brukes. Brukerdokumentasjonen er skrevet slik at man ikke skal trenge mer enn grunnleggende datakunnskaper for å forstå dokumentasjonen og få utbytte av den. 123

124 Innholdsliste 1 Forord Faguttrykk Global meny Body Footer Innledning Presentasjon av programmene Løsningen Brukerside Administrasjonssiden Veiledning Bruk av nettsidene Brukersiden Se på prospektbilder Instruksjoner Beskrivende instruksjoner Endre skriftstørrelse Instruksjoner Beskrivende instruksjoner Administratorsiden Logg inn Instruksjoner: Beskrivende instruksjoner Legg til prospekt Instruksjoner Beskrivende instruksjoner Deaktiver prospekt Instruksjoner Beskrivende instruksjoner Last opp bilde Instruksjoner

125 5.4.2 Beskrivende instruksjoner Kilder

126 Faguttrykk I denne dokumentasjonen vil det bli brukt noen ord og uttrykk som kan være ukjent for en person som ikke er veldig godt kjent med data eller programmeringsspråk. Her vil diverse faguttrykk som er brukt i dokumentasjonen forklares nærmere. Global meny En global meny er en meny som synes til enhver tid og gir et overordnet bilde av hva man finner på nettstedet. Den er som regel statisk. I vårt tilfelle ser den globale menyen slik ut: Figur 53: Global meny 3.7 Body Body er en html-tag som brukes ved programmering av nettsider med html-innhold. I body-tagen plasseres normalt innholdet som er mellom menyen øverst på siden og innholdet nederst på siden (f.eks. kontaktinformasjon). Dette vil si innhold som tekst, bilder, tabeller og lister for å nevne noe. 126

127 2.3 Footer Footer er en html-tag som brukes ved programmering av nettsider med html-innhold. I footer-tagen plasseres innholdet som vises nederst på siden, og denne informasjonen er gjerne den samme på alle undersidene på en nettside. I vårt tilfelle har vi plassert kontaktinformasjon, en link til toppen av siden og en knapp til Meglerhusets facebookside i nettsidens footer. Figur 54: Footer Innledning Presentasjon av programmene Her presenteres løsningen som er blitt utviklet. I brukerdokumentasjonen kalles brukernettsiden som er blitt utviklet for "brukersiden" og administrasjonsdelen kalles "administrasjonssiden". Den første delen av manualen beskriver hva som kan gjøres på nettsidene som er utviklet, den andre delen beskriver hvordan man gjennomføre de ulike oppgavene. Nettsidene er designet slik at det skal være enkelt å forstå hvordan man finner frem eller hvordan man skal bruke funksjonene som finnes. Løsningen Løsningen kan deles inn i to deler: Brukersiden og administrasjonssiden. Disse har hvert sitt tilgangsnivå, og har hver sin funksjon. Både brukersiden og administrasjonssiden, samt deres funksjoner presenteres i denne delen av rapporten. Hensikten med dette er å gi en kort innføring i de to ulike løsningene med informasjon om hvilke funksjoner som tilbys og informasjon om hvem de er beregnet for. 127

128 3.3 Brukerside Brukersiden er en nettside som er utviklet med ønske om å gi brukeren god informasjon om Meglerhuset Bjerke og deres prospekter. En typisk bruker er en person som ønsker å kjøpe eller selge en bolig, fortrinnsvis på Østlandet da meglerkontoret er lokalisert på Elverum. Nettstedet skal gi informasjon om hvordan man kan komme i kontakt med en megler, gi en oversikt over tilgjengelige boliger og se boligprospekter i sin helhet. All input fra brukeren vil foregå ved bruk av mus. Eventuelt kan brukeren manøvrere seg rundt ved bruk av tastatur. 3.4 Administrasjonssiden Administrasjonssiden er utviklet for at administrator skal kunne administrere innholdet på kjøps- og prospektsiden. Dette er informasjon som trenger jevnlig oppdatering da Meglerhuset Bjerke får nye prospekter som må legges ut på brukernettsiden Vanlige brukere har ikke tilgang til administratorsiden, og må man logge seg inn med brukernavn og passord for å få tilgang. Administrator skal på administratorsiden ha mulighet til å legge ut nye prospekter på kjøps- og prospektsiden, samt slette eller oppdatere disse. Typisk bruk av input på administrasjonssiden vil være bruk av tastatur til å skrive tekst, og bruk av mus til navigering samt til klikking av knapper. 128

129 Veiledning Bruk av nettsidene Funksjonene som finnes i brukersiden og administratorsiden er ment å være selvforklarende og enkle i bruk. Her følger en veiledning for navigering og bruk av funksjoner i løsningen vår. 4.1 Brukersiden Brukersiden består av veldig lite input fra brukeren utover museklikk, da dette er en ren informasjonsside og er ment for å promotere Meglerhuset Bjerke og deres virksomhet. Brukeren kommer inn på en type nettside de trolig allerede er godt kjent med fra andre aktører i samme marked, og vil således også kjenne seg igjen i oppbygningen av siden. En statisk global meny øverst på midten gjør navigeringen enkel og gjenkjennbar. Informasjonen i body er oversiktlig plassert, og det er en footer nederst på siden med kontaktinformasjon som markerer slutten på siden Se på prospektbilder Instruksjoner 1. Gå inn på prospektsiden 2. Trykk på pilene på høyre eller venstre side i bildekarusellen 129

130 Beskrivende instruksjoner Navn: Formål: Hva som gjøres: Inndata: Hvordan utføre: Se på bilder på prospektsiden Se ulike bilder av et prospekt Veksler mellom bilder raskere enn karusellen allerede gjør. Museklikk Når brukeren går inn på prospektsiden, finnes det en bildekarusell som veksler mellom bildene som finnes av prospektet. Det kan tenkes at brukeren ønsker å få en rask oversikt over hvordan boligen ser ut og vil trykke seg raskt igjennom de. Brukeren kan da trykke på pilene som finnes på venstre og høyre side av karusellen med musen for å øke frekvensen på visningen av bildene. Figur 55: Bildekarusell fra prospektsiden 130

131 4.1.2 Endre skriftstørrelse Instruksjoner 1. Trykk på "aa aa AA" Beskrivende instruksjoner Navn: Formål: Hva som gjøres: Inndata: Hva som utføres: Skriftstørrelse Øke eller minske størrelsen på skriften Øker eller minsker skriftstørrelsen på siden Museklikk Om brukeren ønsker det kan skriftstørrelsen på siden økes eller minskes. Dette gjøres ved at musepekeren flyttes til linkene som ser slik ut: "aa aa AA" og klikkes på av brukeren. Skriftstørrelsen vil da utvides eller minskes alt etter hvilken knapp som er trykket. Figur 56: Skriftstørrelse 131

132 Administratorsiden Administratorsiden er utviklet for at administrator skal kunne legge ut prospekter og fjerne disse. For å komme inn på administratorsiden må man først logge inn med brukernavn og passord. Når man er innlogget kommer man til "legg til prospekt"-siden. Derfra kan man navigere til "deaktiver prospekt" eller "last opp bilder". Under følger instruksjoner til hvordan man skal utføre oppgaver på administratorsiden. 5.1 Logg inn Instruksjoner: 1. Trykk Logg inn på brukerside 2. Skriv inn e-post 3. Skriv inn passord 4. Trykk Logg inn Beskrivende instruksjoner Navn: Formål: Hva som gjøres: Inndata: Hvordan utføre: Logg inn Logge inn på administratorsiden Logger inn på administratorsiden Brukernavn og passord Trykk på "Logg inn" nede i venstre hjørne på brukersiden. Skriv inn brukernavn i feltet "E-postadresse" og skriv inn passord i feltet "Passord". Trykk så "Logg inn" 132

133 Figur 57: Logg inn 5.2 Legg til prospekt Instruksjoner Viktig informasjon: Linken til finn.no må legges inn sammen med prospektet. 1. Velg Legg til prospekt 2. Skriv inn informasjon 3. Velg megler 4. Trykk Legg til nytt prospekt 133

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

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

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

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

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

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

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

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

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

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

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

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

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

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

Detaljer

Dokument 3 - Prosessdokumentasjon

Dokument 3 - Prosessdokumentasjon Dokument 3 - Prosessdokumentasjon Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Dokument 3 - Prosessdokumentasjon Innholdsfortegnelse

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

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 22.01.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Meso

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

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

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

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

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

[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

Kravspesifikasjon Innholdsfortegnelse

Kravspesifikasjon Innholdsfortegnelse Kravspesifikasjon Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:... 2 1.3 Kontaktsperson hos Retriever:... 2 1.4 Veileder:... 2 1.5 Bakgrunn... 3 2. Om Kravspesifikasjonen...

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

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

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

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

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

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

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

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

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

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

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

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

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

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

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet.

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. DAGBOK Uke 43: Torsdag 28/10 Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. Uke 44: Mandag 1/11 Gruppen utformet den første statusrapporten til prosjektet.

Detaljer

29. april 2010 Høgskolen i Gjøvik. Statusrapport III «Studentradio og studentavis i en digital tidsalder» Victoria Engebretsen & Randi Stangeland

29. april 2010 Høgskolen i Gjøvik. Statusrapport III «Studentradio og studentavis i en digital tidsalder» Victoria Engebretsen & Randi Stangeland 29. april 2010 Høgskolen i Gjøvik Statusrapport III «Studentradio og studentavis i en digital tidsalder» Victoria Engebretsen & Randi Stangeland Status Her beskriver vi hvordan den nåværende statusen er

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

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

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

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

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

Wordpress. Kurs Kristiansand Folkebibliotek

Wordpress. Kurs Kristiansand Folkebibliotek Wordpress Kurs Kristiansand Folkebibliotek Innhold Forord... 2 Bruksområde for blogger... 2 Hva er WordPress?... 2 Hvorfor Wordpress?... 2 Sett opp blogg i WordPress... 3 Populære blogge tjenester:...

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

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

Refleksjonsnotat Web.

Refleksjonsnotat Web. Refleksjonsnotat Web. www.kildebruk.host22.com Mariell Hagen Hovedoppgaven i Web Webdesign: opphavsrett og bruk av kilder Vi har hatt prosjektperiode i litt over 2 uker. Oppgaven var at vi skulle lage

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

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

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

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

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

Prosjekt. Halvårs-rapport. til fordypning. Eva-Anita Thorsen 2MKA. 7.Januar, 2010

Prosjekt. Halvårs-rapport. til fordypning. Eva-Anita Thorsen 2MKA. 7.Januar, 2010 1 0 Prosjekt 7.Januar, 2010 til fordypning Eva-Anita Thorsen 2MKA Halvårs-rapport 0.1 innhold 2 INFO SIDE Innhold 2 Innledning 3 Hoveddel 4-8 Avslutning 9 Logg 10-12 Bakside 13 0.2 innledning 3 Innledning

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

Denne ukens mål: Avtale møte med MediaLT Fortsette research rundt MS og få systematisert bedre den informasjonen vi har funnet.

Denne ukens mål: Avtale møte med MediaLT Fortsette research rundt MS og få systematisert bedre den informasjonen vi har funnet. Ukesmål Grunnet en del problemer med blog-siden vår (www.nettverkskort.com/hovedprosjekt) og tidligere uoversiktlig oppsett, har vi valgt å samle alle ukesmålene opp igjennom prosjektet i dette dokumentet.

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

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

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

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

Gruppe 33 - Hovedprosjekt

Gruppe 33 - Hovedprosjekt Gruppe 33 - Hovedprosjekt s188080 Joakim Rishaug s181130 Sondre Sparby Boge s188098 Martin Hagen s178816 Lars Erik Kasin 1 av 7 Kravspesifikasjon Forord Kravspesifikasjonen utformes både for kunden, og

Detaljer

Forprosjektrapport. Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015

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

Detaljer

Oblig 1 Webutvikling av Jon-Håkon Rabben

Oblig 1 Webutvikling av Jon-Håkon Rabben Oblig 1 Webutvikling av Jon-Håkon Rabben Oppgave 2 og 3) http://www.it-stud.hiof.no/~jhrabben/boxmodel.html Oppgave 6) http://www.it-stud.hiof.no/~jhrabben/oblig1oppg6.html Oppgave 1) Siden tar lang tid

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

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

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

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer

Detaljer

Prosjektplan Bacheloroppgave 2014. - Hvordan kan Joker Gjøvik styrke sin markedsposisjon?

Prosjektplan Bacheloroppgave 2014. - Hvordan kan Joker Gjøvik styrke sin markedsposisjon? Prosjektplan Bacheloroppgave 2014 - Hvordan kan Joker Gjøvik styrke sin markedsposisjon? Amund Farås 23.01.2014 1 Innholdsfortegnelse Innhold 1 Innholdsfortegnelse... 2 2 Innledning... 3 3 Organisering...

Detaljer

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport.

Prosjektdagbok FRA 30.10-08 TIL 2.3-09. Uke Dato Personer tilstede. Beskrivelse 10:00. 44 30.10-08 Øyvind. Vi dannet gruppe og skrev Statusrapport. Prosjektdagbok FRA 30.1008 TIL 2.309 Uke Dato Personer tilstede 44 30.1008 48 25.1108 49 02.1208 2 8.109 Tid 10:00 12:00 12:00 12:00 Beskrivelse Vi dannet gruppe og skrev Statusrapport. Kontaktet bedrifter

Detaljer

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1

Dokumentasjon. Prosjektdagbok Timelister. Rolled Up Task. Rolled Up Milestone. Rolled Up Progress. Split. Page 1 ID Name Duration Start Finish 1 Planlegging 95 days Mon 02.10.06 Fri 09.02.07 2 Statusrapport 20 days Mon 02.10.06 Fri 27.10.06 3 Prosjektskisse 25 days Mon 30.10.06 Fri 01.12.06 4 Prosjektweb 31 days

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

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9 Forprosjektrapport Gruppe 17 Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen Side 0 av 9 Innholdsfortegnelse: Presentasjon - Service Broker AS - Kontaktpersoner Sammendrag Dagens situasjon Mål og

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

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

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

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

Oblig 4 Webutvikling. Oppgave

Oblig 4 Webutvikling. Oppgave Oblig 4 Webutvikling Oppgave Lag din egen Wordpress- site der du tester ut CMS- systemet. Det å lage egne templates fra bunnen kan være noe komplisert, så det holder for dette prosjektet om dere modifiserer

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

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

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio.

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio. Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen

Detaljer

OBLIG 2 WEBUTVIKLING

OBLIG 2 WEBUTVIKLING OBLIG 2 WEBUTVIKLING Oppgave 1 Design ved hjelp av skisser eller wireframes et nettsted med et "avansert" design. Lag spesifikke design for ulike skjermstørrelser og utskrift. Fokuser spesielt på å få

Detaljer

STATUSRAPPORT 2: Produksjon av webside for Skjerdingen Høyfjellshotell. http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen

STATUSRAPPORT 2: Produksjon av webside for Skjerdingen Høyfjellshotell. http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen STATUSRAPPORT 2: Produksjon av webside for Skjerdingen Høyfjellshotell 1 25. MARS 2010 http://hovedprosjekter.hig.no/v2010/imt/mp/skjerdingen INNHOLD PROSJEKTDELTAGERE 3 FREMDRIFTSPLAN 3 LEVERANSER OG

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

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

WP-WATCHER WORDPRESS SIKKERHET

WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER BACKUP - SIKKERHETSKOPIERING «Hei! Jeg oppdaterte en plugin på siden min og nå kommer jeg ikke inn på siden min i det hele tatt. Kan du hjelpe meg?» «Hjelp! Jeg

Detaljer

Presentasjon. Kristian Hewlett- Packard 29.05.2012

Presentasjon. Kristian Hewlett- Packard 29.05.2012 2012 Presentasjon Kristian Hewlett- Packard 29.05.2012 1 Innledning Denne innledningen inneholder informasjon om gruppen, samt bakgrunn og mål for oppgaven og en introduksjon til temaet. 1.1 Gruppen Vår

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

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Supplerende Kommunikasjon Assistent (SKA) Bachelorprosjektet går

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

!!!!!!!!!!!! !!!!!!!!!!! WP-WATCHER WORDPRESS SIKKERHET

!!!!!!!!!!!! !!!!!!!!!!! WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER WORDPRESS SIKKERHET WP-WATCHER BACKUP - SIKKERHETSKOPIERING «Hei Jeg oppdaterte en plugin på siden min og nå kommer jeg ikke inn på siden min i det hele tatt. Kan du hjelpe meg?» «Hjelp Jeg

Detaljer

Oblig 3 Webutvikling. Oppgave 1

Oblig 3 Webutvikling. Oppgave 1 Oblig 3 Webutvikling Oppgave 1 Ta for deg en selvvalgt bedrift (gjerne lokal/mindre) og tenk deg at du hadde fått i oppgave å være en SEOkonsulent for disse i én uke. På denne uken skulle du gjennomført

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

fleksibilitet når det gjelder geografisk plassering og etablerte arbeidsrutiner. Qubic cms

fleksibilitet når det gjelder geografisk plassering og etablerte arbeidsrutiner. Qubic cms Qubic cms Qubic cms publiseringsverktøy tilbyr avanserte, men lettfattelige løsninger for å publisere innhold på internett. Ved å bestå av flere forskjellige moduler, som både kan legges til og skreddersys,

Detaljer

Entobutikk 4.PROSESSRAPPORT VÅR 2011

Entobutikk 4.PROSESSRAPPORT VÅR 2011 4.PROSESSRAPPORT VÅR 2011 1 DELKAPITTEL 1 FORORD Denne prosessrapporten inneholder detaljer om alle metoder vi har benyttet og alle fasene vi gikk gjennom under gjennomføringen av hovedprosjektet ved Høgskolen

Detaljer

Håndbok for Office 365

Håndbok for Office 365 ProCloud As P Håndbok for Office 365 Nyttige brukertips for å få mer ut av din løsning Geir Hogstad 2012 w w w. p r o c l o u d 3 6 5. n o Innholdsfortegnelse Forord... 2 Komme i gang med dokumentbiblioteker....

Detaljer