UML软件工程组织

级别: 初级

Laura Rose
质量保证, IBM Rational

在Rational看来：生产一个高质量的产品，必须有一个过程，它包括了所有贯穿软件开发生命周期内保证质量的项目参与者。

无论有什么样的背景和经验，软件开发专家认为你需要有一些成功项目的知识：产品，员工，客户，计划。当然，知道这些仅仅是开始。在实际操作中我们还是经常被问题绊倒。在这个案例研究中，我会通过详细说明一个新产品的软件开发过程，来与你共同分享一些我们在IBM Rational的开发项目中使用的方法和工具，以提高我们的效力。

熟悉产品
这是很显而易见的。但是在IBM Rational，我们必须懂得，为了真正了解一个产品，你必须在它的生命周期里持续地进行质量保证。这点无论对于是从经销商处购买的产品包，还是你自己开发的商业软件都是适用的。一些已知的关于持续质量保证的经验包括：

开发高质量的需求并复审需求
经常地并且及早测试
根据需求和业务模型跟踪特性
分析缺陷的根本原因并防止更进一步的缺陷

这些实践由IBM®Rational 统一过程（或RUP）所包含，它指导了我们的开发活动。正如图1显示的，RUP把项目工作分为四个阶段：先启，精化，构建，产品化。正如我们开发的Rational产品，我将会描述每个阶段的质量保证工作。

Figure 1: RUP phases, iterations, and activities

图1：RUP阶段，迭代，和活动

开发并复审产品需求
在项目的开始，业务分析师和产品经理提供了适合市场时限的一个很长的功能列表和产品交付时间点。失去这个市场时限不仅意味着失去了今年的销售，同时也意味着我们的竞争对手在我们的客户中逐渐建立了客户关系。

那么，一直等到团队的产品经理，开发人员，测试人员，和技术文档编写者削减了需求的数量(主要由一条描述组成)，基于他们对业务问题的理解和哪些功能才可能在确定的时间点内完成。只要列表还是易于管理的长度，我们就可以精练并补充这些描述直至一个清晰的需求描述，并基于每个需求所需要的工作量及其业务优先级为他们分配高、中或低的等级。在这个阶段，我们只包括几个管理者，因为我们只有一些不多的详细资料。

把需求列表区分出优先级后，我们邀请更多的团队成员加入进来，包括一个技术团队，评估每个需求的可行性和风险性。一个设计团队定义原型，为共同的组件共享结构，运用IBM Rational Rose 和UML（统一建模语言）描述组件的交互和它们之间在个案流程的影响。当我们逐渐了解了更多的关于潜在的特征集，我们可以远离或提炼团队的风险。

在精化阶段，我们确定了系统构架和主要的需求，以便为构建阶段的主要设计和实施工作提供一个稳定的基础。我们所开发的产品是一个更大产品包的一部分。尽管这些需求并没有增加产品或特定顾客的价值，但是我们不得不花费时间和资源去执行，测试，并且更早地完成文档。这意味着削减特性列表。在精化阶段结束的时候，我们开始使用IBM Rational RequisitePro维护需求，它是需求管理的工具。

我们计划在构建阶段为产品进行三次迭代；团队为每次迭代定义了一个子集。使用Rational RequisitePro，我们不断复审并更新最初的特性到计划中，通过每个构建周期修改并评估需求。

在精化阶段结束时，通常我们完成了需求文档，尽量清晰的描述需求。根据过去的经验，我们知道通过模糊的需求定义，特性和系统缺陷会大量出现在测试结果里。我们知道，如果我们能在产品设计的早期发现缺陷，我们就能节省大量的时间和资源。

为了减少含糊不清的需求规格和文档，我们使用一个简单的检查单“好的规格属性”和“谨防有问题的词语”（参见附录A）。运用这些指南来管理需求的复审，从而形成更好的设计文档。

在特性级和系统级测试中所涉及的开发人员
我们曾经提到的策略“尽早并经常地测试代码”是一项为开发者提出的最佳实践，无论是在特性验证还是产品的验证（系统级）测试中。在我们的项目里，有三十个开发者，但是仅仅有四个测试工程师，因此就会有这样的观点：三十个开发者开发的功能很容易就超出了测试的工作量。

我们的开发人员与测试人员的合作产生了很好的结果。我们有一个自动测试架构，它可以自动运行单元测试以及功能级的测试用例（无论什么时候创建了的构建它都可用自动运行）。通过使用这个框架，开发者更多地学到了如何“打破”软件，并且测试人员获得了关于产品如何工作的详细知识。随着理解如何管理测试，通过确认某个数据点，开发者能设计更多的供测试用的代码。开发人员和测试人员共同使用IBM Rational PureCoverage产生一个代码覆盖矩阵。这使得我们通过不同的构建迭代增加了测试覆盖率。

开发人员和测试人员同样分享其它的工具：Rational TestManager来管理测试集，并标识测试结果，同时Rational Application Analyzer分析应用并记录测试结果来复审迭代出口标准。开发人员和测试人员共同参与报告测试结果，并能汇集这些标准。

了解员工
我们都知道定义不清的需求和低效率的沟通，使得变更对开发人员是件令人头痛的事情，开发人员必需为满足交付期限和质量标准进行努力。然而，一个软件开发项目包括了很多开发领域之外的内容：业务分析，项目管理，配置管理，测试，以及技术文档的编写，每项都有自己的难处－－但是需要相互衔接－－涉及的质量和主要的观点（请参见附录B））。例如：

业务分析需要努力写出好的需求规格，有效的沟通需求及其变更，同时正确地解释客户的需要。
当测试人员不能参与到需求确认时，他们应该尽量评估软件的质量，同时满足交付的期限。

糟糕的软件质量是一个业务难题，这会影响到一个组织的每个部分。一个软件的生命周期过程，承认并对每个独立的部分提供处理方法，能够很大地提高不同涉众的沟通，同时提高组织者的质量能力。

在上面我们提到的其它方法，包括了在产品开发过程中的测试计划复审，减少核心工作人员的工作复杂度。我们的目标是让每个人都认可测试的计划，而不是只让少数关键的人知道它。每个人都已经超负荷了，复审没有明确地安照计划时间表进行，并且很难定义，相比“快速读完就说完成了”，什么是一个“好的复审”。另外，很多核心的工作人员没有依据测试计划来完成他们的工作。

为了弥补参与人员的问题，项目团队减少了必需的复审人员的数量。我们注意到如果我们能把计划分派给更多的人来复审，我们只能收到很少的意见。可能每个人都想“其它人”会给出一个复审意见，所以他们就可以不做了。但是，如果我们只向每个主要部门询问一个典型的代表，他们会感到要负责任地代表他们部门的兴趣和目标给出意见，这样他们会更负责更认真地完成。

一旦我们减少了所需的复审员名单，我们会注意到每个复审员的反馈。我们每周召开会议，制定详细测试计划。在这些计划里，我们会展示给复审员如何评估他们的观点，详细的测试区域如何关联到他们各自的工作。比如，我们为技术支持人员提供一个机会，使得产品开发后他们能有足够的产品支持技能。对于产品经理和业务分析人员，我们强调客户的流程和客户应用环境，后来会应用到beta环境中。对于开发者，我们描绘了共享的测试环境和平台，可以在构建周期内进行单元测试和功能测试。

让人惊讶的是，最大的抱怨者是管理复审的测试人员。这个过程需要时间；他们说，仅仅给一大组人发布一个测试计划并等待他们的意见是容易做到的。但是如果没有意见反馈，我们会轻松地说，“这不是我们的错。我们给了每个人复审我们计划的机会，但他们并没有做”。然而，这样的策略首先与管理质量测试计划复审的根本原因是相反的。

了解客户
专家们通过不同的方法定义了质量，但是最基础的问题是，“产品满足目标客户了吗”？保证客户满意最好的办法，同时也是控制费用的办法通常是得到客户的输入。你会采用什么办法？这里有一些我们使用的方法：

邀请客户参与你的设计；要求他们直接到开发团队。
把握客户关注的组。
安排用户访问你的站点。
收集beta配置的反馈并管理调查。
要求客户进行启发式的界面复审。
要求客户提供竞争性的简短描述和正式复审。
基于你的场景和需求来管理里程碑。
邀请客户进行目标系统可用性的评估和确认。

对于我们所开发的产品，易于使用是我们的一个主要目标，因为自动化工具在这个产品的市场里有时使用起来是复杂的，同时还产生复杂的报告。因此“易于使用”意味着不同的用户，从用户那里得到的意见是极为重要的。对于每个构建迭代，我们有不同的用户致力于集成。我们并没有等到产品开发完成或在开发阶段。我们为技术支持团队提供了测试用例，并安装了文档，他们会在产品发布后提供产品的支持；我们为培训团队集成了包，他们会为客户提供产品的课程；同时我们为支持人员发去了相似的包，他们为客户站点提供反馈。我们从不同的团队搜集意见并跟踪他们，使用IBM Rational ClearQuest作为我们的缺陷跟踪工具。

我们也为每个迭代周期进行可用性的研究，从精化4阶段开始。可用性专家经常复审产品，并且在每个迭代出口时提供正式的评估报告。

另外，我们通过IBM的内部产品部门来进行产品的性能测试。我们在精化和构建阶段为易用性问题指派为最高级别的问题，同时在相同的阶段开发人员对缺陷进行修复。直到关闭了所有问题的用例，我们才允许完成这次迭代。最后，我们每周请高层管理者关注产品的可用性和易用性的变化。

了解时间表
管理开发进度最大的挑战在于“唯一不变的就是变化”。防止计划失控最好的办法是对软件交替进行开发和测试。通过在里程碑处体现你的努力，让用户尽早证明评估产品的结果，你可以消除风险和缺陷，当花费不多时进行变更，从而保证你集成的产品是用户真正想要的。

不仅仅在每个迭代详细描述，在构建阶段中我还要关注我熟练做什么。

我们所开发项目的构建阶段包含了三个迭代，每个迭代都包括这些活动：计划，编码，特性验证测试（FVT），缺陷修复，和评估（参见图2）。

Figure 2: Activities in project Construction iterations

图2：项目构建迭代里的活动

构建迭代是交替的；计划活动在第二个迭代里－－构建2（C2）－－和第一个迭代的最后一个活动同时发生，或者是构建1（C1）。由于构件的独立性以及项目里的人员数量，这是必要的。这也是维护计划的有效方法。例如，开发人员不是必须要在C1中提交特性或修复缺陷，就可以进行C2的工作，而不是一直到C1结束都保持空闲。

在早些时候，我接触的所有任务都是在构建阶段完成的；图3总结了在每个构建迭代的阶段，随同他们相应的任务。在每个迭代完成前，我们复审了所有的工件和结果，验证了他们满足我们的出口标准。

Figure 3: Construction iteration tasks for Rational software product development project

图3：Rational 软件产品开发项目的构建迭代任务

总结
本文仅仅讨论了发生在IBM Rational的软件产品开发，用它的度量做持续质量保证。我希望我充分描述了所有项目里的人。每个人都关联到了项目成功所要求的基本知识领域中的一个：产品，员工，客户，和计划。

在整个软件开发过程中建立一个过程主要是为了创建高质量的软件。这个案例研究证明了一个迭代的过程怎样能保证所开发的产品只有最少的缺陷，有效的操作，并且包含用户所需要和希望的功能。为了学习到更多的有关如何持续保证质量的方法，一定要阅读在The Rational Edge中的 “软件质量的商业价值” 和 “为你的业务需求构建正确的软件开发基础”的第三部分文章中的相关内容。

注意：附录C展示了本文讨论到的我们在开发产品中所使用的自动化工具。

参考资料
Keith Eades 和 Jeff Fisher， The Formula that Helps Win Sales. （讨论痛苦链。）No Boundary Press, 2000, ISBN: 0964501392.

Mike Perks, "IBM Best Practices for Software Development Projects."可以在以下得到： http://www.computerworld.com/managementtopics/management/project/story/0,10801,85198,00.html

Andy Owen, "Best Practices for Software Development."可以在以下得到：http://owen.typepad.com/tt/

Ron Patton, Software Testing。

Cem Kaner, James Back 和 Bret Pettichord, Lessons Learned in Software Testing。

Tom Gilb, Principles of Software Engineering Management。

Murray Cantor, Software Leadership: A Guide to Successful Software Development。

Tom Mochal 和 Jeff Mochal, Lessons in Project Management。

Philippe Krutchen, The Rational Unified Process: An Introduction。

附录A：需求复审工具（来自Ron Patton的软件测试）

需求复审检查单
再次测试的功能列表：