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

Størrelse: px
Begynne med side:

Download "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. https://developer.fronter.com/api/activedocs 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: 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

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline

Forprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016. Pillbox Punchline Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2016 Pillbox Punchline Gruppe 8 André Østhagen Bye, s198607 Annika Hammervoll, s198611 Hanne Rygge, s198613

Detaljer

Hovedprosjektet i Data Høgskolen i Oslo våren 2010

Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Hovedprosjektet i Data Høgskolen i Oslo våren 2010 Kevin Holmvik s147777 Nikolai Godager s147790 Einar Drivdal s147782 Chau Quoc Quo Do s147792 PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi

Detaljer

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet

Utvikle en prototype for en digital versjon av helsekort for gravide. Programvareleverandør av ehelse-løsninger for helsevesenet Kravspesifikasjon Hovedprosjekt 2014 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Tittel: Oppgave: Gruppemedlemmer: Digitalt Helsekort for Gravide Utvikle en prototype

Detaljer

Forprosjekt gruppe 13

Forprosjekt gruppe 13 Forprosjekt gruppe 13 Presentasjon Tittel: Oppgave: Periode: Gruppemedlemmer: Veileder: Oppdragsgiver: Kontaktperson: Mobilbillett i HTML5 Utvikle en mobil billettautomat innenfor kategorien dedikert web

Detaljer

Bachelorprosjekt 2015

Bachelorprosjekt 2015 Bachelorprosjekt 2015 Høgskolen i Oslo og Akershus Tam Ha (s171513) Arslan Yousaf (s189135) Gabriel Noraker Alfarrustad (s161910) Eivind Lund (s180381) Phillip Padiernos Næss (s162951) Forprosjekt Prosjektets

Detaljer

Høgskolen i Oslo og Akershus

Høgskolen i Oslo og Akershus Høgskolen i Oslo og Akershus Gruppe 2 Forprosjektrapport Presentasjon Oppdragsgiver: Prosjekttittel: Definisjon: Accenture Shera Shera er en «event»-applikasjon til Android der man kan registrere arrangementer

Detaljer

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni.

KRAVSPESIFIKASJON. Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. KRAVSPESIFIKASJON Tittel: Pris++ Oppgave: Utvikle en Android applikasjon med tilhørende databasesystem. Periode: 1. Januar til 11. Juni. Prosjektgruppe: 27 Prosjektmedlem: Ole Almenning Stenhaug Veileder.

Detaljer

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus

Hovedprosjekt 2014, Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 2 Hovedprosjekt 2014, Høgskolen i Oslo og Akershus 1 INNHOLD 2 Presentasjon... 2 2.1 Gruppen medlemmer... 2 2.2 Oppgave... 2 2.3 Oppdragsgiver... 2 2.4 Veileder... 2 3 Sammendrag...

Detaljer

Del IV: Prosessdokumentasjon

Del IV: Prosessdokumentasjon 1 2 Forord Dette dokumentet omhandler detaljert beskrivelse av vår arbeidsprosess gjennom hele perioden med prosjektet. Prosessdokumentasjonen er en viktig del av sluttrapporten, og er delt opp i følgende

Detaljer

KRAVSPESIFIKASJON FORORD

KRAVSPESIFIKASJON FORORD KRAVSPESIFIKASJON FORORD Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg

Detaljer

Vedlegg Side 83 av 155

Vedlegg Side 83 av 155 4 Side 83 av 155 Innholdsfortegnelse 1 Kravspesifikasjon... 86 2 Kravspesifikasjon 2.0... 92 3 Domenemodell... 98 4 UseCase Diagram Oversikt... 102 6 Detaljert beskrivelse av UseCase Diagram... 106 Webapplikasjon...

Detaljer

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634

Forprosjekt. Accenture Rune Waage, rune.waage@accenture.com, 91605634 Forprosjekt Presentasjon Gruppe 19: Event-planlegger Andreas Berglihn s169991 Harald R. Svendsen s127142 Gruppe Gruppe 19 Andreas Berglihn, s169991 Harald R. Svendsen s127142 Oppgave Eventplanlegger Utvikle

Detaljer

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer...

1. Forord... 2 2. Innholdsfortegnelse... 3 3 innledning... 5. 4. Funksjonelle egenskaper og krav... 7. 5. Spesifikke krav av delsystemer... Side 1 1. Forord Dette dokumentet er en kravspesifikasjon og har blitt utarbeidet av arbeidsgiver og prosjektgruppen. Dokumentet består av ni kapitler. Det vil først bli presentert hvem prosjektgruppen

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Kravspesifikasjon Forord Kravspesifikasjonen skal beskrive applikasjonens funksjonalitet og betingelsene som oppdragsgiver krever. Det skal også hjelpe utviklerne med å begrense applikasjonen slik at den

Detaljer

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen.

Artist webside. Gruppe medlemmer Joakim Kartveit. Oppdragsgiver Tetriz Event & Management. Frode Mathiesen. Gry Anita Nilsen. Artist webside Innhold Artist webside...1 Gruppe medlemmer...1 Oppdragsgiver...1 Kontaktperson...2 Veileder...2 Oppgaven...2 Muligheter...2 Sammendrag...2 Dagens situasjon...2 Mål og rammebetingelser...3

Detaljer

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester.

Kunden er en av Norges ledende leverandører av digital-tv og bredbåndstjenester. 1 Forord Hensikten med kravspesifikasjonen er å gi oppdragsgiver og utviklere en enighet og forståelse av funksjonaliteten til applikasjonen som skal produseres. en definerer i tillegg prosjektets rammer

Detaljer

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo

Hovedprosjekt i ingeniørfag, data, våren 2015. Oslo 19.01.2015. Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Hovedprosjekt i ingeniørfag, data, våren 2015 Oslo 19.01.2015 Gruppe 23 Torstein Frogner, Bernt Kristoffer Helland, Vahid Khairkhah, Jonas Myren Mo Forprosjektrapport Presentasjon Tittel: Pizzaplutselig.no

Detaljer

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535)

Hovedprosjekt 2011. Høgskolen i Oslo. Gruppe 24. Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Hovedprosjekt 2011 Høgskolen i Oslo Gruppe 24 Tore Holmboe (s155547) Vegard Kamben (s148147) Anders Fohlin Kjøde (s155551) Haakon Nygård (s155535) Stian Pettersen (s144449) en RSS-leser på tvers av touchenheter

Detaljer

Dokument 1 - Sammendrag

Dokument 1 - Sammendrag Dokument 1 - Sammendrag Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Innholdsfortegnelse Sammendrag 1 1. Innledning 1 2. Om

Detaljer

Produktrapport Gruppe 9

Produktrapport Gruppe 9 Forord Dette dokumentet er ment for personer som skal vedlikeholde, endre eller utvikle systemet. Produktdokument innholder informasjoner om programmets funksjoner og hvordan de fungerer. Før bruk av dette

Detaljer

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm

Forprosjektrapport. Gruppe 26. Digitalt læreverktøy for Cappelen Damm Hovedprosjekt i informasjonsteknologi 2016 Høyskolen i Oslo og Akershus Forprosjektrapport Digitalt læreverktøy for Cappelen Damm Gruppe 26 Sofia Aittamaa - s198580@stud.hioa.no Petter Lysne - s198579@stud.hioa.no

Detaljer

FORPROSJEKT RAPPORT PRESENTASJON

FORPROSJEKT RAPPORT PRESENTASJON FORPROSJEKT RAPPORT PRESENTASJON Tittel: Oppgave: Appenes App Utvikle en Windows 8.1 Applikasjon for Tablet, og en Windows 8 Phone App og en backend. Periode: 06.01.2013-27.05.2013 Gruppemedlemmer: Athavan

Detaljer

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas

Testrapport Prosjekt nr. 2011-22 Det Norske Veritas Prosjekt nr. 2011 22 Testrapport Hovedprosjektets tittel Implementering av plugin og utvikling av wizard for Det Norske Veritas Prosjektdeltakere Magnus Strand Nekstad s156159 Jørgen Rønbeck s135779 Dato

Detaljer

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk

Produktdokumentasjon. Madison Møbler Administrasjonsside og Nettbutikk Produktdokumentasjon Madison Møbler Administrasjonsside og Nettbutikk 1 1. Forord 1.1 Dokumentasjonen Dette er en teknisk dokumentasjon på produktet som er utviklet. Denne er tiltenkt personer med teknisk

Detaljer

Testrapport. Studentevalueringssystem

Testrapport. Studentevalueringssystem Testrapport Studentevalueringssystem 1 Forord 1.2 Forord Dette prosjektet er et hovedprosjekt i data ved Høgskolen i Oslo, avdeling for ingeniørutdanning, og gjennomføres i samarbeid med Ingeniøravdeling

Detaljer

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell

Forprosjektrapport. Universelt LæringsVerktøy (ULV) Å lage en læringsplattform som tilfredsstiller alle krav til universell Forprosjektrapport Presentasjon Tittel: Oppgave: utforming Periode: Gruppemedlemmer: Hafnor Prosjektgruppe: Veileder: Oppdragsgiver: Kontaktperson: Nettside for gruppa: Universelt LæringsVerktøy (ULV)

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Produktrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Produktrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Produktrapport 1 Innholdsfortegnelse 1 Innholdsfortegnelse... 1 2 Produktdokumentasjon... 2 3 Beskrivelse av mobilapplikasjonen...

Detaljer

Presentasjon. Kristian Hewlett- Packard 29.05.2012

Presentasjon. Kristian Hewlett- Packard 29.05.2012 2012 Presentasjon Kristian Hewlett- Packard 29.05.2012 1 Innledning Denne innledningen inneholder informasjon om gruppen, samt bakgrunn og mål for oppgaven og en introduksjon til temaet. 1.1 Gruppen Vår

Detaljer

Multi-Faktor Autentisering. Brukerveiledning

Multi-Faktor Autentisering. Brukerveiledning Multi-Faktor Autentisering Brukerveiledning 1 Innhold Innledning... 3 Telefonanrop (standard)... 3 Oppsett... 3 Bruk... 3 Mobil App (valgfri)... 4 Oppsett... 4 Bruk... 5 Multi-Faktor portal...7 Pålogging...7

Detaljer

4.5 Kravspesifikasjon

4.5 Kravspesifikasjon 4.5 Kravspesifikasjon 4.5.1 Funksjonalitet og systembeskrivelse Webapplikasjonen har tre overordnede funksjoner; Opprett Spotify arrangement, Opprett SoundCloud arrangement og Bli med på arrangement. Brukere(kalt

Detaljer

GC4AXWG [WHERE DO YOU WANT TO GO TODAY?] av thomfre. En introduksjon til Wherigo og Wherigo-cacher

GC4AXWG [WHERE DO YOU WANT TO GO TODAY?] av thomfre. En introduksjon til Wherigo og Wherigo-cacher GC4AXWG av thomfre [WHERE DO YOU WANT TO GO TODAY?] En introduksjon til Wherigo og Wherigo-cacher [EN INTRODUKSJON TIL WHERIGO].--.....-... --. --- Innholdsfortegnelse Hva er Wherigo?... 2 Wherigo-moduler...

Detaljer

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport

Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013. Testrapport Eventhandler Teknologi, kunst og design Høgskolen i Oslo og Akershus, våren 2013 Testrapport 1 INNHOLDSFORTEGNELSE 1 INNHOLDSFORTEGNELSE... 1 2 Innledning... 2 3 Formål med testing... 3 3.1 Funksjonalitet...

Detaljer

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad

Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini og Erling Fjelstad Forprosjektrapport Presentasjon Tittel: Oppgave: Infront SSO Utvikle en Single Sign-on løsning for Infront Periode: 8/1-2013 28/5-2013 Gruppemedlemmer: Jon Hammeren Nilsson, Anders Emil Rønning, Lars Grini

Detaljer

Brukerveiledning WordPress. Innlogging:

Brukerveiledning WordPress. Innlogging: Brukerveiledning WordPress Her er en liten guide for hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging Lage en side Lage et innlegg Innlogging: For å logge

Detaljer

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer...

Presentasjon... 3. Sammendrag... 4. Dagens situasjon... 5. Mål og rammebetingelser... 5. Moduler... 6. Løsning og alternativer... Innholdsfortegnelse Presentasjon..................................................... 3 Sammendrag.................................................... 4 Dagens situasjon.................................................

Detaljer

Komme igang med App Inventor Introduksjon App Inventor PDF

Komme igang med App Inventor Introduksjon App Inventor PDF Komme igang med App Inventor Introduksjon App Inventor PDF Introduksjon Dette er en introduksjon til MIT App Inventor, hvor du skal lære å lage applikasjoner til Android. Å lage apps i App Inventor er

Detaljer

VEDLEGG 1 KRAVSPESIFIKASJON

VEDLEGG 1 KRAVSPESIFIKASJON VEDLEGG 1 KRAVSPESIFIKASJON INNHOLDSFORTEGNELSE Forord... 2 1 Systembeskrivelse... 2 2 Mål for systemet... 3 3 Funksjonelle krav... 4 4 Ikke-funksjonelle krav... 5 5 Use-case diagram... 6 6 Rammekrav...

Detaljer

1 Del I: Presentasjon

1 Del I: Presentasjon 1 Del I: Presentasjon 2 Forord Denne sluttrapporten er skrevet av gruppe 12 som består av 4 studenter som studerer ved Høgskolen i Oslo og Akershus. Vi studerer Anvendt datateknologi og denne rapporten

Detaljer

1. Forord 2. Leserveiledning

1. Forord 2. Leserveiledning KRAVSPESIFIKASJON 1 1. Forord Hensikten med kravspesifikasjonen er at den skal fungere som et styringsdokument under prosessen og definere rammer og betingelser rundt hovedprosjektet. Den er utviklet etter

Detaljer

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495

Kravspesifikasjon. Android app for aktivering av jakt- og fiskekort. Bacheloroppgave vår 2014. Høgskolen i Oslo og Akershus. Charlotte Sjøthun s180495 Charlotte Sjøthun s180495 Nanna Mjørud s180477 Anette Molund s181083 Kravspesifikasjon Android app for aktivering av jakt- og fiskekort Bacheloroppgave vår 2014 Høgskolen i Oslo og Akershus Forord Hensikten

Detaljer

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie

Hovedprosjekt 2013. Gruppe 27. Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie 2013 Hovedprosjekt 2013 Gruppe 27 Forprosjektrapport [GILJE AS] Lars Gjestang - Hiran Piapo - Bård Skeie Innhold 1. Presentasjon... 2 2. Sammendrag... 2 3. Dagens Situasjon... 2 4. Mål og rammebetingelser...

Detaljer

>> Fronter@NIH på 1 2 3 Studenter

>> Fronter@NIH på 1 2 3 Studenter >> Fronter@NIH på 1 2 3 Studenter Ved Norges idrettshøgskole, NIH bruker vi læringsplattformen Fronter i forbindelse med undervisningen. Denne korte veiledningen tar for seg de viktigste funksjonene for

Detaljer

Lærebok. Opplæring i CuraGuard. CuraGuard Opplæringsbok, - utviklet av SeniorSaken -

Lærebok. Opplæring i CuraGuard. CuraGuard Opplæringsbok, - utviklet av SeniorSaken - Lærebok Opplæring i CuraGuard 1 Med dette heftet gis en innføring i hvordan bruke CuraGuard og andre sosiale medieplattformer med fokus på Facebook. Heftet er utviklet til fri bruk for alle som ønsker

Detaljer

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive,

som blanker skjermen (clear screen). Du får en oversikt over alle kommandoene ved å skrive, 1. Last ned og installer XAMPP. 2. Sjekk at alt fungerer. 3. MySQL. Vi begynner med databaseserveren, MySQL. Gå til DOS klarmelding eller ledetekst (finnes under tilbehør på startmenyen om du ikke som

Detaljer

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen

Hovedprosjekt i informasjonsteknologi våren 2014. Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Hovedprosjekt i informasjonsteknologi våren 2014 Oslo 22.01.2014 Gruppe 32 - Erik M. Forsman, Lars H. Nordli og Simen A. Hansen Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Meso

Detaljer

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften

Kravspesifikasjon. Leserveiledning Kravspesifikasjonen består av følgende deler: Presentasjon Om bedriften Kravspesifikasjon Presentasjon Hovedprosjektet gjennomføres ved Høgskolen i Oslo, avdelingen for ingeniørutdanning. Målet med oppgaven er å utvikle en online webshop for bestilling av postkasser. Dette

Detaljer

Oblig 5 Webutvikling. Av Thomas Gitlevaag

Oblig 5 Webutvikling. Av Thomas Gitlevaag Oblig 5 Webutvikling Av Thomas Gitlevaag For oppgave 1 og 2 skal dere levere en funksjonell webside på deres hjemmeområde. Dere skal også levere alle phps-filene slik at man for en hver side kan slenge

Detaljer

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18

HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 HOVEDPROSJEKT 2010 - HIO IU - DATA FORPROSJEKTRAPPORT GRUPPE 18 INNHOLDSFORTEGNELSE 1. PRESENTASJON 2. SAMMENDRAG 3. DAGENS SITUASJON 4. MÅL OG RAMMEBETINGELSER 5. LØSNINGER \ ALTERNATIVER 6. ANALYSE AV

Detaljer

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon.

Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon. Møtereferater: HP36 uke 2, 10.1.2012: Gruppemedlemmer: Christian Salater Magne Hjermann Zunaira Afzal Tola Sarzali Waleed Abtidon Møtereferat: 1. møte med veileder I dette møtet presenterte vi oss for

Detaljer

Administrering av SafariSøk

Administrering av SafariSøk Administrering av SafariSøk Administrering av SafariSøk Revisjonshistorie Revisjon $Revision: 1.6 $ $Date: 2003/08/05 12:44:02 $ Innholdsfortegnelse 1. Om programmet... 1 Generelt... 1 2. Fremgangsmåter...

Detaljer

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus

Forprosjektrapport. Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Presentasjon Gruppenummer: 21 Forprosjektrapport Hovedprosjekt 2015 Institutt for informasjonsteknologi, Høgskolen i Oslo og Akershus Gruppemedlemmer: Guro Asbjørnsen, Ester Jansson, Marius Skalstad og

Detaljer

Thursday, August 19, 2010. Web-prosjekt

Thursday, August 19, 2010. Web-prosjekt Web-prosjekt Om kurset Organisering av kurset Består av to hoveddeler: Webpublisering Prosjektarbeid Motivasjon Web Lære å utvikle websider Lære prinsipper for brukervennlighet og tilgjengelighet Skrive

Detaljer

VMware Horizon View Client. Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang

VMware Horizon View Client. Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang VMware Horizon View Client Brukerveiledning for nedlasting, installasjon og pålogging for fjerntilgang Introduksjon Fjerntilgang er blitt oppgradert til en bedre og mer moderne løsning. Programmet er identisk

Detaljer

S y s t e m d o k u m e n t a s j o n

S y s t e m d o k u m e n t a s j o n S y s t e m d o k u m e n t a s j o n Monitorering av produksjonsløyper ved Nasjonalbiblioteket - Project BAKE Utarbeidet av: Einar Wågan Kristian Akerhei Studium: Informasjonssystemer Innlevert: 26.5.2015

Detaljer

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93

TESTRAPPORT... 91 FORORD... 91 INNHOLD... 92 23 INNLEDNING... 93 24 TEST AV SYSTEMET... 93. 24.1 Databasen og SQL spørringer... 93 90 Testrapport Forord Dette dokumentet er testrapporten for hovedprosjektet, og skal gi en oversikt over all testing utført på systemet under og etter ferdigstilling, samt feil og løsninger gruppen har

Detaljer

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort

Forprosjektrapport. Presentasjon. Studentgruppen. Bekk Consulting AS. Android app for aktivering av jakt- og fiskekort Forprosjektrapport Presentasjon Tittel: Oppgave: Gruppemedlemmer: Prosjektgruppe: Veileder: Hovedoppdragsgiver: Kunde av oppdragsgiver: Ansvarlig for gruppen: Faglig veileder hos BEKK: Android app for

Detaljer

Del VII: Kravspesifikasjon

Del VII: Kravspesifikasjon 1 2 Forord Dette dokumentet inneholder retningslinjer for gruppen vår og beskrivelse av betingelsene for utviklingen av vårt prosjekt. Vår gruppe benyttet dette dokumentet som et styringsdokument for å

Detaljer

Compello Invoice Approval

Compello Invoice Approval Compello Invoice Approval Godkjenning Webmodul brukerdokumentasjon Nettbrett og desktop via nettleser Index 1 Innledning... 3 2 Funksjonalitet... 4 Nettbrett og desktop via nettleser... 4 2.1.1 Desktop

Detaljer

PROSESSDOKUMENTASJON

PROSESSDOKUMENTASJON PROSJEKT NR.: 10-30 Studieprogram: Anvendt Datateknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo TILGJENGELIGHET: Papir og elektronisk Telefon: 22 45 32 00

Detaljer

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav.

Funksjonskravene er delt opp i to deler, krav til spillsekvens og generelle funksjonskrav. Kravspesifikasjon I dette kapittelet foreligger kravspesifikasjonen som ble utformet tidlig i prosjektprosessen. Dette er den opprinnelige kravspesifikasjonen. Det har igjennom prosjektprosessen vært naturlig

Detaljer

WordPress. Brukerveiledning. Kjære kunde. Innlogging:

WordPress. Brukerveiledning. Kjære kunde. Innlogging: Brukerveiledning WordPress Sist oppdatert: 26.02.2014 Kjære kunde Her er en liten guide for å hjelpe deg gjennom det grunnleggende i Wordpress. Denne veilederen vil ta deg gjennom: Innlogging - s.1 Kontrollpanel

Detaljer

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av:

Forprosjektrapport for Agresso R&D Ansettelsessystem 31.01.07. Hovedprosjekt våren 2007. Skrevet av: Forprosjektrapport for Agresso R&D Ansettelsessystem Hovedprosjekt våren 2007 31.01.07 Skrevet av: Anders Hartvoll Ruud Christian Årving Leif Martin Næss Sahdia Fayyaz Moghal 1 Sammendrag Prosjektittel:

Detaljer

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra.

kan flere studenter falle av underveis, da det er vanskelig for faglærer å se hvem som kan ha nytte av å følges opp ekstra. Visjonsdokument 1 Introduksjon Dette prosjektet er gitt av Svend Andreas Horgen, og gjennomføres som en prosjektoppgave i faget TDAT3022-A 14H Systemutviklingsprosjekt ved HiST, AiTEL. Hensikten med dette

Detaljer

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1

KRAVSPESIFIKASJON. Gruppe 2. Hovedprosjekt, Høgskolen i Oslo og Akershus. Våren 2014 KRAVSPESIFIKASJON 1 KRAVSPESIFIKASJON Gruppe 2 Hovedprosjekt, Høgskolen i Oslo og Akershus Våren 2014 KRAVSPESIFIKASJON 1 CONTENTS 1. Forord... 3 2. Presentasjon... 3 2.1 Gruppens medlemmer... 3 2.2 Oppdragsgiver... 3 2.3

Detaljer

Norsk Data Senter AS Installasjon av Intentor Helpdesk

Norsk Data Senter AS Installasjon av Intentor Helpdesk Intentor Helpdesk - Installasjon Step #1: Generell informasjon Dokumentasjon levert av: Prosjekt:. Norsk Data Senter AS Installasjon av Intentor Helpdesk Norsk Data Senter AS e-post info@nds.no ORG. NR.

Detaljer

BRUKERMANUAL. Deviations and Reporting

BRUKERMANUAL. Deviations and Reporting BRUKERMANUAL Deviations and Reporting Forord Dette er brukermanual for CEMAsys Immediate Reporting applikasjon som er laget for iphone og Android telefoner. CEMAsys Immediate Reporting er en applikasjon

Detaljer

Båtforening på nett. Produktrapport

Båtforening på nett. Produktrapport Båtforening på nett Hovedprosjekt våren 2009, Høgskolen i Oslo Prosjektgruppe 36 Vegard Skipnes, Rade Vuckovic & Frode Sørensen Produktrapport 1 Sammendrag Denne rapporten er en del av Hovedprosjektet

Detaljer

Publiseringsløsning for internettsider

Publiseringsløsning for internettsider Publiseringsløsning for internettsider Hva er Edit? Edit er et verktøy for publisering og vedlikehold av nettsider. Tidligere har det å vedlikeholde en nettside vært en tungvinn prosess, men nå kan alle

Detaljer

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl

Kravspesifikasjon. Kravspesifikasjon Gruppe nr 10 Hårgalleriet. DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl Kravspesifikasjon HOVEDPROSJEKTETS TITTEL Bestillingssystem for frisørsalong PROSJEKTDELTAKERE Endre Gulbrandsen (s150690) DATO 08. februar 2011 ANTALL SIDER 8 INTERN VEILEDER Tor Krattebøl OPPDRAGSGIVER

Detaljer

Brukermanual. Studentevalueringssystem

Brukermanual. Studentevalueringssystem Brukermanual Studentevalueringssystem 1 Forord 1.1 Forord Denne brukermanualen innholder beskrivelse av systemets funksjonalitet og introduserer systemet for brukeren. Brukermanualen er delt inn i tre

Detaljer

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen

1 Inledning. 1.1 Presentasjon. Tittel Informasjonsplattform for NorgesGruppen. Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Kravspesifikasjon 1 Inledning 1.1 Presentasjon Tittel Informasjonsplattform for NorgesGruppen Oppgave Utvikle en informasjonsplattform for butikkene i NorgesGruppen Periode 3. Januar 14. Juni Gruppemedlemmer

Detaljer

Testdokumentasjon. Testdokumentasjon Side 1

Testdokumentasjon. Testdokumentasjon Side 1 Testdokumentasjon Testdokumentasjon Side 1 1. Innledning Dette er en testrapport som er laget for å teste applikasjonene for ios og Android plattformer. Den vil være delt opp i 4 deler. Den første delen

Detaljer

Prosjekt. Halvårs-rapport. til fordypning. Eva-Anita Thorsen 2MKA. 7.Januar, 2010

Prosjekt. Halvårs-rapport. til fordypning. Eva-Anita Thorsen 2MKA. 7.Januar, 2010 1 0 Prosjekt 7.Januar, 2010 til fordypning Eva-Anita Thorsen 2MKA Halvårs-rapport 0.1 innhold 2 INFO SIDE Innhold 2 Innledning 3 Hoveddel 4-8 Avslutning 9 Logg 10-12 Bakside 13 0.2 innledning 3 Innledning

Detaljer

Tjenestebeskrivelse Webhotelltjenester

Tjenestebeskrivelse Webhotelltjenester Tjenestebeskrivelse Webhotelltjenester Sist endret: 2004-12-01 Innholdsfortegnelse 1 INTRODUKSJON... 3 1.1 GENERELT... 3 1.2 NYTTEVERDI WEBHOTELLTJENESTER FRA TELENOR... 3 2 FUNKSJONALITET... 4 2.1 INNHOLD

Detaljer

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON

Hovedprosjekt ved Høgskolen i Oslo våren 2011 CHARITY DOCTORS KRAVSPESIFIKASJON CHARITY DOCTORS KRAVSPESIFIKASJON Hovedprosjekt i informasjonsteknologi ved Høgskolen i Oslo våren 2011 Gruppe 13 Muleha Nhonzi Harlem Tambwe Mufoncol Ruban Amuthalingam Page 1 of 6 1 Innledning 1.1 Innledning

Detaljer

1. Programmering: Hva og hvorfor? Scratch fra scratch Enkel programmering for nybegynnere

1. Programmering: Hva og hvorfor? Scratch fra scratch Enkel programmering for nybegynnere 1. Programmering: Hva og hvorfor? 1. Programmering: Hva og hvorfor? Du har nå valgt å lære deg å programmere. Gratulerer med et flott valg! Programmering er en allsidig og nyttig aktivitet, og det er et

Detaljer

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9

Forprosjektrapport. Gruppe 17. Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen. Side 0 av 9 Forprosjektrapport Gruppe 17 Askar Mehdi, Thomas Tykesson, Magnus Arneberg Nilsen Side 0 av 9 Innholdsfortegnelse: Presentasjon - Service Broker AS - Kontaktpersoner Sammendrag Dagens situasjon Mål og

Detaljer

Kandidat nr. 1, 2 og 3

Kandidat nr. 1, 2 og 3 Kandidat nr. 1, 2 og 3 Rapport 1 IT202E Bacheloroppgave i Informatikk Vår 2011 Mobilapplikasjonsutvikling med Scrum 1 Innhold Innledning... 3 Overordnet Prosjektplan... 3 Produktbacklog... 5 Sprint planning

Detaljer

Norsk Data Senter AS Oppgradering av Intentor Helpdesk

Norsk Data Senter AS Oppgradering av Intentor Helpdesk Intentor Helpdesk - Oppgradering Step #1: Generell informasjon Dokumentasjon levert av: Prosjekt:. Norsk Data Senter AS Oppgradering av Intentor Helpdesk Norsk Data Senter AS e-post info@nds.no ORG. NR.

Detaljer

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no

Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Presentasjon av hovedprosjekt ved HIST Nettbutikk www.midt-svartdal.no Hovedprosjekt 2008 av Audun M. Solheim, student HIST/BAIN, audun@c2i.net Oppdragsgiver:Bjørg Minnesjord Solheim, bjorg@midt-svartdal.no

Detaljer

Prosjektdagbok Gruppe 18

Prosjektdagbok Gruppe 18 Prosjektdagbok Gruppe 18 Dato: 14.05.2014 25.05.2014 Oppmøte: Alle I denne perioden har vi sittet alle mann på skolen nesten hele tiden. Vi har jobbet sammen om sluttdokumentasjonen. Selv om vi all hovedsak

Detaljer

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress

KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress KOM I GANG MED WORDPRESS En enkel guide for å hjelpe deg gjennom det grunnleggende i Wordpress Sist oppdatert 05.06.2015 Innholdsfortegnelse 1. Hva er Wordpress?... 3 2. Hvordan logger jeg inn i kontrollpanelet?...

Detaljer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer

Kravspesifikasjon. Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011. Gruppemedlemmer Kravspesifikasjon Høgskolen i Oslo, våren 2011 Sted og dato: Oslo, 9. februar 2011 Gruppemedlemmer Adeel Yousaf Khan s141459 Mats Klingenberg Naustdal s148155 Nur M. Ahmed s148108 Thomas Wiborg s161335

Detaljer

Denne ukens mål: Avtale møte med MediaLT Fortsette research rundt MS og få systematisert bedre den informasjonen vi har funnet.

Denne ukens mål: Avtale møte med MediaLT Fortsette research rundt MS og få systematisert bedre den informasjonen vi har funnet. Ukesmål Grunnet en del problemer med blog-siden vår (www.nettverkskort.com/hovedprosjekt) og tidligere uoversiktlig oppsett, har vi valgt å samle alle ukesmålene opp igjennom prosjektet i dette dokumentet.

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer

Introduksjon til Min Sky - http://min-sky.no

Introduksjon til Min Sky - http://min-sky.no Introduksjon til Min Sky - http://min-sky.no Min Sky 1 Velkommen til Min Sky! Min Sky er en tjeneste for å lagre dine bilder og filer enkelt og trygt i nettskyen. Når disse er lagret kan du se dem på din

Detaljer

Programmeringsrammeverk som kan installeres på Windows Mobiloperativsystem

Programmeringsrammeverk som kan installeres på Windows Mobiloperativsystem .NET Android AOSP Programmeringsrammeverk som kan installeres på Windows operativsystem Mobiloperativsystem Android Open Source Project. Har i oppgave å vedlikeholde og videreutvikle Android operativsystem.

Detaljer

Brukerveiledning for nedlastning og installasjon av Office 2013. Av Roar Nubdal, fagprøve IKT-servicefag, juni 2014

Brukerveiledning for nedlastning og installasjon av Office 2013. Av Roar Nubdal, fagprøve IKT-servicefag, juni 2014 Brukerveiledning for nedlastning og installasjon av Office 2013 Av Roar Nubdal, fagprøve IKT-servicefag, juni 2014 1 Innhold Brukerveiledning for nedlastning og installasjon av Office 2013... 1 Info...

Detaljer

Kjørehjelperen Testdokumentasjon

Kjørehjelperen Testdokumentasjon 2013 Kjørehjelperen Testdokumentasjon Høgskolen i Oslo og Akershus Henrik Hermansen og Lars Smeby Gruppe 8 26.05.2013 Forord Dette dokumentet tar for seg to forskjellige ting. Først forklares det hvordan

Detaljer

Installere JBuilder Foundation i Windows XP

Installere JBuilder Foundation i Windows XP Installere JBuilder Foundation i Windows XP Installasjon av JBuilder Foundation på Windows (dekker her spesifikt fremgangen ved bruk av Microsoft Windows XP Professional, men det vil mest trolig ikke være

Detaljer

Brukermanual for nettpublisering. frivilligsentral.no

Brukermanual for nettpublisering. frivilligsentral.no Brukermanual for nettpublisering frivilligsentral.no Innholdsfortegnelse Introduksjon 3 1 - Innlogging 4 1.1 - Logge inn 4 1.1 - Logge ut 4 2 - Grensesnitt 5 2.1 - Menyfelt 5 2.2-3 - Opprette, lagre og

Detaljer

KRAVSPESIFIKASJON FOR SOSIORAMA

KRAVSPESIFIKASJON FOR SOSIORAMA KRAVSPESIFIKASJON FOR SOSIORAMA Innhold 1. Forord... 2 2. Definisjoner... 3 3. Innledning... 4 3.1 Bakgrunn og formål... 4 3.2 Målsetting og avgrensninger... 4 4. Detaljert beskrivelse... 8 4.1 Funksjonelle

Detaljer

Mobil rapportering for Android og ios PROSESSRAPPORT. Deviations and Reporting

Mobil rapportering for Android og ios PROSESSRAPPORT. Deviations and Reporting Mobil rapportering for Android og ios PROSESSRAPPORT Deviations and Reporting FORORD Vi ønsker å takke vår veileder Simen Hasselknippe for veldig god veiledning gjennom hele prosjektet, resultatet hadde

Detaljer

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet.

DAGBOK. Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. DAGBOK Uke 43: Torsdag 28/10 Patrick - Opprettet blogside for å kunne legge ut informasjon om hva som skjer underveis i prosjektet. Uke 44: Mandag 1/11 Gruppen utformet den første statusrapporten til prosjektet.

Detaljer

Innstallasjon og oppsett av Wordpress

Innstallasjon og oppsett av Wordpress Del 1 - Installasjon og oppsett Innstallasjon og oppsett av Wordpress Wordpress har blitt en veldig populær publiseringsplattform for websider. Uten særlige tekniske ferdigheter kan man sette opp profesjonelle

Detaljer

BRUKERMANUAL. Telsys Online Backup

BRUKERMANUAL. Telsys Online Backup BRUKERMANUAL Telsys Online Backup TELSYS AS - 06.08.2009 Innhold Generelt... 3 Kom i gang... 4 Installasjon av Telsys Online Backup Proff/Standard... 4 Start opp klienten for første gang!... 10 Logg inn...

Detaljer

- reklamebannere mobil og tablet

- reklamebannere mobil og tablet Spesifikasjoner - reklamebannere mobil og tablet FINN.no Versjon 2.4 Sist oppdatert 16.08.2013 1. Innhold Innhold Introduksjon Målsetning Spesifikasjoner HTML Fysisk størrelse 225 px* Eksempler Størrelser

Detaljer

[GILJE SELSKAPSLOKALER]

[GILJE SELSKAPSLOKALER] 2013 Hovedprosjekt 2013 Gruppe 27 Kravspesifikasjon [GILJE SELSKAPSLOKALER] Lars Gjestang - Hiran Piapo - Bård Skeie Kravspesifikasjon 1 Presentasjon 1.1 Innledning Dette prosjektet er et hovedprosjekt

Detaljer