IN2000/ 12.3.2020 Slide 1

Forskningsmetoder / Evaluering av IT-systemer

Dag Sjøberg og Gunnar Bergersen

IN2002: Software engineering med prosjektarbeid 12. mars 2020

IN2000/ 12.3.2020 Slide 2

Plan

• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år, gruppeoppgave 1

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 3

Forskningsmetode = måten kunnskap dannes på

God metode Pålitelig kunnskap

Dårlig metode Upålitelig kunnskap(mest ekstreme: Fake news)

IN2000/ 12.3.2020 Slide 4

Hvordan velger man metoder, teknikker, praksiser, verktøy, språk for systemutvikling?

• Ofte basert å moter/”hype” og synsing fra “guruer”• Velger ofte det man kjenner best• Ideelt: Basert på empiriske undersøkelser

(empirisk = erfaringsmessig, det som baserer seg på hva som fungerer i praksis)

IN2000/ 12.3.2020 Slide 5

Hvordan finne ut om noe er bedre enn noe annet?

• Undersøk hva som fungerer best i praksis, dvs. gjennomfør en empirisk studie

– Eksperiment– Spørreundersøkelse – case studier, aksjonsforskning, etnografiske studier,

m.fl.

IN2000/ 12.3.2020 Slide 6

Nytteverdi

• Nyttig å kjenne til systematisk evaluering og forskningsmetoder – Forstå og nyttiggjøre forskningsresultater – Stille kritiske spørsmål til påstander– Nyttig både i privat og offentlig sektor– Nyttig i alle fag, ikke bare informatikk

IN2000/ 12.3.2020 Slide 7

Hva betyr det at noe er bedre?

– Hvor mye?– Hvor mange?– Hvor stor?– Hvor gammel?– Hvor lang?– Hvor høy?– Hvor varm?– Hvor tjukk, fast etc.

• Data expresses quantity

IN2000/ 12.3.2020 Slide 8

Kvantitative data

• Data uttrykker kvantitet• Data kan tallfestes• Brukes i statistikk

Kvalitative data

• Data uttrykker kvalitet på en eller annen måte

• Tekst, bilder og andre formater unntatt tall

• Brukes ikke i statistikk

IN2000/ 12.3.2020 Slide 9

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år, gruppeoppgave 1

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 10

Case på IN2000-pilot 2018:Anta at et firma vil utvikle en tjeneste for å finne filmer & serier

• Finnes X versjoner av en prototype på en app med denne tjenesten

IN2000/ 12.3.2020 Slide 11

Hvordan evaluere kvaliteten på app’en?

IN2000/ 12.3.2020 Slide 12

Gruppeoppgave studentene fikk: (dere får en tilsvarende oppgave)

Hvilke kriterier kan man vurdere tjenesten utfra?– Tenk på det dere har lært om kravene til systemet

• Funksjonelle krav• Ikke-funksjonelle krav

– Tenk over kriterier som kan variere mellom ulike interessenter (stakeholders)

IN2000/ 12.3.2020 Slide 13

Aspekter ved evaluering av IT-systemer: ISO 25010

– Functional suitability– Reliability– Usability– Performance efficiency– Maintainability– Portability– Compatibility– Security

Hvike av disse produkt-egenskapene er relevante for dere?

Hvilke prosesskrav gir disse produktkravene opphav til, dvs. hvordan jobber dere for å innfri disse kravene?

IN2000/ 12.3.2020 Slide 14

Funksjonelle krav

Hva systemet skal gjøre

– Hvilke tjenester (funksjoner) skal systemet tilby?– Hvordan skal det reagere på ulike typer input?

IN2000/ 12.3.2020 Slide 15

Ikke-funksjonelle krav

• Hvordan systemet skal implementere de funksjonelle kravene

IN2000/ 12.3.2020 Slide 16

Typer av ikke-funksjonelle krav

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Dependabilityrequirements

Securityrequirements

Regulatoryrequirements

Ethicalrequirements

Legislativerequirements

Operationalrequirements

Developmentrequirements

Environmentalrequirements

Safety/securityrequirements

Accountingrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

Figur fra Ian Sommerville

Spesielt viktige for app’en?

IN2000/ 12.3.2020 Slide 17

”Usability requirements”– er systemet lett å lære og bruke?

• Brukskvalitet/Brukervennlighet – avhenger av krav til opplæring – varierer for ulike brukergrupper– universell utforming

• Kan måles:– Hvor lang tid tar det å lære systemet for nybegynnere?– Hvor mange “brukerfeil” oppstår med erfarne brukere? – Hvor ofte får brukerne meningsløse tilbakemeldinger? – Responstid: Tid fra brukeren trykker ’OK’ til systemet svarer

IN2000/ 12.3.2020 Slide 18

Brukskvalitet (usability)

• Hvordan gjennomføre en studie avbrukskvalitet: https://www.usability.gov/how-to-and-tools/methods/running-usability-tests.html

• Guidelines for Android:https://developer.android.com/guide/practices/ui_guidelines/index.html

IN2000/ 12.3.2020 Slide 19

Resultater av gruppediskusjonene i 2018

IN2000/ 12.3.2020 Slide 20

Gruppe 1

Ikke-funksjonelle krav:• Nedetid på maks 15 minutter, tid mellom hver gang nede?• God arkitektur for videreutvikling• Mulig å drive versjonshåndtering• Høy nok sikkerhet (hva betyr det konkret?)• Lav feilrate (mål på dette?)• Rask responstid (mål på dette?)• Følger designplattformer• Ikke vise offensive bilder (nakenhet/blasfemi osv) (følge rating

filmprodusenter)

IN2000/ 12.3.2020 Slide 21

Gruppe 2• Som bruker ønsker jeg å benytte appen på både mine Android og mine

iOS devices. Jeg ønsker å ha samme opplevelse over alle plattformene.• Som produkteier ønsker jeg at appen skal være enkel og billig å

vedlikeholde i fremtiden (hvordan teste ut det? Hva betyr enkel og billig?)

• Som bruker ønsker jeg at appen skal være lett – altså ta lite blass både i minne og lagring

• Som produkteier ønsker jeg at appen skal se profesjonell ut slik at jeg kan fremme mine interesser (hva betyr profesjonell? Følge standarder som brukes i app’er som brukes i arbeidslivet/profesjonelt – seriøsitet)

• Som produkteier ønsker jeg at appen skal være lett å koble opp mot mine andre produkter (f.eks. felles innlogging, lenker til relaterte tjenester) – kompatibilitet

• Som buker ønsker jeg å kunne benytte meg av tredjeparts verifisering gjennom f.eks google eller facebook.

IN2000/ 12.3.2020 Slide 22

Gruppe 3

Ikke-funksjonelle krav:• Legal: ikke lekke søkehistorikk (konfidensialitet,

personvern)• Performance: 40 requests per 10. sekund • Usability: easy to use. verdiløs dersom bruker ikke klarer å

bruke appen (hvordan teste dette?)• Development requirement: det skal være mulig å oppdatere

og vedlikeholde appen (hva betyr “mulig”?)

IN2000/ 12.3.2020 Slide 23

Gruppe 4• Videreutvikling (relativt enkelt å videreutvikle, kompatibilitet)• Enkel kode som følger godtatte standarder • God versjonskontroll og dokumentasjon• Brukbarhet (usability testing)• Fart på spørringer (ytelse/performance efficieny)• Sikker (hva betyr det i praksis?) Dersom vi har

brukerinformasjon så er dette ekstra viktig• Etiske hensyn, personvern, “Selge informasjon til

tredjepart?”

IN2000/ 12.3.2020 Slide 24

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år, gruppeoppgave 1

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 25

Summegruppeoppgave 1

• Velg ett av casene i prosjektoppgaven1. Bevegelser i havet2. Ras-, flom- og flovarsling3. Luftkvalitet i kommuner4. Prediksjon av klima5. Droner og luftrom6. Åpen case

• Foreslå kriterier for å vurdere kvalitet på app’en(noter forslag til bruk senere)

IN2000/ 12.3.2020 Slide 26

Når kriteriene for evaluering er klare, hvordan gjennomføre evalueringen?

• Hvilke forsknings- eller undersøkelsesmetoder egner seg?

IN2000/ 12.3.2020 Slide 27

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 28

• Et eksperiment undersøker årsak-virkning – hva fører til hva?

• Manipulerer (endrer) det fenomenet man studerer, og så måler man virkningen

• Enkeltindivider eller team (deltakere) utfører like oppgaver der hensikten er å sammenligne ulike “treatments”

(Kontrollert) eksperiment

IN2000/ 12.3.2020 Slide 29

Eksperiment

IT-system/app

Uavhengige variable (treatment)

Avhengige variable (resultat)

Effekt

Moderator variable (kontekst), f.eks. kompetanse

Tid & Kvalitet

IN2000/ 12.3.2020 Slide 30

Hva er kost-nytten ved parprogramming?

*E. Arisholm, H.E. Gallis, T. Dybå and D.I.K. Sjøberg. Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise, IEEE Transactions on Software Engineering 33(2):65-86, 2007

Verdens største eksperiment i software engineering med 300 profesjonelle utviklere som deltakere

Eksperiment omtalt på IN1030:

IN2000/ 12.3.2020 Slide 31

Effekten av å bruke parprogrammering “kommer an på”

Programmerings-ekspertise

Oppgave- kompleksitet

Bruke PP?

Kommentar

Junior Lett Ja Gitt at hovedmålet er god kvalitet

Vanskelig Ja Gitt at hovedmålet er god kvalitet

Mellomnivå Lett Nei

Vanskelig Ja Gitt at hovedmålet er god kvalitet

Senior Lett Nei

Vanskelig Nei*

* Med mindre oppgaven er svært for vanskelig, selv for en senior

IN2000/ 12.3.2020 Slide 32

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 33

Case-studier

• Eksperimenter svarer på “hva” effekten er, case-studier mer på “hvordan” og “hvorfor”

• Case-studier legger vekt på å studere fenomener i sine naturlige omgivelser

• Case-studier har få datapunkter og mange variable. Derfor generaliserer man ved bruk av teori, ikke statistikk som i eksperimenter

IN2000/ 12.3.2020 Slide 34

Intervjuer – ofte brukt i case-studier

� Strukturerte intervjuerØ Spørsmålene definert på forhånd, veldefinerte svaralternativer. Kan

kvantifisere (telle opp) hvor mange som svarer hva på hvert spørsmål

� Semistrukturerte intervjuerØ Intervjuerne baserer seg på stikkord og spørsmål som evt. kan

droppes underveis, og nye spørsmål kan stilles avhengig av hvordan intervjuet forløper

� Åpne (ustrukturerte) intervjuerØ Forløper seg mer som en samtale mellom intervjuer og intervjuobjekt

IN2000/ 12.3.2020 Slide 35

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 36

Etnografi/observasjon

IN2000/ 12.3.2020 Slide 37

• Dyp forståelse av folk, organisasjon og konteksten for arbeidet

• Forskeren observerer over lengre tid hva folk gjør og er mer involvert i gruppen som studeres enn i case-studier

• Personene som studeres trenger ikke å forklare hva de gjør

Metode

IN2000/ 12.3.2020 Slide 38

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 39

Spørreskjemaundersøkelser (Surveys )

IN2000/ 12.3.2020 Slide 40

• Numeriske verdier, for eksempel alder

• Svarkategorier, for eksempel stillingstype

• Ja/Nei-svar

• Ordinalskala (rangering) som vanligvis er bedre for holdninger og preferanser. Tre typer

– Enighetsskalaer, f.eks. 5-nivå Likert-skala med kategoriene: sterkt uenig, uenig, verken uenig eller enig, enig, sterkt enig

– Frekvensskala, for eksempel aldri, sjelden, av og til, ofte, alltid

– Evalueringsskalaer: svært dårlig, dårlig, passe, god, veldig god

• Åpne spørsmål

Spørreskjemaer – type spørsmål

IN2000/ 12.3.2020 Slide 41

Gruppeoppgave 2

Hvilken metoder kan anvendes på hvilke kriterier?

Innspill fra 4 grupper angitt i rødt på de neste slidene.

IN2000/ 12.3.2020 Slide 42

Gruppe 1Ikke-funksjonelle krav:• Nedetid på maks 15 minutter, tid mellom hver gang nede?

– Samle inn data over tid, evt. gjennomføre scenarier ved å pushe ny versjon eller oppdatering og teste om dette kan gjøres innen 15 minutter

• God arkitektur for videreutvikling– Ekstern ekspertvurdering / tredjepart (ulempe å bruke en av

app’utviklerne fordi han/hun kjenner denne)• Mulig å drive versjonshåndtering• Høy nok sikkerhet (hva betyr det konkret?)• Lav feilrate (mål på dette?)• Rask responstid (mål på dette?)• Følger designplattformer• Ikke vise offensive bilder (nakenhet/blasfemi osv) (følge rating

filmprodusenter)

IN2000/ 12.3.2020 Slide 43

Gruppe 2

• Som bruker ønsker jeg å benytte appen på både mine Android og mine iOS devices. Jeg ønsker å ha samme opplevelse over alle plattformene.

– Observasjon/etnografi evt. spørreundersøkelser for å se om app’en tilfredsstiller brukeren

• Som produkteier ønsker jeg at appen skal være enkel og billig å vedlikeholde i fremtiden (hvordan teste ut det? Hva betyr enkel og billig?)

• Som bruker ønsker jeg at appen skal være lett – altså ta lite plass både i minne og lagring

– La folk bruke den og observer, men også intervjue brukerne (semistrukturert, men viktig å være åpen for at folk kan si det de har på hjertet).

• Som produkteier ønsker jeg at appen skal se profesjonell ut slik at jeg kan fremme mine interesser (hva betyr profesjonell? Følge standarder som brukes i app’er som brukes i arbeidslivet/profesjonelt – seriøsitet)

• Som produkteier ønsker jeg at appen skal være lett å koble opp mot mine andre produkter (f.eks. felles innlogging, lenker til relaterte tjenester) – kompatibilitet

• Som buker ønsker jeg å kunne benytte meg av tredjeparts verifisering gjennom f.eksgoogle eller facebook.

IN2000/ 12.3.2020 Slide 44

Gruppe 3Ikke-funksjonelle krav:• Legal: ikke lekke søkehistorikk (konfidensialitet, personvern)

– La uavhengige sikkerhetsselskaper prøve å hente ut info som de ikke skal ha tilgang til

• Performance: 40 requests per 10. sekund – Stresstesting

• Usability: easy to use. verdiløs dersom bruker ikke klarer å bruke appen(hvordan teste dette?)

– Observasjon• Development req: det skal være mulig å oppdatere og vedlikeholde

appen (hva betyr “mulig”?)– Statisk og dynamiske analyseverktøy, spørreundersøkelse blant

utviklere (hva synes de om koden de har jobbet med)

IN2000/ 12.3.2020 Slide 45

Gruppe 4

• Videreutvikling (relativt enkelt å videreutvikle, kompatibilitet)– Eksperiment med et team som skal videreutvikle app’en (test en ny

tjeneste på alle 4 appene)– Evt. ekstern ekspert som ser på koden til alle 4 app’ene

• Enkel kode som følger godtatte standarder • God versjonskontroll og dokumentasjon• Brukbarhet (usability testing)• Responstid på spørringer (ytelse/performance efficieny)

– eksperimenter• Sikker (hva betyr det i praksis?) Dersom vi har brukerinformasjon så er

dette ekstra viktig

IN2000/ 12.3.2020 Slide 46

Plan• Behov for metodekunnskap• Metodekunnskap for utvikling av IT-systemer

– Case fra 2018– Case i år

• Typer forskningsmetoder– Eksperiment– Case-studie– Etnografi– Spørreskjema-undersøkelse (survey)

• Gruppeoppgave 2

IN2000/ 12.3.2020 Slide 47

Summegruppeoppgave

• Foreslå 2-3 kvalitetskriterier dere vil bruke til å evaluere app’en etter tre ukers utvikling?

• Hvilke metoder vil dere anvende?

IN2000/ 12.3.2020 Slide 49

Oppsummering

• Evaluering av et produkt (og prosess) kan gjøres mer eller mindre vitenskapelig

• God forskningsmetode gir pålitelig kunnskap• Bruk av forskningsmetode krever kompetanse og

tilstrekkelig med ressurser