黑暗中摸索，UP实践

用例驱动的问题其实很复杂，我这里只能简单的说解释一下。为什么说用例也是构架的一个部分呢？其实你看UP中对构架的解释，那里就说到一个视图是用例。简单说用例为构架提供了功能性的理由，并且用例其实也为结构提出了一个高层次的理念参照系统。这些都是比较明显的。其实还有一个方面是比较隐秘的，那就是开发过程也是用例驱动的。这里有两个方面的内容，一个是需要用例来制定计划，部署资源等等。而另外一个方面是，用例之过程的的理由和约束的前提。比如你要搞一个文档，那么为什么你需要这个文档，并不是说你的过程要求你必须有这个文档，而是你的用例需要这个文档来完成它。比如你要搞一个测试，并不是你的程序需要测试，也不是客户要求你必须测试，而是你的用例自身需要通过某些检查来验证其自身。这一点是我以前很少意识到，也是我在其他地方没有看到过的。我仅仅是在最近研究RUP文件的时候，才注意到的，并且这一点在《统一软件开发过程》中有解释的。这也就是我说任何工作都需要从用例里面找到理由和原因的意思。 同时我要对构架的问题在多做解释。其实我们谈构架的时候，很多情况下混淆了构架和构架基线的概念。构架基线，自然是越来越稳定，并且后期很少变更。但是请注意构架基线不变更，并不代表构架不变更。而且越是后期构架的越是应该清晰，越是应该明确，越是应该被加强。也就是说构架也不是一个前期就设定好了，就很少变化的东西，而是一个随着你的开发过程的进步，不断的被强化被清晰被明确表达的过程。这一点非常的重要。 另外我觉得引入一个方法，最好要找一个突破口，然后一步一步前进，而不是一下子就铺开一个大的阵势，全面实施。比如你这里其实我看主要的就是实施了迭代，其他方面都是次要和辅助的。而你们的组织应该总结这个方面的内容，并在下一个阶段继续加强。然后在迭代的过程中，逐步使引入其他的实践。

RUP的问题在于，很容易在某些方面造成误解，其自身的说明非常不明确。主要是摊子铺的太大，概念太多，容易迷失。并且实施过程也不能很明快而短期实现，所以见效会比较慢。至少CMM可以做到很多方面都明确而具体。

恩，受教。我觉得如果裁剪得当，对于项目组来说上面的问题应该可以很大程度的降低。但裁剪却又是一件不容易的事情。

另外，似乎就只有你在帮忙传道解惑啊。怎么没有其它人来参与呢？都搞敏捷去了是吧。呵呵。

为啥说要裁剪，裁剪的理由是啥——用例。别人都不喜欢玩虚的，只有我比较虚罢了。嘿嘿