系統分析與設計（二）

瀑布模型

優點：1.降低軟體開發的複雜程度，提高軟體開發過程的透明性，提高軟體開發過程的可管理性

2.推遲軟體實現，強調在軟體實現前必須進行分析和設計工作

3.以專案的階段評審和文件控制為手段有效地對整個開發過程進行指導，保證了階段之間的正確銜接，能夠及時發現並糾正開發過程中存在的缺陷，使產品達到預期的質量要求

缺點：1.強調過程活動的線性順序

2.缺乏靈活性，特別是無法解決軟體需求不明確或不準確的問題

3.風險控制能力較弱

4.瀑布模型中的軟體活動是文件驅動的，當階段之間規定過多的文件時，會極大地增加系統的工作量

5.管理人員如果僅僅以文件的完成情況來評估專案完成進度，往往會產生錯誤的結論

增量模型

優點：1.增強客戶對系統的信心

2.降低系統失敗風險

3.提高系統可靠性

4.提高系統的穩定性和可維護性

缺點：1.增量粒度難以選擇

2.確定所有的基本業務服務比較困難

螺旋模型

優點：1.設計靈活，可以在專案的各個階段進行變更

2.以小的分段來構建大型系統，使成本計算變得簡單容易

3.客戶始終參與每個階段的開發，保證了專案不偏離正確方向以及專案的可控性

4.隨著專案推進,客戶始終掌握專案的最新資訊，從而他或她能夠和管理層有效地互動

缺點：1.需要具有相當豐富的風險評估經驗和專門知識，在風險較大的專案開發中，如果未能夠及時標識風險，會造成重大損失

2.過多的迭代次數會增加開發成本，延遲提交時間

原型方法

優點：1.有助於增進軟體人員和使用者對系統服務需求的理解，減少兩者之間的誤解

2.易於確定系統的效能，確認各項主要系統服務的可應用性，確認系統設計的可行性，確認系統作為產品的結果

3.軟體原型版本有的可以原封不動地成為產品，有的略加修改就可以成為最終系統的乙個組成部分，有利於最終系統的建成

缺點：1.大型系統難以進行直接的原型模擬，只能經過系統分析得到系統的整體結構

2.原型方法難以構造處理大量運算、邏輯性較強的程式模組的原型

3.原有應用的業務流程、資訊流程混亂的情況下，原型構造與使用有一定的困難

4.批處理系統的大部分活動是內部處理的，應用原型方法會有一定的困難

5.此外原型方法還存在容易忽略文件工作、建立原型帶來的資源浪費、專案規劃和管理困難等問題

一、用例驅動

（1）採用用例來捕獲對目標系統的功能需求

（2）採用用例來驅動軟體的整個開發過程，保證需求的可跟蹤性，確保系統所有功能均被實現

（3）將使用者關心的軟體系統的業務功能實體功能模型和開發人員結合起來，提供一種貫穿整體軟體生存週期的開發方式，使得軟體開發的各個階段的工作自然、一致地協調起來

二、以架構為中心的

（1）強調在開發過程的早期，識別出軟體與軟體的體系結構緊密相關的用例，並通過對這些用例的分析、設計、實現和測試，形成體系結構框架

（2）在後續階段中對已形成的體系結構框架進行不斷細化，最終實現整體系統

（3）在開發過程中的早期形成良好的軟體體系結構，有利於對系統的理解、支援重用和有效的組織軟體開發

三、受控的迭代式增量開發

（1）將軟體開發分為一系列小的迭代過程，在每個得帶過程中逐步增加資訊、進行細化

（2）根據具體情況決定迭代的次數、每次迭代延續的時間以及迭代工作流

（3）每次迭代都選擇目前對風險影響最大的用例進行，以分解和降低風險

用例驅動和受控的迭代式增量開發體現使用者驅動開發，以架構為中心體現風險驅動開發。

每個階段結束於乙個主要的里程碑(major milestone)，並在階段結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意的話，可以允許專案進入下乙個階段。

初始階段里程碑：生命週期目標里程碑，包括一些重要的文件，如：專案構想、原始用例模型、原始業務風險評估、乙個或者多個原型、原始業務案例等。需要對這些文件進行評審，以確定正確理解用例需求、專案風險評估合理、階段計畫可行等。

精化階段里程碑：生命週期體系結構里程碑，包括風險分析文件、軟體體系結構基線、專案計畫、可執行的進化原型、初始版本的使用者手冊等。通過評審確定軟體體系結構已經穩定、高風險的業務需求和技術機制已經解決、修訂的項目計畫可行等。

構建階段里程碑：初始執行能力標里程碑，包括可以執行的軟體產品、使用者手冊等，它決定了產品是否可以在測試環境中進行部署。此刻，要確定軟體、環境、使用者是否可以開始系統的執行。

工期和質量均已由甲方乙方在合同中確定，只有範圍/內容是可變的，由團隊控制的。

因為迭代式增量開發過程中，每次迭代都是有過程可循的，只是在上一輪迭代的基礎上新增內容。有序生產的企業的迭代的週期是基本確定的。

系統分析與設計（二）

系統分析與設計（二）

系統分析與設計

系統分析與設計

相關推薦