某公司质量管理部管理制度汇编

1、 1 / 36质量管理部管理制度质量管理部管理制度质量管理制度质量管理制度1 1 目标目标 5 52SQA2SQA 岗位职责岗位职责 5 53SQA3SQA 流程流程 6 64SQA4SQA 与各技术方向的关系与各技术方向的关系 6 65 5 软件工程标准与规软件工程标准与规 7 75.1 软件工程标准 75.2 软件标准文档模版规 95.3 软件技术规 106SQA6SQA 任务管理任务管理 10106.1 任务来源 106.2 流程管理 106.3 主要任务 10附件一：软件质量保证计划附件一：软件质量保证计划 12121 1 引言引言 13131.1 目的 13 2 / 361.2 定义

2、 131.3 参考资料 132 2 管理管理 14142.1 机构 142.2 任务 142.3 职责 153 3 文档文档 15153.1 基本文档 153.2 其它文档 163.3 文档质量的度量准则 164 4 标准、条例和约定标准、条例和约定 17175 5 评审和检查评审和检查 18185.1 第一次评审 195.2 第二次评审 195.3 第三次评审 206 6 软件配置管理软件配置管理 20207 7 工具、技术和方法工具、技术和方法 21218 8 媒体控制媒体控制 21219 9 对供货单位的控制对供货单位的控制 22221010 记录的收集、维护和保存记录的收集、维护和保存

3、 2222附件二：技术月报附件二：技术月报 2323附件附件 3 3：软件阶段评审表：软件阶段评审表 1 1附件附件 4 4：软件配置管理计划：软件配置管理计划 3 31 1 引言引言 4 41.1 目的 41.2 围 41.3 术语定义 41.4 参考资料 61.5 概述 62 2 软件配置管理软件配置管理 6 6 3 / 362.1 机构 62.2 任务 72.3 职责 72.4 接口控制 72.5 实现 82.6 适用的标准、条例和约定 83 3 软件配置管理活动软件配置管理活动 8 83.1 配置标识 93.1.1 标识方法 93.1.2 各类基线 93.2 配置和变更控制 93.3

4、配置状态审计 103.4 配置的检查和评审 114 4 工具、技术和方法工具、技术和方法 11115 5 里程碑里程碑 12126 6 培训和资源培训和资源 12127 7 对供货单位的控制对供货单位的控制 12128 8 记录的收集、维护和保存记录的收集、维护和保存 12121 1 目标目标质量管理(Supplier Quality Assurance)，以下简称 SQA，主要对研发和工程进行软件过程的质量管理。SQA 的目标：保障研发的软件产品质量，为工程项目提供稳定、可靠的运行平台，提升公司产品的层次；保障工程项目的软件产品质量和实施的规性、成功性； 4 / 36形成公司健全的质量管理体

5、系，提高公司管理水平与产品质量，提升公司的市场竞争力；通过质量管理制度的贯彻与执行，逐步向国际标准靠拢。质量管理的工作主要包括以下两个方面：制定、贯彻和持续改进质量管理的方针、指南、规；监督和检查质量管理的方针、指南、规在软件的开发过程中的实施情况，保证开发出的软件和软件开发过程符合相应的标准与规，保证软件产品、软件过程中存在的问题得到处理。2 2 SQASQA 岗位职责岗位职责跟踪软件过程的质量活动并鉴别活动中出现的偏差；里程碑式技术评审，实现软件质量的过程化管理；软件配置管理，利用配置管理工具，建立配置服务器环境，控制文档与程序的修改信息和版本；全面测试，采用适当手段对软件需求、软件分析、

6、软件设计、软件实现和文档进行全面测试；软件产品文档与程序源码归档与保管。3 3 SQASQA 流程流程 5 / 364 4 SQASQA 与各技术方向的关系与各技术方向的关系SQA 的主要职责是为研发和工程提供质量管理保障，协助各技术方向按时、保质、保量完成软件过程质量管理任务；SQA 负责对研发和工程的质量管理支持，严格按照制定的质量保证计划实施，研发和工程必须配合质量保证计划的实施；1）SQA 制定的各种标准与规，各技术方向必须严格按照标准与规执行；2）SQA 人员和研发和工程总监需要进行沟通，共同完成软件过程跟踪、审查和里程碑式评审；3）研发和工程提交配置管理计划和阶段性实施情况，SQA

7、 负责指导和监督执行。SQA 人员工作过程中发现的不符合问题与时形成软件问题单，研发和工程按照软件问题单，提出处理意见与处理时间，直到问题解决为止；研发和工程总监定期向 SQA 提交软件开发进度表；一个 SQA 人员需要同时支持研发和工程多个软件开发任务的质量管理。 6 / 365 5 软件工程标准与规软件工程标准与规5.15.1 软件工程标准软件工程标准软件工程模型1） 软件生存周期模型(瀑布模型 Waterfall Model)2） 原型模型(Prototype Model)特点： 上一阶段的变换结果 是下一阶段的变换的 输入，相邻两个阶段 具有因果关系，紧密 相联。需求分析需求分析问题定

8、义问题定义可性行研究可性行研究计划计划时期时期概要设计概要设计详细设计详细设计编编 码码 测测 试试开发开发时期时期运行与维护运行与维护运运 行行时时 期期加工原型原型快速分析和设计建造原型客户评价原型1原型系统仅包括未来系统的主要功能， 以与系统的重要接口；2为了尽快向用户提供原型，开发原型系统时应尽量使用能缩短开发周期的语言和工具。 7 / 36软件工程方法1）结构化设计方法(SD- Structured Design)结构化设计方法是基于模块化、自顶向下细化、结构化程序设计等程序设计技术基础发展起来的。它所提供的方法和原则，主要是用来指导软件的概要设计。结构化设计属于面向数据流的设计方法

9、。在软件的需求分析阶段，数据流是软件开发人员考虑问题的出发点和基础。数据流从系统的输入端向输出端，则要经历一系列的变换或处理。用来表现这个过程的数据流(DFD),实际上就是软件系统的逻辑模型。面向数据流的设计要解决的任务，就是在上述需求分析的基础上，将 DFD图映射(Mapping)-软件系统的结构。换句话说，这类设计方法，允许把用 DFD 图 表示的系统逻辑模型，很方便地转换成对于软件结构的初始设计描述。结构化设计分析工具：Microsoft Project，项目进度计划编制工具EPMS，工作流图制作工具Microsoft Visio，数据流图(DFD)、结构图制作工具Sybase Powe

10、rdeigner，数据库模型分析设计工具2）面向对象的分析方法(Object Oriented Analysis) OOA 的核心思想是利用 OO 的概念和方法对软件需求建造模型，以使用户需求逐步精确化、一致化、完全化。为此， OOA 的方法步骤为:识别对象属性与外部服务识别类与其结构定义对象之间的消息传递 8 / 36面向对象分析工具：UML、RationalRose上述列出了软件工程的两个模型和两个方法，采用哪类模型和方法，可根据具体的工程项目经过充分的论证后进行选择。5.25.2 软件标准文档模版规软件标准文档模版规需求分析需求分析需求分析-功能需求附件一：业务流图附件二：数据流图附件三

11、：业务工单/报表样需求分析-数据规划概要设计概要设计功能结构设计数据库设计说明书详细设计测试大纲使用手册维护手册5.35.3 软件技术规软件技术规工作流图(EPMS)规数据流图(DFD)规IPO 图规数据库技术规VS2008（采用的编程语言）技术规 9 / 36目录结构规文档编制规6 6 SQASQA 任务管理任务管理6.16.1 任务来源任务来源工程项目的质量管理；研发的质量管理；选定新的软件工程方法，软件工程标准文档模版和软件技术规的修订。6.26.2 流程管理流程管理工程项目启动章程宣布后，SQA 任务正式启动。6.36.3 主要任务主要任务制定软件质量保证计划(格式与容见附件 1)，根

12、据研发和工程提交的软件任务实施计划(人力资源和进度计划等)制定与其对应的软件质量保证计划，组织计划的评审，形成评审报告。向给研发和工程总监、开发人员和所有相关人员发布计划，便于研发和工程总监与 SQA 人员对其工作的监督。选定软件工程方法，要求研发和工程采用；制定与修订软件工程标准文档模版和软件技术规，要求研发和工程采用和遵循；接收来自研发和工程总监提交的软件阶段进度信息，(格式与容见附件2)；研发和工程执行的软件过程化跟踪与审查，偏离标准和规的问题与时 10 / 36的反映和处理；里程碑式评审，主要任务是保证软件执行的活动与预定义的软件过程一致，使软件过程在软件产品的开发中得到遵循，保障研发

13、和工程定义的每个软件任务得到实际的执行(软件阶段评审表格式与容见附件 3)；配置管理工作的检查和审查；由研发和工程提出配置管理计划(格式与容见附件 4)，SQA 以软件配置基线(里程碑)，软件配置项为依据，负责过程管理与监控，对研发和工程软件执行过程中产生的阶段性文档和程序进行有效的版本管理与控制。SQA 人员工作过程中记录的工作结果和发现的不符合问题，填写相应的问题单，直到问题解决，详见附件 3；这是 SQA 的一个重要的任务，SQA 人员要对工作过程中记录的工作结果和发现的不符合问题进行处理，与时向有关人员与高级管理者反映。在处理问题的过程中对符合标准过程的活动，SQA 人员应该积极地报告

14、活动的进展情况以与这些活动在符合标准方面的效果；对不符合标准过程的活动，SQA 要报告其不符合性以与它对产品的影响，同时提出改进建议。收集新方法，提供软件工程标准与规的改进。研发和工程软件执行过程中，对标准和规定义不准确或是不方便的地方，与时提出修改意见，以便 SQA 进行有效的修改和完善标准与规；对 SQA 制定的规培训。 11 / 36附件一：软件质量保证计划附件一：软件质量保证计划质量保证计划质量保证计划产品名称：编制单位：产品编号：文档编号：版 本 号：编制日期：更改日期：拟制人审核批准 12 / 361 1 引言引言1.11.1 目的目的本条必须指出特定的软件质量保证计划的具体目的。

15、还必须指出该计划所针对的软件项目（与其所属的各个子项目）的名称和用途。 本计划的目的在于对所开发的软件规定各种必要的质量保证措施，以保证所交付的软件能够满足项目委托书或合同中规定的各项需求，能够满足本软件总体制定的该软件系统需求规格说明书中规定的各项具体需求。软件开发单位在软件执行过程中，按照本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经相关人员批准。1.21.2 定义定义本条应该列出计划正文中需要解释的而在 GB/T 11457 未包含的术语的定义，必要时，还要给出这些定义的英文单词与其缩写词。1.31.3 参考资料参考资料本条必须列

16、出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。GB/T 11457 软件工程术语 13 / 36GB 8566 计算机软件开发规GB 8567 计算机软件产品开发文件编制指南GB/T 12505 计算机软件配置管理计划规 2 2 管理管理必须描述负责软件质量保证的机构、任务与其有关的职责。2.12.1 机构机构本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员有机构中的相互关系。2.22.2 任务任务本条必须描述计划涉与的软件生存周期中有关阶段的任务，特别要把重点放在描述这些阶段所应进行的软

17、件质量保证活动上。软件质量保证工作涉与软件生存同期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。因此，对实施的软件任务，要按照本计划的各项规定进行各项评审工作。SQA 人员参加所有的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在软件开发过程中，应该进行以下三次评审：第一次评审软件需求、概要设计、验证与确认方法；第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是 14 / 36功能检查、物理检查和综合检查。关于这些评审工作的详细容见第 5 章。阶段评审工作要组织专门

18、的评审小组，原则上由软件组长、副组长或特邀专家担任评审组长，评审小组成员应该包括项目委托单位或用户的代表、SQA人员、软件开发单位和上级主管部门的代表，其他参加人员视评审容而定。每一次评审工作都应填写评审总结报告与软件问题报告单。格式详见质量管理制度。日常检查：在软件的开发过程中，应该填写项目进展报表，即软件报表表头与软件阶段产品完成情况表。SQA 可以通过项目进展季报表发现有关软件质量的问题。格式详见质量管理制度。软件验收：必须组织专门的验收小组对软件进行验收。验收容应包括文档验收、程序验收、演示、验收测试与测试结果评审等几项工作。2.32.3 职责职责本条必须指明软件质量保证计划中规定的每

19、一个负责单位或成员的责任。3 3 文档文档必须列出在该软件的开发、验证与确认以与使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则。3.13.1 基本文档基本文档为了确保软件的实现满足需求规格说明书中规定的各项需求，至少应该编 15 / 36写以下八个方面容的文档：1) 软件任务实施计划； 2) 软件需求规格说明书；3) 软件设计说明书，应该包含概要设计和详细设计两个文档；4) 软件测试大纲；5) 使用手册；6) 维护手册 7) 项目开发总结。8) 源代码清单； 3.23.2 其它文档其它文档除了基本文档之外，对于尚在开发中的软件，还应该包括以下四个方面的文档：1) 软件质量保

20、证计划；2) 软件配置管理计划；3) 软件阶段进展表，其详细格式参考质量管理规的各项规定；4) 软件阶段评审表，其详细格式参考质量管理规的各项规定。3.33.3 文档质量的度量准则文档质量的度量准则文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。难作确认就是要检查各阶段文档的合适性。评审文档质量的度量准则是有以下六条：1) 完备性：所有承担软件开发任务的单位，都城必须公司制定的软件文档标准模版编制相应的文档，以保证在开发阶段结束时其文档是齐全的。2) 正确性：在软件开发各个阶段所编写的文档的容，必须真实的反映阶段的工作且与该阶段的需求相一致。 16 / 363) 简明性：在软件

21、开发各个阶段所编写的各种文档的语言表达应该清晰、准确简炼，适合各种文档的特定读者。4) 可追踪性：在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性和横向可追踪性两个方面。前者是指在不同的文档的相关容之间相互检索的难易程序；后者是指确定同一文档某一容在本文档中的围的难易程度。5) 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。6) 规性：在软件开发各个阶段所编写的各种文档应该具有良好的规性。文档的规性是指文档的封面、大纲、术语的含义以与图示符号

22、等符合有关规的规定。4 4 标准、条例和约定标准、条例和约定在软件的开发过程中，还必须遵守下列标准、条例和约定：1) 软件文档模版标准规需求分析需求分析需求分析-功能需求附件一：业务流图附件二：数据流图附件三：业务工单/报表样需求分析-数据规划概要设计概要设计功能结构设计数据库设计说明书 17 / 36详细设计测试大纲使用手册维护手册2) 软件技术规工作流图(EPMS)规数据流图(DFD)规IPO 图规数据库设计规VS 编程规目录结构规文档编制规3) 软件配置管理计划5 5 评审和检查评审和检查必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程以与通过与否的技

23、术准则。至少要进行下列各项评审和检查工作：1) 软件需求评审(software requirements review)在软件概要设计结束后必须进行概要设计评审，以确保在软件需求规格说明书中所规定的各项需求的合适性。2) 概要设计评审(preliminary design review)在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以与各主要部件之间的接口等方面的合适性。3) 详细设计评审(detailed design review)软件详细设计阶段结束后必须进行详细设计评审，以评价软件验证与确认 18

24、 / 36计划中所规定的验证与确认方法的合适性与完整性。4) 功能检查(functional audit)在软件释放前，要对软件进行物理检查，以验证程序和文档已经满足在软件需求说明书中规定的所有需求。5) 物理检查(physical audit)在验收软件前，要对软件进行物理检查，以难程序和文档已经一致并已做好了交付的准备。6) 综合检查(comprehensive audit)在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的一致性。7) 管理评审(management reviews)要对计划的执行情况定期（或按阶段）进行管理评审；这些

25、评审必须由独立于被评审单位的机构或授权的第三方主持进行。5.15.1 第一次评审第一次评审第一次评审会要对软件需求、概要设计以与验证与确认方法进行评审。1) 软件需求评审（SRR）应确保在软件需求规格说明书中规定的各项需求的合理性；2) 概要设计评审（PDR）应评价软件设计说明书中的软件概要设计的技术合适性；3) 软件验证和确认评审（SV&VR）应评价软件验证和确认计划中确定的验证和确认方法的合适性和完整性。5.25.2 第二次评审第二次评审第二次评审会要对详细设计、功能测试与演示进行评审，并对第一次评审结果进行复核。如果在软件开发过程中发现需要修改第一次评审结果，则应按照软件配置管理

26、计划的规定处理。1) 详细设计评审（DDR）应确定软件设计说明书中的详细设计在满足软件 19 / 36需求规格说明书中的需求方面的可接受性。 2) 编程格式评审应确保所有编码采用规定的工作语言，能在规定的运行环境中运行，满足技术规中的约定，并且符合规约定的编程风格。在满足这些要求之后，方可进行测试工作评审。3) 测试工作评审应对所有的程序单元进行静态分析，检查其程序结构（即模块和函数的调用关系和调用序列）和变量使用是否正确。在通过静态分析后，再进行结构测试和功能测试。各个软件子系统或模块只进行功能测试，不单独进行结构测试。测试测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测

27、试工作时，不仅要运行开发单位给出的测试用例，而且要允许运行任务委托单位或用户、评审人员选定的采样用例。 5.35.3 第三次评审第三次评审第三次评审会要进行功能检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。1) 功能检查(FA)，应验证所开发的软件已满足在软件需求规格说明书中规定的所有需求。 2) 物理检查(PA)，应对软件进行物理检查，以验证程序和文档已经一致，并已做好了交付的准备。 3) 综合检查(CA)，应验证代码和设计文档的一致性、接口规格说明的一致性（硬件和软件） 、设计实现和功能需求的一致性、功能需求和测试描述的一致性。6 6 软件配置管理软件配置管理必须编制软件

28、配置管理计划，规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以与评审和检查配置工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的 20 / 36机构与其职责。7 7 工具、技术和方法工具、技术和方法在软件的研制与开发过程中，都应该在各自的软件质量保证活动中合理地使用软件质量支持工具、技术和方法。这些工具主要有下列三种：1) 软件配置管理工具，它支持用户对源代码清单的更新管理以与对重新编译与连接的代码的自动组织；支持用户有不同文档相关容之间进行相互检索并确定同一文档中的

29、涉与围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理；2) 文档辅助生成工具与图形编辑工具，它主要协助用户绘制描述程序流程与结构的工作流图(EPMS)与数据流图(DFD)。绘制描述软件功能（输入、输出关系）的曲线以与绘制描述系统特性的一些其他图形，同时还可生成若干与软件文档编制大约相适应的文档模板。用户利用这个工具的正文与图形编辑功能以与上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，还有助于提高文档的编制质量；3) 数据库设计工具，主要设计完成数据库的逻辑模型与物理模型，同时还可生成与软件文档编制大约相适应的数据字典。8 8 媒体控制媒体控制为了保护计算机

30、程序的物理媒体，以免非法存取，意外损坏或自然老化，SQA 人员按照软件工程小组制订的、且经批准的软件配置管理计划妥善管理和存放各个子系统与其专用支持软件的媒体。 21 / 369 9 对供货单位的控制对供货单位的控制需要从软件销售购买、委托或其他开发单位开发、从开发单位现存软件库中选用或从项目委托单位或用户的现有软件库中选用软件时，SQA 必须参与软件选用评审、测试与检查，只有当演示成功、测试合格后才能批准选用。如果只选用其中部分容，则按待开发软件的处理过程办理，此时 SQA 不再干预。 1010 记录的收集、维护和保存记录的收集、维护和保存在软件的研制与开发期间，要进行各种软件质量保证活动，

31、准确记录、与时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。SQA 人员负责收集、汇总与保存有关软件质量保证活动的记录。要收集、汇总与保存的记录名字与其保存期限见表 1。表 1 记录名称与其保存的期限记录的名称与分类记录的名称与分类要保存的期限要保存的期限阶段评审阶段评审总结整个软件开发周期记录阶段评审主要问题整个软件开发周期阶段评审成员整个软件开发周期日常检查软件阶段产品完成情况整个软件开发周期修改软件问题报告单整个软件开发周期组织软件质量人员记录整个软件开发周期 22 / 36附件二：技术月报附件二：技术月报技技 术术 月月 报报 （一）（一）统计日期：项目名称进度甘特图项目

32、信息项目经理合同工期项目进度信息计划进度计划进度实际进度实际进度阶段阶段开始日期开始日期结束日期结束日期开始日期开始日期结束日期结束日期备注备注1 需求分析阶段2 概要设计阶段3 详细设计阶段4 软件编码阶段5 软件测试阶段6 系统试运行阶段7 系统综合验收说明：阶段产品包括实施计划、需求规格说明书、概要设计说明书、详细设计说明书、测试大纲、 使用手册、维护手册、项目开发总结、源代码清单、配置管理计划等。质量信息阶段阶段质量过程状态质量过程状态评审状态评审状态评审结果评审结果质量总结质量总结1 需求分析阶段过程跟踪评审评审 复审通过 不通过2 概要设计阶段过程跟踪评审评审 复审通过 不通过3

33、详细设计阶段过程跟踪评审评审 复审通过 不通过4 软件编码阶段过程跟踪评审评审 复审通过 不通过5 软件测试阶段过程跟踪评审评审 复审通过 不通过6 系统试运行阶段过程跟踪评审评审 复审通过 不通过7 系统综合验收过程跟踪评审评审 复审通过 不通过说明：对项目进度的甘特图可另用篇幅，采用 Excel 格式制作，用不同的颜色同时体现计划和实际进度状况。 23 / 36技技 术术 月月 报报 （二）（二）统计日期：费用信息项目预算： （人月）其中项目组： （人月）其中专题组： （人月）项目组员项目组员（现场）（现场）项目组员项目组员（非现场）（非现场）专题组专题组（现场）（现场）专题组专题组（非现

34、场）（非现场）其他人员其他人员（现场）（现场）其他人员其他人员（非现场）（非现场）房租费房租费通信费通信费办公费办公费招待费招待费生活用品生活用品差旅交通差旅交通奖金奖金月月份份本月累计本月累计本月累计本月累计本月累计本月累计本月累计本月累计本月累计本月累计本月累计本月累计本月累计123456789101112合计合计 1 / 36附件附件 3 3：软件阶段评审表：软件阶段评审表在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。阶段评审可以对某个开发阶段产品进行评审，也可以对某几个开发阶段产品进行综合评审。在每次阶段评审中，必须履行正式手续，填写必要的评审表格

35、，以利于项目管理工作，利于产品验收时的质量检查工作。软件阶段评审表由两子表组成:1) 评审总结报告；2) 主要问题的详细描述(软件问题报告单)； 评审总结报告登 记 号评审日期评审总结报告评审性质评审 复审阶段状态需求分析概要设计详细设计软件编码软件测试安装与验收软件总开发阶段负 责 人地址 不需修改通 过 稍作修改作重要修改评审结论不通过要重新评审质量管理：产品经理：评审成员工程总监： 2 / 36研发总监：项目经理：备 注表 2：软件问题报告单登记号登记日期年 月 日软件问题报告单发现日期年 月 日子系统名称模块名称模块编码 阶段状态需求分析概要设计详细设计软件编码软件测试安装与验收 报告

36、人地址 软件问题程序数据库文档 其它 问题描述/影响：附注与修改建议： 3 / 36附件附件 4 4：软件配置管理计划：软件配置管理计划软件配置管理计划软件配置管理计划产品名称：编制单位：产品编号：文档编号：版 本 号：编制日期：更改日期：拟制人审核批准 4 / 361 1 引言引言配置管理计划的简介应提供整个文档的概述。它应包括此配置管理计划的目的、围、定义、术语定义、参考资料和概述。1.11.1 目的目的阐明此配置管理计划的目的。1.21.2 围围简要说明此配置管理计划的围；它的相关模型，以与受到此文档影响的任何其他事物。1.31.3 术语定义术语定义本小节应提供正确理解此配置管理计划所需

37、的全部术语、首字母缩写词和缩略语的定义。软件配置管理，简称 SCM(Software Configuration Management 的缩写)，是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以与风险水平。软件的规模越大，配置管理就显得越重要。基线(baseline)，是项目储存库中每个工件版本在特定时期的一个“快照” 。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。功能基线(Functional Baseline)，功能基线是指在系统分析

38、与软件定 5 / 36义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。指派基线(Allocated Baseline)，指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。产品基线(product baseline)产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所

39、开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。配置控制(configuration control)，对软件任务在开发过程中的资源进行标识，以便识别。配置检查(configuration audit)，对软件配置管理过程中的活动进行检查。配置标识(configuration identification)配置状态记录(configuration status accounting)软件开发库(Software Development Library)，软件开发库是指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。软件受控

40、库(Software Sontrolled Library)，软件受控库是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息一人工可读信息的库。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。软件产品库(Software Product Library)，软件产品库是指在软件生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户 6 / 36运行或在现场安装的软件的库。接口控制(Interface Control） ，接口控制是指描述有关由一个或多个部门提供的两个或两个以上的配置项接口的所有功能特性和物

41、理特性的过程。在实现之前，要确保对这些功能特性和物理特性所建议的修改已经过评审和批准。1.41.4 参考资料参考资料本小节应完整列出此配置管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用） 、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。GB/T 11457 软件工程术语GB 8566 计算机软件开发规GB 8567 计算机软件产品开发文件编制指南GB/T 12504 计算机软件质量保证计划规1.51.5 概述概述本小节应说明此配置管理计划中其他部分所包含的容，并解释文档的组织方式。2 2 软件配置管理软件配置管理描述负责软

42、件配置管理的机构、任务、职责与其有关的接口控制。2.12.1 机构机构本小节描述在各阶段中负责软件配置管理的机构。描述的容如下：A 描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管 7 / 36理的机构； B 说明项目和子项目与其他有关项目之间的关系；C 指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的相互关系。2.22.2 任务任务本小节描述在软件生存周期各个阶段中的配置管理任务以与要进行评审的检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控库或软件产品库） 。 2.32.3 职责职责本小节描述与软件配置管理有关的各类机构或成员的职责，并

43、指出这些机构或成员相互之间的关系。A指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以与配置的评审与检查）的机构的职责； B指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以与用户等机构的关系；C说明由本计划第 2.2 条指明的生存周期各个阶段的评审、检查和审批过程中的用户职责以与相关的开发与维护活动；D指出与项目开发有关的各个机构的代表的软件配置管理职责；E指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。2.42.4 接口控制接口控制本小节应该描述：A 接口规格说明标识和文档控制的方法；B 对已交付的接口规格说明和文档进行修改的方法； 8

44、 / 36C 对要完成的软件配置管理活动进行跟踪的方法；D 记录和报告接口规格说明和文档控制状态的方法；E 控制软件和劫持它运行的硬件之间的接口的方法。2.52.5 实现实现本小节应该规定实现软件配置管理计划的主要里程碑，例如：A 建立配置控制组；B 确定各个配置基线；C 建立接口控制协议；D 制订评审与检查软件配置管理计划和规程；E 制订相关的软件开发、测试和支持工具的配置管理计划和规程。2.62.6 适用的标准、条例和约定适用的标准、条例和约定 本小节指明所适用的软件配置管理标准、条例和约定，并把它们作为本计划要实现的一部分；描述遵循的具体规与标准，描述容可以包括：A软件库的操作，包括准备

45、、存储和更新模块的方法；软件产品库中软件产品入库、移交或交付的过程；B软件文档标准规和软件技术开发规；C 版本级别的命名约定； 9 / 363 3 软件配置管理活动软件配置管理活动它应包括此软件配置管理活动的配置标识、配置变更控制、配置状态记录与报告以与配置检查与评审等到四方面的软件配置管理活动的需求。3.13.1 配置标识配置标识3.1.13.1.1 标识方法标识方法本小节说明程序和文档的命名规则；对每一个新交付的版本，要给出版本交付号、新修改的描述、修改交付的方法、对支持软件的修改要求以与有关文档的修改要求；3.1.23.1.2 各类基线各类基线 基线提供一项正式标准，随后的工作都基于此标准，并且只有经过授权后才能对此标准进行变更。说明软件项目的基线（即最初批准的配置标识） ，并把它们与本计划第 2.2条描述的生存周期的特定阶段相联系。在软件生存