软件文档(document)也称文件,通常指的是一些记录的数据
和数据媒体,它具有固定不变的形式,可被人和计算机阅读。它和
计算机程序共同构成了能完成特定功能的计算机软件(有人把源
程序也当作文档的一部分)。我们知道,硬件产品和产品资料在整
个生产过程中都是有形可见的,软件生产则有很大不同,文档本
身就是软件产品。没有文档的软件,不成其为软件,更谈不到软件
产品。软件文档的编制(documentation)在软件开发工作中占有突
出的地位和相当的工作量。高效率、高质量地开发、分发、管理和维
护文档对于转让、变更、修正、扩充和使用文档,对于充分发挥软
件产品的效益有着重要意义。
然而,在实际工作中,文档在编制和使用中存在着许多问
题,有待于解决。软件开发人员中较普遍地存在着对编制文档不感
兴趣的现象。从用户方面看,他们又常常抱怨:文档售价太高、文
档不够完整、文档编写得不好、文档已经陈旧或是文档太多,难于
使用等等。究竟应该怎样要求它,文档应该写哪些,说明什么问
题,起什么作用?这里将给出简要的介绍。
文档在软件开发人员、软件管理人员、维护人员、用户以及计
算机之间的多种桥梁作用可从图9.2中看出。软件开发人员在各
个阶段中以文档作为前阶段工作成果的体现和后阶段工作的依
据,这个作用是显而易见的。软件开发过程中软件开发人员需制定
一些工作计划或工作报告,这些计划和报告都要提供给管理人员,
并得到必要的支持。管理人员则可通过这些文档了解软件开发项
目安排、进度、资源使用和成果等。软件开发人员需为用户了解软
件的使用、操作和维护提供详细的资料,我们称此为用户文档。以
上三种文档构成了软件文档的主要部分。我们把这三种文档所包
括的内容列在图6中。其中列举了十三个文档,这里对它们作
一些简要说明:
· 可行性研究报告:说明该软件开发项目的实现在技术上、经
济上和社会因素上的可行性,评述为了合理地达到开发目标可供
选择的各种可能实施的方案,说明并论证所选定实施方案的理
由。 · 项目开发计划:为软件项目实施方案制定出具体计划,应
该包括各部分工作的负责人员、开发的进度、开发经费的预算、所
需的硬件及软件资源等。项目开发计划应提供给管理部门,并作
为开发阶段评审的参考。 · 软件需求说明书:也称软件规格说明书,其中对所开发软
件的功能、性能、用户界面及运行环境等作出详细的说明。它是用
户与开发人员双方对软件需求取得共同理解基础上达成的协议,
也是实施开发工作的基础。 · 数据要求说明书:该说明书应给出数据逻辑描述和数据采
集的各项要求,为生成和维护
系统数据文卷作好准备。 · 概要设计说明书:该说
明书是概要设计阶段的工作
成果,它应说明功能分配、模
块划分、程序的总体结构、输
入输出以及接口设计、运行设
计、数据结构设计和出错处理
设计等,为详细设计奠定基
础。 · 详细设计说明书:着重
描述每一模块是怎样实现的,
包括实现算法、逻辑流程等。 ·用户手册:本手册详细
描述软件的功能、性能和用户
界面,使用户了解如何使用该软件。 文档
| file:///C:/DOCUME~1/QiuMin/LOCALS~1/Temp/msohtmlclip1/01/clip_image002.gif
| 用户文档
| file:///C:/DOCUME~1/QiuMin/LOCALS~1/Temp/msohtmlclip1/01/clip_image003.gif
| 用户手册
| 操作手册
| 维护修改建议
| 软件需求(规格)说明书
| 开发文档
| file:///C:/DOCUME~1/QiuMin/LOCALS~1/Temp/msohtmlclip1/01/clip_image004.gif
| 软件需求(规格)说明书
| 数据要求说明书
| 概要设计说明书
| 详细设计说明书
| 可行性研究报告
| 项目开发计划
| 管理文档
| file:///C:/DOCUME~1/QiuMin/LOCALS~1/Temp/msohtmlclip1/01/clip_image005.gif
| 项目开发计划
| 测试计划
| 测试报告
| 开发进度月报
| 开发总结报告
|
·
图
三种文档 · 操作手册:本手册为操作人员提供该软件各种运行情况的
有关知识,特别是操作方法的具体细节。 · 测试计划:为做好组装测试和确认测试,需为如何组织测试
制定实施计划。计划应包括测试的内容、进度、条件、人员、测试用
例的选取原则、测试结果允许的偏差范围等。 · 测试分析报告:测试工作完成以后,应提交测试计划执行
情况的说明。对测试结果加以分析,并提出测试的结论意见。 · 开发进度月报:该月报系软件人员按月向管理部门提交的
项目进展情况报告。报告应包括进度计划与实际执行情况的比较、
阶段成果、遇到的问题和解决的办法以及下个月的打算等。 · 项目开发总结报告:软件项目开发完成以后,应与项目实
施计划对照,总结实际执行的情况,如进度、成果、资源利用、成本
和投入的人力。此外还需对开发工作作出评价,总结出经验和教
训。 · 维护修改建议,软件产品投入运行以后,发现了需对其进
行修正、更改等问题,应将存在的问题、修改的考虑以及修改的影
响估计作详细的描述,写成维护修改建议,提交审批。
以上这些文档是在软件生存期中,随着各阶段工作的开展适
时编制。其中有的仅反映一个阶段的工作,有的则需跨越多个阶
段。表5给出了各个文档应在软件生存期中哪个阶段编写。这
些文档最终要向软件管理部门,或是向用户回答以下的问题:
表9.2 软件生存期各阶段编制的文档
阶段 文档
| 可行性药酒与计划
| 需求分析
| 设计
| 代码编写
| 测试
| 运行与维护
| 可行性研究报告
|
|
|
|
|
|
| 项目开发计划
|
|
|
|
|
|
| 软件需求说明
|
|
|
|
|
|
| 数据要求说明
|
|
|
|
|
|
| 概要设计说明
|
|
|
|
|
|
| 星系设计说明
|
|
|
|
|
|
| 测试计划
|
|
|
|
|
|
| 用户手册
|
|
|
|
|
|
| 操作手册
|
|
|
|
|
|
| 测试分析报告
|
|
|
|
|
|
| 开发进度月报
|
|
|
|
|
|
| 项目开发总结
|
|
|
|
|
|
| 维护修改建议
|
|
|
|
|
|
|
· · 哪些需求要被满足,即回答“做什么?” · 所开发的软件在什么环境中实现以及所需信息从哪里来,
即回答“从何处?” · 某些开发工作的时间如何安排,即回答“何时干?” · 某些开发(或维护)工作打算由“谁来干?” · 某些需求是怎么实现的? · 为什么要进行那些软件开发或维护修改工作?
上述十三个文档都在一定程度上回答了这六个方面的问题。这可从表中看到。
表
文档所回答的问题
所提问题
文档
| 什么
| 何处
| 何时
| 谁
| 如何
| 为何
| 可行性研究报告
| √
|
|
|
|
| √
| 项目开发计划
| √
|
| √
| √
|
|
| 软件需求说明
| √
| √
|
|
|
|
| 数据要求说明
| √
| √
|
|
|
|
| 概要设计说明
|
|
|
|
| √
|
| 详细设计说明
|
|
|
|
| √
|
| 测试计划
|
|
| √
| √
| √
|
| 用户手册
|
|
|
|
| √
|
| 操作手册
|
|
|
|
| √
|
| 测试分析报告
| √
|
|
|
|
|
| 开发进度月报
| √
|
| √
|
|
|
| 项目开发总结
| √
|
|
|
|
|
| 维护修改建议
| √
|
|
| √
|
| √
|
至此,我们对文档的作用有了进一步的理解。每一个文档的任
务也是明确的,任何一个文档都此是多余的。
|