过程和项目度量概述 课件

SoftwareProjectManagement第2讲过程和项目度量主讲：张纲强SoftwareProjectManagement第21过程领域和项目领域中的度量主要内容软件测量软件质量度量有软件过程中集中度量小型组织的度量制定软件度量大纲过程领域和项目领域中的度量主要内容软件测量软件质量度量有软件2通过提供目标评估的机制，测量使我们能够对项目和过程有更深入的了解。Lord

Kelvin曾经说过：

当你能够测量你所说的事物，并能用数字表达它时，你就对它有了一定的了解；但当你不能测量它，也不能用数字表达时，就说明你对它的了解还很贫乏，不令人满意：这可能是知识的开始，但你在思想上还远远没有进入科学的境地。测量可以应用于软件过程中，目的是持续地改进软件过程。测量也可以应用于整个软件项目中，辅助进行估算、质量控制、生产率评估及项目控制。最后，软件工程师还可以使用测量来帮助评估工作产品的质量，并在项目进展过程中辅助进行战术决策。通过提供目标评估的机制，测量使我们能够对项3进行测量的理由：刻画－通过刻画而获得对过程、产品、资源和环境的了解，并建立同未来评估进行比较的基线；评价－通过评价来确定相对于计划的状况；预测－通过理解过程和产品间的关系，并构造这些关系的模型来进行预测；改进－通过识别障碍、根本原因、低效率和其他改进产品质量和过程性能的机会来进行改进。测量是一个管理工具，如果能正确地使用，它将为项目管理者提供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使项目成功的决策。进行测量的理由：4测度、度量和指标测度、度量和指标5测度、度量和指标虽然术语“measure”(测量)、“measurement”(测度)和“metrics”(度量)经常被互换地使用，但注意到它们之间的细微差别是很重要的。因为“measure”(测量)和“Measurement”(测度)既可以作为名词也可以作为动词，所以它们的定义可能会混淆。在软件工程领域中，“measure”(测量)对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个定量的指示。“Measurement”(测度)则是确定一个测量的行为。IEEE的软件工程术语标准辞典(IEEE

Standard

Glossary

of

Software

Engineering

Terms)［IEE93］中定义“metric”(度量)为“对一个系统、构件或过程具有的某个给定属性的度的一个定量测量”。6测度、度量和指标虽然术语“measure”(测量)、“mea测度、度量和指标当获取到单个的数据点(如在一个模块的复审中发现的错误数)时，就建立了一个测量。测度的发生是收集一个或多个数据点的结果(如调研若干个模块的复审，以收集每一次复审所发现的错误数的测量)。软件度量在某种程度上与单个的测量相关(如每一次复审所发现的错误的平均数，或复审中每人/小时所发现的错误的平均数)。软件工程师收集测量结果并产生度量，这样就可以获得指标“indicator”。指标是一个度量或度量的组合，它对软件过程、软件项目或产品本身提供了更深入的了解［RAG95］。指标所提供的更深入的理解，使得项目管理者或软件工程师能够调整开发过程、项目或产品，这样使事情进行得更顺利，能被更好地完成。7测度、度量和指标当获取到单个的数据点(如在一个模块的复审中发过程领域和项目领域中的度量过程领域和项目领域中的度量8过程领域和项目领域中的度量测量在工程界中是常事。我们测量动力消耗、重量、物理体积、温度、电压、信号—噪音比……不胜枚举。过程度量的收集涉及所有的项目，而且要经历相当长的时间，目的是提供能够引导长期的软件过程改进的一组过程指标。项目度量使得软件项目管理都能够：(1)评估正在进行的项目的状态；(2)跟踪潜在的风险；(3)在问题造成不良影响之前发现它们；(4)调整工作流程或任务；(5)评估项目团队控制软件工程工作产品质量的能力。测量数据由项目团队收集，然后被转换成度量数据在项目期间使用。测量数据也可传送给那些负责软件过程改进的人员。因此，很多相同的度量既可以用于过程领域，又可用于项目领域。9过程领域和项目领域中的度量测量在工程界中是常事。我们测量动力过程领域和项目领域中的度量过程度量和软件过程改进改进任何过程的唯一合理的方法是测量该过程的特定属性，再根据这些属性建立一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。但是，在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程仅是众多“改进软件质量和组织性能的控制因素”中的一种［PAU94］。图2－1软件质量和组织有效性的决定因素在图2－1中，过程位于三角形的中央，连接了三个对软件质量和组织绩效有重大影响的因素。人员的技能和激励被认为是对质量和绩效最有影响的因素［BOE81］。产品复杂性对质量和团队绩效也有相当大的影响。过程中采用的技术(如软件工程方法)也有影响。另外，过程三角形存在于环境条件的圆圈之内，环境条件包括：开发环境(如CASE工具)、商业条件(如交付期限，业务规则)、客户特性(如通信的容易程度)。10过程领域和项目领域中的度量过程度量和软件过程改进改进任何过程过程领域和项目领域中的度量过程度量和软件过程改进我们可以间接地测量一个软件过程的功效。也就是说，我们可以根据从过程中获得的结果导出一组度量。这些结果包括：在软件发布之前发现的错误数的测量，交付给最终用户并由最终用户报告的缺陷的测量，交付的工作产品的测量，花费的工作量的测量，花费的时间的测量，与进度计划是否一致的测量，以及其他测量。我们还可以通过测量特定软件工程任务的特性来导出过程度量。如测量一般软件工程活动所花费的工作量和时间。11过程领域和项目领域中的度量过程度量和软件过程改进我们可以间接过程领域和项目领域中的度量过程度量和软件过程改进不同类型的过程数据的使用可以分为“私有的和公用的”。因为某个软件工程师可能对在其个人基础上收集的度量的使用比较敏感，这是很自然的，这些数据对此人应该是私有的，是仅供此人参考的指标。私有度量的例子有据：

个人缺陷率软件构件缺陷率开发过程中发现的错误数。私有过程数据是软件工程师个人改进其工作的重要驱动力。12过程领域和项目领域中的度量过程度量和软件过程改进不同类型的过过程领域和项目领域中的度量过程度量和软件过程改进某些过程度量对软件项目团队是私有的，但对所有团队成员是公用的。例如：主要软件功能(由多个开发人员完成)的缺陷报告、正式技术复审中发现的错误、以及每个构件或功能的代码行数或功能点数。这些数据可由团队进行复查，以找出能够改善小组性能的指标。

公用度量一般吸取了原本是个人的或团队的私有信息。收集和评估项目级的缺陷率(肯定不能归因于某个个人)、工作量、时间及相关的数据，以找出能够改善组织过程性能的指标。13过程领域和项目领域中的度量过程度量和软件过程改进某些过程度量过程领域和项目领域中的度量过程度量和软件过程改进软件度量规则：解释度量数据时使用常识，并考虑组织的敏感性。

向收集测量和度量的个人及团队定期提供反馈。不要使用度量去评价个人。

与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。

不要用度量去威胁个人或团队。指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。

不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。14过程领域和项目领域中的度量过程度量和软件过程改进软件度量规则过程领域和项目领域中的度量项目度量软件过程度量主要用于战略的目的。软件项目度量则是战术的。即，项目管理者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项目工作流程和技术活动。在大多数软件项目中，项目度量的第一个应用是在估算阶段。从过去的项目中收集的度量可以作为估算当前软件工作工作量及时间的基础。随着项目的进展，可以将花费的工作量及时间的测量与最初的估算值(及项目进度)进行比较。项目管理者可以使用这些数据来监控项目的进展。随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，需要收集技术度量来评估设计质量，并提供若干指标，这些指标将会影响代码生成及测试所采用的方法。15过程领域和项目领域中的度量项目度量软件过程度量主要用于战略的过程领域和项目领域中的度量项目度量项目度量的目的是双重的。首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改进质量。

随着质量的提高，错误会减到最小，而随着错误数的减少，项目中所需的修改工作量也会降低。这就导致整个项目成本的降低。16过程领域和项目领域中的度量项目度量项目度量的目的是双重的。1软件测量软件测量17软件测量测量在现实世界中可分为两类：直接测量(如螺钉的长度)和间接测量(如生产的螺钉的“质量”，由计算其次品率来测量)。软件测量也有两种分类方法：

软件工程过程的直接测量，包括花费的成本和工作量；产品的直接测量，包括产生的代码行(lines

of

code，LOC)、运行速度、内存大小及某段时间内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性及许多其他的“产品特性”。18软件测量测量在现实世界中可分为两类：直接测量(如螺钉的长度)软件测量将项目度量联合起来可以得到整个软件组织公用的过程度量。但是，一个组织如何将来自不同个人或项目的度量结合起来呐？

为了说明这个问题，我们看一个简单的例子：两个不同项目团队中的人将他们在软件工程过程中所发现的所有错误进行了记录和分类。然后，将这睦个人的测量结合起来就产生了团队的测量。在软件发布前，团队A在软件过程中发现了342个错误，团队B发现了184个错误。所有其他情况都相同，那么在整个过程中哪个团队能更有效地发现错误呢？因为不知道项目的规模或复杂性，所以我们不能回答这个问题。不过，如果度量采用规范化的方法，就有可能产生能够在更大的组织范围内进行比较的软件度量。如此说来，面向规模的度量和面向功能的度量都是规范化的方法。19软件测量将项目度量联合起来可以得到整个软件组织公用的过程度量软件测量面向规模的度量面向规模的软件度量是通过规范化质量和（或）生产率的测量值而得到的，这些测量都基于已经开发的软件的“规模”。如果软件组织一直在做简单的记录，就会产生一个如图2－2所示的面向规模测量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量数据。查看alpha项目的数据(图2－2)：花费了24个人·月的工作量，成本为168000美元，产生了12100行代码。应该注意到表中记录的工作量和成本涵盖了所有软件工程活动(分析、设计、编码及测试)，而不仅仅是编码。alpha项目更进一步的信息包括：产生了365页的文档；在软件发布之前，发现了134个错误；软件发布给客户之后运行的第一年中遇到了29个缺陷；有3个人参加了alpha项目的软件开发工作。20软件测量面向规模的度量面向规模的软件度量是通过规范化质量和（图2－2面向规模的度量图2－2面向规模的度量21软件测量面向规模的度量为了产生能和其他项目中同类度量进行比较的度量，我们选择代码行作为规范化值。根据表中所包含的基本数据，每个项目都能产生一组简单的面向规模度量：每千行代码(KLOC)的错误数。

每千行代码(KLOC)的缺陷数。每千行代码(KLOC)的成本。每千行代码(KLOC)的文档页数。

除此之外，还能够计算出其他有意义的度量：

每人·月错误数。每人·月千代码行(KLOC)。每页文档的成本。22软件测量面向规模的度量为了产生能和其他项目中同类度量进行比较软件测量面向规模的度量面向规模的度量并不被普遍认为是测量软件开发过程的最好方法［JON86］。大多数的争议都是围绕着使用代码行(LOC)作为关键的测量是否合适。LOC测量的支持者们声称LOC是所有软件开发项目的“生成品”，并且很容易进行计算；许多现有的软件估算模型使用LOC或KLOC作为关键的输入，并且已经有大量的文献和数据涉及到LOC。另一方面，反对者们则认为LOC测量依赖于程序设计语言；它们对设计得很好，但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以得到的信息(如，早在分析和设计完成之前，计划者就必须估算出要产生的LOC)。23软件测量面向规模的度量面向规模的度量并不被普遍认为是测量软件软件测量面向功能的度量面向功能的软件度量使用功能（由应用系统提供）测量数据作为规模化值。应用最广泛的面向功能的度量是功能点（FunctionPoint,FP）。功能点是根据软件信息域的特性及复杂性来计算的。与LOC测量一样，功能点测量也是有争议的。支持者们认为FP与程序设计语言无关，对于使用传统语言和非过程语言应用系统来说，它都比较理想的；而且它所依据的数据是在项目开发初期就可能得到的数据。因此，作为一种估算方法，FP更有吸引力。反对者们则声称这种方法需要某种“熟练手法”，因为计算的依据是主观的而非客观的数据，信息域（及其他方面）的计算可能难以在事后收集。而且FP没有直接的物理意义，它仅仅是一个数字而已。24软件测量面向功能的度量面向功能的软件度量使用功能（由应用系统软件测量调和代码行和功能点的度量方法代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。很多研究试图将FP测量和LOC测量联系起来。引用Albrecht和Gaffney［ALB83］的话说：本研究的论点是：应用(程序)所提供的功能数能够从所使用的数据或提供的数据的主要组成部分的详细记录中估算出来，或是直接从记录中得到。更进一步，功能的估算应该与要开发的LOC数及开发所需的工作量关联起来。表2-1［QSM02］给出了在不同的程序设计语言中实现一个功能点所需的平均代码行数的粗略估算：25软件测量调和代码行和功能点的度量方法代码行和功能点度量之间的过程和项目度量概述课件26过程和项目度量概述课件27查看上表可知：C++的一个LOC所提供的“功能性”大约是C的一个LOC的2.4倍（平均来讲）。而且，Smalltalk的一个LOC所提供的“功能性”至少是传统程序设计语言（如Ada、COBOL或C）的4倍。利用上表中所包含的信息，只要知道了程序设计语言的语句行数，就可以“逆向”估算出现有软件的功能点数量。软件测量调和代码行和功能点的度量方法基于功能点和LOC的度量都是对软件开发工作量和成本的比较精确的判定。然而，如果使用LOC和FP进行估算，还必须要建立一个历史信息基线。在过程度量和项目度量中，最关心的是生产率和质量－软件开发“输出量”（作为投入的工作量和时间的函数）的测量和对生产的工作产品的“适用性”测量。为了进行过程改进和项目策划，必须掌握历史的情况。在以往的项目中，软件开发的生产率是多少？生产的软件质量如何？怎样利用以往的生产率数据和质量数据推断现在的生产率和质量？如何利用这些数据帮助我们改进过程，以及更精确地规划新项目？28查看上表可知：C++的一个LOC所提供的“功能性”大约是C的传统的软件项目度量（LOC或FP）也可以用于估算面向对象的软件项目。但是，这些度量并没有提供对进度和工作量进行调整的粒度，而这却是我们在演化模型或增量模型中进行迭代时所需要的。用于OO项目的度量：场景脚本的数量关键类的数量支持类的数量每个关键偶氮染料平均支持类数量子系统的数量软件测量面向对象的度量29传统的软件项目度量（LOC或FP）也可以用于估算面向对象的软软件测量用于OO项目的度量场景脚本的数量场景脚本是一个详细的步骤序列，用来描述用户和应用系统之间的交互。应用系统的规模及测试用例的数量都与场景脚本的数量紧密相关。关键类的数量关键类是“高度独立的构件”，在面向对象分析的早期进行定义。由于关键类是问题域的核心，因此这些类的数量既是开发软件所需工作量的指标，也是系统开发中潜在的复用数量的指标。支持类的数量支持类是实现系统所必需的但又不与问题域直接相关的类。例如，UI类、数据库访问及操作类、计算类。另外，对于每一个关键类，都可以开发其支持类。支持类的数量既是开发软件所需工件量的指标，也是系统开中潜在的复用数量的指标。软件测量用于OO项目的度量场景脚本的数量30软件测量用于OO项目的度量每个关键类的平均支持类数量通常，关键类在项目的早期就可以确定下来，而支持类的定义则贯穿于项目的始终。对于给定的问题域，如果知道了每个关键类的平均支持类数量，估算（根据类的总数）将应得非常简单。在采用GUI的应用中，支持类是关键类的2~3倍；在不采用GUI的应用中，支持类是关键类的1~2倍。子系统的数量子系统是实现某个功能（对系统最终用户可见）的类的集合。一旦确定了子系统，人们就更容易制定出合理的进度计划，并将子系统的工作在项目人员之间进行分配。软件测量用于OO项目的度量每个关键类的平均支持类数量31软件测量面向对象的度量为了将类似于上述的那些度量有效地应用于面向对象的软件工程环境中，必须将它们随同项目测量（例如花费的工作量、发现的错误和缺陷、建立的模型或文档资料）一起收集。随着数据库规模的增长（在完成大量项目之后），面向对象的测量数据和项目测量数据之间关系将提供有助于项目估算的度量。软件测量面向对象的度量为了将类似于上述的那些度量有效地应用于32软件测量面向用例的度量与LOC或FP相类似，使用用例作为规范化的测量应该是合理的。同FP一样，用例也是在软件过程早期进行定义的。在重大的建模活动和构造活动开始之前，就允许使用用例进行估算。用例描述了（至少是间接地）用户可见的功能和特性，这些都是系统的基本需求。用例与程序设计语言无关。另外，用例数量同应用系统的规模（LOC）和测试用例的数量成正比，而测试用例是为了充分测试该应用系统而必须设计的。由于可以在不同的抽象级别上创建用例，所以用例的大小没有标准。由于对用例本身还没有标准的测量，因此将用例作为规范化的测量（如，每个用例花费的工作量）是不可信的。尽管许多研究人员试图推导出用例度量，但仍有很工作要做。软件测量面向用例的度量与LOC或FP相类似，使用用例作为规33软件测量Web工程项目度量所有Web工程项目的目标都是建立一个Web应用（WebApp），交付给最终用户一个内容和功能的结合体。很难将那些用于传统软件工程项目的测量和度量直接转化应用于Web应用系统中。然而，Web工程组织应该建立一个数据库，随着大量项目的完成，就可以使用该数据库来评估组织内部的生产率和质量。在这些测量中，可以收集的有：静态Web页的数量动态Web页的数量内部页面链接的数量永久数据对象的数量通过界面连接的外部系统的数量静态内容对象的数量动态内容对象的数量可执行的功能数量软件测量Web工程项目度量所有Web工程项目的目标都是建立34软件测量Web工程项目度量静态Web页的数量静态内容的Web页（即最终用户不能控制页面显示的内容）是所有Web应用系统最普通的特征。这些页面复杂性较低，通常构造静态页面所需的工作量少于动态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系统所需的工作量。动态Web页的数量在所有的电子商务应用、搜索引擎、金融应用以及许多其他Web应用中，动态内容的Web页（即根据最终用户的操作，页面上显示出相应的定制内容）是必需的要素。动态页面复杂性较高，构造动态页面所需的工作量高于静态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系统所需的工作量。软件测量Web工程项目度量静态Web页的数量35软件测量Web工程项目度量内部页面链接的数量内部页面链接就是一个指针，它在Web应用中提供了到达其他某个Web页的超链接。这项测量提供了一个Web应用内部结构互连程度的指标。随着页面链接的增加，花费在导航设计和开发上的工作量也会增加。永久数据对象的数量Web应用可以访问一个或多个永久数据对象（如数据库或数据文件）。随着永久数据对象数量的增加，Web应用系统的复杂性也会增加，实现应用系统所需的工作量也会成比例地增加。软件测量Web工程项目度量内部页面链接的数量36软件测量Web工程项目度量通过界面连接的外部系统的数量Web应用系统必须经常与“后台的”业务应用相连接。随着界面连接需求的增多，系统复杂性和开发工作量也会增加。静态内容对象的数量静态内容对象包括静态文本、图像、视频、动画和音频信息，它们在Web应用中被集成在一起。在一个Web页中，可能同时出现多个内容对象。软件测量Web工程项目度量通过界面连接的外部系统的数量37软件测量Web工程项目度量动态内容对象的数量动态内容对象是根据最终用户的操作而产生的，包括内部产生的文本、图像、视频、动画和音频信息，它们在Web应用中被集成在一起。在一个Web页中，可能同时出现多个内容对象。可执行的功能的数量可执行的功能（如，脚本和小程序）为最终用户提供了某些计算服务。随着可执行功能数量的增加，建模和构造的工作量也会随之增加。软件测量Web工程项目度量动态内容对象的数量38软件测量Web工程项目度量上面提到的每个测量都可以在Web工程过程的初期就确定下来。例如，我们可以定义一个度量，来反映Web应用所需的最终用户的定制程度，并使它与Web工程项目花费的工作量以及评审中发现的错误关联起来。为此，我们进行以下定义：

Nsp=静态Web页的数量

Ndp=动态Web页的数量

那么

定制指数C=Ndp/(Ndp+Nsp)

C的取值范围是0到1。随着C值的增大，Web应用的定制水平将成为一个重大的技术问题。类似的Web应用度量也呆以被计算出来，并同项目测量（如花费的工作量、发现的错误和缺陷、已建立的模型或文档）关联起来。随着数据库规模的扩大（在完成了很多项目之后），Web应用测量与项目测量之间的关系将提供有助于项目估算的指标。软件测量Web工程项目度量上面提到的每个测量都可以在Web39软件质量度量软件质量度量40软件质量度量软件工程的基本高目标就是在某个时间框架内开发出满足市场需要的高质量的系统、应用软件或产品。为了达到这个目标，软件工程师必须掌握在成熟的软件过程背景下，使用有效的方法及现代化的工具。此外，一个优秀的软件工程师(及优秀的软件工程管理者)必须通过测量来判断能否实现高质量。将软件工程师个人收集的私有度量结合起来，可以提供项目级的度量。虽然可以收集到很多质量测量数据，但在项目级上最主要的还是测量错误和缺陷的数目。从这些测量中导出的度量能够提供一个指标，表明个人及小组在软件质量保证和控制活动上的效率。度量－比如说工作产品（如需求或设计）－每功能点的错误数、在评审中每小时发现的错误数、及测试中每小时发现的错误数，使我们能够深入了解度量所涉及的活动的功效。有关错误的数据也能用来计算每个过程框架活动的缺陷排除率（defectremovalefficiency,DRE）

。41软件质量度量软件工程的基本高目标就是在某个时间框架内开发出满软件质量度量测量质量虽然有很多软件质量的测量方法，但对软件进行正确性、可维护性、完整性、及可用性的测量为项目组提供了有用的技术指标。Gilb［GIL88］给出了这些属性的定义及测量。正确性：一个程序必须能够正确地执行，否则对于用户就没有价值了。正确性是软件完成所要求的功能的程度。最常用的关于正确性的测量是每千行(KLOC)的缺陷数，这里缺陷是指已被证实不符合需求的地方。当考虑软件产品的的整体质量时，缺陷是指在程序发布后经过了全面使用，由程序用户报告的问题。为了进行质量评估，缺陷是按标准时间段来计数的，典型的是一年。软件质量度量测量质量虽然有很多软件质量的测量方法，但对软件进42软件质量度量测量质量可维护性：与任何其他软件工程活动相比，软件维护需要更多的工作量。可维护性是指遇到错误时程序能够被修改的容易程度，环境发生变化时程序能够适应的容易程度，用户希望变更需求时程序能被增强的容易程度。可维护性无法直接测量；因此我们必须采用间接测量。有一种简单的面向时间的度量，称为平均变更时间(mean-time-to-change，MTTC)。它包括分析变更请求、设计合适的修改方案、实现变更并进行测试、以有把该变更发布给全部用户所花的时间。一般情况下，与那些不可维护的程序相比，可维护的程序应有较低的MTTC(相对于相同类型的变更)。软件质量度量测量质量可维护性：与任何其他软件工程活动相比，软43软件质量度量测量质量完整性：在防火墙和在黑客时代，软件完整性已变得日益重要。这个属性测量的是一个系统对安全性攻击(包括偶然的和蓄意的)的抵抗能力。软件的所有三个成分（即程序、数据及文档）都会遭到攻击。为了测量完整性，必须定义另外两个属性：危险性和安全性。危险性是指一个特定类型的攻击在给定时间内发生的概率(能够估算或根据经验数据导出)。安全性是指一个特定类型的攻击将被击退的概率(能够估算或根据经验数据导出)。一个系统的完整性可以定义为：

完整性=Σ［1－危险性×(1－安全性)］例如，假设危险性（发生攻击的可能性）是0.25，安全性（击退攻击的可能性）是0.95，则系统的完整性是0.99（很高）；另一方面，假设危险性是0.5，击退攻击的可能性仅是0.25，则系统的完整性只有0.63（低得无法接受）。软件质量度量测量质量完整性：在防火墙和在黑客时代，软件完整性44软件质量度量测量质量可用性：如果一个程序不容易使用，即使它完成的功能很有价值，也常常注定要失败。可用性力图对“使用的容易程度”进行量化，根据四个特性来测量：(1)学会一个系统所需的体力的和/或智力的投入；(2)在系统的使用上达到中等效率所需的时间；(3)当系统由某个具有中等效率的人使用时，测量到的生产率的净增长(与被该系统替代的老系统相比)；以及(4)用户对系统的态度的一个主观评估(有时可以通过调查表获得)。上述的四个因素仅仅是被建议作为软件质量测量的众多因素中的一个样板。。软件质量度量测量质量可用性：如果一个程序不容易使用，即使它完45软件质量度量缺陷排除效率DRE缺陷排除效率（DRE）是在项目级和过程级都有意义的质量度量。本质上，DRE是对质量保证及控制活动的过滤能力的一个测量，而这些活动贯穿应用于所有过程框架活动中。当把项目作为一个整体来考虑时，DRE按如下方式定义：DRE=E/（E＋D）

其中E=软件交付给最终用户之前所发现的错误数D=软件交付之后所发现的缺陷数。软件质量度量缺陷排除效率DRE缺陷排除效率（DRE）是在项46软件质量度量缺陷排除效率DRE最理想的DRE值是1，即软件中没有发现缺陷。现实中，D会大于0，但随着E值的增加，DRE的值仍能接近1。事实上，随着E的增加，D的最终值可能会降低(错误在变成缺陷之前已经被过滤了)。如果DRE作为一个度量，提供关于质量控制和保证活动的过滤能力的衡量指标，则DRE就能促进软件项目团队采用先进的技术，力求在软件交付之前发现尽可能多的错误。软件质量度量缺陷排除效率DRE最理想的DRE值是1，即软件47软件质量度量缺陷排除效率DRE在项目内部，也可以使用DRE来评估一个团队在错误传递到下一个框架活动或软件工程任务之前发现错误的能力。例如，在需求分析任务中创建了一个分析模型，而且对该模型进行了评审以发现和改正其中的错误。那些在评审过程中未被发现的错误会传递给了设计（在设计中它们可能被发现，也可能不被发现）。在这种情况下，我们重新定义DRE为：DREi=Ei/(Ei＋Ei＋1)

其中Ei=在软件工程活动i中所发现的错误数;Ei＋1=在软件工程活动i＋1中所发现的错误数，这些错误都是在软件工程活动i中没被发现的错误。软件项目团队(或软件工程师个人)的质量目标是使DREi

接近1。即错误应该在传递到下一个活动之前被过滤掉。软件质量度量缺陷排除效率DRE在项目内部，也可以使用DR48在软件过程中集成度量在软件过程中集成度量49在软件过程中集成度量大多数软件开发者仍然没有进行测量，更可悲的是，他们中大多数根本没有开始测量的愿望。正如我们在本章开始所说的，这是文化的问题。试图收集过去从来没有人收集的测量常常会遇到阻力。备受折磨的项目经理会问“为什么我们要做这个？”。超负荷工作的开发者抱怨“我看不出这样做有什么用”。在本节中，我们要考虑一些有关软件度量的观点，并给出软件工程组织内部制定度量收集计划的方法。但在此这前，先看看Grady和Casewell[GRA87]所说的话：我们在这里描述的一些事情听起来似乎相当容易。但实际上，成功地制定全公司范围内的软件度量计划是很困难的工作。如果我们说，你必须至少等上3年才能在组织内形成显著的趋势，你就可以对这一工作量的规模有个概念。50在软件过程中集成度量大多数软件开发者仍然没有进行测量，更可悲在软件过程中集成度量支持软件度量的论点测量软件工程及其生产出来的产品（软件）为什么这么重要？答案其实很明显。如果不进行测量，就无法确定我们是否在改进。如果我们没有在改进，就会导致失败通过对生产率测量和质量测量提出要求，并进行评估，软件团队（及其管理者）能够建立改进软件工程过程的有意义的目标。如果软件开发过程能够得到改进，对最终结果（bottomline）将产生直接的影响。而要建立改进目标，就必须了解软件开发的当前状态。因此，可以使用测量来建立过程的基线，并根据此基线来评估改进每天繁重的软件项目工作使得人们几乎没有时间进行战略性的思考。软件项目经理更关心现实的问题：例如，建立有意义的项目估算、开发高质量的系统、按期交付产品等等。通过使用测量来建立项目基线，将使这些问题变得更容易管理。我们已经知道，基线是估算的基础。此外，质量度量的收集可以使一个组织“调整”其软件工程过程，以消除那些对软件开发有重大影响的缺陷产生的根源。51在软件过程中集成度量支持软件度量的论点测量软件工程及其生产出在软件过程中集成度量建立基线通过建立度量基线，在过程级、项目级和产品（技术）级上都能获得收益。而要收集的信息并非完全不同，相同的度量可以用于多个方面。度量基线由从以往开发的软件项目中收集的数据构成，它可能像图2－2所示的表格那样简单；也可能像一个综合数据库那样复杂，其中含有几十个项目测量数据及从中导出的度量。图2－2面向规模的度量52在软件过程中集成度量建立基线通过建立度量基线，在过程级、项目在软件过程中集成度量建立基线为了有效地协助进行过程改进和（或）成本及工作量估算，基线数据必须具有下列属性：数据必须相当精确，要避免对过去项目进行“推测”应该从尽可能多的项目中收集数据；测量数据必须是一致的，例如，在收集数据涉及的所有项目中对代码行的解释必须是一致的；基线数据所在的应用系统应该与将要做估算的工件类似，如果把一个适用于批处理系统工作的基线用于估算实时嵌入式应用系统就没有什么意义。53在软件过程中集成度量建立基线为了有效地协助进行过程改进和（或在软件过程中集成度量度量收集、计算和评估建立度量基线的过程如图2－3所示。理想情况下，建立基线所需的数据已经在项目开发过程中收集了。但遗憾的是，很少有这样做的。因此，在收集数据时，需要对以往的项目做历史调查，以重建所需的数据一旦收集好了测量数据，就可以进行度量了。依赖于所收集的测量数据的广度，度量可以涵盖众多面向应用的度量（如，LOC，FP，面向对象，WebApp）以及其他面向质量和面向项目的度量。最后，度量还要在估算、技术工作、项目控制及过程改进中加以评估和使用。度量评估主要是分析结果产生的根本原因，并生成一组指导项目或过程的指标。图2－3软件度量的收集过程54在软件过程中集成度量度量收集、计算和评估建立度量基线的过程如小型组织的度量小型组织的度量55小型组织的度量在绝大多数软件开发组织中，软件人员都不到20人。期望这样的组织能制定出全面的软件度量大纲是不合理的，在多数情况下也是不现实的。然而，建议各种规模的软件组织都进行测量，然后使用从中导出的度量来帮助他们改进其软件过程，提高所开发产品的质量，缩短开发时间，这样的要求是合理的。要完成任何软件过程相关的活动，一种常识性方法：保持简单，根据项目需要对它进行定制，确保它带来增值。“保持简单”是一个在很多活动中相当奏效的原则。但是，我们如何能够得到一组“简单的”又有价值的软件度量？我们如何确定这些简单的度量能否满足一个特殊软件组织的需要？我们不是从测量而是从结果入手，软件小组通过表决来确定一个需要改进和目标，例如，“减少评估和实现变更请求的时间”。根据这个目标，小型组织可以选择下列易于收集的测量：56小型组织的度量在绝大多数软件开发组织中，软件人员都不到20人小型组织的度量从提出请求到评估完成所用的时间（小时或天），tqueue。进行评估所用的工作量（人·小时），Weval。从完成评估到把变更工单派到员工所用的时间（小时或天），teval。实现变更所需的工作量（人·小时），Wchange。实现变更所需的时间（小时或天），tchange。在实现变更过程中发现的错误数，Echange。将变更发布给客户后发现的缺陷数，Dchange。57小型组织的度量从提出请求到评估完成所用的时间（小时或天），t小型组织的度量一旦从大量变更请求中收集到这些数据，就能计算出从变更请求到变更实现所用的总平均时间，以及初始排队、评估、派发变更和实现变更所占用时间的百分比。类似地，还可以计算出评估和实现变更所需工作量的百分比。这些度量也可以根据质量数据Echange和Dchange进行评估。从这些百分比数据还可清楚地看出变更请求过程在什么地方延迟了，从而进行过程改进，以减少tqueue、Weval、teval、Wchange和Echange。此外，缺陷排除效率又可以用以下公式计算：DRE＝Echange/（Echang

+Dchange）将DRE同变更所花费的时间和总工作量进行比较，可以看出质量保证活动对变更所需时间和工作量的影响。58小型组织的度量一旦从大量变更请求中收集到这些数据，就能计算出小结测量能使管理者和开发者改进软件过程，辅助进行软件项目的计划、跟踪及控制，评估生成的产品(软件)的质量。对过程、项目及产品的特定属性的测量可用于计算软件度量。分析这些度量可获得指导管理及技术行为的指标。过程度量使得一个组织能够从战略角度深入了解一个软件过程的功效。项目度量是战术性的，能使项目管理者实时改进项目的工作流程及技术方法。面向规模的度量和面向功能的度量在业界都得到了广泛的应用。面向规模的度量以代码行作为其他测量（如人·月，缺陷）的规范化因子。功能点则是从信息域的测量及对问题复杂度的主观评估中导出的。软件质量度量（如生产率度量）关注的是过程、项目及产品。一个组织通过建立并分析质量的度量基线，能够纠正引起软件缺陷的软件过程区域。测量会带来企业文化的改变。如果开始进行度量，则数据收集、度量计算及度量分析是必须完成的三个步骤。通常，目标驱动的方法有助于一个组织关注于对其业务的正确度量。通过建立度量基线——一个包含过程和产品测量的数据库，软件工程师及管理者能够更好地了解他们所做的工作和开发的产品。小结测量能使管理者和开发者改进软件过程，辅助进行软件项目的计59对软件度量的私有使用和公用使用有什么不同？当我们收集软件度量时，应该采用什么指导原则？在项目中，我们应该如何使用度量？什么是度量基线？它能为软件工程师提供什么益处？我们应该怎样导出一组“简单的”软件度量？一个Web工程团队已经开发了一个包含145个网页的电子商务WebApp。在这些页面中，65个是动态页面，即根据最终用户的的输入而在内部生成的页面。那么，该应用的定制指数是多少？思考题对软件度量的私有使用和公用使用有什么不同？思考题60在产品交付之前，团队A在软件工程过程中发现了342个错误，团队B发现了184个错误。对于项目A和B，还需要做什么额外的测量，才能确定哪个团队能够更有效地排除错误？你建议采用什么度量来帮助做决定？哪些历史数据可能有用？什么是间接测量？为什么在软件度量工作中经常用到这类测量？软件团队将软件增量交付给了最终用户。在使用的第一个月中，用户发现了8个缺陷。在交付之前，软件团队在正式技术评审和所有的测试任务中发现242个错误。那么，项目的总的缺陷排除率（DRE）是多少？用于控制先进的影印机的软件需要32,000行C语言代码和4200行Smalltalk语言代码。估算该影印机软件的功能点数。作业二：在产品交付之前，团队A在软件工程过程中发现了342个错误，团61过程和项目度量概述课件62SoftwareProjectManagement第2讲过程和项目度量主讲：张纲强SoftwareProjectManagement第263过程领域和项目领域中的度量主要内容软件测量软件质量度量有软件过程中集中度量小型组织的度量制定软件度量大纲过程领域和项目领域中的度量主要内容软件测量软件质量度量有软件64通过提供目标评估的机制，测量使我们能够对项目和过程有更深入的了解。Lord

Kelvin曾经说过：

当你能够测量你所说的事物，并能用数字表达它时，你就对它有了一定的了解；但当你不能测量它，也不能用数字表达时，就说明你对它的了解还很贫乏，不令人满意：这可能是知识的开始，但你在思想上还远远没有进入科学的境地。测量可以应用于软件过程中，目的是持续地改进软件过程。测量也可以应用于整个软件项目中，辅助进行估算、质量控制、生产率评估及项目控制。最后，软件工程师还可以使用测量来帮助评估工作产品的质量，并在项目进展过程中辅助进行战术决策。通过提供目标评估的机制，测量使我们能够对项65进行测量的理由：刻画－通过刻画而获得对过程、产品、资源和环境的了解，并建立同未来评估进行比较的基线；评价－通过评价来确定相对于计划的状况；预测－通过理解过程和产品间的关系，并构造这些关系的模型来进行预测；改进－通过识别障碍、根本原因、低效率和其他改进产品质量和过程性能的机会来进行改进。测量是一个管理工具，如果能正确地使用，它将为项目管理者提供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使项目成功的决策。进行测量的理由：66测度、度量和指标测度、度量和指标67测度、度量和指标虽然术语“measure”(测量)、“measurement”(测度)和“metrics”(度量)经常被互换地使用，但注意到它们之间的细微差别是很重要的。因为“measure”(测量)和“Measurement”(测度)既可以作为名词也可以作为动词，所以它们的定义可能会混淆。在软件工程领域中，“measure”(测量)对一个产品过程的某个属性的范围、数量、维度、容量或大小提供了一个定量的指示。“Measurement”(测度)则是确定一个测量的行为。IEEE的软件工程术语标准辞典(IEEE

Standard

Glossary

of

Software

Engineering

Terms)［IEE93］中定义“metric”(度量)为“对一个系统、构件或过程具有的某个给定属性的度的一个定量测量”。68测度、度量和指标虽然术语“measure”(测量)、“mea测度、度量和指标当获取到单个的数据点(如在一个模块的复审中发现的错误数)时，就建立了一个测量。测度的发生是收集一个或多个数据点的结果(如调研若干个模块的复审，以收集每一次复审所发现的错误数的测量)。软件度量在某种程度上与单个的测量相关(如每一次复审所发现的错误的平均数，或复审中每人/小时所发现的错误的平均数)。软件工程师收集测量结果并产生度量，这样就可以获得指标“indicator”。指标是一个度量或度量的组合，它对软件过程、软件项目或产品本身提供了更深入的了解［RAG95］。指标所提供的更深入的理解，使得项目管理者或软件工程师能够调整开发过程、项目或产品，这样使事情进行得更顺利，能被更好地完成。69测度、度量和指标当获取到单个的数据点(如在一个模块的复审中发过程领域和项目领域中的度量过程领域和项目领域中的度量70过程领域和项目领域中的度量测量在工程界中是常事。我们测量动力消耗、重量、物理体积、温度、电压、信号—噪音比……不胜枚举。过程度量的收集涉及所有的项目，而且要经历相当长的时间，目的是提供能够引导长期的软件过程改进的一组过程指标。项目度量使得软件项目管理都能够：(1)评估正在进行的项目的状态；(2)跟踪潜在的风险；(3)在问题造成不良影响之前发现它们；(4)调整工作流程或任务；(5)评估项目团队控制软件工程工作产品质量的能力。测量数据由项目团队收集，然后被转换成度量数据在项目期间使用。测量数据也可传送给那些负责软件过程改进的人员。因此，很多相同的度量既可以用于过程领域，又可用于项目领域。71过程领域和项目领域中的度量测量在工程界中是常事。我们测量动力过程领域和项目领域中的度量过程度量和软件过程改进改进任何过程的唯一合理的方法是测量该过程的特定属性，再根据这些属性建立一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。但是，在我们讨论软件度量及它们对软件过程改进的影响之前，必须注意到过程仅是众多“改进软件质量和组织性能的控制因素”中的一种［PAU94］。图2－1软件质量和组织有效性的决定因素在图2－1中，过程位于三角形的中央，连接了三个对软件质量和组织绩效有重大影响的因素。人员的技能和激励被认为是对质量和绩效最有影响的因素［BOE81］。产品复杂性对质量和团队绩效也有相当大的影响。过程中采用的技术(如软件工程方法)也有影响。另外，过程三角形存在于环境条件的圆圈之内，环境条件包括：开发环境(如CASE工具)、商业条件(如交付期限，业务规则)、客户特性(如通信的容易程度)。72过程领域和项目领域中的度量过程度量和软件过程改进改进任何过程过程领域和项目领域中的度量过程度量和软件过程改进我们可以间接地测量一个软件过程的功效。也就是说，我们可以根据从过程中获得的结果导出一组度量。这些结果包括：在软件发布之前发现的错误数的测量，交付给最终用户并由最终用户报告的缺陷的测量，交付的工作产品的测量，花费的工作量的测量，花费的时间的测量，与进度计划是否一致的测量，以及其他测量。我们还可以通过测量特定软件工程任务的特性来导出过程度量。如测量一般软件工程活动所花费的工作量和时间。73过程领域和项目领域中的度量过程度量和软件过程改进我们可以间接过程领域和项目领域中的度量过程度量和软件过程改进不同类型的过程数据的使用可以分为“私有的和公用的”。因为某个软件工程师可能对在其个人基础上收集的度量的使用比较敏感，这是很自然的，这些数据对此人应该是私有的，是仅供此人参考的指标。私有度量的例子有据：

个人缺陷率软件构件缺陷率开发过程中发现的错误数。私有过程数据是软件工程师个人改进其工作的重要驱动力。74过程领域和项目领域中的度量过程度量和软件过程改进不同类型的过过程领域和项目领域中的度量过程度量和软件过程改进某些过程度量对软件项目团队是私有的，但对所有团队成员是公用的。例如：主要软件功能(由多个开发人员完成)的缺陷报告、正式技术复审中发现的错误、以及每个构件或功能的代码行数或功能点数。这些数据可由团队进行复查，以找出能够改善小组性能的指标。

公用度量一般吸取了原本是个人的或团队的私有信息。收集和评估项目级的缺陷率(肯定不能归因于某个个人)、工作量、时间及相关的数据，以找出能够改善组织过程性能的指标。75过程领域和项目领域中的度量过程度量和软件过程改进某些过程度量过程领域和项目领域中的度量过程度量和软件过程改进软件度量规则：解释度量数据时使用常识，并考虑组织的敏感性。

向收集测量和度量的个人及团队定期提供反馈。不要使用度量去评价个人。

与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。

不要用度量去威胁个人或团队。指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。

不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。76过程领域和项目领域中的度量过程度量和软件过程改进软件度量规则过程领域和项目领域中的度量项目度量软件过程度量主要用于战略的目的。软件项目度量则是战术的。即，项目管理者和软件项目组经过使用项目度量及从其中导出的指标，可以改进项目工作流程和技术活动。在大多数软件项目中，项目度量的第一个应用是在估算阶段。从过去的项目中收集的度量可以作为估算当前软件工作工作量及时间的基础。随着项目的进展，可以将花费的工作量及时间的测量与最初的估算值(及项目进度)进行比较。项目管理者可以使用这些数据来监控项目的进展。随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，需要收集技术度量来评估设计质量，并提供若干指标，这些指标将会影响代码生成及测试所采用的方法。77过程领域和项目领域中的度量项目度量软件过程度量主要用于战略的过程领域和项目领域中的度量项目度量项目度量的目的是双重的。首先，这些度量能够指导进行一些必要的调整以避免延迟，并减少潜在问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行的基础上评估产品质量，并且可在必要时修改技术方法以改进质量。

随着质量的提高，错误会减到最小，而随着错误数的减少，项目中所需的修改工作量也会降低。这就导致整个项目成本的降低。78过程领域和项目领域中的度量项目度量项目度量的目的是双重的。1软件测量软件测量79软件测量测量在现实世界中可分为两类：直接测量(如螺钉的长度)和间接测量(如生产的螺钉的“质量”，由计算其次品率来测量)。软件测量也有两种分类方法：

软件工程过程的直接测量，包括花费的成本和工作量；产品的直接测量，包括产生的代码行(lines

of

code，LOC)、运行速度、内存大小及某段时间内报告的缺陷。产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性及许多其他的“产品特性”。80软件测量测量在现实世界中可分为两类：直接测量(如螺钉的长度)软件测量将项目度量联合起来可以得到整个软件组织公用的过程度量。但是，一个组织如何将来自不同个人或项目的度量结合起来呐？

为了说明这个问题，我们看一个简单的例子：两个不同项目团队中的人将他们在软件工程过程中所发现的所有错误进行了记录和分类。然后，将这睦个人的测量结合起来就产生了团队的测量。在软件发布前，团队A在软件过程中发现了342个错误，团队B发现了184个错误。所有其他情况都相同，那么在整个过程中哪个团队能更有效地发现错误呢？因为不知道项目的规模或复杂性，所以我们不能回答这个问题。不过，如果度量采用规范化的方法，就有可能产生能够在更大的组织范围内进行比较的软件度量。如此说来，面向规模的度量和面向功能的度量都是规范化的方法。81软件测量将项目度量联合起来可以得到整个软件组织公用的过程度量软件测量面向规模的度量面向规模的软件度量是通过规范化质量和（或）生产率的测量值而得到的，这些测量都基于已经开发的软件的“规模”。如果软件组织一直在做简单的记录，就会产生一个如图2－2所示的面向规模测量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量数据。查看alpha项目的数据(图2－2)：花费了24个人·月的工作量，成本为168000美元，产生了12100行代码。应该注意到表中记录的工作量和成本涵盖了所有软件工程活动(分析、设计、编码及测试)，而不仅仅是编码。alpha项目更进一步的信息包括：产生了365页的文档；在软件发布之前，发现了134个错误；软件发布给客户之后运行的第一年中遇到了29个缺陷；有3个人参加了alpha项目的软件开发工作。82软件测量面向规模的度量面向规模的软件度量是通过规范化质量和（图2－2面向规模的度量图2－2面向规模的度量83软件测量面向规模的度量为了产生能和其他项目中同类度量进行比较的度量，我们选择代码行作为规范化值。根据表中所包含的基本数据，每个项目都能产生一组简单的面向规模度量：每千行代码(KLOC)的错误数。

每千行代码(KLOC)的缺陷数。每千行代码(KLOC)的成本。每千行代码(KLOC)的文档页数。

除此之外，还能够计算出其他有意义的度量：

每人·月错误数。每人·月千代码行(KLOC)。每页文档的成本。84软件测量面向规模的度量为了产生能和其他项目中同类度量进行比较软件测量面向规模的度量面向规模的度量并不被普遍认为是测量软件开发过程的最好方法［JON86］。大多数的争议都是围绕着使用代码行(LOC)作为关键的测量是否合适。LOC测量的支持者们声称LOC是所有软件开发项目的“生成品”，并且很容易进行计算；许多现有的软件估算模型使用LOC或KLOC作为关键的输入，并且已经有大量的文献和数据涉及到LOC。另一方面，反对者们则认为LOC测量依赖于程序设计语言；它们对设计得很好，但较小的程序会产生不利的评判；它们不适用于非过程语言；而且它们在估算时需要一些可能难以得到的信息(如，早在分析和设计完成之前，计划者就必须估算出要产生的LOC)。85软件测量面向规模的度量面向规模的度量并不被普遍认为是测量软件软件测量面向功能的度量面向功能的软件度量使用功能（由应用系统提供）测量数据作为规模化值。应用最广泛的面向功能的度量是功能点（FunctionPoint,FP）。功能点是根据软件信息域的特性及复杂性来计算的。与LOC测量一样，功能点测量也是有争议的。支持者们认为FP与程序设计语言无关，对于使用传统语言和非过程语言应用系统来说，它都比较理想的；而且它所依据的数据是在项目开发初期就可能得到的数据。因此，作为一种估算方法，FP更有吸引力。反对者们则声称这种方法需要某种“熟练手法”，因为计算的依据是主观的而非客观的数据，信息域（及其他方面）的计算可能难以在事后收集。而且FP没有直接的物理意义，它仅仅是一个数字而已。86软件测量面向功能的度量面向功能的软件度量使用功能（由应用系统软件测量调和代码行和功能点的度量方法代码行和功能点度量之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。很多研究试图将FP测量和LOC测量联系起来。引用Albrecht和Gaffney［ALB83］的话说：本研究的论点是：应用(程序)所提供的功能数能够从所使用的数据或提供的数据的主要组成部分的详细记录中估算出来，或是直接从记录中得到。更进一步，功能的估算应该与要开发的LOC数及开发所需的工作量关联起来。表2-1［QSM02］给出了在不同的程序设计语言中实现一个功能点所需的平均代码行数的粗略估算：87软件测量调和代码行和功能点的度量方法代码行和功能点度量之间的过程和项目度量概述课件88过程和项目度量概述课件89查看上表可知：C++的一个LOC所提供的“功能性”大约是C的一个LOC的2.4倍（平均来讲）。而且，Smalltalk的一个LOC所提供的“功能性”至少是传统程序设计语言（如Ada、COBOL或C）的4倍。利用上表中所包含的信息，只要知道了程序设计语言的语句行数，就可以“逆向”估算出现有软件的功能点数量。软件测量调和代码行和功能点的度量方法基于功能点和LOC的度量都是对软件开发工作量和成本的比较精确的判定。然而，如果使用LOC和FP进行估算，还必须要建立一个历史信息基线。在过程度量和项目度量中，最关心的是生产率和质量－软件开发“输出量”（作为投入的工作量和时间的函数）的测量和对生产的工作产品的“适用性”测量。为了进行过程改进和项目策划，必须掌握历史的情况。在以往的项目中，软件开发的生产率是多少？生产的软件质量如何？怎样利用以往的生产率数据和质量数据推断现在的生产率和质量？如何利用这些数据帮助我们改进过程，以及更精确地规划新项目？90查看上表可知：C++的一个LOC所提供的“功能性”大约是C的传统的软件项目度量（LOC或FP）也可以用于估算面向对象的软件项目。但是，这些度量并没有提供对进度和工作量进行调整的粒度，而这却是我们在演化模型或增量模型中进行迭代时所需要的。用于OO项目的度量：场景脚本的数量关键类的数量支持类的数量每个关键偶氮染料平均支持类数量子系统的数量软件测量面向对象的度量91传统的软件项目度量（LOC或FP）也可以用于估算面向对象的软软件测量用于OO项目的度量场景脚本的数量场景脚本是一个详细的步骤序列，用来描述用户和应用系统之间的交互。应用系统的规模及测试用例的数量都与场景脚本的数量紧密相关。关键类的数量关键类是“高度独立的构件”，在面向对象分析的早期进行定义。由于关键类是问题域的核心，因此这些类的数量既是开发软件所需工作量的指标，也是系统开发中潜在的复用数量的指标。支持类的数量支持类是实现系统所必需的但又不与问题域直接相关的类。例如，UI类、数据库访问及操作类、计算类。另外，对于每一个关键类，都可以开发其支持类。支持类的数量既是开发软件所需工件量的指标，也是系统开中潜在的复用数量的指标。软件测量用于OO项目的度量场景脚本的数量92软件测量用于OO项目的度量每个关键类的平均支持类数量通常，关键类在项目的早期就可以确定下来，而支持类的定义则贯穿于项目的始终。对于给定的问题域，如果知道了每个关键类的平均支持类数量，估算（根据类的总数）将应得非常简单。在采用GUI的应用中，支持类是关键类的2~3倍；在不采用GUI的应用中，支持类是关键类的1~2倍。子系统的数量子系统是实现某个功能（对系统最终用户可见）的类的集合。一旦确定了子系统，人们就更容易制定出合理的进度计划，并将子系统的工作在项目人员之间进行分配。软件测量用于OO项目的度量每个关键类的平均支持类数量93软件测量面向对象的度量为了将类似于上述的那些度量有效地应用于面向对象的软件工程环境中，必须将它们随同项目测量（例如花费的工作量、发现的错误和缺陷、建立的模型或文档资料）一起收集。随着数据库规模的增长（在完成大量项目之后），面向对象的测量数据和项目测量数据之间关系将提供有助于项目估算的度量。软件测量面向对象的度量为了将类似于上述的那些度量有效地应用于94软件测量面向用例的度量与LOC或FP相类似，使用用例作为规范化的测量应该是合理的。同FP一样，用例也是在软件过程早期进行定义的。在重大的建模活动和构造活动开始之前，就允许使用用例进行估算。用例描述了（至少是间接地）用户可见的功能和特性，这些都是系统的基本需求。用例与程序设计语言无关。另外，用例数量同应用系统的规模（LOC）和测试用例的数量成正比，而测试用例是为了充分测试该应用系统而必须设计的。由于可以在不同的抽象级别上创建用例，所以用例的大小没有标准。由于对用例本身还没有标准的测量，因此将用例作为规范化的测量（如，每个用例花费的工作量）是不可信的。尽管许多研究人员试图推导出用例度量，但仍有很工作要做。软件测量面向用例的度量与LOC或FP相类似，使用用例作为规95软件测量Web工程项目度量所有Web工程项目的目标都是建立一个Web应用（WebApp），交付给最终用户一个内容和功能的结合体。很难将那些用于传统软件工程项目的测量和度量直接转化应用于Web应用系统中。然而，Web工程组织应该建立一个数据库，随着大量项目的完成，就可以使用该数据库来评估组织内部的生产率和质量。在这些测量中，可以收集的有：静态Web页的数量动态Web页的数量内部页面链接的数量永久数据对象的数量通过界面连接的外部系统的数量静态内容对象的数量动态内容对象的数量可执行的功能数量软件测量Web工程项目度量所有Web工程项目的目标都是建立96软件测量Web工程项目度量静态Web页的数量静态内容的Web页（即最终用户不能控制页面显示的内容）是所有Web应用系统最普通的特征。这些页面复杂性较低，通常构造静态页面所需的工作量少于动态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系统所需的工作量。动态Web页的数量在所有的电子商务应用、搜索引擎、金融应用以及许多其他Web应用中，动态内容的Web页（即根据最终用户的操作，页面上显示出相应的定制内容）是必需的要素。动态页面复杂性较高，构造动态页面所需的工作量高于静态页面。这项测量提供了一个指标，标志着应用系统的整体规模和开发应用系统所需的工作量。软件测量Web工程项目度量静态Web页的数量97软件测量Web工程项目度量内部页面链接的数量内部页面链接就是一个指针，它在Web应用中提供了到达其他某个Web页的超链接。这项测量提供了一个Web应用内部结构互连程度的指标。随着页面链接的增加，花费在导航设计和开发上的工作量也会增加。永久数据对象的数量Web应用可以访问一个或多个永久数据对象（如数据库或数据文件）。随着永久数据对象数量的增加，Web应用系统的复杂性也会增加，实现应用系统所需的工作量也会成比例地增加。软件测量Web工程项目度量内部页面链接的数量98软件测量Web工程项目度量通过界面连接的外部系统的数量Web应用系统必须经常与“后台的”业务应用相连接。随着界面连接需求的增多，系统复杂性和开发工作量也会增加。静态内容对象的数量静态内容对象包括静态文本、图像、视频、动画和音频信息，它们在Web应用中被集成在一起。在一个Web页中，可能同时出现多个内容对象。软件测量Web工程项目度量通过界面连接的外部系统的数量99软件测量Web工程项目度量动态内容对象的数量动态内容对象是根据最终用户的操作而产生的，包括内部产生的文本、图像、视频、动画和音频信息，它们在Web应用中被集成在一起。在一个Web页中，可能同时出现多个内容对象。可执行的功能的数量可执行的功能（如，脚本和小程序）为最终用户提供了某些计算服务。随着可执行功能数量的增加，建模和构造的工作量也会随之增加。软件测量Web工程项目度量动态内容对象的数量100软件测量Web工程项目度量上面提到的每个测量都可以在Web工程过程的初期就确定下来。例如，我们可以定义一个度量，来反映Web应用所需的最终用户的定制程度，并使它与Web工程项目花费的工作量以及评审中发现的错误关联起来。为此，我们进行以下定义：

Nsp=静态Web页的数量

Ndp=动态Web页的数量

那么

定制指数C=Ndp/(Ndp+Nsp)

C的取值范围是0到1。随着C值的增大，Web应用的定制水平将成为一个重大的技术问题。类似的Web应用度量也呆以被计算出来，并同项目测量（如花费的工作量、发现的错误和缺陷、已建立的模型或文档）关联起来。随着数据库规模的扩大（在完成了很多项目之后），Web应用测量与项目测量之间的关系将提供有助于项目估算的指标。软件测量Web工程项目度量上面提到的每个测量都可以在Web101软件质量度量软件质量度量102软件质量度量软件工程的基本高目标就是在某个时间框架内开发出满足市场需要的高质量的系统、应用软件或产品。为了达到这个目标，软件工程师必须掌握在成熟的软件过程背景下，使用有效的方法及现代化的工具。此外，一个优秀的软件工程师(及优秀的软件工程管理者)必须通过测量来判断能否实现高质量。将软件工程师个人收集的私有度量结合起来，可以提供项目级的度量。虽然可以收集到很多质量测量数据，但在项目级上最主要的还是测量错误和缺陷的数目。从这些测量中导出的度量