-
目录
瀑布模型（面向文档的软件开发模型）
场景：适用于需求稳定、明确的项目。
过程：需求分析、总体设计、详细设计、编码和调试、集成测试和系统测试。
特点：是一种严格遵循软件生命周期各个阶段的固定顺序的模型，每个阶段划分明确，都有固定文档或源程序流入下一个阶段。需求分析是一切活动的基础。
缺点：
1. 由于需求不可能精确、完整的描述整个系统，造成后期维护工作繁重，这些维护工作大多都是在修正需求分析阶段引入的缺陷。
2. 难以适应变化，如果软件在后期出现需求变化，整个系统需要从头开始。
3. 交付时间长，需要等到所有阶段都结束才能交付产品，导致客户无法尽快确定需求是否满足。
4. 产生大量对客户无用的文档，确花费了大量人力，是一种重载过程。
-
演化模型
场景：适用于用户需求不明确，且软件完善周期较长的项目。
特点：从初始的模型中逐渐演化为最终软件产品，是一种“渐变式”原型法。可以看作是若干次瀑布模型的迭代，在迭代的过程中得以演化和完善。
缺点：
1. 需要对需求进行明确的拆分，能清晰识别需求边界。
2. 所有的产品需求一开始并不完全弄清楚，会给总体设计带来困难及削弱产品的完整性。
-
螺旋模型
场景：项目规模庞大，复杂且高风险。
特点：是瀑布模型和演化模型的结合，并增加了风险分析（引入非常严格的风险识别、风险分析、风险控制），支持用户需求动态变化。
过程：需求定义、风险分析、工程实现、评审。
缺点：1. 需要具有相当丰富的风险评估经验和专业知识。
2. 过多的迭代次数会增加开发成本，延迟提交时间。
-
增量模型
场景：在系统的技术架构成熟、风险较低的时候采用。
特点：提前进行集成测试和系统测试，缩短初始版本的发布周期，提高用户对系统的可见度
策略：
- 增量发布
特点：将系统划分为若干个不同的版本，每个版本都是一个完整的系统，后一版本以前一版本为基础进行开发，扩充功能，版本间的增量必须是均匀的。
- 原型法
特点：当用户需求不明确或技术架构中存在很多不可认知因素的时候，采用原型法。主要目的是获得精确的用户需求或验证架构的可用性，一般情况会在后期的开发中抛弃这个原型，重新实现完整的系统。
缺点：如何组织一个开放的结构使得该模型不会退化到建造修补模型。
-
构件组装模型
特点：独立的、自包容的，构件之前通过接口相互协作。
过程：设计构件组装、建立构件库、构建应用软件、测试与发布。
优点：
1. 构件的自包容性让系统更容易扩展
2. 更容易被重用，降低开发成本
3. 粒度更小，因此安排开发任务更加灵活。
缺点：
- 设计不良的构件难以实现构件的优点，需要经验丰富的系统架构师。
- 考虑重用度时往往会对其他方面做出让步，如性能等。
- 组装应用程序时，要求程序要熟练掌握构件，增加研发人员学习成本。
- 第三方构建质量难以控制，可能会影响最终软件质量。
-
统一过程（up）（迭代的软件过程，以架构为中心）
场景：一个通用的过程框架，适合于各种应用领域、组织水平、项目规模的项目。
过程：初始、细化、构建、交付。
- 初始阶段（目标里程碑）：界定系统范围，明确系统目的，实现业务建模和需求分析。
- 细化阶段（架构里程碑）：描述抽象的软件逻辑模型（分析），设计软件架构。
- 构建阶段（能力里程碑）：完成系统构建（实施），并进行测试和部署。
- 交付阶段（发布里程碑）：系统完全成熟或产品化，进入下一个阶段，对产品进行重构、修改、测试和部署。
优点：
- 采用强大的UML建模语言，能够在团队中形成统一规范和模板。
- 有很多成熟的商业软件提供整个开发周期的相关支持，极大的降低开发和管理成本，提高开发效率。
缺点：虽然UP是一个迭代的开发模型，但是本身并不属于敏捷开发，未经裁剪的up是一个重载过程。
-
敏捷开发模型
场景：适用于小规模软件或者小团队开发。
特点：是一种以人为核心、迭代、循序渐进的开发方法。