初次在实际项目中进行业务建模的体会

　　我从去年起就开始跟进一个系列工作，系列工作被拆分成了多个项目，都在按计划开展。最近系列工作最终落地实施的软件项目开始启动了，最终中标的开发商业务经验一般，我作为甲方的项目管理人员，为了避免项目进度因为需求调研质量问题造成拖延的风险，我决定采取两个措施，

　　一是全程引入迭代开发的概念，其实这也不是什么新东西，但好像开发商还是用瀑布模型的多。
　　二是在需求阶段，特别是业务分析阶段，我将主导这个过程，整体分析，然后分配相关工作给开发商做。

　　项目呢基本上就在上周开始的，第一次的调研会开的很不成功，原因就是设计的流程和实际的流程有偏差，实际执行人就不乐意了，这是我没料到的，以为业务部门自己设计的流程，只有照着分析和实施就行了，其实实际上负责实施的部门有着自己的一套做法，和制定好的程序不一致甚至是冲突的，毕竟系统做出来是要给执行人用的，如果他们的愿景照顾不到的话，那系统做出来只有是破烂。

　　因此，我重新整理了下思路，决定业务建模按照以下的过程来实施：
　　调研现状－描述业务总流程或上下文－识别参与者和业务用例－构建业务模型－描述用例－完成业务调研报告。

　　按照这个路径，做起来顺利多了，上周基本上做了以下几样工作：
　　１、找业务策划了解了目前的现状，并用活动图记录了下来，形成了总体的流程图，在与实际负责人讨论后，我发现实际执行的流程和设计上的流程其实出入并不大，也就是只有检查点的设置问题而已，只需要在设计流程时灵活的定义一下就可以了。
　　２、根据总体的流程图和相关部门，识别出了参与者，然后通过参与者进行了用例的分解，并形成了初步的用例模型。
　　在这里我曾经犯过一个错误，就是在项目招标阶段，想当然的制定过一个业务模型，后来由开发商根据理解又细分了一下，结果问题比较大，其中的用例识别的很有问题，还好及时的纠正了过来，虽然现在的也不一定就正确，但至少清楚了许多。
　　３、剩下的工作就是找每个用例的负责人去落实用例内部的工作流了，这部分工作就交给开发商去做了，我最后把把关就可以了。　　

　　在做这次项目业务建模阶段的过程中，主要的问题还是边界、业务参与者和业务用例上面，这三样如果搞不清楚，那就肯定是因为业务没摸透，想当然的话肯定做不好。特别是业务用例这块，如果识别的不正确，后面的工作就相当的迷茫，有种进行不下去的感觉。当这种感觉出现的时候，如果想草草了事，随便搞个业务调研报告就开始进行需要分析，那就麻烦了，打根上就有问题的，还能指望开发出来的东西能用？

　　在业务用例识别的问题上，一直都有个问题始终搞不太清楚，就是如何将一项工作的总体流程，拆分成一个个的用例，做的过程中渐渐发现，我困惑的原因还是在于对业务的不熟悉，在于边界的模糊和参与者的识别错误，在将整体流程完全掌握，并按参与者的责任逐步划分后，业务用例自然而然就出现了，最终形成的用例形成几类：
　　１、重要的市场活动用例。
　　２、为市场活动提供支撑的用例。
　　３、为达到更好效果进行相关管理的用例。
　　至于总体流程（这里叫业务上下文也许更合适，但过于技术，需求部门应该难以理解），毕竟业务用例模型不是用来描述流程的，所以还是得再用个图例表示。

　　在上周五完成了业务用例模型后，周六没啥事就又找了些资料看看，有篇文章对我启发还是比较大，前面写的一些内容在当时只是有个大概的感觉，当时写不出来，现在写下来也是看了这篇文章有了些启发才动手写下来的，文章标题：使用用例捕获业务需求，连接：http://www.uml.org.cn/UMLTools/200503093.htm

　　我作为甲方跟进项目的负责人，充其量也就是个项目协调人，如果不是这个项目太重要，我也不会做到这种程度，水平有限，一篇豆腐块写了一个多小时，惭愧呀，当是锻炼锻炼了。

　　主要参考资料：rup2000中业务建模部分，周末又看了rup2003，奇怪为什么ibm把业务建模那部分给整没了，只好还是看rup2000.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/1673/viewspace-246112/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/1673/viewspace-246112/