Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta

Koko: px
Aloita esitys sivulta:

Download "Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta"

Transkriptio

1 Aalto-yliopisto Informaatio- ja luonnontieteiden tiedekunta Tietotekniikan tutkinto-ohjelma Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta Kandidaatintyö 2. joulukuuta 2010 Frans Joonas Wärn

2 Aalto-yliopisto Informaatio- ja luonnontieteiden tiedekunta Tietotekniikan tutkinto-ohjelma Kandidaatintyön tiivistelmä Tekijä: Frans Joonas Wärn Työn nimi: Käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistäminen prosessimallien näkökulmasta Päiväys: 2. joulukuuta 2010 Sivumäärä: iii + 36 Vastuuopettaja: Professori Ilkka Niemelä Työn ohjaajat: TkL Johanna Viitanen TkT Casper Lassenius Tuotteen käytettävyyttä voidaan edistää käyttämällä kehitystyössä apuna käyttäjäkeskeistä suunnittelua, joka integroidaan osaksi olemassaolevaa ohjelmistokehitysprosessia. Käyttäjäkeskeiset suunnittelumenetelmät ovat olennainen täydennys ohjelmistokehityksen menetelmiin ja prosessimalleihin, jotka ovat usein yksinään käytettävyyden näkökulmasta riittämättömiä. Ohjelmistokehityksessä ovat viime vuosina niin kutsutut ketterät menetelmät kasvattaneet huomattavasti suosiota, mutta niitä on yhtälailla syytetty riittämättömiksi käytettävyyden näkökulmasta. Tässä työssä on tutkittu käyttäjäkeskeisen suunnittelun ja ketterien menetelmien yhdistämistä prosessimallien näkökulmasta ja esitellään havaitut edut ja ongelmat. Ongelmien osalta käydään lisäksi läpi niihin ehdotettuja ratkaisuja. Tutkimustyössä rajoituttiin ketterien menetelmien osalta XP:hen ja Scrumiin. ja käyttäjäkeskeisten suunnittelumenetelmien Usability Engineering Life Cycleen, ISO :een ja LUCIDiin. Verrattaessa perinteisiin kehitysmenetelmiin havaittiin tutkimuksessa ketteriin menetelmiin liittyvän sekä selkeitä etuja että ongelmia käyttäjäkeskeisen suunnittelun näkökulmasta. Ongelmien ratkaisuksi ehdotettuja ideoita löytyi myös runsaasti, mutta lähes poikkeuksetta ehdotusten todellisesta kyvystä ratkaista ongelmia ei esitetty empiiristä tutkimusnäyttöä lainkaan tai se pohjautui tutkijoiden subjektiivisiin arvioihin. Avainsanat: Kieli: ketterä, scrum, xp, käytettävyys, käyttäjäkeskeinen suunnittelu Suomi i

3 Sisältö 1 Johdanto 1 2 Tausta Ohjelmistokehityksen prosessimallit Paradigmat Vesiputousmalli Iteratiivinen kehitys Ketterät menetelmät Käyttäjäkeskeinen suunnittelu Yhteenveto Yhdistämisessä havaittuja etuja Iteratiivisuus Käyttäjä mukana kehitystyössä Ei jäykkää vaatimusmäärittelyä Ketterien menetelmien parantaminen käyttäjäkeskeisin suunnittelumenetelmin Yhdistämisessä havaittuja ongelmia Iteratiivisuuden nopeus Kulttuurierot Eri näkemys käyttäjästä ii

4 5 Keinoja ongelmien ratkaisemiseksi Muutoksia syklijärjestelmään Käyttöliittymäsuunnittelun jakaminen osiin Kevyempiä käyttäjäkeskeisiä menetelmiä Käytettävyysasiantuntijoiden ulosanti ketteräksi Käytettävyysasiantuntija edustamaan käyttäjää Yhteenveto ja pohdinta 30 Lähteet 33 iii

5 Luku 1 Johdanto Tuotteen käytettävyyttä voidaan edistää käyttämällä kehitystyössä apuna käyttäjäkeskeistä suunnittelua (engl. user-centred design). Käytännössä tämä toteutetaan integroimalla käyttäjäkeskeinen suunnittelu ja sen periaatteet osaksi olemassaolevaa ohjelmistokehitysprosessia. Käyttäjäkeskeiset suunnittelumenetelmät ovatkin olennainen täydennys ohjelmistokehityksen menetelmiin ja prosessimalleihin, jotka ovat usein yksinään käytettävyyden näkökulmasta riittämättömiä. Ohjelmistokehityksessä 2000-luvun trendi on ollut ketterien menetelmien suosion kasvu. Niitä on yhtälailla syytetty yksistään riittämättömiksi käytettävien ohjelmistojen tuottamiseen. Ketterät menetelmät ovat kuitenkin käyttäjäkeskeisen suunnittelun näkökulmasta mielenkiintoinen muutos, vaikka useimmat käyttäjäkeskeisen suunnittelun menetelmät ja ohjeistot väittävät olevansa riippumattomia ohjelmistokehitysprosessista johon ne integroidaan. Väitteisiin on kuitenkin syytä suhtautua varauksella, onhan koko käyttäjäkeskeisen suunnittelun synnyn edellytys ollut olemassaolevien prosessimallien puutteet. Lähtökohta vaikuttaa lupaavalta, ketterät menetelmät näyttävät nimittäin painottavan samoja teemoja kuin käyttäjäkeskeinen suunnittelukin: iteratiivista kehitystyötä ja käyttäjän tuomista lähemmäksi suunnittelu- ja toteutusprosessia. Syvemmälle mennessä kuitenkin paljastuu, että käyttäjäkeskeisen suunnittelun yhdistämisessä ketteriin menetelmiin esiintyy ihan uusia ongelmia. Tämä tutkimus pyrkii vastaamaan kahteen kysymykseen: Mitä etuja ja ongelmia kohdataan kun käyttäjäkeskeisiä suunnittelumetodeja yritetään yhdistää ketteriin ohjelmistokehitysprosesseihin? 1

6 LUKU 1. JOHDANTO 2 Mitä ratkaisuja edellämainittuihin ongelmiin on ehdotettu? Näkökulmaksi on valittu prosessimallit ja niiden yhteensovittaminen. Tarkastelun ulkopuolelle on siten jätetty ketterien menetelmien osalta muut kuin välittömästi prosessimalleihin liittyvät toimintatavat ja ohjeistot. Lisäksi ketterien menetelmien osalta rajoitutaan XP:n (Extreme Programming) ja Scrumin prosessimallien tarkasteluun. Käyttäjäkeskeisten suunnittelumenetelmien osalta rajoitutaan tarkastelussa Usability Engineering Life Cyclen, ISO :n ja LUCIDin esittelemiin periaatteisiin ja suosituksiin. Tutkimuksessa esitellään ensin taustatietoa ohjelmistokehityksen prosessimalleista ja paradigmoista, mukaanlukien ketterät menetelmät. Taustatiedon parissa jatketaan käyttäjäkeskeisen suunnittelun periaatteilla ja suosituksilla. Taustan jälkeen siirrytään tarkastelemaan ketterien menetelmien ja käyttäjäkeskeisen suunnittelun yhteensovittamisessa havaittuja etuja ja ongelmia. Lopuksi käydään läpi yhdistämisessä havaittuihin ongelmiin esitettyjä ratkaisuja, ennen loppuyhteenvetoa ja pohdintaa.

7 Luku 2 Tausta 2.1 Ohjelmistokehityksen prosessimallit Tässä luvussa esitellään ohjelmistokehityksen tunnetuimpia prosessimalleja. Niitä voidaan jäsentää monella tavalla ja alan kirjallisuutta lukemalla voi nopeasti saada tuntuman, että määrityksiä on yhtä monta kuin määrittelijöitä. Tässä tutkimuksessa tehdyt jaoittelut ja määritelmät pohjautuvat Sommervillen (2007) näkemykseen. Ohjelmistoprosessi (engl. software process) on tapahtumasarja, jonka tarkoituksena on tuottaa valmis ohjelmistotuote tai -järjestelmä. On kolme perustoimintoa, jotka ovat yhteisiä kaikille ohjelmistoprosesseille: määrittely (engl. software specification), kehitys (engl. software development) ja todennus (engl. software validation). Ohjelmistokehityksen prosessimalli (engl. software process model) on yksinkertaistettu kuvaus ohjelmistoprosessista, joka edustaa yhtä näkökulmaa tähän prosessiin. Prosessimallit voivat sisältää toimia jotka ovat osa ohjelmistoprosessia, ohjelmistokomponentteja, sekä rooleja joita eri ihmisillä on osana ohjelmistokehitystä. Ohjelmistokehityksen paradigmat (engl. paradigm of software development) ovat yleisiä prosessimalleja, joihin ohjelmistokehityksen prosessimallit perustuvat. 3

8 LUKU 2. TAUSTA Paradigmat Ohjelmistokehityksen paradigmoja kutsutaan lähteestä riippuen myös ohjelmistokehityksen yleisiksi prosessimalleiksi (engl. general process model), lähestymistavoiksi (engl. approach), elinkaariksi (engl. life cycle) tai viitekehyksiksi (engl. framework). Sommervillen (2007) mukaan useimmat ohjelmistokehityksen prosessimallit perustuvat yhteen kolmesta paradigmasta: Vesiputousmalli (engl. waterfall model/approach) Tässä lähestymistavassa ohjelmistoprosessin perustoiminnot ovat prosessissa ajallisesti toisiaan seuraavia vaiheita ja ne suoritetaan yksi kerrallaan toisensa jälkeen. Vesiputousta kutsutaan myös usein lineaariseksi lähestymistavaksi. Iteratiivinen kehitys (engl. iterative development) Tässä lähestymistavassa ohjelmistoprosessin perustoiminnot sijoittuvat ajallisesti limittäin. Ensimmäinen versio järjestelmästä kehitetään nopeasti hyvin abstrakteista määrittelyistä. Tämän jälkeen ohjelmistoa parannellaan asiakkaan palautteen perusteella niin että lopulta pystytään tuottamaan ohjelmisto joka täyttää kaikki asiakkaan tarpeet ja vaatimukset. Komponenttipohjainen ohjelmistotekniikka (engl. component-base software engineering) Tämä lähestymistapa olettaa että osa järjestelmästä on jo olemassa. Prosessi keskittyy eri osien integrointiin sen sijasta että niitä kehitettäisiin tyhjästä. On myös useita prosessimalleja, jotka perustuvat useampaan paradigmaan, kuten esimerkiksi Rational Unified Process (RUP) joka yhdistelee piirteitä kaikista kolmesta. (Sommerville, 2007) Seuraavissa luvuissa käsitellään kaksi ensinnä mainittua paradigmaa. Viimeisintä paradigmaa ei tässä tutkimuksessa sen sijaan käsitellä tarkemmin. On myös huomattava, etteivät kaikki Sommervillen tapaan miellä komponenttipohjaista ohjelmistotekniikkaa samantasoiseksi paradigmaksi ensinnämainittujen kanssa Vesiputousmalli Vesiputousmalli on ohjelmistokehityksen tunnetuin prosessimalli. Syynä lienee sen selkeys ja ymmärrettävyys myös maallikoille. Mallin juuret ovat järjestelmäsuunnittelun (engl. systems engineering) prosessimalleissa, joista se

9 LUKU 2. TAUSTA 5 on lainattu ohjelmistokehityksen käyttöön tietokoneiden alkutaipaleella luvulla (katso esimerkiksi Benington, 1983). Puhdasoppinen vesiputousmalli tarkoittaa lineaarisesti vaihe vaiheelta etenevää prosessia, jossa yhden vaiheen ollessa valmis, siirrytään seuraavaan (kuva 2.1). Tyypillisesti kunkin vaiheen tuotoksena syntyy dokumentti tai dokumentteja, joiden hyväksyntä oikeuttaa seuraavaan vaiheeseen siirtymisen. Tästä syystä vesiputousmallia luonnehditaan dokumenttiohjatuksi (engl. document-driven) prosessimalliksi. Kuva 2.1: Vesiputousmalli (kuva Royce, 1987, s. 329) Usein vesiputousmalli yhdistetään Roycen paperiin vuodelta 1970 (Royce, 1987). Tähän viittaaminen on kuitenkin kyseenalaista. Royce esittää kyllä paperissaan vesiputousmallia vastaavan mallin (käyttämättä tosin tätä nimistystä), mutta ainoastaan ohimennen esimerkkinä prosessimallista joka ei voisi käytännössä ikinä toimia kuin ihan pienimpien projektien kanssa (tämä prosessimalli esiintyy kuvassa 2.1). Sen sijaan hän esittelee paperin lopputuloksena tästä huomattavasti poikkeavan mallin (Royce, 1987, s. 338), joka sisältää piirteitä iteratiivisesta paradigmasta. Ironisesti hänen paperistaan on kuitenkin useimmissa yhteyksissä jäänyt elämään vain se osuus, jota hän itsekin jo alunperin kritisoi. Useat asiantuntijat (muun muassa Cockburn, 1993) ovat sitä mieltä, ettei

10 LUKU 2. TAUSTA 6 niin sanotun puhdasoppisen vesiputousmallin noudattaminen käytännössä ole mahdollista, ja että nekin jotka väittävät näin tekevänsä, todellisuudessa käyttänevät jollain tavoin sisäisesti inkrementaalista lähestymistapaa (katso seuraava luku). Vesiputousmalli voidaan tosin käsittää myös vähemmän puhdasoppisena, jolloin vaiheet voivat olla osittain päällekkäisiä ja tarvittaessa aiempiin suljettuihin vaiheisiin voidaan palata tekemään muutoksia. Monet näkevät tässä tapauksessa mallin edelleen käyttökelpoisena (näin myös esimerkiksi Sommerville, 2007), osa taas on sitä mieltä ettei vesiputousmalli ole milloinkaan hyvä ajatus ohjelmistokehityksen prosessimalliksi Iteratiivinen kehitys Iteratiivinen kehitys, jota nimitetään myös evolutiiviseksi kehitykseksi (engl. evolutionary development) on paradigma jonka ydin on kehitysprosessin (ja siten sen perustoimintojen määrittelyn, kehityksen ja todennuksen) toistaminen useita kertoja ohjelmistoprosessin aikana. Päinvastoin kuin vesiputousmallissa, prosessia ei siis suoriteta vain kertaalleen alusta loppuun, vaan sitä toistetaan useampia kertoja. Nykyään käsitteeseen ymmärretään vaiheiden toiston lisäksi liittyvän myös ohjelmiston parantelu ennakoitavaa prosessia noudattaen. Inkrementaalisella kehityksellä (engl. incremental development) puolestaan viitataan siihen, että ohjelmiston osat kehitetään eri aikaan tai eri tahdissa ja integroidaan niiden valmistuttua. Iteratiivinen kehitys ilman inkrementaalisuutta tarkoittaa, että koko ohjelmisto kehitetään kerralla, mutta sen pariin palataan uudelleen seuraavassa iteraatiossa, tarkoituksena parantaa aiempaa versiota. Inkrementaalinen kehitys ilman iteratiivisuutta puolestaan viittaa prosessiin, jossa ohjelmiston eri osat kehitetään täysin valmiiksi ja lopullisiksi ennen integroimista. (Cockburn, 1993) Iteratiivis-inkrementaalisella kehityksellä viitataan prosessimalliin, jossa prosessi on toistuva ja ohjelmistoa rakennetaan pala palalta kohti täydellistä versiota. Iteratiivisuus ja inkrementaalisuus kulkevatkin ohjelmistokehityksessä lähes aina käsi kädessä. Ideana on rakentaa ensin minimaalinen lähtöversio ja sen jälkeen lisätä uusia osioita ja ominaisuuksia sekä parantaa olemassaolevia osia, julkaisten tasaisin väliajoin uusia yhä täydellisempiä versiota siihen saakka kunnes tuote tai järjestelmä on lopulta riittävä. Vähemmän ohjelmistokehityksen historiaa tuntevat saattavat kuvitella iteratiivis-inkrementaalisten prosessimallien olevan moderni, ketterien mene-

11 LUKU 2. TAUSTA 7 telmien myötä esiin noussut lähestymistapa. Iteratiivis-inkrementaalisen kehityksen historia alkaa kuitenkin ihan yhtä kaukaa kuin vesiputousmallinkin (Larman ja Basili, 2003). Mielenkiintoinen huomio on myös aiemmin viitatun Beningtonin (1983) esipuhe vuoden 1956 paperin uudelleenjulkaisussa, jossa hän paljastaa SAGE-projektissa (josta hän paperinsa vesiputousmallia noudattavan prosessikuvauksen kirjoitti) kehitystyötä käytännössä tehdyn myös inkrementaalisin menetelmin Ketterät menetelmät Ketterät menetelmät (engl. agile methods) ovat iteratiivis-inkrementaalisen paradigman ohjelmistokehitysmenetelmiä, edustaen arvoja jotka käyvät ilmi ketterästä manifestista : Olemme päätyneet arvostamaan Yksilöitä ja vuorovaikutusta enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista (Beck et al., 2001, käännös Wikipedia) Ketterät menetelmät keskittyvät nopeaan ensimmäisen toimivan ohjelmistoversion toimittamiseen, inkrementaaliseen julkaisuun, tiimin tiiviiseen kommunikointiin ja yhteistyöhön, sekä nopeaan ja vaivattomaan kykyyn vastata muutoksiin. Yhden näkemyksen mukaan ketterien menetelmien voidaan katsoa syntyneen ratkaisemaan ongelma, jonka Nandhakumar ja Avison (1999) havaitsevat suurta kehitysorganisaatiota seuratessaan. He väittävät, että tietojärjestelmien perinteiset kehitysmetodologiat ovat vain kuvitelma tarpeellisen kontrollivaikutelman ja symbolisen statusarvon luomiseksi, ja ne ovat liian mekaanisia ollakseen paljoakaan hyödyksi kehittäjien tehtävien päivittäisessä organisoinnissa. Abrahamsson et al. (2002) jatkavat tämän tutkimuksen päälle ja toteavat ketterien menetelmien mallintavan huomattavasti paremmin kehitystyön todellisuutta, ja siten todennäköisesti vastaavan ohjelmistokehittäjien tarpeisiin paremmin kuin perinteiset näkökulmat ohjelmistokehitykseen. Vaihtoehtoisena näkemyksenä Armitage (2004) esittää, että ketterät menetelmät saattoivat olla ratkaisu hyvien ohjelmistosuunnittelijoiden, arkkitehtien ja strategien puutteeseen. Armitagen mukaan ohjelmistot ovat vaikeita mallintaa

12 LUKU 2. TAUSTA 8 ja ketterät menetelmät voidaan nähdä raa an voiman (engl. brute-force) menetelmänä saada hyväksyttävä työ aikaiseksi ilman suunnitelmaa tai suunnittelijoita. Ketteristä menetelmistä tunnetuimpia ovat XP ja Scrum, joiden tarkasteluun tässä tutkimuksessa keskityttiin. Kummankin tapauksessa kehityssyklit ovat aikarajoitettuja ja tyypilliseltä pituudeltaan viikosta neljään. Prosessin näkökulmasta merkittävin uutuus aiempaan verrattuna on näiden verrattain lyhyiden syklien tuoma nopea iteratiivisuus ja lähes olematon määrittelyvaihe (yhden kokouksen mittainen). XP (Beck ja Andres, 2004) on vuosituhannen vaihteessa näyttävimmin pinnalle noussut ketteristä menetelmistä. Beck ja Andres listaavat XP:n arvoiksi tiiviin kommunikoinnin niin tiimin sisällä kuin sidosryhmien kanssa, yksinkertaiset suunnitteluratkaisut, jatkuvan palautteen vastaanoton eri tasoilla, rohkeuden, sekä kunnioituksen muita tiimin jäseniä kohtaan. XP:n periaatteet ja toimintavat puolestaan pohjautuvat näihin arvoihin. XP metodologiana keskittyy näiden hyvin pragmaattiselle tasolle menevien toimintatapojen ympärille ja luottaa paljolti itseohjaavien tiimien kykyyn parhaiten organisoida oma työnsä. months weeks Releaseplan days hours Iteration plan minutes Acceptance Test Stand up meeting Pair Negotiation Unit Test Pair Programming Code Kuva 2.2: XP:n prosessin ydin, palautesilmukka (CC-BY-SA Marcel Dekker)

13 LUKU 2. TAUSTA 9 Scrum katsoo ketteryyttä XP:tä enemmän projektinhallinnan näkökulmasta. Se voidaan nähdä prosessin rungon kuvauksena johon kuuluvat tietyt roolit ja prosessimalli, mutta vähemmän toimintatapoja. Rooleja ovat scrummaster, joka löyhästi määritellen voidaan nähdä projektipäällikköä vastaavana roolina, tuoteomistaja (engl. product owner), joka toimii kehitystiimin ulkopuolisten sidosryhmien ja erityisesti asiakkaan ja kaupallisten realiteettien edustajana, sekä itse kehitystiimi, jonka vastuulla on varsinainen ohjelmistokehitys. XP:n tavoin kehitystiimi on hyvin itseohjaava, eikä scrummaster ei ole varsinaisesti tiimin johtaja, vaan ainoastaan avustaa tiimiä ongelmien ratkaisussa. 24 h 30 days Product Backlog Sprint Backlog Sprint Working increment of the software Kuva 2.3: Scrumin prosessimalli (CC-BY-SA LakeWorks) Scrumissa prosessimalli on kohtuullisen yksinkertainen (kuva 2.3). Tuoteomistaja ylläpitää tuotteen kehitysjonoa (engl. product backlog), josta kehitystiimi poimii joka sprintin (scrumin nimitys kehityssyklille) alussa tietyn määrän ominaisuuksia sprintin tehtävälistaan (engl. sprint backlog). Kehitystiimi kokoontuu joka päivä maksimissaan 15 minuutin pituisissa seisomapalaverissa, jossa käydään läpi edistymistä ja kehitystyön esteenä olevia ongelmia. Sprintin lopussa saavutettu lopputulos esitellään tuoteomistajalle ja muille kiinnostuneille sidosryhmäläisille ja aloitetaan sitten uusi sprintti. XP ja Scrum noudattavat kumpikin samaa filosofiaa, suurimpana erona ehkä se, että XP on keskittynyt enemmän kehityksessä käytettyjen toimintapojen ja -menetelmien tarkasteluun, kun taas Scrum enemmän projektinhallintaan littyviin asioihin. Koska varsinaista ristiriitaa niiden välillä ei ole, voidaan ne myös sovittaa yhteen (Vriens, 2003).

14 LUKU 2. TAUSTA Käyttäjäkeskeinen suunnittelu Käyttäjäkeskeinen suunnittelu (engl. User-centred Design tai Human-centred Design) on vuorovaikutteisten järjestelmien suunnittelemisen ja kehittämisen lähestymistapa, joka keskittyy järjestelmien käytettävyyteen. Käytettävyys (engl. Usability) puolestaan on mitta, miten hyvin määrätyt käyttäjät voivat käyttää tuotetta tietyssä käyttötilanteessa saavuttaakseen määritetyt tavoitteet tuloksellisesti, tehokkaasti ja tyytyväisinä. (ISO :2010) Sharp et al. (2007, s. 14) määritelmän mukaisesti käyttäjäkeskeisiin suunnittelumenetelmiin perehtyneitä henkilöitä kutsutaan käyttöliittymäsuunnittelijoiksi (engl. user interface designer) ja tuotteiden käytettävyyttä arvioivia henkilöitä käytettävyysinsinööreiksi (engl. usability engineer). Tässä tutkimuksessa on pyritty käyttämään näitä käsitteitä silloin kun on haluttu painottaa eroa näiden välillä. Muissa tapauksissa on käytetty yleisempää käsitettä käytettävyysasiantuntija (tämä on verrattavissa Sharp et al. englanninkieliseen määritelmään user experience designer/architect/researcher). Käyttäjäkeskeisellä suunnittelulla sanotaan myös usein olevan omia prosessimallejaan, viitaten esimerkiksi Usability Engineering Life Cycleen (Nielsen, 1992), ISO :aan (ISO :2010) ja LUCIDiin (Kreizberg, 2008). Tutustumalla näihin kolmeen selviää kuitenkin ettei mikään niistä ota kantaa tuotteen varsinaiseen kehittämiseen, vaan tarkastelee ainoastaan käyttöliittymäsuunnittelijoiden tehtäviä. Näistä kahden ensimmäisen sisältöä voi prosessimallin sijasta ajatella tarkistuslistoina kohdistettavaksi varsinaiseen tuotekehitysprosessiin. LUCID taas sisällyttää ohjelmistokehityksen kokonaisuudessaan yhden vaiheen sisään, eikä ota sen sisältöön mitään kantaa. Seuraavissa kappaleissa esitellään nämä kolme tarkemmin. Usability Engineering Life Cycle (Nielsen, 1992) sisältää suosituksen kymmenestä toiminnosta, jaoiteltuna vaiheen mukaan. Ennen suunnittelua Nielsen suosittelee (1) tunnistamaan käyttäjän, (2) analysoimaan kilpailevia tuotteita ja (3) asettamaan käytettävyystavoitteet. Suunnittelun aikana (4) ottamaan käyttäjän mukaan suunnitteluun, (5) suunnittelemaan käyttöliittymän koordinoidusti kokonaisuutena, (6) käyttämään käyttöliittymäohjeistuksia ja heuristisia analyyseja, (7) tekemään prototyyppejä, (8) testaamaan käyttöliittymää ja (9) suunnittelemaan iteratiivisesti. Suunnittelun jälkeen (10) keräämään palautetta kentältä. Nielsenin mukaan hyötyjen saavuttamiseksi ei ole välttämätöntä ottaa käyttöön kaikkia näitä toimintoja, vaan jo osittaisellakin hyödyntämisellä parannetaan käytettävyyttä.

15 LUKU 2. TAUSTA 11 Standardi vuorovaikutteisten järjestelmien käyttäjäkeskeisestä suunnittelusta (ISO :2010) sisältää suosituksia suunnittelutoiminnoista interaktiivisten järjestelmien toteuttamiseen. ISO julkaistiin maaliskuussa 2010, syrjäyttäen vanhemman ISO standardin (SFS-EN ISO 13407:1998). Mielenkiintoisimmat muutokset tämän työn kannalta olivat sanan prosessi poistuminen standardin nimestä, sekä iteraation tarkentaminen koskemaan koko suunnitteluprosessia, eikä pelkästään käytettävyysarviointia. Standardi esittää käyttäjäkeskeisen suunnittelun pohjana olevan kuusi yleistä periaatetta, jotka ovat riippumattomia käytetyistä prosessimalleista tai suunnittelumenetelmistä: Suunnittelu pohjautuu yksikäsitteiseen ymmärrykseen käyttäjistä, tehtävistä ja ympäristöstä. Käyttäjät ovat osallisina suunnittelu- ja kehitystyössä koko tämän työn ajan. Suunnittelua ohjataan ja jalostetaan käyttäjäkeskeisillä arvioinneilla. Prosessi on iteratiivinen. Suunnittelu huomioi koko käyttäjäkokemuksen. Suunnitteluryhmä edustaa monialaisia taitoja ja perspektiivejä. Näiden periaatteiden lisäksi standardi esittää neljä käyttäjäkeskeistä suunnittelutoimintoa, joiden tulisi olla osa jokaista interaktiivisen järjestelmän kehitysprojektia. Nämä suunnittelutoiminnot ja niiden keskinäinen suhde esitetään kuvassa 2.4. Usein tämä standardissa esitetty kaavio mielletään virheellisesti tuotekehityksen prosessimalliksi käyttäjäkeskeisestä näkökulmasta, mutta tosiasiallisesti se korkeintaan ilmaisee missä järjestyksessä käyttäjäkeskeisiä suunnittelutoimintoja tulisi tehdä. Sen sijaan standardi neuvoo (ISO :2010, luku 5) miten liittää suunnittelutoiminnot osaksi tuotteen kehitysprosessia. Tämä prosessin suunnitteluvaihe tulisi tehdä ensimmäisenä ennen varsinaisia käyttäjäkeskeisiä suunnittelutoimintoja, kuten kuvasta 2.4 ilmenee. LUCID (Kreizberg, 2008) on käyttäjäkeskeisen suunnittelun viitekehys, joka sisältää kuusivaiheisen prosessimallin tuotteen suunnitteluun. Neljä ensimmäistä vaihetta liittyvät tuotteen käyttöliittymän määrittelyyn ja suunnitteluun. Varsinainen tuotteen kehittäminen (sisältäen tuotteen määrittelyn ja

16 LUKU 2. TAUSTA 12 Suunnittele käyttäjäkeskeinen suunnitteluprosessi Järjestelmä täyttää vaatimukset Ymmärrä ja määrittele käyttötilanne Määrittele käyttäjävaatimukset Tuota suunnitteluratkaisuja Arvioi suunnitelmat Iteroi Kuva 2.4: Käyttäjäkeskeisten suunnittelutoimintojen liittyminen toisiinsa suunnittelun muun kuin käyttöliittymän osalta) sijoittuu prosessin viidenteen vaiheeseen ja julkaisu kuudenteen. Kreizbergin mukaan hänen mallissaan käyttöliittymäsuunnittelijoiden ja kehittäjien väliseen kanssakäymiseen on vain hyvin vähän tarvetta, koska kehittäjät saavat täydelliset määrittelyt ennen työnsä aloittamista. LUCIDia voisikin ihan aiheellisesti kutsua käyttäjäkeskeiseksi vesiputousmalliksi. Kreizbergin suhtautuminen ketteriin menetelmiin on irrationaalinen ja tähän liittyvä argumentointi ontuvaa. Hänen mukaansa LUCID on ketterä prosessi, koska suunnittelu suoriutuu luonnostaan parhaiten iteratiivisella tavalla. (Kreizberg, 2008, käännös kirjoittajan). Kreizberg esittää, että LUCID soveltuu hyvin sovellettavaksi myös iteratiivisten kehitysmenetelmien kanssa, kunhan kaikki kehitys suoritetaan hänen mallinsa viidennessä vaiheessa. Voinee väittää, ainakin kärjistämällä, ettei LUCIDia voi integroida minkään ohjelmistokehityksen prosessimallin kanssa, vaan ohjelmistokehityksen prosessi voidaan ainoastaan upottaa LUCIDin viidenteen vaiheeseen. Toisinsanoen LUCID ei tue minkäänlaista käyttöliittymäsuunnittelun ja ohjelmistokehityksen rinnakkaisuutta. 2.3 Yhteenveto Yhdistämistä silmälläpitäen käyttäjäkeskeisten suunnittelumenetelmien suurin ongelma on se, etteivät ne ota juurikaan kantaa varsinaiseen ohjelmistoke-

17 LUKU 2. TAUSTA 13 hitykseen. Täten ne eivät pysty riittävästi huomioimaan käytännön ohjelmistokehityksessä tapahtuvia muutoksia. Scott (2009) tuo esille, että tapa kehittää ohjelmistoja on muuttunut paljon viimeisen kymmenen vuoden aikana ja että käytettävyysalan on tarpeellista muuttua tämän mukaisesti. Tänä päivänä ohjelmistoja tehdään iteratiivisesti ja paljon nopeammalla syklillä kuin aiemmin. Siinä missä ennen käytettävyystestausta tehtiin paperiprotoilla, tänä päivänä sitä tehdään oikealla tuotteella, jota voidaan muokata reaaliajassa. (Scott, 2009) LUCIDin kohdalla voimme lisäksi todeta tilanteen vielä ongelmallisemmaksi. Sitä ei ole tarkoitettu varsinaisesti integroitavaksi ollenkaan, vaan kehitystyö sisältyy kiinteästi sen yhden vaiheen sisälle. Tämä ei sovi ketterien menetelmien filosofian kanssa yhteen ollenkaan. Silminpistävin ketterien menetelmien ongelma käyttäjäkeskeisen suunnittelun kannalta on se, etteivät nämä sisällä ollenkaan erillistä vaihetta vaatimusmäärittelylle tai suunnittelulle, vaan ohjelmakoodin ja toteutuksen pariin mennään samantien. Ongelma tämä on siksi, että useat käyttäjäkeskeiset suunnittelumenetelmät odottavat löytävänsä prosessista vaiheita ennen käyttöliittymän implementointiin siirtymistä.

18 Luku 3 Yhdistämisessä havaittuja etuja Tässä luvussa käydään läpi ketterien menetelmien ja käyttäjäkeskeisen suunnittelun yhdistämisessä havaittuja etuja (verrattuna ketteriä menetelmiä perinteisiin ohjelmistokehitysmenetelmiin). Havaittiin kolme selkeää etua: iteratiivisuus, käyttäjän osallistuminen kehitystyöhön ja vaatimusmäärittelyn joustavuus. Lisäksi neljännessä alaluvussa käydään läpi muutamia esimerkkejä tutkimuksista, joissa käyttäjäkeskeisten suunnittelumenetelmien avulla on onnistuneesti korjattu ketterien menetelmien kanssa havaittuja käytännön ongelmia. 3.1 Iteratiivisuus Sekä ketterät menetelmät että käyttäjäkeskeinen suunnittelu nojaavat vahvasti iteratiiviseen kehitysparadigmaan. Kummankin kohdalla tuotetta rakennetaan ja parannetaan aiemmista sykleistä tai kierroksista saadun palautteen pohjalle. Esimerkiksi XP:ssä yksi kantavista arvoista on palautteen huomioiminen, ja sitä pyritään tekemään monella eri tasolla (katso kuva 2.2). Yhtälailla käyttäjäkeskeisen suunnittelun yksi peruspilareista on iteratiivinen suunnitteluprosessi. (Chamberlain et al., 2006) Kuitenkin prosessin inkrementaalisuuteen ketterät menetelmät ja käyttäjäkeskeinen suunnittelu suhtautuvat hieman eri tavalla. Ketterät menetelmät luottavat myös inkrementaalisuuteen (ollen siten iteratiivis-inkrementaalisia), kun taas käyttäjäkeskeisen suunnittelun kohdalla inkrementaalisuus ei olekaan enää toivottu asia. Jo ensimmäisen suunnitteluversion toivotaan sisältävän kaikki käyttöliittymän osat, jolloin käyttöliittymä voidaan suunnitella koko- 14

19 LUKU 3. YHDISTÄMISESSÄ HAVAITTUJA ETUJA 15 naisuutena. Käyttöliittymäkehitys osissa voi olennaisesti heikentää käyttöliittymän yhtenäisyyttä. (esimerkiksi Nodder ja Nielsen, 2008) 3.2 Käyttäjä mukana kehitystyössä Ketterät menetelmät asettavat painoa käyttäjän kanssa kommunikointiin, rohkaisten osallistumiseen koko kehitysprosessin aikana. Scrumissa kuukausittaiseen käyttäjätestaukseen rohkaistaan tuomalla joka kehityssyklin päätteeksi viimeisin versio tuotteesta loppukatselmointiin ja XP:ssä käyttäjä ideaalitilanteessa kuuluu yhtenä jäsenenä kehitystiimiin. Myös yksi käyttäjäkeskeisen suunnittelun pääperiaatteista on aikainen ja jatkuva huomion keskittäminen käyttäjään. (Chamberlain et al., 2006) Käytännössä asiasta löytyy kuitenkin pieniä painotuseroja. Ketterien menetelmien kohdalla ideaalikäyttäjänä nähdään maksava asiakas, jonka uskotaan olevan tietoinen käyttäjistä ja heidän tarpeistaan, ja siksi hyvä valinta edustamaan loppukäyttäjiä. Käyttäjäkeskeisessä suunnittelus painotus on tuotteen lopullisessa käyttäjässä. Yhteistä ketterille menetelmille ja käyttäjäkeskeiselle suunnittelulle kuitenkin on ymmärrys siitä, että onnistuneen lopputuloksen aikaansaamiseksi kehitystyötä ei voida tehdä suljettujen ovien takana. Palautetta on haettava aika ajoin myös kehitystiimin ulkopuolelta ja tarkistettava että kehitystyön alla oleva tuote täyttää asiakkaan tai käyttäjän odotukset. 3.3 Ei jäykkää vaatimusmäärittelyä Yksi ketterien menetelmien näkyvimmistä piirteistä on raskaiden vaatimusmäärittelyjen korvaaminen kevyemmilla ilmaisutavoilla. Esimerkiksi XP:ssä vaatimukset kirjoitetaan käyttäjätarinoiden (engl. user stories) muotoon, jotka on kirjoitettu seinään kiinnitettävälle kortille. Näiden on tarkoitus ajaa samaa asiaa kuin formaalimmankin vaatimusmäärittelyn, mutta esitettynä selkokielellä ja rajoitetun pituisena, mahdollistaen myös muiden kuin ohjelmistokehittäjien osallistumisen niiden määrittelyyn. Ketterien menetelmien vahvuus on vaatimuksien nopea ja vaivaton muokattavuus kehitystyön keskelläkin. Käyttäjäkeskeisen suunnittelun kannalta tämä on hyvä asia, koska näin esimerkiksi käytettävyystestauksesta saadut havainnot voidaan viiveettä ottaa huomioon kehitystyössä.

20 LUKU 3. YHDISTÄMISESSÄ HAVAITTUJA ETUJA 16 Lisäksi Constantine (2002) toteaa, että kevyimmät käyttäjäkeskeisen suunnittelun menetelmät käyttävät samankaltaista korttijärjestelmää tehtävätapausten (engl. task case) kanssa. Constantinen mukaan samoja kortteja voidaan hyvin yhdistää käytettäväksi sekä käyttöliittymien kehityksessä että ohjelmistokehityksessä. 3.4 Ketterien menetelmien parantaminen käyttäjäkeskeisin suunnittelumenetelmin Kirjallisuudessa raportoidaan myös hyödyistä joita käyttäjäkeskeisen suunnittelun menetelmät voivat tarjota avuksi joihinkin ketterien menetelmien kohdalla havaittuihin ongelmiin. Tässä luvussa kerrotaan kaksi esimerkkiä. Patton (2005) esittelee artikkelissaan yrityksen, joka siirtyy käyttämään ketteriä menetelmiä halutessaan parantaa mahdollisuuksia reagoida projektien aikana muuttuviin asiakasvaatimuksiin. Pilottiprojektissa siirrytään käyttämään XP:tä, mutta törmätään uuteen ongelmaan. Johtuen pilotoitavan ohjelmistotuotteen kompleksisuudesta, käyttäjätarinoita syntyy lähdes 700 ja haasteeksi muodostuu näiden priorisointi. Käyttäjätarinoiden keskinäisiä riippuvuuksi oli määrästä johtuen lähes mahdotonta hahmottaa, eikä ryhmä täten pystynyt tekemään päätöksiä siitä, mitkä ominaisuudet olisi valittava ensimmäiseen iteraatioon. Patton kertoo avun löytyneen Garretin käyttäjäkokemuselementitmallista (engl. Elements of User Experience Model) sekä Cockburnin tavoitetaso (engl. goal level) konseptista. Näiden kahden käyttäjäkeskeisen suunnittelumenetelmän avulla saatiin lähes 700 käyttäjätarinaa muunnettua noin 80:ksi tehtäväksi (engl. user task) joista 30 valittiin toteutettavaksi ensimmäiseen julkaisuun. Tämän lisäksi kehittäjien ymmärrystä käyttäjien kohtaamista todellisista ongelmista kohennettiin seuraamalla käyttäjiä heidän päivittäisessä työympäristössään, joka lisäsi kehittäjien ymmärrystä tärkeimmistä prioriteeteista. (Patton, 2005) Myös Nodder ja Nielsen (2008) raportoivat käyttäjäkeskeisten suunnittelumenetelmien antamista hyödyistä ketterien menetelmien yhteydessä. He toteavat, että käyttäjätarinoita voidaan olennaisesti parantaa hyödyntämällä käyttäjäkeskeisiä suunnittelumenetelmiä, muun muassa käyttämällä persoonia sekä tutkimalla käyttäjävaatimuksia. Tuotteen kehitysjonon (engl. product backlog) priorisointia voidaan heidän mukaansa olennaisesti avustaa käyttäjäskenaarioilla, kuvakäsikirjoituksilla ja rautalankamalleilla. Lisäksi Nodder ja

21 LUKU 3. YHDISTÄMISESSÄ HAVAITTUJA ETUJA 17 Nielsen toteavat, että laadunvarmistuksen kannalta on hyödyllistä, jos käyttäjätarinoiden läpäisykriteereihin voidaan asetettaa käytettävyystavoitteita ja todentaa ne käytettävyystestauksella.

22 Luku 4 Yhdistämisessä havaittuja ongelmia Tässä luvussa käydään läpi ketterien menetelmien ja käyttäjäkeskeisen suunnittelun yhdistämisessä havaittuja ongelmia. Näkökulma vertailee ketteriä menetelmiä ensisijaisesti perinteisiin ohjelmistokehitysmenetelmiin ja siten tästä tarkastelusta on jätetty pois yleisen tason ongelmia, jotka ovat yhteisiä kaikille ohjelmistokehitysmenetelmille. Ongelmat on jaettu kolmeen ryhmään, jotka kukin on esitelty omassa alaluvussaan. Jako on vain ohjeellinen, useissa kohdin käytännön tason ongelmissa voidaan nähdä piirteitä useammasta ryhmästä. 4.1 Iteratiivisuuden nopeus Ketterien menetelmien ja käyttäjäkeskeisen suunnittelun välillä on selkeä filosofinen ero: Käyttäjäkeskeisen suunnittelun periaatteet kannustavat loppukäyttäjän ymmärtämiseen mahdollisimman aikaisessa vaiheessa ja ennen varsinaisen kehitystyön aloittamista, kun taas ketterät menetelmät vastustavat vahvasti etukäteen tehtävää määrittely- ja tutkimustyötä (engl. Big Design Up Front) ohjelmakoodin kirjoittamisen sijasta (Chamberlain et al., 2006). Constantine (2002) toteaa myös saman ongelman. Onnistuneen ja käytettävän käyttöliittymän suunnittelu vaatii kuitenkin jonkinlaisen kokonaisarkkitehtuurin miettimistä heti kehityksen alkuvaiheessa (Constantine, 2002). Ketterässä ohjelmistokehityksessä koodin kirjoittaminen alkaa tyypillisesti samantien kun projekti on käynnistetty, eikä käytettävyysasiantuntijoilla enää ole projektin alussa käytettävissä aikaa syvälliseen käyttäjien, tehtävien tai ympäristön analysointiin. Tästä voi seurata ainakin kolme käytännön on- 18

23 LUKU 4. YHDISTÄMISESSÄ HAVAITTUJA ONGELMIA 19 gelmaa. Ensiksi, käytettävyysasiantuntijoiden vastuulla olevat käyttöliittymäsuunnitelmat voivat muodostua kehitystyön aloittamisen pullonkaulaksi, kun ohjelmistokehittäjät joutuvat odottelemaan niitä. Toiseksi, kiireessä ja kiristetyillä aikatauluilla tehtyjen käyttöliittymäsuunnitelmien laatu on heikompi. Kolmanneksi, kiireellä tehtyjä käyttöliittymäsuunnitelmia ei ehditä tarkistaa käytettävyystestein. Tällöin myös suunnittelupäätöksistä käyttävä keskustelu voi muuttua puhtaaksi mielipideväittelyksi, kun käytettävissä ei ole mitään käyttäjäpalautetta päätöksenteon tueksi. (Miller ja Sy, 2009) Toisaalta, Nodder ja Nielsen (2008) pohdiskelevat edeltävän kaltaisen kritiikin ketteriä menetelmiä kohtaan kielivän joustamattomuudesta. Heidän mukaansa käytettävyysasiantuntijoiden tarve etukäteen tehtävälle suurelle työmäärälle ei ole todellinen, vaan pohjautuu vain aiempaan tottumukseen. Sen sijaan vesiputousmallin mukaisissa prosesseissa etukäteen tehtävän työn tarve oli todellinen, koska muutoksien tekeminen prosessin myöhemmissä vaiheissa oli hyvin vaikeaa tai mahdotonta. Ketterien menetelmien kanssa sen sijaan tilanne on eri, ja suuren työmäärän uhraaminen etukäteen ei ole enää järkevää. Lisäksi analyyseja ja käytettävyystestausta on paljon järkevämpi tehdä todellisen ohjelmiston kanssa, jos ja kun se ketterien menetelmien kanssa on mahdollista. (Nodder ja Nielsen, 2008) Sen lisäksi, että kehitystyö alkaa välittömästi projektin alussa, voivat ketterien prosessien lyhyet ja nopeat kehityssyklit olla ongelma, kun käyttöliittymäkehitystä tehdään samoissa aikarajoissa. Syklit voivat olla liian lyhyitä käytettävyysasiantuntijoille yksittäisten työvaiheiden alusta loppuun saattamiseksi. Ongelmat voivat ilmentyä suunnitelmien saamisessa ajoissa valmiiksi tai siinä ettei aikaa ole riittävästi käytettävyystestaukselle. (Sy, 2007; Miller ja Sy, 2009) Samaa ongelman yhtä puolta edustaa kokonaiskuvan hämärtyminen suunnittelutyön keskellä. Wolkerstorfer et al. (2008) kokemusten mukaan käyttäjät kokevat ohjelmistotuotteen usein tilkkutyöksi, mikäli se on kehitetty XP:n tavalla alhaalta ylös. Heidän mukaansa tämä johtuu kokonaiskuvan puuttumisesta projektien alussa. Miller ja Sy (2009) listaavat tästä ongelmasta seuraavien oireiden joukkoon muun muassa jaetun näkemyksen puuttumisen lopullisesta tavoitteesta, keskittymisen liiaksi yksityiskohtiin, sekä priorisoinnin ja päätöksenteon hankaluuden käyttöliittymäsuunnitelmissa. Nodder ja Nielsen (2008) arvioivat käytettävyysasiantuntijoiden kokemukset liian lyhyistä sykleistä johtuvan osittain aikaavievän käytettävyystestauksen dominoivasta asemasta menetelmänä. Moni käytettävyysasiantuntija nimittäin pitää käytettävyystestejä ainoana luotettavana menetelmänä käytettävyy-

24 LUKU 4. YHDISTÄMISESSÄ HAVAITTUJA ONGELMIA 20 den mittaamiseksi ja parantamiseksi. Nodder ja Nielsen mukaan tämä on saattanut nostaa käytettävyystestauksen tärkeämpään asemaan kuin mitä se todellisuudessa ansaitsisi. He huomauttavatkin, että käytettävyystestit ovat vain yksi tapa löytää ongelmia käytettävyydessä. Käytettävyystestauksen lisäksi on olemassa myös paljon muita menetelmiä ja tekniikoita, joilla saadaan aikastakin palautetta käyttäjiltä. Nodder ja Nielsen muistuttavat, että käytettävyysinsinöörin ensisijainen tavoite ei tulisi olla käytettävyystestauksen läpikäynti, vaan laadullisesti parempien ohjelmistojen julkaisu. 4.2 Kulttuurierot Ohjelmistokehittäjät ja käytettävyysasiantuntijat tulevat eri taustoista, erilaisilla asenteilla ja lähestymistavoilla ja usein jopa ilmaisevat itseään erilaisilla tavoilla. Ketterät menetelmät edellyttävät tiivistä yhteistyötä tiiminjäsenten kesken, mikä voi tuoda ohjelmistokehittäjien ja käytettävyysasiantuntijoiden väliset ajatusmaailmalliset erot kuuluvammin esiin. Ohjelmistokehittäjillä on tyypillisesti hyvin tekninen lähestyminen tuotekehitykseen, kun taas käytettävyysasiantuntijat psykologisen taustan kanssa näkevät tuotteen kehittämisen kognitiivisestä nakökulmasta. Nämä näkemyserot voivat johtaa ongelmiin työilmapiirissä. (Wolkerstorfer et al., 2008) Lievesley ja Yee (2006) nostaa myös esiin riskin liittyen käytettävyysasiantuntijan liian läheiseen osallistumiseen ketterän tiimin toimintaan, erityisesti projektin alkuvaiheessa. Käytettävyysasiantuntijan aloittaessa tuotteen tutkimusta, yksi arvokkaimmista asioista on rajoittamaton tutkimusmatkailu aihepiirissä yrittäen luoda kokonaisvaltaista ymmärrystä aihealueesta koostaen ja yhdistellen tietoja. Tällaisen yhdistelevän tutkimuksen tekeminen voi muodostua käytettävyysasiantuntijalle vaikeaksi osana yksityiskohtiin keskittyvää ketterää ohjelmistotiimiä. (Lievesley ja Yee, 2006) Kolmas ongelma ketterien tiimien kanssa työskentelyssä voi nousta esiin mikäli yksi käytettävyysasiantuntija jakaa työaikaansa useamman tiimin kanssa. Usean tiimin kanssa työskennellessä osallistuminen kaikkien tiimien kokouksiin voi viedä työajasta kohtuuttoman paljon aikaa verrattuna itse suunnittelutyöhön (Miller ja Sy, 2009). Mikäli vähäisiä resursseja lisäksi käytetään epätasaisesti tiimien välillä, voi käytettävyysasiantuntijan osoittamalla priorisoinnilla olla vaikutus myös vähemmälle huomiolle jäävän tiimin työmoraaliin. Myös dokumentointikäytäntöjen erot saattavat aiheuttaa ongelmia. Useimmat

25 LUKU 4. YHDISTÄMISESSÄ HAVAITTUJA ONGELMIA 21 käytettävyysasiantuntijat mieltävät tietyt suunnitteludokumentit välttämättömiksi asioiden eteenpäin kommunikoimiseksi (esimerkiksi ohjelmistokehittäjille), kun taas ketterien menetelmien filosofia on tuottaa mahdollisimman vähän dokumentaatiota ja luottaa suullisesti käytyihin keskusteluihin (Chamberlain et al., 2006). Erot dokumentointitavoissa saattavat johtaa myös kommunikaatiokatkoksiin, jos toinen osapuoli luottaa kirjoitettuihin raportteihin ja toinen suullisiin raportteihin. Kommunikaatiokatkokset saattaa ilmetä esimerkiksi väärinymmärrettyinä käyttöliittymäsuunnitelmina, tiimin erimielisyytenä suunnitellusta käyttöliittymästä sekä tärkeän informaation katoamisena (Miller ja Sy, 2009). 4.3 Eri näkemys käyttäjästä Ketterät menetelmät keskittyvät asiakkaaseen, mutta asiakas ei usein ole itse tuotteen loppukäyttäjä. Tämä aiheuttaa ongelmia, mikäli ketterässä tiimissä ei ole henkilöä, joka pystyy edustamaan todellista käyttäjää kehitettävälle tuotteelle. (Nodder ja Nielsen, 2008; Wolkerstorfer et al., 2008) Silloinkin kun asiakas ja käyttäjä ovat sama taho, Sy (2007) havaitsee ongelmaksi ketterien menetelmien suuren riippuvuuden palautteesta. Käyttäjien mielipiteen kuuntelua parempi menetelmä on usein käyttäjien havainnointi. Väite pohjautuu monien käytettävyysasiantuntijoiden (muun muassa Nielsen, 1993; Shneiderman ja Plaisant, 2005) näkemykseen, että käyttäjän tarkkailussa syntyvät havainnot ovat olennaisempia kuin käyttäjän suullisesti esittämät ideat.

26 Luku 5 Keinoja ongelmien ratkaisemiseksi Tässä luvussa esitellään edellisessä kappaleessa havaittujen ongelmien ratkaisuideoita. Ratkaisuideat on ryhmitelty neljään päätason ideaan, jotka kukin on esitelty omassa alaluvussaan. 5.1 Muutoksia syklijärjestelmään Luvussa 4.1 käytiin läpi ongelmia liittyen välittömään kehitystyön aloittamiseen projektin alussa. Tässä luvussa käsittelemme ehdotettuja muutoksia ketterien menetelmien syklijärjestelmään, jotka pyrkivät korjaamaan tätä ongelmaa. Detweiler (2007) ehdottaa lobbaamaan erillisiä, pelkästään vaatimusmäärittelyyn omistautuneita kehityssyklejä ja pitää tätä tärkeänä erityisesti projekteja käynnistettäessä. Hänen mukaansa kehittäjiä voi näissä sykleissä hyödyntää asiakaskäynneillä kerätyn tietoaineiston jalostamiseen. Myös Ungar ja White (2008) ja Sy (2007) ehdottavat niin sanotun syklin nolla (engl. cycle zero) käyttöä projektien alussa antamaan käyttöliittymäsuunnittelijoille etumatkaa kehittäjiin, joskaan eivät vaadi niiden keskittyvän pelkästään vaatimusmäärittelyyn. Budwig et al. (2009) ehdottaa lisäksi neljännesvuosittaisia visiointisyklejä (engl. design vision sprint) normaalin syklikierron lomaan estämään kokonaiskuvan kadottamista (katso luku 4.1). Budwig et al. suorittaman casetutkimuksen mukaan tämän avulla saavutetaan yhtenäisempiä ja parempia käyttöliittymäsuunnitelmia. 22

27 LUKU 5. KEINOJA ONGELMIEN RATKAISEMISEKSI 23 Nielsen (1992) taas esittää, että alkuvaiheen käytettävyyteen liittyviä työtehtäviä voi teetätyttää osana markkinatutkimusta, jolloin ne on tehty jo ennen ohjelmistosuunnittelun aloittamista (tämä ohje on annettu jo ennen ketterien menetelmien yleistymistä, mutta lienee nyt entistä ajankohtaisempi). Constantinen (2002) mukaan etukäteen tehtävien asioiden määrä ei kuitenkaan tarvitse olla niin suuri kuin usein mielletään, vaan kolme asiaa riittää. Ensiksi yleisen rakenteen kuvaus kaikille käyttöliittymän osille, siten että se sopii käyttäjän tehtävien rakenteeseen. Toiseksi joustava yleiskaavio navigointiin eri käyttöliittymän osien välillä. Kolmanneksi visuaalinen suunnitelma ja vuorovaikutussuunnitelma, joka takaa yhtenäisen käyttötuntuman (engl. look-andfeel) eri eri osioiden välillä. (Constantine, 2002) Kuva 5.1: Rinnakkaiset polut (kuva Sy, 2007, s. 118) Sen lisäksi, että käyttöliittymäsuunnittelijat tarvitsevat etumatkaa projektin alussa, on huolehdittava että etumatka säilyy projektin aikana. Sy (2007) esittää ratkaisuksi rinnakkaisia polkuja ohjelmistokehittäjille ja käytettävyysasiantuntijoille (kuva 5.1). Ideana on se, että käytettävyysasiantuntijat suunnittelevat syklissä yksi käyttöliittymän niille ominaisuuksille, joita ohjelmistokehittäjät arvioivat tekevänsä syklissä kaksi. Lisäksi käytettävyysasiantuntijat tekevät syklissä yksi jo käyttäjätutkimusta ja -analyysia ominaisuuksille, joita ohjelmistokehittäjät tekevät arviolta syklissä kolme. Lisäksi käytettävyysasiantuntijat suorittavat käytettävyystestausta edellisessä syklissä valmiiksi saatuun ohjelmistoon, tarkistaakseen että lopullinen ratkaisu on toimiva. Ongelmaksi jää enää vain ihan projektin alku ja ensimmäiset syklit, mutta tämä voidaan ratkaista aloittamalla ohjelmistokehitys ohjelmistoarkkitehtuu-

28 LUKU 5. KEINOJA ONGELMIEN RATKAISEMISEKSI 24 rista, mikä vaatii tuekseen vain vähän tai ei ollenkaan käyttöliittymäsuunnitelmia. (Sy, 2007) Kuva 5.2: Erilliset ketterät tiimit ohjelmistokehittäjille ja käytettävyysasiantuntijoille (kuva Budwig et al., 2009, s. 3082) Edellä esitetyssä Syn rinnakaisten polkujen mallissa ohjelmistokehittäjät ja käytettävyysasiantuntijat ovat edelleen samassa tiimissä. Budwig et al. (2009) puolestaan kertoo case-tutkimuksesta, jossa päädyttiin hajottamaan nämä kaksi ryhmää kokonaan erillisiin ketteriin tiimeihin. Kummallakin tiimillä oli myös omat tuoteomistajat (kuva 5.2). Syn ja Budwig et al. näkemykset ovat mielenkiintoisella tavalla ristiriitaiset. Sy painottaa omassa esimerkissään kommunikoinnin tärkeyttä tahojen välillä ja sitä kuinka käytettävyysasiantuntijoiden on osana ketterää prosessia otettava myös ketterän filosofian kanssa paremmin yhteensopiva lähestymistapa kommunikointiin (katso lisää luvusta 5.4). Budwig et al. toisaalta puolustavat heidän päätöstään jakaa tahot eri tiimeihin, vaikkakin myös he näkee runsaan kommunikoinnin tahojen välillä tärkeänä. Myös Nodder ja Nielsen (2008) pohtivat rinnakkaisten syklien riskejä ja näkevät kommunikoinnin puutteen eri leirien välillä vakavana riskinä. Olivat käyttöliittymäasiantuntijat ja ohjelmistokehittäjät samoissa tai eri tiimeissä, Chamberlain et al. (2006) havaitsevat tutkimuksessaan, että ohjelmistokehittäjien ja käytettävyysasiantuntijoiden välille syntyy merkillisen helpos-

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki

Specifying user requirements for corporate intranet with user centered design methods. Espoo Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Specifying user requirements for corporate intranet with user centered design methods Espoo 29.9.2016 Tekijä: Henri Ström Valvoja: TkT Kalevi Kilkki Sisältö Työn tausta Ongelman asettelu Metodiikka Kehitysprojekti

Lisätiedot

Tutkittua tietoa. Tutkittua tietoa 1

Tutkittua tietoa. Tutkittua tietoa 1 Tutkittua tietoa T. Dybå, T. Dingsøyr: Empirical Studies of Agile Software Development : A Systematic Review. Information and Software Technology 50, 2008, 833-859. J.E. Hannay, T. Dybå, E. Arisholm, D.I.K.

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit Ohjelmiston testaus ja laatu Ohjelmistotekniikka elinkaarimallit Vesiputousmalli - 1 Esitutkimus Määrittely mikä on ongelma, onko valmista ratkaisua, kustannukset, reunaehdot millainen järjestelmä täyttää

Lisätiedot

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

Scrum is Not Enough. Scrum ei riitä. Ari Tanninen & Marko Taipale. Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12. Scrum is Not Enough Scrum ei riitä Ari Tanninen & Marko Taipale Nääsvillen oliopäivä 2009 Tampereen teknillinen yliopisto 9.12.2009 Ari Tanninen Vanhempi ohjelmistoinsinööri Marko Taipale Teknologiajohtaja,

Lisätiedot

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit

Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit Käyttäjäkeskeisen suunnittelun periaatteet ja prosessit Kurssilla: Johdatus käyttäjäkeskeiseen tuotekehitykseen 23.1.2008 Johanna Viitanen johanna.viitanen@soberit.hut.fi Luennon aiheet Tuotekehityksen

Lisätiedot

Kun scrum ei riitä - skaalaa ketterä tuotekehitys SAFe lla Nestori Syynimaa Sovelto Oyj

Kun scrum ei riitä - skaalaa ketterä tuotekehitys SAFe lla Nestori Syynimaa Sovelto Oyj Kun scrum ei riitä - skaalaa ketterä tuotekehitys SAFe lla 28.10.2016 Nestori Syynimaa Sovelto Oyj 1 Puhujasta Seniori-konsultti Nestori Syynimaa SAFe, Scrum, Lean IT, ITIL, kokonaisarkkitehtuuri,.. PhD

Lisätiedot

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

KÄYTETTÄVYYDEN PERUSTEET 1,5op. Mitä on käyttäjäkeskeinen suunnittelu? Mitä on käyttäjäkeskeinen muotoilu? Pieniä harjoituksia KÄYTETTÄVYYDEN PERUSTEET 1,5op Mitä on käyttäjäkeskeinen suunnittelu? Katja Soini TaiK 21.3.2007 1. MÄÄRITTELE 2. TUNNISTA RATKAISU 5. ARVIOI 3. MÄÄRITTELE 4. LUO Aiheena keskiviikkona 21.3.2007 Luento

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op)

Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistoprosessit ja ohjelmistojen laatu (4op) 581361 Ohjelmistoprosessit ja ohjelmistojen laatu (4op) Ohjelmistojärjestelmien syventävien opintojen kurssi Myös ohjelmistotekniikan profiilin pakollinen kurssi eli ohjelmistotekniikka-aiheisen gradun

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

Ohjelmistojen mallintaminen. Luento 11, 7.12. Ohjelmistojen mallintaminen Luento 11, 7.12. Viime viikolla... Oliosuunnittelun yleiset periaatteet Single responsibility eli luokilla vain yksi vastuu Program to an interface, not to concrete implementation,

Lisätiedot

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

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

Lisätiedot

Määrittely- ja suunnittelumenetelmät

Määrittely- ja suunnittelumenetelmät Menetelmädokumentti Määrittely- ja suunnittelumenetelmät Versio Päiväys Tekijä Kuvaus 0.01 5.12.01 Pekka Koskinen Alustava sisällysluettelo 0.1 7.12.01 Pekka Koskinen Ensimmäinen luonnos 1.0 11.12.01 Pekka

Lisätiedot

OpenUP ohjelmistokehitysprosessi

OpenUP ohjelmistokehitysprosessi OpenUP ohjelmistokehitysprosessi Sami Männistö Helsinki 14.11.2008 Seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos i HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET Tiedekunta/Osasto Matemaattis-luonnontieteellinen

Lisätiedot

Oleelliset vaikeudet OT:ssa 1/2

Oleelliset vaikeudet OT:ssa 1/2 Oleelliset vaikeudet OT:ssa 1/2 Monimutkaisuus: Mahdoton ymmärtää kaikki ohjelman tilat Uusien toimintojen lisääminen voi olla vaikeaa Ohjelmista helposti vaikeakäyttöisiä Projektiryhmän sisäiset kommunikointivaikeudet

Lisätiedot

Petri Mattila KÄYTTÄJÄKESKEISEN SUUNNITTELUN INTEGROINTI KETTERÄN KEHITTÄMISEN PROSESSIIN JA ROOLEIHIN

Petri Mattila KÄYTTÄJÄKESKEISEN SUUNNITTELUN INTEGROINTI KETTERÄN KEHITTÄMISEN PROSESSIIN JA ROOLEIHIN Petri Mattila KÄYTTÄJÄKESKEISEN SUUNNITTELUN INTEGROINTI KETTERÄN KEHITTÄMISEN PROSESSIIN JA ROOLEIHIN JYVÄSKYLÄN YLIOPISTO TIETOJENKÄSITTELYTIETEIDEN LAITOS 2014 TIIVISTELMÄ Mattila, Petri Käyttäjäkeskeisen

Lisätiedot

Teoreettisen viitekehyksen rakentaminen

Teoreettisen viitekehyksen rakentaminen Teoreettisen viitekehyksen rakentaminen Eeva Willberg Pro seminaari ja kandidaatin opinnäytetyö 26.1.09 Tutkimuksen teoreettinen viitekehys Tarkoittaa tutkimusilmiöön keskeisesti liittyvän tutkimuksen

Lisätiedot

Scrumin käyttö ketterässä sovelluskehityksessä

Scrumin käyttö ketterässä sovelluskehityksessä Scrumin käyttö ketterässä sovelluskehityksessä 9.4.2008 Janne Kuha Manager, Java Services Descom Oy Janne Kuha Manager, Java Services janne.kuha@descom.fi Kuka? Descom Oy:llä, sitä ennen Wanadu Inc., Mountain

Lisätiedot

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita 581259 Ohjelmistotuotanto 378 Lemström, 2006-2011 581259 Ohjelmistotuotanto Kiitos Tuomolle kuvasta 379 Ohjelmistotuotannon perustehtävät projektinhallinta:

Lisätiedot

Saavutettavuus tietojärjestelmien hankinnoissa

Saavutettavuus tietojärjestelmien hankinnoissa Saavutettavuus tietojärjestelmien hankinnoissa Saavutettava tieto- ja viestintäympäristö (Stivi) - suosituksen julkaisuseminaari 31.03.2014 Jani Ruuskanen / Valtion tieto- ja viestintätekniikkakeskus Valtori

Lisätiedot

Miten ideoidaan ja kehitetään uusia toimintatapoja? Juha Koivisto, THL

Miten ideoidaan ja kehitetään uusia toimintatapoja? Juha Koivisto, THL Miten ideoidaan ja kehitetään uusia toimintatapoja? Juha Koivisto, THL 1 Hankekohelluksesta ketterään ja kokeilevaan toimintatapojen kehittämiseen Hankesuunnittelu, -arviointi ja -raportointi on usein

Lisätiedot

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

SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus SEPA-päiväkirja: Käytettävyystestaus & Heuristinen testaus Lehmus, Auvinen, Pihamaa Johdanto Käyttäjätestauksella tarkoitetaan tuotteen tai sen prototyypin testauttamista todellisilla käyttäjillä. Kehittäjät

Lisätiedot

E-kirjan kirjoittaminen

E-kirjan kirjoittaminen 1 E-kirjan kirjoittaminen Ohjeet e-kirjan kirjoittamiseen Tämän ohjeistuksen tavoitteena on auttaa sinua luomaan yksinkertainen e-kirja (pdftiedosto) asiakkaallesi. Kirja näyttää hänelle kuinka hyvin ymmärrät

Lisätiedot

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7 Viitearkkitehtuurin suunnitteluprosessi Ohje v.0.7 Viitearkkitehtuurin suunnitteluprosessi XX.XX.201X 2 (13) Sisällys 1. Johdanto... 3 2. Viitearkkitehtuurin suunnitteluprosessin vaiheet... 3 2.1. Vaihe

Lisätiedot

Suunnitteluvaihe prosessissa

Suunnitteluvaihe prosessissa Suunnittelu Suunnitteluvaihe prosessissa Silta analyysin ja toteutuksen välillä (raja usein hämärä kumpaankin suuntaan) Asteittain tarkentuva Analyysi -Korkea abstraktiotaso -Sovellusläheiset käsitteet

Lisätiedot

Kuka kylää kehittää? Salon seudun malli kyläsuunnitteluun

Kuka kylää kehittää? Salon seudun malli kyläsuunnitteluun Kuka kylää kehittää? Salon seudun malli kyläsuunnitteluun Salon seudun suunnittelumalli yhdistää toiminnallisen kyläsuunnittelun ja maankäytön suunnittelun Toiminnallinen kyläsuunnitelma edustaa kyläläisten

Lisätiedot

Pisteytysohje loppuraporttien vertaisarviointiin

Pisteytysohje loppuraporttien vertaisarviointiin Pisteytysohje loppuraporttien vertaisarviointiin Pisteytys olettaa kaikkien kuvattujen vaatimusten täyttymistä pistemäärän saavuttamiseksi. Esimerkiksi: Raportti täyttää rakenteen ja kieliasun osalta kaikki

Lisätiedot

1. Oppimisen ja opettamisen haasteet

1. Oppimisen ja opettamisen haasteet 1. Oppimisen ja opettamisen haasteet Oppimisen aihepiirit oppijan mielenkiinnon mukaan. Sosiaaliset taidot, ongelmaratkaisu pienryhmissä, johtajuus, empatia, yrittäjämäinen toiminta, Oppijan oman lahjakkuuden

Lisätiedot

Viisi vinkkiä tasokkaaseen tiedolla johtamiseen ja parempaan asiakasymmärrykseen

Viisi vinkkiä tasokkaaseen tiedolla johtamiseen ja parempaan asiakasymmärrykseen Viisi vinkkiä tasokkaaseen tiedolla johtamiseen ja parempaan asiakasymmärrykseen Big Data Solutions Oy 2017 VIISI VINKKIÄ TASOKKAASEEN TIEDOLLA JOHTAMISEEN JA PAREMPAAN ASIAKASYMMÄRRYKSEEN Basware on maailman

Lisätiedot

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely

Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 582101 - Ohjelmistotekniikan menetelmät, käyttötapauksiin perustuva vaatimusmäärittely 1 Vaatimukset ja käyttötapaukset Vaiheittainen mallintaminen ja abstraktiotasot Järjestelmän rajaaminen sidosryhmäkaaviolla

Lisätiedot

Ohjelmiston testaus ja laatu. Testaus käytettävyys

Ohjelmiston testaus ja laatu. Testaus käytettävyys Ohjelmiston testaus ja laatu Testaus käytettävyys Yleistä - 1 Käytettävyys on osa tuotteen laatuominaisuutta Käytettävyys on mittari, jolla mitataan tuotteen käytön tuottavuutta, tehokkuutta ja miellyttävyyttä.

Lisätiedot

Kilpailemaan valmentaminen - Huipputaidot Osa 3: Vireys- ja suoritustilan hallinta. Harjoite 15: Keskittyminen ja sen hallinta

Kilpailemaan valmentaminen - Huipputaidot Osa 3: Vireys- ja suoritustilan hallinta. Harjoite 15: Keskittyminen ja sen hallinta Kilpailemaan valmentaminen - Huipputaidot Osa 3: Vireys- ja suoritustilan hallinta Harjoite 15: Keskittyminen ja sen hallinta Harjoitteen tavoitteet ja hyödyt Harjoitteen tavoitteena on varmistaa, että

Lisätiedot

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014

Yhtälönratkaisusta. Johanna Rämö, Helsingin yliopisto. 22. syyskuuta 2014 Yhtälönratkaisusta Johanna Rämö, Helsingin yliopisto 22. syyskuuta 2014 Yhtälönratkaisu on koulusta tuttua, mutta usein sitä tehdään mekaanisesti sen kummempia ajattelematta. Jotta pystytään ratkaisemaan

Lisätiedot

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

Lisätiedot

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS

IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA LUONNOS 20.4.2015 IT2015 EKT ERITYISEHTOJA OHJELMISTOJEN TOIMITUKSISTA KETTERIEN MENETELMIEN PROJEKTEILLA 1 1.1 SOVELTAMINEN Näitä erityisehtoja sovelletaan ohjelmistojen tai niiden osien toimituksiin ketterien

Lisätiedot

Eväitä yhteistoimintaan. Kari Valtanen Lastenpsykiatri, VE-perheterapeutti Lapin Perheklinikka Oy

Eväitä yhteistoimintaan. Kari Valtanen Lastenpsykiatri, VE-perheterapeutti Lapin Perheklinikka Oy Eväitä yhteistoimintaan Kari Valtanen Lastenpsykiatri, VE-perheterapeutti Lapin Perheklinikka Oy 3.10.2008 Modernistinen haave Arvovapaa, objektiivinen tieto - luonnonlaki Tarkkailla,tutkia ja löytää syy-seuraussuhteet

Lisätiedot

Koulutuksen nimi Koulutuksen kuvaus Tavoite Esitiedot Alkaa Päättyy Viim.ilm.päivä

Koulutuksen nimi Koulutuksen kuvaus Tavoite Esitiedot Alkaa Päättyy Viim.ilm.päivä Tulevat ITIL Service Design (jatkokoulutus) paikka Jyväskylän yliopisto, Agora (Mattilanniemi 2) agb301 tausta ja tavoitteet ITIL on globaalisti hyödynnetty, ITalan parhaista käytännöistä

Lisätiedot

Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013!

Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013! Siirtyminen ketterien menetelmien maailmaan! Maarit Laanti 24 October 2013! Sisältö! 1. Tilanne nyt: waterscrumming! 2. Kokonaisvaltainen ketteryys mitä sillä haetaan, mitä sillä saadaan?! 3. Ketterän

Lisätiedot

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

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan

Lisätiedot

Uusi toimintamalli henkilöturvallisuuden parantamiseen räjähdysvaarallisissa työympäristöissä. Tuija Luoma, VTT

Uusi toimintamalli henkilöturvallisuuden parantamiseen räjähdysvaarallisissa työympäristöissä. Tuija Luoma, VTT Uusi toimintamalli henkilöturvallisuuden parantamiseen räjähdysvaarallisissa työympäristöissä Tuija Luoma, VTT RÄJÄHDYSVAARALLISEN TYÖYMPÄRISTÖN HENKILÖTURVALLISUUTEEN VAIKUTTAVAT TEKIJÄT Tekijät määritetty

Lisätiedot

Global Mindedness kysely. Muuttaako vaihto-opiskelu opiskelijan asenteita? Kv päivät Tampere May- 14

Global Mindedness kysely. Muuttaako vaihto-opiskelu opiskelijan asenteita? Kv päivät Tampere May- 14 Global Mindedness kysely Muuttaako vaihto-opiskelu opiskelijan asenteita? Kv päivät Tampere 13.5. May- 14 Mistä olikaan kyse? GM mittaa, kuinka vastaajat suhtautuvat erilaisen kohtaamiseen ja muuttuuko

Lisätiedot

Mitä taitoja tarvitaan tekstin ymmärtämisessä? -teorian kautta arkeen, A.Laaksonen

Mitä taitoja tarvitaan tekstin ymmärtämisessä? -teorian kautta arkeen, A.Laaksonen Mitä taitoja tarvitaan tekstin ymmärtämisessä? -teorian kautta arkeen, A.Laaksonen Lukemisen taitoja Tulisi kehittää kaikissa oppiaineissa Vastuu usein äidinkielen ja S2-opettajilla Usein ajatellaan, että

Lisätiedot

Opintokokonaisuuden toteuttaminen opettajatiiminä

Opintokokonaisuuden toteuttaminen opettajatiiminä Opintokokonaisuuden toteuttaminen opettajatiiminä Juho Tiili, Markus Aho, Jarkko Peltonen ja Päivi Viitaharju n koulutusyksikössä opetusta toteutetaan siten, että saman opintokokonaisuuden opintojaksot

Lisätiedot

Standardit osana käyttäjäkeskeistä suunnittelua

Standardit osana käyttäjäkeskeistä suunnittelua Standardit osana käyttäjäkeskeistä suunnittelua 20.4.2006 Mikä on standardi? sovittu tapa tehdä jokin asia saatetaan tarkoittaa asian määrittelevää normatiivista asiakirjaa varmistetaan esim. Euroopassa

Lisätiedot

Kirjaston verkkopalvelun suunnittelu käyttäjäkeskeisesti. Päivi Ylitalo-Kallio Eduskunnan kirjasto (Metropolia Ammattikorkeakoulun kirjasto)

Kirjaston verkkopalvelun suunnittelu käyttäjäkeskeisesti. Päivi Ylitalo-Kallio Eduskunnan kirjasto (Metropolia Ammattikorkeakoulun kirjasto) Kirjaston verkkopalvelun suunnittelu käyttäjäkeskeisesti STKS Tietoaineistoseminaari 14.3.2012 Päivi Ylitalo-Kallio Eduskunnan kirjasto (Metropolia Ammattikorkeakoulun kirjasto) tietoisku Oppiva kirjasto

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Ohjelmistotuotanto syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole

Lisätiedot

Laadunvarmistuksen merkitys toimitusketjussa. Fingrid: Omaisuuden hallinnan teemapäivä. Kaj von Weissenberg

Laadunvarmistuksen merkitys toimitusketjussa. Fingrid: Omaisuuden hallinnan teemapäivä. Kaj von Weissenberg Laadunvarmistuksen merkitys toimitusketjussa Fingrid: Omaisuuden hallinnan teemapäivä Kaj von Weissenberg 19.5.2016 1 Lisää Inspectasta Luomme turvallisuutta, luotettavuutta ja kestävää kehitystä Pohjois-Euroopassa

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4 Tämän esityksen sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan

Lisätiedot

AMO prosessin osallistuneiden näkemys ihanneprosessista

AMO prosessin osallistuneiden näkemys ihanneprosessista AMO prosessin osallistuneiden näkemys ihanneprosessista Ninni Saarinen, Annika Kangas & Heli Saarikoski Oulu 13.-14.3. Metsävarojen käytön laitos, Metsäntutkimuslaitos Q menetelmä Menetelmän idea on tutkia

Lisätiedot

Käyttäjätutkimus: Havainnointi suunnittelun lähtökohtana

Käyttäjätutkimus: Havainnointi suunnittelun lähtökohtana KÄYTETTÄVYYDEN PERUSTEET 1,5op Käyttäjätutkimus: Havainnointi suunnittelun lähtökohtana Katja Soini TaiK 28.3.2007 1. MÄÄRITTELE 2. TUNNISTA RATKAISU 5. ARVIOI 3. MÄÄRITTELE 4. LUO Aiheena keskiviikkona

Lisätiedot

Luku 8. Aluekyselyt. 8.1 Summataulukko

Luku 8. Aluekyselyt. 8.1 Summataulukko Luku 8 Aluekyselyt Aluekysely on tiettyä taulukon väliä koskeva kysely. Tyypillisiä aluekyselyitä ovat, mikä on taulukon välin lukujen summa tai pienin luku välillä. Esimerkiksi seuraavassa taulukossa

Lisätiedot

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

SOVELLUSPROJEKTIN ARVIOINTILOMAKE SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa

Lisätiedot

ja -kehitysmenetelmistä Jyri Partanen, QA Manager Sulake Corporation www.sulake.com

ja -kehitysmenetelmistä Jyri Partanen, QA Manager Sulake Corporation www.sulake.com Huomioita Habbo-suunnittelusta ja -kehitysmenetelmistä Jyri Partanen, QA Manager Sulake Corporation www.sulake.com Jyri Partanen FM (tietojenkäsittelytiede) Certified Scrum Master Certified Product Owner

Lisätiedot

BaRE Käyttövalmis vaatimusmäärittelymenetelmä

BaRE Käyttövalmis vaatimusmäärittelymenetelmä BaRE Käyttövalmis vaatimusmäärittelymenetelmä Uolevi Nikula, Tietotekniikan osasto, LTKK, Uolevi.Nikula@lut.fi 13.11.2002 un/tsoft 1 Esityksen sisältö Jatko-opinnot Lisensiaatintutkimus BaRE menetelmä

Lisätiedot

Minea Ahlroth Risto Havunen PUUN JA KUOREN VÄLISSÄ

Minea Ahlroth Risto Havunen PUUN JA KUOREN VÄLISSÄ Minea Ahlroth Risto Havunen PUUN JA KUOREN VÄLISSÄ Talentum Helsinki 2015 Copyright 2015 Talentum Media Oy ja kirjoittajat Kansi, ulkoasu ja kuvitus: Maria Mitrunen 978-952-14-2411-3 978-952-14-2412-0

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

Tik-76.612 Ohjelmistoprojektien Hallinta

Tik-76.612 Ohjelmistoprojektien Hallinta Tik-76.612 Ohjelmistoprojektien Hallinta Tervetuloa kurssille! 2 Kurssin yleisinfo Kurssin tausta Katsaus luentoihin Aloitusluennon agenda Luennoitsijoiden esittely Harjoitustyön läpikäynti Muut käytännön

Lisätiedot

Ohjelmistojen laadun parantaminen refaktoroinnilla Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto

Ohjelmistojen laadun parantaminen refaktoroinnilla Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Ohjelmistojen laadun parantaminen refaktoroinnilla Simo Mäkinen Tietojenkäsittelytieteen laitos Helsingin yliopisto Mäkinen / Ohjelmistojen laadun parantaminen / Ohjelmistoprosessit ja ohjelmistojen laatu

Lisätiedot

Käytettävyys verkko-opetuksessa Jussi Mantere

Käytettävyys verkko-opetuksessa Jussi Mantere Käytettävyys verkko-opetuksessa 21.8.2002 Jussi Mantere Mitä käytettävyys on? Learnability (opittavuus) Efficiency (tehokkuus) Memorability (muistettavuus) Errors prevented (virheiden tekeminen estetty)

Lisätiedot

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

HELIA 1 (11) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu HELIA 1 (11) Luento 4 Käytettävyyden tuottaminen... 2 Käytettävyys ja systeemityöprosessi... 3 Määrittely... 3 Suunnittelu... 3 Toteutus ja testaus... 3 Seuranta... 3 Kriittiset tekijät käytettävyyden

Lisätiedot

Kahdenlaista testauksen tehokkuutta

Kahdenlaista testauksen tehokkuutta Kahdenlaista testauksen tehokkuutta Puhe ICTexpo-messuilla 2013-03-21 2013 Tieto Corporation Erkki A. Pöyhönen Lead Test Manager Tieto, CSI, Testing Service Area erkki.poyhonen@tieto.com Sisällys Tehokkuuden

Lisätiedot

Lyhyt johdatus ketterään testaukseen

Lyhyt johdatus ketterään testaukseen TTY:n Testauspäivät, Tampere 15.8.2006 Lyhyt johdatus ketterään testaukseen eli Ketterän ohjelmistokehityksen laatukäytäntöjä Juha Itkonen SoberIT Teknillinen korkeakoulu Juha.Itkonen@tkk.fi Ketterä ohjelmistokehitys

Lisätiedot

Kandityön kirjoittaminen. Opinnäyteseminaari

Kandityön kirjoittaminen. Opinnäyteseminaari Kandityön kirjoittaminen Opinnäyteseminaari Lue ja kirjoita Ajatukset eivät kasva tyhjästä. Ruoki niitä lukemalla ja kirjoittamalla lukemastasi. Älä luota muistiisi Merkitse alusta asti muistiinpanoihin

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009

Ohjelmistoprosessit ja ohjelmistojen laatu kevät 2009 7. Iteratiivinen ohjelmistokehitys Iteratiivinen (ja evoluutio-)ohjelmistokehitys (iterative and evolutionary software development) on prosessimallien perhe, missä ohjelmiston elinkaari muodostuu useasta

Lisätiedot

Käyttäjäkeskeinen suunnittelu ja muutamia menetelmiä. HelMet-kirjastot Päivi Ylitalo-Kallio Oppiva kirjasto -verkosto

Käyttäjäkeskeinen suunnittelu ja muutamia menetelmiä. HelMet-kirjastot Päivi Ylitalo-Kallio Oppiva kirjasto -verkosto Käyttäjäkeskeinen suunnittelu ja muutamia menetelmiä HelMet-kirjastot 3.5.2012 Päivi Ylitalo-Kallio Oppiva kirjasto -verkosto Esityksen runko 1. Käyttäjäkeskeinen suunnittelu 2. Havainnointi 3. Tulevaisuustyöpaja

Lisätiedot

Kontrollipolkujen määrä

Kontrollipolkujen määrä Testaus Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät

Lisätiedot

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja

JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja JHS XXX ICT-palvelujen kehittäminen: Laadunvarmistus Liite 2: Tarkistuslistoja Versio: 0.9 Julkaistu: n.n.2011 Voimassaoloaika: toistaiseksi 1 Yleistä Palvelun kehitys jakautuu vaiheisiin, joiden väleissä

Lisätiedot

KÄYTETTÄVYYDEN PERUSTEET 1,5op. Käyttäjäaineiston tulkinta. Tehtävä Käyttäjäaineiston tulkinta ja suunnitteluvaatimukset. Katja Soini TaiK 11.4.

KÄYTETTÄVYYDEN PERUSTEET 1,5op. Käyttäjäaineiston tulkinta. Tehtävä Käyttäjäaineiston tulkinta ja suunnitteluvaatimukset. Katja Soini TaiK 11.4. KÄYTETTÄVYYDEN PERUSTEET 1,5op Käyttäjäaineiston tulkinta Katja Soini TaiK 11.4.2007 1. MÄÄRITTELE 2. TUNNISTA RATKAISU 5. ARVIOI 3. MÄÄRITTELE 4. LUO Aiheena keskiviikkona 11.4.2007 Luento Käyttäjäaineiston

Lisätiedot

Laatukäsikirja - mikä se on ja miten sellainen laaditaan?

Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Laatukäsikirja - mikä se on ja miten sellainen laaditaan? Matkailun laatu laatukäsikirja osaksi yrityksen sähköistä liiketoimintaa Sähköinen aamuseminaari matkailualan toimijoille 24.8.2010 Riitta Haka

Lisätiedot

Koodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/

Koodaamme uutta todellisuutta FM Maarit Savolainen https://blog.edu.turku.fi/matikkaajakoodausta/ Koodaamme uutta todellisuutta FM Maarit Savolainen 19.1.2017 https://blog.edu.turku.fi/matikkaajakoodausta/ Mitä on koodaaminen? Koodaus on puhetta tietokoneille. Koodaus on käskyjen antamista tietokoneelle.

Lisätiedot

Tik Harjoitustyö

Tik Harjoitustyö Tik-76.612 Harjoitustyö Harjoitustyön uusi aikataulu Ti 12.3 Kurssin aloitus Harjoitustyön läpikäynti To 14.3 Ti 19.3 Projektin synty Projektisuunnitelma Ryhmien muodostuminen To 21.3 Ti 26.3 To 4.4 Ti

Lisätiedot

H Prosessi- ja kokonaisarkkitehtuurityökalu palveluna Liite 17 Käytettävyyden arviointi

H Prosessi- ja kokonaisarkkitehtuurityökalu palveluna Liite 17 Käytettävyyden arviointi H087-12 Prosessi- ja kokonaisarkkitehtuurityökalu palveluna Liite 17 Käytettävyyden arviointi Tämän dokumentin tarkoituksena on määrittää kilpailutukseen H087-12 liittyvää käytettävyyden arviointia Tässä

Lisätiedot

Harjoitustyö Case - HelpDesk

Harjoitustyö Case - HelpDesk Harjoitustyö Case - HelpDesk Harjoitustyön Case: HelpDesk -sovellus Tietotekniikkatoimittaja AB ja asiakas X ovat viime vuonna sopineet mikrotukiyksikön ulkoistamisesta X:ltä AB:n liikkeenjohdon vastuulle.

Lisätiedot

NextMakers-kasvuyritysbarometri. Julkaistu Microsoft Fluxissa

NextMakers-kasvuyritysbarometri. Julkaistu Microsoft Fluxissa NextMakers-kasvuyritysbarometri Julkaistu 9.2.2017 Microsoft Fluxissa NextMakers-kasvuyritysbarometri 1/2017 NextMakers-barometri käsittelee kasvuyrityksille kiinnostavia, ajankohtaisia aiheita. Ensimmäisen

Lisätiedot

Esimerkkikysymyksiä: Tulitko pyörällä kouluun? Syötkö lähes päivittäin koulussa välipalan? Käytkö päivittäin välitunnilla ulkona?

Esimerkkikysymyksiä: Tulitko pyörällä kouluun? Syötkö lähes päivittäin koulussa välipalan? Käytkö päivittäin välitunnilla ulkona? 1 Idealaboratorio on työpaja, jossa nuoret pääsevät itse ideoimaan koulun toimintakulttuuria. Työpaja on suunniteltu 15-60 hengelle ja ideointi tapahtuu 4-5 oppilaan ryhmissä. 60-90 minuuttia kestävän

Lisätiedot

Standardi IEC Ohjelmisto

Standardi IEC Ohjelmisto Sundcon Oy Standardi IEC 61508 3 Ohjelmisto muutokset Matti Sundquist Sundcon Oy www.sundcon.fi Standardi IEC 61508 3 (1) Standardissa di esitetään vaatimukset niiden tietojen ja menettelytapojen valmisteluun,

Lisätiedot

TU-A Itsensä tunteminen ja johtaminen Tervetuloa kurssille!

TU-A Itsensä tunteminen ja johtaminen Tervetuloa kurssille! TU-A1140 - Itsensä tunteminen ja johtaminen Tervetuloa kurssille! Kurssin avaus 7.1. 2016 Eerikki Mäki eerikki.maki@aalto.fi Opiskelijapalautetta vuoden 2015 kurssista Kurssi poikkesi todella paljon verrattuna

Lisätiedot

Toimiva työyhteisö DEMO

Toimiva työyhteisö DEMO Toimiva työyhteisö DEMO 7.9.6 MLP Modular Learning Processes Oy www.mlp.fi mittaukset@mlp.fi Toimiva työyhteisö DEMO Sivu / 8 TOIMIVA TYÖYHTEISÖ Toimiva työyhteisö raportti muodostuu kahdesta osa alueesta:

Lisätiedot

CHERMUG-pelien käyttö opiskelijoiden keskuudessa vaihtoehtoisen tutkimustavan oppimiseksi

CHERMUG-pelien käyttö opiskelijoiden keskuudessa vaihtoehtoisen tutkimustavan oppimiseksi Tiivistelmä CHERMUG-projekti on kansainvälinen konsortio, jossa on kumppaneita usealta eri alalta. Yksi tärkeimmistä asioista on luoda yhteinen lähtökohta, jotta voimme kommunikoida ja auttaa projektin

Lisätiedot

Automaattinen yksikkötestaus

Automaattinen yksikkötestaus Teknillinen Korkeakoulu T-76.115 Tietojenkäsittelyopin ohjelmatyö Lineaaristen rajoitteiden tyydyttämistehtävän ratkaisija L models Automaattinen yksikkötestaus Ryhmä Rajoitteiset Versio Päivämäärä Tekijä

Lisätiedot

ALTEn toimintaohjeisto

ALTEn toimintaohjeisto ALTEn toimintaohjeisto Johdanto Vuonna 1994 ALTEn jäsenet tekivät päätöksen tarpeesta luoda virallinen toimintaohjeisto, jossa sekä määriteltäisiin ne standardit, joihin nykyiset ja tulevat jäsenet yksimielisesti

Lisätiedot

Prosessiajattelu. Organisaation prosessikuvaus - CMMI. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessien määritys CMMI käytänteet

Prosessiajattelu. Organisaation prosessikuvaus - CMMI. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessien määritys CMMI käytänteet Organisaation prosessikuvaus - CMMI Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 7.2.2007 Level5 Level4 Level3 Requirements Development Technical Solution Product Integration

Lisätiedot

Jamk Innovointipäivät

Jamk Innovointipäivät Keskiviikko3 Asiakastutkimuksien suunnittelu Jamk Innovointipäivät Miksi asiakastutkimukset? Olemme nyt saaneet toimeksiannon kehitystehtäväämme ja tarkentaneet sen jälkeen tiimissämme mitä meidän halutaan

Lisätiedot

Projektin suunnittelu. Pienryhmäopetus - 71A00300

Projektin suunnittelu. Pienryhmäopetus - 71A00300 Projektin suunnittelu Pienryhmäopetus - 71A00300 Projektikanvaasi Mikä on projektikanvaasi? Visuaalinen työkalu projektitiimille, joka helpottaa projektin suunnittelussa ja projektin tavoitteiden kommunikaatiossa

Lisätiedot

Katetta kumppanuudelle

Katetta kumppanuudelle JUKKA VESALAINEN Katetta kumppanuudelle Hyöty ja sen jakaminen asiakas-toimittaja-suhteessa Esipuhe T ämä teos on jatkoa vuonna 2002 julkaistulle Kaupankäynnistä kumppanuuteen -kirjalle, jossa tarkastelin

Lisätiedot

Käyttäjäkeskeisyys verkkopalveluissa

Käyttäjäkeskeisyys verkkopalveluissa Käyttäjäkeskeisyys verkkopalveluissa JHS-keskustelutilaisuus 6. kesäkuuta 2013 Raino Vastamäki raino.vastamaki@adage.fi Käyttäjäkeskeisyys verkkopalveluissa KLO 14.45 15.15 Käytettävyys ja esteettömyys

Lisätiedot

SITRAN PERSOONAKUVAUSTEN KÄYTTÖOHJE

SITRAN PERSOONAKUVAUSTEN KÄYTTÖOHJE SITRAN PERSOONAKUVAUSTEN KÄYTTÖOHJE Tämän ohjeen tavoitteena on selkiyttää sitä, mitä persoonakuvaukset ovat ja mikä käytännön merkitys niillä on Sitra.fi sivuston suunnittelulle. Kerromme, kuinka persoonakuvaukset

Lisätiedot

AHLSTROM OYJ:N OSAKKEENOMISTAJIEN NIMITYSTOIMIKUNNAN TYÖJÄRJESTYS

AHLSTROM OYJ:N OSAKKEENOMISTAJIEN NIMITYSTOIMIKUNNAN TYÖJÄRJESTYS AHLSTROM OYJ:N OSAKKEENOMISTAJIEN NIMITYSTOIMIKUNNAN TYÖJÄRJESTYS 5.4.2016 1. Nimitystoimikunnan tarkoitus Ahlstrom Oyj:n (jäljempänä Yhtiö ) osakkeenomistajien nimitystoimikunta on Yhtiön osakkeenomistajien

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

Menetelmäraportti - Konfiguraationhallinta Menetelmäraportti - Konfiguraationhallinta Päiväys Tekijä 22.03.02 Ville Vaittinen Sisällysluettelo 1. Johdanto... 3 1.1 Tärkeimmät lyhenteet... 3 2. Konfiguraationhallinnan tärkeimmät välineet... 4 2.1

Lisätiedot

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana

Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Testaus ja säästöt: Ajatuksia testauksen selviämisestä lama-aikana Muutamia ajatuksia siitä, miten testaus pärjää lama-ajan säästötalkoissa. Laman patologioita ja mahdollisuuksia. Säästämisen strategioita.

Lisätiedot

Menetelmäraportti Ohjelmakoodin tarkastaminen

Menetelmäraportti Ohjelmakoodin tarkastaminen Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5

Lisätiedot

Test-Driven Development

Test-Driven Development Test-Driven Development Syksy 2006 Jyväskylän yliopisto Test-Driven Development Testilähtöinen ohjelmistojen kehitystapa. Tehdään ensin testi, sitten vasta koodi. Tarkoituksena ei ole keksiä kaikkia mahdollisia

Lisätiedot

Lukutaitotutkimukset arviointiprosessina. Sari Sulkunen Koulutuksen tutkimuslaitos, JY sari.sulkunen@jyu.fi

Lukutaitotutkimukset arviointiprosessina. Sari Sulkunen Koulutuksen tutkimuslaitos, JY sari.sulkunen@jyu.fi Lukutaitotutkimukset arviointiprosessina Sari Sulkunen Koulutuksen tutkimuslaitos, JY sari.sulkunen@jyu.fi Kansainväliset arviointitutkimukset Arvioinnin kohteena yleensä aina (myös) lukutaito Kansallisista

Lisätiedot

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA

Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA Projektinhallinta TARJA NISKANEN LÄHTEENÄ MM. KEHITTÄJÄN KARTTAKIRJA PROJEKTITOIMINNAN ONGELMIA Kaikkea mahdollista nimitetään projekteiksi Projekti annetaan henkilöille muiden töiden ohella Ei osata käyttää

Lisätiedot

Tavallisimmat kysymykset

Tavallisimmat kysymykset Autodesk Design- ja Creation Suite -paketit Tavallisimmat kysymykset Tässä dokumentissa on vastauksia tavallisimpiin kysymyksiin Design- ja Creation Suite -pakettien myynnin loppumisesta. 24.5.2016 Sisällysluettelo

Lisätiedot

Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0. Kuntamarkkinat Tuula Seppo, erityisasiantuntija

Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0. Kuntamarkkinat Tuula Seppo, erityisasiantuntija Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0 Kuntamarkkinat 14.9.2016 Tuula Seppo, erityisasiantuntija Kuntasektorin asianhallinnan viitearkkitehtuuri 1.0 Hallinnon toimintatapojen digitalisointi

Lisätiedot

Muutoshistoria Versio Laatija Päiväys Muutokset Hyväksynyt 0.9 Juuso Mikkonen

Muutoshistoria Versio Laatija Päiväys Muutokset Hyväksynyt 0.9 Juuso Mikkonen 1 (6) 25.11.2015 Lappeenrannan kaupungin tietoturvapolitiikka 2016 Muutoshistoria Versio Laatija Päiväys Muutokset Hyväksynyt 0.9 Juuso Mikkonen 25.11.2015 Valmis Tietohallintotyöryhmän käsittelyyn. 1.0

Lisätiedot

Harjoite 1: Kysymyksiä valmentajalle lasten innostuksesta ja motivaatiosta

Harjoite 1: Kysymyksiä valmentajalle lasten innostuksesta ja motivaatiosta Harjoite 1: Kysymyksiä valmentajalle lasten innostuksesta ja motivaatiosta 30-60 minuuttia valmentajan aikaa, ja Harjoituslomake ja kynä noin 1-2 viikkoa oman työn tarkkailuun. Tavoitteet Harjoite on kokonaisvaltainen

Lisätiedot

Ihmisten johtaminen, itsensä johtaminen ja organisaatiokulttuurin muutos

Ihmisten johtaminen, itsensä johtaminen ja organisaatiokulttuurin muutos Ihmisten johtaminen, itsensä johtaminen ja organisaatiokulttuurin muutos Johtamisen suurimpia haasteita Jatkuva uudistuminen ja nopea muutos Lisääntyvä monimutkaisuus Innovatiivisuuden ja luovuuden vaatimukset

Lisätiedot

Politiikka-asiakirjojen retoriikan ja diskurssien analyysi

Politiikka-asiakirjojen retoriikan ja diskurssien analyysi Politiikka-asiakirjojen retoriikan ja diskurssien analyysi Perustuu väitöskirjaan Sukupuoli ja syntyvyyden retoriikka Venäjällä ja Suomessa 1995 2010 Faculty of Social Sciences Näin se kirjoitetaan n Johdanto

Lisätiedot

SoberIT Ohjelmistoliiketoiminnan ja tuotannon laboratorio

SoberIT Ohjelmistoliiketoiminnan ja tuotannon laboratorio Informaatioverkostojen koulutusohjelma Ihminen ja vuorovaikutus Pääaineen rakenne: T100-1 Informaatioverkostojen perusmoduuli (A1) T200-2 Ihminen ja vuorovaikutus (A2) UUSI T110-3 Ihmisläheiset tietojärjestelmät

Lisätiedot