HOVEDPROSJEKT. EEGBliss. Studieprogram: Informasjonsteknologi Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo
|
|
- Stina Dalen
- 8 år siden
- Visninger:
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... 1 Testrapport Wireframe... 2 1. INTRODUKSJON... 2 1.1 Systemoversikt... 2 1.2 Meningen med testen... 2 2 TESTPLAN... 2 2.1 Funksjoner som
DetaljerTestrapport 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
DetaljerStudentdrevet innovasjon
Studentdrevet innovasjon Hovedprosjekt 2013 Høgskolen i Oslo og Akershus Forprosjektrapport av Gruppe 11 Karoline Sanderengen, Mona Isabelle Yari og Randi Ueland 25.01.2013 Studentdrevet innovasjon 9 Innhold
DetaljerTestrapport. 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
DetaljerTestrapport 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
DetaljerHOVEDPROSJEKT I DATA VÅR 2011
PROSJEKT NR. 18 TILGJENGELIGHET åpen Studieprogram: Postadresse: Postboks 4 St. Olavs plass, 0130 Oslo Besøksadresse: Holbergs plass, Oslo Telefon: 22 45 32 00 Telefaks: 22 45 32 05 HOVEDPROSJEKT I DATA
DetaljerPROSESSDOKUMENTASJON
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
DetaljerProduktrapport. Produktrapport. Hjelpemiddel portal for Parkinsonforbundet
Produktrapport Hjelpemiddel portal for Parkinsonforbundet 1 Innhold: Forord ------------------------------------------------------------------------------------------------------2 Planlegging og arbeidsmetode
DetaljerHovedprosjekt 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...
DetaljerUKEOPPGAVER 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
DetaljerPrototyping. Plenumstime Uke 6. Med Maria og Helle
Prototyping Plenumstime Uke 6 Med Maria og Helle Hva skjer i dag? Prototyping Hva og hvorfor Konseptuelt design Dimensjoner Low-fi og high-fi Oblig 3 Do s and don ts Oblig 1 09/09 Oblig 2 23/09 Oblig 3
DetaljerKunden 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
Detaljer1. 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
DetaljerForskningsmetoder 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
DetaljerDokument 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
DetaljerUtvikle 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
DetaljerTestdokumentasjon. 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
Detaljer3. 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
DetaljerKravspesifikasjon. 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...
DetaljerMø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
DetaljerHovedprosjektet 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
DetaljerPrototyping og kommunikasjon med brukere
Inf 1510: Bruksorientert design Prototyping og kommunikasjon med brukere 04.04.2016, Rune Rosseland Oversikt Brukerinvolvering Hva er brukerens motivasjon for å bidra? Hva skal brukerens rolle være? Hvordan
DetaljerForprosjektrapport. Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren Digitalisering av Sentralen UNG Gründer
Forprosjektrapport Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 207 Digitalisering av Sentralen UNG Gründer Gruppe 34 Kenneth Di Vita Jensen, s236745 Frank Arne Bjørkmann
DetaljerKravspesifikasjon. Forord
Kravspesifikasjon Forord Hensikten med en kravspesifikasjon er å gi et overblikk over programmets funksjonalitet og tilleggsfunksjoner, dette vil si både over de som er utviklet før prosjektstart, og de
Detaljer24.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
DetaljerArbeidsplan. 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,
DetaljerMakerSpace Event System
18. Januar 2019 Bachelor gruppe 11: Amanda Kristine Hansen Anders Tidemann Norli Dexter Winther Smith Innholdsfortegnelse Prosjektpresentasjon 3 Innledning 4 Bachelorgrupp a 4 Amanda Kristine Hansen 4
DetaljerDel 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
DetaljerGJENNOMGANG 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.
DetaljerKRAVSPESIFIKASJON 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
DetaljerKravspesifikasjon MetaView
Kravspesifikasjon MetaView BACHELOROPPGAVE VÅREN 2014 1. Presentasjon Tittel: MetaView Oppgave: Lage en applikasjon og api som skal kommunisere med MetaVision slik at det skal bli enklere for leger og
DetaljerForprosjektrapport. 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)
DetaljerForprosjektrapport. 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
DetaljerBachelorprosjekt 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
DetaljerStudentevaluering av undervisning. En håndbok for lærere og studenter ved Norges musikkhøgskole
Studentevaluering av undervisning En håndbok for lærere og studenter ved Norges musikkhøgskole 1 Studentevaluering av undervisning Hva menes med studentevaluering av undervisning? Ofte forbindes begrepet
DetaljerGruppe 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
DetaljerForprosjektrapport. 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
DetaljerHovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus. Forprosjektrapport. Bravo Booking App
Hovedprosjekt i Informasjonsteknologi 2016 Høgskolen i Oslo og Akershus Forprosjektrapport Bravo Booking App 1 Presentasjon 2 1.1 Gruppe 2 1.2 Oppdragsgiver 2 1.3 Kontaktpersoner 2 1.4 Oppgave 3 2 Dagens
DetaljerForord 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
DetaljerInf1510: 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.
DetaljerGruppe 43. Hoved-Prosjekt Forprosjekt
Gruppe 43 Hoved-Prosjekt Forprosjekt Mobil Applikasjon Utvikling HiOA Bacheloroppgave forprosjekt våren 2017 Presentasjon Gruppen består av: Gebi Beshir Ole-Kristian Steiro Tasmia Faruque s182414 s189141
DetaljerKandidat 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
DetaljerKravspesifikasjon. 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
DetaljerProsjektrapport. 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
DetaljerProduktrapport 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
DetaljerTESTRAPPORT - 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
DetaljerBachelorprosjekt 2017
Bachelorprosjekt 2017 Høgskolen i Oslo og Akershus Gruppe 41 Kristan Munter Simonsen (s236789) Andreas Jacobsen (s236778) Jamal Lakbir (s236722) 1 Innholdsfortegnelse Forprosjekt... 3 Presentasjon... 3
DetaljerFORPROSJEKT 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
DetaljerForprosjektrapport. 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
DetaljerFORPROSJEKT KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK
2017 FORPROSJEKT BACHELOROPPGAVE 2017 KIM LONG VU DUY JOHNNY KHAC NGUYEN ADRIAN SIIM MELSOM HÅKON THORKILDSEN SMØRVIK PRESENTASJON OPPGAVE: Oppgaven er å lage en webapplikasjon som kan hjelpe bachelor
DetaljerSe 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
DetaljerGrunnleggende 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,
DetaljerForprosjektrapport. Gruppe Januar 2016
Forprosjektrapport Gruppe 22 22. Januar 2016 Innholdsfortegnelse Innholdsfortegnelse Presentasjon Sammendrag Dagens situasjon Mål og rammebetingelser Mål Rammebetingelser Løsninger og alternativer Løsning
DetaljerForskningsmetoder 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
DetaljerFunksjonskravene 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
DetaljerDesign, bruk, interaksjon
Design, bruk, interaksjon Magnus Li magl@ifi.uio.no INF1510 23.01.2017 Denne forelesningen 1. Mennesker 2. Informasjonssystemer 3. Områder innen menneske-maskin interaksjon 4. Designe for brukere og brukskontekst:
DetaljerTestrapport 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
DetaljerTeam2 Requirements & Design Document Værsystem
Requirements & Design Document Høgskolen i Sørøst-Norge Fakultet for teknologi, naturvitenskap og maritime fag Institutt for elektro, IT og kybernetikk SRD 22/01/2018 Systemutvikling og dokumentasjon/ia4412
DetaljerForprosjektrapport 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
DetaljerLæ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
DetaljerKRAVSPESIFIKASJON. 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.
DetaljerBachelorprosjekt i informasjonsteknologi, vår 2017
Bachelorprosjekt i informasjonsteknologi, vår 2017 Gruppe 29: Marthe Janson Skogen, s236357, Ingeniørfag - data Odd Einar Hoel, s236313, Ingeniørfag - data Forprosjektrapport Rapporten inneholder presentasjon,
DetaljerHø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
Detaljer6 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
DetaljerUse Case Modeller. Administrator og standardbruker
Vedlegg 1 Use Case Modeller Administrator og standardbruker 2 Use case Logge inn Bruker Bruker ønsker å logge inn Bruker har valgt å logge inn Bruker er logget inn 1. Systemet ber om brukernavn 2. Systemet
DetaljerForprosjektrapport ElevApp
Forprosjektrapport ElevApp Bachelorprosjekt i informasjonsteknologi ved Høgskolen i Oslo og Akershus, våren 2017 Gruppe 14 Mirko Grimm, s236630 Andreas Krutnes, s236656 Japple John Regalario, s236621 Innholdsfortegnelse
DetaljerTESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen
TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS GRUPPE 15 Kenneth Ådalen Vegard Gulbrandsen Kien Trung Nguyen Dataingeniørutdanningen, Høgskolen i Oslo Våren 2009 2 S i d e FORORD I dette dokumentet tar
DetaljerBachelorprosjekt 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
DetaljerForprosjektrapport. 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:...
DetaljerChiCMS 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
DetaljerPå leting i hverdagen 5 øvelser Anbefales brukt som forarbeid og i fase 1. DET KUNNE VÆRT ANNERLEDES!
På leting i hverdagen 5 øvelser Anbefales brukt som forarbeid og i fase 1. DET KUNNE VÆRT ANNERLEDES! MÅL Å trene elevenes evne til problemløsing At elevene skaffer seg grunnlag til å lage problemstillinger
Detaljer1 Forord. Kravspesifikasjon
[Type text] [Type text] 3/5 Hovedprosjekt ingeniørutdanningen 09 Kravspesifikasjon Tittel på hovedprosjektet Tarantell Dashboard Gruppe 28 Bjørn Ove Pedersen Stian Dalviken Antall sider 6 Intern veileder
DetaljerBrukerveiledning. 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
DetaljerBokanbefalinger (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
DetaljerVed 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
DetaljerKRAVSPESIFIKASJON. 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
DetaljerRapport til Extrastiftelsen fra forprosjektet Svipp innom
1 Rapport til Extrastiftelsen fra forprosjektet Svipp innom Forord I det følgende vil vi redegjøre for forprosjektet Svipp innom, et utvikling og innovasjonsprosjekt som startet opp sommeren 2017. Dette
DetaljerBrukermanual - 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
DetaljerProgrammering i barnehagen
Programmering i barnehagen Etter at du har lest teksten skal du skrive med stikkord: Hva handler programmering om? Hvilke erfaringer bør barna i barnehagen få med programmering? 1 En digital verden Av:
DetaljerFORPROSJEKT. Gruppemedlemmer: Raja Zulqurnine Ali Muddasar Hussain (Gruppeleder/Prosjektleder) Zain-Ul-Mubin Mushtaq Christopher Llanes Reyes
FORPROSJEKT I denne rapporten gjør vi analyse for hvor mye arbeid som kan gjøres. Rapporten skal også avgrense prosjektet med en mer presis beskrivelse. Den vil i tillegg blant annet inneholde teknologi
DetaljerHovedprosjekt 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
DetaljerIKT i norskfaget. Norsk 2. av Reidar Jentoft 25.03.2015. GLU3 1.-7.trinn. Våren 2015
IKT i norskfaget Norsk 2 av Reidar Jentoft 25.03.2015 GLU3 1.-7.trinn Våren 2015 Bruk av digitale verktøy i praksis I denne oppgaven skal jeg skrive om bruk av IKT fra praksisperioden i vår. IKT er en
DetaljerForprosjekt. Oppgdragsgiver Unikia, Lille grensen 7, 0159 Oslo, Kontaktperson Anders Kose Nervold,
Hovedprosjekt i data/informasjonsteknologi Høgskolen i Oslo og Akershus Forprosjekt Prosjekttittel Unikia Android applikasjon Gruppe 13 Markus Bugge-Hundere s188909 Morten Wold Aksel Wiig s236326 s232324
DetaljerJon 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
DetaljerForprosjektrapport. Utvikle en plattform for digitalisering av foosballbord.
Forprosjektrapport Tittel Oppgave Periode Openfoos Utvikle en plattform for digitalisering av foosballbord. 3. januar til 15. juni Gruppemedlemmer Amir Ghoreshi Marcel Eggum Neberd Salimi Valentin Rey
DetaljerProsjektplan. Bachelor - Bygg Ingeniør våren 2014
Prosjektplan Bachelor - Bygg Ingeniør våren 2014 090886 Innholdsfortegnelse 1. Mål og rammer... 3 1.1 Prosjektet og problemstilling... 3 1.2 Bakgrunn... 4 1.3 Prosjektmål... 4 1.4 Rammer... 4 1.5 Programvaren...
DetaljerBRYLLUPSKREASJON. Del 1: IDEUTVIKLING - Digitalt moodboard - Skisser. Del 2: MØNSTER - Analyse av valgt skisse - Enkel mønstertilpasning
BRYLLUPSKREASJON Ut fra stikkordet skal du utvikle og produsere en bryllupskreasjon eller et bryllupsantrekk. Du har stor frihet når det gjelder design og materialbruk. Bare husk at antrekket skal kunne
DetaljerNotat om sekvens av handlinger mellom menneske og maskin
IN1030 - Systemer, krav og konsekvenser Notat av Tone Bratteteig og Jo Herstad Våren 2019 Notat om sekvens av handlinger mellom menneske og maskin Figur: Forsidene til bøkene Plans and Situated Action
Detaljer1. 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
DetaljerModerne samhandling gir konkurransefortrinn
Moderne samhandling gir konkurransefortrinn IBM Smarter Business 7november Arne Berven IT sjef Vi skaper uforglemmelige øyeblikk Visjon Skal vi nå denne visjonen må vi fra IT funksjonen bidra til verktøy
DetaljerKravspesifikasjon. 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.
DetaljerHovedprosjekt 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
DetaljerTestrapport. 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
DetaljerFagerjord sier følgende:
Arbeidskrav 2A I denne oppgaven skal jeg utføre en analyse av hjemmesiden til Tattoo Temple (http://www.tattootemple.hk) basert på lenker. Analysen er noe basert på et tidligere gruppearbeid. Hjemmesiden
DetaljerVed KHiB brukes åtte kriterier som felles referanseramme for vurdering av studentenes arbeid ved semestervurdering og eksamen:
VURDERING OG EKSAMEN I KHiBS BACHELORPROGRAM I KUNST 1. Introduksjon til vurderingskriteriene I kunst- og designutdanning kan verken læring eller vurdering settes på formel. Faglige resultater er komplekse
DetaljerKravspesifikasjon 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
DetaljerRessurs 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
DetaljerRapportskriving. En rettledning.
Rapportskriving En rettledning http://www.mal.hist.no/hovedprosjekt Rapportens innhold Forord Sammendrag Innholdsfortegnelse Innledning Hoveddeler Teori Metode Resultater Avslutning Referanser/Litteratur
DetaljerVeiledning og vurdering av Bacheloroppgave for Informasjonsbehandling
Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling Oppdatert 15. jan. 2014, Svend Andreas Horgen (studieleder Informasjonsbehandling og itfag.hist.no) Her er noen generelle retningslinjer
Detaljer