EagleBear2002 的博客

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

软件质量管理-09-复习

发表于 更新于 分类于
本文字数： 34k 阅读时长 ≈ 31 分钟

本文内容有许多超出 2023Fall 授课范围，不建议用作考试复习。本文不持续维护。

软件开发的四大本质难题

四大本质难题是什么

  1. 不可见性：软件项目是一个逻辑实体
  2. 复杂性：实体数量众多
  3. 可变性
  4. 一致性

四大本质难题之间的关系

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

几个注意点

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

软件发展

软件发展的两个趋势：

  1. 软件项目规模日益扩大：使得软件越来越难做。
  2. 软件在整个系统中的比重日益增加：将软件质量问题的影响上升到前所未有的高度。

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

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

软件发展的三大阶段：

  1. 软硬件一体化阶段：软件完全依附于硬件，软件作坊（50 年代到 70 年代）
  2. 软件成为独立的产品（70 年代到 90 年代）
  3. 网络化和服务化（90 年代中期至今）

软硬件一体化阶段

  1. 软件完全依赖于硬件
    1. 软件应用典型特征：软件支持硬件完成计算任务、功能单一、复杂度有限、几乎不需要需求变更。
    2. 软件开发典型特征：硬件太贵、团队以硬件工程师和数学家为主。
    3. 典型软件过程和实践
      1. 非常线性
      2. 三思而后行（measure twice，cut once）
  2. 软件作坊
    1. 软件应用典型特征：功能简单、规模小。
    2. 软件开发典型特征：很多非专业领域人员涌入软件、高级程序语言出现、质疑权威文化盛行。
    3. 典型软件过程和实践：
      1. Code and Fix
      2. 编码 + 改错

软件成为独立的产品

  1. 软件应用典型特征：摆脱了硬件的束缚（OS）、功能强大、个人电脑出现 -> 普通人成为软件用户 -> 需求多变、兼容性要求、来自市场的压力
  2. 典型软件过程和实践
    1. 形式化方法：将所有的方法当作数学方法，做数学化的检验，主要解决质量和正确性问题。
    2. 结构化程序设计和瀑布模型
      1. 自顶向下，逐步求精。
      2. 问题和不足（效率和质量）
        1. 形式化在扩展性和可用性方面存在不足。
        2. 瀑布模型成为一个重文档、慢节奏的过程。

网络化和服务化

网络化和服务化

  1. 软件应用典型特征：功能更复杂、规模更大、用户数量急剧增加、快速演化和需求不确定、分发方法的变化（SaaS）
  2. 典型软件过程和实践：
    1. 迭代式（90 年代中后期）大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来交付。
    2. 雪鸟会议和敏捷宣言
      1. 个体和互动 胜过 流程和工具
      2. 可以工作的软件 胜过 详尽的文档
      3. 客户合作 胜过 合同谈判
      4. 响应变化 胜过 遵循计划
      5. 尽管右项有价值，但是我们更重视左项的价值
    3. XP eXtreme Programming 方法：偏重于一些工程实践的描述
    4. Scrum：管理框架和管理实践。
    5. KanBan
      1. 精益生产（丰田制造法）的具体实现
      2. 可视化工作流、限定 WIP、管理周期时间
    6. 开源软件开发方式：
      1. 一种基于并行开发模式的软件开发的组织与管理方式。
      2. Linus 定律：如果有足够多的 beta 测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。
      3. “早发布，常发布，倾听用户的反馈”、“把你的用户当作开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径”、“设计上的完美不是没有东西可以再加，而是没有东西可以再减”
      4. 代码管理：严格的代码提交社区审核制度、内部开源（inner source）、众包（Crowdsourcing）

更深化的网络化和服务化

  1. 软件应用典型特征
    1. 进一步服务化和网络化（移动是主流）随处可见（pervasive）
    2. 用户需求的多样性进一步凸显
    3. 软件产品和服务的地位变化
    4. 错综复杂的部署环境。
    5. 近乎苛刻的用户期望
      1. 多：功能丰富，个性化
      2. 快：快速使用，及时更新，快速解决问题
      3. 好：稳定，可靠，安全，可信
      4. 省：用户的获得成本低，最好免费
  2. 软件开发的典型特征
    1. 空前强大的开发和部署环境：XaaS，IaaS、PaaS、SaaS
    2. 盛行开源和共享文化
    3. 盛行敏捷开发
    4. 软件工程的潜在支撑力量获得了长足进步（AI、大数据、云计算）
  3. 【2021Fall】典型软件过程和实践：DevOps
    1. 开发运维一体化
    2. 方法论的基础是软件敏捷开发、精益思想和看板 KanBan 方法
    3. 以领域驱动设计为指导的微服务架构方式
    4. 大量虚拟化技术的使用
    5. 一切皆服务 XaaS 的理念指导
    6. 构建了强大的工具链，支持高水平自动化。

软件工程

  1. 软件工程是一门研究用工程化的方法构建和维护有效的、实用的和高质量的软件的学科。
  2. 软件工程的两大视角
    1. 管理视角：能否复制成功？
    2. 技术视角：是否可以将问题解决得更好？

管理

  1. 管理的三大关键要素：目标、状态（是在接近目标还是在原理目标）和纠偏。
  2. 大部分情况下，管理仅仅是视图复制其他地方（场景）的成功，但是这种复制一般不容易
  3. 软件项目管理是为了降低/减少各种无谓的损耗来实现本该有的性能。
  4. 软件过程改进是为了达到更好的效能，其中质量/缺陷是首要目标或限制。

软件项目管理

  1. 典型的三大目标：成本、质量和工期。
  2. 定义：软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
    1. 软件项目管理包括估算、计划、跟踪、风险管理、范围管理、人员管理、沟通管理等等。
    2. 软件项目管理的对象是各类软件项目
  3. 可以细分为两种管理视角：软件过程与生命周期模型

软件过程管理

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

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

  1. 两者含义接近
  2. 软件过程管理参考模型 CMM/CMMI，SPICE 等。
  3. 软件过程改进参考元模型 PDCA、IDEAL 等。

软件过程

  1. 软件过程是为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这一组实践往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。

广义软件过程

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

生命周期模型

  1. 生命周期模型是对软件过程的一种人为划分。
  2. 典型生命周期模型：瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等。

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

  1. 定义：CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。
  2. 级别：分为五个级别，一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

等级一：初始级 Initial

  1. 特点：处于该级别的组织基本上没有健全的软件工程管理制度。
    1. 每件事情都用特殊的方法去做：如果特定工程遇到有能力的管理员和一个优秀的软件开发组来做，则可能是成功的。
    2. 大多数的行动知识应付危机，而非事先计划好的任务。通常的情况是，由于缺乏健全的总体管理和详细计划，时间和费用经常超支。
    3. 软件过程完全取决于当前的人员配置，具有不可预测性。
  2. 要精确地预测产品的开发实践和费用之类重要的项目，是不可能的。

等级二：可重复级 Repeatable

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

等级三：已定义级 Defined

  1. 特点：为软件生产的过程编制了完整的文档。
    1. 软件过程管理方面和技术方面已经做了明确的定义，并且按需要不断地改进过程。
    2. 采用评审的方法来保证软件的质量。
  2. 这个级别可以引用 CASE 环境来进一步提高质量和产生率。
  3. 在第一级的过程中，高技术会使得该危机驱动过程更加混乱。

等级四：已管理级 Managed

  1. 特点：公司对每个项目都设定质量和生产目标。
    1. 这两个量将被不断地测量，当偏离目标太多时，就采取行动来修正。
    2. 利用统计质量控制，管理部门能区分出随机偏离和有深刻含义的质量或生产目标的偏离。
  2. 统计质量控制措施的一个简单例子：是每千行代码的错误率，相应的目标就是随时间推移减少这个量。

等级五：优化级 Optimizing

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

软件过程管理/改进模型：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 不适合在当前软件开发当中应用的原因

软件过程改进模型：PDCA 模型

PDCA 模型的步骤：

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

软件过程改进模型：IDEAL 模型

  1. IDEAL 模型解决了软件组织在各种质量改进环境下的需要。它包括了软件过程改进周期中的五个阶段，IDEAL 是代表这五个阶段的单词的首字母。
    1. I: Initiating 初始
    2. D: Diagnosing 诊断
    3. E: Establishing 建立
    4. A: Acting 执行
    5. L: Leveraging 调整

软件过程管理模型：ISO/IEC 1504

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

软件过程框架：RUP

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

软件过程改进模型

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

软件质量管理发展：软件质量大师的主要观点和贡献、工作

描述下述质量管理大师的主要观点和贡献，工作对软件过程和项目管理的借鉴意义

Shewhart

  1. 最早将统计控制的思想引入质量管理，是质量改进奠基人;
  2. 提出 PDS 模型（计划执行检查 Plan-Do-See)，后被戴明进一步发展为 PDCA。

软件开发实践

敏捷软件开发

  1. 敏捷中也有计划驱动

敏捷目的

为了使软件开发团队具有高效工作和快速响应变化的能力

敏捷原则

  1. 最重要的是通过尽早和不断交付有价值的软件满足客户需要
  2. 欢迎需求的变化
  3. 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好
  4. 业务人员和开发者应该在整个项目过程中始终朝夕在一起工作
  5. 最好的信息传达方式是面对面的交谈

敏捷宣言

敏捷宣言内容
  1. 敏捷软件开发宣言的 4 个简单的价值观:
    1. (1')个体和交互 胜过 过程和工具
    2. (1')可以工作的软件 胜过 面面俱到的文档
    3. (1')客户合作 胜过 合同谈判
    4. (1')响应变化 胜过 遵循计划
  2. (1')也就是说，尽管右项有其价值，我们更重视左项的价值

敏捷软件开发方法

极限编程 XP
  1. eXtreme Programming，极限的含义是指把好的开发实践运用到极致
  2. 极限编程的有效实践
    1. 客户作为开发团队的成员 —— 客户代表
    2. 使用用户素材
    3. 短交付周期
    4. 验收测试
    5. 结对编程——结对编程就是由两名开发人员在同一台计算机上共同编写解决同一个问题的程序代码，通常一个人编码，另一个人对代码进行审查与测试，以保证代码的正确性与可读性。结对编程是加强开发人员相互沟通与评审的一种方式。
    6. 测试驱动开发——极限编程强调“测试先行”。在编码之前，应该首先设计好测试方案，然后再编程，直至所有测试都获得通过之后才可以结束工作。
    7. 集体所有
    8. 持续集成
    9. 可持续的开发速度 <=40h/week
    10. 开放的工作空间
    11. 重构
    12. 使用隐喻
Scrum
  1. 迭代式增量软件开发过程：

  1. Scrum 中的文档
    1. 产品订单（product backlog)：整个项目的概要文档，包含了已划分优先等级的、项目要开发的系统或产品的需求清单，是动态的。
    2. 冲刺订单（sprint backlog)：细化了的文档，包含了团队如何实现下一个冲刺的需求信息。
      1. 哪些产品订单会加入一次冲刺由冲刺计划会议决定。会议中，产品负责人告诉开发团队他们需要完成产品订单中的哪些订单项，开发团队决定在下一次冲刺中承诺完成多少订单项。
      2. 在冲刺的过程中，没有人能够变更冲刺订单（sprint backlog)，这意味着在一个冲刺中需求是被冻结的。
    3. 燃尽图（burn down chart)
  2. Scrum 中角色
    1. 产品负责人，代表利益所有者
      1. 产品负责人的职责是将开发团队开发的产品价值最大化。
      2. 产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：
        1. 清晰地表述产品待办列表项；
        2. 对产品待办列表项进行排序，使其最好地实现目标和使命；
        3. 优化开发团队所执行工作的价值；
        4. 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队下一步要做的工作；以及
        5. 确保开发团队对产品待办列表项有足够深的了解。
    2. Scrum Master，类似于项目经理，负责维护过程和任务
      1. 促进和支持 SCRUM
      2. 帮助每个人理解 SCRUM 理论、实践、规则和价值
      3. SCRUM Master 是一位服务型领导。
        1. 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的
        2. 改变 SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团队所创造的价值。
      4. Scrum Master 服务于产品负责人，包括：
        1. 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
        2. 找到有效管理产品待办列表的技巧；
        3. 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
        4. 理解在经验主义的环境中的产品规划；
        5. 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
        6. 理解并实践敏捷性；以及，
        7. 当被请求或需要时，引导 Scrum 事件。
      5. Scrum Master 以各种方式服务于开发团队，包括
        1. 作为教练在自组织和跨职能方面给予开发团队以指导；
        2. 帮助开发团队创造高价值的产品；
        3. 移除开发团队工作进展中的障碍；
        4. 按被请求或需要时，引导 Scrum 事件；以及，
        5. 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
      6. Scrum Master 以各种方式服务于组织，包括：
        1. 带领并作为教练指导组织采纳 Scrum；
        2. 在组织范围内规划 Scrum 的实施；
        3. 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
        4. 引发能够提升 Scrum 团队生产率的改变；以及，
        5. 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。
    3. 开发团队
      1. 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
      2. 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。开发团队具有下列特点：
        1. 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该如何把产品待办列表变成潜在可发布的功能增量；
        2. 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全部技能；
        3. Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开发人员）。
        4. Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测试、架构、运维或业务分析；同时，
        5. 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。
  3. Scrum 常见活动
    1. Sprint Planning Meeting
    2. Daily standup meeting
    3. review meeting
    4. retrospective meeting
    5. sprint
  4. Empirical Process Control VS. Statistical Process Control，不同于统计过程控制方法（也叫预测式、计划式）不能解决不可预见的需求变化问题，Scrum 采用的实证过程控制承认问题无法完全理解或定义，即用户可以在项目过程中变更需求，关注于如何使开发团队快速推出和响应需求变化的能力最大化
  5. Scrum VS. XP
    1. 迭代周期不同。XP 迭代周期为 1~2 周，而 Scrum 迭代周期为 2~4 周
    2. 迭代中是否允许需求变更。XP 中只要变更需求与原需求所需时间资源相等即可变更，而 Scrum 在迭代中需求被冻结
    3. 迭代中，需求是否严格按照优先级来实现。XP 中务必遵守优先级别，Scrum 中则比较灵活，原因是可能有需求依赖问题
    4. 过程工程化。Scrum 开发过程并未工程化，要求开发者自觉保证，但 XP 则对开发流程定义严格，例如 TDD，结对编程，重构等
Kanban 方法
  1. 精益生产（丰田制造法）的具体实现
  2. 可视化工作流、限定 WIP、管理周期时间
  3. 马丁提出了微服务架构

PSP 个体软件过程

PSP 是什么？

  1. PSP 是包括了数据记录表格、过程操作指南和规程在内的结构化框架。
  2. PSP 着重于软件开发人员的个人能力提升，体现在估算能力、计划能力、计划执行以及质量管理等方面
  3. 基本的 PSP 包括策划、设计、编码、编译、单元测试以及总结等阶段。
    1. 每个阶段都有相应的过程操作指南，用来指导该阶段的开发活动。
    2. 每个阶段，都有相应的过程操作指南，用来指导该阶段的开发活动。
    3. 所有的开发活动都需要记录相应的时间日志和缺陷日志。

PSP 基本原理（为什么要有 PSP）

  1. 软件系统的整体质量由该系统中质量最差的某些组件所决定
  2. 软件组件的质量取决于开发工程师所使用的开发过程。
  3. 软件工程师应当自己度量、跟踪自己的工作流程，并建立持续的自我改进机制（在自己开发过程的偏差中学习、总结，并将这些经验教训整合到自己的开发实践），自己管理软件组件的质量。

上述基本原理除了继续肯定“过程质量决定最终产品质量“这一软件过程改进的之外，更加突出了个体软件工程师在管理和改进自身过程中的能动性。这就形成了 PSP 的理论基础。

PSP 的成熟度级别

PSP 的度量

基本度量项

  1. 度量时间：序号、所属阶段、开始时间、结束时间、中断时间、净时间、中断原因
  2. 度量缺陷：序号、发现日期、注入阶段、消除阶段、消除时间、关联缺陷、缺陷产生原因
  3. 度量规模：使用 PROBE 方法
    1. 选择的规模度量方式必须反映开发成本
    2. 度量规模必须被精确定义
    3. 度量规模必须有自动化方法统计
    4. 有助于早期规划
  4. 日程（TSP）

度量的作用

  1. 度量体现着决策者对试图要实现的目标的关切程度。
  2. 度量帮助过程的实践者了解过程状态，理解过程偏差。

规模度量标准

  1. 选择的度量方式必须反映开发成本。
  2. 选择的度量方式必须精确。
  3. 选择的度量方式必须能用自动化方法来统计。
  4. 选择的度量方式必须有助于早期规划。

规模的度量的困境

  1. 精确的度量方式往往不便于早期规划。
  2. 有助于早期规划的度量往往难以生成精确度量结果。

PROBE 方法

  1. 估算的目的是给各类计划提供决策依据
估算原理
  1. 设置合理的代理作为精确度量和早期规划需要的度量之间的桥梁：相对大小矩阵
  2. 相对大小而非绝对大小
PROBE 方法例子
  1. 估算房子面积大小
    1. 使用房间相对大小矩阵
    2. 使用房间作为代理
  2. 估算程序规模和工作量
    1. 使用代码相对大小矩阵
      1. 每个组件都有设定的类型（计算、逻辑或数据）
      2. 规模（非常小、小、中、大、非常大）
    2. 假设
      1. 如果新建立的组件与以前建立的组件类似，那么新组建所需的工作量与旧组件一样。
      2. 当开始一个新项目时，我们可以将任务划分为与代码库中组件相似的类型和规模，然后利用线性回归方法来估算项目的工作量。
  3. 具体例子见课本
方法思想
  1. 在 PROBE 估算中，需要建立自己的代码库，以跟踪所有程序的规模和工作量，而代码库中的每个组件都有设定的类型（计算、逻辑或数据等）和规模（非常小、小、中、大、非常大）。
    1. 如果新建立的组件与以前建立的组件类似，那么新组件所需的工作量与旧组件一样。
    2. 当开始一个新项目时，我们可以将任务划分成与代码库中组件相似的类型和规模，然后利用线性回归方法来估算项目的工作量。
  2. 估算本质上是一种猜测，追求的目标是一致性以及估算结果的使用者对估算结果的信心。
    1. PROBE 方法通过定义估算过程和数据收集以及使用的框架，使得估算结果可以尽可能一致，从而使得一些统计方法可以用来调整估算结果，增强用户对估算结果的信心。
    2. PROBE 方法非常依赖高质量的历史数据，一旦数据不完整或缺失，会导致估算结果有明显偏差。
通用计划框架

  1. 上述框架中，那些步骤必须人为的干预
    1. 定义需求
    2. 概要设计：划分由人为开始，规模划分好之后估算是自动产生的
    3. 日程计划
  2. 这会带来什么的好处？比较容易扛住别人的质疑。
    1. 攻击点：资源和时间是否被高估了
    2. 解决：估算没有代码行 PROBE 只有功能点是大中小。
PROBE 估算过程

  1. 概要设计
    1. 确定产品功能，以及产生这些功能所需的程序组件/模块
    2. 将程序组件/模板与你之前写的程序相比较，估算它们的规模
    3. 最后将程序组件/模块估算综合给出总规模
  2. 估算要点：
    1. 尽可能划分详细一些：估算多个部件的时候，总的误差会比各个部件的误差的总和小
    2. 建立对结果的信心
    3. 依赖数据
    4. 估算要的是过程，而非结果，估算的过程是相关干系人达成一致共识的过程。
注意点 1：整理历史数据

以估算规模为例，可以假定代理规模与实际程序规模之间存在简单关系映射、正态分布、对数正态分布，也可以假定不知道两者之间的关系，按照线性回归方法进行计算。

  1. 简单方法
    1. 内容：最小值作为 VS、最大值作为 VL、中值作为 M,VS 与 M 均值作为 S、VL 与 M 均值作为 L
    2. 优点：计算简单
    3. 缺点：不稳定
  2. 正态分布法
    1. 内容：均值作为 M，计算标准差 σ，则 S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ
    2. 优点：相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵
  3. 对数正态分布法:
    1. 内容：
      1. 以 e 为底计算所有数据的自然对数
      2. 取对数之后的值的均值作为 M，计算相应标准差 σ;S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ
      3. 取反对数
    2. 优点：更加符合人们对于程序的规模的直观感觉，因为大多数人习惯写很多规模很小的程序，少量规模较大的程序
  4. 线性回归方法
    1. 计算的时候计算了两组线性回归的参数，也就是项目所需的资源并不是直接由程序规模和历史数据中的生产效率相除得到。程序的复杂度和程序规之间并不是简单的正相关关系。
    2. 线性回归方法估算的是一定概率条件下估算值的分布。例如最终实际程序规模有 90%的可能性落在（a,b)区间内
    3. Range 为在一定概率条件下的变化区间，而 p 为概率
    4. Variance 为扰动程度：有时候，历史数据中的一些极端数据会造成相关性的“假象”，故需要先进行数据除噪。

\[ \begin{array}{l} Plan\ Size = \beta_{0\ size} + \beta_{1\ size}(E) \\ Plan\ Time = \beta_{0\ time} + \beta_{1\ time}(E) \\ Range = t(p,df)\delta\sqrt{1 + \frac{1}{n} + \frac{(x_k-x_{avg})^2}{\sum\limits_{i=1}\limits^{n}(x_i-x_{avg})^2}} \\ Variance = \delta^2 = \frac{1}{n-2}\sum\limits_{i=1}\limits^n(y_i - \beta_0 - \beta_1x_i)^2 \\ \end{array} \]

  1. Plan Size 和估算的类数量不呈现 45 度，是受到了估算误差和方法外代码的数量共同影响
  2. 该方法没有使用生产效率进行计算，为什么在 PROBE 中不使用生产效率？这样子使用好不好？因为 Plan Size 是在一个范围内波动，生产效率也在一个范围内波动，如果将生产效率作为分母，那么可能会导致更大的误差，也就违背了误差的出发点。
  3. 估算能力的强弱关注是多稳定，而不是多接近具体的实际情况
注意点 2：处理有限的历史数据
  1. 规模估算
    1. 往往可以依据历史数据来完成，使用代理规模与实际程序规模之间的关系。
    2. 其原因在于规模估算结果的偏差产生原因相对客观，偏差可以用以修正新的估算结果。
    3. 估算规模对历史数据的要求如下

其中 r 为相关性（两组数据之间相互关联的程度，PSP 中要求 r>= 0.7)，其中 S 为显著性（两组数据的相关关系出现的偶然性，PSP 要求 s<=0.05)

  1. 时间估算
    1. 使用代理规模和实际开发时间的关系。
    2. 时间估算的偏差产生原因更加复杂：一方面和规模有关，另一方面和人的主观能动性有关。
    3. 历史数据中的时间偏差可参考价值不大。

其中 r 为相关性（两组数据之间相互关联的程度，PSP 中要求 r>= 0.7)，其中 S 为显著性（两组数据的相关关系出现的偶然性，PSP 要求 s<=0.05)

注意点 3：处理极端数据
  1. 极端数据可能造成相关性假象。

PSP 的质量管理

PSP 质量观与质量策略

  1. 软件项目的日程、成本以及质量三大目标统一于质量目标
  2. 什么是软件质量？
    1. 与软件产品满足规定的和隐含的需求能力有关的特征或者特征的全体
    2. PSP 中定义质量为满足用户需求的程度，需要明确用户需求的范围、优先级、度量方式
  3. 软件质量分为内外两部分的特性
    1. 其外部质量特性面向软件产品的最终用户。
    2. 其内部质量特性不直接面向最终用户。
  4. 软件质量的不同视角
    1. 软件质量为软件产品可以改变世界，使世界更加美好的程度。从用户的角度考察软件质量，用户满意度是最为重要的判断标准。
    2. 软件质量是对人（用户）的价值，这一定义强调了质量的主观性，即对于同一款软件而言，不同的用户对其质量有不同的体验。
面向用户的质量观
  1. PSP 中也采用了面向用户的质量观，定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：
    1. 用户究竟是谁？
    2. 用户需求的优先级是什么？
    3. 这种用户的优先级对软件产品的开发过程产生什么样的影响？
    4. 怎样来度量这种质量观下的质量水平？
  2. 典型用户质量期望
    1. 这款软件产品必须能够工作：因此可以使用缺陷管理代替质量管理
    2. 这款软件产品最好有较快的执行速度
    3. 这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异。
  3. 指导意义
    1. 开发在前，运维在后
    2. 高质量开发确保 DevOps 中的价值顺畅流动
    3. 个体软件工程师的技能、过程直接影响产品质量
    4. PSP 关注提升个体软件工程师工程技能
质量策略
  1. 首先确保基本没有缺陷，然后再考察其他的质量目标。
  2. 使用缺陷管理来代替质量管理
  3. 高质量的产品也就意味着组成软件产品的各个组件基本无缺陷
  4. 各个组件的高质量是通过高质量评审来实现的

为什么有效?

  1. 提高生产效率，通过关注每个组件的质量，往往可以避免在集成测试和系统测试消除
  2. 大量缺陷，减少消除代价，提升生产效率
质量路径 Quality Journey

为了追求极高的质量，你有哪些手段？

  1. 第一步：各种测试
  2. 第二步：进入测试之前的产物质量提升
  3. 第三步：评审过程度量和稳定
  4. 第四步：质量意识和主人翁态度
  5. 第五步：个体 review 的度量和稳定
  6. 第六步：诉诸设计
  7. 第七步：缺陷预防
  8. 第八步：用户质量关 —— 其他质量属性

发现缺陷的几个示例流程

测试消除缺陷的典型流程
  1. 发现待测程序的一个异常行为
  2. 理解程序的工作方式
  3. 调试程序，找到出错的位置，确定出错的原因：非常耗时，在项目后期可能会消耗数天甚至数周的时间
  4. 确定修改方案，修改缺陷
  5. 回归测试，以确认修改有效
评审发现缺陷的典型流程

在如下的步骤中，每一步消耗的时间都不会太多。尽管评审的技能因人而异，但是，通过适当培训和积累，有经验的评审者可以发现 80%左右的缺陷。

  1. 遵循评审者的逻辑来理解程序流程
  2. 发现缺陷的同时，也知道了缺陷的位置和原因
  3. 修正缺陷

评审与测试

评审检查表
  1. 评审检查表的建立和维护：示例见课本
  2. 评审检查表的使用
评审形式

打印后评审效果更好

  1. 单个屏幕可以展现的内容比较有限（评审对象比较复杂的时候，单个屏幕往往不能体现评审对象的整体结构、整体安全、整体性能以及其他整体属性）
  2. 评审人员的注意力：基于屏幕的评审往往容易受到干扰，从而影响评审人员的注意力
评审时机
  1. 编译、评审
    1. 对于某些类型的缺陷而言，通过编译发现并消除的效率往往是通过评审发现并消除的数倍。
      1. 越来越强大的编译器一般可以发现超过 90% 的拼写错误。
      2. 不管怎么努力，评审还有会遗漏约 20-50% 的语法错误。
      3. 即便编译器遗漏了一些类似语法的错误，这些错误也不难通过单元测试消除。
    2. 一些基于解释执行的集成开发环境，可以实现消除编译错误。
  2. 评审、编译
    1. 为了确保评审的效率，不管在评审之前有没有编译，评审的速度是一定的，也就意味着评审所需时间是一定的，那么如果先评审后编译，在编译阶段就可以节省较多的时间。
    2. 编译器会大概会遗漏 9%左右的缺陷，从前面讨论可知，为了有较高的质量，这些缺陷仍然期望通过评审加以消除。
    3. 有数据表明，编译过程中缺陷较多，往往意味着单元测试中缺陷也较多。
    4. 即便单元测试也可以发现一些类似语法的错误，但是，毕竟还有些很难发现，而单元测试之后的一些缺陷消除环节的 Pahse Yield 往往还低于单元测试。
    5. 编译之前评审也是一种自我学习的好机会。
    6. 干净的编译，即编译过程没有缺陷对于软件工程师来说，也有极大的成就感。
评审的具体形式

个人评审、小组评审

  1. 个人评审 -> 小组评审
  2. 小组评审的意义
    1. 有利于更好地发现缺陷，预防风险，提高 Process Yield 进而确保质量。
    2. 在个人评审之后安排小组评审，也有利于提升个人的技能。特别是那些个人评审未发现而个人评审发现的缺陷，往往都需要引起足够的注意。软件工程师通过对这些缺陷的分析，往往可以学到很多东西。
评审中缺陷预防过程中的缺陷数据选择
  1. 选择那些在系统测试、验收测试以及应用环节出现的缺陷，特别是验收测试和应用环节中的缺陷，这些缺陷往往意味着软件开发过程本身有不足之处。
  2. 选择那些在出现频率较高或者消除代价较高的缺陷，这些缺陷如果可以预防，往往可以节省较多开发的代价，从而体现缺陷预防的优势。
  3. 选择那些预防方法容易识别和实现的缺陷，这样的策略容易让软件工程师迅速看到缺陷预防的好处，鉴定使用缺陷预防策略的信心。

PSP 质量控制的衍生指标

Yield 指标
基本定义
  1. 定义了各个阶段在消除缺陷方面的效率
    1. Yield 指标越高越好
    2. Process Yield 我们期望在 80 以上

\[ \begin{array}{} Phase\ Yield = 100 * \frac{某个阶段发现的缺陷个数}{某个阶段注入的缺陷个数 + 进入该阶段前遗留的缺陷个数} \\ \\ Process\ Yield = 100 * \frac{第一次编译前发现的缺陷个数}{第一次编译前注入的缺陷个数} \end{array} \]

  1. Yield 可用于制定质量计划并且在项目执行阶段用于进行风险监控、预测、识别以及控制
  2. 例子
阶段 Injected Removed remain Yield
DFD 10 0 10 0
DFD REVIEW 0 4 6 40
CODING 20 2 24 1/13  100
CODE REVIEW 0 12 12 50
UNIT 0 12 0 100
  1. IBM：最后的测试如果发现了一个错误，那么其中一定还有一个错误没有被发现（所以最后的 Yield 的值为 50），修改后如下（没有发现的也按照原本的比例来分）
阶段 Injected Removed remain Yield
DFD 10+4 0 14 0
DFD REVIEW 0 4 10 2/7  100
CODING 20+8 2 36 2/19  100
CODE REVIEW 0 12 24 1/3  100
UNIT 0 12 12 50
  1. Yield 的计算是一种事后的质量控制手段，而且除非发现了所有的缺陷，否则很难非常精确地进行计算。

上图第一个消除步骤是需求评审，第二个消除步骤是设计评审，第三个消除步骤是测试评审

  1. 改进方案
    1. 结果受限于历史数据在简单性、可理解性、稳定性、可度量性、相关性等方法的质量。因此，维护历史数据。
    2. 影响因子的选择上面不仅仅需要有关软件规模的数据，还需要有关开发过程、开发文档、开发人员等方面的数据，并且需要将数据可度量化。
    3. 反馈模型。即在开发过程中随着实际数据的产生，将这些数据作为输入变量放入模型中以调整回归参数。
    4. （重要）可能的改进是假设注入水平和消除水平都符合正态分布，计算均值和标准差，因此，可以用蒙特卡罗方法模拟结果。
A/FR
  1. COQ(Cost of Quality)
    1. 失效成本：分析失效现象、查找原因，做必要的修改所消耗的成本
    2. 质检成本：评价软件产品，确定其质量状况所消耗的成本
    3. 预防成本：识别缺陷根本原因、采取措施预防其再次发生所消耗的成本
  2. 质检失效比
    1. A/FR = PSP 质检成本 / PSP 失效成本
    2. 质检成本 = 设计评审时间 + 代码评审时间
    3. 失效成本 = 编译时间 + 单元测试时间
  3. 理论上，A/FR 值越大，意味着质量越高，但 A/FR 值过大说明评审过多，则开发效率低下，因此 PSP 中 A/FR 期望值为 2.0
【2013】【2018Fall】PQI Process Quality Index 过程质量指标
  1. 为 5 个数据的乘积（以基准值作为 1，最后结果越接近 1，质量越高）
    1. 设计质量：设计时间应该大于编码时间，\(\min(\frac{设计时间}{编码时间}, 1)\)
    2. 设计评审质量：设计评审的时间应该大于设计时间的 50%，\(\min(2 \frac{设计评审时间}{设计时间}, 1)\)
    3. 代码评审质量：代码评审时间应该大于编码时间的 50%，\(\min(2 \frac{代码评审时间}{编码时间}, 1)\)
    4. 代码质量：代码的编译缺陷密度应当小于 10 个/千行，\(\min(\frac{20}{编译缺陷密度 + 10}, 1)\)
    5. 程序质量：代码的单元测试缺陷密度应当小于 5 个/千行，\(\min(\frac{10}{单元测试缺陷密度 + 5}, 1)\)
  2. 用途
    1. 判断模块开发质量
    2. 规划质量活动计划
    3. 过程改进
Review Rate
  1. 评审的速度是一个用以指导软件工程师开展有效评审的指标
  2. 代码评审速度小于 200 LOC（代码行）/h
  3. 文档评审速度小于 4 page（文档采用页）/h
DRL Defect-Removal-Leverage 缺陷消除效率比
  1. 缺陷消除效率比：不同缺陷消除手段消除缺陷的效率
  2. 计算方法：以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是 DRL

  1. 发现的效率：代码评审 > 设计评审 > 设计检查 > 代码检查 > 单元测试 > 系统测试

PSP 的设计

  1. PSP 设计过程的关注点并不是具体的设计方法，而是设计的步骤定义以及设计的表现形式

设计与质量的关系

  1. 低劣的设计是导致在软件开发中返工、不易维护以及用户不满的主要原因。
  2. 充分设计可以显著减少最终程序的规模，提升质量
  3. 设计本身也是一种排除错误的过程。

设计什么

  1. 设计目标程序在整个应用系统中的位置
  2. 设计目标程序的使用方式
  3. 设计目标程序与其他组件以及模块之间的关系
  4. 设计目标程序外部可见的变量和方法
  5. 设计目标程序内部运作机制
  6. 设计目标程序内部静态逻辑

设计的过程

设计内容

动态信息 静态信息
外部信息 交互信息（服务、消息等） 功能（继承、类结构等）
内部信息 行为信息（状态机） 结构信息（属性、业务逻辑等）

设计模板

动态信息 静态信息
外部信息 OST/FST FST
内部信息 SST LST
操作规格模板 Operational Specification Template
  1. 描述系统与外界的交互，用于场景描述：也就是”用户“与”待设计系统的正常情况和异常情况下的交互。
  2. 定义测试场景和测试用例，用来与用户讨论需求的基础，特别是操作相关的需求描述
  3. 与 UML 比较：用例图、时序图
功能规格模板（Functional Specification Template， 简称 FST）
  1. 描述系统的对外接口，是一种静态信息的展现。
  2. 提供的典型信息有类和继承关系、外部可见的属性和方法等。
  3. 用形式化符号等方法描述方法等行为，消除二义性。
  4. 与 UML 对比：UML 类图，但类图的方法的行为没有描述
状态规格模板（State Specification Template，简称 SST）
  1. 可以精确定义程序的所有状态、状态之间的转换以及伴随着每次状态转换的动作。
  2. SST 模板中，需要描述如下的信息
    1. 所有状态的名称
    2. 所有状态的简要描述
    3. 在 SST 中需要使用的参数和方法的名称与描述
    4. 状态转换的条件
    5. 状态转换是发生的动作。
  3. 与 UML 对比：UML 状态图
逻辑规格模板（Logical Specification Template，简称 LST）
  1. 可以精确描述系统的内部静态逻辑。为了消除描述的二义性，一般建议使用伪代码配合形式化符号来描述设计结果。
  2. LST 模板中，需要描述如下的信息
    1. 关键方法的静态逻辑
    2. 方法的调用
    3. 外部引用
    4. 关键数据的类型和定义
  3. 与 UML 对比：没有对应图
UML
  1. UML 图有用例图、时序图、类图、状态机图
  2. UML 的用例图和时序图提供了与 PSP 中 OST 同样的信息；
  3. UML 中的时序图和类图所描述的类之间的关系以及对象之间的交互信息在 PSP4 个设计模板中没有对应的内容；
  4. UML 类图中记录了方法的型构，然而方法的行为没有描述，这一点在 PSP 的 FST 中有相应的内容；
  5. PSP 中的 LST 用以描述程序的静态逻辑，这在 UML 没有对应的图示方法；
  6. UML 中的状态图与 SST 描述的状态图类似，但是 SST 中描述的关于状态、状态转换条件以及状态转换中的动作没有对应的 UML 图示方法。

PSP 设计验证方法

状态机验证
  1. 检查状态机的完整性和正交性
    1. 完整性：对于状态机中任何一个状态，对应的所有条件组合，下一个状态的转换都有定义。
    2. 正交性：对于状态机中任何一个状态，其所有下一个状态的转换条件都不能相同。
  2. 验证步骤
    1. 检查状态机，消除死循环和陷阱状态
    2. 检查状态转换，验证完整性和正交性
    3. 评价状态机，检验是否体现设计意图
  3. 具体验证方法参见 PPT
    1. 使用状态图，检查死循环和陷阱状态
    2. 使用真值表来进行分析
符号化验证
  1. 将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示是，然后系统地开展分析和验证
  2. 验证步骤
    1. 识别伪码程序中的关键变量
    2. 将这些变量使用代数符号表示，重写伪码程序
    3. 分析伪码程序的行为。
  3. 具体示例见 PPT：交换两个变量的值
  4. 优点
    1. 实施简单，可以给出一般化的验证结果
    2. 适用于不复杂的算法，特别是遗漏系统的改造中，应用这种方法识别和理解原有的设计
  5. 缺点：不适合于有复杂逻辑的场合；纯手工验证方法容易引入错误。
执行表验证
  1. 执行表
  2. 步骤
    1. 识别伪码程序的关键变量
    2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量
    3. 初始化被选定的变量
    4. 跟踪被选择的关键变量的变化情况，从而判断程序行为
  3. 优点：实施简单；结果可靠，可用于复杂逻辑的验证。
  4. 缺点：每次只能验证一个用例；手工验证比较耗时，容易引入错误。
跟踪表验证
  1. 步骤
    1. 识别伪码程序的关键变量
    2. 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量
    3. 初始化被选定的变量
    4. 识别将伪码程序符号化的机会，并加以符号化
    5. 定义并且优化用例组合
    6. 跟踪被选择的关键变量的变化情况，从而判断程序行动。
  2. 跟踪表应用符号化以及用例识别等方法，对程序的一般化行为进行验证，是执行表验证的补充，可以每次验证多个用例，从而提供更加高效地开展验证工作。
正确性验证
  1. 将伪码程序当做数字定理，采用形式化方法加以推理和验证
  2. 步骤
    1. 分析和识别用例
    2. 对于复杂伪码程序的结构，应用正确性验证的标准问题逐项加以验证
    3. 对于不能明确判断的复杂程序结果，使用跟踪表等辅助验证
  3. While-Do 循环的验证
    1. 条件 1：condition 是否最终一定会为"假"，从而使得循环可以结束。
    2. 条件 2：condition 为"真"的时候，单独的循环结构执行结果与循环体再加一个循环结构，其执行结果是否一致？
    3. 条件 3：condition 为"假"的时候，循环体内所有变量是否未被修改？

TSP 团队软件过程

TSP 提供了：

  1. 一个已经定义的团队构建过程
  2. 一个团队作业框架
  3. 一个有效的管理环境

团队工程开发：需求开发

需求开发包含需求获取、需求汇总、需求验证

需求分类

  1. 客户需求描述的是客户的期望，是客户解决问题的愿望。
    1. 客户需求可能很简单，也可能很复杂；可能很清晰，也可能模糊。
    2. 比如，客户希望有一种快速进行数据计算的工具帮助其完成繁琐的计算工作。
  2. 产品需求描述的是开发团队所提供的解决方案。即针对上述的客户需求，开发团队设计出一个可以帮助客户解决工作当中碰到的问题的方案。
  3. 产品组件需求描述的是组成产品的各个组件的需求规格。与产品需求相比，这是更低层次，更为细致的描述了上述解决方案中的某个组件的功能、性能与形式等。

为什么说“需求是一切工程活动的基础”

  1. 设计活动一定是依据需求而开展的
  2. 产品集成活动中，各个组件之间的接口必须满足事先确定的接口需求，否则会造成接口不匹配。
    1. 验证（Verification）活动也是检验获得的产品和产品组件能不能满足各自事先定义好的需求规格。
    2. 确认（Validation）活动是为了确保产品可以满足客户的需求以及实际操作场景的要求。
  3. 此外，需求也是项目计划活动的关键输入。比如，项目的规模估算、成本估算等必须参考需求来进行。

需求获取

  1. 需求是采用”诱导“式方法获取客户的显式需求和隐式需求，尽可能的识别客户的期望与所受到的限制。
    1. “诱导”不仅仅是普通的需求采集，隐含了更加积极地、前瞻性地识别那些客户没有明确提供的额外需求。
    2. 客户所受到的限制也应当作为需求开发过后需要关注的内容。限制包括技术、成本、时间、风险、行业规则、法律等等。

需求汇总

  1. 整理各种来源的信息，识别缺失的信息。
  2. 解决冲突的需求
    1. 需求的整理和转化：我们需要将客户的需求转换为产品需求和产品组件的需求
    2. 推导未显式描述的需求内容，例如采用某项技术的附属需求

需求验证

  1. 对需求进行分析和确认，以确保符合使用者预期
  2. 典型活动包括
    1. 建立和维护操作概念和相关的场景；场景一般而言是指使用产品时可能发生的时间顺序。
    2. 分析需求，以确保其必要性、充分性和平衡性。
    3. 确认需求，以确保将要产生的产品能在预期的用户环境中运行并且工作正常。

需求文档制作

  1. 需求开发工作完成的一个基本标志是形成了一份完整的、规范的、经过评审的需求规格说明书。
  2. 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。
优秀需求规格文档特征
特征 描述
内聚特征 需求规格描述应当尽可能内聚，即仅仅用以说明一件事情
完整特征 需求规格描述应当完整，不能遗漏信息
一致特征 需求规格描述的各个条目和章节不能互相矛盾，需求规格描述与所有外部的参考资料之间也应当消除矛盾之处
原子特征 需求规格描述的过程中，应当尽可能避免连接词的使用。如果需要描述多项内容，可以分别用简单语句加以描述
可跟踪特征 客户需求、产品需求以及产品组件需求必须可以双向跟踪，即客户需求的任何内容，都应当在产品需求和产品组件需求中得到体现。反之，产品组件需求的每一项描述也要可以跟踪到客户需求中的内容
非过期特征 需求描述的内容必须体现相关干系人对于项目的最新认识。即不能包含已经废弃的需求定义
可行性特征 需求规格描述的各项内容应该在项目所拥有的资源范围内可以实现
强制特征 需求规格描述的内容应当体现强制性，即需求规格描述的内容的任何一项缺失，都会导致最终产品不能满足客户期望。因此，可选的需求内容要么不要出现，要么以明确的方式标注
可验证特征 需求规格描述应当便于在后期开发过程中进行验证。即实现该需求与否，应该有明确的判断标准
SRS 示例
  1. 引言
  2. 系统定义
  3. 应用环境
  4. 功能规格
  5. 性能需求
  6. 实现约束
  7. 质量描述
  8. 其它要求
  9. 参考材料
  10. 签字认证

对于需求规格模板中的功能规格定义可以用多种方式灵活定义。典型的方式有原型描述、结构化分析方法描述、用例（User Case）描述、可测试需求列表描述等。

团队工程开发：团队设计

团队智慧

发挥团队智慧两大挑战

  1. 确定整体架构之前很难进行分工
  2. 鼓励团队成员在讨论和评审会议中的参与程度

设计标准

  1. 命名规范：项目小组应当设计一个统一的命名规范来命名各个模块并建立系统词典
  2. 接口标准：组件之间的接口标准和格式也需要作为设计标准的内容之一加以定义
  3. 系统出错信息：系统异常信息和出错信息往往也需要通过一个规范加以标准化
  4. 设计表示标准：设计表示标准定义了设计工作的产物应当满足的标准。

复用性支持

  1. 在设计阶段必须要充分考虑复用的可能。为了支持复用，软件项目团队需要建立一套复用管理流程，具体而言，包括
    1. 复用接口标准
    2. 复用文档标准
    3. 复用质量保证机制

可测试性考虑

设计可测试性考虑主要体现在两方面

  1. 要尽可能减少测试代码的数量
  2. 要制作合理的测试计划。

可用性考虑

  1. 可用性的问题应当在设计阶段就开始考虑，而不能推延到实现阶段。
  2. 针对每一个关键功能都定义操作概念和操作场景。
  3. 分析操作场景以确保软件系统开发完成之后，系统使用者会满意。
  4. 必要时，可以邀请最终用户参与场景的评审，使用模拟、原型等技术，更好的把握用户真实意图。

设计的文档化

团队工程开发：实现策略

评审的考虑

  1. 设计的时候采用的策略是自顶向下、逐层精化，这有利于建立系统的整体观，
  2. 实现的时候为了方便对实现结果评审，建议采用自底向上的方式进行，首先实现底层的内容，然后对这些底层的模块进行评审，有利于复用策略的应用。

复用策略

  1. 采用自底向上的开发策略有利于进行复用。
  2. 几个经典的复用策略
    1. 编码注释的应用：编码注释采用统一格式，标明功能，调用方式。异常信息等有利于复用的信息。
    2. 站立式会议：在会上，团队成员可以讨论实现计划，识别可复用组件，了解现有的复用组件库中的内容

可测试性考虑

实现计划必须与测试计划一致，不能出现集体测试的时候部分模块未实现的情况。

团队工程开发：集成策略选择

大爆炸集成策略

  1. 定义：将所有已经完成的组件放在一起进行一次集成
  2. 优点：需要很少的测试用例
  3. 缺点：需要所有有待集成的组件质量非常高，否则会出现难以定位缺陷位置的问题，从而消耗很多测试时间；另外，系统越复杂，规模越大，问题越突出

逐一添加集成策略

  1. 与大爆炸集成策略相反，采取一次添加一个组件的方式进行集成
  2. 优点：很容易定位缺陷位置，特别是在产品组件质量不高的情况下，每次集成之前都有着坚实的质量基础
  3. 缺点：需要测试用例非常多；存在有大量的回归测试，测试时间成本大

集簇集成策略

  1. 定义：是对逐一添加集成策略的改进，把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件，然后以组件为单位继续较高层次的集成
  2. 优点：可以尽早获得一些可以工作的组件，有利于其它组件测试工作的开展
  3. 缺点：过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统层面的缺陷

扁平化集成策略

  1. 定义：优先集成高层的部件，然后逐步将各个组件、模块的真正实现加入系统。即尽快构建一个可以工作的扁平化系统
  2. 优点：可以尽早发现系统层面的缺陷
  3. 缺点：为了确保完成的系统，需要大量的打“桩”（stub），即提供一些直接提供返回值的伪实现。这种方式往往不能覆盖整个系统应该处理的多种状态

团队工程开发：验证与确认 V&V

什么是 V&V?

  1. 验证（Verification)活动也是检验获得的产品和产品组件能不能满足各自事先定义好的需求规格；
  2. 确认（Validation)活动是为了确保产品可以满足客户的需求以及实际操作场景的要求。
  3. 验证（Verification)和确认（Validation)都是为了提升最终产品的质量而采取的措施。

V&V 的区别与联系

  1. 验证和确认的目的不同：
    1. 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求（即产品需求或产品组件需求）一致。
    2. 确认的目的则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确，关注的是客户需求的满足。
  2. 验证和确认又是相互依存、关系紧密的两个活动
    1. 验证活动的依据来源于确认的目标，即产品组件需求必须与客户需求一致。
    2. 验证活动为确认活动提供了前提条件，在完成产品需求和产品组件需求之前，考虑客户需求是否满足是没有意义的。

V&V 的活动

  1. 环境准备
    1. 对于验证工作，如果是评审，则需要准备文件材料、人员以及会议场所等；如果是测试，需要准备模拟器、场景生成程序、环境控制以及其他系统接口等
    2. 对于确认工作，则需要模拟真实环境和场景
  2. 对象选择
    1. 对于验证工作，验证对象往往从工作产品中选择
    2. 对于确认工作，确认对象从产品中选择
  3. 活动实施
    1. 确认工作活动包括早期对产品需求评审工作和最后的验收测试
    2. 验证工作：一般的评审和测试工作
  4. 结果分析
    1. 对于评审结果，可以根据评审结果反思软件开发过程的合理性、以及是否还有隐藏的缺陷
    2. 对于验收测试的结果，则可以关注那些一直遗留到验收阶段才被发现的缺陷，看看这些缺陷在什么阶段被引入，为什么前面未能发现等

V&V 的例子

  1. 单元测试：验证
  2. 集成：验证
  3. 需求评审：确认
  4. 验收测试：确认

团队项目规划：工作分解结构与范围管理

工作分解结构（WBS，Work Breakdown Structure）

  1. 工作分解结构是以可交付成果为导向对满足项目目标和开发交付产物的项目相关工作进行的分解。
    1. 它归纳和定义了项目的整个工作范围。
    2. 每下降一层代表对项目工作的更详细定义。
  2. 作用/特点
    1. 提供了项目范围基线，是范围变更的重要输入。
    2. 可以展现项目整体观，使得项目团队成员可以集中注意力实现项目的目标上。
    3. 为开发项目提供了一个整体框架，防止遗漏项目的可交付成果。
    4. 使得项目中各个角色的责任更明确，帮助项目团队的建立和获得项目成员的承诺。
    5. 为评估和分配任务提供具体的工作包的定义，工作包可以分配给项目某个成员或者另一个团队。
    6. 是进行估算和编制项目日程计划的基础。
    7. 可以帮助项目团队理解工作内容，分析项目的风险。
  3. 表示方式
    1. 树型层次结构
    2. 清单型层次结构
创建 WBS
  1. 将复杂的项目逐步分解为一系列明确定义的工作任务并作为随后计划活动的指导文档。
  2. 要将整个项目分解成工作包：
    1. 识别和分析可交付成果以及相关工作。
    2. 确定工作分解结构的结构与编排方法。
    3. 自上而下逐层细化分解。
    4. 为工作分解结构组成部分制定和分配标志编码。
    5. 核实工作分解的程度是必要且充分的。
好的 WBS 的检查标准
  1. 最底层要素不能重复，即任何一个工作应该在 WBS 中的一个地方且只应该在 WBS 中的一个地方出现。
  2. 所有要素必须清晰完整定义，即相应的数据词典必须完整定义。
  3. 最底层要素必须有定义清晰的责任人，可以支持成本估算和进度安排。
  4. 最底层要素是实现目标的成分必要条件，即项目的工作范围得到完整体现。

范围管理

  1. 包括确保项目做且只做成功完成项目所需的全部工作的各过程。
  2. WBS 为范围管理提供了基础
    1. 收集需求
    2. 定义范围
    3. 创建 WBS
    4. 核实范围
    5. 控制范围变更

团队项目规划：开发策略与计划

  1. 定义：是在产品组件需求基础之上，明确每个产品组件的获得方式与顺序，从而在项目团队内部建立起大家都理解的产品开发策略
  2. 注意事项：
    1. WBS 的使用
    2. 产品组件开发顺序的考虑
    3. 产品组件获得方式的考虑

团队项目规划：生命周期模型选择

  1. 生命周期模型的各个阶段
    1. 项目启动阶段
    2. 项目策划阶段
    3. 需求开发阶段
    4. 技术实现阶段
    5. 集成与测试阶段
    6. 交付与维护阶段
    7. 项目总结

团队项目规划：计划

日程计划原理和方法

任务计划和日程计划
  1. 任务计划描述了项目所有的任务清单，任务之间的先后顺序以及每个任务所需时间资源。
  2. 日程计划描述了每个任务在日志上的安排，即每个任务计划哪天开始和计划哪天结束。
  3. 制定资源计划，结合任务计划就可以定义日程计划
  4. 团队形式的日程计划考虑
    1. 资源平衡：要求项目团队结合每个团队成员的工作效率、工作内容以及资源水平，找到一个时间点，让所有团队成员几乎同时完成任务
    2. 资源同步：安排日程时必须兼顾某些项目人物之间的依赖关系。
典型计划流程回顾
  1. 估算规模
  2. 估算资源
  3. 规划日程

质量计划原理和方法

  1. 项目的质量计划中应当确定需要开展的质量保证活动。
  2. 典型的质量保证活动包括了个人评审、团队评审、单元测试、集成测试以及验收测试等。
  3. 在质量计划中需要解决的关键问题是该开展哪些活动，以及这些活动开展的程度，如时间、人数和目标是什么。

风险计划

  1. 风险管理的目标是：在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。
  2. 风险管理是一个持续的、前瞻的过程，此过程是项目管理的重要部分。有效的风险管理是通过相关干系人的合作与参与，尽快且积极地识别风险，指定项目风险管理计划。
    1. 风险管理需要同时考虑有关成本、进度、绩效以及其他风险的内部及外部来源。
    2. 在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低且较不具破坏性。
    3. 早期且积极的风险侦测是重要的。
  3. 风险管理大致分为两部分，即风险识别和风险应对。
  4. 早期风险侦测的重要性：在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低及较不具破坏性。
风险识别
  1. 风险：没有发生，有一定概率会发生，发生后有一定影响
  2. 问题：已经发生的，比如人员调动等。
  3. 典型的识别方法
    1. 检查 WBS 的每个组件以找出相应的风险
    2. 使用定义好的风险分类表上来评估风险
    3. 访谈相关的领域专家
    4. 与类似项目进行比较来审查风险管理
    5. 检查以往项目的总结报告或组织级数据库
    6. 检查设计规格和协议书需求。
  4. 典型的风险识别活动包括
    1. 识别与成本、进度及绩效相关的风险
    2. 审查可能影响项目的环境因素
    3. 审查工作分解结构的所有组件，作为风险识别的一部分，以协助确保所有的工作投入均已考虑
    4. 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑
    5. 记录风险的内容、条件及可能的结果
    6. 识别每一风险相关的干系人
    7. 利用已定义的风险参数，评估已识别的风险
    8. 依照定义的风险类别，将风险分类并分组
    9. 排列降低风险的优先级
      1. 可能性很低，但是发生影响程度很大：政策变化、领导层大规模变动、公司倒闭
      2. [P（可能性）, I（影响程度）, T（阈值）]
风险应对
  1. 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险
  2. 典型的策略包括
    1. 风险转嫁
      1. 指通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织。
      2. 比如有的公司采取外包的方式，把一部分有技术风险的产品组建交由其他公司开发，在放弃部分收益的同时，也规避了技术风险。
    2. 风险解决
      1. 指采用一些有效措施，使得风险的来源不再存在。
      2. 这往往是一种预防性的手段，比如针对项目面临的技术风险，采取技术调研或者引进技术专家的手段，使得原有的风险来源不再存在或者存在可能性极低，从而测试解决该风险。
    3. 风险缓解
      1. 指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响。
        1. 一般情况下，都需要指定相应的风险缓解计划：理性对待每个关键性的风险，研究可选择的应对方案，并对每个风险皆制定相应的行动过程，是风险缓解计划的关键内容。
        2. 特定风险的风险缓解计划包括规避、降低及控制风险发生可能性的技术和方法，或降低风险法身时遭受的损失程度的方法，或上述两者。
      2. 监控风险：
        1. 当风险超过设定的阈值时，实施风险缓解计划，以使受冲击的部分回归到可接受的风险等级。
        2. 只有当风险结果评定为高或者无法接受时，才相应指定风险缓解计划和紧急应对计划，其他情况只需要适当监控即可。

计划评审与各方承诺

  1. 项目各项计划完成之后，需要与各类计划的相关干系人开展评审工作，解决工作中相互矛盾与不一致的地方，并获得参与项目的各方对项目计划的承诺。
    1. 识别每一项计划所需支持，并与相关干系人协商承诺。
    2. 记录所有的承诺，包括完整的承诺和临时的承诺，并确保由适当层次的人员签署。
    3. 适当与资深管理人员一起审查承诺。

团队项目规划：TSP 项目启动

TSP 的九次会议

  • 几个认识
    • 错误的认识：软件开发阶段理解为注入缺陷的阶段，软件测试阶段理解为消除缺陷的阶段。
    • 正确的认识：开发和测试都是既有可能引入缺陷，也有可能消除缺陷的阶段
  • 项目完成的实际时间由什么决定？最晚完成的工作的人决定的
  • 经过平衡的计划和没有平衡的计划有什么不一样？更有把握去成功。

团队项目跟踪与分析

项目跟踪意义

  1. 在项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展和计划产生严重偏差时，可采取适当的纠正措施。
    1. 项目进度滞后与是否需要参照物，即项目计划。
    2. 项目跟踪需要管理偏差而采取的纠偏措施。
  2. 团队项目的跟踪与管理主要包括进度的跟踪（利用不同跟踪方法，例如挣值管理、里程碑评审）、纠偏活动管理

项目的挣值管理方法（EVM，Earned Value Managerment)

什么是 EVM？
  1. 项目的挣值管理方法是用来客观度量项目进度的一种项目管理方法。
    1. 每项任务实现附以一定价值（credit）
    2. 100%完成该项任务，就获得相应的价值。
  2. EVM 采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。
挣值管理实现
  1. 简单实现：仅仅关注进度信息。
    1. 实现方式
      1. 首先需要建立 WBS，定义工作范围
      2. 其次为 WBS 中每一项工作定义一个计划价值（PV, Planned Value）
      3. 最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作，该值成为挣值（EV, Earned Value)
    2. 常用规则
      1. 0-100 原则：只有当某项任务完成时，该任务的 PV 值将转化成 EV 值
      2. 50-50 原则：只需要开始某项任务，即可以赋原 PV 值的 50%作为 EV 值，完成时，再加上另外的 50%
      3. 实际完成的工作所需成本 AC 不对 EV 值产生任何影响
  2. 中级实现
    1. 在简单实现的基础上，加入日程偏差的计算，加入了成本线（AC)
    2. 典型计算方式有
      1. 日程偏差 SV = EV – PV
      2. 日程偏差指数 SPI = EV/PV；
  3. 高级实现：添加预测线（BAC），当任务足够多的时候，我们就可以让预测线尽可能平直，同时我们延伸挣值（EV），找到与预测线（BAC）的交点，我们就可以明确项目的落后时间
挣值管理图解

  1. 上面的线是为了获取这些挣值付出的实际代价，这个线和挣值之间的差异是成本差异。
  2. 中间的线是预算（每天需要完成多少挣值）BAC，理想情况下是一条直线。
  3. 下面的线是挣值（实际的进展情况）（EV），和 owner value 有关，对应 plan value
  4. 实际获取挣值和预计获取挣值的差异是进度差异。
  5. 例子：
    1. 一共 100 个值（计划投入时间），第一天需要完成 50 个值，第二天需要完成 20 个值，第三天需要完成 30 个值。
    2. BAC：第一天 50，第二天 70，第三天 100.
    3. 超期情况，EV：第二天 50 值，AC：第二天 100 值。
      1. 这就意味这这两天投入了 100 个值完成了原计划用 50 个值完成的工作，这就对应着进度落后，成本超支。
      2. CV = 50，SV = 20
    4. 有可能出现第二天用户说，任务 B 和任务 C 不做了（项目进度落后变为了项目进度正常）
  6. 挣值管理会带来什么好处？可以很好的适应项目的动态变化。
挣值管理的度量
  1. BAC 表示按照 PV 值的曲线，当项目完成的时候所需预算或者时间
  2. 成本差异 CV = EV-AC，表示的是已经完成的工作与所消耗的成本的差异。可以表示为消耗的时间，也可以表示为消耗的资金。
  3. 成本差异指数 CPI = EV/AC，表示单位成本创造的价值
    1. CPI<1 说明成本超支
    2. CPI=1 说明成本与预期一致
    3. CPI>1 说明成本低于预期。
  4. 日程偏差 SV = EV – PV，表示进度偏差。
    1. SV<0 表示进度落后；SV=0 表示进度正常
    2. SV>0 表示进度超前。
  5. 日程偏差指数 SPI = EV/PV
  6. 预计完成成本 EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展已经成本消耗情况，整个项目完成的时候所需消耗的成本。
挣值管理的应用
  1. 发现项目已经滞后
    1. 削减功能，使得已经完成的任务的 EV 值增加
    2. 通过加班或加人等手段，有效提升获取 EV 值的速度
  2. 见课本 126 页相关例子
    1. EV 值显示的项目落后可能是假象
    2. 分析例子
挣值管理的局限性
  1. 一般不能应用软件项目的质量管理。
  2. 需要定量化的管理机制，这就使得在一些探索型项目以及常用的敏捷开发方法中的应用受到限制。
  3. 完全依赖项目的准确估算，然而在项目早期，很难对项目进行非常准确的估算。
另一种挣值管理变形：燃尽图

  1. 燃尽图是简单的挣值管理的变形。
  2. 他是剩下的工作占的百分比。

里程碑评审

  1. 软件项目的里程碑往往是指某个时间点，用以标记某些工作的完成或者阶段的结束。
    1. 典型的里程碑事件：
      1. 完成某项工作
      2. 获得干系人签字认可
      3. 完成某产物的评审
      4. 修改或交付某产物
  2. 里程碑评审的审查内容包括：
    1. 项目相关的承诺，如日期、规格、质量等等；
    2. 项目各项计划的执行状况；
    3. 项目当前的状态讨论；
    4. 项目面临的风险讨论等
  3. 里程碑评审也可用于质量管理

其他类型跟踪方法

  1. 日程计划跟踪
  2. 承诺计划跟踪
  3. 风险计划跟踪
  4. 数据收集计划跟踪
  5. 沟通计划跟踪

纠偏活动的管理

典型的纠偏活动包括：偏差原因分析、纠偏措施定义、纠偏措施管理

  1. 偏差原因分析：收集偏差相关的各种信息，基于收集到的信息，开展充分的分析工作，找出偏差的根本原因。
  2. 纠偏措施定义：确认偏差的根本原因，就可以有针对性地定义纠偏的措施。
  3. 纠偏措施管理：管理纠偏措施直到结项。

项目审查

审查的内容包括

  1. 项目相关的承诺，如日期、规格、质量等等。
  2. 项目各项计划的执行状况。
  3. 项目当前的状态讨论
  4. 项目面临的风险讨论
  5. 其他计划跟踪
  6. 日程计划跟踪
  7. 承诺计划跟踪
  8. 风险计划跟踪
  9. 数据收集计划跟踪
  10. 沟通计划跟踪

项目总结

项目总结的定义

  1. 项目总结需要系统化有条理的进行，才能不遗漏重要的内容。
  2. 因此往往需要事先定义总结过程，然后就按部就班地开展总结工作。

一般项目总结流程

基于 PMBOK 的总结方式，包含范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整合管理 9 大知识领域（每个领域具体内容见 Lec-4)

  1. 项目范围包括产品范围和项目范围。对项目范围管理的总结应当主要关注项目的需求开发过程与变更管理中的得失，对需求管理实际执行情况的差距进行原因分析，找到改进的机会。
  2. 时间管理所关注的就是项目的日程计划以及对日程计划的跟踪和管理状况。因此主要考察计划的准确程度以及各个里程碑的偏差情况。
  3. 成本管理包括对成本进行估算、预算和控制的各个过程，从而确保项目在批准的预算内完工
  4. 质量管理包括执行组织确定质量政策、目标与职责的各过程和活动，从而使项目满足其预定的需求。
  5. 人力资源管理包括组织、管理与领导项目团队的各个过程。
  6. 沟通管理包括为确保项目信息及时且恰当地生成、收集、发布、存储、调用最终处置所需的各个过程
  7. 风险管理包括风险管理规划、风险识别、风险分析、风险应对规划和风险监控等各个过程。
  8. 采购管理包括从项目组织外部采购或获得所需产品、服务或成果的各个过程。
  9. 整合管理包括为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动

TSP 项目总结方式

  1. 准备阶段
  2. 过程数据评审阶段：该阶段往往由过程经理或者质量经理带领整个团队分析过程数据，识别过程改进机会。
    1. 可以结合典型 TSP 团队角色，逐个讨论改进领域。如团队领导力、计划准确性、过程优劣、质量管理能力、开发环境以及配置管理等。
    2. 此外，也可以就 TSP 教练的作用进行评价。
    3. 过程数据评审阶段还要求开发团队的所有成员都整理过程改进提案（PIP）：PIP 是 TSP 过程中供开发人员在日程工作中记录改进想法的工具。其基本思想是积累小的改进，慢慢形成大的改进。在软件开发过程中，重大的改进机会不多，因此，往往需要从小做起，慢慢积累之后，就会形成对原有过程的显著改进。小的改进机会虽然多，但是容易被遗忘，PIP 的作用就在于提供了一个标准表格工具，允许软件工程师时时记录改进方案。在项目总结阶段，将开发过程中记录的所有 PIP 整理出来，形成整个开发周期的过程改进提案，供讨论，以确定下个开发周期要实施的过程改进。
  3. 人员角色评价阶段（角色包括项目组长、计划经理、开发经理、质量经理、过程经理和支持经理）：详见 Lec-4
  4. 总结报告撰写阶段

通用项目总结流程

  1. 准备阶段
  2. 总结阶段
  3. 报告阶段

项目总结的意义

提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等，给项目团队成员持续学习和改进的机会。

项目管理支持活动

  1. 项目管理支持活动包含：配置管理、度量和分析、决策分析和根因分析。

配置管理

配置管理的目的

建立与维护工作产品的完整性

配置管理的概念
  1. 配置项：
    1. 在配置管理当中作为单独实体进行管理和控制的工作产品集合
    2. 典型的可能作为配置项纳入配置管理的工作产品包含过程说明文档、项目开发计划文档、需求规格说明书、设计规格说明书、设计图表、产品规格说明书、程序代码、开发环境，如特定版本的编译器等、产品数据文件、产品技术文件、用户支持文档
  2. 基线：基线是一个或多个配置项及相关的标识符的代表，是一组经正式审查同意的规格或工作产品集合，是未来开发工作或交付的基础，而且只能经由严格的变更控制程序才能改变。
    1. 发布一个基线包括该基线所有的配置项以及这些配置项的最新变更，因此，可以将基线作为接下来工作的基础。
    2. 典型的发布基线时间点为需求分析之后、设计完成之后、单元测试之后以及最终产品发布。
    3. 是配置项持续演进的稳定基础
配置管理的流程

配置管理是用管理的手段监督和指导如下工作的流程[CMMI 2006]

  1. 识别和记录配置项的物理特性和功能特性
  2. 控制上述特性的变更；
  3. 记录和报告变更过程和相应的配置项状态
  4. 验证配置项是否与需求一致
配置管理活动
  1. 识别配置项
  2. 建立配置管理系统
  3. 创建和发布基线
  4. 跟踪变更请求
  5. 控制配置项变更
  6. 建立配置管理记录
  7. 配置审计

配置管理各个活动之间的关系

度量和分析

度量和分析简介
  1. 意义：在软件项目管理决策的过程中，基于客观的数据很重要，这种客观决策可以显著消除错误决策的风险。而这些客观数据的获得，必须依照一定的流程以正确的方式获得和使用。度量和分析活动就定义了上述客观数据的获取与使用方式。
  2. 目的：建立与维持度量能力，以支持管理的信息需要。
度量和分析活动
  1. 建立度量目标
  2. 指定度量方式
  3. 指定数据收集和保存的流程
  4. 指定分析流程
  5. 收集度量数据
  6. 分析度量数据
  7. 保存数据和结果
  8. 交流度量结果

活动组成就是 8 个圆圈内的内容

GQM 方法的原理和应用
  1. GQM(Goal Question Metric)是一种应用非常广泛的建立软件度量体系的方法，从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼成可以测量的值，是一种科学的、系统的思考问题的方式。
    1. 概念层（目标）：目标是为某个特定的对象而定义的。这里的对象是指软件产品、软件过程以及相关的资源等。定义的目标基于不同原因和不同质量模型,也要参考不同的角色视图与特定的环境。
    2. 操作层（问题）：基于一定的刻画上述目标是否达成或者目标达成的进展情况的模型，使用一系列的问题来定义所研究的对象, 然后得出评价或评估特定目标达成进展情况。所选择的问题应当尽量体现质量相关的话题。
    3. 量化层（度量）：试图以量化的方式回答上述操作层识别出来的问题。
  2. 示例：
    1. 例子一：PM
      1. G：确保稳定性、可预测性的开发过程来满足计划的里程碑
      2. Q：我的项目是否按照计划的轨迹前进，计划的里程碑都能实现嘛？
      3. M：软件项目开发工作的挥发性（分支、流、统计变更管理 UCM 活动）
    2. 例子二：QM
      1. G：最大化所有团队贡献者的生产力
      2. Q：开发人员能够完成分配给他们的任务吗，或者他们遇到障碍了吗？
      3. M：由个体或者工作组产生的项目工作的量级
    3. 详见课本 153-155 页

决策分析

根因分析

  1. 避免类似错误反复发生
  2. 一个正式根因分析过程往往包含下列的活动：
    1. 识别和选定问题
    2. 根因分析
    3. 建立改进的行动方案
    4. 实施改进，评估效果

团队动力学

  1. 软件开发的特点
    1. 软件开发是一项既复杂又富有创造性的知识工作。
    2. 软件开发：智力劳动，需要处理和讨论极其抽象的概念，并把不同的部分（不可见）整合成一个可以工作的系统。
      1. 要求从事软件开发的工程师
        1. 必须全身心地参与工作：知识工作必须是全身心投入的，任务切换一般需要 30 分钟才能全身心的投入。
        2. 主观意愿上努力追求卓越。
      2. 要求管理者激励并维持激励
        1. 激励手段
        2. 维持激励手段
  2. 管理知识工作的关键规则是：管理者无法管理工作者，知识工作者必须实现并学会自我管理
    1. 要自我管理，知识工作者必须（自我管理的前提条件）
      1. 有积极性
      2. 能做出准确的估算和计划
      3. 懂得协商承诺
      4. 有效跟踪他们的计划
      5. 持续地按计划交付高质量产品。
    2. 知识工作者实现自我管理：胶冻状团队。
  3. 知识工作者的管理需要的是领导者，而不是经理，领导者需要诚实、有能力、有远见、鼓舞人心。

自主团队

团队定义

一个团队必须包括至少两个成员，他们为了共同的目标和愿景而努力工作，他们每个人都有明确的角色和相应的职责定义，任务的完成需要团队成员互相依赖和支持。

自主团队的含义

软件工程师所从事的工作一般称之为复杂的知识工作。在这种性质的工作中，实现软件工程师的自我管理往往可以获得最好的工作效率和质量水平。如果整个团队的所有成员都实现了自我管理，也就形成了所谓的自主团队。

自主团队的特点
  1. 自行定义项目的目标
  2. 自行决定团队组成形式以及成员的角色
  3. 自行决定项目的开发策略
  4. 自行决定项目的开发过程
  5. 自行制定项目的开发计划
  6. 自行度量、管理和控制项目工作
自主团队的必要性
  1. 自主团队可以形成“胶冻态团队”。在这样的团队中存在一种神奇的力量，这种神奇力量弥漫于该团队做的所有工作
  2. 团队成员互相支持，更为重要的是，团队成员在任何时刻都知道应该以怎样的方式帮助别人;团队成员相互信任，有强烈的归属感
  3. 团队在适当的知道会聚集在一起，研究现状，讨论策略。
自主团队的形成
  1. 自主团队不是偶然形成的。
  2. 大部分情况下，在团队建立之初，团队成员往往有着不同的目标;缺乏清晰的角色定义和职责安排。对于待开发的产品只有模糊的概念;团队成员也有着不同的工作习惯和工作方法。
  3. 经过一段时间的协同工作，团队成员可以慢慢培养团队协作方式，从而逐渐演化成自主团队。
自主团队的外部环境
  1. 项目启动阶段获得管理层的支持
    1. 项目小组应当表现出已经尽最大的可能在满足管理层的需求的工作态度。
    2. 项目小组应当在计划中体现定期需要向管理层报告的内容。
    3. 项目小组应当向管理层证明他们所制定的工作计划是合理的。
    4. 项目小组应当在项目中体现为了追求高质量而开展的工作。
    5. 项目小组应当在工作计划中允许必要的项目变更。
    6. 项目小组应当向管理层寻求必要的帮助。
  2. 在项目进展过程中获得管理层的支持
    1. 项目小组应当严格遵循定义好的开发过程开展项目开发过程。
    2. 项目小组应当维护和更新项目成员的个人计划和团队计划。
    3. 项目小组应当对产品质量进行管理。
    4. 项目小组应当跟踪项目进展，并定期向管理层报告。
    5. 项目小组应当持续地向管理层展现优异的项目表现。

激励方式

  1. 威逼：完全依靠不同角色的等级关系，通常是上级强制要求下属必须完成某些工作。
  2. 利诱：通过许诺一定的好处来吸引下属努力工作
  3. 鼓励承诺：
    1. 建立承诺文化，利用软件工程师希望得到别人尊重的心理，鼓励他们合理承诺并努力满足承诺，从而得到别人的尊重。
    2. 位于马斯洛需求理论的 4 级以上，应当是主要的方式，并且最好以团队为单位做出承诺
交易型领导方式
  1. 承诺奖励激励
  2. 人们通常能找到新的方式来获得奖励，同时少做工作。
  3. 威逼和利诱属于交易型领导方式。
转变型领导方式
  1. 用成就激励
  2. 鼓励承诺属于转变型领导方式。
  3. 由于交易型领导方式很少能产生成功并且有创造性的团队，因此转变型领导方式是首选。

马斯洛的需求层次理论

  1. 五个层次：生理需求（Physiological)、安全感（Safety)、爱和归属感（social)、获得尊敬（Esteem)、自我实现（Self-Actualization)
  2. 注意
    1. 自我实现是最高的层次。
    2. 激励来自为没有满足的需求而努力奋斗。
    3. 低层次的需求必须在高层次需求满足之前得到充分满足。
    4. 满足高层次的需求的途径比满足低层次的途径更为广泛。
  3. 威逼利诱比较低层，鼓励承诺在 4-5 层，效果比较好

承诺文化的建立与团队激励

  1. 在个人级别，承诺有很大差异
    1. 有些人对承诺非常认真
    2. 有些人对承诺非常轻率。
  2. 在满足以下条件下，团队承诺比个人承诺的激励作用更大
    1. 所有团队成员共同参与作出承诺。
    2. 团队依赖于每一位成员履行自己的承诺。
    3. 如果有计划在支撑承诺，那么就更为可信
  3. 软件开发团队在制定承诺时
    1. 需要保证承诺是自愿的、公开的、可信（行）的，向团队做出承诺。
    2. 承诺需要有详细计划支撑
    3. 开发者需要参与承诺的协商和设计。
  4. 除了以团队形式作出承诺以外，承诺文化的建立还要求在项目进行过程中维持承诺水平。
    1. 及时提供各种反馈信息是维持承诺的有效手段。
    2. 反馈信息包括项目进度、更新后的项目计划以及里程碑实现情况等。
  5. leader 和 manager 的区别

  1. 维持激励需要及时的绩效反馈
    1. 绩效反馈包括
      1. 根据一个详细计划衡量进度。
      2. 当前计划不准确时重做计划，想想为什么？
      3. 为漫长而富有挑战性的项目提供中间反馈，即里程碑，想想为什么？
    2. 激励水平的重要影响因素
      1. 回报：回报越大，激励水平越高
      2. 期望：完成这件事情的把握越大，激励水平越高
海兹伯格的激励理论
  1. 激励因素（内在因素）：成就感、责任感、晋升、被赏识、认可。
  2. 保健因素（外在因素）：工作环境、薪金、工作关系、安全等。
麦克勒格的 X、Y－理论
  1. 麦克勒格的 X－理论：人性本恶，独裁式的管理风格
    1. 不喜欢他们的工作并努力逃避工作
    2. 缺乏进取心，没有解决问题与创造的能力
    3. 更喜欢经常的指导，避免承担责任，缺乏主动性
    4. 自我中心，对组织需求反应淡漠，反对变革
    5. 用马斯洛的底层需求（生理和安全）进行激励
  2. 麦克勒格的 Y-理论：人性本善，民主式的管理风格
    1. 如果给予适当的激励和支持性的工作氛围，会达到很高的绩效预期
    2. 具有创造力，想象力，雄心和信心来实现组织目标
    3. 能够自我约束，自我导向与控制，渴望承担责任
    4. 用马斯洛的高层需求（自尊和自我实现）进行激励
期望理论 Expectancy Theory
  1. 人们在下列情况下能够收到激励并且产生出大量成果 M = V  E
    1. 相信他们的努力很可能会产生成功的结果（V）
    2. 相信自己因为成功而得到相应的回报（E）
  2. Motivation = Valence x Expectancy(Instrumentality)，即激发力量 = 效价 X 期望值
    1. M 表示激发力量，是指调动一个人的积极性，激发人内部潜力的强度。
    2. V 表示目标价值（效价），这是一个心理学概念，是指达到目标对于满足他个人需要的价值。同一目标，由于各个人所处的环境不同，需求不同，其需要的目标价值也就不同。同一个目标对每一个人可能有三种效价：正、零、负。效价越高，激励力量就越大
    3. E 是期望值，是人们根据过去经验判断自己达到某种目标的可能性是大还是小，即能够达到目标的概率。目标价值大小直接反映人的需要动机强弱，期望概率反映人实现需要和动机的信心强弱。
提高成功把握的两种方法
  1. 现实扭曲力场（乔布斯传）
  2. 数据

TSP 的典型角色

项目组长

项目组长的目标和衡量指标

  1. 项目组长应当建设和维持高效率的团队。
  2. 项目组长应当激励团队成员积极工作。
  3. 项目组长应当合理处理团队成员的问题。
  4. 项目组长应当向管理层提供项目进度相关的完整信息。
  5. 项目组长应当充当合格的会议组织者和协调者。
典型技能
  1. 你是天生的领导者
  2. 你有能力识别问题的关键并且做出客观的决策
  3. 你不介意偶尔充当“恶人”
  4. 你尊敬你的团队成员
工作内容
  1. 激励团队成员努力工作
  2. 主持项目周例会
  3. 每周汇报项目状态
  4. 分配工作任务
  5. 维护项目资料
  6. 组织项目总结

计划经理

  1. 开发完整的、准确的团队计划和个人计划
  2. 每周准确的报告项目小组状态
典型技能
  1. 最为重要的一点是，你做事有条理和逻辑
  2. 你对于过程数据非常感兴趣，期待通过每周输入的数据来了解项目当前状况
  3. 你认为计划非常重要，也愿意要求团队成员跟踪和度量他们的工作
工作内容
  1. 带领项目小组开发项目计划
  2. 带领项目小组平衡计划
  3. 跟踪项目进度
  4. 参与项目总结

开发经理

  1. 开发优秀的软件产品
  2. 充分利用团队成员的技能
典型技能
  1. 你喜欢创造事物
  2. 你愿意成为软件工程师，并且喜欢带领团队开展设计和开发工作
  3. 你具备足够的背景可以胜任设计师的工作，并且可以领导设计团队开展工作
  4. 你熟悉主流的设计工具
  5. 你愿意倾听和接受其他人的设计思想
工作内容
  1. 带领团队制定开发策略。
  2. 带领团队开展产品规模估算和所需时间资源的估算。
  3. 带领团队开发需求规格说明。
  4. 带领团队开发高层设计。
  5. 带领团队开发设计规格说明。
  6. 带领团队实现软件产品。
  7. 带领团队开展集成测试和系统测试。
  8. 带领团队开发用户支持文档。
  9. 参与项目总结

质量经理

  1. 项目团队严格按照质量计划开展工作，开发出高质量的软件产品
  2. 所有的小组评审工作都正常开展，并且都形成了评审报告
典型技能
  1. 你关注软件产品的质量
  2. 你有评审方面的经验，熟悉各种评审方法
  3. 你有协调组织有效评审的能力
工作内容
  1. 带领团队开发和跟踪质量计划
  2. 向项目组长警示质量问题
  3. 软件产品提交配置管理之前，对其进行评审，以消除质量问题
  4. 项目小组评审的组织者和协调者
  5. 参与项目总结

过程经理

  1. 所有团队成员准确的记录、报告和跟踪过程数据。
  2. 所有的团队会议都有相应会议记录。
典型技能
  1. 你对过程定义、过程度量非常感兴趣
  2. 你对过程改进非常感兴趣
工作内容
  1. 带领团队定义和记录开发过程并且支持过程改进。
  2. 建立和维护团队的开发标准。
  3. 记录和维护项目的会议记录。
  4. 参与项目总结。

支持经理

  1. 项目小组在整个开发过程中都有合适的工具和环境
  2. 对于基线产品，不存在非授权的变更
  3. 项目小组的风险和问题得到跟踪
  4. 项目小组在开发过程中满足复用目标
典型技能
  1. 你对于各种开发工具很感兴趣，熟悉各类工具的适用场合。
  2. 你对版本控制工具很熟悉，也熟悉配置管理流程。
  3. 对于本项目所有工具而言，你都是专家。
工作内容
  1. 带领团队识别开发过程中所需要的各类工具和设施。
  2. 主持配置管理委员会，管理配置管理系统。
  3. 维护软件项目的词汇表。
  4. 维护项目风险和问题跟踪系统。
  5. 支持软件开发过程中复用策略的应用。
  6. 参与项目总结。

开发人员

定量管理与仿真建模

高成熟度项目管理

CMMI 模型

一般的项目管理

  1. 主要关心
    1. 当前状况（注意：也可能使用数据）
    2. 是否需要调整干预
  2. 但是，回答不了必须进行预测的问题，例如
    1. 维持现状，项目最后是否能成功？
    2. 如果某些方面进行调整，会有什么不同的结果？

定量的项目管理

  1. 基于数据，主要关心
    1. 你对当前状态理解是否有足够信心？
    2. 对偏差的理解
  2. 回答如下典型问题
    1. 项目最后是否能成功？多大把握？是否需要预防？
    2. 如果某些方面进行调整，会有什么不同的结果？

为什么需要理解偏差

  1. 有的时候，我们会面临这样的问题
  2. 客户希望 10 周以内交付，但是，历史数据表明，类似任务是 9~11 周完成，那这个任务该接受么？

定量管理基本范式

  1. 构建定量模型
    1. 子过程能力基线
    2. 过程模型
  2. 应用模型：监控影响子过程的关键因素

基本概念

  1. （子）过程性能：遵循某个特定（子）过程的之后产生结果的量化描述，既包括（子）过程度量 Xi（例如，时间、缺陷消除效率、工时等），也包括产物度量 Yi（例如，缺陷密度，相应时间等）。
  2. （子）过程性能基线：上述过程性能的一个定量化的刻画，一般包括均值和范围。通常用作过程性能的 benchmark。
  3. 过程或子过程性能模型：依据子过程的逻辑关系构建相应的数学模型，描述子过程性能基线和整体过程有意义的性能输出（例如，质量、生产效率、成本等）之间关系。例如过程 Yield 和 Phase Yield。

定量模型构建的关键实践

  1. 基于 Yield 来构建一个基本的缺陷预测模型，假设
    1. 上述阶段分别为需求开发、需求评审、设计、设计评审、编码、测试；
    2. 需要基于该模型也测最终产出物中有多少个缺陷？
  2. 讨论
    1. 需要补充哪些数据？请设计一个可行的数据获取要求；
    2. 上述数据显然不可能是一个恒定不变的数据，该如何处理？

定量模型应用（定量管理）的关键实践

常用定量管理技术

  1. 定量管理技术通常被分为非统计技术和统计技术，这些技术的使用能够帮助解决软件项目管理中多种问题。

常用非统计技术

  1. 非统计技术一般是为了描述数据集整体特征或者关联关系，从而帮助选择适用的统计技术以应用于给定的数据集，以及调查通过数据分析检测到异常的原因。例如，检查表（或列联表），帕累托图，直方图，因果图，散点图等。
常用非统计技术：直方图
  1. 直方图以频率统计的方式进行显示，可以描述过程属性的频率，例如缺陷修复的时间、每次测试发现的缺陷的个数、每天无故障工作的时间、计算产品的不合格率等。
  2. 一般用于有助于判断过程是否正常，过程能力是否满足需要，不良产品是否发生，分析产品质量问题的原因等。
常用非统计技术：帕累托图
  1. 一种特殊的直方图
  2. 按照由高到低排列的直方图

常用非统计技术：因果图
  1. 因果图是用来分析影响产品质量的各种原因的一种有效的定性的分析图，它将对特性或结果有影响的要素加以分类分析，是一种发现问题根本原因的方法，可以让项目组成员通过头脑风暴、集思广益的方法从各个方面各种不同的角度找出这些问题的所有原因。

常用非统计技术：散布（点）图
  1. 整理和观察收集到的数据的常用图形工具
  2. 散布图表示的是一个变量相对于另一个变量的表现情况，可以假定一个变量是因变量，另一个变量是自变量。散布图通常表现了 5 种相关关系。如图所示的散布图中分别表现了两个变量之间的弱正相关、弱负相关、不相关、强正相关、强负相关。

常用统计技术

  1. 统计思维认识到许多决策是在不确定条件下做出的。统计方法有助于量化这种不确定性并指导采取行动以减少不确定性。
  2. 统计分析支持许多类型的决策，在支持过程管理决策的统计分析中，有效的过程管理通常需要两级决策
    1. 实时控制单个活动或子流程
    2. 根据当前和已完成的活动对未来和最终过程的结果进行预测
  3. 常用的统计技术包括：统计过程控制图，回归分析，方差分析，预测区间，假设检验，敏感性分析等
常用统计技术：控制图
  1. 控制图是根据概率统计原理构造的一种图，用来监测生产过程是否处于控制状态。
  2. 控制图是对过程质量数据测定、记录从而进行质量管理的一种用科学方法设计的图。
  3. 图上有中心线（CL)、上控制限（UCL)和下控制限（LCL)，并有按时间顺序抽取的样本统计量数值的描点序列。

  1. 控制图可由正态分布演变而来
  2. 正态分布可用两个参数即均值 μ 和标准差 σ 来决定。正态分布有一个结论对质量管理很有用，即无论均值 μ 和标准差 σ 取何值，产品质量特性值落在 μ±3σ 之间的概率为 99.73%，落在 μ±3σ 之外的概率为 100%-99.73%=0.27%，而超过一侧，即大于 μ+3σ 或小于 μ-3σ 的概率为 0.27%/2=0.135%≈1‰。

  1. 以下显示了不处于受控状态的 8 种典型情况（异常模式）：
  1. 两类错误（需要检验）：
    1. Ⅰ 类错误：虚发警报错误，在生产正常的情况下,纯粹出于偶然而点子出界的概率虽然很小,但不是绝对不可能发生。故当生产正常而根据点出界判断生产异常就犯了虚发警报错误,发生这种错误的概率通常记以 α
    2. Ⅱ 类错误：漏发警报错误,在生产异常的情况下,产品质量的分布偏离典型分布,但总有一部分产品的质量特性值在上下控制界之内。如果抽到这样的产品进行检测描点,根据点未出界判断生产正常就为漏发警报错误,此概率通常记以 β。