项目验收管理制度.docx

项目验收管理制度.docx

《项目验收管理制度.docx》由会员分享，可在线阅读，更多相关《项目验收管理制度.docx（8页珍藏版）》请在冰豆网上搜索。

项目验收管理制度

项目验收管理制度

LT

1.

2.

3.系统验收申请

开发方在完成规定的系统验收申请前的各项准备工作以后，应适时向用户方正式提出系统验收申请报告，扼要说明申请系统验收的准备情况和系统所具备的验收条件。

开发方在提交系统验收申请报告时，必须按合同书的有关规定，交付有关的产品资料，其中包括系统设备及系统软件配置清单、文档、技术总结报告和测试分析报告等。

系统验收申请报告应有开发方的技术负责人签字。

用户方的经办人必须了解要验收系统的功能、性能和系统配置与文档等方面的要求，掌握合同书中规定的系统验收条款，对开发方提交的系统验收。

申请报告进行审查，提出处理意见。

用户方技术负责人经审查后，在申请报告上签字并对开发方的申请作出答复。

用户方将按合同有关条款做好系统验收的全部准备工作，包括对测试用例、测试数据、测试过程和测试环境的准备。

4.系统验收计划

在系统验收活动进行之前，开发方应制定一套完整的系统验收测试计划。

系统验收计划应由系统的开发方和用户方共同制订或由用户方委托开发方单位制订。

该计划要由用户方认可，而且还要包括一些由用户方提供的测试方案。

该计划应包括系统验收工作的活动程序、验收测试要求、技术条件、设备资源、验收准则、工作人员的组成以及日程安排等内容。

该计划由用户方审定后执行。

5.验收测试计划

系统的验收测试是系统验收活动中最关键的步骤，被验收的系统必须满足合同条款与系统需求说明书中规定的要求。

4.1测试计划及流程包括下列几项：

（1）测试计划及程序的目的；

（2）各项功能测试所需输入的数据；

（3）测试结果记录的说明；

（4）观察、测试结果的设备、工具及程序；

（5）测试进度表；

4.2有关的测试结果要以书面报告的形式由开发方向用户方提交，内容包括：

（1）测试的系统功能；

（2）为纠正系统缺点需做的变动；

（3）为提高系统性能提出的建议。

6.验收测试前的检查

在系统验收测试开始之前，用户方必须提前将验收的有关资料分发给用户方验收人员。

验收人员需要检查测试环境是否符合要求，检查全部测试项目的测试用例是否准备好，有关测试人员是否全部到位。

7.系统演示

开发方应向用户方演示被验收系统的全部界面、系统包括的主要功能、性能，以证明系统实现的功能与合同要求一致。

通过演示活动让用户方成员对系统有一个直观和概括的了解。

验收委员可现场选用实例对被验收系统时行演示考核，以证实与系统需求的一致性、程序和文档的一致性。

8.验收测试

系统验收测试组应按系统验收测试计划对系统进行功能测试、可靠性测试、安全性测试、性能测试、一致性测试和文档测试。

测试员按分工分别对被验收系统进行逐项测试，并详细记录每一项测试结果，将这些结果分别与预期的结果对照分析，然后写出《系统验收测试报告》，该报告将作为用户方评价系统的主要依据，也是用户方确定是否接收该系统的主要依据。

9.系统验收评审

在验收测试完成以后，用户方应及时主持评审会，通过有关报告和审议验收结果，并对系统作出综合评价。

8.1评审内容包括：

（1）《文档审查报告》

（2）《系统验收测试报告》

（3）《测试分析报告》

（4）《技术总结报告》

8.2按以下的验收准则对系统进行评价：

（1）系统是否满足用户信息系统要实现的目标。

（2）系统采用的技术和实现方案是否做到可靠、稳定、灵活、实用。

（3）所选用的应用开发平台和开发工具先进、简便、有效，便于与其他系统的衔接，实现资源共享。

（4）运行系统的可靠性是系统建设的首要出发点。

因此，要求开发方提供高可靠性的产品和技术，确保系统的安全和可靠。

要求系统具有较强的容错能力，使系统不易崩溃。

（5）关键系统设备与数据备份的设施是否达到安全可靠。

用户方应进行认真地讨论，对被验收的系统给出实事求是的评价，内容包括系统的先进性、功能性、可靠性和安全保密性。

最后由用户方进行决定系统是否通过验收。

10.系统验收报告

在验收评审后，用户方应写出《系统验收报告》，详尽地记录验收中对系统的评价及验收意见。

尤其要明确系统在验收中发现的问题和缺陷，以及需要改进的意见和开发方对此所作的承诺。

用户方全体成员在验收报告上签字。

根据用户方表决情况，由用户方主任在验收报告上签署验收意见。

如果系统验收不能通过，用户方将根据合同书的规定与供需双方协商处理意见，可能的结果是：

要求开发方限期完成开发任务，重新提出验收申请或者终止合同。

系统验收通过后，要确定系统进入试运行的时间结束时间，明确开发方在试运行期间要解决的遗留问题以及改进系统的意见，对此开发方的代表要作出承诺。

11.产品移交

文档应在申请验收时提交，系统也已上线运行，此时的移交应是一些收尾工作，如：

开发方不应再保留正式系统的账号，以及数据的管理职能等。

一、项目验收原则

验收参与部门：

信息化验收小组，开发单位。

在软件开发合同的签订阶段就提出软件验收项目和验收通过标准的意见；在软件的需求评审阶段，仔细审阅软件的需求规格说明书，指出不利于测试和可能存在歧义的描述；在开发方开发完软件并经过开发方内部仔细的测试后，对完成的软件进行评审（或第三方的验收测试），提供完整的错误报告提交给用户方，由用户方根据之前签订的开发合同中相应的验收标准判断是否进行验收。

二、验收内容和评定

1.验收内容

1.1功能项测试

对软件需求规格说明书中的所有功能项进行测试；

1.2业务流程测试

对软件项目的典型业务流程进行测试；

1.3容错测试

容错测试的检查内容包括:

（1）软件对用户常见的误操作是否能进行提示；

（2）软件对用户的操作错误和软件错误，是否有准确、清晰的提示；

（3）软件对重要数据的删除是否有警告和确认提示；

（4）软件是否能判断数据的有效性，屏蔽用户的错误输入，识别非法值，并有相应的错误提示。

1.4安全性测试

安全性测试的检查内容包括:

（1）软件中的密钥是否以密文方式存储；

（2）软件是否有留痕功能,即是否保存有用户的操作日志；（3） 软件中各种用户的权限分配是否合理；

1.5性能测试

对软件需求规格说明书中明确的软件性能进行测试。

测试的准则是要满足规格说明书中的各项性能指标。

1.6易用性测试

易用性测试的内容包括:

（1） 软件的用户界面是否友好；

（2） 软件中的提示信息是否清楚、易理解，是否存在原始的英文提示；

（3） 软件中各个模块的界面风格是否一致；

（4） 软件中的查询结果的输出方式是否比较直观、合理。

1.7适应性测试

参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满足的软、硬件环境。

对每个环境进行测试。

1.8文档测试

用户文档包括:

安装手册、操作手册和维护手册。

对用户文档测试的内容包括:

（1） 文档是否齐全、是否包含产品使用所需的信息和所有的功能模块；

（2） 文档描述的信息是否正确,是否没有歧义和错误的表达；

（3） 文档是否容易理解,是否通过使用适当的术语、图形表示、详细的解释来表达；

（4） 文档对主要功能和关键操作是否提供应用实例；

（5） 文档是否有详细的目录表和索引表；

2.验收评定

2.1软件错误的严重性等级

（1）不能执行正常功能或重要功能,或者危及人身安全；

（2）严重地影响系统要求或基本功能的实现,且没有办法解决；

（3）严重地影响系统要求或基本功能的实现,但存在合理的解决办法；

（4）使操作者不方便或遇到麻烦,但不影响执行正常功能或重要功能；

（5）其它错误；

2.2错误与严重性等级对应表

1级错误

这一级别的错误一般包括以下内容:

没有实现或错误地实现重要的功能；业务流程存在重大隐患；软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情况；软件在操作过程中由于软件自身的原因对系统或数据造成破坏；在现有的软、硬件环境下不能实现应有的功能；特殊软件在操作过程中可能危及系统和人身安全等。

2级错误

这一级别的错误一般包括:

没有实现基本功能，并且不存在替代办法；没有实现重要功能中的部分功能，并且不存在替代办法；业务流程衔接错误；密钥以明文方式存储；没有留痕功能；用户的权限分配不合理；在现有的环境下，不能实现部分功能且没有替代方案；没有满足系统的性能要求。

3级错误

这一级的错误是与第2级别的错误相对应的，而第3级错误则存在替代方法；对误操作或错误操作没有提示，导致非法数据进入数据库。

4级错误

这一级别的错误通常为易用性方面的错误。

比如界面不友好、前后风格不一；中英文混杂；查询结果输出不直观等。

5级错误

通常为文档方面的错误，如安装手册、操作手册、维护手册中的描述错误。

要求对发现的每一个错误都要确定相应的严重性等级。

全部改正方可，如错误的级别和数量在合同可接受的范围外，用户方认为软件不可验收，要求开发方在规定的时间内全面整改软件,并再次进行完整的验收测试。

2.3验收标准

（1） 测试用例不通过数的比例<1.5%；

（2） 不存在错误等级为1的错误；

（3） 不存在错误等级为2的错误；

（4） 错误等级为3的错误数量≤5；

（5） 所有提交的错误都已得到更正；

2.4验收标准的详细说明

验收项目的划分参照GB/T16260标准。

在该标准中，将软件的质量特性分为6大特性、21个子特性，而对于具体的软件，并非都要进行这21个特性的测试和评价。

本文选取的是最通用的子特性部分，针对各种不同的软件，可以对验收项目进行剪裁或扩充。

需要制定的验收标准，即每一级别的错误量的可接受范围。

一般来说，不允许存在1级和2级错误，而3级错误的数量则可按本标准确定或由用户方和开发方根据软件的规模和复杂程度进行商定，并在软件开发合同中明确地列出。

在软件验收测试中，测试的依据包括软件的投标文件、开发合同、需求规格说明书,同时还包括特定软件的相关行业标准（这些行业标准应在开发合同中明示出来）。

在用户方进行验收测试后，将发现的所有错误进行总结和归纳，并提交完整的错误报告，在错误报告中包括每一级别的错误数量和错误清单（所有的错误都需经过用户方和开发方的确认）。

用户方根据错误报告中每一级别的错误数量和错误清单与软件开发合同中的验收标准进行对照，如错误的级别和数量在合同中没有约定，可按本办法的规定进行。

用户方认为软件可以验收，但要求开发方对错误报告中的所有错误进行整改，并提交给软件评测中心进行回归测试，确认错误报告中的所有错误全部改正方可；如错误的级别和数量在合同可接受的范围外，用户方认为软件不可验收，要求开发方在规定的时间内全面整改软件，并再次进行完整的验收测试。

三、验收资料

1.工程立项批准文件

2.项目验收申请报告

3.工程招标书

4.工程投标书

5.工程施工中标通知书

6.工程施工合同（含预算表）

7.软件需求说明书

8.概要设计说明书

9.数据及数据库设计说明书

10.详细设计说明书

11.操作手册

12.用户手册

13.项目用户评价过程意见

14.软件接口规范

15.原代码或安装盘

16.测试分析报告