]]>
业务建模QBusiness ModelingQ是一U徏模方法的集合Q目的是对业务进行徏模。这斚w的工作可能包括了?a target="_new">业务程建模Q对业务l织建模Q改q业务流E，领域建模{方面?/font>
一、ؓ什么要业务建模
Brooks 大师_三十多年来各式各L应用pȝQApplication Programs APQ历l多ơ的修修ҎQ已l变得面目全非，如同一的怪兽Q难以驯服?/font>
Rogerson大师也说QThe application is a rock in the river of change.Q应用（pȝQ成为改变之潮流中的石Q?/font>
对很多企业而言Q有一个统合企业各部门的信息系l的心愿g已经成了一U奢望。企业中或多或少都会有一些应用系l在辅助企业的自动化q作Q当企业信息ȝ希望能够对目前的信息pȝq行整合Q能够配合企业的发展的时候，他们失望了。大多数的应用缺乏一个统一的接口，难以q行整合?/font>
在我们进行项目开发的银行中，我们也同样发Cq个问题Q不同部门的pȝ之间无法q行互联Q跨部门的业务流E必ȝq手工的处理?/font>
以前Q应?a target="_new">E序的开发都是基于部门的功能的而徏的。单U只是ؓ了解决目的而徏立应用系l。所以这U方式徏立的应用pȝ是针对特定的功能区域QFunction AreaQ而徏立的。至于如何企业内的多个应用pȝ共同q作Q就不在设计者的考虑之列了。随着企业的发展，׃发现企业需要变化以适应市场变化Q业务发展的时候，原有的一pd应用pȝ却成了企业发展的拦\虎，q得企业不得不回到手工的时代?/font>
针对q种情况Q有没有相应的解决之道呢Q解决的Ҏ是从业务徏模入手，而不是从较低层次Q部门或以下）入手。通过用例分析技术，建立企业的业务模型，q行适当的切Ԍ选取E_?a target="_new">软g架构Q分析出企业?a target="_new">业务实体Q?a target="_new">Business Entity 企业中微不可分的事物，抽象或具体的Q如帐户Q契U等Q又被称?a target="_new">Business ObjectQ，以此为基Q组装出lgQ?a target="_new">ComponentQ，落实到相应的三层l构Q徏立针对特定功能区域的应用pȝ?/font>
以这L程做出来的企业应用pȝQ不模是部门U的Q还是企业的，都有扩展的余地。以lg为基的Y件三层构Ӟ也能够较好的配合企业的业务变化而变化（相应变化的代仯）。而整个流E的W一步，是业务建模?/font>
在前一D|_中国很流行企业流E再?a target="_new">BPR(Business Process Re-engineering)q个名词。BPRq一名词中的R(Re-engineering)一词是由Dr. Hammer提出Q说明企业必L动四个层面的重新设计QRe-position、Re-organization、Re-system、Re-vitalizing之再造工E；名称中的P(Process)Q更是管理上由销售、采购到财务、生产各层次Q力求降低成本、提高出，所必须_֯设计的企业管理流E或E序。这个词目前都是和ERP串联在一P成了ERP的前|工E，更成Z证ERP能徏立企业完管理体p，以支持高l效的最重要因素。实际上呢，q个BPR是我们所谈到的业务徏模?/font>
可以看出Q业务徏模在ERP工程中被着重强调，而且ERP中的BPR已经成ؓ一门独立的学科。不仅如此，即便是在普通的信息pȝ中，业务建模也是非常重要的，所不同的，仅仅是它们的规模而已。这一点上Q可能大家会不理解，如果你只是ؓ企业的业务自动化建立应用Q直接照搬企?a target="_new">模式不就行了吗。这里有两点原因Q一是企业原有的业务模式在以Zؓȝ环境中可能运行的很好Q可是把q套模式原本不动的搬?a target="_new">计算?/a>上就未必会适合了。h的能力和计算机的能力有很大的出入Q所以流E必ȝq调整以适应计算机；W二个原因是上面已经提到q的避免产生部门U的Q部分功能区域的应用pȝ?/font>
?a target="_new">RUP中，业务建模被作Z游流E的输入重点Q业务模型是需?/a>工作?/a>E的一U重要输入，用来了解对系l的需求。业务实体是分析设计工作程的一U输入，用来定设计模型中的实体c?/a>。（RUPQ?/font>
二、业务徏模的目的
了解目标l织Q将要在其中部vpȝ的组l）的结构及机制?
了解目标l织中当前存在的问题q确定改q的可能性。?
保客户、最l用户和开发h员就目标l织达成p?
导出支持目标l织所需的系l需求?
为实现这些目标，业务建模工作程说明了如何拟定新目标l织的前景，q基于该前景来确定该l织?a target="_new">业务用例模型?a target="_new">业务对象模型中的程、角色以及职责?/font>
作ؓ对这些模型的补充Q还开发了以下工gQ?
补充业务规约
词汇?
与其他工作流E的关系
业务建模工作程与其他工作流E的关系如下Q?
业务模型是需求工作流E的一U重要输入，用来了解对系l的需求?
业务实体是分析设计工作流E的一U输入，用来定设计模型中的实体cR?
环境工作程开发ƈl护支持工gQ例如“业务徏模指南”?
三、业务徏模的规模
Ҏ环境和需求的不同Q业务徏模工作可能有不同的规模。以下列Z六种q样的场景?
场景 #1 - l织?/font>
您可能需要构建组l及其流E的图，以便更好C解对正在构徏的应用程序的需求。在q种情况下，业务建模成?a target="_new">软g工程目中的一部分Q它主要是在先启阶段执行的。通常Q这些工作在开始时仅仅是画出组l图Q其目的q不是对l织q行变更。但实际上，构徏和部|新的应用程序时往往会进行一定程度的业务改进?/font>
场景 #2 - 领域建模
如果您构建应用程序时的主要目的是理和提供信息（例如Q订单管理系l或银行pȝQ，那么您可能选择在业务别上构徏该信息的模型Q而不考虑该业务的工作程。这q为领域徏模。请参见工作程明细Q开?a target="_new">领域模型。通常Q领域徏模是软g工程目的一部分Q它是在目的先启阶D和_阶段中执行的?
场景 #3 - 单业务多pȝ
如果您正在构Z个大的系l（即一pd的应用程序）Q那么一个业务徏模工作可能成为数个Y件工E项目的输入。业务模型帮助您扑և功能性需求，q且也作为构建应用程序系列构架的输入。详情请参见概念Q从业务模型到系l。在q种情况下，通常业务徏模工作本w当做一个项目?
场景 #4 - 通用业务模型
如果您正在构Z个供多个l织使用的应用程序（例如Q销售支持应用程序或l̎应用E序Q。一U有效的做法是：从头到尾q行一ơ业务徏模工作，从而按q些l织的经营方式对它们q行调整Q避免一些对于系l来说过于复杂的需求（业务改进Q。但如果无法对组l进行调_那么业务建模工作能够帮助您了解ƈ理q些l织使用该应用程序时存在的差别，q您更Ҏ定应用E序功能的优先?
场景 #5 - C?/font>
如果某个l织军_要启动一全新的业务Q业务创建）Qƈ构Z息系l来支持该业务，那么需要进行业务徏模工作。在q种情况下，业务建模的目的就不仅仅是要找出对pȝ的需求，而且q要定C务是否可行。在q种情况下，通常业务徏模工作本w当做一个项目?
场景 #6 - 修改
如果某个l织军_要对其经营方式进行彻底修改（业务重徏Q，那么业务建模通常本n是一个或多个目。通常Q业务重建分C阶段完成Q新业务展望、对现有业务实施逆向工程、对C务实施正向工E以及启动新业务?/font>
四、业务徏模时期的主要d
目涉众的共同愿景：要想目成功Q可M开目涉众的支持。在目一开始，不论是项目涉众还是开发h员，寚w目的d、范围都是模p不清的。但随着目的深入，原来模糊的景象会慢慢清晰、立体v来。但是ؓ了不费旉Q我们有必要在项目射入之前，现在目涉众中竖立一个共同的愿景?/font>
共同愿景的竖立可没有惌中的那么单，因ؓ每位涉众都关心自q利益Q都有自q评判标准。你可以把大家的意见都列在白板上Q然后逐项集中讨论Q做Z正，直到大家的意见一致的时候ؓ止。在共同q景的竖立过E中Q其实有两g事情也已l同时做了，目范围QscopeQ和高阶Qhigh-levelQ需求?/font>
目范围Q项目该做什么，不该做什么，需要在一开始就有明的定义。对于项目范围内的需求，一个也不要放过Q而项目之外的Q一个也不要d心。虽然有的时候，范围的变化会有利于项目本w，例如客户的合理要求或是市场目标客L变化Q但是这U变化应该要?资源能够支持"?得到审批"的前提下q行?/font>
目范围的描q可以通过陈述和图C来q行。我大家使用囄。因为陈q语句比较含p不清。例如常常听到有客户说?我要建立我公司的电子商务pȝ?q句话就是含p不清的Q你的电子商务系l是销售什么品？面向什么客P是否要支持在U支付？Ҏq些疑问Q这个陈q句可以做进一步的修改Q?建立在线订货pȝQ针对当前的目标客户销售公司的目前产品?q样清楚许多了。不q图C的Ҏ会更好一些，在图的选择上，你可以用DFD图或?a target="_new">用例?/a>。根据经验，DFD图比较容易ؓ客户所接受?/font>
高阶需求：q个部分我们在下面会详细讨论。既然是高阶需求，׃能讨多的l节。在讨论高阶需求的时候，量保证快速的讨论出系l的概貌Q徏立需求模型，得到目涉众的一致通过?/font>
取得支持Qؓ了保证需求计划的利q行Q取得项目涉众的支持臛_重要。你可以选择在这个时候告诉项目涉众他们的权利和义务，以及开发h员的权利和义务。在q个斚wQ具体的我不惛__大家可以参考?a target="_new">软g需?/a>』的W二章。主要的是"涉众有改变需求的权利Q同时要承担向开发h员讲解需求的义务?开发h员的权利和义务正好和涉众相反?/font>
业务建模会议Q所有的q一切都通过业务建模会议q行Q和其它会议不同的是Q这个会议需要所有的目涉众参加Q如果不能获取所有项目涉众的意见Q那׃是完的。会议中最重要的工具就是白板，一位出色的速记员也是必ȝ?/font>
五、需求和业务建模
业务建模?a target="_new">需求工E?/a>中最初始的阶D，也是整个目的初始阶Dc需要指出的是，业务建模旉的跨度在不同的项目中有很大的差别的。在有些目中，例如大型ERPpȝQ可能需要几个月的时间。而对于普通的目Q业务徏模的旉可能仅仅需要几天的旉?/font>
需求是技术无养Itechnology independentQ的。在需求阶D讨论技术是没有M意义的。那只会让你的注意力分散。技术的实现l节是在后面的分析、设计阶D|需要考虑的事情。而在业务建模阶段Q不但要保证需求的技术无x，q要保证你的需求不要深入细节。因为在业务建模阶段Q最重要的事情就是要了解业务的全貌，深入l节会浪Ҏ间和_֊。要知道Q讨Z个企业里的业务细节，ql你一个月的时间也没必能够l束?/font>
在实际中Q这两点都是很难做到的。例如企业原先有一个系l，q就不得不由你讨论和新旧pȝ的兼定w题。这时候就要注意，如果你是讨论有pȝ?a target="_new">架构的话Q那q是属于技术无关的范畴Q如果你一旦进而讨论各具体模块/lg的细节，那就非但不是技术无养I而且也深入细节了。在不深入细节的问题上，往往你很隄止项目涉众（StakeholderQ①不去讨论一些相关的业务l节。这个时候你可以这些细节记录下来，然后再回C务徏模上?/font>
①A stakeholder is defined as anyone who is materially affected by the outcome of the project.
涉众是所有会受到目l果重大影响的h?/font>
摘自《IBM DeveloperWorks?/font>
六、业务徏模中的用?/strong>
在上一中我们讨论了很多用例的知识Q可是落实到企业中的时候，我们往往会感觉难以把握企业的用例Q这一Ҏ们在用例的误Z也有提到。在实际的情况中Q你可能会对角色的归c，用例的划分，_度的把握等很细节的斚w都没有底Q偏偏这些实际的东西对你的项目有非常大的影响?
RUP中，有多U的概念来支持用例的实现Q?a target="_new">业务主角Q?a target="_new">Business ActorQ、业务实体（Business EntityQ?a target="_new">业务用例Q?a target="_new">Business Use CaseQ?a target="_new">业务角色Q?a target="_new">Business WorkerQ、业务用例实例（Business Use-Case InstanceQ。ؓ了能够比较清楚的展示Z务徏模，我们采用了UPҎ的代表――RUP。但在实际中Q要视大家具体的情况而定Q这里所讲到的概念，都是Z帮助大家理解建模q程Qƈ不是让大家生搬硬套?
在我们对pȝq丝毫不了解的时候，我们׃把系l看成一个很大很大的黑盒Q这个大黑盒子我们会叫他业务域（Business DomainQ，把它的外部看成一个业务环境（business environmentQ。而那些在业务环境中和业务域有关系的hQ也可能是物Q就被称Z务主角（Business ActorQ。在实际的例子中Q我们可能会把信贷业务（注意不是信贷业务pȝQ这里是业务建模Q系l还不存在。）UCؓ业务域，我们l过调查Q发现^时和信贷业务打交道的有客P人民银行Q外汇管理局Q其他银行，信贷部门使用的其他系l，银行内部的其他部门。所以这些hQ物Q就是业务主角。业务主角的实例一般包括了客户、供应商、合作伙伴、潜在客P"市场"Q、当地政府、在业务中未建模部分工作的同事等。必L意的是，业务主角表示的特?a target="_new">cd的用P而不是某一个具体的用户。一个角色可能会有很多实际用h任，一个实际的用户也可能会担Q很多的角艌Ӏ?
业务用例以及业务用例实例在RUP中的定义如下Q?
A business use-case instance is a sequence of actions performed in a business that produces a result of observable value to an individual actor of the business. A business use case defines a set of business use-case instances. A business use case has a name.
业务用例实例是在业务中执行的一pd动作Q这些动作ؓ业务的个体主角生具有可见h值的l果。业务用例定义了一l业务用例实例。业务用例具有名U?
刚开始大家可能会对业务用例以及业务用例实例有所疑问。其实可以把他们看成基类和子cȝ关系。在一个企业中Q具体的工作程可能有很多很多，比如你去麦当劳的时候，Ҏ堡和点薯条的工作程׃一栗众多的程l需求的调查工作造成了一定的隑ֺ。即使是最古老的哲学也告诉我们，表面现象是复杂的Q本质是单的。ؓ了简化需求工作，我们把Ҏ堡和点薯条归Uؓ炚w。这P炚w是一个业务用例，而点汉堡、点薯条是相对应的业务用例实例?
业务用例
业务角色和业务主角的概念也很Ҏ让h怸着头脑。其实看它们的英文愿意会更容易理解它们的区别QBusiness WorkerQBusiness Actor。Worker有工人的意思，而Actor有参与者的意思。所以它们的区别是一个在内部Q一个在外部。业务角色是实现业务用例的hQ业务主角是和业务有关的人。例如，寚w行的押汇业务而言Q客户就是业务主角，他和业务有关。而押汇h员就是业务角Ԍ因ؓ他们是实C务用例的人。在RUP中，二者定义如下：
A business worker represents a role or set of roles in the business. A business worker interacts with other workers and manipulates business entities while participating in business use-case realizations.
业务角色代表业务中的一个或一l角艌Ӏ参?a target="_new">业务用例实现Ӟ一个业务角色和其他角色q行交互Qƈ操纵业务实体
A business actor represents a role played in relation to the business by someone or something in the business environment.
业务主角代表了与业务有关的角Ԍ此角色由业务环境中的某个人或物来担Q?
业务角色
业务主角
分L业务角色和业务主角要看环境而定。当你开发企业的ERPpȝӞ部门的员工都属于业务角色Q而你开发一个部门的应用时Q其他部门的员工可能属于业务主角?
业务实体Q在一些文章中被称为商业对象（Business ObjectQ。不论怎么叫，所表示的意义都是一L。例如在银行信贷q个例子中，我们涉及到很多业务实体Q契U、单W贷ƾ、客L。所以业务实体就是企业中那些很基本的要素。如果觉得银行押汇的例子不好理解。可以想象餐厅中的菜单、汉堡等都是业务实体。在RUP中，业务实体被定义ؓQ?
A business entity represents a "thing" handled or used by business workers.
业务实体代表业务角色处理或用的"事物"?
业务实体
在很早以前，我们讨论q需求易变性。相对于需求的不断变化Q可是业务实体对象在一D늛当长的时间内都存在。航I公总天打折，明天又不打，q有明折、暗折。可是机从来没见有什么大的变化，从来也只有那几样属性：h、航班、出发地、目的地。所以业务实体是比较E_的。这对于我们是有很大的意义的Q?
"一个业务实体经总表某个对多个业务用例或用例实例有价值的事物Q因此，业务实体对象的生存期相当ѝ一般而言Q一个好的业务实体不包含关于其用主体和使用Ҏ的信息?QRUPQ?
׃务实体组成的业务用例会稳定很多。在以前Q开发方式采用模块ؓ基础的方法，需求变化的时候，只好改写模块。如果采用稳定的业务实体来实C务用例的话，业务用例的改变只需要对业务实体q行重新的组合。当Ӟq里q需要很多的技术来实现Qƈ没有那么单。要知道Q四个现代化可不是一天就能够实现的?
q有一个用业务实体的重要原因Q业务实体的Ҏ决定它h天生的重用性。就像麦当劳的销售系l中有汉堡实体，生pȝ中也有，供应铄l中也有。天哪，q世界真是美好！
使用业务实体一个很大的困惑是应该把它做为类q是属性。这个取决于业务环境对这个实体的重视E度。一个客户在银行信贷部门是一个很重要的类Q而在押汇部门只是信用证实例的一个属性。这个问题非常的重要。设计时的失误可能会D今后pȝ改进的极大痛苦。例如本该设计ؓcȝ业务实体设计成了属性，在今后增加属性的时候不得不面对着数据?/a>的调整和pȝ的修攏V?
6. 建立业务用例模型
业务用例模型Qbusiness use-case modelQ，在RUP中定义ؓQ?
The business use-case model is a model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.
业务用例模型是说明业务预期功能的模型。作Z个核心输入模型，业务用例模型用于定l织的各个角色和可交付工件?
从业务用例模型的定义可以看出Q它是企业最核心Q最概括的业务说明。它主要是由业务用例和业务主角构成的Q其主要目的是说明客户和合作伙伴是如何开展业务的Q它描述业务的主要方式是通过业务用例的方式。下图ؓRUP中业务用例模型的囄?
业务用例模型
从图中我们也可以很清楚的看出业务用例模型包括一l的业务用例。这是因Z业中的业务通常都会由多个的业务用例的多个实例构成。这些业务用例Ş成的企业工作程可能会由业务主角所引发Q也可能会由业务规则②所引发?
②业务规则（Business RulesQ：业务规则是必遵守的政策或条件的声明。（Business Rules are declarations of policy or conditions that must be satisfied.Q?
业务用例模型实际上就是企业经营业务的一U描qͼZ建立完整、准的企业用例模型Q应该将注意力专注于企业的业务做了些什么事情，而不应该集中于如何做。虽然这样可能会产生一些业务用例相冲突Q相重复的情况，但是RUP的思想在于q代Q这工作完全可以在接下ȝq代周期内完善?
业务用例模型是和企业业务最贴近的计机模型。它的很多思想和企业日常经营如Z辙。在企业的日常活动中Q业务的U类可能有很多种。在一些讲qERP思想的文章中Q通常会强调三c：
一U是和主营业务密切相关的工作Q例如银行的营业部、信贷部、押汇部{。这U工作通过人的力_Q将一U资源{变ؓ另一U资源，产生价倹{?
一U是理型的工作Q例如公司的理层，财务部门{。这U工作本wƈ不生h|但是它通过指导、管理、检第一U工作，加大W一U工作的产出价倹{?
q有一U称为支持工作，例如pȝ理、安全等。它q不是很重要Q具有支持其他工作的性质?
业务模型同样可以使用q种分类。通过q种分类Q可以更好的把握核心业务用例Qؓ下一步的工作打好基础?
有很多业务用例是׃务主角触发的QRUP中也把和业务主角有关联关pȝ业务用例UCؓ核心业务用例QCore Business Use CaseQ。这了构Z务模型的目的是ؓ了提供以用户Z心的服务。这也是我们建立业务用例的时候应该注意的?
当然Q有时候业务用例的触发是ؓ了生用户需要的l果。例如企业的市场调查行ؓ׃是由业务主角触发Q而是企业U篏了大量用戯求的l果。而对于管理型、支持型的，不直接和业务主角的客L发生联系Q但是也有其特定的业务主角，如管理型的业务用例需要和董事会ؓ发生联系Q支持型的业务用例可能和供应商发生联pR?
在徏立了基本的业务用例模型之后，Ҏ模型q行_是非常有必要的，q时候，在上一章中我们介绍的用例的扩展关系和用关pd有了用武之地。除了这两种关系Q还有一U新的关pR?
7. 在业务徏模中使用关系
泛化关系QGeneralizationQ：Ҏ我的理解Q可以把它看作我们比较熟悉的l承关系很相似的一U关pRGeneralization一词含有一般化、概括的意思。它是一个相Ҏ象的词。虽然它和承关p非常相|但是它们在用环境和产生目的斚w都有相异之处。下图描qC四个业务实体之间的泛化关p：
当你去麦当劳的时候（不要误会Q我q不是很l常ȝQ，会选择麦香鸡汉堡、麦香鱼汉堡或是吉士汉堡。但是分别对q三U汉堡徏立业务实体就非常没有意义。所以可以将它们概括为汉堡这个业务实体。同L道理Q企业的业务程中也可以概括Z些共有的属性和行ؓ。ؓ了避免多ơ说明同一个工作流E，您可以将共有的行为放在一个单独的业务用例中。称为父用例Q执行子用例的用例实例将遵@父用例的事g，同时插入附加行ؓ或修改在子用例事件流中定义的行ؓ?
8. Ҏ的选择
以上的原理我采用了UP的方法。但是除了UPҎQ还?a target="_new">XP?a target="_new">FDD{方法。所以在做业务徏模的时候，也要Ҏ不同的方法选择适当的工件。例如素材和功能。方法的好坏q不是我们这片文章讨论的重点Q我会在另一文章中讨论Ҏ。再一ơ需要强调的是，上面讨论的RUP的工件只是ؓ了学习，所以才定义了比较复杂的工gQ区分了它们之间的区别。但是在实际中，q不需要这么多的工Ӟ那只会你的目涉众和开发h员糊涂。这些工件的区别只要在你心中可以了?br />
六、业务徏模的原则QPrincipleQ?/strong>
1. 谁才?上帝"
我们说客h上帝Q是因ؓ客户的重要性，客户占有军_性的C。可是在软g开?/a>中，到底是谁有决定权呢？是出资方Q还是项目经历，或是E序员？
职责不清Q是业务建模p|的主要原因之一。我们可以很Ҏ的看见客h自己的要求用几句话高度浓~之后扔l开发h员，或是开发h员按照自q意思开发程序。难道说Q客户和开发h员之间真的是"心有늊"Q完全不用沟通的吗?
我在前文中已l提到过目涉众和开发h员的权利和义务，我想q里q有必要再次。Scott W. Ambler_
it is the role of project stakeholders to provide requirements, it is the role of developers to understand and implement them.
在我一ơ开发过E中Q遇到过一个很有意思的涉众Q他在他?a target="_new">需求分?/a>中这样写Q?MQ要实现那种能够惛_p做到功能?我想Q这位涉众对我们的计机工业有着非常q大的抱负。但我不得不客气的告诉他目前实现是不太现实的?
大家听了可能会觉得好W，但是在我自己和客h交道的生涯中Q这U客户不在少数。现实就是这P你要怎么做？是一W之后，弃之不顾吗？我想大多Ch会这样做。因Z的要求太荒唐了嘛。可是，你有没有花时间去了解一下，他这句荒唐的话背后代表了他的什么意思呢Q我觉得QY件开发h员负有教育涉众的义务Q你需要引g的涉众，让他们说q心声。我在看到这位涉众的q句话后Q就׃一些时间去了解Q其实呢Q事情很单，他就是想要一个能够定制报表模板的功能。而在目l束后，我和q位涉众有幸再一ơ的合作Q这时候，他已l成Z一个出色的客户方的目领导者了?
q个例子说明了什么呢Q涉众往往都是领域专家Q对自己的工作有很深的认识，可是׃对Y件开发的不了解，涉众往往表达不清Q甚臌达不q需求。这时候，是体现你的功力的时候了。记住，象对待上帝一样对待你的客戗?
2. 耐心是首要的
明白了谁?上帝"Q那p耐心的对待上帝。学理工U的人，一般在逻辑思维上会比较好，可是对于涉众来说Q可不一定是q样。我遇到过一位做档案工作的涉众，在了解需求的时候，扯东扯西Q含p不清。明明一分钟前才否定的方法，下一分钟又提出来了。我觉得我的脾气应该是不错的Q可到最后也几乎发飚。所q，最后我l于撑了下来。我惻I在经历过qg事情之后Q我的耐心指数又会有一个很大的提高了吧?
我有一位同事的耐性是我所佩服的，在一个网站项目中Q他负责pȝ分析。他整整׃三天的时_和网站项目的负责Z在一赗最后系l分析出来之后，他的_q不错，可是那位负责人已l快不行了?
当然Q这只是个笑话，q不是去鼓励大家拼命。劳逸结合还是很重要的，w体是革命的本钱嘛。但是这告诉我们Q如果缺耐心Q需求是很难成功的。例如在业务建模的讨Z上，你虽然规定了q次的会议讨论的是高阉求，可是与会者M时不时的争辩一些芝ȝ豆的事ѝ你怎么办？我相信这U情冉|很普遍的?
耐心最后会仍会体现为沟通，只有耐心的沟通，你才能揭开需求的重重面纱。h的行为L会受到思想的指|如果你解不开涉众的心l，你就不可能了解他真正需要的?
我的一位项目涉众的表现很奇怪，ҎL在不停的说一件事情："她要实现报表自动生成?她的需求讲来讲d像总脱不出q个范围Q可是我从她那里几乎听不到别的东西了。这时候，我决定放弃了Q我想从她哪里可能已l没有更多的资料了。但在我了解到她的工作中报表处理占用了她大量的时间之后，我改变了x。在我花了一些时间帮她理清了报表处理的思\之后Q她q在其他斚wl了我很大的帮助?
3. 参与是重要的
XPҎ的一个重要实践，是提?现场客户"Qon-site customerQ。也是_客户应该随时和开发h员在一P随时提供资料和做出决{。而这个客P也必领域专Ӟ而且能够有权做出决策?
q种现场客户怿国内的Y件组l多半还做不到。但是一定要往q方面努力。我认ؓQ这U现场客h两种人：一U是目涉众Q还有一U是行业专家。其实很多Y件公叔R会配备一些管理咨询h员，q些人就是行业专家。有数据l计_目前q东省Y件公怸的咨询h员和开发h员的比例辑ֈ?Q?。我觉得q是好事。项目涉众往往对自q工作中的事务性部分有很深的认识，但是很难之提升C个理论的水^。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨，q能够激发项目涉众的灉|Q想到原来他想不到的斚w。这是"潜在需?的开发?
另一斚wQ参与还意味着需要项目涉众全w心的投入到业务建模的过E中来，要能够调动他们的U极性。因此呢Q太复杂的流E会ȝ涉众的参与。所以，使用一些简单的、能够ؓ客户所接受的工ӞArtifactQ来q行业务建模是很有必要的。我说过前面讨论的那?主角"啊，"用例"啊，那是理论Q是l开发h员看的，让开发h员心里有个底。你l涉众看q些Q他们能懂吗Q等他们了解了这套机Ӟ恐怕黄p都凉了吧?
素材QUser StoryQ、特性（FeatureQ、CRC卡片q些都是很不错的工gQ既单，又能够满需要?
知识点：素材和特性都表述了用L一个简单的要求Q它能够在较短的旉内完成。素材是XPҎ中的工gQ特性是FDDҎ中的工g。CRC?a target="_new">class?responsibility、collaborator的羃写，它是一张分Z个部分的卡片Q分别标CcdQ类的责任，以及cM间的合作关系。非常的贴近客户Q甚臛_以在做游戏的q程中完成卡片的填写Q能带来很强的客户参与度?
4. 拥抱变化
我想q一点会遭到开发h员点一致指责。毕竟，需求变化是开发h员最讨厌的一件事了。不错，我也讨厌。可是，像我们常说"哭不能解决问?一P讨厌能解决问题吗Q拒l客L变更要求Q要求客户在需求规D明书上签字。这些做法只能是适得其反。没有Q何正面的、积极的意义?
必要的需求变更管理是重要的。因为无休止、无控制的变化必然会造成资源的极大浪贏V但从另一斚w_需求变更被接受的评判标准应该是"是否合理"Q而不?是否易于实现"?
需求变更要求我们的开发工作要q代式进行，包括需求、设计、实现等阶段。这h能将变更风险减到最。这一Ҏ们在讨论具体需求徏模的时候会q一步讨论?
拥抱变化的更高一个层ơ是提前预估变化。制定一个可能的变化清单来记录可能出现的变化。最单的例子是一个企业在开发了q销存系l之后又希望能够开发胦会系l与之相q。如果你能够预先留下伏笔Q相信能够省不少力气。预估变化的另一U做法是通过使用模式。但是切讎ͼ模式的用也不能q头。这些是题外话，如果有机会我会在其他的文章中集中讨论q方面的问题?
七、业务徏模的实践QPracticeQ?/strong>
5. 建模会议
会议是业务徏模最重要的手Dc尽会议在中国L背负着一些骂名，但是只要l织得好Q它是一U相当有效的沟通（CommunicationQ手Dc徏模会议是一U大范围的会议，换句话说Q所有的相关人员都应该参加会议。因为在业务建模时期Q主要的目的是建立对系l的高阶需求，q就要求众多目涉众的共同参与，以保证需求的q泛性。所以呢Q徏模会议的规模是相当大的。出资方、高U经理、经理、直接用戗开发h员，各方各面的h都应该参加或是派代表参加建模会议?
如果大家有过参加大型会议的经验都知道Q越是大型的会议Q它的决{效率就低。这是正常的。因Z个h的时候，不需要沟通，决策效率最高。等C个h的时候，他们需要沟通的旉来进行决{。等C个h的时候，q个沟通ƈ达成一致的旉更ѝ如果h数到了四个h、五个h甚至一二十个hQ那么大部分的时间都会花在沟通上。更何况Qh和h之间q有观念不同、利益之争。所以呢Qؓ了保证会议的效率和效果，应该遵@一定的规则Q?
·做好准备Q如果你要开会，与会者连内容都不清楚Q那你会怎么办。你必须首先花很多的旉来说明你开会的目的Q是不是。要事先会议的主题、议E连同会议通知发送给与会者，让他们先有个准备Q会议开始时p够迅速进入正题?
·量邀h多的人：我已l说q，如果建模会议不能够听取最q泛的意见，它就不是一个成功的会议。可是在现实中，q点往往难以做到。因为目标组l做为客P往往都很"?Q在没有充分认识会议的重要性之前，要做到全部到场简直就是不可能。而客观上也会有出差、休假、有要事{原因做不到q一炏V这里，一斚w你需要向目标l织的决{者阐明利宻I让他们重视。另一斚wQ你也需要积极主动的邀请项目涉众参与。因为邀h有的人是不可能的Q所以就可能的多吧?
·分出与会者的U别Q我很喜Ƣ那U有一个内圈、一个外圈的会议室。因为我邀h有h是g无法做到的事情，所以我首先要保证核心h员能够全部到场，坐在内圈Q然后才是次要的人员Q坐在外圈。核心h员是和你的项目息息相关的那种人。比如，财务pȝQ胦务主就是核心h员。要保证核心人员全员到场Q至于次要h员，全好?
·从底层开始：中国人有个比较不好的习惯Q就是老板说一的时候，他决不会说二。所以要先让底层先说话，然后才轮C层，再到上层。开发h员是不说话的Q他们要么听Q要么引导大家说话。如果我们一开始就先让领导来训话一番，那底层的Z׃用再说什么了?
·列D所有涉众的所有观点：首先要让大家能够Ҏ的系l畅所Ʋ言Q然后把所有的观点都罗列在白板上。这里头可能会有一些观点会是非常荒唐的Q但没有关系Q尽写上去。这是一个脑力激荡的q程Q很Ҏ产生出新的idea。主持的开发h员的主要工作是引导和鼓励大家说出更多的xQƈ记录下来。这里我们稍微离题一下，有h说中国h在会议上大都不愿意发表意见，我看在这U徏模会议上不必q于担心此事。ؓ什么呢Q因为项目涉众不需要ؓ他们的发a担Q何的责QQ说了，白说Q白说谁不说?
·观点分c：惛_你的目涉众已经有些累了Q创意也差不多了Q你的白板估计也满了。但是你看看白板上的观点Q有很多是重复的Q有很多是类似的。所以你需要用逻辑的观念将q些观点归类整理。这个工作也可以׃引导大家d?
·定优先U：对观ҎZ先也是非常重要的，它能够帮助你识别出重大的风险QƈZ在制定P代计划时提供指导。同Pq项工作也应该由目涉众来确定?
·调查主要业务逻辑Q什么叫主要业务逻辑Q包括了企业的主要业务流E、主要的业务规则、重大的法。这些都是需要在一开始就十分明确的资料，需要在建模会议上了解清楚。当Ӟ你不能对你的目涉众_"q个Q接下来Q大家谈一谈主要的业务逻辑吧?下面的涉众一定摸不着头脑。你q是应该引导涉众Q从涉众的话语中捕捉你需要的信息?
·注意会议旉Qh不是机器Q是会篏的。所以控制好会议的长度很关键。一般，q种会议会有四五个小ӞҎl计Q两个小时内的会议不会让Z生疲x。所以应该把会议分成几小Dc另外，你还可以Ҏ会议的进展来军_每小D会议参与的人数。因为，会议往后，一些与会者就不太重要了?
·避免l节Q徏模会议主要的目标是徏立高阉求。如果把q多的时间花在讨论鸡毛蒜皮的事Q那׃费大家的时间。而在此时调查需求细节是没有很大的意义的。因Z对很多的事情都还不了解，需要进一步的深入。这时候的l节对你q没有太多的帮助?
·回避技术：我在一ơ徏模会议的时候，遇到一位负责技术的涉众Q他L不停的询问系l的技术架构，推销他的设计理念。得我不得不好几次重申Q?技术问题我们会单独找时间谈?我想Q那位技术h员应该是有比较好的理念，也很希望能够表现一把，q点无可厚非。但是这个时候还不是讨论技术的时候，需求尚未明，讨论技术实C是本末倒置么？
·做好记录Q俗话说Q好记性不如烂W头。所以在会议上做好记录是非常关键的。因U会议的代h相当高昂Q你的项目涉众不可能每天不干z，陪你开会的Q就他们肯Q他们的老板也不肯。所以要充分利用好会议的成果Q所以一个优U的速记员绝Ҏ必要的。另外，Ҏ研究昄Q如果用录x的话Q会使得与会者心存芥蒂而不愿开口，所以，不要使用录音机?
6. 试
在需求的初始阶段提到试可能会觉得有些奇怪。凡是项目，M有一个标准来考核是否成功。这里的试指的是考核软g目是否成功的一?执行性目??
q个目标会是Y件开发最l要满的条Ӟ软g成功与否的判定标准。很多企业在信息化徏讄时候没有一个比较明的目标。所以在被问道这斚w的问题时Q他的答案往往是我的目标是建成企业的ERPpȝQ徏设企业的信息化^台等I洞的话。这L软g怎么开发？q结束的标准都没有。是费用用完l束呢，q是决策者说停就停了呢。目标应该有一个可以量化的标准。例如，开发物系l的目的是ؓ了羃短品周转周期，降低库存Q开发供应链pȝ是ؓ了加强和供应商的联系Q降低库存。这些和具体业务有关的指标都是可以通过l化Q用多种分指标来度量的，所以是可以做到的?
我们把这U目标称为测试就是要提醒开发h员，要把满q种目标当作最l的试。你的Y件做得再好，不是涉众惌的，又有什么用Q这是很显的道理，可是在实际中Q涉众方和开发方往往因ؓ一些具体的因素看不到这一炏V其实，q个目标在上一中我们也讲q，那时我们是把它叫做愿景、范围。在本质上是一L?
q种"可执行性目?可以使用一些因素来衡量Q?
7. 业务实体
业务实体Qbusiness entityQ是企业中的一些v到关键作用的cd。客戗供应商、员工、订单、凭证，q种业务实体的例子可以D出很多很多。业务实体往往会成Z个很关键的因素，因ؓ在系l中Q角色操作业务实体的行ؓ往往会分配给业务实体Q例?Ҏ订单计算h"会成单的一个行为。这P工作程的实现往往是多个业务实体相互合作完成的。所以业务实体设计的好坏会对pȝ有很大的影响作用?
业务实体设计的主要工作包括找Z务实体，定业务实体的属性和行ؓ?
要确定业务实体，首先必须定角色Qƈ从角色的行ؓ扑և业务实体。角色需要我们对目标l织q行讨论。以我个人的l验Q寻找业务角色一般比较简单，但是要记住，一个h可能担Q好几个的业务角色Q这是经常发生的情况。从业务角色的行为，我们可以扑և业务角色所处理的事物，q些是我们所需要的业务实体。业务实体是一个单独的业务实体q是业务实体的一个属性是值得研究的。一个本该是属性的事物被判断成业务实体只是会带来一些开销Q可是一个本该单独列出的业务实体却只是被判定为其它业务实体的一个属性就有可能会带来N性的后果Q最大的可能是系l难以扩展?
在一个h力资源管理系l中Q员工类可能是非帔R要的一个业务实体，它可能有非常多的属性。而在其它的系l中Q例如进销存，员工cd是vC个记录、权限管理的作用|了。再比如Q在一些企业内部的自动化处理系l中Q客户可能只是其它一些实体的属性，而以客户Z心的设计大行光的现在，q种设计有它的致命~陷?
要确定业务实体的属性和行ؓQ主要是要确定每个类Q业务实体）要做的事情，属性则是ؓ了能够更好的描述cdc要做的事情。利用CRC卡片是一个不错的办法?
CRC?c?QclassQ，"责Q"QresponsibilityQ及"辅助?QcollaboratorQ三者的Uͼq些资料常呈现在一张卡片上?
cdU?
责Q1 责Q1的辅助?
责Q2 责Q2的辅助?
? ?
通过制作q样的CRC卡片Q可以比较容易的扑և每个业务实体的行为（责QQ和属性（辅助者）。您可能会问Qؓ什么不直接扑և属性和行ؓQ而要多此一丑֑。这个问题是我们一直在的。在建模阶段Q我们面对的是可能对计算机技术完全不懂的涉众Q所以，采用大家易于接受的方法，可以够保证需求的完整和正?
8. 准备计划
目前在Y件开发中Q关于计划有两个极端的误解?
在有些Y件组l中Q一般不做计划，或是做一些笼l的、没什么用处的计划。一些开发h员认为，"做计划是虚的Q还不如做些实际的事?对于目l理Q或是对q种情况没有办法Q或是发布的计划开发h员阳奉阴q，让计划成ZU空文。项目执行中随意性极大，偏离方向的事情时有发生?
而在另外一些组l中Q计划被视ؓ重中之重Q需要花费大量的旉、h力，做出来的计划可谓事无巨细Q算无遗{。而写的出q种计划的项目经理也被视为高Uh才。开发h员叹口气_"写程序的不如写文档的?可是在执行的时候，原来_֯的计划往往漏洞癑ևQ项目的q度一拖再拖?
我们所有h都知道那句明aQ在软g开发中Q要?0%的时间完?0%的项目，然后再用90%的时间完成剩下的10%的项目。ؓ什么呢Q计划不U学?
在管理学中，计划Q也有叫规划的，定义?为组l确定目标、实现目标的战略与手Dc步骤、程序的q程?打个比方_我想要把一个箱子推倒一个地方，q个地方是我的目的Q我Z到达那里Q我是不是要估计一下按什么\U推Q要推多快。然后我开始推Q还要不时的和原先的计划比较比较Q需不需要调整\U和速度。这个估计就是计划?
计划的目标不是消除错误，而是让所有错误变成一堆经q细心规划后的小错误。研I四U设计方式后Q最l放弃三U，最多不q是三个错误而已Q但因没有做好设计而将E序重写三遍Q却可能造成三个大错误?
然而ؓ什么会出现上面提到的两个极端呢Q第一U情况其实是软g行业最早期的一UŞ态，没有计划Q资源分配乱，软g的开发过E处于沌、无序、自发的状态。项目的成功全凭q气和项目成员的个h能力。而第二种情况其实一个前q了的Ş态，最典型的代表就是我们之前提到过的瀑布模型。那q种考虑周密的计划ؓ什么也Ҏp|呢？很简单，你认Z考虑周密Q可是实际上却不一定。我pq标榜自p虑周详的计划中排出的时间表是一?天的。看来他一开始就没打让开发h员休息了。计划是Ҏ来的一U估计，哪一个h能够准确的说?个月后的情况Q恐怕没行吧??1号之前，有几个h能料到那天会发生q么大的事情Q那你凭什么推出半年Q甚至一q后的事情呢Q另外，你是不是真的非常了解你的开发h员，以至于有信心代替他们制定计划呢？
有h_计划没有变化快。这句话说得很对Q它提醒我们Q没有计划是不行的，不具备可执行性的计划也是不行的。计划不是拿来炫耀的，是要用来执行的。我们定计划的时候，可以没有华丽的词藻，好的构惟뀂但是我们不能没有一些要素：
·什?WHAT)Q按序列出辑ֈ目标所需完成的工作；
·何时(WHEN)Q完成工作所需要的旉Q?
·做到的程?HOW-WELL)Q要完成的工作以何标准来度量Q?
·资源(RESOURCES)Q完成工作需要的人员/资金{；
·?WHO)Q由谁负责完成Q务?
但是我们仍然逃不开现实和计划的背离的问题。我们虽然对预计一q后的事情把握不大，Ҏ握开发h员在想什么把握也不大。但是如果你自己x自己两个星期后的事情应该q是能够猜的八九不离十吧。这引Zq代的概c一个项目由几个甚至几十个的q代周期l成Q每个P代周期都是比较容易估ƈ制定计划的。这是q代的思想Q也是Y件工E技术的一个大飞跃。说到这里，我又要吊大家的胃口了。关于具体制定P代计划的讨论Q我们会留到下一章节讨论l节需求徏模的时候再谈?
9. 培训
我很难想象一个项目没有培训该如何q行。兵书有云，"三军未动Q粮草先行?我们可以理解Z先做好充分的准备。项目也是一P在一开始就要指定好培训的计划，留出培训的时间。我惻I除非是一个非常完的团队Q否则他的成员一定也q是有不懂的东西吧，如果没有培训计划Q把学习的Q务推倒个人头上，目的风险就会变得难以控制?
说v培训Q大家可能就会认为是大家正儿八经的坐在那里，听一位老师上课。ƈ不是q样的，q里说的培训是一个广义范围的培训Q达Cl课E、一ơ会议，到一ơ讨论、一ơ交，都可以是培训。而其目的Q就是ؓ了让团队成员拥有_的知识和技能，来完成项目?
]]>