软件工程 软件过程模型概述

概述

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

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

瀑布模型(Waterfall Model)

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

瀑布模型假定，一个待开发的系统需求是完整的、简明的、一致的，而且可以先于设计和实现完成之前产品。

这种模型的优点在于易于理解、管理成本低，强调阶段性早期计划及需求调查和产品测试。不足之处是，客户必须能够完整、正确、清晰地表达他们的需要。并且往往只有当项目接近结束的时候才能发现需求或设计中的错误，项目风控能力较弱。

事实上这种模型是过于理想化了，人在工作过程不可能不犯错，因此实际瀑布模型一般存在发现错误后回退修正错误的流程。

增量模型(Incremental Model)

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设将需求分段为一系列的增量产品，每一增量都可以分别开发。该模型采用随日程的进展而交错的线性序列。每个线性序列产生软件一个可发布的增量。

在增量模型中，第一个增量往往是核心产品，客户对每个增量的使用和评估都将作为下一个增量发布时的新特征和功能，这个过程在每一个增量发布后不断重复。直至产生完善的产品。如下图：

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

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

演化模型(Evolutionary Model)

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

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

原型模型(Prototype Model)

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

这个模型始于沟通，目的是定义软件的总体目标，标注需求，然后快速指定原型的开发计划，确定原型的目标和范围，迅速构建原型并交付，随后收集用户意见，然后进入下一轮原型的迭代开发。

螺旋模型(Spiral Model)

对于复杂的大型软件，一个原型往往难以达到要求，螺旋模型就是将瀑布模型和演化模型结合，加入两种模型都没有做到的风险分析。

这种模型将开发过程分为几个螺旋周期，每个螺旋周期与瀑布模型大致相似，如下图：

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

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

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

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

喷泉模型(Water Fountain Model)

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

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

这种模型的优点是各阶段没有界线，开发人员得以同步进行，提高开发效率。但这种方法由于同步进行往往需要更多的人员，这样不利于项目的管理。因此这种模型严格要求管理文档，但同时也使审核难度大幅提升。

基于构件的开发模型(Component-based Development Model)

这是一种利用预先包装的构件来构造应用的方法，构件可以来自于组织内部开发的，也可以是 商业化成品(COTS, Commercial Off-The Shelf) 软件构件。基于构件开发有很多螺旋模型的特点，这种方式本质上也是演化模型，需要迭代的方式来开发。但不同之处在于，这种模型采用预先打包的构件。

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

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

形式化方法模型(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年