㈠ 開發文檔都有哪些

1標題
軟體系統名稱和標識符
模塊名稱和標識符（如果本卷宗包含多於一個的模塊，則用這組模塊的功能標識代替模塊名）
程序編制員簽名
卷宗的修改文本序號
修改完成日期
卷宗序號（說明本卷宗在整個卷宗中的序號）
編排日期（說明整個卷宗最近的一次編排日期）
2模塊開發情況表
3功能說明
扼要說明本模塊（或本組模塊）的功能，主要是輸入、要求的處理、輸出。可以從系統設計說明書中摘錄。同時列出在軟體需求說明書中對這些功能的說明的章、條、款。
4設計說明
說明本模塊（或本組模塊）的設計考慮，包括：
a． 在系統設計說明書中有關對本模塊（或本組模塊）設計考慮的敘述，包括本模塊在軟體系統中所處的層次，它同其他模塊的介面；
b． 在程序設計說明書中有關對本模塊（或本組模塊）的設計考慮，包括本模塊的演算法、處理流程、牽涉到的數據文卷設計限制、驅動方式和出錯信息等；
c． 在編制目前已通過全部測試的源代碼時實際使用的設計考慮。
5原代碼清單
要給出所產生的本模塊（或本組模塊）的第一份無語法錯的源代碼清單以及已通過全部測試的當前有效的源代碼清單。
6測試說明
說明直接要經過本模塊（或本組模塊）的每一項測試，包括這些測試各自的標識符和編號、進行這些測試的目的、所用的配置和輸入、預期的輸出及實際的輸出。
7復審的結論
把實際測試的結果，同軟體需求說明書、系統設計說明書、程序設計說明書中規定的要求進行比較和給出結論。

㈡ 項目開發是否應該寫具體設計文檔

我知道，我也感受這工具有用，可是此刻的新公司不讓寫了，怎麼辦呢？公司不要求不妨，自己寫好，如不美觀哪天來了個手藝型的上司，一看手下居然還有人堅持寫測試用例，必然另眼相看。寫代碼前把測試用例寫好，寫完功能後，按照測試用例去做單元測試。

㈢ 軟體開發中詳細設計文檔怎麼寫

設計文檔肯定包括功能模塊的簡述，子模塊的功能描述，包括基礎平台描述，資料庫鏈接描述、許可權設計描述等等，需要模板的話請向ITJOB老師索取下。

㈣ 怎麼寫項目開發的文檔

軟體開發中文檔的編寫是一個不可缺少的環節，常見的如《需求分析》、《概要分析》、《資料庫設計》等。在「軟體人」的陣營里向來存在兩種觀點，注重文檔還是關心代碼。

㈤ 要做一個HTML5開發的APP，設計文檔怎麼寫

針對需求來寫了，需求是什麼，就針對什麼來寫，另外，你的設計文檔要符合客戶的要求，比如顏色，規格等，還有設計文檔要寫使用什麼技術，用的什麼版本的js css等這些東西希望能幫助到你

㈥ 如何寫詳細設計文檔

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

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

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

詳細設計文檔規范
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 補充信息 (如果有需要特別說明的)

㈧ 軟體開發中的 概要設計文檔 詳細設計文檔在正常情況下 是不是程序員寫的吧！

一個項目設計是最重要的。其實現在在技術上難題不多。同一個公司你不會肯定有別人會，相互問問就好。最關鍵的是需求理解。所以開發人員自己寫詳細設計是很有好處的。譬如我現在在平安科技。我們的流程時：客戶將需求講解給SA（需求分析師），SA理解之後在召集開發人員一起講解，最後由開發人員自己設計並將設計文稿發出去由負責人及SA評估。 如果沒有問題就會按照詳細設計來開發。 這樣的話雖然設計花費了一定的開發時間，但是在熟悉需求的基礎上開發可謂是：磨刀不誤砍柴工！
望點贊。 謝謝