Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä

Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä

Agenda Tehtävänanto Johdanto Näkökulma Ohjelmistotuotantoprosessit Testaus & arviointimenetelmät Menetelmien yhdistäminen, onnistuuko? Systemaattinen käyttöliittymäsuunnittelu/ Vapaata keskustelua ja kysymyksiä

Tehtävänanto Käytettävyyttä voidaan yrittää huomioida lisäämällä ohjelmistokehitysprosessiin käyttöliittymän arviointi- ja testausmenetelmiä (systemaattisen kälisuunnittelun sijaan). Ks. lähtökohdaksi tietoa eri testausmenetelmistä esim. Käli II kurssin luentosivuilta tai testausseminaarin sivuilta. Valitse tarkasteltavaksi pari erilaista ohjelmistoprosessimallia (esimerkiksi vesiputousmalli, evoluutiomalli tai jokin ketterä menetelmä). Lisää näihin prosesseihin parhaaksi katsomasi testausmenetelmät, piirrä niistä kaaviokuvat ja perustele valintasi. Mitä tästä seuraa käyttöliittymälle? Vertaa seurauksia siihen, mitä tapahtuisi, jos prosessiin olisikin lisätty systemaattinen kälisuunnittelu. Valitse konkreettisia esimerkkitapauksia omista työkokemuksistasi tai keksi itse sopivia esimerkkejä.

Johdanto Eräässä työpaikassa oli käytettävyys palaveri Järjestetään muutaman kerran vuodessa Käydään läpi ennakkoon kerättyjä ongelmia, jotka koskevat esim. yksittäisiä dialogeja Selkeästi ongelmat johtuivat kokonaisuudesta Asiakkaan tarkkaa käyttötarvetta ei tunnettu Pohdin jo tuolloin, kuinka ohjelmistoa voisi parantaa vastaamaan paremmin todellisuutta tai kuinka prosessia voisi parantaa?

Näkökulma Näkökulma käyttöliittymäsuunnittelijan rooli Kuinka selviytyä perinteisessä ohjelmistotuotantoprojektissa? Mitä arviointi ja testausmenetelmiä voidaan käyttää, mitä siitä seuraa? Miten nämä ongelmat voidaan havainnollistaa esim. projektijohdolle? Näkökulma perustuu osittain omiin kokemuksiin lähihistorian työpaikasta

Ohjelmistotuotantoprosessit

Vesiputousmalli Peräisin 70-luvulta, insinööritausta Käytettiin alkuaan alkeellisten I/O tyyppisten järjestelmien suunnitteluun Perustuu syötteinä toimiviin dokumentteihin, virheet kertautuvat todennäköisesti Toimii kohtuullisesti pienissä projekteissa, jos tekijätiimi taitava ja kokenut Todellisuudessa prosessin esittämän jaon noudattaminen mahdotonta, projekti luisuu anarkiaan.

Extreme Programming

Extreme Programming Perustuu inkrementaaliseen ohjelmistokehitykseen Asiakas ei tiedä mitä haluaa: I can't tell you what i want, but i'll know when i see it Dokumentointi pyritään minimoimaan Ei panosteta uudelleen käytettävyyteen Ohjelmistoyritysten rahastusautomaatti, jotain tapahtuu jatkuvasti, todellinen vastuu projektista asiakkaalla, laskutus juoksee Jatkuva iterointi lisää monimutkaisuutta

Extreme Programming Malli muodostaa rikkinäisiä työketjuja Tarvittavat toiminnot löytyvät todennäköisesti Asiakas ei hahmota kokonaisuutta

Arviointi- ja testausmenetelmät Tehokkuus Opittavuus Näiden kahden tekijän tasapainon oltava kunnossa Tehokkuuteen voidaan lisätä käytettävyyttä Opittavuus ja tehokkuus voivat olla pahasti ristiriidassa->esimerkki Sopivat menetelmät, jotka sopisivat kälisuunnittelijalle itsenäiseen työhön

Arviointi- ja testausmenetelmät

Simulointitestaus

Simulointitestaus Asiantuntijan simuloima, käyttäjää ei tarvita Selvitetään paras mahdollinen ratkaisu Selvitetään paras kälin tarjoama ratkaisu Ristiriita näiden vaihtoehtojen välillä mahdollinen Asiantuntija simuloi käyttäjää, voisiko käyttäjä täydellisellä tietämyksellä järjestelmästä suorittaa tehtävän Arvioi hyödyllisyyttä ja tehokkuutta Ei ota juuri kantaa opittavuuteen

Simulointitestaus Simulointia suoritetaan useaan kertaan, simuloinnista piirretään havainnollinen kaavio, jossa kaikki vaiheet Tilanteen tulee olla realistinen Tehokkuusongelmat havaitaan esimerkiksi monimutkaisista navigointiketjuista Tietosisältöongelmat löytyvät jos päätöksentekoon ei löydy riittävästi tietoa

Kognitiivinen läpikäynti

Kognitiivinen läpikäynti Asiantuntijan simuloima, käyttäjää ei tarvita Keskittyy opittavuuteen liittyviin ongelmiin Suoritetaan kun tehokkuuteen liittyvät ongelmat on ratkaistu Poistetaan opittavuusesteitä Tietosisällöllä ei merkitystä (on jo kunnossa) Tärkeää on, että käyttäjä keksii ja oivaltaa mitä hänen pitää tehdä Ongelmia voidaan korjata esimerkiksi poistamalla ylimääräisiä vaiheita Vaati proton tai kälikuvat

Heuristinen arviointi

Heuristinen arviointi Asiantuntijan simuloima, käyttäjää ei tarvita Sovellusalueen tuntemisesta etua, tarvittaessa alan asiantuntija avustaa Tarkastellaan käytettävyysperiaatteiden mukaan Auttava esiintulevien ongelmien korjaamista Arviointiin sopii käyttäjätarinasta valmiiseen ohjelmaan Löydetään piileviä käytettävyysongelmia, mutta ei oteta kantaa hyödyllisyyteen

Ohjelmistokehitysprosessit + Arviointi ja testausmenetelmät + =:-)

Ohjelmistokehitysprosessit + Arviointi ja testausmenetelmät Mitä tapahtuu kun perinteisiin prosessimalleihin lisätään arviointi ja testausmenetelmiä? Taustalla tilanneasettelu, tutkielmassa Käyttöliittymäsuunnittelijan valta rajallinen Pääpaino prosesseissa vanhojen tapojen säilyttäminen, koska realistista Käyttöliittymäsuunnittelijan vastuu kasvaa Prosessin muiden osapuolten rooli ei muutu

Vesiputousmalli Määrittely Heuristinen Analyysi Suunnittelu Heuristinen Analyysi Simulointitestaus Toteutus Simulointitestaus Testaus&käyttöönotto Kognitiivinen läpikäynti

Vesiputousmalli Pyritään vähentämään turhia iteraatiokierroksia Estetään virheellisen syötteen pääsy seuraavalle tasolle Vaihesiirtymät kontrolliin, validointitapa Projekti ei pääse toteutukseen, ennen kun käytettävyys kunnossa Käyttöliittymäsuunnittelija tarkastelee jokaista askelmaa käytettävyyden lomassa, kommunikoi kaikille osapuolille heidän omalla kielellään

Vesiputousmalli Määrittelyvaiheessa piirretään esim. umlkäyttötapausten perusteella kälikuvat Kälikuvat ja interaktiomalli toimitetaan toteuttajille, näin koodaajien ei tarvitse ottaa kantaa käyttöliittymään, laatu paranee Toteutusvaiheessa varmennetaan simulointitestauksella, että ohjelmisto vastaa määrittelyään (kälikuvat) Käyttöönoton yhteydessä tulevat ongelmat (käytettävyys, opittavuus, työkulku)

Vesiputousmalli Suoritetaan iteraatiokierroksia ja korjataan ongelmat, kierrosten määrä vähäinen Ei ratkaisi ongelmaa täysin, mutta auttaa varmentamaan ko. prosessissa edes siedettäväntasoisen käytettävyyden Käyttöliittymäsuunnittelijan rooli ja taakka suuri, lähes projektipäällikkömäinen Lopputuloksen ratkaisee se, paljon informaatiota on saatu ja kuinka sitä on käytetty Projekti voi edelleen epäonnistua pahasti

Extreme programming malli

Extreme programming malli Käytettävyyden kannalta suurimmat ongelmat toimintosaarekkeissa Pala palalta ilman suunnitelma toteutettu ohjelmisto on sekainen Koko ohjelmistoa ei voida nähdä XP-muistuttaakin kalliilla tavalla toteutettua GUIDe prosessia Voidaan taistella vastaan suorittamalla sopivissa kohdissa käliarvioita

Extreme programming malli Asiakkaan toiveet kokonaisempia, ei yksittäisiä nappuloita Asiakkaan toiveen jälkeen heuristinen analyysi vaikutuksesta ohjelmistoon Toteutuksen jälkeen simulointitestauksella varmennetaan, että tapaus menee läpi, samoin varmennetaan edelliset tapaukset Näin estetään ohjelman rikkoutuminen Uuden lisääminen ei vahingoita vanhoja

Vesiputous+GUIDe Määrittely -Käyttötapaukset Käyttöliittymäsunnittelu GUIDen tuoma muutos alkuun Käyttöliittymän arviointi-iteraatiot Toteutuksen suunnittelu Toteutus& yksikkötestaus Integrointi & järjestelmätestus Käyttöönotto & Ylläpito

Extreme programming+guide Käyttötapausten selvittäminen Ei asiakkaan laatimia käyttäjätarinoita vaan alussa selvitettyjä käyttötapauksia Käyttöliittymäsuunnittelu Käyttöliittymän arviointi iteraatiot Nopea toteutu ksen suunnitelu GUIDen tuoma muutos projektin alkuun KT 1 Koodaus työnjako 1 Yksikkö testit 1 Pari koodaus 1 Yksikkö testaus 1 Integrointi 1 KT 1 Koodaus työnjako 2 Yksikkö testit 2 Pari koodaus 2 Yksikkö testaus 2 Integrointi 2

GUIDe-edut Ohjelmasta saadaan aina riittävän toimiva pienoismalli ennen kallista toteutusvaihetta Vähentää molemmissa malleissa, erityisesti vesiputousmallissa, iterointia eri kohtien välillä, sillä syöte on jo mahdollisimman oikeellista alusta pitäen Vesiputousmallissa GUIDe auttaa tekemään käytettävyydestä täsmällisen, mitattavan suureen

Kysymyksiä? Yrityksistä näyttäisi olevan tarvetta/kysyntää sellaisille menetelmille, jotka parantavat nykyisiä prosesseja Kynnys kirjoittaa softat uudelleen on aivan liian suuri, lisäksi toimintatavat ovat jäykkiä ja pinttyneitä