工作量估计.docx

《工作量估计.docx》由会员分享，可在线阅读，更多相关《工作量估计.docx（19页珍藏版）》请在第一文库网上搜索。

1、基于用例的工作量估量本文描述了基于用例进行评估的一个框架。为了使描述更加具体，本文为框架的参数选择了一些值，尽管这些值有待于论证，但它们并不总是错误的。像平常一样，随着数据的搜集，这种估量应当依据实际状况和重新估量的参数值进行测试。这种框架对于不同种类的系统考虑了用例层次、规模和简单度等思想，并且不再实行细粒度的功能分解。为减轻计算的负担，对于诸如Estimate Professional这样的工具，可以构建一个前端，从而供应一种基于用例的规模输入的不同的方法。问题直观上看起来好像依据用例模型的特征，可以对开发工作所需的规模和工作量进行估量。究竟，用例模型捕获了功能性需求，那么莫非不应当有基于

2、等价于功能点的用例吗？这里存在很多困难： 有很多不同的用例规格样式和形式，很难定义一个度量标准，例如，某人可能盼望能够度量用例的长度； 用例应当代表外部参加者对于系统的观点，因此，500,000 sloe系统的用例就与5,000 sloe子系统的用例在完全不同的层次上（Cockburn 97争辩了层次和目标的概念）; 用例可能在简单性方面不同，编写时是显式的，实现时又是隐式的。 用例应当从参加者的角度来描述行为，但是这可能相当简单，特殊是当系统具有状态时（绝大多数状况是这样的）。所以描述这种行为需要系统的模型（在实现它们之前）。当试图捕获行为本质时，这将导致过多的功能分解层次和细节。所以，为了

3、能够进行评估，是否有必要实现一些种类的用例呢？或许是对于直接依据用例进行估量的期望过高，并且在功能点和用例点的概念之间直接划等号对我们产生了误导。功能点数量的计算无论如何都需要一个系统模型。从用例描述中派生的功能点需要达到与用例表达全都的层次，并且只有达到该层次时，我们才能够对功能点的数量有信念。Feteke 97描述了一种从用例到功能点的映射，但是，用例的层次必需适当，这样映射才能有效。其他的方法使用基于类或基于对象的度量标准作为来源，PRICE Object Points就是一个这样的例子(Minkiewicz 96)。其他工作在描述和形式化用例方面的工作相当完备一一Hurlbut 97对

4、此有很好的概括。而从用例中派生估量的度量标准却寥寥无几。Graham 95和Graham 98中包含了对于用例相当严格的批判(但是我并不完全理解为什么他认为他的想法和用例是大相径庭的)，并且建议将“任务场景”作为克服用例问题的方法一一包括它们的变化的长度和简单度。Graham的“原子任务场景“是任务点”度量收集的基础。原子任务场景存在的问题是它处于低层：依据Graham的说法，它最抱负的状况是作为一个单一的句子，并且假如仅仅使用本事域的术语那么不能更进一步进行分解。Graham的“根任务”包含一个或者更多的原子任务场景，并且每一个根任务”在初始化方案的类中，与一个系统操作正好对应“(Graha

5、m98)。这些根任务在我看来好像特别像低层用例，并且这些原子任务场景犹如是这样的用例中的步喉。然而,这种层次方面的问题仍旧没有解决。Karner (Karner93) Major (Major98) Armour,以及Catherwood (Armour96)和Thomson (Thomson 94)完成了其他方面的工作。Karner的论文中指出了计算用例点的一种方法，但是该方法仍旧假设这些用例是以一种通过类可以实现的方式来表达的(例如，在一种更合适的细节层次上而不是子系统上)。那么，我们应当不使用用例来估量而依靠于所实现的分析和设计吗？这个问题阻碍了做出估量的力量，并且无法满足已经实行该技术

6、的项目管理者的要求一一需要尽早估量并且不得不使用其他方法。对于项目管理者来说，为了做项目规划，最好能够尽早获得评估，然后反复对其进行精化，而不是拖延评估并且毫无头绪地进行工作。本文中描述了一个框架，在该框架中可以使用任何层次的用例来形成工作量估量。为了展现这些观点，本文描述了一些简洁的法律规范结构，这些结构具有相关的肯定实践基础上的维度和规模。本文中大多是大胆的(或者应当说缺乏依据的)推想，由于我没有其他的方法来解决这个领域中缺少的工作和数据的问题。本文引用了“互连系统构成的系统”思想。接下来，我将临时撇开主题来介绍一些将我引入本文主题的一些背景想法。避开功能分解吗?功能分解的思想对于软件开发

7、领域中的很多人来说像一个“诅咒”。我对功能分解的体验更是其中的极端（在一个很大的数据流图中有3000个原始转换，五层或者六层深，在除了基础设施层外没有使用任何构架的思想的状况下完成），让我感到特别悲观。在该用例中存在的问题不仅仅与功能分解思想有关，还和下面这种想法有关，即直到分解到功能的原始层次才描述一个进程。在该层次上规格说明的长度应当少于一页。所得到的结果难以理解一一所需要的更高层次的行为如何从这些原始转换中显现出来，这一点很难搞清晰。此外，功能结构如何映射到物理结构上来满足性能和其他质量方面的要求并不是特殊明显。这就产生了一种自相冲突状况，我们始终进行分解直到达到了能够“解决问题”（原始

8、层次）的那一层，但是，这些原始层是否能够实际上协同工作以满足更高层的目标却并不清晰或者可以被证明。没有方法以这种方式来考虑非功能性需求。从总体上讲,构架和基础设施（通讯，操作系统等等）都应当随着分解而不断演进，并且每一次分解都应当对其它分解产生影响。那么Bauhaus规章”形式听从功能”又如何呢？有很多好的设计源自功能主义方法，但也不乏一些不良设计。例如，随处可见的平屋顶结构的使用。假如您只关怀屋顶的功能,并且将其完全设计为居民所需的一个房盖，那么至少在一些特定的领域中是不能够令人满足的。这种屋顶很难防水，并且简洁积雪。现在这些问题可以解决了，但是在一个更大的范围内而不是在您已经选择的不同设计

9、中。尽管看上去有些过时，但是形式还是应当听从全部的功能和非功能性需求，以及后续的美学要求。架构师面对的问题常常是非功能性需求常常表达模糊，并且过多的依靠于架构师的“事情就应当是这样”的阅历。因此假如功能分解仅仅用来驱动构架（即分解产生了几个向下的层次并且功能的原始层次与“模块一一匹配）和定义其接口，那么将一无是处。像这样的考虑使我确信，在完成构架工作之前，将用例向下分解到标准化的水平（这可以通过类的协作来实现），这没有任何意义。对于肯定规模的系统而言，这些分解的确必要,（参见Jacobson 97）但是分解的标准和实施过程至关重要一一特殊是当功能分解不是足够好的时候。系统考虑系统工程师完胜利能

10、分析、功能分解和功能安排工作（当综合一项设计时），但是功能并不是系统构架的唯一驱动因素，一个特地的工程师团队就能够在评估不同的设计方面做出贡献。正EE Std 1220,系统工程过程的应用和管理标准（Standard for Application andManagement of the Systems Engineering Process）在 6.3 节中描述了功能分解的使用,功能分析（Functional Analysis）在 节,功能分解（Functional Decomposition）,和系统产品解决方案等综合在6.5节中。6.5.1节包含了一些特殊好玩的内容，分组（Group）

11、功能和安排（Allocate）功能，6.5.2节是物理解决方案的选择（Physical Solution Alternatives）o在6.3.1节中指出，分解是用来清晰地理解系统必需完成哪些功能，并且一般状况下一层分解就足够了。留意，功能分解的目的并不是为系统定型（由综合工作来来完成定型），而是理解和沟通系统必需完成什么一一功能模型是能够完成这些的好的方式。在综合中，子功能首先被安排给解决方案的结构，然后评估这个解决方案一一必需考虑全部的需求。这种方法和多层功能分解之间的不同之处在于：在每一层都试图描绘所要求的行为，并且在打算是否该行为在下一层需要被精化，以及安排到更低层的组件中之前，找到一

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

13、nal中，我们认为用例的数量应当很小（1050个），并且熟悉到大量（超过100个）的用例表明可能需要进行功能分解，在功能分解中用例对于参加者毫无价值。然而，在实际项目中我们仍旧能够发觉大量的用例，并不总是“糟糕的。至少在层次上是全面的。例如，在Rational内部的电子邮件中,作者引用了一个Ericsson例子： Ericsson,对大部分的新一代电话交换机的建模，估量要多于600个人年（最多,3到400个开发人员），200个用例（使用不止一层用例，请参考”互连系统构成的系统”）对于一个超过600人年（这有多大呢？ 150万行C+代码吗？）的系统，唯恐用例分析会限于子系统上面的某一层上（也就是

14、说，假如一个人定义了一个7000到10000行代码的子系统），否则用例的数量还会增加。因此，我仍旧强调这种观点即少量的外部用例是适合的。为了匹配我曾经建议的结构和规格，我断言10个外部用例，每个用例带有30个相关场景，这对于描述行为是合适的。假如实际中用例的数量超过了 10个，并且的确是外部用例，那么它们所描述的系统要比相应的法律规范系统具有更大规模。在下文中我将供应一些支持理由来说明这些数字是合理的。结构分层建议的结构分层如下： 4-多个系统组成的系统 3-系统 2-子系统组 1-子系统 0类类和子系统在UML中定义为；在UML中更大的聚合是子系统（包含子系统），为了更简洁的进行描述，我进行

15、了不同的命名。对于那些知道2167和498军方标准（称子系统为CSC,称类为CSU）中的术语的人来说，子系统组（subsystemGroup）的规模用CSCI来表示。我记得，经过2167天的关于Ada的结构应当映射到哪一层次的争辩后，尘埃落定，Ada包通常映射为CSo我并不建议系统必需严格的遵循这种层次结构，还将存在层次之间的混合，这种层次结构使我能够更好地了解规模对于每个用例工作量的影响。在每一层上都会有用例（尽管对于单个的类可能不是这样），但并不是单纯的大量细节堆砌，而是用例针对那个层上的每个组件（例如子系统、子系统组，等等）。在上文中我曾断言对于每一层的每一个组件都有10个用例一一假如用例的描述平均是10页，那么将会给出一个潜在的、大约100页长度的说明文档（还要加上类似的或者少一些的关于非系统性需求的相应说明），这是Stevens 98提倡的数字，并且和Royce98推举的数字很接近。但是为什么是10个用例呢？为了得出这个数字，基于对每一个子系统的类的数量、类的规模、操作规模等等我认为的合理的规模，我进行了自下向上的推理。这些和其他假设共同搜集在下表中供大家引用。操作规模70 sloes