软件流程和管理（八）：质量管理

目录

1. 质量管理的基本原理

1.1 什么是质量？

1.2 什么是软件质量？

1.3 质量的成本

2. 质量管理流程

2.1 Quality assurance 质量保证

2.1.1 Verification vs Validation 核查与验证

2.1.2 Quality Assurance 质量保证标准

2.2 Quality Planning 质量规划

2.2.1 Software Quality Plan SQP - 模板

2.2.2 Software Quality Attributes 软件质量属性

2.3 Quality Control and Monitoring 质量控制和监测

2.3.1 Reviews

2.3.2 Technical Reviews 技术评审

2.3.2 Business Reviews 业务评审

2.3.3 Management Reviews 管理评审

---

1. 质量管理的基本原理

1.1 什么是质量？

质量不是一种行为，而是一种习惯 - 亚里士多德

• 证据表明，我们不能简单地在事后修复我们的软件，并在建立系统后加入质量属性。
• 质量必须从一开始就被建立在软件中。
• 在本专题中，你将学习如何通过一系列的 Quality Management 质量管理活动将质量纳入软件中。

1.2 什么是软件质量？

我们从两个广泛的角度来定义质量：

End-user’s Perspective 终端用户的角度

通常，终端用户通过与产品的交互来判断产品的质量。对于用户来说，如果一个系统适合于目的，可靠，性能合理，易于学习和使用，并帮助用户实现他们的目标，那么这个系统就是有质量的。有时，如果功能很难学习，但非常重要，值得学习，那么用户仍然会判断该系统具有高质量。这些被称为 external quality characteristics 外部质量特征，因为它们通常与系统的外部行为相关联。

Developer’s Perspective 开发者的观点
开发者的观点通常还包括系统的故障数量，修改系统的难易程度，测试系统的难易程度，理解系统设计的难易程度，组件的可重用性，与需求的一致性，资源的使用，以及性能。 这些主要是 internal quality characteristics 内部质量特性，因为它们涉及到系统内部结构的质量。

1.3 质量的成本

有些人声称：

大多数质量保证活动的成本太高了——不使用资源所节省的费用大于修复故障所产生的费用。

• 例如，与其对需求规格文件进行正式审查，不如建立系统，向客户/用户征求反馈意见，并从中纠正任何错误。
• 或者，我们可以简单地发布系统，并在用户报告时纠正错误。

经验性研究反驳了上述说法。

• 在这个领域有很多研究

这张图展示了在不同阶段想要修复 一个 bug 所需的成本呢，在 requirement 阶段就解决这个 bug，造成的成本较低，越往后拖，投入成本就越高

2. 质量管理流程

Quality assurance 质量保证

建立一个组织程序和标准的框架，以实现高质量的软件。 The establishment of a framework of organizational procedures and standards that lead to high-quality software

Quality planning 质量规划

从框架中选择适当的程序和标准，为具体项目所采用。 The selection of appropriate procedures and standards from the framework, adopted for the specific project

Quality control 质量控制

确保软件开发团队遵循项目的质量程序和标准。 Ensuring that the software development team has followed the project quality procedures and standards

2.1 Quality assurance 质量保证

2.1.1 Verification vs Validation 核查与验证

核查和验证（V&V）是质量保证的重要方面。

核查 Verification

• Verification 是一种确保正确构建产品的尝试，在某种意义上，活动的输出产品满足在以前的活动中强加给它们的规范。
• Verification通常涉及两(组)比较：req. spec. v.s design / design v.s code；这是一个内部开发人员活动。
• Verification是确保您 building the system right 以正确的方式构建系统。

验证 Validation

• 验证是为了确保建立正确的产品 —— 即产品满足其特定的预期目的。
• 验证包括回到利益相关者那里，检查产品是否符合他们的要求；这通常涉及到外部的东西/人。
• 验证是确保你正在 building the right system 建立正确的系统（以满足利益相关者的需求）。

不同的测试层次

• unit test：对一段代码进行功能性测试
• integration test：一段代码是否能与其他代码协调工作的很好
• validation test：是否建立了正确的系统（以正确的方式满足了 stakeholders 的需求）

2.1.2 Quality Assurance 质量保证标准

质量保证流程主要涉及定义或选择 quality standards 质量标准

• 标准可以简单地定义为 set of rules for ensuring quality 一套确保质量的规则
• 标准在质量管理过程中发挥着重要作用

有两种类型的标准：

Product standards 产品标准

这些标准适用于正在开发的产品

• 设计评审表格模板 Design review form template
• 需求文档结构 Requirements document structure
• 文档标准 Documentation standards
• 遵循的编码标准 Coding standards to follow
• 项目计划格式 Project plan format
• 从模板更改请求 Change request from template

Process standards 流程标准

这些标准定义了软件开发流程中应遵循的流程

• 设计评审 Design review conduct
• 设计验证过程 Design validation process
• 版本发布过程 Version release process
• 项目计划批准过程 Project plan approval process
• 变更控制过程 Change control process
• 测试记录过程 Test recording process

文件标准（Document standards）

文件标准中包含了 文件自身的标准还有文件的流程标准，当然还有一些其他的标准：文件交换标准。

在整个产品的开发过程中 document 作为一种经常产出的 product 形式，肯定是具有其 product standards 的，但同时 document 的种类很多，而且通常在很多地方使用，因此对于所有的 document 应该有一个流程标准。

为什么文件标准很重要？

• 文档是软件的有形表现形式

文档流程标准

• 应该如何开发、验证和维护文档

文档标准

• 关注文件的识别、结构、表现形式、变化突出等。

文档互换标准

• 文件如何在不同的文件系统之间进行存储和互换
• XML是一种新兴的文件交换标准，将在未来得到广泛支持。

标准的优点

• 提供一个框架，可以围绕这个框架实施质量保证过程 Provide a framework around which the quality assurance process may be implemented
• 提供最佳，或至少是最合适的实践的封装 Provide encapsulation of best, or at least most appropriate, practice
• 客户在选择软件供应商时，有时需要一个特定的质量标准/水平 Customers sometimes require a particular quality standard/level when choosing a software vendor

标准存在的问题

• 不被软件工程师认为是相关的和最新的 Not seen as relevant and up-to-date by software engineers
• 涉及到太多的官僚主义的表格填写 Involve too much bureaucratic form filling
• 没有软件工具的支持，因此需要繁琐的手工工作来维护标准 Unsupported by software tools so tedious manual work is involved to maintain standards

标准不应该被避免，但应该根据需要进行调整!

今天存在许多与软件质量有关的标准和系统

ISO 9000 family quality management and 能力成熟度模型

• 软件质量管理体系标准
• 能力成熟度模型

一些软件标准和体系的例子

•  ISO 9000系列质量管理 ISO 9000 family Quality management
  • ISO 9000:2015 质量管理体系 ISO 9000:2015 Quality management systems
  • ISO 9001:2015 质量管理体系 ISO 9001:2015 Quality management systems
  • ISO 9004:2018 质量管理 ISO 9004:2018 Quality management

能力成熟度模型

用这个模型可以帮助公司进行自我评定，来判断他们的流程目前属于一个什么样的成熟度

• 由卡内基梅隆大学的软件工程研究所（SEI）开发。
• 卡内基梅隆大学的软件工程研究所（SEI）开发的
• 描述了一个有效的软件开发过程的关键因素
• 描述了软件公司从一个临时的、不成熟的过程转变为一个成熟的开发过程的方法。
• 根据组织所遵循的流程，将其划分为1-5级。

• Level 1 Initial：不可预测，控制不良，反应迟钝流程
• Level 2 Managed：为项目描述的过程，通常是反应性的。
• Level 3 Defined：过程为组织特征，是主动的。(项目根据组织的标准调整它们的过程)
• Level 4 Quantitatively Managed：测量和控制的过程
• Level 5 Optimizing：专注于流程改进

Initial

Repeatable 可重复的

• Software configuration management 软件配置管理
• Software quality assurance 软件质量保障
• Software subcontract management 软件分包合同管理
• Software project tracking and oversight 软件项目跟踪和监督
• Software project planning 软件项目规划
• Requirements management 需求管理

Defined 定义

• Peer reviews 同行审查
• Intergroup coordination 组间协调
• Software product engineering 软件产品工程
• Integrated software management 综合软件管理
• Training programme 培训计划
• Organization process definition 组织流程定义
• Organization processfocus 组织过程的重点

Managed

• Software quality management 软件质量管理
• Quantitative process management 量化过程管理

Optimizing

• Process change management 流程变革管理
• Technology change management 技术变革管理
• Defect prevention 缺陷预防

2.2 Quality Planning 质量规划

• 选择那些适合于特定组织和项目的标准和系统的过程 .
• 规划过程的结果如下：
  • 软件质量计划 Software Quality Plan（SQP），有时也称为软件质量保证计划Software Quality Assurance Plan（SQAP）。

2.2.1 Software Quality Plan SQP - 模板

Software Quality Assurance Plan 软件质量保障计划

Product Overview 产品概述

• 对产品、预期市场和质量期望的描述 A description of the product, intended market, and quality expectations

Product Plan 产品计划

• 关键的发布日期和责任 - 可以指向时间表 The critical release dates and responsibilities – could point to the schedule

Quality Goals 质量目标

• 产品的质量目标和计划，包括关键产品质量属性的识别和论证。 The quality goals and plans for the product, including identification and justification of critical product quality attributes

Process Description 流程描述

• 应该用于产品开发和管理的质量保证过程（审查、审计等）。 The quality assurance processes that should be used for product development and management (reviews, audits etc)

Document and Coding Standards 文件和编码标准

• 文件和编码标准的标准 Standards for the documents and coding standards

Risks and Risk Management 风险和风险管理

• 可能影响产品质量的主要风险以及应对这些风险的行动（可提供与风险管理计划中适当风险的联系） The key risks that might affect product quality and the actions to address these risks (could provide a link to appropriate risks in the Risk Management Plan)

2.2.2 Software Quality Attributes 软件质量属性

安全性         可理解性         可移植性
安全性         测试性             可用性
可靠性         适应性             可重用性
复原力         模块化             效率
稳健性         复杂性             可学习性

• 一些质量属性只对开发者重要，而其他属性对最终用户重要。
• 任何系统都不可能对所有属性都进行优化--必须进行权衡以选择最重要的属性。

2.3 Quality Control and Monitoring 质量控制和监测

涉及监测软件开发过程，以确保SQP中规定的质量保证程序和标准得到遵守。

2.3.1 Reviews

• Review 审查是用于验证和确认的一种常见技术.
• 对开发过程中产生的工件进行审查，作为发现问题的一种方式，以寻求早期改进的方法。
• 三种常见的审查类型。
  • Technical Reviews 技术评审
  • Business Reviews 业务评审
  • Management Reviews 管理评审

2.3.2 Technical Reviews 技术评审

• 对工件的审查是由开发团队的 peers 同行 进行的，但作者也参与其中。
• 其目的是发现工件中的问题，并寻求改善工件的方法。
• 被认为是一种质量保证的“软”方法——也就是说，没有任何东西被执行。
  • 一些开发者对评审持怀疑态度——然而，经验证据表明，这种怀疑是没有道理的。

技术审查的优点

技术审查的劣势

• 可能耗费时间和资源
• 应仔细计划和执行，以获得预期的结果

技术审查的类型

• Informal Reviews 非正式审查
• Formal Reviews 正式审查
• Walk throughs 演练
• Code inspections 代码检查
• Audits 审计

Informal Reviews 非正式审查

• 一个简单的桌面检查或与同事的休闲会议，目的是提高文件的质量。
• 没有正式的准则或程序可循
• 非正式审查的有效性大大低于正式审查，因为在一个小组中缺乏多样性。
• 核对表（checklist）是可以帮助提高审查效率的工具。
• 核对表是一份审查员必须回答的关于工件的问题清单，然而，这些问题是关于该类型工件的通用问题。
• 比正式审查更省时省力

Formal Reviews 正式的审查

• 与多个利益相关者，如开发人员、测试人员、客户的会议。
  • 小组方式的好处是可以带出不同的观点
• 会议应遵守以下限制
  • 评审小组应该由3-5名成员组成，并经过精心挑选
  • 会议时间不应超过90分钟
  • 以下是关键角色：
    • 评审组长：负责组织评审工作
    • 作者：至少有一名作者应出席
    • 评审员：至少有两到三个非作者的利益相关者
    • 记录员：负责记录所有重要的评审意见
• 评审会议可以建议以下一种情况：
  • 接受，不作进一步修改
  • 接受并提出修改意见
  • 拒绝该工件 - 这需要在修改后重新审查

Walk throughs 走查

Walkthroughs：根据已经提出的测试用例，用人工的方法来运行程序，即 让人代替机器沿着程序的逻辑“走”一遍；

• walkthrough 可以针对代码或文档。
• 这是一个评审过程，过程中有作者(程序员或设计师)领导一组评审人员。
• 以下是 walkthrough 与正式评审（formal review）的主要区别：
  • 主持人（moderator），领导评审工作的是被评审工件的作者。
  • 评审人员不需要预备工作（preparation），
  • 当发现缺陷或不一致时，讨论可能的解决方案

Code inspections 代码检查

• 这与正式审查非常相似，但重点是在代码上。

Audits​​​​​​​ 审核

2.3.2 Business Reviews 业务评审

• 业务评审的目标是确保IT解决方案提供项目范围和需求文档中指定的功能
• 业务评审可以包括所有项目的可交付成果，以确保:
  • 任务按照预期完成 It is complete
  • 提供了进入下一个阶段或过程所需的信息 Provides the information needed to move to the next phase or process
  • 符合标准 Meets the standards

2.3.3 Management Reviews 管理评审

• 将项目的实际进度与基线项目计划进行比较 Compares the project’s actual progress against a baseline project plan
• 项目经理负责展示项目进度，并提供当前状态的清晰蓝图 Project Manager is responsible for presenting the project progress and providing a clear picture of the current status
• 需要解决的问题——例如，根据需要重新分配资源，在需要时改变项目进程 Issues need to be resolved – e.g. resources reallocated as needed, change to the project course if needed
• 可能涉及到审查项目是否符合范围、进度、预算和质量目标 May involve reviewing if the project meets the scope, schedule, budget and quality objectives