软件开发方法之 V 模型

简介

在软件开发方法中，V 模型是一种强调验证与确认、测试与开发阶段性对应的软件/系统开发过程模型。

通常 V 模型的左侧主要代表了需求的分解与开发，系统规范的制定。而 V 模型的右侧则代表了与之对应的集成与验证。每一级左侧的研发阶段都与之对应了一级右侧的测试验证阶段。

V 模型从上至下，模型描述的粒度就越细粒，具体可以看下面的介绍。

特别注意的是，虽然 V 模型整体上是先进行左侧活动，然后进行右侧活动，但在实际项目管理中，左右的一些活动是可以同步进行的，比如右侧的测试验证，验证使用的用例，测试环境搭建等活动可以在左侧开发进行时同步进行。

需求分析是 V 模型的第一步，主要是通过分析用户需求，来拆解为系统需求，旨在确定理想系统应具备的功能。

常见的需求收集方法有：和用户面对面沟通，问卷调查，原型，用例等。

在这一阶段，系统工程师，软件设计师等人员会把用户需求拆解为面向系统（软件工程）的业务需求，同时评估需求的可行性。

一般对于不明确，不可实现，不可验证的需求，需要同客户沟通重新审议。

在这里我举两个例子，分别阐明什么叫做用户需求可以和不可以被转换为业务需求。

例如，在一个银行软件中，客户希望提供这样一个功能，那就是当用户在银行软件中进行定期存款业务，软件系统判断该用户属于什么级别的 VIP 用户，根据不同级别给与该用户 x% 的利率上浮。

在将这个客户需求转换为业务需求时，我们拆解为如下业务规则：

在这个简单的例子中，我们可以看到这个需求最终是符合业务逻辑，当前软件系统也能够实现的。

而一个用户需求不能转换为业务需求的典型例子，就是"五彩斑斓的黑"。

在架构设计阶段，项目中的软件架构师根据业务需求的实际情况，准备好改业务需求需要的模块列表，依赖关系，数据库表，设计模式，接口关系等技术细节。

模块设计是最底层的设计阶段，通常和模块的代码编写一同进行，具体的开发人员根据架构师准备的软件开发详细说明书完成各自模块的开发工作。

当然规范的流程中，开发人员最终除了交付代码外，还需要交付一份包含详细模块设计的实现说明书。

验证阶段主要包含单元测试，集成测试和系统测试。

其中单元测试通常由开发人员自主完成，近些年在单元测试的基础上，出现了一种叫做开发者测试的开发者级别测试，相比于函数级别的单元测试，开发者测试更聚焦于验证完整功能能否正常运行。

开发者测试本质上就是集成测试，只不过将操作人员变为了开发者本身，而非测试人员。

系统测试通常由团队的解决方案团队，专门的测试团队组成，系统测试应该从各个方面（负载测试、性能测试、压力测试、回归测试）全量对系统进行测试验证。

除了上述测试过程外，还有一步是客户侧进行的用户验收测试，这一测试过程由用户主导。

在这里我不准备写 V 模型的优点和缺点，因为不同的软件开发方法适用于不同的场景，没有横向比较的意义。

V 模型主要使用场景有如下的特点：

需求明确且变更少：V模型假设需求在开发早期就能完整、清晰地定义，并且后续变更可控。因此它适合需求稳定的项目
对质量与可追溯性要求极高：V模型从需求到测试完全对应，每个开发阶段都有对应的测试阶段，便于进行双向追溯（比如每项需求对应系统测试用例）。适合安全攸关或合规性要求严格的领域
项目规模中等偏大、生命周期长：对于生命周期长达数年、参与团队众多（如供应商、多个分包商）的大型项目，V模型提供了清晰的阶段里程碑和交付物，便于管理和评审

V 模型主要使用的行业有，汽车电子，航空航天，工业自动化等。可以看到在倡导敏捷开发的互联网行业，并不适合 V 模型来指导软件开发。