软件质量-概念整理

考试形式

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

重要的概念整理

1. KLOC：千行代码，是一个计算机程序有多大或者需要多少人来完成其编码工作的一个传统的度量标准。这些代码通常是源代码。
2. Defects pre KLOC：千行代码缺陷率
3. 软件度量：对软件开发项目、过程及其产品进行定量化的过程，目的在于对其加以理解、预测、评估、控制和改善。

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

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

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

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

CMM对质量的定义：一个系统、组件或过程符合特定需求的程度，符合客户或用户的要求或期望的程度。

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

4. 三个方面：产品、过程、资源。

5. 二个层次：内部属性（容易度量），外部属性（难以度量，但由内部属性决定）

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

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

7. 项目管理核心：PDCA图

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

8. 项目计划三个基础：目标、资源、约束。

9. 项目计划三个前提：生命周期、wbs（Work Breakdown Structure 工作分解结构）、估计

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

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

12. 估计方法：加权平均法，Delphi法，功能点。

13. 加权平均法：可以用于估计软件项目的规模、工作量和成本等。

    1. 按照最佳的、可能的、悲观的三种情况给出估计值，记作：a、m、b
    2. 期望值 = (a + 4 * m + b) / 6
    3. 期望值就是最终的估计值

14. Delphi法：

    1. 建立估计小组：专家、工作人员
    2. 开会介绍内容，评判约束达成一致
    3. 专家打分
    4. 统计结果，计算差别 = max((最大值 - 平均值), (平均值 - 最小值)) / 平均值
    5. 差别大于接受水平x%，要重新打分，直到差别在接受水平范围内

15. 功能点

    

    1. ILF：内部逻辑文件，在被度量应用内部维护的、用户可识别的、逻辑相关的数据组或控制信息组。
    2. EIF：外部接口文件，由应用程序引用的用户可识别的、逻辑相关数据或控制信息。

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

    一个应用的外部接口文件是其他应用程序的内部逻辑文件

    ILF和EIF的主要区别：

    • ILF在被度量的应用内维护

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

    3. EI：外部输入，数据由外向内跨越边界的基本处理过程，数据可能来自于数据输入屏幕、电子输入或其他应用程序。
    4. EO：外部输出，导出的数据由内向外跨越边界的基本处理过程，数据发送给其他应用的报表或输出文件。
    5. EQ：外部查询，包括输入和输出的基本处理过程，输入和输出导致一个或多个内部逻辑文件和外部接口文件的数据检索。该信息被发送出应用程序边界。输入过程不会更新任何内部逻辑文件。

    EI、EO、EQ

    • EI：主要目的维护一个或多个ILF
    • EQ、EO：呈现信息给用户
    • EO：包含更多处理逻辑
    • 含数学公式或计算、创建衍生数据，维护一个或多个ILF，改变应用行为

    6. 在逻辑文件中，包含DET和RET两种元素类型：
       • DET：数据元素类型。用户可知的，不重复的数据域。取值大致对应逻辑文件的用户可见数据项个数。
       • RET：记录元素类型。用户可以理解的数据元素子集。取值大致对应逻辑文件的实体个数。
    7. 在基本过程中，包含FTR和DET两种元素类型：
       • FTR：文件类型引用。维护/引用的逻辑文件。取值大致对应基本过程访问的逻辑文件数。
       • DET：数据元素类型。用户可知的，不重复的数据域。取值大致对应基本过程访问的用户可见字段数。

    参考：【项目管理】如何应用功能点估算项目规模 - 知乎 (zhihu.com)

    8. 计算调整因子VAF（UAFP调整前，VAF调整因子，AFP调整后）
       • AFP = UAFP * (0.65 + 0.01 * VAF)
       • 调整后 = 调整前 * (0.65 + 0.01 * 调整因子)

16. 度量模型

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

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

    1. 信息层（实例层）（information layer）：信息是由我们希望描述的数据组成，这些数据通常是一些用户数据（user data），主要职责是描述信息领域中详细信息。

    2. 模型层（model layer）：模型层由元数据组成，元数据是描述信息层的数据，元数据的集合被称作为模型。模型层的主要职责是为描述信息层而定义的一种“抽象语言”（即没有具体语法或符号的语言）。信息层的数据，即用户数据，是模型层的一个实例。

    3. 元模型层（metamodel layer）：元模型层是由元一元数据组成，元一元数据定义了元数据的结构和语义，元一元数据的集合被称作为元模型。元模型层的主要职责是为了描述模型层而定义的一种“抽象语言”，是对模型层的进一步抽象。也就是说，模型层描述的内容通常要比元模型层描述的内容丰富、详细。一个模型是元模型的一个实例。数据词典中的元数据是对数据模型的描述。

    4. 元元模型层（meta-metamodel layer）：元元模型层是由元元数据的结构和语义的描述组成，这层的主要职责是为了描述元模型而定义的一种“抽象语言”。元元模型的定义要比元模型更加抽象、简洁。一个元元模型可以定义多个元模型，而每个元模型也可以与多个元模型相关联。通常所说的相关联的元模型和元元模型共享同一个设计原理和构造，这也不是绝对的准则。每一层都需要维护自己设计的完整性。一个元模型是元元模型的一个实例。

18. 产品质量

    1. 功能正确性、可维护性、效率、可移植性、可用性、可靠性
    2. 可用性：软件可持续使用在特定间隔的百分比：服务时间/观察间隔
    3. 可靠性：平均间隔故障时间：服务时间/发生故障次数

19. 技术有效性

    1. 技术适合性：技术满足所有的已分配的需求或需要额外的技术？
    2. 技术易变性：新的技术是否太多的变更而造成风险？

计算（度量方法）

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

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

• 系统的输入是：

  • 员工定期信息（员工ID，基本工资，等级，部门等）
  • 考勤细节及月信息（如专门的纳税扣除额和收入等）

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

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

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

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

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

  • Employee Name and static details file
  • Department
  • Grade

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

度量构造实例：生产率

• 决策制定者需要标识出一个期望的软件生产率水平作为制定项目计划的基础
• 可测量概念是：过去项目的生产率可以作为未来项目的有效估计，而且生产率与所花的工作量和要生产的软件数量相关。因此，工作量和代码是需要关注的可测量的软件实体。

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