GB-T 8567-2006 计算机软件文档编制规范

1、、GB/T 8567-2006计算机软件文件作成规范、目录、1修订背景2修订是3因旧版本的差异而导致的4新版本的标准结构5文件作成过程6文件作成要求7文件作成形式8总结，1、本标准修订的背景，GB/T8567-1988版是英国的这个标准的公布和实施对我国1980年代、90年代的软件开发起到了重要的作用。 但是，随着时间的流逝，软件工程技术的发展和提高，目前88版无法满足软件产业发展的需要，需要修改GB/T8566-1988版。 二、GB/T8567-2006制定的依据，主要依据： GB/T8566-2001信息技术软件生存周期过程SJ/T20778-2000软件开发和文件制作ISO/IEC15

2、910:1999信息技术软件用户文件处理T8567新版本的主要差异GB/T8567-1988主要应用于瀑布型模型的开发方法GB/T8567-1988提出了14种文件的制作形式的要求：1)可行性研究报告书2 )项目开发计划3 )软件的要求说明书，以及T8567的旧版本的主要差异4 )数据要求说明书5 )概要设计说明书6 )详细设计说明书7 )数据库设计说明书8 )用户手册9 )操作说明书10 )模块开发卷宗11 )测试计划12 )测试分析报告书13 )开发进展月报14 )项目开发总结报告书T8567新版本的主要差异GB/T8567-2006原则上可以应用于各种类型的开发方法GB/T8567-20

3、06描述了文档生成过程GB/T8567-2006要求25种文档的生成形式1 )可行性分析(研究)报告软件测试计划4 )软件安装计划，GB/T8567的旧版本的主要差异5 )软件交接计划6 )运行概念说明7 )系统/子系统需求规格说明8 )接口需求规格说明9 )系统/子系统设计(结构设计) 软件需求规格说明12 )数据需求说明13 )软件(结构)设计说明，GB/T8567新版本的主要差异14 )数据库(顶层)设计说明15 )软件测试说明16 )软件测试报告17 )软件结构管理计划18 开发进展月报20 )项目开发总结报告，GB/T8567新版本的主要差异21 )软件产品规格说明22 )软件版本说

4、明23 )软件用户手册24 )计算机操作手册25 )计算机编程提出了面向对象的10种文件的制作形式的要求，4，GB/T8567-2006标准结构1，范围2，标准的引用文件3，术语和定义4，缩写5，文件(制作)过程6，文件制作要求7，文件制作格式附录a面向对象软件的文件制作，5，文件(有主要类型的标准： a .产品标准、规定产品特征和功能要求的b .规定产品开发过程的流程标准。 随着应用程序和计算机软件的复杂性的增加，越来越需要为使用计算机的用户提供完整、准确、易懂的文档。 此标准通过定义影响软件文档质量的活动(做什么和谁做)提供了用于实现这些目的的工具。 文档往往会在意在软件安装后做什么. 但

5、是，为了质量，软件文档的制作必须是软件生产过程的一部分。 工艺计划必须包括文档计划。此标准还为用户和客户提供了工具，以保证文档流程的实施。 这个标准的主要活动之一是制定开发文件的广泛计划。 因为有计划，文件制作的质量提高，流程效率提高。 为了遵循这个标准，计划必须包含样式规格的说明。 此标准没有规定样式规格说明的内容(即没有规定具体的布局和字体)，但是样式规格说明必须复盖什么。 本标准还规定了什么样的信息可以用于文件管理者，谁进行审查和文件的再生产。 5.2文件(制作)过程的关注点、文件制作计划文件开发(制作)文件审查、5.3文件计划、5.3.1概要文件管理者必须准备文件计划。 这项计划规定了

6、文件编制过程中执行的工作。 这个文件计划必须经过用户的正式同意，预言完全垄断了用户的要求。 l文件计划通常复盖整个文件系列。 文档计划必须正式描述计划的文档范围和限制，以及重要的文档分析和设计决策。 还必须规定在文档开发过程中实现的流程和控制。 文档计划应包括但不限于以下内容： a )计划文档的工作名称、目的、范围和限制。 b )文件的预定读者和使用目的。 c )文档内容草案表，包含估计页数和其他媒体的同等详细信息。 d )分发：打印份数、是否提供电子副本、磁盘和文件格式(包括软件版本)和分发位置。 e )版权所有者和其他所有权。 l这是一个复杂的问题，必须在合同中规定。 f )适当的位置，包

7、括每份文件的安全或机密等级。 g )根据需要管理和控制文档开发过程。 h )使用的生产方法、工具、工具版本。 I )文档开发人员所属团队的结构，可选，包括团队选择计划。 l文件制作和生产不同阶段的工作人员需要不同的技术。 作者可能要求正在制作的系统有良好的知识和文件制作的经验编辑要求有编辑经验，可能没有要求系统知识的版面设计艺术家可能除了使用的版面设计工具以外没有知识要求。 j )项目依赖。 k )被要求的人的时间和成本。 l )项目资源的需求，包括用户提供的信息和其他资源。 m )在软件开发期间，更改软件向文档管理员传达信息的方式。 n )计划文档的变更管理和维护(可选)。 o )实现后审查

8、的计划(可选)。 p )查看适当的里程碑的时间表。 1 )文档计划的批准文档中的每个项目都必须重复。 l文件计划2 )各草案的准备、审查和修正3 )可用性测试4 )印刷、装订、公开。 如果需要，这些活动中的每一项都在文件开发开始前进行准备和批准，以确保所有部门都同意目标和使用方法。 批准后，计划必须尽可能广泛地分发，包括所有文件开发人员、需要者和子签约者。 5.3.2文件计划控制正式同意后，文件管理者必须控制文件计划及其公布。 文档管理员必须保留文档计划副本的分发列表。 今后文件计划变更时(得到文件管理者和用户的同意时)，文件管理者必须向得到文件计划复印件的所有人收到变更通知。 l由于计划的过

9、期副本可能会引起问题，文档管理员必须禁止对计划进行未受控制的副本，并创建计划的所有副本都被更新的审计流程。 5.4按照文件开发、文件计划的规定进行文件开发。 通常，在进行文档开发之前，规定文档的格式(样式)。 在软件的开发和管理过程中，需要这些文档，每个文档的规格如下所示。 概述5.5审查，5.5.1本节规定的文件审查的要求和相关活动。 本节主要以用户文档的评论为例进行说明。 开发文件的审查，由供应商组织实施。批准由开发组织的上级技术机关实施。 必须重视更频繁和非正式的重视实效。 不应该追求形式。 用户文件的审查，包括根据需要与文件管理者进行讨论，必须由必要一方实现。 l审查的目的是保证提交的

10、资料完全准确，满足合同和文件计划中定义的需求。 审查应该由有适当资格的人进行，这些人被授权要求变更和批准文件内容。 l审查人数必须限制审查功能所需的东西。 用户在批准每个用户的文件草案前，必须保证文件的安全和合法性。 为了审查而交付的文件中，包括文件管理者的说明书，必须说明审查的目的和评委的责任。 l注1 :在用户和文件管理者之间通过开发过程保持良好的通信，可以提高文件质量，有利于审查的成功。 这包括非正式讨论和尽快向需要者提供模板和初始资料。 l注2 :如果请求的更改超出合同和文档计划的范围，则需要更改合同。 l注3 :审查程序不免除文件管理员。 他们的责任是尽可能保证文件的正确性和完整性。

11、 l注4 :来自审查结果的用户的审查结果，最好有适当的参考，或附上被标记的草案写评论。 必要时，必须保留变更的副本以与以下草案进行比较。 评论必须允许文档开发人员实现所请求的更改，而无需审阅者进一步解释。 l注5 :在大型复杂或正在编写文件的系统中，可能需要草案和校对两次以上。 在这种情况下，最好在用户和文件管理者之间同意最多的草案数，用文件计划来规定。 5.5.2文件计划审查这项审查的目的必须保证文件计划中定义的文件，完成时，满足开发过程的需求和用户在合同中规定的文件目标。 用户同意文档计划是同意计划中定义的用户文档的所有交付件的特征。 l注：请注意内容草案表中所示的文档的结构、完整性和可用

12、性。 如果合适，文件计划应该在第一个草案开始工作前进行审查和批准。 5.5.3第一条草案审查的第一条草案包括文档计划中所述的文档主体、内容表、附录和术语。 使用自动索引工具，生成的索引包含位置引用。 标点符号、样式和布局必须按照文档计划中的说明进行。 文件第一个草案的审查目的是检查文件的技术正确性和完整性，保证草案达到文件计划的目标。 标点符号、样式和布局必须与文档计划中定义的相同。 在第一份草案的批准中，除了要求的变更外，审查批准技术的正确性、结构的明确性和文件的完整性。 l注1 :第一条草案必须在交货前进行编辑。 这有两个理由： a )保证审查者不注意修改印刷和纸面的错误；b )保证审查者

13、捕获编辑过程引起的技术错误。 l注2 :草案必须审查文件计划中批准的目标、读者定义、内容表和其他特征。 在返回带有评论的第一条草案之前，请确保草案已完全修改，以满足文档计划的要求。 5.5.4第2草案审查第2草案必须包括第1草案审查中达成的所有变更，尽可能以接近最后的形式包含文件计划中定义的可交货内容。 本审查的目的是验证最初草案中的内容是否正确实现。 在第二个草案的批准中，除了草案的物理形式以外，批准文件的各个方面。 草案的物理形式可能是可交货的和不准确的。 l注：在批准第2条草案之前，请确保准备好批准草案(包括对草案的审查)。 六、文件编制请求、6.1软件的生存期间和各种文件的编制，在计算

14、机软件的生存期间，一般应该生成以下基本文件。可行性分析(研究)报告软件(或项目)开发计划软件要求规格说明接口要求规格说明系统/子系统设计(结构设计)说明软件(结构)设计说明，接口设计说明数据库(顶层) 设计说明(软件)用户手册操作手册测试计划测试报告、软件构成管理计划软件质量保证项目开发进展月报项目开发的总结报告书软件产品规格的说明软件版本的说明等。 本标准提供了这些文件的制作规范，同时本标准也是这些文件制作质量的检查标准。 一般地，软件总是一个计算机系统(包括硬件、固件、软件)的组件。 考虑到计算机系统的多样性，本标准一般与系统开发中的文件制作问题无关，本标准只是软件开发中的文件制作指南。

15、对于使用文档的用户来说，您感兴趣的文档类型因您所负责的工作而异。 管理者：可行性分析(研究)报告，项目开发计划，软件配置管理计划，软件质量保证计划，开发进展月报，项目开发总结报告，开发者：可行性分析(研究)报告，项目开发计划，软件需求规格说明，界面需求规格说明设计说明、界面设计说明书、数据库(顶层)设计说明、测试计划、测试报告、维护人员：软件要求规格说明、接口要求规格说明、软件(结构)设计说明、测试报告、用户：软件产品规格说明、软件版本该标准规定了在软件开发过程中制作文件的要求，这些文件从使用的角度分为用户文件和开发文件。 其中，用户文件必须交付给用户。 用户应该得到的文件的种类和规模由供应商

16、和用户之间签订的合同规定。 如上所述，软件被认为是软件的生存期，直到从一个想法出现之日起，软件开发成功地开始使用，最后停止使用并被另一软件取代为止。软件的生存期通常可分为以下六个阶段需求分析阶段设计阶段实现阶段测试阶段运行和维护阶段。 在可行性分析(研究)和计划阶段，要确定该软件的开发目标和总要求，必须制定可行性分析、投资收益分析、开发计划，并完成要制定的文件。 在需求分析阶段，系统分析者对所设计的系统进行系统分析，确定其软件的各功能、性能需求和设计约束，确定书面要求，作为该阶段的工作的结果，一般来说是软件需求规格说明(也称为软件需求说明、软件规格说明)，数据在设计阶段，系统设计者和程序设计者

17、在反复理解软件需求的基础上，提交多个设计，分析各设计可履行的功能并相互比较，最后确定设计，确定该软件的结构、模块(或CSCI )的区分、功能的分配、处理流在设计的系统复杂的情况下，设计阶段必须分为概要设计阶段和详细设计阶段两个阶段。 一般要完成的文件是结构设计说明、详细设计说明、测试计划的初稿。 在实现阶段，要完成源程序的编码、编译(或汇编)和调试，得到没有语法错误的程序列表，开始制作进展日报、周报和月报(是否需要日报和月报，取决于项目的重要性和规模)，用户手册在测试阶段，程序将被完全测试，创建的文档将被审查。 通常完成测试分析报告。 作为开发工作的结束，对生产的程序、文件、开发工作本身进行评价，最后制作项目开发的总结报告书。 开发团队必须在整个开发过程(即最初的5个阶段)中，按月制作开发进展月报。 在运行和维护阶段，软件