软件文档
软件文档 文档的作用和分类 软件文档(document)也称文件，通常指的是一些记录的数据 和数据媒体，它具有固定不变的形式，可被人和计算机阅读。它和 计算机程序共同构成了能完成特定功能的计算机软件(有人把源 程序也当作文档的一部分)。我们知道，硬件产品和产品资料在整 个生产过程中都是有形可见的，软件生产则有很大不同，文档本 身就是软件产品。没有文档的软件，不成其为软件，更谈不到软件 产品。软件文档的编制(documentation)在软件开发工作中占有突 出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维 护文档对于转让、变更、修正、扩充和使用文档，对于充分发挥软 件产品的效益有着重要意义。 然而，在实际工作中，文档在编制和使用中存在着许多问 题，有待于解决。软件开发人员中较普遍地存在着对编制文档不感 兴趣的现象。从用户方面看，他们又常常抱怨：文档售价太高、文 档不够完整、文档编写得不好、文档已经陈旧或是文档太多，难于 使用等等。究竟应该怎样要求它，文档应该写哪些，说明什么问 题，起什么作用?这里将给出简要的介绍。 图 文档桥梁作用 文档在软件开发人员、软件管理人员、维护人员、用户以及计 算机之间的多种桥梁作用可从图9．2中看出。软件开发人员在各 个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依 据，这个作用是显而易见的。软件开发过程中软件开发人员需制定 一些工作计划或工作报告，这些计划和报告都要提供给管理人员， 并得到必要的支持。管理人员则可通过这些文档了解软件开发项 目安排、进度、资源使用和成果等。软件开发人员需为用户了解软 件的使用、操作和维护提供详细的资料，我们称此为用户文档。以 上三种文档构成了软件文档的主要部分。我们把这三种文档所包 括的内容列在图6中。其中列举了十三个文档，这里对它们作 一些简要说明： o 可行性研究报告：说明该软件开发项目的实现在技术上、经 济上和社会因素上的可行性，评述为了合理地达到开发目标可供 选择的各种可能实施的方案，说明并论证所选定实施方案的理 由。 o 项目开发计划：为软件项目实施方案制定出具体计划，应 该包括各部分工作的负责人员、开发的进度、开发经费的预算、所 需的硬件及软件资源等。项目开发计划应提供给管理部门，并作 为开发阶段评审的参考。 o 软件需求说明书：也称软件规格说明书，其中对所开发软 件的功能、性能、用户界面及运行环境等作出详细的说明。它是用 户与开发人员双方对软件需求取得共同理解基础上达成的协议， 也是实施开发工作的基础。 o 数据要求说明书：该说明书应给出数据逻辑描述和数据采 集的各项要求，为生成和维护 系统数据文卷作好准备。 o 概要设计说明书：该说 明书是概要设计阶段的工作 成果，它应说明功能分配、模 块划分、程序的总体结构、输 入输出以及接口设计、运行设 计、数据结构设计和出错处理 设计等，为详细设计奠定基 础。 o 详细设计说明书：着重 描述每一模块是怎样实现的， 包括实现算法、逻辑流程等。 o用户手册：本手册详细 描述软件的功能、性能和用户 界面，使用户了解如何使用该软件。 文档 用户文档 用户手册 操作手册 维护修改建议 软件需求（规格）说明书 开发文档 软件需求（规格）说明书 数据要求说明书 概要设计说明书 详细设计说明书 可行性研究报告 项目开发计划 管理文档 项目开发计划 测试计划 测试报告 开发进度月报 开发总结报告 o 图 三种文档 o 操作手册：本手册为操作人员提供该软件各种运行情况的 有关知识，特别是操作方法的具体细节。 o 测试计划：为做好组装测试和确认测试，需为如何组织测试 制定实施计划。计划应包括测试的内容、进度、条件、人员、测试用 例的选取原则、测试结果允许的偏差范围等。 o 测试分析报告：测试工作完成以后，应提交测试计划执行 情况的说明。对测试结果加以分析，并提出测试的结论意见。 o 开发进度月报：该月报系软件人员按月向管理部门提交的 项目进展情况报告。报告应包括进度计划与实际执行情况的比较、 阶段成果、遇到的问题和解决的办法以及下个月的打算等。 o 项目开发总结报告：软件项目开发完成以后，应与项目实 施计划对照，总结实际执行的情况，如进度、成果、资源利用、成本 和投入的人力。此外还需对开发工作作出评价，总结出经验和教 训。 o 维护修改建议，软件产品投入运行以后，发现了需对其进 行修正、更改等问题，应将存在的问题、修改的考虑以及修改的影 响估计作详细的描述，写成维护修改建议，提交审批。 以上这些文档是在软件生存期中，随着各阶段工作的开展适 时编制。其中有的仅反映一个阶段的工作，有的则需跨越多个阶 段。表5给出了各个文档应在软件生存期中哪个阶段编写。这 些文档最终要向软件管理部门，或是向用户回答以下的问题： 表9.2 软件生存期各阶段编制的文档 阶段 文档 可行性药酒与计划 需求分析 设计 代码编写 测试 运行与维护 可行性研究报告 项目开发计划 软件需求说明 数据要求说明 概要设计说明 星系设计说明 测试计划 用户手册 操作手册 测试分析报告 开发进度月报 项目开发总结 维护修改建议 o o 哪些需求要被满足，即回答“做什么?” o 所开发的软件在什么环境中实现以及所需信息从哪里来， 即回答“从何处?” o 某些开发工作的时间如何安排，即回答“何时干?” o 某些开发(或维护)工作打算由“谁来干?” o 某些需求是怎么实现的? o 为什么要进行那些软件开发或维护修改工作? 上述十三个文档都在一定程度上回答了这六个方面的问题。这可从表中看到。 表 文档所回答的问题 所提问题 文档 什么 何处 何时 谁 如何 为何 可行性研究报告 √ √ 项目开发计划 √ √ √ 软件需求说明 √ √ 数据要求说明 √ √ 概要设计说明 √ 详细设计说明 √ 测试计划 √ √ √ 用户手册 √ 操作手册 √ 测试分析报告 √ 开发进度月报 √ √ 项目开发总结 √ 维护修改建议 √ √ √ 至此，我们对文档的作用有了进一步的理解。每一个文档的任 务也是明确的，任何一个文档都此是多余的。 文档的管理和维护 在整个软件生存期中，各种文档作为半成品或是最终成品， 会不断地生成、修改或补充。为了最终得到高质量的产品，达到上 节提出的质量要求，必须加强对文档的管理。以下几个方面是应注意做到的： ①软件开发小组应设一位文档保管人员，负责集中保管本 项目已有文档的两套主文本。两套文本内容完全一致。其中的一套可按一定手续，办理 借阅。 ②软件开发小组的成员可根据工作需要在自己手中保存一些个人文档。这些一般都应是主 文本的复制件，并注意和主文本保持一致，在作必要的修改时，也应先修改主文本。 ③开发人员个人只保存着主文本中与他工作相关的部分文档。 ④在新文档取代了旧文档时，管理人员应及时注销旧文档。 在文档内容有更动时，管理人员应随时修订主文本，使其及时反映更新了的内容。 ⑤项目开发结束时，文档管理人员应收回开发人员的个人文档。发现个人文档与主文本有 差别时，应立即着手解决。这常常是未及时修订主文本造成的。 ⑥在软件开发过程中，可能发现需要修改已完成的文档，特别是规模较大的项目，主文本 的修改必须特别谨慎。修改以前要充分估计修改可能带来的影响，并且要按照：提议、 评议、审核、批准和实施等步骤加以严格的控制。 文档编制的质量要求 为了使软件文档能起到前节所提到的多种桥梁作用，使它有 助于程序员编制程序，有助于管理人员监督和管理软件开发，有助 于用户了解软件的工作和应做的操作，有助于维护人员进行有效 的修改和扩充，文档的编制必须保证一定的质量。质量差的软件文 档不仅使读者难于理解，给使用者造成许多不便，而且会削弱对 软件的管理(管理人员难以确认和评价开发工作的进展)，增高软 件的成本(一些工作可能被迫返工)，甚至造成更加有害的后果(如误操作等)。 造成软件文档质量不高的原因可能是： o缺乏实践经验，缺乏评价文档质量的标准。 o不重视文档编写工作或是对文档编写工作的安排不恰当。 最常见到的情况是，软件开发过程中不能按表5给出的进度， 分阶段及o时完成文档的编制工作，而是在开发工作接近完成时集 中人力和时间专门编写文档。另一方面，和程序工作相比，许多 人对编制文档不感兴趣。于是在程序工作完成以后，不得不应付 一下，把要求提供的文档赶写出来。这样的做法不可能得到高质 量的文档。实际上，要得到真正高质量的文档并不容易，除去应在 认识上对文档工作给予足够的重视外，常常需要经过编写初稿， 听取意见进行修改，甚至要经过重新改写的过程。 高质量的文档应当体现在以下一些方面： ①针对性；文档编制以前应分清读者对象，按不同的类型、不 同层次的读者，决定怎样适应他们的需要。例如，管理文档主要是 面向管理人员的，用户文档主要是面向用户的，这两类文档不应 像开发文档(面向软件开发人员)那样过多地使用软件的专业术语。 ②精确性：文档的行文应当十分确切，不能出现多义性的描 述。同一课题若干文档内容应该协调一致，应是没矛盾的。 ⑧清晰性：文档编写应力求简明，如有可能，配以适当的图 表，以增强其清晰性。 ④完整性：任何一个文档都应当是完整的、独立的，它应自成 体系。例如，前言部分应作一般性介绍，正文给出中心内容，必要 时还有附录，列出参考资料等。同一课题的几个文档之间可能有些 部分相同，这些重复是必要的。例如，同一项目的用户手册和操作 手册中关于本项目功能、性能、实现环境等方面的描述是没有差别 的。特别要避免在文档中出现转引其它文档内容的情况。比如，一 些段落并未具体描述，而用“见××文档××节”的方式，这将给 读者带来许多不便。 ⑤灵活性：各个不同的软件项目，其规模和复杂程度有着许 多实际差别，不能一律看待。图6所列文档是针对中等规模 的软件而言的。对于较小的或比较简单的项目，可做适当调整或合 并。比如，可将用户手册和操作手册合并成用户操作手册；软件需 求说明书可包括对数据的要求，从而去掉数据要求说明书；概要设 计说明书与详细设计说明书合并成软件设计说明书等。 ⑥可追溯性；由于各开发阶段编制的文档与各阶段完成的工 作有着紧密的关系，前后两个阶段生成的文档，随着开发工作的逐 步扩展，具有一定的继承关系。在一个项目各开发阶段之间提供的 文档必定存在着可追溯的关系。例如，某一项软件需求，必定在设 计说明书，测试计划以至用户手册中有所体现。必要时应能做到 跟踪追查。 程序文档合一与动态文档 很多企业已经建立了许多庞大的计算机管理系统，而且将不断地推出新的系统。满足经 营的需求须不断维护、改造计算机系统，但同时又要不影响现行生产，所以必须建立一 整套机制来评价、控制和完成对系统的维护。在软件维护过程中，提出程序与文档合一 的概念在软件开发的同时建立动态文档。 程序与文档合一概念的提出 一、目前软件的状况 　　程序与文档的形式分离，不仅是用各自独立的形式存放，而且使用不同的工具在不 同的时间里书写和检索。维护程序时不能方便地得到文档的帮助，不能同步修改文档。 　　程序与文档的内容分离，由于程序与文档采用不同的描述，既有计算机语言也有自 然语言。维护过程中不能及时、一致地更新文档或程序，使文档不能准确地描述程序而 几乎成为废纸甚至带来负面价值。 　　软件开发与维护的分离，绝大多数软件在设计、开发时不太考虑以后可能的修改， 加大了软件维护的难度，而且使维护容易引入新的错误。 　　这些分离也表现在设计、开发的不同阶段的文档之间的不相容性，例如：需求分析 说明书是纸上的东西，在概要设计阶段不能很好地继承、利用需求分析说明书，设计、 编制概要设计时必须从零开始，需要重新分析、理解需求分析，这种思维上的脱节，不 仅延缓开发进度、加重设计人员的负担，而且由于理解上的不同导致不同阶段描述的对 象有许多不相容情况。这些分离使得文档在系统的设计、开发、维护中的作用下降，这 也是很多软件人员不愿意编写文档的主要原因。 二、程序与文档合一的概念提出 　　怎样才是好的文档系统呢？应当具备以下属性： 　　1. 能够准确地描述软件、...
软件文档