忧虑：公司的很多项目就是用rose来分析分析需求，画画USE CASE。
　

---

而且非常的不细致，导致开发过程中很多的业务不精确，开发往往要走歪路，很是郁闷，所以我想，是不是现在我们国内的很多公司的技术人员都还是非常的热衷于开发技术，对业务的分析和设计往往很不重视，觉得技术好了什么问题都能解决，实际上却忽略了如何对问题实施更好更快的解决。这样，工作效率很低，重复劳动很大，往往一个项目的周期会超出预算时间很多。
就我个人而言，我们公司似乎还没有想改变这种现状的想法，还是在依赖某个项目组的某些核心人员，需求、设计、全是这一个人在做，到了开发，加几个会编程的人就开始做了，当然，那些需求，设计等等文档写的真是惨不忍睹，这些归结到原因上，就成了他们嘴里的流程死板和个人习惯，“只要作出来就行了！”。
我不知道其他公司是怎么样的，上面的一些话可能有失偏颇。
我只是希望能真正的规范化我们的项目运作，提高我们的效率，减小我们的工作量，以及提高我们的产品质量。
在这里，也欢迎各位批评指正，和交流。

我97年和国内的一个教授--陈平（相信很多人知道他）合作，那时他就在用rose,不过它主要用那个来分析class 关系，加上他人手不够，需要自动大带生成功能。
至于use case等等，见仁见智，不太好说。
在最关键的architecture设计上，RUP/rose基本上讲了一些政治口号，个人觉得，这一方面应该改进（不知道rose现在支持不支持SPM,考分几个包，等等动作，那也叫设计构架，有点太虚）。
不过，会UML懂RUP找个好工作据说挺容易的：）

在我看来，use case为我们提供了一个很好业务分析的手段，而我们公司却没有真正的将其利用到需求分析当中，导致较多的业务都比较混乱，影响了开发进度和质量，就拿我们现在做的这个项目来说吧，前面的这套用户管理子系统完全失败了，本来一个简单的子系统花了近一个月的时间设计和开发，而且后者所花费时间比例占了近90%，结果系统割接后核心业务全都无法正常开展，没办法，只有推到重做，更可悲的是，这一次的重做在我们一个非常精通业务的同事配合下只花了4天的时间就完成了，并基本顺利的交付使用，我想我们不得不反思这个巨大的差异，当然这里面的原因是多方面的，但如果在第一次的需求分析中将这些业务分析清楚，分析细致，我想不会发生如此之大的差异。
在architecture设计上，我同意frankwoo的观点，ROSE在一方面做的不够实际，更像是完全按照uml设计的一套试验工具。

谢谢。
software architure design的设计思想好象是介绍的最少。一般的都是将讲口号。

 看来你们公司的确问题多多，如果继续走下去，一旦发生人员危机就很危险了。不过，在Rose的使用上，我有一些个人看法：
　

---

我觉得，通过Rose这个工具实际上可以完成很多事情，在于人——使用者，也在于工程，如果是Mis系统，我觉得，基本上都可以使用Rose完成它的需求描述、分析设计直至代码的导出，这个工具和这种方式给了我们一种很好的表述的方法，可以完全取代过去的纯文本的描述方式，使各个阶段的描述都更清晰，更易于表达，更容易理解。
所以，我个人是一致支持采用全程建模的方式实现全过程的，而不仅仅只在某一些阶段使用（而仅仅在某一些阶段使用这个工具的人很多时候，可以说是为了面子问题，是为了让用户或者其他人觉得自己很高明，而不是为了更好的解决问题——个人观点！）。

我认为采用什么工具和方式来描述需求或设计，这只是手段，只要表达的清楚，能用来有效的沟通就可以了（如果项目中的人员基本对某种方式熟悉，那么就可以采用该方式来表达），就是只有Word采用字也能描述的清楚，其实Rose的各种图形都有备注来让你描述得更准确和完整。
我觉得Rose的功能很强，从需求到生成代码，并且与文档的集成应用。我也使用过，并生成代码和数据库模型。如果只作为开发周期中某个阶段的表达工具，而不进行生成代码，我并不认为需要采用Rose，因为其它工具也已经足够了，只有能画出来吗。
其实，现在许多的客户对Use-Case并不熟悉，除非你能对他们进行培训，使他们能够通过Use-Case来沟通，否则，不要与客户通过Use-Case来沟通，可以用传统的方式或客户熟悉的方式。

我也是这么认同的。但考虑到客户和后期的开发，一个好的CASE工具是很有必要的。像ROSE确实不错，在这方面我需要加强。