软件度量复习
软件规模度量——软件内部属性的测量
3.1 基本知识 1.可以从哪些方面测量软件的规模?
软件功能数量: 数据流图、用例图
软件模块数量:模块功能结果图
代码的行数:操作符、操作数
设计文档的页数
用户手册的页数
2. 软件规模可以用于反映:
Effort 工作量(人月)
Cost 成本
Productivity 效率
Schedule 进度安排
3. 可以根据以下方面定义软件规模:
Length 长度(代码长度、规格说明书长度)
Functionality 功能性
Complexity 复杂性
Reuse 软件重用
4. 通过软件功能性(Functionality)来度量软件规模:
功能点 Function Point
特征点 Feature Point
对象点 Object Point
用例点 Use-case Point
3.2 功能点度量方法 (FunctionPoint,FP)
功能点度量就方法可以通过数据流图(Data Flow Diagram,DFD)来分析;
数据流图中四个元素:起点终点、数据流、数据处理、数据存储;
功能点计算方法: Function Point = UFC * VAF (FP = 未调整前的功能点数 * 调整因子);
(1) 按照下表测量数据流图中的五类元素:
|
测量元素 |
个数 |
权重因子 |
小计 |
|
输入个数 |
3 4 6 |
||
|
输出个数 |
4 5 7 |
||
|
用户查询个数 |
3 4 6 |
||
|
内部文件个数 |
5 7 10 |
||
|
外部接口个数 |
7 10 15 |
||
|
总计 |
(2)将 5 类测量元素(输入、输出、查询、内部文件、外部接口)的难易程度分为三 个难易级别:简单、一般、复杂,并给出对应的权重因子。评价每个测量元素的难易级别, 计算权重因子。
(3)UFC 计算与两个因素有关:5 类测量元素(输入、输出、查询、内部文件、外部 接口)的个数、每个测量元素的难易程度(简单、一般、复杂)。
从理论上讲,共有 15 个不同种类的项(5 类中每一类都有三个复杂性等级),因此,未
调整前功能点数计算方法:用各类的项目数乘以该类的权重值,再对这 15 个乘积求和:
UFC = ∑((第𝑖类项数) ∗ 权重值𝑖)
(4)VAF:性能要求对软件规模的影响,包括内部系统复杂性与用户角度的功能性相 关的复杂性。
共 14 项因素 Fi(1≤i≤14),影响程度由轻到重从 0-5 评价。0 意味着子因素对系统没 有影响,3 意味着子因素对系统的影响适中,5 意味着子因素对正在构造的系统起关键作用。
表 1 技术复杂性系统组成部分
|
F1 |
可靠的备份与恢复 |
F8 |
在线更新 |
|
F2 |
数据通信 |
F9 |
复杂接口 |
|
F3 |
分布式的功能 |
F10 |
复杂处理 |
|
F4 |
性能 |
F11 |
可重用性 |
|
F5 |
大量使用的配置 |
F12 |
易安装性 |
|
F6 |
在线数据入口 |
F13 |
多场所 |
|
F7 |
易操作性 |
F14 |
容易变更 |
(5)
VAF 取值[0.65, 1.35],所有 Fi 的值都是 0 时 VAF=0.65,所有 Fi 的值是 5 时 VAF=1.35。
功能点度量方法优点:
在设计与编码之前即可对软件规模进行预测,即在需求分析阶段即可进行预测; 在软件开发周期的前期即可预测项目的成本、工作量及进度; 有助于合同谈判(成本、进度安排); 对于软件规模的度量有据可依,采用一定的标准;
功能点度量方法缺陷:
FP 计算带有主观性:5 类测量元素的难易程度以及性能影响的程度都由人来决定;
重复计算问题:在未调整之前功能点数的输入输出的加权计算和 VAF 计算时,对内部 复杂性进行了重复计算。
数值不直观的问题:当 Fi 的复杂性为“一般”时评定的等级都为 3,则 VAF 的值应为 1。 但根据公式计算得到的 VAF=1.07。
在生命周期早期使用的问题:计算功能点,不能只有用户需求文档,还需要较完整的软 件系统规格说明。
应用领域问题:功能点度量适用于度量数据处理较多的系统,如 MIS 系统,而对实时 系统、控制系统或科学应用领域的系统不太适合。
3.3 特征点度量方法(FeaturePoint, FeP) 特征点度量方法是在功能点度量方法的基础上考虑算法的复杂性,即考虑了系统中的以
下因素:输入、输出、查询、内部文件、外部接口、算法。 特征点度量方法适用于对实时系统、控制系统、嵌入式系统等具有复杂算法的系统的规
模进行度量。
3.4 对象点度量方法(ObjectPoint,OP) 对象点度量方法是在软件开发过程中的可行性分析阶段对软件规模进行初步度量的方
法。
将系统中对象分为三类:Screen(界面)、Report(报表)和第三代语言的组件
将三类对象分为简单、一般、复杂三类,根据界面、报表中数据源(表与视图)的数量及来源来评估。
界面复杂性等级
|
包含的 视图数 |
数据表的数量和来源 |
||
|
总数< 4 |
总数< 8 |
总数 8+ |
|
|
<3 |
简单 |
简单 |
适中 |
|
3-7 |
简单 |
适中 |
复杂 |
|
8+ |
适中 |
复杂 |
复杂 |
报表复杂性等级
|
包含的 小节数 |
数据表的数量和来源 |
||
|
总数< 4 |
总数< 8 |
总数 8+ |
|
|
<3 |
简单 |
简单 |
适中 |
|
3-7 |
简单 |
适中 |
复杂 |
|
8+ |
适中 |
复杂 |
复杂 |
对象点的复杂性权重
三类对象的点数相加即可得到系统的对象点数。 如果考虑到系统中有重用,假设 r%的对象是从以前的项目中重用来的,则: 新对象点=对象点*(1-r%)
3.5 用例点度量方法(Use-CasePoint, UP) 用例图是在面向对象方法分析设计软件时用于进行需求分析的一种方法。 用例图中包括用例与角色,用例点度量软件规模的方法主要衡量用例中的用例与角色。 计算用例点六个步骤:
(1) 计算未调整前的角色权重(Unadjusted actor weights, UAW)
(2) 计算未调整前的用例权重(Unadjusted use case, UUC)
(3) 计算未调整前的用例点(UUCP) UUCP = UAW + UUC
(4) 计算技术复杂因子(TCF)
TCF = 0.6 +(0.01 * TFactor)
(5) 计算环境因子(EF)
EF = 1.4 +(-0.03 * EFactor)
(6) 计算调整后的用例点(UPC) UPC = UUCP * TCF * EF
角色权重评估,将角色分为简单、一般、复杂三种类型:
两种用例权重评估方法,即基于交互的评估方法与基于分析类的评估方法,两种方法都 将用例分为简单、一般、复杂三种类型
因为用例是对一组动作序列(交互)的抽象描述,系统会执行这些动作序列,产生相应 的结果。因此用例中包含的这些交互越多就越复杂。因为用例分析是从用例模型到分析模型的过程,是需求与设计之间的桥梁。用例分析把 系统的行为分配给分析类,让分析类交互完成系统的行为。因此,用例涉及到的分析类越多 就越复杂。分析类包括三种类:边界类、控制类、实体类。
|
角色类型 |
描述 |
权重因子 |
|
简单 |
程序接口 |
1 |
|
一般 |
交互接口、协议驱动的接口 |
2 |
|
复杂 |
图形化接口、人机接口 |
3 |
|
用例类型 |
描述 |
权重因子 |
|
简单 |
3 个或少于 3 个交互 |
5 |
|
一般 |
4-7 个交互 |
10 |
|
复杂 |
超过 7 个交互 |
15 |
|
用例类型 |
描述 |
权重因子 |
|
简单 |
少于 5 个分析类 |
5 |
|
一般 |
5-10 个分析类 |
10 |
|
复杂 |
超过 10 个分析类 |
15 |
3.6 Length 长度来衡量软件规模的方法 Halstead 方法
LOC
规格说明与设计的长度
3.8 LOC(Line Of Code)
LOC = NCLOC + CLOC
NCLOC:Non-Commented Line Of Code 非注释行
CLOC: Commented Line Of Code 注释行
注释密度:CLOC/LOC,反映了程序的可理解性、可修改性、可维护性
LOC 度量的优点:
(1) 简单、可自动测量
(2) 与程序的工作量及成本直接相关
LOC 度量的缺点:
(1) 定义模糊(如代码行数是否算注释行)
(2) 代码长度与编程语言相关
(3) 不适用于在软件开发早期阶段对软件规模进行预测
(4) 与开发者的能力有关
第四章 软件结构度量方法
早期软件度量学和当时面向功能分解的设计方法相联系,多以模块度量为主。
面向过程的程序设计,影响软件质量的主要因素:耦合性、内聚性、复杂性、 模块化及规模大小。
利用软件模块结构图进行分析,可以从以下方面度量:
模块间传递数据量的最大值
模块间传递数据量的平均值
模块间传递数据量的总数
模块间公共数据数目
模块扇入、扇出平均值和最大值
模块条件调用、循环调用数目
最大深度(层数)
一般认为设计良好的软件产品用其内部结构来描述其特点。软件内部结构属 性包括模块性、耦合、内聚、复杂度、信息流、重用度等。如果能够对这些属性 进行度量,就能够找出软件中难于实现、测试与维护的部分。
4.2 结构度量的类型
结构会影响到设计、编码和测试的时间与工作量、维护成本以及复杂性。 主要对三类结构进行度量:控制流结构、数据流结构、数据结构。 控制流(Control Flow)解决的是各种指令在程序中的执行顺序问题,反映了
程序的迭代和循环性质。程序规模对一条指令只能进行一次计数,而控制流反映 出在程序在实际运行时可能会多次执行某条指令。
数据流(Data Flow)能够在程序创建或处理某个数据项的过程中对其轨迹进 行跟踪。数据流度量描述了数据在与程序进行交互的行为。
数据结构(Data Structure)涉及数据自身的组织问题,与程序无关。如果把 数据元素组织成表、队列、堆栈或者其他具有良好定义的结构,则程序实现时就 容易对创建、修改或删除数据的算法进行良好定义。数据结构能够反映出在编写 “用来处理数据”的程序时的难度以及定义“用来验证程序正确性”的测试用例
时的难度。有些情况下,程序的复杂性是由复杂的数据结构而不是复杂的控制流 或数据流结构引起的。
4.3 控制流结构
控制流度量的建模通常采用有向图(Directed Graph)。
在有向图中,每个结点(或点)所对应的是一条程序语句,每段弧(或有向 边)所表示的是从一条语句到另一条语句的控制流。这个有向图是控制流图 (Control-flow Graph)或流图(Flow Graph)。
McCabe 圈复杂性能够对控制流结构进行度量,有以下三种方法:
(1)用程序流图的圈数来测量程序的复杂性。(需要将程序流图的首尾结点 连起来)
(2)通过 V(G)= e – n +2 计算,其中 e 是程序流图中的边数,n 是程序 流图中的结点数。
(3)可以通过计算程序中的用于分支与循环判断的判定语句数量。
4.4 数据流结构 4.4.1 耦合
模块内的内聚(Cohesion)与模块间的耦合(Coupling)。
耦合:两个模块之间的相互依赖程度。因此耦合指的是模块对的一个属性, 而不是作为一个整体的设计属性。设计中模块的全集表示的是全局耦合(Global Coupling),全局耦合可以从可能的模块对中的耦合推导而来。
系统中有两个模块 x 和 y,两个模块之间可能有 6 种耦合关系:
-
(1) 无耦合关系 R0:x 和 y 之间没有任何联系,即 x 和 y 完全独立;
-
(2) 数据耦合关系 R1:x 和 y 通过参数产生联系,其中每个参数是一个数据元素或者是一个由不含控制元素的同类数据项的组成的集合。这种类型的耦合对模块之间的任何联系都是必须的;
-
(3) 标记耦合关系 R2:x 和 y 把相同的记录类型当作一个参数。这种类型的耦合可以使两个在其他方面不相关的模块相互依赖;
(4) 控制耦合关系 R3:x 向 y 传递了一个参数,能够控制 y 的行为。即传 递的参数是一个标志,如传递了 1 或 0 的值,用于控制 y 中程序的执行过程;
(5) 公共耦合关系 R4:x 和 y 引用相同的全局数据。这种类型的耦合会使得在全局数据格式改变时,必须改变所有公共耦合关系的模块。
(6) 内容耦合关系 R5:x 引用到 y 的内部,即 x 的一个分支进入 y,或者改变 y 内的数据,或者修改 y 内的某个语句。
以上 6 种耦合关系的排列顺序:顶端的依赖性最弱,底端的依赖性最强。所以 i〉j,则 Ri〉Rj。i 等于 1 或 2,则认为 x 和 y 之间是一种松散耦合(Loosely Coupled)。 等于 4 或 5,即公共耦合和内容耦合是属于紧耦合(Tightly Coupled)。
用(i, j)表示模块 x 和 y 之间的耦合性,其中 i 表示耦合关系 Ri,j 表示给定 类型的耦合出现在 x 和 y 之间的次数。
模块 x 和 y 之间耦合性的度量方法为:
c(x, y) = k + n / n+1
k 表示 x 和 y 之间存在的最大的耦合关系 Rk,n 是 x 和 y 之间的相互连接数。
(Fention, Melton. 1990)
假设系统 S 是由模块 D1, ..., Dp,..., Dq,...,Dn 组成,则系统 S 的全局耦合度 C 的 度量方法:
C(S)是集合{ c(Dp, Dq): 1≤p≤q≤n} 的中位数
系统 S 的全局耦合度反映了系统中连接性的总体水平。
耦合是影响系统设计质量的最重要属性之一。
4.4.2 内聚
模块内聚时指完成同一任务时对模块各个组成部分的需要程度。7 种内聚: 功能内聚:模块完成一个定义良好的功能; 顺序内聚:模块完成的功能不止一个,但这些功能出现的次序是规格说明所
规定; 通信内聚:模块完成的功能不止一个,但这些功能都位于同一个数据体上; 过程内聚:模块完成的功能不止一个,但这些功能只与一个通用过程相关;
时间内聚:模块完成的功能不止一个,这些功能是在相同的时间内出现的。 如:初始化模块。
逻辑内聚:模块完成的功能不止一个,但这些功能只在逻辑上相关; 巧合内聚:模块完成的功能不止一个,这些功能是不相关的。
以上 7 种耦合关系的排列顺序:顶端的内聚最强,底端的内聚最弱。
一个系统的内聚程度的度量方法:
内聚率 = 具有功能内聚的模块数/模块总数 (Yourdon and Constantine, 1979)
复杂的内聚度量方法 (Bieman and Ott, 1994) 4.4.3 信息流
模块和系统其他部分之间的信息流,存在于以下情况:
(1) 一个模块调用另外一个模块,并且向该模块传递信息;
(2) 被调用模块向调用模块返回一个结果。
如果被调用模块返回的信息随后被传递给第二个被调用模块,则认为存在局 部间接流(local indirect flow);如果信息流通过全局数据结构从一个模块传递到 另一个模块,则认为存在全局流(global flow)。
4.5 数据结构
通过对简单的数据类型(如整数类型、字符类型和布尔类型)、复杂数据结 构以及在这些数据类型的各种操作对数据结构进行度量。
Halstead 方法中对操作符、操作数的计算,即是一种数据结构的度量方法。
第六章 软件质量度量
外部属性:考虑与外部环境的关联时才能被测量的属性。 例如:可靠性是指无失效运行的概率。与及其运行的环境和用户有关; 内部属性在软件生命周期早期能够测量到,而外部属性只有在软件或产品完
成(或几乎完成)时才能测量;内部属性比外部属性容易测量;内部属性往往会 影响到外部属性,可以通过内部属性预测外部属性。
软件质量就是“软件与明确的和隐含的定义的需求相一致的程度”。具体地 说,软件质量是软件符合明确叙述的功能和性能需求、文档中明确描述的开发标 准、以及所有专业开发的软件都应具有的隐含特征的程度。
百度百科中的外部属性:
1.性能(Performance)是指系统的响应能力,即要经过多长时间才能对某个事 件作出响应,或者在某段时间内系统所能处理的事件个数;
2.可用性(Availability)是指系统能够正常运行的时间比例;
3.可靠性(Reliability)是指系统在应用或者错误面前,在意外或者错误使用的 情况下维持软件系统功能特性的能力;
4.健壮性(Robustness)是指在处理或者环境中系统能够承受的压力或者变更 能力;
5.安全性(Security)是指系统向合法用户提供服务的同时能够阻止非授权用 户使用的企图或者拒绝服务的能力;
6.可修改性(Modification)是指能够快速地以较高的性能价格比对系统进行变 更的能力;
7.可变性(Changeability)是指体系结构扩充或者变更成为新体系结构的能力; 8.易用性(Usability)是衡量用户使用软件产品完成指定任务的难易程度; 9.可测试性(Testability)是指软件发现故障并隔离定位其故障的能力特性,以
及在一定的时间或者成本前提下进行测试设计、测试执行能力; 10.功能性(Function ability)是指系统所能完成所期望工作的能力; 11.互操作性(Inter-Operation)是指系统与外界或系统与系统之间的相互作用
能力。
6.2 软件质量建模
McCall 质量模型、Boehm 质量模型、ISO 9126 质量模型
6.2.1 McCall 质量模型
McCall 质量模型分为产品运行、产品修正、产品转移三类。 产品运行:正确性、健壮性、效率、完整性、可用性、风险; 产品修改:可理解性、可维修性、灵活性、可测试性; 产品转移:可移植性、可再用性、互运行性。
6.2.2 Boehm 质量模型
Boehm 软件质量模型通过一系列属性的指标来量化软件质量,采用层级的 质量模型结构,包括高层属性、中层属性和原始属性。
高层属性:As-is Utility 常规使用 Maintainability 可维护性
Portability 可移植性 中层属性包含了 7 个质量要素:
可移植性、可靠性、效率、人类工程学(易用性)、可测试性、 可理解性、可修改性
6.2.3 ISO 9126 质量模型
ISO 9126 定义了软件的 6 个质量特征: 1.功能性(Functionality):当软件在指定条件下使用时,软件产品提供满
足明确和隐含需要的功能的能力; 2.可靠性(Reliability):在指定条件下使用时,软件产品维持规定的性能级
别的能力; 3.易用性(Usability):在指定条件下使用时,软件产品被理解、学习、使
用和吸引用户的能力;
4.效率(Efficiency):在规定条件下,相对于所有资源的数量,软件产品可 提供适当性能的能力;
5.可维护性(Maintainability):软件产品可被修改的能力。修改可能包括 纠正性、适应性、预防性、完善性等方面的修改。
6.可移植性(Portability):软件产品从一种环境迁移到另一种环境的能力。
