软件开发生命周期模型
瀑布模型
优点：有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究，提高了大型软件项目开发的质量和效率。 缺点：开发过程一般不能逆转，否则代价太大；实际的项目开发很难严格按该模型进行；客户往往很难清楚地给出所有的需求，而该模型却要求如此；软件的实际情况必须到项目开发的后期客户才能看到，这要求客户有足够的耐心。 使用范围：用户的需求非常清楚全面，且在开发过程中没有或很少变化；开发人员对软件的应用领域很熟悉；用户的使用环境非常稳定；开发工作对用户参与的要求很低。
增量模型
优点：采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源；如果核心产品很受欢迎，则可增加人力实现下一个增量；可先发布部分功能给客户，对客户起到镇静剂的作用。 缺点：并行开发构件有可能遇到不能集成的风险，软件必须具备开放式的体系结构；增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。 使用范围：进行已有产品升级或新版本开发，增量模型是非常适合的；对完成期限严格要求的产品，可以使用增量模型；对所开发的领域比较熟悉而且已有原型系统，增量模型也是非常适合的。
螺旋模型
优点：设计上的灵活性，可以在项目的各个阶段进行变更；以小的分段来构建大型系统,使成本计算变得简单容易；客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性； 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。 缺点：采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失；过多的迭代次数会增加开发成本，延迟提交时间。 使用范围：螺旋模型只适合于大规模的软件项目。
统一软件过程
主要特点
AUP主要适用于20人以下的团队采用面向对象的方法进行中小型项目的开发。其主要特点是：
- 以架构为中心：软件架构提供一个其它开发过程所涉及到的中心点。
- 用例驱动：开发团队使用从需求收集到编程，测试阶段的测试用例。
- 迭代和增量：逐步趋向稳定，有效管理需求变更，持续集成，更快的理解系统，持续风险评估。
各个阶段
RUP中的软件生命周期在时间上被分解为四个顺序的阶段，分别是：初始阶段 (Inception)、细化阶段 (Elaboration)、构造阶段 (Construction) 和交付阶段 (Transition)。
每个阶段结束于一个主要的里程碑：每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。
- 初始阶段：生命周期目标（Lifecycle Objective）里程碑，包括一些重要文档，如项目构想 (Vision)、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务案例等 。
- 精化阶段：生命周期体系结构 (Lifecycle Architecture) 里程碑，包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。
- 构建阶段：初始运行能力 (Initial Operational Capability) 里程碑，包括可以运行的软件产品、用户手册等，它决定了产品是否可以在测试环境中进行部署。
- 移交阶段：产品发布 (Product Release) 里程碑，确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。
统一过程为企业按固定节奏生产、固定周期发布软件产品提供了依据。统一过程模型中，各个阶段的生命周期是有固定长度的， 因此在产品的的迭代开发过程有较为明确的时间限制的。
固定周期生产和发布产品的原因
软件开发周期的确定的，因为每个阶段都会有显著的里程碑，每个迭代阶段的目标是明确的。各个阶段的生命周期具有固定长度， 所以产品的的迭代开发过程有较为明确的时间限制，因此软件企业能按固定节奏生产、固定周期发布软件产品。每个迭代都是瀑布的工作流程，在迭代内部需求明确的情况下，差错较少。每个迭代在增量且制品可运行，能够及时交付并得到反馈。固定迭代周期有利于量化团队和个人的生产率。而且软件工程的规模对于客户来说是模糊的，因此软件工程的范围也是相对可控的。方便了项目的管理，当工程目标细化了之后，管理更加高效有序（当然也能帮公司赚取更多利润）。
