1、冯惠,GB/T 8567-2006 计算机软件文档编制规范,目次,1 修订背景 修订依据 新老版本的差异 新版标准结构 文档编制过程 文档编制要求 文档编制格式 小结,一、本标准修订的背景,版是参考英国某公司的文档标准，结合当时国内软件开发的经验，而且主要是针对瀑布模型的开发方法而制定的。该标准的发布与实施对我国上世纪八十年代、九十年代的软件开发发挥了重要作用。但随着时间的推移，软件工程技术的发展与提高，目前来看，版已经不适应软件产业发展的需要，因此修订版势在必行。,二、GB/T8567-2006制定的依据,主要依据： 信息技术 软件生存周期过程 软件开发与文档编制 ： 信息技术 软件用户文档
2、过程,三、新老版本的主要差异,主要适用于瀑布模型开发方法 给出了种文档的编制格式要求：）可行性研究报告）项目开发计划）软件需求说明书,新老版本的主要差异,）数据要求说明书 ）概要设计说明书 ）详细设计说明书 ）数据库设计说明书 ）用户手册 ）操作手册 ）模块开发卷宗 ）测试计划 ）测试分析报告 ）开发进度月报 ）项目开发总结报告,新老版本的主要差异,6原则上适用于各种类型的开发方法 6描述了文档编制过程 6给出种文档的编制格式要求）可行性分析（研究）报告）软件开发计划）软件测试计划）软件安装计划,新老版本的主要差异,）软件移交计划）运行概念说明）系统子系统需求规格说明）接口需求规格说明）系统子
3、系统设计（结构设计）说明 ）接口设计说明 ）软件需求规格说明 ）数据需求说明 ）软件（结构）设计说明,新老版本的主要差异,）数据库（顶层）设计说明 ）软件测试说明 ）软件测试报告 ）软件配置管理计划 ）软件质量保证计划 ）开发进度月报 ）项目开发总结报告,新老版本的主要差异,）软件产品规格说明 ）软件版本说明 ）软件用户手册 ）计算机操作手册 ）计算机编程手册 另外给出了面向对象的种文档的编制格式要求,四、6标准结构,、范围 、规范性引用文件 、术语和定义 、缩略语 、文档（编制）过程 、文档编制要求 、文档编制格式 附录 面向对象软件的文档编制,五、文档（编制）过程 5.1 概述,有两种主要
4、类型的标准：a. 产品标准，它规定产品的特征和功能需求；b. 过程标准，它规定开发产品的过程。应用程序和计算机软件的复杂性日益增加，使得给使用计算机的用户提供完整的、正确的和易懂的文档的需要更加迫切。本标准通过规定影响软件文档的质量的活动（做什么和由谁做），提供达到这些目的的工具。,文档常常是关心在软件已经实现后做些什么。然而，为了质量，软件文档编制应作为整个软件生产过程的一部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。本标准的主要活动之一是建立开发文档的广泛计划。这是必须的，因为有计划，文档编制的质量会更好，过程的效率会更高。为遵循本标准，计划必须包括风
5、格规格说明。本标准不规定风格规格说明的内容（即不规定具体的布局和字体），但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对于文档管理者是可用的和谁做评审和再生产文档。,5.2 文档（编制）过程的关注点,文档编制计划 文档开发（编制） 文档评审,5.3 文档计划,5.3.1 概要文档管理者应准备一文档计划，此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意，以预示它完全覆盖了需方的要求。l 文档计划通常将覆盖整个文档系列。文档计划应正式地描述计划的文档的范围和限制，以及重要的文档分析和设计决定。也应规定在文档开发期间实现的过程和控制。,文档计划应包括（但不限于）以下内容：a）计
6、划的文档的工作名称、目的、范围和限制。b）文档的预定的读者，和使用的目的。c）文档内容的草案表，带有估计的页数和其他媒体的等效细节。d）交付：打印副本数，是否提供电子副本，磁盘和文件格式（包括软件版本）和在何处交付。e）版权的拥有者和任何其他所有权。l 这是复杂的问题，应在合同中规定。,f）适当处，包括每个文档的安全或机密级。g）管理文档开发过程的步骤和控制，包括存储、检索、后备、处理和质量保证（若要求）。h）所用的生产方法、工具和工具版本。i）文档开发人员所在的队伍的结构，任选地，包括队伍选择计划。l 在文档编写和生产的不同阶段中的工作人员，需要不同的技巧。编写人员可能要求对正在编写的系统有
7、好的知识加上写文档的经验；编辑人员可能要求有编辑经验而对系统知识无要求；版面艺术家可能对所用的版面工具外，无任何知识要求。,j）项目依赖。k）所要求的人时和成本。l）项目资源需求，包括需方提供的信息和其他资源。m）在软件开发期间，软件变更传送信息给文档管理者的方法。n）文档的变更控制和维护的计划（任选）。o）实现后评审的计划（任选）。,p）显示适当的里程碑的时间表，包括：1）文档计划批准； 对于文档的每一项应重复。l 文档计划宜2）每个草案的准备、评审和改正；3）可用性测试；4）打印、装订和发布。若适当，这些活动的每一个在文档的开发开始以前准备与批准，以保证所有部门同意目标和所用的方法。批准后
8、，计划宜尽可能广泛地分发；分发宜包括所有文档开发人员和可能包括需方人员及子合同方。,5.3.2 文档计划控制在正式同意后，文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清单。若以后文档计划变更了（得到文档管理者和需方的同意），文档管理者应保证所有得到文档计划副本的人员，应得到变更通知。l 因为，计划的过时的副本可能引起问题，文档管理者宜禁止计划的未控制的副本并制订计划的所有副本已经更新的审核过程。,5.4 文档开发,按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式（风格）。在软件的开发和管理过程中需要那些文档，每种文档的规范在下面说明。,5.5
9、 评审,5.5.1 概述本节规定文档评审的要求和相关活动。本节主要以用户文档的评审为例说明。对于开发文档的评审，由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。不是要追求形式。,用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。l 评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。 l 需方宜限止评审人员数为评审功能所必需的那些。需方在批准每个用户文档草案之前，应保证文档的安全和合法。为评审交付的文档应包括从文档管理者来的说明书，说
10、明评审的目的和评审员的职责。,l 注1：在需方和文档管理者之间在整个开发过程期间维持良好的通信会提高文档的质量并利于评审成功。这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。l 注2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。l 注3：评审过程不免除文档管理者，他们的责任是试图尽可能保证文档的精确和完整。l 注4：从评审的结果而来的需方的评论结果宜用或是加上标记的草案或用有适当的参考的方式写评论。需方宜保持变更的副本为了与下一草案相比较。评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。l 注5：对于大的、复杂的系统或正在写文档时系统仍在开发，可能需要多于
11、两次草案和一次校样。在这样情况下，最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。,5.5.2 文档计划评审此评审的目的应保证文档计划定义的文档，当完成时，既满足开发过程的需要也满足需方在合同中规定的的文档目标。需方同意文档计划，是同意在计划中定义的用户文档的所有可交付的特征。l 注：需方宜放注意至在内容的草案表中展示的文档的结构、完整性和可用性。只要适当，文档计划宜在第一个草案开始工作之前评审和批准。,5.5.3 第一个草案评审第一个草案应包含如在文档计划中描述的文档主体，加上内容表，附录和词汇。在使用自动索引工具处，生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描
12、述的。文档的第一个草案的评审目的是核查文档的技术正确性和完整性，以保证草案满足文档计划的目标。标点符号、风格和版面应如在文档计划中定义的。,在批准第一个草案中，除了要求的变更外，评审批准技术正确性、结构清楚性和文档的完整性。l 注1：第一个草案宜在交付前编辑。这有两个理由：a）这保证评审者不分心于改正印刷的和版面的错误；b）保证由编辑过程引起的任何技术错误被评审者捕获。l 注2：草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一个草案返回前，宜确认，若草案完全改正了，将满足文档计划的要求。,5.5.4 第二个草案评审第二个草案应包在第一个草案评审中同意的所有
13、变更且应以尽可能接近最后的形式包括在文档计划中定义的可交付的内容。此评审的目的是核查在第一个草案中的内容已经正确实现。在第二个草案的批准中，除了草案的物理形式外，批准文档的所有方面。草案的物理形式可能与可交付的不精确相同。l 注：在批准第二个草案前，宜确认草案（包含评审对草案的评论）已经准备好批准。,六、文档编制要求,6.1 软件生存周期与各种文档的编制,在计算机软件的生存周期中，一般地说，应该产生以下一些基本文档。可行性分析（研究）报告；软件（或项目）开发计划；软件需求规格说明；接口需求规格说明； 系统子系统设计（结构设计）说明；软件（结构）设计说明；,接口设计说明； 数据库（顶层）设计说明
14、；（软件）用户手册；操作手册；测试计划；测试报告；,软件配置管理计划；软件质量保证计划；开发进度月报；项目开发总结报告；软件产品规格说明；软件版本说明等。,本标准将给出这些文档的编制规范，同时，本标准也是这些文档的编写质量的检验准则。一般地说，一个软件总是一个计算机系统（包括硬件，固件和软件）的组成部分。鉴于计算机系统的多样性，本标准一般不涉及整个系统开发中的文档编制问题，本标准仅仅是软件开发过程中的文档编制指南。对于使用文档的人员而言他们所关心的文件的种类随他们所承担的工作而异。,管理人员：可行性分析（研究）报告，项目开发计划，软件配置管理计划，软件质量保证计划，开发进度月报，项目开发总结报
15、告；,开发人员：可行性分析（研究）报告，项目开发计划，软件需求规格说明，接口需求规格说明，软件（结构）设计说明，接口设计说明书，数据库（顶层）设计说明，测试计划，测试报告；,维护人员：软件需求规格说明，接口需求规格说明，软件（结构）设计说明，测试报告，,用 户：软件产品规格说明，软件版本说明，用户手册，操作手册。本标准规定了在软件开发过程中文档编制的要求，这些文档从使用的角度可分为用户文档和开发文档两大类。其中，用户文档必须交给用户。用户应该得到的文档的种类和规模由供应者与用户之间签订的合同规定。,如前所述，软件，从出现一个构思之日起，经过软件开发成功投入使用，直到最后决定停止使用并被另一项软
16、件代替之时止，被认为是该软件的一个生存周期，一般地说这个软件生存周期可以分成以下六个阶段：,可行性与计划研究阶段；需求分析阶段；设计阶段；实现阶段；测试阶段；运行与维护阶段。,在可行性分析（研究）与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文档。在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明（也称为：软件需求说明、软件规格说明）、数据要求说明和初步的用户手册应该编写出来。,在设计阶段内，系统设计人员和程序
17、设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块（或CSCI）的划分、功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：结构设计说明、详细设计说明和测试计划初稿。,在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写进度日报、周报和月报（是否要有日报或周报，取决于项目的重要性和规模），并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。在测试阶段：该程序
18、将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。,在整个开发过程中（即前五个阶段中），开发团队要按月编写开发进度月报。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。,6.2 文档编制中的考虑因素,文档编制是开发过程的有机组成部分，也是一个不断努力的工作过程。是一个从形成最初轮廓、经反复检查和修改，直至程序和文档正式交付使用的完整过程。其中每一步都要求工作人员做出很大努力。要保证文档编制的质量，要体现每个开发项目的特点，也要
19、注意不要花太多的人力。为此编制中要考虑如下各项因素。,6.2.1 文档的读者每一种文档都具有特定的读者。这些读者包括个人或小组、软件开发单位的成员或社会上的公众、从事软件工作的技术人员、管理人员或领导干部。他们期待着使用这些文档的内容来进行工作，例如设计、编写程序、测试、使用、维护或进行计划管理。因此这些文档的作者必须了解自己的读者。这些文档的编写必须注意适应自己的特定读者的水平、特点和要求。,6.2.2 重复性本规范中列出的文档编制规范的内容要求中，显然存在某些重复。较明显的重复有两类。引言是每一种文档都要包含的内容，以向读者提供总的梗概.第二类明显的重复是各种文档中的说明部分，如对功能性能
20、的说明；对输入、输出的描述；系统中包含的设备等。这是为了方便每种文档各自的读者，每种文档应该自成体系，尽量避免读一种文档时又不得不去参考另一种文档。当然，在每一种文档里，有关引言、说明等同其他文档相重复的部分，在行文上、在所用的术语上、在详细的程度上，还是应该有一些差别以适应各种文档的不同读者的需要。,6.2.3 灵活性鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，本规范认为在文档编制工作中应允许一定的灵活性。这种灵活性表现在如下各款。,a. 应编制的文档种类尽管本规范认为在一般情况下，一项软件的开发过程中，应产生如上所述的各种文档，然而针对一项具体的软件开发
21、项目，有时不必编制这么多的文档，可以把几种文档合并成一种。一般地说，当项目的规模、复杂性和失败风险增大时，文档编制的范围，管理手续和详细程度将随之增加，反之，则可适当减少。为了恰当地掌握这种灵活性，本规范要求贯彻分工负责的原则，这意味着：,1） 一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定，主要是：在不同的条件下，应该形成哪些文档？这些文档的详细程度？该开发单位的每一个项目负责人，必须认真执行这个实施规定。,2） 对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划（可以包含在软件开发计划中）
22、，其中包括：,（1） 应该编制哪几种文档，详细程度如何？(2) 各个文档的编制负责人和进度要求；(3) 审查、批准的负责人和时间进度安排 (4) 在开发时间内，各文档的维护、修改和 管理的负责人，以及批准手续。每项工作必须落实到人。这个文件编制计划是整个开发计划的重要组成部份。3） 有关的设计人员则必须严格执行这个文档编制计划。,b. 文档的详细程度从同一份提纲起草的文件的篇幅大小往往不同，可以少到几页，也可以长达几百页。对于这种差别，本规范是允许的。此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行环境所需要的详细程度的判断。,c. 文档的扩展当被开发系统的规模非常大例如
23、源码超过一百万行时，一种文档可以分成几卷编写，可以按其中每一个系统分别编制；也可以按内容划分成多卷，例如：项目开发计划可能包括：质量保证计划，配置管理计划，用户培训计划，安装实施计划；,系统设计说明可分写成：系统设计说明，子系统设计说明；程序设计说明可分写成：程序设计说明，接口设计说明，版本说明；,操作手册可分写成：操作手册，安装实施过程；测试计划可分写成：测试计划，测试设计说明，测试规程，测试用例；,测试分析报告可分写成：综合测试报告，验收测试报告；项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。,d. 节的扩张与缩并在有些文档中，可以使用本规范所提供的章、条标题，有存在一系列需要
24、分别讨论的因素。本规范认为，所有的条都可以扩展，可以进一步细分，以适应实际需要。反之如果章条中的有些细节并非必需，也可以根据实际情况缩并。此时章条的编号应相应地变更。,e. 程序设计的表现形式本规范对于程序的设计表现形式并未作出规定或限制，可以使用流程图的形式，判定表的形式，也可以使用其他表现形式，如程序设计语言（PDL）、问题分析图（PALb）等。f. 文档的表现形式本规范对于文档的表现形式亦未作出规定或限制。可以使用自然语言，也可以使用形式化语言。也可以使用各件图、表。,七、文档编制格式,7.1 可行性分析（研究）报告（FAR）,说明：1. 可行性分析（研究）报告（FAR）它是项目初期策划
25、的结果，它分析了项目的要求、目标和环境；提出了几种可供选择的方案；并从技术、经济和法律各方面进行了可行性分析。可作为项目决策的依据。2. FAR也可以作为项目建议书、投标书等文件的基础。,1 引言本章分为以下几条。 1.1 标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。 1.2 背景说明项目在什么条件下提出，提出者的要求、目标、实现环境和限制条件。,1.3 项目概述本条应简述本文档适用的项目和软件的用途，它应描述项目和软件的一般特性；概述项目开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；
26、列出其它有关的文档。 1.4 文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。,2 引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。,3 可行性分析的前提3.1 项目的要求 3.2 项目的目标 3.3 项目的环境、条件、假定和限制 3.4 进行可行性分析的方法,4 可选的方案4.1 原有方案的优缺点、局限性及存在的问题 4.2 可重用的系统，与要求之间的差距 4.3 可选择的系统方案1 4.4 可选择的系统方案2 4.5 选择最终方案的准则。,5 所建议的系统5.1 对所建议的系统的说明
27、 5.2 数据流程和处理流程 5.3 与原系统的比较（若有原系统）,5.4 影响（或要求） 5.4.1 设备 5.4.2 软件 5.4.3 运行 5.4.4 开发 5.4.5 环境 5.4.6 经费 5.5 局限性,6 经济可行性（成本效益分析）6.1 投资：包括基本建设投资（如开发环境、设备、软件和资料等），其他一次性和非一次性投资（如技术管理费、培训费、管理费、人员工资、奖金和差旅费等）。,6.2 预期的经济效益 6.2.1 一次性收益 6.2.2 非一次性收益 6.2.3 不可定量的收益 6.2.4 收益投资比 6.2.5 投资回收周期 6.3 市场预测,7 技术可行性（技术风险评价）本
28、公司现有资源（如人员、环境、设备和技术条件等）能否满足此工程和项目实施要求，若不满足，应考虑补救措施（如需要分承包方参与、增加人员、投资和设备等），涉及经济问题应进行投资、成本和效益可行性分析，最后确定此工程和项目是否具备技术可行性。8 法律可行性系统开发可能导致的侵权、违法和责任。,9 用户使用可行性用户单位的行政管理和工作制度；使用人员的素质和培训要求。10 其它与项目有关的问题未来可能的变化。,11 注解本章应包含有助于理解本文档的一般信息（例如原理）。本章应包含为理解本文档需要的术语和定义，并给出解释；所有缩略词语和它们在文档中的含义的字母序列表。 附录 附录可用来提供那些为便于文档维
29、护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。,7.2 软件开发计划（SDP）,说明：1. 软件开发计划（SDP）描述开发者实施软件开发工作的计划，本文档中”软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其它所有的活动。2. SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。3. 本计划的某些部分可视实际需要单独编制成册，例如，软件配置管理计划、软件质量保证计划和文档编制计划等。,1 引言本章分为以下几条
30、。 1.1 标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。 1.2 系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其它有关的文档。,1.3 文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。 1.4 与其它计划之间的关系（若有）本条描述本计划和其它项目管理计划的关系。 1.5 基线给出编写本项目开发计划的输入基线，如软件需求规格说明。,2 引用文档本章应列出本文档引用的
31、所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。,3 交付产品3.1 程序 3.2 文档 3.3 服务 3.4 非移交产品 3.5 验收标准 3.6 最后交付期限列出本项目应交付的产品，包括软件产品和文档。其中，软件产品应指明哪些是要开发的，哪些是属于维护性质的；文档是指随软件产品交付给用户的技术文档，例如用户手册、安装手册等。,4 所需工作概述本章根据需要分条对后续章描述的计划作出说明，（若适用）包括以下概述：a. 对所要开发系统、软件的需求和约束；b. 对项目文档编制的需求和约束；c. 该项目在系统生命周期中所处的地位；d. 所选用的计划/采购
32、策略或对它们的需求和约束；e. 项目进度安排及资源的需求和约束；f. 其它的需求和约束，如：项目的安全性、保密性、私密性、方法、标准、硬件开发和软件开发的相互依赖关系等。,5 实施整个软件开发活动的计划本章分以下几条。不需要的活动的条款用”不适用”注明，如果对项目中不同的开发阶段或不同的软件需要不同的计划，这些不同之处应在此条加以注解。除以下规定的内容外，每条中还应标识可适用的风险和不确定因素，和处理它们的计划。,5.1 软件开发过程本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段（适用的话）、目标、和各阶段要执行的软件开发活动。 5.2 软件开发总体计划本
33、条应分以下若干条进行描述。,5.2.1 软件开发方法本条应描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描述。该方法应覆盖论及它的所有合同条款。如果这些方法在它们所适用的活动范围有更好的描述，可引用本计划的其它条。,5.2.2 软件产品标准本条应描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准。标准应覆盖合同中论及它的所有条款。如果这些标准在标准所适用的活动范围有更好的描述，可引用在本计划中的其它条。对要使用的各种编程语言都应提供编码标准，至少应包括：,a. 格式标准（如：缩进、空格、大小写和信息的排序）；b. 首部注释标准，例如
34、（要求：代码的名称/标识符，版本标识，修改历史，用途）需求和实现的设计决策，处理的注记（例如：使用的算法、假设、约束、限制和副作用），数据注记（输入、输出、变量和数据结构等）；c. 其它注释标准（例如要求的数量和预期的内容）；d. 变量、参数、程序包、过程和文档等的命名约定；e.（若有）编程语言构造或功能的使用限制；f. 代码聚合复杂性的制约。,5.2.3 可重用的软件产品本条应分以下若干条。 5.2.3.1 吸纳可重用的软件产品本条应描述标识、评估和吸纳可重用软件产品要遵循的方法，包括搜寻这些产品的范围和进行评估的准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对己选定的或候选的可
35、重用的软件产品应加以标识和说明，（若适用）同时应给出与使用有关的优点、缺陷和限制。,5.2.3.2 开发可重用的软件产品本条应描述如何标识、评估和报告开发可重用软件产品的机会。描述应覆盖合同中论及它的所有条款。,5.2.4 处理关键性需求本条应分以下若干条描述为处理指定关键性需求应遵循的方法。描述应覆盖合同中论及它的所有条款。5.2.4.1 安全性保证5.2.4.2 保密性保证5.2.4.3 私密性保证5.2.4.4 其它关键性需求保证,5.2.5 计算机硬件资源利用本条应描述分配计算机硬件资源和监控其使用情况要遵循的方法。描述应覆盖合同中论及它的所有条款。 5.2.6 记录原理本条应描述记录
36、原理所遵循的方法，该原理在支持机构对项目作出关键决策时是有用的。应对项目的”关键决策”一词作出解释，并陈述原理记录在什么地方。描述应覆盖合同中论及它的所有条款。,5.2.7 需方评审途径本条应描述为评审软件产品和活动，让需方或授权代表访问开发方和分承制方的一些设施要遵循的方法。描述应遵循合同中论及它的所有条款。,6 实施详细软件开发活动的计划本章分条进行描述。不需要的活动用”不适用”注明，如果项目的不同的开发阶段或不同的软件需要不同的计划，则在本条应指出这些差异。每项活动的论述应包括应用于以下方面的途径（方法/过程/工具）：1）所涉及的分析性任务或其它技术性任务：2）结果的记录：3）与交付有关
37、的准备（如果有的话）。论述还应标识存在的风险和不确定因素，及处理它们的计划。如果适用的方法在5.2.1处描述了的话，可引用它。,6.1 项目计划和监督本条分成若干分条描述项目计划和监督中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.1.1 软件开发计划（包括对该计划的更新）6.1.2 CSCI测试计划6.1.3 系统测试计划6.1.4 软件安装计划6.1.5 软件移交计划6.1.6 跟踪和更新计划，包括评审管理的时间间隔,6.2 建立软件开发环境本条分成以下若干分条描述建立、控制、维护软件开发环境所遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.2.1 软件工程环境6.
38、2.2 软件测试环境6.2.3 软件开发库6.2.4 软件开发文档6.2.5 非交付软件,6.3 系统需求分析6.3.1 用户输入分析6.3.2 运行概念6.3.3 系统需求 6.4 系统设计6.4.1 系统级设计决策6.4.2 系统体系结构设计,6.5 软件需求分忻本条描述软件需求分析中要遵循的方法。应覆盖合同中论及它的所有条款。 6.6 软件设计本条应分成若干分条描述软件设计中所遵循的方法.各分条的计划应覆盖合同中论及它的所有条款。6.6.1 CSCI级设计决策6.6.2 CSCI体系结构设计6.6.3 CSCI详细设计,6.7 软件实现和配置项测试本条应分成若干分条描述软件实现配置项测试
39、中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.7.1 软件实现6.7.2 配置项测试准备6.7.3 配置项测试执行6.7.4 修改和再测试6.7.5 配置项测试结果分析与记录,6.8 配置项集成和测试本条应分成若干分条描述配置项集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.8.1 配置项集成和测试准备6.8.2 配置项集成和测试执行6.8.3 修改和再测试6.8.4 配置项集成和测试结果分析与记录,6.9 CSCI合格性测试本条应分成若干分条描述CSCI合格性测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.9.1 CSCI合格性测试的
40、独立性6.9.2 在目标计算机系统（或模拟的环境）上测试6.9.3 CSCI合格性测试准备6.9.4 CSCI合格性测试演练6.9.5 CSCI合格性测试执行6.9.6 修改和再测试6.9.7 CSCI合格性测试结果分析与记录,6.10 CSCI/HWCI集成和测试本条应分成若干分条描述CSCI/HWCI集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.10.1 CSCI/HWCI集成和测试准备6.10.2 CSCI/HWCI集成和测试执行6.10.3 修改和再测试6.10.4 CSCI/HWCI集成和测试结果分析与记录,6.11 系统合格性测试本条应分成若干分条描述系统
41、合格性测试中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.11.1 系统合格性测试的独立性6.11.2 在目标计算机系统（或模拟的环境）上测试6.11.3 系统合格性测试准备6.11.4 系统合格性测试演练6.11.5 系统合格性测试执行6.11.6 修改和再测试6.11.7 系统合格性测试结果分析与记录,6.12 软件使用准备本条应分成若干分条描述软件应用准备中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.12.1 可执行软件的准备6.12.2 用户现场的版本说明的准备6.12.3 用户手册的准备6.12.4 在用户现场安装,6.13 软件移交准备本条应分成若干分
42、条描述软件移交准备要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.13.1 可执行软件的准备6.13.2 源文件准备6.13.3 支持现场的版本说明的准备6.13.4 “已完成”的CSCI设计和其它的软件支持信息的准备6.13.5 系统设计说明的更新6.13.6 支持手册准备6.13.7 到指定支持现场的移交,6.14 软件配置管理本条应分成若干分条描述软件配置管理中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。6.14.1 配置标识6.14.2 配置控制6.14.3 配置状态统计6.14.4 配置审核6.14.5 发行管理和交付,6.15 软件产品评估本条应分成若干分条
43、描述软件产品评估中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.15.1 中间阶段的和最终的软件产品评估6.15.2 软件产品评估记录（包括所记录的具体条目）6.15.3 软件产品评估的独立性,6.16 软件质量保证本条应分成若干分条描述软件质量保证中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.16.1 软件质量保证评估6.16.2 软件质量保证记录、包括所记录的具体条目6.16.3 软件质量保证的独立性,6.17 问题解决过程（更正活动）本条应分成若干分条描述软件更正活动中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。 6.17.1 问题/变更报告它包
44、括要记录的具体条目（可选的条目包括：项目名称，提出者，问题编号，问题名称，受影响的软件元素或文档，发生日期，类别和优先级，描述，指派的该问题的分析者，指派日期，完成日期，分析时间，推荐的解决方案，影响，问题状态，解决方案的批准，随后的动作，更正者，更正日期，被更正的版本，更正时间，己实现的解决方案的描述）。 6.17.2 更正活动系统,6.18 联合评审（联合技术评审和联合管理评审）本条应分成若干分条描述进行联合技术评审和联合管理评审要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.18.1 联合技术评审包括一组建议的评审6.18.2 联合管理评审包括一组建议的评审,6.19 文档编
45、制本条应分成若干分条描述文档编制要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。应遵循本标准第5章文档编制过程中的有关文档编制计划的规定执行。,6.20 其它软件开发活动本条应分成若干分条描述进行其它软件开发活动要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.20.1 风险管理，包括己知的风险和相应的对策6.20.2 软件管理指标，包括要使用的指标6.20.3 保密性和私密性,6.20.4 分承制方管理6.20.5 与软件独立验证与确认（IV&V）机构的接口6.20.6 和有关开发方的协调6.20.7 项目过程的改进6.20.8 计划中未提及的其它活动,7 进度表和活动网络
46、图本章应给出：a. 进度表，标识每个开发阶段中的活动，给出每个活动的初始点、提交的草稿和最终结果的可用性，和其它的里程碑及每个活动的完成点；b. 活动网络图，描述项目活动之间的顺序关系和依赖关系，标出完成项目中有最严格时间限制的活动。,8 项目组织和资源本章应分成若干分条描述各阶段要使用的项目组织和资源。 8.1 项目组织本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。,8.2 项目资源本条应描述适用于本项目的资源。（若适用）应包括：a.人力资源，包括；1）估计此项目应投入的人力（人员/时间数）；2）按职责（如：管理，软件工程，软件测试
47、，软件配置管理，软件产品评估，软件质量保证和软件文档编制等）分解所投入的人力；3）履行每个职责人员的技术级别、地理位置和涉密程度的划分；,b. 开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其它特性；c. 为满足合同需要，需方应提高的设备、软件、服务、文档、资料及设施，给出一张何时需要上述各项的进度表；d. 其它所需的资源，包括：获得资源的计划、需要的日期和每项资源的可用性。,9 培训9.1 项目的技术要求根据客户需求和项目策划结果，确定本项目的技术要求，包括管理技术和开发技术。 9.2 培训计划根据项目的技术要求和项目成员的情况，确定是否需要进行项
48、目培训，并制订培训计划。如不需要培训，应说明理由。,10 项目估算说明项目估算的结果。10.1 规模估算10.2 工作量估算10.3 成本估算10.4 关键计算机资源估算10.5 管理预留,11 风险管理分析可能存在的风险，所采取的对策和风险管理计划。12 支持条件12.1 计算机系统支持。12.2 需要需方承担的工作和提供的条件。12.3 需要分包商承担的工作和提供的条件。,13 注解本章应包含有助于理解本文档的一般信息（例如原理）。本章应包含为理解本文档需要的术语和定义并给出解释，所有缩略词语和它们在文档中的含义的字母序列表。 附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表
49、、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。,7.11 软件需求规格说明（SRS）,说明：1. 软件需求规格说明（SRS）描述对计算机软件配置项CSCI的需求，及确保每个要求得以满足的所使用的方法.涉及该CSCI外部接口的需求可在本SRS中给出：或在本SRS引用的一个或多个接口需求规格说明（IRS）中给出。2. 这个SRS，可能还要用IRS加以补充，是CSCI设计与合格性测试的基础。,1 范围本章应分为以下几条。 1.1 标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。 1.2 系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其它有关的文档。,
