Forskningsmetoder / Evaluering av IT-systemer · • Nedetid på maks 15 minutter, tid mellom hver...
Transcript of Forskningsmetoder / Evaluering av IT-systemer · • Nedetid på maks 15 minutter, tid mellom hver...
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
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
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
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
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
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.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
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
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
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.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
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
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
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
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!