本文发表在 rolia.net 枫下论坛以前没有相关business经验， 在这个领域的项目几乎就不可能新手来做。象金融，证券，保险等都是非常专业的。但是现在采用这些标准化的Process，和工具， 与非常有经验的团队相比，差别应该缩小很多。
不管怎么说， 这些都是best practice, 也就是经验的浓缩。但是要怎么消化这个浓缩果汁， 怎么用好best practice？ 又需要一层经验。
经典的Design pattern都有很多applicable & not applicable, 可以说明得很透彻了。 但是对应RUP和UML的applicable & not applicable还差得很远。 希望大家能一起交流经验。
现在我就有2个问题， 一个请看帖子 #1347180。
第二个问题是我在国内网站交流时，别人问的一个问题： 如何把设计阶段的“拆分package”和分析阶段（System analyze 不是 requirement analyze）的Use case挂起钩来？ 目的是尽量使一个use case使用最少量的Package, 否则Package和use case交叉太多， 系统就会很凌乱，测试的时候，或者给程序员分工的时候就会遇到麻烦。
其实这个问题也和第一个问题有关：如何掌握System Use case的细度。只要够细，packaging的时候对系统的了解就足够， 设计的时候就不容易交叉太多。 但是太细了， elaboration阶段化太多时间和精力，把这个阶段当作construction就麻烦了。
当然反过来说， 如果第二个问题搞清楚， 对第一个问题也有一部分解答：Use case的细度作到对整个系统有足够的了解即可，或者作到对packaging有把握就好。
需要很多实例分析。 有什么相关的书讲这个吗？更多精彩文章及讨论，请光临枫下论坛 rolia.net
不管怎么说， 这些都是best practice, 也就是经验的浓缩。但是要怎么消化这个浓缩果汁， 怎么用好best practice？ 又需要一层经验。
经典的Design pattern都有很多applicable & not applicable, 可以说明得很透彻了。 但是对应RUP和UML的applicable & not applicable还差得很远。 希望大家能一起交流经验。
现在我就有2个问题， 一个请看帖子 #1347180。
第二个问题是我在国内网站交流时，别人问的一个问题： 如何把设计阶段的“拆分package”和分析阶段（System analyze 不是 requirement analyze）的Use case挂起钩来？ 目的是尽量使一个use case使用最少量的Package, 否则Package和use case交叉太多， 系统就会很凌乱，测试的时候，或者给程序员分工的时候就会遇到麻烦。
其实这个问题也和第一个问题有关：如何掌握System Use case的细度。只要够细，packaging的时候对系统的了解就足够， 设计的时候就不容易交叉太多。 但是太细了， elaboration阶段化太多时间和精力，把这个阶段当作construction就麻烦了。
当然反过来说， 如果第二个问题搞清楚， 对第一个问题也有一部分解答：Use case的细度作到对整个系统有足够的了解即可，或者作到对packaging有把握就好。
需要很多实例分析。 有什么相关的书讲这个吗？更多精彩文章及讨论，请光临枫下论坛 rolia.net