WEB APPLICATION DEVELOPMENT – REST API &...

1

WEB APPLICATION

DEVELOPMENT – REST API &

EMBERJS

pure hubProsjektgruppe: Raheel Akhtar

Quan Vu

Loc Cao Do

Rådgiver: Kirsten Ribu

Produkteier: Tommy Kristoffersen

Kunde: Syscom AS

HiOA - Fakultet for teknologi, kunst og design (TKD )

3

Kull 2011

HOVEDPROSJEKT

HOVEDPROSJEKTETS TITTEL

Web application development - API & EmberJS

DATO

23.05.2014

ANTALL SIDER / BILAG

128/1

PROSJEKTDELTAKERE

Raheel Arshad Akhtar (3AA), s181139

Thien-Loc Cao Do (3AB), s181093

Quan Minh Vu (3IA), s180490

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 www.pureservice.com. 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

Studieprogram: Informasjonsteknologi

Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo

Besøksadresse: Holbergs plass, Oslo

PROSJEKT NR.

22

TILGJENGELIGHET

Telefon: 22 45 32 00

Telefaks: 22 45 32 05

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

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.

7

Innholdsfortegnelse

Web application development – REST API & EmberJS ............................................................................. 1

HOVEDPROSJEKT ..................................................................................................................................... 3

Forord ...................................................................................................................................................... 5

LISTE AV ILLUSTRASJONER ......................................................................................................... 11

Presentasjon ................................................................................................................................................ 13

1. Forord ................................................................................................................................................ 15

2. Prosjektgruppen ................................................................................................................................ 15

3. Oppdragsgiver ................................................................................................................................... 15

4. Bakgrunn for oppgaven .................................................................................................................... 16

5. Mål for oppgaven .............................................................................................................................. 17

6. Beskrivelse av sluttproduktet ........................................................................................................... 19

7. Rammebetingelser og konsept ......................................................................................................... 19

Prosessrapport ............................................................................................................................................ 21

8. Forord ................................................................................................................................................ 23

9. Planlegging og metode ...................................................................................................................... 23 9.1 Planlegging .................................................................................................................................................. 23

10. Arbeidsforhold ................................................................................................................................ 24

11. Kommunikasjon .............................................................................................................................. 25 11.1 Samarbeid - prosjektgruppen ..................................................................................................................... 25 11.2 Samarbeid med oppdragsgiver .................................................................................................................. 26 11.3 Samarbeid med veileder ............................................................................................................................ 26

12. Styringsdokumenter ........................................................................................................................ 27 12.1 Statusrapport .............................................................................................................................................. 27 12.2 Prosjektskisse ............................................................................................................................................ 27 12.3 Forprosjektrapport ..................................................................................................................................... 27 12.4 Prosjektdagbok .......................................................................................................................................... 27 12.5 Risikoanalyse ............................................................................................................................................. 27 12.6 Risikotabell ................................................................................................................................................ 28 12.7 Risikohåndtering ........................................................................................................................................ 30 12.8 Fremdriftsplan ........................................................................................................................................... 31

13. Kravspesifikasjon ............................................................................................................................ 32

14. Versjonskontroll og backupløsninger ........................................................................................... 32

15. Teknologier og verktøy ................................................................................................................... 33 15.1 Verktøy .................................................................................................................................................. 33 15.1.1 Visual studio ..................................................................................................................................... 33 15.1.2 TFS(Team Foundation Server) ............................................................................................................... 33 15.1.3 Microsoft Word ...................................................................................................................................... 34 15.1.4 Postman .................................................................................................................................................. 35 15.1.5 Ember Inspector ...................................................................................................................................... 35 15.1.6 Kompilator .............................................................................................................................................. 36

8

15.1.7 Twitter bootstrap ............................................................................................................................. 37 15.1.8 Pluralsight ......................................................................................................................................... 37 15.1.9 Stackoverflow ......................................................................................................................................... 38 15.1.10 Microsoft Azure Web Sites ......................................................................................................... 38 15.1.11 Localstorage.......................................................................................................................................... 39 15.2 Språk .......................................................................................................................................................... 40 15.2.1 Javascript ................................................................................................................................................ 40 15.2.2 AJAX ...................................................................................................................................................... 40 15.2.3 JQuery..................................................................................................................................................... 40 15.2.4 HTML ..................................................................................................................................................... 40 15.2.5 JSON....................................................................................................................................................... 41 15.2.6 CSS ......................................................................................................................................................... 41 15.2.7 SQL ........................................................................................................................................................ 42 15.3 Rammeverk og testing ............................................................................................................................... 42 15.3.1 EmberJS .................................................................................................................................................. 42 15.3.2 Ember Canary ......................................................................................................................................... 43 15.3.3 Odata ................................................................................................................................................... 43 15.3.4 FlotCharts .......................................................................................................................................... 44 15.3.5 Entityframework .............................................................................................................................. 45 15.3.6 RESTFUL API ....................................................................................................................................... 46 15.3.7 Webgrease .......................................................................................................................................... 46 15.4 Testing ....................................................................................................................................................... 46 15.4.1 Mocking .................................................................................................................................................. 46 15.4.2 Dependency injection ............................................................................................................................. 47 15.4.4 Moq ........................................................................................................................................................ 47

16. Om utviklingsprosessen .................................................................................................................. 49 16.1 Utviklingsmetode....................................................................................................................................... 49 16.1.1 Scrum ...................................................................................................................................................... 49 16.2 Tilegning av kunnskap ............................................................................................................................... 53 16.3 Faser .......................................................................................................................................................... 54

17. Avsluttende del ................................................................................................................................ 68 17.1 Det ferdige produktet ................................................................................................................................. 68 17.2 Utbytte for oppdragsgiver .......................................................................................................................... 68 17.3 Læringsutbytte ........................................................................................................................................... 68 17.4 Tilbakemelding fra oppdragsgiver ............................................................................................................. 69 17.5 Videreutvikling og vedlikehold ................................................................................................................. 69 17.6 Konklusjon ................................................................................................................................................ 69

Produktrapport ........................................................................................................................................... 71

18. Forord .............................................................................................................................................. 73

19. Innledning ........................................................................................................................................ 73

20. Bakgrunn for oppgaven .................................................................................................................. 73

21. Kodespråk og prinsipper angående syntaks ................................................................................. 74 21.1 Prinsipper ................................................................................................................................................... 74 21.2 Språk .......................................................................................................................................................... 76

22. Struktur ........................................................................................................................................... 77 22.1 Backend ..................................................................................................................................................... 77 22.2 Server ......................................................................................................................................................... 77 22.3 Databasen .................................................................................................................................................. 78 22.4 Controllere ................................................................................................................................................. 80 22.5 UnhandledExceptionFilter ......................................................................................................................... 81

23. Frontend ........................................................................................................................................... 82 23.1 Funksjonalitet ............................................................................................................................................ 83 23.2 Lasting av data ........................................................................................................................................... 83 23.3 Visning av data .......................................................................................................................................... 84 23.4 Lagring av data .......................................................................................................................................... 85

9

23.5 Komponenter ............................................................................................................................................. 85 23.5.1 Flot Chart ................................................................................................................................................ 85 23.5.2 Filter komponent..................................................................................................................................... 86 23.6 Query params ............................................................................................................................................. 87 23.7 Local Storage ............................................................................................................................................. 88 23.8 Metadata .................................................................................................................................................... 89

24 Samsvar med kravspesifikasjon og produkt .................................................................................. 90 24.1 Oppfyllelse av krav .................................................................................................................................... 90 24.2 Avslutning ................................................................................................................................................. 90 24.3 Produktets kvaliteter .................................................................................................................................. 90 24.4 Tilbakemelding .......................................................................................................................................... 92 24.5 Videreutvikling og vedlikehold ................................................................................................................. 92 24.6 Konklusjon ................................................................................................................................................ 93

Testrapport .................................................................................................................................................. 95

17. Forord .............................................................................................................................................. 97 18. Metoder........................................................................................................................................................ 97 19. Verktøy til testing: ....................................................................................................................................... 97 20. Feiltesting av kode ....................................................................................................................................... 97 21. Testing på forskjellige nettlesere ................................................................................................................. 98 22. Brukertesting ............................................................................................................................................. 101 23. Konklusjon ................................................................................................................................................ 103

Brukermanual........................................................................................................................................... 105 24. Forord ........................................................................................................................................................ 107 25. Startsiden ................................................................................................................................................... 107 26. Filter .......................................................................................................................................................... 108 27. Konfigurasjon ............................................................................................................................................ 109 28. Errors ......................................................................................................................................................... 117 29. Usages ....................................................................................................................................................... 119 30. Customers .................................................................................................................................................. 120

Vedlegg ...................................................................................................................................................... 124

39. Kravspesifikasjon .......................................................................................................................... 124 39.1 Innledning ................................................................................................................................................ 124 39.2 Om bedriften ............................................................................................................................................ 124 39.3 Bakgrunn for prosjekt .............................................................................................................................. 124 39.4 Forord ...................................................................................................................................................... 125 39.5 Krav til oppgaven .................................................................................................................................... 125

40. Kildeliste ........................................................................................................................................ 127

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

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 46: Query params


Skjermbilde 48: Metadata parser

Skjermbilde 49: Tilbakemelding fra Syscom AS

Skjermbilde 50: Kodesnutt fra testing

Presentasjon

13

PRESENTASJON


Kull 2011

Presentasjon

14

Presentasjon

15

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

Presentasjon

16

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

Skjermbilde3: Noen av Syscoms kunder.

4. Bakgrunn for oppgaven

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.

Presentasjon

17

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 www.pureservice.com. 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

http://www.supportpoint.net/

Presentasjon

18

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

Presentasjon

19

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

applications), 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.

Presentasjon

20

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

format 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:

http://purehub.azurewebsites.net/api/errorlog.

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.

http://purehub.azurewebsites.net/api/errorlog

Prosessrapport

21

PROSESSRAPPORT


Kull 2011

Prosessrapport

22

Prosessrapport

23

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.

Prosessrapport

24

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

Prosessrapport

25

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.

11.1 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

Prosessrapport

26

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.

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

Prosessrapport

27

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.

12.1 Statusrapport

Dette er et av de første dokumentene som ble skrevet, og levert rundt desember 2013.

Dokumentet inneholder en kort beskrivelse av statusen om hvordan vi lå an med å finne en

oppgave.

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

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

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

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

Prosessrapport

28

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 5 6 7 8

Meget sannsynlig 4 5 6 7

Sannsynlig 3 4 5 6

Lite sannsynlig 2 3 4 5

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.

Prosessrapport

29

Interne krangler/Uenigheter:


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:


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.

Prosessrapport

30

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.

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.

0

2

4

6

8

10

12

Januar Februar Mars April Mai

Ødelagt utstyr

Forsinket (kollektiv)

Jobb/andre fag

Overtredelse deadline

Tekniske vanskeligheter

Korttidssykdom

Prosessrapport

31

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

Prosessrapport

32

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.

Prosessrapport

33

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.

15.1 Verktøy

15.1.1 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

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

Prosessrapport

34

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

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

Prosessrapport

35

15.1.4 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

15.1.5 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

Prosessrapport

36

15.1.6 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

Prosessrapport

37

15.1.7 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

15.1.8 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

Prosessrapport

38

15.1.9 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

15.1.10 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

Prosessrapport

39

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


Prosessrapport

40

15.2 Språk

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

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

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

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

Prosessrapport

41

15.2.5 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

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

Prosessrapport

42

15.2.7 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

15.3.1 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

Prosessrapport

43

15.3.2 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

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

Skjermbilde 23: OData

Prosessrapport

44

15.3.4 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 9.5 + og Konqueror 4 + og bruker HTML5 Canvas.

Skjermbilde 24: FlotCharts

Prosessrapport

45

15.3.5 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

Prosessrapport

46

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

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

15.4 Testing

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

Prosessrapport

47

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

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

Prosessrapport

48

Prosessrapport

49

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 "server-

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

16.1 Utviklingsmetode

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

Prosessrapport

50

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

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

Prosessrapport

51

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.

16.1.3 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

Prosessrapport

52

Skjermbilde 28: User stories og tasks

Skjermbilde 29: Definisjon av done

Prosessrapport

53

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.

Prosessrapport

54

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.

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

16.3.1 Idéfase

I idéfasen fokuseres det på omfanget av prosjektet. Det ble utarbeidet en målsetting,

fremdriftsplan og utkast til modeller.

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

Prosessrapport

55

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.

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

Prosessrapport

56

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

Prosessrapport

57

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.

Prosessrapport

58

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.

Prosessrapport

59

Skjermbilde 33: En liten bit av det generiske repositoryen

Prosessrapport

60

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

tjeneren 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:

http://purehub.azurewebsites.net/api/errorlog/?$filter=User 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".

Prosessrapport

61

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

Prosessrapport

62

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

Prosessrapport

63

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.

16.3.3 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

Prosessrapport

64

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.

16.3.4 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 16.3.5, “Dokumentasjonsfasen”.

Prosessrapport

65

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

Prosessrapport

66

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

Prosessrapport

67

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

Prosessrapport

68

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.

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

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

Prosessrapport

69

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

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

17.6 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

Prosessrapport

70

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.

Produktrapport

71

PRODUKTRAPPORT


Kull 2011

Produktrapport

72

Produktrapport

73

18. Forord


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.

Produktrapport

74

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.

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

Produktrapport

75

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

klassen 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 9.3.2 i prosessrapporten)

Skjermbilde 36: SOLID prinsippene

Produktrapport

76

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

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

Produktrapport

77

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.

22.1 Backend

Backenden består av en database som inneholder all dataen og et REST API med OData-

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

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

Produktrapport

78

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

mange relasjon mellom FixedErrorReport og ErrorLog.

Produktrapport

79

15.3.1 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 LastUpdated-

verdi.

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.

Produktrapport

80

22.4 Controllere

Som forklart i kapittel 15.3.3 i prosessrapporten har vi brukt Microsoft sitt nyutviklede Odata-

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

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

Produktrapport

81

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.


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

Produktrapport

82

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

Produktrapport

83

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.

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

Produktrapport

84

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.

Produktrapport

85

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.

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

Produktrapport

86

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.

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


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.

Produktrapport

87

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.

Produktrapport

88

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


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.

Produktrapport

89

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

Produktrapport

90

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.

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

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

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

Produktrapport

91

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.

Produktrapport

92

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.

Produktrapport

93

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.

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

Produktrapport

94

Testrapport

95

TESTRAPPORT


Kull 2011

Testrapport

96

Testrapport

97

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

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

Testrapport

98

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.

Testrapport

99

Testresultatene er av korte kommentarer. “OK” betyr at testen ble godkjent uten noen

kommentarer.

Test Google

Chrome

Mozilla

Firefox

Opera Internet

Explorer

Safari

Default tabeller OK OK OK OK OK

Local Storage OK OK OK OK OK

Lage nye error

tabell

OK OK OK OK OK

Lage nye error

tabell

OK OK OK OK OK

Lage nye

piechart

OK OK OK OK OK

Lage nye

timechart

OK Feil, grunnet

gammelt

nettleser

versjon

OK Feil, grunnet

gammelt

nettleser

versjon

Rammeverket

støtter ikke

denne

nettleseren

Funksjonaliteten

på filteret

OK OK OK OK OK

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.

Testrapport

100

Testrapport

101

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

inntrykk av

PureHub

Ryddig, fint og

oversiktlig

Oversiktlig og

behagelig

design

Oversiktlig og

ryddig. Simpelt.

Simpel og lett,

lett å forstå hva

den skal brukes

til.

Lag en ny error

tabell på 10 feil

Veldig lite rom

for feil.

Ganske lett, lite

rom for feil.

Forstod raskt

hvordan det

fungerte, lite

rom for feil.

Ok, veldig rett

fram.

Lag en ny usage

tabell med

oversikt over nye

usages etter 2014-

05-05

Veldig enkelt.

Vanskelig å

gjøre noe feil

her.

Fort gjort. Lite

rom for feil.

Veldig lett, er

ingen rom for

feil nesten.

Ok, veldig greit

med eksempelet

over datoen.

Modifiser på en

tabell

Rett fram,

akkurat som å

lage ny tabell

Forståelig,

ganske lik

hvordan du

lager ny tabell

Helt likt som

tidligere, veldig

lett.

Ok, helt lik som

tidligere.

Lag en sektor

diagram

Enkelt, simpel

og fin visning

av diagrammet.

Ok, ryddig og

fin diagram.

Ok, oversiktlig

og lett

forståelig

diagram.

Veldig lett og

oversiktlig

diagram.

Testrapport

102

Lag en linjegraf

over et år med

forskjellige farger

Ok, veldig

mange

alternativer for

farger her.

Ok, mange

farger å velge

mellom.

Ok, gøy med

mange valg av

farger.

Ok, oversiktlig

og fin graf.

Fiks en feil Ok, lett å forstå. Ok, bra at det

går fra rødt til

grønt.

Ok, lett å forstå

når feil er

fikset.

Ok, enkelt og

forståelig.

Er det noen

funksjonalitet du

savner?

Nei, den virker

veldig

komplett.

Virker som alt

er på plass.

Nei, den virker

helt ferdig.

Nei, alt er

ganske

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.

Testrapport

103

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.

Testrapport

104

Brukermanual

105

BRUKERMANUAL


Kull 2011

Brukermanual

106

Brukermanual

107

24. Forord


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.

Brukermanual

108

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.

Brukermanual

109

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.

Brukermanual

110

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.

Brukermanual

111

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

Brukermanual

112

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.

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

Brukermanual

113

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.

Brukermanual

114

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


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.

Brukermanual

115

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


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.

Brukermanual

116

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

4. "Backgroundcolor2 Dropdown" listen inneholder mange av de standarder fargene man

kan velge for hvordan bakgrunnen skal se ut, og fargen blender sammen med punkt 3.

Brukermanual

117

C. Når alle innstillingene er satt etter behov, trykker man på "Save Changes"-knappen og


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

Brukermanual

118

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.

Brukermanual

119

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.

Brukermanual

120

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.

Brukermanual

121

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

Brukermanual

122

Vedlegg

124

VEDLEGG

39. Kravspesifikasjon

39.1 Innledning

Prosjektet blir utført, som hovedprosjekt for dataingeniør og informatikk v/HIOA i samarbeid

med Syscom AS.

Oppgaven er å lage en hub for å holde oversikt over alle produktene, samle disse og

presentere det på en god måte.

Oppgaven skal bli utviklet hovedsakelig ved bruk av HTML, CSS og Javascript, EmberJS og

skal deretter bli lagt ut på Windows Azure websites. Backend av systemet skal bli lagd som et

REST API.

39.2 Om bedriften

Syscom AS er spesialister innen IT Service Management, IT Security og Client/Infrastructure

Management. De leverer kreative løsninger med fokus på mennesker, og har en

leveringsmetodikk som går ut på å sikre kundene optimal verdi av IT-investeringen. Syscom

ble etablert i 1987 av Ole Bryhn, og har kontorer i Oslo, Stockholm og København.

39.3 Bakgrunn for prosjekt

Syscom AS har mange kunder som bruker 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. Syscom AS hadde fra før allerede planlagt hvordan løsningen

skulle se ut, men hadde ikke tid eller kapasitet til å gjennomføre dette.

Vedlegg

125

39.4 Forord

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

39.5 Krav til oppgaven

Kravspesifikasjonen er beregnet for gruppemedlemmene, produkteieren i Syscom AS og

veilederne på skolen i HioA.

Løsningen skal tilby:

- Database som inneholder informasjon om error/exceptions

- Database som inneholder informasjon om brukerstatistikk

- Database som innehold informasjon om kunder

- Et API endepunkt for å sende inn errors/exceptions

- Et API endepunkt for å sende inn brukerstatistikk

- Et API endepunkt for å sende inn informasjon om kunder

- Muligheten til å filtrere på errors/exceptions, brukerstatistikk og kunder

- Kakediagram med oversikt over hvilke type feil som oppstår oftest

- Kakediagram som gir oversikt over kunder med flest feil

- Muligheten til å sortere informasjonen

- Logging av errors/exceptions som oppstår på selve løsningen vi utvikler

Videre under utviklingsprosessen ble det tilført flere krav som løsningen skulle tilby:

- Database som innehold informasjon om kunder

Vedlegg

126

- Et API endepunkt for å sende inn informasjon om kunder

- Graf over antall feil siste uken, måneden og året

- Kunne konfigurere sin egen forside for hva som skal vises

- Muligheten til å kunne melde inn om en error/exception er rettet på

Dette er kravene løsningen skulle tilby og tilsvarer de samme kravene som er nevn i

prosessrapporten i form av «backlogs». Videre var det ønske om å la oss inspireres av andre

API og tilby et lignende designmønster. Bortsett fra disse kravene var det veldig åpent for oss

å legge til flere funksjonaliteter som vi syntes ville være passende.

Tilleggskrav som vi valgte å tilføre oppgaven:

- Dynamisk filtrering av error/exceptions, brukerstatistikk og kundeinformasjon

- Dynamisk sortering av informasjon

- Endre farge på grafene

- Kunne legge til og slette informasjon om kunder

Vedlegg

127

40. Kildeliste

Syscoms hjemmeside

www.syscomworld.com/no

Pureservice hjemmeside

www.pureservice.com

EmberJS

www.emberjs.com

www.smashingmagazine.com

JQuery

www.jquery.com

FlotCharts

www.flotcharts.org

Visual Studio

www.visualstudio.com

Twitter Bootstrap

www.getbootstrap.com

StackOverflow

www.stackoverflow.com

Pluralsight

www.pluralsight.com/training

W3Schools

www.w3schools.com

http://www.syscomworld.com/no

http://www.pureservice.com/

http://www.emberjs.com/

http://www.smashingmagazine.com/

http://www.jquery.com/

http://www.flotcharts.org/

http://www.visualstudio.com/

http://www.getbootstrap.com/

http://www.stackoverflow.com/

http://www.pluralsight.com/training

http://www.w3schools.com/

Vedlegg

128

Wikipedia

www.wikipedia.com

Microsoft Odata, REST API

www.msdn.microsoft.com

Microsoft Azure

www.azure.microsoft.com

Balsamiq

www.balsamiq.com

Javascript error

www.developer.mozilla.org

Gliffy

www.gliffy.com

Twitter API

www.dev.twitter.com

Google API, Yoututbe API

www.developers.google.com

Facebook API

www.developers.facebook.com

http://www.wikipedia.com/

http://www.msdn.microsoft.com/

http://www.azure.microsoft.com/

http://www.balsamiq.com/

http://www.developer.mozilla.org/

http://www.gliffy.com/

http://www.dev.twitter.com/

http://www.developers.google.com/

http://www.developers.facebook.com/

WEB APPLICATION DEVELOPMENT – REST API &...

Documents

Transcript of WEB APPLICATION DEVELOPMENT – REST API &...