1、第 1 章 软件功能点度量方法概述本章介绍软件项目开发与维护所面临的典型问题，指出解决这些问题的基本途径是软件项目的定量评价分析。在比较了各种软件定量评价方法的基础上建议采用功能点方法作为软件定量评价的基础方法。本章进一步介绍目前被 ISO 标准采纳的 5 种功能点标准，依次 是 MarkII 功 能 点 标 准 、 COSMIC 功 能 点 标 准 、 NESMA 功 能 点 标 准 、 FISMA 功 能 点 标 准以 及 IFPUG 功 能 点 标 准 。 本 章 还 对 5 种 功 能 点 标 准 的 不 同 之 处 进 行 了 比 对 分 析 并 给 出 了 建议 。1.1 软件困境
2、软件在我们生活和工作中的重要性正与日俱增。试想，没有银行软件系统和证券软件平台的应用，庞大复杂的银行业务便不能有效地开展，证券业务也只能局限于现场交易，因而不能发挥其应有的金融职能；没有网络管理软件系统的应用，快捷的电话联系方式也是不可想象的；除了目前已经广泛应用的固定电话和移动电话业务之外，更有如雨后春笋般出现的各种数据服务，例如宽带上网、GPS 定位导航等，而这些应用无一例外地依赖于各种软件系统。软件应用对于很多行业的发展变革甚至起决定的作用，例如基于网络的传媒信息更多地取代了传统的纸质媒体，人们的阅读习惯因而发生了有史以来最重要的变化。由此可见，软件无论在我们的生活还是工作中已经变得不可
3、或缺。软件以其快捷、高效、经济等诸多优势几乎渗透到各个行业中，正是软件的普及应用塑造了信息时代的主要特征。因为软件应用的互通互联，因特网时代之前的“信息孤岛”正日益消亡，伴随着世界范围内各种经济、科技和教育等方面的信息共享， “地球村”的预言正成为现实。具有讽刺意味的是，软件在促进信息共享、信息透明的同时，自身却存在典型的“灯下黑”现象。与传统的建筑等行业相比较，软件系统的建设与开发充满了各种不确定性。用户业务需求不明确、工期和费用设置的盲目性、开发团队不稳定、人员的工作经验和技术水平参差不齐、 “作坊式”开发模式等诸多因素使得软件开发往往达不到预期的目的。软件开发与建设对客户来说更多地呈现为
4、“黑盒子”特征。实际开发出的软件系统往往差强人意，用户在使用中抱怨不断，不能真正满足客户的要求。具体表现为所提交的软件系统功能与用户期望的需求差异过大、工期严重拖延、费用超支明显、质量问题层出不穷等现象。导软件项目功能点度量方法与应用2致出现以上问题的原因纷繁复杂，但究其主要原因，则是因为软件系统的建设与开发的过程中管理不善所致。大量的实践表明有效的软件项目管理是改善和提高软件系统建设与开发效率的主要途径。要对软件项目进行有效的管理，首先得了解软件项目的特点。与传统行业相比较，软件项目具备以下三个重要特点。（1）前期业务需求不清，导致项目执行过程中需求频繁变更。对于大部分软件项目，开发团队在启
5、动软件需求分析之前都无法获取明确的需求。例如对于一个电子政务项目而言，前期可能只会给出该项目的定位，例如“通过将现有手工业务转变为软件支撑的电子流工作方式，提升工作效率，并对现有的业务模式进行合理优化” 。可是如何对这样笼统的项目要求进行细化，并将其转变为相应的软件需求规格，软件开发团队还面临着各种挑战。首先是获取单一部门内的业务流程，现有的业务流程可能本身就存在不合理或者冲突的情形，需要需求分析人员与业务人员进一步讨论才能确定。如果涉及到部门之间的业务流程，其困难程度还会进一步加大，因为不同部门的人员都倾向于站在自己的立场来考虑问题，所以部门之间的业务流程确定往往还需要领导的强力参与。伴随着
6、组织业务流程的调整，通常意味着部门和人员的重新定位，有时甚至影响相关人员的切身利益，此时的需求分析将会面临更大的阻力。除了来自业务部门本身的挑战外，业务人员与技术人员的沟通也存在明显的障碍，即客户与技术开发方对业务需求的理解不一致。客户方的业务人员通常认为自己对业务需求的表述清楚无误，而开发方却觉得业务人员语焉不详，并没有将业务的来龙去脉交待清楚。不少项目在各方对于需求的理解还未达成一致的情况下就开始项目，结果项目是边做边改，等到项目临近结束时，需求已“面目全非” ，与双方前期确定的需求相差甚远。试想，一栋大楼或一座大桥在还未确定功能或结构的前提下就开始动工，然后在施工的过程中再根据用户的要求
7、不断变更，将会出现什么样的结果？结果很可怕，所以没人做这样的尝试。但软件项目不然，环顾我们身边的软件项目，有多少项目真正能够做到“谋定而后动”呢？正是软件需求的脆弱性和易变性导致了软件项目的失控。（2）项目目标失控，明显超出客户心理预期。所有的软件项目在初期都会设置相应的管理目标，包括项目所要实现的功能、项目工期、项目预算以及项目的质量目标等。可是在项目开发的过程中却发现这些目标无异于“海市蜃楼” ，可望而不可及。大部分软件项目或多或少地表现出下列特征：要么是“种瓜得豆” ，要求的功能大幅缩水；要么是项目工期严重滞后，影响客户业务的正常运行；或者项目严重超支，软件开发商虽然投入了额外的人力物力
8、，但客户并不领情；更有甚者，虽然软件系统勉强按时上线，但后续的质量问题却层出不穷， “摁下葫芦浮起瓢” ，永远有解决不完的问题。既然上述问题是目前软件项目所面临的共性问题，那么单一地将其归属为软件开发商的责任似乎有失公允。设 想 这 样 的 场 景 ： 如 果 对 一 个 小 学 班 级 进 行 数 学 测 验 ， 孩 子 们 最 后 的 平 均 成 绩 为 30 分（考试采用百分制） 。30 分的平均成绩说明什么呢？首先孩子们的数学知识学得不够好，第 1 章 软件功能点度量方法概述 3怎么才考 30 分呢？其次，数学测验题目有问题，为孩子们设置了过高的目标要求（学生家长往往更倾向于这种结论）
9、 。对软件项目而言，也存在类似的现象。所以在抱怨软件开发商工作绩效的同时，客户似乎也应该进行自我反省，客户要求的目标合理吗？我国现在大部分的软件项目均采用招投标的方式来选择供应商，再加上在国内的软件行业中普遍存在“买方市场”的特点，许多软件开发商都存在“先拿到合同再说”这样的心理，故而往往对于客户所提的各种要求都满口应承，即使认为客户设置的项目目标不合理，也往往忍气吞声、委曲求全 1。也有一些软件开发组织与客户签署合同之前，对于客户单方面设定的目标会提出不同的建议，例如更为合理的工期、成本与质量目标等，但这些建议对于客户往往缺乏足够的说服力。因为大多数软件开发组织并没有一个明确的、量化的过程可
10、以向客户表明自己所建议目标的客观性、合理性，代之以“根据我们的经验” 、“参照我们以前的项目”等说法，因而缺乏说服力，最终只能接受客户方设置的项目目标。但软件项目最终的结果却让客户追悔莫及，油然而生“早知如今，何必当初”的感叹。所以如何为客户设定合理的项目目标至关重要。（3）软件项目的成功过度依赖个人，缺乏来自组织的过程保证。成熟与不成熟的软件开发组织相比较，其最大差异在于两者的可预期性。不成熟的软件开发组织往往倾向于过度承诺，而实际开发过程中却经常面临捉襟见肘的困境：要么是工期严重滞后，要么是成本超支，工期若能勉强得到保证，通常即意味着质量风险。而高成熟度组织所做出的承诺通常可以得到真实的兑
11、现。在不成熟的软件开发组织内，更多地采用“游击队” 、 “个人英雄主义”的开发模式，在项目中甚至没有采用相应的软件配置管理平台，更没有进行软件项目计划与跟踪、软件项目质量评价等相应的管理措施。这种“作坊式”的开发模式导致软件开发的最终结果主要取决于个人因素，而组织对软件项目的管理与控制则力不从心，只能寄希望于员工在工作中一直表现出认真、负责、任劳任怨的态度。如果出现项目经理或项目组成员离职等情形，对软件开发的影响通常是致命的，新加入的人员不得不从头再将前任的工作完成一遍。软件开发是一项群体的智力活动，软件开发过程是否高效、开发团队工作是否工作在同一基础之上、个人的工作成果能否完全融合到项目中等
12、因素对于成功的软件开发至关重要，而要保证软件团队工作的有效性，来自软件开发组织的过程管理则必不可少。适用于软件开发的典型过程管理模型包括 ISO9000 模型、CMMI 模型和 RUP 模型等，而在这些模型中无一例外地强调了过程度量的重要性。正是通过过程度量，我们才能评价当前工作的好与坏、正常还是异常、是否需要采取纠正措施或补救措施等。 “人贵有自知之明”被许多人奉为人生的圭臬，可是许多软件开发组织却缺乏“自知之明” ，项目组的产出如何？组织的开发绩效如何？对开发过程中生成的需求或技术文档质量状况是否满意？对类似的1 作为某些人的处世哲学，这种态度无可厚非。但用于软件项目目标的设置则弊端丛生，
13、因为不负责任的承诺常常会害人又害己。软件项目功能点度量方法与应用4问题许多组织往往会采用“还行” 、 “不错” 、 “我们有信心”等模棱两可的说法来搪塞，因为组织根本就没有数据。基于以上分析，目前软件项目管理所面临的困境可以归结为三个“说不清”：需求说不清；目标说不清；过程说不清。要做什么不清楚，做到什么程度不清楚，中间过程也说不清，这样的项目做出的软件可想而知会是什么结果。说不清首先和软件本身的特点相关，从客观角度分析可能包含两方面的原因：首先，软件不同于其他的有形产品，很多时候难以去想象最终的产品究竟是什么样子；其次，软件的开发过程主要表现为人们的智力活动，表现为建立模型、编写文档和代码调
14、试等可见性较低的活动形式。所以上述两类原因导致人们对软件不容易“说清楚” 。除了客观方面的原因外，可能也有来自人员本身的主观原因。现在各行各业都在倡导“定量化”的管理模式，对于软件行业也应该引入定量管理的理念，可为什么在国内的软件开发组织中真正采用定量管理模式的组织却少之又少呢？第一，可能是由于思维惯性。“我们一直都是这么跟着感觉走，也没出啥大问题嘛” ，不愿意主动提升和优化现有的软件开发过程。第二，和我们的传统文化有关。如果采用定量管理的办法使得大家的工作都透明化，是否组织中的每个人都喜欢看到这样的结果？中国的传统文化强调中庸，强调“水至清则无鱼” ，你把账算那么清楚，犯得着吗？所以我们看到
15、在各个国家审计部门都不是一个受欢迎的部门，他们总是拿着数据报告要别人解释自己的行为或结果。在软件项目中采用定量评价的方式虽不至于产生类似经济领域的“审计风暴” ，但迫使人们在事后要关注自己的行为，有时甚至还需要为自己的行为进行解释。在潜意识里，人们希望自己在工作中的束缚和来自外部的检查尽可能的少。因而在软件开发组织中引入定量管理评价机制通常是不受欢迎的，甚至会遭到抵制。因 为 存 在 这 样 那 样 的 原 因 ， 所 以 我 们 国 家 的 软 件 开 发 现 状 在 最 近 5 年 、 甚 至 最 近 10 年并没有发生明显的变化 1。虽然我们的软件行业表现得朝气蓬勃，但我们的沉淀和积累仍
16、然不足。如果我们对现状不满，那就必须做出改变。如何改变？在软件开发过程中引入定量管理评价方法则是必不可少的一个主要步骤，而定量评价方法的基础则是软件项目规模的评价。如果能够在软件项目管理过程中引入基于功能点度量方法的规模评估，则有助于我们做到“需求说清楚” 、 “目标说清楚”和“过程说清楚” 。1.2 软件规模评价方法为什么说软件规模评价是软件量化管理的基础？在实际的软件开发项目中我们好像更关注工期、成本和质量。软件规模、工期、成本以及质量之间存在什么样的关系以及如何1 甚至于软件开发组织中的人员平均年龄也是如此，10 年前的软件开发组织人员平均年龄大概为二十六七岁，10 年后的平均年龄依然如
17、此。第 1 章 软件功能点度量方法概述 5图 1.1 软件项目管理三角形对这些关系进行定量表述是软件项目量化管理的主要内容。在介绍这些依赖关系之前，有必要首先建立“和谐项目管理”理念。对一个软件项目而言，在项目中会设置 4 个最主要的目标，即项目范围、项目时间、项目成本以及项目质量。它们 4 者之间相互影响、相互依赖，如图 1.1 所示。也许有些读者还记得若干年前我们国家的一句政治口号：“多快好省地建设社会主义” ，这种提法的出发点是好的，但忽视了经济建设的内在规律，最终导致了“大跃进”的局面，对中国经济的健康发展造成很大的伤害。即使在我们大力倡导科学发展观的今天，仍然有不少客户和领导希望软件
18、项目完成的功能越多越好、工期越快越好、成本越低越好、质量越高越好，岂不是“多快好省”模式在软件行业的完全翻版？我们应该从错误的做法中汲取经验和教训，而不是重蹈覆辙。我们现在的社会和经济发展强调“和谐”理念，对于软件项目管理也要遵循“和谐”的管理模式。概言之，即要完成的软件功能有多少，就应该设置多长的工期，就应该设定多少预算，就应该设置相应的质量目标，而不是一味求快贪多，置客观事务的内在联系于不顾。正如其他传统行业的定量评价机制一样，项目的工期、成本和质量目标的设置主要取决于项目所要完成的工作内容 1。例如修建铁路的成本与工期主要取决于道路的长度；办公大楼的建设费用与工期则主要取决于建筑面积。所
19、以要在软件项目管理过程中引入量化评价机制，对于软件规模本身的评价则是首要任务。只有确定了软件规模，才能得到其他的项目管理目标；只有预先设定了项目目标，定量管理才有执行的依据。根据软件行业的实践，目前评价软件规模的方法可以区分为两种评价方法：非标准评价方法和标准评价法。非标准评价方法具有操作简单、容易实施等特点，但不容易在项目干系人之间达成一致，往往会引起较多的分歧；标准评价法则较好地克服了非标准评价方法的不足，但因为其操作相对繁琐，很多情形下甚至需要外部咨询机构的辅导，因而在实际应用中也受到一定程度的限制。1.2.1 非标准评价方法与软件规模标准评价方法相比，非标准评价方法更多采用约定俗成的方
20、式，评价方法有较强的主观性，因而难以保证评估结果的一致性。但因为这些评价方式简便易行，因而在我国软件行业中仍然占据主导地位。典型的非标准评价方法包括软件源代码行评价法、1 软件项目的工期、成本和质量目标主要取决于项目的工作内容，但同时还要受其他很多因素的影响，例如需求是否清晰、软件技术是否成熟、开发人员的工作经验和工作能力、开发团队的人员规模等许多因素。对这一话题感兴趣的读者可以通过网络途径参阅笔者的博士论文IT 行业经济与管理指标测度与预报模型的实证研究 。软件项目功能点度量方法与应用6对象点评价法、需求数量评价法、用例数评价法以及文档页码评价法等。1软件源代码行评价法在所有的软件项目规模评
21、价方法中，软件源代码行方法在我国的软件行业中仍然占据统治地位。顾名思义，软件源代码行法就是以完成的软件源代码的数量表示软件项目所完成的功能的多少。源代码行方法最大的特点即是简单，直接数出代码行的数量即可。不同的项目源代码行数量不同，小项目可能只有几千行代码，而那些规模巨大的项目动辄会超过百万行。但应用代码行作为评价软件项目规模的方法，其缺点也是显而易见的。首先，代码行从技术而非业务角度度量软件规模。对于没有足够技术背景的客户或其他项目外部干系人来说，代码行不具备说服力，他们总是倾向猜测技术人员使用了过多的代码来实现软件功能。其次，代码行度量不及时。度量软件项目规模的主要目的往往要在前期确定项目
22、的工期、费用等关键指标，但在项目前期只有笼统的业务需求，只有当项目完成后才能得到真正的代码行数量。项目前期或项目执行过程中估算出的代码行数量没有足够的说服力，不同人员估算得到的代码行数量也许会有 50%的偏差。第三，缺乏代码行度量标准。一行代码是多长？注释语句算不算？跨行的语句算一行还是多行？在行业中并没有一致的规定。即使 IEEE 和 SEI 尝试过颁布了一些代码行度量标准，但并没有得到广泛的接受。最后，不同语言编写的代码行可比较性差。如何比较汇编语言、C 语言或者Java 语言编写的语句呢？如果使用多语言开发的程序，又该如何度量代码行的数量呢？虽然软件代码行方法目前在我国的软件行业中仍然是
23、一种普遍的规模估算方法，但因为其一致性不容易得到保证，越来越多的软件开发组织倾向于采用标准评价方法（功能点标准）来衡量软件项目的规模。2对象点评价法对象点（Object Point）评价法属于 Barry Bohem 所提出的 COCOMOII 模型的组成部分，主要适用于基于组件或可视化开发环境的项目，同时也适用于原型项目。对象点评价法基于加权的概念将软件项目的工作内容转换为相应的对象点数量，它包含最基本的三个对象点类型：屏幕、报表和组件 1。屏幕对应的复杂度加权表如表 1.1 所示。表 1.1 对象点评价法的屏幕计算表屏幕计算表引用数据表的个数包含的视图个数 总数8(3 Server ; 5
24、 Client)8 平均 困难 困难如果一个屏幕包含了 5 个视图，且访问了 5 个数据表，其中两个是 Server 端的数据表，而另外三个是客户端的数据表，则该屏幕对应的复杂度为平均。报表对应的复杂度加权表如表 1.2 所示。表 1.2 报表的复杂度加权表报表计算表引用数据表的个数报表的节数 总数8(3 Server ; 5 Client)0,1 简单 简单 平均2,3 简单 平均 困难4+ 平均 困难 困难如果一个报表包含三个节，访问一个服务器端的数据表，对应的复杂度为简单。对象点评价法中并没有对组件设置相应的复杂度加权表，所有的组件默认其复杂度为平均。确定了屏幕、报表以及组件的复杂度，然
25、后再根据对象点权重表将其转换为统一的对象点，如表 1.3 所示。表 1.3 对象点权重转换表对象点权重表复杂度权重对象类型简单 平均 困难屏幕 1 2 3报表 2 5 8三代语言组件 10 10 10如果一个软件开发项目要完成 10 个平均复杂度的屏幕、8 个平均程度和 3 个困难程度的报表以及 2 个三代语言组件，则该项目的对象点规模即为（102+85+38+2 10） =104。基于对象点的生产率对应表（如表 1.4 所示） ，即可推算完成该项目所需要的工作量。假定项目组的生产率为平均水平，则对应的工作量为 8 人月（103/13=8） 。表 1.4 基于对象点的生产率对应表OP对应的生产
26、率开发人员的能力及开发环境的效率 生产率（NOP/人月）软件项目功能点度量方法与应用8很低 4低 7平均 13高 25很高 50对象点评价法的评价方法一致，但其对对象点类型的划分并无详细的规定，所以在操作中容易引起歧义，例如不同人员对视图的理解可能就存在歧义。3其他非标准评价法除了上面的两种方法外，实际工作中还会使用到需求数量评价法、用例数评价法以及文档页码评价法等方法。需求数量以项目需要完成的需求数量作为规模衡量的方法，但对于需求的粒度却从来就没有统一的规定，包括经常所提的模块数量、功能模块数量也属于需求数量衡量的范畴，它们共同的缺陷都在于缺乏统一的标准，甚至不如代码行方法的一 致性。用例（
27、Use Case）是基于 UML 方法的一种定义软件需求的方式。用例是软件工程或系统工程中对系统如何反映外界请求的描述，每个用例提供了一个或多个场景，该场景说明了系统如何同最终用户或其他系统交互，从而获得一个明确的业务目标。通过用例描述的方式可以将软件系统所实现的功能进行抽象和总结，软件系统要实现的功能则表现为一组用例，所以可通过用例数量来描述软件项目的规模。相对笼统的“需求” 、 “功能”等说法，用例具有较好的一致性。UML 语言对用例规范建立了用例模板，例如典型的用例应该包含如下内容：用例名、迭代、综述、前置条件、触发器、基本事件流、备选路径、后置条件、业务规则、说明、作者和日期等。如果能
28、采用用例作为软件规模的衡量手段也不失为一种可取的方式。但用例也存在粒度不一致的缺点，不同的用例可能相差很大。对一个银行应用软件来说，描述用户管理的用例和住房贷款的用例可能会有很大的差别，从而缺乏横向比 对 的 意 义 。 除 此 之 外 ， 用 例 对 于 客 户 往 往 缺 乏 说 服 力 ， 尽 管 UML 的 倡 导 者 声 称用 例 是 客户和技术人员沟通需求的最佳方式，但客户对用例描述的需求多数还是采用敬而远之的 态度。采用文档页码评价法的优点和不足也是显而易见的，页码最容易统计，但人们的书写习惯、逻辑表达能力、图形与文字的比例、甚至纸张的大小等因素都使得页码评价法很难成为合适的软件
29、规模评价方法。非标准评价法以其方便理解、易于操作的特点在实际工作中得到广泛应用，尽管存在不同程度的不一致缺陷，但聊胜于无。无论如何，非标准评价法对于软件规模给出了一个明确的、用数字表示的数值，从而使得在此基础上讨论项目的工期、费用和质量目标等量化管理目标成为可能。如果要尽可能减少项目干系人对于软件规模评价结果理解的歧义，则需要采用软件规模的标准评价方法功能点方法。第 1 章 软件功能点度量方法概述 91.2.2 标准评价方法上述各种非标准评价方法虽然在实际工作中也有着普遍的应用，但更多地局限于软件开发团队内部。如果要在业务部门与开发部门、甲方与乙方等外部组织约定软件开发的工期或费用等关键项目目
30、标，则首先需要对软件项目规模进行标准、一致的评价与估算。目前的软件规模标准评价方法都同属一类方法，即功能点方法。用功能点衡量软件项目规模类似于用平方米衡量房间的面积，或者用千克衡量体重，所以如果使用功能点方法衡量软件项目规模，则不同的人员对同一项目的软件功能可以得到一致的结果，从而克服软件规模非标准评价方法的不足。从美国人 Allan J. Albrecht 在 20 世纪 70 年代末提出功能点方法以来，功能点在软件行业的应用与实践已超过 30 年，在 Albrecht 的功能点模型基础之上，经过进一步应用与发展，功能点标准演进为一个总标准（ISO14143）与 5 个子标准（MarkII
31、标准、COSMIC 标准、NESMA 标准、FISMA 标准以及 IFPUG 标准） 。1.3 功能点标准作为评价软件规模的标准方法，功能点度量方法（Function Point Analysis）已经被纳入 ISO14143 标准系列。就功能点方法的发展历程分析，目前被纳入 ISO14143 的 5 种实际操作方法都源自于 Allan J. Albrecht 所提出的功能点分析思想。当然，各种标准之间又存在一定的差异和共性。为了保证这些功能点操作方法的一致性和客观性，ISO 组织委托ISO/IEC JTC 1（信息技术）的 SC 7（软件与系统工程）委员会制定了 ISO14143 标准。IS
32、O14143 标准本身又包含了 6 个子标准，各子标准的作用如下： ISO14143-1：概念定义（Definition of Concepts） ，对标准中所采用的术语给出解释。 ISO14143-2：一致性评价（Conformity Evaluation） ，给出如何检验功能点操作标准是否符合 ISO14143 标准的评价过程。 ISO14143-3：验证（Verification） ，在需要时对功能点操作标准进行验证。 ISO14143-4：参考模型（Reference Model） ，给出功能度量方法模型以及需要度量的内容。 ISO14143-5：应用领域确定（Determinatio
33、n of Functional Domains） ，确定功能点操作标准适用的应用领域。 ISO14143-6：使用指南（Guideline for Use） ，对功能点标准的应用提出建议和指导。ISO14143 给出了度量功能模型的标准，但在度量具体的软件功能时，使用者还应该考虑 所 度 量 的 软 件 应 用 领 域 ， 从 而 选 取 合 适 的 功 能 点 度 量 方 法 。 所 以 从 这 个 角 度 分 析 ，软件项目功能点度量方法与应用10ISO14143 是 关 于 功 能 点 度 量 标 准 的 标 准 。 在 实 际 的 软 件 规 模 度 量 实 践 中 ， 目 前 符 合
34、ISO14143 标 准 的 功 能 点 操 作 方 法 有 5 种 ， 依 次 是 MarkII 标 准 、 COSMIC 标 准 、 NESMA 标准 、 FISMA 标 准 以 及 IFPUG 标 准 。 下 面 各 节 对 这 些 操 作 标 准 的 主 要 特 点 和 操 作 方 法 进 行 简要 说 明 。1.4 MarkII 功能点标准1991 年 ， 英 国 人 Charles Symons 在 自 己 的 Software Sizing and Estimating: MkII Function Point Analysis一书中介绍了 MarkII 功能点的操作方法。Sym
35、nos 先生在为毕马威咨询公司工作期间提出了 MarkII 功能点操作方法，在该操作方法的基础之上形成了 MarkII 功能点标准，该标准提出后被英国政府所采纳，目前该标准由英国软件行业协会维护 1。MarkII 功 能 点 标 准 目 前 主 要 在 英 国 应 用 ， 此 外 在 印 度 等 国 家 也 有 一 定 的 应 用 。 正 如Symons 先生自己所言 2，该功能点标准受到 Albreht 先生的功能点操作方法启发，不过采用了不同的加权方式来定义功能点标准。除了功能点的操作方法外，该标准还包含了功能点的应用建议，例如如何基于 MarkII 功能点标准来计算项目的生产率和工作量等
36、内容。1.4.1 MarkII 功能规模度量 规则为 了 保 证 MarkII 功 能 点 标 准 的 一 致 性 ， 该 标 准 采 用 了 基 于 规 则 的 度 量 方 式 。 MarkII 的度量规则共有 6 条，分述如下：规则 1 边界（1）MarkII 功能点标准用于度量应用系统的用户所要求功能的规模。（2）由边界所包含的应用或部分应用必须是逻辑一致的功能，包含一个或多个完整的事务逻辑类型。规则 2 功能规模与逻辑事务（1）应用系统的功能规模是逻辑事务的规模之和，每个逻辑事务的输入和输出部分穿越应用边界。（2）逻辑事务是最低级别的完整过程，它包含三个组成部分：进入边界的输入、边界内
37、和存储数据相关的处理以及离开边界的输出。（3）逻辑事务由用户关心的独特的事件触发，当事务完成时，应用系统处于逻辑完整的状态 3。逻辑事务也可以由用户从应用系统获取信息的需求触发，此时应用系统为未1 英国 软 件 行 业 协 会 网 站 为 http:/www.uksma.co.uk， 读 者 可 以 访 问 该 网 站 并 下 载 MarkII 功 能 点 标 准 。2 Symons 先生不但作为 MarkII 功能点标准的创始人，最近他又作为 COSMIC 功能点标准的度量委员会成员，积极倡导 COSMIC 功能点标准的推广与应用。笔者曾在 2007 年与 Symons 先生在罗马有一面之缘，Symons 先生是一位睿智和蔼的长者，对于功能点标准在软件行业的应用多有真知灼见。3 Self-consistent state 逻辑完整的状态，说明事务功能已经完成，不存在只有输入或者只有输出的
