WEB APPLICATION DEVELOPMENT REST API & EMBERJS

Transkript

1 WEB APPLICATION DEVELOPMENT REST API & EMBERJS pure hub Prosjektgruppe: Rådgiver: Produkteier: Kunde: Raheel Akhtar Quan Vu Loc Cao Do Kirsten Ribu Tommy Kristoffersen Syscom AS HiOA - Fakultet for teknologi, kunst og design (TKD) 1

2 2

3 PROSJEKT NR. 22 Kull 2011 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET Telefon: Telefaks: HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL Web application development - API & EmberJS DATO PROSJEKTDELTAKERE Raheel Arshad Akhtar (3AA), s Thien-Loc Cao Do (3AB), s Quan Minh Vu (3IA), s ANTALL SIDER / BILAG 128/1 INTERN VEILEDER Kirsten Ribu OPPDRAGSGIVER Syscom AS KONTAKTPERSON Tommy Kristoffersen SAMMENDRAG Vår oppgave er å utvikle en web-basert løsning som skal benyttes til å samle inn viktig informasjon fra og sende informasjon til kunder som har pureservice installert lokalt og pureservice egen skyløsning Løsningen skal bistå den daglige driften av pureservice (DevOps) på Microsoft Azure samt hjelpe Syscom med å samle inn viktig informasjon om de lokalt installerte instansene av pureservice hos kunder 3 STIKKORD REST API EmberJS Webapplikasjon 3

4 4

5 Forord Dette dokumentet omfatter all dokumentasjon gjort i forbindelse med hovedprosjekt i bachelorstudium Ingeniørfag - data og Informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Prosjektet er utført i samarbeid med Syscom AS, og er ment for å gi oss en innsikt i hvordan det er å jobbe med systemutvikling av større prosjekter i næringslivet. Vi kontaktet Syscom AS selv på eget initiativ da vi hadde lyst til å jobbe med systemutvikling for en bedrift med et godt fotfeste i næringslivet. Rapporten består av fem hoveddeler: Presentasjon- en introduksjon av gruppen, oppdragsgiver og prosjektet. Prosessrapport - beskriver utviklingsprosessen. Produktrapport - beskriver produktet vi har utviklet. Testrapport - beskrivelse av tester utført på produktet. Brukerveiledning - en veiledning for hvordan produktet skal brukes. Presentasjonsdokumentet gir en introduksjon til oppgaven og det anbefales at man starter med å lese dette dokumentet. Under denne forutsetningen kan de resterende delene leses som selvstendige dokumenter. I rapporten er det oppgitt referanser på tvers av dokumentene, i disse tilfellene oppgis navn på rapporten og hvilket kapittel det refereres til. Vi vil gjerne takke Kirsten Ribu fra HiOA for all hjelp og støtte hun har bidratt med under prosjektet i sin rolle som veileder og rådgiver. Vi vil også takke våre kontaktpersoner ved Syscom AS, Tommy Kristoffersen og Håkon Vik, som har vært til stor hjelp for oss under prosjektet. Ved å være tilgjengelig til enhver tid og ved å veilede oss under alle faser av prosessen har de vært til en stor hjelp. Uten deres veiledning ville vi ikke hatt mulighet til å levere et såpass brukervennlig og profesjonell produkt. 5

6 6

7 Innholdsfortegnelse Web application development REST API & EmberJS... 1 HOVEDPROSJEKT... 3 Forord... 5 LISTE AV ILLUSTRASJONER Presentasjon Forord Prosjektgruppen Oppdragsgiver Bakgrunn for oppgaven Mål for oppgaven Beskrivelse av sluttproduktet Rammebetingelser og konsept Prosessrapport Forord Planlegging og metode Planlegging Arbeidsforhold Kommunikasjon Samarbeid - prosjektgruppen Samarbeid med oppdragsgiver Samarbeid med veileder Styringsdokumenter Statusrapport Prosjektskisse Forprosjektrapport Prosjektdagbok Risikoanalyse Risikotabell Risikohåndtering Fremdriftsplan Kravspesifikasjon Versjonskontroll og backupløsninger Teknologier og verktøy Verktøy Visual studio TFS(Team Foundation Server) Microsoft Word Postman Ember Inspector Kompilator

8 Twitter bootstrap Pluralsight Stackoverflow Microsoft Azure Web Sites Localstorage Språk Javascript AJAX JQuery HTML JSON CSS SQL Rammeverk og testing EmberJS Ember Canary Odata FlotCharts Entityframework RESTFUL API Webgrease Testing Mocking Dependency injection Moq Om utviklingsprosessen Utviklingsmetode Scrum Tilegning av kunnskap Faser Avsluttende del Det ferdige produktet Utbytte for oppdragsgiver Læringsutbytte Tilbakemelding fra oppdragsgiver Videreutvikling og vedlikehold Konklusjon Produktrapport Forord Innledning Bakgrunn for oppgaven Kodespråk og prinsipper angående syntaks Prinsipper Språk Struktur Backend Server Databasen Controllere UnhandledExceptionFilter Frontend Funksjonalitet Lasting av data Visning av data Lagring av data

9 23.5 Komponenter Flot Chart Filter komponent Query params Local Storage Metadata Samsvar med kravspesifikasjon og produkt Oppfyllelse av krav Avslutning Produktets kvaliteter Tilbakemelding Videreutvikling og vedlikehold Konklusjon Testrapport Forord Metoder Verktøy til testing: Feiltesting av kode Testing på forskjellige nettlesere Brukertesting Konklusjon Brukermanual Forord Startsiden Filter Konfigurasjon Errors Usages Customers Vedlegg Kravspesifikasjon Innledning Om bedriften Bakgrunn for prosjekt Forord Krav til oppgaven Kildeliste

10 10

11 LISTE AV ILLUSTRASJONER (Numerisk Ordre) Skjermbilde 1: Logoen til Syscom Skjermbilde 2: Logoen til Pureservice Skjermbilde 3: Noen av Syscoms kunder Skjermbilde 4: Skisse av løsningen Skjermbilde 5: Syscoms tilholdssted Skjermbilde 6: Bilder av kommunikasjon verktøy Skjermbilde 7: Graf over utfordringer under utviklingen Skjermbilde 8: Fremdritfsplanen Skjermbilde 9: Visual studio Skjermbilde 10: Team Foundation Server Skjermbilde 11: Postman i Chrome Skjermbilde 12: Ember Inspector i Chrome Skjermbilde 13: Hvordan en typisk kompilator opererer Skjermbilde 14: Twitter bootstrap Skjermbilde 15: Oversikt over hva Pluralsight dekker Skjermbilde 16: Stackoverflow Skjermbilde 17: Windows Azure Websites Skjermbilde 18: Localstorage Skjermbilde 19: JSON Skjermbilde 20: SQL Skjermbilde 21: EmberJS Skjermbilde 22: Ember Canary Skjermbilde 23: OData Skjermbilde 24: FlotCharts Skjermbilde 25: Entityframework Skjermbilde 26: Oversikt over sprintene Skjermbilde 27: Backlogs Skjermbilde 28: User stories og tasks Skjermbilde 29: Definisjon av done Skjermbilde 30: Fokuspunktene Skjermbilde 31: ER-modell 11

12 Skjermbilde 32: Relasjon mellom BLL, DAL, Web og Domain Skjermbilde 33: En liten bit av generiske repository Skjermbilde 34: Illustrasjon av hvordan en spørring ser ut Skjermbilde 35: Balsamiq mockups Skjermbilde 36: SOLID prinsippene Skjermbilde 37: ER modell med attributter Skjermbilde 38: Kodesnutt Queryable Skjermbilde 39: Filteret Skjermbilde 40: Informasjon om feilen som blir lagret Skjermbilde 41: Oversikt over filene Skjermbilde 42: Kodesnutt getapi Skjermbilde 43: En liten bit av templaten Skjermbilde 44: Logging av feil på frontend Skjermbilde 45: Filteret Skjermbilde 46: Query params Skjermbilde 47: Localstorage Skjermbilde 48: Metadata parser Skjermbilde 49: Tilbakemelding fra Syscom AS Skjermbilde 50: Kodesnutt fra testing 12

13 Presentasjon PRESENTASJON HiOA - Fakultet for teknologi, kunst og design (TKD) Kull

14 Presentasjon 14

15 Presentasjon 1. Forord Dette dokumentet skal gi leseren informasjon om gruppen, oppdragsgiver, samt mål og bakgrunn for oppgaven. Vi anbefaler å lese presentasjon før videre lesing av rapporten. Dokumentet er beregnet for alle som ønsker å få et innblikk i prosjektet vårt. 2. Prosjektgruppen Vi er en gruppe på tre studenter fra Høgskolen i Oslo og Akershus og består av Quan Vu(IT), Raheel Akhtar(Data-ing) og Loc Cao Do(Data-ing). Vi har arbeidet sammen før i forbindelse med tidligere prosjekter under studiet med stor suksess, og kjenner derfor hverandres faglige styrker meget godt. Vi regnet med det å danne en gruppe sammen som en selvfølge da vi føler vi har like stor interesse og like høye ambisjoner innen systemutvikling og web-teknologi. 3. Oppdragsgiver Vår oppdragsgiver er Syscom AS som ble etablert i 1987 av Ole Bryhn. Syscom har kontorer i København, Stockholm og Oslo. Syscom er spesialist på IT Service Management, IT Security og Client/Infrastructure Management. Syscom har over 25 års erfaring med verktøy, prosesser, opplæring og tjenester rundt IT Service Management. Skjermbilde 1: Logoen til Syscom Pureservice(tidligere kalt Support Point) er en del av Syscom og utviklingsavdelingen holder til på Majorstuen, i hjertet av Oslo. Pureservice er et servicedesk-verktøy som Syscom tilbyr til kundene sine. Skjermbilde 2: Logoen til Pureservice 15

16 Presentasjon I over 25 år har de jobbet med flere anerkjente selskaper som: Norsk Gjenvinning, Asker kommune, NHO, Kongsberg Maritime, Kirkens Bymisjon, ABB, Odin Forvaltning, Finnmark fylkeskommune, Hasselblad, Larvik Kommune, Skatteetaten, Avinor, Universitetet i Stavanger, TV2, Sparebank2 4. Bakgrunn for oppgaven Skjermbilde3: Noen av Syscoms kunder. Syscom AS har mange kunder som benytter seg av pureservice. For å holde oversikt over dette trengs det ha en løsning som støtter opp under alle applikasjonene som er i produksjon under produktnavnet pureservice. Løsningen skal få informasjon fra alle produktene, samle disse og presentere data på en god måte. Med «informasjon» menes for eksempel brukerstatistikk, feillogger, lisensinformasjon, informasjon om oppdateringer av Pureservice, nyheter og oppdateringer til pureservices egen «app store». Syscom AS hadde fra før allerede planlagt hvordan løsningen skulle se ut, men hadde ikke tid eller kapasitet til å gjennomføre dette. 16

17 Presentasjon Hensikten med løsningen er at den skal bistå den daglige driften av pureservice (DevOps) på Windows Azure samt hjelpe Syscom AS med å samle inn viktig informasjon om de lokalt installerte instansene av pureservice hos kunder. Løsningen skal også inneholde et register over de kundene som har kjøpt lisens. Web-baserte løsningen skal gjøre det enklere for Syscom AS å drifte produktene sine og det skal virke på flere området i selskapet. Pureservice har utviklet seg raskt de siste årene, og er å finne i de fleste plattformer. Det er derfor viktig at den skal kunne klare å kommunisere med alle plattformer. Skjermbilde 4: Skisse av løsningen 5. Mål for oppgaven Hovedmålet med oppgaven var å utvikle en løsning som skal benyttes til å samle inn viktig informasjon fra og sende informasjon til kunder som har pureservice installert lokalt og Puresvervices egen skyløsning Med «informasjon» menes for eksempel brukerstatistikk, logger, lisensinformasjon, informasjon om oppdateringer av Pureservice, nyheter og oppdateringer til pureservices egen «app store». Alt dette vil bli lagd i en fristilt hub i Azure som kan bli brukt av alle produktene i porteføljen. Hubben skal være en 17

18 Presentasjon tjeneste for å ta imot data fra produktene i porteføljen, lagre disse i en database tilby dataene via et REST API, og presentere dataene. Kundedata hentes ved at har blitt integrert mot eksisterende salgs- og faktureringsverktøy. Videre har det blitt gjort mulig til å redigere/legge til kundedata i samme løsning, som for å oppdatere lisenser eller opprette/avslutte et abonnement fullstendig. Web-baserte løsningen skal tilby: Lagre feil(exceptions/error) i databasen, både server - og klient-siden. Vise, sortere og gruppere feil som har oppstått Søke etter feil med filtrering Rapportere en feil som har blitt fikset Loggføre brukerstatistikk Presentere dataene i en tabell og i grafer Legge til nye kunder Brukervennlig SPA(single-page-application) løsning Web-baserte løsningen bør tilby: Forsiden skal kunne konfigureres etter eget ønske og det blir lagret i localstorage I tillegg hadde vi følgende visjoner å strekke oss etter: Lære oss Ember js, og bruke kunnskapen til å lage den beste web-baserte løsningen 18

19 Presentasjon 6. Beskrivelse av sluttproduktet Prosjektets sluttprodukt er en Hub som brukes til å lagre informasjon om kunder som benytter seg av pureservice. 7. Rammebetingelser og konsept Før selve programmeringen og planleggingen av løsningen startet, gikk gruppen og veilederen fra Syscom AS grundig gjennom en konseptutviklingsfase. Der kom vi fram til at løsningen skulle følge Syscom AS sin standard og utvikles i C#/.NET, på Visual Studio, i MVC arkitektur. Videre skulle løsningens brukergrensesnitt benytte seg av SPA rammeverket EmberJS og dataene skulle tilbys via et REST-API. Sluttproduktet skulle ligge på en server hos Syscom i Microsoft Azure, og med tanke på sikkerheten for Syscoms servere er våres tilgang til Syscoms servere begrenset til at vi kun kan publishe prosjektet og hente connectionstringen til databasen. Utviklingsmetoden som skulle anvendes var Scrum fordi det var denne metodikken som ble brukt hos Syscoms utviklerteam. Syscom AS ønsket at vi skulle følge deres standard og retningslinjer innen utvikling, og ville derfor at vi skulle jobbe med smidig metodikk, og da med metodikken Scrum. Det krever ingen ekstra økonomiske ressurser for oppdragsgiveren, skolen eller gruppen å utvikle systemet. Det eneste oppdragsgiveren har ansvar for i utgangspunktet er å sette opp en server og en database slik at utviklingen av systemet kan settes i gang. Under følger en kort beskrivelse av rammeverk og teknologier som skulle anvendes i prosjektet: EmberJS EmberJS er en «open-source» klient-side javascript applikasjon, og rammeverket er basert på Model-View-Controller(MVC) arkitekturen. Den tillater SPA(single-pageapplications), som er web-applikasjoner på en enkelt HTML-side der alle ressurser blir lastet opp ved en enkelt page load, videre oppdateres siden dynamisk, når brukeren navigerer seg rundt. 19

20 Presentasjon Microsoft Azure Microsoft Azure(tidligere kalt Windows Azure) er en åpent og fleksibelt sky plattform, laget av Microsoft, for å bygge, distribuere og administrere applikasjoner og tjenester gjennom et globalt nettverk av Microsoft-administrerte datasentre. REST-API REST(Representational State Transfer) er en enkel "stateless" arkitektur som vanligvis går over HTTP. REST er avhengig av en klient-server, og er standard bibliotek i C#. REST-API blir identifisert av en navngitt URI, og åpnes ved hjelp av HTTP metoder (HEAD, GET, POST, PATCH, DELETE). Dataene blir vanligvis representert i XMLformat men dette kan endres til JSON hvis man ønsker. En URI for å vise f. eks alle dataene i en tabell kalt errorlog i databasen kan f. eks se slik ut: REST-API gjør det enkelt for andre brukere å få tilgang til dataene og bruke det. Dette er en av de største fordelene i REST-API og i vårt tilfelle er Pureservice brukerne. Det er i tillegg viktig å sikre databasen mot modifisering fra uautoriserte brukere. Det er derfor et stort fokus på sikkerhet for å hindre andre brukere enn Syscom får tilgangen. 20

21 Prosessrapport PROSESSRAPPORT HiOA - Fakultet for teknologi, kunst og design (TKD) Kull

22 Prosessrapport 22

23 Prosessrapport 8. Forord Det forutsettes at leseren av dette dokumentet har lest og gjort seg kjent med presentasjonsdokumentet. Under denne forutsetning kan dette dokumentet leses selvstendig. Denne oppbygningen har vi for å gi et bedre innblikk i hva vår oppgave går ut på, informasjon om gruppen og oppdragsgiver med mer. Denne rapporten beskriver vår arbeidsprosess for hovedprosjektet og er beregnet for sensor og veileder. Vi forutsetter at leseren er kjent med datatekniske begreper, men de vil bli forklart underveis. 9. Planlegging og metode Denne delen vil beskrive hvordan vi gikk frem for å planlegge arbeidsprosessen, og hvilke verktøy vi har brukt for planlegging og utvikling. 9.1 Planlegging Planleggingen av prosjektet startet fra første møtet med oppdragsgiver den 3. desember, hvor det ble gitt informasjon om oppgaven. Vi bestemte oss ganske fort at dette var noe vi ønsket å jobbe med, dermed kunne planleggingen av prosjektet starte. Det ble inngått en skriftlig samarbeidsavtale mellom prosjektgruppen, oppdragsgiver og høyskolen. Til å begynne med var vi uerfarne innen Javascript og rammeverket EmberJs, derfor var vi klar over at vi ville bruke en del tid på å lære oss dette. Prosjektet hadde en offisiell oppstartdato 6. januar. Tiden mellom første møtet med oppdragsgiver og prosjektets startdato ble brukt på å lære seg Javascript og EmberJS rammeverket. Oppdragsgiver anbefalte oss å bruke Pluralsight som er en læringsportal som blant annet utviklere i Syscom AS bruker. Vi fikk låne en bruker på Pluralsight for innlogging, og dermed var forberedelsene til prosjektet allerede i gang. Planlegging har vært en sentral prosess, ikke bare i starten av prosjektet, men underveis i hele prosjektperioden. En god del planlegging ble gjort ved oppstart, men noe har blitt forandret underveis. Med metodikken Scrum som vi brukte for utviklingsfasen ble det mye enklere å endre på planleggingen. Man må forvente at det ofte oppstår endringer underveis og derfor er det viktig å gjøre planleggingen så fleksibel som mulig. 23

24 Prosessrapport 10. Arbeidsforhold Medlemmene i gruppen var godt kjent med hverandre, og visste hverandres svake og sterke sider. Gjennom studiet har vi som gruppe bygget sterk tillitt til hverandre. Derfor har det vært en ganske enkel oppgave å fordele arbeid, og vi visste at vi kunne stole på hverandre, og at jobben ble gjort. Ved oppstarten i januar ble det bestemt i samarbeid med Syscom AS at vi skulle få faste plasser med en tilhørende tavle/scrumboard i deres utviklingslokal. Dette gjorde at vi kunne jobbe nært med utviklerne og konsulentene fra Syscom AS og kunne derfor spørre dem om hjelp etter behov. Lokalet ligger i KPMG bygget i Majorstua, og vi skulle møte opp 3 dager i uka, mandag, tirsdag og fredag. Mens onsdag og torsdag var beregnet for arbeid med fag i tillegg til prosjektet. En typisk arbeidsdag i utviklingsprosessen kunne se slik ut: 1. Arbeidstid på 09:00 til 17:00 på Syscom AS 2. Jobbe hjemme ved behov. Arbeidstype 1 var den hyppigste arbeidsformen, den sparte oss for unødvendig arbeid med å vise hverandres problemer på dataskjermen. Vi benyttet oss av Scrum metodikken, som vi skal forklare i "utviklingsmetode" kapittelet, og hadde 2 uker lange sprinter. Det ble beregnet at vi hadde 72 timer i kapasitet i hver sprint. Arbeidstiden var vanligvis fra 09:00 til 17:00, men i noen tilfeller har vi måttet jobbet ekstra for å bli ferdig med sprinten i tide. Skjermbilde 5:Syscoms tilholdssted 24

25 Prosessrapport Vår oppgave var veldig utfordrende siden ingen av oss hadde vært borti SPA rammeverket EmberJS før. Det var mye å sette seg inn i, og mye nytt vi måtte lære oss. Men vi hadde fordelen av at vi hadde lært. NET/C# på Visual Studio i løpet av studeit, og trengte derfor ikke opplæring innen det. Vi hadde faste plasser på Syscom AS utviklingslokal, og dette dro vi stor nytte av. Vi hadde fordelen av at vi ikke trengte å reservere grupperom på skolen og dermed kunne konsentrere oss mer om prosjektet. 11. Kommunikasjon Dette delkapittelet gir en beskrivelse av kommunikasjon og samarbeidet innad prosjektgruppen, med oppdragsgiver og med veileder Samarbeid - prosjektgruppen Før oppstarten av prosjektet benyttet gruppen skolens grupperom til å holde av møter. Mye av kommunikasjon foregikk gjennom Facebook og vi har i tillegg lagt til en privat side på Facebook kun for medlemmer av gruppen. Vi brukte også sms/mobil slik at vi kunne kontakte hverandre i alle døgnets tider, og holde hverandre oppdatert. Som nevnt tidligere ble det avtalt ved oppstarten av prosjektet at vi skulle jobbe eksplisitt med prosjektet i Syscoms lokaler tre dager i uken. Mye av kommunikasjonen foregikk dermed i Syscoms lokaler, hvor vi satt sammen med hverandre og kunne diskutere og utvikle sammen. Samarbeidet i gruppen har vært veldig bra. Vi har hatt flere diskusjoner underveis både innad i gruppen og med oppdragsgiver da det har vært alternative løsninger til utviklingen og i forbindelse med viktige avgjørelser. Dette er en av de største fordelene ved bruk av Scrum metodikken, slik kan vi forandre løsningen underveis og optimalisere dette. Gjennom et godt samarbeid har vi funnet en god balanse for hva som er vært best for vårt prosjekt. Skjermbilde 6: Bilder av kommunikasjonsverktøy 25

26 Prosessrapport 11.2 Samarbeid med oppdragsgiver Tommy Kristoffersen har vært vår kontaktperson hos Syscom, og er selv en utvikler. Vi har også fått hjelp av en annen utvikler hos Syscom, Håkon Vik. Vi har hatt jevnlig kontakt med Tommy Kristoffersen under prosjektperioden i form av ukentlige møter, og han hadde bestandig muligheten til å se på tavlen/scrumboardet for å få en oversikt over hvordan det gikk med sprinten vår. Tommy Kristofferesen var produkteier, derfor skulle han alltid være oppdatert med hva vi drev med. Kommunikasjonen har vært meget god, og de har vært veldig imøtekommende og behjelpelige, og vi har følt oss veldig velkomne. I tillegg til kontakt på Syscom AS har vi også hatt kontakt med produkteier gjennom mail. Det har vært en fordel at vår kontaktperson var en utvikler. Dette gjorde kommunikasjonen lettere ettersom han hadde god forståelse for muligheter og utfordringer vi hadde. De ukentlige møtene vi hadde med oppdragsgiver ble ofte brukt til å diskutere fremgang og få tilbakemelding på hvordan funksjonaliteten som nylig hadde blitt implementert samsvarer med kravspesifikasjonen og oppdragivers ønsker. Dette bidro til å gjøre prosjektet så komplett og gjennomført som mulig Samarbeid med veileder Vi ble tildelt Kirsten Ribu som veileder fra HiOA, og ved oppstart av prosjektet sendte vi mail om et mulig møte for å informere hun om oppgaven som har blitt valgt. Vi bestemte at etter hver sprint skulle vi sende mail om hvordan det har gått, og ellers var det ikke nødvendig med flere møter med tanke på at vi var så sydd inn i miljøet hos Syscom. Hun har hatt en mindre rolle i dette prosjektet, da vi følte oss relativ selvgående. Vi har prøvd å være minst mulig avhengige av veiledere og annen hjelp siden vi ville finne løsninger selv. 26

27 Prosessrapport 12. Styringsdokumenter I planleggingsfasen og underveis i prosjektperioden ble det opprettet diverse styringsdokumenter. Disse dokumentene hadde som hensikt å støtte arbeidsprosessen og ble aktivt brukt som hjelpemidler underveis i prosessen Statusrapport Dette er et av de første dokumentene som ble skrevet, og levert rundt desember Dokumentet inneholder en kort beskrivelse av statusen om hvordan vi lå an med å finne en oppgave Prosjektskisse Prosjektskissen inneholder en presentasjon av oppdragsgiver, en kort beskrivelse av oppgaven, kravene som hadde kommet frem på dette tidspunktet og prosjektets rolle i oppdragsgivers virksomhet Forprosjektrapport Dette ble skrevet etter prosjektskissen og var mye mer omfattende. Dokumentet gir en nærmere og mer presis beskrivelse av prosjektet og oppgavens omfang. Det ble bestemt hvilke teknologier og verktøy som skulle benyttes og hvordan oppgaven skulle bli løst. Forprosjektrapporten er tilgjengelig på vår hjemmeside Prosjektdagbok Prosjektdagboken ble opprettet i starten av prosjektet, og ble regelmessig oppdatert av alle prosjektgruppens medlemmer. Men utover i utviklingsfasen følte vi at det var bedre å bruke TFS, som vil bli forklart i delkapittel "Teknologier og verktøy, som dagbok, siden det inneholdt kommentarer på endringer som ble gjort Risikoanalyse For å være bedre i stand til å håndtere uforutsette hendelser som kan påvirke prosjektets fremgang, ble det utarbeidet en risikoanalyse. Analysen tar utgangspunkt i sannsynligheten for at en hendelse inntreffer og hvilke konsekvenser dette har for prosjektets fremgang. 27

28 Prosessrapport 12.6 Risikotabell Tabellen viser en oversikt over ulike risikonivåer avhengig av sannsynligheten for at en hendelse skal inntreffe og konsekvenser. Hendelser Lite farlig Farlig Kritisk Katastrofalt Svært sannsynlig Meget sannsynlig Sannsynlig Lite sannsynlig Risikonivå Lav: 0-3 Middels: 4-5 Høyt: 6 8 Korttidssykdom: Sannsynlighet: Svært sannsynlig Konsekvens: Lite farlig Risikonivå: 5 Tiltak: Fordele oppgaver som er kritiske for prosjektet til andre medlemmene, evt. Jobbe hjemmefra om det er mulig. Langtidssykdom: Sannsynlighet: Lite sannsynlig Konsekvens: Kritisk Risikonivå: 7 Tiltak: Fordele arbeidsoppgaver slikt at prosjektet ikke stopper opp og avhenger av en person. Tidsmangel: Sannsynlighet: Sannsynlig Konsekvens: Kritisk Risikonivå: 5 Tiltak: Ha oversikt og kontroll over planen og viktige frister, jobbe hjemme og i helger. 28

29 Prosessrapport Interne krangler/uenigheter: Sannsynlighet: Lite sannsynlig Konsekvens: Farlig Risikonivå: 4 Tiltak: God kommunikasjon og standup hver morgen for å dele med resten av gruppa hva hver av oss har gjort, og ta noen viktig avgjørelser. Tap av data/informasjon: Sannsynlighet: Lite sannsynlig Konsekvens: Katastrofalt Risikonivå: 5 Tiltak: Team Foundation Server og hver av oss har det lokalt. Faglige/tekniske vanskeligheter: Sannsynlighet: Meget sannsynlig Konsekvens: Farlig Risikonivå: 5 Tiltak: God kommunikasjon med hverandre og oppdragsgiver. Hjelpe hverandre. 29

30 Prosessrapport 12.7 Risikohåndtering Vi fulgte risikoplanen som beskrevet over, dokumentet ga instruksjoner over hva vi skulle gjøre dersom noen problemer skulle dukke opp. Under prosjektet inntraff noen små og store hendelser. Det gikk heldigvis bra siden vi aktivt fulgte planen for å håndtere risikoen som inntraff. Det tilfellet som oftest inntraff var korttidssykdom og det håndterte vi ved at vedkommende jobbet hjemmefra og kontaktet de andre via mobil eller Facebook. Hvis vedkommende var alt for syk, måtte vi omstrukturerte litt så han kunne hvile. Det var heldigvis ikke så mye annet enn korttidssykdom som inntraff, nedenfor ser du en figur med oversikt over hva som har hendt gjennom hele prosjektet Ødelagt utstyr Forsinket (kollektiv) Jobb/andre fag Overtredelse deadline Tekniske vanskeligheter Korttidssykdom 2 0 Januar Februar Mars April Mai Skjermbilde 7: Graf over utfordringer under utviklingen Under følger noen hendelser som førte til noen forsinkelser under utviklingsprosessen: - Etter ca. En måneds tid møtte vi på noen problemer i forbindelse med opplasting av prosjektet på Azure. Problemet var at vi hadde gått tom for credits. Credits tilsvarer antall opplastninger til Azure server. - I løpet av mars utgikk lisensen av Visual Studio 2013 og den måtte da fornyes. - I begynnelsen av Mai-måned hadde vi noen eksamener som krevde en del tid. Derfor måtte vi omprioritere litt for å gjennomføre eksamener. 30

31 Prosessrapport 12.8 Fremdriftsplan For å lettere holde oversikt over prosjektets fremgang og ulike aktiviteter som skulle utføres parallelt, opprettet vi en fremdriftsplan. Denne planen gir en grov oversikt over de ulike fasene av prosjektet, samt hvilke aktiviteter som skal utføres til hvilken tid. I fremdriftsplanen satte vi opp milepæler i samsvar med viktige frister. Planen er utformet som et gantdiagram for å lett kunne holde oversikt over de ulike tidsperiodene. Fremdriftsplanen ble justert for endringer underveis i prosjektperioden Skjermbilde 8: Fremdriftsplanen 31

32 Prosessrapport 13. Kravspesifikasjon Kravspesifikasjonen er brukt som et styringsdokument og er mer eller mindre bestemt av kunden. Hensikten med kravspesifikasjonen var å gi oss og oppdragsgiver en bedre forståelse av funksjonaliteten til web-løsningen som skulle utvikles. Den er en form for skriftlig avtale mellom prosjektgruppen og oppdragsgiver, og har blitt oppdatert kontinuerlig. I og med at vi har benyttet oss av Scrum, har dette gjort at kravspesifikasjonen har hatt en del endringer underveis. Dette gjelder i hovedsak hvordan ting skulle utvikles, men også funksjonaliteten som skulle utvikles og implementeres. 14. Versjonskontroll og backupløsninger Til dokumentasjonen benyttet vi Microsoft Word og dokumentet ble kontinuerlig oppdatert og delt ut til gruppemedlemmene på Dropbox. Før vi lagret måtte vi forsikre at ikke flere enn en jobbet på samme fil slik at vi ikke mistet viktig informasjon. Vi har derfor vært påpasselig med å lagre nye versjoner. Når vi kom til utviklingsfasen benyttet vi Microsoft Visual Studio med Team Foundation Server. Det ble bestemt av Syscom AS at vi skulle bruke dette, da de selv bruker det til sine web-løsninger. Vi var fra før godt kjent med det og hadde derfor ingen problemer. Dette gjør at vår oppgave vil derfor lettere kunne brukes som referansestoff for dem. For å publisere web-løsningen benyttet vi Microsoft Azure som er en åpen og fleksibel sky-plattform. Syscom AS benyttet seg av dette og ville også at vi skulle bruke det, slik at de har oversikt over vår web-løsning og tilgang til å lagre data i databasen. 32

33 Prosessrapport 15. Teknologier og verktøy Dette delkapittelet gir en oversikt og beskrivelse av hvilke teknologier vi har tatt i bruk og verktøy som ble benyttet til analyse, utvikling, testing og kommunikasjon i prosjektperioden Verktøy Visual studio Visual studio er et komplett sett med utviklerverktøy for bygging av ASP.NET webapplikasjoner, XML Web Services, desktop - og mobile applikasjoner. For å kunne ta i bruk Visual Studio, må man ha Windows operativsystem. Vi benyttet dette til utvikling av vår web-baserte løsning. Skjermbilde 9: Visual studio TFS(Team Foundation Server) TFS er et produkt utviklet av Microsoft, innebygget i Visual Studio og benyttes til samarbeidsprosjekter innenfor utvikling av programvare. Programmet gir oss muligheten til å lage et prosjekt på en.net-server, og jobbe med prosjektet samtidig. Man kan laste ned siste versjonen og laste opp endringene man har gjort på filer. Medlemmer av prosjektet må først registrere en Microsoft bruker og deretter bli invitert til TFS gruppen. Hvis flere personer har gjort endringer i filen samtidig må man "merge" filen og godta endringer. Dette har gjort det mulig for oss å jobbe tett og effektivt, og utvikle ulike funksjonalitet i samme prosjekt. 33

34 Prosessrapport I 2012 introduserte Mircosoft en oppdatert versjon av TFS med smidig planleggingsverktøy spesielt for Scrum. I 2013 ble disse verktøyene utvidet og inneholder funksjoner som "produkt backlogs", "Scrumboard", "user stories" og "burndown tabell". Skjermbilde 10: Team Foundation Server Microsoft Word Microsoft Word er et populært skriveprogram som mange anser som standarden for tekstbehandling og -formattering. Vi har benyttet oss av Microsoft Word for å formattere sluttrapporten før leveranse. Med Microsoft Word hadde vi mulighet til å tilføre bl.a. sidetall i innholdsfortegnelsen og kapittelnumre. 34

35 Prosessrapport Postman Postman er en kraftig HTTP-klient for å hjelpe med å teste web-tjenester. Postman lar deg lage enkle HTTP-forespørsler, som i vår i tilfelle er for REST-API. Dette blir brukt til å teste APIet vi har utviklet, for å hente data, lagre, slette og endre. Dette er en utvidelse i Chrome og kan bli installert fra Chrome Web Store. Skjermbilde 11: Postman i Chrome Ember Inspector Ember Inspector er et verktøy for "debugging" av Ember applikasjoner. Ember Inspector er en "plug-in" for Chrome, som et utviklerverktøy som brukes til å forstå hvordan Ember applikasjonen er satt opp. Vi bruker dette hyppig mens vi utvikler og er den eneste måten og debugge Ember applikasjonen på. Skjermbilde 12: Ember Inspector i Chrome 35

36 Prosessrapport Kompilator En kompilator er et dataprogram som gjør om kildekode som er skrevet i et programmeringsspråk til maskinkode. Dette er for å gjøre at programmet blir et kjørbart program på maskinen. En kompilator brukes som regel til å oversette kildekode til maskinkode, men den kan også utføre mange andre oppgaver. Blant annet kan den sjekke om det er riktig syntaks og optimalisering av koden. Skjermbilde 13: Hvordan en typisk kompilator opererer. 36

37 Prosessrapport Twitter bootstrap Bootstrap er en gratis samling av verktøy for å lage websider og webapplikasjoner. Den inneholder HTML og CSS-baserte designmaler for meny, skjemaer, knapper, navigasjon og andre grensesnittkomponenter, samt valgfrie Javascript-utvidelser. Skjermbilde 14: Twitter bootstrap Pluralsight Pluralsight er en online læring tjeneste for utviklere, Plurasight har et bibliotek med opplæringsvideoer som du kan abonnere på. Videoene er ordnet i kurs basert på et utvalg av programmerings relaterte emner. Hvert emne blir delt i en serie av korte video snutter. Snuttene er rundt 40 minutter til en time. Skjermbilde 15: Oversikt over hva Pluralsight dekker 37

38 Prosessrapport Stackoverflow Stackoverflow er et Q&A forum med et bredt spekter av emner innenfor data programmering. Nettstedet fungerer som et sted for brukere å spørre og få svar på spørsmål angående hovedsakelig en eller annen form for programmering. Gjennom medlemskap og aktiv deltakelse kan de tjene poeng. Ved å stemme på spørsmål og gi den poeng eller ikke, og redigere spørsmål og svare på en måte som ligner på en wiki. Skjermbilde 16: Stackoverflow Microsoft Azure Web Sites Er en cloud basert plattform for hosting av nettsteder. Den er opprettet og drives av Microsoft. Det er en plattform som tillater publisering av nettsteder som kjører på flere rammer og skrevet i forskjellige programmeringsspråk. F. eks NET, node.js, PHP. Skjermbilde 17: Microsoft Azure 38

39 Prosessrapport Localstorage Localstorage er en standardteknologi som gjør det mulig for et nettsted eller en applikasjon å lagre og hente frem data på en lokal datamaskin, mobiltelefon eller annen enhet. De fleste nettlesere har innstillinger som gjør det mulig å velge om du vil tillate lokal lagring. Tidligere ble dette gjort med cookies, men Localstorage er sikrere, raskere og har større lagringskapasitet. Dataene er ikke inkludert med hver server forespørsel, men KUN brukes når bedt om. Det er også mulig å lagre store mengder data, uten å påvirke nettstedets ytelse. Skjermbilde 18: Localstorage 39

40 Prosessrapport 15.2 Språk Javascript Javacsript er et veldig populært programmeringsspråk som er dynamisk skrevet og innehar nyttige funksjoner. Språket er oftest brukt som en del av nettlesere og er designet primært for å legge til interaktivitet til nettsider og lage web-applikasjoner AJAX "Asynchronous Javascript and XML" også kalt for AJAX er en teknikk for å lage raske og dynamiske websider. AJAX lar nettsider oppdatere asynkront ved å utveksle små mengder data med serveren i bakgrunnen. Dette betyr at det er mulig å oppdatere deler av en web-side uten å laste hele siden JQuery JQuery er et raskt og konsist bibliotek i Javascript, og formålet med JQuery er å gjøre det mye enklere å bruke Javascript på din nettside. Dette biblioteket er laget for å gjøre det lettere og navigere rundt, behandle hendelser og utvikle AJAX-applikasjoner HTML HTML er standard kodespråk som brukes til å lage websider. Nettleseren viser ikke HTML kodene, men leser HTML kodene og viser det frem. HTML beskriver strukturen av et nettsted noe som gjør det et kodespråk i stedet for et programmeringsspråk. HTML-elementer blir brukt for alle nettsider. Det kan også legge inn skript skrevet på språk som Javascript for å påvirker oppførselen til nettsiden. 40

41 Prosessrapport JSON JSON er en åpen standard format som bruker lesbar tekst til å overføre dataobjekter. Det er først og fremst brukt til å overføre data mellom en server og web-applikasjon. Opprinnelig stammer Json fra JavasScript, så den er språkuavhengig. Kode for parsing og generering av JSON-data er lett tilgjengelig i et stort utvalg av programmeringsspråk. Skjermbilde 19: JSON CSS Cascading Style Sheets (CSS) er en stil ark språk som brukes for å beskrive utseende og formatering av et dokument skrevet i et kodespråk. Som oftest brukt til og style nettsider og grensesnitt skrevet i HTML og XHTML. CSS er i hovedsak utviklet for og style på elementer som layout, farger og fonter. Dette kan gjøre innholdet mer tilgjengelighet, gir mer fleksibilitet og kontroll i spesifisering av presentasjonsegenskaper. 41

42 Prosessrapport SQL SQL er et spesielt programmeringsspråk designet for å håndtere data som holdes i en relasjonsdatabase. Men selv om all dataen er i en database, trenger vi noe vi kan bruke for å få informasjonen vi trenger. Til dette blir det brukt SQL, ved å bruke SQL har vi mulighet til å få ut valgte poster (select), endre poster(update), legge til poster(insert) eller slette poster(delete). Skjermbilde 20: SQL 15.3 Rammeverk og testing EmberJS Ember.js er en åpen kildekode klient-side Javascript webapplikasjon rammeverk basert på Model-View-Controller (MVC). Den lar utviklere lage skalerbare applikasjoner ved å legge til vanlige egenskaper og beste praksis i et rammeverk som gir det et rikt objekt modell, deklarative toveis databinding, beregnet egenskaper, automatisk-oppdatering maler ved bruk av Handlebars.js, og en ruter for håndtering av applikasjonstilstand. Skjermbilde 21: EmberJS 42

43 Prosessrapport Ember Canary Ember Canary er kanten av utviklingen i Ember. Canary builden inneholder funksjoner som enda ikke er tilgjengelig på release eller beta builden. Skjermbilde 22: EmberCanary build Odata OData er en standardisert protokoll for å skape tidskrevende data APIer. OData bygger på kjerne protokoller som HTTP og REST. Resultatet er en måte å eksponere dataene på API et på. OData gir full metadata av datakilden, med en metadata spørring er det mulig å se hele strukturen av de tilgjengelige dataene fra en gitt OData service, samt datatyper, forhold, osv. Odata lar deg i tillegg filtrere direkte på url. Odata er nytt og kom tidlig i Skjermbilde 23: OData 43

44 Prosessrapport FlotCharts FlotCharts er et javascript bibliotek for grafer og støtter alle diagramtyper. De tilgjengelige diagramtypene er linjediagram, sektordiagram, stolpediagram, områdekart og stablet diagram. Flot støtter også sann tid oppdatering av diagrammer og Ajax oppdatering av dem. Flot er et veldig nyttig verktøy for å lage grafer. Den bruker jquery og fungerer med Firefox 2 +, Internet Explorer 6 +, Opera og Konqueror 4 + og bruker HTML5 Canvas. Skjermbilde 24: FlotCharts 44

45 Prosessrapport Entityframework Entity Framework (EF) er et objektrelasjonsskisseprogram som gjør det mulig for NET utviklere å jobbe med relasjonsdata ved hjelp av domenespesifikke gjenstander. Det eliminerer behovet for det meste av data - tilgangskode som utviklere trenger vanligvis å skrive. Det er et sett av teknologier i ADO NET som støtter utviklingen av dataorienterte programmer. Entity Framework gjør det mulig for utviklere å arbeide med data i form av domenespesifikke objekter og egenskaper, for eksempel kunder og kundeadresser, uten å måtte bry seg med de underliggende databasetabeller og kolonner hvor dataene er lagret. Med Entity Framework, kan utviklere jobber på et høyere abstraksjonsnivå med data, og kan opprette og vedlikeholde dataorienterte applikasjoner med mindre kode enn i tradisjonelle applikasjoner. Skjermbilde 25: Entityframework 45

46 Prosessrapport RESTFUL API REST står for Representational State Transfer, den bruker fire HTTP metoder GET, POST, PUT og DELETE for å utføre ulike operasjoner. En REST API er et sett med operasjoner som kan brukes ved hjelp av fire verb, den bruker URI som parametere for operasjonene. For eksempel kan det brukes ved å ha en metode som spør om alle kundene som kalles for Kunder. En HTTP GET parameter forteller programmet at det skal returnere alle kunder Webgrease WebGrease optimaliserer en webapplikasjons filer som f. eks CSS, Javascript, og bildefiler. Funksjoner som den utfører er blant annet at den minimerer CSS og Javascript-filer, pakker alle filer til én utgangs fil, kombiner alle bildene det refereres til i en CSS-fil til en enkelt sprite, gi nytt navn til statiske filer basert på en hash av deres innhold. Dette verktøyet installeres automatisk med Visual Studio Testing Mocking Brukes primært i enhetstesting. Et objekt under test kan avhenge av andre objekter. For å isolere oppførselen til objektet vi ønsket å teste, erstatter vi de andre objektene ved mocks som simulerer oppførselen til de virkelige. Dette er nyttig hvis de virkelige objektene er upraktisk å bruke i enhetstesting. Kort sagt, er mocking å lage objekter som simulerer oppførselen til virkelige objekter. 46

47 Prosessrapport Dependency injection Depencency injection er en programvare design mønster der en eller flere avhengigheter er injisert. Mønsteret skiller mellom etablering av klienten sine avhengigheter fra sitt eget atferd, dette gjør at den blir løst koblet og følger dependency inversion og enkle prinsipper for samfunnsansvar. Dependency injection innbærer fire elementer: implementasjon av en service object, client objet avhengig av tjenesten, grensesnittet clienten bruker for å snakke med tjenesten og injisert objekt Moq Moq er et "mocking" rammeverk for C#/.NET. Den brukes i enhetstesting for å isolere klassen under test fra sine avhengigheter og sørge for at de riktige metodene på de avhengige objektene blir kalt. Vi bruker dette rammeverket til å teste våre klasser. 47

48 Prosessrapport 48

49 Prosessrapport 16. Om utviklingsprosessen I dette delkapittelet skal vi gjøre rede for hvilken utviklingsmetodikk som har blitt valgt. Videre skal vi beskrive de ulike fasene vi har vært gjennom i utviklingsprosessen, fra "serverside" til client-side og arbeidsmåten til gruppen. Prosjektet ble startet fra bunnen av og det ble utviklet både en server del og en klient del. Vi har derfor valgt å ha et delkapittel for hver i utdypningsfasen, som forklarer prosessen Utviklingsmetode Scrum Scrum er en smidig utviklingsmetodikk, som ofte brukes i større komplekse informasjonsteknologiprosjekter. Metodikken baserer seg på korte tidsintervaller (iterasjoner) og disse kalles sprinter. En sprint varer som regel fra to uker til fire uker(2 uker i vårt tilfelle), hvor spesifikke deler av prosjektet (kalt en delleveranse) blir ferdigstilt for hvert intervall. Når et prosjekt bruker Scrum er det som regel delt opp i en rekke enheter. En produkteier(i vårt tilfelle var det Tommy Kristoffersen) som produserer en product backlog kø som består av funksjoner og krav. Scrum-teamet som blir oss, har som mål å implementere disse kravene innen den gitte tidsfristen. I hvert Scrum-team er det en Scrum-master som er ansvarlig for at teamet organiserer seg og samspiller med produkteieren. I prosjektgruppen vår valgte vi Raheel Akhtar som Scrum-master. Når en sprint starter, forplikter teamet seg til å levere en del av produktkøen de tror de klarer. Dette blir plukket ut av produkteieren, som også setter mål for sprinten. Med tanke på produktkøen definerer teamet oppgavene som må fullføres for å nå målet innen tidsfristen. Dette kalles for en Sprint Backlog. I starten av hver arbeidsdag ble det avholdt et 5-10 minutter langt Scrum-møte, hvor hvert gruppemedlem informerte hva de har gjort siden sist arbeidsdag og avklarte dagens mål og arbeidsfordeling, dette møte kalte vi for en standup. 49

50 Prosessrapport Etter hver sprint blir det vist fram hva som er blitt gjort i løpet av sprinten i et såkalt review. Her pleier som regel produkteier og andre utviklere å være tilstede. Ofte var lederen for utviklingsavdeling tilstede, og i noen tilfeller var også Administrerende direktør for Syscom AS tilstede. På denne måten kunne vi få tilbakemeldinger i form av tips og konstruktiv kritikk av andre utviklere og interessenter. Etter endt sprint og sprint-review er det refleksjonsmøter der teamet kan komme med innspill på hva som har gått eller dårlig. Her evalueres prestasjonen i forhold til det som var forventet ved oppstarten av sprinten. Under møtet settes det opp fokuspunkter som teamet mener at de må være med observant på for neste sprint, og punktene blir satt opp synlig på tavlen/scrumboarden. Skjermbilde 26: Oversikt over sprintene Hvorfor vi utviklet i Scrum Scrum metodikken er brukt av Syscom AS sine utviklere. Syscom AS ønsket at vi skulle følge deres standard og retningslinjer innen utvikling, og ville derfor at vi skulle jobbe med smidig metodikk, og da med metodikken Scrum. Vi var godt kjent med Scrum fra før gjennom skolens studier og hadde derfor ikke noe imot å utdype oss innenfor denne metodikken. 50

51 Prosessrapport Scrum metodikken passet godt til utviklingen av løsningen, siden det var knyttet stor usikkerhet til hastigheten på utviklingen. Vi hadde ikke tidligere brukt SPA rammeverket EmberJS, og dette var nytt for alle gruppemedlemmer. Vi regnet med at mengden funksjoner og krav oppnådd per sprint ville øke lineært med forløpt tid. I tillegg kunne vi vise fram til ferdigstilt funksjonalitet, og se at prosjektet bli sakte men sikkert mer og mer ferdig. Dette ga bedre indikasjon på hvordan vi lå an for produkteieren Hvordan vi utviklet i Scrum For hver sprint som varte i to uker, valgte vi en eller flere backlogs som skulle utføres i denne sprinten. Det ble definert user stories hvor målet var å dele backloggen inn i mindre deler. En "user story" beskriver hvem som skal utføre oppgaven, hva som utføres og begrunnelse for hvorfor det gjøres. Ved å definere disse hadde vi en bedre oversikt over hva som skal lages og hvorfor. Hver user story ble lagt på Scrumtavlen. Skjermbilde 27: Sprint backlogs 51

52 Prosessrapport Skjermbilde 28: User stories og tasks Skjermbilde 29: Definisjon av done 52

53 Prosessrapport Vi hadde to ukers sprinter, der to av dagene i sprinten gikk bort til planlegging og reviews. Første dagen av sprinten går til planlegging av "user stories" som skulle være med, og siste dagen ble brukt til å vise fram og presentere hva vi hadde gjort for alle konsulenter og utviklere hos Syscom. Til slutt så hadde vi et refleksjonsmøte for oss selv der vi evaluerte hva som gikk bra eller dårlig i løpet av sprinten og hva som måtte forbedres. Når vi kom fram til hva som måtte forbedres ble det sett opp som fokuspunkter til neste sprint på tavla. Til slutt ville produkteier gi oss en tilbakemelding på hvordan han synes sprinten hadde gått. Skjermbilde 30: Fokuspunktene 16.2 Tilegning av kunnskap Ved prosjektstart var vi klar over at det var mange nye teknologier og områder vi trengte og forbedre våre kunnskaper på siden det var masse nytt. Backenden skulle bestå av et Rest-API og vi måtte benytte oss av Postman for å teste APIet. Disse to teknologiene var sentrale i utviklingen av den web-baserte løsningen. Derfor var det viktig å vite hva hensikten med å utvikle et Rest-Api, forstå hva det brukes til og hvordan det fungerte. Vi startet først med å bruke Pluralsight til å lære oss om REST-API. Pluralsight er en læringsportal som Syscom benytter seg av, og har vært en viktig kilde til hvordan vi har utviklet Rest-API. For Postman fikk vi gjennomgang av veilederen vår. 53

54 Prosessrapport For klient-delen ble det lagt stor vekt på Javascript, et språk vi ikke hadde brukt mye på skolen. En av oss hadde noe erfaring med Javascript, men ikke fra et prosjekt i denne størrelsen. Vi ble fortalt at dette var et språk som blir mer og mer brukt i arbeidslivet for å lage dynamiske nettsider. Videre har vi benyttet oss av SPA - rammeverket EmberJS, som vi ikke hadde en gang hørt om. EmberJS ble brukt til å lage web applikasjoner på en enkelt HTML-side, slik alt lastingen av nettsiden ble kjørt ved første gang. Selv om vi ikke kjente til EmberJS, var det noe vi ville absolutt lære. Utover dette var det nye språk, rammeverk, biblioteker, regler vi måtte samle informasjon om før vi kunne starte for fullt. Det ble brukt en god del av tiden til tilegning seg av kunnskap Faser Utviklingsmodellen som vi har valgt er inndelt i fire faser: idéfase, utdypningsfase, konstruksjonsfase og overgangsfase. I dette delkapittelet vil det gi en beskrivelse av hvilke aktiviteter disse fasene bestod av og arbeidsmåten til prosjektgruppen i de ulike fasene Idéfase I idéfasen fokuseres det på omfanget av prosjektet. Det ble utarbeidet en målsetting, fremdriftsplan og utkast til modeller Prosjektstart I prosjektstart-stadiet satt vi sammen og diskuterte prosjektoppgavene som hadde kommet inn til høyskolen. Vi kom fram til at ingen av de innsendte oppgavene var så interessante for oss fordi vi ønsket å jobbe med web-utvikling og C#/.NET. Vi tok derfor saken i egne hender og begynte å søke direkte til bedrifter vi visste jobbet med dette. Vi fikk tilbud både fra Syscom AS og Epinova AS, men til slutt falt valget på Syscom AS. 54

55 Prosessrapport Det ble avtalt et møte med Syscom AS, der vi ble møtt av Syscoms HR, Trine Andersen, adm dir. Pål Nome og en av utviklerne hos Syscom, Tommy Kristoffersen, som ble vår kontaktperson. Ved første intervju vurderte Syscom AS om vi var faglig flink nok til å kunne jobbe med C#/.NET. På den tiden hadde de ikke en ferdiglagd prosjektbeskrivelse, siden de ville se om vi kunne klare å fullføre et eventuelt prosjekt. Vi ble bedt om å vise fram tidligere prosjekter, og da spesielt i C#/.NET. Ved andre intervju gikk vi gjennom prosjektbeskrivelsen, og hva som var forventet av prosjektgruppen. Prosjektbeskrivelsen bestod allerede av flere krav som de ville at løsningen skulle oppfylle. Syscom AS presenterte en veldig utfordrende og interessant oppgave som gruppen gikk gjennom før vi bestemte oss for å takke ja til dette oppdraget. I utviklingen har vi tatt hensyn til to ulike målgrupper. Det er først og fremst utviklere ved Syscom som vil ta i bruk web-baserte løsningen vi har utviklet. De kreves selvfølgelig en robust og oversiktlig løsning med bruk av riktige verktøy og teknologier. Web-baserte løsningen er dessuten utviklet i henhold til krav og ønsker fra produkteieren, som er en utvikler ved bedriften. Når det gjelder brukerne av nettsiden, kan dette være ansatte i Syscom, i ulike aldersgrupper og avdelinger. Vi har gjort det mulig for brukere å konfigurere forsiden på nettsiden etter deres ønske, ved bruk av localstorage Forprosjekt Etter at oppgaven ble godkjent av veileder ved høyskolen begynte vi og Syscoms veileder, Tommy Kristoffersen å planlegge hvordan vi skulle gå frem for å løse den. Det ble avtalt flere møter med oppdragsgiver hvor vi diskuterte problemområdet. Det ble i tillegg foretatt vurdering av hvilke tekniske løsninger og verktøy som skulle tas i bruk. I samarbeid med vår veileder ble det bestemt hvilke teknologier og verktøy som skulle benyttes, samt hvilke rammer og betingelser som gjelder for løsningen. I tillegg til vurderinger rettet til tekniske løsninger, måtte vi ta stilling til ulike valg. Vi ga også forslag til forbedringer og endringer til veilederen. 55

56 Prosessrapport Utdypningsfase I utdypningsfasen har vi hatt flere diskusjoner med oppdragsgiver angående krav, design, programmets oppbygning, databasestruktur, mappestruktur og funksjonalitet. Analyse av krav og systemarkitektur står sentralt i denne fasen. Implementering var også en viktig del av denne fasen. I utdypningsfasen ble det bestemt sammen med produkteier hvordan server-delen skulle utvikles. Vi har derfor designet en database som skal lagre data som blir sendt fra kundene til Syscom AS og tilby dataene i et REST API, og presentere dataene. Kravene som vi fulgte var: Feilhåndtering Når en feil oppstår i de forskjellige produktene blir feilen(error / Exception) lagret i denne tjenesten. Parametere inn er melding, hvilken klasse som hadde feilen, kodelinje feilen skjedde på, hele callstacken etc. Disse blir lagret i databasen, og det blir vist på nettsiden hvilken feil som skjer oftest, hvilket produkt har flest feil, en oversikt over alle feil, hvilken versjon som feiler mest. Dette blir presentert i forskjellige former(grafer og tabeller). Brukerstatistikk Det skal kunne sendes inn forskjellige parametere som hvilken knapp som er trykket på, hvilken url man går til, hvilken browser som blir brukt osv. fra produktene. Disse blir lagret og presentert i forskjellige former(grafer og tabeller). Kundeoversikt Det skal være oversikt over alle kundene hos Syscom. Det ønskes å rapporteres lisensinformasjon, hvor mange saker en kunde har opprettet, hvor mange agenter som bruker systemet etc. Dette skal også presenteres. 56

57 Prosessrapport Dette er de tre hovedpunktene som hadde høyest prioritert for at programvarekravene skulle oppfylles. Programvarekravene ble utarbeidet av vår oppdragsgiver Syscom, og vil bli nærmere beskrevet i produktrapporten. Skjermbilde 31: ER-modell I denne fasen fulgte vi kravene og lagde en skisse til databasestrukturen, vi bygget videre på denne strukturen underveis i prosjektet. Server delen ble utviklet i MVC-arkiktetur, og model er delt i Data Access Layer, Business Logic Layer og Domain. Domain lagdelen ble brukt til DTO(Data Transfer Object) objekter for å overføre data fra Data Access Layer til Web. I MVC- arkitekturen, vil ikke Web ha tilgang til Data Access Layer, og derfor er det nødvendig med Domain lagdel. For å kunne overføre data på den mest effektive og raskeste måten, benyttet vi av rammeverket "Automapper". Dette gjorde at vi kunne enkelt legge til nye modeller og ta i bruk, uten store modifikasjoner på systemet. Videre har vi en test lagdel som blir brukt til testing av uavhengige metoder, som vi bli forklart i kapittel 20 om mocking. 57

58 Prosessrapport Skjermbilde 32: Relasjon mellom BLL, DAL, Web og Domain Før vi startet med å utvikle i Data Access Layer, ble det brukt tid på å finne ut så mye som mulig om hva en "error/exception" inneholder. Vi kom fram til at det var mulig å få tak i "error" meldingen, filen den oppstår på, linjenummer, applikasjons navn(f. eks Visual Studio), hvilken nettleser og versjon det ble brukt, og callstacken. For å fange opp disse feilene internt i systemet vi utviklet tok vi i bruk "UnhandledExceptionsFilter", som vi bli grundig forklart i produktrapporten. Videre ble det gjort "research" på hvilke attributter som var nødvendig for brukerstatistikk og kundeoversikt tabellene. Disse ble lagret i databasen, ved bruk av en generisk "repository" klasse. Repository er en generisk utviklet klasse som ikke trenger å tenke på hva slags objekter som skal bli lagret. Under utviklingen av databasen kom vi fram til at vi trengte en funksjonalitet til å fikse "error/exception" som oppstår. Det ble derfor opprettet en ny "user story" av vår oppdragsgiver. Databasen er designet etter tredje normalform for å oppnå en mer oversiktlig datastruktur og for å sikre at det ikke oppstår inkonsistens i databasen. Det ble benyttet rammeverket EntityFramework, Code-First Migration til å utvikle databasen. 58

59 Prosessrapport Skjermbilde 33: En liten bit av det generiske repositoryen 59

60 Prosessrapport For å kunne kommunisere effektiv med REST-tjeneren, var det viktig å ha en standardisert måte å kontakte den. En viktig del av kravene som oppdragsgiver ønsket var at henting av data fra databasen skulle forenkles, enten ved å ha metoder med mer dynamiske parametere for SQL-spørringer, eller et rammeverk for å behandle denne kommunikasjonen. RESTtjeneren vår tilbyr HTTP-tjenester både over GET-, PUT, DELETE og POST- metodene, og vi måtte derfor implementere generell funksjonalitet for alle mulighetene. Som nevnt startet vi først med å utvikle en struktur bestående av Data Access Layer, Business Logic Layer og Domain, men fant rask ut, i samarbeid med produkteieren vår at det var mer hensiktsmessig å benytte oss av et rammeverk, kalt OData. Vår API ble utviklet i API-Controllere men for å benytte oss av OData måtte dette endres til OData-Controllere. Med Odata-Controllere kunne database spørringer skje direkte på URL, og dette var en veldig stor fordel, slik at vi slapp å modifisere nye metoder når vi la til nye tabeller. En spørring kan se slik ut: eq 'Purehub' Og vil gi resultatet: Skjermbilde 34: Illustrasjon av hvordan en spørring ser ut I dette tilfellet er det blitt filtrert etter alle "User" som er lik "Purehub". 60

61 Prosessrapport Faglige utfordringer Det er vanlig å møte på tekniske og faglige utfordringer i alle prosjektoppgaver av en viss vanskelighetsgrad. Blant utfordringene vi har møtt på har de fleste vært av høyere faglig nivå og vært ganske tidsbegrenset. Vi har som regel klart å løse utfordringene på en måte vi føler ga best resultater, uten at det har påvirket kravet til oppgaven og sluttproduktet. Dette er vist fra tilbakemeldingene vi har fått fra produkteier (Se kap. 10.4). Utfordringer som vi møtte på i begynnelsen av prosjektet var blant annet at oppdragsgiver ønsket at løsningen skulle utvikles ved hjelp av teknologier som vi ikke var så kjent med på det tidspunktet. Det har vært vanskelig og krevende å gjøre oss kjent med hva slags muligheter disse teknologiene kunne gi oss. Kunnskaper innen andre utviklingsspråk og teknologier har vært grunnlaget for læringsprosessen. Primærmålet med oppgaven var å lage et system som hadde oversikt over feillogging, brukerstatistikk og kundeoversikt. I forhold til tradisjonelle oppgaver som kun resulterer i en web-applikasjon som sluttprodukt, var implementering i vårt prosjekt delt i to steg; backend og frontend. I dette kapittelet skal vi gjøre rede for de valgene vi har tatt vedrørende de alternative teknologiene som var aktuelle for oppgaven vår. Kapittelet inneholder en vurdering av disse teknologiene. Videre vil vi beskrive valgene vi har tatt underveis i utviklingsprosessen, relatert til rammeverket og hvilke løsninger vi har implementert. Til slutt i kapittelet vil vi beskrive valg relatert til brukergrensesnittet. 61

62 Prosessrapport Valg og vurdering av teknologier Rammebetingelsene for oppgaven var i stor grad bestemt av oppdragsgiver når de presenterte oppgaven for oss. Vi fikk imidlertid beskjed om å gjøre en vurdering av hva som var mest aktuelt for oppgaven. Rammeverket vi skulle ta for oss var EmberJS (Se kap. 8.14), og det skulle ha en standard API-grensesnitt. Derfor måtte vi tenke over at layout og menyene skulle være intuitivt og enkelt å bruke. Vi har valgt å gi applikasjonen et enkelt og standardisert design med Twitter bootstrap. Oppdragsgiver ønsket at vi skulle velge farger og logo selv, vi bestemte oss for å gå for Syscoms PureService sine farger for at det skulle samstemme med tanke på at PureHub er en del av PureService. I applikasjonen var det mye data som skulle vises frem, derfor var det viktig å ta hensyn til design og layout slik at dataene ble presentert så ryddig og oversiktlig som mulig. Fokuset på grensesnittet vårt var at det skulle være intuitivt og lett å forstå. Vi valgte å plassere menyknappene Home, Errors, Usages og Customers øverst til venstre. Disse vil alltid være synlig uansett hvor du er på siden. På startsiden ser du tabeller som er standard for alle som laster inn PureHub for første gang, brukeren skal ha muligheten å konfigurere det som skal vises på forsiden selv. Det er mulig for brukeren å tilpasse hva som skal vises av tabeller og grafer og disse lagres på localstoragen, så neste gang man laster inn PureHub vil det fortsatt være slik som da man lukket den. I utgangspunktet ble vi bedt om å utvikle applikasjonen hovedsakelig gjennom EmberJS. Dette innebar at den skulle være en kombinasjon mellom HTML5/CSS/Javascript/Jquery og EmberJS. På denne måten har websiden oppredt dynamisk og lasting av all nødvendig kode skjer ved en enkel page load. Utformingen av webinnholdet ble strukturert på en MVC-måte, for å sikre enkel lesbarhet av koden. Views, kontrollere, modeller og rutere som er standard oppsett for EmberJS. Disse hadde hver sitt rolle og ble alle laget som egne filer. 62

63 Prosessrapport Vi hadde en mappe med komponenter, der vi la inn komponenter som ofte blir gjenbrukt. Grunnen til dette var at det var mye mer oversiktlig og EmberJS støttet bruk av komponenter på denne måten. Javascript kan brukes som et objektorientert språk hvis visse retningslinjer blir fulgt. Alle klasser, funksjoner og variable ble innkapslet i pakker - namespaces - for og både strukturere koden, og lage objekter som både kunne opprettes, endres, presenteres og slettes. Senere da vi hadde fått inn all dataene og listet det ut på en fin måte, trengte vi nå et rammeverk for å vise det frem med forskjellige grafer. Her fikk vi selv bruke tiden på å finne frem et rammeverk vi ønsket å bruke. Vi kom fram til to som vi skulle velge mellom, FlotCharts vs HighCharts. Til slutt bestemte vi oss for å gå for FlotCharts siden den var gratis. Grafene vi hadde bruk for i dette rammeverket var et sektordiagram for å gruppere og vise frem feil i systemet, og vanlig linjegraf som viser antall nye feil over tid. Under utviklingen brukte vi Google Chrome, denne nettleseren tar høyde for mange av W3Cs standarder og derfor lett å jobbe med. Selv om vi ikke trengte å lage dette kompatibel med andre nettlesere valgte vi å gjøre det. Grunnen til dette er for videreutvikling og drift av PureHub. Selve webinnholdet er skrevet, strukturert og kodet til HTML5-standarden. Denne standarden gir tilgang til en rekke strukturelle elementer som gjør den kompatibel for andre og fremtidige nettlesere. Alt av farger på design ble gjort gjennom et CSS3-basert stil ark, og ble gjennomgående sjekket om det passet for nettleseren. For å optimalisere det, ble det lagt fokus på å lage gjenbrukbare stiler, noe som ble brukt flere ganger gjennom siden Konstruksjonsfase Konstruksjonsfasen var den største og mest tidskrevende fasen. I konstruksjonsfasen jobbet vi hovedsakelig med utvikling av web-baserte løsningen, men også en del med databasen og detaljering av modellene. Fasen bestod av 8 sprinter og hver sprint resulterte i en delleveranse. Ettersom utviklings tok utgangspunkt i teknologier som vi var lite kjent med, møtte vi en del faglige utfordringer, disse utfordringene er beskrevet i delkapittel om "Faglige utfordringer". Det ble tidlig bestemt at vi skulle bruke TFS(Team Foundation Server) til deling av kode, etter krav fra Syscom AS. Vi alle var kjent med hvordan vi skulle benytte oss av TFS fra før 63

64 Prosessrapport og hadde derfor ingen vanskeligheter. I tillegg var det en stor fordel å bruke det fordi det ga oss versjonskontroll og det fungerer utrolig bra. I henhold til utviklingen jobbet vi hovedsakelig på Syscom AS sin utviklingsavdeling. Vi har derfor kunnet jobbet tett sammen og hatt oversikt over utviklingen av task hvert gruppemedlem har valgt. Det ble også benyttet ved visse tilfeller par-programmering, som har fungert veldig bra. Vi har jobbet etter en iterativ metode og arbeidet har blitt utført innenfor tidsrammen. I hver sprint skal "taskene" gjennomføres innenfor en gitt tidsramme. En tidsramme er antall timer en task krever. Tidsrammen blir bestemt under planleggingen av sprinten sammen med veilederen vår. Det kan være fra 2 til 20 timer etter hvor lang tid vi tror det kommer til å ta. Ved visse tilfeller har vi klart å utføre oppgaven mye fortere enn forventet, slik at vi kan ta inn flere "task". Siste dag av sprinten ble det brukt til å vise fram og presentere hva vi har fått til for Syscom og andre utviklere. Fremgangen ble diskutert, og vi fikk konstruktive tilbakemeldinger som har vært veldig nyttig til videre utvikling. Til slutt hadde vi refleksjonsmøte for oss og evaluerte hva som var bra og dårlig i sprinten. Når vi kom fram til hva som må forbedres satt vi opp fokuspunkter som vi skulle følge. Produkteier vil etter det sende oss mail på hvordan han syntes dette har gått Overgangsfase Ved slutten av konstruksjonsfasen var vi stort sett ferdig med en stor del av utviklingen. Overgangsfasen ble brukt til å ferdigstille produktet. Mye av tiden ble brukt til feilhåndtering og brukertesting. Kildekoden og produktet har nå blitt levert til Syscom gjennom TFS. Denne fasen ble også brukt til å sette sammen og ferdigstille dokumentasjonen, og det er beskrevet i delkapittel , Dokumentasjonsfasen. 64

65 Prosessrapport Brukergrensesnitt og designvalg Designe en web-basert EmberJS løsning for API var nytt for oss alle, vi var klar over at det ville bli en stor, men ikke minst en spennende utfordring. I tillegg visste vi fra før at det var viktig å tenke på skjermstørrelsen, siden brukere har ulike oppløsninger på dataskjermen de bruker. Siden vi ikke hadde jobbet med utvikling av en API nettside, hentet vi inspirasjon fra ulike nettsider som tilbyr API som Facebook, Youtube, Twitter og andre lignende. Utformingen av webinnholdet ble strukturert på en objektorientert MVC-måte, for å sikre enkel lesbarhet i ettertid. Som tidligere forklart er rammeverket basert på MVC. Views, kontrollere og modeller ble alle lagret som egne filer, og benyttet på templates. Videre er det kodet til HTML5-standarden. Denne standarden gir tilgang til en rekke strukturelle elementer som både gjør applikasjonen mer tilgjengelig, men høyner også kompatibilitet for fremtidige nettlesere. All stilsetting ble gjort gjennom et sentralt CSS3 - basert sheet, og vi benyttet oss av "frontend" rammeverket twitter bootstrap. Vi la vekt på at designet skulle være lett og brukervennlig for alle typer brukere, og spesielt for utviklere hos Syscom. Noe av det mest vesentlige i em design er fargene, disse må være behagelig for brukere slik at det ikke forekommer irritasjon. Vi ble enige om at vi måtte ha en hovedmeny som inneholdt navigasjonsmuligheter til hvert enkelt hoved emne som feil, bruksstatistikk og kunder. Vi produserte skisser av ideene vi hadde om hva som skulle være på disse enkeltsidene i applikasjonen, ved bruk av verktøyet Balsamiq. 65

66 Prosessrapport Skjermbilde 35: Balsamiq mockups Skjermbilde over viser en standard forside vi ønsket å designe, og samtidig er det åpent for muligheter til å konfigureres. Vi ønsket at brukere skal kunne designe sin egen forside og har derfor lagt til en knapp som heter "Configure", og mulighet til å fjerne tabeller fra forsiden. Brukere vil kunne legge til nye tabeller som er filtrert etter deres ønske og dette vil bli lagret på PC-en, ved bruk av teknologien LocalStorage. LocalStorage er en måte til å lagre store data på brukerens pc som ble forklart i kapittel

67 Prosessrapport Dokumentasjonsfasen Vi valgte å benytte oss av verktøyet Microsoft Word til skriving av alle dokumentasjon, siden alle var kjent med dette verktøyet og hadde det tilgjengelig. Som utgangspunkt for skriving av dokumentasjon gikk vi gjennom dokumentasjonsstandarden utarbeidet av førstelektor Ann Mari Torvatn for hovedprosjekter ved HIOA, for å få tips til hvordan man skal forme dokumentasjonen. Andre rapporter fra tidligere grupper ble også gjennomgått. I tillegg fikk vi nyttige råd fra vår interne veileder Kirsten Ribu. Før vi startet ble det diskutert hvilke oppsett og tilpasning til struktur i dokumentene vi skulle ha. Vi har kommet fram til en som passer veldig godt til vår oppgave. Vi har delt inn i mange kapitler og underkapitler slik at leseren enkelt kan navigere,ved å bruke hyperlinker og referanser til andre kapitler. Dette gjør at rapporten blir enklere og mer lesbar. Bilde er forklart i billedtekster so å beskrive hva bildene illustrerer. Dokumentasjonen er delt inn i hoveddeler som samlet representerer sluttdokumentasjon. Presentasjon- en introduksjon til gruppen, oppdragsgiver og prosjektet. Prosessrapport - beskriver utviklingsprosessen. Produktrapport - beskriver produktet vi har utviklet. Testrapport - beskrivelse av tester utført på produktet. Brukerveiledning - en veiledning for hvordan produktet skal utvikles. 67

68 Prosessrapport 17. Avsluttende del 17.1 Det ferdige produktet Produktet vi har laget brukes i dag av kunden. Etter brukertest har vi fått mange gode tilbakemeldinger, og kunden er fornøyd. Det finnes forbedringsmuligheter, og løsningen kan videreutvikles, men alle krav som ble satt er oppnådd Utbytte for oppdragsgiver Syscom får stadig nye kunder, og må holde oversikt over disse. Ved at oppdragsgiver tar i bruk produktet vi har utviklet vil de få en god oversikt over disse kundene. Produktet gjør det mulig for dem å holde oversikt over produktene deres. Løsningen får inn informasjon fra alle produktene, samler disse og presenterer dataene på en god måte. Løsningen viser også feil som oppstår i de forskjellige instansene av PureService Læringsutbytte Gjennom prosjektet har vi fått mye erfaring i prosjektplanlegging og styring. Oppgaven har gitt oss erfaring med hvordan det er å jobbe i team og for en oppdragsgiver. Dette var nytt for de fleste av oss, men det har vært et lærerikt samarbeid med en stor bedrift. Her fikk vi lære deres arbeidsmetoder, øke vår forståelse og erfaring innen programmering, dokumentering og bruk av forskjellige verktøy. For oss har vi fått igjen et stort faglig utbytte og fått en dyp innsikt i hvordan det er å jobbe i forskjellige fagområder. Under utviklingen har vi mestret og lært oss en god del teknologier som var helt nytt for oss. Utviklingen av et Hub har vært veldig givende for oss, og vi ser nytten i det for Syscom. Ettersom dette vil forenkle og samle alt av viktig informasjon på et sted. 68

69 Prosessrapport 17.4 Tilbakemelding fra oppdragsgiver Gjennom prosjektets løp fikk vi kontinuerlig tilbakemelding fra oppdragsgiver. Oppdragsgiver har i tillegg vært veldig fornøyd med arbeidet vi har gjort, og vi har klart å oppfylle krav fra kravspesifikasjonen og har fått god tilbakemelding på sluttproduktet. Noen ord fra produkteieren på en av sprintene: Teamet jobber veldig raskt og har nå fått god kontroll på applikasjonen og utvikler ved en veldig høy hastighet. Utviklere til pureservice skal nå ta i bruk PureHub ila den følgende sprinten for å få sendt inn reell data til PureHub Videreutvikling og vedlikehold Utvidelser og videreutvikling av prosjektet har to forskjellige aspekter: kontinuerlig oppdatering av rammeverket å utvide prosjektet. Siden vi bruker EmberJS Canary build og ODATA som er i betafasen som stadig utvikles bør denne oppdateres ofte. Siden vi bruker EmberJS rammeverket, gir den oss en oversiktlig mappestruktur som gjør at det er enkelt å legge til nye komponenter og funksjoner uten å gjøre store endringer i den opprinnelige koden. Hvordan dette gjøres blir nærmere beskrevet i produktrapporten Konklusjon Under hele skolegangen er dette det største prosjektet vi har vært med på, det har vært lærerikt, spennende og tidskrevende. Underveis måtte vi ta viktige valg som påvirket hvordan sluttproduktet ble. Vi føler at vi har tatt riktige valg og er fornøyd med sluttproduktet vi utviklet. Læringskurven har vært veldig bratt, siden teknologien som ble tatt i bruk var ganske nytt for oss. Vi hadde noe bakgrunnskunnskap som hjalp oss slik at læringsprosessen gikk ganske greit. Dette var spennende og utfordrende for hver enkel av oss, og vi føler at vi har kommet 69

70 Prosessrapport godt ut av det. Vi har vært så heldige at vi har fått lært mye relevant og forståelse av nye teknologier. Prosjektet har gitt oss en god innsikt i hvordan det er å jobbe i et større prosjekt for å komme seg i mål, og hvor viktig det er å sette opp planer, krav og frister. Gjennom prosjektets løp har vi hatt et godt samarbeid med nesten ingen uenigheter, og kommet i mål. Samarbeidet med veilederen hos HiOA og Syscom har vært veldig bra, vi har alltid fått gode og raske tilbakemeldinger. Begge var veldig tilgjengelig på mail til enhver tid. Dette har vært til stor hjelp gjennom prosjektet, og nå er vi mål med erfaring og et produkt vi er stolte av. 70

71 Produktrapport PRODUKTRAPPORT HiOA - Fakultet for teknologi, kunst og design (TKD) Kull

72 Produktrapport 72

73 Produktrapport 18. Forord Det forutsettes at leseren av dette dokumentet har lest og gjort seg kjent med presentasjonsdokumentet og prosessdokumentet. Under denne forutsetning kan dette dokumentet leses selvstendig. Denne oppbygningen har vi for å gi et bedre innblikk i hva vår oppgave går ut på, informasjon om gruppen og oppdragsgiver med mer. 19. Innledning I denne rapporten presenterer vi produktet vi har hatt som oppgave å utvikle. Det består av en server side rest api og en klient side single page application. Rapporten består av en grundig beskrivelse av produktet, hvordan det er bygget opp, hvilke teknologier og rammeverk som er brukt og hvorfor det er brukt. Videre er det også beskrevet hvem som skal benytte seg av produktet og hvilke krav som stilles til systemet. 20. Bakgrunn for oppgaven Hensikten med produktet er å kunne loggføre javascript-errors og.net-exceptions i en database, og kunne presentere den loggførte dataen på en oversiktlig og brukervennlig måte. Det å kunne filtrere mot databasen er en grunnleggende funksjon for produktet slik at brukeren av systemet skal kunne stille krav til dataen som blir presentert. Som det er beskrevet innledningsvis er systemet to-delt, en databaseløsning som tar hånd om data i form av et REST API, og en frontend løsning som viser dataen. Denne løsningen vil bli brukt av Syscom ASs utviklere. De vil få en felles portal med alle feil som systemene deres har og alle utviklere vil ha tilgang til denne portalen. Planen er at denne applikasjon alltid vil være kjørende på en storskjerm midt i utviklingslokalet der utviklerne enkelt kan få en oversikt over feil som må rettes på. I tillegg til oversikt over feil skal det også være en oversikt over kundene til Syscom, deres brukerstatistikker og generell informasjon som lisensinformasjon. 73

74 Produktrapport 21. Kodespråk og prinsipper angående syntaks 21.1 Prinsipper Vi har valgt å følge noen prinsipper for å få et system som er enkelt å vedlikeholde og utvikle over tid. Ved å følge disse prinsippene har vi fått et system som er smidig, fleksibelt, gjenbrukbart(generisk), enkelt å opprettholde og enkelt for en ekstern person å sette seg inn i SOLID Prinsippene vi har fulgt kan forkortes til SOLID som står for SRP(Single responsibility), OCP(Open/close principle), LSP(Liskov substitution principle), ISP(Interface segregation principle) og DIP(Dependency inversion principle). SRP fokuserer på at alle klasser i programmet kun skal ha ansvar for en oppgave og den oppgaven kun skal beregnes til den ene klassen. Som et eksempel på implementasjonen av dette prinsippet har vi en klasse ved navn filter. Denne filterklassens har som oppgave å behandle krav til informasjon brukeren vil ha og bearbeide det om til et sql kall. Brukeren kan filtrere på kunder i systemet eller feil i systemet, men filterklassen er uavhengig av hva kunden vil ha filtrert. (Se kapittel i produktrapporten) OCP stadfester at klasser, moduler og funksjoner skal være åpne for utvidelser men lukket for modifikasjoner. Det vil si at klasser, moduler og funksjoner skal kunne utvikles videre uten at store endringer i opprinnelig kode må foretas. Dette er nødvendig ved for eksempel enhetstesting. Et eksempel på dette i vårt produkt er controller-klassene på APIet. Ved et POST-kall krever controlleren hele objektet som skal legges til i databasen og ikke hvert eneste attributt. Slik kan et ekstra attributt legges til dette objektet i databasen uten at controlleren må endres. LSP går ut på at en klasse som utvider en annen klasse(extender) skal kunne erstatte klassen den utvider. Dette er grunnleggende for alle klassebiblioteker. For hver gang man utvider en klasse så arver man alle metodene og attributtene til klassen man utvider. For eksempel inneholder javascript arrayene objekter som extender Ember.Object. 74

75 Produktrapport ISP vil si at en klasse ikke skal implementere metoder den ikke bruker. Dette har vi ikke hatt bruk for i vårt system siden det ikke er noen subklasser i systemet. Et eksempel på bruk av dette kunne vært hvis vi hadde delt ErrorLog klassen inn i to subklasser. Da ville vi hatt et interface ved navn ErrorLog og to subklasser Error og Exception. En Exception-klasse har flere attributter enn en Error-klasse, derfor trenger den ikke å implementere alle attributter fra ErrorLog-interfacet. ErrorLog-interfacet kan derfor deles inn i to interface der Exceptionklassen implementerer begge interfacene og Error-klassen implementerer kun det ene interfacet med de nødvendige attributtene. (Dette er kun et eksempel). Det er vanlig å programmere fra bunnen av klassehierarkiet og oppover noe som lett kan føre til at de øvrige klassene er avhengige av underklassene. Eksempel på denne avhengigheten kan være at en overordnet klasse skal håndtere underliggende objekter i klassehierarkiet, hvis underklassene endres må klassen over også endres. DIP går ut på at denne tankegangen inverteres slik at den overordnede klasser ikke trenger å ta hensyn til om underliggende klassen kan endres. Eksempel på dette prinsippet i vårt system er HubRepository-klassen. Denne klassen inneholder generiske objekter, slik er manipulasjon av underordnende klasser enkelt. (Se kapittel i prosessrapporten) Skjermbilde 36: SOLID prinsippene 75

76 Produktrapport DRY Prinsippet DRY er en forkortelse for «dont repeat yourself» og vil rett og slett si at repetering av kode må begrenses så mye som mulig. Dette er essensielt i objekt orientert programmering og gir oss et system som er gjenbrukbart og enkelt å vedlikeholde. Dette prinsippet går igjen i SOLID prinsippet som er forklart tidligere i rapporten. Eksempel på dette prinsippet finner vi i filterobjektet. Det blir sendt sql-kall til databasen flere ganger i systemer, men før kallet kan gjøres må det genereres. Denne genereringen er flyttet til et filterobjekt som blir gjenbrukt flere steder i systemet Språk Programmeringsspråket vi bruker på serversiden er Microsoft egenutviklede C# som er basert på C++ og Java. Det er et robust objektorientert språk som er designet for Microsofts.Net plattform. Verktøyet som er blir benyttet er Microsoft Visual Studio som er beskrevet i prosessrapporten. Brukergrensesnittet er også utviklet i Microsoft Visual Studio, men her er flere programmeringsspråk tatt i bruk som html, css, javascript, json, ajax og jquery. Html er brukt for selve skjelettet til applikasjonen i mens css blir brukt til designen og formatteringen av html elementene. Javascript blir brukt til alt annet som databehandling, navigering og brukerinteraksjoner. JSON blir brukt i forbindelse med konvertering av xml data og konvertering av data fra databasen og konvertering fra objekter til string og omvendt. Ajax og jquery er benyttet i forbindelse med lagring til databaser og andre manipuleringer av brukergrensesnitt som er beskrevet senere i rapporten. Nærmere beskrivelse av disse programmeringsspråkene er gitt i prosessrapportens kapittel

77 Produktrapport 22. Struktur I dette kapittelet kommer det en beskrivelse av datamodellene, strukturen i både koden og selve klassene og designet av koden. Siden løsningen vår er todelt med en frontend og en backend vil vi ta hensyn til dette i rapporten og dele kapittelet i to deler der vi tar for oss backend-delen først så frontend-delen. Dette har vi gjort for å gi en bedre oversikt og en mer forståelig rapport Backend Backenden består av en database som inneholder all dataen og et REST API med ODatacontrollere. I tillegg til databasen og APIet har vi et et Exception-filter som fanger opp og loggfører feil som oppstår internt i systemet. Slik får vi et MVC mønster der controllere ser databasen og fungere som en kanal mellom viewet og modellen/databasen. I løsningen vår er viewet programmert i javascript rammeverket EmberJs som er beskrevet senere i produktrapporten Server Vi har brukt Microsoft Azure som er en skylagrings plattform utviklet av Microsoft. Det at det er en sky vil si at den ikke er avhengig av noen lokal server, men en ekstern via internett. 77

78 Produktrapport 22.3 Databasen Databasen er satt opp med code first i.net sitt «Entity Framework»-rammeverk. Code First er en spesiell tilnærming til oppretting av databasestrukturer der man koder klasser og oppgir relasjonen ved å oppgi virtual objekter. Slik trenger man ikke å sende SQL-spørringer til databasen. Systemet skal kun håndtere brukerstatistikk, error/exceptions og kundedata, vi trenger altså ikke en altfor avansert database. Eneste som er felles i systemet er informasjon om kundene som brukerstatistikken hører til og kundedataene i systemet. Dette har vi løst ved å lage en egen klasse for kunder og en egen klasse for kundedataen. Videre har kundedataen fjernnøkkel til kunden og det samme har brukerstatistikken. Skjermbilde 37: ER modell med attributter Som vist i illustrasjonen er det mulig å registrere om en feil har blitt fikset i form av en relasjon til «FixedErrorReport»-klasse. Det er en tabell som inneholder informasjon om en feil har blitt fikset eller ikke. Den klassen har et arrayobjekt av ErrorLog fordi en feil kan forekomme flere ganger, men trenger bare å bli markert som fikset kun en gang. Dette fører til at FixedErrorReport-klassen har referanser til flere ErrorLog objekter. Slik får vi en en-tilmange relasjon mellom FixedErrorReport og ErrorLog. 78

79 Produktrapport Beskrivelse av tabeller Under følger en beskrivelse av alle tabellene databasen består av. ErrorLog Denne tabellen inneholder informasjon om den loggførte feilen. Den har en unik Id(primærnøkkel). Videre inneholder den informasjon over hvilken bruker som har forårsaket feilen, hvilken fil feilen oppstod på, når feilen oppstod, hvilket linjenummer i koden feilen oppstod på, hva slags type feil det er, hvilken nettleser feilen oppstod på og hvilken versjon av nettleseren, navn på applikasjonen og feilmeldingen. Videre blir det gitt en bool verdi som er false til å begynne med. Når feilen blir fikset vil den bli markert til true og tabellen vil få en referanse til en FixedErrorReport-tabell. FixedErrorReport Denne tabellen opprettes hver gang en feil blir fikset. Den inneholder en unik ID(primærnøkkel). Videre inneholder den en kommentar som brukeren skriver inn når feilen er blitt fikset. Tabellen inneholder referanser til alle like feil i systemet. Hver gang en feil blir fikset, blir alle lignende feil også markert som fikset og alle feilene får referanse til en felles FixedErrorReport tabell. Customer Denne tabellen inneholder informasjon om en kunde. Den har en unik Id(primærnøkkel). Videre har den også en unik key. Det inneholder informasjon om når den ble opprettet og når den sist ble oppdatert. Videre har den referanser til Usage og CustomerData tabeller. CustomerData Denne tabellen viser informasjon som har blir lagt til en customer. Den har en unik Id(primærnøkkel) og en customerid(fjernnøkkel). Videre står det når den ble opprettet. Hver gang en ny customerdata blir lagt til en customer oppdateres Customertabellens LastUpdatedverdi. Usage Denne tabellen inneholder informasjon om hver brukerhendelse. Fra hvilken link man navigerer til hvilken link. Hvor lang tid det tar og hvilken nettleser som blir brukt. 79

80 Produktrapport 22.4 Controllere Som forklart i kapittel i prosessrapporten har vi brukt Microsoft sitt nyutviklede Odatarammeverk. Dette gir oss tilgang til mye nyttig informasjon i form av metadata som blir forklart senere i rapporten. ODATA-controllene lar oss filtrere direkte fra url-en som er forklart tidligere i prosessrapporten. Videre er alle controllere basert på et REST API med GET, POST, PUT, UPDATE og DELETE metoder som er grundigere forklart i prosessrapport kapittel Videre implementerer alle metodene et «Iqueryable» attributt som gir oss effektiv filtrering på data i databasen. Forskjellen mellom filtrering på «Enumerable» som er standarden og «Iqueryable» er at ved «Enumerable» hentes først alle dataene opp fra databasen, og deretter filtreres den. I motsetning får man et ferdig filtrert resultat fra databasen ved Iqueryable. Skjermbilde 38: Kodesnutt Queryable 80

81 Produktrapport 22.5 UnhandledExceptionFilter Et av kravene i systemet er at det skal kunne loggføre feil som oppstår internt i systemet. Dette er gjort ved et såkalt UnhandledExceptionFilter som blir triggered hver gang det oppstår en feil internt i systemet. Dets funksjons er å loggføre den exception som oppstod. Samtidig hindrer det systemet fra og kræsje ved en feil. Dette gir oss mulighet til å håndtere feil i systemet på en smart og effektiv måte uten at mye går galt. Nedenfor er det gitt et skjermbilde av koden til filteret. Skjermbilde 39: Filteret Man kan få frem en del informasjon fra en exception. Alt fra hvilke linjenummer feilen oppstod på til hva slags type feil det. Nedenfor er gitt en oversikt over noe av informasjonen man kan hente ut av en exception. Skjermbilde 40: Informasjon om feilen som blir lagret 81

82 Produktrapport 23. Frontend Frontenden er den delen av systemet som brukeren interagerer med. Frontend kommuniserer med backend via de ressursene som er tilgjengelig gjennom APIet. Denne delen av systemet er skrevet i Html, Css, Javascript, Jquery, Ajax og Json og benytter seg av rammeverket EmberJs. Ember er et SPA rammeverk som går ut på at all nødvendig html, javascript og css kode blir lastet opp og lagt til på siden ved første «page load». Deretter blir nødvendig data lagt til på nettsiden dynamisk ettersom brukeren utfører handlinger. Det blir ikke gjort noen oppdatering av siden i form av «post back/refresh». Som beskrevet i prosessrapporten er Ember rammeverket delt opp i router, controller, views, components og såkalte handlebars/templates. Routeren har i oppgave å hente data eventuelt fra en database eller andre kilder. Routeren sender deretter dataen videre gjennom controllere og ut i handlebars/templates. Controllere holder altså på informasjon og all behandlinger av data og videresending gjøres gjennom controlleren. Handbars/templates inneholder html og css representasjonen av hva som skal vises på siden. Views og components kan aksessere data fra sine respektive controllere, modifisere dataen og deretter vise den ut i templaten. Skjermbilde 41: Oversikt over filene 82

83 Produktrapport 23.1 Funksjonalitet I dette kapittelet beskriver vi hva som skjer «bak kulissene» ved brukerinteraksjon. Det er forklart hvordan vi henter opp dataen fra databasen, hvordan den behandles og modifiseres, hvordan den vises og eventuelt hvordan data blir send til databasen. En grundig beskrivelse av systemets visuelle funksjonalitet er gitt i vedlegget Brukermanual Lasting av data Løsningen består av klasser som inneholder funksjoner som henter ut data fra gitt api-url. Disse funksjonene er kalt for getapi og koden er gjengitt nedenfor. Data blir hentet fra APIet og formattert med JSON og lagret som Ember.Objekt i routere. Skjermbilde 42: Kodesnutt getapi Som vist på bildet ovenfor blir data hentet fra et api og formattert med JSON. Deretter blir det opprettet et Ember.Object som blir satt inn i et felles array. I løsningen er det tre modeller som extender Ember.Object, disse tre modellene er Customer, ErrorLog og Usage, og det er variabel av disse objektene som blir opprettet ved henting av data og lagt til i routeren. 83

84 Produktrapport 23.3 Visning av data Data blir hentet opp fra routeren og videreført til controlleren som holder på dataen. Det er i controlleren all modifiserings og tilpasningslogikk foregår. Ved hver handling brukeren foretar, blir en eller annen metode i controlleren kalt. Controlleren kaller på eventuelle views og components og gir dem en «bit» av det grafiske brukergrensesnittet. Skjermbilde 43: En liten bit av templaten Bildet ovenfor viser html koden i de såkalte handlebars/templatesene. Dette ligner veldig på vanlig html bortsett fra doble krøllparenteser. Dataen som er innenfor krøllparentesene er data som er lagret i controlleren. I dette tilfellet holder controlleren på et array av Usages som heter list. Koden {{each list}} går igjennom hele list-arrayen og skriver ut Id, User, Customer og Browser for hver Usage. 84

85 Produktrapport 23.4 Lagring av data Lagring til databasen gjøres ved et Ajax kall. Videre blir det bruk JSON for konvertering av objektet som skal lagres til databasen. Hvis det oppstår noen feil internt i systemet på frontenden loggføres de slik: Skjermbilde 44: Logging av feil på frontend 23.5 Komponenter Vi har komponenter som er selvdrevne og behandler data som blir overført til dem via controller. Komponentene opprettes kun etter et kall fra controlleren. Deretter er de ikke lenger avhengige av controlleren og opererer for seg selv Flot Chart Flot chart er et Jquery plugin vi har brukt for grafisk fremstilling av data. Det er blitt brukt Flot Chart til å vise data i from av kakediagram og grafer som viser antall feil i løpet av en tidsperiode. Dette fungerer ved at det blir gitt et array med data til komponent, videre er komponentens oppgave å tegne opp grafene. 85

86 Produktrapport Grafene over antall feil i det gitte tidsintervallet fungerer ved at det blir opprettet et array av objekter som inneholder x og y verdier for plassering av punkt. Kakediagrammet henter opp all dataen som trengs fra databasen og grupperer deretter dataen inn i det brukeren ønsker Filter komponent Filterkomponents er en komponent vi laget selv og er sentral i oppgaven. Dens oppgave er å ta i mot filtre fra brukeren, omgjøre dem til en sql spørring i from av en «string» og returnere den. I brukermanualen er det gitt beskrivelse av hvordan filteret fungerer praktisk, men det er en del logikk bak komponenten. Hver gang brukeren legger til et filter blir det lagt til et objekt i et filter-array som inneholder hvilke type, hvilken operator og hva brukeren har tastet inn. Det objektet kan eksempelvis være «User eq Ola». Samtidig blir det opprettet en sqlsetning med utgangspunkt i innholdet av filter-arrayen som kan sendes videre til apiet for å få opp ønsket informasjon. Skjermbilde 45: Filteret Som man ser på illustrasjonen har det blitt opprettet en sql setning i urlen. Sql setningen blir som følger: «Error eq NullreferenceException and ((User eq Loc ) or User eq Ole )». Det blir lagt til en «and» mellom alle Error og User, og det blir lagt til en «or» mellom alle User. I tillegg blir alle User plassert innenfor parenteser. 86

87 Produktrapport 23.6 Query params For at filter komponenten skulle virke dynamisk og samtidig ikke hente opp unødvendig informasjon har vi tatt i bruk noe som heter «query params» som er i betafasen og ikke helt ferdigutviklet enda. Det fungerer slik at hver gang url-en forandres kalles routeren på nytt og data blir hentet fra databasen på ny. Dette er kjempe effektivt for da slipper man å hente masse unødvendig data før man må filtrere, slik får man allerede filtrert data fra databasen. Dette får tabellen til å opptre dynamisk og den blir mer brukervennlig. Skjermbilde 46: Query params Som vist i bildet ovenfor får vi alle Feil der brukeren enten heter Loc eller Ole og feilen er en NullRefrenceException. Med Query-params kan en bruker av systemet sende link til en annen bruker slik at vedkommende for samme filtrering på dataen. 87

88 Produktrapport 23.7 Local Storage Brukeren kan modifisere forsiden og vise ønskede tabeller og grafer. Når brukeren navigerer bort fra forsiden skal den modifiserte forsiden vises på ny. Dette har vi gjort ved at alle tabeller og grafer på forsiden blir lagret på Local Storage som er forklart i prosessrapportens delkapittel Hver gang brukeren kommer inn på forsiden vil data hentes fra local storage og vises på skjermen. Slik kan hver enkelt bruker ha egen modifisert forside. Localstorage er sikrere, raskere og har større lagringskapasitet enn f.eks cookies. Skjermbilde 47: Localstorage Data blir hentet fra Local Storage med kallet localstorage.getitem og lagret ved kallet localstorage.setitem. LocalStorage kan kun inneholde stringverdier, derfor bruker vi JSON.parse og JSON.stringify for å konvertere mellom objekter og stringrepresentasjoner. 88

89 Produktrapport 23.8 Metadata Filterkomponenten har en dropdownliste som inneholder forskjellige verdier man kan filtrere på. Disse verdiene tilsvarer de forskjellige dataene hvert ErrorLog, Usage og Customer objekt kan inneholde. Hvis det blir lagt til et nytt datafelt på for eksempel ErrorLog må det også legges til på denne dropdownlisten. Ved bruk av metadata unngår vi den hardkodede dropdownlisten. Verdiene i dropdownlisten blir lagt til ut ifra innholdet i metadataen til apiet. Metadata er gitt i en xml-fil som vi går igjennom og finner den dataen vi er ute etter, videre blir denne data lagt til i dropdownlisten. Måten det er gjort på er gjengitt i kodesnutten nedenfor. Skjermbilde 48: Metadata parser 89

90 Produktrapport 24 Samsvar med kravspesifikasjon og produkt I dette kapittelet blir det redegjort for hvordan produktet samsvarer med kravspesifikasjonen og hvordan det innfrir forventningene oppdragsgiver hadde. Kravspesifikasjonen er beskrevet i et eget vedlegg, derfor henvises det til kapittel 31 i rapporten Oppfyllelse av krav Kravene ble satt av oppdragsgiver Syscom AS og er gitt som et vedlegg i kapittel 31 i rapporten. Kravspesifikasjonen beskriver oppdragivers funksjonelle og ikke-funksjonelle krav til produktet. Videre har det blitt stilt flere krav til produktet underveis i utviklingen. Dette har krevd en ekstra innsats enn forventet, og det har ført til at vi har klart å levere mer enn det som i utgangspunktet var forventet. Det var forventet en bratt læringskurve, spesielt med nye teknologier som API og ikke minst rammeverket EmberJS som vi ikke hadde vært bort i før. Dette har krevd en stor innsats i forhold til tidsrammen. Til tross for det har vi klart å innfri alle kravene til systemet. Oppdragsgiver har vært positivt overrasket over hvor fort vi har klart å lære oss de forskjellige rammeverkene Avslutning Avslutningsvis vil vi i dette kapittelet beskrive resultatet av vårt arbeid og tilbakemeldingen vi har mottatt fra oppdragsgiver. Videre vil vi gjøre rede for videre utvikling, og bruk av systemet. Til slutt er det noen avsluttende ord om produktet Produktets kvaliteter Apiet er robust og generisk med en solid grunnstruktur som er åpent for utbygging og videreutvikling. Det er lett å sette seg inn i apiet og består av en forståelig og ikke minst oversiktlig kode på grunn av SOLID prinsippene som er blitt fulgt. Apiet består i dag av en database som holder informasjon om feil, brukerstatistikk og kunder. Bruk av ODATA controllere gir oss rask filtrering av data ved at dataen blir filtrert før den hentes i motsetning til å filtrere etter og hentet opp all data. Det kan bli sendt data til databasen, og databasen kan også endres uten tap av data på grunn av migrations. 90

91 Produktrapport Frontenden er utviklet i Javascript rammeverket EmberJs noe som har gitt en meget brukervennlig og dynamisk side. Siden har en god flyt og fungerer veldig bra som en webapplikasjon. Inneholder i databasen blir presentert på en oversiktlig måte og man har tilgang til all nødvendig informasjon fra siden. Det at hver enkelt bruker kan modifisere sin egen forside gir brukeren rask tilgang til akkurat den informasjonen brukeren trenger. Filtrering av data skjer veldig raskt og dynamisk, det gir en god brukeropplevelse. Produktet som er utviklet vil gi ansatte på Syscom AS en enkel, rask og ikke minst brukervennlig oversiktlig over feil, brukerstatistikker og kundedata. Produktet fungerer som en felles portal for denne informasjonen som er lett tilgjengelig. Hvis en feil har blitt fikset kan den bli markert som "fikset" slik at brukere av systemet er oppdatert til enhver tid. Hver bruker kan tilpasse sin egen forside noe som gir en rask tilgang på informasjon. 91

92 Produktrapport 24.4 Tilbakemelding Syscom AS er meget fornøyd med produktet vi har utviklet og er overrasket over hvor fort vi har klart å lære oss rammeverket EmberJS i forhold til tidsintervallet. Samtidig er de godt fornøyd med at vi har oppfylt alle krav og tilleggskrav. Skjermbilde 49: Tilbakemelding fra Syscom AS 24.5 Videreutvikling og vedlikehold Avvendingen av SOLID-prinsippene har gitt en gjenbrukbar, lett forståelig og robust kode som er enkel å vedlikeholde og videreutvikle. Endringer på databasen kan gjøres uten tap av data ved hjelp av migrations. Bruken av EmberJS rammeverket gir oss en oversiktlig mappestruktur og med komponenter, views og controllere. På grunn av dette er det enkelt å legge til nye komponenter og funksjoner uten store endringer i den opprinnelige koden. 92

93 Produktrapport ODATA og qeury-params er teknologier som er i betafasen og ikke ferdigutviklet enda. Dette må tas hensyn til da det kan komme nyere versjoner underveis og det krever oppdateringer. Query-params oppdatering kommer i form av nye script publisert på nettsiden EmberJS.com. Der må en velge "Ember Canary Build"-skriptet. Odata-rammeverket oppdateres via NuGet package manager konsollen Konklusjon Oppgaven vår skiller seg fra vanlig systemutvikling siden vi både har utviklet frontenden og backenden. Vanligvis gjør man enten det ene eller det andre. Vi har utviklet en robust og generisk API som er enkelt å vedlikeholde og videreutvikle og er lett forståelig. Samtidig har vi utviklet en frontend i EmberJS-rammeverket som gir en brukervennlig og oversiktlig presentasjon av data i from av tabeller og grafer. Prosessen har resultert i et produkt som gjør god nytte av digitale verktøy og nyere teknologi som Odata. Sluttproduktet er noe oppdragsgiveren vil ha stor nytte av. Det vil være spesielt nyttig for utviklerne i Syscom AS. De vil ha rask tilgang på feil som må rettes opp og de kan gjøre det før feilene utvikler seg til det verre. Samtidig vil de ha nyttig informasjon om kunder og brukerstatstikk på en felles side. Vi har utfordret oss selv på et høyt nivå og samtidig utviklet et nyttig produkt. På bakgrunn av oppnåelse av de mål som var satt for produkter og tilbakemelding fra oppdragsgiver kan vi konkludere med at prosjektet har vært svært vellykket. 93

94 Produktrapport 94

95 Testrapport TESTRAPPORT HiOA - Fakultet for teknologi, kunst og design (TKD) Kull

96 Testrapport 96

97 Testrapport 17. Forord Dette dokumentet beskriver hvilken tester vi har gjennomført og hva slags metoder som ble tatt i bruk, samt resultatene av disse. Rapporten er ment for sensor og oppdragsgiver og kan være til hjelp med vedlikehold og videreutvikling. Selv om testing ikke har vært en stor del av prosjektet, velger vi å ta med dette. Siden vi faktisk fikk nyttig informasjon for videreutvikling underveis. Grunnen til at test ikke er med som et fokuspunkt er at produkteier ønsket at vi fokuserte på implementasjon og funksjonalitet. 18. Metoder Formålet med testing er at vi kan sikre at produktet er sikkert og robust nok til at det kan settes ut i drift. I løpet av utviklingen gjennomførte vi ulike tester ved hjelp av ulike metoder. Det første vi startet med var bruk av mock testing og dependency injection. 19. Verktøy til testing: Visual studios innebygde test verktøy Mocking Dependency injection Nettlesere Local storage Brukertesting 20. Feiltesting av kode Nylig implementert kode ble testet ved det ble lagd såkalte mocks gjennom Moqrammeverket. Det gikk ut på at mockenene simulerte reelle objekter som de forskjellige metodene i systemet skulle behandle. Det ble sendt mocking-objekter til metodene i controllere og det ble rapportert hvis noen uhåndterte feil oppstod. Det ble brukt dependency injection for å teste de forskjellige metodene. Slik trengtes det ikke å opprettes nye controllere kun for å teste dem, derimot ble det brukt eksisterende controllere. Disse testene ble kun gjort 97

98 Testrapport på serversiden siden produkteier ville at det skulle legges mer vekt på utviklingen av systemet. Disse testene ble utført i forbindelse med generell feiltesting og kontroll av kvalitet, hensikten med feiltestingen var at koden som nylig ble implementert også fungerer på riktig måte. Skjermbilde 50: Kodesnutt fra testing I tidlig utviklingsfase testet vi hver funksjon grundig for all mulige inn og utdata de kunne bli utsatt for, og om de ga riktige verdier. Selv om vi var ganske ny innen dette fikk vi ganske gode tilbakemeldinger på testingen fra produktier. Tilbakemelding fra produkteier i forbindelse med testing: Dette var også et relativt nytt tema for teamet, men de tok det til seg fort og har høy testdekning etter første sprint. - Tommy Kristoffersen 21. Testing på forskjellige nettlesere Denne delen oppsummerer alle testene vi utførte på PureHub med forskjellige nettlesere. Dette var for å se hvordan det ser ut, og hvordan den oppførte seg hos forskjellige nettlesere. Feil i andre nettlesere enn Google Chrome er ikke kritiske, grunnen til dette er at i første omgang skal dette kun bli brukt intern hos Syscom. Vi valgte derimot å ta med testing av forskjellige nettlesere for videreutvikling og drift. 98

99 Testrapport Testresultatene er av korte kommentarer. OK betyr at testen ble godkjent uten noen kommentarer. Test Google Mozilla Opera Internet Safari Chrome Firefox Explorer Default tabeller OK OK OK OK OK Local Storage OK OK OK OK OK Lage nye error OK OK OK OK OK tabell Lage nye error OK OK OK OK OK tabell Lage nye OK OK OK OK OK piechart Lage nye timechart OK Feil, grunnet gammelt nettleser versjon OK Feil, grunnet gammelt nettleser versjon Rammeverket støtter ikke denne nettleseren Funksjonaliteten OK OK OK OK OK på filteret Utseende og størrelse. OK Feil, grunnet gammelt nettleser versjon OK OK OK Grunnen til at vi valgte ut og testet disse er at de er de mest brukte nettlesere. Ut i fra testene ser man at PureHub fungerer likt hos alle, men det er noen uregelmessigheter i forbindelse med design. Dette gjelder kun de eldre versjonene av nettlserne. At det ikke fungerer på alle nettlesere er ikke kritisk i dette punktet, grunnet at dette er kun brukt intern for å starte med, men kan være relevant for senere utvikling. Utenom dette så fungerer alle funksjoner som local storage, nye tabeller og filteret på alle nettlesere. 99

100 Testrapport 100

101 Testrapport 22. Brukertesting Når vi nærmet oss slutten og nærmet oss mål, tok vi i bruk brukertesting. Både fagpersoner med kunnskaper og andre personer som ikke har noe faglig bakgrunn, ble bedt om å prøve PureHub. Det vi var ute etter var tilbakemeldinger om blant annet når det gjaldt oppførsel på siden, navigasjon og brukergrensesnitt. Vi ga disse brukertestere forskjellige scenario og oppgaver å fullføre, disse ble utført kronologisk som vist på tabellen under. Hvis oppgaven eller fremgangsmåten ikke var forståelig eller noe uklart for brukeren, revurderte vi og eventuelt endret brukergrensesnittet. Spørsmål/oppgave Testbruker 1 Testbruker 2 Testbruker 3 Testbruker 4 Hva er ditt første Ryddig, fint og Oversiktlig og Oversiktlig og Simpel og lett, inntrykk av oversiktlig behagelig ryddig. Simpelt. lett å forstå hva PureHub design den skal brukes til. Lag en ny error Veldig lite rom Ganske lett, lite Forstod raskt Ok, veldig rett tabell på 10 feil for feil. rom for feil. hvordan det fram. fungerte, lite rom for feil. Lag en ny usage Veldig enkelt. Fort gjort. Lite Veldig lett, er Ok, veldig greit tabell med Vanskelig å rom for feil. ingen rom for med eksempelet oversikt over nye gjøre noe feil feil nesten. over datoen. usages etter her Modifiser på en Rett fram, Forståelig, Helt likt som Ok, helt lik som tabell akkurat som å ganske lik tidligere, veldig tidligere. lage ny tabell hvordan du lett. lager ny tabell Lag en sektor Enkelt, simpel Ok, ryddig og Ok, oversiktlig Veldig lett og diagram og fin visning fin diagram. og lett oversiktlig av diagrammet. forståelig diagram. diagram. 101

102 Testrapport Lag en linjegraf Ok, veldig Ok, mange Ok, gøy med Ok, oversiktlig over et år med mange farger å velge mange valg av og fin graf. forskjellige farger alternativer for mellom. farger. farger her. Fiks en feil Ok, lett å forstå. Ok, bra at det Ok, lett å forstå Ok, enkelt og går fra rødt til når feil er forståelig. grønt. fikset. Er det noen Nei, den virker Virker som alt Nei, den virker Nei, alt er funksjonalitet du veldig er på plass. helt ferdig. ganske savner? komplett. oversiktlig og fint. Resultatene vi fikk var overaskende, og mange syns brukergrensesnitt var ganske lett og forståelig. Funksjonaliteten fikk mange positive tilbakemeldinger, fremvisning av PureHub ble oppfattet oversiktlig og simpelt. 102

103 Testrapport 23. Konklusjon Testene som vi tok for oss, avslørte noen feil tidlig så vi kunne rette opp i dette i tidligere i utviklingsprosessen. Testmetodene har bidratt til å øke kvalitet ved å sikre at den funksjonaliteten er på plass og fungerer som de skal. Det har vært til nyttig for oss ved at vi fikk rettet opp i et par bugs i en tidlig fase. Brukertesting var et viktig test område for oss under utviklingsprosessen. Interne og eksterne brukere ga oss gode tilbakemeldinger, og dette bidro til å lage noe sluttbrukeren ønsket seg. Produktet er lett forståelig og enkelt å bruke, dette bidrar til at Syscom kan samle all informasjon de trenger til en enkelt side og vist det frem på en ryddig og fin måte. Ved å ha brukeren sentralt i utviklingsprosessen med hyppige brukertesting og tilbakemelding fra både Tommy(produkteier), utviklere som skal ta dette i bruk og andre testpersoner endte i opp med et godt resultat. Produktet ble tatt godt imot og brukere mente at dette var enkelt å bruke og var veldig fornøyde. Utviklerne som skal bruke dette, syns det var både oversiktlig og ryddig, og det var akkurat det de trengte. 103

104 Testrapport 104

105 Brukermanual BRUKERMANUAL HiOA - Fakultet for teknologi, kunst og design (TKD) Kull

106 Brukermanual 106

107 Brukermanual 24. Forord Det forutsettes at leseren av dette dokumentet har lest og gjort seg kjent med presentasjonsdokumentet. Under denne forutsetning kan dokumentet leses selvstendig. Det anbefales at brukeren har noe kjennskap til produktrapporten. Dette dokumentet beskriver hvordan vi kan benytte oss av PureHub. Dokumentet er beregnet for utviklere hos Syscom AS, og kreves ingen forkunnskaper enn at man er tilkoblet på internett, og må kunne bruke en pc, nettbrett eller mobil. Det blir beskrevet steg for steg hva man kan gjøre på web-løsningen. Manualen er kronologisk bygd opp, her starter vi med å forklare startsiden. Det blir brukt noen tekniske ord, men disse blir godt forklart slik at det er forståelig for alle. Brukermanualen viser instruksjoner for hvordan du kan få et eget definert side, der du selv velger hva du ønsker å vise fram. 25. Startsiden På startsiden ser du en meny med knapper som ligger øverst til venstre. Disse brukes til å navigere seg rundt og er å finne på alle underlinker av nettsiden. Tabellene som vises på skjermbildet nedenfor er standard for alle som laster inn PureHub for første gang. Disse tabellene kan fjernest eller modifisere hvis en ønsker. Det er mulig å tilpasse hva som skal vises av tabeller og grafer. Disse vil bli lagret i localstorage, slik at tilpasningen ikke blir slettet når man krysser av nettsiden. 107

108 Brukermanual Navigerings-knappene øverst til venstre er: Home: Hovedsiden med innhold som en selv har valgt. Errors: Oversikt over alle loggførte feil/error som har oppstått. Har et filter som brukes til å finne spesifikke feil/error. Usages: Oversikt over alle brukerstatistikk fra kunder. Har et filter som brukes til å finne spesifikke brukere. Customers: Oversikt over alle kundedata fra kunder. Har et filter som brukes til å finne spesifikke kunder. Det vil bli forklart hva slags muligheter man har i hver av navigasjons-knappene, med bilder og tekst. 26. Filter Med filter er det mulig å søke etter lagret data og finne fram innholdet. Filteret finnes i alle underlinker på nettsiden som inneholder mengder av data. 1. I "dropdown" listen finnes det mange alternativer. Hvilke alternativer man kan velge kommer helt ann på hvor man befinner seg i. I "Errors" vil alternativene være: User, File, Date, Error, Application Name som man kan filtrere etter. 2. I denne "dropdown" listen kan man velge mellom eq som er lik, ne som IKKE er lik, lt som er mindre enn og gt som er større enn. Det siste blir som regel brukt til å filtrere etter dato som vist på eksemplet. 108

109 Brukermanual 3. Fritekst for søking av data. 4. Ved å trykke på knappen legger man til spesifiserte filteret man har skrevet og det vil kjøre gjennom REST-API etter data. 5. "Checkboxene" er kun tilgjengelig på Errors og vil ikke bli vist noen andre steder. Boksene brukes til å velge mellom å vise kun feil som er fixed (Krysser av på Fixed errors ), feil som IKKE er fikset (Krysser av på Not fixed errors ) eller alle (Krysse av på begge) 27. Konfigurasjon Disse tabellene/grafene kan vises fram som vist under. Errors: Feil som har blitt logget av systemet, kan bli vist fram i en enkel tabell som viser id, applikasjonsnavnet, navn på feilen, i hvilken fil, dato og hvem bruker som forårsaket dette. Usages: Brukerstatistikken blir vist fram i en enkel tabell med informasjon om id, hvilken bruker, hvilken kunde og fra hva salgs nettleser de bruker. 109

110 Brukermanual Piechart: Feil kan også bli vist fram i form av et sektordiagram. Timechart: Viser feil i form av linjegraf med antall feil i et gitt tidsintervall. 110

111 Brukermanual A. Navigerings knappene er tilgjengelig i alle underlinker og det er alltid mulig å navigere seg vekk fra en link til en annen. B. 1. Blyant knappen brukes til å modifisere tabellen. 2. X-knappen vil slette tabellen. C. Ved å trykke på Add vil man få muligheten til å legge til flere tabeller/grafer. Som vist på skjermbildet nedefor, er det mulig å velge mellom alternativene Error table, Usage table, Error pie eller "Error line. 111

112 Brukermanual D. Tittel man selv har valgt vil stå på dette feltet. Det er alltid mulig å endre dette ved å trykke på blyant knappen som tidligere har blitt forklart. E. Inneholder de siste 5 data som man har valgt. Det er mulig å modifisere og øke innholdet Error table A. Ved valg av ny tabell vil det dukke opp en "modal" vindu som inneholder "input" felter og et filter, som vist på skjermbildet ovenfor. Man kan selv velge hva tabellen skal hete og hvis feltet er tomt når man velger å lagre vil den hete etter hvilken type som er valgt, f.eks "Errors". B. Filteret fungerer på lik måte som det tidligere har blitt forklart og brukes til å filtrere data etter det en ønsker å vise fram. C. Feltet er for å bestemme størrelsen på innholdet i tabellen, og det er "default" på 5 hvis en glemmer å fylle ut. D. Når alle innstillingene er satt etter behov, trykker man på "Save Changes"-knappen og tabellen vil dukke opp etter dine innstillinger. 112

113 Brukermanual E. Om man vil gå ut av "modal" vinduet, er det enten mulig ved å trykke på "x" knappen helt øverst til høyre, "close" knappen eller trykke på det gråe vinduet i bakgrunnen 26.2 Usages table A. Ved valg av ny tabell vil det dukke opp en "modal" vindu som inneholder "input" felter og et filter, som vist på skjermbildet ovenfor. Man kan selv velge hva tabellen skal hete og hvis feltet er tomt når man velger å lagre vil den hete etter hvilken type som er valgt, f.eks "Usages". B. Filteret fungerer på lik måte som det tidligere har blitt forklart og brukes til å filtrere data etter det en ønsker å vise fram. C. Filter som man legger til vil havne på dette vinduet. Om man ønsker å fjerne det valgte filterer, er det mulig ved å trykke på "X" knappen. 113

114 Brukermanual D. Feltet er for å bestemme størrelsen på innholdet i tabellen, og det er "default" på 5 hvis en glemmer å fylle ut. E. Når alle innstillingene er satt etter behov, trykker man på "Save Changes"-knappen og tabellen vil dukke opp etter dine innstillinger. F. Om man vil gå ut av "modal" vinduet, er det enten mulig ved å trykke på "x" knappen helt øverst til høyre, "close" knappen eller trykke på det gråe vinduet i bakgrunnen 26.3 Piechart A. Ved valg av ny graf vil det dukke opp en "modal" vindu som inneholder "input" felter og et filter, som vist på skjermbildet ovenfor. Filteret fungerer på lik måte som det tidligere har blitt forklart og brukes til å filtrere data etter det en ønsker å vise fram. 114

115 Brukermanual B. Filter som man legger til vil havne på dette vinduet. Om man ønsker å fjerne det valgte filterer, er det mulig ved å trykke på "X" knappen. C. "Dropdown" listen inneholder alternativer som: error, date, user, fixed, og brukes til å gruppere grafen. D. Når alle innstillingene er satt etter behov, trykker man på "Save Changes"-knappen og tabellen vil dukke opp etter dine innstillinger. E. Om man vil gå ut av "modal" vinduet, er det enten mulig ved å trykke på "x" knappen helt øverst til høyre, "close" knappen ellertrykke på det gråe vinduet i bakgrunnen. Når man er ferdig vil det bli vist fram et sektordiagram etter det en har valgt. 115

116 Brukermanual 26.4 Timechart A. Ved valg av ny graf vil det dukke opp en "modal" vindu som inneholder "input" felter og et filter, som vist på skjermbildet ovenfor. Filteret fungerer på lik måte som det tidligere har blitt forklart og brukes til å filtrere data etter det en ønsker å vise fram. B. Her er det mange muligheter som blant annet: 1. "Last Days Dropdown" listen inneholder alternativer som: 7, 30 og 365, og grafen viser etter dette. 2. "Linecolour Dropdown" listen inneholder mange av de standarder fargene man kan velge for hvordan linjen skal se ut. 3. "Backgroundcolor1 Dropdown" listen inneholder mange av de standarder fargene man kan velge for hvordan bakgrunnen skal se ut, og fargen blender sammen med punkt "Backgroundcolor2 Dropdown" listen inneholder mange av de standarder fargene man kan velge for hvordan bakgrunnen skal se ut, og fargen blender sammen med punkt

117 Brukermanual C. Når alle innstillingene er satt etter behov, trykker man på "Save Changes"-knappen og tabellen vil dukke opp etter dine innstillinger. D. Om man vil gå ut av "modal" vinduet, er det enten mulig ved å trykke på "x" knappen helt øverst til høyre, "close" knappen ellertrykke på det gråe vinduet i bakgrunnen. 28. Errors Ved å navigere til "Errors" vil man bli møtt med en tabell som inneholder 250 siste lagrede feil/error 117

118 Brukermanual Innholdet i tabellen er trykkbare og man vil bli navigert til den valgte feil/error, hvor man vil kunne se grundigere informasjon, om den har blitt fikset eller ikke. På skjermbildet under vil man kunne se at feilen/erroren ikke har blitt fikset. A. All informasjonen av denne feilen blir vist fram her. B. Statusen til feilen her er ikke fikset og blir merket i rødt, kommentaren og datoen vil være tom. C. For å fikse denne feilen kan man skrive en kommentar, og helst om hvordan det har blitt ordnet, og trykke på "Save" knappen. Da vil samme feilen som går om igjen bli fikset i hele systemet og statusen vil bytte farge. Videre vil kommentaren og datoen komme opp på skjermen. 118

119 Brukermanual A. Etter at en har fikset feilen vil fargen bli byttet. B. Kommentaren som ble skrevet for feilen vil dukke opp her. C. Datoen denne feilen ble fikset vil stå her. 29. Usages Brukerstatistikken har ganske lik funksjoner som Errors. Innholdet i tabellen er trykkbare og man vil bli navigert til den valgte brukstatistikken, hvor man vil kunne se grundigere informasjon. 119

120 Brukermanual Her er en oversikt over alle attributtene til en enkel Usage. 30. Customers I Customers siden er også filteret tilgjengelig, og innholdet i tabellen er trykkbare og man vil bli navigert til den valgte kunden, hvor man vil kunne se grundigere informasjon. 120

121 Brukermanual I hver enkel kunde vil man se oversikt over kundedataen, når den blir laget og sist den ble oppdatert. Samt et sektordiagram over kundedataene som har blitt lagd av kunden. A. Her vises detaljert informasjon om kunden med kundens id, navn, dato den ble lagd og sist den ble oppdatert. B. Sektordiagram vises basert på kundedataen. C. Her vises kundedataen med id, type, antall og dato. Det er også mulighet til å fjerne en eller flere kundedata ved å trykke på X. 121