首页 > 国家标准(GB) > GB/T 8567-2006 计算机软件文档编制规范
GB/T 8567-2006

基本信息

标准号: GB/T 8567-2006

中文名称:计算机软件文档编制规范

标准类别:国家标准(GB)

标准状态:现行

发布日期:2006-03-14

实施日期:2006-07-01

出版语种:简体中文

下载格式:.rar.pdf

下载大小:42855329

标准分类号

标准ICS号:信息技术、办公机械设备>>35.080软件开发和系统文件

中标分类号:>>>> >>>>77

关联标准

替代情况:替代GB/T 8567-1988

采标情况:ISO/IEC JTC1/SC7 N2106-1999 NEQ

出版信息

出版社:中国标准出版社

页数:平装16开 页数:130, 字数:256千字

标准价格:43.0 元

计划单号:20020215-T-339

出版日期:2006-07-01

相关单位信息

首发日期:1988-01-07

起草单位:中软网络技术股份有限公司、信息产业部电子工业标准化研究所、北京联想软件有限公司、用友软件股份有限公司

归口单位:信息产业部电子工业标准化研究所

提出单位:中华人民共和国信息产业部

发布部门:中华人民共和国国家质量监督检验检疫总局 中国国家标准化管理委员会

主管部门:国家标准化管理委员会

标准简介

本标准对软件的开发过程和管理过程应编制的主要文档及其编制的内容、格式规定了基本要求。本标准原则上适用于所有类型的软件产品的开发过程和管理过程。 GB/T 8567-2006 计算机软件文档编制规范 GB/T8567-2006 标准下载解压密码:www.bzxz.net

标准图片预览






标准内容

ICS35.080
中华人民共和国国家标准
GB/T 8567-2006
代替GB/T8567-1988
计算机软件文档编制规范
Specificationforcomputersoftwaredocumentation2006-03-14发布
2006-07-01实施
中华人民共和国国家质量监督检验检疫总发布中国国家标准化管理委员会 
规范性引用文件
术语和定义
缩略语
文档过程
源材料准备
文档计划
文档开发
与其他公司的文档开发子合同
文档编制要求
软件生存周期与各种文档的编制文档编制中的考虑因素
文档编制格式
可行性分析(研究)报告(FAR)
软件开发计划(SDP)
软件测试计划(STP)
软件安装计划(SIP)
软件移交计划(STrP)
运行概念说明(OCD)
系统/子系统需求规格说明(SSS)7.7
接口需求规格说明(IRS)
7.9系统/子系统设计(结构设计)说明(SSDD)7.10接口设计说明(IDD)
7.11软件需求规格说明(SRS)
7.12数据需求说明(DRD)
7.13软件(结构)设计说明(SDD)
7.14数据库(顶层)设计说明(DBDD)7.15软件测试说明(STD)
7.16软件测试报告(STR)
7.17软件配置管理计划(SCMP)
7.18软件质量保证计划(SQAP)
7.19开发进度月报(DPMR)
7.20项目开发总结报告(PDSR)7.21软件产品规格说明(SPS)
7.22软件版本说明(SVD)
7.23软件用户手册(SUM)
7.24计算机操作手册(COM)
7.25计算机编程手册(CPM)
附录A(规范性附录)面向对象软件的文档编制A.1综述
A.2总体说明文档
用况图文档
类图文档
顺序图文档
协作图文档
状态图文档
A.8活动图文档
A.9构件图文档
A.10部署图文档
A.11包图文档
参考文献
GB/T8567-2006《计算机软件文档编制规范》本标准是GB/T8567一1988《计算机软件产品开发文件编制指南》的修订版,并改名为《计算机软件文档编制规范》。本标准从实施之日起代替GB/T8567一1988。本标准与GB/T8567一1988相比,主要变化如下:a)本标准增加了文档编写过程。其内容参考了IS0/IECJTC1/SC7N21061999/04/15《软件工程一一用户文档过程》
本标准主要从软件开发与管理的角度,规定相应的文档及规范。其内容依据GB/T8566一2001《软件生存周期过程》。
在编写本标准时,综合了在软件开发与管理中的经验及中软网络技术股份有限公司有关CMM中拟订的一些文档规范。
本标准与SJ20778一2000《软件开发与文档编制》很好地链接。本标准在规定软件需求规格说明、软件测试文件、软件质量保证计划与软件配置管理计划等文档e)
时,既依据相应的国标,又根据发展与实践经验作了相应的扩展。f)
本标准把SJ/T11291一2003《面向对象的软件系统建模规范第3部分:文档编制》中的文档编制规范作为本标准的规范性附录。本标准的附录A是规范性附录。
本标准由中华人民共和国信息产业部提出。本标准由信息产业部电子工业标准化研究所归口。本标准起草单位:中软网络技术股份有限公司、信息产业部电子工业标准化研究所、北京联想软件有限公司、用友软件股份有限公司。本标准主要起草人;周明德、冯惠、韩乃平、欧阳春生、殷树勋、黄万镒、强学锋、韩振江、邓适宜。1范围
GB/T8567-2006《计算机软件文档编制规范》计算机软件文档编制规范
本标准根据GB/T8566一2001《信息技术软件生存周期过程》的规定,主要对软件的开发过程和管理过程应编制的主要文档及其编制的内容、格式规定了基本要求。本标准原则上适用于所有类型的软件产品的开发过程和管理过程,使用者可根据实际情况对本标准进行适当剪裁(可剪裁所需的文档类型,也可对规范的内容作适当裁剪)。软件文档从使用的角度大致可分为软件的用户需要的用户文档和开发方在开发过程中使用的内部文档(开发文档)两类。供方应提供的文档的类型和规模,由软件的需方和供方在合同中规定。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些支件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准GB/T8566—2001信息技术软件生存周期过程(idtIS0/IEC:12207:1995)GB/T11457一2006软件工程术语
3术语和定义
GB/T11457一2006确立的以及下列术语和定义适用于本标准。3.1验收acceptance
需方授权代表的一项活动,通过该活动,需方接受履行合同的部分或全部的软件产品的所有权。3.2需方acquinr
为自已或为另一个组织采购软件产品的组织。3.3批准approval
需方的授权代表或开发方的上级组织对开发方的项目计划、设计或其他方面表示满意并可以作为下一阶段工作基础而签署的书面文件。
3.4体系结构architecture
个系统或CSCI(ComputerSoftwareConfigurationItem-计算机软件配置项)的组织结构,标明它的组成,这些组成的接口和它们之间的操作概念。3.5相关开发方associatedeveloper一个既不是主承包方也不是开发方的分承包方的组织,但它在同一个或相关系统或项目中承担开发工作。3.6行为设计behavioraldesign
从用户观点出发,对整个系统或CScI的行为进行的设计,它只考虑满足用户需求而不考虑系统或CSC的内部实现。这种设计与体系结构设计不同,后者要标明系统或CSCI的内部部件,并有这些部件的详细设计。3.7构建版;开发阶段build
(1)软件的一个版本,它满足完整的软件所要满足的全部需求的一个特定的子集。(2)开发满足特定需求子集的软件版本所经历的时间。注:术语一开发阶段”和一版本”之间的关系依赖于开发方:例如,可以通过几个版本来实现一个开发阶段,一个开发阶段也可以发行几个并行的版本如发往不同的地点),或者将它们用作为同义词。3.8计算机数据库computerdatabase见3.14数据库。
3.9计算机硬件computerhardware能接收和存储计算机数据的,对计算机数据执行一系列系统性的操作的,或能产生控制输出的设备。这类设备能实现基本的解释、计算、通信、控制或其他逻辑功能,3.10计算机程序computerprogram能使计算机硬件实现计算或控制功能的计算机指令和数据定义的集合。3.11计算机软件computersoftware见3.32软件。
GB/T8567-2006《计算机软件文档编制规范》3.12计算机软件配置项computersoftwareconfigurationitem(cscI)满足最终使用功能的软件集合,而且它由需方指定进行单独的配置管理。CSCI应从下列诸因素中进行折衰选择:软件功能、规模、宿主机或目标计算机、开发方、支持概念、重用计划、关键性、接口考虑、是否需要单独编写文档和控制以及其他因素。3.13配置项configurationitem
能满足最终使用功能的硬件集合、软件集合或者软、硬件两者的集合,且由需方指定进行单独的配置管理3.14数据库database
以一种能被用户或计算机程序通过一个数据库管理系统进行访问的方式,存储在一个或多个计算机文件中的相关数据的集合。
3.15数据库管理系统databasemanagementsystem是一整套计算机程序,它提供为建立、修改、使用和完整性维护一个数据库所需的功能。3.16可交付的软件产品deliverablesoftwareproduct合同要求交付给需方或其他指定的接受方的软件产品。3.17设计design
开发方为响应一定的需求而对一个系统或CSCI选取的一些性能/规格。这些特性中有些是与需GB/T8567-2006求相匹配的:有一些是需求的精细化,如为了响应显示错误信息这一需求而定义所有的错误信息;有一些则是与实现有关的,如为满足需求,决定选用哪些软件配置项和逻辑。3.18开发方developer
开发软件产品的组织(“开发”包括新的软件开发、修改、重用、再工程、维护或产生软件产品的任何其他活动)。开发方可以是一个承制方或者政府机构。3.19文档/文档编制document/documentation能供人或机器阅读的,一般具有永久性的一套资料(不管它们记录在什么媒体上)。3.20评价evaluation
确定一个项或一个活动是否满足指定准则的过程。3.21固件firmware
硬件设备和以只读软件的形式驻留在硬件设备上的计算机指令和/或计算机数据的组合。3.22硬件配置项hardwareconfigurationitem(HwcI)满足最终使用功能并由需方指定进行单独配置管理的一套硬件。3.23独立验证与确认independentverificationandvalidation(IV&V)由一个机构对软件产品和活动作系统的评估,这个机构不负责该产品的开发或被评估的活动。IV&V不在本标准的范围内。
3.24接口interface
在软件开发中,两个或多个实体(如cScI一cScIcscI一HWC:ICSCI一用户,或软件配置项一软件配置项)之间的关系。这些实体依据这种关系共享、提供或交换数据。接口并不是CSCI、软件配置项或其他的系统部件;接口只是这些实体间的一种关系。3.25联合评审jointreview
由需方和开发方双方代表参加的对项目状态、软件产品和/或项目中的问题进行检查和讨论的活动或会议。3.26非交付的软件产品Non-deliverablesoftwaerproduct不是合同中要求交付给需方或其他指定接受方的软件产品。3.27过程process
为实现某个既定目的而进行的一组有组织的活动,例如,软件开发过程。3.28合格性测试qualificationtesting为了向需方表明一个CSCI或系统满足其指定的需求而进行的测试。3.29再工程reengineering
为了以一种新的形式重组一个现有的系统而对其进行检查和改造的过程。再工程可包括逆向工程(分析一GB/T8567-2006《计算机软件文档编制规范》个系统并产生更高一级的抽象来表示它,如从代码到设计)、重构(在同一个抽象级上把系统从一种表示形式转换到另一种表示形式)、重编文档(分析一个系统并产生用户文档式支持文档)、正向工程(从现有的系统的软件产品结合新的需求,产生新系统)、重定目标系统(对系统进行转换以便将其安装到不同的目标系统上)和翻译(将源码从一种语言转换到另一种语言或者从一种语言的某个版本转换成另一种版本)。3.30需求requirement
(1)为了使需方能够接受一个系统或CSCI所必需具备的特性。(2)本标准或合同中规定的必须遵守的陈述。3.31可重用的软件产品reusablesoftwareproduct为一个用途开发但还具有别的用途的软件产品,或者专门为了用于多个项目而开发的软件产品,或者在个项目中有多种作用的软件产品。例子包括(但不限于)上市的商用软件产品,需方已装备的软件产品,重用库中的软件产品和开发方现存的软件产品。每一次使用可以包括这些软件产品的全部或部分,也可以涉及对它的修改。这个术语可以应用于任何软件产品(例如需求,体系结构等)而不只限于软件本身。3.32软件software
计算机程序和计算机数据库。
注:虽然有些软件的定义中包括文档,本标准把这个定义只限于计算机程序和计算机数据库。3.33软件开发softwaredevelopment产生软件产品的一整套活动。软件开发可以包括新开发、修改、重用、再工程、维护或者任何会产生软件产品的其他活动。
3.34软件开发文件softwaredevelopmentfile(SDF)与特定软件实体开发有关的资料库。其内容一般包括(直接的或引用的)有关需求分析、设计和实现的考虑、原理和约束条件;开发方内部的测试资料;进度和状态资料。3.35软件开发库softwaredevelopment1library(SDL)一组受控的软件、文档、其他中间的和最终的软件产品,以及相关的用以促进软件的有序开发和后续支持的工具和方法。
3.36软件开发过程softwaredevelopmentprocess为了把用户的需求转换成软件产品而进行的一系列有组织的活动。3.37软件工程softwareengineering一般情况下,它是软件开发的同义词。在本标准中,软件工程是软件开发的一个子集,它包含除了合格性测试之外的全部活动。本标准之所以加以这种区分只是为了给软件工程和软件测试环境以不同的命名。3.38软件工程环境softwareengineeringenvironment实施软件工程所需要的设施、硬件、软件、固件、方法和文档。它可以包括(但不限于)计算机辅助软件工程(CASE)的工具、编译程序、汇编程序、莲接程序、装载程序、操作系统、排错程序、仿真程序、模拟程序、文档工具和数据库管理系统。
3.39软件产品softwareproduct
为了满足一个合同而建立、修改或组台的软件及相关资料。例如包括计划、需求、设计、代码、数据库、测试资料和手册。
3.40软件质量softwarequality
软件满足所规定的需求的能力。3.41软件支持softwaresupport
为保证软件安装后能继续按既定目标持续运行而且在系统的运行中能起到既定的作用而实施的一系列活动。软件支持包括软件维护、用户支持和有关的活动。3.42软件系统softwaresystem
只由软件组成的系统,有时可能还包括该软件赖以运行的计算机设备。3.43软件测试环境softwaretestenvironment为完成软件合格性测试和可能的其他测试所需的设施、硬件、软件、固件、方法和文档。其要素可以包括(但不限于)仿真程序、代码分析程序、测试用例生成程序和路径分析程序,还可能包括在软件工程环境下用到的要素。
3.44软件移交softwaretransitionGB/T8567-2006《计算机软件文档编制规范》使软件开发的责任从一个组织转交给另一个组织的一系列活动。一般说,前一个组织是实现初期软件开发而后一个组织是进行软件支持。3.45软件单元softwareunit
CSCI设计中的一个基本单位:
该分支的一个组成部分、
一个类、对象、模
例如,CSCI的一个主要分支,
函数、子程序或者数据库。软件配置项可以出现在层次结构的不同层上并可以由其他的软件配置项组成。设计中的软件配置项与实现它们的代码和数据实体(例程、过程、数据库、数据文件等)及或包含这些实体的计算机文件之间不一定有一一对应的关系。4缩略语
计算机辅助软件工程
计算机操作手册
计算机编程手册
计算机软件配置项
数据库(顶层)设计说明
资料条目说明
开发进度月报
数据需求说明
可行性分析报告
硬件配置项
接口设计说明
接口(软件)需求规格说明
独立验证和确认
运行概念说明
项目开发总结报告
软件配置控制委员会
软件配置管理
软件配置管理计划
软件(结构)设计说明
软件开发文件
软件开发文档
软件开发库
软件开发计划
软件安装计划
软件产品规格说明
软件质量保证
软件质量保证计划
软件需求规格说明
系统/子系统设计(结构设计)说明系统/子系统需求规格说明
软件测试说明
软件测试计划
软件测试报告
软件移交计划
软件用户手册
Computer
Engineering
Assistant Software
Computer Operation Manual
Computer
Programming Manual
Computer Software
Configuration Item
Database Design Description
Data Item Description
Development Plan Month ReportDatarequirement Description
Feasibility analysis Report
Hardware Configuration Item
Interface Design DescriptionRequirement Specification
Interface
IndependentverificationandvalidationOperation
Conception Description
Project
Development
summary Report
ConfigurationControlBoard
Software
Software
Configuration
Manager
eConfigurationManagerPlan
Software
Design Description
Software
Software
Development File
Software
Development Document
Software
Development Library
Development Plan
Software
Software
Installation Plan
Software
Product Specification
Software
Quality
Assure
Software Quality AssurePlan
Software
Requirement Specification
System Subsystem DesignDescriptionRequirement Specification
System Subsystem
Software
Software
Testing Descrition
Testing Plan
Software
Testing Report
Transfer Plan
Software
Software User Manual
软件版本说明
5文档过程
5.1概述
有两种主要类型的标准:
a)产品标准,它规定产品的特征和功能需求;b)过程标准,它规定开发产品的过程。GB/T8567-2006《计算机软件文档编制规范》SoftwareVersion Description
Software
应用程序和计算机软件的复杂性日益增加,使得给使用计算机的用户提供完整的、正确的和易懂的文档的需要更加迫切。本标准通过规定影响软件文档的质量的活动(做什么和由谁做),提供达到这些目的的工具文档常常是关心在软件已经实现后做些什么。然而,为了质量,软件文档编制应作为整个软件生产过程的部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。本标准的主要活动是建立开发文档的广泛计划。这是必须的,因为有计划,文档编制的质量会更好,过程的效率会更高。计划必须包括风格规格说明。本标准不规定风格规格说明的内容(即不规定具体的布局和字体),但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对文档管理者是可用的、谁做评审和再生产文档。本标准遵循GB/T8566一2001《信息技术软件生存周期过程》。为其开发过程和管理过程中的主要文档规定了编制规范。
本标准是按文档由专门的文档管理人员和文本编写人员的模式规定的。具体的项目可根据具体情况安排。文档过程的活动应按图1中的顺序执行。图1文档编制过程概要
得到源材料(需方与文档管理者)开发文档计划
评审文档计划
开发文档---如文档计划中规定的评审文档
可用性测试
--如在文档计划
中规定的那样
重生产和发布
-如在文档计划中规定的那样
其中,有两个阴影框。在一个阴影框中的所有活动应在下一个阴影框中的活动开始之前完成。在阴影框中的活动可以并行执行。虚线指示可能的重复。在文档的最小内容已经由需方规定的情况下,这宜由文档管理者在文档计划开发期间纳入。5.2源材料准备
需方应允许文档管理者访问以下内容:a)所有有关的规格说明、记录格式、屏幕和报告布局、cASE工具输出和文档的准备所需要的任何其他的信息;
b)若可用,软件的操作副本:
GB/T8567-2006《计算机软件文档编制规范》c)软件的分析员和程序员,以及及时和确切地解答由文档开发人员提出的问题:d)若可能,访问典型的用户(为了做读者分析和可用性测试)。为了增加对产品和它的读者的了解,对软件开发人员的访问是必要的但使这样的访问保持到最小是文档管理者的责任,
不管文档管理者是否是软件的开发者,需方应提供适用的标准、风格和格式指南和其他相关的材料。文档管理者应分发这些材料至需要它的文档开发人员。保证需方交付给文档管理者的所有材料,当交付时,是完整的和正确的且在交付后保持是最新的,这是需方的责任。
需方保证,提供的材料没有一个违反任何其他部门的知识产权。文档管理者应采取所有有理由的步骤,以保证由需方提供的材料保持在很好的状态,应保证需方要求的信息安全并在文档项目完成后,所有材料返回给需方。注:在某些情况下,不是所有材料需要返回;这应在合同中定义。在某些情况下,由需方传送给文档管理者的材料
要求保持机密和安全。合同宜规定对于传送给文档管理者的材料,需方要求文档管理者的机密和安全等级5.3文档计划
5.3.1概要
文档管理者应准备一份文档计划,此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意以预示它完全覆盖了需方的要求。注:文档计划通常将覆盖整个文档系列。文档计划应正式地描述计划的文档的范围和限制,以及重要的文档分析和设计决定。也应规定在文档开发期间实现的过程和控制。
文档计划应包括(但不限于)以下内容:a)计划的文档的工作名称、目的、范围和限制;b)文档的预定的读者,和使用的目的;c)文档内容的草案表,带有估计的数和其他媒体的等效细节:d)交付:打印副本数,是否提供电子副本,磁盘和文件格式(包括软件版本)和在何处交付:e)版权的拥有者和任何其他所有权;(注:这是复杂的问题,应在合同中规定。)f)适当处,包括每个文档的安全或机密级:g)管理文档开发过程的步骤和控制,包括存储、检索、后备、处理和质量保证(若要求);h)所用的生产方法、工具和工具版本:i)文档开发人员所在的队伍的结构,可包括队伍选择计划;注:在文档编写和生产的不同阶段中的工作人员,需要不同的技巧。编写人员可能要求对正在编写的系统有好的知识加上编写文档的经验;编辑人员可能要求有编辑经验而对系统知识无要求;版面艺术家可能对所用的版面工具外,无任何知识要求。j)项目依赖;
k)所要求的人时和成本;
1)项目资源需求,包括需方提供的信息和其他资源:m)在软件开发期间,软件变更传送信息给文档管理者的方法n)文档的变更控制和维护的计划(任选);0)实现后评审的计划(任选);
p)显示适当的里程碑的时间表,包括:1)文档计划批准;
2)每个草案的准备、评审和改正;3)可用性测试;
4)打印、装订和发布。
若适当,这些活动的每一个对于文档的每一项应重复。GB/T8567-2006《计算机软件文档编制规范》注:文档计划宜在文档的开发开始以前准备与批准,以保证所有部门同意目标和所用的方法。批准后,计划宜尽可能广泛地分发;分发宜包括所有文档开发人员和可能包括需方人员及子合同方。5.3.2文档计划控制
在正式批准后,文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清单。若以后文档计划变更了(得到文档管理者和需方的同意),文档管理者应保证所有获得文档计划副本的人员得到变更通知。
注:因为,过时的计划副本可能引起问题。文档管理者宜杜绝计划副本的失控,并制订计划的所有副本已经更新的审核过程。
5.4文档开发
按文档计划规定进行文档开发。通常,在进行文档开发前,要规定文档的格式(风格)。在软件的开发和管理过程中需要那些文档,每种文档的规范在下面说明。5.5评审
5.5.1概述
本条规定文档评审的要求和相关活动。本条主要以用户文档的评审为例说明。对于开发文档的评审,由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。用户文档的评审应由需方实现,包括当需要时与文档管理者讨论,注:评审的耳的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。评审宜由合适的有资格的人员执行,这些人员被授权请求变更和批准文档的内容。注:需方宜限制评审人员数,满足评审功能所必需的那些即可。需方在批准每个用户文档草案之前,应保证文档的安全和合法。为评审交付的文档应包括从文档管理者来的说明书,说明评审的目的和评审员的职责。注1:在需方和文档管理者之间在整个开发过程期间维持良好的沟通会提高文档的质量并利于评审成功。这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。注2在要求的变更超出了合同和文档计划的范围时,需要变更合同。注3评审过程不排除文档管理者,他们的责任是试图尽可能保证文档的精确和完整注4宜采用作为评审结果的需方的评论,或在草案上加上标记,或写有适当的参考的评论。需方宜保持变更的副本为了与下一章案相比较。评论应使文档开发人员能实现所要求变更而不需要评审人员进一步解释。注5对于大的、复杂的系统或正在写文档时系统仍在开发,可能需要多于两次草案和一次校样。在这样情况下,最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。5.5.2文档计划评审
此评审的目的应保证文档计划定义的文档,当完成时,既满足开发过程的需要也满足需方在合同中规定的文档目标。需方同意文档计划,是同意在计划中定义的用户文档的所有可交付的特征。注:需方宜把注意放在内容的草案表中展示的文档的结构、完整性和可用性。只要适当,文档计划宜在第一个草案开始工作之前评审和批准。5.5.3第一个草案评审
第一个草案应包含如在文档计划中描述的文档主体,加上内容表、附录和词汇。在使用自动索引工具处,生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。文档的第一个草案的评审目的是核查文档的技术正确性和完整性,以保证草案满足文档计划的目标。标点符号、风格和版面应如在文档计划中定义的。在批准第一个草案中,除了要求的变更外,要评审批准技术的正确性、结构清楚性和文档的完整性。注1:第一个草案宜在交付前编辑。这有两个理由:a)这保证评审者不分心于改正印刷的和版面的错误;b)保证由编辑过程引起的任何技术错误被评审者捕获。注2草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一GB/T8567-2006《计算机软件文档编制规范》个草案返回前,宜确认,若草案完全改正了,将满足文档计划的要求。5.5.4第二个草案评审
第二个草案应包括在第一个草案评审中同意的所有变更,且应以尽可能接近最后的形式,包括在文档计划中定义的可交付的内容。
此评审的目的是核查在第一个草案中的内容已经正确实现。在第二个草案的批准中,除了草案的物理形式外,批准文档的所有方面。草案的物理形式可能与可交付的不精确相同。
注:在批准第二个草案前,宜确认草案包含评审对草案的评论)已经准备好待批准。5.5.5校样评审
校样应包括在第二个草案评审中同意的所有变更。此评审的目的是核查对第二个草案的评论已正确实现。任何不正确实现的评论应迅速地通知文档管理者,他们应相应地修改文档并返回可替换部分的副本,用于进一步评审。由批准证明,被接受的文档已准备好生产。5.6与其他公司的文档开发子合同文档管理者应保证子合同的文档遵循本标准,遵循文档计划和合同。在子合同的文档中,文档管理者作为本标准的“需方”而子合同承担者作为“文档管理者”。注:文档管理者应与子合同承担者签定符合本标准的协议。6文档编制要求
6.1软件生存周期与各种文档的编制在软件的生存周期中,一般地说,应该产生以下一些基本文档:a)可行性分析(研究)报告;Www.bzxZ.net
b)软件(或项具)开发计划:
c)软件需求规格说明;
d)接口需求规格说明:
e)系统/子系统设计(结构设计)说明:f)软件(结构)设计说明;
g)接口设计说明;
h)数据库(顶层)设计说明;
i))(软件)用户手册:
j)操作手册:
k)测试计划;
1)测试报告;
m)软件配置管理计划:
n)软件质量保证计划;
0)开发进度月报;
p)项目开发总结报告;
q)软件产品规格说明;
r)软件版本说明等。
本标准将给出这些文档的编制规范,同时,本标准也是这些文档的编写质量的检验准则。一般地说,一个软件总是一个计算机系统(包括硬件、固件和软件)的组成部分。鉴于计算机系统的多样性,本标准一般不涉及整个系统开发中的文档编制问题,本标准仅仅是软件开发过程中的文档编制指南。对于面向对象的软件开发,其文档编制要求,参见附录A,对于使用文档的人员而言,他们所关心的文件的种类随他们所承担的工作而异。管理人员
可行性分析(研究)报告
项目开发计划
软件配置管理计划
软件质量保证计划
开发进度月报
项目开发总结报告
开发人员
可行性分析(研究)报告
项目开发计划
软件需求规格说明
接口需求规格说明
软件(结构)设计说明
接口设计说明书
数据库(顶层)设计说明
测试计划
测试报告
维护人员
软件需求规格说明
接口需求规格说明
软件(结构)设计说明
测试报告
软件产品规格说明
软件版本说明
用户手册
操作手册
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。