STUDENTARBEID Front-end webklient for Enoro AS 01.03.2015 Forprosjekt Kim René Merkesvik Anders Aalen Andrii Petrychak Lenkje til nettstad: http://studprosjekt.hisf.no/~15enoro Avdeling for Ingeniør og Naturfag HO2-300 Hovudprosjekt Vår 2015
STUDENTRAPPORT Postadresse: Postboks 523, 6803 Førde Telefon: 57 67 60 00 Fax: 57 67 61 00 www.hisf.no TITTEL Front-end webklient for Enoro AS PROSJEKTITTEL HO2-300 Hovudprosjekt RAPPORTNR. 01 TILGJENGE Open DATO 01.03.2015 TAL SIDER 22 Forfattarar Kim René Merkesvik Anders Aalen Andrii Petrychak OPPDRAGSGJEVAR ENORO AS ANSVARLEGRE RETTLEIAR Joar Sande Tormod Iversen SAMMANDRAG Hovudmålet med prosjektet er å utvikla ein front-end brukarklient som skal visuelt presentere strømforbruk og temperatur for kundane til kraftbransjen. SUMMARY The goal of a project is to develop a front - end software application, which is going to visually represent electricity-consumption for end-users. EMNEORD: HTML, CSS, JavaScript, API, JSON, AJAX,Database 2
Fagtermar AJAX API Back-End CSS Database DOM Front-end Git GUI HTML Java Java Swing JavaFX JavaScript JSON Asynchronous JavaScript and XML Application Programming Interface Server Cascading Style Sheets Strukturert samling av data Document Object Model Klient Versjonskontrollsystem Graphical User Interface HyperText Markup Language Objektorientert programmeringsspråk Grafisk brukargrensesnitt (GUI) Java Grafisk brukargrensesnitt (GUI) Java Et skriptspråk JavaScript Object Notation 3
Innhaldsliste 1SAMANDRAG...6* 2INNLEIING...7* 3PROBLEMSTILLING...8* 3.1$Bakgrunn$...$8* 3.2$Utgreiing$av$problemstilling$...$8* 3.3$Avgrensing$...$8* 3.4$Drøfting$av$løysing$...$8* 3.5$Val$av$løysing$...$9* 3.6*KONKLUSJON*...*10* 3.6.1$Hovudmål$...$10* 3.6.2$Delmål$...$10* 3.6.3$Tittel$...$10* 3.6.4$Rammebetingelsar$...$10* 3.7$Kritiske$Suksessfaktorar$...$10* 4WEBAPPLIKASJONSDLAG...11* 4.1$FrontMend$(Klient)$...$11* 4.1.1$HTML5$(Hyper$Text$Markup$Language$5)$...$11* 4.1.2$CSS$(Cascading$Style$Sheets)$...$11* 4.1.3$Javascript$...$11* 4.1.4$jQuery$...$11* 4.1.5$Bootstrap$...$12* 4.1.6$JSON$(JavaScript$Object$Notation)$...$12* 4.1.7$AJAX$(Asynchronous$JavaScript$and$XML)$...$12* 4.1.8$Highcharts$...$12* 4.2*BACK<END*(SERVER<SIDE)*...*13* 4.2.1$API$...$13* 4.2.2$Database$...$13* 5VERSJONSKONTROLL...14* 5.1$Git$...$14* 6RISIKOANALYSE...15* 6.1*RISIKOANALYSE*...*15* 6.2*FRÅVÆR*GRUNNA*SJUKDOM*...*15* 6.3*FEILBEREKNING*AV*TID*...*16* 6.4*SVIKT*I*KOMMUNIKASJON*...*16* 6.5*KONFLIKT*I*GRUPPA*...*16* 6.6*KONFLIKT*MED*OPPDRAGSGJEVAR*...*16* 6.7*KOMMUNIKASJONSSVIKT*MED*OPPDRAGSGJEVAR*...*16* 4
6.8*KONFLIKT*MED*ANDRE*FAG*...*16* 6.9*OVERARBEID*...*17* 6.10*NY*TEKNOLOGI*...*17* 6.11*KOMPATIBILITETSPROBLEM*...*17* 6.12*API*KOMMUNIKASJON*...*17* 6.13*TAP*AV*DATA*...*17* 6.14*MASKINVAREFEIL*...*17* 7BUDSJETT...18* 7.1*MILJØOMSYN*...*18* 8ORGANISERING...18* 8.1*OPPDRAGSGJEVAR*...*19* 8.2*STYRINGSGRUPPE*...*19* 8.3*PROSJEKTGRUPPA*...*19* 9PROSJEKTADMINISTRASJON...20* 9.1*MILEPELAR*...*20* 9.2*MØTEPLAN*...*20* 9.2.1$Gjennomførte$møter$...$20* 9.2.2$Planlagde$møter$...$20* 10.1*REFERANSEKJELDER*...*21* 10.2*FIGURAR*...*21* 10.3*TABELLAR*...*21* 10.4*VEDLEGG*...*21* 5
1Samandrag Dette er forprosjekt til vår Bacheloroppgåve som avgangsstudentar ved Høgskulen i Sogn og Fjordane, ingeniør elektro- og automatiseringsteknikk, våren 2015. Gruppa har fått i oppdrag å utvikle ei programvare, front-end web klient for Enoro AS i Dale i Sunnfjord. Enoro AS leverer leiande programvareløysingar for kundeinformasjon i Norge og i Europa. Bedrifta har vakse til ein av dei mest anerkjente leverandørane av programvare i energibransjen i Norge. Front-end er brukargrensesnittet som brukaren av programvara kommuniserer direkte med. I utviklinga av front-end, er grafisk design viktig for å gjere grensesnittet brukarvenlig. Brukaren skal oppleve at det er enkelt å finne fram og skaffe seg oversikt over tilgjengelege funksjonar i grensesnittet. Hovudmålet med prosjektet er å utvikla ein front-end som skal visuelt presentere strømforbruk og temperatur for kundane til kraftbransjen. Strømforbruk skal presenterast for minimum to forskjellige målepunkt frå databasen til Enoro AS. Vi skal hente temperaturprognose for målepunkta frå nettstaden Yr.no og presentere den prognosen saman med strømforbruket. Det bør vere mogeleg for brukaren å velje målar-id tilknytt energiselskapet eller adressa for punktet. Inngangsparameter for Yr.no sin API (Application Programming Interface) skal være GPS-koordinatar. Vêret som vert vist i Front-End skal vere i stand til å varsle brukaren om framtidig temperaturforandringar. Ved til dømes auka variasjon i vêrprognosen som kan føre til eit auka strømforbruk, skal programmet ha moglegheit for å varsle brukaren. Forprosjektet belyser ulike løysningar som var diskutert tidleg i prosjektfasen, men vi legg særleg vekt på løysninga som gruppa meiner egna seg best til føremålet. Forprosjekt skal bli godkjent frå styringsgruppa før ein jobbar vidare med hovudprosjektet. 6
2Innleiing I sjette og siste semester av ingeniørutdanninga skal alle studentane gjennomføre eit hovudprosjekt som utgjer 20 av totalt 180 studiepoeng. Hovudprosjektet er den avsluttande oppgåva ved Høgskulen i Sogn og Fjordane, Ingeniør elektroautomatiseringsteknikk. Gruppa har fått i oppdrag å utvikte ein front-end web klient for Enoro AS i Dale i Sunnfjord. Føremålet med forprosjektet er å belyse ulike løysningar som har blitt skissert opp i forprosjektsperioden, og til å gå inn på ei endeleg løysing som gruppa meiner er den beste løysinga for å utvikle ein front-end webklient. Forprosjektet skal fastslå om prosjektet er mogleg å gjennomføre innanfor gitte rammer og avklare moglegheitene prosjektet har. I kapittel 3 kan ein lesa om problemstillinga vår, derunder bakgrunn, avgrensing, drøfting og val av løysing, konklusjon og kritiske suksessfaktorar. I kapittel 4 opplyser vi om webapplikasjonslaga vi ynskjer å nytta, i kapittel 5 kan ein lesa om versjonskontroll. Risikoanalyse og inngåande beskriving av moglege risikoar finn ein i kapittel 6. Budsjett finn ein i kapittel 7, gruppeorganisering med oppdragsgivar, styringsgruppe og prosjektgruppe finn ein i kapittel 8. I kapittel 9 ligg alt som har med prosjektadministrasjon å gjera, samt referansar, figurar, tabellar og vedlegg. Rapporten skal kunne lesast av alle, men er av særlig interesse for dei som vil ha eit innblikk i korleis ein kan utvikle ein front-end frå grunnen av. 7
3Problemstilling 3.1Bakgrunn Oppdragsgjevaren til prosjektet er Enoro AS som er leiande innan programvareløysingar for kundeinformasjon i Norge, Norden og Europa. Enoro AS har som ønskje at det blir utarbeida ein front-end web-klient for kraftbransjen, med føremål å tilby kundane av kraftbransjen eit meir effektivt energiforbruk. 3.2Utgreiingavproblemstilling Oppdragsgjevar Enoro AS har ønskje om at det blir utarbeidd ein front-end for kraftbransjen. Føremålet med front-enden klienten er at kundar av kraftbransjen skal kunne nytte denne for å få presentert straumforbruket sitt, samtidig som dei får vita den kommande prognose for utetemperaturen. Strømforbruket skal presenterast for minimum to forskjellige målepunkt frå databasen til Enoro AS. Det skal hentast temperaturprognose for målepunkta frå Yr.no og presentere desse saman med strømforbruket. Det bør vere mogeleg for brukaren å velje målepunkt ved å skrive unik ID for målepunktet, eller adressa for punktet. Inngangsparameter for yr sin API skal være GPS koordinatar. 3.3Avgrensing Frå Enoro AS sin database skal vi hente informasjon om straumprisar og forbruk. Frå Yr.no sine nettstadar skal vi henta informasjon om vêret no og vêrprognosane fram i tid. 3.4Drøftingavløysing Vi skal sende og mota data frå ein database og presentere dei data visuelt på ein skjerm. Det finnast fleire mogelege måtar å hente data frå ein database, samt fleire måtar å presentere data på ein skjerm. Vi har diskutert metodar med Enoro AS for mogelege løysingar for å presentere data frå deira database. Enoro AS gav oss mogelegheita til å velje fritt kva slags teknologiar som skal nyttast i dette prosjektet så lenge vi brukar data frå deira database. Vi hadde fleire mogelege løysningar for denne utfordringa. 8
Vår første løysning var å få data direkte frå databasen med grunnleggande databasespråk. Enoro AS sine dataopplysningar ligg lagra i ein type SQL-database, og det er mogeleg å hente data frå databasen ved hjelp av SQL- spørjing og presentere den vidare med høg-nivå språk, for eksempel Java. Det var då naturleg å velje Java og MySQL fordi vi har brukt dette språket under våre studiar. Under diskusjonen dukka det opp fleire løysingar. Enoro AS hadde API (Application Programming Interface) som brukar REST-basert kommunikasjon. I så fall kunne klienten sende http-førespurnad med nødvendige parameter til Enoro AS sin API og få dei naudsynte data i, for eksempel JSON-format. På klient-sida ble de vurderte Java som programmeringsspråk og JavaFX (GUIbibliotek til Java) som GUI. 3.5Valavløysing Vi konkluderte vi med at den mest hensiktsmessige løysinga var å bruke Enoro AS sin eksisterande API som mellomstasjon mellom databasen og front-end klient fordi denne løysinga hadde fleire store fordelar som: database-strukturen er skjult bruken av API gjer fleksibilitet av datapresentasjon, fordi data i JSON format kan analyserast og visast på universell måte. ein treng ikkje å lære grunnleggjande databasespråk for å utvikle systemet. Vi kan konsentrere oss om klientsida. Vidare valte vi ei løysing med HTML5 som programeringspråk. Årsaka er at front-end web løysingar er raskt veksande, og at HTML5 i praksis er vorte standard i front-end web-utvikling. Ei anna positiv side med eit web-grensesnitt er at det er mange "open source" bibliotekar, som jquery og Bootstrap som forenklar utviklinga av ein frontend. Vi vil også bruka HighCharts for å presentera data i diagram. HighCharts er eit Javascript-bibliotek, utvikla av det norske selskapet HighSoft i Vik i Sogn. 9
3.6Konklusjon I dette kapittelet vil vi framstilla kva som er målet med prosjektet og utgreia kva som skal gjerast. 3.6.1Hovudmål Vi skal laga ein front-end klient for Enoro som kan nyttast for å visa straumforbruk og temperatur for kundane til kraftbransjen. 3.6.2Delmål Vi vil undersøke kva rammeverk eller teknologiar bør leggast til grunn for framtidas front-end løysningar for Enoro AS sine kundar, og korleis den kan nyttast for å auke brukarvenlegheita for brukarane. Vi vil utvikle og teste ein prototype. Vi vil lære å bruke MS Project som ein del av prosjektstyringa. 3.6.3Tittel Tittelen på prosjektet er "Front-end webklient for Enoro AS". 3.6.4Rammebetingelsar Enoro AS gav oss mogelegheita til å velje fritt kva slags teknologiar som skal nyttast i dette prosjektet så lenge vi brukar data frå deira database. 3.7KritiskeSuksessfaktorar God og riktig bruk av prosjektstyringsverktøy er avgjerande for eit vellykka prosjekt. Arbeidet med prosjektet kan verte tidskrevjande. Gruppa vil bruke MS Project som eit styringsverktøy. Vi har fått frie tøyler hjå oppdragivar til å velje teknologien sjølv, noko som gjer at dette kan vera ein kritisk suksessfaktor. 10
4WebapplikasjonsDlag 4.1FrontDend(Klient) Front-end er sjølve webapplikasjonen som brukarane betjener og kommuniserer med. Front-end kommuniserer med Enoro AS sin back-end via ressursane som ligg i deira API. Front-end er skrive i HTML, CSS og Javascript og brukar rammeverket til jquery. I utviklinga av front-end er grafisk design viktig for å lage eit brukarvennleg grensesnitt. Det er viktig at brukaren opplever at det er enkelt å finne fram og å skaffe seg oversikt over tilgjengelege funksjoner i grensesnittet. [1] 4.1.1HTML5(HyperTextMarkupLanguage5) HTML er eit felles markeringspråk for alle nettsider. HTML fortel nettlesaren korleis strukturen og omrisset av nettsida ser ut. HTML5 er ein vidareutvikla versjon av HTML for auka bruk av multimedia på nettet. HTML kodane kallast tagger (tags), som fortel om teksten er ei overskrift, vanleg tekstavsnitt, tabell, punktliste eller ei lenke. Taggane for tekstens funksjon refererer til eit stilark (stylesheet) som styrer oppsett og strukturen til dokumentet. [2] 4.1.2CSS(CascadingStyleSheets) CSS er stilark språk som definerer utsjånaden til eit HTML dokument. Utgangspunktet for CSS er at ein skal spare arbeid med utvikling av store nettsider, der fonter, fargeinformasjonen og animasjon som blir lagt til kvar enkelt side blir ein lang og kostbar prosess. CSS-informasjonen ligg ofte i ei eiga fil, der ein kan endre utsjånaden av heile nettstader ved å endre bare ein fil. [3] 4.1.3Javascript Javascript kom til då etterspurnaden om dynamiske nettsider var etterlengta. JavaScript gjer det mogeleg å konstruere nettsidene med dynamisk oppførsel og animasjon, som gjer brukarvenleg og auka oppleving (respons) for brukaren. 4.1.4jQuery JQuery er eit JavaScript bibliotek utvikla for å forenkle front-end utvikling. jquery sin syntax gjer det lettare å navigere i eit dokument, velje DOM-element, opprette animasjonar, handtere handlingar og utvikle Ajax applikasjonar. JQuery gjer det også mogeleg å lage programvareutvidingar til JavaScript biblioteket. [4] 11
4.1.5Bootstrap Twitter Bootstrap er for tida ein av dei mest populære og nytta front-end rammeverk. Det er eit gratis og gjennomtesta rammeverk for raskare og enklare webutvikling. Bootstrap er laget av Twitter som brukte det til å forbetre utviklinga av det populære nettsamfunnet Twitter. Dei fant ut at andre kunne ha bruk for rammeverket til å lage fine websider og web-applikasjonar. Løysinga er kompatibel med dei nyaste versjonane av dei store nettlesarane. Ein brukar HTML, CSS og Javascript til utvikling av brukargrensesnitt for knappar, skjema, navigasjon og andre grensesnittkomponentar. [5] 4.1.6JSON(JavaScriptObjectNotation) JSON er ein enkel open tekstbasert standard for datautveksling. JSON er opphaveleg basert på ei undergruppe av JavaScript, men er uavhengig av dette eller andre programmeringspråk. Det at JSON brukar framgangsmåtar som er kjent for programmeraren som har bakgrunn frå andre programmeringspråk gjer det til eit ideelt datautvekslingsspråk. JSON blir brukt først og fremst til å overføre data mellom ein server og ein web-applikasjon, som eit alternative til XML. Til bruk i AJAXapplikasjonar er JSON svært godt eigna. [6] 4.1.7AJAX(AsynchronousJavaScriptandXML) AJAX er laga for å gje web-applikasjonar ein raskar og meir responsiv brukar - opplevelse. Dette vert gjort ved at websida i bakgrunnen utvekslar informasjon med serveren. Dermed må ein ikkje laste heile web-sida når brukaren gjer ei forandring. Brukaren vil gjerne ikkje merke denne informasjonsflyten. Dette gjev ei betre brukaroppleving. Andre sider som ikkje bruker AJAX må gjerne laste heile websida på nytt når det vert gjort forandringar, noko som tek lenger tid. [7] 4.1.8Highcharts Highcharts er ein enkel måte å lage interaktive diagram til webapplikasjonar. Highcharts er eit JavaScript-bibliotek som fungerer på alle moderne nettlesarar. Det er ikkje nødvendig å kjøpe lisens for å bruke Highcharts på private heimesider, skulesider eller ikkje-kommersielle websider. Det kan gjerast endringar i kildekoden, og dette gjev rom for personlige modifikasjonar og fleksibilitet. Highcharts bygger på teknologiar som finnast i nettlesaren frå før og ein treng ikkje å installere programtillegg som Flash eller Java. Det trengst heller ikkje 12
nokon installasjon på webserveren, sidan Highcharts bruker andre rammeverk som jquery, MooTools eller Prototype. Highcharts er utvikla av Highsoft AS som er lokalisert i Vik i Sogn. [8] 4.2BackDend(ServerDside) Back-end er serversida som er grensesnittet mellom front-end og databasen. Det som inngår i back-end er det som skjer bak kulissane i ein web-applikasjon. Det vil seie alle handlingane som vert gjort før det kjem til nettlesaren din. Eit vanleg oppsett for ein back-end er ein web server, ein applikasjon og ein database. [9] 4.2.1API API er eit programmeringsgrensesnitt som gjer det mogeleg å overføre informasjon automatisk mellom ulike program som er sett opp for å kommunisere med kvarandre. Ein av fordelane er at eksterne programmerarar kan lage applikasjon og tilføre ekstra tenester på ein enklare måte frå denne forbindelsen. Det er vanlig at programvareutviklarane lagar API til sine programsystem. [10] 4.2.2Database Ein database er ei strukturert samling av data. Det vert som regel brukt eit databasesystem som heiter DBMS (Database Management System) til å administrere ein database. Databasesystemet sørgjer for å implementere ein eller fleire databasar og utfører visse tenester etter førespurnad frå ein klient som er satt opp til å sende førespurnad til databasesystemet. Dette kan være eit eksternt program. [11] 13
5Versjonskontroll 5.1Git Versjonskontrollsystem er programvare som held kontroll på versjonar av datafiler og endringar, gjerne med full historikk med moglegheiter for å kommentere endringar. Git er eit verktøy for versjonskontroll og kodedeling mellom programvareutviklara. Det er lagt vekt på fart, dataintegritet og støtte for distribuerte system. Ein kan lagra heile historikken for koden og sjå korleis han har utvikla seg. Dette gjer det lettare å samarbeida, fordi kvar utviklar kan sjå heile utviklingshistorikken og ein unngår kodekonflikt. 14
6Risikoanalyse 6.1Risikoanalyse Risikoanalyse har som mål å gje eit risikobilete ved å kartlegge og beskrive risikoen til prosjektet. Risikofaktor = Sannsyn * konsekvens. Første steg i ein risikoanalyse er å kartlegge mogelege initierande hendingar. Deretter vil vi vurdere sannsynet for at desse hendingane inntreff og konsekvensen dersom dei inntreff. Gruppa vil sette i verk mindre tiltak for å minske risikofaktoren. Dette skal minka sannsynet for at dei initierande hendingane inntreff, samt minka at hendingane resulterer i større konsekvensar for prosjektet. Risiko Sannsyn Konsekvens Risikofaktor Fråvær grunna sjukdom 3 3 9 Feilberekning av tid 3 3 9 Kommunikasjonssvikt i gruppe 1 4 4 Kommunikasjonssvikt med oppdragsgjevar 1 4 4 Konflikt i gruppa 1 4 4 Konflikt med oppdragsgjevar 1 4 4 Konflikt med andre fag 2 2 4 Overarbeid 2 3 6 Ny teknologi 3 3 9 Kompatibilitetsproblem 2 6 12 API kommunikasjon 1 6 6 Tap av data 1 6 6 Maskinvarefeil 1 6 6 Tabell1Risikoanalyse 6.2Fråværgrunnasjukdom Sjukdom kan ramme alle i gruppa, men vi ser ikkje at dette skal få store konsekvensar for prosjektet. Vi har mogelegheiter til å jobbe sjølvstendig med rapport og programmeringa. Vi er heller ikkje avhengig av anna utstyr enn eigne datamaskiner. Gruppemedlemane er involvert i alle delane av prosjektet sjølv om oppgåvene er fordelt ulikt mellom studentane. 15
6.3Feilberekningavtid Arbeid med prosjekt er ofte tidskrevjande, og det er vanskeleg å berekne kor lang tid kvar del av prosjektet tek. Gruppa brukar MS Project som eit styringsverktøy for å halde gjevne tidsrammer. 6.4Sviktikommunikasjon Gruppa jobbar mykje sjølvstendig, så det er viktig med god kommunikasjon. Vi har planlagt gruppemøter og Skypemøter. Kommunikasjon via e-post, telefon og sosiale mediar er også nytta. Vi har prøvd symphonical.com for å organisere oppgåvene. Men vi opplever ikkje at Symphonical gjev ein oversikt slik som det var meint. Gruppa har sett at det er nødvendig å bruke MS Project, der ein tileigna seg god oversikt over oppgåvene som skal gjerast og kven som er ansvarlig for at oppgåvene blir gjort. Ein får også eit bilete over kor langt ein er komen i prosjektet. Til fil-deling nyttar vi Dropbox. 6.5Konfliktigruppa Konflikt mellom gruppemedlemmane kan oppstå. Det kan vere konfliktar om arbeidsoppgåver og løysingar av sjølve prosjektet. Konfliktar er viktig å løyse så raskt som mogeleg, slik at det ikkje går over lengre tid. Gode løysingar der alle gruppemedlemane er einige, er viktig å prøve å få til. Gruppa jobbar mot felles mål. Gruppa er einige om ein gruppeavtale som vi kan gå tilbake på. Det er viktig å opptre sakleg og profesjonelt og at private konfliktar blir halden utanfor prosjektet. 6.6Konfliktmedoppdragsgjevar Vi har av oppdragsgjevar fått forme oppgåvene ganske fritt og bedrifta har vore imøtekomande med kompetanse og rettleiing. Vi trur ikkje det vil bli nokon konflikt med oppdragsgivar sidan vi har vore med på å utarbeide problemstillingar sjølv. Det er svært uheldig og lite ønskelig om det skulle oppstå ei konflikt. Det må i så fall løysast raskt og god dialog vil bidra til å redusere denne risikofaktoren. 6.7Kommunikasjonssviktmedoppdragsgjevar Ein av gruppemedlemane har i semesteret "styrt praksis" hos oppdragsgjevar. Det bidrar til ein god kommunikasjon med bedrifta. Gruppa opplever god dialog med oppdragsgjevar og håpar den gode dialogen vil forsette vidare i prosjektet, også etter at perioden for styrt praksis er over. 6.8Konfliktmedandrefag Det er mykje sjølvstendig arbeid, og fellesarbeid er planlagt slik at det ikkje kjem i konflikt med andre fag. 16
6.9Overarbeid Gruppemedlemar som føler seg overarbeidd eller dersom nokon føler ei større belasting i periodar, må andre gruppemedlemer komme inn å hjelpe og avlaste med oppgåver. Ein god prosjektplan i MS Project skal minske risikoen for at dette skal føre til større konsekvensar. 6.10Nyteknologi Gruppemedlemane har ulike bakgrunnar. Nokon kjenner betre til teknologien vi skal bruke, enn andre i gruppa. For at alle gruppemedlemane skal ha / få kjennskap og forståelse for prosjektet, har vi brukt tid på å lære web-programmering på www.codecademy.com. Ein ingeniør må ofte tileigne seg ny kunnskap, og dette blir gjerne endå vanlegare i framtida. 6.11Kompatibilitetsproblem I prosjektet har gruppa forskjellige operativsystem på våre eigne maskiner. To av oss bruker OS X og ein bruker Windows. Dette treng ikkje å føre til nokon kompatibilitetsproblem mellom program og plattform, men kompatibilitetsproblem er heller ikkje unaturleg i eit programmeringsprosjekt. 6.12APIkommunikasjon Vi har fått god hjelp av Enoro AS med API kommunikasjon. 6.13Tapavdata Prosjektrapporten blir skrive med løysing frå Microsoft. Vi brukar Word og nettstaden OneDrive, der medlemar kan utarbeide rapporten i fellesskap. Vi tar backup av rapporten kvar dag. For å ha system på programmeringa, brukar vi Github for versjonskontroll og backup. Andre prosjektfiler deler vi i Dropbox som har innebygd funksjon for backup. 6.14Maskinvarefeil Det kan bli ganske kostbart å erstatte eiga datamaskin i tilfelle den blir øydelagt, men vi ser på risikoen for at maskiner blir øydelagt som liten. 17
7Budsjett Prosjektet har ikkje noko store kostnader sidan HTML, CSS, JavaScript, JSON, AJAX er gratis og open for alle. 7.1Miljøomsyn Vi ser ikkje at det vert knytt noko større miljørisiko til dette prosjektet. Prosjektet krev minimalt med papir. Rapporten, programvarene og det gruppa utviklar er bits og bytes. Det skal heller ikkje skrivast ut nokon rapport. Rapporten vert levert på PDF format. Gruppa har hatt ein tur til Dale i planleggingsfasen av prosjektet. 8Organisering Organiseringa av prosjektet består av tre nivå. Vi har oppdragsgjevar på toppen, under har vi styringsgruppa og prosjektgruppa. Oppdragsgivar* Enoro*AS* Styringsgruppe* Joar*Sande* *Prosjektansvarleg*HISF* Tormod*Iversen* *Kontaktperson*Enoro* Sven*Andre*Naustdal* *Kontaktperson*Enoro* Prosjektgruppe* Kim*René*Merkesvik* *Prosjektleiar* Anders*Aalen** Andrii*Petrychak** Figur1Organisasjonskart 18
Prosjektgruppa: Kim René Merkesvik, kimrm@stud.hisf.no Anders Aalen, andersaa@stud.hisf.no Andrii Petrychak, andriip@stud.hisf.no Styringsgruppe: Joar Sande, joar.sande@hisf.no 8.1Oppdragsgjevar Oppdragsgjevar til prosjektet er Enoro AS. Enoro er lokalisert i Dale i Sunnfjord og leverer leiande programvareløysingar for kundeinformasjon (KIS), Smart Grid og Market interaskjon for energibransjen i Norge, Norden og Europa. I over 20 år i energibransjen har Enoro AS vakse til å verte ein av dei mest anerkjente leverandørane av programvare i Norge. [12] 8.2Styringsgruppe Rettleiarane og kontaktpersonar frå Enoro AS utgjer styringsgruppa, som fattar alle viktige vedtak i prosjektet. Kontaktinformasjon for styringsgruppa: Joar Sande, joar.sande@hisf.no 57 72 26 29 / 41 44 05 91 8.3Prosjektgruppa Prosjektgruppa består av tre avgangsstudentar frå automasjon ved HISF-AIN våren 2015. Studentane hadde ulik bakgrunn før dei byrja på HISF hausten 2012. Kim René Merkesvik er valt til prosjektleiar for gruppa og han har ansvaret for at arbeidsoppgåvene vert fordelt mellom gruppemedlemane, kalle inn til gruppemøter og sørgje for framdrift etter prosjektplanen. 19
9Prosjektadministrasjon Gruppemedlemane tek fag parallelt med prosjektet. Andrii tek "styrt praksis" hos Enoro AS i Dale i Sunnfjord. Tidsforbruket til prosjektgruppa har vore jamt fordelt mellom gruppemedlemmane. Dei planlagde møtene kan forandrast dersom prosjektgruppa ytrar ynskje om det. 9.1Milepelar* I førekant av prosjektet, blei det gjevet rammer for prosjektet. Prosjektstart* Måndag 05.01.2015 Prosjektbeskrivelse* Fredag 16.01.2015 Forprosjektrapport* Søndag 01.03.2015 Midtvegspresentasjon* Onsdag 08.04.2015 Innlevering*av*sluttrapport* Fredag 22.05.2015 Presentasjon*m/plakat* Onsdag 27.05.2015 Nettsida ferdigstillast* Fredag 05.06.2015 Tabell2Milepelar 9.2Møteplan 9.2.1Gjennomførtemøter* Dato Kl. Møtestad Type 19.01.2015 12.00 Enoro Informasjonsmøte 05.02.2015 12.30 HISF Statusmøte 24.02.2015 21.00 Skype Statusmøte Tabell3Gjennomførtemøter 9.2.2Planlagdemøter* Dato Kl. Møtestad Type 05.03.2015 12.30 Statusmøte 24.03.2015 12.30 Statusmøte 09.04.2015 12.30 Statusmøte 23.04.2015 12.30 Statusmøte 07.05.2015 12.30. Statusmøte 21.05.2015 12.30 Statusmøte Tabell4Planlagdemøter 20
10Lister 10.1Referansekjelder [1]*Ivan*Codesido.*(2009,*Sep.)*theguardian.*[Online].* http://www.theguardian.com/help/insideguardian/2009/sep/28/blogpost* [2]*Ivar*M*Lister*og*Eirik*Rossen.*(2009,*Mar.)*Store*Norske*Leksikon.*[Online].* https://snl.no/html* [3]*w3schools.*http://www.w3schools.com.*[Online].* http://www.w3schools.com/css/css_intro.asp* [4]*jquery.*[Online].*http://jquery.com* [5]*Internett*Studio*AS.*(2012,*Sep.)*Internett*Studio*AS.*[Online].* http://www.istudio.no/aktuelt/63<twitter<bootstrap* [6]*Introducing*JSON.*[Online].*http://json.org* [7]*w3schools.com.*[Online].*http://www.w3schools.com/Ajax/ajax_intro.asp* [8]*Highsoft*AS.*HIGHCHARTS.*[Online].* http://www.highcharts.com/products/highcharts* [9]*Josh*Long.*(2012,*Sep.)*teamtreehouse.blog.*[Online].* http://blog.teamtreehouse.com/i<dont<speak<your<language<frontend<vs<backend* [10]*e<conomic*norge.*e<conomic.*[Online].*https://www.e< conomic.no/regnskapsprogram/ordliste/api* [11]*Finn*Haugen,*WEBPROGRAMMERING.*7005,*Trondheim:*Tapir*Akademisk*Forlag,* 2003.* [12]*Framtidsfylket.no.*(2015,*Feb.)*[Online].* http://framtidsfylket.no/naeringsklynger/ikt/enoro<as/* 10.2Figurar FIGUR*1*ORGANISASJONSKART*...*18* 10.3Tabellar TABELL*1*RISIKOANALYSE*...*15* TABELL*2*MILEPELAR*...*20* TABELL*3*GJENNOMFØRTE*MØTER*...*20* TABELL*4*PLANLAGDE*MØTER*...*20* 10.4Vedlegg* Avtale*internt*i*gruppa...Vedlegg*1* Timelister*hittil*i*prosjektet....Vedlegg*2* Møtereferat*1... Vedlegg*3* Møtereferat*2......Vedlegg*4* Møtereferat*3... Vedlegg*5* Gant*Skjema.. Vedlegg*6* 21
Vedlegg 1 Gruppeavtale Prosjektgruppa er einig om følgjande : 1. Den formelle leiarjobben skal prosjektleiar ta seg av. Han/ho har ansvaret for at arbeidsoppgåvene vert fordelt mellom gruppemedlemmene, innkalle til gruppemøter og sørgje for framdrift etter prosjektplan. Han/ho skal informere dei som har vore borte om kva som har hendt i gruppa sidan sist. 3. Alt arbeid skal leverast til avtalte fristar. Dersom noko ikkje vert levert til rett tid, må det oppgjevast ein god grunn for det. 4. Dersom ein medlem ikkje møter opp på gruppemøta, eller ofte let vere å levere eller leverer for seint, kan dei andre i gruppa bestemme at vedkommande ikkje lenger er medlem, og stryke namnet til vedkommande på svaret/rapporten. 5. Vi skal forsøke å bli einige gjennom diskusjon, men dersom det ikkje går, må vi halde avstemming. Gruppeleiaren har då dobbeltstemme dersom det er stemmelikheit. 6. Det er lov å kritisere arbeidsmåten til den enkelte medlemmen av gruppa, men vi skal seie frå på ein skikkeleg måte. 7. Alle har ansvar for gjennomføring av prosjektet. Dersom arbeidet i gruppa ikkje fungerer, må vi saman gå tilbake til desse reglane og finne ut kva som var gale med dei, og korleis dei kan gjerast betre. 8. Alle skriv sin del av arbeidet ved hjelp av tekstbehandlingsprogram og menyval for marg, linjeavstand og avsnitt. Rapport- og tekstbehandlingsarbeid vert fordelt så likt som mogleg i gruppa. Dato 29.01.2015 KIM RENÉ MERKESVIK ANDERS AALEN ANDRII PETRYCHAK 22
Vedlegg 2 Timelister forprosjekt Møter Andrii Anders Kim René Veke 2 Veke 3 1 1 1 Veke 4 2 4 4 Veke 5 Veke 6 2 2 2 Veke 7 1 1 1 Veke 8 3 3 3 Veke 9 1 1 1 Rapport Adm. Andrii Anders Kim René Veke 2 Veke 3 2 1 1 Veke 4 Veke 5 Veke 6 Veke 7 1,5 4 Veke 8 9 29 31 Veke 9 5 36 38 Codecademy.com Andrii Anders Kim René Veke 2 Veke 3 19.5 Veke 4 22.5 Veke 5 5,5 5 Veke 6 20,5 20 Veke 7 7 11 Veke 8 Veke 9 Front-end Utv. Andrii Anders Kim René Veke 2 Veke 3 Veke 4 Veke 5 22 Veke 6 14 Veke 7 6 Veke 8 18 Veke 9 13,5 Totalt 143 115 118 23
Vedlegg 3 Møtereferat frå Enoro Hovudprosjekt 2015 Dato 19.01.2015 Klokkeslett 12.00 Møtestad Enoro AS, Dale i Sunnfjord Til stades Tormod Iversen Sven Andre Naustdal (informant) Kim René Merkesvik Anders Aalen Andrii Petrychak (informant) Referent Kim René Merkesvik Neste møte 05.02.2015 Sakliste 1. Informasjon om hovudprosjekt. Ved siste semester ved Høgskulen i Sogn og Fjordane skal studentane gjennomføre et hovudprosjekt. Høgskulen oppmodar studentane til å finne ekstern oppdragsgivar, for å gjera prosjektet mest mogleg verkelegheitsnært. Vi vart invitert til Enoro for eit informasjonsmøte om ei eventuell oppgåve. Anders og Kim René vart opplyst om prosjektet av Utviklinsdriketør Sven André Naustdal og Andrii. Sidan Andrii har styrt praksis hos Enoro AS har han vore med på å utforme idéen til prosjektet. Ideen for dette prosjektet er å laga eit front-end system som viser eit visuelt temperatur og strømforbruk. Strømforbruket frå minimum 2 forskjellige målepunkter. Målepunktet skal ha ein temperatur prognose. Systemet skal gi brukaren ein visuell tilbakemelding. 24