如何寫軟件設計文檔

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

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

• 瀑布式模型

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

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

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

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

軟件設計的整體思路

軟件設計的本質就是針對軟件的需求，創建模型，經過將模型映射爲軟件，來解決實際問題。所以軟件設計須要解決的核心問題是創建合適的模型，使得可以開發出知足用戶需求的軟件產品，並具備如下特性：

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

所以，軟件設計並無一套放之四海而皆準的方法和模板，須要咱們的設計開發人員在軟件的設計開發過程當中針對軟件項目的特色進行溝通和協調，整理出對軟件項目團隊的行之有效的方式，進行軟件的設計。並保障軟件設計文檔的一致性，完整性和可理解性。

誰來進行軟件設計

在咱們開發人員中，有不少人這樣理解：「軟件設計文檔就是軟件架構師和設計人員的事情」，其實否則。設計文檔是整個軟件開發團隊的產出，其中有些設計文檔由架構師或者設計人員給出，有些文檔由開發人員給出。這並無必定的區分。

最佳實踐

咱們常常聽到這樣的話：

• 「設計文檔沒有用，是用來糊弄客戶和管理層的文檔」；
• 「用來寫設計文檔的時間，個人開發早就作完了」；
• 「項目緊張，沒有時間作設計」；

這些言論，並非正確的觀念，根據軟件項目的實際狀況，軟件開發設計團隊能夠約定設計文檔的詳細程度。項目團隊須要保障設計文檔的完整性和一致性，在項目進度緊張的狀況下，軟件設計文檔能夠更初略一些；在項目時間充裕的狀況下，相關文檔能夠更爲詳盡。可是在項目開發過程當中，須要軟件設計開發團隊對於設計文檔有共同的理解。

設計文檔分類與使用

一般來講，做爲軟件項目，咱們須要有這幾類文檔

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

就像我以前說到的，在某個軟件團隊，對於以上的文檔的要求是能夠徹底不一樣的，在簡單項目中，可能全部類型的文檔放在一個文檔中進行說明；在複雜項目中，每一類文檔可能都要寫幾個文檔；而在最極端的狀況下，可能每一類文檔都能裝訂成幾冊。所以，在咱們軟件設計和開發人員心目中須要明確的是：文檔並非咱們進行設計的目標，也不是咱們設計過程當中額外的工做。

軟件設計文檔是咱們在軟件設計開發過程當中造成的，用來在軟件設計開發團隊內部以及與各干係人之間進行溝通的文檔，這些文檔記錄了軟件項目中的各類知識，方案的思路、以及各類決策意見。

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

需求分析

需求分析是咱們進行任何一個軟件項目設計開發過程當中都必需要完成的工做。

這個工做一般與客戶一塊兒完成。在不一樣的項目中，這個「客戶」可能來自真正的購買產品的用戶，使用系統的用戶，也有可能來自團隊的某我的員，如產品經理等。軟件設計開發團隊的參與成員根據項目的不一樣規模，則參與的人員也有所不一樣。原則上，設計開發人員參與的時間點越早，對於需求的理解和把握會更好。這個階段，一般須要軟件架構師參與其中。從資源優化的角度來講，開發人員沒必要參與需求分析，但須要理解需求。

需求分析的結果一般咱們須要使用需求說明文檔來描述，目前主流的需求描述方法包括：用戶例圖、用戶故事等方式。這些方式有所不一樣的側重，其核心思想就是描述清楚用戶的使用場景。但不管採起何種方式，進行需求的描述，需求說明須要明確如下幾點：

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

功能設計

功能設計與需求分析差很少同時在開展，在不少軟件項目中，對於功能設計不是特別重視。但對於某些軟件項目而言，這是一個至關重要的工做。對於主要是用戶界面的軟件項目來講，功能設計能夠看做是畫出原型界面，描述使用場景，得到用戶承認的過程。而對於沒有界面的軟件項目來講，則功能設計與需求分析的區分更爲模糊。

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

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

• 系統的行爲

系統架構設計

系統架構設計是一個很是依賴於經驗的設計過程。須要根據軟件項目的特定功能需求和非功能性需求進行取捨，最終得到一個知足各方要求的系統架構。系統架構的不一樣，將很大程度上決定系統開發和維護是否可以較爲容易的適應需求變化，以及適應業務規模擴張。

架構設計工做中，用戶參與程度很低。軟件開發團隊中的需求人員參與程度很低，但團隊中的全部核心設計和開發人員都應該參與其中，並達成一致意見。

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

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

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

模塊/子系統概要設計

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

• 模塊實現機制設計
• 模塊接口設計
• 關鍵類設計
• 畫出時序圖
• 交互圖等。

模塊詳細設計

在瀑布式開發模型中，模塊的詳細設計會要求比較嚴格，將全部類進行詳細設計。據我所知，除了一些對於系統健壯性要求很是嚴格的軟件項目，如國防項目，金融項目還要求有詳細設計文檔以外。其餘的項目大多采用其餘方式來處理這樣的工做，如自動化測試等。

綜上所述，軟件設計文檔做爲軟件開發團隊的溝通、理解、知識共享的手段，具備很是重要的意義。而根據軟件團隊的規模，對於文檔上承載的信息詳細程度能夠有不一樣程度的要求。咱們軟件團隊對於*如何使用設計文檔有一個統一的理解，並堅持更新設計文檔*，這就是軟件設計的最佳實踐！

軟件設計所須要的知識與技能

• UML 統一建模語言
• 軟件工程
• 面向對象的編程 OOP
• 操做系統
• 數據庫原理
• 設計模式
• 溝通能力