IT – Business Analyst 具体要怎么做

January 17th, 2010 Arale 2 comments

前几天看书, 摘抄了一段BA究竟要做什么, 感觉讲的太笼统. 比如人家问你说, 你今天中午吃的什么? 你回答, 吃的饭. 这样的回答有一些欠揍. 我又稍微总结了一下书上讲的. 其实我并不是专业的BA, 也正在学习中. 如果看文章的你发现我有说的不对的地方, 还请不吝指教.

按照B.O.O.M.(Business Object Oriented Modeling)的步骤来说, 分为5个部份, Initiation, Discovery, Construction, Final Verification and Validation(V&V)和Closeout, 把每一个步骤需要做什么东西,搞清楚了, 其实就算是入门了.

1. Initiation 初始阶段, 这一阶段要做的主要有4点.

  • 定义用例模型, 主要涉及定义业务用例(用业务用例图), 还有就是业务用例的关系了, 具体到就是(Acitivty Diagram)
  • 定义系统模型, 定义角色(Role Map), 定义系统用例包(System use-case diagram),定义系统用例(System use-case idagram)
  • 定义类图. (Class diagrams for key business classes)
  • Set baseline, 定义目标(这里我个人理解也不太清楚, 如何set baseline. 后续搞清楚之后会补上)

2. Discovery 探索阶段

  • 行为分析, 描述系统用例(use-case description), 描述状态行为(这一点也没有搞清楚)
  • 结构化分析. (Class Diagram)包括定义实体类, 类的泛化, 模型之间的关系, 添加属性 等一系列的.
  • 定义测试, 测试计划等.
  • 部署计划
  • 开发的目标.

3. Construction

在这一步, 是把遗留下来,比较简单的一些元素进行迭代实现,并开始准备部署.

4. Final Verification and Validation (V&V)

在完成之前的测试工作, 查看是否整个系统都已经按照前面讲到的Test Paln进行测试.

5. Closeout

这个我感觉就是, BA在最后布署的时候, 参与进来, 看一看是不是所有的都是按照部署计划来的.

一套流程下来, BA大概要涉及的就是这么多东西, 看完一本书,往往会很困惑, 那么多图, 怎么用?  具体到每一个步骤的标准是什么,怎么个写法, 这个我暂时也讲不清楚, 因为我也只是刚刚开始学习, 如果有现成的文档的话, 应该会加深自己的理解. 不过这整个流程中, 所需要使用的Diagram都已经表示出来了. 所以在看书的时候应该不会感到困惑了.

Read more...

杂文 – 周记

January 16th, 2010 Arale No comments

早晨, 依然被已经设定好的闹钟叫醒, 时间6:00分. 躺在床上, 竖着耳朵听着窗外, 除了偶尔穿过free way的汽车的声音, 什么都没有, 一片静寂. 窗外的Holiday Inn的Logo还在亮着, 远处天边已经有了一抹的鲜红. 天快亮了.

美国的程序员通常可以干一辈子, 即使在30多岁辞职, 依然可以找到一份工作. 但是反观国内, 30岁之后的程序员如果要找工作好像是比较困难的. 而且技术更新太快, 国内的公司也不停的更新自己的技术, 但并不是每一个人都能赶上时代的步伐, 特别是随着年龄的增长, 有了家庭的负担之后.这样的矛盾就越发的突出. 爱好和未来, 不得不做出选择.

这个周一直在看BA方面的书籍, 其实之前也在看, 只是没有这个周密度那么密. 很希望可以有机会可以转型做Business Analyst. 在些地方很难有机会得到这样的机会, 因此只能自己去学习这方面.不知道有没有什么相关的培训呢?

某个朋友告诉我, 让我列出我这辈子最想干的27件事情, 然后在做每一件的时候都去想想,和这27件事情有没有关系. 这样,我的生活可能会充满了意义. 嗯, 这是一个不错的主意, 只是我想了好久… …

x

Read more...

IT – 活动图中的Object和Activity

January 16th, 2010 Arale No comments

活动图, Activity Diagram, 是UML用于对系统的动态行为建模的另一种常用工具,它描述活动的顺序,展现从一个活动到另一个活动的控制流。活动图在本质上是一种流程图。活动图着重表现从一个活动到另一个活动的控制流,是内部处理驱动的流程. 活动图的元素有开始结点, 活动状态图(Activity), 动作(Action), 动作约束状态(Action Constraints),动作流, 对象, 终止节点等等组成. 具体的元素对应的图像可以很容易的在网上找到, 这里不做过多解释.

这里是要解释一下Object和Activity之间的关系.

objectacitivty

如上图所示, 中Activity是指 schedule gathering date,convene gathering,assign a reviewer.review a case. 而object就是图中的两个方块来表示的.

如果你对这个图有疑问, 这里没有办法作出解释, 因为,这个图像是已经假设业务已经成立的情况下而画出来的. 你的业务会导致什么样的结果, 这是需要在分析的时候指出的. 这里只是为了解释图之间元素的关系而已.

  • Activity Schedule gathering date 会产生一个结果,叫做Case sate being set to Scheduled for Gathering, 简单理解, 该对象会生成一个Case的对象,
  • 这个object会令下面的Convene Gathering来使用,也就是说Convene Gathering需要Schedule gathering生成的object来做为输入..
  • 同样的, Convene Gathering在接收到[Sheduled for Gathering]之后,经过处理也会生成另一个对象, 供下面的Review Case来使用.
Read more...

IT – 几种描述工作流程的图形的比较

January 16th, 2010 Arale No comments

 

Diagram Description Advantages Disadvantages

System flowchart

Earliest form for depicting sequencing of activities.

Intuitive. Each type of input and output is clearly marked with its own symbol.
Includes logic symbols.

Not compliant with UML.
Can be hard to learn (many
symbols).

Swimline workflow diagram

Tool used for describing process logic.
UML equivalent is an
activity diagram with
partition.

Intuitive.
Can handle many situations in one diagram.
Shows who is responsible for which action(using
partitions).

Not compliant with UML.

Sequence diagram

OO tool for describing one
path (scenario) through a
use case.

Part of OO standard (UML).
Encourages thinking in objects: Clearly specifies who does what.
Simplifies logic: Only one situation dealt with in each
diagram. Sometimes recommended for business modeling.

Diagramming style is often non-intuitive for Business Analysts and users.
Requires analyst to determine not only who carries out each activity, but who requests it.

Activity diagram

OO tool for describing logic. Used to describe entire system, a use case, or an activity within a use case. Has two versions:
Activity diagram without partitions: Does not show who does what.
Activity diagram with partitions: Shows who does what.

Part of OO standard (UML).
Can handle many situations in one diagram.
Intuitive.
Simple diagramming conventions.
Encourages thinking about opportunities for parallel activities (more than one
activity going on at the same time).

Ability to handle many
situations can lead to a diagram that is too complex to follow.

Read more...

IT – 用例图的一些符号

January 15th, 2010 Arale No comments

首先看一下下面的图.

  • Business actor: 业务之外的一些角色, 例如客户和供应商
  • Worker: 使用业务的角色, 比如说具体的员工,或者是客服代表.
  • Association: actor (business actor or worker) 和business use case之间的联系.

一些其它的元素:
Case worker: A worker who interacts directly with actors outside the system.
Internal worker: A worker who interacts with other workers and entities inside the system.

Read more...

IT – Business Analyst 的视角理解 Polymorphism

January 15th, 2010 Arale No comments

多态性:  关于多态性的定义, 我还没有想出一个通俗的定义.

举例说明:

Car, Truck, Roadster, Vehicle,前面说过.Vehile是车辆, 也就是Generalized class, Car, Truck, Roadster是Vehicle的Specialized class.  

而且这么多各类的车, 我有一个买车的操作. Buy, 在买车的时候, 需要根据买车人描述的车的种类, 车的价格,然后来返回车的类型. 哪种车, 什么价格, 这就需要BA去和stakeholder商量了.  于是,我说, 我要买车, 我给了Vehicle一个请求, 提供了必务的条件, 然后Vehicle返回了一款车给我, 可能是Bus, Car也可能是Roadster, 这是根据我给Vehicle的条件来决定的. 也就是说Vehicle是多样的.

同样的, 比如说Buy的这个方法, 在Vehicle中已经声明, 在Bus, Car中也可以使用, 但是不同的车购买的流程可能不一样. 因此就要在Bus的Buy, Car的Buy是重新书写这个购买的过程. BA便需要将这些描述清楚.

BA 所要做的, 就是找出这些东西, 如果Bus, Car的购买流程与Vehicle没有什么不一样的话, 便执行Vehicle中的Buy, 如果有不同的话, 就要在Bus, 或者是Bar中指出,并说明. 这里的说明不是长篇大论, 并不需要解释,什么条件, 情况下执行这个, 什么条件下,执行那个,只是说 "有不同" 就OK了~

P.S.

如果在C#中想要体现多态性, 虚函数是最好的方式之一.

下面的E文,是用另一个例子来描述的.

Polymorphic Objects
Suppose that a financial company handles different subtypes of Funds, such as an Asia Fund, Domestic Fund, and so on, each with its own idiosyncrasies. The BA models this situation using a generalized class, Fund, and a specialized class for each subtype of Fund.

Next, the BA moves on to capture investment rules in an Investment class. Checking with the stakeholders, the BA finds that one of its operations, invest capital, deals with all Funds the same way, regardless of subtype. The BA handles this by ensuring that the documentation for the invest capital operation refers exclusively to the generalized class Fund—not to any of its specializations.When the operation is actually executed, though, the Fund object will take on one of many forms—for example, an Asia Fund or a Domestic Fund. In other words, the Fund object is polymorphic.

Polymorphic Operations
Continuing with the same example, since all the Fund subtypes have to be able to accept deposits, the BA defines a Fund operation called accept deposit. This operation is inherited by all the specializations. The BA can also specify a method for this Fund operation that will be inherited by the specializations. But what if one or more of the specializations— for example, the Asia Fund—uses a different procedure for accepting deposits? In this case, the BA can add documentation to the Asia Fund class that describes a method that overrides the one inherited from the generalized class. (For example, the method described might involve supplementary charges.) In practice, when capital investment causes a Fund to accept a deposit, the method that is used to carry out the operation will take on one of many forms. This is what is meant by a polymorphic operation.With polymorphic operations, the selection of the method depends on which particular class (Asia
Fund, Domestic Fund, and so on) is carrying it out.

Read more...

IT – Business Analyst 的视角理解 Composition

January 15th, 2010 Arale No comments

组合: 当你理解聚合, Aggregation之后, Composition就比较好理解了. 在聚合中, 部份可以属于多个整体, 在组合中, 部份只允许属于一个整体. 当整体被删除掉, 部份也就没有了.

BA的职责当然是找出这种关系了.

举个例子, 比如说推出一种饮料调查, 需要做一个问卷,单独的一种问卷. 哪位用户, 什么职业, 年龄, 认为怎么样? 每有人喝过这种饮料, 就记录一次. 这个Form和饮料调查的关系就是Composition,当我打算删除掉饮料调查的时候, 这个FORM也就被删除了. 

当然这个例子可能不太恰当, 希望能有更好的例子.

Read more...

IT – Business Analyst 的视角理解 Aggregation

January 15th, 2010 Arale No comments

聚合: 聚合是一种用来描述 整体和部份的关系.  聚合也是一种关联. 都是将两个类之间的关系.

比如说DELL的产品, 是由 笔记本, 台式机, 服务器 组成.

“DELL Product is a collection(aggregation) that consists of many computers "

然而,笔记本, 台式机, 服务器并不仅仅属于DELL,  同样的HP可能也具有同样的产品. 在这种情况下. 可以将DELL 与 笔记本, 台式机, 服务器的关系描述成为Aggregation, 聚合.

 

当然BA的任务自然是找出这些对象及其之间的Aggregation的关系. 当然,在查找的时候,要注意可以"重用", 当你做了一个DELL产品的聚合的时候, 有一部份是 笔记本电脑, 你在定义"笔记本电脑"属性和操作时候,需要考虑, 如果我把这个拿给"HP产品" 的聚合的时候也能用.

Read more...

IT – Business Analyst 的视角理解 Association

January 15th, 2010 Arale No comments

关联: 当然这种联系并不是类似前面说的Relation,关系. 你用一个类描述的对象与另一个类描述的对象产生了关联.(这里是关联, 不是关系.) 一个很简单的例子, 当你把鼠标链接到电脑的时候,  你正在将鼠标和电脑关联. 两个类之间有联系,

作为一名BA, 正确处理好关联是很重要的一关. 因为关联错了, 前功尽弃. 比如说一台组装电脑, 有CPU, 显示卡, 母板, 硬碟, RAM等. 你是自己组装的这台电脑. BA做啥? 需要找出组成这台电脑的每一个配件, 将其和生产厂家做出关联. 如果关联做错了. 或者是少了关联会发生什么情况? 对, 配件得不到维修. 也就是说, 你的文档不正确. 扩展到业务, 你的系统可能会不支持一些业务.

Read more...

IT – Business Analyst 的视角理解 Generalization,Relationships

January 15th, 2010 Arale No comments

OO中的概念, 关系.

Car is a kind of Vehicle.  小车是一种车辆. 这句话中, Car和Vehicle是类, 两个类的关系呢就是"a kind of", 理解为是一种.

Generalization, 泛化. 可以这样理解. 同样还是上面有Car, Vehicle的例子. 其实Vehicle中不仅仅只有Car,还有Truck, Bus, Roadster 等等吧. 所以我们说Vehicle的时候, 实质上是说的是Car, Truck, Bus, Roadster 等等… 这些特定车辆. 我们把Veicle和其Subtypes(Car, Bus, Truck, Roadster)等, 叫做泛化.

这几组词可能经常在会见到.

Generalized, Specialized / Superclass, Subclass /Base class, Derived Class/Parent, Child

在UML中定义各种类的之间的关系通常有这么几种BA可能会用的到. Generalization, Association, Aggregation and Composition. (泛化, 关联, 聚合, 组合)

做为BA, 当处理这些关系的时候, 是需要找出更能用的一些方式. 前面的Car, Truck为例子, BA需要需要指出, 哪一些属性是Car和Truck共有的, 而且哪一些属性又是只存在于Car的, 哪一些属性仅存在于Truck的.通常这些属性只需要指出一次就可以了, 这样发生变动的时候, 修改起来也比较简单一些.

Read more...