Brukermedvirkning

1. Brukermedvirkning In 140 Forelesning

2. Historie • Skandinaviske tradisjon • Sosio-teknisk metode • NJMF-prosjektet(1972-73) • Dataavtalen LO-NAF(i dag NHO) • Arbeidsmiljøloven §12 • UTOPIA prosjektet(1981-84) • Aksjonsforskning • I dag: stor enighet i software industrien at brukermedvirkning er viktig

3. Hvorfor brukermedvirkning? • Det er brukernes arbeid som skal støttes vha. IT • Problemdefinering en viktig del av systemutviklingsprosessen • Brukere har ofte motstridende behov • Perfekt teknisk løsning, men for galt problem • Gjensidig læring mellom bruker og utvikler • Brukere må lære om IT • Utviklere må lære om problemområdet • Flere perspektiver • Eierskap til systemet • Prosess like viktig som produktet

4. Betingelser for brukermedvirkning • Relasjonen til brukerorganisasjonen • Leverandør av hyllevare • Konsulent • Intern utvikling • Systemutvikleren er selv ofte brukeren • Grad av usikkerhet • Rutine, problemløsning og problemdefinering

5. Brukermedvirkning kun ved utforming av kravspesifikasjonen er ikke nok • Krav.spek er ofte ikke presis nok • Detaljer krever kommunikasjon med brukerne • Krav endres • Vi gjøre feil • Vi lærer • Andre løsninger er billigere og bedre • Analyse, design og implementering påvirker hverandre

6. Systembeskrivelser med eller for brukere • Systembeskrivelse for brukere degenererer lett til reklame • Systembeskrivelse med brukerne er en gjensidig læringsprosess • Krever en sosio-teknisk tilnærming • Unngå abstrakte diskusjoner • Prototyping • Bedriftsbesøk • Demonstrasjoner • Veggraf

7. Systembeskrivelser med brukere • Gjensidig kunnskapsoppbygging • Tekniske spørsmål ses konsekvent i relasjon til brukernes arbeid og organisasjon • Veksle mellom generelle beskrivelser av arbeid, spesifikke beskrivelser av systemet og relasjonen mellom dem • Skape konkrete forestillinger om systemet og bruken av systemet

8. Eksperimentell systemutvikling • Analyse og design bør utføres i gjensidig samspill • Prototyping • Formålet med prototypen • Hvem evaluerer prototypen? • Systemutvikleren, representanter for brukerne, eller alle brukerne? • Gir brukerne reel mulighet til å påvirke systemet

9. Eksperimentell systemutvikling(2) • Problemer og fallgruber: • Vanskelig å styre prosjektet • Vanskelig å styre forventninger til brukerne • Bruk og kast–prototype blir endelig (del)system • Tidlig prototype kan føre til blindhet i forhold til andre systemer

10. Bruk av ulike perspektiver • Bruk av en metode innebærer et bestemt perspektiv • Konfliktperspektiv eller harmoni • Databaseperspektiv • Kommunikasjonsperspektiv • Verktøyperspektiv • Fugleperspektiv eller personperspektiv

11. Perspektiv • Noe vi anvender når vi forholder oss til et fenomen • Tre vesentlige egenskaper • Ståsted • Seleksjon • Tolkning • De er viktig at vi bruker ulike perspektiver i systemutviklingsprosessen (eks. database og kommunikasjonsperspektiv)

12. Valg av samarbeidsform • Samarbeidsform bør bestemmes ved prosjektetablering (men revurderes ut i fra situasjoner som oppstår) • Rutine-, problemløsning-, eller problemdefineringssituasjon? • Risikovurdering

13. Samarbeidsformer - 1 • Samtaler og intervjuer med brukere • Strukturerte eller ustrukturerte • Brainstorming • Forutsetter at brukerne vet hva de vil • Billig teknikk

14. Samarbeidsformer - 2 • Studere kjent system • I en annen organisasjon eller en annens leverandørs system • Krav utformes ut i fra disse systemene • Forutsetter at krav til funksjonalitet er kjent

15. Samarbeidsformer – 3 • Systematisk analyse av arbeidssituasjon og designforslag • Mulighet for nytenkning • Forutsetter gode abstraksjonsevner til brukerne og gode kommunikasjonsevner hos utviklerne • Kan være kostbar • Bygger på idealet av en rasjonell systemuviklingsprosess

16. Samarbeidsformer – 4 • Eksperimentell systemutvikling/prototyping • Håndterer usikkerhet

17. Teknikk for valg av samarbeidsform • Trinn 1: Definer situasjonen • Trinn 2: Karakteriser situasjonen • Trinn 3: Vurder usikkerhet • Trinn 4: Velg PRIMÆR samarbeidsform • Kvalitativ vurdering, ikke kvantitativ

18. Trinn 1: Definere situasjonen • Hva er problemområdet for prosjektet? • Hvilket system skal utvikles? • Hvem er brukerne av det nye system? • Hvem er systemutviklerne?

19. Trinn 2: Karakterisere situasjonen • Problemområdet: (Svaralternativ: ja,nei kanskje) • Finnes det en brukbar beskrivelse av problemområdet? • Er problemområdet stabilt? • Finnes det fastlagte prosedyrer/rutiner? • Er dataene stabile? • IT-systemet • Anvendes IT-systemet utelukkende på lavere nivå i organisasjonen? • Er systemet enkelt å forstå?

20. Trinn 2 forts. • Brukerne: • Er brukergruppen homogen? • Har brukerne abstraksjonsevne? • Har brukerne erfaring med oppgavene i problemområdet? • Har brukerne erfaring med tilsvarende edb-systemer? • Har brukerne erfaring med systemutvikling? • Systemutviklerene: • Har systemutviklerne kjennskap til oppgavene i problemområdet? • Har systemutviklerne erfaring med utvikling av tilsvarende systemer? • Har systemutviklerne analyse- og designerfaring?

21. Trinn 3: Vurdere usikkerhet • Eksistens og stabilitet av krav til systemet • Evne hos brukerne til at formulere krav • Evne hos systemutviklerne til å frembringe og vurdere krav:

22. Situasjoner: Rutine Problemløsning Problemdefinering Samarbeidsform: Uformell samtaler Analyse av kjent system Systematisk analyse Eksperimentell utvikling Trinn 4: Velg primær samarbeidsform Lav usikkerhet Høy usikkerhet