从一个执行层面的测试做到测试主管这个级别，当你手下管理多个项目和测试人员时，流程成为你必须要考虑的事，一般公司也很少有自己独立的SQA部门进行过程管控，如果是弱矩阵式的组织架构的模式下，基本QA/QC作为一个质量部门存在于公司内，而过程管控流程制定一般也分摊到项目管理者或质量部门中。那我们今天就来讨论一下软件研发流程这个话题，对于大多数普通的人员来看，流程是否完善规范，也是看一家公司的软件研发是否正规的主要标准。对于国内的软件企业，我们一般常见的几种开发模型有：
边做边改模型：没有规格说明，没有相关的设计，得到客户需求直接进行编码形成版本，随着客户的需要一次一次不断的修改；也就是我们早期所说的作坊式软件开发模型
瀑布模型：相信也是现在传统软件研发使用最广泛的开发模型，软件生命周期被计划、需求、设计、编码、测试、维护六个阶段进行划分，自上而下以固定次序衔接着进行一轮迭代。
快速原型模型：在需求阶段建立一个快速模型让客户或客户代表以此原型进行需求评论，细化需求，等原型满足用户需求后再进行软件的开发，常见的是那种客户前端和研发后端相分离的组织里，产品运营产品经理，UI设计及客户体验或QA验收作为一个客户代表团队，前端后端QC测试作为一个实现团队分部合作的项目中比较常见这种开发模型也算是弥补了瀑布模型的需求开发风险不明确的风险缺点
增量模型：又叫演化模型，在此模型中软件各阶段并不直接交付一个可运行的完整产品，而是交付满足客户需求一的个子集的可运行的产品，整个产品被分解成若干个构件，研发人员逐个构件进行交付，迭代的完成整个软件产品，我们常说的敏捷开发就主要以这种开发模型发展改良为主
RUP：这个模型是由rational公司提出的一套开发过程模型，是一个面向对象软件工程的通用业务流程，主要适合大型的商业软件项目，是一整套系统的方法论，对应的它有一整套工具集和规范标准进行辅助，因为其复杂度和适应性，国内很少有企业进行项目实践
IPD模型、螺旋模型、智能模型等等：因适用性的问题在这里就不一一说明了，网上相关的介绍文章有很多
介绍了那么多通用工作流程，主要并不是想去比较哪个流程孰优孰劣，而是觉得每个流程都有其可取之处，只有适合之说而没有好坏之分。就拿我们普遍认为小作坊式的边做边改模式，你不可否认其工作的便利性和灵活性，初创公司在没有用户及资源基础或非矩阵式组织内人员不多的情况下，这种工作方式是最适合不过的了。
网友评论
