ISO软件开发全套文档 配置管理控制程序

ISO软件开发文档模板_测试和检验控制程序测试和检验控制程序是软件开发过程中必不可少的一环，它能够确保软件产品符合规定的需求和质量标准。

本文将介绍一份常见的ISO软件开发文档模板，包括测试和检验控制程序的主要内容和要求。

一、引言在软件开发过程中，为了确保产品的质量和符合客户的需求，需要进行全面的测试和检验工作。

本文档描述了测试和检验控制程序的计划、内容和步骤，旨在确保软件开发过程的可控性和可追溯性。

二、目的本文档的主要目的是定义软件测试和检验的过程和标准，以确保产品能够满足相关的需求和质量标准。

三、测试和检验计划1.测试和检验计划的制定2.测试和检验计划的审查和批准四、测试和检验的内容1.功能测试2.性能测试3.安全测试4.兼容性测试5.集成测试6.用户验收测试7.缺陷管理和修复8.文档和报告的编写和维护五、测试和检验步骤1.根据测试和检验计划，制定详细的测试和检验步骤2.实施测试和检验步骤，并记录相关的测试结果和问题3.分析和评估测试结果，并提出改进和修复建议4.完成测试和检验报告，包括测试结果、问题汇总和修复情况5.测试和检验结果的审核和确认，确保产品符合相关要求和标准六、测试和检验记录和报告1.测试和检验记录的编写和维护2.测试和检验报告的编写和维护七、问题管理和修复1.问题的记录和跟踪2.问题的分析和评估3.问题的解决和修复4.问题的验证和确认八、持续改进1.根据测试和检验的结果和问题，提出改进和优化建议2.更新相关的文档和流程，确保持续改进的可行性和有效性九、培训和沟通1.培训测试和检验人员，使其熟悉测试和检验过程和步骤2.与相关部门和利益相关方进行沟通，确保测试和检验的顺利进行和结果的传达总结测试和检验控制程序是软件开发过程中必不可少的一环，它能够确保软件产品的质量和符合规定的要求和标准。

本文档提供了一个ISO软件开发文档模板，包括测试和检验计划、内容和步骤的制定和实施，以及问题管理和持续改进的措施。

1目的 (2)2过程定义 (2)2.1范围 (2)2.2过程负责人 (2)2.3主要输入 (2)2.4主要输出 (2)2.5职责权限 (2)2.6过程重要控制点 (2)2.7过程测量指标 (2)3术语 (2)4流程 (2)5过程描述 (2)5.1配置计划 (2)5.2配置定义和标识 (2)5.3建立配置管理数据库 (2)5.4CMDB的控制和维护 (2)5.5配置审计和验证 (2)5.6生成配置报告 (2)6相关文件 (2)7相关记录 (2)8附加说明 (2)9文件历史记录 (2)1目的配置管理流程的总体目的是提供一个统一的、一致的流程来管理售后服务环境中的所有组成部分，以确保：1)所有配置项（CI）被识别和记录下来；2)配置项当前和历史状态得到汇报；3)配置项记录的完整性得到维护和确认；4)客户服务环境的稳定性；5) 实现资产管理的目的。

2过程定义2.1范围配置管理的范围是公司开发的管理信息系统的运行和服务环境下所包含的配置项（CI），包括系统运行环境的部署环境设备、系统软件等，及服务环境中涉及的客户信息配置。

具体活动包括识别、控制、汇报和审核等行为。

包括：●客户信息●软件信息●服务文档：服务项目文档、服务记录、用户手册等；●供应商：供应商信息。

不包括：●处于开发或测试环境的业务系统。

2.2过程负责人配置管理负责人2.3主要输入2.4主要输出2.5职责权限配置管理负责人主要具有以下职责：1)定义并维护配置管理流程文件及所需要的记录模板；2)管理配置管理流程的实施；3)确保配置管理流程目标的实现；4)识别配置管理过程中存在的问题并提出改进措施；5)定期向IT服务管理小组汇报实施过程中存在的问题；6)批准建立配置库基线；7)对配置报告进行核对和审核。

配置管理员主要具有以下职责：1)建立配置管理数据库；2)及时录入各设备、软件、供应商、服务等的配置项信息；3)根据服务需求说明来协调用户之间的联系；4)配置管理数据的完整性和准确性，确保为其他操作管理提供准确的信息；一线支持人员主要具有以下职责：1)识别ITSM配置库中存在的问题并提出改进措施；2)核对并修改ITSM各设备、供应商、服务等的配置项信息。

一、项目开发计划1．引言 (1)1.1编写目的 (1)1.2项目背景 (1)1.3定义 (2)1.4参考资料 (2)2．项目概述 (2)2.1工作内容 (2)2.2条件与限制 (2)2.3产品 (2)2.4运行环境 (2)2.5服务 (3)2.6验收标准 (3)3．实施计划 (3)3.1任务分解 (3)3.2进度 (3)3.3预算 (3)3.4关键问题 (3)4．人员组织及分工 (3)5．交付期限 (3)6．专题计划要点 (3)1．引言1.1编写目的【阐明编写开发计划的目的，指明读者对象。

】1.2项目背景【可包括：a.项目的委托单位、开发单位和主管部门；b.该软件系统与其他系统的关系。

】1.3定义【列出本档中用到的专门术语的定义和缩写词的原文。

】1.4参考资料【可包括：a.项目经核准的计划任务书、合同或上级机关的批文；b.文档所引用的资料、规范等；列出这些资料的作者、标题、编号、发表日期、出版单位或资料来源。

】2．项目概述2.1工作内容【简要说明项目的各项主要工作，介绍所开发软件的功能、性能等。

若不编写可行性研究报告，则应在本节给出较详细的介绍。

】2.2条件与限制【阐明为完成项目应具备的条件、开发单位已具备的条件以及尚需创造的条件。

必要时还应说明用户及分合同承包者承担的工作、完成期限及其他条件与限制。

】2.3产品2.3.1程序【列出应交付的程序名称、使用的语言及存储形式。

】2.3.2文档【列出应交付的文档。

】2.4运行环境【应包括硬件环境、软件环境。

】2.5服务【阐明开发单位可向用户提供的服务。

如人员培训、安装、保修、维护和其他运行支持。

】2.6验收标准3．实施计划3.1任务分解【任务的划分及各项任务的负责人。

】3.2进度【按阶段完成的项目，用图表说明开始时间、完成时间。

】3.3预算3.4关键问题【说明可能影响项目的关键问题，如设备条件、技术焦点或其他风险因素，并说明对策。

】4．人员组织及分工5．交付期限6．专题计划要点【如测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。

产品/ 项目系统名称配置管理计划北京xxxXt限公司200年XX月1 引言1.1 编写目的编写的目的主要在于对所开发的软件系统规定各种必要的配置管理条款，以保证所开发出的软件能满足用户需求。

1.2背景a.开发的软件系统的名称列出本软件系统的中文全称、英文全称及英文表示简称。

b.开发的软件系统的最终用户或适用的领域；c.项目来源、主管部门等1.3定义列出本文件中涉及的专门术语定义和外文缩写的原词组。

1.4 参考资料列出涉及的参考资料。

2 管理描述软件配置管理的机构、任务、职责和有关的接口控制。

2.1 机构描述软件生存周期中各阶段中软件配置管理的功能和负责软件配置管理的机构。

说明项目和自项目与其他有关项目之间的关系。

指出在软件生存周期各阶段中的软件开发或维护机构与配置控制组的关系。

2.2 任务描述在软件生存周期中各阶段的配置管理任务以及要进行的评审和检查工作，并指出各阶段的阶段产品应存放在哪一类软件库中（软件开发库、软件受控制库或软件产品库）。

2.3职责指出负责各项软件配置管理任务（如配置标识、配置控制、配置状态记录以及配置的评审与检查）的机构的职责；指出上述机构与软件质量保证机构、软件开发单位、项目承办单位、项目委托单位以及用户等机构的关系。

说明软件生存周期各个阶段的评审、检查和审批过程中的用户职责以及相关的开发与维护活动。

指出与项目开发有关的各机构的代表的软件配置管理职责。

指出与其他特殊职责，例如为满足软件配置管理要求所必要的批准要求。

2.4定义软件配置项（ SCI）包括：1．系统约定2．软件项目计划3．软件需求文档4．用户手册5．设计文档6．源代码清单7．测试文档a.测试计划和过程b.测试用例和结果记录8．可执行程序a.模块的可执行代码b.链接的模块9．数据库描述a.模式和文件结构b.初始内容10．联机用户手册11．维护文档a.软件问题报告b.维护记录c.工程变化12．软件工程的标准和规程2.5软件配置管理计划的实现规定实现软件配置管理计划的主要里程碑，例如：建立配置控制组确定各个配置基线建立接口控制协议指定评审与检查软件配置管理计划和规程制定相关的软件开发、测试和支持工具的配置管理计划和规程2.6适用的标准、条例和约定可包括如下内容：软件结构层次树中软件位置的标识方法；程序和模块的命名约定；版本级别的命名约定；软件产品的标识方法；规格说明、测试计划与测试规程、程序设计手册及其他文档的标识方法；媒体和文档管理的标识方法；文档交付过程；软件产品库中软件产品入库、移交或交付的过程；问题报告、修改请求或修改次序的处理过程；配置控制组的结构和作用；软件产品交付给拥护的验收规程软件库的操作，包括准备、存储和更新模块的方法；软件配置管理活动的检查；问题报告、修改请求或修改次序的文档要求，指出配置修改的目的和影响；软件进入配置管理之前的测试级别；质量保证级别，例如：在进入配置管理之前，验证软件满足有关基线的程度3 软件配置管理活动。

ISO软件开发全套不合格品控制程序为了确保软件开发过程中的质量和可靠性，ISO（International Organization for Standardization，国际标准化组织）制定了一系列的标准和指南。

而软件开发中的不合格品控制程序则是其中一个至关重要的环节。

本文将详细介绍ISO软件开发全套不合格品控制程序，以帮助开发团队更好地管理和控制软件开发过程。

一、不合格品的定义和识别不合格品指的是与ISO标准和项目要求不符的产品或过程。

在软件开发过程中，不合格品可能出现在需求分析、设计、编码、测试、上线等各个环节。

为了及时发现和处理不合格品，需要制定相应的识别和分类标准。

1.1 不合格品的定义不合格品可以指软件或相关文件中的错误、缺陷、不完整或不一致之处。

它们可能导致软件功能异常、性能低下、用户体验差，甚至安全风险。

1.2 不合格品的识别为了识别不合格品，可以采取以下方法：1）需求复核和验证：与相关方沟通、评审需求文档，确保需求的准确性和完整性。

2）设计和编码复核：通过代码评审、静态分析工具等手段，发现潜在的问题和缺陷。

3）测试：进行系统测试、回归测试、性能测试等，找出软件存在的问题。

4）用户反馈：及时收集用户的反馈，发现并解决用户遇到的问题。

二、不合格品控制程序不合格品控制程序包括以下几个关键环节：记录、分类、评估和处理。

2.1 记录不合格品所有发现的不合格品都应该被记录下来，以便后续的处理和追踪。

记录内容应包括不合格品的描述、识别时间、识别人员、识别环节等。

2.2 分类不合格品为了更好地管理和控制不合格品，需要对其进行分类。

常见的分类方式有：1）严重程度分类：根据不合格品对软件质量和稳定性的影响程度，将其划分为重要、一般和次要等级。

2）类型分类：根据不合格品的性质和来源，将其划分为功能性、性能性、安全性、可维护性等类型。

3）阶段分类：根据不合格品出现的开发阶段，将其划分为需求分析、设计、编码、测试等。

某某有限公司设计开发控制程序文件编号：QY1S/QP-07版本号：A/0受控状态：受控分发号：_______________持有人：_______________编制：日期：2023-06-01审核：日期：2023-06-01批准：日期：2023-06-01发布日期：2023-06-01实施日期：2023-06-01确保本公司新产品的开发工作有计划有依据，并能保证满足客户的要求及合适的成本时进行生产。

2.0适用范围本程序适用于公司新产品的开发过程控制。

3.0职责和权限3.1业务部：3.11新产品开发过程中有关原料之计划、输入、输出、评审、验证、确认、更改等各阶段的实施，确保产品开发符合设计开发要求；3.1.2客户意图和要求与研发人员进行沟通。

3.1.3负责开发过程中的外购物料、灌装量、包装方法的确认。

3.2研发工程师：对新产品的调试和生产工艺的设计，参与质量的检测、输入、输出、评审、验证、确认、更改各过程，负责填写相关记录。

3.3品管部：负责新产品样板和新产品生产中质量的检测。

3.4总经理：新产品开发项目的批准。

根据市场信息需求的反馈及顾客开发意向的确认，签发《产品开发进度表》；参与新产品开发各阶段输出的评审并进行审批。

4.0工作程序：4.1设计和开发的策划4.1.1新产品开发方案的提出：业务部根据市场信息或顾客需求等结合公司实际，每季度制订《产品开发进度表》，将新产品开发的意向通知研发人员及相关部门，《产品开发进度表》必须得到总经理的批准，内容包括；A、新产品名称；B、市场促销方式和销售渠道；C、预计开发周期，包括生产周期和出货时间；D、资源配置需求，包括生产数量，品种，设备、资金及成本等；E、开发过程的项目主要责任人。

4.1.2业务部根据总经理批准的《产品开发进度表》，按开发进度编制《新产品包装造型结构表》,发放到相关部门，同时应明确A、产品的开发设计方案名称、新产品名称类型；B、产品相关结构、特性要求；C、与产品相关法律法规、标准的要求的相关信息；D、设计开发输入、输出、评审、验证、确认等各阶段的划分、时间进度安排和各阶段责任人的职责和权限；4.1.3《产品开发进度表》确认前，总经理或授权人应召集产品业务部、、生产部的部门负责人进行评审；评审应形成明确的结论。

ISO27001-软件开发安全控制程序软件开发安全控制程序（依据ISO27001标准）1. 目的为规范公司软件开发的安全管理，包括软件系统从计划、需求、设计、开发、测试、部署过程中的安全管理，特制定本程序。

2. 范围本程序适用于公司的软件系统在需求分析、开发测试、上线运行阶段的安全管理，包括软件外包开发的安全管理。

3. 职责与权限3.1 技术部负责公司相关信息系统的软件开发、外包软件开发过程的安全管理，以及软件开发相关文档及软件源代码的归档保管。

3.2 其他部门其他相关部门协助技术部进行软件/系统需求收集、分析、系统测试等工作。

4. 相关文件a)《软件控制程序》5. 术语定义无6. 控制程序6.1 软件开发任务提出公司根据客户反馈和调研，编写用户需求分析报告，经过公司总经理批准后，交付技术部进行设计开发。

6.2 软件开发的策划技术部在接到用户需求后，首先要判断可行性，如果接受，技术部根据用户申请书和要求部门共同协商，编写软件设计开发计划，明确设计开发的各个阶段评审与测试要求及设计开发人员的职责与权限，设计开发计划方案由要求部门和技术部负责人共同批准后予以实施；必要时，如果对计划进行更改也需要获得双方经理共同批准。

软件设计开发计划应包括以下内容：a)软件功能要求；b)详尽的业务流程；c)信息安全要求；d)时间进度要求；e)设计开发的各个阶段评审与测试要求；f)设计开发人员的职责与权限；g)其它要求，例如在复杂系统环境下，应考虑业务信息系统互联相关的信息，并考虑安全保护。

6.3 软件开发方案的评审及开发过程控制6.3.1技术部应根据软件设计开发计划的要求，编制软件设计开发方案，由技术部负责人对方案的技术可行性及系统的安全性进行确认。

6.3.2对于大型软件开发方案应由设计开发人员、应用部门（用户）人员、内部IT 方面的专家共同进行评审。

方案确认与审批的结果及任何必要的措施应予以记录。

6.3.3软件设计开发方案应包括以下内容：a)确定软件开发工具；b)应用系统功能；c)业务实现流程；d)输入数据确认要求；e)必要时，系统内部数据确认检查的要求；f)输出数据的确认要求；g)应用系统的安全要求；h)对系统硬件配置的要求；i)系统验收标准。

软件配置管理规范流程Is the eternal love the truth. December 22, 20211概述目的本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性;适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减;配置管理可采用各种工具及手工办法,本文件以CVS并行版本系统配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行;术语和缩略语软件配置管理Software Configuration Management,SCM软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程;是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施;配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置;配置项Configuration Item,CI凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的;每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等;所有配置项都被保存在配置库里,确保不会混淆、丢失;配置项及其历史记录反映了软件的演化过程;基线Baseline在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”;每一个基线都是其下一步开发的出发点和参考点;基线确定了元素配置项的一个版本,且只确定一个版本;一般情况下,基线一般在指定的里程碑处创建,并与项目中的里程碑保持同步;每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其修改要严格地按照变更控制的过程进行;在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线;基线的主要属性有：名称、标签、版本、日期等;权限与职责研发总经理助理1 审核变更请求;项目经理Project Manager,PM1 审核批准配置管理计划；2 接收或拒绝小范围的变更申请；3 召集评估变更；4 提出配置管理的建议和要求；5 配合配置管理员的工作;配置管理员Configuration Management Officer,CMO1 编写配置管理计划；2 执行版本控制和变更控制方案；3 制定访问控制策略；4 负责项目的配置管理工作,包括搭建环境、权限分配、配置库的建立、配置项的控制等；5 配置管理工具的日常管理与维护；6 配置库的日常操作和维护；7 负责配置审核并提交报告；8 根据配置部署表单编译发布版本,并维护版本；9 对开发人员进行相关的培训；10 对配置审核中发现的不符合项,拟订纠正措施,要求相关责任人进行纠正;11 监督项目组成员规范的执行情况;开发人员Developer1 根据确定的配置管理计划和相关规定,提交配置项和基线；2 负责项目组内部测试；3 负责软件集成和版本生成；4 按照软件配置管理工具的使用模型来完成开发任务;2 实施细则配置项管理配置项的范围软件配置可包括以下几方面：开发文档,代码,第三方控件、插件,参考资料,测试文档,用户文档,项目管理文档,验收文档等;l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录;l 代码主要指：源代码等;l 工具主要指：脚本文件、插件、第三方控件等;配置项基线管理结合SPP和ISO9000的相关规定,配置管理员根据配置管理规范及配置管理计划,对配置项进行分阶段管理,每一阶段正式评审通过后纳入受控库,作为该项目的一个基线;l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档,评审或审批通过后建立发布基线;l 需求阶段：系统调研后开发人员进行需求分析,并整理产品需求规格说明书;产品需求规格说明书经过客户的确认后,建立需求基线;如需升级版本则必须通过评审或审批并得到客户的确认;l 项目计划：需求分析完成后即可制定项目的开发计划,包括项目计划和主要下属计划;包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划;项目开发计划评审通过后,建立项目计划基线;l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计;针对用户需求规格说明书进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系;设计说明书评审或审批通过后,建立设计基线;l 编码设计实现：编码按功能模块分子项目,即每个模块记作一个配置项;代码在提交项目组系统测试时建立Beta版本,系统测试产品正式发布后建立Version版本;l 测试：单元测试和系统测试;单元测试通过提交单元测试报告,项目启动后应提交系统测试计划,系统测试完成后应提交系统测试报告;配置时应说明测试的版本与编码版本的对应关系;系统测试完成后建立测试基线;l 版本发布：项目组提交部署表单,CMO根据部署表单进行编译,发布测试服务器上,并对版本进行维护;同时将发布的版本上传到文档服务器上备份;l 交付与验收：在交付前配置审核完成后建立产品基线,产品基线包含程序以及有关文档配置项,包括交付文档、代码、工具等;l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档;l 相关资料：相关资料也应作为配置项纳入配置管理,此部分包括：1 相关法律、法规；必须遵照或项目组约定的技术规范；2 与客户或项目组内部重要的交互信息记录,如会议记录、会谈记录、e-mail和MSN记录等；版本控制文档的版本控制所有文档的管理纳入配置管理库,用版本控制工具进行统一管理;文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现,主要分为以下几类：版本变化型文档命名方式：文档名称+子系统名称可选适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等;示例：项目计划.doc详细设计_SP门户.doc标签结构：大版本 + 子系统简称 + 版本号 + 日期标签控制说明版本信息l 大版本：可选 ,表示同一项目为不同用户定制的版本;l 子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;l 版本号：采用Vs_x_y的形式;l 日期：纳入基线管理的日期,用8位表示,如说明：a.文档发布名称采用文档名+ Vs_x_y的形式,文档的版本号应该和版本控制工具中相应标签上的版本号一致;b. 对文档的修改需要从配置管理库中取到本地进行;c. 对于文档小的修改,如文字错误,格式调整,变更Vs_x_y中的y来区别如：V1_0_1;d. 文档内容没有大的增加和删节,意思表述没有发生重大的变化,版本标识通过版本工具中加上x标签来表示如：V1_1_0,以及在文档内部控制页标注变化来表示;e. 文档有重大增加和删节,意思表述有重大变化的,版本标识通过在相应文档加上s标签来表示如：V2_0_0;f. 对于纳入基线库的文档的修改需要提交变更申请,经批准才能进行修改,并且修改的内容要经再次评审才能重新纳入基线库,作为后续阶段的参考文档;时间区别型文档命名方式：文档名称＋撰写时间适用文档：文档名称有明确的含义,需要用时间标识的日常性文档;如周例会会议纪要,项目月计划,项目月总结,阶段性计划等等;示例：周例会会议纪要时间序号型文档命名方式：文档名称+人员姓名拼音+撰写时间+序列号适用文档：测试报告示例：单元测试报告其他文档：对于不能按照前四种类型进行命名的文档会议纪要：会议纪要YYYYMMDD示例：9月9日召开的项目启动会命名为：会议纪要项目启动.doc评审报告：评审报告YYYYMMDD同”会议纪要”要求一致;示例：10月9日召开的项目总体方案评审命名为：评审报告总体方案.doc发行版本表示发行版本采用标签说明,结构如下：大版本 + 版本类型 + 版本号 + 子系统简称拼音+日期 +序号大版本：可选 ,表示同一项目为不同用户定制的版本;子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;版本类型：分为3种Beta表示项目组内部测试,标签：Release系统测试,标签：Version正式发行版,标签：版本号对于Version正式发行版是必须要注明的,而其它可选;发行产品基线在版本号前加Version,如Version_1, Version_2,Version_3….表示分支；Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签；Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签;配置库管理配置库的分类配置库统一由配置管理员负责管理,服务器端使用,客户端主要使用乌龟CVS;配置库目录结构如下：配置库的建立所有项目应建立配置库,以便管理各配置项,配置管理员组织建立配置库;程序库主要通过设置版本的分支来实现对配置项权限管理：1开发库：开发人员相对比较自由的存储空间,开发人员可以在自己的权限范围内任意取出提交;2基线库：配置管理员有最高权限,其余相关人员均为读的权限,发生变更时变更人员须提交变更申请后方可修改基线库内的配置项;文档评审通过后,文档严格受控;由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除;代码一般在移交系统测试时纳入基线库受控,可根据项目的具体情况设置基线;3产品库：产品库的产品均出自于基线库,产品库存储的产品用于交付和存档;配置三库统一由配置管理员管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作;在变更发生时,应及时做好基线的推进;分配权限项目开始后配置管理员编写配置库目录结构表明确项目组成员以及相关人员的权限;在wincvs里有三种权限,读r、写w、添加删除c权限;在开发库内,文档部分项目组成员有rcw权限,其他相关人员只r权限；代码部分项目组成员有rcw权限,其他相关人员没有任何权限;在基线库内,项目组成员仅有r权限,其他相关人的权限视情况而定;在产品库内,所有人没有任何权限;配置管理员在三库内均拥有最高权限;配置变更控制变更的分类软件及其相关文档的变更按照变更的影响范围进行分类：1A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认;2B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可;3 C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准;系统测试前变更控制流程：系统测试完毕发布release版本后变更控制流程图2 变更控制流程变更请求的提出a．由技术支撑中心汇集顾客意见,影响到需求变更则填写配置项变更控制报告,并提交给配置管理员;b．配置管理员对申请表是否清晰、明确和完整性进行审查,若发现变更不明确或不完整,应返回申请者;对通过审查的变更申请分配变更ID,以便跟踪和记录变更信息;评估变更a．配置管理员将配置项变更控制报告发送给项目经理或者其他授权人员,由项目经理负责对变更进行评估;b．项目经理对变更进行分解,一般的BUG修正不需要审批直接由项目经理决定是否需要变更;新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更;变更评估文档在完成变更评估后发送给配置管理员;变更实施和确认a．变更被批准后,项目经理提交变更实施进度计划,开发人员开始实施变更,并详细记录变更的内容；质量部对变更的实施进行跟踪;b．对于代码变更,必须进行回归测试,以确保变更没有引入新的Bug;另外与变更相关的文档必须修订,以反映变更;当变更以及测试完成后,进行提交;c．通过测试后,质保人员需对变更进行审核,审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号;a．审核后,由配置管理员更新到基线库中;配置状态报告目的记录和报告整个软件生命周期演化状态;记录内容配置状态报告记录的内容包括：1 软件和文档的标识；2 目前状态；3 基线演化状态；4 变更状态；5 版本交付信息等;生成报告配置管理报告自第一个基线创建时建立,由配置管理系统生成,及时反映当前配置状态;配置审核类别配置审核分为：1功能配置审核Functional Configuration Audit,FCA：审核软件功能是否与需求一致,并符合基线文档要求,通常要审查测试文档等;2 物理配置审核Physical Configuration Audit,PCA：审核要交付的组成项是否存在,是否包含所有必需的项目,如正确版本的源代码、资源、文档、安装说明等等;执行时机通常选择以下几种情况由质量保证人员负责实施配置审核：1软件产品交付或是软件产品正式发行前；2软件开发的阶段工作结束后；3在产品维护工作中,定期地进行;不符合项处理对配置审核中发现的不符合现象,配置管理员进行记录,并交由责任部门限期进行纠正,配置管理员负责纠正措施的验证;所有的不符合项报告均关闭后,才能发布新版本;发行管理通过配置审核后,经项目经理批准,由配置管理员负责生产新版本;交付管理这里“交付”是指从配置库中提取配置项,交付给客户或项目外的人员;交付出去的配置项必须有据可查,避免发生混乱;流程如下：1交付人向质量部申请；2质量部如果不同意交付,则拒绝交付配置项;如果同意交付,配置管理员应给出详细的交付清单；3交付人验收后签字;。

质量管理体系文件软件研发控制程序文件编号：QP/XXXX-X. X（根据GB/T 19001 idt ISO 9001:2000编写）编制: 审核: 批准:年月日年月日年月日修改状态栏1目的描述软件研发项目从开始到结束经历的各个阶段，明确各个阶段的先后次序，说明每个阶段输出的质量记录及所遵循的规范，明确相关人员的职责，为提高整个软件开发水平，提高项目及软件产品质量提供有力保障。

2适用范围适用于软件研发项目管理的全过程。

3术语和定义本程序采用ISO 9000:2000质量管理体系基础和术语》中的术语和定义。

4职责4.1总经理：大型项目上，组织人员进行项目立项报告编制，项目经董事会批准后，召开协调会，向研发部经理下达“任务委托书”；参与评审“产品研发项目计划”；控制研发项目的进度。

负责跨研发部门的协调和管理。

4.2技术委员会：为产品研发提供技术指导与支持。

4.3研发部经理：选择合适的项目负责人，研发部内部项目资源的分配和协调；评审项目计划书、项目需求设计和技术设计；研发部内部跨项目的协调和管理；项目质量监督，查看项目负责人的周报；项目考核，人员考核等。

4.4项目负责人：配合总经理和技术委员会完成项目任务书；负责项目的整体运行，保证项目在此流程的控制之下，进行项目计划的编制，组织评审及项目任务的分工，人员调配，项目汇报等管理工作，并确保整个项目的文档化管理。

4.5项目成员：负责完成项目负责人布置的工作任务，并按照规范及时准确填写各种质量记录，高质量的完成项目所需的各种技术文档，确保项目运行有完整详细的文档记录和高质量的软件。

4.6软件测试人员：负责软件的测试说明书的编写，软件的测试和软件质量的保证。

4.7技术文秘：负责配置管理软件的日常维护，培训工作。

视项目规模及人员配置部分职责可以兼任，如软件测试兼技术文秘。

5工作程序5.1项目立项阶段5.1.1编写立项建议书立项建议书由项目的发起人编写，可以是市场营销部、应用服务部等；主要内容为市场营销分析、成本效益分析、技术方案分析，更多内容见《项目立项建议书编制规范》。

目录1. 前言11.1 目的11.2 术语11.3 参考文献11.4 版本说明和修改历史12. 软件文档12.1 文档的定义及作用12.2 软件文档的分类22.3 软件文档的制作与软件生存周期之间的关系3 2.4 文档的使用者33. 文档编制格式规范43.1 文档编码规则43.2 文档组成格式43.2.1 封面43.2.2 目录63.2.3 版本更新说明63.2.4 文件内容63.2.5 正文格式63.3 文档制作工具74. 文档管理规范74.1 文档管理岗位职责74.2 文档的制作74.2.1 文档的分类、编码与标识84.2.2 文档的作者、修改者和打字者84.3 文档的收集84.4 文档的配置84.5 文档的控制84.6 文档的修改管理94.7 文档的借阅和复制管理制度94.8 文档的保密性95. 技术文档的质量评价101.前言1.1 目的软件开发的不同阶段都会产生大量的文档。

为了加强管理、提高工作效率，充分借鉴前人的经验，对文档进行规范化管理是很有必要的。

它对于保管在开发中形成的文档，为公司积累宝贵的技术知识的财富，为今后的软件开发工作提供第一手的宝贵资料起着重要的作用。

为了规范创智集团工程项目的开发工作，根据国家标准局制定的有关软件开发和开发文件的规范标准，结合公司的实际，制定本规范。

1.2 术语略。

1.3 参考文献1)《1998计算机软件工程规范----国家标准》中国标准出版社1998年6月第一版。

2)《软件工程概论》郑人杰等清华大学出版社1998年4月第一版。

3)《实用软件工程》郑人杰等清华大学出版社1997年4月第二版。

4)《创智软件园文档管理规范》创智（湖南）软件园有限公司1996年5月。

5)《创智软件园软件开发管理规范》创智（湖南）软件园有限公司1995年12月。

1.4 版本说明和修改历史本规范是在公司原有文档规范的基础上，于1999年05月份修订而成，具体的修订人员为孙继纲、赵海等。

受控状态：编制：审核：批准：XXX Precision Equipment Co., Ltd文件修改记录1.目的有效控制公司各类文件，确保文件各使用处所使用的文件为最新或有效版本。

2.适用范围适用于与质量体系相关的规范性的文件控制。

3.职责3.1 管理者代表负责质量手册的组织编制、修订和审核，总经理批准。

3.2 程序文件由相关部门的负责人组织编制、修订，管理者代表审核，总经理批准。

3.3 作业指导书由相关部门负责人组织编写、修订和审核，部门负责人审批。

3.4 质量部负责所有受控文档的归档、登记、发放、回收、销毁及原稿保存。

3.5 文件使用单位负责使用文件的保管，负责旧版和作废文件的收集和回收。

5. 作业程序与控制要求5.1 新文件取号、编号5.1.1 文件编制者根据编号规则从文件管理员处获取编号，并填写“文件取号登记表”记录文件名及文件号。

5.1.2 编号规则5.1.2.1 编号结构1)部门文件2）质量体系文件5.1.2.2 文件类型代码质量手册-QM程序文件-QP记录、证据-QR管理文件-M流程文件-P作业指导书-W5.1.2.3部门代码表单、记录编号时，在对应的管理文件、程序文件后加“-流水号”，以“-001”开始,表单或记录无版本例：《质量管理手册》 QM-M-001《量具保养管理规定》 QD-M-003/A0《刀具管理规定》 SC-M-002/A1《人力资源控制程序》RS-P-004/B0《文件控制流程》 QP-P-001/AO《蔡司三坐标保养规定》QD-M-003/A0《蔡司三坐标日常点检表》QD-M-003-0015.2 文件编写5.2.1 手册和程序文件由管理者代表组织编写5.2.2 工程部负责编制设计文件，包括技术标准、采购规范、图样、工艺文件等。

5.2.3 其他管理文件、作业指导书由相关部门组织编写。

5.2.4 同一文件刊头、刊尾、封面的编写格式要统一，内容格式不做统一要求。

5.3 文件的审批5.3.1 手册、程序文件由管理者代表审核、总经理批准。