尴尬的概要设计文档

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

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个工人，简单的告诉他们，每人负责盖一层楼，是盖不出楼房的。

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