Kuviossa menetelmä on keskiössä. Se pitää sisällään tietyn paradigman ja arvot sekä lähestymistavan, jollaisena menetelmässä nähdään ohjelmistokehitys. Me-netelmän taustalla on myös erilaisia periaatteita, ja sillä on olemassa jokin
kon-teksti, jossa sitä sovelletaan. Tämä voi olla esimerkiksi menetelmän kehittämi-sen tai ohjelmistokehitykkehittämi-sen konteksti.
Menetelmä voidaan kuvata erilaisin tavoin, kuten esimerkiksi ilmaisemal-la sen sisältö kirjallisesti. Eriilmaisemal-laiset toimijat, kuten organisaatiot, kehitystiimit ja menetelmäkehittäjät, voivat käyttää menetelmää hyväkseen. Organisaation jä-senillä voi olla erilaisia rooleja, kuten kehittäjiä tai projektipäälliköitä, ja erilaiset roolit usein käyttävät menetelmää eri tavoin. Menetelmässä on usein erilaisia tekniikoita ja käytänteitä, kuten erilaisia palavereita tai ohjelmointikäytänteitä.
Menetelmä pitää sisällään prosessin, jota ohjelmistokehitys noudattaa. Proses-sin eri vaiheissa eri tekniikoita ja käytänteitä voidaan käyttää hyväksi. Käytän-nön työssä menetelmän käyttäminen on sen soveltamista käytännössä.
Menetelmän voi määritellä osista koostuvina kokonaisuutena seuraavalla tavalla. Menetelmä on ennalta määritelty, tietyn taustan, lähestymistavan ja pe-riaatteita omaava kokonaisuus, jonka käyttämisen tavoitteena on parantaa oh-jelmistokehitystä. Menetelmä määrittelee prosessin, jonka eri vaiheissa käyte-tään eri tekniikoita ja käytänteitä. Menetelmää käyttävät erilaiset henkilöt ja organisaatiot tietyssä ainutlaatuisessa kehittämiskontekstissa, ja eri menetelmät soveltuvat parhaiten eri konteksteihin.
2.1.3 Menetelmän hyötyjä, rooleja ja haasteita
Menetelmän käytöllä on havaittu olevan useita hyötyjä. Sen on havaittu paran-tavan ohjelmistokehityksen prosessia, vähentävän rahan, ajan ja työvoiman tar-vetta sekä parantavan myös mahdollisesti itse kehitystyön lopputuloksen laa-tua (Leppänen, 2005). Tolvanen (1998) sanoo menetelmän käytön parantavan dokumentaatiota, systematisoivan ohjelmistokehityksen prosessia, parantavan mahdollisuuksia saada kehityksen lopputuloksen vastaamaan vaatimuksiaan sekä lisäävän käyttäjien osallistumista kehitystyöhön. Tämän lisäksi menetel-mien on huomattu lisäävään kontrollia projekteista ja lisäävän sen ennustetta-vuutta sekä tuovan yhteisen pohjan keskustelulle ja ymmärrykselle. Menetelmä auttaa lisäksi uusia työntekijöitä tunnistamaan, mistä heidän tulee tietää enemmän, ja helpottaa keskusteluja kokeneempien työntekijöiden kanssa ja tu-kevan tietämyksen kokoamista ja jakamista tarjoamalla muun muassa yhteisen terminologian ja työnkulut keskustelujen pohjaksi. (Schönström & Carlsson, 2003.)
Edellä mainitut hyödyt liittyvät menetelmän ns. rationaaliseen rooliin (Fitzgerald, Russo & Stolterman, 2002). Mutta menetelmällä on myös poliittinen rooli. Siihen liittyvinä höytyinä voidaan mainita seuraavia (Fitzgerald ym., 2002, 104-106): menetelmä voi auttaa ammatillistamaan tietojärjestelmätyötä, paran-tamaan kehittämistyöstä vastaavan osaston asemaa yrityksessä, lisäämään luot-tamusta lopputuloksen laatuun (comfort or confidence factor), jäljittämään sen kohdan kehittämisprosessia, jossa mahdollinen väärä päätös tehtiin, sekä tar-joamaan määrämuotoisen perustan kehittämistä koskevan sopimuksen tekemi-selle ja tulkinnalle oikeudellisen perustan. Menetelmän käyttö johtaa usein or-ganisaatiossa ns. menetelmäekspertin (method champion) syntymiseen, jolla
voi olla muodolliseen asemaansa verrattuna suurempi valta. Chang, Tung-ching ja Sheng (2002) tutkivat 56 tapaustutkimusta ohjelmistonkehitysproses-seista, joista he löysivät yhteensä 192 poliittista peliä, jotka voitiin jakaa 41 eri kategoriaan. Esimerkkeinä poliittisista peleistä voivat olla etäisenä pysyminen, jolloin pyritään välttämään vastuuta, varman päälle pelaaminen, jolloin pyri-tään välttämään epävarmuutta ja osallistutaan mieluummin varmoihin projek-teihin, sekä koalitioiden muodostaminen niin työntekijöiden kuin myös muiden asianomaisten kanssa. (Cheng, Tung-ching & Sheng, 2002.)
Menetelmän käyttö on joissain tapauksissa nähty jopa välttämättömäksi.
Ramamoorthy, Garg ja Prakash (1986) toteavat, että ainoastaan kurinalainen ja menetelmää käyttävä kehitystyö voi saada ison ohjelmistoprojektin onnistu-maan. Palvia ja Nosek (1993) taas huomasivat, että heidän havaintonsa mene-telmän käytön vähyydestä on pelottava ja häiritsevä. Fitzgerald (1996) kuiten-kin toteaa, että ihmiset kehittävät ohjelmistoja, ei menetelmät, ja että menetel-mät ainoastaan voivat parhaimmillaan tarjota hyödyllisen viitekehyksen kehit-tämiselle. Kokeneet kehittäjät voivatkin ymmärtää menetelmien rajoitteet, ja jättää ne käyttämättä, jos niistä ei nähdä olevan hyötyä. (Fitzgerald, 1996.)
Menetelmän käytöllä on omat haasteensa, eikä niiden käyttö ohjelmisto-kehityksessä takaa millään tavalla projektin onnistumista. Ne on koettu muun muassa sopiviksi vain suuriin ja monimutkaisiin projekteihin, ja ne voivat olla joustamattomia tai vastata huonosti tilannetekijöihin, jotka liittyvät käsillä ole-vaan organisaatioon, projektiin tai teknologiaan. Ne eivät myöskään aina tuo luvattuja parannuksia tuottavuuteen, ja niiden taustalla voi olla yksinkertaista-via oletuksia esimerkiksi siitä, että käyttäjät ovat tietoisia ohjelmiston vaati-muksista, mikä ei käytännössä aina pidä paikkaansa. (Avison & Fitzgerald, 2003.) Menetelmän työkalut voivat olla myös kalliita ja vaatia erityisiä teknisiä taitoja (Leppänen, 2005). Menetelmää on käytetty myös sosiaalisena puolustuk-sena epämiellyttäviä asioita vastaan, jolloin se pahimmillaan estää oppimista ja luovaa ajattelua (Wastell, 1996).
2.2 Menetelmäkehitys
Seuraavaksi tarkastellaan sitä, miten menetelmiä kehitetään yleisellä tasolla ja tietyn organisaation tai projektin käyttöön. Brinkkemper (1996) määrittelee me-netelmän kehittämisen (engl. method engineering) tarkoittavan työtä, jonka tarkoi-tuksena on suunnitella, rakentaa ja soveltaa menetelmiä, tekniikoita ja työkaluja tietojärjestelmien kehittämistä varten. Tolvanen (1998) sanoo menetelmäkehi-tyksen idean olevan samankaltainen kuin esimerkiksi järjestelmäkehimenetelmäkehi-tyksen.
Kun järjestelmäkehityksessä kehitetään ja ylläpidetään järjestelmiä tukemaan liiketoimintaprosesseja, menetelmäkehityksessä kehitetään ja ylläpidetään me-netelmiä tukemaan järjestelmäkehitystä. (Tolvanen, 1998.) Leppänen (2005) määrittelee menetelmän kehittämisen seuraavalla tavalla:
Menetelmän kehittäminen tarkoittaa kaikkia niitä aktiviteetteja, joiden avulla tietojär-jestelmän kehittämismenetelmä on kehitetty, ja mahdollisesti myöhemmin räätälöity ja konfiguroitu vastaamaan organisaation ja/tai projektin tarpeita. Leppänen (2005, 442)
Leppänen on esittänyt menetelmän kehittämiselle viitekehyksen (kuvio 3). Vii-tekehyksessä menetelmän kehittämiselle on määritelty kolme erillistä strategiaa, kolme erillistä kontekstia sekä kuusi erillistä prosessia, joiden avulla voidaan selventää menetelmän kehittämisen periaatteita ja tilanteita. Strategia tarkoittaa menetelmän kehittämisen yhteydessä yleistä keinoa suorittaa jokin tietty suun-nittelun pyrkimys. Strategioista ensimmäinen, luominen, tarkoittaa tietojärjes-telmän kehittämismenetietojärjes-telmän suunnittelua ilman aiempien menetelmien käyt-tämistä pohjana. Integraatio tarkoittaa menetelmän kehittämistä kokoamalla komponentteja tai palasia jo olemassa olevista menetelmistä. Mukauttaminen taas tarkoittaa olemassa olevan menetelmän komponenttien muokkaamista tai poisjättämistä, tai menetelmän laajentamista uusilla osilla. (Leppänen, 2005.)