Dynamic Systems Development Method

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ä.[14]

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

Asiakkaan osallisuus projektissa[15].

Nopeasti tapahtuva ohjelmiston kehittäminen edellyttää sitä, että tarvittavat valinnat voidaan tehdä nopeasti. Hidas päätösaikataulu yleensä estää tarvittavien ominaisuuksien toimittamisen ajallaan. [16]

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. [16]

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. [17]

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. [17]

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. [17]

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. [1]

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. [18]

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. [1]

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. [19]

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. [19]

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.[20]

Mitä vähemmän tuotteeseen tehdään ominaisuuksia, sitä varmemmin se tulee toimitetuksi ajallaan ja sitä helpompi sitä on ylläpitää. [21]

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. [6]

Kolme pizzaa ja juusto[22].

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. [6]

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. [6][21]

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ää.[23]

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. [24]

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. [24]

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. [24]

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ä.[25] Määrittely sisältää liiketoiminnalliset ja tekniset osat. [21] 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. [26]

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.[27]

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.[28]

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.[29]

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. [30]

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

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. [31]

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.[32]

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ä.[33]

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ä.[34]

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.[35]

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. [36]

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. [36]

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. [39]

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

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

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. [41]

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. [41]

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. [41]

Aikalaatikkoprosessi[42]

Aikalaatikkoprosessi lineaarisella asteikolla[42]

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.[43]

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

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). [44]

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

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.[46]

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ä.[40]

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. [43]

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. [43]

• 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.[49]

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ä. [52] DSDM-prototyypit kehittyvät projektin aikana toimitettavaksi järjestelmäksi. [51]

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. [52]

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. [52]

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ä.[48]

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. [53]

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ä.[52] 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.[50]

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ää.[54]

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.[53] Prototyyppien kehittämisdemonstraatiot ja käyttäjätestaukset ohjataan huolellisesti, ja kaikki käyttäjien palaute on tallennettava. [51]

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.[55]

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.[55]

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.[56]

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.[57]

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).[58]

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.[58]

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.[59]

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.[58]

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ä.[60]

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.[60]

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.[60]

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

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.[62]

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.[50]

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.[63] DSDM:ää tulisi käyttää niin, että työntekijöiden normaali työaika riittää työtehtävien suorittamiseen.[64] DSDM-projektin logistinen ohjaus on haastavaa. Toisistaan riippuvien tehtävien aikataulutus vaatii taitoa, kun aikalaatikot ja kokonaiskehitysaika ovat lyhyet.[65]

DSDM-projektissa muutosten hyväksyminen on hallinnoitu kevyemmin perinteisissä projekteissa.[53] 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ä.[66]

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.[65]

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ä.[66]

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.[64]

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.[67]

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.[67]

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. [68] 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.[69]

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.[68]

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.[70]

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.[68]

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.[71]

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.[72]

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

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.[73]

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ä.[74]

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ä.[75]

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.[76]

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.[76]

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

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. [85]

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. [85]

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ä. [86]

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. [86]

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. [86]

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

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. [86]

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.[87]

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ä. [88]

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. [88]

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

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. [88]

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.[89]

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. [90]

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. [90]