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

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

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

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

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

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

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

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

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

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

Dokument 1 - Sammendrag

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

Detaljer

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

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

Forprosjekt gruppe 13

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

Detaljer

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

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

Detaljer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 7 - revidert 29.01.2014. Gevir IT Drift AS Webside: www.gevir.no.

Brukerveiledning. Kom i gang. publiseringsverktøy. versjon 7 - revidert 29.01.2014. Gevir IT Drift AS Webside: www.gevir.no. Brukerveiledning Kom i gang publiseringsverktøy versjon 7 - revidert 29.01.2014 Gevir IT Drift AS Webside: www.gevir.no Side 1 Velkommen som bruker av Kameleon Introduksjon Kameleon er et publiseringsverktøy

Detaljer

4.1. Kravspesifikasjon

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

Detaljer

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

Tillit og troverdighet på nett. Tillit. troverdighet. på nett. Cato Haukeland, 2007

Tillit og troverdighet på nett. Tillit. troverdighet. på nett. Cato Haukeland, 2007 Tillit og troverdighet på nett Tillit OG troverdighet på nett Bacheloroppgave ibacheloroppgave nye medier i nye medier av Cato Haukeland, Universitetet i Bergen 2007 Cato Haukeland, 2007 1 Innhold 1 Forord

Detaljer

Analyse av Web- medier, Lenker. Oppgaven jeg her skal presentere har tatt utgangspunkter et gruppearbeid vi fikk utlevert. Dette lyder som følgende :

Analyse av Web- medier, Lenker. Oppgaven jeg her skal presentere har tatt utgangspunkter et gruppearbeid vi fikk utlevert. Dette lyder som følgende : Arbeidskrav 2- Atle Remi Olsen Analyse av Web- medier, Lenker. Kapittel 1- Innledning. Oppgaven jeg her skal presentere har tatt utgangspunkter et gruppearbeid vi fikk utlevert. Dette lyder som følgende

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

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

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

Detaljer

Veiledning og vurdering av Bacheloroppgave for Informasjonsbehandling

Veiledning 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

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

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

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

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

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

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

Detaljer

Tilgjengelighetstesting av elektronisk meldekort på nav.no

Tilgjengelighetstesting av elektronisk meldekort på nav.no 21. mai 2010 - "Brukerundersøkelser for universell utforming av IKT - fra forskning til praksis" Tilgjengelighetstesting av elektronisk meldekort på nav.no Ståle Kjone Seniorrådgiver & Brukskvalitetsansvarlig

Detaljer

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen

MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen If you think education is expensive... try ignorance! MindIT sin visjon er å være en anerkjent og innovativ leverandør av teknologi og tjenester i den globale opplæringsbransjen Styrende verdier i MindIT:

Detaljer

INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen. Utviklingsprosesser & krav og behov

INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen. Utviklingsprosesser & krav og behov INF1500 Høst 2015 Magnus Li Martine Rolid Leonardsen Utviklingsprosesser & krav og behov I DAG GENERELT - Generell informasjon - Et par eksempler på dårlig utforming UTVIKLINGSPROSESSER - Fire tilnærminger

Detaljer

Kravspesifikasjon. IT-infrastruktur. Kravspesifikasjon. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008

Kravspesifikasjon. IT-infrastruktur. Kravspesifikasjon. Høgskolen i Oslo. Avdeling for Ingeniører. 23. mai 2008 IT-infrastruktur Kravspesifikasjon Mathias Hagen Balagumar Rajaratnam Høgskolen i Oslo Avdeling for Ingeniører 23. mai 2008 Høgskolen i Oslo Hovedprosjekt i data, 2008 Gruppe 8 side 2 PROSJEKT NR. 08-08

Detaljer

Kjørehjelperen Presentasjon

Kjørehjelperen Presentasjon 2013 Kjørehjelperen Presentasjon Høgskolen i Oslo og Akershus Henrik Hermansen og Lars Smeby Gruppe 8 26.05.2013 Forord Oppgaven vår i dette hovedprosjektet gikk ut på å lage en mobilapplikasjon som skal

Detaljer

Noark med fokus på innhold og typografi

Noark med fokus på innhold og typografi Noark med fokus på innhold og typografi Metadatabasertesystemer Et Noark system er egentlig veldig enkel Metadata og dokumenter "Alltid" hørt folk klage på systemene Det jeg har sett bærer preg av det

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

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

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

Detaljer

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

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

Detaljer

MMI-sammendrag fra eksamener

MMI-sammendrag fra eksamener MMI-sammendrag fra eksamener Hva er MVC MVC er en software arkitektur som muliggjør å skille datalaget fra presentasjonslaget i en applikasjon. I Swing er View og Controller ofte sydd sammen til GUI komponenter

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

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

Kreativitet i brukerundersøkelser: Personas and beyond

Kreativitet i brukerundersøkelser: Personas and beyond Kreativitet i brukerundersøkelser: Personas and beyond Riitta Hellman Karde AS Brukerundersøkelser for universell utforming av IKT fra forskning til praksis Metodeworkshop om brukerundersøkelser 21. mai

Detaljer

Kvalitetskrav til løsninger

Kvalitetskrav til løsninger Prosjektoppgaven Kvalitetskrav til løsninger Noen retningslinjer for å styre beslutningene deres finnes i form av hva brukere forlanger av software (og hardware): Brukbarhet. - Produktet skal være selvforklarende

Detaljer

Windows eller Linux. i MinButikk

Windows eller Linux. i MinButikk Windows eller Linux i MinButikk Windows eller Linux Scenario Jeg har startet matbutikken MinButikk og er medlem av ToppKjeden Kjeden har ingen krav til personalsystem så jeg kan fritt velge system selv.

Detaljer

Introduksjon 1. Innledning.

Introduksjon 1. Innledning. Avdeling for informatikk og e-læring, Høgskolen i Sør-Trøndelag Introduksjon Jarle Larsen 03.01.2007 Lærestoffet er utviklet for faget LO340D Multimediaproduksjon med flash - teoridel 1. Innledning. Målet

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 MASTERPROGRAM I DESIGN 1. Introduksjon til vurderingskriteriene I kunst- og designutdanning kan verken læring eller vurdering settes på formel. Faglige resultater er komplekse

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

Politisk dokument Digitalisering av høyere utdanning

Politisk dokument Digitalisering av høyere utdanning Holbergs gate 1 / 0166 Oslo T: 22 04 49 70 F: 22 04 49 89 E: nso@student.no W: www.student.no Politisk dokument Digitalisering av høyere utdanning «Digitalisering åpner for at kunnskap blir tilgjengelig

Detaljer

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

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

Detaljer

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

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

TESTRAPPORT INTRANETT, CMA ASSET MANAGEMENT AS. Dataingeniørutdanningen, Høgskolen i Oslo GRUPPE 15. Kenneth Ådalen. Vegard Gulbrandsen

TESTRAPPORT 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

Detaljer

Dokument 3 - Prosessdokumentasjon

Dokument 3 - Prosessdokumentasjon Dokument 3 - Prosessdokumentasjon Automatnett - Nytt CMS-verktøy for Uno-X Automat Fakultet for teknologi, kunst og design Høgskolen i Oslo og Akershus, 2013 Dokument 3 - Prosessdokumentasjon Innholdsfortegnelse

Detaljer

BIRD - Administrasjon av forskningsdata (Ref #2219b941)

BIRD - Administrasjon av forskningsdata (Ref #2219b941) BIRD - Administrasjon av forskningsdata (Ref #2219b941) Søknadssum: 1 000 000 Varighet: Toårig Kategori: Innsatsområder Samarbeid og partnerskap Opplysninger om søker Organisasjonsnavn / nr Handelshøyskolen

Detaljer

Oppfølgingsdokument. Kode 009 29. januar 2004 GymPack. D01-2004 Oppfølgingsdokument. Periode 009 Forfatter. Hanne Johnsen

Oppfølgingsdokument. Kode 009 29. januar 2004 GymPack. D01-2004 Oppfølgingsdokument. Periode 009 Forfatter. Hanne Johnsen Periode 009 Forfatter Hanne Johnsen www.multipro-skien.no www.kiprod.com www.prosjekt.kiprod.com 1 av 7 Oppgaver for D01-2004: I denne perioden har vi konstruert infokiosken, detaljert use caser, og begynt

Detaljer

Forprosjektrapport MetaView

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

Detaljer

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

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

Detaljer

Opplæringen har som mål at elevene skal kunne: Temaer / hovedområder:

Opplæringen har som mål at elevene skal kunne: Temaer / hovedområder: Kunst & håndverk 10. kl 2015/2016 3 timer pr. uke Lærebok: Dahl, Johansen og Larsen: Akantus kunst og håndverk for 8. - 10. klasse Faglærer: Katrine E.S. Haraldsen Opplæringen har som mål at elevene skal

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

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12

Granitt Grafisk AS Kravspesifikasjon Gruppenr: 2011-12 1 av 6 1.Innledning 1.1Presentasjon Dato: 01.02.2011 Bacheloroppgave: Produktkalkyle for Granitt Grafisk AS Gruppenr: 11-12 Gruppemedlemmer: Pål Georg Dahl Myran Joakim Haneberg Johansen Michael Venables

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 KUNST 1. Introduksjon til vurderingskriteriene I kunst- og designutdanning kan verken læring eller vurdering settes på formel. Faglige resultater er komplekse

Detaljer

Måling av universell utforming på kommunale nettsider Resultater fra EIII. Daniel Scheidegger NAV Tilde

Måling av universell utforming på kommunale nettsider Resultater fra EIII. Daniel Scheidegger NAV Tilde Måling av universell utforming på kommunale nettsider Resultater fra EIII Daniel Scheidegger NAV Tilde EIII is co-funded under the European Union Seventh Framework Programme (Grant agreement no: 609667).

Detaljer

Beregninger i ingeniørutdanningen

Beregninger i ingeniørutdanningen Beregninger i ingeniørutdanningen John Haugan, Høyskolen i Oslo og Akershus Knut Mørken, Universitetet i Oslo Dette notatet oppsummerer Knuts innlegg om hva vi mener med beregninger og Johns innlegg om

Detaljer

Søknad. Dette skjemaet er til orientering. Søknadsskjemaet blir tilgjengelig i digital form på Norgesuniversitetets hjemmeside i juni.

Søknad. Dette skjemaet er til orientering. Søknadsskjemaet blir tilgjengelig i digital form på Norgesuniversitetets hjemmeside i juni. Søknad Dette skjemaet er til orientering. Søknadsskjemaet blir tilgjengelig i digital form på Norgesuniversitetets hjemmeside i juni. 1. Prosjekttittel Tittelen bør være så kort som mulig, men må samtidig

Detaljer

Mobile apps for Android and ios platforms Forprosjekt

Mobile apps for Android and ios platforms Forprosjekt Mobile apps for Android and ios platforms Forprosjekt Presentasjon : Hovedprosjekt gruppe 17 Høgskolen i Oslo og Akershus Deltakere : Anders Nordli Knudsen Maha Sami Laham Kedar Nassir Shyto Hussain Salbi

Detaljer

Moderne samhandling gir konkurransefortrinn

Moderne 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

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