软件质量管理

十大问题

1. 软件过程管理和软件项目管理是不是一回事？两者差异是什么？

2. 软件估算过程中，项目经验/历史数据的作用是什么？

• 如何把项目经验/历史数据转变成估算结果？
• 估算结果经得起时间考验吗？比如隔了 3 个月能否保证估算结果一致？

3. 估算追求的目标是什么？

4. 管理的要素有哪些？如何区分好/坏管理？

5. 什么是软件质量？如何做质量管理？

6. 敏捷是什么？

7. 度量是什么？为什么要度量？

8. 成熟度模型是什么？

9. 定量管理的本质是什么？DevOps 还需要定量管理吗？

10. 关于工程实践，需求分析/设计/测试究竟要解决什么问题？

术语

软件过程管理 SPICE

软件过程改进模型 CMMI PDCA IDEAL

软件过程/开发过程/开发方法

XP SCRUM Cleanroom Gate TSP

软件实践 Waterfall SCRUM XP

软件开发实践

敏捷软件开发

敏捷软件开发宣言的 4 个简单的价值观:

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值

敏捷软件开发方法

1. 特征
   1. 小周期迭代
   2. 快速响应变更
   3. 价值交付
   4. 自动化
2. 以下不适合用于描述敏捷开发方法：
   1. 严格 —— 所有优秀的工程方法和实践都是严格的。
   2. 重型 —— 如上，此外，轻量级和重型其实并没有刻画具体方法，何为重型，并没有严格定义；对于变更这件事情，几乎所有方法都是限制，因此，很难说敏捷方法是轻量级方法。
   3. 计划驱动 —— 所有正式的项目都是计划驱动的，否则计划的作用无法体现

• 极限编程方法 XP
  • 将好的开发实践运用到极致，规定开发人员每周工作时间不超过40小时，连续加班不可以超过2周。
  • 比如客户作为开发团队的成员、短交付周期、结对编程、测试驱动开发(TDD)、持续集成、重构
• Scrum：
  • 3个角色：产品负责人、Scrum Master、开发团队
  • 3个工件：产品订单(优先级、动态)、冲刺订单(细化、冻结)、燃尽图
  • 5个活动：Sprint、Sprint Planning、Sprint Daily Standup、Spring Review、Sprint Retrospective
  • 5个价值观：Coverage(勇气)、Openness(开放)、Focus(专注)、Commitment(承诺)、Respect(尊重)
• KanBan方法
  • 精益生产(丰田制造法)的具体实现
  • 活动：可视化工作流、限制WIP、管理周期时间
• Scrum vs. XP
  • 迭代周期不同：Scrum的迭代周期为2-4周，XP的迭代周期为1-2周
  • 迭代中是否允许需求变更：Scrum迭代中需求冻结，XP只要时间资源相同即可变更。
  • 迭代中是否严格遵守需求优先级：Scrum比较灵活(可能有需求依赖)，XP严格遵守。
  • 过程工程化：Scrum开发过程并未工程化，XP对开发流程严格定义。
• Linus 定律：如果有足够多的beta测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。

软件过程

• 同义词：软件过程、软件开发过程、软件开发方法
• 净室 Clean Room 方法、极限编程方法、Scrum 方法、Gate 方法

生命周期模型

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

软件过程改进模型

软件过程改进模型指导过程改进，不涉及开发的过程。不是软件过程管理。

CMMI

PDCA

• Planning:
  • 分析现状找出问题
  • 分析影响质量的原因
  • 找出措施
  • 拟定措施计划
• Do:
  • 执行措施和计划
• Check:
  • 检查效果发现问题
• Action:
  • 总结经验纳入标准

IDEAL

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

• I: Initiating 初始
• D: Diagnosing 诊断
• E: Establishing 建立
• A: Acting 执行
• L: Leveraging 调整

PSP 个体软件过程

PSP 度量

基本度量项

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

度量选择标准

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

PROBE

PSP 质量观

面向用户的质量观

PSP 中也采用了面向用户的质量观，定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：

1. 用户究竟是谁？
2. 用户需求的优先级是什么？
3. 这种用户的优先级对软件产品的开发过程产生什么样的影响？
4. 怎样来度量这种质量观下的质量水平？

质量路径 Quality Journey

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

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

质量指标

Yield

A/FR

1. A/FR = PSP 质检成本/PSP 失效成本；

2. A/FR控制目标
   1. 理论上，A/FR的值越大，往往意味着越高的质量。
   2. 过高的 A/FR 往往意味着做了过多的评审，反而会导致开发效率的下降。作为指南，在 PSP 中 A/FR 的期望值就是 2.0

PQI

5 个数据乘积

1. 设计质量：设计的时间应该大于编码的时间, min{设计时间/编码时间, 1}
2. 设计评审质量：设计评审的时间应该大于设计时间的 50%，min{(2 * 设计评审时间 / 设计时间), 1}
3. 代码评审质量：代码评审时间应该大于编码时间的 50%，min{(2 * 代码评审时间)/编码时间 , 1}
4. 代码质量：代码的编译缺陷密度应当小于 10 个/千行，min{20/(编译缺陷密度 + 10), 1}
5. 程序质量：代码单元测试缺陷密度应当小于 5 个/千行 min{10/(单元测试缺陷密度 + 5), 1}

Review Rate

1. 评审的速度(Review Rate)是一个用以指导软件工程师开展有效评审的指标
2. 高质量的评审需要软件工程师投入足够的时间进行评审
3. 在PSP的实践中，代码评审速度小于200 LOC/小时，文档评审速度小于4 Page/小时
4. 估算
   1. 估算文档数量
   2. 估算代码数量
   3. 估算评审时间等等

DRL

1. 缺陷消除效率比度量的是不同缺陷消除手段消除缺陷的效率。
2. 其计算方式是以某个测试阶段（一般为单元测试）每小时发现的缺陷数为基础，其他阶段每小时发现缺陷数与该测试阶段每小时发现的缺陷的比值就是 DRL。

PSP 设计

设计内容

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

设计模板

	动态信息	静态信息
外部信息	OST/FST	FST
内部信息	SST	LST

设计验证方法

5.6.6.1. 状态机验证

1. 检查状态机的完整性和正交性
   1. 完整性：对于状态机中任何一个状态，对应的所有条件组合，下一个状态的转换都有定义。
   2. 正交性：对于状态机中任何一个状态，其所有下一个状态的转换条件都不能相同。
2. 验证步骤
   1. 检查状态机，消除死循环和陷阱状态
   2. 检查状态转换，验证完整性和正交性
   3. 评价状态机，检验是否体现设计意图

TSP 团队软件过程

TSP 提供了

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

团队工程开发：需求开发

需求开发包含需求获取、需求汇总、需求验证、需求文档制作

需求分类

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

团队工程开发：团队设计

集成策略

验证与确认 V&V

什么是 V&V?

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

生命周期模型选择

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

计划

风险应对

1. 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险
2. 典型的策略包括
   1. 风险转嫁
      1. 指通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织。
      2. 比如有的公司采取外包的方式，把一部分有技术风险的产品组建交由其他公司开发，在放弃部分收益的同时，也规避了技术风险。
   2. 风险解决
      1. 指采用一些有效措施，使得风险的来源不再存在。
      2. 这往往是一种预防性的手段，比如针对项目面临的技术风险，采取技术调研或者引进技术专家的手段，使得原有的风险来源不再存在或者存在可能性极低，从而测试解决该风险。
   3. 风险缓解
      1. 指容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响。
         1. 一般情况下，都需要指定相应的风险缓解计划：理性对待每个关键性的风险，研究可选择的应对方案，并对每个风险皆制定相应的行动过程，是风险缓解计划的关键内容。
         2. 特定风险的风险缓解计划包括规避、降低及控制风险发生可能性的技术和方法，或降低风险法身时遭受的损失程度的方法，或上述两者。
      2. 监控风险：
         1. 当风险超过设定的阈值时，实施风险缓解计划，以使受冲击的部分回归到可接受的风险等级。
         2. 只有当风险结果评定为高或者无法接受时，才相应指定风险缓解计划和紧急应对计划，其他情况只需要适当监控即可。

通用计划框架 & 全流程

如何制定一份让人无法拒绝的计划，请描述基本步骤和一些注意事项 10’

1. 制定任务计划和日程计划：前者描述项目所有的任务清单，任务之间的先后顺序、以及每个任务所需时间资源，后者描述了各个任务在日程上的安排，哪天开始哪天结束;
2. 制定资源计划
3. 这种⽇程计划的关键是必须⽤正推的⽅式来制订项⽬计划。⼀个典型的项⽬计划框架如下图
4. 在这个过程中，除了概要设计之外，其他环节尽可能⾃动化完成。充分参考历史数据进⾏估算。

TSP 项目启动

TSP 的九次会议

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

团队项目跟踪与分析

挣值管理

EVM，Earned Value Managerment

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. 在简单实现的基础上，加入日程偏差的计算，加入了 PV
   2. 典型计算方式有
      1. 日程偏差 SV = EV – PV
      2. 日程偏差指数 SPI = EV/PV；
3. 高级实现：添加实际成本 AC

配置管理

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

团队动力学

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. 自行度量、管理和控制项目工作

TSP 典型角色

项目组长

1. 项目组长应当建设和维持高效率的团队。
2. 项目组长应当激励团队成员积极工作。
3. 项目组长应当合理处理团队成员的问题。
4. 项目组长应当向管理层提供项目进度相关的完整信息。
5. 项目组长应当充当合格的会议组织者和协调者。

计划经理

1. 开发完整的、准确的团队计划和个人计划
2. 每周准确的报告项目小组状态

开发经理

1. 开发优秀的软件产品
2. 充分利用团队成员的技能

质量经理

1. 项目团队严格按照质量计划开展工作，开发出高质量的软件产品
2. 所有的小组评审工作都正常开展，并且都形成了评审报告

过程经理

1. 所有团队成员准确的记录、报告和跟踪过程数据。
2. 所有的团队会议都有相应会议记录。

支持经理

1. 项目小组在整个开发过程中都有合适的工具和环境
2. 对于基线产品，不存在非授权的变更
3. 项目小组的风险和问题得到跟踪
4. 项目小组在开发过程中满足复用目标

开发人员