三个模型
瀑布模型增量模型集成和配置模型没有适用于所有不同类型软件开发的过程模型。
瀑布模型
需求定义系统和软件的设计实现与单元测试集成与系统测试运行与维护瀑布模型的特征
从上一项活动中接受该项活动的工作成果（工作产品），作为输入。利用这一输入实施该项活动应完成的内容给出该项活动的工作成果，作为输出传给下一项活动对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。瀑布模型的优点：
1.强调开发的阶段性；
2.强调早期计划及需求调查；
3.强调产品测试。
瀑布模型的缺点：
从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。特别是瀑布模型过于依赖早期进行的唯一一次需求调查，不能适应需求的变化；软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。特别是由于瀑布模型是单一流程，开发中的经验教训不能反馈应用于本产品的过程。瀑布模型适合的系统种类
嵌入式系统：软件必须和硬件连接、交互，由于硬件不灵活，将软件功能的决策推迟到开发阶段通常不可行。关键性系统：要求在早期对软件规格说明和设计的安全性和信息安全进行全面分析，在实现阶段处理安全性问题通常代价非常大。大型软件系统：需要完整的规格说明以使不同的子系统可以独立开发。增量模型
增量模型的特点
增量模型又称产品改进模型（Incremental Model）从给定需求开始，通过构造一系列中间版本来实施开发活动，依次类推，直到系统完成。每一个中间版本都是需求分析、设计、编码和测试的过程。某些中间版本的开发可以并行进行。增量模型的优点
降低了实现需求变更的成本。较瀑布模型而言，重新分析和修改文档的工作流要少很多。在开发过程中更容易得到客户对已完成的开发工作的反馈意见。客户可以对软件的已有版本进行评价，并可以判断项目进度；客户通常会觉得从软件设计文档中评价项目、判断项目进度很困难。即使并未实现所有功能，也可以在早期向客户交付有用的软件，相对瀑布模型而言，客户可以更早地使用软件增量模型的缺点
过程不可见。管理人员需要常规的交付物来掌握进度。如果系统是快速开发的，那么要产生每个版本的文档就很不划算。伴随新的增量的加入，系统结构会退化。敏捷方法建议定期对软件重构。面对大型、复杂以及长生命周期的系统，增量模型的以上缺点更为突出。大型系统不同部分由不同团队开发，需要稳定的框架或体系结构，这种体系结构需要事先进行计划而不是增量地开发。集成与配置模型
寻找可复用的代码，按照需求对他们进行修改，并将他们与新代码相集成。
优点与缺点
优点：
基于配置和集成的面向复用的软件工程在降低软件开发量以及降低成本和风险方面有着明显的优势。可以实现更快的软件交付。
缺点：
系统可能不完全满足用户的真实需求。可能失去对系统演化的控制，因为可复用构建的新版本并不在使用该构件的组织的控制之下。
软件过程
软件过程中的四个活动(牢记)
软件需求规格说明（可行性分析、需求获取、需求分析）软件开发（总体设计、详细设计、实现）软件确认（测试）软件演化（维护）应对变化(牢记)
变化预测：软件过程包括可以在要求大量返工之前预见或预测可能的变化的活动，如原型。变化容忍：基于过程和软件设计手段，使系统修改变得容易。如增量模型、重构、框架。过程改进的方法
过程成熟度方法。关注改进过程和项目管理，并将好的软件工程实践引入到组织中。目标是提高产品质量和过程的可预测性。敏捷方法。关注迭代化的开发以及降低软件工程中的额外开销。主要特点是快速交付功能以及对客户需求变更的快速响应。其哲学思想：最好的过程是那些额外开销最低的过程。过程成熟度方法：
CMM是指“能力成熟度模型"其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。
正式的过程改进中的额外开销过高，小企业不用，有些大企业在实践。
