软件过程模型

软件过程模型

软件过程模型习惯上称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。

1. 瀑布模型

瀑布模型将软件生命周期中的各个活动规定为依据线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。

1.1 瀑布模型的优点（顺序进行、阶段明确、易于管理）

• 阶段明确、顺序执行、易于管理，并且每个阶段都有明确的输出成果。

1.2 瀑布模型的缺点（不灵活，无法提前发现并解决问题）

• 无法灵活应对需求变更、无法在早期阶段发现和解决问题等。在瀑布模型中，需求或设计的错误往往只有到了项目后期才能被发现，对项目风险的控制能力较弱，导致项目通常会延期，开发费用超出预算。

2. 增量模型

增量模型是一种分阶段的软件开发过程，它将在软件开发的不同阶段中，按照一定的时间间隔，逐步增加新的功能和特性。增量模型的特点是逐步增加软件的功能、减少开发风险以及灵活的变更管理。

2.1 增量模型的优点（减少风险、快速发布、灵活投资）

可交付的第一个版本所需要的成本和时间很少，开发由增量表示的小系统所承担的风险不大，由于很快发布了第一个版本，因此可减少用户需求的变更。同时，它也具有瀑布模型所有的优点。

2.2 增量模型的缺点（需求变更、重新开发和配置管理复杂）

若没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；若需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发或重新发布；管理发生的成本、进度和配置的复杂性可能会超出组织的能力。

3. 演化模型

典型的演化模型有原型模型和螺旋模型。

3.1 原型模型

原型模型开始于沟通，目的是定义软件的总体目标、标识需求，然后快速制定原型开发计划，确定原型的目标和范围，快速构建原型并交付用户使用，收集客户反馈意见，并在下一轮中对原型进行改进。在前一个原型需要改进(或扩展其范围)的时候，进入下一轮原型的迭代开发。

原型模型又根据使用目的的不同，分为探索型原型、实验型原型和演化型原型。

3.2 螺旋模型

螺旋模型是一种风险驱动的软件开发过程，它将软件开发分为多个螺旋周期，每个螺旋周期都包含需求分析、设计、实现和测试等阶段，同时不断评估风险和调整开发计划。螺旋模型的特点是不断迭代和完善的软件开发过程、高风险的分析和风险管理以及灵活的变更管理。

3.2.1 螺旋模型的优点（灵活、适用于大项目）

• 设计上的灵活性，可以在项目的各个阶段进行变更。
• 以小的分段来构建大型系统，使成本计算变得简单容易。
• 客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性。
• 随着项目推进，客户始终掌握项目的最新信息，从而他或她能够和管理层有效地交互。

3.2.2 螺旋模型的缺点（成本大、风险高）

• 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
• 过多的迭代次数会增加开发成本，延迟提交时间。

4. 敏捷开发模型

敏捷开发模型是一种以人为中心、迭代、灵活的软件开发过程，它强调快速响应变化、持续交付价值和高质量的软件产品。敏捷开发模型的特点是高度迭代、自我组织、开放式反馈以及持续改进。

4.1 极限编程（XP）

XP是一种轻量级(敏捷)、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。

4.1.1 4大价值观

沟通、简单性、反馈和勇气。

4.1.2 5个原则

快速反馈、简单性假设、逐步修改、提倡更改和优质工作。

4.1.3 12个最佳实践

测试驱动开发（TDD）；短迭代周期；简单设计；结对编程；集体所有制；持续集成；每周工作40小时；现场客户；代码规范；可持续的开发速度；计划游戏；系统隐喻。

4.2 水晶法(Crystal)

水晶法认为每一个不同的项目都需要一套不同的策略、 约定和方法论，认为人对软件质量有重要的影响，因此随着项目质量和开发人员素质的提高，项目和过程的质量也随之提高。通过更好地交流和经常性的交付，软件生产力得到提高。

4.3 并列争求法(Scrum)

并列争求法使用迭代的方法，其中，把每30天一次的迭代称为一个“冲刺”，并按需求的优先级别来实现产品。多个自组织和自治的小组并行地递增实现产品。协调是通过简短的日常情况会议来进行，就像橄榄球中的“并列争球”。

4.4 自适应软件开发(ASD)

4.5 敏捷统一过程(AUP)

敏捷统一过程(Agile Unified Process，AUP) 采用”在大型上连续”以及在“在小型上迭代”的原理来构建软件系统。采用经典的UP阶段性活动(初始、精化、构建和转换)，提供了一系列活动，能够使团队为软件项目构想出一个全面的过程流。在每个活动里，一个团队迭代使用敏捷，并将有意义的软件增量尽可能快地交付给最终用户。每个AUP迭代执行以下活动:

• 建模。建立对商业和问题域的模型表述，这些模型“足够好”即可，以便团队继续前进。
• 实现。将模型翻译成源代码。
• 测试。像XP一样，团队设计和执行一系列的测试来发现错误以保证源代码满足需求。
• 部署。对软件增量的交付以及获取最终用户的反馈。
• 配置及项目管理。着眼于变更管理、风险管理以及对团队的任一-制品的控制。项目管理追踪和控制开发团队的工作进展并协调团队活动。
• 环境管理。协调标准、工具以及适用于开发团队的支持技术等过程基础设施。

5. 基于构件的开发模型

基于构件的开发模型是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品（COTS）软件构件。一种基于构件的开发模型包括领域工程和应用系统工程。

1. 领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。
2. 应用系统工程的目的是使用可复用构件组装应用系统。

6. 统一过程模型

统一过程（UP）模型是一种“用例和风险驱动，以架构为中心，迭代并增量”的开发过程，由 UML 方法和工具支持。统一过程定义了四个技术阶段及其主要工作产品：

1. 起始阶段：专注项目的初创活动，主要工作产品有构想文档、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划、业务模型及多个原型（需要时）。
2. 精化阶段：在理解了最初的领域范围之后进行需求分析和架构演进，主要工作产品有用例模型、补充需求、分析模型、整体体系结构描述、可执行的软件体系结构原型、初步设计模型、修订的风险列表、项目计划及初始用户手册。
3. 构建阶段：关注系统的构建，产生实现模型，主要工作产品有设计模型、软件构件、集成软件增量、测试计划及步骤、测试用例及支持文档（用户手册、安装手册等）。
4. 移交阶段：关注软件提交方面的工作，产生软件增量，主要工作产品有提交的软件增量、β 测试报告和综合用户反馈。

统一过程的典型代表是 RUP，RUP 是 UP 的商业扩展，完全兼容 UP，比 UP 更完整、更详细。

敏捷方法的总体目标是通过尽可能早地、持续地对有价值的软件进行交付使客户满意。敏捷过程的典型方法有很多，每一种方法基于一套原则，这些原则实现了敏捷方法所宣称的理念，即敏捷宣言。

---

软考学习笔记，欢迎纠错与探讨，不喜勿喷！

---