Repetisjon om evaluering av It-systemer Hvordan vurdere og verdsette?
Evaluere - Bokmålsordboka Evaluere Vurdere, verdsette, gi karakter for. Vurdere Bedømme, verdsette. Bedømme Dømme om Verdsette Vurdere, taksere, sette pris på Foreta en vurdering av systemet og nytten det har for brukerne. En systematisk innsamling av data som gir informasjon om nytteverdien systemet har for en spesiell bruker eller brukergrupper for å løse en arbeidsoppgave i en gitt situasjon.
Hvorfor evaluere? Foreta beslutning om kjøp eller integrasjon av programvare Overtar ansvar for utvikling, markedsføring og vedlikehold et produkt Utarbeide spesifikke krav i en utviklingskontrakt Foreta beslutning om ytterligere investeringer i programvare Programvaren holder ikke lenger definerte kvalitetsmål For å sikre produktkvalitet, kontrollere kostnader For å minimalisere forretningsrisiko Andre grunner
Utsagn mot å evaluere før kjøp Vi kjøper et system eller en løsning vi kjenner fra før Evaluering koster tid og penger la oss ta en leverandør vi allerede kjenner godt Vi vet hva vi vil ha, eller har behov for det er unødvendig å kjøre en omfattende prosess. Ofte avdekker prosessen at: leverandører og løsninger endres oppfatninger av hva vi egentlig trenger endres
Grunner for å evaluere før kjøp Sikre en løsning som tilfredstiller virksomhetens krav og behov Sikre at løsningen Stemmer med virksomhetens IT-strategi Stemmer med virksomhetens system arkitektur Kan fungere sammen med resten av bedriftens systemer Sikre fri konkurranse mellom forskjellige leverandører(spesielt i offentlig sektor) Sikre kvalitet både av løsning og hos leverandør Sikre best mulig pris for systemet
Evalueringstabell Lage en liste med kriterier Velg kriteriene på grunnlag av bruk og produkt Prioriter mellom kriteriene Verdsett vekt hvert kriterium Estimer en verdi for hvert kriterium Velge produktet med størst poengsum? Listen blir ofte subjektiv Kriterium Produkt 1 Produkt 2 Produkt 3 Produkt 4 Brukergrensesnitt 5 3 3 4 Troverdig leverandør 2 4 4 1 Pris 5 4 2 2 Går også på UNIX 0 5 5 0
En generell metode Forberede evalueringen Starte arbeidet, planlegging og kontroll Analyse og utarbeide krav, kriterier Gjennomføre evalueringen Avslutte evalueringen Rapportere resultatene Vurdere, avklare, beslutte og presentere Kompetanseoverføring Avslutte arbeidet
Evaluering av brukergrensesnitt Brukergrensesnittet gjør det mulig å kommunisere med datamaskinen Bestemmer hva brukeren skal se og gjøre Reflektere hvem som gjør hva Både maskin og bruker påvirker hverandre Optimalisere brukerens mulighet for kontroll Programmet skal nå sitt mål som er å påvirke brukeren
Et godt grensesnitt gjør at Feil ikke oppstår og feilfrekvens reduseres Opplæringen kan forenkles Produktivitet og effektivitet øker Brukerne blir fornøyde Systemet kan bli lettere å selge
Fem grunner til at systemer kan være vanskelige å bruke Systemet er tilpasset maskinen og arbeidsoppgaven - ikke brukeren Brukernes arbeidsoppgaver endres, mens organisasjonene ikke endres Å utvikle gode systemer for alle brukere er utfordrende fordi brukernes krav er forskjellige I utviklingsfasen klarer en ikke å enes om hva som er viktigst Gode grensesnitt krever ofte mer maskinkraft enn det som er tilgjengelig.
Definisjon av brukskvalitet Brukskvalitet er... the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments Anvendbarhet, Effektivitet og Tilfredsstillelse for bestemte brukere med bestemte mål i bestemte omgivelser
Brukskvalitet
Brukskvalitet og andre egenskaper Brukskvalitet er en kontekstavhengig egenskap ved et produkt og er bare meningsfylt å måle når en vet: Hvem som skal bruke produktet Hva de vil bruke det til Hvor, og i hvilken sammenheng de skal bruke det Kontekstuavhengige egenskaper oppfattes likt av alle slik som: Vekt, Størrelse, Farge, Prosessorhastighet.
Et system har høy brukskvalitet når det er Lett å lære Brukere kan gå raskt fra å ikke kjenne systemet til å bruke det Effektivt Lar ekspertbrukeren oppnå en høy grad av produktivitet. Lett å huske Brukere med lav brukshyppighet kan ta det i bruk igjen uten å måtte lære alt på nytt. Feilfritt og feiltolerant Brukerne gjør få feil, og feilene medfører ikke stopp og det er lett å komme videre Behagelig og tilfredsstillende å bruke Gir brukeren positive opplevelser når de bruker systemet.
9 eksempler på høy brukskvalitet 1. Systemet er konsistent - likt over alt 2. Det er mulig å bruke snarveier - kontrolltegn 3. Har meningsfylte feil- og tilbakemeldinger 4. Benytter dialoger med klar begynnelse og slutt 5. Feilhåndteringen hindrer at systemet stopper 6. Har angrefunksjon - reversere handlinger 7. Lar brukeren føle at han kontrollerer systemet 8. Stiller små krav til hukommelse hos brukeren 9. Hjelp er lett tilgjengelig og forståelig
Høy brukskvalitet for en nettbutikk Oversiktlige og strukturerte produktbeskrivelser, gode tilbakemeldinger og menystruktur som viser hvor i systemet kjøperen befinner seg. Kjøpeknapp og handlekurv lett tilgjengelig. Brukeren merker at løfter overholdes. Brukeren har mulighet til å angre uten å måtte fylle ut skjemaet på nytt. Enkle snarveier for flergangskunder. Feilmeldinger gir god informasjon uten koder.
Høy og lav brukskvalitet
Tilfredse brukere får vi når systemet: Gjør det brukeren forventer Er effektivt Hjelper brukeren til å gjøre en god jobb Det medfører: God reklame for systemet Brukere som er lite villige til å gå over til et nytt system
Evalueringsspørsmål Hvor lang tid tar det før en bruker Har god oversikt over systemets funksjonalitet? Kommer med forslag om hvordan systemet kan brukes? Ser hvilken effekt og nytte han har av systemet? Hvor lang tid tror du brukeren er villig til å bruke på dette?
Noen evalueringsspørsmål Er grensesnittet standardisert og konsistent? Finnes det snarveier for eksperten? Gir grensesnittet informative tilbakemeldinger? Kan vi reversere handlinger (undo)? Er det gode feilmeldinger og god feilhåndtering? Er det brukeren eller grensesnittet som har kontrollen? Er neste hendelse selvinnlysende? Er grensesnittet selvforklarende/intuitivt? Slipper du å huske brukssekvenser?
Om informasjon på internett Hvordan vet jeg om om informasjonen er: Sann Pålitelig Troverdig Kvalitetssikret At det ikke er påvirkningsinformasjon desinformasjon manipulert unyansert ufullstendig feilinformasjon
Konsekvenser av feil valgt informasjonssystem Systemet støtter ikke viktige forretningsprosesser eller støtten er dårlig Misfornøyde kunder, brukere Tap av markedsandeler Systemet blir ikke brukt eller det utvikler seg nye arbeidsmåter som ikke er optimale
Et utgangspunkt for evaluering Forstå rammebetingelsene og forutsetningene Hva vi ønsker/forventer at systemet skal gjøre Hva vi opplever at systemet gjør Kvaliteten Forskjellen mellom forventning og det i fikk Hvordan støttes arbeidet i virksomheten? Drift og vedlikehold av systemet Dokumentasjon av systemet Holde systemet oppe Hjelp når noe går feil Feilretting, endring og nyutvikling
En modell for evaluering og valg Løse dagens behov ITsystemet løser dagens arbeidsoppgaver Løse fremtidige behov ITsystemet løser fremtidige arbeidsoppgaver Implementering Tilpasning til maskiner, infrastruktur og installasjon av systemet Support Hvordan systemet videreutvikles og tilpasses nye behov i program og virksomhet Kostnader Alle kostnader ved å bruke systemet. Drift, vedlikehold, lisenser, reduksjon/økning av personalkostnader og estimering av alle ikke målbare størrelser som goodwill, personaltrivsel.
Eksempel på struktur i en evaluering Kost/nytteanalyse Hvilke redusert kostnader fører systemet til? Hvilken økt nytte fører systemet til? Kravspesifikasjonen til systemet Hvordan er hvert krav oppfylt? Innføring av systemet Drift, vedlikehold og videreutviklling
Evaluering av kravene Beskriv systemets hovedfunksjoner fra forskjellige perspektiver i virksomheten: brukerens perspektiv ledelsens og ansattes perspektiv driftspersonalets perspektiv og vurder hvordan hver funksjon er løst. Vurder hvert delsystem som systemet består av på tilsvarende måte
Evalueringskriterier Løsningens arkitektur Skalerbarhet Ytelse Pålitelighet Utvidbarhet Programmerbarhet Åpenhet/enkel å integrere Sikkerhet Drift- og administrerbarhet Støtte for outsourcing scenarioer Tilgjengelighet på kompetanse Løsningens modenhet i markedet Funksjonalitet Kostnad både i innkjøp og drift Brukervennlighet og brukertilgjegelighet Internasjonal støtte Konfigurerbarhet Standardstøtte Produktets fremtidige veikart roadmap Leverandørens størrelse og finansielle status Analytiker rating eller vurdering Support-organisasjon
En sjekkliste - 1 Regner systemet riktig? Er systemet lett å lære/bruke? Gir systemet nyttige rapporter? Er det lett å lage nye rapporter? Hvordan samvirker systemet med andre systemer i virksomheten Hvordan er systemet å drifte Hvordan påvirker systemet virksomhetens organisering Er systemet forankret i ledelsen? Er brukergrensesnittet selvforklarende? Hvordan vil det gå om nøkkelpersoner slutter?
En sjekkliste - 2 Hvilke hovedoppgaver har systemet? Hvordan løses hovedoppgavene? Hvilke positive og negative påvirkninger har systemet på virksomheten Hvilken maskinplattform - ny eller som før? Proprietær eller åpen programvare? Har driftsavdelingen kompetanse til å drifte systemet?
Systemets livsløp - 1 Hvilke behov vil virksomheten løse? Hvilke behov skal systemet løse? Hvordan løses behovene? Grov beskriving av hvordan behovene løses Vurder kravspesifikasjon mot løsning Hvordan er programmene bygd opp? Utviklingsplattform, objektorientering, gjenbruk Feiltesting, svakheter, avgjørende valg
Systemets livsløp - 2 Innføring Undervise brukerne Lage et driftsmiljø: Maskin, personale, kontaktarbeid Forvaltning Drift Vedlikehold og videreutvikling Lage nye eller tilpasse rapporter Lage nye eller tilpasse funksjoner Rette alvorlige feil Lære opp brukere System- og brukerdokumentasjon Brukerhåndbok, hjelpfunksjonen
Distribusjonskjeden G D G P D F
Evalueringer og IT-strategi Et IT innkjøp er realiseringen av en IT strategi Evalueringskriterier skal være forankret i IT strategien Beslutningen må kunne forankres i IT strategi og ikke gå på tvers av denne Vurder strategiske vs taktiske sysnpunkter! Det vil alltid være behov for unntak, men Legg ikke IT strategien i det øyeblikk dokumentet er ferdigstillt