[Document]System Design Document(SDD)

眾所周知，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的開展的。

本文出自“ jayenho ”博客，請務必保留此出處http://jayenho.blog.51cto.com/37194/95812