|
达到该目的的另一个方法就是研究一下对于 7000 slocs 的 C++代码需要多少测试用例(从场景派生而来)。这些测试用例不受单元测试层次的制约，并且在 Jones 91 和 Boeing 777 项目中有许多证据表明这个数字是安全的，至少它符合实践。这些来源表明在 250 到 280 之间是合适的。在一个完全不同的层次上，加拿大自动空中交通系统(Canadian Automated Air Traffic System ，CAATS)项目使用了 200 项系统测试(我私下里获悉的)。项目管理者联盟文章
用例的规模项目管理培训
用例应该具有多大规模呢?是否应该足够大以及表达足够的细节才能表达所需要的行为--这取决于与系统有关的用例复杂性、内部用例和外部用例。--这里我们就应该描述多少系统的内部动作来深入探讨一下这个问题。很明显，从外部行为描述来构建系统，要求将输出与输入关联起来。例如，如果行为对历史记录敏感并且很复杂，那么在没有系统内部的一些概念模型及行为的动作时，就很难描述它。注意，没有必要描述一个系统是如何从内部构建的--任何满足非功能性需求和匹配模型行为的设计就能够满足要求。
UML 1.3 中提供的定义是："用例【类】：一个系统可以执行的动作(包括变体)序列的说明，其中这些动作与系统参与者进行交互"。对复杂的行为的内部动作，可能合理的采用这个定义也可以在实现阶段再进行定义――这对于最终用户来说是个更远的步骤。业务规则也应该纳入到用例中以便约束参与者的行为(例如，在一个ATM系统中，银行需要有一条规则：在一次交易中，提取的金额不能超过 500 美元，无论账号中的余额为多少)。项目管理者联盟
根据这种解释，事件的用例流描述的页数可以为 2-20 。从计算的角度上看，具有简单行为的系统显然不需要冗长的描述。或许我们可以认为简单的商务系统通常用 2 到 10 页来描述，平均为 5 页。对于更复杂的系统来说，业务系统和科学系统在 6 到 15 页之间，平均为 9 页。复杂的命令和控制系统在 8 到 20 页之间，平均为 12 页(这些比率反映了相同规模系统的工作量与类型之间的非线性关系)，尽管我没有数据来支持这种观点。更富有表达力和描述性的形式(例如状态机或者活动图)可能需要更少的篇幅--我们仍旧倾向于加强文本，所以此处不讨论其他形式，毕竟相关资料很少或者根本没有。项目管理培训
与上述规模有系统差异的开发应该运用乘法规则来计算在这些假设基础上得出的每个用例的小时数(我建议增加一个 COCOMO -样式的成本驱动，该驱动是系统类型的(简单的业务类型、更复杂的类型、命令及控制类型等等)的观察到的平均规模或建议的平均规模。项目管理者联盟
用例规模的另一个方面是场景的数量。例如，一个 5 页长的用例可能是一个具有很多路径的复杂结构。再一次重申，需要将场景的数量以及这个比例估计为 30(这是我对于每个用例的场景数的初步估计)，将其作为成本的驱动因素。项目管理者联盟文章
得到的结果是，我们假设基于大约长度为 100 页说明的用例，对于任何给定层次的外部说明及补充说明来说，都是足够的。范围是 20 到 200 页之间(这些界限是模糊的)。注意，一个系统(子系统组)在最低的层次上的总数是 3-15 页/ ksloc(简单的业务系统)到 12-30 页/ ksloc(复杂的命令和控制系统)。这或许能够解释 Royce 98 表中的 14-9 和实际项目之间明显的矛盾之处，前者的工件所占用的篇幅非常少，而实际项目却占用了大量的页。本文的观点认为规格说明的层次不应受页数的限制。--Royce 是正确的，对于大型的、复杂的系统而言，重要内容的说明(如版本声明)可以达到范围的上限――200 页talent.mypm.net
子系统层次项目管理论坛
一个子系统层次看上去像什么呢?这里有一些我用过的简单的"标准"形式。注意，这些只是用来实现一个系统的概念形式。实际系统的范围超出了这些形式的集合，并且每个子系统外部用例的总和就是系统全部的外部用例;因此，一个实际的系统可能有超过 10 个外部用例，但是正如我们后面将要看到的那样，上限并不是无限的。注意，这里并不是建议所有的开发都在它们的描述中使用 4 层用例。小的系统(<5 万 slocs)可能只用 1 层或者 2 层。项目管理论坛
第一层项目管理者联盟
在第一层，具有通过零个或以上的子系统中的类实现的用例项目管理者联盟
一个 Pareto 式样的分布图项目管理论坛
 项目管理者联盟
在这一层估计系统(系统具有可通过类来实现的用例)规模的范围(使用7+或者-2的概念)：项目管理者联盟
2 到 9 个类(没有形成到子系统中)――1700 slocs 到 8000 slocs ，或者blog.mypm.net
由 5 个类组成的子系统，共计 4000 slocs项目管理者联盟
由 7 个类组成的子系统为 9 个，共计 53,550 slocsblog.mypm.net
范围为 2 到 76 个用例。这是个模糊的界限，至少对于上限来说是这样的――在该限定下，以这种方式构建一个系统(在这个规模上)，永远也不使用更高层的形式来表达所要求的行为，那么用例的数量应该降到零。如果用例的数字大于零，那么就是画蛇添足。项目管理者联盟
第二层项目管理者联盟
在第二个层次上，我们有一个由 8 个子系统组成的子系统组。我认为这等同于防御性术语中的计算机系统配置项(computer system configuration item ，CSC I)。在这一层，用例是通过子系统的协作来实现的：service.mypm.net
 项目管理论坛
在这一层估计系统规模的范围(使用 7+或者-2 的概念)：bbs.mypm.net
从由 5 个子系统(每个子系统有 5 个类)组成的子系统组，共计 22,000 slocs，到
9 个由 7 个子系统(每个子系统有7个类)组成的子系统组，共计 370,000 slocs。PgMp.mypm.net
|
