软件开发质量体系程序文件

一、 合同评审规程
二、 产品立项规程
三、 需求规程说明规程
四、 开发策划规程
五、 设计规程
六、 实现规程
七、 测试规程
八、 内部测试规程
九、 系统测试规程
十、 复制规程
十一、 交付和安装规程
十二、 验收规程
十三、 项目结项规程
十四、 维护规程
十五、 用户手册编写指导规范
十六、 产品度量规程
十七、 过程度量规程
十八、 规则、惯例和约定控制规程
十九、 配套软件产品控制规程

合同评审规程
1．目的
本开发中心建立合同评审以及协调这些活动的规程，以确保合同反映了用户的要求，而且本开发中心有能力满足这些要求。
 
2. 说明
由于本开发中心不直接承接计算机应用系统开发合同，而是由新和数码公司与用户签定合同，然后再委托本开发中心开发其中的软件部分。因此本开发中心负责评审合同中的软件部分和软件与硬件接口部分及适应性。
 
3. 适用范围
适用于本开发中心的合同情况下软件开发的合同评审活动及合同修订的控制。
 
4. 职责
4.1. 合同评审委员会按规程文件的要求进行合同的评审工作。
4.2. 新和数码科技公司提供与合同有关的用户方面的信息。
4.3. 开发项目组回答合同有关的技术问题。
4.4. 技术办公室通过制定工作程序文件对合同评审工作进行管理。

5. 程序
5.1. 合同评审委员会的组成
当新和数码科技公司或开发中心接到合同意向时，即由有关人员组成合同评审委员会。合同评审委员会由新和数码科技公司销售人员、技术人员（可兼任）、及相关开发项目组的负责人或其指定代表组成，委员会主席由开发中心负责人或其指定的代表担任。需要时，合同评审委员会主席可邀请其他人员参加。合同评审委员会不是常设机构，负责在软件生存周期中对合同进行解释及修订。
5.2. 检查和评审
合同评审委员会应对合同的内容进行检查和评审。
以确保：
合同的范围和需求已明确；
开发中心有能力满足合同要求；
规定开发中心对分供方工作的责任；
用户有能力履行为完成合同开发而提供的协助职责。
 
5.3. 初评
合同评审委员会首先依照合同意向或草稿，根据本开发中心的能力以及需方的条件，决定是否放弃或是进一步联系，或是进行投标准备。
经过初评后，若决定放弃合同或投标意向，则结束评审活动；否则进入合同评审或投标阶段。
 
5.4. 投标阶段
5.4.1. 合同评审委员会组织对标书进行评审，可采用会议的方式，并保存评审记录；

5.4.2. 在已决定投标后，合同评审委员会根据评审意见，责成相应项目组按照需方的要求制作投标书，经相关人员确认、签字后，送至需方。

5.5. 合同评审
5.5.1. 合同评审委员会应对合同中的技术及质量条款进行评审，确认合同已对产品的功能及性能，验收准则，交货期限，维护责任，需方提供的配套产品或是支持条件等进行了规定，并识别可能出现的意外或风险。合同评审时对产品功能及性能的评审，只是确认目标、范围以及要求已清楚，细节要求可在需求规格说明书评审时进行。
 
5.5.2. 意外情况及不确定项的处理

5.5.2.1. 对可能出现的意外情况和风险以及评审时不能确定的事项，合同评审委员会应在评审报告中特别列出，以引起执行部门的重视，并规定排除此种意外情况或风险的期限。对评审时不能确定的事项，也要规定确定的最后期限及验证标准。
 
5.5.2.2. 合同谈判期间，若经上述评审后定稿的合同草案有实质性变动，应按本规程5.5.规定的程序重新评审。
 
5.5.3. 评审结论
合同评审委员会应对是否批准合同作出明确的结论。如果作出不接受该合同的结论，应做好记录后移交技术办公室存档，并委托新和数码科技有限公司通知需方，评审活动即告结束；如果认为需要同需方重新谈判部分条款后可考虑接受该合同，则应在谈判后按本规程5.5.规定的程序重新评审。

5.5.4. 对于评审通过的合同，合同评审委员会应编写《合同评审报告》，报开发中心开发负责人审批。
 
5.5.5. 合同执行过程中的修改。
在合同执行过程中, 经任何一方提出，双方同意对合同做出修改后,须按本
规程规定的程序重新进行评审。如双方沟通成功, 其达成的合同修改协议应作为合同补充文本进入合同文档中生效。合同评审委员会编写《合同变更评审报告》 ，并负责将合同修改记录传递给技术办公室、项目组等相关部门。
 
5.6. 变更合同的评审人员
对合同变更的评审可由原评审委员会进行，也可重新组成评审委员会。
5.7. 特殊合同的处理。
对于项目组成员不超过两个，且开发周期（到系统测试为止）不超过六个月的合同，或是由外地分公司签订的合同，可以不组成合同评审委员会，而由合同当事人，按合同评审要求直接起草意见，由项目组负责人或新和数码科技有限公司副总经理以上的负责人签字后予以确认。
对于因时间紧急或其它特殊原因而不能在合同签订之前进行评审的合同，应在合同签订一个月内，按本规程5.5.规定的程序组织评审。这种评审的重点是合同的风险以及不确定因素，并制定风险控制的措施以及明确不确定因素的方法。如果必要应考虑与用户谈判对合同的修改。
 
5.8. 合同评审记录的保存
合同评审记录由合同评审委员会进行收集、整理、并交由项目组保存； 合同评审记录的保存期限至少截止到合同完结后的一年。
 6. 相关程序文件
《更改控制规程》

《产品开发文档控制规程》

《质量记录控制规程》
 7. 质量记录
《合同评审报告》

《合同变更评审报告》
 
8. 输出产品开发文档
《产品合同书》

重庆CMMI认证★重庆ISO27001认证★重庆ISO20000认证★重庆ITSS认证★四川CMMI认证★四川ISO27001认证★四川ISO20000认证★四川ITSS认证

 
附录1：
《合同变更评审报告》

DT-Q1-01-01-01-2002
合同变更评审报告
序号：
项目名称：
用户名称： 联系人：
评审委员会成员：

主席：
评审日期：    200   年   月    日
项目进行阶段：□需求分析  □设计  □实现 □测试  □维护  
其它：
更改要求简介：

受影响阶段：□需求分析  □设计  □实现 □测试  □维护  
其它：
受影响部门：
处理意见：
主席签名：                             日期： 200   年   月    日
备注：

产品立项规程
1. 目的
对开发中心自主产品开发的立项活动做出规定，以确保被立项的产品满足潜在用户的需要，有市场竞争力，且开发中心有能力在规定的时间内完成该项产品的开发。
 
2. 适用范围
适用于本开发中心的自主产品设立以及原有产品版本升级的立项申请及评审活动。
 3. 职责
3.1. 产品立项发起人编写立项申请报告；
3.2. 新和数码科技有限公司提供对被立项产品的市场需求信息；
3.3. 产品立项发起部门回答有关问题；
3.4. 开发中心负责人组织评审活动。
 
4. 程序
4.1. 自主产品立项的发起
4.1.1. 当开发中心根据市场调查情况，有确立新产品开发的意向时，由相关的项目组指定人员作为产品的立项发起人。
4.1.2. 当原有产品因功能改进或其它原因（不包括为修正原版中遗留的错误）而开发一个新的版本时，由原项目组作为该版本（也称为产品）的立项发起人。

4.2. 产品立项评审委员会的组成
产品立项评审委员会由公司销售人员、技术人员（可兼任）和开发中心的有关人员组成。开发中心的有关人员是指：开发中心负责人，产品立项发起人，产品立项发起项目组负责人，与被立项产品有配合关系的项目组负责人及被评审委员会主席邀请的其它人员。
 
4.3. 产品立项评审的目的
确保：
立项产品的范围和目标已明确；
按以上目标开发的产品在市场上是有竞争力的；
开发中心有能力开发出达到以上目标的产品。
 4.4. 编制《产品立项申请书》
产品立项发起人根据开发中心提出的产品开发意见，在进行了有关调研活动后，参照《产品立项申请书》模板编写《产品立项申请书》。《产品立项申请书》应包括以下内容：
背景情况介绍
产品开发目标
产品主要功能描述
产品市场情况预测
可行性分析
风险及不确定情况分析
产品开发所需资源及进度安排
同类产品情况介绍
4.5. 立项评审
4.5.1. 产品立项评审委员会应对《产品立项申请书》中的技术条款进行评审，确认申请书已对产品的功能和性能做了明确的描述，并识别可能出现的意外或风险。立项评审时对产品功能及性能的评审，只是确认目标、范围以及要求已清楚，但不包括细节要求。
 
4.5.2. 产品立项评审委员会还应评审立项产品的市场销售前景。
 
4.5.3. 产品立项评审委员会应特别评审立项产品开发对资源的要求以及进度安排的可行性，应考虑的因素有：
产品开发所需资源能否充分保证；
开发人员是否具备所需的技术及技能；
产品开发如需其它部门支持，这种支持有无可能实现；
与立项产品配合使用的上下游产品的开发进度，使用上的衔接；
产品开发有无合适的项目负责人。
 
4.5.4. 意外情况及不确定项的处理
对可能出现的意外情况和风险以及评审时不能确定的事项，立项评审委员会应在评审报告中特别列出，以引起执行部门的重视，并规定排除此种意外情况或风险的期限。对评审时不能确定的事项，也要规定确定的最后期限及验证标准。
 
4.5.5. 评审结论
立项评审委员会应对是否批准产品立项做出明确的结论。如果作出不批准该产品立项的结论，则做好记录后移交技术办公室存档，评审活动即告结束；如果认为立项报告有重大疏漏或有问题而需进行补充，则责令产品立项发起人在对《产品立项申请书》进行修改后重新按本规程的要求进行评审。如果《产品立项申请书》中存在部分问题，但对这些问题的解决办法在评审中已达成共识，则可以在批准产品立项后，由产品立项发起人按评审意见实施修改；
对于评审通过的产品立项，立项评审委员会应编写《产品立项评审报告》，报开发中心负责人审批。
 
4.5.6. 执行过程中的变更
在产品立项批准后进行开发的过程中, 当对《产品立项申请书》中规定的目标进行实质性修改时, 必须按本规程4.5.规定的程序重新进行评审，并将评审结果通知有关部门，此种评审也可重新组成评审委员会进行。
 
4.5.7. 评审记录的保存
评审记录由立项评审委员会进行收集、整理，并交项目组保存。
 
4.5.8. 立项产品的备案
立项产品通过评审后，项目组应通知过程管理组，进行备案。
 
4.6. 小项目的立项处理
对于项目组成人员不超过两个，且开发周期（到系统测试为止）不超过六个月的小项目的立项，可以不组成立项评审委员会，而由立项发起人按立项评审要求直接起草评审意见，由开发中心负责人签字后予以确认。
 
5. 相关规程
《更改控制规程》

《产品开发文档控制规程》

《质量记录控制规程》
 
6. 质量记录
《产品立项申请书》模板

《产品立项评审报告》
 
重庆CMMI认证★重庆ISO27001认证★重庆ISO20000认证★重庆ITSS认证★四川CMMI认证★四川ISO27001认证★四川ISO20000认证★四川ITSS认证

三、需求规程说明规程
1. 目的
对软件产品需求分析活动进行控制，明确需求规格说明书的要求。
 2. 适用范围
适用于开发中心开发产品的用户需求分析活动。
 
3. 职责
3.1. 开发中心负责人指定人员组成用户需求分析小组，并委任负责人。
3.2. 用户需求分析小组了解用户的需求，并编制《用户需求规格说明书》。
3.3. 新和数码科技有限公司协助了解用户需求。
3.4. 开发中心负责人按规程文件要求组织对照需求规格说明书的评审。
3.5. 技术办公室通过制定工作程序文件控制需求分析与需求规格说明书的评审工作。

4. 程序
4.1. 在合同通过评审后或潜在用户意向明确后，按照开发中心业务划分，由对应的项目组负责产品的开发任务。开发中心负责人指定人员组成用户需求分析小组，并委任负责人。
 
4.2. 用户需求分析小组与新和数码科技有限公司共同进行用户需求分析工作。
 
4.3. 用户需求分析应了解以下主要的内容：
用户业务中与待开发的产品有关的部分；
用户的工作流程；
用户的相关部门及职责；
产品的使用人员的技术水平；
产品与用户原有系统的接口；
用户原有系统的情况；
用户对产品的期望；
用户对产品的具体要求。
 
4.4. 在进行用户需求调研时，应进行必要的记录，并整理保存。
 
4.5. 在充分了解用户需求的基础上，用户需求分析小组编写出《用户需求规格说明书》。《用户需求规格说明书》的要求参见《用户需求规格说明书》模板。该模板规定了《用户需求规格说明书》的内容和要求，编写时可根据具体的项目/产品的情况进行调整。必要时，可在有关的章节中引述其它资料作为附件。
 
4.6. 《用户需求规格说明书》应当经过评审，并由开发中心负责人审批。

4.7. 《用户需求规格说明书》经评审和审批后，应纳入基线，按《配置管理规程》进行管理。
 
4.8. 无论是用户原因还是开发中心自身原因，需对《用户需求规格说明书》进行修改时，执行《更改控制规程》。

5. 相关规程
《更改控制规程》

《配置管理规程》
 
6. 质量记录
《用户需求规格说明书》模板

《用户需求规格说明书评审报告》
 7. 输出产品开发文档
《用户需求规格说明书》

《用户手册》初稿

 
附录1：
DT-Q1-01-03-01-2002
用户需求规格说明书评审报告
序号：
项目名称： 项目类型：合同         自主产品
用户名称：
评审组成员：

组长：
评审日期：    200   年   月    日
评审活动记录：

不确定事项及处理办法：

评审结论：

组长签名：                          日期： 200   年   月    日
开发中心负责人意见：

签名：                              日期： 200   年   月    日
备注：

重庆CMMI认证★重庆ISO27001认证★重庆ISO20000认证★重庆ITSS认证★四川CMMI认证★四川ISO27001认证★四川ISO20000认证★四川ITSS认证

四、开发策划规程
1. 目的
规定具体产品整个生存周期中的各种计划及质量保证措施，使产品开发的全过程在规范化的规程指导下进行，预防、控制及消除可能发生的失误和缺陷。
 2. 适用范围
适用于产品开发初始阶段所进行的策划活动。
 
3. 职责
3.1. 项目组长编制《开发计划》和《质量计划》。
3.2. 支持经理编制《配置管理计划》，开发环境的安装、调试和维护工作。
3.3. 测试组长编制产品的《测试计划》。
3.4. 开发中心负责人审批上述计划。

4. 程序
4.1. 制定项目的《开发计划》
项目组长根据合同/产品立项书和需求规格说明书，编制项目《开发计划》。项目《开发计划》应包括以下内容：
项目描述；
项目开发资源描述；
开发阶段的划分及各阶段的输入输出描述；
进度安排；
不同部门间的接口与协调；
开发工作应遵守的规则、惯例和约定，开发使用的工具与技术。
 
4.2. 编制《质量计划》
4.2.1. 质量计划是质量体系在具体产品开发中的实施方案，是质量策划的文件性结果。
 
4.2.2. 项目组长根据项目的规模、目标、开发周期等具体情况编制《质量计划》。
 
4.2.3. 《质量计划》应包括以下的内容：
项目的质量目标；
项目质量保证活动的职责与权限；
项目开发过程中采取的质量保证措施。
 4.3. 编制《配置管理计划》
见《配置管理规程》。
 
4.4. 编制《测试计划》
测试组长编制《测试计划》，根据项目的具体情况，从单元测试、集成测试、系统测试以及用户测试这种类型中选择至少两种，并保证这两种测试活动不完全是由相同的人员完成的。 《测试计划》中应根据项目的具体情况，规定测试的强度、覆盖程度和频度。
 
4.5. 开发计划评审
在《开发计划》及相关的《质量计划》、《配置管理计划》和《测试计划》编制完成后，由开发中心负责人对上述计划进行评审。参加者应包括开发中心负责人、新和数码科技有限公司负责人、项目组长；《测试计划》的评审还应有测试部门的人员参加。评审结果应当形成记录，即《开发策划活动评审表》。上述计划的变更应在原范围内重新评审并做好记录。
 
4.6. 小项目的开发策划要求
对项目组成员不超过两人，且开发周期（至系统测试前为止）不超过6个月的项目，可以按上述各计划的要求，把开发策划活动中应当形成的开发计划、质量计划与测试计划合并成一个计划，仍称为《开发计划》。
 5. 相关规程
《配置管理规程》
 6. 质量记录
《配置管理计划》

《开发计划》

《测试计划》

《质量计划》

《开发策划活动评审表》

附录1：
DT-Q1-01-04-01-2002
配置管理计划
序号：

一、 配置管理职责
描述项目组中相关人员在配置管理中的职责，包括项目组长、支持经理，以及配置管理人员（可选）。
二、 软件产品配置项标识的管理要求；
描述在生存周期各阶段中，产品配置项构成的划分准则，标识方法。
三、 软件产品配置项测试/评审状态的管理要求；
描述在生存周期各阶段中，产品配置项测试及评审状态的标识方法，状态发生变化时应执行的程序。
四、 软件产品配置项的更改控制方法；
描述对软件配置项变更的申请、标识、审批、验收等活动的规定。
五、 配置管理使用的工具、技术和方法；
描述项目组在配置管理中对统一使用的工具、技术和方法的要求。
六、 计划制定人的姓名及制定日期

重庆CMMI认证★重庆ISO27001认证★重庆ISO20000认证★重庆ITSS认证★四川CMMI认证★四川ISO27001认证★四川ISO20000认证★四川ITSS认证

附录2：
DT-Q1-01-04-02-2002
开发计划
序号：

1. 项目描述
描述项目的背景、开发目标。
2. 项目开发资源描述
描述项目开发中需要的资源，如人员配备、职责与权限、设备与工具。
3. 开发阶段的划分
明确项目开发主要的阶段，包括阶段的划分、阶段的输入、输出及验证准则。
本开发中心规定开发过程至少应包括设计、实现（编码）、测试三个阶段。
4. 进度安排
规定组成项目开发的各任务实施的时间表、相互的进展顺序以及不同任务和阶段对资源的要求。
5. 各部门间的接口与协调
描述相关部门如新和数码科技有限公司、测试部等应提供的协助。
6. 开发使用的工具与技术
描述本项目开发中使用的主要的工具和技术方法。
7. 规则、惯例和约定
描述本项目中使用到的规则、惯例和约定，质量记录表格等。
8. 计划制定人的姓名及制定日期

五、设计规程
1. 目的
规定进行软件设计工作应遵循的原则,保证需求规格说明书中的各项需求能够得到满足。
 
2. 适用范围
适用于本开发中心开发产品在软件生命周期中设计阶段的活动。
 
3. 职责
3.1. 项目组长制定设计计划，组织人员完成设计工作，并对整个设计过程进行管理。

3.2. 开发中心负责人组织对设计结果的评审。

3.3. 技术办公室通过制定工作程序文件，对设计活动进行控制。

4. 程序
4.1. 总则
项目组根据项目的具体情况选择合适的设计方法和模型，并按照项目的复杂程度及风险水平，决定设计的详细程度，但设计要求应在设计进行之前确定，并形成《设计计划》。
 
4.2. 指导原则
设计工作应遵循以下原则：
忠实而全面地反映用户需求规格说明书的各项要求；
采用适合被开发软件产品的系统化的设计方法和模型；
便于编码实现、测试、维护和使用；
适当考虑以后的重用性、扩展性和可移植性。
 
4.3. 工作步骤
4.3.1. 制定《设计计划》
《设计计划》应包括以下内容：
参与人员及其职责与权限；
设计工作进度安排；
采用的设计方法与模型、设计的详细程度以及具体要求；
设计输出要求；
4.3.2. 设计输出
设计输出形成《产品设计书》，其中应当描述以下内容：
4.3.2.1. 程序流程结构
描述软件总体的程序结构、处理流程。
4.3.2.2. 接口
外部接口：产品与外部系统接口的要求及数据格式。
内部接口：产品中由本开发中心开发的部分与硬件及配套的软件产品之间接
口的要求与数据格式。
模块接口：构成产品的主要组成部分与模块之间接口的要求与数据格式。
4.3.2.3. 数据格式
系统中的全局的或是重要的局部数据的定义及格式要求。
4.3.2.4. 模块及算法
描述主要的程序模块以及关键算法的实现方法。
 
4.4. 设计评审
在设计完成后，由开发中心负责人或由其指定负责人组织进行评审。设计评审应形成《设计评审报告》。评审活动的原始记录应予以保存，评审活动过程应描述清楚。
 
4.5. 设计更改
经评审通过后的设计应纳入基线。此后无论因何种原因引起的设计修改，都应按《更改控制规程》执行。
 
5. 相关规程
《需求规格说明规程》

《更改控制规程》
 
6. 质量记录
《设计计划》

《设计评审报告》
 
7. 输出产品开发文档
《产品设计书》

附录1：
DT-Q1-01-05-01-2002
设计计划
序号：

一、 设计人员及负责人
列出所有参与设计的人员的名字，并标明负责人
二、 设计工作分工
描述设计人员各自负责工作
三、 设计工作进度安排
设计工作阶段的划分及完成时间
四、 采用的设计方法与模型
五、 设计的详细程度以及具体要求
六、 设计输出要求
七、 计划制定人姓名及制定日期

附录2：
DT-Q1-01-05-02-2002
设计评审报告
序号：
项目名称： 项目类型：合同         自主产品
用户名称：
评审组成员：

组长：
评审日期：    200   年   月    日
评审活动简介：

评审意见：

评审结论：

遗留问题及解决措施：

组长签名：                          日期：      年   月    日
开发中心负责人意见：

签名：                              日期：      年   月    日
备注：

重庆CMMI认证★重庆ISO27001认证★重庆ISO20000认证★重庆ITSS认证★四川CMMI认证★四川ISO27001认证★四川ISO20000认证★四川ITSS认证

六、实现规程
1. 目的
对软件开发的实现过程进行严格的质量控制，使实现过程能够按计划顺利完成并与设计相一致，在实现环节尽量减少和预防故障的发生。
 
2. 范围
适用于开发中心产品开发的实现阶段，即软件开发中从设计结果变为可运行的产品形态的过程。
 
3. 职责
3.1. 项目组按设计要求完成产品的实现。

3.2. 项目组长领导项目组人员进行开发工作，协调小组内部各角色之间的协同合作关系。
 
3.3. 测试组长组织协调项目组成员进行内部测试，参见《内部测试规程》。
 
3.4. 行政助理提供开发所需的各种工具；指导监督项目组成员编写实现过程中的各种相关文档，并进行整理和保存。

3.5. 行政助理按《配置管理规程》及配置管理计划在实现过程中进行配置管理。

3.6. 项目组成员按照《开发计划》和《质量计划》，完成编码、测试、修改工作。

4. 程序
4.1. 总则
在产品的设计确定后，项目组长应根据《产品设计书》，依据开发规范和开发计划领导整个项目组进行编码。编码须忠实于设计。
 
4.2. 实现准备
4.2.1. 项目组长组织整个项目组成员熟悉《用户需求规格说明书》和《产品设计书》，必要时由行政办公室对开发人员进行系统专门知识的培训。
 
4.2.2. 领会设计结构后，项目组长应组织全体成员讨论实现方案，明确分工。

4.3. 编码控制
项目组成员编码时应严格遵守开发规范，对于比较复杂的算法或实现方法，应编写专门的说明文档解释其实现思想。项目组长负责对项目组成员的代码进行抽查，对于违反开发规范的应责令其重新编写。项目组长定期或不定期召开组内全体会议，讨论出现的问题，控制开发进度。
 
4.4. 编码规范
编写代码时，根据使用的不同编程语言的特点，对于源代码文件名、变量名以及函数的命名按《配置管理规程》和开发中心的内部约定执行。另外，在源代码文件，应给出足够的注释来解释程序描述的处理过程。
 
4.5. 单元测试和集成测试
在编码过程项目组应按照《内部测试规程》以及《测试计划》的要求进行同步单元测试和集成测试，对于发现的错误及时改正，并按《内部测试规程》和《更改控制规程》形成记录。
 
4.6. 设计修改
程序员编码过程中如果发现设计存在缺陷或用户提出需求变更要求，均应按《更改控制规程》进行回溯，修改设计并重新进行评审。
 
4.7. 《用户手册》
编码实现过程中，行政助理充当用户角色参与界面部分的设计实现，并同步编写联机帮助和《用户手册》（参见《软件产品用户手册编写规范》）。
 
4.8. 配置管理
行政助理按《配置管理规程》控制各种输出结果。
 5. 相关规程
《内部测试规程》

《配置管理规程》

《更改控制规程》
 
6. 输出产品开发文档
《编码程序文件》（即源代码）

《用户手册》

重庆CMMI认证★重庆ISO27001认证★重庆ISO20000认证★重庆ITSS认证★四川CMMI认证★四川ISO27001认证★四川ISO20000认证★四川ITSS认证

七、测试规程
1. 目的
保开发中心开发的各种产品经过测试并合格后才被放行，保证开发中心在需要进行产品评测时按规定进行。
 
2.范围

3. 职责
3.1. 测试组
负责测试技术及测试方法的研究、指导和培训；
负责测试流程及工具的开发与支持；
接受系统测试申请并负责系统测试的组织和执行；
批准测试计划，负责测试计划规定范围内的各阶段综合测试报告的综合评价，并根据评价结果决定产品是否可以放行；
测试组长对于可以放行的产品发布产品发行通知书。
 
3.2. 项目组
测试组长是项目组测试职责的直接责任人；
负责测试计划的制订，并组织测试计划的评审；
负责解决或协调其他项目组解决所有测试过程中发现的问题；
负责单元测试、集成测试过程、用户测试过程的组织和实施；并在系统测试过程中配合测试中心的工作。
 
4. 程序 
4.0. 总则
    开发中心正式立项开发的各种产品必须经过单元测试、集成测试、用户测