SALLA HEINÄNEN KÄYTTÄJÄKESKEINEN SUUNNITTELU INTRANETPROJEKTISSA

SALLA HEINÄNEN KÄYTTÄJÄKESKEINEN SUUNNITTELU INTRANETPROJEKTISSA Diplomityö Tarkastajat: professori Kaisa Väänänen-Vainio-Mattila ja professori Tommi Mikkonen Tarkastajat ja aihe hyväksytty Tietotekniikan osastoneuvoston kokouksessa 11. joulukuuta 2006

II TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan koulutusohjelma HEINÄNEN SALLA: Käyttäjäkeskeinen suunnittelu intranetprojektissa Diplomityö, 72 sivua Joulukuu 2007 Pääaine: Käytettävyys Tarkastajat: professori Kaisa Väänänen-Vainio-Mattila ja professori Tommi Mikkonen Avainsanat: Intranet, toiminnallinen määrittely, käyttäjäkeskeinen suunnitteluprosessi, Contextual Design, Goal Directed Design, Rational Unified Process, ISO 13407 Intranetit ovat suljettuina verkkoina mielenkiintoinen suunnittelukohde, koska käyttäjäryhmä on tarkasti tiedossa, mutta liikesalaisuuksien vuoksi niiden vertailu on vaikeaa. Hyvä intranet säästää käyttäjänsä aikaa tuottavaan työhön. Huono intranet taas hidastaa työtä ja pienikin käytettävyysvirhe voi tulla yritykselle kalliiksi. Käyttäjäkeskeinen suunnittelu on tullut suosituksi vuorovaikutteisten järjestelmien suunnittelussa. Silti perinteisiä menetelmiä käytetään ohjelmistojen toiminnalliseen määrittelyyn myös vuorovaikutteisissa järjestelmissä. Käyttäjäkeskeisiä suunnittelumenetelmiä on useita, ja prosessi on kuvattuna ISO 13407 -standardissa. Tässä työssä kuvataan kolme eri toiminnallisen määrittelyn tuottavaa suunnittelumenetelmää: Rational Unified Process, Contextual Design ja Goal Directed Design. Menetelmiä verrataan ISO 13407 -standardin kuvaamiin aktiviteetteihin ja arvioidaan tutkittujen menetelmien sopivuutta Alma Median intranetprojektiin. Työssä suunnittelumenetelmäksi valittiin Goal Directed Design. Valittu menetelmä soveltui hyvin intranetsuunnitteluun. Laajalla haastattelukierroksella ymmärrettiin asiakkaan liiketoimintatavoitteet sekä tunnistettiin ja löydettiin käyttäjäryhmät. Goal Directed Design -menetelmän persoonat auttoivat suunnitteluryhmää huomioimaan loppukäyttäjän koko suunnitteluprosessin ajan. Toiminnallinen määrittely todettiin toimivaksi sekä asiakkaan että toteuttajan kannalta.

III ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Master s Degree Programme in Information Technology HEINÄNEN, SALLA: User-Centered design for intranet project Master of Science Thesis, 72 pages December 2007 Major: Usability Examiners: Professor Kaisa Väänänen-Vainio-Mattila and Professor Tommi Mikkonen Keywords: Intranet, functional requirements definition, User-centered design process, Contextual Design, Goal Directed Design, Rational Unified Process, ISO 13407 As private networks intranets are interesting to design because the user groups are known. Business secrets, however, make benchmarking difficult. A good intranet saves the user s time for productive work. A bad intranet slows down the work, and even a small usability problem can become very expensive. In the field of interactive systems design user-centered design has become popular. In many cases, even if the design target is an interactive system, functional requirements definition is still carried out with traditional methods. There are many methods available for user-centered design. The process for the method of user-centered design process is described in the ISO 13407 standard. This work describes three methods for functional requirements specification: Rational Unified Process, Contextual Design and Goal Directed Design. The methods are compared with the design activities outlined in the ISO 13407, and their suitability for the Alma Media intranet project is evaluated. The Goal Directed Design method was chosen for this thesis The chosen method as well suited for intranet design. The client's business goals and the user groups were identified in comprehensive interviews. The personas of the Goal Directed Design helped the design team to keep the end user in mind throughout the design process. Both the client and the project group found the functional requirements definition successful.

IV ALKUSANAT Tämä työ on tehty Plenware Oy:ssä. Työn asiakkaana oli Alma Median konserniviestintä. Työn tarkastajina toimivat professori Kaisa Väänänen-Vainio-Mattila ja professori Tommi Mikkonen, joita haluan kiittää kommenteista, jotka nostivat työn lopullista laatua huomattavasti. Kiitos myös viestintäpäällikkö Anne Valtaselle, joka toimi intranetprojekin projektipäällikkönä. Tämän työn tekeminen oli pitkä prosessi ja oloni on helpottunut. Haluan kiittää kaikkia ihmisiä, jotka ovat näinä opiskeluvuosina kannustaneet minua. Erityiskiitos kuuluu Petjalle ja vanhemmilleni, jotka eivät koskaan menettäneet toivoaan. Tampereella syntymäpäivänäni 23.11.2007 Salla Heinänen

V SISÄLLYS 1. Johdanto... 1 2. Ohjelmiston määrittelyyn käytettävät menetelmät... 3 2.1. Ohjelmistojen määrittely... 3 2.2. Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnitteluprosessi... 5 2.3. Rational Unified Process... 7 2.3.1. Yleiskuvaus... 7 2.3.2. Vaatimusten määrittely Rational Unified Prosessissa... 9 2.3.3. Iteraatiot... 12 2.4. Contextual Design... 12 2.4.1. Contextual inquiry... 13 2.4.2. Work modeling... 14 2.4.3. Consolidation... 16 2.4.4. Work redesign... 18 2.4.5. User environment design... 19 2.4.6. Mock-up and test with customers... 19 2.4.7. Completing the Design... 20 2.5. Goal Directed Design... 20 2.5.1. Tutkimus... 21 2.5.2. Mallinnus... 25 2.5.3. Vaatimusten määrittely... 29 2.5.4. Luonnokset... 31 2.5.5. Suunnittelu... 33 2.6. Suunnittelumenetelmien vertaaminen ISO 13407 -standardin aktiviteetteihin 34 3. Intranetin määritelmä, suunnittelu ja menetelmän valinta intranetprojektille... 37 3.1. Johdanto intranetsuunnitteluun... 37 3.1.1. Intranetin määritelmä... 37 3.1.2. Intranetin merkitys yritykselle... 37 3.1.3. Intranetsuunnittelun erityispiirteitä... 38 3.1.4. Intranetien käytettävyyden arviointi ja mittaaminen... 39 3.2. Alma Median intranetprojekti ja tavoitteet... 41 3.3. Määrittelymenetelmien vertailu... 42 3.4. Suunnittelumenetelmän valinta... 44 4. Cooperin tavoiteohjatun suunnittelun soveltaminen intranetprojektissa... 45 4.1. Projektin yleiskuvaus... 45 4.1.1. Projektiryhmä ja projektiorganisaatio... 45 4.1.2. Projektin aikataulu... 46 4.2. Tutkimus... 47

4.3. Mallinnus... 52 4.4. Vaatimusmäärittely... 59 4.5. Luonnokset... 62 4.6. Suunnittelu... 65 4.7. Suunnittelumenetelmän arviointi... 66 4.8. Projektin sujumisen arviointi... 67 4.9. Lopputuotteen arviointi... 68 5. Yhteenveto... 69 Lähteet... 71 VI

1. JOHDANTO Intranet on yhä tärkeämmässä asemassa yritysten sisäisessä tiedottamisessa ja tiedonjakelussa. Sen tehtävä on muuttunut sähköisestä arkistosta kohti sähköistä työpöytää, joka tukee käyttäjänsä tehtäviä koko työpäivän ajan. Intraneteihin kohdistuvat odotukset ovat suuria, koska niiden toteuttaminen ja ylläpitäminen on suuri investointi. Intranetien hyvällä käytettävyydellä on osoitettu koituvan suoria säästöjä yrityksille, joten yritykset ovat valmiita investoimaan niiden suunnitteluun. Huonosti suunniteltu intranet taas tuhlaa rahaa enemmän kuin se, että yrityksellä ei olisi intranetiä lainkaan. Intranetit ovat suljettuja verkkoja, mikä aiheuttaa suunnittelulle omat erityispiirteensä. Suunnittelijat tunnistavat tulevat käyttäjät hyvin, mutta toisaalta referenssien löytäminen ja vertaileminen on haastavaa. Käytettävyydeltään hyvään lopputulokseen tähtääviä ohjelmistosuunnittelumenetelmiä on kehitetty jo jonkin aikaa. Uusimpien joukossa on käyttäjäkeskeinen suunnittelu, jossa pyritään suunnittelemaan tuote siten, että se vastaa loppukäyttäjän tarpeita. Käyttäjäkeskeisessä suunnittelussa keskitytään käyttökokemukseen ja käytettävyyteen. Käyttäjäkeskeistä suunnittelua varten on kehitetty vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnittelustandardi ISO 13407 standardi, jota suunnittelumenetelmät noudattavat. Tässä työssä pyritään löytämään hyvä suunnittelumenetelmä intranetsuunnittelua varten ja esittelemään valitulla metodilla toteutettu Alma Median intranetprojekti. Työssä esitellään kolme vaihtoehtoista suunnittelumenetelmää, joilla intranetprojekti voidaan toteuttaa. Esiteltyjen suunnittelumenetelmien aktiviteetteja verrataan vuorovaikutteisen käyttäjäkeskeisen suunnittelun standardiin ja pohditaan kunkin menetelmän soveltumista Alma Median projektissa. Työssä esitellään myös intranetsuunnittelun erityispiirteitä ja erilaisia intranetien mittaamiseen käytettäviä menetelmiä. Työn kirjoittaja toimi intranetprojektissa suunnittelijana, joka osallistui projektiin täysipäiväisesti. Työn rakenne on kuvattu seuraavassa. Työn toinen luku keskittyy teoriaan. Siinä kuvataan ensin yleisiä ohjelmiston määrittelyyn kuuluvia menetelmiä ja käyttäjäkeskeinen suunnittelustandardi ISO 13407. Näiden jälkeen käydään läpi kolme eri suunnittelumenetelmää, joista kaksi on käyttäjäkeskeisiä. Lopussa arvioidaan miten luvussa esitellyt suunnittelumenetelmät vastaavat käyttäjäkeskeiseen suunnittelustandardiin. Kolmannessa luvussa kuvataan intranetejä, niiden suunnittelua ja suunniteluun liittyviä erityispiirteitä sekä intranetien mittaamista. Luvun tarkoituksena on selittää, miten intranetsuunnittelu poikkeaa muiden tuotteiden suunnittelusta. Lisäksi kolmannessa luvussa verrataan esiteltyjä suunnittelumenetelmiä ja niiden soveltuvuutta projektiin sekä intranetsuunnitteluun. Neljäs luku kuvaa valitulla

metodilla toteutetun työn suorituksen. Siinä käydään läpi työn vaiheet ja joitakin lopputuloksia. Lisäksi luvussa arvioidaan työn onnistuminen ja arvioidaan valitun suunnittelumenetelmän soveltuvuus intranetprojektiin. Viidennessä luvussa vedetään yhteen koko työ. 2

3 2. OHJELMISTON MÄÄRITTELYYN KÄYTETTÄVÄT MENETELMÄT Tämän luvun alussa kuvataan lyhyesti, mitä tarkoitetaan ohjelmistojen määrittelyllä yleensä ja tässä diplomityössä. Seuraavassa kohdassa kuvataan käyttäjäkeskeinen suunnittelustandardi ISO 13047. Luvun lopussa kuvataan kolme ohjelmistojen toiminnalliseen määrittelyyn soveltuvaa menetelmää: Rational Unified Process, Contextual Design ja Goal Directed Design. 2.1. Ohjelmistojen määrittely Perinteisessä ohjelmistoprojektissa käytetään vesiputousmallia, jossa määrittely sijoittuu projektin alkuun. Vesiputousmallissa määrittely tehdään yleensä esitutkimuksen ja teknisen suunnittelun välissä. Esitutkimus voi olla myös osa määrittelyvaihetta. [HaiMä98] Kuvassa 2.1 On kuvattuna vesiputousmallin osat. Kuva 2.1 Vesiputousmalli[HaiMä98] Nykyisin ohjelmistoprojekteissa käytetään myös iteratiivista ja inkrementaalista ohjelmistokehitysmallia. Siinä määrittelyä tehdään jokaisessa jokaisessa iteraatiovaiheessa.[lar07] Ikrementaalisen mallin perusidea on esitettynä kuvassa 2.2.

4 Kuva 2.2 Inrementaalinen ohjelmistonkehtysmalli Määrittelyprosessi voidaan ajatella kuvan 2.3 mukaisesti. Määrittelyyn liittyvät tehtävät ovat projektin tavoitteiden ja tarpeellisuuden selvittäminen, tavoitteiden ja tehtävien määrittely sekä ratkaisumallin laatiminen. Toiminnallisessa määrittelyssä kuvataan ohjelmiston toiminnot, toteutukselle asetettavat ei-toiminnalliset vaatimukset, sekä rajoitukset. Toimintojen yhteydessä määritellään ohjelmistolla toteutettavat ominaisuudet, käyttöliittymä ja kommunikointi muiden ohjelmistojen kanssa. Eitoiminnalliset vaatimukset ovat esimerkiksi suoritusteho ja vasteaika, rajoituksia puolestaan vaikkapa käytettävissä oleva muisti ja toteutuskieli. [HaiMä98] Kuva 2.3 Määrittelyprosessi [HaiMä98]

5 Tässä diplomityössä keskitytään vain ohjelmiston kehitysprosessin toiminnallisen määrittelyn vaiheeseen. Toiminnallisella määrittelyllä tarkoitetaan tässä ihmisen ja koneen välisen vuorovaikutuksen määrittelemistä. 2.2. Vuorovaikutteisten järjestelmien käyttäjäkeskeinen suunnitteluprosessi Vuorovaikutteisten järjestelmien suunnitteluprosessista on tehty standardi ISO 13407, joka antaa opastuksen ihmiskeskeisiin suunnittelukäytäntöihin koko tietokonepohjaisten vuorovaikutteisten sovellusten elinkaaren ajan. Standardi on suunnattu henkilöille, jotka hallitsevat suunnitteluprosessia. Se tarjoaa tietolähteitä ja standardeja, jotka ovat tärkeitä ihmiskeskeiseen lähestymiseen. [ISO13407] Käyttäjälähtöinen suunnittelu sisältää standardin mukaan neljä toimintoa: 1. Käyttöympäristön ja käytön ymmärtäminen ja määrittäminen. 2. Käyttäjän ja organisaation vaatimusten ymmärtäminen. 3. Suunnitteluratkaisujen tuottaminen. 4. Suunnitelmien arviointi vaatimuksia vastaan. [ISO13407] Kuvassa 2.4 on esitettynä näiden toimintojen välinen suhde. Käyttäjäkeskeinen suunnittelu suositellaan aloitettavaksi heti ohjelmistoprojektin alussa, ja sitä pitää jatkaa iteratiivisesti, kunnes järjestelmä toteuttaa sille asetetut vaatimukset. Käyttäjäkeskeisen suunnittelumenetelmän tarve määritetään järjestelmän toiminnallisista päämääristä, esimerkiksi täyttämään asiakkaan käytettävyysvaatimukset. [ISO13407] Kuva 2.4 Ihmiskeskeisen suunnittelun toimintojen välinen riippuvuus [ISO13407]

6 Käyttöympäristön ja käytön määrittämisessä ja ymmärtämisessä tarkoituksena on tunnistaa käyttäjä, ymmärtää missä tuotetta/palvelua käytetään ja tehtävät, joihin tuotetta/palvelua käytetään [Jok03]. Käyttäjä voidaan tunnistaa erilaisten ominaisuuksien perusteella kuten tietotaso, taidot, kokemus, koulutus ja käyttäytymistavat. Tässä kohdassa voidaan myös määritellä erityyppisten käyttäjien kuten asentajien ja ylläpitäjien tyypilliset piirteet. Käyttäjien tulevat tehtävät voidaan määritellä lopullisilla tavoitteilla, joita järjestelmälle on. Tehtävät, jotka vaikuttavat käytettävyyteen, pitäisi tunnistaa. Tehtäviä ei pitäisi kuvata ainoastaan toimintoina ja ominaisuuksina. Käyttöympäristön kuvaaminen sisältää ohjelmistojen, laitteiden ja käytettävissä olevan muun materiaalin ominaisuudet, jotka vaikuttavat tulevan ohjelman suorituskykyyn tai käyttäjäkeskeisyyden arviointiin, ominaisuuksiin tai käyttäytymispiirteisiin. Fyysisen ja sosiaalisen ympäristön merkittävät piirteet tulisi kuvata. Ne voivat sisältää merkittävät standardit tai laajemman teknisen kokonaisuuden piirteet, lainsäädännölliset, fyysiset, sosiaaliset ja kulttuurilliset piirteet. Tämän vaiheen lopputuloksena tulisi esitellä tulevien käyttäjien kirjo sillä tarkkuudella, että siitä on hyötyä suunnittelussa. Lopputulokseen tulee päätyä monista eri lähteistä. Se pitää olla johdettu käyttäjistä tai jos niitä ei ole saatavilla, niistä jotka ovat kiinnostuneita prosessista. Vaiheen pitää olla riittävästi dokumentoitu ja suunnittelutiimin saatavilla oikeaan aikaan, jotta siitä on hyötyä suunnittelussa. [ISO13407] Käyttäjän ja organisaation vaatimusten ymmärtäminen. Lyhyesti tässä kohdassa tuotteen käytettävyydelle asetetaan hyväksyttävä taso, esimerkiksi kuinka nopeasti tyypillinen käyttäjä pystyy suorittamaan tehtävän tuotteella ja määritellään suunnitteluohjeistukset ja rajoitteet [Jok03]. Kohdan tulisi toiminnallisten ja muiden vaatimusten määrittämisen lisäksi tuottaa eksplisiittinen määritelmä käyttäjän ja organisaation vaatimuksista suhteessa käyttöympäristön ja käytön kuvauksen kanssa. Seuraavat asiat tulee huomioida vaatimuksia määritellessä: uuden järjestelmän vaadittu käyttäytyminen toiminnallisiin ja taloudellisiin seikkoihin nähden, tarvittavien lakisääteisten vaatimusten huomiointi mukaan lukien turvallisuus ja terveys, käyttäjien ja muiden tahojen välinen yhteistyö ja viestintä, käyttäjien työtehtävät, tehtävien suoritus, työn suunnittelu ja organisointi, muutoksen hallinta sisältäen koulutuksen ja henkilökunnan joka on mukana, ylläpidon ja toiminnan soveltuvuus sekä käyttöliittymä ja työasemasuunnittelu. Käyttäjien ja organisaation vaatimusten ymmärtäminen -kohdan lopputuloksen tulee sisältää seuraavat asiat: tunnistaa suunnittelussa asiaankuuluvat käyttäjät ja muut tahot; esittää selkeä näkemys ihmiskeskeisen suunnittelun tavoitteista; määritellä asianmukaiset prioriteetit vaatimuksille; tarjota mitattava kriteeristö, mitä vastaan suunnittelua voidaan testata; varmistaa vaatimukset käyttäjillä tai niillä, joilla on prosessia kohtaan kiinnostusta; sisältää lainmukaiset vaatimukset ja olla asianmukaisesti dokumentoitu. [ISO13407] Suunnitteluratkaisujen tuottaminen. Yhdistää ihmisen ja koneen välisen vuorovaikutuksen tietämys suunnitteluratkaisuiksi [Jok03]. Tässä kohdassa tulisi

7 käyttää olemassa olevaa tietoa tuottamaan suunnitteluehdotelmia, tehdä suunnitteluratkaisuista konkreettisempia simulaatioilla ja malleilla, esittää suunnitteluratkaisuja käyttäjille ja antaa heidän suorittaa tehtäviä, muunnella suunnitelmaa perustuen käyttäjäpalautteeseen ja iteroida suunnitelmaa kunnes käyttäjäkeskeiset suunnittelutavoitteet saavutetaan, hallita iteraatioita ja suunnitteluratkaisuja. [ISO13407] Suunnitelmien arviointi vaatimuksia vastaan. Suunnitelmien käytettävyyttä arvioidaan käyttäjän tehtävillä [Jok03]. Evaluointi on tärkeä vaihe käyttäjäkeskeisessä suunnittelussa ja sitä pitäisi tapahtua koko suunnittelun ajan. Arviointia voidaan käyttää tarjoamaan palautetta, jolla suunnitelmaa voidaan parantaa, arvioida onko käyttäjän ja organisaation tavoitteet saavutettu ja monitoroida järjestelmän pitkä aikaista käyttöä. [ISO13407] 2.3. Rational Unified Process Rational Unified Process (RUP) on alun perin Rational Softwaren kehittämä kokonaisvaltainen ohjelmiston kehitysprosessi [Jac99]. RUP:n mukaan ohjelmiston kehitysprosessi on joukko toimintoja, joilla käyttäjävaatimukset saadaan muunnettua ohjelmistoksi. RUP sisältää kuvan 2.5 ohjelmiston kehitysprosessi -vaiheen toiminnot. Prosessikuvaus perustuu lähteeseen [Jac99], mikäli toisin ei ole mainittu. Kuva 2.5 Ohjelmiston kehitysprosessi [HaiMä98] RUP on opastus siihen, miten saman yhtiön kehittämää Unified Modelling Language - kuvauskieltä (UML) käytetään tehokkaasti ohjelmiston kehitysprojektissa. [Rat98] 2.3.1. Yleiskuvaus RUP:n vaatimusmäärittely perustuu käyttötapauksiin ja käyttötapausmalliin, joka kuvaa koko järjestelmän toiminnallisuuden, eli se on käyttötapauspohjainen suunnittelumalli. Mallien perusteella ohjelmistonkehittäjät toteuttavat ohjelmiston toiminnallisuuden. Funktiopohjainen määrittelymenetelmä kertoo mitä ohjelma tekee, mutta RUP vastaa lisäksi kysymykseen, mitä järjestelmä tekee kullekin käyttäjälle. Suunnittelijat vertaavat toiminnallisuuksia käyttötapauksiin eli toteuttaako järjestelmä käyttötapauksen. Vaikka käyttötapaukset ohjaavatkin suunnittelua ja järjestelmän arkkitehtuuria, myös arkkitehtuuri vaikuttaa käyttötapauksiin. Molemmat kehittyvät koko prosessin ajan.

8 RUP on arkkitehtuurikeskeinen prosessi, mutta jokaisella tuotteella on toiminnot ja toteutus, joita ilman tuote ei ole ehjä kokonaisuus. Käyttötapaukset ja ohjelmistoarkkitehtuuri ovat vuorovaikutuksessa keskenään. Toteutettujen käyttötapausten pitää toimia arkkitehtuurin asettamissa rajoissa. Toteutettavan tuotteen arkkitehtuurin tulee kuitenkin olla niin avoin, että se antaa mahdollisuuden ohjelmiston laajentamiseen ja kehittämiseen. RUP perustuu iteraatioon ja inkrementointiin, jossa työ jaetaan pieniin osakokonaisuuksiin. Jokainen iteraatiokierros lisää tuotteen toimintoja ja laajentaa tuotetta. Tehokkaat iteraatiot ovat kontrolloituja, eli ne pitää valita ja toteuttaa suunnitellulla tavalla. Iteroitavat tuotteen osat valitaan siten, että ryhmä käyttötapauksia yhdessä kasvattaa tuotteen käytettävyyttä ja siten, että iteraatio käsittelee tuotteen tärkeimpiä riskialueita. Ensimmäistä iteraatiokierrosta varten ohjelmistoarkkitehti tarvitsee vain 5-10 prosenttia avainkäyttötapauksista, jotta hän voi tehdä ensimmäisen arkkitehtuurisuunnitelman. RUP etenee iteraatiokierroksittain, ihannetapauksessa uusi iteraatiokierros tehdään suoraan edellisessä iteraatiossa syntyneen version päälle. Yleensä iteraatiokierros lisää tuotteen toimintoja, mutta etenkin alkuvaiheessa näin ei aina ole, vaan osia saatetaan joutua tekemään uudestaan. Kontrolloitu iteraatio vähentää tuotteen kustannusriskiä, koska yhdellä iteraatiokierroksella tehty virhe vaatii korjausta vain siihen liittyvään toiminnallisuuteen. RUP:n mukaisen ohjelman elinkaari on kuvan 2.6 mukainen. Jokainen julkaisu, toisin sanoen uusi versio, syntyy, kun siihen liittyvät vaiheet on suoritettu. Kuva 2.6 RUP:n mukaisen ohjelman elinkaari ja julkaisuun liittyvät vaiheet [Jac99], Jokainen julkaisuun liittyvä sykli koostuu seuraavista neljästä vaiheesta: alku, yksityiskohtainen tarkastelu, rakentaminen ja siirtyminen. Siirtymävaiheen jälkeen tuotteesta tulee uusi versio, ja se on valmis julkaistavaksi. Jokaisessa versiossa on

9 mukana käyttöohjeet sekä muut kyseiseen vaiheeseen asti tehdyt tuotokset sekä lähdekoodi, joka voidaan kääntää toimivaksi ohjelmaksi. Lopullisessa tuotteessa on mukana kaikki projektin aikana syntynyt materiaali: vaatimukset, käyttötapaukset, eitoiminnalliset vaatimukset, testitapaukset, arkkitehtuuri ja kaikki projektin aikana piirretyt kaaviot. Lopputuotteen tulee täyttää asianomistajien tavoitteet ja heidän pitää pystyä määrittelemään, toteuttamaan, testaamaan ja käyttämään tuotetta. Kun uusi versio on julkaistu, seuraavan version kehittäjät tarvitsevat kaiken siihen mennessä tuotetun dokumentaation, jotta kehittäminen voi jatkua. Kuva 2.7 Työnkulun osa-alueet ja niiden suhde RUP:n vaiheisiin Edellä mainittujen vaiheiden lisäksi RUP jaetaan myös neljään työnkulkuvaiheeseen, joissa painotetaan aina yhtä tai useampaa RUP:n osa-aluetta. Työnkulkuvaiheet ovat vaatimustenmäärittely, analyysi, suunnittelu, toteutus ja testaus. Vaiheiden ja työnkulun suhteet on esitetty kuvassa 2.7. 2.3.2. Vaatimusten määrittely Rational Unified Prosessissa RUP:ssa vaatimuksia määritellään useassa eri työvaiheessa kuvan 2.7 mukaisesti seuraten RUP:n vaiheita ja työnkulkua. Alkuvaiheessa määritellään alle 10 prosenttia vaatimuksista. Yksityiskohtaisen tarkasteluvaiheen jälkeen vaatimuksista pitäisi olla määriteltynä noin 80 prosenttia, jolloin myös suurin osa käyttötapauksista pitäisi olla valmiina. Loput vaatimukset löydetään toteutusvaiheessa. Ennen ajateltiin, että ohjelmistojen vaatimukset saadaan määriteltyä vain haastattelemalla loppukäyttäjiä. Tämä onkin osittain totta, sillä haastattelemalla saadaan selville paljon ohjelman vaatimasta interaktiosta. RUP:n periaatteiden mukaan tätä

10 tärkeämpää on kuitenkin, että ohjelma palvelee tarkoitustaan. Lopputuotteen pitää tuottaa lisäarvoa yrityksen toimintaan ja käyttäjille, sekä niille, joihin ohjelmiston käyttö vaikuttaa. Liiketoiminta, toimintaympäristö ja tekniikka saattavat kuitenkin muuttua projektin aikana. Tästä johtuen vaatimusten määrittely on hankalaa, mutta RUP pyrkii tarjoamaan johdonmukaisen prosessin vaatimusten hallintaan. Vaatimukset-työvaiheen tarkoituksena on saada suunnittelu etenemään kohti oikeanlaista järjestelmää. Tässä työvaiheessa vaatimukset pitää pystyä kuvaamaan niin, että ohjelmiston toiminnoista saadaan riittävä kuva, jotta asiakas ja ohjelmiston toimittaja pääsevät yhteisymmärrykseen valmiin tuotteen ominaisuuksista. Ominaisuudet pitää pystyä esittämään asiakkaan kielellä ja siten, että ei-tekninen henkilökin pystyy ne ymmärtämään. Tämän työvaiheen lopputulos auttaa myös projektin vetäjää suunnittelemaan toteutukseen vaadittavia iteraatiokierroksia. Projektien lähtötilanteet voivat olla hyvin erilaisia. Jossain tapauksissa asiakkaalla on hyvin tarkka kuva, mitä ominaisuuksia ohjelmistoon halutaan. Joskus hänellä on vain pieni ajatus, mitä valmiissa tuotteessa saattaisi olla. Tilanteesta riippumatta seuraavissa kappaleissa esitetyt asiat ovat käyttökelpoisia määrittelyä tehtäessä. Niiden tekeminen ei ole kuitenkaan välttämätöntä. Vaatimusehdokkaiden listaaminen. Listassa ovat kaikki mahdolliset vaatimukset, ja se on tarkoitettu vain suunnittelun tueksi. Siihen lisätään ja siitä poistetaan vaatimuksia sitä mukaan, kun niitä löytyy tai ne tulevat tarpeettomiksi. Vaatimuksia voidaan luokitella tärkeyden tai prioriteetin mukaan. Lisäksi niiden toteutuskustannuksia ja mahdollisia riskejä voidaan analysoida jo tässä vaiheessa. Samalla voidaan myös arvioida projektin kokoa ja työmäärää. Järjestelmän toimintaympäristön ymmärtäminen. Tarkoituksenmukaista järjestelmää suunniteltaessa toimintaympäristön ymmärtäminen on erityisen tärkeää. Projektissa pitää olla mukana ainakin muutama henkilö, jotka ymmärtävät asiakkaan toimintaympäristön. Toimintaympäristöä voidaan yrittää ymmärtää ainakin mallintamalla toimintakenttää tai liiketoimintaa. Toimintaympäristöanalyysi koostuu toimintaympäristön muuttamista käsitteiksi ja niiden linkittäminen keskenään. Suurin osa käsitteistä löytyy vaatimuksista tai haastattelemalla liiketoiminnan asiantuntijoita. Käsitteitä on kolmea tyyppiä: liiketoimintaoliot, jotka edustavat niitä asioita, joita liiketoiminta käsittelee, todelliset asiat, joista järjestelmän pitää olla perillä ja tapahtumat, kuten lounastauot tai muut ympäristöön liittyvät asiat. Samalla määritellään keskeinen sanasto. Joissakin tapauksissa pelkkä sanasto riittää toimintaympäristön analyysiksi. Sanasto on tärkeä, jotta kehittäjät, asiakkaat ja loppukäyttäjät puhuvat samaa kieltä. Tässä vaiheessa koottu sanasto siirtyy myös lopputuotteeseen ja sitä käytetään käyttötapauksia kirjoitettaessa. Toimintaympäristöanalyysi piirretään UML:n avulla, analyysin avulla kehittäjät,

11 asiakkaat, käyttäjät ja muut asianosaiset saavat selville toimintaympäristön käsitteet ja niiden suhteet. Liiketoimintamallin analysointi listaa kaikki olemassa olevat ja nähtävissä olevat prosessit ja tutkii, mitkä prosesseista ovat tekemisissä tulevan järjestelmän kanssa. Liiketoimintamalli on ikään kuin laajennettu toimintaympäristöanalyysi. Toimintaympäristöanalyysi kuvaa vain konkreettiset asiat, jotka kuuluvat yritykseen. Liiketoimintamalli kuvaa yrityksen sisäisen toimintatavan. Liiketoimintamallissa kokonaisuudet syntyvät lisäksi haastattelemalla asiakkaita ja tunnistamalla liiketoiminnan käyttötapauksia. Toimintaympäristön käsitteillä on ominaisuuksia, mutta hyvin harvoin toimintoja. Liiketoiminnan käsitteet taas sisältävät useimmiten toimintoja. Liiketoiminta-analyysissä ei pyritä ainoastaan hahmottamaan kokonaisuuksia, vaan myös löytämään miten kokonaisuudet toimivat kunkin toimijan näkökulmasta. Liiketoiminnan mallintamisessa löytyneitä toimijoita käytetään lähtökohtana, kun ensimmäisiä käyttötapauksia aletaan yhdistellä. Näin jokainen käyttötapaus voidaan jäljittää toimijoiden ja liiketoimintamallien kautta asiakkaaseen. Samaan tapaan jokainen ohjelman toiminto voidaan jäljittää käyttötapauksiin.[jac99] Toiminnallisten vaatimusten kiinnittäminen. Toimijoiden ja käyttötapausten löytäminen on vaatimusten kiinnittämisen tärkein osa. Aluksi järjestelmäasiantuntijan pitää rajoittaa järjestelmän toimintaympäristö, määrittää mitkä toimijat ovat tekemisissä järjestelmän kanssa ja määrittää millaista toiminnallisuutta järjestelmältä odotetaan. Tässä vaiheessa tehdään myös sanasto. Järjestelmäasiantuntija vastaa yksin toimijoiden ja käyttötapausten löytämisestä, mutta hän ei voi tehdä työtä yksin. Tässä vaiheessa mukana ovat myös asiakas, järjestelmän loppukäyttäjät ja muita asiantuntijoita. Nämä tahot kokoontuvat yhteen erilaisissa työryhmissä. Jos järjestelmästä on tehty toimintaympäristö- tai liiketoimintamalli, ne ovat alussa suurena apuna, kun ensimmäisiä käyttötapauksia suunnitellaan. Käyttötapausten ja toimijoiden löytäminen koostuu neljästä vaiheesta: toimijoiden löytäminen, käyttötapausten löytäminen, käyttötapausten lyhyt kuvaaminen ja käyttöliittymämallin kuvaaminen. Toimijat löytyvät helposti joko liiketoimintamallista tai keskustelemalla asiakkaan kanssa. Tässä vaiheessa pitää huomioida kaikki toimijat, systeemin kanssa tekemisissä olevat muut järjestelmät, ylläpitäjät ja loppukäyttäjät. Jokainen löydetty toimija nimetään ja siitä tehdään lyhyt kuvaus. Käyttötapaukset voidaan helposti löytää liiketoimintamallista. Mikäli liiketoimintamallia ei ole tehty, järjestelmäasiantuntija voi pitää ryhmätyöpajoja, joissa etsitään sopivat käyttötapaukset. Kaikista mahdollisista käyttötapauksista ei tehdä omiaan, vaan niistä voi tulla osa jotakin käyttötapausta. Jokainen käyttötapaus nimetään, useimmiten nimi alkaa verbillä ja sen pitäisi kuvata sitä, mitä toimijan ja systeemin välillä tapahtuu. Käyttötapaus tuo aina lisäarvoa toimijalle, jota se koskee.

12 Käyttötapausten määrittelemisen jälkeen jokainen käyttötapaus kuvataan lyhyesti. Kuvaus voi olla muutaman sanan mittainen tai joskus vain nimi. Priorisoinnin jälkeen käyttötapaukset kuvataan tarkemmin, jotta toimijan ja systeemin välinen vuorovaikutus selviää tarkasti. Tässä vaiheessa jokainen käyttötapaus piirretään sillä tarkkuudella, että tiedetään jokaisen käyttötapauksen mahdolliset toimintopolut. Mallintamisessa voidaan käyttää esimerkiksi tilakaavioita. Lopuksi käyttötapaukset kuvataan käyttötapausmallina. Se kuvaa miten käyttötapaukset toimivat keskenään. Käyttötapausmallin ei tarvitse olla suoraviivainen, vaan sen voi kuvata myös erilaisina paketteina, jotka sisältävät käyttötapaukset. Käyttötapausmallin piirtämisen jälkeen käyttötapaukset priorisoidaan, jotta voidaan päättää mitkä toteutetaan ensimmäisessä iteraatiossa. Tulos kuvataan käyttötapausmallin arkkitehtuurinäkymässä. Jokainen käyttötapaus kirjoitetaan ja kuvataan myös yksityiskohtaisesti. Tämän työn tekevät käyttötapausten määrittelijät. Käyttötapauksen yksityiskohtaiseen kuvaukseen kuuluu käyttötapauksen kaikkien eri tilojen läpikäyminen alkutilasta lopputilaan kaikkien mahdollisten välivaiheiden kautta. Vaatimusten määrittelyn yhteydessä käyttöliittymäasiantuntija tekee myös käyttöliittymän prototyypin. Käyttötapauksia tutkitaan yleisellä tasolla, jotta saadaan selville, mitä käyttöliittymältä vaaditaan eri toimijoille. Tämän jälkeen piirretään fyysisen käyttöliittymän prototyyppi. Se kuvaa miten käyttäjät pystyvät toteuttamaan järjestelmällä käyttötapausten kuvaamat tehtävät. Tämäkin vaihe tehdään aluksi vain tärkeimmille käyttäjäryhmille eikä se ole täydellinen. Sanasto on myös tässä vaiheessa olennaisessa osassa, jotta käyttöliittymään tulevat oikeat termit. Ei-toiminnallisten ja täydentävien vaatimusten kiinnittäminen. Useat eitoiminnalliset vaatimukset viittaavat tiettyyn käyttötapaukseen, ja ne kuvataan kunkin käyttötapauksen yhteyteen. Ne ei-toiminnalliset, täydentävät vaatimukset, jotka eivät liity suoranaisesti mihinkään käyttötapaukseen, voidaan listata erikseen. 2.3.3. Iteraatiot Ohjelman elinkaaren aikana vaatimuksiakin määritellään jokaisella iteraatiokierroksella uudelleen. Kuvan 2.7 mukaisesti vaatimusten määrittelyn osuus pienenee kuitenkin huomattavasti mitä pidemmälle työnkuluissa mennään. Uuden julkaisun yhteydessä vaatimuksia määritellään lisää tilanteesta riippuen. [Jac99] 2.4. Contextual Design Contextual Design (CD) on seitsemän vaihetta käsittävä käyttäjäkeskeinen suunnittelumenetelmä. Tässä kohdassa kuvataan lyhyesti CD:n eteneminen. CD tarjoaa

13 selkeät vaiheet ja lopputuotokset koko suunnittelulle. CD on alun perin suunniteltu suurille ja monimutkaisille projekteille, mutta sitä voidaan käyttää yhtä hyvin pienissä projekteissa. CD:n pyrkimyksenä on tehdä prosessi niistä vaiheista, jotka hyvä määrittelijä tekee itsestään suunnitellessaan uutta järjestelmää. Contextual designin tarkoituksena on mallintaa kaikki ne suunnittelun vaiheet, jotka pitää joka tapauksessa tehdä tavalla tai toisella. [BeHo98] Kuvassa 2.8 on esitettynä Contextual Designingmenetelmän vaiheet. Prosessikuvauksen vaiheet perustuvat lähteeseen [BeHo98] ellei toisin mainita. Kuva 2.8 Contextual Designin vaiheet [BeHo98b] Suunnittelutiimin koko on vähintään kaksi henkilöä. Suositeltavaa on kuitenkin, että tiimissä on enemmän ihmisiä, jotta suunnitteluun saadaan enemmän näkökulmia. Projektissa tulee olla ainakin kaksi ihmistä, jotka vastaavat siitä. Lisäksi on suositeltavaa, että muista tiimeistä lainataan ihmisiä esimerkiksi yhdistelytyövaiheeseen. [BeHo98] 2.4.1. Contextual inquiry Contextual inquiry (CI), eli kontekstissa tapahtuva käyttäjätutkimus tarkoittaa yksinkertaistetusti: mene sinne missä asiakas tekee työtään, tarkkaile asiakkaan

14 työskentelyä ja keskustele asiakkaan kanssa hänen työstään. Tarkemmin kuvattuna suunnittelija menee asiakkaan luokse oppimaan hänen työtään. Hän seuraa mestarin (asiakkaan) työskentelyä ja oppii sillä perusteella ymmärtämään yleisiä periaatteita, jotka ovat työn teon taustalla. Tässä työvaiheessa suunnittelija tutustuu mahdollisimman kattavasti suunniteltavan kohteen sovellusalueeseen ja selventää käyttäjien todelliset tarpeet. Samalla saadaan selville työhön liittyviä yksityiskohtia ja työntekijöiden asenteita. Lopuksi kerätty tieto jaetaan koko suunnittelutiimin kesken. CI:n neljä pääkohtaa ovat: konteksti, kumppanuus, tulkinta ja fokus. Kontekstissa mennään asiakkaan työpaikalle ja nähdään miten työtä tehdään. Se on CI:n yksinkertaisin ja tärkein asia. Kumppanuuskohdassa tarkoituksena on ymmärtää asiakkaan työtä. Tulkinta selvittää asian, jolla on käyttäjän kannalta merkitystä. Fokus on tärkeä, jotta tutkija tarkkailee oikeita asioita. Mestari kertoo työstään sen mitä haluaa. Hyvän fokuksen avulla oppipoika osaa kysyä oikeita asioita, joilla on merkitystä. Käytännössä CI:ssä yhdistetään käyttäjätarkkailu ja haastattelu. Vuorovaikutuksen pitää olla luontevaa, ja haastattelun olisi hyvä tapahtua oikeassa työskentely-ympäristössä. Tässä tilanteessa tehdään yhteistyötä. Tarkkailija voi esimerkiksi kysellä työntekijältä tarkentavia kysymyksiä, ja työntekijä kertoo tarkkailijalle mitä ja miksi hän tekee. Contextual design ehdottaa erilaisia vuorovaikutusmalleja kuten mestari-kisälli. Siinä haastattelija eli kisälli menee oppimaan tarkkailtavalta eli mestarilta hänen työtään. Tarkoituksena ei ole oppia tekemään itse työtä, vaan ymmärtää sen perusteet. Muita suositeltuja tarkkailumalleja on lapsi-aikuinen ja tutkija-tutkimuskohde. CI:n aikana haastattelija voi kerätä artefakteja eli erilaisia ohjeita, muistilappuja ja muita haastateltavan työssään käyttämiä esineitä. Ennen seuraavaan vaiheeseen siirtymistä pidetään tulkintatilaisuus. Tulkintatilaisuuden tarkoituksena on jakaa kaikki CI:n aikana kerätty tieto koko suunnittelutiimille. Tilaisuudessa käytetään koko suunnittelutiimin asiantuntemusta, jotta työn kannalta tärkeimmät asiat saadaan selville. Tässä tilaisuudessa voidaan jo kerätä suunnitteluideoita ja kirjata niitä muistiin. 2.4.2. Work modeling Work modeling -vaiheessa kuvataan CI-vaiheessa saatu data graafisesti. CD tarjoaa viisi mallia kuvaamaan käyttäjän työtä. Mallit ovat vuorovaikutus-, sekvenssi-, artefaktikulttuuri- ja fyysinen malli. Mallien peruslähtökohtana on tarjota suunnitteluryhmälle yhteinen kieli ja jakaa tarkkailusta saatu tieto kaikkien kesken. Myöhemmin malleja käytetään suunnittelun tukena. Tässä kappaleessa kuvataan lyhyesti kaikki mallit ja niiden tarkoitus.

15 Vuorovaikutusmalli kuvaa miten työ jakautuu eri ihmisten kesken ja miten ihmiset toimivat, jotta he voivat varmistaa, että työ sujuu odotetulla tavalla. Pohjimmiltaan on tarkoitus selittää millaisessa vuorovaikutuksessa haastateltu on työssään muiden kanssa. Work flowssa kuvataan jonkun työtehtävän koko prosessi mukaan lukien sähköpostit, puhelinsoitot ja kahvitunnilla tapahtuva keskustelu. Vuorovaikutusmallista saadaan myös ylemmän tason näkemys koko organisaatiosta, koska siinä näkyvät ihmiset ja heidän vastuualueensa ja keskustellut asiat sekä viestintäkanavat, jotka eivät ole sidotut aikaan. Sekvenssimalli kuvaa sitä, millaisessa järjestyksessä työ tai työvaiheet tapahtuvat. Sekvenssimallilla voidaan kuvata ihmisten työstrategioita. Sen avulla voidaan tarkistaa, että uusi järjestelmä tukee työn eri vaiheita. Sekvenssimallin tarkkuuden voi määritellä tapauskohtaisesti. Artefaktimallissa kuvataan käyttäjän työssään käsittelemiä asioita ja esineitä, esimerkiksi muistilaput, kalenteri tai suunnittelukokoukset. Artefakteja pitää pysyä tulkitsemaan, esimerkiksi miten artefakti tukee työntekijää, voisiko sen korvata jollain. Artefaktit voivat kuvata mahdollista interaktiota ihmisen ja järjestelmän välillä. Kaikki työ tehdään työkulttuuriympäristössä. Kulttuurimallilla pyritään kuvaamaan työympäristön muodolliset ja epämuodolliset menettelyt sekä toimintaympäristön ja toimialan synnyttämä ilmapiiri. Kulttuurimalliin vaikuttavat erityisesti standardit, menettelytavat, valta, arvot ja identiteetti. Fyysinen malli kuvaa työntekijän työympäristön. Siihen kuvataan työskentelypaikat, erilaiset rakenteelliset esteet, työssä tarvittavat välineet ja niin edelleen. Sen tarkoituksena on näyttää, miten fyysinen ympäristö vaikuttaa työhön ja miten tilaa käytetään. Edellä kuvatut mallit tehdään tulkintatilaisuudessa, jossa on läsnä kaikki suunnittelutiimin jäsenet. Jokaisella jäsenellä on rooli, jotta tilaisuus on tehokas. Roolit ja tehtävät on lueteltuna taulukossa 2.1.

16 Taulukko 2.1 Tulkintatilaisuuden roolit Haastattelija Työn kuvaajat (work modelers) Nauhoittaja Osallistujat Moderaattori Kankkulankaivon vartija Henkilö, joka on ollut haastattelija CI:n aikana. Hän kertoo koko haastattelutilanteen kulun muulle ryhmälle, oikomatta mitään. Haastattelijaa voidaan keskeyttää ja pyytää lisätietoja koko hänen puheensa ajan. Haastattelijan tehtävä on myös piirtää fyysinen malli, koska se on hänelle helpointa. Työn kuvaajat piirtävät malleja fläppitaululle sitä mukaan, kun he kuulevat niitä. Piirrettävät mallit ovat vuorovaikutus-, sekvenssi- ja kulttuurimalli. Muu ryhmä tarkkailee työn tulosta koko ajan. Nauhoittaja pitää kirjaa kokouksen kulusta siten, että kaikki näkevät kokoajan hänen muistiinpanonsa. Näitä muistiinpanoja käytetään myöhemmin yhdenmukaisuuden saamiseksi. Osallistujat kuuntelevat muita ja esittävät kommenttejaan muodostaen samalla oman kuvansa työstä. He voivat kirjoittaa myös muistiin suunnitteluideoita. Moderaattori on koko tilaisuuden näyttämömestari. Hänen tehtävänään on pitää keskustelu asiassa. Tässä tapauksessa keskustellaan siitä, mitä tapahtui käsiteltävän haastattelun aikana ja mitä tietoa pitää saada talteen. Hänen tehtävänään on myös saada kaikki osallistumaan tilaisuuteen. Kankkulankaivon vartija (rat hole watcher) pitää huolta, että keskustelu ei jää junnaamaan johonkin epäolennaiseen asiaan. Käytännössä tulkintatilaisuuksissa kaikki pitävät huolta, että turhanpäiväisyyksistä pysytään erossa. 2.4.3. Consolidation Consolidation-vaiheessa yhdistetään mallit ja haastattelujen tulokset. Vaiheen tarkoituksena on kerätä kaikki aikaisemmin kerätty tieto yhteen, luoda asiakkaasta yksi yhteinen kuva ja saada suunnittelutiimille yhteinen fokus. Lopullisena tuloksena syntyy uusia ideoita ja mahdollisuuksia käyttäjän työstä. Yhdenmukaisuuskaavio kokoaa tulkintatilaisuudessa tehdyt muistiinpanot. Yhdenmukaisuuskaavio näyttää asiakkaan ongelman kohteen. Siinä näkyvät yhdessä paikassa kaikki keskeiset työhön liittyvät ongelmat, asiat ja elementit. Yhdenmukaisuusseinässä jokainen tulkintatilaisuudessa tehty muistiinpano ryhmitellään toisten muistiinpanojen kanssa. Yhdenmukaisuusseinä rakennetaan alhaalta ylös. Ensin vain muutama asia liittyy yhteen. Sitten asiat liitetään aina suuremmiksi kokonaisuuksiksi ja kullekin kokonaisuudelle annetaan otsikko, joka kuvastaa ryhmää mahdollisimman hyvin. Yhdenmukaisuusseinää rakennettaessa tiimi on koko ajan vuorovaikutuksessa keskenään, jotta ryhmittelyjä voidaan pohtia. Yhdenmukaisuusseinässä on yksi päätaso ja kolme alitasoa, joista alimpana on tulkintatilaisuudessa ilmikäyneet asiat. Hyvän yhdenmukaisuusseinän voi lukea alusta

17 loppuun siten, että siitä näkee jokaisen työvaiheen ja kaiken, mitä suunnitteluryhmä on oppinut asiasta siihen mennessä. Vuorovaikutusmallien yhdenmukaistaminen tuo esiin viestintämallit, jotka kertovat siitä, miten asiakas tekee liiketoimintaansa. Sen tarkoituksena on näyttää, mitä osaa asiakaskunnasta käsitellään ja miten olemassa olevaa systeemiä voidaan laajentaa tukemaan työtä paremmin. Yhdistetty vuorovaikutusmalli näyttää yleiset mallit, jotka ovat eri organisaatioiden työnkuvausten takana. Yhdistetyn vuorovaikutusmallin päätehtävä on määritellä yksilöiden roolit ja yhdistää samanlaiset roolit. Mallin avulla voidaan tutkia, mitä olemassa olevassa järjestelmässä voidaan parantaa, jotta se tukisi paremmin koko organisaatiota. Sekvenssimallien yhdistäminen paljastaa niiden työtehtävien rakenteen, jotka ovat yhtenäisiä kaikille työtä tekeville. Siinä pyritään tuomaan esille kaikkien samaa työtä tekevien toimintamalli. Yhdistetty sekvenssimalli esittää suunnittelijalle yksityiskohtaisen rakenteen, jota pitää tukea, poistaa tai parantaa. Artefaktimallien yhdistämisen tarkoituksena on näyttää, miten ihmiset järjestävät ja ryhmittelevät työnsä päivästä toiseen. Yhdistetty artefaktimalli esittää yleisiä konsepteja, joilla ihmiset rakentavat työnsä. Se myös kuvaa ihmisten tavoitteita, jotka saattaisivat muuten jäädä huomioimatta. Samaa asiaa ajavien yksittäisten artefaktien tutkiminen näyttää yhteisen rakenteen. Fyysisten mallien yhdistäminen näyttää yleisen fyysisen mallin, jossa asiakas toimii ja vaihtelevuudet, jossa systeemin pitää toimia. Yhdistetty fyysinen malli muistuttaa suunnittelutiimiä siitä, että fyysiseen työskentely-ympäristöön ei voi aina vaikuttaa. Siinä pyritään löytämään muuttuvat seikat ja yhtäläisyyksiä, joita kaikilla asiakkailla on. Kulttuurimallien yhdistäminen paljastaa työskentelyilmapiiriin liittyviä tärkeitä arvoja, jotka suunnitteluryhmän pitää huomioida uutta tuotetta suunnitellessaan. Kaikki mallit ja mihin ne vastaavat on esitelty taulukossa 2.2. [BeHo98]

18 Taulukko 2.2 CD:ssa toteutettavat mallit[beho98] Vuorovaikutusmalli Roolien vaihtaminen, useita rooleja samalla käyttäjällä, roolien jakaminen ja roolien erottaminen toisistaan. Kulttuurimalli Miten työntekijöiden välisiä ongelmia voidaan vähentää suunnittelulla? Fyysinen malli Mitkä asiat ovat muutettavissa? Liikkuminen, kommunikaatio, artefaktien kulkeminen paikasta toiseen. Sekvenssimalli Järjestelmä tulee toteuttaa kaikki tavoitteet, vaiheiden poisto/automatisointi, roolien vaihtaminen, käyttäjän toimintastrategiat. Artefaktimallit Voiko joitakin artefakteja automatisoida, poistaa tai tarjota helpommin? 2.4.4. Work redesign Work redesign -vaiheen tarkoituksena luoda järjestelmä, joka kehittää käyttäjänsä työkäytäntöjä. Ensimmäisenä työryhmä käy uudelleen läpi kaiken consolidationvaiheessa tuotetun tiedon. Yhdenmukaisuusseinän läpikäymisellä pyritään muistamaan mitä ja kenelle ollaan suunnittelemassa. Kaikkien suunniteltujen ominaisuuksia pitää helpottaa suunnittelun kohteen työtä tai toimintatapoja. Jokainen suunnitteluryhmän jäsen käy seinän läpi itsekseen ja voi tehdä samalla muistiinpanoja. Yhdistetyt mallit käydään läpi pareittain tai pienissä ryhmissä. Niistä keskustellaan ja tehdään muistiinpanoja. Jokaisella mallilla on oma roolinsa, eli mitä mallin pitää tuottaa. Ne ovat esitettyinä taulukossa 2.2. Mallien ja yhdenmukaisuusseinän läpikäymisen jälkeen vuorossa on visiointi. Ennen visiointia tehdään kaksi listaa: teknologia ja aloituskohdat. Teknologialistaan kirjoitetaan muistiin kaikki mahdolliset käytössä olevat teknologiat ja aloituskohtalistaan ehdotetaan mielenkiintoisia vision lähtökohtia, kuten hankitaan kaikille kannettavat päätelaitteet. Visiointi on ikään kuin aivoriihi, mutta siinä on ensisijaisena lähtökohtana asiakkaan tarpeet ja ennen visiointia tehdyt teknologia- ja aloituskohtalistat. Visiointitilaisuudessa ovat osallistujien lisäksi roolit kynä ja ohjaaja. Kynä piirtää kaikki ideat fläppitaululle ja ohjaaja päättää, ovatko ideat liian kaukana lähtökohdasta. Ideoita voidaan myös lisätä uusiksi lähtökohdiksi. Tässä vaiheessa visioita voidaan esittää ilman huolta niiden toteutusratkaisuista. Visiointitilaisuudessa käydään läpi useita lähtökohtia. Jokainen arvioidaan ja lopuksi yhdistetään parhaat puolet. Tavoitteena on saavuttaa yksi ratkaisu, jonka pohjalta tuotetta lähdetään suunnittelemaan.

19 Vision löytämisen jälkeen se esitetään kuvallisesti tarinataulun avulla. Tarinatauluun piirretään yhdistettyjen sekvenssimallien mukaista toimintojen todellista käyttöä. Mukaan voidaan ottaa dataa myös muista yhdistetyistä malleista. Tarinataulut ovat vain luonnoksia ja niin on tarkoituskin. Niihin piirretään myös interaktio muiden järjestelmien ja ihmisten välille. Vision avulla saadaan koko organisaatio toimimaan kohti yhteistä päämäärää. Se on pohja, jonka päälle insinöörit rakentavat lopullisen järjestelmän. 2.4.5. User environment design User enviroment design edustaa CD:ssä samaa asiaa kuin asunnon pohjapiirustus asuntosuunnittelussa. UED esittää kaikki ohjelmiston toiminnot, joilla on merkitystä loppukäyttäjän työn kannalta - mitä työn osaa mikäkin osa tukee ja miten ne liittyvät toisiinsa. UED:ssä ei oteta kantaa käyttöliittymään, jotta voidaan keskittyä vain rakenteeseen ja eri tehtävien väliseen vuorovaikutukseen. UED:n fokusalueet esittävät johdonmukaisesti ne asiat, jotka tukevat työn tekemistä ja niiden välisen vuorovaikutuksen. Uuden järjestelmän UED voidaan rakentaa esimerkiksi tarinataulujen pohjalta keräämällä kaikista tauluista toiminnot ja yhdistämällä ne siten, että kaikki toiminnot tulevat UED:hen. UED:n voi tehdä myös jo olemassa olevasta systeemistä, jolloin saadaan selville niiden rakenne ja löydetään ongelmakohdat. UED-vaiheen lopuksi kaavio käydään läpi. Tämä tapahtuu aina ennen kuin käyttöliittymää aletaan suunnitella. Läpikäymisen tarkoituksena on selvittää, ovatko fokusalueet yhdenmukaisia, tukevatko ne oikeaa työtä, ovatko toiminnot oikeita, ovatko fokusalueet selviä, ovatko fokusalueiden väliset linkit järkeviä ja tukeeko UED:n kuvaava järjestelmä työn tekemistä. UED on hyvin monipuolinen dokumentti. Sen avulla voidaan kehittää yrityksen prosesseja, koska ne ovat jo kuvattuna UED:hen. Se on apuna järjestelmän kehittämisessä, koska se tarjoaa tuotteen toiminnan, mutta ei ota kantaa käyttäjän interaktioon järjestelmän kanssa. Se kuvaa tuotteen tarkoituksen, joten siitä voidaan jatkaa kuvaamalla, mitä järjestelmä tekee. UED auttaa myös lopullisen järjestelmän testauksessa. Yhdessä tarinataulujen kanssa se sisältää tiedon, jota tarvitaan testauksen suunnittelussa ja aloituksessa. 2.4.6. Mock-up and test with customers CD:n viimeisessä suunnitteluvaiheessa otetaan mukaan loppukäyttäjä. Tässä vaiheessa pyritään varmistamaan, että UED on toimiva. Aluksi tehdään karkea käyttöliittymän prototyyppi, joka pohjautuu UED:hen. Sitä testataan loppukäyttäjien kanssa käyttötilanteessa. Sen tulokset käydään läpi suunnitteluryhmän kanssa, prototyyppiin ja UED:hen tehdään tarvittavat muutokset ja tätä iterointia jatketaan, kunnes tilanne

20 tasaantuu. Menetelmä antaa paljon ohjeita prototyypin rakentamista varten ja auttaa sen läpikäymistä loppukäyttäjän kanssa. 2.4.7. Completing the Design Contextual Design saavuttaa lopputilansa, kun iteraatiot ovat saavuttaneet tasapainotilan. Tämän jälkeen pidetään vielä yksi palaveri jossa varmistetaan, että suunnitelmassa on kaikki tarpeellinen asia. Viimeisenä suunnitelma dokumentoidaan käyttäen kunkin yrityksen omaa dokumentointimenetelmää.[howewo2005] UED:n avulla järjestelmä voidaan jakaa sopiviin toteutuskokonaisuuksiin, jotta heti ensimmäinen versio on hyödyllinen. UED auttaa myös toteutustiimiä jakamaan toteutuksen luokkiin ja olioihin. 2.5. Goal Directed Design Goal Directed Design eli tavoiteohjattu suunnittelu on Alan Cooperin kehittämä käyttäjäkeskeisen suunnittelun menetelmä [CoRe2003]. Se yhdistää etnografian, asianomistajahaastattelut, markkinatutkimuksen, tuote- ja kirjallisuusanalyysit, yksityiskohtaiset käyttäjämallit, käyttötapauspohjaisen suunnittelun sekä tärkeimmät vuorovaikutusmallit ja periaatteet. Goal Directed Design tarjoaa ratkaisumallin, joka ottaa huomioon loppukäyttäjän tarpeet ja tavoitteet. Malli koostuu kuudesta vaiheesta, jotka käydään läpi tässä kohdassa. Vaiheiden sisältö käy ilmi lyhyesti kuvasta 2.9 Prosessikuvaus perustuu lähteeseen [CoRe2003], ellei toisin mainita.

21 Kuva 2.9 Goal Directed Designin vaiheet. [CoReCr2003] 2.5.1. Tutkimus Tutkimusvaiheessa käytetään etnograafisia kenttätutkimuksia, toisin sanoen tarkkailua ja kontekstitutkimuksia, jotta saadaan laadullista tietoa potentiaalisista tai todellisista tuotteen käyttäjistä. Goal Directed Designissa tutkimusvaihe on kvalitatiivinen, koska se auttaa suunnittelijaa ymmärtämään tuotteen ympäristön paremmin kuin määrällinen tutkimus. Laadullisen tutkimuksen avulla opitaan ymmärtämään käyttäjien ja potentiaalisten käyttäjien käyttäytymistä paremmin kuin määrällisessä tutkimuksessa. Lisäksi laadullinen tutkimus on huomattavasti edullisempaa ja nopeampaa kuin määrällinen tutkimus. Cooper jakaa tutkimusvaiheen seuraaviin osiin: - asianomistajahaastattelut - asiantuntijahaastattelut - käyttäjä- ja asiakashaastattelut

22 - kirjallisuustarkastelut - tuotteen/ prototyypin/ kilpailevien tuotteiden arviointi. Asianomistajahaastattelut. Vaikka tutkimusvaiheen päätarkoitus onkin käyttäjän ymmärtäminen, se pitää ja kannattaa aloittaa asianomistajahaastatteluilla. Asianomistajahaastattelujen aikana suunnittelija saa kokonaiskuvan yrityksen toiminnasta ja teknisestä ympäristöstä, jossa tuote rakennetaan. Asianomistajahaastattelut eivät ainoastaan auta hyvän tuotteen suunnittelussa, vaan ne auttavat löytämään myös yhteisen kielen ja ymmärryksen suunnittelutiimin, asiakkaan johdon ja teknisen tiimin välille. Asianomistajat ovat yleensä asiakasyrityksen avainhenkilöitä markkinoinnista, myynnistä, tekniseltä osastolta, markkinointiviestinnästä, asiakaspalvelusta ja käytettävyydestä. Asianomistajahaastattelut suositellaan tehtäväksi yksilöhaastatteluina ennen käyttäjätutkimuksen aloittamista. Yhden haastattelun ei tarvitse kestää tuntia pidempään. Asianomistajahaastattelujen jälkeen suunnittelutiimin pitäisi pystyä palvelemaan omaa asiakastaan ja suunniteltavan tuotteen loppukäyttäjää paremmin. Asianomistajahaastatteluissa pitäisi kerätä seuraavaa tietoa: - Mikä on suunniteltavan tuotteen ensisijainen visio? - Mikä on tuotteen aikataulu ja budjetti? - Millaisia teknisiä rajoitteita tuotteella on? - Mitkä lähtökohdat liiketoiminnalla on? - Millainen mielikuva asianomistajalla on loppukäyttäjästä? Asiantuntijahaastattelut. Jotkut asianomistajat voivat olla asiantuntijoita, mutta useimmiten asiantuntijat ovat henkilöitä, jotka ovat olleet tekemisissä suunniteltavan tuotteen tai sen edeltäjien kanssa. Asiantuntijahaastatteluja ei aina tarvita, ja niiden tekemisen yhteydessä kannattaa muistaa, että jotkut ovat voineet tottua nykyisen tuotteen käyttäytymiseen niin paljon, että heidän mielipiteensä ovat vääristyneitä. Asiantuntijahaastatteluihin kannattaa siis suhtautua varauksella. Asiantuntijoita voidaan käyttää myös tuotteen suunnittelun edetessä varmistamaan tuotteen toimivuutta ja oikeaa sisältöä. Kirjallisuusanalyysi. Asianomistajahaastattelujen kanssa samanaikaisesti voidaan tehdä kirjallisuusanalyysiä. Tähän analyysiin voi kuulua esimerkiksi liiketoimintaympäristöön liittyviä tutkimuksia, mutta myös asiakkaan omia dokumentteja, esimerkiksi markkinointimateriaaleja tai teknisiä dokumentteja. Tämän kirjallisuuden sisällöstä voidaan kehittää asianomistaja- ja asiantuntijahaastattelujen kysymyksiä.