IT1901 Informatikk Prosjektarbeid I. Sheep Locator

Størrelse: px
Begynne med side:

Download "IT1901 Informatikk Prosjektarbeid I. Sheep Locator"

Transkript

1 IT1901 Informatikk Prosjektarbeid I Sheep Locator Gruppe november 2013 Thomas Gautvedt Aina Elisabeth Thunestveit Jostein Granli Geir Forslund Roar Gjøvaag

2 Innhold 1 Introduksjon Om prosjektet Om oppgaven Om gruppen Organisering Strukturering Arbeidsorganisering Møtereferat Organiseringsverktøy Facebook Trello Google Drive Git & GitHub Gantter Gruppens forkunnskaper Ansvarsområder Planlegging Risikoanalyse Kravspesifikasjon Work Breakdown Structure Tidsestimering Gantt Use case Sekvensdiagram Utviklingsprosess Scrum Organisering i Git Utviklingsverktøy Balsamiq Mockups Xcode Tekstredigeringsprogrammer LaTeX Databaseprogrammer Filopplastning Bilderedigering Nettlesere Annet I

3 5 Arkitektur Oversikt arkitektur Database Databaseoppbyggelse RESTful API Oppbygging av APIet Teknisk forklaring JSON-string App Teknisk oppbygging Ajax-kall Templates Rammeverk jquery og jquery UI Google Maps API v Underscore.js Moment.js Design Simulator Testing Enhetstesting Systemtesting Funksjonalitet Negativitets testing Ytelse Sikkerhet Stress Gjenoppretting Brukbarhetstesting Akseptansetesting Dimensjonstesting Manualer & innloggingsdetaljer Brukermanual Brukermanual Teknisk brukermanual Innloggingsdetaljer Oppsummering 23 II 23

4 1 Introduksjon 1.1 Om prosjektet Denne rapporten er skrevet for å oppsummere resultatet av prosjektet som ble gjennomført av gruppe 6 i forbindelse med faget IT1901 Informatikk prosjektarbeid I ved NTNU i Trondheim høsten Målet med dette prosjektet er å simulere en utviklingsprosess der en gruppe skal utvikle et program for en fiktiv kunde. Hovedmålet er at gruppen skal oppleve og prøve vanlige metoder og teknikker, i hovedsak Scrum, for å jobbe som en gruppe og erfare hvordan disse metodene fungerer i praksis. Et annet aspekt ved oppgaven er å videreutvikle gruppens kunnskaper om programmering. Vi har valgt å løse oppgaven ved hjelp av et RESTfult web API, som er skrevet i PHP og som snakker med en HTML5 app. Vår løsning er ytterligere forklart i kapittel Om oppgaven Oppgaven går ut på at vi skal utvikle et system for bønder til administrering av sauer. Noen av de mest vesentlige funksjonene ved dette programmet er at bonden skal ha en oversikt over alle sauene han eier og han skal kunne se hvor sauene er lokalisert på et kart. Det skal også bli sendt varsel til bonden dersom en sau er under angrep. For mer informasjon om kravspesifikasjonen se kapittel Om gruppen Gruppe 6 består av fem personer med ulik utdanningsbakgrunn og erfaring innenfor fagfeltet informatikk. Alle går pr. i dag ved linjen Bachelor i Informatikk (BIT). De 5 personene er Thomas Gautvedt 21 år som er vår mest erfarne programmerer. Aina Elisabeth Thunestveit 23 år, med bachelor i matematikk, som er den som har kommet lengst i studieløpet. Jostein Granli 21 år, første år på NTNU etter årskurs i informatikk ved høyskolen i Molde. Roar Gjøvaag 31 år, startet på informatikkstudiet i fjor etter mange år hos Nortura i Trondheimsområdet og Geir Forslund 23 år, første års student ved informatikk tidligere studier hos NTNU gjør at han befinner seg mellom første og andre årstrinn. 1

5 IT1901 Informatikk Prosjektarbeid I, Sheep Locator Gruppe 6 Figur 1.1: Fra venstre: Thomas Gautvedt, Jostein Granli, Aina Elisabeth Thunestveit, Roar Gjøvaag, Geir Forslund 2 23

6 2 Organisering 2.1 Strukturering Arbeidsorganisering Det første vi gjorde var å bestemme hvordan vi skulle organisere arbeidet. Vi startet med å gjøre oss kjent med hverandres erfaringsnivåer og interesser. Etter å ha kartlagt erfaring og kompetanse i gruppen ble vi enige om hvordan Scrum-modellen (4.1) skulle løses. Det viste seg raskt at den største utfordringen til gruppen ble timeplanen, da mer eller mindre samtlige deltok i forskjellige kurs og fag det aktuelle semesteret. Dette førte til at den sammeslåtte timeplanen ikke hadde mange åpninger. Tross dette fant vi timer der alle kunne være med på arbeidsøkter og møter. Dette ble fastsatt til å være torsdager 10:15-12:00. I tillegg skulle vi ha korte Scrum-møter på tirsdager, onsdager og fredager. Bare to uker inne i prosjekter merket vi at dette ikke var en optimal løsning for vår gruppe. Arbeidsøktene og møtene fungerte bra, mens de korte møtene mellom forelesningene ikke var hensiktsmessig fordi tiden ble brukt lite effektivt. Vi bestemte oss for å revurdere møtestrukturen, ved at kortmøtene ble byttet ut med jevnlig oppdatering gjennom sosialnettstedet Facebook (2.2.1) og prosjektstyringsverktøyet Trello (2.2.2). I tillegg utvidet vi med lengere arbeidsøkter, slik at læringsutvekslingen ble maksimert. Møtene ble fastsatt til onsdager 12:15-14:00 og torsdager 10:15-12:00, med et potensielt ekstramøte på tirsdager ved behov. Arbeidsøktene ble en arena for diskusjon, problemløsing og utveksling av kompetanse. Siden samtlige i gruppen var interesserte i å få mest mulig ut av dette faget, ble det et sterkt fokus på å få muligheten til å sitte sammen. Møtene begynte alltid med en gjennomgang av forrige møtes saksliste samt eventuelle demonstrasjoner av nye funksjoner i programmet. Etter faste punkter og gjennomgang av eventuelle sprinter, ble tiden brukt til praktisk arbeid. Stort sett ble programmeringen utført på individuell basis Møtereferat Møtereferat er skrevet som oppsummering av hva som har skjedd av ekstraordinære saker og en statusrapport for applikasjonen. Møtereferatene ble i utgangspunktet ført pr. møte, men grunnet omstrukturering av møtene ble referat skrevet pr. uke (se vedlegg: møtereferat), noe som reduserte mengden dokumenter og ga en bedre oversikt i hver sprint. Ellers er formålet med møtereferatene å holde seg oppdatert på prosjektet når man er fraværende. 3

7 2.2 Organiseringsverktøy Noe som tidlig ble bestemt var bruk av hjelpemidler til prosjektet. Det finnes et bredt utvalg av organiseringsverktøy, det var derfor viktig for oss å raskt orientere oss om behov. Vi spurte oss selv hvilke hjelpemiddeler og verktøy som kunne få oss til å gjøre en bedre og mer effektiv jobb for prosjektet. Noen av verktøyene som ble tatt i bruk, ble valgt ut på bakgrunn av risikoanalysen (se vedlegg: risikoanalyse) og dens tiltak, for eksempel backup-løsning Facebook Facebook ble kommunikasjonsplattformen til gruppen, hvor medlemmene fikk gitt og mottatt raske beskjeder om eventuelle utfordringer med prosjektet og eventuelle fravær i oppkommende møter. Vi valgte denne plattformen fordi alle på gruppen allerede hadde etablert en bruker der, og fordi løsningen var godt integrert med mobiler og de dagelige rutinene til samtlige av oss Trello Hovedverktøyet i forhold til prosjektorganisering og prosjektets praktiske arbeidsoppgaver ble Trello. Trello er et rent prosjektorganiseringsverktøy, som skal være laget for mindre prosjekter som dette og verktøyet ble også anbefalt av gruppens veileder. Verktøyet kan forklares som en digital Post-it vegg, hvor man lager notater om gjøremål, delegerer oppgaver, diskuterer løsninger og funksjonalitet. Programmet er lett å bruke og skapte raskt en oversikt over arbeidsoppgavenes status. Da dette var det beste alternativet og på grunn av anbefalingen ble dette et naturlig valg for gruppen Google Drive For å dekke opp for en av våre risikoer som var backup (se vedlegg: risikoanalyse), bestemte vi oss for at alt skulle lagres i Google Drive. Med Drive fikk vi i tillegg sammarbeidet tett om rapportskrivingen, diagram- og møtereferat justering. Vi vurderte å bruke en sky-løsning som Dropbox, men bestemte oss for å kun bruke Google Drive da den tilbydde samme funksjonalitet pluss samarbeidsmulighetene som vi har hatt stor nytte av Git & GitHub Vi har brukt versjonskontrollsystemet Git for å utvikle sammen uten å måtte bekymre oss for å skrive over hverandres filer. Vi vurderte en stund å bruke SVN da det er enklere å sette seg inn i, men grunnet tidligere erfaringer på gruppen, bestemte vi oss for å bruke Git og heller gi de som ikke hadde den samme erfaringen et kort introduksjonskurs. En beskrivelse av hvordan vi har jobbet med Git finnes i kapittel Gantter Etter litt utprøving av verktøy for å utarbeide et Gantt-diagram, falt vi på et onlineverktøy ved navn Gantter 1. Dette verktøyet ble valgt først og fremst fordi det hadde funksjonaliteten vi hadde behov for, både med tanke på eksportering, muligheter for å sette underkategorier og arbeidstimer

8 2.3 Gruppens forkunnskaper Gruppen består i hovedsak av studenter ved informatikkstudiet og majoriteten er på 2. året som Thomas Gautvedt, Jostein Granli og Roar Gjøvaag, mens Aina Elisabeth Thunestveit og Geir Forslund følger et mindre tradisjonelt studieløp. Ellers er gruppen satt sammen av meget forskjellige personligheter og bakgrunner. Thomas Gautvedt Arbeidserfaring som webutvikler Programmeringserfaring Nesten ti års erfaring med PHP, HTML, Javascript, CSS, jquery og databasesystemer, samt generell kunnskap om Java, Python, Objective C og C# Aina Elisabeth Thunestveit Bachelor i matematikk Programmeringserfaring Jostein Granli Generell Java, Python, Objective C, C# og generelt om databaser Programmeringserfaring Geir Forslund Generell Visual basic, Java, Python, databaser og strategisk webdesign Programmeringserfaring Roar Gjøvaag Generell Java og databaser Programmeringserfaring Generell Java, Python og databaser 2.4 Ansvarsområder Alle i gruppen har deltatt i alle deler av prosessen, men ansvarsområdene har vært formelt fordelt innad i gruppen. Ansvarsområdene er delt ut etter ønske og forkunnskaper. Områdene definerer ikke nødvendigvis hvem som har gjort jobben innenfor de enkelte områdene. Personen som har hatt hovedansvaret for at jobben ble gjennomført, har også fungert som en ressurs oppimot området det skulle gjelde. Thomas Gautvedt Hovedprogrammerer Git-ansvarlig App-medhjelper Aina Elisabeth Thunestveit Simulator-ansvarlig Testing Jostein Granli 5 23

9 App-medhjelper Diagram-ansvarlig Geir Forslund Databaseansvarlig App-hovedansvarlig Roar Gjøvaag Scrum-master API-ansvarlig Rapportansvarlig Git-ansvarlig har vært personen som har gått igjennom kode og godkjent pullrequsts når arbeidet var fullført. Mer informasjon om hvordan vi har jobbet og organisert i Git er beskrevet i kapittel

10 3 Planlegging 3.1 Risikoanalyse Dette var noe av det første gruppen satte i gang med, for å være forberedt på utfordringer vi kunne møte allerede fra starten. Risikoanalysen (se vedlegg: risikoanalyse) ble utarbeidet ved idèmyldring, tidligere erfaringer og tips fra veileder. Det essensielle spørsmålet var, Hvilke risikoer kan man stå ovenfor i et slikt prosjekt?. Samtlige punkter i analysen ble så gradert ved å sette en poengverdi for frekvens og konsekvens. Disse ble så multiplisert og dannet vår prioriteringsliste. Prioriteringslisten viste oss hvilke punkter vi måtte være ekstra oppmerksomme på. Deretter iverksatte vi forebyggende tiltak i forhold til prioriteringen. Se vedlegget for en mer grundig forklaring av hvert enkelt risikopunkt og dets forebyggende- og strakstiltak. I retroperspektiv ser vi også at denne listen var i henhold til faktiske forhold, men vi har vært relativt skånet for utfordringer og deres konsekvenser. Fravær fra møtene var den hyppigste, men denne typen risiko hadde svært lav konsekvens. Hadde vi ikke iverksatt forebyggende tiltak kunne dette vært destruktivt for prosjektet. 3.2 Kravspesifikasjon Vår tolkning av kravspesifikasjonen er ganske lik kundens (se vedlegg: kundens kravspesifikasjon). Underveis i prosjektet fikk vi opplyst at vi ikke skulle legge stort fokus på kravspesifikasjonens feilsituasjoner. Det er derfor ikke nevnt i vår kravspesifikasjon Vår kravspesifikasjon: Brukeren skal ha et passord og et brukernavn for å få tilgang til systemet Hver sau skal rapporterer sin lokasjon tre ganger i døgnet. Rapporteringen til samtlige sauer er spredt utover for å begrense påkjenningen på systemet. Brukeren og eventuelle varslingsadresser som er lagt til i systemet skal motta varsel både i applikasjonen og på e-post, dersom en sau er under angrep. Vi benytter en webapp som kommuniserer med en webserver (se kapittel 5 for oppbygging av arkitekturen) Større tilpasningsdyktighet Kan brukes på enheter som de fleste allerede eier og bærer med seg stort sett overalt Løsningen kan benyttes så lenge man har dekning for mobildata, praktisk under oppgaver som for eksempel sauesanking da man gjerne befinner seg i høyfjellet. Brukeren slipper noen form for installasjon, dette vil senke terskelen for å ta i bruk applikasjonen. 7

11 Systemet er dimensjonert for at over 200 bønder og sauer skal kunne håndteres samtidig. Responstiden til systemet skal være bra selv med høy belastning. Se for systemtesting av ytelse. 3.3 Work Breakdown Structure Formålet ved å sette opp et WBS-diagram (se vedlegg: Work Breakdown Structure) er å skaffe en oversikt over hovedoppgavene i prosjektet for å forenkle organisering og tidsestimering. Vi valgte å dele inn WBS i fem deler: organisering, planlegging, utvikling, testing og rapportering. Dette gjorde organiseringen av underpunktene enklere. 3.4 Tidsestimering Dette er veldig viktig for at man skal klare å levere et ferdig produkt i henhold til kravspesifikasjonene. Vi laget et Gantt-diagram for å ha en god oversikt som vi kunne følge. Da vi laget denne estimerte vi ut i fra vår egen erfaring, råd fra stud.ass og det som kom frem i forelesningene. Vi hadde i tillegg to faste holdepunkter i prosessen, midtveispresentasjonen og selvfølgelig leveringsfristen. De fleste av oss hadde ikke noe særlig erfaring med større prosjekt som dette, men vi hadde alle programmeringserfaring fra vår tid ved NTNU. Oppgavene som måtte gjøres ble lagt i sprinter basert på backlogen.(se vedlegg: backlog, sprinter og burndown chart), som vi deretter plasserte i Ganttdiagrammet vårt. Da vi hadde kommet frem til punktene vi trengte, estimerte vi timer på de forskjellige oppgavene. Vi hadde som mål å holde oss innenfor 10 timer pr. person pr. uke og med sprinter på to uker hadde vi ca. 20 timer pr. person i hver sprint. Sprintene ble lagt opp slik at de sammenfalt i stor grad med møtene våre med stud.ass. Det førte til at vi hele tiden fikk en indikasjon på hvordan vi lå an. Vi erfarte at ikke alle estimeringene våre holdt vann, både den ene og den andre veien. Heldigvis hadde vi tatt våre forholdsregler, og hadde god kontroll da det viste seg at vi måtte justere litt på estimeringen. Dette er detaljert forklart i vedlegget om risikoanalyse og illustrert i burndown chart. 3.5 Gantt Gantt-diagram er en type stolpediagram, som skal illustrere planen for prosjektet. I utgangspunktet skal den sette start- og sluttdatoer for sprinter og individuelle aktiviteter. Gantt-diagrammet har tatt utgangspunkt i Work Breakdown Structure og tidsestimeringen vi gjorde. Diagrammet gir raskt en oversikt over hvor mye som er gjort og hvor mye som står igjen, med forbehold om at tidsestimeringen er riktig. 3.6 Use case Use case er et svært enkelt diagram for å se overordnet oppbygging av systemet. Vi har laget et enkelt Use case-diagram for å illustrere de forskjellige valgene og tingene som brukeren, systemet og sauen kan foreta seg. Se vedlegget om Use case-diagram for mer detaljer. 8 23

12 3.7 Sekvensdiagram Hensikten med et sekvensdiagram er å se flyten og levetiden til ulike objekt, i tillegg til hvilke funksjoner som blir kjørt. I en vanlig Java-applikasjon, lever objektet gjennom hele programmet sin kjøretid, så sant du ikke dreper det manuelt eller det ikke er i bruk og blir plukket opp av Java sin garbage collection. Siden vi har laget en webapplikasjon vil vi i vårt tilfelle ikke få utnyttet sekvensdiagrammet til sitt fulle, fordi hvert brukerobjekt dør ved et nytt kall. Det brukeren får returnert i en forespørsel er borte til neste gang. Vi har allikevel laget noen sekvensdiagram som du kan se i vedlegget sekvensdiagram. 9 23

13 4 Utviklingsprosess 4.1 Scrum Scrum er et iterativt og inkrementellt utviklingsrammeverk for programvare-prosjekter og er en av modellene innenfor smidig programvareutvikling. Rammeverkets fokus er å ha et fleksibelt miljø der gruppen skal jobbe mot et felles mål og hvor samlokalisering av gruppemedlemmene er en viktig del. Fokuset førte til tett og hypping kommunikasjon innad i gruppen. Dette blir ofte oppnådd med hyppige Scrum-møter, som er korte daglige møter der alle i gruppen oppdaterer hverandre om status i prosjektet. Andre prinsipper innenfor Scrum, er det innebygde fleksibilitets prinsippet. Det i motseting til andre tradisjonelle rammeverk som er mer avhengig av forutsigbarhet og omfattende planlegging. Hvordan Scrum implementeres i prosjekter varierer mye, alt i fra mange applikasjonsverktøy til meget enkle redskaper som lapper på en tavle. Vi valgte å bruke en del organiseringsverktøy (se 2.2 for komplett liste) da det forenklet organiseringen. Gruppen skal også ha en Scrum-master som skal stå for den organisatoriske tilretteleggelsen for gruppen. Scrum-master skal ikke være en gruppeleder, men bindeleddet mellom gruppen og kunde, som i vårt tilfelle var stud.ass. Ellers skal denne personen prøve å fjerne hindringer og legge til rette for at gruppens arbeid skal kunne gjennomføres mest mulig effektivt. Personen skal også være utfordreren i gruppen, ved å stille de vanskelige spørsmålene samtidig som han/hun hever gruppens fokus og arbeidsmål. Gruppen valgte Roar Gjøvaag som Scrum-master, da han var den første som tok initiativ til at gruppen skulle samles tidlig i prosjektet og samtidig påtok seg mye av det organisatoriske ansvaret. Han hadde også prosjekterfaring fra tidligere. Summen av dette gjorde valget enkelt da posisjonen som Scrum-master skulle fylles. 4.2 Organisering i Git Git fungerer slik at prosjekter er delt opp i såkalte repositories. Man kan se på dette som et lagringssted for kode. Da vi hadde tre prosjekter opprettet vi tre repositories i Git, et for REST-APIet, en for appen og en for simulatoren. Git fungerer også slik at hvert enkelt repository er delt opp i branches. Det vil i all enkelhet si at koden kan være forskjellig i to brancher og når de samles så merges koden sammen og Git er smart nok til å skjønne hvilke endringer som skal overskrive utdatert innhold. Si at du lager en ny branch fra Develop og fikser en feil i en fil. Når denne fila er lagret og endringene er sendt til Git, så kan disse branchene merges sammen igjen. Git har da oppdaget at den nye branchen har endringer som ikke finnes i Develop og syr disse endringene sammen. Ved bruk av Git har vi derfor unngått å ha problemer med at folk skriver i samme filer og skriver over hverandres endringer. Vi har prøvd å kjøre et ryddig miljø hvor alle repositoriene har basert seg på Develop hvor vi har merget inn endringer, fikser og ny kode. Git-ansvarlig har gått over pull-requests (som det heter når man ønker å merge noe sammen), og sett at koden var god nok. Har det vært mangler eller feil har forespørselen blitt avslått og ytterlige endringer blitt krevd. På denne måten har vi klart å utelukke en god del bugs 10

14 og problemer allerede tidlig i utviklingsprosessen ved å være veldig kritisk til egen kode. 4.3 Utviklingsverktøy Balsamiq Mockups Balsamiq Mockups ble tidlig brukt for å raskt og enkelt skape bilder/mockups av hvordan vi så for oss at programmet skulle se ut. Vi gjorde dette for å gjøre den videre utviklingsprossessen lettere da vi som gruppe hadde visualisert det endelige resultatet. Det endelige resultatet ble i stor grad likt slik vi hadde skisset det ut i starten. Noen endringer ble gjort underveis, men i all hovedsak fungerte skissene som et godt utgangspunkt gjennom utviklingen (se vedlegg: Mockups) Xcode Vi brukte Xcode som er et Integrert utviklingsmiljø (eller IDE på engelsk) på Mac OS X for å utvikle blant annet iphone-apps. Xcode kommer med en komplett simulator for iphone som gjorde det enkelt for oss å teste hvordan webappen kom til å se ut og føles på en mobil enhet Tekstredigeringsprogrammer Da prosjektet vårt hovedsaklig har bestått av PHP, HTML, JavaScript og CSS som i bunn og grunn er rene tekstfiler, har medlemmene på gruppen stått veldig fritt til å velge sine egne tekstredigeringsprogrammer. Av tidligere erfaringer ble Notepad++ og Sublime Text 3 anbefalt. På Mac OS X ble Coda også brukt. Disse programmene er relativt like og tilbyr på autofullføring av metoder, syntaks-fremheving og mange andre funksjoner som gjør utvikling og programmering enklere LaTeX Vi valgte å skrive rapporten i LaTeX, i stedet for Word som alle har god kjennskap til, fordi vi hadde hørt at det var et godt verktøy for tekstformatering og ønsket å lære oss noe nytt. Noen på gruppen har benyttet LaTeX før og dette gjorde overgangen lettere for resten. At vi har brukt LaTeX er årsaken til at rapporten er noen sider for lang, dette grunnet mye white-space i LaTeX sin formatering Databaseprogrammer Ettersom vi brukte MySQL (5.2), har vi benyttes oss en del av phpmyadmin, som er et grafisk grensesnitt for database-administrasjon. phpmyadmin er ett av de mest populære administrasjonsverktøyene for MySQL og er derfor standard software på de fleste servere. Dette er årsaken til at vi har brukt det. I tillegg har vi også benyttet oss av MySQL Workbench og Sequel Pro som også er databaseadministrasjonsverktøy Filopplastning For å laste opp filer på forskjellige servere har vi utelukkende brukt Filezilla som støtter filoverføring over FTP- og SFTP-protokollene. Samtidig har også tekstredigeringsprogrammet Notepad++ integrert FTP-støtte, som vi har brukt når vi har utviklet rett i utviklingsmiljøet Bilderedigering For å lage logoer, ikoner og andre grafiske elementer har vi benyttet oss av Photoshop CS6. Noe av grafikken er basert på gratis vektor-filer som vi har funnet på nettet, men det meste er laget fra bunnen av. Alle Photoshop-filene ligger i app-prosjektmappen

15 4.3.7 Nettlesere For å teste hvordan appen og simulatoren fungerer har vi benyttet oss av de mest vanlige nettleserne. Det inkluderer de nyeste versjonene av Opera, Chrome, Firefox og Safari. Dette ga oss riktignok bare et halvveis korrekt bilde da appen er laget og utformet for mobile enheter. I tillegg til å teste og utvikle i disse nettleserne har vi benytttet oss av Safari på ios og Chrome på Android-systemer Annet Vi har tatt i bruk en rekke biblioteker i appen for å gjøre arbeidet med utviklingen så enkel som mulig. Disse er listet opp under arkitektur-forklaring i neste kapittel

16 5 Arkitektur 5.1 Oversikt arkitektur I dette prosjektet har vi valgt å lage en webapp som enkelt kan integreres i smarttelefoner som iphone, Windows-Phone og modeller som kjører Android. Vi valgte å gå for en webapp-løsning fordi dette er mye enklere å lage enn en Native-app 1. En webapp er ikke annet enn en nettside som presenteres som et eget program. Prosjektet er satt opp slik at selve appen ikke er noe annet enn HTML5, CSS 2 og Javascript. Javascriptet snakker til backend-systemet som er et RESTful-API skrevet i PHP 3. Kommunikasjonen mellom APIet og appen er forklart i kapittel om Ajax. APIet lagrer data i en MySQL-database. 5.2 Database Da vi skulle velge database-løsning sto valget mellom MySQL og PostgreSQL. Disse løsningene er i grunn veldig like og valget falt på MySQL hovedsaklig fordi gruppen hadde mer erfaring med dette fremfor PostgreSQL. I tillegg ønsket vi å drifte det ferdige produktet på en stabil server hvor vi ikke trengte å tenke på oppe- og responstid. Thomas Gautvedt eier allerede en webserver hos Webhuset og vi valgte tidlig i planleggingsfasen å bruke de som webhotell. Webhuset tilbyr MySQL-servere, men ikke PostgreSQL, og dette var også en faktor som påvirket oss. MySQL er verdens nest mest brukte databasesystem, så vi visste at vi gikk til et alternativ som var godt utprøvd og stabilt Databaseoppbyggelse Databasen er bygget opp slik at brukere og system er separert med en mange-til-mange-relasjon. Dette betyr at et system kan ha flere brukere. Vi syntes dette virket logisk om en gård skulle ønske å ha flere brukere i sitt system (for eksempel bonde og nabobonden). På samme måte er relasjonen mellom sauer og system satt opp. En sau kan høre til flere systemer. Vi har gjort dette med sikt på videreutvikling. Slik det er satt opp nå vil dette skape problemer med varsling, men kan på sikt føre til at flere bønder kan samarbeide om en flokk sauer. Om dette er et helt realistisk bilde har vi ikke undersøkt, men det er satt opp slik at det er mulig. Se vedlegg om videreutvikling for mer detaljer. Til sammen består databasen av åtte tabeller hvor to av disse brukes til mange-til-mange-relasjoner. I tillegg brukes tre til lagring av bruker, system og sau. De resterende tre databasene lagrer informasjon om varsling, logg-innlegg og masterpassord som brukes for å logge inn i simulatoren. Vi tilpasset databasen slik at all tekst lagres som UTF-8, som sikrer at vi ikke får problemer med tegnsetting og spesialtegn i det norske alfabetet. Alle felter som e-post, navn osv er lagret såpass sto- 1 Med andre ord programmert i programmeringsspråket som støttes av operativssytemet til mobilen. 2 Cascading Style Sheet. 3 Hypertext Preprocessor. Et populært serverside programmeringsspråk. 13

17 re at ingen burde komme i en situasjon hvor et realistisk navn eller e-post er for langt å lagre i databasen. I tillegg har vi utnyttet indekser på IDer i alle tabellene som gjør at oppslag går mye fortere. IDer er satt til auto_increment som gjør at IDene alltid vil være unike for hver tabell. For mer informasjon om databaseoppbyggingen, se vedlegg om databasediagram. 5.3 RESTful API I planleggingsfasen kom vi frem til at vi ønsket å lage et API for å servere data til appen. I en ordentlig webapp skal ikke appen selv snakke med databasen, men snakke til et API som tar for seg henting av informasjon og returnerer dette til webappen som behandler og viser data slik det selv vil. Med en slik løsning kan APIet brukes i forskjellige programmer uten å måtte skrives spesfikt for det ene eller det andre. Det er også en mye mer moderne løsning og er noe som er mye brukt for tiden. Det er derfor ikke noe problem å få hjelp på Internett, eller finne eksempler på hvordan løsningen kan utvikles og struktureres. Vi diskuterte flere forskjellige API-løsninger. I all hovedsak så vi på løsninger for Websockets, RESTløsninger og SOAP. Vi valgte tidlig å gå bort fra SOAP fordi vi innså at det kom til å bli en stor jobb å programmere en komplett SOAP-løsning. Vi valgte også å gå bort fra Websockets for å få appen til å fungere på flest mulig mobile enheter, da Websockets er en teknologi som ikke fungerer på de eldste mobilene. Vi valgte derfor å gå for et RESTfult API Oppbygging av APIet APIet er skrevet i PHP. Vi diskuterte lenge valget mellom PHP og Python. Flesteparten hadde mest erfaring med Python fra tidligere fag på NTNU, og vi kunne for eksempel laget et RESTfult API med Webrammeverket Bottle i Python. Problemet var at vi ønsket å implementere en løsning for templates også, dette er beskrevet i kapittel Vi kunne mest sannsynlig tilplasset Bottle til å fungere slik vi ville, men endte til slutt opp med å skrive et rammeverk helt fra bunn av selv. Da vi skulle begynne på scratch var det mye enklere å gjøre dette i PHP. PHP er ett av de mest brukte programmeringsspråkene i hele verden, og store nettsider som Facebook og Wikipedia er skrevet i dette språket. Vi visste dermed at vi gikk til et stabilt, populært og mye testet språk. Thomas har også programmert i dette språket tidligere, og anbefalte det da det ansees for å være veldig enkelt, raskt og med god implementasjon mot databaser Teknisk forklaring Hele APIet er skrevet med en objektorientert tilnærming. I bunn av systemet er klassen REST. REST-klassen har metoder for å sjekke at brukeren er logget inn, sjekker om metoder og data som kreves er sendt med forespørselen, samt en rekke andre metoder som brukes av systemet. De forskjellige Controller-klassene extender REST-klassen. Når en forespørsel kommer til systemet blir forespøreselen sendt til fila index.php. I index.php inkluderes alle filer vi trenger, setter tidssoner, og definerer hvilke data systemet skal returnere. Her er det også en klasse som heter Loader. Denne klassen laster inn riktig Controller som skal behandle forespøreselen. Eksempel på en forespørsel: /sheep/10?method=get&access_token=[...] Loader-klassen fungerer slik at den ser på det første ordet av forespøreselen og sjekker om det finnes en Controller-klasse som heter dette. I eksempelet ovenfor vil den sjekke om det finnes en fil som heter 14 23

18 sheepcontroller.php. Dersom denne ikke finnes vil systemet returnere en feilmelding. Hvis Controller-klassen finnes i systemet vil den opprette en instans av denne klassen. Når det skjer vil scriptet gå i en variabel i REST-klassen som heter $path og sjekke hvilke metode den skal kalle. I eksempelet ovenfor vil den kalle en funksjon som heter sheep_single. REST-APIer er bygget på et prinsipp hvor et verb bestemmer hvilke handling som skal utføres. Denne har vi kalt method i vårt system. Get vil si å hente ut data, Post vil sette inn ny data (for eksempel å legge til en ny sau), Put vil oppdatere informasjon på et eksisterende element og Delete vil slette et element. I eksempelet ovenfor ønsker vi å hente ut data om sau med ID 10. Dersom sauen eksisterer og den finnes i systemet som brukeren er logget inn i, vil dataen returneres som en JSON-string. Se vedlegg om klasse-diagram for mer informasjon om oppbyggingen av REST-APIet JSON-string JSON står for JavaScript Object Notation 4 og er et format for å utveksle data. Sammenlignet med XML (som er det samme), er JSON lett lesbart for mennesker og tar mindre plass enn tilsvarende XML. Ettersom vi har utviklet en mobilapplikasjon som kanskje ikke alltid har Wifi-tilkobling men heller 3G eller GSM, ønsket vi å gjøre overføringen av data så liten som overhode mulig. En typisk JSON-string kan se slik ut: {"code":121,"msg":no user has this access_token"} Denne stringen kan enkelt gjøres om til et objekt som Javascript kan loope eller lese av. Metoder for å kode og dekode objekter og JSON-stringer er innebygget i alle moderne lettlesere og dette har blitt en svært populær og mye brukt standard. 5.4 App Selve appen er skrevet i HTML, CSS og Javascript. I tillegg brukes en del grafikk i form av.png og.jpeg-bilder. HTML tar for seg oppbyggingen av appen og inkluderer de bibliotekene vi bruker, scriptene vi trenger og stilsettingen i form av CSS-filer. Vi har valgt å bruke HTML5 fordi alle nettlesere på mobile enheter støtter denne standarden, og vi slapp å tenke på andre nettlesere, som for eksempel utdaterte versjoner av Internet Explorer. Det er brukt en standard CSS-fil for å stilsette hvordan appen skal se ut. Mer om dette under design i kapittel Teknisk oppbygging Appen er bygget opp med med en klasse kalt base.js i bunn. Denne klassen holder styr på alle metodene og snakker med APIet. Mellom APIet og selve appen har vi script.js. Her er alle hendelselytterne 5. Når en bruker ønsker å logge inn fyller han/hun ut e-post og passord og trykker på Logg inn-knappen. Script.js har en lytter på Logg inn-knappen og sjekker om alle feltene er fylt ut korrekt. Dersom brukeren har glemt å fylle ut enten e-post eller passord vil systemet klage. Hvis alt er ok vil dataen blir sendt videre til base-klassen. I base.js blir dataen tatt i mot og et Ajax-kall sendt til APIet. Base.js sjekkes svaret fra APIet og man logger enten inn eller får beskjed om at passord og brukernavn er feil Javascript EventListeners 15 23

19 5.4.2 Ajax-kall Ajax er en teknologi som er helt sentral i webapps. Tanken bak webapps er at de aldri kan gå fra en side til en annen. Dette kan sammenlignes ved å være på forsiden til vg.no og deretter trykke seg inn på en artikkel. Nettleseren blir hvit og alt innholdet blir lastet på nytt. Dette kalles en sidelastning. Dersom dette utføres i en webapp vil mobilen hoppe ut av webappen og heller gå over til nettleseren på mobilen. På grunn av dette er alt som skjer i en webapp nødt til å skje på en side uten sidelastninger. Dette gjøres ved en teknologi som kalles Ajax. Ajax står for Asynchronous JavaScript and XML og ble populært på starten av millieniumet. Med Ajax kan man gjøre en forespørsel til nettside og laste litt innhold uten å gjennomføre en komplett sidelastning som krever at all dataen lastes på nytt. På nettsider som Facebook og Twitter brukes Ajax masse for å gjøre responstiden så liten som mulig ved å kun laste det som brukeren velger å se. På Facebook kan du for eksempel åpne og lukke et chatvindu uten at man må gjennomføre en sidelastning. Tilsvarende kan man sende og motta svar i chatvinduet via Ajax. Når en bruker ønsker å se data om en sau, eller logge inn, blir tilsvarende Ajax-forespørsler gjort til APIet som returnerer en JSON-string. Systemet leser JSON-stringen og bestemmer deretter hva som skal skje Templates Da webappen benytter seg av Ajax som kun inneholder den faktiske dataen vi ønsker å motta, må vi ha et sted hvor vi definerer hvordan HTML-markupen skal se ut. Dette er en oppskrift på hvordan vi ønsker at dataen skal presenteres. Vi har lagd APIet slik at man også kan spesifisere hvilke templates man ønsker å motta med en forespørsel. En enkel template kan se slik ut: <div class="block"> <div class="block-top"> <h2>logger</h2> </div> <div class="block-body"> <ul> <%= inner %> </ul> </div> </div> Vi bruker deretter rammeverket Underscore.js til å erstatte og fylle inn verdier for spesielle tags. I dette tilfellet vil listen med logger erstatte taggen inner. Underscore.js er forklart i kapittel Rammeverk I appen har vi valgt å bruke en rekke Javascript-rammeverk for å gjøre utviklingsjobben enklere for oss selv jquery og jquery UI Vi har brukt jquery og jquery UI massivt i appen. Dette er i all hovedsak fordi rammeverket gjør Javascript mye enklere å skrive. Vi har masse Ajax-kall og animasjoner, og med jquery blir disse tingene mye enklere å skrive enn å måtte definere egne metoder i helt ren Javascript. Vi har inkludert jquery UI (som er en utvidelse av jquery-biblioteket) fordi man trenger UI for å kunne animere farger og et par andre spesielle tilfeller som vi kom over i løpet av utviklingen

20 Google Maps API v3 Da vi bestemte oss for å inkludere kart og markører falt valget fort på Google Maps APIet. I all hovedsak fordi dette var det beste alternativet vi kunne finne, det er lett og fordi flere på gruppa hadde vært borti det tidligere. Google Maps er også skrevet i Javascript, som gjorde det veldig enkelt for oss å implementere i prosjektet vårt Underscore.js Med templates fra APIet bruker vi Underscore.js til å fylle inn data. Hvordan templates hentes fra APIet er forklart i kapittel Underscore.js er et lite bibliotek som brukes som template-prosessor og template-motor. Med dette biblioteket kan vi legge til tags i templatene som blir erstattet med faktiske verdier fra APIet. Et eksempel på dette er å finne i seksjonen om templates som det er referert til ovenfor. Vi kunne skrevet vår egen parser for å gjøre dette, men Underscore.js gjorde alt vi ønsket, og ble et naturlig valg etter anbefalinger og testing Moment.js Moment.js er et bibliotek for dato- og tids-behandling i Javascript. Man kan gi biblioteket en dato og den kan enkelt regne ut hvor lenge det er siden. Vi hadde bruk for en slik funksjon et par steder i appen, og i stedet for å gjøre dette manuelt bestemte vi oss for å bruke Moment.js til denne jobben Design Designet i appen er basert på andre apps og blitt bestemt etter mockups vi lagde da vi planla hvordan de forskjellige skjermbildene skulle se ut. Vi har prøvd å gjøre appen lik andre apps som brukere er godt kjent med. Eksempler på disse kan være Facebook, Twitter og Spotify. Vi har gjort oppbyggingen lik på alle sidene, slik at for eksempel lagre-knappen ikke er på forskjellige steder, men man alltid kan forvente at de er å finne på det samme stedet. 5.5 Simulator Simulatoren er laget kjapt og enkelt og fungerer som en normal side i PHP. Den benytter seg av jquery og Ajax-kall i likhet appen, samt Google Maps API. Her kan man logge inn, velge hvilke system man skal simulere, og simulere bevegelser på sauene i sanntid. Her er det også gjort mulig at man kan få simuleringen kan gå fortere enn den faktiske tiden. Dette er hovedsakelig for å teste og sjekke hvordan det vil se ut i appen. Simulatoren er satt opp slik at sauene sender data tre ganger om dagen. Den teller antall sauer i systemet, ganger med tre og deler på 24 timer. Man får da intervallet på hvor ofte simulatoren skal sende en oppdatering. Dette går på rundgang på alle sauene. I tillegg kan man dra sauene rundt på kartet og klikke på en av dem for å angripe eller drepe dem. Simulatoren simulerer hvordan systemet ville fungert i virkeligheten og knytter alle sauene til sin fiktive chip. Med denne chip-iden sendes en forspørsel til APIet som bestemmer hvilke handlinger som skjer. Disse handlingene kan være en normal forflyttelse, angrep eller at en sau har dødd

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

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

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

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

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

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

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

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

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

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

Vedlegg: IT1901 Informatikk Prosjektarbeid I. Sheep Locator

Vedlegg: IT1901 Informatikk Prosjektarbeid I. Sheep Locator Vedlegg: IT1901 Informatikk Prosjektarbeid I Sheep Locator Gruppe 6 20. november 2013 Thomas Gautvedt Aina Elisabeth Thunestveit Jostein Granli Geir Forslund Roar Gjøvaag Innhold 1 Kundens kravspesifikasjon

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

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS

HTML5. Skjemaer på nettsider. Skjemaer med. Informasjonsteknologi 1 og 2. Gløer Olav Langslet Sandvika VGS Skjemaer med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 10 Informasjonsteknologi 1 og 2 Skjemaer på nettsider I denne leksjonen skal vi se litt nærmere på bruk av skjemaer på nettsider. Du har sett

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

- 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

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

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11

Høgskolen i Oslo og Akershus. Forprosjektrapport. Gruppe 11 Høgskolen i Oslo og Akershus Forprosjektrapport Gruppe 11 Michael Pande, Petter L. Olsen, Diego A. Pasten 23.01.2015 Presentasjon Vi er en gruppe på tre dataingeniørstudenter som har tatt på oss oppgaven

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

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

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

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

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

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

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

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

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

Virus på Mac? JA! Det finnes. Denne guiden forteller deg hva som er problemet med virus på Mac hva du kan gjøre for å unngå å bli infisert selv

Virus på Mac? JA! Det finnes. Denne guiden forteller deg hva som er problemet med virus på Mac hva du kan gjøre for å unngå å bli infisert selv Virus på Mac? JA! Det finnes. Denne guiden forteller deg hva som er problemet med virus på Mac hva du kan gjøre for å unngå å bli infisert selv «Å tro at det ikke finnes virus på Mac er dessverre litt

Detaljer

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD

Forprosjektrapport. Feilsøkingsverktøy for Homebase AS INNHOLD Forprosjektrapport Feilsøkingsverktøy for Homebase AS INNHOLD Presentasjon Sammendrag Om bedriften Dagens situasjon Mål og rammebetingelser Funksjonelle krav: Ikke-funksjonelle krav: Løsninger Analyse

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

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

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet.

Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Produktrapport Forord Denne rapporten er beregnet for dataansvarlig på Grefsenhjemmet, den som skal installere, vedlikeholde og modifisere systemet. Dataansvarlig eller supporter trenger informasjon om

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

lagring med HTML5 Offline lagring Offline Informasjonsteknologi 2 Gløer Olav Langslet Sandvika VGS

lagring med HTML5 Offline lagring Offline Informasjonsteknologi 2 Gløer Olav Langslet Sandvika VGS Offline lagring med HTML5 Gløer Olav Langslet Sandvika VGS Leksjon 8 Informasjonsteknologi 2 Offline lagring I IT1 brukte vi databaser til å lagre data. Der kunne vi bygge tabeller og fylle dem med innhold

Detaljer

1. Intro om SharePoint 2013

1. Intro om SharePoint 2013 Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Intro om SharePoint 2013 Stein Meisingseth 09.08.2013 Lærestoffet er utviklet for faget LO205D Microsoft SharePoint 1. Intro om SharePoint

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

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

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon

24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus. Forprosjektrapport. Presentasjon 24.01.2014 Hovedprosjekt i Informasjonsteknologi ved Høgskolen i Oslo og Akershus Forprosjektrapport Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes

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

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

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

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

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

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

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

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no

2014 Høgskolen i Oslo og Akershus. Forprosjektrapport Rinnovasjon (Renovasjon og innovasjon) monabjerke.no 2014 Høgskolen i Oslo og Akershus Torbjørn Gjøn s180399 Snorre Duun Strømsborg s180371 Matias Pettersen s180395 Forprosjektrapport "Rinnovasjon" (Renovasjon og innovasjon) monabjerke.no Presentasjon Tittel:

Detaljer

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp

Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp Læringsplattform for IT-fag basert på HTML5 utviklet i CakePhp { En selvstendig plattform som kan brukes til å formidle kurs på nett med dagsaktuell teknologi. Oppgave 5, av Fredrik Johnsen Oppgavestiller

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

- Java kan lastes ned gratis http://www.java.com. For installasjon, se punktet Hvordan laster jeg ned og installerer Java på min maskin?.

- Java kan lastes ned gratis http://www.java.com. For installasjon, se punktet Hvordan laster jeg ned og installerer Java på min maskin?. Innhold Hva er Java?... 2 Hvor finner jeg Java?... 2 Hvorfor må jeg ha Java for å bruke nettbanken?... 2 Hvordan installerer jeg Java på min maskin?... 2 Jeg får bare en feilmelding om "File is corrupt"

Detaljer

Brukermanual. www.bygdekvinnelaget.no

Brukermanual. www.bygdekvinnelaget.no Brukermanual www.bygdekvinnelaget.no Viktige endringer Nye Bygdekvinnelaget.no er lagt opp på en måte der brukere og redaktører står for innhold, mens systemet i enda større grad en tidligere står for

Detaljer

Hei verden Introduksjon Swift PDF

Hei verden Introduksjon Swift PDF Hei verden Introduksjon Swift PDF Introduksjon Swift er et programmeringsspråk laget av Apple og er etterfølgeren til Objective-C. Med Swift kan du lage apper for ios og OSX. For å gjennomføre dette kurset

Detaljer

Gruppe 33 - Hovedprosjekt

Gruppe 33 - Hovedprosjekt Gruppe 33 - Hovedprosjekt s188080 Joakim Rishaug s181130 Sondre Sparby Boge s188098 Martin Hagen s178816 Lars Erik Kasin 1 av 7 Kravspesifikasjon Forord Kravspesifikasjonen utformes både for kunden, og

Detaljer

TRÅDLØS TILKOBLING PÅ KHIO

TRÅDLØS TILKOBLING PÅ KHIO TRÅDLØST KHIO TRÅDLØS TILKOBLING PÅ KHIO Vi har delt brukere i tre forskjellige grupper A) Ansatte med KHiO-PC 1 B) Ansatte/studenter med hjemme-pc/mac. Kan også benyttes for smarttelefoner og nettbrett

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

Vanlige spørsmål. GallupPanelet. TNS Panel-app. TNS Juni 2015 v.1.3

Vanlige spørsmål. GallupPanelet. TNS Panel-app. TNS Juni 2015 v.1.3 Vanlige spørsmål Innhold 1 Hvor kan man laste ned appen 1 2 Vanlige spørsmål 03-19 3 Begrensninger i GallupPanel-app v. 2.3.2 20 4 Kontakt oss 21 2 Hvor kan man laste ned GallupPanel-appen? For ios kan

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

Eksamen i Internetteknologi Fagkode: IVA1379

Eksamen i Internetteknologi Fagkode: IVA1379 Høgskolen i Narvik Side 1 av 5 Eksamen i Internetteknologi Fagkode: IVA1379 Tid: Mandag, 07.06.04, 9:00-12:00 Tillatte hjelpemidler: Alle trykte og skrevne hjelpemidler tillatt. Eksamen består av 4 oppgaver

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

TDT4102 Prosedyre og Objektorientert programmering Vår 2014

TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Norges teknisk naturvitenskapelige universitet Institutt for datateknikk og informasjonsvitenskap TDT4102 Prosedyre og Objektorientert programmering Vår 2014 Øving 10 Frist: 2014-04-11 Mål for denne øvinga:

Detaljer

Velkommen til Pressis.

Velkommen til Pressis. 1 Velkommen til Pressis. Dette er et veiledende dokument med linker i innledningen. Veiledningene vil ta deg igjennom de forskjellige tilkoblings muligheter du har med oss. Hvis du bare har behov for en

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

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

Virus på Mac? JA! Det finnes. Denne guiden forteller deg hva som er problemet med virus på Mac hva du kan gjøre for å unngå å bli infisert selv

Virus på Mac? JA! Det finnes. Denne guiden forteller deg hva som er problemet med virus på Mac hva du kan gjøre for å unngå å bli infisert selv Virus på Mac? JA! Det finnes. Denne guiden forteller deg hva som er problemet med virus på Mac hva du kan gjøre for å unngå å bli infisert selv «Å tro at det ikke finnes virus på Mac er dessverre litt

Detaljer

NorskInternett Brukermanual. Sist oppdatert 09.08.15. Side 1/30

NorskInternett Brukermanual. Sist oppdatert 09.08.15. Side 1/30 NorskInternett Brukermanual Sist oppdatert 09.08.15. Side 1/30 Innholdsliste Hvordan kan vår tjeneste brukes...2 Hva vi leverer...2 Kontoinformasjon...3 Bruk av VPN tilkobling...3 Konfigurering av Android...4

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

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS

if-tester Funksjoner, løkker og iftester Løkker og Informasjonsteknologi 2 Læreplansmål Gløer Olav Langslet Sandvika VGS Løkker og if-tester Gløer Olav Langslet Sandvika VGS 29.08.2011 Informasjonsteknologi 2 Funksjoner, løkker og iftester Læreplansmål Eleven skal kunne programmere med enkle og indekserte variabler eller

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

4.1. Kravspesifikasjon

4.1. Kravspesifikasjon 4.1. Kravspesifikasjon Dette delkapittelet beskriver nærgående alle deler av systemet, hvordan det er tenkt ferdigutviklet med fokus på oppdragsgivers ønsker. 4.1.1. Innledning Informasjon om hvordan kravspesifikasjonens

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

FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING

FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING 23. JANUAR 2015 FORPROSJEKTRAPPORT EMILIE STRAND, RANNVEIG A. SKJERVE OG MADELEINE RØNNING Innholdsfortegnelse Presentasjon... 2 Sammendrag... 2 Dagens situasjon... 2 Mål og rammebetingelser... 2 Mål...

Detaljer

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker.

Ble ferdig med prosjektskisse. Sett på forskellige rammeverk for php. Lager milepæl for to uker. Logg 22 oktober 2013 Vi skriver status rapport og starter også med å skrive logg idag. Vi har vært i kontakt med mange firmaer uten alt for mye interesse fra deres side. Vi fortsetter å søke etter oppgave.

Detaljer

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD

VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD VEDLEGG HOVEDPROSJEKT VÅR 2013 KNOWIT CVREG TILBUD GRUPPE 36 FORFATTERE: NORDENGEN, THOMAS LARSEN, GLENRUBEN E. STEEN, SEBASTIEN-JEROME 1 INNHOLDSFORTEGNELSE VEDLEGG 1 KRAVSPESIFIKASJON... 03 VEDLEGG 2

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

Generell brukerveiledning for Elevportalen

Generell brukerveiledning for Elevportalen Generell brukerveiledning for Elevportalen Denne elevportalen er best egnet i nettleseren Internett Explorer. Dersom du opplever kompatibilitets-problemer kan det skyldes at du bruker en annen nettleser.

Detaljer

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5

Testrapport. Aker Surveillance. Gruppe 26. Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, 24.5.2013. Public 2013 Aker Solutions Page 1 of 5 Testrapport Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 24.5.2013 Public 2013 Aker Solutions Page 1 of 5 Innledning I denne rapporten vil vi skrive om testingen som

Detaljer

AlgDat 12. Forelesning 2. Gunnar Misund

AlgDat 12. Forelesning 2. Gunnar Misund AlgDat 12 Forelesning 2 Forrige forelesning Følg med på hiof.no/algdat, ikke minst beskjedsida! Algdat: Fundamentalt, klassisk, morsomt,...krevende :) Pensum: Forelesningene, oppgavene (pluss deler av

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

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

Mobil Feltdagbok. Hvordan effektivisere en oppsynsmanns datafangst i felten med smarttelefon som har GPS stedfesting

Mobil Feltdagbok. Hvordan effektivisere en oppsynsmanns datafangst i felten med smarttelefon som har GPS stedfesting Mobil Feltdagbok Hvordan effektivisere en oppsynsmanns datafangst i felten med smarttelefon som har GPS stedfesting Vårt utgangspunkt Interaksjonsdesignere mest web/applikasjoner Ønsket å lære mer om hvordan

Detaljer

Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet)

Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet) Olav Dæhli: 06.10.05 Prosjektstyring med Projectfronter (En innføring i grunnleggende Projectfronter-funksjonalitet) Fronters systemer består av tre sentrale moduler, Classfronter, Teamfronter og Projectfronter

Detaljer

Brukerguide for www.altadykkerklubb.com

Brukerguide for www.altadykkerklubb.com Brukerguide for www.altadykkerklubb.com Utgitt første gang: 27/09-07 Sist oppdatert: 23/03-09 1 Innledning Dette er den nye siden til Alta Dykkerklubb! Den er blitt laget over et system som gjør det mulig

Detaljer

Installasjonguide LAG DIN EGEN BRUKERKONTO

Installasjonguide LAG DIN EGEN BRUKERKONTO Installasjonguide LAG DIN EGEN BRUKERKONTO KONFIGURER MOT WI-FI MOTTA VIDEO-SAMTALE DEL TILGANG MED FLERE BRUKERE BEVEGELSE SENSOR CLOUD VIDEO OPPTAK KOSTNAD FOR CLOUD FEILSØKING LAG DIN EGEN BRUKERKONTO

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

Web fundamentals. Web design. Frontend vs. Backend 17.01.2008. Webdesign 17. januar 2008 3. Monica Strand

Web fundamentals. Web design. Frontend vs. Backend 17.01.2008. Webdesign 17. januar 2008 3. Monica Strand Web fundamentals Webdesign 17. januar 2008 Monica Strand Webdesign 17. januar 2008 1 Web design Fagområdet Web design inneholder flere disipliner Grafisk design Informasjonsdesign Brukergrensesnittdesign

Detaljer

Endringer i Flash CS6 Professional. Innhold. Endringer i forhold til boka. Oppdatering til boka: Multimedieutvikling i Flash CS5 Professional

Endringer i Flash CS6 Professional. Innhold. Endringer i forhold til boka. Oppdatering til boka: Multimedieutvikling i Flash CS5 Professional Oppdatering til boka: Multimedieutvikling i Flash CS5 Professional Endringer i Flash CS6 Professional I denne oppdateringen går vi gjennom boka Multimedieutvikling i Flash CS5 Professional og beskriver

Detaljer

BankID 2.0. Rune Synnevåg, Uni Pluss AS

BankID 2.0. Rune Synnevåg, Uni Pluss AS BankID 2.0 Rune Synnevåg, Uni Pluss AS First Hotel Marin 27. - 28. oktober 2014 BankID 2.0 Hva er BankID, og hva kan det brukes til? Signere.no AS Hvorfor BankID 2.0? Hvordan fungerer det? BankID 2.1 Demo

Detaljer

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011

ChiCMS Hovedprosjekt ved Høgskolen i Oslo 2011 TESTRAPPORT Forord Denne testrapporten har som formål å beskrive all testing som er utført på systemet, både under utviklingen og etter ferdigstilling. Målet for testingen er for å verifisere at vi har

Detaljer

Vurdering for Studiestøtte Lånekassen. Poengsum: 83 poeng av moglege 105 poeng - 79 %

Vurdering for Studiestøtte Lånekassen. Poengsum: 83 poeng av moglege 105 poeng - 79 % Vurdering for Studiestøtte Lånekassen Poengsum: 8 poeng av moglege 105 poeng - 79 % 1. Tjenesten er enkel å finne (Studiestøtte - Lånekassen) 1.1 Tjenesten er enkel å finne gjennom søk og navigasjon [

Detaljer

Informatikk Prosjekt 1 IT1901

Informatikk Prosjekt 1 IT1901 Introduksjon 1 11/21/2012 Gruppe 2 Informatikk Prosjekt 1 IT1901 Alf Håkon Lille-Mehlum Erik Frøseth Ingeborg Ødegård Oftedal Mathias Tempelhaug Tord Kloster Tuyet Trang Thi Pham Norges teknisk-naturvitenskapelige

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

PBL Barnehageweb. Brukerveiledning

PBL Barnehageweb. Brukerveiledning PBL Barnehageweb Brukerveiledning 1 1. Innledning Gratulerer med valget av nye PBL Barnehageweb! Med PBL Barnehageweb skal det være enkelt å lage en brukervennlig, moderne og profesjonell nettside 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

Forprosjektrapport MetaView

Forprosjektrapport MetaView Forprosjektrapport MetaView BACHELOROPPGAVE VÅREN 2014 Presentasjon Tittel: MetaView Oppgave: Utvikle en Windows 8 applikasjon som skal forenkle en liten del av MetaVision. Et verktøy for sykehus, leger

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

3. Kravspesifikasjon. Experior - rich test editor for FitNesse -

3. Kravspesifikasjon. Experior - rich test editor for FitNesse - 3. Experior - rich test editor for FitNesse - 3.1. Forord Dette dokumentet inneholder krav til funksjonalitet i Experior og hvordan denne skal integreres inn i selve FitNesse. I tillegg spesifiseres krav

Detaljer

Scan Secure GTS 5.1 + PAS

Scan Secure GTS 5.1 + PAS Scan Secure GTS 5.1 + PAS Installasjonsmanual For versjon 5.1.7 og nyere Denne installasjonsmanualen er konfidensiell Den er kun ment til bruk for system administrator Den skal ikke benyttes av brukere

Detaljer

Brukerveiledning for identifisering med BankID

Brukerveiledning for identifisering med BankID Brukerveiledning for identifisering med BankID Innledning Denne brukerveiledningen tar kun for seg identifisering med BankID med sikkerhetskort. Brukerveiledningen vi ikke inneholde beskrivelse av alle

Detaljer

Google Chrome. Microsoft Edge. Mozilla Firefox. Internet Explorer. Opera. Safari

Google Chrome. Microsoft Edge. Mozilla Firefox. Internet Explorer. Opera. Safari Google Chrome Microsoft Edge Mozilla Firefox Internet Explorer Opera Safari Google Chrome Dersom nettbanken ikke vises eller fungerer som den skal, så hjelper det ofte å slette midlertidige filer i din

Detaljer