EagleBear2002 的博客

这里必须根绝一切犹豫，这里任何怯懦都无济于事

软件质量管理-01-概述

发表于 更新于 分类于 ，
本文字数： 4.8k 阅读时长 ≈ 4 分钟

本文主要内容来自 SpriCoder 的博客，更换了更清晰的图片并根据新的课程设计做了补充和修正。

引入

  1. 软件在改变（定义？颠覆？）我们的世界
  2. 软件自身的变化：
    1. 规模
    2. 比例

软件危机：四大本质难题

《人月神话》软件的四大本质困难和挑战： 1. 不可见性：软件项目是一个逻辑实体 2. 复杂性：实体数量众多 3. 可变性 4. 一致性

四大本质难题之间的关系

  1. 除了不可见性以外，其他三个本质难题因项目而异。
  2. 四大本质难题互相促进。
  3. 本质难题变化带动软件方法（过程）演变。

几个注意点

  1. 软件开发四大本质难题永远存在，不可能彻底解决，在不同时期凸显程度有差异。
  2. 软件开发本质上是智力劳动，开发者心理方面的因素不可忽视

软件危机 vs. 软件工程

软件危机：是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。主要体现有：

  1. 软件开发费用和进度失控
  2. 软件可靠性差
  3. 生产出来的软件难以维护
  4. 用户对“已完成”系统不满意现象经常发现

软件工程：是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

软件工程的两大视角： 1. 管理视角——能否复制成功？ 2. 技术视角——是否可以将问题解决得更好？

软件项目管理

软件项目管理概念（重要）

管理的三大关键要素：目标、状态：是在接近目标还是在远离目标、纠偏。

大部分情况下，管理仅仅是试图复制其他地方（场景）的成功，但是这种复制一般不容易。

软件项目管理是为了降低/减少各种无谓的损耗来实现本该有的性能。

软件过程改进是为了达到更好的效能，其中质量/缺陷是首要目标或限制。

软件项目管理： 1. 典型的三大目标：成本、质量、工期； 2. 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程； 3. 估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理，等等

参考《PMBOK》项目管理知识体

质量实践和质量管理是不一样的： 1. 质量实践包括测试等等 2. 质量管理是对质量的管理，而不是实践，管理必须有上面所说的三个要素

软件项目管理的视角

成功是否可以复制？

软件项目管理的两种视角：

  1. 软件过程：软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。
  2. 生命周期模型：对软件过程的一种人为的划分

软件过程管理

广义软件过程

  1. 理论基石：软件产品和服务的质量，很大程度上取决于生产和维护该软件或者服务的过程的质量。
  2. 广义软件过程包括技术、人员以及狭义过程
  3. 广义软件过程的同义词：软件开发方法、软件开发过程
    1. 净室 Cleanroom 方法、极限编程方法、SCRUM 方法、Gate 方法；Cleanroom 工程过程和 CMM 管理过程互为补充；Cleanroom 比 CMM 更注重质量，更偏向于使用一些数学工具
    2. 而更一般的，敏捷软件过程/方法、轻量型过程/方法以及重型过程/方法等描述也是恰当的

生命周期模型

生命周期模型与软件过程区别和联系： 1. 生命周期模型是对一个软件开发过程的人为划分 2. 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分 3. 生命周期模型往往不包括技术实践

典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等

软件过程管理

  1. 管理对象是软件过程
  2. 管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效（performance）

  1. 左侧是软件开发部分，右侧是传统生产部分。

  2. 敏捷和计划驱动：敏捷中也需要计划驱动

  3. 管理视角的核心问题——能否复制成功？

软件过程管理与软件过程改进

两者意思接近： 1. 软件过程管理参考模型 CMM/CMMI, SPICE 等 2. 软件过程改进参考元模型 PDCA，IDEAL

软件过程改进模型

  1. 重点关注“过程质量”，强调“持续改进”
  2. 获得 ISO 9000 标准认证的企业应该具有 CMM 第 2~3 级的水平

软件过程管理模型：ISO/IEC 1504（2023Fall 不涉及）

  1. 也叫 SPICE（Software Process Improvement and Capability Determination）
  2. 过程类别共有五种，分别是
    1. 客户-供应商（CUS）过程
    2. 工程（ENG）过程
    3. 支持（SUP）过程
    4. 管理（MAN）过程
    5. 组织（ORG）过程

软件过程改进模型：PDCA 模型（2023Fall 不涉及）

PDCA 模型的步骤：

  1. 分析现状，找出问题
  2. 分析影响质量的原因
  3. 找出措施
  4. 拟定措施计划
  5. 执行措施，执行计划
  6. 检查效果，发现问题
  7. 总结经验，纳入标准
  8. 遗留问题转入下期 PDCA 循环

软件过程改进模型：IDEAL 模型（2023Fall 不涉及）

IDEAL 模型解决了软件组织在各种质量改进环境下的需要。它包括了软件过程改进周期中的五个阶段，IDEAL 是代表这五个阶段的单词的首字母。

  1. I: Initiating 初始
  2. D: Diagnosing 诊断
  3. E: Establishing 建立
  4. A: Acting 执行
  5. L: Leveraging 调整

软件过程管理/改进模型：CMM

定义：CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。

级别：分为五个级别，一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

等级一：初始级 Initial

特点：处于该级别的组织基本上没有健全的软件工程管理制度。

  1. 每件事情都用特殊的方法去做：如果特定工程遇到有能力的管理员和一个优秀的软件开发组来做，则可能是成功的。
  2. 大多数的行动只是应付危机，而非事先计划好的任务。通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。
  3. 软件过程完全取决于当前的人员配置，具有不可预测性。

要精确地预测产品的开发实践和费用之类重要的项目，是不可能的。

等级二：可重复级 Repeatable

特点：有些基本的软件项目的管理行为、设计和管理技术是基于相似产品中的经验。

  1. 采取了一些措施，这些措施是实现一个完备过程所必不可缺少的第一步。
    1. 典型措施包括：仔细地追踪费用和进度。
    2. 不像第一级那样，在危机状态下才行动，管理人员在问题出现时便可发现，并立即采取修正行动，防止它们变成危机。
  2. 关键一点：没有这些措施，要在问题变得无法收拾前发现它们是不可能的。在一个项目中财务的措施也可以为未来的项目拟定实现的期限和费用计划。

等级三：已定义级 Defined

特点：为软件生产的过程编制了完整的文档。

  1. 软件过程管理方面和技术方面已经做了明确的定义，并且按需要不断地改进过程。
  2. 采用评审的方法来保证软件的质量。

这个级别可以引用 CASE 环境来进一步提高质量和产生率。

在第一级的过程中，高技术会使得该危机驱动过程更加混乱。

等级四：已管理级 Managed

特点：公司对每个项目都设定质量和生产目标。

  1. 这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。
  2. 利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离。

统计质量控制措施的一个简单例子：是每千行代码的错误率，相应的目标就是随时间推移减少这个量。

等级五：优化级 Optimizing

目标：连续地改进软件过程。

  1. 使用统计质量和过程控制技术作为指导。
  2. 从各方面获得的知识将被运用在以后的项目中，从而使软件过程融入正反馈循环，使生产率和质量得到稳步的改进。

【2022Fall】软件过程管理/改进模型：CMMI

CMMI Capability Maturity Model Integration 能力成熟度集成模型

  1. 刻画了软件团队/组织从不成熟到成熟的每个阶段的特征（也就是 roadmap）
  2. 等级 2 和等级 3 关注的是当前状态
  3. 等级 4 和等级 5 是根据结果（未来）来进行管理

等级一：初始级

开发相对混乱，依赖个人英雄主义，没有过程概念，救火文化盛行

  1. 软件组织对项目的目标与要做的努力很清晰，项目的目标可以实现。
  2. 由于任务的完成带有很大的偶然性，软件组织无法保证在实施同类项目时仍然能够完成任务，项目实施是否成功主要取决于实施人员。

等级二：已管理级

项目小组体现出项目管理的特征，有项目计划和跟踪、需求管理、配置管理等。

  1. 软件组织对项目有一系列管理程序，避免了软件组织完成任务的随机性，保证了软件组织实施项目的成功率。
  2. 软件组织在项目实施上能够遵守既定的计划与流程，有资源准备，权责到人，对项目相关的实施人员进行相应的培训，对整个流程进行监测与控制，并联合上级单位对项目与流程进行审查。
  3. 从 2 级升级到 3 级的原因：固化最佳实践，对小组而言是能够更快地学习其他的做法。

等级三：已定义级

公司层面有标准流程和相应的规范，每个项目小组可以基于此定义自己的过程，使得优秀的做法可以在公司内分享。

  1. 软件组织能够根据自己的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。
  2. 软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。
  3. 科学管理成为软件组织的一种文化，成为软件组织的财富。

等级四：定量管理级

构建预测模型，以统计过程控制的手段来管理过程

  1. 软件组织的项目管理实现了数字化。
  2. 通过数字化技术来实现流程的稳定性，实现管理的精度，降低项目实施在质量上的波动。
  3. 在这个级别我们希望能够看到一个预测模型。

等级五：优化级

继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题

  1. 软件组织能够充分利用信息资料，对软件项目在项目实施的过程中可能出现的次品予以预防。
  2. 能够主动地改善流程，运用新技术，实现流程的优化。

一些理解

  1. CMM/CMMI 不适用于软件开发的原因
    1. CMM/CMMI 并不是一种具体的软件过程或者软件开发方法
      1. CMM/CMMI 建立了一组有效地描述成熟软件组织特征的准则。
      2. CMMI 是过程改进模型而非软件过程或者软件过程模型：CMMI 指导软件过程改进，不指导开发。
      3. 按照 CMM/CMMI 模型的要求，一个软件组织应当定义使用本软件组织特点的软件过程，并且不断优化该过程，来更好地实现软件组织的商业目标。
    2. CMM/CMMI 并不能作为检验软件过程优劣的标准：过程改进对不同企业的含义不一样，成熟度等级无法脱离企业环境直接横向比较。
    3. CMM/CMMI 与其他软件过程或者软件开发方法的比较是没有任何意义的。
  2. 一些误解：
    1. CMMI 模型需要适当裁剪以适应公司的实际情况：需要裁剪的是公司内部定义的组织级开发流程和开发规范。
    2. CMMI 模型太重了，不适合互联网时代的轻量级开发：这个说法的错误之处在于，不一定是 CMMI 重或者轻，而是，CMMI 根本就不是开发模型。
    3. CMMI 模型只适合大公司、大项目，不适合小项目：首先没人检验过；其次，项目的大小衡量本身也缺乏值得信赖的参考依据；最后，接受这种说法的人还是把 CMMI 当成是一种特殊的开发模型。
    4. CMMI 模型只适合需求不变或者很少变化的场合，不适合需求不确定，变化很多的场合：CMMI 不是开发模型，与需求变化与否无关，谈不上适应或者不适应。
  3. CMMI 不是过程优劣的标准，也不适合用作公司之间的能力比较，说法怎么样？对的，CMMI 本身是有评级。（美国国防部订单招标要求企业至少达到 CMMI 的 3 级。因为公司的能力需要绝对东西，也就是能力强，能力弱，而 CMMI 衡量的是相对的水平，CMMI 仅仅关注在本公司的目标下的等级
  4. 更多讨论：试论 CMM/CMMI 不适合在当前软件开发当中应用的原因

软件过程框架：RUP（2023Fall 不涉及）

  1. Rational 统一过程（Rational Unified Process）
  2. 最佳实践
    1. 迭代式开发
    2. 管理需求
    3. 使用基于构件的体系结构
    4. 可视化建模
    5. 验证软件质量
    6. 控制软件变更
  3. RUP 软件开发生命周期
    1. 初始阶段：建立业务模型，定义最终产品视图，并且确定项目的范围
    2. 精化阶段：设计并确定系统的体系结构，制定项目计划，确定资源需
    3. 构建阶段：开发出所有构件和应用程序，把它们集成为客户需要的产品，并且详尽地测试所有功能
    4. 移交阶段：把开发的产品提交给用户使用