DSDM周期有7個階段：
  1、項目準備階段；
  2、可行性研究階段；
  3、業務研究階段；
  4、功能建模階段（迭代式）；
  5、系統設計編程階段（迭代式）；
  6、實施階段；
  7、項目后期；
  項目準備階段確保啟動、建立正確的項目。可行性研究階段和業務研究階段是順序進行的，它們為后面的迭代、增量式的開發制定了基本規則。也就是說，在這兩個階段的工作充分完成后，才能進入后面的迭代階段，而后續迭代階段具體的迭代方式、迭代周期如何確定、整合，則需要視項目具體情況來定。比如：有些項目需要首先完成功能建模的全部迭代，然后再進入設計和編碼階段進行迭代，最后進入實施階段，這種方式是順序的，是各階段內部獨立完成迭代；有些項目將功能建模、設計和編碼這兩個階段的每一次相關的活動做為一次迭代，通過不斷的迭代，完成項目開發，最后進入項目實施；有些項目將功能建模、設計和編碼、實施這一個過程做為一次迭代，通過不斷的迭代，不斷的呈現給用戶滿足他們需求的軟件。因此，DSDM框架是極其靈活性的，在應用DSDM之前，必須要定義和評估使用DSDM的方式，在項目過程中，也可以隨需而變，進行動態調整，以便能夠更好的支持商業需求。DSDM“動態系統開發方法”的名稱也是由此得來的吧！哈！^_^
  DSDM的可行性研究階段主要側重評估DSDM方法是否適用于本項目，我覺得這一點比較與眾不同，因為在很多的可行性研究結果中，已經把瀑布模型默認為軟件開發方法了。在可行性研究階段需要得到一些結論“該系統技術上可行嗎？”、“對當前業務流程帶來的影響可接受嗎？”、“DSDM是開發這個系統最好的方法嗎？”......必須把這些問題弄清楚，以便確定“這樣去做值得嗎？”。然后需要出一份全面的可行性報告，對于風險很高的方面，還需要提供如何應對、控制風險的策略。除了可行性報告之外，還需要提供開發的框架計劃（outline plan），證明預期的結果是可實現的；另外，也可以提供一個快速原型，目的是證明項目從技術上是可行的。當然，如果對業務已經有了一定程度理解，相應的技術也已經用過，那么生成原型的價值也不大，可以不需要。DSDM的哲學就是：“足夠就好，無需過多！”。
  業務研究階段主要是對業務流程進行分析和定義。首先需要開展一系列的討論會，對業務流程及其相關信息、用戶群進行定義，這些定義的結果被稱做業務區定義，經過管理層同意后，需要從使用業務的用戶群中選出代表參與到開發過程中。進行業務區定義時，可以采用結構化分析方法，定義主要的數據流程圖；也可以采用面向對象的方法，定義重要的用戶用例。對于業務區定義的功能，必須區分出是功能性需求還是非功能性需求并且劃分優先級，因為DSDM是以業務為導向的，所有制定優先級的原則也必須要以業務為導向，但是也需要從技術實現需要的角度來考慮，把技術上要求先實現的功能做為高優先級。這樣就可以清晰的理解需要開發的功能和它們實現的優先級，從而引導我們對系統架構的定義，系統架構定義實際上定義了軟件開發、運行的平臺，軟件模塊和接口的結構。最后，根據可行性研究階段的開發框架計劃和業務區定義可以制定出開發計劃，這個開發計劃應該包含功能建模階段和設計編程階段的開發策略、測試策略和配置管理計劃。
  功能建模階段主要是深入分析業務區定義的功能并進行細化，在分析模型的基礎上構建軟件模塊，將創建的原型交付用戶評審，經過用戶評審后進一步充實和改進，這樣經過不斷迭代，原型逐漸演化成可工作的軟件。在功能建模階段，還會產生以下產物：
  1、帶有優先級的功能：隨著業務的細化，業務研究階段定義的優先級需要調整，從而保證本次迭代中包含用戶最需要的核心功能。
  2、功能性原型的評審文檔：用戶每次對原型評審時提出的改進建議都需要被記錄下來，并需要根據這些評審結果對業務定義、建模進行修正。
  3、非功能性需求：在功能建模階段將非功能需要也需要記錄下來。（但是，這里我就有一個問題一直比較困惑，因為在前期建模階段，主要注重了對業務流程的分析建模，和對高優先級需求的原型實現，倡導快速實現、交付用戶評審，因此，這個過程一直注重功能性需求，對于性能方面關注不多，因為無法從全局考慮、并更深入的考慮 到整個系統的性能瓶頸，特別是前期架構設計若存在缺陷將導致后期出現性能隱患，這是很難解決的；另外，若前期迭代功能與后期迭代關聯功能存在性能制約，也存在一定風險。因此，我覺得在這一階段，進行建模時也必須要考慮到各種可能的性能需求的技術實現，并且也需要制定優先級，在不同的迭代中處理必要的性能需求。）