尴尬的概要设计文档

一般软件开发可分为如下阶段。

1.需求分析

2.概要设计

3.详细设计

4....

其中概要设计,我觉得起到的作用,就是从需求过度到详细设计阶段的一个中间过程。这种划分方式,不是从软件开发本身的需要出发的,而是按实际的项目过程控制需要划分的。因为不同的项目,需求在理解难度上、抽象程度上,千差万别。因此到达实际的产品功能设计和程序设计(即详细设计),所需要的信息,也差别很大。需求分析阶段侧重于从用户那获取原始需求。而所谓概要设计,就是要把到达详细设计中间缺少的信息补全。

所以,所谓概要设计文档,内容是五花八门的,没有确定性质的内容。有人还在找概要设计的模板,这实在可笑。而后文列举的一些原因将导致概要设计文档内容更加混乱。

注意:GB8567-88概要设计模板是过时的。在概要设计上中国已经超过了IBM、微软、HP等大牛公司,搞出了自己的标准,只是太久不维护了。

这种划分方法,和按软件开发工件内容性质划分的开发阶段,是两种维度。一个是管理角度,一个是软件开发的客观规律的角度。

概要设计文档,有时也作为用户了解系统实现的文档。这时,概要设计的作用就是给用户一个大体的方案介绍。对开发本身来说,只是一个参考。

我觉得这样的阶段性划分,是迎合一般用户理解能力的划分方法。实际编写的概要设计文档,也未必能满足,上文我对概要设计阶段的作用的要求。要么概要设计文档,就是个摆设,常常出现很多辅助文档。要么就是概要设计抢详细设计的活,里边有界面设计,有库表设计等。悲剧的是,有的公司生搬硬套开发过程,要求写概要设计文档。写文档的人,只好把认为有用的内容都向文档里塞。这样的文档体系是混乱的。开发过程也是混乱的。

概要设计文档里的长见内容比较难理解,也比较尴尬。

1.界面设计。这个最麻烦。这时还不到明确详细界面的时候。放的都是拍脑门的界面设计或从别处拷贝来的图片,表达的是需求,界面是不能当真的。可是文档的读者程序员,如何知道是否应该对界面当真呢?这种极其混淆的表达方法,常常让读文档的人不知如何是好。

需求的表达有专业的表示工具,用例。可是会用的太少了。用胡乱的界面表达需求,能传达的有用信息是很少的。

2.实际的界面设计。在抢详细设计的饭碗。

3.库表设计。又在抢详细设计的饭碗。

4.程序流程图。抛开实际代码的流程图,只是帮助梳理程序思路,却不得不明确程序的运行过程,这些脱离实际的过程设计,对于实际的代码编写基本是多余的。在我看来,应该采用靠近代码的设计方法,这样才有实际意义。而这个,是详细设计的内容。

5.架构设计。合理的内容。

6.功能模块设计。合理内容。

...

因此,概要设计阶段,必要时要有,但不必写概要设计文档(用户不要求的情况下),按实际的需要编写工件,才是正确的。这样,拿到的文档才都是有效的。

-------------------

这帖子说的有意思:

http://www.kaixin001.com/repaste/94351869_5296386792.html?uid=94351869&urpid=5296393564

说明了这个领域的模糊和随意性。

--------------------

概要设计相关的内容,在以前应该是正统的方法。(具体没做过考据)

但是,现代的开发方法,迭代式开发是主流方法。但是,开发方法是一个没有统一标准的领域。很多公司,根本就是简单的把任务分配到人头就不管了。开发任务能否做好,是完全不进行管理的。这样的团队,不可能做出好的软件。软件开发不是一件简单的事,找来10个工人,简单的告诉他们,每人负责盖一层楼,是盖不出楼房的。

吃过亏的公司会试图改革,引入一些开发管理。而传统的开发过程的划分,看上去很美(因为简单,好管理等等),实践起来,是另一回事。因此,形式上不得不按大家认可的过程开发,但实践上,却不得不采用迭代式开发方法,这是由需求的不稳定性决定的。

相关推荐