软件开发V模型

万事万物，形成发展和创造都必然有其内在的发展趋势和规律。组织一件事情，一个组织、一个项目也是这样。忽然就从中感觉到了管理的魅力，根据规律制定合适的计划寻找流程真的让人通体舒畅，这或许也算是顺应趋势的一种吧，我们都属于自然。以软件开发为例，记录一些自己的体会。

V模型基本流程

开发系统前的基本流程如下：

1. 系统需求
2. 系统架构
3. 软件需求
4. 软件架构
5. 模块设计
6. 编码
7. 静态分析
8. 模块测试
9. 集成测试
10. 系统测试

上述流程是一个软件开发的基本步骤，在实施过程中测试贯穿全文，需要验证某些功能是否实现，实现中是否存在问题。所以V模型的拐点出现在静态分析后。需要通过单元测试来验证模块开发是否正确，集成测试来判断架构设计是否实现，最后的软件测试来判断软件需求、系统需求、系统架构等目标是否实现。
实际上也就是下图表达的含义，一层一层对应，像一个V字型，所以称为V模型。

需求更改

产品完成前或投入运营后可能会出现各种一开始没有发现的异常情况，此时对系统的需求或架构等会发生变化，将其以文件形式记录就称为软件变更规格。修正的过程需要对应的文件进行记录，同时也要有与实际改变之间的对应，这时候就构成了追踪关系。实际流程应为根据变更的需求找到对应的架构，再找实现该功能的模块，对模块中的函数进行修改。修改过程中需要写明新旧版本之间的区别，修改了哪些函数或头文件等，被称为“代码对比”。

在针对这些修正进行测试时需要写“测试大纲”，测试大纲中主要描述的是针对变更点进行的测试案例。描述测试案例时需要有测试案例编号，对应软件需求编号和对应的变更点。

这就给追踪找到了另一条路，可以从代码对比中找到修改的模块。而模块是用来实现功能架构的，所以可以找到对应的架构编号。不同的架构编号是用来实现不同的软件需求的。所以从下往上的路就此畅通。根据这些对应关系就可以实现编号追踪。
给一个变更点就可以捋出一条线来，这样就对开发的更改有了更加明确的了解。

碎碎念

实际在核对的时候也是你对自己系统更了解的一个过程，抽丝剥茧，才能找到真正的东西。
学习应当珅生不息。