Nordic Funding Nettportal hvor små og mellomstore bedrifter kan låne og investere

Nordic Funding Nettportal hvor små og mellomstore bedrifter kan låne og investere Hovedprosjekt våren 2014 27.05.2014 Side 0 av 133

PROSJEKT NR. Gruppe 8 Studieprogram: Anvendt datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Nordic Funding Nettportal hvor små og mellomstore bedrifter kan låne og investere PROSJEKTDELTAKERE Paul Musabe Bizimana Ragnhildur Osk Arnadottir Huy Nhut Tran Mina Ravem Fredrik Notevarp Singsaas DATO 27. mai 2014 ANTALL SIDER / BILAG 88/133 INTERN VEILEDER Torunn Gjester Telefon: 22 45 32 00 Telefaks: 22 45 32 05 OPPDRAGSGIVER KONTAKTPERSON Sebastian Martens Harung Sebastian Martens Harung Sebastian Martens Harung SAMMENDRAG Utvikle en nettportal der små og mellomstore bedrifter i Norge kan søke om lån og investorer har mulighet til å investere. Nettsiden skal gi brukere mulighet til å registrere seg, logge inn og søke om lån eller investere. Vi har lagt stort fokus på brukervennlighet ved å lage intuitive funksjoner og godt design. Nettsiden er utviklet for gründeren Sebastian Martens Harung som ønsket å lage den for sitt nystiftet selskap Nordic Funding. 3 STIKKORD Nettside Bootstrap PHP Side 1 av 133

Innholdsfortegnelse HOVEDPROSJEKT... 1 Forord... 6 1. Innledning... 9 1.1 Oppdragsgiver... 9 1.2 Bakgrunn for prosjektet... 9 1.3 Mål... 10 1.3.1 Resultatmål... 10 1.3.2 Effektmål... 10 1.3.3 Læringsmål... 11 1.4 Kravspesifikasjon... 11 1.4.1 Hovedfunksjoner for systemet:... 12 2. Analyse... 14 2.1 Prosjektstyring... 14 2.2 Utviklingsmodell... 14 2.3 Use Case... 15 2.3.1 Use case for låntaker... 16 2.3.2 Use case for investor... 18 2.3.3 Use case for administrator... 19 2.3.4 Use case for uregistrert bruker... 20 2.4 ER-modell... 22 2.5 Nettsidens struktur... 22 3. Design... 25 3.1 Low-fidelity prototype... 25 3.2 Første utkast av design... 27 3.2.1 Ulemper og fordeler ved første design... 27 3.3 Andre utkast av design... 28 3.3.1 Hvorfor er design 2 et godt design... 30 3.4 Navigasjonskart... 31 3.5 Oppdeling av nettsiden... 32 3.6 Design av databasen... 33 3.6.1 Tabellene... 34 3.7 Rammeverk... 35 4. Implementasjon... 38 4.1 Nettstedet for besøkende - Vanlig brukere... 38 4.1.1 Forside... 38 4.1.2 Brødsmuler... 40 4.1.3 Textsizer... 40 Side 2 av 133

4.1.4 Generelle informasjon for bedrifter... 41 4.1.5 Generelle informasjon for investorer... 42 4.1.6 Hvordan det fungerer... 43 4.1.7 Markedsplass... 44 4.1.8 Database tilkobling... 45 4.1.9 Markedsstatistikk... 45 4.1.10 Libchart... 46 4.1.11 Om oss... 47 4.1.12 Registrering... 48 4.1.13 Epost koden... 55 4.1.14 PHP-Mailer... 55 4.2 Nettside for registrert brukere... 57 4.2.1 Innlogging/Glemt passord... 57 4.2.2 Kontroll av logg inn... 58 4.3 Nettsiden for Låntakere... 59 4.3.1 Sammendrag... 59 4.3.2 Søk om lån... 60 4.3.3 Visning av profil... 61 4.3.4 Endring av profil... 62 4.3.5 Sider uten innhold... 63 4.4 Nettsiden for investorer... 64 4.4.1 Sammendrag... 64 4.4.2 Hvordan det fungerer... 65 4.4.3 Investering/Budrunde... 65 4.4.4 Visning av profil... 67 4.4.5 Profil koden... 68 4.4.6 Endring av profil... 69 4.4.7 Sider uten innhold... 70 4.5 Tilgjengelige sider for alle brukere... 70 4.5.1 Footer... 70 4.5.2 Kontakt oss... 71 4.5.3 Om oss... 73 4.5.4 Sider uten innhold... 74 4.6 Nettstedet for administrator... 75 4.6.1 Administrator innlogging... 75 4.6.2 Administrator hjem... 75 4.6.3 List ut alle brukere... 76 4.6.4 Legge til ny bruker... 76 Side 3 av 133

4.6.5 Slett bruker... 77 4.6.6 Rediger bruker... 78 4.6.7 List ut alle prosjekter... 80 4.6.8 List ut alle bud... 80 4.6.9 List ut låneavtaler... 81 4.7 Feilhåndtering... 82 4.8 Database... 82 5. Testing... 83 5.1 Brukertesting... 83 5.2 Gjennomføring... 83 5.3 Resultater... 83 5.3.1 Funksjoner... 83 5.3.2 Design... 84 5.4 Kvalitets- og browsertesting på ulike plattformer... 86 5.4.1 Resultater fra plattform og kvalitetskontroll... 87 6. Konklusjon... 88 6.1 Måloppnåelse... 88 6.2 Konklusjon av produkt... 88 Vedlegg... 89 Vedlegg A. Verktøy og hjelpemidler... 91 Vedlegg B. Kommunikasjon... 92 Vedlegg C. Risikoplan... 93 Vedlegg D. Milepælsplan... 95 Vedlegg E. Samarbeidskontrakt... 97 Vedlegg F. Prosjektdagbok... 99 Vedlegg G. Sekvensdiagram... 100 Vedlegg H. Use case beskrivelser... 101 Vedlegg I. Kravspesifikasjon... 109 Vedlegg J. SQL script for databasen... 112 Vedlegg K. Low-fi prototype... 116 Vedlegg L. Spørreundersøkelse... 126 Vedlegg M. Oppgaver til brukertestere... 131 Kilder... 132 Side 4 av 133

Side 5 av 133

Forord Dette er en rapport som beskriver hvordan planleggingen og utviklingsprosessen foregikk under gjennomføringen av prosjektet Nordic funding. Prosjektet er et hovedprosjekt i bachelorstudium i Anvendt datateknologi ved Høgskolen i Oslo og Akershus, våren 2014. Vår oppdragsgiver er en økonom som ønsker en nettbasert løsning for sin forretningsidé. Denne går ut på at de mindre bedriftene i Norge skal kunne ta opp lån uten å involvere banken. Oppdragsgiveren vår har en teori om at begge parter tjener på at banken ikke involveres i disse lånene. For å finansiere disse lånene kan hvem som helst som oppfyller spesifikke krav investere gjennom nettsiden. Vi skal utvikle en pilotversjon av denne handelsplattformen som ved et senere tidspunkt skal videreutvikles. Vi har delt denne rapporten inn i tre hoveddeler: Analyse Design Implementasjon Analysedelen er basert på innhenting av informasjon for hele systemet. Designdelen inneholder prosessen av valg av design og brukertesting av nettsiden. Implementasjonsdelen inneholder forklaringer på funksjoner og deres kode. Vi takker vår veileder Torunn Gjester for god støtte og veiledning gjennom hele prosjektet. Vi vil også takke vår oppdragsgiver Sebastian Martens Harung for et spennende prosjekt. Side 6 av 133

Nettsiden finnes på: http://cube.iu.hio.no/~s180386/nordicfundingv1/home.php Testbrukere Låntaker: brukernavn: 2013nordic@gmail.com passord: 123456 Investor: brukernavn: tester@tester.no passord: tester Administrator: brukernavn: admin@nf.no passord: 1234 Side 7 av 133

Side 8 av 133

1. Innledning NORDIC FUNDING Nettportal hvor små og mellomstore bedrifter kan låne og investere. 1.1 Oppdragsgiver Vår oppdragsgiver Sebastian Martens Harung er en økonom med utdanning fra Copenhagen Business School. Han jobber som rådgiver og med finansiell kommunikasjon hos Geelmuyed.Kiese. Han har erfaring knyttet til selskapstransaksjoner, forretningsutvikling, kapitalanalyser og strategi. Han har et velutviklet nettverk innenfor det norske næringslivet. 1.2 Bakgrunn for prosjektet Oppdragsgiveren vår har stor tro på et system hvor man kan låne og investere penger, uten å involvere en bank. Grunnen er at han har sett at dette konseptet fungerer og vokser fort i popularitet blant annet i England 1, USA 2 og Tyskland 3. Han har derfor stor håp om at det blir like attraktivt i Norge. Små og mellomstore bedrifter er ryggraden i norsk næringsliv og utgjør over 99 prosent av det (regjeringen, 2014). Et system som dette eksisterer ikke i Norge fra før og dette vil hjelpe de mindre bedriftene i Norge med å utvikle seg ved å gi dem et alternativ til lån fra bank. En viktig bakgrunn for prosjektet er behovet for lån til norske bedrifter. Det er mange små og mellomstore bedrifter som sliter med å få lån fordi de er en høyere risiko for banken enn andre kunder de har. Risiko blir også nå mer vektlagt etter at det kom nye og strengere kapitalregler (DN, 2014). Noen investorer er interessert i høy avkastning og i vanlig norske banker kan det være vanskelig å få høy avkastning fordi det er en lav risiko (skagenfondene, 2014). Nordic funding vil bidra til økonomisk vekst over hele landet ved å støtte Norges viktigste bedrifter gjennom effektiv 1 www.fundingcircle.com og www.lendingclub.com 2 www.rebuildingsociety.com 3 https://www.finmar.com/ Side 9 av 133

allokering av kapital fra Norges investorer. Nordic Funding har et ønske om å være låneplassen for Norges viktigste bedrifter. Ved å utvikle en elektronisk handelsplattform vil Nordic Funding kunne betjene begge parter, og tilby en vinn-vinn løsning som gir mer lån til bedriftene til akseptable renter, og bedre avkastning til investorene. Dette kalles for en peer-to-peer løsning og blir mer og mer vanlig, og fungerer godt som et alternativ til tradisjonell bankvirksomhet. 1.3 Mål 1.3.1 Resultatmål Oppdragsgiver ønsker en nettside som skal presentere Nordic Funding på en troverdig måte. Nettsiden skal inneholde informasjon om to ulike brukergrupper, låntakere og investorer. Disse to hovedgruppene skal kunne registrere seg, logge inn og utføre aktivitetene søk av lån og investere i lån igjennom nettsiden. Nordic Funding sitt hovedmål er å gjøre lån for små og mellom store bedrifter mer tilgjengelig. På denne måten skal Nordic funding hjelpe SMB-bedrifter med å vokse ved å gi mulighet for attraktive lån og samtidig gi investorer en gevinst. 1.3.2 Effektmål 1. Øke mulighet for lån til små og mellomstore bedrifter som sliter med å få økonomisk støtte fra banken. 2. Bedre renteverdi for investor enn vanlige investeringsløsninger som finnes per dags dato. 3. Tilby långivere en akseptabel avkastning med moderat til lav risiko. Innen 2 år: Et lånevolum på 100 150 millioner kroner, tilsvarende 4 5 millioner kroner i inntekter. Innen 5 år: Ca. 0,5 % markedsandel, eller et lånevolum på ca. 600 millioner til en milliard koner, tilsvarende 20 40 millioner koner i inntekter. 4. I tillegg kommer selskapets langsiktige skandinaviske ambisjoner: Innen 5 år: Et lånevolum på ca. 100 millioner kroner fra Danmark og Sverige, tilsvarende ca. 3,5 millioner kroner i inntekter. Innen 10 år: Ca. 0,5 % markedsandel, eller et lånevolum på opptil 2,75 milliarder kroner, tilsvarende ca. 95 millioner kroner i inntekter. 5. Øke oppdragsgiver sin årslønn. Side 10 av 133

1.3.3 Læringsmål Vi skal utforme en kravspesifikasjon i samarbeid med vår oppdragsgiver og deretter jobbe ut ifra det dokumentet. I løpet av denne perioden vil vi alle utfordre oss selv og være åpen for å tilegne oss ny kunnskap. Et av våre mål er å anvende et rammeverk gjennom prosjektet, på denne måten vil vi sette oss inn i nye teknologier og programvare. Når prosjektet er ferdig ønsker vi å ha skaffet oss erfaring med utviklingsmetode i praksis og blitt bedre på samarbeid i gruppe. Gjennom prosjektet vil vi bruke all vår kunnskap samt alt vi har lært i løpet av de tre årene vi har gått på Anvendt datateknologi studie. Noe av kunnskapen vi har tilegnet oss tidligere og som vi skal bruke i dette prosjektet er blant annet universell utforming, prototyping, informasjonsarkitektur, webutvikling, IT i praksis, systemutvikling og databaser. Andre læringsmål som er verdt å nevne er: Forbedre kjennskap til hvordan arbeidslivet som utvikler er. Lære å sette mål og tidsfrister og følge disse. Bli dyktige på å beregne arbeidstid opp mot arbeidsmengde. Lære å dokumentere et større prosjekt. 1.4 Kravspesifikasjon Hensikten med denne kravspesifikasjonen er at den skal fungere som et styringsdokument for gruppemedlemmene i prosjektet. Dessuten skal kravspesifikasjonen fungere som en skriftlig avtale mellom gruppen og oppdragsgiver. Den skal gi en beskrivelse av systemet og de funksjonalitetene det inneholder. Vi vil bruke kravspesifikasjonen som en retningslinje mens vi jobber oss fremover i prosjektet. Kravspesifikasjonen fungerer også som en veiledning for sensor, slik at sensor kan se hva som forventes i dette prosjektet. Side 11 av 133

1.4.1 Hovedfunksjoner for systemet: Nettsiden skal tilby informasjon til låntakere og investorer Brukere skal kunne registrere seg Brukere skal kunne logge seg inn Investorer skal kunne investere i lån Låntakere skal kunne søke om lån Begge typer brukere skal ha en profil hvor de har mulighet til å redigere sin brukerinformasjon Begge typer brukere skal ha en oversikt over egne aktiviteter Administrator skal kunne administrere hele siden inkludert alle dens funksjoner Nettsiden skal være universell utformet For komplett kravspesifikasjon se vedlegg I. Side 12 av 133

Prosessdokumentasjon Side 13 av 133

2. Analyse 2.1 Prosjektstyring Vi bestemte oss ved starten av prosjektet å jobbe fire dager i uka, fire timer per dag. I tillegg ble vi enige om at hvis det ble nødvendig skulle vi jobbe lengre dager og/eller fem dager i uken. Før vi startet undertegnet vi en samarbeidskontrakt og vi utnevnte en gruppeleder som skulle passe på frister og at alle gjorde de skulle. Samarbeidskontrakten finnes i vedlegg E. Etter hvert møte vi har hatt, har vi skrevet dagbok som sier hva vi har gjort for den dagen. Et utdrag av prosjektdagboken vår ligger i vedlegg F. Vi lagde milepælsplaner som skulle beskrive den tilstanden vi skulle ha oppnådd til hver tid. Milepælsplaner varte i to uker fordi vi følte det ble enklere å oppnå målene som vi hadde satt opp. Vår erfaring er at oppgaver ikke blir gjort og utsatt i lang tid ved å ha for mange uker imellom hvert mål. Derfor kan det bli vanskelig å oppnå resultatene slik man ønsket i begynnelsen. For å oppnå målene våres har vi benyttet oss av forskjellige verktøy, for både forskjellige faser og oppgaver. For å lese mer om verktøy og hjelpemidler se vedlegg A og for å se et utdrag av milepælsplaner se vedlegg D. Kommunikasjonen i gruppen har gått bra. Vi utviklet en risikoplan som skulle bidra med forskjellige tiltak hvis det oppstod problemer underveis. For å lese om kommunikasjon i gruppe se vedlegg B og for å lese fullstendig risikoplan se vedlegg C. 2.2 Utviklingsmodell I dette prosjektet har vi benyttet oss av en utviklingsmodell som heter fossefallsmetoden. Med denne metoden tar man et steg om gangen og fullfører oppgavene før man begynner på neste steg. Siden vi er fem på gruppen var vi nødt til å planlegge godt slik at alle får deltatt på ulike oppgaver i prosjektet. Fossefallsmetoden innebærer mindre sjanse for at det dukker opp problemer underveis fordi man fullfører en fase før man begynner på neste. Vi har fulgt fossefallsmetoden til den grad at vi har fullført et steg om gangen og gjort forandringer deretter hvis det har vært behov for det. Denne utviklingsmodellen er sterk på planlegging med fokus på tid, leveranse og implementasjon. Side 14 av 133

Derimot kan denne modellen gi en del svakheter med metoder som gir små muligheter for overføring av kunnskap og læring mellom fasene. Alle utviklingsmodeller har sine fordeler og ulemper. (Tollefsen, M. udatert) Figur 1: Viser fossefallsmetoden som er en utviklingsmodell som man kan benytte seg av ved utvikling av systemer. Øverst starter man med idémyldring som man fullfører før man starter på neste fase som er planlegging. Disse fasene fortsetter man til systemet er klart. Laget i Google Draw. 2.3 Use Case Vi startet med å analysere hva systemet skulle gjøre og hvilke hovedfunksjoner det skulle inneholde. Samtidig identifiserte vi de forskjellige brukerne av systemet. Det var viktig å analysere hvilke type brukere som skulle bruke systemet, og hvilke oppgaver de skulle kunne utføre før vi startet å kode. For å kartlegge dette benyttet vi oss av use case diagrammer. Siden gruppen vår består av fem personer er det viktig at alle har en lik oppfatning av systemet og hvordan hovedflyten går i de forskjellige scenarioene. Vi har laget use case beskrivelser av alle funksjoner til systemet. (Se vedlegg H) Side 15 av 133

Nå skal vi se på våre tre use cases: Use case for lånetaker Use case for investor Use case for administrator Use case for uregistrert bruker 2.3.1 Use case for låntaker Figur 2: Use case for bedrift. Viser hva slags aktiviteter brukeren Bedrift kan gjøre på nettsiden. Hver boks inneholder en aktivitet som bedrift brukeren kan benytte seg av. Noen aktiviteter er avhengige av at brukeren er logget inn. Side 16 av 133

Use case beskrivelse for låntaker Use Case Aktør Sekundær aktør Pre-betingelse Post-betingelse Normal hendelsesflyt Variasjon Logge inn Bedrift Nordic Funding, investorer Du er registrert Du er innlogget 1. Du taster inn brukernavn og passord 2. Du er innlogget 1a Du taster inn feil brukernavn/passord 1a1. Får feilmelding om feil brukernavn/passord og må skrive inn på nytt. 1a2. Kan ikke koble til databasen/server. Bruker må prøve å logge inn på nytt. Use case beskrivelse: I tabellen ovenfor er en beskrivelse av aktiviteten logg inn. Denne forklarer hva som må gjøres og hva som hender ved å logge inn. Normal hendelsesflyt forklarer hva som må gjøres steg for steg. Variasjonen viser hva som kan skje og hva som må gjøres hvis det oppstår en feil. Side 17 av 133

2.3.2 Use case for investor Figur 3: Use case for investor. Use case modell for investor: Viser hva slags aktiviteter brukeren Investor kan gjøre på nettsiden. Use case beskrivelse for investor Use Case Aktør Sekundær aktør Pre-betingelse Post-betingelse Normal hendelsesflytt Variasjoner Investere Investor Bedrift, Nordic Funding Registrere investor Du kan låne bort penger 1. Logg inn 2. Oversikt over lånesøknader 3. Velge en søknad 4. Byr på lån 5. Investering/bud godtatt 1.1 Feil kombinasjon av brukernavn og passord 1.1.1 Fylle inn gyldig brukernavn/passord 1.2 Bruker har glemt passord 1.2.1 Trykk på Glemt passord Fyller inn e-post/brukernavn Får tilsendt reset link 5.1 Investeringen/bud blir ikke godtatt Side 18 av 133

I tabellen ovenfor er en beskrivelse av aktiviteten investere. Denne forklarer hva som må gjøres og hva som hender ved å registrere en investering/bud. 2.3.3 Use case for administrator Figur 4: Use case for administrator. Ovenfor vises hva slags aktiviteter brukeren Administrator. Administrator er en super bruker og er ikke registrert i databasen, men trenger fortsatt å logge inn for å få tilgang til sitt e eget brukergrensesnitt. Side 19 av 133

Use case beskrivelse for administrator Use Case Aktør Sekundær aktør Pre-betingelse Post-betingelse Normal hendelsesflyt Redigere en bruker Administrator Nordic Funding Har admin rettigheter Bruker har blitt redigert 1. Logger seg på som admin 2. Navigerer seg til endre bruker 3. Skriver brukernummeret til bruker som skal redigeres 4. Fylle ut informasjon som skal endres 5. Trykk ferdig 6. Bruker har blitt ferdig redigert Variasjoner 3.1 Bruker eksisterer ikke 3.1.1 Skrive gyldig brukernummer 4.1 Ugyldig informasjon 4.1.1 Fylle inn gyldig informasjon I tabellen ovenfor er en beskrivelse av aktiviteten redigere en bruker. Denne forklarer hva som må gjøres og hva som skjer når administrator skal redigere en bruker. 2.3.4 Use case for uregistrert bruker Figur 5: Use case for en vanlig bruker. Ovenfor vises hva slags aktiviteter en bruker som ikke er logget inn kan utføre på siden. Side 20 av 133

Use case beskrivelse for uregistrert bruker Use Case Aktør Sekundær aktør Pre-betingelse Post-betingelse Normal hendelsesflyt Registrere seg som låntaker/investor Uregistrert bruker Nordic Funding En bruker ønsker å registrere seg som låntaker/investor Bruker blir registret som låntaker/investor 1. Bruker går inn på nettsiden 2. Bruker klikker på registeringsknapp 3. Fyller inn informasjon 4. Bruker blir registret Variasjoner 1. Nettstedet er nede 1.1.1 Prøve på nytt senere 3.1. Informasjon er ikke riktig fylt inn 3.1.1 Fyll inn gyldig informasjon 3.2. Registrering avbrutt av bruker 3.2.1 Starte på nytt I tabellen ovenfor er en beskrivelse av aktiviteten Registrere seg som låntaker/investor. Denne forklarer hva som må gjøres og hva som skjer ved registrering av en ny investor eller låntaker. I vedlegg H finnes alle use case beskrivelsene for alle aktører og aktiviteter på nettstedet. Vi har også laget sekvensdiagram og brukte dette som et hjelpemiddel under programmeringsfasen. Dette for å finne strukturen og oppførselen til systemet, for å visualisere og kontrollere systemets arkitektur og for selv å få en bedre forståelse av systemet vi utvikler. Se vedlegg G for sekvensdiagrammene. Side 21 av 133

2.4 ER-modell En ER-modell brukes for å kartlegge og beskrive en database før databasen implementeres. De to hovedkomponentene til en ER-modell er entiteter og relasjonene mellom disse. Når vi lagde vår database brukte vi use case ene som retningslinjer. Entitetene vi endte opp med var: Bruker, Lån, prosjekt, Bud, Admin og Poststed. På figuren under kan man se vår ER-modell. Figur 6: ER modell 2.5 Nettsidens struktur Nettsidens struktur er viktig når det gjelder design og brukerens behov. Vi har fokusert på brukeropplevelsen ut ifra brukere som er fargeblinde, svaksynte eller dyslektikere. For å sikre god lesbarhet må all meningsbærende tekst ha tilstrekkelig kontrast mot bakgrunnen. Dette er gunstig for denne brukergruppen, særlig under krevende lysforhold. Farger kan også være god meningsbærer, de er fine til å gi bedre oversikt og assosiasjoner. Men det er viktig å ikke kombinere ugunstige fargekombinasjoner spesielt med tanke på fargeblinde. Derfor har vi valgt mørkeblå farge kombinert med hvit bakgrunn og svart tekst. Teksten på siden må også være enkel og troverdig, hvor samme strukturen går konsekvent gjennom hele nettsiden. Brødtekst eller løpende tekst gjør det også enklere hvis man ønsker å hoppe fra et avsnitt til et annet. Vi ønsket at all informasjon på Side 22 av 133

siden skulle være lett tilgjengelige slik at brukeren fort kom til ønsket mål. (Universell utforming av IKT, udatert) Figur 7: Strukturen på nettsiden. Som vi ser inneholder nettsiden tre hoveddeler. Forsiden som deles opp i mange undersider, i tillegg til to forskjellige brukergrupper som er bedrift og investor. Side 23 av 133

Side 24 av 133

3. Design 3.1 Low-fidelity prototype Oppdragsgiver hadde ikke noen sterke meninger om hvordan designet på siden skulle se ut. Vi var derfor fri til å starte med dette som vi ønsket. Det første vi gjorde i denne fasen var og lage en lowfidelity prototype, utifra de funksjonene han ønsket for systemet. En low-fidelity prototype er en prototype som går kjapt å lage og som heller ikke koster oss stort. Det blir et første utkast av en skisse som er enkel å endre på. Vi lagde en komplett nettside bare med penn og papir slik at oppdragsgiver kunne teste og kommentere. På denne måten fikk vi mulighet til å få tilbakemeldinger på hva som kunne forbedres i en tidlig fase. Disse skissene lagde vi veldig fort uten å tenke for mye. De har få detaljer men allikevel hjelper det oss i gruppen med å få dette ned på papir. På denne måten kan gruppen visualisere bedre hvordan vi tenker å gjøre, sånn at alle får en lik oppfatning av systemet med tanke på at vi er fem personer på gruppen. En fullstendig low-fidility prototype finnes i Vedlegg K. På bildet under er vårt første utkast av hvordan vi tenkte forsiden skulle se ut. Sånn som resultatet har blitt ligner de mye på hverandre. Side 25 av 133

Figur 8: Hjem prorotype Under har vi enda et bilde fra vårt første utkast. Dette er hvordan vi så for oss at innlogging skjermen skulle se ut. Figur 9: Logg inn prototype Side 26 av 133

3.2 Første utkast av design På bildet nedenfor er et bilde av vårt første utkast av nettsiden. Oppdragsgiver var veldig positiv til dette utkastet. Han likte spesielt godt de rene linjene og bruken av fargen blå. 3.2.1 Ulemper og fordeler ved første design Ulempene ved dette designet er at den manglet litt farger, de grå tonene var litt kjedelig og nettsiden var lite ordinær, spesielt meny knappene. Vi ønsket oss mer unikt design hvor brukeren husket godt hvordan nettsiden så ut. Det som var veldig bra med dette designet var at den var enkel og oversiktlig. Dette designet lagde vi nokså kjapt og var ikke helt fornøyd med. Vi følte at vi ikke hadde tenkt nok på det estetiske, vi var mer interesserte i å få alle funksjoner til å fungere først. Derfor bestemte vi oss for å bruke litt tid på å lage en annen design, hvor oppdragsgiver fikk mulighet til å sammenligne to forslagene. Side 27 av 133

Figur 10: Første utkast av design 3.3 Andre utkast av design Vi bestemte oss for å lage en illustrasjon av et annet design for ikke bruke for mye tid på koding, før vi fikk tilbakemelding fra oppdragsgiver. Dette designet falt bedre i smak både hos oppdragsgiver og oss. Fokuset var rettet mot bruk av farger og nyanser, samt bedre oppdeling av informasjon på siden. Oppdragsgiver likte godt bruken av farger og det store Nordic Funding banneret midt på siden. Han ønsket gjerne at dette kunne skiftes ut til en bildekarusell. Vi valgte derfor å fortsette utviklingen av dette designet med både koding og implementasjon. Side 28 av 133

Figur 11: Andre utkast av designet. Laget i Moqups. Moqups.com er en gratis nettside hvor man kan lage high-fidelity prototyper. Figur 12: Screenshot av første utkast ved koding etter at vi bestemte oss for design. Side 29 av 133

Figur 13: Screenshot av nettsiden ferdig utviklet. På figur 13 ser vi hvordan nettsiden utviklet seg til å bli da vi var ferdig med å programmere, og implementere alle de funksjonene som vi allerede hadde laget. Etter vår mening ble den mer troverdig og gjennomtenkt enn den første som vi laget. 3.3.1 Hvorfor er design 2 et godt design Design 1 Design 2 Fordeler - Enkelt - Stor logo - Ikke for mange menyvalg - Bruk av farger/nyanser - Blikkfang - Bildekarusellen - Ikke for mange menyvalg - Enkelt - Bedre meny plassering og menynavn. Ulemper - Lite farger. Bare grått. - Ikke noen bilder eller lignende som fanger brukerens oppmerksomhet. - Litt mye tekst - Teksten kan være litt liten Designet på sluttproduktet ble mer moderne med sterkere farger og mer kontrast. Etter vår vurdering og brukertesting (Se punkt 5.1) så nettsiden mer profesjonell ut med moderne Side 30 av 133

bildekarusell på første side og flere bilder generelt på siden. Nettsiden er heller ikke full av informasjon. Vi har prøvd å lage mellomrom og en del white space for å gi den balanse og kontraster. For at det skal være enklere å lese teksten på siden brukes det ofte en divider som deler opp teksten men en lysegrå linje. Et mål med siden er at brukere skal registrere seg og begynne å bruke siden. Derfor er registreringsknapper gjort lett tilgjengelig ved at det er mulig å komme dirkete til registreringsskjemaet fra alle sider. Brukeren skal til en hver tid skal vite hvor de befinner seg på nettsiden og vi har derfor laget breadcrumbs. For å unngå at nettsiden ser rotete ut har vi tenkte på at de forskjellige elementene på nettsiden må være på linje med hverandre. Det er ikke minst viktig at nettsiden er konsistens. Bruker skal ha en følelse av at de er på den samme siden uansett hvor de er hen. Dette gjør vi ved å ha lik meny og footer på alle sidene og at fargene går igjen i tekst og knapper (tutsplus.com, 2014; Sandnes, 2011) 3.4 Navigasjonskart En god navigasjon er fundamentet til et godt design. Informasjon skal være lett tilgjengelige og brukervennlige. Det er viktig at brukeren kan navigere til hvilken side som helst, uansett hvor den befinner seg. Brukeren skal kun behøve å trykke få ganger til å komme seg til ønsket mål. (Mardiros internet marketing, udatert) Nettsiden har to hovedfunksjoner som er investering og søk om lån. Brukere av nettstedet er tre forskjellige aktører. Aktørene er låntakere, uregistrerte brukere, og investorer hvor de kan enten registrere seg privat eller som bedrift. Sånn ser navigasjonen ut: Figur 14: Navigasjonsstruktur Side 31 av 133

3.5 Oppdeling av nettsiden Global meny: Meny som alltid er tilstede og gir et overordnet bilde av hva man finner på nettsiden. Når en bruker er logget inn vil global menyen forandre seg. Dette kommer an på hvilken type bruker som er logget inn. Innhold: Alt hovedinnholdet befinner seg her. Alt av informasjon og handlinger som skal kunne utføres er plassert i innhold. Undermeny: I undermenyen har vi informasjon til brukeren hvor og hvordan den kan kontakte bedriften, generelle vilkår osv. Figur 15: Navigasjon Side 32 av 133

3.6 Design av databasen Database kan ses på som et elektronisk arkiv. Ved hjelp av database kan man lagre viktige data og senere hente disse ut. Dataene blir lagret inn i tabeller og tabellene blir koblet mot hverandre ved hjelp av nøkler og ID som kjennetegner og gjør tabellene unike. Dette er viktig slik at man unngår redundans i systemet. Vi valgte å ta i bruk en database til nettsiden fordi det skal lagres mange informasjon om alle brukere som registrerer seg, låneavtaler, investeringer og andre viktige informasjon. Figur 16: Database oppsettet Primærnøkkel Fremmednøkkel Side 33 av 133

Figuren over viser hvordan databasen er bygd opp. Hver tabell har flere rader som er koblet med de andre tabellene. Alle tabellene har egen primærnøkkel. Primærnøkkel er en naturlig identifikator. Vi kan se f.eks. i tabellen bruker så har vi valgt brukernummer for primærnøkkel fordi at ingen av de registrerte kommer til å ha det samme nummeret, derfor kan man slå opp dette nummeret til å finne den riktige brukeren. Alle tabeller har også en fremmednøkkel som henviser til andre data i en database. 3.6.1 Tabellene Bruker: Her registreres all nødvendig informasjon om brukeren. Informasjon som fornavn, etternavn, adresse, e-post, kontonummer osv. Dersom brukeren er en bedrift blir det registrert firmanavn, organisasjonsnummer, selskapsform, daglig leder, bransje, styrets leder osv. Hver bruker får også et unikt brukernummer ved registrering. Poststed: Denne tabellen inneholder alle poststedene med sine tilsvarende postnummer i Norge. Når en bruker registrerer seg trenger brukeren å taste inn postnr så kommer poststed automatisk. Prosjekt: Prosjekt tabellen er tabellen hvor brukernes ønsker om lån blir registrert. Her registrerer man brukernummer, tittel, formål, detaljer, beløp og tidsfrister. Bud: I bud tabellen registreres det alle bud som blir bydd på de forskjellige lån ønsker. Informasjon som registreres er budnummer, prosjektnummer, brukernummer, tittel, risiko, beløp, opprinnelig beløp, renter og tid. Låneavtale: I låneavtale registreres de avtalene som låntakeren og investoren blir enige om. Her har vi registrert lånenummer, brukernummer og budnummer. For å se et fullstendig script som lager databasen se vedlegg J Side 34 av 133

3.7 Rammeverk I planleggingsfasen ble gruppen enige om å ta i bruk et rammeverk. Ved dette prosjektet var det viktig for oss å lære noe nytt. Vi ønsket å tilegne oss en kunnskap som vi ikke hadde gjort gjennom studiene. Derfor brukte vi ganske mye tid på å lære hvordan man skulle håndtere og bruke et rammeverk ved koding. Det som er veldig bra med et rammeverk er at det kan bidra med blant annet ferdige funksjoner, ryddigere kode og bedre sikkerhet i forhold til implementasjon. Før vi bestemte oss for hvilket rammeverk vi skulle velge, gikk vi igjennom disse rammeverkene : Codelgniter - PHP CakePHP - PHP Bootstrap - CSS & HTML Vi brukte god tid til å undersøke og teste disse rammeverkene for finne ut hvilke som passet best til vårt prosjekt Fordeler CodeIgniter - Katalogstrukturen er enkel å forstå - God dokumentasjon - Stort samfunn - Ganske enkelt å lære Ulemper - Mangler noen kraftige funksjoner - Ingen tutorials - Må laste ned add-ons for å brukt det på best mulig måte CakePHP - Stort bibliotek av komponenter og plug-ins - Et aktivt samfunn - Enkelt å laste ned - Vanskelig å lære - Sakte side nedlasting Bootstrap - Fungerer bra i alle moderne browsere - Kan tilpasses - Gir siden en rød tråd - Kommer med jquery - Har gode maler - Mange tutorials - på github og bootstrap.com (David Connellys Blog 2011, LinkedIn 2014) - jquery plug-ins er begrenset - Selvom det er mulig å tilpasse koden, ser mange sider like ut - Store filer Side 35 av 133

Vi kom frem til den konklusjonen at Bootstrap er et ideelt rammeverk for oss. Bootsrap ville kunne hjelpe oss i forhold til at vi har satt oss et mål med at nettsiden skal være universelt utformet. Bootstrap rammeverket er ganske populært og er blitt brukt blant mange utviklere på grunn av fint design, god hastighet, og har et bibliotek som har mange gode tilleggs funksjoner. Det var også forholdsvis enkelt å lære seg Bootstrap da det fantes mange gode tutorials. Side 36 av 133

Produktdokumentasjon Side 37 av 133

4. Implementasjon I denne delen kommer det først en presentasjon av nettstedet vi har laget med skjermbilder av nettsiden. Vi har laget et strukturkart så det skal være enklere å få oversikt over hvor man befinner seg på nettsiden mens man ser på bildene. Det grønne symboliserer hvilken side som vises. 4.1 Nettstedet for besøkende - Vanlig brukere 4.1.1 Forside Den første siden brukeren kommer til er forsiden. Det er viktig at den fanger brukerens oppmerksomhet og at man fort får inntrykk hva nettsiden går ut på. Vi har laget et avsnitt hver for investor og bedrift som kort og greit forklarer hvilke muligheter hver av disse har. Registreringsknapper har vi også lagt til så det skal være så enkelt for brukerne å registrere seg, og også for å oppfordre dem til å gjøre det. Med en bildekarusell får vi også mer innhold uten scrolling, og med dette verktøyet viker nettsiden også mer profesjonell. Side 38 av 133

Figur 17: Forside kart Figur 18: Forside Side 39 av 133

4.1.2 Brødsmuler Figur 19: Brødsmuler Øverst på nettsiden under global meny har vi brødsmulesti. Den viser bruker hvor den er til hver tid og representerer hierarkiet på nettsiden. Koden til brødsmulestien ser slik ut: <div class="breadcrumb"><div class="active"><b>du er her: </b><a href="home.php">hjem</a> > Hvordan det fungerer</div></div> 4.1.3 Textsizer Helt til høyre på nettsiden har vi en globalmeny hvor vi har a A. Disse symbolene har vi laget slik at svaksynte har mulighet for å forstørre teksten eller hvis brukeren ønsker å forminske teksten på siden. Koden bak denne linken ser slik ut: textsizer.js var tgs = new Array('body'); var szs = new Array( 'xx-small','x-small','small','medium','large','x-large','xx-large' ); var startsz = 2; function ts( trgt,inc ) { if (!document.getelementbyid) return; var d = document,cel = null,sz = startsz,i,j,ctags; sz += inc; if ( sz < 0 ) sz = 0; if ( sz > 6 ) sz = 6; startsz = sz; } if (!( cel = d.getelementbyid( trgt ) ) ) cel = d.getelementsbytagname( trgt )[ 0 ]; cel.style.fontsize = szs[ sz ]; for ( i = 0 ; i < tgs.length ; i++ ) { ctags = cel.getelementsbytagname( tgs[ i ] ); for ( j = 0 ; j < ctags.length ; j++ ) ctags[ j ].style.fontsize = szs[ sz ]; } Side 40 av 133

4.1.4 Generelle informasjon for bedrifter Her er det mulighet for å lese alt som handler om bedriften. Denne siden er spesielt ment for søking av lån hvor brukeren kan få alle spørsmål og svar angående en lånesøknad og hvordan den prosessen foregår. Figur 20: Bedrift kart Figur 21: Bedrift siden Som vi ser er knappen til å registere bedriften både øverst i høyre hjørnet og nederst på siden. Side 41 av 133

4.1.5 Generelle informasjon for investorer Investorene kan lese om hvordan investeringen på Nordic Funding fungerer. De kan skaffe seg informasjon om hvordan den prosessen fungerer og hvilken krav de må oppnå til å kunne investere i en eller flere bedrifter. Figur 22: Investor kart Figur 23: Investor siden Side 42 av 133

4.1.6 Hvordan det fungerer Her kan alle brukere lese om hvordan Nordic Funding fungerer hva som er målet og hvorfor alle parter kan tjene på lån og investering. Figur 24: Hvordan det fungerer kart Figur 25: Hvordan det fungerer siden Side 43 av 133

4.1.7 Markedsplass Her kan brukeren få oversikt over hvilken låne ønsker som er blitt lagt ut, når tidsfristen går ut og hvor mye lån bedriftene ønsker. Hvis en investor allerede har logget inn så kan den velge et bud som er interessant og gi bud på en bestemt sum til den bedriften. Figur 26: Markedsplass kart Figur 27: Markedsplass siden For å liste opp alle registrert lån søknader (Prosjekter) trengs det å kobles opp mot database. Koden for dette ser du under. Side 44 av 133

4.1.8 Database tilkobling Koden for å koble til databasen har vi i egen fil øverst på nettsiden. Koden for koblingen ser slik ut : connecttodb.php DEFINE('DATABASE_USER', 'root'); DEFINE('DATABASE_PASSWORD', ''); DEFINE('DATABASE_HOST', 'localhost'); DEFINE('DATABASE_NAME', 'nordicfunding'); $db = @mysqli_connect(database_host, DATABASE_USER, DATABASE_PASSWORD, DATABASE_NAME); if (!$db) { trigger_error('kunne ikke koble til databasen: '. mysqli_connect_error()); echo "Feil i db".$db->connect_error; } 4.1.9 Markedsstatistikk Her kan alle brukere se en oversikt over både bud og lån som har blitt gjennomført den siste tiden. Figur 28: Markedsstatistikk kart Figur 29: Markedsstatistikk siden Side 45 av 133

4.1.10 Libchart Libchart er et bibliotek som brukes for å lage stople- og kakediagrammer. Vi valgte å bruke dette biblioteket da vi skulle lage grafiske diagrammer for å kunne vise brukere forskjellige statistikker på Nordic Funding. Vi brukte et eksempel på hvor mye penger som har blir investert i år 2014-2015 Vi har ikke brukt Libchart på det fulleste da vi ikke hadde nok konkrete data å gå ut ifra, og derfor har vi bare funnet opp noe data. Nedenfor viser vi en kodesnutt der vi kaller på objektet VerticalBarChart som genererer et stolpediagram ut i fra data vi setter inn. NB: Her har vi satt inn data manuelt, men det er mulig å hente data fra en database. chart_maker.php $chart = new VerticalBarChart(500, 250); $dataset = new XYDataSet(); $dataset->addpoint(new Point("Jan 2014", 55)); $dataset->addpoint(new Point("Feb 2014", 79)); $dataset->addpoint(new Point("March 2014", 102)); $dataset->addpoint(new Point("April 2014", 84)); $chart->setdataset($dataset); $chart->settitle("måndentlig investeringer 2014 (1k = 1000 NOK)"); $chart->render("demo/generated/demo1.png"); Side 46 av 133

4.1.11 Om oss Her finnes det generelle informasjon om Nordic Funding, både besøks adresse, historie og hva Nordic Funding gjør. Figur 30: Om oss kart Figur 31: Om oss siden Side 47 av 133

4.1.12 Registrering For at en bruker skal kunne benytte seg av nettsiden må de registrere seg som en bruker. Øverst i høyre hjørne vil det alltid være en Registrer -knapp. Ved å trykke på denne vil bruker bli sendt til en side med et skjema som må fylles ut. Figur 32: Registrering Figur 33: Registrering type bruker Dersom brukeren ikke godkjenner vilkår til Nordic Funding vil den ikke komme seg videre i registreringen. Ved å trykke på Godkjenn vilkår linken vil brukeren få lest igjennom vilkårene til Nordic Funding. Side 48 av 133

Figur 34: Registrering vilkår Brukeren må velge om den skal registrere seg som en investor eller en bedrift som søker om lån. Deretter vil brukeren bli sendt videre til et nytt skjema. Ved valg av Bedrift vil bruker få et nytt skjema til å fylle ut. Her kan vi se en bruker som registrerer seg som en bedrift. Side 49 av 133

Figur 35: Registrering bedrift Figur 36: Registrering bedrift info Side 50 av 133

Dersom ikke alle informasjon er riktig utfylt vil brukeren få beskjed om å taste inn riktige informasjon til å kunne komme seg videre. Sånn som vi ser på bildet er nedenfor. Figur 37: Registrering bedrift feilmelding Side 51 av 133

En bruker som registrerer seg som investor vil få opp to valgmuligheter før den begynner å registrere seg, enten må den velge investor bedrift eller investor privat. Figur 38: Registrering investor Figur 39: Registrering investor type All denne informasjonen trengs for å kunne kredittsjekke og vite at det er en seriøs bedrift. Når dette er fylt inn trykker bruker på Registrer -knappen og vil da få beskjed om at de har blitt registrert og at de har fått tilsendt en epost med en link som må trykkes på for å aktivisere profilen. Aktivering av epost er brukt med hensyn til sikkerhet. Når registeringen er fullført uansett om du har registrert deg som investor privat eller bedrift vil brukeren få opp samme tilbakemeldingen, om at registrering er fullført, hvis den ble vellykket. Side 52 av 133

Figur 40: Registrering investor kart Figur 41: Registrering investor info Side 53 av 133

Figur 42: Registrering ferdig/feil kart Figur 43: Registrering ferdig/feil Hvis brukeren har aktivert linken får den tilsendt på epost får den beskjed om å logge inn. Dersom brukeren har fullført registeringen, får den tilsendt en link på epostadressen til å aktivere epostadressen. Der vil den få beskjed om å logge inn. Her nedenfor kan vi se kildekoden når en bruker enten registerer seg eller har behov for et nytt passord. Side 54 av 133

4.1.13 Epost koden connecttodb.php DEFINE("EMAIL_PASSWORDRESET_CONTENT", "For å resette passordet ditt hos Nordic Funding, klikk på linken nedenfor: \nlinken fungerer bare én gang\n\n") DEFINE('WEBSITE_URL', 'http://127.0.0.1/bootstrap1') DEFINE("MESSAGE_ACTIVATION_LINK", "For å aktivere brukeren hos Nordic Funding, klikk på linken nedenfor: \n\n") DEFINE("EMAIL_SIGNATURE", "\n\n --\nnordic Funding\nwww.nordicfunding.no\nAdresse") DEFINE("EMAIL_SMTP_HOST", "nordicfund2013@gmail.com") DEFINE("EMAIL_SMTP_PASSWORD", "nordic2013") Figur 44: Aktivering Hvis det oppstår feil i registeringen, eksempel feil med epost-tjenesten vil bruker få beskjed på skjermen at registeringen ikke ble fullført. Figur 45: Feil med e-post 4.1.14 PHP-Mailer Alle de sende epost løsningene har vi løst ved å bruke et PHP-bibliotek (PHP-mailer) for nettsiden. Funksjonene i biblioteket utførte disse oppgavene på en enkel og grei måte. Biblioteket har hjulpet oss med å få til disse oppgavene på Nordic Funding sine sider : Sende en aktiveringslink på epost til brukere som registere seg Sende en link for gjenoppretting på epost til brukere som har glemt passordet Sende en bekreftelses epost til brukere som har sendt en forespørsel til Nordic Funding Side 55 av 133

Her nedenfor kan vi se koden vi har brukt til å løse dette : reg_investor_privat.php $mail = new PHPMailer; $mail->issmtp(); // Set mailer to use SMTP $mail->charset='utf-8'; // Use UTF8 (ie. ÆØÅ) $mail->smtpauth = true; // Enable SMTP authentication $mail->host = "ssl://smtp.gmail.com"; // Specify main and backup server $mail->username = EMAIL_SMTP_HOST; // SMTP username $mail->password = EMAIL_SMTP_PASSWORD; // SMTP password $mail->smtpsecure = "ssl"; // Enable encryption, 'ssl' also accepted $mail->port= 465; $mail->from = 'no-reply@nordicfunding.no'; $mail->fromname = 'Nordic Funding'; $mail->addaddress($brukernavn); // Add a recipient $mail->subject = 'Aktivering av brukerkonto på Nordic Funding som investor privat'; $link = WEBSITE_URL. '/activate.php?email='. urlencode($brukernavn). "&key=$activation"; //En mail blir sendt til epostadressen med aktiveringsnøkkel $mail->body = MESSAGE_ACTIVATION_LINK. $link. EMAIL_SIGNATURE; echo "<meta http-equiv=\"refresh\" content=\"0;url=reg_ferdig.php\">"; //Mailen ble ikke sendt da det skjedde noe feil og ingenting blir satt inni databasen if(!$mail->send()) { $sql = "DELETE FROM `bruker` WHERE epost='$brukernavn';"; $resultat = mysqli_query($db, $sql); //debugkode dersom mail ikke blir sendt //echo 'Mailer Error: '. $mail->errorinfo; / echo "<meta http-equiv=\"refresh\" content=\"0;url=reg_feil.php\">"; } Side 56 av 133

4.2 Nettside for registrert brukere 4.2.1 Innlogging/Glemt passord For å kunne logge inn må bruker allerede være registrert hos Nordic Funding. Brukeren benytter seg av eget brukernavn(epost) og passord. Det er mulighet for å logge inn som tre forskjellige brukergrupper: Bedrift (lånesøker) Investor Administrator Figur 46: Logg inn kart Figur 47: Logg inn For å kunne logge inn må bruker skrive inn epostadresse og passord. Det blir sjekket i databasen hva slags tilgang brukeren skal ha. En bruker kan ikke være registrert som bedrift, investor og administrator på en epostadresse. Dersom brukeren har glemt passordet kan den trykke på Jeg har glemt passordet mitt og da vil brukeren ha mulighet for å få passordet tilsendt til ønsket epostadresse. Side 57 av 133

4.2.2 Kontroll av logg inn Koden her nedenfor viser hvordan den kontrollerer om brukeren er logget inn før den får tilgang til innhold som krever innlogging. Hvis man ikke er logget inn blir man sendt til innlogging siden. header_loaner.php header_investor.php if ($_SESSION["loggedIn"]!= true) { header('location: login_fail.php'); die('you cannot directly access this page!'); } // kill the page display error Ved gjenoppretting av passord vil brukeren skrive inn egen epostadresse. Videre vil den få tilsendt en link til å gjenopprette passordet. Figur 48: Passord gjenoppretting Her ser vi at passordet har blitt sendt til ønsket epostadresse. Figur 49: Passord gjenoppretting e-post Side 58 av 133

4.3 Nettsiden for Låntakere 4.3.1 Sammendrag Hvis låntaker har logget seg inn, kommer den til et sammendrag hvor man kan få oversikt over tidligere lån og sammendrag av egne aktiviteter. Dersom låntaker skal oppdatere lånesøknaden sin ved å enten slette et låne ønske, kan det gjøres det ved å trykke på den grønne Oppdater knappen. Hvis brukeren velger å oppdatere et lån må den fylle ut detaljert låne beskrivelse sånn som vi ser på bildet nedenfor. Figur 50: Sammendrag kart Figur 51: Sammendrag låntaker Figur 52: Slett/Oppdater lånønske Side 59 av 133

4.3.2 Søk om lån For å kunne søke om en et lån må brukeren for bedriften være innlogget. Når bruker er innlogget er det et menyvalg som heter Søk om lån. Det vil føre bruker til en ny side hvor det må fylles ut en søknad. Når alt er fylt inn må bruker trykke på knappen Registrer søknaden. Foreløpig må søknaden bli godkjent manuelt av administrator. Men tilbakemelding om sendt søknad kommer nederst på siden, etter at brukeren har trykket på Registrer søknaden. Brukeren får beskjed om at låneønsket er blitt registrert. Figur 53: Søk lån kart Figur 54: Registrer lånønsker Side 60 av 133

4.3.3 Visning av profil Ved å gå inn på profilen er det mulighet for å få oversikt over registrert informasjon om brukeren. Videre kan man redigere på profilen om det er ønskelig. Figur 55: Profil kart Figur 56: Profil info Side 61 av 133

4.3.4 Endring av profil Her har låntaker mulighet for å endre egen profil hvis det er ønskelig eller hvis det er informasjon som forandrer seg underveis. Den trykker inn i det feltet den ønsker å forandre og trykker på Fullfør knappen nederst på siden. Figur 57: Rediger profil kart Figur 58: Rediger profil info Side 62 av 133

4.3.5 Sider uten innhold Hvordan det fungerer, Låneavtale, Finansielle nøkkeltall, Bruk av lånet, Kredittvurdering og Q&A Disse siden har det samme innhold. Vi har ikke fått noe tekst fra oppdragsgiver. Figur 59: Uten innhold kart Figur 60: Uten innhold info Side 63 av 133

4.4 Nettsiden for investorer 4.4.1 Sammendrag Når brukeren har logget inn kommer den direkte til sammendrag fra egen statistikk. I det tilfellet her nedenfor ser vi et eksempel på en investor som har logget inn. På denne siden skal investor få en oversikt over sine egne aktiviteter med hjelp av forskjellige visualiseringer. Figur 61: Sammendrag investor kart Figur 62: Sammendrag investor Side 64 av 133

4.4.2 Hvordan det fungerer Hvordan det fungerer for investor inneholder en oversikt over meny knapper og forklaringer på hva man finner på de forskjellige menyene. Figur 63: Hvordan det fungerer investor kart Figur 64: Hvordan det fungerer investor 4.4.3 Investering/Budrunde En investor må være innlogget for å kunne investere i et lån. Når investor er innlogget vil de få et meny valg hvor de kan investere. De vil da få en oversikt over de lånene det er mulig å investere i. Investor kan se beløp, ønskelig nedbetalingstid, beskrivelse osv. For å investere på et lån velges det et lån og det vil da dukke opp 3 felter som må fylles inn (Beløp, rente og tid). Side 65 av 133

Figur 65: Investere/bud kart Figur 66: Investere/bud Investor har mulighet for å trykket på den bedriften den ønsker å investere i, ved å trykke på Velg prosjekt vil den komme videre til et skjema hvor den fyller ut det beløpet den ønsker å investere med, renter og tilbakebetalingstid. Side 66 av 133

Figur 67: Investere/bud Når investor har tastet inn bestemt løp, renger og tilbakebetalingstid for bedriften den ønsker å investere i får den tilbakemelding om at investeringen er registrert. Figur 68: Investere/bud vellykket 4.4.4 Visning av profil Profil visning er likt som for låntaker. Ved å gå inn på profilen er det mulighet for å få oversikt over registrert informasjon om seg selv. Videre kan man redigere på profilen om ønskelig. Side 67 av 133

Figur 69: Profil for investor Figur 70: Profil info, investor 4.4.5 Profil koden I min profil koden som man kan gå til etter å ha logget inn,kobler vi til databasen og henter ut all informasjon som er lagret på den innloggede bruker og lister det ut i en tabell. if ($_SESSION["loggedIn"] = true){ $bruker = $_SESSION["brukernavn"]; $passordet = $_SESSION["passord"]; $sql = "Select * from bruker where epost = '$bruker' and passord = '$passordet'"; $result = $db->query($sql); if (!$result) { echo "Error". $db->error. "<br/>"; } else { $rad = mysqli_fetch_array($result,mysqli_assoc); Side 68 av 133

4.4.6 Endring av profil Endring av profil vil foregå likt som for låntaker. Ved å gå inn på profilen er det mulighet for å trykke på Rediger profilen -knappen. Det vil da komme opp et skjema hvor bruker kan skrive inn den informasjon de vil endre. Her ser vi et eksempel på en låntaker som ønsker å redigere sin profil. Figur 71: Profil redigering kart Figur 72: Profil redigering investor Her ovenfor ser vi at brukeren investor har tenkt å forandre på epostadressen. Når den har skrevet inn riktig epostadresse kan den fortsette ved å trykke på den grønne knappen Fullfør og da vil alle endringer bli lagret. Brukeren blir bedt om å logge inn på nytt til å fortsette, sånn at alle informasjon blir oppdatert og lagret. Side 69 av 133

Figur 73: Profil redigering fullført 4.4.7 Sider uten innhold Alle disse sidene (overfør, automatisk bud, låne deler, selg og statistikk) ser likt ut siden de ikke har noe innhold. Innholdet mangler ettersom vi ikke har fått dette fra oppdragsgiveren. Figur 74: Sider uten innhold kart Figur 75: Sider uten innhold 4.5 Tilgjengelige sider for alle brukere 4.5.1 Footer Gjennom hele siden vil den samme footer gjenstå uansett hvor på nettsiden brukeren befinner seg. Footeren inneholder både gateadressen og kontaktinformasjon til Nordic Funding. På footeren har brukeren også mulighet for å lese igjennom personvern, generelle vilkår, hjelp og andre nyttige informasjon som knytter seg til Nordic Funding. Det finnes også alternativer til å følge bedriften på Facebook, Titter eller Google. Side 70 av 133

Figur 76: Footer kart Figur 77: Footer 4.5.2 Kontakt oss Det er mulighet for alle besøkende av nettsiden å sende inn en henvendelse på noe de lurer på til bedriften. De trenger da bare å fylle inn sin egen e-postadresse, hva det gjelder(emne) og beskrivelse. Når det trykkes på send vil avsender få tilsendt kopi på epost og det vil bli sendt en epost til Nordic Funding. Dersom det oppstår feil med mail-tjenesten vil bruker få en melding at eposten ikke ble sendt, men henvendelsen blir fortsatt registrert i systemet. Side 71 av 133

Figur 78: Kontakt oss kart Figur 79: Kontakt oss Når en registrert, eller ikke registrert bruker har sendt inn en henvendelse til Nordic Funding får en beskjed om å bekrefte de informasjonene som har blitt tastet inn. Side 72 av 133

Figur 80: Kontakt oss bekreftelse 4.5.3 Om oss Her har brukeren mulighet til å lese om Nordic Funding. Både hvor de befinner seg og hvordan man kan kontakte dem. Figur 81: Om oss kart Figur 82: Om oss Side 73 av 133

4.5.4 Sider uten innhold Personvern, Generelle vilkår, Presse og Hjelp Oppdragsgiver har tenkt å komme med egen tekst på disse sidene. Sånn som dagens situasjon eksistere det ikke noe innhold for disse sidene. Figur 83: Sider uten innhold kart Figur 84: Sider uten innhold Side 74 av 133

4.6 Nettstedet for administrator Ansatte i Nordic Funding som er autorisert skal ha mulighet til å logge seg inn som administrator. De får da sitt eget grensesnitt hvor de kan utføre alle handlinger som de trenger for å opprettholde siden. 4.6.1 Administrator innlogging Administratoren blir logget inn ved hjelp av denne koden, koden er hasjet slik at man ikke kan inspisere koden på siden og se det originale passordet: login.php else if ($user == "admin@nf.no" && $hash_password == "d404559f602eab6fd602ac7680dacbfaadd13630335e951f097af3900e9de176b6db28512f2e000b9d 04fba5133e8b1c6e8df59db3a8ab9d60be4b97cc9e81db") { $_SESSION["admin"] = true; echo "<meta http-equiv=\"refresh\" content=\"0;url=./admin/admin.php\">"; 4.6.2 Administrator hjem Første siden som en administrator kommer til etter innlogging. Ut ifra en global menyen kan administrator navigere seg frem til det som ønskes. Logg ut knappen befinner seg alltid øverst til høyere. Figur 85: Administrator hjem Side 75 av 133

4.6.3 List ut alle brukere På denne siden kan administrator se alle brukerne av systemet og de tilhørende informasjonene. Siden det blitt nokså mye informasjon om hver bruker må man benytte bruk av scrolling. Figur 86: Liste ut brukere 4.6.4 Legge til ny bruker Administrator kan legge til en ny bruker, og det fungerer ganske likt,som når en bruker registrerer seg selv. Først velger administrator en type bruker som skal registreres og går videre derifra med taste inn ønsket informasjon. Figur 87: Ny bruker Side 76 av 133

4.6.5 Slett bruker For å slette en bruker skriver administrator inn brukernummeret til brukeren som skal bli slettet. Figur 88: Slett bruker Systemet finner en bruker med det oppgitte brukernummeret hvor det blir listet opp informasjon om brukere og man må bekrefte slettingen av brukeren. Figur 89: Bekreft sletting Side 77 av 133

Hvis brukeren har aktive prosjekter kan ikke brukeren bli slettet uten at prosjektene har blitt fjernet først. For å redigere disse kan man trykke på Endre prosjekter som vist på bildet under. Etter å ha utført dette kan man prøve å slette brukeren på nytt. Figur 90: Endre prosjekter 4.6.6 Rediger bruker På samme måte kan man redigere brukere. Man taster inn brukernummeret til brukeren som man ønsker å redigere. Figur 91: Rediger bruker Side 78 av 133

Man får deretter opp informasjonen om brukeren hvis brukeren eksisterer i systemet og kan derifra velge om man vil redigere som vist under. Figur 92: Rediger bruker Side 79 av 133

4.6.7 List ut alle prosjekter Admin kan se en liste over alle prosjekter/låneønsker med alle detaljer. På denne måten skal admin ha mulighet til å slette/endre disse. Figur 93: List ut prosjekter 4.6.8 List ut alle bud Admin har også mulighet for å gjøre dette for bud også. Her ser vi en liste av bud der investorer har bydd på de forskjellige prosjektene. Figur 94: List ut bud Side 80 av 133

4.6.9 List ut låneavtaler Til slutt kommer låneavtaler. Denne lister ut alle de aktive låneavtalene mellom investor og låner. Figur 95: Aktive låneavtaler Side 81 av 133

4.7 Feilhåndtering Alle skjemaer er programmert slik at systemet gir en tilbakemelding til bruker dersom et eller flere felt er fylt ut feil eller hvis det mangler informasjon fra bruker. Hvis bruker skal komme seg videre må alle felt være fylt ut riktig. Denne type feilhåndtering er også referert til i use case beskrivelser som variasjoner. Disse variasjoner kan være alt fra mangel på informasjon, feil i inntastet informasjon eller andre feilmeldinger. Se vedlegg H for komplett use case beskrivelser. 4.8 Database Vi lagde en database ved å tegne en ER-modell og deretter fylle inn alle attributter i tabellene. Med denne ER-modell kunne vi ved hjelp av MYSQL Workbench lage et SQL script som oppretter databasen for oss. Dette scriptet inneholder et sett med instruksjoner som skaper databasen med alle dens verdier. Den skaper tabeller med navn og tilhørende kolonner med navn for innsetting av data. Dette kjøres på serveren ved hjelp av Putty verktøy og en enkel kommando. mysql -u s180386 -h cube s180386 < nordicfunding.sql Fordelen ved å ha et SQL script er at hvis man skal opprette databasen på nytt så er det bare å kjøre dette scriptet. For SQL database script se vedlegg J. Side 82 av 133

5. Testing 5.1 Brukertesting Hensikten med vår brukertesting var å forbedre systemet ut ifra brukerens behov og forståelse. Selv om vi forstår systemet og syns det er brukervennlig er det viktig å få synspunkter fra brukerne da de ikke vet på forhånd hvordan forskjellige funksjoner skal brukes. Vår oppdragsgiver ga oss en liste med 13 mulige brukere som vi kunne teste siden på. Vi valgte å sende en epost med oppgaver og spørreundersøkelse til alle da det kunne hende vi ikke ville få svar av alle. Likevel skulle en brukertest kunne holde med kun fem brukere (Nielsen Norman Group, 2000). Ved bruk av fem testere er det stor sjanse for å finne mange problemer innenfor brukervennlighet. Med flere enn fem brukere får man mye repetisjon og det vil være liten sjanse for at den sjette bruker vil komme med noe nytt. 5.2 Gjennomføring Vi lagde en spørreundersøkelse der brukeren skulle svare på noen spørsmål etter å ha utført noen oppgaver. For å se spørreundersøkelsen se vedlegg L. Nettsiden har to forskjellige brukertyper og det ga et behov for to forskjellige oppgavesett, disse er å finne i vedlegg M. Oppgavene gikk ut på at bruker skulle teste ut bestemte funksjoner. Ved å få brukerne til å gjøre bestemte oppgaver ville vi klare å få oversikt over hva vi måtte forbedre av eventuelt funksjoner, eller hva som kunne forandres ut ifra brukerens ønsker og behov. Den første oppgaven gikk ut på at de skulle browse gjennom siden for å få et inntrykk av siden og da spesielt med tanke på design. De neste oppgavene gikk ut på teste de forskjellige funksjonene som å registrere seg, logge inn og redigere profil. Etter at alle oppgavene var gjennomført skulle brukerne ta en spørreundersøkelse angående oppgavene de nettopp hadde gjort. Spørreundersøkelsen skulle finne ut om alle funksjoner fungerte som de skulle og at funksjonene på sidene var enkle å bruke og forstå. 5.3 Resultater 5.3.1 Funksjoner Selv om vi ikke fikk svar fra alle brukerne vi sendte brukertesten til fikk vi veldig gode og utfyllende svar fra de som tok den. Noe som gikk igjen i tilbakemeldingene vi fikk var at siden alt i alt så fin ut. Likevel støtte noen av brukerne på et par problemer når de skulle fullføre oppgavene de ble gitt da noen funksjoner ikke fungerte som de skulle. Det var også noen funksjoner som ikke var brukervennlig da noen brukere ikke forsto helt hva de skulle gjøre for å fullføre oppgaven. Et par brukere kunne tenke seg en forklaring til de forskjellige utfyllingsboksene på registreringsskjemaet, Side 83 av 133

som f.eks. at et organisasjonsnr skal inneholde 9 tall. Det var en funksjon som ikke fungerte under brukertesting og det var å få lagt inn et bud. Hele 4 av 5 brukere hadde problemer med dette og den største og nesten eneste årsaken var at de fikk en error (se figur 96). Brukerundersøkelsen fortalte oss at funksjonene var forståelige og fungerte bra, men vi fikk noen tilbakemeldinger på at det var noen småting som kunne endres. En ting nesten alle brukerne nevnte i brukerundersøkelsen var at endring av profil kunne være litt vanskelig fordi det var lite forståelig. Når en bruker skulle endre profil så fikk de opp blanke felter slik at det kunne se ut som at informasjon ble slettet og man måtte fylle inn alle feltene på nytt for å gjøre en endring. Vi endret derfor dette til at informasjonen som allerede var lagret vistes i utfyllingsboksene ved endring av profil. Brukertesten fortalte oss alt i alt at funksjonene på nettsiden var intuitive og enkle å bruke, men at det dukket opp noen feilmeldinger og at alle funksjoner ikke alltid fungerte som de skulle. Figur 96: Brukertesting resultater 5.3.2 Design Første inntrykket til de fleste som tok spørreundersøkelsen var at siden var veldig fin. Det var ingen som hadde noe negativt å komme med på denne delen. Alle syntes dessuten at fargevalget på nettsiden fungerte meget bra (se figur 97). Vi har også fått tilbakemeldinger på mail, hvor de sier at designet fungerer bra og at siden er oversiktlig og enkel. Det var noen brukere som kunne tenkt seg mindre tekst og flere bilder. Oppdragsgiver ville gjerne ha all tekst på siden. Så vi har prøvd å få til en mellom ting slik at bruker ikke blir overveldet av alt for mye tekst. Flere av brukerne likte også godt bildekarusellen på startsiden fordi det ga et godt og profesjonelt inntrykk. Vi fikk en del tilbakemeldinger på at teksten på nettsiden inneholdt en del skrivefeil og at språket kunne ha tendenser til å bli litt tungt. Som sagt var oppdragsgiver fast bestemt på å skrive innholdet til Side 84 av 133

nettsiden. Derfor valgte vi å ikke endre noe på hvordan setninger var formulert, men rette opp i skrivefeilene med fokus på knappet og overskrifter. Figur 97: Brukertesting resultater Figur 98: Brukertesting resultater Side 85 av 133

5.4 Kvalitets- og browsertesting på ulike plattformer Testing av nettsiden er viktig og det er fordi at man ønsker gjerne at nettsiden er lesbar i ulike nettlesere. Det er viktig at det ikke finnes en underliggende kode som skaper problemer for andre nettlesere. Vi tester i de fem største nettlesere (Firefox, Safari, Chrome, Opera og Internet explorer) og de seks mest brukte plattformer (Pc, Mac, Android nettbrett, Android smartmobil, Ipad, Iphone). Nettsiden din vil se annerledes ut i ulike nettlesere. Det er fordi nettlesere forstår noen kode litt annerledes. Som utviklere må vi teste for å være sikre på at nettsiden fungerer godt i alle moderne nettlesere. Nye nettlesere blir mer og mer standard-kompatibel, så forhåpentligvis vil dette være mindre problematisk for oss. Side 86 av 133

Nettlesere Platform Funksjoner Oppløsning Zooming Scrolling Firefox v 22.0 Pc Ok Ok Ok Ok Firefox - Ipad - - - - Firefox v 28.0 Mac Ok Ok Ok Ok Firefox v 28.0.1 Android nettbrett Ok Ok Ok Ok Firefox v 28.0.1 Android mobil Ok Ok Ok Ok Firefox Iphone - - - - Safari v 5.1.7 Pc Ok Ok Ok Ok Safari v fant ikke Ipad Ok Ok Ok Ok Safari v 7.0.2 Mac Ok Ok Ok Ok Safari Android nettbrett - - - - Safari Android mobil - - - - Safari v fant ikke Iphone Ok Ok Ok Ok Chrome v 34.0.1847 Pc Ok Ok Ok Ok Chrome v 33.0.1750 Ipad Ok Ok Ok Ok Chrome v 34.0.1847 Mac Ok Ok Ok Ok Chrome v 18.0.1025469 Android nettbrett Ok Ok Ok Ok Chrome v 34.0.1847 Android mobil Ok Ok Ok Ok Chrome v 33.0.1750 Iphone Ok Ok Ok Ok Opera v 20.0.1387.91 Pc Ok Ok Ok Ok Opera v 7.0.5.45389 Ipad Ok Ok Ok Ok Opera v 20.0.1387.91 Mac Ok Ok Ok Ok Opera v Android nettbrett Ok Ok Ok Ok 21.0.1437,74904 Opera v 21.0.1437.74 Android mobil Ok Ok Ok Ok Opera Iphone - - - - Internet explorer v Pc Ok Ok Ok Ok 11.0.9600 Internet explorer Ipad - - - - Internet explorer Mac - - - - Internet explorer Android nettbrett - - - - Internet explorer Android mobil - - - - Internet explorer Iphone - - - - - : Betyr at vi ikke fikk testet nettleseren for gjeldende plattform. Ok : Betyr at det ble gjennomført uten problemer. 5.4.1 Resultater fra plattform og kvalitetskontroll Plattform og kvalitetskontrollen gikk uten problemer. Vårt system fungerte på ulike plattformer i forskjellige nettlesere. Noen av de forskjellige plattformene støttet ikke alle nettlesere og vi fikk derfor ikke testet på disse. Side 87 av 133

6. Konklusjon 6.1 Måloppnåelse Samarbeidet har gått veldig bra. Vi har hatt diskusjoner og uenigheter men det har løst på en grei måte. Arbeidsfordelingen i gruppen har vært noenlunde jevn. Alle gruppemedlemmer har vært flinke til å delta på møter og til å ta initiativ til å løse forskjellige arbeidsoppgaver. Vi har lært at korte arbeidsperioder fungerte best for å nå målene vi satte oss. Det ga mindre fallhøyde i tilfelle arbeid måtte endres eller forkastes. For eksempel hvis et gruppemedlem ble syk eller ikke kunne komme på møte nådde vi likevel målene våre i tide. Vi fikk tilegnet oss gode kunnskaper om bruken av at CSS rammeverk. Erfaringen vår har blitt større og bedre ved bruk av programmeringsspråk som HMLT5, JavaScript og PHP. 6.2 Konklusjon av produkt Vi hadde satt oss mange krav til prosjektet for fullstendig kravspesifikasjon se vedlegg I. Som vi forutså fikk vi ikke fullført alt vi hadde satt som krav til systemet. Vi fikk f.eks. ikke til å lage grafer for investor og bedrift. Det ble ikke gjort på grunn av mangel på kunnskap og ikke minst tid. Designet ble det brukt mye tid på. Det gikk igjennom flere faser og det gjorde at sluttproduktet ble bra. Hovedmålene vi satte oss i starten av prosjektet fikk vi utført på en god måte og det gjør at nettsiden og dens funksjoner fungerer fint. For fremtidig utviklere er denne koden enkel å vedlikeholde og videreutvikle. Oppdragsgiver har vært svært positiv gjennom hele prosjektet og ser frem til å ta i bruk nettsiden. Side 88 av 133

Vedlegg Side 89 av 133

Vedlegg oversikt Vedlegg A. Verktøy og hjelpemidler... 91 Vedlegg B. Kommunikasjon... 92 Vedlegg C. Risikoplan... 93 Vedlegg D. Milepælsplan... 95 Vedlegg E. Samarbeidskontrakt... 97 Vedlegg F. Prosjektdagbok... 99 Vedlegg G. Sekvensdiagram... 100 Vedlegg H. Use case beskrivelser... 101 Vedlegg I. Kravspesifikasjon... 109 Vedlegg J. SQL script for databasen... 112 Vedlegg K. Low-fi prototype... 116 Vedlegg L. Spørreundersøkelse... 126 Vedlegg M. Oppgaver til brukertestere... 131 Side 90 av 133

Vedlegg A. Verktøy og hjelpemidler For å oppnå målet vårt i dette prosjektet har vi benyttet forskjellige verktøy og tjenester som står beskrevet nedenfor : Fildeling, dokumentasjon og backup Google Drive - Brukt til lagring og redigering av dokumenter. Dropbox - Brukt til lagring av kode, dokumenter og bilder. Microsoft office - Brukt til redigering av rapporten. Putty - Brukt til å opprette og koble til database. Google Drive er Google sin nettbaserte kontorpakke. Brukeren har mulighet til å opprette dokumenter, presentasjoner, bilder, kalender og tegninger. Tjenesten er tilgjengelig for alle som har opprettet Google-konto. Google Drive tilbyr også fillagring og -deling, så våre dokumenter ble lagret der. Dropbox har vi brukt som backup for alle andre dokumenter, bilder, database og kode. Utvikling og web Penn og papir Netbeans - Brukt til kode. Notepad++ - Brukt til kode. WinSCP(FTP-klient) - Brukt til overføring av filer til skoleserver. XAMPP/MAMP - Brukt til å kjøre siden lokalt. MySQL workbench - Brukt til å lage og redigere ER modell. Microsoft Visio 2013 - Brukt til å tegne navigasjonskart. Nettleser - Brukt til å innhente informasjon og testet nettsiden. Utviklingsverktøy - programmeringsspråkene Vi har hatt frie tøyler når det gjelder hvilke verktøy vi skulle bruke under prosjektet. Det ene kravet vi fikk fra oppdragsgiver var at systemet skulle være lett å vedlikeholde. I tillegg skulle det være enkelt for andre programmerere å sette seg inn i ved videreutvikling av systemet. Vi har også valgt å utfordre oss selv med dette prosjektet og arbeide med et rammeverk. Vi utviklet nettstedet ved hjelp av disse fem språkene: HTML5 CSS - Bootstrap Javascript PHP SQL Side 91 av 133

Vedlegg B. Kommunikasjon Under prosjektet var kommunikasjonen i gruppen veldig bra. Vi hadde våre faste rutiner ved å komme hver dag, 4 dager i uken og jobbe sammen i fellesskap. Det gjorde det enklere for oss å holde motivasjonen oppe. Ved fravær var det viktig å ha respekt for de andre ved å gi beskjed hvis en ikke kunne komme. Vi har ikke støttet på noen problemer i forhold til kommunikasjon mens prosjektet har pågått. Alle har vært tilgjengelige og bidratt med det som var forventet. Vi har hatt en grei dialog med oppdragsgiver gjennom hele prosjektet. Det var viktig at han fikk se resultater underveis slik at han kunne komme med sine meninger hvis han eventuelt ønsket å forandre noe spesielt på nettsiden. Det er viktig at oppdragsgiver blir fornøyd med produktet og får det produktet han ønsker for bedriften. Vi har også hatt god kommunikasjon med vår veileder Torunn Gjester. Hun har både støttet og gitt oss gode råd som har bidratt til et bra og gjennomført resultat. Kommunikasjonsverktøy Telefoni/sms E-post Facebook Side 92 av 133

Vedlegg C. Risikoplan Risikoplanen er et dokument som lister opp hva som kan gå galt i dette prosjektet. Det er lurt å være forberedt på uventede problemer som kan oppstå. Ved en risikolån kan man planlegge hvordan man kan både unngå en del risikoer samtidig forberede seg på å håndtere problemet hvis det skulle oppstå. Konsekvens Svært liten Liten Moderat Alvorlig Svært alvorlig Sannsynlighet 5 Svært stor 6,1 1 3 4 Stor 5 2 3 Middels 7 2 Liten 1 Svært liten 4 Alvorlig risiko Moderat risiko Liten risiko 1. Sykdom: Om et gruppemedlem blir syk vil ikke det få alt for store konsekvenser fordi vi er mange gruppen, med mindre medlemmet er langtidssyk. 2. Ukjent verktøy: Hvis vi har et nytt verktøy som vi vil bruke kan vi eventuelt bruke lang tid, hvis vi ikke forstår det. Det kan føre til at vi ikke rekker å fullføre prosjektet tidsnok. 3. Tidsmangel : Det hender at ting kan ta lengre tid en forventet. Hvis det skjer må vi jobbe lengre enn planlagt. Siden vi er så motiverte til å både møte opp og arbeide så ville ikke det hatt noe alvorlige konsekvenser for prosjektet. 4. Tap av data : Det skal mye til for at dette skjer. Alle har lagret all data lokalt på sine datamaskiner, vi har også all data på Droppes og Google Drive. Hvis det skulle skjedd så ville det hatt svært alvorlige konsekvenser for prosjektet. 5. Ujevn fordeling av arbeidsoppgaver : Siden vi er 5 på gruppen så er det stor sannsynlighet for at dette skjer. Men siden vi har såpass god dialog og godt samarbeid prøver vi å unngå det slik at alle er med på arbeidet. Konsekvensene ville ikke vært så alvorlige. Side 93 av 133

6. Mangel på oppmøte : Når vi er så mange,så er det stor sannsynlighet for dette. Men alle er motiverte så det ville ikke ført til noe alvorlige konsekvenser. 7. Nettsiden vises forskjellig i ulike nettlesere : Det finnes sannsynlighet for at det vil skje. Ut ifra det vi vet så skal det aller meste vises i de aller fleste nettlesere. Hvis det ikke gjør det så er vi nødt til å ordne opp i det. Det ville ikke vært noe store konsekvenser. Side 94 av 133

Vedlegg D. Milepælsplan For å få oppgaver gjort og holde en god driv i prosjektet har vi valgt å lage milepælsplaner for to uker om gangen. Vår veileder foreslå at to ukers milepælsplaner kunne være en fin måte å jobbe på. Da ville vi ha litt mindre og flere mål å jobbe mot istedenfor noen få store. Ved å bare ha noen milepæler kunne det bli vanskelig å se hva som måtte bli gjort for å komme videre og man kunne ende opp med å bruke alt for lang tid på enkle oppgaver. Vi valgte likevel å sette en deadline for når vi ville være ferdig med programmering av funksjoner og design, og skriving av rapport, slik at vi ville være ferdig i god tid til innlevering for å kunne ha mulighet for å gjøre endringer eller rette opp i feil. Vi synes dette var en fin måte å jobbe på, da alle gruppemedlemmer alltid hadde oppgaver å jobbe med og det var enklere å komme i mål med de større milepælene. Milepælplan utdrag Uke 10-11 (3-14 mars) Sider skal ha brødsmuler. Lage innholdsfortegnelse for nettsiden. De punktene i uke 9 skal VÆRE FERDIG! Gjør sekvens diagram. Se nærmere på rapport (mål, grunn for prosjekt osv + bruk andre rapporter) Aktiviteter, at investor og bedrifter skal kunne se sine aktiviteter. Investor skal kunne legge inn bud. Låntaker skal kunne se og redigere sine lån ønsker. Fikse FAQ - Vi har ikke innhold for FAQ. Oversette eller komme med litt innhold. Se igjennom tilbakemeldinger fra Sebastian/skrive konkret til Sebastian hva vi mangler. Fikse en mappestruktur på koden. Uke 9 (24-28 feb) Kalender funksjon skal være på plass. Vi skal teste ut et annet design på siden. Ordne slik at navnet kommer på siden når man logger inn. Fikse at låntager kan legge inn lån ønsker. Fikse at investorer kan få oversikt over alle lånønsker. Side 95 av 133