管理业务流程集成项目的基本原则（转与Rational Edge）

Bill Higgins, Architect, Systems Engineering and Architecture, IBM Global Services 2005 年 10 月 19 日 来自于 Rational Edge：复杂的业务流程集成（BPI）项目是非常具有挑战性的，这是因为不同的部门可能会遵循不同的开发过程，并使用不同的开发技术和工具。本文建议管理这种项目的技术应该按照三个方面来进行：组织过程和工具，组织结构，以及需求和变更管理过程。 现代企业的一个核心目标就是整合跨公司和关键合作伙伴、供应商以及顾客。 1 将他们的业务过程端到端地集成在一起。企业级IT组织通过将支持业务流程集成（BPI）项目的软件应用程序过程集成起来，来完成此目标。这样的项目是非常具有挑战性的，这是因为不同的部门可能遵循不同的开发过程，并且使用不同的开发技术和工具。那些找到优化其BPI项目方法的企业会在市场上获得巨大的优势：他们可以更快速和更有效地响应正在浮现的市场机会和竞争威胁。本文主要讨论你的开发组织可以使用的一些基本原则和技术，应用这些原则和技术将会有助于更有效地执行BPI项目。 首先，我们来分析一下一个BPI项目的特点。然后，我们将从如下三个方面来描述基本规则和技术： 组织过程和工具 组织结构 需求和变更管理过程 我们将在后面分别加以讨论。 术语： 在整篇文章中，我将会使用很多术语，这些术语同它们在文学作品中的意思相去甚远。下面的定义解释了在上下文中它们的具体含义。如果在统一建模语言（UML）中有类似的术语，我已经将其在圆括号中标注出来。 2 业务流程集成项目――一个业务转换项目，涉及到多个业务流程领域，多个独立团队，以及许多个应用软件。 超系统――在一个业务流程集成项目的开发和测试中所涉及到的所有应用软件的一整套系统。（UML2：系统） 子系统：――在超系统中被视作一个单元的相关业务应用软件集。一个子系统是一个开发部分，它应该在超系统范围定义、架构以及变更管理活动中进行描述。（UML2：子系统） 应用软件：――一个不同的开发团队的软件功能的一个单元。在一个集成信息技术环境中，一个用户可能并没有意识到某个特定的事务或工作流程中所涉及到的彼此独立的应用软件（因为点击一下超链接，用户便可能无缝地跨过不同应用软件之间的边界）。（UML2：子系统） BPI项目的特点： 在大型企业中，业务流程重构工作是一项非常复杂的项目，可能要花费数年，并涉及到众多的人力和信息技术系统。典型的BPI项目包括连接、简化和组织一个大规模的业务流程及其支持应用软件。 要想理解以下所描述的能够提高这种项目成功可能性的技术，重要的是要首先理解BPI项目和更典型的应用软件开发项目之间存在的差异。 不论是BPI还是应用软件开发项目，都是在交付新的软件组件或已有软件组件的新版本，它们都会用于更好地支持一个企业的业务流程。一个软件开发团队――由项目经理、分析师、开发人员、测试人员以及部署人员组成――共同工作，以推动完成一个可配置的和可靠的系统来支持一组商业目标的实现。 图1：一个通常的开发项目：一个团队，一个系统 然而，BPI项目同应用软件开发项目最根本的不同就在于组织上和设计上的复杂性。一个典型的应用软件开发项目也许只需要二十到五十人共同工作，整个系统也只有50,000至100,000行代码。与此形成鲜明对照的是，BPI项目则可能涉及二十到一百个应用软件，而每一个应用软件都有自己的开发团队和相当规模的代码量。如此大量的应用软件并不是困难的原因，真正首要的原因在于由不同应用软件之间相互依赖所引起的复杂性。 不同应用软件间越来越多的互相依赖导致整个项目难以管理。如果一个应用软件依赖于另一个，那么这两个应用软件的开发团队就必须在开发计划，测试计划和变更管理方面进行协调。把这个扩大到五十至一百个应用软件之间，你最终会在相互依赖的应用软件和团队所编织成的脆弱网络中以失败告终。 图2：BPI项目：多个团队，多个系统，以及一个集成团队 BPI的另外一个挑战是应用软件的开发团队们来自于完全各异的组织机构，所以他们往往遵循不同的开发过程，使用不同的术语和开发工具。尽管使用有细微差别的工具或者将关键术语赋予略有不同的含义看起来是微不足道的问题，但是如果将这些通过多种渠道传来的花费数月工作量的不协调累计起来，就会在不同团队间产生大量的不必要的矛盾。所以，下一小节我们将会讨论BPI项目取得成功的第一条基本原则：使用规范的开发过程和工具集。 使组织过程和工具规范化： 在讨论如何规范开发过程和工具之前，让我们先来看一看为什么要这么做。 首先，我们应当在这里区分采用任意一个特定的方法学同采用一个规范化的 方法学的差别。一个特定的团队可能会认识到只要采用任一种开发过程而不是什么临时方案就可以获得生产力。但是，如果不同的团队开始在一项大规模的业务流程集成项目中共同工作时，开发过程的差异就会导致不必要的矛盾和生产力的损失。 一个组织机构可以通过降低复杂度将某个单一过程的规范化推而广之到更大型的项目中，从而消除大量的无用功。最终的结果是缩短了产品进入市场的时间，获得了更高的质量，以及压缩了成本。节省下来的这些开销将会被继续投入到进一步增强产品功能之中，或者用于企业的其他投资项目，或者回报给股东。 各不相同的开发过程和工具在许多方面导致了复杂性的增加和不必要的浪费。当不同的团队遵循不同的开发过程时，有合作关系的团队间就必须不断地处理由于彼此间不同的术语、工件和图表结构以及一般性任务的处理方法所造成的问题。举个例子，一个团队可能使用用例图传达功能需求，然而另外那个团队却可能使用传统的“应该……”这种表述方式。这些团队于是就会在系统边界处的功能表述问题上产生问题。 当项目中使用不统一的开发工具时，想在不同团队间共享数据，或者在抽象的更高层次中收集和分析项目的数据，即使并非不可能，也一定是非常困难的事情。在BPI项目中，经常会出现一个团队需要使用另一个团队的某个需求来证明相关联性。如果这些团队使用的是不同的需求管理工具，那么他们就需要在多个系统中输入相同的需求，进行并行的修改，并建立多个追踪链接以确保一致性。 不幸地是，建立一个规范化的开发过程和工具集是一件非常困难的事情。为什么呢？ 开发团队通常很不情愿使用规范化的开发过程和工具集，除非自身的开发过程和工具集就是规范的， 短期的商业需要和冲突经常延缓长期的开发过程和工具集的标准化工作的进程； 团队成员需要经过培训后才能有效地使用规范化的开发过程和工具集。 转换到规范化的开发过程和工具集需要强有力的管理层支持，经过慎重考虑后确定的路标，以及持久的执行。与其使用武断的方法来试图转变整个企业，我更建议各组织机构根据BPI项目的内容使用新的开发过程和工具集。这些项目包括许多不同团队各不相同的过程领域的集成，他们还需要内部团队的有效协调来取得成功。在这样的环境中，团队成员们就会很容易的看到规范化的开发过程和工具集所带来的巨大好处，并且深刻意识到这才是获得成功的必备条件。 关注那些关键的团队成果以及相关的活动： 组织机构通常都会犯这样一个错误，那就是试图一下子就去规范化所有东西。这就不可避免的导致了失败。以此引入过多的变化必将导致巨大的混乱，团队成员们就会退回到以前那种陈旧的，支离破碎的开发过程中。 一个开发过程从本质上来说就是角色、工件和工作流程的集成体。因而我建议组织应该通过在BPI项目中关注那些关键协同完成的工件来实现规范化。 需求； 变更请求； 集成项目计划； 技术接口规格。 需求和变更请求决定系统的最终范围。集成项目计划则确保团队之间的相互依赖在可管理的范围内，项目能够按日程表的进度进行以及不超出预算。技术接口规格定义了开发应用软件的不同团队间的通讯协议。 在BPI的开发过程中没有白纸一样的东西，我们总是要在现有的系统上工作。 3 在某种意义上，BPI项目中的每一项需求都可以看作是一个变更请求。所以，在本文中我们区分需求和变更请求的标准就是看它们何时被纳入到项目范围中。一个需求是在对迭代范围基线化之前你所接受的范围的一个单元，而一个变更请求则是在你对迭代范围基线化之后对原有范畴的一个增量（增加、删除或者修改）。 在迭代方式中采用新工具： 出于一些原因，正常而明智的信息技术专业人员经常不相信“软件物理学法则”适用于新的软件开发工具的部署。即使懂得迭代地开发商业应用软件是一种明智的行为，但是他们仍抱有这样一种错误的想法，那就是它们可以一次性地成功部署出一个完整的新工具集。 一个较好的原则是每次只采用一个大型的开发工具。规范化这样一个工具是一项长期的投资，在团队使用新的开发工具提高技术含量时需要先期的投资，包括培训、数据迁移以及生产力受到影响。 BPI项目应该将关注点放在它所能产生的新的商业能力上，而不是放在采用新的开发工具上。一次就引入多于一种主要的开发工具只能给项目的成功系数带来消极的影响。 在部署新工具前对团队成员进行再培训： 正如我们前面所提到的，工具应该服务于开发过程，而不是限制它。即使为战略性的开发过程定制一个配套的开发工具，它仍将会促使产生出某种“世界观”，并不可避免地影响到原先制定的开发过程。 试图部署新的开发工具而不对团队成员进行再培训将会导致下面这些负面结果： 团队成员抵制使用这种新工具，因为他们并不理解它所支持的这种开发过程； 团队成员试图将他们原来旧的开发过程强塞进这种新工具中。 对团队成员进行再培训是一项非常值得的投资，首先是要教授那套不久即将成为标准的开发过程，然后是教授如何使用相应的开发工具。这种培训可以使非正式的，但必须要通过某种形式来开展。 在开发周期的间歇部署新的开发工具： 如果想要过渡到使用新的开发工具，就应该选择一个团队成员们时间安排较为灵活的时间段。例如，如果要引入IBM公司的? Rational RequisitePro? 软件来管理需求，临近开发成果的结束阶段是一个较为合理的引入时间，因为那时整个开发过程已经趋于稳定，并且系统分析员也拥有更多的时间来接受培训。另外一个对团队进行培训的适宜时间是两个项目之间的间隙，这是因为开发者们此时完成了一项项目的最后一段工作，并且已经准备转换到另一项项目的起步阶段。 如果你已经决定在开发间歇采用新工具，那么请意识到项目经理们可能并不会对这种必要的培训提供支持，因为他们本打算将这些人力派往其它的项目中去，因而培训这些人力就意味着丧失项目的收益。为了避免这种情况，最好是由工会人力资源组织所提供的职业发展预算来提供培训支持，而不是由项目预算来提供。 以上我们分析了开发工具和过程，下面我们来看看组织结构对于BPI项目的顺利实施发挥何种影响。 建立一个一致的组织结构： 正如我们前面所讨论过的，BPI项目是多方面相关的复合体。它们有若干业务流程领域，若干功能规范，各不相同的开发过程、术语学和文档格式。你可以通过建立清晰的领导层以及将多种应用归类为模式化的单元来减轻系统的复杂性。在下面两个小节中，我们将会探求这些技术手段。 为每一个关键的项目角色设置一个领导者： 对于一个小规模的团队，在关键角色中设置领导相对容易一些，比如项目经理、架构师、系统分析师以及变更经理。然而，在大型的BPI项目中往往产生领导层的问题。问题并不在于在项目层面上没有关键人物的领导层，更不在于某个人试图领导每一个角色，而是在于能够真正掌控项目的人似乎并不是那么明确。 第一种情形出现的原因很容易理解。要想在大型的BPI层面上领导管理，需要具备不同过程组织结构所涉及到的广博的知识面，而且还要具备协调遵循不同过程工作的各个团队的能力。 第二种情形，即两个或者更多的人争当关键位置的领导者，这种情况通常在当两个大型的组织机构需要合作开发某个大规模的集成项目时发生。来自不同组织的领导者们将会争夺BPI层面上的领导权。即便你设法通过协商来设立一个共同的领导层，这也将导致决策速度的延缓。 为了获得及时和权威的决定，项目中需要在如下的关键任务中明确一个单一的领导者： 项目经理领导者； 架构师领导者； 系统分析师领导者； 测试经理领导者。 这些领导者应当从其它团队成员出收集信息，但是，最终它们必须作出对整个项目最有力的权威的决定。 一个出色的BPI项目领导者究竟都需要具备什么素质呢？理论上说，关键人物的领导者应当最少具备在该组织结构目前的应用投资组合中三年以上的相应能力的工作经验。这些人熟悉大部分在应用投资组合中有知识有影响的人员，所以他们能够很快的收集至关重要的信息，解决潜在的问题，以及委派小规模的工作任务。 将应用软件分解为更小的、半独立的单元： 我曾经在一个具有上千个应用的大型的内部IBM项目中工作过，我们将其分解为15个功能领域，用粗粒度的业务流程加以组织，例如“市场和销售”和“完成订制”。尽管每一个这样的领域都包含30-400个应用软件，但是在那些熟悉每一个领域里的相应应用的高级项目经理和架构师的协助工作下，我们能够实现仅仅处理15个子系统而不是上千个应用软件。 很显然，期望某个人理解一个或者两个以上复杂应用的具体细节是不现实的。一个大型的BPI项目可能涉及到数十个甚至数百个应用。在这种情况下，应该考虑通过将所有应用按照业务流程领域分组来使项目结构实现模块化。举例来说，你可以将所有有关财务的应用或者所有网上贸易的应用归并在一起。 图3：应用软件的非模块视图与模块视图的对比 在任何应用领域，任命一个项目经理和一个构架师都代表着该领域在项目上的水平。这要求技术管理者从一个相对来说粗粒度的水平去考虑一个复杂的庞大项目系统。 为每个重要的功能部分建立相应具有代表性的委员会 当我在另一个大型的BPI项目中担任一个业务流程或集成架构师的工作时，我负责一个每周例行的架构方面的相互协调会议。尽管我们在这套超级系统中拥有大约10个大型的子系统，但只有7个子系统对于每周的构架检查点具有代表性。 这些需求本身坦白来说一般都不太令人满意；大多数典型代表都是非常难以修改的，并且常伴有让人难以忍受的自我冲突和技术主张。然而，那些没有注意这些早期构架需求的项目，最终变得更加令人失望。当我们完成了我们的第一个开发阶段的迭代并且开始进行集成测试，这些在需求上不具典型性的子系统会发现非常大的集成问题。 早期的会议可能太简单，令人不满意，因为你是在事先解决问题而不是在事后。那些略过会议和争论的团队也无法让问题随之溜走，他们只是简单的把问题拖延到了以后。 预先降低项目风险最有效的途径是让每一个重要功能规程的小组（项目管理、需求、构架、测试、变更管理和部署）能够与他们的子系统领导频繁地协调沟通。另外，子系统领导应该建立一个“变更委员会”以此来应对跨过子系统边界的有规律的对任何改动的评论和通过。 图4：职能领导和协调 既然我们已经讨论过如何成功地组织一个项目，现在让我们来讨论一些更为具体和重要的开发过程：需求和管理变更。 优化需求和变更管理过程 正如我们先前讨论的，需求和变更请求，各自都是BPI项目中最为重要的工件。下面是优化这些项目元素的具体技术。 使用迭代化方法交付功能 我强烈推荐在您的项目中遵循一种迭代的部署过程，这使得您能在大约几周内了解从概念到系统的运行，而不需要几个月甚至几年。这对于BPI特别重要，因为新的功能性被讨论的时候通常停留在一个抽象的高水平上，需要来自不同的涉众的广泛的、不同的进一步阐释。早期传递大多数新功能的时候，通过一系列的迭代，使涉众能够看到、接触到并且对新功能给予反应，这样一来，如果有需要的话，您可以快速的明确和重新定义需求，并且在问题比较容易解决的时候发现和解决问题。 使用迭代方法的另一个原因是，在BPI项目中用来集成的子系统实际上是大型应用软件或大型应用软件的集成。传统的瀑布方法使得子系统集成滞后到生命周期的最后阶段，这时您可能会发现高错误率并且发现自己有大量的工作要重做。 如果您使用迭代化方法，比较理想的，您的测试环境应该能后映射您的成果环境；最起码，能够模拟该环境。由于它包含了许多应用软件和潜在的上百台的服务器，这项操作的花费可能看起来被BPI所禁止。但是如果您去考虑在项目上的大量的重复工作的开销与预先在大型测试环境上的投资做一个对比，我相信您会选择后者。 警告：迭代化开发使得您能很容易的向现有架构中简单的添加功能，但是同时也使得您想要改变主要架构变得更加困难。如果您想要在大型的超级系统中做一个基本架构的修改，例如，用一个SAP部署来代替自产的ERP系统，您将会被引诱到一个给您带来沉重打击的道路上。但是，您可以使用另一种更加明智的迭代化方法,即便您想要对主要架构做一些修改。再来看SAP的例子，您可以通过一系列的版本从自定义的应用软件向SAP发展改变其功能性，通常利用开启越来越多地SAP自带功能来实现。 每个涉众组只允许一个代表去提交需求和更改需求。 在大型的项目中，成百上千的工人会直接或间接地参与到项目的执行中。如果任何与项目有关的人都能够提交新的需求和/或变更需求，那项目会很快地陷入一片混乱并失去控制。相反，最好的办法是让每个涉众组正确地任命一个代表，代表全组来负责提交需求和更改需求。 一个涉众工作组是有什么人组成的呢？理想状态下，小组应该包含与你在概念阶段建立项目视图时所定义的机制相同。 对于一个大型的BPI项目来说，拥有多个涉众是很平常的。在一个典型的供应链集成项目中，例如，行销，出售，实行，以及财务都属于涉众。每个组都需要一个明确的代表来提交和改变需求。 未来的用户包含通过系统（例如通过网络或是电话接口）与您的公司有直接交互的顾客和商业合作者和那些利用系统来完成工作的雇员。这些用户是典型的公司代理（比如顾客维护组织），因为管理与成百的或是上千的实际用户、商业伙伴和雇员交互是不可能的。 BPI项目的开发团队实际上是一个拥有很多团队的团队，每个团队负责超级系统中的一个大型的子系统。由于一个大型的BPI项目可能包含十几个甚至上百的应用软件，这如我们前面所讨论的，这些子系统实际成为一个对商业过程领域软件的收集者。接下来，每个子系统的开发团队的代表可以向申明独立性和计划变更需求的变更委员会去提交系统需求，并在以后的开发过程中修改这些需求。 区分各种需求变更 巧妙的响应一个变更需求，您需要首先了解变更的原因。尽管这些原因可能无穷无尽，但是，只有一小部分正当理由能够证明系统需要变更。 在外部商业环境中的变更 商业问题的错误理解 方案中的技术性瑕疵 商业外部环境的变更。这种变化会带来一系列广泛的影响，从指示一些琐碎细节的变更到更新整个陈旧的项目。例如，在2004年，IBM有许多项目想要去提升PC生意。公司宣布完全停止这些项目并将其卖给联想，同时把商业焦点转移到整顿上的工作上。 总体来说，那些特许的和投资的商业涉众应该向项目团队来宣布在外部商业环境中的变更。最终，他们将是改变项目范围的决策者，他们同架构领导者和项目管理者一同决定如何去响应这个改变。假设这个项目还存在，BPI级别的项目管理者同各自子系统的管理者一起去指定随后的计划并构思设计适合于商业改变的相应改动。 商业问题的错误理解。团队在一开始对商业问题有一个不太正确的理解几乎是个不可避免的问题。然而，随着项目从概念进展到原型再到运行系统，业务和开发团队对业务问题的理解应当会逐渐从模糊走向具体。熟练的开发团队使用技术去尽早的获得清楚地认识，其中包括原型和更少的反复过程。当他们发现错误理解商业问题所带来的问题时，架构领导者将会同商业涉众更新设计方案，这些改变将会影响到一个或多个子系统。 方案中的技术性瑕疵。技术上的瑕疵与其他合法的可变驱动是不同的，因为它与商业领域毫无关系；典型的，它是由开发团队提出的而非商业团队。技术上的瑕疵在子系统的边缘更为盛行，问题更多。一个团队可能意识到它的子系统需要一个来自上层子系统的额外的数据元素，这样它才能够运行正确。这些变更应该在变更委员会之前被子系统的代表提出来。唯一的例外是如果设计上的瑕疵完全在一个子系统中，那么子系统的团队可以独自控制该变更。我们将会在下面仔细讨论这个问题。 在子系统团队内处理局部变更 一个集中式的、高水准的BPI项目领导团队的底线是当你在项目的精心制作和建造过程中进入到细节的工作时，能够比较容易的形成一个瓶颈。如果每个需求和需求变更，不论它多小，都必须通过变更委员会，那么，进步不是很慢就是缓缓前进，要不就是在创新的道路上迂回不前。与控制每个细节（需求和设计）方面相比，领导组把具体的活动放到稍低的层次显得更加合理。 由外部商业环境（参见前面的章节）所引起的改变应该通过变更委员会，因为架构领导者必须要决定如何在超级系统中实现变更。然而，设计上的瑕疵带来的变更则不需要再通过变更委员会。 需要变更两个或多个子系统的修改应该需要通过变更委员会来确定每个部分都达成一致意见。然而，如果需求或是变更需要在一个子系统的局部，该子系统可以独立操作变更。他们在这个领域是无可厚非的专家，能够精确并快速地处理变更；请示变更委员会并没有带来更多的优势反而降低了解决问题的效率。只有在变更会严重影响子系统进度，进一步影响超级系统进度的时候才有必要在局部工作中使用变更委员会。 避免暂时的、手动的工作区 BPI项目团队在紧张的工作安排中可能会感到他们需要求助于手动工作区来避免复杂的软件设计问题。手动工作区有两种类型：一次性的变更和正在进行的程序步骤。 我的工作成功地实现一个一次性的工作区。该项目的一个主要需求是将一个顾客的CRM应用软件改为一个卖家的CRM包。这包括定制一个与现有性能和移植后的客户数据库相匹配的CRM应用软件包。在构建阶段的过程中，开发人员们发现他们忽略了移植一个包含一些对整个商业数据非常重要的小型客户数据库的需要。他们认识到通过写脚本来移植会破坏工作表。这一发现带来了恐慌。然而，最后大家提出，由于数据库比较小，可以雇佣一组临时工作者利用一周的时间手工向新系统中输入数据来代替书写复杂的脚本。这个解决方法实行了，数据移植的开销相对降低了，并且没有打乱项目的工作安排和预算。 类似这样的一次性的工作区可能更倾向于开发只使用一次的软件（除非软件在一个庞大的数据集上操作）。 暂时性手工工作区的吸引力更小，它将成为日常操作的一部分。执行这样的一个工作区开销通常很大（必须雇用人去执行这个工作），如果它被完全替换，它将需要很长时间转化成永久的IT解决办法。作为一个商业业主，当你被建议使用一个暂时性的手工工作区时，一定要确定在一个将来的版本中您能获得一个永久的IT解决办法，并且相应的风险比较小。 总结 在这篇文章中，我们讨论了一些关于BPI项目的独特特点和问题。接着，我描述了一些解决此类问题的基本规则和技术。进一步，我们希望能够看到越来越多的大型集成项目，因此学习如何正面的面对这些问题并有效地解决它们变得非常重要。能完成这项工作的团队会创造出更加实用的系统，并使得他们的组织在市场中更有竞争力。 感谢 感谢以下每一个人，他们给与我在本文中提到的很多思想：Carolyn Maher, Grady Booch, Jay Strosnider, John Hartley, James Jamison, Kurt Bittner, Ralph Nelson, Russ Taylor, and Simon Johnston. 同时谢谢 Marlene Ellin 在编辑过程中的耐心指导和 Kurt Bittner， Michael Hanford 在本文初期迭代阶段提供反馈。 详细阅读和参考资料 Kurt Bittner and Ian Spence, Use Case Modeling. Addison-Wesley Professional, 2002. Frederick P. Brooks, The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition. Addison-Wesley Professional, 1995. Robert Galen, Software Endgames: Eliminating Defects, Controlling Change, and the Countdown to On-time Delivery. Dorset House, 2004. "IBM‘s Sam Palmisano‘s Definition of On Demand Business" at http://www.ibm.com/e-business/za/about_ondemand/def.html James Rumbaugh, Ivar Jacobson, and Grady Booch, Unified Modeling Language Reference Manual， 第二版， Addison-Wesley， 2004. 注释 1查看IBM的Sam Palmisano关于商业需求的定义http://www-5.ibm.com/e-business/za/about_ondemand/def.html 2文中提到UML部分的完整定义见 James Rumbaugh, Ivar Jacobson,和 Grady Booch 的 Unified Modeling Language Reference Manual，第二版， Addison-Wesley Professional, 2004。 3即使一个新应用软件也不可能将完全崭新的功能引入到超级系统中来。 4 Kurt Bittner 和 Ian Spence， Use Case Modeling。Addison-Wesley Professional， 2002。 参考资料 您可以参阅本文在 developerWorks 全球站点上的 英文原文。 关于作者 Bill Higgins 是IBM公司全球服务部的一名架构师，他所从事的工作是与IBM公司的 On Demand Workplace 和 Rational 组织相关的协作开发技术。当前，他正在研究一种门户网站的解决方法来帮助软件开发团队。他在技术方面关心的内容包括：IBM? Rational Team Unifying Platform,? IBM Lotus Workplace,? IBM WebSphere Portal Server,?将业务过程映射到IT，以及在他的IBM developerWorks blog中记录他的活动及观点。另外，Higgins 还拥有宾夕法尼亚大学计算机科学学士学位。