軟體設計文件編寫概述

瀑布式、快速原型法以及迭代式

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

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

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

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

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

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

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

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

我們經常聽到這樣的話：

「設計文件沒有用，是用來糊弄客戶和管理層的文件」；

「用來寫設計文件的時間，我的開發早就做完了」；

「專案緊張，沒有時間做設計」；

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

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

軟體設計文件是我們在軟體設計開發過程中形成的，用來在軟體設計開發團隊內部以及與各干係人之間進行溝通的文件，記錄了軟體專案中的各種知識，方案的思路、以及各種決策意見。

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

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

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

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

1.所需要開發的軟體系統邊界

2.系統所有的相關及使用人員角色

3.系統關鍵的使用場景

4.系統規模、效能要求以及部署方式等非功能性需求

但對於某些軟體專案而言，這是乙個相當重要的工作。

1.對於主要是使用者介面的軟體專案來說，功能設計可以看作是畫出原型介面，描述使用場景，獲得使用者認可的過程。

2.對於沒有介面的軟體專案來說，則功能設計與需求分析的區分比較模糊。

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

功能設計需要明確的核心是系統的行為

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

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

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

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

模組/子系統的概要設計，由架構師參與，核心設計開發人員負責的方式進行。

在概要設計工作中，我們需要在架構確定的開發路線的指導下，完成模組功能實現的設計工作。

在概要設計階段，需要關注於模組的核心功能和難點進行設計。

推薦採用uml來進行概要設計，需要進行的工作如下：

在瀑布式開發模型中，模組的詳細設計會要求比較嚴格，將所有類進行詳細設計。

但現在除了一些對於系統健壯性要求非常嚴格的軟體專案，如國防專案，金融專案要求有詳細設計文件之外，其他專案大多採用其他方式來處理這樣的工作，如自動化測試等。

軟體設計文件作為軟體開發團隊的溝通、理解、知識共享的手段，具有非常重要的意義。

而根據軟體團隊的規模，對於文件上承載的資訊詳細程度可以有不同程度的要求。

軟體團隊對於如何使用設計文件有統一的理解，並堅持更新設計文件，才是軟體設計的最佳實踐！

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

軟體設計概述

軟體設計，是乙個很複雜的過程，需要先進行需求採集，然後進行需求分析，最後利用一些專業的設計工具對軟體進行設計，並交付給客戶相應的產出物，比如文件 包含 設計圖 原型等。一般的軟體設計 注 適用於簡單系統，不適用於複雜系統 主要包含概要設計 詳細設計兩部分，也是軟體整個生命週期非常重要的兩個階段，因為...

軟體設計文件

軟體設計文件的清單 1。結構文件。描述程式設計的文件，包括軟體所主要部分的描述以及相互之間的互動方式。2。資料流圖。表示資料在程式中如何流動的正規示意圖，戲稱 泡泡圖 3。狀態轉化圖。把軟體分解為基本狀態或者條件的一種正規示意圖。4。流程圖。用圖形描述程式邏輯的傳統方式。一旦投入使用，根據詳細的流圖...

軟體設計文件

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