基于用例的工作量估计Word文档下载推荐.docx
《基于用例的工作量估计Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《基于用例的工作量估计Word文档下载推荐.docx（16页珍藏版）》请在冰豆网上搜索。
Graham95和Graham98中包含了对于用例相当严格的批评（但是我并不完全理解为什么他认为他的想法和用例是大相径庭的），并且建议将"
任务场景"
作为克服用例问题的方法――包括它们的变化的长度和复杂度。
Graham的"
原子任务场景"
是"
任务点"
度量收集的基础。
原子任务场景存在的问题是它处于低层：
根据Graham的说法，它最理想的情况是作为一个单一的句子，并且如果仅仅使用本领域的术语那么不能更进一步进行分解。
根任务"
包含一个或者更多的原子任务场景，并且每一个根任务"
在初始化计划的类中，与一个系统操作正好对应"
（Graham98）。
这些根任务在我看来似乎非常像低层用例，并且这些原子任务场景如同是这样的用例中的步骤。
然而，这种层次方面的问题仍然没有解决。
Karner（Karner93）、Major（Major98）、Armour，以及Catherwood（Armour96）和Thomson（Thomson94）完成了其他方面的工作。
Karner的论文中指出了计算用例点的一种方法，但是该方法仍然假设这些用例是以一种通过类可以实现的方式来表达的（例如，在一种更合适的细节层次上而不是子系统上）。
那么，我们应该不使用用例来估计而依赖于所实现的分析和设计吗？
这个问题妨碍了做出估计的能力，并且无法满足已经采取该技术的项目管理者的要求――需要尽早估计并且不得不使用其他方法。
对于项目管理者来说，为了做项目规划，最好能够尽早获得评估，然后反复对其进行精化，而不是拖延评估并且毫无头绪地进行工作。
本文中描述了一个框架，在该框架中可以使用任何层次的用例来形成工作量估计。
为了展示这些观点，本文描述了一些简单的规范结构，这些结构具有相关的一定实践基础上的维度和规模。
本文中大多是大胆的（或者应该说缺乏根据的）推测，因为我没有其他的方法来解决这个领域中缺少的工作和数据的问题。
本文引用了"
互连系统构成的系统"
思想。
接下来，我将暂时撇开主题来介绍一些将我引入本文主题的一些背景想法。
避免功能分解吗？
功能分解的思想对于软件开发领域中的许多人来说像一个"
诅咒"
。
我对功能分解的体验更是其中的极端（在一个很大的数据流图中有3000个原始转换，五层或者六层深，在除了基础设施层外没有使用任何构架的思想的情况下完成），让我感到异常悲观。
在该用例中存在的问题不仅仅与功能分解思想有关，还和下面这种想法有关，即直到分解到功能的原始层次才描述一个进程。
在该层次上规格说明的长度应该少于一页。
所得到的结果难以理解――所需要的更高层次的行为如何从这些原始转换中显现出来，这一点很难搞清楚。
另外，功能结构如何映射到物理结构上来满足性能和其他质量方面的要求并不是特别明显。
这就产生了一种自相矛盾情况，我们一直进行分解直到达到了能够"
解决问题"
（原始层次）的那一层，但是，这些原始层是否能够实际上协同工作以满足更高层的目标却并不清楚或者可以被证明。
没有办法以这种方式来考虑非功能性需求。
从总体上讲，构架和基础设施（通讯，操作系统等等）都应该随着分解而不断演进，并且每一次分解都应该对其它分解产生影响。
那么Bauhaus规则"
形式服从功能"
又如何呢？
有许多好的设计源自功能主义方法，但也不乏一些不良设计。
例如，随处可见的平屋顶结构的使用。
如果您只关心屋顶的功能，并且将其完全设计为居民所需的一个房盖，那么至少在一些特定的领域中是不能够令人满意的。
这种屋顶很难防水，并且容易积雪。
现在这些问题可以解决了，但是在一个更大的范围内而不是在您已经选择的不同设计中。
尽管看上去有些过时，但是形式还是应该服从所有的功能和非功能性需求，以及后续的美学要求。
架构师面对的问题经常是非功能性需求经常表达模糊，并且过多的依赖于架构师的"
事情就应该是这样"
的经验。
因此如果功能分解仅仅用来驱动构架（即分解产生了几个向下的层次并且功能的原始层次与"
模块"
一一匹配）和定义其接口，那么将一无是处。
像这样的考虑使我确信，在完成构架工作之前，将用例向下分解到标准化的水平（这可以通过类的协作来实现），这没有任何意义。
对于一定规模的系统而言，这些分解确实必要，（参见Jacobson97）但是分解的标准和实施过程至关重要――特别是当功能分解不是足够好的时候。
系统考虑
系统工程师完成功能分析、功能分解和功能分配工作（当综合一项设计时），但是功能并不是系统构架的唯一驱动因素，一个专门的工程师团队就能够在评估不同的设计方面做出贡献。
IEEEStd1220，系统工程过程的应用和管理标准（StandardforApplicationandManagementoftheSystemsEngineeringProcess）在6.3节中描述了功能分解的使用，功能分析（FunctionalAnalysis）在6.3.1节，功能分解（FunctionalDecomposition），和系统产品解决方案等综合在6.5节中。
6.5.1节包含了一些特别有趣的内容，分组（Group）功能和分配（Allocate）功能，6.5.2节是物理解决方案的选择（PhysicalSolutionAlternatives）。
在6.3.1节中指出，分解是用来清晰地理解系统必须完成哪些功能，并且一般情况下一层分解就足够了。
注意，功能分解的目的并不是为系统定型（由综合工作来来完成定型），而是理解和沟通系统必须完成什么――功能模型是能够完成这些的好的方式。
在综合中，子功能首先被分配给解决方案的结构，然后评估这个解决方案――必须考虑所有的需求。
这种方法和多层功能分解之间的不同之处在于：
在每一层都试图描绘所要求的行为，并且在决定是否该行为在下一层需要被精化，以及分配到更低层的组件中之前，找到一种解决方案来实现它。
从中可以得出一个结论就是，在任何层次上使用数百个用例来描述行为是没有必要的。
可能很少量的外部用例（和相关场景）就能够恰当地覆盖所要描述的对象（系统、子系统、类）的行为。
我应该讲一下我所说的外部用例是指什么。
举一个由子系统组成的系统例子，这些子系统又由类组成。
描述系统及其参与者的用例，我称之为外部用例。
子系统或许有它们自己的用例――它们对于系统来说是内部用例，但是对于子系统来说是外部用例。
最终用来构建一个庞大系统（大于100万行代码）的外部用例和内部用例的总数，可能数以百计，因为这样规模的系统将包含其它系统，或者至少包含子系统。
对结构和规模的假定
用例的数量
在IBMRational中，我们认为用例的数量应该很小（10－50个），并且认识到大量（超过100个）的用例表明可能需要进行功能分解，在功能分解中用例对于参与者毫无价值。
然而，在实际项目中我们仍然能够发现大量的用例，并不总是"
糟糕的"
，至少在层次上是全面的。
例如，在Rational内部的电子邮件中，作者引用了一个Ericsson例子：
●Ericsson，对大部分的新一代电话交换机的建模，估计要多于600个人年（最多，3到400个开发人员），200个用例（使用不止一层用例，请参考"
）对于一个超过600人年（这有多大呢？
150万行C++代码吗？
）的系统，恐怕用例分析会限于子系统上面的某一层上（也就是说，如果一个人定义了一个7000到10000行代码的子系统），否则用例的数量还会增加。
因此，我仍然强调这种观点即少量的外部用例是适合的。
为了匹配我曾经建议的结构和规格，我断言10个外部用例，每个用例带有30个相关场景，这对于描述行为是合适的。
如果实际中用例的数量超过了10个，并且确实是外部用例，那么它们所描述的系统要比相应的规范系统具有更大规模。
在下文中我将提供一些支持理由来说明这些数字是合理的。
结构分层
建议的结构分层如下：
●4-多个系统组成的系统
●3-系统
●2-子系统组
●1-子系统
●0-类
类和子系统在UML中定义为；
在UML中更大的聚合是子系统（包含子系统），为了更简单的进行描述，我进行了不同的命名。
对于那些知道2167和498军方标准（称子系统为CSC，称类为CSU）中的术语的人来说，子系统组（subsystemGroup）的规模用CSCI-来表示。
我记得，经过2167天的关于Ada的结构应该映射到哪一层次的争论后，尘埃落定，Ada包通常映射为CSU。
我并不建议系统必须严格的遵循这种层次结构，还将存在层次之间的混合，这种层次结构使我能够更好地了解规模对于每个用例工作量的影响。
在每一层上都会有用例（尽管对于单个的类可能不是这样），但并不是单纯的大量细节堆砌，而是用例针对那个层上的每个组件（例如子系统、子系统组，等等）。
在上文中我曾断言对于每一层的每一个组件都有10个用例――如果用例的描述平均是10页，那么将会给出一个潜在的、大约100页长度的说明文档（还要加上类似的或者少一些的关于非系统性需求的相应说明），这是Stevens98提倡的数字，并且和Royce98推荐的数字很接近。
但是为什么是10个用例呢？
为了得出这个数字，基于对每一个子系统的类的数量、类的规模、操作规模等等我认为的合理的规模，我进行了自下向上的推理。
这些和其他假设共同搜集在下表中供大家引用。
我没有大量的经验数据－贯穿文中的是琐碎的、分散的数据，Lorentz94和Henderson-Sellers96有一些数据，我也有一些在澳大利亚的项目中得出的数据，主要是在军用航空航空领域。
任何情况下，在这个阶段，将框架或多或少的定位到合适的位置是非常重要的。
分层结构中组件的大小
这里我应该指出的是，我曾经使用代码行来度量组件的大小，但许多人不喜欢这种度量。
这些是C++（或者相同层次的语言）代码行，所以，要回到功能点非常容易。
在容器中的类的数目和能表达的行为的丰富性之间肯定有许多关系。
我选择了8个类/子系统，8个子系统/子系统组，8个子系统组/子系统，等等。
那么为什么是8个呢？
1.它在7或－2之间；
2.由于每个类有850slocs（每70slocs有12个操作）的C++代码，它得出了一个子系统的规模是7000slocs－一个可以由小的团队（3－7人）在4－9个月就能够交付的功能/代码的程序块，其中系统的迭代长度就该调整到30万－100万slocs（RUP99）的范围内。
那么，多少用例能够表达八个类的行为（外部的）？
，哪些是属于子系统的并且已经被定位在子系统中了？
决定丰富性的原因不仅仅是用例的数量，还有每个用例的场景数量。
现在，并没有多少方法来指导场景/用例扩展――在Booch98中，GradyBooch指出"
存在一个从用例到场景的"
膨胀系统"
，一个复杂度适当的系统中可能有几十个用于捕获系统行为的用例，每个用例可能具有几十个场景…."
，BrucePowelDouglass在Douglass99中指出，"
….为了详细描述用例需要很多场景，通常需要1打到几打"
我选择了30个场景/用例――这处于"
几打"
的较低的一边，但是Rechtin（在Rechtin91中）指出，工程师能够处理5到10个互相作用的变量（对于这个变量，我解释为互相协作的5到10个类）并且10到50种交互（我解释为场景）。
以这种方式解释，多个用例即为该变量空间的多个实例。
因此，10个用例，每个用例30个场景，也就是说一共300个场景（后面将导致大约300个测试用例）对于覆盖8个类的有意义的行为来说已经足够了。
是否有其他的迹象表明这是个合理的数字呢？
如果应用Pareto的80-20规则，那么20%的类将表达80%的功能，同样，80%的功能将被每个类中20%的操作来表达。
让我们保守的说，我们需要20%的类（等）来达到75%的功能并且通过这点来构建一个Pareto分布图。
（图1）
图1:
一个Pareto式样的分布图
如果我们想要描述80%的系统行为，并且将Pareto规则应用到类、操作和场景数量方面，那么对于每一者都需要描述其行为的93%（0.933＝0.8）－－也就是对于每一个都需要50%，例如，4个类和5个操作（=（12－2构建器/析构器）/2）。
节点树的不同分叉的数量可能达到数千个（其中节点树用来代表4个类及每个类5个操作的执行模式）。
我为每个节点创建了1到3个链接，假设在顶层有10个操作（接口操作）的层次结构，并且形成了一个三层的树。
这将会有1000条路径或者场景。
所以，500个场景将会得到93%的覆盖。
使用300个场景（用相同的假定）我们可以得到73%的覆盖。
根据一个选定的算法，可以对这个树进行修剪，从而删除冗余的行为说明，甚至更少的数量就完全可以符合要求。
达到该目的的另一个方法就是研究一下对于7000slocs的C++代码需要多少测试用例（从场景派生而来）。
这些测试用例不受单元测试层次的制约，并且在Jones91和Boeing777项目中有许多证据表明这个数字是安全的，至少它符合实践。
这些来源表明在250到280之间是合适的。
在一个完全不同的层次上，加拿大自动空中交通系统（CanadianAutomatedAirTrafficSystem，CAATS）项目使用了200项系统测试（我私下里获悉的）。
用例的规模
用例应该具有多大规模呢？
是否应该足够大以及表达足够的细节才能表达所需要的行为－－这取决于与系统有关的用例复杂性、内部用例和外部用例。
－－这里我们就应该描述多少系统的内部动作来深入探讨一下这个问题。
很明显，从外部行为描述来构建系统，要求将输出与输入关联起来。
例如，如果行为对历史记录敏感并且很复杂，那么在没有系统内部的一些概念模型及行为的动作时，就很难描述它。
注意，没有必要描述一个系统是如何从内部构建的－－任何满足非功能性需求和匹配模型行为的设计就能够满足要求。
UML1.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（复杂的命令和控制系统）。
这或许能够解释Royce98表中的14－9和实际项目之间明显的矛盾之处，前者的工件所占用的篇幅非常少，而实际项目却占用了大量的页。
本文的观点认为规格说明的层次不应受页数的限制。
－－Royce是正确的，对于大型的、复杂的系统而言，重要内容的说明（如版本声明）可以达到范围的上限――200页
子系统层次
一个子系统层次看上去像什么呢？
这里有一些我用过的简单的"
标准"
形式。
注意，这些只是用来实现一个系统的概念形式。
实际系统的范围超出了这些形式的集合，并且每个子系统外部用例的总和就是系统全部的外部用例；
因此，一个实际的系统可能有超过10个外部用例，但是正如我们后面将要看到的那样，上限并不是无限的。
注意，这里并不是建议所有的开发都在它们的描述中使用4层用例。
小的系统（<
5万slocs）可能只用1层或者2层。
第一层
在第一层，具有通过零个或以上的子系统中的类实现的用例
在这一层估计系统（系统具有可通过类来实现的用例）规模的范围（使用7＋或者－2的概念）：
∙2到9个类（没有形成到子系统中）――1700slocs到8000slocs，或者
∙由5个类组成的子系统，共计4000slocs
∙由7个类组成的子系统为9个，共计53,550slocs
范围为2到76个用例。
这是个模糊的界限，至少对于上限来说是这样的――在该限定下，以这种方式构建一个系统（在这个规模上），永远也不使用更高层的形式来表达所要求的行为，那么用例的数量应该降到零。
如果用例的数字大于零，那么就是画蛇添足。
第二层
在第二个层次上，我们有一个由8个子系统组成的子系统组。
我认为这等同于防御性术语中的计算机系统配置项（computersystemconfigurationitem，CSCI）。
在这一层，用例是通过子系统的协作来实现的：
在这一层估计系统规模的范围（使用7＋或者－2的概念）：
∙从由5个子系统（每个子系统有5个类）组成的子系统组，共计22,000slocs，到
∙9个由7个子系统（每个子系统有7个类）组成的子系统组，共计370,000slocs。
这就是说，外部用例的范围是4到66。
再次重申，这些只是模糊的界限。
第三层
在第三层，我们具有一个系统（由子系统组构成）。
在这一层，用例是通过子系统组的协作来实现的：
∙从1个系统，由5个子系统组组成，每个子系统组又由5个子系统（每个子系统有5个类）组成，共计11万slocs，到
∙9个系统，每一个系统都由7个子系统组组成，每个子系统组又由7个子系统（每个子系统有7个类）组成，共计260万slocs的类组成。
外部用例的范围是3到58。
再次重申，这些界限是模糊的。
第四层
在第四层中，我们有一个由系统组成的系统。
在这一层，用例是通过系统的协作来实现的：
∙从1个由5个系统组成的系统，每个系统是由5个子系统组组成，每个子系统组是由5个子系统（每个子系统有5个类）组成，共计54万slocs，到
∙9个由系统组成的系统，每个大系统由7个系统组成，每个系统由7个子系统组组成，每个子系统组由7个子系统（每个子系统有7个类）组成，共计1800万slocs的类组成。
外部用例的范围是2到51。
再重申一次，这些界限是模糊的。
假设更大的聚合也是可能的，但是我实在不想再考虑了！
每个用例的工作量
通过对每一层的额定的规模的工作量估计，我们可以对每个用例的工作量有一些深入了解。
使用EstimateProfessional?
工具（基于COCOMO2和Putnam'
sSLIM模型），将语言设置为C++（其他成本驱动因素设置为额定值），然后计算每一个示例系统类型在每个额定规模点的工作量（假设10个外部用例），得到表1。
表中描述的L1和L2范围考虑到了单个用例的复杂度――使用COCOMO的代码复杂性矩阵通过类比进行估计。
在L2层，我相信复杂性在被纳入系统类型的特征时复杂程度发生变化，因此一个更高层次的复杂命令和控制系统用例，将包含在一个较低的层次上复杂性的混合。
在一个按照log-log比例的图上绘制这些数据，得到图2。
图2:
用例工作量规模图
从中我们可以看到，150-350小时/用例（102.17-102.54）这个原来的Objectory数字在L1层上很适合，例如，这些用例可以通过类的协作来实现――因此存在一些理由来支持这个数字。
然而，它不足以在分析中用来描述所有项目－－我的一位同事曾在电子邮件与我交流时说：
它太"
片面"
了。
工作量估计
当前的实际系统不能与这些槽（slot）一一匹配。
所以，为了帮助了解
升级会员 