OHJELMISTOARKKITEHTUURISUUNNITTELU EXTREME PROGRAMMINGISSA PERIAATTEET, VAHVUUDET JA HEIKKOUDET

Koko: px
Aloita esitys sivulta:

Download "OHJELMISTOARKKITEHTUURISUUNNITTELU EXTREME PROGRAMMINGISSA PERIAATTEET, VAHVUUDET JA HEIKKOUDET"

Transkriptio

1 teknillinen korkeakoulu Tietotekniikan osasto Janne Lemmetti OHJELMISTOARKKITEHTUURISUUNNITTELU EXTREME PROGRAMMINGISSA PERIAATTEET, VAHVUUDET JA HEIKKOUDET Kandidaatintyö Espoo Työn ohjaaja: DI Mikko Raatikainen

2 teknillinen korkeakoulu kandidaatintyön tiivistelmä Tekijä: Janne Lemmetti Työn nimi: Ohjelmistoarkkitehtuurisuunnittelu Extreme Programmingissa periaatteet, vahvuudet ja heikkoudet Päivämäärä: Kieli: Suomi Sivumäärä: 6+25 Tutkinto-ohjelma: Tietotekniikka Vastuuopettaja: Prof. Jukka Mantere Ohjaaja: DI Mikko Raatikainen Extreme Programming (XP) on ketterä ohjelmistokehitysmenetelmä, jonka tunnuspiirteitä ovat muun muassa lyhyet kehitysiteraatiot, läheinen yhteistyö asiakkaan kanssa, suullisen viestinnän korostaminen, pariohjelmointi ja minimaalinen dokumentointi. Ohjelmistoarkkitehtuurilla tarkoitetaan ohjelman rakennetta tai rakenteita, jotka koostuvat ohjelmiston osista, niiden välisistä suhteista sekä osien ulkopuolelle näkyvistä ominaisuuksista. Arkkitehtuurin suunnittelulla ja dokumentoinnilla pyritään esimerkiksi mahdollistamaan ohjelmistoprojektin sidosryhmien välinen kommunikointi, helpottamaan varhaisten suunnittelupäätösten tekemistä sekä varmistamaan, että ohjelmistolle asetetut laatuvaatimukset toteutuvat. Tässä työssä tutkittiin kuinka XP:n lähestymistapa ohjelmisto- ja arkkitehtuurisuunnitteluun poikkeaa perinteisistä menetelmistä. XP:ssä ei ole eksplisiittistä arkkitehtuurisuunnittelua lainkaan. Etukäteissuunnittelun ja dokumentoinnin sijaan XP:ssä ohjelmistosuunnittelu tapahtuu toteutuksen yhteydessä ja arkkitehtuuri muodostuu kehityksen kuluessa erilaisten käytäntöjen kautta. XP:n tuottaman arkkitehtuurin laatua on epäilty ja kritisoitu eri lähteissä. Tutkimuksen perusteella XP:n tapa on hyvin perusteltu ja vaikuttaa soveltuvan hyvin vähemmän vaativiin projekteihin. Eksplisiittisen arkkitehtuurisuunnittelun puuttumisen vuoksi XP:n soveltuvuus sellaisenaan laajoihin ja laatuvaatimuksiltaan tiukkoihin projekteihin on kyseenalaista eikä aiheesta ole tarpeeksi tutkimustietoa. Aihe kuitenkin kaipaisi perinpohjaisempaa todellisissa teollisuuden olosuhteissa ja kokeneilla kehittäjillä tehtyä tutkimusta. Avainsanat: ohjelmistoarkkitehtuurisuunnittelu, extreme programming

3 iii Esipuhe Haluan kiittää ohjaajaani DI Mikko Raatikaista huolellisesta ohjauksesta ja opastuksesta tieteelliseen kirjoittamiseen. Lisäksi haluan kiittää DI Varvana Myllärniemeä hyödyllisestä keskustelusta ja palautteesta. Otaniemi, Janne Lemmetti

4 iv Sisältö Tiivistelmä Esipuhe Sisällysluettelo ii iii iv 1 Johdanto 1 2 Arkkitehtuuri ja sen suunnittelu Ohjelmistoarkkitehtuuri Arkkitehtuurisuunnittelu Tarve arkkitehtuurisuunnittelulle Extreme Programming Tausta Yleisimpiä käytäntöjä Yhteenveto Arkkitehtuurisuunnittelu XP:ssä XP:n lähestymistapa arkkitehtuurisuunnitteluun Arkkitehtuurisuunnitteluun liittyvät käytännöt XP:ssä Jatkuva ohjelmistosuunnittelu Muut käytännöt Käytäntöjen eroavaisuus XP:n versioiden välillä XP:n laajennettavuus XP:n lähestymistavan puolustus ja kritiikki Yleisiä havaintoja Jatkuva ohjelmistosuunnittelu Puolustus Kritiikki Muut menetelmät Pohdinta Arkkitehtuurisuunnittelun huomiointi XP:ssä

5 6.2 XP:n lähestymistavan riittävyys arkkitehtuurisuunnittelun tarpeiden kannalta XP:n lähestymistavan vahvuudet ja heikkoudet XP:n soveltuvuus erilaisiin projekteihin XP:n laajentamisesta ja mukauttamisesta XP:hen liittyvästä kirjallisuudesta ja tutkimuksesta Oman tutkimuksen validiteetista ja luotettavuudesta Yhteenveto 22 v

6 1 Johdanto Ohjelmistoarkkitehtuurin suunnittelu on osa ohjelmistokehitysprojekteja ja suunnittelun merkitys korostuu erityisesti laajoissa projekteissa [20]. Arkkitehtuurilla tarkoitetaan ohjelmiston sisäistä korkean tason rakennetta tai rakenteita. Tietynlaisella arkkitehtuurilla pyritään muun muassa takaamaan, että kehitettävä ohjelmisto tulee täyttämään sille asetetut toiminnalliset ja laadulliset vaatimukset. Laadullisia vaatimuksia ovat esimerkiksi suorituskykyyn tai tietoturvaan liittyvät vaatimukset [7]. Tyypillisesti arkkitehtuuri suunnitellaan ohjelmistokehityksen alkuvaiheessa ohjelmistolle kerättyjen vaatimusten perusteella. Arkkitehtuuri pyritään suunnittelemaan kokonaan ennen varsinaisen toteutustyön aloittamista [17]. Perinteiset ohjelmistokehitysmenetelmät, kuten vesiputousmalli ja useat iteratiiviset menetelmät, pitävät ohjelmiston etukäteissuunnittelua, johon myös arkkitehtuurin suunnittelu kuuluu, tärkeänä. Toisaalta on myös olemassa joustavampia iteratiivisia menetelmiä, kuten Rational Unified Process (RUP) [16], jossa arkkitehtuurisuunnittelu tapahtuu iteratiivisesti, mutta pääosin ensimmäisten iteraatioiden aikana. Huolellinen etukäteissuunnittelu tulee kalliiksi, jos vaatimuksiin tulee yllättäviä muutoksia kehityksen myöhemmissä vaiheissa [5]. Alussa tehtyjä päätöksiä on yleensä hankala muuttaa, kun varsinainen kehitys on jo edennyt alkuperäisten suunnitelmien mukaan. Ketterät ohjelmistokehitysmenetelmät ovat 90-luvun puolivälin jälkeen syntyneitä kevyitä menetelmiä, jotka pyrkivät vastaamaan jatkuvien muutosten aiheuttamiin ongelmiin perinteisiä menetelmiä joustavammin. Ketterien menetelmien tunnusmerkkejä ovat iteratiivisuus ja inkrementaalisuus, kehittäjien ja asiakkaan tiivis yhteistyö, itseorganisoituvat kehitystiimit sekä se, että muutokset esimerkiksi vaatimuksiin kesken kehitystyön hyväksytään [11]. Extreme Programming (XP) [4] on yksi varsin tunnettu ketterä menetelmä. Alun perin vuonna 1999 esitelty ja viisi vuotta myöhemmin huomattavasti uudistettu menetelmä perustuu tiettyihin ydinperiaatteisiin ja -arvoihin, joita toteutetaan noudattamalla joukkoa toisiaan tukevia käytäntöjä. XP:n tunnusmerkkeihin kuuluvat muun muassa lyhyet kehitysiteraatiot, läheinen yhteistyö asiakkaan kanssa, jatkuva testaus, refaktorointi ja pariohjelmointi [1]. XP:n minimaalisen etukäteissuunnittelun lähestymistapa on herättänyt epäilyksiä menetelmän tuottaman arkkitehtuurin laadusta [14, 20]. Yleinen käsitys tuntuu olevan, että myöhemmässä kehitysvaiheessa tulevat arkkitehtoniset muutokset ovat liian kalliita toteuttaa, joten XP:hen kuuluva ohjelmistosuunnitelman ja -arkkitehtuurin jatkuva parantaminen on kyseenalaistettu [4]. Tässä opinnäytetyössä pyrin selvittämään kirjallisuuskatsauksen avulla vastaukset seuraaviin kysymyksiin: Kuinka arkkitehtuurisuunnittelu huomioidaan ja tehdään XP:ssä?

7 2 Miten XP:n lähestymistapaa perustellaan ja mitä etuja siitä on? Mistä XP:n lähestymistapaa kritisoidaan? Työn rakenne on seuraavanlainen. Luvuissa kaksi ja kolme taustoitan tarkemmin ohjelmistoarkkitehtuurin käsitettä sekä XP:tä. Luvussa neljä paneudun XP:hen arkkitehtuurisuunnittelun kannalta. Luku viisi käsittelee XP:n lähestymistavan saamaa puolustusta ja kritiikkiä. Luvussa kuusi pohditaan tutkimuksen tuloksia ja luvussa seitsemän on työn yhteenveto.

8 3 2 Arkkitehtuuri ja sen suunnittelu Tässä luvussa selvitetään tarkemmin, mitä ohjelmistoarkkitehtuuri ja sen suunnittelu tarkoittavat. Lisäksi selvitetään, miksi arkkitehtuurisuunnittelua pidetään tärkeänä. 2.1 Ohjelmistoarkkitehtuuri Ohjelmistoarkkitehtuurille on lukuisia määritelmiä. IEEE:n [13] standardi arkkitehtuurien kuvaamiselle määrittelee arkkitehtuurin seuraavasti: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. Bass, Clements ja Kazman [8] puolestaan määrittelevät arkkitehtuurin seuraavasti: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. Yllä olevan kaltaiset määritelmät ovat tyypillisiä alan kirjallisuudessa [7]. IEEE:n standardin mukaan järjestelmän perimmäinen järjestys tai organisaatio ilmentyy sen komponenteissa sekä niiden suhteissa toisiinsa ja ulkomaailmaan. Jälkimmäinen määritelmä korostaa lisäksi sitä, että järjestelmällä ei ole yhtä tiettyä rakennetta, joka olisi ylitse muiden. Arkkitehtuuri on useasta samanaikaisesta, erilaisesta rakenteesta koostuva abstrakti käsite. Järjestelmällä voi olla staattinen rakenne, esimerkiksi sen ositus toteutusyksiköihin. Toisaalta järjestelmällä voi myös olla erilaisia dynaamisia rakenteita. Nämä voivat liittyä esimerkiksi siihen, kuinka tieto kulkee ja muuttuu järjestelmässä suorituksen aikana. IEEE:n määritelmässä arkkitehtuuriin kuuluvat myös periaatteet, joiden pohjalta se on suunniteltu ja kehitetty. Periaate voi tarkoittaa esimerkiksi dokumentoituja asiakkaan tarpeita, joiden perusteella arkkitehtuuri suunnitellaan. Bass et al. pitävät näitä periaatteita asioina, jotka eivät kuulu arkkitehtuurin käsitteeseen. Periaatteet tulisi kuitenkin kirjata arkkitehtuurin dokumentaatioon [8]. Lisäksi Bass et al. painottavat, että jokaisella olemassa olevalla järjestelmällä on arkkitehtuuri. Sitä ei ole välttämättä suunniteltu tai dokumentoitu lainkaan, mutta jo sovelluksen olemassaolo implikoi jonkinlaista arkkitehtuuria. Jälkimmäinen määritelmä mainitsee järjestelmän osien ulospäin näkyvät ominaisuudet. Rozanski ja Woods [20] jakavat kyseiset ulospäin näkyvät ominaisuudet toimintaan ja laatuun. Toiminnalla tarkoitetaan järjestelmän jonkin osan vuorovaikutusta

9 muiden osien ja ympäristön kanssa. Esimerkiksi osan tarjoama julkinen ohjelmointirajapinta voidaan luokitella ulospäin näkyväksi toiminnaksi. Laadulliset ominaisuudet ovat järjestelmän havaittavia, myös ei-toiminnallisiksi kutsuttuja ominaisuuksia kuten suorituskyky, tietoturva tai skaalattavuus. Keskeistä arkkitehtuurissa on, että se on abstraktio. Siihen kuuluvat ne asiat, jotka ovat järjestelmän eri sidosryhmien ja heidän tarpeidensa toteutumisen kannalta oleellisia. Esimerkiksi järjestelmän osien sisäinen toiminnallisuus, joka ei näy ulospäin ja jolla ei ole vaikutusta järjestelmältä vaadittuihin laadullisiin ominaisuuksiin, ei kuulu arkkitehtuuriin. Arkkitehtuurikirjallisuudessa käsitellään arkkitehtuurin ja ohjelmistosuunnitelman (engl. design) välistä eroa [7]. Järjestelmä toteutetaan ohjelmistosuunnitelman pohjalta. Osa suunnitelmasta voi perustua arkkitehtuuriin, mutta kaikki millä ei ole arkkitehtuurin kannalta merkitystä, ei kuulu arkkitehtuuriin. Suunnitelma määrittelee tietyn toteutuksen, jolle arkkitehtuuri voi asettaa erilaisia rajoituksia [7] Arkkitehtuurisuunnittelu Arkkitehtuurisuunnittelun tavoitteena on suunnitella arkkitehtuuri, joka täyttää eri sidosryhmien tarpeet. Perinteisissä ohjelmistokehitysprosesseissa kuten vesiputousmallissa tai Rational Unified Processissa suunnittelu sijoittuu prosessin alkupuolelle tai ensimmäisiin iteraatioihin, yleensä vaatimusmäärittelyn ja varsinaisen suunnittelun väliin [20]. Rozanski ja Woods [20] esittelevät kirjassaan iteratiivisen arkkitehtuurisuunnittelumenetelmän, jonka vaiheita ovat sidosryhmien tarpeiden selvittäminen, arkkitehtonisten suunnittelupäätösten tekeminen näiden tarpeiden pohjalta sekä tehtyjen päätösten dokumentoiminen arkkitehtuurikuvaukseen. Bass et al. [8] kuvaavat hieman toisenlaisen suunnittelumenetelmän nimeltä Attribute-Driven Design. 2.3 Tarve arkkitehtuurisuunnittelulle Bass et al. [8] perustelevat ohjelmistoarkkitehtuurin tärkeyttä kolmella syyllä. Ensiksi dokumentoitu arkkitehtuuri mahdollistaa sidosryhmien välisen kommunikoinnin. Se toimii yhteisenä abstraktiona suunnitellusta järjestelmästä, johon keskustelut ja neuvottelut voidaan pohjata. Toiseksi suunniteltu arkkitehtuuri perustuu varhaisiin suunnittelupäätöksiin, jotka vaikuttavat oleellisesti järjestelmän myöhempään suunnitteluun, kehitykseen ja käyttöön. Näitä päätöksiä on vaikeaa muuttaa myöhemmässä vaiheessa, joten arkkitehtuurisuunnitelma auttaa oikeiden suunnittelupäätösten tekemisessä. Kolmantena syynä mainitaan tietynlaisen arkkitehtuurin siirrettävyys ja uudelleenkäytettävyys muissa toiminnallisilta ja laadullisilta vaatimuksiltaan samanlaisissa järjestelmissä. Arkkitehtuurisuunnittelu on tärkeää myös laadullisten vaatimusten toteutumisen kannalta. Dokumentoitu arkkitehtuurisuunnitelma tuo nämä vaatimukset esiin ja

10 ohjaa kehitystä kohti niiden toteutumista vaikuttamalla myöhempiin suunnittelupäätöksiin. 5

11 6 3 Extreme Programming Extreme programming on ketterä ohjelmistokehitysmenetelmä, joka pyrkii mahdollistamaan ohjelmistokehityksen erityisesti tilanteissa, joissa vaatimukset ovat epäselviä tai alati muuttuvia [1]. Tässä luvussa esitellään XP:n taustaa, perusideoita ja lopuksi muutamia keskeisimpiä käytäntöjä niiltä osin, mitkä ovat oleellisia tämän työn aiheen kannalta. 3.1 Tausta Varhaisimpia XP:tä esitteleviä lähteitä ovat Kent Beckin vuonna 1999 julkaistu artikkeli Embracing Change with Extreme Programming [2] sekä hieman myöhemmin julkaistu kirja Extreme Programming Explained [3]. Julkaisujen aikaan XP:n soveltamisesta käytäntöön ei ollut juurikaan kokemuksia eikä menetelmän mahdollisia rajoituksia vielä tunnettu. Viisi vuotta myöhemmin julkaistussa Beckin kirjan toisessa painoksessa [4] XP:tä on uudistettu huomattavasti painosten välisenä aikana kerääntyneen kokemuksen pohjalta. XP pohjautuu Beckin [2] havaintoon, jonka mukaan perinteisten ohjelmistokehitysmallien, kuten vesiputousmallin ja iteratiivisten mallien lähestymistapa ei nykyään ole paras mahdollinen. Vanhojen mallien taustalla on ajatus muutosten kustannusten jyrkästä noususta ohjelmistokehityksen edetessä ajallisesti. Tämän vuoksi perinteiset mallit ovat jaettu erillisiin toisiaan seuraaviin vaiheisiin, kuten analysointi, ohjelmistosuunnittelu, toteutus ja testaus. Koska muutoksilta halutaan välttyä, pyritään esimerkiksi klassisessa vesiputousmallissa (kuva 1a) aluksi analysoimaan asiakkaan tarpeet täydellisesti. Tämän jälkeen suunnitellaan koko järjestelmä ja vasta sen jälkeen aloitetaan toteutus. Kun toteutus on valmis, siirrytään testausvaiheeseen. Iteratiivisissa menetelmissä (kuva 1b) kehitystyö jaetaan iteraatioihin, joissa edellä mainitut kehitysvaiheet toistu- Kuva 1: Erilaiset ohjelmistokehitysmallit (a) Vesiputousmalli: pitkät peräkkäiset vaiheet. (b) Lyhyemmät iteratiiviset vaiheet (c) Kaikki vaiheet rinnakkain koko kehityksen ajan XP:ssä. Kuva on mukailtu Beckin artikkelista [2].

12 vat useammin. Ajatuksena on, että huolellisella etukäteissuunnittelulla päädytään oikeisiin ratkaisuihin, jolloin toteutus on suoraviivaista. Erityisesti vesiputousmalli on kuitenkin todettu huonoksi [16], sillä vaatimukset ovat vain harvoissa ohjelmistoprojekteissa alusta lähtien täysin selvillä. Lisäksi vaatimusten muuttuminen kesken kehitystyön on hyvin yleistä. Beckin [2] mukaan erilaisten ohjelmistokehityksen tekniikoiden kehittyminen mahdollistaa muutoskustannusten alentamisen. Tähän havaintoon pohjaava XP hylkää perinteisen peräkkäisten kehitysvaiheiden lähestymistavan: kaikkia aktiviteettejä tehdään rinnakkain lyhyissä iteraatioissa läpi koko kehityksen (kuva 1c). XP ei määrittele tarkkaa prosessia, vaan lähinnä joukon hyväksi havaittuja ohjelmistokehityksen käytäntöjä. Nykyinen XP perustuu joukkoon arvoja, käytäntöjä ja periaatteita. Arvot ovat yleisluontoisia ohjeita tai tavoitteita, joihin XP:tä käyttävän tiimin tulisi keskittyä, kuten kommunikaatio tai yksinkertaisuus. Käytännöt ovat konkreettisia aktiviteetteja, joita tiimi toteuttaa päivittäin, kuten pariohjelmointi tai yhteisessä tilassa istuminen. Periaatteet ovat arvoja ja käytäntöjä yhdistäviä ohjenuoria. Ne ohjaavat käyttämään tilanteeseen sopivia, XP:n arvoja tukevia käytäntöjä. Esimerkiksi kommunikaatioarvon tapauksessa inhimillisyyden periaate ohjaa tiimiä kasvokkaista viestintää painottavien käytäntöjen suuntaan sen sijaan, että arvoa vaalittaisiin tuottamalla paljon dokumentaatiota Yleisimpiä käytäntöjä XP:n käytännöt jakautuvat kahteentoista pääkäytäntöön ja yhteentoista seurauskäytäntöön [4]. Pääkäytännöt tukevat toisiaan, mutta niiden tulisi toimia myös yksinään. Seurauskäytännöt voivat olla hankalampia toteuttaa, mikäli tiimi ei ole vielä omaksunut pääkäytäntöjä. Eräitä XP:lle tunnusomaisia käytäntöjä ovat yhdessä istuminen, pariohjelmointi, tarinat, viikoittainen ja neljännesvuosittainen sykli sekä inkrementaalinen suunnittelu. Yhdessä istumisella tarkoitetaan kehitystiimin sijoittamista avoimeen tilaan omien työhuoneiden tai koppien sijaan. Käytännön on tarkoitus edistää tiimin jäsenten välistä viestintää. Pariohjelmointi tarkoittaa, että kaikki kehitystyö tehdään parityönä saman tietokoneen äärellä ja pareja kierrätetään säännöllisesti. Käytännön pitäisi viestinnän tehostamisen lisäksi parantaa kehittäjien keskittymiskykyä sekä selkeyttää heidän ideoitaan. Lisäksi parin osapuolet voivat vahtia, että kumpikin noudattaa tiimin muita käytäntöjä. XP:ssä kehitystyön suunnittelu tapahtuu käyttäjälle näkyvän toiminnallisuuden kokoisissa palasissa, joita kutsutaan tarinoiksi. Toivottu toiminnallisuus kirjoitetaan tarinamuodossa paperilapulle ja kullekin tarinalle pyritään arvioimaan toteutukseen kuluva aika. Tarinat sijoitetaan näkyvälle paikalle, kuten yhteisen työtilan seinälle. Kehitystä suunnitellaan viikon jaksoissa. Kunkin jakson alussa pidetään tapaami-

13 nen, jossa arvioidaan tähän mennessä tapahtunutta edistystä sekä kuinka hyvin edistys vastaa edellisen viikon arviota. Tapaamisessa asiakas valitsee alkavan jakson aikana toteutettavat tarinat. Kehittäjät pilkkovat tarinat pienemmiksi tehtäviksi ja arvioivat niihin kuluvan ajan. Viikoittaisen syklin lisäksi kehitystä suunnitellaan myös neljännesvuosittain. Pidempien jaksojen alussa tulisi pohtia tiimiä, projektia ja sen edistymistä laajemmassa mittakaavassa. Seuraavalle vuosineljännekselle valitaan teema tai teemat sekä tarpeeksi teemoihin sopivia tarinoita. Teemojen tarkoituksena on auttaa tiimiä säilyttämään kokonaiskuva kehitettävästä järjestelmästä. Pidempi sykli mahdollistaa suunnittelun ajoittamisen bisnespuolen aktiviteettien kanssa, jolloin ne voidaan ottaa huomioon. Inkrementaalisen ohjelmistosuunnittelun käytäntö tarkoittaa ohjelmiston suunnitelman ja rakenteen jatkuvaa hiomista. Suunnitelman tulisi olla jatkuvasti paras mahdollinen järjestelmän sen hetkisille tarpeille. Kun kehittäjien käsitys parhaasta mahdollisesta suunnitelmasta paranee, tulisi ohjelmiston nykyinen suunnitelma ja rakenne saattaa asteittain vastaamaan uutta optimitilaa. XP:ssä suunnitelma on siis jatkuvan muutoksen kohteena, joten kehittäjien on luotava olosuhteet, joissa muutokset eivät aiheuta kohtuuttomia kustannuksia Yhteenveto XP ei ole varsinainen ohjelmistokehitysprosessi, jolla on tarkasti määritelty rakenne ja vaiheet. XP on hyvää ohjelmointitaitoa, selkeää kommunikointia ja tiimityötä painottava tapa kehittää ohjelmistoja [4]. XP:n tyylille ominaisia piirteitä ovat lyhyet kehitysiteraatiot ja koko projektin ajan jatkuva suunnittelu. XP:n pitäisi toimia joustavasti vaatimusten muuttuessa ja menetelmä painottaa suullista viestintää sekä lähdekoodia ja testitapauksia perinteisen dokumentoinnin sijaan. XP:n omien arvojen lisäksi voidaan valita myös muita projekti- tai organisaatiokohtaisia arvoja. Oleellista on, että tiimin käytös tukee valittuja arvoja, milloin myös käytännöt saattavat muuttua [4]. Erilaisiin tarpeisiin voidaan kehittää uusia käytäntöjä. XP:n periaatteet toimivat suuntaviivoina myös uusia käytäntöjä laadittaessa. Tämä luku ei kata koko XP:tä, vaan olen pyrkinyt esittelemään työn aiheen kannalta oleellisimpia asioita. Beckin kirja [4] kuvaa laajemmin luvussa käsiteltyjä asioita ja sisältää myös paljon asiaa, jota ei tässä ole tuotu esille. Tämä ja edeltävä luku toimivat taustatietona työn varsinaiselle aiheelle. Seuraavassa luvussa tarkastellaan XP:tä tarkemmin arkkitehtuurisuunnittelun kannalta.

14 9 4 Arkkitehtuurisuunnittelu XP:ssä Tässä luvussa tarkastellaan XP:tä tarkemmin arkkitehtuurisuunnittelun kannalta. Aluksi käsitellään yleisesti XP:n lähestymistapaa arkkitehtuurisuunnitteluun. Tämän jälkeen esitellään tarkemmin XP:n tärkeimmät arkkitehtuuriin vaikuttavat käytännöt. Lopuksi käsitellään XP:n laajennettavuutta. 4.1 XP:n lähestymistapa arkkitehtuurisuunnitteluun XP:ssä ei ole eksplisiittistä arkkitehtuurisuunnittelun käytäntöä tai vaihetta. Beck [2, 3, 4] puhuu käytännössä vain ohjelmistosuunnittelusta. Toisaalta Jensen et al. [14] tulkitsevat XP:n ohjelmistosuunnittelun sisältävän osin myös arkkitehtuurisuunnittelua. XP:ssä ohjelmistosuunnittelu on jatkuvaa eli suunnittelu tapahtuu yhtä aikaa toteutuksen kanssa. Perusajatus on, ettei arkkitehtuuria eikä ohjelmistoa ylipäätään suunnitella etukäteen, vaan suunnitelma ja arkkitehtuuri syntyvät toteutuksen aikana käytäntöjä noudattamalla vaikkei XP:ssä varsinaisesti ole arkkitehtuurin käsitettä. Siten XP:stä voidaan löytää tiettyjä arkkitehtuuriin merkittävästi vaikuttavia käytäntöjä. 4.2 Arkkitehtuurisuunnitteluun liittyvät käytännöt XP:ssä XP:ssä on muutamia käytäntöjä, jotka liittyvät arkkitehtuurin suunnitteluun ja kehitykseen. Näitä ovat inkrementaalinen ohjelmistosuunnittelu sekä muutamat muut käytännöt [3, 4]. Seuraavassa esitellään ensin tarkemmin inkrementaalinen ohjelmistosuunnittelu ja sen jälkeen muut käytännöt. Lopuksi tarkastellaan käytäntöihin liittyviä eroavaisuuksia XP:n eri versioissa Jatkuva ohjelmistosuunnittelu XP:n inkrementaalisen ohjelmistosuunnittelun käytäntöä kutsutaan yleisemmin jatkuvaksi ohjelmistosuunnitteluksi (engl. continuous design). Käytännön ideana on etukäteissuunnittelun sijaan luoda ohjelmistosuunnitelmaa toteutuksen aikana ja parantaa sitä koko kehityksen ajan [4]. Jatkuvassa ohjelmistosuunnittelussa keskitytään nykyhetkeen ja pyritään optimoimaan suunnitelma parhaaksi sen hetkiselle toteutukselle. Tulevaisuuden varalle ei suunnitella mitään, mutta suunnitelmaa joudutaan arvioimaan ja hiomaan säännöllisesti [21]. Koska jatkuva ohjelmistosuunnittelu tarkoittaa, että ohjelmistosuunnitelmaan tulee muutoksia kehityksen kaikissa vaiheissa, eivät nämä muutokset saa olla kalliita. Jotta jatkuva ohjelmistosuunnittelu toimisi, on XP-tiimin noudatettava tehokkaasti

15 muutamaa muuta ydinkäytäntöä [10]. Nämä käytännöt ovat testaaminen, jatkuva integrointi sekä refaktorointi. XP:n nykyisen version testivetoisen ohjelmoinnin käytännön ideana on toteuttaa kaikki kehitettävä toiminnallisuus siten, että kehittäjät kirjoittavat ensin toiminnallisuutta vastaavat yksikkötestit ja sitten testit läpäisevän varsinaisen koodin [4]. Käytäntö ohjaa jatkuvaa suunnittelua ja tuottaa täsmällisesti noudatettuna kattavan testisuojaverkon, joka paljastaa tehokkaasti muutosten yhteydessä mahdollisesti syntyvät virheet [10]. Jatkuva integrointi tarkoittaa muutosten integroimista ja integraatiotestausta muutaman tunnin välein [4]. Käytännön ideana on pitää eri kehittäjäparien tuottaman koodin synkronointi mahdollisimman ongelmattomana minimoimalla konfliktien todennäköisyys. Refaktorointi tarkoittaa ohjelman rakenteen muokkaamista ja jäsentelyä kooditasolla ilman, että ohjelman käyttäjälle näkyvä toiminnallisuus muuttuu [9] Muut käytännöt Jatkuvan ohjelmistosuunnittelun lisäksi XP:ssä on muutama käytäntö, jotka liittyvät jossain määrin arkkitehtuurin suunnitteluun ja muotoutumiseen. Käytäntöjä ovat kehityspiikit, metaforat, ensimmäinen iteraatio, pienikokoiset julkaisut, sekä erilaiset tiimikäytännöt [22]. Lisäksi XP:ssä tiimin jäsenillä on erilaisia rooleja, joista yksi on arkkitehdin rooli [4]. Kehityspiikit (engl. spike) ovat projektin alussa tehtäviä nopeita, poisheitettäviä ratkaisuyritteitä. Yritteen ideana on tutkia nopeasti erilaisia lähestymistapoja ongelmaan, jota yritetään ratkaista. Yritteiden ja laadittujen tarinoiden perusteella tulisi syntyä alustava käsitys ohjelman rakenteesta. Tietyn yritteen lähtökohtana voi olla jokin laatuvaatimus, jolloin yrite ohjaa kehittäjien ajatuksia ohjelman rakenteesta suuntaan, joka huomioi kyseisen vaatimuksen. Metafora on XP:n ainoa suoraan arkkitehtuurisuunnitteluun liittyvä käytäntö [14]. Metafora on projektin alkuvaiheessa keksitty vertauskuva koko järjestelmän toiminnasta, minkä tarkoituksena on ohjata järjestelmän kehitystä. Metaforan avulla kehittäjien tulisi havaita ongelma-alueen keskeiset käsitteet ja niiden väliset vuorovaikutukset sekä siten ymmärtää järjestelmän korkean tason toiminnallisuutta. Esimerkiksi graafisen käyttöliittymän tapauksessa työpöytä on yleinen metafora. Beckin [3] mukaan metafora korvaa pitkälti sen, mitä perinteisesti pidetään arkkitehtuurina. Ensimmäisen varsinaisen kehitysiteraation aikana on tarkoitus saada aikaan toimiva runko koko järjestelmälle. Ohjelman ei tarvitse olla toiminnallinen, mutta arkkitehtuurin tulisi olla paikallaan. Iteraation tarinoiksi valitaan joukko, joka oletettavasti pakottaa luomaan alustavan arkkitehtuurin. Tarinat toteutetaan mahdollisimman yksinkertaisella, mutta toimivalla tavalla. Pienikokoiset julkaisut tarkoittavat sitä, että yhden lopullisen julkaisun sijasta asiakkaalle toimitetaan noin neljän iteraation välein toimiva versio ohjelmistosta. Koska

16 asiakkaalle on saatava toimiva versio varsin lyhyessä ajassa, oleellinen rakenne tulee saada paikoilleen aikaisin, jolloin arkkitehtuurin pitäisi muotoutua nopeasti. Lisäksi asiakkaalta saadaan palautetta jo ensimmäisen julkaisun jälkeen, jolloin arkkitehtuurin heikkoudet on mahdollista saada nopeasti selville. Tiimikäytännöillä tarkoitetaan, että esimerkiksi pariohjelmoinnin ja siihen liittyvän parien vaihdon myötä tiimin kesken välittyy tieto siitä, mihin suuntaan ohjelman rakennetta ollaan kehittämässä. XP-tiimissä arkkitehdin rooliin kuuluu etsiä ja toteuttaa laajemman mittakaavan refaktorointeja. Arkkitehti ohjaa järjestelmän arkkitehtuurin kehittymistä läpi järjestelmän kehityskaaren. Lisäksi arkkitehdin tehtäväksi mainitaan järjestelmän osittaminen itsenäisiin kokonaisuuksiin. Ositusta ei ole tarkoitus tehdä spekulatiivisesti ennen kehitystä vaan vasta, kun järjestelmästä on olemassa alustava toteutus. Arkkitehti säilyttää mielessään järjestelmän kokonaiskuvan, kun muut kehittäjät keskittyvät yksittäisten osien jatkokehittämiseen Käytäntöjen eroavaisuus XP:n versioiden välillä XP:n versioiden välisiä eroja arkkitehtuurin suunnitteluun ja muodostumiseen liittyvien käytäntöjen suhteen esitetään taulukossa 1. Oleellisimmat erot ovat, että uudesta XP:stä on poistunut metafora-käytäntö eikä projektin alussa olevasta tutkimusvaiheesta kehityspiikkeineen enää puhuta. Lisäksi uuteen XP:hen on lisätty arkkitehdin rooli. Muilta osin käytännöt löytyvät jossain muodossa molemmista versioista, joskin osa eri nimillä tai esimerkiksi useampi vanha käytäntö uudeksi yhdistettynä. Esimerkiksi vanhassa XP:ssä testauskäytäntöä kutsuttiin jatkuvaksi testaamiseksi, mutta uudessa XP:ssä se on muuttunut testivetoiseksi ohjelmoinniksi, joka painottaa enemmän testien etukäteen kirjoittamista. Samoin refaktorointi on vanhassa XP:ssä oma käytäntönsä, kun se uudessa versiossa sisältyy muutaman muun käytännön kanssa inkrementaaliseen ohjelmistosuunnitteluun. Toisaalta alkuperäisessä XP:ssä ei ollut erillistä inkrementaalisen ohjelmistosuunnittelun käytäntöä, mutta lähestymistapa ohjelmistosuunnitteluun oli kuitenkin sama kuin nykyisessä XP:ssä. 4.3 XP:n laajennettavuus Beckin [4] mukaan XP tulisi sopeuttaa käyttöympäristöönsä. Uusia käytäntöjä voi luoda ja vanhoja muokata, jotta XP:n taustalla olevia arvoja ja periaatteita voidaan tukea. Seuraavassa esitellään muutama laajennusehdotus. Jensen et al. [14] ehdottavat XP:hen uutta käytäntöä, joka ottaa eksplisiittisesti kantaa arkkitehtuurisuunnitteluun. Heidän ehdottama kehittäjätarinoiden (developer stories) käytäntö vastaa XP:n käyttäjätarinoiden käytäntöä, mutta tarinat liittyvät kehittäjille näkyviin ominaisuuksiin. Käytännön ideana on, että kun kehittäjät havaitsevat iteraation aikana, että ohjel-

17 12 Käytäntö tai menetelmä Alkuperäinen XP Nykyinen XP Jatkuva ohjelmistosuunnittelu + + Refaktorointi + + Testaaminen + + Jatkuva integrointi + + Metafora + - Kehityspiikit + - Ensimmäinen iteraatio + + Pienet julkaisut + + Tiimikäytännöt + + Arkkitehdin rooli - + Taulukko 1: XP:n versioiden väliset eroavaisuudet arkkitehtuurisuunnitteluun liittyvien käytäntöjen osalta. man arkkitehtuurissa on ongelmia, niistä laaditaan iteraation lopussa kehittäjätarinoita. Tarinat kuvaavat havaittuja ongelmia refaktorointitehtävinä sekä uutena kehitystyönä. Kehittäjätarinoiden tavoite on suunnitella konkreettisesti refaktorointia ja ilmaista sen tarvetta. Lisäksi tarinoiden laatiminen pakottaa miettimään ohjelmiston suunnitelmaa ja auttaa hahmottamaan arkkitehtuuria. Käytännön tulisi helpottaa erityisesti laajempia refaktorointeja. Kehittäjätarinat tulisi kirjoittaa kunkin iteraation alussa ennen varsinaista iteraatiosuunnittelua. Kehittäjät laativat tarinat yhdessä ja ne lisätään kaikkien tarinoiden joukkoon, josta asiakas valitsee alkavan iteraation tarinat. Asiakkaalle tulisi tehdä selväksi kehittäjien näkemys kehittäjätarinoiden tärkeydestä. Käytäntö tukee XP:n arvoja ja periaatteita esimerkiksi siten, että se ei tuo mukanaan etukäteissuunnittelua. Käytännön toimivuutta ei ole kuitenkaan testattu missään projektissa. Nord ja Tomayko [19] kirjoittavat Carnegie Mellon-yliopiston SEI-instituutissa kehitettyjen arkkitehtuurikeskeisten menetelmien käyttämisestä XP:ssä. Heidän mukaan Quality Architecure Workshop- (QAW), Attribute-Driven Design- (ADD) ja Architecture Trade-off Analysis Method- (ATAM) sekä Cost-Benefit Analysis Method (CBAM)-menetelmät voisivat auttaa XP:n arkkitehtuurisuunnittelua ottamaan laatuvaatimukset paremmin huomioon. QAW-menetelmän tarkoituksena on tuoda esiin laadullisia vaatimuksia samaan aikaan kun XP:n tarinoita luodaan. Työpajaan osallistuvat eri sidosryhmät pohtivat yhdessä erilaisia skenaarioita, jotka paljastavat järjestelmän tärkeimmät laatuvaatimukset. ADD-menetelmän tarkoituksena on suunnitella järjestelmän perusrakenne laatuattribuuttien perusteella. Menetelmää käytettäisiin lähinnä XP:n ensimmäisessä iteraatiossa ja mahdollisesti myöhemmin, jos arkkitehtuuria on tarkoitus muuttaa

18 merkittävästi. ATAM- ja CBAM -menetelmien tarkoituksena on arvioida arkkitehtonisten päätösten seurauksia laatuvaatimusten ja bisnestavoitteiden kannalta. Näitä menetelmiä tulisi käyttää projektin alkuvaiheessa, kun kehittäjät ovat suunnitelleet arkkitehtuurin ADD-menetelmällä. Nordin ja Tomaykon ehdotus tuo XP:hen konkreettista etukäteissuunnittelua. He eivät kuitenkaan raportoi käytännön kokemuksista liittyen menetelmien liittämisestä XP:hen. 13

19 14 5 XP:n lähestymistavan puolustus ja kritiikki Tässä luvussa käsitellään sitä miten kirjallisuudessa puolustetaan ja kritisoidaan XP:n lähestymistapaa arkkitehtuurisuunnitteluun. Aluksi esitellään yleisiä havaintoja aiheen käsittelystä ja sen jälkeen käydään läpi käytäntökohtaisesti puoltavia ja kritisoivia mielipiteitä. 5.1 Yleisiä havaintoja XP:n arkkitehtuurisuunnittelua voimakkaasti puoltavaa tai vastustavaa materiaalia ei juurikaan löydy. Beckin [2, 3, 4] XP-materiaalissa ei eksplisiittisesti erotella arkkitehtuurisuunnittelua ohjelmistosuunnittelusta. Yleinen kritiikin aihe onkin, että XP:ssä ei ole perinteistä etukäteistä arkkitehtuurisuunnittelua. Koska XP:n jatkuvaa ohjelmistosuunnittelua voidaan kuitenkin pitää osin arkkitehtuurisuunnitteluna, käsittelen siihen liittyvää keskustelua. 5.2 Jatkuva ohjelmistosuunnittelu Puolustus Syy XP:n lähestymistavalle ohjelmistosuunnitteluun on selkeästi pyrkimys ketteryyteen vaatimusten ollessa epävakaita tai epäselviä. Tämän vuoksi XP:ssä pyritään välttämään kaikki työ, josta ei ole välitöntä hyötyä. Etukäteissuunnittelu tuottaa dokumentaatiota, jota ei välttämättä tulla koskaan käyttämään. Beckin [4] mukaan suunnittelua tulee tehdä vain välittömään tarpeeseen, jolloin suunnittelupäätöksen oikeellisuudesta saadaan heti palautetta. Kun suunnittelupäätöksiä lykätään niin kauan kuin se on järkevästi mahdollista, on kehittäjien helpompi tehdä oikeita päätöksiä, koska heillä on enemmän kokemusta kehitettävästä järjestelmästä. Ketteryyttä saavutetaan myös arvostamalla yksinkertaisuutta. Kun suunnittelu ja toteutus tapahtuvat vain nykyhetkeä varten, ei ohjelmistoon tuoda ylimääräistä koodia ja se pysyy mahdollisimman yksinkertaisena mahdollisimman kauan. Tulevaisuuteen varautuminen lisää ohjelmiston monimutkaisuutta, joka vaikeuttaa muutosten tekemistä ja siten korottaa niiden kustannuksia. Artikkelissaan Is Design Dead? [10] Fowler käsittelee ja perustelee XP:n lähestymistapaa ohjelmistosuunnitteluun. Hän kuvaa sekä etukäteisen että jatkuvan ohjelmistosuunnittelun ongelmia ja sitä miksi hänen mielestään XP:ssä jatkuva menetelmä toimii. Fowlerin [10] mukaan ohjelmistokehitys ilman etukäteissuunnittelua johtaa yleensä ohjelman rakenteeseen, joka tulee kaiken aikaa yhä vaikeammaksi muuttaa ja alttiimmaksi virheille. Etukäteen tehdyn suunnitelman suurimpana ongelmana on muuttuvat vaatimukset. Muutoksiin varautuminen suunnitelmassa on vaikeaa tai

20 15 Kuva 2: Ajan myötä muuttuvat muutoskustannukset (a) perinteisessä ohjelmistokehitysmallissa ja (b) XP:n tavoittelemana. Kuva on mukailtu Beckin kirjasta [3]. mahdotonta ja varautuminen lisää suunnitelman monimutkaisuutta. Perinteisesti molemmat lähestymistavat siis johtavat klassiseen ohjelmiston muutoskäyrään (kuva 2a), jossa muutosten kustannukset kasvavat eksponentiaalisesti kuluneen ajan suhteen. Etukäteisessä suunnittelussa tämä johtuu siitä, että muutokset tulisi heijastaa aikaisemmissa vaiheissa tuotettuihin dokumentteihin ja aiempi huolellinen suunnittelu menee hukkaan. XP:n perusajatuksena on, että kustannuskäyrä voidaan tasoittaa muotoon, jossa kustannukset pysyvät kurissa ajasta riippumatta (kuva 2b). Fowlerin [10] mukaan oikein toteutettuna luvussa kuvatut ydinkäytännöt mahdollistavat käyrän litistämisen, joka taas mahdollistaa jatkuvan ohjelmistosuunnittelun toimimisen. Fowler puolustaa XP:n lähestymistapaa huomauttamalla, että yleinen syy XP:n menetelmän kritisointiin on se, että kriitikot eivät ole ymmärtäneet käytäntöjen keskinäistä riippuvuutta: jos jatkuvaa ohjelmistosuunnittelua tukevia käytäntöjä ei noudateta, ei niistä riippuvat käytännöt tule toimimaan. Toisaalta Beckin uusimmassa kirjassa [4] jatkuva ohjelmistosuunnittelu listattu pääkäytännöksi, jonka tulisi toimia itsenäisesti. Shore [21] kehuu jatkuvaa ohjelmistosuunnittelua. Hänen kokemustensa perusteella jatkuva ohjelmistosuunnittelu on tuottanut yksinkertaisempia ja helpommin laajennettavia suunnitelmia, kuin etukäteen suunnittelemalla olisi ollut mahdollista. Shoren mukaan myös vaikeiden muutosten, kuten tietoturvaominaisuuksien tai monikielisyystuen lisääminen on onnistunut, kunhan jatkuvassa suunnittelussa on noudatettu tiettyjä periaatteita kuten toistuvan koodin välttämistä ja yksinkertaisuutta, joita XP painottaa. Myös Little [18] kehuu jatkuvaa ohjelmistosuunnittelua artikkelissaan, jossa hän kertoo omakohtaisesta kokemuksestaan keskisuuressa ohjelmistoprojektissa. Projektissa käytettiin XP:tä, mutta aluksi arkkitehtuuri päätettiin suunnitella etukäteen. Tämän johti toimivaan, mutta liian monimutkaiseen suunnitelmaan, jota kehittäjät eivät ymmärtäneet. Kun suunnitelma hylättiin ja tiimi vaihtoi jatkuvaan ohjelmistosuunnitteluun, tulokset olivat erinomaisia. K osoittautui helpoksi ja tehokkaaksi. Myös Little uskoo ettei etukäteissuunnittelulla olisi päästy yhtä hyvään raken-

21 teeseen. Negatiivisena havaintona Little mainitsee laajojen arkkitehtonisten refaktorointien haastavuuden ja työläyden Kritiikki Jensen et al. [14] väittävät, että XP:n tuottaman arkkitehtuurin laatua epäillään useassa julkaisussa. He ovat myös itse havainneet käytännön kokeessa, että XP:n jatkuvalla suunnittelulla syntynyt arkkitehtuuri ei ole välttämättä paras mahdollinen. Kokeessa suoritettiin pienen ohjelmistoprojektin muutama ensimmäinen iteraatio, joiden jälkeen tarkasteltiin syntynyttä arkkitehtuuria. Tarkastelun perusteella arkkitehtuurissa olisi ollut parantamisen varaa. Lisäksi he toteavat, että seuraaviin iteraatioihin valitut tarinat eivät myöskään olisi laukaisseet uusia refaktorointeja. Boehm [5] toteaa, että jatkuva ohjelmistosuunnittelu ei sovi tilanteisiin joissa vaatimukset ovat ennustettavissa ja tiedetään ettei niihin tule muutoksia. Tällöin XP:n lähestymistavassa jätetään tietoisesti toteuttamatta arkkitehtonisen tuki vaadituille ominaisuuksille. Lisäksi menetelmä saattaa Boehmin mielestä tällaisessa tapauksessa haitata asiakassuhteita, koska asiakas voi luulla, ettei hänen tarpeitaan oteta huomioon varautumalla niihin etukäteen. Vaikka Fowler [10] puolustaakin XP:n jatkuvaa ohjelmistosuunnittelua, hän myöntää että eksplisiittisen arkkitehtuurisuunnittelun puuttuminen saattaa olla XP:n heikkous. Hänen mielestään XP:hen sopisi jonkinlainen alustava arkkitehtuurin suunnittelu. Cao et al. [6] ovat tutkineet XP:n soveltuvuutta laajojen, monimutkaisten ohjelmistojärjestelmien kehittämiseen. Tutkimuksessa XP:tä sovellettiin laajan pankkialaan liittyvän sovelluksen kehittämiseen, mutta XP:tä räätälöitiin sopimaan paremmin projektin tarpeisiin. Koska ongelma-alue oli hyvin tunnettu ja vaatimuksiltaan vakaa, arkkitehtuurin etukäteissuunnittelu oli mahdollista ja myös tarpeellista. Koska sovelluksella oli kriittisiä laatuvaatimuksia kuten tietoturva ja luotettavuus, oli etukäteissuunnittelu heidän mielestään välttämätöntä. Lisäksi todettiin, että näin laajassa projektissa tiimin jäsenten on vaikea hahmottaa kokonaisuutta ilman erillistä dokumentaatiota. 5.3 Muut menetelmät Jensen et al. [14] tekemän kirjallisuuskatsauksen perusteella metafora-käytäntö on ollut vaikea ymmärtää ja hyödyntää. Käytäntö oli kuitenkin heistä hyödyllinen, koska se pyrki luomaan yhteistä käsitystä arkkitehtuurista sidosryhmien välille. Heidän mukaan metafora-käytännöstä luopumista on kritisoitu. Lisäksi he kritisoivat XP:n esittelemää arkkitehdin roolia siitä, että se kuvataan varsin epämääräisesti. Roolin määrittelyssä ei esimerkiksi ohjeisteta kuinka tiimin tulisi viestiä laajemmista arkkitehtonisista refaktoroinneista. Herbsleb, Root ja Tomayko [12] ovat tutkineet metafora-käytännön vaikutusta ark-

22 kitehtuuriin yliopiston ohjelmatyökurssilla siten, että opiskelijaryhmiä ohjeistettiin laatimaan metafora projekteilleen. Tutkimuksen perusteella Herbsleb et al. toteavat, että metafora on suhteellisen hyödytön käytäntö arkkitehtuurin kehittymisen kannalta. Myös West [23] pitää metaforaa heikkona erityisesti siksi, että käytäntöä ei ole selitetty kunnolla eikä sitä siksi ole ymmärretty. Juric [15] epäilee etteivät refaktorointi ja metafora riitä kaikkien arkkitehtonisten asioiden kattamiseen XP:n käytännöt ja näkemys arkkitehtuurista eivät käsitä kaikkea mitä arkkitehtuuriin perinteisesti pidetään kuuluvan. 17

23 18 6 Pohdinta Tässä luvussa pohditaan työn tuloksia. Aluksi käsitellään arkkitehtuurisuunnittelun huomiointia XP:ssä. Tämän jälkeen pohditaan XP:n lähestymistavan riittävyyttä perinteisten arkkitehtisuunnittelun tarpeiden valossa. Tämän jälkeen eritellään XP:n lähestymistavan havaittuja vahvuuksia ja heikkouksia. Seuraavaksi pohditaan XP:n ja sen lähestymistavan soveltuvuutta erilaisiin projekteihin. Tämän jälkeen käsitellään XP:n laajennuksia ja niiden vaikutusta XP:n luonteeseen. Lopuksi kommentoidaan aiheeseen liittyvää tutkimusta ja kirjallisuutta sekä arvioidaan omaa tutkimusta. 6.1 Arkkitehtuurisuunnittelun huomiointi XP:ssä XP:ssä ei ole eksplisiittisiä arkkitehtuurin ja arkkitehtuurisuunnittelun käsitteitä. Tästä johtuen XP:ssä ei ole juurikaan arkkitehtuurisuunnitteluun suoraan liittyviä käytäntöjä. Toisaalta koska osa ohjelmistosuunnittelusta on arkkitehtonista, on XP:n jatkuva ohjelmistosuunnittelu myös osaltaan arkkitehtuurisuunnittelua. Arkkitehtuurisuunnittelun kannalta ongelmana on kuitenkin etukäteissuunnittelusta kieltäytyminen. XP:n lähestymistavan orjallinen noudattaminen edellyttää, että myös arkkitehtoniset suunnittelupäätökset tehdään vasta toteutuksen aikana, kun tarve niiden tekemiselle ilmenee. Jos XP:tä toisaalta laajennetaan arkkitehtuurisuunnittelun osalta esimerkiksi SEI-instituutin menetelmillä, saattaa XP:n ketteryys horjua. Laajennusten tulisi ottaa huomioon XP:n arvot ja periaatteet. Teoriassa XP:ssä ei tarvita etukäteistä arkkitehtuurisuunnittelua, koska ohjelmiston pitäisi pysyä niin helposti muokattavana. Tällöin arkkitehtonisten suunnittelupäätösten toteuttaminen pitäisi olla helppoa vaikka niihin ei olisi ennalta varauduttu. XP siis periaatteessa eliminoi tarpeen tehdä varhaisia suunnittelupäätöksiä. Jatkuva ohjelmistosuunnittelu kuulostaa teoriassa hyvältä ja se on perusteltu hyvin, mutta sen soveltuvuudesta suuriin ja vaativiin projekteihin, joissa arkkitehtuurisuunnittelu on perinteisesti merkittävässä roolissa, ei ole riittävästi vakuuttavaa materiaalia. 6.2 XP:n lähestymistavan riittävyys arkkitehtuurisuunnittelun tarpeiden kannalta XP vastaa omalla epäsuoralla tavallaan suurimpaan osaan luvussa 2.3 esiteltyihin tarpeisiin eli sidosryhmien välisen kommunikoinnin helpottamiseen, varhaisten suunnittelupäätösten tekemiseen, siirrettävyyteen ja laatuvaatimusten toteutumiseen. Seuraavassa tarkastellaan kutakin erikseen. XP:ssä asiakas periaatteessa jatkuvasti hyvin lähellä tiimiä, joten tälle arkkitehtuurin kommunikoinnilla ei ole kovin suurta merkitystä. Toisaalta on myös muita sidosryhmiä, joille dokumentoidusta arkkitehtuurista voisi olla hyötyä. Heidän tarpeitaan

24 XP ei tunnu huomioivan, sillä dokumentaatiota ei ole tarkoitus tuottaa. Toisaalta arkkitehtuuri on jatkuvan muutoksen alla, joten sen dokumentaation ylläpitäminen ei olisi kovin käytännöllistä. Poistuneen metafora-käytännön tarkoituksena oli erityisesti helpottaa hyvin korkean tason arkkitehtuurin kommunikointia. Varhaiset suunnittelupäätökset ovat vastoin XP:n arvoja ja periaatteita. Varhaiset päätökset koskevat tyypillisesti asioita, joita on vaikea muuttaa tulevaisuudessa. XP:n jatkuvan ohjelmistosuunnittelun pitäisi johtaa ohjelmistoon, jota on helppo muuttaa, joten varhaisille päätöksille ei pitäisi olla tarvetta. Arkkitehtuurien siirrettävyyteen XP ei ota käytännössä mitään kantaa. Arkkitehtuurisuunnitelman uudelleenkäyttö edellyttäisi periaatteessa dokumentoitua suunnitelmaa, jota ei normaalisti tehdä. Jos siirrettävyyttä ajatellaan koodin uudelleenkäytön kannalta, lienee sekin vastoin XP:n arvoja, joissa lähdetään liikkeelle kaikkein yksinkertaisimmasta ratkaisusta. XP:ssä ei oteta eksplisiittisesti kantaa laatuvaatimuksiin. Etukäteisen suunnitelman puuttuessa ei ole dokumenttia, josta laatuvaatimukset kävisivät ilmi. Toisaalta käyttäjien kirjoittamat tarinat voivat sisältää myös laadullisia vaatimuksia. Laatuvaatimukset ovat tyypillisesti jälkikäteen vaikeasti lisättäviä ominaisuuksia ja on kyseenalaista osaako asiakas vaatia niitä aikaisessa vaiheessa tai ylipäätään ottaa laatuun kantaa. Mikäli XP:n lupaus helposta muutettavuudesta pitää, ei laatuvaatimustenkaan toteuttamisen pitäisi olla mahdotonta myöhäisessäkään vaiheessa. On syytä huomata, että luvussa 2.3 mainitut tarpeet arkkitehtuurisuunnittelulle eivät todennäköisesti ole ainoita tunnistettuja tarpeita, mutta tämän työn puitteissa käsittely rajoittuu niihin XP:n lähestymistavan vahvuudet ja heikkoudet XP:n lähestymistavalle ei löydy yksikäsitteistä puoltavaa tai vastustavaa materiaalia. Toiset ovat havainneet menetelmän toimivaksi ja toisissa tutkimuksissa se on havaittu riittämättömäksi. XP:n lähestymistavan vahvuus on erityisesti sopeutuvuus muutoksiin. Ohjelmisto pysyy helposti muutettavana koko kehityksen ajan eikä kehitystiimin tarvitse käyttää aikaa dokumentaation ajan tasalla pitämiseen. Useamman lähteen mukaan jatkuva ohjelmistosuunnittelu on tuottanut ohjelmia, jotka ovat rakenteeltaan parempia kuin etukäteen suunnittelemalla olisi ollut mahdollista. Paremmuus tarkoittaa näissä tapauksissa yleensä ylläpidettävyyttä ja muokattavuutta, johon XP ja jatkuva ohjelmistokehitys juuri pyrkivät. Laatuvaatimusten olematon huomiointi on todennäköisesti XP:n heikko kohta, vaikka ohjelman pitäisi olla helposti muokattava ja myös etukäteen suunnittelemattomien laatuvaatimusten toteuttamisesta on joitain todisteita [21]. Eksplisiittisen arkkitehtuurisuunnittelun puuttuminen on useammassa lähteessä mainittu XP:n heikkoudeksi [10, 14]. Erillisen arkkitehtuurisuunnittelun sisällyttäminen

25 XP:hen voi kuitenkin olla ongelmallista, jos halutaan pysyä uskollisena XP:n arvoille ja pitää menetelmä yhtä ketteränä XP:n soveltuvuus erilaisiin projekteihin XP vaikuttaa soveltuvan sellaisenaan pieniin ja keskisuuriin projekteihin, jotka ovat vaatimuksiltaan epävakaita ja joilla ei ole erityisiä laatuvaatimuksia. Lisäksi XP tuntuu soveltuvan paremmin tilanteisiin, joissa kehittäjät eivät tunne ongelma-aluetta hyvin, koska tällöin etukäteissuunnittelu on vaikeaa ja toisaalta jatkuva lähestymistapa lisää kokemusta jatkuvan palautteen kautta. Lisäksi monimutkaisen suunnitelman sisäistäminen ja toteuttaminen lienee hankalampaa kuin mahdollisimman yksinkertaisesta ratkaisusta aloittaminen ja vaiheittainen kehittäminen. Eniten tunnutaan epäilevän XP:n lähestymistavan soveltuvuutta laajamittaisiin projekteihin etenkin jos ohjelmistolla on tiukempia laatuvaatimuksia. Vaikka dokumentoimattomuus on toisaalta etu ja kenties edellytys ketteryydelle, se ei näin äärimmilleen vietynä todennäköisesti toimi, kun projektin koko kasvaa tarpeeksi. Jos kehitettävä ohjelmisto on tarpeeksi laaja, alkaa sen hahmottaminen käydä mahdottomaksi ilman mitään näkyvää dokumentaatiota. Lisäksi laajemman mittakaavan arkkitehtoniset refaktoroinnit ovat todennäköisesti erittäin työläitä. 6.5 XP:n laajentamisesta ja mukauttamisesta Mikään ei estä räätälöimästä XP:tä soveltumaan paremmin omaan projektiinsa. Beck jopa kannustaa tähän, kunhan muutokset palvelevat XP:n arvoja. XP:n muokkaamista on kahdentyyppistä: uusien käytäntöjen ja muiden lisäysten tuominen XP:hen ja toisaalta vain joidenkin XP-käytäntöjen hyödyntäminen ja mukauttaminen tietyn projektin tarpeisiin. Uusien käytäntöjen kehittämisestä on tehty jonkin verran tutkimusta. Luvussa 4.3 esitellyissä ratkaisuissa on kuitenkin ongelmana se, että niiden toimivuutta ei ole tutkittu käytännössä. Laajentamista on tehty sekä pysyen uskollisena XP:n arvoille, että ottamatta niitä sen kummemmin huomioon. Tarkemman tutkimuksen puutteessa on vaikea arvioida menettääkö XP merkittävästi ketteryyttään, jos siihen tuodaan käytäntöjä, jotka eivät sovi hyvin XP:n arvoihin ja periaatteisiin. Samasta syystä ei ole varmaa tietoa laajennusten vaikutuksesta arkkitehtuuriin. XP:n mukauttamisesta projektin tarpeisiin on jonkin verran enemmän raportteja. Erilaisissa laajemmissa projekteissa on otettu käyttöön osajoukko XP:n käytännöistä perinteisempien menetelmien rinnalle ja lisäksi muokattu valittuja käytäntöjä soveltumaan paremmin projektiin. Lukemissani raporteissa tällaisesta XP:n mukauttamisesta oltiin saatu pääosin positiivisia kokemuksia, mutta usein juuri ohjelmistoja arkkitehtuurisuunnittelua oltiin päädytty tekemään perinteisin keinoin etukäteen. Kun XP:tä laajennetaan huomattavasti tai siitä otetaan käyttöön vain kourallinen käytäntöjä, voidaan pohtia onko ohjelmistokehitys silloin enää XP:tä tai ylipäätään

26 ketterää. Onko mahdollista tehdä etukäteissuunnittelua ja pysyä silti joustavana muutoksille? Voidaanko XP:n äärimmilleen viedyn ketteryyden ja perinteisten menetelmien välitä löytää sopiva keskitie esimerkiksi siten, että vain osa järjestelmästä toteutetaan XP:llä ja XP:lle haastavampiin osiin sovelletaan muita menetelmiä? XP:hen liittyvästä kirjallisuudesta ja tutkimuksesta Beckin kirjoittamat perusteokset XP:stä kuvaavat käytäntöjä varsin epämääräisesti. Käytäntöjen oikeaoppisen toteutuksen ja riippuvuussuhteiden selvittäminen on jäänyt muiden selvitettäväksi. Lisäksi Beckin kirjojen väliset huomattavat rakenteelliset ja sisällölliset erot ovat hämmentäviä. Ovatko uusi ja vanha XP toisensa poissulkevia? Ovatko vanhan XP:n osin päteviltä vaikuttavat käytännöt huonoja, koska niitä ei enää ole uudessa XP:ssä? XP:hen liittyvän tutkimuksen laatu herättää paikoin epäilyksiä. XP:tä on kyllä testattu käytännössä, mutta usein testaus on teetetty esimerkiksi opiskelijaprojekteissa tai projektia on tehty vain muutaman iteraation ajan ja sen perusteella on tehty johtopäätöksiä. Tällaisissa tapauksissa epäilyttää se, kuinka kurinalaisesti ja oikeaoppisesti kehittäjät ovat noudattaneet XP:n käytäntöjä. Edellä mainitun kaltaisissa pintapuolisissa tutkimuksissa päädyttiin yleensä kritisoimaan XP:tä enemmän kuin tutkimuksissa, joissa XP:tä oli käytetty todellisessa ohjelmistoprojektissa läpi koko projektin. 6.7 Oman tutkimuksen validiteetista ja luotettavuudesta Peruskirjallisuus toimi hyvänä lähteenä taustatiedolle, mutta varsin uutena menetelmänä XP:stä ei ainakaan arkkitehtuurisuunnitteluun liittyen löytynyt paljoa käytännön tutkimusta. Arkkitehtuuriin ja sen suunnitteluun keskittyvien artikkeleiden lisäksi olisi voinut olla hyödyllistä lukea tai ainakin selata myös yleisemmin XP:tä käsitteleviä tutkimuksia. Selkeämpiä tuloksia voisi saada seuraamalla oikeita projekteja, joissa käytetään XP:tä. Kehittäjien tulisi olla XP:n suhteen kokeneita, jotta käytäntöjen toteutetaan oikeaoppisesti.

27 22 7 Yhteenveto Tässä työssä tutkittiin kuinka arkkitehtuurisuunnittelua tehdään XP:ssä. Lisäksi selvitettiin kuinka XP:n tapaa on puolustettu ja kritisoitu. Näiden perusteella pohdittiin XP:n lähestymistavan vahvuuksia, heikkouksia ja soveltuvuutta erilaisiin projekteihin. XP on ketterä ohjelmistokehitysmenetelmä, joka koostuu joukosta käytäntöjä. Ohjelmistoarkkitehtuuri tarkoittaa ohjelman osien, niiden välisten suhteiden sekä osien ulospäin näkyvien ominaisuuksien muodostamia rakenteita. Arkkitehtuurin suunnittelulla ja dokumentoinnilla pyritään muun muassa varmistamaan sidosryhmien tarpeiden toteuttaminen ja helpottamaan varhaisten suunnittelupäätösten tekemistä. XP:n lähestymistapa ohjelmistosuunnitteluun poikkeaa perinteisestä etukäteisestä ohjelmistosuunnittelusta. Erityisesti XP:ssä ei ole eksplisiittistä arkkitehtuurisuunnittelua. Sen sijaan XP:ssä tehdään jatkuvaa ohjelmistosuunnittelua, jossa suunnittelu tapahtuu samaan aikaan kehityksen kanssa. Tällöin suunnittelu tapahtuu vain nykyhetkeä varten. Myös arkkitehtuuri muodostuu kehityksen kuluessa erilaisten käytäntöjen myötä. Lähestymistapa tarkoittaa käytännössä säännöllistä koodin refaktorointia ja edellyttää testivetoisen ohjelmoinnin sekä jatkuvan integroinnin käytäntöjä. Refaktorointi on ohjelmakoodin rakenteen muokkaamista ja uudelleenjäsentelyä ilman, että ohjelman toiminta muuttuu. Testivetoisessa ohjelmoinnissa kaikki toteutustyö alkaa yksikkötestien laatimisella ja vasta niiden jälkeen kirjoitetaan toteuttava, testit läpäisevä koodi. Käytäntö ohjaa suunnittelua ja tuottaa kattavan turvaverkon refaktoroinnin virheiden varalle. Jatkuvassa integroinnissa kehittäjäparit synkronoivat tuottamansa koodin yhteen lyhyin väliajoin, jottei jatkuvista muutoksista synny vaikeita konflikteja. Arkkitehtuurin ja arkkitehtuurisuunnittelun rooli on vähäinen XP:ssä, koska sillä tuotetun ohjelmiston pitäisi pysyä niin helposti muutettavana ettei erityistä suunnittelua tarvita. Vaikeiden suunnittelupäätösten tekeminen ei kuitenkaan ole arkkitehtuurisuunnittelun ainoa tehtävä. XP:n lähestymistapa ei esimerkiksi ota kovin hyvin huomioon kaikkien sidosryhmien tarpeita tai kääntäen se edellyttää myös sidosryhmien toimintatapojen muuttamista XP:lle sopivammaksi. Lähestymistavan toimivuudesta on joitakin raportteja, mutta se kaipaisi vielä perinpohjaisempaa tutkimusta. Tämän tutkimuksen perusteella XP vaikuttaa lähestymistapoineen soveltuvan pieniin ja keskikokoisiin projekteihin, joilla ei ole tiukkoja laatuvaatimuksia. Eniten XP:stä saanee irti, jos vaatimukset eivät ole heti alusta asti selvät ja niiden muutoksen todennäköisyys on suuri. Samoin XP soveltuu paremmin projekteihin, joissa sovellusalue ei ole kehittäjille ennestään tuttu tai muutoin hyvin vakiintunut kuten esimerkiksi pankkialan sovellukset. Käytännössä kyseessä ovat siis tilanteet, joissa arkkitehtuurilla ei ole niin suurta merkitystä tai sitä on vaikea suunnitella etukäteen. Laajoja ja muuten XP:n lähestymistavalle huonosti soveltuvia projekteja varten XP:tä on yritetty laajentaa ja mukauttaa erilaisin keinoin. XP:lle on kehitetty uu-

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

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

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa

Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Ohjelmistoarkkitehtuurit Kevät 2016 Johdantoa Samuel Lahtinen http://www.cs.tut.fi/~ohar/ 8.1.2014 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3

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

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

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti

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

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

Kandidaatintyön aiheita

Kandidaatintyön aiheita Kandidaatintyön aiheita PM&RG:n aihe-ehdotukset Mervi L. Ranta ja Henrik J. Asplund Mervi L. Ranta & Henrik J. Asplund PL 15400, 00076 AALTO email: pmrg@tkk.fi FINLAND http://www.cs.hut.fi/~pmrg Version

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

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

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

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

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

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

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

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

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

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

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

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

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

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

Jalostaminen ja kehittäminen Yhdisteleminen (osaamisten, näkökulmien ja ideoiden)

Jalostaminen ja kehittäminen Yhdisteleminen (osaamisten, näkökulmien ja ideoiden) TAVOITE TÄNÄÄN Jalostaminen ja kehittäminen Yhdisteleminen (osaamisten, näkökulmien ja ideoiden) Jalostamista tukevan tutkimuksen suunnittelua Pohdimme esillä olevien terveysliikuntakonseptien kautta tutkimuskentältä

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

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2008 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia 1.4 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi

Lisätiedot

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008

Verkkopokerijärjestelmä. Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008 Verkkopokerijärjestelmä Loppuraportti Ryhmä Kanat Ohjelmistotuotantoprojekti, syksy 2008 Projektiryhmä Samuli Aalto-Setälä Jukka Kekälainen Jarno Kyykkä Mika Mielonen Mårten Smeds Otto Waltari Ohjaaja

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi 1.4 Toteutusalustan arkkitehtuurin rooli 1.5 Yhteenvetoa

Lisätiedot

Software product lines

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

Lisätiedot

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

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

Lisätiedot

COTOOL dokumentaatio SEPA: Refaktorointi

COTOOL dokumentaatio SEPA: Refaktorointi Table of Contents Refaktorointi................................................................................ 1 1 Tehtävänanto.............................................................................

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

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

MONOGRAFIAN KIRJOITTAMINEN. Pertti Alasuutari

MONOGRAFIAN KIRJOITTAMINEN. Pertti Alasuutari MONOGRAFIAN KIRJOITTAMINEN Pertti Alasuutari Lyhyt kuvaus Monografia koostuu kolmesta pääosasta: 1. Johdantoluku 2. Sisältöluvut 3. Päätäntäluku Lyhyt kuvaus Yksittäinen luku koostuu kolmesta osasta

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

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

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

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1

1 Johdanto. Ohjelmistoarkkitehtuurit Syksy 2010 TTY Ohjelmistotekniikka 1 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto

Arkkitehtuurien tutkimus Outi Räihä. OHJ-3200 Ohjelmistoarkkitehtuurit. Darwin-projekti. Johdanto OHJ-3200 Ohjelmistoarkkitehtuurit 1 Arkkitehtuurien tutkimus Outi Räihä 2 Darwin-projekti Darwin-projekti: Akatemian rahoitus 2009-2011 Arkkitehtuurisuunnittelu etsintäongelmana Geneettiset algoritmit

Lisätiedot

ALAN ASIANTUNTI- JATEHTÄVISSÄ TOIMIMINEN, KE- HITTÄMINEN JA ONGELMANRAT- KAISU - perustella asiantuntijatehtävissä. toimiessaan tekemiään

ALAN ASIANTUNTI- JATEHTÄVISSÄ TOIMIMINEN, KE- HITTÄMINEN JA ONGELMANRAT- KAISU - perustella asiantuntijatehtävissä. toimiessaan tekemiään ALKUVAIHEEN MINEN MISALUEET Tasot ALAN TEORIOIDEN, KÄSITTEIDEN, ME- NETELMIEN JA PE- RIAATTEIDEN MINEN 5 - käyttää keskeisiä teorioita, käsitteitä ja menetelmiä johdonmukaisesti erilaisissa - kirjoittaa

Lisätiedot

Käyttäjätarinat perinteisessä hankkeessa. Sisältö ja käytännöt

Käyttäjätarinat perinteisessä hankkeessa. Sisältö ja käytännöt Käyttäjätarinat perinteisessä hankkeessa Sisältö ja käytännöt Helsingin kaupunki 21/03/17 Käyttäjätarinat perinteisessä hankkeessa Mikä on käyttäjätarina Käyttäjätarina perinteisessä hankkeessa Käyttäjätarinan

Lisätiedot

Tietokoneohjelmien käyttö laadullisen aineiston analyysin apuna

Tietokoneohjelmien käyttö laadullisen aineiston analyysin apuna Tietokoneohjelmien käyttö laadullisen aineiston analyysin apuna Laadullinen, verbaalinen, tulkinnallinen aineisto kootaan esimerkiksi haastattelemalla, videoimalla, ääneenpuhumalla nauhalle, yms. keinoin.

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Tarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen

Tarjolla tänää: Ohjelmiston toteutuksesta. Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit. Testilähtöinen kehittäminen JOT2007. Uudelleenrakentaminen Tarjolla tänää: Ohjelmiston toteutuksesta JOT2007 CRC-kortit Testilähtöinen kehittäminen Uudelleenrakentaminen Voisiko ohjelmointi olla sittenkin suunnittelua? Kuinka tulla hyväksi ohjelmoijaksi? CRC-kortit

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

Teoreettisen viitekehyksen rakentaminen

Teoreettisen viitekehyksen rakentaminen Teoreettisen viitekehyksen rakentaminen Eeva Willberg Pro seminaari ja kandidaatin opinnäytetyö 26.1.09 Tutkimuksen teoreettinen viitekehys Tarkoittaa tutkimusilmiöön keskeisesti liittyvän tutkimuksen

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

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

Lisätiedot

Sähköisten viranomaisaineistojen arkistoinnin ja säilyttämisen palvelukokonaisuus

Sähköisten viranomaisaineistojen arkistoinnin ja säilyttämisen palvelukokonaisuus Luo / Muokkaa Lähetä Lausunnonantajat Yhteenveto Sähköisten viranomaisaineistojen arkistoinnin ja säilyttämisen palvelukokonaisuus Sähköinen arkistoinnin palvelukokonaisuus Lausunnonantajia: 1 Puollatko

Lisätiedot

Urban Design Management ja lisäarvo - Integroiva suunnitteluoperaatio. Tommi Mäkynen 14.12.2007 maekynen@arch.ethz.ch

Urban Design Management ja lisäarvo - Integroiva suunnitteluoperaatio. Tommi Mäkynen 14.12.2007 maekynen@arch.ethz.ch Urban Design Management ja lisäarvo - Integroiva suunnitteluoperaatio Tommi Mäkynen 14.12.2007 maekynen@arch.ethz.ch Mitä arvo on? Arvo on subjektiivinen ja asiakas moninainen Helsinki Design District?

Lisätiedot

Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

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

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

Rakenteellinen turvallisuus miten teoria ja käytäntö kohtaavat?

Rakenteellinen turvallisuus miten teoria ja käytäntö kohtaavat? RIL, Rakennus- ja rakennetekniikkaryhmä 30.10.2013 Rakennusten sortumat miten estetään? Rakenteellinen turvallisuus miten teoria ja käytäntö kohtaavat? Ralf Lindberg, Tampereen teknillinen yliopisto 1.

Lisätiedot

Käsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti

Käsitteistä. Reliabiliteetti, validiteetti ja yleistäminen. Reliabiliteetti. Reliabiliteetti ja validiteetti Käsitteistä Reliabiliteetti, validiteetti ja yleistäminen KE 62 Ilpo Koskinen 28.11.05 empiirisessä tutkimuksessa puhutaan peruskurssien jälkeen harvoin "todesta" ja "väärästä" tiedosta (tai näiden modernimmista

Lisätiedot

Johdantoluento. Ohjelmien ylläpito

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

Lisätiedot

Testaaminen ohjelmiston kehitysprosessin aikana

Testaaminen ohjelmiston kehitysprosessin aikana Testaaminen ohjelmiston kehitysprosessin aikana 04.02.2004 http://cs.joensuu.fi/tsoft/ Sisällys 1. Johdanto 2. Yksikkö- ja integrointitestaus 3. Järjestelmätestaus 4. Hyväksymistestaus http://cs.joensuu.fi/tsoft/

Lisätiedot

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti

Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Teknillinen korkeakoulu 51 Vaatimusmäärittely Ohjelma-ajanvälitys komponentti Versio Päiväys Tekijä Kuvaus 0.1 21.11.01 Oskari Pirttikoski Ensimmäinen versio 0.2 27.11.01 Oskari Pirttikoski Lisätty termit

Lisätiedot

Internet-pohjainen ryhmätyöympäristö

Internet-pohjainen ryhmätyöympäristö Menetelmäohje Internet-pohjainen ryhmätyöympäristö Riku Hurmalainen, 24.3.2002 Sisällysluettelo 1. Johdanto...3 2. Termit...4 3. Toteutus...5 3.1. Yleiskuvaus...5 3.2. Tekninen ratkaisu...5 3.3. Tietoturva...6

Lisätiedot

NextMakers-kasvuyritysbarometri. Julkaistu Microsoft Fluxissa

NextMakers-kasvuyritysbarometri. Julkaistu Microsoft Fluxissa NextMakers-kasvuyritysbarometri Julkaistu 9.2.2017 Microsoft Fluxissa NextMakers-kasvuyritysbarometri 1/2017 NextMakers-barometri käsittelee kasvuyrityksille kiinnostavia, ajankohtaisia aiheita. Ensimmäisen

Lisätiedot

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri?

1 Johdanto. Pieni motivointikalvo. 1.1 Mikä on ohjelmistoarkkitehtuuri? 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

OHEISMATERIAALIN TARKOITUS

OHEISMATERIAALIN TARKOITUS (2012) OHEISMATERIAALIN TARKOITUS Kalvosarja on oheismateriaali oppaalle TASA ARVOSTA LAATUA JA VAIKUTTAVUUTTA JULKISELLE SEKTORILLE Opas kuntien ja valtion alue ja paikallishallinnon palveluihin ja toimintoihin

Lisätiedot

Sosiaalisen median käyttö autokaupassa. Autoalan Keskusliitto ry 3/2012 Yhdessä Aalto Yliopisto, Helsingin kauppakorkeakoulu opiskelijatiimi

Sosiaalisen median käyttö autokaupassa. Autoalan Keskusliitto ry 3/2012 Yhdessä Aalto Yliopisto, Helsingin kauppakorkeakoulu opiskelijatiimi Sosiaalisen median käyttö autokaupassa Autoalan Keskusliitto ry 3/1 Yhdessä Aalto Yliopisto, Helsingin kauppakorkeakoulu opiskelijatiimi Sosiaalinen media suomessa Kaikista suomalaisista yli % on rekisteröitynyt

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

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

Lisätiedot

Viitearkkitehtuurin suunnitteluprosessi. Ohje. v.0.7

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

Lisätiedot

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

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

Lisätiedot

Project group Tete Work-time Attendance Software

Project group Tete Work-time Attendance Software Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: etenemisraportti Projektin etenemisen seuranta ja kontrollointi Niilo Fredrikson T-76.115 Software project 2(5) Muutosloki

Lisätiedot

Vapaapäivien optimointi

Vapaapäivien optimointi Mat-2.4177 Operaatiotutkimuksen projektityöseminaari Vapaapäivien optimointi Väliraportti, 4.4.2014 Asiakas: Computational Intelligence Oy Projektiryhmä: Teemu Kinnunen (projektipäällikkö) Ilari Vähä-Pietilä

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

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

Eläinlääketieteen lisensiaatin tutkielma Seminaarityöskentelyohjeet

Eläinlääketieteen lisensiaatin tutkielma Seminaarityöskentelyohjeet Eläinlääketieteen lisensiaatin tutkielma Seminaarityöskentelyohjeet Eläinlääketieteellinen tiedekunta Helsingin yliopisto 2017 1 Yleistä Eläinlääketieteen lisensiaatin tutkielman seminaarityöskentelyyn

Lisätiedot

Kajaanin ammattikorkeakoulu Opinnäytetyösuunnitelman ohje

Kajaanin ammattikorkeakoulu Opinnäytetyösuunnitelman ohje Kajaanin ammattikorkeakoulu Opinnäytetyösuunnitelman ohje Tutkintonimike Koulutus Syksy / Kevät 201X Opinnäytetyön aiheen valinnan ja aiheanalyysin hyväksynnän jälkeen tehdään opinnäytetyösuunnitelma.

Lisätiedot

Pysähdy! Nyt on syytä miettiä tämä asia uudelleen. Kiinnitä huomiosi tähän. Hienoa, jatka samaan malliin. Innokylän arviointimittari

Pysähdy! Nyt on syytä miettiä tämä asia uudelleen. Kiinnitä huomiosi tähän. Hienoa, jatka samaan malliin. Innokylän arviointimittari Innokylän arviointimittari Innokylän arviointimittari on kehittämistoiminnan itse- ja vertaisarvioinnin työkalu, jonka avulla arvioidaan kehittämisprosessia ja kehittämisen tavoitteiden saavuttamista.

Lisätiedot

Miten asiakaspolku näkyy asiakaskokemuksen seurannassa?

Miten asiakaspolku näkyy asiakaskokemuksen seurannassa? YHTEENVETO 25.4.2017 Feelback Oy Pieni Robertinkatu 9, 00130 HELSINKI Y-tunnus 1702297-8 www.feelback.com Miten asiakaspolku näkyy asiakaskokemuksen seurannassa? Tausta!! - Asiakaspolku - Tutkimuksen toteuttaminen

Lisätiedot

1.3 Katsaus ohjelmistotuotannon kehittymiseen

1.3 Katsaus ohjelmistotuotannon kehittymiseen Yleisiä asioita Oliokirja:http://www.cs.tut.fi/~kk/Ohjelmistoarkkitehtuuri.pdf Tenttipäivä 7.5. Tallennukset, jospas tänään onnistaisi Viikkoharkat löytyvät IDLEstä (TTY), kurssin kotisivuilta/paikallisilta

Lisätiedot

YHTEISTYÖSTÄ LISÄVOIMAA YHDISTYKSILLE -MITEN PÄÄSTÄ ALKUUN?

YHTEISTYÖSTÄ LISÄVOIMAA YHDISTYKSILLE -MITEN PÄÄSTÄ ALKUUN? Kehittämistehtävä (AMK) Hoitotyö Terveydenhoitotyö 3.12.2012 Elina Kapilo ja Raija Savolainen YHTEISTYÖSTÄ LISÄVOIMAA YHDISTYKSILLE -MITEN PÄÄSTÄ ALKUUN? -Artikkeli julkaistavaksi Sytyn Sanomissa keväällä

Lisätiedot

Hyviä käytäntöjä asiakkaan osallisuutta vahvistavaan kohtaamiseen Kehittäjätyöntekijät: Katriina Kunttu, Eksote Ellinoora Mantere, Rovaniemen

Hyviä käytäntöjä asiakkaan osallisuutta vahvistavaan kohtaamiseen Kehittäjätyöntekijät: Katriina Kunttu, Eksote Ellinoora Mantere, Rovaniemen Hyviä käytäntöjä asiakkaan osallisuutta vahvistavaan kohtaamiseen Kehittäjätyöntekijät: Katriina Kunttu, Eksote Ellinoora Mantere, Rovaniemen kaupunki Asiakkaan osallisuus alkaa ensikontaktista Ennen tapaamista

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

Kokonaisuuksien, riippuvuuksien ja synergioiden hahmottaminen helpottuvat

Kokonaisuuksien, riippuvuuksien ja synergioiden hahmottaminen helpottuvat Johtaminen voidaan jakaa karkeasti kolmeen osaan: 1. Arvojohtaminen (Leadership) 2. Työn(kulun) johtaminen (Process management) 3. Työn sisällön ja tulosten/ tuotosten johtaminen (esim. Product management)

Lisätiedot

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2007

1 Johdanto. TTY Ohjelmistotekniikka. Ohjelmistoarkkitehtuurit Syksy 2007 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Katsaus ohjelmistotuotannon kehittymiseen 1.3 Epäonnistuneen ohjelmistoarkkitehtuurin seurauksia 1.4 Ohjelmistoarkkitehtuuri ja ohjelmistokehitysprosessi

Lisätiedot

Arkkitehti?

Arkkitehti? 1 Johdanto 1.1 Mikä on ohjelmistoarkkitehtuuri? 1.2 Ohjelmistoarkkitehtuuri ja laatuvaatimukset 1.3 Katsaus ohjelmistotuotannon kehittymiseen 1.4 Miksi ohjelmistoarkkitehtuuri on tärkeä 1.5 Ohjelmistoarkkitehtuuri

Lisätiedot

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti

SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Järjestelmäprojekti 1 projektisuunnitelma ICT4TN007-2 SALAKIRJOITUKSEN VAIKUTUS SUORITUSKYKYYN UBUNTU 11.10 käyttöjärjestelmässä -projekti Versio 0.1 Tekijät Keijo Nykänen Tarkastanut Hyväksynyt HAAGA-HELIA

Lisätiedot

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus

Ohjelmistoprosessit ja ohjelmistojen laatu Kevät Ohjelmistoprosessit ja ohjelmistojen laatu. Projektinhallinnan laadunvarmistus LAADUNVARMISTUS 135 Projektinhallinnan laadunvarmistus Projektinhallinnan laadunvarmistus tukee ohjelmistoprojektien ohjaus- ja ylläpitotehtäviä. Projektinhallinnan laadunvarmistustehtäviin kuuluvat seuraavat:

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

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

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

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

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

Lisätiedot

Ylläpito. Ylläpidon lajeja

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

Lisätiedot

T Projektikatselmus

T Projektikatselmus T-76.115 Projektikatselmus Projektityöryhmä GenCode I3-iteraatio 17.3.2004 Agenda Tavoitteiden toteutuminen (5 min) Resurssien käyttö (5 min) Iteraation tulokset (10 min) Riskit (5min) +Kokemuksia työskentelymenetelmistä

Lisätiedot

Uusi Seelanti. katju.holkeri@vm.fi

Uusi Seelanti. katju.holkeri@vm.fi Uusi Seelanti katju.holkeri@vm.fi Tavoite 1 Haluttu työnantaja Varmistaa, että valtionhallinto on työnantajana houkutteleva hyville, sitoutuneille työntekijöille. Tavoite 2 Erinomaiset virkamiehet Luoda

Lisätiedot

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma

Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma Enterprise SOA. Nyt. Systeemi-integraattorin näkökulma 12.11.2007 Janne J. Korhonen 12.11.2007 Agenda 1. Prosessit ja palvelut, BPM ja SOA 2. BPM-projekteista yleensä 3. Prosessin elinkaarimalli 4. Kokemuksia

Lisätiedot

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

PEILISALI - sosiaalityön reflektiivisen itsearvioinnin lomake

PEILISALI - sosiaalityön reflektiivisen itsearvioinnin lomake Kuvastin PEILISALI - sosiaalityön reflektiivisen itsearvioinnin lomake Peilisalin itsearviointiteemojen avulla työntekijä voi reflektoida tekemäänsä työtä ja asiakkaan tilannetta ikään kuin ulkopuolisen

Lisätiedot

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

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

Lisätiedot

Ohjelmistoarkkitehtuurit. Syksy 2010

Ohjelmistoarkkitehtuurit. Syksy 2010 Ohjelmistoarkkitehtuurit Syksy 2010 Kai Koskimies Tervetuloa Oulun yliopisto, Tampereen yliopisto, Turun yliopisto, Tampereen teknillinen yliopisto, Vaasan yliopisto Kurssin tavoitteet Arkkitehtuurin roolin

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

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

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu KÄYTTÖOHJE. LiKe Liiketoiminnan kehityksen tukiprojekti

Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu KÄYTTÖOHJE. LiKe Liiketoiminnan kehityksen tukiprojekti Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu JÄRJESTELMÄN KÄYTTÖOHJE LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 13.2.2001

Lisätiedot

KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1

KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1 KOKONAISSUUNNITELMA KEHITTÄMISTEHTÄVÄLLE lomake 1 TYÖRYHMÄN NIMI: pvm: jolloin täytetty työryhmän kanssa KEHITTÄMISTEHTÄVÄN NIMI TAVOITTEET Leppävaaran sosiaaliohjaajat (Espoo, lastensuojelun avopalvelut)

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