|
这就是说，外部用例的范围是 4 到 66。再次重申，这些只是模糊的界限。bbs.mypm.net
第三层www.mypm.net
在第三层，我们具有一个系统(由子系统组构成)。在这一层，用例是通过子系统组的协作来实现的：项目管理者联盟
 项目管理培训
在这一层估计系统规模的范围(使用 7+或者-2 的概念)：项目管理者联盟
从 1 个系统，由 5 个子系统组组成，每个子系统组又由 5 个子系统(每个子系统有5个类)组成，共计 11 万 slocs，到项目管理者联盟
9 个系统，每一个系统都由 7 个子系统组组成，每个子系统组又由 7 个子系统(每个子系统有 7 个类)组成，共计 260 万 slocs 的类组成。外部用例的范围是 3 到 58。再次重申，这些界限是模糊的。blog.mypm.net
第四层pmp.mypm.net
在第四层中，我们有一个由系统组成的系统。在这一层，用例是通过系统的协作来实现的：
 项目管理者联盟
在这一层估计系统规模的范围(使用 7+或者-2 的概念)：项目管理者联盟
从 1 个由 5 个系统组成的系统，每个系统是由 5 个子系统组组成，每个子系统组是由 5 个子系统(每个子系统有 5 个类)组成，共计 54 万 slocs，到项目管理者联盟
9 个由系统组成的系统，每个大系统由7个系统组成，每个系统由 7 个子系统组组成，每个子系统组由 7 个子系统(每个子系统有7个类)组成，共计 1800 万 slocs 的类组成。外部用例的范围是 2 到 51。再重申一次，这些界限是模糊的。
假设更大的聚合也是可能的，但是我实在不想再考虑了!service.mypm.net
每个用例的工作量项目管理者联盟
通过对每一层的额定的规模的工作量估计，我们可以对每个用例的工作量有一些深入了解。使用 Estimate Professional? 工具 (基于 COCOMO 2 和 Putnam's SLIM 模型)，将语言设置为 C++(其他成本驱动因素设置为额定值)，然后计算每一个示例系统类型在每个额定规模点的工作量(假设 10 个外部用例)，得到表 1。表中描述的 L1 和 L2 范围考虑到了单个用例的复杂度――使用 COCOMO 的代码复杂性矩阵通过类比进行估计。在 L2 层，我相信复杂性在被纳入系统类型的特征时复杂程度发生变化，因此一个更高层次的复杂命令和控制系统用例，将包含在一个较低的层次上复杂性的混合。在一个按照 log-log 比例的图上绘制这些数据，得到图 2。项目管理者联盟
 项目管理者联盟
 项目管理者联盟
从中我们可以看到，150-350 小时/用例(10 2.17-10 2.54)这个原来的 Objectory 数字在 L1 层上很适合，例如，这些用例可以通过类的协作来实现――因此存在一些理由来支持这个数字。然而，它不足以在分析中用来描述所有项目--我的一位同事曾在电子邮件与我交流时说：它太"片面" 了。项目管理者联盟
工作量估计项目管理者联盟
当前的实际系统不能与这些槽(slot)一一匹配。所以，为了帮助了解应该如何描述一个系统，我们将使用从该方法种得出的模糊的界限并将它们绘制出来：项目管理培训
Figure 3: 每个层次的规模范围
 项目管理者联盟
从图 3 中，我们可以看到一个超过 2.2 万 slocs 的系统最可能是在第一层描述，用例的数量在 2 到 30 之间。在这个规模上，更高的用例数量表明用例的粒度太细了。项目管理者联盟
规模在 2.2 万 和 5.4 万 slocs 之间的系统，应该使用一层用例和两层用例的混合，用例的数量在 4(都在第二层)和 76 都在第一层)之间，正如上图所表明的那样，一般不会出现极限值。项目经理圈子
|
