软件过程模型
分类：
瀑布模型、 增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型、形式化方法模型
瀑布模型：
优点：
容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。
不足之处是，客户必须能够完整、正确和清晰地表达他们的需要；在开始的两个或3个阶段中，很难评估真正的进度状态;当接近项目结束时，出现了大量的集成和测试工作:直到项目结束之前，都不能演示系统的能力。
在瀑布模型中，需求或设计中的错误往往只有到了项目后期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出预算。
缺点：
（1）开发过程一般不能逆转，否则代价太大；
（2）实际的项目开发很难严格按该模型进行；
（3）客户往往很难清楚地给出所有的需求，而该模型却要求如此。
（4）软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。
适用于：
（1）用户的需求非常清楚全面，且在开发过程中没有或很少变化；
（2）开发人员对软件的应用领域很熟悉；
（3）用户的使用环境非常稳定；
（4）开发工作对用户参与的要求很低。
它是以文档作为驱动、适合于软件需求分明的软件项目的模型
增量模型：
优点：
作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外，它还有以下优点:
（1）第一个可交付版本所需要的成本和时间很少;
（2）开发由增量表示的小系统所承担的风险不大；
（3）由于很快发布了第一个版本，因此可以减少用户需求的变更；
（4）运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。
缺点：
（1）并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；
（2）增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
适用于：
（1）进行已有产品升级或新版本开发，增量模型是非常适合的；
（2）对完成期限严格要求的产品，可以使用增量模型；
（3）对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
增量模型适用于需求比较明确，架构比较稳定的软件开发，每次增量不影响已有的架构，在已有的架构下增加新的功能。迭代模型适用于需求不甚明确、难度比较大的软件开发。
原型模型：
优点：
（1）可以得到比较良好的需求定义，容易适应需求的变化；
（2）有利于开发与培训的同步；
（3）开发费用低、开发周期短且对用户更友好。
缺点：
（1）客户与开发者对原型理解不同；
（2） 准确的原型设计比较困难；
（3） 不利于开发人员的创新。
适用于：
（1）对所开发的领域比较熟悉而且有快速的原型开发工具；
（2）项目招投标时，可以以原型模型作为软件的开发模型；
（3）进行产品移植或升级时，或对已有产品原型进行客户化工作时，原型模型是非常适合的。
适用于用户需求不清、需求经常变换的情况。当系统规模不是很大也不是太复杂时，采用该方法比较好
螺旋模型：
优点：
（1）设计上的灵活性,可以在项目的各个阶段进行变更；
（2）以小的分段来构建大型系统,使成本计算变得简单容易；
（3）客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；
（4） 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。
缺点：
（1）采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；
（2）过多的迭代次数会增加开发成本，延迟提交时间。
适用于：
螺旋模型只适合于大规模的软件项目。
对于新近开发，需求不明确的情况下，适合用螺旋模型进行开发，便于风险控制和需求变更。
喷泉模型：
介绍：
喷泉模型是-种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。
它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。
喷泉模型使开发过程具有迭代性和无间隙性，迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断地完善软件系统。无间隙是指在开发活动(如分析、设计、编码)之大间不存在明显的边界，也就 是说，它不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代地进行。
适用于：
喷泉模型主要用于面向对象的软件项目，软件的某个部分通常被重复多次，相关对象在每次迭代中随之加入渐进的软件成分。