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.

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

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

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

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

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

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

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

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

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

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

Test-Driven Development

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

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

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

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

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

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

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

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

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

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

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

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

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia

Ohjelmistojen mallintaminen, kurssikoe esimerkkivastauksia Ohjelmistojen mallintaminen, kurssikoe 15.12. esimerkkivastauksia Tehtävä 1 a: Ohjelmistotuotantoprosessi sisältää yleensä aina seuraavat vaiheet: määrittely, suunnittelu, toteutus, testaus ja ylläpito.

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

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

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

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

Ohjelmistotuotteen hallinnasta

Ohjelmistotuotteen hallinnasta Ohjelmistotuotteen hallinnasta Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Haikala ja Märijärvi, Ohjelmistotuotanto Royce, Software Project Management, A Unified Framework 1 Tavoitteista

Lisätiedot

LAATURAPORTTI Iteraatio 1

LAATURAPORTTI Iteraatio 1 LAATURAPORTTI Iteraatio 1 LAATURAPORTTI 2 (7) VERSION HALLINTA Versio Päivä Tekijä Kuvaus 0.1 9.12.2006 Kaarlo Lahtela Ensimmäinen versio 0.2 Kaarlo Lahtela Korjauksia 1.0 Lauri Kiiski Katselmointi ja

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

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

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

Hyvällä johtamisella hyvään työelämään Paasitorni, Paula Risikko, sosiaali- ja terveysministeri

Hyvällä johtamisella hyvään työelämään Paasitorni, Paula Risikko, sosiaali- ja terveysministeri Hyvällä johtamisella hyvään työelämään Paasitorni, 10.12.2013 Paula Risikko, sosiaali- ja terveysministeri 1 Johtamisverkosto selvittää, kokoaa, kehittää ja jakaa johtamisen ja esimiestyön hyviä käytäntöjä

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

Testausoppeja toimialavaihdoksesta

Testausoppeja toimialavaihdoksesta Testausoppeja toimialavaihdoksesta Maaret Pyhäjärvi Email: Gsm: 040-8233777 Erkki Pöyhönen & Maaret Pyhäjärvi Nimeä Attribution (Finland) http://creativecommons.org/licenses/by/1.0/fi/

Lisätiedot

Testilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi

Testilähtöinen ohjelmistokehitys. Testilähtöinen ohjelmistokehitys. TDD Testilähtöinen ohjelmistokehitys. Testi! Testi Testilähtöinen ohjelmistokehitys Kevät 2008 Jonne Itkonen Jyväskylän yliopisto Testilähtöinen ohjelmistokehitys Test-Driven Development, TDD Tehdään ensin testi, sitten vasta koodi. TDD Testilähtöinen

Lisätiedot

Projektin suunnittelu. Pienryhmäopetus - 71A00300

Projektin suunnittelu. Pienryhmäopetus - 71A00300 Projektin suunnittelu Pienryhmäopetus - 71A00300 Projektikanvaasi Mikä on projektikanvaasi? Visuaalinen työkalu projektitiimille, joka helpottaa projektin suunnittelussa ja projektin tavoitteiden kommunikaatiossa

Lisätiedot

YRITTÄJÄTESTIN YHTEENVETO

YRITTÄJÄTESTIN YHTEENVETO YRITTÄJÄTESTIN YHTEENVETO Alla oleva kaavio kuvastaa tehdyn testin tuloksia eri osa-alueilla. Kaavion alla on arviot tilanteestasi koskien henkilökohtaisia ominaisuuksiasi, kokemusta ja osaamista, markkinoita

Lisätiedot

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant

dokumentin aihe Dokumentti: Testausraportti_I1.doc Päiväys: Projekti : AgileElephant AgilElephant Testausraportti I1 Tekijä: Petri Kalsi Omistaja: ElectricSeven Aihe: Testausraportti Sivu 1 / 5 Dokumentti Historia Muutoshistoria Revision Numero Revision Päiväys Yhteenveto muutoksista Revision

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

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

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

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori

TIE Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2. Antti Jääskeläinen Matti Vuori TIE-21204 Ohjelmistojen testaus 2015 Harjoitustyö Vaiheet 1 ja 2 Antti Jääskeläinen Matti Vuori Työn yleiset järjestelyt 14.9.2015 2 Valmistautuminen Ilmoittaudu kurssille Lue harjoitustyön nettisivut

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

Rakennusautomaation käytettävyys. Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT

Rakennusautomaation käytettävyys. Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT Rakennusautomaation käytettävyys Rakennusautomaatioseminaari 30.5.2013 Sami Karjalainen, VTT 2 Oma tausta Perusinsinööri DI, lvi-tekniikka, TKK 1993 Herääminen käytettävyysasioihin noin 2002 Tekniikan

Lisätiedot

Harjoitustyön testaus. Juha Taina

Harjoitustyön testaus. Juha Taina Harjoitustyön testaus Juha Taina 1. Johdanto Ohjelman teko on muutakin kuin koodausta. Oleellinen osa on selvittää, että ohjelma toimii oikein. Tätä sanotaan ohjelman validoinniksi. Eräs keino validoida

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

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } }

Yksikkötestaus. import org.junit.test; public class LaskinTest public void testlaskimenluonti() { Laskin laskin = new Laskin(); } } Yksikkötestauksella tarkoitetaan lähdekoodiin kuuluvien yksittäisten osien testaamista. Termi yksikkö viittaa ohjelman pienimpiin mahdollisiin testattaviin toiminnallisuuksiin, kuten olion tarjoamiin metodeihin.

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

Kohti Kohaa avoimen lähdekoodin kirjastojärjestelmän käyttöönotto

Kohti Kohaa avoimen lähdekoodin kirjastojärjestelmän käyttöönotto Kohti Kohaa avoimen lähdekoodin kirjastojärjestelmän käyttöönotto Virpi Launonen Kirjastotoimenjohtaja Mikkelin kaupunginkirjasto Etelä-Savon maakuntakirjasto Yleistä OKM rahoittanut lokalisoinnin, Joensuun

Lisätiedot

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testaussuunnitelma. Koskelo. Helsinki Ohjelmistotuotantoprojekti. HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testaussuunnitelma Koskelo Helsinki 16.12.2004 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Tom Bertell Johan

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

Järjestelmän kriittisimmille toiminnallisuuksille (listattu alla), toteutetaan 1

Järjestelmän kriittisimmille toiminnallisuuksille (listattu alla), toteutetaan 1 1. Testattavat asiat Järjestelmän kriittisimmille toiminnallisuuksille (listattu alla), toteutetaan 1 selainyhteensopivuustesti käyttäen Suomessa eniten käytössä olevia selaimia. Uuden keräyksen lisääminen

Lisätiedot

Torstai Mikkeli

Torstai Mikkeli Torstai 14.2.2013 Mikkeli OSUVA (2012 2014) - Osallistuva innovaatiotoiminta ja sen johtamista edistävät tekijät sosiaali- ja terveydenhuollossa. hanke tutkii minkälaisilla innovaatiojohtamisen toimintatavoilla

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

L U PA TE HDÄ FIKS UM M IN

L U PA TE HDÄ FIKS UM M IN Joustavasti ja avoimesti uuteen toimintakulttuuriin L U PA TE HDÄ FIKS UM M IN Marika Tammeaid Kehityspäällikkö, Valtion henkilöstöjohtamisen tuki, Valtiokonttori #Työ2.0 Klassikot uudessa valossa Kohti

Lisätiedot

2. Ohjelmistotuotantoprosessi

2. Ohjelmistotuotantoprosessi 2. Ohjelmistotuotantoprosessi Peruskäsitteet: prosessimalli: mahdollisimman yleisesti sovellettavissa oleva ohjeisto ohjelmistojen tuottamiseen ohjelmistotuotantoprosessi: yrityksessä käytössä oleva tapa

Lisätiedot

PROJEKTIN SUDENKUOPAT. f JOUNI HUOTARI PÄIVITETTY

PROJEKTIN SUDENKUOPAT. f JOUNI HUOTARI PÄIVITETTY PROJEKTIN SUDENKUOPAT f JOUNI HUOTARI PÄIVITETTY 18.1.2011 TEHTÄVÄ Mitä sudenkuoppia esiintyy projektin eri prosesseissa (vaiheissa)? Miten ne voitaisiin välttää? Jouni Huotari 19.3.2012 2 Sudenkuoppia

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

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen

A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen 1 AS-0.3200 Automaatio- ja systeemitekniikan projektityöt A14-11 Potilaan mittaustiedon siirtäminen matkapuhelimeen Projektisuunnitelma Tommi Salminen, Hanna Ukkola, Olli Törmänen 19.09.2014 1 Projektin

Lisätiedot

Työkalut innovoinnin tehostamiseen valmiina käyttöösi. Microsoft SharePoint ja Project Server valmiina vastaamaan organisaatioiden haasteisiin

Työkalut innovoinnin tehostamiseen valmiina käyttöösi. Microsoft SharePoint ja Project Server valmiina vastaamaan organisaatioiden haasteisiin Työkalut innovoinnin tehostamiseen valmiina käyttöösi Microsoft SharePoint ja Project Server valmiina vastaamaan organisaatioiden haasteisiin Terve! Pieni, nopea kysely kiitos! Lyhyt katsaus osallistujiin

Lisätiedot

Menetelmäraportti Ohjelmakoodin tarkastaminen

Menetelmäraportti Ohjelmakoodin tarkastaminen Menetelmäraportti Ohjelmakoodin tarkastaminen Sisällysluettelo 1. Johdanto...3 2. Menetelmän kuvaus...4 2.1. Tarkastusprosessi...4 2.1.1. Suunnittelu...4 2.1.2. Esittely...5 2.1.3. Valmistautuminen...5

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

SOVELLUSPROJEKTIN ARVIOINTILOMAKE

SOVELLUSPROJEKTIN ARVIOINTILOMAKE SOVELLUSPROJEKTIN ARVIOINTILOMAKE Arviointilomake on tarkoitettu Sovellusprojektin vastaavan ohjaajan arvioinnin tueksi, eikä sillä siten tule korvata erillistä projektilausuntoa. Useaa arviointikohtaa

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

Tulevaisuuden näkökulmia tietoyhteiskuntavalmiuksiin

Tulevaisuuden näkökulmia tietoyhteiskuntavalmiuksiin 1 Tulevaisuuden näkökulmia tietoyhteiskuntavalmiuksiin Päivi Häkkinen PERUSOPETUS 2020 Tietoyhteiskuntavalmiudet 18.3.2010, Opetushallitus, Helsinki 2 Millaista osaamista tulevaisuudessa tarvitaan ja halutaan

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

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

voimavaroja. Kehittämishankkeen koordinaattori tarvitsee aikaa hankkeen suunnitteluun ja kehittämistyön toteuttamiseen. Kehittämistyöhön osallistuvill

voimavaroja. Kehittämishankkeen koordinaattori tarvitsee aikaa hankkeen suunnitteluun ja kehittämistyön toteuttamiseen. Kehittämistyöhön osallistuvill Niemi, Petri. 2006. Kehittämishankkeen toteuttaminen peruskoulussa toimintatutkimuksellisen kehittämishankkeen kuvaus ja arviointi. Turun yliopiston kasvatustieteellisen tiedekunnan lisensiaatintutkimus.

Lisätiedot

Vertaispalaute. Vertaispalaute, /9

Vertaispalaute. Vertaispalaute, /9 Vertaispalaute Vertaispalaute, 18.3.2014 1/9 Mistä on kyse? opiskelijat antavat palautetta toistensa töistä palaute ei vaikuta arvosanaan (palautteen antaminen voi vaikuttaa) opiskelija on työskennellyt

Lisätiedot

E-kirjan kirjoittaminen

E-kirjan kirjoittaminen 1 E-kirjan kirjoittaminen Ohjeet e-kirjan kirjoittamiseen Tämän ohjeistuksen tavoitteena on auttaa sinua luomaan yksinkertainen e-kirja (pdftiedosto) asiakkaallesi. Kirja näyttää hänelle kuinka hyvin ymmärrät

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

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

Ohjelmistotekniikka - Luento 3 Jouni Lappalainen

Ohjelmistotekniikka - Luento 3 Jouni Lappalainen Ohjelmistotekniikka - Luento 3 Jouni Lappalainen Luku 3: Ketterä kehitys - ketterien menetelmien 12 periaatetta - XP (extreme programming) - Scrum menetelmä - Lean menetelmä 1 Luku 3: Ketterä kehittäminen

Lisätiedot

Oppiminen ja oivaltaminen

Oppiminen ja oivaltaminen Oppiminen ja oivaltaminen Pohdittavaa Kuinka hyvä lapsestasi tulee, jos opetat hänelle kaiken sen mitä jo osaat? Riittääkö tämä lapselle? Kuinka hyvä pelaajasta tulee 2025, jos hän tekee kaiken sen, mitä

Lisätiedot

KUNTO Muutoksen seurantakysely

KUNTO Muutoksen seurantakysely KUNTO Muutoksen seurantakysely Muutoksen seurantakyselyn tavoitteena on auttaa organisaation johtoa seuraamaan muutosprosessia ja arvioimaan sen vaikutuksia. Kysely tarjoaa henkilöstölle mahdollisuuden

Lisätiedot

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä

$$$ Raha ratkaisee. $$$ Raha ratkaisee. Ohjelmistotuote. Ohjelmistotekniikan määritelmä $$$ Raha ratkaisee On vaara rakastua tekniikkaan, myös asiakkailla Kaikki pitää pystyä perustelemaan taloudellisesti Projektin toteutus yleensä -> voidaan jättää toteuttamatta, jos ei maksa itseään takaisin

Lisätiedot

Verkkokoulutus ja uuden oppimiskulttuurin luominen. TieVie-kouluttajakoulutus Helsinki Pirjo Ståhle

Verkkokoulutus ja uuden oppimiskulttuurin luominen. TieVie-kouluttajakoulutus Helsinki Pirjo Ståhle Verkkokoulutus ja uuden oppimiskulttuurin luominen TieVie-kouluttajakoulutus Helsinki 8.11.2002 Pirjo Ståhle Organisaation tieto- ja toimintaympäristöt Suhteet avoin tiedonvaihto mekaaninen orgaaninen

Lisätiedot

Opiskelijat valtaan! TOPIC MASTER menetelmä lukion englannin opetuksessa. Tuija Kae, englannin kielen lehtori Sotungin lukio ja etälukio

Opiskelijat valtaan! TOPIC MASTER menetelmä lukion englannin opetuksessa. Tuija Kae, englannin kielen lehtori Sotungin lukio ja etälukio Opiskelijat valtaan! TOPIC MASTER menetelmä lukion englannin opetuksessa Tuija Kae, englannin kielen lehtori Sotungin lukio ja etälukio Päättääkö opettaja ohjelmasta? Vai voisivatko opiskelijat itse suunnitella

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

Miksipä Benchmarking?

Miksipä Benchmarking? Esityksen sisälmykset Miksipä Benchmarking? 1. yleistä (so. korkealentoista) benchmarkingista 2. kokemuksia yhdestä yritelmästä TieVie-asiantuntijakoulutus Turun lähiseminaari 18.3.2005 Markku Ihonen Benchmarking

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

Tietotekniikan Sovellusprojektit

Tietotekniikan Sovellusprojektit Tietotekniikan Sovellusprojektit Jukka-Pekka Santanen Tietotekniikan laitos 16.2.2010 Tavoitteena taitoja ja kokemusta projektimuotoisesta työtavasta ja ryhmätyöstä, projektin hallinnasta ja johtamisesta,

Lisätiedot

SEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2

SEPA diary. Dokumentti: SEPA_diary_PK_RI.doc Päiväys: Projekti : AgileElephant Versio: V0.2 AgilElephant SEPA Diary Pasi Kallioniemi 49477B Rauli Ikonen 51051V Tekijä: Kallioniemi&Ikonen Omistaja: ElectricSeven Aihe: RI & PK Sivu 1 of 7 Dokumenttihistoria Muutoshistoria Revision päiväys: 1.11.2004

Lisätiedot

TITANIC TEMPPU, vaan ei karille

TITANIC TEMPPU, vaan ei karille TITANIC TEMPPU, vaan ei karille Mikko Mäkelä Tuomo Rintamäki 17/10/10 Helsinki Metropolia University of Applied Sciences 1 Metropolia- ammattikorkeakoulusta Suomen suurin ammattikorkeakoulu, joka aloitti

Lisätiedot

TOPSIDE. Opas taustatuelle. Koulutusta kehitysvammaisille vertaistukijoille Euroopassa. www.peer-training.eu. Inclusion Europe

TOPSIDE. Opas taustatuelle. Koulutusta kehitysvammaisille vertaistukijoille Euroopassa. www.peer-training.eu. Inclusion Europe TOPSIDE Koulutusta kehitysvammaisille vertaistukijoille Euroopassa Opas taustatuelle Inclusion Europe www.peer-training.eu Tekijät: TOPSIDE kumppanit Hugh Savage, ENABLE Skotlanti Petra Nováková, Inclusion

Lisätiedot

Uusia näkökulmia riskienhallintaan ja toiminnan kehittämiseen

Uusia näkökulmia riskienhallintaan ja toiminnan kehittämiseen Uusia näkökulmia riskienhallintaan ja toiminnan kehittämiseen Juuso Kanner, Founder Celkee Oy Projektinhallintapäivä TTY:llä 20.08.2013 Celkee Oy projektijohdon ja hankinnan asiantuntija 1. Konsultointi

Lisätiedot

58160 Ohjelmoinnin harjoitustyö

58160 Ohjelmoinnin harjoitustyö 58160 Ohjelmoinnin harjoitustyö Testaus 30.3.2009 Tuntiop. Sami Nikander sami.nikander@helsinki.fi 58160 Ohjelmoinnin harjoitustyö, Sami Nikander 30.3.2009 1 Testaus Ohjelman systemaattista tutkimista

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

OpenUP ohjelmistokehitysprosessi

OpenUP ohjelmistokehitysprosessi OpenUP ohjelmistokehitysprosessi Sami Männistö Helsinki 14.11.2008 Seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos i HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET Tiedekunta/Osasto Matemaattis-luonnontieteellinen

Lisätiedot

Bimodaalisuus IT Palvelunhallinnassa Case UPM

Bimodaalisuus IT Palvelunhallinnassa Case UPM Bimodaalisuus IT Palvelunhallinnassa Case UPM Kuka on Johanna Manager, IT Service Managmement UPM:lla ja osana IT Strategy and Governance tiimiä Vastuulla Palvelunhallinnan maturiteetti UPM IT:ssä BBA

Lisätiedot

Hyvän työelämän eväät - Johtamisella vaikutetaan jaksamiseen

Hyvän työelämän eväät - Johtamisella vaikutetaan jaksamiseen Hyvän työelämän eväät - Johtamisella vaikutetaan jaksamiseen Juha Sipilä Hyvinvointia työelämään -seminaari 12.10.2013 Kaikki alkaa ajatuksesta Luomisen prosessi koostuu kolmesta osatekijästä: 1) Kaikki

Lisätiedot

SYSTEEMITYÖ. Tärkeitä sanoja

SYSTEEMITYÖ. Tärkeitä sanoja SYSTEEMITYÖ Tärkeitä sanoja SYSTEEMITYÖN TÄRKEITÄ SANOJA Laatu (itse tuotteessa ja sen tekemisessä) Dokumentaatio Riskienhallinta Vaatimustenhallinta Uudelleenkäytettävyys Versionhallinta 2 LAATU Parityönä:

Lisätiedot

Mihin tutkimuksen käyttöönotto törmää hoitotyössä?

Mihin tutkimuksen käyttöönotto törmää hoitotyössä? Mihin tutkimuksen käyttöönotto törmää hoitotyössä? Heljä Lundgrén-Laine, kehittämisylihoitaja VSSHP, post doc, Turun yliopisto, hoitotiede helja.lundgren-laine@tyks.fi +358 50 562 4374 Miksi se törmää

Lisätiedot

IPT-työpaja # Kysely kehitys- ja toteutusvaiheissa oleville hankkeille

IPT-työpaja # Kysely kehitys- ja toteutusvaiheissa oleville hankkeille IPT-työpaja #7 15-16.3 Kysely kehitys- ja toteutusvaiheissa oleville hankkeille Kyselytutkimus Tilaajan / käyttäjien edustajat 5 vastaajaa, joista: 5 APR:n jäsentä 2 projektipäällikköä 7 vastaajaa, joista:

Lisätiedot

Toimintatapa lajin urheilutoiminnan kehittämisen etenemiseen

Toimintatapa lajin urheilutoiminnan kehittämisen etenemiseen Toimintatapa lajin urheilutoiminnan kehittämisen etenemiseen Lajin urheilutoiminnan kehittäminen yleistä työkalusta taustalle LUONNOS 7.10.2016 toimintatapa lajin urheilutoiminnan kehittämiseen kuvaa 5

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

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

Paja 3, Tampere

Paja 3, Tampere Paja 3, Tampere 3.12.2015 Aikataulu 9.15-9.30 Aamukahvit 9.30-9.45 Tervetuloa 9.45-11.30 Kotitehtävän purku 11.30-12.15 Lounas 12.15-13.30 Työskentelyä 13.30-14.00 Pajojen arviointi 14.00 14.15 Kahvi 14.15-14.30

Lisätiedot

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016

CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2016 VIIME KERRALLA MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus)

Lisätiedot