軟體架構設計文檔

㈠ 從一個人編寫的文檔就能看出他是否適合做軟體架構設計

1、能否分層次思考問題如果不能用較簡練的語言、較為清晰的描述清楚系版統所面對的問權題和解決思路，不合格。2、（同一層次中）能否清晰劃分模塊邊界，避免過度耦合比如，用戶注冊，則應為他初始化home目錄、分配磁碟限額;如果出現錯誤，則清理未成功初始化的目錄結構並提示用戶：這樣的說明就很好。介面狀態清晰、嚴謹;有了這樣的設計，就很難寫出太渣的代碼。反之，如果說成「用戶注冊時，先調用adser、如果adser返回xx則yy....」這樣就不太好。說明作者不太能區分高層設計與實現細節;遇到疑難/復雜問題時，容易被細節干擾設計，造成耦合過重甚至導致「面條設計」。更差的，可能是「xxx模塊調用yyy模塊的注冊用戶介面;yyy模塊要如何如何;如果yyy模塊返回什麼什麼錯誤，則xxx要怎麼怎麼...」：這樣的差的就比較遠了。他搞的設計，耦合不重已經不可能了。當然，做一些小的簡單項目（比如萬把行的、邏輯/演算法較簡單的[比如流程式的項目]），他還是能勝任的。至於差到表達不清的……還是洗洗睡吧。

㈡ 撰寫軟體詳細設計文檔時，怎麼描述軟體模塊之間的關系呢最好用圖。

概要設計文檔是唯一開發規范和程序模塊最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的概要設計怎麼做 結構化軟體設計方法：

㈢ 軟體文檔怎麼寫

1.0概述 這部分提供對整個設計文檔的概述。描述了所有數據，結構，介面和軟體構件級別的設計。

1.1 目標和對象 描述軟體對象的所有目標。

1.2 陳述范圍 軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。

1.3 軟體內容 軟體被置於商業或者產品線中，討論相關的戰略問題。目的是讓讀者能夠對「宏圖」有所了解。

1.4 主要系統參數 任何商務軟體或者產品線都包含軟體規定、設計、實現和測試的說明和規范。

2.0 數據設計 描述所有數據結構包括內部變數，全局變數和臨時數據結構。

2.1 內部軟體數據結構 描述軟體內部的構件之間的數據傳輸的結構。

2.2 全局數據結構 描述主要部分的數據結構。

2.3 臨時數據結構 為臨時應用而生成的文件的描述。

2.4 資料庫描述 作為應用程序的一部分，描述資料庫結構。

3.0 結構化和構件級別設計 描述程序結構。

3.1 程序結構 詳細描述應用程序所選定的程序結構。

3.1.1 結構圖 圖形化描述結構。

3.1.2 選擇性 討論其它可供考慮的結構。選定3.1.1中結構類型的原因。

3.2 構件描述 詳細描述結構中的每個軟體構件。

3.2.1 構件過程敘述(PSPEC) 描述構件的過程。

3.2.2 構件介面描述 詳細描述構件的輸入和輸出。

3.2.3 構件執行細節 每個構件的詳細演算描述。

3.2.3.1 介面描述

3.2.3.2 演算模型(e.g., PDL)

3.2.3.3 規范/限制 ]

3.2.3.4 本地數據結構

3.2.3.5 在3.2.3.6設計中包含的執行結果

3.3 軟體介面描述 軟體對外界的介面描述

3.3.1機器對外介面 與其他機器或者設備的介面描述。

3.3.2系統對外介面 對其它系統、產品和網路的介面描述。

3.3.3與人的介面 概述軟體與任何人的界面。

4.0 用戶界面設計 描述軟體的用戶界面設計。

4.1 描述用戶界面 詳細描述用戶界面，包括屏幕顯示圖標、圖片或者類型。

4.1.1 屏幕圖片 從用戶角度描述界面。

4.1.2 對象和操作 所有屏幕對象和操作的定義。

4.2 界面設計規范 用戶界面的設計和實現的規范和標准。

4.3 可見構件 實現的GUI可見構件說明。

4.4 UIDS描述 用戶界面開發系統描述。

5.0約束、限制和系統參數 會影響軟體的規格說明、設計和實現的特殊事件。

6.0測試標准 測試策略和預備測試用例描述。

6.1 測試的類別 規定實施測試的類別，包括盡量詳細的描述。這里是針對黑盒測試現象的描述。

6.2期待軟體反饋 測試期待的結果描述。

6.3執行界線 特殊執行需要的說明。

6.4 重要構件確認 決定性構件或者需要特殊注意的構件的測試確認。

7.0附錄 設計說明的補充信息。

7.1系統可跟蹤矩陣 一個定期回歸系統規格跟蹤軟體需求的矩陣。

7.2 產品戰略 如果規格說明書是為一個產品設計的，描述相關的產品戰略。

7.3 使用分析演算法 描述所有分析活動所使用到的分析演算法。

7.4 補充信息 (如果有需要特別說明的)

㈣ linux 怎麼寫軟體模塊詳細設計

概要設計階段通常得到軟體結構圖
詳細設計階段常用的描述方式有：流程圖、N-S圖、PAD圖、偽代碼等

概要設計和詳細設計
在軟體設計中，大家經常問到的一個問題是：概要設計應該怎樣一個概要法，詳細設計應該怎樣一個詳細法？
這個問題在公司內部經常有人問。現在陳述一下。
我們公司的研發流程是瀑布型的，這個模型中的分析、設計階段是基於經典的結構化方法。
結構化設計方法的基本思路是：按照問題域，將軟體逐級細化，分解為不必再分解的的模塊，每個模塊完成一定的功能，為一個或多個父模塊服務（即接受調用），也接受一個或多個子模塊的服務（即調用子模塊）。模塊的概念，和編程語言中的子程序或函數是對應的。
這樣一來，設計可以明顯地劃分成兩個階段：
概要（結構）設計階段：把軟體按照一定的原則分解為模塊層次，賦予每個模塊一定的任務，並確定模塊間調用關系和介面。
詳細設計階段：依據概要設計階段的分解，設計每個模塊內的演算法、流程等。

概要設計階段：
在這個階段，設計者會大致考慮並照顧模塊的內部實現，但不過多糾纏於此。主要集中於劃分模塊、分配任務、定義調用關系。模塊間的介面與傳參在這個階段要定得十分細致明確，應編寫嚴謹的數據字典，避免後續設計產生不解或誤解。概要設計一般不是一次就能做到位，而是反復地進行結構調整。典型的調整是合並功能重復的模塊，或者進一步分解出可以復用的模塊。在概要設計階段，應最大限度地提取可以重用的模塊，建立合理的結構體系，節省後續環節的工作量。
概要設計文檔最重要的部分是分層數據流圖、結構圖、數據字典以及相應的文字說明等。以概要設計文檔為依據，各個模塊的詳細設計就可以並行展開了。
詳細設計階段：
在這個階段，各個模塊可以分給不同的人去並行設計。在詳細設計階段，設計者的工作對象是一個模塊，根據概要設計賦予的局部任務和對外介面，設計並表達出模塊的演算法、流程、狀態轉換等內容。這里要注意，如果發現有結構調整（如分解出子模塊等）的必要，必須返回到概要設計階段，將調整反應到概要設計文檔中，而不 能就地解決，不打招呼。

詳細設計文檔最重要的部分是模塊的流程圖、狀態圖、局部變數及相應的文字說明等。一個模塊一篇詳細設計文檔。
概要設計文檔相當於機械設計中的裝配圖，而詳細設計文檔相當於機械設計中的零件圖。文檔的編排、裝訂方式也可以參考機械圖紙的方法。
我們公司對模塊的認識和傳統定義有所不同，認為是較大的軟體功能單元才可以稱作模塊。這種認識使大家對概要設計和詳細設計的分工產生了混亂的理解，降低了文檔的可用性，應該予以糾正。
概要設計中較頂層的部分便是所謂的方案。方案文檔的作用是在宏觀的角度上保持設計的合理性。
有的項目採用面向對象的分析、設計方法。可能在概要設計、詳細設計的分工上疑問更多。其實，面向對象的分析、設計方法並沒有強調結構化方法那樣的階段性，因此一般不引入概要、詳細設計的概念。如果按照公司的文檔體系，非要有這種分工的話，可以將包的劃分、類及對象間的關系、類的對外屬性、方法及協作設計看做 概要設計；類屬性、方法的內部實現看做詳細設計。

1.需求分析--產生軟體功能規格說明書,需要確定用戶對軟體的需求,要作到明確、無歧義。不涉及具體實現方法。用戶能看得明白，開發人員也可據此進行下面的工作（概要設計）。
2.概要設計--產生軟體概要設計說明書，說明系統模塊劃分、選擇的技術路線等，整體說明軟體的實現思路。並且需要指出關鍵技術難點等。
3.詳細設計--產生軟體詳細設計說明書，對概要設計的進一步細化，一般由各部分的擔當人員依據概要設計分別完成，然後在集成，是具體的實現細節。理論上要求可以照此編碼。

概要設計和詳細設計的區別與聯系
軟體設計採用自頂向下、逐次功能展開的設計方法，首先完成總體設計，然後完成各有機組成部分的設計。
根據工作性質和內容的不同，軟體設計分為概要設計和詳細設計。概要設計實現軟體的總體設計、模塊劃分、用戶界面設計、資料庫設計等等；詳細設計則根據概要設計所做的模塊劃分，實現各模塊的演算法設計，實現用戶界面設計、數據結構設計的細化，等等。
概要設計是詳細設計的基礎，必須在詳細設計之前完成，概要設計經復查確認後才可以開始詳細設計。概要設計，必須完成概要設計文檔，包括系統的總體設計文檔、以及各個模塊的概要設計文檔。每個模塊的設計文檔都應該獨立成冊。
詳細設計必須遵循概要設計來進行。詳細設計方案的更改，不得影響到概要設計方案；如果需要更改概要設計，必須經過項目經理的同意。詳細設計，應該完成詳細設計文檔，主要是模塊的詳細設計方案說明。和概要設計一樣，每個模塊的詳細設計文檔都應該獨立成冊。
概要設計裡面的資料庫設計應該重點在描述數據關繫上，說明數據的來龍去脈，在這里應該結合我們的一個結果數據，說明這些結果數據的源點，我們這樣設計的目的和原因。詳細設計里的資料庫設計就應該是一份完善的數據結構文檔，就是一個包括類型、命名、精度、欄位說明、表說明等內容的數據字典。
概要設計里的功能應該是重點在功能描述，對需求的解釋和整合，整體劃分功能模塊，並對各功能模塊進行詳細的圖文描述，應該讓讀者大致了解系統作完後大體的結構和操作模式。詳細設計則是重點在描述系統的實現方式，各模塊詳細說明實現功能所需的類及具體的方法函數，包括涉及到的sql語句等。

㈤ 誰有軟體項目管理文檔中「系統架構設計」的書寫規范，心得體會也行，我原先沒有寫過，不知道怎麼入手

規範本身有國標和軍標可供查詢啊。
實例你應該很難看到，這些都是涉密的文檔。

㈥ 做軟體項目設計文檔怎麼寫啊

按照以下格式填就好了，不過是我自己寫的，有不好的地方大家互相學習修改一下~

詳細設計文檔規范
1.0概述
這部分提供對整個設計文檔的概述。描述了所有數據，結構，介面和軟體構件級別的設計。
1.1 目標和對象
描述軟體對象的所有目標。
1.2 陳述范圍
軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。
1.3 軟體內容
軟體被置於商業或者產品線中，討論相關的戰略問題。目的是讓讀者能夠對「宏圖」有所了解。
1.4 主要系統參數
任何商務軟體或者產品線都包含軟體規定、設計、實現和測試的說明和規范。
2.0 數據設計
描述所有數據結構包括內部變數，全局變數和臨時數據結構。
2.1 內部軟體數據結構
描述軟體內部的構件之間的數據傳輸的結構。
2.2 全局數據結構
描述主要部分的數據結構。
2.3 臨時數據結構
為臨時應用而生成的文件的描述。
2.4 資料庫描述
作為應用程序的一部分，描述資料庫結構。
3.0 結構化和構件級別設計
描述程序結構。
3.1 程序結構
詳細描述應用程序所選定的程序結構。
3.1.1 結構圖
圖形化描述結構。
3.1.2 選擇性
討論其它可供考慮的結構。選定3.1.1中結構類型的原因。
3.2 構件描述
詳細描述結構中的每個軟體構件。
3.2.1 構件過程敘述(PSPEC)
描述構件的過程。
3.2.2 構件介面描述
詳細描述構件的輸入和輸出。
3.2.3 構件執行細節
每個構件的詳細演算描述。
3.2.3.1 介面描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 規范/限制
]3.2.3.4 本地數據結構
3.2.3.5 在3.2.3.6設計中包含的執行結果
3.3 軟體介面描述
軟體對外界的介面描述
3.3.1機器對外介面
與其他機器或者設備的介面描述。
3.3.2系統對外介面
對其它系統、產品和網路的介面描述。
3.3.3與人的介面
概述軟體與任何人的界面。
4.0 用戶界面設計
描述軟體的用戶界面設計。
4.1 描述用戶界面
詳細描述用戶界面，包括屏幕顯示圖標、圖片或者類型。
4.1.1 屏幕圖片
從用戶角度描述界面。
4.1.2 對象和操作
所有屏幕對象和操作的定義。
4.2 界面設計規范
用戶界面的設計和實現的規范和標准。
4.3 可見構件
實現的GUI可見構件說明。
4.4 UIDS描述
用戶界面開發系統描述。
5.0約束、限制和系統參數
會影響軟體的規格說明、設計和實現的特殊事件。
6.0測試標准
測試策略和預備測試用例描述。
6.1 測試的類別
規定實施測試的類別，包括盡量詳細的描述。這里是針對黑盒測試現象的描述。
6.2期待軟體反饋
測試期待的結果描述。
6.3執行界線
特殊執行需要的說明。
6.4 重要構件確認
決定性構件或者需要特殊注意的構件的測試確認。
7.0附錄
設計說明的補充信息。
7.1系統可跟蹤矩陣
一個定期回歸系統規格跟蹤軟體需求的矩陣。
7.2 產品戰略
如果規格說明書是為一個產品設計的，描述相關的產品戰略。
7.3 使用分析演算法
描述所有分析活動所使用到的分析演算法。
7.4 補充信息 (如果有需要特別說明的)

㈦ 需要說明一個軟體系統的各個層次的每一個程序(模塊)設計考慮的文件是什麼

摘要：
本文是在概要設計實踐和學習中的一些心得與學習筆記，希望與大家分享，如有不妥之處歡迎指正。
關鍵字：
概要設計，結構化，OOD
正文：
在需求明確、准備開始編碼之前，要做概要設計，而詳細設計可能大部分公司沒有做，有做的也大部分是和編碼同步進行，或者在編碼之後。因此，對大部分的公司來說，概要設計文檔是唯一的設計文檔，對後面的開發、測試、實施、維護工作起到關鍵性的影響。
一、問題的提出
概要設計寫什麼？概要設計怎麼做？
如何判斷設計的模塊是完整的？
為什麼說設計階段過於重視業務流程是個誤區？
以需求分析文檔還是以概要設計文檔來評估開發工作量、指導開發計劃准確？
結構化好還是面向對象好？
以上問題的答案請在文章中找。
二、概要設計的目的
將軟體系統需求轉換為未來系統的設計；
逐步開發強壯的系統構架；
使設計適合於實施環境，為提高性能而進行設計；
結構應該被分解為模塊和庫。
三、概要設計的任務
制定規范：代碼體系、介面規約、命名規則。這是項目小組今後共同作戰的基礎，有了開發規范和程序模塊之間和項目成員彼此之間的介面規則、方式方法，大家就有了共同的工作語言、共同的工作平台，使整個軟體開發工作可以協調有序地進行。
總體結構設計：
功能（加工）－>模塊：每個功能用那些模塊實現，保證每個功能都有相應的模塊來實現；
模塊層次結構：某個角度的軟體框架視圖；
模塊間的調用關系：模塊間的介面的總體描述；
模塊間的介面：傳遞的信息及其結構；
處理方式設計：滿足功能和性能的演算法
用戶界面設計；
數據結構設計：
詳細的數據結構：表、索引、文件；
演算法相關邏輯數據結構及其操作；
上述操作的程序模塊說明（在前台？在後台？用視圖？用過程？······）
介面控製表的數據結構和使用規則
其他性能設計。
四、概要設計寫什麼
結構化軟體設計說明書結構（因篇幅有限和過時嫌疑，在此不作過多解釋）
任務：目標、環境、需求、局限；
總體設計：處理流程、總體結構與模塊、功能與模塊的關系；
介面設計：總體說明外部用戶、軟、硬體介面；內部模塊間介面（註：介面≈系統界面）
數據結構：邏輯結構、物理結構，與程序結構的關系；
模塊設計：每個模塊「做什麼」、簡要說明「怎麼做」（輸入、輸出、處理邏輯、與其它模塊的介面，與其它系統或硬體的介面），處在什麼邏輯位置、物理位置；
運行設計：運行模塊組合、控制、時間；
出錯設計：出錯信息、處錯處理；
其他設計：保密、維護；
OO軟體設計說明書結構
1 概述
系統簡述、軟體設計目標、參考資料、修訂版本記錄
這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。
2 術語表
對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。
3 用例
此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。
4 設計概述
4.1 簡述
這部分要求突出整個設計所採用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶/伺服器結構）以及使用到的相應技術和工具（例如OMT、Rose）
4.2 系統結構設計
這部分要求提供高層系統結構（頂層系統結構、各子系統結構）的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
4.3 系統界面
各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它系統的介面，比如說從其它軟體系統導入/導出數據，必須在此說明。
4.4 約束和假定
描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟體類型以及這樣導致的約束。
實現的語言和平台也會對系統有約束，同樣在此予以說明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。
5 對象模型
提供整個系統的對象模型，如果模型過大，按照可行的標准把它劃分成小塊，例如可以把客戶端和伺服器端的對象模型分開成兩個圖表述。在其中應該包含所有的系統對象。這些對象都是從理解需求後得到的。要明確哪些應該、哪些不應該被放進圖中。所有對象之間的關聯必須被確定並且必須指明聯系的基數。聚合和繼承關系必須清楚地確定下來。每個圖必須附有簡單的說明。
6 對象描述
在這個部分敘述每個對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說明它是個臨時對象（transient object）。
對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的演算法的簡要說明（如果不是特別簡單的話）。如果對變數或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
7 動態模型
這部分的作用是描述系統如何響應各種事件。一般使用順序圖和狀態圖。
確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
7.1 場景（Scenarios）
對每個場景做一則條目，包括以下內容：
場景名：給它一個可以望文生義的名字
場景描述：簡要敘述場景是干什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的相對時間順序。
7.2 狀態圖
這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個對象畫一個狀態圖，但事實上會導致太多不期望的細節信息，只需要確定系統中一些重要的對象並為之提供狀態圖即可。
8 非功能性需求
五、概要設計怎麼做
結構化軟體設計方法：
詳細閱讀需求規格說明書，理解系統建設目標、業務現狀、現有系統、客戶需求的各功能說明；
分析數據流圖，弄清數據流加工的過程；
根據數據流圖決定數據處理問題的類型（變換型、事務型、其他型）；
通過以上分析，推導出系統的初始結構圖；
對初始結構圖進行改進完善：所有的加工都要能對應到相應模塊（模塊的完整性在於他們完成了需求中的所有加工），消除完全相似或局部相似的重復功能（智者察同），理清模塊間的層次、控制關系，減少高扇出結構，隨著深度增大扇入，平衡模塊大小。
由對數據字典的修改補充完善，導出邏輯數據結構，導出每種數據結構上的操作，這些操作應當屬於某個模塊。
確定系統包含哪些應用服務系統、客戶端、資料庫管理系統；
確定每個模塊放在哪個應用伺服器或客戶端的哪個目錄、哪個文件（庫），或是在資料庫內部建立的對象。
對每個篩選後的模塊進行列表說明。
對邏輯數據結構進行列表說明。
根據結構化軟體設計說明書結構對其他需要說明的問題進行補充說明，形成概要設計說明書。
OO軟體設計方法：
在OOA基礎上設計對象與類：在問題領域分析（業務建模和需求分析）之後，開始建立系統構架。
第一步是抽取建立領域的概念模型，在UML中表現為建立對象類圖、活動圖和交互圖。對象類就是從對象中經過「察同」找出某組對象之間的共同特徵而形成類：
對象與類的屬性：數據結構；
對象與類的服務操作：操作的實現演算法；
對象與類的各外部聯系的實現結構；
設計策略：充分利用現有的類；
方法：繼承、復用、演化；
活動圖用於定義工作流，主要說明工作流的5W（Do What、Who Do、When Do、Where Do、Why Do）等問題，交互圖把人員和業務聯系在一起是為了理解交互過程，發現業務工作流中相互交互的各種角色。
第二步是構建完善系統結構：對系統進行分解，將大系統分解為若乾子系統，子系統分解為若干軟體組件，並說明子系統之間的靜態和動態介面，每個子系統可以由用例模型、分析模型、設計模型、測試模型表示。軟體系統結構的兩種方式：層次、塊狀
層次結構：系統、子系統、模塊、組件（同一層之間具有獨立性）；
塊狀結構：相互之間弱耦合
系統的組成部分：
問題論域：業務相關類和對象(OOA的重點)；
人機界面：窗口、菜單、按鈕、命令等等；
數據管理：數據管理方法、邏輯物理結構、操作對象類；
任務管理：任務協調和管理進程；
第三步是利用「4＋1」視圖描述系統架構：用例視圖及劇本；說明體系結構的設計視圖；以模塊形式組成包和層包含概要實現模型的實現視圖；說明進程與線程及其架構、分配和相互交互關系的過程視圖；說明系統在操作平台上的物理節點和其上的任務分配的配置視圖。在RUP中還有可選的數據視圖。
第四步是性能優化（速度、資源、內存）、模型清晰化、簡單化（簡單就是享受）。
六、概要設計的原則
總體原則和方法：由粗到細的原則，互相結合的原則，定性分析和定量分析相結合的方法，分解和協調的方法和模型化方法。
要系統考慮系統的一般性、關聯性、整體性和層次性。
分解協調：目的是為了創造更好的系統。系統分解是指將一個復雜的系統分解為若干個子系統，系統協調一是系統內協調，即根據系統的總結構、總功能、總任務和總目標的要求，使各個子系統之間互相協調配合，在各個子系統局部優化基礎上，通過內部平衡的協調控制，實現系統的整體優化；
屏蔽抽象：從簡單的框架開始，隱含細節；
一致性：統一的規范、統一的標准、統一的文件模式；
每個模塊應當有一個統一命名的容易理解的名字；
編碼：由外向內（界面－>核心）；
面向用戶：概要設計是對於按鈕按下後系統「怎麼做」的簡要說明；
模塊、組件的充分獨立性、封閉性；
同時考慮靜態結構與動態運行；
每個邏輯對象都應當說明其所處物理對象（非一一對應）；
每個物理對象都有合適的開發人員，並且利於分工與組裝。（詳細說明見本人另一篇文章：系統構架設計應考慮的因素）；
確立每個構架視圖的整體結構：視圖的詳細組織結構、元素的分組以及這些主要分組之間的介面；
軟體構架與使用的技術平台密切相關，目前常用的平台有J2EE、.NET、CORBA等等，因此具體的軟體構架人員應當具備使用這些平台的軟體開發經驗；
通過需求功能與設計模塊之間的列表對應，檢查每個需求功能是否都有相應的模塊來實現，保證需求功能的可追溯性和需求實現（模塊）的完整性，同時可以檢查重復和不必要的模塊。
在需求調研分析過程中對業務處理過程了解的完整性和准確性非常重要。調查了解清楚所有的業務流程才能設計出適合各流程業務節點用戶業務特點和習慣的軟體，使開發出來的軟體更受歡迎。當然在進行軟體概要設計時，要盡量排除業務流程的制約，即把流程中的各項業務結點工作作為獨立的對象，設計成獨立的模塊，充分考慮他們與其他各種業務對象模塊的介面，在流程之間通過業務對象模塊的相互調用實現各種業務，這樣，在業務流程發生有限的變化時（每個業務模塊本身的業務邏輯沒有變的情況下），就能夠比較方便地修改系統程序模塊間的調用關系而實現新的需求。如果這種調用關系被設計成存儲在配置庫的數據字典里，則連程序代碼都不用修改，只需修改數據字典里的模塊調用規則即可。
七、概要設計的重要輸出
編碼規范：信息形式、介面規約、命名規則；
物理模型：組件圖、配置圖；
不同角度的構架視圖：用例視圖、邏輯視圖、進程視圖、部署視圖、實施視圖、數據視圖（可選）；
系統總體布局：哪些部分組成、各部分在物理上、邏輯上的相互關系；
兩個不可忽視的輸出：
與需求功能的關系：對於需求中的每一個功能，用哪一層、哪個模塊、哪個類、哪個對象來實現（一對多關系）；反過來，應當說明將要創建的系統每一層、每個模塊、每個對象、每一個類「做什麼」，他們是為了幫助實現哪些功能（一對多關系）。（需求的顆粒度在一開始往往是比較粗的，因此根據功能點對於整體項目規模的估計或得到項目WBS其誤差范圍也是比較大的。更為重要的原因是，需求往往不是編碼工作分解的准確依據，因為一個需求的功能點可能對應多個代碼模塊，而多個需求的功能點也可能只對應一個或少數代碼模塊，同時還有軟體復用等因素要考慮，因此只有在概要設計完成以後才能准確地得到詳細設計或編碼階段的二次 WBS，並估計較為准確的整體項目規模。）
邏輯與物理位置：每個對象在邏輯上分別落在哪一層、哪個模塊、哪個類；在物理上每個模塊、每個對象、每一個類放在哪個應用伺服器或客戶端的哪個目錄、哪個文件（庫），或者是建立在資料庫管理系統中的什麼東東（過程、函數、視圖、觸發器等等）。
八、結構化與面向對象方法特點比較
1. 從概念方面看，結構化軟體是功能的集合，通過模塊以及模塊和模塊之間的分層調用關系實現；面向對象軟體是事物的集合，通過對象以及對象和對象之間的通訊聯系實現；
2. 從構成方面看，結構化軟體＝過程＋數據，以過程為中心；面向對象軟體＝（數據＋相應操作）的封裝，以數據為中心；
3. 從運行控制方面看，結構化軟體採用順序處理方式，由過程驅動控制；面向對象軟體採用互動式、並行處理方式，由消息驅動控制；
4. 從開發方面看，結構化方法的工作重點是設計；面向對象方法的工作重點是分析；但是，在結構化方法中，分析階段和設計階段採用了不相吻合的表達方式，需要把在分析階段採用的具有網路特徵的數據流圖轉換為設計階段採用的具有分層特徵的結構圖，在面向對象方法中則不存在這一問題。
5. 從應用方面看，相對而言，結構化方法更加適合數據類型比較簡單的數值計算和數據統計管理軟體的開發；面向對象方法更加適合大型復雜的人機互動式軟體和數據統計管理軟體的開發；
參考文獻：
《實用軟體工程》第二版，鄭人傑、殷人昆、陶永雷等著
《微軟項目：求生法則》Steve McConnell著，余孟學譯
《軟體工程：實踐者的研究方法》（第5版）Roger S.Pressman著
《軟體構架實踐》SEI軟體工程譯叢，林·巴斯著
《RUP2000》電子版；
《UML與系統分析設計》張龍祥著；
《面向對象的分析與設計》楊正甫著；

㈧ 做軟體項目設計文檔怎麼寫啊

按照以下格式填就好了，不過是我自己寫的，有不好的地方大家互相學習修改一下~

詳細設計文檔規范
1.0概述
這部分提供對整個設計文檔的概述。描述了所有數據，結構，介面和軟體構件級別的設計。
1.1 目標和對象
描述軟體對象的所有目標。
1.2 陳述范圍
軟體描述。主要輸入，過程功能，輸出的描述，不考慮詳細細節。
1.3 軟體內容
軟體被置於商業或者產品線中，討論相關的戰略問題。目的是讓讀者能夠對「宏圖」有所了解。
1.4 主要系統參數
任何商務軟體或者產品線都包含軟體規定、設計、實現和測試的說明和規范。
2.0 數據設計
描述所有數據結構包括內部變數，全局變數和臨時數據結構。
2.1 內部軟體數據結構
描述軟體內部的構件之間的數據傳輸的結構。
2.2 全局數據結構
描述主要部分的數據結構。
2.3 臨時數據結構
為臨時應用而生成的文件的描述。
2.4 資料庫描述
作為應用程序的一部分，描述資料庫結構。
3.0 結構化和構件級別設計
描述程序結構。
3.1 程序結構
詳細描述應用程序所選定的程序結構。
3.1.1 結構圖
圖形化描述結構。
3.1.2 選擇性
討論其它可供考慮的結構。選定3.1.1中結構類型的原因。
3.2 構件描述
詳細描述結構中的每個軟體構件。
3.2.1 構件過程敘述(PSPEC)
描述構件的過程。
3.2.2 構件介面描述
詳細描述構件的輸入和輸出。
3.2.3 構件執行細節
每個構件的詳細演算描述。
3.2.3.1 介面描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 規范/限制
]3.2.3.4 本地數據結構
3.2.3.5 在3.2.3.6設計中包含的執行結果
3.3 軟體介面描述
軟體對外界的介面描述
3.3.1機器對外介面
與其他機器或者設備的介面描述。
3.3.2系統對外介面
對其它系統、產品和網路的介面描述。
3.3.3與人的介面
概述軟體與任何人的界面。
4.0 用戶界面設計
描述軟體的用戶界面設計。
4.1 描述用戶界面
詳細描述用戶界面，包括屏幕顯示圖標、圖片或者類型。
4.1.1 屏幕圖片
從用戶角度描述界面。
4.1.2 對象和操作
所有屏幕對象和操作的定義。
4.2 界面設計規范
用戶界面的設計和實現的規范和標准。
4.3 可見構件
實現的GUI可見構件說明。
4.4 UIDS描述
用戶界面開發系統描述。
5.0約束、限制和系統參數
會影響軟體的規格說明、設計和實現的特殊事件。
6.0測試標准
測試策略和預備測試用例描述。
6.1 測試的類別
規定實施測試的類別，包括盡量詳細的描述。這里是針對黑盒測試現象的描述。
6.2期待軟體反饋
測試期待的結果描述。
6.3執行界線
特殊執行需要的說明。
6.4 重要構件確認
決定性構件或者需要特殊注意的構件的測試確認。
7.0附錄
設計說明的補充信息。
7.1系統可跟蹤矩陣
一個定期回歸系統規格跟蹤軟體需求的矩陣。
7.2 產品戰略
如果規格說明書是為一個產品設計的，描述相關的產品戰略。
7.3 使用分析演算法
描述所有分析活動所使用到的分析演算法。
7.4 補充信息 (如果有需要特別說明的)