软件过程模型详解：构建高效开发流程

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

1、瀑布模型（Waterfall Model）

瀑布模型是将软件生存周期中各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、测试、运行与维护。它规定了由前至后、相互衔接的固定次序，如同瀑布流水逐级下落。如下图所示。

瀑布模型为软件的开发和维护提供了一种有效的管理模式，根据这一模式来制订开发计划，进行成本预算，组织开发力量，以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导，因此它是以文档为驱动，适合于软件需求很明确的软件项目的模型。

优点是容易理解，管理成本低；强调开发的阶段性早期计划及需求调查和产品测试。

缺点是客户必须完整、正确和清晰的表达他们的需要，而这往往又不可能；在后期很难评估项目的进度状态；对项目的风险控制能力弱。

2、增量模型（Incremental Model）

增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的“增量”，如下图所示。当使用增量模型时，第一个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。

增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点。此外还具有如下优点：

• 第一个可交付版本所需要的成本和时间很少；
• 开发由增量表示的小系统所承担的风险不大；
• 由于很快发布了第一个版本，因此可以减少用户需求的变更；
• 运行增量投资，即在项目开始时，可以仅对一个或两个增量投资。

增量模型有如下不足之处：

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

3、演化模型（Evolutionary Model）

软件类似于其他复杂的系统，会随着时间的推移而演化。在软件开发过程中，常常会面临以下情形：

• 商业和产品需求经常发生变化，直接导致最终产品难以实现；
• 严格的交付时间使得开发团队不可能圆满的完成软件产品，但是必须交付功能有限的版本以应对竞争或商业压力；
• 很好的理解了核心产品和系统需求，但是产品或系统扩展的细节问题却没有定义。

演化模型是迭代的过程模型，使得软件开发人员能够逐级开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏准确认识的情况。典型的演化模型有原型模型和螺旋模型等。

1）原型模型（Prototype Model）

并非所有的需求都能预先定义，大量的实践表明，在开发初期很难得到一个完整的、准确的需求规格说明。这主要是由于客户往往不能准确的表达对未来系统的全面要求，开发者对要解决的应用问题模糊不清，以至于形成的需求规格说明常常是不完整的、不准确的，有时甚至是有歧义的。此外，在整个开发过程中，用户可能会产生新的要求，导致需求的变更。而瀑布模型难以适应这种需求的不确定性和变化，于是出现了快速原型（Rapid Prototype）这种新的开发方法。原型方法比较适用于用户需求不清、需求经常变化的情况。当系统规模不是很大也不太复杂时，可以采取该方法。

原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本的构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速的开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟悉的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。原型模型如下图所示。

原型模型开始于交流沟通，其目的是定义软件的总体目标，标识需求，然后快速制订原型开发计划，确定原型的目标和范围，采用快速射击的方式对其进行建模，并构建原型。

根据使用原型的目的不同，原型可以分为探索型原型、实验型原型和演化型原型3种。

• 探索型原型的目的是要弄清楚目标的要求，确定所希望的特性，并探讨多种方案的可行性。
• 实验型原型的目的验证方案或算法的合理性，是在大规模开发和实现前，用于考查方案是否合适、规格说明是否可靠等。
• 演化型原型的目的是将原型作为目标系统的一部分，通过对原型的多次改进，逐步将原型演化成最终的目标系统。

2）螺旋模型（Sprial Model）

对于复杂的大型软件，开发一个原型往往达不到要求。螺旋模型将瀑布模型和演化模型结合起来，加入了两种模型均忽略的风险分析，弥补了这两种模型的不足。

螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合，如下图所示。

每个螺旋周期又分为如下4个步骤。

1）制订计划。确定软件的目标，选定实施方案，明确项目开发的限制条件。

2） 风险分析。分析所选的方案，识别风险，消除风险。

3） 实施工程。实施软件开发，验证阶段性产品。

4） 用户评价。评价开发工作，提出修正建议，建立下一个周期的开发计划。

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，从而做出应有的反应。因此螺旋模型特别适用于庞大、复杂并且具有高风险的系统。

与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰富的风险评估经验和专门知识。

4、喷泉模型（Water Fountain Model）

喷泉模型是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。它克服了瀑布模型不支持软件重用和多项开发活动集成的局限性。喷泉模型使开发过程具有迭代性和无间隙性，如下图所示。

迭代意味着模型中的开发活动常常需要重复多次，在迭代过程中不断的完善软件系统。无间隙是指开发活动（如分析、设计、编码）之间不存在明显的边界，也就是说它不像瀑布模型那样，在需求分析活动结束后才开始设计活动，在设计活动结束后才开始编码活动，而是允许各开发活动交叉、迭代的进行。

喷泉模型的各个阶段没有明显的界线，开发人员可以同步进行。其优点是可以提高软件项目的开发效率，节省开发时间。由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大。

5、基于构件的开发模型（Component-based Development Model）

基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。

一种基于构件的开发模型如下图所示，它包括领域工程和应用系统工程两部分。

领域工程的目的是构建领域模型、领域基准体系结构和可复用构件库。为达到此目的，首先要进行领域分析，分析该领域中各种应用系统的公共部分或相似部分，构建领域模型和领域基准体系结构，表示领域的候选构件，对候选构件进行可变性分析以适应多个应用系统的需要，最后构建可复用构件，经严格测试和包装后存入可复用构件库。

应用系统工程的目的是使用可复用构件组装应用系统。首先进行应用系统分析，设计应用系统的体系结构，标识应用系统所需的构件，然后在可复用构件库中查找合适的构件（也可以购买第三方构件），这些选取的构件需进行特化，必要时做适当修改，以适应该应用系统的需要。对于那些未找到合适构件的应用部分，仍需要单独开发，并将其与特化修改后的构件组装成应用系统。在此过程中，还需要对可复用构件的复用情况进行评价，以改进可复用构件，同时对新开发的部分进行评价，并向领域工程推荐候选构件。

6、统一过程（UP）模型

统一过程模型是一种“用例和风险驱动，以架构为中心，迭代并且增量”的开发过程，由UML方法和工具支持。迭代的意思是将整个软件开发项目划分为多个小的“袖珍项目”，每个“袖珍项目”都包含正常软件项目的所有元素：计划、分析和设计、构造、集成和测试，以及内部和外部发布。

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

1）起始阶段（Inception Phase）

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

2）精化阶段（Elaboration Phase）

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

3）构建阶段（Construction Phase）

构建阶段关注系统的构建，产生实现模型，产生的主要工作产品有设计模型、软件构件、集成的软件增量、测试计划及步骤、测试用例以及支持文档（用户手册、安装手册和对于并发增量的描述）。

4）移交阶段（Transition Phase）

移交阶段关注于软件提交方面的工作，产生软件增量，产生的主要工作产品有提交的软件增量、β测试报告和综合用户反馈。

每次迭代产生包括最终系统的部分完成的版本和任何相关的项目文档的基线，通过逐步迭代基线之间相互构建，直到完成最终系统。

在每个迭代中有5个核心工作流：

• 捕获系统应该做什么的需求工作流；
• 精化和结构化需求的分析工作流；
• 在系统架构内实现需求的设计工作流；
• 构造软件的实现工作流；
• 验证实现是否如期望那样工作的测试工作流。

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

7、敏捷方法（Agile Development）

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

敏捷过程的典型方法有很多，每一种方法都基于一套原则，这些原则实现了敏捷方法所宣称的理念。

1）极限编程（XP）

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

• 4大价值观：沟通、简单性、反馈和勇气。
• 5个原则 快速反馈； 简单性假设； 逐步修改； 提倡更改； 优质工作。
• 12个最佳实践 计划游戏（快速制订计划、随着细节的不断变化而完善）； 小型发布（系统的设计要能够尽可能早的交付）； 隐喻（找到合适的比喻传达信息）； 简单设计（只处理当前的需求，使设计保持简单）； 测试先行（先写测试代码，然后在编写程序）； 重构（重新审视需求和设计，重新明确的描述它们以符合新的和现有的需求）； 结队编程； 集体代码所有制； 持续集成（可以按日甚至按小时为客户提供可运行的版本）； 每周工作40个小时； 现场客户； 编码标准。

2）敏捷统一过程（AUP）

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

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

免责声明：本文系网络转载或改编，未找到原创作者，版权归原作者所有。如涉及版权，请联系删