软件过程模型
软件生命周期
从设计、投入使用到被淘汰的全过程注意这里不只是设计、连维护也是每个过程会产生相应的文档
软件过程模型
也称为软件开发模型、软件生存周期模型结构框架能直观表达软件开发全过程
能力成熟度模型
用来评估软件的生产能力CMM是目前国际上使用流行的一种软件生产过程行业标准模型，可定义、评价软件开发过程的成熟度，并提供提高软件质量的指导。CMM模型分为五级：初始级(1级)、可重复级(2级)、定义级(3级)、管理级(4级)、优化级(5级)共5个成熟度等级，低级别是实现高级别的基础对应说明：
(1)初始级(initial)。
工作无序，项目进行过程中常放弃当初的计划。
管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一但离去，工作秩序面目全非。
(2)可重复级(Repeatable)。
管理制度化，建立了基本的管理制度和规程，管理工作有章可循。
初步实现标准化，开发工作比较好地按标准实施。
变更依法进行，做到基线化，稳定可跟踪，新项目计划和管理基于过去实践经验，具有重复以前成功项目的环境和条件。
核心：建立基本的项目管理和实践来跟踪项目费用、进度和功能特性
(3)已定义级(Defined)。
许多组织追求的目标
开发过程，包括技术工作和管理工作，均已实现标准化、文档化。
建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。
核心：使用标准开发过程(或方法论)构建(或集成)系统
(4)已管理级(Managed)。
产品和过程已建立了定量的质量目标。
开发活动中的生产率和质量是可量度的。
已建立过程数据库。
已实现项目产品和过程的控制。
可预测过程和产品质量趋势，如预测偏差，实现及时纠正。
核心：管理层寻求更主动地应对系统的开发问题
(5)优化级(Optimizing)。
可集中精力改进过程，采用新技术、新方法。
拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。
可取得过程有效性的统计数据，并可据进行分析，从而得出最佳方法。
核心：连续地监督和改进标准化的系统开发过程
传统的软件过程模型
瀑布模型
瀑布模型（Waterfall Model） 是一个软件生命周期模型，开发过程是通过设计一系列阶段顺序展开的，从系统需求分析开始直到产品发布和维护，项目开发进程从一个阶段“流动”到下一个阶段，这也是瀑布模型名称的由来。是一种使用广泛，以文档为驱动的模型每个阶段都有与其相关联的里程碑和可交付产品每个阶段结束前完成文档审查，及早改正错误特点
阶段间具有顺序性和依赖性
必须等前一阶段的工作完成之后，才能开始后一阶段的工作。前一阶段的输出文档就是后一阶段的输入文档。推迟实现的观点
清楚的区分逻辑设计与物理设计，尽可能推程序的物理实现，是因为编码之前阶段的工作没做或做得不扎实，过早地考虑进行程序实现，往往导致大量返工，有时甚至发生无法弥补的问题，带来灾难性的后果。质量保证的观点
每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。
每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。
实际模型
原因
传统的瀑布模型过于理想化，人在工作过程中不可能不犯错误。当后面阶段发现前面阶段的错误时，需要沿图中左侧的反馈线返回前面的阶段，修正前面阶段的产品之后再回来继续完成后面阶段的任务。
缺点
瀑布模型是由文档驱动，在可运行的软件产品交付给用户之前，用户只能通过文档来了解产品是什么样的。瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。也不适合需求模糊的系统。测试只是其中一个阶段，缺乏全过程测试思想
应用场合
适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗
V模型
V模型的中心思想是，研发人员和测试人员需要同时工作，在软件做需求分析的同时就会有测试用例的跟踪，这样可以尽快找出程序错误和需求偏离，从而更高效的提高程序质量，最大可能的减少成本，同时满足用户的实际软件需求。V模型的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。单元测试：是否满足详细设计的要求
集成测试：验证已测试过的部分是否可以很好地结合在一起
系统测试：检验系统功能、性能是否达到系统的要求。
验收测试：确定软件的时限是否满足用户需求或合同需求
特点
V模型体现的主要思想是开发和测试同等重要，左侧代表的是开发活动，而右侧代表的是测试活动。V模型针对每个开发阶段，都有一个测试级别与之相对应。测试依旧是开发生命周期中的阶段，与瀑布模型不同的是，有多个测试级别与开发阶段对应。V模型适用于需求明确和需求变更不频繁的情形。
缺点
虽然测试尽早的进入到开发阶段，但是真正进行软件测试是在编码之后，这样忽视了测试对需求分析，系统设计的验证，时间效率上也大打折扣。
原型模型
博客出处
在开发真实系统之前，通过构建一个可以运行的软件原型，使开发人员与用户达成共识，以便理解和澄清问题，最终在确定的客户需求基础上开发客户满意的软件产品。
根据运用原型的目的和方式不同，可以将原型模型分为快速原型模型（抛弃型）和原型进化模型（渐进型）。
快速原型模型
快速原型模型是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统在需求上的模糊认识，或用来试探某种设计是否能够获得预期结果。特点
快速原型是用来获取用户需求的，或是用来试探设计是否有效的。一旦需求或设计确定下来了，原型就将被抛弃。因此，快速原型要求快速构建、容易修改，以节约原型创建成本、加快开发速度。快速原型往往采用一些快速生成工具创建，例如 4GL 语言。目前，Microsoft Visual Basic、Inprise Delphi 等基于组件的可视化开发工具，也被应用于原型创建之中，并且都是非常有效的快速原型创建工具，而且还可用于原型进化。
快速原型是暂时使用的，因此并不要求完整。它往往针对某个局部问题建立专门原型， 如界面原型、工作流原型、查询原型等。
快速原型不能贯穿软件的整个生命周期，它需要和其他的过程模型相结合才能产生作 用。例如，在瀑布模型中应用快速原型，以解决瀑布模型在需求分析时期存在的不足。
原型进化模型（演化模型）
原型进化对开发过程的考虑是，针对有待开发的软件系统，先开发一个原型系统给用户使用，然后根据用户使用情况的意见反馈，对原型系统不断修改，使它逐步接近并最终到达开发目标。跟快速原型不同的是，快速原型在完成需求定义后将被抛弃，而原型进化所要创建的原型则是一个今后将要投入应用的系统，只是所创建的原型系统在功能、性能等方面还有许多不足，还没有达到最终开发目标，需要不断改进。 原型进化的工作流程如图所示。特点
原型进化模型将原型用于开发的全过程，原型由最基本的核心开始，逐步增加新的功能和新的需求，反复修改反复扩充，最后发展为用户满意的最终系统。原型进化模型是通过不断发布新的软件版本而使软件逐步完善的，因此，这种开发模式特别适合于那些用户急需的软件产品开发。它能够快速地向用户交付可以投入实际运行的软件成果，并能够很好地适应软件用户对需求规格的变更。原型进化模型能够适应软件需求的中途变更
问题
原型进化模型虽说使开发进程加快了，但不能像瀑布模型那样提供明确的里程碑管理，随着开发过程中版本的快速更新，项目管理、软件配置管理会变得复杂起来，管理者难以把握开发进度。因此，对于大型软件项目，原型进化模型缺乏有效的管理规程。
开发过程中软件版本的快速变更，还可能损伤软件的内部结构，使其缺乏整体性和稳定性。另外，用于反映软件版本变更的文档也有可能跟不上软件的变更速度。这些问题必将影响到今后软件的维护
增量模型
原博文
把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次地分析、设计、编码和测试这些增量组件。
增量模型对软件过程的考虑是：在整体上按照瀑布模型的流程实施项目开发，以方便对项目的管理；但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，并以构件为单位逐个地创建与交付，直到全部增量构件创建完毕，并都被集成到系统之中交付用户使用。如同原型进化模型一样，增量模型逐步地向用户交付软件产品，但不同于原型进化模型的是，增量模型在开发过程中所交付的不是完整的新版软件，而只是新增加的构件。
增量模型的优点
增量模型的最大特点就是将待开发的软件系统模块化和组件化。基于这个特点，增量模型具有以下优点。
1、将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展。
2、以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统。
3、开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件。当组件的优先级发生变化时，还能及时地对实现顺序进行调整。
增量模型的缺点：
1、要求待开发的软件系统可以被模块化。如果待开发的软件系统很难被模块化，那么将会给增量开发带来很多麻烦。
2、由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
3、在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。
增量模型适用范围：
1、软件产品可以分批次地进行交付。
2、待开发的软件系统能够被模块化。
3、软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。
4、项目管理人员把握全局的水平较高。
螺旋模型
螺旋模型是快速原型法以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。这种模型的每一个周期都包括需求定义、风险分析、工程实现和评审4个阶段，由这4个阶段进行迭代。螺旋模型即是一种引入了风险分析与规避机制的过程模型，是瀑布模型、快速原型方法和风险分析方法的有机结合。螺旋模型最大的特点在于引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。优点
设计上的灵活性,可以在项目的各个阶段进行变更。
以小的分段来构建大型系统,使成本计算变得简单容易。
客户参与每个阶段的开发,保证了项目不偏离正确方向及项目的可控性。
客户始终掌握项目的最新信息, 能够和管理层有效地交互。
客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。
