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