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-

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ

KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ KÄYTETTÄVYYSTESTAUS OSANA KETTERÄÄ KEHITYSTÄ Eeva Kangas 05.11.2015 @FixUi Oy 2013 2015 FIXUI "Autamme yrityksiä suunnittelemaan sellaisia tuotteita, joita ihmiset osaavat ja haluavat käyttää" Käyttäjätutkimukset

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, 21.1.2013 Johanna Kaipio, TkT, DI Tutkijatohtori ja opettaja Strategisen käytettävyyden

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

Käytettävyyslaatumallin rakentaminen verkkosivustolle

Käytettävyyslaatumallin rakentaminen verkkosivustolle Käytettävyyslaatumallin rakentaminen verkkosivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -tutkielma Timo Laapotti 9.6.2005 Esityksen sisältö Kirjoittajan

Lisätiedot

Ketterä projektinhallinta

Ketterä projektinhallinta Ketterä projektinhallinta Petri Heiramo Agile Coach, CST 1 Petri Heiramo Ikä: 37 (vielä pari päivää ) Oma koulutus- ja valmennusyritys, Agilecraft Oy, reilut 3 viikkoa Lähes 10v ohjelmistokehitys- ja -prosessitausta

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

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

PROJEKTINHALLINTA. Käyttäjälähtöinen suunnittelu

PROJEKTINHALLINTA. Käyttäjälähtöinen suunnittelu PROJEKTINHALLINTA Käyttäjälähtöinen suunnittelu PROJEKTINHALLINTA OSANA KURSSIA Opettaja: Tomi Jokitulppo email: Tomi.Jokitulppo@metropolia.fi puhelin: 040 5430197 4 opetuskertaa: 2.10., 9.10., 16.10.

Lisätiedot

Studio ART Oy. Yritysesittely. Studio ART Oy. Kasöörintie 14 90420 Oulu p. 040-5799073 www.studioart.fi

Studio ART Oy. Yritysesittely. Studio ART Oy. Kasöörintie 14 90420 Oulu p. 040-5799073 www.studioart.fi Studio ART Oy Yritysesittely Studio ART Oy Kasöörintie 14 90420 Oulu p. 040-5799073 www.studioart.fi Pekka Klemetti Managing Director pekka.klemetti@studioart.fi Studio ART Oy Toimiala ICT Avainsana Tuotekehitys,

Lisätiedot

Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä.

Toiminnallisen määrittelyn tarina. Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä. Toiminnallisen määrittelyn tarina Esimerkki Reaktorin tavasta tehdä toiminnallista määrittelyä. Toimitusjohtajan pulma Tässä on toimitusjohtaja Roope, jonka tavoitteena on pyörittää Rengasmaster Oy:tä

Lisätiedot

Käytettävyys tuotekehityksessä mitä pitäisi osata?

Käytettävyys tuotekehityksessä mitä pitäisi osata? Käytettävyys tuotekehityksessä mitä pitäisi osata? ( mitä tehdä konkreettisesti ja kuinka paljon?) Timo Jokela, FT, dos. Joticon Oy (Oulun yliopisto, Helsingin yliopisto) Käytettävyyseminaari Oulu 15.4.2011

Lisätiedot

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori

Testauksen tuki nopealle tuotekehitykselle. Antti Jääskeläinen Matti Vuori Testauksen tuki nopealle tuotekehitykselle Antti Jääskeläinen Matti Vuori Mitä on nopeus? 11.11.2014 2 Jatkuva nopeus Läpäisyaste, throughput Saadaan valmiiksi tasaiseen, nopeaan tahtiin uusia tuotteita

Lisätiedot

Ketterä vaatimustenhallinta

Ketterä vaatimustenhallinta Ketterä vaatimustenhallinta ja miksi se on useimmiten hyvä asia K A R I A L HO C E O I M P R OV EIT OY Sisältö ImproveIt Oy Perinteinen vaatimushallinta Ketterä vaatimustenhallinta Monenlaista softakehitystä

Lisätiedot

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa 1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä

Lisätiedot

Scrumjatkuvan palvelun DWprojektissa-case. Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy

Scrumjatkuvan palvelun DWprojektissa-case. Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy Scrumjatkuvan palvelun DWprojektissa-case OP-Pohjola Niina Mäkiranta & OP-scrum-tiimi Aureolis Oy Agenda Scrum lyhyesti Jatkuvan palvelun DW-projekti- Case OP-Pohjola Lähtötilanne ennen Scrumia Scrumin

Lisätiedot

Käyttäjäkeskeinen vaatimusmäärittelytyö ketterän käyttöliittymäsuunnittelun haasteena

Käyttäjäkeskeinen vaatimusmäärittelytyö ketterän käyttöliittymäsuunnittelun haasteena Käyttäjäkeskeinen vaatimusmäärittelytyö ketterän käyttöliittymäsuunnittelun haasteena, prof. Teknillinen korkeakoulu, tietotekniikan osasto SoberIT Ohjelmistoliiketoiminnan ja tuotannon laboratorio Käytettävyys

Lisätiedot

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.

Käytettävyyslaatumallin rakentaminen web-sivustolle. Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9. Käytettävyyslaatumallin rakentaminen web-sivustolle Tapaus kirjoittajan ABC-kortti Oulun yliopisto tietojenkäsittelytieteiden laitos pro gradu -suunnitelma Timo Laapotti 28.9.2005 Kirjoittajan ABC-kortti

Lisätiedot

Käytettävyyssuunnittelu. Kristiina Karvonen Käytettävyysasiantuntija Nokia Networks

Käytettävyyssuunnittelu. Kristiina Karvonen Käytettävyysasiantuntija Nokia Networks Käytettävyyssuunnittelu Kristiina Karvonen Käytettävyysasiantuntija Nokia Networks Mitä on käytettävyys helppo käyttää helppo oppia helppo muistaa virheetön miellyttävä käyttää Käyttäjän tehtävänä ei ole

Lisätiedot

Käytettävyyden arviointi ja käytettävyystestauksen soveltaminen terveydenhuollon tietojärjestelmien valinnassa

Käytettävyyden arviointi ja käytettävyystestauksen soveltaminen terveydenhuollon tietojärjestelmien valinnassa Käytettävyyden arviointi ja käytettävyystestauksen soveltaminen terveydenhuollon tietojärjestelmien valinnassa Janne Pitkänen Adusso Oy, Aalto yliopisto Matti Pitkäranta Adusso Oy Terveydenhuollon tietojärjestelmien

Lisätiedot

Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä

Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä Käytettävyyden huomiointi ohjelmisto prosessissa testausta lisäämällä Agenda Tehtävänanto Johdanto Näkökulma Ohjelmistotuotantoprosessit Testaus & arviointimenetelmät Menetelmien yhdistäminen, onnistuuko?

Lisätiedot

Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia

Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia Testauksen suunnittelu ja dokumentointi ketterässä testauksessa Tutkimustuloksia Nina Perta, Senior quality consultant Knowit Oy Elina Varteva, QA Specialist Knowit Oy Copyright Knowit Oy 2014 Nina Perta

Lisätiedot

Miten suunnitella hyvä käyttöliittymä?

Miten suunnitella hyvä käyttöliittymä? Miten suunnitella hyvä käyttöliittymä? 6.5.2010 Timo Jokela Timo Jokela FT (2001), dosentti (Oulun yliopisto 2009) historiaa 1990-luvun alussa VTT:llä käyttöliittymien mallinnusta 1995 Nokia Mobile Phones,

Lisätiedot

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015

Fiksumpi käyttöliittymä kuntaan. Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Fiksumpi käyttöliittymä kuntaan Miten kuntien tietojärjestelmät saadaan palvelemaan kuntalaisia? LapIT-päivät 2015 Otso Kivekäs 20.8.2015 Otso Kivekäs+ Codento Kehittämispäällikkö, kunta-alan projektit

Lisätiedot

Miten varmistaa käytettävyys terveydenhuollon tietojärjestelmien* hankinnoissa? Vaihtoehdot ja niiden haasteet?

Miten varmistaa käytettävyys terveydenhuollon tietojärjestelmien* hankinnoissa? Vaihtoehdot ja niiden haasteet? Miten varmistaa käytettävyys terveydenhuollon tietojärjestelmien* hankinnoissa? Vaihtoehdot ja niiden haasteet? Timo Jokela, FT, dos. Joticon Oy (Oulun yliopisto, Helsingin yliopisto) *asiakaskohtaisten

Lisätiedot

OppiScrum opintojen läpäisyasteen ja oppimisen omistajuuden edistäjänä

OppiScrum opintojen läpäisyasteen ja oppimisen omistajuuden edistäjänä Jengi duunaa ihan tosissaan! OppiScrum opintojen läpäisyasteen ja oppimisen omistajuuden edistäjänä Otto Burman Virpi Peuralinna Pirkka Ruishalme Linda Salminen Oppimisen ja opettamisen haasteet Oppimisen

Lisätiedot

Yhteisöllisen toimintatavan jalkauttaminen!

Yhteisöllisen toimintatavan jalkauttaminen! Yhteisöllisen toimintatavan jalkauttaminen! Käyttöönoton vaiheet Yrityksen liiketoimintatavoitteet Yhteisöllisen toimintatavan käyttöalueet Työkalut Hyödyt yritykselle Hyödyt ryhmälle Hyödyt itselle Miten

Lisätiedot

Yhteisöllisen tuotekehyksen avoin verkkolaboratorio. Asta Bäck

Yhteisöllisen tuotekehyksen avoin verkkolaboratorio. Asta Bäck Yhteisöllisen tuotekehyksen avoin verkkolaboratorio Asta Bäck Sosiaalisen median mahdollisuuksia Palvelu voi rakentua kokonaan käyttäjien tuottaman aineiston ja käyttäjien aktiviteetin ympärille Flickr

Lisätiedot

COTOOL dokumentaatio SEPA: Käytettävyystestaus

COTOOL dokumentaatio SEPA: Käytettävyystestaus Table of Contents Käytettävyystestaus......................................................................... 1 1 Johdanto.................................................................................

Lisätiedot

Kirjaston verkkopalvelun suunnittelu käyttäjäkeskeisesti

Kirjaston verkkopalvelun suunnittelu käyttäjäkeskeisesti Kirjaston verkkopalvelun suunnittelu käyttäjäkeskeisesti STKS Tietoaineistoseminaari 14.3.2012 Päivi Ylitalo-Kallio Eduskunnan kirjasto (Metropolia Ammattikorkeakoulun kirjasto) Vähän minusta Päivi Ylitalo-Kallio

Lisätiedot

Ohjelmistoprojektien hallinta Vaihejakomallit

Ohjelmistoprojektien hallinta Vaihejakomallit Ohjelmistoprojektien hallinta Vaihejakomallit Vaihejakomallit TAVOITE: YMMÄRTÄÄ eri vaihejakomallien etujajahaittoja 2 Erilaisia malleja Tee ja korjaa (Code-and-Fix) Vesiputousmalli (Waterfall) Vesiputousmalli

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA

Ohjelmointitekniikka lyhyesti Survival Kit 1 Evtek KA ELINKAARIMALLEISTA Ohjelmointitekniikka lyhyesti Survival Kit. Vesiputousmalli ELINKAARIMALLEISTA. Ohjelmiston elinkaari Ohjelmiston elinkaarella (life cycle) tarkoitetaan aikaa, joka kuluu ohjelmiston kehittämisen aloittamisesta

Lisätiedot

Urban Design Management ja lisäarvo - Integroiva suunnitteluoperaatio. Tommi Mäkynen 14.12.2007 maekynen@arch.ethz.ch

Urban Design Management ja lisäarvo - Integroiva suunnitteluoperaatio. Tommi Mäkynen 14.12.2007 maekynen@arch.ethz.ch Urban Design Management ja lisäarvo - Integroiva suunnitteluoperaatio Tommi Mäkynen 14.12.2007 maekynen@arch.ethz.ch Mitä arvo on? Arvo on subjektiivinen ja asiakas moninainen Helsinki Design District?

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

Ketterä kehitys yhteistyöhankkeessa. 11.12.2014 Sami Hautakangas, OTM-hanke

Ketterä kehitys yhteistyöhankkeessa. 11.12.2014 Sami Hautakangas, OTM-hanke Ketterä kehitys yhteistyöhankkeessa 11.12.2014 Sami Hautakangas, OTM-hanke Esityksen sisältö 1. Hanke ja sen organisointi 2. Ketterä projekti - ketterä kehitys - ketterä käyttöönotto 3. Opittua 1 Hanke

Lisätiedot

Palvelujen konseptointi

Palvelujen konseptointi Palvelujen konseptointi TWG Mikko Koivisto 22.4.2013 1 PaMu Ideointi PaMu Ideointi Vaihtoehtoisten palveluratkaisujen ideointi kertyneeseen ymmärrykseen (mm. käyttäjätarpeet ja palveluntarjoajan tavoitteet),

Lisätiedot

Käyttäjäkeskeisen suunnittelun sulauttaminen osaksi tuotekehitysprosessia

Käyttäjäkeskeisen suunnittelun sulauttaminen osaksi tuotekehitysprosessia http://www.cs.tut.fi/ihte http://www.cs.tut.fi/ihte/projects/kaste Käyttäjäkeskeisen suunnittelun sulauttaminen osaksi tuotekehitysprosessia Kati Kuusinen Esityksen sisältö Työn taustasta Työn tavoitteista

Lisätiedot

Käytettävyystyön laatu: tarjotaanko oikeita palveluja, tuotetaanko oikeita tuloksia?

Käytettävyystyön laatu: tarjotaanko oikeita palveluja, tuotetaanko oikeita tuloksia? Käytettävyystyön laatu: tarjotaanko oikeita palveluja, tuotetaanko oikeita tuloksia? Timo Jokela, FT Timo Jokela, FT historiaa 1990-luvun alussa VTT:llä käyttöliittymien mallinnusta 1995 Nokia Mobile Phones,

Lisätiedot

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

Käyttöliittymän suunnittelu tilastotieteen verkko-opetukseen. Jouni Nevalainen Käyttöliittymän suunnittelu tilastotieteen verkko-opetukseen Jouni Nevalainen Esityksen sisällysluettelo Työn tausta Ongelman asettelu Käsitteitä ja määritelmiä Käytetyt menetelmät Tulokset Johtopäätökset

Lisätiedot

TIETOTEKNIIKAN KOULUTUSOHJELMA

TIETOTEKNIIKAN KOULUTUSOHJELMA TIETOTEKNIIKAN KOULUTUSOHJELMA Tietotekniikan koulutusohjelman toimintaympäristö ja osaamistavoitteet Tietotekniikan koulutusohjelmasta valmistuneet insinöörit sijoittuvat suunnittelu-, ohjelmointi-, esimies-,

Lisätiedot

Työkalut ohjelmistokehityksen tukena

Työkalut ohjelmistokehityksen tukena 1 Työkalut ohjelmistokehityksen tukena Johdanto 2 Työkaluja eli ohjelmistotyötä tukevia ohjelmistoja käytetään ohjelmistoalan yrityksissä nykypäivänä paljon. Työkalut auttavat ohjelmistoalan ihmisiä suunnittelemaan

Lisätiedot

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011

AVOIMEN TUOTTEEN HALLINTAMALLIT. Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö. Yhteentoimivuutta avoimesti 2.12.2011 AVOIMEN TUOTTEEN HALLINTAMALLIT Kunnassa toteutettujen tietojärjestelmien uudelleenkäyttö Yhteentoimivuutta avoimesti 2.12.2011 Erikoistutkija, MSc. Tapio Matinmikko, Teknologian tutkimuskeskus VTT 2 Esittäjästä

Lisätiedot

Multisite -projektit uhasta mahdollisuus? Johtamiseväitä projektipäällikölle

Multisite -projektit uhasta mahdollisuus? Johtamiseväitä projektipäällikölle Multisite -projektit uhasta mahdollisuus? Johtamiseväitä projektipäällikölle TTY / Projektinhallintapäivä 23.8.2011 Olli-Pekka Mäkirintala olli-pekka.makirintala@altonova.fi 040 5541031 Olli-Pekka Mäkirintala

Lisätiedot

Käyttäjäkeskeinen suunnittelu

Käyttäjäkeskeinen suunnittelu Käyttäjäkeskeinen suunnittelu Aapo Puskala Käytettävyystutkija, CEO User Point Oy aapo.puskala@userpoint.fi www.userpoint.fi Aapo Puskala Käytettävyystutkija, CEO +358 40 722 0706 aapo.puskala@userpoint.fi

Lisätiedot

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät

Ohjelmistotekniikka kevät 2003 Laatujärjestelmät Laatujärjestelmät Ohjelmistotekniikka kevät 2003 Prosessiajattelu Sisään Prosessi Ulos ohjaus mittaus Laatujärjestelmät Laatujärjestelmät määrittelevät sen, mitkä prosessit täytyy olla määritelty ei sitä,

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

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara

Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara Globaalisti Hajautettu Ohjelmistokehitys Mitä, Miksi & Miten? Maria Paasivaara Mitä? Mitä? Yrityksen sisäinen Mitä? Yrityksen sisäinen Alihankinta Mitä? Yrityksen sisäinen Open Source -kehitys Alihankinta

Lisätiedot

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

SEPA päiväkirja. Dokumentti: SEPA_diary_EM_PV.doc Päiväys: 26.10.2004 Projekti : AgileElephant Versio: V0.9 AgilElephant T-76.115 Esa Mommo, 57197J Pauli Vesterinen, 65220P Tekijä: Esa Mommo/Pauli Vesterinen Omistaja: ElectricSeven Aihe: Sivu 1 of 6 Dokumentti Historia Revisio Historia Revision päiväys: 26.10.2004

Lisätiedot

HELIA 1 (1) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu 02.11.00 16:08

HELIA 1 (1) Outi Virkki Käyttöliittymät ja ohjelmiston suunnittelu 02.11.00 16:08 HELIA 1 (1) Luento 9 Käytettävyyden arviointi... 2 Yleistä... 2 Menetelmiä... 3 Etuja... 3 Ongelmia... 3 Palautteet... 4 Käyttäjäkyselyt ja haastattelut... 5 Ryhmäläpikäynti... 7 Käyttäjien havainnointi...

Lisätiedot

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

KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014. Käyttäjätutkimus ja käsitteellinen suunnittelu. Järjestelmän nimi. versio 1.0 KÄYTTÄJÄKOKEMUKSEN PERUSTEET, TIE-04100, SYKSY 2014 Käyttäjätutkimus ja käsitteellinen suunnittelu Järjestelmän nimi versio 1.0 Jakelu: Tulostettu: 201543 Samuli Hirvonen samuli.hirvonen@student.tut.fi

Lisätiedot

Palvelumuotoilu ja muotoiluajattelu bisneksessä

Palvelumuotoilu ja muotoiluajattelu bisneksessä Palvelumuotoilu ja muotoiluajattelu bisneksessä Hanna-Riina Vuontisjärvi Projektipäällikkö/ Palvelumuotoilija Lapin yliopisto, Taiteiden Tiedekunta hanna-riina.vuontisjarvi@ulapland.fi Mitä palvelumuotoilija

Lisätiedot

Mitä käytettävyys on? Käytettävyys verkko-opetuksessa. Miksi käytettävyys on tärkeää? Mitä käytettävyys on? Nielsen: käytettävyysheuristiikat

Mitä käytettävyys on? Käytettävyys verkko-opetuksessa. Miksi käytettävyys on tärkeää? Mitä käytettävyys on? Nielsen: käytettävyysheuristiikat Mitä käytettävyys on? Käytettävyys verkko-opetuksessa 21.8.2002 Jussi Mantere Learnability (opittavuus) Efficiency (tehokkuus) Memorability (muistettavuus) Errors prevented (virheiden tekeminen estetty)

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

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena Mittaaminen ja ohjelmistotuotanto seminaari 18.04.01 Matias Vierimaa 1 Miksi mitataan? Ohjelmistokehitystä ja lopputuotteen laatua on vaikea arvioida

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

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

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

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Kandidaatintyön aiheita

Kandidaatintyön aiheita Kandidaatintyön aiheita PM&RG:n aihe-ehdotukset Mervi L. Ranta ja Henrik J. Asplund Mervi L. Ranta & Henrik J. Asplund PL 15400, 00076 AALTO email: pmrg@tkk.fi FINLAND http://www.cs.hut.fi/~pmrg Version

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

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

Harjoituskoe Vastaukset. ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus

Harjoituskoe Vastaukset. ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus Harjoituskoe Vastaukset ISTQB Ketterä testaaja 2015 Perustason sertifikaattisisällön laajennus Alkup. versio 1.0 Käännösversio 1.0 Tekijänoikeushuomautus Tämän dokumentin saa kopioida kokonaisuudessaan

Lisätiedot

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Organisaation toiminnan kehittämisen sykli

JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Organisaation toiminnan kehittämisen sykli JHS 179 ICT-palvelujen kehittäminen: Kokonaisarkkitehtuurin kehittäminen Liite 1 Organisaation toiminnan kehittämisen sykli Versio: 1.0 Julkaistu: 8.2.2011 Voimassaoloaika: toistaiseksi Sisällys 1 Organisaation

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

Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla:

Nimi: Opnro: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä. 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: Harjoitustyön suoritus: ( ) syksy 2006 ( ) syksy 2005 ( ) muu, mikä 1. Selitä seuraavat termit muutamalla virkkeellä ja/tai kaaviolla: a) käytettävyys b) käyttäjäkeskeinen suunnittelu c) luonnollinen kieli

Lisätiedot

työryhmien SharePoint-yhteistyötä helpottava ratkaisu

työryhmien SharePoint-yhteistyötä helpottava ratkaisu työryhmien SharePoint-yhteistyötä helpottava ratkaisu LIIKKEENJOHDON SUURIN HAASTE Modernin yrityksen on muutoksen kyydissä pysyäkseen suunniteltava tehokas strategia ja seurattava sitä. Siinä piilee kuitenkin

Lisätiedot

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Ohjelmistotekniikka - Luento 2 Jouni Lappalainen Luku 2: Prosessimallit - miten spiraalimalliin päädyttiin - spiraalimallista (R)UP malliin - oman ammattitaidon kehittäminen; PSP ja TSP mallit Luku 3:

Lisätiedot

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita!

Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! Kehittää ohjelmointitehtävien ratkaisemisessa tarvittavia metakognitioita! eli... Hyvä kaava sanoo enemmän kuin,... tuhat riviä koodia!... sata riviä tekstiä!... kymmenen diagrammia! YLEISTÄ FORMAALEISTA

Lisätiedot

1. Johdanto. Ohjelmistotuotannon ongelmia

1. Johdanto. Ohjelmistotuotannon ongelmia 1. Johdanto Mitä ohjelmistotuotanto on? ohjelmointi + ohjelmisto + tekniikat + insinööritaito + kurinalainen työskentely Määritelmä (60-luvun ohjelmistokriisi): The establishment and use of sound principles

Lisätiedot

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI Vesa Tenhunen Tarkastusmenettelyt Keino etsiä puutteita ohjelmakoodeista, dokumenteista ym. ohjelmistoprosessissa syntyvästä materiaalista Voidaan käyttää kaikissa

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

Ketterä (agile) tietojärjestelmien suunnittelu

Ketterä (agile) tietojärjestelmien suunnittelu Ketterä (agile) tietojärjestelmien suunnittelu Abrahamsson P, Conboy B and Wang X, Lots done, more to do: the current state of agile systems development research European Journal of Information Systems

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

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

28.8.1975 ruovedellä pohjois-hämeessä. lepounit.com (yritys) lepo.net (oma)

28.8.1975 ruovedellä pohjois-hämeessä. lepounit.com (yritys) lepo.net (oma) Muokattu: 2015-01-29 Viimeisin versio: http://lepo.net/cv/fi CV taru puhuvasta nörtistä henkilötiedot nimi anu leponiemi syntynyt 28.8.1975 ruovedellä pohjois-hämeessä sähköposti ja www anu (at) lepounit.com

Lisätiedot

TUTKIMUKSEN LÄHTÖKOHTIA, TOTEUTUS ja HYÖDYT Kalle Saastamoinen Lappeenrannan Teknillinen Yliopisto LTY 2003

TUTKIMUKSEN LÄHTÖKOHTIA, TOTEUTUS ja HYÖDYT Kalle Saastamoinen Lappeenrannan Teknillinen Yliopisto LTY 2003 KÄYTETTÄVYYDEN TUTKIMISELLAKO TOIMIVAMMAT WWW-SIVUT? TUTKIMUKSEN LÄHTÖKOHTIA, TOTEUTUS ja HYÖDYT Kalle Saastamoinen Lappeenrannan Teknillinen Yliopisto LTY 2003 Sisältö Mitä on tarkoitetaan sanalla käytettävyys

Lisätiedot

Tilannekatsaus 4.11.2013. Opintopolku.fi

Tilannekatsaus 4.11.2013. Opintopolku.fi Tilannekatsaus 4.11.2013 tilannekatsaus 4.11.2013 Muuntotyön tilanne AT/EAT muunnossa olleet aineistot toimitettu Opetushallitukselle. Muunnettuja tutkintoja 114, 13 tutkintoa jäänyt muuntamatta niihin

Lisätiedot

Aineistoista. Laadulliset menetelmät: miksi tarpeen? Haastattelut, fokusryhmät, havainnointi, historiantutkimus, miksei videointikin

Aineistoista. Laadulliset menetelmät: miksi tarpeen? Haastattelut, fokusryhmät, havainnointi, historiantutkimus, miksei videointikin Aineistoista 11.2.09 IK Laadulliset menetelmät: miksi tarpeen? Haastattelut, fokusryhmät, havainnointi, historiantutkimus, miksei videointikin Muotoilussa kehittyneet menetelmät, lähinnä luotaimet Havainnointi:

Lisätiedot

Tik-76.612 Harjoitustyö

Tik-76.612 Harjoitustyö Tik-76.612 Harjoitustyö Harjoitustyö Tehdään 2-3 hengen ryhmissä Koostuu etapeista joiden aikana simuloidaan ohjelmistoprojektin läpivientiä On nivottu osaksi kurssin luentoja On pakollinen 2 Harjoitustyön

Lisätiedot

Onko sinun ideasi seuraava menestystarina? Pyydä asiantuntija-arvio alueesi Tuoteväylä-tiimistä

Onko sinun ideasi seuraava menestystarina? Pyydä asiantuntija-arvio alueesi Tuoteväylä-tiimistä Onko sinun ideasi seuraava menestystarina? Pyydä asiantuntija-arvio alueesi Tuoteväylä-tiimistä Tuo ideasi Tuoteväylän asiantuntijoiden arvioitavaksi Onko sinulla uusi innovatiivinen idea, josta voisi

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

Ostavat organisaatiot konsultin silmin

Ostavat organisaatiot konsultin silmin Ostavat organisaatiot konsultin silmin Softaa sutjakasti - Kuinka pitää projektimopo käsissä Sytyke Ry:n laivaseminaari 9.9.2009 Paula Miinalainen, Arbor Vitae Konsulttina monitoimittajaympäristöissä muutosten

Lisätiedot

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön

Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko - Viitekehys alueellisten verkostojen yhteistyöhön Aikuisopiskelijan viikko tarjoaa mainion tilaisuuden toteuttaa tapahtumia yhteistyössä oman alueen eri organisaatioiden kanssa.

Lisätiedot

Matopeli C#:lla. Aram Abdulla Hassan. Ammattiopisto Tavastia. Opinnäytetyö

Matopeli C#:lla. Aram Abdulla Hassan. Ammattiopisto Tavastia. Opinnäytetyö Matopeli C#:lla Aram Abdulla Hassan Ammattiopisto Tavastia Opinnäytetyö Syksy 2014 1 Sisällysluettelo 1. Johdanto... 3 2. Projektin aihe: Matopeli C#:lla... 3 3. Projektissa käytetyt menetelmät ja työkalut

Lisätiedot

Strathclyde-prosessi

Strathclyde-prosessi Strathclyde-prosessi (Materiaali pohjautuu Terry Williamsin luentokalvoihin The Catastrophic Project - an examination of some real-life project failures and an exposure of root causes. Project Management

Lisätiedot

Suomen Hiusyrittäjät ry Ajanvarausjärjestelmän tarjous

Suomen Hiusyrittäjät ry Ajanvarausjärjestelmän tarjous Ajanvarausjärjestelmän tarjous 13.1.2012 1/7 Tarjous Tarjous on osa yhteistä LeasIT Oyn ja DigitalBooker Finland Oyn yhteistarjousta jossa tarjoamme Kassa- ja ajanvarausjärjestelmien kombinaatiota. Tämä

Lisätiedot

Webforum. Version 14.4 uudet ominaisuudet. Viimeisin päivitys: 2014-12-6

Webforum. Version 14.4 uudet ominaisuudet. Viimeisin päivitys: 2014-12-6 Webforum Version 14.4 uudet ominaisuudet Viimeisin päivitys: 2014-12-6 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Yleistä & hallinnointi... 5 Dokumentit... 5 Perättäinen tarkistus- ja hyväksymisprosessi...

Lisätiedot

PROJEKTINHALLINTA SCRUMIN AVULLA

PROJEKTINHALLINTA SCRUMIN AVULLA PROJEKTINHALLINTA SCRUMIN AVULLA Anttoni Lahtinen Mika Suikkanen Saana Vaateri Helmikuu 2016 Tietojenkäsittely Proakatemia 2 SISÄLLYS 1 JOHDANTO... 3 1.1 Ketterä kehitys... 3 1.2 Melu... 4 2 SCRUMIN ROOLIT...

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

EDISTYMISRAPORTTI - PS Virtuaaliyhteisöjen muodostaminen Versio 1.0

EDISTYMISRAPORTTI - PS Virtuaaliyhteisöjen muodostaminen Versio 1.0 EDISTYMISRAPORTTI - PS Edited by Checked by Approved by Antti Tuomaala Harri Kauhanen i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. PROJEKTIN TILA 2 2. SUORITETUT TEHTÄVÄT 3 Projektisuunnitelma 3 Vaatimusmäärittely

Lisätiedot

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi

Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Good Minton Sulkapalloliiton Kilpailujärjestelmä SEPA: Heuristinen arviointi Versiohistoria: Versio: Pvm: Laatijat: Muutokset: 0.1 2006-11-25 Janne Mäkelä Alustava 1.0 2006-12-10 Janne Mäkelä Valmis 1.

Lisätiedot

Esimiehen opas erityisesti vuorotyötä tekevissä yksiköissä

Esimiehen opas erityisesti vuorotyötä tekevissä yksiköissä Työhyvinvointikyselyn tulosten käsittely ja hyvinvointisuunnitelman laatiminen työyksikön hyvinvointipajassa Esimiehen opas erityisesti vuorotyötä tekevissä yksiköissä Lapin sairaanhoitopiirin työhyvinvointisyke

Lisätiedot

IPT-hanke: Kehitysvaihe -työpaja Työpaja 5: Kokoushotelli Gustavelund 26.-27.5.2015

IPT-hanke: Kehitysvaihe -työpaja Työpaja 5: Kokoushotelli Gustavelund 26.-27.5.2015 Integroitujen projektitoimitusten kehittäminen johtavien tilaajien ryhmähankkeena (IPT-hanke) IPT-hanke: Kehitysvaihe -työpaja Työpaja 5: Kokoushotelli Gustavelund 26.-27.5.2015 IPT-hanke; kehitysvaihe-työpaja

Lisätiedot

Mitä kokonaisarkkitehtuurityöllä haetaan? Miika Nurminen Johtaja, Kokonaisarkkitehtuuriratkaisut QPR Software Oyj

Mitä kokonaisarkkitehtuurityöllä haetaan? Miika Nurminen Johtaja, Kokonaisarkkitehtuuriratkaisut QPR Software Oyj Mitä kokonaisarkkitehtuurityöllä haetaan? Miika Nurminen Johtaja, Kokonaisarkkitehtuuriratkaisut QPR Software Oyj http://www.britannica.com/ blogs/2009/10/the-classictree-swing-example-ofproduction-and-customerservice-gone-awry/

Lisätiedot

7. Iteratiivinen ohjelmistokehitys

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

Lisätiedot

Lomalista-sovelluksen määrittely

Lomalista-sovelluksen määrittely Thomas Gustafsson, Henrik Heikkilä Lomalista-sovelluksen määrittely Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikka Dokumentti 14.10.2013 Tiivistelmä Tekijä(t) Otsikko Sivumäärä Aika Thomas

Lisätiedot

Talent Q. työsuhteen elinkaaren kaikkiin eri vaiheisiin.

Talent Q. työsuhteen elinkaaren kaikkiin eri vaiheisiin. Talent Q henkilöstön kehittämisen seuraava askel Perinteisesti organisaatiot käyttävät useita soveltuvuusarviointityökaluja henkilöstön osaamisen kehittämisen eri vaiheissa. Eri menetelmien ylläpito kuitenkin

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