结合经验浅谈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的开展的。