time 
设为首页】【收藏本站
当前位置: 主页 > 软件工程 > 需求工程 > 需求分析 > 通过RUP用例进行需求管理的可追踪性策略(一)

通过RUP用例进行需求管理的可追踪性策略(一)

时间:2009-11-14 21:37 点击:487次 字体:[ ]




  1. 摘要

  在许多用例建模技术的商业应用软件中,用例模型必须与更传统的需求获取技术结合起来,从而提供一个让项目涉及的所有涉众均可接受的需求管理流程。本文探讨了组织在采用用例建模技术作为部分需求管理策略时可以使用的可追踪性策略。

  2. 简介/背景

  2.1 可追踪性项

  在讨论需求管理时,特别在使用 RequisitePro 此类工具的时候,“需求”这个词丰富的含义常常使人感到困惑。除了通常定义为“需求”的项以外,我们还需捕获和追踪其他许多类型的项的属性以及这些项之间的可追踪性。这些其他的可追踪性项包括问题、假设、请求、词汇表术语、主角以及测试等等。

  捕获并追踪这些其他类型的可追踪性项能够帮助我们有效地管理项目需求。

  定义:可追踪性项

  需要明确地从另一个文本或模型项进行追踪的任何文本或模型项,目的是为了跟踪两者之间的依赖关系。

  在 RequisitePro 中,这个定义又可另述为:

  在 RequisitePro 中用一个 RequisitePro 需求类型的实例表示的任何文本或模型项。

  RequisitePro 本身提供了一个优秀工具,用于定义、捕获并跟踪值、属性以及软件开发所涉及的多种可追踪性项之间的可追踪性链接。

  2.2 隐含和明确的可追踪性

  任何开发流程都隐含有一定量的可追踪性。这些可追踪性通常由流程中工件之间的正式关系提供。

  这类隐含的可追踪性的示例包括:

  命名约定

  例如,设计模型中名为 Fred 的类由实施模型中的 Fred 类来实现。

  构建模型间的映射

  例如,Rose 中的构件视图允许 Rose 中逻辑视图内的包和类显式映射到实施模型中的包。这种映射可以包含对具有不同打包策略的模型与应用程序之间的重命名。

  模型项本身之间的关系

  例如,在 Rational Unified Process 中,设计模型中的用例实现可追溯至实现它们的用例。

  确立不同的角度来阐明一个模型中的元素如何满足另一个模型的元素所隐含的需求

  例如,设计模型中的用例实现说明了设计模型的模型元素如何通过合作实现用例的方式。这就提供了一个从用例角度说明设计模型的方法,它可以验证和补充设计模型中类和包的静态封装方法。

  所有这些示例都具有一定级别的可追踪性,允许利用开发模型保留的信息执行影响分析。

  如下图所示,受用例驱动的开发包括一系列相互关联关系的模型。

  

通过RUP用例进行需求管理的可追踪性策略(一)_www.fengfly.com

  该图显示了模型以及它们之间的隐含关系。模型之间的关系具有一定级别的可追踪性,它是开发流程隐含的。

  在进行用例驱动的开发时,需要一些支持工件来支持用例模型,并定义完整的软件需求规约。在 Rational Unified Process 中,这些工件是补充规约和词汇表。其他有关的工件还有商业理由以及前景文档,它们包含了项目的需要、目标和特性的定义。

  模型间的关系不涉及这些支持工件,因此就不包含在开发流程内建的隐含的可追踪性之中。

  隐含关系是开发流程的基础,并且它可以从构建作为开发人员工作的一个有机组成部分中受益。这些关系是建模流程的核心,它们需要在模型趋向成熟的过程中进行构建和维护。

  隐含的可追踪性仅限于在建模表示法中可用的关系。

  那么为何还需要明确的可追踪性呢?

  如果我们打算采用需求可追踪性的原则,就需要将需求、模型项及其他可追踪性项集成到一个可追踪性分层结构中。我们最好还要向开发流程添加更多的可追踪性关系。

  下图是一个可追踪性分层结构示例,该分层结构显示了前景文档定义的“特性”与用例模型和补充规约定义的“软件需求”之间的关系。它还显示了软件需求如何追溯至测试需求、设计和用户文档。

  

通过RUP用例进行需求管理的可追踪性策略(一)_www.fengfly.com

  如果我们仔细查看补充需求(在补充规约文档中定义)与设计、实施和模型之间的关系,就可以发现该关系并未包含在模型间隐含的可追踪性之内。

  这是另一级别明确的可追踪性的典型示例,它通常是项目必需的。许多需求由于与用例模型之间存在隐含关系,需要在整个模型系列中进行追踪。补充需求在补充规约里是沿着用例模型获取的,它们不直接与考虑它们的设计模型中的任何包相关,与实现它们的实施模型中的构件也无直接关系。

  其他示例包括以下各项之间的关系:

  - 系统特性与用例模型之间的关系

  - 用例模型与用户文档之间的关系

  - 用例模型与测试需求之间的关系

  在建立需求可追踪性流程时,需要作出的重大决定之一就是确定所需的可追踪性级别,以及达到该目标需要多大的明确可追踪性。我们希望我们的需求、可追踪性和管理的方案有利于开发流程的执行,而不是使之复杂化或对其施加限制。

  可以看到,增加开发工件明确的可追踪性会显著提高项目成本。当考虑到采集和维护这些额外消息的长期成本时,这种影响尤其显著。我们要做的就是为项目确立一个合适的可追踪性级别,使得我们在额外的明确可追踪性上的投资能得到回报。我们的开发人员应该把时间放在开发上,而不是进行追踪。为了达到这个目标,在给项目增加明确的可追踪性成本之前,需要建立可追踪性策略,并对策略进行评估。

  可追踪性策略定义我们希望添加到软件开发流程的明确可追踪性级别。

  2.3 管理支持工件

  上面的图 1 显示了在 RUP 中需求规约所涉及的工件。

  这里要注意,用例模型和补充规约形成了完整的软件需求规约 (SRS) 。这就是说,我们并不需要传统需求管理技术所必需的正式软件需求规约文档。

  

通过RUP用例进行需求管理的可追踪性策略(一)_www.fengfly.com

  下面的图 2 显示了传统 SRS 文档通常如何与 RUP 工件相关。传统的 SRS 仅仅是记录软件需求的一种备用方法。这两种方案都可以为我们提供定义待建系统的完整外部行为的软件需求规约,意识到这一点非常重要。

  这种关系经常被曲解为这两种需求管理模型不能共存。人们经常以为,在使用正式软件需求规约文档的传统需求管理技术,以及基于使用用例模型及补充规约的需求管理技术的用例模型之间,必须选择其一。实际上,在某些情况下,同一项目中存在两种形式的软件需求管理规约是必然。

  2.4 可能的可追踪性策略

  2.4.1 可接受的可追踪性策略是否不止一个?

  有许多可追踪性策略可用于改进需求管理流程,即使在 Rational Unified Process 的框架内,也可能存在多种方案。读者在应用中最常见的策略有四种,分别是:

  1. 唯用例模型

  在这种情况下,用例模型是系统需求的唯一声明。选择这种方案的项目特点在于,客户和开发员之间有紧密的联系和高度的信任。

  用例模型和词汇表以及补充规约形成了系统需求的完整声明 - 不存在其他需要、产品特性或软件需求定义。

  2. 特性驱动用例模型

  这是 Rational Unified Process 推荐的默认策略。用例模型和补充规约形成了完整的软件需求规约。特性记录在前景文档中,并追踪到用例。如果它们未在用例模型中反映出来,则将它们追踪至补充规约的补充需求。

  在这种情况下,用例模型作为功能需求的主要声明。除词汇表和补充需求外,用例模型和补充需求还用需要和产品特性加以完善。

  3. 用例模型是对软件需求规约的一种解释

  在这种情况下,用例模型是对正式传统的软件需求规约的一种解释。由于规章、协议或内部原因而被迫采用正式传统的软件需求规约,以及在必须使用用例模型来启用受用例驱动的开发时,经常用到这种方案。

  追踪至正式软件需求规约文档而不是软件需求的(与传统需求管理一样)特性,随后显式追踪至用例模型中。

  4. 用例模型调和多个传统软件需求集

  用例模型是对来自多个源的软件需求规约集的解释,它提供了单个通用系统的规约。

  在这种情况下,每个涉众都有自己的软件特性和软件需求集,这在他们各自的前景和软件需求规约文档内有详细的说明。这些多样化的观点,以及可能存在的相互矛盾的期望,都需要在单个用例模型中进行调和(该用例模型指定了系统将要执行的操作内容)。这一策略在处理独立涉众的大集合时非常有效。

  在不包括选项 1 在内的所有情况下,我们把用例模型与传统需求可追踪性流程的元素结合起来。

  当然还存在许多其他选项,它们也许根本没有用例模型。我们把这些选项称为“无用例模型”。

  这些方案及其他方案,在下面的可追踪性策略分类中有更详细的论述。

  2.5 为何要采用混合方案?

  可以看到,以上的两种极端方案(唯用例模型和无用例模型)采用的观点极其纯粹,都只允许存在一种形式的需求捕获。两者都假设有一种万能方案可适用于所有的项目和涉众群体。两者方案本都看到了成功的希望,但由于它们在处理复杂情形以及“真实世界”项目中产生的涉众关系集时表现呆板和无能,最终落得个声名狼藉。

  Rational Unified Process 推荐如下的可追踪性分层结构:

  

通过RUP用例进行需求管理的可追踪性策略(一)_www.fengfly.com

  这是上面的“特性驱动用例模型”选项,而且也可能是最有效的可追踪性策略。但应该注意,即使 Rational Unified Process 采用了这种方案,它也并不总是最有效的。

  将用例建模作为功能软件需求规约的唯一机制,这种做法证明是有问题的,有例为证:

  存在许多矛盾的需求源(即许多矛盾的期望需要进行跟踪和管理)。

  承担项目的组织坚持与现有的传统需求捕获流程保持兼容。

  让涉众参加建模专题研讨会,制定一个大家一致同意的需求模型时存在困难。

  采用用例建模技术在现有需求捕获流程的约束下驱动面向对象的软件开发。

  涉众群体不能或者不愿意直接在用例模型内表达所有的功能软件需求级别期望。

  客户确定了产品将以传统软件需求集的形式交付。在进行开发投标的时候,这种情况很常见 - 传统的需求声明成为交付合同的一部分。

  我们认为,应该采用哪个方案必须根据每个项目和开发组织的具体情况来决定这个问题不存在万能的解决方案,那种企图强行将所有项目都用一个需求管理方案来解决的做法是愚蠢的。

  应该记住,Rational Unified Process 是一个可配置的流程,能够处理本文介绍的、不包括“无用例模型”方案在内的所有可追踪性策略(Rational Unified Process 的用例驱动本质排除了采用该选项的可能)。在编写 Rational Unified Process 开发案例的过程中,其中决策之一是决定采用哪种方案。



本文地址 : http://www.fengfly.com/plus/view-153244-1.html
标签: 追踪 策略 管理 需求 通过 进行
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: