企业业务建模介绍

企业业务建模介绍&讨论

2021/5/91课程内容企业业务建模使用UML进行业务建模需求管理与用例建模技术2021/5/92一、企业业务建模定义、目的、框架、业务规则、业务模式、业务架构、软件架构2021/5/93企业业务建模定义

企业业务建模，也称企业建模或业务建模，是一种全新的企业经营管理模式，它为企业提供一个框架结构，以确保企业的应用系统与企业经常改进的业务流程紧密匹配。2021/5/94企业业务建模目的对企业进行更好的理解和提供公共一致的表示形式重用企业中现有的知识和技能分析企业的某些特性以持续的改进企业性能管理企业系统的复杂性提高企业信息系统的模型驱动设计水平2021/5/95企业业务建模的几种框架Zachman框架ARIS集成信息系统架构EPMS业务过程建模方法CIM-OSA方法IDEF方法DEM动态企业建模方法2021/5/96Zachman框架What（数据）How（行为）Where（地点位置）Who（角色）When（时间）Why（动机）2021/5/972021/5/98ARIS集成信息系统架构eERMeERM-attribute定位图关系图特性设置图图表数据视图机构图网络拓扑结构网络图组织视图功能树枝图目标图应用系统分类图应用系统样本图功能视图信息流图功能定位图增值链图eEPC，PCD访问图访问图表（具体的）控制视图2021/5/99ARIS集成信息系统架构组织视图：组织结构的静态模型。包括：层次组织结构的人员资源，生产资源（设备，运输等）以及计算机、通信网络结构等。数据视图：业务信息的静态模型。包括：数据模型，知识结构，信息载体，技术术语和数据库模型等。功能视图:业务流程任务的静态模型。包括：功能层次，业务对象，支持系统和应用软件等。控制视图：动态模型，展示流程运转情况，并能够将业务流程与流程相关的资源、数据以及功能等联系起来。包括：事件驱动过程链、信息流、物流、通信图、产品定义、价值增值图等。2021/5/910业务规则业务规则是组织用于做出运作决策的原则业务规则是对如何操作业务的各种要求。他们可以是业务需要遵守的法律或规范，也可以是业务范围政策以及计算方法和公式、风险阈值和正式授权分类：约束规则：规定了限制对象结构和行为的策略和条件推导规则：规定了从一些事实经过推理和计算得到其他事实的策略和条件。2021/5/911业务规则管理业务规则管理（BRM）将控制运作决策的逻辑从单独的应用程序中解放出来。在单个应用程序中，这些逻辑一般是被封锁在编程代码内的。这种方式就像数据库管理解放了数据库一样。业务规则管理减少了上市时间和总拥有成本，节省了大量应用程序实施成本。2021/5/912业务规则描述对象约束语言(ObjectConstraintLanguage,OCL)OCL表达式以附加在模型元素的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式、附加在操作和方法上的前置条件和后置条件等。2021/5/913业务模式一个业务模式描述了一个可重用方法来解决一个特别的商业问题，这个商业问题通常是在商业过程范围内例如：资源和规则模式目标模式过程模式BusinessModelingwithUML:BusinessPatternsatWork2021/5/914案例：神州数码的企业业务模型组织结构图公司业务分布网络技术职位序列文化体系服务产品体系业务布局图销售业务流程图2021/5/915业务架构相互之间具有明确关系的元素组成的集合，这些元素一同形成了一个按功能定义的整体。他们代表业务的组织及行为结构，并提供对业务的关键流程与结构的抽象表达。2021/5/916业务架构中的视图业务流程视图包括业务的关键业务流程并对其进行概述，这些流程是业务存在的原因组织结构视图概述业务中的关键角色和职责以及他们的分组情况文化视图说明组织的文化特征，以及为鼓励这些特征而采取的机制人力资源视图讨论为维持和发展组织的人力资源而应用的机制领域视图定义应用于信息结构的关键机制和模式2021/5/917软件架构软件架构包含了软件系统组织结构的重要决策软件系统的组织对组成系统的结构元素及接口的选择在元素间的协作中所详述的行为将结构元素和行为元素组合进逐步增大的子系统指定这种组织的架构样式：静态、动态元素和它们的接口、它们的协作、它们的合成2021/5/918软件架构中的视图2021/5/919用例视图包括用例模型，它代表由它的终端用户所见的该系统想要的功能和环境用作终端用户和开发者之间的一个合同对分析和设计以及测试活动是重要的。包括用例图、用例事件流和补充文档。它也能包括活动图是其它视图的心脏，因为它详述了形成系统架构的动力2021/5/920设计视图支持该系统的功能性需求，即系统应该提供给它的终端用户的服务包括用例实现、类和交互图。它也能包括状态图和活动图注：一组执行业务用例工作的角色个体和作为部分工作而访问并使用的业务对象一起，称为业务用例实现。记录业务用例实现的首选方法就是绘制活动图，还可以使用序列图，类图等。2021/5/921进程视图包括构成该系统的并发性和同步机制的线程和进程包含了形成系统并发与同步机制的线程和进程该视图主要针对性能、可伸缩性和系统的吞吐量。对单处理环境是不必要的2021/5/922实现视图根据包装、分层和配置管理描述静态的软件模块（源代码、数据文件、组件、可执行文件等）。关注开发容易性、软件资产管理、重用、子合同等问题2021/5/923部署视图只用于分布式系统显示各种各样的可执行文件和运行时组件如何被映射到潜在的平台和计算节点关注部署、安装和性能等问题显示一张部署图2021/5/924业务模型和软件模型的融合业务用例模型业务分析模型业务模型=用例模型分析模型设计模型实现模型测试模型业务建模需求分析和设计实现测试2021/5/925基于用例的建模用例是组织需求的一种推荐方法用例不是使用一个需求列表组织需求，用例使用某人可以如何使用系统的方式来组织需求通过用例，需求更完整和更一致，并且可以从用户的角度更好的理解需求的重要性2021/5/926二、使用UML进行业务建模见IBM原版教材2021/5/927三、需求管理与用例建模技术2021/5/928传统软件过程面临的问题分析与用户存在语义分歧对问题域缺乏全面的认识多变的需求导致效率低下设计无法预知和降低风险设计决定用户难以理解与实现难以平滑衔接实现周期过长与分析设计脱节版本之间管理混乱测试测试成本过高无法做到回归测试维护成本过高产品质量不可靠寿命短重用性低可维护性差兼容性差文档混乱2021/5/929造成软件项目失败的根本原因不好的需求管理模糊和不精确的交流脆弱的架构未检测出需求、设计和实现之间的不一致测试的不足对于项目状况的评估过于主观为解决存在的风险无法控制变化的产生和传播自动控制不做2021/5/930软件工程的六条最佳实践迭代的开发软件管理需求应用基于组件的架构为软件建立可视化的模型持续的验证软件质量控制软件的变更2021/5/931软件工程的六条最佳实践迭代开发控制变更管理需求使用基于组件的架构可视化建模质量验证架构为中心迭代和增量开发用例驱动2021/5/932什么是需求用户为了达到某个目标而解决某个问题时所必需的一种软件能力系统或系统组件为满足某个合约、标准、规格说明或其它正式文档所必须达到或拥有的软件能力2021/5/933什么是需求管理描述、组织和文档化需求的过程为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程2021/5/934从用户需求到软件需求2021/5/935需求分类涉众要求（Request）或涉众需求（Need）关于涉众对系统期望的描述，与具体的解决方案无关特性（Feature）为了满足涉众需要，系统提供的外部可见的服务软件需求（SoftwareRequirement）功能性需求非功能性需求约束（Constraint）设计系统及流程设计的约束条件2021/5/936需求举例涉众要求（Request）或涉众需求（Need）可以快速找到系统中的所有岗位信息特性（Feature）使用树形结构显示系统提供的岗位信息软件需求（SoftwareRequirement）功能性需求用户选择“注册”功能，系统提供空白注册界面非功能性需求提供24*7小时服务约束（Constraint）用户通过互联网访问；系统使用java技术2021/5/937为什么需求管理困难因为需求有如下特征：总是不显而易见来源多种多样不容易用文字清晰表达与其他需求和软件工程过程中的其他交付物关联容易变化需求数量增加时难以控制2021/5/938需求管理的目标在预算内按时开发出符合客户真正需要的高质量产品2021/5/939帮助项目成功问题分析理解问题取得涉众同意清晰表达业务目标需求描述指明谁将使用系统（Actor）描述系统如何被使用（UseCase)需求管理详细说明需求管理需求、变更和错误控制范围蔓延团队成员参与2021/5/940项目团队参与需求开发人员、测试人员以及文档编写人员帮助需求管理的实行监控需求是否被实现文档化需求参与需求评价参加变更控制组（CCB）评价跟踪结果验证质量、易测性和完备性2021/5/941软件需求的质量特性正确完备一致无二义可验证可排序（重要性和稳定性）可修改可跟踪可理解2021/5/942RUP中的需求管理RationalUnifiedProcess是一个软件过程框架，它为开发组织提供了分配任务及责任的规程和方法2021/5/943RUP概览2021/5/944需求规程的工作流详述2021/5/945需求规程的目标需求规程的目的:与客户和其他项目涉众就应用系统应该有什么取得一致意见，并维护这种一致性帮助系统开发人员更好的了解系统需求定义系统的边界为规划迭代的技术内容提供基础定义系统的用户界面，主要关注用户的需要和目标要实现这些目标，首先要理解尝试使用该系统解决的问题的定义和范围，这一点很重要。确定项目涉众并引发、收集和分析涉众需求。然后将开发需求工作产品来描述系统（系统要做什么）以便将所有项目涉众（包括客户和潜在客户）视为除了系统需求以外的重要信息来源2021/5/946角色和工件2021/5/947需求管理涉及的主要工件远景（Vision）问题定义涉众列表环境和平台补充规约非功能性需求UseCase规约功能性需求术语（Glossary）公共术语涉众需要涉众的需要和请求2021/5/948我们在哪里？2021/5/949分析问题的目标开发之前对要解决的问题有一个更好的理解有的时候，解决一个特定的问题仅仅需要改变业务流程，而不是需要一个新系统。比如，建立管理生产流程，提供其他的变通方法。作为解决问题的人，我们有义务在建立新系统之前先去考察一些可能的替代解决方案2021/5/950分析问题的步骤识别涉众涉众指能被系统或项目的结果造成实际影响的人理解问题在问题定义上达成一致识别系统或项目的约束确定并验证解决根本问题的方案确定系统边界2021/5/951远景文档远景文档是从客户的角度撰写的，它关注系统的主要特性和可以接受的质量等级。远景应该描述将要包括的特性以及那些已考虑到但没有包括进来的特性。它还应该指定操作容量（卷、响应时间、精确度）、用户概要文件（谁将使用系统）以及与系统边界外的实体之间的互操作界面（如果适用）。远景文档提供正在开发的软件系统的完整远景，并支持出资方与开发组之间的约定。每个项目都需要一个来源，以记录项目涉众的期望值。2021/5/952远景文档提纲简介定位涉众和用户描述产品概述产品特性约束质量范围优先顺序和优先级其他产品要求记录要求功能属性2021/5/953识别约束环境政策经济技术系统可行性2021/5/954识别约束约束源约束理由操作性销售订单数据必须在系统中保持一年时间数据丢失风险太大系统及操作系统这个程序在服务器上应该占用少用20M的空间服务器上空间有限设备预算必须使用已有的服务器和主机成本控制已经设备维护人员预算固定的人力资源：无外部资源现有预算紧张技术要求应该才用OO技术相信这种技术可以增加生产效率并增加可靠性2021/5/955Actor帮助定义系统边界可以简单认为，解决方案的世界分为两个部分我们要开发的系统与我们系统进行交互的事物这种交互的事物我们称为我们系统的参与者。可以通过以下问题来帮助寻找谁会对系统提供信息、使用信息、删除信息谁将操作系统谁是维护者系统在哪儿被使用系统从哪儿得到信息哪些外部系统要和系统进行交互2021/5/956捕捉公共词汇定义项目中的术语帮助减少误解2021/5/957我们在哪里？2021/5/958需求的来源PartnersCustomerUsersProblemDomain2021/5/959可能遇到的问题涉众对解决方案有先入为主的想法不知道自己真正想要什么不能正确描述自己想要的东西交付之前以为自己知道想要什么系统分析员以为自己比用户更了解问题每个人从各自的角度看待问题相信自己是正确的2021/5/960涉众需要工件属于涉众包括来自涉众的所有需要来源包括Email、客户需求说明、白板、电子表格…可能包括对任何外部资源的引用项目组据此得到产品特性及软件需求2021/5/961如何抽取涉众需求查阅用户需求说明需求讨论会UseCase讨论会头脑风暴用户访谈调查问卷角色扮演系统原型故事板2021/5/962我们在哪里？2021/5/963特性（Feature）特性是外部可见的服务特性是为了完成涉众的一个或多个需要而提供的服务例子：问题跟踪系统的特性是能够提供趋势报告，以帮助项目经理评估项目状态ATM应允许客户之间转款2021/5/964实例特性1：个人用户和企业用户均可以通过internet注册特性2：系统提供岗位IT技能测评和按课程的单科评测特性3：系统能够以树状方式显示岗位列表技能列表特性4：企业能够根据自身需求设置岗位及对应的技能特性n：能够修改用户的支付信息，并能够为企业用户分配lisence数量2021/5/965识别系统特性的建议步骤写产品定位陈述使用头脑风暴收集系统特性回购收集来的特性把这些特性与涉众需要进行关联，建立跟踪矩阵精化远景文档确定产品定位陈述列出关键特性2021/5/966用例建模步骤识别Actor和UseCase简要描述写每个Usecase的提纲基本流可选流详述每个Usecase详述时间流结构化用例加入详细信息，如前置/后置条件、特殊需求、关系、图等2021/5/967我们在哪里？2021/5/968定义系统范围资源预算时间范围2021/5/969建立需求基线需求基线一个特性的集合，建立在一致认同的基础上，只能通过正式程序进行变更基线必须至少对客户来说是可接受的在团队看来具有合理的成功可能性2021/5/970设定特性优先级对于规模管理非常重要在确定优先级的过程中，重要的是由客户和用户、产品经理或其它代表而不是开发团对自己做决定并建立优先级实际上，这个早期的优先级确定过程不应该受到技术部门的过多影响；否则，技术难度将影响客户的优先级决定2021/5/971评估工作量为提出的基线中的每个特性粗略确定工作量为了不在后来被认为是“浪费资源”的事物上投入资源，包括不能实现的特性的需求说明、设计和以后的测试脚本。我们最大的目标是在项目的初始版本就减少开发特性的数量，由于资源有限，我们不能在当前的基线下对不可能实现的特性作投入2021/5/972设定Usecase优先级考虑与基线中特性相关联的Usecase选择具有如下特点的场景代表有意义的、重要的功能与实际的系统元素或接口相关联代表系统中明确的、精细部分被标记为高风险为今后的迭代设定优先级2021/5/973我们在哪里？2021/5/974设计约束设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、架构及设计约束、购买的构件、类库等。设计约束是对系统的设计或开发的限制，他不影响系统的外部行为，但必须被完成以满足技术、商业或合同的义务被开发的系统基础设施中，通常包括：操作系统、与已有系统的兼容性、应用标准开发所使用的规章和标准的实体。例如：ISO9000标准2021/5/975如何描述功能性需求使用Usecase和说明文档为了理解系统的复杂性，两者都很重要2021/5/976如何处理不在Usecase中的需求？使用说