stanford-oval/wikipedia huggingface dataset:
Pieni Ruokopuolinen
Vesistösuhteet

Järvi sijaitsee Kymijoen vesistössä (vesistöaluetunnus 14) Sysmän reitin valuma-alueen (14.8) Rautaveden alueella (14.83), jonka Sääksjärven valuma-alueeseen (14.833) se kuuluu. Järven vedenpinnan korkeus on 123,2 metriä mpy.
Martin

| Martin |
| --- | --- |
Nimipäivä:   
– suomenkielinen:  10. marraskuuta
– ruotsinkielinen:  10. marraskuuta
– ortodoksinen:  –
Muunnelmia:  Martti
Vastineita eri kielissä:  Mårten
Nimen alkuperä:  Martinus
Infobox OKNimi-testi OK: 
Martin on monissa maissa yleinen miehen etunimi. Nimi on latinalaisen Martinus-nimen lyhentymä ja viittaa alkujaan sodan jumala Marsiin. Nimen on tehnyt laajalti suosituksi Pyhä Martinus, (suom. Pyhä Martti), protestanttisissa maissa lisäksi Martti Luther. Nimen suomalainen vastine on Martti.
Martinin nimipäivä on suomenruotsalaisen ja vuodesta 2025 lähtien myös suomenkielisen kalenterin mukaan 10. marraskuuta, Martti Lutherin syntymäpäivänä. Samalla päivällä on suomenkielisessä kalenterissa jo ennestään nimi Martti.
Vuoden 2019 loppuun mennessä nimi Martin on Suomessa annettu 8 716 miehelle ja alle 25 naiselle. Nimen naispuolinen vastine on Martina. Monissa maissa Martin on yleinen myös sukunimenä.
Tunnettuja Martin-nimisiä > Kuvitteellisia Martineja

Martin Beck, poliisi Sjövallin ja Wahlöön poliisiromaaneissa
Martin Crane, televisiosarjassa Frasier
Martin Ellingham, kirurgi draamakomediasarjassa Doc Martin
Martin Keamy, televisiosarjassa Lost
Martin Prince, piirroshahmo televisiosarjassa Simpsonit
Zachary "Zack" ja Codester "Cody" Martin, televisiosarjoista Zackin ja Codyn viiden tähden elämää ja Viiden tähden merielämää.
Martin, soturi ja Redwallin luostarin perustaja Brian Jacquesin kirjassa Urhea Martin
Muita merkityksiä

Aston Martin, brittiläinen autovalmistaja
C.F. Martin & Company, yhdysvaltalainen kitaravalmistaja
Glenn L. Martin Company oli yhdysvaltalainen lentokonevalmistaja
Lockheed Martin, yhdysvaltalainen aseiden, lentokoneiden ja avaruuslaitteiden valmistaja
Siemens-Martin-prosessi, ahjomellotus, historiallinen teräksem valmistusmenetelmä
Aiheesta muualla

Kuvia tai muita tiedostoja aiheesta Martin Wikimedia Commonsissa
Putkijärvi (järvi Hartolassa)

| Putkijärvi |
| --- | --- |
Valtiot:  Suomi
Maakunnat:  Päijät-Häme
Kunnat:  Hartola
Koordinaatit:  61°41′53″N, 25°52′55″E
Vesistöalue ja valuma-alueen tietoja
Päävesistöalue:  Kymijoen vesistö (14)
Valuma-alue:  Rautaveden alue (14.83)
Laskujoki:  Mertijoki Rautaveteen 
Järvinumero:  14.834.1.001
Mittaustietoja
Pinnankorkeus:  92,5 m  
Pituus:  2 km  
Leveys:  830 m  
Rantaviiva:  8,444 km  
Pinta-ala:  1,08708 km²   
Saaria:  7 
 fiPutkijärvi 
Putkijärvi  on Päijät-Hämeessä Hartolassa  Putkijärven lähellä sijaitseva järvi.
Maantietoa

Järvi on 2,0 kilometriä pitkä, 830 metriä leveä, ja sen pinta-ala on 109 hehtaaria eli 1,1 neliökilometriä. Järvellä on kartan mukaan 7 saarta.  Sen rantaviivan pituus on 8,4 kilometriä.
Vesistösuhteet

Järvi sijaitsee Kymijoen vesistössä (vesistöaluetunnus 14) Sysmän reitin valuma-alueen (14.8) Rautaveden alueella (14.83), jonka Merijoen valuma-alueeseen (14.834) se kuuluu. Järven vedenpinnan korkeus on 92,5 metriä mpy.
Dynamic Systems Development Method
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.selvennä 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:ää.
DSDM:n yleisperiaatteet > 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ä.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
DSDM:n yleisperiaatteet > 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.
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ää.
DSDM-prosessi > 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.
DSDM-prosessi > 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.
DSDM-prosessi > 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.
DSDM-prosessi > 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.
DSDM-prosessi > 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.
DSDM-prosessi > 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.
DSDM:n soveltaminen käytännössä > 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ä.
DSDM-projektin pitäminen aikataulussa > 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ä.
DSDM-projektin pitäminen aikataulussa > 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.