过程和项目度量概述课件

软件工程软件工程1第19章过程和项目度量第19章过程和项目度量2主要内容过程领域和项目领域中的度量软件测量软件质量度量小结主要内容过程领域和项目领域中的度量3过程和项目度量软件过程和项目度量是定量的测量，这些测量能使软件工程师更深入地了解软件过程的功效，以及使用该过程作为框架进行开发的项目的功效。度量时，首先收集基本的质量数据和生产率数据，然后分析这些数据、与过去的平均值进行比较，通过评估来确定是否已有质量和生产率的提高。度量也可以用来查明问题区域，以便确定合适的补救方法，并改进软件过程。过程和项目度量软件过程和项目度量是定量的测量，这些测量能使软4过程和项目度量软件度量由软件管理者来分析和评估。测量数据通常由软件工程师来收集。如果不进行测量，只能根据主观评价来做判断。通过测量，可以发现趋势，可以更好地进行估算，随着时间的推移能够获得真正的改进。过程和项目度量软件度量由软件管理者来分析和评估。测量数据通常5过程和项目度量首先确定一组有限的易于收集的过程测量和项目测量。通常使用面向规模或面向功能的度量对这些测量进行规范化。然后，对测量结果进行分析，并与该组织以前完成的类似项目的平均数据进行比较。最后评估趋势，并给出结论。工作产品是得到一组软件度量，它们提供了对过程的洞察力和对项目的理解。过程和项目度量首先确定一组有限的易于收集的过程测量和项目测6过程和项目度量通过提供目标评估的机制，测量使我们能够对项目和过程有更深入的了解。LordKelvin曾经说过：当你能够测量你所说的事物，并能用数字表达它时，你就对它有了一定的了解；当你不能测量它，也不能用数字来表达时，就说明你对它的了解还很贫乏，不能令人满意：这可能是知识的开始，但你在思想上还远远没有进入科学的境地。过程和项目度量通过提供目标评估的机制，测量使我们能够对项目和7过程和项目度量测量可以应用于软件过程中，目的是持续地改进软件过程。测量也可以应用于整个软件项目中，辅助进行估算、质量控制、生产率评估及项目控制。最后，软件工程师还可以使用测量来帮助评估工作产品的质量，并在项目进展过程中辅助进行战术决策。过程和项目度量测量可以应用于软件过程中，目的是持续地改进软件8过程和项目度量[PAR96]讨论了进行测量的理由：

(1)刻画——通过刻画而获得对过程、产品、资源和环境的了解，并建立同未来评估进行比较的基线；

(2)评价——通过评价来确定相对于计划的状况；

(3)预测——通过理解过程和产品间的关系，并构造这些关系的模型来进行预测；

(4)改进——通过识别障碍、根本原因、低效率和其他改进产品质量和过程性能的机会来进行改进。测量是一个管理工具，如果能正确地使用，它将为项目管理者提供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使项目成功的决策。过程和项目度量[PAR96]讨论了进行测量的理由：

(1)刻9过程领域和项目领域中的度量过程度量的收集涉及所有的项目，而且要经历相当长的时间，目的是提供能够引导长期的软件过程改进的一组过程指标。项目度量使得软件项目管理者能够：(1)评估正在进行中的项目的状态；(2)跟踪潜在的风险；(3)在问题造成不良影响之前发现它们；(4)调整工作流程或任务；(5)评估项目团队控制软件工作产品质量的能力。测量数据由项目团队收集，然后被转换成度量数据在项目期间使用。测量数据也可以传送给那些负责软件过程改进的人员。因此，很多相同的度量既可用于过程领域，又可用于项目领域。过程领域和项目领域中的度量过程度量的收集涉及所有的项目，而且10过程度量和软件过程改进改进任何过程的唯一合理方法就是测量该过程的特定属性，再根据这些属性建立一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。但是，在讨论软件度量及其对软件过程改进的影响之前，必须注意到：过程仅是众多“改进软件质量和组织性能的控制因素”中的一种。过程度量和软件过程改进改进任何过程的唯一合理方法就是测量该过11软件质量和组织有效性的决定因素图19-1软件质量和组织有效性的决定因素软件质量和组织有效性的决定因素图19-1软件质量和组织有效12过程度量和软件过程改进在图19-1中，过程位于三角形的中央，连接了三个对软件质量和组织绩效有重大影响的因素。其中，人员的技能和动力被认为是对质量和绩效影响最大的因素，产品复杂性对质量和团队绩效也有相当大的影响，过程中采用的技术也有一定的影响。另外，过程三角形位于环境条件圆圈内，环境条件包括：开发环境、商业条件、客户特性。过程度量和软件过程改进在图19-1中，过程位于三角形的中央，13过程度量和软件过程改进可以间接地测量软件过程的功效。即，可以根据从过程中获得的结果来导出一组度量。这些结果包括：在软件发布之前发现的错误数的测度，提交给最终用户并由最终用户报告的缺陷的测度，交付的工作产品的测度，花费的工作量的测度，花费时间的测度，与进度计划是否一致的测度，以及其他测度。还可以通过测量特定软件工程任务的特性来导出过程度量。过程度量和软件过程改进可以间接地测量软件过程的功效。即，可以14过程度量和软件过程改进[GRA92]认为不同类型的过程数据的使用可以分为“私有的和公有的”。私有度量的例子有：个人缺陷率、软件构件缺陷率和开发过程中发现的错误数。“私有过程数据”的观点与Humphrey所建议的个人软件过程方法相一致。Humphrey认为过程改进能够、也应该开始于个人级。私有过程数据是软件工程师个人改进其工作的重要驱动力。有些过程度量对于软件项目团队是私有的，但对所有团队成员是公用的。例如，主要软件功能的缺陷报告、正式技术评审中发现的错误，以及每个构件或功能的代码行数或功能点数。这些数据可由团队进行评审，以便找出能够改善团队性能的指标。过程度量和软件过程改进[GRA92]认为不同类型的过程数据的15过程度量和软件过程改进公用的度量一般吸收了原本是个人或团队的私有信息。收集和评估项目级的缺陷率、工作量、时间以及相关的数据，来找出能够改善组织过程性能的指标。软件过程度量对于组织提高其整体的过程成熟度能够提供很大的帮助。不过，就像所有其他度量一样，软件过程度量也可能被误用，产生的问题比它们所能解决的问题更多。过程度量和软件过程改进公用的度量一般吸收了原本是个人或团队的16过程度量和软件过程改进[GRA92]提出一组“软件度量规则”。管理者和开发者在制定过程度量大纲时，这些规则都适用：解释度量数据时使用常识，并考虑组织的敏感性。向收集测量和度量的个人及团队定期提供反馈。不要使用度量去评价个人。与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。不要用度量去威胁个人或团队。指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。过程度量和软件过程改进[GRA92]提出一组“软件度量规则”17过程度量和软件过程改进随着一个组织更加得心应手地收集和使用过程度量，简单的指标获取方式就会逐渐被更加精确的方法所取代，该方法称为统计软件过程改进。本质上，SSPI使用软件失效分析方法收集在应用软件、系统或产品的开发及使用过程中所遇到的所有的错误及缺陷信息。过程度量和软件过程改进随着一个组织更加得心应手地收集和使用过18项目度量软件过程度量用于战略目的，而软件项目度量则用于战术目的。即，项目管理者和软件项目团队通过使用项目度量及从中导出的指标，可以改进项目工作流程和技术活动。在大多数软件项目中，项目度量的第一次应用是在估算阶段。从过去项目中收集的度量可以作为估算当前软件工作量及时间的基础。随着项目的进展，可以将花费的工作量及时间的测量与最初的估算值(及项目进度)进行比较。项目管理者可以使用这些数据来监控项目的进展。项目度量软件过程度量用于战略目的，而软件项目度量则用于战术目19项目度量随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，需要收集技术度量来评估设计质量，并提供若干指标，这些指标将会影响代码生成及测试所采用的方法。项目度量随着技术工作的启动，其他项目度量也开始有意义了。生产20项目度量项目度量的目的是双重的。首先，利用度量能够对开发进度进行必要的调整，以避免延迟，并减少潜在的问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行过程中评估产品质量，必要时可调整技术方法以提高质量。随着质量的提高，缺陷会减到最少。而随着缺陷数的减少，项目中所需的修改工作量也会降低，这将使整个项目成本降低。项目度量项目度量的目的是双重的。首先，利用度量能够对开发进度21软件测量软件测量有两种分类方法：(1)软件过程(如花费的成本和工作量)和产品(如产生的代码行(LOC)、运行速度以及某段时间内报告的缺陷)的直接测量;(2)产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性，以及许多其他的“产品特性”。将项目度量联合起来可以得到整个软件组织公用的过程度量。软件测量软件测量有两种分类方法：(1)软件过程(如花费的成本22面向规模的度量面向规模的软件度量是通过规范化质量和(或)生产率的测量值而得到的，这些测量都基于已经开发的软件的规模。如果软件组织一直在做简单的记录，就会产生一个如图19-2所示的面向规模测量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量数据。面向规模的度量面向规模的软件度量是通过规范化质量和(或)生产23面向规模的度量图19-2面向规模的度量面向规模的度量图19-2面向规模的度量24面向规模的度量为了产生能和其他项目中同类度量进行比较的度量，选择代码行作为规范化值。根据表中所包含的基本数据，每个项目都能得到一组简单的面向规模的度量：每千行代码(KLOC)的错误数；每千行代码的缺陷数；每千行代码的成本；每千行代码的文档页数；此外，还能计算出其他有意义的度量。面向规模的度量为了产生能和其他项目中同类度量进行比较的度量，25面向功能的度量面向功能的软件度量使用功能测量数据作为规范化值。应用最广泛的面向功能的度量是功能点FP。功能点是根据软件信息域的特性及复杂性来计算的。面向功能的度量面向功能的软件度量使用功能测量数据作为规范化值26调和代码行和功能点的度量方法代码行和功能点之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。很多研究试图将FP测量和LOC测量联系起来。表19-1(P340页)给出了在不同的程序设计语言中实现一个功能点所需的平均代码行数的粗略估算。调和代码行和功能点的度量方法代码行和功能点之间的关系依赖于实27调和代码行和功能点的度量方法人们发现基于功能点和LOC的度量都是对软件开发工作量和成本的比较精确的判定。然而，如果使用LOC和FP进行估算，还必须要建立一个历史信息基线。在过程度量和项目度量中，最关心的是生产率和质量——软件开发“输出量”（作为投入的工作量和时间的函数）的测量和对生产的工作产品的“适用性”的测量。为了进行过程改进和项目策划，必须掌握历史的情况。在以往的项目中，软件开发的生产率是多少？生产的软件质量如何？怎样利用以往的生产率数据和质量数据推断现在的生产率和质量？如何利用这些数据帮助我们改进过程，以及更精确地规划新的项目？调和代码行和功能点的度量方法人们发现基于功能点和LOC的度量28面向对象的度量传统的软件项目度量也可以用于估算面向对象的软件项目。但是，这些度量并没有提供对进度和工作量进行调整的足够的粒度，而这却是在演化模型或增量模型中进行迭代时所需要的。[LOR94]提出了下列用于OO项目的度量。场景脚本的数量关键类的数量支持类的数量每个关键类的平均支持类数量子系统的数量面向对象的度量传统的软件项目度量也可以用于估算面向对象的软件29面向用例的度量与LOC或FP相类似，使用用例作为规范化的测量应该是合理的。同FP一样，用例也是在软件过程早期进行定义的。在重大的建模活动和构造活动开始之前，就允许使用用例进行估算。用例描述了用户可见的功能和特性，这些都是系统的基本需求。用例与程序设计语言无关。另外，用例的数量同应用系统的规模和测试用例的数量成正比，而测试用例是为了充分测试该应用系统而必须设计的。面向用例的度量与LOC或FP相类似，使用用例作为规范化的测量30软件质量度量软件工程的基本目标是在某个时间框架内开发出满足市场需要的高质量的系统、应用或产品。为了达到这个目标，软件工程师必须在成熟的软件过程背景下，使用有效的方法及现代化的工具。此外，一个优秀的软件工程师必须通过测量来判断能否实现高质量。软件质量度量软件工程的基本目标是在某个时间框架内开发出满足市31软件质量度量将软件工程师个人收集的私有度量结合起来，可以提供项目级的度量。虽然可以收集到很多质量测量数据，但在项目级上最主要的还是测量错误和缺陷的数量。从这些测量中导出的度量能够提供一个指标，表明个人及小组在软件质量保证和控制活动上的效力。软件质量度量将软件工程师个人收集的私有度量结合起来，可以提供32软件质量度量度量——比如说工作产品(如需求或设计)——每功能点的错误数、在评审中每小时发现的错误数、测试中每小时发现的错误数，使我们能够深入了解度量所涉及的活动的功效。有关错误的数据也能用来计算每个过程框架活动的缺陷排除效率DRE。软件质量度量度量——比如说工作产品(如需求或设计)——每功能33测量质量正确性、可维护性、完整性和可用性为项目团队提供了有用的指标。正确性：一个程序必须能够正确地执行，否则对于用户就没有价值了。正确性是软件完成所要求的功能的程度。最常用的关于正确性的测量是每千行代码的缺陷数。可维护性：可维护性是指遇到错误时程序能够被修改的容易程度，环境发生变化时程序能够适应的容易程度，用户希望变更需求时程序能够被增强的容易程度。还没有一种方法可以直接测量可维护性，只能采用间接测量。有一种简单的面向时间的度量，称为平均变更时间MTTC。测量质量正确性、可维护性、完整性和可用性为项目团队提供了有用34测量质量完整性：这个属性测量的是一个系统对安全性攻击的抵抗能力。软件的所有三个成分都会遭到攻击。为了测量完整性，必须定义另外两个属性：危险性和安全性。危险性是指一个特定类型的攻击在给定的时间内发生的概率。安全性是指一个特定类型的攻击将被击退的概率。一个系统的完整性可定义为：

完整性=∑[1-(危险性×(1-安全性))]测量质量完整性：这个属性测量的是一个系统对安全性攻击的抵抗能35测量质量可用性：如果一个程序不容易使用，即使它完成的功能很有价值，也常常注定要失败。可用性力图对“使用的容易程度”进行量化。测量质量可用性：如果一个程序不容易使用，即使它完成的功能很有36缺陷排除效率缺陷排除效率DRE是在项目级和过程级都有意义的质量度量。本质上，DRE是对质量保证及控制活动中滤除缺陷能力的测量，而这些质量保证及质量控制活动贯穿应用于所有过程框架活动中。当把项目作为一个整体来考虑时

DRE=E/(E+D)

其中E是软件交付给最终用户之前发现的错误数，D是软件交付之后发现的缺陷数。缺陷排除效率缺陷排除效率DRE是在项目级和过程级都有意义的质37缺陷排除效率在项目内部，也可以使用DRE来评估一个团队在错误传递到下一个框架活动或软件工程任务之前发现错误的能力。在这种情况下，将DRE重新定义为：

DREi=Ei/(Ei+Ei+1)

其中，Ei是在软件工程活动i中发现的错误数；Ei+1是在软件工程活动i+1中发现的错误数，这些错误都是在软件工程活动i中没被发现的错误。软件项目团队的质量目标是使DREi接近于1，即错误应该在传递到下一个活动之前被过滤掉。缺陷排除效率在项目内部，也可以使用DRE来评估一个团队在错误38小结小结39作业P345页19.519.11作业P345页19.519.1140软件工程软件工程41第19章过程和项目度量第19章过程和项目度量42主要内容过程领域和项目领域中的度量软件测量软件质量度量小结主要内容过程领域和项目领域中的度量43过程和项目度量软件过程和项目度量是定量的测量，这些测量能使软件工程师更深入地了解软件过程的功效，以及使用该过程作为框架进行开发的项目的功效。度量时，首先收集基本的质量数据和生产率数据，然后分析这些数据、与过去的平均值进行比较，通过评估来确定是否已有质量和生产率的提高。度量也可以用来查明问题区域，以便确定合适的补救方法，并改进软件过程。过程和项目度量软件过程和项目度量是定量的测量，这些测量能使软44过程和项目度量软件度量由软件管理者来分析和评估。测量数据通常由软件工程师来收集。如果不进行测量，只能根据主观评价来做判断。通过测量，可以发现趋势，可以更好地进行估算，随着时间的推移能够获得真正的改进。过程和项目度量软件度量由软件管理者来分析和评估。测量数据通常45过程和项目度量首先确定一组有限的易于收集的过程测量和项目测量。通常使用面向规模或面向功能的度量对这些测量进行规范化。然后，对测量结果进行分析，并与该组织以前完成的类似项目的平均数据进行比较。最后评估趋势，并给出结论。工作产品是得到一组软件度量，它们提供了对过程的洞察力和对项目的理解。过程和项目度量首先确定一组有限的易于收集的过程测量和项目测46过程和项目度量通过提供目标评估的机制，测量使我们能够对项目和过程有更深入的了解。LordKelvin曾经说过：当你能够测量你所说的事物，并能用数字表达它时，你就对它有了一定的了解；当你不能测量它，也不能用数字来表达时，就说明你对它的了解还很贫乏，不能令人满意：这可能是知识的开始，但你在思想上还远远没有进入科学的境地。过程和项目度量通过提供目标评估的机制，测量使我们能够对项目和47过程和项目度量测量可以应用于软件过程中，目的是持续地改进软件过程。测量也可以应用于整个软件项目中，辅助进行估算、质量控制、生产率评估及项目控制。最后，软件工程师还可以使用测量来帮助评估工作产品的质量，并在项目进展过程中辅助进行战术决策。过程和项目度量测量可以应用于软件过程中，目的是持续地改进软件48过程和项目度量[PAR96]讨论了进行测量的理由：

(1)刻画——通过刻画而获得对过程、产品、资源和环境的了解，并建立同未来评估进行比较的基线；

(2)评价——通过评价来确定相对于计划的状况；

(3)预测——通过理解过程和产品间的关系，并构造这些关系的模型来进行预测；

(4)改进——通过识别障碍、根本原因、低效率和其他改进产品质量和过程性能的机会来进行改进。测量是一个管理工具，如果能正确地使用，它将为项目管理者提供洞察力。因此，测量能够帮助项目管理者和软件团队制定出使项目成功的决策。过程和项目度量[PAR96]讨论了进行测量的理由：

(1)刻49过程领域和项目领域中的度量过程度量的收集涉及所有的项目，而且要经历相当长的时间，目的是提供能够引导长期的软件过程改进的一组过程指标。项目度量使得软件项目管理者能够：(1)评估正在进行中的项目的状态；(2)跟踪潜在的风险；(3)在问题造成不良影响之前发现它们；(4)调整工作流程或任务；(5)评估项目团队控制软件工作产品质量的能力。测量数据由项目团队收集，然后被转换成度量数据在项目期间使用。测量数据也可以传送给那些负责软件过程改进的人员。因此，很多相同的度量既可用于过程领域，又可用于项目领域。过程领域和项目领域中的度量过程度量的收集涉及所有的项目，而且50过程度量和软件过程改进改进任何过程的唯一合理方法就是测量该过程的特定属性，再根据这些属性建立一组有意义的度量，然后使用这组度量提供的指标来导出过程改进策略。但是，在讨论软件度量及其对软件过程改进的影响之前，必须注意到：过程仅是众多“改进软件质量和组织性能的控制因素”中的一种。过程度量和软件过程改进改进任何过程的唯一合理方法就是测量该过51软件质量和组织有效性的决定因素图19-1软件质量和组织有效性的决定因素软件质量和组织有效性的决定因素图19-1软件质量和组织有效52过程度量和软件过程改进在图19-1中，过程位于三角形的中央，连接了三个对软件质量和组织绩效有重大影响的因素。其中，人员的技能和动力被认为是对质量和绩效影响最大的因素，产品复杂性对质量和团队绩效也有相当大的影响，过程中采用的技术也有一定的影响。另外，过程三角形位于环境条件圆圈内，环境条件包括：开发环境、商业条件、客户特性。过程度量和软件过程改进在图19-1中，过程位于三角形的中央，53过程度量和软件过程改进可以间接地测量软件过程的功效。即，可以根据从过程中获得的结果来导出一组度量。这些结果包括：在软件发布之前发现的错误数的测度，提交给最终用户并由最终用户报告的缺陷的测度，交付的工作产品的测度，花费的工作量的测度，花费时间的测度，与进度计划是否一致的测度，以及其他测度。还可以通过测量特定软件工程任务的特性来导出过程度量。过程度量和软件过程改进可以间接地测量软件过程的功效。即，可以54过程度量和软件过程改进[GRA92]认为不同类型的过程数据的使用可以分为“私有的和公有的”。私有度量的例子有：个人缺陷率、软件构件缺陷率和开发过程中发现的错误数。“私有过程数据”的观点与Humphrey所建议的个人软件过程方法相一致。Humphrey认为过程改进能够、也应该开始于个人级。私有过程数据是软件工程师个人改进其工作的重要驱动力。有些过程度量对于软件项目团队是私有的，但对所有团队成员是公用的。例如，主要软件功能的缺陷报告、正式技术评审中发现的错误，以及每个构件或功能的代码行数或功能点数。这些数据可由团队进行评审，以便找出能够改善团队性能的指标。过程度量和软件过程改进[GRA92]认为不同类型的过程数据的55过程度量和软件过程改进公用的度量一般吸收了原本是个人或团队的私有信息。收集和评估项目级的缺陷率、工作量、时间以及相关的数据，来找出能够改善组织过程性能的指标。软件过程度量对于组织提高其整体的过程成熟度能够提供很大的帮助。不过，就像所有其他度量一样，软件过程度量也可能被误用，产生的问题比它们所能解决的问题更多。过程度量和软件过程改进公用的度量一般吸收了原本是个人或团队的56过程度量和软件过程改进[GRA92]提出一组“软件度量规则”。管理者和开发者在制定过程度量大纲时，这些规则都适用：解释度量数据时使用常识，并考虑组织的敏感性。向收集测量和度量的个人及团队定期提供反馈。不要使用度量去评价个人。与开发者和团队一起设定清晰的目标，并确定为达到这些目标需要使用的度量。不要用度量去威胁个人或团队。指出问题区域的度量数据不应该被“消极地”看待，这些数据仅仅是过程改进的指标。不要在某一个别的度量上纠缠，而无暇顾及其他重要的度量。过程度量和软件过程改进[GRA92]提出一组“软件度量规则”57过程度量和软件过程改进随着一个组织更加得心应手地收集和使用过程度量，简单的指标获取方式就会逐渐被更加精确的方法所取代，该方法称为统计软件过程改进。本质上，SSPI使用软件失效分析方法收集在应用软件、系统或产品的开发及使用过程中所遇到的所有的错误及缺陷信息。过程度量和软件过程改进随着一个组织更加得心应手地收集和使用过58项目度量软件过程度量用于战略目的，而软件项目度量则用于战术目的。即，项目管理者和软件项目团队通过使用项目度量及从中导出的指标，可以改进项目工作流程和技术活动。在大多数软件项目中，项目度量的第一次应用是在估算阶段。从过去项目中收集的度量可以作为估算当前软件工作量及时间的基础。随着项目的进展，可以将花费的工作量及时间的测量与最初的估算值(及项目进度)进行比较。项目管理者可以使用这些数据来监控项目的进展。项目度量软件过程度量用于战略目的，而软件项目度量则用于战术目59项目度量随着技术工作的启动，其他项目度量也开始有意义了。生产率可以根据创建的模型、评审的时间、功能点以及交付的源代码行数来测量。此外，对每个软件工程任务中所发现的错误也要进行跟踪。在软件从需求到设计的演化过程中，需要收集技术度量来评估设计质量，并提供若干指标，这些指标将会影响代码生成及测试所采用的方法。项目度量随着技术工作的启动，其他项目度量也开始有意义了。生产60项目度量项目度量的目的是双重的。首先，利用度量能够对开发进度进行必要的调整，以避免延迟，并减少潜在的问题及风险，从而使得开发时间减到最少。其次，项目度量可在项目进行过程中评估产品质量，必要时可调整技术方法以提高质量。随着质量的提高，缺陷会减到最少。而随着缺陷数的减少，项目中所需的修改工作量也会降低，这将使整个项目成本降低。项目度量项目度量的目的是双重的。首先，利用度量能够对开发进度61软件测量软件测量有两种分类方法：(1)软件过程(如花费的成本和工作量)和产品(如产生的代码行(LOC)、运行速度以及某段时间内报告的缺陷)的直接测量;(2)产品的间接测量，包括功能、质量、复杂性、有效性、可靠性、可维护性，以及许多其他的“产品特性”。将项目度量联合起来可以得到整个软件组织公用的过程度量。软件测量软件测量有两种分类方法：(1)软件过程(如花费的成本62面向规模的度量面向规模的软件度量是通过规范化质量和(或)生产率的测量值而得到的，这些测量都基于已经开发的软件的规模。如果软件组织一直在做简单的记录，就会产生一个如图19-2所示的面向规模测量的表。该表列出了在过去几年中完成的每一个软件开发项目及其相关的测量数据。面向规模的度量面向规模的软件度量是通过规范化质量和(或)生产63面向规模的度量图19-2面向规模的度量面向规模的度量图19-2面向规模的度量64面向规模的度量为了产生能和其他项目中同类度量进行比较的度量，选择代码行作为规范化值。根据表中所包含的基本数据，每个项目都能得到一组简单的面向规模的度量：每千行代码(KLOC)的错误数；每千行代码的缺陷数；每千行代码的成本；每千行代码的文档页数；此外，还能计算出其他有意义的度量。面向规模的度量为了产生能和其他项目中同类度量进行比较的度量，65面向功能的度量面向功能的软件度量使用功能测量数据作为规范化值。应用最广泛的面向功能的度量是功能点FP。功能点是根据软件信息域的特性及复杂性来计算的。面向功能的度量面向功能的软件度量使用功能测量数据作为规范化值66调和代码行和功能点的度量方法代码行和功能点之间的关系依赖于实现软件所采用的程序设计语言及设计的质量。很多研究试图将FP测量和LOC测量联系起来。表19-1(P340页)给出了在不同的程序设计语言中实现一个功能点所需的平均代码行数的粗略估算。调和代码行和功能点的度量方法代码行和功能点之间的关系依赖于实67调和代码行和功能点的度量方法人们发现基于功能点和LOC的度量都是对软件开发工作量和成本的比较精确的判定。然而，如果使用LOC和FP进行估算，还必须要建立一个历史信息基线。在过程度量和项目度量中，最关心的是生产率和质量——软件开发“输出量”（作为投入的工作量和时间的函数）的测量和对生产的工作产品的“适用性”的测量。为了进行过程改进和项目策划，必须掌握历史的情况。在以往的项目中，软件开发的生产率是多少？生产的软件质量如何？怎样利用以往的生产率数据和质量数据推断现在的生产率和质量？如何利用这些数据帮助我们改进过程，以及更精确地规划新的项目？调和代码行和功能点的度量方法人们发现基于功能点和LOC的度量68面向对象的度量传统的软件项目度量也可以用于估算面向对象的软件项目。但是，这些度量并没有提供对进度和工作量进行调整的足够的粒度，而这却是在演化模型或增量模型中进行迭代时所需要的。[LOR94]提出了下列用于OO项目的度量。场景脚本的数量关键类的数量支持类的数量每个关键类的平均支持类数量子系统的数量面向对象的度量传统的软件项目度量也可以用于估算面向对象的软件69面向用例的度量与LOC或FP相类似，使用用例作为规范化的测量应该是合理的。同FP一样，用例也是在软件过程早期进行定义的。在重大的建模活动和构造活动开始之前，就允许使用用例进行估算。用例描述了用户可见的功能和特性，这些都是系统的基本需求。用例与程序设计语言无关。另外，用例的数量同应用系统的规模和测试用例的数量成正比，而测试用例是为了充分测试该应用系统而必须设计的。面向用例的度量与LOC或FP相类似，使用用例作为规范化的测量70软件质量度量软件工程的基本目标是在某个时间框架内开发出满足市场需要的高质量的系统、应用或产品。为了达到这个目标，软件工程师必须在成熟的软件过程背景下，使用有效的方法及现代化的工具。此外，一个优秀的软件工程师必须通过测量来判断能否实现高质量。软件质量度量软件工程的基本目标是在某个时间框架内开发出满足市71软件质量度量将软件工程师个人收集的私有度量结合起来，可以提供项目级的