七种常见软件开发模型

• 目录

  瀑布模型（面向文档的软件开发模型）

  演化模型

  螺旋模型

  增量模型

  构件组装模型

  统一过程（up）（迭代的软件过程，以架构为中心）

  敏捷开发模型

  ---

  瀑布模型（面向文档的软件开发模型）

场景：适用于需求稳定、明确的项目。

过程：需求分析、总体设计、详细设计、编码和调试、集成测试和系统测试。

特点：是一种严格遵循软件生命周期各个阶段的固定顺序的模型，每个阶段划分明确，都有固定文档或源程序流入下一个阶段。需求分析是一切活动的基础。

缺点：

1. 由于需求不可能精确、完整的描述整个系统，造成后期维护工作繁重，这些维护工作大多都是在修正需求分析阶段引入的缺陷。

2. 难以适应变化，如果软件在后期出现需求变化，整个系统需要从头开始。

3. 交付时间长，需要等到所有阶段都结束才能交付产品，导致客户无法尽快确定需求是否满足。

4. 产生大量对客户无用的文档，确花费了大量人力，是一种重载过程。

             

• 演化模型

场景：适用于用户需求不明确，且软件完善周期较长的项目。

特点：从初始的模型中逐渐演化为最终软件产品，是一种“渐变式”原型法。可以看作是若干次瀑布模型的迭代，在迭代的过程中得以演化和完善。

缺点：

1. 需要对需求进行明确的拆分，能清晰识别需求边界。

2. 所有的产品需求一开始并不完全弄清楚，会给总体设计带来困难及削弱产品的完整性。

• 螺旋模型

场景：项目规模庞大，复杂且高风险。

特点：是瀑布模型和演化模型的结合，并增加了风险分析（引入非常严格的风险识别、风险分析、风险控制），支持用户需求动态变化。

过程：需求定义、风险分析、工程实现、评审。

缺点：1. 需要具有相当丰富的风险评估经验和专业知识。

2. 过多的迭代次数会增加开发成本，延迟提交时间。

• 增量模型

场景：在系统的技术架构成熟、风险较低的时候采用。

特点：提前进行集成测试和系统测试，缩短初始版本的发布周期，提高用户对系统的可见度

策略：

• 增量发布

特点：将系统划分为若干个不同的版本，每个版本都是一个完整的系统，后一版本以前一版本为基础进行开发，扩充功能，版本间的增量必须是均匀的。

• 原型法

特点：当用户需求不明确或技术架构中存在很多不可认知因素的时候，采用原型法。主要目的是获得精确的用户需求或验证架构的可用性，一般情况会在后期的开发中抛弃这个原型，重新实现完整的系统。

缺点：如何组织一个开放的结构使得该模型不会退化到建造修补模型。

• 构件组装模型

特点：独立的、自包容的，构件之前通过接口相互协作。

过程：设计构件组装、建立构件库、构建应用软件、测试与发布。

优点：

     1. 构件的自包容性让系统更容易扩展

     2. 更容易被重用，降低开发成本

     3. 粒度更小，因此安排开发任务更加灵活。

缺点：

1. 设计不良的构件难以实现构件的优点，需要经验丰富的系统架构师。
2. 考虑重用度时往往会对其他方面做出让步，如性能等。
3. 组装应用程序时，要求程序要熟练掌握构件，增加研发人员学习成本。
4. 第三方构建质量难以控制，可能会影响最终软件质量。

• 统一过程（up）（迭代的软件过程，以架构为中心）

场景：一个通用的过程框架，适合于各种应用领域、组织水平、项目规模的项目。

过程：初始、细化、构建、交付。

1. 初始阶段（目标里程碑）：界定系统范围，明确系统目的，实现业务建模和需求分析。
2. 细化阶段（架构里程碑）：描述抽象的软件逻辑模型（分析），设计软件架构。
3. 构建阶段（能力里程碑）：完成系统构建（实施），并进行测试和部署。
4. 交付阶段（发布里程碑）：系统完全成熟或产品化，进入下一个阶段，对产品进行重构、修改、测试和部署。

优点：

1. 采用强大的UML建模语言，能够在团队中形成统一规范和模板。
2. 有很多成熟的商业软件提供整个开发周期的相关支持，极大的降低开发和管理成本，提高开发效率。

缺点：虽然UP是一个迭代的开发模型，但是本身并不属于敏捷开发，未经裁剪的up是一个重载过程。

• 敏捷开发模型

场景：适用于小规模软件或者小团队开发。

特点：是一种以人为核心、迭代、循序渐进的开发方法。