企业业务建模介绍课件

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