|
|
|
|
|
（1）《软件文档管理指南》GB/T 16680—1996。
|
|
|
|
（2）《计算机软件产品开发文件编制指南》GB/T 8567—1988。
|
|
|
|
（3）《计算机软件需求说明编制指南》GB/T9385—1988。
|
|
|
|
|
|
《软件文档管理指南》GB/T 16680—1996（NEQ ISO/IEC TR 9294—1990）由原国家技术监督局于1996年12月18日发布，1997年7月1日起实施。
|
|
|
|
该标准为那些对软件或基于软件的产品的开发负有职责的管理者提供软件文档的管理指南。该标准的目的在于协助管理者在他们的机构中产生有效的文档。该标准涉及策略、标准、规程、资源和计划，管理者必须关注这些内容，以便有效地管理软件文档。
|
|
|
|
根据该标准，文档是指一种数据媒体和其上所记录的数据。它具有永久性，并可以由人或机器阅读，通常仅用于描述人工可读的内容，例如技术文件、设计文件和版本说明文件。
|
|
|
|
软件文档的作用：管理依据、任务之间联系的凭证、质量保证、培训与参考、软件维护支持、历史档案。
|
|
|
|
软件文档可归入三种类别：开发文档（描述开发过程本身）、产品文档（描述开发过程的产物）、管理文档（记录项目管理的信息）。
|
|
|
|
|
|
文档计划是指一个描述文档编制工作方法的管理用文档。该计划主要描述要编制什么类型的文档，这些文档的内容是什么，何时编写，由谁编写，如何编写，以及什么是影响期望结果的可用资源和外界因素。
|
|
|
|
|
|
|
|
|
|
|
|
（4）提供编制文档所需要的条件，落实文档编写人员、所需经费以及编制工具等。
|
|
|
|
（5）明确保证文档质量的方法，为了确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等。
|
|
|
|
（6）绘制进度表，以图表形式列出在软件生存期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。
|
|
|
|
此外，文档计划规定每个文档要达到的质量等级，以及为达到期望结果必须考虑哪些外部因素。文档计划还确定该计划和文档的分发，并且明确叙述参与文档工作的所有人员的职责。
|
|
|
|
|
|
开发文档是描述软件开发过程，包括软件需求、软件设计、软件测试、保证软件质量的一类文档，开发文档也包括软件的详细技术描述（程序逻辑、程序间相互关系、数据格式和存储等）。开发文档起到如下5种作用：
|
|
|
|
（1）是软件开发过程中包含的所有阶段之间的通信工具，它们记录生成软件需求、设计、编码和测试的详细规定和说明。
|
|
|
|
（2）描述开发小组的职责。通过规定软件、主题事项、文档编制、质量保证人员以及包含在开发过程中任何其他事项的角色来定义做什么、如何做和何时做。
|
|
|
|
（3）用作检验点而允许管理者评定开发进度。如果开发文档丢失、不完整或过时，管理者将失去跟踪和控制软件项目的一个重要工具。
|
|
|
|
（4）形成了维护人员所要求的基本软件文档。这些支持文档可作为产品文档的一部分。
|
|
|
|
|
|
基本的开发文档有可行性研究和项目任务书；需求规格说明；功能规格说明；设计规格说明，包括程序和数据规格说明；开发计划；软件集成和测试计划；质量保证计划、标准、进度；安全和测试信息。
|
|
|
|
|
|
产品文档规定关于软件产品的使用、维护、增强、转换和传输的信息。产品文档起到如下三种作用：
|
|
|
|
（1）为使用和运行软件产品的任何人规定培训和参考信息。
|
|
|
|
|
|
|
|
|
|
（1）用户。他们利用软件输入数据、检索信息和解决问题。
|
|
|
|
|
|
|
|
|
|
（1）用于管理者的指南和资料，他们监督软件的使用。
|
|
|
|
（2）宣传资料。通告软件产品的可用性，并详细说明它的功能、运行环境等。
|
|
|
|
|
|
基本的产品文档有培训手册；参考手册和用户指南；软件支持手册；产品手册和信息广告。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这种文档从管理的角度规定涉及软件生存的信息。相关文档的详细规定和编写格式见GB8567。
|
|
|
|
|
|
文档等级是指所需文档的一个说明，它指出文档的范围、内容、格式及质量，可以根据项目、费用、预期用途、作用范围或其他因素选择文档等级。每个文档的质量必须在文档计划期间就有明确的规定，文档的质量可以按文档的形式和列出的要求划分为4级。
|
|
|
|
（1）最低限度文档（1级文档）：适合开发工作量低于一个人月的开发者自用程序。该文档应包含程序清单、开发记录、测试数据和程序简介。
|
|
|
|
（2）内部文档（2级文档）：可用于在精心研究后被认为似乎没有与其他用户共享资源的专用程序。除1级文档提供的信息外，2级文档还包括程序清单内足够的注释以帮助用户安装和使用程序。
|
|
|
|
（3）工作文档（3级文档）：适合于由同一单位内若干人联合开发的程序，或可被其他单位使用的程序。
|
|
|
|
（4）正式文档（4级文档）：适合那些要正式发行供普遍使用的软件产品。关键性程序或具有重复管理应用性质（如工资计算）的程序需要4级文档。4级文档应遵守GB8567的有关规定。
|
|
|
|
|
|
《计算机软件产品开发文件编制指南》GB/T 8567—1988（FIPS 3864）由原国家标准局于1988年1月7日发布，1988年7月1日起实施。该指南是一份指导性文件。
|
|
|
|
该指南建议在一项计算机软件的开发过程中，一般地说，应该产生14种文件。这14种文件是可行性研究报告、项目开发计划、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、用户手册、操作手册、模块开发卷宗、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
|
|
|
|
|
|
软件生命周期各阶段与软件文档编制工作的关系如下表所示。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在一项软件的开发过程中，随着程序的逐步形成和逐步修改，各种文件也在不断地产生、不断地修改或补充。因此，必须加以周密的控制，以保持文件与程序产品的一致性，保持各种文件之间的一致性和文件的安全性。这种控制表现为：
|
|
|
|
（1）就从事一项软件开发工作的开发集体而言，应设置一位专职的文件管理人员（接口管理工程师或文件管理员）。在开发集体中，应该集中保管本项目现有全部文件的主文本两套，由该文件管理人员负责保管。
|
|
|
|
（2）每一份提交给文件管理人员的文件都必须具有编写人、审核人和批准人的签字。
|
|
|
|
（3）这两套主文本的内容必须完全一致。其中有一套是可供出借的，另一套是绝对不能出借的，以免发生万一。可出借的主文本在出借时必须办理出借手续，归还时办理注销出借手续。
|
|
|
|
（4）开发集体中的工作人员可以根据工作的需要，在本项目的开发过程中持有一些文件，即所谓个人文件，包括为使他完成他承担的任务所需要的文件，以及他在完成任务过程中所编制的文件。但这种个人文件必须是主文本的复制品，必须同主文本完全一致，若要修改，必须首先修改主文本。
|
|
|
|
（5）不同开发人员所拥有的个人文件通常是主文本的各种子集。所谓子集是指把主文本的各个部分根据承担不同任务的人员或部门的工作需要加以复制、组装而成的若干个文件的集合。文件管理人员应该列出一份不同子集的分发对象的清单，按照清单及时把文件分发给有关人员或部门。
|
|
|
|
（6）一份文件如果已经被另一份新的文件所代替，则原文件应该被注销。文件管理人员要随时整理主文本，及时反映出文件的变化和增加情况，及时分发文件。
|
|
|
|
（7）当一个项目的开发工作临近结束时，文件管理人员应逐个收回开发集体内每个成员的个人文件，并检查这些个人文件的内容。经验表明，这些个人文件往往可能比主文本更详细，或同主文本的内容有所不同，必须认真监督有关人员进行修改，使主文本能真正反映实际的开发结果。
|
|
|
|
|
|
《计算机软件需求说明编制指南》GB/T 9385—1988（NEQANSI/IEEE 830—1984）由原国家标准局于1988年6月18日发布，1988年12月1日起实施。
|
|
|
|
该指南详细描述了计算机软件需求说明（Software Requirements Specifications，SRS）应该包含的内容及编写格式。该指南为软件需求实践提供了一个规范化的方法，不提倡把软件需求说明划分成等级，避免把它定义成更小的需求子集。
|
|
|
|
|
|
（1）前言：包括目的、范围、定义、缩写词、略语、参考资料。
|
|
|
|
（2）项目概述：包括产品描述、产品功能、用户特点、一般约束、假设和依据。
|
|
|
|
|
|
|
|
SRS应该具有以下特性：无歧义性、完整性、可验证性、一致性、可修改性、可追踪性（向后追踪、向前追踪）、运行和维护阶段的可使用性。
|
|
|
