Projektien kehitysmenetelmän valinnasta

Koko: px
Aloita esitys sivulta:

Download "Projektien kehitysmenetelmän valinnasta"

Transkriptio

1 Projektien kehitysmenetelmän valinnasta LuK-tutkielma TURUN YLIOPISTO Informaatioteknologian laitos Tietojenkäsittelytiede Kalle Hjerppe 2011

2 <Tiivistelmätemplate> </Tiivistelmätemplate>

3 Sisällysluettelo 1 Johdanto Ketterä ohjelmistotuotanto Yleistä Scrum Plan-driven metodit Yleistä CMMI Menetelmien vertailu Yleispätevä menetelmä Kotikentät Tasapaino Riskin mukaan tasapainottaminen Scrum ja CMMI Yhteenveto Lähteet...22

4 1 Johdanto Ketteryys kuvailee ohjelmistotuotannon metodeja, jotka perustuvat iteratiiviseen ja inkrementaaliseen kehittämiseen. Ohjelmiston iteraatio on yksi kehityssyklin ajoittainen työjakso, jossa ohjelmistoon on tuotettu lisää arvoa. Plan-driven menetelmät ovat perinteisiä suunnitteluun ja dokumentointiin perustuvia kehitysmetodeja. Ketteryys ja kurinalaisuus vaikuttavat toistensa vastakohdilta, mutta ohjelmistontuotannossa ne tukevat toisiaan. Plandriven kehittäjien on nykyaikana oltava ketterä ja ketterien kehittäjien on oltava kurinalaisia. Tutkielman tavoitteena on selvittää molempia lähtökohtia hyödyntäviä tasapainoisia kehitysmetodeja. Tällaiset kehitysmetodit vaihtelevat projektista toiseen ja niiden on otettava huomioon vallitsevat olosuhteet ja mahdolliset riskit. Tutkielmassa tutkitaan ketterien ja plandriven ohjelmistotuotantomenetelmien ominaisuuksia tarkoituksena selvittää, millaisiin projekteihin nämä soveltuvat parhaiten. Menetelmien välimuodoista tutkitaan tasapainoon pyrkiviä menetelmiä, kuten riskistrategioihin perustuvaa kehitysmenetelmää. Käytännön esimerkkeinä tutkielmassa on ketterä menetelmä Scrum ja plan-driven menetelmä Capability Maturity Model Integration (CMMI). [8] Suuri osa tutkielman lähteistä perustuu Barry Boehmin ja Richard Turnerin julkaisuihin aiheesta, tärkeimpänä on kirja "Balancing Agility and Discipline A Guide for the Perplexed". Boehm on tutkinut ohjelmistotuotannon menetelmiä yli viisikymmentä vuotta. Hän on ohjelmistotuotannon professori ja Etelä-Californian yliopiston ohjelmistotuotannon keskuksen johtaja. Turner on tutkimusta tekevä professori suunnittelun johtamisen ja systeemisuunnittelun alalla George Washingtonin yliopistossa. Hänellä on laaja kokemus ohjelmistotuotannon alalta, sekä yksityiseltä sektorilta, että valtion virasta. [8, s. 268] Sekä ketteristä, että plan-driven menetelmistä on yleisiä väärinkäsityksiä. Sanotaan, ettei ketterissä metodeissa suunnitella. Tämä ei pidä paikkaansa, vaan ketterät metodit saavat nopeutensa kehitysryhmän välisen hiljaisen tiedon käyttämisestä hyväksi dokumentaation kustannuksella. Toisaalta dokumentoitujen suunnitelmien teko suuren ajan kustannuksella ei tarkoita sitä, että niitä noudatettaisiin oikein.[8, s. 54] On väärinkäsitys, että ketteriä ja plan-driven menetelmiä ei voida yhdistää. Onnistuneita ohjelmistoja on kehitetty tasapainoisilla menetelmillä. Yksittäistä kaikki projektit kattavaa kehitysmenetelmää on mahdotonta kehittää, koska projekteilla on liian erilaiset ominaisuudet. Kehitysmenetelmien tasapainottaminen on moniulotteinen prosessi, jossa on harkittava asiaa teknologian, johtamisen ja henkilöstön kannalta. [8, s. 97]

5 2 Ketterä ohjelmistotuotanto 2.1 Yleistä Ketterä ajattelu ohjelmistotuotannossa alkoi The Agile Alliancen manifestista, joka luotiin ketterien metodien asiantuntijoiden kokoontuessa Utahissa pienimuotoiseen konferenssiin. Jo aiempina vuosina oli noussut esiin kevyitä ohjelmistotuotantometodien malleja ja keskustelua niistä. Ne olivat kasvavassa suosiossa, suurimmaksi osaksi siksi, että tällaisilla menetelmillä oli työtä vapauttavia ominaisuuksia. The Agile Manifesto veti yhteen kokoontumiseen osallistuneiden asiantuntijoiden näkemykset ketterän kehityksen perusperiaatteista; Asiantuntijat loivat seuraavan julistuksen (liite 2.1), sekä kaksitoista ketteryyden periaatetta. [1] Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. Liite 2.1 The Agile Manifesto [1] Liite 2.1. on Agile Alliancen julkaisema manifesti, jossa todetaan heidän päätyneen seuraaviin johtopäätöksiin ketteryyden arvoista. Ketterissä menetelmissä arvostetaan työntekijöitä yksilöinä ja heidän välistä interaktiotaan enemmän, kuin määrättyjä prosesseja, tai työkaluja. Yksilön tiedot ja taidot ovat tärkeitä pienryhmissä tapahtuvassa kehityksessä. Toimiva ohjelmisto on tärkeämpää, kuin työn tarkka dokumentaatio. Tällä tarkoitetaan sitä, että tarkasteltaessa työn tuloksia, suuri määrä valmista ohjelmaa on arvokkaampaa, kuin vähäinen määrä yksityiskohtaisesti dokumentoitua ohjelmaa. [1] Manifestin mukaan yhteistyötä asiakkaan kanssa arvostetaan enemmän, kuin sopimukesta neuvottelua. Tästä toivotaan seuraavan pitkä ja tuottoisa asiakassuhde. Valmius muutoksiin vaatimusmäärittelyssä on tärkeämpää, kuin suunnitelman seuraaminen. Muutosten tapahtuessa suunnitelma on vanhentunut. Manifestista voidaan myös todeta, tutkielman kannalta mielenkiintoisesta näkökulmasta, minkälaiseen projektiin ketterän kehityksen periaatteet sopivat. Agile -ajattelu syntyikin vastaiskuna vanhempia, tehottomia kehitysmalleja kohtaan. Manifesti kertoo jo paljon siitä, millaisia asioita kettterässä kehittämisessä pidetään tärkeinä tai vähemmän tärkeinä [2].

6 The Agile Manifeston kaksitoista periaatetta kiteyttävät ketteryyden pääominaisuudet: 1) Tärkein tehtävä on asiakkaan palveleminen tuottamalla arvokasta ohjelmaa aikaisin ja jatkuvasti. 2) Projektissa vastaanotetaan vaatimusmäärtittelyä koskevia muutoksia, jopa myöhäisessä vaiheessa. 3) Ohjelman iteraatioita toimitetaan usein, muutaman viikon kuukauden välein. 4) Liiketoiminnan henkilöiden ja ohjelmistokehittäjien tulee olla yhteistyössä päivittäin. 5) Projektit rakennetaan motivoitujen yksilöiden ympärille; heitä tuetaan tarvittavilla tavoilla ja osoittamalla luottamusta. 6) Henkilökohtainen keskustelu on tehokkain tiedonvälitysmedia kehittäjille ja heidän välillään. 7) Toimivan ohjelman määrä on projektin edistymisen tärkein mittari. 8) Ketterät menetelmät ovat jatkuvaa työntekoa kestäviä. Kehittäjien tulisi pystyä jatkamaan tasaista työvauhtia jatkuvasti. 9) Ketteryyttä lisää jatkuva huomio tekniseen erinomaisuuteen ja hyvään suunnitteluun. 10) Oleellista on turhan työn määrän minimointi. 11) Itseäänjohtavat ryhmät luovat parhaat arkkitehtuurit, vaatimusmäärittelyt ja suunnitelmat. 12) Ryhmä arvioi tasaisin väliajoin omaa toimintaansa ja pyrkii parantamaan sitä. [1] Ketterässä kehitystavassa painotetaan suhteita ja kommunikaatiota ohjelmistonkehittäjien keskuudessa. Esimerkiksi, sopimuksissa ihminen on tärkeämpi kuin valittava prosessi, tai kehitystyökalu. Olemassa olevissa käytännöissä tämä ilmenee tiiviinä ryhminä, läheisinä työympäristön ratkaisuina ja muina ryhmähenkeä luovina tapoina.[3] Kehittäjäryhmän tärkein tehtävä on tuottaa jatkuvasti toimivaa ja testattua ohjelmistoa. Uusia versioita julkaistaan tasaisin väliajoin, päivittäisistä julkaisuista kerran kuussa tuleviin: nopeus on metodologiakohtaista. Päämääränä on rakentaa ohjelmaa valmiimmaksi iteraatio kerrallaan. Pystyäkseen pitämään jatkuvan kehityksen nopeuden, kehittäjien tulee pitää ohjelmakoodi yksinkertaisena ja helppona, jolloin dokumentaation määrä ja tärkeys vähenee.[3] Ketterässä ajattelussa asiakkaan ja kehittäjän väliselle yhteistyölle ja suhteelle annetaan suurempi painoarvo kuin tiukoille sopimuksille. Asiakasta kunnioitetaan myös tulevaisuuden kumppanina, jolloin on edullista vaalia hyvää suhdetta. Sopimusneuvottelut on keino luoda ja ylläpitää tätä asiakas kehittäjä -suhdetta, eikä niitä kohdella voitontavoitteluna. Riskiä siitä, ettei sopimus täyttyisi vähentää se, että ketterässä kehityksessä toimitetaan arvoa iteraatioittain heti projektin alusta lähtien. Hyvin muotoillun sopimuksen tärkeys kuitenkin kasvaa sitä enemmän, mitä suurempi projekti on kyseessä.[3] On olemassa lukuisia erilaisia kehitysmetodeja, joita kuvaillaan ketteriksi. Osia useasta voidaan jopa käyttää yhtäaikaisesti samassa projektissa. Kehitysmetodeja voidaankin pitää työkaluina, joista valitaan projektiin parhaiten sopivat. On myös käytännössä yleistä, että projekteissa on käytössä kehitysryhmän itsensä räätälöimä tapa, joka koostuu monen metodin yksittäisistä tavoista. Ketteryys tarkoittaa periaatteita toiminnan perustana, ketterät metodit ovat näitä

7 periaatteita soveltavia toimintatapoja. Toimintatavat eivä vastaa täysin projektien tarpeita, ja siksi niitä on muokattava sopiviksi. [8, s.26-30] 2.2 Scrum Scrum on ketterä, iteraatioittain ohjelmistoa tuottava metodi ohjelmistonkehitykseen. Se kehystää tuotannon työjaksoihin, jotka on nimetty Sprinteiksi. Yhden iteraation pituus on enintään kuukausi, ja ne seuraavat toisiaan ilman välissä olevia taukoja. Sprinttien aikataulutuksesta käytetään termiä timeboxed, joka tarkoittaa sitä, että Sprintin aikataulu on kiinnitetty sovitun mittaiseksi. Sprintti loppuu tiettynä päivänä, oli työ valmis tai ei. Sprintin kestoa ei voi pidentää sen ollessa kesken. Tämän rajoituksen tarkoituksena on taata vakaa kehitysympäristö Sprintin ajaksi, mikä sallii kehittäjien keskittyä tietyn ajan tiettyihin ohjelmiston osiin. [4] Scrum-kehityksessä on määritetty kolme pakollista dokumentaatioartikkelia. Ensimmäinen on asiakkaan vaatimuksista pidettävä priorisoitu lista, backlog. Projektilla on yksi backlog, johon valitaan toteutettavat ominaisuudet tärkeysjärjestyksessä. Projektin backlog voi muuttua koska tahansa, mutta jo toteutettuja ominaisuuksia ei luonnollisesti poisteta. Jokaisen Sprintin alussa kehitysryhmä valitsee projektin backlogista toteutettavat ominaisuudet ja sitoutuu tekemään parhaansa niiden toteuttamiseksi Sprintin aikana. Kehitysyhmän itse arvioidessa, paljonko he kykenevät Sprintissä toteuttamaan, ja sitoutuessaan siihen, saavutetaan suurempi tuotantomäärä ja työmoraali, kuin määrättäessä tehtävä työ ryhmälle. Kokenut ryhmä kykenee luonnolliesti arvioimaan paremmin yhdessä Sprintissä toteutettavan työmäärän, eli optimaalisen tuotantonopeuden saavuttamiseen on tehtävä useita Sprinttejä kokemuksen saamiseksi. [4] Valitut ominaisuudet kirjataan toiseen pakolliseen dokumenttiin, Sprintin backlogiin, joita luodaan uusi jokaista Sprinttiä kohden. Sprintin ollessa kesken kehitysryhmä toteuttaa Sprintin backlogia tärkeysjärjestyksessä ja vaikka projektin backlog muuttuisi, Sprintin backlogia ei vaihdeta. Tämä on taas toimenpide siihen, että kehittäjät voisivat tehdä työtään häiriöittä, ilman, että heidän tarvitsisi keskittyä muuttuviin vaatimuksiin. Tilanteessa, jossa kesken olevan Sprintin jatkaminen olisi liian kallista, eli Sprintin backlog ei vastaa projektin tarpeita lainkaan, on mahdollista keskeyttää koko Sprint, aloittaa uusi ja tehdä uusi Sprintin backlog. [4] Kolmas Scrumin määrittämä dokumentaation muoto on Sprintin burndown chart. Luodessaan Sprintin backlogia kehitysryhmä arvioi kuhunkin tehtävään kuluvan ajan määrän. Tämä arvio auttaa seuraavien Sprinttien työtä valitessa, koska kehitysryhmä voi tarkemmin valita työmäärän, johon sitoutua. Burndown chart on kaavio, johon joka päivä merkitään aiemman arvioinnin perusteella, paljonko työtä Sprintissä on jäljellä. Tästä syntyy, projektin edetessä, vähenevä kuvaaja, josta kehitysryhmä näkee työn etenemisen. Tärkeää on, että kehitysryhmä näkee Sprintissä jäljellä olevan työn määrän ja voi siten säädellä toimintaansa ajan kuluessa. [4] Scrum määrittää myös kolme kehitykseen kuuluvaa roolia: Product owner, ScrumMaster ja Team. Product owner on kakkien projektiin kuuluvien osakkaiden edustaja. Hän vastaa siitä, millainen ohjelmistosta tulee ja projekti etenee hänen näkemyksensä mukaan. Product owner priorisoi ohjelmistoon tulevat ominaisuudet, ja hyväksyy tai hylkää lopulliset tuotokset. Product

8 owner omistaa projektin backlogin ja hallinnoi sitä. ScrumMaster on yksi kehitysryhmän jäsenistä, jonka tehtävänä on johtaa Scrumin toimintatapojen toteutumista ja toimia linkkinä kehitysryhmän ja ulkopuolisten välillä. Ryhmä siis on siis vakaassa kehitysympäristössä, jota ScrumMaster suojelee. Team on Scrumin termi kehitysryhmälle. Erityisvaatimuksia ryhmän kokoonpanosta ei ole, mutta se koostuu tyypillisesti viidestä yhdeksään jäsenestä, jotka johtavat toisiaan. Ryhmän sisällä tulee olla lähes kaikki projektissa tarvittava taito ja tieto. Koko kehitysryhmä on vastuussa työn tuloksesta. [4] Projektin työntekoon Scrum määrittää pidettäväksi neljä seremoniaa: päivittäisen Scrumkokouksen, sekä Sprint planning, review ja retrospective -kokoukset. Päivittäinen Scrum-kokous on lyhyt tapaaminen, jossa kehitysryhmä kokoontuu yhden kerran nopeasti käymään läpi seuraavat asiat: 1) Mitä tehtiin eilen? 2) Mitä tehdään tänään? 3) Mitä esteitä työn tekemiselle oli tai on? Päivittäiseen tapaamiseen ei kuulu tuoda muita asioita, ja jos on suurempia ongelmia, niitä koskien sovitaan toinen jatkokokous. [4] Sprint planning -kokous on kaksiosainen, yhteensä noin päivän kestoinen tapahtuma. Ensimmäisessä osassa Product owner ja kehitysryhmä keskustelevat siitä, mitä Sprintissä pitää tehdä ja millainen heidän näkemyksensä siitä on. Toisessa osassa kehitysryhmä suunnittelee keskenään, miten sovitut asiat toteutetaan. Ryhmä arvioi, kauanko kussakin tehtävässä kuluu aikaa, ja sitoutuu tämän perusteella toteuttamaan tietyn työmäärän. Sprintin backlog luodaan. [4] Sprintin jälkeen pidetään Sprint review -kokous, joka on epämuodollinen, noin kahden tunnin pituinen tapahtuma, jossa kehitysryhmä esittelee Sprintin aikana saavuttamansa tulokset. Kokous voi olla esimerkiksi demonstraatio uusista ohjelmiston ominaisuuksista, tai arkkitehtuurin tarkastelua. Sääntönä on, että kokousta ei saa valmistella kahta tuntia enempää, eikä diaesityksiä saa näyttää. Tämän perustelu on tapahtuman pitäminen epämuodollisena. Koko kehitysryhmän on osallistuttava reviewiin ja paikalle kannustetaan saapumaan kaikki projektiin osalliset henkilöt. [4] Scrumin tärkeä teema on jatkuva oman toiminnan tarkastelu ja kehittäminen. Jokaisen Sprintin lopussa järjestetään retrospective-tapaaminen, jossa käydään läpi Sprintissä hyvin, tai huonosti menneitä asioita ja sitä, miten toimintaa parannettaisiin. Retrospective on tyypillisesti nopea kokous, alle tunnin pituinen ja siihen osallistuu vähintään koko kehitysryhmä ja Product owner. Tapa toteuttaa itsearviointi voi olla jokaisen osallistujan vuorollaan kertoen seuraavaan Sprinttiin yhden asian, mitä he haluavat aloittaa, yhden asian minkä lopettaa ja yhden mitä jatkaa tehdä.[4]

9 Kuva 2.2 Scrumin malli [4] Kuva 2.2 on kaavio Scrum-projektin etenemisestä. Product Owner kuuntelee käyttäjiä, asiakkaita, kehitysryhmää ja muita projektin osakkaita. Saadun tiedon perusteella hän luo projektin backlogin. Ennen Sprinttiä projektin backlogista valitaan toteutettavat tehtävät Sprint backlogiin Spring planning -kokouksessa. Sprintin ajan kokoonnutaan päivittäin ja päivitetään burndown chart. Sprintin ja sen loppuseremonioiden jälkeen lopputuloksena pitäisi olla valmis inkrementti ohjelmistoon. "Potentially shippable" tarkoittaa sitä, että Sprintin jälkeen tehty työ ei saisi olla kesken, vaan se on valmis toimitettavaksi vaikka heti. [4] Scrumin perimmäinen ajatus on se, että ohjelmistontuotannossa on useita teknisiä ja ympäristöstä riippuvia muuttujia, kuten ohjelman vaatimukset, projektin aikataulu, käytettävissä olevat resurssit, ja teknologia. Näiden muuttujien odotetaan muuttuvan prosessin aikana, mikä tekee prosessista vaikeasti ennustettavan ja monimutkaisen. Tämän vuoksi Scrum lähestyy aihetta joustavasta näkökulmasta ja on valmiina reagoimaan muutoksiin. Tavoitteena on se, että tuotettu järjestelmä on hyödyllinen kun se toimitetaan eikä vastaa vanhoja, jo muuttuneita vaatimuksia. [3] Scrumia käyttämällä kehitysryhmä saa rauhallisen työympäristön ja voi saavuttaa nopeimman ryhmän taitoa vastaavan kestävän tuotantonopeuden. Kehitysryhmä tarkastelee omaa toimintaansa kriittisesti ja pyrkii parantamaan sitä joka Sprintissä.

10 3 Plan-driven metodit 3.1 Yleistä Perinteinen tapa tuottaa ohjemistoja on vaiheittain etenevä, vesiputousmallia seuraava kehitys. Vesiputousmalli on menetelmä, jossa kehitys jaetaan vaiheisiin, kuten vaatimusmäärittelyyn, suunnitteluun ja ohjelmointiin. Vaiheet seuraavat toisiaan tietyssä järjestyksessä edellisen valmistuessa. Nämä vaiheet on tyypilliset vaiheet ovat: 1) Vaatimusmäärittely, 2) Suunnittelu, 3) Toteuttaminen, 4) Testaus ja 5) Ylläpito.[9] Plan-driven metodeista on monia muunnelmia, kuten V-malli, mutta kaikki noudattavat samankaltaista elinkaarimallia jotenkin muokattuna. V-malli on kaksisuuntainen vesiputousmalli, joka tuo erityisesti esille jokaista kehityksen vaihetta vastaavan testausvaiheen. [10] Esimerkiksi alijärjestelmien arkkitehtuurin suunnitteluvaihetta vastaa niiden testaus ja moduulien toteutusta vastaa yksikkötestaus. V-mallissa vesiputous etenee ylhäältä alas ensin laajojen asioiden suunnittelusta yksityiskohtiin ja niiden toteutukseen. Sitten toiminta etenee alhaalta ylös testaten ja verifioiden jokaisen tason yksityiskohdista aloittaen. Prosessi voidaan vielä jakaa kolmeen näkökulmaan: käyttäjän, suunnittelijan ja toteuttajan näkökulmiin. Käyttäjää koskee ylin taso ja toteuttajaa yksityiskohdat. Suunnittelija on näiden välillä.[10] V-mallissa projekti on testivetoista, kun jokaista elinkaaren askelta vastaa testausvaihe. Tästä seuraa myös se, että testijärjestelyjä harkitaan jo aikaiseisessa projektin vaiheessa, mikä lisää projektin varmuutta ja vähentää epävarmuutta tilanteessa, jossa riskejä ei voida ottaa. [11] Tyypillisesti plan-driven prosessi alkaa yksityiskohtaisesta suunnitteluvaiheesta, jossa koko tuote käydään läpi, suunnitellaan ja dokumentoidaan tarkasti. Suunnitteluvaiheeseen vaadittu työmäärä on tiedossa ja voidaan aikatauluttaa ja organisoida helposti. Yksityiskohtaisen designdokumentin perusteella koko työ voidaan jakaa osiin, arvoida jokaisen kustantama aika- ja työmäärä ja aikatauluttaa tarkasti. Tämän jälkeen projekti voidaan kokonaisuudessaan vielä esittää hyväksyttäväksi tarkkoine kustannusarvoineen, vielä ennen kuin paljoa työtä ollaan tehty. [4] Vasta edellisten vaiheiden jälkeen itse kehitysryhmä ryhtyy työhön projektin parissa. Osa ryhmästä voi toki olla myös suunnitteluryhmässä, mutta elinkaarimallissa tämä ei suinkaan ole pakollista. Kehitysryhmässä jokaisella on omat, määrätyt roolinsa, ja työ etenee askel askeleelta esimerkiksi eri osastojen välillä. Työn valmistuttua se siirtyy testausvaiheeseen, jossa ohjelman laatu ja toimivuus tarkastetaan ennen sen toimitettamista asiakkaalle. [4] Plan-driven menetelmä on looginen ja sen kulkua on helppo seurava valmiiden milestonemerkkipaalujen valmistumisen myötä. Milestone on ennalta sovittu ohjelmiston osa tai kehitysprosessin vaihe, joiden valmistumisen myötä projektin etenemistä voidaan seurata. Milestoneilla voi olla määrätty päivämäärä, jolloin niiden tulee olla valmiina, mikä auttaa projektin aikataulussa pysymisessä ja sen seuraamisessa. Projekti pysyy hallinnassa ja luultavimmin tarkasti suunnitelmassa, koska elinkaarimallissa dokumentointi on suuressa osassa ja kaikesta on kirjoitettu oikea toimintatapa. Projektin kulku on suunniteltua ja muistuttaa muita perinteisiä tekniikan alan työprojekteja: Ensin työ ajatellaan läpi, kirjoitetaan suunnitelma. Toiseksi seurataan suunnitelmaa toteutuksessa ja yritetään pitää kaikki järjestyksessä.

11 Kolmanneksi toteutettu työ testataan ja toimitetaan asiakkaalle. [4] 3.2 CMMI 1980-luvun loppupuolella Yhdysvaltojen puolustusministeriö tilasi ehdotuksia ratkaisemaan vallitsevien ohjelmistotuotantotapojen ongelmia, kuten tehottomuutta, kalliutta ja epäonnistumisalttiutta. Ehdotuksista valittiin ja rahoitettiin Software Engineering Institute (SEI), joka teki tutkimusta luoden lopulta mallin, josta tuli Capability Maturity Model (CMM). CMM luotiin armeijan projektien prioriteettien mukaan: jos ohjelma epäonnistuisi, ihmisiä kuolisi. Myös se, että projekteja toteutettiin valtion rahoituksella vaati tietyn vastuullisuuden tason kaikilta mukana olevilta tahoilta. Projekteissa arvostettiin riskien pienuutta, standardeja ja sopimuspohjaisia ratkaisuja kehittäjän ja asiakkaan välillä. Muutaman vuoden jälkeen CMM laajennettiin moneksi samankaltaiseski metodologiaksi ja siitä tuli suosittu kansainvälisesti. Suosiossaan monista versioista alkoi olla haittaa, joten Capability Maturiy Model Integration (CMMI) luotiin, joka kokosi monien versioiden puolet yhteen menetelmään. CMMI on plandriven kehitysmalli, joka antaa ohjeet siitä, mitä kehitysorganisaation tulee tehdä ohjelmistontuotantoprosessissaan. [2] CMMI-kehittäminen on kokoelma best practice -tapoja, eli tapoja joiden on todettu olevan paras ratkaisu tietyssä tilanteessa, ja muita kehittämisen toimintoja. CMMI on koko ohjelmiston elinkaaren mukana suunnittelusta toimittamiseen. Metodologia sisältää 22 prosessialuetta, joissa toimintaa on tarkoitus parantaa ja keskittyy siihen. Ajattelumalli on, että kehitysprosessi on se, mikä pitää organisaation hallinnassa ja määrittää sen, miten liiketoimintaa tehdään. Jokaiselle prosessialueelle on määritelty tarkoitus, sekä geneeriset ja spesifiset tavoitteet. [12, s. 12] Spesifiset tavoitteet ovat prosessialuetta koskevia kriteerejä, joiden on täytyttävä, ennen kuin alue on valmis. Esimerkiksi versionhallinnan yksi spesifisistä tavoitteista on: "Baseline-versioilla on oltava hyvä ja ylläpidetty integriteetti." (Baseline-versio on toimiva ohjelmiston versio, johon tulevien käännösten muutoksia voidaan verrata). Spesifisten tavoitteiden saavuttamiseksi CMMI kuvailee toimintatapoja, joilla ne voidaan saavuttaa ja olettaa niitä käytettävän. [12, s. 13] Geneeriset tavoitteet ovat tavoitteita, jotka ovat samoja monen prosessialueen kesken. Ne kuvaavat prosessialueen ominaisuuksia, joiden on täytyttävä, että prosessit käyvät metodologiaan. Geneeriset tavoitteet ovat pakollisia täyttää, jotta prosessialuetta kohdeltaisiin valmiina. Esimerkki geneerisestä tavoitteesta on: "Prosessi on vakiinnutettu määriteltynä prosessina." Geneeristen tavoitteiden saavuttamiseksi CMMI määrittelee geneerisiä toimintatapoja. Sama toimintatapa voi olla käytössä useassa prosessialueessa ja ne ovat luonteeltaan yleisiä. Määritellyt toimintatavat ovat sellaisia, joita pidetään tärkeinä geneeristen tavoitteiden täyttymiseksi. Organisaatio vertaa omia prosessejaan CMMIn prosessialueisiin varmistaakseen menetelmän toiminnan.[12, s. 13] Yllä mainitut CMMIn komponentit muodostavat tasoja. Tasot ovat evolutiivinen tapa kehittää organisaation kehitysprosesseja ja palveluita. Organisaation prosessien ollessa tietyllä tasolla se käy todisteesta siitä, että organisaatio on järjestäytynyt ja voi auttaa esimerkiksi liikekumppanuuksien luomisessa. Tietyn tason saavuttamiseksi organisaation on täytettävä kaikki

12 sitä tasoa vastaavat tavoitteet kehitettävällä prosessialueella. Kypsyystasoja on viisi ja niiden saavuttamisen kriteerit tiukkenevat ja muuttuvat käytännön ongelmien ratkaisusta aktiiviseen kehittymiseen. [12, s.23-26] Ensimmäinen taso kuvaa organisoimatonta toimintaa. Kehitys on kaaottista ja epävakaata. Toinen kypsyystaso on johdettua kehitystä: jotain kehitysprosessia noudatetaan ja työ on hallinnassa. Kolmas taso on hyvin määritellyt prosessit. Organisaatio käyttää tiettyjä prosesseja ja työkaluja tasaisesti kaikkien projektien kesken. Yksittäisen projektin prosessit on räätälöity organisaation omista menetelmistä sopiviksi. Neljäs kypsyystaso tarkoittaa sitä, että organisaatiolla on lukumääräisiä mittareita laadun ja prosessien mittaamiseen. Viidennen tason organisaatio kehittää prosessejaan jatkuvasti tavoitteidensa mittarien mukaisesti. Neljännen ja viidennen tason suurin ero on keskittyminen johtamiseen ja organisaation ylätasojen optimointiin. [12, s ] 4 Menetelmien vertailu Ketterät menetelmät lupaavat asiakastyytyväisyyttä, vähemmän virheitä, nopeampaa tuotantoa ja mahdollistuutta usein muuttuviin vaatimuksiin. Plan-driven menetelmät lupaavat ennustettavuutta ja vakautta. Molemmilla on hyvät puolensa, mutta myös huonot puolensa, jotka voivat johtaa projektien epäonnistumiseen huomioimatta jäädessään. Tämä heijastuu siihen, millaiseeen projektiin kumpikin lähestymistapa sopii. Haasteellisinta on tasapainotella tilanteessa, jossa projektin ominaisuudet eivät ole äärimmäisiä. Silloin paras ratkaisu olisi käyttää molempien lähestymistapojen sopivia osia. Projekti voi käyttää sekä ketteriä, että plandriven menetelmiä suhteessa sen tarpeisiin. [5] Boehm ja Turner esittävät kuusi toteamusta ketterien ja perinteisten menetelmien tasapainottamisesta: 1) Kummastakaan lähtökohdasta ei voida saada kaikenkattavaa ratkaisua. 2) Molemmilla menetelmillä on oma kotikenttänsä, jossa se on selvästi toista vahvempi tapa. 3) Tulevaisuuden ohjelmistonkehitysarviot ennustavat sellaisten sovelluksien, joiden kehittämisessä tarvitaan sekä ketteriä, että perinteisiä toimintatapoja, nousua. 4) Joitain tasapainoisia kehitysmenetelmiä on kehitteillä. 5) On toimivampaa rakentaa kehitysmenetelmänsä alhaalta ylös, kuin karsia kaikenkattavasta metodologiasta itselleen sopivaa. 6) Kehitysmenetelmät ovat tärkeitä, mutta todelliset ratkaisut voivat olla ihmissuhteissa, kommunikaatiossa ja odotusten hallinnasssa. [5]

13 4.1 Yleispätevä menetelmä Frederik Brooks on tutkinut kaikenkattavaa yksittäistä ratkaisua ohjelmistontuotantoon. Hän on päätynyt lopputulokseen, ettei yleispätevää menetelmää voida kehittää, koska ohjelmistojen ominainen vaikeus tekee kehittämisestä aina monimutkaista. Ohjelmiston sisimmäinen olemus on rakennelma limittäisiä abstrakteja käsitteitä, kuten tietorakenteita, alkioiden välisiä suhteita tai algoritmeja. Vaikea osa ohjelmistokehittämisessä on tehdä tämän abstraktin konseptin mukaan vaatimukset, suunnitelu ja testaaminen. Vaikeaa ei ole olemusta vastaavan esityksen tekeminen ja sen toimivuuden testaaminen; kaikki tekevät syntaksivirheitä, mutta ne eivät ole merkittäviä verrattuna käsitteellisiin ohjelmien ongelmiin. Tämän pitäessä paikkansa, ohjelmistotuotanto tulee aina olemaan vaikeaa, eikä yleispätevää tuotantomenetelmää ole. Ohjelmistoilla on neljä luontaista vaikeaa ominaisuutta: kompleksisuus, mukautuminen, muttuvuus ja näkymättömyys. [6] Ohjelmistot ovat monimutkasimpien ihmisen luomien rakennelmien joukossa, sillä yksikään osa ei ole samanlainen kuin toinen, ainakaan lausetasoa ylempänä. Jos ne ovat, ne yhdistetään samaksi rutiiniksi. Tässä suhteessä ohjelmat ovat varsin erilaisia verrattuna tietokoneisiin, rakennuksiin tai ajoneuvoihin, joissa kaikissa on paljon toistuvia elementtejä. Tietokoneet ovat sinällään todella kompleksisia, koska niillä on todella monta erilaista tilaa. Tästä johtuen niiden luominen, kuvaileminen ja testaaminen on vaikeaa. Ohjelmistoilla on vielä monta kertaa enemmän erilaisia tiloja kuin tietokoneilla. [6] Toinen monimutkaisuutta lisäävä seikka on se, että ohjelmiston on mukauduttava kaikkiin sitä ympäröiviin rajapintoihin. Ei voida löytää luonnonlakeja ohjelmistoille, joiden mukaan asiat toimivat: suuri osa kompleksisuudesta on väkinäistä mukautumista ympäristöön. Usein ohjelmiston on mukauduttava, koska se luotiin viimeksi. Toisin siksi, että sen on helpointa mukautua muihin. Kuitenkaan erilaisiin rajapintoihin mukautumisesta syntyvään vaikeuteen ei voi vaikuttaa ohjelmistotuotannon menetelmillä, vaan se on luontaista. [6] Ohjelmistoilla on jatkuvasti paine muuttua. Muutoksia tulee toimittamisen jälkeenkin. Osittain tämä muutosherkkyys johtuu siitä, että ohjelmistoa voi muutta helposti; se on vain informaatiota, eikä materiaa. Onnistuneelle ohjelmistolle löydetään uusia käyttötarpeita myöhemmässä vaiheessa sen elinkaarta, ja näihin vastataan muutoksilla. Ohjelmistot myös kestävät kauemmin kuin niiden käyttöalustat. Uusien tietokoneiden, tallennusmuotojen tai muiden laitteiden vaihtuessa käyttöön ohjelmiston on muututtava ottamaan ne mukaan. [6] Viimeinen ohjelmistontuotannon luontainen vaikeus on ohjelmiston näkymättömyys. Ohjelma on näkymätön, eikä sitä voi visualisoida. Arkkitehti voi piirtää talon piirrustukset, joka havainnollistaa vahavasti sitä, millainen talosta tulee. Ohjelmiston suunnitelmadokumenteista ei näy ohjelmiston toimintaa silmäyksellä. Tämä haittaa ei vain ohjelmiston suunnittelua, vaan myös kommunikaatiota ihmisten välillä ohjelmiston toimintaa koskien. [6] Tässä luvussa tarkasteltiin, miten vaikeaa ohjelmistoa on kehittää. Vaikka ei ole olemassa yksittäistä ratkaisua, joka vastaisi kaikista edellisistä vaikeuksista koostuvaan onglemaan, eri ohjelmistontuotantomenetelmissä on ratkaisuja yksittäisiin vaikeuksiin. Ketterissä menetelmissä pyritään vähentämään muuttuvuuden ja näkymättömyyden tuomia esteitä luomalla yhteisen näkemyksen kehitysryhmän sisällä siitä, millainen ohjelmiston tulee olla. Monesti ketterät

14 menetelmät kariutuvat monimutkaisuuteen ja mukautuvuuteen: ne eivät toimi yhtä hyvin suurissa projekteissa monimutkaisuuden kasvaessa, eivätkä ole yhtä järjestäytyneitä kuin standardeja noudattavat prosessit. [6] Plan-driven menetelmissä ratkaisuna mukautuvuuteen ja näkymättömyyteen on panostaminen yksityiskohtaiseen dokumentointiin. Toisaalta tämä johtaa menetelmien heikkouteen muuttuvuutta vastaan. Dokumentointi, systems of systems -ratkaisut ja organisaation integrointi prosessiin lisäävät menetelmien monimutkaisuutta. Systems of systems on kokoelma tehtäväkohtaisia tai muuten omistautuneita menetelmiä, joita yhdessä käyttämällä pyritään hallitsemaan kokonaistilannetta, luoden yhden todella monimutkaisen, metodien summan.[5] 4.2 Kotikentät Molemmilla kehitysmenetelmillä on oma kotikenttänsä, vaikka harvan projektin ominaisuudet sopivat täysin kumpaankaan. Menetelmän kotikenttä kuvaa sellista projektia, jonka ominaisuudet sopivat täysin kyseisen metodin käyttöön. Kehitysmenetelmän sopivuudella projektin ominaisuuksiin kotikenttien välillä on vaikutus projektin onnistumismahdollisuuksiin. Mitä enemmän projektin tilanne eroaa käytetyn menetelmän kotikentästä, sitä suurempi on projektin epäonnistumisen riski. [7, s.58] Projekteista voidaan ottaa esille useita ominaisuuksia, mutta pääteemat ovat ohjelmiston vaatimukset, projektinhallinta, tekniset ominaisuudet ja projektin henkilöstö [5]. Kehitettävän ohjelmiston vaatimukset ovat tärkeimmässä osassa valittaessa käytettävää kehitysmenetelmää. Ketterässä metodissa ohjelmiston tavoitteena on saada arvoa nopeasti ja olla avoimina muutoksille. Plan-driven metodissa tavoitteena on ennustettavuus ja vakaus. Laajan ohjelmiston, jonka kehittäminen vaatii montaakymmentä ihmistä, kehittämiseen soveltuu parhaiten plan-driven metodit. Pieniin projekteihin taas kuuluvat ketterät metodit. Se, millaiseen ympäristöön ohjelmistoa kehitetään vaikuttaa metodien toimivuuteen. Rauhattomille ja nopeasti muuttuville markkinoille tuotettava ohjelmisto, joka keskittyy yksittäiseen projektiin, on ketterille metodeille edullinen. [5] Projektinhallinnan ominaisuudet vaikuttavat projektin sijaintiin ketterä plan-driven -skaalassa. Kehittäjän suhde asiakkaaseen on yksi näistä ominaisuuksista. Ketteryys vaatii paljon sitoutumista asiakkaalta: omistautuneet, kehityspaikalla olevat asiakkaat ovat ketterään metodiin sopivia. Plan-driven metodissa asiakkaan välistä kanssakäymistä ei tarvita yhtä paljon kuin ketterässä. Asiakas on keskittynyt sopimusehtoihin, kun taas ketterässä asiakas arvostaa priorisointinsa mukaan tapahtuvaa inkrementaalista arvonlisäystä.[5] Projektin teknisistä ominaisuuksista voidaan määrittää alueita, joilla menetelmät ovat toistaan parempia. Projektin vaatimusten ollessa prioritisoidussa järjestyksessä olevia ei-formaaleja tarinoita ja testitapauksia, tai niiden muuttuessa ennakoimattomasti, ketterät metodit ovat parhaiten onnistuvia. Plan-driven metodin parhaan tilanteen näkökulmasta vaatimusten evoluutio on ennustettavissa ja ne ovat virallisesti määriteltyjä. Itse ohjelmiston kehitys on ketterässä kotikentässä yksinkertaista suunnittelua, jota toteutetaan lyhyillä inkrementaatioilla. Refaktoroinnin oletetaan olevat halpaa. Plan-driven metodeissa suunnittelu on laajamittaista ja inkrementit ovat pidempikestoisia. Refaktorointi oletetaan kalliiksi, ja viimeiseen ratkaisuun

15 pyritään ensimmäisellä kerralla. Ohjelmistoa testataan plan-driven metodissa dokumentoitujen testisuunnitelmien ja proseduurien mukaan. Ketterässä metodissa toteutetaan testitapauksia, jotka siten määräävät testauksen kulun.[5] Kotikenttien näkökulmasta on myös tarkasteltava projektin käytössä olevien työntekijöiden ja muiden siihen osallistuvien ihmisten, kuten asiakkaan, ominaisuuksia. Kehitysryhmän kokoonpano voi muuttua projektin aikana. Plan-driven metodi vaatii projektin alussa, sen tärkeimmässä vaiheessa, erittäin osaavan kehitysryhmän joka hallitsee käytettävän prosessin. Myöhemmin prosessin edetessä kehityksessä voidaan toisaalta käyttää vähemmän taitavia henkilöitä, jotka vain tekevät mekaanista työtä. Toisaalta kettärässä kehitysryhmässä kaikkien jäsenten oletetaan olevan cross-functional osaajia, jotka taitavat käytettävän kehitysmetodin. Osaamisen tarve säilyy koko projektin ajan, ja käytettävää menetelmää tuntematonta henkilöä on haasteellista käyttää. [5] 4.3 Tasapaino Kaikki projektit eivät sovi puhtaasti kumpaankaan ohjelmistonkehitysmenetelmään, ketterään tai plan-driveniin. On mahdollista käyttää yhdistelmää ketteristä ja plan-driven menetelmistä saaden paremmat mahdollisuudet projektin onnistumiseen, kuin käyttämällä huonosti projektiin sopivaa menetelmää. Ketterät kehittäjät voivat skaalata projektiaan suuremmaksi ottamalla käyttöön plan-driven menetelmiä tukemaan aiempia tapoja. Plan-driven menetelmiin tottuneet kehittäjät voivat tehdä raskaammista osista kehitystään kevyempiä ketterillä menetelmillä. [8, s.83] On todettava, että ketterien ja plan-driven menetelmien tasapainottaminen ei ole yksinkertainen työ. Joka projektilla on omat ominaisuutensa, johon on räätälöitävä oikeanlainen ratkaisu. Kehitysmenetelmien sekoittaminen ja niiden rajojen ulkopuolella toimiva käyttö vaatii myös kokeneen henkilön, jollaon syvällistä tietoa kaikista projektissa käytettävistä menetelmistä. Epäonnistuminen menetelmien sekoittamisessa voi johtaa koko projektin sekaisin menemiseen ja lopulta kaatumiseen, tai vähintään tehottomaan toiminttaan. [8, s. 97] Ketterän metodin laajemmaksi skaalaamisessa ilman plan-driven menetelmiä kohdataan kolme ongelmaa. Ketterissä kehitysryhmissä iso osa tiedosta on hiljaista ryhmän yksilöiden tietämystä ja sitä ei ole suoranaisesti dokumentoitu. Ohjelmistoa kehitettäessa dokumentointi pysyy kevyenä, eikä tieto ole kaikkien saatavilla. Skaalattaessa ketterää kehitystä laajaan projektiin, tämän tiedon määrä kasvaa liian suureksi muistettavaksi ilman dokumentointia. Ongelma korostuu moninkertaiseksi, jos kehitysryhmän henkilöstö vaihtuu kesken projektin. [8, s ] Toinen ongelma ketterien menetelmien käytössä laajoissa projekteissa on laajuuden luoma tarve saada entistä kokeneempia kehitysryhmän jäseniä. Henkilön on hallittava käytettävä ketterä metodi hyvin, jotta hän osaa poiketa sen rutiineista oikein. Poikkeuksia on tehtävä kohdissa, joissa projektin laajuus estää normaalin ketterän tavan toiminnan, tai tekee siitä vähemmän tehokasta. [8, s ] Kolmas ongelma ilmenee projektin ollessa laaja ja sellainen, jonka muutokset ovat ennustettavissa. Ketteät menetelmät suosivat ohjelmakoodin ja arkkitehtuurin pitämistä mahdollisimman yksinkertaisena; ylimääräisiä asioita ei ohjelmoida varmuuden vuoksi. Joissakin tilanteissa on selvää, että tietynlaisia objekteja tullaan tarvitsemaan monenlaisia, mutta

16 ketterissä metodeissa näitä ei ohjelmoida kuin tarpeen mukaan, vaikka yleisemmän ratkaisun tekeminen olisi helpompaa tulevaisuuden kannalta. Tämä johtaa koodin jatkuvaan refaktorointiin, eli uudelleen kirjoittamiseen, aina uutta sen tyyppistä objektia tarvittaessa. [8, s.88] Ratkaisu näihin ongelmiin on ottaa kehitykseen mukaan joitain plan-driven metodeja helpottamaan keihtyksen laajemmaksi skaalaamista. Hiljaisen tietämyksen taakan jakamiseen voidaan ottaa käyttöön korkean tason arkkitehtuureja, jotka antavat kehittäjille kokonaiskuvan kehitettävästä ohjelmistosta helposti. Toista ongelmaa vastaan voidaan määritellä milestoneja tarkemmin, jotta ohjelmiston osia ei pidetä valmiina niiden ollessa kesken. Kolmatta ongelmaa, yksinkertaisten kehitystapojen haittoja, voidaan helpottaa käyttämällä valmiita suunnittelumalleja ja arkkitehtuurisia ratkaisuja. Tämä onnistuu luonnollisesti ainoastaan ohjelmiston kohdissa, joissa muutokset ovat ennustettavissa. [8, s.89-90] Plan-driven menetelmien virtaviivaistaminen ketterillä tavoilla on ketterien arvojen tuomista hitaan, suunnitellun toiminnan mukaan. Ensimmäinen seikka on ottaa ketteryyden inhimilliset arvot, "Individuals and Interactions over Processes and Tools ", huomioon projektia suunnitellessa. Tyypillisessä plan-driven menetelmässä ihmiset mukautuvat käytettävien prosessien vaatimiin rajoituksiin ja tapoihin. Tämä arvosuhde voidaan vaihtaa toisin päin ja mukauttaa käytettävissä olevat työkalut ja prosessit projektin henkilöstön tarpeisiin. Esimerkiksi tietyt standardit voidaan huomioida, mutta niiden mutta niiden milestonet voidaan mukauttaa käytännöllisiksi. [8, s. 92] Kuva Metodinvalinnan ulottuvuudet [5] Boehm ja Turner ovat määrittäneet viisi akselia, joiden muuttujia tarkastelemalla voidaan tehdä valinta kehitysmenetelmästä. Nämä ovat graafisessa muodossa kuvassa Akselit ovat projektin kriittisyys, koko, työkulttuuri, muutokset ja henkilöstö. Tähdenmuotoinen graafi auttaa hahmottamaan erilaisten projektien suuntauksia nopealla tarkastelulla. Arvioimalla projektia jokaisen akselin suhteen voidaan visuaalisesti kuvata sen suhdetta äärimmäisiin

17 kehitysmenetelmiin. Pieni tähti, jossa projektia vastaavat kunkin akselin arvot ovat sisemmässä osassa graafia, tarkoittaa sitä, että projekti sopii ketterille kehitysmenetelmille täysin. Akselien ulkoreunoilla olevat arvot ovat taas täysin plan-driven menetelmiä vastaavia. Useimmiten käytännön projekteissa nämä arvot eivät vastaa kumpaakaan ääripäätä ja tällöin tarvitaan tasapainoisia menetelmiä. [5] Kriittisyysakseli kuvaa projektin epäonnistumisen seurauksia. Mitä kriittisempi projekti on, sitä vähemmän siinä voidaan tehdä riskejä. Akselin ääripäät ovat epäonnistumisesta seuraava mielipaha ja ihmishenkien menetys. Projektin koko on akseli kolmesta kolmeen sataan ja kuvaa kehitysryhmän henkilömäärää. Ketterät menetelmät suosivat pieniä kehitysryhmiä ja pienen riskin projekteja. Plan-driven menetelmissä epäonnistumisen riski pienenee ja henkilöstön määrällä ei ole vaikutusta. [5] Organisaation työkulttuuri -akseli on abstrakti arvio siitä, kuinka järjestäytynyttä kehitysympäristön kulttuuri on. Plan-driven menetelmät toimivat huonommin ilman kurinalaista organisaatiorakennetta kun taas ketterät kehitysryhmät ovat itseorganisoivia. Projektin muutoksia kuvaava akseli on arvio siitä, kuinka todennäköisesti projektin vaatimukset vaihtuvat kuukauden aikana. On mainittava, että ketterille menetelmille sopii sekä paljon, että vähän muuttuvat vaatimukset, kun taas plan-driven menetelmillä on vaikeuksia reagoida muutoksiin. Projektin henkilöstön akseli kuvaa käytettävät menetelmät taitavien henkilöiden osuutta kehitysryhmässä. Plan-driven menetelmille sopii se, että suuri osa ryhmästä ei ole erityisen kokeneita, se riittää, että mukana on muutama taitava henkilö. Ketterät menetelmät vaativat enemmän metodin tuntevia henkilöitä ja on sitä parempi, mitä vähemmän kokemattomia tekijöitä on. [5] Tilanteessa, jossa projektin ominaisuudet eivät ole yhtenäisesti akselien ääripäiden lähettyvillä, vaan tukevat yhdessä ketterää ja toisessa plan-driven menetelmää, tarvitaan tasapainoisia kehitysmenetelmiä. Ketteriä metodeja voidaan käyttää hyödyksi muuten plan-driven menetelmissä aiemmin mainitulla tavalla, ja plan-driven metodeja ketterissä projekteissa. Seuraavassa luvussa tutkitaan tapaa tehdä projektille räätälöity hybridimenetelmä, joka käyttää molempien lähtökohtien parhaita puolia Riskin mukaan tasapainottaminen Riskin mukaan tasapainottaminen on Boehmin ja Turnerin esittämä käytännön metodi, jossa riskien analyysillä ja yhtenäisellä projektin viitekehyksellä voidaan valita sopivin ohjelmistonkehitysstrategia. Metodissa määritetään ja otetaan huomioon erityisesti ketterään ja plan-driven kehittämiseen yleisesti liittyviä riskejä käyttäen riskianalyysiä. Tämän prosessin tarkoituksena on auttaa organisaatioita ja projekteja käyttämään hyväksi sekä ketterien, että plandriven menetelmien parhaita puolia ja minimoimaan niiden huonommin sopivia ominaisuuksia. Metodi koostuu viidestä vaiheesta: 1) Riskianalyysi, 2) Riskien vertailu, 3) Arkkitehtuurin analyysi, 4) Projektin mukauttaminen, 5) Toteutus ja valvonta. [7] Ensimmäiseksi tehdään riskianalyysi menetelmien tiedettyihin riskialueisiin. Sen tarvitsee myös vastata kysymyksiin siitä, miten tasapainotellaan sen välillä, että tekee tarpeeksi jotain verrattuna liian paljon tekemiseen. Esimerkiksi kysymyksiin, kuten "Paljonko testausta on tarpeeksi?" tai "Kuinka paljon suunnittelua ja arkkitehtuuria on tarpeeksi?" on vaikea vastata, mutta se on

18 tehtävä menetelmän valitsemiseksi. [8, s.100] Riskianalyysissä arvioidaan projektin ympäristöä, ketteryyttä ja plan-driven memetelmiä koskevat riskit. Mikäli näistä ei päästä varmuuteen, voidaan lisää informaatiota ostaa tekemällä prototyyppejä, keräämällä käyttäjädataa ja -analyysillä. Vaikka riskianalyysi ei ole helppo tehtävä, se luo perustan päätöksenteolle kehityksen strategiasta myöhemmin prosessissa. Mainituista kolmesta riskikategoriasta tarkastellaan etukäteen valittuja kandidaattiriskejä. Riskianalyysiä tehdessä on huomioitava, että kandidaattiriskit ovat vain yleisiä riskejä huomioitavaksi. Aina ne eivät sovi projektin tilanteeseen, ja aina ne eivät ole riittäviä tarkasteltavaksi. Riskianalyysi riippuukin paljon kyseessä olevasta projektista, eikä siihen voida antaa täysin valmista vastausta. [8, s.103] Seuraavassa luettelossa on kunkin kategorian kandidaattiriskit: Projektin ympäristöä koskevat riskit: Teknologiassa on epävarmuuksia. Projektilla on monta erilaista osakasta, joita on koordinoitava. Projekti koskee monimutkaisia systems of systems -ohjelmistoja Ketteryyteen liittyvät riskit: Projekti on kriittinen, eikä siinä saa olla virheitä. Projekti on erittäin laajamittainen. Ketterän kehityksen yksinkertaisesta suunnittelusta seuraavat ongelmat, kuten tarve tehdä ohjelmiston osien suunnittelua etukäteen Ketterä kehitys on riippuvainen kehitysryhmän sisäisestä tiedosta, eli jos projektin henkilöstö on erittäin vaihtuvaa, tämä voi olla ongelma. Kehitysryhmässä ei ole tarpeeksi ihmisiä, jotka ovat taitavia ketterissä menetelmissä. Plan-driven menetelmien riskit: Projektin vaatimukset ovat jatkuvasti muutoksen alaisina. Projektilla on tarve saada aikaan nopeita tuloksia. Ohjelmistosta voi nousta uusia vaatimuksia, kun käyttäjät pääsevät tutustumaan sen käyttöön. Kehitysryhmässä ei ole tarpeeksi ihmisiä, jotka ovat taitavia plan-driven menetelmissä. [8, s ] Riskien kartoittamisen jälkeen on analysoitava niiden tulokset. Prosessin vaihe kaksi on kolmisuuntainen valintatilanne, josta päätetään, tehdäänkö projekti ketterien, plan-driven, vai tasapainoisen menetelmän mukaan. Mikäli kaikki projektin riskit viittaavat siihen, että projekti sopii täysin ketterällä tai plan-driven metodilla tehtäväksi, on strategiaksi helppo valita kyseinen menetelmä. Mikäli projekti on tämänlainen, prosessin kolmas vaihe jätetään välistä ja jatketaan suoraan neljänteen vaiheeseen. Tilanteessa, jossa projektissa todetaan riskejä molemmissa menetelmissä, on parasta käyttää tasapainoitettua strategiaa. [8, s.103]

19 Vaihe kolme on siis projektille, jota ei voi luokitella kumpaankaan menetelmään täysin, tai sillä on vakavia riskejä eri alueilta. Mikäli on mahdollista, kehitetään ohjelmiston arkkitehtuuri, jota voidaan kehittää ketterien menetelmien avulla niillä osa-alueilla, joilla niiden vahvuuksia voidaan hyödyntää, mutta samalla minimoiden niihin liittyvät riskit. Plan-driven menetelmiä käytetään jäljelle jäävään työhön ja niitä kohdellaan oletusmenetelminä alueilla, joille ei voida luoda sopivaa arkkitehtuuria. Mikäli tässä vaiheessa nousee esiin uusi riski, jota ei riskianalyysissä huomioitu, prosessissa voidaan palata askeleita taaksepäin tarpeen mukaan. [8, s.104] Ennen arkkitehtuurin luomista, koska suunnitteleminen maksaa, on vastattava kysymykseen: "Kuinka paljon suunnittelua on tarpeeksi?" Käytännössä on arvioitava kahta riskiä vastakkain. Tarkastellaan onko liian vähäisen suunnittelun seuraus pahempi menetys, kuin suunnitteluun käytetyn ajan ja rahan tuoma markkinaikkunan pieneneminen. Liian vähästä suunnittelusta seuraa jo valmiin työn uudelleen tekemistä. Projekteissa, joissa aikataulu on tiukka, ei ole varaa tehdä työtä moneen kertaan. Kriittisessä projektissa, jossa epäonnistumisella on vaaralliset seuraukset, arkkitehtuurin virheillä on seurauksia. Yleisesti ketterät riskit tukevat enemmän suunnittelua ja plan-driven riskit päinvastoin. Toisaalta suunnitteluun käytetystä ajasta johtuva riski nousee siitä, jos arkkitehtuurin pitää olla todella ykstyiskohtaisia, koska muutosten sisällyttäminen siihen on vaikeaa. [8, s ] Vaihe neljä on projektin mukauttaminen todettuihin riskeihin ja valittuun menetelmään. Tasapainoisessa strategiassa projektin runko voi noudattaa jotain plan-driven metodologiaa, jos sen heikkouksiin vastataan ketterillä menetelmillä. Tärkeintä on tehdä riskienhallintastrategia, joka ottaa huomioon prosessin alussa todetut riskit. Jokainen riski on huomioitava, mutta niille tehtävän hallintastrategian ei välttämättä ole pakko olla monimutkainen. Tämän vaiheen yksityiskohdat ovat pääosin riippuvaisia kehitysorganisaation resursseista ja johtajien kokemuksesta. Esimerkiksi projekti, jonka vaatimukset muuttuvat paljon, voi rakentaa plandriven ohjelmistorungon arkkitehtuurin muutoksia sietäväksi ja tuottaa siihen sisälletyt moduulit ketterillä ryhmillä. Riskienhallintastrategiat voivat myös olla ihmisten välisiä pehmeitä ratkaisuja. Riskiä siitä, että projektin tärkeimpiä ihmisiä lähtee pois kesken työn ja jättää projektin pulaan, voidaan vähentää esimerkiksi tarjoamalla bonuksia projektin valmistumisesta. [8, s ] Viimeinen vaihe prosessissa on käytännön toteutus ja sen valvonta. Prosessi soveltaa ketterää tapaa tarkastella kriittisesti omaa toimintaa ja pyrkiä parantamaan sitä mahdollisimman usein. Koska yksikään arviointi tai päätös ei ole hyvä joka tilanteessa, projektista vastaavien tarvitsee koko elinkaaren ajan valvoa ja arvioida edellä tehtyjen ratkaisujen toimivuutta. Mikäli ongelmia havaitaan, voi olla pakko palata taaksepäin ja suunnitella uudelleen niitä aiheuttava kohta. Tärkeää on se, että muutokset, jos niitä on tehtävä, toteutetaan mahdollisimman nopeasti, jolloin niistä seuraava haittakin on pienempi. [8, s ] Toiminnan tarkastelusta voi myös seurata positiivisia asioita. Valvomalla ohjelmiston kehittymistä saattaa huomata uusia mahdollisuuksia tuottaa enemmän arvoa asiakkaalle, tehdä toiminnasta tehokkaampaa ja nopeampaa, tai muita tapoja parantaa organisaation toimintaa. [8, s ]

20 4.3.2 Scrum ja CMMI Scrum ja CMMI ovat todella erilaisia menetelmiä, mutta ne voivat silti sopia samaan projektiin yhdessä ja olla synergisiä. Projektissa, jossa plan-driven menetelmään sopivaa runkoa halutaan virtaviivaistaa ketterillä metodeilla, Scrum ja CMMI voivat toimia. On fakta, että CMMI määrittää prosessialueet todella yksityiskohtaisesti ilman paljoa tulkinnanvaraa. [2] Paras tapa käyttää CMMItä on kohdella sitä prosessien mallina, eikä suoranaisena kehitysmenetelmänä. CMMI ei määrittele miten prosessin toiminta tehdään, vaan se kertoo, mitä organisaation on tehtävä projektin toimimiseksi. Projekti voisi hyvinkin käyttää Scrumia lähes kokonaisuudessaan CMMIn ohella. Scrum määrittelee muutaman toimintatavan ja henkilöstön roolit, sekä tiettyjen dokumenttien käytön. Näitä ei estetä CMMIn määrityksissä lainkaan. [2] CMMI voidaankin nähdä kokoelmana mallitoimintatapoina, enemmän teoreettisena mallina, joka on tehty tutkimuksen perusteella. Näin CMMI on konsepti, josta opitaan ja jota sovelletaan oikeisiin käytännön tilanteisiin. Tämä ajatus näkyy myös tavassa, jolla CMMIn prosessit ovat kirjoitettu. Ne ovat abstraktimmalla tasolla, kuin tavallinen toimintatavan kuvaus. Toisaalta ketteristä menetelmistä, kuten myös Scrumista, puuttuu korkean tason määrittelyjä. [2] Käytännössä siis Scrumin ja CMMIn yhdistelmämenetelmä on ketterää Scrum kehitystä, jossa käytetään jonkin verran aikaa ja resursseja CMMIn vaatimusten toteuttamiseen. Mikäli tavoitteena on saada korkeampia kypsyystasoja, on käytettävä paljonkin huomiota organisaation toiminnan kehittämiseen. Plan-driven vaikutteista saadaan ryhtiä ja paremmin ketteriä riskejä kestävää toimintaa. Myös monet CMMItä käyttävät organisaatiot ovat nykyään ottaneet ketteriä kehitysryhmiä tekemään käytännön työtä. [2]

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

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

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

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

Software product lines

Software product lines Thomas Gustafsson, Henrik Heikkilä Software product lines Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Asiantuntijateksti 17.11.2013 Sisällys 1 Johdanto 1 2 Software product

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

Onnistunut ohjelmistoprojekti

Onnistunut ohjelmistoprojekti Onnistunut ohjelmistoprojekti 2.12.2008 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt ja työkalut Tulevaisuuden

Lisätiedot

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä

Arkkitehtuuritietoisku. eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Arkkitehtuuritietoisku eli mitä aina olet halunnut tietää arkkitehtuureista, muttet ole uskaltanut kysyä Esikysymys Kuinka moni aikoo suunnitella projektityönsä arkkitehtuurin? Onko tämä arkkitehtuuria?

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

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

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

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

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

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

Ohjelmiston toteutussuunnitelma

Ohjelmiston toteutussuunnitelma Ohjelmiston toteutussuunnitelma Ryhmän nimi: Tekijä: Toimeksiantaja: Toimeksiantajan edustaja: Muutospäivämäärä: Versio: Katselmoitu (pvm.): 1 1 Johdanto Tämä luku antaa yleiskuvan koko suunnitteludokumentista,

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

SOVELLUSALUEEN KUVAUS

SOVELLUSALUEEN KUVAUS Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu SOVELLUSALUEEN KUVAUS LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 2.1 Tila: hyväksytty Päivämäärä: 12.12.2000

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

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista) 9.10.2013

Tietohallinnon nykytilan analyysi. Analyysimenetelmä (sovitettu Tietohallintomallista) 9.10.2013 Tietohallinnon nykytilan analyysi Analyysimenetelmä (sovitettu Tietomallista) 9.10.2013 Haastattelurunko Kerättävät perustiedot Budjetti (edellisvuoden) Henkilöstökustannukset IT-ostot Muut Liite - Kypsyysanalyysin

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

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

Johdatus ohjelmistotuotantoon

Johdatus ohjelmistotuotantoon Johdatus ohjelmistotuotantoon Luento nro 3, 9.9.2013 Kari Systä (materiaali osin Ilkka Haikalalta ja Marko Leppäseltä) 9.9.2013 JOTU/K.Systä 1 Tiedotettavaa Viikkoharjoitusryhmiä on vähennetty yhdellä

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

10 v. työkokemus teknologiaprojekteista, tiiminvedosta ja agile menetelmistä.

10 v. työkokemus teknologiaprojekteista, tiiminvedosta ja agile menetelmistä. 1 Heikki Paananen, MSc., Lehtori Lahden Ammattikorkeakoulu, Liiketalouden Ala Tietojenkäsittely vuodesta 2011 Mm. Ketterät projektinhallintatekniikat, projektiohjaus. 10 v. työkokemus teknologiaprojekteista,

Lisätiedot

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen

Vastausten ja tulosten luotettavuus. 241 vastausta noin 10 %:n vastausprosentti tyypillinen Vastausten ja tulosten luotettavuus Vastaukset 241 vastausta noin 10 %:n vastausprosentti tyypillinen Kansainväliset IT:n hallinnan hyvät käytännöt. Luotettavuusnäkökohdat Kokemukset ja soveltamisesimerkit

Lisätiedot

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3

ADE Oy Hämeen valtatie 144 20540 TURKU. Tuotekonfigurointi. ADE Oy Ly Tunnus: 1626957-3 Tuotekonfigurointi ADE Oy lyhyesti Asiakkaiden tarpeisiin suunnattua innovatiivista ja toimivaa ohjelmisto- ja 3d animaatiopalvelua. Ade Oy on toteuttanut vuodesta 2000 alkaen haastavaa interaktiivista

Lisätiedot

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

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta

OHJ-3010 Ohjelmistotuotannon perusteet. Ohjelmistoprojektin hallinta OHJ-3010 Ohjelmistotuotannon perusteet Ohjelmistoprojektin hallinta 1 Sisältö Projektiorganisaatio ja sidosryhmät Ohjelmistoprojektin kulku Projektin suunnittelu Ositus Osallistujat Työmäärän arviointi

Lisätiedot

Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun

Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun Tilannetietoisuus läpinäkyvyys antaa välineet parempaan palveluun l Yrityksen kumppanien yhteydenpidon lisääminen Janne Ohtonen, Enterprise Architect, Affecto Finland Oy Yit Yrityksen kumppaniverkosto

Lisätiedot

DevOps Suomessa TUTKIMUSRAPORTTI 5.5.2014

DevOps Suomessa TUTKIMUSRAPORTTI 5.5.2014 DevOps Suomessa TUTKIMUSRAPORTTI 5.5.2014 Tutkimuksen toteutti Eficode Oy:n toimeksiannosta asiantuntijaorganisaatioihin erikoistunut markkinatutkimustoimisto Value Clinic Oy. 1 Yhteenveto, DevOps-menetelmä

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

5aDay strategiatyössä

5aDay strategiatyössä 5aDay strategiatyössä Pilvipalvelu 5aDay (www.5aday.fi) on kuin 2010- luvun Time Manager. Helppo- käyttöisellä välineellä saavutat erinomaisia tuloksia keskittymällä olennaisiin asioihin. Koska käyttäjiä

Lisätiedot

Project-TOP QUALITY GATE

Project-TOP QUALITY GATE Project-TOP QUALITY GATE FOR SUCCESSFUL COMPANIES TYÖKALU ERP- JÄRJESTELMIEN TESTAUKSEEN PROJECT-TOP QUALITY GATE Quality Gate on työkalu ERP-järjestelmien testaukseen Huonosti testattu ERP- järjestelmä

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

Projektisuunnitelma. Projektin tavoitteet

Projektisuunnitelma. Projektin tavoitteet Projektisuunnitelma Projektin tavoitteet Projektin tarkoituksena on tunnistaa erilaisia esineitä Kinect-kameran avulla. Kinect-kamera on kytkettynä tietokoneeseen, johon projektissa tehdään tunnistuksen

Lisätiedot

S11-09 Control System for an. Autonomous Household Robot Platform

S11-09 Control System for an. Autonomous Household Robot Platform S11-09 Control System for an Autonomous Household Robot Platform Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Quang Doan Lauri T. Mäkelä 1 Kuvaus Projektin tavoitteena on

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

3. Ryhdy kirjoittamaan ja anna kaiken tulla paperille. Vääriä vastauksia ei ole.

3. Ryhdy kirjoittamaan ja anna kaiken tulla paperille. Vääriä vastauksia ei ole. 1 Unelma-asiakas Ohjeet tehtävän tekemiseen 1. Ota ja varaa itsellesi omaa aikaa. Mene esimerkiksi kahvilaan yksin istumaan, ota mukaasi nämä tehtävät, muistivihko ja kynä tai kannettava tietokone. Varaa

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

Kuinka IdM-hanke pidetään raiteillaan

Kuinka IdM-hanke pidetään raiteillaan Kuinka IdM-hanke pidetään raiteillaan Projektipäällikön kokemuksia 4.10.2011 IdM-projektitkin pitää suunnitella Kaiken perustana on riittävä ymmärrys projektin sisällöstä, laajuudesta ja vaaditusta osaamisesta

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

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

Koulutuksen suhdannevaihtelut. Zeppeliinistä suihkukoneaikaan

Koulutuksen suhdannevaihtelut. Zeppeliinistä suihkukoneaikaan Koulutuksen suhdannevaihtelut Zeppeliinistä suihkukoneaikaan Suhdannevaihtelut People 1970-1990 Perusasiat kestävät ratkaisut 1990-1995 Teknologiat nopean ohjelmistokehityksen ratkaisut 1995 2000 Menetelmät

Lisätiedot

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Määrittelydokumentti NJC2. Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Määrittelydokumentti NJC2 Helsinki 11.2.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti ( ov) Projektiryhmä Eero Anttila Olli

Lisätiedot

Soft QA. Vaatimusten muutostenhallinta. Ongelma

Soft QA. Vaatimusten muutostenhallinta. Ongelma Vaatimusten muutostenhallinta Ongelma Muutostenhallinta on usein vaatimustenhallinnan Akilleen kantapää. Projektien alkaessa ensimmäiset vaatimukset kootaan ja dokumentoidaan, mutta usein vaatimuksia ei

Lisätiedot

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant

Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant Miten löydän Sen Oikean? 22.11.2012 Senaattoritilaisuus Liisa Paasiala, Senior Consultant On mahdollista löytää Se Oikea! Luotanko sattumaan? Onnistuminen on aloitettava heti Onnistumisen kaava on 4 x

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

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

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

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

Ketterät menetelmät ja julkinen hankinta

Ketterät menetelmät ja julkinen hankinta Liiketoimintaosaamisen klusteri Tietohallintojohtamisen EO Ylempi AMK Ketterät menetelmät ja julkinen hankinta Ilkka Meriläinen 27.4.2011 Ketterät menetelmät Joukko järjestelmän kehitysmenetelmiä, joille

Lisätiedot

ICT:n johtamisella tuloksia

ICT:n johtamisella tuloksia Tuottava IT ICT:n johtamisella tuloksia Data: Tietohallintojen johtaminen Suomessa 2012 Tietääkö liiketoimintajohto mitä IT tekee? Ei osaa sanoa tietääkö Ei tiedä Osittain Tietää 0 % 10 % 20 % 30 % 40

Lisätiedot

Yhteisöllisen oppimisen työpaja 9.12.2010 Reflektori 2010 Tulokset

Yhteisöllisen oppimisen työpaja 9.12.2010 Reflektori 2010 Tulokset Yhteisöllisen oppimisen työpaja 9.12.2010 Reflektori 2010 Tulokset Fasilitointi: Kati Korhonen-Yrjänheikki, TEK; Dokumentointi työpajassa: Ida Mielityinen, TEK; Fläppien dokumentointi tulosraporttia varten:

Lisätiedot

1. Ohjaustyylit. Esimerkkejä tyylin käyttötilanteista. Tavoite. Työpaikkaohjaajan toiminta. Tulokset

1. Ohjaustyylit. Esimerkkejä tyylin käyttötilanteista. Tavoite. Työpaikkaohjaajan toiminta. Tulokset 1. Ohjaustyylit on hyvä tunnistaa itselleen ominaiset tavat ohjata opiskelijoita. on hyvä osata joustavasti muuttaa ohjaustyyliään erilaisiin tilanteisiin ja erilaisille opiskelijoille sopivaksi. Seuraavaksi

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

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet

Järjestelmäarkkitehtuuri (TK081702) Lähtökohta. Integroinnin tavoitteet Järjestelmäarkkitehtuuri (TK081702) Integraation tavoitteita Lähtökohta Web-palvelut Asiakasrekisteri ERP, Tuotannon ohjaus Tuotanto Myynti Intranet Extranet? CRM Johdon tuki Henkilöstö Kirjanpito Palkanlaskenta

Lisätiedot

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

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

Lisätiedot

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi

Laadukas vaatimustenhallinta. Pekka Mäkinen Copyright SoftQA Oy www.softqa.fi Laadukas vaatimustenhallinta Pekka Mäkinen www.softqa.fi Esityksen perusajatuksia Vaatimuksilla on elinkaari ja ne muuttuvat. Tuotteen elinkaari vaikuttaa vaatimuksiin. Vaatimusten keruussa ja -hallinnassa

Lisätiedot

Webforum. Version 15.3 uudet ominaisuudet. Päivitetty: 2015-09-21

Webforum. Version 15.3 uudet ominaisuudet. Päivitetty: 2015-09-21 Webforum Version 15.3 uudet ominaisuudet Päivitetty: 2015-09-21 Sisältö Tietoja tästä dokumentista... 3 Yleistä... 4 Alustan otsikointi... 5 Alustan otsikoinnin uusi ryhmittely käyttäjän kuvalla... 5 Aloita

Lisätiedot

SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor 2014

SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor 2014 SYSTEEMIJOHTAMINEN! Sami Lilja! itsmf Finland 2014! Oct 2-3 2014! Kalastajatorppa, Helsinki! Reaktor Mannerheimintie 2 00100, Helsinki Finland tel: +358 9 4152 0200 www.reaktor.fi info@reaktor.fi 2014

Lisätiedot

Meidän visiomme......sinun tulevaisuutesi

Meidän visiomme......sinun tulevaisuutesi Meidän visiomme... Asiakkaittemme akunvaihdon helpottaminen...sinun tulevaisuutesi Uusia asiakkaita, lisää kannattavuutta ja kehitystä markkinoiden tahdissa Synergy Battery Replacement Programme The Battery

Lisätiedot

Hankinnan problematiikka

Hankinnan problematiikka Antti Kirmanen Hankinnan problematiikka Toimittajan näkökulma Asiakkaan näkökulma www.sulava.com www.facebook.com/sulavaoy 2 1. Ristiriita www.sulava.com www.facebook.com/sulavaoy 3 Asiakas haluaa Onnistuneen

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

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

Moduls: Tehokkuutta myymälärakentamiseen tehostamalla konehuonerakentamista

Moduls: Tehokkuutta myymälärakentamiseen tehostamalla konehuonerakentamista Moduls: Tehokkuutta myymälärakentamiseen tehostamalla konehuonerakentamista Konehuoneen rakentamissa on haasteita, jotka vaikuttavat suoraan kauppaketjujen liiketoimintaan HAASTEET VAIKUTUKSET RATKAISU:

Lisätiedot

Hiljaisen tietämyksen johtaminen

Hiljaisen tietämyksen johtaminen Hiljaisen tietämyksen johtaminen Uudista ja uudistu 2009 Hiljainen tietämys on osa osaamista Hiljainen ja näkyvä tieto Hiljainen tieto Tiedämme enemmän kuin kykenemme ilmaisemaan *) kokemusperäistä, alitajuista

Lisätiedot

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007

Merlin Systems Oy. Kommunikaatiokartoitus päätöksenteon pohjaksi. Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlin Systems Oy Kommunikaatiokartoitus päätöksenteon pohjaksi Riku Pyrrö, Merlin Systems Oy 8.11.2007 Merlinin palvelujen toimittaminen ja Asiakasratkaisuyksikön tehtäväkenttä Merlin Asiakasratkaisut

Lisätiedot

Oma ääni kuuluviin omat taidot näkyviin

Oma ääni kuuluviin omat taidot näkyviin Oma ääni kuuluviin omat taidot näkyviin Hyvää Ikää Kaikille seminaari Seinäjoella 18.9.2014 Marjut Mäki-Torkko Vammaispalvelujen johtaja, KM Mitä ajattelet ja sanot minusta Sitä luulet minusta Sinä olet

Lisätiedot

Avoimen lähdekoodin kehitysmallit

Avoimen lähdekoodin kehitysmallit Avoimen lähdekoodin kehitysmallit Arto Teräs Avoimen lähdekoodin ohjelmistot teknisessä laskennassa -työpaja CSC, 25.5.2009 Avoimen lähdekoodin kehitysmallit / Arto Teräs 2009-05-25

Lisätiedot

Keskitetyn integraatiotoiminnon hyödyt

Keskitetyn integraatiotoiminnon hyödyt Keskitetyn integraatiotoiminnon hyödyt Janne Kangasluoma / Chief Enterprise Architect, Ilmarinen Teemu O. Virtanen / Director, Information Logistics, Digia 2013 IBM Corporation HUOLEHDIMME NOIN 900 000

Lisätiedot

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä

Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Oppivat tuotantokonseptit uusi näkökulma tuotantokonseptien ja välineiden kehittämiseen yrityksissä Tuotanto, konseptit, oppiminen yritystoiminnan kehittämisen uudet näkökulmat 25.5.2011 Aalto-yliopiston

Lisätiedot

Lakki. Lisää ot sik k o osoit t am alla. Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010

Lakki. Lisää ot sik k o osoit t am alla. Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy. vierailuluentosarja OTM kurssi 2010 Lakki Nöyrästi vain lakki kourassa... Jussi Vänskä Espotel Oy vierailuluentosarja OTM kurssi 2010 2.luento: ohjelmistokehityksen päivärutiinit Lisää ot sik k o osoit t am alla Siitä vain reunasta Miten

Lisätiedot

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina

HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina HP OpenView ratkaisut toiminnan jatkuvuuden turvaajina - Käytännön esimerkkejä ITIL ja ITSM mukaisista IT palveluhallinnan toteutuksista ja mahdollisuuksista Ville Koskinen Sales Specialist, HP Software

Lisätiedot

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen

Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä. Simo Tauriainen Simulaattoriavusteinen ohjelmistotestaus työkoneympäristössä Simo Tauriainen www.ponsse.com 25.8.2011 Ponsse-konserni Ponsse Oyj on tavaralajimenetelmän metsäkoneiden myyntiin, tuotantoon, huoltoon ja

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

Psykologitiimi Päämäärä Oy

Psykologitiimi Päämäärä Oy Psykologitiimi Päämäärä Oy Perustettu 1994 Turussa Päätoimiala soveltuvuustutkimukset ja opiskelijavalintojen tutkimukset Valintakoeyhteistyötä 14 toisen asteen oppilaitoksen ja 5 ammattikorkeakoulun kanssa

Lisätiedot

Miten kirjastossa oleva tieto saadaan asiakkaiden käyttöön? Mihin kirjastossa tarvitaan osaamista?

Miten kirjastossa oleva tieto saadaan asiakkaiden käyttöön? Mihin kirjastossa tarvitaan osaamista? Miten kirjastossa oleva tieto saadaan asiakkaiden käyttöön? Mihin kirjastossa tarvitaan osaamista? Kirjaston tehtävä Sivistys Innoitus Kirjaston tavoitteet Palvelu, jolla on merkitystä ja jota käytetään

Lisätiedot

Yhdeksän mittaria ohjelmistotuotannon. seuraamiseen. tsoft. Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004. http://cs.joensuu.

Yhdeksän mittaria ohjelmistotuotannon. seuraamiseen. tsoft. Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004. http://cs.joensuu. Yhdeksän mittaria ohjelmistotuotannon tilan seuraamiseen tsoft Vesa Tenhunen Joensuun yliopisto, TKT:n laitos 15.9.2004 http://cs.joensuu.fi/tsoft/ Yhdeksän mittaria ohjelmistotuotannon tilan seuraamiseen

Lisätiedot

Mihin kaikkeen voit törmätä testauspäällikön saappaissa?

Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Mihin kaikkeen voit törmätä testauspäällikön saappaissa? Arto Stenberg Copyright Kuntien Tiera Oy Kuntien Tiera Copyright Kuntien Tiera Oy Tiera on vuonna 2010 perustettu yli 200:n kuntatoimijan omistama

Lisätiedot

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

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

Lisätiedot

Tutkimushankkeiden riskienhallinta

Tutkimushankkeiden riskienhallinta Tutkimushankkeiden riskienhallinta Tutkimuksen tuki, yrittäjyys ja innovaatiot Jyväskylän yliopisto Kirsi Murtosaari Parityö Tutkimushankkeet: Kuvatkaa hankkeiden haasteita suunnittelu- ja toteutus- tai

Lisätiedot

Seuraavat väitteet koskevat keskijohtoa eli tiimien esimiehiä ja päälliköitä tai vastaavia.

Seuraavat väitteet koskevat keskijohtoa eli tiimien esimiehiä ja päälliköitä tai vastaavia. KESKIJOHDON OSAAMISTARPEET Vastaajan taustatiedot: Vastaaja on: Vastaajan vastuualue: 1. Tiimin esimies tai vastaava 2. Päällikkö tai vastaava 3. Johtaja 1. Johto ja taloushallinto 2. Tutkimus ja kehitys

Lisätiedot

Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia

Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia Tuottavatko pilotoinnit tuloksia riittävän nopeasti käytännön hankkeiden kokemuksia Tuottavat ja eivät tuota Tulokset riippuvat niistä tekijöistä, jotka projektia perustettaessa on määritelty ja miten

Lisätiedot

MYYNTI- VALMENNUKSEN OSTAJAN OPAS MIISA HELENIUS - POINTVENUE

MYYNTI- VALMENNUKSEN OSTAJAN OPAS MIISA HELENIUS - POINTVENUE MYYNTI- VALMENNUKSEN OSTAJAN OPAS MIISA HELENIUS - POINTVENUE 8 ASIAA, JOTKA KANNATTAA HUOMIOIDA, KUN OSTAA MYYNTI- VALMENNUSTA 8 ASIAA, JOKTA KANNATTAA HUOMIOIDA KUN OSTAA MYYNTI- VALMENNUSTA Olen kerännyt

Lisätiedot

ELMAS 4 Laitteiden kriittisyysluokittelu 8.2.2012 1/10. Ramentor Oy ELMAS 4. Laitteiden kriittisyysluokittelu. Versio 1.0

ELMAS 4 Laitteiden kriittisyysluokittelu 8.2.2012 1/10. Ramentor Oy ELMAS 4. Laitteiden kriittisyysluokittelu. Versio 1.0 1/10 Ramentor Oy ELMAS 4 Laitteiden kriittisyysluokittelu Versio 1.0 2/10 SISÄLTÖ 1 Kuvaus... 3 2 Kriittisyysluokittelu ELMAS-ohjelmistolla... 4 2.1 Kohteen mallinnus... 4 2.2 Kriittisyystekijöiden painoarvojen

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

1. JAKSO - SÄÄNNÖT Tavat, käytös, toisen kunnioittava kohtaaminen, huomaavaisuus, kohteliaisuus.

1. JAKSO - SÄÄNNÖT Tavat, käytös, toisen kunnioittava kohtaaminen, huomaavaisuus, kohteliaisuus. 1. JAKSO - SÄÄNNÖT Tavat, käytös, toisen kunnioittava kohtaaminen, huomaavaisuus, kohteliaisuus. 1. Ympäristö a. Tässä jaksossa ympäristö rakennetaan pedagogiikkaa tukevien periaatteiden mukaisesti ja

Lisätiedot

MIIKKA VUORINEN, SANTERI TUOMINEN, TONI KAUPPINEN MAT-81100 Verkkopalvelun laadukkuus ja arviointi

MIIKKA VUORINEN, SANTERI TUOMINEN, TONI KAUPPINEN MAT-81100 Verkkopalvelun laadukkuus ja arviointi AMPPARIT.COM VERKKOPALVELUN ARVIOINTISUUNNITELMA RYHMÄ VUTUKA MIIKKA VUORINEN, SANTERI TUOMINEN, TONI KAUPPINEN MAT-81100 Verkkopalvelun laadukkuus ja arviointi II SISÄLLYS 1 Arvioitava verkkopalvelu 3

Lisätiedot

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T

4.12.2005. SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA REFAKTOROINTI Antti Ahvenlampi, 57408L Erik Hakala, 57509T SEPA: REFAKTOROINTI 2 (9) SEPA: REFAKTOROINTI 3 (9) VERSIOHISTORIA Version Date Author Description 0.1 2.12.2005 Erik Hakala Ensimmäinen

Lisätiedot

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille

Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille 1(23) Testaus-tietoisku: Tärkeimpiä asioita testauksesta projektityökurssilaisille Matti Vuori, Tampereen teknillinen yliopisto 30.10.2012 Sisällysluettelo 1/2 Esityksen tarkoitus 4 Laatu on tärkeää, ei

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

Kaari-työhyvinvointikysely - esimiehen opas

Kaari-työhyvinvointikysely - esimiehen opas Kaari-työhyvinvointikysely - esimiehen opas Valmistaudu kyselyyn vinkkilista esimiehelle vinkkilista työyhteisölle Valmistaudu kyselyyn - vinkkilista esimiehelle Missä tilaisuudessa/palaverissa työyhteisönne

Lisätiedot

Monipuolisen yhteistyön haaste pyrittäessä korkealle

Monipuolisen yhteistyön haaste pyrittäessä korkealle 1 Monipuolisen yhteistyön haaste pyrittäessä korkealle Markus Hellström 2 Esityksen kiteytys 3 Esityksen sisältö Tavoite ja sen merkitys liiketoiminnan johtamisessa Miten vien liiketoiminnan tavoitteeseen?

Lisätiedot

Maanrakennusalan arki rallattamaan MaaRaksan avulla!

Maanrakennusalan arki rallattamaan MaaRaksan avulla! Maanrakennusalan arki rallattamaan MaaRaksan avulla! MaaRaksa auttaa yritystä: Parantamaan kannattavuutta tuomalla tehdyt työt ja tarvikkeet laskutukseen Säästämään aikaa poistamalla moneen kertaan samojen

Lisätiedot

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna

Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Mittaaminen projektipäällikön ja prosessinkehittäjän työkaluna Finesse-seminaari 22.03.00 Matias Vierimaa 1 Mittauksen lähtökohdat Mittauksen tulee palvella sekä organisaatiota että projekteja Organisaatiotasolla

Lisätiedot

Kehittämisen omistajuus

Kehittämisen omistajuus Kehittämisen omistajuus Kuntaliitto 18.4.2013 Tuottava ja hallittu kehittämistoiminta kunnissa hanke (KUNTAKEHTO) Pasi-Heikki Rannisto Kehityspäällikkö, HT Tampereen Palveluinnovaatiokeskus (TamSI) Kehittämistyön

Lisätiedot

A11-02 Infrapunasuodinautomatiikka kameralle

A11-02 Infrapunasuodinautomatiikka kameralle A11-02 Infrapunasuodinautomatiikka kameralle Projektisuunnitelma AS-0.3200 Automaatio- ja systeemitekniikan projektityöt Lassi Seppälä Johan Dahl Sisällysluettelo Sisällysluettelo 1. Projektityön tavoite

Lisätiedot

Tulevaisuuden markkinat tulevaisuuden yrittäjä. Vesa Puhakka vesa.puhakka@oulu.fi

Tulevaisuuden markkinat tulevaisuuden yrittäjä. Vesa Puhakka vesa.puhakka@oulu.fi Tulevaisuuden markkinat tulevaisuuden yrittäjä Vesa Puhakka vesa.puhakka@oulu.fi Dynaamisessa liiketoimintaympäristössä on valtavasti informaatiota mutta vähän tietoa. Koska suurin osa yrityksistä ja ihmisistä

Lisätiedot

Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria?

Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria? Miten kuvaat ja kehität organisaation kokonaisarkkitehtuuria? Kuntamarkkinat Tietoisku 10. ja 11.9.2014 1 Mitä on kokonaisarkkitehtuuri? Kokonaisarkkitehtuuri on organisaation johtamis- ja kehittämismenetelmä,

Lisätiedot