众所周知,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的开展的。
转载于:https://blog.51cto.com/jayenho/95812