拓展阅读
Devops-02-Jpom 简而轻的低侵入式在线构建、自动部署、日常运维、项目监控软件
项目管理平台-01-jira 入门介绍 缺陷跟踪管理系统，为针对缺陷管理、任务追踪和项目管理的商业性应用软件
项目管理平台-01-Phabricator 入门介绍 一套集成的强大工具，帮助公司构建更高质量的软件
V模型
软件开发中的V模型是一种延伸自瀑布模型的软件开发过程，是通用V模型的一个例子。
V模型的软件开发不是以直线的方式进行，其过程在源代码阶段之前逐步往下，而在源代码阶段之后逐步往上，形成了V字形。
V模型指出了软件开发中的各阶段以及其对应软件测试阶段之间的关系。
横轴表示时间或是专案的完成度，而纵轴表示抽象的程度（范围越大，越抽象的在越上方）
专案定义阶段
需求分析
需求分析阶段是专案定义阶段中的第一个阶段，有些文献也称为是验证（verification）阶段的第一个阶段。此阶段要分析用户的需要，整理出系统的需求（功能需求）。此阶段着重的是建构出要实现的理想系统，但不用决定软件的设计方式。一般而言，此阶段会和用户面谈，建立用户需求文件（user requirements document）。
用户需求文件会说明系统的功能、界面、性能、资料、安全性等，会列出客户预期的需求。企业分析师会用这个，配合其系统性的了解，来和用户沟通。用户会仔细的确认这些文件，因为文件是系统设计师的指南，也会在这个阶段规划用户验收测试。
在收集用户需求时，有许多不同的方式，常见的有访问、问卷、文件分析、观察、利用可丢弃的原型、用例等。
系统设计
系统设计是系统设计师根据用户需求文件，分析并理解要开发系统的业务流程的阶段。此阶段会列出要实现用户需求需要的技术以及可能性。若有些用户需求不可行，会反应给用户，针对此需求的最后处理方式也会列在用户需求文件中。
此阶段也会产生软件规格文件（software specification document），是开发阶段的蓝图，其中会包括大致的系统架构、指令选单结构、数据结构等，其中也会包括业务场景、样本视窗以及报表以帮助理解。此阶段也会产生实体图（entity diagrams）、数据字典等技术文件，并且整理系统测试的文件。
架构设计
这个阶段会设计计算机系统结构及软件架构，也称为高阶设计。选择架构的基准是应该可以实现所有模组的列表、模组的简单机能、界面关系、相依性、数据库、数据库表、架构图、技术细节等。在这个阶段也会设计整合测试的内容[3]。
模组设计
模组设计阶段也称为低阶设计。会将设计的系统拆解为较小的单元或是模组，也会说明每一部分的内容，让程式设计者可以直接写程式。 低阶设计文件或是程式规格书会包括模组的逻辑细节，可能会以伪代码的方式表示，也会有以下的内容：
数据库表，其中有所有的元素、型态以及大小。 完整应用程序接口程式的界面细节 所有相依性的议题 错误讯息列表 模组的所有输入及输出 单元测试会在此阶段进行规划。
确认阶段
在V模型中，验证（或专案定义）阶段中的每一阶段，在确认阶段都会有对应旳阶段[4]。以下是V模型的验证阶段，不过也会使用其他的名称。
单元测试
在V模型中，在模组设计阶段就会规划单元测试计划（Unit Test Plans）。单元测试计划的目的是要消除程式码层级及单元层级的错误。单元是程式中可以独立存在的最小程式体，例如程式模组。单元测试是验证最小的程式体在和其他程式隔离的情形下，是否可以正常运作。
整合测试
整合测试的计划会在架构设计阶段订定。整合测试会验证这些独立创建、独立测试过的模组是否可以共存，互相交换讯息。整合测试的测试结果常会分享给用户的团队。
系统测试
系统测试计划会在系统设计的阶段订定。系统测试不同于单元测试及整合测试。系统测试计划会由用户的团队来进行。系统测试会确保所开发的软件符合预期的需求，会测试整个软件的机能、相互依存以及通讯。系统测试也会验证系统符合机能需求以及非机能需求。像负载测试、性能测试、压力测试及回归测试等，都是系统测试的一部分。
用户验收测试
用户验收测试（User Acceptance Test）计划会在需求分析阶段就订定。测试计划是由企业用户来进行。
用户验收测试会在用户的环境下进行，设法模拟实际产品的环境，也会使用实际的数据。
用户验收测试的目的是要确认所提供的系统符合客户需求，而且系统已可以在实际环境下使用。
批评
敏捷软件开发倡议者对V模型有所批评，因为以下的原因，V模型不适合作为软件开发的模型：
V模型太过简单，无法准确的反映软件开发的过程，会让管理者有一种错误的安全感。
V模型反映了软件开发中，管理者的观点，适合专案管理者、会计师及律师，但不适合软件开发者及用户。
对于新手而言，V模型很容易了解。但新手需要对开发流程有进一步的了解，并了解V模型在在实务上如何应用及扩展，才能真正的应用V模型。若开发者仍坚持早期对V模型的较不成熟的观点，很难成功的应用V模型。
V模型不太可变，鼓励在软件开发上，比较严谨及线性的观点，在本质上比较没有反应变化的能力。
V模型是瀑布模型小幅改变后的版本，因此也有类似瀑布模型的问题。这类模型较强调测试、特别是早期的测试计划。不过有关V模型常见的批评就是：V模型将测试塞在开发流程后面的时间区间内，有可能早期的专案设计时程已经超过时间，但软件正式发布的时间不变，因此就会大幅压缩测试的时间。
V模型较符合一些效率较低、效果也较弱的测试方法，因此潜在的也会鼓励这种测试方法。V模型较鼓励事先写测试脚本，而不是进行探索测试。V模型鼓励测试者去确认他们预期会发现的项目，不是找出实际的情形。V模型也鼓励在开发阶段及确认阶段各对应阶段的严谨连结（例如，由用户需求文件产生用户验收测试），而不是鼓励测试者去选择最有效率、有效果的方式来进行测试。
V模型缺乏一致性及准确性。因此许多人会对V模型困惑，不确定其准确定义。若将V模型视为是大多数人认为的那种方法，在软件开发上旳意义又不大。不同的人可能对于V模型的优点及缺点会有不同的认知，这也反应V模型在某程度上没有共通的定义。
现状
V模型的支持者指出V模型也会逐渐进步，在开发过程中也可以有可变性，符合敏捷开发的原则。
支持者认为V模型强调纪律、也提倡精细的设计、开发以及文件,这些都是要建构稳定软件产品时，必要的元素。
近年来，V模型已用在医疗软件的开发上。
参考资料
https://zh.wikipedia.org/wiki/V%E6%A8%A1%E5%9E%8B_(%E8%BB%9F%E9%AB%94%E9%96%8B%E7%99%BC)
