CMM实践-利用Rational RequisitePro进行需求管理
2005-10-19 10:31
381 查看
CMM实践-利用RequisitePro进行需求管理
需求管理中的问题
在CMM3中需求管理(RM)关键过程域是非常重要的一个环节。在我们公司CMM3级的实践中,需求管理往往是非常花费成本的一个工作,比如,在需求分析、建立需求跟踪矩阵等活动中,如果是一个团队或是几个小组在进行协作时,会有大量的Word、Excel文件需要在不同的人员间传递,其间即使用了类似VSS等工具,仍然没办法避免繁琐低效的工作方式,其间会产生例如文档传递不顺畅、协作人员的需求用例重叠、扩展需求遗漏等等问题,在实施CMM3时,此环节更为公司增加了大量运作成本。比如,在多人协作完成需求分析,对所有需求用例进行管理的活动中,需求人员只能根据前面的需求调研报告,所有的人使用同一份Word文档模版,分别详细分析与描述属于自己任务内的需求用例,然后负责人再把每个人写好的Word文档进行合并,这种合并完全是手工的合并,同时,对于每个人需求分析的情况,只能阅读所有的文档内容才能检查出是否有所遗漏等严重问题。
再比如,公司在使用最原始方法建立需求跟踪矩阵时,往往是用一个Excel表,列出一个二维表,把软件生存期的几个阶段做为几列,例如“需求”,“设计”、“编码”、“测试”、“发布”等,然后首先由需求分析人员在第一列的“需求用例”上,列出所有的需求点,然后再把这个Excel表交给设计人员,再由设计人员在第二列的“设计”上,列出每个需求对应的设计项,这样一直传递下去。其间这张表也不知经过了多少人的手,一旦其中某阶段一项做了修改,很难安全保障正确的向前追溯。
如果为了解决以上问题,公司自行开发一些管理工具,仍然需要花较大成本。
Rational RequisitePro特性
IBM® Rational® RequisitePro® 解决方案是一种需求和用例管理工具,能够帮助项目团队改进项目目标的沟通,增强协作开发,降低项目风险,以及在部署前提高应用程序的质量。通过与 Microsoft® Word 的高级集成方式,为需求的定义和组织提供熟悉的环境
提供数据库与Word 文档的实时同步能力,为需求的组织、集成和分析提供方便。
支持需求详细属性的定制和过滤,以最大化各个需求的信息价值。
提供了详细的可跟踪性视图,通过这些视图可以显示需求间的父子关系,以及需求之间的相互影响关系。
通过导出的XML格式的项目基线,可以比较项目间的差异。
可以与 IBM Software Development Platform 中的许多工具进行集成,以改善需求的可访问性和沟通。
在CMM实践中Rational RequisitePro的灵活应用
通过上面列出的特性,可以看出,此软件是一个功能很强大的需求管理工具,我们可以利用它的一些特性灵活的处理CMM3级中有关需求的一些操作性较难的活动。对于多个人使用Word进行需求分析时,可以利用此工具的与数据库、Word文档的实时同步能力,及多人协作能力,把需求进行组织、集成。
对于建立需求跟踪矩阵,我们可以利用它的具有非常丰富的可跟踪性视图的特性,按照我们原始的方法,把Excel二维表中每列的阶段项分别设置为一种类型的需求。比如“Use Case 需求”、“设计”、“编码”、“测试”这几种自定义类型需求分别添加成四列。然后,再把这些需求项连接到Word文字段。比如“设计项”可以关联到Rose中的Use Case项或是关联到设计文档中相关的段落。
这时,项目组的需求人员就可以利用RequisitePro来添加第一列的“Use Case 需求”了,需求都添加完了,设计人员也可以使用它来添加“设计”这一列的项,而这些操作完全不用再传递某个Excel文档了,只要使用RequisitePro打开同一个项目即可。同样,项目组进入到不同的阶段,就可以让相关的人员使用此工具在此项目中进行添加与修改。
这样,我们就可以进行需求覆盖分析。通过建立视图的方法,对“Use Case 需求”、“设计”、“编码”、“测试”等我们定义的需求类型间的覆盖程度进行分析,即某个阶段的记录是否可回溯(可跟踪到)到某个Use Case 需求项,即由果->因。
特别地,也可以产生从阶段项可以到Use Case需求项的回溯跟踪矩阵,带红线的箭头表示suspect(可疑)的跟踪,即若存在跟踪关系的二个项中的任何一个独立修改后,requisitePro将自动标记为可疑跟踪,以提醒注意。
以上仅仅举了个Rational RequisitePro的例子,总之,灵活使用工具,可以很大程度上解决在CMM3实施过程中很难操作的一些问题,减少实施成本。
CMM的实施过程中要善于利用工具
我个人认为,在实施CMM的过程中是不能本本主义,生搬硬套的,否则会使实施成本巨大,怎样在实践中利用工具更好的解决问题是最重要的,当然,对于不同的情况可以使用不同的工具,这就要充分发挥实施者的能力了,从这一点上说,CMM只告诉我们应该做什么,但没有告诉我们应该怎么做却是有道理的了。因为同样一个目标,会有非常多的方法去实现,对于一个CMM实施者来说,他相当于一个改革者,就像我们国家的改革一样,没有什么西方已有的方法是最好的,只有通过自己的实践找到最适合我们自己的方法才是成功的关键。Rational RequisitePro使用方法介绍
Rational RequisitePro是一款不错的需求构建、管理工具,这里以RequisitePro自带的例子Learning Project-UseCases为例,简要说明部分使用方法。1.打开项目的模式
当需要(这是由requisitePro决定的)修改某些project属性时,需要选择该模式,这时当前用户为该project的唯一用户。不过一般情况下,无需对“Open Project Option”做任何选择,在requisitePro检测到你将修改某种project属性只有在Exclusive模式下才可执行时,requisitePro将给出对话框供你确定“Exclusive”模式。
2.界面元素
通过可视化的图标可以确定相应的概念。
这里仅对Package、Document(word文档)、Requirement(需求)、View(视图),作出说明:
1) Package:是需求的组织机制,与UML中的包在概念上基本类似,Package还可以包含子Package、Document、Requirement、View。
2) Document:这是呈现打印版需求文档、也是需求编写的一个重要方法。一般通过在Package图标上的快捷菜单建立word文档,并在word文档中对文本进行选择,以建立自动编号的UC事件、TERM项、FEAT项等。可以说Document是需求的容器。文档在requisitePro中被类型化。
3) Requirement:主要指UC事件、TERM项、FEAT项等。
4) View:在创建完自动编号的UC事件、FEAT项后,就可以对这两种需求进行分析,而分析的可视图就是通过View来实现的,View基本上就是一个查询的结果,在requisitePro中可通过设置查询的需求类型和其属性来得到特定的视图,如根据需求优先级进行需求排序。
3.通过包组织需求文档
在构建基于Use-Case Template的需求管理project时,一级包名如下:
1) Coverage Analysis包:需求覆盖分析。通过建立视图的方法,常于用于对UC事件、FEAT项这两种需求类型实例间的覆盖程度分析,即某个UC事件是否可回溯(可跟踪到)到某个FEAT项,即由果->因。
2) Features and Vision包:特点和前景。这是高层的需求,这是相对use case规范文档而言,相当于系统overview:有主要特点、关键的风险承担人的需要、关键服务。
3) Glossary包:术语。对本应用领域的术语。如应用领域的角色。基本上是与计算机无关的概念。
4) Impact Analysis包:影响分析。以视图的方式显示需求间(如:UC事件、FEAT项)的前溯关系。与Coverage Analysis包不同的是本包存放的是需求的正向跟踪矩阵,以表达需求的影响链,即由因->果。
5) Supplementary Requirements包:补充需求。这个词语不是很准确,因为该包存放的是无法由单个use case规范文档表达的需求,即非功能需求,如:可移植性、可重用性、安全性、可伸缩性等,这些需求一般对多个use case规范表达约束。
6) Use Cases包:用例。存放use case规范文档,描述的是功能需求。
4.文档类型
通过对需求文档进行类型化,以标识不同的需求、文档的格式(通过文档类型所对应的文档模板做到这一点)。
主要用到3种文档:
1) Glossary Document Type:术语文档类型。
注意:双下划线的段落存放在requisitePro项目所对应的DB中,其它的段落只保存在该word文档中(但扩展名为GLS),故requisitePro将保持双下划线的段落与DB的双向同步。
2) Use case specification document type:use case规范文档类型,专用于陈述某个use case。
use case规范文档的目录中,可以看到基本流程、可选流程、特别的需求(一般为非功能需求)、前件、后件。这种类型的文档表达use case图中的某个椭圆(即一个use case)的详细内容,详细内容主要是该use case所涉及的交互事件(UC项)、该use case执行的前件、后件。一般可在该文档后附上一张use case图以概要地描述该use case与其它use case间的关系。
上图是该类型文档的一个样例,其中陈述了:可用性、易用接口、培训、等非功能需求。作为链接到use case 规范文档包,其中有功能性一项。
5.需求类型
这里的需求类型是对在word文档中可被存入DB的段落的类型化。注意:这些类型通过前缀表达其含义:
FEAT项:标识某个特点段落,其一般存放在vision.VIS文档(word)中。
(双划线的段落将被存放入DB)。
其它的需求项,与FEAT项类似。
6.需求项的属性
所有requisitePro元素都有properties,但只有需求项拥有attribute(需求属性)。
FEAT项:FEAT: product Feature的需求属性,从中可设置其优先级、难度、状态、稳定性等。
通过建立视图查询,可以将某个包中的所有需求项例出来。
7.视图类型
有三种视图类型:不同类型的视图,可从其图标上分别。
1) attribute matrix:属性矩阵.
2) Traceability Matrix:跟踪矩阵
从UC项到FEAT项的回溯跟踪矩阵,带红线的箭头表示suspect(可疑)的跟踪,即若存在跟踪关系的二个项中的任何一个独立修改后,requisitePro将自动标记为可疑跟踪,以提醒需求分析员注意。
3) Traceability Tree:跟踪树:基本上是跟踪矩阵的树型表示。
8.在word中建立需求项
以建立UC项为例,在word中建立UC项。虽然也可在requisitePre界面中建立UC项,但该UC项不会自动出现在word文档中,故推荐采用在word中建立UC项的方法。
1)选中待建立UC项的word段落
2)打开new Requirement并进行设置
a) 设置UC项名
b) 设置hierarchy
设置该UC项的父UC项,用于供requisitePro自动计算该UC项的编号:
c) 设置其它属性后,并保存文档
在requisitePro中就可看到该UC项了。
9.对团队开发的支持略。
相关文章推荐
- 使用 Rational RequisitePro 进行需求管理的新技术
- 使用 Rational RequisitePro 进行需求管理的新技术
- 使用 IBM Rational RequisitePro 进行项目执行管理
- 利用 IBM Rational Suite AnalystStudio 进行迭代需求管理
- 用Rational Rose 和 Rational RequisitePro进行用例管理
- 集成 IBM Rational RequisitePro 与 IBM Rational Portfolio Manager
- 最大化利用内核资源进行Linux驱动开发--摘自《嵌入式Linux驱动模板精讲与项目实践》
- [Android Pro] 利用tcpdump和wireshark对android网络请求进行分析
- Android开发实践:利用ProGuard进行代码混淆
- 下载了一个用IBM Rational软件开发平台进行SOA开发的实践指南
- 利用深度学习方法进行情感分析以及在海航舆情云平台的实践
- 利用Rational对.NET程序进行建模(来自网络)
- 利用aix.unix-center.net免费平台进行 Aix 5L命令实践(一)
- 利用Jmeter对简易投票系统进行刷票的实践
- 利用深度学习方法进行情感分析以及在海航舆情云平台的实践
- 使用 IBM Rational RequisitePro 和 Rational ClearCase 为 DB2 9 开发 SQL-XQuery Web 服务转换器
- IBM Rational RequisitePro
- 转:利用深度学习方法进行情感分析以及在海航舆情云平台的实践
- 在IBM Rational RequisitePro - RequisitePro 项目管理员中初学者的常见错误
- 用Rational RequisitePro写用例规约(Use Case Specification)的心得