GB/T8567-2006《计算机软件文档编制规范》 3.29再工程 reengineering 为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程。再工程可包括逆向工程(分析 个系统并产生更高一级的抽象来表示它,如从代码到设计)、重构(在同一个抽象级上把系统从一种表示形式转 换到另一种表示形式)、重编文档(分析一个系统并产生用户文档式支持文档)、正向工程(从现有的系统的软件 产品结合新的需求,产生新系统)、重定目标系统(对系统进行转换以便将其安装到不同的目标系统上)和翻译 将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换成另一种版本)。 3.30需求 requirement (1)为了使需方能够接受一个系统或CSCI所必需具备的特性 (2)本标准或合同中规定的必须遵守的陈述 3.31可重用的软件产品 reusable software product 为一个用途开发但还具有别的用途的软件产品,或者专门为了用于多个项目而开发的软件产品,或者在一 个项目中有多种作用的软件产品。例子包括(但不限于)上市的商用软件产品,需方已装备的软件产品,重用库 中的软件产品和开发方现存的软件产品。每一次使用可以包括这些软件产品的全部或部分,也可以涉及对它的 修改。这个术语可以应用于任何软件产品(例如需求,体系结构等)而不只限于软件本身 3.32软件 software 计算机程序和计算机数据库 注:虽然有些软件的定义中包括文档,本标准把这个定义只限于计算机程序和计算机数据库。 3.33软件开发 software development 产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件 产品的其他活动 3.34软件开发文件 software development file(SDF) 与特定软件实体开发有关的资料库。其内容一般包括(直接的或引用的)有关需求分忻、设计和实现的考虑、 原理和约束条件:开发方内部的测试资料:进度和状态资料。 3.35软件开发库 software development library(SDL) 组受控的软件、文档、其他中间的和最终的软件产品,以及相关的用以促进软件的有序开发和后续支持 的工具和方法。 336软件开发过程 software development process 为了把用户的需求转换成软件产品而进行的一系列有组织的活动 3.37软件工程 software engineering 一般情况下,它是软件开发的同义词。在本标准中,软件工程是软件开发的一个子集,它包含除了合格性 测试之外的全部活动。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命名 3.38软件工程环境 software engineering environment 实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括(但不限于)计算机辅助软件工 程(CASE)的工具、编译程序、汇编程序、连接程序、装载程序、操作系统、排错程序、仿真程序、模拟程序 文档工具和数据库管理系统。 339软件产品 software product 为了满足一个合同而建立、修改或组台的软件及相关资料。例如包括计划、需求、设计、代码、数据库、 测试资料和手册。 340软件质量 software quality 软件满足所规定的需求的能力 3.41软件支持 software support 为保证软件安装后能继续按既定目标持续运行而且在系统的运行中能起到既定的作用而实施的一系列活 动。软件支持包括软件维护、用户支持和有关的活动 3.42软件系统 software system 只由软件组成的系统,有时可能还包括该软件赖以运行的计算机设备
GB/T 8567-2006《计算机软件文档编制规范》 3.29 再工程 reengineering 为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程。再工程可包括逆向工程(分析一 个系统并产生更高一级的抽象来表示它，如从代码到设计)、重构(在同一个抽象级上把系统从一种表示形式转 换到另一种表示形式)、重编文档(分析一个系统并产生用户文档式支持文档)、正向工程(从现有的系统的软件 产品结合新的需求，产生新系统)、重定目标系统(对系统进行转换以便将其安装到不同的目标系统上)和翻译 (将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换成另一种版本)。 3.30 需求 requirement (1)为了使需方能够接受一个系统或 CSCI 所必需具备的特性。 (2)本标准或合同中规定的必须遵守的陈述。 3.31 可重用的软件产品 reusable software product 为一个用途开发但还具有别的用途的软件产品，或者专门为了用于多个项目而开发的软件产品，或者在一 个项目中有多种作用的软件产品。例子包括(但不限于)上市的商用软件产品，需方已装备的软件产品，重用库 中的软件产品和开发方现存的软件产品。每一次使用可以包括这些软件产品的全部或部分，也可以涉及对它的 修改。这个术语可以应用于任何软件产品(例如需求，体系结构等)而不只限于软件本身。 3.32 软件 software 计算机程序和计算机数据库。 注：虽然有些软件的定义中包括文档，本标准把这个定义只限于计算机程序和计算机数据库。 3.33 软件开发 software development 产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件 产品的其他活动。 3.34 软件开发文件 software development file(SDF) 与特定软件实体开发有关的资料库。其内容一般包括(直接的或引用的)有关需求分忻、设计和实现的考虑、 原理和约束条件；开发方内部的测试资料；进度和状态资料。 3.35 软件开发库 software development library(SDL) 一组受控的软件、文档、其他中间的和最终的软件产品，以及相关的用以促进软件的有序开发和后续支持 的工具和方法。 3.36 软件开发过程 software development process 为了把用户的需求转换成软件产品而进行的一系列有组织的活动。 3.37 软件工程 software engineering 一般情况下，它是软件开发的同义词。在本标准中，软件工程是软件开发的一个子集，它包含除了合格性 测试之外的全部活动。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命名。 3.38 软件工程环境 software engineering environment 实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括(但不限于)计算机辅助软件工 程(CASE)的工具、编译程序、汇编程序、连接程序、装载程序、操作系统、排错程序、仿真程序、模拟程序、 文档工具和数据库管理系统。 3.39 软件产品 software product 为了满足一个合同而建立、修改或组台的软件及相关资料。例如包括计划、需求、设计、代码、数据库、 测试资料和手册。 3.40 软件质量 software quality 软件满足所规定的需求的能力。 3.41 软件支持 software support 为保证软件安装后能继续按既定目标持续运行而且在系统的运行中能起到既定的作用而实施的一系列活 动。软件支持包括软件维护、用户支持和有关的活动。 3.42 软件系统 software system 只由软件组成的系统，有时可能还包括该软件赖以运行的计算机设备
GB/T8567-2006《计算机软件文档编制规范》 3.43软件测试环境 software test environment 为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括 (但不限于)仿真程序、代码分析程序、测试用例生成程序和路径分析程序,还可能包括在软件工程环境下用到 的要素。 3.44软件移交 software transition 使软件开发的责任从一个组织转交给另一个组织的一系列活动。一般说,前一个组织是实现初期软件开发, 而后一个组织是进行软件支持。 3.45软件单元 software unit CSCI设计中的一个基本单位:例如,CSCI的一个主要分支,该分支的一个组成部分、一个类、对象、模 块、函数、子程序或者数据库。软件配置项可以出现在层次结构的不同层上并可以由其他的软件配置项组成。 设计中的软件配置项与实现它们的代码和数据实体(例程、过程、数据库、数据文件等)及或包含这些实体的计 算机文件之间不一定有一一对应的关系 缩略语 CASE计算机辅助软件工程 omputer Assistant Software Engineering OM计算机操作手册 Computer Operation Manual CPM|计算机编程手册 Computer Programming Manual CSCI计算机软件配置项 Computer Software Configuration Item DBDD数据库(项层)设计说明 Database Design Description DID资料条目说明 Data Item Description DPMR 发进度月报 Development Plan Month Report DRD数据需求说明 Data requirement Description FAR可行性分析报告 Feasibility analysis Report HWCI硬件配置项 Hardware Configuration Item D接口设计说明 Interface Design Description IRS接口(软件)需求规格说明 Interface Requirement specification IV&V|独立验证和确认 Independent verification and validation OCD运行概念说明 Operation Conception Description PDSR项目开发总结报告 Project Deve lopment summary Report SCCB软件配置控制委员会 Software Configuration Control Board 软件配置管理 Software Configuration Manager SCMP软件配置管理计划 Software Configuration Manager Plan SDD|软件(结构)设计说明 Software Design Description SDF软件开发文件 I Software Development file SFD软件开发文档 Software Development Document SDL软件开发库 Software Development Library SDP软件开发计划 Software Development Pl SIP|软件安装计划 Software Installation plan SPS|软件产品规格说明 Software Product Specification SQA软件质量保证 Software Quality Assure SQAP软件质量保证计划 Software Quality Assure Pl SRS软件需求规格说明 Software Requirement specificati SS系统/子系统设计(结构设计)说明| System Subsystem Design Description SS系统/子系统需求规格说明 System Subsystem Requirement specification STD|软件测试说明 Software Testing descrition STP|软件测试计划 Software Testing Plan
GB/T 8567-2006《计算机软件文档编制规范》 3.43 软件测试环境 software test environment 为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括 (但不限于)仿真程序、代码分析程序、测试用例生成程序和路径分析程序，还可能包括在软件工程环境下用到 的要素。 3.44 软件移交 software transition 使软件开发的责任从一个组织转交给另一个组织的一系列活动。一般说，前一个组织是实现初期软件开发， 而后一个组织是进行软件支持。 3.45 软件单元 software unit CSCI 设计中的一个基本单位：例如，CSCI 的一个主要分支，该分支的一个组成部分、一个类、对象、模 块、函数、子程序或者数据库。软件配置项可以出现在层次结构的不同层上并可以由其他的软件配置项组成。 设计中的软件配置项与实现它们的代码和数据实体(例程、过程、数据库、数据文件等)及或包含这些实体的计 算机文件之间不一定有一一对应的关系。 4 缩略语 CASE 计算机辅助软件工程 Computer Assistant Software Engineering COM 计算机操作手册 Computer Operation Manual CPM 计算机编程手册 Computer Programming Manual CSCI 计算机软件配置项 Computer Software Configuration Item DBDD 数据库(顶层)设计说明 Database Design Description DID 资料条目说明 Data Item Description DPMR 开发进度月报 Development Plan Month Report DRD 数据需求说明 Data requirement Description FAR 可行性分析报告 Feasibility analysis Report HWCI 硬件配置项 Hardware Configuration Item 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
GB/T8567-2006《计算机软件文档编制规范》 STR软件测试报告 Software Testing Report STrP软件移交计划 Software Transfer plan 软件用户手册 Software user manual SVD软件版本说明 Software Version Description SW Software 5文档过程 5.1概述 有两种主要类型的标准: a)产品标准,它规定产品的特征和功能需求 b)过程标准,它规定开发产品的过程。 应用程序和计算机软件的复杂性日益增加,使得给使用计算机的用户提供完整的、正确的和易懂的文档的 需要更加迫切。本标准通过规定影响软件文档的质量的活动(做什么和由谁做),提供达到这些目的的工具。 文档常常是关心在软件已经实现后做些什么。然而,为了质量,软件文档编制应作为整个软件生产过程的 部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。 本标准的主要活动是建立开发文档的广泛计划。这是必须的,因为有计划,文档编制的质量会更好,过程 的效率会更高。计划必须包括风格规格说明。本标准不规定风格规格说明的内容(即不规定具体的布局和字体) 但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对文档管理者是可用的、谁做评审和再生产文档。 本标准遵循GB/8566-2001《信息技术软件生存周期过程》。为其开发过程和管理过程中的主要文档 规定了编制规范。 本标准是按文档由专门的文档管理人员和文本编写人员的模式规定的。具体的项目可根据具体情况安排。 文档过程的活动应按图1中的顺序执行。 图1文档编制过程概要 「得到源材料(需方与文档管理者) 开发文档计划 评审文档计划 开发文档--如文档计划中规定的 评审文档 可用性测试 --如在文档计划 中规定的那样 重生产和发布 如在文档计划中规定的那样 其中,有两个阴影框。在一个阴影框中的所有活动应在下一个阴影框中的活动开始之前完成。在阴影框中 的活动可以并行执行。虚线指示可能的重复。 在文档的最小内容已经由需方规定的情况下,这宜由文档管理者在文档计划开发期间纳入
GB/T 8567-2006《计算机软件文档编制规范》 STR 软件测试报告 Software Testing Report STrP 软件移交计划 Software Transfer Plan SUM 软件用户手册 Software User Manual SVD 软件版本说明 Software Version Description SW 软件 Software 5 文档过程 5.1 概述 有两种主要类型的标准： a)产品标准，它规定产品的特征和功能需求； b)过程标准，它规定开发产品的过程。 应用程序和计算机软件的复杂性日益增加，使得给使用计算机的用户提供完整的、正确的和易懂的文档的 需要更加迫切。本标准通过规定影响软件文档的质量的活动(做什么和由谁做)，提供达到这些目的的工具。 文档常常是关心在软件已经实现后做些什么。然而，为了质量，软件文档编制应作为整个软件生产过程的 一部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。 本标准的主要活动是建立开发文档的广泛计划。这是必须的，因为有计划，文档编制的质量会更好，过程 的效率会更高。计划必须包括风格规格说明。本标准不规定风格规格说明的内容(即不规定具体的布局和字体)， 但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对文档管理者是可用的、谁做评审和再生产文档。 本标准遵循 GB/T 8566—2001《信息技术 软件生存周期过程》。为其开发过程和管理过程中的主要文档 规定了编制规范。 本标准是按文档由专门的文档管理人员和文本编写人员的模式规定的。具体的项目可根据具体情况安排。 文档过程的活动应按图 1 中的顺序执行。 图 1 文档编制过程概要 其中，有两个阴影框。在一个阴影框中的所有活动应在下一个阴影框中的活动开始之前完成。在阴影框中 的活动可以并行执行。虚线指示可能的重复。 在文档的最小内容已经由需方规定的情况下，这宜由文档管理者在文档计划开发期间纳入。 开发文档计划 评审文档计划 得到源材料（需方与文档管理者） 开发文档----如文档计划中规定的 重生产和发布 ----如在文档计划中规定的那样 可用性测试 ----如在文档计划 中规定的那样 评审文档
GB/T8567-2006《计算机软件文档编制规范》 5.2源材料准备 需方应允许文档管理者访问以下内容 a)所有有关的规格说明、记录格式、屏幕和报告布局、cASE工具输出和文档的准备所需要的任何其他的 信息; b)若可用,软件的操作副本 c)软件的分析员和程序员,以及及时和确切地解答由文档开发人员提出的问题 d)若可能,访问典型的用户(为了做读者分析和可用性测试)。 为了增加对产品和它的读者的了解,对软件开发人员的访问是必要的但使这样的访问保持到最小是文档管 理者的责任。 不管文档管理者是否是软件的开发者,需方应提供适用的标准、风格和格式指南和其他相关的材料。文档 管理者应分发这些材料至需要它的文档开发人员 保证需方交付给文档管理者的所有材料,当交付时,是完整的和正确的且在交付后保持是最新的,这是需 方的责任。 需方保证,提供的材料没有一个违反任何其他部门的知识产权。 文档管理者应采取所有有理由的步骤,以保证由需方提供的材料保持在很好的状态,应保证需方要求的信 息安全并在文档项目完成后,所有材料返回给需方 注:在某些情况下,不是所有材料需要返回;这应在合同中定义。在某些情况下,由需方传送给文档管理 者的材料 要求保持机密和安全。合同宜规定对于传送给文档管理者的材料,需方要求文档管理者的机密和安全等级 5.3文档计划 5.3.1概要 文档管理者应准备一份文档计划,此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意 以预示它完全覆盖了需方的要求。 注:文档计划通常将覆盖整个文档系列。 文档计划应正式地描述计划的文档的范围和限制,以及重要的文档分析和设计决定。也应规定在文档开发 期间实现的过程和控制 文档计划应包括(但不限于)以下内容 a)计划的文档的工作名称、目的、范围和限制 b)文档的预定的读者,和使用的目的 c)文档内容的草案表,带有估计的页数和其他媒体的等效细节 d)交付:打印副本数,是否提供电子副本,磁盘和文件格式(包括软件版本)和在何处交付 e)版权的拥有者和任何其他所有权:注:这是复杂的问题,应在合同中规定。) f)适当处,包括每个文档的安全或机密级 g)管理文档开发过程的步骤和控制,包括存储、检索、后备、处理和质量保证(若要求) h)所用的生产方法、工具和工具版本 i)文档开发人员所在的队伍的结构,可包括队伍选择计划 注:在文档编写和生产的不同阶段中的工作人员,需要不同的技巧。编写人员可能要求对正在编写的系统 有好的知识加上编写文档的经验;编辑人员可能要求有编辑经验而对系统知识无要求;版面艺术家可能对所用 的版面工具外,无任何知识要求
GB/T 8567-2006《计算机软件文档编制规范》 5.2 源材料准备 需方应允许文档管理者访问以下内容： a)所有有关的规格说明、记录格式、屏幕和报告布局、cASE 工具输出和文档的准备所需要的任何其他的 信息； b)若可用，软件的操作副本； c)软件的分析员和程序员，以及及时和确切地解答由文档开发人员提出的问题； d)若可能，访问典型的用户(为了做读者分析和可用性测试)。 为了增加对产品和它的读者的了解，对软件开发人员的访问是必要的但使这样的访问保持到最小是文档管 理者的责任。 不管文档管理者是否是软件的开发者，需方应提供适用的标准、风格和格式指南和其他相关的材料。文档 管理者应分发这些材料至需要它的文档开发人员。 保证需方交付给文档管理者的所有材料，当交付时，是完整的和正确的且在交付后保持是最新的，这是需 方的责任。 需方保证，提供的材料没有一个违反任何其他部门的知识产权。 文档管理者应采取所有有理由的步骤，以保证由需方提供的材料保持在很好的状态，应保证需方要求的信 息安全并在文档项目完成后，所有材料返回给需方。 注：在某些情况下，不是所有材料需要返回；这应在合同中定义。在某些情况下，由需方传送给文档管理 者的材料 要求保持机密和安全。合同宜规定对于传送给文档管理者的材料，需方要求文档管理者的机密和安全等级。 5.3 文档计划 5.3.1 概要 文档管理者应准备一份文档计划，此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意， 以预示它完全覆盖了需方的要求。 注：文档计划通常将覆盖整个文档系列。 文档计划应正式地描述计划的文档的范围和限制，以及重要的文档分析和设计决定。也应规定在文档开发 期间实现的过程和控制。 文档计划应包括(但不限于)以下内容： a)计划的文档的工作名称、目的、范围和限制； b)文档的预定的读者，和使用的目的； c)文档内容的草案表，带有估计的页数和其他媒体的等效细节； d)交付：打印副本数，是否提供电子副本，磁盘和文件格式(包括软件版本)和在何处交付； e)版权的拥有者和任何其他所有权；(注：这是复杂的问题，应在合同中规定。) f)适当处，包括每个文档的安全或机密级； g)管理文档开发过程的步骤和控制，包括存储、检索、后备、处理和质量保证(若要求)； h)所用的生产方法、工具和工具版本； i)文档开发人员所在的队伍的结构，可包括队伍选择计划； 注：在文档编写和生产的不同阶段中的工作人员，需要不同的技巧。编写人员可能要求对正在编写的系统 有好的知识加上编写文档的经验；编辑人员可能要求有编辑经验而对系统知识无要求；版面艺术家可能对所用 的版面工具外，无任何知识要求
GB/T8567-2006《计算机软件文档编制规范》 j)项目依赖; k)所要求的人时和成本 1)项目资源需求,包括需方提供的信息和其他资源 m)在软件开发期间,软件变更传送信息给文档管理者的方法; n)文档的变更控制和维护的计划(任选) 0)实现后评审的计划(任选) p)显示适当的里程碑的时间表,包括 1)文档计划批准 2)每个草案的准备、评审和改正 3)可用性测试 4)打印、装订和发布 若适当,这些活动的每一个对于文档的每一项应重复。 注:文档计划宜在文档的开发开始以前准备与批准,以保证所有部门同意目标和所用的方法。批准后,计 划宜尽可能广泛地分发;分发宜包括所有文档开发人员和可能包括需方人员及子合同方。 5.32文档计划控制 在正式批准后,文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清 单。若以后文档计划变更了(得到文档管理者和需方的同意),文档管理者应保证所有获得文档计划副本的人员 得到变更通知。 注:因为,过时的计划副本可能引起问题。文档管理者宜杜绝计划副本的失控,并制订计划的所有副本已 经更新的审核过程。 5.4文档开发 按文档计划规定进行文档开发。通常,在进行文档开发前,要规定文档的格式(风格)。在软件的开发和管 理过程中需要那些文档,每种文档的规范在下面说明, 5.5评审 5.5.1概述 本条规定文档评审的要求和相关活动。本条主要以用户文档的评审为例说明。对于开发文档的评审,由供 方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审 用户文档的评审应由需方实现,包括当需要时与文档管理者讨论 注:评审的耳的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要 评审宜由合适的有资格的人员执行,这些人员被授权请求变更和批准文档的内容 注:需方宜限制评审人员数,满足评审功能所必需的那些即可 需方在批准每个用户文档草案之前,应保证文档的安全和合法 为评审交付的文档应包括从文档管理者来的说明书,说明评审的目的和评审员的职责。 注1:在需方和文档管理者之间在整个开发过程期间维持良好的沟通会提高文档的质量并利于评审成功。 这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。 注2:在要求的变更超出了合同和文档计划的范围时,需要变更合同。 注3:评审过程不排除文档管理者,他们的责任是试图尽可能保证文档的精确和完整
GB/T 8567-2006《计算机软件文档编制规范》 j)项目依赖； k)所要求的人时和成本； l)项目资源需求，包括需方提供的信息和其他资源； m)在软件开发期间，软件变更传送信息给文档管理者的方法； n)文档的变更控制和维护的计划(任选)； 0)实现后评审的计划(任选)； p)显示适当的里程碑的时间表，包括： 1)文档计划批准； 2)每个草案的准备、评审和改正； 3)可用性测试； 4)打印、装订和发布。 若适当，这些活动的每一个对于文档的每一项应重复。 注：文档计划宜在文档的开发开始以前准备与批准，以保证所有部门同意目标和所用的方法。批准后，计 划宜尽可能广泛地分发；分发宜包括所有文档开发人员和可能包括需方人员及子合同方。 5.3.2 文档计划控制 在正式批准后，文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清 单。若以后文档计划变更了(得到文档管理者和需方的同意)，文档管理者应保证所有获得文档计划副本的人员 得到变更通知。 注：因为，过时的计划副本可能引起问题。文档管理者宜杜绝计划副本的失控，并制订计划的所有副本已 经更新的审核过程。 5.4 文档开发 按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式(风格)。在软件的开发和管 理过程中需要那些文档，每种文档的规范在下面说明。 5.5 评审 5.5.1 概述 本条规定文档评审的要求和相关活动。本条主要以用户文档的评审为例说明。对于开发文档的评审，由供 方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。 用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。 注：评审的耳的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。 评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。 注：需方宜限制评审人员数，满足评审功能所必需的那些即可。 需方在批准每个用户文档草案之前，应保证文档的安全和合法。 为评审交付的文档应包括从文档管理者来的说明书，说明评审的目的和评审员的职责。 注 1：在需方和文档管理者之间在整个开发过程期间维持良好的沟通会提高文档的质量并利于评审成功。 这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。 注 2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。 注 3：评审过程不排除文档管理者，他们的责任是试图尽可能保证文档的精确和完整