企业业务建模介绍.ppt

《企业业务建模介绍.ppt》由会员分享，可在线阅读，更多相关《企业业务建模介绍.ppt（85页珍藏版）》请在三一办公上搜索。

1、企业业务建模介绍&讨论,吴晓明,课程内容,企业业务建模使用UML进行业务建模需求管理与用例建模技术,一、企业业务建模,定义、目的、框架、业务规则、业务模式、业务架构、软件架构,企业业务建模定义,企业业务建模，也称企业建模或业务建模，是一种全新的企业经营管理模式，它为企业提供一个框架结构，以确保企业的应用系统与企业经常改进的业务流程紧密匹配。,企业业务建模目的,对企业进行更好的理解和提供公共一致的表示形式重用企业中现有的知识和技能分析企业的某些特性以持续的改进企业性能管理企业系统的复杂性提高企业信息系统的模型驱动设计水平,企业业务建模的几种框架,Zachman框架ARIS集成信息系统架构EPMS

2、业务过程建模方法CIM-OSA方法IDEF方法DEM动态企业建模方法,Zachman框架,What（数据）How（行为）Where（地点位置）Who（角色）When（时间）Why（动机）,ARIS集成信息系统架构,ARIS集成信息系统架构,组织视图：组织结构的静态模型。包括：层次组织结构的人员资源，生产资源（设备，运输等）以及计算机、通信网络结构等。数据视图：业务信息的静态模型。包括：数据模型，知识结构，信息载体，技术术语和数据库模型等。功能视图:业务流程任务的静态模型。包括：功能层次，业务对象，支持系统和应用软件等。控制视图：动态模型，展示流程运转情况，并能够将业务流程与流程相关的资源、数据

3、以及功能等联系起来。包括：事件驱动过程链、信息流、物流、通信图、产品定义、价值增值图等。,业务规则,业务规则是组织用于做出运作决策的原则业务规则是对如何操作业务的各种要求。他们可以是业务需要遵守的法律或规范，也可以是业务范围政策以及计算方法和公式、风险阈值和正式授权分类：约束规则：规定了限制对象结构和行为的策略和条件推导规则：规定了从一些事实经过推理和计算得到其他事实的策略和条件。,业务规则管理,业务规则管理（BRM）将控制运作决策的逻辑从单独的应用程序中解放出来。在单个应用程序中，这些逻辑一般是被封锁在编程代码内的。这种方式就像数据库管理解放了数据库一样。业务规则管理减少了上市时间和总拥有成

4、本，节省了大量应用程序实施成本。,业务规则描述,对象约束语言(Object Constraint Language,OCL)OCL表达式以附加在模型元素的条件和限制来表现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式、附加在操作和方法上的前置条件和后置条件等。,业务模式,一个业务模式描述了一个可重用方法来解决一个特别的商业问题，这个商业问题通常是在商业过程范围内例如：资源和规则模式目标模式过程模式Business Modeling with UML:Business Patterns at Work,案例：神州数码的企业业务模型,组织结构图公司业务分布网络技术职位序列文化体系服

5、务产品体系业务布局图销售业务流程图,业务架构,相互之间具有明确关系的元素组成的集合，这些元素一同形成了一个按功能定义的整体。他们代表业务的组织及行为结构，并提供对业务的关键流程与结构的抽象表达。,业务架构中的视图,业务流程视图包括业务的关键业务流程并对其进行概述，这些流程是业务存在的原因组织结构视图概述业务中的关键角色和职责以及他们的分组情况文化视图说明组织的文化特征，以及为鼓励这些特征而采取的机制人力资源视图讨论为维持和发展组织的人力资源而应用的机制领域视图定义应用于信息结构的关键机制和模式,软件架构,软件架构包含了软件系统组织结构的重要决策软件系统的组织对组成系统的结构元素及接口的选择在元

6、素间的协作中所详述的行为将结构元素和行为元素组合进逐步增大的子系统指定这种组织的架构样式：静态、动态元素和它们的接口、它们的协作、它们的合成,软件架构中的视图,用例视图,包括用例模型，它代表由它的终端用户所见的该系统想要的功能和环境用作终端用户和开发者之间的一个合同对分析和设计以及测试活动是重要的。包括用例图、用例事件流和补充文档。它也能包括活动图是其它视图的心脏，因为它详述了形成系统架构的动力,设计视图,支持该系统的功能性需求，即系统应该提供给它的终端用户的服务包括用例实现、类和交互图。它也能包括状态图和活动图,注：一组执行业务用例工作的角色个体和作为部分工作而访问并使用的业务对象一起，称为

7、业务用例实现。记录业务用例实现的首选方法就是绘制活动图，还可以使用序列图，类图等。,进程视图,包括构成该系统的并发性和同步机制的线程和进程包含了形成系统并发与同步机制的线程和进程该视图主要针对性能、可伸缩性和系统的吞吐量。对单处理环境是不必要的,实现视图,根据包装、分层和配置管理描述静态的软件模块（源代码、数据文件、组件、可执行文件等）。关注开发容易性、软件资产管理、重用、子合同等问题,部署视图,只用于分布式系统显示各种各样的可执行文件和运行时组件如何被映射到潜在的平台和计算节点关注部署、安装和性能等问题显示一张部署图,业务模型和软件模型的融合,业务用例模型,业务分析模型,业务模型,=,用例模

8、型,分析模型,设计模型,实现模型,测试模型,业务建模,需求,分析和设计,实现,测试,基于用例的建模,用例是组织需求的一种推荐方法用例不是使用一个需求列表组织需求，用例使用某人可以如何使用系统的方式来组织需求通过用例，需求更完整和更一致，并且可以从用户的角度更好的理解需求的重要性,二、使用UML进行业务建模,见IBM原版教材,三、需求管理与用例建模技术,传统软件过程面临的问题,分析与用户存在语义分歧对问题域缺乏全面的认识多变的需求导致效率低下,设计无法预知和降低风险设计决定用户难以理解与实现难以平滑衔接,实现周期过长与分析设计脱节版本之间管理混乱,测试测试成本过高无法做到回归测试维护成本过高,产

9、品质量不可靠寿命短重用性低可维护性差兼容性差文档混乱,造成软件项目失败的根本原因,不好的需求管理模糊和不精确的交流脆弱的架构未检测出需求、设计和实现之间的不一致测试的不足对于项目状况的评估过于主观为解决存在的风险无法控制变化的产生和传播自动控制不做,软件工程的六条最佳实践,迭代的开发软件管理需求应用基于组件的架构为软件建立可视化的模型持续的验证软件质量控制软件的变更,软件工程的六条最佳实践,迭代开发,控制变更,管理需求,使用基于组件的架构,可视化建模,质量验证,架构为中心,迭代和增量开发,用例驱动,什么是需求,用户为了达到某个目标而解决某个问题时所必需的一种软件能力系统或系统组件为满足某个合约

10、、标准、规格说明或其它正式文档所必须达到或拥有的软件能力,什么是需求管理,描述、组织和文档化需求的过程为系统的需求进行启发、组织、建档的系统方法，一个建立和维护客户和项目团队之间关于变更系统需求所达成的一致性的过程,从用户需求到软件需求,需求分类,涉众要求（Request）或涉众需求（Need）关于涉众对系统期望的描述，与具体的解决方案无关特性（Feature）为了满足涉众需要，系统提供的外部可见的服务软件需求（Software Requirement）功能性需求非功能性需求约束（Constraint）设计系统及流程设计的约束条件,需求举例,涉众要求（Request）或涉众需求（Need）可以

11、快速找到系统中的所有岗位信息特性（Feature）使用树形结构显示系统提供的岗位信息软件需求（Software Requirement）功能性需求用户选择“注册”功能，系统提供空白注册界面非功能性需求提供24*7小时服务约束（Constraint）用户通过互联网访问；系统使用java技术,为什么需求管理困难,因为需求有如下特征：总是不显而易见来源多种多样不容易用文字清晰表达与其他需求和软件工程过程中的其他交付物关联容易变化需求数量增加时难以控制,需求管理的目标,在预算内按时开发出符合客户真正需要的高质量产品,帮助项目成功,问题分析理解问题取得涉众同意清晰表达业务目标需求描述指明谁将使用系统（A

12、ctor）描述系统如何被使用（Use Case)需求管理详细说明需求管理需求、变更和错误控制范围蔓延团队成员参与,项目团队参与需求,开发人员、测试人员以及文档编写人员帮助需求管理的实行监控需求是否被实现文档化需求参与需求评价参加变更控制组（CCB）评价跟踪结果验证质量、易测性和完备性,软件需求的质量特性,正确完备一致无二义可验证可排序（重要性和稳定性）可修改可跟踪可理解,RUP中的需求管理,Rational Unified Process 是一个软件过程框架，它为开发组织提供了分配任务及责任的规程和方法,RUP概览,需求规程的工作流详述,需求规程的目标,需求规程的目的:与客户和其他项目涉众就应

13、用系统应该有什么取得一致意见，并维护这种一致性帮助系统开发人员更好的了解系统需求定义系统的边界为规划迭代的技术内容提供基础定义系统的用户界面，主要关注用户的需要和目标要实现这些目标，首先要理解尝试使用该系统解决的问题的定义和范围，这一点很重要。确定项目涉众并引发、收集和分析涉众需求。然后将开发需求工作产品来描述系统（系统要做什么）以便将所有项目涉众（包括客户和潜在客户）视为除了系统需求以外的重要信息来源,角色和工件,需求管理涉及的主要工件,远景（Vision）问题定义涉众列表环境和平台补充规约非功能性需求Use Case 规约功能性需求术语（Glossary）公共术语涉众需要涉众的需要和请求,

14、我们在哪里？,分析问题的目标,开发之前对要解决的问题有一个更好的理解有的时候，解决一个特定的问题仅仅需要改变业务流程，而不是需要一个新系统。比如，建立管理生产流程，提供其他的变通方法。作为解决问题的人，我们有义务在建立新系统之前先去考察一些可能的替代解决方案,分析问题的步骤,识别涉众涉众指能被系统或项目的结果造成实际影响的人理解问题在问题定义上达成一致识别系统或项目的约束确定并验证解决根本问题的方案确定系统边界,远景文档,远景文档是从客户的角度撰写的，它关注系统的主要特性和可以接受的质量等级。远景应该描述将要包括的特性以及那些已考虑到但没有包括进来的特性。它还应该指定操作容量（卷、响应时间、精

15、确度）、用户概要文件（谁将使用系统）以及与系统边界外的实体之间的互操作界面（如果适用）。远景文档提供正在开发的软件系统的完整远景，并支持出资方与开发组之间的约定。每个项目都需要一个来源，以记录项目涉众的期望值。,远景文档提纲,简介定位涉众和用户描述产品概述产品特性约束质量范围优先顺序和优先级其他产品要求记录要求功能属性,识别约束,环境政策经济技术系统可行性,识别约束,Actor 帮助定义系统边界,可以简单认为，解决方案的世界分为两个部分我们要开发的系统与我们系统进行交互的事物这种交互的事物我们称为我们系统的参与者。可以通过以下问题来帮助寻找谁会对系统提供信息、使用信息、删除信息谁将操作系统谁是

16、维护者系统在哪儿被使用系统从哪儿得到信息哪些外部系统要和系统进行交互,捕捉公共词汇,定义项目中的术语帮助减少误解,我们在哪里？,需求的来源,PartnersCustomerUsersProblem Domain,可能遇到的问题,涉众对解决方案有先入为主的想法不知道自己真正想要什么不能正确描述自己想要的东西交付之前以为自己知道想要什么系统分析员以为自己比用户更了解问题每个人从各自的角度看待问题相信自己是正确的,涉众需要工件,属于涉众包括来自涉众的所有需要来源包括Email、客户需求说明、白板、电子表格可能包括对任何外部资源的引用项目组据此得到产品特性及软件需求,如何抽取涉众需求,查阅用户需求说明

17、需求讨论会Use Case讨论会头脑风暴用户访谈调查问卷角色扮演系统原型故事板,我们在哪里？,特性（Feature）,特性是外部可见的服务特性是为了完成涉众的一个或多个需要而提供的服务例子：问题跟踪系统的特性是能够提供趋势报告，以帮助项目经理评估项目状态ATM应允许客户之间转款,实例,特性1：个人用户和企业用户均可以通过internet注册特性2：系统提供岗位IT技能测评和按课程的单科评测特性3：系统能够以树状方式显示岗位列表技能列表特性4：企业能够根据自身需求设置岗位及对应的技能特性n：能够修改用户的支付信息，并能够为企业用户分配lisence数量,识别系统特性的建议步骤,写产品定位陈述使用

18、头脑风暴收集系统特性回购收集来的特性把这些特性与涉众需要进行关联，建立跟踪矩阵精化远景文档确定产品定位陈述列出关键特性,用例建模步骤,识别Actor和Use Case简要描述写每个Use case的提纲基本流可选流详述每个Use case详述时间流结构化用例加入详细信息，如前置/后置条件、特殊需求、关系、图等,我们在哪里？,定义系统范围,资源,预算,时间,范围,建立需求基线,需求基线一个特性的集合，建立在一致认同的基础上，只能通过正式程序进行变更基线必须至少对客户来说是可接受的在团队看来具有合理的成功可能性,设定特性优先级,对于规模管理非常重要在确定优先级的过程中，重要的是由客户和用户、产品经

19、理或其它代表而不是开发团对自己做决定并建立优先级实际上，这个早期的优先级确定过程不应该受到技术部门的过多影响；否则，技术难度将影响客户的优先级决定,评估工作量,为提出的基线中的每个特性粗略确定工作量为了不在后来被认为是“浪费资源”的事物上投入资源，包括不能实现的特性的需求说明、设计和以后的测试脚本。我们最大的目标是在项目的初始版本就减少开发特性的数量，由于资源有限，我们不能在当前的基线下对不可能实现的特性作投入,设定Use case优先级,考虑与基线中特性相关联的Use case选择具有如下特点的场景代表有意义的、重要的功能与实际的系统元素或接口相关联代表系统中明确的、精细部分被标记为高风险为

20、今后的迭代设定优先级,我们在哪里？,设计约束,设计约束代表已经批准并必须遵循的设计决定。其中包括软件语言、软件流程需求、开发工具的指定用途、架构及设计约束、购买的构件、类库等。设计约束是对系统的设计或开发的限制，他不影响系统的外部行为，但必须被完成以满足技术、商业或合同的义务被开发的系统基础设施中，通常包括：操作系统、与已有系统的兼容性、应用标准开发所使用的规章和标准的实体。例如：ISO 9000标准,如何描述功能性需求,使用Use case和说明文档为了理解系统的复杂性，两者都很重要,如何处理不在Use case中的需求？,使用说明文档描述软件需求使用关键字帮助说明，如“应该”为每个需求编号

21、并命名相关需求进行分组使用团队容易理解的语言主语+动词精确完整使用1到3个句子描述需求使需求完整使用来自词汇表的术语,用例模板,Brief DescriptionFlow of EventsBasic Flow of EventsAlternative Flow of EventsSpecial RequirementsPreconditionsPostconditionsExtension PointsRelationshipsUse-case DiagramsOther Diagrams/Enclosure,使用户界面远离Use case,文本不适合描述可视化元素Use case不适合UI

22、在分析设计中用用户体验模型或系统原型描述UI,我们在哪里？,需求为什么会变更,人民对问题的理解程度在提高待解决的问题本身在变化没有在合适的时间问合适的人合适的问题没有创建合适的流程来管理变更用户改变了注意或有了新的领悟外部环境变化,控制需求的处理过程,Reqt,Design,Code,Test,Maint,New Feature,New Requirement,BUG,Change Request,客户和用户,市场,程序员测试员,服务台用户,变更控制组CCB,唯一的批准渠道,需求跟踪,保证质量验证所有的需求已被实现验证应用仅实现了目标需求分析变更的影响定位相关需求检查相关需求,需求中的变更管理,组织未授权的变更保留需求文档的修订版取得早期版本支持受控的基线发布策略阻止文档的同时更新,谢谢,