BACHELORPROSJEKT. Mobilapplikasjon for Norges Idrettshøgskole og oppmøteregistrering

Transkript

1 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo PROSJEKT NR. TILGJENGELIGHET Åpen Telefon: Telefaks: BACHELORPROSJEKT HOVEDPROSJEKTETS TITTEL Mobilapplikasjon for Norges Idrettshøgskole og oppmøteregistrering DATO ANTALL SIDER / BILAG 84 PROSJEKTDELTAKERE Håkon Planke Holm Martin Ramstad Arne Kristoffer Solberg s s s INTERN VEILEDER Ismail Hassan OPPDRAGSGIVER Norges Idrettshøgskole KONTAKTPERSON Willy Jensen SAMMENDRAG Mobilapplikasjonen er laget for å være ett nyttig hjelpemiddel for studenter og ansatte på Norges Idrettshøgskole. Den ble laget i to deler da Norges Idrettshøgskole gjerne ville ha en tilleggsfunksjon der de lettere kunne registrere oppmøte på obligatorisk undervisning. 3 STIKKORD Mobilapplikasjon Oppmøteregistrering Modulær

2 Innhold i rapporten: Innledning Prosessrapport Produktrapport Brukerveiledning Vedlegg 2

3 Innledning Forord Denne sluttrapporten er utarbeidet i forbindelse med hovedprosjekt våren 2015 ved Høgskolen i Oslo og Akershus. Rapporten omhandler utviklingen av en mobilapplikasjon og oppmøteprosjekt for studenter og ansatte ved Norges idrettshøgskole som gir de nyttige lenker og nyheter om hva som skjer på Norges Idrettshøgskole. Rapporten har blitt utarbeidet av: Arne Kristoffer Solberg - s Håkon Planke Holm - s Martin Ramstad - s Mobilapplikasjonen er utviklet for IKT-avdelingen på Norges Idrettshøgskole (senere kun omtalt som NIH). Prosessrapporten gir en beskrivelse av utviklingen av prosjektet, mens produktdokumentasjonen går mer inn på det tekniske ved det vi har produsert. Leserveildening Denne innledningen gir en kort oversikt over hva sluttrapporten inneholder, og en introduksjon til oppgaven. Første del av produktrapporten anbefales å lese for å få en oversikt over funksjonalitet i det utviklede produktet. Andre halvdel av produktrapporten beskriver hvordan funksjonaliteten er implementert, med andre ord, en mer teknisk beskrivelse. 3

4 Prosessrapporten beskriver utviklingen av prosjektet underveis i prosjektperioden, utfordringer vi har taklet underveis og drøfting rundt forbedringspotensial. Kort beskrivelse NIH-appen er en applikasjon laget for å gi studenter på NIH nyttige lenker til funksjoner de kan få bruk for og nyheter om det som skjer på NIH. NIH-appen lar brukere mulighet til å sjekke nyheter, mail og timeplan samt se timer som er obligatoriske hvor mange prosent brukeren har vært til stede. All funksjonalitet er dokumentert i kravspesifikasjonen som kan finnes i vedlegg. Prosjektet ble noe innviklet og på grunn av en ønsket tileggsfunksjon bestemte vi at det ville være mest fornuftig å dele prosjektet i to. Oppmøteregistreringsdelen var ønsket av NIH for å lette arbeidet med registrering av studenters oppmøte på obligatorisk undervisning da det per i dag ble gjort manuelt. Bakgrunn Siden applikasjoner er blitt veldig populært i dagens samfunn, var dette noe NIH ønsket seg da vi ble intervjuet. Applikasjonen skulle ha et lignende design som Instabart. Vi ble inspirert av deres design som vi mente vil fungere godt i vår applikasjon. Der det var også et ønske om en oppmøteregistrering, for obligatoriske timer. 4

5 Prossessrapport NIH-App Gruppe 9 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo,

6 Innholdsfortegnelse 1. Forord Bakgrunnen for oppgaven Gruppen Oppdragsgiver Oppgaven Planlegging Forprosjekt Kravspesifikasjonen Fremgangsmåte Design Arbeidsmetodikk Scrum og smidig systemutvikling Sprints Brukertesting Prosjektstyringsverktøy Valg av teknologi ASP.NET/C# Html og Css Javascript Arkitektur Utviklingsprosess Sprint1: Oppstartsfase Sprint2: Webside og mobilapplikasjon Sprint 3: Oppmøteregistrering Sprint 4: Dokumentasjon og finpuss Brukertesting Konklusjon Bruken av scrum og samarbeid i gruppe Samarbeid i gruppe Evaluering av tiltak for å redusere risiko Problemer underveis og hva vi prioriterte bort Forslag til fremtidig utvikling/forbedring

7 7

8 1. Forord Dette er prossessrapporten vi har laget for hovedprosjektet vårt i 2015 ved Høgskolen i Oslo og Akershus. Den beskriver prossessen som ble gått gjennom med utviklingen av NIH-Appen. Appen gir en enkel måte for studenter ved NIH å finne frem til nyttige verktøy og lenker de kan ha nytte av i sin studenthverdag, samt en lettere måte for forelesere å registrere oppmøte i obligatorsk undervisning enn det som finnes per i dag. Denne prossessrapporten skal forklare mer om bakgrunnen for hovedprosjektet, arbeidmetoden som ble benyttet, utfordringer og vurderinger som ble gjort og hva vi til slutt endte opp med. Vi kommer til å gjøre en antakelse om at en del av uttrykkene er kjent for leserne og forklare det vi mener er nødvendig. 2. Bakgrunnen for oppgaven Denne delen forklarer noe av bakgrunnen for oppgaven, gruppen som jobbet med den, hva oppgaven bestod av og hvem den ble utført for (oppdragsgiveren). 2.1 Gruppen Gruppen som jobbet med dette hovedprosjektet var tre dataingeniørstudenter på Høgskolen i Oslo og Akershus. Vi ble kjent i begynnelsen av studiet og har hatt godt samarbeid i tiden vi har gått på HiOA. Tidlig i 2014 bestemte vi oss for å danne gruppe og begynte å se etter mulige oppgaver vi kunne ha som hovedprosjekt. Det var en del spredt kunnskap i gruppen, da vi ikke alle hadde tatt de samme fagene, men det så vi som en styrke da vi kunne bidra på vår egen måte. To av oss jobbet sammen på prosjekt tidligere, men vi hadde alle jobbet sammen under blant annet eksamenforberedelser og er med i samme studentforening. Det var kun en i gruppen som allerede hadde kunnskaper om.net-rammeverket de andre måtte da lese seg opp på de forskjellige rammeverkene som vi behøvde for å utføre prosjektet. 2.2 Oppdragsgiver 8

9 Vi fant en oppgave for Norges Idrettshøgskole, der de ønsket seg en mobilapplikasjon. De har ikke hatt noe slikt tidligere, men var imponert over en mobilapplikasjon som var utviklet for NTNU og som heter Instabart. Norges Idrettshøgskole er en høgskole som driver med forskning og utdanning innen idrettsvitenskap. Vi fant oppgaven til hovedprosjekt på HiOA sine sider, der de listet opp en del potensielle oppdragsgivere og oppgaver. NIH sitt oppdrag virket interessant da det innebar å lære om en del nye programspåk, teknologier og utviklingsverktøy som vi ikke tidligere hadde vært borti. Vi avtalte et intervju med NIH og fikk i stand en avtale om at vi skulle utvikle mobilapplikasjonen for de, med en ganske stor tilleggsoppgave spesielt tilpasset deres behov. Vi tok kontakt med NIH via mail høsten 2014, ble invitert til et intervju og fikk deretter tilbud om å utføre prosjektet for dem. Vi fikk tildelt en prosjektkoordinator som skulle veilede oss og fungere som produkteier gjennom prosjektperioden. 2.3 Oppgaven Vi var på intervju hos NIH og de fortalte oss hva de så for seg at oppgaven ville bestå av. De lurte på om vi kunne utvikle en mobilapplikasjon for de som ville fungere på alle de «store» mobiloperativsystemene (Android, Windows Phone og ios). Det var noe de hadde ønsket seg en stund og de viste oss en app som heter Instabart. Instabart var utviklet for NTNU, og de ville ha noe som var like enkelt og oversiktlig å bruke. Vi så med en gang at Instabart ikke var en optimal løsning med tanke på eventuelle fremtidige endringer og kom på noe som er lettere å endre på i etterkant. NIH hadde et tilleggsønske, nemlig at de hadde et problem med registrering av studentenes oppmøte på obligatorisk undervisning. De lurte på om ikke det kunne være mulig å lage en modul eller funksjon til en mobilapplikasjon der man kunne gjøre det på enklere måte. Vi hadde et oppstartmøte i januar 2015 der vi fikk vite litt om hvilke ønsker de hadde til applikasjonen og kunne da begynne på definere en kravspesifikasjon til vår prosjektoppgave. 9

10 3. Planlegging Denne delen av prossessrapporten beskriver hvordan planlegginsfasen av hovedprosjektet ble gjennomført. 3.1 Forprosjekt Leting etter prosjekt: vi kom litt sent i gang med valg av oppgave, men sendte noen forespørsler på mail til de oppdragsgiverne vi syntes var interessante. Vi hadde allerede dannet gruppe og da vi fikk svar fra NIH og sett litt mer på oppgaven og hva mulighetene var, begynte vi å planlegge og tenke ut løsninger i samarbeid med veilederen vår og kontaktpersonen hos NIH. Kravspesifikasjonen kom på plass og ble definert, og vi ble enige om at en smidig (Scrum) utviklingsmetodikk ville passe best for å fullføre prosjektet. 3.2 Kravspesifikasjonen Kravspesifikasjonen ble til at vi har som oppgave å lage en mobilapplikasjon for Norges Idrettshøgskole. De har en del ønsker som vi skal forsøke å innfri, men oppgaven er noe åpen så vi kan være oppfinnsomme med tanke på funksjonalitet og utforming. NTNU har en app som heter Instabart og det er noe liknende vi skal forsøke å få laget for NIH. Noen av ønskene til funksjonalitet er: -dagens middag i SiO kantiner -informasjon om og fra foreninger -annet nyttig informasjon, som kommende arrangementer mm -personlig timeplan -NIH mailen -litteraturlister/studieplaner -gruppetimer/aktivitet, NIH, gruppetimer osv. Med push varsel om mulig -språk for appen: mulighet til å velge mellom norsk/engelsk Enkelhet i mobilapplikasjonen foretrekkes slik at det skal være lettere å videreutvikle dersom det er ønskelig å endre på noe i fremtiden. 10

11 3.3 Fremgangsmåte Vi velger å gjøre det så enkelt som mulig med webløsningen (mobilapplikasjonen er basert på denne) slik at de som skal ha tilgang til å endre noe der kan gjøre det på en lett måte. Vi har laget en struktur til en html side og skal bruke den videre til å legge til funksjonalit og «porte» mobilapplikasjonen en til de tre store mobiloperativsystemene Windows Phone, ios og Android. Utseendemessig så var egentlig alle enige om at vi ville lage en app som var enkel å bruke, men samtidig hadde de funksjoner som var nødvendige. En minimalistisk mobilapplikasjon som forhåndslagrer (cacher) en webside var noe vi hadde brukt før og visste kunne fungere. 3.4 Design Her er en skisse av hvordan vi så for oss at mobilapplikasjonen ville se ut: 11

12 Siden NIH sine servere er.net-baserte så må vi benytte oss av de mulighetene og begrensningene det gir oss. Verktøy vi kommer til å bruke til å utvikle mobilapplikasjonen er blant annet: Visual Studio. Av prosjektstyringsverktøy ble vi anbefalt Trello, da denne er enkel og oversiktlig å bruke. Vi sto også fritt til å benytte andre verktøy som vi synes kan være hensiktsmessige. Dette er websiden til Norges Idrettshøgskole som vi benyttet som utgangspunkt: 3.5 Arbeidsmetodikk I og med at vi hadde noe forskjellig bakgrunn så bestemte vi oss for at Scrum (smidig utviklingsmetode) kunne være det som passet best for oss. Denne avgjørelsen tok vi også fordi vi sto ganske fritt til å utvikle, uten at vi måtte definere nøyaktige oppgaver og steg slik som kunne være mer vanlig i en mer tradisjonell måte å utvikle på. Scrum er en arbeidsmetodikk som vi allerede hadde noe erfaring med og som vi mener fungerer godt, også med tanke på innspill fra oppdragsgiver. 12

13 3.5.1 Scrum og smidig systemutvikling Scrum og smidig utvikling handler i stor grad om å ha korte «sprint» i utviklingsprossessen der man presenterer noe ferdig etter hver sprint. Det er en smidig prossess der oppdragsgiver er mer innvolvert enn ved andre metoder der man fastslår kravene og leverer ferdig produkt. Med scrum så får man innspill underveis og kan gjøre endringer ved behov eller dersom man kommer på bedre alternativer. Scrum er på en måte selvorganiserende der man jobber tett sammen som en gruppe for å oppnå et mål. Man treffes ofte, eller har ihvertfall muligheten til dette, og får tilbakemeldinger underveis. Noe av hovedgrunnen til at vi ville bruke scrum er at vi sto litt fritt til å gjøre ting med mobilapplikasjonen og oppmøteregistreringen og derfor kunne det komme noen endringer i kravene fra NIH. Vi hadde også i oppgave å utvikle en funksjon for oppmøteregistrering som etterhvert utviklet seg til å bli et mer eller mindre, helt eget prosjekt da det ble ganske stort. Dette var en av årsakene til at vi ikke valgte å bruke en mer tradisjonell måte å jobbe på. Vi følte at vi måtte ha muligheten til å kunne gjøre endringer underveis etterhvert som vi fant mer ut av hvilke muligheter vi hadde med tanke på hvilken infrastruktur som var på plass hos NIH, hvilken informasjon vi kunne hente ut derfra og hva de ville gi oss tilgang til å hente ut Sprints Vi hadde forskjellige sprint deler av prosjektet, som er en egenskap ved scrum at man har en sprint og leverer et produkt, for så å gå videre. Vi delte opp sprintene i følgende episoder: Sprint 1: Finne oppgave og få alt det formelle på plass. Utarbeidelse av kravspesifikasjonen ble en den av denne. Sprint 2: Denne omhandlet utviklingen av webløsningen/mobilapplikasjonen. Sprint 3: 13

14 Oppmøteregistrering. Sprint 4: Dokumentasjon og ferdigstillelse. 3.6 Brukertesting Vi planla at vi skulle ha brukertesting i slutten av hver sprint. Det skulle skje med fagansvarlig som ønsket en oppmøteregistreringsfunksjonalitet, siden mobilapplikasjonen er ganske selvforklarende og vi ikke så helt behovet for brukertesting av denne delen. 3.7 Prosjektstyringsverktøy Vi fant ut at vi skulle bruke et verktøy fra Atlassian som heter Bitbucket og Trello som prosjektstyringsverktøy. Vi utviklet i Visual Studio og lagret i bitbucket, google drive og på HiOA sitt webområde. Bitbucket: Bitbucket er en web-hosting tjeneste som er gratis for inntil 5 brukere. Det ga oss muligheten til lett å kunne lagre koden til prosjektet i en «sky» og laste ned til våre respektive maskiner for så å kunne jobbe med koden mer eller mindre samtidig. Google Docs & Google Drive: Vi brukte google docs til å samarbeide om sluttrapport og de andre dokumentene, og lagret på google drive slik at alle hadde tilgang til å jobbe med de samme dokumentene. Visual Studio Community Edition 2013: Dette var ett av hovedverktøyene vi brukte til å utvikle mobilapplikasjonen og til å lage oppmøteregistreringsfunksjonaliteten. Trello: 14

15 Gratisverktøy som vi brukte til å styre prosjektet. Veldig enkelt og oversiktlig å bruke og selv om det ligner mer på oppslagstavlemetoden som er lignende kanban, så fant vi at det fungerte godt for oss med vår valgte scrum-metodikk. 3.8 Valg av teknologi Når vi hadde fått alle detaljer om det de ville ha i den foreløpige kravspesifikasjonen, måtte vi bestemme oss for valg av teknologi. På møtet med NIH ble vi forklart at vi måtte bruke ASP.NET/C# siden serverne deres bruker det. Det var det kun en av oss som tidligere hadde hatt erfaring med dette fra før. Vi brukte en vanlig løsning med MVC for webapplikasjonen ASP.NET/C# Vi valgte å bruke ASP.NET/C# da alle serverne til NIH er ASP.NET servere. Det var kun en av oss som hadde noe erfaring med ASP.NET/C#. Vi måtte derfor lære dette underveis. Dette gjorde vi blant annet ved å følge en del videoforelesninger, blant annet på youtube, og lese oss opp på løsninger. ASP.NET er ett rammeverk for webutvikling som tillater en å skrive dynamiske nettsider. Bygget på CLR (common language runtime), som tillater en å skrive i hvilket som helst.net programmeringsspråk (C# i vårt tilfelle). C# er et programmeringsspråk som ble utviklet av Microsoft og som kan ses som å være multiparadigmet. Det støtter både objektorientering, component basert programmering og funksjonell programmering Html og Css Vi måtte benytte en del html og css på webløsningen som danner grunnlaget for mobilapplikasjonen og vi satte opp den sistnevnte til å forhåndslagre (cache) html sidene. 15

16 I tillegg var det et designønske fra NIH om at vi hadde fliser som snudde seg, da de likte det designet. Dette gjorde vi i css Javascript Javascript er et dynamisk programmeringsspråk. De er mest brukt til nettlesere, med implementering av interaksjon med brukere og hva som da vises av innholdet på siden. Det er et multi-paradigme språk det vil si at den tilbyr et rammeverk med en variasjon av stiler. 3.9Arkitektur Når vi hadde bestemt oss for hvilke teknologier som skulle brukes til å utvikle applikasjonen og Web-API-et måtte vi ta en vurdering hvordan de skulle bygges opp. Vi planla å starte med rammeverket, det vil si kjernen i løsningen vi skulle utvikle, som skulle bestå av Model-View-Controller, slik det er vanlig å gjøre. Vi skulle kalle løsningen NIHApp. Vi regnet med å bruke den vanlige formelen med at kontrollerklassene sender kommandoer til modellklassene for å oppdatere disse. Samtidig skulle kontrollerklassene gjøre at viewklassene endret hva den viser av modellklassene. Modellklassene skulle oppdatere sine kontrollerklasser og viewklasser om endret status slik at disse henholdsvis ville oppdatere hva som viser og hvilke metoder og kommandoer som ville bli utført. Viewklassene skulle vise output enten ved å motta informasjon eller ved å sende en forespørsel om hva som skal vises. Følgende illustrasjon viser hva som er den vanlige modelen: 16

17 4. Utviklingsprosess Grafisk fremstilling; milepælsplan: 4.1 Sprint1: Oppstartsfase Vi sendte mail til NIH for å høre om muligheten til å gjennomføre bachelorprosjektet hos de den 07/11/2014 og ble etterhvert enige om å komme til intervju den 12/12/2014. Vi diskuterte litt løst hva NIH ønsket og om vi hadde mulighet til å lage dette. Etterhvert kom vi også inn på delen av 17

18 prosjektet som omhandler oppmøteregistrering og mulige løsniner rundt dette. Det ble også bestemt at studentene på NIH skulle kunne komme med ønsker om funksjonalitet i mobilapplikasjonen da det hovedsakelig er de som skal bruke den. Den møttes vi igjen for å skrive kontrakt og utarbeide kravspesifikasjonen. NIH ville gjerne at vi skulle jobbe der slik at vi kunne ha tettere oppfølging og kommunikasjon. Vi så på hva som ville fungere best for alle og ble enige om at vi skulle jobbe på NIH hver fredag. Denne delen av oppgaven handlet i stor grad om å finne prosjekt, få det formelle på plass og legge til rette for resten av prosjektet. Vi brukte tid på å få ideer og snakke rundt hva vi ville ha med av funksjoner og hvordan det hele skulle bli bygget opp. Vi fikk laget en kravspesifikasjon og begynte å gå i detalj om de enkelte delene av mobliapplikasjonen som vi skulle utvikle og gjorde vurderinger rundt hindre som kunne komme i veien for at vi fikk utført prosjektet. En av tingene som vi brukte mest tid på var å avklare hva vi ville ha tillatelse til å registrere med oppmøtefunksjonaliteten og hva vi kunne bruke av øvrig infrastruktur på NIH til å virke. Vi så også på hvilke risiko som kunne inntreffe og hva vi kunne gjøre for å minske effekten av disse. Vi startet å bruke Trello som prosjektstyringsverktøy og la til veileder og kontaktperson på NIH til vår gruppe slik at de kunne følge utviklingen. Vi hadde noen småproblemer, blant annet med visual studio og kontoer. Vi måtte finne en felles versjon av Visual Studio vi skulle bruke. Noen av oss hadde allerede installert Visual Studio i forbindelse med andre fag og prosjekter, så vi ble enige om å benytte Visual Studio 2013 Community Edition. Dette fordi det er gratis og godt egnet for å utvikle ASP.NET løsninger. Fronter er en av de mest brukte undervisningsstøtteverktøyene og NIH bruker dette. Vi kontaktet Fronter for å få informasjon av hva vi kunne bruke av deres api, men fikk følgende svar da de holdt på å gjøre endringer og derfor ikke hadde så mye informasjon som de kunne hjelpe oss med: Hei Kristoffer, takk for hyggelig henvendelse. Vi driver for tiden og moderniserer API'ene våre og har ennå ikke en sentral moderne API-løsning på plass dessverre. 18

19 Vi har endel API'er der tilgang kan gis for den fronterbygningen dere er brukere av, og da kan dere gjøre integrasjon mot den bygningen. Vennligst se, og ta kontakt med oss igjen når det er spørsmål. Vi har dessverre veldig lite kapasitet for å følge opp dette, men skal gjøre vårt beste for å hjelpe dere videre hvis dere finner de API'ene dere trenger i dokumentasjonen. Thomas Malt Director of Engineering Fronter fronter.com E: thomas.malt@pearson.com M: Pearson Always Learning Her er en mail vi mottok tidlig fra NIH, der de sender med noen ønsker de har: Hei. Jeg har ikke anledning til å komme på møte i dag, beklager for sen tilbakemelding. Vi har pratet litt om det i studentstyret, og vi har følgende punkter: -dagens middag -foreninger- info, kommende arrangementer osv - personlig timeplan -NIH mailen - litteraturlister/studieplaner - gruppetimer/aktivitet, NIHI, gruppetimer osv. Med push varsel om mulig - språk for appen: mulighet til å velge mellom norsk/engelsk 19

20 Vi foretrekker også enkelhet i appen, men slik teknisk kan nok de som skal utvikle den bedre enn oss. Jeg håper å stille på neste møte, og bare si om det trengs noe for oss. Mvh, Stian Mæland Risikovurdering sprint 1: Vi satte opp en tabell over hvilke problemer vi kunne få og denne er gjengitt nedenfor: Risiko Årsak Sannsynlighet Konsekvens Tiltak 1 Liten Sykdom Høy Lav Lite å gjøre annet enn å holde seg unna syke mennesker, spesielt i omgangssykeperioden osv 2 Liten Tap av data Lav Høy Lagret i sky; redundans på egne maskiner 3 Høy Ikke lov å registrere Middels Høy Avklare med datatilsynet oppmøte 4 Høy Frafall i gruppen 5 Middels Dårlig samarbeid Middels Middels Ha det formelle på plass Lav Middels Sette opp samarbeidsavtale og ha et godt sosialt liv slik at vi jobbet bedre sammen 6 Middels Manglende kunnskap Middels Høy Ta seg tid i begynnelsen for å sette 20

21 seg inn i de forskjellige teknologiene vi ville bruke 7 Høy Prosjektet blir for stort Høy Høy Avgrense prosjektet, gjerne på et tidlig stadie; ha forståelse fra oppdragsgiver og veileder at vi muligens kom til å måtte nedprioritere noen deler 4.2 Sprint2: Webside og mobilapplikasjon Denne delen var det vi begynte med og som NIH hadde vært ute etter en stund. Vi gjorde det enkelt ved at vi laget en webløsning som så ble cachet av mobilapplikasjonene på de respektive mobiloperativsystemene, det vil si Android, Windows Phone og ios. Et fremtidig ønske fra NIH er at de kanskje vil ha en mulighet for å motta bluetooth push-meldinger I mobilapplikasjonen, men det måtte vi prioritere bort fordi prosjektet ville bli for omfattende. Infrastrukturen for å sende push-meldinger, om for eksempel nyheter og endringer i undervisning er heller ikke på plass, men ett ønske for fremtiden. Vi laget mobilapplikasjonen slik at den cacher websider og siden den er såpass modulær og lett å endre på så er den ett godt utgangspunkt for å legge til en slik funksjonalitet i fremtiden. Ifølge kravspesifikasjonen skulle vi lage en mobilapplikasjon for NIH som inneholdt nyttige lenker til verktøy og sider som studenter bruker til daglig eller kan ha nytte av å ha mer tilgjengelig gjennom en mobilapplikasjon. 21

22 Vi hadde blant annet ett møte med en studentrepresentant i oppstartsfasen og snakket noe om hva som kunne være nyttige lenker. IT-avdelingen på NIH hadde selv noen forslag, basert på hva de likte med Instabart, og som vi noterte og diskuterte. Blant annet så likte IT-avdelingen hvordan flisene i Instabart virket, ved at de snudde seg og viste litt informasjon om lenken på baksiden av flisen. Det var vi enige at var en designmessig pen løsning og valgte å lage noe som liknet. Av lenker så kom vi frem til at følgende kunne være nyttige: -dagens middag i SiO kantiner -informasjon om og fra foreninger -annet nyttig informasjon, som kommende arrangementer mm -personlig timeplan -NIH mailen -litteraturlister/studieplaner -gruppetimer/aktivitet, NIH, gruppetimer osv. Med push varsel om mulig. -språk for appen: mulighet til å velge mellom norsk/engelsk Vi går nærmere inn på de tekniske detaljene rundt dette i produktrapporten, men vi her skrive litt rundt prossessen og hvordan vi tenkte. Publisering og distribuering: For å dele mobilapplikasjoner må man lage utviklerkonto på Google Play, Windows Marketplace og Appstore. NIH sa seg villige til å betale for en distribusjonslisens på de siste webløsningene for distribusjon av mobilapplikasjoner til sine studenter. Etter å ha vurdert litt forskjellig utforming så kom vi frem til at følgende lenker ville være de mest nyttige: 22

23 Nyheter Fronter Timeplan E-post Oppmøteregistrering Foreninger Ruter Dagens middag Forklaring på lenkene: Nyheter Denne fant vi ut at kan være nyttig da denne blir brukt til å formidle nyheter og det er alltid greit å få med seg det siste som skjer på sitt læringssted. Denne siden hos NIH kan også brukes til å formidle endringer i undervisning eller eksamenssted, selv om det heller er andre steder det skal opplyses om. Fronter Dette er det mest brukte undervisningsverktøyet, ihvertfall i Oslo. Her får man forelesningsnotater, kan laste opp innleveringer og diverse nyttig informasjon man trenger om de fagene man tar. Timeplaner Denne linken går til NIH sine timeplansider, der man kan se hvor man har undervisning og gruppetimer, samt at man kan reservere grupperom. Linken går til NIH sin versjon av TimeEdit og denne ser ut til å fungere meget bra. Den er oversiktlig og lett å bruke. E-post Denne er mer eller mindre selvsagt da e-post er mer eller mindre akseptert som en god og offisiell kommunikasjonsmetode per i dag. Det er her viktige personlige beskjeder kommer, i motsetning til for eksempel Fronter, der man får generell informasjon til alle i klassen/trinnet. Oppmøteregistrering 23

24 Dette er lenken går til den andre delen av vårt prosjekt, nemlig oppmøteregistrering. Denne brukes til å registrere at man er tilstede på undervisning der det kreves for å bestå faget eller for å få tatt eksamen. Det er noe annerledes på NIH enn på for eksempel HiOA, da de har en del fag der man krever oppmøte på en del fag Foreninger Her var det ett ønske fra blant annet studentrepresentanten vi snakket med om at vi skulle ha en lenke til foreningssiden på NIH. Det å være med i en studentforening kan gi mye glede i en ellers hektisk studenhverdag og kan være ett godt tilbud til studenter og kan være med på å bidra til at man får interesse og overstkudd i studenthverdagen. Ruter Ved å følge lenken på denne flisen kommer man direkte til ruter sine nettsider der de lister sanntidsinformasjon om avganger på Sognsvann stasjon. Denne stasjonen er stoppestedet som er nærmest NIH og derfor mener vi dette er en nyttig lenke å ha. Den er raskere enn å søke på Ruter sine sider siden man blir videreført direkte dit. Dagens middag Lenken går direkte til siden der det informeres om hva som er tilbudet på dagens middag hos SiO sin kantine på NIH. Dette var ett forslag som vi så at fantes på Instabart og som vi mener kan være nyttig da man raskt kan planlegge om man blir på skolen for å fortsette å jobbe eller må ta tid til å reise hjem for å lage egen middag dersom tilbudet ikke er fristende. 24

25 Dette gir en rekke lenker som ser slik ut før vi bruker fliser: - Risikovurdering sprint 2: Risiko Årsak Sannsynlighet Konsekvens Tiltak 1 Liten Sykdom Høy Lav Samme som for sprint 1 2 Liten Tap av data Lav Høy Samme som tidligere 3 Høy Ikke lov å registrere oppmøte Middels Høy Dette hadde vi allerede avklart med Datatilsynet 25

26 4 Høy Frafall i gruppen Middels Middels Det formelle var i orden og jevne dager vi møttes for å jobbe på. 5 Middels Dårlig samarbeid 6 Middels Manglende kunnskap Lav Middels Samme som for sprint 1 Middels Høy Vi fortsatte å sette oss inn i teknologiene mens vi gradvis jobbet 7 Høy Prosjektet blir for stort Høy Høy God avgrensning 4.3 Sprint 3: Oppmøteregistrering Denne sprinten startet vi på etter at den andre delen var mer eller mindre ferdig. Vi hadde «brukertest» i form av at vi presenterte produktet for kunden og fikk tilbakemelding. Vi hadde en del spørsmål i starten, spesielt om hva som ville være lov å registrere. Vi valgte å ikke lagre sensitiv personlig informasjon, som for eksempel personnummer, i mobilapplikasjonen. Vi fant ut at vi måtte kontakte datatilsynet for å få vite hva reglene rundt registrering av informasjon var. Vi tok kontakt med datatilsynet for å få bekreftet at det var lov å registrere oppmøte på den måten vi hadde tenkt. Dette er korresponsen med datatilsynet: Hei og takk for din e-post. Vår svartjeneste gir deg kortfattet rådgivning. Vi vil derfor ikke konkludere i saken din, men gi deg råd og veiledning. 26

27 Det er ikke noe i veien for å registrere oppmøte i obligatorisk undervisning, verken med klasseliste eller elektroniske hjelpemidler. Du kan lese mer om apper og personvern her Det er viktig at det etableres rutiner for hvor lenge listene skal lagres og hvem som skal ha tilgang. Jeg antar at dere skal bruke en skyløsning av en eller annen type, dere kan lese mer om personvern i skyen her: Håper dette var til hjelp, ta gjerne kontakt om du har flere spørsmål. Vennlig hilsen, Gullik S.H. Gundersen Juridisk konsulent Datatilsynet Telefon: (+47) Postadresse: Postboks 8177 Dep., 0034 Oslo Besøksadresse: Tollbugata 3, Oslo Følg med på: www. personvernbloggen.no Datatilsynet i front for retten til selvbestemmelse, integritet og verdighet 27

28 -----Opprinnelig melding----- Fra: Kristoffer Solberg [mailto:] Sendt: 12. mars :50 Til: Postkasse Emne: Spørsmål om mulighet til å registrere oppmøte Hei, Vi er tre studenter på HiOA som jobber med ett bachelorprosjekt. En del av oppgaven er å lage en funksjon i en app for å registrere oppmøte på obligatorisk undervisning. Vi lurer på om det ville vært lov å registrere dette med en app og dersom det er lovlig, kan man registrere at en student er tilstede over en tid (1-2 timer)? Med forbehold om at brukeren av en app godtar betingelser for bruk og at de er gjort oppmerksom på at deres oppmøte vil bli registrert. Mvh, Kristoffer Solberg Vi tok dette som en bekreftelse på at det er tillatt å registrere oppmøte elektronisk og kunne derfor jobbe videre med denne delen av prosjektet. Vi hadde tok kontakt med en som var nettverksansvarlig hos NIH og forklarte han hva vi var ute etter. Vi hadde sett på en løsning der man kunne hente ut tilgjengelige nettverksaksesspunkt fra mobiler og dermed bestemme om en student var tilstede på undervisning eller ikke. 28

29 Vi fant raskt ut at det var noen problemer med dette. Androidoperativsystemet er relativt åpent og vi kunne derfor lage en funskjon for å hente ut en liste med tilgjengelige aksesspunkter og sammenlikne det med aksesspunktene som var tilgjengelige for en forelesers mobiltelefon, dersom begge brukte android. Vi hadde ikke den samme muligheten for å gjøre det med Windows Phone og ios, da de ikke åpner for å kunne hente ut en liste over tilgjengelige aksesspunkter. De sistnevnte mobiloperativsystemene gir oss kun mulighet til å finne det aksesspunktet de for øyeblikket er tilkoblet. Det ga oss en utfordring da vi hadde basert en stor del av prosjektet vårt på å kunne gjøre dette på en så sikker måte som mulig for å forhindre juks. Vi måtte gå tilbake og se på hele oppmøteregistreringsdelen av prosjektet vårt og se hva vi kunne gjøre. I samtale med IKT-avdelingen på NIH så kom vi frem til at vi ikke trengte å gjøre det helt 100% sikkert, bare like sikkert som dagens løsning med papirark der man skrev ned at studentene var tilstede på undervisningen. Vi hadde tatt som utgangspunkt at det skulle være så sikkert at det ville bli umulig å jukse med oppmøte på obligatorisk undervisning, men da ville denne delen av prosjektet bli så omfattende på grunn av de tekniske begrensningene, spesielt med mobiloperativsystemene Windows Phone og ios at prosjektet ville bli for stort. Vi måtte derfor revurdere og kom frem til at dagens løsning er sikker nok og vi tok sikte på minst like sikkert. Problemet med dagens løsning er at denne listen som blir laget ved at man tar oppmøte manuelt må deretter registreres i systemet av en fagansvarlig, som bruker mye tid på å føre det inn i systemet slik at man har oversikt over hvem som har vært tilstede på nok timer til å kunne få avlegge eksamen/få godkjent faget. Det var ønskelig med ett elektronisk system for dette slik at arbeidsmengden som ble brukt på dette ble redusert og fagansvarlig kunne benytte tiden sin bedre på andre ting enn å sitte og registrere oppmøte manuelt. Vi startet på nytt og laget en løsning der man har en kode som blir generert av programmet og gis ut av foreleser. Studentene har da en tidsbegrenset mulighet for å registrere seg via webløsningen vi laget for dette formålet. Vi har gjort det slik at man kan generere koder på forhånd og få en oversikt 29

30 over hvilke studenter som har oppfyllt kravene og møtt opp på tilstrekkelig undervisning slik at fagansvarlig slipper å gjøre dette manuelt. Risikovurdering i sprint 3: Risiko Årsak Sannsynlighet Konsekvens Tiltak 1 Liten Sykdom Høy Lav Samme som tidligere 2 Liten Tap av data Lav Høy Samme som tidligere 3 Høy Ikke lov å registrere Middels Høy Avklart med Datatilsynet oppmøte 4 Høy Frafall i gruppen Middels Middels Formelle på plass og arbeide jevnt 5 Middels Dårlig samarbeid 6 Middels Manglende kunnskap Lav Middels Samme som sprint 1. Middels Høy Vi satte oss inn i teknologien og jobbet med det. 7 Høy Prosjektet blir Høy Høy K.I.S.S for stort 4.4 Sprint 4: Dokumentasjon og finpuss Dette ble en egen sprint da vi hadde begge delene av prosjektet mer eller mindre ferdige, men vi hadde nedprioritert dokumentasjonen noe for å få ferdig produktene og at vi hadde alle andre fag som vi måtte gjennomføre og ta eksamen i. Vi kom noe sent i gang med dokumentasjonen men 30

31 siden vi hadde gode møtereferater og en god prosjektdagbok så lot dette seg ordne allikevel. Dokumentasjonen ble delt opp i en kort innledning,produktdokumentasjon, prosessdokumentasjon og vedlegg og så ble dette satt sammen til den endelige sluttrapporten. Risikovurdering sprint 4: Risiko Årsak Sannsynlighet Konsekvens Tiltak 1 Liten Sykdom Høy Høy I denne avslutningsperioden ville konsekvensen av sykdom være høy. Det var viktig å forebygge for enhver pris. 2 Liten Tap av data Lav Høy Dette ville vært katastrofalt, og derfor hadde vi lagret på flere steder. 3 Lav Ikke lov å registrere Lav Lav Avklart med Datatilsynet. oppmøte 4 Høy Frafall i gruppen Middels Middels Dette ville hatt alvorlige konsekvenser for om prosjektet ville vært gjennomførbart. 5 Middels Dårlig samarbeid Middels Middels Det kan hende at i stressende situasjoner at 31

32 samarbeid ikke fungerer optimalt lenger og det kunne hatt noe påvirkning dersom det ikke ble rettet opp i. 6 Middels Manglende kunnskap 7 Høy Prosjektet blir for stort Middels Høy Dette er ikke et tema for denne delen. Høy Høy Avgrensning og tidsstyring. Gant-Diagram over sprintene i begge prosjektdelene: 4.5 Brukertesting Vi fikk tid til å gjøre noe brukertesting på slutten av prosjektet. Det vi testet mest var oppmøteregistreringdelen, da det var mest nødveldig. Vi hadde en del kontakt med han som etterlyste denne funksjonaliteten og han hadde noen ønsker. Vi gjorde ferdig denne delen av prosjektet i sprint 4 og testet deretter. I all hovedsak var kunden fornøyd, og vi måtte kun gjøre små endringer. Vi hadde en viss idè om hvordan de fagene der de hadde obligatorisk oppmøte foregikk, men etter å ha laget ferdig denne delen så ble vi forklart nærmere under brukertestingen hva som de ønsket endringer på. 32

33 5.Konklusjon 5.1 Bruken av scrum og samarbeid i gruppe Vi hadde noe erfaring med Scrum tidligere, men vi ser at den riktige utviklingsmetodikken å bruke siden vi sto ganske fritt til å løse oppgaven og det var nyttig å kunne snakke med NIH om hva vi tenkte på de forskjellige stadiene. Vår tilnærming til arbeidsmetode sett under ett har vært god. Vi har fokusert på smidige prinsipper og en god fremdrift gjennom prosjektperioden. 5.2 Samarbeid i gruppe Det er fordeler og ulemper når vi kjenner hverandre så godt som vi gjorde fra før. Når man er mye sammen på fritiden også er det lett at ting sklir litt ut av og til. Enkelte ganger kunne man bli litt irritert på enkelte i gruppen. Et forbedringpotensial var nok å sette et større skille mellom arbeidstid og sosial tid. De gangene enkelte jobbet med andre fag, skjedde det av og til lite på prosjektet. Hver av oss har sine foretrukne måter å jobbe på, og derfor så ble ikke samarbeidet alltid optimalt. Vi var derimot ganske flinke til å møte til jobbing på NIH slik vi hadde avtalt. 5.3 Evaluering av tiltak for å redusere risiko Vi benyttet følgende skjema for å vurdere det vi antok var risiko vi kunne oppleve. Tiltakene fungerte i stor grad, men det oppsto noe sykdom på slutten av prosjektperioden. Det er en delvis vanskelig tid å redusere risiko for blant annet sykdommer, da det er en dårlig periode for allergikere og det er en del omgangssyke og liknende som er vanlig. Konsekvensene og risiko i de forskjellige sprintene ble derfor naturlig nok varierende, og det gjenspeiles i forskjellene i vurderingene i hver enkelt sprint. Risiko Årsak Sannsynlighet Konsekvens Tiltak 1 Liten Sykdom Høy Lav 2 Liten Tap av data Lav Høy 33

34 3 Høy Ikke lov å registrere oppmøte 4 Høy Frafall i gruppen 5 Middels Dårlig samarbeid 6 Middels Manglende kunnskap 7 Høy Prosjektet blir for stort Middels Middels Lav Middels Høy Høy Middels Middels Høy Høy 5.4 Problemer underveis og hva vi prioriterte bort Vi begynte litt feil på grunn av litt dårlig kommunikasjon i begynnelsen, blant annet med Litteraturlister/studieplaner da vi begynte å se gjennom, kopiere, og forsøke å lage en fullstendig liste. Det som egentlig var kravet er en lenke til websiden, så vi kastet bort en del timer på dette. Vi brukte mye tid på å prøve å komme frem til en løsning for oppmøte som var meget sikkert, men kravet er kun at det må være like sikkert som dagens løsning, bare lettere å bruke. Vi måtte velge vekk en del for at prosjektet ikke skulle bli for stort. Blant annet så begynte vi å se noe på funksjonalitet for funksjonshemmede med tanke på universell utforming. Vi fant ut at flisene er såpass selvforklarende og lette å bruke at det ikke er veldig nødvendig. Vi vurderte det som unødvengig å ha kart over skoleområdet i en mobilapplikasjon, da det er et ganske kompakt område. I oppmøteregistreringsdelen brukte vi alt for mye tid på å lage en løsning som vi senere måtte velge bort fordi vi så at det var en stor prosentandel av studentene som brukte mobiltelefoner med ios. Hadde en større andel av de brukt Android, kunne vår løsning fungert, men dessverre så ble det ikke slik. 34

35 5.5 Forslag til fremtidig utvikling/forbedring NIH hadde ett ønske om en fremtidig løsning for å motta bluetooth push-meldinger og det kan nok være en idè når infrastrukturen er på plass. Det er ganske enkelt å lenge til en slik modul eller andre funksjoner i mobilappliksjonen. 35

36 Produktrapport NIH-App Gruppe 9 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo,

37 Innholdsfortegnelse 1.Forord Caching av webløsning PhoneGap/Apache Cordova: Entity Framework LINQ Razor view engine Mobilapplikasjonen Funksjonelle krav Oppbygning av applikasjonen Design på Fliser Sikkerhet Utviklingsmiljø Nedprioriteringer UTFORDRINGER Oppmøteregistrering Oversikt Funksjoner Klassene Sikkerhet UTFORDRINGER

38 1.Forord Denne delen av rapporten forklarer mer teknisk om hva begge delene av prosjektet inneholder. Vi velger derfor å dele den inn i to deler, da den ene delen vi hadde i oppgave å gjøre ble såpass stor at det kunne vært et eget prosjekt. Mobilapplikasjonen Kravspesifikasjonen vi utarbeidet med NIH og studentrepresentanten er at vi skulle lage en mobilapplikasjon for NIH som skulle fungere fint på de tre store mobiloperativsystemene Windows Phone, ios og Android. Dette vil være behovet for en mobilapplikasjon for de fleste mobiltelefonene som er i bruk i dag. Vi valgte derfor å lage en webløsning med en webside som kunne være modulær og lett å endre på ved behov og som så ble cachet av nettlesere på de respektive mobiloperativsystemene. Dette ble gjort for å lette arbeidet med fremtidige endringer slik at det ville være websiden som man kunne endre på uten å gjøre nye nedlastninger av mobilapplikasjonen og dermed slippe mye tilleggsarbeid. Oppmøteregistrering Det var et spesielt ønske fra ansatte på NIH om vi kunne utvikle, som del av prosjektet, utvikle en funksjon som kunne registrere oppmøte på obligatorisk undervisning på en bedre måte enn det som har blitt gjort tidligere. Systemet de har per i dag er at de skriver opp navn til studenter på en liste, og så må en ansatt føre dette inn i en oversikt manuelt for å se hvor mange timer eller undervisningsbolker som studenter har deltatt på. Vi vurderte flere løsninger, men fant ut at det letteste ville være å gjøre dette som ett eget prosjekt, i sin egen sprint (ref. scrum som arbeidsmetodikk). Det vi endte opp med var en funksjon der studenter logger seg inn på en side som det lenkes til i mobilapplikasjonen til NIH, og bruker sitt eget brukernavn/studentnummer og passord til å logge inn og bruker en kode som foreleser/fagansvarlig genererer på forhånd og deler ut til klassen for å registrere oppmøte. 38

39 Det fantes ingen formell kravspesifikasjon til hvordan vi løste denne funksjonen, så vi sto veldig fritt til å bruke kreativiteten her. Vi diskuterte mye, kom på og forkastet ideer, før vi fant en løsning som vi presenterte for fagansvarlig. 2 Tekniske løsninger 2.1 Caching av webløsning Figuren over viser hvordan vi gjennomførte caching av websiden til mobiler. Vi laget en webløsning med fliser slik at det skulle se likt ut på de forskjellige mobiloperativsystemene og lagret det som ble ligger på serveren til en app som ikke hadde andre oppgaver enn å forhåndslagre webløsningen. I webløsningen finnes fliser med lenker til de funksjonene vi ble enige med NIH at skulle være der. Funksjonene i seg selv er websider som man kan bruke det meste som har internettilgang til å logge på, men for å gjøre en mobilapplikasjon mer brukervennlig så har vi laget lenker i fliser som åpner nettleseren på mobilen og tar brukeren rett til websiden. Dette gjør at løsningen er modulær og lett å endre ved behov, man trenger ikke gjøre noe med mobilapplikasjonene som er installerte, men heller bare gjøre endringene ett sted. For kontrollerne til.net kan man styre caching med data annotations for de klassene eller metodene man ønsker med [OutputCache()] man kan sette tiden i sekunder cachen er gyldig med Duration atributten. man kan fortelle om cachen skal skilles ved parametre ved VaryByParam det vanligste vil være VaryByParam=Id som gjør at man har forskjellige cacher for hver id. Man kan sette hvor man skal cache med Location parameter der man kan velge mellom Any Client tilsvarer HttpCacheability.Public kan lagres på hos klienten, webserveren, proxy, og alle andre servere som deltar i forespørselen. tilsvarer HttpCacheability.Private skal bare lagres i klienten som foretar spørringen 39

40 Downstream kan lages i alle http 1.1 cachable enheter andre enn serveren der forespørselen behandles. None caching avslått for denne settingen. Server lagres bare serveren hvor forespørselen behandles ServerAndClient både på serveren der forespørselen behandles og i klienten som foretar spørringen vi skal legge til caching med Client lokasjon på alt i oppmøteregistreringen med en caching tid på 5 sekunder. På link appen har vi foreløpig valgt og bruke Any med en varighet på 24t 60*60*24. Vi har laget caching profiler i web.conf filen som gjør det mye lettere og endre tiden, parametrene og lokasjoner i ettertid 2.2 PhoneGap/Apache Cordova: Vi brukte PhoneGap for å en mobiltelefonapplikasjon som viser nettsiden på mobiltelefon.denne ble satt opp til å følge standard html caching-regler og brukte javascript til hente nettsiden når mobilapplikasjonen slik at den bør virke offline så lenge brukere har åpnet den online først og ikke sletter cachen sin. Den vil også automatisk oppdatere seg etter nettsiden så lenge den er online. Fordelen med å bruke html-cache istedenfor å lagre websiden i mobilapplikasjonen de laster ned er at man slipper å oppdatere gjennom de respektive app stores ene for å oppdatere html. 2.3 Entity Framework Entity Framework er et Object-relational mapping rammeverk som er en del av.net rameverket. Vi benyttet oss av entity framework code first for og generere databasen fra modellene. Dette gjør at vi får en sammenheng mellom datatypene og en enkel sammenheng mellom datene vi 40

41 tillater i databasen og i modellene våre. Disse begrensningene kan blant annet settes ved hjelp av dataannotations. Når man lager modellene er det veldig greit at man legger til pekere i alle klassene som har tilhørighet til hverandre i tillegg til id, men man bør huske på og sette set metoden private i klassene som ikke inneholder id sånn at man ikke får Circular Reference exception hvis man prøver og serialisere det. Dette fører til at man må passe på og oppdatere koden på riktig sted. Data modellene våre er laget med tanke på at de skal være lette å bruke med LINQ queries samtidig som de skal være enkle og serialisere. Object-relational mapping er en programmerings teknikk for og konvertere data mellom inkompatible datatyper. Dette lager en virtuell object database som man kan bruke fra programmeringspråket man jobber i, i vårt tilfelle C# LINQ LINQ (Language-Integrated Query) er er en.net komponent som gir dataspørring (querying) egenskaper til blant annet C#. LINQ legger til spørringsspesifike Expressions og datanotasjoner som forekspel dataanotasjonene: [Table(Name= navn ] som man setter over en klasse og forteller hva tabellen til klassen skal hete. [Colum] som er for kolonner som blant annet kan ta atributtene IsPrimarykey som forteller om kolonnen er primærnøkkel og fremmednøkler hvor man kan fortelle at kolonnen er pimærnøkkel til en annen kolonne. Den største fordelen med LINQ er at spøringene bruker EntityFramework som enkelt konverterer databasedatane til C# datatyper og at en del spøringer blir mye ryddigere for eksempel binding (joins) kategoriene fra en klasse med KlasseId = id som iqueryable<kategori> k = klasse from db.klasses kategori from klasse.kategoris 41

42 where klasse.klasseid == id select kategori; Istedet for sql query der tilsvarende ville vært select Kategoris.* from kategoris join klasses on kategoris.klasseid = klasse.klasseid where klasse.klasseid = id; iqueryable<deltar> deltars = oppmote from db.oppmotes deltar from oppmote.time.kategori.klasse.deltars select deltars tilsvarende for sql spørring vil inneholde fire joins En av spørringene våre fra oppmåteregistreringen er med LINQ syntaxen i bold blue IQueryable<AppUserVewModel> m = from usr in db.appusers from del in usr.deltars //dene linjen er en join statment where del.klasseid == klasseid orderby usr.fornavn, usr.etternavn //sorterer først etter fornavn dereter etternavn select new AppUserVewModel() //velger og populerer AppUserVewModel { //det mappes manuelt fordi vi bruker en view klasse AppUserId = usr.appuserid, Fornavn = usr.fornavn, Etternavn = usr.etternavn, AtallOppmotesPerKategoris = ( from o in usr.oppmotes where del.klasse.kategoris.contains(o.time.kategori) group o by o.time.kategori into kategori orderby kategori.key.kategoriid select new AntallOppmotes() { Kategori = kake.key, Antall = kake.count() }) 42

43 }; 2.4 Razor view engine Razor view engine er et ASP.NET programmeringssyntaks man bruker for å lage dynamiske netsider der man for og fortelle at det kommer C# kode i motsetning til ASPX der man merker C# med <% kode %> vi har brukt razor når vi har laget viewene våre. 3. Mobilapplikasjonen Enkel grafisk fremstilling: I tillegg til kravspesifikasjonen fra IKT-avdelingen, hadde studentrepresentanten noen ønsker som vi forsøkte å innfri, blant annet: -dagens middag i SiO kantiner -informasjon om og fra foreninger 43

44 -annet nyttig informasjon, som kommende arrangementer mm -personlig timeplan -NIH mailen -litteraturlister/studieplaner -gruppetimer/aktivitet, NIH, gruppetimer osv. Med push varsel om mulig //TODO mulig fjerne -språk for appen: mulighet til å velge mellom norsk/engelsk 3.1 Funksjonelle krav Vi forsøkte å oppfylle følgende funsjonelle krav: Nr Del av applikasjon Funksjonelt krav 1 Modulær mobilapplikasjon 2 Fungere på alle store mobiloperativsystemer 3 Minimalistisk, men stilig design 4 Fungere med servere på NIH x x x x 5 Nyttige funksjoner x 6 Dagens middag x 7 Informasjon fra foreninger 8 Annen nyttig informasjon x x 9 Personlig timeplan x 44

45 10 NIH mail x 11 Litteraturlister/timepla ner x 12 Gruppetimer/aktivitet x 13* Bluetooth push varsler x 14 Valg av språk x 15** Oppmøteregistrering x *) Denne infrastrukturen var ikke på plass, men et mulig fremtidig ønske **) Denne delen ble så stor at vi måtte se på det som ett eget prosjekt Hvordan vi innfridde funksjonelle krav: I samtale med NIH så hadde de sett for seg en mobilapplikasjon som likner på den NTNU har og som heter Instabart. Vi var enige om at den var minimalistisk og stilig og ville lage noe som liknet. Det har vi fått til ved å bruke en webløsning som utgangspunkt og style den, istedenfor å lage det samme flere ganger til de forskjellige mobiloperativsystemene. Det vi har laget vil også fungere på NIH sine servere siden de bruker Windowsservere. Mobilapplikasjonen er modulær med tanke på at man kan legge til lenkter til funksjoner uten å måtte endre på flere mobilapplikasjoner. Dette gjelder også fremtidige teknologier som kan på en enklere måte implementeres i en webløsning enn å måtte kodes for hver enkelt platform. Vi har sett for oss de som kan være nyttig av lenker, mye basert på ønskene til studentene (via studentrepresentanten) og derfor oppfylt dette kravet også. Skjermbilde av mobilapplikasjonen: 45

46 Det som vises i rødt er lenker som ikke går noe sted. I dette tilfellet er det oppmøteregistreringsdelen som vi ikke har lastet opp til NIH sine servere enda. Denne delen av prosjektet virker som det skal og omhandles i en egen del av denne prosjektrapporten. Vi ser på skjermbildet av vi har lagt til de lenkene som var viktigst for NIH. Når man trykker på de respektive flisene i webløsningen, vender disse og så blir man viderekoblet. Når man trykker på Nyheter, vender flisen slik: 46

47 Dette er sidene det lenkes til: 47

48 3.2 Oppbygning av applikasjonen E/R-diagram webløsning og mobilapplikasjon: Vi bruker denne datastrukturen for at man enkelt skal kunne hoste flere sider. der side klassen inneholder beskrivelse av siden og overskrift mens link klassen skal inneholde alt innhold som skal opp en flis. Det skal enkelt kunne bli laget ny fliser i nettleseren og endre rekkefølgen på dem. Mobilapplikasjonen er laget skrevet som en ASP.NET MVC applikasjon. En kort forklaring på dette er at views er presentasjonslaget, models er kjernen i systemet som interagerer med datakilden og controller er mellomleddet der ting skjer. 48

49 Under Models finner vi noen klasser som skal vise hvordan lenkene og sidene skal være DAL -Data Access Layer Lager database for å lagre, hente tilbake, modifisere og webside for å hente inn informasjon. NIHContext.cs Dette er hvordan applikasjonen kommuniserer med databasen. NIHInitializer.cs Her seed er vi databasen med en liste med lenker. Dette er de som danner grunnlaget for flisene vi skal bruke i mobilapplikasjonen. 49

50 3.3 Design på Fliser Vi har sett på noen ikoner til flisene blant annet er ikonene fra MetroUI er gratis for ikkekommersiell bruk. Vi har også hentet ikoner fra noen tjenester og programmer som NIH bruker og legger ved kilden til disse. Vi har forsøkt å velge enkle og selvforklarende ikoner for flisene i mobilapplikasjonen så det er lett å se hva som er hva. Nyheter: 50

51 Timeplan: E-post: 51

52 Fronter: Oppmøte på obligatorisk undervisning: Foreninger 52

53 Ruter: Dagens middag fra SiO Kantiner: Kilder: Windows8-News-icon.html