另一种视角体验设计文档-概要设计

  在软件项目实施过程中，无疑设计是一个重要的环节。设计的好，能避免更多后面出现的问题。但是现在的项目开发过程中，却存在着以下现象，首先我觉得不能不经调查就说是问题。

第一，              缺少设计，或有的设计文档是从类似的摘抄过来。这样的文档实际指导意义不强，违背了设计文档前期分析，设计，指导的初衷。

第二，              后来补设计文档。那么这种仅仅是为了应付提供软件的交付物。这样的设计如果补的好，和实际的产品比较接近一致。但这样同样无法对产品开发进行指导。

第三，              开发人员与设计人员分离。仅仅是为了应付产品交付或检查。这样做当然有必要性。没有相应的文档，有时候单子拿不到，一切无从谈起。

现象还有很多。比较各种设计边界不清晰，有重复或遗漏的现象。当然也有的项目比较小，完成的比较好。我个人觉得很多因素在于经验。比如你，你以前做过一个类似的项目，现在重新做项目。虽然没有设计文档，但你的头脑中仍然拥有的这种设计经验。但是，如果人员变更，那么同样面临很大的问题。

如何改变这种现象。首先一点，这种现象是否有必要去改变。在这一点上容易出现比较一致的想法。就是应该有前期规范的设计，开发经设计来指导。这样的软件开发的进度，风险管控，软件质量会有很好的帮助。特别是项目规模比较大的时候，更需要这样严格的管理。本人在电信参与的累计近亿的项目。很多时间放在需求和管理方面。真正开发的时间很少，有没有这种必要，在没有新的好的方法之前，谁也不敢放弃这些虽然是过于繁琐的管理过程。

既然很有必要去优化和改变。那么我们就去寻找路。个人对这方面有一些由实际中感触，可以说是比较朦胧的理解。

目的：设计文档应该更好的支撑需求，同时要对实际开发有根本的指导意义。当然设计的不好，导致开发出现的的偏移，这是需要优化设计质量的文档规范的问题。在这过程中，现在的文档是铺天盖地，雷同性太强。所以希望能真正有指导意义，不能忽视一点，简约就是美。简约不代表越少越好，但肯定是不能太臃肿。感觉现在的文章越来越长，质量也越来越来。道德经就是简约的典范。

对象：突出重围，就要把握重点。毛泽东的战术思想，断其十指，不如断其一指，很有启发。那么哪个文档是相对比较重点的呢？当然针对不同的项目实际，答案自然不同。在我所经历的目前的项目中，统一为CRM项目，但是CRM项目太大，里面包含的很多了系统和模块。二期，三期，后来。都是在这个项目上进行扩展。构造子模块，升级模块。如果项目类似于我所说的这种情景。那么我觉得概要设计就是突出的重点。因为总体设计，平台设计几年前大的方向已经做好了，没有大的改变。而详细设计，过于细化，特别是需求难以明确的情况下，不想浪费更多的时间更新，那么很难。而概要设计是指导性，设计的好，至少对架构体系，系统交互，功能模块能能给出良好的边界。也就是大的方向能定下来。在接下来，开发严格按照设计的指导去做，哪怕进步一点，意义也是积极的。

内容：那么接下来概要设计的内容应该包括哪些呢。这是很难有一致的答案。各个公司，都有不同的地方。也许世界的美正在于多样化。我的想法是应该是包含以下几个层面。

前言：

目的，背景，参考等等在此不说了

 0层：系统与外在的平台或其他系统的关系

应该说明开发的系统与平台的关系。当然是指导存在平台。以及系统与其他系统交互的关系。数据同步的策略，简要的说，就是开发的系统与外在的世界之间的关系。

1层：系统的内部结构

  描述本系统的结构，包含功能，模块，类图，接口服务，以及内部的公共组件及中间件等。在此并不想严谨的去描述应该包含具体哪些，但应该是以更符合项目实际来划分，来描述。边界就是本系统

2层：

上面1层描述的是应用本身，通俗的的代码内部的组织形式。在运行在特定的环境中。比如，java程序得运行在jvm上。通常我们的应用还要与数据库进行交互。而数据库则又是独立的产品。有其特有的规范。在这层，我理解需要描述数据库结构，最直接，实际的是，把表关系描述清楚。ER图与数据库结构保持一致。当然如果有必要，也可以先设计CDM,再推导PDM.

其他：

  如果说上面的可以划分为三层的话，当然每一层也可以命名为具体。但我个人总认为，不同的项目实际，很难有一致的名称。在这里从思维的角度用第几层来代指。正如，道可道，非常道。代指，有便于我们更好的扩展，完善。而一个名称，再好的名称只会渐渐的僵化和限制。那么其他包含哪些呢，比如我所使用到的组件视图，运行视图。这方面因项目而异，不同的公司可结合实际来规范。

 

设计文档与其他文档的关系

此内容应该包含在1 层 更合适些。

  1 设计文档中的功能与需求的对应关系

最好在功能清单列表，有单独的模板，比如excel格式，标识所有需求覆盖下的功能点，对相互的关系。维护功能点的状态，类型等。

在这里需要说明一点，我个人认为。应该每个功能点，应该描述其操作，比如新增，修改，复制，导入，导出等。为什么要这样做呢，在此进行描述这些操作，而在详细设计里描述这个操作的内容。保证文档的一致性，在开发完成后，可以开发人员，对照进行比对，防止有遗失的现象。在实际中很有必要，有的开发完成后，发现缺少个导入。或者人为的检查，经常出现责任不明的现象。

 2 设计文档的功能与程序文件的关系

  如果希望做的细一些，每个功能点，对应的文件结构，包，类名。当然这是否更应该是在详细设计里，需要商榷。我的想法，是需要一个附件，维护需求-功能点-程序文件的关系。包括命名规范，目录结构都可以在这里进行优化与规范。这一块，目前还在思考过程，有一点很重要，就是保持文档在整个项目中的唯一性。

  当然还有其他，比较文件组织结构，异常，接口服务等等。这些都可以根据实际的技术体系，项目实情划分到各自的部分进行描述。未来如有需要，我可将优化后的设计文档及关联文件进行细化描述或直接提供附件，以便与大家进行沟通，学习。

   设计是软件项目的一个重要环节。设计文档的规范与可指导性，是软件质量的重要方面。软件以用为本，设计文档同样要以用为指导。在这方面肯定还有许多有争议的地方，但可以肯定的说，这远远胜于没有进行设计，或设计与开发脱节的要好。