GB/T8567-2006 IDD 接口设计说明(Interface Design Description) IRS 接口（软件）需求规格说明(Interface Requirement Specification)) IV&.V 独立验证和确认(Independent verification and validation) OCD 运行概念说明(Operation Conception Description) PDSR 项目开发总结报告(Project Development summary Report). SCCB 软件配置控制委员会(Software Configuration Control Board) SCM 软件配置管理(Software Configuration Manager). SCMP 软件配置管理计划(Software Configuration Manager Plan) SDD 软件（结构）设计说明(Software Design Description) SDF 软件开发文件(Software Development File) SFDD 软件开发文档(Software Development Document) SDL 软件开发库(Software Development Library) SDP 软件开发计划(Software Development Plan) SIP 软件安装计划(Software Installation Plan) SPS 软件产品规格说明(Software Product Specification) SQA 软件质量保证(Software Quality Assure). SQAP 软件质量保证计划(Software Quality Assure Plan) SRS 软件需求规格说明(Software Requirement Specification) SSDD 系统/子系统设计（结构设计）说明(System Subsystem Design Description) SSS 系统/子系统需求规格说明(System Subsystem Requirement Specification) STD 软件测试说明(Software Testing Descrition) STP 软件测试计划(Software Testing Plan) STR 软件测试报告(Software Testing Report). STrP 软件移交计划(Software Transfer Plan) SUM 软件用户手册(Software User Manual) SVD 软件版本说明(Software Version Description) SW 软件(Software) 5文档过程 5.1概述 有两种主要类型的标准： a)产品标准，它规定产品的特征和功能需求： b)过程标准，它规定开发产品的过程。 应用程序和计算机软件的复杂性日益增加，使得给使用计算机的用户提供完整的、正确的和易懂的 文档的需要更加迫切。本标准通过规定影响软件文档的质量的活动（做什么和由谁做），提供达到这些 目的的工具。 文档常常是关心在软件已经实现后做些什么。然而，为了质量，软件文档编制应作为整个软件生产 过程的一部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程 实施。 本标准的主要活动是建立开发文档的广泛计划。这是必须的，因为有计划，文档编制的质量会更 好，过程的效率会更高。计划必须包括风格规格说明。本标准不规定风格规格说明的内容（即不规定具 体的布局和字体)，但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对于文档管理者是可 用的和谁做评审和再生产文档。 6
GB/T8567-2006 本标准遵循GB/T8566一2001《信息技术软件生存周期过程》。为其开发过程和管理过程中的 主要文档规定了编制规范。 本标准是按文档由专门的文档管理人员和文本编写人员的模式规定的。具体的项目可根据具体情 况安排。 文档过程的活动应按图1中的顺序执行。 威长密 得到源材料（需方与文档管理者） 开发文档计划 评审文档计划 开发文档—如文档计划中规定的 评审文档 可用性测试—如在 文档计划中规定的 那样 重生产和发布—如在文档计 划中规定的那样 图1文档编制过程概要 其中，有两个阴影框。在一个阴影框中的所有活动应在下一个阴影框中的活动开始之前完成。在 阴影框中的活动可以并行执行。虚线指示可能的重复。 在文档的最小内容已经由需方规定的情况下，这宜由文档管理者在文档计划开发期间纳入。 5.2源材料准备 需方应允许文档管理者访问以下内容： a)所有有关的规格说明、记录格式、屏幕和报告布局、CASE工具输出和文档的准备所需要的任 何其他的信息； b)若可用，软件的操作副本；
GB/T8567-2006 c)软件的分析员和程序员，以及及时和确切地解答由文档开发人员提出的问题； d)若可能，访问典型的用户（为了做读者分析和可用性测试）。 为了增加对产品和它的读者的了解，对软件开发人员的访问是必要的但使这样的访问保持到最小 是文档管理者的责任。 不管文档管理者是否是软件的开发者，需方应提供适用的标准、风格和格式指南和其他相关的材 料。文档管理者应分发这些材料至需要它的文档开发人员。 保证需方交付给文档管理者的所有材料，当交付时，是完整的和正确的且在交付后保持是最新的， 这是需方的责任。 需方保证，提供的材料没有一个违反任何其他部门的知识产权。 文档管理者应采取所有有理由的步骤，以保证由需方提供的材料保持在很好的状态，应保证需方要 求的信息安全并在文档项目完成后，所有材料返回给需方。 注：在某些情况下，不是所有材料需要返回：这应在合同中定义。在某些情况下，由需方传送给文档管理者的材料 要求保持机密和安全。合同宜规定对于传送给文档管理者的材料，需方要求文档管理者的机密和安全等级。 5.3文档计划 5.3.1概要 文档管理者应准备一份文档计划，此计划规定在文档创建中要执行的工作。此文档计划应经需方 正式同意，以预示它完全覆盖了需方的要求。 注：文档计划通常将覆盖整个文档系列。 文档计划应正式地描述计划的文档的范围和限制，以及重要的文档分析和设计决定。也应规定在 文档开发期间实现的过程和控制。 文档计划应包括（但不限于）以下内容： a)计划的文档的工作名称、目的、范围和限制； b)文档的预定的读者，和使用的目的； ©）文档内容的草案表，带有估计的页数和其他媒体的等效细节： )交付：打印副本数，是否提供电子副本，磁盘和文件格式（包括软件版本）和在何处交付： e)版权的拥有者和任何其他所有权； 注：这是复杂的问题，应在合同中规定。 )适当处，包括每个文档的安全或机密级： g) 管理文档开发过程的步骤和控制，包括存储、检索、后备、处理和质量保证（若要求）； h)所用的生产方法、工具和工具版本： )文档开发人员所在的队伍的结构，可包括队伍选择计划： 注：在文档编写和生产的不同阶段中的工作人员，需要不同的技巧。编写人员可能要求对正在编写的系统有好的 知识加上编写文档的经验：编辑人员可能要求有编辑经验而对系统知识无要求：版面艺术家可能对所用的版面 工具外，无任何知识要求。 j)项目依赖； k)所要求的人时和成本： I)项目资源需求，包括需方提供的信息和其他资源： )在软件开发期间，软件变更传送信息给文档管理者的方法： n)文挡的变更控制和维护的计划（任选）： o)实现后评审的计划（任选）； p)显示适当的里程碑的时间表，包括： 1)文挡计划批准： 2)每个草案的准备、评审和改正： 8
GB/T8567-2006 3)可用性测试； 4)打印、装订和发布。 若适当，这些活动的每一个对于文档的每一项应重复。 注：文档计划宜在文档的开发开始以前准备与批准，以保证所有部门同意目标和所用的方法。批准后，计划宜尽可 能广泛地分发；分发宜包括所有文档开发人员和可能包括需方人员及子合同方。 5.3.2文档计划控制 在正式批准后，文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的 分发的清单。若以后文档计划变更了（得到文档管理者和需方的同意），文档管理者应保证所有获得文 档计划副本的人员得到变更通知。 注：因为，过时的计划副本可能引起问题，文档管理者宜杜绝计划副本的失控，并制订计划的所有副本已经更新的审 核过程。 5.4文档开发 按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式（风格）。在软件的开 发和管理过程中需要那些文档，每种文档的规范在下面说明。 5.5评审 5.5.1概述 本条规定文档评审的要求和相关活动。本条主要以用户文档的评审为例说明。对于开发文档的评 审，由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实 效的评审。 用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。 注：评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。 评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。 注：需方宜限制评审人员数，满足评审功能所必需的那些即可。 需方在批准每个用户文档草案之前，应保证文档的安全和合法。 为评审交付的文档应包括从文档管理者来的说明书，说明评审的目的和评审员的职责。 注1：在需方和文档管理者之间在整个开发过程期间维持良好的沟通会提高文档的质量并利于评审成功。这宜包 括非正式的讨论和尽早地提供样板或初始材料给需方。 注2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。 注3：评审过程不排除文档管理者，他们的责任是试图尽可能保证文档的精确和完整。 注4：宜采用作为评审结果的需方的评论，或在草案上加上标记，或写有适当的参考的评论。需方宜保持变更的副 本为了与下一草案相比较。评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。 注5：对于大的、复杂的系统或正在写文档时系统仍在开发，可能需要多于两次草案和一次校样。在这样情况下，最 多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。 5.5.2文档计划评审 此评审的目的应保证文档计划定义的文档，当完成时，既满足开发过程的需要也满足需方在合同中 规定的文档目标。需方同意文档计划，是同意在计划中定义的用户文档的所有可交付的特征。 注：需方宜把注意放在内容的草案表中展示的文档的结构、完整性和可用性。只要适当，文档计划宜在第一个草案 开始工作之前评审和批准。 5.5.3第一个草案评审 第一个草案应包含如在文档计划中描述的文档主体，加上内容表、附录和词汇。在使用自动索引工 具处，生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。 文档的第一个草案的评审目的是核查文档的技术正确性和完整性，以保证草案满足文档计划的目 标。标点符号、风格和版面应如在文档计划中定义的。 在批准第一个草案中，除了要求的变更外，要评审批准技术的正确性、结构清楚性和文档的完整性。 9
GB/T8567-2006 注1：第一个草案宜在交付前编辑。这有两个理由： a)这保证评审者不分心于改正印副的和版面的错误； b)保证由编辑过程引起的任何技术错误被评审着捕获。 注2：草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一个草案返 回前，宜确认，若草案完全改正了，将满足文档计划的要求。 5.5.4第二个草案评审 第二个草案应包括在第一个草案评审中同意的所有变更，且应以尽可能接近最后的形式，包括在文 档计划中定义的可交付的内容。 此评审的目的是核查在第一个草案中的内容已经正确实现。 在第二个草案的批准中，除了草案的物理形式外，批准文档的所有方面。草案的物理形式可能与可 交付的不精确相同。 注：在批准第二个草案前，宜确认草案（包含评审对草案的评论）已经准备好待批准。 5.5.5校样评审 校样应包括在第二个草案评审中同意的所有变更。 此评审的目的是核查对第二个草案的评论已正确实现。任何不正确实现的评论应迅速地通知文档 管理者，他们应相应地修改文档并返回可替换部分的副本，用于进一步评审。 由批准证明，被接受的文档已准备好生产。 5.6与其他公司的文档开发子合同 文档管理者应保证子合同的文档遵循本标准，遵循文档计划和合同。 在子合同的文档中，文档管理者作为本标准的“需方”而子合同承担者作为“文档管理者”。 注：文档管理者应与子合同承担者签定符合本标准的协议。 6文档编制要求 6.1软件生存周期与各种文档的编制 在软件的生存周期中，一般地说，应该产生以下一些基本文档： a)可行性分析（研究）报告； b)软件（或项目）开发计划； c)软件需求规格说明； d)接口需求规格说明； e)系统/子系统设计（结构设计）说明； )软件（结构）设计说明； g) 接口设计说明： h) 数据库（顶层）设计说明； )(软件)用户手册： j》操作手册； k)测试计划； 1)测试报告； m)软件配置管理计划； n) 软件质量保证计划； o)开发进度月报； p)项目开发总结报告； q)软件产品规格说明； r) 软件版本说明等。 10