Telefon: Telefaks: Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Transkript

1 PROSJEKT NR. 30 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo BACHELORPROSJEKT TILGJENGELIGHET Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL Induct Entrepeneur Zone DATO ANTALL SIDER / BILAG 100 PROSJEKTDELTAKERE Ullvar Brekke (s236375) Kristoffer Pettersen (s239404) Eyvind Hatlevold Nielsen (s177748) INTERN VEILEDER Terje Gjøsæter OPPDRAGSGIVER Induct Software KONTAKTPERSON Morten Aamodt SAMMENDRAG Induct Entrepreneur Zone er utviklet av tre studenter på Høgskolen i Oslo og Akershus i samarbeid med Induct Software. Induct Entrepreneur Zone er en digital møteplass for oppstartsbedrifter og investorer med muligheten til å automatisk matche bedrifter og investorer ut i fra brukerens preferanser. Denne matchingen skjer ved hjelp av en lærende og intelligent algoritme, som er selvutviklet av studentene på gruppen. Hos Induct Entrepreneur Zone kan brukere registrere seg, se gjennom andre brukere og vise interesse for potensielle samarbeidspartnere. Induct Entrepreneur Zone setter to parter i kontakt når begge har vist interesse for hverandre. Utviklingen har foregått i Visual Studio med teknologier som Angular 2,.NET og Web API. 3 STIKKORD Webapplikasjon Digital møteplass Maskinlæring

2 ii

3 Forord Denne oppgaven er gitt av Induct Software til å utvikle en webapplikasjon for oppstartsbedrifter og investorer som skal formidle kontakt mellom disse. «Induct Entrepreneur Zone» (arbeidstittel) er et prosjekt som Induct Software i lengre tid har tid ønsket å gjennomføre, men som er blitt nedprioritert i mangel på ressurser. Det ble holdt et møte i November 2016 sammen med kontaktperson Morten Aamodt og CTO i Induct Software Tor Andre Johansen, om å lage rammeverket til Induct Entrepreneur Zone. Vi vil i resten av rapporten omtale Induct Entrepreneur Zone som IEZ. For investorens del skal det bli lettere å finne det markedsområdet investoren er interessert i og man vil bli skjermet fra stor pågang fra oppstartsbedrifter man ikke er interessert i. For oppstartsbedriften vil det bli lettere å finne investeringer. Denne rapporten inneholder en del kode så noe kjennskap til programmeringsspråk er nødvendig. Vi vil rette en takk til Induct Software og spesielt Morten Aamodt som har hjulpet oss og gjennomføre dette prosjektet. Dette er den avsluttende rapporten for vårt bachelorprosjekt ved Høgskolen i Oslo og Akershus. Oppgaven er utført av tre studenter ved ingeniørfag data. Ullvar Brekke Eyvind Hatlevold Nielsen Kristoffer Pettersen s s s

4 Innholdsfortegnelse 1 INNLEDNING ARBEIDSGIVER PROBLEMET MÅL Kravspesifikasjon BESKRIVELSE AV INDUCT ENTREPRENEUR ZONE FORUTSETNINGER OG BEGRENSNINGER LESERVEILEDNING TEORI TEKNOLOGIER Angular 2 og typescript Bootstrap, HTML og CSS NET og C# Entity Framework og SQL-database API Alternative teknologier DESIGN AV GRAFISK BRUKERGRENSESNITT Farger Innhold og informasjon Universell utforming Tilpasning til mobil plattform GOD PRAKSIS Generell god praksis ved programmering Angular MASKINLÆRING SIKKERHET EKSISTERENDE TJENESTER

5 3 PROSESS PLANLEGGING Fremdriftsplan Verktøy til utviklingsprosessen Skisser for grafisk design av IEZ Valg av teknologier UTVIKLING Design av grafisk brukergrensesnitt Universell utforming Stack Registrering av bruker Innlogging og utlogging Brukerside Administrasjonsside Matching-funksjon Sikkerhet Tilpasning på mobile enheter PRODUKT GENERELLE FUNKSJONER BRUKER ADMINISTRATOR TESTING SYSTEMTEST AKSEPTANSETEST ENHETSTESTING OG INTEGRASJONSTESTING DISKUSJON FRONTEND Lokalisering av funksjonaliteter knyttet til matching Funksjonalitet på mobile enheter Forbedringer av grafisk brukergrensesnitt FORBEDRINGER OG BRUK AV MATCHING FUNKSJONEN SIKKERHET BACKEND

6 6.5 VALG AV VERKTØY PROSESS OG PLANLEGGING Samarbeid med Induct Software TESTING KONKLUSJON VIDERE ARBEID BESKRIVELSE AV INDUCT ENTREPRENEUR ZONE - DEN ENDELIGE APPLIKASJONEN FLERE FUNKSJONALITETER REFERANSER VEDLEGG

7 1 INNLEDNING 1.1 ARBEIDSGIVER Kontaktperson hos Induct Software: Morten Aamodt Induct Software er et norsk programvareselskap som leverer programvare for innovasjonsledelse. Induct Software leverer innovasjonssamfunn som kunder kan bruke til å samle ideer, dele utfordringer eller kjøre kampanjer. Induct Software jobber med å knytte disse innovasjonssamfunnene sammen i nettverk for å oppfordre til deling av kunnskap på tvers av ulike organisasjoner. Gjennom 9 år har Induct Software bygget opp en portefølje av kunder fra flere forskjellige sektorer; helse, offentlig, og privat. 1.2 PROBLEMET Aldri før har det blitt registrert så mange oppstartsbedrifter i Norge som nå. Disse bedriftene ønsker å komme seg ut på et eksisterende marked eller skape nye. Teknologibedrifter står for en stor del av de nye bedriftene som blir registrert, og det er enkeltmannsforetak som står for den største andelen (1). Av disse oppstartsbedriftene er det få som klarer seg og ofte er problemene at de slipper opp for penger, har mangelfull forretningsmodell eller problemer med å skaffe seg investorer (2). Induct Entrepreneur Zone skal gjøre det lettere for oppstartsbedrifter å finne de ressursene som trengs. Ved å hjelpe disse bedriftene med å overleve er sjansen for at flere bedrifter får utviklet sine ideer større. Dette kan hjelpe Norge med å bli et mer innovativt land. Norge lå i 2016 fortsatt et stykke ned på lista i EU sin årlige undersøkelse European Innovation Scoreboard men har muligheten til å vise ny og innovativ teknologi ved at oppstartsbedrifter får muligheten til å ferdigutvikle produktene sine (3). Ideen kommer fra et av Induct Software sine kontor i Brasil hvor de har en avdeling som holder en årlig gründer-konkurranse hvor oppstartsbedrifter kan vise seg frem for et kvalifisert panel med mennesker som rangerer bedriftene. De beste vil bli sendt videre til investorer som kan vise sin interesse for disse oppstartsbedriftene (4). Dette er en ide som Induct Software også ønsker å innføre til Norge. Dessverre er det for få oppstartsbedrifter i Norge til å kunne holde en konkurranse 7

8 på samme måte, så Induct Software var på utkikk etter en enklere løsning for at oppstartsbedrifter skal kunne møte investorer. Den overordnede funksjonen til IEZ er å gjøre det enklere å investere i eller skaffe midler til en oppstartsbedrift. En oppstartsbedrift kan være i forskjellige faser og kan derfor trenge forskjellige typer ressurser. En bedrift som bare har en ide kan trenge lokaler eller en incubator så de får laget prototyper. De som allerede har prototyper klare kan trenge en mindre økonomisk investering til å starte produksjon, mens en annen bedrift kan være i ferd med å bli en stor bedrift og trenger en større økonomisk investering. Investorer har forskjellige interesser, og det er ikke alltid like lett for en oppstartsbedrift og avgjøre om en investor er interessert i oppstartsbedriften. Problemer fra investorenes side kan være å finne riktige bedrifter å investere i og å håndtere stor pågang fra bedrifter man ikke er interessert i. Det kan også hende at en oppstartsbedrift ikke har interesse av å samarbeide med noen typer investorer. Det finnes allerede en del løsninger som samler oppstartsbedrifter og investorer, men tradisjonelt sett fungerer disse løsningene gjennom at man enten samler en stor database med bedrifter, eller inviterer til ulike arrangementer hvor man kan møtes ansikt til ansikt og knytte kontakter. 1.3 MÅL Det finnes andre tjenester som benytter samme type metode til å få parter til å møtes. Dating tjenester som Tinder benytter brukerens interesser for å finne relevante partnere mellom single personer, hvilket er en metode IEZ skal bruke for å finne riktige forretningspartnere. IEZ skal være med å skape en arena der både investoren og oppstartsbedriften skal kunne finne sin perfekte partner uten å måtte kontakte eller bli kontaktet av kandidater som ikke er av interesse. Målet med denne oppgaven er utvikle en fungerende webapplikasjon som løser problemene nevnt i 1.2 og som har et godt rammeverk for videreutvikling. IEZ skal gjøre prosessen rundt investering og ressurssamling enklere for både investorer og oppstartsbedrifter. IEZ skal ha en enkel og uformell, men likevel seriøs fremtoning. Med matchingen vil oppstartsbedriften vite at investoren er interessert i produktet, og IEZ vil sette små bedrifter i direkte kontakt med interesserte investorer. Et overordnet mål satt av oppdragsgiver er at IEZ etter hvert skal utvides med flere funksjoner og tilrettelegges for nye brukergrupper. 8

9 1.3.1 Kravspesifikasjon Gjennom samtaler og diskusjoner med Induct Software ble denne kravspesifikasjonen designet. Innledning Gruppen skal utvikle en webapplikasjon for Induct Software. Formålet med webapplikasjonen er å lage en digital møteplass for investorer og oppstartsbedrifter, med hovedfokus på å matche investorer og oppstartsbedrifter. Bakgrunn/Behov Induct Software har vært involvert i oppstartsprosjekter før, blant annet 100 open startups, som er en fysisk arena som matcher oppstartsbedrifter med investorer. Det finnes mange løsninger, både fysiske og digitale, som har som mål å sette sammen oppstartsbedrifter og investorer. Selv om det finnes en del tilbud så ønsker Induct Software å komme med en forbedret versjon der brukere blir presentert et mer tilpasset innhold. Hensikt med kravspesifikasjon Hensikten med kravspesifikasjonen er å gi et klart bilde på hva som må utvikles i forhold til de mål som blir satt. Kravspesifikasjonen skal bestå av krav som må oppfylles og andre krav som Induct Software ser som nyttige og ha, men som ikke er nødvendige. Kravspesifikasjonen er utarbeidet i samarbeid med Induct Software og gruppen. Beskrivelse av systemet Webapplikasjonen som utvikles skal ha et brukergrensesnitt for brukere og administratorer, samt et grensesnitt for registrering av nye brukere. Brukere skal kunne få opp potensielle matcher og se sine endelige matcher. Brukergrensesnittet for administrator skal kunne ha enkele funksjoner for sletting og endring av brukere. 9

10 Krav Funksjonelle krav Brukere skal kunne registrere seg ved å skrive inn relevant informasjon. Brukere skal kunne logge seg inn Investorer og oppstartsbedrifter skal kunne matches Matching skal fungere en til en Det skal lages en enkel administrasjonsside for sletting og endring av brukere Ikke-funksjonelle krav Webapplikasjonen skal være enkel å bruke for investorer og oppstartsbedrifter Det skal tilrettelegges for videreutvikling av webapplikasjonen Rammekrav Innsetting og uthenting av informasjon skal skje via web-api..net skal brukes som rammeverk i backend Koden skal være på engelsk Språket som brukes i webapplikasjonen skal være på norsk Webapplikasjonen skal være funksjonell på mobile enheter, men ikke optimalisert 1.4 BESKRIVELSE AV INDUCT ENTREPRENEUR ZONE For at IEZ best mulig skal kunne gi både oppstartsbedriften og investoren de resultatene de ønsker, må både investor og oppstartsbedrift fylle ut et registreringsskjema som kartlegger hvilke områder hver av partene er interessert i og hva de har å tilby. Når brukeren er registrert vil de få tilgang til hovedfunksjonaliteten i webapplikasjonen. Brukeren får opp en liste over potensielle partnere filtrert på bedriftens preferanser, og melder sin interesse for de som virker interessante. Denne listen med 10

11 potensielle partnere blir generert av en algoritme som vil bli nærmere forklart senere i kapittel Algoritmen vil benytte registreringsskjema og sammenligne feltene brukeren har fylt ut med tilsvarende skjema hos andre brukere. Med denne informasjonen klarer IEZ å presentere en liste med potensielle partnere som de har mest interesse av å samarbeide med, og vil presentere de mest aktuelle først. Rangeringen vil endres etter hvert som brukeren benytter IEZ. Eksempelvis så er noe av det viktigste for en investor produktet og hvilket fagfelt dette produktet dekker (5). IEZ vil prioritere oppstartsbedrifter som lager det produktet investoren er på utkikk etter og presentere disse først. Hvis begge parter har vist interesse for hverandre blir det en match, og man kan opprette kontakt. Man kan ikke ta kontakt med hverandre uten å matche. En administrator kan også logge inn på IEZ for å få oversikt over diverse informasjon som en vanlig bruker ikke har tilgang til. Administratoren skal ha lister over alle brukere og mulighet til å administrere disse. 1.5 FORUTSETNINGER OG BEGRENSNINGER Gruppen består av tre studenter med erfaring fra det som er undervist i obligatoriske og valgfrie fag på Høgskolen i Oslo og Akershus. Undervisningen har gitt oss grunnleggende kunnskap om noen av systemene som er benyttet i bacheloroppgaven. I oppgaven skal det utvikles en algoritme som sorterer resultater basert på et registreringsskjema som brukeren fyller ut. Hvis mulig ønsker gruppen å benytte en form for maskinlæring. Høgskolen tilbyr ingen undervisning av dette i skolegangen så gruppemedlemmene må sette seg inn i dette på egenhånd. Induct Software kom med et begrenset sett med krav, noe som har resultert i en fleksibel kravspesifikasjon. Gruppen har stor frihet til å løse oppgaven sånn de selv ønsker. Det er ikke benyttet noen ressurser fra Induct Software som databaser eller kode som de har utviklet tidligere. Alt i denne oppgaven er utviklet av gruppen. 11

12 1.6 LESERVEILEDNING Navn, ord og uttrykk i denne rapporten har så langt det er mulig, blitt oversatt til norsk. Der hvor vi ikke har kunnet finne gode norske alternativer, har vi valgt å benytte original form navn, ord og uttrykk. Det vil spesielt bli nevnt to ord, frontend og backend. Frontend refererer til forsiden av IEZ eller delen av webapplikasjonen som kjører i klienten sin nettleser. Backend refererer alt som har med Web API og funksjonalitet knyttet til database å gjøre, som kjører på server. Resten av rapporten er organisert på følgende måte: Kapittel 2 inneholder relevant teori. Kapittel 3 beskriver prosessen og gir begrunnelse på de valg som har blitt tatt, basert på teorien gitt i kapittel 2. Kapittel 4 skal fungere som en brukerveiledning og gi et bilde av hvordan IEZ fungerer for brukere og administrator. Kapittel 5 vil ta for seg den testingen som har blitt utført på IEZ. Kapittel 6 diskuterer prosessen og resultatene. Avsluttningsvis inneholder kapittel 7 og 8 konklusjon og videre arbeid. 12

13 2 TEORI For å løse de overordnede utfordringer og mål, er det viktig å ta i bruk riktige arbeidsverktøy, metoder og teknologier. Det vil i dette kapittelet bli gjennomgått relevant teori som støtter innholdet i kapittel TEKNOLOGIER I dette kapittelet blir både Angular 2 og Bootstrap beskrevet som frontend rammeverk. Angular 2 er hovedsakelig et rammeverk som knytter seg til funksjonalitet, mens Bootstrap sitt rammeverk er knyttet til grafisk design Angular 2 og typescript Angular 2 er et komplett frontend rammeverk basert på javascript. Det er hovedsakelig utviklet for å gjøre utviklingen av SPA (Single-page-applications) lettere. Angular 2 bruker typescript som hovedspråk, altså det språket det kodes i, for så å transpilere (6).ts filene til standard javascript filer. Fordelen med dette oppsettet er at man får en ryddig og oversiktlig kode med typescript, se figur 2.1. Samtidig har man filer i javascript - som kan kjøres på nært sagt alle web-servere og nettlesere. Figur 2.1: Ser her at kodeeksempelet til Typescript er ryddigere og mindre en Javascript eksempelet. Angular 2 tilbyr muligheten til å utvikle på flere plattformer slik som web for mobil, web for desktop, native mobil og native desktop. Ved hjelp av server-side rendering oppnår angular-applikasjoner høy 13

14 hastighet. Server-side rendering vil si at sidene i webapplikasjonen gjøres klare med innhold før de sendes til klienten. Angular 2 sitt bibliotek er bygget fra grunnen av slik at alle komponenter passer godt sammen. Angular 2 gjør det enkelt å integrere kode i html-maler, slik at webutvikling gjøres på en rask og god måte. (7) Bootstrap, HTML og CSS HTML eller HyperText Markup Language er et markeringsspråk for formatering av nettsider med hypertekst og annen informasjon som kan vises i en nettleser. (8) CSS eller Cascading Style Sheets er et språk som brukes til å definere utseende på filer som er skrevet i HTML eller XML. (9) Bootstrap, med sin åpne kildekode, er et gratis frontend-rammeverk for nettsider og webapplikasjoner. (10) NET og C#.NET er et rammeverk utviklet av Microsoft. Rammeverket er en samling av flere verktøy som blir brukt til programvareutvikling..net bruker blant annet C# og Visual Basic som programmeringsspråk. (11) C# eller C Sharp er et objektorientert programmeringsspråk utviklet av Microsoft. C# er basert på java og C++ og er designet for å være raskt og kraftig. Det er hovedspråket i utviklingsverktøyet Visual Studio. (12) Entity Framework og SQL-database Entity Framework er et rammeverk utviklet av Microsoft til bruk i applikasjoner som krever tilgang til data fra database. Entity Framework gjør det mulig for C#-objekter å bli lagret direkte i databasen. Det fokuserer på å gjøre koblingen mellom database og applikasjon lettere, ved å eliminere mye av koden som må til for å hente data fra databasen. Man har to innfallsvinkler til Entity Framework; Code first eller Design first. Code First betyr at databasetabellene blir automatisk generert fra 14

15 modeller i applikasjonen. Velger man Design First går man andre veien, det vil si at man designer tabellene og modeller i applikasjonen blir generert automatisk. Structured Query Language (SQL) database blir brukt for å lagre data som brukes i applikasjonen. (13) (14) API API står for Application Programming Interface, som er et grensesnitt i en programvare som lar deler av denne kjøres fra annen programvare. API brukes blant annet i webapplikasjoner slik at de kan gjøre endringer, kjøre prosesser eller på annen måte behandle data. Det er ofte slik at APIet benyttes til å kommunisere med en database. Det er ved hjelp av API mulig å utvikle kun en databaseløsning som kan brukes av flere applikasjoner. (15) Alternative teknologier Ettersom krav til teknologier knyttet til backend er satt av Induct Software, så beskriver dette kapittelet alternativer til teknologier som knytter seg til funksjonaliteter i frontend. Det er her vanlig å bruke en form for javascript, selv om språk som php også kan brukes. Når det kommer til bruk av javascript så finnes det en lang liste over rammeverk og biblioteker. Akkurat som antallet rammeverk og biblioteker, så finnes det mange bruksområder. Et godt alternativ er facebook sitt javascript bibliotek React. React og Angular 2 deler noe av den samme funksjonaliteten slik som server-side rendering og de er begge komponent-basert. Med React Native så er det også mulig å utvikle applikasjoner som kjører på mobile plattformer. En av fordelene med React er Reacts virtuelle DOM eller domeneobjektsmodell (16). Når en endring skjer hos klienten, oppdateres kun de elementene som ble endret. Dette skjer ved at React sammenligner den virtuelle DOM med den hos klienten. Dette gir raskere kjøring av webapplikasjonen. Siden React og Angular 2 begge baserer seg på javascript, så er det mulig å bruke React til å assistere Angular 2 der det er nødvendig. Problemet oppstår når det blir mange bindinger mellom html og Angular 2. Dette resulterer i en tregere webapplikasjon siden Angular 2 oppdaterer hele DOM for hver endring som skjer. For å hjelpe Angular 2 så kan derfor React taes i bruk, slik at det er kun de endrede elementene som blir oppdatert. Selv om det er mulig å utvikle applikasjoner ved hjelp av kun et bibliotek eller rammeverk, så kan ofte en sammensetning være beste løsning. 15

16 2.2 DESIGN AV GRAFISK BRUKERGRENSESNITT Farger Når det kommer til design og utseende på en nettside/webapplikasjon så er det viktig å tenke på bruk av farger. Noe av det viktigste med fargevalget er fargen på logoen. Det er ut fra logoen at man kan bestemme resten av fargevalget på siden. Grunnen til at man velger resten av fargene på siden ut fra logoen er at fargene først og fremst skal komplimentere hverandre på en måte som gjør det behagelig for brukeren å se på siden. Det er viktig at logoen din syns godt på siden, det er tross alt den brukerne forbinder med produktet. For å få logoen til å synes godt på siden, er det viktig å velge aksentfarger på resten av siden som fremhever logoen. Når farge på logoen er bestemt så kan det velges ut to til tre andre aksentfarger for resten av siden. Her burde sekundærfargen til logoen brukes til å fremheve knapper og overskrifter som er viktig. Dette kan være registrering/login og overskrifter på siden. Videre så kan den tredje fargen på siden brukes på mindre tekst og andre skille elementer på siden. Når det kommer til bakgrunnsfarge på siden så må denne velges ut fra hva man ønsker å promotere på siden. Hvis det er en side som skal selge et produkt burde det velges en nøytral eller hvit farge. Hvis dette er en siden som promoterer et merke eller tjeneste så burde fargen enten settes som en nyanse av logoen, slik at siden blir forbundet med merket. Det er også mulig å velge farge på bakgrunnen ut fra hva slags type tjeneste dette er. Farger som er av typen grønn forbindes ofte med natur og helse. Farger som er av type gul representerer ungdommelighet og positivitet. På samme måte så representerer fargene av type blå mer trygghet, sikkerhet og fredfullhet. (17) Innhold og informasjon Plasseringen av informasjon på siden er viktig. Det er viktig slik at brukeren vet hvor den kan finne ting og slik at siden blir lett å navigere. Det er mulig å lage sider som er lette å navigere men som ser 16

17 veldig rotete ut. Selv om dette er mulig så kan det som regel være greit å begrense informasjonen på siden til det mest nødvendige. Det er også lurt å plassere elementene på siden på en måte som brukeren vanligvis er vant til. Dette kan for eksempel være å plassere navigasjonsfeltet øverst på siden, eller på en av sidene. Det er også vanlig å plassere generell informasjon slik som kontaktinformasjon nederst på siden. Den viktigste informasjonen plasseres som regel på midten av siden, det er gjerne det første stedet som brukeren fester blikket etter å ha gått inn på siden. (18) Universell utforming Universell utforming går ut på å forme en nettside slik at den er tilgjengelig for alle. Dette betyr at nettsiden skal være tilgjengelig for personer med nedsatt funksjonsevne, for eksempel blinde, døve, fargeblinde, personer med lærevansker eller nedsatt motorikk. Det finnes retningslinjer for hvordan dette skal oppnåes for websider, nemlig WCAG 2.0 (Web Content Accessibility Guidelines). Disse er utviklet i samarbeid med enkeltpersoner og organisasjoner over hele verden, med hensikt å komme frem til en felles standard for tilgjengelig webinnhold som dekker behovene til enkeltpersoner, organisasjoner og myndigheter verden over. (19) Man kan beskrive disse retningslinjene med 4 hovedpunkter: Mulig å oppfatte Informasjon og brukergrensesnitt må kunne presenteres for brukere slik at de kan forstå det Mulig å betjene Brukergrensesnitt og navigasjon må kunne brukes av alle Forståelig Informasjon og operasjon av brukergrensesnitt må være forståelig Robust Innholdet må være robust nok til at alle kan bruke det, også hjelpe-teknologier (tekst til tale, øyestyring etc.) Tilpasning til mobil plattform I 2014 ble mobiltelefonen på verdensbasis oftere brukt til å søke opp informasjon enn en datamaskin (20). Derfor er det viktig å få gjort webapplikasjonen brukbar på mobile enheter for ikke å miste 17

18 brukere. Det er gjort en oppdatering i googles søkemotor som nedprioriterer nettsider som ikke er klargjort for mobile enheter, som igjen vil resultere i færre brukere (20). Når en webapplikasjon skal tilrettelegges for mobile enheter er det ingen fastsatte regler for hvordan dette gjøres men det finnes mange tips og triks for å gi en god brukeropplevelse. For at brukeren skal få lik opplevelse av siden uavhengig av hvilken enhet som blir brukt må all informasjon som er tilgjengelig for brukeren på datamaskin også være tilgjengelig på mobile enheter. Ved å bruke design som er responsivt til brukerens enhet kan man lage webapplikasjoner som lett tilpasse seg de forskjellige størrelsene på mobile plattformer. Informasjonen som skal vises vil da skalere eller vises på en annen måte som bedre passer størrelsen på enheten som brukes. 2.3 GOD PRAKSIS Generell god praksis ved programmering Det er i teorien mulig å skrive en hel applikasjon i en fil, men dette ville gjort utvikling og vedlikehold veldig vanskelig. Derfor er det greit å ha litt kunnskap om god praksis. Det kan være lurt å kommentere kode og beskrive hva de forskjellige metodene gjør. Kommentering og dokumentering er hovedsakelig til størst hjelp for nye utviklere som skal jobbe på applikasjonen. Det skal ikke være nødvendig å kommentere selvforklarende variabler eller deler av kode. (21) Selve koden burde også være behagelig å se på. Her er det lurt å bestemme seg for en måte å strukturere funksjoner, tester og løkker. Her må det avgjøres om for eksempel krøll-parentesene skal ligge på samme linje som funksjons-navnet eller om de skal komme på neste linje. Ved å ha slike retningslinjer vil det blir lettere å lese koden. Det er ikke alltid like viktig å tenke på dette når koden skrives, ettersom mange utviklingsmiljøer har innebygd funksjon for dette. (21) Hvis funksjoner inneholder flere deler med kode som gjør forskjellige ting, så kan det være lurt å skille de forskjellige delene med et mellomrom. (21) Forskjellige programmeringsspråk, har forskjellige retningslinjer når det kommer til navngiving. I enkelte språk er det vanlig å gi navn til klasser på formen min_klasse, mens i andre språk er det vanlig 18

19 å skrive det som minklasse. Har ikke programmeringsspråket noen preferanser når det kommer til navngiving, er det viktigste at navngivingen er konsekvent i hele applikasjonen. (21) Navngiving av variabler burde være beskrivende, med unntak av midlertidige variabler som ofte brukes i løkker. Midlertidige variabler kan godt være så korte som en bokstav. (21) Unngå, så lenge det ikke er nødvendig, å lage funksjoner med flere tester inni hverandre. Selv om det ikke går utover funksjonaliteten til applikasjonen, så kan det være vanskelig å lese. Her burde testene struktureres, kanskje deles opp, slik at funksjonaliteten er den samme men koden blir lettere å lese. (21) Lengden på kode-linjene bør ikke bli for lange. Selv om det ikke er noen grense på hvor lange linjer kan være, blir det utfordrende å lese en hel klasse eller funksjon som er skrevet på en linje. (21) Angular 2 Utover det som er skrevet over, har også Angular sin egen stilveiledning. Her er det hentet ut noen av de viktigste punktene. En-regelen Definer en ting per fil, slik som enten en service eller komponent. Ved å kun definere en ting per fil, blir koden mye lettere å lese, vedlikeholde og oppdatere. Det blir også mindre forekomster av skjulte feil som kan oppstå ved at flere klasser bruker samme variabler. Målet er å gjøre koden lettere å lese, lettere å gjenbruke og mindre utsatt for feil. Det er også en fordel å begrense filer til maks 400 linjer med kode. (22) Små funksjoner Det er best å lage små funksjoner, helst på ikke mer enn 75 linjer. Fordelen med små funksjoner er at de er lettere å teste, gjenbruke, lese og vedlikeholde. Det er vanskelig å finne skjulte feil dersom en funksjon blir veldig omfattende. (22) 19

20 Retningslinjer for navngiving Det er lurt å være konsistent når filer og typer skal navngis. Navngivning bør generelt skje ved at egenskap skrives først også hva slags type det er, altså i formen egenskap.type.ts. Ved å ha slike retningslinjer for navngiving så blir det lettere å lokalisere innhold. Hovedformålet med navngiving er å kunne gjøre det lettere å finne ønsket del av koden. Navn på klasser skal starte med stor bokstav. Navn på symbol og fil skal stemme overens. Hvis filen heter app.component.ts så skal symbol-navnet være på formen AppComponent. (22) Bootstrapping Legg bootstrapping og plattform-logikk til applikasjonen i en fil som heter main.ts. Applikasjonslogikk skal ikke legges i main.ts, men i en egen komponent, gjerne app.component.ts. Dette gjør at applikasjonen følger standard startoppsett for oppstart. (22) Avstand på importeringer Det kan være greit å skille mellom tredjeparts importeringer og importeringer fra applikasjonen. Importeringer kan også listes i alfabetisk rekkefølge. Det blir da lettere å skille mellom hva som har blitt laget i applikasjonen og hva som kommer utenfra. (22) Struktur på applikasjonen og Angular moduler LIFT LIFT(Locate, Identify, Flat, Try to be DRY). Applikasjonen skal struktureres slik at det er lett å lokalisere kode og identifisere kode raskt. Hold så flat struktur som mulig og prøv å være DRY (Don t repeat yourself). Strukturen på applikasjonen skal følge disse fire retningslinjene, prioritert i gitt rekkefølge. Ved å følge en slik struktur blir applikasjonen lett skalerbar, og effektiviteten ved utvikling øker. (22) Locate Ved å holde relaterte filer nærme hverandre i en logisk filstruktur, blir filene lettere å lokalisere. Dette er også en stor fordel når andre utviklere skal komme inn for å jobbe videre på applikasjonen. (22) 20

21 Identify Filer skal navngis slik at det er lett å identifisere hva de gjør basert på navnet. Dette gjør at utviklingen blir mer effektiv ved at man slipper å bruke mye tid på å lete etter filer. (22) Flat Strukturen skal, så langt det er mulig, være flat. Hvis en mappe har 7 eller flere filer, bør det lages undermapper. For å holde en flat struktur ved utvikling, kan det være greit å konfigurere utviklingsmiljøet til å gjemme genererte.js og.js.map filer, som uansett er irrelevante og ikke skal editeres. Ved å holde en flat struktur blir det lettere å lokalisere relevante filer. (22) T-DRY(Try to be DRY) Gjentakelse skal unngås, så lenge det ikke går utover lesbarheten. Det er Try to be DRY ettersom dette er foretrukket, med mindre det går utover andre elementer i LIFT. Det er lite hensiktsmessig å kalle en mal ettersom.html sier i seg selv at dette er en mal. Unntaket her er hvis noe ikke er åpenbart, da kan det være hensiktsmessig å gitt et mer beskrivende navn. (22) 2.4 MASKINLÆRING Maskinlæring er en gren av kunstig intelligens. Maskinlæring går ut på å designe og utvikle algoritmer som gjør datamaskiner i stand til å lære fra og utvikle atferd basert på empiriske data. Hovedfokuset til maskinlæring er å lære gjenkjenning av komplekse mønstre og gjøre intelligente beslutninger basert på data. (23) 2.5 SIKKERHET Passord: Et passord skal helst ikke lagres noe annet sted enn i hodet til eieren. Men for at en applikasjon skal kunne vite hvem det er som logger på, må man ha denne informasjonen tilgjengelig et eller annet sted. Problemet blir da hvis noen utenforstående får tilgang til denne informasjonen. Man vil helst lagre disse passordene et sted, uten at de har brukbarhet for inntrengere som får tak i dem. Dette kan hindres ved å kryptere passordene før de blir lagret. Kort forklart betyr dette at man kjører passord-teksten i gjennom en krypterings-funksjon som gjør de ubrukelige i kryptert form, og lagrer 21

22 de i databasen. Når en bruker skal logge inn, kjører man denne funksjonen på nytt. Hvis teksten som kommer ut passer med teksten som er i databasen, er det riktig passord og brukeren får logget inn. Hvis en angriper får tilgang til alle passordene i databasen, vil ikke dette ha noe å si siden passordene er ubrukelige hvis ikke man vet hva det originale passordet er. Når man skal velge krypterings-måte, er det greit å kartlegge hva som er viktig når man har med passord å gjøre. For det første må man gjøre passordet uleselig for alle når man skal lagre det. Det skal ikke gå for noen å lese passordet til brukeren. Hvis brukeren glemmer sitt passord, så må brukeren lage et nytt. Dette kan man få til ved hjelp av hashing, som er en form for enveis kryptering. Hashing fungerer slik at man transformerer den originale teksten ved hjelp av en algoritme, slik at man får en tilfeldig tekst som er umulig å reversere. For det andre må man velge egnet kryptering. Når man skal velge krypteringer er det lurt å ta hensyn til hvilke områder krypteringen skal dekke. Om passord-kryptering sier ietf.org (internet engineering task force) dette: Krypteringen må være enveis, og algoritmen må være med hensikt treg. Den må kunne itereres igjennom mange ganger, og hver algoritme må gjøres unik ved hjelp av en ekstra parameter, et såkalt salt. Det finnes mange forskjellige krypteringsalgoritmer der ute, og man kan se nærmere på de mest brukte: PBKDF2 (Password based key derivation function 2) En krypteringsalgoritme som bruker en pseudo-tilfeldig funksjon for å produsere en nøkkel. Funksjonen krever en del arbeid for å kjøre, noe som gjør dette til en ganske treg algoritme. Algoritmen kan gjentas på en tekst flere ganger. (24) SHA 256 (Secure hash algorithm) En algoritme som bruker flere funksjoner for å produsere en nøkkel. Dette er en algoritme som krever lite arbeid, og blir derfor ansett som veldig rask. Siden dette er en rask algoritme blir SHA helst brukt til andre krypterings-behov. (25) 22

23 BCRYPT Fungerer på samme måte som PBKDF2. Den har valg av antall ganger itereringer, og inneholder også et salt. I tillegg til dette er BCRYPT en adaptiv algoritme. Det vil si at den kan øke antall itereringer over tid, slik at algoritmen blir tregere. (26) Token og informasjonskapsler: En brukerbasert nettside må kunne identifisere og validere en bruker kontinuerlig gjennom hele brukerens sesjon. Dette kan oppnås ved å lagre brukerens identitet et sted hvor webapplikasjonen har tilgang, enten som en cookie eller en token. Informasjonskapsel (Cookie): Når en bruker logger inn vil serversiden opprette en sesjon i en database, og brukeren vil få tilsendt en id som passer til denne sesjonen, en såkalt sesjons-id. Denne består som regel av et navn, en utløpsdato og en unik signatur. Hver gang brukeren gjør et kall vil serversiden først sjekke informasjonskapselens autentisitet ved hjelp av signaturen, for så å sjekke brukerens id opp mot databasen og verifisere brukeren. (27) Token: En token vil ikke trenge å ha lagret en sesjon på en database. I hvert kall brukeren gjør til serveren vil det ligge en token i overskriften til kallet. Disse tokens blir så verifisert på serversiden. (27) En slik token er bygd opp av tre deler: - Header Inneholder info om hvordan token det er, og hvordan algoritme den er kryptert Med - Payload Inneholder generell informasjon. Det vil si hvem brukeren er, hva slags rolle den har, hvilket nettsted som har utstedt en token og når den går ut på dato - Signature en digital signering av en token som sier at en token er ekte og ikke har blitt forandret på. 23

24 Hver gang brukeren skal gjøre et kall som er beskyttet av innlogging, vil kallet sende med en token i overskriften på API-kallet. Serversiden vil ta tak i denne token og validere signaturen. Hvis den er ok, vil serveren sende et klarsignal om at denne brukeren er ekte, og API-kallet kan da gjennomføres. Deaktivering/Sletting av bruker: Det er delte meninger når det kommer til sletting av informasjon i en database. Generelt er det av flere grunner ikke god praksis å slette informasjon helt. Dersom en bruker ønsker å slette sin konto, men senere ønsker denne tilbake, vil ikke det være mulig. Det er også nyttig å beholde informasjon i databasen slik at denne senere kan brukes til analytiske formål. Sletting av brukere og annen informasjon kan heller fungere på en slik måte at det er et felt som settes til ikke-sann. På den måten så vil man kunne skille mellom brukere som er slettet og de som ikke er det. Det er også viktig å sette seg inn i de reglementer som finnes i det landet det opereres i når det kommer til lagring av informasjon. Validering av input fra bruker: All input som kommer fra bruker må valideres for å kunne hindre sql-injection. (28) Sql-injection går ut på å bruke felter for input på siden til å sende potensielt skadelige sql-spørringer som kan slette og endre innhold på databasen. Det er også mulig å sende skadelige sql-spørringer direkte til APIet, så det holder ikke å validere input fra bruker kun i frontend. Entity framework sin parametrisering av sql spørringer hindrer dette, siden spørringene blir generert før man setter inn variabler fra brukeren. Har man mulighet for å laste opp filer på applikasjonen er dette et stort sikkerhetshull. Et vanlig scenario er å ha et inputfelt for bildeopplastning. Dette kan lett utnyttes for å laste opp andre filer, for eksempel et script som kan kjøres i backend. 24

25 2.6 EKSISTERENDE TJENESTER Det finnes allerede noen kommunikasjonstjenester til bruk for investorer og oppstartsbedrifter. Nedenfor presenteres noen av de mest aktuelle konkurrentene til IEZ. Gust: Gust tilbyr tjenester som Gust Launch, som hjelper å opprette bedriften din og Gust Equity Management, som hjelper til med administrasjon av eierskap. I tillegg kan man søke blant Angel Investors og Venture capitalists for å få penger til støtte eller søke blant akseleratorer for hjelp til utvikling av bedriften. Gust tilbyr tjenester for oppstartsbedrifter, investorer og akseleratorer. Gust har integrerte funksjoner til å diskutere avtaler og følge disse opp. (29) Angel.co: Hos Angel.co kan privatpersoner søke jobb i oppstartsbedrifter, eller en oppstartsbedrift kan utlyse en stilling. Enkeltpersoner kan investere i oppstartsbedrifter med deal-by-deal investering, Angel investering eller professional investor. (30) Younoodle: Younoodle er en tjeneste til å arrangere konkurranser og rekrutteringsprosesser for å finne entreprenører. (31) Den største konkurrenten til IEZ vil være Gust. Disse tilbyr mange av tjenestene som IEZ vil ha og litt ekstra. Med rammeverket som blir lagt til grunn i IEZ vil det være mulig å utvikle et produkt med mye funksjonalitet som kan sammenlignes med Gust, men som vil kunne overgå konkurrentene på grunn av kombinasjon mellom funksjonaliteten og IEZ sin evne til å tilpasse potensielle partnere. 25

26 3 PROSESS Prosessen for utvikling av IEZ vil bli gjennomgått i dette kapittelet. Kapittelet om prosess drøfter og forsvarer de valgene som har blitt tatt og gir en forklaring på bruk av arbeidsverktøy, metoder og teknologier presentert i kapittel PLANLEGGING Det var viktig for oss i planleggingsfasen å få klargjort så mye som mulig av funksjoner på forhånd så vi kunne lage en realistisk arbeidsplan for hele prosjektet. Siden ingen av gruppemedlemmene hadde jobbet på et prosjekt av denne størrelsen før, hadde vi lite erfaring med å sette tidsrammer på hvor lang tid de forskjellige delene av prosjektet skulle ta. Ved å ta utgangspunkt i tidligere prosjekter gjorde vi et så realistisk anslag som mulig Fremdriftsplan Fremdriftsplanen (Vedlegg 2) viser at rapportskrivingen går fra uke 4 og til uke 21. Det skal være fokus på rapporten under hele utviklingsperioden men ekstra fokus på kun rapport de siste fire ukene. Utvikling og planlegging overlapper med en uke fordi oppsett av prosjektet og planleggingen foregår samtidig. Utviklingsfasen går frem til og med uke 12 hvor undertitler forklarer nærmere hva som utvikles i disse ukene. Mesteparten av tiden under utviklingen blir brukt på å lage et solid rammeverk for videre utbygging av IEZ og algoritmen til å finne relevante matcher. Til slutt kommer testing og bugfix som vil avslutte utviklingen av appen og de siste ukene vil gå med til rapportskriving Verktøy til utviklingsprosessen Teknologier og verktøy vi har brukt for å hjelpe oss med prosjektet. Trello Trello gjør det mulig for grupper å opprette tavler. På hver tavle er det mulig å legge til kort. Kortet beskriver en oppgave som må utføres. Alle brukere som har tilgang til tavlen kan sette seg selv opp på ett av kortene og da vet de andre at den oppgaven utføres. Trello er gratis og nyttig til bruk i store og små prosjekter med flere gruppemedlemmer (Figur 3.1) 26

27 Figur 3.1: Bilde av Trello-tavlen. Git/Github Git er et versjonskontroll-verktøy som holder styr på historien til kildekoden. Github brukes til å legge ut kildekoden slik at alle medlemmene av gruppen har tilgang på kildekoden. Google Calendar Med Google Calendar så er det mulig å opprette en felles kalender for alle medlemmene på gruppen. Dette gjør det lettere for gruppen å vite når man skal møtes for å jobbe, og å vite når det er møter med veileder og bedrift. Google Docs Google Docs brukes for å samle all dokumentasjon og logger som har med prosjektet å gjøre. Dette gjør skriving av rapport enklere ettersom alle kan skrive i samme dokument til enhver tid. Det gjør også at alle i gruppen har tilgang på alt av dokumentasjon hele tiden. Det er også i Google Docs at gruppen har hatt sin felles fremdriftsplan. 27

28 Figur 3.2: Øverst vises den orginale planen. Nederste er revudert utgave fra uke 12. Slack Slack er et kommunikasjonsverktøy som hovedsakelig brukes til å holde gruppemedlemmene oppdatert om fremgangen i prosjektet. Dette gjøres ved at Slack tilbyr utvidelser som kan integreres med verktøyet. De utvidelsene som gruppen har brukt er: - Oppdateringer når kildekoden endres på github. - Oppdateringer når avtaler legges til eller slettes i kalenderen, samt varsel når en avtale skal skje. - Oppdateringer når kort legges til eller endres på trello-tavlen. Visual Studio (IDE) I dette prosjektet har Visual Studio vært brukt som integrert utviklingsmiljø. Visual Studio tilbyr funksjonalitet som gjør det mulig å utvikle både backend og frontend i samme miljø. Visual Studio er et utviklingsverktøy laget av Microsoft. Det er et fullstendig verktøy med editering av kode, design av database, debugger og andre innebygde designløsninger. 28

29 3.1.3 Skisser for grafisk design av IEZ For å kunne angi hvilke metoder og funksjoner som skulle være med i IEZ ble det laget enkle skisser for å forutse hvordan en bruker ville gå igjennom siden. Dette ble førsteutkastet til designet av IEZ og er brukt som en mal for å lage designet. Nedenfor er en gjennomgang av skissene som ble brukt for å planlegge grensesnittet for registrering av en investor. Brukeren får valget om de vil registrere seg som oppstartsbedrift eller investor (Figur 3.3). Figur 3.3: Skjerm som redegjør for om det er investor eller startup som skal registreres. Neste side skal inneholde de spørsmålene som redegjøre for hvilke områder en investor har interesse for (Figur 3.4). 29

30 Figur 3.4: Første del av registrering for investor. Til slutt kommer investoren til den siste delen av registreringen hvor grunnleggende informasjon om eieren registreres (Figur 3.5). Figur 3.5: Siste del av registreing for investor. 30

31 Alle skissene danner et lite nettverk av bilder som gjør det lettere å se hvilke html-sider som må lages (Figur 3.6). Figur 3.6: Oversikt over nettverket med skjermbilder. Ved å sette opp skissene på denne måten kan det i tillegg benyttes som et enkelt flytdiagram som sørger for at IEZ får en fin flyt for brukeren. Det er nyttig for å sørge for at alle knapper får logiske plasser og at innholdet på siden er relevant med hva man trykker på Valg av teknologier Frontend Når det kommer til bruk av teknologier i frontend, sto gruppen fritt til å velge i forhold til kravspesifikasjon. Det ble diskutert å bruke diverse javascript-biblioteker og rammeverk, men det har vært lite fokus på utvikling av webapplikasjoner i studiet, så kunnskapene var begrenset. Med så mange forskjellige muligheter og få retningslinjer fra Induct Software så ble det et vanskelig valg. Det ble til slutt bestemt at Angular 2 skulle brukes. Dette var et rammeverk som var noe kjent fra gruppen tidligere. Angular 2 sitt programmeringsspråk typescript er godt likt av mange utviklere og det er også et språk som mange utviklere ønsker å bruke. Angular er også noe av det mest brukte rammeverket blant utviklere. (32) 31

32 Ettersom Angular tilbyr raske og universelle applikasjoner og et oversiktlig programmeringsmiljø med typescript, og samtidig er veldig populært, så framstod det som et godt alternativ. Det er også interessant å lære et populært rammeverk med tanke på senere arbeid. IEZ bruker også Bootstrap ettersom det finnes en del gratis maler. Med Bootstrap spares det mye tid på utviklingen med tanke på at mye av arbeidet allerede er gjort. Bootstrap er også et rammeverk som veldig mange bedrifter bruker og det er helt klart relevant å lære seg med tanke på videre karriere. Backend I backend bruker IEZ.NET som rammeverk. Selve APIet og databasefunksjonene er skrevet i C#. Visual Studio var et naturlig valg siden Induct Software ønsket.net og C# som teknologier etter som det er dette de benytter seg av i sine eksisterende løsninger. Gruppen har programmert en del i Java, og C# er ikke så veldig ulikt med hensyn til syntaks. Det var viktig for gruppen å bruke teknologier i backend vi følte oss trygge på, med tanke på at rammeverket og programmeringsspråket i frontend er nytt og ukjent. En annen fordel med Visual Studio er at dette er et fullstack utviklingsverktøy. Alle lag, fra frontend-html til databaselaget kan utvikles i Visual Studio. Dette gjør at gruppen slipper utfordringer som versjons-konflikter og kompatibilitetsproblemer. Gjennom.NET og Visual studio finnes også tilgang til flere mindre rammeverk og verktøy som gjør utviklingsprosessen lettere. IEZ tar i bruk både Entity Framework og MySQL for å lagre data i databasen. Dette gjør IEZ robust, med tanke på at alle rammeverk i backend er laget for å fungere optimalt sammen. 32

33 3.2 UTVIKLING Design av grafisk brukergrensesnitt Det er viktig å kunne gi testbrukere et godt inntrykk av hva IEZ kan gjøre og hvordan et sluttresultat kan bli. For å ha et gjennomgående tema i IEZ har vi benyttet Bootstrap som er forklart nærmere i kapittel Dette frontend rammeverket har ferdigutviklet design som gjør at siden vil fungere på skjermer av alle størrelser og at knapper og menyer holder det samme tema gjennom hele siden. IEZ har fått et enkelt design med blå og hvit som hovedfarger. Det er tidligere diskutert hvordan den blå fargen er en farge som kan symbolisere trygghet og sikkerhet. Det er brukt forskjellige nyanser av blåfargen på de sidene som trenger å deles opp. Hovedsiden har en litt lysere blåfarge der det står informasjon om hva IEZ er. Det vises en ramme rundt registrer-knappen når man ikke er logget inn. Dette setter fokus mot denne knappen for å få nye brukere til å registrere seg. Er man innlogget har man oversikt over potensielle matcher som er listet opp i prioritert rekkefølge etter relevans, og den mest relevante informasjonen om investoren/oppstartsbedriften vises sammen med et profilbilde. For å redigere profilen til brukeren har vi benyttet en modal (33). Vi har valgt å bruke en modal i stedet for en ny side fordi det skaper en bedre flyt i siden og gjør navigasjonen enklere ettersom bruker forblir på samme side. Dette er viktig for oss da vi setter fokus på enkelhet i IEZ Universell utforming For å gjøre IEZ mest mulig tilgjengelig for alle, kan man gått gjennom WCAG 2.0 sine 12 hovedretningslinjer for tilgjengelige nettsider. Dette fører til at IEZ kan brukes av alle, og vil også gjøre IEZ generelt mere brukervennlig. Det finnes forskjellige nivåer av konformitet man kan gå etter, herunder A, AA og AAA. (A er minimum, AAA er maksimum). (19) 33

34 RETNINGSLINJER 1. Mulig å oppfatte 1.1 Tekstalternativer til ikke-tekst innhold IEZ har et tekstalternativ til alle bilder som vises på siden. Dette alternativet er laget ifølge vanlig html standard, og kan brukes av hjelpeteknologier. Denne teksten vil også dukke opp hvis bildet ikke lastes. 1.2 Alternativer til tidsbasert media Vi har ingen tidsbasert media på siden vår, så dette punktet utgår. 1.3 Mulighet til å tilpasse innhold til å presenteres på forskjellige måter Vår side er skalerbar i størrelse, og tekst og bilder vil ikke bli borte i en eventuell forstørrelse. Elementene på siden vil også tilpasse seg en eventuell forandring på nettleseren. 1.4 Mulig å skille innhold fra hverandre Kontrast på forgrunn og bakgrunn (tekst mot farge) er på 5.13:1, som er innenfor WCAG 2.0 sine retningslinjer (4.5:1). (A) Farge på navigeringsmenyen er laget med en enda større kontrast (Svart/Hvitt), slik at denne alltid er synlig, selv når scrolling gjør at navigeringsmenyen overlapper med annen tekst. IEZ er også testet med zoom-funksjon i alle nettlesere, slik at størrelse på tekst kan økes med 200%. (AA) 2. Mulig å betjene 2.1 All funksjonalitet er tilgjengelig med tastatur Brukere kan navigere seg rundt på hele siden ved hjelp av tabulator-tasten. Dette gjør at alle funksjoner er tilgjengelig med tastaturet 2.2 Gi brukere nok tid til å lese og bruke innhold Vi har ingen tidsbegrensning på noe av vårt innhold, slik at dette punktet utgår 34

35 2.3 Ikke utform innhold som på en måte er kjent for å forårsake anfall Vi har ikke innhold som kan føre til anfall, så dette punktet utgår. 2.4 Gjøre det mulig for brukere å navigere, samtidig som de vet hvor de befinner seg Vi har overskrifter på alle hoved - og undersider, slik at brukeren vet hvor den befinner seg til enhver tid. Vi har også lagt opp navigeringen slik at en bruker alltid har tilgang til hver underside til hovedsiden den befinner seg på. Dette gjør at en bruker ikke trenger å navigere seg via sider for å komme til målet sitt. 3. Forståelig 3.1 Gjøre innholdet leselig og forståelig Nesten all tekst i IEZ er brukerstyrt, slik at det er opp til brukeren selv å skrive innhold. Denne vil ha en viss kvalitetssikring i og med at brukeren selv vil framstå som forståelig for andre brukere. Tekst som er applikasjonens egen, er gjort så selvforklarende som mulig. 3.2 Gjøre nettsiden forutsigbar Vi har gjort siden forutsigbar ved at navigasjonsmenyen alltid befinner seg på samme sted. Innhold vil også vises på samme sted hver gang. Innhold og meny vil også skalere seg parallelt med vinduet, slik at posisjoneringen blir konsekvent. IEZ har også elementer plassert på konvensjonelt vis. Dette betyr at sidens logo ligger alltid øverst til venstre, og meny ligger øverst til høyre. Innhold på siden vises sentralt. 3.3 Hjelpe brukere med å unngå feil på brukerinput Det er brukt HTML required Attribute som gjør at ingen felter i et skjema kan være tomme når skjemaet skal sendes inn. Alt av utfylling blir sjekket av siden, og brukeren vil få informasjon om hvor feilen befinner seg. Det var et problem med Mozilla Firefox der hintet om hvor feilen befant seg ikke ble vist. For å sørge for at brukeren skal kunne se hvor feilen befinner seg er det lagt til en rød ramme på felter som ikke er fylt ut, og en grønn ramme på felter som er riktig fylt ut. Siden vil også sjekke riktig utfylling av epost, og om passordet stemmer med det brukeren ville skrive inn. 35

36 4. Robust 4.1 Maksimere kompatibilitet med alle slags nettlesere, både nåværende og fremtidige All html kode inneholder de riktige start og avslutnings tagger. ID på forskjellige elementer har også egne unike navn Stack IEZ er bygd opp av tre lag; Backend, Web API, og Frontend (figur 3.7). Backend er laget som kommuniserer med databasen, Web API er kommunikasjons-laget mellom backend og frontend, og frontend er det brukeren ser og interagerer med. Frontend-laget snakker med backend-laget gjennom Web APIet ved hjelp av http-spørringer. Frontend sender en spørring til Web APIet, og Web APIet sender et svar basert på hva frontend spør om. Figur 3.7: Oppbygningen av IEZ. Dette kan for eksempel være et spørsmål om å få listet opp alle investorer som er registrert i databasen. Klienten sender spørsmålet, og APIet sender et OK tilbake med alle investorer serialisert som JSON (34). (Dette er avhengig av at spørsmålet kommer fra en validert bruker. Om dette ikke er tilfelle, vil svaret være at du ikke har lov til denne operasjonen). 36

37 Backend Figur 3.8: Et forenklet klassediagram over backend. I figur 3.8 ovenfor er et forenklet klassediagram over backend. Investor/Startup/Admin modellene har blitt samlet sammen i en modell kalt Entity for denne modellen. Dette for å lettere vise logikken. Backend er satt opp slik at klassene definerer databasen ved hjelp av et rammeverk kalt Entity Framework. Entity Framework fungerer slik at det genereres en database ut i fra modeller skrevet av utviklerne. Som et eksempel kan vi ta utgangspunkt i en modell som skal representere en oppstartsbedrift. Denne vil bestå av flere felter som vil være attributtene til bedriften. Dette er attributter som 37

38 oppstartsbedriften lagret når den registrert e seg (epost, lokasjon, ønsket investeringsbeløp etc.) Når man genererer databasen for første gang vil Entity Framework se etter slike modeller, og lage tabeller basert på modellens attributter. En modell som vist i figur 3.9 vil generere en tabell som vist i figur 3.10: Figur 3.9 Databasemodell for en oppstartsbedrift Id (Int) Name Owner Location Figur 3.10: Databasetabell for en oppstartsbedrift. Variablene vil være de samme som i klassen. Dette gjør at utviklere bare trenger å konsentrere seg om koden, og ikke sette opp databasen og koden hver for seg. 38

39 Entity Framework finner disse modellene, samt hvordan man kobler seg til databasen, i en egen klasse kalt DatabaseContext.cs. Dette er en klasse som beskriver oppsettet til databasen. Her kan man også bestemme om man vil generere tilfeldige attributter til databasemodellene, som kan være lurt når man tester produktet. Alle metodene som tar for seg logikken mellom databasen og backend er i en egen klasse kalt iezdb.cs. Disse metodene inneholder forskjellige spørringer som programmet kan gjøre til databasen. Disse spørringene er skrevet i.net Language-Intergrated query (LINQ). Dette er en måte å lage spørringer på som integrerer objektorientert programmering med spørringer til databasen. I et Entity Framework miljø opererer LINQ direkte på modellene du har definert, slik at man kan bruke disse modellene i spørringene. Som et eksempel kan vi se på metoden som brukes når man lagrer en investor i databasen: 39

40 Figur 3.11: Metode for lagring av investor. I figur 3.11 blir et investor-objekt tilsendt fra brukerens registreringsskjema i frontend-laget, med attributter som brukeren har skrevet inn. Metoden vil så opprette et nytt objekt og tilegne variablene fra det tilsendte objektet til det nye objektet. Den vil så finne tabellen Investors i databasen, og legge dette objektet til. Til slutt returnerer metoden en boolsk verdi basert på om registreringen var vellykket eller ikke. I denne klassen er det også laget ulike metoder som av sikkerhetsmessige grunner ikke kan ligge i frontend. Dette er metoder som krypterer passord, sjekker passord-input fra brukeren opp mot det krypterte passordet som ligger lagret i databasen, generering av tokens og validering av tokens. 40

41 Web API Figur 3.12: Et forenklet klassediagram over web APIet. Investor/startup/Admin kontrollere har blitt til Entities, for enkelhets skyld. All kommunikasjon mellom frontend og backend går gjennom et Web API (figur 3.12). Dette er et grensesnitt som ligger på serversiden og fungerer basert på http spørringer. APIet består av ulike kontrollere basert på modellene i backend som tar seg av spørringer til sine respektive modeller. Dette fungerer slik at frontend bruker en URL basert på kontrollerens navn og metode for å sende spørringen. For eksempel: Hvis frontend trenger å hente ut alle investorer registrert i databasen, sender den en url som ser slik ut: Denne vil da sende spørringen til APIet, så til investor-kontrolleren, og så til slutt finne fram metoden kalt GET. Hvis alt er ok vil frontend få et svar fra denne URLen som inneholder alle investorer som er registrert. Selve metoden i kontrolleren tar spørringen og sender den til backend-metoden som 41

42 snakker med databasen. Backend vil da sende informasjon tilbake til kontrolleren, som kontrolleren sender videre til frontend som en http-melding. Når en http-spørring blir sendt fra frontend til kontrolleren, vil den også inneholde diverse annen informasjon i overskriften til spørringen, også kalt header. Dette vil være informasjon om hvilket format spørringen er i, og hvilket format man vil at svaret skal være i.iez opererer med JSON formatet (JavaScript Object Notation). Dette er et format som lett kan konvertere et C#-objekt til lesbar tekst i et javascript-objekt. Dette gjør at attributtene til objekter man får fra backend lett kan finnes fram og vises i frontend. I overskriften til spørringen vil det også sendes med en token, som verifiserer at brukeren kan gjøre spørringen. Hvis brukeren ikke er logget inn på siden, vil den heller ikke kunne utføre spørringer til APIet. Mer om dette under sikkerhet. Et eksempel på en http-spørring kan være at IEZ vil hente ut informasjon om en oppstartsbedrift. Man starter med å sende spørringen fra frontend. Figur 3.13 viser metoden som sender spørringen og, hvis alt går bra, får svar. Den sender med et tall som tilsvarer IDen til den oppstartsbedriften man vil ha info om. Metoden oppretter en overskrift til spørringen. Denne inneholder informasjon om formatet, samt en token som tilhører brukeren. Denne tokenen brukes til autentisering. Så blir selve spørringen sendt. I dette tilfellet vil den først bli sendt til oppstartskontrolleren, så til en metode kalt GET som tar imot en parameter ( API/startup/GET/ +ID). Hvis alt går bra vil metoden få et svar returnert som en json-streng. Figur 3.13: Metode i frontend som henter informasjon om oppstartsbedrift. 42

43 I kontrolleren har vi GET(int ID) metoden. Figur 3.14 viser metoden GET som tar imot en parameter kalt id, og returnerer en http-melding. Det første den gjør er å hente ut en token fra overskriften, og validerer denne. Hvis dette går bra, finner metoden den riktige oppstartsbedriften basert på IDparameteren ved hjelp av en metode som ligger i backend (IEZDB.cs sin getstartup). Oppstartsbedriften blir så serialisert til en JSON-streng. Dette fordi formatet må være JSON slik at frontend skjønner hva dette er. Hvis alt har gått bra returnerer metoden JSON-strengen sammen med en statuskode OK. 43

44 Figur 3.14: GET metode i API-Controller som henter og returnerer informasjon om oppstartsbedrift. 44

45 Frontend Figur 3.15: Viser hvordan bruker komuniserer med web API både med beskyttet og ikke beskyttede sider gjennom Auth.Gard. IEZ er bygd opp som en blanding av single-page application design (SPA) og multi-page application design (MPA). Den er en MPA i den forstand at den har egne html-sider for de forskjellige hoveddelene av siden. Dette innebærer login-siden, hovedsiden, registreringssiden, administratorsiden og brukersiden. Siden er også en SPA fordi hovedsidene som regel består av flere undersider. 45

46 På grunn av størrelsen på IEZ passet det best å lage denne som en MPA. Dette fører til oversiktlig kode, og koden er også delt opp slik at sidene fungerer uavhengig av hverandre. Dette betyr at selv om en del svikter, kan man fortsatt bruke den andre delen. Har man derimot en webapplikasjon kun bygd opp som MPA, vil dette føre til lange lastetider på steder hvor brukeren navigerer hyppig imellom undersider. Dette løses ved å bygge opp siden som en overordnet MPA, men med SPA design på de forskjellige hovedsidene. Dette fører til oversiktlig kode og oppbygning, og samtidig korte lastetider på de forskjellige undersider. Angular er også optimalisert for SPA ved at det laster opp hele hovedsiden med en gang, slik at en bruker kan navigere seg rundt uten lastetider. En anonym bruker vil bare ha tilgang til hovedsiden, loginsiden og registreringssiden. For at brukeren skal få tilgang til brukersiden, må den gjennom en autorisering i form av en vaktpost (se figur 3.15). Denne fungerer slik at hver gang brukeren klikker seg inn til en side som krever en autorisering, må den gjennom en vaktpost-funksjon som sjekker om brukeren er ekte. Det samme gjelder for administratorer, bare at her er det en egen administrator-vaktpost som sjekker autentisiteten. Når brukeren logger inn vil en egen tjeneste kalt auth.service sende passordet som brukeren skriver inn til backend gjennom APIet. Dette vil bli sjekket opp mot databasen, og returnere OK og en token avhengig om passordet er riktig. Auth.service legger så denne token i nettleserens lokale lagringsplass. Denne blir så brukt av vaktposten i validerings-prosessen. Alle sidene snakker med API.service tjenesten. Denne tjenesten tar for seg alle spørringer til APIet. Matching.service er tjenesten som tar for seg alt som har med matching å gjøre. Dette innebærer selve algoritmen som bestemmer hvordan brukere ser andre brukere på siden. 46

47 Mappestruktur Nedenfor gis en beskrivelse av mappestrukturen, dette gir et bedre bilde av stacken. Mappestrukturen består av hovedmapper som representerer de forskjellige lagene i IEZ. De er i all hovedsak delt opp i tre forskjellige mapper: App (Fig 3.16) Figur 3.16: Oversikt over mappestruktur for frontend. I denne mappen ligger frontend-filene. De er delt opp i undermapper som representerer hver side, samt undermapper som inneholder ulike verktøy. I hver undermappe som representerer en side ligger det en.html fil (dette er filen som brukere ser), en.css fil (inneholder informasjon om hvordan designet er) og to.ts filer (Denne ene inneholder funksjonene til siden, og den andre viser hvor IEZ kan finne den). 47

48 i app-mappen ligger det også en mappe kalt services, som inneholder felles funksjoner for frontend. Til slutt har vi en mappe kalt shared. Denne inneholder oppskrifter på ulike objekter som vi sender til backend (Investor-objekt, admin-objekt etc.). Controllers Figur 3.17: Mappe som inneholder kontrollere til web API og backend kode. Denne mappen inneholder kontrollere til web APIet (figur 3.17). Dette er klassene som tar seg av http-spørringene mellom frontend og backend. Det er en kontroller for hvert objekt i databasen. Database Figur 3.18 Mappen med backend-koden. Her har vi backend-koden (figur 3.18). DatabaseContext.cs er klassen som sier hvordan databasen skal se ut når den lages. Dbinitializer.cs fyller databasen med informasjon. Denne blir bare brukt når man skal teste IEZ. Errorlogger.cs tar seg av alle feilmeldinger og skriver disse ut til administratorene. Til slutt har vi Iezdb.cs. Denne tar seg av all logikken i backend. Dette er de viktigste strukturene. For en oversikt over hele strukturen, se vedlegg 1. 48

49 3.2.4 Registrering av bruker Før brukeren kan bruke alle funksjonene til IEZ må de registrere seg enten som investor eller som en oppstartsbedrift. Det er to forskjellige skjema, ett til hver type bruker, som de fyller ut og som senere blir benyttet i matching-funksjonen. Registreringsskjema til en Investor inneholder: - Hvor holder du til - Hvilken type investering er du på utkikk etter - Innen hvilket felt ser du etter å investere - En beskrivelse av deg - Hvor langt på vei er oppstartsbedriften du er interessert i kommet. - Hvor mye du er villig til å investere - Generell kontaktinformasjon og passord. Skjema til oppstartsbedrift inneholder: - Hvor langt på vei er du - Lokasjon på bedriften - Hva de utvikler - Innen hvilket fagfelt - Beskrivelse av produktet - Hvilken type investering - Hvor mye penger de trenger - Generell kontaktinformasjon og passord Innholdet i disse feltene er bestemt gjennom diskusjoner med Induct Software hvor flere av de ansatte tidligere har både investert og startet eget. Det var ønskelig å plukke ut den informasjonen som trengs av bedriftene for å kunne gjøre matchingen mellom brukerne så relevant som mulig, uten at registreringsprosessen skal være for tidkrevende. Målet med å holde en enkel og uformell fremtoning i IEZ får vi frem ved at webapplikasjonen spør brukeren spørsmål som Hvem er du og Hva gjør du som de svarer på under registreringen. Eksempler på dette kan ses i kapittel fire hvor vi går igjennom produktet. Dette er gjort bevisst for å holde den uformelle stemningen, få svar på seriøse spørsmål og treffe en moderne brukergruppe. 49

50 Det har ikke blitt utarbeidet noen reell løsning når det kommer til hvor mye som trengs av investeringer eller hvor mye som er ønskelig å investere. I utgangspunktet skal dette feltet være mer retningsvisende enn en faktisk indikator på ønsket investeringsbeløp. Det vil bli mer aktuelt i en ferdig versjon å velge høyeste og laveste sum, for så å la partene bli enige om en endelig sum. Beløpet som settes i løsningen nå er kun laget for å kunne teste IEZ. Med tanke på videreutvikling har vi lagt vekt på å lage komponenter for tabeller i registreringsskjema, som også brukes andre steder i IEZ. Dette er tabeller for land, produkt, type felt, type investor og type startup. En slik komponent inneholder et objekt av type felt og en metode som fyller en tabell med objekter når metoden blir kalt (figur 3.19 og 3.20). I IEZ slik det er nå så er disse komponentene fordelt på services og shared i mappestrukturen, men kan fint settes sammen til en klasse hvis IEZ blir større. Ved å lage slike komponenter så er det enkelt å legge til eller endre på tabellene uten å måtte gå inn i flere filer, eller å måtte lete igjennom masse kode. Figur 3.19: Klasse som definerer et Field objekt. Verdi (value) brukes av IEZ for å matche, og navn (name) er det brukeren ser. 50

51 Figur 3.20: Klasse som returnerer en tabell med Field objekter. Ved registrering så kreves det også at bruker skriver inn passord to ganger for å sjekke at passord blir skrevet inn riktig. Det kommer en feilmelding hvis det første passordet som er skrevet inn ikke stemmer med det andre passordet. Figur 3.21 viser hvordan passordsjekken fungerer i metoden som lager en investor. Det blir først gjort en sjekk på om passord som blir skrevet inn er like. Felter fra skjema blir et nytt investor-objekt. Bilde blir lastet opp, hvis bruker ikke har valgt noe bilde så blir bilde satt til å være default. Deretter blir investor sendt til APIet som lagrer i databasen. 51

52 Figur 3.21: Bilde av metode som lagrer en investor. 52

53 3.2.5 Innlogging og utlogging IEZ sin frontend benytter Angular 2 sin router til å navigere mellom de forskjellige sidene (figur 3.22). Det er to sider som er beskyttet og som krever innlogging for å få tilgang til, administrator og bruker side. Når en bruker ønsker seg tilgang til en av de beskyttede sidene så vil routes kalle på canactivate metoden enten i AuthGuard eller AdminGuard. Figur 3.22: Bilde av app.routes.ts. De forskjellige vaktpostene vil returnere sann eller falsk basert på om det finnes en token i lokal lagringen til nettleseren. Returneres det sann, vil routes navigere til den gjeldende path eller vei. Returneres det flask så vil routes navigere til standard vei **, som er hjemsiden. Standard vei vil også gjelde for alle forespørsler som ikke passer med andre veier. Når en bruker logger inn så sendes det en spørring til APIet med e-post og passord. Dette sjekkes mot databasen. Finnes ikke bruker eller passordet er feil så sendes en falsk boolsk variabel tilbake til APIet, som sender videre en passende http status melding. Hvis denne statusmeldingen av type feil, så vises det en feilmelding til bruker om at enten e-post eller passord er feil. Hvis bruker finnes i databasen og passordet er riktig så vil det genereres en token, som deretter sendes til klient via APIet. Denne token lagres i lokal lagringen til nettleseren. Etter å ha mottatt en OK melding fra APIet så vil også routes bli kalt, med en forespørsel om å få navigere til brukersiden. Denne forespørselen vil bli godkjent ettersom token finnes og bruker blir videresendt til innlogget brukerside. Når en bruker logger ut, blir routes kalt og bruker sendt til login siden (figur 3.23). AuthticationService blir også kalt og her settes token til å være NULL og alle tokens blir fjernet fra lokal lagringen i nettleseren. 53

54 Figur 3.23: Bilde som viser "logout" funksjonen i AuthenticationService Brukerside Når en bruker enten logger inn eller navigerer til brukersiden så vil token til nåværende bruker hentes ut fra lokal-lagringen i nettleseren. Ut i fra denne token hentes all informasjon om nåværende bruker fra databasen. Dette skjer i UserService (Figur 3.24). Figur 3.24: Bilde som viser klassen UserService. Etter at informasjonen om nåværende bruker er hentet ut, sendes det en spørring med nåværende bruker som objekt til matchingservice, som henter ut potensielle matcher og endelige matcher. Figur 54

55 3.25 viser hvordan en spørring sendes til matchingservice som henter ut og returnerer en tabell med foreslåtte matcher. Hvis tabellen som returneres er tom vises en feilmelding Både potensielle og endelige matcher legges inn i tabeller som deretter skrives ut i html-siden. Hvis nåværende bruker allerede har sendt forespørsel om match til en annen bruker vil ikke denne andre brukeren legges inn i tabellen med potensielle matcher. Når en bruker trykker på match-knappen så sendes det en spørring til matchingservice med bruker og matchen som objekt. Deretter slettes denne matchen fra tabellen med potensielle matcher og vil da heller ikke lengre vises på html siden. Figur 3.25: metoden for å hente foreslåtte matcher. Når en nåværende bruker ønsker å se endelige matcher sendes det en spørring til matchingservice som først henter ut tabellen med alle brukere nåværende bruker har trykket match på. Deretter sjekkes det om nåværende bruker finnes i tabellene til de brukerne som ble hentet ut. Hvis nåværende bruker finnes i match-tabellen til en annen bruker så blir denne andre brukeren lagt inn i tabellen for endelige matcher og sendt til brukersiden. Funksjonene for å oppdatere profilinformasjon og bilde fungerer på samme måte som ved registrering av bruker. Når en bruker trykker på knappen rediger profil vil det åpnes en modal med et redigeringsskjema. Skjemaet i modalen fylles med informasjon om nåværende bruker ved at det sendes det en spørring til userservice. Når en bruker er ferdig med å redigere profilen så sendes det en oppdateringsspørring til APIet som oppdater nåværende bruker med gitt ID. 55

56 Det siste nåværende bruker kan gjøre i modalen er å endre passord (figur 3.26). Når en bruker skal endre passord, må det først skrives inn nåværende passord og deretter nytt passord. Det nye passordet må skrives inn to ganger, på samme måte som i registreringen. Når brukeren da trykker på knappen, vil først det gamle passordet sjekkes mot databasen. Hvis det gamle passordet er riktig, vil det sendes en spørring til APIet med det nye passordet, for så å hashe og oppdatere det i databasen. Figur 3.26: Bilde som viser funksjonen for å endre passord. 56

57 3.2.7 Administrasjonsside IEZ har en egen side som man kan gjøre ulike administrasjonsoppgaver fra. Denne er bare tilgjengelig hvis en bruker er registrert som administrator. Administrasjonssiden er delt opp i to hoveddeler: Show data: Denne siden viser forskjellig statistikk over brukerbasen til IEZ. Man kan se en grafisk oversikt over hvor mange som er registrert, hvor mye siden blir brukt, og hva slags områder oppstartsbedrifter og investorer opererer innenfor. Figur 4.7 i kapittel 4 viser hvordan en av grafene på administrasjonssiden ser ut grafisk, og figur 3.27 viser html kode av grafen som registreringer over tid. Grafen består av flere attributter som settes i komponenten til admin.html. Disse statistikkene vises i forskjellige grafer, basert på hva slags info som skal vises. Informasjonen hentes ut fra databasen via web APIet, og verdiene brukes til å lage grafen gjennom et eksternt bibliotek kalt ng2- charts. Dette er et bibliotek for Angular2 som inneholder hjelpemetoder for å lage grafisk visning av statistikk. Figur 3.27: Html kode av grafen som viser registreringer over tid. 57

58 Figur 3.28: Lager graf over antall registrerte i forskjellige perioder. Figur 3.28 viser hvordan en metode henter ut måneden fra registreringstidspunktet til brukeren, og fyller de forskjellige søylene med antall registreringer. Man vil også kunne få en oversikt over alle feilmeldinger som siden har skapt. Under Show Errorlogs vil man få opp en liste over samtlige feilmeldinger. Disse inneholder navn, info og tidspunkt. Alle funksjoner i programmet ligger inne i en try/catch funksjon. Kort forklart gjør denne funksjonen det mulig å fange opp alle feilmeldinger som programmet lager. Disse vil bli lagret i en egen tabell i databasen via Errorlogger.cs i backend, som en administrator kan hente opp via denne fanen. Show users (Show investors/show startups): Denne siden inneholder en oversikt over alle brukere på siden. Listen blir hentet ut fra databasen, og en administrator kan søke gjennom listen etter en spesiell bruker. 58

59 For hver bruker er det en knapp som enten aktiverer eller deaktiverer en bruker, basert på statusen til brukeren (er brukeren deaktivert vil den ha en aktiver -knapp, og vice versa). Trykker man på denne vil brukeren settes til deaktivert i databasen, og brukeren vil ikke kunne bruke siden før en administrator aktiverer den igjen. Figur 3.29 viser metoden for å deaktivere en oppstartsbedrift. Metoden tar i bruk samme funksjoner som når man redigerer en bruker. Det eneste feltet man redigerer er i dette tilfellet activate feltet. Merk at metoden sender informasjon både til matchingtabellen og brukertabellen, siden brukere må bli deaktivert både som matches for andre og innlogging som seg selv. Figur 3.29: Metode i frontend som deaktiverer en oppstartsbedrift Matching-funksjon En viktig del av IEZ er funksjonen som foreslår potensielle investorer for oppstartsbedrifter og oppstartsbedrifter for investorer (Figur 3.33). Ved registrering tas det inn en del informasjon og det er denne informasjonen som brukes når det skal matches mellom brukere. Det er satt et begrenset og smart utvalgt av felter som det skal matches på. Disse feltene er valgt ut slik at det ikke skal være for vanskelig og tidkrevende å registrere seg, men fortsatt gi matching-funksjonen evnen til å presentere gode alternativer til brukeren. Det er hovedsakelig seks forskjellige felter det matches på. Disse feltene er: - produkt, altså om det er et fysisk produkt, en app eller noe annet - felt, innenfor hvilket fagfelt er dette produktet relevant - sum, hvor mye penger som trengs/som en ønskelig å bruke på en evt. investering 59

60 - lokasjon, befinner denne bedriften seg i Norge eller utlandet - type oppstartsbedrift, hva slags type oppstart dette er. Om det er en oppstart som bare har en ide, om de har kommet i gang eller om de er på kanten til å bli større - type investor, hva slags type investor det er. Om det er en business angel som hovedsakelig kun er ute etter å tilby penger eller om det er en inkubator som kan tilby husrom. Disse feltene har i matching-funksjonen blitt rangert på følgende måte: 1. Produkt 2. Fagfelt 3. Sum 4. Lokasjon 5. Type oppstart 6. Type investor Denne rangeringen har blitt utarbeidet i samarbeid med Induct Software. Type oppstart og type investor er begge like på hver sin måte i forhold til om du er investor eller oppstartsbedrift. Det er heller ikke vanskelig å legge til flere alternativer under produkt og fagfelt. På denne måten blir det også lettere å kunne tilpasse hva brukeren ønsker å vise frem eller se. Hvis disse alternativene blir for begrensende for brukeren har de også et alternativ å skrive litt mer om bedriften i klartekst i et eget input. Dette input feltet er foreløpig ikke noe del av matchingfunksjonen, men det kan senere bli aktuelt og også ta med deler av friteksten som kan brukes i matchingen. Kort om hvordan matchingen fungerer for en investor (fungerer på samme måte for oppstartsbedrift): Det blir først sendt informasjon om brukeren som er logget inn, basert på token, fra user.component.ts til matchingservice.ts. I matchingservice.ts sin funksjon getsuggestedstartups, hentes alle oppstartsbedrifter fra databasen. 60

61 Matchingen skjer ved at feltene til den innloggede brukeren blir sammenlignet med feltene til oppstartsbedriftene i tabellen som blir hentet ut. I første test sjekkes alle feltene mot hverandre og hvis testen passeres, legges oppstartsbedriftene som har alle feltene like som investoren inn i en ny tabell kalt foreslåtte oppstartsbedrifter og blir da tatt ut av den originale tabellen. I neste test fjernes det feltet som er rangert lavest (type oppstart) og resten av feltene beholdes. Hvis det blir funnet noen oppstartsbedrifter som matcher på de gjenværende feltene, legges de inn bakerst i tabellen med foreslåtte oppstartsbedrifter. Slik fortsetter det videre nedover. Ettersom de mest relevante oppstartsbedriftene blir lagt først i tabellen, er det også de som blir vist øverst når potensielle matcher blir vist på brukersiden. Deretter sammenlignes tabellen med nå potensielle oppstartsbedrifter, med de oppstartsbedriftene som investoren allerede har trykket match på. Hvis investoren har trykket match på en oppstart, vil denne oppstartsbedriften tas ut av foreslåtte oppstartsbedrifter, slik at det ikke går an å trykke match på samme bedrift to ganger. Figur 3.30 viser hvordan en løkke går igjennom listen med oppstartsbedrifter. Her testes det om alle feltene er like og om oppstartsbedriften er aktiv. Hvis testen er sann, blir oppstartsbedriften lagt inn i tabellen med foreslåtte og tatt ut av den originale. Det vises i dette tilfellet hvordan sum fungerer nå. Hvis summen er innafor et område på pluss/minus femti tusen, vil testen bli sann Figur 3.30: løkke og test som velger ut potensielle oppstartsbedrifter. 61

62 Beskrivelse av hvordan systemet lærer av brukerens valg Sorteringen beskrevet over presenterer potensielle investorer og oppstartsbedrifter basert på en til en matching og tar ikke hensyn til brukerens match-valg. Riktig nok vil den vise potensielle bedrifter som passer med brukerens prefererte felter, men den vil ikke kunne gi noe mer tilpasset innhold. Slik sorteringsalgoritmen er nå, er det bare produkt, fagfelt og lokasjon det testes på når innholdet til brukeren skal tilpasses. Sum-feltet er i første del av matching-funksjonen rangert høyere enn lokasjon og er også en del av testene der. Sum-feltet har ikke blitt tatt med i andre del av matchingen ettersom en reell løsning ikke har blitt utarbeidet. Det er også unødvendig å ta med investor ettersom det finnes bare en type slik IEZ er nå. Type oppstartsbedrift er heller ikke tatt med ettersom dette er et felt som investorer ikke er så interessert i. For å kunne tilpasse innholdet en bruker blir presentert, så er det nødvendig å innføre en form for maskinlæring. Alle match-forespørsler lagres i en egen tabell slik at det er mulig å se hvilke brukere en gitt bruker har ønsket å matche med. Når IEZ ser at en bruker har begynt å matche, er det mulig å tilpasse de potensielle matche brukeren presenteres, basert på hva brukeren tidligere har matchet på. Denne tilpasningen av informasjon skjer ved at feltene til de brukerne som brukeren har ønsket å matche med telles opp (Figur 3.32). Dette skjer ved å gå igjennom tabellen med match-forespørsler. Feltene som telles opp nå er produkt, fagfelt og lokasjon. Det blir aktuelt å legge til flere felter senere. Når feltene er telt opp, vil de legges i en egen teller-tabell som holder styr på feltet og antallet. Deretter sammenligner funksjonen feltene og finner ut hvilket felt som har størst antall forekomster og legger denne verdien til biggest-objektet som er av typen counter. Hvis alle feltene har like mange forekomster, altså like store, så settes variabelen samecount til sann og sammenligningen er derfor ikke nødvendig. Hvis samecount er sann, settes tabellen med foreslåtte matcher sammen av tabellen med de brukerne som har mest til felles og tabellen med de resterende sorterte potensielle brukerne. Hvis samecount er falsk, betyr det at feltene er ulike. Da sjekkes biggest objektet sitt navn i tre forskjellige tester (Figur 3.31). 62

63 Figur 3.31: Tester for å sjekke biggest objektet. Hvis produkt er det feltet som har flest forekomster, vil biggest.name === productcount være sann. Da kommer tabellen med potensielle matcher til å sorteres på nytt hvor produkt alltid er en del av spørringen. Det betyr at potensielle matcher som har produkt til felles med brukeren kommer høyere på listen. Når den andre sorteringen er ferdig, vil tabellen med foreslåtte matcher settes sammen av tabellen med de brukerne som har mest til felles, tabellen sortert basert på hva brukeren selv er interessert i og tabellen med resterende brukere som kanskje bare har en ting til felles med bruker. På denne måten så kan IEZ lære av de valgene brukeren tar og presentere mer relevant innhold. 63

64 Figur 3.32: Bilde som viser hvordan opptelling og sammenligning av felter skjer. 64

65 Figur 3.33: Diagram som beskriver hvordan matching-funksjonen fungerer. 65

66 3.2.9 Sikkerhet Passord: Alle passord som registreres av brukeren blir kryptert ved hjelp av en PBKDF2 kryptering før det legges i databasen. PBKDF2 er en kryptografisk funksjon som lager en kryptert nøkkel fra et passord ved at den kjører passordet gjennom en pseudo-tilfeldig funksjon (En funksjon som lager tilfeldige verdier basert på gitte premisser) mange ganger. Fordelen med slik kryptering er at den er enveis. Det vil si at det ikke finnes en felles nøkkel for alle passord. Nøkkelen er passordet, som ideelt sett bare finnes i minnet til brukeren. I vårt tilfelle itererer vi passordet gjennom krypteringen ganger, som er anbefalt av NIST (National institute of Standards and Technology) sine retningslinjer innen sikring av passord. (35) En PBKDF2 kryptering er også med hensikt en veldig treg algoritme, som gjør den ideell til bruk for passord. Grunnen til dette er at hvis en potensiell angriper skal finne passordet fra nøkkelen lagret i databasen, må den teste masse ord opp mot nøkkelen. Hvis algoritmen er treg, vil dette ta veldig mye lengre tid enn en kjapp algoritme. Vi har også lagt til en tilfeldig verdi (salt) som gjør at hver operasjon som genererer nøkler blir unik. Dette gjør at en mulig angriper ikke kan gjette et passord for så å se etter treff i et stort antall krypterte nøkler. Figur 3.34 viser hashing funksjonen. p er passord fra bruker. Den kjøres gjennom Rfc898DeriveBytes funksjonen som tar tre argumenter: pass (inputen fra bruker), salt (en tilfeldig verdi for å gjøre krypteringen unik) og antall ganger den skal kjøres. 66

67 Figur 3.34: Hashingalgoritmen. Når vi skal validere passordet til en bruker tar vi inputen til brukeren og itererer den igjennom en funksjon med de samme premissene som når vi lagde den krypterte nøkkelen til passordet. Hvis resultatet matcher med den lagrede nøkkelen, er passordet gyldig og brukeren blir validert. Figur 3.35 viser funksjonen som tar imot fra bruker (for å finne det krypterte passordet i databasen) og input fra bruker (passordet funksjonen skal sammenligne med). Den sammenlikner så de to passordene. Er det en match, returnerer den true, hvis ikke returnerer den false. 67

68 Figur 3.35: Funksjon som validerer passord. Token: Når brukeren logger inn, vil det bli generert en token i backend som lagres i brukerens lokale lager i nettleseren. I en token lagres: - ID Dette er et nummer som refererer til brukerens rad i databasen - Rolle Sier om brukeren er en oppstartsbedrift eller investor - Utgiver Hvilken side som har gitt ut tokenen. I dette tilfellet er det Induct Entrepeneur Zone - Dato Når en token er utgitt, dato og klokkeslett - Signering Tokenen blir kryptert med en SHA256 kryptering med et nøkkelord. Dette nøkkelordet er lagret i backend, og brukes for å validere tokenen. Fordelen med å bruke tokens istedenfor cookies er at en token er selvstendig. Serveren trenger ikke å ha oversikt over hvilke sesjoner som foregår, men bare verifisere at tokens den får tilsendt er ekte. 68

69 En annen fordel er at man i en token kan lagre forskjellige metadata, mens i en cookie får man bare lagret en ID. En token i seg selv lett å lese, selv om den er kryptert. (Man kan klippe den ut og lime den inn i en hvilken som helst dekrypterings-verktøy, og lese informasjonen). Derfor er det viktig å bare lagre informasjon som ikke er klassifisert. Denne informasjonen blir brukt for at IEZ skal skjønne hvem som er logget inn, og gi ut informasjon basert på dette. En typisk token fra en investor ser slik ut: Figur 3.36: skjermdump fra Til venstre ser vi en token i kryptert form. Den er delt opp i header, payload og signature (xxxx.xxxx.xxxx). Til høyre ser vi en token i dekryptert form. (Dette illustrerer også eksempelet over hvor lett det er å dekryptere en token, siden den bare er klippet ut fra det lokale lageret til nettleseren og limt inn på ). Her er også informasjonen som er lagret i de forskjellige delene. Den nederste delen er signaturen til tokenen. I dette eksempelet er den hemmelige nøkkelen skrevet inn, slik at denne token er validert (i et ekte scenario ville dette feltet vært tomt, og Signature verified ville ikke vært der). 69

70 Hver gang en bruker navigerer seg rundt på siden, vil IEZ gjøre en sjekk på om brukeren har en token. Er sjekken ok, vil brukeren kunne navigere seg dit den vil. Er den derimot ikke ok, vil brukeren bli sendt til startsiden, og må logge seg inn på nytt. Brukerens token blir også sendt med i hvert kall til APIet, og en token blir kjørt gjennom en valideringsmetode. Denne metoden sjekker om en token er ekte ved å sammenligne krypteringen med nøkkelordet. Finnes det ingen token i kallet, eller det er feil token til kallet (om man skal gjøre et kall som er forbeholdt administratorer, men man er en bruker), vil man ikke kunne gjennomføre kallet. Hvis man har en riktig token, og den ikke blir validert i valideringsmetoden, vil IEZ kaste en exception. Denne vil bli fanget opp og skrevet ut i en feilmeldings-logg som administratorer har tilgang til. Dette er informasjon som administratorer gjerne vil ha tilgang til; hvis valideringen er feil er det enten en feil med genereringen av tokens, eller så er det et mulig angrep på siden. Deaktivere bruker: Hvis en bruker ikke lenger ønsker å bruke eller ikke lenger får lov til å bruke IEZ, så skal denne brukeren "slettes". Det som skjer er at brukeren settes som "inactive"/deaktiveres. Når en bruker er deaktivert, vil ikke denne brukeren kunne logge inn. Andre brukere vil heller ikke få opp denne brukeren som en foreslått match. Har en bruker allerede matchet med en annen bruker som deretter har blitt deaktivert, så vil heller ikke den deaktiverte brukeren komme opp under final matches. Hvis en bruker allerede er logget inn, vil det sjekkes om denne brukeren er aktiv for hver handling denne brukeren foretar seg. Hvis brukeren blir deaktivert for så å foreta en handling, vil denne brukeren bli logget ut. Det vil si at hvis en bruker er logget inn for å bli deaktivert, vil den ikke umiddelbart bli logget ut, men denne brukeren vil heller ikke kunne foreta seg noe uten å bli logget ut. Selve deaktiveringen fungerer slik at et eget felt kalt activate blir satt til sant eller usant, basert på om brukeren er deaktivert eller ikke. Navn og epost blir også forandret slik at dette blir frigjort for andre. For eksempel: Hvis eposten til en bruker er bruker@bruker.com blir denne til bruker@bruker.comdeactivated. 70

71 Figur 3.37 viser del av funksjonen til å redigere bruker. Hvis brukeren som kommer inn som parameter bare har verdi på activate feltet, skjønner funksjonen at den må gjøre en activate/deactivate operasjon på brukeren. Operasjonen forandrer på navnet og epost, samt setter riktig verdi på activate-feltet. Figur 3.37: Del av funksjonen som redigerer bruker. Validering av input: Alle felter som har å gjøre med innsetting av informasjon i databasen blir validert med regular expressions. Dettes gjøres både i frontend og backend. I frontend gjøres dette ved hjelp av Angular 2 og i backend ved hjelp av C#. Det er viktig å gjøre dette begge steder fordi det fortsatt er mulig å sende informasjon til databasen ved å direkte kontakte APIet. Bildeopplastning kan potensielt være veldig farlig, fordi brukere kan laste opp filer i form av scripts og lignende. IEZ har validering på bildeopplastning i form av begrensning på størrelse, og sjekk på filtype. I komponenten til registreringsskjemaet har man denne funksjonen (Figur 3.38): 71

72 Figur 3.38: Sjekk på bildefil i komponenten. Denne sjekker om størrelsen er akseptabel, slik at brukere ikke kan laste opp for store bilder. For å sjekke filtype har man en validerings-sjekk i selve inputfeltet på HTML-siden (Figur 3.39): Figur 3.39: Sjekk på bildefil i html-dokumentet Denne sjekker om filen er av typen png, gif eller jpg. Samtidig så kaller den sjekkbilde funksjonen når brukeren legger til et bilde. Hvis bildet er for stort får man en feilmelding Tilpasning på mobile enheter For å kunne tilby tjenesten til så mange brukere som mulig var det ønskelig i kravspesifikasjonen at produktet skulle være funksjonell på mobiltelefon. Siden IEZ hovedsakelig er tiltenkt å brukes på pc, er dette det designet det er brukt mest tid på, men vi har gjort noen endringer så nettsiden skal fungere på mobile enheter. Bootstrap gjør mye av arbeidet med tilpasning for forskjellige enheter og skjermstørrelser, men noen endringer måtte gjøres av oss. Tilpasningene forklart nedenfor er i tillegg til Bootstrap så alle endringene passer på mobile enheter. For at IEZ skal skjønne hvilken type enhet som blir brukt kjøres en enkel spørring på hver hovedside som sjekker størrelsen på oppløsningen til enheten. I figuren er en sjekk på om skjermen som brukes har en oppløsning på mindre enn 770 Figur 3.40: Sjekk av størrelse på skjerm. piksler i bredden (Figur 3.40). Det testes på oppløsningen for å velge hvilket format som skal vises, da kan utseende på andre typer skjermer som av ulike årsaker trenger å ha lav oppløsning også endres. Hvis skjermen har oppløsning på under 770, endres noe av 72

73 innholdet på siden så det tar mindre plass. Nedenfor vises hvordan hjemskjermen gjør menyen i toppen på skjermen mindre for at den skal passe bedre på mobile plattformer. Figur 3.41: Hjemskjerm på pc-skjerm. På det store bildet ser vi hvordan startskjermen ser ut på en vanlig pc (Figur 3.41). Når denne siden vises på en mobiltelefon blir tittelen på siden og de to knappene øverst for mye og det ser rotete ut. I stedet brukes forkortelsen IEZ og menyen blir til en nedfallsmeny. Her kommer fordelen med en SPA, så alt vi har gjort er å vise forskjellige div-bokser. Dette er gjort på alle stedene i IEZ hvor menyen har blitt for stor. I tillegg er det fjernet muligheten for å logge inn i nav-menyen på toppen av siden. I stedet vil brukeren bli sendt til innloggingssiden, dette gjorde vi så det ikke skulle bli for mye funksjoner oppe i nav-menyen da det er begrenset med plass. De fleste nettlesere har i dag nyttige verktøy til å hjelpe med utvikling til mobile plattformer. Under innstillingene til nettleseren kan man velge å bruke en enkel emulator som viser siden som om de skulle vært en mobiltelefon. Eksempelet i figur 3.42 er fra Firefox med en iphone 6 emulator så man lett kan se hvordan IEZ vil se ut på en telefonskjerm. Figur 3.42: Hjemskjerm på mobil. 73

74 4 PRODUKT I dette kapittelet forklares det hvordan en bruker skal benytte IEZ. Funksjonaliteten fra både investoren og oppstartsbedriften sitt synspunkt blir forklart for å gjøre rede for alle funksjoner. 4.1 GENERELLE FUNKSJONER En bruker som ikke enda er registrert på siden vil møte en hjemmeside som viser en stor logo av IEZ og et kort slagord om tjenesten. Brukeren kan navigere ned på siden ved å trykke på pil-ikonet under slagordet som sender brukeren lenger ned på forsiden hvor man kan få mer informasjon om IEZ og hva denne tjenesten gjør. Øverst på siden er en meny som strekker seg over hele bredden av skjermen og som inneholder tre knapper: Registrer, Logg inn og tittelen Induct entrepreneur zone. Det er en ramme rundt registrer som trekker fokus på siden mot denne. Brukere som ikke allerede er registrert vil da lettere finne frem og bli en registrert bruker. Brukeren blir sendt til første del av registreringsskjema som vil redegjøre for om brukeren er en investor eller oppstartsbedrift (figur 4.2). Resten av registreringsskjema blir forklart nedenfor. Figur 4.1 Figur 4.2: Sjekker om en oppstartsbedrift eller Investor skal registrere seg. 4.2 BRUKER Beskrivelsen av registreringen blir forklart både for investor og oppstartsbedrift i samme uttrykk, fordi skjemaene er veldig like og gir en like god forklaring på hvordan å bruke siden. En bruker som fortsetter registreringen vil komme til del to av registreringsskjema, vist i figur 4.3, som inneholder spørsmålene som er nevnt i Registrering av bruker. Her må brukeren benytte nedfallssmenyer for å svare på spørsmålene som vil gi så korrekt informasjon om bedriften som mulig. Det er et felt for fritekst hvor brukeren kan bedre beskrive bedriften eller investoren enn nedfallsfeltene. Dette er teksten andre brukerne ser når de leter etter potensielle partnere. Det er 74

75 derfor ikke lurt å legge sensitive opplysninger om bedriften eller ideen i denne friteksten. Brukeren benytter seg av pilen nederst på siden for å angi et ønsket beløp for investeringer og til slutt kan de gå til siste del av registreringen. Figur 4.3: Viser hva brukeren har å tilby og hva de ønsker. I siste del av registreringen fylles det inn generell informasjon om brukeren (figur 4.4). Her skrives alt inn med fritekst bortsett fra et felt som er til for å laste opp bilde, hvis brukeren ønsker å ha logoen med. Logoen kan lastes opp på vanlig måte, ved å trykke Browse og velge den filen man ønsker å bruke. Om brukeren ikke velger et bilde vil det bli generert et standard bilde. Når brukeren er ferdig registrert blir man sendt til en innloggingsside. 75

76 Figur 4.4 Generell informasjon om brukeren. Brukeren kan benytte seg av denne innloggingssiden eller logge inn ved hjelp av menyen på toppen av siden. Ved å trykke på logg inn vil brukeren få frem felter for å skrive inn epost og passord, her vil det komme opp advarsel om feltene ikke er korrekt utfylt. Når man logger inn kommer man først til siden med oversikt over de mest aktuelle bedriftene eller investorer som passer til brukeren (figur 4.5). Figur 4.5: Menyen som viser potensielle matcher. 76

77 Her har man en oversikt med navnet på bedriften/investoren, en kort beskrivelse og en knapp med teksten match nederst. Brukeren kan lese seg frem til hvilke andre som kan være av interesse og trykke på match. En bruker kan trykke match på et ubegrenset antall andre brukere, men de man har mest til felles med vil vises øverst på siden så, jo lengre ned man kommer jo mindre relevant vil resultatet være for brukeren. Øverst på siden til den innloggede brukeren har vi fortsatt den gjennomgående menyen med Induct Entrepreneur Zone til venstre og resten av menyen til høyre. Denne menyen er nå en nedfallsmeny med fire alternativer. Her kan man redigere brukeren, gå til siden for å finne nye matcher, se på matcher man har fått eller logge ut. Finn matcher er den samme siden som man kommer til når man først logger inn. Her velger man hvilke andre bedrifter/investorer man er interessert i. Final matches er der brukeren kan se hvem som har vist interesse tilbake. Det vil si at begge parter har trykket på match på hverandre, og man kan her finne kontaktinformasjonen til andre brukere for å ta videre kontakt. Figur 4.6: Redigering av bruker. 77

78 Redigere bruker (figur 4.6) gjøres ved at et nytt vindu dukker opp i forgrunnen med et skjema som har samme felter og valg som ved registrering. Brukeren kan her endre på det de måtte ønske og trykke på lagre for å oppdatere med de nye valgene. Her har brukeren også mulighet til å endre bilde eller passord. Trykker man på logg ut vil man komme til den samme innloggingssiden som vises etter man har registrert seg. 4.3 ADMINISTRATOR En administrator vil på IEZ ha en egen side hvor man kan administrere brukere og ha tilgang til ekstra informasjon som ikke er relevant for vanlige brukere. Administratorsiden er en enkel side med en meny som har fire knapper, Logout, Show data, Show all startups og show all investor. Logout logger ut administratoren og sender administratoren til hovedsiden for IEZ. Show data er en nedfallsmeny som inneholder de forskjellige områdene med data. Her kan administratoren få en oversikt over registreringer, startup info, investor info, matching info og error log. Inne på registreringer får administratoren en graf over hvor mange oppstartsbedrifter og investorer som har registrert seg i løpet av året. Figur 4.7: Hvilker produkter som utvikles. Startup info viser hvor stor andel av oppstartsbedrifter som utvikler innen de forskjellige feltene, som vises i figur 4.7. Investor info viser det samme men med oversikt over investorer. 78

79 Matching info er en graf som viser hvor mange ganger det blir trykket match av de forskjellige brukerne. Denne vil gi administratoren et innblikk i aktiviteten på siden matchingen er hovedfunksjonen til siden. Error log er en oversikt over hvilke feil som har oppstått på siden og hvor ofte de har oppstått. De to siste knappene i hovedmenyen er show all startups og show all investors. Her er det en oversikt over alle investorer og oppstartsbedrifter. Administratoren kan bruke denne siden til å redigere eller å deaktivere brukere. Det er en del av arbeidet som administrator å aktivere eller deaktivere brukere som sender epost til administratoren for å få gjort dette. 79

80 5 TESTING I dette kapittelet går vi igjennom den testingen som har blitt utført på IEZ. Black-box testing refererer til en type testing der tester ikke ser hva som skjer i selve koden. Dette er en type testing som går ut på at tester bruker IEZ slik den kommer til å bli brukt av investorer og oppstartsbedrifter. White-box testing refererer til en type testing der det som ligger bak IEZ testes, altså selve koden. (36) 5.1 SYSTEMTEST Systemtest har blitt utført både på pc og mobil med tredjeparter. Dette blir gjennomført som en type black-box testing der brukere uten særlig kunnskaper om programmering testet IEZ. Når IEZ i tidlig fase ble testet på mobile enheter kom det frem at en del av feltene på registreringssiden ikke var tilgjengelige; de hadde på grunn av den lille skjermen laget seg under menyen. Det ble også avdekket en feil med feltet for login i navigasjonsmenyen på hjemmesiden. Hvis en bruker trykket på "login", ville menyen lukke seg og det var da nødvendig å åpne menyen igjen for å kunne logge inn. Design og innhold på pc ble også testet av en designstudent. Det ble gitt tilbakemelding om at kontrast mellom bakgrunn og tekst var for lav, slik at det kunne være vanskelig å lese teksten. Det ble ikke nevnt noen andre feil eller mangler ved design og innhold. Da de nevnte feil og mangler har blitt utbedret så tilfredsstiller IEZ de forventede kravene fra bruker. 80

81 5.2 AKSEPTANSETEST Det ble utført en akseptansetest av Morten, veileder fra Induct Software. Dette ble også utført som black-box testing, da de fleste krav i kravspesifikasjonen går mer ut på det overfladiske og ikke teknologier som vi sto fritt til å velge selv. I testingen ble prosessen for registrering av bruker gjennomgått, innlogging av bruker ble testet og det ble matchet mellom oppstartsbedrifter og investorer. Matchingen ble testet med at det ble generert en database med 200 ulike investorer og 200 ulike oppstartsbedrifter. Deretter ble det registrert en investor og en oppstartsbedrift, med tilnærmet like felter. Den nyregistrerte investoren logget så inn, for å sjekke at den nyregistrerte oppstartsbedriften ble plassert mot toppen av listen. Dette stemte. Det samme ble gjort med den nyregistrerte oppstartsbedriften og resultatet ble det samme. En-til-en matchingen fungerte derfor som ønsket. Det ble også gått igjennom funksjonalitetene til administrator-panelet, der sletting og endring av brukere ble testet. Funksjonalitet på mobile enheter ble også testet, etter at feil hadde blitt utbedret. Tilbakemelding fra Morten var god og IEZ tilfredsstiller de krav som ble satt i kravspesifikasjonen. 5.3 ENHETSTESTING OG INTEGRASJONSTESTING Integrasjonstesting har blitt utført hver gang en ny del har blitt lagt til i systemet. Det har da blitt sjekket at verdier som legges inn via IEZ er uendret når de legges inn i databasen. Det har blitt gjort forskjellige kall til APIet for å sjekke at riktige statuskoder returneres, og det har blitt testet at disse retur-svarene blir håndtert på riktig måte. Selvstendige kodebiter har blitt testet under utvikling for å sjekke at de kjører som forventet og returnerer forventet resultat. 81

82 6 DISKUSJON Det vil i dette kapittelet bli diskutert litt rundt valg som ble tatt, metoder som ble brukt og teknologier som ble brukt. 6.1 FRONTEND Lokalisering av funksjonaliteter knyttet til matching Slik IEZ er utviklet nå, er mye av funksjonaliteten knyttet til matching lokalisert i frontend. Det var et ønske fra Induct Software at frontend skulle være selvstendig, men fortsatt skulle kunne knyttes til deres eksisterende database. Siden gruppen ikke har hatt tilgang til Induct Software sine servere så ble det avgjort at det meste av funksjonalitet skulle legges i frontend. Fordelene med å legge mye av funksjonaliteten i frontend er at IEZ kan knyttes til databaser uavhengig av hva slags teknologi som benyttes i databasen, så lenge det kan returneres JSON-data. Når eller hvis det skal utvikles applikasjoner for mobile enheter, eller andre grensesnitt som ikke støtter Angular 2, så må det gjøres en del endringer. Det kan bli en utfordring å replisere matchingfunksjonen slik den er nå, i et annet språk og miljø. Det ville da vært mer hensiktsmessig å flytte det meste av funksjonalitet knyttet til sortering over i backend, slik at dette ikke trengs å utvikles på nytt hver gang. Det ville også vært hensiktsmessig å legge matching-funksjonen i backend med tanke på at det nå hentes ut hele lister med investorer og oppstartsbedrifter for så å sortere de. Disse listene kan inneholde flere tusen brukere og etterhvert bli ganske store. Javascript kjører i en sandkasse i nettleseren hos klienten. Det betyr at en sortering i IEZ, slik som den er nå, vil skje på klientsiden og ikke serversiden. Hvor raskt denne sorteringen skjer er avhengig av hvor rask maskinen til klienten er. Derfor burde det meste av sortering ikke skje i frontend, slik at brukere med tregere maskiner ikke opplever lengre ventetid enn de med raskere maskiner. Sortering burde heller skje i backend og på server, da ytelsen til server er kjent og lik for alle brukere. Lengre ventetid kan også oppleves for brukere med tregere internett ettersom pakkene som sendes kan bli store. 82

83 En fordel med sortering i frontend er for lister som skal sorteres og allerede finnes hos klienten. Det er ikke nødvendig for klienten å spørre server om den samme listen, bare sortert på en annen måte. Dette er bedre ettersom spørring til server kan ta lengre tid enn sortering hos klienten. Slik IEZ er nå, har det blitt gjort tester på lister med 5000 brukere og IEZ ble ikke noe merkbar tregere av dette, med tanke på at informasjonen kun kommer i form av tekst. Tiden det tok for å hente ut 100 brukere var tilforlatelig lik tiden det tok for å hente ut 5000 Eksempel: En bruker som blir hentet ut har størrelse på rundt 80 byte. En liste med 5000 brukere vil da være byte. Dette tilsvarer rundt 0,38 megabyte. Med tanke på at listene som hentes ut er store så bør det også lages en cache funksjon slik at listene kun hentes ut en gang. Nå hentes listene ut hver gang en bruker logger inn og navigerer mellom de forskjellige menyene. Dette bør egentlig gjøres uansett hvor store lister som hentes ut. Det skal ikke være nødvendig å hente ut mer enn en gang Funksjonalitet på mobile enheter IEZ er optimalisert for bærbare pc-er og stasjonære enheter. IEZ er funksjonell på mobile enheter, selv om dette ikke er et typisk use-case. Det vil bli aktuelt å lage en dedikert applikasjon for IOS og android. En mobilapplikasjon vil da ha mer fokus på selve delen for matching, og heller være et sted hvor det er lett å holde seg oppdatert. Det er gjort enkle tiltak for å få en versjon som fungerer på mobile enheter. Det er ikke lagt fokus på å optimalisere eller gjøre administrasjonsdelen av IEZ funksjonell for mobile enheter. Selv om det er mulig å logge inn i administrasjonsdelen på en mobil plattform, er det ikke tenkt at en administrator skal bruke IEZ på en slik måte Forbedringer av grafisk brukergrensesnitt 83

84 Det grafiske brukergrensesnittet har forbedringspotensial, men er et godt utgangspunkt med tanke på videreutvikling og prototyping. Bootstrap-malen som har blitt brukt har vært til stor hjelp ettersom ingen av gruppemedlemmene har erfaring med design av grafiske brukergrensesnitt. Som del av videreutviklingen vil det bli aktuelt å få noen med bedre kunnskap om design av grafisk brukergrensesnitt til å se på dette. 6.2 FORBEDRINGER OG BRUK AV MATCHING FUNKSJONEN Algoritmen for matching lærer av brukerens valg og presenterer en liste med de potensielle matchene som har de feltene som brukeren er mest interessert i. Denne sorteringen basert på brukerens valg vil starte med en gang brukeren begynner å trykke match. Slik algoritmen er nå, vil det ta litt tid å endre hva brukeren helst ønsker å se hvis brukeren har matchet mye på et felt. Det kan lages en slags reset funksjon som gjør det mulig for brukeren å få nye favoritter fortere. En annen løsning kunne vært å regne ut et bedre forhold mellom de forskjellige feltene. Det beste vil nok være å lagre opptellingen av feltene som brukeren trykker match på, i en egen tabell. Denne opptellingen kan deles opp i flere økter, hvor en økt er tiden en bruker er logget inn og driver med matching. Når en bruker da logger inn og spør etter potensielle matcher, vil dataen fra opptellings-tabellen hentes ut der det går an å se antall på hvilken type felter som var interessante ved en gitt økt gitt dato. Deretter kan alle feltene telles opp totalt for å finne en oversikt over hva som generelt sett er mest interessant. Samtidig kan feltene for et gitt antall økter telles opp for å kunne finne ut hva som har vært mest interessant i det siste. Når opptellingene er ferdig regnes det ut et forhold mellom de forskjellige feltene i hvert av tilfellene. Til slutt sammenlignes det generelle forholdet med det som har vært mest interessant i det siste. Er disse to like, altså at brukeren ikke har endret sin interesse, vil tabellen med potensielle matcher sorteres ut fra det feltet som har høyest verdi generelt sett. Er disse to ulike, altså at brukeren har endret sin interesse, vil tabellen med potensielle matcher sorteres ut fra det feltet som har høyest verdi blant det som har vært mest interessant i det siste. Bedre tilpasning av innhold ved å la investorer registrere flere oppstartsbedrifter 84

85 Slik IEZ er nå, kan investorer kun registrere en type oppstartsbedrift de er interessert i. Ved å kun ha en type vil det være færre bedrifter som trenger å sorteres, derfor vil ikke denne algoritmens fulle potensiale vise seg før det er mulig for investorer å velge flere oppstartsbedrifter. Endring av uønskede felter Det er mulig å finne ut hvilke typer felter brukeren ikke er interessert i ved å sjekke feltet med lavest verdi. Foreløpig vil disse automatisk bli lagt nederst i tabellen. Hvis det er slik at en bruker ikke viser interesse for et felt, kan det gis tips til bruker at denne profilen burde oppdateres, slik at IEZ kan presentere mer relevant informasjon. Rangering av opptalte felter Nå sorterer funksjonen for matching potensielle matcher kun ut fra det feltet som har høyest verdi, mens resten av matchene blir plassert nederst i tabellen. For å kunne dra full nytte av opptellingen av felter kan de rangeres. Da vil det feltet med høyest verdi legge matcher inn øverst, feltet med nest høyest verdi til legges inn etter og slik går det helt til feltet med lavest verdi legges inn bakerst. Effektivisering av kodebruk Det blir brukt en del tester og løkker i funksjonen for matching, og de fleste er nesten helt like med unntak av et par setninger. Med tanke på at disse testene er så like, bør det gjøres noen endringer som åpner mer for gjenbruk av kode. Det er mulig å telle opp brukeres felter i en løkke der hvert felt testes mot nåværende bruker. Blir det funnet et felt som er likt settes en variabel for dette feltet til sann, hvis ikke til falsk. Deretter kjøres en ny løkke som går igjennom resultatene fra den første, og legger de brukerne med flest sanne variabler inn først. Deretter legges det med nest mest inn, osv. På den måten vil sorteringen begrenses til kun to løkker og en test i den første løkken for hvert felt, og en test i den andre for hver variabel. 6.3 SIKKERHET Sikkerhet er et stort og komplisert tema, og det utvikles stadig nye angrepsmetoder for å bryte seg inn. Etterhvert som brukerbasen og funksjonaliteten til IEZ vokser, vil også informasjonen til brukere bli mer attraktivt for hackere. Sikkerheten til IEZ per dags dato er etter gruppens mening god nok, men burde også videreutvikles i takt med veksten på webapplikasjonen. Man burde også vurdere muligheten med å ta i bruk ferdigstilte løsninger fra eksterne parter, slik som.net sin innebygde 85

86 autentisering, eller Auth0 (Auth0 er en ekstern tjeneste som tar for seg token-generering og autentisering). For dette prosjektet sin del var det læringsutbytte som sto i fokus. Derfor har sikkerheten blitt utviklet med minst mulig bruk av eksterne ressurser. Dette har gitt gruppen kunnskap om datasikkerhet, og gitt IEZ en sikkerhet som er akseptabel for webapplikasjonen slik den er i dag. Hvis man skal ta sikkerheten ett skritt videre, er det noen ting man kan diskutere: Validere bildefiler IEZ har allerede en validering av filtype når det kommer til opplasting av bilder, men denne valideringen vil nok ikke holde når IEZ lanseres. Grunnen til dette er at det er lett for angripere å kamuflere filtyper under et annet filnavn. Eksempelvis kan en fil med en.jpg ending inneholde kode som er et script. En løsning på dette er å ha en funksjon i backend som sjekker koden som bildefilen er bygd opp med. Den kan så skille et ekte bilde fra et skript ved hjelp av regulære uttrykk. Nøkkel til token i backend Alle tokens blir kryptert med en signatur. Denne sørger for at IEZ kan sjekke om en token er ekte, og ikke er blitt tuklet med. Signaturen er en tekststreng lagret i backend. Får noen tak i denne kan man bruke strengen til å lage en validert token. For å få tak i denne nøkkelen må man inn i koden på serveren, så denne er allerede ganske sikker. Hvis man derimot vil sikre denne bedre kan man lage et system som gir ut unike signaturer til tokens. Systemet vil ligge beskyttet på en annen server. Dette gjør at selv om en signatur-nøkkel blir funnet, vil den bare fungere for den ene token, og ikke for alle. Passord Passord i databasen er sikret med en kryptering som er mer enn god nok for en webapplikasjon. Passordene er derimot sårbare før de blir kryptert, altså på veien fra brukerinput til server. Dette løses med en sikker tilkobling (https) som er nevnt under kapittelet om videre arbeid. Den største svakheten tilknyttet bruken av passord er og vil alltid være brukerstyrt. Svake passord fra brukere er vanskelig å kontrollere fullstendig, siden det som regel er utenfor utviklerens kontroll. Det beste man kan gjøre er å hjelpe brukeren på vei til å lage et sterkt nok passord. Spørsmålet blir da om man skal nøye seg med hint, eller tvinge brukeren til å en gitt lengde og en blanding av store bokstaver og tall. Nøyer man seg bare med hint vil man nok få en del utrygge passord, siden mange 86

87 brukere har lite kunnskap om passordsikkerhet. Man ville nok gått for en blanding, altså validering på lengde (minimum 8 bokstaver), og diverse hint på styrke. 6.4 BACKEND IEZ sitt oppsett av backend ble valgt etter nøye diskusjon rundt hva slags funksjonalitet IEZ skulle ha, samt hva slags begrensninger gruppen hadde. Det viktigste punktet som Induct Software og gruppen ble enige om, var mulighet for videreutvikling. Det var også et krav at IEZ skulle bygges opp rundt et Web API. Gruppen ville også fokusere på egen kunnskap og tilgang til ressurser, slik at backenden ble skrevet i C#. Med tanke på selve databasen ble denne laget slik at investor og oppstartsbedrift har hver sin tabell uten relasjoner. Dette er fordi de fungerer som to separate brukergrupper til IEZ, og har forskjellige verdier som må lagres. Matching-tabellene er satt opp på samme måte, det vil si som to separate modeller uten relasjon. Man kan diskutere om ikke matching-tabellene skulle hatt en mange-tilmange relasjon med tabellene for investor og oppstartsbedrift. Dette ville gjort spørringene enklere og mere effektive. Samtidig ville det også ført til komplikasjoner med tanke på algoritmen. Selv om spørringene hadde gått raskere, ville det vært mer utfordrende å hente ut nøyaktig informasjon. Når IEZ vokser, vil det være naturlig å ha med flere relasjoner mellom databasetabellene. Mer spesifikt vil dette være nyttig når man tar i bruk flere investor-typer, samt gir investorer mulighet for å vise interesse for flere typer oppstartsbedrifter. Figur 6.1 viser et eksempel på hvordan en mangetil-mange relasjon kan brukes når IEZ blir utvidet med flere funksjoner. Figur 6.1: Et eksempel på mange-til-mange database. 6.5 VALG AV VERKTØY 87

88 Til å utvikle IEZ ble det brukt flere verktøy som gruppen ikke hadde benyttet tidligere. Dette skapte noen problemer og unødvendig bruk av tid men har gitt oss et stort læringsutbytte. Utviklingen i Visual Studio var stort sett uproblematisk. Det var store fordeler med å ha alt av utvikling samlet i et integrert utviklingsmiljø og det gjorde samarbeidet i gruppa lettere. Hvor alt av funksjonalitet var blitt lagt kunne bli litt uoversiktlig etter hvert som prosjektet vokste og ny funksjonalitet ble lagt til av gruppemedlemmene. Mye av mappestrukturen ser lik ut og er til tider repeterende rent utseendemessig og ble en utfordring når et gruppemedlem måtte jobbe med deler av prosjektet de ikke hadde jobbet mye med tidligere. Feilmeldinger fra forskjellige utviklingsmiljøer kan være lite konkrete, og gi liten indikasjon om hvor feilen befinner seg. Siden IEZ var samlet i et integrert utviklingsmiljø var det lett å se feil ved hjelp av feilsøk i Visual Studio og hvor disse feilene befant seg. Hadde vi benyttet utviklingsverktøy som hadde delt opp utviklingen hadde vi måttet lete på forskjellige steder etter feil. Versjonskontroll-verktøyet Git hadde vært lite brukt av gruppemedlemmene i forkant av dette prosjektet, og krevde en del tid i starten av utviklingen. Til å begynne med ble Git benyttet så profesjonelt som mulig med at hvert gruppemedlem hadde en egen gren med sin egen kopi av IEZ. På grunn av størrelsen på prosjektet og hvor få medlemmer det er på gruppen gikk vi bort i fra dette siden det tok mer tid å opprettholde denne strukturen på Git enn det faktisk hjalp i utviklingen. Vi gikk over til at alle på gruppen hadde tilgang til den samme versjonen av IEZ og holdt denne oppdatert sammen. Dette fungerte fint da mye av arbeid foregikk sammen og vi hadde god kommunikasjon gjennom hele prosessen. Til å holde kontakten benyttet vi Slack som er et profesjonelt verktøy vi hadde lite problemer med. Valget å bruke Slack foran Facebook sine tjenester var for å holde samtalene profesjonelle og mulighetene for å legge inn meldinger fra kalender, Trello og Git i Slack så alle fikk beskjed om endringer der. 6.6 PROSESS OG PLANLEGGING 88

89 Under diskusjonene rundt fremdriftsplanen i januar var det lite forventninger om at antagelsene våre skulle stemme så godt. Hvor lang tid som skulle brukes til de forskjellige delene av prosjektet ble beregnet på grunnlag av prosjekter gruppemedlemmene hadde hatt tidligere i studiet, men ingen av disse prosjektene kunne direkte sammenlignes med en bacheloroppgave. Å benytte Trello til å dele opp oppgavene mellom gruppemedlemmene fungerte bra, men kunne til tider bli lite brukt siden nesten alt av samarbeidet foregikk sammen på skolen og det alltid var god kommunikasjon i gruppen. Gruppemedlemmene hadde lite erfaring med programmeringsspråk, rammeverk og verktøy som ble brukt til utviklingen av IEZ. Det kunne by på flere uventede problemer og bruk av tid på uplanlagte oppgaver. Det har vært en bratt læringskurve for å kunne gjennomføre prosjektet da alt er laget av oss og alt er laget fra grunnen av uten bruk av noen eksisterende systemer fra Induct Software Samarbeid med Induct Software Induct Software har vært lite involvert i prosessen. Dette har både vært positivt og negativt. Det har vært negativt ettersom selve planleggingen og utviklingsprosessen har tatt lengre tid, med tanke på at dette er noe vi har gjort på egenhånd. Utover en del teori knyttet til gründer-markedet og forslag til krav i kravspesifikasjonen, så har prosjektet blitt utført selvstendig av gruppemedlemmene. Det har også vært positivt ettersom gruppen har hatt stort læringsutbytte fra å ha jobbet mye selvstendig. Med en åpen kravspesifikasjon har gruppen fått jobbet med de teknologier som er interessante og relevante for arbeidsmarkedet. 89

90 6.7 TESTING Systemtest kunne ha blitt gjort av flere testere. Selv om et par feil og mangler ble oppdaget, ville det vært positivt med flere tilbakemeldinger. Hadde gruppen fått lagt ut en prototype på en server så ville systemtesting vært enklere å gjennomføre. Det var ikke mulig å gjøre det for prosjektet ettersom gruppen ikke hadde tilgang på server. Akseptansetest har gått bra med tanke på at de kravene som var satt ble oppfylt. Enhetstesting og integrasjonstesting har blitt gjort manuelt. Selve koden har blitt sjekket at utføres på riktig måte, men det har ikke blitt brukt noe dedikert testing-program. Et slikt program ville gjort feilsøking enklere og skjulte feil ville lettere ha blitt oppdaget. Med tanke på størrelsen til IEZ nå så har det gått greit å teste kode manuelt, men når IEZ blir større så vil det bli aktuelt å se mer på automatisert testing 90

91 7 KONKLUSJON Gruppen har fått et godt læringsutbytte av prosjektet, som har både vært utfordrende og spennende. Med bruk av nye teknologier og kjente verktøy, har gruppen tilegnet seg kunnskap som er relevant for arbeidslivet. Det har vært interessant å bevege seg inn på det området som er maskinlæring. Selv om det var et ukjent område for gruppen, ble det utviklet en løsning som gir et godt bilde på hvordan dette fungere i en fremtidig versjon av IEZ. Målet med prosjektet ble å lage en webapplikasjon som gjør det enklere for oppstartsbedrifter å skaffe investeringer, og for investorer å finne oppstartsbedrifter å investere i. For å løse dette, ble det utviklet en webapplikasjon med tilhørende API og database, kalt Induct Entrepreneur Zone. IEZ tilbyr funksjonalitet knyttet til registrering og administrering av brukere, samt oversikt over relevant statistikk. Det ble utviklet en enkel matching-funksjon for en-til-en matching og en mer avansert maskinlæringsbasert del av matching-funksjonen som presenterer tilpasset innhold til brukere. Ved å kreve at både oppstartsbedrift og investor må trykke match på hverandre før kontakt kan opprettes, får oppstartsbedriften tidlig en bekreftelse på at dette er en passende investor. IEZ er nå blitt mye mer enn bare en fungerende webapplikasjon. Bruk av ny og relevant teknologi har vært sentralt for utviklingen. Det har blitt lagt stor vekt på å følge god praksis som gjelder ved utvikling av denne type webapplikasjon. Brukertesting ble utført og IEZ tilfredsstiller de forventede kravene fra brukere. Det har blitt lagt fokus på sikkerhet, design av systemet og muligheten for å legge til mere funksjonalitet og brukergrupper. Alt dette bidrar til et godt rammeverk for videreutvikling. I akseptansetesten ble det fastslått at alle punkter i kravspesifikasjonen er innfridd. 91

92 8 VIDERE ARBEID I dette kapittelet gis det et bilde på hvordan den endelige versjonen av IEZ potensielt kommer til å se ut. Det blir også gått igjennom tilleggsfunksjonalitet som kan bli implementert i en videre utvikling av IEZ. 8.1 BESKRIVELSE AV INDUCT ENTREPRENEUR ZONE - DEN ENDELIGE APPLIKASJONEN Den endelige versjonen av Induct Entrepreneur Zone vil ha flere funksjonaliteter og flere muligheter for registrering av investorer. Det er tenkt at det den endelige versjonen kommer til å gjøre større bruk av faseinndelingen av oppstartsbedrifter. Til dette prosjektet har denne faseinndelingen kun vært til bruk for å matche investorer med deres foretrukne oppstartsbedrift. Hvordan faseinndelingen kommer til å brukes i den endelige webapplikasjonen: Når en oppstartsbedrift registrerer seg, vil denne fortsatt ha mulighet til å velge mellom de tre fasene, slik som det også fungerer nå. Hvis oppstartsbedriften velger å kun registrere seg med en ide, vil ikke noe videre dokumentasjon sendes inn. Hvis oppstartsbedriften registreres som på vei eller klar til oppskalering, er det nødvendig for bedriften å svare på et nytt skjema besvares for å kunne validere at denne bedriften faktisk plasseres i riktig fase. Hvis oppstartsbedriften befinner seg i en tidlig fase og mener at den nå kvalifiserer seg til å gå videre til neste fase, må et nytt skjema besvares for å kunne avgjøre om denne bedriften skal gå videre til neste fase. Ideen med denne faseinndelingen er å kunne la noen som bare har en ide komme å registrere seg for så å skalere i gjennom fasene og komme ut på andre siden som et fungerende selskap. Induct Entrepreneur Zone kommer til slutt å integreres med Induct Software sin allerede eksisterende løsning. Den endelige versjonen kommer til å åpne muligheter for folkefinansiering av oppstartsbedrifter og ideer. 92

93 Det kommer til å bli mulig for oppstartsbedrifter å søke etter nye personer å ansette, samtidig som det skal være mulig for enkeltpersoner og søke på jobber. Det skal være mulig for store bedrifter som ønsker å investere å registrere flere brukere under seg. Det skal fungere slik at et selskap registrerer seg for så selv å ha mulighet til å opprette nye brukere som tilhører den bedriften. Det er også tenkt at det skal utvikles en egen mobilapplikasjon. Denne applikasjonen skal ha mye mer fokus på matchingen. 8.2 FLERE FUNKSJONALITETER Utover det som ble gjort og som var satt som must have, så er det mer funksjonalitet som er markert nice to have. Disse funksjonalitetene som er markert nice to have er funksjonaliteter som skulle tas med hvis det ble tid. Under er en oversikt over de funksjonalitetene som ikke ble implementert. Deaktivering av brukere Det skal være mulig for en bruker å deaktivere seg selv. Hvis en bruker deaktiverer seg selv, vil den ikke komme opp som foreslått match hos andre. Den vil heller ikke komme opp på endelige matcher. Denne deaktiveringen vil kun gjøre at andre brukere ikke kan se den deaktiverte brukeren. Brukeren vil fortsatt ligge i databasen og administrator vil fortsatt kunne se og endre den. Når den deaktiverte brukeren velger å logge inn igjen, vil den bli aktivert og igjen være mulig å matche med. Deaktivering av inaktive brukere Hvis en bruker som har registrert seg ikke er aktiv på et gitt antall dager, kan denne brukeren settes til å være inaktiv. Når brukeren settes til å være inaktiv, vil det fungere på samme måte som når den deaktiverer seg selv. Egen side hvor brukere kan søke etter andre brukere Dette er en egen side for alle brukere av IEZ som gir mulighet til å søke i hele databasen, uavhengig av hva deres bestemte preferanser er. 93

94 Det skal være mulig å filtrere søket basert på hvilke felter brukeren velger. Hvis brukeren for eksempel velger Norge som land så vil det kun komme opp investorer/oppstartsbedrifter som holder til i Norge. La investor registrere flere investeringer Vanligvis er det ikke slik at investorer kun investerer i en bedrift, men heller flere ideer og bedrifter. I en senere versjon av IEZ blir det aktuelt å gjøre om dette. Da må det gjøres om på blant annet databasen slik at det blir laget en egen tabell med ønskede matcher fra investorer, som da blir koblet til investor-tabellen. La brukere legge til andre som favoritter Dette gjelder nok mest for investorer, men er en funksjonalitet som skal være tilgjengelig for både investorer og oppstartsbedrifter. Det kan være tilfeller der IEZ ikke gir nok informasjon om bedriften og det kanskje må gjøres litt mer research før det kan tas en endelig beslutning. Da vil det være greit å ha en funksjonalitet som lett lar brukeren finne fram til denne igjen uten å måtte bla gjennom flere sider med potensielle matcher. Chat-funksjon Slik funksjonaliteten er nå så blir det kun presentert kontaktinformasjon når to parter matcher. En ide fra Induct Software var at IEZ skal administrere det meste som trengs når det kommer til å skaffe investeringer fra investorer. Rapportering av falske brukere Legge til en knapp på hver profil som gir andre brukere mulighet til å rapportere andre brukere de mistenker kan være falske. Når en bruker rapporteres, fjernes denne fra foreslåtte matcher til den som rapporterer. Deretter får administrator muligheten til å gå igjennom rapporterte brukere for så å avgjøre om dette faktisk er en falsk profil. En investor har sett profilen din Dette gjelder for oppstartsbedrifter ettersom investorer kommer til å ha mer enn nok oppstartsbedrifter som ser på profilen deres. Dette er en funksjonalitet som skal gi oppstartsbedriftene motivasjon til å fortsette å bruke IEZ. Slik IEZ er nå, er det ikke mulig å 94

95 implementere denne funksjonen, for å gjøre det så må det utvikles egne sider for hver bruker slik at det går an å registrere hvem som går inn på dem. Verifisering av profiler Dette er for å gi trygghet til både oppstartsbedrifter og investorer. Nøyaktig hvordan denne verifiseringen skal skje er enda ikke avgjort. En mulighet er at dette gjøres av Induct Software ved at brukere sender inn informasjon om bedriften sin. Når en profil er verifisert, vil det legges til et merke som vises når andre ser på profilen. Verifisering av e-post Dette er en funksjonalitet som skal gjøre profilene til brukerne sikrere. Når en bruker registrerer seg i starten, blir de bedt om å trykke på linken som blir sendt på mail for å kunne logge inn. Det er viktig for brukere å verifisere epost ettersom dette er eneste måte å tilbakestille passord på. For når det passord skal tilbakestilles så sendes det en mail med en link som lar brukere sette et nytt passord. 95

96 9 REFERANSER 1. Statistisk sentralbyrå. statisisk sentralbyrå. Foretak. [Internett] Den Norske Stat, [Sitert: ] 2. CB Insights. Cbinsights. The top ten reasons startups fail. [Internett] Cb inc., [Sitert: ] 3. European Commision. European Commision. Growth. [Internett] [Sitert: ] open startups. 100 Open Startups. Home. [Internett] Kiwano, N/D N/D N/D. [Sitert: ] 5. Tobiassen, Markus. Dagens næringsliv. DN grunder. [Internett] Dagens Næringsliv, [Sitert: ] 6. Angular. Angular. Glossary. [Internett] Google inc, N/D N/D [Sitert: ] Angular. Angular homepage. [Internett] Google inc., N/D N/D [Sitert: ] 8. World wide web consortium. World wide web consortium. Html. [Internett] World wide web consortium, [Sitert: ] World wide web consortium. Cascading style sheets homepage. [Internett] World wide web consortium, [Sitert: ] Bootstrap. bootstrap. Bootstrap Home. [Internett] N/A, N/D N/D [Sitert: ] Microsoft. Microsoft. Microsoft.NET. [Internett] Microsoft, N/D N/D [Sitert: ] Microsoft..NET languages. [Internett] Microsoft, [Sitert: ] Microsoft. Microsoft developer network. [Internett] Microsoft, [Sitert: ] Microsoft Azure. Microsoft SQL Database. [Internett] Microsoft, [Sitert: ] ASP. Learn about ASP.NET Web API. [Internett] Microsoft, N/D N/D [Sitert: ] Fowler, Martin. Martinfowler. eaacatalog. [Internett] Martin Fowler, N/D N/D N/D. [Sitert: ] 96

97 17. Wong, Connie. Website Builder Expert. How to choose a good color scheme for your website. [Internett] Best website builder reviews, [Sitert: ] Hit Reach. HitReach. Perfect webpage. [Internett] Hit reach, N/D N/D [Sitert: ] World Wide Web Consortium. World Wide Web Consortium. Web Content Accessibilty guidelines. [Internett] World Wide Web Consortium, [Sitert: ] Cisnero, Kristina. Hootsuite. Blogs. [Internett] Hootsuite media inc., [Sitert: ] Guzel, Burak. EnvatioTuts. Html and css. [Internett] Envato Pty Ltd, [Sitert: ] net Angular. Angular. Styleguide. [Internett] Google inc., N/D N/D [Sitert: ] Hosch, William L. Encyclopedia Britannica. Machine Learning. [Internett] Encyclopedia Britannica inc., N/D N/D N/D. [Sitert: ] Kaliski, B. Internet engineering task force tools. Password-Based Cryptography Specification Verson 2.0. [Internett] The internet society, N/D [Sitert: ] Xorbin.com. Xorbin. Tools. [Internett] Xorbin.com, N/D N/D [Sitert: ] Mazieres, Niels Provos and David. Usenix. Legacy events. [Internett] Usenix, [Sitert: ] Kukic, Ado. Auth0. Blog. [Internett] Auth0 inc., [Sitert: ] World Wide Web Consortium. w3 schools. SQL Injection. [Internett] World Wide Web Consortium, N/D N/D [Sitert: ] GUST. GUST. home page. [Internett] GUST, N/D N/D [Sitert: ] Angel.co. Angel.co. home page. [Internett] Angel.co, N/D N/D [Sitert: ] YouNoodle inc. younoodle. home page. [Internett] YouNoodle inc., N/D N/D [Sitert: ] Stack overflow. Stack Overflow. Developer survey results. [Internett] Stack overflow, N/D N/D [Sitert: ] World Wide Web Consortium. w3 Schools. Bootstrap modal plugin. [Internett] World Wide Web Consortium, N/D N/D [Sitert: ] 97

98 34.. w3 schools. JSON - introduction. [Internett] World Wide Web Consortium, N/D N/D [Sitert: ] National Institute of Standards and Technology. NIST. Authentication and Lifecycle Management. [Internett] National Institute of Standards and Technology, [Sitert: ] Software Testing Fundamentals. Software Testing Fundamentals. Differences Between Black Box Testing and White Box Testing. [Internett] Software Testing Fundamentals, N/D N/D [Sitert: ] 98

99 10 VEDLEGG Vedlegg 1: Mappestruktur 99

100 Vedlegg 2: Fremdriftsplan 100