Verkkopalvelun sisällöntuotanto 2. luento 11.12.2007 erikoistutkija Kirsi Silius tutkija Anne-Maritta Tervakari Tampereen teknillinen yliopisto 1
Teemat Aiempien vuosien harjoitustöiden aiheita Luento: Mitä verkkopalvelun suunnittelu yleensä on? Miten suunnittelutyö yleensä etenee? Suunnittelumallien tarkoitus Muutamia suunnittelumalleja Luennon tavoitteena on johdattaa verkkopalvelun sisällön ja toimintaprosessien suunnittelutyöhön. 2
Aiempien vuosien harjoitustöitä Nordic Jet Line http://www.njl.fi jatkokehitys IC Toolbox aineettoman pääoman tuottavuuden kehittämisen välineenä hanke uusi palvelu Domus Mundus palvelu kotitaloustyön tekijöiden ja palveluiden varaamisen helpottamiseksi uusi palvelu Juorukello palvelu suomalaisille juoruilusta kiinnostuneille uusi palvelu Alasarjat.com jalkapalloilun aladivisioonat, ottelutuloksia yms. vanhan palvelun uudistaminen (uusi palvelu käytännössä) OHO opiskelunhallinta ja oppimisympäristö uusi palvelu TTY:n opiskelijoille Tampereen TietoTeekkarikillan kotisivut http://tite.cs.tut.fi/ Vanhan sivuston uudistaminen 3
Aiempien vuosien harjoitustöitä Mielipidekysely viihteellinen palvelu, jonka avulla ihmiset voivat tehdä erilaisia kyselyitä uusi palvelu Kangasalan SK-suunnistusseuran kotisivut http://www.kangasalask.fi/ --> jatkokehitys Suomalainen elokuvaportaali elokuvien arvostelu uusi palvelu englanninkielisen pohjalta Pistokset.net oppimateriaali lääkäreille injektioiden antamisesta uusi palvelu Urheiluareena miehille suunnattu urheilusivusto uusi palvelu Varjo opinto-opas opintojaksojen arviointisivusto uusi palvelu Avaruus verkkojulkaisu http://www.avaruusmgz.info/ jatkokehitys SubTV.fi http://www.subtv.fi/ jatkokehitys Tehomylly.net http://www.tehomylly.net/ jatkokehitys 4
Mistä lähdetään liikkeelle? Toimeksianto (briefing) on lähtökohtana koko tuotantoprosessille. Toimeksiannossa tilaaja määrittelee minkälaisen verkkopalvelun tai sisällön hän tilaa. Toimeksianto on tilaajan vastuulla. Usein se tehdään kuitenkin yhteistyössä, sillä toimeksiannon tulee olla riittävän yksiselitteinen ja kattava, jotta molemmat sekä tilaaja että toimittaja ovat yhtä mieltä siitä, mihin lopputulokseen pyritään. (Keränen, Lamberg & Penttinen 2003, 24. ) 5
Mistä lähdetään liikkeelle? Toimeksiannossa määritellään: Tavoite: Mihin verkkopalvelua tai -sisältöä tarvitaan? Tyyli: Miten asiat viestitään? Mitä toiminnallisuus viestittää? Kohderyhmä: Kenelle verkkopalvelu on suunnattu? Keihin halutaan vaikuttaa? Jakelu: Millä viestimillä/välineillä verkkopalvelun tai sisällön saavuttaa? Aikataulu: Millä aikataululla tuotantoprosessin tulee edetä? Budjetti: Paljonko verkkopalvelun tai sisällön tuotantoprosessi maksaa? (Keränen, Lamberg & Penttinen 2003, 24. ) 6
Mistä lähdetään liikkeelle? Ideointivaiheesta... Verkkosisältöjen ideointi lähtee harvoin aivan puhtaalta pöydältä. Ideointi käynnistyy, kun on havaittu tarpeita, joihin verkossa voitaisiin vastata. Tarpeet voivat liittyä näkyvyyteen, tunnettuvuuteen, vaikuttamiseen tai verkkoon halutaan siirtää toimintoja antaa tai saada jotakin. Kaikki ideat eivät ole toteuttamiskelpoisia. Tarvitaan myös kriittistä tarkastelua Mitä erityistä lisäarvoa verkko voi tuottaa ja mitä erityistä annettavaa verkkosisällöllä tai -palvelulla tulee olemaan.... kohti suunnitteluvaihetta 7
Mitä verkkopalvelun suunnittelu on? Verkkopalveluiden suunnittelu on monivaiheinen ja monipuolinen prosessi, johon tulee panostaa aikaa ja asiantuntemusta. Huonoja suunnitelmia on myöhemmin vaikea korvata edes tuotantovaiheen asiantuntemuksella. Suurempien verkkopalveluiden suunnittelutyöhön on varattava 2-8 kuukauden työpanos. Verkkopalvelun suunnittelutyössä on kaksi puolta: projektin suunnittelu, budjetointi, aikataulutus ja työjako sekä varsinaisen tuotteen/palvelun ja sen sisällön yksityiskohtainen suunnittelu ja määrittely (Esim. Grönroos 1990, 58 67; Parasuraman, Zeithaml & Malhotra 2005.) 8
Mitä verkkopalvelun suunnittelu on? Suunnittelutyön tueksi tarvitaan perusinformaatiota: palveluntarjoajasta ja sen (liike)toiminnasta, palvelun kohderyhmän toiminnasta ja tarpeista sekä Internetistä ja verkkopalveluista Suunnittelussa tarvitaan asiantuntemusta: sisällön, markkinoinnin, asiakaspalvelun, viestinnästä sekä erityisesti verkkopalvelun asiantuntijoita. Suunnittelussa pitää olla mukana myös toteutustekniikan asiantuntijoita. (Esim. Grönroos 1990, 58 67; Parasuraman, Zeithaml & Malhotra 2005.) 9
Verkkopalvelun tuotantoprosessi Verkkopalvelun tuotantoprosessi hahmotetaan syklinä ideoinnista toteutukseen, ja edelleen ylläpitoon ja jatkokehittelyyn. Se sisältää spiraalimaista etenemistä: ideoiden, suunnittelun ja toteuttamisen asteittaista syvenemistä tuotantoprosessin aikana. Verkkopalvelun tuotantoprosessi. Lähde: Kauhanen-Simanainen 2001, 73) 10
Mitä verkkopalvelun suunnittelu on? 1. Ohjelmisto (käyttöliittymä) (software interface): Toiminnot ja tehtävät (tasks), jotka vievät asiointiprosesseja eteenpäin (verkkopalvelu on työkalu, jota käyttämällä asiakas saavuttaa tavoitteensa). Korostuu operatiivisissa, tehtäväkeskeisissä verkkopalveluissa. Olennaista on tehtäväkeskeisyys. 2. Hypertekstijärjestelmä (hypertext system): Informaatioavaruus, missä asiakkaat liikkuvat. Korostuu viestinnällisissä verkkopalveluissa - mitä informaatiota asiakkaille tarjotaan ja mitä informaatio merkitsee asiakkaille. Olennaisinta on informaatiokeskeisyys. (Garret 2003, 27 31.) 11
Tuotteen/palvelun suunnittelun alueita Taso 1: Palvelun strategia (strategy plane) käyttäjien tarpeiden määrittely palveluntuottajan tavoitteet esim. liiketoiminnalliset tavoitteet Taso 2: Palvelun rajaus (scope plane) toiminnallisuuteen liittyvät vaatimukset informaatiosisällölliset vaatimukset Taso 3: Palvelun rakenne (structure plane) vuorovaikutuksen suunnittelu informaatioarkkitehtuurin suunnittelu Taso 4: Palvelun kehys (skeleton plane) informaation esitystavan suunnittelu käyttöliittymän suunnittelu liikkumisjärjestelmän suunnittelu Taso 5: Palvelun ulkoasu (surface plane) visuaalinen suunnittelu (Garret 2003, 33. ) 12
1. Palvelun strateginen suunnittelu Määritellään perusteet toteutettavalle palvelulle kuvataan palvelun idea, sisältö ja toiminta ( palvelun käyttötarkoitus) Asiakasryhmien (käyttäjäryhmien) tunnistaminen ominaisuudet tarpeet ja vaatimukset ulkoiset vaatimukset asiakassegmentit demografiset tekijät: esim. ikä, sukupuoli, tulotaso, perhestatus psykografiset tekijät: asenteet, arvot, uskomukset, persoonallisuuden piirteet elämäntyyli: digitaalinen elämäntyyli (web-usage-related lifestyle) Palveluntuottajan tavoitteet tarpeet ja vaatimukset sisäiset vaatimukset Liiketaloudelliset tavoitteet, yrityskuvaan liittyvät tavoitteet (imago, brandi) (Garret 2003. ) 13
1. Palvelun strateginen suunnittelu Erityisesti korostuu palveluprosessin suunnittelu. Palveluprosessin suunnittelussa tulee huomioidaan verkossa tapahtuvan palveluprosessin etenemisen lisäksi myös se, millä tavalla palveluprosessi etenee verkon ulkopuolella. Asiakkaiden tarpeiden määrittelyä, informaatiosisältöjen ja toimintaprosessien kuvausta käsitellään enemmän luennolla neljä. Täysin uudentyyppinen verkkopalvelu haasteena onko palvelulle tarvetta potentiaaliset asiakas (käyttäjä)ryhmät hyödynnetään usein tulevaisuuden tutkimuksen menetelmiä, joiden avulla pyritään kokoamaan tietoa päätöksenteon tueksi. (Garret 2003. ) 14
1. Palvelun strateginen suunnittelu - Ulkoisen ja sisäisen asiakkaan prosessit nivoutuvat toimintaprosesseissa. - Asiakas tarvitsee tiedon prosessin tilasta ja tuloksesta (esimerkkeinä POSTI ja e-lippu). asiakas tapahtuma 1 tapahtuma 2 tapahtuma 3 tehtävä 4 palvelun toimintoprosessi(t) toiminto 1 toiminto 2 toiminto 3 toiminto 4 lopputulos palvelun tarjoajan edustaja toimija 1 toimija 2 toimija 3 toimija 4 tiedoksi aika 15
2. Palvelun rajaus (sisällölliset ja toiminnalliset vaatimukset) Verkkopalvelun sisältö käsittelee jotakin aihetta kuten autoja, puutarhan hoitoa, urheilua jne. voi koostua useistakin aiheita, mutta viime kädessä niillä on kuitenkin jokin yhteinen nimittäjä esim. uutiset. on aina olemassa jäsennys ja esitystapa, jotka riippuvat mm. verkkopalvelun käyttötarkoituksesta, kohderyhmästä, genrestä ja toimintoprosesseista Sisällön suunnitteluvaiheessa määritellään ja rajataan palveluun tuleva sisältö sekä missä muodossa sisältö esitetään. Määritellään palvelun keskeiset toiminto- ja asiointiprosessit Hahmotellaan palvelun informaatioarkkitehtuuri Informaatiosisältöjen ja toiminto- ja asiointiprosessien yhteen nivominen Mitä vaatimuksia tekniselle toteuttamiselle? (Garret 2003. ) 16
3. Palvelun rakenne (structure plane) Syvennetään aiemmin hahmoteltua karkean tason informaatioarkkitehtuuria koskemaan yksittäisiä sisällön osa-alueita Informaatiosisällöt ryhmitellään kokonaisuuksiksi, nimetään ja järjestetään tarkoituksenmukaiseksi informaatiorakenteeksi. Informaatiosisällölle luodaan kestävä perusrakenne, laaditaan verkkopalvelun asiointiprosesseja tukevat vuorovaikutus- ja liikkumisjärjestelmät sekä hakutoiminnot. (Garret 2003. ) 17
4. Palvelun kehys (skeleton plane) Verkkopalveluihin voidaan liittää erilaisia mediaelementtejä. Mediasuunnitteluvaiheessa valitaan ne mediaelementit (ääni, kuva, teksti, animaatio), jotka ovat tarkoituksenmukaisia sisällön esittämisen kannalta. Mediasuunnittelu ottaa myös kantaa monikanavajulkaisemisen (eri mediat, eri päätelaitteet) vaatimuksiin. Verkkopalvelun käyttöliittymän suunnitteluun sisältyy sivuston rakenteen, visuaalisen (graafisen) ulkoasun, navigoinnin ym. toimintojen sekä näyttöjen tietosisältöjen suunnittelu. Käyttöliittymäsuunnittelun lopputuloksena syntyy käyttöliittymän määrittely, joka ottaa kantaa siihen, mitkä järjestelmän toiminnot näkyvät ja miten. Käyttöliittymän suunnittelu pohjaa pitkälle toiminnallisuuden ja informaatioarkkitehtuurin suunnitelmiin. tarkoituksena on, että käyttöliittymä tukee käyttäjien toimintalogiikkaa sekä käyttäjien tarvetta löytää tarvitsemansa tietosisältö. (Garret 2003. ) 18
5. Palvelun ulkoasu (surface plane) Visuaalisessa suunnittelussa verkkopalvelulle määritellään ulkoasu. lähtökohtana on palvelun kohderyhmä Huomioidaan myös palvelun käyttötarkoitus, imagoon ja kulttuuriin liittyvät tekijät Valittua visuaalista linjaa, yleisilmettä tulee noudattaa johdonmukaisesti jokaisella sivulla. Visuaalisen suunnittelun tekijän tulee tuntea ennen kaikkea internetin toimintaperiaatteet ja hallita www-taiton erityishaasteet. (Garret 2003. ) 19
Eri vaiheiden limittyminen Lähde: Garret 2003, 27 20
Suunnittelumalleja ja menetelmiä 21
Ad hoc - tai Trial and Error Tyypillisiä pienissä verkkopalveluprojekteissa toteuttava ryhmä on pieni ja tiivis toteutettava verkkopalvelu on suhteellisen rajattu sisällöltään ja toiminnallisuudeltaan. lähtee liikkeelle lähinnä kokeiluna, joka sitten viimeistellään ja hyväksytään lopulliseksi ratkaisuksi Nopeaa ja helppoa! Ongelmia: Jatkokehitys? Dokumentoimaton toteutus, jonka logiikkaa ei kukaan ulkopuolinen ymmärrä. Miten hallita verkkototeutusten kompleksisuutta? Miten hallita tuotantoprosessia, kun välitavoitteiden asettaminen on hankalaa? Miten arvioida kustannuksia ja työmäärää? Miten selvittää mitä käyttäjät ja/tai tilaajat itse asiassa haluavat? Etenkään kun tilaajakaan ei aina tiedä mitä haluaa. Mitä tehdä kun vaatimukset muuttuvat jopa projektin aikana? 22
Suunnittelumallin tarkoitus Auttaa käyttäjää hahmottamaan ja jäsentämään monimutkaista suunnittelu- ja toteutusprosessia. muodostaa yksinkertaistetun kuvan todellisuudesta auttaa käyttäjäänsä visualisoimaan suunnitteluprosessin kokonaisuutena auttaa jakamaan suunnitteluprosessin helpommin hallittaviin kokonaisuuksiin pyrkii havainnollistamaan suunnittelu- ja toteutusprosessin eri vaiheita ja niiden suhteita toisiinsa Toimivat siten projektinhallinnan apuvälineenä. (Esim. Ryder 2005 ) 23
Erilaisia suunnittelumalleja Suunnittelumalleja on erilaisia perinteisemmät suunnittelumallit, koostuvat erilaisista vaiheista (steps): vaatimusmäärittely, suunnittelu, toteutus, arviointi, jakelu ja käyttö sekä ylläpito (esim. Balci ym. 2001a). toisen polven suunnittelumallit koostuvat erilaisista tekijöistä (points), joihin suunnittelutyön aikana tulee kiinnittää huomiota korostavat suunnittelun kehämäisyyttä, jolloin yksittäiseen tekijään tulee kiinnittää huomiota useassa eri vaiheessa ketterät menetelmät, joille ominaista on mm. inkrementaalisuus Verkkopalvelujen suunnittelussa hyödynnetään eri alojen lähestymistapoja ja suunnittelumalleja Ohjelmistotuotanto, ihminen-tietokone vuorovaikutus, käytettävyystutkimus jne. 24
Suunnittelumallien jaottelua Ohjelmistotuotannon malleja Vesiputousmalli (the Waterfall Model) Spiraalimalli (the Spiral Model) ym. HCI suunnittelumalleja Usability Engineering Life Cycle Model Star Model ym. Hypermedian suunnittelumalleja The Object-Oriented Hypermedia Design Model (OOHDM) Scenario-Based Design ym. Ketterät menetelmät Adaptive Software Development (ASD), Agile Modeling (AM), Crystal Family, Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Feature-Driven Development (FDD), Scrum ym. ym. 25
Vesiputousmalli (the Waterfall Model) (Preece ym. 1994, 355-357. ) 26
Vesiputousmalli (the Waterfall Model) Olennaista: vaiheet seuraavat toisiaan ennalta määritellyssä järjestyksessä. jokainen vaihe päättyy arviointiin (tarkastukset ja katselmukset) jo suoritettuun vaiheeseen ei palata. Vaiheet (vaihtelevat hieman lähteestä riippuen) 1. vaatimus määrittely (requirement analysis,, system engineering, analysis) : järjestelmän tehtävät, päätoiminnot, ulkoiset vaatimukset ja rajoitukset, liittymät jne.) 2. suunnittelu (design): tekninen rakenne, pääkomponentit, tietorakenteet, käyttöliittymä yms. 3. toteutus (implementation): suunnitelman realisointi toimivaksi ohjelmaksi 4. testaus (testing): toimivuuden ja vaatimusten täyttyminen, virheiden korjaus 5. käyttöönotto : käyttäjien koulutus, asennukset 6. ylläpito (maintenance): tarvittavat korjaukset ja päivitykset (Preece ym. 1994, 355-357. ) 27
Vesiputousmalli (the Waterfall Model) Hyviä puolia: Helppo omaksua sekä selkeä ja yksinkertainen käyttää. Pitää sisällään periaatteessa kaikki tarvittavat vaiheet Soveltuu projektiin, tavoitteet ovat selkeät ja yksiselitteiset toteuttajana pieni, tehokas ja yhteen hitsautunut työtyhmä Tuloksena on helposti johdettava ja ennakoitava projekti. Ongelmia: Todellisen elämän projekti on harvoin lineaarinen. Ohjaa käsittelemään liian suuria kokonaisuuksia kerralla. Vaiheesta toiseen eteneminen on sidottu tarkastuksiin ja hyväksymisiin, mikä tekee mallista jäykän menetelmän. Toimiva järjestelmä asiakkaan käyttöön suhteellisen myöhäisessä vaiheessa nähdään konkreettisesti miltä toteutus näyttää ja miten se toimii loppukäyttäjän näkökulmasta tarkasteltuna. Loppuvaiheessa esiin nousseet muutostarpeet saattavat tulla todella kalliiksi. (Esim. Preece ym. 1994, 355 357.) 28
Spiraalimalli (the Spiral Model) 29
Spiraalimalli (the Spiral Model) Lukuisia eri versioita. yhdistyy iteratiivisen vaatimusmäärittelyn sekä lineaaristen mallien systemaattisen lähestymistavan sisältää samoja vaiheita kuin esim. vesiputousmalli. ratkaisuun ja valmiiseen tuotteeseen edetään iteroiden, useiden toistuvien syklien avulla korostaa riskien hallintaa Hyviä puolia: soveltuu suunniteluun, missä perusratkaisu ei ole täysin kirkastunut: mitä oikeastaan on tarkoitus tehdä edetään ongelman esittämisen ja ratkaisun sykleinä hioutuen valmiiksi ratkaisuehdotuksiksi, joita voidaan analysoida tarkemmin. riskien määrä vähenee kierros kierrokselta tukee myös asiakkaan sitoutumista suunnittelutyöhön. Ongelmia: suhteellisen vaikeasti hallittavissa, koska eri vaiheista on vaikea sanoa missä ne alkavat ja mihin ne päättyvät. ei sovellu aloitteleville suunnittelijoille asiakkaan jatkuva aktivointi voi olla myös ongelmana mallin mukainen suunnittelu on suhteellisen hidastempoista. (Vrt. Boehm 1988; Preece ym. 1994, 355 357.) 30
Star Model Hartsonin ja Hixin Star - malli (ref. Preece ym. 1994, 381) Implemen-tation Task analysis/ functional analysis Prototyping Evaluation Requirement specification Conceptual design/ formal design 31
Star Model Suunnittelutyön osa-alueiden järjestys on epäolennaista voi alkaa periaatteessa mistä tahansa vaiheesta edetä arviointivaiheen kautta mihin vaiheeseen hyvänsä. Arvioinnilla on keskeinen merkitys kaikki vaiheet arvioidaan käyttäjien ja asiantuntijoiden toimesta. korostaa myös prototyyppien käyttöä sekä inkrementaalista kehitystyötä. Hyviä puolia: korostaa käyttäjäkeskeisyyttä ja realistisuutta keskittyy selvittämään mitä järjestelmältä vaaditaan, mitä tietoa tarvitaan, mitä käyttäjien tulee tietää sekä miten asetetut tavoitteet saavutetaan saadaan nopeasti palautetta käyttäjiltä. (Preece ym. 1994, 380-381.) Ongelmia: projektin ja toteutuksen eri versioiden hallinta vaikeutuu samoin dokumentaatio hankaloituu kritisoitu: ainoastaan esittää vesiputousmallin vaiheet lisäten niihin arvioinnin, ei aidosti tue ihminen - tietokone vuorovaikutuksen suunnittelua. (Gellner & Forbrig 2003.) 32
Scenario-Based Design Malli korostaa käyttäjien tarpeiden ja vaatimusten määrittelyä: Miten käyttäjien tulee toimia saavuttaakseen tavoitteensa. Poikkeaa formaaleista ja tarkkaan määritellyistä menetelmistä. kevyt menetelmä, joka auttaa kartoittamaan mahdollisia käyttötapoja. Käytetään hyödyksi skenaarioita: Pieniä, rajattuja kertomuksia, jotka kuvaavat yhden mahdollisen tapahtumapolun. Soveltuvat varsin hyvin tiedon kokoamiseen käyttäjiltä heidän tehtävistään ja käyttötilanteesta helpottaen siten vaatimusanalyysin kiinnittämistä todelliseen ympäristöön. (Carroll ym. 1998; Potts 1995: Rosson & Carroll 2002.) 33
Scenario-Based Design Mallin vaiheet: Vaatimusten analysointi (analyze): edunsaajien (kohderyhmän) määrittely, toiminnallisten ja laadullisten vaatimusten määrittely hyödyntäen skenaarioita (problem scenarios). Suunnittelu (design): Toimintojen määrittely (activity design): vallitsevien toimintojen ja uusien tarkoituksenmukaisten toimintojen määrittely hyödyntäen skenaarioita (activity scenarios). Informaatiosisällön suunnittelu (information design): tehtävien suorittamisen ja tavoitteiden saavuttamisen kannalta olennaisen informaation sisällön ja aihioiden määrittely hyödyntäen skenaarioita (information scenarios). Prototyypit ja arviointi (prototype and evaluate): Käytettävyyden arviointi (usability evaluation): skenaarioiden hyödyntäminen käytettävyys tavoitteiden määrittelyssä. (Carroll ym. 1998; Potts 1995: Rosson & Carroll 2002.) 34
Scenario-Based Design Hyviä puolia: nopea ottaa käyttöön sekä helppo tehdä uudestaan tarvittaessa. suunnittelutyöhön voidaan helposti ottaa mukaan laajempikin käyttäjäjoukko. erilaiset ideat saadaan nopeasti testattua skenaariot ovat konkreettisia, on tuloksia helppo analysoida ja tulkita saadaan helposti reaalimaailman tapaukset arvioitaviksi. Ongelmia: Mallin hyödyntämisessä tarvitaan jonkinasteista perehtymistä ihmisen kognitiivisten prosessien ominaispiirteisiin ja sosiaaliseen käyttäytymiseen Käyttöönoton helppoudessa piilee vaaransa (ei osata lopettaa ajoissa) Aiheesta lisää luennolla 4. 35
Ketterät menetelmät Menetelmiä on lukuisia kuten esim. Adaptive Software Development (ASD), Agile Modeling (AM), Crystal Family, Dynamic Systems Development Method (DSDM), Extreme Programming (XP), Feature-Driven Development (FDD), Scrum ym. keskeisiä ominaisuuksia nopeus ja yksinkertaisuus, versioiden tiheä julkaiseminen, aktiivinen palautteen kokoaminen, inkrementaalisuus, iteratiivisuus korostavat mm. tiivistä yhteistyötä, kasvokkain tapahtuvaa kommunikointia, itseorganisoitumiskykyä, kykyä ottaa huomioon asiakkaiden vaatimusten muuttuminen missä kehitysvaiheessa tahansa (Abrahamsson ym. 2003) 36
(Abrahamsson ym. 2003)
Ketterien menetelmien eroavaisuudet Ohjelmistokehityksen elinkaaren kattaminen (software development life-cycle) Projektinhallinta (project management) Abstrakteja periaatteita vai konkreettisia ohjeita (abstract principles vs. concrete guidance) Yleisluonteinen menetelmä vs. tilannekohtainen menetelmä (universally predefined vs. situation appropriate) Tutkimuksellinen tuki (empirical support) (Abrahamsson ym. 2003) 38
The field is crying for methodological quality - not method quantity. (Abrahamsson ym. 2003, 252.) 39
Lähteet: Abrahamsson, P., Warsta, J., Siponen, M.T. & Ronkainen, J. 2003. New directions on agile methods: a comparative analysis [online]. Proceedings of 25th International Conference on Software Engineering ICSE 03 on 3-10 May 2003 in Portland, USA, 244-254. Saatavissa pdf-muodossa TTY:n verkon kautta <URL: http://dx.doi.org/10.1109/icse.2003.1201204>. ISBN: 0-7695-1877-X. Balci, O. ym. Animations to Assist Learning Some Key Computer Science Topics [online]. Blacksburg (VA.): Virginia Polytechnic Institute and State University. Department of Computer Science, 2001a, [viitattu 10.12.2007]. Software Engineering. The Waterfall Model. Saatavissa www-muodossa: <URL: http://courses.cs.vt.edu/~csonline/se/lessons/waterfall/index.html >. Boehm, B. 1988. The spiral model of software development and enhancement. IEEE Computer, 21 (5), 61-72. Carrol, J. M. ym. 1998. Requirements Development in Scenario-Based Design. IEEE Transactions on Software Engineering, Vol. 24 Issue 12, 1156 1170. Garret, J. J. 2003. The elements of User Experience. New York: American Institute of Graphic Arts. 40
Lähteet: Gellner, M. & Forbig, P. Extreme Evaluations Lightweight Evaluations for Soft- ware Developers [online]. Rostock: University of Rostock, 2003 [viitattu 9.12.2007]. Interact 2003 - Closing the Gaps: Software Engineering and Human-Computer Interaction in Zürich, Switzerland in 1-2 September 2003. Saatavissa pdf-muodossa <URL: http://www.sehci.org/bridging/interact/gellner.pdf >. Grönroos, C. 1990. Nyt kilpaillaan palveluilla. Suom. M. Tillman. 2. painos. Helsinki: Weilin+Göös. Kauhanen-Simanainen, A. 2001. Sisältöä verkkoon mitä sisällön tuottajan pitää hallita. Helsinki: IRH konsultointi. Keränen, V., Lamberg, N. & Penttinen, J. 2003. Digitaalinen viestintä. Porvoo: WS Bookwell. Parasuraman, A., Zeithaml, V. & Malhotra, A. 2005. E-S-QUAL A Multiple- Item Scale for Assessing Electronic Service Quality. Journal of Service Research, Vol. 7, Nro 3. February 2005, 213-233. Saatavissa myös pdfmuodossa [viitattu 9.12.2007]: <URL: http://jsr.sagepub.com/cgi/reprint/7/3/213 > 41
Lähteet: Potts, C. 1995. Using Schematic Scenarios to Understand User Needs. Proceedings of the conference on Designing Interactive Systems: processes, practices, methods & techniques: Ann Arbor, USA, elokuu 1995, 247 256. Preece, J. & al. 1994. Human-Computer Interaction. Essex: Addisson- Wesley. Rosson, M. B. & Carrol, J. M. Scenario-Based design [online]. Blacksburg VA: Virginia Polytechnic Institute and State University, 2002 [viitattu 9.12.2007]. Saatavissa pdf-muodossa: <URL: http://www.lucas.lth.se/sepm/session1/sbd-handbook.pdf >. Myös teoksessa: J. Jacko & A. Sears (Eds.). 2002. The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies and Emerging Applications. Mahwah (NJ.):Lawrence Erlbaum Associates, 2002, pp. 1032-1050. Ryder, M. Instructional Design Models [online]. Denver: University of Colorado at Denver. School of Education [päivitetty] 13.1.2005 [viitattu 9.12.2007]. Saatavissa www-muodossa: <URL: http://carbon.cudenver.edu/~mryder/itc_data/idmodels.html >. 42