夜雨聆风软件工程是指应用计算机科学、数学及管理科学等原理，以工程化的原则和方法来解决软 件问题的工程，其目的是提高软件生产率、提高软件质量、降低软件成本。IEEE 对软件工程的 定义是：将系统的、规范的、可度量的工程化方法应用于软件开发、运行和维护的全过程及上 述方法的研究。
软件工程由方法、工具和过程三个部分组成。软件工程方法是完成软件工程项目的技术手 段，它支持整个软件生命周期；软件工程使用的工具是人们在开发软件的活动中智力和体力的扩 展与延伸，它自动或半自动地支持软件的开发和管理，支持各种软件文档的生成；软件工程中的 过程贯穿软件开发的各个环节，管理人员在软件工程过程中，要对软件开发的质量、进度、成本 进行评估、管理和控制，包括人员组织、计划跟踪与控制、成本估算、质量保证和配置管理等。
7.1 软件生命周期
软件产品从形成概念开始，经过开发、使用和维护，直到最后退役的全过程称为软件生命 周期或生存周期。一个完整的软件生命周期是以需求为出发点，从提出软件开发计划的那一刻 开始，直到软件在实际应用中完全报废为止。软件生命周期的提出是为了更好地管理、维护和 升级软件，其中更大的意义在于管理软件开发的步骤和方法。
目前，划分软件生命周期阶段的方法有许多种，软件规模、种类、开发方式和开发环境， 以及开发时使用的方法论都影响软件生命周期阶段的划分。对软件生命周期各阶段进行划分， 必须遵循一条基本的原则，那就是各阶段的任务应尽可能地相对独立，同一阶段各项任务的性 质应尽可能地相同，从而降低每个阶段任务的复杂度，减少不同阶段任务之间的联系，有利于 软件工程的组织和管理。
软件生命周期过程
在国家标准《系统与软件工程软件生存周期过程( GB/T 8566—2022)》中，将软件生存周 期中可能执行的活动分为5个基本过程、9个支持过程和7个组织过程。每个生存周期过程划 分为一组活动，每一项活动进一步划分为一组任务。
(1)基本过程。基本过程供各主要参与方在软件生存周期期间使用，主要参与方是发起或 完成软件产品开发、运行或维护的组织。基本过程分为获取过程、供应过程、开发过程、运作 过程和维护过程。获取过程是指为获取系统、软件产品或软件服务的组织(即需方)而定义的 活动；供应过程是指为向需方提供系统、软件产品或软件服务的组织(即供方)而定义的活动； 开发过程是指为定义并开发软件产品的组织(即开发方)而定义的活动，包括需求分析、设计 编码、集成、测试以及与软件产品有关的安装和验收等活动；运作过程是指为在规定的环境中 为其用户提供运行计算机系统服务的组织(即操作方)而定义的活动；维护过程是指为提供维
第7章 软件工程 245
护软件产品服务的组织(即维护方)而定义的活动，也就是对软件的修改进行管理，使它保持 合适的运行状态，包括软件产品的迁移和退役。
(2)支持过程。支持过程作为一个有机组成部分支持其他过程，以便取得软件项目的成功， 并提高软件项目的质量。支持过程包括文档编制过程、配置管理过程、质量保证过程、验证过 程、确认过程、联合评审过程、审核过程、问题解决过程和易用性过程。根据需要，支持过 程可被其他过程应用和执行。文档编制过程是指为记录生存周期过程所产生的信息而定义的活 动；配置管理过程是指定义配置管理活动；质量保证过程是指为客观地保证软件产品和过程符 合规定的需求以及已建立的计划而定义的活动，联合评审、审核、验证和确认可以作为质量保 证技术使用；验证过程是指根据软件项目需求，按不同深度为需方、供方或某独立方验证软件 产品而定义的活动；确认过程是指为需方、供方或某独立方确认软件项目的软件产品而定义的 活动；联合评审过程是指为评价一项活动的状态和产品而定义的活动，该过程可由任何两方应 用，其中一方(评审方)以联合讨论会的形式评审另一方(被评审方);审核过程是指为判定符 合需求、计划和合同而定义的活动，该过程可由任何两方应用，其中一方(评审方)审核另一 方(被评审方)的软件产品或活动；问题解决过程是指为分析和解决问题(包括不合格)而定 义的活动，不论问题的性质或来源如何，它们都是在实施开发、运作、维护或其他过程期间暴 露出来的；易用性过程是指为易用性专业人员而定义的活动。
(3)组织过程。组织过程可被某个组织用来建立和实现 可行性研究 获取过程
由相关的生存周期过程和人员组成的基础结构，并不断改进 供应过程
这种结构和过程。应用这些过程通常超出特定的项目和合同的 需求分析
范围，但是，这些特定项目和合同的经验教训有助于改善组织
状况。组织过程包括管理过程、基础设施过程、改进过程、人 概要设计
力资源过程、资产管理过程、重用大纲管理过程和领域工程过
程。管理过程是指为生存周期中的管理(包括项目管理)而 详细设计
定义的基本活动：基础设施过程是指为建立生存周期过程基
础结构而定义的基本活动；改进过程是指为某一组织建立、 实现
测量、控制和改进其生存周期过程而定义的需要执行的基本
活动；人力资源过程是指为给组织或项目提供拥有技能和知 组装测试
识的员工而定义的活动；资产管理过程是指为组织的资产管
理人员而定义的活动；重用大纲管理过程是指为组织的复用 确认测试
大纲主管而定义的活动；领域工程过程是指为领域模型、领
运作过程
域架构的确定及该领域资产的开发和维护而定义的活动。 使用
软件生命周期各阶段的任务
维护
根据国家标准GB/T 8566—2022, 软件生命周期可以划 维护过程
分为可行性研究、需求分析、概要设计、详细设计、实现、 退役
组装测试、确认测试、使用、维护、退役10个阶段，各自
分别对应于软件生存周期的基本过程，如图7-1所示。
246 系统分析师教程(第2版)
(1)可行性研究和项目开发计划。通过分析用户提出的软件开发要求，确定软件项目的 性质、目标和规模，得出可行性研究报告。如果可行性研究的结果是可行的，就要制定详细的 项目开发计划。这两个活动通常被整合在一起进行，在实际工作中通常把它们归类到同一个阶 段中。
(2)需求分析。需求分析工作是软件生命周期中重要的一步，也是决定性的一步。只有通 过需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软 件开发的基础。
(3)概要设计。根据软件需求规格说明建立软件系统的总体结构和模块间的关系，定义各 功能模块接口，设计全局数据库或数据结构，规定设计约束，制定组装测试计划。
(4)详细设计。将各模块要实现的功能用相应的设计工具详细描述出来。
(5)实现。写出正确的、易理解的和易维护的程序模块。程序员根据详细设计文档将详细 设计转化为程序，完成单元测试。
(6)组装测试(集成测试)。将经过单元测试的模块逐步进行组装和测试。
(7)确认测试。测试系统是否达到了系统需求，按照规格说明书的规定，由用户(或在用 户积极参与下)对系统进行验收。必要时，还可以再通过现场测试或并行运行等方法对系统进 行进一步的测试。
(8)使用。将软件安装在用户确定的运行环境中，测试通过后移交用户使用。在软件的使 用过程中，客户和维护人员必须认真收集发现的软件错误，定期或阶段性地撰写软件问题报告 和软件修改报告。
(9)维护。通过各种必要的维护活动使系统持久地满足用户的需要。
(10)退役。终止对软件产品的支持，软件停止使用。
7.2 软件开发方法与模型
软件开发方法是指软件开发过程所遵循的办法和步骤，从不同的角度可以对软件开发方法 进行不同的分类。从开发风范上看，可分为自顶向下的开发方法与自底向上的开发方法。在实 际软件开发中，经常是两种方法结合使用，只不过是应用于开发的不同阶段和以何者为主而已。
软件开发模型则给出了软件开发活动各阶段之间的关系，它是软件开发过程的概括，是软 件工程的重要内容。软件开发模型为软件工程管理提供了里程碑和进度表，为软件开发过程提 供了原则和方法。
7.2.1 传统软件开发模型
软件开发模型大体上可分为三种类型：第一种是以软件需求完全确定为前提的瀑布模型； 第二种是在软件开发初始阶段只能提供基本需求时采用的迭代式或渐进式开发模型，例如，喷 泉模型、螺旋模型、统一开发过程和敏捷方法等；第三种是以形式化开发方法为基础的变换 模型。
第7章 软件工程 247
瀑布模型
软件开发生命周期( Software Development Life Cycle,SDLC) 模型的发展体现了软件工程 理论的发展。在最早的时候，软件的开发过程处于无序和混乱的状况，人们为了能够控制软件 的开发过程，就将软件开发严格区分为多个不同的阶段，并在阶段之间加上严格的审查，这就 是瀑布模型产生的起因。
瀑布模型是一种严格定义方法，它将软件开发的过程分为软件计划、需求分析、软件设计、 程序编码、软件测试和运行维护6个阶段，形如瀑布流水，最终得到软件产品，如图7-2所示。
软件计划
需求分析
软件计划
程序编码
软件测试
运行维护
图7-2 瀑布模型
瀑布模型是一个线性顺序模型，支持线性开发。它假设当线性序列完成之后就能交付一个 完善的系统，并没有考虑软件的演化特征。其优点是强调开发的阶段性、早期计划和需求调查 以及产品测试，以这样严格的方式构造软件，开发人员很清楚每一步应该做什么,有利于项目 管理。
然而，在瀑布模型中，依赖于早期进行的需求调查，不能适应需求的变化；由于是单一流 程，开发中的经验教训不能反馈应用于本产品的过程；风险往往推迟至后期的开发阶段才显露 出来，从而失去了及早纠正的机会。在瀑布模型中，需求或设计中的错误往往只有到了项目后 期才能够被发现，对于项目风险的控制能力较弱，从而导致项目常常延期完成，开发费用超出 预算。
2. 演化模型
演化模型主要针对事先不能完整定义需求的软件开发，是在快速开发一个原型的基础上， 根据用户在调用原型的过程中提出的反馈意见和建议，对原型进行改进，获得原型的新版本， 重复这一过程，直到演化成最终的软件产品。
演化模型的主要优点是，任何功能一经开发就能进入测试，以便验证是否符合产品需求， 可以帮助引导出高质量的产品要求。其主要缺点是，如果不加控制地让用户接触开发中尚未稳 定的功能，可能对开发人员及用户都会产生负面的影响。
248 系统分析师教程(第2版)
螺旋模型
螺旋模型是瀑布模型与演化模型相结合，并加入两者所忽略的风险分析所建立的一种软件 开发模型。螺旋模型是一种演化软件过程模型，它将原型实现的迭代特征与线性顺序模型中的 控制和系统化的方面结合起来，使软件的增量版本的快速开发成为可能。在螺旋模型中，软件 开发是一系列的增量发布。
螺旋模型沿着螺旋线进行若干次迭代，每次迭代都包括制订计划、风险分析、实施工程和 客户评估4个方面的工作。螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的 风险有所了解，继而做出应有的反应。因此，它特别适用于庞大、复杂并具有高风险的系统。
与瀑布模型相比，螺旋模型支持用户需求的动态变化，为用户参与软件开发的所有关键决 策提供了方便，有助于提高软件的适应能力，并且为项目管理人员及时调整管理决策提供了便 利，从而降低了软件开发的风险。在使用螺旋模型进行软件开发时，需要开发人员具有相当丰 富的风险评估经验和专门知识。另外，过多的迭代次数会增加开发成本，延迟提交时间。喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件 开发过程。该模型认为软件开发过程自下而上的各阶段是相互重叠和多次反复的，就像水喷上 去又可以落下来，类似一个喷泉。各个开发阶段没有特定的次序要求，并且可以交互进行，可 以在某个开发阶段随时补充其他任何开发阶段中的遗漏。
在喷泉模型中，各活动之间无明显边界，例如，分析和设计之间没有明显的边界。这种特 性称为无间隙性。由于对象概念的引入，只用类和关系来表达分析、设计和实现等活动，从而 可以较容易地实现活动的迭代和无间隙，提高软件项目开发效率，节省开发时间。变换模型
变换模型是基于形式化规格说明语言和程序变换的软件开发模型，它对形式化的软件规格 说明进行一系列自动或半自动的程序变换，最后映射为计算机能够接受的软件系统。为了确认 形式化规格说明与软件需求的一致性，往往以形式化规格说明为基础开发一个软件原型，用户 可以从人机界面、系统主要功能和性能等方面对原型进行评审。必要时，可以修改软件需求、 形式化规格说明和原型，直至原型被确认为止。这时，开发人员即可对形式化的规格说明进行 一系列的程序变换，直至生成计算机可以接受的目标代码。
变换模型的优点是解决了代码结构经多次修改而变坏的问题，减少了许多中间步骤(例如， 设计、编码和测试等)。但是，变换模型仍有较大的局限性，以形式化开发方法为基础的变换模 型需要严格的数学理论和一整套开发环境的支持。智能模型
智能模型也称为基于知识的软件开发模型，它综合了上述若干模型，并把专家系统结合在 一起。该模型应用基于规则的系统，采用规约和推理机制，帮助开发人员完成开发工作，并使 维护在系统规格说明一级进行。为此，需要建立知识库，将模型本身、软件工程知识与特定领 域的知识分别存入知识库。
第7章 软件工程 249
7.V 模型
V 模型是在快速应用开发模型的基础上演变而来的，由于将整个开发过程构造成一个V 字 形而得名。V 模型应用在软件测试方面，和瀑布模型有一些共同的特征。V 模型的过程从左到右， 描述了基本的开发过程和测试行为，其价值在于它非常明确地标明了测试过程中存在的不同级 别，并且清楚地描述了这些测试阶段和开发过程各阶段的对应关系，如图7-3所示。
需求分析 验收测试
概要设计 系统测试
详细设计 集成测试
编码 单元测试
图7-3 V 模型
在V 模型中，单元测试是基于代码的测试，最初由开发人员执行，以验证程序代码的各个 部分是否已达到预期的功能要求；集成测试验证了两个以上单元之间的集成是否正确，并有针 对性地对详细设计中所定义的各单元之间的接口进行检查；在所有单元测试和集成测试完成后， 系统测试开始以客户环境模拟系统的运行，验证系统是否达到了在概要设计中所定义的功能和 性能；最后，当技术部门完成了所有测试工作后，由业务专家或用户进行验收测试，以确保产 品能真正符合用户业务上的需要。
V 模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证较高的软 件质量的情况下缩短开发周期。V 模型适合企业级的软件开发，它更清楚地揭示了软件开发过 程的特性及其本质。
7.2.2 快速应用开发
快速应用开发( Rapid Application Development,RAD) 是一种比传统生命周期法快得多的 开发方法，它强调极短的开发周期。RAD 模型是瀑布模型的一个高速变种，通过使用基于构件 的开发方法获得快速开发。如果需求理解得很好，且约束了项目范围，利用这种模型可以很快 开发出功能完善的信息系统。
1.RAD 的基本思想
RAD的基本思想体现在以下4个方面：
(1)让用户更主动地参与到系统分析、设计和构造活动中来。
(2) 将项目开发组织成一系列重点突出的研讨会，研讨会要让项目投资方、用户、系统分 析师、设计人员和开发人员一起参与。
(3) 通过一种迭代的构造方法，加速需求分析和设计阶段。
(4)让用户提前看到一个可工作的系统。
2.RAD的开发阶段
RAD的流程从业务建模开始，随后是数据建模、过程建模、应用生成、测试与交付。
(1)业务建模。确定驱动业务过程运作的信息、要生成的信息、如何生成、信息流的去向 及其处理等，可以使用数据流图来帮助建立业务模型。
(2)数据建模。为支持业务过程的数据流查找数据对象集合、定义数据对象属性，并与其 他数据对象的关系构成数据模型，可以使用E-R 图来帮助建立数据模型。
(3)过程建模。将数据对象变换为要完成一个业务功能所需的信息流，创建过程以描述增 加、修改、删除或获取某个数据对象，即细化数据流图中的加工。
(4)应用生成。利用第四代语言(4GL) 写出处理程序，复用已有构件或创建新的可复用 构件，利用环境提供的工具自动生成并构造出整个应用系统。
(5)测试与交付。因为RAD强调复用，许多构件已经是测试过的，这就减少了测试的时 间。由于大量复用，所以一般只做总体测试，但新创建的构件还是要测试的。
3.RAD的特点
RAD采用基于构件的开发方法，复用已有的程序结构(如果可能的话)或使用构件，或者 创建可复用的构件(如果需要的话)。在所有情况下，均可以使用CASE 工具辅助进行软件构 建。如果一个业务能够被模块化，使得其中每一个主要功能均可以在不到三个月的时间内完成， 那么,它就是RAD的一个候选者。每个主要功能可由一个单独的RAD 组来实现，最后再集成 起来，形成一个整体。
RAD通过大量使用可复用构件，加快了开发速度。但是，RAD 也具有以下局限性：
(1)并非所有应用都适合RAD 。RAD对模块化要求比较高，如果有哪一项功能不能被模 块化，那么RAD 所需要的构件就会有问题；如果高性能是一个指标，且该指标必须通过调整接 口使其适应系统构件才能获得，则RAD也有可能不能奏效。
(2)开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导 致RAD项目失败。
(3)RAD 只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系 统要采用很多新技术，或当新系统要与现有系统有较高的互操作性时，就不适合使用RAD。
7.2.3 统一过程模型
统一过程( Unified Process,UP) 是一个通用过程框架，可以用于种类广泛的软件系统、不 同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP 是基于构件的，在为 软件系统建模时，UP 使用的是UML。与其他软件过程相比，UP 具有三个显著的特点，即用例 驱动、以架构为中心、迭代和增量。
UP 提供了在开发组织中分派任务和责任的纪律化方法，它的目标是在可预见的日程和预算 前提下，确保满足最终用户需求的高质量产品。对所有的关键开发活动，它为每个团队成员提 供了使用准则、模板和工具指导。而通过对相同基础知识的一致理解，在进行需求分析、设计、
第7章 软件工程
测试或配置管理等工作时，均能确保全体成员共享相同的知识、过程和开发软件的视图。
1.RUP 概述
RUP( Rational Unified Process) 是 Rational 公司开发和维护的过程产品，是由Objectory 过 程演化而来的。RUP 将项目管理、业务建模、分析与设计等统一起来，贯穿整个开发过程。 RUP采用Internet 技术，可以增强团队的开发效率，并为所有成员提供最佳的软件实现方案， 它使团队中每个开发人员的见解和思想得到统一，使开发小组成员的沟通更为容易，而这正是 任何项目取得成功的关键因素。RUP 可以增强开发人员对软件的预见性，最终的好处就是提高 了软件质量，并有效缩短了软件从开发到投放市场的时间。RUP 为软件开发提供了规范性的指 南、模板和范例，可用来开发所有类型的应用。
RUP中的软件过程在时间上被分解为4个顺序的阶 段，分别是初始阶段、细化阶段、构建阶段和移交阶段。 每个阶段结束时都要安排一次技术评审，以确定这个阶 段的目标是否已经满足。如果评审结果令人满意，就允 许项目进入下一个阶段。基于RUP 的软件过程模型如 图7-4所示。
从图7-4中可以看出，基于RUP 的软件过程是一个 迭代过程。初始、细化、构建和移交4个阶段就是一个 开发周期，每次经过这4个阶段就会产生一代软件。除 非产品退役，否则，通过重复同样的4个阶段，产品将
初始阶段
细化阶段
构建阶段
移交阶段
图7-4 基于RUP 的软件过程
演化为下一代产品，但每一次的侧重点都将放在不同的阶段上。
2. 初始阶段
初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与 系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段关注的是整个项目的业务 和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。初 始阶段的实现过程如下：
(1)明确项目规模。建立项目的软件规模和边界条件，包括验收标准；了解环境及重要的 需求和约束，识别系统的关键用例。
(2)评估项目风险。软件过程主要关心的是软件开发的已知方面，只能准确描述、计划、 分配和评审那些已经知道将要完成的事情。风险管理则主要关心未知方面。在基于RUP的迭代 式软件过程中，很多决策要受风险决定。要达到这个目的，开发人员需要详细了解项目所面临 的风险，并对如何降低或处理风险有明确的策略。
(3)制订项目计划。估计整个项目的总体成本、进度和人员配备。综合考虑备选架构，评 估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源。在这个过程中，要通过 对一些概念的证实来证明可行性，可以采用可模拟需求的模型形式或用于探索高风险区的初始 原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了，具体实现留到细化阶 段和构建阶段。
(4) 阶段技术评审。初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，
并决定继续进行项目还是取消项目。在评审过程中，需要考虑项目的规模定义、成本和进度估 算是否适中、估算根据是否可靠、需求是否正确、开发方和用户方对软件需求的理解是否达成 一致、是否已经确定所有风险且有针对每个风险的规避策略等问题。
3. 细化阶段
细化阶段的任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素。在细化 阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能和诸如性能等 非功能需求，同时为项目建立支持环境。细化阶段的实现过程如下：
(1)确定架构。确保架构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确 定开发所需的成本和开发进度。通过处理架构中的关键场景，建立一个已确定基线的架构，并 验证其将在适当时间、以合理的成本支持系统需求。
(2)制订构建阶段计划。为构建阶段制订详细的过程计划，并为其建立基线。
(3)建立支持环境。包括开发环境、开发流程、支持构建团队所需的工具和自动化/半自 动化支持。
(4)选择构件。评估现有的构件库和潜在构件，充分了解自制/外购/复用决策，以便有把 握地确定构建阶段的成本和进度。集成所选构件，并按主要场景进行评估。
(5)阶段技术评审。评审时，需要检验详细的系统目标和范围、架构的选择，以及主要风 险的解决方案。
在细化阶段，可执行的原型依赖于项目的范围、规模、风险和先进程度。必须至少处理初 始阶段中识别的关键用例，因为关键用例通常揭示了项目的主要技术风险。
4. 构建阶段
在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详 细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优 化成本、进度和质量。构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开 发成本降到最低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、 场地和用户是否已经为部署软件做好准备。
在构建阶段，开发团队的工作可以实现某种程度的并行。一些项目的规模大得足够产生许 多并行的增量构建过程，即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各 团队之间实现并行开发。这些并行活动在加速版本发布的有效性的同时，也增加了资源管理和 工作流同步的复杂性。
构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行。
5. 移交阶段
当基线已经足够完善，可以安装到最终用户实际环境中时，则进入移交阶段。移交阶段的 重点是确保软件对最终用户是可用的。移交阶段的主要任务是进行β测试，制作产品发布版 本；对最终用户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对
第7章 软件工程 253
当前版本的反馈，基于反馈调整产品，例如，进行调试、性能或可用性的增强等。
移交阶段结束时也要进行技术评审，评审目标是否实现、是否应该开始演化过程、用户对 交付的产品是否满意等。
从本节的介绍可以看出，RUP由于太过庞大和复杂，相对于轻量级的敏捷方法来说，显得 死板和难以实施。RUP 不但不能快速适应需求的变化，而且变更一个需求要经历复杂的过程和 很多额外的工作。对于较小的组织和项目来说，使用敏捷方法可能比较合适，而使用RUP 似乎 有些费力不讨好。
7.2.4 敏捷方法
敏捷方法是从20世纪90年代开始引起广泛关注的一些新型软件开发方法，以应对快速变 化的需求。虽然它们的具体名称、理念、过程、术语都不尽相同，但相对于“非敏捷”而言， 它们更强调开发团队与用户之间的紧密协作、面对面的沟通、频繁交付新的软件版本、紧凑而 自我组织型的团队等，也更注重人的作用。
敏捷宣言
2001年，Kent Beck 等人组织了敏捷联盟，阐述了敏捷开发的原则，试图强调灵活性在快 速且有效地开发软件中所发挥的作用，他们共同签署了敏捷软件开发宣言，该宣言认为，个体 和交互胜过过程和工具；可工作的软件胜过大量的文档；客户合作胜过合同谈判；响应变化胜 过遵循计划。
敏捷方法强调：让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方 法；最小化软件工程工作产品以及整体精简开发。产生这种情况的原因是，在绝大多数软件开 发过程中，提前预测哪些需求是稳定的和哪些需求会变化非常困难；对于软件项目构建来说， 设计和实现是交错的；从制定计划的角度来看，分析、设计、实现和测试并不容易预测；可执 行原型和部分实现的可运行系统是了解用户需求和反馈的有效媒介。
目前，主要的敏捷方法有极限编程 ( eXtreme Programming,XP)、自适应软件开发 (Adaptive Software Development, ASD) 、水晶方法( Crystal) 、特性驱动开发( Feature-Driven Development,FDD) 、 动态系统开发方法(Dynamic Systems Development Method,DSDM)、 测试驱动开发 ( Test-Driven Development,TDD) 、Scrum、敏捷数据库技术( Agile Database Techniques, AD) 和精益软件开发( Lean Software Development) 等。虽然这些过程模型在实践 上有差异，但都遵循敏捷宣言或者敏捷联盟所定义的基本原则。这些原则包括客户参与、增量 式移交、简单性、接受变更、强调开发人员的作用和及时反馈等。
2. 敏捷方法的特点
敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。在敏捷方法中，软件项目的构 建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。在敏捷方 法中，从开发者的角度来看，主要的关注点有短平快的会议、小版本发布、较少的文档、合作 为重、客户直接参与、自动化测试、适应性计划调整和结对编程；从管理者的角度来看，主要 的关注点有测试驱动开发、持续集成和重构。
254 系统分析师教程(第2版)
近年来，虽然敏捷方法发展得较快，但在实施的过程中，也暴露出很多问题，一些敏捷方 法的基本原则很难实施，主要体现在以下4个方面：
(1)客户参与往往依赖于客户参与的意愿和客户自身的代表性。
(2)团队成员的性格可能不适合激烈的投入，可能无法做到与其他成员之间的良好沟通。
(3) 对系统的变更做出优先级排序可能是极端困难的。
(4)维护系统的简洁性往往需要额外的工作，但迫于时间表的压力，可能没有时间执行系 统简化过程。
与RUP 相比，敏捷方法的周期可能更短。敏捷方法在几周或几个月的时间内完成相对较小 的功能，强调的是能尽早将尽量小的可用的功能交付使用，并在整个项目周期中持续改善和增 强，并且更加强调团队中的高度协作。相对而言，敏捷方法主要适用于以下场合：
(1) 项目团队的人数不能太多，适合于规模较小的项目。
(2)项目经常发生变更。敏捷方法适用于需求萌动并且快速改变的情况，如果系统有比较 高的关键性、可靠性、安全性方面的要求，则可能不完全适合。
(3)高风险项目的实施。
(4)从组织结构的角度看，组织结构的文化、人员、沟通性决定了敏捷方法是否适用。与 这些相关联的关键成功因素有组织文化必须支持谈判、人员彼此信任、人少但是精干、开发人 员所做的决定得到认可、环境设施满足团队成员之间快速沟通的需要。
3. 极限编程方法
敏捷方法中最著名的就是极限编程(XP),XP 是一种轻量、高效、低风险、柔性、可预测、 科学且充满乐趣的软件开发方式，适用于小型或中型软件开发团队，并且客户的需求模糊或需 求多变。与其他方法相比，XP 方法最大的不同如下：
(1)在更短的周期内，更早地提供具体、持续的反馈信息。
(2)迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过 程中不断地发展它。
(3)依赖于自动测试程序来监控开发进度，并尽早捕获缺陷。
(4)依赖于口头交流、测试和源程序进行沟通。
(5)倡导持续的演化式的设计。
(6)依赖于开发团队内部的紧密协作。
(7)尽可能达到程序员短期利益和项目长期利益的平衡。
XP由价值观、原则、实践和行为4个部分组成，它们彼此相互依赖、关联，并通过行为 贯穿于整个生命周期。XP 的核心是其总结的四大价值观，即沟通、简单、反馈和勇气。它们是 XP的基础，也是XP 的灵魂。XP 的5个原则是快速反馈、简单性假设、逐步修改、提倡更改 和优质工作。而在XP 方法中，贯彻的是“小步快走”的开发原则，因此工作质量决不可打折 扣，通常采用测试先行的编码方式来提供支持。
4. 动态系统开发方法
动态系统开发方法( DSDM) 倡导以业务为核心，快速而有效地进行系统开发。可以把
第7章 软件工程 255
DSDM看成一种控制框架，其重点在于快速交付并补充如何应用这些控制的指导原则。
DSDM是一整套的方法论，不仅仅包括软件开发内容和实践，也包括了组织结构、项目管 理、估算、工具环境、测试、配置管理、风险管理、重用等各个方面的内容。
DSDM的基本观点
DSDM认为任何事情都不可能一次性圆满完成，应该用20%的时间完成80%的有用功能， 以适合商业目的为准。实施的思路是：在时间进度和可用资源预先固定的情况下，力争最大化 地满足业务需求(传统方法一般是需求固定，时间和资源可变),交付所需要的系统。对于交付 的系统，必须达到足够的稳定程度，以在实际环境中运行；对于业务方面的某些紧急需求，也 必须能够在短时间内得到满足，并在后续迭代阶段对功能进行完善。DSDM的基本原则 DSDM的基本原则包括：
●用户必须参与。
●必须授权DSDM团队进行决策。
●注重频繁交付产品。
●判断产品是否可接受的基本标准是是否符合业务目的。
●对准确的业务解决方案需要采用循环和增量开发。
●开发期间的所有更改都是可逆的。
● 在高层次上制定需求的基线(以在低优先级的项目上获得一定的灵活性)。
● 在整个生命周期集成测试。
●在所有参与者之间采用协作和合作方法。
5.Scrum
Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个 框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint, 每 个 Sprint的建议长度是2～4周。
在Scrum 中，使用产品Backlog 来管理产品的需求，产品Backlog 是一个按照商业价 值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum 团队总是先开发对客户具 有较高价值的需求。在Sprint 中 ，Scrum团队从产品Backlog 中挑选最高优先级的需求进行 开发。
挑选的需求在Sprint 计划会议上经过讨论、分析和估算得到相应的任务列表，称为Sprint Backlog。在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。Scrum起源于软件开 发项目，但它适用于任何复杂的或创新性的项目。
