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