点度量（3）—功能规模度量方法选择
blueski推荐 [2005-1-18]
出处：51CMM
作者：中南大学刘秋林译
4. 功能规模度量方法的共性问题
依照文献，功能规模度量方法也要处理一些难题。Kemerer 在文献[23]引用 Pressmann说道：“功能点度量，像 LOC，也有相关的争议…反对者说道，这种方法不是完全客观和依靠数据，而是更多地需要一些基于主观的计算手段…”；Capers Jones 发现，FP计算方法的变量结果可以在超过+/- 50％范围内变化。还有G. Low 和D.R. Jeffery 也发表过声明，“在组织内，功能点计算变化的范围大约平均在30％之内…”。由此可见，可再现性和客观性是功能规模度量方法的核心问题。其他论文如Abran等的文章[15]提到未来需要集中研究的问题如自动操作和可兑换性。本文这部分将讨论以下几个重要的问题：
自动操作（automation），
客观性/可靠性（objectivity / reliability），
可兑换性（convertibility），
加权因子值的需要（need of a Value Adjustment Factor）
重用的包含(inclusion of reuse),
新技术的影响(influence on / of new technologies),
不同的度量软件工作产品（different measurement artifacts）。
4.1 度量的自动操作（Automation of measurement）
如在第3章提到的那样，一种完全自动化度量的独立估计工具是个理想的解决方案。对应于实际的软件生命周期阶段，工具应源于实际文档的功能点计算。自动数据收集不但减少了萃取数据过程中发生错误的风险并且减轻了工作量。这对大家接受功能规模度量非常重要。
为了自动化操作，有关这类方法的可能性进行了大量的讨论。比如Symons提出实现IFPUG功能点非常困难，但Mark II功能点在CASE工具的帮助下可以实现自动化[14]。
MacDonnell做了调查产品的复杂评估是否可以完全以自动化，不需要人工输入方式的进行[18]，结果如表5所示。表5显示了他的观点，完全自动化估计是不可能的
| 方法 | 是否可以自动化 |
| Bang Metric | 不可以 |
| IFPUG | 不可以 |
| Mark II FPA | 不可以 |
| 表 5: 自动化度量的可能性 | |
Ho等提出了一种源于源代码利用程序的篇幅来自动化度量功能点的框架方法[24]。被提出的框架可以用来建立一种符合“IFPUG计算实践手册”自动化功能点度量模型。认识到模型高度依赖于限幅工具的能力和效率，已经进行了原型开发的进一步研究。Paton发表了对于这种方法的理论基础[25] 。首先，定义了中间程序表现包含足够信息计算功能点的DF（P）的方式。其次，很明显这种中间程序表示法可以利用程序篇幅（一种静态代码分析形式）以及程序追查（一种动态代码分析形式） 得到。 因而，自动化功能点计算是可能的。
另外一种是Oppermann 为了支持全面功能点版本1自动化度量而开发的方法[27]，它作为西门子和马格德堡的大学（译者注：马格德堡的大学是德国的一所综合性大学）合作的成果论文提出的。 它是经过评价全面功能点在西门子的适用性后，才决定开发一个工具进行自动计算[28]。但是，遗憾的是经过进一步的调查研究发现，由于西门子说明书文档的结构复杂和多样性，完全自动化计算是不可能的。因而开发了一个由两部分组成的帮助度量的工具。 FFPExtract 分析西门子的需求说明书且选出一些可能可以度量的作品。然后FFPCounter 在一个对话框中显示出需求说明书和建议进行度量的作品。这些作品可以被用户接受进行计算也可以拒绝。
Diab, Frappier 和St-Denis 提出了另一种有趣的方法[52][53]。利用IFPUG和全面功能点的正式定义，他们能够进行自动计算。这种方法对B说明书语言（针对IFPUG）和ROOM（实时面向对象模型）语言（针对COSMIC的全面功能点）特别适用。
自动计算功能点的一般解决方案是可能的（本文介绍的方法是非常专门的），但还没有令人满意，还必须做在这个领域的进一部研究。
4.2客观性/可靠性（Objectivity/Reliability）
在功能规模度量，任何参与的评估员个人的方法主观地方强调的越多，结果的可重复性越难。
举一个Symons给出的有关IFPUG内部问题的例子[15]：三个子系统单独度量的功能点和少于由他们组成的整个系统度量的功能点。
此外，在他看来单个功能元素如输入、输出等的权重是任意选择，他认为应该根据某种具体环境进行修改。
Iok Kuan Wu Simon在一次案例研究（500不同地区的香港商业公司）中发现由于功能点方法太主观，仅有大约23％的公司使用这种方法[29]。从这里可以看出经验对功能点分析方法的结果可重复性是非常重要。因此，这个问题可以通过培训来解决，但是太花工作量。然而，不管主观性，LOC对Simon来说好像也不是一个好的选择，特别是在科学应用如数据通讯和多媒体应用领域。
MacDonnell已经做了调查[18]：不管对个人要求或者执行评价或估计要求，模型是否如定义的那样对一个给定的系统在一个给定的时间点（假设没有计算错误）总是会得出同样的结果。表6可见调查结果。
| 方法 | 是否客观 |
| Bang Metric | 不 |
| IFPUG | 不 |
| Mark II FPA | 不 |
| 表6：方法的客观性 | |
依照Abran全面功能点要有好的可重复性，需要评估人员有和业务领域一样的功能度量领域的经验。
从上面争议的陈述可见，这个主题还需进一步研究。其中包括为客观性和可重复性，清楚定义计算，分别地估计和度量什么，怎样计算、估计和度量。
为了支持客观性/可重复性的评价，ISO标准14143第三部分提供了一个和准确性一样验证可重复和可再现性的框架[49]。
4.3 可兑换性（Convertibility）
有许多功能规模方法分布在不同功能业务领域而且因此有不同的度量策略。
如果想提出一种新的方法或者比较不同方法之间的度量结果，必须研究不同方法之间的可兑换性。Symons已经提出人们是否接受一个新的规模的方法其是否能转换是需要考虑的条件[08]。 通过分析可兑换性，他发现COBOL SLOC和Albrecht 功能点相互关联不是很好，同样Albrecht 功能点和Mark II 功能点也不是很好转换。
Capers Jones 认为特种点和功能点之间开发了兑换[30]，SPR工具如KnowledgePlan能执行这些转换。由于是不同的度量策略，想得到DeMarco's Bang这种度量方式和其他功能点或特征点的兑换关系是不可能的
Meli调研了Mark II和IFPUG功能点之间的关系[31]。既然两者都是用于相同功能业务方面，他们之间应该有个比例并且因此能从一个转换成另外一个。但是依照Meli的看法，这些方法不能进行比较。
全面功能点的可兑换性仍然在研究中。这是COSMIC主动提出而且强调最多正在研究的方面之一。
为了支持可兑换性的分析，ISO标准14143第三部分提供了一个可兑换性的确认方法的框架[49]。
4.4 加权因子值（Value Adjustment Factors）
有关加权因子值非常有趣的讨论早已提出。问题是它的作用是什么和应该怎么样使用它。
Lokan 等说根据他们的经验，一般系统特征（GSC the General System Characteristics）和加权因子值（VAF the Value Adjustment Factor）很难理解[32]。一般看来它们是重要的，但是很难成功应用。由于加权因子值，即使在技术和质量要求上的做了大量努力也是明显无效的。依照Symons导致这种尴尬地步的一个原因是已经引入这个集合和因子的争议和试验策略 [14]。
在功能点分析的演化过程中，一般系统特征（GSC）已经被修改和分别大范围地减少（在他们的数量和他们的集合方面）。
根据Lokan等[32]，一些规模度量方法加了些特征（如Mark II 功能点不是14个特征而是19个），但是也有一些其他规模度量方法（包括特征点，3-D等）不描述调整过程或者甚至直接采用IFPUG的建议。ISO在功能规模度量的标准明确拒绝采用加权因子值。
Lokan后来的陈述道，没有任何调查研究加权因子值的人发现使用这个因子后对工作量估计的准确性有多大程度的提高。因此不断有估计人员根本就不使用一般系统特征和加权因子值。（可以参见我们在西门子同样的经历[27][28]），他们忽略它或者在工作量估计时把它考虑为成本驱动因素。
结果，Lokan做出了这样的结论：一般系统特征和加权因子值是度量一个应用软件的不同方面。认为规模有不同的尺度衡量比使劲将它们合起来形成一个数据要好些。
Meli 有相同的结论[31]。他告诉大家我们必须放弃使用加权因子值，至少不应用作应用软件规模度量的调节元素，也许加权因子值可以作为一个限制条件使用（如加权因子值越大，应用软件越好）或者用作会影响生产成本的元素调节生产力值。
Symons建议应该可能地校准一般系统特征，在不同的应用软件领域从而就有不同的加权因子值[14]。
在Meli的观点，只有两种处理加权因子值的可能选择[33]。一是完全放弃加权因子值，只使用未调整数。第二是为了限制某种特殊应用软件的功能点数而使用加权因子值。这就意味着同一个功能点数目可以是非常有用和有效的组件的功能点计算也可以是不是那么有用有效的组件的功能点计算。
然后限制条件可以给出这个不同的概念。如影响程度越高（用一个计算出来的数字表示），应用软件越好。
下面是处理这个问题需要进一步研究的方面
多少个一般系统特征数应该定义（建议4到100）
哪个集合是必须的 ，
影响范围应该是多少（+/-5 范围内或者不是这样）。
4.5重用的包含（Inclusion of reuse）
传统的功能规模度量是度量用户视域中的整个软件产品功能规模。
既然新提出的软件开发方法都支持重用，如面向对象，COTS和JavaBeans,在商业计算时，为了单独决定软件的自我继承部分是多少时，传统的度量方式是不够的（更详细的信息请参见文献[45]）。
Meli发现需要区别开用户要求且发布给用户的功能点和软件开发团队实际开发的功能点[33]。这也是为什么需要发现并提出新方法的原因。他提出了一个对这个问题的解决方法[31]：定义两种不同的功能点度量方法，一个是和外部用户视域相关联，另一个是为了满足软件制造管理和生产性的需要。
Ho等为了处理这个问题度量了软件工程的执行过程[34]。因此，识别出发生了多少重用是非常重要的。为了得到这个信息，全面功能点使用了层的概念识别软件中潜在的功能重用源并进行度量。
Meli进一步说道，现存的软件工作产品事实上（如文档、源代码、说明书和用户手册等）可能包含一个积累，它能用一个可选的定量化标准范围 [33]。和新产生的详细描述的软件数据一起考虑，一个基准数据基数是比较重要的。它能在重用现象的强烈作用下形成产品数据。因此如果项目计划在草稿到实现过程中使用了大量的重用，平均比率不是有用的。由于这个原因，应该要有一个完全开发的功能点生产率数据。而后，由于指望的重用，对于具体的项目，要在完全开发的基础上重新校准工作量。
4.6 新技术的影响（Impact of new software technologies）
传统的软件规模度量方法研发时满足了传统的软件开发需要。既然有新的方法和领域引入，即使功能规模度量仍能可以适用于软件的新方法也必须对传统方法进行完善。在本文提到的新的软件方面如下：
Internet 和 Intranet 软件，
图形用户界面，
分布式软件（如客户端服务器），
面向对象系统
其他
依照Longstreet [35] [36]面向对象系统主要不同是其对系统采用的一种另外不同的观察方式。传统的软件系统是个结构合成物，面向对象看来是一个单一的实体，对象表现了数据和过程。
对于图形用户界面（GUI），internet 和 intranet 软件同样是对软件的另类观察。用FrontPage或者其他html工具开发的Web站点可能或者不可能包含任何功能。关键是对信息在哪里存放和信息怎样处理过程的理解。多数网站无非是菜单和文本。但也必须考虑这类系统的功能度量。
但Longstreet认为IFPUG功能点能适合面向对象环境[36]（既然产品的功能规模是面向用户，它应该和实现方式无关），但是必须要有一些面向对象和传统开发比较的标准化要素。为了支持这个观点，Longstreet发布了扩展的IFPUG 4.1版来适合图形用户界面、Internet, Intranet, OO和其他新出现的软件技术领域[20]。
Boehm也说全面功能点适用于图形用户界面（GUI）,客户/服务器（client/server） 和 面向对象（object-oriented） 系统[19]，但也有一些问题需要解决。
当然，利用大多数功能规模方法，每一个功能业务领域可以度量功能规模，也可以得到一个数值。但是问题是，这个数据是否能正确代表系统或者它是否只是个数字，没有其他任何意义。
Symons意识到一个困难是方法的定义和过程将逐渐变的越复杂[08]，因为为了将一个老的规模方法改编适应新的开发方法和技术，就必须连续加入新的规则到老的规模度量方法中[08]。因此很难维持这些追加内容的一致性。
另外一个是有关分布式软件的问题，用户对功能的看法是必要实现的功能是否充分刻画。对这个问题的一个可能的方案是使用全面功能点版本2.0，它包含了层的概念来分别处理不同软件视域。进一步的研究会揭示新的功能规模度量方法是如全面功能点方法是否完全解决这些问题。
4.7 度量的工作产品（Measurement artifacts）
在整个软件生命周期都有可能有功能规模度量。既然在不同的软件生命周期阶段工作产品不同，就需要有不同的考虑：
哪些工作产品可以用来度量/估计 ，
对某种方法，什么时候是度量的最早时间点，
方法是在估计吗，
UML 是否可以用于度量/估计，
是否有可能从源代码进行后期度量计算 。
度量的工作产品（Artifacts for measurement）
首先，功能规模度量的开始时间点已经讨论。图8和图9（figures 8 and 9）是COSMIC [16] 自己确定的早期和后期实现用户功能需求的 模型。
Figure 8: Pre-implementation FURs (Source: [16])
Figure 9: Post- implementation FURs (Source: [16])
图中所有显示的工作产品，应该可以得到度量的必须信息。
度量时间的最早点（Earliest point of time for measurement）
Garmus和 Herron [03] 说过，DeMarco's Bang和3-D功能点方法需要对系统过程的详细认识，但是在初期不可能充分计算系统过程（如系统的状态和转换过程），对这两种方法来说， 计算功能点越早越困难。因此它们必须在比 Mark II功能点、特征点和IFPUG功能点使用的软件生命周期更后的阶段度量，其中Mark II功能点、特征点和IFPUG功能点可以在相同的系统详情水平，得到相同精确程度的功能点，但是不幸的是他们需要的详情业只有经过大约15-40 %的开发时间后才可能有。
早期估计（Earlier estimations）
Boehm指出越早度量项目就可能越早在控制之下[19]。
一般都相信只有在设计阶段才可能进行功能点计算，但是有规则可以使得更早得到功能点数据（在IFPUG4.0支持下）。有时用启发式规则。但在真正进行这种可能新得计算往往发现是又不可能，根据一般模型的适用性，在需求收集阶段，功能点计算可能只是一个更好或者更差估计。当所有商业需求终结时，可能有准确的功能点计算。为了克服这个时间点迟后问题，有人提出了早期功能点方法。Meli总结了应用这种方法的结果[31][33]。他发现方法在软件项目没有所有详细资料（功能说明书）时估计功能点值早期功能点是一种非常有用的方法，它能是一种正式标准的计算。
但重要的是需要考虑这种方法的效力，这种方法的系统是根据实际计算案例来设置的，它的效果只是用一种不变的确认来保证。但依照资料，早期功能点方法已经完善地比较有效，在大多情况它估计的数值在实际功能点数值+/-10%内。
另外一种早期估计的方法是早期全面功能点方法。这种方法基于早期功能点分析并且现在正在开发完善。
利用UML进行度量（Measurement using UML）
有几种利用UML元素进行估计功能规模的方法已经被提出和讨论。其中一种是Stutzke被提出来的用来估计特征点的方法[44]。他参考结合了以前别人的工作成果如Reifer's模型(1990)、类点方法（the Class Points Method，被Fischmann/McRitchie 提出）和南非方法（the South African Method 被Meyerson提出)。但他认为不是所有的问题都解决了，可能问题是：
对象模型的重用部分需要多少工作量 ，
特别的分析方法是怎样影响工作量的 ，
将设计的对象转换为执行代码需要多少工作量 。
Longstreet给出了一些怎么用用例度量功能点的例子[20]。他声明每一步必须分析它是否是一个事务或者是一个数据类型。他还列出了采用用例进行功能点计算的风险：
在用例中没有标识清楚必须的事务，
在用例中可能没有正确标识事务，
在用例中没有清楚定义属性数，
属性数不能固定到一个实体上。
但他， Longstreet [36], 声明功能点分析可以非常容易的适用于用例方法。
Meli 提出用例已经变成一个捕获用户需求的一般方法，因为用例是从用户的角度描述功能，他们应该很容易转换成功能点[37]。但这个事实需要一项一项确认，既然功能转换和用例的“解剖”水平可能不同，进一步的研究应提供些这种潜在关系的统计证据。
从源代码进行后期计算（Post-calculation from source code）
一个最后重要的考虑是希望从源代码进行后期计算功能点 。既然有方法已经从源代码实现功能业务内容自动度量，后期计算也是可能。自动度量的方法在本文的4.1进行了介绍
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/