2007-9-26  20:31:55  mybyte：  我现在感觉比较困惑，公司想做产品化的工作，由我来负责，原来的产品化很低，很多事情都在重复的做，老师你觉得我应该先从哪方面下手改进 
2007-9-26  20:32:44  mybyte：  个人感觉在需求和设计上很有问题，复用度太低 
2007-9-26  20:35:10  潘：  需求和设计都要下手。需求上需要老总作出明确定位，根据定位强化核心需求，砍掉次要需求。设计需要向更抽象的级别重构 
2007-9-26  20:38:42  mybyte：  我们的产品化其实根据项目来产品化，我的想法是拿到项目后根据项目来进行产品化的工作，抽取核心需求，对这个些需求进行组件化的设计。 
2007-9-26  20:43:55  mybyte：  原来我们的设计很弱，经常为了救火到处打补丁，到最后代码都改的很难控制，我想采用类似外包公司的方式的设计方式，即设计很细，在设计上进行控制 
2007-9-26  20:46:29  mybyte：  但是公司老员工都的培训使用EA 来需求和设计，难度不小 
2007-9-26  20:48:03  潘：  产品中，设计的细，关键不在细到实现，而是在业务内涵里切割出合适的接口 
2007-9-26  20:48:37  潘：  架构师的功力很重要 
2007-9-26  20:49:01  mybyte：  正在招架构师，呵呵 
2007-9-26  20:51:06  mybyte：  感觉EA，没有ROSE 好用 
2007-9-26  20:51:40  潘：  Rose 没有UML2.0 
2007-9-26  20:52:29  mybyte：  是的，rose 到2003 后就没有，被IBM 收购后就变味了 
2007-9-26  20:56:14  mybyte：  老师业务建模，只关心业务需求，需求规格说明书就关心到系统需求是吗？ 那是不是做与其他系统接口应用的系统，是不是业务建模这块就可以不做了 
2007-9-26  20:57:31  潘：  不是啊，业务建模一样有好处，参见业务建模各幻灯片的例子，如迅雷例子 
2007-9-26  21:05:07  mybyte：  我们公司的客户是移动和联通，可能用户水平比较高，经常是他们要求系统要求什么、什么功能，忽略业务建模阶段，如果客户对需求很了解的话，是对系统需求启到很好的作用，有时有些
客户自认为是正确的事情，其实存在问题，我们提醒也不听，导致按照他的要求做了后最后还得改成我们建议的方式，这种事情往往是最耗工作量的 
2007-9-26  21:06:36  潘：  客户不是一块铁板啊，也许和你谈话的"客户"，只是联通里面的一个小干部，小小涉众而已。对他来说正确，对老大来说就不正确了 
2007-9-26  21:10:23  mybyte：  但是老大基本上是不会管具体事情，在需求阶段时也很难得到他的确认，等到后期出现问题时他可能会出现 
2007-11-13  18:07:20  mybyte：  老师用例文档是要与用户确认的，但是用例文档中有比如"执行者"、"字段"， 这些字眼是不是有冲突呀 
2007-11-13  18:18:04  潘：  那你就改成用户能接受的形式 
2007-11-13  18:18:19  潘：  "视图"和"模型"分开 
2007-11-13  20:41:20  mybyte：  不是很明白 
2007-11-13  20:42:10  mybyte：  "视图"和"模型"分开这个不是很明白 
2007-11-13  20:45:07  潘：  需求模型是用例文档，这个只有一个，但和各类涉众交流的时候，你要用各种形式和他交流－－我们课上说过的 
2007-11-13  20:46:30  mybyte：  哦，这个到是明白了些 
2007-11-13  20:47:20  mybyte：  就是"见人说人话，见鬼说鬼话" 呵呵 
2007-11-13  20:47:32  潘：  是啊 
2007-11-13  20:51:16  mybyte：  每个涉众关心点都不同，所以对每个涉众说的东西着重点不同，对于一个系统，如果牵涉到很多部门的话，方案和需求都要对他们所关心的问题都有体现 
2007-11-13  20:53:00  潘：  涉众排序，关注前排涉众的看法 
2007-11-13  20:54:26  mybyte：  这点很重要 
2007-11-13  20:58:35  mybyte：  谢谢，老师