Forskningsmetoder / Evaluering av IT-systemer · • Nedetid på maks 15 minutter, tid mellom hver gang nede? – Samle inn data over tid, evt. gjennomføre scenarier ved å pushe

12/02/19

1

IN2000/ 12.2.2019 Slide 1

Forskningsmetoder / Evaluering av IT-systemer

Dag Sjøberg og Gunnar Bergersen

IN2002: Software Engineering og prosjektarbeid 12. februar 2019

IN2000/ 12.2.2019 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

12/02/19

2

IN2000/ 12.2.2019 Slide 3

Forskningsmetode* = måten kunnskap dannes på

God metode Pålitelig kunnskap

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

*Forskningsmetode er pensum

IN2000/ 12.2.2019 Slide 4

Valg av støtteteknologi (prosessmodeller, metoder, teknikker, praksiser, verktøy, språk)

•  På hvilket grunnlag velger man teknologi som støtter programmering og annen 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)

12/02/19

3

IN2000/ 12.2.2019 Slide 5

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.2.2019 Slide 6





12/02/19

4

IN2000/ 12.2.2019 Slide 7

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.2.2019 Slide 8

Hvordan evaluere kvaliteten på app’en?

12/02/19

5

IN2000/ 12.2.2019 Slide 9

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.2.2019 Slide 10

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?

12/02/19

6

IN2000/ 12.2.2019 Slide 11

Funksjonelle krav

Hva systemet skal gjøre

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

IN2000/ 12.2.2019 Slide 12

Ikke-funksjonelle krav

• Hvordan systemet skal implementere de funksjonelle kravene

12/02/19

7

IN2000/ 12.2.2019 Slide 13

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.2.2019 Slide 14

Brukskvalitet (usability)

•  Hvordan gjennomføre en studie avbrukskvalitethttps://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

12/02/19

8

IN2000/ 12.2.2019 Slide 15

Resultater av gruppediskusjonene

IN2000/ 12.2.2019 Slide 16

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)

12/02/19

9

IN2000/ 12.2.2019 Slide 17

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.2.2019 Slide 18

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”?)

12/02/19

10

IN2000/ 12.2.2019 Slide 19

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.2.2019 Slide 20





12/02/19

11

IN2000/ 12.2.2019 Slide 21

Summegruppeoppgave 1

•  Velg ett av de 5 casene i prosjektoppgaven –  Case 1 – Været til sjøs –  Case 2 – Lynvarsling –  Case 3 – Planlegging av flytur –  Case 4 – Luftkvalitet i storbyene –  Case 5 – Norsk klima i endring

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

IN2000/ 12.2.2019 Slide 22

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

•  Hvilke (forsknings/undersøkelses)metoder egner seg?

12/02/19

12

IN2000/ 12.2.2019 Slide 23


–  Case fra 2018 –  Case i år



IN2000/ 12.2.2019 Slide 24

•  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

12/02/19

13

IN2000/ 12.2.2019 Slide 25

Eksperiment

IT-system/app

Uavhengige variable (treatment)

Avhengige variable (resultat)

Effekt

Moderator variable (kontekst), f.eks. kompetanse

Tid & Kvalitet

IN2000/ 12.2.2019 Slide 26

Hva er kost-nytten ved parprogramming? •  Sommerville skriver i boka s. 70:

–  “However, studies with more experienced programmers (Arisholm et al., 2007*; Parish et al., 2004) did not replicate these results. They found that there was a significant loss of productivity compared with two programmers working alone.”

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

12/02/19

14

IN2000/ 12.2.2019 Slide 27

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.2.2019 Slide 28





12/02/19

15

IN2000/ 12.2.2019 Slide 29

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.2.2019 Slide 30

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

12/02/19

16

IN2000/ 12.2.2019 Slide 31





IN2000/ 12.2.2019 Slide 32

Etnografi/observasjon

12/02/19

17

IN2000/ 12.2.2019 Slide 33

•  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.2.2019 Slide 34





12/02/19

18

IN2000/ 12.2.2019 Slide 35

Spørreskjemaundersøkelser (Surveys )

IN2000/ 12.2.2019 Slide 36

•  Numeriske verdier, for eksempel alder

•  Svarkategorier, for eksempel stillingstype

•  Ja/Nei-svar

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

12/02/19

19

IN2000/ 12.2.2019 Slide 37

Gruppeoppgave 2

Hvilken metoder kan anvendes på hvilke kriterier? Innspill fra gruppene angitt i rødt på de neste slidene.

IN2000/ 12.2.2019 Slide 38

Gruppe 1 Ikke funksjonelle: •  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)

12/02/19

20

IN2000/ 12.2.2019 Slide 39

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.eks google eller facebook.

IN2000/ 12.2.2019 Slide 40

Gruppe 3 Ikke-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)

12/02/19

21

IN2000/ 12.2.2019 Slide 41

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.2.2019 Slide 42





12/02/19

22

IN2000/ 12.2.2019 Slide 43

Summegruppeoppgave

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

•  Hvilke metoder vil dere anvende?

IN2000/ 12.2.2019 Slide 44

Prosessen påvirker resultatet •  Systemutviklingsprosessen vil påvirke kvaliteten både på prosjektet selv

og systemet som utvikles •  Måten man jobber på påvirker også arbeidsmiljøet (trivsel, motivasjon,

kompetanseutvikling etc.) som igjen påvirker prosjekt- og produktkvalitet •  Din kompetanse og måten du og ditt team jobber på avgjør hvordan

prosjektet og sluttproduktet blir!

12/02/19

23

IN2000/ 12.2.2019 Slide 45

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

Documents

Forskningsmetoder / Evaluering av IT-systemer · • Nedetid på maks 15 minutter, tid mellom hver gang nede? – Samle inn data over tid, evt. gjennomføre scenarier ved å pushe