Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS ...T-76.650 Ohjelmistotuotannon...

T-76.650 Ohjelmistotuotannon seminaari, TKK, kevät 2002.

Seppo Sahi, Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS 4CCviitekehystä.

1

Ketterienohjelmistokehitysmallien

analyysi käyttäen SEMS 4CCviitekehystä

Extreme Programming, Microsoft Synch-and-Stabilize,SCRUM, Dynamic Systems Development Method

Seppo Sahi 48027S



2

Tiivistelmä

Kirjoittaja: Seppo Sahi

Tutkielman nimi: Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS4CC viitekehystä

Päiväys: 15.4.2002 Sivuja: 26

Tutkimuksen aiheena on tutkia voidaanko ketteriä ohjelmistokehitysmetodologioitakuvata käyttäen 4CC viitekehystä. Tutkimuksen kohteeksi valittiin metodologiatMicrosoft Synch-and-Stabilize, Extreme Programming, Scrum ja Dynamic SystemsDevelopment Method.

4CC viitekehys yhdistää ohjelmistoyrityksen liikkeenjohdon ja tuotekehityksennäkökulmat toisiinsa. Sitä voidaan käyttää sekä yrityksen nykyisenohjelmistokehitystoiminnan arviointiin, että sen kehittämiseen.

Tutkimuksessa havaittiin, että Microsoftin Synch-and-Stabilize on tutkielmanmetodologioista selvästi kaikkein kokonaisvaltaisin. Se on metodologioista ainoa jokamäärittelee keinot tuotteen julkaisujen pitkäaikaissuunnitteluun. Tämä saattaakuitenkin kaventaa kyseisen metodologian sovellusaluetta, koska kaikkia senkäytäntöjä ei varmaankaan voi sellaisenaan soveltaa monessakaan yrityksessä.

Tutkielman analyysista saatiin myös tukea kokemuksille joiden mukaan ExtremeProgramming ja Scrum tukevat toisiansa.

Yleisesti ottaen ketterien ohjelmistokehitysmetodologioiden kuvaaminen 4CCviitekehyksellä onnistui kiitettävästi sillä suurin osa tutkimukseen valittujenmetodologioiden tärkeimmistä ominaisuuksista pystyttiin sijoittamaan viitekehyksenmukaiseen jakoon.

Avainsanat: Four Cycles of Control, 4CC, Synch-and-Stabilize, ExtremeProgramming, Scrum, Dynamic Systems Development Method



3

Sisällysluettelo

Tiivistelmä ........................................................................................................................ 2

Sisällysluettelo .................................................................................................................. 3

1 Johdanto ........................................................................................................................ 51.1 Tutkielman tausta.............................................................................................. 51.2 Tutkimusongelma ja tutkimuksen tavoitteet..................................................... 51.3 Tutkielman rajaukset ........................................................................................ 61.4 Tutkimusmenetelmät ........................................................................................ 61.5 Tutkielman rakenne .......................................................................................... 6

2 Aikaisemman tiedon kuvaus ......................................................................................... 72.1 Mikä tekee metodologiasta ketterän? ............................................................... 72.2 4CC viitekehys.................................................................................................. 72.3 Extreme Programming...................................................................................... 92.4 Microsoft Synch-and-Stabilize ....................................................................... 112.5 Scrum 122.6 Dynamic Systems Development Method........................................................ 13

3 Analyysi ...................................................................................................................... 163.1 Strateginen tuotejulkaisujen ohjaussykli ........................................................ 16

3.1.1 Extreme Programming........................................................................ 163.1.2 Synch-and-Stabilize............................................................................ 163.1.3 Scrum.................................................................................................. 163.1.4 Dynamic Systems Development Method ........................................... 16

3.2 Julkaisuprojektin ohjaussykli.......................................................................... 173.2.1 Extreme Programming........................................................................ 173.2.2 Synch-and-Stabilize............................................................................ 173.2.3 Scrum.................................................................................................. 173.2.4 Dynamic Systems Development Method ........................................... 18

3.3 Iteraation ohjaussykli ...................................................................................... 183.3.1 Extreme Programming........................................................................ 183.3.2 Synch-and-Stabilize............................................................................ 193.3.3 Scrum.................................................................................................. 193.3.4 Dynamic Systems Development Method ........................................... 19

3.4 Mini-milestone................................................................................................ 203.4.1 Extreme Programming........................................................................ 203.4.2 Synch-and-Stabilize............................................................................ 203.4.3 Scrum.................................................................................................. 203.4.4 Dynamic Systems Development Method ........................................... 20

4 Johtopäätökset............................................................................................................. 22

5 Tutkielman arviointia.................................................................................................. 24



4

6 Yhteenveto ...................................................................................................................25

Lähdeluettelo ...................................................................................................................26



5

1 Johdanto

1.1 Tutkielman tausta

Tutkielma tehdään Teknillisessä korkeakoulussa järjestettävän Ohjelmistotuotannonseminaarikurssin seminaarityönä. Seminaarikurssin aiheena keväällä 2002 on ketteräohjelmistokehitys.

SEMS on Ohjelmistotuotannon- ja liiketoiminnan instituutin vuonna 2001 alkanutprojekti, jonka tavoitteena on parantaa pienten ja keskikokoistenohjelmistotuoteyritysten ohjattavuutta ja ohjelmistotuotantoprosesseja sekä tätä kauttaparantaa niiden kannattavuutta ja auttaa niitä kasvamaan. Tavoitteena on myös auttaayrityksiä itseään sekä niiden potentiaalisia rahoittajia arvioimaan yrityksen käyttämienohjelmistotuotantometodien kypsyyttä ja laatua. Tutkielman kirjoittaja ei ole itsemukana tässä projektissa.

Four Cycles of Control (4CC) on SEMS projektin kehittämä viitekehys joka onsuunniteltu pienten ja keskisuurten yritysten ohjelmistotuoteliiketoiminnan jaohjelmistokehitystoiminnan analysointiin ja kehittämiseen. Viitekehys pyrkiiyhdistämään yrityksen liiketoiminta- ja ohjelmistokehitysnäkökulmia toisiinsayksinkertaisella, käytännöläheisellä ja nimenomaan pieniä ja keskisuuria yrityksiähyödyttävällä tavalla. 4CC kehittäjien motivoivana voimana on ollut olemassa olevienreferenssimallien, lähinnä CMM:n ja SPICE:n sopimattomuus pienten yritystentarpeisiin johtuen kyseisten mallien massiivisuudesta.

1.2 Tutkimusongelma ja tutkimuksen tavoitteet

Tutkimusongelmana on selvittää voidaanko ketteriä ohjelmistokehitysmetodologioitakuvata käyttäen 4CC viitekehystä?

Kysymys on mielenkiintoinen, koska sen kautta voidaan saada ymmärrystä tutkimuksenkoohteena olevien metodologioiden ominaisuuksista. Tämä puolestaan mahdollistaametodologioiden vertailemisen. Toisaalta 4CC viitekehys on hyvin nuori jotentutkimuksen avulla voidaan myös testata sen soveltuvuutta nimenomaan tähänsovellusalueeseen.

Tavoitteena on osaltaan antaa vastauksia seuraaviin kysymyksiin: Mihin viitekehyksenosaan metodologia ottaa kantaa ja millä tavalla? Mitä tämän jaottelun perusteellavoidaan päätellä valituista metodologioista? Miten valitut metodologiat eroavattoisistaan viitekehyksen läpi analysoituna?

Tutkielman tavoitteena on yhtäältä laajentaa tutkielman tekijän näkemystä ketteristäohjelmistokehitysmetodologioista sekä toisaalta parantaa hänen taitojaan tieteellisentutkimuksen tekemisessä.



6

1.3 Tutkielman rajaukset

Tutkielma rajataan käsittelemään seuraavia metodologioita: Extreme Programming(XP), Microsoft Synch-and-Stabilize, Scrum sekä Dynamic Systems DevelopmentMethod (DSDM) Tällä rajauksella halutaan saada tutkimuksen tekemiseen käytettytyömäärä vastaamaan seminaarikurssin työmäärävaatimuksia.

1.4 Tutkimusmenetelmät

Tutkimus suoritetaan kokonaisuudessaan kirjallisuustutkimuksena.

1.5 Tutkielman rakenne

Kappale 2. Aikaisemman tiedon kuvaus selventää valittujen metodologioidenpääominaisuudet sekä kertoo 4CC viitekehyksestä sen mitä lukija tarvitseeymmärtääkseen tutkielman loppuosan.

Kappale 3. Analyysi jakaa valittujen metodologioiden ominaisuudet 4CC viitekehyksenmukaisiin kokonaisuuksiin.

Kappale 4. Johtopäätökset sisältää tutkielman kirjoittajan näkemyksiä ja johtopäätöksiäedellisessä kappaleessa suoritetusta jaosta.

Kappale 5. Tutkielman arviointia sisältää tutkielman kirjoittajan subjektiivisenmielipiteen tutkimuksen onnistumisesta.

Kappale 6. Yhteenveto sisältää yhteenvedon tutkielman pääkohdista.



7

2 Aikaisemman tiedon kuvaus

2.1 Mikä tekee metodologiasta ketterän?

Ketterien metodologioiden päällimmäisenä tavoitteena on tuottaa asiakkaalle toimiviaohjelmistojulkaisuja. Kyseisissä metodologioissa toimivaa ohjelmistoa pidetään sekäonnistumisen, että edistymisen mittarina (Cockburn, 2001).

(Cockburn, 2001) määrittelee ketterän metodologian olevan mahdollisimman kevyt,mutta silti tarkoitukseensa riittävä. Samalla sen tulisi olla hyvin pitkälle itseohjautuvasekä ympäristöön ja vaatimuksiin mukautuva.

Ketterät ohjelmistokehitysmallit olettavat, että ohjelmistolle asetetut vaatimuksetmuuttuvat ja kehittyvät jatkuvasti koko kehitystyön ajan. Kehitystyö on yleensäiteratiivista, jotta tuotettuja inkrementtejä voidaan käyttää palautteena ja vaatimuksientarkentajina. Ketterät metodologiat pitävät kehitystiimin kommunikaationsaumattomuutta tärkeänä menestystekijänä ja luottavat hyvin pitkälle tiimien kykyynratkaista ongelmia. Dokumentointi nähdään kommunikointimenetelmänä muidenjoukossa ja se koetaan yleensä tarpeelliseksi vain jos kommunikaatiolle halutaanpysyvyyttä (Cockburn, 2001).

2.2 4CC viitekehys

Seuraavassa esitellään 4CC viitekehyksen pääkohdat niinkuin ne on lähteessä(Rautiainen et al., 2002) kerrottu.

Four Cycles of Control (4CC) on viitekehys ohjelmistotuotekehityksen johtamiseen jasuunniteluun pienissä ja keskisuurissa yrityksissä. Kehittäjiensä mukaan viitekehysyhdistää yrityksen liikkeenjohdon ja ohjelmistokehityksen näkökulmat toisiinsakokonaisvaltaisella, yksinkertaisella ja käytännönläheisellä tavalla. Viitekehystä voidaankäyttää sekä yrityksen nykyisen ohjelmistotuotekehitystoiminnan arviointiin, että senkehittämiseen.

Motivaationa viitekehyksen kehittäjillä on ollut olemassa olevien referenssimallien,kuten CMM:n ja SPICE:n sopimattomuus pienten yritysten tarkoituksiin. Kyseisetmallit ovat turhan mahtipontisia pienille yrityksille eivätkä itseasiassa anna riittävääratkaisua pienten yritysten liiketoiminnan suunnitteluun. Lisäksi nämä mallit onsuunniteltu lähinnä projektiliiketoiminnan tarpeisiin.

Kuva 1 visualisoi viitekehyksen pääosat. Kunkin kontrollisyklin tarkoitus on suunnitellatavoitteet kuvassa oikealla olevalle syklille jonka jälkeen oikealla oleva sykli toteuttaanämä suunniteltujen raamien puitteissa. Kaaviokuvassa palaute edistymisestä kulkeeoikealta vasemmalle ja esimerkiksi markkinaympäristön vaatimukset vasemmaltaoikealle. Syklien koot ilmentävät syklin läpiviemiseen kuluvaa aikaa.



8

Kuva 1. 4CC viitekehys (Vähäniitty, 2002)

Strateginen tuotejulkaisujen ohjaussykli (engl. Strategic release management)muodostaa rajapinnan liikkeenjohdon ja ohjelmistokehitystoiminnan välille, sillä senaikana tuotteen eri sidosryhmät päättävät tuotejulkaisujen ajoituksesta ja sisällöstä,resurssien jakamisesta sekä teknologisista pääsuuntaviivoista. Syklin aikana tehtäviinpäätöksiin vaikuttaa ennenkaikkea yrityksen suunniteltu strategia sekä resurssiensaatavuus. Sykliin liittyy olennaisena osana vaatimusten pitkäaikaishallinta. Kuvasta 1.nähdään eri sidosryhmät vaatimusten lähteinä.

Julkaisuprojektin ohjaussyklissä (engl. Release project management) hallitaanyksittäistä julkaisuprojektia. Syklin tehtävänä on määrittää esim. iteraatiosyklien määrä,sisältö, ajallinen pituus ja budjetti strategisessa tuotejulkaisujen ohjaussyklissäasetettujen vaatimusten toteutumiseksi. Julkaisuprojektin ohjaussykli antaa strategiselletuotejulkaisujen ohjaussyklille palautetta edistymisestä ja onnistumisesta.

Iteraation ohjaussyklin (engl. Iteration management) tarkoituksena on tuottaa vakaa jatoimiva tuotejulkaisun inkrementti jota voidaan käyttää palautteen saamiseksi javaatimusten tarkentamiseksi. Jokaisen iteraation aikana jokin joukko määriteltyjävaatimuksia muutetaan toimivaksi toiminnallisuudeksi tuotteeseen. Jotta iteraationhallitseminen olisi helpompaa Iteration management syklissä suunnitellaan myösiteraation jakaminen pienempiin askeliin joita kutsutaan viitekehyksessä termillä mini-



9

milestone. Iteraation ohjaussykli tuottaa myös yksityiskohtaisen tehtäväluetteloniteraation läpiviemiseksi.

Mini-milestonejen (engl. Mini-milestones) tarkoitus on helpottaa kokonaisuudenhallintaa sekä auttaa mittaamaan edistymistä iteraation aikana. Tarkoitus on siissynkronoida yksittäisten kehittäjien tuotokset suuremmaksi kokonaisuudeksi. Mini-milestoneja voivat olla esimerkiksi päivittäiset buldit.

Kuvan 1. alaosan nuolilla on kuvattu ohjelmistotuotannon eri aktiviteettikategoriatjoihin syklien aikana tapahtuva toiminta voidaan jakaa.

Suunnittelulla ja seurannalla (engl. Planning and monitoring) tarkoitetaan prosessinaikataulutuksen ja toteutuksen suunnittelua sekä seuraamista. Käytännössä tämätarkoittaa esimerkiksi vastuujakojen suunnittelua, aikataulujen suunnittelua ja seurantaasekä tuotejulkaisujen ja projektien onnistumisen arviointia.

Ohjelmistosuunnittelulla ja toteutuksella (engl. Design and implementation) tarkoitetaankaikkea ohjelmistotuotteen arkkitehtuurin suunnitteluun ja toteutukseen liittyväätoimintaa.

Tuotehallinto (engl. Product management) käsittää ohjelmiston komponenttien,konfiguraatioiden ja versioiden hallinnan.

Vaatimusten hallinnan (engl. Requirements engineering) päällimmäinen tavoite onvarmistaa, että lopputuote vastaa asiakkaiden vaatimuksia. Tämä sisältää vaatimustenkartoittamisen, analysoinnin, priorisoinnin sekä vaatimusmuutosten hallinnan.

Testauksella ja laadunvarmistuksella (engl. Verification and validation) tarkoitetaantuotteen laatutavoitteiden määrittämistä ja seurantaa sekä toisaalta näihinlaatutavoitteisiin pääsemiseksi suoritettua toimintaa.

4CC mallia tarkasteltaessa tulee muistaa, että mikäli jokin yksittäinen metodologia eiota kantaa kaikkiin viitekehyksen ohjaussykleihin ei automaattisesti tarkoita, ettäkyseinen metodologia olisi huono vaan pikemminkin kyse on painotuksesta jafokusoitumisesta johonkin tiettyyn ohjelmistokehityksen osa-alueeseen.

2.3 Extreme Programming

Extreme Programming (XP) lähtee yksinkertaisesta olettamuksesta, että ohjelmistonvaatimukset ovat muuttuvia ja muutosten määrä sekä ominaisuudet ovat ennaltaarvaamattomia. XP:n filosofian mukaan on turhaa suunnitella arkkitehtuuriatulevaisuutta varten, koska tulevaisuudessa suunnittelulähtökohdat saattavat kuitenkinolla täysin erilaiset.

XP pyrkii hallitsemaan tätä kaaosta kahdentoista käytännön avulla (Beck, 2000). Näitäovat suunnittelupeli (engl. planning game), pienet julkaisut (engl. small releases),metafora (engl. metaphor), yksinkertainen design (engl. simple design), testaus (engl.testing), refaktorointi (engl. refactoring), pariohjelmointi (engl. pair programming),kollektiivinen koodin omistaminen (engl. collective ownership), jatkuva integrointi



10

(engl. continious integration), 40-tuntinen viikko (engl. 40-hour week), on-site asiakas(engl. on-site customer), ohjelmointistandardit (engl. coding standards). Ohessa aukikirjoitettuna tämän tutkielman kannalta olennaisimmat käytännöt. Muut käytännöt ovatkäytäntöjä joita ei voida sioittaa 4CC mallin mihinkään osaan.

XP on iteratiivinen metodologia. XP:ssa iteraation pituus vaihtelee viikosta kolmeenviikkon. XP:n terminologian mukaisilla pienillä julkaisuilla tarkoitetaan nimenomaansitä, että ohjelmistoinkrementtejä tulisi julkaista mahdollisimman usein.

XP:n suunnittelupelissä asiakas päättää seuraavan toteutettavan inkrementin laajuudenja aikataulun. Käytännössä tämä tapahtuu siten, että asiakas valitsee ”ostoskoriinsa”haluamiansa käyttäjätarinoita. Kehittäjät ovat ennen suunnittelupeliä hinnoitelleetkäyttäjätarinat sen mukaan kuinka paljon he arvioivat niiden toteuttamiseen kuluvanaikaa.

Ennen ohjelmiston toteutuksen aloittamista määritellään metafora. Sillä tarkoitetaanohjelmistosuunnittelun lähtökohtana käytettävää tarinaa. Koska suurin osaohjelmistosuunnittelutyöstä tehdään ikäänkuin hajautetusti ohjelmointityön yhteydessä,niin on perusteltua käyttää metaforaa arkkitehtuurisuunnittelun korvaajana. Metaforatarkentuu sitä mukaa mitä enemmän ohjelman koodista on valmiina.

Itse kehitystyö tehdään XP:ssä aina pariohjelmointina. Pariohjelmoinnissa kaksiohjelmoijaa työskentelee käyttäen työkaluna yhtä tietokonetta. Eräs ohjelmointiparinpaivittäisistä rutiineista on uuden koodin integroiminen suurempaan kokonaisuuteenvähintään kerran päivässä. XP:n termien mukaan puhutaan jatkuvasta integroinnista.Integroinnin yhteydessä kaikki yksikkötestit on ajettava onnistuneesti tai muutokset onhylättävä. Jatkuvan integroinnin ansiosta saatavilla on koko ajan toimiva versioohjelmasta.

XP:n prinsiippien mukaan ohjelmiston design tulisi säilyttää mahdollisimmanyksinkertaisena. Toisinsanoen yksinkertainen design tarkoittaa XP:ssä sitä, ettäohjelmistosuunnittelussa ei tulisi ajatella tulevaisuutta liikaa vaan ohjelmoida niinyksinkertaisesti kuin vain on mahdollista toteuttaa vaaditut ominaisuudet.Refaktoroinnilla eli vanhan ohjelmakoodin ajoittaisella uudelleen organisoinnillavarmistetaan, että yksinkertaisen designin periaatetta noudattamalla tuotettu koodi onarkkitehtuurisesti laadukasta ja vakaasti toimivaa.

Testaus on eräs XP:n ydintekniikoista. Jokainen tuotantoon menevä ominaisuus ontestattava yksikkötesteillä. Ohjelmoijat kirjoittavat itse yksikkötestit omilleohjelmakokonaisuuksilleen ennen itse ohjelmakoodin kirjoittamista. Tällöin testienkirjoittaminen toimii myös suunnittelun apuvälineenä. Yksikkötesteistä tehdäänautomaattisia ja niiden tulee toimia aina siitä lähtien kun ne on kirjoitettu.Funktionaaliset testit ohjelmistoinkrementille kirjoittaa asiakas.

On-site asiakas toimii fyysisesti kehitystiimin läheisyydessä ja vastaa kehitystyön aikananouseviin kysymyksiin. On-site asiakkaan avulla pienennetäänkommunikaatiokustannuksia kehitystiimin ja asiakkaan välillä.



11

Osa näistä käytännöistä on ollut olemassa jo pitkään ennen XP:n kehittämistä. XP:ssaon uutta se, että käytännöt yhdistetään toisiansa tukevaksi kokonaisuudeksi. Esimerkiksiyksikkötestaus ja pariohjelmointi tukevat toisiaan sillä pareittain yksikkötestiensuunnittelu ja kirjoittaminen on nopeampaa (Beck, 2000).

2.4 Microsoft Synch-and-Stabilize

Microsoftin Synch-and-Stabilizea voidaan pitää ketteränä metodologiana siinä mielessä,että se pyrkii sopeutumaan nopeasti markkinoiden muuttuviin vaatimuksiin. Synch-and-stabilize ei myöskään ole dokumenttivetoinen niinkuin perinteinen vesiputoismalli.

Lähteen (Cusumano & Smith, 1997) mukaan kehitysmalli etenee seuraavasti. Synch-and-Stabilize lähtee liikkeelle suunnitteluvaiheella, jonka aluksi määritellään tuotevisio.Sen tarkoituksena on kertoa kehitettävän tuotteen tavoitteet ja se perustuu priorisoituihinkäyttäjävaatimuksiin. Tuotevisio korvaa osittain vesiputousmallin funktionaalisenmäärittelyn. Synch-and-Stabilize sisältää myös funktionaalisen määrittelyn, mutta seelää ohjelmiston koko kehityskaaren ajan ja sen oletetaan olevan lopullinen vasta kuntuote on valmis. Tämän jälkeen tehdään suunnitelma työn jakamisesta kehityssykleihin,joita Synch-and-Stabilizessa kutsutaan alisykleiksi (engl. subcycle). Kunkin syklinaikataulu on lyöty lukkoon ja toteutettavat ominaisuudet on priorisoitu, jottaalhaisimman prioriteetin ominaisuuksia voidaan jättää pois mikäli kaikkea ei ehditätoteuttaa. Toiminnallisuuskokonaisuuksille määritetään vastuulliset tiimit, joiden kokoon yleensä kymmenen hengen molemmin puolin. Tiimi sisältää yleensä yhtä paljontestaajia kuin kehittäjiä.

Kunkin alisyklin aikana kehittäjät suunnittelevat, toteuttavat ja debugaavat suunnitelluttoiminnallisuudet. Testaajat toimivat pareittain kehittäjien kanssa ja testaavat heidäntyötään jatkuvasti. Kehittäjät synkronoivat joka päivä tuottamansa koodin päivittäistenbuildien muodossa. Syklin loppuvaiheessa julkaisu stabiloidaan eli uusientoiminnallisuuksien toteuttaminen lopetetaan ja keskitytään ainoastaan testaamiseen jadebugaamiseen. Jokaisen syklin lopputuloksena julkaistaan tuotejulkaisu. Viimeisessäsyklissä tämä julkaisu on lopullinen markkinoille tuleva tuote ja muissa se on alpha- taibetajulkaisu.

Viimeinen kehityssykli on samanlainen kuin sitä edeltävätkin, mutta se sisältääylimääräisen stabilointivaiheen jota ennen käyttöliittymä jäädytetään, jotta tuotteendokumentaatio voidaan saattaa valmiiksi.



12

Kuva 2. Microsoft Synch-and-Stabiize kehitysmalli (Cusumano & Yoffie, 1999)

2.5 Scrum

Seuraavan kuvauksen tiedot ovat kokonaisuudessaan lähteestä (Beedle et al., 2001).

Scrum on metodologia 6-8 hengen tiimeille. Scrumissa tuotepäällikkö (engl. Productowner) ylläpitää tuotteen käsiteltävien asioiden listaa (engl. Product backlog). Tähän onlistattu prioriteettijärjestyksessä tuotteen käyttäjävaatimukset. Kaikki muutokset tähänlistaan kulkevat tuotepäälikön kautta.

Itse kehitystyö tehdään tasan 30 päivän mittaisissa iteraatioissa joita kutsutaansprinteiksi. Ennen sprinttiä pidetään suunnittelupalaveri (engl. Sprint planning meeting)jossa on läsnä asiakkaat, käyttäjät, johto, tuotepäällikkö ja Scrum tiimi. Palaverissapäätetään seuraavan sprintin laajuus eli täytettävät käyttäjävaatimukset sekä sprintintavoite (engl. Sprint goal). Tämän jälkeen iteraation laajuutta ei voida enää muuttaa jascrum tiimille on taattava työrauha tavoitteeseen pääsemiseksi.

Suunnittelupalaverin jälkeen scrum tiimi pitää oman palaverin jossa hahmotellaanarkkitehtuurisia suuntaviivoja sekä luodaan tarkempi tehtäväluettelo sprintintekemättömistä tehtävistä.

Sprintin aikana Scrum tiimi pitää kerran päivässä palaverin jota kutsutaan nimelläpäivittäinen scrum (engl. Daily Scrum). Päivittäisen scrumin tarkoituksena on auttaa



13

tiimiä ja projektin johtoa seuraamaan edistymistä, tukea tiimin kommunikaatiota sekäautaa johtoa tunnistamaan ja poistamaan kehitystyötä haittaavia esteitä.

Sprintin päätyttyä pidetään sprintin tarkastelupalaveri (engl. Sprint review meeting).Palaverissa katselmoidaan sprintin aikana tuotettu ohjelmistoinkrementti. Palaverinjälkeen tuotteen käsiteltävien asioiden lista päivitetään vastaamaan nykytilannetta.

Scrum mestari (engl. Scrum master) on henkilö joka on vastuussa scrumin mukaistenkäytäntöjen toteutumisesta. Mestari mm. johtaa päivittäiset scrum palaverit. Hänentehtävänään on myös valvoa, että scrum tiimi saa työskennellä rauhassa. Ei nimittäin olelainkaan harvinaista, että kehitystiimin jäseniltä tullaan kyselemään, että ’voisiko vielätämän ominaisuuden toteuttaa’ kuluvan sprintin aikana.

Sscrum ottaa huomioon ohjelmistokehityksen kaaottisuuden ja olettaa jokaisenohjelmistoprojektin olevan erilainen. Scrum on niin kutsuttu empiirinen prosessimallijossa Scrum tiimi kehittyessään ja tiivistyessään löytää yhdessä tien jolla sprintintavoitteet täyttyvät. Scrum tiimissä ei varsinaisesti ole rooleja vaan jokainen jäsen tekeesitä mitä parhaiten osaa.

2.6 Dynamic Systems Development Method

DSDM on kehittäjiensä (Stapleton, 1997) mukaan kokoelma parhaaksi katsottujakäytäntöjä laadukkaan ohjelmiston nopeaan kehittämiseen. DSDM pohjautuu yhdeksäänpääperiaatteeseen: 1. käyttäjien tulee osallistua aktiivisesti kehitysprosessiin, 2. DSDMtiimeillä pitää olla tarpeeksi valtaa tehdä päätöksiä, 3. kehitysprosessin tulee fokusoituatuottamaan uusia tuoteinkrementtejä mahdollisimman usein, 4. tuoteinkrementtejäarvioidaan pääosin käyttäjätarpeiden täyttymisen perusteella, 5. kehitystyössä käytetääniteratiivista ja inkrementaalista mallia, 6. kaikki kehitystyön aikana tehdyt muutokset onpystyttävä perumaan, 7. vaatimukset on pystyttävä lyömään lukkoon karkealla tasollaprojektin alussa, 8. testaus tulee integroida jatkumaan koko tuotteen kehityskaaren ajanja 9. onnistunut yhteistyö sidosryhmien välillä on elintärkeää. Näistä ensimmäiset neljäon kivijalka jonka varaan DSDM on rakennettu ja loput viisi on periaatteita joita tuleenoudattaa DSDM prosessissa.

Kuva 3. visualisoi DSDM prosessin kulun. Jokainen DSDM prosessi alkaaesitutkimuksella (engl. feasibility study) jonka aikana päätetään kannattaako projektiaryhtyä toteuttamaan. Esitutkimusvaiheessa harkitaan myös kannattaako DSDM malliakäyttää kyseisessä projektissa. Vaihe kestää tyypillisesti muutaman viikon.

Businesstutkimusvaiheessa (engl. Business study) kartoitetaan ja priorisoidaantoiminnalliset ja ei toiminnalliset vaatimukset karkealla tasolla. Yleensä tämä tehdäänsidosryhmien ryhmätyönä. Myös arkkitehtuurinen suunnitelma (engl. Systemarchitecture definition) sekä prototypisointisuunnitelma (engl. Prototyping plan) tehdääntässä vaiheessa. Prototypisointisuunnitelma sisältää alustavan suunnitelman kaikistakehitystyön aikana tehtävistä prototyypeistä. Kaikki dokumentit ovat luonnoksia joidentarkentaminen kehitystyön edetessä on sallittua ja suositeltavaa.Businesstutkimusvaiheen tulisi kestää alle kuukauden.



14

Kuva 3. DSDM prosessi (Stapleton, 1997)

Esitutkimus ja businesstutkimusvaihe suoritetaan peräkkäin. Seuraavat kolme vaihettaovat luonteeltaan iteratiivisiä joten niitä kutakin voidaan suorittaa useampia kertoja.Vaiheita voidaan myös suorittaa osittain päällekkäin ja aikaisemmin suoritettuunvaiheeseen voidaan palata. Kuvassa 3. takaisin palaamista on merkitty harmaallanuolella ja eteenpäin menemistä mustalla. Varsinainen kehitystyö tehdään näistäkolmesta kahden ensimmäisen aikana. Kolmas vaihe on tarkoitettu lopputuotteentoimittamiseen asiakkaalle.

Ensimmäinen näistä on toiminnallinen malli –iteraatio (engl. Functional modeliteration). Vaiheen tarkoituksena on tuottaa prototyyppi suunnitelluista toiminnallisistavaatimuksista sekä erityisesti käytettävyyteen liittyvistä ei-toiminnallisistavaatimuksista. Prototyypin avulla tarkennetaan businesstutkimusvaiheessa kerättyjävaatimuksia.

Design ja rakennus –iteraation (engl. Design & build iteration) tarkoituksena on tuottaavakaa ja testattu ohjelmistotuote joka voidaan antaa loppukäyttäjien käsiin. Mikälivaiheen aikana tulee vielä tarvetta testata käyttäjillä jotain toiminnallista vaatimusta,voidaan palata edelliseen iteraatioon niinkuin harmaa nuoli Kuvassa 3. osoittaa.



15

Käyttöönottoiteraation (engl. Implementation) aikana ohjelmistolle tehdäänhyväksymistestaus ja ohjelmisto luovutetaan asiakkaalle. Lisäksi käyttäjille järjestetäänkoulutus ennen käyttöönottoa. Projektin päätyttyä tuotetaan projektintarkasteludokumentti (engl. Project review document) missä arvioidaan projektinonnistumista eli vertaillaan kehityskaaren aikana määriteltyjä vaatimuksia ja tarpeitasiihen mitä on saavutettu. Tätä kuvastavat Kuvassa 3. käyttöönottoiteraatiosta lähtevätharmaat nuolet.



16

3 Analyysi

Analyysissä jokaiselle metodologialle on tehty 4CC viitekehyksen mukainen jaottelu.Yhteenveto jaottelusta on esitetty Taulukossa 1. Tämän kappaleen sisältämät yläviitteetviittaavat Taulukon 1. sisältämiin juoksevasti numeroituihin metodologioidenominaisuuksiin.

Jaottelu on tehty käyttäen seuraavien lähteiden tietoja: XP (Beck, 2000), Synch-and-Stabilize (Cusumano & Smith, 1997), Scrum (Beedle et al., 2001) ja DSDM (Stapleton,1997).

3.1 Strateginen tuotejulkaisujen ohjaussykli

3.1.1 Extreme Programming

Extreme Programming ei ota kantaa tähän ohjaussykliin.

3.1.2 Synch-and-Stabilize

Synch-and-Stabilizessa tuotteelle laaditaan kolmivuotinen tuotesuunnitelma2 (engl.three-year product plan) jonka tarkoitus on suunnitella ja jaksoittaa tuotteen julkaisujapitkällä aikavälillä. Suunnitelman tekee tuotepäällikkö yhdessä markkinoinnin kanssa.Kunkin tuotepäällikön suunnitelmat katselmoidaan ja hyväksytään tuoteohjelmankatselmuksissa1 (engl. Program review), joissa on paikalla myös yrityksen ylin johto BillGatesia myöten.

Synch-and-stabilizessä käytetty tuotevisio3 määrittää tuotteen pääfokuksen, mitentuotetta markkinoidaan, seuraavan julkaisun tarkoituksen sekä tarkeimmät osa-alueetjoihin seuraava julkaisu pureutuu. Visio toimii myöhemmin toiminnallisen määrittelynpohjana.

3.1.3 Scrum

Scrumissa tuotepäällikkö hallitsee käyttäjävaatimuksia ylläpitämällä tuotteenkäsiteltävien asioiden listaa1. Sääntönä on, että tuotepäällikön tulee hyväksyä listallekaikki ehdotukset, mutta tuotepäällikön mielipiteellä suuri vaikutus siihen mitkäkäyttäjävaatimukset täytetään, sillä yksin hänellä on valta muuttaa listan priorisointia.

3.1.4 Dynamic Systems Development Method

DSDM ei ota kantaa tähän ohjaussykliin.



17

3.2 Julkaisuprojektin ohjaussykli


Suunnittelupeli1 on XP:n tapa suunnitella seuraavan iteraation laajuus ja aikataulu.Koska suunnittelupeli ei ota kantaa muuhun kuin nimenomaan seuraavaan käsilläolevaan iteraatioon, sitä ei voida sijoittaa stragiseen tuotejulkaisujen ohjaussykliin.

XP:ssä ei tehdä varsinaista arkkitehtuurisuunnitelmaa vaan arkkitehtuuri määritelläänkarkealla tasolla XP:ssä metaforan2 avulla. Metafora on yksinkertainen kaikenkattavatarina siitä miten järjestelmän tulisi toimia

Osa XP:n vaatimusten hallintaa sekä verifikointi ja validointia on on-site asiakas3. On-site asiakas auttaa kehittäjiä päivittäisissä käyttäjävaatimuksiin liittyvissä kysymyksissä.Sillä välin kun kehittäjät työskentelevät seuraavan tuoteinkrementin parissa, on-siteasiakas valmistelee hyväksymistestejä samalle inkrementille.


Synch-and-Stabilizessa osa suunnitteluvaihetta on funktionaalisen määrittelyntuottaminen4. Tämän tekee julkaisuprojektin päällikkö yhteistyössä kehittäjien kanssa.Määrittely kirjoitetaan käyttäjän näkökulmasta ja se sisältää kaikki käyttöliittymänmenut, dialogit, näkymät sekä virheilmoitukset.

Suunnitteluvaiheessa määritellään myös kehitystiimit13 (engl. Feature team) sekäkehitysaikataulu5 (engl. Development schedule) mikä sisältää suunnitelman iteraatioidenaikataulutuksesta.

Synch-and-Stabilizessa näkyvin palaute strategiselle tuotejulkaisujen ohjaussyklilletulee valmiin ohjelmistotuotteen7 muodossa. Valmista tuotetta käytetään seuraavienjulkaisujen suunnittelussa.

3.2.3 Scrum

Scrumin sprintin suunnittelupalaverissa2 asiakkaat, käyttäjät, johto, tuotepäällikkö jaScrum tiimi yhdessä määrittävät seuraavalle sprintille laajuuden ja tavoitteen3. Sijoitanpalaverin tähän ohjaussykliin, koska siinä päätetään ainoastaan seuraavan sprintintavoitteista ja laajuudesta. Mikäli palaverin tarkoitus olisi suunnitella sprinttien suhdettatoisiinsa pidemmällä aikavälillä sijoittuisi se ensimmäiseen ohjaussykliin.

Sprintin katselmuksessa7 asiakkaat, käyttäjät, johto, tuotepäällikkö ja Scrum tiimikatselmoivat sprintin aikana tuotetun tuoteinkrementin. Sprintin onnistumista mitataanvertaamalla sprintin tavoitetta ja käsiteltävien asioiden listaa sprintin aikanasaavutettuihin todellisiin tuloksiin. Päähuomio on kuitenkin tuotetussa inkrementissä,josta saatua palautetta käytetään hyväksi seuraavan sprintin suunnittelupalaverissa.



18

Mikäli tuotteen julkaisut on jaettu useampaan julkaisuprojektiin, ylläpitää scrumintuotepäällikkö myös julkaisun käsiteltävien asioiden listaa4 (Release backlog). Listakuvaa käyttäjävaatimuksia samalla tarkkuudella tuotteen käsiteltävien asioiden lista.


DSDM prosessi hallitsee tuotejulkaisun vaatimuksia priorisoimalla ja kirjaamallatärkeimmät toiminnalliset ja ei-toiminnalliset vaatimukset3 omaan dokumenttiinsaprosessin businesstutkimusvaiheen aikana.

Businesstutkimusvaiheessa kirjoitetaan prototypisointisuunnitelma1 mikä sisältääsuunnitelman kaikista kehitystyön aikana tehtävistä prototyypeista. Suunnitelmatoisinsanoen antaa aikataulut ja tavoitteet kullekkin iteraatiolle.

Businesstutkimusvaiheessa tehdään myös arkkitehtuurinen suunnitelma2. Suunnitelmamäärittelee kehitys- ja tuontantoympäristöt sekä tuotettavan ohjelmiston arkkitehtuurisetpääsuuntaviivat. Suunitelmaa tarkennetaan kehitysprosessin edetessä.

DSDM määrittelee explisiittisesti, että julkaisuprojektin lopuksi on tehtävähyväksymistestaus8 asiakkaalla.

3.3 Iteraation ohjaussykli


XP määrittää, että kehitystyön tulee olla iteratiivistä ja että julkaisusyklin tulisi lyhyt.XP:n terminologian mukaan puhutaan pienistä julkaisuista4. Termin sijoittaminenTaulukkoon 1. on hankalaa, sillä kyse on enemmänkin ohjenuorasta kuinohjelmistotuotantoaktiviteetistä. Mikäli pienet julkaisut kuitenkin ymmärretääniteraatioiden lopputuotteena jota verifioidaan ja validoidaan, niin voidaan se sijoittaataulukkoon.

XP:ssä iteraation sisällä suoritettavat tehtävät suunnitellaan ja jaetaan iteraationsuunnittelupelissä6 (engl. Iteration planning game).

Aikaisemmin mainittiin, että metafora toimii arkkitehtuurin suunnannäyttäjänä. XP:ssäarkkitehtuuri muodostuu ja hioutuu ohjelmistoon ajan myötä kun ohjelmoijat toteuttavatyksenkertaisen designin ja refaktoroinnin periaatteita. Täten yksinkertainen design jarefaktorointi7 voidaan yhtenä kokonaisuutena sijoittaa Taulukkoon 1.

Toisaalta myös XP:n käyttämä yksikkötestaus8, missä testit suunnitellaan ennenvarsinaista koodia on myös osa ohjelmiston suunnittelua, koska yksikkötestejä tehtäessäsuunnitellaan itseasiassa samalla itse ohjelmistoa.

XP:n käyttämä pariohjelmointi9 voidaan käsittää myös toimenpiteenä laadunvarmistamiseksi, koska pareittain ohjelmoitaessa koodiin eksyy todennäköisestivähemmän virheitä, sillä pari saattaa huomata virheitä mitä ohjelmoija ei itse huomaa.



19


Kuten aikaisemmin mainittiin on Synch-and-Stabilizen kehitystyö on jaettu tyypillisestikolmeen iteraatioon joita metodologia kutsuu termillä alisykli (engl. subcycle).Alisyklin aikana kehittäjät toteuttavat määrittellyt toiminnallisuudet. Ennentuoteinkrementin julkaisua seuraa ns. stabilointivaihe10 (engl. Stabilation period).Stabilointivaiheessa uuden koodin tuottaminen lopetetaan ja kehittäjät yhdessä testaajienkanssa keskittyvät tuotetun koodin integroimiseen, testaamiseen ja debuggamiseen.Jokainen alisykli sisältää aikapuskurin8 (engl. Buffer time), jonka tarkoitus onpehmentää ominaisuuksien lisäämisestä tai arvaamattomista ongelmista aiheutuviaviivästyksiä.

Viimeinen alisykli eroaa hieman tavallisesta. Sen aikana ohjelmiston sisältämätominaisuudet lyödään lukkoon14 (engl. Feature complete) ja käyttöliittymä jäädytetään9

(engl. UI freeze). Tämän jälkeen seuraa vaihe jossa ohjelmakoodin katsotaan olevanvalmis (engl. Code complete). Tätä voidaan ajatella ikäänkuin ylimääräisenästabilointivaiheena ja siksi sitä ei ole merkitty erikseen Taulukkoon 1. Vaihe sisältääviimeisen testauksen ja debuggauksen ennen virallisen tuotejulkaisun tekemistä.

Koko tuotteen kehityskaaren ajan julkaisuprojektin päällikkö ja kehitystiimi päivittävätfunktionaalista määrittelyä12. Siksi siitä onkin järkevää lisätä maininta Taulukkoon 1.

Kunkin alisyklin lopputuotteena valmistuu joko lopullinen tuotejulkaisu tai alpha- taibetajulkaisu6. Julkaisuprojektin ohjaussykli ja strateginen tuotejulkaisujen ohjaussyklikäyttävät näitä julkaisuja palautteen saamiseksi tuotteesta.

3.3.3 Scrum

Scrumissa sprintin suunnittelupalaverin jälkeen scrum tiimi pitää omansuunnittelupalaverinsa, jossa se tuottaa sprintin tehtävälistan5 (engl. Sprint backlog)sprintin suunnittelupalaverissa määriteltyjen tavoitteiden täyttämiseksi. Tehtävälistaahallitsee yksinomaan scrum tiimi. Tehtävälista elää jätkuvasti sprintin edistyessä ja sesaattaa aluksi olla vailinainen esimerkiksi mikäli käytettävä teknologia tunnetaanhuonosti.


DSDM:n toiminnallinen malli –iteraatio ja design ja rakennus –iteraatio seuraavatkumpikin samanlaista kaava, jonka vaiheet ovat seuraavat: prototyypin identifiointi4

(engl. Identify prototype), aikataulun sopiminen5 (engl. Agree schedule), prototyypinrakentaminen6 (engl. Build prototype) ja prototyypin katselmointi7 (engl. Reviewprototype).

Ensimmäisessä vaiheessa mietitään prototypisointisuunnitelman ja vaatimusten pohjaltamillainen prototyyppi ollaan rakentamassa ja toisaalta arkkitehtuurisuunnitelmanpohjalta miten tämä prototyyppi rakennetaan. Tässä vaiheessa tulee muistaa, että DSDMsallii kummankin äsken mainitun suunnitelman päivittämisen ja tarkentamisen mitävarmasti myös tapahtuu.



20

Toisessa vaiheessa määritellään jaksotus iteraation sisällä sekä sitoutetaan kehitysryhmäaikatauluun. Kolmannessa vaiheessa vaiheessa rakennetaan prototyyppi edellisissävaiheissa tehtyjen sunnitelmien mukaisesti. Viimeisessä vaiheessa katselmoidaantuotettu prototyyppi ja siihen liittyvät dokumentit.

3.4 Mini-milestone


XP:ssä projektin johdolla on kokoajan käsitys edistymisestä iteraatiosyklin aikana,koska kehittäjät integroivat ohjelmakoodinsa osaksi suurempaa kokonaisuutta useampiakertoja päivässä. XP:n terminologian mukaan toimintaa kutsutaan jatkuvaksiintegroinniksi.


Synch-and-Stabilizessa kehittäjät synkronoivat tekemänsä ohjelmakoodin päivittäinkeskitetylle palvelimelle. Useimmissa projekteissa palvelimen koodista tehdäänpäivittäinen build11 (engl. Daily build). Samalla integroidulle koodille tehdään joukkotestejä15. Mikäli virheitä havaitaan ne tulee korjata välittömästi. Koska koodikäännetään joka päivä on virheiden paikallistaminen käytännössä helppoa.

3.4.3 Scrum

Scrumin päivittäisessä scrum palaverissa6 kaikki tiimin jäsenet vastaavat kolmeenkysymykseen: Mitä olet tehnyt edellisen Scrumin jälkeen? Mitä teet ennen huomistaScrumia? Onko työskentellyssä jotain esteitä tai hankaluuksia? Palaveri pidetään jokapäivä samassa paikassa samaan aikaan. Palaverin on tarkoitus kestää alle 15 minuuttia jakaikki näiden kysymysten ulkopuoliset keskustelut järjestetään palaverin jälkeen.Päivittäisen scrumin tarkoituksena on auttaa tiimiä ja projektin johtoa seuraamaanedistymistä, tukea tiimin kommunikaatiota sekä autaa johtoa tunnistamaan japoistamaan kehitystyötä haittaavia esteitä.


DSDM ei ota kantaa tähän ohjaussykliin.



21

Synch-and-Stabilize

1 Tuoteohjelman katselmus

2 Kolmivuotinen tuotesuunnitelma

3 Tuotevisio

4 Funktionaalinen määrittely5 Kehitysaikataulu

1 5 13 11 6 Alpha ja beta julkaisut

3 8 14 7 Valmiin tuotteen julkaisu

2 3 9 8 Aikapuskuri

3 4 12 9 Käyttöliittymän jäädyttäminen7 6 10 15 10 Stabilointivaihe

1 6 5 11 Päivittäiset buildit

2 7 8 9 12 Funktionaalisen määrittelyn päivittäminen

13 Kehitystiimien määrittäminen

3 14 Ominaisuuksien lyöminen lukkoon3 4 8 9 15 Päivittäinen testaus

7 2 3 5 6

Extreme Programming

1 4 1 Suunnittelupeli7 2 Metafora

1 5 3 On-site asiakas

2 4 6 4 Pienet julkaisut

5 Jatkuva integrointi

3 6 Iteraation suunnittelupeli8 7 7 Yksinkertainen design ja refaktorointi

8 Yksikkötestaus

9 Pariohjelmointi

Scrum

1 Tuotteen käsiteltävien asioiden lista

2 Sprintin suunnitelupalaveri

3 Sprintin tavoite

4 Julkaisun käsiteltävien asioiden lista

5 Sprintin tehtävälistä

6 Päivittäinen scrum

7 Sprintin katselmus

DSDM

1 Prototypisointisuunnitelma

2 Arkkitehtuurinen suunnitelma

3 Priorisoitu lista vaatimuksista

4 Prototyypin identifiointi

5 Aikataulun sopiminen

6 Prototyypin rakentaminen

7 Prototyypin katselmointi

8 Hyväksymistestaus

Taulukko 1. Yhteenveto analyysistäMetodologioiden ominaisuudet on lueteltu ja numeroituoikealla puolella olevaan listaan. Tämän jälkeenominaisuudet on asetettu analyysitaulukkoon. Sijoittelunperustelut löytyvät kappaleesta 3. Analyysi. Selitykset 4CC:nohjaussykleille ja aktiviteettikategorioille löytyvätkappaleesta 2.2 4CC viitekehys.

Syn

ch-a

nd-

Sta

biliz

e<

Met

od

olo

gia

4CC:naktiviteettikategoria v

Suunnittelu ja seuranta

Testaus ja laadunvarmistus

Vaatimustenhallinta

Tuotehallinto

4CC:n ohjaussykli >

Tuotehallinto

Vaatimustenhallinta


Ext

rem

epr

ogra

mm

ing Suunnittelu ja seuranta

Ohjelmistosuun. ja toteutus

Tuotehallinto

Vaatimustenhallinta


Min

i-mile

ston

et

DS

DM



Tuotehallinto

Vaatimustenhallinta


Scr

um




Str

ateg

inen

tuot

ejul

kais

ujen

ohja

ussy

kli

Julk

aisu

proj

ektin

ohja

ussy

kli

Itera

atio

noh

jaus

sykl

i



22

4 Johtopäätökset

Microsoftin Synch-and-Stabilize on tutkielman metodologioista selvästi kaikkeinkokonaisvaltaisin. Se määrittää yrityksen toiminnan suhteelisen tarkasti myösstrategisessa tuotejulkaisujen ohjaussyklissä. Tutkimuksen muiden metodologioidenkäytännöt ovat kyseisessä syklissä kevyitä tai jopa olemattomia. Toisaalta tätä ei pidälaskea muiden metodologioiden heikkoudeksi, sillä useissa tapauksissa yrityksen onhelpompaa ottaa käyttöön metodologia joka sallii tuotteen julkaisujenpitkäaikaissuunnittelukäytäntöjen säilyttämisen samanlaisena kuin ne ovat ainaolleetkin. Synch-and-Stabilizen tapauksessa on kyse metodologiasta joka on kehitettyyksittäisen yrityksen, Microsoftin tarkoituksiin. Sen kehittämisessä ja dokumentoinnissaei todennäköisesti ole mietitty metodologian käytettävyyttä muissa yrityksissä. XP,Scrum ja DSDM ovat tässä mielessä yleispätevämpiä, että ne sallivat julkaisujenpitkäaikaissuunnittelussa käytettävän kullekkin yritykselle sopivimpia työkaluja.Toisinsanoen viitekehysanalyysin perusteella huomataan, että kaikki muut metodologiatpaitsi Synch-and-Stabilize tarvitsevat aika paljon lihaa luidensa ympärille mikäli niitäruvetaan käytännössä implementoimaan. Seikka mikä kannattaa muistaa aina Synch-and-Stabilizea tarkasteltaessa on se, että siitä kertovat lähteet ovat suhteellisen vanhojaeikä allekirjoittaneella ole tietoa mihin suuntaan kyseinen metodologia on kehittynytlähteiden kirjoittamisen jälkeen.

Scrum määrittää paljolti miten ohjelmistotyötä pitäisi suunnitella ja seurata. XP:ssätämä puoli on jätetty vähemmälle ja keskitytty määrittelemään yksittäisiä käytännönohjelmointitekniikoita joita käyttämällä ohjelmistotyön tuottavuutta ja laatua voidaannostaa. Kuten analyysitaulukosta huomataan on XP:n painopiste testauksen jalaadunvarmistuksen sekä ohjelmistosuunnittelun ja toteutuksen puolella. Scrumissapainopiste on puolestaan suunnittelussa ja seurannassa sekä vaatimustenhallinnassa.Analyysin perusteella metodologiat voisivat täydentää ja tukea toisiaan hienosti. Näinkäytännössä onkin sillä (Beedle et al., 2001) kertoo XP:n ja Scrumin olevan yhdessäkäytettynä hyperproduktiivinen yhdistelmä.

Mikäli metodologioita vertaillaan viitekehysanalyysin perusteella huomataan, ettäitseasiassa osa eri metodologioiden tavoista toimia on samoja, mutta niillä on eri nimet.Tästä esimerkkinä XP:n jatkuva integrointi ja Synch-and-Stabilizen päivittäiset buildit.Tämä pienentää metodologioiden eroavaisuuksia jonkin verran. Silti metodologiateroavat kuitenkin toisistaan selvästi.

4CC viitekehyksen suurin käyttösovellus on varmasti yritysten käytössä olevienohjelmistokehityskäytäntöjen analysoinnissa. Ajan myötä voidaan saada näppituntumaasiitä millainen metodologia soveltuu mihinkin liiketoimintaympäristöön ja yrityksensisäisiin ominaisuuksiin. Tällöin tämän tutkimuksen tapaista analyysia voidaanpuolestaan käyttää päätöksenteon tukena siinä vaiheessa kun arvioidaan etukäteenpaperilla jonkun metodologian soveltuvuutta käytäntöön.

Ketterien ohjelmistokehitysmetodologioiden kuvaaminen 4CC viitekehyksellä onnistuikiitettävästi sillä suurin osa tutkimukseen valittujen metodologioiden tärkeimmistäominaisuuksista pystyttiin sijoittamaan viitekehyksen mukaiseen jakoon. Tämä ei



23

sinänsä ole yllätys sillä osaa näistä metodologioista on käytetty viitekehyksensuunnittelun lähtökohtana (Rautiainen et al., 2002).



24

5 Tutkielman arviointia

Allekirjoittaneen mielestä tutkielman tavoitteet täyttyivät. Tutkimusongelmaan saatiinselkeästi vastaus.

Oma tietämykseni sekä tutkimuksen metodologioista, että ketteristä metodologioistaylipäätänsä otti varmasti suuren harppauksen eteenpäin. Toisaalta nyt tehty tutkielma olihyvin teoreettinen. Silti se antaa hyvät lähtökohdat tutkia seuraavaksi jotainkäytännönläheisempää aihetta. Tavoitteet täyttyivät myös siinä mielessä, että valmiutenitieteelliseen kirjoittamiseen paranivat.

Eräs tutkimuksen aikana ilmennyt ongelma oli se, että alunperin tutkimuksen yhdeksikohteeksi oli valittu Feature Driven Development (FDD). FDD jouduttiin kuitenkinvaihtamaan DSDM:n, koska kirjallisuutta FDD:stä oli vaikea löytää.

Toinen ongelma oli 4CC mallin nuori ikä ja siitä johtuva lähdedokumenttienmuuttuminen tutkimuksen edetessä.



25

6 Yhteenveto

Tutkimuksen aiheena on tutkia voidaanko ketteriä ohjelmistokehitysmetodologioitakuvata käyttäen 4CC viitekehystä. Tutkimukseen kohteeksi valittiin metodologiatMicrosoft Synch-and-Stabilize, Extreme Programming, Scrum ja Dynamic SystemsDevelopment Method.

4CC on viitekehyksen on suunniteltu pienten ja keskisuurten ohjelmistoyritystentuotekehitystoiminnan analysointiin ja kehittämiseen. Viitekehys jakaa yrityksentoiminnan neljään ohjaussykliin. Strategisessa tuotejulkaisujen ohjaussyklissä tuotteeneri sidosryhmät päättävät tuotejulkaisujen ajoituksesta ja sisällöstä, resurssienjakamisesta sekä teknologisista pääsuuntaviivoista. Julkaisuprojektin ohjaussyklissäpuolestaan suunnitellaan julkaisuprojektin jakaminen iteraatioihin ja määritetääniteraatioille laajuus, aikataulu ja budjetti. Iteraation ohjaussyklin tarkoituksena onpuolestaan hallita itse iteraatiota ja tuottaa vakaa sekä toimiva tuotejulkaisuninkrementti jota voidaan käyttää palautteen saamiseksi ja käyttäjävaatimustentarkentamiseksi. Edistystä iteraation aikana puolestaan seurataan mini-milestonejenavulla.

Analyysissä tutkimukseen valituttujen metodologioiden käytännöt jaettiin äskenesiteltyihin sykleihin. Taulukko 1. sivulla 21 vetää yhteen tämän analyysin.

Analyysin perusteella huomattiin, että Microsoftin Synch-and-Stabilize on tutkielmanmetodologioista selvästi kaikkein kokonaisvaltaisin. Se määrittää yrityksen toiminnansuhteelisen tarkasti myös strategisessa tuotejulkaisujen ohjaussyklissä. Tutkimuksenmuiden metodologioiden käytännöt ovat kyseisessä syklissä kevyitä tai jopaolemattomia.

Scrum määrittää paljolti miten ohjelmistotyötä pitäisi suunnitella ja seurata. XP:ssätämä puoli on jätetty vähemmälle ja keskitytty määrittelemään yksittäisiä käytännönohjelmointitekniikoita joita käyttämällä ohjelmistotyön tuottavuutta ja laatua voidaannostaa. Kuten analyysitaulukosta huomataan on XP:n painopiste testauksen jalaadunvarmistuksen sekä ohjelmistosuunnittelun ja toteutuksen puolella. Scrumissapainopiste on puolestaan suunnittelussa ja seurannassa sekä vaatimustenhallinnassa.Analyysin perusteella metodologiat voisivat täydentää ja tukea toisiaan hienosti. Näinkäytännössä onkin sillä (Beedle et al., 2001) kertoo XP:n ja Scrumin olevan yhdessäkäytettynä hyperproduktiivinen yhdistelmä.

Ketterien ohjelmistokehitysmetodologioiden kuvaaminen 4CC viitekehyksellä onnistuikiitettävästi sillä suurin osa tutkimukseen valittujen metodologioiden tärkeimmistäominaisuuksista pystyttiin sijoittamaan viitekehyksen mukaiseen jakoon. Tämä eisinänsä ole yllätys sillä osaa näistä metodologioista on käytetty viitekehyksensuunnittelun lähtökohtana (Rautiainen et al., 2002).



26

Lähdeluettelo

Julkaisut

(Beck, 2000) Beck K. 2000. Extreme programming explaned: embrace change. Reading(MA). Addison-Wesley. 190 s. ISBN 0201616416.

(Beck, 1999) Beck K. 1999. Embracing change with extreme programming. IEEEComputer. Vol. 32, Issue 10. s. 70. ISSN 0018-9162.

(Beedle et al., 2001) Beedle M., Schwaber K., Martin R. 2001. Agile SoftwareDevelopment with SCRUM. Paperback. 150 s. ISBN 0130676349.

(Cockburn, 2001) Cockburn A., 2001. Agile Software Development. Addison-Wesley.Reading (MA). 256 s. ISBN 0201699699.

(Cusumano, 1995) Cusumano M.A. 1995. Microsoft secrets: how the world's mostpowerful software company creates technology, shapes markets, and manages people.New York. Free Press. 512 s. ISBN 0028740483.

(Cusumano & Yoffie, 1999) Cusumano M.A., Yoffie D.B. 1999. Software developmenton Internet time. IEEE Computer. Vol. 32, Issue 10. s. 60. ISSN 0018-9162.

(Cusumano & Selby, 1997) Cusumano M., Selby R. 1997. How Microsoft buildsSoftware. Communications of the ACM. Vol. 40, Issue 9. s. 53. ISSN 0001-0782.

(Cusumano & Smith, 1997) Cusumano M., Smith S. 1997. Beynd the Waterfall:Software Development at Microsoft. Teoksessa: Yoffie D. Competing in the age ofdigital convergence. USA. ISBN 0875847269.

(Haikala, Märijärvi 1998) Haikala I., Märijärvi J. 1998. Ohjelmistotuotanto. 5. painos.Suomen Atk-kustannus Oy. Jyväskylä. 385 s. ISBN 951-762-666-5.

(Rautiainen et al., 2002) Rautiainen K., Lassenius C., Sulonen R., 2002. 4CC: Balancingflexibility and control: A framework for Product Development Management in SmallSoftware Companies, Helsinki University of Technology. EI VIELÄ JULKAISTU.

(Stapleton, 1997) Stapleton J. 1997. Dynamic Systems Development Method. DSDMConsortium. Reading. 163 s. ISBN 0201178893.

Muut kirjalliset lähteet

(Vähäniitty, 2002) Vähäniitty J. 2002. SEMS – Software Engineering ManagementSystem for SME’s in the SW Product Business. Tekesin Spin-teknologiaohjelmanvuosiseminaari. Helsinki 3.4.2002. Saatavilla www:stä<http://www.swbusiness.fi/portal/?cid=650026962>

Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS ...T-76.650 Ohjelmistotuotannon...

Documents

Transcript of Ketterien ohjelmistokehitysmallien analyysi käyttäen SEMS ...T-76.650 Ohjelmistotuotannon...