本文所述的系统开发方法利用了Murray
Cantor使用 IBM Unified Process进行有关系统工程的工作，以及Rational领域组织应用这些技能与技术为解决现实世界问题所作的工作。这些工作包括各种各样的项目，范围从国防程序到电子政务的启动。这些项目最显著和最一般的特点就是它们的规模和复杂度。在每个案例中，关注的焦点不仅仅在于要创建软件产品，而且还要创建完整的系统来支持业务或者任务。
本白皮书描述了 IBM Rational Software进行系统开发所使用的整体方法，包括在系统开发项目中必须执行的重要原则以及
IBM Rational Software提供的特定解决方案两方面。本文通过描述所解决的主要问题，重点介绍了促使遵循使用该方式的因素。
本文所述的系统开发方法利用了Murray Cantor
使用 IBM Unified Process进行有关系统工程的工作，以及Rational领域组织应用这些技能与技术为解决现实世界问题所作的工作。这些工作包括各种各样的项目，范围从国防程序到电子政务的启动。这些项目最显著和最一般的特点就是它们的规模和复杂度。在每个案例中，关注的焦点不仅仅在于要创建软件产品，而且还要创建完整的系统来支持业务或者任务。
本文的目标就是来描述一种创建系统所使用的结合、集成的方式，同时还包括创建这类系统所使用的平台，使团队能够在不断变复杂的环境中进行工作。
简介
一套系统是指"一套能够完成已定义目标的集成元素。其中包括硬件、软件、固件、人员、信息、技术、设备、服务和其他支持元素。
"
我们为什么要重新评估进行信息系统开发的方法与技术呢？业界中存在的问题驱使我们这样做，下面就是一些驱动因素。
- 企业架构。1996年，美国国会通过了Clinger-Cohen法案，其中特别授权联邦机构开发并维护企业信息技术（IT）的架构。该法案使人们越来越关注政府组织已经开发出的一些应用程序，这些应用程序在成功地部分满足了一套选民的较窄范围需求的同时，不能结合起来满足更广泛的需求。目前，这些组织中的很多都致力于Enterprise
Architecture（EA）的研究，使广泛范围内系统实现互操作，从而完成不断增加的任务；这些研究工作包括对不断增加的任务清晰定义，并且描述出这套互操作系统是如何完成这些任务的
。这个系统包括硬件、软件和人员，由于关注的焦点在于整个系统，所以使用传统的以数据或以功能为中心的方法表示企业架构是无效的。它们无法为不断发展的企业提供支持，这一点在架构实施于工作系统之后尤其显得更加明显。
- 增强软件功能。软件灵活性的增强使引入新的系统功能变得轻松。服务可以由硬件、人员或者--不断增加的比率--软件来提供。在一个系统开发项目中，开发团队使用正确的方法和工具是很关键的，这会使他们能够权衡设计方案。这也增加了分析员、项目经理和系统工程师工作环境的复杂度。在生命周期的较早阶段，就要判定出如何设计才能实现系统功能。
- 开发生命周期。虽然引入迭代式和敏捷方法进行系统开发会带来大量相关的压力，但是传统的方法--尤其是瀑布式方法--并没有满足以增量的形式发布系统"组块"的需要。
- 项目与程序的失败。项目失败的实例有很多。Standish
Group的一项统计数据尤其明显地表明了这一点，1995
年，美国政府花费了大概 810
亿美元取消软件项目。这也突出了一个事实，即项目和程序正在走向失败，而导致失败的中心因素就是他们使用的系统开发方法。这就使得组织需要重新评估他们的系统开发能力，并参照例如CMMI和ISO的标准为他们的能力设定基准。
系统工程方法都需要些什么呢？
"系统工程是一种跨学科的方法和手段，能够成功地实现系统。它关注于定义客户需求以及开发周期的早期所需的功能，使用文档记录需求，然后在完整考虑问题的同时，从综合设计与系统检验下手：
- 操作
- 性能
- 测试
- 大量生产
- 成本与时间表
- 培训与支持
- 处理
系统工程将所有学科和专家小组集成于团队，形成了结构化的开发过程，从概念到生产再到操作。系统工程同时考虑了所有客户的业务与技术需求，它的目标就是提供高质量的产品，满足用户的需求。
"
这一定义体现了下面几个重要的概念：
- 客户需求--在描述系统是如何支持组织的任务或者业务流程时，系统工程方法必须围绕着需要考虑的所有内容。
- 沟通--系统工程方法涉及并沟通团队中的思想、信息和过程。系统工程方法必须提供抽象的方法，允许向所有的项目干系人沟通每个系统元素，同时提供一种机制，将每个业务流程的需求映射于上述抽象内容。
- 过程与项目具有真实性--由于系统是在"现实"世界中进行开发的，负有时间和成本的压力，所以要确保您的开发方法没有导致项目的过度开支，这一点是很重要的。
- 与系统标准保持一致--系统开发的一个重要目标就是您系统中的组件和元素要与系统标准和架构保持一致。
- 团队协作--任何系统开发方法必须能够使大型或小型工作组中的成员有效地协同进行工作，同时也要和处于分布环境中的其他类似工作组有效地协作。
考虑到所有这些因素，使用"整体"方法作为系统工程方法是大势所趋的。所谓"整体"，意思就是一种方法，涉及到系统开发过程中整套的规范：需求、分析、设计和实施，并将这些规范集成于同一过程中。而且，这种方法必须包括一种机制，允许测试系统并将结果与项目干系人进行沟通。
客户需要--用例与需求
任何系统的主要职责就是完成组织的任务或者业务目标。因此，一套系统必须在一套来自不同项目干系人的需求环境下进行开发，包括：
- 关心功能与性能的用户（例如，军事系统中的雷达操作员）。
- 关心部署与所有权的成本，包括维护的成本决策者（例如，军事系统中的程序管理办公室）。
- 关心给定系统会如何更好地服务于业务并提供有竞争力的优势投资者（例如，赞助军事系统的政府部门）。
每个项目干系人的需求都必须作为系统架构的因素，而且也必须体现于最后的设计中。这些需求也将包括各种各样的非功能性内容，例如：
- 可用性--系统使用起来是否会比较方便？
- 可维护性--系统的维护周期如何？处理一个缺陷的速度如何？
- 可扩展性--它的灵活性与"可变性"如何？
- 可伸缩性--有多少用户使用？分布于多少个地点？
- 性能--在不同情况下，响应时间/吞吐量/等的预期值为多少？
- 可维护性--维护系统要做什么准备？在什么环境中？
- 大量生产与部署的成本--大量生产然后复制的可接受成本为多少？
- 运行成本--保持系统持续工作的成本是多少？
这些问题的答案也就是必须在系统行为的环境中得到满足的需求。而且，这种系统行为可以使用一套用例来描述。
- 用例描述了不同用户操作系统时系统的行为；从用例方面来说，这些用户被称为"操作者"。用例清楚地关注于操作者，从很多方面来看，用例事实上已经成为的一种描述计算机系统功能需求的实际机制。
- 用例从客户（操作者）的观点描述了系统的行为。（实际上，客户可以作为另外一个外在系统或者系统操作员）。这种方法允许将功能性需求仅仅描述为需求，因此，不会对系统实现这些需求的方式进行描述。因为用例是从客户的角度描述需求的，所以也很容易通过客户对其进行评审。
- 由于用例所包括的路径范围从一切都运行正常时的普通交易到对不频繁出现的"非常不快乐"路径的描述，很自然要以增量的方式交付系统，而系统增量能够支持这些情景。这种方式非常有助于实行迭代式开发，开发团队可以交付支持特定情景的系统组块，并对客户说明情况。
- 用例描述了对客户有价值的端对端的交易。这里，关键内容--"有价值"--意味着用例并不是对功能的强制分割，而是对客户有价值的处理过程（参见图
1 ）。
图 1
：面向零售系统项目的一个典型的业务级用例图
一个用例可能有很大的时间跨度，并且包括许多子系统和组件。用例也可以作为一种"环境粘合剂"，确保所有的系统元素共同配合产生价值。这种方法的一个主要益处就在于用例定义了对系统集成的测试，使系统能够从相同的环境中进行开发。
将用例与传统的文本需求相结合可以使系统项目利用这两种需求表现形式各自的益处。一个用例可以为文本需求提供的"交易"环境，并且使用强大的机制将所交付的起作用的系统增量结构化。文本需求允许项目干系人使用自然语言描述系统。
沟通--架构、可视化建模和
UML
企业与系统架构
系统架构是指"通过系统元素、界面、过程、约束和行为定义的基础、统一的系统结构。
"这一定义可以用来计划开发过程、管理风险并且促使完整地进行开发过程。注意，对于系统架构的描述是与企业架构的定义紧密相连的，正如"…一个记载企业中所有信息系统、它们的关联以及它们如何互动以完成企业的任务蓝图。
"这是有意而为之的。企业架构一般就是一个系统，而系统架构往往不能代表一个企业。术语"企业"定义了系统和其完整性的范围。因此，要创建企业架构就需要组织创建面向特定环境的完整系统定义。
企业架构所面对的主要挑战之一就是创建过程中所需的时间量。如果努力创建的架构要满足很多项目干系人的需求的话，那么最终的产品常常需要过长的时间，而且也无法足够地满足任何人的需要。经验表明，使用迭代的、增量的方式创建EA是很关键的--而创建过程的核心就是系统的架构。
系统的架构需要提供创建系统所需的足够细节。有些人认为，应该使用足够详细的信息按照真实的情况描述系统，并从中得出企业架构的活动；这些活动包括资源计划,
IT投资组合管理等等。但是，并不是所有的项目都需要类似的活动，因此，系统的架构应该足够完整，以满足其项目干系人的需要，从而创建系统。
为架构的视图建模
使用两种主要维度描述系统架构：
从一般意义上来讲，系统架构的发展起源于建模。初始时，系统架构师创建了环境模型，然后发展为逻辑分析和设计，最后再到实施阶段（不同的模型级别）。通过这种发展过程，就可能从不同的角度查看系统模型，例如企业工人、信息、物理结构等等（参见图
2 ）。这种方法可以使架构师定义系统并且使其结构化，同时也允许项目干系人查看所关心的架构。
子系统
子系统是指带有一套已定义的服务系统逻辑块。其他子系统都依靠于这些服务。当联合使用时，它们可以提供描述于用例中的功能。换句话说，用例是通过提供服务的许多子系统的集合实现的（参见图
3 ）。
图 3
：子系统和其关联的框图。每个子系统定义了一套服务，联合使用时可以提供用例描述的功能。
位置
"位置"，从工程的观点来看，是指一种机制，用以描述系统过程部署的逻辑位置。子系统的服务分配于特定位置上，可以按顺序通过物理过程而实现。位置框图包括两个元素：
- 位置--一组计算与存储的资源，可以作为处理的主机。
- 连接--物理位置间的信息通道。
将非功能性需求（例如质量、可靠性以及性能）与位置联系起来，才可能从逻辑上描述每个位置的规范。就连接来说，位置可以很好地用来将吞吐量与管理需求归因于系统架构。图4展示了位置设计的实例，表明了两个位置间的特定连接。
用例下放流
这是分析/ 逻辑设计级的活动，可以用来得出功能的需求，并将其与系统元素相联系。该活动的主要结果为：
执行用例下放流的第一步就是来进行用例描述，系统在其中被看成是一个黑箱。然后，使用典型的面向对象分析与设计技术建立待选子系统。下一步，检查子系统判断它们是如何来实现用例的，同时添加对于子系统功能的白箱描述。将子系统的附加元素、位置以及过程加入下放流中，来描述子系统应该完成的功能、完成的位置以及使用的过程。需要重复这一过程，深入考虑细节，处理不同的模型级别。
需要注意的重要一点就是上面所述的方法通过添加入更多的信息"创建"了待选架构。该方法没有使用用例来分解需求。不要将用例下放流与功能分解混淆。
可视化建模为开发团队提供了一种方式，既可以概括问题，也可以将解决方案与其他关键的项目干系人进行沟通，而且作为业界标准语言的UML也能够处理这些模型。UML提倡使用基于组件的方式以使架构结构化。子系统形式的组件使开发团队能够清晰地将系统分为高聚合的模块，这就意味着从变更的角度来看，系统模块是很有用的，低耦合意味着每个组件并不是非常依赖于其他组件才能完成功能，这也为未来确保了强健的架构。
过程--利用 IBM
Rational Unified Process的系统工程
Rational的 IBM Rational Unified
Process（或者简称 RUP ）为系统开发提供了框架。使用 RUP 进行系统开发的主要原则是：
- 架构--RUP促使了模块化的、基于组件的架构。它提倡使用UML定义系统架构，鼓励有规律的系统设计、开发和检验。
- 并发设计--能否使用多名人员同时进行系统开发是成功的关键因素。通过提供一套工件与过程的清晰步骤，使组织大型的开发团队成为了可能。RUP关注于架构，鼓励使用结构化的环境以及反映架构的团队，从而清晰地定义了组件间的职责。
- 迭代式开发--RUP提倡使用迭代式的方法。每次迭代通过交付相应的功能来减少风险。风险管理是
RUP 所提倡的主要"最佳实践"，由初始阶段开始，在其中定义关于范围和功能需求的风险。然后，随着项目生命周期的不断前进，识别出关于架构、大量生产以及部署的附加风险，并对其进行控制。这种迭代的方法使团队能够有效地工作，以增量的方式构建系统，同时减少整体风险情况。
- 变更管理--RUP将以架构为中心的方式与迭代式生命周期相结合，提供了支持变更的框架。变更在所有的项目中都会出现，使用一种优秀的过程可以主动管理这些变更，并为文档记载、实施与测试变更提供了指南。考虑到大多数系统的规模和复杂度，最重要的一点就是要管理变更带来的影响，并且持续评估所影响到的组件以及变更会对整个系统的架构带来什么样的影响。
符合规范--测试
如果您已经定义了系统的需求，在系统架构的环境下设计并且开发出系统组件，那么测试这些组件就变得很关键。当您使用迭代的、增量的方式开发时，这就更加重要了。增量式的开发可以加速生命周期中的测试、检验与验证阶段，使它们在开发阶段的早期出现。正如在RUP中定义的那样，测试可以应用于很多核心实践中：
- 发现并记载系统中的缺陷
- 总体上为可预测的系统质量提供建议
- 通过具体陈述证明与验证在系统架构和需求中作出的假设
- 检验系统功能是否按照定义进行
- 检验需求是否已被实现
缺陷检察与报告
由于Rational的进行系统开发方法的本质是迭代式的，所以在整个生命周期都要对系统进行测试。即使在早期的迭代阶段，系统的方方面面也要进行测试。最重要的一点就是，要使发现的监察结果文档化，而且对每次的交付品都要进行报告。系统的某一部分在项目的最后阶段突然不起作用了，这种事情发生过很多次，这是因为从开始阶段这一部分就没有工作，而只是假设缺陷已被记入文档并且进行了修改。
缺陷报告的过程必须被作为一个自然的过程，而且并不对运行费用产生什么较大的影响。使用ClearQuest应用程序的Rational方法提供了一种机制，向网表单中输入缺陷或者使用本机应用程序。这些观察结果，随后可能成为缺陷，它们通过测试和正式测试这两种方式得到，而不是使用某种规范和探索性测试。就正式测试来说，最关键的一点就是，在某种测试计划的环境中，并不将任何缺陷与测试中并不使用的规范相联系。对于探索性测试，关于环境的信息，能够捕获的越多就越好，这也是很关键的。
度量系统质量
一般情况下，系统进行测试的完整程度与系统失败导致的后果成正比。在所有环境中，测试每个系统路径所得的回报是不断减少的。因此，重要的一点就是考虑要测试系统的哪个部分，然后从中判定如果不对所有部分进行测试会存在哪些相关的风险。存在两个主要的工件，在质量保证专业人员作出下列决策时起到了很关键的作用：用例与系统架构。
用例按照"黑箱"的方式描述系统。用例是从操作者的角度编写的，而并不描述系统是如何实现该行为的。由于用例和由用例组成的流是用来作为迭代的主要驱动因素，所以测试
"端对端"的流可以使时间表专业人员更好地了解系统质量。这也使他们能够了解已交付的功能，以及功能的工作情况。由于迭代过程存在于风险的环境中，所以将风险映射于质量度量中从而更好地了解系统是很可能的。例如，我们已经交付了x个用例，并得到了y个缺陷，但是仍然存在r个明显的风险，因此由于我们还没有处理所有的风险，所以我们确实不知道质量如何。
系统架构定义了组成系统的服务和组件。在用例的使用环境之外隔离测试这些服务可以从某种程度上度量质量。但是，在用例的使用环境中执行这些服务可以使服务根据客户需求的规范进行测试。
测试的过程
测试应该作为整个系统开发过程中的一个集成部分。清晰地定义测试任务，同时使用来自其他规范的恰当输入工件，能够使测试成为过程中的一个自然部分。迭代式开发在生命周期的早期就要进行测试，并且提倡将质量度量方法作为报告过程中的一部分，即使在生命周期的早期阶段中。图
5 描述了RUP中的测试规范。该规范突出了测试的过程必须进行持续地度量，同时也要对系统和组件进行实际的测试。
独立验证与检验（ IV&
V ）
从传统意义上来讲，验证是一种过程，可以评估系统是否按照规范正确地创建，并且回答系统的有关问题"系统创建得正确吗？"。验证关心的是系统是否解决了它应该解决的问题，并且回答了简单的问题"创建的系统正确吗？"。
随着增量的发布，每个增量都在其规范（验证）的环境下进行测试，同时描述出不符合规范的缺陷。让客户得到迭代阶段的产品，因为交付的功能从某种程度上来讲，如用例流所定义的那样，也是系统的一个完整部分，客户可以判定出迭代产品是否满足了他们的特定需要。系统被逐步地创建，这样可以使管理层真正了解到在整个过程中使用IV&V所得的结果。
图 5 ： RUP 的测试规范
团队协作--配置和变更的管理
在任何的给定时刻，系统都可以被描述为处于不同的状态：例如，它的当前状态（系统目前是如何工作的）或者不同的未来状态，也常常包括长期的和短期的描述。因为清晰地记得工作情况的配置对于系统开发人员变得越来越困难，所以能够管理系统定义的无数配置方式是很重要的。
由于开发系统是一项团队活动，所以所面对的挑战呈几何级数地增长。团队可能包括处于许多地点的既属于组织内部又属于组织外部的人员，他们都要参与进许多活动中。每个团队成员都要工作于相同的开发过程中，并且参照相同的"虚拟"存储库，这一点是很重要的。我们已经讨论了有关过程的内容，以及整个团队如何工作于一个开发过程中，使用RUP
完成系统工程（又名RUP SE）对于了解他们的职责是什么、每个工件的大概内容以及存在什么样的关联是很重要的。
RUP SE是一个可配置的过程，还包括过程描述、模板、指南和实例。它并不"强迫"团队去遵守教条。对于许多开发团队来说，这是一件好事，可以允许团队根据他们的经验和专业知识来决定自己应该做什么，但是这样仍然需要一个共享的知识库作为基础。但是，在一个领域中，这样做会出现问题。这个领域就是变更管理。团队需要根据相同的变更过程进行工作，在该过程中工件的变化状态是共享的，项目要"强迫"使用模型，这一点是很重要的。将这种状态模型与每个团队成员都可以共享的存储库结合起来，就是IBM
Rational进行系统开发的核心解决方案。
IBM Rational提供了一种集成的解决方案，可以使对于工件的变更管理和清晰定义与执行的过程集成起来。Unified
Change Management（UCM）是一种在软件生命周期中自动处理变更的工作流，可以使用于分布的、多功能的开发团队。UCM
的核心就是将步骤与特定变更请求相联系的功能。然后，当您注册与检验工件时，您可以将它们与步骤相联系。因此，您就可以在"变更记录"的环境中工作。
UCM 能够协调团队的活动并且设定优先级，确保团队使用正确的工件进行工作，这样就帮助经理削减了风险。在整个生命周期中调节所有的项目领域信息--需求、可视化模型、编码和测试工件--这样有助于团队在编写代码和测试的同时，有效地"设定基线"需求。
如果您已经使用存储库的基础设施和集成的面向活动的变更管理过程，下一步就是要将变更过程与开发过程相联系。通过将变更请求与需求相连，程序管理办公室就可能在一套需求基线的基础上管理变更。变更管理记录系统应该面向系统的用户，允许他们添加对于特定发布版本（迭代产品）的评论。当系统具有若干个项目干系人时，这样做尤其会得到良好的效果。对于他们的输入进行管理是很重要的，这样可以提升最终系统的质量，同时减少1000个以上从没有被映射到新功能或者版本的变更请求带来的混乱。
变更管理常常被认为是系统开发中的令人厌倦的部分--这是一种必要的痛苦。将自动化、集成的变更管理过程与您整个系统的开发方法相配合，将会成功得到一种迭代式的、增量式的变更管理。
结束语
一套系统不仅仅包括软件；它是人员、软件与硬件的结合体，统一起来才能得到共同的目标。正确的系统开发方法需要考虑事物如何运作才能支持特定的业务目标或任务。正如上面所述，IBM
Rational的系统开发方法是完整的，提供了统一的过程和集成的工具。从广泛的意义来讲，这种方法可以被分为若干个区域：用例与需求；架构、可视化建模和UML；系统工程的过程；配置和变更管理。对于每种区域，IBM
Rational都提供了思想上的指导和工具，利用现代的解决方案来解决现代化的问题。
构建系统并不是一件简单的活动。客户需求的灵活性要求越来越高，还有大规模的团队、许多的项目干系人以及大量业务驱动因素带来的压力，系统开发项目给人们带来很大的挑战。本白皮书介绍了一种整体的系统开发方法。这种整体方法在开发过程的所有阶段都使用明确集成的工件，使所开发的项目减少了整体交付时的风险。最佳实践明确地体现于RUP中--这些实践已经被应用于无数的系统和软件项目中--使用这种方法，即使面对最复杂的系统开发项目也可以取得成功。
参考资料
- 您可以参阅本文在 developerWorks
全球站点上的 英文原文。
|
