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

文章目录

• Quality 的定义
• • End user 角度
  • Developer 角度
  • 实现 quality 的代价
• 质量管理过程（quality management process）
• • 质量保证（quality assurance）
  • • Verification
    • Validation
    • 不同的测试层次
    • 质量标准（quality standards）
    • • 产品标准（Product Standard）
      • 流程标准（Process Standard）
      • 例：文件标准（Document standards）
      • 使用 standards 的好处
      • 使用 standards 的问题
      • 软件标准及系统（Software Standards and Systems）
      • • ISO 9000 family quality management
        • 软件能力成熟度模型（Capability Maturity Model）
  • 质量计划（quality planning）
  • • 软件质量计划（Software Quality Plan）SQP
    • • 模版（template）
    • 软件质量属性（Software Quality Attributes）
  • 质量管理（quality control）
  • • 审查（Review）
    • • 技术审查（Technical Reviews）
      • • Advantages
        • disadvantages
        • 非正式审查（informal reviews）
        • • Checklist
        • 正式审查（formal reviews）
        • 走查（walkthrough）
        • 代码校验（code inspection）
        • 审计（audits）
      • 商业审查（Business Reviews ）
      • 管理审查（Management Reviews）

Quality 的定义

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

Developer 角度

• 大多数质量保证活动的成本都太高了——不使用资源所节省的成本要大于修复故障所产生的成本
  • 例如，与其对需求规范文档进行正式的评审，不如构建系统，请求客户用户提供反馈，并从那里纠正任何错误。
  • 或者，可以简单地发布系统并在用户报告错误时纠正错误。
    

    质量保证（quality assurance）

    • 建立高质量软件的组织程序和标准的框架
      
      
      • 质量保证过程主要涉及确定或选择质量标准
      • 一个标准可以简单地定义为一套规则，
      • 质量标准在质量管理过程中发挥重要作用
      
    • 文档是软件的有形表现形式
    • 文档流程标准： 文档应该如何开发、验证和维护
    • 文档标准：文档标识、结构、呈现、更改高亮显示等。
    • 文档交换标准：
      • 如何在不同的文档系统之间存储和交换文档
      • XML是一种新兴的文档交换标准，在未来将得到广泛的支持

    使用 standards 的好处

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

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

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

    
    • 描述一个有效的软件开发过程的关键要素。
    • 描述软件公司从一个特别的、不成熟的过程过渡到一个成熟的开发过程的方法
    • 根据组织遵循的过程，组织被划分为1-5级
      
    

  模版（template）

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

  质量管理（quality control）

  

技术审查（Technical Reviews）

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

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

disadvantages

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

Checklist

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

走查（walkthrough）

• （Walkthroughs）：根据已经提出的测试用例，用人工的方法来运行程序，即 让人代替机器沿着程序的逻辑“走”一遍；
  
  • 这些与正式的评审非常相似，只不过重点是在代码上

  审计（audits）

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

  管理审查（Management Reviews）

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

  来源：暖仔会飞