SEPA Päiväkirja. Käytettävyyden arviointi

Transkriptio

1 SEPA Päiväkirja Käytettävyyden arviointi T Ohjelmistotuotannon erikoiskurssi Aleksi Airola 39054L Vesa Haukkavaara 60610A Elina Kontro 57184R

2 Muutoshistoria Versio Pvm Tekijä Kuvaus Elina Kontro Ensimmäinen versio, johdantoa Elina Kontro Pieniä korjauksia, ajatuksia ranskalaisilla viivoilla Aleksi Airola Lisäyksiä keltaisella merkittyinä, kommentointia Elina Kontro Muokkasin, korjasin, alustavasti menetelmien soveltamisesta Elina Kontro Käytettävyyskriteerit, ryhmäläpikäyntiasiaa Elina Kontro Lisäyksiä ryhmäläpikäynti kohtaan, kirjoitusvirheiden korjausta, Proton kuvia liitteeksi, testitilaisuudenrakenne liitteeksi, lähdeluettelo Vesa Haukkavaara Testitehtävät lisätty liitteeseen, kirjoitusvirheiden korjausta Elina Kontro Loput protokuvat Elina Kontro Kriteerien päivitystä, liitteen 2 päivitystä Elina Kontro Ryhmäläpikäynnin tuloksia Elina Kontro Toinen käytettävyystesti kuvaus aloitettu Elina Kontro Jatkoa toiseen käytettävyystestiin, liite 5 lisätty Vesa Haukkavaara Testitehtäviä lisätty täyttämään I1:n lopun tarpeet Aleksi Airola Heuristisen arvio I1 iteraatiossa Elina Kontro 2. käytettävyystesti tarkennus, kritteerien päivitys, muuta muokkausta Elina Kontro 3. käytettävyystestin suunnittelua Elina Kontro Aleksi Airola Heuristisen arvion kokemuksia Pieniä korjauksia kolmanteen käytettävyystestiin kommenttien perusteella Elina Kontro Käytettävyystesti 3. tuloksista, testitietojen päivitys Aleksi Airola Heuristisen arvion tulokset Elina Kontro Korjailua ja yhteenveto

3 Sisällysluettelo 1 JOHDANTO MENETELMIEN SOVELTAMINEN PROJEKTISSA KÄYTETTÄVYYSTESTIT Ryhmäläpikäynti Toinen käytettävyystesti Kolmas käytettävyystesti HEURISTINEN ARVIO Heuristinen arvio I1-iteraatiossa Heuristinen arvio I2-iteraatiossa KOKEMUKSIA TOTEUSTUSITERAATIO Ryhmäläpikäynti Heuristinen arvio Toinen käytettävyystesti TOTEUSTUSITERAATIO Kolmas käytettävyystesti Toinen heuristinen arvio YHTEENVETO LÄHDELUETTELO...16 LIITTEET...1

4 1 Johdanto Tässä dokumentissa kuvataan T Ohjelmistotuotannon erikoiskurssin puitteissa toteutettava perehtyminen valittuihin ohjelmistokehityksen käytäntöihin. Dokumentissa kuvattuja käytäntöjä sovelletaan samaan aikaan suoritettavalla T Ohjelmistokehitysprojekti I-kurssilla toteutettavassa CoSCA - simulaattorin jatkokehitysprojektissa. Tässä työssä käytettävyyden arviointia tehtiin sekä käytettävyystesteillä että heuristisella arviolla. Käytettävyyden arvioinnin tavoitteena on testata ja parantaa kehitteillä olevan tuotteen käytettävyyttä. Tuotetta kehitettäessä pyritään kiinnittämään erityistä huomiota tuotteen tulevien käyttäjien näkökulmaan: pystyvätkö käyttäjät tekemään järjestelmällä niitä tehtäviä, joihin se on suunniteltu? Ohjelmistokehitysprojektissa tavoitteena on toteuttaa olemassa olevaan CoSCA -simulaattoriin helppokäyttöinen ja opittava käyttöliittymä, joka mahdollistaa simulaattorin hyödyntämisen Helsingin Kauppakorkeakoulussa (HKKK) opetuksen apuvälineenä. Näin ollen oli luontevaa ottaa käytettävyyden arviointi yhdeksi projektissa käytettäväksi menetelmäksi, jolla pyrittiin varmistamaan halutun tavoitteen helposti käytettävän ja opittavan käyttöliittymän saavuttaminen. Käytettävyystestauksessa käyttäjäryhmä, johon keskitytään, ovat HKKK:n opiskelijat, joita osallistui testeihin yhteensä 25 henkilöä. Testejä tehtiin projektin aikana kolme kappaletta. Heuristinen arviointi tehtiin Nielsenin heuristiikkojen pohjalta ja suoritettiin kerran kummassakin iteraatiossa. Käytettävyyden arviointia suunniteltaessa perehdyttiin Jacob Nielsenin kirjaan Usability Engineering ja Sirpa Riihiahon artikkeleihin Käytettävyystestauksen muunnelmia ja Käytettävyyden arviointi käyttäjiä. 1

5 2 Menetelmien soveltaminen projektissa Valittuja menetelmiä, heuristinen arvio ja käytettävyystestit, käytetään osana toteutettavan tuotteen testausta. Seuraavissa luvuissa kuvataan valittujen menetelmien soveltamista CoSCA -simulaattorin jatkokehitysprojektissa. 2.1 Käytettävyystestit Ryhmäläpikäynti Ensimmäinen käytettävyystesti käyttäjien kanssa tullaan tekemään paperiprotoa käyttäen ns. ryhmäläpikäyntimenetelmällä [2]. Testi tullaan tekemään heti I1-iteraation alussa, jotta testistä saatua palautetta ja tuloksia voidaan hyödyntää käyttöliittymän suunnittelussa I1-iteraation aikana. Koska kehitettävän käyttöliittymän ensisijainen kohdeyleisö on Helsingin Kauppakorkeakoulun opiskelijat, tulevat käyttäjät testissäkin olemaan ko. kohderyhmän edustajia. Ryhmäläpikäyntiin osallistuu 2 käyttäjää, 1 käyttöliittymän suunnittelija ja 2 käytettävyysasiantuntijaa. Ryhmäläpikäynnissä sekä käyttäjät että suunnittelija tekevät itsenäisesti annetut t (liite 1) paperiprotoa käyttäen, merkiten paperiprotoon ne toiminnot, joita käyttää n tekemiseksi. Käytettävyysasiantuntijoista toinen toimii testitilanteen ohjaajana ja toinen ohjaa tehtävien jälkeistä keskustelua. Vaikka keskustelu onkin vapaamuotoista, pyritään sitä ohjaamaan niin, että ennalta määritellyistä osa-alueista (taulukko 1 ja liite 2) saadaan palautetta. Testissä käytettävän proton kuvat ovat liitteessä 3. Tilaisuudessa Aleksi edustaa suunnittelijoita, Elina ja Vesa käytettävyysasiantuntijoita: Vesa ohjaa testitehtävien läpiviennin, Elina ohjaa keskusteluosuutta. Testitilaisuuden rakenne (tarkemmin liiteessä 2): - Esittely (10min) - Kaksi ä paperiprotolla itsenäisesti (20 min) (Tehtävät annetaan yksitellen) - Keskustelua testitehtävistä ja protosta ( 30 min) - Lopetus (10 min) Käytettävyyskriteerit Käytettävyyden arvioinnissa keskitytään opittavuuden ja miellyttävyyden mittaamiseen. Kurss(e)ille, jossa työkalua käytetään opetuksen apuvälineenä, tulee uusia opiskelijoita joka vuosi. Työkalun tulee olla nopeasti opittavissa, jotta harjoitusten tekemisessä aika ei kulu työkalun käytön opiskeluun, vaan itse asiaan, 2

6 harjoitusten tekemiseen ja niistä oppimiseen. Mitä miellyttävämmäksi opiskelijat kokevat työkalun käytön sitä mieluummin sitä myös käytetään. Taulukossa 1 on koostettu käytettävyyskriteerit ja mittarit, joihin ensimmäisessä käytettävyystestissä keskitytään. Miellyttävyyttä mitattaessa käyttäjiä pyydetään arvoimaan käytön helppoutta, ikkunoiden ryhmittelyä ja tulostentarkastelua asteikolla 1-3 ja annetuista arvioista lasketaan keskiarvo. Annetulla asteikolla 1 on paras arvosana ja 3 huonoin (tarkemmin kysymyskohtaisesti liitteessä 2) Taulukko 1. Käytettävyyskriteerit ja mittarit Opittavuus Käytettävyyskriteeri Käytettävyystekijä Mittaustapa Mittari Esimerkki systeemin valitseminen Esimerkki työvirran valitseminen Esimerkki kustannusrakenteen valitseminen Tarkasteluaikavälin valinta Päätössäännönvalinta Käyttöliittymässä käytetyt termit Miellyttävyys Käytön helppous Keskustelu Käyttöliittymässä käytetyt termit Käyttöliittymän toimintojen ryhmittelyn selkeys Tulosten tarkastelu Keskustelu Keskustelu Haastattelu tehtävän mukaisen systeemin ilamn tehtävän mukaisen systeemin tehtävän mukaisen kustannusrakent een tehtävän mukaisen tarkasteluaikaväli n haluamansa päätössäännön Käyttöliittymässä käytety termit Alin hyväksytty taso Tavoite taso Paras Taso apua termien kanssa 1/2 tuntee termit ovat tuttuja Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymässä käytety termit ovat tuttuja apua termien kanssa 1/2 tuntee termit Käyttöliittymän ryhmittely on onnistunut (keskiarvo) Tulosten esitystapa on ymmärrettävä (keskiarvo) /2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 tuntee termit 2/2 tuntee termit 3

7 2.1.2 Toinen käytettävyystesti Toinen käytettävyystesti on perinteinen testitehtävillä suoritettava testi. Testi tehdään iteraatio 1:n lopussa, jolloin testissä on käytettävissä sovelluksen ensimmäinen toimiva ohjelmaversio ja saatuja tuloksia voidaan hyödyntää I2 iteraatiossa. Myös tässä testissä testikäyttäjät edustavat kohderyhmää eli ovat HKKK:n opiskelijoita ja testejä tehdään kaksi kappaletta. Käytettävyystestiin osallistuu kerrallaan yksi testikäyttäjä, testiohjaaja ja avustaja. Testiohjaaja kertoo mitä testissä tapahtuu, antaa t ja haastattelee lopuksi testikäyttäjän. Avustaja kirjaa muistiinpanot havainnoista ja haastattelusta. Ensimmäisessä testissä Elina on testiohjaaja ja Vesa kirjaa muistiinpanoja, toiseen testiin rooleja vaihdetaan. Testikäyttäjä suorittaa ennalta määritellyt t sovelluksella itsenäisesti kertoen samalla ääneen mitä on tekemässä. Ryhmäläpikäynnissä käytettyjä tehtävit on muokattu tähän käytettävyystestiin sopivaksi (tehtävät 3 ja 4 liiteessä 1). Testit pidetään Otaniemessä 8.12 ja yhden testitilaisuuden kesto on noin 1 tunti. Testitilaisuuden rakenne (tarkemmin liiteessä 6): - Esittely (10min) - Kaksi ä toimivalla ohjelmalla ääneen ajatellen (20 min) (Tehtävät annetaan yksitellen) - Haastattelu (20 min) - Lopetus (10 min) Käytettävyyskriteerit Toisessakin käytettävyys testissä keskitytään opittavuuden ja miellyttävyyden mittaamiseen. Taulukossa 2 on koostettu käytettävyyskriteerit ja mittarit, joihin toisessa käytettävyystestissä keskitytään. Miellyttävyyttä mitattaessa käyttäjiä pyydetään arvoimaan käytön helppoutta, ikkunoiden ryhmittelyä ja tulostentarkastelua asteikolla 1-3 ja annetuista arvioista lasketaan keskiarvo. Annetulla asteikolla 1 on paras arvosana ja 3 huonoin (tarkemmin kysymyskohtaisesti liitteessä 6). Opittavuutta mitataan testitehtävillä; saavatko testikäyttäjät tehtyä annetut tehtävät. Taulukko 2. Käytettävyyskriteerit ja mittarit Opittavuus Käytettävyyskriteeri Käytettävyystekijä Mittaustapa Mittari Esimerkki systeemin valitseminen tehtävän mukaisen systeemin Alin hyväksytty taso Tavoite taso Paras Taso 2/2 saa tehtyä 4

8 Miellyttävyys Esimerkki työvirran valitseminen Esimerkki kustannusrakenteen valitseminen Tarkasteluaikavälin valinta Päätössäännönvalinta Päätössäännönvalinta Käyttöliittymässä käytetyt termit Ohjelman käytön helppous Käyttöliittymässä käytetyt termit ja lyhenteet Wizardin käytön helppous Käyttöliittymän toimintojen ryhmittelyn selkeys Wizardissa Tulosten tarkasteluikkuna n selkeys Tulosten tarkastelu Haastattelu Haastattelu Haastattelu Haastattelu Haastattelu Haastattelu tehtävän mukaisen systeemin tehtävän mukaisen kustannusrakent een tehtävän mukaisen tarkasteluaikaväli n haluamansa päätössäännön Saa vaihdettua haluamansa päätössäännön Käyttöliittymässä käytety termit apua termien kanssa 1/2 tuntee termit ovat tuttuja Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymässä käytety termit ovat tuttuja apua termien kanssa 1/2 tuntee termit Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymän ryhmittely on onnistunut (keskiarvo) Tulosten tarkasteluikkuna on selkeä (keskiarvo) Tulosten esitystapa on ymmärrettävä (keskiarvo) /2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 tuntee termit 2/2 tuntee termit Kolmas käytettävyystesti Alkuperäisestä suunnitelmasta poiketen päätimme lisätä kolmanen käytetävyystestin 2. iteraation puoliväliin. Tämä katsottiin tarpeelliseksi koska käyttöliittymän tehdään (on osin jo toteutettu) sekä toiminnallisia lisäyksiä ja muutoksia että ulkonäöllisiä korjauksia. Muutokset ja korjaukset perustuvat joko muuttuneisiin vaatimuksiin tai aikaisemmista käytettävyyden arvionneista saatuihin tuloksiin (kuten esim termistön korjaaminen). Koska omat tuntiresurssimme ovat rajalliset tullaan käytettävyystesti toteuttamaan asiakkaan avustuksella käyttäen kyselylomakketta. Helmikuun alussa pidettävän välidemo tilaisuuden jälkeen käytössä oleva ohjelmisto toimitetaan asiakkaalle, joka edelleen toimittaa tai muutoin mahdollistaa ohjelmiston käytön vähintään kahdelle HKK:n opiskelijalle. Opiskelijat saavat yhden n (liite 10), jonka suorittamisen jälkeen he täyttävä liitteenä 11 olevan kyselylomakkeen. Vesa vastaa n tekemisestäja Elina kyselylomakkeen 5

9 laatimisesta. Testi tulee ajallisesti sijoittumaan viikolle 6. Käytettävyyskriteerit ovat vastaavat kuten aiemminkin, edelleen kiinnostus kohdistuu opittavuuteen ja miellyttävyyteen. Taulukko 3. Käytettävyys kriteerit 3. käytettävyystestiin Opittavuus Miellyttävyys Käytettävyyskriteeri Käytettävyystekijä Mittaustapa Mittari Testitehtävän tekeminen Esimerkki työvirran valitseminen Esimerkki kustannusrakenteen valitseminen Tarkasteluaikavälin valinta Päätössäännönvalinta Päätössäännönvalinta Käyttöliittymässä käytetyt termit Ohjelman käytön helppous Wizardin käytön helppous Käyttöliittymän toimintojen ryhmittelyn selkeys Wizardissa Tulosten tarkasteluikkuna n selkeys Tulosten tarkastelu Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Kyselylomake Alin hyväksytty taso Tavoite taso Paras Taso tehtävän mukaisen systeemin 1 saa tehtyä 2 saa tehtyä tehtävän mukaisen systeemin tehtävän mukaisen kustannusrakent een tehtävän mukaisen tarkasteluaikaväli n haluamansa päätössäännön Saa vaihdettua haluamansa päätössäännön Käyttöliittymässä käytety termit ovat tuttuja apua termien kanssa 1/2 tuntee termit Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymän ryhmittely on onnistunut (keskiarvo) Tulosten tarkasteluikkuna on selkeä (keskiarvo) Tulosten esitystapa on ymmärrettävä (keskiarvo) /2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 tuntee termit 6

10 2.2 Heuristinen arvio Heuristinen arvio I1-iteraatiossa Heuristinen arvio tehdään ennen toista käytettävyystestiä 5.12 ja arvioitavan ohjelmiston laajuus on iteraatio 1:n tuotokset. Menetelmällä pyritään löytämään yleisiä käytettävyysongelmia, kuten epäloogiset ja puuttuvat perustoiminnallisuudet, epäyhtenäisyydet näyttöjen sommittelussa tai painikkeiden ja tekstikenttien epäjohdonmukainen ryhmittely ja järjestys. Arvioinnin suorittavat Aleksi ja Elina. Arviointi suoritetaan ensi vaiheessa itsenäisesti läpikäyntinä ja tavoitteena on löytää käyttöliittymän käytettävyysongelmia. Arvioinnin apuna käytetään tarkistuslistaa (liite 7) ja Nielsenin kymmenen heuristiikkaa(1993) (liite 8). Löytyneille ongelmille kirjataan tunniste, lyhyt kuvaus, heuristiikka, jota se rikkoo ja subjektiivinen arvio vakavuudesta [taulukko 4]. Virheitä ei pyritä tässä vaiheessa arvioimaan muuten kuin arvioijan henkilökohtaisella mielipiteellä tai tekemään korjausehdotuksia. Toisessa vaiheessa Aleksi koostaa ensimmäisessä vaiheessa kerääntyneen tiedon, arvioi niiden vakavuuden sekä tekee alustavat parannusehdotukset ja arvio niiden työmäärän. Yhteenveto käydään läpi palaverissa, jossa päätetään tarvittavista jatkotoimista. Taulukko 4. Virheiden luokitus ja toimenpiteet Virheen vakavuus Selitys Toimenpiteet 1 Virhe ei vaikuta ohjelman toiminnallisuuteen ja se ei riko ohjelman ulkoasua vakavasti. Korjataan, jos se muun tehtävän työn ohessa pystytään korjaamaan. 2 Virhe vaikeuttaa ohjelman käyttöä, on usein käytetty toiminto tai rikkoo ohjelman ulkoasua vakavasti. Virheet arvioidaan työmäärän mukaan ja otetaan osaksi jatkokehitystä. 3 Virhe vaikeuttaa ohjelman käyttöä vakavasti tai aiheuttaa tilanteen, jossa käyttäjä ei pysty tekemään toimintoa toisella tavalla. Nämä kaikki virheet tulee korjata ennen kuin ohjelmaa jatkokehitetään. 7

11 2.2.2 Heuristinen arvio I2-iteraatiossa Toinen heuristinen arvio tehtiin samaan aikaan kuin vertaistestaus I2-iteraation loppupuolella, jolloin mahdolliset korjaukset ehditän tekemään lopulliseen versioon. Arvion kohteena ovat I2:n tuotokset. Käytettävä menetelmä on sama kuin ensimmäisessä heuristisessa arvioinnissa, mutta sen suorittaa vain Aleksi. Arvio suoritetaan itsenäisenä läpikäyntinä, kuten I1:ssa, mutta erona on, että käytetään vakavuuden luokitukseen uutta luokitusta, johon ei ole sidottu toimenpiteitä. Lisäksi tarkistuslistana käytetään vain Nielsenin kymmentä heuristiikkaa. Löytyneet virheet koostetaan ja niille arvioidaan työmäärä. Kooste lähetetään sähköpostitse Elinalle ja Vesalle, ketkä päättävät korjataanko havaitut virheet. Tavoitteena menetelmälle on löytää ainakin 15 virhettä. Taulukko 5. I2:n virheiden luokitus Virheen vakavuus Selitys 1 Virhe ei vaikuta ohjelman toiminnallisuuteen ja se ei riko ohjelman ulkoasua vakavasti. 2 Virhe vaikeuttaa ohjelman käyttöä, on usein käytetty toiminto tai rikkoo ohjelman ulkoasua vakavasti. 3 Virhe vaikeuttaa ohjelman käyttöä vakavasti tai aiheuttaa tilanteen, jossa käyttäjä ei pysty tekemään toimintoa toisella tavalla. 8

12 3 Kokemuksia Seuraavissa kappaleissa kuvataan kuvatuista käytettävyyden arviontimenetelmistä saatuja tuloksia ja kokemuksia. 3.1 Toteustusiteraatio Ryhmäläpikäynti Ryhmäläpikäynti kesti 1,5 tuntia ja kokonaisuudessaan tilaisuus sujui hyvin ja oli palautteen osalta antoisa. Käyttäjät selkeästi pohtivat proton käyttöä testitehtäviä tehdessään. Kumpikin käyttäjä sai t tehtyä. Keskusteluosuudessa kuitenkin kävi ilmi, että käytetty termistö ja lyhenteet eivät olleet täysin tuttuja, mutta olivat pääteltävissä niin, että tehtävän sai tehtyä. Liitteessä 4 on koostettu keskusteluosuudessa esille nostettuja kysymyksiä ja kommentteja. Taulukoon 6. on koostettu tulokset mitattujen käyttävyyskriteerien osalta. Yhteenveto voi todeta, että kriteerit täyttyivät hyvin, testissä saavutettiin joko tavoite taso tai paras mahdollinen taso. Seuraavassa käytettävyystestissä kriteereitä tulee kuitenkin hiukan tarkentaa. Esim. kohta tuntee termistön on tulkinnanvarainen, koska osa oli tuttua ja osa ei. Taulukon tulossarakkeen värikoodaus tarkoittaa seuraavaa: Vihreä = Testissä saavutettiin paras taso Keltainen = Testissä saavutettiin tavoitetaso Taulukko 6. Testissä mitattujen käytettävyyskriteerien tulokset Käytettävyyskriteeri Käytettävyystekijä Mittaustapa Mittari Saavutettu Tulos Alin hyväksytty taso Tavoite taso Paras Taso Opittavuus Esimerkki systeemin valitseminen Esimerkki työvirran valitseminen Esimerkki kustannusrakenteen valitseminen tehtävän mukaisen systeemin ilamn tehtävän mukaisen systeemin tehtävän mukaisen kustannusrakent een 2/2 sai tehtyä 2/2 sai tehtyä 2/2 sai tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 9

13 Tarkasteluaikavälin valinta Päätössäännönvalinta Käyttöliittymässä käytetyt termit Miellyttävyys Käytön helppous Keskustelu Käyttöliittymässä käytetyt termit Käyttöliittymän toimintojen ryhmittelyn selkeys Tulosten tarkastelu Keskustelu Keskustelu Haastattelu tehtävän mukaisen tarkasteluaikaväli n haluamansa päätössäännön Käyttöliittymässä käytety termit ovat tuttuja Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymässä käytety termit ovat tuttuja Käyttöliittymän ryhmittely on onnistunut (keskiarvo) Tulosten esitystapa on ymmärrettävä (keskiarvo) 2/2 sai tehtyä 2/2 sai tehtyä 2/2 tuntee termit niin että sais tehtävät tehtyä 2 2/2 tuntee termit osittain apua termien kanssa 1/2 tuntee termit 2/2 saa tehtyä 2/2 saa tehtyä 2/2 tuntee termit apua termien 1/2 tuntee 2/2 tuntee kanssa termit termit Heuristinen arvio Heuristisen arvion suoritti kaksi henkilöä projektin sisältä, Elina ja Aleksi. Molemmat arvion tekijät kävivät läpi ohjelman tarkistuslistan ja Nielsenin heuristiikkojen avulla. Löydetyille poikkeavuuksille annettiin id, kuvaus, heuristiikka, jota ne rikkovat ja kategorisoitiin kolmeen vakavuus asteeseen. Poikkeavuudet kerättiin yhteen listaan ja niitä arvioitiin muuttuneiden vaatimusten ja suunnitelmien pohjalta. Niille, jotka olivat vielä ajankohtaisia, arvioitiin muutokseen tarvittava työmäärä. Menetelmää arvioitaessa täytyy huomioida, että tulokset ovat riippuvaisia arvioijan taidoista vaikka menetelmä onkin suhteellisen helppo. Menetelmän ansiosta tuli käytyä läpi asioita, jotka perinteisen testauksen menetelmin olisi jäänyt huomaamatta. Aikaa käytettiin neljä tuntia ja saavutimme siitä huomattavaa hyötyä. Vakavuus asteikon määrittely todettiin sisältävän virhe olettaman, että kaikki poikkeavuudet korjataan, sillä esim. muuttuneista vaatimuksista johtuen kaikkia ongelmia ei korjata. Luokittelu heuristiikkoihin, joita rikotaan, koettiin haasteelliseksi, koska heuristiikojen rajat eivät ole selviä, jolloin sama ongelma voi liittyä useampaan heuristiikkaan. Tavoitteiden saavuttamisen mittareita ei ollut tarpeeksi ajateltu. Liitteessä 8 on lueteltuna kaikki menetelmällä havaitut ongelmat. Tila-sarakkeessa merkintä korjattu tarkoittaa, että kyseistä ongelmaa on korjattu arvion perusteella ja merkintä muuttunut viittaa siihen, että ongelma on menettänyt merkityksensä muuttuneiden vaatimusten vuoksi. 10

14 3.1.3 Toinen käytettävyystesti Toinen käytettävyystesti pidettiin I1-iteraation lopussa ja siihen osallistui kaksi asiakkaan rekrytoimaa HKKK:n opiskelijaa. Seuraavan taulukkoon on kuvattu testi tulokset suhteessa asetettuihin kriteereihin. Taulukko käytettävyystestin tulokset Alin hyväksytty taso Tavoite taso tai sen lähellä Paras mahdollinen taso Opittavuus Miellyttävyys Käytettävyyskriteeri Käytettävyystekijä Mittaustapa Mittari Esimerkki systeemin valitseminen Esimerkki työvirran valitseminen Esimerkki kustannusrakenteen valitseminen Tarkasteluaikavälin valinta Päätössäännönvalinta Päätössäännönvalinta Käyttöliittymässä käytetyt termit Ohjelman käytön helppous Käyttöliittymässä käytetyt termit ja lyhenteet Wizardin käytön helppous Käyttöliittymän toimintojen ryhmittelyn selkeys Wizardissa Tulosten tarkasteluikkunan selkeys Tulosten tarkastelu Haastattelu Haastattelu Haastattelu Haastattelu Haastattelu Haastattelu tehtävän mukaisen systeemin tehtävän mukaisen systeemin tehtävän mukaisen kustannusrakent een tehtävän mukaisen tarkasteluaikaväli n haluamansa päätössäännön Saa vaihdettua haluamansa päätössäännön Käyttöliittymässä käytety termit ovat tuttuja Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymässä käytety termit ovat tuttuja Käyttöliittymän käytön helppous (keskiarvo) Käyttöliittymän ryhmittely on onnistunut (keskiarvo) Tulosten tarkasteluikkuna on selkeä (keskiarvo) Tulosten esitystapa on ymmärrettävä (keskiarvo) Saavutettu taso Alin hyväksytty taso Tavoite taso Paras Taso apua termien kanssa 1/2 tuntee termit 2 2,5 1, ,5 1 2,5 2,5 1,5 2,5 1,5 2,5 1,5 2,5 1,5 2,5 1,5 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 saa tehtyä 2/2 tuntee termit

15 Yhteenveto voidaan todeta, että testi oli onnistunut ja hyödyllinen vaikka osallistujia oli vain kaksi. Yleisesti ottaen käyttö koettiin helpoksi. Eniten hankaluuksia tuotti tulosten tulkinta, johon vaikutti se, että käyttäjät eivät muistaneet esim. päätössäännöistä käytettyjä lyhenteitä. He eivät myöskään havainneet, että wizardissa lyhenteistä oli mahdollisuus saada opasteteksti. Tästä syystä wizardin termit päätettiin kirjoittaa kokonaan auki. Tulosten arviointiin vaikutti myös hankaluus ymmärtää kiirehtimis- ja myöhästymiskustannusten ero. Graafisten tulosten esitysten arveltiin helpottavan tulosten tulkintaa. Toivomuksena esitettiin, että graafin saisi tallennettua, jotta se olisi liitettävissä esim. harjoitusraportteihin. Lisäksi toivottiin, että olisi mahdollista nähdä mitä sääntöjä kullakin viikolla oli käytetty. Nämä toiveet otetaan huomioon I2-teotuksista päätettäessä. 3.2 Toteustusiteraatio Kolmas käytettävyystesti Alkuperäisestä suunnitelmasta poiketen sovellus, ohjeet ja kyselylomake jaettiin www-sivun kautta, jolloin kyselylomakekin oli siis www-pohjainen lomake. Koska enää ei ollut tarvetta pysytellä yhden A4-sivun kokoisessa kyselyssä, oli kyselyyn mahdollisuus lisätä kysymyksiä. Kysymysten lisäämisestä ja siitä, ettei vastaajien lukumäärä ollut ennalta tiedossa kriteeritaulukkoa ja sen asteikkoa jouduttiin muuttamaan. Liitteet 9-11 ovat suoritetun testin mukaisia. Loppujen lopuksi määräaikaan mennessä vastauksia tuli 21, joka ylitti odotukset huimasti, sillä vastauksia toivottiin vähintään kahdelta. Taulokossa 8 on kuvattu testitulokset suhteessa kriteereihin nähden. Tilan ahtauden vuoksi taulukosta on poistettu sarake mittaustapa, sillä ainoa käytetty mittaustapa oli kyselylomake. Taulukko käytettävyystestin tulokset ja värimerkintöjen merkitys Alin hyväksytty taso tai lähellä sitä Lähellä tavoite tasoa Tavoite taso tai parempi Paras mahdollinen taso Käytettävyyskriteeri Käytettävyystekijä Mittari (keskiarvo) Saavutettu taso Alin hyväksytty taso Tavoite taso Paras Taso Opittavuus Asennuksen suorittaminen Asennus onnistuu ja on helppoa 1,2 2,5 1,5 1,1 Opittavuus Testitehtävän tekeminen Testitehtävän tekeminen onnistuu ohjetta 1,3 2,5 1,5 1,1 Opittavuus/ Miellyttävyys Sovelluksen käyttäminen Sovelluksen käyttäminen on helppoa 1,4 2,5 1,5 1,1 Opittavuus Sovelluksen termistö Sovelluksen termit ovat tuttuja 1,3 2,5 1,5 1,1 12

16 Käytettävyyskriteeri Käytettävyystekijä Mittari (keskiarvo) Saavutettu taso Alin hyväksytty taso Tavoite taso Paras Taso Opittavuus/ Miellyttävyys Opittavuus Opittavuus/ Miellyttävyys Opittavuus Opittavuus/ Miellyttävyys Opittavuus Opittavuus Tulosten tarkastelu Sovelluksen toiminta Sovelluksen hyöty opetuskäytössä Päätössääntöjen vaihtaminen Referenssitulosten hyödyllisyys Simulaation luominen Simulaation ajaminen Tulokset ovat selkeitä Sovellus toimii odotusten mukaisesti Sovelluksesta on hyötyö opetuksen apuvälineenä Päätössääntöjen vaihtamisen helppous Referenssituloksista on hyötyä Simulaation luominen on helppoa Simulaation ajaminen on helppoa 2,5 2,5 1,5 1,1 1,6 2,5 1,5 1,1 1,5 2,5 1,5 1,1 1,7 2,5 1,5 1,1 1,3 2,5 1,5 1,1 1,6 2,5 1,5 1,1 1,1 2,5 1,5 1,1 Opittavuus Opittavuus Opittavuus Opittavuus Opittavuus Opittavuus/ Miellyttävyys Tulosten tarkastelu Systeemin rakenteen tarkastelu Päätössääntöjen vaihtaminen Simulaation tallentaminen Tallennetun simulaation käyttö Sovelluksen hyödyllisyys Tulosten tarkastelu on helppoa Systeemin rakenteen tarkastelu on helppoa Päätössääntöjen vaihtaminen on helppoa Simulaation tallentaminen on helppoa Tallennetun simulaatiom käyttö on helppoa Sovelluksesta on enemmän hyötyä kuin haittaa opetuksen apuvälineenä 1,7 2,5 1,5 1,1 2,3 2,5 1,5 1,1 1,6 2,5 1,5 1,1 1,5 2,5 1,5 1,1 1,7 2,5 1,5 1,1 1,5 2,5 1,5 1,1 Tulosten perusteella voidaan todeta, että simulaation ajaminen oli erityisen helppoa, sillä siinä saavutettiin paras mahdollinen taso, joskin yksi käyttäjä kirjoitti ettei heti hahmottanut ajo-painikkeen sijaintia. Avointen kommenttien perusteella kaikki eivät olleet heti huomanneet mahdollisuutta ajaa simulaatiota sekä askelittain että kerralla kokonaan. Suurin osa toiminnoista koettiin enemmän helpoksi kuin vaikeiksi. Vain kaksi tekijää on alimmalla hyväksytyllä tasolla tai lähellä sitä. Tuloksia ei pidetty riittävän selkeinä tai niitä ei osattu tulkita. Lisäksi systeemin rakenteen tarkastelu koettiin hankalaksi. Koska puunäkymä oli testin aikaan vielä keskeneräinen ei sitä testissä huomioida. Yksi käyttäjistä ei ollut onnistunut asennuksessa tai ohjelman käynnistyksessä ja lähetetyn informaation peruteella oli mahdotonta lähteä arvaamaan mistä ongelma johtui. Yhtenä mahdollisuutena pidettiin, että ohjeesta huolimatta käyttäjällä on ollut väärä Java -ympäristö asennettuna. Jatkokehitysehdotuksiin tullaan lisäämään ehdotus, että ohjelma tarkistaa käynnistyksen yhteydessä asennetun Java ympäristön ja ilmoittaa käyttäjälle mikäli versio on liian vanha. Muutoin asennusta pidettiin helppona, eniten aikaa oli kulunut oikean Java -paketin hakemiseen, jos sellaista ei valmiina omalla koneella ollut. 13

17 Vastaajista 12/20 piti graafia hyödyllisempänä kuin numeerista tulosten esittämisessä. Avoimien kommenttien perusteella suurin osa käyttäjistä koki sovelluksen käytön yleisesti ottaen helpoksi ja selkeäksi. Wizardin yksinkertaisuudesta pidettiin; wizard ohjasi selkeästi valintojen tekemistä eteni loogisesti. Vaikeaksi koettiin tulosten tulkinta ja ymmärtäminen mitä oli tullut tehtyä. Tämän perusteella voidaan todeta ettei työkalu sovellu ns. itseopiskeluun vaan lähinnä tavoitteen mukaiseen opetuksen apuvälineen asemaan. Tähän viittaa myös se, että suurin osa termistön vaikeudesta liittyi päätössääntöihin; ei muistettu tai tiedetty mitä mikäkin käytännössä tarkoittaa. Hankalimmaksi termiksi osoittautui tardy/tardiness. 13/20 vastasi kysymyksen vaikeista termeistä ja vain yksi heistä totesi, että termit olivat tuttuja suoritetuilta kursseilta. Jatkokehityksessä voisi sovelluksen käytössä olleet päätössäännöt olla lyhyesti kuvattuna myös sovelluksen käyttöohjeessa. Vain muutama vastaajista oli käyttänyt tai katsonut käyttöohjetta, joten kommentit sen osalta jäivät vähäisiksi. On myös todettava ettei käyttöohje ollut vielä tuossa vaiheessa valmis, mutta kommenttien perusteella käytettyä fonttia ja sen kokoa päätettiin muuttaa, jotta ohje olisi helppolukuisempi. Lisäksi käyttöohjeeseen pääsy lisätään myös wizardista. Testissä löytyi myös yksi bugi (kombinaatiolla CR+SPT, CONWIP ja 3-stage system), bugi todennettiin myös omalla testillä ja raportoitiin bugzillaan. Testi perusteella muita sovittuja toimenpiteitä olivat graafin parantaminen (käytännössä johti käytetyn graafipaketin vaihtoon) sekä selkeytetään tulosten luettavuutta siltä osin kuin käytettävissä olevilla resurseilla (tunneilla) on mahdollista. Käytännössä tämä tarkoittaa poistamalla tekstistä lihavointi tarpeettomilta osin sekä siirretään benchmark tuloksia enemmän erilleen omista tuloksista, radikaalimpiin muutoksiin ei ole tämän projektin puitteissa mahdollista, joskin jatkokehityksessä näihin kannattaa kiinnittää huomiota. Systeemin rakenteen tarkastelu tiedettiin haasteelliseksi eikä sitä tässä projektissa lähdetä enää muuttamaan, jatkokehitysehdotuksissa (erillinen dokumentti) tullaan esittämään tähänkin liittyviä parannusehdotuksia. Testi aikaan keskeneräiset toiminnot kuten käyttöohje ja puunäkymän toiminta tehdään loppuun suunnitelmien mukaisesti sekä testissä havaittu bugi korjataan. Käytettävyystestin voidaan kaiken kaikkiaan todeta olleen onnistunut ja hyödyllinen. Erityisen hienoa oli se, että palautetta saatiin odotettua suuremmalta joukolta vaikka testiin annettu aika oli suhteellisen lyhyt. Käytettävyystestiin osallistuneiden arvion perusteella sovelluksesta on selkeästi enemmän hyötyä kuin haittaa opetuksen apuvälineenä, kritteereissä täsäs saavutettiin tavoitetaso. Tämä oli hyvä viesti ajatellen koko projektin tavoitteita. Kun opiskelijoille kertyy kokemusta sekä sovelluksesta että aihealuuesta, pystyvät he varmasti antamaan entistä parempaa palautetta jatkokehityksen kannalta, joten käyttäjät kannattaa pitää mukana kehityksessä Toinen heuristinen arvio Toinen heuristinen suoritettiin yhtä aikaa vertaistestauksen kanssa. Ajankohta oli hyvin myöhäinen, jotta pystyisi tekemään enää mitään merkittäviä muutoksia. Arvioinnissa keskityttiin kokonaisuuden visuaaliseen puoleen ja 14

18 löydettiin myös joitain toiminnallisia virheitä. Arvion suorittaminen tukee normaalia testausprosessia, kun kaikki toiminnot käydään läpi. Tarkistuslistan käyttö oli rajattu vain Nielsenin kymmeneen heuristiikkaan ja se on aivan liian karkea. Tarkistuslistaa pitäisi yrittää kerätä ja parantaa ajan mittaan, koska emme löytäneet käyttöön parempaa. Tavoitteen asettelu löytää 15 virhettä oli naiivi. Saavutimme tavoitteen, mutta se ei kuitenkaan kerro mitään laadusta. Laatua voi tässä tapauksessa arvioida subjektiivisesti. Arvioni mukaan laatu on hyvä. Arvioinnissa löytyi 2 kappaletta tason 2 virhettä ja 18 kappaletta tason 1 virhettä (tasot on kuvattu kappaleessa 2.2.2). Kooste tuloksista on liitteessä Yhteenveto Suoritetut käyttävyydenarviot olivat projektin kannalta hyödyllisiä. Käyttöliittymien suunnittelu käyttäjäystävällisiksi, helposti opittaviksi ja miellyttäviksi on haasteellista, sillä vaikka on tiettyjä yleisesti hyväksyttyjä suunnittelutapoja, jää kuitenkin jäljelle paljon asioita jotka pitää ratkaista tapauskohtaisesti tai ainakin se, kuinka mitäkin yleistä ohjetta kussakin tapauksessa noudatetaan. Ilman erillistä SEPA aihetta käytettävyydenarviosta emme todennäköisesti olisi kiinnittäneet niin paljon huomiota tähän arviointiin vaikka käyttäjän huomioon ottava tuotekehitysnäkökulma oli alusta asti mielessä. Ideaalitilanne olisi ollut jos useampi henkilö projektiryhmästä olisi voinut osallistua jonkin arviointitavan suorittamiseen. Heurististen arvioiden avulla saatiin testaustapa, jossa keskityttiin käyttöliittymän suunnittelun ongelmien havaitsemiseen. Koska käyttöliittymä oli projektin keskeisimpiä asioita, ei sen arvioinnin tärkeyttä voi vähätellä. Heurististen arvioiden ajankohta ei ollut välttämättä paras mahdollinen, tosin kovin monella muullakaan ajoituksella niitä ei olisi voinut tehdä. Ensimmäinen arvio oli järkevää tehdä silloin kun ensimmäinen toimiva asiakkaalle lähtevä versio oli valmis, mutta osa havainnoista menetti merkityksensä vaatimusten muuttumisen myötä. Toiseen heuristisen arvioon oli käytettävissä vain yksi resurssi ja luonnollisesti olisi ollut parempi jos arvion olisi tehnyt vähintään kaksi henkilöä. Ajoitus oli siinä mielessä myöhäinen, että merkittäviin muutoksiin ei ollut enää aikaa, mikäli niitä olisi löytynyt. Käyttäjien kanssa tehty ensimmäinen käytettävyys testi paperiprotolla oli erinomainen ajatus. Näin saimme heti palautetta käyttöliittymäsuunnitelmiin. Testiin osallistui vai kaksi käyttäjää, joka oli aika vähäinen määrä. Ensimmäisen testiin olisi voinut myös joko lisätä konseptin validointi -näkökulman tai testi tarkoitusta olisi voinut muuttaa siten, että koko ideaa ja sen käyttökelpoisuutta olisi arvioitu käyttäjien kanssa, sillä kuinka hyödyllinen opetuksen apuväline sovellus on, riippuu pitkälti siitä kuinka hyödylliseksi opiskelijat sen kokevat. Joka tapauksessa protoilu oli kannattavaa. Toinen testi tehtiin sovelluksen ensimmäisellä toimivalla versiolla iteraation lopussa. Ajankohta on jälleen kaksipiippuinen juttu, toisaalta saatiin palautetta hyvissä ajoin mutta toisaalta huomio kiinnittyi välillä enemmän siihen mitä vielä puuttuu kuin siihen miten olemassa oleva toiminnallisuus toimii. Tokihan palaute puuttuvien toiminnallisuuksienkin osalta oli hyödyllistä. Jälleen käyttäjiä oli vain kaksi, joka on suhteellisen pieni lukumäärä. Käytettävissä olevilla resursseilla emme kuitenkaan olisi 15

19 voineet lukumäärää kasvattaakaan. Kolmas testi ei kuulunut alkuperäiseen suunnitelmaan mutta onneksi se saatiin mukaan. Päätös toteuttaa testi www-pohjaisen jakelun kautta tehtiin suhteellisen myöhään, joka johti siihen, ettei testin kaikkia osa-alueita ehditty suunnittelemaa riittävän hyvin. Tästä seurasi mm. se että jälleen keskeneräisen softan puutteisiin kiinnitettiin huomiota. Sitä olisi voitu ainakin osin taklata paremmalla informoinnilla. Joka tapauksessa testi oli onnistunut palautetta tuli todella mukavasti, niin ruusuja kuin risujakin. Jatkon kannalta voikin todeta, että ennen tarkempien jatkokehityssuunnitelmien tekemistä kannattaa kerätä käyttäjien kokemuksia ja kuunnella heidän näkemyksiään siitä kuinka sovellus voisi paremmin tukea heidän oppimistaan. 4 Lähdeluettelo [1]Nielsen, Jakob. Usability Engineering. AP Professional, Boston (1993) [2]Riihiaho, Sirpa. Käytettävyystestauksen Muunnelmia. [3]Riihiaho, Sirpa. Käytettävyyden arviointi käyttäjiä. [4]TeamDC. CoSCA Simulaattorin jatkokehitysprojektin Projektisuunnitelma v.1.0 (2005) [5]TeamDC. CoSCA-Vaatimusmäärittely v.1.5 (2005) [6] TeamDC. Laatusuunnitelma v.0.48 (2005) 16

20 LIITTEET Liite 1: Käytettävyystestien t Liite 2: 1. Käytettävyystestitilaisuuden rakenne Liite3: Testautun paperiproto kuvat Liite 4: 1. Käytettävyystestin tuloksia Liite 5: 2. Käytettävyystestitilaisuuden rakenne Liite 6: Heuristisen arvion tarkistuslista Liite 7: Nielsenin heuristiikat (1993) Liite 8: 1. heuristisenarvion tulokset Liite 9: 3. käytettävyystestin etusivu Liite 10: 3. käytettävyystestin ja ratkaisu Liite 11: 3. käytettävyystestin palautelomake Liite 12: 2. Heuristisenarvion tulokset 1

21 Testitehtävät Liite 1 Testitehtävä 1 (Paperiproto) Olet konsulttina kansainvälisessä konsulttitoimistossa ja asiakkaanasi on eräs suuri suomalainen matkapuhelinvalmistaja. Asiakkaasi on palkannut sinut ja tiimisi suunnittelemaan tuotannonohjausjärjestelmäänsä. Olette saaneet ison osan perustyöstä valmiiksi ja tehtaan pohjapiirroskin on olemassa. Tiedät, että tehtaan perusprosessi tulee olemaan ns. liukuhihnamainen (flow job). Koneiden tavoitekäyttöaste on erittäin korkea, niinpä suurimmat kustannukset syntyvät, mikäli prosessi myöhästyy. Aloititte juuri tilausten priorisointisääntöjen suunnittelun. Teillä on tiettyjä oletuksia siitä, miten tilaukset tulevat todennäköisesti jakautumaan ja haluaisitte seuraavaksi testata priorisointisääntöjänne simulaation avulla. Tiedät, että sopiva tarkasteluväli simulaatiolle olisi 1 vuosi. Haluat tarkastella tuloksia jo puolen vuoden jälkeen ja tuolloin vaihtaa priorisointisääntöjä, mikäli koet tähän olevan tarvetta. Olet saanut käsiisi Cosca-järjestelmän, jonka tiedät mahdollistavan tämän tyyppisen simuloinnin. Valitettavasti et ole koskaan aiemmin käyttänyt ohjelmistoa, joten päätät lähestyä järjestelmää sen Wizard-toiminnon kautta. Tehtävä: Luo wizardilla testisimulaatio, joka vastaa mahdollisimman tarkasti asiakkaasi tulevaa tehdasta ja em. ongelmankuvausta. Testitehtävä 2 (Paperiproto) Olet juuri aloittanut työsi ruotsalaisessa paperitehtaassa logistiikka-asiantuntijana. Työtehtävänäsi on ko. tehtaan toimitusketjun hallinta sekä ylä- että alavirtaan. Tehtaanne valmistaa useita erilaisia paperilaatuja. Paperitehtailla on perinteisesti korkeat varastointikustannukset. Vähentääksesi näiden kustannusten vaikutusta, päätät tehdä kokeiluja eri priorisointisäännöillä toimitusketjun osien tehostamiseksi: nykyisellään käyttöaste on eri osissa vain n. 80 % luokkaa. Onneksi työvirta on melko tasainen eikä sisällä satunnaisuutta nimeksikään. Tiedät, että priorisointisääntöjen vaikutus näkyy tällaisessa järjestelmässä melko nopeasti. Suunnitteletkin simuloivasi tilannetta puolen vuoden ajan. Haluat kuitenkin tarkastella osien suoriutumista kuukauden välein; tällöin voit tarvittaessa hienosäätää päätössääntöjä jo kesken simulaation. Yritykselläsi on valitettavasti juuri laajat säästötoimenpiteet meneillään, eikä kalliisiin kaupallisiin toimitusketjusimulaattoreihin haluta investoida. Työkaverisi on kuitenkin suositellut sinulle akateemisesti kehitettyä Cosca-simulaattoria, jolla sinun pitäisi pystyä suorittamaan tutkimuksesi. Olet juuri saanut simulaattorin asennettua ja päätät tehdä ensimmäisen testiajosi käyttäen siihen rakennettua Wizard-toimintoa. Tehtävä: Luo wizardilla testisimulaatio, joka vastaa mahdollisimman tarkasti toimitusketjuanne ja em. ongelmankuvausta. 2

22 Testitehtävät Liite 1 Testitehtävä 3 (Iteraatio 1 loppu) Olet konsulttina kansainvälisessä konsulttitoimistossa ja asiakkaanasi on eräs suuri suomalainen matkapuhelinvalmistaja. Asiakkaasi on palkannut sinut ja tiimisi suunnittelemaan tuotannonohjausjärjestelmäänsä. Olette saaneet ison osan perustyöstä valmiiksi ja tehtaan pohjapiirroskin on olemassa. Tiedät, että tehtaan perusprosessi tulee olemaan ns. liukuhihnamainen (flow job). Koneiden tavoitekäyttöaste on erittäin korkea, niinpä suurimmat kustannukset syntyvät, mikäli prosessi myöhästyy. Aloititte juuri tilausten priorisointisääntöjen suunnittelun. Teillä on tiettyjä oletuksia siitä, miten tilaukset tulevat todennäköisesti jakautumaan ja haluaisitte seuraavaksi testata priorisointisääntöjänne simulaation avulla. Aiotte asettaa kaikille koneille priorisointisäännöksi FCFS:n. Tiedät, että sopiva tarkasteluväli simulaatiolle olisi 24 viikkoa. Haluat tarkastella tuloksia kolmen viikon välein ja tuolloin vaihtaa priorisointisääntöjä, mikäli koet tähän olevan tarvetta. Olet saanut käsiisi Cosca-järjestelmän, jonka tiedät mahdollistavan tämän tyyppisen simuloinnin. Valitettavasti et ole koskaan aiemmin käyttänyt ohjelmistoa, joten päätät lähestyä järjestelmää sen Wizard-toiminnon kautta. Tehtävä: Luo wizardilla testisimulaatio, joka vastaa mahdollisimman tarkasti asiakkaasi tulevaa tehdasta ja em. ongelmankuvausta. Aja luotua simulaatiota tarkasteluväleittäin ja muuta halutessasi päätössääntöjä. Testitehtävä 4 (Iteraatio 1 loppu) Olet juuri aloittanut työsi ruotsalaisessa paperitehtaassa logistiikka-asiantuntijana. Työtehtävänäsi on ko. tehtaan toimitusketjun hallinta sekä ylä- että alavirtaan. Tehtaanne valmistaa useita erilaisia paperilaatuja. Paperitehtailla on perinteisesti korkeat varastointikustannukset. Vähentääksesi näiden kustannusten vaikutusta, päätät tehdä kokeiluja eri priorisointisäännöillä toimitusketjun osien tehostamiseksi: nykyisellään käyttöaste on eri osissa vain n. 80 % luokkaa. Onneksi työvirta on melko tasainen eikä sisällä satunnaisuutta nimeksikään. Tiedät, että priorisointisääntöjen vaikutus näkyy tällaisessa järjestelmässä melko nopeasti. Suunnitteletkin simuloivasi tilannetta 12 viikon ajan. Haluat kuitenkin tarkastella osien suoriutumista viikon välein; tällöin voit tarvittaessa hienosäätää päätössääntöjä jo kesken simulaation. Yritykselläsi on valitettavasti juuri laajat säästötoimenpiteet meneillään, eikä kalliisiin kaupallisiin toimitusketjusimulaattoreihin haluta investoida. Työkaverisi on kuitenkin suositellut sinulle akateemisesti kehitettyä Cosca-simulaattoria, jolla sinun pitäisi pystyä suorittamaan tutkimuksesi. Olet juuri saanut simulaattorin asennettua ja päätät tehdä ensimmäisen testiajosi käyttäen siihen rakennettua Wizard-toimintoa. Tehtävä: Luo wizardilla testisimulaatio, joka vastaa mahdollisimman tarkasti asiakkaasi tulevaa tehdasta ja em. ongelmankuvausta. Aja luotua simulaatiota tarkasteluväleittäin ja muuta halutessasi päätössääntöjä. 3

23 Testitilaisuudenrakenne 1. Käytettävyystesti Liite 2 1 Esittely Ryhmän jäsenten esittely Testattavan käyttöliittymän tarkoituksen esittely Testin esittely; Kuinka edetään jne (esimerkki toimintojen merkitsemisestä). 2 Testitehtävät Testitehtävät annetaan yksitellen kaikille yhtäaikaa. Tehtävä luetaan ääneen sen lisäksi kukin testaaja saa tehtävän paperilla. Uusi tehtävä annetaan kaikille yhtäaikaa. Protolla tehtävät toiminnot kirjoitetaan paperiprotoon. 3 Keskustelua testitehtävistä ja Protosta Käyttäjät kertovat tekemistään ratkaisuista Tarvittaessa kuvataan suunniteltu toimintatapa Mille testi tuntui? Olivatko testi tehtävät ymmärrettäviä? ( Oliko proton käyttö helppoa (arvioi asteikolla 1-3, 1= helppoa, 2=sopiva(ei helppo/ei vaikea), 3= vaikeaa) Jäikö jokin vaivaamaan? Heräsikö kysymyksiä/kommentteja? Oliko käytetty termistö tuttua? Mille asioiden ryhmittely ikkunoissa vaikutti? (arvioi asteikolla 1-3, 1= erittäin hyvä/selkeä, 2=selkeä, 3= ei kovin selkeä) Mille tulosten katseluikkunoissa vaikutti? (arvioi asteikolla 1-3, 1= erittäin hyvä/selkeä, 2=selkeä, 3= ei kovin selkeä) Toiveita? 4

24 Testitilaisuudenrakenne 1. Käytettävyystesti Liite 2 4 Lopetus Lyhyesti mitä tuloksille tehdään, mitä tapahtuu jatkossa Kiitettään osallistumisesta 5

25 Proton kuvat Liite 3 Kuva 1. Systeemin valinta Kuva 2. Työvirran valinta 6

26 Proton kuvat Liite 3 Kuva 3. Kustannusrakenteen valinta Kuva 4. Tarkasteluaikavälin ja tarkistuspisteiden valinta (valikko tarkoituksella avattu) 7

27 Proton kuvat Liite 3 Kuva 5. Flow Shop, päätössäännöt valinta Kuva 6. Tulosikkuna 8

28 Proton kuvat Liite 3 Kuva 7. Flow shop- Flow shop- Job shop, päätössääntöjen valinta Kuva 8. Tulosikkuna 9

29 1. käytettävyystestin tuloksia Liite 4 Kuvat, joihin viitataan ovat liiteessä 3. 1) Systeemin valitseminen (kuva 1) - Yläosan System-> Workfolw-> Costs -> Timeframe, on hyvä ja kuvaava. Hyvä, että näkee ettei tämä ole loputon - Flow Shop ei ole tullut tuttu termi toiselle käyttäjistä, toinen oli kuullut. Mahtuisiko viereen pieni kuva, jossa näkyisi myös se monestako resurssista flow shop koostuu - Supply Chain (two... and...) Ei ole selvä; Mitä tarkoitaa? Tulossivulla erilainen systeemi... - Mitä tapahtuisi Define Own System valinnasta? 2) Työvirran valitseminen (kuva 2) - OK, selvä - Kirjoitusvirhe 3) Kustannusrakenteen valitseminen (kuva 3) - Ok, mutta jäi mietityttämään mitä taphtuu muille arvoille kuin vain valitulle...?? 4) Tarkasteluaikavälin valiseminen (kuva 4) - Kyllä tästä ymmärsi mitä pitää tehdä, mutta olisiko osannut valita jos ei olisi ollut annettua tehtävää, jossa annetaan vinkkiä aikaväleistä? - Hämäävää, mitä tarkoittaa /s -> voisiko lukea vain months? 5) Flow shop Päätössäännönvalinta (kuva 5 ja 7) - Mistä tähän ilmestyi 4 resurssia, en valinnut mistään sellaista? - RUN-nappi mitä siitä tapahtuu? - Scheduling Rule -> Priority Rule - Lyhenteet, ei niitä muista - Mikä on CR+ SPT? - Alareunan Time? Mikä aika? Mitä aikajana kuvaa? Miksi se on 6 kohdalla? Onko tämä simulaatiojakson pituus? 10

30 1. käytettävyystestin tuloksia Liite 4 6) Flow shop tulostentarkastelu (kuva 6 ja 8) - Mitä on PCP ja RPV? - Month 6 aika huomaamaton? Mitä tarkoittaa? Koko ajon pituutta vai tähän mennessä ajettua? Näkyy slideristä paremmin, mutta menee sekaisin, mitä eroa sliderin ja tämän tekstin välillä. - Mihin joutuu jos painaa Back to config? - Start sim...-jatkaako puolesta vuodesta eteenpäin? Miten eroaa End simulation? Ajaako kuukauden kerrallaan - Ilmeisesti sääntöä saa vaihtaa jos tarvitsee? - End simul... -> Finalize? Muita kommentteja - Jotenkin olisi hyvä nähdä pullonkaularesurssit, visuaalisesti (voisiko olla värikoodit?) jos mahdollista. - Painikkeiden (back to config, start simu, end simu) sijainti ei hyvä. Voisiko tulosten katseluikkuna olla ihan omanaan jossa ei ole mitään nappeja ja kaikki mitkä liittyy simulaation ajoon olisi omassaan? - Slider voisi olla vain tulosten tarkastelua varten (miten siitä muuten näkisi mistä kohdasta ajo voi jatkua) - Resursseja ei ilmeisesti voi lisätä kesken ajon (ok)? - Puunnäkymä: siltä varmaan pääsee tarkastelemaan ja muokkaamaan resurssien parametreja - Configuration, on ok, ei tule parempaakaan termiä mieleen - Tulosten esittely graafisesti olisi hyvä juttu - Jos paljon resurseja saisiko niistä listan jota voisi sortata eri tavoin, eli esim. käyttöasteen mukaan? - Proton käyttö: Alku helppoa, loppu osa vaikeampi -> arvio Wizardi-ikkunoiden ryhmittely: Erittäin selkeä -> arvio Tulostenkatseluikkuna: Periaatteessa selvä, lyhenteet ei selviä -> arvio 2, (Testikäyttäjien opiskelut noin puolivälissä 100 ja 130 oparia, kurssi jolle työkalua suunnitellaan on jo suoritettuna). 11

31 Testitilaisuudenrakenne - 2. käytettävyystesti Liite 5 1 Esittely Ryhmän jäsenten esittely Testattavan käyttöliittymän tarkoituksen esittely Testin esittely; Kuinka edetään jne (esimerkki ääneen ajattelusta). 2 Testitehtävät Testitehtävät annetaan testikäyttäjälle kirjallisesti yksitellen Testikäyttäjä lukee tehtävän ensin ääneen Testikäyttäjä kertoo ääneen mitä tekee (ja ajattelee), kun tekee testitehtäviä 3 Haastattelukysymysket Mille testi tuntui? Olivatko t ymmärrettäviä? Millaista ohjelman käyttö oli (arvioi asteikolla 1-3, 1= helppoa, 2= ei helppo/ei vaikea, 3= vaikeaa) Millaista Wizardin käyttö oli? (arvioi asteikolla 1-3, 1= helppoa, 2= ei helppo/ei vaikea, 3= vaikeaa) Mille asioiden/toimintojen ryhmittely Wizardin ikkunoissa vaikutti? (arvioi asteikolla 1-3, 1= erittäin hyvä/selkeä, 2=selkeä, 3= ei kovin selkeä) Mille vaikutti käytetty termistö ja lyhenteet? (arvioi asteikolla 1-3, 1= erittäin hyvä/selkeä, 2=selkeä, 3= ei kovin selkeä) Mille tulosten katseluikkunoissa vaikutti? (arvioi asteikolla 1-3, 1= erittäin hyvä/selkeä, 2=selkeä, 3= ei kovin selkeä) Oliko saadut tulokset ymmärrettäviä? (arvioi asteikolla 1-3, 1= erittäin hyvä/selkeä, 2=selkeä, 3= ei kovin selkeä) Heräsikö kysymyksiä/kommentteja/toiveita? 4 Lopetus Lyhyesti mitä tuloksille tehdään, mitä tapahtuu jatkossa Kiitetään osallistumisesta 12

32 Heuristisen arvion tarkistuslista Liite 6 Heuristisen arvion tarkistuslista Koko ohjelma: 1. Onko Look and Feel sopiva. 1. Pääseekö näppäimistöllä liikkumaan loogisesti (mukaanlukien enter) 2. Onko asemointi ok. a. Fontit b. Kappaleiden sijoittelu c. Nappuloiden sijoittelu d. Nappuloiden toiminta e. Tekstikenttein sijoittelu ym. 3. Ovatko tekstit järkeviä 4. Toimivatko tooltipit oikein 5. Ovatko palautteet riittävät 6. Ovatko poistumiset selkeät 7. Onko käyttäjällä mahdollista tehdä jotain laitonta 8. Puuttuuko jotain olennaista 9. Mitä hyvää ohjelmasta löytyy SimulationFrame: 1. Onko puun rakenne ymmärrettävä 2. Onko Framen rakenne toimiva Koon säätäminen Valikkojen sijoittelu Toiminnallisuuksien löytyminen/sijoittelu 3. Onko system näkymä selkeä 4. Onko report näkymä selkeä Wizard: Voiko käyttäjä hukata Wizard ikkunan 13

33 Nielsenin heuristiikat (1993) Liite 7 Nielsenin kymmenen heuristiikkaa (1993) [1] : 1. Käytä yksinkertaista ja luonnollista dialogia 2. Käytä käyttäjien omaa kieltä 3. Minimoi käyttäjän muistikuormaa 4. Tee käyttöliittymästä kauttaaltaan yhdenmukainen 5. Anna käyttäjälle palautetta toiminnoista 6. Anna selkeä poistumistapa eri tiloista ja toiminnoista 7. Anna käyttäjälle mahdollisuus käyttää oikopolkuja 8. Anna virhetilanteista selkeät virheilmoitukset 9. Vältä virhetilanteita 10. Anna riittävä ja selkeä apu ja dokumentaatio 14

34 Iteraatio I heuristisen arvion tulokset Liite 8 ID Kuvaus Heuristiikka, jota rikkoo Vakavuus Tila Open wizard at startup valinnalla ei ole vaikutusta 2d 1 Wizard next, back ja cancel näppäimet ovat eri kokoisia. 2c 2 Korjattu Wizard ikkuna on resizable 2 2 Korjattu Wizardissa enterillä ei pääse eteenpäin 1 2 Wizardissa ylipitkät tekstit pätkittävä usealle riville 2 1 Korjattu Wizardissa details nappulat system ja costs sivuilla eri kokoiset 2c 1 Muuttunut Wizardissa alivalinnat eri sivuilla siirtyy oikealle ja vasemmalle. 2c 1 Muuttunut Decision rules sivulla teksti alkaa liian alhaalta 2b 1 Korjattu Käynnistäessä (Eclipsestä) focus pääikkunassa eikä wizardissa (onko ikkunan aukaisu/omistussuhde oikein) 9 2 vaikka wizardi auki voi mennä valisemaan jotakin pääikkunan valikoista (sama ongelma kuin edellä) 9 2 Korjattu Details... -panikkeet ei toimi 5 1 Wizardissa siirtymänuolet on epäselvät 1, 5 1 Korjattu Kyseenalaista kuinka selviä (ovatko käyttäjän kieltä) "workflow" vaihtoehtojen kuvaukset/tekstit ovat 2, 10 1 Muuttunut Lisä kommentteja Vaatii lisätyönä mekanismin, jolla ohjelman asetukset tallennetaan kovalevylle. Voi olla, että nappulat poistuvat kokonaan 15