软件过程与建模学习之：Quality Management

Quality 的定义

End user 角度

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

Developer 角度

• 开发人员的视角通常还包括系统的故障数量、修改系统的难易性、测试系统的难易性、理解系统设计的难易性、组件的可重用性、对需求的符合性、资源使用和性能。这些主要是内部质量特征，因为它们与系统内部结构的质量有关。

实现 quality 的代价

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

  • 例如，与其对需求规范文档进行正式的评审，不如构建系统，请求客户用户提供反馈，并从那里纠正任何错误。
  • 或者，可以简单地发布系统并在用户报告错误时纠正错误。
    

• 这张图展示了在不同阶段想要 fix 一个 bug 所投入的 cost，在 requirement 阶段就解决这个 bug，造成的 cost 是不多的，越往后拖，投入成本就越高

质量管理过程（quality management process）

质量保证（quality assurance）

• 建立高质量软件的组织程序和标准的框架
  

Verification

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

Validation

• Validation 是为了确保构建了正确的产品，也就是说，产品满足了特定的预期目的。
• Validation 包括回到 stakeholders 那里检查产品是否满足他们的需求;这通常涉及到外部的事物/人。Validation 是确保您构建了正确的系统(以满足涉众的需求)。

不同的测试层次

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

质量标准（quality standards）

• 质量保证过程主要涉及确定或选择质量标准
• 一个标准可以简单地定义为一套规则，
• 质量标准在质量管理过程中发挥重要作用

产品标准（Product Standard）

• 设计评审表格模板
• 需求文档结构
• 文档标准
• 遵循的编码标准
• 项目计划格式
• 从模板更改请求

流程标准（Process Standard）

• 设计评审
• 设计验证过程
• 版本发布过程
• 项目计划批准过程
• 变更控制过程
• 测试记录过程

例：文件标准（Document standards）

• 文件标准中包含了 文件自身的标准还有文件的流程标准，当然还有一些其他的标准：文件交换标准
• 在整个产品的开发过程中 document 作为一种经常产出的 product 形式，肯定是具有其 product standards 的，但同时 document 的种类很多，而且通常在很多地方使用，因此对于所有的 document 应该有一个流程标准。
  
• 文档是软件的有形表现形式
• 文档流程标准： 文档应该如何开发、验证和维护
• 文档标准：文档标识、结构、呈现、更改高亮显示等。
• 文档交换标准：
  • 如何在不同的文档系统之间存储和交换文档
  • XML是一种新兴的文档交换标准，在未来将得到广泛的支持

使用 standards 的好处

• 提供一个围绕质量保证过程可能实现的框架。
• 提供最佳的，或至少是最适当的实践的封装。
• 客户在选择软件供应商时，有时需要特定的质量标准/级别

使用 standards 的问题

• 不被软件工程师认为是相关的和最新的
• 填写太多的官僚表格
• 软件工具不支持，维护标准需要繁琐的手工工作

标准不应该被回避，而应该根据需要量身定制!

软件标准及系统（Software Standards and Systems）

ISO 9000 family quality management

软件能力成熟度模型（Capability Maturity Model）

• 描述一个有效的软件开发过程的关键要素。
• 描述软件公司从一个特别的、不成熟的过程过渡到一个成熟的开发过程的方法
• 根据组织遵循的过程，组织被划分为1-5级
  
• 用这个模型可以帮助公司进行自我评定，来判断他们的流程目前属于一个什么样的成熟度

质量计划（quality planning）

• 从框架中选择适当的程序和标准，针对具体项目采用
• 选择适合于特定组织和项目的标准和系统的过程
  

软件质量计划（Software Quality Plan）SQP

• 作为一个 software quality planning process 的产出
  

模版（template）

软件质量属性（Software Quality Attributes）

• 有些质量属性只对开发人员有意义，
• 而另一些则对最终用户有意义—任何系统都不可能针对所有属性进行优化，必须权衡选择最重要的属性

质量管理（quality control）

• 监控软件开发过程，确保质量保证程序和SQP中规定的标准得到遵守

审查（Review）

• 评审是用于Verification 和 validation 的一种常见技术。
• 评审开发过程中产生的 artifacts，作为识别 problems 的一种方法，寻求尽早改进它们的方法
  

技术审查（Technical Reviews）

• 一般是通过同行来操作
• 同行帮助发现作品中的问题（代码问题或其他）
• 是否被认为是质量保证的“软”方法——也就是说，什么都不执行

Advantages

• 可以在任何软件artifact上执行，然而许多质量保证的“硬”方法，例如测试和度量，只能在可执行工件上执行。
• 尽早发现软件 artifacts 中的问题可以降低解决问题的成本。
• 研究表明，在项目中发现的所有编程错误中，大约有30-70%是通过源代码审查找到的，根据IBM的研究，这一比例高达80%。一些研究表明，评审技术发现了测试未能发现的几种类型的错误，反之亦然。
• 与测试相反，检查在源代码中发现实际的错误，测试仅仅表明程序中某处存在错误。通过测试检测到故障后，必须对其进行定位。
• 由于软件发布的内部压力，程序员在纠正测试中发现的错误时犯的错误比在评审阶段纠正错误时犯的错误更多

disadvantages

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

非正式审查（informal reviews）

• 简单的案头检查或与同事的非正式会议，目的是提高文件的质量。
• 没有遵循正式的指导方针或程序。
• 非正式审查的有效性远远低于正式审查，因为在团队中缺乏多样性。
• 检查清单 （checklist）是有助于提高审查有效性的工具。
• 检查表是审查员必须回答的关于工件的问题的列表，然而，这些问题是关于该类型工件的通用问题
• 比正式审查节省时间

Checklist

正式审查（formal reviews）

• 有多个涉众参加的会议，如开发人员、测试人员、客户小组的方法
  • 有提出不同观点的好处
• 会议应遵守以下约束条件：
  • 评审团队应由3-5名精心挑选的成员
  • 组成会议持续时间不应超过90分钟
  • 以下是关键角色：
    • 评审领导（review leader）：负责组织评审
    • 作者（Author）:应至少有一名作者出席
    • 评审人员（reviewers）:
    • 记录者（recorder）:负责记录所有重要的评审意见。
• 评审会议可以提出以下建议之一:
  • 不作任何更改并接受当前的工作成果。
  • 接受并一些提出的意见。
  • 拒绝当前工作的成果——这项工作拿去重做，然后再重新 re-review

走查（walkthrough）

• （Walkthroughs）：根据已经提出的测试用例，用人工的方法来运行程序，即 让人代替机器沿着程序的逻辑“走”一遍；
  
• walkthrough 可以针对代码或文档。
• 这是一个评审过程，过程中有作者(程序员或设计师)领导一组评审人员。
• 以下是 walkthrough 与正式评审（formal review）的主要区别：
  • 主持人（moderator），领导评审工作的是被评审工件的作者。
  • 评审人员不需要预备工作（preparation），
  • 当发现缺陷或不一致时，讨论可能的解决方案

代码校验（code inspection）

• 这些与正式的评审非常相似，只不过重点是在代码上

审计（audits）

• audits 是对流程（processes）和产品（products）的 reivew,以确定是否一个特定的产品或流程符合标准,
• 这是一种类型的 technical review，其中 被审核工件的作者完全不参与审核过程，所有其他角色都类似于 formal review
• audits 通常是一个完全外部负责 audits 的组织（第三方）
• 两种类型的 audits:
  • Product audits：确认产品符合的标准
  • Process audits：确保团队遵循 process

商业审查（Business Reviews ）

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

管理审查（Management Reviews）

• 将项目的实际进度与基线项目计划进行比较
• 项目经理负责展示项目进度，并提供当前状态的清晰蓝图。
• 需要解决的问题——例如，根据需要重新分配资源，在需要时改变项目进程。
• 可能涉及到审查项目是否符合范围、进度、预算和质量目标