项目验收过程
验收作为项目执行过程中的一个重要的里程碑，对公司和客户具有重要的意义。
一、验收申请
二、验收准备
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程序，部署维护是软件生存周期中最长的一个过程，配置文件的审核显得尤为重要。对配置文件的审核要求与源代码的审核要求完全一致.
发布评论