软件项目验收流程各步骤内容.doc
《软件项目验收流程各步骤内容.doc》由会员分享，可在线阅读，更多相关《软件项目验收流程各步骤内容.doc（6页珍藏版）》请在冰点文库上搜索。
项目验收过程
验收作为项目执行过程中的一个重要的里程碑，对公司和客户具有重要的意义。
一、验收申请
二、验收准备
2．1开发商资料收集
根据软件项目的特点，在验收时应收集以下文档：
编号
名称
形式
介质
1
项目开发计划
文档
电子、纸质
2
软件需求说明书
文档
电子、纸质
3
系统概要设计说明书
文档
电子、纸质
4
总体设计说明书
文档
电子、纸质
5
数据库设计说明书
文档
电子、纸质
6
详细设计文档
文档
电子、纸质
7
为本项目开发的软件源代码
文档
电子、纸质
8
FAT&SAT报告
文档
电子、纸质
9
试运行报告
文档
电子、纸质
10
性能测试报告、功能测试报告
文档
电子、纸质
11
项目实施报告
文档
电子、纸质
12
培训计划
文档
电子、纸质
13
服务计划
文档
电子、纸质
14
维护手册
文档
电子、纸质
15
用户手册
文档
电子、纸质
16
应用软件清单
文档
电子、纸质
17
系统参数配置说明
文档
电子、纸质
18
所提供的第三方产品的技术说明和操作、维护资料
文档
电子、纸质
19
系统崩溃及恢复步骤文档
文档
电子、纸质
20
技术服务和技术培训等相关资料
文档
电子、纸质
21
项目总结报告
文档
电子、纸质
除上述文档外，还应单独收集、保存各应用软件源程序代码及开发商所用第三方资源信息。
开发商所使用的第三方控件，除已经得到审计署的许可之外，必须提供控件的源代码，并拥有授权使用的证明或保证（由开发商提供无版权争议承诺书）；对于原始程序代码，要求能够在本地不经过任何特殊设置，即可编译并正常运行。
源程序清单中列举的项目应该和源程序一一对应。
2．2最终用户资料收集
依据软件开发需求说明书和概要设计说明书，编写相关软件的用户满意度调查表，该调查表应该涵盖软件在需求说明书中列举的所有模块，包含软件在不同操作系统下的运行情况等。
最终用户或甲方项目组按照实际情况填写该调查表。
三、验收测试
验收测试是软件开发结束后，用户对软件产品投入实际应用以前进行的最后一次质量检验活动，它要回答开发的软件产品是否符合预期的各项要求，以及用户能否接受的问题。
由于它不只是检验软件某个方面的质量，而是要进行全面的质量检验，并且要决定软件是否合格，因此验收测试是一项严格的正式测试活动。
需要根据事先制订的计划，进行软件配置评审、功能测试、性能测试等多方面检测。
软件验收测试分为三部分：
文档代码一致性审核、软件配置审核和可执行程序测试，其顺序可分为：
文档审核、源代码审核、配置脚本审核、测试程序、平台API测试、集成测试、验收测试等。
文档代码一致性审核、软件配置审核是软件部署和实施全面验收测试的基础，由各应用软件验收责任人检查它们的完整性；由于工程开发的各软件运行环境均基于审计管理系统、审计实施系统平台，最终的集成测试、验收测试由德华工贸员工、验收专家所有参与验收工作的人员一起完成。
3．1文档审核
文档审核的主要要求是确定软件开发的所有过程都在提交文档的控制下，对文档的具体要求如下：
（1）文档完备性：
是否按照合同及其附件要求提交了全部文档；
（2）内容针对性：
指文档是否是甲方要求的文档；文档的内容应该按照功能模块的重要性在论）上达到不同的详细程度；
（3）内容充分性：
指该文档全面、详细的程度；
（4）文档的价值：
文档应该能够反映软件开发的整个过程，即需求中提到的功能在概要设计中体现，在详细设计中实现，在测试计划中检验；
（5）图表翔实性：
是否包含了足够的图形和表格；
（6）符合甲方规范程度：
是否很好地符合甲方要求的规范、标准；
（7）内容一致性：
是否存在前后矛盾；是否存在需求说明中提到的功能在概要设计、详细设计中没有涉及的情况；
（8）文字明确性：
不使用“可能”、“也许”、“待定”等语义含糊不清的语句；
（9）易读性：
能够在一篇文档中说明清楚的内容，尽量不要拆分成若干文档，不要循环引用，文档目录一目了然，结构清晰。
3．2源代码审核
源代码审核的主要要求是确保开发商将全部源程序交付甲方，并确保交付的代码没有版权问题（由开发商提供无版权争议承诺书）对源代码审核的具体要求如下：
3．2．1版权明晰
（1）提交的代码中注释版权的地方均应去掉版权声明，或声明版权为审计署所有。
（2）得到甲方允许，可以使用的控件，由开发商提供无版权争议承诺书。
使用其他的具有源代码的控件，均需要当作提交代码的一部分，直接置于编译环境的工程文件中，在编译发布时无需额外设置。
3．2．2代码完整
（1）开发商必须把所有实现用户需求的代码交付甲方。
（2）除非已经得到甲方的允许，使用的控件也必须有源代码，并得到授权使用证明；由开发商提供无版权争议承诺书。
（3）包含开发工具的程序文件；要求能够在甲方计算机中正常编译、运行；除非得到甲方允许，在甲方计算机中编译的时候无需额外安装开发工具的插件或控件。
3．2．3可读性强
注释是软件可读性的具体体现。
程序注释量不少于程序编码量的30%。
程序注释不能用抽象的语言（如“处理”、“循环”等），要精确表达出程序的处理说明。
为避免每行程序都使用注释，可以在一段程序的前面加一段注释，有明确的处理逻辑。
3．3配置文件审核
对于B/S程序，部署维护是软件生存周期中最长的一个过程，配置文件的审核显得尤为重要。
对配置文件的审核要求与源代码的审核要求完全一致。
3．4测试用例编写及测试程序、脚本审核
这个过程是在文档审核和配置脚本审核后，为了检验通过源代码编译后的程序是否满足设计需求。
检验方式主要是API测试、集成测试、验收测试；这一阶段应该完成设计及其有关测试所包括的特性，还需要完成测试所需的测试用例和测试规程，并规定特性的通过准则。
（1）测试用例说明：
列出用于输入的具体值以及预期的输出结果，并规定在使用具体测试用例时，对测试规程的各种限制。
要求将测试用例与测试设计分开，可以使它们用于多个设计并能在其它情形下重复使用。
（2）测试规程说明：
规定对于运行系统和执行指定的测试用例来实现有关测试设计所要求的所有步骤。
测试方案
（1）针对性测试方案：
从满意度调查表中筛选出可能不符合需求设计的功能模块，编写针对具体模块设计的测试方案。
这种方案的实现耗时短，根据实际使用情况调查软件的具体实现，适合在软件得到较大面积试用后采取的验收测试。
（2）抽样测试方案：
在设计文档中随机选取，根据抽样的样本大小不同，最后得到的结论可能会出现差异。
这种方案的实现耗时可长可短，适合软件未得到大面积适用前验收时采用。
3．5平台API测试
常见的白盒测试是单元测试。
单元测试是测试中最小单位的测试。
简而言之，就是拿一个函数出来，加上驱动模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：
条件判断点、循环点、选择分支点等）。
驱动模块是模拟调用被测函数的函数。
根据设计文档选取关键函数和所有开放的API，设计测试用例。
3．6集成测试/压力测试
常见的黑盒测试包括：
集成测试，系统测试。
集成测试是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。
程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
通过一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作，在协同工作时是否能够达到功能要求。
3．7验收测试
目的是检验待验收软件是否对平台和其它软件保持良好的兼容性。
四、验收结论（成绩评定标准）
验收结束时，根据以上文档，填写验收结论，对软件的质量做出评价
1．优秀
1）材料完整
2）软件可正常运行
3）实现项目软件需求说明书要求的各项功能需求
4）软件界面友好，易于交互
5）软件功能新颖，有较强创新
2．合格
1）本标准第2.1条要求的材料完整
2）可正常运行实现功能达到软件需求说明书要求的三分之二以上
3．不合格
1）标准第2.1条要求的材料不完整
2）软件不能运行
3） 软件需求说明书要求的主要功能 。
升级会员 