软件质量-知识点整理

考试形式

概念题
- 重要的概念
- 英文缩写的中文含义
论述题
- 重要概念的理解（举例说明）
综合题
- 计算（度量方法）
- 构造（度量模型）
- 具体步骤

内容

软件度量的内容
软件度量的方法
软件度量的模型

软件项目任务

需求 -> ?? -> 产品
计划，执行，跟踪评估
按时交付
预算之内
质量合格
完成计划内的事项

软件项目管理问题

我们项目的开发生产率是多少（KLOC/人月）？

KLOC(千行代码)是一个计算机程序有多大或者需要多少人来完成其编码工作的一个传统的度量标准。这些代码通常是源代码。

我们的开发成本是多少（元/KLOC）？
我们的开发质量如何？
Defects per KLOC 千行代码缺陷率
开发周期
客户满意度
投资回报

定量分析是重要的

工程化的软件开发需要定量、科学的描述（实施前、实施过程中、实施完成后）
定量、科学的描述有助于获取软件项目以及所开发的软件的某种可视性，促进软件项目的管理
定量的信息描述必须在软件项目开发过程中采集

什么是软件度量

软件度量（software measurement）：对软件开发项目、过程及其产品进行定量化的过程，目的在于对其加以理解、预测、评估、控制和改善。

理解：获得对过程、产品、资源等的理解，是评估、预测和改进活动的基础

预测：通过建立预测模型，进行估算和计划

评估：对产品的质量、过程改进的效果等进行评估

改进：根据得到的量化信息，确定潜在的改进机会

CMM对质量的定义是：

一个系统、组件或过程符合特定需求的程度
一个系统、组件或过程符合客户或用户的要求或期望的程度

软件质量是许多质量属性的综合体现，各种质量属性反映了软件质量的方方面面。人们通过改善软件的各种质量属性，从而提高软件的整体质量。

软件度量的内容

三个方面二个层次

三个方面
- 产品：过程的活动中产生的成果，如：程序和文档等
- 过程：软件相关活动的集合
- 资源：过程需要的实体，如：各种资源，如人员、费用等
二个层次
- 内部属性
  - 软件产品，过程和资源本身所具有属性，如：软件产品的复杂度、程序长度等
  - 易于度量
- 外部属性
  - 软件产品，过程和资源与外部环境（用户、管理人员等）间的关系，如：成本、效益、可靠性、可维护性等
  - 难以度量，但由内部属性所决定

	产品	过程	资源	关注对象	难易程度
内部属性	代码长度、程序功能、重用性、模块的耦合和内聚度	工作量、计划和进度	人、软硬件环境、方法、经验	软件开发人员和项目管理人员	相对比较容易
外部属性	可靠性、可理解性、质量、可维护性、可移植性	成本、可控制性	成本、时间	用户和软件项目管理人员	相对比较困难，但由内部属性决定

质量属性场景

质量属性场景由以下六部分组成：

刺激源（Stimulus Source）：某个生成该刺激的实体；
刺激（Stimulus）：刺激达到系统时需要考虑的条件；
环境（Environment）：该刺激在某些条件下发生；
制品（Artifact）：被刺激的对象，可以是系统或系统的一部分
响应（Response）：在刺激达到后采取的行动；
响应度量（Response Measure）：以某种方式对其进行度量，对需求进行测试。

质量属性场景杨例

可修改性场景：

刺激源：开发人员
刺激：希望改变用户界面
环境：设计时
制品：代码
响应：修改不产生副作用
响应度量：在3小时内

安全性场景：

刺激源：
刺激：
环境：
制品：
响应：
响应度量：

软件度量的方法

项目度量：规模度量、成本度量、顾客满意度度量
产品度量（质量度量）
过程度量：成熟度度量、管理度量、生命周期度量

项目管理

项目管理核心：PDCA图
项目计划三个基础：目标、资源、约束
项目计划三个前提：生命周期、wbs（Work Breakdown Struceure 工作分解结构）、估计

PDCA

项目管理的核心——PDCA

P（Plan）：计划
D（Do）：执行计划
C（Check）：检查，从结果中学习
A（Action）：正式行动，采取措施

生命周期

瀑布、原型（形式）、增量、进化
统一软件开发过程：初始、细化、构造、移交

工作分解结构（WBS）

工作分解结构（WBS）以层次结构组织项目活动元素，它是根据自顶向下的方法，按照模块化的思想将项目分解成易于管理的工作包。

工作包是可以分别分配、执行和跟踪的单独工作单元

在WBS中，每个任务应赋予一个唯一的标志符
WBS包括一个任务字典，它描述了每个任务的工作
将WBS作为基本框架，对项目所作的工作进行计划、组织和控制

**WBS是估计、计划、跟踪和监控的主要依据。**构造好WBS，将会给项目的计划和实施带来极大的便利。

总体估计实例

项目工期估计，假定某个项目包含四个业务子系统，即“前期管理”、“投资计划管理”、“基建统计”、“专题图管理”。

序号系统功能总数重用数

1 前期管理 17 0

2 投资计划 53 22

3 基建统计 33 25

4 专题图 19 0

合计 122 47

新功能平均生产率：每个功能5/人日122 - 47 = 75个新功能

复用功能平均生产率：每个功能1/人日47个复用功能

全部功能工作量？75 * 5 + 47 * 1 = 422/人日

文档管理室功能工作量的40%

最终工作量？422 * 1.4 = 590.8/人日

每个月25个工作日，平均5个开发人员

总体开发时间？422 / 125 = 3.376月

加上实施和项目管理？(3.376 * 1.4 = 4.7264) 月

序号	系统	功能总数	重用数
1	前期管理	17	0
2	投资计划	53	22
3	基建统计	33	25
4	专题图	19	0
合计		122	47

估计方法

加权平均法
Delphi法
功能点（Function Point Method）

加权平均（1:4:1）

Pert Sizing是一种加权平均法，可以用于估计软件项目的规模、工作量和成本等

在估计每一项任务时，首先按最佳的、可能的、悲观的三种情况给出估计值，记作：a、m、b

然后用一下公式计算期望值，期望值就是最终的估计值：

期望值 = (a + 4 * m + b) / 6

Delphi法

建立估计小组：专家、工作人员
开会介绍内容，评判约束达成一致
专家打分
统计结果，计算差别：

差别 = max((最大值 - 平均值), (平均值 - 最小值)) / 平均值
差别大于接受水平x%，要重新打分，直到差别在接受水平范围内

功能点

功能点function point（FP）：UAFP调整前，VAF调整因子，AFP调整后
未调整功能点：EI，EO，EQ，ILF，EIF
工作量：功能点/平均生产率

功能点度量实例

度量数据功能
- 数据功能分类：ILF，EIF
- 识别数据功能的类型：DET，RET
- 确定复杂性和功能规模
度量事物功能
- 基本过程分类：EI，EO，EQ
- 识别事务功能的类型：DET，FTR
- 确定复杂性和功能规模

内部逻辑文件（ILF）（Inside）

在被度量应用内部维护的、用户可识别的、逻辑相关的数据组或控制信息组
主要目的：保存由被度量应用的基本过程维护的数据
在FP中，文件和表的含义是一样的

外部接口文件（EIF）（External）

由应用程序引用的用户可识别的、逻辑相关数据或控制信息
主要目的：保存由被度量应用的基本过程引用的数据
数据完全驻留在应用程序外部，由其他应用程序所维护
一个应用的外部接口文件是其他应用程序的内部逻辑文件

文件：不是物理文件或表，而是逻辑相关的数据组

基本过程：事务功能（添加员工信息（添加家属信息，添加电话））

维护：创建、增加、修改、删除、倒入、更新数据

用户可识别：数据或事务被用户、软件开发者共同认可和理解

控制信息：报表定义信息（报表名称、显示字段、数据排序方式）

ILF和EIF的主要区别：

ILF在被度量的应用内维护

EIF由其他应用维护，但被度量应用会引用其数据

外部输入（EI）

数据由外向内跨越边界的基本处理过程

数据可能来自于数据输入屏幕、电子输入或其他应用程序
数据可以是控制信息或业务信息。如果数据是业务信息，它用于维护一个或多个内部逻辑文件。如果数据是控制信息，它不必更新内部逻辑文件

外部输出（EO）

导出的数据由内向外跨越边界的基本处理过程

数据发送给其他应用的报表或输出文件。这些报表和输出文件由一个或多个内部逻辑文件和外部接口文件所创建

外部查询（EQ）

包括输入和输出的基本处理过程
输入和输出导致一个或多个内部逻辑文件和外部接口文件的数据检索。该信息被发送出应用程序边界。输入过程不会更新任何内部逻辑文件

EI（外部输入）表

FTR：File type reference（文件类型引用）

数据元素：每个唯一的、用户可识别的、不重复的字段，算一个数据元素

ILF和EIF表

RET：Record element types（记录元素类型）

数据元素：唯一的用户可识别的不重复的字段

功能点度量

判断其中的RET和DET

DET：数据元素类型
数据功能中唯一的、用户可识别的、非重复属性
- 用户信息：员工编号、姓名、性别、所属部门、密码、学历、爱好
- 员工信息：员工编号、姓名、出生年月、所属部门、住址、入职时间、员工家属
RET：记录元素类型
一个数据功能中用户可识别的数据元素类型子集
每个数据功能是一个RET（每个数据功能有一个DET子集）
数据功能中包含一个以上RET的每个逻辑DET子集是一个RET

包含非键值属性的关联实体
实体子类型
非强制一对一关系的属性实体

判断其中的RET：实体子类型

实体子类型继承父实体类型的所有属性和关系，也有自己独有的属性和关系

每个子类型只有一个父实体

一个父实体有多个子类型

子类型不能作为一个独立的数据功能，和父实体一起共同构成一个数据功能

包含多个独有属性的子类型是该数据功能的一个RET

功能点实例

实例：ABC公司大约有3000名员工，要开发一个工资系统，需求大致如下：

要生产一个工资单，显示所有的工资计算。要打印收入和纳税扣除额。还要求将工资单显示在屏幕上。工资单的功能复杂度是“高”。另外，要产生7个报表，每个报表的复杂度是“低”。

系统的输入是：

员工定期信息（员工ID，基本工资，等级，部门等）

考勤细节及月信息（如专门的纳税扣除额和收入等）

以上两个输入都是屏幕输入，复杂度为“高”

另外，还要有一个所得税信息的输入，该输入的复杂度是“平均”

总共有20个查询，每个查询的复杂度是“低”

系统内要维护一个Employee Master File，该文件的复杂度是“高”

系统引用了三个目录/表：

Employee Name and static details file

Department

Grade

第一个目录的复杂度是“平均”，其他两个的复杂度是“低”

功能点 -> 实际工作量

复杂程度确定

低平均高如何确定？

计算调整因子VAF（UAFP调整前，VAF调整因子，AFP调整后）

AFP = UAFP * (0.65 + 0.01 * VAF)
调整后 = 调整前 * (0.65 + 0.01 * 调整因子)

规模偏离度x%（12%）

考虑功能点数=AFP * (1 + x%)

实际工作量

考虑功能点数/平均生产率（人天）
平均生产率 n FP/人天（0.9）

功能点度量

度量数据功能

数据功能分类：ILF（内部逻辑文件），EIF（外部接口文件）

文件：不是物理文件或表，而是逻辑相关的数据组
识别数据功能的类型：DET，RET
由DET和RET个数确定复杂性
由复杂性确定功能规模

识别数据功能

业务数据：核心数据，大部分
- 员工信息、工作信息
引用数据：维护业务数据，少部分
- 工资应用：税率，税务代码（不能相互代替）
代码数据：列表数据、转化数据，开发者识别
- 机场代码和机场名称（可相互代替）
- YQY，SYD

度量事务功能

EI：外部输入

处理来自外部数据或控制信息的过程
目的：维护一个或多个ILF或改变应用行为
删除、增加、更改

EO：外部输出

发送数据或控制信息到外部的过程，含处理逻辑
目的：通过处理逻辑呈现信息给用户
处理逻辑：含数学公式或计算、创建衍生数据，维护一个或多个ILF，改变应用行为（4项中1项）
报表：计算出的销售总额

EQ：外部查询

发送数据或控制信息到外部的过程
目的：通过对数据或控制信息的提取呈现信息给用户
不含数学公式或计算、不创建衍生数据，不维护ILF，不改变应用行为
根据用户ID查新用户的基本信息

EI、EO、EQ

EI：主要目的维护一个或多个ILF

EQ、EO：呈现信息给用户

EO：包含更多处理逻辑

含数学公式或计算、创建衍生数据，维护一个或多个ILF，改变应用行为

度量事务功能：处理逻辑

执行验证：登陆界面验证用户信息
执行数学公式、计算：总计数据
等价值转换：员工年龄：表->年龄范围组
特定规则对多组数据过滤和选择：查询，H系统查年龄20-30岁研发工作员工信息，员工数据组+工作数据组
分析条件判断适用情况：用户登录分析用户安全等级确定用户可操作的功能
更新一个或多个ILF：增加、删除、修改
引用一个或多个ILF：显示商品的人民币及美元价格，需引用汇率表中的汇率
提取数据或控制信息：查询用户信息，从用户信息表中提取数据
通过转换现有数据创建衍生数据：
- 衍生数据：数据不仅仅是从数据功能中直接提取，还是对现有数据进行操作的结果
- 注册号：系统自动将用户姓名和手机号连接成一个数据显示
改变应用行为：H系统自动通知合同到期的控制更改（每月一次改为每月两次）
向外部呈现信息：是EQ和EO的主要目的
接受进入应用的数据或控制信息：
- EI执行这样的处理逻辑：用户注册时，接受用户信息
对数据分类和排序

每一个事务功能执行一个或者多个处理逻辑

网站登录

验证、分析条件、引用一个或多个ILF、提取数据或控制信息、创建衍生数据、向外部呈现信息

度量事务功能

识别基本过程
确定唯一性

相同过程只能度量一次

包含相同DET

包含相同FTR

完成基本过程的处理逻辑相同

事务功能分类：EI、EO、EQ
判断其中的FTR和DET
由DET和FTR个数确定复杂性
由复杂性确定事务功能规模

基本过程分类：EI、EO、EQ
识别事务功能的类型：DET、FTR
确定复杂性和功能规模

FTR识别

FTR：文件类型引用 file type reference

被事务功能读取或维护的数据功能

数据功能

ILF：被事务功能读取或维护
EIF：被书屋功能读取

EQ的FTR：

其读取的ILF或EIF

EI和EO的FTR：

其读取的ILF或EIF
其维护的ILF

IFL既被维护有被读取只能算一个

FTR实例

需求1:L系统，添加用户信息，访问H系统“员工信息”判断是否本单位员工，非本单位不能使用L系统

添加用户信息
EI
ILF，EIF
FTR：2

需求2：L系统，查阅借阅单，显示图书ID，名称、作者、借阅用户ID、借阅用户名、用户电话、借阅日期、到期日期

查阅借阅单
EQ
ILF：图书信息、用户信息、借阅信息
FTR：3

度量模型

度量信息模型
度量过程模型

使度量发挥作用的两个关键因素：

信息驱动的度量方法：即测量的定义和实现时为了在设定优先级的基础上解决项目特殊的信息需要。随着项目的进展和信息需要的变化，应用的度量方法也应随之改变。信息驱动度量方法本质上讲必须理清三方面关系————需要什么样的信息，实际测量的是什么，测量如何定义并组合成可用的结果。

结构化可重复的度量过程：定义了项目的度量活动和相关的信息接口。度量过程必须是弹性的和可修改的，以支持现有的软件技术、管理过程和环境，同时支持特定应用领域特性。度量过程必须是迭代的，持续关注最关键问题的度量成果。度量过程必须贯穿于项目的整个生命周期，支持对进化的过程和产品属性的度量，如项目信息需要、相关的目标和问题及变更。

软件度量的概念模型

度量元模型

元模型
元对象机制（MOF，Meta-Object Facility）起源于统一建模语言（UML），对象管理机制（Object Management Group|OMG）需要一种元模型结构来定义UML。MOF被设计为4层次的结构。位于顶部的是元元模型层，即M3层。M3模型是MOF建立元模型（被称为M2模型）的语言。M2模型最明显的例子是UML元模型，该模型描述UML。M2模型描述M1层以及M1层的要素，例如UML模型。最后一层是M0层或数据层。它描述真实世界的物体。
模型是对现实的抽象，或者是对这个抽象的描述。
元模型（meta-model）当然也是模型，描述的对象是“模型中的元素、元素间关系以及表示法”，或者说它是一种语言，人们使用这种语言来描述模型。使用同样元模型的人，可以互相理解彼此所建立的模型。

元模型结构

典型的元模型结构可以描述为实例层、模型层、元模型层和元元模型层。

信息层（information layer）
- 信息是由我们希望描述的数据组成，这些数据通常是一些用户数据（user data），主要职责是描述信息领域中的详细信息。
模型层（model layer）
- 模型层是由元数据组成，元数据是描述信息层的数据，元数据的集合被称作为模型。
- 模型层的主要职责是为描述信息层而定义的一种“抽象语言”（即没有具体语法或符号的语言）。信息层的数据，即用户数据，是模型层的一个实例。
元模型层（metamodel layer）
- 元模型层是由元一元数据组成，元一元数据定义了元数据的结构和语义，元一元数据的集合被称作为元模型。元模型层的主要职责是为了描述模型层而定义的一种“抽象语言”，是对模型层的进一步抽象。也就是说，模型层描述的内容通常要比元模型层描述的内容丰富、详细。一个模型是元模型的一个实例。数据词典中的元数据是对数据模型的描述。
元元模型层（meta-metamodel layer）
- 元元模型层是由元元数据的结构和语义的描述组成，这层的主要职责是为了描述元模型而定义的一种“抽象语言”。元元模型的定义要比元模型更加抽象、简洁。一个元元模型可以定义多个元模型，而每个元模型也可以与多个元模型相关联。通常所说的相关联的元模型和元元模型共享同一个设计原理和构造，这也不是绝对的准则。每一层都需要维护自己设计的完整性。一个元模型是元元模型的一个实例。

信息分类

大部分项目信息需要可以分成通用的组，称作“信息分类”：

可测量概念

用于满足已定义的信息需要的数据可以通过测量许多不同的软件过程元素和产品特性来获得，这些过程元素和产品特性称为“软件实体”。

可测量概念是关于实体的概念，这些实体应被测量以满足信息需要。例如，生产率、里程碑完成情况、工作单元进展等等。

进度、进展（可测量概念）
- 里程碑完成：里程碑日期
- 关键路径性能：关键任务或交付日期
- 工作单元进展：已跟踪的XX、已测试的XX
- 增量式能力：已集成的构件、已集成的功能
资源、费用（可测量概念）
- 人员工作量：员工级别、经验水平
- 财务性能：成本、预算
- 环境和支持资源：需要额度数量、可用的数量
产品规模和稳定性（可测量概念）
- 物理规模和稳定性：数据库大小、组件数、接口数、代码行数
- 功能规模和稳定性：需求数、功能变更数、功能点数
产品质量（可测量概念）
- 功能正确性、可维护性、效率、可移植性、可用性、可靠性
- 可用性：软件可持续使用在特定间隔的百分比：服务时间/观察间隔
- 可靠性：平均间隔故障时间：服务时间/发生故障次数
过程性能（可测量概念）
- 过程符合性：基准成熟度判定、过程审计发现
- 过程效率：生产率、循环时间
- 过程有效性：已包括的缺陷、漏掉的缺陷、返工工作量、返工组件
技术有效性（可测量概念）
- 技术适合性：技术满足所有的已分配的需求或需要额外的技术？
- 技术易变性：新的技术是否太多的变更而造成风险？
客户满意度（可测量概念）
- 客户反馈：满意度评定、建立费用
- 客户支持：客户支持请求多快能得到处理？支持的请求数、支持时间

度量信息模型关系

在项目的计划和执行阶段，必须连续做出涵盖许多不同领域的技术和管理决策。决策制定者必须在综合考虑成本、进度、能力和质量的基础上做出权衡的决策。因而，决策制定者需要大量的信息来支持决策制定过程。
度量信息模型帮助定义项目决策者的信息需要并关注于度量计划活动，在计划活动中选择和制定最适合的软件测量来满足这些需要。
随着测量的实施和数据的采集，度量信息模型将度量数据和相关分析构造成结构化的信息产品。这些信息产品结合了度量结果以及已制定的决策准则并给项目决策制定者提出建议，以便他们可以采用替代的行动。

信息需要 -> 度量的过程

信息需要 -> 可测量概念 -> 度量构造 -> 度量规程 -> 度量计划

度量构造

信息需要如何转化为度量计划

制定度量计划时，首先要标识经理或工程师为了做出项目决策而指定的信息需要。
可测量概念将特定的活动和产品与信息需要关联起来。
每个给定的可测量概念课用多种方法实现。实现可测量概念的方法叫做“度量构造（measurement construct）”。度量构造严格地指定来要测量什么以及数据是如何整合成满足信息需要的结果的。
度量规程（measurement procedure）定义了采集和组织用来实例化一个度量构造所要求的数据的机制。
度量构造是将用来满足制定信息需要所要测量的对象联系起来的详细结构
实际测量的对象包括制定的软件过程和产品的属性，如规模、工作量和缺陷数
度量构造描述了相关软件属性是如果量化并转化成提供决策制定基础的指示器的
一个单一的度量构造可能包括三种测量类型或层次：基本测量、派生测量和指示器
度量计划人员必须制定要使用的度量构造的细节以及在度量计划中数据采集、分析和汇报的规程
度量构造设计的约合理，将要测量的软件属性与已标识的信息需要结合得就越好，项目经理也就越容易制定出可靠的客观的决策

度量构造可以用层次结构来组织
- 信息需要
- 指示器
- 基本测量
- 派生测量
- 属性

度量构造图：

生产率实例

度量构造实例：生产率

决策制定者需要标识出一个期望的软件生产率水平作为制定项目计划的基础

可测量概念是：过去项目的生产率可以作为未来项目的有效估计，而且生产率与所花的工作量和要生产的软件数量相关。因此，工作量和代码是需要关注的可测量的软件实体。

上图的指示器绘制了计划和实际产生的代码行的基本测量。另外，计算了软件规模增长了的派生测量。该指示器似乎表明项目比进度提前，但经过进一步调查后，发现一个组件的实际代码数要高于计划的代码数，因为遗漏的需求直到初始组件测试时才标出来。资源分配、进度、预算以及测试进度和计划都受到了这个无法预计的规模增长的影响。

信息需要

信息需要：为了做出正确的决策，度量用户（如经理或项目组成员）需要知道什么。
信息分类：信息需要的逻辑分组，为信息模型提供了结构。
可测量概念：通过定义实体及其可测量的属性来满足信息需要的概念。

度量过程模型

度量过程模型的主要活动：计划测量、执行度量、评价度量、建立和维持委托

计划度量

标识信息需要和设定优先级：
- 信息需要的标识
- 将信息需要映射到信息分类
- 设定信息需要的优先级
选择和制定测量：
- 刻画项目环境
- 定义可测量概念
- 选择可应用的测量
- 制定度量构造
集成到项目过程中：
- 确定度量的数据源
- 制定数据采集和存储规程、数据分析和汇报规程

执行度量

采集和处理数据
分析数据
提出建议

评价度量

评价测量
评价度量过程
更新经验库
标识和实施改进

建立和维持委托

获得组织的委托
定义度量的职责
提供资源
评审度量程序的进展

总结：

两个模型：

度量信息模型

度量过程模型

使度量发挥作用的两个关键因素：

信息驱动的度量方法

结构化可重复的度量过程

信息需要转化为度量计划的过程：

信息需要

可测量概念

度量构造

度量规程

度量计划

信息分类共七大类：

进度和进展

资源和费用

产品规模和稳定性

产品质量

过程性能

技术有效性

客户满意度

度量构造的组成：

信息需要节：信息需要、信息分类、可测量概念

指示器节：指示器、分析模型、决策准则

基本测量节：基本测量、度量方法、方法类型、刻度、刻度类型、度量单位

派生测量节：派生测量、度量函数

属性节：相关实体、属性

度量过程模型：

计划度量

执行度量

评价度量

建立和维持委托

计划度量：

标识信息需要和设定优先级：

信息需要的标识

将信息需要映射到信息分类

设定信息需要的优先级

选择和指定测量：
刻画项目环境

定义可测量概念

选择可应用的测量

指定度量构造

集成到项目过程中：
确定度量的数据源

指定数据采集和存储规程、数据分析和汇报规程

指定度量规程要考虑的事项：

聚集结构

数据采集、分析和汇报的频率

责任人

分析和汇报机制

计划和实际

配置管理

执行度量：

采集和处理数据

分析数据

提出建议

评价度量：

评价测量

评价度量过程

更新经验库

标识和实施改进

建立和维持委托：

获得组织的委托

定义度量的职责

提供资源

评审度量程序的进展