蚕丝被过敏的图片大全:业务建模-转载

来源:百度文库 编辑:九乡新闻网 时间:2024/04/28 19:59:06

业务建模(Business Modeling)是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系,业务建模强调以体系的方式来理解、设计和构架企业信息系统。业务建模(Business Modeling)是一种建模方法的集合,目的是对业务进行建模。这方面的工作可能包括了对业务流程建模,对业务组织建模,改进业务流程,领域建模等方面。

 

注:参考RUP业务建模方法论: http://oa1.jmu.edu.cn/Rose/RUP/process/workflow/ovu_busm.htm

 

一、为什么要业务建模

 

Brooks 大师说,三十多年来各式各样的应用系统(Application Programs AP)历经多次的修修改改,已经变得面目全非,如同一群的怪兽,难以驯服。 Rogerson大师也说,The application is a rock in the river of change.(应用(系统)成为改变之潮流中的顽石)。

     

对很多企业而言,有一个统合企业各部门的信息系统的心愿似乎已经成了一种奢望。企业中或多或少都会有一些应用系统在辅助企业的自动化运作,当企业信息主管希望能够对目前的信息系统进行整合,能够配合企业的发展的时候,他们失望了。大多数的应用缺乏一个统一的接口,难以进行整合。

     

在我们进行项目开发的银行中,我们也同样发现了这个问题,不同部门的系统之间无法进行互联,跨部门的业务流程必须经过手工的处理。

 

以前,应用程序的开发都是基于部门的功能的而建的。单纯只是为了解决目的而建立应用系统。所以这种方式建立的应用系统是针对特定的功能区域(Function Area)而建立的。至于如何使企业内的多个应用系统共同运作,就不在设计者的考虑之列了。随着企业的发展,就会发现企业需要变化以适应市场变化,业务发展的时候,原有的一系列应用系统却成了企业发展的拦路虎,这使得企业不得不回到手工的时代。

     

针对这种情况,有没有相应的解决之道呢?解决的方法就是从业务建模入手,而不是从较低层次(部门级或以下)入手。通过用例分析技术,建立企业的业务模型,进行适当的切割,选取稳定的软件架构,分析出企业的业务实体(Business Entity 企业中微小不可分的事物,抽象或具体的,如帐户,契约等,又被称为Business Object),以此为基础,组装出组件(Component),落实到相应的三层结构,建立针对特定功能区域的应用系统。

 

以这样的流程做出来的企业应用系统,不论规模是部门级的,还是企业级的,都有扩展的余地。以组件为基础的软件三层构架,也能够较好的配合企业的业务变化而变化(相应变化的代价较小)。而整个流程的第一步,就是业务建模。

 

注:业务建模期待解决的问题仍然是从业务和流程的视角来分析和构建IT系统,端到端的业务流程和全局的领域模型期待打破原有的职能部门壁垒和各个IT系统的孤立性。通过业务建模使企业业务和流程平滑过渡到IT系统的构建,从业务场景视角来分析和构建IT系统。

 

在前一段时间,中国很流行企业流程再造BPR(Business Process Re-engineering)这个名词。BPR这一名词中的R(Re-engineering)一词是由Dr. Hammer提出,说明企业必须推动四个层面的重新设计:Re-position、Re-organization、Re-system、Re-vitalizing之再造工程;名称中的P(Process),更是管理上由销售、采购到财务、生产各层次,力求降低成本、提高产出,所必须精密设计的企业管理流程或程序。这个词目前都是和ERP串联在一起,成了ERP的前置工程,更成为保证ERP能建立企业完美管理体系,以支持高绩效的最重要因素。实际上呢,这个BPR就是我们所谈到的业务建模。 (注:BPR的重点仍然是打破职能部门壁垒的横向贯通的端到端业务流程)

可以看出,业务建模在ERP工程中被着重强调,而且ERP中的BPR已经成为一门独立的学科。不仅如此,即便是在普通的信息系统中,业务建模也是非常重要的,所不同的,仅仅是它们的规模而已。这一点上,可能大家会不理解,如果你只是为企业的业务自动化建立应用,直接照搬企业模式不就行了吗。这里有两点原因,一是企业原有的业务模式在以人为主的环境中可能运行的很好,可是把这套模式原本不动的搬到计算机上就未必会适合了。人的能力和计算机的能力有很大的出入,所以流程必须经过调整以适应计算机;第二个原因是上面已经提到过的避免产生部门级的,部分功能区域的应用系统。

 

在RUP中,业务建模被作为下游流程的输入重点强调:业务模型是需求工作流程的一种重要输入,用来了解对系统的需求。业务实体是分析设计工作流程的一种输入,用来确定设计模型中的实体类。(RUP)

 

二、业务建模的目的

 

  • 了解目标组织(将要在其中部署系统的组织)的结构及机制。
  • 了解目标组织中当前存在的问题并确定改进的可能性。 
  • 确保客户、最终用户和开发人员就目标组织达成共识。
  • 导出支持目标组织所需的系统需求。 

为实现这些目标,业务建模工作流程说明了如何拟定新目标组织的前景,并基于该前景来确定该组织在业务用例模型和业务对象模型中的流程、角色以及职责。作为对这些模型的补充,还开发了以下工件:

  • 补充业务规约
  • 词汇表
  • 与其他工作流程的关系
  • 业务建模工作流程与其他工作流程的关系如下:
  • 业务模型是需求工作流程的一种重要输入,用来了解对系统的需求。
    业务实体是分析设计工作流程的一种输入,用来确定设计模型中的实体类。
    环境工作流程开发并维护支持工件,例如“业务建模指南”。


三、业务建模的规模

 

根据环境和需求的不同,业务建模工作可能有不同的规模。以下列出了六种这样的场景。

     

场景 #1 - 组织图

您可能需要构建组织及其流程的简图,以便更好地了解对正在构建的应用程序的需求。在这种情况下,业务建模就成了软件工程项目中的一部分,它主要是在先启阶段执行的。通常,这些工作在开始时仅仅是画出组织图,其目的并不是对组织进行变更。但实际上,构建和部署新的应用程序时往往会进行一定程度的业务改进。

     

场景 #2 - 领域建模

如果您构建应用程序时的主要目的是管理和提供信息(例如,订单管理系统或银行系统),那么您可能选择在业务级别上构建该信息的模型,而不考虑该业务的工作流程。这就称为领域建模。请参见工作流程明细:开发领域模型。通常,领域建模是软件工程项目的一部分,它是在项目的先启阶段和精化阶段中执行的。

     

场景 #3 - 单业务多系统

如果您正在构建一个大的系统(即一系列的应用程序),那么一个业务建模工作可能成为数个软件工程项目的输入。业务模型帮助您找出功能性需求,并且也作为构建应用程序系列构架的输入。详情请参见概念:从业务模型到系统。在这种情况下,通常将业务建模工作本身当做一个项目。

     

场景 #4 - 通用业务模型

如果您正在构建一个供多个组织使用的应用程序(例如,销售支持应用程序或结账应用程序)。一种有效的做法是:从头到尾进行一次业务建模工作,从而按这些组织的经营方式对它们进行调整,避免一些对于系统来说过于复杂的需求(业务改进)。但如果无法对组织进行调整,那么业务建模工作能够帮助您了解并管理这些组织使用该应用程序时存在的差别,并使您更容易确定应用程序功能的优先级。

     

场景 #5 - 新业务

如果某个组织决定要启动一项全新的业务(业务创建),并将构建信息系统来支持该业务,那么就需要进行业务建模工作。在这种情况下,业务建模的目的就不仅仅是要找出对系统的需求,而且还要确定新业务是否可行。在这种情况下,通常将业务建模工作本身当做一个项目。

     

场景 #6 - 修改

如果某个组织决定要对其经营方式进行彻底修改(业务重建),那么业务建模通常本身就是一个或多个项目。通常,业务重建分数个阶段完成:新业务展望、对现有业务实施逆向工程、对新业务实施正向工程以及启动新业务。

四、业务建模时期的主要任务

 

项目涉众的共同愿景:要想项目成功,可离不开项目涉众的支持。在项目一开始,不论是项目涉众还是开发人员,对项目的任务、范围都是模糊不清的。但随着项目的深入,原来模糊的景象会慢慢清晰、立体起来。但是为了不浪费时间,我们有必要在项目射入之前,现在项目涉众中竖立一个共同的愿景。

     

共同愿景的竖立可没有想象中的那么简单,因为每位涉众都关心自己的利益,都有自己的评判标准。你可以把大家的意见都列在白板上,然后逐项集中讨论,做出修正,直到大家的意见一致的时候为止。在共同远景的竖立过程中,其实有两件事情也已经同时做了,项目范围(scope)和高阶(high-level)需求。

     

项目范围:项目该做什么,不该做什么,需要在一开始就有明确的定义。对于项目范围内的需求,一个也不要放过,而项目之外的,一个也不要去关心。虽然有的时候,范围的变化会有利于项目本身,例如客户的合理要求或是市场目标客户的变化,但是这种变化应该要在"资源能够支持"和"得到审批"的前提下进行。

     

项目范围的描述可以通过陈述和图示来进行。我建议大家使用图示。因为陈述语句比较含糊不清。例如常常听到有客户说。"我要建立我公司的电子商务系统。"这句话就是含糊不清的,你的电子商务系统是销售什么产品?面向什么客户?是否要支持在线支付?根据这些疑问,这个陈述句可以做进一步的修改,"建立在线订货系统,针对当前的目标客户销售公司的目前产品。"这样就清楚许多了。不过图示的方法会更好一些,在图的选择上,你可以使用DFD图或是用例图。根据经验,DFD图比较容易为客户所接受。

     

高阶需求:这个部分我们在下面会详细讨论。既然是高阶需求,就不能讨论过多的细节。在讨论高阶需求的时候,尽量保证快速的讨论出系统的概貌,建立需求模型,得到项目涉众的一致通过。

     

取得支持:为了保证需求计划的顺利进行,取得项目涉众的支持至关重要。你可以选择在这个时候告诉项目涉众他们的权利和义务,以及开发人员的权利和义务。在这个方面,具体的我不想多说,大家可以参考『软件需求』的第二章。主要的就是"涉众有改变需求的权利,同时要承担向开发人员讲解需求的义务。"开发人员的权利和义务正好和涉众相反。

     

业务建模会议:所有的这一切都通过业务建模会议进行,和其它会议不同的是,这个会议需要所有的项目涉众参加,如果不能获取所有项目涉众的意见,那就不是完美的。会议中最重要的工具就是白板,一位出色的速记员也是必须的。

 

五、需求和业务建模

 

业务建模是需求工程中最初始的阶段,也是整个项目的初始阶段。需要指出的是,业务建模时间的跨度在不同的项目中有很大的差别的。在有些项目中,例如大型ERP系统,可能需要几个月的时间。而对于普通的项目,业务建模的时间可能仅仅需要几天的时间。

 

需求是技术无关(technology independent)的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设计阶段才需要考虑的事情。而在业务建模阶段,不但要保证需求的技术无关性,还要保证你的需求不要深入细节。因为在业务建模阶段,最重要的事情就是要了解业务的全貌,深入细节会浪费时间和精力。要知道,讨论一个企业里的业务细节,就算给你一个月的时间也没必能够结束。

 

在实际中,这两点都是很难做到的。例如企业原先有一个系统,这就不得不由你讨论和新旧系统的兼容问题。这时候就要注意,如果你是讨论就有系统的架构的话,那还是属于技术无关的范畴,如果你一旦进而讨论各具体模块/组件的细节,那就非但不是技术无关,而且也深入细节了。在不深入细节的问题上,往往你很难禁止项目涉众(Stakeholder)①不去讨论一些相关的业务细节。这个时候你可以将这些细节记录下来,然后再回到业务建模上。

 

①A stakeholder is defined as anyone who is materially affected by the outcome of the project. 涉众是所有会受到项目结果重大影响的人。

 

六、业务建模中的用例

 

在上一篇中我们讨论了很多用例的知识,可是落实到企业中的时候,我们往往会感觉难以把握企业的用例,这一点我们在用例的误区中也有提到。在实际的情况中,你可能会对角色的归类,用例的划分,粒度的把握等很细节的方面都没有底,偏偏这些实际的东西对你的项目有非常大的影响。

 

RUP中,有多种的概念来支持用例的实现:业务主角(Business Actor)、业务实体(Business Entity)、业务用例(Business Use Case)、业务角色(Business Worker)、业务用例实例(Business Use-Case Instance)。为了能够比较清楚的展示出业务建模,我们采用了UP方法的代表――RUP。但在实际中,要视大家具体的情况而定,这里所讲到的概念,都是为了帮助大家理解建模过程,并不是让大家生搬硬套。

  

在我们对系统还丝毫不了解的时候,我们就会把系统看成一个很大很大的黑盒,这个大黑盒子我们会叫他业务域(Business Domain),把它的外部看成一个业务环境(business environment)。而那些在业务环境中和业务域有关系的人(也可能是物)就被称为业务主角(Business Actor)。在实际的例子中,我们可能会把信贷业务(注意不是信贷业务系统,这里是业务建模,系统还不存在。)称为业务域,我们经过调查,发现平时和信贷业务打交道的有客户,人民银行,外汇管理局,其他银行,信贷部门使用的其他系统,银行内部的其他部门。所以这些人(物)就是业务主角。业务主角的实例一般包括了客户、供应商、合作伙伴、潜在客户("市场")、当地政府、在业务中未建模部分工作的同事等。必须注意的是,业务主角表示的特定类型的用户,而不是某一个具体的用户。一个角色可能会有很多实际用户担任,一个实际的用户也可能会担任很多的角色。

 

业务用例以及业务用例实例在RUP中的定义如下: 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. (注:业务用例即是流程,即是流程的活动单元)

  

业务用例实例是在业务中执行的一系列动作,这些动作为业务的个体主角产生具有可见价值的结果。业务用例定义了一组业务用例实例。业务用例具有名称。

  

刚开始大家可能会对业务用例以及业务用例实例有所疑问。其实可以把他们看成基类和子类的关系。在一个企业中,具体的工作流程可能有很多很多,比如你去麦当劳的时候,点汉堡和点薯条的工作流程就不一样。众多的流程给需求的调查工作造成了一定的难度。即使是最古老的哲学也告诉我们,表面现象是复杂的,本质是简单的。为了简化需求工作,我们就把点汉堡和点薯条归纳为点餐。这样,点餐就是一个业务用例,而点汉堡、点薯条就是相对应的业务用例实例。

 

业务角色和业务主角的概念也很容易让人摸不着头脑。其实看它们的英文愿意会更容易理解它们的区别:Business Worker,Business Actor。Worker有工人的意思,而Actor有参与者的意思。所以它们的区别就是一个在内部,一个在外部。业务角色是实现业务用例的人,业务主角是和业务有关的人。例如,对银行的押汇业务而言,客户就是业务主角,他和业务有关。而押汇人员就是业务角色,因为他们是实现业务用例的人。在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.

  

业务角色代表业务中的一个或一组角色。参与业务用例实现时,一个业务角色和其他角色进行交互,并操纵业务实体:A business actor represents a role played in relation to the business by someone or something in the business environment.

 

业务主角代表了与业务有关的角色,此角色由业务环境中的某个人或物来担任。

 

业务角色和业务主角

分辨业务角色和业务主角要看环境而定。当你开发企业的ERP系统时,部门的员工都属于业务角色,而你开发一个部门级的应用时,其他部门的员工可能属于业务主角。

  
业务实体,在一些文章中被称为商业对象(Business Object)。不论怎么叫,所表示的意义都是一样的。例如在银行信贷这个例子中,我们就涉及到很多业务实体:契约、单笔贷款、客户等。所以业务实体就是企业中那些很基本的要素。如果觉得银行押汇的例子不好理解。可以想象餐厅中的菜单、汉堡等都是业务实体。在RUP中,业务实体被定义为:

 

A business entity represents a "thing" handled or used by business workers.

业务实体代表业务角色处理或使用的"事物"。

 

业务实体

在很早以前,我们讨论过需求易变性。相对于需求的不断变化,可是业务实体对象在一段相当长的时间内都存在。航空公司今天打折,明天又不打,还有明折、暗折。可是机票从来没见有什么大的变化,从来也只有那几样属性:价格、航班、出发地、目的地。所以业务实体是比较稳定的。这对于我们是有很大的意义的:

"一个业务实体经常代表某个对多个业务用例或用例实例有价值的事物,因此,业务实体对象的生存期相当长。一般而言,一个好的业务实体不包含关于其使用主体和使用方法的信息。"(RUP)

 

由业务实体组成的业务用例会稳定很多。在以前,开发方式采用模块为基础的方法,需求变化的时候,只好改写模块。如果采用稳定的业务实体来实现业务用例的话,业务用例的改变只需要对业务实体进行重新的组合。当然,这里还需要很多的技术来实现,并没有那么简单。要知道,四个现代化可不是一天就能够实现的。

 

还有一个使用业务实体的重要原因:业务实体的特性决定它具有天生的重用性。就像麦当劳的销售系统中有汉堡实体,生产系统中也有,供应链系统中也有。天哪,这世界真是美好!

 

使用业务实体一个很大的困惑是应该把它做为类还是属性。这个取决于业务环境对这个实体的重视程度。一个客户在银行信贷部门是一个很重要的类,而在押汇部门就只是信用证实例的一个属性。这个问题非常的重要。设计时的失误可能会导致今后系统改进的极大痛苦。例如本该设计为类的业务实体设计成了属性,在今后增加属性的时候不得不面对着数据库的调整和系统的修改。

  

6. 建立业务用例模型

 

业务用例模型(business use-case model),在RUP中定义为: 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.

  

业务用例模型是说明业务预期功能的模型。作为一个核心输入模型,业务用例模型用于确定组织的各个角色和可交付工件。从业务用例模型的定义可以看出,它是企业最核心,最概括的业务说明。它主要是由业务用例和业务主角构成的,其主要目的是说明客户和合作伙伴是如何开展业务的,它描述业务的主要方式是通过业务用例的方式。 

企业中的业务通常都会由多个的业务用例的多个实例构成。这些业务用例形成的企业工作流程可能会由业务主角所引发,也可能会由业务规则所引发。业务规则(Business Rules):业务规则是必须遵守的政策或条件的声明。(Business Rules are declarations of policy or conditions that must be satisfied.)

  
业务用例模型实际上就是企业经营业务的一种描述,为了建立完整、准确的企业用例模型,应该将注意力专注于企业的业务做了些什么事情,而不应该集中于如何做。虽然这样可能会产生一些业务用例相冲突,相重复的情况,但是RUP的思想在于迭代,这项工作完全可以在接下去的迭代周期内完善。


业务用例模型是和企业业务最贴近的计算机模型。它的很多思想和企业日常经营如出一辙。在企业的日常活动中,业务的种类可能有很多种。在一些讲述ERP思想的文章中,通常会强调三类:

  • 一种是和主营业务密切相关的工作,例如银行的营业部、信贷部、押汇部等。这种工作通过人的劳动,将一种资源转变为另一种资源,产生价值。、
  • 一种是管理型的工作,例如公司的管理层,财务部门等。这种工作本身并不产生价值,但是它通过指导、管理、检测第一种工作,加大第一种工作的产出价值。
  • 支持工作,例如系统管理、安全等。它并不是很重要,具有支持其他工作的性质。

业务模型同样可以使用这种分类。通过这种分类,可以更好的把握核心业务用例,为下一步的工作打好基础。有很多业务用例是由业务主角触发的,RUP中也把和业务主角有关联关系的业务用例称为核心业务用例(Core Business Use Case)。这强调了构建业务模型的目的是为了提供以用户为中心的服务。这也是我们建立业务用例的时候应该注意的。

 

当然,有时候业务用例的触发是为了产生用户需要的结果。例如企业的市场调查行为就不是由业务主角触发,而是企业积累了大量用户请求的结果。而对于管理型、支持型的,不直接和业务主角的客户类发生联系,但是也有其特定的业务主角,如管理型的业务用例需要和董事会为发生联系,支持型的业务用例可能和供应商发生联系。

 

在建立了基本的业务用例模型之后,对此模型进行精化是非常有必要的,这时候,在上一章中我们介绍的用例的扩展关系和使用关系就有了用武之地。除了这两种关系,还有一种新的关系。

 

7. 在业务建模中使用关系

 

泛化关系(Generalization):根据我的理解,可以把它看作我们比较熟悉的继承关系很相似的一种关系。Generalization一词含有一般化、概括的意思。它是一个相对抽象的词。虽然它和继承关系非常相似,但是它们在使用环境和产生目的方面都有相异之处。下图描述了四个业务实体之间的泛化关系:

 

当你去麦当劳的时候(不要误会,我并不是很经常去的),会选择麦香鸡汉堡、麦香鱼汉堡或是吉士汉堡。但是分别对这三种汉堡建立业务实体就非常没有意义。所以可以将它们概括为汉堡这个业务实体。同样的道理,企业的业务流程中也可以概括出一些共有的属性和行为。为了避免多次说明同一个工作流程,您可以将共有的行为放在一个单独的业务用例中。称为父用例,执行子用例的用例实例将遵循父用例的事件流,同时插入附加行为或修改在子用例事件流中定义的行为。

  

8. 方法的选择

 

以上的原理我采用了UP的方法。但是除了UP方法,还有XP、FDD等方法。所以在做业务建模的时候,也要根据不同的方法选择适当的工件。例如素材和功能。方法的好坏并不是我们这片文章讨论的重点,我会在另一篇文章中讨论方法。再一次需要强调的是,上面讨论的RUP的工件只是为了学习,所以才定义了比较复杂的工件,区分了它们之间的区别。但是在实际中,并不需要这么多的工件,那只会使你的项目涉众和开发人员糊涂。这些工件的区别只要在你心中就可以了。

 

七、业务建模的原则(Principle)

 

1. 谁才是"上帝"

 

我们说客户是上帝,是因为客户的重要性,客户占有决定性的地位。可是在软件开发中,到底是谁有决定权呢?是出资方,还是项目经历,或是程序员?

  
职责不清,是业务建模失败的主要原因之一。我们可以很容易的看见客户把自己的要求用几句话高度浓缩之后扔给开发人员,或是开发人员按照自己的意思开发程序。难道说,客户和开发人员之间真的是"心有灵犀",完全不用沟通的吗。

 

在我一次开发过程中,遇到过一个很有意思的涉众,他在他的需求分析中这样写:"总之,要实现那种能够想到就能做到功能。"我想,这位涉众对我们的计算机工业有着非常远大的抱负。但我不得不客气的告诉他目前实现是不太现实的。

 

大家听了可能会觉得好笑,但是在我自己和客户打交道的生涯中,这种客户不在少数。现实就是这样,你要怎么做?是一笑之后,弃之不顾吗?我想大多数人会这样做。因为他的要求太荒唐了嘛。可是,你有没有花时间去了解一下,他这句荒唐的话背后代表了他的什么意思呢?我觉得,软件开发人员负有教育涉众的义务,你需要引导你的涉众,让他们说出自己的心声。我在看到这位涉众的这句话后,就花了一些时间去了解,其实呢,事情很简单,他就是想要一个能够定制报表模板的功能。而在项目结束后,我和这位涉众有幸再一次的合作,这时候,他已经成为了一个出色的客户方的项目领导者了。

 

这个例子说明了什么呢?涉众往往都是领域专家,对自己的工作有很深的认识,可是由于对软件开发的不了解,涉众往往表达不清,甚至表达不出自己的需求。这时候,就是体现你的功力的时候了。记住,象对待上帝一样对待你的客户。

  

2. 耐心是首要的

 

明白了谁是"上帝",那就要耐心的对待上帝。学理工科的人,一般在逻辑思维上会比较好,可是对于涉众来说,可不一定是这样。我就遇到过一位做档案工作的涉众,在了解需求的时候,扯东扯西,含糊不清。明明一分钟前才否定的方法,下一分钟又提出来了。我觉得我的脾气应该是不错的,可到最后也几乎发飚。所幸,最后我终于撑了下来。我想,在经历过这件事情之后,我的耐心指数又会有一个很大的提高了吧。

  

我有一位同事的耐性是我所佩服的,在一个网站项目中,他负责系统分析。他整整花了三天的时间,和网站项目的负责人住在一起。最后系统分析出来之后,他的精神还不错,可是那位负责人已经快不行了。

 

当然,这只是个笑话,并不是去鼓励大家拼命。劳逸结合还是很重要的,身体是革命的本钱嘛。但是这告诉我们,如果缺少耐心,需求是很难成功的。例如在业务建模的讨论会上,你虽然规定了这次的会议讨论的是高阶需求,可是与会者总会时不时的争辩一些芝麻绿豆的小事儿。你怎么办?我相信这种情况是很普遍的。耐心最后会仍会体现为沟通,只有耐心的沟通,你才能揭开需求的重重面纱。人的行为总是会受到思想的指导,如果你解不开涉众的心结,你就不可能了解他真正需要的。

 

我的一位项目涉众的表现很奇怪,她总是在不停的说一件事情:"她要实现报表自动生成。"她的需求讲来讲去好像总脱不出这个范围,可是我从她那里几乎听不到别的东西了。这时候,我决定放弃了,我想从她哪里可能已经没有更多的资料了。但在我了解到她的工作中报表处理占用了她大量的时间之后,我改变了想法。在我花了一些时间帮她理清了报表处理的思路之后,她还在其他方面给了我很大的帮助。

  

3. 参与是重要的

 

XP方法的一个重要实践,就是提倡"现场客户"(on-site customer)。也就是说,客户应该随时和开发人员在一起,随时提供资料和做出决策。而这个客户,也必须领域专家,而且能够有权做出决策。

  

这种现场客户相信国内的软件组织多半还做不到。但是一定要往这方面努力。我认为,这种现场客户有两种人:一种是项目涉众,还有一种是行业专家。其实很多软件公司都会配备一些管理咨询人员,这些人就是行业专家。有数据统计说,目前广东省软件公司中的咨询人员和开发人员的比例达到了3:1。我觉得这是好事。项目涉众往往对自己的工作中的事务性部分有很深的认识,但是很难将之提升到一个理论的水平。这时候就需要一些行业专家来帮助了。让行业专家和项目涉众共同探讨,还能够激发项目涉众的灵感,想到原来他想不到的方面。这就是"潜在需求"的开发。

 

另一方面,参与还意味着需要项目涉众全身心的投入到业务建模的过程中来,要能够调动他们的积极性。因此呢,太复杂的流程会阻碍涉众的参与。所以,使用一些简单的、能够为客户所接受的工件(Artifact)来进行业务建模是很有必要的。我说过前面讨论的那些"主角"啊,"用例"啊,那是理论,是给开发人员看的,让开发人员心里有个底。你给涉众看这些,他们能懂吗?等他们了解了这套机制,恐怕黄花菜都凉了吧。

  

素材(User Story)、特性(Feature)、CRC卡片这些都是很不错的工件,既简单,又能够满足需要。

  

知识点:素材和特性都表述了用户的一个简单的要求,它能够在较短的时间内完成。素材是XP方法中的工件,特性是FDD方法中的工件。CRC是class、 responsibility、collaborator的缩写,它是一张分为三个部分的卡片,分别标记了类名,类的责任,以及类之间的合作关系。非常的贴近客户,甚至可以在做游戏的过程中完成卡片的填写,能带来很强的客户参与度。

  

4. 拥抱变化

 

我想这一点会遭到开发人员点一致指责。毕竟,需求变化是开发人员最讨厌的一件事了。不错,我也讨厌。可是,就像我们常说"哭不能解决问题"一样,讨厌能解决问题吗?拒绝客户的变更要求,要求客户在需求规格说明书上签字。这些做法只能是适得其反。没有任何正面的、积极的意义。

  

必要的需求变更管理是重要的。因为无休止、无控制的变化必然会造成资源的极大浪费。但从另一方面说,需求变更被接受的评判标准应该是"是否合理",而  需求变更要求我们的开发工作要迭代式进行,包括需求、设计、实现等阶段。这样才能将变更风险减到最小。这一点我们在讨论具体需求建模的时候会进一步讨论。

 

拥抱变化的更高一个层次是提前预估变化。制定一个可能的变化清单来记录可能出现的变化。最简单的例子就是一个企业在开发了进销存系统之后又希望能够开发财会系统与之相连。如果你能够预先留下伏笔,相信能够省不少力气。预估变化的另一种做法是通过使用模式。但是切记,模式的使用也不能过头。这些是题外话,如果有机会我会在其他的文章中集中讨论这方面的问题。

 

八、业务建模的实践(Practice) (略)