【IT168 技术文章】

    如果您的基于 RUP 的项目比较成功，您怎样知道您的团队所使用的 RUP 是这个项目成功的原因呢？这里 Gary Pollice 提出了一个可以科学地度量几个迭代开发技术的方法。

　  在过去两年内我曾不止一次地说过“软件工程”的说法是不恰当的，我们实际上操作的是软件开发。 1 Philippe Kruchtenn 和其它人说区分软件和其它工程学科主要有两点：其一是每个软件开发项目都是唯一的，其二是没有应用于所有软件的基本定律。这难道意味着我们应该放弃所有寻找基本定律的希望，以及开发一个更像工程学的方法来开发软件吗？

　  完全不是。软件仍然是一个年轻的学科，在我们前面仍然有大量基础和应用研究用于发现它的基本定律。我们同样需要明白软件开发的什么部分以及在什么情况下需要遵守更严格的方法。科学的方法需要我们观测现象（与软件相关的），明确表达假设，用那些假设来预言未来的行为，并验证我们的假设是否是正确的。

　  如果您在您的软件开发实践中应用一个过程，您已经应用了这个科学的方法，至少间接地使用了。让我解释一下我表达的意思。

　  首先，您要观察您的组织的或者开发团队的效力。当您看到他们是高效的，但是您认为他们还可以更加高效，您开始思考变化这个过程也许有所帮助。您观察与软件相关的现象并开始明确表达出一个假设。

　  接下来，您要决定运用什么过程。您在这个阶段中真正在做什么，这是以先前项目的观察和经验为基础来决定您的过程选择的。

　  您选择了您的过程，因为您想要提高您项目的成功机率。因此您必须有效地阐明关于这个过程功效的假设。

　  理想情况下，您为您的项目或者团队来配置过程。当您为您的项目选择和配置这个过程时同样要间接地预知您的项目/过程的未来。

　  现在您必须收集数据并用它来证实您的假设。如果这个假设与观察到的现象不相匹配，您必须修订您的假设。有也必须能够执行预言并且反复验证，以此来说明这个假设已经并证实了，等等。可重复的结果在这个科学的方法中是十分重要的。

　  我想详细考虑一下最后这个步骤——收集数据来验证这个过程的益处。

　  让我们设想您确定，以适合于您的组织的任何一种方式，一个项目是成功的。显然，您假定您所选择的过程是这个项目成功的部分原因。您向您的组织发出了关于您成功的消息，并激励其他人为他们的项目使用您的过程配置，如果他们有类似的项目。您有数据——从成功的项目中收集的——来支持您的主张：这个过程（选择它是明智的）是形成这个成功的原因。可靠的推理，不是吗？

　  第二天，您收到执行委员会发来的通知，让您亲自去证实您的主张。您收集您的数据，并给他们一个关于您所收集数据的极好的幻灯片——每一千行代码中的缺陷率，团队的生产力等等——非常清楚地显示了这个项目是绝对成功的。您重复您的主张说，在这个成功中起作用的因素是您选择了正确过程。

　  关于这一点，这个主要执行审查人员盯着您问了您一个您不知所措的问题。“您的团队都用这个过程吗？”您脑海里出现的唯一的回答是“当然，他们告诉我他们都用的，”以及“他们必须使用这个过程因为这个项目是成功的。”您意识到任何一个都不能充分回答这个问题。即使您做了大部分收集项目数据和度量项目的几个属性的工作，但是您没有收集任何关于这个过程使用情况的数据。

　  的确，这个团队的成员告诉您他们使用了这个过程，他们真诚地相信他们的确这样做了。但是那并不意味着他们真的这样做了，尤其是在这个项目的初始阶段，您所选择的这个过程对于这个组织来说是一个新的过程。他们也许在构建系统方面更加小心，只是因为他们知道您将在他们的执行中收集数据。这只是山楂效应（Hawthorne Effect）的一个例子。 2 因此留下的疑问是：您怎样知道去度量什么?

　  度量 Rational 统一过程（Rational Unified Process）

　  当您执行您的实验时，您必须收集关于您所使用的这个过程的数据和实验结果。如果您大力宣扬您的主张，您必须提供足够的信息证明这个实验能够被其他研究人员或者研究团队来重复试验。对这个实验来说，有相同的结果就是正确的。问题又出现了，因为我们经常不知道去捕捉什么数据，在捕捉数据以后，怎样来分析它。带着确定您的团队事实上多大程度上使用了这个过程的目的，这篇文章的剩下部分提出了几个度量您的过程的方法。如果您可以搜集这些数据，那么您可以确定那些技术在您的环境中是最有效的。

　  Rational 统一过程?，或者 RUP?，包含了软件开发各个方面的指导。为了成功地使用它，您必须创建一个适合您的项目的过程配置。绝大多数RUP配置是建立在一系列非常好的实践和其它已经在不同类型的软件上表明是有效的技术上的。 3

　  我们的方法十分简单。我们将选择一个练习来观察几个度量这团队事实上采取这个实践的情况的方法。我们将使用 Goal Question Method (GQM)技术 4 。 我们的目的显而易见。我们想知道，如果这个团队实际上使用了这个过程，接下来我们的决定将取决于我们将要问的一些问题，这些问题的答案将有助于我们决定能否实现目标。最后，我们将决定使用何种度量方法来回答这些问题。

　  难道我们不能简单地问这些团队成员他们是否使用了这个过程吗？您可以，我们也能够这样问，而且也应该这样问，但是这些回答将会是更加主观的而并不客观。事实上，人们时常会告诉您您想知道的他们在想什么或者他们相信什么是真的，无论那是真还是假。例如，如果您问别人他们怎样转到自行车的左边去，他们会告诉您仅仅将车把转到左边自行车就自然而然地转到左边了。但是如果他们想一下这个问题，他们将会告诉您他们也可以将自己的身子倾斜到左边。如果他们十分谨慎地叙述他们自己将自行车转到左边，事实上，他们做的第一件事是将自行车车把转到右边。 这个小小的移动没有使他们转到自行车的左边，而然后把自行车车把转到左边来完成这个转向。也就是说，他们需要的是经验主义的数据——基于对这个团队成员行为的观察或者我们通过其它方法获取的数据——这些数据将使我们能够确定他们是否使用了这个过程以及使用的程度。

　  我们将看看RUP三个基本的区域：需求管理，迭代开发和测试。有太多的区域或者区域合并需要我们去尝试并实施。在这篇文章中我们目的是，为了更好地理解我们的过程，我们怎样选择一个技巧或者方法，并在其中应用一定的度量方法。