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

恩,说的不错.
不过太多的团队是从实际的项目用户这边获取到需求信息的
很少有脱离需求分析过程的领域建模工程，从某种意义上来说领域分析过程是一种研发活动,成本挺高的.
所以领域分析理论上是可以脱离于需求分析而独立存在的,但在实践中往往是交错进行的,甚至互相混淆，这种混淆对于单个项目来说问题不大……

事实确实如此，但是前一个项目是不是可以为下一个项目进行必要的积累？对一个行业的开发项目，是否可以成为为另外相关领域的研究过程？
如果单纯的从一个项目去研究对于目前广大的软件企业并没有太多的意义，因为我们的公司往往都是在进行短期的、成本和周期被严格限定的项目。但是越是这样我们就越是有必要去研究领域中的问题。
而用户使用我们的产品往往是为了解决一些他们现在已经不能解决的业务问题，这些问题解决的方法他们自己并不知道。作为一个非行业内的人士需要为行业中可以称为专家级别的人提出行业的解决方案的事情经常性的出现在我们的周围。我们如果不能找到解决的途径，我们就必然会被淘汰。
传统的需求工程所研究的问题和论述的方法，往往只是局限在单独项目的一个周期。这不能不说是一个非常严重的问题。这一点就类似LISP中的出现的你可以表达一个方程，但是这并不代表你解决了求方程解的方法。
我还认为对于领域的研究可以增加我们对个别项目客户需求理解的能力，从而更好的理解他们的真正目标。同时这样作还可以大幅度的提高我们建立一个行业内通用平台的能力，从而在工期和成本以及质量上更好的完成项目。
所以剩下关键的问题就是如何去从原来的经验中去提纯出关于领域的知识，并且把这些知识变成我们解决问题的能力。这就是我最近在作的研究。

就我个人的实践而言，我觉得这几乎完全取决于个人的能力
尤其是一种从繁复表象中抽取内在的完备的逻辑的能力。
在完备的基础上，能够抽取出越复杂的逻辑，该能力就越高。

工程学研究的一个方向就是如何产生知识，传递知识，和应用知识。同时作为个人的成长来说，寻找必要的方法和适当的方式，也是非常必要的。
同时作为一个组织，如果不能把其成员的经验进行沉淀，不能把前面的工作作为后面工作的基础，这也是一种资源的最大浪费。
所以我们有必要去学习如何进行这些知识的积累，去学习如何把经验变成知识。

知识是可以传递的，但是能力是无法传递的。
“授人以渔”是及其困难的一件事情……，基本上我是对此抱悲观态度的。

说点个人拙见， 虽然业务模型和 领域模型有可能在需求分析之前大体可以确定下来，但是我觉得可以这样理解这句话， 虽然大体的模型可以确定下来，但是在得到具体的需求 和 用例场景后，仍然需要对业务模型进行一个 整体的分析，得出一个更具体的更适合的 领域模型， 我想这个过程应该是在第一次迭代中对所有抽取出来的主要用例进行整体分析而得出的一个结果。

从这个理解上来说 ，我认为 业务建摸和 领域模型应该在需求分析之后 ，有什么过错？

领域模型是超出某个单独的系统设计的,业务领域适用的一套规则模型. 所以对于单个系统开发来说应该是早期需求/研究阶段进行建立, 目的是帮助界定系统边界/基本框架,确定基本业务规则.需求分析阶段之后是否还需要进行这样的工作?应该是不用的,因为这时系统边界已经确立了,开发工作应该围绕的是需求模型而非业务模型进行.
当然不排除系统开发完毕对于领域模型的理解有了进一步深入的看法,对其进行整理,以便今后相关项目开发之利.
但是根据单独系统需求的不同, 去修改领域模型, 这实在是犯了一个概念性错误.

我是第一次接触业务建模这个概念，大家不要笑话。

这里不是在讨论业务建模和传统瀑布模型的优劣，我觉得现在大部分的项目，还是按照瀑布模型来做，至多其中加了些更先进的方法。

不知道现在进行业务建模的软件公司多不多，反正我呆过的是没有，也许是我孤陋寡闻。
但我觉得业务建模确实有它大大的好处。就像各种模式一样，如果有个套路让你去套，你只需要在这基础上修修补补，不是可以剩下很多时间和精力么。但难的是，这个业务模型怎么建立起来，这方面的经验和能力应该要比较高了。

呵呵，我在挖坟，把老帖翻出来看了看，忍不住想把感想写下来。

我觉得不要太强调把整个过程的分得过于清晰，而应该根据具体情况来定，如果团队开发一个熟悉的领域，当然可以先进行业务建模，然后进行需求调研，但是如果涉足一个新的领域的话，我认为需求调研中就应该包含业务调研，需求调研不应该只是被动的接受客户提出的要求，还应该主动去了解行业的知识，客户的业务运转模式，和业务规则，通过调研人员主动去认识业务，并且这里存在一个管理思路的问题，一个软件并不只是迎合用户目前的业务，而是通过软件来提高用户的生产效率达到一个更好的效果，虽然现在国内软件做的并不是那么好，但这总是个方向。有点跑题，但是我觉得如果有能力在需求调研前业务建模当然是好，要是不行，我觉得在系统分析时做比较合适，软件基本过程总是从外至内的反复迭代来进行分析设计的，这里的外不是指界面而是从外部交互到内部交互，就像rose中会有business use case 和use case一样

业务建模，需要专业人士的介入，比如说领域专家，他们可以不是做软件的，但是他们对于这个领域非常的了解，以致于他们能给出一个适合于该领域的模型，同时又能顾虑到特殊的用户需求。

一般在进行业务（领域）建模时是需要有一名领域专家，再加上调研人员，还有客户，这样做出来的需求分析设计才会更完善。

当然，小的项目或者行业背景不深的项目，可能不需要领域专家的参与。但是，在行业背景很深的情况下，如果调研人员什么都不懂，那么跟客户交流起来也是很费劲的，毕竟大多数客户他们也并不真正的能把他的工作抽象起来，这个都需要领域专家的帮助。