Käyttäjäkeskeinen vaatimusmäärittelytyö ketterän käyttöliittymäsuunnittelun haasteena, prof. Teknillinen korkeakoulu, tietotekniikan osasto SoberIT Ohjelmistoliiketoiminnan ja tuotannon laboratorio Käytettävyys ja käyttöliittymät http://www.soberit.hut.fi/
Käytettävyys ja käyttöliittymät SoberIT:ssa SoberIT Ohjelmistoliiketoiminnan ja -tuotannon laboratorio: http://www.soberit.hut.fi Vuonna 2000 perustettu Teknillisen korkeakoulun tietotekniikan osaston laboratorio Tutkimus ja opetus soveltavaa tietotekniikkaa, tietotekniikka yritystoiminnan osana Viisi professuuria: tietojenkäsittelytiede (Reijo Sulonen) ohjelmistotuotanto (Tomi Männistö) teollisuuden tietotekniikka (Matti Hämäläinen, Martti Mäntylä vv.) digitaalitalous, ohjelmistojuridiikka (Juha Laine) käytettävyys ()
Esityksen rakenne Johdantoa vaatimusmäärittelyihin ja käyttöliittymän mallintamiseen Mallintamisen syistä ja taustoista Tuotekehityssyklin muuttuminen Moderneista ohjelmistokehitysmalleista Käyttäjäkeskeisen vaatimusmäärittelyn ja käyttöliittymäsuunnittelun haasteet uudessa ohjelmistokehitysympäristössä Käytettävyys strategisen tuotekehityksen välineeksi
Mallien ja mallinnuksen perusteita Relevanttien/oikeiden asioiden esiin nostaminen Asioiden järjestäminen tarkoituksenmukaisella tavalla Kommunikointi Tehokas kommunikointi Semiformaali tai formaali kuvaus käyttöliittymän toiminnasta Formaali mallintaminen HCI-alueella alkanut 1970-luvun loppupuolella (Phyllis Reisner 1977, 1981 (BNF); Embley 1978; Ledgard & Singer 1978)
Mallinnusohjeistoa (Pressman 1987) Kuvauksessa/mallinnuksessa käytettävän esitysmuodon ja sisällön on oltava relevanttia suhteessa tarkasteltavaan ongelmaan Kuvauksessa esitettävän aineiston on oltava kerroksittaista: yleisestä yksityiskohtaiseen tietoon Kerrallaan käytettäviä kuvaustapoja ei saa olla liikaa ja niiden on oltava yhdenmukaisia Kuvausten on oltava helposti muokattavissa Ajatuksena (Reisner 1981): yksinkertaisempi kuvaus johtaa yksinkertaisempaan käyttöliittymään ja helpompaan käyttöön
Vaatimusmäärittelyt (trad.) Vaatimusmäärittelyt kuvaavat yksityiskohtaisesti ne tarpeet, joihin järjestelmän pitää tuottaa ratkaisu Vaatimusten analysointi ja määrittely on alku perinteisen vesiputousmallin mukaisessa suunnitteluprosessissa (Vaatimusten analysointi -> Määrittely -> Suunnittelu (arkkitehtuuri, yksityiskohdat) -> Toteutus -> Integrointi -> Ylläpito) Tiukimmin tulkittuna seuraavaa vaihetta ei aloiteta ennen kuin edellinen vaihe on päättynyt; edelliseen vaiheeseen ei myöskään palata, iteratiivisuus tuo tähän muutoksia Esimerkkejä vaatimusmäärittelyiden rakenteesta löytyy mm. IEEE:ltä (alkaen 830-1984) Ennustava, etukäteen asiat määrittävä ja kiinnittävä lähestymistapa (vrt. adaptiivinen; predictive vs. adaptive)
Ennustava suunnittelu: vesiputousmalli (Royce 1970, Pressman 1987) System System Engineering Engineering BDUF: Big Design Up Front Analysis Analysis Design Design Code Code Testing Testing Maintenance Maintenance
Vaatimusmäärittelyn rakenne (Pressman 1987) Johdanto tavoitteet (toiminta, liiketoiminta), projektin reunaehdot Tietomalli yksityiskohtainen kuvaus ongelmasta, jonka järjestelmä ratkaisee tietovirrat, tietosisällöt, tiedon rakenteet, järjestelmärajapinnat (hw, sw, hci!) Toiminnallinen kuvaus toiminnalliset osat, toimintojen kuvaukset (toimintaselostus, rajoitukset, suorituskykyvaatimukset, suunnittelurajoitukset, kuvaavat diagrammit) Validointikriteerit suorituskyvyn reunaehdot, käytettävät testit, erityishuomiot (Viitteet, liitteet)
Mihin vaatimusmäärittelyjä tarvitaan? Suunnittelu lähtee liikkeelle vaatimusten määrittelystä Perinteisesti vaatimusmäärittelyissä (spesifikaatioissa) pyritään kuvaamaan lopputuloksena syntyvä järjestelmä sellaisella tarkkuudella, että suunnittelijat voivat toteuttaa järjestelmän. Käyttäjät ja asiakkaat allekirjoittavat sopimuksen ja sitoutuvat siten tehtyyn suunnitelmaan. Onko ongelmia? Hankaluuksia helposti ymmärtämättömyyden ja puuttuvan osaamisen vuoksi Vaihtoehtoja massiivisille vaatimusmäärittelydokumenteille: skenaariomuotoiset kuvaukset, paperiprototyypit, iteratiivinen suunnittelutapa
Mallinnustapoja Luonnollinen kieli helppoa kirjoittaa, mutta pitkät ja moniselitteiset kuvaukset joskus hankalia Formaalit ja semiformaalit kielet Kaaviot Formalism in HCI BNF Backus-Naur Form; TAG Task-Action Grammar; GOMS vaikeuksia esim. puurakenteen luontevassa esittämisessä vaikeita myös suorakäyttö-käyttöliittymissä; vaihtoehtoja liikaa kuvattavaksi valikko- ja dialogirakenteen kuvaavat puut siirtymädiagrammit ja tilakuvaukset
Usage-Centered Design: A Model-Driven Process (Constantine & Lockwood 2000: Structure and Style in Use Cases for User Interface Design)
Essential Use Cases (Constantine & Lockwood 2000)
Free-form Scenarios vs. Essential Use Cases (Constantine & Lockwood 2000)
Tuotekehityssyklit nopeutuneet 1980-luku: vuosia 1990-luku: vuosi Esim. TEKES-ohjelma RAPID Tuotekehityksen tehostaminen valmistavassa teollisuudessa 1996-1999 2000-luku: kuukausia Nyt: viikkoja tai jopa päiviä Millaista voi olla käyttäjäkeskeisyyden toteutuminen lyhytkestoisissa projekteissa?
Doing user observations first is wrong I now suggest that for many projects the order is design, then study (D. Norman 2006) ACM Interactions 2006 http://www.jnd.org/dn.mss/why_doing_user_obser.html
Ohjelmistokehityksen ketterä nykyaika Vesiputousmallista (ennustava malli) siirrytty pois Ketterät ohjelmistokehitysmenetelmät valtaavat alaa Adaptiivisuus keskeistä, ennustavuus ei Vaatimukset muuttuvat jatkuvasti, asiakkaat oppivat pyytämään asioita vasta kehittämistyö myöhäisessä vaiheessa Henkilö-, kommunikaatio- ja yhteistoimintapainotukset usein vahvoja Esim. SCRUM: jatkuvasti suunnattavat kehityspyrähdykset XP: koodaus, testaus, kuuntelu, suunnittelu Adaptive software development ASD: spekulointi, yhteinen työstäminen, oppiminen
Normanin uudet teesit Toistuva käytettävyyssuunnittelun taistelu käyttäjätiedon keruusta projektien käynnistyessä: strategian muutos tarpeen Kun projekti käynnistetään, on jo liian myöhäistä tutkia, mitä projektissa pitäisi tehdä ja tuottaa Luovat ja tutkivat osiot toteutettava jo ennen projektin kännistämistä! (Uusi vaatimus projektivalmistelulle ja päätöksenteolle) Saman sovelluksen jatkokehitysprojekteissa ei ole tarpeen toistaa aiemmin tehtyä käyttäjätutkimusta, uutta tietoa voidaan kerätä käytönaikaisesti Projektikohtainen seikkaperäinen käyttäjätutkimus hidastaa projektityötä Ketterään ohjelmistokehitykseen tarvitaan integroitua ketterää käytettävyys- ja käyttöliittymäsuunnittelua: taustoittaminen erikseen, ketterä toteuttaminen yhteistyöllä
Käytettävyyssuunnittelu ja käyttäjätiedon keruu strategisen tuotekehityksen välineeksi Käyttäjätiedon hyödyntäminen ja käytettävyyden huomiointi on tärkeää jo mahdollisimman aikaisessa vaiheessa suunnitteluprosessia: jo ennen projektin käynnistämistä Käyttäjätiedon hyödyntäjiä alkuvaiheessa strategisia tuotelinjauksia määrittelevät päälliköt ja johtajat projekti- ja tuote- ja markkinapositiointipäätösten tukena Käyttäjä- ja käytettävyysdataa kerätään jatkuvasti osana iteratiivisia kehityshankkeita, ei kuitenkaan erillisenä projektin alussa tapahtuvana erillisenä vaiheena Kerättyä dataa hyödynnetään käynnistyvien ja ajallisesti lyhytsyklisten projektien lähtötietoina Projektin toteutuksessa pitää voida edetä nopeasti
Everyone wants us [UI/HCI] on the team, but only if we won t slow down the work. (D. Norman 2006)