技术支持 13:21:46
我想请教一下：
业务建模是对目标组织实际的业务流程建模(突出实际的流程)。
还是目标组织使用计算机系统后形成的业务流程模型(突出我们将要实现的系统)。或是其它？
狐狸糊涂 13:23:05
当然是实际的业务流程了。你的系统业务流程也是基于实际的业务流程才有的。除非业务流程存在非常不合理的情况，才考虑是否调整。
飞蓝 13:23:10
请问现在在深圳在软件开发大概的薪水在什么幅度,VB
青润 13:23:09
业务建模其实可以考虑分为两个渐进的阶段。
第一个是描述实际业务流程的内容。
第二个阶段属于业务整合规划的阶段。
青润 13:23:41
第二个阶段也就是要向实际的用例转换的阶段。
飞蓝 13:24:32
项目大,周期长,资金充足才会用得着这些工具或概念
青润 13:24:51
其实，任何项目都可以用。只是用的方式不同，用的过程不同而已。
青润 13:25:08
事情不能固定不变的去看，而应该根据实际情况进行调整和选择。这样才能做成。
狐狸糊涂 13:26:38
不同意飞蓝的看法。这些概念在任何项目中都是存在，或许已经使用了，只是并没有刻意的去作，所以自己不觉得吧。
飞蓝 13:29:25
这样说吧,有时候有些项目只是实现客户要求的功能,而人员有限,时间有限,你还去刻意建什么模呀,有个大致概念就会马上着手开发,不是这样吗,要不,现在做软件的怎么忙得经常加班
技术支持 13:29:53
比如说客户关心的是自己工作如何在计算机中表现，我们绘制的业务模型如果只是表现实际的业务流程。
这对客户来说是否没有价值。只是对我们了解目标组织的功能和结构有用。
狐狸糊涂 13:30:06
所以我说只是有时候并没有刻意的去作，但是还是有建模这个概念的
青润 13:30:44
你看了我书上的介绍了么？
给用户交流的除了业务用力外，还有一个部分，那就是界面原型。你所说的报表展现问题其实是界面原型的内容。
狐狸糊涂 13:31:34
业务建模对客户来说，他或许并不关心，一般他只关心他能看见的东西和他使用的东西。同意青润大哥的～：）
飞蓝 13:32:14
你们都是搞前期需求的吧
飞蓝 13:32:32
写需求书?
飞蓝 13:32:55
一般会有公司模板
技术支持 13:33:23
谢谢，基本明白。
技术支持 13:34:16
用例阐述在Rose里是用哪个工具写的，还是用Word等文字处理软件定好后导到Rose里？
飞蓝 13:34:40
ROSE也不会用
狐狸糊涂 13:34:43
可以用UML来描述用例哈。当然最好是图形＋文字的描述方式
青润 13:34:46
用word写。
不过，我的新的方法中已经把用例阐述改变了一种表达方式。
青润 13:35:20
通过uml的状态/活动图（泳道图）来表示用例阐述的内容，目前看起来效果也还不错。
飞蓝 13:35:28
画图用VISIO也行的
青润 13:36:17
visio画图还可以，但是不能用作分析设计。和rose以及together根本不是一个水平上的工具
青润 13:36:22
不能相提并论的。
青润 13:36:29
这一点，微软的人也都承认。
飞蓝 13:37:39
但是给客户的只是需求书而已
飞蓝 13:37:50
WORD文件
狐狸糊涂 13:38:09
难道你的word文件不能插入图表么？
青润 13:38:46
呵呵，实际情况未必只能这么做。给用户的可以有多种方式。其实用户看到的只是打印出来的纸，而不易定非要是所谓的“书”。
只要能说明问题，如何做，都是可以的。
飞蓝 13:40:38
把简单的事情做复杂啦,要看有没有时间和精力
青润 13:41:17
应该是尽量把复杂的事情做简单。
相反过多的使用不同的工具，反而会把简单的问题弄复杂。
飞蓝13:42:26
理论上正确
青润13:42:59
实践上也是正确的。使用的工具越多就会越麻烦。呵呵，人员需要了解的无用的东西也就越多。
