信息化项目验收管理办法

1、信 息 化 项 目 验 收 管 理 办 法 一、项目验收流程 1. 开发方申请验收的准备工作 根据用户系统的特点，系统验收都应在最终用户方的实际系统运行环境中进行。要系统 验收申请前应完成如下的工作： 开发方应在系统交付用户方验收之前，对完整产品的运行情况进行确认； 开发方在完成确认测试后，证实系统已满足合同规定的条件及需求说明书中对系统功能 和性能的要求； 开发方应准备好提交验收的各种文档、系统软硬件配置清单，并做好产品的交付准备； 开发方的实施小组应准备好测试分析报告和技术总结报告，作为系统验收的必 备文件提供给用户方； 开发方应支持用户方对系统的验收测试和评审； 开发方应作出向用户方提供

2、人员培训和技术支持的计划。 2. 系统验收申请 开发方在完成规定的系统验收申请前的各项准备工作以后，应适时向用户方正式提出系 统验收申请报告，扼要说明申请系统验收的准备情况和系统所具备的验收条件。开发方在提 交系统验收申请报告时， 必须按合同书的有关规定， 交付有关的产品资料， 其中包括系统设 备及系统软件配置清单、文档、技术总结报告和测试分析报告等。系统验收申请报告应有开 发方的技术负责人签字。 用户方的经办人必须了解要验收系统的功能、性能和系统配置与文档等方面的要求，掌 握合同书中规定的系统验收条款，对开发方提交的系统验收。 申请报告进行审查， 提出处理意见。用户方技术负责人经审查后， 在

3、申请报告上签字并 对开发方的申请作出答复。 用户方将按合同有关条款做好系统验收的全部准备工作，包括对 测试用例、测试数据、测试过程和测试环境的准备。 3. 系统验收计划 在系统验收活动进行之前，开发方应制定一套完整的系统验收测试计划。系统验收计划 应由系统的开发方和用户方共同制订或由用户方委托开发方单位制订。该计划要由用户方认 可，而且还要包括一些由用户方提供的测试方案。该计划应包括系统验收工作的活动程序、 验收测试要求、技术条件、设备资源、验收准则、工作人员的组成以及日程安排等内容。该 计划由用户方审定后执行。 4. 验收测试计划 系统的验收测试是系统验收活动中最关键的步骤，被验收的系统必须

4、满足合同条款与系 统需求说明书中规定的要求。 4.1测试计划及流程包括下列几项： (1) 测试计划及程序的目的； (2) 各项功能测试所需输入的数据； (3) 测试结果记录的说明； (4) 观察、测试结果的设备、工具及程序； (5) 测试进度表； 4.2有关的测试结果要以书面报告的形式由开发方向用户方提交，内容包括: (1) 测试的系统功能； (2) 为纠正系统缺点需做的变动； (3) 为提高系统性能提出的建议。 5. 验收测试前的检查 在系统验收测试开始之前，用户方必须提前将验收的有关资料分发给用户方验收人员。 验收人员需要检查测试环境是否符合要求，检查全部测试项目的测试用例是否准备好，有关

5、 测试人员是否全部到位。 6. 系统演示 开发方应向用户方演示被验收系统的全部界面、系统包括的主要功能、性能，以证明系 统实现的功能与合同要求一致。通过演示活动让用户方成员对系统有一个直观和概括的了 解。验收委员可现场选用实例对被验收系统时行演示考核，以证实与系统需求的一致性、程 序和文档的一致性。 7. 验收测试 系统验收测试组应按系统验收测试计划对系统进行功能测试、可靠性测试、安全性测试、 性能测试、一致性测试和文档测试。测试员按分工分别对被验收系统进行逐项测试，并详细 记录每一项测试结果， 将这些结果分别与预期的结果对照分析， 然后写出系统验收测试报 告该报告将作为用户方评价系统的主要依

6、据，也是用户方确定是否接收该系统的主要依 据。 8. 系统验收评审 通过有关报告和审议验收结果，并对 在验收测试完成以后，用户方应及时主持评审会， 系统作出综合评价。 8.1评审内容包括： 文档审查报告 (2) 系统验收测试报告 (3) 测试分析报告 (4) 技术总结报告 8.2按以下的验收准则对系统进行评价： (1) 系统是否满足用户信息系统要实现的目标。 (2) 系统采用的技术和实现方案是否做到可靠、稳定、灵活、实用。 (3) 所选用的应用开发平台和开发工具先进、简便、有效，便于与其他系统的衔接, 实现资源共享。 (4) 运行系统的可靠性是系统建设的首要出发点。 因此，要求开发方提供高可靠

7、性 的产品和技术，确保系统的安全和可靠。要求系统具有较强的容错能力，使系 统不易崩溃。 (5) 关键系统设备与数据备份的设施是否达到安全可靠。 用户方应进行认真地讨论，对被验收的系统给出实事求是的评价，内容包括系统的先进 性、功能性、可靠性和安全保密性。最后由用户方进行决定系统是否通过验收。 9. 系统验收报告 在验收评审后，用户方应写出系统验收报告，详尽地记录验收中对系统的评价及验 收意见。尤其要明确系统在验收中发现的问题和缺陷，以及需要改进的意见和开发方对此所 作的承诺。用户方全体成员在验收报告上签字。根据用户方表决情况， 由用户方主任在验收 报告上签署验收意见。 如果系统验收不能通过，

8、用户方将根据合同书的规定与供需双方协商处理意见，可能的 结果是：要求开发方限期完成开发任务， 重新提出验收申请或者终止合同。系统验收通过后， 要确定系统进入试运行的时间结束时间，明确开发方在试运行期间要解决的遗留问题以及改 进系统的意见，对此开发方的代表要作出承诺。 10. 产品移交 文档应在申请验收时提交，系统也已上线运行，此时的移交应是一些收尾工作口：开 发方不应再保留正式系统的账号，以及数据的管理职能等。 二、项目验收原则 验收参与部门：信息化验收小组，开发单位。 在软件开发合同的签订阶段就提出软件验收项目和验收通过标准的意见；在软件的需求 评审阶段，仔细审阅软件的需求规格说明书， 指出

9、不利于测试和可能存在歧义的描述； 在开 发方开发完软件并经过开发方内部仔细的测试后，对完成的软件进行评审 (或第三方的验收 测试)，提供完整的错误报告提交给用户方，由用户方根据之前签订的开发合同中相应的验 收标准判断是否进行验收。 三、验收内容和评定 1. 验收内容 1.1功能项测试 对软件需求规格说明书中的所有功能项进行测试； 1.2业务流程测试 对软件项目的典型业务流程进行测试； 1.3容错测试 容错测试的检查内容包括： (1) 软件对用户常见的误操作是否能进行提示； (2) 软件对用户的操作错误和软件错误，是否有准确、清晰的提示； (3) 软件对重要数据的删除是否有警告和确认提示； (4

10、) 软件是否能判断数据的有效性，屏蔽用户的错误输入， 识别非法值，并有相应 的错误提示。 1.4安全性测试 安全性测试的检查内容包括： (1) 软件中的密钥是否以密文方式存储； (2) 软件是否有留痕功能，即是否保存有用户的操作日志；(3)软件中各种用户 的权限分配是否合理； 1.5性能测试 对软件需求规格说明书中明确的软件性能进行测试。测试的准则是要满足规格说明 书中的各项性能指标。 1.6易用性测试 易用性测试的内容包括： (1) 软件的用户界面是否友好； (2) 软件中的提示信息是否清楚、易理解，是否存在原始的英文提示; (3) 软件中各个模块的界面风格是否一致； (4) 软件中的查询结

11、果的输出方式是否比较直观、合理。 1.7适应性测试 参照用户的软、硬件使用环境和需求规格说明书中的规定，列出开发的软件需要满 足的软、硬件环境。对每个环境进行测试。 1.8文档测试 用户文档包括：安装手册、操作手册和维护手册。对用户文档测试的内容包括 (1) 文档是否齐全、是否包含产品使用所需的信息和所有的功能模块； (2) 文档描述的信息是否正确，是否没有歧义和错误的表达； (3) 文档是否容易理解，是否通过使用适当的术语、图形表示、详细的解释来表 达； (4) 文档对主要功能和关键操作是否提供应用实例； (5) 文档是否有详细的目录表和索引表； 2. 验收评定 2.1软件错误的严重性等级

12、(1) 不能执行正常功能或重要功能，或者危及人身安全; (2) 严重地影响系统要求或基本功能的实现，且没有办法解决； (3) 严重地影响系统要求或基本功能的实现，但存在合理的解决办法; (4) 使操作者不方便或遇到麻烦，但不影响执行正常功能或重要功能； (5) 其它错误； 2.2错误与严重性等级对应表 1级错误 这一级别的错误一般包括以下内容 ：没有实现或错误地实现重要的功能；业务流程 存在重大隐患；软件在操作过程中由于软件自身的原因自动退出系统或出现死机的情 况；软件在操作过程中由于软件自身的原因对系统或数据造成破坏；在现有的软、硬件 环境下不能实现应有的功能；特殊软件在操作过程中可能危及系

13、统和人身安全等。 2级错误 这一级别的错误一般包括：没有实现基本功能，并且不存在替代办法；没有实现重 要功能中的部分功能，并且不存在替代办法；业务流程衔接错误；密钥以明文方式存储; 没有留痕功能；用户的权限分配不合理；在现有的环境下，不能实现部分功能且没有替 代方案；没有满足系统的性能要求。 3级错误 这一级的错误是与第2级别的错误相对应的，而第 3级错误则存在替代方法；对误 操作或错误操作没有提示，导致非法数据进入数据库。 4级错误 这一级别的错误通常为易用性方面的错误。比如界面不友好、前后风格不一；中英 文混杂；查询结果输出不直观等。 5级错误 通常为文档方面的错误，如安装手册、操作手册、

14、维护手册中的描述错误。 要求对发现的每一个错误都要确定相应的严重性等级。全部改正方可，如错误的级 别和数量在合同可接受的范围外，用户方认为软件不可验收，要求开发方在规定的时间 内全面整改软件，并再次进行完整的验收测试。 2.3验收标准 (1) 测试用例不通过数的比例 1.5 % ; (2) 不存在错误等级为1的错误； (3) 不存在错误等级为2的错误； (4) 错误等级为3的错误数量W 5 ; (5) 所有提交的错误都已得到更正； 2.4验收标准的详细说明 验收项目的划分参照 GB/T 16260标准。在该标准中，将软件的质量特性分为6大 特性、21个子特性，而对于具体的软件，并非都要进行这2

15、1个特性的测试和评价。本 文选取的是最通用的子特性部分，针对各种不同的软件，可以对验收项目进行剪裁或扩 充。 需要制定的验收标准，即每一级别的错误量的可接受范围。一般来说，不允许存在 1级和2级错误，而3级错误的数量则可按本标准确定或由用户方和开发方根据软件的 规模和复杂程度进行商定，并在软件开发合同中明确地列出。 在软件验收测试中，测试的依据包括软件的投标文件、开发合同、需求规格说明书， 同时还包括特定软件的相关行业标准 (这些行业标准应在开发合同中明示出来 )。 在用户方进行验收测试后，将发现的所有错误进行总结和归纳，并提交完整的错误 报告，在错误报告中包括每一级别的错误数量和错误清单(所有的错误都需经过用户方 和开发方的确认)。 用户方根据错误报告中每一级别的错误数量和错误清单与软件开发合同中的验收标 准进行对照，如错误的级别和数量在合同中没有约定，可按本办法的规定进行。用户方 认为软件可以验收，但要求开发方对错误报告中的所有错误进行整改，并提交给软件评 测中心进行回归测试，确认错误报告中的所有错误全部改正方可；如错误的级别和数量 在合同可接受的范围外， 用户方认为