实验二 20141344013 张逸鸣

1、南京信息工程大学实验(实习)报告实验名称 软件产品的质量度量 实验日期 2016.3.23 指导老师 徐旦华 学院 计算机与软件 专业 软件工程 班级 1 姓名 张逸鸣 学号 20141344013 一、 实验目的通过网络等参考资料了解软件工程领域中不同的软件质量模型的原理及特点，了解软件产品规模度量的相关方法及相应的特点，了解软件产品复杂度度量方法及其特点，了解软件产品缺陷密度度量相关方法及原理，了解顾客满意度度量方法，并进行对比分析。二、 实验时间2学时。三、 实验内容1、 依据网络资源，了解软件度量中的相关知识，了解不同的软件质量模型及其各自的特点2、 重点了解软件产品规模度量方法、软件

2、复杂度度量方法、软件产品缺陷度量方法及顾客满意度度量方法。3、 分析对比各类方法的特点。四、 实验结论1、 软件度量： 在软件开发中，软件度量的根本目的是为了管理的需要。利用度量来改进软件过程。人们是无法管理不能度量的事物。在软件开发的历史中，我们可以意识到，在60年代末期的大型软件所面临的软件危机反映了软件开发中管理的重要性。而对于管理层人员来说：没有对软件过程的可见度就无法管理；而没有对见到的事物有适当的度量或适当的准则去判断、评估和决策，也无法进行优秀的管理。我们说软件工程的方法论主要在提供可见度方面下工夫。但仅仅是方法论的提高并不能使其成为工程学科。这就需要使用度量。度量是一种可用于决

3、策的可比较的对象。度量已知的事物是为了进行跟踪和评估。对于未知的事物，度量则用于预测。本专题将讨论软件度量的一些基本问题。但应认识到软件度量的成果是非常初步的，还需要大量工作才可能真正地做到实用化，但它的实用化成就将对软件的高质量和高速发展有不可估量的影响。那么, 一、什么是度量呢? 度量概念： 度量存在于左右我们生活的很多系统的核心之中。在经济领域,度量决定着价格和付款的增加;在雷达系统中,度量使我们能透过云层探测到飞机;在医疗系统中,度量使得能够诊断某些特殊疾病;在天气预测系统中,度量是天气预报的基础;没有度量,技术的发展根本无法进行。度量的正式定义是: 度量 是指在现实的世界中,把数字或

4、符号指定给实体的某一属性, 以便以这种方式来根据已明确的规则来描述它们. 因此,度量关注的是获取关于实体属性的信息。一个实体可以是一个实物,如人或房间；或者是一个事件，如旅行；或软件项目的测试阶段。属性是我们所关注的实体的特征或特性,如血压的高度(人)、时间(测试阶段)、范围或颜色(房间)、花销(旅行) 等。因此,说"度量事物"或"度量属性"的说法是不完全正确的;应该说"度量事物的属性"。"度量房间"的说法是模糊的;我们可以说度量它的长度、范围和温度等。同样说"度量温度"的说法也是模糊的,应该说

5、：我们度量的是某一特定地理位置和特定情况下的温度。 理论支持： 如在设计电路的时候我们应用欧姆定律。这个定律描述了电路中电阻、电流和电压三者之间的关系。但是这些理论已超出了一般意义上的科学方法的范畴，在这种范畴里最基本的东西是度量。度量除了在发展一个理论的过程中起作用外，我们使用度量并应用它们。因此设计一个特定电流和电阻的电路时我们就知道需要多大的电压。 如果没有度量，我们很难想象关于电子、机械、及普通工程的定律能得到发展。但事实上在软件工程的主流里度量却被忽略了。 情况是：当我们在设计和开发软件产品的时候，我们并未能制定出度量的目标。例如：我们保证说我们将使用户界面友好、可靠、易于维护；而并

6、未使用度量的术语来详细说明它们的具体含义。Gilb曾经说过：所谓模糊目标定理，就是没有明确目标的项目将不能明确地达到它的目标。我们未能对构成软件项目实际费用的各个不同的部分进行有效的度量。譬如：通常我们并不知道，和测试阶段相比，设计阶段花费时间多大。我们并未试图使我们开发的产品的各种质量合格。因此我们未能使用术语（如：在一段时间里使用故障的可能性、把产品安装到新环境中需花费的工作量等）向潜在的用户说明产品的可靠性很高。我们总是试图说服自己使用另一种新的革新的开发技术和方法进行软件开发 事实上，我们在软件度量方面做的工作很少很少，而且所作的度量方面的工作也与一般科学意义上的度量相分离。我们经常会

7、看到诸如此类的话："软件的费用有80%花费在维护上。"或"软件每一千行程序中平均有55个Bugs。"。但是这些话并没有告诉我们这样的结果是怎样产生的、试验是怎样设计、执行的、度量的是那个实体、及错误的框架是什么等等。没有这些东西，我们就不能在我们自己的环境中客观地进行反复度量，重现度量的结果以获得与工业标准的真实比较。因此，归因于度量不充分的问题的产生是由于缺乏严格的度量方法造成的。 除了传统的对计算机硬件的性能进行度量外，对算法的复杂性的度量一直是计算机科学的重要组成部分。但是，这种度量方法只适用于小程序，而对大型、复杂的软件来说它却无能为力了。这就属

8、于软件工程的范畴了。如果我们不承认度量将会一个更重要的作用的话，软件危机将在随后的几年里依然存在。 意义： 软件开发正在经受一场危机。费用超支（特别是在维护阶段的花费太大）、生产率低下、 以及质量不高等问题正困扰着它。简言之，软件开发经常处于失控状态。软件之所以失控是因为没有度量。Tom Demarco曾经说过："没有度量就不能控制。"这种说法是好的，但不完全。并不能说为了获得控制必须进行度量。度量活动必须有明确的目标或目的，而正是这决定着我们选择哪种属性和实体进行度量。这个目标与软件开发、使用时所涉及的人的层次有关。 以下主要从管理者和软件工程师两种角度来考虑，为了达到各

9、种目标所要进行的度量工作。 对管理者而言：1.需要度量软件开发过程中的不同阶段的费用。例如：度量开发整个软件系统的费用（包括从需求分析阶段到发布之后的维护阶段）。必须清楚这个费用以决定在保证一定的利润的情况下的价格。2.为了决定付给不同的开发小组的费用，需要度量不同小组职员的生产率。3.为了对不同的项目进行比较、对将来的项目进行预测、建立基线以及设定合理的改进目标等，需要度量开发的产品的质量。4.需要决定项目的度量目标。例如：应达到多大的测试覆盖率、系统最后的可靠性应有多大等。5.为了找出是什么因素影响着费用和生产率，需要反复测试某一特定过程和资源的属性。6.需要度量和估计不同软件工程方法和工

10、具的效用，以便决定是否有必要把它们引入到公司中。 对软件工程师而言：1.需要制定过程度量以监视不断演进的系统。这包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等等。2.需使用严格的度量的术语来指定对软件质量和性能的要求，以便使这些要求是可测试的。例如：系统必须"可靠"，可用如下的更具体 的文字加以描述："平均错误时间必须大于15个CPU时间片。"3.为了合格需要度量产品和过程的属性。例如：看一个产品是否合格要看产品的一些可度量的特性如"测试阶段少于20个错误。"，"每个模块的代码行不超过100行。"，和开发

11、过程的一些属性如"单元测试必须覆盖90%以上的用例。"等。4.需要度量当前已存在的产品和过程的属性以便预测将来的产品。例如：(1).通过度量软件规格说明书的大小来预测目标? 的大小。(2).通过度量设计文档的结构特性来预测将来维护的"盲点"。(3).通过度量测试阶段的软件的可靠性来预测软件今后操作、运行的可靠性。 研究上面我们列出的度量的目标和活动我们可以发现：软件度量的目标可大致 概括为两类。 其一，我们使用度量来进行估计。这使得我们可以同步地跟踪一个特定的软件项目 。 其二，我们应用度量来预测项目的一些重要的特性。但是，值得指出的是我们不能 过分夸大

12、这些预测。因为它们并不是完全正确的。软件度量得到也仅仅是预测而已。有些人甚至认为只要使用合适的模型和工具，所获得的预测可以精确到只需使用极少的其他度量（甚至根本就不用使用度量）。事实上，这种期望是不现实的。2、 软件质量模型： Jim McCall 软件质量模型（1977 年） Barry W. Boehm 软件质量模型（1978 年） FURPS/FURPS+ 软件质量模型 R. Geoff Dromey 软件质量模型 ISO/IEC 9126 软件质量模型（1993 年） ISO/IEC 25010 软件质量模型（2011 年1. Jim McCall 软件质量模型 常见的软件质量模型 关

13、于软件质量模型，业界已经有很多成熟的模型定义，比较常见的质量模型有 McCall 模型、Boehm 模型、FURPS 模型、Dromey 模型和 ISO9126 模型。 · Jim McCall 软件质量模型（1977 年） · Barry W. Boehm 软件质量模型（1978 年） · FURPS/FURPS+ 软件质量模型 · R. Geoff Dromey 软件质量模型 · ISO/IEC 9126 软件质量模型（1993 年） · ISO/IEC 25010 软件质量模型（2011 年） Jim McCall 软件质量模型

14、（1977 年） Jim McCall 的软件质量模型，也被称为 GE 模型（General Electrics Model）。其最初起源于美国空军，主要面向的是系统开发人员和系统开发过程。McCall 试图通过一系列的软件质量属性指标来弥补开发人员与最终用户之间的沟壑。McCall 质量模型使用 3 中视角来定义和识别软件产品的质量：1. Product revision (ability to change)；2. Product transition (adaptability to new environments)；3. Product operations (basic opera

15、tional characteristics)。McCall 模型通过层级的要素、标准和指标来详述这 3 个视角定义（产品修改、产品转移、产品运行）：11 Factors (To specify)描述软件的外部视角，也就是客户或使用者的视角；23 Criterias (To build)：描述软件的内部视角，也就是开发人员的视角；Metrics (To control)：定义衡量指标和方法。2. Barry W. Boehm 软件质量模型（1978 年） Boehm 软件质量模型试图通过一系列的属性的指标来量化软件

16、质量。Boehm 的质量模型包含了 McCall 模型中没有的硬件属性。Boehm 模型也类似于 McCall 的质量模型，采用层级的质量模型结构，包括高层属性、中层属性和原始属性。高层属性主要关注 3 个问题：As-is utility；Maintainability；Portability。中层属性包含了 7 个质量要素：Portability (General utility characteristics)；Reliability (As-is utility characteristics)；Efficiency (As-is utility characteristics)；Usa

17、bility (As-is utility characteristics, Human Engineering)；Testability (Maintainability characteristics)；Understandability (Maintainability characteristics)；Flexibility (Maintainability characteristics, Modifiability。)可以看出，Boehm 模型和 McCall 模型有些相似，区别在于 McCall 模型主要关注于高层属性（“As-is utility”）的精确度量上，而 Boehm

18、 模型则基于更广泛的属性，并且对可维护性做了更多的关注。3. FURPS/FURPS+ 软件质量模型 FURPS 模型最初由 Robert Grady 提出，后来由 Rational Software 进行扩展至 FURPS+。FURPS 模型包括：Functionality；Usability；Reliability；Performance；Supportability。FURPS 包括两种不同的类型：功能性和非功能性。4. R. Geoff Dromey 软件质量模型： Dromey 软件质量模型由 3 个主要元素组成:1.Product properties that influence

19、 quality；2.High level quality attributes；3.Means of linking the product properties with the quality attributes.构建该质量模型包括以下 5 个步骤：1.Chose a set of high-level quality attributes necessary for the evaluation；2.List components/modules in your system；3.Identify quality-carrying properties for the compone

20、nts/modules (qualities of the component that have the most）；4.impact on the product properties from the list above)；5.Determine how each property effects the quality attributes；6.Evaluate the model and identify weaknesses.5. ISO/IEC 9126 软件质量模型（1993年） ISO/IEC 9126: Software Product Evaluation: Quali

21、ty Characteristics and Guidelines for their Use-standard。ISO/IEC 9126 模型是建立在 McCall 和 Boehm 模型之上的，同时加入了功能性要求，还包括识别软件产品的内部和外部质量属性。软件的 6 个质量特征:1.功能性(Functionality)：当软件在指定条件下使用时，软件产品提供满足明确和隐含需要的功能的能力；2.可靠性(Reliability)：在指定条件下使用时，软件产品维持规定的性能级别的能力；3.易用性(Usability)：在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力；4.效率(Eff

22、iciency)：在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力；5.可维护性(Maintainability)：软件产品可被修改的能力。修改可能包括纠正、改进或软件对环境、需求和功能规约变化的适应程度；6.可移植性(Portability)：软件产品从一种环境迁移到另一种环境的能力。6. ISO/IEC 25010 软件质量模型（2011年） ISO/IEC 9126-1：2001 已被 ISO/IEC 25010：2011 代替并废止。上图阐明了ISO/IEC 25000 SQuaRE系列标准的组织，其组成部分均称为分部。 SQuaRE系列国际标准内的分部有：1.ISO/

23、IEC 2500n 质量管理分部。构成这个分部的那些标准定义了由SQuaRE系列标准中的所有其他标准引用的全部公共模型、术语和定义。在针对特定应用情况使用适当标准方 面的引用路径和高级的实用建议有助于所有类型的用户。这一分部还提供了用于负责管理软件产品需求和评价的支持功能的要求和指南。2.ISO/IEC 2501n 质量模型分部。构成这个分部的标准给出一个包括软件内部质量、 软件外部质量和软件使用质量的特性的详细质量模型。此外, 内部和外部的软件质量特性被分解细化成一些子特性，并且还提供了使用该质量模型的实用指南。3.ISO/IEC 2502n 质量测量分部。构成这个分部的标准包括软件产品质量

24、测量参考模型、质量测量的数学定义及其应用的实用指南。给出了应用于软件内部质量、软件外部质量和使用质量的测量。定义并给出了构成后续测量基础的质量测量元素。4.ISO/IEC 2503n 质量要求分部。构成这个分部的标准帮助用户规定质量要求。这些质量要求可用在要开发的软件产品的质量需求抽取过程中或用作评价过程的输入。需求定义过程可映射到ISO/IEC 15288 中定义的技术过程。5.ISO/IEC 2504n 质量评价分部。构成这个分部的标准给出了无论由评价方、需方还是由开发方执行的软件产品评价的要求、建议和指南。还给出了作为评价模块的测量文档编制支持。6.ISO/IEC 25050到ISO/I

25、EC 25099保留用于SQuaRE扩展的国际标准和/或技术报告。 软件质量模型包含 8 个特征，并且被进一步分解为可以度量的内部和外部多个子特征。3、 四类度量方法：1. 软件产品规模度量方法：软件开发项目规模度量(size measurement)是估算软件项目工作量、编制成本预算、策划合理项目进度的基础。规模度量是软件项目失败的重要原因之一。一个好的规模度量模型可以解决这一问题。有效的软件规模度量是成功项目的核心要素：基于有效的软件规模度量可以策划合理的项目计划，合理的项目计划有助于有效地管理项目。规模度量的要点在于：由开发现场的项目成员进行估算；灵活运用实际开发作业数据；杜绝盲目迎合顾

26、客需求的“交期逆推法”。 软件规模度量有助于软件开发团队准确把握开发时间、费用分布以及缺陷密度等等。软件规模的估算方法有很多种，如：功能点分析(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)等

27、，这些方法不断细化为更多具体的方法。2. 软件复杂度度量方法：根据软件的生命周期，Halstead复杂性度量和McCabe圈复杂度度量都属于可以应用在软件测试阶段的度量技术。在基于程序体积的复杂性度量算法中，最具影响力的是20世纪70年代由Halstead提出的软件科学度量理论。 Halstead从统计学和心理学的角度研究软件复杂性，把程序看成由可执行的代码行词汇(操作符和操作数)组成的符号序列。Halstead在其度量理论中采用一些基本的度量值来确定软件开发中的一些定量规律，这些度量值通常在程序产生之后得出，或者设计完成之后算出。Halstead的重要结论之一是：程序实际的Halstead长

28、度值N可以由代码行词汇n算出。 McCabe于1976年指出：应该用程序流图的圈数(Cycloramic number)来测量程序的复杂性，并基于程序控制论和图论提出了经典的McCabe圈复杂性度量理论。McCabe控制流图是一种简化的程序流程图，如果把流程图中的每个基本框抽象为一个点，略去每个框的具体信息，就产生一个由结点和弧（或称为分支）组成的图，称为控制流图。控制流图是有向图，可用G = <V，E>表示，其中V表示结点集合，代表程序流程图中的基本框；E表示有向边，代表程序流程图中的控制方向。代码行数度量法：代码行数度量法以程序的总代码行数作为程序复杂性的度量值。这种度量方法有

29、一个重要的隐含假定是：书写错误和语法错误在全部错误中占主导地位。然而，由于这类错误严格来讲是私有的，不应把它们计入错误总数之中，在这种情况下，这种度量方法的前提就不存在。因而，代码行数度量法是一种很粗糙的方法，在实际应用中很少使用。 McCabe度量法：McCabe度量法以程序流程图的分析为基础，通过计算强连通的程序图中线性无关有向环的个数，建立复杂性的度量。其计算公式为：V(G)=m-n+p，其中V(G)是强连通有向图G中的环数；m是G中的弧数；n是G中的节点数；p是G中分离部分的数目。 对于一个正常的程序来说，程序图总是连通的，即p=1。为了使之强连通，我们可以从出口点到入口点画一条虚弧。

30、实际上，我们常常采用另一种计算方法来获得McCabe度量值，即对于单入口单出口模块(通常都属这种情况)，我们只需计算程序中判断语句个数加1即可得V(G)值。McCabe度量法实质上是对程序控制流复杂性的度量，它并不考虑数据流，因而其科学性和严密性具有一定的局限性。 Halstead度量法：Halstead度量法通过计算程序中的运算符和操作数的数量对程序的复杂性加以度量。设n1表示程序中不同运算符的个数，n2表示程序中不同操作数的个数，N1表示程序中实际运算符的总数，N2表示程序中实际操作数的总数。令H表示程序的预测长度，Halstead给出H的计算公式为：H=n1log2n1+n2log2n2

31、；令N表示实际的程序长度，其定义为：N=N1+N2。Halstead的重要结论之一是：程序的实际长度N与预测长度非常接近。这表明即使程序还未编写完也能预先估算出程序的实际长度N。Halstead还给出了另外一些计算公式，包括：程序容量：V=N log2(n1+n2)，程序级别：L=(2/n1) * (n2/N2)，编制程序所用的工作量：E=V/L，程序中的错误数预测值：B=N log2(n1+n2)/3000。Halstead度量实际上只考虑了程序的数据流而没有考虑程序的控制流，因而也不能从根本上反映程序的复杂性。3. 软件产品缺陷度量方法：需求变化的原因：需求度量的主要目的是度量需求的数量、

32、需求变化的类型以及变化数量在软件工程阶段的分布情况需求的变化，不论返工还是新增，都意味着劳动成本的增加需求变化是引起软件危机的根本原因，需求越在早期确定，软件项目按计划完成的可能性就越大如果度量结果表明，在设计、编码和测试阶段存在大量的需求变更，则说明组织与之相关的软件过程有缺陷，应及时纠正或采用更合适的软件工程方法。IEEE公布的需求定义从用户和开发者的角度来说明什么是需求。可以将需求分解为四个层次：业务需求、用户需求、功能需求和非功能需求。这些需求往往在开发过程中发生变更，因而提出变更有可能在开发的任何阶段。引起需求变更可能有多种因素，单纯的用户因素：由于用户在软件开发的过程中不断加深对系

33、统的了解，引发的对需求的新认识，于是提出了新的、变更了的需求；系统因素：在系统内部，如计算机硬件、操作软件、数据或支撑软件等的变更要求与其相适应，从而引起的需求的变更；工作环境因素：与软件运行相关的工作制度或法规、条例等的变更，或是业务变更导致的需求变更；需求开发工作缺陷：需求调研、分析、定义和评审工作不够充分，致使需求规格说明中存在着隐含问题，在开发过程中发现。或者需求开发中开发人员与用户沟通的不够充分，或者对技术和市场的发展认识不够。 基于阶段的缺陷度量：基于阶段的缺陷度量将软件生命周期分割为不同的阶段和过程。需求变更管理主要是一个在项目开发过程中对需求变更进行控制的过程，该过程包括变更建

34、议的提出，分析变更的影响并据此做出变更决策，监督变更的实施过程等。规范化的变更控制过程可以有效地减少随意变更的数量，让变更处在一种可控的实施过程中。 实施基于阶段的缺陷度量的前提首先是在软件生命周期过程中具有系统化、规范化的需求获取和管理措施，如对各阶段的需求和需求变更的评审、论证等。其次，度量要与软件开发过程紧密结合，软件阶段的划分为度量提供了数据采集点和采集机制。本文参照具有可能迭代的瀑布的生命周期模型，将软件生命周期划分为5个阶段：需求阶段；设计阶段；实现阶段(编码、单元测试)；测试阶段(集成测试、系统测试、验收测试)；运行阶段。 基于阶段的缺陷度量矩阵如表1所示，该矩阵记录了整个生命周

35、期各阶段发现的缺陷数量、缺陷来源、缺陷被发现阶段、占总缺陷的比率和缺陷传递率等信息。4. 顾客满意度度量方法： 顾客满意是软件开发项目的主要目的之一，而顾客满意目标要得以实现，需要建立顾客满意度度量体系和指标对顾客满意度进行度量。顾客满意度指标(CSI：customer satisfaction index)以顾客满意研究为基础，对顾客满意度加以界定和描述。项目顾客满意度量的要点在于：确定各类信息、数据、资料来源的准确性、客观性、合理性、有效性，并以此建立产品、服务质量的衡量指标和标准。企业顾客满意度度量的标准会因为各企业的经营理念、经营战略、经营重点、价值取向、顾客满意度调查结果等因素而有所

36、不同。比如：NEC于2002年12月开始实施的CSMP 活动的度量尺度包括共感性、诚实性、革新性、确实性和迅速性，其中，将共感性和诚实性作为CS活动的核心姿态，而将革新性、确实性和迅速性作为提供商品和服务中不可或缺的尺度。每个尺度包括两个要素，各要素包括两个项目，共计5大尺度、10个要素和20个项目。例如，共感性这一尺度包括“了解顾客的期待”、“从顾客的立场考虑问题”这两个要素；“了解顾客的期待”这一要素又包括“不仅仅能胜任目前的工作还能意识到为顾客提供价值而专心投入”、“对顾客的期望不是囫囵吞枣而是根据顾客的立场和状况来思考顾客到底需要什么并加以应对”这两个项目。 美国专家斯蒂芬(Steph

37、en H.Kan)在软件质量工程的度量与模型(Metrics and Models in Software Quality Engineering)中认为，企业的顾客满意度要素如表所示：作为企业的顾客满意度的基本构成单位，项目的顾客满意度会受到项目要素的影响，主要包括：开发的软件产品、开发文档、项目进度以及交期、技术水平、沟通能力、运用维护等等。具体而言，可以细分为如表7-2所示的度量要素，并根据这些要素进行度量。顾客满意度项目 顾客满意度度量要素软件产品 功能性、可靠性、易用性、效率性、可维护性、可移植性开发文档 文档的构成、质量、外观、图表以及索引、用语项目进度以及交期 交期的根据、进度迟延情况下的应对、进展报告技术水平 项目组的技术水平、项目组的提案能力、项目组的问题解决能力沟通能力 事件记录、式样确认、Q&A运用维护 支持、问题发生时的应对速度、问题解决能力。4、 软件质量度量的意义： 软件开发