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.

Ohjelmistoprojekteista. Datanomiopiskelijat 2.vuosi

Ohjelmistoprojekteista. Datanomiopiskelijat 2.vuosi Ohjelmistoprojekteista Datanomiopiskelijat 2.vuosi Yleistä projekteista Projekti on selkeästi asetettuihin tavoitteisiin pyrkivä, ajallisesti rajattu kertaluonteinen hanke, jonka toteuttamisesta vastaa

Lisätiedot

Ohjelmistojen mallintaminen. Luento 11, 7.12.

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

Lisätiedot

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

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

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

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

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

Ohjelmistotekniikka - Luento 2

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

Lisätiedot

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 14. kesäkuuta, 2018 Petri Strandén Manager Cyber Security Services Application Technologies Petri.stranden@kpmg.fi Petri vastaa KPMG:n Technology

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 1 Luento

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

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

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

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

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

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

Onnistunut ohjelmistoprojekti

Onnistunut ohjelmistoprojekti Onnistunut ohjelmistoprojekti ICT-ajankohtaisseminaari 15.4.2009 Hermanni Hyytiälä Reaktor Innovations Oy Agenda Yritysesittely Keinoja onnistuneeseen ohjelmistoprojektiin Ihmiset Menetelmät Käytännöt

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

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

KOODAAKO PROJEKTIPÄÄLLIKKÖ?

KOODAAKO PROJEKTIPÄÄLLIKKÖ? KOODAAKO PROJEKTIPÄÄLLIKKÖ? - ROOLIODOTUKSET KETTERISSÄ OHJELMISTOPROJEKTEISSA Mikko Viskari Development Manager Ohjelmistoprojektikokemusta vuodesta 2005 Teknisen projektipäällikön roolissa vuodesta 2011

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

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

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

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

Ketterien periaatteiden merkitys projektityössä

Ketterien periaatteiden merkitys projektityössä Ketterien periaatteiden merkitys projektityössä Suvi Jentze-Korpi Helsinki 18.10.2012 Kandidaatintutkielma-kurssin aine HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Sisältö i 1 Johdanto 1 2 Lineaarinen

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

Sisäänrakennettu tietosuoja ja ohjelmistokehitys

Sisäänrakennettu tietosuoja ja ohjelmistokehitys Sisäänrakennettu tietosuoja ja ohjelmistokehitys Petri Strandén 8. kesäkuuta, 2018 Agenda Ohjelmistokehitys Ohjelmistokehitys vs. konsultointi Vaatimukset Tietosuoja Tietosuoja ohjelmistokehityksessä kiteytettynä

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

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

Ketteryys pähkinänkuoressa. Kokopäivän Scrum-kurssin sisältö tislattuna ja tiivistettynä kolmeen varttiin

Ketteryys pähkinänkuoressa. Kokopäivän Scrum-kurssin sisältö tislattuna ja tiivistettynä kolmeen varttiin Ketteryys pähkinänkuoressa Kokopäivän Scrum-kurssin sisältö tislattuna ja tiivistettynä kolmeen varttiin Empiirinen prosessinhallinta Iteraatiot ja inkrementit riskienhallinnassa Imuohjaus Ketteryyden

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ön ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework

Työn ositusmalleista. Luennon tavoitteista. Motivointia. Walker Royce, Software Project Management, A Unified Framework Työn ositusmalleista Luennon tavoitteista Luennon sisällöstä Motivointia Lähteinä: Walker Royce, Software Project Management, A Unified Framework 1 Tavoitteista Luentojen jälkeen opiskelijan tulisi osata:

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

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

Projektityö

Projektityö Projektityö 21.10.2005 Projektisuunnitelma Työn ositus Projektisuunnitelman sisältö Kurssin luennoitsija ja projektiryhmien ohjaaja: Timo Poranen (email: tp@cs.uta.fi, työhuone: B1042) Kurssin kotisivut:

Lisätiedot

Alkukartoitus Opiskeluvalmiudet

Alkukartoitus Opiskeluvalmiudet Alkukartoitus Opiskeluvalmiudet Päivämäärä.. Oppilaitos.. Nimi.. Tehtävä 1 Millainen kielenoppija sinä olet? Merkitse rastilla (x) lauseet, jotka kertovat sinun tyylistäsi oppia ja käyttää kieltä. 1. Muistan

Lisätiedot

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

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

T Tietojenkäsittelyopin ohjelmatyö Tietokonegrafiikka-algoritmien visualisointi Vaatimustenhallinta

T 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

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

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

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

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

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

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

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

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

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

Projektinhallintapäivä Päivi Kähönen-Anttila

Projektinhallintapäivä Päivi Kähönen-Anttila Projektinhallintapäivä 5.6.2019 Päivi Kähönen-Anttila 1.Omistajuus Epäselvät tehtävänannot tai tehtävän osoittaminen useammalle henkilölle aiheuttaa ennen pitkää haasteita ja herättää epäluottamusta tiimin

Lisätiedot

Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky

Koekysymyksiä. Ohjelmistoprosessit ja ohjelmistojen laatu Ohjelmistojen suorituskyky Koekysymyksiä Ohjelmistoprosessit ja ohjelmistojen laatu 30.4.2015 58153003 Ohjelmistojen suorituskyky 1 Kurssikokeeseen tulee neljä koetilaisuudessa vastattavaa kysymystä KOKEESSA VASTATTAVAT KYSYMYKSET

Lisätiedot

JULKISTEN PALVELUJEN ELINKAARI; HYVÄ PALVELU EILEN, TÄNÄÄN, HUOMENNA MIHIN PALVELUT OVAT MENOSSA? Lauri Helenius, Solita Oy

JULKISTEN PALVELUJEN ELINKAARI; HYVÄ PALVELU EILEN, TÄNÄÄN, HUOMENNA MIHIN PALVELUT OVAT MENOSSA? Lauri Helenius, Solita Oy JULKISTEN PALVELUJEN ELINKAARI; HYVÄ PALVELU EILEN, TÄNÄÄN, HUOMENNA MIHIN PALVELUT OVAT MENOSSA? 24.10.2017 Lauri Helenius, Solita Oy Solitalaisia yli 650 Liikevaihto 2016 67 M Keski-ikä 36 V. Kasvu 2016

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

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

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

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

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

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

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

PROJEKTI- PÄÄLLIKÖSTÄ PRODUCT OWNERIKSI MEERI CEDERSTRÖM

PROJEKTI- PÄÄLLIKÖSTÄ PRODUCT OWNERIKSI MEERI CEDERSTRÖM PROJEKTI- PÄÄLLIKÖSTÄ PRODUCT OWNERIKSI MEERI CEDERSTRÖM TAUSTA Otaniemi UX (User Experience) Teknologiaa kaikille Silta tekniikan ja bisneksen välillä Testaaja (Tanska) Scrum Käyttöliittymäsuunnittelija

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

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

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

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

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

Testausdokumentti. Kivireki. Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Testausdokumentti Kivireki Helsinki 17.12.2007 Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Kurssi 581260 Ohjelmistotuotantoprojekti (6 ov) Projektiryhmä Anu Kontio Ilmari

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

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

Yrittäjäkasvatuksen polku - sivusto. Yksityiskohtainen suunnittelu Huhtikuu 2018

Yrittäjäkasvatuksen polku - sivusto. Yksityiskohtainen suunnittelu Huhtikuu 2018 Yrittäjäkasvatuksen polku - sivusto Yksityiskohtainen suunnittelu Huhtikuu 2018 Sisällys 1. Sivuston tavoitteet 2. Tausta 3. Näkemys työn tekemisestä ja etenemisestä 4. Roolit ja vastuut -ehdotus 5. Ylätason

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

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

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus

SEPA päiväkirja. BetaTeam. Juho Mäkinen, 57796V, Jari Leppä, 42710V, Versio Pvm Tekijä Kuvaus SEPA päiväkirja BetaTeam Juho Mäkinen, 57796V, jvmakine@cc.hut.fi Jari Leppä, 42710V, jleppa@cc.hut.fi Versio Pvm Tekijä Kuvaus 0.1 10.11.2005 Juho Mäkinen Johdanto 1. 0.2 11.11.2005 J.Mäkinen, Käytäntöön

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

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

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

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

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

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

Ville Isomöttönen. Agile. Jyväskylän Yliopisto Sivu 1 Tietotekniikan laitos

Ville Isomöttönen. 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 doit.throughthisworkwehavecometovalue:

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

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

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

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

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

Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen

Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen Testauksen hallinta Testaustyökalut Luento 7 Antti-Pekka Tuovinen 23 April 2018 1 Tavoitteet Yleiskuva seuraavista aiheista Testauksen organisointi Testaussuunnittelma Testauksen kustannukset Testausstrategia

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

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

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

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

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1

T Tietojenkäsittelyopin ohjelmatyö. Testiraportti, vaihe T1. Tietokonegrafiikka-algoritmien visualisointi. Testiraportti, vaihe T1 T-76.115 Tietojenkäsittelyopin ohjelmatyö Sisältö Tästä dokumentista ilmenee T1-vaiheessa suoritettu testaus, sen tulokset ja poikkeamat testisuunnitelmasta. Päivämäärä 1.12.2002 Projektiryhmä Keimo keimo-dev@list.hut.fi

Lisätiedot

UCOT-Sovellusprojekti. Testausraportti

UCOT-Sovellusprojekti. Testausraportti UCOT-Sovellusprojekti Testausraportti Ilari Liukko Tuomo Pieniluoma Vesa Pikki Panu Suominen Versio: 0.02 Julkinen 11. lokakuuta 2006 Jyväskylän yliopisto Tietotekniikan laitos Jyväskylä Hyväksyjä Päivämäärä

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

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

MITÄ ON GEMBA-WALK? Janne Metsolahti Työnjohtaja YIT Infra Oy

MITÄ ON GEMBA-WALK? Janne Metsolahti Työnjohtaja YIT Infra Oy MITÄ ON GEMBA-WALK? Janne Metsolahti Työnjohtaja YIT Infra Oy janne.metsolahti@yit.fi MITÄ ON GEMBA-WALK? Sana gemba tulee japanin kielestä ja tarkoittaa todellista paikkaa, paikkaa jossa arvo tuotetaan

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

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

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

Soft QA. Vaatimusten muutostenhallinta. Ongelma

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

Lisätiedot

T Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu. Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki

T Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu. Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki T-76.612 Ohjelmistoprojektien hallinta Tehtävän 3 ratkaisu Maija Kangas, Kimmo Stålnacke ja Outi Syysjoki Osa 1 - Ongelmat McConnellin (1996) luokittelun mukaisesti: Ihmiset Prosessi Tuote Teknologia Osa

Lisätiedot