软件工程过程模型课件

第2章软件工程过程模型2.1软件工程的技术基础2.2软件工程过程2.3软件过程模型2.4线性顺序模型2.5原型模型2.6快速应用开发模型2.7演化软件过程模型2.8软件过程技术2.9软件重用技术2.10小结第2章软件工程过程模型2.1软件工程的技术基础12.1软件工程的技术基础图2.1软件工程过程层次图2.1软件工程的技术基础图2.1软件工程过程层次图2正如其他工程方法一样，软件工程必须以有组织的软件质量保证为基础。因此说，对质量的关注构成了软件工程的根基。软件工程过程是将技术层(包括工程技术与管理技术)结合在一起的凝聚力。过程层是软件工程的基层。软件工程过程定义了一组关键过程域(KPAs)，这对于软件工程技术的有效应用是必需的。这些关键过程区域是对软件工程项目进行管理与控制的基础，并且确定了上、下各区域之间的关系。其中，对于技术方法的采用、阶段产品的产生、工程里程碑的建立、质量监控与保证、变更控制等方面都进行了规定。除各个开发组织可以定义自己的软件工程过程之外，目前流行比较广泛的软件工程过程包括有RUP过程、极限(XP)过程、敏捷软件过程(AgileS.P)等等。正如其他工程方法一样，软件工程必须以有组织的软件质量3软件工程方法涵盖了需求分析、设计、编程、测试、维护等各个环节，它给出了完成这些任务在技术上应当“如何做”的方法。它依赖于一组基本原则，这些原则控制了每一个技术区域，涉及到建模活动和其他描述技术。工具层对过程和方法提供支持，使得工程活动、管理活动得以自动、半自动的进行。例如，目前广为使用的数据库建模工具Erwin、面向对象的建模工具RationnalRose、配置管理工具等等。如果把一系列的工具集成起来使用，使得一个工具产生的信息可以被另一个工具使用时，就形成了一个支持软件开发的系统。这种集成了软件、硬件和一个软件工程数据库的软件工程环境，称为计算机辅助软件工程(CASE)。软件工程方法涵盖了需求分析、设计、编程、测试、维护等42.2软件工程过程如前所述，软件工程过程是开发或维护软件及其相关产品的一系列活动。软件工程过程是过去十年中人们关注的焦点。软件工程和软件工程过程之间是强相关的。软件工程过程通常包括四种基本的过程活动：(1)软件规格说明：规定软件的功能、性能及其运行限制。(2)软件开发：产生满足规格说明的软件，包括设计与编码等工作。(3)软件确认：确认软件能够满足客户提出的要求，对应于软件测试。(4)软件演进：为满足客户的变更要求，软件必须在使用的过程中演进，以求尽量延长软件的生命周期。2.2软件工程过程如前所述，软件工程过程是开发或5在一个良好的软件过程中，还应当包括一些“保护性”的活动，包括软件项目的跟踪监控、正式的技术审核、软件配置管理活动、软件质量保证活动、文档的准备和产生、软件测试、风险管理等等。这些保护性活动贯穿于整个工程过程之中。在具体的工程过程中，可以根据实际需要，采用不同的过程模型来实现上述的基本活动和保护活动。事实上，软件工程过程是一个软件开发组织针对某一类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响到软件产品的质量。一个良好的软件工程过程应当具备如下特点：在一个良好的软件过程中，还应当包括一些“保护性”的活6(1)易理解性。(2)可见性：每个过程活动都以得到明确的结果而告终，保证过程的进展对外可见。(3)可支持性：容易得到CASE工具的支持。(4)可接受性：比较容易被软件工程师接受和使用。(5)可靠性：不会出现过程错误，或者出现的过程错误能够在产品出错之前被发现。(6)健壮性：不受意外发生问题的干扰。(7)可维护性：过程可以根据开发组织的需求的改变而改进。(8)高效率：从给出软件规格说明起，就能够较快地完成开发而交付使用。(1)易理解性。7一个软件过程可以表示成如图2.2所示的形式。其中，公共过程框架是通过定义若干适合于所有软件项目的框架活动而建立的；若干任务集合中，每一个集合都由软件工程工作任务、软件项目里程碑、软件工作产品和交付物以及质量保证点组成；保护性活动独立于任何一个框架，贯穿于整个过程。一个软件过程可以表示成如图2.2所示的形式。其中，公8图2.2软件工程过程图2.2软件工程过程92.3软件过程模型在一个具体的实际工程活动中，软件工程师必须设计、提炼出一个工程开发策略，用以覆盖软件过程中的基本阶段，确定所涉及的过程、方法、工具。这种策略常被称为“软件工程过程模型”。这一模型的选择应当是根据组织定义的标准软件过程，参考具体工程项目的特点和资源状况进行裁剪来进行的。2.3软件过程模型在一个具体的实际工程活动中，软10从宏观上来看，所有的软件开发过程都可以看成是一个循环解决问题的过程。其中包括四个截然不同的阶段：状态描述、问题定义、技术开发和方案综述，如图2.3所示。状态描述表示了事物的当前状态；问题定义标识了要解决的特定问题；技术开发通过应用某些技术来解决问题；方案综述提交解决结果(如文档、程序、数据、新的商业功能、新产品)给那些从一开始就需要方案的人。前面定义的软件工程的一般阶段和步骤很容易映射到这些阶段上。

从宏观上来看，所有的软件开发过程都可以看成是一个循环11图2.3问题循环解决的各个阶段图2.3问题循环解决的各个阶段12上述的问题循环解决过程可以应用于软件工程的多个不同开发级别(阶段)上，包括考虑整个系统开发的宏观阶段，开发程序构件的中间阶段，甚至是代码编制阶段，因此可以采用分级集合表示。可以定义一个模式，然后在连续的、更小的规模上递归地应用它，这样来提供一个关于过程的理想化的视图。问题循环解决过程的每一个阶段又包含一个相同的问题循环解决过程，如图2.4所示。可以认为，软件开发是从用户到开发者再到技术的一个连续的过程。随着向一个完整系统的逐步进展，上述的阶段递归地应用于用户的需求和开发者的软件技术说明中。

上述的问题循环解决过程可以应用于软件工程的多个不同开13图2.4问题循环解决阶段中的阶段图2.4问题循环解决阶段中的阶段14要想像图2.3那样清楚地划分阶段活动是很困难的，因为阶段内部和阶段之间的活动往往是交叉的。但是对于任何一个软件项目而言，不管选择了什么样的具体的软件工程过程模型，所有四个活动阶段在某个细节的级别上都是同时存在的。图2.4描述了实际过程的递归性质。在后面的讨论中，我们将会看到，每一种具体的软件工程过程模型实际上都代表了一种将本质上无序的活动有序化的企图。每一种模型都具有能够帮助实际软件项目的控制及协调的特征，但在它们的核心中，这些模型又表现了无序模型的特点。要想像图2.3那样清楚地划分阶段活动是很困难的，因为15在软件工程实践中，有许多专家治力于过程模型的研究。像瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、形式化方法模型、RUP模型、敏捷过程模型、构件组装模型、并发开发模型等等都先后得到了有效的应用。目前，关于软件工程过程模型的研究仍然在积极地进行之中，将不断取得新的进展与成就。在软件工程实践中，有许多专家治力于过程模型的研究。像162.4线性顺序模型图2.5线性顺序模型2.4线性顺序模型图2.5线性顺序模型17线性顺序模型有时也称为“瀑布模型”。它表示了软件开发系统的、顺序的方法。虽然瀑布模型支持带反馈的循环，但大多数使用者均把它视为是严格线性的。从系统级开始，随后是分析、设计、编码、测试和维护。借鉴传统的工程周期，线性顺序模型的活动如图2.5所示。

线性顺序模型有时也称为“瀑布模型”。它表示了软件开18线性顺序模型是最早，也曾经是应用最广泛的软件工程过程模型，但是这种模型不适应需求经常发生变更的环境。实际的项目很少能够严格地按照该模型给出的顺序进行。需求的变更、设计的变更、编码的变更几乎是不可避免的。虽然线性顺序模型能够允许迭代，但却是间接的迭代。在项目的开发过程中，变更可能会引起混乱。所以，有人形象地把采用线性模型进行商业软件工程称之为“在沙滩上盖楼房”。考虑到用户对于需求的理解有一个渐进渐深的过程，一开始用户往往难以明确地提出所有的需求，这样，线性顺序模型的第一步输入就得不到满足。线性顺序模型是最早，也曾经是应用最广泛的软件工程过程19同时，线性顺序模型也经常不能接受项目开始阶段自然存在的不确定性。在采用线性顺序模型的时候，用户只有到项目的开发晚期才能够得到程序的可运行版本。大的错误如果到这时才被发现，那么造成的后果往往是灾难性的。同时，因为线性顺序模型每一步的工作都必须以前一阶段的输出为输入，这种特征会导致工作中发生“阻塞”状态。某些项目组成员不得不等待组内其他成员先完成前驱任务才可能展开自己的工作。有时这种等待时间可能会超过实际花在工作上的时间。这种阻塞状态在线性顺序过程的开始和结束时经常会发生。同时，线性顺序模型也经常不能接受项目开始阶段自然存在20虽然存在着上述的种种问题，但是线性顺序模型仍然有其值得肯定之处。它提供了一个模板，使得分析、设计、编码、测试与维护工作可以在该模板的指导下有序地展开，避免了软件开发、维护过程中的随意状态。采用这种模型，曾经成功地进行过许多大型软件工程的开发。直至目前，对于需求确定、变更相对较少的项目，线性顺序模型仍然是一种可以考虑采取的过程模型。但在“用户驱动”的商业软件开发中，采用线性顺序模型并不是一个好的选择。虽然存在着上述的种种问题，但是线性顺序模型仍然有其值212.5原型模型大型建筑在施工之前，常常按照图纸制造一个缩小的模型来验证工程完成后可能的效果；新的工业设计在充分证明其正确性之前，也往往利用在缩小规模的前提下制造少量成品进行检验的方法来验证设计正确与否。同样的，如果在开发一项软件工程的时候，用户不能准确、全面地描述其需求，或者开发者还不能确定所选用算法的有效性或人机交互界面的形式时，同样也可以建立一个简化了的样品程序并使之运行，引导用户通过对样品运行情况的观察，进一步明确需求或验证算法的正确性。这种开发模式就称之为“原型模型”，如图2.6所示。2.5原型模型大型建筑在施工之前，常常按照22图2.6原型模型图2.6原型模型23原型模型从需求收集开始，开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后进行快速设计并进行编码实现，进行原型的建造。这种快速设计和建造通常集中在那些对用户可见的部分(如输入方式、输出界面)。原型建造好之后，运行原型程序，由用户和开发者进行评估、验证。接着进一步精化待开发软件的需求，逐步调整原型以使其逐渐满足用户的真正需求，同时也使开发者对将要完成的开发任务有更深入的理解。这一过程是多次迭代进行的。原型模型从需求收集开始，开发者和用户在一起定义软件的24使用原型模型必须有两个前提。其一是用户必须积极参与原型的建造，同时开发者和用户必须有共识：建造原型仅仅是为了定义需求，之后就必须被全部抛弃(至少是部分抛弃)，实际的软件必须在充分考虑到软件质量和可维护性之后才被开发。从这个意义上说，原型模型又往往被称为“抛弃原型模型”。其二是必须有快速开发工具可供使用。使用原型模型必须有两个前提。其一是用户必须积极参与原252.6快速应用开发模型快速应用开发(RAD)模型是线性顺序模型的一个“高速”变种，强调极端的开发周期。RAD模型通过使用基于构件的建造方法达到快速开发的效果。在需求得到很好理解、项目的范围约束明晰的前提下(通常不容易保证这样的条件)，采用RAD过程能够使项目组在很短的时间内(如60～90)天创建出功能完善的系统。RAD过程主要用于信息应用软件的开发，如图2.7所示，它包含如下几个开发阶段：2.6快速应用开发模型快速应用开发(RAD)模型是26图2.7RAD模型图2.7RAD模型27业务建模：业务活动中的信息流被模型化。此阶段说明什么信息驱动业务流程、生成什么信息、谁负责生成该信息、该信息流向何处、谁处理它等。数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需的数据对象。此阶段标识出每个数据对象的特征属性，定义这些对象之间的关系。处理建模：数据建模阶段定义的数据对象变换成为要完成一项业务功能所需的信息流。此阶段创建处理描述以便增加、修改、删除或获取某个数据对象。业务建模：业务活动中的信息流被模型化。此阶段说明什么28应用生成：RAD过程不是采用传统的第三代程序设计语言来创建软件，而主要是复用已有的程序构件或是创建可复用的构件。在所有情况下，均使用自动化工具辅助软件建造。测试及反复：RAD过程强调复用，许多构件是已经测试过的，减少了测试工作量。但是所有的新创建构件、所有的接口都必须测试到。采用RAD模型时，系统的每一个主要功能部件可以由一个单独的RAD工作组完成，最后再将所有的部件集成起来形成完整的软件。应用生成：RAD过程不是采用传统的第三代程序设计语言29RAD模型强调可复用程序构件的开发，支持多小组并行工作以缩短整体工期。但是如果一个系统难以被适当地模块化，构件的复用和建造就会出现问题。作为线性顺序模型的一个变种，它具有线性顺序模型所具有的种种特性。同时，RAD模型依赖于构件复用，它不适用于技术风险很高的、要采用很多新技术的项目。对于具有高性能需求的软件，如果这种高性能必须通过对接口的反复调整才能实现，那么采用RAD模型也就有可能失败。RAD模型强调可复用程序构件的开发，支持多小组并行工302.7演化软件过程模型软件就象其他复杂系统一样，需要经过一段时间的演化改进，才能够最终满足用户需求。业务和产品需求随着开发的进展常常发生变更，因而难以一步到位地完成最终的软件产品，但是，紧迫的市场期限又不允许软件工程师过多地延长开发周期。为了应对市场竞争或商业目标的压力，构造了“演化软件模型”。它的基本思想是“分期完成、分步提交”。可以先提交一个有限功能的版本，再逐步地使其完善。2.7演化软件过程模型软件就象其他复杂系统一样，需31演化模型的主要特点是利用“迭代”方法，使工程师们渐进地开发，生产出逐步完善的软件版本。在商业软件开发实践中，演化模型日益得到广泛的应用。用户的支持、理解和全程参与是成功采用演化模型的重要前提。演化模型兼有线性顺序模型和原型模型的一些特点。但线性顺序模型本质上是假设当线性开发序列完成之后就能够交付一个完整的系统；原型模型的目的是引导用户明确需求、帮助工程师验证算法，总体上讲它并不交付一个最终的产品系统。它们都没有考虑到软件的“演化”过程。根据开发策略的不同，演化模型又可以细分为“增量”模型和“螺旋”模型两种。演化模型的主要特点是利用“迭代”方法，使工程师们渐进322.7.1增量模型增量模型融合了线性顺序模型的基本成分(重复的应用这些成分)和原型模型的迭代特征，如图2.8所示。增量模型实际上是一个随着日程/时间的进展而交错的线性序列集合。每一个线性序列产生一个软件的可发布的“增量”，所有的增量都能够结合到原型模型中去。2.7.1增量模型33图2.8增量模型图2.8增量模型34当使用增量模型时，第一个增量模型往往是核心部分的产品，它实现了软件的基本需求，但很多已经明晰或者尚不明晰的补充特性还没有发布。核心产品交由用户使用或进行详细复审。使用或复审评估的结果是制定下一个增量开发计划。该计划包括对核心产品的修改及增加一些新的功能与特性。这个过程在每一个增量发布后迭代地进行，直到产生最终的完善产品。和原型模型不一样的是，增量模型虽然也具有“迭代”特征，但是每一个增量都发布一个可操作的产品，不妨称之为“产品扩充迭代”。它的早期产品是最终产品的可拆卸版本，每一个版本都能够提供给用户实际使用。当使用增量模型时，第一个增量模型往往是核心部分的产品35在实际开发过程中，增量模型是十分有用的一种模型。对于防范技术风险、缩短产品提交时间都能够起到良好的作用。应当再次强调的是，用户在开发软件的过程中，往往有“一步到位”的思想，因而增量式的工程开发必须取得用户的全面理解与支持，否则是难以成功的。在实际开发过程中，增量模型是十分有用的一种模型。对于362.7.2螺旋模型螺旋模型也是属于演化软件过程模型。它将原型的迭代特征与线性顺序模型中控制的和系统化的方面结合起来，使得能够快速开发软件的增量版本。在螺旋模型中，软件开发是一系列的增量发布。和增量模型不同，它并不要求每一个增量都是可以运行的程序。在早期的迭代中，发布的增量可以是一个纸上的模型或原型；在以后的迭代中产生更加完善的版本。螺旋模型被划分为若干个框架活动，如图2.9所示。活动也称为任务区域，一般包括：2.7.2螺旋模型37(1)用户通信：建立开发者和用户之间有效通信所需要的任务。(2)计划：定义资源、进度和其他项目相关信息所需要的任务。(3)风险分析：评估技术的及管理的风险所需要的任务。(4)工程：建立应用的一个或多个表示所需要的任务。(5)建造及发布：建造、测试、安装和提供用户支持所需要的任务。(6)用户评估：基于在工程阶段产生的或在安装阶段实现的软件表示的评估，是获得用户反馈所必需的任务。(1)用户通信：建立开发者和用户之间有效通信所需要38图2.9一个典型的螺旋模型图2.9一个典型的螺旋模型39每一个框架活动(任务区域)均含有一系列的适应待开发项目特点的工作任务(活动)。在所有的情况下，都需要应用诸如软件配置管理、软件品质保证等保护性活动。随着演化过程的开始，软件工程项目组按照顺时针方向沿螺旋移动。从核心开始，第一圈可能产生软件规格说明书，第二圈可能开发出一个原型，随后可能是软件更完善的版本。经过计划区域的每一圈都会对计划进行调整，基于从用户处得到的反馈，调整进度和费用以及版本的内容。项目管理者可以根据项目的具体情况调整所需要的迭代次数。

每一个框架活动(任务区域)均含有一系列的适应待开发项40和传统的过程模型不同，螺旋模型能够适应于计算机软件产品的整个生命周期，而不是当软件交付后就结束过程。对于大型系统及软件的开发工作来说，螺旋模型是一种很好的模型方法。采用这种模型，随着过程的发展演化，开发者和用户能够更好地理解和对待每一个演化级别上的风险。它使开发者在产品演化的任何阶段上都能够使用原型方法，保持了传统生命周期模型中的阶段化的工作方式，但同时又引入了迭代的框架，更加真实地反映了现实世界。同时也有利于防范技术风险。螺旋模型的应用同样有赖于用户的充分理解和积极参与。同时，它需要使用专门的风险评估技术以便识别风险、防范风险。和传统的过程模型不同，螺旋模型能够适应于计算机软件产412.8软件过程技术前面讨论的过程模型必须适合于软件项目组的使用。为满足这一要求，先后开发出了许多过程管理工具以帮助软件组织分析他们当前的过程，协调组织工作任务，控制和监管进度以及管理技术质量。例如，利用配置管理工具来进行配置管理和缺陷管理；利用自动测试工具进行测试；利用统一建模语言UML来进行对象建模、分析与设计；利用Project制订和监测项目计划及其进展；利用第四代技术，通过开发者在较高的层次上说明软件的某些特征，之后工具就能够自动的根据说明生成源代码等等。计算机辅助软件工程已经在软件领域中发挥着重要的作用。2.8软件过程技术前面讨论的过程模型必须适合于软件42采用合适的过程技术工具，使得软件开发组织能够建造一个自动模型，该模型包括通用的过程框架、任务集合及保护性活动。该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流程，考察可能导致降低开发时间和成本的可供选择的过程结构。一旦创建了一个可接受的过程，就可以使用其他过程工具来分配、监管，甚至控制过程模型中所定义的所有软件工程任务。软件项目组的每一个成员均能够使用这些工具产生一个清单，包括：要完成的任务、要开发的工作产品以及要实现的质量控制活动等等。采用合适的过程技术工具，使得软件开发组织能够建造一个432.9软件重用技术“重用”是提升软件财富价值的有效途径。一般来说，这里所指的重用可以包括知识重用、方法重用、软件成分重用三个层次。例如，软件工程知识的重用使我们能够高效率的开发、维护一个又一个的软件项目；行之有效的软件工程方法的重用帮助我们有章可循的解决各类工程问题；软件成分的重用则使我们在需求分析、系统设计和编码事项的过程中能够事半功倍2.9软件重用技术“重用”是提升软件财富价值的有效44对于软件工程师来说，软件成分的重用是我们最为关注的问题。介绍RAD模型时，我们已经了解了构件重用的重要作用。没有构件重用，RAD模型就只能是纸上谈兵。再具体一点地说，软件成分重用又可以分为分析结果重用、设计结果重用和代码重用三个层次。需求分析在软件工程中的地位举足轻重。一个完善的需求分析将指导我们走上成功之路，反之，错误的分析必将导致项目的彻底失败。在大部或局部雷同的项目中重复地使用已经被前驱项目证明是正确的部分分析结果，是提高分析工作效率、保证分析成功的一种有效方法。对于软件工程师来说，软件成分的重用是我们最为关注的45设计重用在开发类同项目的软件，尤其是在软件移植过程中能够极大地减少工作量，提高工作效率。设计结果重用包括体系结构设计重用和详细设计重用两重内涵。代码重用是最直接的重用。包括基于“宏”的重用、基于函数库的重用和基于继承的重用三种不同的方法。目前，基于函数库的重用(例如C语言)和基于继承(VB、JAVA等)的重用代表着代码重用的主流。尤其是基于继承的代码重用，随着面向对象方法的成熟，越来越受到重视。设计重用在开发类同项目的软件，尤其是在软件移植过程中46基于软件重用思想的框架(Framework)开发模式近年来备受关注。业界认为，软件构件化是21世纪软件工业发展的大趋势。工业化的软件复用已经从通用类库进化到了面向领域的应用框架。GartnerGroup(美国一家著名的IT咨询公司)认为：“到2003年，至少70%的新应用将主要建立在如软件构件和应用框架这类'构造块'之上；应用开发的未来就在于提供一个开放体系结构，以方便框架和构件的选择、组装和集成”。框架的重用已成为软件生产中最有效的重用方式之一。框架是整个或部分系统的可重用设计，表现为一组抽象构件及构件实例间交互的方法。另一种定义认为，框架是可被应用开发者定制的应用骨架。前者是从应用方面而后者是从目的方面给出的定义。基于软件重用思想的框架(Framework)开发模式47可以说，一个框架是一个可复用的设计构件，它规定了应用的体系结构，阐明了整个设计、协作构件之间的依赖关系、责任分配和控制流程，表现为一组抽象类以及其实例之间协作的方法，它为构件复用提供了上/下文(Context)关系。因此，构件库的大规模重用也需要框架。框架的最大好处就是重用。面向对象系统获得的最大的复用方式就是框架，一个大的应用系统往往可能由多层互相协作的框架组成。由于框架能重用代码，因此从一已有构件库中建立应用变得非常容易，因为构件都采用框架统一定义的接口，所以使构件间的通信趋于简单。可以说，一个框架是一个可复用的设计构件，它规定了应用48框架能够重用设计。它提供可重用的抽象算法及高层设计，并能将大系统分解成更小的构件，而且能描述构件间的内部接口。这些标准接口使在已有的构件基础上通过组装建立各种各样的系统成为可能。只要符合接口定义，新的构件就能插入框架中，构件设计者就能重用构件的设计。框架还能重用分析。所有的人员若都按照框架的思想来分析事务，那么就能将它划分为同样的构件。采用相似的解决方法，从而使采用同一框架的分析人员之间能进行沟通。框架能够重用设计。它提供可重用的抽象算法及高层设计，49采用框架技术进行软件开发的主要特点包括：(1)领域内的软件结构一致性好。(2)建立了更加开放的系统。(3)重用代码大大增加，软件生产效率和质量也得到了提高。(4)软件设计人员要专注于对领域的了解，使需求分析更充分。(5)存储了经验，可以让那些经验丰富的人员去设计框架和领域构件，而不必限于低层编程。采用框架技术进行软件开发的主要特点包括：50(6)允许采用快速原型技术。(7)有利于在一个项目内多人协同工作。(8)大粒度的重用使得平均开发费用降低，开发速度加快，开发人员减少，维护费用降低，而参数化框架使得适应性、灵活性增强。在现代软件工程领域中，“重用”软件成分的价值越来越为人们所认知。而为了重用财富，必须持续不断地积累财富。在工程实践中建立软件开发组织的财富数据库已经成为这些组织的共识。SEI(软件工程研究所)已经将建立与使用软件财富库作为提高开发组织软件过程成熟度的一个目标，有关这方面的具体内容可参见有关CMM3级的相关资料。(6)允许采用快速原型技术。512.10小结本章讲述了软件过程的基本概念和常用软件过程的构造与特点。我们已经知道，软件工程在计算机软件的开发中集成了过程、方法和工具。工程过程是用以开发或维护软件及其相关产品的一系列活动，包括软件工程活动和软件管理活动。从最传统的线性顺序过程开始，本章对原型模型、演化模型、RAD模型的结构、特点作了具体的介绍。通过对本章的学习，我们应当了解到如何根据具体项目的特点和开发环境，选择正确的过程模型，达到最佳的开发效果。2.10小结本章讲述了软件过程的基本概念和常用52第2章软件工程过程模型2.1软件工程的技术基础2.2软件工程过程2.3软件过程模型2.4线性顺序模型2.5原型模型2.6快速应用开发模型2.7演化软件过程模型2.8软件过程技术2.9软件重用技术2.10小结第2章软件工程过程模型2.1软件工程的技术基础532.1软件工程的技术基础图2.1软件工程过程层次图2.1软件工程的技术基础图2.1软件工程过程层次图54正如其他工程方法一样，软件工程必须以有组织的软件质量保证为基础。因此说，对质量的关注构成了软件工程的根基。软件工程过程是将技术层(包括工程技术与管理技术)结合在一起的凝聚力。过程层是软件工程的基层。软件工程过程定义了一组关键过程域(KPAs)，这对于软件工程技术的有效应用是必需的。这些关键过程区域是对软件工程项目进行管理与控制的基础，并且确定了上、下各区域之间的关系。其中，对于技术方法的采用、阶段产品的产生、工程里程碑的建立、质量监控与保证、变更控制等方面都进行了规定。除各个开发组织可以定义自己的软件工程过程之外，目前流行比较广泛的软件工程过程包括有RUP过程、极限(XP)过程、敏捷软件过程(AgileS.P)等等。正如其他工程方法一样，软件工程必须以有组织的软件质量55软件工程方法涵盖了需求分析、设计、编程、测试、维护等各个环节，它给出了完成这些任务在技术上应当“如何做”的方法。它依赖于一组基本原则，这些原则控制了每一个技术区域，涉及到建模活动和其他描述技术。工具层对过程和方法提供支持，使得工程活动、管理活动得以自动、半自动的进行。例如，目前广为使用的数据库建模工具Erwin、面向对象的建模工具RationnalRose、配置管理工具等等。如果把一系列的工具集成起来使用，使得一个工具产生的信息可以被另一个工具使用时，就形成了一个支持软件开发的系统。这种集成了软件、硬件和一个软件工程数据库的软件工程环境，称为计算机辅助软件工程(CASE)。软件工程方法涵盖了需求分析、设计、编程、测试、维护等562.2软件工程过程如前所述，软件工程过程是开发或维护软件及其相关产品的一系列活动。软件工程过程是过去十年中人们关注的焦点。软件工程和软件工程过程之间是强相关的。软件工程过程通常包括四种基本的过程活动：(1)软件规格说明：规定软件的功能、性能及其运行限制。(2)软件开发：产生满足规格说明的软件，包括设计与编码等工作。(3)软件确认：确认软件能够满足客户提出的要求，对应于软件测试。(4)软件演进：为满足客户的变更要求，软件必须在使用的过程中演进，以求尽量延长软件的生命周期。2.2软件工程过程如前所述，软件工程过程是开发或57在一个良好的软件过程中，还应当包括一些“保护性”的活动，包括软件项目的跟踪监控、正式的技术审核、软件配置管理活动、软件质量保证活动、文档的准备和产生、软件测试、风险管理等等。这些保护性活动贯穿于整个工程过程之中。在具体的工程过程中，可以根据实际需要，采用不同的过程模型来实现上述的基本活动和保护活动。事实上，软件工程过程是一个软件开发组织针对某一类软件产品为自己规定的工作步骤，它应当是科学的、合理的，否则必将影响到软件产品的质量。一个良好的软件工程过程应当具备如下特点：在一个良好的软件过程中，还应当包括一些“保护性”的活58(1)易理解性。(2)可见性：每个过程活动都以得到明确的结果而告终，保证过程的进展对外可见。(3)可支持性：容易得到CASE工具的支持。(4)可接受性：比较容易被软件工程师接受和使用。(5)可靠性：不会出现过程错误，或者出现的过程错误能够在产品出错之前被发现。(6)健壮性：不受意外发生问题的干扰。(7)可维护性：过程可以根据开发组织的需求的改变而改进。(8)高效率：从给出软件规格说明起，就能够较快地完成开发而交付使用。(1)易理解性。59一个软件过程可以表示成如图2.2所示的形式。其中，公共过程框架是通过定义若干适合于所有软件项目的框架活动而建立的；若干任务集合中，每一个集合都由软件工程工作任务、软件项目里程碑、软件工作产品和交付物以及质量保证点组成；保护性活动独立于任何一个框架，贯穿于整个过程。一个软件过程可以表示成如图2.2所示的形式。其中，公60图2.2软件工程过程图2.2软件工程过程612.3软件过程模型在一个具体的实际工程活动中，软件工程师必须设计、提炼出一个工程开发策略，用以覆盖软件过程中的基本阶段，确定所涉及的过程、方法、工具。这种策略常被称为“软件工程过程模型”。这一模型的选择应当是根据组织定义的标准软件过程，参考具体工程项目的特点和资源状况进行裁剪来进行的。2.3软件过程模型在一个具体的实际工程活动中，软62从宏观上来看，所有的软件开发过程都可以看成是一个循环解决问题的过程。其中包括四个截然不同的阶段：状态描述、问题定义、技术开发和方案综述，如图2.3所示。状态描述表示了事物的当前状态；问题定义标识了要解决的特定问题；技术开发通过应用某些技术来解决问题；方案综述提交解决结果(如文档、程序、数据、新的商业功能、新产品)给那些从一开始就需要方案的人。前面定义的软件工程的一般阶段和步骤很容易映射到这些阶段上。

从宏观上来看，所有的软件开发过程都可以看成是一个循环63图2.3问题循环解决的各个阶段图2.3问题循环解决的各个阶段64上述的问题循环解决过程可以应用于软件工程的多个不同开发级别(阶段)上，包括考虑整个系统开发的宏观阶段，开发程序构件的中间阶段，甚至是代码编制阶段，因此可以采用分级集合表示。可以定义一个模式，然后在连续的、更小的规模上递归地应用它，这样来提供一个关于过程的理想化的视图。问题循环解决过程的每一个阶段又包含一个相同的问题循环解决过程，如图2.4所示。可以认为，软件开发是从用户到开发者再到技术的一个连续的过程。随着向一个完整系统的逐步进展，上述的阶段递归地应用于用户的需求和开发者的软件技术说明中。

上述的问题循环解决过程可以应用于软件工程的多个不同开65图2.4问题循环解决阶段中的阶段图2.4问题循环解决阶段中的阶段66要想像图2.3那样清楚地划分阶段活动是很困难的，因为阶段内部和阶段之间的活动往往是交叉的。但是对于任何一个软件项目而言，不管选择了什么样的具体的软件工程过程模型，所有四个活动阶段在某个细节的级别上都是同时存在的。图2.4描述了实际过程的递归性质。在后面的讨论中，我们将会看到，每一种具体的软件工程过程模型实际上都代表了一种将本质上无序的活动有序化的企图。每一种模型都具有能够帮助实际软件项目的控制及协调的特征，但在它们的核心中，这些模型又表现了无序模型的特点。要想像图2.3那样清楚地划分阶段活动是很困难的，因为67在软件工程实践中，有许多专家治力于过程模型的研究。像瀑布模型、原型模型、快速应用开发模型、增量模型、螺旋模型、形式化方法模型、RUP模型、敏捷过程模型、构件组装模型、并发开发模型等等都先后得到了有效的应用。目前，关于软件工程过程模型的研究仍然在积极地进行之中，将不断取得新的进展与成就。在软件工程实践中，有许多专家治力于过程模型的研究。像682.4线性顺序模型图2.5线性顺序模型2.4线性顺序模型图2.5线性顺序模型69线性顺序模型有时也称为“瀑布模型”。它表示了软件开发系统的、顺序的方法。虽然瀑布模型支持带反馈的循环，但大多数使用者均把它视为是严格线性的。从系统级开始，随后是分析、设计、编码、测试和维护。借鉴传统的工程周期，线性顺序模型的活动如图2.5所示。

线性顺序模型有时也称为“瀑布模型”。它表示了软件开70线性顺序模型是最早，也曾经是应用最广泛的软件工程过程模型，但是这种模型不适应需求经常发生变更的环境。实际的项目很少能够严格地按照该模型给出的顺序进行。需求的变更、设计的变更、编码的变更几乎是不可避免的。虽然线性顺序模型能够允许迭代，但却是间接的迭代。在项目的开发过程中，变更可能会引起混乱。所以，有人形象地把采用线性模型进行商业软件工程称之为“在沙滩上盖楼房”。考虑到用户对于需求的理解有一个渐进渐深的过程，一开始用户往往难以明确地提出所有的需求，这样，线性顺序模型的第一步输入就得不到满足。线性顺序模型是最早，也曾经是应用最广泛的软件工程过程71同时，线性顺序模型也经常不能接受项目开始阶段自然存在的不确定性。在采用线性顺序模型的时候，用户只有到项目的开发晚期才能够得到程序的可运行版本。大的错误如果到这时才被发现，那么造成的后果往往是灾难性的。同时，因为线性顺序模型每一步的工作都必须以前一阶段的输出为输入，这种特征会导致工作中发生“阻塞”状态。某些项目组成员不得不等待组内其他成员先完成前驱任务才可能展开自己的工作。有时这种等待时间可能会超过实际花在工作上的时间。这种阻塞状态在线性顺序过程的开始和结束时经常会发生。同时，线性顺序模型也经常不能接受项目开始阶段自然存在72虽然存在着上述的种种问题，但是线性顺序模型仍然有其值得肯定之处。它提供了一个模板，使得分析、设计、编码、测试与维护工作可以在该模板的指导下有序地展开，避免了软件开发、维护过程中的随意状态。采用这种模型，曾经成功地进行过许多大型软件工程的开发。直至目前，对于需求确定、变更相对较少的项目，线性顺序模型仍然是一种可以考虑采取的过程模型。但在“用户驱动”的商业软件开发中，采用线性顺序模型并不是一个好的选择。虽然存在着上述的种种问题，但是线性顺序模型仍然有其值732.5原型模型大型建筑在施工之前，常常按照图纸制造一个缩小的模型来验证工程完成后可能的效果；新的工业设计在充分证明其正确性之前，也往往利用在缩小规模的前提下制造少量成品进行检验的方法来验证设计正确与否。同样的，如果在开发一项软件工程的时候，用户不能准确、全面地描述其需求，或者开发者还不能确定所选用算法的有效性或人机交互界面的形式时，同样也可以建立一个简化了的样品程序并使之运行，引导用户通过对样品运行情况的观察，进一步明确需求或验证算法的正确性。这种开发模式就称之为“原型模型”，如图2.6所示。2.5原型模型大型建筑在施工之前，常常按照74图2.6原型模型图2.6原型模型75原型模型从需求收集开始，开发者和用户在一起定义软件的总体目标，标识出已知的需求，并规划出进一步定义的区域。然后进行快速设计并进行编码实现，进行原型的建造。这种快速设计和建造通常集中在那些对用户可见的部分(如输入方式、输出界面)。原型建造好之后，运行原型程序，由用户和开发者进行评估、验证。接着进一步精化待开发软件的需求，逐步调整原型以使其逐渐满足用户的真正需求，同时也使开发者对将要完成的开发任务有更深入的理解。这一过程是多次迭代进行的。原型模型从需求收集开始，开发者和用户在一起定义软件的76使用原型模型必须有两个前提。其一是用户必须积极参与原型的建造，同时开发者和用户必须有共识：建造原型仅仅是为了定义需求，之后就必须被全部抛弃(至少是部分抛弃)，实际的软件必须在充分考虑到软件质量和可维护性之后才被开发。从这个意义上说，原型模型又往往被称为“抛弃原型模型”。其二是必须有快速开发工具可供使用。使用原型模型必须有两个前提。其一是用户必须积极参与原772.6快速应用开发模型快速应用开发(RAD)模型是线性顺序模型的一个“高速”变种，强调极端的开发周期。RAD模型通过使用基于构件的建造方法达到快速开发的效果。在需求得到很好理解、项目的范围约束明晰的前提下(通常不容易保证这样的条件)，采用RAD过程能够使项目组在很短的时间内(如60～90)天创建出功能完善的系统。RAD过程主要用于信息应用软件的开发，如图2.7所示，它包含如下几个开发阶段：2.6快速应用开发模型快速应用开发(RAD)模型是78图2.7RAD模型图2.7RAD模型79业务建模：业务活动中的信息流被模型化。此阶段说明什么信息驱动业务流程、生成什么信息、谁负责生成该信息、该信息流向何处、谁处理它等。数据建模：业务建模阶段定义的一部分信息流被精化，形成一组支持该业务所需的数据对象。此阶段标识出每个数据对象的特征属性，定义这些对象之间的关系。处理建模：数据建模阶段定义的数据对象变换成为要完成一项业务功能所需的信息流。此阶段创建处理描述以便增加、修改、删除或获取某个数据对象。业务建模：业务活动中的信息流被模型化。此阶段说明什么80应用生成：RAD过程不是采用传统的第三代程序设计语言来创建软件，而主要是复用已有的程序构件或是创建可复用的构件。在所有情况下，均使用自动化工具辅助软件建造。测试及反复：RAD过程强调复用，许多构件是已经测试过的，减少了测试工作量。但是所有的新创建构件、所有的接口都必须测试到。采用RAD模型时，系统的每一个主要功能部件可以由一个单独的RAD工作组完成，最后再将所有的部件集成起来形成完整的软件。应用生成：RAD过程不是采用传统的第三代程序设计语言81RAD模型强调可复用程序构件的开发，支持多小组并行工作以缩短整体工期。但是如果一个系统难以被适当地模块化，构件的复用和建造就会出现问题。作为线性顺序模型的一个变种，它具有线性顺序模型所具有的种种特性。同时，RAD模型依赖于构件复用，它不适用于技术风险很高的、要采用很多新技术的项目。对于具有高性能需求的软件，如果这种高性能必须通过对接口的反复调整才能实现，那么采用RAD模型也就有可能失败。RAD模型强调可复用程序构件的开发，支持多小组并行工822.7演化软件过程模型软件就象其他复杂系统一样，需要经过一段时间的演化改进，才能够最终满足用户需求。业务和产品需求随着开发的进展常常发生变更，因而难以一步到位地完成最终的软件产品，但是，紧迫的市场期限又不允许软件工程师过多地延长开发周期。为了应对市场竞争或商业目标的压力，构造了“演化软件模型”。它的基本思想是“分期完成、分步提交”。可以先提交一个有限功能的版本，再逐步地使其完善。2.7演化软件过程模型软件就象其他复杂系统一样，需83演化模型的主要特点是利用“迭代”方法，使工程师们渐进地开发，生产出逐步完善的软件版本。在商业软件开发实践中，演化模型日益得到广泛的应用。用户的支持、理解和全程参与是成功采用演化模型的重要前提。演化模型兼有线性顺序模型和原型模型的一些特点。但线性顺序模型本质上是假设当线性开发序列完成之后就能够交付一个完整的系统；原型模型的目的是引导用户明确需求、帮助工程师验证算法，总体上讲它并不交付一个最终的产品系统。它们都没有考虑到软件的“演化”过程。根据开发策略的不同，演化模型又可以细分为“增量”模型和“螺旋”模型两种。演化模型的主要特点是利用“迭代”方法，使工程师们渐进842.7.1增量模型增量模型融合了线性顺序模型的基本成分(重复的应用这些成分)和原型模型的迭代特征，如图2.8所示。增量模型实际上是一个随着日程/时间的进展而交错的线性序列集合。每一个线性序列产生一个软件的可发布的“增量”，所有的增量都能够结合到原型模型中去。2.7.1增量模型85图2.8增量模型图2.8增量模型86当使用增量模型时，第一个增量模型往往是核心部分的产品，它实现了软件的基本需求，但很多已经明晰或者尚不明晰的补充特性还没有发布。核心产品交由用户使用或进行详细复审。使用或复审评估的结果是制定下一个增量开发计划。该计划包括对核心产品的修改及增加一些新的功能与特性。这个过程在每一个增量发布后迭代地进行，直到产生最终的完善产品。和原型模型不一样的是，增量模型虽然也具有“迭代”特征，但是每一个增量都发布一个可操作的产品，不妨称之为“产品扩充迭代”。它的早期产品是最终产品的可拆卸版本，每一个版本都能够提供给用户实际使用。当使用增量模型时，第一个增量模型往往是核心部分的产品87在实际开发过程中，增量模型是十分有用的一种模型。对于防范技术风险、缩短产品提交时间都能够起到良好的作用。应当再次强调的是，用户在开发软件的过程中，往往有“一步到位”的思想，因而增量式的工程开发必须取得用户的全面理解与支持，否则是难以成功的。在实际开发过程中，增量模型是十分有用的一种模型。对于882.7.2螺旋模型螺旋模型也是属于演化软件过程模型。它将原型的迭代特征与线性顺序模型中控制的和系统化的方面结合起来，使得能够快速开发软件的增量版本。在螺旋模型中，软件开发是一系列的增量发布。和增量模型不同，它并不要求每一个增量都是可以运行的程序。在早期的迭代中，发布的增量可以是一个纸上的模型或原型；在以后的迭代中产生更加完善的版本。螺旋模型被划分为若干个框架活动，如图2.9所示。活动也称为任务区域，一般包括：2.7.2螺旋模型89(1)用户通信：建立开发者和用户之间有效通信所需要的任务。(2)计划：定义资源、进度和其他项目相关信息所需要的任务。(3)风险分析：评估技术的及管理的风险所需要的任务。(4)工程：建立应用的一个或多个表示所需要的任务。(5)建造及发布：建造、测试、安装和提供用户支持所需要的任务。(6)用户评估：基于在工程阶段产生的或在安装阶段实现的软件表示的评估，是获得用户反馈所必需的任务。(1)用户通信：建立开发者和用户之间有效通信所需要90图2.9一个典型的螺旋模型图2.9一个典型的螺旋模型91每一个框架活动(任务区域)均含有一系列的适应待开发项目特点的工作任务(活动)。在所有的情况下，都需要应用诸如软件配置管理、软件品质保证等保护性活动。随着演化过程的开始，软件工程项目组按照顺时针方向沿螺旋移动。从核心开始，第一圈可能产生软件规格说明书，第二圈可能开发出一个原型，随后可能是软件更完善的版本。经过计划区域的每一圈都会对计划进行调整，基于从用户处得到的反馈，调整进度和费用以及版本的内容。项目管理者可以根据项目的具体情况调整所需要的迭代次数。

每一个框架活动(任务区域)均含有一系列的适应待开发项92和传统的过程模型不同，螺旋模型能够适应于计算机软件产品的整个生命周期，而不是当软件交付后就结束过程。对于大型系统及软件的开发工作来说，螺旋模型是一种很好的模型方法。采用这种模型，随着过程的发展演化，开发者和用户能够更好地理解和对待每一个演化级别上的风险。它使开发者在产品演化的任何阶段上都能够使用原型方法，保持了传统生命周期模型中的阶段化的工作方式，但同时又引入了迭代的框架，更加真实地反映了现实世界。同时也有利于防范技术风险。螺旋模型的应用同样有赖于用户的充分理解和积极参与。同时，它需要使用专门的风险评估技术以便识别风险、防范风险。和传统的过程模型不同，螺旋模型能够适应于计算机软件产932.8软件过程技术前面讨论的过程模型必须适合于软件项目组的使用。为满足这一要求，先后开发出了许多过程管理工具以帮助软件组织分析他们当前的过程，协调组织工作任务，控制和监管进度以及管理技术质量。例如，利用配置管理工具来进行配置管理和缺陷管理；利用自动测试工具进行测试；利用统一建模语言UML来进行对象建模、分析与设计；利用Project制订和监测项目计划及其进展；利用第四代技术，通过开发者在较高的层次上说明软件的某些特征，之后工具就能够自动的根据说明生成源代码等等。计算机辅助软件工程已经在软件领域中发挥着重要的作用。2.8软件过程技术前面讨论的过程模型必须适合于软件94采用合适的过程技术工具，使得软件开发组织能够建造一个自动模型，该模型包括通用的过程框架、任务集合及保护性活动。该模型一般表示成一个网络，对其加以分析，就能够确定典型的工作流程，考察可能导致降低开发时间和成本的可供选择的过程结构。一旦创建了一个可接受的过程，就可以使用其他过程工具来分配、监管，甚至控制过程模型中所定义的所有软件工程任务。软件项目组的每一个成员均能够使用这些工具产生一个清单，包括：要完成的任务、要开发的工作产品以及要实现的质量控制活动等等。采用合适的过程技术工具，使得软件开发组织能够建造一个952.9软件重用技术“重用”是提升软件财富价值的有效途径。一般来说，这里所指的重用可以包括知识重用、方法重用、软件成分重用三个层次。例如，软件工程知识的重用使我们能够高效率的开发、维护一个又一个的软件项目；行之有效的软件工程方法的重用帮助我们有章可循的解决各类工程问题；软件成分的重用则使我们在需求分析