DSDM (Dynamic Systems Development Method), taipuisa järjestelmän kehitysmenetelmä (TJKM), on liiketoiminnan tarpeisiin keskittyvä ohjelmistokehitysmenetelmä, jonka tavoitteena on mahdollistaa liiketoiminnan vastaaminen markkinoiden tarpeisiin välittömästi tarpeiden ilmaantuessa. Stapleton, s. 16 - 17 DSDM:llä luodaan projektiympäristö. Kun projektin toteuttamiselle on puitteet, DSDM pyrkii ohjaamaan projektin asetettuihin tavoitteisiin.
DSDM luetaan yhdeksi ketteristä menetelmistä, ja sen tavoite on tuottaa järjestelmään liiketoiminnan kipeimmin tarvitsemat toiminnallisuudet nopeasti ylittämättä hankkeen aikataulua tai talousarviota. Stapleton, s. xx DSDM on projektin ohjausrakenne, jonka menetelmät ovat niin yleisellä tasolla, että se soveltuu käytäväksi luonteeltaan erilaisissa organisaatioissa eri toimialoilla kooltaan vaihtelevissa projekteissa joko kansallisissa tai kansainvälisissä projekteissa.Stapleton, s. xx, 12 ja 15 DSDM kohdistuu jokaiseen projektissa mukana olevaan henkilöön. Sitä voidaan käyttää sekä rakenteisessa (proseduraalisessa) että olioperustaisessa lähestymistavassa projektin kaikissa vaiheissa.Stapleton, s. xx - xxi
DSDM määrittelee projektin ohjauksen suorittamisen, määrittelyn, protoilun, aikalaatikoinnin, asetusten hallinnan, testauksen ja laadunvarmistuksen. Viitekehys määrittelee projektin jäsenten roolit ja vastuut, työryhmän kokoonpanon, toteutusympäristön, riskinhallinnan, ylläpidettävyyden toteuttamisen, uudelleenkäytettävyyden ja kaupalliset suhteet.Stapleton, s. xxi
DSDM:n perusperiaatteita on neljä. Kehitys tapahtuu yhteisesti työskennellen (team effort), korkealla laadulla tarkoitetaan sekä tarkoitukseen sopivuutta että teknistä toimivuutta, suositaan osatoimituksia ja keskitytään kehittämään liiketoiminnan kannalta ensiarvoisia ohjelmistokomponentteja.
DSDM:n päävaiheet ovat toiminnallisuuden määrittelyn iteraatio, suunnittelun ja toteutuksen iteraatio ja käyttöönoton iteraatio. Stapleton, s. 3 Prosessin tärkeimmät ohjausrakenteet ovat aikalaatikot ja ominaisuuksien priorisointi VTaToU-luokittelua käyttäen.Stapleton, s. 33 ja 43 - 44 Projektin ohjauksen painopiste on toteuttajien yhteisöllisyydessä, vuorovaikutuksessa ja heidän osaamisessaan, ei itse prosessissa.
Ketterät menetelmät painottavat toteuttajien ja käyttäjien välistä kommunikaatiota. DSDM-ryhmän koko on pienimmillään kaksi henkilöä. Suurin DSDM-ryhmänmatriisin suositeltava koko on kuusi henkilöä kuudessa ryhmässä.Stapleton, s. xix, 13 ja 15
Projektin kehitystyön kaksi ensimmäistä vaihetta ovat samanaikaiset toteutettavuuden arviointi ja liiketoiminnan määrittely. Iteraatiovaiheen vaiheita ensimmäinen vaihe on toiminnallisen mallinnuksen iteraatio (TOMI). Iteraatiovaiheen muita vaiheita ovat suunnittelun ja toteutuksen iteraatio (SUTI) sekä käyttöönoton iteraatio (KAI). Lisäksi projektiin kuuluvat vaiheina projektin käynnistäminen ja päättäminen. Nämä vaiheet eivät sisällä iteraatioita.
DSDM ottaa huomioon ihmisresurssin luonteen ja projektien monimuotoisuuden. Sitä käytettäessä loppukäyttäjät ottavat järjestelmän todennäköisesti vastaan helpommin, vääränlaisen järjestelmän toteutuksen todennäköisyys vähenee ja järjestelmä vastaa todennäköisesti liiketoiminnan asettamia vaatimuksia. Lisäksi käyttäjät ovat paremmin koulutettuja ja järjestelmän käyttöönotto sujuu vaivattomasti. DSDM ei ratkaise kaikkia projekteissa esiin tulevia ongelmia, mutta se helpottaa huomattavasti järjestelmän kehitystyötä.Stapleton, s. xx, xxiv ja xxv
Historia
Vesiputousmallissa on nähty puutteita jo pitkään. Sen puutteita on pyritty täydentämään muun muassa lisäämällä siihen iteroivan ohjelmistokehityksen tekniikoita, mutta siinä on usein epäonnistuttu. RAD ja Extreme Programming eivät kata kaikkia ohjelmistoprojektin osa-alueita, joten on ollut tarve kehittää parempi menetelmä.Stapleton, s. xxi - xxii
DSDM-yhteenliittymä (DSDM Consortium) perustettiin tammikuussa 1994. Sen tavoitteena on laatia ohjelmistotuotannon toimintatapa, joka on yleisesti saatavissa, yleisesti hyväksytty ja joka sopii erilaisiin toteutustekniikoihin. DSDM on tapa toteuttaa prosessi.Stapleton, s. xxii
DSDM:n kehitettiin vuonna 1994, ja ensimmäinen versio julkaistiin vuoden 1995 alkupuolella. Työtavan toinen versio julkaistiin marraskuussa 1995 ja kolmas elokuussa 1997. DSDM:stä on tarkoitus laatia ohjelmistoprojektin erityisluonteen tarkemmin huomioon ottava versio.
DSDM verrattuna vesiputousmalliin
Järjestelmän toimitusaikataulu eroaa DSDM:ää käytettäessä ohjelmistotuotannon vesiputousmallista, jossa ohjelmistokehitys tapahtuu peräkkäisinä vaiheina ilman iteraatioita. Tärkein DSDM:n työtapa on aikalaatikko, jonka aikana projekti tuottaa tuotteen jonkin ominaisuuden. Aikalaatikon kesto voi olla muutama päivä tai muutamia viikkoja. DSDM keskittyy enemmän tuotteeseen kuin työvaiheen toteutustapaan. Jäljitettävyyden ansiosta ohjelmistokehittäjät voivat palata kehitystyössä tilanteeseen, jossa virhe syntyi. Stapleton, s. xxv
DSDM:ää käytettäessä voidaan toteuttaa vastaava järjestelmä kuin vesiputousmallilla, mutta lyhyemmässä ajassa. DSDM vaatii vähemmän työtä kuin vesiputousmalli ja tiedonkulku on tehokkaampaa kuin vesiputousmallia käyttäessä. Työajansäästö syntyy kokousten määrän ja niihin käytettävän ajan vähenemisestä ja siitä, että tuotteisiin ei toteuteta turhia ominaisuuksia. Lisäksi tehtävien anto tilaajalta toimittajalle nopeutuu. Viestinnän paraneminen näkyy siinä, että ongelmat, väärinkäsitykset ja virheellisesti annetut ohjeet havaitaan nopeasti ja ne voidaan korjata mahdollisimman aikaisessa vaiheessa. Vesiputousmallissa viestinnän toimimattomuus voi johtaa siihen, että ohjelmistotuote joudutaan projektin loppuvaiheessa kirjoittamaan suurelta osin uudelleen. DSDM:ää käyttäen koodin dokumentointi on koko projektin ajan ajantasaista, ja siksi ohjelmiston ylläpidettävyys on hyvä verrattuna tilanteeseen, jossa vesiputousmallissa dokumentaatio tuotetaan vasta projektin loppuvaiheessa.
DSDM:n yleisperiaatteet
DSDM:ssä on yhdeksän periaatetta. Näitä periaatteita ovat loppukäyttäjien osallisuus, työryhmän autonomia, näkyvät tulokset, toimitusten tarkoituksenmukaisuus, iteratiivisuus ja käytännön ratkaisut, palautuspisteet, kokonaiskuva, testaus toteutusvaiheessa ja yhteistyö. DSDM:n yhdeksän yleisperiaatetta toimivat vuorovaikutteisesti toistensa suhteen, ja niitä kaikkia tulisi soveltaa projektissa samanaikaisesti. Jos yhdenkin periaatteen soveltaminen on mahdotonta, tulisi käyttää jotain muuta menetelmää kuin DSDM:ää. Stapleton, s. 13
Loppukäyttäjän osallisuus
Loppukäyttäjien osallistuminen kehitystyöhön on DSDM:n tärkein periaate. Loppukäyttäjä osallistuu kehitystyöhön tasaisesti koko projektin ajan, jolloin hänelle hahmottuu oikea käsitys projektin sisällöstä. Käyttäjän osallistuminen on jatkuvaa. Kommunikaatiossa on tärkeintä jatkuvuus ja keskittyminen projektin tarpeisiin. Liiketoimintatietämyksen tulee siirtyä kehittäjille nopeasti ja suoraan mahdollisimman virheettömänä.Stapleton, s. 13 - 14
DSDM-projektin ja perinteisen projektin loppukäyttäjien osallistumista on kuvattu niin sanotulla piikikkään sohvan käyrällä.
700px|thumb|Asiakkaan osallisuus projektissamukaillen Stapleton 2003, 14.
Työryhmän autonomia
Nopeasti tapahtuva ohjelmiston kehittäminen edellyttää sitä, että tarvittavat valinnat voidaan tehdä nopeasti. Hidas päätösaikataulu yleensä estää tarvittavien ominaisuuksien toimittamisen ajallaan. Stapleton, s. 15
Työryhmän jäsenillä tulee olla riittävä päätösvalta päättää itse toistuvista pienistä asioista. Sellaisia ovat muun muassa vaatimusten toteutustapa, toiminnallisuuden ja käytettävyyden toteutustapa, vaatimusten toteutusjärjestys ja teknisten yksityiskohtien lopullinen toteutustapa. Mikään näistä ei aiheuta katastrofia ohjelmistolle. Toteuttajien liian laaja päätäntävalta aiheuttaa sen, että tuotteen toteutustavasta tulee epämääräinen.
Näkyvät tulokset
DSDM:n toimitukset tapahtuvat aikataulun mukaan ja sisällöltään laajenevina. Toimituksissa on tarkoituksenmukainen toiminnallisuus, ja niitä tehdään lyhyiden kehitysjaksojen puitteissa. Toimiminen lyhyissä toimitusiteraatioissa mahdollistaa projektin hyvän seurannan. Stapleton, s. 16
Tuotteen ominaisuuksiin keskittyvä projektinohjaus on joustavampi kuin projektissa suoritettaviin tehtäviin perustuva projektinohjaus. Keskusteltuaan työryhmän muiden jäsenten kanssa ohjelmiston toteuttaja voi vapaasti valita tavan, jolla hän rakentaa tuotteessa tarvittavan ominaisuuden. Tehtäväkeskeisessä projektinohjauksessa toteuttajat kiinnittävät annetut tehtävät henkilökohtaisiksi aikatauluiksi. Nämä aikataulut ovat joustamattomia.
Toimitukset voivat sisältää muun muassa ohjelmakoodia tai esimerkiksi järjestelmän malleja. Tuotteen avulla projekti etenee kohti lopullista järjestelmää. Tuotteen ei tarvitse olla täysin valmis kehitystyön ollessa kesken, vaan sen perustarkoitus on osoittaa se suunta, johon projekti etenee.
Toimitusten tarkoituksenmukaisuus
DSDM:ssä toimitettavan tuotteen on vastattava liiketoiminnan tarpeita. Perinteisessä ohjelmistotuotannossa on riittänyt se, että tuote vastasi vaatimusmäärittelyä, vaikka määritellyt ominaisuudet olisivat olleet epäolennaisia tai tarpeettomia. Liiketoiminnalle koituvien hyötyjen maksimointia on DSDM-projekteissa pidettävä jatkuvasti päätavoitteena.
Iteratiivisuus ja käytännön ratkaisut
Kehitystyö on iteratiivista, ja se tuo ratkaisuja todellisiin kehitystarpeisiin. Ajantasainen kommunikaatio mahdollistaa sen, että projektin suuntaa voidaan tarkistaa heti, kun ensimmäinen varoitus ilmenee. Näin virheiden korjaus tapahtuu heti, ja korjauskustannukset ovat alhaiset. Stapleton, s. 17
Palautuspisteet
Muutosten on oltava jäljitettävissä taaksepäin. Iteratiivinen ja ominaisuuksia lisäävä työtapa voi joskus johtaa ohjelmiston umpikujaan. Tällöin on voitava palata ohjelmiston aikaisempaan kehitysvaiheen palautuspisteeseen, josta voidaan valita toinen kehityslinja.
Kokonaiskuva
Tärkeimmät vaatimukset muutetaan tuotteen ominaisuuksiksi. Liiketoiminnan tarpeet täyttävät ominaisuudet ovat toteutusprioriteetiltaan korkeimmalla tasolla. Nämä vaatimukset on sovittu liiketoiminnan määrittelyn perusteella. Stapleton, s. 18
Testaus toteutusvaiheessa
Testaus on sisällytetty toteutusvaiheeseen. Mitä aikaisemmin testaus aloitetaan, sitä enemmän siitä on hyötyä. DSDM:n filosofia on "testaa kun voit". Kehittäjät testaavat teknisiä komponentteja ja käyttäjän edustajat toiminnallisuutta. Integraatiotestaus tehdään heti, kun komponentti voidaan yhdistää muuhun järjestelmään. Regressiotestaus on DSDM:ssä tärkeä, sillä aikaisempien komponenttien kanssa yhteen sopimaton uusi komponentti ei ole DSDM:n mukaan hyväksyttävissä. Jatkuvalla testauksella valvotaan koko ajan ohjelmiston laatua.
Yhteistyö
Projektin jäsenet työskentelevät yhteistyössä. DSDM-projektin perusta on me-henki, koska vastuu on jaettu ryhmän jäsenten kesken. Yhteistyössä työskenteleminen edellyttää ryhmän jäsenten välistä luottamusta. Lisäksi tilaajalla ja toimittajalla on oltava tarkka käsitys siitä, mitkä ominaisuudet ovat lopputuotteessa välttämättömiä. DSDM:ssä ajatellaan, että kehittäjät eivät kykene määrittämään järjestelmän käyttäjien tarpeita ilman yhteistyötä heidän kanssaan. Jokaisen työryhmän jäsenen on tultava toimeen jokaisen muun jäsenen kanssa hänen organisaatioasemastaan riippumatta. Jos projektin jäsenet eivät työskentele yhteistyössä, työryhmästä katoaa me-henki.Stapleton, s. 19 - 20
DSDM-prosessi Kolme pizzaa ja juusto
Mitä vähemmän tuotteeseen tehdään ominaisuuksia, sitä varmemmin se tulee toimitetuksi ajallaan ja sitä helpompi sitä on ylläpitää. Stapleton, s. 12