軟體設計的不同模型：瀑布式、快速原型法以及迭代式

自從1968年提出“軟體工程”概念以來，軟體開發領域對於借鑑傳統工程的原則、方法，以提高質量、降低成本的探索就從未停止過。而在這個過程中，提出了許多不同的軟體開發模型，典型的有：瀑布式，快速原型法，以及迭代式開發等。

• 瀑布式模型

是由W.W.Royce在1970年最初提出的軟體開發模型，在瀑布模型中，開發被認為是按照需求分析，設計，實現，測試 (確認)， 整合，和維護順序的進行。

• 快速原型法
  快速原型模型的第一步是建造一個快速原型，實現客戶或未來的使用者與系統的互動，使用者或客戶對原型進行評價，進一步細化待開發軟體的需求。通過逐步調整原型使其滿足客戶的要求，開發人員可以確定客戶的真正需求是什麼；第二步則在第一步的基礎上開發客戶滿意的軟體產品。
• 迭代式開發

在迭代式開發方法中，整個開發工作被組織為一系列的短小的、固定長度（如3周）的小專案，被稱為一系列的迭代。每一次迭代都包括了需求分析、設計、實現與測試。採用這種方法，開發工作可以在需求被完整地確定之前啟動，並在一次迭代中完成系統的一部分功能或業務邏輯的開發工作。再通過客戶的反饋來細化需求，並開始新一輪的迭代。

不同的開發模型，對於設計階段的工作要求也不盡相同。相對來說，瀑布式模型中對於設計文件的粒度要求得最細，而快速原型法對於設計的要求一般來說比較弱，迭代式開發在每一階段中的設計文件工作量都相對較少，但在軟體開發完成後，最終的設計文件完善程度要比快速原型法的好。

軟體設計的總體思路

軟體設計的本質就是針對軟體的需求，建立模型，通過將模型對映為軟體，來解決實際問題。因此軟體設計需要解決的核心問題是建立合適的模型，使得能夠開發出滿足使用者需求的軟體產品，並具有以下特性：

• 靈活性（Flexibility）
• 有效性（Efficiency）
• 可靠性（Reliability）
• 可理解性（Understandability）
• 維護性（Maintainability）
• 重用性（Reuse-ability）
• 適應性（Adaptability）
• 可移植性（Portability）
• 可追蹤性（Traceability）
• 互操作性（Interoperability）

因此，軟體設計並沒有一套放之四海而皆準的方法和模板，需要我們的設計開發人員在軟體的設計開發過程中針對軟體專案的特點進行溝通和協調，整理出對軟體專案團隊的行之有效的方式，進行軟體的設計。並保障軟體設計文件的一致性，完整性和可理解性。

誰來進行軟體設計

在我們開發人員中，有很多人這樣理解：“軟體設計文件就是軟體架構師和設計人員的事情”，其實不然。設計文件是整個軟體開發團隊的產出，其中有些設計文件由架構師或者設計人員給出，有些文件由開發人員給出。這並沒有一定的區分。

最佳實踐

我們經常聽到這樣的話：

• “設計文件沒有用，是用來糊弄客戶和管理層的文件”；
• “用來寫設計文件的時間，我的開發早就做完了”；
• “專案緊張，沒有時間做設計”；

這些言論，並不是正確的觀念，根據軟體專案的實際情況，軟體開發設計團隊可以約定設計文件的詳細程度。專案團隊需要保障設計文件的完整性和一致性，在專案進度緊張的情況下，軟體設計文件可以更初略一些；在專案時間充裕的情況下，相關文件可以更為詳盡。但是在專案開發過程中，需要軟體設計開發團隊對於設計文件有共同的理解。

設計文件分類與使用

通常來說，作為軟體專案，我們需要有這幾類文件

• 需求說明文件
• 功能設計文件
• 系統架構說明書
• 模組概要設計文件
• 模組詳細設計文件

就像我之前說到的，在某個軟體團隊，對於以上的文件的要求是可以完全不同的，在簡單專案中，可能所有型別的文件放在一個文件中進行說明；在複雜專案中，每一類文件可能都要寫幾個文件；而在最極端的情況下，可能每一類文件都能裝訂成幾冊。因此，在我們軟體設計和開發人員心目中需要明確的是：文件並不是我們進行設計的目標，也不是我們設計過程中額外的工作。

下面我們就軟體設計開發過程中必須要完成的工作進行梳理，而我們需要注意到，這些需要完成的工作，在不同的開發流程模型的指導下可能有不同的時間要求，而我們需要關注的是在這個階段內需要完成的工作，以及這個階段內我們需要溝通的人員。

需求分析

需求分析是我們進行任何一個軟體專案設計開發過程中都必須要完成的工作。

這個工作通常與客戶一起完成。在不同的專案中，這個“客戶”可能來自真正的購買產品的使用者，使用系統的使用者，也有可能來自團隊的某個人員，如產品經理等。軟體設計開發團隊的參與成員根據專案的不同規模，則參與的人員也有所不同。原則上，設計開發人員參與的時間點越早，對於需求的理解和把握會更好。這個階段，通常需要軟體架構師參與其中。從資源優化的角度來說，開發人員不必參與需求分析，但需要理解需求。

需求分析的結果通常我們需要使用需求說明文件來描述，目前主流的需求描述方法包括：使用者例圖、使用者故事等方式。這些方式有所不同的側重，其核心思想就是描述清楚使用者的使用場景。但無論採取何種方式，進行需求的描述，需求說明需要明確以下幾點：

• 所需要開發的軟體系統邊界
• 系統所有的相關及使用人員角色
• 系統關鍵的使用場景
• 系統規模、效能要求以及部署方式等非功能性需求

功能設計

功能設計與需求分析差不多同時在開展，在很多軟體專案中，對於功能設計不是特別重視。但對於某些軟體專案而言，這是一個相當重要的工作。對於主要是使用者介面的軟體專案來說，功能設計可以看作是畫出原型介面，描述使用場景，獲得使用者認可的過程。而對於沒有介面的軟體專案來說，則功能設計與需求分析的區分更為模糊。

參與的人員與需求分析的參與人員類似，架構師更側重於參與此類工作，並給與一些實現層面的判斷和取捨。

功能設計需要明確的核心是：

• 系統的行為

系統架構設計

系統架構設計是一個非常依賴於經驗的設計過程。需要根據軟體專案的特定功能需求和非功能性需求進行取捨，最終獲得一個滿足各方要求的系統架構。系統架構的不同，將很大程度上決定系統開發和維護是否能夠較為容易的適應需求變化，以及適應業務規模擴張。

架構設計工作中，使用者參與程度很低。軟體開發團隊中的需求人員參與程度很低，但團隊中的所有核心設計和開發人員都應該參與其中，並達成一致意見。

架構設計的主要成果，是將系統的不同檢視予以呈現，並使之落實到開發中：

• 系統開發檢視及技術路線選擇
• 系統邏輯檢視
• 系統部署檢視
• 系統模組檢視
• 系統的領域模型

在軟體開發過程中，系統的架構不是一成不變的，隨著設計人員和開發人員對於系統的理解不斷深入，系統的架構也會發生演化。在軟體專案中，架構設計是開發團隊溝通的統一語言，設計文件必須要隨著系統的變化進行更新，保障開發團隊對於系統的理解和溝通的一致性。

模組/子系統概要設計

模組/子系統的概要設計，由架構師參與，核心設計和開發人員負責的方式進行。
在概要設計工作中，我們需要在架構確定的開發路線的指導下，完成模組功能實現的關鍵設計工作。在概要設計階段，需要關注於模組的核心功能和難點進行設計。這個過程中更多推薦的採用UML來進行概要設計，需要進行：

• 模組實現機制設計
• 模組介面設計
• 關鍵類設計
• 畫出時序圖
• 互動圖等。

模組詳細設計

在瀑布式開發模型中，模組的詳細設計會要求比較嚴格，將所有類進行詳細設計。據我所知，除了一些對於系統健壯性要求非常嚴格的軟體專案，如國防專案，金融專案還要求有詳細設計文件之外。其他的專案大多采用其他方式來處理這樣的工作，如自動化測試等。

綜上所述，軟體設計文件作為軟體開發團隊的溝通、理解、知識共享的手段，具有非常重要的意義。而根據軟體團隊的規模，對於文件上承載的資訊詳細程度可以有不同程度的要求。我們軟體團隊對於*如何使用設計文件有一個統一的理解，並堅持更新設計文件*，這就是軟體設計的最佳實踐！

軟體設計所需要的知識與技能

• UML 統一建模語言
• 軟體工程
• 面向物件的程式設計 OOP
• 作業系統
• 資料庫原理
• 設計模式
• 溝通能力