项目度量
项目度量是针对软件开发项目的特定度量，目的在于度量项目规模、项目成本、项目进度、顾客满意度等，辅助项目管理进行项目控制。
规模度量
软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾客需求的“交期逆推法”。
软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种，如：功能点分析(FPA：function points analysis)、代码行(LOC：lines of code)、德尔菲法(Delphi technique)、COCOMO模型、特征点(feature point)、对象点(object point)、3-D功能点(3-D function points)、Bang度量(DeMarco's bang metric)、模糊逻辑(fuzzy logic)、标准构件法(standard component)等，这些方法不断细化为更多具体的方法。
1. 功能点分析法
（1）功能点分析法概述
功能点分析法(FPA：function point analysis)是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。FPA法由IBM的工程师艾伦·艾尔布策(Allan Albrech)于20世纪70年代提出，随后被国际功能点用户协会(IFPUG：The International Function Point Users' Group)提出的IFPUG方法继承，从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是：“在外部式样确定的情况下可以度量系统的规模”，“可以对从用户角度把握的系统规模进行度量”。功能点可以用于“需求文档”、“设计文档”、“源代码”、“测试用例”度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。经由ISO组织已经有多种功能点估算方法成为国际标准，如：①加拿大人艾伦·艾布恩(Alain Abran)等人提出的全面功能点法(full function points)；②英国软件度量协会(UKSMA：United Kingdom Software Metrics Association)提出的IFPUG 功能点法(IFPUG function points)；③英国软件度量协会提出的Mark II FPA功能点法(Mark II function points)；④荷兰功能点用户协会(NEFPUG：Netherlands Function Point Users Group)提出的NESMA 功能点法，以及软件度量共同协会(COSMIC：the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法，这些方法都属于艾尔布策功能点方法的发展和细化。
（2）功能点分析法的基本计数
功能点分析的基本计数就是依据标准计算出的系统(或模块)中所含每一种元素的数目：
①外部输入数(EI：external input)：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。
②外部输出数(EO：external output)：计算每个用户输出，它们向软件提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单独计算。
③外部查询数(EQ：external query)：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。
④内部逻辑文件(ILF：internal logical file)：计算每个逻辑的主文件，如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件。
⑤外部接口文件(EIF：external interface file)：计算所有机器可读的接口，如磁带或磁盘上的数据文件，利用这些接口可以将信息从一个系统传送到另一个系统。
（3）功能点分析的主要步骤
功能点分析可以按照如图5-6所示步骤进行：
图5-6 功能点分析的主要步骤
（4）案例：CSK株式会社的功能点分析案例
【CSK株式会社的CSFPA概述】
在实施CSFPA之前，CSK以Step数方法来估算开发规模。但是在利用VB、C++、Java、SQL等语言的项目开发中，用Step数方法进行规模估算比较困难。为了以定量化手段降低甚至消除估算错误，CSK在IFPUG(International Function Point Users Group)的FP法的基础上加以改良开发出自身的CSFPA(CSK Simplified Function Point Analysis)法，并在企业内加以实施。CSK于1995年加入IFPUG组织，并于1998年开始正式开展活动。
CSFPA改良的两点是：增加了度量要件定义等上游工程的简易测量功能；避免使用人为因素太强的调整系数。CSFPA法适用体制在项目估算时的FP度量、项目完成时的FP度量、实际数据的收集、统计分析、工数模型化、质量指标化等方面具有CSK特有的方式，CSK在该方法的教育与培训、模型构筑、估算·质量计划的适用、结果评价·差异分析等方面取得了良好的绩效。
【CSFPA法的估算步骤】
CSFPA法与IFPUG法的估算步骤有所不同，二者的相似点以及不同点请参照图5-7。
图5-7 CSFPA功能点估算步骤
【CSFPA法的推广运用】
为了普及和适用CSFPA，CSK在企业内设立由多名专任人员组成的事务局，推进方法的定义以及维护、管理、员工教育、度量支援、数据收集、统计分析、数据利用等。下面对CSFPA的适用体制加以介绍。
项目估算时的FP度量。在估算时度量软件规模，通过适用相应的工数模型测算预计工数，以此作为制定日程的根据。CSFPA的工数模型以开发的全过程为对象，按照项目的开发范围进行估算，将式样、品质、技术的对应要件作为变动要素对此加以调整。
项目完成时的FP度量。在项目完成阶段对FP数、使用环境、技术、工数以及质量信息等几十个项目加以记录，比较估算时的FP数并进行差异分析，以提升度量精度和模型有效性。
实际数据的收集。将度量的实际数据剃除异常点后纳入数据库，并加以分析，然后向全企业公开。这种标本数据已经超过400件。由于FP度量过程中由于度量者的不同可能导致较大的误差，事务局还面向经验甚浅的度量者提供现场支持，验证度量结果的妥当性，提高度量的精度。另外，还与其他企业所提供的数据进行比较验证，持续收集数据。
统计分析。对于收集起来的数据，还需要考虑到项目特性的差异并加以分析。作为分析的界限，CSK建立了包括约50种类型(可视化工具类开发、Web类开发、维护的主框架开发等)的数据库，并对各自包括工数在内的10种以上的项目和FP值实施相关分析。
工数模型化。CSK将FP数和工数的关系称之为“工数模型”，现在已经拥有可适用的6种工数模型。这些模型与实际数据的收集相配合，实施差异分析，持续提升估算精度。
质量指标化。与工数模型一样，CSK将FP数和质量数据(缺陷、问题等)之间的相关关系作为质量模型加以提供。通过定义经由质量模型获得的指标，并与现存的指标相结合，构筑综合性的质量指标。
【CSK推进FP法的经验总结】
度量方法的教育与渗透—— 启蒙。要使用FP法进行度量，当然需要了解度量规则。CSK在其“项目管理研修”这一体制中，对企业员工实施教育，讲解FP法的定位、概要、使用方法，进行度量演习，让企业员工掌握FP法。
模型构筑—— 提升估算精度的路径。要使用各种模型提升估算的精度，需要度量项目特性以及仔细检查数据。CSK通过现场调研和支援活动，积累起专业知识和技能，并对技术、式样、质量方面的特性信息加以整理，构筑适合CSK的估算模型，提高估算精度。
估算·质量计划的适用—— 制定适当而正确的计划。构筑起来的模型在实际提案的时候作为估算的根据或者在产品的质量计划制定过程中适用。在模型不断适用的情况下，这些模型的适用实例也就逐渐丰富起来。
结果评价·差异分析—— 取得反馈信息至更高水平的运用。项目开发过程中，变更点管理以及计划与实绩的差异分析非常重要。在这个过程中，需要获得适当的反馈信息，在把握复杂的项目状况的同时需要灵活应对这些变更和反馈。CSK在这方面也在积极运作并在整个企业内展开。
【CSK功能点法今后的展开】
将FP作为商务活动中的共通尺度是CSK导入FP法的主要目的之一。为了提高CSK与顾客之间将之作为共通尺度的认知度，CSK认为需要实施如下事项：一是提高方法本身的认知度和信赖性；二是客观地验证度量数据的精度。FP是度量软件规模的手段，在软件开发的商务活动、项目管理、资产管理等诸多场合中都是切实把握规模的依据，是以适当的价格提供高质量软件的基础，也是客观性表示CSK的生产性的重要因素。CSK在通信、控制、嵌入式开发中正在试用COSMIC-FFP。
2. 代码行
代码行(line of code)指所有的可执行的源代码行数，包括可交付的工作控制语言(JCL：job control language)语句、数据定义、数据类型声明、等价声明、输入/输出格式声明等。一代码行(1LOC)的价值和人月均代码行数可以体现一个软件组织的生产能力。组织可以根据对历史项目的审计来核算组织的单行代码价值。代码行LOC常用于源代码的规模估算，常使用的单位有：SLOC(single line of code)、KLOC(thousand lines of code)、LLOC(logical line of code)、PLOC(physical line of code)、NCLOC (non-commented line of code)、DSI(delivered source instruction)。
3. 德尔菲法
德尔菲法(Delphi technique)是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来、新技术与特定程序之间的差别，但专家“专”的程度及对项目的理解程度是工作中的难点，尽管德尔菲技术可以减轻这种偏差，在评定一个新软件实际成本时通常用得不多，但是，这种方式对决定其他模型的输入时特别有用。德尔菲法鼓励参加者就问题相互讨论。德尔菲法的步骤是：(1)协调人向各专家提供项目规格和估算表格；(2)协调人召集小组会和各专家讨论与规模相关的因素；(3)各专家匿名填写迭代表格；(4)协调人整理出一个估算总结，以迭代表的形式返回给专家；(5)协调人召集小组会，讨论较大的估算差异；(6)专家复查估算总结并在迭代表上提交另一个匿名估算；(7)重复4～6，直到最低估算和最高估算一致。
4. 构造性成本模型
构造性成本模型(COCOMO：constructive cost model)是一种精确、易于使用的基于模型的成本估算方法，最早由勃姆(Boehm)于1981年提出。该模型按其详细程度分为3级：基本COCOMO模型、中间COCOMO模型和详细COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的源代码行数(LOC)为自变量的函数来计算软件开发工作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发工作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中分析、设计等各步骤的影响。COCOMO模型具有估算精确、易于使用的特点。在该模型中使用的基本量有以下几个：(1)DSI(源指令条数)，定义为代码行数，包括除注释行以外的全部代码。若一行有两个语句，则算做一条指令。(2)MM(度量单位为人月)表示开发工作量。(3)TDEV(度量单位为月)表示开发进度，由工作量决定。(4)COCOMO模型重点考虑15种影响软件工作量的因素，并通过定义乘法因子，从而准确、合理地估算软件的工作量。
成本度量
软件开发成本度量主要指软件开发项目所需的财务性成本的估算。主要方法如下：
类比估算法。类比估算法是通过比较已完成的类似项目系统来估算成本，适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目。其约束条件在于必须存在类似的具有可比性的软件开发系统，估算结果的精确度依赖于历史项目数据的完整性、准确度以及现行项目与历史项目的近似程度。
细分估算法。细分估算法是将整个项目系统分解成若干个小系统，逐个估算成本，然后合计起来作为整个项目的估算成本。细分估算法通过逐渐细化的方式对每个小系统进行详细的估算，可能获得贴近实际的估算成本。其难点在于，难以把握各小系统整合为大系统的整合成本。
周期估算法。周期估算法是按软件开发周期进行划分，估算各个阶段的成本，然后进行汇总合计。周期估算法基于软件工程理论对软件开发的各个阶段进行估算，很适合瀑布型软件开发方法，但是需要估算者对软件工程各个阶段的作业量和相互间的比例具有相当的了解。
顾客满意度度量
顾客满意是软件开发项目的主要目的之一，而顾客满意目标要得以实现，需要建立顾客满意度度量体系和指标对顾客满意度进行度量。顾客满意度指标(CSI：customer satisfaction index)以顾客满意研究为基础，对顾客满意度加以界定和描述。项目顾客满意度量的要点在于：确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性，并以此建立产品、服务质量的衡量指标和标准。企业顾客满意度度量的标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所不同。比如：NEC于2002年12月开始实施的CSMP 活动的度量尺度包括共感性、诚实性、革新性、确实性和迅速性，其中，将共感性和诚实性作为CS活动的核心姿态，而将革新性、确实性和迅速性作为提供商品和服务中不可或缺的尺度。每个尺度包括两个要素，各要素包括两个项目，共计5大尺度、10个要素和20个项目。例如，共感性这一尺度包括“了解顾客的期待”、“从顾客的立场考虑问题”这两个要素；“了解顾客的期待”这一要素又包括“不仅仅能胜任目前的工作还能意识到为顾客提供价值而专心投入”、“对顾客的期望不是囫囵吞枣而是根据顾客的立场和状况来思考‘顾客到底需要什么’并加以应对”这两个项目。
美国专家斯蒂芬(Stephen H.Kan)在《软件质量工程的度量与模型》(Metrics and Models in Software Quality Engineering)中认为，企业的顾客满意度要素如表5-11所示：
表5-11 顾客满意度要素及其内容
顾客满意度要素 | 顾客满意度要素的内容 |
技术解决方案 | 质量、可靠性、有效性、易用性、价格、安装、新技术 |
支持与维护 | 灵活性、易达性、产品知识 |
市场营销 | 解决方案、接触点、信息 |
管理 | 购买流程、请求手续、保证期限、注意事项 |
交付 | 准时、准确、交付后过程 |
企业形象 | 技术领导、财务稳定性、执行印象 |
作为企业的顾客满意度的基本构成单位，项目的顾客满意度会受到项目要素的影响，主要包括：开发的软件产品、开发文档、项目进度以及交期、技术水平、沟通能力、运用维护等等。具体而言，可以细分为如表5-12所示的度量要素，并根据这些要素进行度量。
表5-12 顾客满意度项目度量要素
顾客满意度项目 | 顾客满意度度量要素 |
软件产品 | 功能性、可靠性、易用性、效率性、可维护性、可移植性 |
开发文档 | 文档的构成、质量、外观、图表以及索引、用语 |
项目进度以及交期 | 交期的根据、进度迟延情况下的应对、进展报告 |
技术水平 | 项目组的技术水平、项目组的提案能力、项目组的问题解决能力 |
沟通能力 | 事件记录、式样确认、Q&A |
运用维护 | 支持、问题发生时的应对速度、问题解决能力 |
产品度量
软件质量的生命周期及其度量
软件产品度量用于对软件产品进行评价，并在此基础之上推进产品设计、产品制造和产品服务优化。软件产品的度量实质上是软件质量的度量，而软件的质量度量与其质量的周期密切相关，如图5-8所示：
图5-8 软件质量的生命周期及其度量
软件质量度量模型
软件产品的度量主要针对作为软件开发成果的软件产品的质量而言，独立于其过程。软件的质量由一系列质量要素组成，每一个质量要素又由一些衡量标准组成，每个衡量标准又由一些量度标准加以定量刻划。质量度量贯穿于软件工程的全过程以及软件交付之后，在软件交付之前的度量主要包括程序复杂性、模块的有效性和总的程序规模，在软件交付之后的度量则主要包括残存的缺陷数和系统的可维护性方面。一般情况下，可以将软件质量特性定义成分层模型。勃姆(Barry W. Boehm)在《软件风险管理》(Software Risk Management)中第一次提出了软件质量度量的层次模型。而麦考尔(McCall)等人将软件质量分解至能够度量的层次，提出FCM 3层模型(参见表5-13)：软件质量要素(factor)、衡量标准(criteria)和量度标准(metrics)，包括11个标准，分为产品操作(product operation)、产品修正(product revision)和产品转移(product transition)。ISO 9126将软件质量总结为6大特性，每个特性包括一系列副特性，其软件质量模型包括3层，即高层：软件质量需求评价准则(SQRC)；中层：软件质量设计评价准则(SQDC)；低层：软件质量度量评价准则(SQMC)。
表5-13 软件质量度量FCM模型
层 级 | 名 称 | 内 容 |
第一层 | 质量要素：描述和评价软件质量的一组属性 | 功能性、可靠性、易用性、效率性、可维护性、可移植性等质量特性以及将质量特性细化产生的副特性 |
第二层 | 衡量标准： 衡量标准的组合反映某一软件质量要素 | 精确性、稳健性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、文件完备性等 |
第三层 | 量度标准： 可由各使用单位自定义 | 根据软件的需求分析、概要设计、详细设计、编码、测试、确认、维护与使用等阶段，针对每一个阶段制定问卷表，以此实现软件开发过程的质量度量 |
凯悦(Lawrence E. Hyatt)和罗森贝克(Linda H. Rosenberg)在《识别项目风险以及评价软件质量的软件质量模型与度量》(A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality)中比较了这3种最常用的软件质量模型，其基本情况如表5-14所示。
表5-14 3种软件质量模型之比较
度量标准/目标 | 麦 考 尔 | 勃 姆 | ISO 9126 |
正确性(Correctness) | X | X | 可维护性 |
可靠性(Reliability) | X | X | X |
完整性(Integrity) | X | X | |
可用性(Usability) | X | X | X |
效率性(Efficiency) | X | X | X |
可维护性(Maintainability) | X | X | X |
可测试性(Testability) | X | | 可维护性 |
互操作性(Interoperability) | X | | |
适应性(Flexibility) | X | X | |
可重用性(Reusability) | X | X | |
可移植性(Portability) | X | X | X |
明确性(Clarity) | | X | |
可变更性(Modifiability) | | X | 可维护性 |
文档化(Documentation) | | X | |
恢复力(Resilience) | | X | |
易懂性(Understandability) | | X | |
有效性(Validity) | | X | 可维护性 |
功能性(Functionality) | | | X |
普遍性(Generality) | | X | |
经济性(Economy) | | X | |
软件质量度量方法
软件质量度量方法比较多，例如：(1)Halstead复杂性度量法，基本思路是根据程序中可执行代码行的操作符和操作数的数量来计算程序的复杂性。操作符和操作数的量越大，程序结构就越复杂。(2)McCabe复杂性度量法，其基本思想是程序的复杂性很大程度上取决于程序控制流的复杂性，单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。
过程度量
软件过程性能
过程度量是对软件开发过程的各个方面进行度量，目的在于预测过程的未来性能，减少过程结果的偏差，对软件过程的行为进行目标管理，为过程控制、过程评价持续改善提供定量性基础。过程度量与软件开发流程密切相关，具有战略性意义。软件过程质量的好坏会直接影响软件产品质量的好坏，度量并评估过程、提高过程成熟度可以改进产品质量。相反，度量并评估软件产品质量会为提高软件过程质量提供必要的反馈和依据。过程度量与软件过程的成熟度密切相关，其度量模型如图5-9所示：
图5-9 软件过程性能的度量模型
软件过程管理中的过程度量
弗罗哈克(William A.Florac)、帕克(Robert E.Park)和卡尔顿(Anita D.Carleton)在《实用软件度量：过程管理和改善之度量》(Practical Software Measurement：Measuring for Process Management and Improvement)中描述了过程管理和项目管理的关系。认为软件项目团队生产产品基于三大要素：产品需求、项目计划和已定义软件过程。度量数据在项目管理中将被用来：(1)识别和描述需求，(2)准备能够实现目标的计划，(3)执行计划，(4)跟踪基于项目计划目标的工作执行状态和进展。而过程管理也能使用相同的数据和相关度量来控制和改善软件过程本身。这就意味着，软件组织能使用建构和维持度量活动的共同框架来为过程管理和项目管理两大管理功能提供数据。
软件过程管理包括定义过程、计划度量、执行软件过程、应用度量、控制过程和改善过程，其中计划度量和应用度量是软件过程管理中的重要步骤，也是软件过程度量的核心内容。计划度量建立在对已定义软件过程的理解之上，产品、过程、资源的相关事项和属性已经被识别，收集和使用度量以进行过程性能跟踪的规定都被集成到软件过程之中。应用度量通过过程度量将执行软件过程所获得的数据，以及通过产品度量将产品相关数据用来控制和改善软件过程。
软件过程度量的内容
软件过程度量主要包括三大方面的内容，一是成熟度度量(maturity metrics)，主要包括组织度量、资源度量、培训度量、文档标准化度量、数据管理与分析度量、过程质量度量等等；二是管理度量(management metrics)，主要包括项目管理度量(如里程碑管理度量、风险度量、作业流程度量、控制度量、管理数据库度量等)、质量管理度量(如质量审查度量、质量测试度量、质量保证度量等)、配置管理度量(如式样变更控制度量、版本管理控制度量等)；三是生命周期度量(life cycle metrics)，主要包括问题定义度量、需求分析度量、设计度量、制造度量、维护度量等。
软件过程度量流程
软件过程的度量，需要按照已经明确定义的度量流程加以实施，这样能使软件过程度量作业具有可控制性和可跟踪性，从而提高度量的有效性。软件过程度量的一般流程主要包括：确认过程问题；收集过程数据；分析过程数据；解释过程数据；汇报过程分析；提出过程建议；实施过程行动；实施监督和控制。这一度量过程的流程质量能保证软件过程度量获得有关软件过程的数据和问题，并进而对软件过程实施改善。
