软件工程之过程模型

第四章：过程模型

过程模型的概念：

过程模型为软件工程工作提供了特定的路线图,该路线图规定了所有活动的流程、动作、任务、迭代的程度、工作产品及要完成的工作应如何组织。

作用：减少开发新软件产品时出现的混乱。

惯用过程模型：瀑布模型、增量过程模型、演化过程模型、并发模型

1.瀑布模型

瀑布模型( waterfall model)又称为经典生命周期(classic life cycle)，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程,最终提供完整的软件支持如下图所示：

瀑布模型的v型变体：

瀑布模型存在的问题：

目前，软件工作快速进展，经常面临永不停止的变更流，特性、功能和信息内容都会变更，瀑布模型往往并不适合这类工作。尽管如此，在需求已确定的情况下，且工作采用线性的方式完成的时候，瀑布模型是一个很有用的过程模型。

2.增量过程模型

增量模型交付一系列称为增量的版本，随着每个版本的交付，逐步为用户提供更多的功能。增量模型综合了第3章讨论的线性过程流和并行过程流的特征。如选下图所示，随着时间的推移，增量模型在每个阶段都运用线性序列。每个线性序列生产出软件的可交付增量。

3.演化过程模型

演化模型是迭代的过程模型，这种模型使得软件开发人员能够逐步开发出更完整的软件版本。接下来，将介绍两种常用的演化过程模型—原型开发和螺旋开发。

3.1原型开发：

原型开发。很多时候,客户定义了软件的一些基本任务，但是没有详细定义功能和特性需求。另一种情况下，开发人员可能对算法的效率、操作系统的适用性和人机交互的形式等情况并没有把握。在这些情况和类似情况下，采用原型开发范型(prototyping paradigm）是最好的解决办法。原型开发范型如下图所示：

快速设计产生了一个原型。对原型进行部署，然后由利益相关者进行评估。根据利益相关者的反馈信息，进一步精炼软件的需求。在原型系统不断调整以满足各种利益相关者需求的过程中，采用迭代技术．同时也使开发者逐步清楚用户的需求。

原型开发可能存在的问题

3.1.1整个软件是随意搭建的，开发者没有考虑带软件质量和长期可维护性

3.1.2软件工程师为了使程序尽快运行起来，可能会使用自己熟悉但不合适的操作系统或编程语言

尽管问题会发生，但原型开发对于软件工程来说仍是一个有效的范型。关键是要在游戏开始的时候制定规则，也就是说，所有利益相关者必须承认原型是为定义需求服务的。然后丢弃原型(至少是部分丢弃)，实际的软件系统是以质量第一为目标而开发的。

3.2 螺旋模型

螺旋模型是一种演进式软件过程模型。它结合了原型的迭代性质和瀑布模型的可控性和系统性特点。它具有快速开发越来越完善的软件版本的潜力。螺旋模型能运用在应用系统开发的整个生命周期，从概念开发到维护。典型的螺旋模型如下图：

螺旋模型是开发大型系统和软件的很实际的方法。螺旋模型将软件开发为一系列演进版本。在早期的迭代中，软件可能是一个理论模型或是原型。在后来的迭代中，会产生一系列逐渐完整的系统版本。螺旋模型把原型作为降低风险的机制，更重要的是，开发人员可以在产品演进的任何阶段使用原型方法。它保留了经典生命周期模型中系统逐步细化的方法，但是把它纳入一种迭代框架之中，这种迭代方式与真实世界更加吻合。螺旋模型要求在项目的所有阶段始终考虑技术风险，如果适当地应用该方法，就能够在风险变为难题之前将其化解。

4.并发模型

并发开发模型( concurrent development model）有时也叫作并发工程，它允许软件团队表述本章所描述的任何过程模型中的迭代元素和并发元素。例如，螺旋模型定义的建模活动由以下一种或几种软件工程动作完成:原型开发、分析和设计。

演化模型的初衷是采用迭代或者增量的方式开发高质量软件。可是，用演化模型也可以做到强调灵活性、可延展性和开发速度。软件团队及其经理所面临的挑战就是在这些严格的项目、产品参数与客户(软件质量的最终仲裁者)满意度之间找到一个合理的平衡点。

专用过程模型：基于构件开发模型、形式化方法模型

专用过程模型具有前面章节中提到的传统过程模型的一些特点，但是，专用过程模型往主应用面较窄且较专一，只适用于某些特定的软件工程方法。

5.1 基于构件开发模型

基于构件的开发模型( component-based development model)具有许多螺旋模型的特点。它本质上是演化模型[Nie92]，需要以迭代方式构建软件。不同之处在于，基于构件的开发模型采用预先打包的软件构件来开发应用系统。

则基于构件开发模型由以下步骤组成（采用演化方法）：

1. 对于该问题的应用领域研究和评估可用的基于构件的产品。
2. 考虑构件集成的问题。
3. 设计软件架构以容纳这些构件。
4. 将构件集成到架构中。
5. 进行充分的测试以保证功能正常。

基于构件的开发模型能够使软件复用，从而为软件工程师带来极大收益。如果构件复用已经成为你所在的软件工程团队文化的一部分，那么将会缩短开发周期并减少项目开发费用。基于构件的软件开发将在第13章进行详细讨论。

5.2 形式化方法模型

形式化方法模型( formal methods model)的主要活动是生成计算机软件形式化的数学规格说明。形式化方法使软件开发人员可以应用严格的数学符 来说明、开发和验证基于计算机的系统。这种方法的一个变形是净室软件工程( cleanroom software engineering)[Mil87,Dye92]，这一软件工程方法目前已应用于一些软件开发机构。

形式化方法模型存在的问题：

1. 目前,形式化模型开发非常耗时,成本也很高。
2. 只有极少数程序员具有应用形式化方法的背景，因此需要大量的培训。
3. 对于技术水平不高的客户，很难用这种模型进行沟通。

统一过程

UML——统一建模语言( unified modeling language)，这种语言包含了大量用于面向对象系统建模和开发的符 。

统一过程认识到与客户沟通以及从用户的角度描述系统（即用例）并保持该描述的一致性的重要性。它强调软件体系结构的重要作用，并“帮助架构师专注于正确的目标，例如可理解性、对未来可变更的可适应性以及复用”。它建立了迭代的、增量的过程流，提供了演进的特性，这对现代软件开发非常重要。

统一过程的阶段：

1. UP的起始阶段（inception phase）：包括客户沟通和策划活动。通过与利益相关者协作定义软件的业务需求，提出系统大致的架构,并制定开发计划以保证项目开发具有迭代和增量的特性。
2. 细化阶段（Elaboration Phase)：包括沟通和通用过程模型的建模活动。(图4-7)。细化阶段扩展了初始阶段定义的用例，并扩展了体系结构以包括软件的五种视图——用例模型、需求模型、设计模型、实现模型和部署模型。
3. UP的构建阶段( construction phase)：与通用软件过程中的构建活动相同。构建阶段采用体系结构模型作为输入，开发或是获取软件构件，使得最终用户能够操作用例。
4. UP的转换阶段( transition phase)：包括通用构建活动的后期阶段以及通用部署(交付和反馈）活动的第一部分。
5. UP的生产阶段（ production phase)：与通用过程的部署活动一致。在该阶段，对持续使用的软件进行监控，提供运行环境（基础设施)的支持，提交并评估缺陷 告和变更请求。

这五个阶段的关系如下图所示

有可能在构建、转换和生产阶段的同时，下一个软件增量的工作已经开始。这就意味着五个UP阶段并不是顺序进行,而是阶段性地并发进行。

产品和过程

如果过程很薄弱，则最终产品必将受到影响。但是对分过程的过分依赖也是很危险的。