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

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

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

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

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

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

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

SEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2

Sonera Viestintäpalvelu VIP VIP Laajennettu raportointi Ohje

COTOOL dokumentaatio SEPA: Käytettävyystestaus

Käytettävyys verkko-opetuksessa Jussi Mantere

Testaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant

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

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Opiskelijoiden HOPSit

Testaussuunnitelma. Dokumentti: Testaussuunnitelma.doc Päiväys: Projekti: AgileElephant Versio: V0.4

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

Visma.net Approval. Versiosaate 1.40

KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0

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

SEPA PÄIVÄKIRJA HEURISTINEN ARVIOINTI. Eero Kallio 54942R Ilkka Terho 57643U Kaarlo Lahtela 61439P

Ponnahdusikkunoiden ja karttatekstien hallitseminen ArcGIS Online kartoissa

Suomi.fi: Asiointi ja lomakkeet osion käyttöliittymämallien käyttäjätestaus. Testaustulosten esittely

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

1. ASIAKKAAN OHJEET Varauksen tekeminen Käyttäjätunnuksen luominen Varauksen peruminen... 4

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

Suvi Junes/Pauliina Munter Tietohallinto/Opetusteknologiapalvelut 2014

Suvi Junes/Pauliina Munter Tampereen yliopisto / tietohallinto 2014

Solve laskutus Sivu 1

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

Laatija: Staria Oyj Ostolaskujen käsittelyohje versio 0.1 Hyväksyjä: Jukka Suonvieri OSTOLASKUJEN KÄSITTELY

RockID-varastonhallintajärjestelmän käyttöohje. v. 1.0

Kuva: Ilpo Okkonen

Visuaalinen käyttöliittymäanalyysi

Pikatreffit. Pikatreffien kuvaus

Esittely. Muistathan, että voit myös käyttää Petsietä aivan normaalina käyttäjänä kasvattajapalveluiden lisäksi. Antoisaa Petsien käyttöä!

Testausraportti. Dokumentti: Testausraportti_I2.doc Päiväys: Projekti : AgileElephant

Santeri Saarinen Korjattu testaustasoja ja tehty tarkennuksia I1-testaukseen

YRITYSTILI KÄYTTÖOHJEET

TAMK Ohjelmistotekniikka G Graafisten käyttöliittymien ohjelmointi Herkko Noponen Osmo Someroja. Harjoitustehtävä 2: Karttasovellus Kartta

Doodle helppoa aikatauluttamista

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

Asiakas ja tavoite. Tekninen toteutus

Ohje 1 (12) Maarit Hynninen-Ojala MOODLE PIKAOHJE. Kirjautuminen Moodleen ja työtilan valitseminen

Uskalla kokeilla -työpaja Agenda ja tehtävät

Testausraportti. Dokumentti: Testausraportti_FD.doc Päiväys: Projekti: AgileElephant

PROJEKTIN OHJAUS JA SEURANTA JOUNI HUOTARI

ProCountorin asiakastyytyväisyyskysely 2009

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

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

Maastotietokannan torrent-jakelun shapefile-tiedostojen purkaminen zip-arkistoista Windows-komentojonoilla

1 eportfolio Kyvyt.fi - palvelun käytön aloittaminen

Scrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.

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

T Tietojenkäsittelyopin ohjelmatyö

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

Jos luet viestin mieluummin selaimella, klikkaa tästä. Autoilija- ja kuljettajatiedote $times tamp-j.n.y$ 1/5

AgilElephant - Projektisuunnitelma. Dokumentti: projektisuunnitelma.doc Päiväys: Projekti : AgileElephant Versio: V1.8

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

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

Käyttäjäkeskeinen suunnittelu

Aktivoi dokumentin rakenteen tarkistamiseksi piilomerkkien näyttäminen valitsemalla valintanauhasta Kappale-kohdasta painike Näytä kaikki.

Laadunvarmistuksen suunnitelma. Ryhmä ExtraTerrestriaLs Aureolis Oy

Opiskelijoiden HOPSit

Google-työkalut: Dokumenttien jakaminen ja kommentointi

Kiipulan ammattiopisto. Liiketalous ja tietojenkäsittely. Erja Saarinen

3. VäI~raportti. FU [ta. Kemin toimeksianto 48912/F Raportointi ajanjaksolta V~puv~i~ta. Eu~oap~rn W~O~i ~ur~x~p~rn Lha~t~

Nuorten hyvinvointi tilastotietokannan käyttöohjeet Tieke

Työssäoppimisen lomake Wilmaohje Turun ammatti-instituutti Sami Mäkelä

1 Kirjautuminen ja Käyttöliittymä Kirjautuminen Käyttöliittymä Uuden varauksen tekeminen Normaali varaus...

WinOodin käyttö VDI-ympäristössä

Hotline-jäsenpalvelun käyttöohjeet

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

Ohje kehitysympäristöstä. Dokumentti: Ohje kehitysympäristöstä.doc Päiväys: Projekti : AgileElephant

SYMBIANIN SERIES 60 JA PUHELIMEN PERUSTOIMINNOT

Ohjeet psykoterapeuteille

Pikaopas. The New Black. Kesäkuu Datscha Pikaopas The New Black ( ) 1 (14)

Hops-ohjaajan ohje Opiskelijan hopsit.

TIETOKONEEN ASETUKSILLA PARANNAT KÄYTETTÄVYYTTÄ

1. Valitse suunniteltu valmistumisvuosi alasvetovalikosta ja tallenna valinta. 2. Luo uusi HOPS painikkeella pääset tekemään HOPSia.

Käytettävyyslaatumallin rakentaminen verkkosivustolle

Ohjeistus yhdistysten internetpäivittäjille

M2 MATKALASKUOHJE KANSALAISOPISTON TUNTIOPETTAJALLE

TTS kannattavuuslaskentaohjelma

Helsingin ammattikorkeakoulu Stadia Verkkosivujen silmäiltävyys ja selailtavuus v. 0.9 > 80 % % % < 50 %

COTOOL dokumentaatio Testausdokumentit

e-opin sä hkö isten öppikirjöjen kä yttö ö nöttö Läppeenrännän Pedä.netöppimisympä

Seutudokumenttien pä ivittä misohje

Dokumentti: projektisuunnitelma.doc Päiväys: Projekti : AgileElephant

Toiminta ennen ensimmäistä ottelua (1/2)

VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D

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

SEPA Heuristinen arviointi

Hirviö Testausraportti I2

Sähköpostitilin käyttöönotto

Tiedostojen toimittaminen FINASiin 1(7)

1 KR-Laskut Mallitiliöinnit Kommenttikentän käyttö mallitiliöinneissä Mallitiliöinnin tallennus-sivu...

Verkkokirjoittaminen. Anna Perttilä Tarja Chydenius

Projektin loppuraportti. Dokumentti: loppuraportti.doc Päiväys: Projekti : AgileElephant

ArcGIS Pro -ohjelmiston käyttöönotto. Ohje /

Google-dokumentit. Opetusteknologiakeskus Mediamylly

Transkriptio:

AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 8

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 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 8

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...8 Aihe: Sivu 3 of 8

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 8

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 8

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 8

- 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 Ynnä muuta tekstiä. Aihe: Sivu 7 of 8

3.5 Yhteenveto Tekstiä. Aihe: Sivu 8 of 8