有些组织的软件验收是这样的：确认了交付过来的软件基本能用（功能可用，但易用性，健壮性差强人意），召开一个验收评审，讲讲软件实现的功能和研制过程，就OK了！
这样的软件验收，带来的结果只能是让用户在软件交付之后忍受软件的使用不便和不断出现的问题……实在忍受不下去了，就一弃了之。
这就是没有进行严格验收带来的后果。
那么软件的验收究竟要怎么做呢？
软件验收主要有三个活动：验收审查，验收测试和验收评审。
验收审查
验收审查并不像有些人想象的那样，只是审查交付物是否完备(也就是通常所说的齐套性检查)这么简单。实际上，验收审查应该包括功能验收审查和物理验收审查（一听这名字，熟悉GJB5000的我们就应该想到，验收审查中的这两类审查类似于GJB5000的配置审核里面的功能审核和物理审核）两大活动。
通过类比配置审核的功能审核，我们知道，功能验收审查，就是通过对研制方提供的设计文档以及软件的验证和确认的结果进行复查，由此来确认软件的需求都已经得到充分的验证。
以下是推荐的一些功能验收审查的具体做法:
a）审查软件测试文档。检查是否所有的软件需求项（包括功能、性能、接口、可靠性、安全性、健壮性等）都得到了测试并且有明确的测试结果，选择的测试类型是否适当以及测试结果的完整性和精确性。
b）审查软件的更改。检查软件的每一次更改的记录（更改原因，影响分析，更改内容等）是否完整，所有的更改是否得到批准，直接更改和受影响的更改是否都得到充分验证。
c）对所有交付的文档进行评审，以保证其正确性、一致性和充分性，能够支持将来的软件维护活动。
d）审查软件评审记录。通过对历次软件评审的结果进行抽样检查，以保证所有的评审问题已得到处理，软件验证结果有效。
通过类比配置审核的物理审核，我们知道，物理验收审查，就是通过对研制过程中产生的各种文档和记录的研究，确保文文一致、文实一致。
以下是推荐的一些物理验收审查的具体做法：
a）检查软件文档完整性。检查软件开发计划定义的软件生命周期模型应产生的文档是否齐全，特别是应交付的文档（这一点类似于本文开篇所提到的“齐套性检查”）。
b）检查软件文档的符合性。检查文档对于模板（GJB438B的文档要求或者组织自己的模板要求）的符合性。
c）检查软件文档的一致性。检查需求文档、设计文档、测试文档以及用户手册等各类软件文档之间的一致性。
验收测试
验收测试内容的确定因具体的项目而异，但验收测试必须由用户(或验收方)进行，或者由用户委托的第三方组织来进行，不能单纯地把系统联试当作验收测试，更不能取消验收测试直接使用供方的测试结果。
一般来说，软件验收测试应该包括验收测试策划（编写验收测试大纲或计划）、执行验收测试、验收测试报告和评审等几个步骤。验收测试要确保覆盖以下4类需求：
a）功能需求，这与软件必须执行的功能相关。
b）性能需求，这与诸如时间或资源约束等操作需求相关。
c）接口需求，这与软件内部、外部的连接相关（例如，人/机、模块/模块、机器/模块）。
d）软件质量需求，包括诸如可靠性、可测试性、正确性及可用性这类因素。
验收评审
验收评审就是验收组织对前两项活动——验收测试和验收审查的结果进行审查和评议，对被验收软件作出结论建议，并向验收方提交验收报告。
验收评审是验收组织的收尾工作，也是软件验收的主要环节。GB1268A从评审时机、评审形式、评审通过准则、评审程序、评审结论和验收报告等几方面提出了要求，使得软件验收评审活动更规范。
评审的时机 验收评审应在完成验收测试、验收审查后进行，不能跨越验收测试、验收审查阶段。
评审的形式 软件验收评审一般都要采取会议评审形式。评审人员可以是没有参加验收测试、验收审查的验收组织指定的专家。
评审通过准则 1)所有软件需求得到满足； 2)交付齐全，可支持后续维护活动。
评审的程序 根据评审通过准则，对被验收的软件进行综合评价，并进行表决，作出评审结论。
评审结论 评审结论分为两种:建议通过和建议不通过。由于验收是否通过的最后的决定权在验收方，验收组织只有建议权，所以这里评审结论为建议通过和建议不通过。评审结论，尤其是建议通过的结论的取得，视被验收软件的完整性级别的不同而不同。
验收报告 验收报告的内容一般包括验收依据、验收内容、验收过程、验收准则、验收测试结论、验收审查结论、表决情况等。由评审负责人在验收报告上签署验收评审结论，参加验收评审的成员应在验收报告上签字。
参考书目：《军用软件工程系列标准实施指南》
微信赞赏专用通道
联系客服
