Dynamic Systems Development Method

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. 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. 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. DSDM kohdistuu jokaiseen projektissa mukana olevaan henkilöön. Sitä voidaan käyttää sekä rakenteisessa (proseduraalisessa) että olioperustaisessa lähestymistavassa projektin kaikissa vaiheissa.

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.

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. Prosessin tärkeimmät ohjausrakenteet ovat aikalaatikot ja ominaisuuksien priorisointi VTaToU-luokittelua käyttäen. 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ä.

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ä.

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ä.

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.

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.

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:ää.

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ä.

DSDM-projektin ja perinteisen projektin loppukäyttäjien osallistumista on kuvattu niin sanotulla piikikkään sohvan käyrällä.

Asiakkaan osallisuus projektissa.

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.

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.

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.

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.

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.

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ää.

DSDM-prosessin kuvaa on kutsuttu kolmeksi pizzaksi ja juustoksi. DSDM:n elinkaaressa on viisi vaihetta. Projekti etenee vahvojen nuolien mukaan, ja mahdolliset paluut aikaisempiin vaiheisiin on merkitty ohuemmilla viivoilla. DSDM-projektissa on seitsemän vaihetta, jotka ovat esiprojekti, toteutettavuus, liiketoiminnan määrittely, toiminnallisen mallinnuksen iteraatio (TOMI), suunnittelun ja toteutuksen iteraatio (SUTI), käyttöönoton iteraatio (KAI) ja jälkiprojekti.

Kolme pizzaa ja juusto.

Esiprojektin tehtävä on tuottaa projektille oikeat toimintamahdollisuudet. Esiprojektissa varmistetaan se, että projekti soveltuu DSDM-projektiksi ja että projekti alustetaan oikein. Kun käytännön järjestelyt on saatu suoritetuksi, alustava projektisuunnitelma sisältää suunnitelman toteutettavuuden tutkimisesta, joka on DSDM-projektin ensimmäinen vaihe.

Toteutettavuus ja liiketoiminnan määrittely suoritetaan peräkkäin. Ne asettavat perussäännöt kehitystyölle, joka on iteratiivista ja laajenevaa. Projektiin kuuluu toteutettavuuden arviointi silloinkin, kun DSDM:ää ei käytetä projektin toteutusvaiheessa.

Ohjelmistoihin tulisi DSDM:n ajattelutavan mukaan toteuttaa mahdollisimman vähän ominaisuuksia. Jokainen uuden ominaisuuden lisäys on perusteltava hyvin. Yleensäkin DSDM:n käytössä tulisi pyrkiä minimalistiseen lähestymistapaan, koska DSDM:n filosofia on tehdä tarpeeksi eikä yhtään enempää.

Toteutettavuuden määrittely (TOMA)

Toteutettavuuden määrittely (The Feasibility Study) on DSDM:n ensimmäinen askel. Projektista arvioidaan muun muassa onko järjestelmän tekninen toteutus mahdollinen, tuoko järjestelmä etuja liiketoiminnalle ja onko järjestelmän toteuttaminen vaivan arvoista. Lisäksi ratkaistaan se, onko DSDM sovellettavissa projektissa. DSDM ei sovellu kaikkiin projekteihin.

Toteutettavuuden määrittely kestää pisimmillään muutaman viikon. Sen arvioinnissa käydään läpi projektin pääkohdat ilman yksityiskohtia. Jos projektissa on suuria riskejä, päätös jatkamisesta tehdään, kun riskeistä on riittävästi tietoja.

Toteutettavuuden määrittelyn aikana laaditaan toteutettavuusraportin lisäksi ja sen pohjalta toteutuksen yleissuunnitelma. Lisäksi toteutetaan nopeasti laadittu prototyyppi niissä tapauksissa, joissa se tuo projektille lisäarvoa. Prototyypin rakentaminen on turhaa, jos järjestelmästä ei ole riittävää tietoa.

Liiketoiminnan määrittely (LIMA)

Jos DSDM:n on todettu soveltuvan käytettäväksi projektissa, liiketoiminnan määrittely (The Business Study) on sen ensimmäinen varsinainen vaihe. Se tuottaa perustan, jolle kaikki muu työ pohjautuu. Tarkoituksena on ymmärtää liiketoimintaprosesseja ja löytää tietosisältö, jonka järjestelmä tarvitsee palvellakseen niitä. Määrittely sisältää liiketoiminnalliset ja tekniset osat. Liiketoiminnan määrittelystä syntyvät dokumentit ovat liiketoiminta-alueen määrittely (Business Area Definition), järjestelmän arkkitehtuurin määrittely (System Architecture Definition) ja kehityssuunnitelma (Development Plan). Liiketoiminta-alueen määrittely on yleiskuvaus automatisoitavista prosesseista, järjestelmän arkkitehtuurin määrittely kuvaa järjestelmän arkkitehtuurin ja kehityssuunnitelma. Kehityssuunnitelma kertoo, miten toiminnallisen mallin iteraatio ja suunnittelun ja toteutuksen iteraatio toteutetaan. Kehityssuunnitelma sisältää kuvaukset prototypoinnin, testauksen ja kokoonpanonhallinnan toteuttamisesta.

Toiminnallisen mallin iteraatio (TOMI)

Toiminnallisen mallin iteraation (Functional Model Iteration) tarkoituksena on tarkentaa liiketoiminnan määrittelystä syntynyt järjestelmän prosessien ja tietosisällön kuvaus. Huolellista analyysia pidetään DSDM:ssä edellytyksenä oikean järjestelmän rakentamiselle. Järjestelmän malli ja toiminnallisuuden toteuttavat komponentit määritellään niin, että ne ovat yhtäpitävät. Ei-toiminnallisista vaatimuksista voidaan kuvata muun muassa käytettävyyteen liittyviä asioita.

Iteraation vaiheet ovat tunnistus, aikataulutus, toteutus ja katselmus. Tunnistuksessa määritellään kierron tehtävät, aikataulutuksessa se, miten tehtävät suoritetaan. Toteutus toteuttaa suunnitelmat. Katselmoinnin tarkoitus on varmistaa, että on tehty oikeat asiat.

Vaiheen lopputuloksena on analyysidokumentaatio ja toimintakelpoinen ohjelmisto, jonka testatut komponentit sisältävät päätoiminnallisuudet. Vaiheen tuloksena syntyvät dokumenttien tulee sisältää toiminnallisuuksien priorisointi, ei-toiminnalliset vaatimukset, käyttöönottosuunnitelma ja prototyyppien katselmointidokumentit. Tärkein osa katselmointidokumenteissa on prototyypeistä saadut käyttäjäkommentit.

Suunnittelun ja toteutuksen iteraatio (SUTI)

Suunnittelun ja toteutuksen iteraation (Design and Build Iteration) rakentaa järjestelmän sen operatiivisessa käytössä vaaditulle tasolle, ja lopputulos on testattu ohjelmisto. Ohjelmiston testausta tapahtuu koko vaiheen ajan.

Ohjelmiston tulisi sisältää sovitut ominaisuudet. Kaikkia projektin aikana havaittuja ominaisuuksia ei yleensä voida toteuttaa. Määrittelyprototyypistä kehitetään suunnitteluprototyyppi ja siitä edelleen toteutusprototyyppi.

Käyttöönoton iteraatio (KAI)

Käyttöönoton (Implementation) iteraatiossa järjestelmä siirretään toteutusympäristöstä tuotantoympäristöön ja sen lopputulos on dokumentoitu toimitettu järjestelmä. Iteraatiokiertoa ei tapahdu, jos järjestelmä toimitetaan yhdellä kertaa.

Käyttöönoton iteraatiovaiheen katselmus vastaa kysymykseen: "Vastaako järjestelmä liiketoiminnan asettamia vaatimuksia?" Käyttöönoton iteraatiosta voidaan palata takaisin aikaisempiin vaiheisiin kolmesta syystä. Näitä ovat kehitystyön aikana on havaittu tärkeä liiketoiminnan tarve, matalan prioriteetin toiminnallisuuden poistaminen ja suunnittelun ja toteutuksen iteraation aikana jo toteutetun ei-toiminnallisen vaatimuksen uudelleentoteuttaminen. Jos järjestelmä vastaa kaikkia vaatimuksia, ei lisätyötä tarvita. Järjestelmän dokumentoinnin lisäksi laaditaan ylläpito- ja käyttäjäohjeet. Käyttöönottoprojekti dokumentoidaan käyttöönottoraportissa.

Jälkiprojekti

Järjestelmän toimituksen jälkeen projekti siirtyy jälkiprojektiin (post-project). Järjestelmään tehtävät muutokset toimitetaan järjestelmän uusien julkaisujen yhteydessä. Jälkiprojektiin voi kuulua käyttöönoton katselmus, jossa arvioidaan se, kuinka hyvin järjestelmä täyttää sille asetetut tarpeet. Käyttöönottoon liittyviä muita asioita ei yleensä käsitellä.

DSDM:n soveltaminen käytännössä

Käyttöalueet ja -kohteet

DSDM:n käyttö edellyttää muihin ketteriin menetelmiin verrattuna enemmän vastuullisuutta toimia projektin itsenäisesti ohjautuvana toteuttajana. Aikaistetut suunniteltua laajemmat toimitukset ovat mahdollisia, mutta ne aiheuttavat lisätyötä.

DSDM soveltuu Stanpletonin mukaan parhaiten liiketoimintasovelluksiin, jotka ovat interaktiivisia ja joissa käyttöliittymä toteuttaa järjestelmän toiminnallisuuden, joiden käyttäjäryhmä on tarkasti rajattu, jotka eivät sisällä monimutkaista laskentaa, jotka voidaan suurissa järjestelmissä jakaa pienemmiksi osiksi, jotka voidaan toteuttaa suunnitellussa ajassa ja jotka sisältävät sellaisia ominaisuuksia, jotka eivät ole erittäin tarkkoja tai kiinnitettyjä. DSDM sallii minkä tahansa ohjelmistokehitysmenetelmän käytön.

Järjestelmän ydinmallin on oltava niukka mutta riittävä. Sen on varmistettava projektin hallinta ja ylläpidon vaivaton toteutus. Järjestelmän ydinmallin lisäksi laaditaan tukimallit. Nämä mallit laaditaan yhtäpitäviksi ennen järjestelmän kehittämisen aloittamista. Tukimallit ovat luonnoksia järjestelmän malleista. Ydinmallin sisältö ja yhtäpitävyys on tarkistettava koko kehitystyö ajan.

Iteraation ja toimitusten sisällön laajenevuus tosielämässä

Iteraation tarkoituksena on poistaa tuotteen virheet mahdollisimman aikaisessa vaiheessa. Iteraation vaarana on se, että toteuttajat ryhtyvät tavoittelemaan täydellisyyttä. Käytettäessä prototyyppejä on määriteltävä ne ominaisuudet, jotka prototyypissä toteutetaan. DSDM:ssä käytössä oleva aikalaatikointi katkaisee loputtoman iteraatiokierteen.

Laajenevat toimitukset sisältävä toimintatapa vastaa nopeimmin liiketoiminnan asettamiin tarpeisiin. Sen sivuvaikutuksena on, että kehittäjille syntyy useita samanaikaisia kehittämispaineita. Nykyaikaiset kehittämistyökalut auttavat ratkaisemaan näitä ongelmia, koska sen ansiosta voidaan laatia useita erityyppisiä tuotteita samanaikaisesti.

DSDM-projektin pitäminen aikataulussa

DSDM-projektin jäsenten tulisi hyväksyä se, että tuote jää valmiinakin epätäydelliseksi ja että yksittäisen kehittäjä ei saa miettiä uusia ominaisuuksia. Tuotteeseen rakennetaan ne ominaisuudet, jotka liiketoiminta edellyttää, ei muuta. Toteuttajat, jotka tavoittelevat täydellisyyttä, hukkaavat aikaa ja häiritsevän muun työryhmän toimintaa. Projekti menestyy, kun tuote on kyllin hyvä.

Projektin on oltava toteutumismahdollisuudeltaan realistinen. Projektin tavoitteet on määriteltävä tarkasti liiketoiminnan määrittely aikana. Tämän perusteella arvioida, voidaanko tavoite toteuttaa käytettävissä olevassa ajassa. Projektin aikana tehdyt ominaisuuksien lisäykset voidaan koettaa rakentaa siirtämällä projektin valmistumisajankohtaa eteenpäin tai lisäämällä projektiin kehittäjiä. Uusien kehittäjien lisääminen projektiin on tehotonta, koska heidän kouluttamisensa kuluttaa projektin alkuperäisten jäsenten resursseja.

Työryhmässä toiminnallisille ja ei-toiminnallisille vaatimuksille määritellyt priorisoinnit määräävät sen, mitä työryhmä tekee milloinkin. Työryhmä tekee nämä päätökset itsenäisesti ja työskentelee yhdessä prioriteetiltaan korkeimpien vaatimusten toteuttamiseksi.

Työpalavereja pidetään usein ja säännöllisesti, jotta varmistetaan projektin suunta, eikä niitä saa käyttää vain tehtävien antoon.

DSDM-projekti tulisi pystyä suorittamaan normaalin työajan puitteissa. Tosin DSDM ei poikkea muista projektinohjaustekniikoista siinä, että projekteissa tehdään yli- ja viikonlopputöitä.

Aikalaatikot

Aikalaatikko voidaan määrittää eri tavoin, voidaan esimerkiksi puhua aikavälistä projektin aloituksesta järjestelmän toimitukseen. DSDM:ssä koko projektin aikalaatikko sisältää peräkkäisiä aikalaatikoita, jotka edistävät projektin tavoitteita.

DSDM:ssä aikalaatikkojen pituus on tavallisesti 2–6 viikkoa. Lyhyitä aikalaatikoita suositellaan, jotta työn suunnittelu ja projektin ohjaus olisi helppoa. Aikalaatikon pituus voi kuitenkin olla jopa seitsemän viikkoa, jos projekti ei kärsi siitä.

Priorisointi ja VTaToU-luokittelu

DSDM-projektissa vaatimukset on asetettu tärkeysjärjestykseen. Tärkeimmät ominaisuudet toteutetaan ensin. Jokaiseen vaatimukseen liittyy laadullinen priorisointi. Laatupriorisointi suoritetaan vaatimuspriorisoinnista erillisenä.

Järjestelmän toiminnallisuuksien priorisointiin käytetään neliportaista VTaToU-luokittelua (engl. MoSCoW-rules). Jokaista priorisoitua ominaisuutta tarvitaan järjestelmässä, mutta päätoiminnat ovat välttämätön-ominaisuuksia.

VTaToU-luokittelu:

• V-ominaisuus (välttämätön): ominaisuudet jotka ovat järjestelmälle välttämättömiä.
• Ta-ominaisuus (tarpeellinen): ominaisuudet, joita ilman järjestelmä selviää.
• To-ominaisuus (toivottava): ominaisuudet, jotka on helpompi jättää pois kuin toteuttaa.
• U-ominaisuus (unelma): ominaisuudet, joita toivotaan, mutta joiden toteuttamiseen ei ole aikaa, joten ne voivat odottaa.

VTaToU-luokittelun soveltaminen VHS-nauhuriin:

• V-ominaisuus (välttämätön): nauhoitus, nauhan takaisinkelaus ja katsominen
• Ta-ominaisuus (tarpeellinen): ajastustoiminto
• To-ominaisuus (toivottava): pikakelaus ja pysäytyskuva
• U-ominaisuus (unelma): kaukosäädin, automaattinen nauhakohdan haku jne.

Aikalaatikoiden (AILA) käytännön toteutus

Aikalaatikkoprosessi

Aikalaatikkoprosessi lineaarisella asteikolla

Lyhyiden aikalaatikoiden käyttö koko projektin aikalaatikon sisällä varmistaa projektin tuotteen laadun ja sen, että aikataulu ei ylity. Lyhyet aikalaatikot helpottavat projektin edistymisen seurantaa.

Kukin aikalaatikko toteuttaa vaatimuksen. Kukin aikalaatikko sisältää vaiheet tutkimus (investigate), parantaminen (refinement) ja vakauttaminen (consolidation). Kukin vaihe alkaa suunnittelulla ja päättyy katselmukseen.

Tutkimusvaiheessa varmistetaan se, että aikalaatikossa aloitettu työ kulkee oikeaan suuntaan. Parantamisvaiheessa kehitetään aloitettua tuotetta, ja vakauttamisvaiheessa rakennetaan tuote toimituskelpoiseksi. Tutkimusvaihe seuraan aikalaatikon käynnistyksen (kick-off) jälkeen, ja vakauttamisvaiheen jälkeen seuraa aikalaatikon sulkeminen (close-out).

Iteraatiomallin mukainen tunnistus, aikataulutus, toteutus ja katselmointi sisältyvät aikalaatikon jokaiseen vaiheeseen.

Aikalaatikon käynnistyksessä määritellään aikalaatikon tavoitteet. Näitä ovat toimitettavat tuotteet ja niiden laatutaso. Käynnistyksessä ovat paikalla ainakin ryhmän johtaja, kehittäjät, testaajat ja suurlähettiläskäyttäjä. Usein käynnistykseen osallistuu myös projektipäällikkö ja tekninen yhteyshenkilö. Tärkeissä käynnistyksissä on läsnä myös muita avainhenkilöitä. Kaikkien osallistujien on oltava yksimielisiä siitä, että ainakin vähimmäistoimitus aikalaatikon lopussa on mahdollinen toteuttaa. Lisäksi sovitaan se, mikä on tutkimusvaiheen lopussa toimitettava tuote.

Aikalaatikossa toimitettavista tuotteista vain osa saa olla välttämätön-tasoa. Kehittäjillä tulee olla mahdollisuus tarpeen vaatiessa käyttää aikaa korkeimman prioriteetin tehtäviin. Toimituksen sisältö testataan tai katselmoidaan mieluummin aikalaatikon sisällä kuin sen jälkeen. Aikalaatikossa suoritettavat toimenpiteet tulisi määritellä toimitettavina ominaisuuksina, ei tiettyinä tehtävinä tai toimenpiteinä.

Aikalaatikoiden käyttö ei sovellu kaikkiin hankkeisiin. DSDM:ää ei saa käyttää silloin, kun se on sopimaton projektin tarpeisiin. DSDM:ää voidaan käyttää samanaikaisesti muiden sopivien menetelmien kanssa.

Projektien kauhuskenaario on hankkeen tärkeysasteen muuttuminen. Jos projektin aikana havaitaan uusi välttämätön-prioriteetti, mutta projektilla ei ole resursseja toteuttaa sitä, neuvotellaan tuotteen ominaisuuksista. Yleensä uuden ominaisuuden lisääminen tarkoittaa sitä, että jokin muu ominaisuus jätetään pois, mutta se ei ole tarpeen, jos aikataulu voidaan pitää. Toimitukseen voidaan varata nopea päivitystoimitus, jos toimitusaikataulu on joustamaton.

DSDM-työryhmä ja projektiroolit

DSDM määrittelee roolit ja vastuut sekä tilaajalle että toteuttajille. DSDM sisältää ryhmärooleja, ja ryhmän koko on tavallisesti 2–6 henkilöä. Kaksihenkisessä ryhmässä toinen on tekninen toteuttaja ja toinen käyttäjän edustaja. Tavallisesti DSDM-projektin koko on 1–2 ryhmää. Yli kuuden henkilön ryhmässä DSDM-prosessi ei enää toimi. Projektissa voi olla useita DSDM-ryhmiä. Suurin DSDM-ryhmämatriisin suositeltava koko on kuusi henkilöä kuudessa rinnakkain työskentelevässä ryhmässä. DSDM-organisaatio toteutetaan niin, että projektin käytettävissä on riittävä asiantuntemus. Se voidaan toteuttaa organisoimalla ryhmä eri tavoilla.

Projektiroolit

• Visionäärikäyttäjä (Senior User) varmistaa kaikkien kohteiden mukaantulon.
• Suurlähettiläskäyttäjä (Ambassador User) tuo liiketoimintatietämyksen projektiin. Hän osallistuu projektin toteutukseen päivittäin ja hankkii lisäselvityksiä omilta sidosryhmiltään.
• Tekninen yhteyshenkilö (Technical Co-ordinator) määrittelee järjestelmän arkkitehtuurin, varmistaa sovelluksen yhteensopivuuden arkkitehtuurin kanssa ja valvoo teknisten standardien ja vaatimusten toteutumista sekä projektin teknistä laatua.
• Testaaja (Tester) testaa sovellusta itsenäisesti ja raportoi tekniselle tukihenkilölle.
• Kehittäjä (Developer): analyytikko, suunnittelija, ohjelmoija tai mikä muu tahansa IT-rooli.

Prototyypin käyttö

Ohjelmmistoprojektissa ovat osapuolina kehittäjistä mm. ohjelmoijat, järjestelmäarkkitehdit, testaajat ja tilaajan puolelta mm. loppukäyttäjät, järjestelmän tilaaja sekä organisaation päätöksentekijät. Kunkin taho muodostaa tietojärjestelmästä ja sen ominaisuuksista oman näkemyksensä mukaisen kuvan, ja tämä kuva voi poiketa huomattavasti kunkin henkilöön taustasta riippuen. DSDM-järjestelmän prototyypit ovat yksi tapa tehostaa kehittäjien ja käyttäjien välistä keskustelua. Kehittäjät ymmärtävät teknisiä kaavioita, mutta käyttäjät tarvitsevat niiden tulkitsemiseen perehdyttämistä. Prototyyppejä käyttämällä kehittäjät toteuttavat "oikean järjestelmän". Suunnitteluvirheet pyritään havaitsemaan projektin varhaisessa vaiheessa.

Prototyyppilajit

DSDM:ssä käytetty sana prototyyppi tarkoittaa yksittäisiä järjestelmän komponentteja. Komponentti vastaa määrittelyjä, se on rakennettu kehitysalustalla ja sitä käytetään lähtökohtana jatkokehittelylle. Poiketen prototyypin yleisestä määrittelystä DSDM-prototyyppiä ei yleensä hylätä. DSDM-prototyypit kehittyvät projektin aikana toimitettavaksi järjestelmäksi.

DSDM:n prototyypit ovat liiketoiminta-, käytettävyys-, suorituskyky- ja kapasiteetti- sekä pystyvyys- ja suunnitteluprototyyppi. Liiketoimintaprototyyppi havainnollistaa järjestelmään rakennettavia liiketoiminnan tarvitsemia toiminnallisuuksia. Käytettävyysprototyyppi tarkastelee toiminnallisuuksiin liittymättömiä käyttöliittymän ominaisuuksia. Suorituskyky- ja kapasiteettiprototyyppiä käytetään varmistamaan järjestelmän suoriutuminen sille asetetusta kuormituksesta. Pystyvyys- ja suunnitteluprototyyppi tutkii suunnittelun lähestymistapaa.

DSDM-prototyyppien näkökulmat eroavat toisistaan, ja niitä käytetään projekteissa usein rinnakkaisina. Yleinen yhdistelmä on liiketoiminta- ja käytettävyysprototyyppien käyttö yhdessä. Prototyypeistä valitaan yhdistelmät, joista saadaan paras hyöty.

Liiketoimintaprototyyppi syntyy toiminnallisen mallin iteraation aikana. Käytettävyysprototyyppi voidaan laatia toiminnallisen mallin tai prototyyppien suunnittelun ja toteutuksen iteraation aikana. Käytettävyysprototyyppiä käytetään pääasiassa toiminnallisen mallin iteraation aikana. Suorituskyky- ja kapasiteettiprototyyppi syntyy prototyyppien suunnittelun ja toteutuksen iteraation aikana. Pystyvyys- ja suunnitteluprototyyppi voidaan laatia missä tahansa DSDM-projektin iteraatiovaiheessa. Yleensä pystyvyys- ja suunnittelumalli hävitetään, kun se on tehnyt tehtävänsä.

Tarkoituksenmukaisen palautteen kerääminen

Eri DSDM-prototyyppien tehokkuuteen vaikuttaa se, kuinka hyvin niitä osataan käyttää. Liiketoimintaprototyyppi laaditaan käyttäjien kanssa tarkaksi kuvaksi liiketoiminnasta; muuten kehittäjät kirjoittavat koodia, jolla ei ole tarkoitusta.

Testattaessa käytettävyysprototyyppejä testitapausten on koostuttava tehtävistä, joita käytetään liiketoiminnassa. Muuten käyttäjät eivät tiedä, mitä tehdä käyttöliittymässä. Käyttöliittymä edustaa käyttäjälle järjestelmän toimintaa. Sen pitää vastata käyttäjän ajattelumallia ja tapaa, jolla liiketoiminta etenee.

Käytettävyysprototyypin laadinnassa käyttäjien pitää saada testata järjestelmää itsenäisesti. Tällöin saadaan esiin erot toteuttajien ja käyttäjien näkemyksissä. Käyttäjien sanallinen palaute siitä, mitä ja miksi he ovat jotain tekemässä, antaa kehittäjille runsaasti tietoa, jonka avulla he voivat parantaa järjestelmää.

Käytettävyysprototyypille sallitaan kaatuminen. Järjestelmään tulisi mielellään lisätä odotusaikoja, koska se antaa realistisemman kuvan toiminnasta ja estää käyttäjää pettymästä myöhemmin. Odotusajat on muistettava poistaa. Prototyyppien kehittämisdemonstraatiot ja käyttäjätestaukset ohjataan huolellisesti, ja kaikki käyttäjien palaute on tallennettava.

Aikalaatikko muutosten hallintavälineenä

Käyttäjät voivat ohjelmiston kehitystyön aikana muuttaa haluamiensa ominaisuuksien listaa muun muassa tutustuttuaan ohjelmistoon ja havaittuaan siinä ominaisuuksia, joita ovat alitajuisesti kaivanneet. Järjestelmää tulisi testata käyttäen eri käyttäjiä mahdollisimman usein. Siitä aiheutuu lisäkustannuksia, mutta tarkkojen määritysten löytyminen projektin varhaisvaiheessa on halvempaa.

Aikalaatikkojen taitava käyttö mahdollistaa sen, että edellytetyt muutokset ovat käsillä olevan asian kannalta olennaisia ja ne voidaan myös toteuttaa. Suurlähettiläskäyttäjän tehtävä on varmistaa järjestelmän tarvittavan toiminnallisuuden toteutuminen ja sen helppokäyttöisyys eli se, miten asiat voidaan tehdä paremmin. Suurlähettiläskäyttäjän kaikkia toiveita ei tarvitse käyttää. Muun muassa kohteiden värit ovat ominaisuuksia, joiden "korjaus" ei välttämättä ole tarpeen.

Hallitun ohjauksen säilyttäminen

Jos prototyypin kehittämisen aikana havaitaan, että määrittelyä täytyy muuttaa, se tulee käsitellä mahdollisimman nopeasti. Prototyyppien käyttö selventää liiketoiminnan vaatimuksia. Hallitsematon teknisten yksityiskohtien muuntelu saattaa heikentää järjestelmän saavutettavia teknisiä ominaisuuksia. Teknisen yhteyshenkilön on ohjattava järjestelmän teknisiä ominaisuuksia.

Kolmivaiheisen aikalaatikon käyttö auttaa kehittäjiä pysymään projektin edellyttämissä tehtävissä. DSDM-projektin käytössä oleva aika on lyhyt, eivätkä kehittäjät voi käyttää aikaa oman mielenkiintonsa kohteisiin tai henkilökohtaisten haasteiden ottamiseen. Kehittäjät eivät saa kehitystyön aikana ottaa kantaa järjestelmän tekniseen toteutukseen. Se tehtävä kuuluu tekniselle yhteyshenkilölle.

Laadunvarmistus

"Kyllin hyvä" -ohjelmistotuote

Järjestelmän pääominaisuudet sovitaan liiketoiminnan määrittelyn aikana. DSDM keskittyy tuottamaan tarvittavan ohjelmiston silloin kun sitä tarvitaan. Lisäksi se varmistaa ylläpidettävyyden, joka on toteutettu itse ohjelmistoon sekä siihen liittyvään dokumentaatioon. DSDM poistaa aikaisemmin ketteriin menetelmiin liitetyn "quick and dirty" –mielikuvan (nopeasti ja rumasti).

Nopeissa DSDM-projekteissa ei voida soveltaa perinteisten projektien laajaa laadunvarmistusmenettelyä, vaan ohjelmiston laadunvarmistus sisältyy itse DSDM-menetelmään. Ohjelmistossa hyväksytään tietty keskeneräisyys, ja ohjelmisto toimitetaan "kyllin hyvänä". Tämän määrittely ei ole aivan helppoa, mutta järjestelmän laatu on riittävällä tasolla, jos käyttäjät ovat riittävän tyytyväisiä käytettävyyteen ja toteuttajien ei tarvitse korjata ohjelmaa jatkuvasti.

Ohjelmiston ylläpidettävyystaso

DSDM-projektissa on määriteltävä ohjelmiston valmiusaste, jonka projekti toteuttaa. Korkein taso on se, että tuote on täysin ylläpidettävä ensimmäisestä toimituksesta alkaen. Keskitasolla tuotteen ylläpidettävyydessä on puutteita ensimmäisen toimituksen yhteydessä, mutta se täydennetään myöhemmin. Alimmalla tasolla tuote on tarkoitettu käytettäväksi väliaikaisena korjauksena ja se poistetaan tuotantokäytöstä heti, kun sen tarve on poistunut.

Korkeimman tason ylläpidettävyystason saavuttaminen on aikaa vievin mutta pitkällä aikavälillä edullisin. Jos järjestelmän ylläpidettävyys rakennetaan vasta projektin jälkeen, projektissa on kuitenkin tehtävä valmisteluja tämän suhteen. Lisäksi jatkoprojektille on oltava varma rahoitus. Väliaikaiseen käyttöön tarkoitetun ohjelmiston ylläpito vaatii paljon työtä ja on varmistuttava siitä, että se ei jää vakituiseen tuotantokäyttöön.

Testaus

DSDM-projekteissa suoritetaan testausta aikalaatikoissa koko projektin ajan. Yksikkö-, integraatio-, regressio- ja järjestelmätestausta suoritetaan samanaikaisesti. Yksikkötestauksen suoritus on samanlaista kun perinteisten projektien yhteydessä. Käyttäjä voi testata komponentin aikalaatikon sisällä, jolloin hänen käsityksensä vastaavat aikalaatikon määrittelyjä.

Integraatiotestaus tapahtuu aikalaatikossa silloin, kun toimitettava tuotteen täytyy toimia yhdessä muun ohjelmiston kanssa. Integraatiotestaus suoritetaan kyseisissä aikalaatikoissa koko projektina ajan ja integroitujen moduulien määrän tulisi kasvaa koko ajan kohti toimitettavien moduulien määrää. Toimitettaville moduuleille on suoritettava vähintään yksikkö- ja käyttäjätestaus.

Työryhmässä oleva käyttäjä arvioi järjestelmän käytettävyyttä projektin aikaisessa vaiheessa. Tämän johdosta virheiden korjaaminen on edullisempaa kuin perinteisessä mallissa, jossa virheet korjataan käyttäjätestauksen jälkeen projektin loppuvaiheessa tai tuotteen päästyä tuotantokäyttöön.

Testauksessa noudatettavat menettelyt on määriteltävä ennen projektin aloitusta. Epätietoisuus testauksen suoritustavasta voi aiheuttaa aikalaatikoiden keston ylittymistä.

The Capability Maturity Model (CMM)

Software Engineering Instituten (SEI) kehittämä CMM on yleisimmin käytetty malli ohjelmistoprosessin pystyvyydestä ja kypsyydestä. Se luokittelee ohjelmistoprojektit viidelle tasolle. DSDM:ää voidaan käyttää parantamaan ohjelmistoprojektien kypsyysastetta.

DSDM:n yhteydessä voidaan soveltaa sekä ISO 9000-3 -standardia että CMM:ää. DSDM:n käyttöönotto voi merkitä sitä, että yrityksen laadunvarmistusmenetelmät ja -tekniikat joudutaan vaihtamaan.

DSDM-projektin toteutus

Projektinohjaus

Yleisimpiä ohjelmistoprojektien riskejä ovat se, että kehitetty järjestelmä ei vastaa liiketoiminnan tarpeita, ja se, että projekti ylittää budjetin tai aikataulun. Näitä riskejä on myös DSDM-projektissa. Riskienhallinnan päätyökalu on DSDM-sopivuus ja riskilista. DSDM:ää tulisi käyttää niin, että työntekijöiden normaali työaika riittää työtehtävien suorittamiseen. DSDM-projektin logistinen ohjaus on haastavaa. Toisistaan riippuvien tehtävien aikataulutus vaatii taitoa, kun aikalaatikot ja kokonaiskehitysaika ovat lyhyet.

DSDM-projektissa muutosten hyväksyminen on hallinnoitu kevyemmin perinteisissä projekteissa. Toiminnalliset ja ei-toiminnalliset vaatimukset luokitellaan ja sijoitetaan aikalaatikoihin, ”toivottava (contingency)" -aikalaatikkoon sijoitetaan vähemmän tärkeä vaatimus, jota ei välttämättä tulla toteutumaan, ja aikalaatikon arvioitu pituus tulisi tarkistaa projektiryhmällä.

DSDM-projektin ryhmän johtaminen vaatii projektipäälliköltä perinteisiä projektin ohjauksen taitoja. Näitä taitoja käytetään vähemmän itse henkilöiden johtamiseen. Projektiin liittyvät vastuut ovat samat kuin aikaisemmin.

Edistymisen seuranta

DSDM-projektin seuranta tapahtuu seuraamalla päivittäin välttämätön-ominaisuuksien määrää ja toteutumista kunkin aikalaatikon sisällä. Ajan seuraaminen on epäolennaista, koska aika loppuu kaikesta huolimatta aikalaatikon täytyttyä.

Päivittäistä toteuttajatason työtä seurataan päivittäisissä ryhmätapaamisissa, joihin osallistuu koko ryhmä. Tapaaminen on työpäivän alussa tai lopussa ja sen kesto on noin 15 minuuttia (5–30 minuuttia), ja paras teho saavutetaan silloin, kun jokainen kertoo muille lyhyesti valmistuneesta työnosasta.

Vaikutukset organisaatioon

Projektiin osallistuvat käyttäjät koulutetaan toimimaan DSDM-ryhmän sääntöjen mukaan. Heidän pitää tietää roolinsa ja vastuunsa. DSDM merkitsee lyhyempiä viestipolkuja työryhmän sisällä ja työryhmästä sen ulkopuolisiin. Öljytty työryhmä (Facilitated Workshop) on esimerkki tästä. Yksi tavoite on myös koulutettu käyttäjä. Päätökset, jotka koskevat projektia ja jotka eivät ole projektiryhmän päätettävissä, on tehtävä nopeasti.

Suurlähettiläskäyttäjän tulee osallistua aktiivisesti ryhmän toimintaan, ja hänen tulee hallita liiketoiminta-alueensa ja olla työtovereidensa kunnioittama organisaationsa kaikilla tasoilla. Suurlähettiläskäyttäjän työaika hyväksytään projektille kuuluvaksi projektin alussa, ja ajasta pidetään kiinni.

Teknologinen tuki

Ketterät menetelmät perustuvat ohjelmistoihin. Näillä ohjelmistoilla voidaan visualisoida kehittäjien ajattelu, jolloin voidaan kerätä palautetta. Ohjelmistoja käytetään koodaukseen, käyttöliittymien suunnitteluun ja projektin ohjaukseen. Erinomainenkin ohjelma on erinomainen käytössä vain silloin, kun sitä osataan käyttää, joten käyttökoulutus on suoritettava hyvin. Ohjelmistot on hankittava harkiten.

Ketterää ohjelmistokehitysmenetelmää käyttävällä kehittäjällä on samat toiveet kuin perinteisissä ohjelmistoprojekteissa työskentelevillä. Tehtävät, jotka vievät aikaa varsinaiselta kehitystyöltä, olisi voitava hoitaa automaattisesti jollakin kehitysalustan työkaluohjelmalla. Näitä tehtäviä ovat muun muassa dokumentointi, konfiguraatioiden hallinta ja testaus.

DSDM-yhteenliittymä ei ota kantaa eri ohjelmistotyökalujen väliseen paremmuuteen DSDM-työkaluina, mutta se on kuvaillut "ketterän nirvanan". Se tukee koko DSDM-prosessia, ja sen työkalut ovat integroituja. Ohjelmistojen tärkeimmät ominaisuudet ovat automaattinen dokumentointi ja tiedon jakaminen.

DSDM kehitysalustalla käytettäväksi testaustyökaluksi on saatavilla useita ohjelmistoja. Tehokas ohjelmisto on ainoa keino rakentaa testausalusta nopeasti ja vaivattomasti. Myös testauksen suoritus on nopeampaa, kun testausohjelmisto on monipuolinen.

DSDM sisältää runsaasti kokoonpanon hallintaa (versionhallinta). Järjestelmän tulisi pystyä käsittelemään useita muunnelmia ja versioita. Organisaatiolla tulisi olla hyvä kokoonpanon hallintaohjelma, ennen kuin se voi ottaa käyttöön DSDM:n.

Extreme programming (XP) ja DSDM yhdessä

Extreme programming on suosittu ohjelmistojen ketterän kehityksen menetelmä. Ohjelmoijat työskentelevät 2–10 hengen ryhmissä yhdessä käyttäjien edustajien kanssa. Vuorovaikutus on vapaata, projektien aikataulut lyhyitä, palaverit päivittäisiä ja testaus jatkuvaa.

XP:tä voidaan pitää DSDM:n kanssa kilpailevana ketteränä menetelmänä. XP voidaan kuitenkin sisällyttää DSDM:n projektikehykseen.

XP:llä ja DSDM:llä on muutamia samankaltaisuuksia. Käyttäjät osallistuvat kehitystyöhön (XP:ssä ei niin aktiivisesti), testaus on jatkuvaa, muutosten lisääminen, nopeat palautetekniikat, nopeat toimitukset, keskittyminen siihen, mitä pitää ja voidaan tehdä nyt, pienet työryhmät ja se, että kehittäjien tulee hallita monia ohjelmistotekniikan osa-alueita.

XP ja DSDM täydentävät toisiaan, ja niiden erot ovat sovellus- ja painopistealueissa. XP:n projektinohjaus on vähäistä samoin kuin DSDM:ssä painotus ohjelmointiin. XP:n ja DSDM:n yhdistelmä on ohjattu projekti korkeatasoisella ohjelmoinnilla. DSDM antaa XP:tä paremmat valmiudet ohjata suuria projekteja, mikä johtuu sen tarkemmasta vastuiden määrittelystä.

XP:n tärkein työtapa on pariohjelmointi, mutta osa ohjelmoijista ei pidä siitä. Pariohjelmointia voidaan käyttää DSDM-projektissa, mutta siihen ei voi pakottaa ketään. DSDM-toteuttajalla on oltava vapaus määritellä omat työtapansa ja -menetelmänsä.

Testitapausten laatiminen ennen koodauksen aloittamista on XP:n perusperiaate. Käytännöllisintä on laatia testitapaukset käytettäväksi aikalaatikon parantamisiteraation alusta alkaen ja edelleen vakauttamisiteraatiovaiheessa.

XP edellyttää, että kehitysympäristö on vakaa ja nopea. Uusi koodi liitetään ja testataan kokonaisuudessaan muutaman tunnin välein tai ainakin kerran päivässä. DSDM:n käyttö helpottaa monikehittäjäympäristössä integraation toteutusta.

Ohjelmiston ylläpito toimituksen jälkeen

Nimestään huolimatta DSDM soveltuu myös järjestelmän ylläpitoon sen toimituksen jälkeen, ja sitä on käytetty myös tietojärjestelmän infrastruktuuriprojekteissa. DSDM:ää voidaan käyttää ohjelmiston ylläpidossa poistamalla siitä järjestelmän kehittämiseen kuuluvat ominaisuudet. DSDM:n yhdeksää periaatetta noudatetaan, ja ylläpito on liiketoimintakeskeistä.

Ohjelmiston ylläpitotoimitusten aikataulusta tulisi olla yksimielisyys liiketoiminta- ja järjestelmän ylläpitäjän kesken. Aikalaatikkoa ei voida käyttää yhtä tarkasti kuin järjestelmän rakentamisvaiheessa, koska muutokset toteutetaan tarvittaessa ja ad hoc -menettelyllä. Ylläpitoprojektin toteutus vastaa työtavoiltaan tavanomaista ohjelmistoprojektia. Päivitykset laaditaan niin, että käyttäjät osallistuvat niiden laatimiseen.

Kun toteuttajat ovat saaneet ohjelman omalta osaltaan valmiiksi, suurlähettiläskäyttäjä testaa ohjelman ja tarkastaa sen dokumentaation. Lisäksi suurlähettiläskäyttäjän on varmistuttava siitä, että ohjelmistossa tapahtuneet muutokset tulevat käyttäjien tietoon.

Jos ohjelmistoon tulee uusia merkittäviä muutoksia, muutosten tekeminen aloitetaan niiden osalta jälleen projektin alkupisteestä. Se tarkoittaa esimerkiksi uutta vaatimusmäärittelyä ja aikataulutusta.

Ammattimainen ketteryys

Nopeat kehitysmenetelmät saivat huonoa mainetta 1990-luvun alussa, kun jotkut kehittäjät toteuttivat järjestelmiä nopeasti ja pyrkimättä hyvään ylläpidettävyyteen. Menetelmiä on pidetty nopeina ja rumina (pikaisina ja likaisina, engl. quick and dirty). DSDM:n myötä ammattimaisten ketterien kehittäjien arvostus on noussut. Hakkerit (sanan kielteisessä merkityksessä) eivät kuulu DSDM:ään.

DSDM voidaan sertifioida. Sen on oltava käytössä vähintään kuusi kuukautta, projektit on dokumentoitava, ja kehittäjän on osallistuva suulliseen kokeeseen osoittaakseen sisäistäneensä DSDM:n.

Projektin jäsenten henkilökohtaiset taidot ja ominaisuudet merkitsevät paljon, koska kuten muissakin projektinohjaustekniikoissa, projektin epäonnistuminen aiheutuu useimmiten projektin henkilöstöstä. Tekniset ongelmat ovat usein helpommin ratkaistavissa kuin henkilöiden väliset ongelmat. Kehittäjien tulisi olla "joukkuepelaajia", jotka eivät keskity liikaa toteutusteknologioihin.

Jokaisen projektin jäsenen on kyettävä toimimaan ryhmässä ja teknisten taitojen lisäksi myös kyettävä viestimään tehokkaasti. Kehittäjillä pitää olla taitoja ja mielenkiintoa kaikkia ohjelmistotuotannon osa-alueita kohtaan. Kehittäjän on oltava valmis jakamaan oman työnsä tulokset muiden ryhmän jäsenten kanssa ja hankittava aktiivisesti käyttäjäpalautetta. Kehittäjälle on tärkeää voida muuttaa nopeasti suunnittelutavoitteitaan. Joustavuus on avaintekijä DSDM:ssä, vaikka jotkut kehittäjät kokevat sen uhkatekijänä.

Yleisin syy DSDM:n vastustukselle on kehittäjien tuntema vastenmielisyys käyttäjäkontakteja kohtaan. Syynä on se, että käyttäjät arvostelet prototyyppejä ja ovat haluttomia neuvottelemaan järjestelmästä. Kehittäjät ajattelevat loogisesti, ja heidän on vaikea ymmärtää käyttäjien "epäloogisuutta".

DSDM on ohjattu prosessi, johon kuuluu olennaisena osana työryhmän yksilöiden vastuu ja toteuttajien itseohjautuvuus ja laatutietoisuus. DSDM-prosessia on valvottava myös pienissä yhden tai kahden kehittäjän projekteissa.

DSDM ja kohtalokkaita virheitä

Projektinohjauksessa käytettävää menetelmää tulisi soveltaa projekteissa pikkutarkasti. Esimerkkinä viisi ohjelmistoprojektia, joiden laatu kärsi DSDM:n puutteellisesta soveltamisesta.

Projektilla ei ollut teknistä yhteyshenkilöä

DSDM-projektin aloittajilla oli pitkä kokemus. Projektille ei valittu teknistä tukihenkilöä, koska sellaista ei ollut kuulunut aikaisempiinkaan projekteihin.

Hanke eteni aikalaatikko kerrallaan, ja ongelmia alkoi ilmetä. Kukaan ei vastannut ohjelmiston kokoonpanosta ja ohjelmistoarkkitehtuurista. Päivittäiset puolentunnin palaverit venyivät pitkiksi keskusteluiksi parhaista ratkaisuvaihtoehdoista. Aikataulun ylitykset olivat suuria.

Kunkin aikalaatikon lopussa tehtiin ylitöitä, jotta aikalaatikko saatiin suljetuksi. Tuloksena oli minimiominaisuudet sisältäviä moduuleja. Eri aikalaatikoiden moduulit jäivät huonosti integroiduiksi. Seurauksena oli paljon vaivaa niiden jälkeisissä aikalaatikoissa. Projektin jälkeen jokainen työntekijä otti kahden viikon loman.

Suurlähettiläskäyttäjän tietämystä ei arvostettu

Rahoitusalan järjestelmää kehittivät suunnittelijat ja ohjelmoijat, jotka olivat työskennelleet alalla ja tiesivät mielestään siitä kaiken. He lisäsivät järjestelmään uusia ominaisuuksia omien tulkintojensa ja ideoidensa pohjalta. Ryhmä oli kenties kaikkien aikojen liiketoimintaorientoitunein toteuttajaryhmä.

Ensimmäiset ongelmat ilmenivät liiketoiminnan määrittelyvaiheessa. Kehittäjien mielestä heidän hahmottamansa ratkaisut olivat luonnostaan parempia kuin suurlähettiläskäyttäjän (nainen) ja visionäärin. Siitä huolimatta suurlähettiläskäyttäjä suostui osallistumaan projektiin kolmena päivänä viikossa.

Ensimmäisen aikalaatikon tutkimusvaiheessa suurlähettiläskäyttäjä laati testiskenaarion. Saapuessaan testaamaan skenaariotaan aikalaatikon parantamisvaiheessa, hän totesi, että moduuli ei vastannut sovittua. Kehittäjät vakuuttivat jälleen tietävänsä kaiken. Yhden kehittäjän kuultiin sanovan: "She doesn't understand all that we can do for her, she's too stupid!"('Onpa tyhmä, kun ei ymmärrä, mitä me teemme hänen hyväkseen) Sen jälkeen suurlähettiläskäyttäjä jätti hankkeen lopullisesti.

Kehittäjät kehittivät väärän järjestelmän. Järjestelmä epäonnistui sekä toiminnallisesti että käytettävyydeltään.

Käytettiin DSDM:ää nimellisesti

Kolmen toteuttajan projektissa projektipäällikkö ei ollut sisäistänyt DSDM:n yhdeksää periaatetta. Projektia johdettiin kuulopuheilla, eikä työryhmällä ollut DSDM:n koulutusta eikä kokemusta siitä. Ryhmän käyttäjä-jäsentä kutsuttiin suurlähettiläskäyttäjäksi, vaikka se ei ollut hänen työroolinsa. Projektia kutsuttiin DSDM-projektiksi ja DSDM:n termejä käytettiin huolettomasti.

Projektipäällikkö laati perinteisen projektiaikataulun, joka noudatti vesiputousmallia ja perustui tehtäviin. Virstanpylväät merkittiin "aikalaatikoiden" loppupisteiksi, ja ne olivat osin päällekkäisiä. Priorisointia suoritettiin satunnaisesti. Projektin vaiheet viivästyivät. Toteutumattomat tehtävät siirrettiin seuraavaan vaiheeseen.

Projekti toimitti sovitun järjestelmän mutta ylittäen aikataulunsa ja budjettinsa. Projektin johto totesi, että DSDM ei hyödytä heitä, ja se hylättiin. Projektin jäsenet olivat samaa mieltä.

Projektilta puuttui testaus- ja laatusuunnitelma

Projektiryhmä oli omaksunut DSDM:n. Projektin aloitusvaiheessa teknisen yhteyshenkilön tehtävät jaettiin useammalle henkilölle ilman erityisvastuualueita. Työryhmässä ei ollut testaajaa.

Kehittäjät suorittivat komponenteille vain yksikkötestauksen. Muutamaa viikkoa ennen toimitusta kehitysryhmään lisättiin testausryhmä, joka totesi ohjelmistossa runsaasti ongelmia.

Testausryhmä ei priorisoinut tehtäviään. Suurlähettiläskäyttäjä ja tekniset yhteyshenkilöt eivät osallistuneet testausryhmän toimintaan. Toimitettu ohjelman suorituskyky oli huono ja eikä soveltunut käyttötarkoitukseensa.

Projektista puuttui me-henki

Projektin kehityshenkilöstön ja tilaajaorganisaation välimatka oli 80 kilometriä. Projekti alkoi lupaavasti. Ilmeni kuitenkin, että suurlähettiläskäyttäjä ei voinut olla muiden tehtäviensä takia läsnä kehitysryhmässä. Kehitysryhmäkään ei voinut järjestää työskentelyä suurlähettiläskäyttäjän luona, koska organisaation infrastruktuuria ei haluttu saattaa yhteensopivaksi.

Projektin edetessä tilaajan ja toimittajan yhteishenki katosi. Yhteyttä pidettiin sähköpostilla ja puhelimitse. Toteuttajien viestit olivat ammattislangia, eivätkä tilaajat ymmärtäneet niitä. Niin mielenkiinto projektiin katosi.

Projekti toimitettiin, mutta tilaajat olisivat tahtoneet osallistua enemmän kehitystyöhön. Kehitystyössä pitäisi saada liiketoimintaosaaminen siirretyksi toteuttajille ja edelleen kehitettävään järjestelmään.

Katso myös

• Ketterät menetelmät
• Scrum
• Käyttäjätuotanto

Lähteet

• Stapleton, J. (toim.): DSDM Business Focused Development Second edition. Yhdistynyt kuningaskunta: Pearson Education Limited, 2003. ISBN 0-321-11224-5

Aiheesta muualla

• DSDM Consortiumin sivusto (Arkistoitu – Internet Archive)
• Agile Alliance (Arkistoitu – Internet Archive)