第一节 质量管理基本策略
为什么要了解并且掌握个体软件过程（PSP）
DevOps"开发在前，运维在后"
高质量开发对于价值流动的意义—The Three Ways
个体软件工程师的技能、过程直接影响产物质量
PSP是极少数专注于提升个体软件工程师工程技能的方法
为什么在DevOps语境之下，仍然需要关注PSP？ 下属说法中正确的有哪些？
A.这是提升开发质量，确保价值顺畅流动得看需要
B.软件开发是有系统可以运维的前提
C.不学习PSP，就不知道应该如果开发软件
D.个体软件工程师的开发对最终产品乃至整个系统的质量至关重要
正确答案：A、B、D你选对了
质量是什么？
软件质量为“与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体”。[ANSI/IEEE STd 729]
软件质量为内外两部分的特性：其外部质量特性面向软件产品的最终用户，其内部质量特性则不直接面向最终用户。《代码大全》
软件质量为软件产品可以改变世界，使世界更加美好的程度。从用户的角度考察软件质量，用户满意度是最为重要的判断标准。
[Tom Demarco]
软件质量为对人（用户）的价值。这一定义强调了质量的主观性即对同一款软件而言，不同的用户对其质量有不同的体验。
[Gerald Weinberg]
面向用户的质量观
定义质量为满足用户需求的程度。在这个定义中，就需要进一步明确：
用户究竟是谁？
用户需求的优先级是什么？
这种用户的优先级对软件产品的开发过程产生什么样的影响？
怎样来度量这种质量观下的质量水平？
典型用户的期望
这款软件产品必须能够工作；
这款软件产品最好有较快的执行速度；
这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现
优异；
PSP质量策略
用缺陷管理来替代质量管理；
高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷；
第二节 PSP基本流程
什么是PSP（personal software process）？
- PSP是包括了数据记录表格、过程操作指南和规程在内的结构化框架。
- 一个基本的PSP流程包括策划、设计、编码、编译、单元测试以及总结等阶段。
- 在每个阶段，都有相应的过程操作指南，用以指导该阶段的开发活动
- 所有的开发活动都需要记录相应的时间日志与缺陷日志。
一个典型的PSP过程
PSP不同级别包含了不同过程元素
PSP过程度量
PSP基本度项
- 规模
- 时间
- 缺陷
- 日程（TSP）
PSP时间度量（时间日志）
时间日志示例
PSP缺陷度量（缺陷日志）
规模度量的意义和困境
规模度量是链接其他度量项的纽带，是估算的基础
规模度量的困境
精确的度量方式往往不便于早期规划；
有助于早期规划的度量往往难以产生精确度量结果；
LOC VS.FP（功能点）？
间接估算
基于代理的估算（PROBE）
模糊逻辑和相对大小估算
PROBE原理示例
相对大小矩阵
某一个相对大小矩阵（C++语言）
行数 仅供参考 软件估算追求什么样的结果
为什么要度量？
·关于度量的争议
度量体现着决策者对试图要实现的目标的关切程度（特别重要，就去度量）
·“高质量的开发是计划出来的"
·如何构建度量体系—GQM方法
第三节 PSP质量路线图
质量路径 Quality Journey
为了追求极高的质量，你有哪些手段？
Step 1：各种测试
Step 2：进入测试之前的产物质量提升 （如果你扔给测试人员是一堆垃圾，那测完了改完了还是一堆垃圾。）
Step 3：评审过程度量和稳定
Step 4：质量意识和主人翁态度
Step 5：个体工程师review过程的度量和稳定化
Step 6：诉诸设计
Step 7：缺陷预防
Step 8：用户质量观其他质量属性
不同缺陷消除方式消除缺陷的效率
设计、代码评审
关于PSP质量策略，下面各种说法当中，哪一种不恰当：
A.用缺陷管理替代质量管理
B.重点是关注模块（即个体软件工程师工作范围）的质量
C.应该进行充分的测试来保障质量
D.通过高质量评审来保障质量
正确答案：C你选对了
测试消除缺陷的典型流程
- 发现待测程序的一个异常行为；
- 理解程序的工作方式；
- 调试程序，找出出错的位置，确定出错原因；
- 确定修改方案，修改缺陷；
- 回归测试，以确认修改有效；
评审发现缺陷典型流程
- 遵循评审者的逻辑来理解程序流程；
- 发现缺陷的同时，也知道了缺陷的位置和原因；
- 修正缺陷；
PSP质量策略续
·用缺陷管理来替代质量管理；
·高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷；
·各个组件的高质量是通过高质量评审来实现的；
如何开展有效的评审
·评审检查表
·质量控制指标
·其他因素
评审检查表
·基于一个共识
“软件工程师未经提醒，会反复犯类似的错误"
·具体做法
- 将历史项目当中的缺陷整理分析，找出改进机会
- 整理形成检查表
- 使用检查表辅助开展个人评审
- 定期更新检查表
质量控制指标之一
·PQI（5个数据乘积）
设计质量：设计的时间应该大于编码的时间
设计评审质量：设计评审的时间应该大于设计时间的50%
代码评审质量：代码评审时间应该大于编码时间的50%
代码质量：代码的编译缺陷密度应当小于10个/千行
程序质量：代码单元测试缺陷密度应当小于5个/千行
PQI与集成测试缺陷之间的关系
关于时间日志，下述说法中比较贴切的是：
A.时间日志精确程度（例如：天、小时或者分钟）应当依据项目需要而定。
B.时间日志只能帮助我们知道每个开发活动消耗的时间。
C.时间日志是帮助工程师判断工程能力的手段之一。
D.每一个工程活动（设计、编码、UT等等）在时间日志中只能有唯一的一条记录。
正确答案：C你选对了
质量控制指标之二
评审的速度
- 评审的速度（Review Rate）是一个用以指导软件工程师开展有效评审的指标
- 高质量的评审需要软件工程师投入足够的时间进行评审
- 在PSP的实践中，代码评审速度小于 200LOC/小时，文档评审速度小于 4Page/小时
评审的其他因素
·环境
·评审时机
·个人评审和小组评审
·缺陷预防
本讲小结
·为了确保DevOps中价值顺畅流动，个人级别的软件
开发质量起着至关重要的作用；
·PSP为高质量开发提供了良好基础
·度量、估算和计划
质量管理策略
高质量策略补充
·评审目标是发现所有错误
·先做好，再做快
·无缺陷编程（The Third Way） 编程就如同是在石头上雕刻，你应该要小心谨慎。
下述各个说法中，哪一种说法描述是在缺陷日志的缺陷描述中应该出现的。
A.系统蓝屏了。
B.程序没有响应了。
C.运行结果错误。
D.循环控制变量没有初始化。
正确答案：D你选对了