对业务建模的思考——为什么要业务建模 (转)

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

以上大家可以理解，我们有没有更深的理解呢？我先从业务主角和业务角色说起业务建模，在业务建模中主要有业务主角（BUSINESS ACTOR）和业务角色（BUSINESS WORKER），对此我们有什么了解呢。我先做出定义：业务主角是服务对象，如对商店进行业务建模， 业务主角是顾客。业务角色是服务人员或系统，如对商店进行业务建模，业务角色是售货员。业务主角是为谁提供服务，产生了用例。业务角色是提供服务，完成了用例。可以仔细看看RUPCN。这两个东西它们在ROSE中图形的表示也不一样。

但大家有没有想过，业务建模更深的意义，我们在传统的软件工程来说并没有类似业务建模这个概念，而RATIONAL公司又要将此放入，在软件工程中，它又到底起了什么作用呢？

一般说来，我们做一个软件项目基本上都是从需求调研后就到需求建模和需求分析了，没怎么去想业务建模。而大家有没有想过，我们对需求的处理比较表象，如界面、功能和数据，对业务处理过程缺少规范的说明，而这正是开发必须的。你有没有觉得你以前很多开发没有准确反应需求，是否有一个原因，不是需求不清，而是对需求的实现过程不清，即没有了解好业务，从RUP的角度来说，也就是缺少了业务建模这一关键环节。我曾经思索过业务建模最主要解决什么问题，我的看法就是业务建模就是创建业务处理模型，是进行需求分析的依据。而需求分析的结果，将要确定一个开发规范，正确的实现业务处理过程应当是它的一个重要内容，而我们在需求调研时，往往忽视了这一点。

那么，在需求调研中，需求建模与业务建模谁先谁后呢？个人认为，业务是本来就存在的，不管有没有这个软件或项目，它都存在，它都在按一定的模式运作，因此业务建模与需求调研、需求建模是无关的，立项之前业务模型就可以存在. 或是立项以前，业务建模就可以完成的。 然而，实际并非如此，用户只知道如何处理业务，却很少有一个完整的业务模型，当立项时，就需求承建方邦助客户创建它。因为承建方不了解客户的业务过程是不能建模的， 又必须了解客户的业务。

对于软件开发过程，从软件工程的角度来说大多数人都清楚从需求调研，到需求建模，需求分析，系统分析，系统结构设计，系统代码设计，系统测试，系统维护这一过程，我参与过的项目，让我感到，有些项目失败或是非常难做，不在于以上这些环节没做好，而在于少了业务的环节。

很多人也许会说，业务不就是需求吗，没错，但更多的时候我们关注的是界面、功能、和数据，却很少注意功能之间的联系即业务过程。

有没有想过，我们将软件所有的功能做成菜单，让用户自己选择他们要做什么，而没有一个业务过程的概念，用户要自己知道用了某个功能后下一个该用哪个。这样的系统其实不是应用系统，只是一个数据处理机或者说是一个比较复杂的计算机器。它把业务过程分解为一些独立/分散的功能，而没有把这些功能组织起来。因此，有必要将业务从需求中分离而进行强调。我想，这也就是RATIONAL 公司引入业务建模这个重要的概念吧，

无论是从我的经验、观点和教训来说，还是看了RUP的观点来年，我个人认为新的软件开发过程是：业务调研，业务建模(业务分析)，(业务模型分析)需求调研（这时，已经有一部分需求可从来务模型中获得）, 需求建模，需求分析……因为建模的过程也是分析的过程，所以业务建模和业务分析可能交叉在一起。如果遇到一个客户，规范到已经有了现成的业务模型，那么直接就拿来就可以了。如果业务建模与需求调研是同一班人，那么需求调研中的业务模型分析工作就比较容易了。


业务建模当中又要注意什么呢？我个人的看法是：千万别把业务建模和需示分析混在一起啦。如网上订单系统，一个人下了订单，当然此订单是通过系统自动完成，并没有后台人员的支持，此时，业务主角当然是下订单的人，那业务角色呢 是否是没有，还是下订单的人？ 对于系统来说，业务主角当然是下订单的人，而业务角色呢？不太可能是系统自已吧？ 而我的看法是业务角色就是系统自已，那不是很矛盾吗？其实，关键一点是业务建模你不能有需求分析的概念，在这里，系统并不是软件系统，而是完成业务主角的订单，即一个用例的东西，根据业务建模的概念，完成了订单这个用例只能是订单系统，那么业务角色也就是订单系统。因为它是下订单这一业务中。

无论业务角色还是业务主角，都是对角色的抽象，不能具体到某个人的。而一个具体的事务，可能会兼任两个不同的角色，但此时，大部分发生了身份或岗位的转移。

关于业务建模，Craig larman在他的名著中倒是有所提到，作者在把它归纳在用例分析中了，比如他始终强调关键业务角色的利益所得和相对趋势。我在一个省级检测机构作项目时，就自觉得把系统对人的影响和角色对系统的期待，以及它们之间的反复作用放在一个很重要的层面上来考虑，尽管这种做法还无法按步就班地操作，就是先研究现有业务流程，把确定性和不确定性的因素考虑周到，再设想系统实现和人的反应性之间的关系。然后再在设计时注意软件的可变动性。这样的一个好处是项目相对比较顺利，和各方面打交道比较顺畅，真正让软件有使用价值，而不是变成一堆代码的尸体。

呵呵，这个帖子好象响应的人不多啊。

我勉强也可以算是做业务需求的吧。
目前我把它分成以下几块内容（主要针对企业定制应用）

1、客户方基本信息。
   包括客户信息、组织结构、用户、用户关系等
2、客户方业务流程和业务信息
3、客户方管理和生产模式
4、客户方的变化和发展方向
以上这几部分其实更接近于咨询所要了解的内容。

5、哪些部分需要使用系统？系统的边界和范围是什么？系统的涉众是什么？
6、系统对应哪些业务流程和业务信息，引入系统以后新的业务流程和业务信息是什么？？
7、引入系统以后新的管理和生产模式是什么？？
以上这三个问题我认为是一个项目最核心的问题
大到横跨整个企业的ERP，小到针对一个人的信息管理，都要考虑这三个问题。

8、对引入系统以后新的业务流程和业务信息进行概念建模
9、对引入系统以后新的管理和生产模式以客户方内部规范的形式固定下来
   这一步也很重要
10、获取具体对象和用例
11、获取对象关系和用例关系

注意：以上的步骤不是先后执行的，根据实际的情况会有调整。
      事实上在实际操作的时候往往是从第10步和第11步开始，但是只有这两步是不够的……

几年前看过高展的“全程建模”，颇有收益，应用于项目中的业务建模，能够解决一些问题，通过实践，也深感业务建模很重要（当时在做企业管理软件）。采用“全程建模”提供的方法和工具（实际上是IDEF）进行业务建模，非专业人士稍加解释也看得懂。
后来看UML、RUP，实践中觉得其中的一些方法、工具又是一种不错的业务建模方式，经过一两次“培训”（就是拿着写好的文档讲给他们听而已），非专业人士也看得懂。
再后来看XP，结合实践觉得“经过裁减的RUP等‘重型方法’+XP的某些原则”，也是很不错的，不过XP就没什么业务建模的概念了。
我是个“投机派”，呵呵，实践中觉得有用就拿来用！

xp团队中要求有一个现场客户，还要什么建模。

这个我看不能绝对，2年前我开始尝试在开发中使用一些XP或敏捷的原则，不过通过实践，说句老实话，即便完全按照XP方法组织开发过程，如果现场客户的业务素质不是很高、很全面，个人认为还是适当地建模先。

这个同意，因为都是为了尽量的沟通使用人员的思路，只不过有现场客户，业务方面全交给他了，自己建模就是业务自己顶一部分了。
不过业务建模我觉得把握度不好掌握，开发团队里面一般都不是业务好手，如果做的项目要求对业务很精通，那可不好处理了。
还有一种不好处理的，就是做之前也不知道要对业务了解多少才行，可能建模以后发现建错了，或者某个地方要大改。
本质上还是业务方和开发方能不能建一个成功模型出来的问题，我觉得业务建模是毕其功于一役的想法，我对它的个人判断是：局限性很大。

呵呵，业务建模为什么要”毕其功于一役“？
业务建模也可以迭代和持续改进的。

XP的很多精神完全可以用到业务建模方面的。

我有点下意识了，把形式和实质混淆了。在我的概念中业务建模是开发方到业务方那里几天，双方拿下这个东西。我下意识认为对于无法提供现场客户情况，我说这种形式是常见的形式。在这种形式下，我觉得基本就是毕其功于一役。
实质上确实可以不这么做，但业务建模要做出一个贯穿始终的模型，对初期建立的模型要求应该不会低吧(推测)，如果推测成立，说基本上是毕其功于一役我想不过分。

你觉得这种形式正常啊？对于开发有影响吗？



呵呵，从我个人的经验来看，这个推测不成立。
从迭代的角度来看，每个迭代的开始都应该是业务分析。