开发文档怎么编写-android开发文档编写

系统开发文档怎么写,开发内容怎么写

admin09-01 16:1882次浏览

软件开发过程中文档书写处于一个异常尴尬的地位。从理论上，在文档上花费1天的时间，在编码和后续测试维护过程中就可以节约10天的时间。从实践上，文档让大家叫苦不迭。写文档很花时间，写出来有没办法指导开发。

下面就我个人在软件开发过程中的一点心得来谈一谈文档书写的问题。

文档是软件开发思路的映射，都是一个逐渐展开的过程

软件开发的过程，首先要思考做什么，其次要考虑做成什么样子，最后要考虑怎么做。这就是问题定义和可行性分析，软件需求和软件设计三个过程。而这三个过程又都是逐步细化的过程。

文档的书写和软件开发的流程也是相同的，不光有问题定义文档、需求文档和设计文档。这三个文档也要经历一个逐步细化的过程。

问题定义的展开(功能范围定义)

很多人对功能范围定义没有明确概念。功能范围定义是整个项目中非常重要的一个环节。

以我亲身经历的一个面试题为例，大家体会一下功能范围定义的意义：

我一次找工作的时候，我投简历的公司给我发了一个邮件，内容如下：

用C语言实现一个表达式解析函数。要求经过测试，逻辑基本没有问题。三天内完成，把源代码发送回来即可。

我用一天时间完成代码后，提供了一份功能范围说明。

实现一个表达式解析函数。表达式仅包含运算符：小括号“()”，加号“+，减号“-”开发文档怎么编写，乘号“*”，除号“/”，求余“~”；表达式计算规则严格遵守C++对以上运算符的计算顺序和结果。表达式内仅包含整数和小数。(实际内部处理为DOUBLE类型)函数输入为多字节格式的字符串格式。函数只返回最终的运算结果。针对除0，函数会返回错误。不考虑对小数求余的问题。

然后我用了半天时间完成了代码并测试通过。

我为什么要做功能范围说明呢。C++运算符总量为40个左右，还有严格的运算顺序，如果全部实现远不是3天能完成的。如果还要对整个表达式进行全面的分析，标出运算顺序和表达式错误。那就是一个时长达到几个月的小型项目了。

合适的功能范围定义是一个项目成功的关键的第一步。

功能范围定义越详细越好，尽量去掉模棱两可的说明，越是具体详细的功能范围定义，越能减少不必要的精力投入。

事实上，功能范围定义贯穿整个项目，项目定义阶段有项目定义的功能范围，项目需求分析阶段有针对场景的功能范围定义，设计阶段有面对实现的功能范围定义。

需求分析(功能脚本的书写)：

目前我经历的项目，都是有需求文档的。文档做的最差的也有一份功能列表。

很多人在做需求的时候还会用到用例图。大家却忽略了更关键的东西，用例脚本。

在实际的需求分析中，用例脚本才是核心。用例是为脚本服务的，用例的拆分，是为了写出更清晰，更流畅的脚本。

给大家放一个用例脚本的例子：

考虑的场景因素：

1、管理平台掉线。

2、授权过期

3、非法外联检测列表打开失败

4、非法外联检测列表格式错误

5、非法外联检测已经启动。

6、非法外联检测正在启动

7、非法外联检测正在关闭

8、非法外联检测已经关闭

9、非法外联检测正在应用

10、程序在退出

流程：

服务器收到，“应用非法外联策略”的消息。服务器判断当前授权没有过期。开始应用新的非法外联策略。备份当前非法外联检测运行标记。设置非法外联检测运行标记为停止。(后面会再启动)服务器解析从客户端传来的新策略。服务器保存当前策略到文件服务器将当前非法外联列表清空。服务器执行新的策略。恢复当前非法外联检测运行标记。(由步骤4备份)服务器向客户端发送应用非法外联策略成功消息。若当前为网络版，向服务中心发送非法外联策略应用成功消息。（即使发送失败也不需要处理）

2a、若当前授权过期，向客户端发送授权过期消息。然后停止流程。

2a1、向客户端发送，操作失败。失败原因是授权过期。

3a、服务器正在执行应用新的策略的流程(从管理中心下发)

3a1、等待服务器的非法外联检测策略执行完毕，再执行新的检测策略。

注意：非法外联检测测率的应用，以后处理原则为准。

3b、若此时发现正在启动或停止非法外联检测。则等待，启动或停止结束。然后再进行策略应用。

6a、若保存失败，则恢复非法外联检测运行标记。向客户端发送应用策略失败消息。退出流程。

用例英文为case，实际上翻译为场景更形象。它表示了，在使用软件过程中的一个场景。用例脚本就是描述这个场景下，程序如何与人、与其它系统交互的流程。该流程要考虑各种可能，并尽可能细化各种操作。

在实际的软件开发流程中，若要在编码过程中全面考虑各种可能，并做出合适的处理，非常困难。且一旦有处理不合适的地方，修改起来也非常麻烦，并可能引入新的BUG。若是在写脚本的过程中，能把要考虑的东西都考虑清除，在编码的时候仅仅实现其过程，就会大幅降低出错的概率。

文档的连续性

每一份文档都不是凭空产生的，它一定是前一份文档的延续、扩充或细化。保证文档的连续性，可以在软件开发的方方面面大幅提高开发效率。最好以近乎强迫症的态度来保证这一点，从中得到的好处，会比想想的还要多。

命名连续性

命名连续性，这是每个人都知道的，但是很难保证的一点。但一旦做到了，提高的效率的幅度是非常可观的。

一个软件中有很多近似的流程，这些流程的差距往往就是命名上的不同。若整个软件开发过程中，包括文档、注释和代码的命名都是一致的，往往一个宏定义就可以替换大量的代码。

以本人在实际项目中的体会，在这些近似流程的开发上，苛刻到病态的命名一致性，甚至可以提高10倍的开发效率。

内容连续性

整个软件开发流程中的文档和代码都是成体系的。在这个体系中，后一阶段的文档是前一阶段文档的喜欢或扩充。在一定的方法论的支撑下，按部就班的书写文档就会变成一种轻松写意的工作。

要保证后续扩充的每一个部分在前一阶段都能找到出处。这是一个良好的习惯，也是快速提高文档书写能力的办法。这也可以说是书写文档必须的规范。

前一阶段对整个软件的理解和划分，在下一阶段，依然要严格按照对应的顺序，依次扩充和细化。这是保证文档描述的整体结构一直保持一个大致的一致性。

迭代的重要作用

没有什么东西一开始就是完美的。没有什么文档一开始就能写的十全十美，考虑的详细周全。因此迭代才是整个软件开发流程中最重要的东西。

进行后面的文档的书写的时候，发现前一阶段的文档有不妥当的地方，那就修改过来。如果发现有前一阶段没有考虑周全的，需要重新考虑，那么就暂停当前工作，先考虑周全在说。这也是瀑布开发模式和敏捷开发模式不同的地方。瀑布开发模式期望每个阶段的工作都做到尽量完美。而敏捷开发模式开发文档怎么编写，承认人力有时尽，它提供了一个快速纠错的方法，就是迭代。

在整个软件开发流程中，迭代无处不在。本流程内迭代，向前一流程迭代。甚至因为测试的发现的一个问题，一直迭代到需求。