總體設計文檔

① 建築設計院出一個「總體設計文本」，什麼是總體設計

總體設來計在我國工程源建設中往往也是設計的一個階段。在很多行業設計中就要求做總體設計。總體設計一般來說就是設計工作的項目比較大，對整個設計方案的的統一規劃、統一規定等等，
包括基本的設計方案及各個專項設計的統一要求等。總體設計也可以和方案設計合並來做，總體設計結束後，就是初步設計（也可以叫做基礎設計），最後是施工圖設計（也可以叫詳細設計）。

② 請問計算機中，概要設計說明書是總體設計階段產生的文檔還是概要設計階段產生的文檔希望詳細解釋下。

軟總體設計階段

③ 概要設計說明書和總體設計說明書的區別

我的理解是，總體設計僅僅描述了產品的形態，如果是網路軟體，可以描述產品以其他子系統在網路中的部署方式、聯系方式。總體設計需要把產品所有可能出現的產品形態列出，這樣可以方便非技術人員(市場、客戶)了解這個產品的功能。
概要設計則是針對一個產品做出稍微詳細的分析，需求提供相關介面、模塊劃分、數據存儲方式等。

我也是最近在做設計才了解的，以上僅是個人理解.

④ 在軟體工程學中總體設計階段提交的文檔叫什麼

如果有需要我可以發給你這些是軟體開發的時候需要的全套文檔

⑤ 編寫文檔的主要工作階段是（ ） A.需求分析 B.總體設計 C.實現 D.測試

這題目多選吧,要不就是腦殘了.....
各個階段文檔都不可少
需求分析階段的需求規格說明書迴文檔,UI設計說答明書文檔等
總體設計階段的概要設計文檔,詳細設計文檔等
實現的時候稍微少一點,但是有的地方是一定要求模塊實現文檔和單元測試文檔的
測試的時候有測試用例,測試報告文檔之類的,少了哪個都不行

⑥ 如何寫詳細設計文檔

在大多數軟體項目中，要末不作詳細設計，要麼開發完成後再補詳細設計文檔，質量也不容樂觀，文檔與系統往往不能同步，使詳細設計文檔完全流於形式，對工作沒有起到實際的幫助。
·
詳細設計是相對概要設計而言的，是瀑布開發流程的一個重要環節，在概要設計的高層設計的基礎上，從邏輯上實現了每一模塊的功能，是編碼階段的主要參考資料，是從高層到低層、逐步精化思想的具體實現。
詳細設計文檔的內容包括各個模塊的演算法設計，
介面設計，
數據結構設計，交互設計等。必須寫清楚各個模塊/介面/公共對象的定義，列明各個模塊程序的
各種執行條件與期望的運行效果，還要正確處理各種可能的異常。
·
在開發過程中，由需求及設計不正確、不完整所導致的問題是項目進度拖延、失敗的一個主要因素，而軟體系統的一個重要特性就是需求和設計的不斷構建和改進，在寫詳細設計文檔過程中，
詳細設計實際上是對系統的一次邏輯構建，可以有效驗證需求的完整性及正確性。
如果不寫詳細設計文檔，一般就從概設直接進入編碼階段，這時開發人員所能參考的資料就是需求規格說明書及頁面原型、資料庫設計等，不能直接進行開發，需要進行信息的溝通，把頁面原型不能體現的設計講清楚，這樣既容易遺忘，也容易發生問題，詳細設計文檔可以作為需求人員、總體設計人員與開發人員的溝通工具，把靜態頁面無法體現的設計體現出來，包含整體設計對模塊設計的規范，體現對設計上的一些決策，例如選用的演算法，對一些關鍵問題的設計考慮等等，使開發人員能快速進入開發，提高溝通效率，減少溝通問題。
對於系統功能的調整，後期的維護，詳設文檔提供了模塊設計上的考慮、決策，包括模塊與整體設計的關系、模塊所引用的資料庫設計、重要操作的處理流程、重要的業務規則實現設計等等信息，提供了對模塊設計的概述性信息，闡明了模塊設計上的決策，配合代碼注釋，可以相對輕松讀懂原有設計。
·存在的問題要由專門的人寫，是比較麻煩的，也是很需要時間的，會對進度造成壓力，也容易形成工作瓶頸，使設計人員負擔過重，而開發人員無事可作。對於現在一般的以資料庫為中心的管理系統而言，這個工作始終是要作的，區別只不過是不是形成專門文檔，形成文檔可能會多花一兩周時間，但相對於規避的風險和問題來說，也是值得的，另外由於現在高級語言的流行，所以更詳細的設計應該直接體現在代碼的設計上，而文檔則只體現設計上的一些決策，協調整體設計與模塊設計的關系，把頁面原型所不能體現的設計情況文檔化，所以所花費的時間是有限的。
設計內容容易過細，但設計階段是不能考慮特別清楚地，時間也不允許。
對於這個問題，一個對策是上邊所提到的，文檔只體現設計上的決策，頁面原型所不能反映的信息，詳細設計只體現總體設計對模塊設計的一些考慮，例如對功能的資料庫設計等等，而具體的實現實現，則到代碼中再去實現，相關的設計也僅體現在代碼中。
需求、設計需要不斷的被更新、構建，則設計文檔需要不斷的重新調整，文檔的維護需要跟上，否則文檔和系統的同步就很難得到保障了，且造成多餘的工作量。文檔的內容易流於形勢，質量糟糕，不能成為開發人員的參考手冊，一是要建立起相關制度，如有修改，先改文檔，後作開發，從工作流程上切實保障文檔與系統的同步，二是要規範文檔質量，對文檔該寫什麼，不該寫什麼，標準是什麼，粒度是什麼，語法應該如何組織，有明確的標准和考慮，同時，建立審計文檔評審、審核制度，充分保障系統的使用。·
首先是文檔的內容，根據項目和團隊的不同，詳細設計文檔的內容也有所不同，一般說來，粒度不宜過細，不能代替開發人員的設計和思考，但要把有關設計的決策考慮進去，包括與其他模塊、整體設計的關系、操作的處理流程，對業務規則的設計考慮等，有一個標准為，凡是頁面原型、需求規格說明書所不能反映的設計決策，而開發人員又需要了解的，都要寫入文檔。
其次是文檔所面向的讀者，主要為模塊開發人員、後期維護人員，模塊開發人員通過詳細設計文檔和頁面原型來了解所開發的功能，後期維護人員通過實際系統、模塊代碼、詳細設計文檔來了解一個功能。
再有就是誰來寫文檔，因為文檔主要考慮的是設計上的決策，所以寫文檔的人應該為負責、參加設計的技術經理、資深程序員，根據團隊情況和項目規模、復雜度的不同，也有所不同。
還需要保證文檔的可讀性、准確性、一致性，要建立嚴格的文檔模板及標准，保證文檔的可讀性及准確性，同時建立審核及設計評審制度，來保障設計及文檔的質量，另外在工作流程中要強調，要先設計、先寫文檔，再進行開發。