文章目录

• 概述
• 瀑布模型(Waterfall Model)
• 增量模型(Incremental Model)
• 演化模型(Evolutionary Model)
• • 原型模型(Prototype Model)
  • 螺旋模型(Spiral Model)
• 喷泉模型(Water Fountain Model)
• 基于构件的开发模型(Component-based Development Model)
• 形式化方法模型(Formal Methods Model)
• 统一过程模型(Unified Process Model)
• 敏捷方法(Agile Development)

概述

软件过程模型实际上就是软件开发模型，这是软件开发全过程、活动、任务的结构框架。

下面将简单介绍一下各种常用的软件过程模型。

瀑布模型(Waterfall Model)

瀑布模型即将 软件生存周期 中的各个活动规定为依线性顺序连接的若干阶段模型。它规定了由前至后、相互连接的固定次序，如同瀑布逐级下落：

作为瀑布模型的变体，同样具有瀑布模型所有优点，另外还有瀑布模型不具有的优点：第一个可交付版本所需成本较少、开发由增量来表示，小系统承担的风险不大、版本交付快，减少用户需求变更、可以仅对少量增量先行投入资金。但它同样也有缺点，若第一版增量不好，则会给后面增量带来风险，另外若需求不稳定，则增量可能要重新开发。

使用增量模型的困难在于，把新的构件集成到现有的系统中的时候，必须不破坏已有的产品，也就是说必须把软件的体系结构设计的便于加入新的组成部分。从某种意义来讲，增量模型本身就是自我矛盾的，它一方面要把软件当做整体，另一方面又要把软件当做构件序列。

演化模型(Evolutionary Model)

软件类似其他复杂系统，会随着时间推移而演化，实际应用里，并非所有需求都被能预先定义，大量的案例证明在开发初期是难以得到一个完整的、准确的需求规格说明的。这主要是由于客户往往不能准确表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清。此外在整个开发过程中用户可能产生新的需求，导致需求变更。

在上述情况下，软件开发人员需要一种专门应对不断演变的过程模型。因此出现了演化模型，这是一种迭代的过程模型，使软件逐步演化出更完整的软件版本，这种模型尤其适合用于对软件需求缺乏准确认知的情况。

原型模型(Prototype Model)

基于上述的原因，产生了 快速原型(Rapid Prototype) 开发方法，原型是预期系统的一个可执行版本，反映出系统性质选定的子集，一个原型不必满足目标软件的所有要求，它目的是快速、低成本地构建出原型。迅速构建出一个让用户看得见、摸得着的系统框架，这样用户就可以根据这个框架提出自己的需求。如下图：

每个螺旋周期大致分为4步：

1. 制定计划——确定软件目标，选定方案，明确项目限制条件
2. 风险分析——分析方案并识别风险，消除风险
3. 实施工程——实施软件开发，验证阶段性成果
4. 用户评估——评价阶段性成果，提出修改建议，确定下一周期开发计划

螺旋模型强调的是风险分析，让开发人员和用户对每个演化层级的风险有了解，从而做出预案，因而这种模型适用于庞大、复杂、高风险的系统开发。与瀑布模型相比，螺旋模型支持用户需求的动态变化，为项目管理人员及时调整管理决策提供便利，从而降低开发风险。

使用这种模型时，需要开发人员具有一定程度的风险评估能力和专业知识。不过，过多的迭代次数会增加开发成本。

喷泉模型(Water Fountain Model)

喷泉模型是一种以用户需求为动力，以对象为驱动的模型，适合面向对象的开发方法，它克服了瀑布模型不支持软件重用和多项开发活动集成的局限。

喷泉模型使得开发过程中具有可迭代性和无间隙性。其中前者指模型中的开发活动常常需要重复多次，而后者指开发活动之间没有明显的边界，不像瀑布模型那样必须一项一项进行，无间隙性的基础是基于面向对象的。如下图：

领域工程的目的是构建领域模型、体系结构、可复用构件库。主要的目的就是分析领域中各种系统中公共部分或者相似部分。对候选的构件进行可变性分析，已适用于多个系统，然后经过严格测试和包装后存入可复用构件库。

而应用系统工程则是真正的使用可复用构件库来组装应用系统，如果其中的构件需要特化则修改，没有可用的构件仍然需要开发。在此过程中还会对构件的复用情况进行评价，以改进可复用构件。

形式化方法模型(Formal Methods Model)

这是一种建立在严格数学基础上的开发方法，采用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析与推导很容易就发现需求的歧义性、不完整性及不一致性。而且也可以用于验证分析模型、设计模型与程序。

通过数学的演算，使形式化功能规约转化为形式化设计规约，再转换为程序代码。

统一过程模型(Unified Process Model)

统一过程是一种用例与风险驱动，以架构为中心，迭代且增量的开发过程，由UML方法和工具支持。

与增量模型类似，这种方法将迭代视为袖珍项目，它们都包含正常软件项目的所有元素：计划、分析设计、构造、集成与测试、发布。

统一过程定义了4个技术阶段及对应的制品：

1. 起始阶段(Inception Phase)

   专注于项目的初创活动，主要产生的制品有：构想文档(Vision Document)、初始用例模型、初始项目术语表、初始业务用例、初始风险评估、项目计划（阶段及迭代）、业务模型、一个或多个原型（需要时）。

2. 精化阶段(Elaboration Phase)

   在理解了最初的领域范围后进行需求分析和架构演进，主要产生的制品有：用例模型、补充需求（含非功能修改）、分析模型、软件体系结构描述、可执行的软件体系结构原型、初步设计模型、修订风险列表、项目计划（含迭代计划、工作流、里程碑、技术工作产品）、初始用户手册。

3. 构建阶段(Construction Phase)

   关注系统的构件，产生现实模型，主要产生的制品有：设计模型、软件构件、集成的软件增量、测试计划及步骤、测试用例及支持文档（用户手册、安装手册、增量描述）。

4. 移交阶段(Transition Phase)

   关注软件提交，产生软件增量，主要产生的制品有：提交的软件增量、β测试 告、综合用户反馈。

每次迭代产生包括最终系统的部分完成版本及项目文档，通过逐步迭代，直至完成最终系统。在每个迭代中有5个核心工作流：需求工作流、分析工作流、设计工作流、实现工作流、测试工作流。

这种模型的典型代表是 RUP(Rational Unified Process) ，它是UP的商业扩展，完全兼容UP，但更完整详细。

敏捷方法(Agile Development)

敏捷开发是现在较为流行的方式，它总体目标是通过尽可能早并持续地交付有价值的软件使客户满意。通过在软件开发过程中加入灵活性，敏捷方法使用户能够在开发周期的后期增加或改变需求。

这种过程的典型方法有很多种，每种方法都基于一套原则，这些原则实现了敏捷方法的总体目标。下面主要简单介绍几种：

1. 极限编程(XP, Extreme Programming)

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

   • 4大价值观：沟通、简单性、反馈、勇气
   • 5个原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作
   • 12个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、结对编程、集体代码所有制、持续集成、每周工作40小时、现场客户、编码标准

2. 并列争球法(Scrum)

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

3. 自适应软件开发(ASD, Adaptive Software Development)

   这种方法采用6个基本原则：

   • 有一个使命做指导
   • 特征被视为客户价值的关键点
   • 过程中等待很重要，重做与做一样关键
   • 变化不视为变更，而是视为对开发中实际情况的调整
   • 确定的交付时间，迫使考虑每个版本的关键需求
   • 风险

4. 敏捷统一过程(AUP, Agile Unified Process)

   采用在大规模上连续、小规模上迭代的原理来构建系统。采用经典的UP阶段性活动，使团队为软件项目构想出一个全面的过程流。在每个活动中的迭代使用敏捷，并将有意义的软件增量尽可能的快速交付给用户。每个AUP执行下列活动：

   • 建模
   • 实现
   • 测试
   • 部署
   • 配置及项目管理
   • 环境管理

文中部分图片来自《软件工程》第4版 张海藩、吕云翔著 人民邮电出版 2013年