银行业务产品软件项目管理办法模版.docx

洛阳银行规章制度汇编
银行业务产品软件项目管理办法

第一章 总 则
第一条 为了加强软件产品管理，建立科学、完善、有效的业务产品软件开发体系，促进我行各项业务快速发展，特制定本办法。
第二条 软件项目是指新业务开发和现有业务完善优化等工作，包括一般软件变更和重大软件变更。重大软件变更主要指涉及新业务开发和原有业务操作流程、会计核算、会计科目或影响我行业务系统日终处理等方面的变更，以及开发工作量核定在3人并超过1个月以上的软件开发项目。一般软件变更是指除重大软件变更外其他业务产品功能完善优化工作。
第三条 软件项目管理是指软件开发过程控制、文档审核、开发资源管理、项目协调等工作，包括软件项目审定立项、软件项目前期准备、软件项目编程、软件项目验收投产和项目文档等管理工作。
第四条 软件开发是指编写开发计划表、软件系统设计说明书，软件代码编程、软件内部测试和协助项目试运行、培训、验收上线及后期技术服务等相关工作。
第五条 项目文档管理是指软件项目管理过程中产生的质量记录，测试、验收文档，系统设计说明书、软件开发文档、软件维护文档、软件使用说明书及程序源代码等管理工作。
第六条 软件项目开发依据其开发主体可分为外包开发、合作开发、独立开发三种形式。外包开发指软件项目开发工作全部由软件公司负责完成；合作开发指我行与软件公司合作共同承担软件项目开发工作；独立开发指软件项目开发工作全部由我行负责完成。
第七条 软件项目维护期是指项目投产后一段期间内对硬件性能和业务问题进行采集分析，重大软件项目维护期为投产后三个月，一般软件变更投产即止。

第二章 项目组织架构及职责
第八条 为保障软件项目开发的进度和质量，软件项目开发由我行信息技术管理委员会统筹规划，评定项目的实施和管理，并针对具体业务开发决定是否设立项目组及组成人员和负责人，决定项目组是否下设需求、业务追踪、软件开发、技术追踪、测试培训、验收等职能小组。
（一）软件项目组织架构

（二）各职能小组职责
1.项目组负责组织整个项目实施管理工作，其成员由行领导、相关业务部门、信息技术部、支行业务骨干和外聘专家组成，在项目实施过程中每周五定期召开项目专题会，并形成书面材料向行领导和信息技术管理委员会汇报项目实施情况和存在的问题，其职责为：
（1）负责向信息技术管理委员会递交各职能小组成员名单和实施计划；
（2）负责协调和管理各职能小组工作；
（3）负责项目成本的估算、申请和解释等工作；
（4）负责定期召开项目专题会并向行领导和信息技术管理委员会汇报项目工作情况；
（5）接受信息技术管理委员会安排的其他工作。
（三）需求小组负责本项目业务需求书的编制和审定，其职责为：
1.负责组织相关人员调查、分析、研究业务开展可行性;
2.负责编写和完善业务需求书；
3.负责项目投产后的业务指导和管理工作。
成员构成：由需求部门抽调业务骨干人员和外部专家组成。
工作周期：从项目立项到维护期止。
（四）业务追踪小组负责项目开发中业务的实现，其职责为：
依据需求书和项目开发计划表，从业务层面实时了解、跟踪业务实现思想和方式，检查项目开发工作进度和业务需求功能完成情况。
成员构成：由需求部门抽调业务骨干人员组成。
工作周期：从项目开发到维护期止。
（五）技术追踪小组负责项目开发中技术手段实现方式，其职责为：
依据需求书和项目开发计划表，从技术层面实时了解、跟踪项目技术实现思想和方式，审定项目设计、测试及上线环节的安全性，审定软件代码。
人员构成：由信息技术部及外聘技术专家组成。
工作周期：从项目系统设计到维护期止。
（六）软件开发小组负责软件开发的全部工作，其职责为：
1.负责编写软件系统设计说明书和软件开发文档等；
2.依据需求书的内容编写软件代码并做好内测工作；
3.协助项目测试、试运行、培训、验收上线等相关工作；
4.上线投产后续技术服务工作。
人员构成：公司人员和信息技术部相关人员组成。
工作周期：从项目系统设计到维护期止。
（七）测试培训小组负责项目业务功能测试和组织相关人员培训工作，其职责为：
1.依据项目需求书编制测试大纲和测试案例；
2.依据测试内容开展项目测试；
3.对测试中发现的问题提出具体修改建议；
4.编写操作手册并组织相关人员进行培训工作；
人员构成：需求部门抽调业务骨干人员组成。
工作周期：从项目开发到维护期止。
（八）验收小组负责项目的验收工作，其职责为：
1.依据需求书编制验收工作目录；
2.按照需求书验收各功能模块，并填写验收表；
3.根据验收结果形成验收报告。
人员构成：需求部门、审计部、风险部、信息技术部和外部专家组成。

第三章 项目管理流程
第九条 业务需求部门按照《业务需求书编写规范》提出业务需求，由信息技术部召集需求部门讨论后统一汇总报我行信息技术管理委员会，由信息技术管理委员会集中审定项目是否立项、项目处理流程（重大或一般变更）、项目开发形式、项目组成员、项目实施计划和项目费用等。
第十条 对于新产品及重大软件进行开发时，其处理流程为：
（一）软件项目审定立项；
（二）制定软件项目实施计划；
（三）项目设计；
（四）项目设计评审；
（五）项目费用成本申报；
（六）开发编程；
（七）项目测试；
（八）项目试运行；
（九）项目培训；
（十）项目验收；
（十一）项目投产。
第十一条 对于一般软件变更，其处理流程为：
（一）软件项目立项审定；
（二）编程开发；
（三）项目测试验收；
（四）项目投产。

第四章 项目立项审定
第十二条 软件项目立项审定分为新产品及重大软件变更和一般软件变更两部分。
（一）新产品及重大软件变更立项审定工作按以下流程：
1.需求提出
需求部门依照《业务需求书编写规范》编写业务需求书。并将需求书转送信息技术部。
2.需求讨论
信息技术部负责需求书的登记造册，并在每周一下午组织各业务部门召开需求讨论会。各相关部门针对需求书内容，讨论其实现流程、需求细节、风险环节的预防控制等；讨论相关的业务管理办法、会计核算办法、业务操作流程等。
3.需求讨论定稿
需求部门在需求论证后，收集整理各部门意见，完善需求书并定稿，经部门负责人签署意见并加盖部门印章后转交各需求相关部门会签。
4.需求回复
需求定稿后，信息技术部负责制定《软件项目实施计划》并提交信息技术管理委员审定《软件项目实施计划》、项目开发形式、项目成本、项目组人员组成等。信息技术部依据信息技术管理委员会审定意见，向需求提出部门反馈需求立项情况。
5.项目筹备
需求立项后，信息技术部依据信息技术管理委员会审定意见，筹备项目实施。
（二）一般软件变更工作按以下流程进行处理：
1.需求提出
需求部门依照《业务需求书编写规范》编写业务需求书。并将需求书转送信息技术部。
2.需求讨论
信息技术部负责需求书的登记造册，并在每周一下午组织各业务部门召开需求讨论会。讨论修改后形成需求定稿，需求部门负责人签署意见并加盖本部门印章。
第十三条 报送信息技术管理委员会审定的需求相关文档必须包括《业务需求书》，新产品及重大软件变更还包括《业务管理办法》和《会计核算办法》。
第十四条 由信息技术管理委员会批准的新产品及重大软件变更项目，可向信息技术部及相关部室公示竞标；除此之外的项目由信息技术部确定开发人员，需求部门确定测试人员，组成项目组。

第五章 项目成本管理
第十五条 项目成本估算
项目成本估算是项目中各项工作开展所需成本的估算和计划。项目成本估算应以整个项目开展所耗费的成本和工作量作为依据。
第十六条 项目成本的构成
项目成本分为直接成本和间接成本。
（一）直接成本包括：购买软硬件、开发工具、第三方软件等成本。
（二）间接成本包括：开发和实施等成本。
第十七条 估算项目总成本
估算项目总成本=（直接成本 + 间接成本）×权重
间接成本主要指我行人员项目实施成本，是由项目总人工数乘以单位人工成本计算取得。项目总人工数根据项目计划周期和投入人数计算取得；单位人工成本依据市场同期同项目或近似项目的单位人工成本取得。权重的分值大小由信息技术管理委员会审定。
第十八条 项目成本申报
项目组依据项目复杂程度编制项目成本后递交信息技术管理委员会审批，审批通过后再提交预算管理委员会审批。项目组负责项目成本的编制计算、申报、解释等工作。

第六章 项目前期准备
第十九条 项目开发环境准备
信息技术部依据项目成本审批情况，准备相应硬件和软件开发环境，若须招标购置的软硬产品，准备招标文件，联系招标厂商，通过招标流程完成招标工作。
第二十条 系统设计及评审
（一）由信息技术管理委员会审批的项目，信息技术部必须将《系统设计》和《项目开发工作计划表》提交给信息技术管理委员会进行系统设计评审，必要时可以外聘技术专家参加评审，评审成员必须签署《系统设计评审表》。
（二）除信息技术管理委员会负责评审的项目，由信息技术部召集相关人员组成项目评审小组，评审《系统设计》和《项目开发工作计划表》，评审小组成员必须签署《系统设计评审表》。

第七章 重大项目实施管理
第二十一条 开发编程
系统设计评审通过后，软件开发小组负责代码编写并做好自测工作，保证代码质量。
第二十二条 各职能小组跟进
开发期间，各职能小组依据自己职责必须全程追踪；项目组负责人依据项目开展情况可不定期发起召开交流沟通会。
第二十三条 项目测试
测试组按照项目计划开展测试工作，其工作流程为：
（一）按照《测试计划书编写规范》编写测试大纲和测试案例并报项目组负责人审批；
（二）按照测试案例进行测试，对测试中发现的问题,测试人员必须填写《测试问题记录单》并由测试组负责人每天及时汇总递交软件开发组负责人；
（三）软件开发组负责人在次日将反馈意见告知测试组负责人。
（四）安全审核人员对测试过程进行跟踪并出具安全性测试报告。
（五）测试结束后软件开发组负责人填写《测试结果清单》并由安全审核人员签署意见。
第二十四条 试运行培训
测试完成后，测试组负责全行相关人员进行试运行前培训工作。
第二十五条 试运行
（一）试运行培训结束后，项目组向信息技术管理委员会汇报项目试运行计划，通过审批后组织项目试运行。
（二）试运行结束后，项目组向信息技术管理委员会提交项目试运行报告。
第二十六条 上线前培训
测试小组负责修订《业务操作手册》并组织全行相关人员进行上线前培训工作。
第二十七条 项目验收
试运行结束和上线前培训完成后，项目组向信息技术管理委员会汇报，并提请项目验收，通过批准后由验收小组负责对项目进行验收，并形成验收报告。
第二十八条 项目投产
验收通过后，项目组向信息技术管理委员会提请项目投产，通过批准后，软件项目可在正式环境进行上正式运行。
第二十九条 项目后评价
软件投产运行30天后，需求部门根据上线运行情况，编写项目运行状况报告，做好项目后评价工作。

第八章 一般变更项目实施管理
第三十条 信息技术管理委员会审定为一般软件变更的项目，按以下内容开展工作：
（一）信息技术部根据需求定稿，负责软件变更开发工作，保证代码质量。
（二）需求部门负责测试和验收工作，并形成验收报告。
（三）通过验收后，需求部门填写上线申请并提交信息技术部。
（四）信息技术部依据需求部门的验收报告和上线申请，完成代码及系统安全性审核并填制《软件投产工作表》，负责软件投产，后期需求部门根据上线运行情况，做好项目后评价工作。

第九章 项目维护管理
第三十一条 项目投产后，信息技术部负责软件技术支持，需求部门负责业务指导和管理。
第三十二条 在软件项目维护期间，需求部门定期收集项目投产后各方面反馈的问题，提交项目组进行完善优化。并做好后续完善的项目的版本控制工作。
第三十三条 重要信息系统投产及变更项目组负责组织业务部门、管理部门、信息技术部在重要信息系统投产及变更实施后1个月内编写总结报告材料，并提交中国银监会或其派出机构。报告内容包括但不限于：投产及变更方案执行情况、效果，问题发现和处理情况，后续改进措施或者回退方案等。如投产及变更失败，应详细说明失败原因。

第十章 项目风险管理
第三十四条 银行项目的风险主要体现在需求、技术、成本和进度，安全要求应纳入系统设计、测试的各个阶段，包含于整个项目生命周期。
第三十五条 信息技术部负责组织相关部门充分识别、分析、评估重要信息系统投产及变更风险，包括系统功能缺陷、客户信息泄露、业务中断、交易缓慢或其他因素可能造成的操作风险、法律风险和声誉风险，并形成风险评估报告。
第三十六条 在采取有效信息安全控制措施的前提下，信息技术部可委托外部专家或具备相应资质的外部专业机构进行重要信息系统投产及变更的风险评估工作。
第三十七条 董事会及经营管理层负责审核重大项目的风险评估报告。
第三十八条 科技信息部负责组织相关部门针对风险评估中发现的薄弱环节制定整改方案，明确整改时间。不具备正该条件的应采取风险缓释措施。

第十一章 项目安全管理
第三十九条 信息技术部负责系统设计、测试及验收阶段的安全审核工作。
第四十条 信息技术部安全审核人员要根据系统安全要求，对系统的详细设计进行评估，并在《系统设计评审表》上签署意见。
第四十一条 信息技术部安全审核人员要根据系统测试情况，对系统的测试过程进行评估，并在《测试结果清单》上签署意见。

第四十二条 针对安全审核评估中发现的薄弱环节，相关开发人员要制定整改方案，明确整改时间。
第四十三条 信息技术部安全审核人员要根据整改情况及系统试运行情况，在《项目验收表》上签署意见。

第十二章 文档管理
第四十四条 项目文档由信息技术部指定专人统一管理，按照《银行档案管理办法》执行。
第四十五条 项目文档管理的具体规定如下：
第四十六条 存贮介质。分书面和电子文件两种形式。电子文件是指存入光盘、磁盘或磁带等介质的文档。
第四十七条 存档。由保管人员负责编目、登记并保存项目文档。书面文档存放于文件柜；存贮电子文件的光盘、磁盘、磁带存放于计算机机房。项目文档至少每年检查一次，确保清晰完整。
保存期限。不得少于软件生存周期。若超过软件生存周期，由信息技术部总经理确定续存期限。若超过续存期限，经信息技术部总经理审核，由保管人员销毁。
发放。发放项目文档，经信息技术部总经理审批，填写“项目文档发放记录”。
接收。相关业务部门收到信息技术部发放的项目文档，须回复确认，并及时存档。

第十三章 版本管理
第四十八条 版本标识方法：
为了使工作规范化、统一化，各项目组实行的版本标识管理方法分为：正式版本和特殊版本。
第四十九条 正式版本
以“V”开头，版本号放后。V前面增加项目名称，版本号分3节：主版本号，次版本号和内部版本号，每节之间以小数点（.）间隔。如V2.0.1表示主版本号为2，次版本号为0，内部版本号为1。研发部控制主版本号和次版本号，各项目组控制内部版本号。例如：一体化平台-平阴版v1.1.1 , 一体化平台为产品名称，平阴版为版本名称（平阴为具体项目名称），v1.1.1为主版本号+次版本号+内部版本号。
第五十条 目录结构
由于各项目组的实际情况不同，目录结构很难统一，但为了能更好地管理各项目组的文档，建议可将被管理的配置项分为三大类：文档类、源码类及安装盘类，这样存放比较清晰，有利于版本管理。至于二级目录是以版本划分，并根据制定的目录结构给出文件级目录清单。
表示正式版本及特殊版本的目录按以下原则定义：
正始版本：以“V”开头，版本号放后，主版本号和次主版本号之间的“.”去掉，明细版本号之前加“-”。举例如下：
第五十一条 文档的存放
（一）当前版本和历史版本的存放
对于源码文件，特别增加了一个Current目录，存放当前正在开发与维护的源码文件，当前未发布版本的所有数据都存放在.....\CURRENT\下。一旦当前版本正式发行，则当前目录被修改为相应的历史目录。
历史版本是指已经发行的版本，存放在相应的版本目录之下，一般不允许改动。
（二）开发文档的存放
根据各项目部自己的情况，将系统用户需求记录、总体设计文档、详细设计及数据结构文件、测试记录、用户手册等放入相应的目录下。
（三）源代码的存放
源代码包括如：java，jsp，BMP，ICO等相关文件，是未经编译处理的、不能直接交付使用的产品文件以及编译产品所需的文件；联机帮助文件HLP在未生成HLP文件之前的DOC，RTF等格式的文档也视为源代码。
各子系统当前的程序源文件放入相应的目录下。对于一个子系统又分多个分子系统的情况，应在该目录下分别建立几个相应的目录。
（四） SQL语句的存放
各子系统SQL文件放入…..\.......\SQL下，对于不同的数据库，分别建立不同的子目录，如oracle、sysbase、db2等。公共SQL文件直接放入…\SQL下即可，不同数据库的特殊SQL分别放入对应的子目录下。
第五十二条 权限控制管理
为保障文档的安全性，一致性，以及防止意外修改，必须对不同的文档设置不同的访问权限。
文档权限类别：只读权限，读写权限。
文档类别：设计文档，源码，发行文档。
用户类别：开发人员、测试人员、分析设计人员、项目经理、配置管理员、安装盘制作人员、问题及需求管理人员、用户文档编写人员等。
为了控制不同的使用权限，根据要求在服务器上分别建立不同的用户，针对不同的配置项所在目录分配不同的权限。
为了便于管理，应以表格的形式列出人员与管理对象的访问关系（用户权限清单）。
第五十三条 版本安全管理
（一）接受任务指派的相关软件职能小组负责软件开发工作中的版本控制、环境搭建和版本的部署工作，保障软件版本在测试、上线环节中的安全性。
（二）版本部署要严格遵从版本编号的顺序，版本上线需要业务申请部门依据验收报告提出上线申请，并经过科技信息部负责人审批。
（三）若有严重缺陷需要部署紧急版本，需要项目组进行论证分析，并报科技信息部负责人审批。

第十四章 软件保密
第五十四条 项目组成员必须遵守《银行计算机安全保密制度规定》。
第五十五条 项目文档属银行重要机密，任何人不得向外泄露，更不得私自转让、拷贝，否则，追究相关责任人的法律责任。

第十五章 附 则
第五十六条 本制度由信息技术部负责修订与解释，自印发之日起开始执行，原有与本制度相抵触的内容按本办法执行。

附件：1.业务需求书编写规范
2.软件项目实施计划编写规范
3.系统设计编写规范
4.项目开发工作计划表
5.系统设计评审表
6.测试计划书编写规范
7.项目试运行计划书编写规范
8.软件试运行计划表
9.试运行结果报告编写规范
10.项目验收表
11.正式运行通知编写规范
12.软件发布审批表
13.软件投产工作表

27

附件1：
业务需求书编写规范

编写目的
阐明编写需求说明书的目的，此项目完成必须达到的目标。
项目背景
需求提出的出处、依据或原因。
功能描述
需求功能详细描述；
核算类需求必须指定相对应的会计分录；
报表类需求必须列示报表结构和显示表单项目、表单项目展示内容的统计方法；
前台交易必须说明是否需要打印，对需打印的必须指定打印格式和内容；
用户界面
屏幕格式、报表格式、菜单格式、输入输出元素、交易界面中静态文字信息等
界面说明
说明交易页面布局、交易归属上级菜单
界面各项目的输入数据项、输入项目的属性（文本输入框、下拉列表选项等）、输出数据的限制、统计方法等。
处理流程
详细叙述业务操作的相关步骤和各项操作的权限级别限制。
输出
1.与操作人员交互的友好提示。
2.打印的格式和内容或样单。
注意事项
柜员权限、交易部门、交易金额的风险类控制要求；错误操作纠正的方法等。
需求出处
指定需求牵头部室、指定需求联系人、同意需求的各机构部室签章；需求提出日期。

附件2：
软件项目实施计划编写规范

项目概述
简要说明项目的各项主要工作，介绍所开发软件的功能、性能等。
可行性分析
详细论述分析项目可行性；
风险分析：实施后对系统的影响及风险；说明可能影响项目的关键问题，如设备条件、技术难点或其他风险因素，并说明对策。
实施条件要求：硬件环境要求、软件环境要求（包括软件开发语言等）。
实施形式：我行独立开发、部分外包、全部外包。
开发人员组成及分工
开发人员组成形式：领导指派、项目负责人挑选、自发组成等。
开发组人员名单、职责、任务的划分及各项任务的负责人等。
项目实施服务支持
列明相关部门和个人为项目开发组提供服务内容。如软硬件环境安装、保修、维护和其他支持。
实施项目周期限定及项目分值
项目开发工作限定开始和结束日期。项目完成验收上线后工作分值。
对新产品及重大软件变更，要求项目组必须按阶段指定开始时间、完成时间。
专题计划要点
分析项目实施各阶段专题计划中重要事项，并做提醒备忘。如：测试计划、质量保证计划、配置管理计划、人员培训计划、系统安装计划等。
参与计划制定人员签署意见并签名

附件3：
系统设计编写规范

编写目的
阐明编写系统设计书的目的。
任务概述
需求概述、系统设计所需的运作环境、此系统完成后必须达到的目标。
总体设计
给出软件系统的结构图。
设计业务处理处理、总体结构和模块设计、功能分配（包括各项功能与程序结构的关系），数据结构与程序的关系。
详细描述
逐个模块给出以下的说明：
界面描述：交易页面布局、交易归属上级菜单。界面各项目的输入数据项、输入项目的属性（文本输入框、下拉列表选项等）、输出数据的限制、统计方法等。
程序逻辑：详细描述模块实现程序语言、程序处理流程、安全保密使用的算法、出错处理设计、合规性判断等。可采用：标准流程图
数据结构设计。
输出：与操作人员交互的友好提示和打印的格式和内容测试要点：给出测试该模块时的主要测试要求。
其他
维护设计
为方便维护工作的设施，详细叙述维护模块的功能和维护范围等。
工作量预估
根据小组成员人数和工作分工，估算完成以上系统设计需要的时间。

附件4:
项目开发工作计划表

（ ）项目开发计划表
序号
开始日期时间
结束日期时间
工作内容(功能模块或业务交易名)
责任人
完成提交测试日期时间

附件5：
系统设计评审表
项目名：
序号
评审事项描述
评审意见及日期
意见反馈及日期
1
总体设计是否完备

2
详细描述设计是否全面

3
维护功能设计

4
工作量预估是否合理

5
项目开发工作计划表制定是否科学合理

6
项目设计是否符合安全性要求

评审人员签署意见、签名、日期

附件6：
测试计划书编写规范

编写目的
阐明编写测试计划的目的。
测试内容介绍
简述测试工作依据的需求内容；测试工作主管部门；测试项目的详细列表。
测试环境及测试资料
说明测试所需的资料及测试环境等。如:测试用一卡通卡号、测试用存折、存单起止号码、测试用打印机型号、终端型号、操作系统版本等测试环境信息描述
测试计划安排
说明确定测试方法和选取测试用例的原则；
编写测试工作的总体进度计划时间表；
列出测试和确认测试中每一项测试的内容、名称、目的，负责机构名称、负责人和职责
测试项目说明
依据测试工作计划安排顺序，逐个对测试项目做出说明，列示测试项目名称及测试内容、范围；详细编写测试用例；对测试问题填写测试问题记录单（附表4）；依据测试工作的进度计划时间表制定阶段进度时间表（附表3），按实际工作填写阶段进度时间表中事项。
测试用例编写规定：
输入数据：依据附表1格式内容填写
输出数据：将输出结果填入附表1中对应项中
步骤及操作：依据附表2格式内容填写
测试内容评价
通过对测试案例中的各项目内容测试，填写测试结果清单（附表5），说明测试问题、测试范围及原因。
测试结论（总体评价）
总结经过测试所表明的软件能力，揭露的软件缺陷和不足，提出为弥补上述缺陷的建议。必须明确说明能否通过测试。

附表1：
测试日期： 交易 类 号 测试人员：
测试业务系统名：
交易名称： 交易码
业务界面要素集
数据
建议或说明
业务处理代码
咨询息技术部后填写

交易序号
系统自动生成后记录

业务权限设定

预期结果：
失败
交易金额不应为0
测试实际结果
成功 失败
说明及意见建议：

A类：业务要素合规性测试 B类：业务要素破坏性测试 C类：非业务要素性测试

【案例】录入资金申请 交易码(6761)
测试日期： 2010-03-22 交易B类 210301号 测试人员：张三
测试业务系统名：核心业务前台操作
交易名称：录入资金申请 交易码 6761
业务界面要素集
数据
建议或说明
业务处理代码
fundin

交易序号
01100018

申请部门
0106

申请类型.
01

币 种
10 人民币

金 额
0

资金使用日期
20100101

业务权限设定
支行B级操作员
预期结果：
失败
交易金额不应为0
测试实际结果
失败
意见建议：
测试通过，达到预期测试结果
A类：业务要素合规性测试 B类：业务要素破坏性测试 C类：非业务要素性测试

附表2：
测试日期： 流程 类 号 测试人员：
测试业务系统名：
测试内容：
操作步骤
预期结果
实际结果
1

2

3

4

5

测试实际结果

意见建议：

A类：业务流程成功性测试 B类：业务流程破坏性测试

【案例】网点资金录入资金申请流程
测试日期： 2010-03-22 流程B类 01号 测试人员：张三
测试业务系统名：核心业务前台操作
测试内容：网点资金录入资金申请
操作步骤
预期结果
实际结果
1录入资金申请
交易码(67611) 提交成功
成功
2审批申请-查询
交易码(6713) 状态“申请”
申请
3审批申请-执行
交易码(6713) 同意
同意
4审批申请-查询
交易码(6713) 状态“同意”
同意
5申请查询维护
交易码(67112) 应提示 错误
该合同状态不是录入不不能修改
测试实际结果
符合测试目的
意见建议：
测试通过，达到预期测试结果
A类：业务流程成功性测试 B类：业务流程破坏性测试

附表3:：阶段进度时间表

阶段进度测试时间表
归属总体进度时间计划表中编号或名称

开始日期时间
结束日期时间
业务测试内容或用例名称
责任人
测试结果、日期时间

附表4： 测试问题记录单
测试问题记录单 填写日期： 年 月 日
测试项目名称： 测试项目编号：
测试计划开始日期

计划结束日期

问
题
描
述

处
理
意
见

备
注

记录时间： 记录人：

附表5：测试结果清单

测试结果清单
测试名称或编号

测试工作日期

测试负责人
联系电话：
联调测试结果
○ 全部通过
○ 部分通过
○ 未测试
日终对账结果
○ 正确
○ 不正确
打印
信息
○ 正确
○ 不正确
未测试用例编号

未测试原因说明

未通过测试用例编号

未通过测试案例问题说明

测试中未解决问题说明

备注

附件7：
项目试运行计划书编写规范

一、简述项目内容
简述项目内容

二、简述项目测试情况
项目测试情况简述

三、简述项目培训情况
简述项目培训情况，并说明是否符合试运行工作开展条件。

四、申请试运行的开始、结束日期

五、试运行工作期间业务负责人名单及联系电话

六、编制计划书部门总经理意见、日期及部门签章

附件8：
软件试运行计划表
项目名：
计划工作起始结束日期
工作内容
责任人
完成日期

评审人员签署意见、签名、签章、日期

附件9：
试运行结果报告编写规范

一、投入试运行的项目名称

二、试运行计划执行情况

三、试运行中各项目情况报告
列出每一项目的名称、内容和运行结果，数据采集验证结果、跟踪办理机构、柜员名称等信息。

四、试运行结论
按需求内容，客观真实的评定软件能力，试运行期间的局限性(即项需求未得到充分测试的情况及原因），说明试运行所揭露的软件缺陷和不足，以及可能给软件运行带来的影响等。是否需要继续开展试运行工作。

五、评价
试运行是否通过，能否正式运行。

六、评审部门总经理意见、日期及部门签章

附件10：
项目验收表
项目名：
软件试运行结束日期

项目开发负责人

验收明细清单
功能实现
功能说明
交易码或菜单名
通过
不通过
验收部门

验收相关部门签署意见、签章、日期
开发部门
业务需求部门
监督验收部门

附件11：
正式运行通知编写规范

一、投入正式运行的项目名称

二、简述试运行工作情况

三、投入正式运行的日期，业务指导负责部门和负责人

四、部门总经理意见、日期及部门签章

附件12：
软件发布审批表
项目名：
软件正式发布日期

项目开发负责人

软件发布工作安排
序号
工作内容
时间安排
源码文档移交
责任人
审验人

签署意见、签章、日期
开发部门

行领导
业务需求部门

行领导

附件13：
软件投产工作表
软件项目编号：
项目名称：
上线日期：
业务负责部门：
测试方意见：
安全审核方意见：
代码审验意见及签字日期：

开发负责人意见和投产实施操作人及签字日期：

领导意见及签字日期：