SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 5993|回复: 1

[推荐] 使用 IBM Rational System Architect 工作区来实施 DoDAF 2 架构

[复制链接]
发表于 2012-1-5 11:45:50 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2012-1-5 11:53 编辑 + R) k) l3 \9 \
" C3 t5 t- ?  g" n! Z7 g% j/ \
工作区简介+ [& f/ }. n7 ]) H2 y+ A4 Y1 p
基本概念
) ^2 s$ ~0 s' i通过实施工作区,您可以在 IBM® Rational® System Architect 之中建模架构的多个版本。您可以为以下的场景创建不同版本的架构:0 K* \# R8 T& s! I8 }2 U
  • 实施一个企业架构
  • 实施一个当期以及未来的架构
  • 集成系统的系统架构
  • 执行交易分析: \. [2 a5 _, C$ E  c; @
工作区的概念非常简单。工作区在概念上与词典非常类似。实施工作区使得您可以打开不同版本的词典。一个工作区的更改不会影响到其他的工作区。这提供了追踪性,原始的和后续的词典版本之间的比较,以及工作区合并(查看 参考资料 部分以得到怎样实施工作区的指示)。! t' E2 N6 z- S
它们工作的方式也很简单:
0 K9 z$ g& Q( \" ~& x& u, J
  • 创建了一个只读模式的基线,它包含了不会变化的信息(例如,一个公司名的列表)。
  • 然后在创建工作区时,来自基线的信息会拷贝到工作区之中。
    : g4 @/ ^) u& ]8 v
您可以更改或者细化工作区之内的信息,而且您可以在工作区内或者跨工作区内进行报告,以进行分析。
% u# ]& {6 f7 _7 }3 X. f% Y) i  Z! x9 \' Q
图 1. 工作区概念
: N; ?4 h8 o) ]7 X2 f , |3 I3 x- O8 b# e- x$ A

/ U: Y" P; C% `3 k( R7 F5 p记住与工作区相关的以下信息,这一点非常重要:
5 L0 p9 w, t! L! Y+ X( V
  • 一个词典只有一个根(基线)工作区。
  • 从根工作区创建的所有工作区都继承了父类的基线;因此,它们继承了所有的图表与定义。
  • 您可以查看一个词典基线,但是您不能编辑它,因为它是只读的。
  • 用户一次只能打开一个工作区。当您更改档案工作区时,活动工作区之中所有打开的项目都会关闭掉。
  • 多个用户可以在相同的工作区内建模。
    . e4 u/ l( t! u4 e) K
您还考虑以下的这些工作区限制:
. }0 O, q5 G- \1 Y
  • 不想要使用多个词典,并将它们放到伪文件架构下的词典之中
  • 不支持在单个的词典中不同的属性设置(所有的工作区使用相同的 usrprops 文件)
  • 不要为对象使用 包裹 或者 名字区域(支持超过一个对象拥有相同的名字)
  • 不支持在更高层次上访问控制分组
  • 不要用于解决正交性的问题  V$ E2 J# [( p3 L  u1 L8 A8 j1 b


/ s2 y$ z( ]) _* l* `1 S) D, ~( z' F1 X( }" ?6 y
为工作区开发规范以及非规范的 DoDAF 2 架构
% ~/ o2 X3 c8 H本文中的场景基于 规范 以及 非规范 架构的概念,以及那些架构中所包含的内容,如 DoDAF 2 标准所述。这一部分提供了关于规范架构层以及非规范架构层的信息,并描述了使用工作区建模架构的常用方法。2 H+ r4 Z/ {1 t# Y  o+ y9 V
在 DoDAF 2.0 之中定义有三种规范的架构层:3 D8 R1 V  T7 B& N$ O( j9 n! T+ v
  • 开发架构 为其他的两层提供了治理功能。它是在机构性层次或者联合员工层次上开发的,例如,它可以是整个美国海岸警卫队或者只是海岸警卫队一个部门,例如后勤部门的架构。它应该包含全局信息格以及 DoD Information 企业架构,以确定低层的架构也考虑了需求与其附属。部门层次的架构就是定义的视图与任务。
  • 功能或者部门架构 描述了以下领域特定功能的使用:- F# W* K, F# B8 E$ J- m4 t3 B
    • 业务(例如,后勤部门开发员如何执行日常任务)。
    • 获取(需要获得什么构件或者服务来满足后勤部门分配的功能)。
    • 战术操作 (例如,定义一个架构以描述后勤部门是怎样为国家安全支持执行操作的)。该架构介绍了日常的业务是如何完成的,对于特定的机构单元,或者特定的环境(例如在伊拉克进行一场战争)。; O' ~/ K1 S. e* x4 u
  • 构件架构 查看特定的需要(例如,什么时候为国家安全执行操作,后勤部门需要什么系统或者服务)。这就是为操作性环境支持技术和服务定义的地方。构件架构显示了需要什么新型服务和技术来支持操作,或者当期使用什么服务和技术。这就是传统的“项目”架构,或者 方案 架构。6 Q& u  K6 X0 q) Q
这三个层次有助于控制架构之中的模型元素,以创建对术语的标准使用。例如,机构性单元是在部门层次上定义的。当您在创建一个功能层次架构时,它应该重复使用部门层次已经定义的机构性单元。这可以加速建模,并使得它变得更加精确。它还为决策制定者提供了部门层次上的功能,以查询多个功能或者方案架构中使用的一般数据。优势在于,例如,如果您要重命名一个机构性单元,删除,或者重新组织,那么影响可以在整个企业的范围内进行评价,而不像今天常见的那样,一个部门中发生变化时,另外一个部门却不会有回应。/ I  U& [9 s3 {. K( j" _6 w: w7 J0 Z
在用于定义的 DoDAF 2 中有四个 规范性 架构层,在每一个规范层中,创建什么类型的架构。( B3 w7 y/ h; l# y
工作区之中的 DoDAF 模型本文涉及到了可能为项目创建的基本 DoDAF 产品。可以使用其他的评审,但是为了让范例尽可能地简单,只有以下的产品才会得到处理(System View 产品类似于 Service View 产品,所以限制并不是意味着范围没有得到处理):
% Q0 \' S2 f- T( X8 y
  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3
    & y7 T2 x9 K, j! j5 w6 s$ s2 U. l( c

- U6 B$ c3 a* m$ W) Y( y7 b
! n: {& g* z$ @
  • 操作性 架构描述了业务和战术性操作,并关注于功能视图,项目视图,以及操作性视图。
  • 系统 架构描述了系统视图和标准视图上的系统,网络,以及交流功能。它应该基于操作性架构。
  • 服务 架构描述了内部性和外部性服务功能,关注于服务视图和标准视图。它应该建立在操作性架构的基础之上。
  • 方案 架构查看的是已存在的架构,并决定将来作出什么更改。它使用所有需要的视图来定义方案。" z0 N/ u& D0 V& b8 }
如图 2 所示,非规范架构存在于每一个规范化架构层上。
: ^& G1 n) N: r6 i( q
  T  q" s& ~. \# n图 2. 规范性和非规范性架构层7 g5 A. i% z& b, n7 L, N
3 i# K) q0 m& ^( O

7 R6 B( M: v' L3 U. z$ N工作区有助于确定架构之内的稳定性,并遵循命名规则以及其他的架构性治理需求。
9 q$ x$ s/ l& M8 }使用工作区实施规范性和非规范性架构0 g# B/ @8 O# v2 I
规范性架构:+ J: ^  }( k8 c$ w
  • 部门架构(基线)
  • 功能或者部门架构(工作区)
  • 构件架构(功能作为基线,构件作为工作区,可以被开发周期划分)) r* w+ ?+ M+ [, [

% |- L( T9 ?3 W& ^图 3. 分解为功能架构的部门架构: W$ v9 D0 m9 L6 M) c) [

$ O  t  i0 l  x. {4 F0 L1 v4 W
! u  P6 c2 Y* l) J3 f非规范性架构
+ M: G. ^6 d7 i- w- R- _/ ?( {
  • 操作性(基线)
  • 系统(基线)
  • 服务(基线)
  • 方案(工作区)
    0 Y2 s2 i8 B" V9 D% @- P8 v

( B' z( `: A9 n0 K. F( [% X图 4. 功能架构分解为多个方案架构
0 x3 d8 c* q3 L8 j" \6 t2 w' X
1 I" W3 K1 Q$ v  }5 C6 G. n7 M6 `. i* G: |( N3 T# H( o1 I7 Q! n

# F; V6 e, q8 r) ^* [3 h

0 \+ ^: Q8 R! k使用工作区的场景# Q8 o% y4 Z3 j$ a! z$ E
本文所展示场景基于处理项目的真实世界经验,但是这并不意味着只有一种方法去建模这些类型的项目,也不意味着特定的模型也在基线之中。! h: S; E# V  O  }) w2 Y* ?
场景 1:企业架构的实施
7 h" S% M* T0 W7 o- S% Z7 g企业架构在大多数的 DoD 构件之内实施。通常出现的一个问题是,怎样在 System Architect 中记录规范架构的层次,以及怎样管理更改。* v( J% K% k" j# z. \( h% k
例如,美国海岸警卫队实施了一个企业架构。它们拥有一个部门架构之内活动,系统,以及公司的标准列表。这些标准被业务行使用,以开发功能或者部门架构(例如,后勤或者金融)。这可以确保每一行的业务都使用相同的术语。它还可以帮助业务行理解它们的交流点(例如,后勤部门怎样与金融部门相交流)。, _) q5 w1 A- H6 O- @3 j
使用工作区,可以创建企业层次的图表与定义,它限制了低层次架构的开发。例如,这可以确保在所有的架构项目之中,都稳定地使用系统名。它还支持在多个架构之间的报告,因为相同的名字在公司之间得到了使用(例如,创建一个报告以查看消除或者自动化一个角色的效果)。  m& W! ?5 b9 h1 v' B
企业架构可以创建一个或者两个方法,以开发标准企业工件的列表。最佳用例场景就是在部门层次架构之上创建该架构元素(系统列表,公司名,等等),该架构在功能/部门层次以及方案层次上得到了扩展。在有些情况下,定义方案或者功能/部门层次,然后从不同的架构中筛选一般的元素变得更加轻松了(范例:从三个功能/部门架构中得到系统的列表,并在部门架构之中创建一个完整的列表)。) |& b( k: k4 _
1 F+ d8 A- E% h  ~$ i  U
图 5. 使用工作区的规范性架构层的分解
. u" M( A* C$ s3 \ 7 T" J% D- Y. f  l! T) n! W
1 I) ]* B9 s4 N
出于简便性的考虑,该范例假设一种底到顶的方法。: z4 v& J+ M$ X. L, p  I$ k# n, m. b0 N
企业架构(EA)项目之内的基线根工作区(部门层次)应该包含以下的内容:
. Y: @2 r5 G5 w% ?1 z* Y& F+ L
  • CV-1(整个公司可用功能的列表)
  • OV-4(整个公司的机构性聊天)
  • OV-5a/b(公司执行的高层次活动)
  • DIV-2(公司之间实体的企业范围内数据模型)
  • 系统与技术的列表(Technical Reference Model)
    1 [1 V8 {0 }5 k+ e
基线还应该包含架构元素或者图表,它们有低层次的架构。例如,如果部门必须遵循 Federal Enterprise Architecture Framework(FEAF),那么 FEAF 数据元素应该包含到基线之中。另外一个范例是其他公司限制的公司,比如美国海岸警卫队和国家安全局。应该包含两个架构之间稳定的元素(例如,使用美国国家安全局的企业数据模型)。
3 b9 G  ]/ ]& T0 H# t' T2 t工作区由功能/部门架构组成,它应该在基线可用的信息上展开。例如,一个功能可能向企业数据模型添加其他的实体,以处理特定的需求。% U5 `) m0 x/ {! a$ c
功能/部门架构工作区应该包含:9 J) F, L3 W) A2 w* t
  • AV-1(解释创建架构的观点,例如,后勤功能)
  • OV-1(描述什么功能或者部门必须操作)
  • OV-2(功能或者部门内执行者之间的资源流程)
  • OV-5a/b 分解(采取基线的高层次活动,并提供具体的细节)
  • SV-1(描述支持功能或者部门系统之间的资源流程 -- 系统应该基于来自基线系统的列表)
  • SV-2(描述 SV-1 中系统之间的物理学界面-- 系统应该基于来自基线系统的列表)
  • DIV-2(改进企业数据模型)
  • DIV-3(反映功能/部门之内使用的物理学数据库)
    & l4 U8 P, `% }  T" d0 ^
在功能或者片段架构完成和批准之后,对部门架构做出需要的更改,然后片段架构的功能被分解为多个方案架构,而功能或者片段作为一个基线。4 N! w) q. |" z* x; t
8 v7 z! r. `- ^3 D/ [0 G; j' s4 b. `0 Y
图 6. 活动被分解为方案层次,最底层的规范架构层
4 x" Y& Y4 I; m# k: {' o 7 n4 c4 F& k, `6 c5 y7 @' w/ o

- T5 w  L+ y: P  L* e% h使用工作区来定义企业架构的优势 % O7 L! q6 F/ Q
  • 在机构内部会稳定地使用相同的术语,消除混乱,并支持在公司之间的部门层次上进行报告。
  • 架构开发将会非常快捷,因为每一个低层次的架构都会使用预定义的定义和图表实现。
  • 报告可以在工作区之间完成,以确保稳定性(例如,确保系统名不会发生变动)。
  • 使用企业范围的数据实现一个新的词典(例如,一个新型的功能/部门词典)非常简单,只需要创建一个新的工作区。
  • 更好地集成系统,因为潜在的数据元素拥有相同的名字与数据格式。
  • 系统功能降低了重复性,并且对已存在的系统功能进行了再使用
    + S# C: V3 G& J: @) Y2 Z; e
场景 2:当前架构以及未来架构的实施
4 z8 O' R6 U5 N1 l3 j9 \DoD 对查看公司的当前状态并不感兴趣。它们还必须为未来制定计划,以确保未来的功能得到识别和预算,这样这些功能才会得到开发。计划的时间线通常是 1,5,10,或者 20 年。
) i) J/ t& I6 D% S) C一个典型的案例就是美国航天部门的空间侦查监视项目。功能,例如更强大的处理和改进的收集能力,在满足这些功能的技术就绪之前就得到了规划。当技术就位之后(更好的相机,以及发射更大卫星的能力),项目按计划进行以实施新的功能,并且在 30 多年间,空间项目的需求都没有发生更改。2 Q8 Z+ ~* E3 x+ ?: H5 Z! |
工作区使得这种类型的规划变得简单起来,在词典中的每一个工作区,都可以代表未来的某段时间。因为更改一个工作区内的定义或者图表,都不会影响到其他工作区内相同名字的定义或者图表。在每段时间内都可以作出更改和更新,而报告将会识别工作区内的更改。
% H# Q& P6 u% o: I* d# y9 I$ g) [" q( Y' z) n0 P
图 7. 不同的时间框架内定义的功能架构
  s- H6 m3 h- y6 {( ? " X+ v6 k- m, U2 g' G$ G
9 E$ I& U  o# m5 V) [' ?# F
基线架构一般是功能/部门架构,因为计划是在该层次上执行的(假设功能/部门映射到一个公司内部的构件,例如美国海岸警卫队的后勤部门)。它应该包括当前的(现在的)模型:
# D9 q/ o- n8 Y) b0 a
  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3
    6 B$ R$ [  w1 W7 K
工作区基于未来的时间线。工作区中将会编辑到的产品包括:% `% G+ U# @$ }; T
  • CV-1(添加未来的功能)
  • OV-1(使用新功能描述新的操作)
  • OV-2(显示需要的其他执行者和资源流程;执行者和资源流程可能也被删除掉)
  • OV-4(显示随着时间的变化执行者或者人员的重新组织,退出以及添加)
  • OV-5(其他的低层次活动可能得到添加,但是 OV-5 中的大多数更改都是为活动产生和使用的数据准备的)
  • SV-1(它会显示系统界面随着时间的变化,以及系统的添加或者删除)
  • SV-2(这将会显示执行者或者系统之间物理交流的更改)
  • SV-4(其他的系统功能可能得到添加,以满足一个新的功能,或者利用新型的技术)
  • DIV-2(新型功能所需要的其他条目与属性)
  • DIV-3(数据库技术改进时物理数据库实施的潜在性更改); x7 T: ]+ M# ]1 T% f+ f
使用现状架构以及将来架构工作区的优势 , d. `- H: d; e. l* M+ S
  • 在性能评价中追踪一项更改(例如:86% 可用性在未来的五年间增加到 95%)
  • 在系统界面中追踪一项更改
  • 追踪系统的替换情况
  • 分析一项新执行者或者角色消除或者引入的影响
  • 更好地进行预算
  • 识别满足一项新功能所需要的新资源
      e" v: i* r' T6 ]. K2 z, Y1 e
场景 3:系统集成架构
# s  v5 n) p0 ^1 D大型的项目,或者 系统的系统,通常会被分解为小型的,更好管理的项目。这些项目一般是由一个或者更多的承包商接手的,这些承包商在开发系统构件时有较强的专业性。但是所有的项目最终都会得到集成,以让整个系统变得可以交互操作。( D6 l& e0 z: Q# Y" p6 N
新窗格的开发就是这种类型系统的一个范例。一个承包商可以构建引擎,另一个窗格主体,另一个分析器,等等。所有这些系统都需要引入到集成的系统之中。通过按照标准的方法记录子系统,并提供高层次的集成计划,系统的集成需要更少的重复劳动,并且更容易实现。
7 ^9 U1 @$ @  [) e* L, r4 T6 A0 ]4 a' S8 Q) n* x
图 8. 为集成式子系统定义的方案架构
% o+ n1 m* X+ w( |4 j% P5 G- ^' F 2 ?  N. L. l" b5 r, J1 t
$ {; A3 [+ |6 k) b
基线架构一般是构件架构,它会识别将会被构建的系统或者系统的系统。它应该包含高层次的设计模型:9 ?+ L4 k) ?: @) U( b' L
  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3( b! k# A6 G, `" O9 g" W
工作区可以是子系统,并且由子承包商分解。基线模型将会得到进一步的分解,以显示子系统设计。在工作区内将会得到编辑的模型包括:
% E& j0 o! u0 _6 L; L
  • OV-2(显示子系统所需要的其他执行者和资源流程;基线 OV-2 只会在高层次上详细显示)
  • OV-5(如果分配给子承包商的活动需要时,可以添加其他低层次的活动)
  • SV-1(显示特定子系统和资源流程的其他细节)
  • SV-2(这将会向子系统之内使用的物理交流显示详细信息)
  • SV-4(可以分解系统功能,以识别子系统低层次系统功能之间的内部性资源流程)
  • DIV-2(需要其他的条目与属性,以提供子系统所需要数据的详细信息)
  • DIV-3(子系统的物理数据库实施)& p/ o/ u" U* f5 U
为集成式架构使用工作区的优势
1 R( F; d5 o$ p& D
  • 设计的治理
  • 集成的消除,因为集成点得到了清晰的理解
  • 分析确保每个子系统的需求都得到了满足
  • 集成点风险的识别与管理
  • 子承包商系统界限的清晰定义
  • 系统界限之间的常用术语
  • 如果子系统发生更改,进行影响分析
  • 系统集成的时间线可以得到识别,因为系统的附属性得到了清晰的理解
    ; H, f& t: k5 @+ W) X9 T2 B
场景 4:Trade-off 分析
2 ~4 x8 ]% k" V7 L9 T; K: u+ GDoD 通常需要研究进行潜在方案的交易分析。他们通常做研究,去测试使用新型技术的可能性。6 v# i! U) d$ W+ w( q! j
美国空军智能收集项目就是关于它的一个很好的范例。在军事监视的早期历史中,二战之后,兴起了一场关于使用高空飞艇,改进式轰炸机(RB-29),以及改进式战斗机(RF-84)来收集情报的辩论。每一项功能的频率和时间都得到了分析(航程/突破率,可靠性,被探测和俘获的风险性),关于找到什么资源来提供最成功结果的决策也制定了。
# i! p+ k/ W1 ^% ~: h- s3 \6 y通过提供一个操作性场景,然后研究每一种潜在性方案(对于空军来说,使用资源来收集情报),工作区简化了不同潜在性方案的分析。方案的技术现实性成为非常明显的一面,并能够满足操作性需求以及性能评价。可以基于每一个潜在性方案的结果来制定决策。
4 |8 N5 F) h4 k5 S
- ~8 n" D( t& k6 o) G/ u图 9. 带有四个交易方案的构件架构范例8 a. G2 G7 a6 W
" Q4 c# H6 ]. o( z
% I0 r6 \; i; k
基线架构一般是构件架构,因为构件架构包含了高层次的操作性需求,方案必须要满足这些需求。该架构可以是当前的(当前),或者是未来的状态(未来)架构。它应该包含未来(未来)模型的当前(现在)状态:
) k8 G7 F7 I0 U7 d5 [9 ?$ C
  • AV-1
  • CV-1
  • OV-1
  • OV-2
  • OV-4
  • OV-5
  • SV-1
  • SV-2
  • SV-4
  • DIV-2
  • DIV-3
    + V& L" w3 L& [  ~" i
工作区基于分析的不同选项。大多数的工程工作都查看不同的系统查看相关的选项;操作性环境之中的信息并不会得到变化。在工作区中将会得到更改的产品包括:
/ t/ D6 q  r- j& Q+ Z; O/ r
  • SV-1(它会显示其他的,或者编辑过的,系统界面)
  • SV-2(它将会显示执行者或者系统潜力之间的物理性交流,基于灵活性分析的新技术)
  • SV-4(其他的系统功能可以得到添加,以利用新的技术)
  • DIV-3(由于添加新功能,对物理数据库实施所造成的潜在性更改)- ]9 N8 c; V3 L$ a6 \& L
为交易分析使用工作区的优势
) s  G+ Y6 d+ R% t0 M& g- n  B. A6 u
  • 报告各种选项成本的能力
  • 为各种选项报告性能措施以及相关需求的能力,以避免不合适工程的方案
  • 确保操作性环境没有发生变化,以让选项变得更加灵活
  • 追踪与不同选项相联系的任务的能力
  • 不同选项之间的标准化以便更轻松的分析(定义名保持一致;图表包含稳定的数据)
    9 ]  f3 X" ]( J! P' B: z


+ Z) h3 x" V+ t: \4 V! G( s9 f- ?0 c: _) _$ G- N9 W
工作区分析工具. _. O7 X5 r7 h( A
SA Compare 特性5 M# H8 r( W. h1 K. i$ t
您可以使用 Rational System Architect SA Compare 设施,来显示工作区之间的变更。例如,SA Compare 可以与 DoDAF 2 架构一起使用,以识别任意的更改:. s' P. p3 }  U; z5 Y
  • 工作区内项目名的变更(例如:根目录下机构名稍后在工作区之中得到了更改)
  • 根源与工作区之间的添加与删除(范例:工作区中添加的其他系统功能,或者工作区中系统的删除)
  • 随着时间的添加或者删除(如果工作区是基于时间的话)
  • 定义内对属性的更改+ e$ j4 c( y4 J& o% ]+ A
如果您想要得到更多信息,您可以查看 Rational System Architect 信息中心之中的 SA Compare 部分,见于 参考资料
! V" {8 ?( R" ]! k/ {' i, b, W" fIBM Cognos 软件
7 {5 [( k8 @0 E" R5 sIBM® Cognos® 业务智能以及性能管理软件支持工作区之间的报告。它还可以用于运行执行计算的报告。使用带有 DoDAF 2 架构的 Cognos 范例包括:
% i0 s2 z0 h$ C0 g+ O: |- Q
  • 活动完整列表的报告包含在两个工作区之内(SA Report Generator 只能报告工作区之内的内容,而不是工作区之间的内容)
  • 提供多个工作区之间的最高系统功能列表
  • 为所有工作区之间的系统功能和活动提供全部的成本(可以运行报告运行以查看哪个选项是最高成本,哪一个是最低成本)
  • 报告一个系统所需要的所有资源流程(可以运行报告的集成操作,以显示创建集成系统所需要的所有资源流程); L1 J: [& n7 D! B4 P$ ?
如果您想要得到更多信息,您可以查看 Rational System Architect Information Center 中所列出的 SA Compare 文献,它列在 参考资料 之中。
  D/ n& [6 b5 H% Z& ]2 B$ [& T6 }Rational Focal Point 软件' T. y1 x; K1 z$ [
IBM® Rational® Focal Point 软件提供了市场驱动的以及业务驱动的产品,和概述管理。使用带有 DoDAF 的 Focal Point 的范例包括:
; k  g# e8 W4 ]& |& v
  • 特定工作区或者跨工作区的操作板,有助于管理项目风险,日程安排,以及成本
  • 使用目标性信息,来做出基于定量分析的设计决策,而不是猜测哪一种是最节省成本,以及最低风险的方法
  • 获取客户需要的优先级,这样架构就反映了最高优先级的功能。
  • 路线图以及规划功能,以分析未来的发展趋势
    ; |' K/ y4 Q6 {4 H
如果想要得到更多信息,您可以查看 参考资料 之中所列出的 Rational Focal Point 概述引用。: }! J: c  S. S9 ]4 O0 e
Rational DOORS 软件
4 N$ ~  k. Z' W9 I# n6 YIBM® Rational® DOORS 是一种工具,它提供了一种综合性的需求管理环境。需求可以从 Department Level 联系至 Component Level,以显示构件架构满足 Capability 与 Department 所有高层次的需求。范例使用带有 DoDAF 2 架构的 DOORS 包括:6 n) p. K, B+ H( g  j( x, }
  • 图表上的图像指示符有一个相应的需求
  • 报告显示没有相关需求的架构元素,以及没有与架构相联系的需求(遗忘的需求)。
  • 3 个规范性架构层层次需求的管理,以及层次之间的追踪性。
  • 架构上的标准和治理可以位于 DOORS 上,并且与架构相联系。
  • 架构变更或者需求变更的影响分析可以使用报告轻松完成。
    8 H! b/ o6 W. m
如果您想要得到更多信息,您可以查看 参考资料 中所列出的 Rational DOORS 概述页面。7 x: d- J* ?; i0 p2 A* |

! E% [; h: s9 i/ w* m) P: ~

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
 楼主| 发表于 2012-1-5 11:47:33 | 显示全部楼层
回复 支持 反对

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|小黑屋|手机版|无图版|SCMLife.com ( 京ICP备06056490号-1 )

GMT+8, 2018-1-20 23:49 , Processed in 0.076685 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

快速回复 返回顶部 返回列表