HOVEDPROSJEKT. EEGBliss. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

Størrelse: px
Begynne med side:

Download "HOVEDPROSJEKT. EEGBliss. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo"

Transkript

1 Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo HOVEDPROSJEKT PROSJEKT NR. TILGJENGELIGHET Telefon: Telefaks: HOVEDPROSJEKTETS TITTEL EEGBliss DATO ANTALL SIDER / BILAG PROSJEKTDELTAKERE INTERN VEILEDER Thor Hasle OPPDRAGSGIVER Larsen Development AS KONTAKTPERSON Sigve Larsen SAMMENDRAG 3 STIKKORD Hjelpemiddel EEG Bliss 1

2 2

3 SAMMENDRAG Et open source prosjekt som kombinerer Blissymbolics og hjernestyring. Jan Ole Lysen Andersen, Tobias Andersen, Nina Bauge, Raymond Wilhelmsen Holthe og Emilie Thomassen EEGBLISS Hovedprosjekt Anvendt Datateknologi, HiOA

4 4

5 FORORD Denne bacheloroppgaven konkluderer vårt arbeid med å bygge opp grunnmuren for EEGBliss systemet. Vi har gjennom flere iterasjoner med brukertesting, forskning og programmering av prototyper kommet fram til et brukergrensesnitt, en systemarkitektur og et konsept som åpner opp en ny form for Menneske- Maskin Interaksjon for sluttbrukerne. Rapporten tar for seg prosessen med å utvikle denne løsningen, hvilke resultater vi har fått og tilbakemeldingene fra de mange interesseorganisasjonene vi har vært i kontakt med underveis. Denne hovedprosjektrapporten konkluderer et bachelorprosjekt ved Anvendt Datateknologi på HiOA, avgangskullet Rapporten er skrevet for veileder og sensorer ved HiOA, Interessenter i prosjektet og Oppdragsgiver. Hovedprosjektrapporten omfatter omtale av rapporter og dokumentasjon på aktiviteter fra forprosjektperioden og prosjektperioden. Rapporten belyser utgangspunkt for prosjektet og hvilke vurderinger som er gjort underveis. Vi har redegjort for hvilken status prosjektet har per i dag og hvordan vi har tilrettelagt for at det kan videreføres etter denne prosjektperioden. Problemstillingen bak prosjektet ble utviklet sommeren 2013, og vi valgte å jobbe videre med den som hovedprosjekt etter oppfordring fra forelesere og Daniel Scheidegger i NAV Tilde. Vi har fått med oss en erfaren utvikler i vår veileder Thor Hasle og vår oppdragsgiver Sigve Larsen. Vi vil takke dem begge for all støtte i prosjektet. Vi vil også takke Torhild Kausrud i StatPed, Daniel Scheidegger i Nav Tilde, Klaus Miesenberger og Gunnar Michelsen for alle innspill underveis. 5

6 6

7 Innhold Forord... 5 Sammendrag Innledning Problemstilling Mål og avgrensninger Bakgrunn for prosjektet Erkjennelse og sondering Strategianalyse Faglige forutsetninger Om utviklingsprosessen Kravspesifikasjonen og dens rolle Metode Brukerinvolvering Prosjektstyring Analyse Utvikling Prosjektstyring Resultater Brukerinvolvering Utvikling Resultater fra testing av GUI Prosjektstyring Diskusjon Visjon Konklusjon Problemstilling Mål Testrapport Prosessrapport Kommentert kildekode Kravspec Personas Behovsanalyse Papirprototype

8 Wireframe Produktdokumentasjon Erling Open Source utvikling Dagbok Gantt YRC... 2 Siterte verk

9 9

10 EEGBliss En Interaksjonsløsning med Blissymbols og EEG Tobias Andersen, Nina Bauge, Jan Ole Lysen Andersen, Emilie Thomassen og Raymond Holthe Hovedprosjekt Anvendt Datateknologi ved HiOA, Vår 2014 SAMMENDRAG Vi har presentert målgruppens behov og dokumentert at hjelpemiddelindustrien ikke har produkter som kan hjelpe dem per i dag. Vi har introdusert markedet for en løsning som kombinerer bruk av EEG og Ideografiske symboler og sannsynliggjort at dette er en ny retning innen hjelpemiddelutvikling. Vi har presentert testresultater som viser at teorien bak løsningen er gjennomførbar og redegjort for hva vi mener må til for å videreutvikle konseptet til beste for målgruppen; kvantitativ kartlegging av brukererfaringer i etisk forsvarlige rammer. Økonomisk og strategisk forpliktelse i organisasjoner som bistår målgruppen. Vi har argumentert for at vi har grunn til å forvente bidrag fra en internasjonal folkebevegelse av programmerere med insentiver til å skape allsidige interaksjonsverktøy med åpen kildekode. INNLEDNING Denne rapporten er organisert i åtte kapitler. I Innledningen vil vi deretter presentere Problemstilling, Mål og avgrensninger. I kapittelet Bakgrunnen for prosjektet vil vi gå gjennom hva som motiverte disse ambisjonene og kickstartet prosjektet, sammen med en redegjørelse for state of the art for de involverte teknologiene. I Metoder vil vi introdusere våre fremgangsmåter og hvordan de henger sammen med målsetningene. Der presenterer vi også vår prosjektorganisering og hvordan vi har kvalitetssikret prosjektet. I Analyse vil vi gjøre rede for hvilket materiale vi har tilgjengelig for å analysere. I Resultater presenterer vi resultatene vi har oppnådd. I Diskusjon drøfter vi hva som gjenstår, hvilke tråder som ikke er tatt tak i og hva som eventuelt kan gjenstå for å oppnå våre mål. I Konklusjonen vil vi redegjøre for hva vi har oppnådd og oppsummerer prosjektstatus. Til sist i denne rapporten deler vi Visjonen. Her inviterer vi likesinnede til å finne sin rolle i en spennende utvikling. Deretter følger Referanseliste og vedlegg. For de mest dedikerte leserne har vi lagt ved en stikkordsliste helt bakerst i rapporten, til hjelp for den som går grundigere gjennom materialet. Problemstilling Studiens overordnede problemstilling er; Hvordan utvikler vi et kommunikasjonsverktøy for brukere med uten motorisk funksjonsevne? Denne hovedproblemstillingen er nærmere presisert i tre underproblemstillinger, som utforskes i oppgavens tre analysedeler, for henholdsvis Brukerinvolvering og Projekstyring. Hvordan utvikle for vår målgruppe? Hvordan utvikle en integrasjonsløsning som binder sammen funksjonalitet fra eksisterende programvare? Hvordan tilrettelegge for videre utvikling etter prosjektperiode? 10

11 Mål og avgrensninger I dette avsnittet vil vi presentere mål og avgrensninger. Vi deler målene inn i læringsmål, prosessmål og produktmål og presenterer dem punktvis. Etter at vi har presentert målene kommer vi inn på avgrensninger, der vi forteller kort om hvilke ambisjoner vi har for dette prosjektet og hva vi vil overlate til en eventuell videreutvikling av prosjektet. Mål Læringsmål Lære å skrive Abstract og presentere oss i en akademisk kontekst Programmering i Kivy [1] og Python [2] Prosjektstyring Involvere interessenter og sluttbrukere Prosessmål Tilrettelegge for at oppdragsgiver kan etablere seg som en aktør i hjelpemiddelmarkedet Tilrettelegge for videre utvikling av et produkt gjennom open source Produktmål Kravspec API Funksjonell prototyp Avgrensninger I dette avsnittet vil vi omtale våre avgrensninger for hovedprosjektet, og drøfte ambisjonene. I dette prosjektet har vi reist vår problemstilling for å sette en bestemt målgruppe på dagsordenen. Vi har store ambisjoner; Vi ønsker å gjøre en forskjell. Vi ønsker at vår løsning skal kunne heve livskvaliteten for målgruppen; Vi ønsker at den skal lindre isolasjonen syke og deres familier, sikre de sårbare og realisere restarbeidsevnen til de arbeidsføre. Som vi har blitt gjort veldig klar over; innstillingen er større enn ett enkelt bachelorprosjekt. Derfor er våre ambisjoner begrenset til én viktig prioritering; at vårt arbeid skal kunne bygges videre. I prosessrapporten har vi presentert en inndeling av våre langsiktige ambisjoner, i ni implementajonsfaser. De ni fasene representerer hvilke funksjonaliteter vi ønsker å introdusere til hvilken «avdeling» i organisasjonen, og hvilken rekkefølge vi vil introdusere dem. Der presenterer vi denne modellen. Hovedprosjekt våren 2014 er ment å dekke Fase 1 og Fase 2.0 Vi vil komme mer inn på dette på side 13, i «Om utviklingsprosessen». BAKGRUNN FOR PROSJEKTET Her vil vi presentere det historiske bakteppet for prosjektet, forklare den faglige strategiske forankringen for prosjektet og redegjøre for våre teorier og forutsetninger før prosjektstart. 11

12 Erkjennelse og sondering Erkjennelsen av behovet for vår løsning oppsto tilfeldig sommeren 2013, som reaksjon på en rekke omstendigheter som inntraff samtidig. Prosjektgruppen jobbet med et prosjekt som kombinerte Facebook-chat og Blissymbolics [3]-symboler, der vi lærte noe om hvor viktig kommunikasjon er for menneskers livskvalitet. Gruppemedlemmene bevitnet den sjokkerende utviklingen til en ALS-rammet familiefar i sin beste alder, gjennom vår utvidede familie. Prosjektgruppen reagerte på hvordan hjelpemidler kommer til kort i møte med disse utfordringene [4] [5]. Prosjektgruppen dyrket TED Talks som sommerunderholdning [5]. Et par av gruppemedlemmene fikk tak i Nekomimi [6] Neurowear-leketøy på ferie. Illustrasjon 1 MRI-scan Utover sensommeren begynte prosjektgruppen å leke med ideer for å kombinere teknologien bak Nekomimi Neurowear med Bliss-chatten som et hjelpemiddel for ALS-pasienter. Da oppdaget vi Emotivpresentasjonen på TED. Med dette utgangspunktet begynte vi å sondere for å avdekke om en integrasjonsløsning kan bære med seg det potensialet vi håpet på. Underveis i denne prosessen ble vi gjort oppmerksomme på et viktig strategisk poeng; Vi så presentasjonen Could future devices read images from our brains? av Mary Lou Jepsen fra 2013 [7], bestemte gruppa seg for å satse på EEG [8, pp ] med Blissymbolics. Grunnen til dette var en studie Mary presenterte som konstanterte at hjerneaktiviteten som oppstår når man ser et bilde, er den samme som når man forsøker å forestille seg bildet i hodet [9]. Se Illustrasjon 1. Gruppa ønsket ut ifra denne studien å utvikle programvare som kombinerer EEG-headsettet fra Emotiv med symbolspråket Blissymbolics. Som et siste ledd i sonderingsfasen fikk vi hjelp av Sigve Larsen i utviklingsselskapet Larsen Development med å kartlegge hva slags teknisk kompetanse man trenger for utvikling av en potensiell applikasjon. I en samtale med gjesteforeleser Daniel Scheidegger fra NAV Sikte [10] i en gjesteforelesning ble det foreslått at vi så nærmere på disse mulighetene som et hovedprosjekt våren Strategianalyse Vi har analysert de strategiske forutsetningene for prosjektet sammen med oppdragsgiver. Vi ser for oss at teknologien vi ønsker å utvikle foreløpig er ung, men at den er på vei inn i markedet. Vi anser EEGkontroll som en utappet kilde for integrasjonsdesignere med nye uutforskede utfordringer. Vi mener teknologien har et stort potensiale som kommer til å få større betydning de neste årene. Vi ser for oss at vi kan bygge et solid faglig nettverk. Vi anser Open Source-utvikling som en bæredykttig ramme for utvikling, der produktet er gratis for brukere, og monetær verdiskapning kan skje gjennom SLA-avtaler med distributører, som Hjelpemiddelsentralen og interesseorganisasjoner. 12

13 Faglige forutsetninger I denne delen skal vi redegjøre for hvilke teorier og forutsetninger vi bygde på. Vi vil redegjøre for vår kompetanse fra utdannelsen og hva vi har måttet lære underveis og hvor vi har brukt kompetanse fra annen utdanning. I dette prosjektet har vi i all hovedsak foretatt våre vurderinger på grunnlag av pensumet gjennom tre år på Anvendt Datateknologi. Vi har valgt metoder fra fagene Prototyping, IT i praksis, IT-tjenester, Systemutvikling, Menneske- og Maskininteraksjon, Informasjonsarkitektur, Visualisering og Universell utforming. To av gruppemedlemene valgte å lære Python og Kivy underveis i prosjektet. Begge har tatt Programmering og Programutvikling som valgfag og har noe bakgrunn fra Java. Ingen av gruppemedlemmene har bakgrunn fra omsorgsyrker eller medisinsk bakgrunn. Der vi har hatt behov for å analysere brukeres behov på grunnlag av medisinske tilstander har vi utført research. Vi kan ikke ta ansvar for forskningsmetodene på dette feltet, annet enn å redegjøre for våre kilder og våre konklusjoner. Om utviklingsprosessen I denne delen vil vi begynne med å redegjøre for vår problemformulering, hvordan vi tenkte i starten om prosjektet og hvordan dette har utviklet seg. Vi vil vise faser, problemer og løsninger. Vi vil også forklare hvilke utviklingsfaser prosjektet har hatt og hvordan vi har reflektert over de faglige utfordringene. Vi vil redegjøre for hvilke valg vi har gjort om oppbygging og funksjon i programmet. Vi vil redgjøre for utfordringer i prosessen og samarbeidet med oppdragsgiver. Faser Denne utviklingsprosessen har, i organisasjonssammenheng, omfattet Strategi- og modningsprosessen og Valgfasen. Kravspesifikasjonen og dens rolle I de følgende avsnittene vil vi redegjøre for rollen Kravspesifikasjonen hadde i utviklingen av løsningen i vårt prosjekt. Vi vil redegjøre for hvordan den har blitt laget og hvordan den har blitt en del av kvalitetssikringen. Kravspesifikasjonen er også presentert på side 27 i Prosessrapporten, og lagt til som et eget vedlegg, se Kravspec_ Kravspesifikasjonen ble utarbeidet i Valgfasen, som en del av den research som har blitt utført her. Den ble utarbeidet på bakgrunn av Behovsanalyse og faglige prinsipper fra Prototyping, IT i praksis, ITtjenester, Systemutvikling, Menneske- og Maskininteraksjon, Informasjonsarkitektur, Visualisering og Universell utforming. Kravspesifikasjonen ble utarbeidet parallelt med utviklingen. Når vi har blitt kjent med nye krav og ønsker til funksjonalitet har vi lagt det inn i Kravspesifikasjonen fortløpende. Vi kan vanskelig påstå at løsningen vår er et produkt av kravene. I vårt arbeid kan vi like gjerne hevde at kravene er et produkt av de erfaringer som er gjort gjennom innledende designfaser. Kravene har derimot blitt brukt og referert til i vår Evalueringsmodell, side 27 i Prosessrapporten. Denne Evalueringsmodellen ble brukt og rapporter på side 28-33, samme dokument. 13

14 Kravspesifikasjonen inneholder krav som er svært spesifikt utarbeidet for målgruppen. METODE I dette kapittelet vil vi vise hvilke metoder vi har benyttet for å besvare problemstillingen og nå våre mål. Vi vil vise hvordan vi planla og hvordan planleggingen fungerte i prosessen. Vi vil redegjøre for hvilke verktøy som ble brukt, til hva og hvorfor. Vi vil forklare hva vi måtte lære, hvordan vi arbeidet og hvordan vi jobbet med oppdragsgiver og andre aktører. Vi vil også redegjøre for hvordan prosjektet ble organisert. Vi vil begynne med å vise til metoder for research til bakgrunnen for prosjektet, der vi kommer inn på kildekritikk. Deretter omtaler vi metoder brukt for utvikling. Til slutt omtaler vi organisering av prosjektet. Brukerinvolvering Behovsanalyse En omfattende Behovsanalyse er et godt utgangspunkt for ethvert utviklingsprosjekt. Vi har researchet målgruppen og designet Personas med eklektiske funksjonsbegrensninger. Vi har deretter benyttet Scenarioer i form av Use-Cases [11, pp ] til å utvikle brukerkrav [12, p. 59]. Utvikling Vi har utviklet løsningen vår med utgangspunkt i en smidig utvikling [13]. Løsningen har blitt stilt til prøve ved testing av fire prototyper. Papirprototype, Wireframe, Konseptprototype og «Proof of concept [11]» prototype.vi har benyttet akseptansetesting [12, pp. 61, ,318,343], Wizard of Oz-testing [8, p. 297] og komponenttesting [13] [14, p. 9]. All testing ble dokumentert med videoopptak. Vi ivaretok testpersonenes personvern med samtykkeskjemaer [15, pp. 98,609,740]. GUI-metoder Vi har hatt idémyldinger med skisser av skjermbilder og GUI-komponenter. Vi har foredlet løsningene med storyboards av Scenarioer og use-case. Vi har dokumentert oppbygningen av informasjonsarkitekturen med blueprint av GUI. Papirprotptype Vi i har laget en Low Fidelity, revolusjonær, bruk-og-kast, papir prototype [16] [17] med horisontal utforming [8, p. 283]. Komponentene til Papirprototypen er skissert for hånd på papir, på en datamaskin, og med ulike papirmaler som er printet og klippet ut. Samtlige av teknikkene er masseprodusert for å kunne benyttes i flere av versjonene på et tidlig- og senere stadium i løpet av testene. Dette er gjort ved å produsere et grovt overskudd av komponenter og holde dem tilgjengelige i plukkebakker. Samtlige metoder er gode kost- og tidsbesparende teknikker for idébidrag til grensesnitt. Wireframe Wireframeing [8, pp ] er en metode som ofte blir brukt innenfor webdesign [18], men er også like verdifull innenfor applikasjonsutvikling. En Wireframe betraktes som en teknisk tegning [8, p. 267] for å visualisere hvordan elementene i de forskjellige skjermbildene vil se ut i det ferdige grensesnittet. Den inneholder ikke design, men fokuserer på dimensjonering, utforming og plassering. Mange velger å bruke enkle grå bokser for å unngå visuelle distraksjoner. 14

15 Programmeringsmetoder For å teste systemdesignet, benyttet vi en «proof of concept» prototype [11]. Denne prototypen er ikke et fullverdig produkt, men skal brukes for å verifisere at systemdesignet vårt vil fungere i praksis. 1 Denne ble programmert i Python [2] med rammeverket Kivy [1], som var et krav fra oppdragsgiver. Kivy ble valgt fordi Kivy har den fordelen at programmer kan kodes én gang og deretter distribueres på Windows [19], Mac [20], Linux [21], Android [22], ios [23] og Raspberry Pi [24], for å nevne noen. Å lage programmer med Kivy sitt rammeverk vil dermed kunne gjøre distribusjon på flere plattformer enklere enn med andre rammeverk. 2 Vi måtte implementere bibliotekene til Emotiv SDK i systemdesignet vårt for å kunne benytte EPOC EEG headsettet fra Emotiv [25]. Emotiv sitt SDK [26] er offisielt sett ikke er laget for programmering med Python [27], vi måtte derfor finne en løsning på dette. Vi lærte oss å programmere i både Python og Kivy. Det å lære seg Kivy var spesielt utfordrende, siden dette er et helt nytt rammeverk (første stabile versjon kom 30 Januar 2014 [28]) med lite dokumentasjon. 3 Ingen i gruppa hadde noen forkunnskaper om Python, Kivy eller Emotiv SDK. Vi har programmert i Eclipse [29] og Sublime Text 2 [30]. Prosjektstyring I denne delen vil vi redegjøre for metoder som er benyttet for å organisere aktiviteter i prosjektperioden. Vi vil redegjøre for kildekritikk, risikoplanlegging og organisasjonsbygging. Kildekritikk Her har vi benyttet oss av pensumbøker, artikler fra artikkeldatabaser og nettsidene til interesseorganisasjoner. Når vi har benyttet oss av artikler har vi vært nøye med å påse at artikkelforfatterne skal referere til artikler forfattet av forskere innen relevante felt, helst ved andre institusjoner enn deres egen, utgitt av anerkjente institusjoner og at de ikke skal henvise til egne, tidligere arbeider. Vi har benyttet interesseorganisasjoners nettsteder for å få innsikt i hvilke hjelpemidler som brukes av målgruppen i dag. 4 Research har blitt dokumentert som kildehenvisninger. Vi har benyttet kilder fra faglitteratur, artikler fra høgskolens databaser og diverse eksterne nettsider fra relevant organisasjoner. Vi har researchet utfordringer underveis i programmeringen ved å oppsøke videobloggere, dokumentasjon på programmeringsspråket og utviklerblogger. Underveis har vi også oppsøkt kontekstrelevante løsninger på chatlogger og forum. Prosjektstyring Vi har benyttet et rammeverk for å dokumentere utvikling og implementering av bransjestandard utformet av Bo Hjorth Christensen [31]. All testing er dokumentert i rapporter utformet i IEEE-standard [32]. Vi har også benyttet en modell for organisering av alle interessenter og aktører, se Illustrasjon 1 [33, p. 12]. 1 Jamfør våre avgrensninger for prosjektet. 2 Omfordele disse opplysningene hvs vi får tid 3 Bør egentlig flyttes til resultater 4 Se situasjonsanalyse, vedlegg prosessrapport 15

16 Illustrasjon 2 Aktører og interessenter Vi har operert med en organisasjon sammensatt av en rekke aktører og interessenter. De er redegjort for i vedlegg. Organisasjonen omfatter representanter fra BCI [3], StatPed [34], ICCHP [35], Isaac Norge [36], Mesh Norway [37] og NAV Sikte [10]. Vi har foretatt en risikoanalyse som omfatter organisatoriske og finansielle forhold, samt våre ambisjoner og avgrensninger. Med utgangspunkt i denne risikoanalysen har vi jobbet målrettet med å forebygge risikofaktorer, blant annet ved å etablere eierskap til prosjektet i alle ledd i organisasjonen. Vi har hatt en underskrevet samarbeidsavtale med oppdragsgiver og en intern samarbeidsavtale i prosjektgruppen. Prosjektgruppen har også vært organisert med individuelle ansvarsområder, og har vært organisert i to fraksjoner med hvert sitt hovedansvar. 5 Vi har søkt å komme i kontakt med målgruppen, utføre brukerundersøkelser og kvalitetssikre gjennom å bygge et faglig nettverk og få tilbakemeldinger på arbeid underveis. Vi har levert to Abstracts til ICCHP, henholdsvis til SS12-Competition [38] og Young Researchers Consortium [39]. Vi deltok med en stand på Isaac Norges messe på Hovseter 8. april. Vi har vært i kontakt Prosjektleder (Prosjekteier) Tobias med utviklermiljøet Mesh Norway og fått noe veiledning i å profilere oss mot eventuelle samarbeidspartnere. Oppdragsgiver GUI-del Emilie Jallis Raymond Illustrasjon 3 Gruppeorganisering Programmeringsdel Nina Tobias ANALYSE Her følger en oversikt over alt materiale vi har lagt til analyse mot konklusjonen av prosjektet. Materialet omfatter rapporter vi har produsert gjennom aktiviteter underveis; Sammendrag av vår research, utvikling og tilrettelegging. Dette materialet er tilgjengelig i rapporten som vedlegg. Analysene er organisert i tre hovedkategorier; Brukerinvolvering, Utvikling og Styringsdokumenter. Dette materialet vil vi bruke til å redegjøre for den nåværende posisjonen til prosjektet, overlevere dokumentasjon til oppdragsgiver og 5 Referer til vedlegg Prosessrapport, Organisering av prosjektet. 16

17 vurdere kvaliteten av vårt eget arbeid. Fra dette materialet kan vi også konkludere ved hvorvidt metodene har egnet seg for å nå våre mål. Brukerinvolvering For å vurdere vår grad av Brukerinvolvering vil vi analysere materiale som stammer fra vår research og brukerkontakt. Dette materialet omfatter Personas, Behovsanalyse og Kravspesifikasjon. Gjennom disse dokumentene kan vi formidle vår forståelse av målgruppene. Materialet bør analyseres samlet, med utgangspunkt i om målgruppen er tilstrekkelig involvert; Har vi lykkes med å ha en brukerstyrt utvikling? Er det sannsynlig at målgruppen har fått satt sitt preg på utviklingsprosessen? Dette arbeidet er ikke så lett å analysere med et kvanitifiserbart resultat. Derimot vil vi kunne reflektere over brukerinvolveringen i kapittelet Diskusjon. Utvikling Beskrivelser av prototypene, Testdokumentasjon og Kildekode. Materialet fra utviklingen bør derimot analyseres med tanke på å dokumentere den tekniske løsningen; Hvordan er den bygget opp og hvordan kan en programmerer bruke den videre? Hvilke krav er oppfylt og hvilke må jobbes mer med? Fra disse dokumentene vil vi legge frem en hel del resultater. Fra beskrivelsene av prototypene vil vi presenter løsningsforslaget vårt gjennom de modeller og beskrivelser vi har produsert i materialet. Fra Testdokumentasjonen vil vi legge frem testresultater. Kildekoden vil bli analysert med tanke på hvor tilrettelagt den er for videre utvikling. Prosjektstyring Til sist vil vi redegjøre for styringsdokumenter og kvalitetssikring av prosessen; Prosessrapport, Dagbok og tilbakemeldinger fra henholdsvis ICCHP og Erling Andersen. Styringsdokumenter analyseres for å vurdere prosjektets levedyktighet og prosjektgruppens gjennomføringsevne. Prosessrapporten inneholder materiale og notater fra prosjektstart, gjennom aktiviteter, research og redegjørelser for strategiske valg. Dagboken redegjør noe for hva som ble gjort når. Fra prosessrapporten og Dagboken vil vi analysere risikohåndteringen i prosjektet. Blant annet vil vi kunne analysere hvorvidt planlegging ble fulgt opp og om tidsrammene holdt. ICCHP har stilt et panel på ti kvalifiserte fagpersoner til å vurdere innsendte Abstract opp mot en rekke kriterier, henholdsvis Scientific Quality, Relevance to Conference, State of the Art, Originality/Novelty, Readability and Organisation of the Paper, User Involvement and User Centred Approach samt Impact and Importance for the Field. Vi vil presentere hvilken score vi fikk fra deres vurdering og reflektere over prosjektets faglige levedyktighet. Det blir også naturlig å reflektere over en epost vi fikk fra en kontakt i Mesh Norway. Underveis i prosjektet var vi i kontakt med mer tradisjonelle utviklingsmiljøer og næringslivet. Vi ble oppfordret til å presentere oss for eventuelle samarbeidspartnere med en PowerPoint-presentasjon. Fra tilbakemeldingene på denne vil vi vurdere prosjektets modenhet for markedsføring. 17

18 RESULTATER I dette kapittelet vil vi samle viktige punkter fra vedleggene for å gi et kort og godt bilde av utviklingen vi har gjennomgått. Vi tar utgangspunkt i dokumentene som er nevnt i Analysen. Brukerinvolvering Resultatet av brukerinvolveringen. Vi har produsert et forslag til brukergrensesnittet og funksjonalitet i henhold til våre faglige vurderinger. Disse vurderingene er gjort med utgangspunkt i vår research om målgruppen, se Vedlegg 002 Prosessrapport, side 12. Fremgangsmåter for design Koble designprosessen med konseptuelle idé Utgangspunkter for å Analysere og beskrive et design Relevante metoder for å prototype Metoder for å dokumentere resultatene Metoder vi brukte Use-Case Idémyldring Skisse Storyboards Designprinsipper Visjon Personas Scenarioer Organisering Layout Posisjon Universell tilgjengelighet Papirprototype Wireframe Aktivitetsdiagrammer Blueprint Kravspesifikasjon Prosessdokumentasjon Metoder vi ikke brukte QOC Tabell 1 Designmetoder Gruppering Labeling Metaforer Rikt bilde Utvikling GUI, beskrivelse I arbeidet med brukergrensesnittet har vi identifisert tilsammen 25 relevante metoder fra pensum. Av disse har vi benyttet 18 metoder i utviklingen. I Feil! Fant ikke referansekilden. gir vi en kort oversikt over hvilke metoder vi har brukt, og hvilke vi ikke har brukt. De metodene vi ikke har benyttet, har sentrert rundt beskrivelse, analyse og kritiske vurderinger av løsninger. Prioriteringen er tydelig; Vi har prioritert en uavbrutt fremmarsj i utviklingen mot en «God nok» og «Brukbar» løsning. I denne settingen ser vi at redegjørelse for designprinsipper og tilgjengelighet er prioritert. Illustrasjon 4 Blueprint, fra Vedlegg _008 På den annen side har vi helt tydelig benyttet et rikt utvalg av metoder for kommunikasjon av ideer og dokumentasjon; Vi har produsert 14 scenarioer, 13 aktivitetsdiagrammer og 1 blueprint over informasjonsarkitekturen. Vi har produsert tilsammen 36 krav til kravspesifikasjonen, parallelt med denne utviklingen. Gjennom kapittelet vil vi gjengi noen av disse, med henvisninger til de ulike delene av rapporten, for å gi et godt bilde av bredden i utviklingen. 18

19 Illustrasjon 5 Global meny Gjennom utviklingen i prosjektet har vi både evaluert, valgt ut og programmert egne komponenter. Noen av tankene vi har gjort oss underveis kan beskrives med de følgende; Illustrasjon 7, Illustrasjon 4, Feil! Fant ikke referansekilden.. Konsept-beskrivelse Konseptet er bygget som en integrasjonsløsning, av komponenter fra ulike systemer som vanligvis ikke blir brukt sammen. Se gjerne Feil! Fant ikke referansekilden. Resultater av konseptprototype-test Testen ga oss 16 av 20 korrekte svar fordelt på de to testpersonene i målgruppen vi testet på. Dette tilsvarer 80% korrekte besvarelser, med bare 5 innlesninger for hver testperson av Blissymbolene for Ja, og 5 innlesninger for Nei. Illustrasjon 7 Modell, fra Vedlegg _004Kravspesifikasjonen Illustrasjon 6 Arkitektur, Vedlegg _004Kravspesifikasjonen 19

20 Resultater fra testing av GUI Resultatene er basert på analyser av adferd og muntlige tilbakemeldinger fra testpersonene. Resultater Papirprototype-test: Vi fikk ingen positive tilbakemeldinger under testene av papirprototypen. Fokuset hos testpersonene lå på det de var ufornøyde med. Alle testpersonene hadde forskjellige problemer, men noen pekte seg ut spesielt. 3 av 4 testpersoner stoppet opp i den samme oppgaven. Etter oppgavene Brukeroppretting og Innlogging, som ikke bød på stor motgang, var det hovedsakelig funksjonene under symboltreningen alle testpersonene hadde vanskeligheter med å forstå konseptet bak. Det var uklart hva knappene gjorde før testpersonene hadde testet dem ut og testpersonene nølte med å gå videre. Det ble klaget på ulogisk tegnbruk og treig navigasjon. Manglende feedback gjorde det også forvirrende å vite hvilke symboler som var valgt, trent og ikke trent for testpersonene. Indikasjon for start av symboltreningen ble etterspurt. Logg ut knappenble testet av to personer uten at de ble bedt om det på forhånd. Vi fikk forslag til forbedringer fra alle testpersonene etter at deres økt var over. Resultater wireframeprototype-test: Det var generelt bedre stemning under wireframe-testene sammeliknet med den forrige testen. Det kom en klage på plasseringen av hjelpeteksten nederst på sidene slik at den ikke ble oppdaget med en gang. Tespersonene leste hjelpetekster når de ble forvirret. Hjelpeteksten hjalp.en testperson klaget over to museklikk for mye under testing av inntrent symbol og ville heller ha mulighet for å teste direkte på ferdig-menyen. To knapper kunne oppfattes tvetydig. Vi fikk tilbakemelding om forvirrende gruppering. En testperson savnet tydeligere feedback på task. Det var tre tilfeller av uviktige feil basert på glemsomhet under utformingen av wireframen, hvor det som var mest alvorlig var at alt var skrevet i comic sans. Dette vil ha første prioritet hos neste versjon av wireframen. Det var muligheter for alternative ruter under noen av scenarioene. De fleste testpersonene tok som regel den korteste veien.hjelpefunksjonen som var tilgjengelig ble ikke enset av noen av testpersonene. Alle testpersonene hadde positive tilbakemeldinger. Funksjonaliteten var lett å gjette seg fram til og veide opp for manglende hjelpetekst. Det vakte mye ros for et intuitivt, kjent og simplistisk design som ble godt likt. Knappene var godt forklarende, med kun et par steder hvor tvetydighet oppstod. Statistikk mellom papir og wireframe: Gjennomgang av alle scenarioer på papirprototyp 20min i gjennomsnitt gjennomgang av alle scenarioer på wireframe 10min i gjennomsnitt. Wireframe ikke avhengig av manuell bytting av skjermbilder, men mer enn dobbelt så mange scenarioer. Inntrykk av at wireframe testene gikk mye raskere til tross for forskjellig hastighet for selve mediumet. 20

Vedlegg Brukertester INNHOLDFORTEGNELSE

Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester INNHOLDFORTEGNELSE Vedlegg Brukertester... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som

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

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

Testrapport for Sir Jerky Leap

Testrapport for Sir Jerky Leap Jasmine Garry (s135600) Line Sørensen (s135590) Fredrik Hoem Grelland (s135595) Tor Anders Gustavsen (s127668) 1 1. Forord Dette dokumentet inneholder informasjon og redegjøring av tester foretatt i forbindelse

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

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

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

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

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo,

Kravspesifikasjon. Aker Surveillance. Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus. Oslo, Kravspesifikasjon Aker Surveillance Gruppe 26 Hovedprosjekt ved Høgskolen i Oslo og Akershus Oslo, 12.01.2013 Public 2013 Aker Solutions Page 1 of 7 Table of Contents Forord... 3 Om bakgrunnen... 3 Presentasjon...

Detaljer

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015

KRAVSPESIFIKASJON DAGSPLANAPPLIKASJON FOR NETTBRETT. Gruppe 28 Hovedprosjekt våren 2015 KRAVSPESIFIKASJON Kravspesifikasjon er en beskrivelse av hvilke krav oppdragsgiver har til systemet som skal utvikles. Den fungerer som en kontrakt mellom oppdragsgiver og utviklere. DAGSPLANAPPLIKASJON

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

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

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR

UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR INF 1050 UKEOPPGAVER 2: SYSTEMUTVIKLINGSPROSESSER OG PROSJEKTARBEID INNSPILL TIL SVAR Oppgave 1 a) Foranalyse: Foranalysen kan med fordel gjøres i to trinn. Den første er å undersøke finansiering og øvrige

Detaljer

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser)

Arbeidsplan. Startfasen. Aktivitet Beskrivelse Ferdig Ansvarlig (Ressurser) Arbeidsplan En arbeidsplan er en måte å få oversikt over de ulike fasene i prosjektet. I arbeidsplanen har vi delt arbeidet i naturlige faser og detaljert disse med estimert tidsbruk. Hovedfasene er startfasen,

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

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015

Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Bachelorprosjekt i anvendt datateknologi våren 2015 Oslo 23.01.2015 Forprosjektrapport Presentasjon Tittel: Definisjon: Gruppemedlemmer: Supplerende Kommunikasjon Assistent (SKA) Bachelorprosjektet går

Detaljer

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016

Forprosjektrapport. Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016 Forprosjektrapport Hovedprosjekt for gruppe 13, Anvendt datateknologi våren 2016 1.0 Presentasjon 2.0 Sammendrag 3.0 Dagens situasjon 4.0 Mål og rammebetingelser 5.0 Løsninger/alternativer 6.0 Analyse

Detaljer

Prosjektrapport. Gruppe 23

Prosjektrapport. Gruppe 23 Prosjektrapport Gruppe 23 Prosjektrapport Forord Hensikten med denne rapporten er å gi en introduksjon til oppgaven. Her vil det bli forklart hensikten med oppgaven og applikasjonens funksjonalitet. Brukergrensesnittet

Detaljer

Forprosjektrapport. Gruppe 3, Anvendt Datateknologi våren 2016

Forprosjektrapport. Gruppe 3, Anvendt Datateknologi våren 2016 Forprosjektrapport Gruppe 3, Anvendt Datateknologi våren 2016 1. Presentasjon 2. Sammendrag 3. Dagens situasjon 4. Mål og rammebetingelser 5. Løsninger/alternativer 6. Analyse av virkninger 1. Presentasjon

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

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport

Høgskolen i Oslo og Akershus. Bachelorprosjekt Hacking Cristin. (midlertidig tittel) Forprosjektrapport Høgskolen i Oslo og Akershus Bachelorprosjekt 2017 Hacking Cristin (midlertidig tittel) Forprosjektrapport Innholdsfortegnelse: 1.0 Presentasjon s. 3 2.0 Sammendrag s. 3 3.0 Dagens situasjon s. 4 4.0 Mål

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

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

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

Bokanbefalinger (Ref #1048)

Bokanbefalinger (Ref #1048) Bokanbefalinger (Ref #1048) Søknadssum: 700000 Varighet: Ettårig Kategori: Innsatsområder Ny formidling Nasjonalbibliotekets digitale tjenester som grunnlag for nye tilbud Opplysninger om søker Organisasjonsnavn

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

Testrapport Prosjekt nr SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 8 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen

Testrapport Prosjekt nr SSP Installasjon AS. Dato: 25.mai 2007 Antall sider: 8 Intern veileder: Kjetil Grønning. Kontaktperson: Kai Evjen Prosjekt nr. 2007-11 Testrapport Tittel: Informasjonssystem SSPI Prosjektdeltakere: Hans Petter Kristiansen, s130182 Espen Skaarer, s123590 Dato: 25.mai 2007 Antall sider: 8 Intern veileder: Kjetil Grønning

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

1. Presentasjon av prosjekt. Forord

1. Presentasjon av prosjekt. Forord 1. Presentasjon av prosjekt Forord Dette prosjektet har strukket seg over et semester på Høgskolen i Oslo og Akershus, institutt for Informasjonsteknologi. Prosjektet har vært et utfordrende, men samtidig

Detaljer

GJENNOMGANG UKESOPPGAVER 9 TESTING

GJENNOMGANG UKESOPPGAVER 9 TESTING GJENNOMGANG UKESOPPGAVER 9 TESTING INF1050 V16 KRISTIN BRÆNDEN 1 A) Testing viser feil som du oppdager under kjøring av testen. Forklar hvorfor testing ikke kan vise at det ikke er flere gjenstående feil.

Detaljer

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android

6 Kravspesifikasjon. 6.1 Presentasjon. Tittel Precision Teaching App for Android 6 Kravspesifikasjon 6.1 Presentasjon Tittel Precision Teaching App for Android Oppgave Å lage en Android app som skal benyttes av studenter for å øve på fagpensum. Appen skal ta i bruk prinsipper fra Precision

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

Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010.

Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010. TESTDOKUMENTASJON Forord Dette er testdokumentasjonen skrevet i forbindelse med hovedprosjekt ved Høgskolen i Oslo våren 2010. Dokumentet beskriver hvordan applikasjonen er testet. Dokumentet er beregnet

Detaljer

Forskningsmetoder i informatikk

Forskningsmetoder i informatikk Forskningsmetoder i informatikk Forskning; Masteroppgave + Essay Forskning er fokus for Essay og Masteroppgave Forskning er ulike måter å vite / finne ut av noe på Forskning er å vise HVORDAN du vet/ har

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

Brukersentert design Kapittel 3 i Shneiderman

Brukersentert design Kapittel 3 i Shneiderman Brukersentert design Kapittel 3 i Shneiderman ISO 9241-210 Iterativ og brukernær systemutvikling. Kriterier for valg av metode. Brukersentrert design vs. RUP. Deltagende design Den skandinaviske arven.

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

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio.

Forprosjektrapport. ERTMS Driver Interface simulering. ERTMS Driver Interface simulering. Alexander Yngling Alexander.Yngling@iu.hio. Forprosjektrapport ERTMS Driver Interface simulering Prosjektets tittel: ERTMS Driver Interface simulering Gruppe medlemmer: Hallgeir Are Olsen s141454, 3IA Hasan Akin s141460, 3IA Oppdragsgiver: NSB skolen

Detaljer

HOVEDPROSJEKT Studieprogram: Informasjonsteknologi. Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo

HOVEDPROSJEKT Studieprogram: Informasjonsteknologi. Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo 1 PROSJEKT NR. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo 2014-28 TILGJENGELIGHET Åpen HOVEDPROSJEKT HOVEDPROSJEKTETS TITTEL

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

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007

Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Hovedprosjekt i data ved Høgskolen i Oslo våren 2007 Testrapport Høgskolen i Oslo Student: Martin Oppegaard Gruppe: 07-12 Dato: 25. mai 2007 Veileder ved HIO: Eva Vihovde Oppdragsgiver: Bekk Consulting

Detaljer

Gruppe Forprosjekt. Gruppe 15

Gruppe Forprosjekt. Gruppe 15 Forprosjekt Gruppe 15 Marius Ylven Westgaard - s236797 - Anvendt Datateknologi Lise Janbu Eide - s236361 - Dataingeniør Lavanja Jeyenthiran - s236346 - Dataingeniør Kristian Pedersen - s236728 - Anvendt

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

Forprosjektrapport Hovedprosjekt våren 2015 HiOA

Forprosjektrapport Hovedprosjekt våren 2015 HiOA Forprosjektrapport Hovedprosjekt våren 2015 HiOA Gruppe 9 Innhold 1. Presentasjon.... 3 2. Sammendrag.... 3 3. Dagens situasjon... 4 4. Mål og rammebetingelser... 5 5. Løsninger/Alternativer.. 6 6. Analyse

Detaljer

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet

Kravspesifikasjon. 1. Innledning. Presentasjon. Innledning. Om bedriften. Bakgrunn for prosjektet Kravspesifikasjon Presentasjon Tittel: Oppgave: Backup for PDA/Smartphones Utvikle en applikasjon for PDA/Smartphones med funksjonalitet for backup av sms, mms, e-post, kontakter, kalender, bilder og dokumenter

Detaljer

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31

Kravspesifikasjon. Noark 5 grensesnitt. Hovedprosjekt informasjonsteknologi. Gruppe 31 Kravspesifikasjon Noark 5 grensesnitt Hovedprosjekt informasjonsteknologi Gruppe 31 Forord Denne kravspesifikasjonen inneholder retningslinjer for oss og for det vi skal utvikle. Den inneholder funksjonelle

Detaljer

TESTRAPPORT - PRODSYS

TESTRAPPORT - PRODSYS TESTRAPPORT - PRODSYS PRODSYS-DATASYSTEM FOR ÅS PRODUKSJONSLAB AS GRUPPE 12 CHRISTOPHER CONRADI STEFFEN DIEDRICHSEN ROMAN KOVALENKO INFORMASJONSTEKNOLOGI, INGENIØRUTDANNINGEN, HØYSKOLEN I OSLO 1. FORORD

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

Forprosjektrapport. Hovedprosjekt Gruppe 15

Forprosjektrapport. Hovedprosjekt Gruppe 15 Forprosjektrapport Hovedprosjekt Gruppe 15 Erlend Gunnesen, Lars Sætaberget, Are Inglingstad, Marius Maudal 25.02.2014 Innholdsfortegnelse 1.Introduksjon... 2 1.1 Medlemmer:... 2 1.2 Oppdragsgiver:...

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

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

Inf1510: Oppsummering. Rune Rosseland

Inf1510: Oppsummering. Rune Rosseland Inf1510: Oppsummering Rune Rosseland Plan Gjennomgang av evalueringskriterier Læringsmål Hva gir en god / dårlig karakter? Svare på spørsmål 3 Læringsmål 1. Bruke flere metoder for bruks-orientert design.

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

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

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

Forskningsmetoder i informatikk

Forskningsmetoder i informatikk Forskningsmetoder i informatikk Forskning; Masteroppgave + Essay Forskning er fokus for Masteroppgave + Essay Forskning er ulike måter å vite / finne ut av noe på Forskning er å vise HVORDAN du vet/ har

Detaljer

Se mulighetene! Forankring i kunnskapsløftet. Norsk. Kompetansemål

Se mulighetene! Forankring i kunnskapsløftet. Norsk. Kompetansemål Forankring i kunnskapsløftet Norsk Et hovedmål for opplæringen i norsk gjennom det 13-årige løpet er språklig selvtillit og trygghet i egen kultur som grunnlag for utvikling av identitet, respekt for andre

Detaljer

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016

Forprosjektrapport. Hovedprosjekt i Informasjonsteknologi. Høgskolen i Oslo og Akershus. Våren 2016 Forprosjektrapport Hovedprosjekt i Informasjonsteknologi Høgskolen i Oslo og Akershus Våren 2016 Gruppe 24 Jon Gillingsrud og Christoffer André Belgen Fredriksen Veileder Thor E. Hasle thor.hasle@hioa.no

Detaljer

emeistring 2.0 behandlerdel Presentasjon av kravspesifikasjon og prototype

emeistring 2.0 behandlerdel Presentasjon av kravspesifikasjon og prototype emeistring 2.0 behandlerdel Presentasjon av kravspesifikasjon og prototype Velkommen! Program for presentasjonen: Bakgrunn for og hensikt med prosjektet Prosjektgruppen og interessenter Prosjektplanen

Detaljer

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO

DRI2001 Offentlige nettsteder. Litt om systemutvikling Torsdag 24 aug Arild Jansen, AFIN, UiO DRI 2001 13.9 : Introduksjon til systemutvikling. Introduksjon til systemutvikling Systemutvikling og nettstedsutvikling Om ulike typer offentlige nettsteder Kvalitetskrav til offentlige nettsteder Litt

Detaljer

Undervisningsopplegg i matematikk. Med fokus på bruk av IKT

Undervisningsopplegg i matematikk. Med fokus på bruk av IKT Undervisningsopplegg i matematikk Med fokus på bruk av IKT Innholdsfortegnelse Innledning... 3 Målsetning... 3 Valg av programvare... 3 Evaluering... 4 Undervisningsopplegget... 5 Arbeidsmetoder... 5 Temaliste...

Detaljer

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 2 - revidert 10.02.2010 AESTON. Side 1

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 2 - revidert 10.02.2010 AESTON. Side 1 Brukerveiledning Kom i gang publiseringsverktøy versjon 2 - revidert 10.02.2010 AESTON Side 1 Velkommen som bruker av Kameleon Introduksjon Kameleon er et publiseringsverktøy (Content Management system

Detaljer

Kravspesifikasjon. Forord

Kravspesifikasjon. Forord Forord Kravspesifikasjonen skal gi en oversikt og forståelse over det planlagte systemets funksjonalitet. Dokumentet skal gi både utviklere og oppdragsgivere innblikk i hvordan og hva systemet skal levere.

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

Ved KHiB brukes åtte kriterier som felles referanseramme for vurdering av studentenes arbeid ved semestervurdering og eksamen:

Ved KHiB brukes åtte kriterier som felles referanseramme for vurdering av studentenes arbeid ved semestervurdering og eksamen: VURDERING OG EKSAMEN I KHiBS BACHELORPROGRAM I DESIGN Spesialisering i Visuell kommunikasjon eller Møbel- og romdesign/interiørarkitektur 1. Introduksjon til vurderingskriteriene I kunst- og designutdanning

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

Kravspesifikasjon for utvikling av digitale selvbetjeningsløsninger for mobilisering til forskningsbasert innovasjon

Kravspesifikasjon for utvikling av digitale selvbetjeningsløsninger for mobilisering til forskningsbasert innovasjon Kravspesifikasjon for utvikling av digitale selvbetjeningsløsninger for mobilisering til forskningsbasert innovasjon Bakgrunn Forskningsrådet har de siste årene utviklet og oppgradert flere tjenester som

Detaljer

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE

RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE RETNINGSLINJER FOR SKRIVING AV SLUTTRAPPORT VED BACHELOROPPGAVE Det gis ulike anbefalinger for hvordan en prosjektrapport skal se ut. Noen krav til innhold og utseende er beskrevet i forslaget nedenfor.

Detaljer

Aktive hyller (Ref #1307884069102)

Aktive hyller (Ref #1307884069102) Aktive hyller (Ref #1307884069102) Søknadssum: 429600 Kategori: Ny formidling Varighet: Ettårig Opplysninger om søker Organisasjonsnavn / nr Deichmanske bibliotek / 992410213 Arne Garborgs plass 4 0179

Detaljer

Notater: INF1510. Veronika Heimsbakk 20. mai 2015

Notater: INF1510. Veronika Heimsbakk 20. mai 2015 Notater: INF1510 Veronika Heimsbakk veronahe@ifi.uio.no 20. mai 2015 Innhold 1 Bruk 3 1.1 Begrepet «bruk»......................... 3 1.2 Begrepet «behov»........................ 3 1.2.1 Maslows behovspyramide................

Detaljer

Regning i alle fag. Hva er å kunne regne? Prinsipper for god regneopplæring. 1.Sett klare mål, og form undervisningen deretter

Regning i alle fag. Hva er å kunne regne? Prinsipper for god regneopplæring. 1.Sett klare mål, og form undervisningen deretter Regning i alle fag Hva er å kunne regne? Å kunne regne er å bruke matematikk på en rekke livsområder. Å kunne regne innebærer å resonnere og bruke matematiske begreper, fremgangsmåter, fakta og verktøy

Detaljer

Forslag til ny læreplan for informatikk studieretningsfag

Forslag til ny læreplan for informatikk studieretningsfag Forslag til ny læreplan for informatikk studieretningsfag Jens Kaasbøll, undervisningsleder, Institutt for Informatikk Foredrag på Faglig-pedagogisk dag Universitetet i Oslo, 4. januar 2000 1 Behov for

Detaljer

Rapportskriving. En rettledning.

Rapportskriving. En rettledning. Rapportskriving En rettledning http://www.mal.hist.no/hovedprosjekt Rapportens innhold Forord Sammendrag Innholdsfortegnelse Innledning Hoveddeler Teori Metode Resultater Avslutning Referanser/Litteratur

Detaljer

Kundereisen Vedlegg 1 Oppdragsbeskrivelse/kravspesifikasjon Konkurransegrunnlag for anskaffelse av Kundereisen 2016

Kundereisen Vedlegg 1 Oppdragsbeskrivelse/kravspesifikasjon Konkurransegrunnlag for anskaffelse av Kundereisen 2016 *Foto: se siste side. Kundereisen 2016 Anskaffelse av kundereiseprosess basert på kvalitativ metode og design thinking relatert til tjenesteutvikling. Dette dokumentet gir en rask oversikt over Kundereisen

Detaljer

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006

Forstudierapport. Magne Rodem og Jan-Erik Strøm. 18. juni 2006 Forstudierapport Magne Rodem og Jan-Erik Strøm 18. juni 2006 Innhold 1 Introduksjon 3 2 Bakgrunn for prosjektet 3 2.1 Beskrivelse av problemer og behov........................... 3 2.2 Kort om dagens systemer................................

Detaljer

Gruppe 23. Rapport D2, MMI. Prototypen. Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under.

Gruppe 23. Rapport D2, MMI. Prototypen. Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under. Rapport D2, MMI Prototypen Tilstandsdiagrammet til prototypen ser slik ut: Designet på prototypen er som under. Man lager en ny avtale ved å trykke på knappen add event oppe i høyre hjørne. For å komme

Detaljer

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling

Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling Innledning Læringsmål Systemutviklingsprosesser Forelesning 2 - INF1050 Systemutvikling 21.1.2009 Forstå hvorfor systemutviklingsprosessen er viktig Forstå de viktigste prinsippene for ulike prosesser

Detaljer

Forprosjektrapport. Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015

Forprosjektrapport. Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015 Forprosjektrapport Hovedprosjekt for gruppe 4, Anvendt datateknologi våren 2015 1.0 Presentasjon 2.0 Sammendrag 3.0 Dagens situasjon 4.0 Mål og rammebetingelser 5.0 Løsninger/alternativer 6.0 Analyse av

Detaljer

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram

Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Læreplan i informasjonsteknologi - programfag i studiespesialiserende utdanningsprogram Fastsatt som forskrift av Utdanningsdirektoratet 3. april 2006 etter delegasjon i brev 26. september 2005 fra Utdannings-

Detaljer

HOVEDPROSJEKT 2006. Endring av nettverksinfrastruktur for Simplicatus AS og implementering av VPN. Morten Sandberg Dataingeniørstudent HiST/AITeL

HOVEDPROSJEKT 2006. Endring av nettverksinfrastruktur for Simplicatus AS og implementering av VPN. Morten Sandberg Dataingeniørstudent HiST/AITeL HOVEDPROSJEKT 2006 Endring av nettverksinfrastruktur for Simplicatus AS og implementering av VPN Morten Sandberg Dataingeniørstudent HiST/AITeL Oppdragsgiver Om Simplicatus Liten bedrift som ble stiftet

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

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish.

Brukermanual - Joomla. Kopiering av materiale fra denne Bonefish manualen for bruk annet sted er ikke tillatt uten avtale 2010 Bonefish. Brukermanual - Joomla Bonefish brukermanual - Joomla Gratulerer med ny nettside fra Bonefish. Du er nå blitt eier og administrator for din egen nettside, noe som gir deg visse forpliktelser ovenfor din

Detaljer

Diskusjonsoppgaver Hvilke fordeler oppnår man ved analytisk evaluering sammenliknet med andre tilnærminger?

Diskusjonsoppgaver Hvilke fordeler oppnår man ved analytisk evaluering sammenliknet med andre tilnærminger? Definisjonsteori Hva er de tre hovedtilnærmingene til evaluering? Nevn de seks stegene i DECIDE. (blir gjennomgått neste uke) Gi et eksempel på en måte å gjøre indirekte observasjon. Hva ligger i begrepene

Detaljer

TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS

TESTRAPPORT   Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS TESTRAPPORT Tittel på hovedprosjektet: Varebestillingssystem for Wokas Salg AS Medlemmer av gruppe 35: Joakim Larsen, s150070, 3AB Kristian Kjelsrud, s147787, 3IA Anastasia Poroshina, s140720, 3AB Prosjektperiode:

Detaljer

Grunnleggende testteori. Etter Hans Schaefer

Grunnleggende testteori. Etter Hans Schaefer Grunnleggende testteori Etter Hans Schaefer Industri- og softwareprodukt Industriprodukt Fysisk produkt Testes under produksjon og til slutt om produktet oppfyller kravene Tilpasses, endres, redesignes,

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

Kuttbeskyttelse til Politiet

Kuttbeskyttelse til Politiet Foto: Peder Austrup DEFINERE FOKUS Kuttbeskyttelse til politiet I dette Design Pilot-prosjektet har Politiets data- og materielltjeneste (PDMT) sett på mulighetene for et bredere spekter av kuttbeskyttelse

Detaljer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer

Akseptansetesten. Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesten Siste sjanse for godkjenning Etter Hans Schaefer Akseptansetesting Formell testing med hensyn til brukerbehov, krav, og forretningsprosesser som utføres for å avklare om et system oppfyller

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

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

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

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

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort

Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort NCEI Teknologifrokost 25. Mars 2015 Fra idé til marked Hvorfor elektronikk handler om mer enn kretskort Del 1: Are Hellandsvik Forsker ved SINTEF IKT Kommunikasjonssystemer Del 2: Terje Frøysa Forsker

Detaljer

Ressurs Aktivitet Resultat Effekt

Ressurs Aktivitet Resultat Effekt Vedlegg 3 til internmelding om arbeidet med evaluering i UDI Hvordan utforme en evaluering? I dette vedlegget gir vi en beskrivelse av en evaluering kan utformes og planlegges. Dette kan benyttes uavhengig

Detaljer

SLUTTRAPPORT. Glenn Bjørlo. Bedriftspraksis. Høgskolen i Østfold. Halden

SLUTTRAPPORT. Glenn Bjørlo. Bedriftspraksis. Høgskolen i Østfold. Halden SLUTTRAPPORT Glenn Bjørlo Bedriftspraksis Høgskolen i Østfold Halden 01.12.2014 INNHOLD Overskrift Sidetall Introduksjon 3 Beskrivelse 4 Refleksjon 6 Vedlegg 1: Timebruk 9 Vedlegg 2: Attest 12 Introduksjon

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

Gjennomføring av muntlig-praktisk eksamen i Teknologi og Forskningslære 1 Privatister

Gjennomføring av muntlig-praktisk eksamen i Teknologi og Forskningslære 1 Privatister Gjennomføring av muntlig-praktisk eksamen i Teknologi og Forskningslære 1 Privatister Utdanningsprogram: Studiespesialisering Realfag Fagkode og fagnavn: REA3018 Teknologi og forskningslære 1 Type fag

Detaljer

Bilag 1 KRAVSPESIFIKASJON. Referanse: KOMM Årsrapport og samfunnsrapport. for årene med opsjon om forlengelse i ett år.

Bilag 1 KRAVSPESIFIKASJON. Referanse: KOMM Årsrapport og samfunnsrapport. for årene med opsjon om forlengelse i ett år. Bilag 1 KRAVSPESIFIKASJON Referanse: KOMM-010-2012 Årsrapport og samfunnsrapport for årene 2012-2014 med opsjon om forlengelse i ett år. Innhold BILAG 1... 1 INNHOLD... 2 1. INNLEDNING... 3 MÅLSETTING

Detaljer

Prosjektplan Bacheloroppgave 2014

Prosjektplan Bacheloroppgave 2014 Høgskolen i Gjøvik Prosjektplan Bacheloroppgave 2014 Hvordan motivere Ahlsells ansatte til økt kvalitet på leveranser? Joachim Adrian Tande Valstad Kai Asle Trøhaugen Chris André Lehre Moen 27/1-2014 Innhold:

Detaljer

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG

GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG GJENNOMGANG UKESOPPGAVER 2 PROSESSMODELLER OG SMIDIG PROGRAMVAREUTVIKLIG INF1050 V16 HVA ER EN SYSTEMUTVIKLINGSPROSESS? De aktivitetene som utføres for å utvikle et IT-system Eksempler på aktiviteter:

Detaljer