DSDM業(yè)務中心框架開發(fā)方法[2]

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