2010年6月1日,星期二,08:44

业务分析方案;了解业务互动

撰写者

在之前的文章中,我们检查了 业务环境模型,使用 业务领域模型。我们研究了业务在 业务分析过程 文章。

本文讨论了业务方案在表达人员与业务元素之间的联系方面的作用,并提出了一种建模方法。即使到了今天,企业的真理珠宝的清晰度和美感也常常在莫名其妙的言语泛滥中被模糊(哈哈!)-可怜的老技术人员不得不从伪装成堆的言语腹泻中挑选出这些宝石作为“文档”。

业务场景可用于:

  • 了解业务交互。
  • 从业务角度对一个软件进行原型制作或情节提要,而无需呈现会分散练习内容的屏幕和按钮,从而使设计活动保持独立。
  • 测试需求的完整性,从而找到迄今为止所理解的逻辑中的空白。例如:
    • 通过业务流程或用例测试一条路径的完整性
    • 在故事(域类)中查找遗漏的角色及其职责
    • 了解场景中角色的更改(状态更改)
    • 了解“用户故事”
    • 用作新系统组件的测试用例
  • 作为观察者记录笔记或增进我们自己的理解;提出问题的工具。

方案的目的是了解和交流 人员,系统或业务或系统的预期逻辑组件之间的交互。换句话说,业务场景只是业务中人或事物/对象之间的对话。

场景也是使用真实示例或情况实例以及其中的人员来测试理论业务流程和领域模型的良好工具。尽管我们在业务场景中指定行为;指定一个真实的实例将使业务场景建模与建模业务流程或用例不同。

那么,我们如何开始构建业务场景呢?使用进行对话的想法,想象业务中存在的所有事物都是可以与他人交谈的人或发明人。例如,下订单后,我需要一种处理帐单的方法。我不知道帐单的概念是什么,但我确实知道有一种叫做“订单”的东西。假设Order是一个人,则需要与其他事物或人进行对话。我将其称为“帐单管理器”(一个逻辑组件,因为我还不了解这方面的知识)。现在,业务流程中的这两个“参与者”可以进行特定的对话(例如,如果已经指定了业务流程或用例的一条路径)。

可以使用以下语法结构将业务场景编写为围绕业务活动的请求和订单的场景子句集:-主语动词名词对象

示例场景:

乔问:“你会修理我的自行车吗?”到弗雷德
弗雷德对乔回答“是的,如果你付钱给我”
乔问“多少钱?”到弗雷德
弗雷德对乔回复“ $ 100 mate”
乔对弗雷德说“好”
乔把自行车交给弗雷德
弗雷德修理自行车
弗雷德对乔说:“我已经修理好你的自行车。请给妈妈100美元。”
乔对弗雷德说:“谢谢,我会的”
乔向妈妈支付了100美元
妈妈问:“那100美元是什么?”到弗雷德
弗雷德对妈妈说“为一辆新自行车节省了钱”

这是表达业务方案的一种完全有效的方法。但是,旧的问题浮出水面。我们将“乔”而不是一次写了9次,“弗雷德”而不是一次写了11次,将“妈妈”而不是一次写了4次,从而增加了工作量。我们无法重用在这种情况下创建的内容。我们必须每次输入“ 乔”或复制“ 乔”。此外,这里获得的知识将丢失在文档中,以后很难找到,这与使用良好的建模工具维护业务体系结构相反,这使我们在下一次交谈时可以将Joe拖到图片中。模型元素“ 乔”将不是经过修改的克隆。那将是唯一的乔。

向利益相关者介绍业务场景建模的一种方法是,如上在白板上开始编写,然后通过擦除左右两侧的对象名称并添加“对话”的方向(箭头),将其转换为图表。和涉及的人员(对象生命线)如下:

弗雷德
乔问 “你会修理我的自行车吗?”→ 到弗雷德
弗雷德回答 ←“是的,如果你付钱给我的话” 给乔
乔问 “多少钱?”→ 到弗雷德
弗雷德回答 ←“ $ 100伴侣” 给乔

消息用各种各样的箭头表示(与所有建模技术一样,我建议读者研究可用的表示法),但是基本上,发送的消息要么是为另一个对象提供服务的调用(订单或请求),要么是返回(答案) )拨打电话。 (请注意,对象提供的服务是对类的操作。)

这是表示为UML序列图的方案:

业务分析场景1

我更喜欢使用统一建模语言(UML),因为:

  1. 它被广泛接受为全球标准的正式符号,
  2. 它可以让我覆盖 所有 我只需要使用一种符号即可完成的建模类型
  3. 我可以对我的业务受众使用现有的标准符号,而不是强加我和同事发明的一种或多种无法普遍理解的符号。
  4. 我可以最大程度地重用模型元素,减少工作量并消除术语上的不一致和错误, 所有图中的符号。

以我的经验,业务和技术读者喜欢描述业务分析师所提供的业务的准确性和速度,业务分析师可以以抽象和逻辑的方式思考,并且使用有意义的标签作为模型元素。我遇到的唯一例外是企业主,他声称自己是言语思想家,后来发现很难查看图表。但是,她对业务分析人员的抱怨是无休止的重复和文本不一致,并且一个反馈评论说:“ ...不应忽略业务场景分析!”还有另一个“我希望看到那些简笔画...”。

我的建议是谨慎而实用地使用UML,请参考帮助手册以避免尽可能地违反规则。在研讨会上,我只使用4到5个符号-容易被高素质的商业听众消化。我在研讨会中的意图不是要向我的企业教授UML。我什至没有提到UML,而只是让听众放心,据我所知,我正在使用当前的标准符号来描述业务。当我记录(比散文要快得多的速度)被理解和达成共识时,我会在绘制符号时“说出”这些符号。稍后,当我对模型进行形式化确定后,我与希望再次查看的人进行了交谈。我的另一个规则是,在未与业务受众进行上述过程之前,绝不要发送或移交模型。

回到场景:一位受人尊敬的解决方案架构师同事告诉我,允许业务分析师进行时序图就像将雕刻刀交给幼儿。我抗议,但发现自己想知道他是否正确。考虑到组织普遍倾向于跳到解决方案模式并谈论系统,他可能已经看到许多业务分析师在解决方案团队的脚步上,而不是在建模时专注于业务概念和对象,尽管他没有忽略由建模人员施加的约束。现有解决方案组件。我会回到这一点。

与任何建模技术一样,重要的是判断何时才适合使用,因为没有时间来开发每种可能的业务方案。为了确定这项工作的范围,请考虑响应重要外部利益相关者的目标和预期结果的核心业务服务。另一方面,我知道一位业务分析师会优先使用此工具作为他理解的起点。如果确实使用它们,那么我建议对成功的快乐日场景进行建模,即80%的时间应该发生什么,并为业务的每个主要领域设置一些主要和典型的例外情况。当然,在我要写的书中,它们应该由业务人员和测试人员在业务分析师的帮助下创建。对于高级建模人员,我建议研究分布式控制和封装的原理,以通过将相关行为和数据保持在一起来减少将来更改的影响。

回到我的观点。我们不要忘记,业务分析师的作用是分析业务,描述业务及其意图。在本文和开头提到的文章中,我们集中于理解,指定和交流问题,业务变更的范围和要求。如果我们坚持业务概念和业务口头表达,就不会冒着技术倾向模型吓models观众的风险。我们需要以一种复杂而有用的方式记录商务谈话,并使其看起来像一场真实的人类谈话。

别忘了在下面留下您的评论


苏珊·简·麦克斯特(Suzanne Jane Maxted)荣誉学士,MBCS CITP, 是一位业务架构师和分析师,在全球拥有17年的经验。她是 精通业务的建模师,讲习班主持人和演示者。 苏珊娜(Suzanne)执教业务分析师和项目经理,并且是《商业分析师时报》(Business Analyst Times)的定期撰稿人,获得了广泛的好评,并获得了读者的积极反馈。在2008年和2009年,她是在新西兰惠灵顿举行的BA世界研讨会的演讲者和小组成员。苏珊娜(Suzanne)忙于业余时间教书和表演舞蹈(参加2007年新西兰舞蹈节,2009年惠灵顿古巴街狂欢节),并与两个孩子玩得开心。可以通过以下方式与她联系 [email protected]

版权所有©Suzanne Jane Maxted,2010年

苏珊·简·麦克斯特

苏珊·简·麦克斯特 是英国计算机协会的IT专业人员认证成员。她获得了英格兰萨塞克斯大学的数学荣誉学士学位&欧洲研究统计学(法国),在巴黎大学就读法语。 Suzanne是一位业务分析师,在全球拥有16年的经验。她是业务分析领域经验丰富的讲习班主持人和演示者,并向欧洲委员会和联合国等高级成员国代表作了演讲。她以将逻辑和顺序应用于不同的业务观点以及交流共识而感到自豪。 Suzanne还指导其他业务分析师和项目经理,并且是《 业务分析师 Times》杂志的定期撰稿人。 2008年,她曾在新西兰惠灵顿举行的BA世界研讨会上担任演讲嘉宾和小组成员。苏珊(Suzanne)在周六早上为3-8岁的孩子教芭蕾舞,并安排业余时间跳舞(她在NZ舞蹈节上表演过),并与两个孩子一起玩耍。苏珊的个人呼吁:请游说您的政府,以控制蜜蜂病毒性疾病和寄生虫的传播。蜜蜂对地球上的所有生命都至关重要。本文基于“真相,美丽&作者于2008年和2009年在新西兰惠灵顿发表的“善良”系列演讲。&“善意”材料并不是要具有权威性,而只是为了帮助其他人进一步发展自己对业务分析的探索。作者希望感谢以下人员对本文的自由贡献和贡献:LD,BL,JM , H T。

版权所有©Suzanne Jane Maxted,2009年2月, [email protected] or [email protected]    3/09

©BA Times.com 2020

麦格雷戈徽标白色网站