计算机软件文档编制规范

'冯惠GB/T8567-2006计算机软件文档编制规范 目次1修订背景２　修订依据３　新老版本的差异４　新版标准结构５　文档编制过程６　文档编制要求７　文档编制格式８　小结 一、本标准修订的背景ＧＢ／Ｔ８５６７－１９８８版是参考英国某公司的文档标准，结合当时国内软件开发的经验，而且主要是针对瀑布模型的开发方法而制定的。该标准的发布与实施对我国上世纪八十年代、九十年代的软件开发发挥了重要作用。但随着时间的推移，软件工程技术的发展与提高，目前来看，８８版已经不适应软件产业发展的需要，因此修订ＧＢ／Ｔ８５６６－１９８８版势在必行。 二、GB/T8567-2006制定的依据主要依据：ＧＢ／Ｔ８５６６－２００１　信息技术　软件生存周期过程ＳＪ／Ｔ２０７７８－２０００　软件开发与文档编制ＩＳＯ／ＩＥＣ１５９１０：１９９９　信息技术　软件用户文档过程 三、ＧＢ／Ｔ８５６７新老版本的主要差异ＧＢ／Ｔ８５６７－１９８８主要适用于瀑布模型开发方法ＧＢ／Ｔ８５６７－１９８８给出了１４种文档的编制格式要求：１）可行性研究报告２）项目开发计划３）软件需求说明书 ＧＢ／Ｔ８５６７新老版本的主要差异４）数据要求说明书５）概要设计说明书６）详细设计说明书７）数据库设计说明书８）用户手册９）操作手册１０）模块开发卷宗１１）测试计划１２）测试分析报告１３）开发进度月报１４）项目开发总结报告 ＧＢ／Ｔ８５６７新老版本的主要差异ＧＢ／Ｔ８５６７－２００6原则上适用于各种类型的开发方法ＧＢ／Ｔ８５６７－２００6描述了文档编制过程ＧＢ／Ｔ８５６７－２００6给出２５种文档的编制格式要求１）可行性分析（研究）报告２）软件开发计划３）软件测试计划４）软件安装计划 ＧＢ／Ｔ８５６７新老版本的主要差异５）软件移交计划６）运行概念说明７）系统／子系统需求规格说明８）接口需求规格说明９）系统／子系统设计（结构设计）说明１０）接口设计说明１１）软件需求规格说明１２）数据需求说明１３）软件（结构）设计说明 ＧＢ／Ｔ８５６７新老版本的主要差异１４）数据库（顶层）设计说明１５）软件测试说明１６）软件测试报告１７）软件配置管理计划１８）软件质量保证计划１９）开发进度月报２０）项目开发总结报告 ＧＢ／Ｔ８５６７新老版本的主要差异２１）软件产品规格说明２２）软件版本说明２３）软件用户手册２４）计算机操作手册２５）计算机编程手册另外给出了面向对象的１０种文档的编制格式要求 四、ＧＢ／Ｔ８５６７－２００6标准结构１、范围２、规范性引用文件３、术语和定义４、缩略语５、文档（编制）过程６、文档编制要求７、文档编制格式附录Ａ　面向对象软件的文档编制 五、文档（编制）过程5.1概述有两种主要类型的标准：a.产品标准，它规定产品的特征和功能需求；b.过程标准，它规定开发产品的过程。应用程序和计算机软件的复杂性日益增加，使得给使用计算机的用户提供完整的、正确的和易懂的文档的需要更加迫切。本标准通过规定影响软件文档的质量的活动（做什么和由谁做），提供达到这些目的的工具。 文档常常是关心在软件已经实现后做些什么。然而，为了质量，软件文档编制应作为整个软件生产过程的一部分。过程计划应把文档计划包括在内。本标准也给用户和客户提供工具以保证文档过程实施。本标准的主要活动之一是建立开发文档的广泛计划。这是必须的，因为有计划，文档编制的质量会更好，过程的效率会更高。为遵循本标准，计划必须包括风格规格说明。本标准不规定风格规格说明的内容（即不规定具体的布局和字体），但它规定风格规格说明必须覆盖什么。本标准也规定何种信息对于文档管理者是可用的和谁做评审和再生产文档。 5.2文档（编制）过程的关注点文档编制计划文档开发（编制）文档评审 5.3文档计划5.3.1概要文档管理者应准备一文档计划，此计划规定在文档创建中要执行的工作。此文档计划应经需方正式同意，以预示它完全覆盖了需方的要求。l文档计划通常将覆盖整个文档系列。文档计划应正式地描述计划的文档的范围和限制，以及重要的文档分析和设计决定。也应规定在文档开发期间实现的过程和控制。 文档计划应包括（但不限于）以下内容：a）计划的文档的工作名称、目的、范围和限制。b）文档的预定的读者，和使用的目的。c）文档内容的草案表，带有估计的页数和其他媒体的等效细节。d）交付：打印副本数，是否提供电子副本，磁盘和文件格式（包括软件版本）和在何处交付。e）版权的拥有者和任何其他所有权。l这是复杂的问题，应在合同中规定。 f）适当处，包括每个文档的安全或机密级。g）管理文档开发过程的步骤和控制，包括存储、检索、后备、处理和质量保证（若要求）。h）所用的生产方法、工具和工具版本。i）文档开发人员所在的队伍的结构，任选地，包括队伍选择计划。l在文档编写和生产的不同阶段中的工作人员，需要不同的技巧。编写人员可能要求对正在编写的系统有好的知识加上写文档的经验；编辑人员可能要求有编辑经验而对系统知识无要求；版面艺术家可能对所用的版面工具外，无任何知识要求。 j）项目依赖。k）所要求的人时和成本。l）项目资源需求，包括需方提供的信息和其他资源。m）在软件开发期间，软件变更传送信息给文档管理者的方法。n）文档的变更控制和维护的计划（任选）。o）实现后评审的计划（任选）。 p）显示适当的里程碑的时间表，包括：1）文档计划批准；对于文档的每一项应重复。l文档计划宜2）每个草案的准备、评审和改正；3）可用性测试；4）打印、装订和发布。若适当，这些活动的每一个在文档的开发开始以前准备与批准，以保证所有部门同意目标和所用的方法。批准后，计划宜尽可能广泛地分发；分发宜包括所有文档开发人员和可能包括需方人员及子合同方。 5.3.2文档计划控制在正式同意后，文档管理者应控制文档计划和它的发布。文档管理者应保持一份文档计划副本的分发的清单。若以后文档计划变更了（得到文档管理者和需方的同意），文档管理者应保证所有得到文档计划副本的人员，应得到变更通知。l因为，计划的过时的副本可能引起问题，文档管理者宜禁止计划的未控制的副本并制订计划的所有副本已经更新的审核过程。 5.4文档开发按文档计划规定进行文档开发。通常，在进行文档开发前，要规定文档的格式（风格）。在软件的开发和管理过程中需要那些文档，每种文档的规范在下面说明。 5.5评审5.5.1概述本节规定文档评审的要求和相关活动。本节主要以用户文档的评审为例说明。对于开发文档的评审，由供方组织和实施。而批准由开发组织的上级技术机构实施。更要着重经常性的、非正式的注重实效的评审。不是要追求形式。 用户文档的评审应由需方实现，包括当需要时与文档管理者讨论。l评审的目的是保证提交的材料是完整的和正确的并满足了在合同和文档计划中定义的需方的需要。评审宜由合适的有资格的人员执行，这些人员被授权请求变更和批准文档的内容。l需方宜限止评审人员数为评审功能所必需的那些。需方在批准每个用户文档草案之前，应保证文档的安全和合法。为评审交付的文档应包括从文档管理者来的说明书，说明评审的目的和评审员的职责。 l注1：在需方和文档管理者之间在整个开发过程期间维持良好的通信会提高文档的质量并利于评审成功。这宜包括非正式的讨论和尽早地提供样板或初始材料给需方。l注2：在要求的变更超出了合同和文档计划的范围时，需要变更合同。l注3：评审过程不免除文档管理者，他们的责任是试图尽可能保证文档的精确和完整。l注4：从评审的结果而来的需方的评论结果宜用或是加上标记的草案或用有适当的参考的方式写评论。需方宜保持变更的副本为了与下一草案相比较。评论应使文档开发人员能实现所要求的变更而不需要评审人员的进一步解释。l注5：对于大的、复杂的系统或正在写文档时系统仍在开发，可能需要多于两次草案和一次校样。在这样情况下，最多的草案数宜在需方和文档管理者之间同意并在文档计划中规定。 5.5.2文档计划评审此评审的目的应保证文档计划定义的文档，当完成时，既满足开发过程的需要也满足需方在合同中规定的的文档目标。需方同意文档计划，是同意在计划中定义的用户文档的所有可交付的特征。l注：需方宜放注意至在内容的草案表中展示的文档的结构、完整性和可用性。只要适当，文档计划宜在第一个草案开始工作之前评审和批准。 5.5.3第一个草案评审第一个草案应包含如在文档计划中描述的文档主体，加上内容表，附录和词汇。在使用自动索引工具处，生成的索引包含位置参照。标点符号、风格和版面应如在文档计划中描述的。文档的第一个草案的评审目的是核查文档的技术正确性和完整性，以保证草案满足文档计划的目标。标点符号、风格和版面应如在文档计划中定义的。 在批准第一个草案中，除了要求的变更外，评审批准技术正确性、结构清楚性和文档的完整性。l注1：第一个草案宜在交付前编辑。这有两个理由：a）这保证评审者不分心于改正印刷的和版面的错误；b）保证由编辑过程引起的任何技术错误被评审者捕获。l注2：草案应针对在文档计划中批准的目标、读者定义、内容表和其他特征进行评审。在带有评论的第一个草案返回前，宜确认，若草案完全改正了，将满足文档计划的要求。 5.5.4第二个草案评审第二个草案应包在第一个草案评审中同意的所有变更且应以尽可能接近最后的形式包括在文档计划中定义的可交付的内容。此评审的目的是核查在第一个草案中的内容已经正确实现。在第二个草案的批准中，除了草案的物理形式外，批准文档的所有方面。草案的物理形式可能与可交付的不精确相同。l注：在批准第二个草案前，宜确认草案（包含评审对草案的评论）已经准备好批准。 六、文档编制要求 6.1软件生存周期与各种文档的编制在计算机软件的生存周期中，一般地说，应该产生以下一些基本文档。可行性分析（研究）报告；软件（或项目）开发计划；软件需求规格说明；接口需求规格说明；系统／子系统设计（结构设计）说明；软件（结构）设计说明； 接口设计说明；数据库（顶层）设计说明；（软件）用户手册；操作手册；测试计划；测试报告； 软件配置管理计划；软件质量保证计划；开发进度月报；项目开发总结报告；软件产品规格说明；软件版本说明等。 本标准将给出这些文档的编制规范，同时，本标准也是这些文档的编写质量的检验准则。一般地说，一个软件总是一个计算机系统（包括硬件，固件和软件）的组成部分。鉴于计算机系统的多样性，本标准一般不涉及整个系统开发中的文档编制问题，本标准仅仅是软件开发过程中的文档编制指南。对于使用文档的人员而言他们所关心的文件的种类随他们所承担的工作而异。 管理人员：可行性分析（研究）报告，项目开发计划，软件配置管理计划，软件质量保证计划，开发进度月报，项目开发总结报告； 开发人员：可行性分析（研究）报告，项目开发计划，软件需求规格说明，接口需求规格说明，软件（结构）设计说明，接口设计说明书，数据库（顶层）设计说明，测试计划，测试报告； 维护人员：软件需求规格说明，接口需求规格说明，软件（结构）设计说明，测试报告， 用户：软件产品规格说明，软件版本说明，用户手册，操作手册。本标准规定了在软件开发过程中文档编制的要求，这些文档从使用的角度可分为用户文档和开发文档两大类。其中，用户文档必须交给用户。用户应该得到的文档的种类和规模由供应者与用户之间签订的合同规定。 如前所述，软件，从出现一个构思之日起，经过软件开发成功投入使用，直到最后决定停止使用并被另一项软件代替之时止，被认为是该软件的一个生存周期，一般地说这个软件生存周期可以分成以下六个阶段： 可行性与计划研究阶段；需求分析阶段；设计阶段；实现阶段；测试阶段；运行与维护阶段。 在可行性分析（研究）与计划阶段内，要确定该软件的开发目标和总的要求，要进行可行性分析、投资一收益分析、制订开发计划，并完成应编制的文档。在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定对该软件的各项功能、性能需求和设计约束，确定对文档编制的要求，作为本阶段工作的结果，一般地说软件需求规格说明（也称为：软件需求说明、软件规格说明）、数据要求说明和初步的用户手册应该编写出来。 在设计阶段内，系统设计人员和程序设计人员应该在反复理解软件需求的基础上，提出多个设计，分析每个设计能履行的功能并进行相互比较，最后确定一个设计，包括该软件的结构、模块（或CSCI）的划分、功能的分配，以及处理流程。在被设计系统比较复杂的情况下，设计阶段应分解成概要设计阶段和详细设计阶段两个步骤。在一般情况下，应完成的文档包括：结构设计说明、详细设计说明和测试计划初稿。 在实现阶段内，要完成源程序的编码、编译（或汇编）和排错调试得到无语法错的程序清单，要开始编写进度日报、周报和月报（是否要有日报或周报，取决于项目的重要性和规模），并且要完成用户手册、操作手册等面向用户的文档的编写工作，还要完成测试计划的编制。在测试阶段：该程序将被全面地测试，已编制的文档将被检查审阅。一般要完成测试分析报告。作为开发工作的结束，所生产的程序、文档以及开发工作本身将逐项被评价，最后写出项目开发总结报告。 在整个开发过程中（即前五个阶段中），开发团队要按月编写开发进度月报。在运行和维护阶段，软件将在运行使用中不断地被维护，根据新提出的需求进行必要而且可能的扩充和删改、更新和升级。 6.2文档编制中的考虑因素文档编制是开发过程的有机组成部分，也是一个不断努力的工作过程。是一个从形成最初轮廓、经反复检查和修改，直至程序和文档正式交付使用的完整过程。其中每一步都要求工作人员做出很大努力。要保证文档编制的质量，要体现每个开发项目的特点，也要注意不要花太多的人力。为此编制中要考虑如下各项因素。 6.2.1文档的读者每一种文档都具有特定的读者。这些读者包括个人或小组、软件开发单位的成员或社会上的公众、从事软件工作的技术人员、管理人员或领导干部。他们期待着使用这些文档的内容来进行工作，例如设计、编写程序、测试、使用、维护或进行计划管理。因此这些文档的作者必须了解自己的读者。这些文档的编写必须注意适应自己的特定读者的水平、特点和要求。 6.2.2重复性本规范中列出的文档编制规范的内容要求中，显然存在某些重复。较明显的重复有两类。引言是每一种文档都要包含的内容，以向读者提供总的梗概.第二类明显的重复是各种文档中的说明部分，如对功能性能的说明；对输入、输出的描述；系统中包含的设备等。这是为了方便每种文档各自的读者，每种文档应该自成体系，尽量避免读一种文档时又不得不去参考另一种文档。当然，在每一种文档里，有关引言、说明等同其他文档相重复的部分，在行文上、在所用的术语上、在详细的程度上，还是应该有一些差别以适应各种文档的不同读者的需要。 6.2.3灵活性鉴于软件开发是具有创造性的脑力劳动，也鉴于不同软件在规模上和复杂程度上差别极大，本规范认为在文档编制工作中应允许一定的灵活性。这种灵活性表现在如下各款。 a.应编制的文档种类尽管本规范认为在一般情况下，一项软件的开发过程中，应产生如上所述的各种文档，然而针对一项具体的软件开发项目，有时不必编制这么多的文档，可以把几种文档合并成一种。一般地说，当项目的规模、复杂性和失败风险增大时，文档编制的范围，管理手续和详细程度将随之增加，反之，则可适当减少。为了恰当地掌握这种灵活性，本规范要求贯彻分工负责的原则，这意味着： 1）一个软件开发单位的领导机构应该根据本单位经营承包的应用软件的专业领域和本单位的管理能力，制定一个对文档编制要求的实施规定，主要是：在不同的条件下，应该形成哪些文档？这些文档的详细程度？该开发单位的每一个项目负责人，必须认真执行这个实施规定。 2）对于一个具体的应用软件项目，项目负责人应根据上述实施规定，确定一个文档编制计划（可以包含在软件开发计划中），其中包括： （1）应该编制哪几种文档，详细程度如何？(2)各个文档的编制负责人和进度要求；(3)审查、批准的负责人和时间进度安排(4)在开发时间内，各文档的维护、修改和管理的负责人，以及批准手续。每项工作必须落实到人。这个文件编制计划是整个开发计划的重要组成部份。3）有关的设计人员则必须严格执行这个文档编制计划。 b.文档的详细程度从同一份提纲起草的文件的篇幅大小往往不同，可以少到几页，也可以长达几百页。对于这种差别，本规范是允许的。此详细程度取决于任务的规模、复杂性和项目负责人对该软件的开发过程及运行环境所需要的详细程度的判断。 c.文档的扩展当被开发系统的规模非常大〈例如源码超过一百万行〉时，一种文档可以分成几卷编写，可以按其中每一个系统分别编制；也可以按内容划分成多卷，例如：项目开发计划可能包括：质量保证计划，配置管理计划，用户培训计划，安装实施计划； 系统设计说明可分写成：系统设计说明，子系统设计说明；程序设计说明可分写成：程序设计说明，接口设计说明，版本说明； 操作手册可分写成：操作手册，安装实施过程；测试计划可分写成：测试计划，测试设计说明，测试规程，测试用例； 测试分析报告可分写成：综合测试报告，验收测试报告；项目开发总结报告亦可分写成项目开发总结报告和资源环境统计。 d.节的扩张与缩并在有些文档中，可以使用本规范所提供的章、条标题，有存在一系列需要分别讨论的因素。本规范认为，所有的条都可以扩展，可以进一步细分，以适应实际需要。反之如果章条中的有些细节并非必需，也可以根据实际情况缩并。此时章条的编号应相应地变更。 e.程序设计的表现形式本规范对于程序的设计表现形式并未作出规定或限制，可以使用流程图的形式，判定表的形式，也可以使用其他表现形式，如程序设计语言（PDL）、问题分析图（PALb）等。f.文档的表现形式本规范对于文档的表现形式亦未作出规定或限制。可以使用自然语言，也可以使用形式化语言。也可以使用各件图、表。 七、文档编制格式 7.1可行性分析（研究）报告（FAR）说明：1.《可行性分析（研究）报告》（FAR）它是项目初期策划的结果，它分析了项目的要求、目标和环境；提出了几种可供选择的方案；并从技术、经济和法律各方面进行了可行性分析。可作为项目决策的依据。2.FAR也可以作为项目建议书、投标书等文件的基础。 1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。1.2背景说明项目在什么条件下提出，提出者的要求、目标、实现环境和限制条件。 1.3项目概述本条应简述本文档适用的项目和软件的用途，它应描述项目和软件的一般特性；概述项目开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其它有关的文档。1.4文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。 2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。 3可行性分析的前提3.1项目的要求3.2项目的目标3.3项目的环境、条件、假定和限制3.4进行可行性分析的方法 4可选的方案4.1原有方案的优缺点、局限性及存在的问题4.2可重用的系统，与要求之间的差距4.3可选择的系统方案14.4可选择的系统方案2…4.5选择最终方案的准则。 5所建议的系统5.1对所建议的系统的说明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技术可行性（技术风险评价）本公司现有资源（如人员、环境、设备和技术条件等）能否满足此工程和项目实施要求，若不满足，应考虑补救措施（如需要分承包方参与、增加人员、投资和设备等），涉及经济问题应进行投资、成本和效益可行性分析，最后确定此工程和项目是否具备技术可行性。8法律可行性系统开发可能导致的侵权、违法和责任。 9用户使用可行性用户单位的行政管理和工作制度；使用人员的素质和培训要求。10其它与项目有关的问题未来可能的变化。 11注解本章应包含有助于理解本文档的一般信息（例如原理）。本章应包含为理解本文档需要的术语和定义，并给出解释；所有缩略词语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。 7.2软件开发计划（SDP）说明：1.《软件开发计划》（SDP）描述开发者实施软件开发工作的计划，本文档中”软件开发”一词涵盖了新开发、修改、重用、再工程、维护和由软件产品引起的其它所有的活动。2.SDP是向需求方提供了解和监督软件开发过程、所使用的方法、每项活动的途径、项目的安排、组织及资源的一种手段。3.本计划的某些部分可视实际需要单独编制成册，例如，软件配置管理计划、软件质量保证计划和文档编制计划等。 1引言本章分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其它有关的文档。 1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性和私密性的要求。1.4与其它计划之间的关系（若有）本条描述本计划和其它项目管理计划的关系。1.5基线给出编写本项目开发计划的输入基线，如软件需求规格说明。 2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期，本章也应标识不能通过正常的供货渠道获得的所有文档的来源。 3交付产品3.1程序3.2文档3.3服务3.4非移交产品3.5验收标准3.6最后交付期限列出本项目应交付的产品，包括软件产品和文档。其中，软件产品应指明哪些是要开发的，哪些是属于维护性质的；文档是指随软件产品交付给用户的技术文档，例如用户手册、安装手册等。 4所需工作概述本章根据需要分条对后续章描述的计划作出说明，（若适用）包括以下概述：a.对所要开发系统、软件的需求和约束；b.对项目文档编制的需求和约束；c.该项目在系统生命周期中所处的地位；d.所选用的计划/采购策略或对它们的需求和约束；e.项目进度安排及资源的需求和约束；f.其它的需求和约束，如：项目的安全性、保密性、私密性、方法、标准、硬件开发和软件开发的相互依赖关系等。 5实施整个软件开发活动的计划本章分以下几条。不需要的活动的条款用”不适用”注明，如果对项目中不同的开发阶段或不同的软件需要不同的计划，这些不同之处应在此条加以注解。除以下规定的内容外，每条中还应标识可适用的风险和不确定因素，和处理它们的计划。 5.1软件开发过程本条应描述要采用的软件开发过程。计划应覆盖论及它的所有合同条款，确定已计划的开发阶段（适用的话）、目标、和各阶段要执行的软件开发活动。5.2软件开发总体计划本条应分以下若干条进行描述。 5.2.1软件开发方法本条应描述或引用要使用的软件开发方法，包括为支持这些方法所使用的手工、自动工具和过程的描述。该方法应覆盖论及它的所有合同条款。如果这些方法在它们所适用的活动范围有更好的描述，可引用本计划的其它条。 5.2.2软件产品标准本条应描述或引用在表达需求、设计、编码、测试用例、测试过程和测试结果方面要遵循的标准。标准应覆盖合同中论及它的所有条款。如果这些标准在标准所适用的活动范围有更好的描述，可引用在本计划中的其它条。对要使用的各种编程语言都应提供编码标准，至少应包括： a.格式标准（如：缩进、空格、大小写和信息的排序）；b.首部注释标准，例如（要求：代码的名称/标识符，版本标识，修改历史，用途）需求和实现的设计决策，处理的注记（例如：使用的算法、假设、约束、限制和副作用），数据注记（输入、输出、变量和数据结构等）；c.其它注释标准（例如要求的数量和预期的内容）；d.变量、参数、程序包、过程和文档等的命名约定；e.（若有）编程语言构造或功能的使用限制；f.代码聚合复杂性的制约。 5.2.3可重用的软件产品本条应分以下若干条。5.2.3.1吸纳可重用的软件产品本条应描述标识、评估和吸纳可重用软件产品要遵循的方法，包括搜寻这些产品的范围和进行评估的准则。描述应覆盖合同中论及它的所有条款。在制定或更新计划时对己选定的或候选的可重用的软件产品应加以标识和说明，（若适用）同时应给出与使用有关的优点、缺陷和限制。 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记录原理本条应描述记录原理所遵循的方法，该原理在支持机构对项目作出关键决策时是有用的。应对项目的”关键决策”一词作出解释，并陈述原理记录在什么地方。描述应覆盖合同中论及它的所有条款。 5.2.7需方评审途径本条应描述为评审软件产品和活动，让需方或授权代表访问开发方和分承制方的一些设施要遵循的方法。描述应遵循合同中论及它的所有条款。 6实施详细软件开发活动的计划本章分条进行描述。不需要的活动用”不适用”注明，如果项目的不同的开发阶段或不同的软件需要不同的计划，则在本条应指出这些差异。每项活动的论述应包括应用于以下方面的途径（方法/过程/工具）：1）所涉及的分析性任务或其它技术性任务：2）结果的记录：3）与交付有关的准备（如果有的话）。论述还应标识存在的风险和不确定因素，及处理它们的计划。如果适用的方法在5.2.1处描述了的话，可引用它。 6.1项目计划和监督本条分成若干分条描述项目计划和监督中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.1.1软件开发计划（包括对该计划的更新）6.1.2CSCI测试计划6.1.3系统测试计划6.1.4软件安装计划6.1.5软件移交计划6.1.6跟踪和更新计划，包括评审管理的时间间隔 6.2建立软件开发环境本条分成以下若干分条描述建立、控制、维护软件开发环境所遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.2.1软件工程环境6.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.1CSCI级设计决策6.6.2CSCI体系结构设计6.6.3CSCI详细设计 6.7软件实现和配置项测试本条应分成若干分条描述软件实现配置项测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。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.9CSCI合格性测试本条应分成若干分条描述CSCI合格性测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.9.1CSCI合格性测试的独立性6.9.2在目标计算机系统（或模拟的环境）上测试6.9.3CSCI合格性测试准备6.9.4CSCI合格性测试演练6.9.5CSCI合格性测试执行6.9.6修改和再测试6.9.7CSCI合格性测试结果分析与记录 6.10CSCI/HWCI集成和测试本条应分成若干分条描述CSCI/HWCI集成和测试中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.10.1CSCI/HWCI集成和测试准备6.10.2CSCI/HWCI集成和测试执行6.10.3修改和再测试6.10.4CSCI/HWCI集成和测试结果分析与记录 6.11系统合格性测试本条应分成若干分条描述系统合格性测试中要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。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软件移交准备本条应分成若干分条描述软件移交准备要遵循的方法。各分条的计划应遵循合同中论及它的所有条款。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软件产品评估本条应分成若干分条描述软件产品评估中要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。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问题/变更报告它包括要记录的具体条目（可选的条目包括：项目名称，提出者，问题编号，问题名称，受影响的软件元素或文档，发生日期，类别和优先级，描述，指派的该问题的分析者，指派日期，完成日期，分析时间，推荐的解决方案，影响，问题状态，解决方案的批准，随后的动作，更正者，更正日期，被更正的版本，更正时间，己实现的解决方案的描述）。6.17.2更正活动系统 6.18联合评审（联合技术评审和联合管理评审）本条应分成若干分条描述进行联合技术评审和联合管理评审要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。6.18.1联合技术评审包括一组建议的评审6.18.2联合管理评审包括一组建议的评审 6.19文档编制本条应分成若干分条描述文档编制要遵循的方法。各分条的计划应覆盖合同中论及它的所有条款。应遵循本标准第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进度表和活动网络图本章应给出：a.进度表，标识每个开发阶段中的活动，给出每个活动的初始点、提交的草稿和最终结果的可用性，和其它的里程碑及每个活动的完成点；b.活动网络图，描述项目活动之间的顺序关系和依赖关系，标出完成项目中有最严格时间限制的活动。 8项目组织和资源本章应分成若干分条描述各阶段要使用的项目组织和资源。8.1项目组织本条应描述本项目要采用的组织结构，包括涉及的组织机构、机构之间的关系、执行所需活动的每个机构的权限和职责。 8.2项目资源本条应描述适用于本项目的资源。（若适用）应包括：a.人力资源，包括；1）估计此项目应投入的人力（人员/时间数）；2）按职责（如：管理，软件工程，软件测试，软件配置管理，软件产品评估，软件质量保证和软件文档编制等）分解所投入的人力；3）履行每个职责人员的技术级别、地理位置和涉密程度的划分； b.开发人员要使用的设施，包括执行工作的地理位置、要使用的设施、保密区域和运用合同项目的设施的其它特性；c.为满足合同需要，需方应提高的设备、软件、服务、文档、资料及设施，给出一张何时需要上述各项的进度表；d.其它所需的资源，包括：获得资源的计划、需要的日期和每项资源的可用性。 9培训9.1项目的技术要求根据客户需求和项目策划结果，确定本项目的技术要求，包括管理技术和开发技术。9.2培训计划根据项目的技术要求和项目成员的情况，确定是否需要进行项目培训，并制订培训计划。如不需要培训，应说明理由。 10项目估算说明项目估算的结果。10.1规模估算10.2工作量估算10.3成本估算10.4关键计算机资源估算10.5管理预留 11风险管理分析可能存在的风险，所采取的对策和风险管理计划。12支持条件12.1计算机系统支持。12.2需要需方承担的工作和提供的条件。12.3需要分包商承担的工作和提供的条件。 13注解本章应包含有助于理解本文档的一般信息（例如原理）。本章应包含为理解本文档需要的术语和定义并给出解释，所有缩略词语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。 7.11软件需求规格说明（SRS）说明：1.《软件需求规格说明》（SRS）描述对计算机软件配置项CSCI的需求，及确保每个要求得以满足的所使用的方法.涉及该CSCI外部接口的需求可在本SRS中给出：或在本SRS引用的一个或多个《接口需求规格说明》（IRS）中给出。2.这个SRS，可能还要用IRS加以补充，是CSCI设计与合格性测试的基础。 1范围本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号和发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途，它应描述系统和软件的一般特性；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；列出其它有关的文档。 1.3文档概述本条应概述本文档的用途和内容，并描述与其使用有关的保密性或私密性要求。1.4基线说明编写本系统设计说明书所依据的设计基线。2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和发行日期，也应标识不能通过正常的供货渠道获得的所有文档的来源。 3需求本章应分以下几条描述CSCI需求，也就是，构成CSCI验收条件的CSCI的特性。CSCI需求是为了满足分配给该CSCI的系统需求所形成的的软件需求。给每个需求指定项目唯一标识符以支持测试和可追踪性。并以一种可以定义客观测试的方式来陈述需求。如果每个需求有关的合格性方法（见第4章）和对系统（若适用，子系统）需求的可追踪性（见5.a条）在相应的章中没有提供，则在此进行注解。 描述的详细程度遵循以下规则：应包含构成CSCI验收条件的那些CSCI特性，需方愿意推迟到设计时留给开发方说明的那些特性。如果在给定条中没有需求的话，本条应如实陈述。如果某个需求在多条中出现，可以只陈述一次而在其它条直接引用。 3.1所需的状态和方式如果需要CSCI在多种状态和方式下运行，且不同状态和方式具有不同的需求的话，则要标识和定义每一状态和方式，状态和方式的例子包括：空闲、准备就绪、活动、事后分析、培训、降级、紧急情况和后备等。状态和方式的区别是任意的，可以仅用状态描述CSCI，也可以仅用方式、方式中的状态、状态中的方式或其它有效方式描述。如果不需要多个状态和方式，不需人为加以区分，应如实陈述；如果需要多个状态或方式，还应使本规格说明中的每个需求或每组需求与这些状态和方式相关联，关联可在本条或本条引用的附录中用表格或其它的方法表示，也可在需求出现的地方加以注解。 3.2需求概述3.2.1目标a.本系统的开发意图、应用目标及作用范围（现有产品存在的问题和建议产品所要解决的问题）。b.本系统的主要功能、处理流程、数据流程及简要说明。c.表示外部接口和数据流的系统高层次图。说明本系统与其他相关产品的关系，是独立产品还是一个较大产品的组成部分（可用方框图说明）。 3.2.2运行环境简要说明本系统的运行环境（包括硬件环境和支持环境）的规定。3.2.3用户的特点说明是那一种类型的用户，从使用系统来说，有些什么特点。3.2.4关键点说明本软件需求规格说明书中的关键点（例如：关键功能、关键算法和所涉及的关键技术等）。 3.2.5约束条件列出进行本系统开发工作的约束条件。例如：经费限制、开发期限和所采用的方法与技术，以及政治、社会、文化、法律等。 3.3需求规格3.3.1软件系统总体功能／对象结构对软件系统总体功能／对象结构进行描述，包括结构图、流程图或对象图。3.3.2软件子系统功能／对象结构对每个主要子系统中的基本功能模块／对象进行描述，包括结构图、流程图或对象图。3.3.3描述约定通常使用的约定描述（数学符号、度量单位等）。 3.4CSCI能力需求本条应分条详细描述与CSCI每一能力相关联的需求。“能力”被定义为一组相关的需求。可以用“功能”、“性能”、“主题”、“目标”、或其它适合用来表示需求的词来替代“能力”。 3.4.x（CSCI能力）本条应标识必需的每一个CSCI能力，并详细说明与该能力有关的需求。如果该能力可以更清晰地分解成若干子能力，则应分条对子能力进行说明。该需求应指出所需的CSCI行为，包括适用的参数，如响应时间、吞吐时间、其它时限约束、序列、精度、容量（大小/多少）、优先级别、连续运行需求、和基于运行条件的允许偏差：（若适用）需求还应包括在异常条件、非许可条件或越界条件下所需的行为，错误处理需求和任何为保证在紧急时刻运行的连续性而引入到CSCI中的规定。在确定与CSCI所接收的输入和CSCI所产生的输出有关的需求时，应考虑在本文3.5.x给出要考虑的主题列表。 对于每一类功能或者对于每一个功能，需要具体描写其输入、处理和输出的需求。a.说明描述此功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。b.输入包括：1）详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定和有效输入范围等。2）指明引用的接口说明或接口控制文件的参考资料。 c.处理定义对输入数据、中间参数进行处理以获得预期输出结果的全部操作。包括：1）输入数据的有效性检查。2）操作的顺序，包括事件的时间设定。3）异常情况的响应，例如，溢出、通信故障、错误处理等。4）受操作影响的参数。5）用于把输入转换成相应输出的方法。6）输出数据的有效性检查。 d.输出1）详细说明该功能的所有输出数据，例如，输出目的地、数量、度量单位、时间关系、有效输出范围、非法值的处理、出错信息等。2）有关接口说明或接口控制文件的参考资料。 3.5CSCI外部接口需求本条应分条描述CSCI外部接口的需求。（如有）本条可引用一个或多个接口需求规格说明（IRS）或包含这些需求的其它文档。外部接口需求，应分别说明：a.用户接口；b.硬件接口；c.软件接口；d.通信接口的需求。 3.5.1接口标识和接口图本条应标识所需的CSCI外部接口，也就是CSCI和与它共享数据、向它提供数据或与它交换数据的实体的关系。（若适用）每个接口标识应包括项目唯一标识符，并应用名称、序号、版本和引用文档指明接口的实体（系统、配置项、用户等）。该标识应说明哪些实体具有固定的接口特性（因而要对这些接口实体强加接口需求），哪些实体正被开发或修改（从而接口需求已施加给它们）。可用一个或多个接口图来描述这些接口。 3.5.x（接口的项目唯一标识符）本条（从3.5.2开始）应通过项目唯一标识符标识CSCI的外部接口，简单地标识接口实体，根据需要可分条描述为实现该接口而强加于CSCI的需求。该接口所涉及的其它实体的接口特性应以假设或“当（未提到实体）这样做时，CSCI将……”的形式描述，而不描述为其它实体的需求。本条可引用其它文档（如：数据字典、通信协议标准、用户接口标准）代替在此所描述的信息。（若适用）需求应包括下列内容，它们以任何适合于需求的顺序提供，并从接口实体的角度说明这些特性的区别（如对数据元素的大小、频率或其它特性的不同期望）： a.CSCI必须分配给接口的优先级别；b.要实现的接口的类型的需求（如：实时数据传送、数据的存储和检索等）；c.CSCI必须提供、存储、发送、访问、接收的单个数据元素的特性，如：1）名称/标识符；a）项目唯一标识符；b）非技术（自然语言）名称；c）标准数据元素名称；d）技术名称（如代码或数据库中的变量或字段名称）；e）缩写名或同义名； 2）数据类型（字母数字、整数等）；3）大小和格式（如：字符串的长度和标点符号）；4）计量单位（如：米、元、纳秒）；5）范围或可能值的枚举（如：0～99）； 6）准确度（正确程度）和精度（有效数字位数）；7）优先级别、时序、频率、容量、序列和其它的约束条件，如：数据元素是否可被更新和业务规则是否适用；8）保密性和私密性的约束；9）来源（设置/发送实体）和接收者（使用/接收实体）； d.CSCI必须提供、存储、发送、访问、接收的数据元素集合体（记录、消息、文件、显示和报表等）的特性，如：l）名称/标识符；a）项目唯一标识符；b）非技术（自然语言）名称；c）技术名称（如代码或数据库的记录或数据结构）；d）缩写名或同义名；2）数据元素集合体中的数据元素及其结构（编号、次序、分组）；3）媒体（如盘）和媒体中数据元素/数据元素集合体的结构； 4）显示和其它输出的视听特性（如：颜色、布局、字体、图标和其它显示元素、蜂鸣器以及亮度等）；5）数据元素集合体之间的关系。如排序／访问特性；6）优先级别、时序、频率、容量、序列和其它的约束条件，如：数据元素集合体是否可被修改和业务规则是否适用；7）保密性和私密性约束；8）来源（设置/发送实体）和接收者（使用／接收实体}； e.CSCI必须为接口使用通信方法的特性。如：1）项目唯一标识符；2）通信链接／带宽／频率／媒体及其特性；3）消息格式化；4）流控制（如：序列编号和缓冲区分配）；5）数据传送速率，周期性/非周期性，传输间隔；6）路由、寻址、命名约定；7）传输服务，包括优先级别和等级；8）安全性/保密性/私密性方面的考虑，如：加密、用户鉴别、隔离和审核等； f.CSCI必须为接口使用协议的特性，如：1）项目唯一标识符；2）协议的优先级别/层次；3）分组，包括分段和重组、路由和寻址；4）合法性检查、错误控制和恢复过程；5）同步，包括连接的建立、维护和终止；6）状态、标识、任何其它的报告特征；g.其它所需的特性，如：接口实体的物理兼容性（尺寸、容限、负荷、电压和接插件兼容性等）。 3.6CSCI内部接口需求本条应指明CSCI内部接口的需求（如有的话）。如果所有内部接口都留待设计时决定，则需在此说明这一事实。如果要强加这种需求，则可考虑本文档的3.5给出的一个主题列表。3.7CSCI内部数据需求本条应指明对CSCI内部数据的需求，（若有）包括对CSCI中数据库和数据文件的需求。如果所有有关内部数据的决策都留待设计时决定，则需在此说明这一事实。如果要强加这种需求，则可考虑在本文档的3.5.x.c和3.5.x.d给出的一个主题列表。 3.8适应性需求（若有）本条应指明要求CSCI提供的、依赖于安装的数据有关的需求（如：依赖现场的经纬度）和要求CSCI使用的、根据运行需要进行变化的运行参数（如：表示与运行有关的目标常量或数据记录的参数）。3.9保密性需求（若有）本条应描述有关防止对人员、财产、环境产生潜在的危险或把此类危险减少到最低的CSCI需求，包括：为防止意外动作（如意外地发出”自动导航关闭”命令）和无效动作（发出一个想要的”自动导航关闭”命令时失败）CSCI必须提供的安全措施。 3.10保密性和私密性需求（若有）本条应指明保密性和私密性的CSCI需求，包括：CSCI运行的保密性/私密性环境、提供的保密性或私密性的类型和程度、CSCI必须经受的保密性/私密性的风险、减少此类危险所需的安全措施、CSCI必须遵循的保密性/私密性政策、CSCI必须提供的保密性/私密性审核、保密性/私密性必须遵循的确证/认可准则。3.11CSCI环境需求（若有）本条应指明有关CSCI必须运行的环境的需求。例如，包括用于CSCI运行的计算机硬件和操作系统（其它有关计算机资源方面的需求在下条中描述）。 3.12计算机资源需求本条应分以下各条进行描述。3.12.1计算机硬件需求本条应描述CSCI使用的计算机硬件需求，（若适用）包括：各类设备的数量、处理器、存储器、输入/输出设备、辅助存储器、通信/网络设备和其它所需的设备的类型、大小、容量及其它所要求的特征。 3.12.2计算机硬件资源利用需求本条应描述CSCI计算机硬件资源利用方面的需求，如：最大许可使用的处理器能力、存储器容量、输入/输出设备能力、辅助存储器容量、通信/网络设备能力。描述（如每个计算机硬件资源能力的百分比）还包括测量资源利用的条件。3.12.3计算机软件需求本条应描述CSCI必须使用或引入CSCI的计算机软件的需求，例如包括：操作系统、数据库管理系统、通信/网络软件、实用软件、输入和设备模拟器、测试软件、生产用软件。必须提供每个软件项的正确名称、版本、文档引用。 3.12.4计算机通信需求本条应描述CSCI必须使用的计算机通信方面的需求，例如包括：连接的地理位置、配置和网络拓扑结构、传输技术、数据传输速率、网关、要求的系统使用时间、传送/接收数据的类型和容量、传送/接收/响应的时间限制、数据的峰值、诊断功能。 3.13软件质量因素（若有）本条应描述合同中标识的或从更高层次规格说明派生出来的对CSCI的软件质量方面的需求，例如包括有关CSCI的功能性（实现全部所需功能的能力）、可靠性（产生正确、一致结果的能力）、可维护性（易于更正的能力）、可用性（需要时进行访问和操作的能力）、灵活性（易于适应需求变化的能力）、可移植性（易于修改以适应新环境的能力）、可重用性（可被多个应用使用的能力）、可测试性（易于充分测试的能力）、易用性（易于学习和使用的能力）以及其它属性的定量需求。 3.14设计和实现的约束.（若有）本条应描述约束CSCI设计和实现的那些需求。这些需求可引用适当的商用标准和规范。例如需求包括：a.特殊CSCI体系结构的使用或体系结构方面的需求，例如：需要的数据库和其它软件配置项；标准部件、现有的部件的使用；政府／需方提供的资源（设备、信息、软件）的使用；b.特殊设计或实现标准的使用；特殊数据标准的使用；特殊编程语言的使用；c.为支持在技术、威胁或任务等方面预期的增长和变更区域，必须提供的灵活性和可扩展性。 3.15数据说明本系统的输入、输出数据及数据管理能力方面的要求（处理量、数据量）。3.16操作说明本系统在常规操作、特殊操作以及初始化操作、恢复操作等方面的要求。 3.17故障处理说明本系统在发生可能的软硬件故障时，对故障处理的要求。a.说明属于软件系统的问题；b.给出发生错误时的错误信息；c.说明发生错误时可能采取的补救措施。 3.18算法说明用于实施系统计算功能的公式和算法的描述。a.每个主要算法的概况b.用于每个主要算法的详细公式 3.19有关人员需求（若有）本条应描述与使用或支持CSCI的人员有关的需求，包括人员数量、技能等级、责任期、培训需求、其它的信息。如：同时存在的用户数量的需求，内在帮助和培训能力的需求：（若有）还应包括强加于CSCI的人力行为工程需求，这些需求包括对人员在能力与局限性方面的考虑：在正常和极端条件下可预测的人为错误：人为错误造成严重影响的特定区域，例如包括错误消息的颜色和持续时间、关键指示器或关键的物理位置以及听觉信号的使用的需求。 3.20有关培训需求（若有）本条应描述有关培训方面的CSCI需求。包括：在CSCI中包含的培训软件。3.21有关后勤需求（若有）本条应描述有关后勤方面的CSCI需求，包括：系统维护、软件支持、系统运输方式、供应系统的需求、对现有设施的影响、对现有设备的影响。 3.22其它需求（若有）本条应描述在以上各条中没有涉及到的其它CSCI需求。3.23包装需求（若有）本条应描述需交付的CSCI在包装、加标签和处理方面的需求（如用确定方式标记和包装8磁道磁带的交付）。（若适用）可引用适当的规范和标准。 3.24需求的优先次序和关键程度（若适用）本条应给出本规格说明中需求的、表明其相对重要程度的优先顺序、关键程度或赋予的权值，如：标识出那些认为对安全性、保密性或私密性起关键作用的需求，以便进行特殊的处理。如果所有需求具有相同的权值，本条应如实陈述。 4合格性规定本章定义一组合格性方法，对于第3章中每个需求，指定所使用的方法，以确保需求得到满足。可以用表格形式表示该信息，也可以在第3章的每个需求中注明要使用的方法。合格性方法包括：a.演示：运行依赖于可见的功能操作的CSCI或部分CSCI，不需要使用仪器、专用测试设备或进行事后分析；b.测试：使用仪器或其它专用测试设备运行CSCI或部分CSCI，以便采集数据供事后分析使用； c.分析：对从其它合格性方法中获得的积累数据进行处理，例如测试结果的归约、解释或推断；d.审查：对CSCI代码、文档等进行可视化检查；e.特殊的合格性方法。任何应用到CSCI的特殊合格性方法，如：专用工具、技术、过程、设施、验收限制。 5需求可追踪性本条应包括：a.从本规格说明中每个CSCI的需求到其所涉及的系统（或子系统）需求的可追踪性。（该可追踪性也可以通过对第3章中的每个需求进行注释的方法加以描述）l注：每一层次的系统细化可能导致对更高层次的需求不能直接进行追踪.例如：建立多个CSCI的系统体系结构设计可能会产生有关CSCI之间接口的需求，而这些接口需求在系统需求中并没有被覆盖，这样的需求可以被迫踪到诸如”系统实现”这样的一般需求，或被追踪到导致它们产生的系统设计决策上.b.从分配到被本规格说明中的CSCI的每个系统（或子系统）需求到涉及它的CSCI需求的可追踪性。分配到CSCI的所有系统（或子系统）需求应加以说明。追踪到IRS中所包含的CSCI需求可引用IRS。 6．尚未解决的问题如需要，可说明软件需求中的尚未解决的遗留问题。7注解本章应包含有助于理解本文档的一般信息（例如背景信息、词汇表、原理〉。本章应包含为理解本文档需要的术语和定义并给出解释，所有缩略词语和它们在文档中的含义的字母序列表。 附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录a为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。 7.13软件（结构）设计说明（SDD）说明：1.《软件（结构）设计说明》（SDD）描述了计算机软件配置项（CSCI）的设计。它描述了CSCI级设计决定、CSCI体系结构设计（概要设计）和实现该软件所需的详细设计。DD可用接口设计说明IDD和数据库（顶层）设计说明DBDD加以补充。2.SDD连同相关的IDD和DBDD是实现该软件的基础。向需方提供了设计的可视性，为软件支持提供了所需要的信息。3.IDD和DBDD是否单独成册抑或与SDD合为一份资料视情况繁简而定。 1引言本章应分为以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识。（若适用）包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其它有关文档。 1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性或私密性要求。1.4基线说明编写本系统设计说明书所依据的设计基线。2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章也应标识不能通过正常的供货渠道获得的所有文档的来源。 3CSCI级设计决策本章应根据需要分条给出CSCI级设计决策，即CSCI行为的设计决策（忽略其内部实现，从用户的角度看，它如何满足用户的需求）和其它影响组成该CSCI的软件配置项的选择与设计的决策。如果所有这些决策在CSCI需求中均是明确的，或者要推迟到CSCI的软件配置项设计时指出，本章应如实陈述。为响应指定为关键性的需求（如安全性、保密性、私密性需求）而作出的设计决策，应在单独的条中加以描述。如果设计决策依赖于系统状态或方式，则应指出这种依赖性。应给出或引用理解这些设计所需的设计约定。 CSCI级设计决策的例子如下：a.关于CSCI应接受的输入和产生的输出的设计决策，包括与其它系统、HWCI、CSCI和用户的接口（本文的4.3.x标识了本说明要考虑的主题）。如果该信息的部分或全部已在接口设计说明（IDD）中给出，此处可引用。b.有关响应每个输入或条件的CSCI行为的设计决策，包括该CSCI要执行的动作、响应时间及其它性能特性、被模式化的物理系统的说明、所选择的方程式/算法/规则和对不允许的输入或条件的处理。 c.有关数据库/数据文件如何呈现给用户的设计决策（本文的4.3.x标识了本说明要考虑的主题）。如果该信息的部分或全部已在数据库（顶层）设计说明（DBDD）中给出，此处可引用。d.为满足安全性、保密性、私密性需求而选择的方法。e.对应需求所做的其它CSCI级设计决策，例如为提供所需的灵活性、可用性和可维护性所选择的方法。 4CSCI体系结构设计本章应分条描述CSCI体系结构设计。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖性。如果设计信息在多条中出现，则可只描述一次，而在其它条引用。应给出或引用为理解这些设计所需的设计约定。 4.1体系结构4.1.1程序（模块）划分用一系列图表列出本CSCI内的每个程序（包括每个模块和子程序）的名称、标识符、功能及其所包含的源标准名。4.1.2程序（模块）层次结构关系用一系列图表列出本CSCI内的每个程序（包括每个模块和子程序）之间的层次结构与调用关系。 4.2全局数据结构说明本章说明本程序系统中使用的全局数据常量、变量和数据结构。4.2.1常量包括数据文件名称及其所在目录，功能说明，具体常量说明等。4.2.2变量包括数据文件名称及其所在目录，功能说明，具体变量说明等。4.2.3数据结构包括数据结构名称，功能说明，具体数据结构说明（定义、注释、取值...）等。 4.3CSCI部件本条应：a.标识构成该CSCI的所有软件配置项。应赋予每个软件配置项一个项目唯一标识符。注：软件配置项是CSCI设计中的一个元素，如CSCI的一个主要的分支、该分支的一个组成部分、一个类、对象、模块、函数、例程或数据库。软件配置项可以出现在一个层次结构的不同层次上，并且可以由其它软件配置项组成。设计中的软件配置项与实现它们的代码和数据实体（例程、过程、数据库、数据文件等）或包含这些实体的计算机文件之间，可以有也可以没有一对一的关系。一个数据库可以被处理为一个CSCI，也可被处理为一个软件配置项。SDD可以通过与所采用的设计方法学一致的名字来引用软件配置项。 b.给出软件配置项的静态关系（如“组成”）。根据所选择的软件设计方法学可以给出多种关系（例如，采用面向对象的设计方法时，本条既可以给出类和对象结构，也可以给出CSCI的模块和过程结构）。c.陈述每个软件配置项的用途，并标识分配给它的CSCI需求与CSCI级设计决策（需求的分配也可在6.a中提供）。d.标识每个软件配置项的开发状态/类型（如新开发的软件配置项、重用已有设计或软件的软件配置项、再工程的已有设计或软件、为重用而开发的软件、为开发阶段N计划的软件等）。对于已有设计或软件，本说明应提供标识信息，如名字、版本、文档引用、库等。 e.描述CSCI（若适用，每个软件配置项）计划使用的计算机硬件资源（例如处理器能力、内存容量、输入/输出设备能力、辅存容量和通信/网络设备能力）。这些描述应覆盖该CSCI的资源使用需求中提及的、影响该CSCI的系统级资源分配中提及的、以及在软件开发计划的资源使用度量计划中提及的所有计算机硬件资源。如果一给定的计算机硬件资源的所有使用数据出现在同一个地方，如在一个SDD中，则本条可以引用它。针对每一计算机硬件资源应包括如下信息： 1）得到满足的CSCI需求或系统级资源分配；2）使用数据所基于的假设和条件（例如，典型用法、最坏情况用法、特定事件的假设）；3）影响使用的特殊考虑（例如虚存的使用、覆盖的使用、多处理器的使用或操作系统开销、库软件或其它的实现开销的影响）；4）所使用的度量单位（例如处理器能力百分比、每秒周期、内存字节数、每秒千字节）；5）进行评估或度量的级别（例如软件配置项、CSCI或可执行程序）。f.指出实现每个软件配置项的软件放置在哪个程序库中。 4.4执行概念本条应描述软件配置项间的执行概念。为表示软件配置项之间的动态关系，即CSCI运行期间它们如何交互的，本条应包含图示和说明，（若适用）包括执行控制流、数据流、动态控制序列、状态转换图、时序图、配置项之间的优先关系、中断处理、时间/序列关系、异常处理、并发执行、动态分配与去分配、对象/进程/任务的动态创建与删除和其它的动态行为。 4.5接口设计本条应分条描述软件配置项的接口特性，既包括软件配置项之间的接口，也包括与外部实体，如系统、配置项及用户之间的接口。如果这些信息的部分或全部已在接口设计说明（IDD）、本文的第5章或其它地方说明的话，可在此处引用。 4.5.1接口标识与接口图本条应陈述赋予每个接口的项目唯一标识符，（若适用）并用名字、编号、版本和文档引用等标识接口实体（软件配置项、系统、配置项、用户等）。接口标识应说明哪些实体具有固定接口特性（从而把接口需求强加给接口实体），哪些实体正在开发或修改（因而已把接口需求分配给它们）。（若适用）应该提供一个或多个接口图以描述这些接口。 4.5.x（接口的项目唯一标识符）本条（从4.5.2开始编号）应用项目唯一标识符标识接口，应简要标识接口实体，并且应根据需要划分为几条描述接口实体的单方或双方的接口特性。如果一给定的接口实体本文没有提到（例如，一个外部系统），但是其接口特性需要在本SDD描述的接口实体时提到，则这些特性应以假设、或“当[未提到实体]这样做时，[提到的实体]将……”的形式描述。本条可引用其它文档（例如数据字典、协议标准、用户接口标准）代替本条的描述信息。本设计说明应包括以下内容，（若适用）它们可按适合于要提供的信息的任何次序给出，并且应从接口实体角度指出这些特性之间的区别（例如数据元素的大小、频率或其它特性的不同期望）。 a.由接口实体分配给接口的优先级；b.要实现的接口的类型（例如实时数据传输、数据的存储与检索等）；c.接口实体将提供、存储、发送、访问、接收的单个数据元素的特性，例如：1）名称/标识符；a）项目唯一标识符；b）非技术（自然语言）名称；c）标准数据元素名称；e）缩写名或同义名； 2）数据类型（字母数字、整数等）；3）大小与格式（例如字符串的长度与标点符号）；4）计量单位（如米、元、纳秒等）；5）范围或可能值的枚举（如0～99）；6）准确度（正确程度）与精度（有效数位数）；7）优先级、时序、频率、容量、序列和其它约束，如数据元素是否可被更新，业务规则是否适用；8）保密性与私密性约束；9）来源（设置/发送实体）与接收者（使用/接收实体）。 d.接口实体将提供、存储、发送、访问、接收的数据元素集合体（记录、消息、文件、数组、显示、报表等）的特性，例如：1）名称/标识符；a）项目唯一标识符；b）非技术（自然语言）名称；c）技术名称（如代码或数据库中的记录或数据结构名）；d）缩写名或同义名；2）数据元素集合体中的数据元素及其结构（编号、次序、分组）； 3）媒体（如盘）及媒体上数据元素/集合体的结构；4）显示和其它输出的视听特性（如颜色、布局、字体、图标及其它显示元素、蜂鸣声、亮度等）；5）数据集合体之间的关系，如排序/访问特性；6）优先级、时序、频率、容量、序列和其它约束，如数据集合体是否可被更新，业务规则是否适用；7）保密性与私密性约束；8）来源（设置/发送实体）与接收者（使用/接收实体）。 e.接口实体为该接口使用通信方法的特性，例如：1）项目唯一标识符；2）通信链路／带宽／频率／媒体及其特性；3）消息格式化；4）流控制（如序列编号与缓冲区分配）；5）数据传输率、周期或非周期和传送间隔；6）路由、寻址及命名约定；7）传输服务，包括优先级与等级；8）安全性/保密性／私密性考虑，如加密、用户鉴别、隔离、审核等。 f.接口实体为该接口使用协议的特性，例如：1）项目唯一标识符；2）协议的优先级/层；3）分组，包括分段与重组、路由及寻址；4）合法性检查、错误控制、恢复过程；5）同步，包括连接的建立、保持、终止；6）状态、标识和其它报告特性。g.其它特性，如接口实体的物理兼容性（尺寸、容限、负荷、电压、接插件的兼容性等）。 5CSCI详细设计本章应分条描述CSCI的每个软件配置项。如果设计的部分或全部依赖于系统状态或方式，则应指出这种依赖性。如果该设计信息在多条中出现，则可只描述一次，而在其它条引用。应给出或引用为理解这些设计所需的设计约定。软件配置项的接口特性可在此处描述，也可在第4章或接口设计说明（IDD）中描述。数据库软件配置项，或用于操作/访问数据库的软件配置项，可在此处描述，也可在数据库（顶层）设计说明（DBDD）中描述。 5.x（软件配置项的项目唯一标识符或软件配置项组的指定符）本条应用项目唯一标识符标识软件配置项并描述它。（若适用）描述应包括以下信息。作为一种变通，本条也可以指定一组软件配置项，并分条标识和描述它们。包含其它软件配置项的软件配置项可以引用那些软件配置项的说明，而无需在此重复。a.（若有）配置项设计决策，诸如（如果以前未选）要使用的算法；b.软件配置项设计中的约束、限制或非常规特征；c.如果要使用的编程语言不同于该CSCI所指定的语言，应该指出，并说明使用它的理由； d.如果软件配置项由过程式命令组成或包含过程式命令（如数据库管理系统（DBMS）中用于定义表单与报表的菜单选择、用于数据库访问与操纵的联机DBMS查询、用于自动代码生成的图形用户接口（GUI）构造器的输入、操作系统的命令或shell脚本），应有过程式命令列表和解释它们的用户手册或其它文档的引用； e.如果软件配置项包含、接收或输出数据，（若适用）应有对其输入、输出和其它数据元素以及数据元素集合体的说明。（若适用）本文的4.5.x提供要包含主题的列表。软件配置项的局部数据应与软件配置项的输入或输出数据分开来描述。如果该软件配置项是一个数据库，应引用相应的数据库（顶层）设计说明（DBDD）；接口特性可在此处提供，也可引用本文第4章或相应接口设计说明。 f.如果软件配置项包含逻辑，给出其要使用的逻辑，（若适用）包括：1）该软件配置项执行启动时，其内部起作用的条件；2）把控制交给其它软件配置项的条件；3）对每个输入的响应及响应时间，包括数据转换、重命名和数据传送操作；4）该软件配置项运行期间的操作序列和动态控制序列，包括：a）序列控制方法；b）该方法的逻辑与输入条件，如计时偏差、优先级赋值；c）数据在内存中的进出；d）离散输入信号的感知，以及在软件配置项内中断操作之间的时序关系；5）异常与错误处理。 6需求的可追踪性本章应包括：a.从本SDD中标识的每个软件配置项到分配给它的CSCI需求的可追踪性（亦可在4.1中提供）；b.从每个CSCI需求到它被分配给的软件配置项的可追踪性。 7注解本章应包含有助于理解本文档的一般信息（例如背景信息、词汇表、原理）。本章应包含为理解本文档需要的术语和定义并给出解释，所有缩略词语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。 7.17软件配置管理计划说明1.《软件配置管理计划》（CMP）说明在项目中如何实现配置管理。 1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其它有关文档。 1.3文档概述本条应概括本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。1.4组织和职责描述软件配置管理（SCM）负责人和软件配置控制委员会（SCCB）的组成以及他们在项目中的职责和权限；说明与项目配置管理相关的人员，如项目经理、部门SCM组长的职责；描述以上人员之间的关系。为了能够清晰的表述，可选用图表的方式进行说明。 1.5资源描述项目配置管理活动所需的各种资源，包括人员、培训、工具、设备、设施等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。本章还应标识不能通过正常的供货渠道获得的所有文档的来源。 3管理描述负责软件配置管理的机构、任务、职责及其有关的接口控制。3.1机构描述在各阶段中负责软件配置管理的机构。描述的内容如下：a.描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构；b.说明项目和子项目与其他有关项目之间的关系；c.指出在软件生存周期各阶段中的软件开发或维护机构与配置控制委员会的相互关系。 3.2任务描述在软件生存周期各阶段中的配置管理任务以及要进行的评审和检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控库或软件产品库）。3.3职责描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系。a.指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责；b.指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系；c.说明由本计划第3.2条指明的生存周期各阶段的评审、检查和审批过程中的用户职责以及相关的开发和维护活动；d.指出与项目有关的各个机构的代表的软件配置管理职责；e.指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。 3.4接口控制描述：a.接口规格说明标识和文档控制的方法；b.对已交付的接口规格说明和文档进行修改的方法；c.对要完成的软件配置管理活动进行跟踪的方法；d.记录和报告接口规格说明和文档控制状态的方法；e.控制软件和支持它运行的硬件之间的接口的方法。 3.5实现规定实现软件配置管理计划的主要里程碑，例如：a.建立配置控制委员会；b.确定各个配置基线；c.建立控制接口协议；d.制订评审与检查软件配置管理计划和规程；e.制订相关的软件开发、测试和支持工具的配置管理计划和规程。 3.6适用的标准、条例和约定3.6.1指明所适用的软件配置管理标准、条例和约定，并把它们作为本计划要实现的一部分；还必须说明这些标准、条例和约定要实现的程度。3.6.2描述要在本项目中编写和实现的软件配置管理标准、条例和约定。这些标准、条例和约定可以包括以下内容：a.软件结构层次树中软件位置的标识方法；b.程序和模块的命名约定； c.版本级别的命名约定；d.软件产品的标识方法；e.规格说明、测试计划与测试规程、程序设计手册及其他文档的标识方法；f.媒体和文档管理的标识方法；g.文档交付过程；h.软件产品库中软件产品入库、移交或交付的过程；i.问题报告、修改请求和修改次序的处理过程； j.配置控制委员会的结构和作用；k.软件产品交付给用户的验收规程；l.软件库的操作，包括准备、存储和更新模块的方法；m.软件配置管理活动的检查；n.问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响；o.软件进入配置管理之前的测试级别；p.质量保证级别，例如，在进入配置管理之前，验证软件满足有关基线的程度。 4软件配置管理活动本章描述配置标识、配置控制、配置状态记录与报告以及配置检查与评审等四方面的软件配置管理活动的需求。4.1配置标识4.1.1本条必须详细说明软件项目的基线（即最初批准的配置标识），并把它们与本计划的3.2条描述的生存周期的特定阶段相联系。在软件生存周期中，主要有三种基线，它们是功能基线、分配基线和产品基线。对于每个基线，必须描述下列内容： a.每个基线的项（包括应交付的文档和程序）；b.与每个基线有关的评审与批准事项以及验收标准；c.在建立基线的过程中用户和开发者参与情况。例如，在产品基线中，要定义的元素可以包括：a.产品的名字和命名规则；b.产品标识编号； c.对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的修改要求以及对有关文档的修改要求；d.安装说明；e.已知的缺陷和故障；f.软件媒体和媒体标识。 4.1.2本条必须描述本项目所有软件代码和文档的标题、代号、编号以及分类规程。例如，对代码来说：a.编译日期可以作为每个交付模块标识的一部分；b.在构造模块源代码的顺序行号时，应使它适合于模块作进一步的修改。4.2配置控制4.2.1本条必须描述在本计划3.2条描述的软件生存周期中各个阶段使用的修改批准权限的级别。 4.2.2本条必须定义对已有配置的修改申请进行处理的方法，其中包括：a.详细说明在本计划第3.2条描述的软件生存周期各个阶段中提出修改申请的程序（可以用注上自然语言的流程图来表达）；b.描述实现已批准的修改申请（包括源代码、目标代码和文档的修改）的方法；c.描述软件库控制的规程，其中包括库存软件控制、对于适用基线的读写保护、成员保护、成员标识、档案维护、修改历史以及故障恢复等七项规程；d.如果有必要修补目标代码，则要描述其标识和控制的方法。 4.2.3对于各个不同层次的配置控制组和其他修改管理机构，本条必须：a.定义其作用，并规定其权限和职责；b.如果已组成机构，则指明该机构的领导人及其成员；c.如果还没有组成机构，则说明怎样任命该机构的领导人、成员及代理人；d.说明开发者和用户与配置控制组的关系。 4.2.4当要与不属于本软件配置管理计划适用范围的程序和项目进行接口时，本条必须说明对其进行配置控制的方法。如果这些软件的修改需要其他机构在配置控制组评审之前或之后进行评审，则本条必须描述这些机构的组成、它们与配置控制组的关系以及它们相互之间的关系。4.2.5本条必须说明与特殊产品（如非交付的软件、现存软件、用户提供的软件和内部支持软件）有关的配置控制规程。 4.3配置状态的记录和报告本条必须：a.指明怎样收集、验证、存储、处理和报告配置项的状态信息；b.详细说明要定期提供的报告及其分发办法；c.如果有动态查询，要指出所提供的动态查询的能力；d.如果要求记录用户说明的特殊状态时，要描述其实现手段。 例如，在配置状态记录和报告中，通常要描述的信息有：a.规格说明的状态；b.修改申请的状态；c.修改批准的报告；d.产品版本或其修改版的状态；e.安装、更新或交付的实现报告；f.用户提供的产品（如操作系统）的状态；g.有关开发项目历史的报告。 4.4配置的检查和评审本条必须：a.定义在本计划的3.2条所定义的软件生存周期的特定点上执行的检查和评审中软件配置管理计划的作用；b.规定每次检查的评审所包含的配置项；c.指出用于标识和解决在检查和评审期间发现的问题的工作流程。 5工具、技术和方法本章必须指明为支持特定项目的软件配置管理所使用的软件工具、技术和方法，指明它们的目的，并在开发者所有权的范围内描述其用法。例如，可以包括用于下列任务的工具，技术和方法：a.软件媒体和媒体文档的标识。b.把文档和媒体置于软件配置管理的控制之下，并把它正式地交付给用户。例如，要给出对软件库内的源代码和目标代码进行控制的工具、技术和方法的描述；如果用到数据库管理系统，则还要对该系统进行描述。又如，要指明怎样使用软件库工具、技术和方法来处理软件产品的交付。c.编制关于程序及其有关文档的修改状态的文档。因此必须进一步定义用于准备多种级别（如项目负责人、配置控制小组、软件配置管理人员和用户）的管理报告的工具、技术和方法。 6对供货单位的控制供货单位是指软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的管理规程，从而使从软件销售单位购买的、其他开发单位开发的或从软件开发单位现存软件库中选用的软件能满足规定的软件配置管理需求。管理规程应该规定在本软件配置管理计划的执行范围内控制供货单位的方法；还应解释用于确定供货单位的软件配置管理能力的方法以及监督它们遵循本软件配置管理计划需求的方法。 7记录的收集、维护和保存本章必须指明要保存的软件配置管理文档，指明用于汇总、保护和维护工程文档的方法和设施（其中包括要使用的后备设施），并指明要保存的期限。 8配置项和基线8.1配置项命名规则根据组织的《标识规范》，对不同类型的配置项建立命名规则。 8.2配置项的识别和基线的划分列出识别到的所有配置项和所属的配置基线，并明确配置项的标识、作者（或负责人）和配置时间。 8.3变更和发布描述配置项和基线变更、发布的流程以及相应的批准权限。为了能够清晰的表述，应选用图表的方式进行说明。9备份说明配置库和配置管理库的备份方式、频度、责任人。 10日程表列出项目配置管理活动的日程表，并确保配置管理活动的日程表与项目开发计划以及质量保证计划保持一致。 11注解本章应包含有助于理解本文档的一般信息（例如背景信息、词汇表、原理）。本章应包含为理解本文档需要的术语和定义并给出解释，所有缩略词语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。 7.18软件质量保证计划（SQAP）说明1.《软件质量保证计划》（SQAP）规定在项目中采用的软件质量保证的措施、方法和步骤。 1引言本章应分成以下几条。1.1标识本条应包含本文档适用的系统和软件的完整标识，（若适用）包括标识号、标题、缩略词语、版本号、发行号。1.2系统概述本条应简述本文档适用的系统和软件的用途。它应描述系统与软件的一般性质；概述系统开发、运行和维护的历史；标识项目的投资方、需方、用户、开发方和支持机构；标识当前和计划的运行现场；并列出其它有关文档。 1.3文档概述本条应概述本文档的用途与内容，并描述与其使用有关的保密性与私密性要求。1.4组织和职责描述SQA负责人在项目中的职责和权限；相应的高层经理、与SQA紧密配合的项目经理的职责；部门内部SQA组长的职责和与项目SQA负责人的关系。1.5资源描述出项目质量保证活动所需的各种资源，包括人员、培训、工具、设备、设施，等等。其中人员是指人力成本，它是根据项目开发计划中的总工时计算得出的。2引用文档本章应列出本文档引用的所有文档的编号、标题、修订版本和日期。也应标识不能通过正常的供货渠道获得的所有文档的来源。 3管理必须描述负责软件质量保证的机构、任务及其有关的职责。3.1机构必须描述与软件质量保证有关的机构的组成，还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员在机构中的相互关系。 3.2任务本条必须描述计划所涉及的软件生存周期中有关阶段的任务，特别是要把重点放在描述这些阶段所应进行的软件质量保证活动上。3.3职责必须指明软件质量保证计划中规定的每一个任务的负责单位或成员的责任。 4文档必须列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则。4.1基本文档为了确保软件的实现满足需求，至少需要下列基本文档：a.软件需求规格说明（或软件规格说明）。b.软件（结构）设计说明。c.测试计划与测试报告。d.软件验证与确认计划。 软件验证与确认计划必须描述所采用的软件验证与确认的方法（例如评审、检查、分析、演示或测试等），以用来验证软件需求（规格）说明中的需求是否已由软件（结构）设计说明描述的设计实现；软件（结构）设计说明表达的设计是否已由编码实现。软件验证与确认计划还可用来确认编码的执行是否与软件需求（规格）说明中所规定的需求相一致。软件验证和确认报告。此报告必须描述软件验证与确认计划的执行结果。这里必须包括软件质量保证计划所需要的所有评审、检查和测试的结果。 4.2用户文档例如，用户手册、操作手册等。4.3其它文档除上述文档外，还应包括以下文档：a.项目开发计划（其中可包括软件配置管理计划，必要时该计划也可单列）。b.项目进展报表。c.项目开发各阶段的评审报表。d.项目总结报告。 5标准、条例和约定必须列出软件开发过程中要用到的标准、条例和约定，并列出监督和保证执行的措施。6评审和检查必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程以及通过与否的技术准则。至少要进行下列各项评审和检查工作： 6.1软件需求（规格）评审在软件需求分析阶段结束后必须进行软件需求评审，以确保在软件需求（规格）说明中所规定的各项需求的合适性。6.2系统/子系统设计评审在系统/子系统设计结束后必须进行系统/子系统设计的评审，以评价软件（结构）设计说明中所描述的软件设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。 6.3软件设计评审在软件设计结束后必须进行软件设计的评审，以评价软件（结构）设计说明中所描述的软件设计，在功能、算法和过程描述等方面的合适性。6.4软件验证与确认计划评审在制订软件验证与确认计划之后要对它进行评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。 6.5功能检查在软件发行前，要对软件进行功能检查，以确认已经满足在软件需求规格说明中规定的所有需求。6.6物理检查在验收软件前，要对软件进行物理检查，以验证程序和文档已经一致并已做好了交付的准备。6.7综合检查在软件验收时，要允许用户或用户委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的一致性、接口规格说明之间的一致性（硬件和软件）、设计实现和功能需求之间的一致性、功能需求和测试描述的一致性。 6.8管理评审要对计划的执行情况定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。7项目策划阶段的SQA活动描述SQA负责人参与制定项目的软件开发计划和配置管理计划的活动，以及它们三者之间的关系。 8评审和审核8.1过程的评审描述对项目进行过程评审的方法和依据，并在下表中列出项目定义的过程以及相应的过程评审。8.2工作产品的审核描述进行产品审核的方法和依据，并在下表中列出项目过程应产生的工作产品和质量记录，以及需要由SQA负责人审核的工作产品和相应的产品审核活动。 8.3不符合问题的解决描述过程评审和产品审核的结果怎样形成记录，应形成哪些记录。描述处理在评审中出现的不符合问题的解决方法。 9软件配置管理必须编制有关软件配置管理的条款，或单独制订文档。在这些条款或文档中，必须规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。 10工具、技术和方法必须指明用以支持特定软件项目质量保证工作的工具、技术和方法，描述它们的用途。11媒体控制必须指出保护计算机程序物理媒体的方法和设施，以免非法存取、意外损坏或自然老化。 12对供货单位的控制供货单位包括项目承办单位、软件销售单位、软件开发单位或软件子开发单位。必须规定对这些供货单位进行控制的规程，从而保证项目承办单位从软件销售单位购买的、其他开发单位（或子开发单位）开发的或从开发（或子开发）单位现存软件库中选用的软件能满足规定的需求。 13记录的收集、维护和保存必须指明需要保存的软件质量保证活动的记录，并指出用于汇总、保护和维护这些记录的方法和设施，并指明要保存的期限。 14日程表列出项目质量保证活动的日程表，并确保质量保证的日程表与项目开发计划以及配置管理计划保持一致。 15注解本章应包含有助于理解本文档的一般信息（例如背景信息、词汇表、原理）。本章应包含为理解本文档需要的术语和定义并给出解释，所有缩略词语和它们在文档中的含义的字母序列表。附录附录可用来提供那些为便于文档维护而单独出版的信息（例如图表、分类数据）。（若适用）在提供资料的文档主体部分应当引用附录。为便于处理，附录可单独装订成册。附录应按字母顺序（A，B等）编排。 八小结重视文档编制，文档是提高软件质量的重要手段，作用是把不可见的逻辑工作变为可见的实体．标准的规定可以剪裁，可以灵活运用，最好形成组织的企业规范．辅以工具、模板实施之'