AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 10
Dokumentti Historia Revisio Historia Revision Numero Revision Päiväys Yhteenveto muutoksista Revision tekijä 0.9 26.10.04 Ensimmäinen versio Esa Mommo 0.91 28.11.04 I1 vaiheen havainnot lisätty Pauli Vesterinen 0.92 29.11.04 I1 vaiheen havaintoja lisää Esa Mommo 0.93 29.11.04 Yhteenveto I1 vaiheen havainnoista Pauli Vesterinen 0.95 09.01.05 Dokumentin rakennetta muutettu Esa Mommo 0.96 06.02.05 I2 vaiheen tulokset lisätty. Esa Mommo 0.97 08.03.05 FD vaiheen tuloksia lisätty Pauli Vesterinen 1.0 12.03.05 FD vaiheen tuloksien viimeistely ja yhteenveto lisätty. Esa Mommo Hyväksyjät Tämä dokumentti vaatii seuraavien henkilöiden hyväksymiset Nimi Seppo Sahi Tehtävä Mentor Jakelu Tämä dokumentti jaetaan seuraaville henkilöille Nimi Projektiryhmä Tehtävä Aihe: Sivu 2 of 10
Sisällysluettelo 1. Esittely...4 1.1 Tarkoitus...4 1.2 Menetelmän kuvaus...4 1.3 Viittaukset...4 2. Käyttöönotto...5 3. Kokemukset ja muutokset...6 3.1 PP-vaihe...6 3.2 I1-vaihe...6 3.3 I2 -vaihe...7 3.4 FD-vaihe...7 3.5 Yhteenveto...10 Aihe: Sivu 3 of 10
1. Esittely 1.1 Tarkoitus Tämän dokumentin tarkoitus on kuvata AgilElephant projektissa käytettyä SEPA-menetelmää. Menetelmän valinta perustellaan tämän dokumentin luvussa 1, luku sisältää myös menetelmän esittelyn. Luvussa 2 esitellään suunnitelma menetelmän käyttöönotolle. Lukuun 3 kirjataan kokemuksia ja havaintoja menetelmän hyödyistä ja sopivuudesta tämän projektin tarpeisiin. 1.2 Menetelmän kuvaus Käytämämme SEPA menetelmä on heuristinen arviointi (heuristic evaluation), joka suoritetaan järjestelmällisellä katselmoinnilla, jonka avulla pyritään tarkastelemaan käyttöliittymän käytettävyyttä. Arvioinnissa käytetään useita arvioijia, joista jokainen ensin suorittaa arvioinnin yksin ja vasta sen jälkeen arvioijat voivat keskustalla ja koota löydetyt havainnot yhteen. Tällä varmistetaan se että toisten arvioijien löytämät viat eivät vaikuta muiden arviointeihin. Kukin katselmoija kirjoittaa omat havaintonsa arviointitilaisuuden aikana ja yhteenvedon eri havainnoista tekevät tilaisuuden järjestäjät. Valitsimme aiheen jonka tarkoituksena on parantaa tuotteen käytettävyyttä, koska käytettävyys on äärimmäisen tärkeä ominaisuus kehitettävässä järjestelmässä. Käytön helppous vaikuttaa merkittävästi siihen, ottavatko käyttäjät järjestelmän ylipäätään käyttöön. 1.3 Viittaukset Nielsen, http://www.useit.com/papers/heuristic Riihiaho, Käytettävyyden arviointi ilman käyttäjiä Aihe: Sivu 4 of 10
2. Käyttöönotto Heuristinen arviointi suoritetaan projektin aikana kaksi kertaa, vaiheiden I1 ja I2 loppupuolella. Arvioinnin ajankohta määräytyy melkein suoraan siitä miten projekti etenee, koska tarvitsemme ainakin jossain määrin valmiin käyttöliittymän arvioitavaksi. Käytämme arvioinnin suorittamiseen 2 4 henkilöä riippuen siitä miten katselmoijia on saatavilla. Pyrimme käyttämään katselmointiin projektin ulkopuolisia henkilöitä, mutta jos tarvittavaa määrää ulkopuolisia ei ole käytettävissä niin voimme siinä tapauksessa käyttää katselmoijina myös projektiryhmän jäseniä. Nielsen suosittelee optimaaliseksi määräksi katselmoijia 4 henkilöä. Ennen varsinaista katselmointitilaisuutta järjestetään perehdyttämistilaisuus, jossa katselmoijille esitellään lyhyesti järjestelmä ja selitetään mihin sitä on tarkoitus käyttää. Lisäksi kerrotaan miten heidän tulee toimia katselmointitilaisuudessa, mm. miten havainnot kirjataan ylös ja mihin asioihin on erityisesti kiinnitettävä huomiota. Perehdyttämistilaisuuden kesto on noin 30 minuuttia. Katselmointitilaisuus järjestetään jossain rauhallisessa paikassa, missä kaikki katselmoijat pääsevät ensin yksin mutta samanaikaisesti perehtymään käyttöliitymään. Yksin suoritettavan arvioinnin aikana katselmoijat eivät saa kommunikoida keskenään, tämän osuuden kesto on noin 1 tunti. Välittömästi tämän jälkeen järjestetään keskustelutilaisuus, jossa eri katselmoijat voivat vaihtaa mielipiteitä ja havaintoja järjestelmästä, lisäksi havainnot kootaan yhteen. Aihe: Sivu 5 of 10
3. Kokemukset ja muutokset Aikataulu syistä johtuen jouduimme I1 vaiheessa hiukan modifioimaan heuristisen arvioinnin suoritustapaa. Kun alun perin oli tarkoitus suorittaa arviointi yhdessä tilaisuudessa, jossa olisivat mukana kaikki arvioijat, mutta sen sijaan jouduimme suorittamaan kaksi erillistä arviointitilaisuutta ja kokoamaan itse yhteen saadut arviot tuotteen käytettävyydestä. Sovimme että käytämme I2 vaiheen lopussa arvioinnissa SoberIT tutkijoita, jotta saisimme arvioijiksi sellaisia henkilöitä joilla on ymmärrystä ja kokemusta ketteristä menetelmistä ja vielä tarkemmin SEMS menetelmästä. Aikataulujen yhteensopimattomuuden vuoksi jouduimme kuitenkin siirtämään tämän katselmointi tilaisuuden seuraavan vaiheen puolelle, mutta katsoimme kuitenkin asiantuntemuksen tarpeen arvioijille niin tärkeäksi, että päätimme hyväksyä tämän muutoksen ja todeta että I2 vaiheessa keskityimme lähinnä seuraavan katselmointitilaisuuden suunnitteluun. 3.1 PP-vaihe Projektin suunnittelu vaiheessa käyttöliittymä-arviointia on huomattavan hankalaa suorittaa, joten tässä vaiheessa voi ainoastaan tehdä suunnitelman arvioinnin tekemiseksi. 3.2 I1-vaihe Käytettävyyttä arvioitiin I1-vaiheessa tehdyn HTML prototyypin avulla. Esan suorittamassa arviointitilaisuudessa oli kaksi arvioitsijaa, molemmat systeemisuunnittelijoita, heistä toisella ei ollut lainkaan kokemusta ketteristä menetelmistä ja toisella oli jonkin verran kokemusta, lähinnä pariohjelmoinnista. Kummallakaan arvioijista ei ollut luonnollisestikaan mitään tietoa SEMS järjestelmästä. Johtuen arvioijien taustasta aluksi pyrittiin käymään ketterien menetelmien ja SEMS järjestelmän pääpiirteet yleisellä tasolla läpi, minkä jälkeen kerroin arvioijille hiukan AgilElephant järjestelmästä. Lisäksi kerroin arvioijille, että heidän pitää löytää nimenomaan käytettävyyteen liittyviä ongelmia. Perehdyttämistilaisuus kesti noin 30 minuuttia ja itse arviointi havaintojen keräämisineen kesti myös noin 30 minuuttia, eli koko tilaisuuden kesto oli noin 1 tunti. Arviointitilaisuudessa annoin myös hiukan vinkkejä siitä mitä pitäisi tehdä, vaikka sellainen ei periaatteessa kuulu heuristiseen arviointiin. Arviointitilaisuudessa tehdyt havainnot(monet havainnot yhteenvetoja useasta samankaltaisesta havainnosta): - järjestelmä vaikuttaa sekavalta - missä on kehitettävä(t) tuote/tuotteet? - käsitteet epäselviä (Esa kommentti: ymmärrettävää ko. perehdyttämisellä) - miksi toiminnot(actions) ovat omassa laatikossaan - miten näkee tuote backlogissa olevat aiheet(item) - missä ovat release backlogissa olevat aiheet(item) Pauli järjestämässä arvioinnissa oli yksi arvioija, jolla ei ollut aiempaa kokemusta ohjelmistokehityksestä. Myöskin SEMS ja ketterät kehitysmenetelmät olivat uusia asioita. Tältä pohjalta pidetyssä perehdyttämistilaisuudessa tutustuttiin ketterien menetelmien tarkoitukseen ja käyttöön sekä AgilElephant -systeemiin. Aikaa kului opiskeluun noin 25 minuuttia. Varsinaiseen arviointiin kului noin 35 min, jolloin kokonaisajaksi tuli tunti. Myöskin itse arvioinnin aikana piti arvioijalle selittää käsitteitä ja käyttötarpeita, johtuen arvioijan taustasta. Seuraavassa lista havainnoista käyttäjältä: - Keltainen on huono väri, näkyy huonosti (prioriteetti) Aihe: Sivu 6 of 10
- Jokaisella sivulla olevat laatikot pitäisi olla suhteutettuja toisiinsa, ei silmäänpistäviä porrastuksia laatikoiden välillä. esim actions-laatikon ja päälaatikon alareunojen välinen porrastus, tyhjää tilaa liikaa alareunassa - Visuaalisesti ankea = visuaalisesti yksinkertainen. Muutenkin esim. voisi miettiä fonttien kokoja, itse fontti on kuitenkin selkeä - Actions-laatikon merkitys? Miksi asiat omassa osassaan? - Tietojen muokkaaminen; esim. item:n muokkauksessa jokaisen rivin lopussa edit -nappi tai rasti ruutuun ja muokkaa jolloin voi siis valita, mitä riviä haluaa muokata (samalla lailla kuin movejuttu ). - Timeline-listan laatikkoon on ahdettu paljon asioita pieneen tilaan, selkeämmäksi! Miksi ei voi käyttää sivun tilaa, kun sitä kerran on? Yhteenvetona tehdyistä arviointitilaisuuksista voidaan todeta, että arvioijat pitivät järjestelmää hiukan sekavana ja visuaalisesti ankeana mm. tietyt värit fonteissa näkyivät huonosti. Arvioijat kaipasivat erityisesti kehitettäviä tuotteita, niitä kun ei tuntunut löytyvän mistään. Toimintojen(Actions) kokoamista yhteen erilliseen ikkunaan vierastettiin myös jonkin verran ja se myös koettiin hankalaksi käyttää, toivottiin mieluummin esim. editointi -näppäimiä. Järjestelmässä olevien ikkunoiden informaation sullomista pieneen tilaan pidettiin myös huonona ratkaisuna eli toivottiin ilmavuutta järjestelmään. Noin yleisesti voidaan pohtia, onko järkevää lähteä suorittamaan heuristista arviointia näin varhaisessa vaiheessa projektia prototyypin avulla. Mutta tulimme kuitenkin siihen tulokseen, että mitä aikaisemmin käytettävyyden ongelmat havaitaan, sitä nopeammin ne ovat ratkaistavissa. Tässä nimenomaisessa arviointikierroksessa suurimpia ongelmia olivat aikataulu, emme pystyneet järjestämään yhtä ainoaa arviointitilaisuutta, arvioijien kokemattomuus ketterien menetelmien osalta sekä arvioitavan prototyypin keskeneräisyys. 3.3 I2 -vaihe Aikataulujen yhteensopimattomuuden vuoksi I2 vaiheen katselmointitilaisuus siirrettiin seuraavan vaiheen alkuun. Tässä vaiheessa lähinnä tehtiin suunnitelma seuraavan vaiheen arviointitilaisuuteen. Suunnitelma katselmointitilaisuuteen: - kaksi katselmoijaa, SoberIT:n tutkijoita (Jarno Vähäniitty ja Kristian Rautiainen) - katselmoinnissa keskitytään käytettävyyteen mutta arvioijat saavat ottaa kantaa myös ohjelman toimitaan muultakin kannalta (arvioijien asiantuntemusta kannattaa käyttää hyväksi) - käytetään bannedwagonilla olevaa ohjelmaversiota - tilaisuuden kesto 1 tunti - järjestelmään perehdyttäminen, 10 minuuttia - arvioijien itsenäinen järjestelmään tutustuminen, 20 minuuttia - keskustelu ja havaintojen kirjaaminen, 20 minuuttia - lisäksi jätetään 10 minuuttia ns. pelivaraa Yleisesti on huomattava, että yksi tunti on sangen lyhyt aika heuristisen käytettävyyden arviointiin. Mutta koska järjestelmämme on kuitenkin suhteellisen kompakti, niin uskomme että tilaisuus on suoritettavissa yhden tunnin aikana varsinkin jos pyrimme tiukasti pitämään agendasta kiinni. 3.4 FD-vaihe I2 -vaiheesta siirretty heuristinen arviointitilaisuus suoritettiin projektin viimeisen iteraation eli FD -vaiheen alussa, jolloin järjestelmässä jo oli suhteellisen paljon toiminnallisuutta valmiina käyttöliittymätasolla ja Aihe: Sivu 7 of 10
heuristisesta arvioinnista oli saatavissa suurin hyöty. Tilaisuuteen saatiin arvioijiksi asiantuntijat juuri SEMS -projektin parista, sillä toinen arvioijista, Kristian Rautiainen, on yksi SEMS -mallin kehittäjistä ja Jarno Vähäniitty on hänkin ollut läheisesti mukana ja seurannut SEMS:n kehitystä tuntien siksi hyvin ketterän ohjelmistokehityksen projektinhallinnan tarpeet. Itse tilaisuus pidettiin 11.2.2005. Tilaisuuteen oli osallistujien tiukkojen aikataulujen mukaisesti varattu aikaa tasan tunti, mikä osoittautui aivan liian vähäiseksi. Järjestelmän esittelyyn ei tarvinnut käyttää aikaa muutoin kuin käyttöliittymätasolla, sillä molemmat arvioijista tunsivat termit ja konseptin hyvin. Lyhyen esittelyn jälkeen herrat alkoivat käyttää järjestelmää kumpikin omilla tietokoneilla samalla muistiinpanoja kirjaten. Tähän vaiheeseen aikaa kului noin 25 minuuttia, jonka jälkeen loppuaika keskusteltiin ja vertailtiin havaintoja. Koko tilaisuuteen varattu aika, yksi tunti, on aivan liian lyhyt tämänkaltaiseen toimintaan. Mikäli arvioijat eivät olisi tunteneet konseptia etukäteen, olisi pitänyt esittelyyn käyttää aikaa huomattavasti enemmän mikä olisi vienyt itse järjestelmän käyttämiseltä aikaa. Nyt herrat ehtivät vasta hieman syvällisemmin tutustua eri toiminnallisuuksiin, kunnollisen arvioinnin suorittamiseksi järjestelmän käyttämiseen olisi hyvä varata aikaa vähintään tunti. Tällöin olisi ehtinyt saada paremman kuvan koko järjestelmän logiikasta ja eri tasoista järjestelmässä. Ajanpuutteesta huolimatta tilaisuus oli onnistunut ja saimme hyvää palautetta ja huomioita kummaltakin osallistujalta järjestelmän toiminnallisuuden ja käytettävyyden parantamiseksi. Jarno Vähäniityn kirjoittamat muistiinpanot järjestelmästä ovat seuraavat: - Reports ja Users erityyppisiä olioita kuin Portfolio, Products ja Home. Olisi hyvä järjestellä linkit loogisiksi kokonaisuuksiksi menu -laatikossa o Home :lle voisi löytyä kuvaavampi nimi, liittyen siihen, mitä siinä itseasiassa näkyy o Logout myös eri tyyppinen kuin add new / search for backlog items - Portfolio -näkymässä erityyppisiä portfolioita voisi erottaa toisistaan, kuten valmiina olevat All releases ja Near-by releases - Voisi auttaa, jos Portfolio -näkymässä jollain tavalla indikoitaisiin minkä tyyppinen olio eri itemi on. Normaalissa käyttötilanteessahan erot ehkä ovat selkeämmät - Create new portfolio => relative start date :n merkitys jää epäselväksi - Kysymys: onko product key = product ID? - Backlog itemeitä lisättäessä voisi jollakin älykkäällä tavalla valita oletusproductin. Tämä varmaan pätee myös muihin vastaaviin tilanteisiin hierarkiassa. - Onko assignee = responsible? Lienee hyvä syy miksi jälkimmäistä ei ole käytetty? - Backlogs -valinta tuntuu samantyyppiseltä kuin Product, mutta siinä ei dropdown -listaa? Johtunee siitä, että voi kuulua vain yhteen productiin. (Tekijöiden huomautus: Ei dropdown-listaa, sillä pitää voida valita useampia yhtä aikaa.) - Autoadjust remaining effort kuulostaa pelottavalta valinnalta, en tiedä saisiko sitä antaa tehdä, riippuu mitä tarkoittaa - Tabitusjärjestystä määrittelemällä pystyisi nopeuttamaan näppäimistön hyötykäyttöä. Esim. Tyypillisesti käyttäjän vois kuvitella haluavan hypätä johonkin actioniin aina kun klikannut jollekin vasemman puolen vaihtoehdoista, jolloin tabijärjestys vaihtuisi siten, että kun painaa tabia niin valinnat alkaisivat actions -valikosta - Hieman epäselväksi jäänyt teksti käyttöohjeessa: Portfolio is a view to the system that concludes certain time, certain products and certain work types. It can be one users own or also visible to all other users. Kristian Rautiaisen havainnot järjestelmästä ovat seuraavat, lisäksi on hyvä huomata että Kristian suoritti järjestelmän testausta vielä jonkin aikaa katselmointitilaisuuden jälkeenkin: - Preferences outo: Vain joku release types (+ actioneissa jotain pientä) - Olen täysin Jarnon kannalla menun ryhmittämiseen liittyvissä asioissa. Nyt omenat ja päärynät sekaisin, mikä hieman hämää käyttäjää. - Effort Reportissa Query näyttää Kaarlaksen, vaikka Rautiainen valittu. Filtteröintiä ei siis ole vielä toteutettu? - Onko description kentässä tahallaan eri fontti? - RuntimeException; nested exception is: java.lang.illegalargumentexception: Cannot change status from 100 to 200 in backlog of type 1 (kun teki ChangeItemStatus to Open, In-Progress toimi, mutta kun sen jälkeen valitsi uudelleen In-Progress + Save tuli samankaltainen virhe) Aihe: Sivu 8 of 10
- Item statuksessa on hämäävää, että lukee 'new'. Kun sitten valitsee sen 'Open' se on itse asiassa sama status (koska se kaatui). Ei voi käyttää kahta eri termiä! - Kommentointitoiminto on kiva, mutta pienellä näytöllä voi helposti kadota sivun alalaidan alle, jolloin jää huomioimatta - Date-muoto epäselvä, eikä virheviesti kerro mikä formaatti pitäisi olla. On yleensä nopeampaa tehdä käsin kuin avata kalenteri. - Relative luvut kalenterin kohdalla epäselvät. - Kalenteri hyppää vuoteen 2015 release end daten kohdalla. - Hieman epäselvää, miten ja missä release pitää luoda. Kyllä se pitäisi pystyä luomaan tuotteen alla actionina (jolloin automaattinen linkitys kyseiseen tuotteeseen, eli paljon loogisempaa, etenkin jos roolina tuotepäällikkö). Meni vähän aikaa löytää. Kun release on luotu, iteraation luominen on sitten jo helpompaa (ja loogista) - Haku ei löydä mitään... - Näin nopealla tahdilla luodun BacklogItemin löytäminen jälkikäteen vaikutti hankalalta (varsinkin, kun haku ei toiminut). Käytettävyyden kannalta olisi hyvä, jos jossain olisi valikko, joka listaa kaikki itemit, joita sitten voi luodussa näytössä filtteröidä mielensä mukaan. - On huonoa, että effort estimation voidaan luoda vain silloin, kun backlogitem luodaan (puhumattakaan siitä minuuttien syöttämisestä...). Jos tehdään Product backlog -tasoinen item, eihän silloin välttämättä ole hajuakaan siitä, mikä se effort tulee olemaan. Ainakaan en löytänyt paikkaa, jossa pääsisi editoimaan effort estimationia muuten kuin kuittaamalla tehtyjä tunteja ja antamalla uuden arvion. - Miksi iteraatiossa näkyy effort(hours) = 0.0, vaikka kyseiseen iteraatioon on luotu yksi backlogitem, jonka effort on 1 hour? Onko iteraation effort laskennallinen kalenteriaika? Silloin joka tapauksessa pitäisi näkyä yhden päivän iteraatiolle (jonka loin) 8 tuntia. Jos iteraation effort = iteration members (oliko niitä vai vain release members?) arvioitu osallistuminen, se ei välttämättä aukene tai ole looginen. - Kaiken kaikkiaan jäi hieman sekava kuva AgilElephantista. Käytettävyys olisi pitänyt huomioida jo aikaisemmin ja koko juttu suunnitella selkeämmistä käyttötapauksista, esim. eri roolien kautta "normaalia käyttöä simuloimalla". - Tuli virheviesti, kun kirjasin iteraation effortia (käyttäjälle tosin epäselvää, että hän on tekemässä juuri tätä, mutta päättelin error messagesta), laitoin itse lasketun jäljellä olevan arvion ja jätin kuitenkin automatically adjust päälle ja painoin update (se myös jäi päälle itemin T2: Blaa kohdalle... jos painaa 'View, edit, log...' niin pääsee samaan virheilmoitukseen suoraan takaisin): type Exception report message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.jasperexception j root cause org.apache.jasper.servlet.jspservletwrapper.service(jspservletwrapper.java:372) org.apache.jasper.servlet.jspservlet.servicejspfile(jspservlet.java:292) org.apache.jasper.servlet.jspservlet.service(jspservlet.java:236) avax.servlet.http.httpservlet.service(httpservlet.java:810) org.jboss.web.tomcat.filters.replyheaderfilter.dofilter(replyheaderfilter.java:75) java.lang.nullpointerexception......... note The full stack trace of the root cause is available in the Apache Tomcat/5.0.28 logs. Aihe: Sivu 9 of 10
3.5 Yhteenveto Yleisesti voi sanoa että varsinkin alkuvaiheessa meillä oli hiukan epäilyksiä siitä kuinka hyödyllistä heuristinen arviointi ylipäätään on tämänkaltaisessa projektissa. Mutta täytyy rehellisesti tunnustaa että arviointi olikin yllättävän antoisaa tekemistä ja siitä oli saatavissa myös selkeää hyötyä projektille. Luonnollisesti ja ensisijaisesti keskityimme käytettävyyden ongelmiin, mutta varsinkin asiantuntijaarvioijilta saimme paljon myös toiminnallisuuteen liittyviä neuvoja ja palautetta. Mutta myös ns. amatööriarvioijilta saimme myös hyvää ja ansiokasta palautetta ennen kaikkea käytettävyyden kannalta. Heuristisen arvioinnin hyöty on ennen kaikkea siinä että saadaan ulkopuolisilta tahoilta näkemystä ja havaintoja järjestelmän toimivuudesta suunniteltuun tarkoitukseen. Usein käy niin että tekijät ikään kuin sokeutuvat omille tavoilleen ratkaista ongelmia ja ne näyttävät aivan järkeviltä ja luonnollisilta, mutta henkilö joka ei ole niin syvällä mukana projektissa voi nähdä asiat toisin. Suurin saatu hyöty heuristisesta arvioinnista oli käytettävyyden puolella. Saadun palautteen perusteella pystyimme ryhmittelemään järjestelmän eri valintoja loogisemmiksi ja helpommin käytettäviksi kokonaisuuksiksi. Myös eri värien käyttöön saimme arvokasta palautetta ja pystyimme muuttamaan niitä toivottavasti enemmän kaikkien käyttäjien silmää miellyttävään muotoon. Käsitteitä ja termejä pystyimme myös yksinkertaistamaan ja harmonisoimaan saamamme palautteen perusteella. Lisäksi asiantuntijaarvioijat löysivät myös toiminnallisuuteen liittyviä bugeja, joita pystyimme ja ehdimme jossain määrin korjaamaan. Ylipäätään voimme todeta että heuristinen arviointi onnistui sangen hyvin, saimme paljon arvokasta palautetta ja sitä myös käytettiin järjestelmän toiminnallisuuden ja käytettävyyden parantamiseen. Suurimmat ongelmat olivat lähinnä ensimmäisessä arviointitilaisuudessa arvioijien löytäminen ja toisessa tilaisuudessa tilaisuuden kesto (1 h), joka oli aivan liian lyhyt tämänkaltaiseen toimintaan, jotta maksimaalinen hyöty olisi ollut saatavissa. Ensimmäisissä arviointitilaisuuksissa 1 tunti oli aivan riittävä aika kun arvioitavana oli vain HTML proto, mutta toisessa tilaisuudessa se osoittautui liian lyhyeksi järjestelmän toiminnallisuuden kasvamisen myötä, kuten edellä onkin jo mainittu. Vastaisuuden varalle voimme lämpimästi suositella tämän kurssin tekijöille ja muillekin heuristisen arvioinnin käyttämistä järjestelmien toiminnallisuuden ja käytettävyyden parantamiseen. Aihe: Sivu 10 of 10