Menetelmädokumentti Käyttöliittymäsuunnittelu

Samankaltaiset tiedostot
Teknillinen korkeakoulu T Tietojenkäsittelyopin ohjelmatyö. Käyttöliittymäprototyypin testaussuunnitelma. Koordinaattieditori

T Johdatus käyttäjäkeskeiseen tuotekehitykseen. suunnitteluprosessissa. Käyttäjän huomiointi. Iteroitu versio paljon kirjoitusvirheitä

Käyttäjäkeskeinen suunnittelu

Käyttöliittymän vaatimusmäärittely. Koordinaattieditori

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

Toteutusvaihe T2 Edistymisraportti

Käytettävyys verkko-opetuksessa Jussi Mantere

Menetelmäraportti Ohjelmakoodin tarkastaminen

SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus

Määrittely- ja suunnittelumenetelmät

Mitä käytettävyys on? Käytettävyys verkko-opetuksessa. Miksi käytettävyys on tärkeää? Mitä käytettävyys on? Nielsen: käytettävyysheuristiikat

SEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant Versio: V0.9

Testiraportti - Koordinaattieditori

Teknillinen korkeakoulu T Tietojenkäsittelyopin ohjelmatyö. Testitapaukset - Koordinaattieditori

Ohjelmiston testaus ja laatu. Testaus käytettävyys

Käytettävyystyön laatu: tarjotaanko oikeita palveluja, tuotetaanko oikeita tuloksia?

Tik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

KÄYTETTÄVYYDEN PERUSTEET 1,5op. Mitä on käyttäjäkeskeinen suunnittelu? Mitä on käyttäjäkeskeinen muotoilu? Pieniä harjoituksia

Testaussuunnitelma Versio Päiväys Tekijä Kuvaus

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Toteutusvaihe T3 Digi-tv: Edistymisraportti

Menetelmäraportti - Konfiguraationhallinta

SEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant Versio: V0.93

Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen

Käytettävyyssuunnittelu. Kristiina Karvonen Käytettävyysasiantuntija Nokia Networks

Käytettävyys tuotekehityksessä mitä pitäisi osata?

Convergence of messaging

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Miten suunnitella hyvä käyttöliittymä?

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

Yhteenvetodokumentti PULSU. Syksy 2008 Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Käyttöliittymän suunnittelu tilastotieteen verkko-opetukseen. Jouni Nevalainen

Linssintarkastusjärjestelmän käyttöliittymän käytettävyyden arviointi

Digi-tv vastaanottimella toteutettavat interaktiiviset sovellukset Selvitys GPL-lisensoinnin tuomat ongelmat

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008

SEPA Heuristinen arviointi

Teknillinen korkeakoulu T Tietojenkäsittelyopin ohjelmatyö. Testitapaukset - Xlet

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Teknillinen korkeakoulu T Tietojenkäsittelyopin ohjelmatyö. Testitapaukset - Siirtoprotokolla

Testaussuunnitelma. Ohjelmistotuotantoprojekti Nero. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

TUTKIMUKSEN LÄHTÖKOHTIA, TOTEUTUS ja HYÖDYT Kalle Saastamoinen Lappeenrannan Teknillinen Yliopisto LTY 2003

WCLIQUE. Ohjelmistoprojekti. Testaussuunnitelma

Testaussuunnitelma Labra

T Käyttäjäkeskeisen tuotekehityksen harjoitustyö kevät 2005

Yhteisöllisen tuotekehyksen avoin verkkolaboratorio. Asta Bäck

T Tietojenkäsittelyopin ohjelmatyö. Testisarja Ray tracing. Tietokonegrafiikka-algoritmien visualisointi. Testisarja Ray tracing

Yhteenveto tutkimusmenetelmien kehittäminen ja evaluointi. Tuomo Kujala Agora Center WUD 2007 Jyväskylä

Kuopio Testausraportti Asiakkaat-osakokonaisuus

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. Testaussuunnitelma D/968/240.20/2017 Tampere3 HR-tietojärjestelmä/käytettävyyssuunnitelma ja - testaus

Onnistunut SAP-projekti laadunvarmistuksen keinoin

T Testiraportti - järjestelmätestaus

Käyttäjätestaus. Mika P. Nieminen Käytettävyysryhmä Teknillinen korkeakoulu. Mika P. Nieminen, TKK 1

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

Newsletter Manager Extensions - Loppuraportin tiivistelmä

Käytettävyystestaus. Henkilökohtainen ohjelmistotuotannon harjoitus. Loppuraportti

Käyttötapausanalyysi ja testaus tsoft


FixUi:n palvelumuotoilupaketit. Ota yhteyttä:

Yhteenveto mittareiden ja laskureiden kehittämistyöstä

Automaattinen yksikkötestaus

TESTIRAPORTTI - VYM JA KANTA Virtuaaliyhteisöjen muodostaminen Versio 1.0

Yhteenvetodokumentti. PLAYOFF Jari Anttila Sanna Fröblom Aarno Sandvik Tommi Paavilainen Miikka Kohijoki. Päivi Pääkkö, ohjaaja

Figure 1: Projektipäälliköt Juha-Pekka Honkavaara ja Juha Mattila

COTOOL dokumentaatio SEPA: Käytettävyystestaus

T SEPA - STAATTISET MENETELMÄT Tuomas Tolvanen, 55382U Timo Töyry, 58578B

Ohjelmistotekniikka - Luento 2

HELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Testaaminen ohjelmiston kehitysprosessin aikana

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Testaussuunnitelma. Pizzeria - Pitseria HAAGA-HELIA ammattikorkeakoulu Tietojenkäsittelyn koulutusohjelma. WebPizza

KÄYTETTÄVYYDEN PERUSTEET 1,5op. Käytettävyyden arviointi paperiprototyypeillä Kirsikka Vaajakallio TaiK

POHJOIS-POHJANMAAN ELINIKÄISEN OHJAUKSEN YHTEISTYÖRYHMÄ Verkko-Ohjaus Marko Kilpeläinen

Käytettävyyden testaus

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Versio Päiväys Tekijä Kuvaus Tikkanen varsinainen versio

SEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: Projekti : AgileElephant

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

HELIA 1 (1) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu :08

$%& & % ' %& %#&& ' ( ) * ( + (, + (, + -

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

TESTIRAPORTTI - XMLREADER LUOKKA Virtuaaliyhteisöjen muodostaminen Versio 1.0

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille

Tik Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset. Riskienhallinta DTV projektissa

Käytettävyyslaatumallin rakentaminen verkkosivustolle

PS-vaiheen edistymisraportti Kuopio

Ryhmäläisten nimet:

Ohjelmistojen mallintaminen. Luento 11, 7.12.

vero.fi: Hankinnasta ylläpitoon Miten varmistaa saavutettavuus?

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Testausraportti. Orava. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Ohjelmistotuotantoprojekti

Kuopio Testausraportti Kalenterimoduulin integraatio

Transkriptio:

Menetelmädokumentti Käyttöliittymäsuunnittelu

Sisällysluettelo 1. Johdanto...3 2. Käytetty kehitysprosessi...4 3. Prosessin vaiheiden erittely...5 3.1. Käyttäjäkartoitus...5 3.2. Vaatimusmäärittely...5 3.3. Paperiprototyyppi...6 3.4. Paperiprototyypin testaaminen...7 3.5. Interaktiivinen prototyyppi...8 3.6. Interktiivisen prototyypin testaaminen...9 4. Johtopäätökset...10 Versio- ja muutoshistoria Versio Päiväys Tekijä Kuvaus 0.1 9.2.2002 Mika Ståhlberg Ensimmäinen luonnos 0.1b 10.2.2002 Tapio Nissilä Pikkukorjauksia katselmoinnin perusteella Tallennettu: 10.2.2002 8:50 Tulostettu: 12.2.2002 11:25 00 Menetelmäraportti: Käyttöliittymäsuunnittelu 2

1. Johdanto Tässä dokumentissa on kuvattu digi-tv ohjelmiin liittyvän koordinaattiinformaation luomiseen tarkoitetun editorin (koordinaatti editorin) käyttöliittymän kehittämisessä käytetty menetelmä tai pikemminkin prosessi. Projektissa kehitettävä editori on käytettävyysvaatimuksiltaan erittäin vaativa, joten projektissa laitettiin suuri painoarvo käyttöliittymän kehittämiselle. Tässä raportissa on viitattu seuraaviin projektin dokumentteihin: [käyttöliittymän vaatimusmäärittely] - v0.3, 10.12.2001 [käyttöliittymän prototyypin testaussuunnitelma] - v0.3, 10.12.2001 [käyttöliittymän paperiprototyyppi] - v0.3, 23.12.2001 Menetelmäraportti: Käyttöliittymäsuunnittelu 3

2. Käytetty kehitysprosessi Kuvassa 1 on esiteltynä projektissa käytetty käyttöliittymän kehittämisprosessi. Prosessi kiteytyy käyttäjähaastattelujen perusteella laadittuun vaatimusmäärittelyyn ja sen pohjalta prototyyppien kautta tapahtuvaan iteratiiviseen kehitykseen. Toimeksianto Käyttäjäryhmät Skenaariot Haastattelut Vaatimusmäärittely Paperiprototyyppi Testaus Vuorovaikutteinen proto Testaus Valmis tuote Kuva 1: Käyttöliittymän kehitysprosessi Menetelmäraportti: Käyttöliittymäsuunnittelu 4

3. Prosessin vaiheiden erittely 3.1. Käyttäjäkartoitus Käyttöliittymän kehittäminen aloitettiin käyttäjistä. Ensimmäiseksi selvitettiin, ketä järjestelmän käyttäjät oikein ovat. Käyttäjiksi hahmottuivat videoeditointia ja sisällöntuotantoa nykytehtävissään tekevät työntekijät. Nämä henkilöt tekevät luovaa työtä, eivätkä he etsi haastetta työkalunsa käyttämisestä toisin kuin insinööreillä on usein tapana. Käyttäjäkartoituksen kanssa rinnan mietittiin projektiryhmässä skenaarioita tilanteita, joissa käyttäjä tuotetta käyttää. Näitä skenaarioita kirjattiin ylös, ja ne luettiin haastateltaville, jotta päästään oikeaan tunnelmaan. Lopulliset jalostuneet skenaariot on kuvattu [Käyttöliittymän testaussuunnitelmassa]. Käyttäjäkartoituksen tavoitteena oli haastatella vähintään kolmea järjestelmän potentiaalista käyttäjää. Todellisuudessa haastattelu tehtiin vain kahdelle tällaiselle henkilölle. Haastatteluihin valmistauduttiin laatimalla kysymyssarjoja. Hankaluutena tämän projektin haastatteluissa oli vastaavan olemassaolevan sovelluksen puuttuminen. Olisi ollut huomattavasti helpompi haastatella kohderyhmien ihmisiä, jos heidän työskentelyään vastaavan tuotteen parissa olisi voinut seurata. Käyttäjien haastatteluissa pyrittiin ennenkaikkea löytämään käyttäjien tarpeita ja tavoitteita, sekä kehittämään tuotteen käyttötilanteita eli skenaarioita. Näin löydettyjä skenaarioita voidaan käyttöliittymän kehittämisen lisäksi myös käyttää tuotteen markkinoinnin ja jatkokehittämisen tukena. Eräänä tärkeänä tavoitteena oli myös käyttäjän termistön selvittäminen, jotta käyttöliittymässä puhuttaisiin käyttäjän kieltä. Käyttäjäkartoituksen haastatteluiden muistiinpanot kirjoitettiin puhtaaksi [Käyttöliittymän vaatimusmäärittelyyn]. Aikataulusta johtuen kartoituksen tulokset jäivät hieman keveiksi, ja vaatimusmäärittelyn laatimisessa täytyi voimakkaasti tukeutua projektiryhmän omiin näkemyksiin tuotteesta ja sen käytettävyydestä. Osin syynä oli jo edellä mainittu vastaavan olemassaolevan tuotteen puuttuminen, osin oikeiden kysymysten löytäminen. 3.2. Vaatimusmäärittely Käyttöliittymälle laadittiin käyttäjähaastettelujen, varsinaisen vaatimusmäärittelyn ja käyttötapausten (use case) perusteella oma vaatimusmääritte- Menetelmäraportti: Käyttöliittymäsuunnittelu 5

lynsä. Tavoitteena oli selvittää perusteet paperiprototyypin laatimiselle. Tarkempina tavoitteina oli 1 : - Selvittää tuotteen käyttäjät ja ryhmitellä heitä - Luoda kuvauksia käyttäjäryhmistä - Luoda skenaarioita todellisista käyttötilanteista - Analysoida tuotteen toimintaympäristöä - Asettaa käytettävyystavoitteet Vaatimusmäärittelyvaihe onnistui käyttöliittymän osalta erittäin hyvin haastattelujen puutteellisuuksista huolimatta. Tästä kertoo se, ettei paperiprototyyppiin tarvinnut testauksen perusteella enää tehdä kovinkaan suuria muutoksia. Samalla käyttöliittymän suunnittelu palveli koko projektia käyttötapausten ja sekvenssikaavioiden työstämistä tukevana kehitysprosessina. 3.3. Paperiprototyyppi Paperiprototyyppi tarkoittaa karkeaa paperilapuille piirrettyä mallia käyttöliittymästä. Testitilanteessa testaaja toteuttaa prototyypin toiminnallisuuden ja logiikan esittelemällä testihenkilölle kulloinkin oikean käyttöliittymänäkymän. Prototyypillä pyritään hankkimaan testattavilta tietoa seuraavista tuotteen ominaisuuksista 2 :? tarvittavat ominaisuudet ja toiminnallisuudet? tehtävien suorittamisjärjestys? käyttäjää tukevien toiminteiden tarve (help, undo, )? käyttöliittymän ulkonäkö ja tuntuma (look and feel) Prototyypin käyttämisen ideana on työn säästäminen. Usein käyttöliittymä suunnitellaan vasta varsinaisen toiminnallisuuden koodaamisen jälkeen, jolloin käyttöliittymä tehdään insinöörien ei käyttäjien ehdoilla. Paperiprototyyppiä käytettäessä on suurienkin muutosten tekeminen käyttöliittymään vaivatonta ja oikeaa ratkaisua on helppo lähteä hakemaan rohkeillakin lähestymistavoilla. Ohjelmointikoodilla toteutettua prototyyppiä ei yleensä haluta aivan pienten käytettävyysasioiden takia lähteä enää muuttamaan ( don t-fix-it-if-it-ain t-broke ). 1 Nieminen, Marko: Käytettävyys vaatimusmäärittelyvaiheessa. Käytettävyysopas, Ohjelmistojen käytettävyys-kurssi, Teknillinen korkeakoulu, 2000. 2 Preece, Jenny (toim.): Human Computer Interaction. Addison-Wesley 1994. ss. 537-594. Menetelmäraportti: Käyttöliittymäsuunnittelu 6

Paperiprototyyppivaihe koettiin varsin antoisaksi, ja se säästi selkeästi ohjelmointityötä. Prototyyppi olisi kuitenkin kannattanut tehdä vieläkin karkeammaksi, sillä osa käyttöliittymän komponenteista piirrettiin kuvankäsittelyohjelmilla. Lyijykynällä piirretyt paperilaput ovat helpon muutettavuutensa takia selkeästi paras vaihtoehto prototyypin työmenetelmäksi. 3.4. Paperiprototyypin testaaminen Paperiprototyyppiä testattiin kolmella käyttäjäryhmiin kuuluvalla henkilöllä ja lisäksi projektiryhmän henkilöt tekivät itsekin testaamista, lähinnä saadakseen yhteisen näkemyksen kehitteillä olevasta tuotteesta. Paperiprototyyppiä testattaessa prototyyppiä kehitettiin jatkuvasti eteenpäin. Muutoksia tehtiin jopa kesken testin ja tarvittaessa palattiin takaisin vanhaan ratkaisuun, jos uusi malli ei toiminut odotetulla tavalla. Videoeditointiohjelmiston testaaminen paperiprototyypillä osoittautui yllättävän vaikeaksi. Videoeditointihan edellyttää liikkuvaa videokuvaa. Käytettävyysongelmista vaikeimmat liittyvät nimenomaan videokuvan liikutteluun eteen- ja taaksepäin, ja tiettyjen kohtien hakemiseen kuvanauhalta. Testattavien täytyi kuvitella videokuva paperiprototyypissä, jolloin testien kautta kehitetyt hallintamekanismit saattavat hyvinkin myöhemmässä vaiheessa osoittautua toimimattomiksi. Erityisen ongelmallista oli kuvavirran hidastaminen ja pysäyttäminen tiettyyn kohtaan tai frameen kuvassa. Tällöin käyttäjä painaisi toistuvasti hidastusnäppäintä kunnes kuvan nopeus on nolla. Tämän simuloiminen paperiprototyypillä on hyvin vaikeaa. Projektissa käytetty testausmenetelmä oli hieman perinteisistä käytettävyystesteistä poikkeava heuristinen arviointi. Heuristisessa arvioinnissa joukko arvioijia tutkii käyttöliittymää ja vertaa sitä yleisesti hyväksyttyihin käytettävyysperiaatteisiin (eli heuristiikkaan). Arvioijia täytyy olla useita, sillä eri henkilöt löytävät aina eri ongelmia ja tutkimukset ovat osoittaneet löydettyjen ongelmien olevan eri ongelmia eri arvioijien kohdalla. Arvioija kertoo ääneen arvionsa käytettävyydestä ja testaaja kirjaa ne ylös. Perinteisessä menetelmässä testaaja antaa testikäyttäjälle tehtävän eikä voi auttaa käyttäjää käyttöliittymän käytössä sen enempää. Tämän jälkeen testaaja kirjaa ylös käyttäjän suoritteet. Heuristisessa menetelmässä käyttöliittymän analysoinnin tekee testikäyttäjä (tässä: arvioija), jolloin testaaja kirjaa ylös jalostetut arviot, ei pelkkiä suoritteita. Lisäksi heuristisessa arvioinnissa testaaja voi vastata arvioijan kysymyksiin ja auttaa häntä ongelmatilanteissa. Menetelmäraportti: Käyttöliittymäsuunnittelu 7

Heuristisen menetelmän etuna on selkeästi perinteisiä menetelmiä parempi kyky arvioida suunnitteluvaiheessa olevan käyttöliittymän käytettävyyttä eli testata paperiprototyyppejä. Ongelmana paperiprototyypeillä on kuitenkin erilaisten virheenestotoiminteiden ja virheilmoitusten testaaminen. Heuristiikassa asetetaan niille suuri painoarvo, mutta niiden testaaminen paperilapuilla vaatii hyvää mielikuvitusta. Projektin heuristiikka on esitelty [käyttöliittymän prototyypin testaussuunnitelmassa] ja se on mukailtu Jakonb Nielsenin esittämistä heuristiikasta 3. 3.5. Interaktiivinen prototyyppi Prototyyppi on olennainen osa iteratiivista käyttäjäkeskeistä suunnittelua, jonka peruselementteinä ovat testaaminen ja prototyypin muokkaaminen 4. Interaktiivinen käyttöliittymäprototyyppi (software prototype) tarkoittaa järjestelmää, joka:? Todellakin toimii, eli se ei ole idea tai piirros? Voidaan rakentaa nopeasti ja helposti (halvalla!) Interaktiivinen prototyyppi tarkoittaa tässä tapauksessa tietokoneohjelmaa, jolla voidaan testata koordinaattieditorin editointiominaisuuksia. Kyseessä ei ole kaikilta ominaisuuksiltaan täydellinen ohjelmisto, vaan ainoastaan käyttöliittymä, jonka taustalla on jotakin näennäistä toiminnallisuutta. Ulkoasultaan ja vasteajoiltaan prototyypin ei tarvitse olla kovinkaan viimeistelty, vaan se voi olla ns. low fidelity prototyyppi. Kuva 2: Paperiprototyypissä kehitetty koordinaattiobjektien luettelo (vas) ja interaktiivisen prototyypin toteutus samasta aiheesta (oik). Vasemmanpuoleinen esitys on puhtaaksipiirretty versio paperiprototyypistä. Varsinainen testauksessa 3 Nielsen, Jakob: Heuristic Evaluation. http://www.useit.com/papers/heuristic/ 4 Preece, Jenny (toim.): Human Computer Interaction. Addison-Wesley 1994. ss. 537-594. Menetelmäraportti: Käyttöliittymäsuunnittelu 8

käytetty paperiptototyyppi kyseisestä luettelosta oli piirretty lyijykynällä keltaiselle post-it paperilapulle. Koordinaattieditorin osalta interaktiivisen prototyypin tulee kyetä videokuvan tai useamman peräkkäisen still-kuvan näyttämiseen. Prototyypin ei kuitenkaan tarvitse tuottaa minkäänlaista toimivaan tietoa, tai omata kaikkia niitä toiminnalisuuksia, joita lopullinen tuote tulee sisältämään. Olisi hyvä, jos interaktiivinen prototyyppi kirjoitettaisiin jollakin nopealla kehitystyökalulla (esim. Macromedia Director) ja siinä käytetty koodi jätettäisiin täysin käyttämättä lopullisessa tuotteessa. Näin prototyypin laatiminen ja iteratiivinen kehittäminen olisi mahdollisimman vaivatonta ja mitään hätäisiä ohjelmointiratkaisuja ei päädy lopulliseen julkistettavaan koodiin. Tämän projektin resurssit ja aikataulu ei antanut periksi edellä esitetylle periaatteelle, vaan interaktiivinen prototyyppi päätettiin kehittää Java-kielellä, kuten myös lopullinen tuote. Näin ollen, tässä projektissa on vaikea tehdä selkeää eroa käyttöliittymän prototyypin ja koko tuotteen alpha-julkaisun välillä. Voidaankin sanoa käytössä olleen menetelmän olevan evolutionäärinen kehittäminen, jossa interaktiivisesta prototyypistä kehittyy lopulta valmiin tuotteen käyttöliittymä. 3.6. Interktiivisen prototyypin testaaminen Tätä raporttia kirjoitettaessa interaktiivisen prototyypin testaamista ja edelleenkehittämistä suoritetaan edelleen. Tähänastisissa testeissä paperiprototyypin kautta löydetyt ratkaisut ovat osoittautuneet varsin toimiviksi myös interaktiivisella mallilla. Interaktiivisen prototyypin testaamisessa käytetään samaa heuristista menetelmää kuin paperiprototyypilläkin. Menetelmäraportti: Käyttöliittymäsuunnittelu 9

4. Johtopäätökset Käyttöliittymän kehittäminen on iteratiivinen prosessi, jossa on selkeäksi eduksi, jos lopullinen kiillotettu tuote kehitetään vasta mahdollisimman myöhäisessä vaiheessa. Tähän pyrittiin projektissa pääsemään kolmen eri vaiheen kautta: 1) Ensimmäiseksi tehtiin pohjatyö kunnolla. Käyttäjähaastattelujen ja käyttötapausten kauttaa laadittiin käyttöliittymälle vaatimusmäärittely. 2) Seuraavaksi käytettiin iteratiivisessa testaamisessa helposti muokattavaa paperiprototyyppiä 3) Ennen loppullista tuotetta testattiin käyttöliittymää ilman kunnollista toiminnallisuutta käyttöliittymän takana. Lopullinen menetelmän onnistuminen nähdään vasta kun tuote on toimitettu asiakkaille projektin päättyessä. Nyt voidaan kuitenkin jo sanoa, että kyseisellä menettelyllä voidaan säästää aikaa ja kustunnuksia, sillä varsinaiseen ohjelmakoodiin thedään minimaalinen määrä testaamisen perusteella vaadittuja käyttöliittymämuutoksia. Suurin osa käyttöliittymätestauksen perusteella löydetyistä puutteista löydettiin jo ennen yhdenkään koodirivin kirjoittamista. Menetelmäraportti: Käyttöliittymäsuunnittelu 10