stanford-oval/wikipedia huggingface dataset:
Dynamic Systems Development Method
DSDM-projektin pitäminen aikataulussa > Aikalaatikoiden (AILA) käytännön toteutus

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 kauhuskenaariokenen mukaan? 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.
DSDM-työryhmä ja projektiroolit > 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.
Prototyypin käyttö > 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ä.
Prototyypin käyttö > 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.
Prototyypin käyttö > 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.
Prototyypin käyttö > 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.
Laadunvarmistus > 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.
Laadunvarmistus > 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ä.
Laadunvarmistus > 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.
DSDM-projektin toteutus > 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.
DSDM-projektin toteutus > 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.
DSDM-projektin toteutus > 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.
DSDM-projektin toteutus > 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.lähde? 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.
DSDM ja kohtalokkaita virheitä > 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.