软件公司技术管理制度及办法之质量管理制度.doc

技术管理制度及办法之 质量管理制度 技术部门 技术管理制度及办法之 质量管理制度 1 目标 5 2 SQA岗位职责 5 3 SQA流程 6 4 SQA与各技术方向的关系 6 5 软件工程标准与规范 7 5.1 软件工程标准 7 5.2 软件标准文档模版规范 9 5.3 软件技术规范 10 6 SQA任务管理 10 6.1 任务来源 10 6.2 流程管理 10 6.3 主要任务 10 附件一：软件质量保证计划 12 1 引言 13 1.1 目的 13 1.2 定义 13 1.3 参考资料 13 2 管理 14 2.1 机构 14 2.2 任务 14 2.3 职责 15 3 文档 15 3.1 基本文档 15 3.2 其它文档 16 3.3 文档质量的度量准则 16 4 标准、条例和约定 17 5 评审和检查 18 5.1 第一次评审 19 5.2 第二次评审 19 5.3 第三次评审 20 6 软件配置管理 20 7 工具、技术和方法 21 8 媒体控制 21 9 对供货单位的控制 22 10 记录的收集、维护和保存 22 附件二：技术月报 23 附件3：软件阶段评审表 1 附件4：软件配置管理计划 3 1引言 4 1.1 目的 4 1.2 范围 4 1.3 术语定义 4 1.4 参考资料 6 1.5 概述 6 2 软件配置管理 6 2.1 机构 6 2.2 任务 7 2.3 职责 7 2.4 接口控制 7 2.5 实现 8 2.6 适用的标准、条例和约定 8 3 软件配置管理活动 8 3.1 配置标识 9 3.1.1 标识方法 9 3.1.2 各类基线 9 3.2 配置和变更控制 9 3.3 配置状态审计 10 3.4 配置的检查和评审 11 4 工具、技术和方法 11 5 里程碑 12 6 培训和资源 12 7 对供货单位的控制 12 8 记录的收集、维护和保存 12 1 目标 质量管理(Supplier Quality Assurance)，以下简称 SQA，主要对研发和工程进行软件过程的质量管理。 SQA的目标： l 保障研发的软件产品质量，为工程项目提供稳定、可靠的运行平台，提升公司产品的层次； l 保障工程项目的软件产品质量和实施的规范性、成功性； l 形成公司健全的质量管理体系，提高公司管理水平及产品质量，提升公司的市场竞争力； l 通过质量管理制度的贯彻与执行，逐步向国际标准靠拢。 l 质量管理的工作主要包括以下两个方面： l 制定、贯彻和持续改进质量管理的方针、指南、规范； l 监督和检查质量管理的方针、指南、规范在软件的开发过程中的实施情况，保证开发出的软件和软件开发过程符合相应的标准与规范，保证软件产品、软件过程中存在的问题得到处理。 2 SQA岗位职责 l 统一软件工程方法，制定以公司产品线为主的软件标准文档模版规范和软件技术规范； l 跟踪软件过程的质量活动并鉴别活动中出现的偏差； l 里程碑式技术评审，实现软件质量的过程化管理； l 软件配置管理，利用配置管理工具，建立配置服务器环境，控制文档与程序的修改信息和版本； l 全面测试，采用适当手段对软件需求、软件分析、软件设计、软件实现和文档进行全面测试； l 软件产品文档及程序源码归档与保管。 3 SQA流程 4 SQA与各技术方向的关系 l SQA的主要职责是为研发和工程提供质量管理保障，协助各技术方向按时、保质、保量完成软件过程质量管理任务； l SQA负责对研发和工程的质量管理支持，严格按照制定的质量保证计划实施，研发和工程必须配合质量保证计划的实施； 1） SQA制定的各种标准与规范，各技术方向必须严格按照标准与规范执行； 2） SQA人员和研发和工程总监需要进行沟通，共同完成软件过程跟踪、审查和里程碑式评审； 3） 研发和工程提交配置管理计划和阶段性实施情况，SQA负责指导和监督执行。 l SQA人员工作过程中发现的不符合问题及时形成软件问题单，研发和工程按照软件问题单，提出处理意见及处理时间，直到问题解决为止； l 研发和工程总监定期向SQA提交软件开发进度表； l 一个SQA人员需要同时支持研发和工程多个软件开发任务的质量管理。 5 软件工程标准与规范 5.1 软件工程标准 l 软件工程模型 1） 软件生存周期模型(瀑布模型 Waterfall Model) 特点： 上一阶段的变换结果 是下一阶段的变换的 输入，相邻两个阶段 具有因果关系，紧密 相联。 需求分析 问题定义 可性行研究 计划 时期 概要设计 详细设计 编 码 测 试 开发 时期 运行与维护 运 行 时 期 2） 原型模型(Prototype Model) 加工 原型 原型 快速分析 和设计 建造 原型 客户评价原型 1． 原型系统仅包括未来系统的主要功能， 以及系统的重要接口； 2． 为了尽快向用户提供原型，开发原型系统时应尽量使用能缩短开发周期的语言和工具。 l 软件工程方法 1） 结构化设计方法(SD-- Structured Design) 结构化设计方法是基于模块化、自顶向下细化、结构化程序设计等程序设计技术基础发展起来的。它所提供的方法和原则，主要是用来指导软件的概要设计。 结构化设计属于面向数据流的设计方法。在软件的需求分析阶段，数据流是软件开发人员考虑问题的出发点和基础。数据流从系统的输入端向输出端，则要经历一系列的变换或处理。用来表现这个过程的数据流(DFD),实际上就是软件系统的逻辑模型。 面向数据流的设计要解决的任务，就是在上述需求分析的基础上，将DFD图映射(Mapping)---软件系统的结构。换句话说，这类设计方法，允许把用 DFD图 表示的系统逻辑模型，很方便地转换成对于软件结构的初始设计描述。 Ø 结构化设计分析工具： Ø Microsoft Project，项目进度计划编制工具 Ø EPMS，工作流图制作工具 Ø Microsoft Visio，数据流图(DFD)、结构图制作工具 Ø Sybase Powerdeigner，数据库模型分析设计工具 2） 面向对象的分析方法(Object Oriented Analysis) OOA 的核心思想是利用OO的概念和方法对软件需求建造模型，以使用户需求逐 步精确化、一致化、完全化。为此， OOA的方法步骤为: 识别对象 属性及外部服务 识别类及其结构 定义对象之 间的消息传递 面向对象分析工具： UML、RationalRose 上述列出了软件工程的两个模型和两个方法，采用哪类模型和方法，可根据具体的工程项目经过充分的论证后进行选择。 5.2 软件标准文档模版规范 l 需求分析 需求分析 需求分析---功能需求 附件一：业务流图 附件二：数据流图 附件三：业务工单/报表样张 需求分析---数据规划 l 概要设计 概要设计 功能结构设计 数据库设计说明书 l 详细设计 l 测试大纲 l 使用手册 l 维护手册 5.3 软件技术规范 l 工作流图(EPMS)规范 l 数据流图(DFD)规范 l IPO图规范 l 数据库技术规范 l VS2008（采用的编程语言）技术规范 l 目录结构规范 l 文档编制规范 6 SQA任务管理 6.1 任务来源 l 工程项目的质量管理； l 研发的质量管理； l 选定新的软件工程方法，软件工程标准文档模版和软件技术规范的修订。 6.2 流程管理 工程项目启动章程宣布后，SQA任务正式启动。 6.3 主要任务 l 制定软件质量保证计划(格式与内容见附件1)，根据研发和工程提交的软件任务实施计划(人力资源和进度计划等)制定与其对应的软件质量保证计划，组织计划的评审，形成评审报告。向给研发和工程总监、开发人员和所有相关人员发布计划，便于研发和工程总监及SQA人员对其工作的监督。 l 选定软件工程方法，要求研发和工程采用； l 制定与修订软件工程标准文档模版和软件技术规范，要求研发和工程采用和遵循； l 接收来自研发和工程总监提交的软件阶段进度信息，(格式与内容见附件2)； l 研发和工程执行的软件过程化跟踪与审查，偏离标准和规范的问题及时的反映和处理； l 里程碑式评审，主要任务是保证软件执行的活动与预定义的软件过程一致，使软件过程在软件产品的开发中得到遵循，保障研发和工程定义的每个软件任务得到实际的执行(软件阶段评审表格式与内容见附件3)； l 配置管理工作的检查和审查； 由研发和工程提出配置管理计划(格式与内容见附件4)，SQA以软件配置基线(里程碑)，软件配置项为依据，负责过程管理与监控，对研发和工程软件执行过程中产生的阶段性文档和程序进行有效的版本管理与控制。 l SQA人员工作过程中记录的工作结果和发现的不符合问题，填写相应的问题单，直到问题解决，详见附件3； 这是SQA的一个重要的任务，SQA人员要对工作过程中记录的工作结果和发现的不符合问题进行处理，及时向有关人员及高级管理者反映。在处理问题的过程中对符合标准过程的活动，SQA人员应该积极地报告活动的进展情况以及这些活动在符合标准方面的效果；对不符合标准过程的活动，SQA要报告其不符合性以及它对产品的影响，同时提出改进建议。 l 收集新方法，提供软件工程标准与规范的改进。研发和工程软件执行过程中，对标准和规范定义不准确或是不方便的地方，及时提出修改意见，以便SQA进行有效的修改和完善标准与规范； l 对SQA制定的规范培训。 附件一：软件质量保证计划 质量保证计划 产品名称： 编制单位： 产品编号： 文档编号： 版 本 号： 编制日期： 更改日期： 拟制人 审核 批准 1 引言 1.1 目的 [本条必须指出特定的软件质量保证计划的具体目的。还必须指出该计划所针对的软件项目（及其所属的各个子项目）的名称和用途。] 本计划的目的在于对所开发的软件规定各种必要的质量保证措施，以保证所交付的软件能够满足项目委托书或合同中规定的各项需求，能够满足本软件总体制定的该软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在软件执行过程中，按照本计划中的有关规定，但可根据各自的情况对本计划作适当的剪裁，以满足特定的质量保证要求，剪裁后的计划必须经相关人员批准。 1.2 定义 [本条应该列出计划正文中需要解释的而在GB/T 11457中尚未包含的术语的定义，必要时，还要给出这些定义的英文单词及其缩写词。] 1.3 参考资料 [本条必须列出计划正文中所引用资料的名称、代号、编号、出版机构和出版年月。] l GB/T 11457 软件工程术语 l GB 8566 计算机软件开发规范 l GB 8567 计算机软件产品开发文件编制指南 l GB/T 12505 计算机软件配置管理计划规范 2 管理 [必须描述负责软件质量保证的机构、任务及其有关的职责。] 2.1 机构 [本条必须描述与软件质量保证有关的机构的组成。还必须清楚地描述来自项目委托单位、项目承办单位、软件开发单位或用户中负责软件质量保证的各个成员有机构中的相互关系。] 2.2 任务 [本条必须描述计划涉及的软件生存周期中有关阶段的任务，特别要把重点放在描述这些阶段所应进行的软件质量保证活动上。] 软件质量保证工作涉及软件生存同期各阶段的活动，应该贯彻到日常的软件开发活动中，而且应该特别注意软件质量的早期评审工作。因此，对实施的软件任务，要按照本计划的各项规定进行各项评审工作。SQA人员参加所有的评审与检查活动。评审与检查的目的是为了确保在软件开发工作的各个阶段和各个方面都认真采取各项措施来保证与提高软件的质量。在软件开发过程中，应该进行以下三次评审：第一次评审软件需求、概要设计、验证与确认方法；第二次评审详细设计、功能测试与演示，并对第一次评审结果复核；第三次是功能检查、物理检查和综合检查。关于这些评审工作的详细内容见第5章。 阶段评审工作要组织专门的评审小组，原则上由软件组长、副组长或特邀专家担任评审组长，评审小组成员应该包括项目委托单位或用户的代表、SQA人员、软件开发单位和上级主管部门的代表，其他参加人员视评审内容而定。 每一次评审工作都应填写评审总结报告与软件问题报告单。格式详见质量管理制度。 日常检查：在软件的开发过程中，应该填写项目进展报表，即软件报表表头与软件阶段产品完成情况表。SQA可以通过项目进展季报表发现有关软件质量的问题。格式详见质量管理制度。 软件验收：必须组织专门的验收小组对软件进行验收。验收内容应包括文档验收、程序验收、演示、验收测试与测试结果评审等几项工作。 2.3 职责 [本条必须指明软件质量保证计划中规定的每一个负责单位或成员的责任。] 3 文档 [必须列出在该软件的开发、验证与确认以及使用与维护等阶段中需要编制的文档，并描述对文档进行评审与检查的准则。] 3.1 基本文档 为了确保软件的实现满足需求规格说明书中规定的各项需求，至少应该编写以下八个方面内容的文档： 1) 软件任务实施计划； 2) 软件需求规格说明书； 3) 软件设计说明书，应该包含概要设计和详细设计两个文档； 4) 软件测试大纲； 5) 使用手册； 6) 维护手册 7) 项目开发总结。 8) 源代码清单； 3.2 其它文档 除了基本文档之外，对于尚在开发中的软件，还应该包括以下四个方面的文档： 1) 软件质量保证计划； 2) 软件配置管理计划； 3) 软件阶段进展表，其详细格式参考质量管理规范的各项规定； 4) 软件阶段评审表，其详细格式参考质量管理规范的各项规定。 3.3 文档质量的度量准则 文档是软件的重要组成部分，是软件生存周期各个不同阶段的产品描述。难作确认就是要检查各阶段文档的合适性。评审文档质量的度量准则是有以下六条： 1) 完备性：所有承担软件开发任务的单位，都城必须公司制定的软件文档标准模版编制相应的文档，以保证在开发阶段结束时其文档是齐全的。 2) 正确性：在软件开发各个阶段所编写的文档的内容，必须真实的反映阶段的工作且与该阶段的需求相一致。 3) 简明性：在软件开发各个阶段所编写的各种文档的语言表达应该清晰、准确简炼，适合各种文档的特定读者。 4) 可追踪性：在软件开发各个阶段所编写的各种文档应该具有良好的可追踪性。文档的可追踪性包括纵向可追踪性和横向可追踪性两个方面。前者是指在不同的文档的相关内容之间相互检索的难易程序；后者是指确定同一文档某一内容在本文档中的范围的难易程度。 5) 自说明性：在软件开发各个阶段所编写的各种文档应该具有较好的自说明性。文档的自说明性是指在软件开发各个阶段中的不同文档能独立表达该软件其相应阶段的阶段产品的能力。 6) 规范性：在软件开发各个阶段所编写的各种文档应该具有良好的规范性。文档的规范性是指文档的封面、大纲、术语的含义以及图示符号等符合有关规范的规定。 4 标准、条例和约定 在软件的开发过程中，还必须遵守下列标准、条例和约定： 1) 软件文档模版标准规范 l 需求分析 需求分析 需求分析---功能需求 附件一：业务流图 附件二：数据流图 附件三：业务工单/报表样张 需求分析---数据规划 l 概要设计 概要设计 功能结构设计 数据库设计说明书 l 详细设计 l 测试大纲 l 使用手册 l 维护手册 2) 软件技术规范 l 工作流图(EPMS)规范 l 数据流图(DFD)规范 l IPO图规范 l 数据库设计规范 l VS编程规范 l 目录结构规范 l 文档编制规范 3) 软件配置管理计划 5 评审和检查 必须规定所要进行的技术和管理两方面的评审和检查工作，并编制或引用有关的评审和检查规程以及通过与否的技术准则。至少要进行下列各项评审和检查工作： 1) 软件需求评审(software requirements review) 在软件概要设计结束后必须进行概要设计评审，以确保在软件需求规格说明书中所规定的各项需求的合适性。 2) 概要设计评审(preliminary design review) 在软件概要设计结束后必须进行概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的合适性。 3) 详细设计评审(detailed design review) 软件详细设计阶段结束后必须进行详细设计评审，以评价软件验证与确认计划中所规定的验证与确认方法的合适性与完整性。 4) 功能检查(functional audit) 在软件释放前，要对软件进行物理检查，以验证程序和文档已经满足在软件需求说明书中规定的所有需求。 5) 物理检查(physical audit) 在验收软件前，要对软件进行物理检查，以难程序和文档已经一致并已做好了交付的准备。 6) 综合检查(comprehensive audit) 在软件验收时，要允许用户或用户所委托的专家对所要验收的软件进行设计抽样的综合检查，以验证代码和设计文档的一致性。 7) 管理评审(management reviews) 要对计划的执行情况定期（或按阶段）进行管理评审；这些评审必须由独立于被评审单位的机构或授权的第三方主持进行。 5.1 第一次评审 第一次评审会要对软件需求、概要设计以及验证与确认方法进行评审。 1) 软件需求评审（SRR）应确保在软件需求规格说明书中规定的各项需求的合理性； 2) 概要设计评审（PDR）应评价软件设计说明书中的软件概要设计的技术合适性； 3) 软件验证和确认评审（SV&VR）应评价软件验证和确认计划中确定的验证和确认方法的合适性和完整性。 5.2 第二次评审 第二次评审会要对详细设计、功能测试与演示进行评审，并对第一次评审结果进行复核。如果在软件开发过程中发现需要修改第一次评审结果，则应按照《软件配置管理计划》的规定处理。 1) 详细设计评审（DDR）应确定软件设计说明书中的详细设计在满足软件需求规格说明书中的需求方面的可接受性。 2) 编程格式评审应确保所有编码采用规定的工作语言，能在规定的运行环境中运行，满足技术规范中的约定，并且符合规范约定的编程风格。在满足这些要求之后，方可进行测试工作评审。 3) 测试工作评审应对所有的程序单元进行静态分析，检查其程序结构（即模块和函数的调用关系和调用序列）和变量使用是否正确。在通过静态分析后，再进行结构测试和功能测试。各个软件子系统或模块只进行功能测试，不单独进行结构测试。测试测试工作评审要检查所进行的测试工作是否满足这些要求。特别在评审功能测试工作时，不仅要运行开发单位给出的测试用例，而且要允许运行任务委托单位或用户、评审人员选定的采样用例。 5.3 第三次评审 第三次评审会要进行功能检查、物理检查和综合检查。这些评审会应在集成测试阶段结束后进行。 1) 功能检查(FA)，应验证所开发的软件已满足在软件需求规格说明书中规定的所有需求。 2) 物理检查(PA)，应对软件进行物理检查，以验证程序和文档已经一致，并已做好了交付的准备。 3) 综合检查(CA)，应验证代码和设计文档的一致性、接口规格说明的一致性（硬件和软件）、设计实现和功能需求的一致性、功能需求和测试描述的一致性。 6 软件配置管理 必须编制软件配置管理计划，规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置工作等四方面的活动。还必须规定用以维护和存储软件受控版本的方法和设施；必须规定对所发现的问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。 7 工具、技术和方法 在软件的研制与开发过程中，都应该在各自的软件质量保证活动中合理地使用软件质量支持工具、技术和方法。这些工具主要有下列三种： 1) 软件配置管理工具，它支持用户对源代码清单的更新管理以及对重新编译与连接的代码的自动组织；支持用户有不同文档相关内容之间进行相互检索并确定同一文档中的涉及范围；同时还应支持软件配置管理小组对软件配置更改进行科学的管理； 2) 文档辅助生成工具与图形编辑工具，它主要协助用户绘制描述程序流程与结构的工作流图(EPMS)与数据流图(DFD)。绘制描述软件功能（输入、输出关系）的曲线以及绘制描述系统特性的一些其他图形，同时还可生成若干与软件文档编制大约相适应的文档模板。用户利用这个工具的正文与图形编辑功能以及上述辅助功能，可以比较方便地产生清晰悦目的文档，也有利于对文档进行更改，还有助于提高文档的编制质量； 3) 数据库设计工具，主要设计完成数据库的逻辑模型与物理模型，同时还可生成与软件文档编制大约相适应的数据字典。 8 媒体控制 为了保护计算机程序的物理媒体，以免非法存取，意外损坏或自然老化，SQA人员按照软件工程小组制订的、且经批准的《软件配置管理计划》妥善管理和存放各个子系统及其专用支持软件的媒体。 9 对供货单位的控制 需要从软件销售购买、委托或其他开发单位开发、从开发单位现存软件库中选用或从项目委托单位或用户的现有软件库中选用软件时，SQA必须参与软件选用评审、测试与检查，只有当演示成功、测试合格后才能批准选用。如果只选用其中部分内容，则按待开发软件的处理过程办理，此时SQA不再干预。 10 记录的收集、维护和保存 在软件的研制与开发期间，要进行各种软件质量保证活动，准确记录、及时分析并妥善保存有关这些活动的记录，是确保软件质量的重要条件。SQA人员负责收集、汇总与保存有关软件质量保证活动的记录。要收集、汇总与保存的记录名字及其保存期限见表1。 表1 记录名称及其保存的期限 记录的名称与分类 要保存的期限 阶段评审 阶段评审总结 整个软件开发周期 记录 阶段评审主要问题 整个软件开发周期 阶段评审成员 整个软件开发周期 日常检查 软件阶段产品完成情况 整个软件开发周期 修改 软件问题报告单 整个软件开发周期 组织 软件质量人员记录 整个软件开发周期 - 13 - 附件二：技术月报 技 术 月 报 （一） 统计日期： 项目信息 项目名称 进度甘特图 项目经理 合同工期 说明：对项目进度的甘特图可另用篇幅，采用Excel格式制作，用不同的颜色 同时体现计划和实际进度状况。 项目进度信息 阶段 计划进度 实际进度 备注 开始日期 结束日期 开始日期 结束日期 1需求分析阶段 2概要设计阶段 3详细设计阶段 4软件编码阶段 5软件测试阶段 6系统试运行阶段 7系统综合验收 说明：阶段产品包括实施计划、需求规格说明书、概要设计说明书、详细设计说明书、测试大纲、 使用手册、维护手册、项目开发总结、源代码清单、配置管理计划等。 质量信息 阶段 质量过程状态 评审状态 评审结果 质量总结 1需求分析阶段 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 2概要设计阶段 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 3详细设计阶段 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 4软件编码阶段 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 5软件测试阶段 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 6系统试运行阶段 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 7系统综合验收 过程跟踪□评审□ 评审□ 复审□ 通过□ 不通过□ 技 术 月 报 （二） 统计日期： 费用信息 项目预算： （人月） 其中项目组： （人月） 其中专题组： （人月） 月份 项目组员 （现场） 项目组员 （非现场） 专题组 （现场） 专题组 （非现场） 其他人员 （现场） 其他人员 （非现场） 房租费 通信费 办公费 招待费 生活用品 差旅交通 奖金 本月 累计 本月 累计 本月 累计 本月 累 计 本月 累计 本月 累计 本月 累计 本月 累计 本月 累计 本月 累计 本月 累计 本月 累计 本月 累 计 1 2 3 4 5 6 7 8 9 10 11 12 合计 技术管理制度及办法之 售后服务管理办法 附件3：软件阶段评审表 在软件开发过程中的适当阶段对软件阶段产品进行评审，是确保软件产品最终质量的重要方法。阶段评审可以对某个开发阶段产品进行评审，也可以对某几个开发阶段产品进行综合评审。在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。 软件阶段评审表由两张子表组成: 1) 评审总结报告； 2) 主要问题的详细描述(软件问题报告单)； l 评审总结报告 　评审总结报告 登 记 号 评审日期 评审性质 评审□ 复审□ 阶段状态 需求分析□ 概要设计□ 详细设计□ 软件编码□ 软件测试□ 安装与验收 □ 软件总开发阶段□ 负 责 人 电话 地址 评审结论 通 过 不需修改 稍作修改 不通过 作重要修改 要重新评审 评审成员 质量管理： 产品经理： 工程总监： 研发总监： 项目经理： 备 注 l 表2：软件问题报告单 软件问题报告单 登记号 登记日期 年 月 日 发现日期 年 月 日 子系统名称 模块名称 模块编码 阶段状态 需求分析□ 概要设计□ 详细设计□ 软件编码□ 软件测试□ 安装与验收 □ 报告人姓名 电话 地址 软件问题 程序 □ 数据库 □ 文档 □ 其它 □ 问题描述/影响： 附注及修改建议： 附件4：软件配置管理计划 软件配置管理计划 产品名称： 编制单位： 产品编号： 文档编号： 版 本 号： 编制日期： 更改日期： 拟制人 审核 批准 1引言 [配置管理计划的简介应提供整个文档的概述。它应包括此配置管理计划的目的、范围、定义、术语定义、参考资料和概述。] 1.1 目的 [阐明此配置管理计划的目的。] 1.2 范围 [简要说明此配置管理计划的范围；它的相关模型，以及受到此文档影响的任何其他事物。] 1.3 术语定义 [本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。] l 软件配置管理，简称SCM(Software Configuration Management的缩写)，是在团队开发中，标识、控制和管理软件变更的一种管理。配置管理的使用取决于项目规模和复杂性以及风险水平。软件的规模越大，配置管理就显得越重要。 l 基线(baseline)，是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 l 功能基线(Functional Baseline)，功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。 l 指派基线(Allocated Baseline)，指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标识。 l 产品基线(product baseline)产品基线是指在软件组装与系统测试阶段结束时，经过正式评审的批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标识。 l 配置控制(configuration control)，对软件任务在开发过程中的资源进行标识，以便识别。 l 配置检查(configuration audit)，对软件配置管理过程中的活动进行检查。 l 配置标识(configuration identification) l 配置状态记录(configuration status accounting) l 软件开发库(Software Development Library)，软件开发库是指在软件生存周期的某一个阶段期间，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。 l 软件受控库(Software Sontrolled Library)，软件受控库是指在软件生存周期的某一个阶段结束时，存放作为阶段产品而释放的、与软件开发工作有关的计算机可读信息一人工可读信息的库。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。 l 软件产品库(Software Product Library)，软件产品库是指在软件生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件的库。 l 接口控制(Interface Control），接口控制是指描述有关由一个或多个部门提供的两个或两个以上的配置项接口的所有功能特性和物理特性的过程。在实现之前，要确保对这些功能特性和物理特性所建议的修改已经过评审和批准。 1.4 参考资料 [本小节应完整列出此配置管理计划中其他部分所引用的任何文档。每个文档应标有标题、报告号（如果适用）、日期和出版单位。列出可从中获取这些参考资料的来源。这些信息可以通过引用附录或其他文档来提供。] l GB/T 11457 软件工程术语 l GB 8566 计算机软件开发规范 l GB 8567 计算机软件产品开发文件编制指南 l GB/T 12504 计算机软件质量保证计划规范 1.5 概述 [本小节应说明此配置管理计划中其他部分所包含的内容，并解释文档的组织方式。] 2 软件配置管理 [描述负责软件配置管理的机构、任务、职责及其有关的接口控制。] 2.1 机构 [本小节描述在各阶段中负责软件配置管理的机构。描述的内容如下： A． 描述在软件生存周期各阶段中软件配置管理的功能和负责软件配置管理的机构； B． 说明项目和子项目与其他有关项目之间的关系； C． 指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的相互关系。] 2.2 任务 [本小节描述在软件生存周期各个阶段中的配置管理任务以及要进行评审的检查工作，并指出各个阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控库或软件产品库）。 ] 2.3 职责 [本小节描述与软件配置管理有关的各类机构或成员的职责，并指出这些机构或成员相互之间的关系。 A．指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责； B．指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系； C．说明由本计划第2.2条指明的生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动； D．指出与项目开发有关的各个机构的代表的软件配置管理职责； E．指出其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。] 2.4 接口控制 [本小节应该描述： A． 接口规格说明标识和文档控制的方法； B． 对已交付的接口规格说明和文档进行修改的方法； C． 对要完成的软件配置管理活动进行跟踪的方法； D． 记录和报告接口规格说明和文档控制状态的方法； E． 控制软件和劫持它运行的硬件之间的接口的方法。] 2.5 实现 [本小节应该规定实现软件配置管理计划的主要里程碑，例如： A． 建立配置控制组； B． 确定各个配置基线； C． 建立接口控制协议； D． 制订评审与检查软件配置管理计划和规程； E． 制订相关的软件开发、测试和支持工具的配置管理计划和规程。] 2.6 适用的标准、条例和约定 [本小节指明所适用的软件配置管理标准、条例和约定，并把它们作为本计划要实现的一部分；描述遵循的具体规范及标准，描述内容可以包括： A．软件库的操作，包括准备、存储