服装行业软件工程新技术

尽管软件工程技术的发展日新月异，但万变不离其宗。在其它相关文章中都有讲内容是软件工程的核心所在，试图跳过软件工程的传统内容而去专注于某种新技术是行之不通的；而忽略新技术，坚持传统思维的做法会导致我们在软件工程的大军中落伍。本章论述几种服装行业软件工程新技术，其中包括：形式化方法、净室软件工程、软件复用与再工程、基于构件的软件开发、敏捷软件开发等。有些技术的提出已有几十年的历史，但其发展成熟并获得应用还是近几年的事情。
教学要求：
①理解形式化方法的背景知识及其规格说明语言。
②理解净室软件工程的基本原理与特点。
③理解基于构件的软件工程基本概念及其特征。
④了解软件复用与再工程的基本概念与过程。
⑤了解敏捷软件开发的价值观及其指导原则。

重点和难点：
①形式化规格说明语言的构成与使用。
②净室软件开发的过程模型。
③基于构件的软件开发过程模型及构件库的建立与使用。
④业务过程再工程与软件再工程的过程模型。
⑤xP极限编程的有效实践及其他几种典型的敏捷过程模型。

12．1．1形式化方法的引入

1．背景

以服装行业软件为例，用于开发软件系统的形式化方法是用基于数学的法则来描述系统的性质，这种形式化方法为我们提供了～个框架，借此框架可对软件系统进行描述、开发和验证。按软件百科全书中的定义，如果一个方法具有良好的数学基础，特别是以形式化说明语言描述的，那么就可称之为形式化的。这种数学基础提供了一致性和完整性等概念的表示方法，更进一步的是用其来定义规格说明、实现过程及其正确性。形式化规格说明所希望的性质包括无二义性、一致性和完整性，这也是所有规格说明方法的目标所在。在规格说明语言中采用形式化语法，使得软件的需求或设计只能以唯一的方式被解释，从而排除了在传统的软件工程方法中采用自然语言或图形符号时经常产生的二义性问题。例如，形式化方法中采用了集合论和逻辑符号的描述机制使得我们可以清晰地描述事实。为了保持前后一致，在规格说明中某处所描述的事实不能与其他地方产生矛盾，其一致性是通过使用推理规则将初始事实以形式化方式映射到其后的规格说明中来加以保证的。

2．非形式化方法的不足

在前几章的讨论中，我们采用自然语言和图形符号进行系统的描述、分析和设计。当然，只要我们认真、细致地采用这些方法并结合严格的复审，也可以进行高质量软件的开发，但是，这些方法在应用上的失误或偏差可能导致各种各样的问题。例如，对系统规格说明中可能包含的矛盾性、二义性、含糊性、不完整性以及抽象层次的混杂性等问题难以对付。以上这些问题又极为常见，每个问题都展示了传统的和面向对象的规格说明方法的潜在不足。

3．形式化方法的优点

如前所述，形式化方法是以严格的数学方式对软件的规格说明进行描述。数学模型对于大型的复杂系统的开发来说有许多有用性质，其中最有用的性质之一是它能够以简洁而准确地方式描述物理现象、动作对象及其结果。另一个优点是它提供了诸多软件工程活动之间的平滑过渡。不仅功能规格说明，而且系统设计也可以用数学方式加以表达。当然，程序代码本身就是数学符号的有序组合。数学的主要性质是它支持抽象，而且是非常优秀的建模手段。因为数学模型的准确性和无二义性，软件的规格说明可以被形式化地加以验证，以揭示其内隐含的矛盾性和不完整性，含糊性问题也完全得以解决。此外，采用数学模型可以严格的、有组织的表示系统规格说明中的抽象层次。数学作为软件开发工具的最后一个优点是，它提供了高层验证的手段，即可以使用数学证明的方式来验证系统设计是否符合规格说明的需求以及验证程序代码是否符合系统设计的要求。

12．1．2形式化规格说明语言

支配形式化方法的基本概念是数据不变式(一个条件表达式，它在包含一组数据的系统的执行过程中总保持为真)、状态(是从系统的外部能够观察到的行为模式的一种表示，或者是系统访问和修改的存储数据)和操作(系统中发生的动作，以及对状态数据的读写操作。每一个操作与两个条件相关联，即：前置条件和后置条件)。离散数学中的集合论和构造性规格说明、集合运算符、逻辑运算符以及与序列相关的表示法构成了形式化方法的理论基础。为了有效地应用形式化方法，软件工程师必须具备集合论以及有关谓词逻辑演算的基本知识。形式化规格说明语言就是应用数学法则来对软件的规格说明进行形式化描述的语言。它通常由以下三部分构成：
·语法域：定义用于表示规格说明的特定表示方法；
·语义域；定义用于描述系统的对象及其动作序列的集合；
·关系域：用于确定哪个对象真正满足规格说明的准则。

形式化规格说明语言的语法域通常基于从标准集合论符号和谓词逻辑演算导出的语法。例如，可用变量X，Y，z来描述一组和问题论域相关的对象，并与相关的运算符一起使用。虽然语法通常是符号化的，但诸如方框、箭头和圆圈等图形符号如果没有二义性也可加以使用。规格说明语言的语义域指明采用语言如何表示系统的需求。例如，程序设计语言采用一组形式化语义使得软件开发者可以刻画输入到输出的转换算法。形式化文法(如BNF范式)可以用于描述程序设计语言的语法。然而，程序设计语言只能表示计算功能，所以它并不是好的规格说明语言。规格说明语言必须要有更广的语义域。就是说，规格说明语言的语义域必须能够表达这样的概念：“对在无限集彳中的所有X，在无限集B中有某Y，使得性质P对X和Y成立”。规格说明语言的应用范围还包括描述系统行为的语义。例如，可以设计一种语法和语义来描述状态和状态转换、事件以及它们对状态转换的影响、同步及定时等要求。在形式化方法中，用不同的语义抽象及不同的方式来描述同一个系统是可能的，即：采用不同的建模表示符号可以用来表示相同的系统，每种表示方法的语义提供了对系统视图的互补展现。

当前已开发了多种形式规格说明语言。较为流行的有对象约束语言(obiectconstraintlanguage，OCL)及z语言。OCL可使UML的拥戴者向他们的规格说明中加入更精确的内容。OCL具有逻辑代数及离散数学的所有优势。在OCL中只能使用ASCII字符，而不能使用传统的数学表示法，这使得OCL更适合于那些不太喜欢数学的软件开发者。对喜欢数学及严谨作风的开发者建议学习使用z语言。z语言是在过去20年里发展起来的规格说明语言，它已在形式化方法领域中广泛使用。z语言在一阶谓词逻辑中采用类型集合、关系及函数来构造其“合子”Schema(一种构造形式化规格说明的工具)。OCL及z这两种语言都具有前述形式化规格描述语言的基本特征，并具有代表性，在此不再赘述。

12．1．3形式化方法的十条戒律
形式化方法并非是解决所有软件工程实际问题的灵丹妙药，可以信手拈来。在现实世界中做出使用形式化方法的决策并非易事，软件工程专家Bowen和Hinchley总结出“形式化方法的十条戒律”作为对那些希望应用这个重要的软件工程方法的人们的行动指南：
·应该选择适当的表示方法。
·应该形式化，但不要过分形式化。
·应该估计成本。
·应该有随时可以请教的形式化方法顾问。
·不应该放弃传统的开发方法。
·应该建立详尽的文档。
·不应该对质量标准打任何折扣。
·不应该教条化。
·应该测试、测试、再测试。
·应该采用软件复用技术。

12．2净室软件工程
净室软件工程(cleanroomsoftwareengineering，CRSE)是一种在软件开发过程中强调建立正确性需求以代替传统的分析、设计、编码、测试和调试周期的软件工程方法。CRSE实质上是这样一个过程模型，在代码增量积聚到系统的同时进行代码增量的统计质量验证。采用CRSE方法使我们在软件开发过程中，在产生严重的错误之前将其消除在萌芽状态。

12．2．1净室方法的引入
净室基础理论建立于20世纪70年代末80年代初。资深数学家和mM客座科学家HarlanMills阐述了将数学、统计学及工程学上的基本概念应用到软件工程领域的设想，从而为CRSE方法学奠定了科学基础。CRSE综合了DijEstra的结构化编程、Wjnb的逐步求精法以及Pamas模块化程序设计的某些思想。净室软件工程遵循的基本原则是：在第一次正确地书写代码增量并在测试以前验证它们的正确性，借此来避免对高成本的软件维护及纠错过程的依赖。其过程模型是在代码增量聚集到系统过程的同时进行代码增量的统计质量检验。12-2-2净室过程模型
净室方法实质上是增量式软件过程模型的一个变种。一个“软件增量的流水线”由若干小的、独立的软件团队开发。每当一个软件增量通过认证，它就被集成到整体系统中。因此，系统的功能随时间而增加。净室过程模型如图12．1所示，其中每个增量的任务序列包括以下九项任务：

1．增量策划
制定一个采用增量策略的项Et计划，确定每个增量的功能、预计规模以及净室开发进度表。
2．需求收集
为每个增量编制一个更为详细的客户级需求描述。
3．盒结构规格说明
使用盒式结构的规格说明来进行分析和设计建模。一个“盒结构”或称“盒子”在某个细节层次上封装系统。通过逐步求精的过程，盒子被细化为层次，其中每个盒子具有引用的透明性。这使得分析员能够分层次地划分一个系统，从顶层的本质表示开始转向底层的特定实现细节中，从而进行形式化设计。
4．形式化设计
通过使用盒结构方法，净室设计就成为规格说明的自然、无缝的扩展。虽然可以清楚地区分两个活动，但是对规格说明(称为“黑盒”)在一个增量内进行迭代求精仍然类似于体系结构设计和构件级设计(分别称为“状态盒”和“清晰盒”)。黑盒刻画系统行为或系统部件的行为，状态盒以类似于对象的方式封装状态数据和操作，清晰盒包含了对状态盒的过程设计。
5．正确性验证
通过使用盒结构的规格说明进行分析和设计建模，CRSE强调将正确性验证(而不是测试)作为发现和消除错误的主要机制。净室团队对设计及代码进行一系列严格的正确性验证活动。验证从最高层次的盒结构(即：规格说明)开始，然后移向设计细节和代码。正确性验证的第一层次通过应用一组“基准问题”来进行，如果这些不能证明规格说明的'正确性，则使用更形式化的数学验证手段。
6．代码生成、检查和验证
首先，将某种专门语言表示的盒结构规格说明翻译为适当的程序设计语言。其次，使用标准的查找技术来保证代码和盒结构语义的相符性以及代码语法的正确性。最后，对源代码进行正确性验证。CRSE的真正特性是对软件工程模型运用了形式化的验证手段。
7．统计测试的规划
分析软件的预计使用情况，规划并设计一组测试用例，以测试使用情况的“概率分布”。
8．使用统计测试
由于对软件进行穷举测试是不可能的，因此，要设计有限数量的测试用例。使用统计技术执行由统计样本获得的概率分布而来导出的一系列测试。这里的统计样本是从来自目标人群的所有用户对程序的所有可能执行中抽取的。
9．认证
一旦完成验证、检查和使用测试，并且纠正了所有的错误，则开始对过程增量进行集成前的认证工作。

12．2．3净室软件工程的特点
结合具有良好定义的持续过程改进策略，净室软件工程CRSE第一次尝试将软件开发过程置于统计质量检验的控制之下。为了达到这个目标，定义了一个独特的净室生命周期，它着重于以正确地进行软件设计为目标的基于数学的软件工程方法学和以软件可靠性认证为目标的基于统计理论的软件测试。CRSE与常规软件工程的差别在于：它不再强调单元测试和调试的作用，从而大量地减少了由软件开发者所承担的测试工作量。CRSE与本书前几章讨论的传统的和面向对象的软件工程相比，具有三个明显的特点：
·CRSE明确地使用了统计质量控制。
·CRSE使用基于数学的正确性证明来验证设计规格说明。
·CRSE实现了一些最有可能揭示出具有严重错误的测试技术。

12．3基于构件的软件工程
软件工程领域的学者和开发者早就设想软件系统的开发可否像机器的建造那样实现零配件的组装化工艺，使软件类似于硬件一样，可用不同的标准构件拼装而成。就是说，可否提供一种手段，使应用软件可用预先编好的、功能明确的产品部件定制而成，并可用不同版本的部件实现应用的扩展和更新。在另一方面，对老的遗留系统，可否利用模块化方法，将复杂的难以维护的系统分解为互相独立、协同工作的部件，并使这些部件可反复重用。为应对这样的挑战与要求，软件构件技术应运而生。使用构件的主要目标是达到需求、分析、设计、编码、测试的复用。基于构件的软件开发(component．basedsoftwaredevelopment，CBSD)方法的诞生标志着一个软件过程新时代的来临。至今，构件技术已形成三个主要流派：Sun公司的EJB平台、Microsoft的COM+技术、ⅢM的CORBA架构。

12．3．1基本概念
软件构件(softwarecomponent)是软件系统内可标识的、符合某种标准要求的构成成分，类似于传统工业中的零部件。广义上讲，构件可以是需求分析、设计、代码、测试用例、文档或软件开发过程中的其他产品。狭义来说，构件是指能对外提供一组规范化接口的、符合一定标准的、可替换的软件系统的程序模块。构件亦可简单地表述为：构件是可复用的软件组成成分，它可被用来构造其他软件。构件可分为构件类和构件实例，通过给出构件类的参数而生成实例，再通过实例的组装和控制来构造相应的应用软件。
构件技术与传统的面向对象技术紧密相关。构件和对象都是对现实世界的抽象描述，通过接口封装了可复用的代码实现。两者的不同之处在于：首先在概念层面上，对象描述客观世界实体，而构件则提供客观世界服务；其次在复用策略上，对象是通过继承实现复用，而构件是通过合成实现复用；最后在技术手段上，构件通过对象技术而实现，对象按规定经过适当的接口包装之后成为构件，而一个构件通常是多个对象的集合体。构件技术是对象技术的发展，构件具有更强的独立性、封闭性和可复用性。软件构件技术目前主要的研究内容包括：构件获取、构件模型、构件描述语言、构件分类与检索、构件组装以及构件标准化等问题。

12．3．2基于构件的软件工程
基于构件的软件工程(component-basedsoftwareengineering，CBSE)和基于构件的开发(component—baseddevelopment，CBD)是一种软件开发的新范型。它是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。
CBSE／CBD的工程学目标包括：降低费用、方便装配、提高复用性、提高可定制性和适应性、提高可维护性。CBSE／CBD的技术目标是：降低构件之间的耦合度、提高构件内诸元素之间内聚、控制构件的规模。
CBSE强调使用可复用的软件构件来设计和改造基于计算机的系统。构件复用是指充分利用过去软件开发过程中积累的成果、知识和经验，去开发新的软件系统，使人们在新系统的开发中着重于解决出现的新问题、满足新需求，从而避免或减少软件开发中的重复劳动。由此产生的问题是：可否通过组装一组可复用的构件来构造复杂的系统?能否以需用者易于访问的方式建造复用所必需的构件库?构件库中存在的构件能否被需用者容易的找到?这些都是CBSE和CBD所要解决的问题。
图12—2给出了一个典型的CBSE过程模型。其中，领域工程的目的是标识、构造、分类和传播一些软件构件，这些构件将适用于某特定应用领域中现有的和未来的软件系统。领域工程的总体目标是建立相应的机制，使得软件工程师在开发新系统或改造老系统时可以共享这些构件，即：复用它们。领域工程包括三个主要的活动：分析、构造和传播。基于构件的开发CBD是一个与领域活动并行的CBSE活动。一旦建立了体系结构，就必须向其中增加构件，这些构件可从复用库中获得，或者根据特定需要而开发。因此，CBD的任务流有两条路径，当可复用构件有可能被集成到体系结构中时，必须对它们进行合格性检验和适应性修改。当需要新的构件时，则必须重新开发。构件组装的任务是将经过合格性检验的、适应性修改的以及新开发的构件组装到为应用建立的体系结构中，最后再进行全面的测试。

12．3．3构件库的建立与使用
CBSE／CBD是以构件库为中心的开发模型，构件库是领域工程和应用工程两个开发过程的桥梁和纽带。构件库系统当然也是一类数据库管理系统，它具备数据库的基本特征和功能。为了向基于构件的应用系统开发者提供所必需的构件，构件库管理系统必须能够存储构件以及相关的信息，如：构件的语义描述、构件的分类、构件的形态、构件的状态。为了能够有效地实施管理和维护，构件库管理系统还必须能够提供如下的操作：构件的添加、构件的检索以及其他管理手段，如构件的删除、备份、用户登记和存取控制等。对构件分类和检索机制的研究一直是构件库研究的热点，目前已有很多方法。从构件表示出发可以分为人工智能方法、超文本方法和信息科学方法三类；而根据复杂度和检索效果的不同则可以分为基于文本的、基于词法描述子的和基于规格说明的编码和检索。
构件化的软件生产亦可在所谓的“软件工厂”内实现，其核心是在一个开发平台上通过预制和定制多个软件构件，依托构件库及相关工具平台，像工业生产零配件一样根据开发目的的要求来组织构件的开发与生产，并进行工业式的组装与协作，以规模化的方式批量生产软件构件。或者说，软件工厂是按照流水线的工作方式，遵循一定的生产质量规范，批量、高效的生产标准化的“软件零部件”(即：软件构件)，并对其进行组装从而批量完成软件产品或应用的机构。软件工厂的出现使得软件开发商通过可重复的开发过程快速高效的生产出成本低、质量好的企业级软件，使得软件生产更加条理化和系统化。项目实施人员可以对零配件、中间件或模块进行自由组合，从而解决了用户需求不确定性问题。软件工厂能够最大限度地利用已有资源，是系统化实现软件复用的有效方式。

12．4软件复用与再工程
软件复用的出发点是应用系统的开发不再采用一切“从零开始”的模式，而是以已有的工作或称遗留资产软件作为基础，充分利用过去应用系统开发中积累的知识和经验，将开发的重点集中于应用特定的软件构件。实现软件复用的关键因素主要包括：软件构件技术(sottwarecomponenttechnology)、领域工程(domainengineering)、软件构架(softwarearchitecture)、软件再工程(softwarereengineering)。软件再工程是指对既有的软件系统进行调查，并二次开发的过程，其目的是重新审视现有的系统，以便进一步利用新技术来改善系统或促进现存系统的再利用。

12．4．1基本概念
软件复用是在软件开发中避免重复劳动的解决方案。通过软件复用，在应用系统开发中可以充分利用已有的开发成果，消除重复劳动，避免重新开发可能引入的错误，从而提高软件开发的效率和质量。软件复用包括两个相关的过程：可复用软件构件的开发(developmentforreuse)和基于可复用软件构件的应用系统构造(developmentwithreuse)，也就是应用系统的集成和组装。
软件复用可以从多个角度进行考察。依据复用的对象，可以将软件复用分为产品复用和过程复用。产品复用指复用已有的软件构件，通过构件的集成或组装得到新的系统。过程复用指复用已有的软件开发过程，借助应用生成器来自动或半自动地生成所需系统。产品复用在目前较为流行。过程复用依赖于软件自动化技术的发展，目前只适用于一些特殊的应用领域。依据对可复用信息进行复用的方式，可以将软件复用分为黑盒(blackbox)复用和白盒(whitebox)复用。黑盒复用指对已有构件不需做任何修改，直接进行复用，这是理想的复用方式。白盒复用指已有构件并不能完全符合用户需求，需要根据用户需求进行适应性修改后才可使用。在大多数应用系统的组装过程中，构件的适应性修改是必需的。
软件再工程是解决软件复用问题的主要技术手段。软件再工程是一个工程过程，它将逆向工程、代码重构与正向工程组合起来，将现存系统重新构造为新的应用形式。再工程的基础是系统理解，包括对运行系统、源代码、设计、分析、文档等的全面理解。但在很多情况下，由于各类文档的丢失，只能对源代码进行理解，即程序进行理解。软件再工程发生在两个不同的抽象层次：在业务层次，再工程着重于业务过程，企图改变业务过程以改善在某个业务领域的竞争力；在软件层次，再工程检查信息系统和应用，企图重构它们以使其展示更高的质量。

12．4．2业务过程再工程
业务过程再工程(businessprocessreengineering，BPR)其实己超出了信息技术和软件工程的范畴。BPR的一个抽象定义是“搜寻并实现业务过程中的根本性改变以达到突破性成果”。但是，如何执行搜寻?如何完成实现?更重要的是，如何能够保证所提出的“根本性改变”将导致事实上的“突破性成果”而又不会造成组织上的混乱?这些问题远未得到解决。
我们首先从业务过程谈起。一个业务过程是指通过执行一组逻辑上相关联的任务以达到预定的业务结果。在业务过程中，将人、设备、材料资源以及业务规程被组合在一起，以期产生特定的结果。每种业务过程都包含一组任务及一个特定的客户，即：接收过程结果的人或小组。此外，业务过程跨越组织边界，需要来自不同开发团体的小组共同参与定义一个过程的“逻辑相关的任务”。
业务过程再工程是迭代式的工程过程，没有开始和结束，因为它是一个演化循环的过程。图12．3描述了一个业务过程再工程模型，该模型定义了6项关键活动：

·业务定义：在4个关键驱动因素(减少成本、减少时间、改善质量，人力开发及授权)的范围内定义业务目标。
·过程标识：对那些能够达到业务目标的关键过程进行识别，然后可以根据其重要性等指标对这些关键过程进行优先级排序。
·过程评估：彻底分析和测量现有的过程。确定过程任务、说明过程任务花费的成本和时间，并且明确质量与性能要求。
·过程规格说明和设计：基于上述三个BPR活动中所获得的信息，为每个将被重新设计的过程准备用例(usecases)。在BPR的范畴内，用例标识了将某些结果传递给客户的一种场景。将用例作为过程的规格说明，为该过程设计一组新任务。
·原型开发：在一个重新设计的业务过程被完全地集成到整体业务之前，必须将其原型化。该活动对重新设计的业务过程进行测试，通过测试后再进行下一步的求精工作。
·求精及实例化：基于来自原型的反馈信息，精化业务过程，然后在业务系统中加以具体实现。

12．4．3软件再工程

不可维护的软件是一个老生常谈的问题。对软件再工程的重视源于30多年不断形成的软件维护“冰山(iceberg)”。之所以软件维护被刻画为“冰山”，是因为以老套模式开发的软件系统随着业务变化及硬件档次的提高不可避免地存在软件维护与更新问题。在正常运行的系统表面之下存在大量潜在的问题和维护成本。据估计对现存软件的维护可能占据软件开发机构所有花费的60％以上，而且随着更多的软件被生产出来，这个百分比还在继续攀升。软件维护并不仅仅是“修正错误”，它通常包括这样4类活动：纠错性维护、适应性维护、完善性维护或预防性维护或再工程。所有维护工作中仅仅大约20％花费于“修正错误”。其余的80％主要花费于修正现有系统以适应外部环境的改变、根据用户要求进行功能的增强以及为了未来的使用所进行的软件再工程。如图12．4所示的是软件再工程过程模型，它是一个循环模型，定义了6类活动：

1．文档目录分析(inventoryanalysis)
该目录可能仅仅是一个电子表格，其中为每一个现行应用系统的规模、年限、业务重要程度等提供了详细的描述
2．文档重构(documentrestructuring)
有下列三种选择：选项1)：如果系统正常运作，我们将保持现状，因为建立文档非常耗时。选项2)：若文档必须更新，但我们的资源很有限，此时将采用“使用时建档”的方法。选项3)：若系统是业务关键的，则必须完全地重构文档。
3．逆向工程(reverseengineering)
软件的逆向工程是通过分析源程序、在高于源代码的抽象层次上再次表示程序的过程。实质上，它是一种设计恢复过程，借助于逆向工程工具从现有的程序中抽取数据、体系结构和过程的设计信息。
4．代码重构(coderestructuring)
最常见的再工程类型是代码重构。某些遗产系统具有相对可靠的程序体系结构。但是，个别模块的编码方式使得程序难以理解、测试和维护。在这样的情形下，可以对可疑模块内的代码进行重构。为了完成该项活动，用重构工具去分析源代码，将与结构化程序设计概念相违背的部分标注出来，然后对代码进行重构。对生成的程序代码再进行评审和测试，以确保没有引入不规则的代码，并更新内部的代码文档。5．数据重构(datarestructuring)
数据体系结构差的程序将难于进行适应性修改和增强。在大多数情况下，数据重构开始于逆向工程活动，它包括对当前的数据体系结构进行分解，并定义必要的数据模型、标识数据的对象和属性，并对现有的数据结构进行质量评审。
6．正向工程(forwardengineenng)
正向工程也称为革新或改造，不仅能够从现有软件恢复出设计信息，而且还能够使用这些信息去改变或重构现有系统，以改善整体质量。在大多数情况，实施了再工程的软件可以重新实现现有系统的功能，并且还能够加入新的功能或改善整体性能。在理想的情况，可以使用自动化的“再工程引擎”来重建应用系统。

12．5敏捷软件过程
敏捷一词有轻巧、机敏、迅捷、灵活、活力、高效等含义。2001年，17位软件开发方法学家齐聚～堂，将各自的开发方法学进行了汇总，并共同定义了术语敏捷(Agile)。会议最终制定了敏捷软件开发宣言(ManifestoforAgileSoftwareDevelopment)，并确立了一系列敏捷开发方法的价值观念和实用原则。敏捷软件开发涵盖了众多的开发方法，其中包括极限编程XP、自适应软件开发ASD、水晶方法族CrysmlMethods、动态系统开发方法DSDM、特征驱动的开发FDD以及SCRUM方法等等。本节对此进行简单介绍。

12．5．1基本概念
敏捷可以看做是对变化中的和不确定的周边环境所作出的一种适时反应。对于软件业来说，变化和不确定性是最令人烦恼的词汇。软件工程自诞生以来，一直试图通过技术和管理手段来降低软件项目的不确定性。人们先后发明了结构化程序设计方法、面向对象的方法学以及CMM／CMMI模型等。这些新的技术和方法确实有助于化解“软件危机”所带来的负面效应，也促进了软件业的发展。然而，软件开发越来越复杂，越来越庞大，这些传统的重量级(heavyweight)方法的副作用，如组织臃肿、办事低效、官僚主义等也越来越明显。
相对于重量级方法，软件业一直存在另一种声音，那就是轻量级(1ightweight)方法，其目标是以较小的代价获得与重量级相当的效果。最负盛名的轻量级方法是所谓的极限编程XP。XP是ExtremeProgramming的缩写，从字面上可以译为极端编程或极限编程。但xP并不仅仅是一种编程方法，也不是照中文字面理解的那种不可理喻的“极端”化做法。实际上，XP是一种审慎的(deliberate)、有纪律(disciplined)的软件生产方法。XP植根于20世纪80年代后期的Smalltalk社区。90年代，KentBeck和wardCunningham把他们使用Smalltalk开发软件的项目经验进行了总结和扩展，逐步形成了一种强调适应性和以人为导向的软件开发方法。

12．5．2敏捷软件开发方法的指导原则
敏捷软件开发(agilesoftwaredevelopmentmethods，ASDM)不是一个具体的过程，而是一个涵盖性术语。ASDM用于概括具有类似基础的软件开发方式和方法，其中包括极限编程XP、自适应软件开发、水晶方法族、动态系统开发方法、特征驱动的开发以及SCRUM等方法。敏捷开发团队及其成员必须具备下列特点：基本的软件相关技能；对所选敏捷过程的全局知识：共同目标；精诚合作；对不确定问题的决断能力；相互信任和尊重；自我组织能力。为了支持软件开发团体实施敏捷开发方法，敏捷联盟提出了“四个价值观”和“十二个指导原则”。

ASDM方法的四个价值观如下：
1．人及其相互作用要比过程和工具更值得关注。
2．可运行的软件要比无所不及的各类文档更值得关注。
3．与客户合作要比合同谈判更值得关注。
4．响应需求变化要比按计划行事更值得关注。

ASDM方法的指导原贝,OPn下：
1．在快速不断地交付用户可运行软件的过程中，将用户的满意放在第一位。
2．以积极的态度对待需求的变化，不管该变化出现在开发早期还是后期。敏捷过程紧密围绕变化展开并利用变化来实现客户的竞争优势。
3．以几周到几个月为周期，尽快、不断地交付可运行的软件供用户使用。
4．在项目过程中，业务人员和开发人员最好能一起工作。
5．以积极向上的员工为中心建立项目组，给予他们所需的环境和支持，对他们的工作予以充分的信任。
6．在项目组中，最有用、最有效的信息沟通手段是面对面的交谈。
7．项目进度度量的首要依据是可运行的软件。
8．敏捷过程高度重视可持续开发。项目发起者、开发者和用户应始终保持步调一致。
9．应时刻关注技术上的精益求精和设计上的合理，这样才能提高软件的快速应变能力。
10．尽可能减少不必要的工作，实现简单化。
11．最好的框架结构、需求和设计产生于有自我组织能力的项目组。
12．项目组要定期对其运作方面进行反思，提出改进意见，并进行相应的细调。

此外，敏捷方法实施中一般采用面向对象技术或其他接口定义良好的开发技术。另外它还强调在开发中要有足够的工具，如配置管理工具、建模工具等的支持。

12．5．3典型的敏捷过程模型

1．极限编程XP
XP是一组简单、具体的实践，这些实践结合形成了一个敏捷开发过程。XP是一种优良的j通用的软件开发方法，项目团队可以拿来直接采用，也可以增加一些实践，或者对其中的一些实践进行修改后再加以采用。XP始于五条基本价值观：交流(communication)，反馈(feedback)，简洁(simplicity)，勇气(courage)和尊重(respect)。在此基础上，XP总结出了软件开发的十余条做法或实践，它们涉及到软件的设计、测试、编码、发布等各个环节。XP过程的关键活动包括：过程策划、原型设计、编码及测试。与其他ASDM轻量级方法相比，XP独一无二地突出了测试的重要性，甚至将测试作为整个开发的基础。每个开发人员不仅要书写软件产品的代码，同时也必须书写相应的测试代码。所有这些代码通过持续性的构建和集成可为下一步的开发打下一个稳定的基础平台。XP的设计理念是在每次迭代周期仅仅设计本次迭代所要求的产品功能，上次迭代周期中的设计通过再造过程形成本次的设计。
2．自适应软件开发(adaptivesoftwaredevelopment，ASD)
ASD由JimHighsmith在1999年正式提出。ASD强调开发方法的自适应(Adaptive)，这一思想来源于复杂系统的混沌理论。ASD不像其他方法那样有很多具体的实践做法，它更侧重为ASD的重要性提供最根本的基础，并从更高的组织和管理层饮来阐述开发方法为什么要具备适应性。ASD自适应软件开发过程的生命周期包括三个阶段：思考(自适应循环策划及发布时间计划)、协作(需求获取及规格说明)、学习(构件实现、测试及事后剖析)。
3．水晶方法族(crystalmethods，CM)
CM由AlistairCockburn在20世纪90年代末提出。之所以是个系列，是因为他相信不同类型的项目需要不同的方法。它们包含具有共性的核心元素、每一个都含有独特的角色、过程模式、工作产品和实践。虽然水晶系列不如XP有那样好的生产效率，但会有更多的人接受并遵循它的过程原则。
4．动态系统开发方法(dynamicsystemdevelopmentmethod，DSDM)
DSDM倡导以业务为核心，快速而有效地进行系统开发。实践证明，DSDM是成功的敏捷开发方法之一。在英国，由于DSDM在各种规模的软件开发团体中的成功，它已成为应用最为广泛的快速应用开发方法。DSDM不但遵循了敏捷方法的原理，而且也适合于那些坚持成熟的传统开发方法又具有坚实基础的软件开发团体。DSDM的生命周期包括：可行性研究、业务研究、功能模型迭代、设计和构建迭代、实现迭代。
5．特征驱动的开发(featuredrivendevelopment，FDD)
FDD由PeterCoad、JeffdeLuca、EricLefebvre共同提出，是一套针对中小型软件开发项目的开发模式。此外，FDD是一个模型驱动的快速迭代开发过程，它强调的是简化、实用。FDD易于被开发团队接受，适用于需求经常变动的项目。FDD方法定义了五个过程活动：开发全局模型、改造特征列表、特征计划编制、特征设计与特征构建。
6．SCRUM方法
SCRUM是一种迭代的增量化过程，用于产品开发或工作管理。它是一种可以集合各种开发实践的经验化过程框架。在SCRUM中，把发布产品的重要性看做高于一切。该方法由KenSchwaber和JeffSutherland提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进。SCRUM过程流包括：产品待定项、冲刺待定项、待定项的展开与执行、每日15分钟例会、冲刺结束时对新功能的演示。

本章小结
本章论述了形式化方法、净室软件工程、软件复用与再工程、基于构件的软件开发、敏捷软件开发等几种软件工程的新技术，它们是目前服装行业软件工程学术界研究的热点。
使用形式化方法所生成的分析模型比用传统的或面向对象的方法生成的模型更加完整、一致和无歧义。采用集合论和逻辑符号使得软件工程师能创建关于事实或需求的清晰描述。使用形式化方法必须考虑启动成本以及与之相关的连锁式变更后果。在大多数情况下，形式化方法对安全关键和业务关键的系统具有最高的回报率。净室软件工程CRSE是软件开发的一种形式化方法，它强调将正确性验证，而不是测试作为发现和消除错误的主要机制。
基于构件的软件开发CBSD模式支持当今流行的分布式计算、浏览器／服务器结构、模块化及子系统的集成，使软件类似于硬件一样，可用不同的标准构件拼装而成。完整的软件构件隐藏了具体的实现细节，它只通过接口对外提供服务。这样在不同的层次上，可将底层的多个构件按逻辑关系组合成高层次上的粒度更大的新构件，甚至直接封装到一个新的系统中，使模块的复用从代码级、对象级、架构级到系统级均可加以实现，从而使软件系统像硬件系统一样，能任人装配定制而成。
软件复用是以现有的工作为基础，充分利用过去应用系统开发中积累的知识和经验，将开发的重点集中于应用已有的软件构件。通过软件复用，可以消除重复劳动、避免重新开发可能引入的错误，从而提高了软件开发的效率和质量。软件再工程是实现软件复用的有效途径。软件再工程发生在两个不同的抽象层次。在业务层次，再工程着重于业务过程，其目的是改善业务过程，提高竞争力；在软件层次，再工程通过对信息系统和应用系统进行一系列的检查，其目的是对它们进行重构以提高软件质量。
敏捷软件过程强调对事物变化的适应，而非预测。敏捷方法以人为中心，而非以流程或事物为中心。简言之，敏捷过程更加强调对变化的适应和对人性的关注。敏捷方法能够在保证软件开发可以取得成功的大前提下，尽量减少开发过程中的活动和“半成品”，从而在满足所需的软件质量要求的前提下，力求提高软件开发的效率。最具代表性的敏捷方法当属xP方法，它提倡测试先行。除了XP以外，其他知名的敏捷过程包括：自适应软件开发、水晶方法族、动态系统开发方法、特征驱动的开发以及SCRUM等方法。