• 软件测试技术
  • 软件测试博客
  • 软件测试视频
  • 开源软件测试技术
  • 软件测试论坛
  • 软件测试沙龙
  • 软件测试资料下载
  • 软件测试杂志
  • 软件测试人才招聘
    暂时没有公告

字号: | 推荐给好友 上一篇 | 下一篇

使 RUP 的剪裁简单化:引入职责矩阵和工件流[1]

发布: 2007-5-14 14:28 | 作者: Remi-Armand ... | 来源: IBM Rational | 查看: 66次 | 进入软件测试论坛讨论

领测软件测试网

  本文来自于 Rational Edge:作者提出了一项将 Rational 统一过程进行剪裁的技术,以适应软件项目具体需求,即使外聘的 RUP 专家不熟悉本公司及其文化。

  设想您是一个 IT 部门的经理,该部门的软件开发职员在满足市场需求的过程中需要更多灵活性。过程的级别应该通过开发的范围和分布、项目的技术复杂度,及文档的需求进行平衡。您采用的方法应该着重于在早期减少 风险,包括技术风险。通过引入迭代开发,您将争取增加最终用户的满意度。要满足这些需求,您和您的开发 团队已经决定在您未来的项目中使用 Rational Unified Process?,或称 RUP?。您已经做出了一个重要的决定,但现在您有更多的决定要做,尤其对不熟悉 RUP 的 项目经理来说是个挑战。

  进退两难

  RUP 包含一个工件扩展库,其中有许多您不需要的东西。没有一个组织需要全部的内容。事实上,RUP 最新版本(7.0)的第一个关键原则是“使过程适应组织和项目”,所以您需要将 RUP 按您的组织及其项目的大小和需求进行剪裁。这样剪裁的结果是 RUP 的一部分,被称为开发案例(development case)。在开发案例中,您将描述在项目中使用的所有活动、角色、工件和模板。

  每个所选择的支持工件(可交付的)都将需要 资源来生产它。向开发案例中添加的每一项元素都应该根据期望的效益进行平衡,您需要考虑的方面包括:时间节省、质量获得,或为项目评估、计划和范围管理提供的基础。换句话说,开发案例太大将会不必要地浪费项目的钱。问题是:您如何继续让您的开发案例正常?您打算自己找出如何剪裁 RUP 的方法吗,或者您打算从外面雇佣一个 RUP 顾问或过程工程师吗?自己处理 RUP 的裁剪,让您的团队等着您的指导,在缺乏剪裁 RUP 的内行经验的情况下,这样做是很困难的。您将不得不花费一些时间来找出哪个工件要被略去、哪个要被添加,并且确定应该如何用它们来适合您的项目,或组织。事实上,您需要了解 RUP 的全部才能够以合理的方式对它进行剪裁,因此您将在将来的六个月中非常繁忙。

  另一种方法,您可以雇佣一个 RUP 顾问,一个可以在什么工件是强制的,以及在特定的情况下只需要哪个工件的方面指导您的人。顾问可以帮助按照您的需求修改 RUP 模板,并最恰当地将它们用于创建有用的工件工具。但是外部的 RUP 顾问对您的业务的了解是有限的,更不要提您的组织或公司的文化。这意味着顾问将使用相当多(昂贵)的时间了解您的业务 —— 否则,结果将是剪裁出来的开发案例并不符合您公司的需求和特性。

  我们已经扮演过外部的 RUP 顾问的角色,并且为各种各样的公司成功地定义了开发案例。作为顾问,我们相信剪裁 RUP 的外部专家经验的价值,并且我们已经开发了帮助加速剪裁过程,并且与此同时描述组织具体需求的技术。我们将介绍两个概念:职责矩阵和工件流。

  职责矩阵

  我们基于建立“什么”和“谁”利用面向目标的方法来剪裁 RUP。我们开始研究项目应该交付 什么 (哪些工件)。由工件开始的一个很大的优势是工件是有形的东西。通过观察哪些工件获得的基线状态(已经被正式地批准)可以很容易地检查项目进展。

  工件必须总是有用的。这可能听起来微不足道,但是在许多情况下,我们发现了由那些不知道工件用途的人撰写的工件。我们经常提出的问题是,“如果没有工件被生成,将会出现什么问题?”这个问题的答案澄清了工件的目的。如果您不能找到此问题的具体答案,那么有很大可能性此工件是多余的。

  在决定生成哪个工件之后,我们研究 谁 (哪个角色)负责创建每个工件。我们将工件、角色和职责一起放入我们的职责矩阵中。我们在最左边的列放工件,在最顶端的行放角色。在交叉部分我们放上表示各种职责的符号。这就形成了如图 1 所示的矩阵。

  
 图 1:职责矩阵实例

  工件的作者不仅涉及创建此工件的那个人。要完成矩阵,我们还要研究哪些角色支持创建过程,以及哪角色些负责正式地接收一个工件。通过访谈、讨论会和评论的方式能够支持角色给出输入。当然,我们能够识别出细粒度的职责,但这很少有用。注意,负责工件(将其写在纸上或汇集工件)的角色是实际的作者。由于这涉及特殊的技能,因此该职责不容易委托。例如,我们要注意的是不要将太多的工件分配给项目经理。他或她应该只撰写并负责管理工件。

  职责矩阵将使简化我们得到适当的开发案例的过程。它提供了许多优点:

  ◆我们可以在所有涉众出席的一个(或多个) 会议上填写职责矩阵。这使其成为每个人都同意的联合工作。
  ◆我们不需要对业务有很多的了解来支持职责矩阵的创建。
  ◆职责矩阵可以被用来作为开发案例的一部分,以非常简洁且易读的方式提供对所剪裁的 RUP 的主要构建模块的概述。

  填写职责矩阵

  职责矩阵可以通过不同的方法填写。我们将看一看其中的三种。

  策略 1:从 100% RUP 开始

  通常的起始点是一组 标准的 RUP 工件和角色。RUP 顾问对组织中需要什么 RUP 工件和角色进行有根据的推测,并填写职责矩阵中的所有职责。该职责矩阵随后用作与涉众进行讨论的基础。

  然而,该方法有两个不利方面:

  与公司经验不相关。职责矩阵没有使用涉众熟悉的角色和工件。
  从涉众的观点出发,RUP 引入了所有的新词汇。因此职责矩阵很难让人理解。这各问题可以通过给人们具体的 RUP 培训,按照开发案例来剪裁来解决。

[1]  [2]  

延伸阅读

文章来源于领测软件测试网 https://www.ltesting.net/

21/212>

关于领测软件测试网 | 领测软件测试网合作伙伴 | 广告服务 | 投稿指南 | 联系我们 | 网站地图 | 友情链接
版权所有(C) 2003-2010 TestAge(领测软件测试网)|领测国际科技(北京)有限公司|软件测试工程师培训网 All Rights Reserved
北京市海淀区中关村南大街9号北京理工科技大厦1402室 京ICP备10010545号-5
技术支持和业务联系:info@testage.com.cn 电话:010-51297073

软件测试 | 领测国际ISTQBISTQB官网TMMiTMMi认证国际软件测试工程师认证领测软件测试网