inf 1510: evaluering

Transkript

1 inf 1510: evaluering mål: oversikt over ulike metoder for evaluering bakgrunn for å planlegge og gjennomføre evaluering i prosjektet dagsorden: evaluering; hva er det og hvorfor gjør vi det kort påminnelse om DECIDE-rammeverket midtveis-evaluering evaluering av gruppearbeidet (bakgrunn for Oblig 3)

2 hvorfor evaluering? vi lager ting for andre brukskunst? hva er det vi vil vite underveis i design-prosessen? klarer brukerne bruke produktet? Vil de bruke det? Vil de kjøpe det? hva kan vi teste underveis, og når? (ideer, modeller, prototyper mm) hvor og hvordan skal vi teste? (lab eller naturlige omgivelser) Preece et al kap. 12, 13, 14 og 15

3 ideer visjon skisser prototyper spesifikasjon FORSTÅ PRAKSIS IDENTIFISER BEHOV & KRAV hvor i tingenes livsløp? ønske behov produkt lage vane, mestre, forbedre forstå lære, 5lpasse TEST & EVALUER MATERIALISER KONKRETISER kast oppdrag bygge & teste design salg kjøp vedlikehold søppel modernisere reparere bruk oppdatere, pusse opp, bygge om

4 ideer visjon skisser prototyper spesifikasjon FORSTÅ PRAKSIS IDENTIFISER BEHOV & KRAV hvor i tingenes livsløp? ønske behov produkt lage vane, mestre, forbedre forstå lære, 5lpasse oppdrag TEST & EVALUER MATERIALISER KONKRETISER bygge & teste salg kast kjøp vedlikehold søppel modernisere reparere evaluering er innbakt i design oppdatere, pusse opp, bygge om evaluering er integrert med design & analyse (iterativ utvikling) Boehm 1988

5 hva er evaluering? é-valuer: se verdien av teste, prøve, sjekke, verifisere, validere sjekke: at artifaktet virker + blir forstått at artifaktet 1) gjør de riktige tingene og 2) gjør dem riktig validere og verifisere de riktige tingene, det vi ønsket NB systematisk! riktig resultat, dvs. funksjonalitet ift kravspesifikasjon

6 tingenes livsløp ideer FORSTÅ PRAKSIS IDENTIFISER BEHOV & KRAV ønske behov produkt lage vane, mestre, forbedre forstå lære, 5lpasse TEST & EVALUER MATERIALISER KONKRETISER kast oppdrag bygge & teste design salg kjøp vedlikehold søppel modernisere reparere bruk oppdatere, pusse opp, bygge om

7 WHAT MAKES What Makes Things Cool? Intentional Design for Innovation THINGS COOL? INTENTIONAL DESIGN FOR INNOVATION Cover Story by Karen Holtzblatt Association for Computing Machinery When Apple released the iphone in 2007, it was a game-changing product in ways we had not seen for many years. Consumers were talking about it everywhere. They gathered around the phone to watch the pinch and the swivel; they were awed by the pictures, apps, and games. The technology industry reacted as well. Companies expressed their frustration at not being able to create a game-changer too. Everyone wanted to re-create the iphone s impact in their own products. Game-changing products and applications are part of the natural ebb and flow of product design. But something different seemed to be happening with the release of the iphone: something all-consuming, something related to the overall user experience, something more than previous technology innovations. But what is that something? What does it mean to design for a transformative experience? What makes things cool? What drives the cool user experience? [1] To guide design teams, and to understand what makes things cool, we launched the Cool Project. Here we introduce the results of the Cool Project and the key constructs we uncovered as core to the user experience of cool. What is going on with people using cool things? What impacts the experience of cool? How does the cool experience change across the lifecycle as we age? We wanted to identify principles to guide companies in designing cool into their offerings. We [2] began by going out into the field to understand people s experience with their cool products. We conducted field interviews with nearly 70 individuals between the ages of 15 and 60 across multiple locations in the U.S. Using Contextual Design [3], our well-known user-centered design technique, we gathered and organized the data, producing affinity diagrams, personas of people and devices, and activity boards summarizing findings in key activity areas such as health and family. Then we conducted an online survey with more than 800 people in multiple cities across the U.S. The analysis of all this data revealed the themes of the cool experience and implications for product design. We organized these themes into the Cool Concepts: the Wheel of Joy and the Triangle of Design. We introduce them below. The absolute center of cool is joy. Joy is our autonomic response to our encounter with the world. Joy is pulled unknowingly and unwillingly from within. It is the most basic of human emotions [4]. Throughout our research we encountered joy over and over, hidden beneath the experience of cool. The experience of cool is compelling because it is tightly connected to the experience of joy and delight. But how can something as simple and limited as a technical gadget or a piece of software create an experience as profound as joy? Consider the following reactions: Look at this, Mom. It s a flashcard app to study for the SATs they even flip. It makes the work like play! My old high school friend just contacted me I haven t talked to her in years. Facebook is soooo cool. I love it! Come see my HDTV. Can you believe the picture? Do you see the green? It s better than real grass on the ball field! This is the coolest! Joy doesn t come from one specific feature. It doesn t come from using trendy colors, or adding people that move or jumping graphics. It doesn t result from using a touchscreen or fewer clicks to complete a task. Rather, joy in life happens when products help us fulfill our most core human motivations: Accomplishment, Connection, Identity, and Sensation.

8 hva er evaluering? é-valuer: se verdien av teste, prøve, sjekke, verifisere, validere sjekke: at artifaktet virker + blir forstått at artifaktet 1) gjør de riktige tingene og 2) gjør dem riktig validere og verifisere de riktige tingene, det vi ønsket NB systematisk! riktig resultat, dvs. funksjonalitet ift kravspesifikasjon

9 hva er evaluering? teste hva i forhold til hva, for hvem hva er det som evalueres? i forhold til hva/hvem: kriterier og mål av hvem: hvem utfører evaluering og hvordan for hvem: hva brukes evalueringen til

10 hva testes = kriterier og mål for evalueringen at artifaktet virker + blir forstått funksjonalitet (behov) kommunikasjon av funksjonalitet evalueringskriterier de riktige tingene validere og verifisere at artifaktet 1) gjør de riktige tingene og 2) gjør dem riktig avhengig av hvem som evaluerer og hva som evalueres at tingene gjøres riktig

11 hvem og hvordan omfang den som har laget artifaktet? den som har bestilt artifaktet? den som skal bruke artifaktet? eksterne? eksperter? evalueringskriterier kostnad (ressurser) tid mål: hva er godt nok? Hvem bestemmer det?

12 hvordan = metoder analytisk evaluering heuristisk evaluering summativ evaluering formativ evaluering predikerende evaluering kombinasjoner av disse bruker-testing brukbarhets-testing brukbarhets-studier bruker-studier feltstudium brukbarhets-lab kontrollert eksperiment

13 hvordan = tilnærminger 3 hovedtyper: i lab, i felten, på kontoret gir forskjellig informasjon, foregår på forskjellig tidspunkt i designprosessen i lab: brukbarhetstesting observere og måle funksjonalitet og kommunikasjon av funksjonalitet i felten: feltstudier observere og intervjue i bruk / med brukere på kontoret: analytisk inspeksjoner, reviews heuristisk evaluering (f.eks. Nielsens oppsummering av 249 brukbarhetsproblemer)

14 tilnærminger 3 hovedtyper: i lab, i felten, på kontoret gir forskjellig informasjon og foregår på forskjellig tidspunkt i design brukbarhetstesting feltstudier analytisk brukere gjør oppgaver naturlig praksis ikke involvert sted kontrollert omgivelse (lab) naturlig hvor som helst når prototype tidlig prototype data kvantitative kvalitative problemer feedback målinger og feil beskrivelser problemer type bruk / anvendelse naturlig praksis ekspert (fra Preece et al)

15 10 Heuristics for User Interface Design useit.com of Heuristics 5/13/11 3:29 PM Papers and Essays Heuristic Evaluation AskTog: First Principles of Interaction Design List nn/g useit.com jnd.org Search Ten Usability Heuristics by Jakob Nielsen These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines. Visibility of system status The system should always keep users informed about what is going on, through appropriate feedback within reasonable time. Match between system and the real world The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow realworld conventions, making information appear in a natural and logical order. User control and freedom Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. Consistency and standards Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. Error prevention Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action. Recognition rather than recall Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate. Flexibility and efficiency of use Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. Aesthetic and minimalist design Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility. Help users recognize, diagnose, and recover from errors Error messages should be expressed in plain language (no codes), precisely Interaction Design Solutions for the Real World Interaction Design Section Living Section 10 Heuristics for User Interface Design Jump to: Anticipation Autonomy Color Blindness Consistency Defaults Efficiency of the User Explorable Interfaces Fitts' Law Human-Interface Objects Latency Reduction Learnability Limit Tradeoffs Metaphors Protect the User's Work Readability Track State Visible Interfaces Updated Findings Translate Search WWW asktog.com AskTog Basics Search Principles The following principles are fundamental to the design and implementation of effective interfaces, whether for traditional GUI environments or the web. Of late, many web applications have reflected a lack of understanding of many of these principles of interaction design, to their great detriment. Because an application or service appears on the web, the principles do not change. If anything, applying these principles become even more important. Belorussian Version: Deutsche (German) Version: Italian Version: Nederlands (Dutch) Version: Polish Version: Portuguese Version: Spanish Version: Effective interfaces are visually apparent and forgiving, instilling in their users a sense of control. Users quickly see the breadth of their options, grasp how to achieve their goals, and do their work. Effective interfaces do not concern the user with the inner workings of the system. Work is carefully and continuously saved, with full option for the user to undo any activity at any time. Effective applications and services perform a maximum of work, while requiring a minimum of information from users. This work is copyright 2003 by Bruce Tognazzini. Permission to make copies for personal use is granted without reservation, provided this copyright notice remains on the copy. Please contact the author for permission to republish on a web site, to publish in bound form, or to make multiple copies, except that educators and in-house corporate 5/13/11 3:29 PM I originally developed the heuristics for heuristic evaluation in collaboration with Rolf Molich in 1990 [Molich and Nielsen 1990; Nielsen and Molich 1990]. I since refined the heuristics based on a factor analysis of 249 usability problems [Nielsen 1994a] to derive a set of heuristics with maximum explanatory power, resulting in this revised set of heuristics [Nielsen 1994b]. Select Language Powered by NN/g Home Page 1 of 2 indicate the problem, and constructively suggest a solution. Help and documentation Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large. About Bruce Tognazzini Google Search First Principles of Interaction Design 5/13/11 3:36 PM Page 1 of 11

16 Shneiderman's Eight Golden Rules of Interface Design 5/15/11 2:33 PM Shneiderman's "Eight Golden Rules of Interface Design" These rules were obtained from the text Designing the User Interface by Ben Shneiderman. Shneiderman proposed this collection of principles that are derived heuristically from experience and applicable in most interactive systems after being properly refined, extended, and interpreted [9]. To improve the usability of an application it is important to have a well designed interface. Shneiderman's "Eight Golden Rules of Interface Design" are a guide to good interaction design. 1 Strive for consistency. Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout. 2 Enable frequent users to use shortcuts. As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user. 3 Offer informative feedback. For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial. 4 Design dialog to yield closure. Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions. 5 Offer simple error handling. As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error. 6 Permit easy reversal of actions. This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions. 7 Support internal locus of control. Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders. 8 Reduce short-term memory load. The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions. From Page 1 of 1

17 i lab

18 i felten

19 i felten

20 DECIDE-rammeverket Determine goals Explore the questions Choose the evaluation approach and methods Identify the practical issues Decide how to deal with ethical issues Evaluate, analyze, interpret and present the data fra Preece et al kap. 13

21 DECIDE-rammeverket Determine goals Explore the questions målene for evalueringen Choose the evaluation approach visjon, and methods grensesnitt, brukbarhet, effekt, robusthet, pålitelighet... Identify the practical issues hvem skal bruke evalueringen, til hva? Decide how to deal with ethical issues hvilken metode passer? Evaluate, analyze, interpret and present the data fra Preece et al kap. 13

22 DECIDE-rammeverket Determine goals finn gode spørsmål Explore the questions hvordan kan dette måles? Choose the evaluation approach and methods hva er indikatorer på dette? Identify the practical issues som man spør, får man svar Decide how to deal with ethical issues Evaluate, analyze, interpret and present the data fra Preece et al kap. 13

23 DECIDE-rammeverket Determine goals Explore the questions Choose the evaluation approach and methods Identify the practical issues tilnærmingen bestemmer metode Decide how to deal with ethical issues feltstudium, brukbarhetstesting Evaluate, analyze, interpret and present the data metode bestemmer hvilke data som samles inn & hvordan de analyseres

24 DECIDE-rammeverket Determine goals Explore the questions velge og finne brukere Choose the evaluation approach and methods tid og ressurser til rådighet Identify the practical issues velge og finne evaluatorer Decide how to deal with ethical issues utstyr til evalueringen Evaluate, analyze, interpret and present the data

25 DECIDE-rammeverket deltakerne må få informasjon om studien og om hvordan dataene behandles Determine goals og om personvern Explore the questions og kan avbryte om og når de ønsker Choose the evaluation approach and methods Identify the practical issues samtykke-erklæring Decide how to deal with ethical issues Evaluate, analyze, interpret and present the data

26 DECIDE-rammeverket avhenger av tilnærming og metode husk: reliabilitet / pålitelighet (data repliseres) eller troverdighet Determine validitet goals eller bekreftbarhet (av analyse, tolkning) Explore the bias questions eller systematisk skjevhet Choose the område: evaluation generalisering approach and eller methods overførbarhet Identify the effekter practical og issues konsekvenser, inkludert bærekraft Decide how to deal with ethical issues Evaluate, analyze, interpret and present the data

27 hvorfor evaluere? vi lager ting for andre brukskunst hva er det vi vil vite underveis i designprosessen? klarer brukerne bruke produktet? Vil de bruke det? Vil de kjøpe det? hva og når kan vi teste underveis? (ideer, modeller, prototyper mm) hvor og hvordan skal vi teste? eller naturlige omgivelser) Preece et al kap. 12, 13, 14 og 15 (lab hva evalueres? i forhold til hva/hvem: kriterier og mål av hvem: hvem utfører evaluering og hvordan for hvem: hva brukes evalueringen til

28 midtveisevaluering prosjektperiode!! hva fungerer bra og ikke? uke 3-16/1! uke 4-22/1! uke 5-30/1! uke 6-6/2! uke 7-13/2! uke 8-20/2! uke 9-27/2! uke 10-5/3! uke 11-12/3! uke 12-19/3! uke 13-26/3! uke 14-2/4! uke 15-9/4! uke 16-16/4! uke 17-23/4! uke 18-30/4! uke 19-7/5! uke 20-14/5! uke 21-21/5! #$'%../%%.012% (mer og mindre av) hvordan jobber dere med emnet (sml andre emner) Tone Bratteteig 16/1 2012! forelesninger! øvingsgruppe & prosjekt! oppgaver! intro bruksorientert design! intro Arduino! mer Arduino! ideer for Arduino! mer bruksorientert! design + prosjektarbeid! bli kjent med Arduino! inf1010-oblig 1 10/2! obl.oppg. 1! 21-24/2! metoder for å forstå bruk! design metoder for å identifisere behov og krav! metoder for å lage ideer og visjoner! metoder for å lage skisser og prototyper! undersøke brukskontekst! inf1050-oblig 1 2/3! obl.oppg. 2! 12/3! inf1010-oblig 2 16/3! metoder for evaluere effekt + gruppearbeid! øving:! gruppearbeid! design! med brukere! intro sosiologi! +,34525/6!*+-%.%7%4819% 16/4! obl.oppg. 3! intro medievitenskap! inf1010-oblig 3 20/4! intro jus! intro psykologi! intro pedagogikk! oppsummering og tips!!"#$%&%'()*#'"+,-% analysere brukskontekst! inf1050-oblig 3 4/5! obl.oppg. 4! 14/5! inf1010-oblig 4 16/5! eksamensinnlevering! grupperap, video, web! individuell rapp.! 30/5! 1/6! inf1050 eksamen 5/6! inf1010 eksamen 12/6!

29 evaluering av gruppearbeidet (bakgrunn for obligatorisk oppgave nr 3) leveranser i hht plan? oppdeling og koordinering av arbeidet roller og oppgaver arbeidsoppgaver og ansvar oppleves arbeidsoppgavene jevnt fordelt? Har alle lært noe nytt? kjøreregler (være sen, ikke komme, ikke levere, når er det et problem, sanksjoner) fakta (# timer, # møter, # bidrag)

30 til eksamen evaluering av prosjekt (& arbeid) mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport INF1510: evalueringskriterier!"#$%$&'()*+"',&$,' Nedenfor er en kort beskrivelse av hvilke kriterier som brukes for å sette karakterer i INF1510. Sluttrapporten, som er en gruppeoppgave er det som gir karakteren til alle i prosjektgruppa. Men gruppa må bestå innlevering nr. 2: en videoen som presenterer design-resultatet: her kan hele gruppa stryke. I tillegg må alle medlemmene i gruppa bestå innlevering nr. 3: en individuell rapport om arbeidet og læringsresultatet i emnet. Det betyr at enkelt-individer i gruppa kan stryke om de ikke får bestått på sin individuelle rapport. Dersom alle i gruppa består alle tre oppgavene, får alle i gruppa samme karakter: den som ble gitt på rapporten. Tommelfingerregelen er at C er en grei gjennomføring av det som må gjøres i emnet, uten noe særlig ekstra innsats utover de forventede 10 studiepoengene (= 40 timer / 3 emner = 13,3 timer/uke i litt over 13 uker, dvs. ca et fullt månedsverk pr. person i gruppa). I en gruppe som får C har studentene lært det viktigste godt nok. A gis når studentene gjør en større innsats og oppnår resultater som er mye bedre enn forventet. B gis når studentene har gjort en stor innsats (i overkant av forventet) og resultatet blir godt, men ikke eksepsjonelt. En gjennomføring av emnet som ikke møter kriteriene for C vil gi prosjektgruppen karakteren D, E eller F, avhengig av hvor store avvikene er. F gis når vi ikke ser noen synlige spor av at de har fulgt emnet i de besvarelsene studentenes har levert. E viser slike spor, men er minimumskravet for å bestå emnet. Her er det viktige ting som studentene ikke har lært eller har misforstått. D brukes når studentene har lagt liten innsats i emnet og kommet kortere enn forventet, og gjort så lite at resultatet blir dårligere enn forventet. Krav til prosjektarbeidet kar mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyp) testing & evaluering helhet A Tema /område er klart def., presisert til spørsmål med målgruppe og eval.krit. Dataene er analysert på en solid måte og det er identifisert behov og ønsker som begrunnes i brukssituasjonen. Funn begrunnes og det argumenteres solid for funn. Gruppa har utnyttet egen kunnskap og interesser Gruppa har gjennomført godt undersøkelser og brukt flere metoder. Metodevalget er godt begrunnet. Metodene er godt beskrevet (både gjennomføring og innsamlede data) og dataene er grundig presentert. Gruppa har observert / intervjuet flere brukere enn nødvendig. Gruppa har etablert samarbeid med en brukergruppe. Gruppa bruker flere begreper fra (flere av) gjesteforelesningene (HumSam), og det er argumentert for at og hvordan begrepene har bidratt til å forstå og forklare analysen av dataene. Ekstra litteratur er trukket inn. Flere ideer er jobbet fram, og finnes i flere skisser. Sluttproduktet representerer en visjon som gruppa kan argumen-tere for basert på innsikt både fra bruk og teknologi. Løsningen er ny i brukssituasjonen og utnytter teknologiens muligheter. Den kommuniserer visjonen gjennom materialer, funksjon og form. Skisser og prototyper demonstrerer hvordan visjonen har utviklet seg iterativt og gjennom brukerdialog og brukertesting. Prototypevalg er godt begrunnet. Minst to forskjellige visjoner har vært vurdert og testet. Løsningsforslag er testet (at det virker) og evaluert. Brukere har vært involvert i flere evalueringer og gruppa har gjennomført flere iterasjoner med (re)design, bruker-dialog og -testing. DECIDE-rammeverket er brukt som mal for evalueringen, og egne evalueringskriterier er diskutert opp mot DECIDE. Minst to forskjellige visjoner har vært vurdert og testet. Gruppa har forkastet egne ideer etter brukerevaluering. Nyskapende prosjekt der gruppa har tenkt ut av boksen. Gruppa har samarbeidet godt og alle har lært om alle sidene i prosjektet.

31 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - egen kompetanse ses som ressurser - klart definert tema - målgruppe definert - evalueringskriterier presisert

32 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - flere metoder for undersøkelser av bruk - godt utvalg og argumentasjon for metodene - god gjennomføring av undersøkelsene - god dokumentasjon av undersøkelsene - god dokumentasjon av data - gode begrunnelser for avslutning av datainnsamling

33 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - solid analyse av data - analysen konkluderer med behov (som lar seg underbygge av dataene) - solide begrunnelser av funn og konklusjoner - bruk av flere begreper og referanser fra gjesteforelesninger og annet fagstoff - demonstrerer at begrepene gir bedre forståelse

34 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - flere ideer er jobbet fram, dokumentert i skisser - flere av mellomproduktene er dokumentert - prototypevalg er godt begrunnet - sluttproduktet representerer en visjon som er forankret i gruppas undersøkelser (bruk) og som utnytter Arduino på en god måte - minst 2 visjoner er beholdt lenge i prosessen - brukerne har deltatt i designprosessen - materialer og form kommuniserer visjonen - feedback til brukerne er gjennomtenkt & -prøvd

35 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - løsningsforslaget er testet godt (både verifisering og validering) - DECIDE-rammeverket brukt (eller gode argumenter for å gjøre noe annet) - flere iterasjoner med design & test har vært gjennomført - brukere har vært involvert i testingen - 2 visjoner har vært evaluert, en forkastet - gruppa har forkastet egne ideer etter bruker-testing

36 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - nyskapende prosjekt (tenkt ut av boksen ) - godt samarbeid - gruppa har modnet - prosjektet framstår som en logisk helhet - alle har lært noe om alt (alle har bidratt)

37 INF1510: Obligatorisk oppgave 3: evaluering av gruppearbeidet Denne oppgaven gjøres i Øvingsgruppene i uke 15: april). Prosjektarbeidet i inf1510 er godt i gang, og dere er omtrent halvveis i prosjektet. Det er ca. syv uker igjen til prosjektet skal avsluttes og dere skal levere eksamensoppgavene. Denne obligatoriske oppgaven skal være en vurdering av om gruppa jobber bra sammen slik at dere unngår å bruke mye tid og krefter på å få samarbeidet til å fungere videre i prosjektarbeidet. En viktig grunn til å diskutere gruppearbeidet nå er at det fremdeles er tid til å gjøre noe med det i grupper som ikke fungerer optimalt, slik at organiseringen av arbeidet og arbeidsformene i den siste delen av prosjektet blir effektive. Hvis arbeidsfordelingen er skjev kan den endres, hvis rollene ikke fungerer kan de omfordeles. Denne øvelsen skal bidra til dette. Hvis noen i gruppa bidrar uforholdsmessig lite i forhold til de andre, kan gruppa stille krav til personen om å yte mer samt planlegge og sette en frist for leveranser. Studenter som ikke bidrar nok til gruppas arbeid kan bli bedt om å trekke seg fra gruppa, men dette kan og bør ikke skje uten at dere har tatt en grundig diskusjon med personen om avtaler og forventninger, i tillegg til at personen må få en sjanse til å forbedre seg. Trekk inn gruppelæreren i diskusjonen hvis deres gruppe er i en slik situasjon. Oppgave: Ta fram igjen oppstart-øvelsen fra uke 9 og 10, og se på Oblig 2, der dere skrev ned dere ble enige om. Da skulle dere bli kjent med hverandre og diskuterte bl.a. ambisjoner, interesserer, tidsbruk mm. Dere ble enige om følgende: møtetidspunkt i tillegg til de oppsatte timene i kurset (Øvingsgruppetimene) roller i prosjektet, faste eller på omgang arbeidsoppgaver og -ansvar: hvem skal gjøre hva til neste gang (se beslutningsreferat) arbeidsområde eller deling av dokumenter kjøreregler for prosjektgruppa o man sier fra om man blir sen til et møte (hvor mye før?) o hva skjer om man ikke kommer på et møte? o hva skjer om man ikke har gjort det man skal? (hva ble dere enige om da?) o når blir slike ting et problem? o kan man kaste ut en som ikke gjør nok? 1) Individuell oppgave (15 minutter): Gå gjennom oppstart-øvelsen (dvs spørsmålene over) og gjør dine egne vurderinger. Tenk også over: Fungerer gruppa bra? Fungerer den slik dere bestemte at dere skulle jobbe? Hvis ikke: hvorfor ikke? Hva kan forbedres? Og hvordan (kom med forslag du tror vil bedre situasjonen)?

38 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - god framstilling: klar, logisk struktur & godt språk - alle punktene ovenfor er - godt dokumentert - godt argumentert for - gruppa viser selvstendig vurdering av eget arbeid (kritisk: både + og -) - relevante faglige referanser

39 til eksamen evaluering av prosjekt mål undersøkelse (metoder) analyse (behov, teori) design (ideer, prototyper) testing & evaluering helhet innlev. 1: sluttrapport innlev. 2: video innlev. 3: individuell rapport - demonstrerer at og hvordan løsningsforslaget virker - presenterer visjonen - presenterer funksjon, form og materialer - en god fortelling - utnytter Arduino godt - en god pitch der alle i gruppa er med

40 til eksamen evaluering av prosjekt!"#$%$&'()*+"',&$,' Innlevering nr. 3 skal dokumentere og presentere at hvert enkelt gruppemedlem har lært det hun/han skal og har bidratt i prosjektet. Bestått NB tilsv. C Ikke bestått Alle skal fortelle hva de har bidratt med i prosjektet og hva de har lært av dette. Prosjektaktivitet Har bidrag Hva er ditt bidrag Hva har du lært Mål - spørsmål Undersøkelse Analyse Design - Ideer - Skisser - Prototyper (prog) Test - evaluering Framdrift i prosjektet Rapportskriving (felles) Gruppearbeidet NB Alle elementene må fylles ut. innlev. 3: individuell rapport - arbeidet: vurder oppdeling, fordeling, roller tiltak? - resultatet: vurder gruppas og ditt bidrag, argumenter - hva lærte du i prosjektet? Hva tar du med til neste gang? I tillegg skal studentene skrive en kort rapport som inneholder: 1) hva likte du best i prosjektet (hvilke aktiviteter, hva gjorde du og hva var det du likte med det?) 2) hva var problematisk i prosjektet, hvorfor og hvordan. Hvordan ble problemene løst? 3) hva lærte du mest av i prosjektet? Hva lærte du minst av? Hva er læringsutbyttet av prosjektet som helhet? 4) hvordan vurderer du prosjektet og din egen innsats? En av radene er ikke fylt ut, dvs at denne studenten ikke har bidratt til prosjektet på dette området. Det kan bety at gruppa har fordelt arbeidet skjevt eller at vedkommende ikke har deltatt like mye som de andre. Uansett grunn vil dette kvalifisere til ikke bestått. Intet eller lite læringsutbytte av emnet, dvs at rapporten viser at studentens læringsutbytte av emnet tilsvarer en D eller E (se under prosjekt / prosjektrapport).

41 inf 1510: evaluering hva er evaluering? begreper og tilnærminger metoder og modeller underveis i undersøkelses- og analyse-aktiviteter underveis i design som egen aktivitet evaluering av læringsresultater