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]

Tutkittua tietoa. Tutkittua tietoa 1

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

Lisätiedot

Scrumin käyttö ketterässä sovelluskehityksessä

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

Lisätiedot

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

Automaattinen yksikkötestaus

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

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

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

Lisätiedot

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

Oleelliset vaikeudet OT:ssa 1/2

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

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

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

Lisätiedot

Avoimen ja yhteisen rajapinnan hallintasuunnitelma v.1.4

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

Lisätiedot

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

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

Lisätiedot

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

Avoin lähdekoodi hankinnoissa Juha Yrjölä

Avoin lähdekoodi hankinnoissa Juha Yrjölä Avoin lähdekoodi hankinnoissa 9.6.2016 Juha Yrjölä Mitä on avoin lähdekoodi? 1. Lähdekoodi tulee jakaa ohjelmiston mukana tai antaa saataville joko ilmaiseksi tai korkeintaan luovuttamiskulujen hinnalla.

Lisätiedot

Ohjelmiston testaus ja laatu. Ohjelmistotekniikka elinkaarimallit

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

Lisätiedot

Kahdenlaista testauksen tehokkuutta

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

Lisätiedot

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

Avoimen ja yhteisen rajapinnan hallintamalli

Avoimen ja yhteisen rajapinnan hallintamalli Avoimen ja yhteisen rajapinnan hallintamalli 1.10.2015 Sisältö tausta avoimet toimittajakohtaiset rajapinnat (toimittajan hallitsemat rajapinnat) avoimet yhteiset rajapinnat (tilaajan hallitsemat rajapinnat)

Lisätiedot

Onnistunut SAP-projekti laadunvarmistuksen keinoin

Onnistunut SAP-projekti laadunvarmistuksen keinoin Onnistunut SAP-projekti laadunvarmistuksen keinoin 07.10.2010 Patrick Qvick Sisällys 1. Qentinel 2. Laadukas ohjelmisto täyttää sille asetetut tarpeet 3. SAP -projektin kriittisiä menestystekijöitä 4.

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

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio

Loppuraportti. Virtuaali-Frami, CAVE-ohjelmisto. Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu. Versio 1 Loppuraportti Virtuaali-Frami, CAVE-ohjelmisto Harri Mähönen projektiassistentti Seinäjoen ammattikorkeakoulu Versio 1.0 15.1.2006 2 Sisällys Tiivistelmä... 3 1 Johdanto... 4 1.1 Dokumentin tarkoitus...

Lisätiedot

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

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

Lisätiedot

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

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

BaRE Käyttövalmis vaatimusmäärittelymenetelmä

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

Lisätiedot

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

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

Lisätiedot

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu

Liite 1: KualiKSB skenaariot ja PoC tulokset. 1. Palvelun kehittäjän näkökulma. KualiKSB. Sivu 1. Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Liite 1: skenaariot ja PoC tulokset 1. Palvelun kehittäjän näkökulma Tilanne Vaatimus Ongelma jos vaatimus ei toteudu Palvelun uusi versio on Palveluiden kehittäminen voitava asentaa tuotantoon vaikeutuu

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

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

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

Lisätiedot

4. Funktion arvioimisesta eli approksimoimisesta

4. Funktion arvioimisesta eli approksimoimisesta 4. Funktion arvioimisesta eli approksimoimisesta Vaikka nykyaikaiset laskimet osaavatkin melkein kaiken muun välttämättömän paitsi kahvinkeiton, niin joskus, milloin mistäkin syystä, löytää itsensä tilanteessa,

Lisätiedot

Integrointialgoritmit molekyylidynamiikassa

Integrointialgoritmit molekyylidynamiikassa Integrointialgoritmit molekyylidynamiikassa Markus Ovaska 28.11.2008 Esitelmän kulku MD-simulaatiot yleisesti Integrointialgoritmit: mitä integroidaan ja miten? Esimerkkejä eri algoritmeista Hyvän algoritmin

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

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

Standardi IEC Ohjelmisto

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

Lisätiedot

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio

Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi, dynaaminen mallintaminen, yhteistoimintakaavio ja sekvenssikaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia

Lisätiedot

Luku 8. Aluekyselyt. 8.1 Summataulukko

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

Lisätiedot

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

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

Lisätiedot

Menetelmäraportti - Konfiguraationhallinta

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

Lisätiedot

Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti

Projektiryhmä Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti Projektiryhmä Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Tietojenkäsittelyopin ohjelmatyö 2(8)

Lisätiedot

markkinointistrategia

markkinointistrategia Menestyksen markkinointistrategia kaava - Selkeät tavoitteet + Markkinointistrategia + Markkinointisuunnitelma + Tehokas toiminta = Menestys 1. markkinat Käytä alkuun aikaa kaivaaksesi tietoa olemassa

Lisätiedot

Software engineering

Software engineering Software engineering Alkuperäinen määritelmä: Naur P., Randell B. (eds.): Software Engineering: A Report on A Conference Sponsored by the NATO Science Committee, NATO, 1968: The establishment and use of

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

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

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

Lisätiedot

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

Ketterän. Hannu Salmela, Mikko Hallanoro, Seppo Sippa, Tommi Tapanainen, Jari Ylitalo organisaation IT

Ketterän. Hannu Salmela, Mikko Hallanoro, Seppo Sippa, Tommi Tapanainen, Jari Ylitalo organisaation IT Ketterän Hannu Salmela, Mikko Hallanoro, Seppo Sippa, Tommi Tapanainen, Jari Ylitalo organisaation IT Talentum Helsinki 2010 Talentum Media Oy ja tekijät ISBN 978-952-14-1505-0 Kansi: Jarkko Nikkanen Taitto:

Lisätiedot

Kandityön kirjoittaminen. Opinnäyteseminaari

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

Lisätiedot

MS-C2105 Optimoinnin perusteet Malliratkaisut 5

MS-C2105 Optimoinnin perusteet Malliratkaisut 5 MS-C2105 Optimoinnin perusteet Malliratkaisut 5 Ehtamo Demo 1: Arvaa lähimmäksi Jokainen opiskelija arvaa reaaliluvun välillä [0, 100]. Opiskelijat, joka arvaa lähimmäksi yhtä kolmasosaa (1/3) kaikkien

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

Kysymykset tarjouspyyntöön Pääarkkitehtipalvelut Dnro 21/021/2013

Kysymykset tarjouspyyntöön Pääarkkitehtipalvelut Dnro 21/021/2013 Kysymykset tarjouspyyntöön Pääarkkitehtipalvelut Dnro 21/021/2013 K1: Tarjouspyynnössä työmääräksi on arvioitu 120-160 htp/vuosi. Voiko tämän jakaa osiin tarjotun pääarkkitehdin ja tämän varahenkilön välillä

Lisätiedot

Ryhmämallitusohje 2016

Ryhmämallitusohje 2016 LUONTAISET TAIPUMUKSET Ryhmämallitusohje 2016 Kalevi Sipinen RYHMÄMALLITUSOHJEITA: VAIHE 1 Mallittamalla otetaan tietoiseen käyttöön olemassa olevia taitoja/mestaruutta LUONTAISET TAIPUMUKSET RYHMÄMALLITUS:

Lisätiedot

Tulevaisuuden ohjaustyöohjaustyön

Tulevaisuuden ohjaustyöohjaustyön Tulevaisuuden ohjaustyöohjaustyön tulevaisuus? Big picture Miten muodostaa kokonaiskuva rinnakkain, päällekkäin ja ennakoimattomasti tapahtuvien muutosten kokonaisuudesta? Iso kuva hukassa niin työyhteisöillä

Lisätiedot

Kompleksisuus ja kuntien kehittäminen

Kompleksisuus ja kuntien kehittäminen Kompleksisuus ja kuntien kehittäminen Kuntatutkijoiden seminaari 25.5.2011, Lapin yliopisto, Rovaniemi Pasi-Heikki Rannisto, HT Tampereen yliopisto Haasteita johtamiselle ja johtamisteorioille Miksi ennustaminen

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

Mallintarkistus ja sen

Mallintarkistus ja sen VERSIO 0.1 LUONNOS Mallintarkistus ja sen soveltaminen PLCohjelmien verifioinnissa AS-0.3200 Automaatio- ja systeemitekniikan projektityöt -projektisuunnitelma Markus Hartikainen 2/1/2009 Sisältö 1. Projektityön

Lisätiedot

Test-Driven Development

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

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

Johdantoluento. Ohjelmien ylläpito Johdantoluento Ylläpito-termin termin määrittely Ylläpito ohjelmistotuotannon vaiheena Evoluutio-termin määrittely Muita kurssin aiheeseen liittyviä termejä TTY Ohjelmistotekniikka 1 Ohjelmien ylläpito

Lisätiedot

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy

Käytännön haasteita ja ratkaisuja integraation toteutuksessa. Jukka Jääheimo Teknologiajohtaja Solita Oy Käytännön haasteita ja ratkaisuja integraation toteutuksessa Jukka Jääheimo Teknologiajohtaja Solita Oy 13.03.2008 Sisältö 2 Alustus Integraation haasteet Integraatioarkkitehtuuri Hyvän integraatioarkkitehtuurin

Lisätiedot

KYMENLAAKSON AMMATTIKORKEAKOULU. Ubuntu. Yukun Zhou

KYMENLAAKSON AMMATTIKORKEAKOULU. Ubuntu. Yukun Zhou KYMENLAAKSON AMMATTIKORKEAKOULU Ubuntu Yukun Zhou 2014 Yukun Zhou Harjoitustyö 1 SISÄLLYSLUETTELO 1. YLEISTÄ... 2 2. JULKAISUT... 3 3. SUOSIO... 4 4. ASENNUS... 4 5. TURVALLISUUS... 4 6. PAKETTIENHALLINTA...

Lisätiedot

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

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

Lisätiedot

Opetusmateriaali. Fermat'n periaatteen esittely

Opetusmateriaali. Fermat'n periaatteen esittely Opetusmateriaali Fermat'n periaatteen esittely Hengenpelastajan tehtävässä kuvataan miten hengenpelastaja yrittää hakea nopeinta reittiä vedessä apua tarvitsevan ihmisen luo - olettaen, että hengenpelastaja

Lisätiedot

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

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

Lisätiedot

Hyvät t käytännöt t julkisiksi miksi ja miten?

Hyvät t käytännöt t julkisiksi miksi ja miten? Hyvät t käytännöt t julkisiksi miksi ja miten? Olemme kaikki kuulleet sanottavan, että virheistä opitaan ja kantapää on hyvä opettaja. Tekevälle tapahtuu virheitä ja niiden salliminen on välttämätöntä,

Lisätiedot

Erilaisia Osaava verkostoja - Lapin hankkeiden Learning café

Erilaisia Osaava verkostoja - Lapin hankkeiden Learning café Erilaisia Osaava verkostoja - Lapin hankkeiden Learning café Aika 27.11.11.2013 klo 9.45 10.30 Kouluttaja: Koulutus- ja kehitysjohtaja Miten hankkeen toimintaa voidaan motivoida, keinoja viedä hanketta

Lisätiedot

SUUNTA TOIMINNAN JA ARVIOINNIN SUUNNITTELUN TYÖKALU

SUUNTA TOIMINNAN JA ARVIOINNIN SUUNNITTELUN TYÖKALU 1 SUUNTA TOIMINNAN JA ARVIOINNIN SUUNNITTELUN TYÖKALU Suunta on työkalu, jota käytetään suunnittelun ja arvioinnin apuna. Se on käyttökelpoinen kaikille, jotka ovat vastuussa jonkun projektin, toiminnon,

Lisätiedot

VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D

VERSIONHALLINTA. PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D VERSIONHALLINTA PARIOHJELMOINTI Lari Ahti, 62634M Antti Kauppinen, 58390D Versio Päivä Tekijä Kuvaus 0.1 26.10.2005 Kaarlo Lahtela Ensimmäinen versio 0.2 10.12.2006 Lauri Kiiski Suomennettu 3 (8 ) SISÄLLYS

Lisätiedot

Lefkoe Uskomus Prosessin askeleet

Lefkoe Uskomus Prosessin askeleet Lefkoe Uskomus Prosessin askeleet 1. Kysy Asiakkaalta: Tunnista elämästäsi jokin toistuva malli, jota et ole onnistunut muuttamaan tai jokin ei-haluttu käyttäytymismalli tai tunne, tai joku epämiellyttävä

Lisätiedot

7.4.7. KÄSITYÖ VALINNAINEN LISÄKURSSI

7.4.7. KÄSITYÖ VALINNAINEN LISÄKURSSI 7.4.7. KÄSITYÖ VALINNAINEN LISÄKURSSI 339 LUOKKA 8 2 h viikossa TAVOITTEET oppii tuntemaan käsityöhön liittyviä käsitteitä ja käyttämään erilaisia materiaaleja, työvälineitä ja menetelmiä oppii käsityön

Lisätiedot

Suunnitteluvaihe prosessissa

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

Lisätiedot

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

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

Lisätiedot

Ketteryydestä muutamien esimerkkien kautta eli mitä voimme

Ketteryydestä muutamien esimerkkien kautta eli mitä voimme Ketteryydestä muutamien esimerkkien kautta eli mitä voimme oppia Tarzanista ja jazz-yhtyeestä Ketterä toiminta on aina ihmisten toimintaa. Kehitettäessä ketteryyttä on hyvä tarkastella prosessien takana

Lisätiedot

Rakennuskustannukset hallintaan Fore-laskennan käyttö suunnittelussa

Rakennuskustannukset hallintaan Fore-laskennan käyttö suunnittelussa Rakennuskustannukset hallintaan Fore-laskennan käyttö suunnittelussa Hankesuunnittelupäivä 25.10.2016, Ari Huomo Kustannusohjauksen tavoitteet Tavoitteellinen, kuhunkin hankkeen vaiheeseen sopiva kustannusarvio

Lisätiedot

Convergence of messaging

Convergence of messaging Convergence of messaging Testaussuunnitelma The Converge Group: Mikko Hiipakka Anssi Johansson Joni Karppinen Olli Pettay Timo Ranta-Ojala Tea Silander Helsinki 20. joulukuuta 2002 HELSINGIN YLIOPISTO

Lisätiedot

Kuinka laadin tutkimussuunnitelman? Ari Hirvonen I NÄKÖKULMIA II HAKUILMOITUS

Kuinka laadin tutkimussuunnitelman? Ari Hirvonen I NÄKÖKULMIA II HAKUILMOITUS Kuinka laadin tutkimussuunnitelman? Ari Hirvonen 15.9.2014 I NÄKÖKULMIA II HAKUILMOITUS I NÄKÖKULMIA Hyvä tutkimussuunnitelma Antaa riittävästi tietoa, jotta ehdotettu tutkimus voidaan arvioida. Osoittaa,

Lisätiedot

ASUKKAAT - kehityksen jarru vai voimavara?

ASUKKAAT - kehityksen jarru vai voimavara? ASUKKAAT - kehityksen jarru vai voimavara? KIRA-foorumi 27.1.2010 Toimitusjohtaja Anja Mäkeläinen ASUNTOSÄÄTIÖ ASUKKAAT KESKIÖSSÄ ASUINALUEITA KEHITETTÄESSÄ Hyvä elinympäristö ei synny sattumalta eikä

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen KEMIA Kemian päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta kemian opiskeluun T2 ohjata ja

Lisätiedot

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito

Ylläpito. Ylläpito. Ylläpidon lajeja Ohjelmistotuotanto, syksy 1998 Ylläpito Kaikki ohjelmistoon sen julkistamisen jälkeen kohdistuvat muutostoimenpiteet jopa 70-80% ohjelmiston elinkaarenaikaisista kehityskustannuksista Ylläpidon lajeja korjaava ylläpito (corrective) testausvaiheessa

Lisätiedot

Esimiehen opas kehityskeskusteluihin. Irma Meretniemi

Esimiehen opas kehityskeskusteluihin. Irma Meretniemi Esimiehen opas kehityskeskusteluihin Irma Meretniemi Talentum Helsinki 2012 Copyright 2012 Talentum Media Oy ja Irma Meretniemi Kustantaja: Talentum Media Oy Kansi: Lapine Oy Taitto: Anni Palotie ISBN

Lisätiedot

1 Määrittelyjä ja aputuloksia

1 Määrittelyjä ja aputuloksia 1 Määrittelyjä ja aputuloksia 1.1 Supremum ja infimum Aluksi kerrataan pienimmän ylärajan (supremum) ja suurimman alarajan (infimum) perusominaisuuksia ja esitetään muutamia myöhemmissä todistuksissa tarvittavia

Lisätiedot

Prosessiajattelu. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessikuvaus - CMMI. Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4.

Prosessiajattelu. Prosessikuvaukset ja elinkaarimallit. Organisaation prosessikuvaus - CMMI. Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4. Prosessikuvaukset ja elinkaarimallit Sami Kollanus TJTA330 Ohjelmistotuotanto 3.4. Organisaation prosessikuvaus - CMMI Level5 Level4 Organizational Innovation and Deployment Causal Analysis and Resolution

Lisätiedot

Yritys AB Oy Verkostokäsikirja (7) VERKOSTOKÄSIKIRJA

Yritys AB Oy Verkostokäsikirja (7) VERKOSTOKÄSIKIRJA Yritys AB Oy Verkostokäsikirja 01.01.2012 1(7) VERKOSTOKÄSIKIRJA Yritys AB Oy Verkostokäsikirja 01.01.2012 2(7) 1 VERKOSTON TARKOITUS JA TEHTÄVÄT... 3 2 VERKOSTOKUMPPANIT... 3 3 YRITYS AB OY JA VERKOSTOKUMPPANIN

Lisätiedot

How to Support Decision Analysis with Software Case Förbifart Stockholm

How to Support Decision Analysis with Software Case Förbifart Stockholm How to Support Decision Analysis with Software Case Förbifart Stockholm (Valmiin työn esittely) 13.9.2010 Ohjaaja: Prof. Mats Danielson Valvoja: Prof. Ahti Salo Tausta -Tukholman ohikulkutien suunnittelu

Lisätiedot

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen

TUKIMATERIAALI: Arvosanan kahdeksan alle jäävä osaaminen 1 FYSIIKKA Fysiikan päättöarvioinnin kriteerit arvosanalle 8 ja niitä täydentävä tukimateriaali Opetuksen tavoite Merkitys, arvot ja asenteet T1 kannustaa ja innostaa oppilasta fysiikan opiskeluun T2 ohjata

Lisätiedot

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

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

Lisätiedot

Toimiva työyhteisö DEMO

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

Lisätiedot

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004

tsoft Tarkastusmenettelyt ja katselmukset Johdanto Vesa Tenhunen 4.2.2004 Tarkastusmenettelyt ja katselmukset tsoft Vesa Tenhunen 4.2.2004 http://cs.joensuu.fi/tsoft/ Johdanto Yksi tärkeimmistä tekijöistä laadukkaiden ohjelmistojen tuottamisessa on puutteiden aikainen havaitseminen

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

Järjestelmien elinkaarenhallinta, järjestelmäsalkunhallinta ja Thinking Portfolio

Järjestelmien elinkaarenhallinta, järjestelmäsalkunhallinta ja Thinking Portfolio 1 Järjestelmien elinkaarenhallinta, järjestelmäsalkunhallinta ja Thinking Portfolio Teppo Jalkanen Asiantuntijapäällikkö: Arkkitehtuuriohjaus OP Arkkitehtuuri 23.9.2016 Järjestelmäsalkunhallinnan käyttöönotto

Lisätiedot

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

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

Lisätiedot

KOULUTUSOHJELMA JA TUTKINTONIMIKE: Artesaani TUTKINNON OSA: Toteuttamisen suunnittelu LAAJUUS: 10 ov TUTKINNON OSAN AMMATTITAITOVAATIMUKSET

KOULUTUSOHJELMA JA TUTKINTONIMIKE: Artesaani TUTKINNON OSA: Toteuttamisen suunnittelu LAAJUUS: 10 ov TUTKINNON OSAN AMMATTITAITOVAATIMUKSET TUTKINTO: Käsi- ja taideteollisuusalan perustutkinto KOULUTUSOHJELMA JA TUTKINTONIMIKE: Artesaani TUTKINNON OSA: Toteuttamisen suunnittelu LAAJUUS: 10 ov TUTKINNON OSAN AMMATTITAITOVAATIMUKSET TUTKINNON

Lisätiedot

Σ!3674. Advanced Test Automation for Complex Software-Intensive Systems

Σ!3674. Advanced Test Automation for Complex Software-Intensive Systems Advanced Test Automation for Complex Software-Intensive Systems = Advanced Test Automation for Complex Software- Intensive Systems Pääteemana kompleksisten ja erittäin konfiguroitavien softaintensiivisten

Lisätiedot

Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille

Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille Tutkintojen, oppimäärien ja muiden osaamiskokonaisuuksien sijoittuminen vaativuustasoille Liite Kansallinen vaativuustaso / eurooppalaisen tutkintojen viitekehyksen taso Taso1 Tutkinnot, oppimäärät ja

Lisätiedot

Yhteenvetoa, pieniä laajennuksia, tulevaisuuden haasteita

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

Lisätiedot

Projektisuunnitelma Viulu

Projektisuunnitelma Viulu Projektisuunnitelma Viulu Kuusela Johannes Sjöblom Teemu Suominen Osma Ohjelmistotuotantoprojekti Helsinki 23.9.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Versiohistoria Päivämäärä Versio

Lisätiedot

Ohjelemistotuotanto, syksy 1998 /Prosessi Prosessimallit

Ohjelemistotuotanto, syksy 1998 /Prosessi Prosessimallit Prosessimallit Prosessimalli on ohjelmiston elinkaaren rakenteen määrittely ts. kuvaus sille millaisten vaiheiden kautta ohjelmisto kehittyy ideasta hautaan mahdollisimman yleisesti sovellettavissa oleva

Lisätiedot

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa:

Testaus käsite. Sekalaista testausasiaa. Testauksen käsitteestä. Kattavuusmitat. Jos ajatellaan, että testaus = V&V, voidaan erottaa: Testaus käsite Sekalaista asiaa Sami Kollanus 15.11.2006 Jos ajatellaan, että = V&V, voidaan erottaa: Staattinen Dynaaminen Toisaalta voidaan määritellä Myersin (1979) mukaan: Testaus on ohjelman suoritusta,

Lisätiedot

Luku 6 Projektisuunnitteluvaihe

Luku 6 Projektisuunnitteluvaihe Luku 6 Projektisuunnitteluvaihe Projektisuunnittelu Project Planning Projektin Project Definition määrittely and ja Planning suunnittelu Projektin Initiate käynnistäminen andja organisointi Project Organize

Lisätiedot

Yhteisöllinen tapa työskennellä

Yhteisöllinen tapa työskennellä Yhteisöllinen tapa työskennellä Pilvipalvelu mahdollistaa uudenlaisten työtapojen täysipainoisen hyödyntämisen yrityksissä Digitalisoituminen ei ainoastaan muuta tapaamme työskennellä. Se muuttaa meitä

Lisätiedot

JHS166:n uudistus ja lopputulokset. JUHTA Raimo Porttikivi

JHS166:n uudistus ja lopputulokset. JUHTA Raimo Porttikivi JHS166:n uudistus ja lopputulokset JUHTA 11.12.2014 Raimo Porttikivi JHS166 uudistamisen työryhmä Raimo Porttikivi, pj Tommi Nordberg, puolustusministeriö Harri Eskola, Tekes Matti Lisitsin, Maanmittauslaitos

Lisätiedot

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima

Esityksen sisältö Määrittelyjen mukaisuudesta varmistuminen - PlugIT-leima Esityksen sisältö Johdanto Yleistä leimausmenettelystä ja leimasta Leimausmenettelyn vaiheet Kuinka määrittelyjen mukaisuus testataan: esimerkkejä testitapauksista Olennaisimmat kysymykset leimausmenettelyn

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3

SEPA diary. Dokumentti: SEPA_diary_PK_HS.doc Päiväys: Projekti: AgileElephant Versio: V0.3 AgilElephant SEPA Diary Petri Kalsi 55347A Heikki Salminen 51137K Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: PK&HS Sivu 1 / 7 Dokumenttihistoria Revisiohistoria Revision päiväys: 29.11.2004 Seuraavan

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

Tanja Saarenpää Pro gradu-tutkielma Lapin yliopisto, sosiaalityön laitos Syksy 2012

Tanja Saarenpää Pro gradu-tutkielma Lapin yliopisto, sosiaalityön laitos Syksy 2012 Se on vähän niin kuin pallo, johon jokaisella on oma kosketuspinta, vaikka se on se sama pallo Sosiaalityön, varhaiskasvatuksen ja perheen kokemuksia päiväkodissa tapahtuvasta moniammatillisesta yhteistyöstä

Lisätiedot