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

　　注意，功能分解的目的并不是为系统定型(由综合工作来来完成定型)，而是理解和沟通系统必须完成什么――功能模型是能够完成这些的好的方式。在综合中，子功能首先被分配给解决方案的结构，然后评估这个解决方案――必须考虑所有的需求。这种方法和多层功能分解之间的不同之处在于：在每一层都试图描绘所要求的行为，并且在决定是否该行为在下一层需要被精化，以及分配到更低层的组件中之前，找到一种解决方案来实现它 。

　　从中可以得出一个结论就是，在任何层次上使用数百个用例来描述行为是没有必要的。可能很少量的外部用例(和相关场景)就能够恰当地覆盖所要描述的对象(系统、子系统、类)的行为。我应该讲一下我所说的外部用例是指什么。举一个由子系统组成的系统例子，这些子系统又由类组成。描述系统及其参与者的用例，我称之为外部用例。子系统或许有它们自己的用例――它们对于系统来说是内部用例，但是对于子系统来说是外部用例。最终用来构建一个庞大系统(大于 100 万行代码)的外部用例和内部用例的总数，可能数以百计，因为这样规模的系统将包含其它系统，或者至少包含子系统。

　　对结构和规模的假定

　　用例的数量

　　在 IBM Rational 中，我们认为用例的数量应该很小(10-50 个)，并且认识到大量(超过100 个)的用例表明可能需要进行功能分解，在功能分解中用例对于参与者毫无价值。然而，在实际项目中我们仍然能够发现大量的用例，并不总是"糟糕的"，至少在层次上是全面的。例如，在 Rational 内部的电子邮件中，作者引用了一个 Ericsson 例子：

　　Ericsson，对大部分的新一代电话交换机的建模，估计要多于 600 个人年(最多，3 到400 个开发人员)，200 个用例(使用不止一层用例，请参考"互连系统构成的系统")对于一个超过 600 人年(这有多大呢?150万行 C 代码吗?)的系统，恐怕用例分析会限于子系统上面的某一层上(也就是说，如果一个人定义了一个 7000 到 10000 行代码的子系统)，否则用例的数量还会增加。

　　因此，我仍然强调这种观点即少量的外部用例是适合的。为了匹配我曾经建议的结构和规格，我断言 10 个外部用例，每个用例带有 30 个相关场景 ，这对于描述行为是合适的 。如果实际中用例的数量超过了 10 个，并且确实是外部用例，那么它们所描述的系统要比相应的规范系统具有更大规模。在下文中我将提供一些支持理由来说明这些数字是合理的。

　　结构分层

　　建议的结构分层如下：

　　4 - 多个系统组成的系统

　　3 - 系统

　　2 - 子系统组

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