《软件工程理论与实践》-第二章

第2章软件过程

【目标】本章的目标是系统介绍软件过程思想。读完本章，读者将了解以下内容。什么是软件过程，软件过程模型;软件过程与软件工程方法学;几种基本软件过程模型及其演化过程;支持软件过程的CASE技术。下一页返回第2章软件过程

软件工程的目标是以较经济的手段获取高质量的软件，然而这一目标终归要靠一系列活动来实现。如何组织这些活动，从事活动的开发者应该遵循身什么样的规范、流程，有哪些工具可以支持他们完成活动中的具体任务?所有这些问题，都推动着软件工程过程的发展与广泛应用。上一页返回2.1软件过程概述

软件过程也称为软件生存周期过程，是指软件工程人员为了获得软件产品而实施的一系列软件活动。这些活动可以是顺序的、迭代的、并行的、嵌套的，或者是依据条件而发生的。随着客户对系统的要求越来越复杂，建立这些系统的软件过程也越来越复杂，这种复杂性也与工程师的判断力有关。正是由于需要判断力和创造力，软件过程无法实现完全自动化。CASE工具可以帮助支持一些过程活动，但无法完全取代人类在软件过程中的富含创造性的活动。此外，不同的人、不同的机构、不同的软件系统有不同的适合的软件过程，因此软件过程具有很大的差异性。这种差异性是软件过程无法实现自动化的另一个原因。虽然存在许多不同的软件过程，但构成软件过程的基本活动还是相同的。这些基本活动包括以下几个方面。下一页返回2.1软件过程概述

(1)软件规格描述，即通俗的需求分析，用来刻画软件的功能、性能需求及运行环境约束。(2)软件开发，包括软件设计与实现，即按照软件规格描述的要求实现一个系统。(3)软件的验证，即测试环节，用来检验开发的软件是否与规格描述相一致。(4)软件的进化，即维护，软件按一定的要求变更。软件过程本身一直在演化，这种演化源于工程师们用经验知识来改进软件工程开发的过程流程，在可以预见的未来，这种演化将会持续下去。软件的过程模型是软件过程的一个抽象表示法，也是对这种演化的阶段性总结或刻画。上一页返回2.2软件过程模型

软件过程模型是软件开发的指导思想和全局性框架，软件过程模型的提出和发展反映了人们对软件过程的某种认识观，体现了人们对软件过程认识的提高和飞跃。下面介绍一些一般性的软件过程模型，每个过程模型都从某个特定角度表现一个过程，提供过程的一些信息。需要指出的是，这些过程模型不是某种必须遵循的标准，它只是一种有用的对过程的抽象，在实际的大型项目开发中，需要作必要的裁剪或组合。下一页返回2.2软件过程模型

2.2.1瀑布模型

瀑布模型又称为软件生命周期模型，是最早提出的模型。如图2.1所示，它以软件生命周期的每一个阶段作为一个活动，依序逐渐完成这些活动。

采用瀑布模型开发软件时，前一个阶段任务的完成是后一个阶段任务开始的基础和前提，后一阶段是前一阶段工作的进一步具体化。每一个阶段的开始和结束都有严格标准。按照该方法，各阶段的工作自顶向下从抽象到具体顺序进行，就像奔流不息的瀑布，因而称为瀑布模型。瀑布模型的优点如下。

(1)历史较长、应用面广泛、为广大软件工作者所熟悉，并且已有与之配套的一组十分成熟的开发方法和丰富的支撑工具。上一页下一页返回2.2软件过程模型

(2)结构简单明了，反映了工程的实际情况。每个阶段必须完成规定的文档，每个阶段结束前完成文档审查，能及早改正错误。

(3)阶段具有顺序性和依赖性，确定了需求分析的绝对重要性，强调推迟实现的观点。瀑布模型把软件过程看成严格线性化的过程，适用于需求能在早期阶段被完全确定、后期变化很小的情况。然而，瀑布模型的这种假设太过理想化，实际中需求很难在开发初期就明确给定，并且软件开发流程之间存在大量的交叉和迭代。采用瀑布模型开发软件时，暴露出的主要问题包括以下几个方面。

(1)对用户需求变更的响应较困难，尤其当这种需求是在开发的后期提出时。上一页下一页返回2.2软件过程模型

(2)早期引入的错误可能在开发后期才发现，这时修改的代价很大，甚至可能导致项目最终失败。

采用极端的瀑布型开发方法意味着要以严格的顺序来完成一系列的项目阶段:需求分析、设计、实现和测试。实际上，多数的开发团队使用改进了的瀑布型开发方法，他们将项目分解成为两个或者更多的部分，这些部分被称为阶段或者时期。这种改良可以帮助简化集成、使测试人员更早地进行测试工作和提供更早的项目状态的观测。这种方法也将代码分解成了易于管理的片断并最小化了以存根和驱动程序形式的、被测试需要的代码集成。此外，这种方法允许使用来自每一个阶段的反馈修改设计。然而，使用瀑布型开发方法的执行与想象是相反的:很多设计团队把在第一阶段之后的对设计的修改视为最初设计或者需求过程的失败。虽然一个改进了的瀑布型开发方法并不排除反馈的使用，但是它并没有促进、支持和鼓励反馈的使用。上一页下一页返回2.2软件过程模型

2.2.2原型模型

软件过程模型一直在演变中，原型过程模型是在瀑布模型基础上引入局部迭代而得到的。原型模型先快速构建一个可运行的软件原型，由客户或未来的用户试用该原型，并在原型的帮助下确定需求。如图2.2所示，这一交互过程一直进行，直到开发人员可以将客户的真实需求完全确定为止。最后，在确定的需求基础上开发软件产品。原型法的优点如下。

(1)原型法强化沟通，可以改进需求质量，降低风险，提高项目成功率。

(2)原型虽然投入了较多先期的时间，但可以显著减少后期变更的时间。上一页下一页返回2.2软件过程模型

(3)原型投入的人力成本代价并不大，还可以节省后期成本。

(4)原型通过充分和客户交流，还可以提高客户满意度。依据对待原型的方式，原型法又分为:抛弃式，即原型只用来获取需求，在取得的明确需求基础上重新开始设计与开发;演化式(探索式)，即最后的系统是在原型基础上继续开发完成的。无沦抛弃式还是探索式，原型主要用来解决系统描述中不确定的、模糊的部分。对于很小规模的系统或者中型系统，原型法可以快速构建系统原型，明确系统需求，进而克服瀑布模型的缺点。但是，对于大型的、生命周期很长的系统，快速构建系统原型不太可能，这时使用原型法存在诸多问题。具体包括以下几个方面。上一页下一页返回2.2软件过程模型

(1)原型法强调快速开发，系统开发过程变得不可见。但对于强调工程控制和管理的大型系统来说，这一点显然无法承受。

(2)软件原型是通过不断修改而形成的，因此系统的结构通常较差，这很容易导致大型项目在集成时失败。

(3)需要采用支持快速构造的开发技术和工具，但这些技术和工具未必与主流技术和工具相容，而且掌握这些特别工具和技术的人较少。软件生命周期法中并不包括原型，或者说没有明确提供原型的概念和定义。可以认为原型是需求分析中的一个子部分。另外，应该说原型方法是对生命周期法的有益补充和完善。图2.3所示为原型(抛弃式)用在软件工程过程中的图示。上一页下一页返回2.2软件过程模型

2.2.3增量模型

单纯的瀑布模型和原型模型都有优缺点，对于绝大多数大型项目来说，需要对不同的部分采用不同的方法。这就需要研究混合式过程，使其既包括瀑布模型的优点又涵盖原型模型的优点。增量模型就是在这样的思想背景下提出的混合式模型。如图2.4所示，增量模型把软件视为一个可添加的系统，像堆积木一样每次通过分析、设计、编码、测试交付一个模块或子系统，逐步完成。当然，首先交付的应当是对系统有决定作用的基础模块，如系统菜单，其次是业务中心子系统。当用户对先交付的模块验收满意后再开发后继模块。上一页下一页返回2.2软件过程模型

增量模型融合了线性顺序模型的基本成分(重复地应用)和原型的迭代特征。增量模型采用随着口程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。当使用增量模型时，第一个增量往往是核心产品，即实现了基本的需求，但很多补充的特性(其中一些是已知的，另外一些是未知的)还没有发布。核心产品交用户使用(或进行更详细的复审)，使用和//或评估的结果是下一个增量的开发计划。该计划包括对核心产品的修改，使其能更好地满足用户的需要，并发布一些新增的特点和功能。这个过程在每一个增量发布后不断重复，直到产生最终的完善产品。采用增量模型的优点如下。

(1)人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。上一页下一页返回2.2软件过程模型

(2)当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。这样即可先发布关键功能给客户，对客户起到镇静剂的作用。

(3)客户可以将早期的增量作为原型，从中获得对后面增量的需求经验。

(4)项目总体失败风险小，即使出现问题，总有一些增量可以交付客户。

(5)关键的服务最早被开发，而后面的增量是不断被集成进来的，这就使得最重要的增量会接受最多的测试。增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个增量，开发人员逐个增量地交付产品，这样做也存在许多问题。上一页下一页返回2.2软件过程模型

(1)由于各个增量是逐渐并人已有的软件体系结构中的，所以加人新增量必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。

(2)在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力远远优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。增量过程模型，像原型和其他演化方法一样，具有迭代的特征。但与原型不一样，增量模型强调每一个增量均发布一个可操作产品。早期的增量是最终产品的“可拆卸”版本，但它们确实提供了给用户服务的功能，并且提供了给用户评估的平台。上一页下一页返回2.2软件过程模型

增量式方法的一个进化是极限编程，它通过不断开发和交付非常小的功能增量来实现系统。极限编程强调持续反馈和尽早发现问题，适用于在开发软件过程中面对模糊或者快速多变的需求。Bcck的文章介绍了使用这种方法的一些成功项目，但这种方法还处于发展过程中。上一页下一页返回2.2软件过程模型

2.2.4螺旋模型

1988年，BarryBochm正式发表了软件系统开发的螺旋模型，它同样是一种混合模型，也是将瀑布模型和快速原型模型结合起来，不同之处在于它强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。如图2.5所示，螺旋模型将软件过程划分为若干个螺旋线。螺旋线的每个回路表示软件过程的一个阶段。因此，最里面的回路可能与可行性有关，接下来的回路与系统需求有关，再下一个回路与系统设计有关，等等。螺旋线的每个回路又被分成4个部分，图中的4个象限代表了这4个部分。上一页下一页返回2.2软件过程模型

(1)制订计划:为项目的这个阶段定义目标，规划可选的实施方案，弄清项目开发的限制条件。

(2)风险分析:分析评估所选方案，考虑如何识别和消除风险。

(3)实施工程:实施软件开发和验证。

(4)客户评估:评价开发工作，提出修正建议，制订下一步计划。螺旋模型采用一种周期性的方法来进行系统开发。这会导致开发出众多的中间版本。早期的版本可以作为原型供客户使用，或为客户证实某些概念。采用螺旋模型的过程整体上类似于快速原型法，以进化的开发方式为中心，在每个项目阶段使用瀑布模型法。瀑布模型的每一个周期都包括前述4个阶段，由这4个阶段进行迭代。软件开发过程每迭代一次，软件开发又前进一个层次。采用螺旋模型的软件过程如图2.6所示。上一页下一页返回2.2软件过程模型

螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而作出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量。减小软件风险的目标是在造成危害之前，及时对风险进行识别及分析，决定采取何种对策，进而消除或减少风险的损害。螺旋模型由风险驱动、强调可选方案和约束条件，从而有助于将软件质量作为特殊目标融人产品开发之中。但是，采用螺旋模型开发软件也存在一些问题和限制条件，具体如下。

(1)螺旋模型强调风险分析，但要求许多客户接受和相信这种分析，并作出相关反应是不容易的，因此，这种模型往往适应于内部的大规模软件开发。上一页下一页返回2.2软件过程模型

(2)如果执行风险分析将极大地影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。(3)采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。

(4)过多的迭代次数会增加开发成本，延迟提交时间。螺旋模型和增量模型都是以某个原型或初始子集为基础，通过不断的演化得到满足用户需求的软件产品，两者之间的区别如下。

(1)螺旋模型是事先定义大部分需求，开发过程中计划性比较强。而增量模型是事先定义少部分需求，灵活的迭代开发和经常的客户反馈，减少了项目风险。

(2)螺旋模型在过程级迭代，增量模型在活动级迭代。

(3)螺旋模型每次迭代都提交一个完整的软件版本，而增量模型每次增量开发是在上次增量的基础上提交新的一部分软件。上一页下一页返回2.2软件过程模型

2.2.5形式化系统开发

形式化方法建立在严格的数学基础上，其开发过程基于的是用形式化数学转换来将系统描述转换为一个可执行的程序。因此，用形式化开发方法开发的系统具有较高的可信度和正确性，它适用于开发对安全性、可靠性等要求极高的系统。如图2.7所示，形式化方法类似于瀑布模型的方法。但两者有着本质的区别:形式化开发方法中将需求用数学符号进行形式化描述;瀑布模型中的设计、实现和单元测试等开发过程被形式化转换过程代替。在形式化变换过程中，系统形式化的数学表达被转换成更详细但仍然正确的数学表达。每转换一次增加一些细节，直至形式化描述最终被转换成一个可执行的程序。上一页下一页返回2.2软件过程模型

由于转换过程的正确性得到数学上的保证，因此转换的结果程序具有较少的缺陷和较高的安全性。尽管如此，除了一些特殊的系统，形式化方法的应用并不多。原因主要在于以下几个方面。

(1形式化方法的掌握需要经过特殊的Jil练。

(2)形式化描述和转换的人力、物力费用很大，采用这种方法开发软件在成本和质量上并不占优势。

(3)形式化方法很难描述系统交互，而系统交互是大多现实系统的重要部分。上一页下一页返回2.2软件过程模型

2.2.6基于组件的开发模型

软件复用被认为是提高软件开发效率和质量的最有效途径。最近几年，一个面向复用的软件开发方法(基于组件的开发方法)出现了，并且正在逐渐地被广泛使用。基于组件的开发方法依赖于可获取的可复用组件及能集成这些组件的框架。基于组件的软件开发过程模型如图2.8所示。

基于组件开发方法的需求分析和系统验证与其他过程类似，不同之处在于中间的几个阶段。在需求确定后，开发人员会搜寻可供使用的组件，并分析得到的组件。通常没有刚好满足要求的组件，在分析组件信息基础上，开发人员可能调整需求以适应组件或者修改现有组件以适应需求。所选的组件可能是从市场上采购或从旧组件中提炼出来上一页下一页返回2.2软件过程模型

的，也可能是新开发的。选完组件后，开发人员要依据所选组件设计系统架构或者复用已有的架构。最后，将所有组件集成起来并完成测试工作。基于组件的开发方法可以减少待开发软件数量，减低软件成本，提高软件质量，相对其他过程具有明显的优势。然而，该方法的使用也受到一些因素的制约。为适应组件，需求的修改通常是不可避免的，而这种修改有可能导致系统不符合用户的需要。此外，系统的进化无法控制，因为可复用组件的新版本不一定是由开发机构控制的。上一页返回2.3计算机辅助软件工程

计算机辅助软件工程(CASE)是帮助进行应用程序开发的软件，包括:需求分析、设计，程序开发和测试。CASE是一组工具和方法的集合，用来促进软件过程的自动化，提高软件开发的效率和软件的质量。

CASE工具由许多部分组成，一般按软件开发的不同阶段分为上游C