基于用例的工作量估计 (1)

　　在容器中的类的数目和能表达的行为的丰富性之间肯定有许多关系。我选择了 8 个类/子系统 ，8 个子系统/子系统组，8 个子系统组/子系统，等等。那么为什么是 8 个呢?

　　1. 它在 7 或-2 之间;

　　2. 由于每个类有 850 slocs(每 70 slocs 有 12 个操作)的 C 代码，它得出了一个子系统的规模是 7000 slocs-一个可以由小的团队(3-7人)在 4-9 个月就能够交付的功能/代码的程序块，其中系统的迭代长度就该调整到 30 万-100 万slocs (RUP 99) 的范围内 。

　　那么，多少用例能够表达八个类的行为(外部的)?，哪些是属于子系统的并且已经被定位在子系统中了?决定丰富性的原因不仅仅是用例的数量，还有每个用例的场景数量。现在，并没有多少方法来指导场景/用例扩展――在Booch 98中，Grady Booch 指出"存在一个从用例到场景的"膨胀系统"，一个复杂度适当的系统中可能有几十个用于捕获系统行为的用例，每个用例可能具有几十个场景…."，Bruce Powel Douglass 在 Douglass 99 中指出，"….为了详细描述用例需要很多场景，通常需要1打到几打"。我选择了 30 个场景/用例――这处于"几打"的较低的一边，但是 Rechtin(在 Rechtin 91中)指出，工程师能够处理 5 到 10 个互相作用的变量(对于这个变量，我解释为互相协作的 5 到 10 个类)并且 10 到 50 种交互(我解释为场景)。以这种方式解释，多个用例即为该变量空间的多个实例。

　　因此，10 个用例，每个用例 30 个场景，也就是说一共 300 个场景(后面将导致大约 300 个测试用例)对于覆盖 8 个类的有意义的行为来说已经足够了。是否有其他的迹象表明这是个合理的数字呢?如果应用 Pareto 的 80-20 规则，那么20%的类将表达80%的功能，同样，80% 的功能将被每个类中20%的操作来表达。让我们保守的说，我们需要20%的类(等)来达到75%的功能并且通过这点来构建一个 Pareto 分布图。(图 1)

　　图 1: 一个 Pareto 式样的分布图

上一页  [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]  ... 下一页  >>