SCMLife.com

 找回密码
 立即注册

QQ登录

只需一步,快速开始

扫一扫,访问微社区

查看: 4684|回复: 1

[推荐] 管理产品系统的运营性需求

[复制链接]
发表于 2011-9-21 15:06:03 | 显示全部楼层 |阅读模式
本帖最后由 技术狂人 于 2011-9-21 15:23 编辑 6 u; q( m7 H5 s( A

! x3 r, y$ {6 s+ F. x5 `  h' ]识别和追踪需求的想法在 IT 专业人士那里得到了广泛的承认。不幸的是,需求通常会自动识别为 用户 需求,例如与特定运营所请求的用户或响应时间相关的功能。7 W1 y5 p, |" a& J% `0 P2 q  J
但是,有其他类型的需求更加清晰,并且通常成为产品系统严重问题的来源。它包括了数据库连接数量,内存分配,以及相互共存,通常是不相关系统之间的共存问题。
; b9 U$ S/ S- {, h- L1 R这些需求来自于这样一个事实,在今天的数据中心里,没有软件是一个拥有无限资源的“孤岛”。相反,整个硬件和软件基础必须得到不断的优化,以改进性能。因此,进入到“生产”阶段的新软件必须满足与共享资源相关的一系列需求,以及来自新系统的限制条件。) d' y. T- K8 Y6 o
在这部分由两篇文章所组成的专题里,我们向您展示了开发部门与运营部门是如何使用 IBM® Rational® Requirements Composer 按照以下两种方式进行协作的:# p8 S' }+ o1 e, N) o, e
  • 建模和追踪产品程序使用相关的需求
  • 稍后添加 IBM® Rational® Quality Manager 来准备和追踪预生产测试
    - W0 H- w. L' I3 P5 W; C
为什么非功能性,运营性的需求会成为一个问题
( o* F+ C1 C/ P- {- a( x) H正如前一文章所讨论的那样(见于 参考资料 中所列出的 Loasacco 与 Castiglioni 资源),非功能性需求(NFRs)代表了在 IT 系统中有兴趣的不同类型的涉众的需要(查看 参考资料 中所列出的 Rozanski and Woods 资源)。7 F1 f) d7 i9 C% q5 p# q+ `
在本文中,我们将会集中讨论那些与新系统的产品环境直接关联的 NFRs,以及与系列进程相联系的 NFRs,以支持其运营。我们会将这些需求引用为 运营性需求
5 j2 P! J8 h1 T' K$ Z% X. R当然,对于我们的需求来说,新系统产品环境规格的首个来源是业务的目的。一般来说,SLAs(访问层次协议)主要来自于业务进程以及系统所必须指出的业务环境的特征。6 H" t& R+ X7 h* r" z) ]) S+ ]; z4 k
但是,运营性需求的第二个重要的来源是 IT 访问管理(或者运营)公司,它包含了以下角色的人员:
7 W1 b, r; c1 e$ z
  • 配置管理专家 ,他维护了系统配置,如有需要应用校正,改进并升级,以及引入新的元素。
  • 数据库管理员 ,他定义了物理数据库,监视数据库的健康状况,并备份静态数据。
  • 服务管理员 ,他决定物理服务器上新系统的位置。
  • 网络和系统管理专家 ,在运行时他监视和控制新程序及其基础(硬件及软件)( F' `+ X* g5 e7 t, V, |
另外,还有其他一些涉众,例如那些可能代表的:; M6 E+ c, w3 {3 L0 I
  • 企业结构师,保证新系统与构建的设计及结构性描述相一致
  • 安全官员,他创建程序和基础必须遵从的标准与安全规则,并执行适当的审计运营
  • 评审员,证实内部性或者外部性标准 和/或 合法性规则
  • 维护员工,出现故障时执行系统维护和问题检查运营
  • 供应商,提供硬件和软件产品以构建将要安装新系统的基础
  • 支持性员工 ,提供对末端用户的支持3 w7 ]: x( D2 j
总的来说,作为一般性的规律,运营性需求来自于以下方面:
* v7 q7 X. l% j; u" S
  • 管理数据中心的 IT 机构的策略
  • 数据中心基础的结构
  • 产品和工具在数据中心已经投入使用或者正计划使用
  • 运营性数据中心的资源限制条件
  • 由于特定服务器上程序的一些构件位置所施加的限制条件
    , v7 s: I3 t. ?+ ?8 @1 ^' E# r' i6 u
但是,运营性需求可以从其他非功能性需求的更通用背景中取出,因为两个系列可以得到紧密的联系。一个角色(在本例中,是业务拥有者)NFR 所表达的范例会转化为一个运营性需求,在给定的界面上您可以指定特定类型的需求。您可以选择特定层次的运营系统(可能是一个新公布的集成了重大性能改进方案的版本)或者中间件软件,因此产生了一个新的运营性需求。! I0 e1 b# s8 x' ?: H
这个非常简单的范例向您展示了运营性需求是怎样相联系的,它需要开发团队和运营团队的不同角色进行紧密的协作。+ H0 D# s4 q# ]; \& z- @$ c
在我们的经验中,当一个新的程序发布到产品中时,大多数的问题是由误解,或者两个组织之间缺乏沟通造成的。对这些问题的分析,显示了下面是一些常见的原因:# E6 F. v( ~+ q7 l; S4 r5 |% N# G
  • 交流缺乏完整性。 通常信息都只是文本格式的,基于表单和合成的检查列表,可能只是部分适合于新系统和交流。
  • 缺乏共享。 信息流程只按照规范的文件方式进行(通常是从开发部门转向运营部门),就算内容得到很好地理解和认识,也想要进行多观点的讨论。
  • 忽视重要的信息 。 接受信息的人员并没有掌握需求的相关性,没有就此进行交流。这通常意味着需求没有包含到开发部门或者运营部门的测试计划中。
    * a$ P& f3 a; Q) i' u: a+ J
在本文中,我们假设在开发部门与运营部门之间有四个步骤的交流过程:
; M! D2 Z# H% P& M4 u
  • 步骤 1 是关于 Context NFRs 的识别的,意味着这些非功能性需求会直接影响到开发新系统的角色,包括需要进行交流的其他已存在的系统。System Context diagram(或者更精确地说,Operational Context 图)以及描述内部性和外部性标准的文件都是该步基础的工件。
  • 步骤 2,逻辑性部署 NFRs,注册了来自技术和结构的 NFRs,包括程序设计阶段的开发决策。这一步是在新程序的逻辑部署模型附近构建的。
  • 步骤 3,物理性的部署 NFRs,识别了与产品环境物理模型和物理限制条件相联系的运营性需求,它来自于支持新系统的基础和中间件。
  • 步骤 4 通过共享评审,并同意来自所有涉及到的涉众,使用来自相关的讨论线程来总结非功能性需求的列表。' X, `$ w8 C7 Y- N8 q! J1 v, `


7 V8 k, G8 m* N5 \' b4 @* G2 _+ @  ~: u+ {  B$ s2 D  F! r. d
) A: z; K  V8 |4 b) ^3 y4 }1 M. ?
使用 Rational Requirements Composer 的不同方式
' U' q) p/ _) z3 K在软件生命周期内 管理 需求的工具已经发布很长的时间了。它们在今天得到了广泛的应用,以创建,追踪和管理需求,并将它们与软件开发过程中的各种工件联系了起来。
5 l' r( N4 r9 V' W) ~关注 收集和定义需求 的支持性活动非常新。
5 p+ P1 @1 ~: G' b8 _% K3 X在一段时间内,我们已经看到了建模技术(用例建模,业务进程建模,等等)得到了越来越多的运用,以补充传统的,基于文本的方法,因为它们提供了更丰富更精细的方式,去表达业务和技术性需求。尽管如此,这样的技术和工具主要由软件结构师或者开发团队使用。末端用户,业务专家,分析者,以及其他的涉众一般使用不是很规范的方法,使用更简便的工具,例如事例板或者模拟软件,这些工具也能使他们获得交换注释,询问问题,得到答案的能力。* D4 r9 U( r+ q) m! t
在这个场景中,处理私人特定需求的方案看起来不够,扩展的团队成为目标观众。基于储存库的方法,拥有信息共享和与其他 Application Lifecycle Management(ALM)或者建模工件强大的集成功能,目前是最好的选择。8 l7 d& C# T7 ^6 R  H- Y
Rational Requirements Composer 是一个基于服务器的方案,帮助团队成员来进行协作定义,改进和评审需求;它构建在 Jazz 平台之上,提供了可以紧密协作的环境,得到了编辑器和其他可视化及文件技术的补充。* S0 t: Z5 P9 o  x9 F. u- ]
协作方法$ v9 S: B- @3 H5 n$ {; u! Q1 Q
Rational Requirements Composer 支持处理需求定义的 团队用户。团队成员可以在地理上分散,远程工作,并在不同的时间内工作。不管何时他们连接到储存库,他们都能看到即将处理的项目,并即时访问工件,注释,评审,在检查之后进行创建和更新。
& M. P; {" d+ ~- q根据他们的义务,他们可以读取和回应注释,创建和更新支持工件,创建和更新需求。, O6 q) y$ i4 l' }4 Y
为了促进关于需求的讨论,业务和技术性术语的词汇表,叫做 Glossaries,提供了整个项目期间经常使用到的术语。当涉众团队很大,经常变迁,或者在地理上分散时,该表会非常有用。4 w8 f/ k3 c- A. J
Comments 是非常简单但是功能强大的机理,可以帮助涉众表达和记录不同的观点,并讨论实施,优先级,预期的受益,时间框架,等等来最终达到某个定义。注释,可以与整个工件或者一个工件之中的单个元素相联系,组织到 线程或者 讨论 之中,特定的用户或者整个团队可以看到它。该协作性 讨论 过程会模拟一个扩展的,正在进行的会议,并支持更精确和稳定的需求定义。- B8 y$ l! ?0 }) U
工件与建模
/ r: I, S; w% m7 ~Rational Requirements Composer 包含了一些编辑器和工具,来提供需求及支持的工件。
- b9 s+ v* s6 K3 P) y1 q在需求定义过程中会广泛使用文本文件。已存在的文件(例如,Microsoft Word 文件)可以轻松上传到 Rational Requirements Composer,或者创建一个新的文本文件。有了 Smart Text 功能,任意大小的文本,例如一个句子,甚至一个简单的词语,都可以被选中和标记为一个需求,或者用于在词汇表中创建一个新的条目,一段文本可以拥有相关的注释或者标签,或者它可以与其他的工件和元素联系起来。1 q% w2 |) u2 r! V; n) @
这个 关系网络 构成了丰富有用的业务及技术知识。
3 j" s' V4 {" }1 o4 g除了文本处理之外,Rational Requirements Composer 提供了一些编辑器以产生特定的工件:
) K: A7 w, [9 n' b4 P* n2 w: ]
  • 用例编辑器 以创建用例规格和用例图;
  • 业务过程编辑器 以描述基于 BPMN 注释的图,呈现活动和事件流程图。这是描述定义的一个灵活技术;然后 BPMN 图可以导出到其他的 Business Process Modeling Notation(BPMN)建模工具之中,以便进一步的编辑。
  • 草图编辑器 以构建用户界面的模型。组成界面视图和界面流程,以演示呈现给末端用户的系统是非常容易的。
  • 事例板特性,以创建事例板,它由反映特定场景的时间线框架组成,例如特定的用户经验。一般来说,事例板用于模拟末端用户是怎样通过 GUI 来进行导航的。但是,这是一种可以应用到多种情况的非常灵活的机理。在我们的案例中,我们会使用事例板来支持定义及改进技术性运营场景及其需求的人工协作过程。
    / e' Y: z# I. p, p6 Q
Rational Requirements Composer 之中的需求定义9 X. B, c; p9 ^
Rational Requirements Composer 会使用特定类型的工件来表达需求。您可以使用一些类型的工件(用例,事例板,等等)来支持需求定义,但是一个需求一般是作为需求类型的实例表达的。# L6 [6 a. ]8 z5 k7 }
需求可以在分析的任意阶段进行定义,通过创建 需求 类型的工件,或者通过将需求与文件中选中的文本或支持工件中的元素相联系。然后团队成员可以评审和注释需求及其相关的工件,但是仍然有规范的评审和确认过程。
/ _8 q/ c; \4 {" _1 }在 Rational Requirements Composer 之中,评审 由一系列的需求以及确认的支持工件组成一个有机的整体,由一组用户负责,每个用户执行特定的角色,例如 Approver 或者 Reviewer,执行特定的运营,例如:Approve 或者 Reject。可以只为评审的目的,或者作为广泛范围的相关工件的 集合 来选择一系列的工件。所有涉及到的用户都会得到通知,去评审创建,并请求评审资源,表达他们的注释,或者根据需要建议进行更改。最终,所有的 Approvers 都必须识别资源。4 u4 l9 k+ c, H4 n
为了演示软件是怎样支持开发团队与 IT 运营部门识别运营性需求的,我们会使用到一个范例:在已存在的数据中心中引入一个新系统(“一个基于 Auction 的电子商城”)。5 x, Q0 Y! @5 w1 D8 N$ d


  M: ^7 j$ u2 o; t' N0 T4 q, c+ N( G0 \* K
$ j# H& l6 M+ d/ K2 z
步骤 1. 新事例板之中的 Context NFRs4 ]- p# K9 H( }; k7 U9 R6 p4 i0 d5 L
进入到“新系统运营实例”首个系列的运营性需求,组成了来自于新系统范围内的非功能性需求。它们可以连接到程序的 System Context 图上,因此识别了新系统的 Operational Context(查看 参考资料 所列出的 Castiglioni-Losacco 注释)。
* l" V- r' t) m# }- {1 k$ m4 m: o# k  a5 J3 a  N* S2 I
图 1. Operational Context 图. S# j) f% F9 Q; I8 ^' u

0 T; Q0 M+ e6 T) d0 v3 U6 H2 ]* D/ M" p
一般来说,Operational Context 图的首个版本包含了角色类型的 NFRs,例如交互用户的响应时间,并发会话的数量,或者程序的可用窗口。
4 M5 @: E& ]: s1 g在我们的范例之中,业务时间内必须能够使用 Registered Users 界面,以允许参与者的运营,支持多达 200 位的并发用户,保证响应时间低于两秒,用户 ID 和密码安全。2 J% f- e# {% I
为了帮助图中的元素能够查看需求之间的联系,我们会在图中使用定位文本标签技术(图 2 中以绿色强调显示),并将需求与注释和那些标签联系起来。
2 W9 z8 S4 f  \( V" d; `/ E0 i对于该基底 IT 需求,运营员工可以添加他们自己的“内容”NFRs:8 d# Z+ i1 `( }5 }
  • 外部性系统所施加的限制条件已经就绪,必须得到整合
  • 政策相关的需求,例如用户访问及外部系统访问的安全性需求,ID 管理政策,审计和登录
  • 数据中心结构化决策
    ) G" G8 a) f6 o7 d$ Z# O5 z
在我们的范例之中,公司的结构标准会调用 IBM® WebSphere® Application Server 作为程序平台,使用 IBM® DB2® 作为数据库服务器。
& n. J, y1 q: v9 `8 p
, R  J: \+ v7 F9 i/ A图 2. 来自文本文件的需求
( F0 m: ]6 i" g! m; o ' h: X4 Q$ M: G* N8 H1 [! T+ y2 x1 l
: b( X$ u8 J4 U  i5 ~$ \1 o' U

8 z% _* z9 x9 U( V0 Z7 a
" R; g& ]1 W6 f) x

* z) M8 {, [* W- i/ e步骤 2. 逻辑性部署非功能性需求5 B, U$ P/ S9 h9 n9 k) f* Z
Development 与 Operations 之间下一个迭代发生在定义新系统的部署结构时。在这一个阶段中,开发团队对系统的主要构件,以及需要什么特性来支持它们有了一个清晰的概念。因此,在这一阶段中,我们希望所有适当的技术都得到了识别,并且做出了主要的结构决策。您可以使用一个 UML Deployment 图或者其他等同物来传达这些决策。, F- a9 m. n0 p8 _  T' O- S
这一阶段有一些需求错位:
1 A  \# i! t6 _, R4 q) ?3 ?7 P
  • 已经部署到产品中由中间件所支持的技术层次是不正确的。
  • 对产品系统拓扑结构所做的开发假设不能得到真实系统的支持。
  • 开发要求 ad hoc 中间件,已经安装到产品之中,因此是冗余的。) _1 ]5 u# V; B7 `; U* J8 p, `
在这一阶段中,您要使用 Rational Requirements Composer 协作性方法的功能。如果信息交换在正确的时间内进行,那么 Development 与 Operations 团队可能都要适应它们的设计,以匹配各自的需求。4 Q5 D- x3 R9 x9 N5 j7 v  _5 @  e
& W0 m* C( D! B2 d0 u
图 3. Logical Model 图7 @; A5 k: r& p" ~& `) p
. }7 B$ O1 ^# Y
; x/ g" r% K9 {  O
在我们的范例之中,开发团队(显然的)有意义遵从公司的中间件标准,因为新系统是一个非常规范的 Java 2 Enterprise Edition(J2EE)程序,有一个网络构件,一个末端的构件,以及一个网络服务请求器构件。但是,它们取决于是否可用特定技术:JAX-WS)Java API for XML Web Services)。如果不能得到对 JAX-WS 的支持,那么程序的网络服务构件就必须得到完全的重写。因此,如果产品环境中尚不能得到该技术层次,那么就必须策划一次更新运营。9 A  u/ p+ v  i
其他的运营限制性因素可以按照相反的方式进行协商。例如,开发团队可以协商使用 IBM® z/OS® 运营系统之上的 IBM® DB2® 数据库,而不是一个分布式平台之上的 DB2,如果它是该类数据的运营平台的话。- {7 H3 x, H6 M8 k; w' Y8 L6 @$ h
这些“会话”是信息比较重要的一方面。在特定的情况下,它们可以与最终的需求一样重要,因为它们获取了制定决策的 rationale。
8 U) M0 A* Q8 s% @2 j
9 n- l, ?' q: G1 |5 \( B3 y: X9 D

6 M) z0 K- [' s9 m
) }+ g8 \3 e* D* D& ]步骤 3. 物理部署非功能性需求
+ i7 v- p: f, Z( O9 R; v需求与限制性因素的协作协商过程显示了系统的物理模型可以进行指定;因此,可以识别整个系列的运营性需求。
  P8 X3 X  |+ Y+ y+ @2 n但是,在前面的迭代中,开发员是信息交换的最初参与者,现在则是过程开始的运营部门。这一阶段所识别的需求主要与以下的两个因素相关:
) n: ?9 a, D7 V: T/ r$ E% x. j
  • 数据中心(物理系统与网络连接)的结构
  • 结构中所涉及到的特定产品系统所施加的限制条件(一般是资源限制条件,例如内存以及对数据库连接的最大连接数量)7 n1 U5 t" m9 l# Y4 R
/ \" F5 D$ S' H# c
图 4. 高层次的物理模型
' R. d, T4 A5 I) B6 S
# f' k; o. W- \8 ?' R& O4 x
: f* g. _, H- \4 P出于清晰性的考虑,在本例中,我们选择首先使用高层次演示图来呈现一个物理模型,然后使用一个更加具体的结构图。一般来说,两种信息都可以包含在一个大型的具体图中。' |' L" T. H8 l; Y/ o
/ |5 l! V, M2 R' H. t. s, K$ `4 b8 s
图 5. 具体的物理模型
5 ]- w" @7 U; e- E; v+ ^ 7 b' U  n, t0 ^8 U1 j5 n1 H0 a! s
/ a, N; s  E; v2 f( [$ e% @7 w
最后,需求会假设新系统必须在一个 IBM® WebSphere® Application 服务器及 DB2 上开发,它是公司中间件的标准。
8 _2 W: |8 v. x$ g正如我们在前一个迭代中所做的那样,我们要添加文本标签,以识别需求中的元素,然后将需求与文本注释联系起来。这些标签会指定新程序可用的资源位于末端服务器之上的,以及可以分配到数据库服务器上联系汇的数量。
& v: M" U1 x# M# `5 e8 Z5 `9 ~( H

, s( j+ d) q& d, E5 |
% R7 F2 [' g# [. C* H. T& d9 [0 b7 w$ B  m
步骤 4. 最终的评审4 F" @6 N4 S3 D$ N7 c# g
在谈判和协商的最终回合结束之后,我们就可以说对共享的需求做出了确认。
$ J3 g' V5 x; wRational Requirements Composer 再一次显示了它在支持一个工作流程上的强大能力:多个评审员可以在最终的结果给出之前进行定义(见于图 6),而评审过程本身可以得到注释和讨论线程的支持。一般来说,运营员工和开发员可以是评审员,但是末端用户及其他的组织,例如结构师,也可能涉及到里面。最终的结果来自于程序的业务主人或者 CIO。) n/ Y* j4 P1 f; L0 z" c' m

2 D' ]1 N1 Z, B+ A" n7 I" t图 6. 同意进程
$ s; m2 e; Z& o * F1 J3 {$ z% z& J' j

8 @; h6 N. f- c接下来,该考虑需求,并将它们转换为可以在预生产测试中可以进行测试的实际应用场景,以显示系统实际上可以在产品环境中使用。这就是本专题第二篇文章所讨论的对象。
3 j- F  B* A0 g, M0 a
$ R# R7 K* ~2 B! z! S
& x) N! O* f9 m+ s/ r$ F
6 T: N5 }4 R* o  ]: U% k* ?! `: ?0 h
( j' j4 |2 [8 }' d
总结
; R/ {! r" B0 ^) n识别与程序环境相关的非功能性需求,就是 development 与 Operations 组不同角色之间的协作,以及末端用户和其他潜在意义上涉众之间的协作。该进程必须得到工具的支持,这种工具可以以一种简单但是实用的方式支持这个协作过程,因为进程中所发生的一切都是很重要的,而不仅仅是最终的结果。2 _* j4 K# y! O, ^4 u
在本文中,您已经看到了 Rational Requirements Composer 可以是这样一种工具。我们建议将该过程分为四个步骤,或者迭代,从开发过程的最早期阶段开始。这使得在设计的所有阶段中可以更好地共享相关的信息,这样您就可以避免盲目地工作和重复劳动。我们还建议您使用大量的图表来支持该进程,以避免只有文本描述所产生的误解。/ d: ~3 [5 P7 Z9 a  ~
该进程所识别的需求可以是预生产测试场景的基础。" r  u5 t- X7 ]) q: g" W& ^7 V

本帖子中包含更多资源

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

x
 楼主| 发表于 2011-9-21 15:08:51 | 显示全部楼层
回复 支持 反对

使用道具 举报

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

本版积分规则

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

GMT+8, 2018-4-27 00:16 , Processed in 0.073935 second(s), 6 queries , Gzip On, MemCache On.

Powered by SCMLife X3.4 Licensed

© 2001-2017 JoyShare.

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