詳細設計文件

2021-07-02 17:35:39 字數 2388 閱讀 6342



如何寫詳細設計文件是乙個很頭疼的話題,簡單的說是需求文件的昇華,也可以說是開發人員開發程式的依據,當然根據詳細設計文件的粒度進行。好的詳細設計文件是需求人員和開發人員之間的橋梁,不過目前好多程式開發都是先開發後,然後為了應付審核,公司制度,文件規範,開發完成後後續補上該文件。如果這樣的方式,詳細設計文件的的作用就忽略了。

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

那到底應不應該寫詳細設計文件呢,怎麼使詳細設計文件起到他應有的作用呢,下面就讓我們來認識一下詳細設計及寫詳細設計文件的好處和問題。

·概念

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

詳細設計文件的內容包括各個模組的演算法設計,

介面設計,

資料結構設計,互動設計等。必須寫清楚各個模組/介面

/公共物件的定義,列明各個模組程式的

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

·

目的

在開發過程中,由需求及設計不正確、不完整所導致的問題是專案進度拖延、失敗的乙個主要因素,而軟體系統的乙個重要特性就是需求和設計的不斷構建和改進,在寫詳細設計文件過程中,詳細設計實際上是對系統的一次邏輯構建,可以有效驗證需求的完整性及正確性。

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

對於系統功能的調整,後期的維護,詳設文件提供了模組設計上的考慮、決策,包括模組與整體設計的關係、模組所引用的資料庫設計、重要操作的處理流程、重要的業務規則實現設計等等資訊,提供了對模組設計的概述性資訊,闡明了模組設計上的決策,配合**注釋,可以相對輕鬆讀懂原有設計。 ·

問題

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

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

對於這個問題,乙個對策是上邊所提到的,文件只體現設計上的決策,頁面原型所不能反映的資訊,詳細設計只體現總體設計對模組設計的一些考慮,例如對功能的資料庫設計等等,而具體的實現實現,則到**中再去實現,相關的設計也僅體現在**中。

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

·步驟

下面討論如何寫出乙個符合要求、實用的詳細設計文件。

首先是文件的內容,根據專案和團隊的不同,詳細設計文件的內容也有所不同,一般說來,粒度不宜過細,不能代替開發人員的設計和思考,但要把有關設計的決策考慮進去,包括與其他模組、整體設計的關係、操作的處理流程,對業務規則的設計考慮等,有乙個標準為,凡是頁面原型、需求規格說明書所不能反映的設計決策,而開發人員又需要了解的,都要寫入文件。

其次是文件所面向的讀者,主要為模組開發人員、後期維護人員,模組開發人員通過詳細設計文件和頁面原型來了解所開發的功能,後期維護人員通過實際系統、模組**、詳細設計文件來了解乙個功能。

再有就是誰來寫文件,因為文件主要考慮的是設計上的決策,所以寫文件的人應該為負責、參加設計的技術經理、資深程式設計師,根據團隊情況和專案規模、複雜度的不同,也有所不同。

還需要保證文件的可讀性、準確性、一致性,要建立嚴格的文件模板及標準,保證文件的可讀性及準確性,同時建立審核及設計評審制度,來保障設計及文件的質量,另外在工作流程中要強調,要先設計、先寫文件,再進行開發。

詳細設計文件

如上圖,可以看到詳細設計文件是,瀑布模型 中承上啟下的乙個關鍵環節,在做好需求分析和軟體架構之後,寫好詳細設計文件就意味可以進行編碼了。由此,可以看到詳細設計文件有三個作用 1,為具體編碼環節做好鋪墊與設計,從而指導編碼工作 2,提供測試所需文件參考 3,可作為理解編碼的參考文件。詳細設計的主要任務...

需求分析文件 概要設計文件 詳細設計文件

由於專案工作需要 需要提供 軟體需求規格說明書 軟體概要設計說明書 和 軟體詳細設計說明書 所以這裡整理學習一下相關文件需要的內容。文章並不設計對所有需求分析,概要設計和詳細設計的詳細描述。因為這其中的任何一點都可以單獨提取出來成為軟體工程學科中的一本書籍內容。2.1 我們為什麼需要 軟體需求規格說...

詳細設計文件規範

詳細設計說明書 編寫目的 背景定義 列出文件中所用到的專門術語的定義和縮寫詞的原文 用一系列圖表列出本程式系統內的每個程式 包括每個模組和子程式 的名稱 識別符號和它們之間 的層次結構關係。逐個地給出各個層次中的每個程式的設計考慮。以下給出的提綱是針對一般情況的。對於乙個具體的模組,尤其是層次比較低...