24-Spring-软件质量与管理期末复习

2024软件质量管理复习+2024回忆 | wbl-z’s Blog | 软件质量管理-习题

PS：本文非背诵速通版本，只是尽力理一下思路

v2.0 修正了一些错误，添加了一些内容

最后一课

课程目标：很多软件工程基本、简单的概念要能够表述准确，经得起推敲

过程线

概念

1. 什么是管理：三个要素还记得不
2. 管理视角，关注的是学习，如何复现别人的成功：首先用一样的方法去做->过程
3. 有了过程为什么还要生命周期？过程太复杂，要有简单的方法：瀑布、生命周期，让别人快速明白
4. 迭代和瀑布：
   1. 迭代式是什么
   2. 关于瀑布的错误观点：有哪些，要有正确的理解
   3. 不理解瀑布模型的话，你觉得你是软件工程职业选手吗？

软件过程管理

有改进的场景：PDCA和IDEAL元模型

CMM和CMMI

软件工程演变的历史视角

软件危机和软件工程怎么来的，解决什么问题

三大阶段？如何正确理解敏捷宣言？（业界理解很多都是偏的）

驱动力：本质难题（人月神话的提到），这些本质难题在不同历史阶段的显现程度决定了演变

项目管理线

1. 自主团队：内部环境和外部环境（外部是管理层）该怎么样，TSP角色和职责（启动过程，九次会议），SCRUM角色和职责
2. 所有估算都是抽象的相对的估算
3. PROBE方法：相对大小矩阵，很典型的抽象，相对的
4. SCRUM故事点：斐波那契数列
5. 通用计划框架：正推，不是逆推，课上还专门讨论了哪些可以实现自动化哪些需要人为判断
6. 注意一份完整的项目计划包含了很多种计划，不止质量、风险
7. （跟踪中最重要的部分）挣值管理体系
   1. 需要思考这套体系为什么更加适合SE？1.支持动态变更，SE天然地会经常改变，需求功能改变这样（最关键的一点） 2.挣值图是相对保守的策略，全部完成才能拿到挣值

质量管理线

1. 质量管理的挑战：从管理的三要素来看，质量管理非常困难
2. 质量管理的策略和背后逻辑
   1. 比如问为什么这么多质量相关的属性，在企业中关注的往往只是其中的测试、缺陷管控？用户优先级排序第一的什么东西？
3. 个人评审：关键控制因素（速度），时机选择（先测试还是评审之类的）
4. 小组评审 九宫图 Capture?
5. 质量控制指标 Yield，A/FR, PQI, DRL 有什么用，能干什么，特点和用途
6. 设计评审：几种评审机制

工程技术线

概念和区别：vertification验证和validation确认，跟客户需求和产品需求联系起来理解就容易区分了

其他

题型

名词解释+简答题

过程线

软件工程究竟是什么？

主要解决面向“人”的问题

什么是软件开发

软件开发的本质困难（四大本质难题）

不可见性

• 软件是一种“看不见、摸不着”的逻辑实体、不具有空间的形体特征
• 开发人员可以直接看到程序源代码，但是源代码本身并不是软件本身
• 软件是以机器代码的形式运行，但是开发人员无法看到源代码是如何运行的

复杂性

• 对于软件复杂的需求导致了软件的复杂性

可变性

• 软件的变化（随时间推移）对其失效率的影响，软件的可变性体现在软件本身升级，功能的变化等

一致性

• 软件不能独立存在，要依附于一定的环境（如硬件、网络、以及其他软件）
• 软件必须遵循从人为的惯例并适应已有的技术和系统
• 软件需要随着接口不同而变化，随着时间推移而变化，而这些变化是不同人设计的结果

四大本质难题之间的关系

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

软件开发的几个注意点

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

本课程要回答的十大问题

复习完可以想想

√软件危机vs软件工程

1. 软件危机
   1. 软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题的现象。
2. 软件工程
   1. 软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。
   2. 软件工程的两大视角
      1. 管理视角——能否复制成功？
      2. 技术视角——是否可以将问题解决得更好？

软件危机->软件工程->两大视角之管理视角

√什么是管理

所以什么是管理？

1. 管理的三大关键要素：
   1. 目标
   2. 状态：是在接近目标还是在远离目标
   3. 纠偏

√软件项目管理

软件项目管理（not 软件过程管理）

1. 典型的三大目标：成本、质量、工期
2. 软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程。
   1. A. 软件项⽬管理包括估算、计划、跟踪、⻛险管理、范围管理、⼈员管理、沟通管理等等。
   2. B. 软件项⽬管理的对象是各类软件项⽬

质量实践和质量管理是不一样的

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

√软件过程管理

管理视角的主要目标/核心问题：成功是否可以复制？

软件过程定义

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

广义软件过程

广义软件过程（Generalized Software Process Model）**通常是一种高度抽象的方法，用于描述软件开发的各个阶段或步骤，旨在兼顾多种具体软件开发过程模型的共通特点。**这种广义的过程不专注于某一个特定的软件过程模型（如瀑布模型、迭代模型、敏捷开发模型等），而是试图概括出在大多数软件开发项目中普遍存在的活动和任务。

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

生命周期模型

1. **主要作用：**便于传达，复制成功
2. 区别和联系
   1. 生命周期模型是对一个软件开发过程的人为划分
   2. 生命周期模型是软件开发过程的主框架，是对软件开发过程的一种粗粒度划分
   3. 生命周期模型往往不包括技术实践
3. 典型生命周期模型
   1. 瀑布模型、迭代式模型、增量模型、螺旋模型、原型法等等

√瀑布模型

瀑布模型是Family，与迭代并不矛盾，团队决定该使用什么样的瀑布模型。

瀑布模型是Family，与迭代并不矛盾，团队决定该使用什么样的瀑布模型。

迭代与瀑布：多个迭代迭代完成，灵活，反馈快；瀑布线性完成，反馈少，不易变更

关于瀑布的错误观点（知道哪些错误的，不背）：

1. 瀑布模型是过时的

​ 正确理解： 瀑布模型并非过时，而是适用于某些特定类型的项目。对于需求明确、不太可能发生变化的项目，瀑布模型可以提供清晰的结构和控制。它在一些政府和大型工程项目中仍然广泛使用。

1. 瀑布模型不允许任何变化

​ 正确理解： 虽然瀑布模型强调顺序进行，但这并不意味着完全不能进行任何变化。实际应用中，许多瀑布项目会在必要时进行一些回溯和调整，只是相对较难和代价较高。因此，在需求稳定、变化较少的项目中，瀑布模型更为有效。

1. 瀑布模型没有反馈环节

​ 正确理解： **瀑布模型中的每个阶段通常都有验证和确认环节，以确保符合需求。**例如，需求分析阶段结束时会有需求评审，设计阶段结束时会有设计评审等。尽管反馈不像迭代式开发那么频繁，但仍然存在。

1. 瀑布模型导致更高的项目失败率

​ 正确理解： 瀑布模型的成功与否取决于项目的性质和执行的严格性。在需求明确且不太会变动的项目中，瀑布模型可以非常成功。项目失败通常更多与管理不善、沟通不畅和需求变化相关，而不是开发模型本身。

如何理解瀑布模型

• 瀑布模型不是单一模型，是一系列模型，覆盖最简单场景(过程元素少)到最复杂的场景(过程元素多)
• 软件项目应该结合实际情况选择合适过程元素的瀑布模型。基本原则是，项目面临困难和挑战越多，选择的模型应该越复杂。
• 软件项目团队往往低估项目的挑战，选择了过于简单的不适用的瀑布模型。

√迭代式模型

迭代式：大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来完成交付。

软件过程管理

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

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

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

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

两者意思接近

1. 软件过程管理参考模型 CMM/CMMI, SPICE等
2. 软件过程改进参考元模型 PDCA，IDEAL

CMM (Capability Maturity Model): 软件能力成熟度模型

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

PDCA (Plan Do Check Action): PDCA循环就是按照这样的顺序进行质量管理，

并且循环不止地进行下去的科学程序。【右上角】

IDEAL (Intiating Diagnosing Establishing Acting Learning): 初始化、诊断、建

立、行动、学习 。【右下角】

√软件发展三大阶段

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

√软硬件一体化阶段（50年代~70年代）

一：软件完全依附于硬件

1. 软件应用典型特征
   1. 软件支持硬件完成计算任务
   2. 功能单一
   3. 复杂度有限
   4. 几乎不需要需求变更
2. 软件开发典型特征
   1. 硬件太贵
   2. 团队以硬件工程师和数学家为主

典型软件过程和实践

1. Measure twice, cut once，相同的软件工程实践：code review & inspection
2. 各种specification，Operational Specifications (操作规格)，Program Specifications (程序规格)，Coding Specifications (编码规格)
   1. specification与参数、代码等部分相关

二：软件作坊

1. 软件应用典型特征
   1. 功能简单
   2. 规模小
2. 软件开发典型特征
   1. 很多非专业领域的人员涌入软件开发领域
   2. 高级程序语言出现
   3. 质疑权威文化盛行
3. Code And Fix
   1. Code And Fix不适合大型软件项目开发
   2. 一开始是“软件依附于硬件”，后来独立出去有“软件作坊”，软件小作坊的特征就是比较简单的Code And Fix

√软件成为独立产品（70年代~90年代）

软件应用典型特征

1. 摆脱了硬件束缚（OS）
2. 功能强大
3. 规模和复杂度剧增
4. 个人电脑出现 => 普通人成为软件用户
   1. 需求多变
   2. 兼容性要求
5. 来自市场的压力

软件典型过程和实践

1. 方法之一：形式化方法：指建立在严格数学基础上的软件开发方法，做数学化的检验，主要解决质量和正确性问题
   1. 问题和不足：形式化方法在扩展性和可用性方面存在不足
2. 方法之二：结构化程序设计和瀑布模型
   1. 设计+开发； 设计文档化；build it twice， 规划和监控测试，引入客户
   2. 问题和不足：瀑布模型成为一个重文档，慢节奏的过程

lean development说：其实royce提出瀑布生命周期模型的本意是该生命周期模型不适合软件开发。 （错误的）参考前文对瀑布模型的理解

√网络化和服务化（90年代中期迄今）

软件应用典型特征

1. 功能更复杂、规模更大
2. 用户数量急剧增加
3. 快速演化和需求不确定
4. 分发方法的变化 （SaaS）

典型软件过程和实践

1. 迭代式：大型软件系统的开发过程也是一个逐步学习和交流的过程，软件系统的交付不是一次完成，而是通过多个迭代周期，逐步来完成交付。

2. √雪鸟会议和敏捷宣言（见下）

   1. 目的：使软件开发团队具有高效工作和快速响应变化的能力

   2. 特征：小周期迭代、快速响应变更、价值交付、自动化

   3. 敏捷软件开发宣言的四个简单价值观

      1. A. 个体和互动胜过流程和工具
      2. B. 可以工作的软件胜过详尽的文档
      3. C. 客户合作胜过合同谈判
      4. D. 响应变化胜过遵循计划

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

   5. That is, while there is value in the items onthe right, we value the items on the left more”

      务必关注这一句话，非常重要：对敏捷宣言正确的理解是，右项是“正和” （根基），左项是“奇胜” 【“凡战者,以正合,以奇胜 ” — 孙子兵法】

3. XP（eXtreme Programming）方法

   1. 偏重于一些工程实践的描述

4. SCRUM

   1. 管理框架和管理实践

5. Kanban

   1. 精益生产（丰田制造法）的具体实现
   2. 可视化工作流、限定WIP【Working in Progress 车间生产管理】、管理周期时间

6. 开源软件开发方法：是一种基于并行开发模式的软件开发的组织与管理方式

   1. Linus 定律：如果有足够多的beta测试者和合作开发者，几乎所有问题都会很快显现，然后自然有人会把它解决。
   2. 早发布，常发布，倾听用户的反馈 、把你的用户当成开发合作者对待，如果想让代码质量快速提升并有效排错，这是最省心的途径、设计上的完美不是没有东西可以再加，而是没有东西可以再减
   3. 代码管理：严格的代码提交社区审核制度
   4. 一些演化：1. 内部开源（inner source） 2. 众包（Crowdsourcing）

√当前软件发展现状

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

√软件工程演变的驱动力

软件工程演变的驱动力是四大本质难题：不可见，复杂，可变，一致。【前文】四大难题之间的关系

√软件过程管理参考模型

成熟度模型CMM/CMMI (Capability Maturity Model)

成熟度模型（最开始是CMM，现在是CMMI）

1. CMMI从第2级升级到第3级的原因：固化最佳实践，对小组而言则是能够更快地学习其他的做法
2. CMMI第3级中的标准化目的不是简单的替换，重点是已定义
3. CMMI第4级我们希望能够看到一个预测模型
4. 第4级和第5级更多是根据结果（未来）来进行管理
5. 第2级和第3级关注的是当前的状态

理解

1. 初始级 Initial
   1. 过程不可预测、项目管理很少、开发相对混乱
   2. 个人英雄主义、救火文化
   3. 工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一旦离去，工作秩序面目全非。
2. 已管理级 Managed
   1. 以项目为单位进行管理，相对被动的管理
   2. 有项目计划和跟踪、需求管理、配置管理等
   3. 管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有复现以前成功项目的环境和条件。
3. 已定义级 Defined
   1. 以公司为单位进行管理，相对主动的管理
   2. 公司层面有标准流程和相应规范，每个项目小组可以基于此定义自己的流程
   3. 开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。
4. 定量管理级 Quantitatively
   1. 过程被度量和管理
   2. 构建预测模型，用统计过程控制的手段来管理过程
   3. 产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可 量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过 程和产品质量趋势，如预测偏差，及时纠正。
5. 优化级 Optimizing
   1. 专注于过程改进
   2. 继续应用统计方法识别过程偏差，找到问题根源并消除，避免未来继续发生类似问题
   3. 可通过采用新技术、新方法，集中精力改进过程。具备防缺陷、识别薄 弱环节以及改进的手段。可取得过程有效性的统计数据，并可据此进行 分析，从而得出最佳方法。

一些讨论

1. CMMI是过程改进模型而非软件过程或者软件过程模型，说法怎么样？对的，CMMI指导软件过程改进，不指导开发。
2. CMMI不是过程优劣的标准，也不适合用作公司之间的能力比较，说法怎么样？对的，CMMI本身是有评级。（美国国防部订单招标要求企业至少达到CMMI的3级。因为公司的能力需要绝对东西，也就是能力强，能力弱，而CMMI衡量的是相对的水平，CMMI仅仅关注在本公司的目标下的等级
3. 为什么CMMI VS. Agile是一个伪命题？ ==> Agile是敏捷过程或方法，这是一种软件开发方法；CMMI是过程管理模型。
4. Level 3及以下是一般的项目管理；Level4&5是高成熟的项目管理，即定量管理

更多见：https://www.jianshu.com/p/b7407257eedb

√软件过程改进元模型

PDCA

1. PDCA：Plan、Do、Check、Action
2. PDCA模型的步骤：
   1. 分析现状，找出问题
   2. 分析影响质量的原因
   3. 找出措施
   4. 拟定措施计划
   5. 执⾏措施，执⾏计划
   6. 检查效果，发现问题
   7. 总结经验，纳⼊标准
   8. 遗留问题转⼊下期PDCA循环

IDEAL

1. IDEAL模型解决了软件在各种质量改进环境下的需要。
2. IDEAL包括了软件改进过程的五个阶段
   1. Initiating 初始
   2. Diagnosing 诊断
   3. Establishing 建立
   4. Acting 执行
   5. Leveraging 调整

项目管理线

√三大目标

成本、质量、工期

注意区分目标的三要素

√团队动力学

软件开发是一项既复杂又富有创造性的知识工作（智力劳动）

• 处理和讨论极其抽象的概念
• 把不同的部分（不可见）整合成一个可以工作的系统

√知识工作特点

软件开发是一种智力劳动，需要工程师全身心地参与工作，主观意愿上努力追求卓越，所以需要管理者激励并且维持激励

√知识工作管理

知识工作者的管理需要的是领导者，而不是经理

管理知识工作的关键规则是：管理者无法管理工作者，知识工作者必须实现并且学会自我管理。

要自我管理，知识工作者必须：

• 有积极性
• 能做出准确的估算和计划
• 懂得协商承诺
• 有效跟踪他们的计划
• 持续地按计划交付高质量产物

√领导者和特点

知识工作者的管理需要的是领导者，而不是经理

• 诚实——言行一致
• 有能力——技能与知识兼备
• 有远见——能否洞察未来，是否拥有一个可信且美好的未来愿景？
• 鼓舞人心——他们对未来是否持有积极、热情和充满活力的态度？

√不同的激励方式

有3种主要的激励方式：

1. 威逼
2. 利诱
3. 鼓励承诺：位于马斯洛需求理论的4级以上，应当是主要的方式，并且最好以团队为单位做承诺

√马斯洛需求层次理论

1. 马斯洛需求理论：生理需求、安全感、爱和归属、获得尊敬、自我实现
   1. 自我实现是最高的层次
   2. 激励来自为没有满足的需求而努力奋斗
   3. 低层次的需求必须在高层次需求满足之前得到满足
   4. 满足高层次的需求的途径比满足低层次的途径更为广泛

√期望理论

期望理论：Motivation = Valence * Expectancy

1. M：激发力量，积极性
2. V：目标价值(效价)，达到目标对于满足个人需要的价值，有正零负三种，效价越高，激励力量越大
3. E：期望值，人们根据过去经验判断自己达到某种目标的可能性大小

其他理论

1. 海兹伯格的激励保健理论 Herzberg’s Motivational and Hygiene Factors
   1. 内在（成就感，责任感）+外在（环境薪资）
2. 麦克勒格的 X－理论 和 Y －理论 McGregor’s Theory X and Y
   1. X理论：基于这种观点，管理者认为员工本质上是懒惰的，缺乏野心，抗拒变化，并且总是避免责任。因此，这种观点认为，必须通过严格的监控、控制和处罚来管理员工。
   2. Y理论：在这种观点中，管理者认为员工是自我激励和自我控制的，愿意接受和寻求责任。他们认为工作是自然的，像休息和玩耍一样。基于Y理论的管理风格强调赋予权力、员工参与和整体目标的追求。
   3. 麦克格雷戈强调，采用Y理论的管理风格可以更有效地激发员工潜能，提高工作效率和满意度。

相应的领导方式

1. 交易型领导方式
   1. 承诺奖励激励
   2. 人们通常能找到新的方式来获得奖励，同时少做工作。
   3. 威逼和利诱属于交易型领导方式。
2. 转变型领导方式
   1. 用成就激励
   2. 鼓励承诺属于转变型领导方式。
3. 由于交易型领导方式很少能产生成功的并且有创造性的团队，因此转变型领导方式是首选。

维持激励水平

维持激励需要及时的绩效反馈，这些反馈包括

1. 根据一个详细计划衡量进度
2. 当前计划不准确时重做计划
3. 为漫长而富有挑战性的项目提供中间反馈，即里程碑

√自主团队

1. 定义：
   1. 一个团队必须包括至少两个成员，他们为了共同的目标和愿景而努力工作，他们每个人都有明确的角色和相应的职责定义，任务的完成需要团队成员互相依赖和支持。
   2. 如果团队成员都实现了自我管理，也就形成了所谓的自主团队。（可结合知识工作特点等说明）
2. 特点
   1. 自行定义项目的目标
   2. 自行决定团队组成形式以及成员的角色
   3. 自行决定项目的开发策略
   4. 自行决定项目的开发过程
   5. 自行制定项目的开发计划
   6. 自行度量、管理和控制项目工作

√内外部环境

内部环境：=特点

外部环境：（大的2点）

• 项目启动阶段获得管理层的支持
  • 项目小组应当体现出已经尽最大的可能在满足管理层的需求的工作态度。
  • 项目小组应当在计划中体现定期需要向管理层报告的内容。
  • 项目小组应当向管理层证明他们所制定的工作计划是合理的。
  • 项目小组应当在计划中体现为了追求高质量而开展的工作。
  • 项目小组应当在工作计划中允许必要的项目变更。
  • 项目小组应当向管理层寻求必要的帮助。
• 在项目进展过程中获得管理层的支持
  • 项目小组应当严格遵循定义好的开发过程开展项目开发工作。
  • 项目小组应当维护和更新项目成员的个人计划和团队计划。
  • 项目小组应当对产品质量进行管理。
  • 项目小组应当跟踪项目进展，并定期向管理层报告。
  • 项目小组应当持续地向管理层展现优异的项目表现。

团队成员自身努力，团队规范合理制定，团队管理妥善 -> 自主团队

√TSP角色和职责

• 项目组长：激励成员、主持例会、汇报项目、分配任务、维护资料、组织总结
• 计划经理：开发项目计划、平衡计划、跟踪进度、参与总结
• 开发经理：开发策略、估算时间、文档编写、产品实现、集成测试、参与总结
• 质量经理：开发质量计划、报告问题、评审问题、组织协调、参与总结
• 过程经理：记录内容、维护标准、维护记录、参与总结
• 支持经理：工具开发、管理配置、维护词汇、参与总结
• 开发人员：参与开发

√TSP启动过程

• 第一次和第二次会议由项目经理主持
• 第三次会议
  • TSP灵活：自定义的流程让人相信项目可以成功
  • 开发策略：打算进行几个迭代周期。
• 几个认识
  • 错误的认识：软件开发阶段理解为注入缺陷的阶段，软件测试阶段理解为消除缺陷的阶段。
  • 正确的认识：开发和测试都是既有可能引入缺陷，也有可能消除缺陷的阶段
• 项目完成的实际时间由什么决定？最晚完成的工作的人决定的

√SCRUM角色和职责

ppt上还有点内容，可以多看看

Scrum 是一个敏捷开发项目管理框架

1. 产品负责人（Product Owner）：
   1. 产品负责人是团队与客户及其他利益相关者之间的关键联系人。他们的主要职责是确保开发团队所开发的产品能够带来最大的价值。为此，产品负责人需要管理产品待办列表（Product Backlog），这是一个按优先级排序的功能需求列表，确保团队始终专注于最重要的任务。
2. Scrum Master：
   1. Scrum Master的角色可以看作是团队的引导者和教练。他们的任务是确保团队正确理解并遵循Scrum的理论、实践和规则。Scrum Master帮助团队解决进度中的障碍，优化流程，确保团队能高效运作。
3. 开发团队：
   1. 开发团队负责具体的产品开发工作。在Scrum中，他们需要交付高质量、可发布的产品增量。这意味着在每个Sprint（迭代周期）结束时，团队应产出完全可用的产品功能。团队成员在日常工作中自主管理自己的工作和时间，强调团队合作和自我管理。

这三个角色共同协作，通过每个迭代不断调整和优化工作方式，以确保项目的顺利进行，并最终达到高效交付高质量软件产品的目标。

典型SCRUM团队由一名产品负责人、开发团队和一名 SCRUM Master 组成

SCRUM团队是跨职能的自组织团队

产品负责人：

• 产品负责人的职责是将开发团队开发的产品价值最大化。
• 产品负责人是负责管理产品待办列表的唯一负责人。产品待办列表的管理包括：（应该看看就好）
  • 清晰地表述产品待办列表项；
  • 对产品待办列表项进行排序，使其最好地实现目标和使命；
  • 优化开发团队所执行工作的价值；
  • 确保产品待办列表对所有人是可见、透明和清晰的，同时显示 Scrum 团队 下一步要做的工作；
  • 以及确保开发团队对产品待办列表项有足够深的了解。

开发团队：

• 负责在每个 Sprint 结束时交付潜在可发布并且“完成”的产品增量。
• 开发团队由组织组建并得到授权，团队自己组织和管理他们的工作。开发团队具有下列特点：（应该看看就好）
  • 他们是自组织的。没有人（即使是 Scrum Master）有权告诉开发团队应该 如何把产品待办列表变成潜在可发布的功能增量；
  • 开发团队是跨职能的团队，团队作为一个整体，拥有创建产品增量所需的全 部技能；
  • Scrum 不认可开发团队成员的任何头衔，不管其承担何种工作（他们都叫开 发人员）。
  • Scrum 不认可开发团队中所谓的“子团队”，无论其需要处理的领域是诸如测 试、架构、运维或业务分析；同时， 开发团队中的每个成员也许有特长和专注的领域，但是责任属于整个开发团队。

Scurm Master:

• 促进和支持 SCRUM
• 帮助每个人理解 SCRUM 理论、实践、规则和价值
• SCRUM Master 是一位服务型领导。 帮助 SCRUM 团队之外的人了解如何与 SCRUM 团队交互是有益的 改变SCRUM 团队之外的人与 SCRUM 团队的互动方式来最大化 SCRUM 团 队所创造的价值。
• Scrum Master 服务于产品负责人，包括：
  • 确保 Scrum 团队中的每个人都尽可能地理解目标、范围和产品域；
  • 找到有效管理产品待办列表的技巧；
  • 帮助 Scrum 团队理解为何需要清晰且简明的产品待办列表项；
  • 理解在经验主义的环境中的产品规划；
  • 确保产品负责人懂得如何来安排产品待办列表使其达到最大化价值；
  • 理解并实践敏捷性；以及，
  • 当被请求或需要时，引导 Scrum 事件。
• Scrum Master 以各种方式服务于开发团队，包括
  • 作为教练在自组织和跨职能方面给予开发团队以指导；
  • 帮助开发团队创造高价值的产品；
  • 移除开发团队工作进展中的障碍；
  • 按被请求或需要时，引导 Scrum 事件；以及，
  • 在 Scrum 还未完全采纳和理解的组织环境中，作为教练指导开发团队。
• Scrum Master 以各种方式服务于组织，包括：
  • 带领并作为教练指导组织采纳 Scrum；
  • 在组织范围内规划 Scrum 的实施；
  • 帮助员工和利益攸关者理解并实施 Scrum 和经验导向的产品开发；
  • 引发能够提升 Scrum 团队生产率的改变；以及，
  • 与其他 Scrum Master 一起工作，增强组织中 Scrum 应用的有效性。

√估算和计划

关于估算的一些事实

估算对象是：规模、时间、日程

1. 估算是客观猜测
2. 估算能力很难提升
3. 没有任何人知道准确的数字究竟是什么
4. 多项实证研究表明，是否使用估算模型（例如，COCOMO）并没有显著差异

√估算的要点

• 尽可能划分详细一些
• 目标是建立对结果的信心
• 尽量依赖数据
• 估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程

√估算目的是什么

目的是给各类计划提供决策依据、达成共识、建立信心（足够详细、依赖数据、最好的猜测）

√PROBE估算方法

1. 以 LOC VS. FP 为例（LOC精确度量，FP早期规划）
   1. 精确度量方式往往不便于早期规划；
   2. 有助于早期规划的度量往往难以产生精确度量结果；
2. PROBE(PROxy Based Estimation)基本原理/作用

• 设立合理的代理作为精确度量和早期规划之间的桥梁
• 相对大小，而非绝对大小

流程

相对大小矩阵

概要设计

“如果你对产品的理解还不足以产出一个概要设计，那么你所知道的还不足以做出一个计划”

**对于大多数的项目，概要设计都应相对较快地完成：**例如，1000LOC 以内程序，试着将概要设计时间限制在10到20分钟之内

1. 估算的第一步是做出一个概要设计
   1. 概要设计不是真实设计
   2. 与已有产品/组件 相关联
   3. 定义能够产生期望功能的产品元素
   4. 估算你计划构造之物的规模
2. 为了做出概要设计，需要确定产品功能，以及产生这些功能所需的程序组件/模块：“如果我有以下这些部件，我可以构造这个产品。”
3. 然后，将这些程序组件/模块与你以前写的程序相比较，估算它们的规模
4. 最后，将程序组件/模块估算综合给出总规模

整合估算

整合多个估算结果

• 整合一个开发人员做的多个估算
• 多个开发人员可以整合独立进行的估算
• 当估算多个部件时，总的误差会比各个部件误差的总和要小。
  • 误差趋于抵消了
  • 假设没有共同的偏差

估算要点一

√SCRUM故事点

• 度量实现一个故事（Story）需要付出的工作量
  • 抽象：混合了对于开发特性所要付出的努力、开发复杂度、各种风险以及类似东西
  • 相对：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
• 度量体现着决策者对试图要实现的目标的关切程度

在敏捷开发实践中，团队通常会进行一次“规划扑克”（Planning Poker）会议，利用斐波那契数列来为每个用户故事分配故事点数值。

估算要点二、三

关于度量

度量体现着决策者对试图要实现的目标的关切程度

PSP基本度项：规模 时间 缺陷 日程（TSP）

以下开始是团队项目规划/计划的部分

WBS(Work Breakdown Structure)

好的WBS检查标准

1. 最底层要素不能重复，即任何一个工作包应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
2. 所有要素必须清晰完整定义，即相应的数据词典必须完整定义。
3. 最底层要素必须有定义清晰的责任人，可以支持成本估算和进度安排。
4. 最底层的要素是实现目标的成分必要条件，即项目的工作范围得到完整体现。

√通用计划框架

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

过程框架——生命周期模型（不背了）

√各类计划

日程计划

1. 任务计划和日程计划
2. 典型计划流程回顾
   1. 估算规模
   2. 估算资源
   3. 规划日程
3. 考虑假期的影响：时间计划和工作计划并存。

前者描述了项目所有的任务清单、任务之间的先后顺序以及每个任务所需时间资源；后者描述了整个各个任务在日程上的安排，即各个任务计划哪天开始和计划哪天结束。

√质量计划

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

需要将项目总体质量目标细分成若干小的目标，这样便于在过程中进行管理和控制。结合本书第3章中介绍的质量管理指标，yield， PQI以及A/FR等，图 6‑4给出了质量管理计划的示例。途中右下角是质量总体目标，即整个系统在系统测试之后总的缺陷数应当小于6.63个。那么相应需要开展的质量保证活动以及每个活动的yield可以根据历史数据或者一般的行业数据确定。而每个质量管理活动所需时间则由PQI指标和A/FR指标加以确定。事实上，PQI和A/FR指标也是为了确保yield目标的实现。

√风险计划

• 风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目的负面影响。

1. 风险识别
   1. 识别成本、进度、绩效、环境因素、组件
   2. 记录风险的内容、条件和结果，识别干系人
   3. 评估、分类、分组、排列优先级
2. 风险应对
   1. 风险转嫁：通过某种安排，在放弃部分利益的同时，将部分的项目风险转嫁到其他的团队或者组织。
   2. 风险解决：指采取一些有效措施，使得风险的来源不再存在。
   3. 风险缓解：容忍风险的存在，采取一些措施监控风险，不让风险对项目最终目标的实现造成负面影响。

风险管理是一个持续的、前瞻的过程，此过程是项目管理的重要部分。有效的风险管理是通过相关干系人的合作与参与，尽早且积极地识别风险，制定项目风险管理计划。风险管理须同时考虑有关成本、进度、绩效及其他风险的内部及外部来源。因为在项目初期进行变更或修正的工作负荷，通常比在项目后期来得容易、花费较低及较不具破坏性，所以，早期及积极的风险侦测是重要的。风险管理大致分成两部分，即风险识别和风险应对。

√定量管理计划（自顶向下）不确定

过程性能

遵循某个特定（子）过程的之后产生结果的量化描述，既包括（子）过程度量Xi（例如，时间、缺陷消除效率、工时等），也包括产物度量Yi（例如，缺陷密度，相应时间等）。

过程性能基线

上述过程性能的一个定量化的刻画，一般包括均值和范围。通常用作过程性能的benchmark。

过程/子过程性能模型

依据子过程的逻辑关系构建相应的数学模型，描述子过程性能基线和整体过程有意义的性能输出（例如，质量、生产效率、成本等）之间关系。例如 过程Yield 和 Phase Yield。

过程组合：关键子过程性能目标、整体过程性能目标

以下是跟踪部分

团队项目的跟踪与管理主要包括进度的跟踪（利用不同跟踪方法，例如挣值管理、里程碑评审）、纠偏活动管理

定量管理的基本范式

定量管理基本范式：

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

项目跟踪意义

• 项目进展过程中开展跟踪活动的目的在于了解项目进度，以便在项目实际进展与计划产生严重偏离时，可采取适当的纠正措施。
  • 项目进度滞后与否是否需要参照物，即项目计划。
  • 项目跟踪需要管理针对偏差而采取的纠偏措施

正如Brooks在《人月神话》一书中指出的那样，**项目延迟整整一年是一次延迟一天慢慢积累起来的。**开展及时有效的项目跟踪就是期望及时发现项目实际进展与计划之间的偏差，及时处理这些偏差，从而消除累计的偏差对项目造成的负面影响。

例如，在软件工程实践中，有一条流传非常广泛的经验总结，即向一个已经落后的项目中增加人手，往往导致项目更加落后。而在实践中，一旦出现项目落后的情况，往往都会采取增加人手的方法来应对。

挣值管理(EV)体系

项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法。

• 每项任务实现附以一定价值（credit）
• 100%完成该项任务，就获得相应价值。

EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。

BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间。

成本差异CV = EV-AC，表示的是已经完成的工作与所消耗的成本的差异。可以表示为消耗的时间，也可以表示为消耗的资金。

成本差异指数CPI = EV/AC，表示单位成本创造的价值，很显然，CPI<1说明成本超支；CPI=1说明成本与预期一致；CPI>1说明成本低于预期。

日程偏差SV = EV–PV，表示进度偏差。显然SV<0表示进度落后；SV=0表示进度正常；SV>0表示进度超前。

日程偏差指数SPI = EV/PV。

预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI，表示的是按照目前的进展已经成本消耗情况，整个项目完成的时候所需消耗的成本。

EV已经产生的价值，AC已经消耗的本钱，PV此时需要达到的预期价值

该图此时出现了加班情况，AC在增长，可能是加班费

√简单、中级和高级

• 简单
  • 这种方式仅仅关注进度信息。在实现时，首先需要建立WBS，定义工作范围；其次为WBS中每一项工作定义一个价值（PV）；最后按照一定的规则将某一数值赋给已经完成的工作或者正在进行的工作。
  • 常用规则分别为0-100规则和50-50规则，前者只有当某项任务完成时，该任务的PV值将转化成EV值；后者只需要开始某项任务，即可以赋原PV值的50%作为EV值，完成时，再加上另外的50%。而实际完成的工作所需成本AC不对EV值产生任何影响。
• 中级
  • 在简单实现的基础上，加入日程偏差的计算。典型计算方式有：
  • 日程偏差SV = EV – PV;
  • 日程偏差指数SPI = EV/PV；
• 高级
  • 在中级实现的基础上，还需要考察项目的实际成本。

EVM的局限性

1. EVM一般不能应用软件项目的质量管理。
2. EVM需要定量化的管理机制，这就使其在一些探索型项目以及部分敏捷开发方法中的应用受到限制。
3. EVM完全依赖项目的准确估算（价值体系），然而在项目早期，很难对项目进行非常准确的估算。

√为何适应软件项目

1. 支持动态变更
2. 相对保守的策略（全部完成才能拿到）

变形：燃尽图

里程碑评审

旨在特定的项目阶段或关键点对项目的进展进行评估和审查

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

项目总结

基于PMBOK的总结

范围管理、时间管理、成本管理、质量管理、人力资源管理、沟通管理、风险管理、采购管理和整合管理9大知识领域

TSP项目总结

• TSP也提供了一种项目总结的方式，在这种方式当中，团队成员结合自己的角色，总结自己角色相关工作的得失，提出下一个开发周期的改进建议。
• 典型角色包括项目组长、计划经理、开发经理、质量经理、过程经理和支持经理等

√EVM体系为何适应软件项目

1. 支持动态变更
2. 相对保守的策略（全部完成才能拿到）

√定量管理的跟踪（自底向上）

√关于子过程性能控制

质量管理线

√软件质量的概念

软件质量为“与软件产品满足规定的和隐含的需求能力有关的特征或者特性的全体”

1. 软件质量的内外两部分的特性
   1. 内部质量特性：不直接面向用户
   2. 外部质量特性：面向软件产品的最终用户
2. 软件质量的不同视角
   1. 软件质量为软件产品可以改变世界，使世界更加美好的程度(用户满意度是最为重要的判断标准)
   2. 软件质量是对人的价值，强调质量的主观性(对同一款软件而言，不同的用户对其质量有不同的体验)

√质量管理的挑战：三要素

成本、质量、工期（也就是软件质量管理的三大目标）

“软件项目的日程、成本以及质量三大目标统一于质量目标。”

√面向用户的质量观

定义质量为满足用户需求的程度，这个定义中需要进一步明确：

1. 用户究竟是谁？
2. 用户需求的优先级是什么？
3. 用户的优先级对软件产品的开发过程产生什么影响？
4. 怎么度量这种质量观下的质量水平？
5. 指导意义：开发在前，运维在后；高质量开发确保DevOps中的价值顺畅流动；个体软件工程师的技能、过程直接影响产品质量；PSP关注提升个体软件工程师工程技能

典型用户质量期望：

1. 这款软件产品必须能够工作；
2. 这款软件产品最好有较快的执行速度；
3. 这款软件产品最好在安全性、保密性、可用性、可靠性、兼容性、可维护性、可移植性等方面表现优异；

这样的列表可以一直列举下去，列表中各项内容的顺序也可以变化，这取决于用户期望、开发环境和应用环境等因素。但是，相信几乎在任何一个列表中，**都会把软件产品能够工作作为一个最基本的期望。**事实上，如果软件产品本身不能工作，那么考虑其他的期望是没有意义的。而为了使一个软件产品可以工作，该产品基本没有缺陷是最基本的要求。这样一来，整个软件产品的质量目标就可以归结成首先得确保基本没有缺陷，然后再考察其他的质量目标。PSP中就采用了这样的方式，用缺陷管理来替代质量管理，这大大简化了质量管理的方法，使得质量管理更加易于操作。

（PSP：质量管理 简化-> 缺陷管理）

质量管理策略和背后逻辑

• 用缺陷管理来替代质量管理
• 高质量产品也就意味着要求组成软件产品的各个组件基本无缺陷
• 各个组件的高质量是通过高质量评审来实现的

缺陷消除

测试消除缺陷的典型流程

1. 发现待测程序的一个异常行为；
2. 理解程序的工作方式；
3. 调试程序，找出出错的位置，确定出错原因；
4. 确定修改方案，修改缺陷；
5. 回归测试，以确认修改有效；

在上述的步骤当中，有一些步骤极耗时间。比如步骤③，在项目的后期，往往会消耗数天甚至数周的时间。此外，在有些软件项目中，开发团队、测试团队和正式发布团队往往分开。那么如果用户在使用软件的过程中发现缺陷，再通过正式沟通渠道将信息反馈到开发团队，然后等待修改和发布，重新安装补丁，这一流程消耗数月时间也是常事。

评审发现缺陷的主要流程

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

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

PSP评审过程的质量

• 评审检查表
• 质量控制指标
• 其他因素
  • 环境
  • 评审时机
  • 个人评审和小组评审
  • 缺陷预防

√个人评审

关键控制因素

速度

时机选择

编译/UT前还是后？（所以先review再编译/UT）

1. **态度方面：**如果review在编译/UT之后，会对review态度产生影响，会有一种这个代码已经差不多对了的感受，态度上会有影响。态度很重要：review要么不做，要做就要抱着查出错误的心态，而不是内心已经认可了，导致code review做的很快，比如2000loc/h
2. **效率成本方面：**在review的时候先发现一些bug，编译/测试的时间会变少，也就是先编译后评审的时间会 > 先评审后编译
3. **高质量软件开发的要求方面：**要降低编译时发生的错误数，是高质量软件开发的要求 => 先评审后编译
4. 编译之前评审也是一种自我学习的好机会
5. 干净的编译，即编译过程没有缺陷对于软件工程师来说，也有极大的成就感

√小组评审

小组评审时机（个人评审之后）

• 小组评审通常安排在个人评审之后进行，尤其是在详细设计和代码开发阶段之后。这样的安排有助于提升Process Yield，即过程产出率。
• 在个人评审后进行小组评审还有利于提升个人技能，尤其是对那些个人评审未发现但小组评审中发现的缺陷，这些缺陷需要引起足够的注意，并通过对这些缺陷的分析使软件工程师能够学习到很多东西。

小组评审的组织形式：

• 准备阶段：
  • 由评审的组织者召集参与人员开一个准备会议。
  • 评审对象的作者需要向参与人员简要介绍评审对象的内容。
  • 组织者向参与人员介绍评审的目标、标准及其他注意事项。
  • 在所有人员都了解评审对象和目标之后，由组织者总结会议并确定下一次评审阶段会议的时间。
• 评审阶段：
  • 组织者确认所有评审参与人员已经完成了各自的评审活动后，再召集所有人开会讨论交流各自评审过程中发现的缺陷，并确定修改责任人和修改期限。

小组评审的附加功能：

• 除了提升产品的质量之外，小组评审还有助于判断评审产物的质量状况。
• 引入了“Catch and Re-Catch”方法来评价评审对象的质量状况，这是从统计学中估算池塘中鱼总数的方法演变而来。

参考 https://imgss.s3.bitiful.net/2024/06/27/20240627005600.png

过程质量控制方式

1. 九宫格(by jhdd)
   1. 在软件质量管理中，使用“Review Rate”和“Defect Density (DD)”构成的九宫格是一种常见的方法，用于评估和可视化软件质量及代码审查的效果。这种矩阵帮助团队识别在哪些区域可以提高代码审查的质量和效率，以便更有效地发现和减少软件缺陷。下面是关于这个九宫格的详细解释：
   2. 九宫格是一个3x3的矩阵，其中：
   3. 纵轴（Review Rate）：表示代码审查的频率或深度，分为低、中、高。
   4. 横轴（Defect Density）：表示每单位代码中的缺陷数量，同样分为低、中、高。
2. Catch and Re-Catch
   1. 小组评审只有两个人参加。假设评审人员A和B分别发现了a个缺陷和b个缺陷，其中c个缺陷两人同时发现。利用上述思想，选择a-c和b-c中较大值，如果相等则可以任选一值。假设a-c是选定的值，那么就可以把a当成上述第一网被标记的鱼，c是第二网中被标记的鱼。简单计算就可以估算出评审对象经过小组评审之后，还遗留a x b/c -(a+b-c)个缺陷。
      1. a / 总数 = c / b -> (a*b) / c
   2. 小组评审有多人参加。小组评审如果有多人参与，那么情况就相对复杂。我们采取了一个简化的计算方法。即选择某个独立发现缺陷最多的评审员作为A，而其他所有参与人员的整体作为B。那么我们仍然可以用上述相同的方式来估算小组评审之后评审对象中遗留的缺陷数。

质量控制指标

这部分最好看看ppt例子

Yield

• Yield指标用以度量每个阶段在消除缺陷方面的效率。越大越好，希望在80以上
  • Phase Yield = 100 * （某阶段发现的缺陷个数）/（某阶段注入的缺陷个数+进入该阶段前遗留的缺陷个数）
  • Process Yield = 100 * （第一次编译前发现的缺陷个数）/（第一次编译前注入的缺陷个数）

例子

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

也就是说，为了确保较高的质量水平，软件工程师应当花费两倍于编译加测试的时间进行评审工作。评审的对象为设计和代码。

PQI

5个数据乘积**（五个数值都是0到1，然后相乘出来也是0到1）**

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

PQI的作用

1. 判断模块质量
2. 评估项目质量
3. 直接可以为软件改进做依据（之前两者是没有的）
   1. 比如最后一个PQI图可以给出的建议
      1. 增加设计时间
      2. 增加设计评审时间
      3. 增加代码评审时间
4. 只追求到0.4，而不是很高的值

Review rate

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

如果不计成本的投入大量时间进行评审，尽管可能发现较多的缺陷，但是又会影响到整个软件过程的生产效率。因此，应当为评审设置一个恰当的速度。

DRL

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

评审的其他考虑因素

• 打印后评审往往效果更好
  • 单个屏幕可以展现的内容比较有限
  • 评审人员的注意力
• 评审时机选择
  • 编译/UT 之前 VS. 之后
• 个人评审和小组评审
  • 小组评审意义
  • 先后顺序

特点和用途

上面这五个怎么用，能干什么，有什么特点大概讲讲

Quality Journey

Journey是什么？顺序？

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

• Step 1：各种测试
• Step 2：进入测试之前的产物质量提升
• Step 3：评审过程度量和稳定
• Step 4：质量意识和主人翁态度
• Step 5：个体review的度量和稳定
• Step 6：诉诸设计
• Step 7：缺陷预防
• Step 8：用户质量观——其他质量属性

设计

设计与质量的关系？为什么要进行设计？

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

典型设计过程

模板：要设计哪些信息？

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

PSP设计模板

操作规格模板OST、功能规格模板FST、状态规格模板SST、逻辑规格模板LST（PPT有详细说明）

设计的层次

系统-子系统-组件-模块 | 需求定义-规格说明-高层设计

PSP模板

设计评审（验证）

意义：简单评审不足以发现复杂缺陷

方法：状态机验证、符号化执行验证、执行表验证、跟踪表验证、正确性验证

状态机验证

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

符号化执行验证

符号化验证方法的基本思想是将描述设计的逻辑规格（一般用伪代码程序表示）用代数符号来表示，然后系统地开展分析和验证。具体步骤如下：

• 识别伪码程序中的关键变量；
• 将这些变量用代数符号表示，重写伪码程序；
• 分析伪码程序的行为。

优缺点分析：

• 符号化验证的方法实施简单，可以给出一般化的验证结果，很多时候往往是唯一提供全面验证的方式。
• 这种方法通常用在验证一些复杂算法中，特别是对遗留系统的改造中，往往应用这种方法来识别和理解原有的设计。
• 但是这种验证方法不适用于有复杂逻辑的场合，而且，纯手工的验证方法也容易引入一些人为的错误。

执行表验证

执行表用一种有序的方法来跟踪伪码程序的执行状况，分析程序行为，从而验证设计。具体步骤如下：

• 识别伪码程序的关键变量；
• 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
• 初始化被选定的变量；
• 跟踪被选择的关键变量的变化情况，从而判断程序行为。

跟踪表验证

跟踪表验证方法是对执行表验证方法的一种扩充。具体步骤如下：

• 识别伪码程序的关键变量；
• 构建表格，表格左侧填入主要程序步骤，右侧填入关键变量；
• 初始化被选定的变量；
• 识别将伪码程序符号化的机会，并加以符号化；
• 定义并且优化用例组合；
• 跟踪被选择的关键变量的变化情况，从而判断程序行为。

比较：执行表一般只能用以验证单独的用例，跟踪表应用符号化以及用例识别等方法，对程序的一般化行为进行验证，从而提供更加高效地开展验证工作。

正确性检验

正确性检验将伪码程序当成数学定理，采用形式化方法加以推理和验证。这种方法的步骤如下：

• 分析和识别用例；
• 对于复杂伪码程序的结构，应用正确性检验的标准问题逐项加以验证；（比如，循环不变式）
• 对于不能明确判断的复杂程序结构，使用跟踪表等辅助验证。

示例while 正确性检验

1
2
3
4

while (condition) 
begin
    states;
end

条件1： condition是否最终一定会为“假”，从而使得循环可以结束；

条件2： condition为“真”的时候，单独的循环结构执行结果与循环体再加一个循环结构，其执行结果是否一致？

条件3： condition为“假”的时候，循环体内所有变量是否未被修改？

工程技术线

需求开发、团队设计、实现策略、集成策略、验证与确认

需求

1. 需求是一切工程活动的基础
2. 需求类别
   1. 客户需求
   2. 产品需求
   3. 产品组件需求

√客户需求

描述的是客户的期望。

1. 往往表现为，**客户在实际工作中碰到了一些具体问题，希望通过某个东西来帮忙解决这些问题。**客户的这种解决问题的愿望，往往就表述为客户需求。
   1. 比如，客户希望有一种快速进行数据计算的工具帮助他/她完成繁琐的计算工作。这就是一个客户需求。
2. **客户需求可能很简单，也可能很复杂；可能很清晰，也可能很模糊。**这就需要开发团队与客户一起进行交流、协商，从而弄清客户的真正意图。

√产品需求

描述的是开发团队所提供的解决方案。即针对上述的客户需求，开发团队设计出一个可以帮助客户解决工作当中碰到的问题的方案。

如上例，产品需求就是提供一个可以输入数据，可以计算符号，可以显示计算结果的手持设备。产品需求是对客户需求的一个提炼和精化，把客户需求真正的表述为开发人员能够理解的语言。同样，产品需求需要进行验证，以确保客户的真实意图得到了体现。

产品组件需求

描述的是组成产品的各个组件的需求规格。与产品需求相比，这是更低层次上，更为细致的描述了上述解决方案中的某个组件的功能、性能、形式等。

需求开发-需求获取-需求汇总-需求验证-需求文档制作（优秀的需求规格文档特征）

√产品经理？

团队设计

√自顶向下

在设计的过程当中，采取的基本策略是自顶向下，逐层精化的策略。这有利于建立系统的整体观。然而，在实现过程当中，应当更多的考虑到是否便于对实现结果的评审。

√团队智慧的使用

发挥团队智慧两大挑战

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

每个团队成员都有不同的知识背景和工作经验，因此，如果设计工作中可以充分发挥每个人的特长，往往对项目带来极大的帮助。然而，设计工作面临的一个很大挑战是在确定整体架构之前很难进行分工。而缺乏合理的分工就不能可充分发挥团队智慧。对于该问题的处理办法是视软件系统的规模而定，选择适当人数的团队成员参与整体架构的开发，而其他人员参与架构的评价和关键技术问题的验证。

发挥团队智慧的另外一个问题是鼓励团队成员在讨论和评审会议中的参与程度。由于各种原因，如掌握项目信息的差异和个人知识背景的差异，在讨论会议中，有些团队成员倾向于主导会议讨论，而有的团队成员则不愿意发表见解。这就需要会议的协调者，特别是项目组长或者设计工作的负责人采取适当的方法来调动整个团队的参与。

设计标准

• 命名规范
  • 项目小组应当设计一个统一的命名规范来命名各个模块并建立系统词典，用以描述各个模块。系统词典在整个系统的设计、实现以及支持文档的开发过程中要时刻保持可用状态。此外，还需要通过命名规范来约定系统的架构类型和名称，典型的包括系统、子系统、组件、模块、程序等。在编码过程中程序的命名、文件的命名、变量的命名以及参数的命名等都需要通过命名规范加以定义。
• 接口标准
  • 组件之间的接口标准和格式也需要作为设计标准的内容之一加以定义。事实上，软件工程的一些设计原则，如高内聚、低耦合等也应当作为接口标准定义的内容，从而约束了模块之间信息交互的方式。
• 系统出错信息
  • 系统异常信息和出错信息往往也需要通过一个规范加以标准化。从而使得出错信息有个一致的、便于理解的描述。此外，也便于在设计和开发中的复用。
• 设计表示标准
  • 设计表示标准定义了设计工作的产物应当满足的标准。这有可能是所有设计标准中最为重要的一项内容。在设计表示标准的定义中，必须明确给出完整而准确地表示设计结果的标准。从而帮助项目团队用一致的方式来表现其设计结果。在本书4.3节中介绍的PSP设计模板可以作为设计表示标准的基础，项目小组可以基于4个设计模板，再参考设计的层次，合理定义团队设计表示的标准。

复用可以显著提升团队生产效率和质量水平，然而，问题是复用的机会并不是偶然发生的，需要设计人员在项目尽可能的早期加以考虑。“Design For Reuse”被很多软件工程方法识别为最佳实践。这句话就深刻体现了在设计的时候，需要为了创造复用机会而有一些特别的考虑。

Design For Reuse复用性支持

在设计阶段必须要充分考虑复用的可能。为了支持复用，软件项目团队需要建立一套复用管理流程，具体而言，包括

• 复用接口标准
  • 在识别可复用组件的时候，需要以高内聚、低耦合的的设计思想来设计可复用组件。另外，为了便于使用，还得定义复用组件的接口标准，比如参数、变量、返回值以及异常消息的格式与命名等。
• 复用文档标准
  • 通常软件工程师在识别复用组件时，往往直接研究代码，这相当耗时。因此，大部分软件工程师倾向于使用自己开发的复用组件。在团队开发中，为了尽可能提升复用机会，对于可复用组件必须提供详细支持文档，便于团队其他人使用。在文档中需明确组件功能、调用方式、返回值类型以及可能的异常信息。此外，项目团队应当为复用文档定义一个统一的模板和标准。
• 复用质量保证机制
  • 复用组件由于有可能在整个系统的多处被使用，因此，复用组件的质量有尤其重要。否则，复用组件中的一个错误会被传播到软件系统各处。为了获得较高的组件质量，建议采用高质量过程来开发，如PSP2.1过程。另外，还得对待复用组件进行充分的测试。根据过程数据来判断复用组件的质量。

可测试性支持

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

• 一是要尽可能减少测试代码的数量；
• 二是要制定合理的测试计划。

减少测试代码的数量主要通过合理的架构设计来体现。而合理的测试计划对于可测试性的帮助往往被忽视。事实上，充分开展测试计划的开发工作，往往可以在计划阶段就可以发现相当多的缺陷，甚至比真正的测试工作发现的缺陷还要多。完整的设计工作和操作场景定义，有助于更好的开展测试计划工作。

可用性支持

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

实现

评审的考虑

在设计的过程当中，采取的基本策略是自顶向下，逐层精化的策略。这有利于建立系统的整体观。然而，在实现过程当中，应当更多的考虑到是否便于对实现结果的评审。**因此，建议采取的策略是自底向上进行实现。**按照这种策略，在实现的过程中优先实现底层的内容，然后这些底层的模块进行评审，以确保其质量。然后基于有着坚实质量基础的模块，再进行高层实现。

此外，这种策略还有利于复用策略的应用。已经实现了的底层模块有着更多被复用的机会。

复用的考虑

除了上述的自底向上实现策略来支持复用之外，为了更加有效支持复用，还需要其他的一些实践。例如，编码注释的应用和每天站立式会议的应用。编码注释应当使用统一的格式，在每个源码文件的开头明确提供有利于复用的重要信息，如功能、调用方式、异常信息等。必要时，可以结合一些自动化工具来自动收集这些信息，便于查询。

可测性考虑

实现阶段对于可测试性的考虑主要体现在实现的计划必须与测试计划一致，从而避免进行集成测试的时候，部分模块没有实现所带来的不便。

集成

覆盖范围

基本策略

爆炸

该策略将所有已经完成的组件放在一起，进行一次集成。这是一种看起来非常具有吸引力策略。因为这有可能是需要测试用例最少的一种方式。然而，这需要所有待集成的产品组件都具有较高的质量水平，否则，难以定位缺陷位置的缺点会使得该策略消耗很多测试时间。而且，系统越复杂、规模越大，问题越突出。

逐一添加

该策略与上述的大爆炸集成策略完全相反，采取一次添加一个组件的方式进行集成。因此其优点就在于很容易定位缺陷的位置，特别在产品组件质量不高的情况下，每次集成之前都有着坚实的质量基础。但是，该方法的缺点也很突出。这可能是需要测试用例最多的一种策略，而且，大量的回归测试也会消耗很多时间。

集簇式

集簇集成策略是对逐一添加集成策略的改进。简单的随机选择产品组件进行集成并不合理。为了提升测试效率，往往会把有相似功能或者有关联的模块优先进行集成，形成可以工作的组件。然后以组件为单位继续较高层次的集成。此外，这种策略还有一个好处就是，可以尽早获得一些可以工作的组件，有利于其他组件测试工作的开展。但是，这种策略的缺点是过于关注个别组件，而缺乏系统的整体观，不能尽早发现系统层面的缺陷。

扁平化

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

CI/CD是哪一种？逐一添加

V&V验证与确认

概念和区别

Verification 验证

验证(Verification)活动也是检验获得的产品和产品组件能不能满足各自事先定义好的需求规格；

Validation 确认

确认(Validation)活动是为了确保产品可以满足客户的需求以及实际操作场景的要求。

区别

• 验证是目的是确保选定的工作产品与事先指定给该工作产品的需求一致。
• 确认的目标则是确保开发完成的产品或者产品组件在即将要使用该产品或者产品组件的环境中工作正确。

因此，验证关注的是是否正确的把软件产品开发出来，即与需求规格一致；确认关注的是是否开发了正确的软件产品，即是否能帮用户解决实际问题。

关联

验证(Verification)和确认(Validation)都是为了提升最终产品的质量而采取的措施。

**另一方面，验证和确认又是相互依存、关系紧密的两个活动。**验证活动的依据来源于确认的目标，即产品组件需求必须与客户需求一致；验证活动为确认活动提供了前提条件，在完全产品需要和产品组件需求之前，考察客户需求是否满足是没有意义的。

验证与确认活动

环境准备

不管是验证工作还是确认工作，环境非常重要，对于验证工作来说，如果是同行评审，就需要准备文件材料、人员以及会议场所等；如果是测试，则可能需要模拟器、场景生成程序、环境控制以及其他系统接口等。对于确认工作而言，环境的准备更加重要，因为确认要考察的是在真实环境中产品是否工作正常，因此，要求尽可能模拟真实环境和场景。如果是模拟环境，则需要开展分析工作，以弄清模拟环境与真实环境的差别以及对测试结果的影响。

对象选择

不是所有的工作产品都需要进行验证和确认。这一点在项目计划阶段都应当建立起相应的验证计划和确认计划。这里需要明确两个不同的概念，即产品和工作产品。产品是面向客户的，需要向客户提交的工作结果；而工作产品则往往是过程的直接结果。并不是所有的工作产品都需要向客户提交，因此，产品一定是工作产品，而反之则不成立。验证活动的对象往往从工作产品中选择而确认活动的对象则从产品中选择。

活动实施

验证和确认的活动主要就是评审和测试。一般情况下，可以将整个项目生命周期中早期对产品需求评审工作和最后的验收测试作为确认工作，而其他的评审和测试工作当成是验证工作。当然，严格的划分验证活动还是确认活动还是应该从活动本身的目标出发，加以区分。

结果分析

对于验证和确认工作的结果需要进行适当分析，以找出潜在问题和改进机会。如对于设计规格说明书的评审工作之外，应当分析一下设计过程的有效性，预测（Catch and Re-Catch）设计规格说明书中还隐藏的缺陷。对于验收测试结果的分析，往往可以重点考察那些一直遗留到验收阶段才被发现的缺陷，看看这些缺陷在什么阶段被引入，为什么前面未能发现等。

其他

配置管理

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

配置项

• 配置项：在配置管理当中作为单独实体进行管理和控制的工作集合。

基线

• 基线：一个或多个配置项及相关的标识符的代表，是一组经正式审查同意的规格或工作产品集合，是未来开发工作或交付的基础，而且只能经由严格的变更控制程序才能改变。
  • 发布时间点：需求分析后、设计完成后、单元测试后、最终产品发布后
  • 配置项持续演进的稳定基础

配置管理的活动

• 识别和记录配置项的物理特性和功能特性；
• 控制上述特性的变更；
• 记录和报告变更过程和相应的配置项状态；
• 验证配置项是否与需求一致。

配置管理的对象

典型的可能作为配置项纳入配置管理的工作产品包括：

• 过程说明文档
• 项目开发计划文档
• 需求规格说明书
• 设计规格说明书
• 设计图表
• 产品规格说明书
• 程序代码
• 开发环境，如特定版本的编译器等
• 产品数据文件
• 产品技术文件
• 用户支持文档

度量和分析

目的：支持管理的信息需要

意义：基于客观的数据对决策很重要，可以显著消除错误决策的风险。而客观数据的获取需要按照一定的流程用正确的方式获得和使用。度量和分析活动就定义了上述客观数据的获取与使用方式。

度量和分析活动可以支持如下的项目管理活动：

• 客观的估计与计划
• 根据建立的计划和目标，跟踪实际进展
• 识别与解决/过程改进/相关议题
• 提供将度量结果纳入未来其他过程的基础

GQM度量体系

GQM(Goal Question Metric)是一种应用非常广泛的建立软件度量体系的方法，从管理的目标出发，将目标归纳、分解为度量的指标，并把这些指标提炼成可以测量的值，是一种科学的、系统的思考问题的方式。

1. 概念层(目标)：目标是为某个特定的对象而定义的。这里的对象是指软件产品、软件过程以及相关的资源等。定义的目标基于不同原因和不同质量模型,也要参考不同的角色视图与特定的环境。
2. 操作层(问题)：基于一定的刻画上述目标是否达成或者目标达成的进展情况的模型，使用一系列的问题来定义所研究的对象, 然后得出评价或评估特定目标达成进展情况。所选择的问题应当尽量体现质量相关的话题。
3. 量化层(度量)：试图以量化的方式回答上述操作层识别出来的问题。

GQM示例-PM（项目管理）

G: 确保稳定性、可预测性的开发过程来满足计划的里程碑。

Q: 我的项目是否按照计划的轨迹前进，计划的里程碑都能实现吗？

M: 软件项目开发工作的挥发性（分支、流、变更管理活动）。

GQM示例-DM（开发管理）

G: 最大化所有团队贡献者的生产力。

Q: 开发人员能够完成分配给他们的任务吗，或者他们遇到障碍了吗？

M: 由个体或者工作组产生的项目工件的量级

决策分析与解决方案

**决策分析的意义：**错误的决策往往会给项目带来灾难性后果。为了降低这种错误决策的风险，往往需要尽可能基于客观事实和正确的流程来开展决策与分析活动

一个正式评估过程往往包含下列的活动：

• 建立评估备选方案的准则
• 识别备选解决方案
• 选择评估备选方案的方法
• 使用已建立的准则与方法，评估备选解决方案
• 依据评估准则，从备选方案中选择建议方案

“招投标“

根因分析与解决方案

根因分析的意义：

1. 错误的决策往往会给项目带来灾难性后果。为了降低这种错误决策的风险，往往需要尽可能基于客观事实和正确的流程来开展决策与分析活动（同上？）
2. 避免类似错误反复发生

一个正式根因分析过程往往包含下列的活动：

• 识别和选定问题
• 根因分析
• 建立改进的行动方案
• 实施改进，评估效果

2-8法则

约仅有20%的因素影响80%的结果。也就是说：所有变因中，最重要的仅有20%，虽然剩余的80%占了多数，影响的幅度却远低于“关键的少数”。

根因分析典型示例: 鱼骨图

1. 典型角度：技术角度 、人员角度、 培训角度、过程角度

配置管理：配置项和基线

度量和分析：GQM度量体系

决策分析和解决方案：招投标

根因分析和解决方案：2-8选择对象，鱼骨头根因分析

思考

1. 课堂思考练习
2. 本课程要回答的十大问题
3. 软件项目管理和软件过程管理的区别？
4. TSP和SCRUM的团队的组成有哪些共性？这些共性对于高效团队有什么帮助？