Kehityssykli ohjelmistokehityksessä

Koko: px
Aloita esitys sivulta:

Download "Kehityssykli ohjelmistokehityksessä"

Transkriptio

1 Kehityssykli ohjelmistokehityksessä TURUN YLIOPISTO Informaatioteknologian laitos TkK-tutkielma Jussi Timonen

2 TURUN YLIOPISTO Informaatioteknologian laitos TIMONEN, JUSSI: Kehityssykli ohjelmistokehityksessä TkK-tutkielma, 29 s. Ohjelmistotekniikka Lokakuu 2008 Ohjelmistokehitys on ala, johon kohdistuu jatkuvasti yhä enemmän paineita maailman tullessa entistä riippuvaisemmaksi erilaisesta tietotekniikasta. Ala on suhteellisen nuori mutta nopeasti kasvava. Ohjelmistojen suurentunut koko ja alati muuttuvat vaatimukset ovat johtaneet tilanteeseen, jossa on tarvetta kehittää uusia tapoja ja tekniikoita, jotka pystyvät vastaamaan nopeasti muuttuvaan tilanteeseen ja pitämään paisuvan ohjelmiston kehittäjiensä hallinnassa. Tämä tutkielma käsittelee pääasiassa ketterien kehitysmenetelmien toimintaa nykypäivän ohjelmistokehityksessä perinteisiä malleja unohtamatta. Tutkielmassa on mukana näkökulma työelämässä toteutetusta Scrum-menetelmän sovelluksesta. Lopussa tutkitaan myös metriikan ja testauksen osuutta kehitystyössä ja niiden eroja perinteisiin ja ketteriin menetelmiin. Asiasanat: ketterät menetelmät, Scrum, extreme Programming, ohjelmistokehitysmallit

3 Sisällys 1 Johdanto 2 2 Perinteiset mallit Vesiputousmalli Spiraalimalli Inkrementaalinen 5 3 Ketterät kehitysmenetelmät Ketterien kehitysmenetelmien historia extreme Programming Scrum 11 4 Testaus osana ketterää ohjelmistokehitystä Testaus perinteisissä malleissa Testaus ketterissä malleissa 15 5 Metriikka ohjelmistoprosessissa Metriikka perinteisissä malleissa Metriikka ketterissä malleissa 18 6 Suuren mittaluokan kehitysprojektit Component Team Feature Team 20 7 Kehitysmalli yrityksessä Nykyinen malli Mallin haasteet Parannusmahdollisuuksia 26 Lähteet 28 Liitteet 29 Liite 1: Agile manifesto 29

4 2 1 Johdanto Ohjelmistoala on historiansa aikana kokenut monia mullistuksia. Ohjelmistojen kompleksisuus, koko ja vaatimukset ovat kasvaneet jatkuvasti. Kehitettäviltä sovelluksilta vaaditaan entistä parempaa laatua ja nopeampaa toimintaa. Näitä kasvavia vaatimuksia vastaamaan on kehitetty erilaisia ohjelmistokehitysmalleja, joilla pyritään selkeyttämään kehitystä, jakamaan työmäärää ja arvioimaan paremmin ohjelmiston valmistumisastetta. Työn tarkoitus on antaa lukijalle kuva perinteisten ohjelmistokehitysmallien ja ketterien menetelmien keskeisimmät eroista ja eduista. Perinteisistä malleista esitellään vesiputousmalli, spiraalimalli ja inkrementaalinen malli. Ketteristä menetelmistä tarkemmin tutkitaan extreme Programming- ja Scrum-malleja. Työhön on otettu mukaan näkökulma työelämästä ja todellisesta ohjelmistokehityksestä. Tässä osassa työ painottuu Scrum- menetelmien ja -työtapojen tuntemiseen, koska tutkimassani työympäristössä käytettiin juuri Scrum-menetelmää. Pelkän ohjelmistokehitysprosessin lisäksi työhön on sisällytetty osiot eri mallien testauksesta sekä luku metriikan merkityksestä ohjelmistoprosessissa.

5 3 2 Perinteiset mallit Ohjelmistokehitysmallit otettiin alun perin käyttöön selkeyttämään kaaoksen valtaamaa ohjelmistokehitysalaa. Mallit ovat tuoneet rakenteen ja suunnittelun ohjelmistokehityksen maailmaan, mutta ala on silti kaaoksen partaalla. (McGraw Hill 2005.) 2.1 Vesiputousmalli Vesiputousmalli (engl. Waterfall model) on yksi tunnetuimpia ja käytetyimipiä vaihejakomalleja. Se perustuu vesiputousmaiseen rakennelmaan, jossa jokaisessa vaiheessa suoritetaan tietty ohjelmistokehityksen osa. Edellisen osan tuloksen on tarkoitus toimia syötteenä seuraavalle osalle ja siten ohjata projektia eteenpäin. Mallin heikkoutena voidaan pitää sen tapaa kiinnittää vaiheet tiukasti. Tästä syystä tuotteen kehitys ei näy prosessin aikana asiakkaalle ja vaatimusten osuus suunnittelussa on erityisen korostunut. (Karttunen 2000, Sommerville 2004.) Alkuperäisen mallin kehittäjä Winston Royce sisällytti malliinsa myös palautekierroksen, jonka avulla kehityksen eri vaiheet saisivat palautetta toisiltaan(kuva 1). Enemmistö mallin käyttäjistä ei ole ottanut tätä kierrosta käyttöön, mistä syystä malli muuttuu lineaariseksi. (McGraw Hill 2005.) Malli jaetaan lähteestä riippuen hieman eri tavoin, mutta jokaisesta mallista voidaan löytää määrittely-, suunnittelu- ja toteutusvaiheet. (Karttunen 2000.) Kuva 1. Vesiputousmalli (Haikala& Merijärvi 2000). 2.1 Spiraalimalli Spiraalimalli eroaa vesiputousmallista siten, että siinä kehitystyö käydään läpi sykleissä, joissa jokaisessa kehitetään ohjelmistoa vastaamaan paremmin sille annettuja vaatimuksia. Spiraalin ideana on täydentää jokaisessa syklissä edellisen syklin vastaavia osia(kuva 2).

6 4 Spiraalimalli jakautuu neljään pääosaan: 1. Tavoiteanalyysi Määritetään tarkat tavoitteet seuraavalle syklille. Luodaan suunnitelma syklin toteuttamiseksi ja tunnistetaan riskit. 2. Riskianalyysi Analysoidaan jokainen tunnettu riski ja pyritään minimoimaan riskin vaikutus. 3. Toteutus ja testaus Kun riskit on todettu, valitaan toteutustapa. Tämä voi olla esimerkiksi vesiputous- tai evolutionäärinen malli. Tässä yhteydessä suoritetaan myös testaus. 4. Suunnittelu Tehdään päätös jatkamisesta seuraavaan kierrokseen. Tästä edetään taas vaiheeseen 1. (Sommerwille 2004.) Kuva 2. Spiraalimalli (Sommerwille 2004).

7 5 2.3 Inkrementaalinen malli Monissa ohjelmistonkehitysprosesseissa vaatimukset ovat tarkasti tiedossa, mutta prosessi tuottaa kuitenkin lineaarisen kehityssyklin. Tälläiselle prosessille voi tulla tarve tuottaa osia toiminnallisuudesta toisia nopeammin. Tätä toiminnallisuutta, joka tuotetaan prosessin osana, kutsutaan inkrementiksi. (Pressman 2005.) Inkrementaalisen kehityksen voi ajatella koostuvan lyhyistä vesiputousmallin sykleistä, joita iteroidaan toinen toisensa jälkeen. Jokainen iteraatio tuottaa inkrementin ja edistää siten ohjelmiston kehitystä. Tällä tavoin voidaan luoda eritasoisia ominaisuuksia, ja jo luotuja ominaisuuksia voidaan myös tarkentaa antamalla lisää toiminnallisuutta seuraavassa iteraatiossa. (Pressman 2005.) Usein ensimmäisen iteraation tuote on ydintuote. Se toteuttaa perusvaatimukset, mutta suurin osa toiminnallisuudesta on vielä toteuttamatta. Ydintuote toimitetaan usein asiakkaalle perusteellista arviointia varten. Näin saavutetaan se, että asiakas ja toteuttaja ymmärtävät toisiaan. Arvioinnin tuloksilla muokataan seuraavia iteraatiotita vastaamaan lopullisen tuotteen vaatimuksia. Täten tuote kehittyy koko sen elinkaaren ajan.

8 6 3 Ketterät kehitysmenetelmät 3.1 Ketterien kehitysmenetelmien historia Ketterien kehitysmenetelmien virallisena syntymäpaikkana voidaan pitää mökkiä Snowbirdin hiihtokeskuksessa Utahissa. Tähän mökkin kerääntyi helmikuun puolessa välissä vuonna 2001 seitsemäntoista ohjelmistoalan ammattilaista pohtimaan alan tulevaisuutta ja rentoutumaan. Kolmipäiväisen tapaamisen tuloksena syntyi Agile software development manifesto, joka esitetään kokonaisuudessaan liitteessä 1. (Agile manifesto 2001; Liite 1.) Manifestin sisältö on seuraava (Martin 20003): Yksilöitä ja interaktioita enemmän kuin prosesseja ja työkaluja Toimivaa sovellusta enemmän kuin kokonaisvaltaista dokumentaatiota Asiakasyhteistyötä enemmän kuin sopimusneuvotteluita Muutokseen reagoimista enemmän kuin suunnitelman noudattamista. Manifestin yhteydessä luotiin vielä 12 periaatetta, jotka erottavat ketterät menetelmät raskaista prosesseista (Martin 2003): 1. Korkein prioriteetti on täyttää asiakkaan vaatimukset aikaisilla ja jatkuvilla toimituksilla sekä arvokkaalla ohjelmistolla. 2. Hyväksytään muuttuvat vaatimukset myös myöhäisessä kehitysvaiheessa. Muutetaan muutokset asiakkaan kilpailukyvyksi. 3. Toimitetaan toimivia ohjelmistoja säännöllisesti, muutaman viikon tai kuukauden välein. Mieluummin usein kuin harvoin. 4. Liiketoiminnan ammattilaisten ja kehittäjien tulee tehdä töitä yhdessä päivittäin koko projektin ajan. 5. Projektin luovat siitä motivoituneet henkilöt. 6. Tehokkain tapa tiedon kuljettamiseksi tiimissä on kasvokkain tapahtuva kommunikaatio. 7. Toimiva ohjelmisto on tärkein edistyksen mittari. 8. Ketterät kehitysmenetelmät edistävät kestävää kehitystä. Rahoittajien, kehittäjien ja käyttäjien pitäisi pystyä säilyttämään tasainen tahti jatkuvasti. 9. Jatkuva huomio tekniseen erinomaisuuteen ja hyvään suunnitteluun lisää ketteryyttä. 10. Yksinkertaisuus tekemättömän työn maksimointi on olennaista.

9 7 11. Parhaat arkkitehtuurit, vaatimukset ja suunnitelmat ilmestyvät itseorganisoituneista tiimeistä. 12. Tiimi arvioi tasaisin väliajoin, miten se voisi tulla tehokkaammaksi ja kehittää siten toimintaansa tehokkaammaksi. 3.1 Extreme programming XP on tunnettu ketterä kehitysmenetelmä, jonka luoja on Kent Beck. XP on kevyt menetelmä, joka sopii pienistä keskikokoisille ohjelmistonkehitystiimeille. Muodollisuutensa puolesta XP asettuu informaaliin ryhmittymään. Sen käytössä ei normaalisti juurikaan suoriteta dokumentointia. Toiminnan runko hahmotellaan tarinakorteille (engl. Story Card). Kuten muutkin ketterät kehitysmenetelmät XP keskittyy asiakkaaseen, muuttuviin vaatimuksiin ja laatuun. (Larman 2004). Sana extreme tulee Beckin uskomuksesta, että ohjelmistokehityksessä ei voi olla liikaa hyviä asioita. Tällä Beck tarkoittaa hyviksi todettujen tapojen viemistä jokapäiväiseen ohjelmointiin äärimmäisellä tasolla (engl. extreme, suom. äärimmäinen). Tämä tarkoittaa esimerkiksi seuraavaa (Larman 2004): Testaus on hyvää, joten kirjoitetaan yksikkötestit (mahdollisuuksien mukaan) koko koodille ja hyväksymistestit koko toiminnallisuudelle. Koodinkatselmointi on hyvää, joten tehdään sitä koko ajan ja käytetään myös pariohjelmointia. XP:n arvot ja käytännöt on esitetty kuvassa 3. Kuva 3. Extreme programmingin käytännöt ja arvot (Larman 2004).

10 8 XP:n erikoisuus ilmenee siinä, että se ei vaadi muuta valmista tuotosta kuin itse koodin ja testit. Vaikka XP:tä käytettäessä pyritään tekemään vain koodi ja testit, voidaan menetelmässä tarvittaessa ottaa käyttöön XP:tä raskaammissa menetelmissä noudatettuja käytäntöjä. Vaikka kaikki evolutionaariset kehitysmenetelmät välttävät spesifikaatioiden kirjaamista, suurin osa kuitenkin rohkaisee kirjoittamaan ylös yksityiskohtia seuraavasta iteraatiosta. XP:n lähestymistapa on korostaa suullista kanssakäymistä vaatimusten ja suunnitelmien määrittämisessä. Ainoa kirjoitettu dokumentti ovat tarinakortit, joille on kirjattu hyvin suurpiirteisiä asioita. Järjestelmä muodostuu tehokkaaksi, kun asiakas on samassa tilassa ja tarinakorttien avulla keskustellaan tuotettavasta koodista. XP:n lähestymistapaa kehitykseen voidaan kuvata Craig Larmanin esittämällä kysymyksellä (Larman 2004): Is there a sane and disciplined way to quickly succeed on typical small projects by focusing on code and tests, while avoiding most other documentation? (Onko olemassa järkevää ja kurinalaista tapaa onnistua nopeasti tyypillisissä pienissä projekteissa keskittymällä koodiin ja testeihin ja samalla minimoimalla muu dokumentaatio? Suom. Jussi Timonen.) XP:n lähtökohta ei ole hakkerimainen koodaa-ja-korjaa-ohjelmointi, vaan se tähtää uuteen rakenteelliseen ja kestävään tapaan onnistua huomioiden samalla ketterien kehitysmenetelmien periaatteet. XP on hyvin kurinalainen ja samalla ketterä ohjelmistonkehitysmenetelmä (Larman 2004). Kuva 4. XP-projektin vaiheet (Ambler 2002).

11 9 XP-projektin vaiheet ovat seuraavat (Amber 2002, kuva 4): Tutkimusvaiheen tärkeänä tuloksena ovat tarinakortit. Tätä vaihetta voidaan pitää valmiina, kun asiakas on sitä mieltä, että tarinakorteilla on enemmän kuin tarpeeksi materiaalia ensimmäistä versiota varten, ja ohjelmoijat ovat sitä mieltä, että järjestelmää ei voi arvioida paremmin kuin implementoimalla se. Tässä vaiheessa ohjelmoijat käyttävät kaikkia eri tekniikoita, joita he aikovat käyttää varsinaisessa ohjelmassa. Parin viikon jälkeen valmistuu kolmesta neljään eri versiota mahdollisesta arkkitehtuurista ja tekniikoista, joita ohjelmoijat voivat arvioida keskenään löytääkseen parhaan mahdollisen vaihtoehdon. Vaiheeseen kannattaa myös sisällyttää simulointi, jossa testataan valmiin järjestelmän rajoja ratkaisumallit huomioon ottaen. Samaan aikaan kun ohjelmoijat suunnittelevat toteutusta, asiakas harjoittelee kirjoittamaan tarinoita eli kuvauksia ohjelman toiminnasta. Tämä on yleensä ensin vaikeaa, koska asiakas ei kirjoita sitä, mitä ohjelmoijat tarvitsevat. Alussa on tärkeää antaa nopeaa palautetta, jotta asiakas löytää oikean näkökulman kirjoittaessaan. Suunnitteluvaiheen tarkoituksena on löytää yhteisymmärrys ensimmäisen ja tärkeimmän ohjelmistoversion valmistumisajankohdalle asiakkaan ja ohjelmoijien kesken. Yleensä ensimmäiseen versioon menee aikaa kahdesta kuuteen kuukautta. Iteraatiot ensimmäiseen versioon tapahtuvat jakamalla aikataulu yhdestä neljän viikon pituisiin iteraatioihin. Jokainen iteraatio tuottaa toimivat testisetit jokaiselle tarinalle, joka on kyseisessä iteraatiossa. Ensimmäinen iteraatio luo arkkitehtuurin ohjelmistolle, ja seuraavassa tulisi valita tarinat, jotka pakottavat luomaan koko järjestelmän. Seuraavissa iteraatioissa oikeat tarinat löydetään tutkimalla kysymystä: Mikä on arvokkain asia tässä iteraatiossa? Jokaisen iteraation aikana etsitään ongelmia tutkimalla aikataulua ja suunnitelmia. Kun havaitaan ongelma, siihen tulee puuttua heti joko muuttamalla tai lisäämällä tarinakortteja. Kuva 5. Iteraation elinkaari (Ambler, 2002).

12 10 Elinkaaren vaiheet ovat seuraavat (Beck 2002; kuva 5): Tuotteistamisvaiheessa iteraation pituus muuttuu kolmesta viikosta noin viikkoon. Tällöin pidetään päivittäisiä tapaamisia ryhmän kesken, jotta kaikki tietävät ohjelmiston tilanteen. Tässä vaiheessa suoritetaan sertifiointia ja rinnakkaista testausta. Tarkoituksena on varmistaa, että kehitettävä järjestelmä on valmis tuote. Koska projekti on jo pitkällä, ryhmällä on varsin paljon tietoa ohjelmiston rakenteesta ja toiminnasta. Tässä vaiheessa suoritetaan järjestelmän optimointi. Nyt myös hidastetaan tahtia, koska riskien arviointi tulee tärkeämmäksi valittaessa tarinoita iteraatioihin. Ylläpitoa voi sanoa XP-projektin normaaliksi tilaksi. Siinä tuotetaan samaan aikaan uutta toiminnallisuutta ja pidetään olemassa oleva systeemi toiminnassa. Muutoksissa ollaan nyt paljon varovaisempia kuin aikaisemmin, koska tuote on jo julkaistu. Ryhmän toiminta saattaa vaatia muutoksia, koska ulkopuolelta tulee tukipyyntöjä. Kun ryhmään liittyy uusi jäsen, hänen tulisi toimia ensimmäisten iteraatioiden ajan pariohjelmoinnissa ja lukea paljon testejä sekä koodia. Kun uusi jäsen tuntee olevansa valmis, hän voi aloittaa varsinaisen ohjelmiston tekemisen mutta kevyemmällä työmäärällä. Kuolema on luonnollinen vaihe ohjelmistokehityksessä siinä kuin ihmiselämässäkin. Kun asiakas ei keksi enää lisää uusia tarinoita, on aika viedä ohjelmisto varastoon. Tässä vaiheessa kirjoitetaan dokumentti, josta käy ilmi ohjelmiston rakenne ja käyttö. Kuolemaan johtavia syitä voi olla kaksi: asiakas on tyytyväinen ohjelmistoon, tai ohjelmisto ei vain toimi kuten haluttaisiin. Roolit ovat tarpeellisia niin normaalissa elämässä kuin työympäristössäkin. XP jakaa eri tekijöille omat roolit ja kehottaa myös tarkastelemaan roolien sopivuutta eri henkilöille. Roolit ovat Beckin (2000) mukaan seuraavat: Ohjelmoija on XP-projektin sydän. Ohjelmoijan toimenkuvaan kuuluvat itse ohjelmointi, testien tekeminen, refraktorointi eli jatkuva ohjelmiston rakenteen parantaminen, tehtävien arviointi ja tärkeänä osana myös kommunikointi. Tarkoituksena on kehittää mahdollisimman arvokasta ohjelmistoa ja samalla jättää turha työ pois. XP-ohjelmoijan työ on jokseenkin erilaista kuin normaali ohjelmistotyö. XP-ohjelmoija tarvitsee hyvät kommunikointi- ja yhteisökyvyt. Asiakas ja ohjelmoija hoitavat testaamisen, ja ohjelmoijan vastuulla on opastaa asiakasta tekemään järkeviä testejä ja ajaa niitä. Asiakas muodostaa ohjelmoijan kanssa XP:n ytimen. Ohjelmoija tietää, miten ohjelmoida, asiakas tietää, mitä ohjelmoida. Asiakkaan rooli XP-projektissa ei ole helppo. Asiakkaan vastuulla on suuri osa projektin menestyksestä. Asiakkaan tulee olla yhtä innokas oppimaan uutta kuin ohjelmoijan.

13 11 Tärkein tehtävä on kirjoittaa hyviä tarinoita ja tehdä päätöksiä, kun niitä tarvitaan, sekä suorittaa testausta. Seuraaja valvoo projektin etenemistä ja tekee arvioita työn onnistumisesta ja aikaisempien arvioiden paikkansapitävyydestä. Seuraaja valvoo uusien työtehtävien arviointia vertaamalla niitä aikaisempiin tuloksiin ja pyrkii siten saattamaan tiimin toiminnan mahdollisimman ajantasaiseksi. Seuraaja pitää yllä tilastoa tiimin toiminnasta ja seuraa kokonaisuutta. Valmentaja on vastuussa prosessista kokonaisuutena. Valmentaja huomaa, jos joku poikkeaa normaalista prosessista ja pyrkii hoitamaan asian kuntoon sekä toimii tarvittaessa tukena ja ohjaajana. Konsultti toimii projektissa ulkopuolisena tahona, joka tarjoaa erikoistietämystään, kun projekti sitä tarvitsee. Konsultin tehtävä ei ole varsinaisesti osallistua työntekoon vaan pikemminkin opettaa tarvittavia taitoja ryhmälle. Johtajan rooli on ryhmälle tärkeä. Johtajan tulee tarjota suunta ryhmälle ja myös huolehtia, että tavoitteista pidetään kiinni. Tärkeä tekijä johtajan roolin onnistumisessa on avoin kommunikaatio ja valmius paneutua ryhmän ongelmiin. Ryhmä luottaa siihen, että johtaja palauttaa sen tarvittaessa oikeaan suuntaan. 3.2 Scrum Scrum on ohjelmistonkehitysmenetelmä, joka korostaa itsenäistä vastuunjakoa ja ryhmän toimintaa ongelmanratkaisussa. Se keskittyy arvoihin ja tapoihin projektinhallinnassa eikä vaatimuksiin ja itse koodauksen käytäntöihin tai testaukseen. Tästä syystä Scrum on helposti yhdistettävissä muihin kehitysmetodeihin. (Larman 2004). Nimensä Scrum on saanut rugbyssä käytettävän aloitusryhmityksen mukaan (Wikipedia). Scrum-projektissa on vain kolme roolia. Nämä ovat tuotteen omistaja (engl. Product Owner), Scrum-ryhmä ja Scrum-mestari (engl. Scrum Master). Kaikki vastuu projektissa on jaettu näiden osapuolien kesken. Tuotteen omistaja on vastuussa siitä, että ulkopuoliset vaatimukset (aikataulut, raha, vaatimukset) välittyvät ryhmän tietoon. Hän myös priorisoi työtehtävät. Ryhmä on itseorganisoitunut itsenäinen yksikkö, joka huolehtii kaikista kehitysiteraatioon kuuluvista vastuista. Ryhmän tavoite on muuttaa iteraatioon valitut tehtävät toimivaksi inkrementiksi aikarajojen sisällä.

14 12 Scrum-mestari on vastuussa prosessista ja sen ylläpitämisestä sekä opettamisesta. Hänen tulee myös varmistaa, että käytetty Scrum sopii organisaatioon. Mestari ei ole erityisasemassa ryhmään nähden. Hänellä on tärkeä tehtävä toimia esteiden poistajana samalla, kun hän toimii ryhmän jäsenenä. Yksilöt, jotka toimivat näissä rooleissa, ovat asiasta kiinnostuneita ja sille omistautuneita. Monet ovat projekteista kiinnostuneita mutta eivät valmiita omistautumaan. Scrum tekee selvän eron näiden kahden ryhmän välille. (Schwaber 2003). Scrum-projektissa arvot ovat seuraavat (Schwaber 2003): Sitoutuminen Koko Scrum-ryhmä sitoutuu määriteltyyn tavoitteeseen iteraation ajaksi ja hoitaa sen kokonaan itsenäisesti. Johtoporras ja Scrum-mestari sitoutuvat olemaan sekaantumatta ryhmän asioihin iteraation aikana sekä tukemaan ja poistamaan esteitä ryhmän tieltä. Tuotteen omistaja sitoutuu määrittelemään ja priorisoimaan Product Backlogin eli eräänlaisen tehtävälistauksen ja ohjaamaan seuraavaan iteraatioon otettavia komponentteja. Keskittyminen Scrum-ryhmän tulee voida keskittyä iteraation eli sprintin tavoitteisiin ilman häiriöitä. Siksi johtoportaan tulee tarjota resursseja, poistaa esteitä ja välttää keskeyttämästä työtä ylimääräisillä pyynnöillä. Avoimuus Avoin Product Backlog tekee tiimin työn ja priorisoinnin näkyväksi. Päivittäisessä Scrum-tapaamisessa jaetaan oma työtilanne ja kerrataan yleinen tilanne. Työn sujuminen ja nopeus esitetään graafilla, joka on kaikille näkyvä. Rohkeus Johtoportaalla on oltava rohkeutta suunnitella ja ohjata ryhmää ja luottaa yksilöihin sekaantumatta iteraation sisäiseen toteutukseen. Ryhmällä on oltava rohkeutta ottaa vastuuta ja ohjata iteraation kulkua.

15 13 Kuva 6. Sprintin kulku (Schwaber2004). Scrum-projektin elinkaari koostuu neljästä vaiheesta: suunnittelu, järjestäminen, kehitys ja julkaisu (kuva 6). Scrum-tapaaminen on palaveri, joka pidetään päivittäin sprintin aikana. Tapaamisen tarkoitus on saattaa koko Scrum-ryhmä ajan tasalle. Tapaaminen pidetään joka kerta samassa paikassa ja samaan aikaan. Ryhmän jäsenet kootaan yhteen ympyrään ja jokaiselle esitetään seuraavat kysymykset: Mitä olet tehnyt viime tapaamisen jälkeen? Mitä aiot tehdä ensi tapaamiseen mennessä? Mitä esteitä on vaikeuttamassa tavoitteisiin pääsyä? Tapaaminen on yleensä lyhyt, noin minuuttia, ja se antaa selvän kuvan projektin vaiheesta. Scrum-ryhmän ulkopuolisilla ei ole tapaamisessa oikeutta puhua, ja he seisovat ympyrän ulkopuolella. Päivittäinen Scrum-tapaaminen pidetään ryhmälle, muut ovat vapaaehtoisesti vain kuuntelemassa. Jos jostain aiheesta jää paljon puhuttavaa, pidetään uusi tapaaminen Scrumtapaamisen jälkeen. (Larman 2004.) Product Backlog on lista, johon on kirjattu kaikenlainen tekemätön työ. Sen ylläpitovastuu on tuotteen omistajalla, joka päivittää ja priorisoi listaa. Lista ei ole koskaan valmis, ja se elää projektin mukana mukautuen ja muuttuen uusien vaatimusten mukaan. Tämän listan pohjalta ryhmä valitsee tehtävät osat seuraavaan sprintiin. (Schwaber 2003.)

16 14 Scrumin kehitysiteraation tavoitteena on luoda mahdollisimman valmis tuote. Scrum-iteraatio syntyy valitsemalla aluksi Product backlogista ne osat, joihin ryhmä pystyy sitoutumaan. Tämä lista on Sprint Backlog. Sprint Backlogin tehtävät pilkotaan vielä pienemmiksi tehtäviksi, eli taskeiksi. Tuotteen omistaja määrittelee jokaiselle sprintille tavoitteen. Tämän jälkeen ryhmälle annetaan aikaa 1 4 viikkoa toteuttaa valitut taskit. Joka-aamuisessa tapaamisessa käydään läpi tilanne ja kirjataan se graafiin. Tässä vaiheessa voidaan pohtia, ollaanko tavoiteajassa vai ei. Sprintin aikana on mahdollista muokata tehtäviä ja tavoitteita edistymisen mukaan, mutta tämä tapahtuu vain ryhmän sisällä. Kun aika on loppu, ryhmä esittelee työnsä tulokset ja tuotteen omistaja vertaa niitä asetettuun tavoitteeseen. Menetelmän tehokkuus liittyy pitkälti ryhmän kykyyn arvioida osaamistaan ja työmääriä sekä omistautumiseen valittujen tavoitteiden toteuttamisesta. (Larman 2004, Schwaber 2003.) Kuva 7. Sprint backlog (Schwaber 2001). Sprintin etenemistä seurataab graafilla(kuva 7). X-akselilla on päivät, ja Y-akselilla näkyy, paljonko työtä on jäljellä. Työn yksikkö muodostuu erilaisista kertoimista ja arvioista työtehtävän vaativuudesta. Scrum-kehityksessä on kolme tärkeää palaveria. Sprintin sunnittelutapaaminen, sprintin tarkastustapaaminen ja retrospektive-palaveri eli kehityspalaveri. Suunnittelupalaverissa hajotetaan product backlogista valitut tehtävät pienemmiksi taskeiksi, joita kehittäjät alkavat tehdä. Tarkastuspalaverissä ryhmä esittelee luomansa tuotteen ja tuotteen omistaja tarkastaa sen sopivuuden Sprintin tavoitteseen nähden. Retrospektive-palaverin tarkoitus on oppia itse prosessista ja työtavoista. Scrum pyrkii olemaan oppiva järjestelmä ryhmän sisällä ja myös prosessissa.

17 15 4 Testaus osana ketterää ohjelmistokehitystä Testaus on tärkeä komponentti jokaisen ohjelmiston kehityksessä. Testauksella pyritään varmistamaan, että ohjelmisto vastaa sille annettua määrittelyä ja myös toimii tarpeeksi hyvin. Testauksella ei koskaan kyetä osoittamaan ohjelmiston virheettömyyttä tai suoraan parantamaan sen laatua vaan mittaamaan sen vallitsevaa tilaa. 4.1 Testaus perinteisissä malleissa Perinteisissä ohjelmistonkehitysmalleissa testaus on toteutettu yhtenä kokonaisena ja muista erillisenä vaiheena. Tällaisessa muodossa käydään läpi kaikki kehitysvaiheet, ja testausvaihe tuottaa uusia vaatimuksia ja virheitä. Löydetyt ongelmat otetaan huomioon seuraavassa syklissä ja pyritään korjaamaan. Virheiden löytäminen johtaa sitä kalliimpiin muutoksiin, mitä myöhemmin ne löydetään. (Kaner 1999.) 4.2 Testaus ketterissä malleissa Ketterien kehitysmenetelmien mukana on kehittynyt erilaisia tapoja luoda ohjelmistoja. Eräs näistä on Test Driven Development, jossa kirjoitetaan yksikkötestit kaikille luotaville metodeille ennen niiden varsinaista ohjelmointia. Näitä testejä ajamalla voidaan varmistaa ohjelman toimivuus, vaikka ohjelman sisälle tehtäisiinkin muutoksia. Testien tulee olla erillisiä ja automaattisia. On tärkeää, että testit ovat toisistaan riippumattomia. Tällöin ei jouduta tilanteeseen, jossa yhden testin epäonnistuminen johtaa satojen muiden testien epäonnistumiseen. On mahdotonta testata kaikkea, joten kannattaa keskittyä sellaisten komponenttien testaamiseen hyvin, jotka ovat herkkiä hajoamaan. Yksikkötestejä kirjoittavat ohjelmoijat. Kaikkien yksikkötestien tulisi mennä läpi, koska ne ovat sidottu suoraan ohjelmistoon. (Beck 2000.) Yleensä XP-ryhmässä tulisi olla ainakin yksi testaukseen erikoistunut jäsen. Hänen tehtävänään on auttaa asiakasta hyväksymistestien kirjoittamisessa ja tarinoiden luonnissa. Asiakkaan luomat hyväksymistestit eivät välttämättä mene läpi, koska ne eivät ole suoraan sidoksissa ohjelmiston sisäiseen rakenteeseen. (Beck 2000.) Automaatio on tärkeässä osassa XP:n kaltaisessa tekniikassa, jossa testejä on paljon ja niitä ajetaan koko kehityksen ajan, useita kertoja päivässä. Mitä lyhyempi iteraatio on, sitä tärkeämmäksi täysin automatisoitu testaus tulee. (Cockburn 2007.) Scrumissa testaus on pitkälle sisällytetty Sprintiin. Kehittäjät testaavat luomansa ominaisuudet samalla, kun kirjoittavat sen. Tätä toimintamallia tukee Scrumin pyrkimys mahdollisimman

18 16 yksinkertaiseen koodiin. Kun sprint on ohi, uudet ominaisuudet yhdistetään ja toiminnallisuus tarkastetaan. (Schwaber 2001.) Scrum ei ota suoraan kantaa testaukseen. On tavallista, että Scrum ja XP yhdistetään, jolloin Scrum tuo toimintamallit ja XP testauksen.

19 17 5 Metriikka ohjelmistoprosessissa On helppoa luoda tilastoja kuvaamaan ohjelman rakennetta ja sisältöä ja kutsua tulosta metriikaksi sekä kohdella näitä tuloksia aivan, kuin niillä olisi teoreettinen perusta tai ennustavaa arvoa. Tällaisella ohjelmiston tutkinnalla on yleensä hyvin vähän todellista arvoa kehitysprosessissa. (Kaner 1999.) Ennen metriikan vakavaa käyttöönottoa tulee pohtia seuraavia kysymyksiä (Kaner 1999): Mitä tämä mitta väittää mittaavansa? Mikä on teoreettinen suhde ominaisuuksien ja mittausten välillä? Onko mittarit valittu sen mukaan, onko niillä perustavanlaatuinen yhteys ominaisuuteen, jota mitataan, vai ovatko ne vain helposti saatavilla? Kun ohjelmoijaa ohjeistetaan pienentämään mittarin tulosta, esim. ohjelman kompleksisuuslukua, onko tuloksena syntynyt tuote luotettavampi vai ei, helpommin ylläpidettävä, helpommin testattava jne.? Onko testattavan ominaisuuden ja mittarin empiirinen suhde kunnossa? Voidaanko mittarin tulosta verrata eri ohjelmistojen kesken? 5.1 Metriikka perinteisissä malleissa Metriikan käyttö on vesiputousmallisessa kehitysmallissa hankalaa. Aluksi vaikuttaa siltä, että oikeat mittarit on helppo löytää. Projektin pitkittyessä asia ei kuitenkaan ole näin, vaan kehitys on vain näennäisesti suoraviivaista. Projektin alussa on eteneminen valmiusastemetriikan mukaan nopeata. Tässä vaiheessa luodaan vaatimuksia ja suunnitellaan ohjelmistoa. Ongelmia syntyy, kun varsinainen ohjelmointityö alkaa ja projektin eteen tulee uusia haasteita. Integrointivaiheessa kehitys hidastuu nopeasti, koska tässä vaiheessa kohdataan helposti odottamattomia ongelmia (kuva 8). Näiden ongelmien kanssa painivalle kehitysryhmälle kohdistuu kuluneen ajan myötä entistä suurempi paine saada järjestelmä toimimaan. Tämä johtaa helposti tilanteeseen, jossa ei ehditä suunnittelemaan kunnollisia korjauksia ohjelmistoon ja sorrutaan tekemään helpoin mahdollinen korjaus. Tuloksena syntyy pahimmillaan hauras ja heikosti ylläpidettävä tuote, joka toimitetaan myöhässä. (Royce 2001.)

20 18 Kuva 8. Metriikan kehitys vesiputousmallissa (Royce2001). 5.2 Metriikka ketterissä malleissa Scrum-ryhmässä valmiusaste muodostuu pitkälti sprintin aikana päivittyvästä Sprint Backlogin graafista. Siihen merkitään joka aamu tehdyt taskit ja seurataan projektin etenemistä. Avainasemassa on ryhmän ja tuotteen omistajan tekemät arviot eri tehtävien vaikeustasosta ja tekemiseen kuluvasta ajasta. Scrum-ryhmä tulee sitä tarkemmaksi arvioissaan, mitä enemmän aikaa kuluu ja tuntemus omiin kykyihin kasvaa. Tuotteen omistaja pitää kirjaa koko projektin arvioiduista tehtävistä Product Backlogissa. Molempien Backlogien näkyvyysalue on laaja, joten projektin seurattavuus on hyvä. Seurattavuuden ongelmana voidaan pitää sitä, että Product Backlog päivittyy jatkuvasti. (Larman 2003.) Scrum-kehityksessä toimiva mittari on Velocity. Se mittaa sprinteissä aikaansaatujen työnyksikköjen keskiarvoa. Velocity auttaa arvioimaan koko Product Backlogin valmistumiseen kuluva aikaa. Jos esimerkiksi on edetty kaksi Sprintiä, joissa on saatu aikaan 50 ja 100 työn yksikköä, on keskiarvo 75. Tämä suure luonnollisesti tarkentuu, mitä kauemmin ryhmä on työskennellyt. Usein mitataan myös asiakkaalle luvattua toiminnallisuutta suhteessa toimitettuun toiminnallisuuteen. XP-projektissa metriikka on keskeisessä asemassa. Suunnittelupeliä arvioidaan vertaamalla arvioitua kehitysaikaa toteutuneeseen. Tällä suureella ryhmä voi päätellä sopivan nopeuden työhönsä. XP-käytäntöihin kuuluu pitää esillä näkyvää karttaa, johon päivitetään ryhmän edistyminen vähintään viikoittain. Metriikalla on tapana menettää tarkoituksensa ajan myötä, joten suureita ja mittaustappoja tulee olla valmius päivittää. Metriikalla on suuntaa antava rooli XP-projektissa. Sen tarkoitus ei ole suoraan ohjata projektia vaan antaa lisätietoa ryhmän tilanteesta. (Beck 2000.)

21 19 6 Suuren mittaluokan kehitysprojektit Ketterät menetelmät tarjoavat toimivan ratkaisun pienistä keskisuuriin ohjelmistoprojekteihin. Ongelmia alkaa tulla, kun järjestelmän koko kasvaa niin suureksi, ettei 7 15 henkilön kehitysryhmällä riitä aika tai asiantuntemus. Ohjelmistoalalla on tarvetta tuoda ketterien menetelmien etuja myös suuriin projekteihin. Seuraavassa esitellään Scrum-menetelmän tapa kehittää suurempaa, kerroksittaista ohjelmistoa. 6.1 Component Team Komponenttiryhmä (engl. Component Team) on vanha lähestymistapa suurien ohjelmistokokonaisuuksien luonnissa. Siinä kehittäjistä muodostetaan ryhmät arkkitehtuuristen kokonaisuuksien ympärille. Esimerkiksi käyttöliittymää ja tietokantaa varten voi olla omat ryhmänsä(kuva 10). Mel Conway on todennut, että tuotettavan ohjelmiston ja sitä tuottavan organisaation välillä on yhteys. Tätä Convayn lakinakin tunnettua tilannetta ovat komponenttitiimien puolestapuhujat siteeranneet, mutta Convay itse ei huomiollaan rohkaise komponenttitiimien käyttöön. Hän pikemminkin vain huomioi asian. Brad Silverberg on muotoillut asian seuraavasti (Larman& Vodde 2008): The software tends to mirror the structure of the organization that built it. If you have a big, slow organization, you tend to build big, slow software. (Ohjelmisto heijastaa rakentajaorganisaationsa rakennetta. Jos organisaatio on suuri ja hidas, on tavallista, että myös ohjelmisto on suuri ja hidas. Suom. Jussi Timonen.) Komponenttiryhmiin järjestäytymiseen ohjasi kaksi perustavaa oletusta: Työntekijät eivät voi tai heidän ei kannata oppia uusia taitoja. Koodia ei voi tehokkaasti jakaa ja integroida ihmisten välillä. Komponenttiryhmä vaikutti loogiselta rakenteelta ja 1970-luvuilla. Silloin ohjelmistokehityksessä erikoistuttiin kapeaan alaan eikä ollut toisia ryhmiä, jotka olisivat voineet hajottaa ohjelmiston rakenteen. Myös versionhallinta ja testaus olivat tiensä alussa. Asiakkaan tarpeet eivät juuri koskaan rajoitu yhteen osaan ohjelmistoa, vaan uudet vaatimukset koskettavat suurta alaa. Tällöin tulee vastaan ongelma työn jakamisesta ja hallinnoinnista. Yleensä tarvitaan erillinen analyysiä varten erikoistunut ryhmä, ja myös testauksen vastuu on epäselvä, koska millään ryhmistä ei ole välttämättä kokonaiskuvaa ohjelmistosta.

22 20 Tämä kehitys johtaa väistämättä vesiputousmaiseen sykliin, jossa kierrokset ovat lyhempiä kuin varsinaisessa vesiputousmallissa(kuva 9). Kun ohjelmistoon lisätään uutta, kompleksista osaa, sitä ei saada valmiiksi ketterien periaatteiden mukaan yhdessä iteraatiossa, vaan se vie ainakin 5 6 kierrosta. Kuva 9. Vesiputousmainen sykli, Kuva 10. Komponenttiajattelu johon komponenttiajattelu johtaa ohjelmistokehityksessä (Larman& Vodde 2008). (Larman& Vodde 2008). 6.2 Feature Team Feature Team pyrkii toimimaan kuten oikein toimiva Scrum-ryhmä. Se pystyy tekemään kaiken työn saadakseen tehtyä Product Backlogista kokonaisen taskin. Tavoitteena on toimia kaikkien järjestelmän moduulien alueella ja tuottaa sellaisenaan käyttökelpoista toiminnallisuutta (kuva 11). Feature Team antaa mahdollisuuden jättää vaatimukset, suunnittelun, ohjelmoinnin sekä testaamisen ryhmän vastuulle toisin kuin Component Teamissa. Tällä saavutetaan parempi näkyvyys asiakkaalle ja huomattavasti yksinkertaistunut prosessi. Tällainen rakenne myös kannustaa Scrumin kannalta tärkeään uuden oppimiseen. Projekteissa toimii samanaikaisesti monia Feature Teameja, jotka käyttävät samoja komponentteja. Siksi on tärkeää, että koodi on hyvälaatuista ja että sitä refraktoroidaan ja integroidaan jatkuvasti. Yksikkötestit ovat tehokas tapa varmistaa järjestelmän toimivuus.

23 21 Kuva 11. Feature Teamin toiminta (Larman & Vodde 2008). Feature Team sisältää myös monia haasteita ratkaistavaksi. Näitä ovat seuraavat (Larman & Vodde 2008): Laajenneet taidot ja tuotetietämys Feature Teamilla on työalueenaan koko ohjelmisto ja sen komponentit. Tämä vaatii suuren määrän tietämystä ja halua oppia. Luonnollisesti jokaisen ei tarvitse tuntea koko järjestelmää, vaan tuotteen omistaja etsii sopivimman ryhmän luomaan uuden ominaisuuden. Jos aikaa on käytettävissä paljon, on myös mahdollista antaa ominaisuus sellaiselle ryhmälle, jolla ei ole asiasta tietämystä mutta jolla on kiinnostusta ja pohjatietoa. On normaalia, että ryhmillä on oma erikoistumisalueensa. Samanaikainen pääsy ohjelmakoodiin Koska ohjelmistoa kehittäviä ryhmiä on monia ja kaikilla on pääsy koko järjestelmän alueelle, eteen tulee tilanne, jossa yhtä komponenttia muokkaa moni eri taho. Tähän haasteeseen apua tuovat monet uudet työkalut. Tärkeä osa ratkaisua on jatkuva integraatio, jolla varmistetaan, että ohjelmisto pysyy toimivana. Jaettu vastuu suunnittelusta Komponenttiajattelussa on olemassa ryhmä, joka vastaa omasta alueestaan ja samalla sen suunnittelusta. Feature Teameilla taas muokataan jatkuvasti eri komponentteja. Jatkuva integraatio toimii tässäkin. Ohjelmisto kannattaa kääntää automatisoidusti useaan kertaan päivässä. Näin päästään hajottamaan suuret kokonaisuudet pieniin osiin ja seurattavuus paranee.

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

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

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

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

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

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

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

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

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

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

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

Ohjelmistoprojektien hallinta Vaihejakomallit

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

Lisätiedot

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

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

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

Lisätiedot

Työkalut ohjelmistokehityksen tukena

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

Lisätiedot

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

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

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

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

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

Lisätiedot

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

Hajautettu Ohjelmistokehitys

Hajautettu Ohjelmistokehitys Hajautettu Ohjelmistokehitys Maria Paasivaara Hajautuksen muotoja Yrityksen sisäinen hajautus Maan sisällä Maiden välillä, esim. offshore Yritysten välinen hajautus Alihankinta Lisenssointi Partnershipit

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

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

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

Lisätiedot

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

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

Lisätiedot

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

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD)

TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) TT00AA12-2016 - Ohjelmoinnin jatko (TT10S1ECD) Ohjelmointikäytännöt 21/3/11 Mikko Vuorinen Metropolia Ammattikorkeakoulu 1 Sisältö 1) Mitä on hyvä koodi? 2) Ohjelmointikäytäntöjen merkitys? 3) Koodin asettelu

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

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

Tapaustutkimus: Soveltuuko Scrum vesiputousmallin korvaajaksi yrityksen sovelluskehitysprojekteihin?

Tapaustutkimus: Soveltuuko Scrum vesiputousmallin korvaajaksi yrityksen sovelluskehitysprojekteihin? Markus Ahonen Tapaustutkimus: Soveltuuko Scrum vesiputousmallin korvaajaksi yrityksen sovelluskehitysprojekteihin? Elektroniikan, tietoliikenteen ja automaation tiedekunta Automaatio- ja systeemitekniikan

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

Millainen on onnistunut ICT-projekti?

Millainen on onnistunut ICT-projekti? Millainen on onnistunut ICT-projekti? Ohjelmistotuotannon lehtori Tero Tensu Ahtee Ohjelmistotekniikan laitoksella 1990- Projektityö-kurssilla 1991- pesunkestävä yliopistohampuusi ei päivääkään oikeissa

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

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

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

TARKASTUSMENETTELYT JA NIIDEN APUVÄLINETUKI

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

Lisätiedot

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

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

Lisätiedot

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu TESTIRAPORTTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001 Tekijä:

Lisätiedot

Projektisalkun kehittäminen - kilpailuetua toimituksiin projektisalkulla. Projektisalkku ohjausvälineenä. Projektisalkun kehittäminen

Projektisalkun kehittäminen - kilpailuetua toimituksiin projektisalkulla. Projektisalkku ohjausvälineenä. Projektisalkun kehittäminen Projektisalkun kehittäminen - kilpailuetua toimituksiin projektisalkulla Projektisalkku ohjausvälineenä Projektisalkun kehittäminen Kilpailukyvyn parantaminen PLUS Akatemia Projektitoiminnan ja -johtamisen

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

Ohjelmistoprosessi aloittavassa ohjelmistoyrityksessä

Ohjelmistoprosessi aloittavassa ohjelmistoyrityksessä Ohjelmistoprosessi aloittavassa ohjelmistoyrityksessä Mika Kuikka 24.5.2008 Joensuun yliopisto Tietojenkäsittelytiede Pro gradu -tutkielma Tiivistelmä Ohjelmistoprosessi määrittää, minkä vaiheiden ja tehtävien

Lisätiedot

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

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

Lisätiedot

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

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

Ohjelmistotekniikka - Luento 2 Jouni Lappalainen

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

Lisätiedot

Ohjelmiston testaus ja laatu. Testaustasot

Ohjelmiston testaus ja laatu. Testaustasot Ohjelmiston testaus ja laatu Testaustasot Testauksen vaihejako Tarpeet / sopimus Järjestelmätestaus Hyväksymiskoe Määrittely testauksen suunnittelu ja tulosten verifiointi Arkkitehtuurisuunnittelu Moduulisuunnittelu

Lisätiedot

JReleaser Yksikkötestaus ja JUnit. Mikko Mäkelä 6.11.2002

JReleaser Yksikkötestaus ja JUnit. Mikko Mäkelä 6.11.2002 JReleaser Yksikkötestaus ja JUnit Mikko Mäkelä 6.11.2002 Sisältö Johdanto yksikkötestaukseen JUnit yleisesti JUnit Framework API (TestCase, TestSuite) Testien suorittaminen eri työkaluilla Teknisiä käytäntöjä

Lisätiedot

PROJEKTINHALLINTA SCRUMIN AVULLA

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

Lisätiedot

Onnistunut Vaatimuspohjainen Testaus

Onnistunut Vaatimuspohjainen Testaus Onnistunut Vaatimuspohjainen Testaus Kari Alho Solution Architect Nohau Solutions, Finland Sisältö Mitä on vaatimuspohjainen testaus? Vaatimusten ymmärtämisen haasteet Testitapausten generointi Työkalujen

Lisätiedot

Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg

Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg Testauksen hallintaa teekkareille (ja muille kiinnostuneille) Arto Stenberg Symbio lyhyesti Innovatiivinen tuotekehitys- ja testauskumppani Juuret Suomessa, perustettu 1997 Laadukkaat ohjelmistotoimitukset

Lisätiedot

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

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

Lisätiedot

@Tampereen Testauspäivät (2012-06)

@Tampereen Testauspäivät (2012-06) @Tampereen Testauspäivät (2012-06) Testausodotukset räätälöityjen järjestelmien projekteissa Maaret Pyhäjärvi, testausasiantuntija Twitter: maaretp Testausvastaava @ Granlund Oy Yrittäjä

Lisätiedot

7. Iteratiivinen ohjelmistokehitys

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

Lisätiedot

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

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

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

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

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO

Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Jussi Klemola 3D- KEITTIÖSUUNNITTELUOHJELMAN KÄYTTÖÖNOTTO Opinnäytetyö KESKI-POHJANMAAN AMMATTIKORKEAKOULU Puutekniikan koulutusohjelma Toukokuu 2009 TIIVISTELMÄ OPINNÄYTETYÖSTÄ Yksikkö Aika Ylivieska

Lisätiedot

Kokonaisvaltainen mittaaminen ohjelmistokehityksen tukena

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

Lisätiedot

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T-76.115 Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tämä on dokumentti esittelee tietokonegrafiikkaalgoritmien visualisointijärjestelmän kehitysprojektissa käytettävän vaatimustenhallintamenetelmän. Päivämäärä

Lisätiedot

LCI Finland vuosipäivä 2013. Mitä on Lean Construction?

LCI Finland vuosipäivä 2013. Mitä on Lean Construction? LCI Finland vuosipäivä 2013 Mitä on Lean Construction? Lean Construction Lean Construction is not just another specific approach to construction, but rather a challenger of the conventional understanding

Lisätiedot

SCRUM- JA XP-KÄYTÄNTEIDEN KÄYTTÖ: HAASTATTELUTUTKIMUS

SCRUM- JA XP-KÄYTÄNTEIDEN KÄYTTÖ: HAASTATTELUTUTKIMUS Hanna Kuirinlahti SCRUM- JA XP-KÄYTÄNTEIDEN KÄYTTÖ: HAASTATTELUTUTKIMUS Tietojärjestelmätieteen pro gradu tutkielma 1.11.2011 Jyväskylän yliopisto Tietojenkäsittelytieteiden laitos Jyväskylä 1 TIIVISTELMÄ

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

Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi

Luku 8 Rakennusvaihe. Detailed Design. Programming. Moduulisuunnittelu. Ohjelmointi Luku 8 Rakennusvaihe Moduulisuunnittelu Detailed Design Programming Ohjelmointi Teknisen Complete suunnittelun Technical viimeistely Design Suunnittelukatselmuksen Design Perform suorittaminen Review Yhteisen

Lisätiedot

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

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

Lisätiedot

Testausta vai määrittelyä? Hyväksymistestaus ja jatkuva integraatio ketterässä ohjelmistokehityksessä

Testausta vai määrittelyä? Hyväksymistestaus ja jatkuva integraatio ketterässä ohjelmistokehityksessä Testausta vai määrittelyä? Hyväksymistestaus ja jatkuva integraatio ketterässä ohjelmistokehityksessä Public 27.10.2008 Ixonos Oyj Juha Inkinen Työnantaja: Ixonos marraskuusta 2007, sitäennen Nokia Networks

Lisätiedot

Advanced Test Automation for Complex Software-Intensive Systems

Advanced Test Automation for Complex Software-Intensive Systems Advanced Test Automation for Complex Software-Intensive Systems Aiheena monimutkaisten ohjelmistovaltaisten järjestelmien testauksen automatisointi Mistä on kyse? ITEA2-puiteohjelman projekti: 2011-2014

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

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

TOIMINNALLINEN MÄÄRITTELY- DOKUMENTTI KETTERÄSTI

TOIMINNALLINEN MÄÄRITTELY- DOKUMENTTI KETTERÄSTI OPINNÄYTETYÖ TIINA MÄÄTTÄ 2010 PIRKKO RAUTIO 2010 TOIMINNALLINEN MÄÄRITTELY- DOKUMENTTI KETTERÄSTI TIETOJENKÄSITTELYN KOULUTUSOHJELMA ROVANIEMEN AMMATTIKORKEAKOULU LUONNONTIETEIDEN ALA Tietojenkäsittelyn

Lisätiedot

OHJELMISTOPROJEKTINHALLINNAN KEHITTÄMINEN SCRUM-MENETELMÄLLÄ

OHJELMISTOPROJEKTINHALLINNAN KEHITTÄMINEN SCRUM-MENETELMÄLLÄ OHJELMISTOPROJEKTINHALLINNAN KEHITTÄMINEN SCRUM-MENETELMÄLLÄ Panu Vuori Opinnäytetyö Kesäkuu 2014 Automaatioteknologian koulutusohjelma YAMK Tekniikan ja liikenteen ala KUVAILULEHTI Tekijä(t) VUORI, Panu

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

Reilun Pelin työkalupakki: Kiireen vähentäminen

Reilun Pelin työkalupakki: Kiireen vähentäminen Reilun Pelin työkalupakki: Kiireen vähentäminen Tavoitteet Tämän toimintamallin avulla opit määrittelemään kiireen. Työyhteisösi oppii tunnistamaan toistuvan, kuormittavan kiireen sekä etsimään sen syitä

Lisätiedot

VIRTAUSTEHOKKUUDEN LISÄÄMINEN PATOLOGIAN LABORATORIOSSA

VIRTAUSTEHOKKUUDEN LISÄÄMINEN PATOLOGIAN LABORATORIOSSA VIRTAUSTEHOKKUUDEN LISÄÄMINEN PATOLOGIAN LABORATORIOSSA Mikko Laiho 6.2.2015 TEHOKKUUSMATRIISI LEAN ON TÄHDEN TAVOITTELUA VAIHTELUA VÄHENTÄMÄLLÄ RESURSSITEHOKKUUS VIRTAUSTEHOKKUUS Vaihtelu Voi syntyä mm.

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

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

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

Lisätiedot

Reilun Pelin työkalupakki: Työkäytäntöjen kehittäminen

Reilun Pelin työkalupakki: Työkäytäntöjen kehittäminen Reilun Pelin työkalupakki: Työkäytäntöjen kehittäminen Tavoite Oppia menetelmä, jonka avulla työyhteisöt voivat yhdessä kehittää työkäytäntöjään. Milloin työkäytäntöjä kannattaa kehittää? Työkäytäntöjä

Lisätiedot

Agile. Jyväskylän Yliopisto Sivu 1 Tietotekniikan laitos

Agile. Jyväskylän Yliopisto Sivu 1 Tietotekniikan laitos Agile Jyväskylän Yliopisto Sivu 1 Tietotekniikan laitos Manifesto of Agile Software Development (2001): We are uncovering better ways of developing software by doing it and helping others do it. Through

Lisätiedot

Kokonaisarkkitehtuuri. Kankaanpään kaupunki

Kokonaisarkkitehtuuri. Kankaanpään kaupunki Kokonaisarkkitehtuuri Kankaanpään kaupunki Kokonaisarkkitehtuuri johtamisvälineenä Kankaanpään strategia 2015 Avoimmuus Edistävä johtajuus Luovuus Jatkuva kehittyminen Tehokkuus Vetovoimaisuus Kilpailukyky

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

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

Extreme Programming. Harri Lindberg. Tampereen yliopisto Tietojenkäsittelytieteiden laitos Tietojenkäsittelyoppi Pro gradu -tutkielma Joulukuu 2003.

Extreme Programming. Harri Lindberg. Tampereen yliopisto Tietojenkäsittelytieteiden laitos Tietojenkäsittelyoppi Pro gradu -tutkielma Joulukuu 2003. Extreme Programming Harri Lindberg Tampereen yliopisto Tietojenkäsittelytieteiden laitos Tietojenkäsittelyoppi Pro gradu -tutkielma Joulukuu 2003. ii Tampereen yliopisto Tietojenkäsittelytieteiden laitos

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

Hyvän johtamisen kriteerit julkiselle sektorille: Hyvällä johtamisella hyvään työelämään

Hyvän johtamisen kriteerit julkiselle sektorille: Hyvällä johtamisella hyvään työelämään Hyvän johtamisen kriteerit julkiselle sektorille: Hyvällä johtamisella hyvään työelämään 8.5.2014 MARJUKKA LAINE, TYÖTERVEYSLAITOS 0 Verkoston lähtökohta ja tehtävät Hallitusohjelma 2011: Perustetaan Työterveyslaitoksen

Lisätiedot

Toteutusvaihe T2 Edistymisraportti

Toteutusvaihe T2 Edistymisraportti Toteutusvaihe T2 Edistymisraportti Sisällysluettelo 1. Projektin tila...3 1.1. Suoritetut tehtävät...4 1.2. Käytetyt menetelmät...5 1.3. Ongelmat...6 1.4. Jatkosuunnitelmat...6 Versio- ja muutoshistoria

Lisätiedot

Palvelutoimisto. Prosessit ja ihmiset rokkaamaan yhdessä. itsmf TOP10 @Kalastajatorppa 3.-4.10.2013 Hanna Nyéki-Niemi ja Mika Lindström 3.10.

Palvelutoimisto. Prosessit ja ihmiset rokkaamaan yhdessä. itsmf TOP10 @Kalastajatorppa 3.-4.10.2013 Hanna Nyéki-Niemi ja Mika Lindström 3.10. Palvelutoimisto Prosessit ja ihmiset rokkaamaan yhdessä itsmf TOP10 @Kalastajatorppa 3.-4.10.2013 Hanna Nyéki-Niemi ja Mika Lindström 3.10.2013 Keitä olemme? Mika Lindström Hanna Nyéki-Niemi Ei anneta

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

KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti

KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI. Kehitysvammaliitto / Hyvät käytännöt -projekti 1 KEHITYSVAMMAISTEN PALVELUJEN HYVÄT KÄYTÄNNÖT OHJEET KÄYTÄNNÖN KUVAAMISEKSI Kehitysvammaliitto / Hyvät käytännöt -projekti 2 Tuotetaan käytännöstä tietoa yhdessä Käytännön kuvaamisen tarkoituksena on

Lisätiedot

Laadunhallinta ketterissä menetelmissä

Laadunhallinta ketterissä menetelmissä Lappeenrannan teknillinen yliopisto Tietotekniikan osasto Kandidaatintyö Laadunhallinta ketterissä menetelmissä Työn ohjaaja ja tarkastaja: Tekniikan tohtori Ossi Taipale Lappeenranta, 26.08.2008 Vesa

Lisätiedot

Ketterät menetelmät ja laadunhallinta

Ketterät menetelmät ja laadunhallinta Lappeenrannan teknillinen yliopisto Tietotekniikan osasto Kandidaatintyö Ketterät menetelmät ja laadunhallinta Työn ohjaaja ja tarkastaja: prof. Kari Smolander Lappeenranta, 6.12.2011 Jesse Yli-Huumo Orioninkatu

Lisätiedot

ASKELMERKKIÄ TULOKSELLISEEN HANKEVIESTINTÄÄN

ASKELMERKKIÄ TULOKSELLISEEN HANKEVIESTINTÄÄN Business Arena 10 ASKELMERKKIÄ TULOKSELLISEEN HANKEVIESTINTÄÄN Opas hankkeiden tuloskortin hyödyntämiseen versio 6/2014 Business Arena Hankkeiden tuloskortti on rakennerahastohankkeiden parissa toimivien

Lisätiedot

Tietojärjestelmän kehittäminen syksy 2003

Tietojärjestelmän kehittäminen syksy 2003 Tietojärjestelmän kehittäminen syksy 2003 Ryhmä C2 Väliraportti 2-24.10. Päivi Laiterla Tomas Windahl Toni Nikkanen Antti Lehto 1 Sisällysluettelo Rich Picture...4 Käsitemalli...5 P-tason

Lisätiedot

Yhteisöllisyyden toteuttaminen verkko-opetuksessa

Yhteisöllisyyden toteuttaminen verkko-opetuksessa Liiketoiminta kehittyy kehity sinäkin. Yhteisöllisyyden toteuttaminen verkko-opetuksessa Tieturi Oy / Arja Sipola HTC Santa Maria, Tammasaarenkatu 5, 00180 Helsinki, Finland www.tieturi.fi (09) 431 551

Lisätiedot

Arviointi ja palaute käytännössä

Arviointi ja palaute käytännössä Arviointi ja palaute käytännössä Merja Ellilä Arvioinnista Oppimista ohjaavan arvioinnin merkitys ohjattavan oppimisen tukemista ja suuntaamista tietojen, taitojen ja asenteiden arvioimista ohjattavan

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

Tinkauspaja 1 Sali LS 2. Ketterä oppiminen

Tinkauspaja 1 Sali LS 2. Ketterä oppiminen Tinkauspaja 1 Sali LS 2 Ketterä oppiminen Tinkauspajan sisältö Johdanto: Ketterä oppiminen kokemuksia Ketterän oppimisen edellytyksiä, ryhmätyöt Millaisia taitoja ihmiset tarvitsevat kyetäkseen oppimaan

Lisätiedot

Verkostojen tehokas tiedonhallinta

Verkostojen tehokas tiedonhallinta Tieto Corporation Verkostojen tehokas tiedonhallinta Value Networks 3.9.2014 Risto Raunio Head of Lean System Tieto, Manufacturing risto.raunio@tieto.com Sisältö Mihin verkostoitumisella pyritään Verkoston

Lisätiedot

Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883

Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883 itsmf Finland Conference 2013 TOP10 The Sounds of IT Service Management Palvelunhallinta monitoimittajaympäristössä Sami Merovuo, Service Manager, HiQ Finland Oy sami.merovuo@hiq.fi, +358 45 133 5883 #monitoimittajaympäristö

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