2008年12月1日,星期一,04:34

业务上下文模型;要多好能有多好

撰写者

希腊哲学家苏格拉底说:“在知识世界中,善的观念首先出现,只有努力才能看到​​。”本文建议,作为业务分析人员,我们必须有胆量,要通过思想和努力尽早找到真正的业务目标来寻求项目的好处。

业务上下文模型需要表达当前的业务问题并提出项目的优缺点。

我生动地回想起在一个特定的业务上下文建模研讨会之后,政府机构的一位高级业务经理对我说:“如果仅以这种方式启动项目x,我们将就我们试图以更快的速度达成共识。 ”我从多个项目的利益相关者以及其他业务分析师那里得到了积极的反馈,他们认为这种技术是使企业参与并使其适应工作计划的有用工具。

业务上下文模型应确定在业务流程或业务领域中起重要作用的参与者(人员,组织,系统),以及与工作范围和可能需要探索的潜在变更相关的重要业务领域并进一步分析。

在项目的早期阶段,我们正在以一种相当不精确的方式在非常高的层次上进行业务建模,即以直升机的角度查看业务。我们不应为诸如输入,输出,业务规则,属性,操作或状态之类的细节建模。我们只是在尝试设置场景。通过以图形方式执行此操作,我们获得了建模的所有常规好处,尤其是将业务上下文模型用作快速合并不同业务观点并提出正确问题的工具。

根据我们的建模风格,我们可能会在上下文建模之外开始更详细的分析。我们可以创建快照上下文模型来启动我们的项目,或者可以再次根据需要或样式来通过项目继续纠正上下文模型。

我已经看到了所有形式的“上下文”图-当前状态,未来状态,环境图,系统图,网络图,通信图,业务流程图,关系图,组织图等。其中大多数在图中使用不一致的符号自己,更重要的是,不要为新来者做准备。它们通常是毫无意义的,而且是文盲。将业务上下文建模置于“上下文”中,我们需要一个快照 商业 和它的问题,还有它的意图。

我们如何开始建模上下文?将业务客户聚集在一个房间中之后,最终客户是我在白板上绘制的第一件事。否则,我将无法提出有关该问题的有意义的问题或开始分析任务。然后我们需要讨论并画出问题;这仅表示当前状态以及启动该工作的原因。下面的示例代表了一些国家当前进出口商品的问题。

 

商业_context1.png

对于不熟悉统一建模语言(UML)的读者,程序包指示感兴趣的领域。固执己见的人代表业务领域中的任何参与者-一个人,一个组织(依次代表其面向客户的渠道,例如网站或企业对企业网关)或系统。我更喜欢将系统显示为固执己见的人,因为我需要记住,作为业务分析师,它正在发挥作用,即它是业务流程中的参与者,正在执行一些业务活动。我的工作不是绘制组织系统的地图,而是专注于业务活动和业务逻辑。还应该牢记的是,在对上下文进行建模时,我们尚未尝试得出软件需求。

我将UML表示法用于上下文建模,因为建模语言与其他模型工件(例如业务域模型)一致(请参阅我的文章, 业务域建模的重要性 在11/1/08 业务分析师时报)。它在全球范围内以及当前工作之外的读者(例如,另一个项目的另一位业务分析师)都得到了理解,我可以重用或追溯到已经创建的元素。

我有 总是 使用UML表示法时,我的商业客户给予了积极的反馈。而且,他们有 总是 了解我们在UML中一起创建的内容。没有人认为我使用“ IT说话”。在讲习班中,我谈论的是我们感兴趣的业务对象,而在此过程中,我仅简要提到了当天将介绍的四个或五个简单符号。我只能说,作为我的业务建模者和分析师,与我多年来尝试和使用的所有其他技术相比,它更好,更轻松,更快,更有趣。

以下业务上下文模型表示如何“弥补”上面表达的导入/导出问题。项目范围由边界框指示。我将新软件包命名为“一堆新东西”,以强调我们需要仔细考虑一个新名称。我们可以包括重要的声明,例如业务目标-它们可以来自项目摘要,上下文建模研讨会中做出和澄清的一些声明,或者来自其他任何来源,例如首席执行官的员工交流。

 

商业_context2.png

从我们的解决方案定义的元素(例如用例)到项目活动要解决的原始业务声明(例如业务结果,目标,收益或范围声明),可追溯性对于业务建模活动至关重要。通过在模型中包含重要的项目陈述,我们立即开始创建可追溯性和业务参与以澄清含义。

在此阶段与我们的业务客户在研讨会上花费一两个小时,将节省在个人之间重新讨论这些讨论的时间。讲习班可能会很紧张和艰辛,但是当我们开始进行适当的建模时,它为我们的顺利进行做好了准备。

用良好的建模工具复制模型以使研讨会上达成的协议正式化将花费很少的时间,并且仅仅是橡皮图章,同时当然具有直接,明确且不接受个人解释和议程的巨大好处。顺便说一句,在此示例中,范围上下文模型比问题上下文模型花费的时间更少,因为我重用了已创建的模型元素。

为了清楚起见,我们可以引入其他模型元素。在这个新示例中,以下表示范围的上下文模型包括一个包,该包包含作为范围声明的特定服务产品(作为对象)。我们可能还会添加主要信息流,例如“客户订单”。当然,通过移动边界框,我们可以轻松地表达另一个项目的范围。

 

商业_context3.png

UML中的软件包可以用作将大量业务复杂性分解为可管理块的一种方式。我用它们来表示感兴趣的业务领域。每个业务分析师都应判断如何削减这些成本,但是以与业务客户对它们相同的方式命名这些软件包很重要。一般准则是使用该程序包包含“一堆东西”。因此,集体名词是很好的单词,例如xyz管理,家庭。我已将软件包命名为部门,这些部门的功能领域与行业模式保持一致,例如销售订单管理,或者再次,仅仅是“一堆东西”,例如边境安全。

如果我们努力查看业务或项目中的优势,我们可以轻松地进行自我设置以进行进一步的分析,并完全可追溯到原始业务需求,从而为我们节省了很多时间。每个感兴趣的领域都可以作为与该工作相关的某些业务流程的基础。包名称可能在我们的业务流程的第一部分中成为活动的泳道,如果合适,还可以与上下文模型中标识的每个参与者的泳道一起。边界框中的软件包将包含业务逻辑,规则和用例,以支持范围内的业务活动和交互。作为建模者,我们的目标之一是给自己最大的机会来重用已经创建的模型元素。

我们可以将上下文建模用于任何我们想考虑的重要事项,甚至可以用于制定家庭计划或帮助我们通过战略决策和承诺以及监管要求进行思考。下面是一个不完整的例子,我较早前就实现生活的各个方面达成了共识。

 

商业_context4.png

软件包,参与者和关联已通过这种方式进行了描述,以允许进行分析,其结果可能直接与上下文模型中的元素相关。我们的目标是减少工作量并重用已经完成的工作。只要符号一致且正确使用,使用良好的建模工具(而不是绘图工具)就可以执行此操作,即,我们不会偏离标准UML到Pidgin UML。毕竟,如果书面材料中的清晰度是每天的工作,我们就不会使用Pidgin English。

如果我们对自己诚实,并听听我们的项目经理的问题陈述(“花费时间太长”),我们的解决方案架构师(“需求不明确或彼此不一致”)和我们的业务客户(“我没有时间审查太多书面工作,也没有时间等待它。”),我们将停止写作,而只花时间澄清一些重要的口头陈述作为可追溯性的基线,并且投资于进行业务建模所需的智力活动。我们必须花时间问所有正确的问题,认真听取答案,使用UML之类的形式表示法,尽可能清晰,明确地捕捉和构建所收集的知识。

就像吉姆和米歇尔·麦卡锡在书中所说的 软件开发动态为我们提供了按时交付出色软件的规则,“软件开发管理的真正任务是调集尽可能多的知识……”如果在项目的早期阶段进行了此类投资,则业务分析师可以捕获业务远景的本质,项目的优势,然后集中精力将业务知识产权(IP)引入后续的业务分析工件中。

对业务环境进行建模并不是一项机械装配线任务,以映射组织中已经存在的某些事物。这是一项智力活动,需要业务分析师来提出业务问题并与业务可视化如何解决该问题。

在以后的文章中,我们将研究对业务流程和控制其组成的活动的规则进行建模。

本文基于“真相,美丽&作者于2008年在新西兰惠灵顿发表的“善意”演示系列。作者在此感谢以下人士对本文的自由贡献:LD,BL,JM,HT。

版权所有©Suzanne Jane Maxted,2008年11月。

 


苏珊·简·麦克斯特 是英国计算机协会的IT专业人员认证成员。她获得了英格兰萨塞克斯大学的数学荣誉学士学位&欧洲研究统计(法语)。 Suzanne是一位业务分析师,在全球拥有16年的经验。她是业务分析领域经验丰富的讲习班主持人和演示者,并向欧洲委员会和联合国等高级成员国代表作了演讲。她以将逻辑和顺序应用于不同的业务观点以及交流共识而感到自豪。苏珊(Suzanne)在周六早上为3-8岁的孩子们教授芭蕾舞,并用业余时间跳舞和与两个孩子一起玩耍。可以在以下位置到达苏珊 [email protected] 要么 [email protected]
苏珊·简·麦克斯特

苏珊·简·麦克斯特 是英国计算机协会的IT专业人员认证成员。她获得了英格兰萨塞克斯大学的数学荣誉学士学位&欧洲研究统计学(法国),在巴黎大学就读法语。 Suzanne是一位业务分析师,在全球拥有16年的经验。她是业务分析领域经验丰富的讲习班主持人和演示者,并向欧洲委员会和联合国等高级成员国代表作了演讲。她以将逻辑和顺序应用于不同的业务观点以及交流共识而感到自豪。 Suzanne还指导其他业务分析师和项目经理,并且是《 业务分析师时报》杂志的定期撰稿人。 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

麦格雷戈徽标白色网站