让设计指导而不是操纵开发

设计文档与代码实现到底如何才能平衡，设计文档到底有多详细才可以进行代码级别的实现？

 

经历过比较正规的大型软件项目，也参与过开发过程简陋到极致的小型软件项目。对文档的要求是完全不同的。

 

小项目因为工期非常紧张，且客户要求也不多，最后只要有可以正常运行的软件系统即可。项目验收也就是一顿酒席罢了，能省则省，别说文档，甚至源代码都不做任何要求。最多要求有一个操作手册，也好给上级领导交差。

 

正规的大型项目则不同了。对文档要求极为严格，在完成系统的试运行后，进行系统项目的验收，就是主要把精力放在文档的处理上了。各类软件工程文档自不必说，还有各种的项目报告，客户独特要求的文档，移交项目内容清单等等，五花八门，种类繁多，在最后验收阶段，全员皆兵，参与到文档的编写修改洪流当中去了。

 

那么在软件项目开发正式开始前，文档的编写到底需要到什么程度，设计文档到底需要详细到什么程度呢。

 

首先需求文档必须有，也就是需求调研过程决不能跳过。正规的软件项目，需求文档必须完整且通过双方的确认，这是软件项目的基石。虽然总是说，客户的需求不会是一成不变的，需要适应变化，但是实际上项目工期、成本的压力，是绝不容许客户在软件项目开发周期内，随意的变更软件需求的。即使有，也得在需求说明的基础上，有限制的改动，前提是决不能变动了整体软件项目需求文档的基础内容。如果出现颠覆性的变化，只能看是前期需求分析人员的失误呢？还是客户在软件项目理解上出现了根本性的失误，再来决定最后项目的走向了。

 

需求文档也是最后项目验收的基准。在最后验收的时候，软件功能到底完成了没有，完成了多少，是否符合用户的业务需要，性能上是否符合要求，都是依据需求文档来的。一旦双方对软件的结果产生的分歧，最终都会以需求文档作为依据。

 

下来就该是设计文档了。设计文档的编写都是依据于需求文档的。很多时候需求分析以及编写人员，和系统设计以及文档编写人员不是一批人，当然如果是一批人是最好的。即使不是，在进行设计的时候，一定要对需求文档认真阅读，对客户的业务认真理解分析，保证得到正确的设计结果。

 

概要设计文档要保证软件子系统的划分、系统组织结构的划分、整体系统数据流、业务过程的设计的正确性，要以软件实现的角度对客户业务过程完整准确的实现。这点是非常重要的。

 

设计文档，先不讨论它的详细程度，更重要的是，好的设计应该是正确的，而不是精确的。

 

就拿我参与过的一个软件项目来说，当时直接参与到软件项目的开发过程中，对项目整体上还没有什么认识，只是简单的对自己负责开发的模块进行了分析理解，就开始编码，倒是也很顺利的完成了编码工作，也完全符合设计文档的要求。

 

但是就在一个基本业务功能子系统完成之后，在客户确认时候，去遭到了客户的否定。认为该业务功能中，数据处理的业务流程，完全不符合客户提出的需求。于是整个的开发完全终止了下来。

 

代码的实现是完全依照设计文档的，那么到底是设计过程出现问题，还是需求分析调研过程出了问题？

 

既然软件开发停止了，大家的精力都放在了系统功能需求设计和分析文档的阅读理解上，来看倒是是设计过程出现了失误，还是需求分析过程中对客户的业务理解就出现了偏差了。

 

一开始看，系统业务数据结构设计基本上没有什么问题，都是照着客户的业务表单来的。主要是业务功能的业务流程出现了问题，无法应用到用户日常业务的处理中。是这样的，用户的业务数据分为几大类，每天各个部门都需要将业务数据上报到上级单位，进行最后的审核与汇总。

 

但是就是这个上报的方式与时间点，出现了问题。在设计的时候，只是简单的将几类业务数据按照下级单位进行归类处理，统一每天进行上报。

 

但是实际上，这些业务数据上报时间点是不一致的。有的是每天上报一次，有的是每小时上报一次，有的是按照三班倒，每班上报一次。

 

这下就问题大了，不仅业务流程设置上需要调整，整体的业务数据结构也无法应对该业务需要，需要非常大的改动。

 

拿设计文档与需求文档来比较，基本上都对应的上，难道是需求分析过程出现了问题，当时没有深入研究，导致对这个业务点没有任何说明？需求文档的重点放在了业务数据内容与组成结构的描述上了。但是在业务功能说明之前，已经比较醒目的说明了各类业务数据上报时间点的不同了。但是设计的时候，完全忽略了这一点，简单粗暴的以一种方式来对待。

 

最终结果自然是设计的失误，只得重新进行数据库的设计，导致已经开发出的软件完全不符合要求，完全丢弃，重新进行开发。导致最后项目的开发周期超期了。

 

现在返回来看那份设计文档，不可谓不详细，不精确，已经详细到具体业务字段，业务流程实现设计，甚至页面的设计布局，但是这么精确的文档，最终导致了项目的返工和延期，就是因为它只是详细精确的，但却不是正确的。

 

设计满足实现即可，不必过于详细。

 

设计文档给予需求文档。客户的需求在整个软件开发过程中谁也保证不会发生变化，所以，需求的变化必然会导致设计的变化，最终导致代码实现的变化。

 

基于以上原因，我们要保证的是需求分析与设计的结果是正确的，就可以了。只要设计文档可以满足开发的要求，就可以进行开发了。最后开发的结果及时反馈客户，以客户的反馈为标杆，进行功能开发的完善变更。毕竟很现实的情况是，开发工期都很紧张，用户急于看到软件的实现结果，没有那么多的时间用来进行详细设计文档的编写，与客户的沟通互动更为重要。

 

如果设计文档非常详细，但是却和最终实现软件代码对不上，那还不如没有。

 

有个取巧的办法，在软件得到确认后，以软件的最终实现结果来完成详细设计文档的编写，这点是用来完成软件项目验收的，实际上对软件的开发实现没有什么大的帮助。