要彻底贯彻RUP 好像有一定的难度。
希望研究 RUP 的朋友跟我交流 el_sinsia@hotmail.com

我想，问题谈到RUP应该是讲这个把：
1。利用不断细化的Use case来制定项目的下一目标
2。利用已经制定的Use cases,来验证项目某个阶段的成果。

RUP不存在单独的设计阶段吧。 是指elaberation阶段？还是每个iteration中coding之前的设计阶段？

 一些想法, 和大家共享.
　

---

问题:
就我的理解，它是用例和构架相互驱动的，用例决定架构，架构实现用例，也是一个
> 迭待过程。
>
但是我在实际应用中我不能很好的把握。很多项目的架构是定死了的，如开发网站时候
>
，用到界面层，商业外观，商业规则，数据访问，系统框架，这几个层次。这导致我在
>
分析阶段很容易陷入迷茫状态，因为我觉得在分析阶段我应该尽可能的了解用例，发掘
> 高次的对象，但我有时侯过早的陷入设计，导致后来的分包不科学。
> 这可能是我经验太少，应用ＲＵＰ经验不够多吧。
>
如果哪个公司有一支优良的团队，包括构架设计师，用况分析师，构件工程师。我想
>
这样的开发环境肯定是非常快乐的。可惜我们公司没有，软件开发还停留在远古时代，
> 你呢？
> 　
>
　还有一个棘手的问题想请教。我发现很多后期的一个包其实为很多用例服务的，一个
>
用例也可能要调用很多包。不能一对一　。一般用例我好像没把他们分过包。如果要分
>
，是不是意味者　用例划分　和　分析设计阶段　类的划分　没有必然的联系呢。是不
> 是用例的划分回影响到分析时类的划分呢？
--------------------------------------------

RUP is a light weight process. It's trying to cover the common area
of most kinds of software project.
如何掌握设计和分析的分界，不同的项目可能大不相同。RUP也无法概括，只能建议利用不断的iteration来修正，architect必须善于辨别项目的核心功能或者模块，尽早解决high
risks, 这样就能避免大量工作已经完成后才发现要做根本性的改变。
RUP无法提供具体如何辨别核心和高风险模块的制导方针，每个项目各不相同。
它提供的这个process也不是帮助你找到这个核心项目，而是帮助项目组避免风险的积累。按照这个理解,您的问题应该是没有找到核心或者高风险的use
case和模块,并且尽早对其设计甚至implement. 如果这样做了,
packaging到后期就不应该变化很大.

同一类项目(可以按照行业分,也可以按c/s 还是 n-tiers
分,多种分类方法)一般都有类似的 risks, 一般来说,只有靠经验来获得.
但是CMM提供一个途径来对Project的各个方面进行量化,
经过对这些量化数据的分析,
项目组能够更迅速,更有效地找到改进方向.
不管是什么原因造成项目质量不高,项目经理能找到影响最大的问题加以解决.
针对您的问题:
假如重新分包对整个项目影响不大(比如重新分包1~2天可以完成),
项目经理就不必太在乎这个,在每个iteration快结束时,安排1~2人花1天左右改动分包.
当然前提是对原来分包存在的问题有文档tracking,
同时这些改动必须以高级别消息通知所有的项目成员. 个人觉得, 对java来说,
packaging
变化了, 编译的时候都会发现问题, 配合比较完善的configuration management,
应该比较容易解决.
虽然这个改动比较烦人,但是不应该对项目整体造成太大的影响.
重点是改动前后的communication.

use
case是很不OO的,它是一个需求分析工具,不是设计工具,
没必要在这个上面和packaging挂钩. 如果希望在分析阶段把握packaging,
应该是domain
modeling需要多花点心思.