結合經驗淺談System Design Document的幾大要素

衆所周知，Design歷來就是一個很見仁見智的東西，Design沒有對與錯，只有好與壞之分，那麼，如何把本身的Design體現出來給Leader（PM？IPS？EA？）知道或者Review呢，一般咱們習慣的作法都是Document下來生成一份SDD，以便指導後續的Designer或者Developer進行實際的開發。

 

那麼一般一份好的SDD裏面應該包含些什麼要素呢？我我的認爲，至少須要包含如下的這些要素（我的看法）

 

1. Executive Summary（可選）

主要介紹這個Design是爲了什麼目的的，能夠簡單說一下這個Project的Background和Purpose。

 

2. Introduction（可選）

說明這份Document的性質，裏面描述的是些什麼東東。

 

3. Architecture Representation（必選）

簡單描述整個Design的Architecture的表現，例如，一般咱們會採用4＋1 View的Model來組織整個Design的Architecture，包括

• Requirement View －－重點，描述software requirements，這裏會包括functional和non-functional的。
• Logical View －－重點中的重點，包括Design中的Object Model，System的分層或者Subsystem的劃分及其之間的依賴關係。
• Process View －－通常描述Design中的同步與併發的狀況。
• Implementation View －－重點，主要描述在整個開發環境中software的靜態組織。
• Deployment View －－重點，主要描述開發完後的software如何和真正的hardware對應起來，顧名思義，就是發佈的結構描述。
• Date View －－通常描述software中的Database的Design，若是有用到DB的話。

這些View Model相當重要的緣由就是在一個開發團隊中，有不一樣的角色，他們能夠根據這份SDD，在整個架構中有針對性的去查找到本身角色所負責的那個Model，各司其職。例如，System engineers能夠僅僅關注logical view，process view和deployment view。Database adminstrators能夠僅僅關注data view。Software Configuration Managers能夠僅僅關注implementation view。而Project Manager也能夠僅僅關注requirement view。

 

4. 各個View Model的展開（必選）

若是說上面Point 3是一個概要描述性的話，如今提到的這一點就是整個Design的命脈所在。這麼說吧，Point 3和Point 4就是一個概要和具體的關係。

 

總而言之，Design雖然沒有對與錯之分，可是SDD是對整個Design的描述，能夠用來指導整個後續開發的進行，若是說SDD是high level design的話，它就是用來指導PS（program specification）這個low level design的開展的。