什麼是軟件詳細設計?

General 更新 2024-11-19

軟件詳細設計包含哪些內容？？

目錄1基本內容基本內容詳細設計　　詳細設計的主要任務是設計每個模塊的實現算法、所需的局部數據結構。詳細設計的目標有兩個：實現模塊功能的算法要邏輯上正確和算法描述要簡明易懂。　　主要任務：　　1．為每個模塊確定採用的算法，選擇某種適當的工具表達算法的過程，寫出模塊的詳細過程性描述；　　2．確定每一模塊使用的數據結構；　　3．確定模塊接口的細節，包括對系統外部的接口和用戶界面，對系統內部模塊的接口，以及模塊輸入數據、輸出數據及局部數據的全部細節。　　在詳細設計結束時，應該把上述結果寫入詳細設計說明書，並且通過複審形成正式文檔。交付給下一階段（編碼階段）的工作依據。　　4．要為每一個模塊設計出一組測試用例，以便在編碼階段對模塊代碼（即程序）進行預定的測試，模塊的測試用例是軟件測試計劃的重要組成部分，通常應包括輸入數據，期望輸出等內容。　　詳細設計的工具：　　1．圖形工具　　利用圖形工具可以把過程的細節用圖形描述出來。　　2．表格工具　　可以用一張表來描述過程的細節，在這張表中列出了各種可能的操作和相應的條件。　　用某種高級語言（稱之為偽碼）來描述過程的細節。

如何撰寫軟件詳細設計內容

首先確定詳細設計說明書的 “詳細” 是到什麼程度，如該項目我決定為每個頁面都寫說明書，也就是挑選出需要描述的對象。 1.系統包含相當多的頁面，為了方便觀看，以系統模塊為小組將文檔分成了不同的小組，確立大的框架 2.考慮每個頁面要描述的內容，要求重點是“詳細描述頁面之間的關聯” 。描述各個部分：程序描述、功能、關聯關係、邏輯流程。即重點是“關聯關係” 3.程序描述：描述頁面功能；功能：列出頁面所提供的功能 4.關聯關係：如頁面 A 和頁面 B 有關聯，個人理解是重點描述“頁面 A 中哪些參數的改變會對頁面 B 產生影響”以及“產生什麼樣的影響” 。具體只是將參數列出，並未列出參數值。首先展現頁面中的元素，3 列表格：左邊列出用到的數據庫中的表、中間列出關鍵的字段必須包含參數、右邊列出受該頁面影響的其它頁面。因為關係包含兩部分：①頁面自身元素之間的關係（各種計算等）；②該頁面元素改變會影響到其它頁面的關係。第①種關係利用語言加上簡單的公式描述即可；第②種關係則要側重於利用“參數”來說明該參數的改變會對其它頁面產生什麼影響。 5.流程邏輯：是為了使人一眼就能看出頁面之間的關係，要突出重點。畫的略為詳細：開始→即打開了頁面，頁面上的所有元素信息均是從數據庫中調取的，有所體現→用戶操作，判斷用戶操作是否規範→信息保存到數據庫相應字段中，根據哪些字段保存。附：頁面中所有的元素信息都是從數據庫中獲取的，所以只要數據庫中的信息改變，頁面就會受到影響，所以我們把信息是根據什麼字段存儲到數據庫中去的描述清楚即可。

在軟件設計中，可應用於詳細設計的工具有哪些

計算機軟件總體分為系統軟件和應用軟件兩大類：

系統軟件是各類操作系統，如windows、Linux、UNIX等，還包括操作系統的補丁程序及硬件驅動程序，都是系統軟件類。

應用軟件可以細分的種類就更多了，如工具軟件、遊戲軟件、管理軟件等都屬於應用軟件類。

系統軟件：

系統軟件是負責管理計算機系統中各種獨立的硬件，使得它們可以協調工作。系統軟件使得計算機使用者和其他軟件將計算機當作一個整體而不需要顧及到底層每個硬件是如何工作的。

一般來講，系統軟件包括操作系統和一系列基本的工具（比如編譯器，數據庫管理，存儲器格式化，文件系統管理，用戶身份驗證，驅動管理，網絡連接等方面的工具）。

具體包括以下四類：

1.各種服務性程序，如診斷程序、排錯程序、練習程序等；

2.語言程序，如彙編程序、編譯程序、解釋程序；

3.操作系統；

4.數據庫管理系統。

應用軟件

應用軟件是為了某種特定的用途而被開發的軟件。它可以是一個特定的程序，比如一個圖像瀏覽器。也可以是一組功能聯繫緊密，可以互相協作的程序的集合，比如微軟的Office軟件。也可以是一個由眾多獨立程序組成的龐大的軟件系統，比如數據庫管理系統。

較常見的有：

文字處理軟件如WPS、Word等

信息管理軟件

輔助設計軟件如AutoCAD

實時控制軟件如極域電子教室等

教育與娛樂軟件

軟件開發是根據用戶要求建造出軟件系統或者系統中的軟件部分的過程。軟件開發是一項包括需求捕捉，需求分析，設計，實現和測試的系統工程。

軟件一般是用某種程序設計語言來實現的。通常採用軟件開發工具可以進行開發。

不同的軟件一般都有對應的軟件許可，軟件的使用者必須在同意所使用軟件的許可證的情況下才能夠合法的使用軟件。從另一方面來講，某種特定軟件的許可條款也不能夠與法律相抵觸。

詳細設計的常用工具

（1）程序流程圖。程序流程圖又稱為程序框圖，是使用最廣泛然而也是用得最混亂的一種描述程序邏輯結構的工具。它用方框表示一個處理步驟，菱形表示一個邏輯條件，箭頭表示控制流向。其優點是：結構清晰，易於理解，易於修改。缺點是：只能描述執行過程而不能描述有關的數據。（2）盒圖。盒圖是一種強制使用結構化構造的圖示工具，也稱為方框圖。其具有以下特點：功能域明確、不可能任意轉移控制、很容易確定局部和全局數據的作用域、很容易表示嵌套關係及模板的層次關係。（3）PAD圖。PAD是一種改進的圖形描述方式，可以用來取代程序流程圖，比程序流程圖更直觀，結構更清晰。最大的優點是能夠反映和描述自頂向下的歷史和過程。PAD提供了5種基本控制結構的圖示，並允許遞歸使用。PAD的特點有：使用PAD符號設計出的程序代碼是結構化程序代碼；PAD所描繪的程序結構十分清晰；用PAD圖表現程序的邏輯易讀、易懂和易記；容易將PAD圖轉換成高級語言源程序自動完成；即可以表示邏輯，也可用來描繪數據結構；支持自頂向下方法的使用。（4）PDL。PDL也可稱為偽碼或結構化語言，它用於描述模塊內部的具體算法，以便開發人員之間比較精確地進行交流。語法是開放式的，其外層語法是確定的，而內層語法則不確定。外層語法描述控制結構，它用類似於一般編程語言控制結構的關鍵字表示，所以是確定的。內層語法描述具體操作，考慮到不同軟件系統的實際操作種類繁多，內層語法因而不確定，它可以按系統的具體情況和不同的設計層次靈活選用，實際上任意英語語句都可用來描述所需的具體操作。用它來描述詳細設計，工作量比畫圖小，又比較容易轉換為真正的代碼。PDL的優點：可以作為註釋直接插在源程序中；可以使用普通的文本編輯工具或文字處理工具產生和管理；已經有自動處理程序存在，而且可以自動由PDL生成程序代碼。PDL的不足：不如圖形工具形象直觀，描述複雜的條件組合與動作間對應關係時，不如判定樹清晰簡單。

軟件詳細設計的目標和任務是什麼?

一般來說，詳細設計是在需求定下來之後，代碼開發之前。

從順序也能看出來，是承上（需求）啟下（開發）的一步。

簡單來說，目標就是：根據需求，把代碼開發階段需要的東西，全部想好。

比如：需求是做一個新浪博客

需要定義web站閥的域名是形式，怎麼解析，有哪些頁面，每個頁面的訪問方式（post、get）、數據如何緩存，這麼大的訪問量怎麼滿足？系統分幾層？每層做什麼？用什麼數據庫？用戶軌跡記錄在哪裡？系統主要的類怎麼交互，數據庫結構（ER圖）等等

可以參考下網上的詳設模板，就知道需要定義哪些東西，但是很多情況下，會根據實際情況增加、減少內容。

你說的任務我沒太明白，我認為只要詳設的產物拿給開發人員，他能明白怎麼寫代碼就算任務完成了，並沒有特定的標準。如果一定要標準，還是參考模板吧。

以上是我的個人見解，供參考

軟件工程中概要設計和詳細設計有什麼區別

在軟件的總體設計中，完成了數據和系統結構的設計。已將系統劃分成為多個模塊，並將它們按照一定的原則組裝起來，也確定了每個模塊的功能及模塊與模塊之間的外部接口。在理想情況下，詳細設計是軟件設計的第二階段。在這個極端，由於開發系統內外的人員理論上都使用一種自然語言，因此設計說明最好是用自然語言。很清楚，這個階段必須定義過程的細節。

軟件建設方案和軟件詳細設計說明書一樣嗎?

肯定不一樣。建設方案是從宏觀上說明客戶的問題怎麼解決，軟件詳細設計說明書從微觀上說明，包括有那些對象，對象有那些公有方法等都要說明。

詳細設計的方法

傳統軟件開發方法的詳細設計主要是用結構化程序設計法。詳細設計的表示工具有圖形工具和語言工具。圖形工具有業務流圖、程序流程圖、PAD圖（Problem Analysis Diagram）、NS流程圖（由 Nassi和 Shneidermen開發，簡稱 NS）。語言工具有偽碼和PDL（Program Design Language）等。

概要設計與詳細設計有什麼區別

怎麼寫界面軟件的詳細設計文檔

在大多數軟件項目中，要末不作詳細設計，要麼開發完成後再補詳細設計文檔，質量也不容樂觀，文檔與系統往往不能同步，使詳細設計文檔完全流於形式，對工作沒有起到實際的幫助。

詳細設計是相對概要設計而言的，是瀑布開發流程的一個重要環節，在概要設計的高層設計的基礎上，從邏輯上實現了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現。

詳細設計文檔的內容包括各個模塊的算法設計，

接口設計，

數據結構設計，交互設計等。必須寫清楚各個模塊/接口/公共對象的定義，列明各個模塊程序的

各種執行條件與期望的運行效果，還要正確處理各種可能的異常。

在開發過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟件系統的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，

詳細設計實際上是對系統的一次邏輯構建，可以有效驗證需求的完整性及正確性。

如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發人員所能參考的資料就是需求規格說明書及頁面原型、數據庫設計等，不能直接進行開發，需要進行信息的溝通，把頁面原型不能體現的設計講清楚，這樣既容易遺忘，也容易發生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發人員的溝通工具，把靜態頁面無法體現的設計體現出來，包含整體設計對模塊設計的規範，體現對設計上的一些決策，例如選用的算法，對一些關鍵問題的設計考慮等等，使開發人員能快速進入開發，提高溝通效率，減少溝通問題。

對於系統功能的調整，後期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關係、模塊所引用的數據庫設計、重要操作的處理流程、重要的業務規則實現設計等等信息，提供了對模塊設計的概述性信息，闡明瞭模塊設計上的決策，配合代碼註釋，可以相對輕鬆讀懂原有設計。

·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發人員無事可作。對於現在一般的以數據庫為中心的管理系統而言，這個工作始終是要作的，區別只不過是不是形成專門文檔，形成文檔可能會多花一兩週時間，但相對於規避的風險和問題來說，也是值得的，另外由於現在高級語言的流行，所以更詳細的設計應該直接體現在代碼的設計上，而文檔則只體現設計上的一些決策，協調整體設計與模塊設計的關係，把頁面原型所不能體現的設計情況文檔化，所以所花費的時間是有限的。

設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。

對於這個問題，一個對策是上邊所提到的，文檔只體現設計上的決策，頁面原型所不能反映的信息，詳細設計只體現總體設計對模塊設計的一些考慮，例如對功能的數據庫設計等等，而具體的實現實現，則到代碼中再去實現，相關的設計也僅體現在代碼中。

需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統的同步就很難得到保障了，且造成多餘的工作量。文檔的內容易流於形勢，質量糟糕，不能成為開發人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，後作開發，從工作流程上切實保障文檔與系統的同步，二是要規範文檔質量，對文檔該寫什麼，不該寫什麼，標準是什麼，粒度是什麼，語法應該如何組織，有明確的標準和考慮，同時，建立審計文檔評審、審核制度，充分保障系統的使用。·