2021-软件质量管理-Lec-4 估算、计划和跟踪

0.1. Lec4-估算、计划和跟踪

1. 估算

1.1. 关于估算

1. 估算目的是给各类计划提供决策依据
2. 估算对象（规模、时间和日程）
3. 估算的常见困惑
   1. 项目交付日期、团队组成等都确定了，估算的意义在哪里？
   2. 哪种估算方法好？
   3. 哪个估算结果更好（靠谱）？
   4. 究竟该如何做好估算？

1.2. 估算练习-1

1. 计算一组实数的均值和标准差，用JAVA程序读取文本文件中的一组实数，然后计算其均值和标准差。
2. 尝试估算代码行和所需开发过程（分钟）
   1. 代码行？30行
   2. 开发实践？5分钟

1.3. 关于估算的一些事实

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

那究竟该如何做软件估算？

1.4. 部分相关知识点回顾

1. 软件开发是知识工作——可重复性不高
2. 软件工程师是知识工作者，需要被激励
3. 激励理论的两大因素：
   1. V（价值）：完成这个项目所获得的收益（往往是一定的，个人难以改变）
   2. E（期望/把握）：内心完成这件事情的把握（和个人相关，主观把握）

1.5. PSP和PROBE

1. 规模度量/估算的困境
2. 以 LOC VS. FP 为例
   1. 精确度量方式往往不便于早期规划/估算；
   2. 有助于早期规划/估算的度量往往难以产生精确度量结果；
3. PROBE(PROxy Based Estimation)的作用：精确度量和早期规划之间的桥梁

1.5.1. PROBE原理示例

1. 估算一栋房屋的建造成本，大部分人没有概念。然而，在早期规划中，会有如下认识/需求

序号	用途	相对大小及数量
1	厨房	1个中等大小
2	卧室	1个大卧室；2个小卧室
3	卫生间	1个中等大小；1个小型
4	书房	1个中等大小
5	客厅	1个大客厅

1.5.2. 相对大小矩阵

1.5.3. PROBE 估算流程

1.6. 概要设计

1. 估算的第一步是做出一个概要设计
   1. 概要设计不是真实设计
   2. 与已有产品/组件 相关联
   3. 定义能够产生期望功能的产品元素
   4. 估算你计划构造之物的规模
2. 对于大多数的项目，概要设计都应相对较快地完成：例如，1000LOC 以内程序，试着将概要设计时间限制在10到20分钟之内
3. 为了做出概要设计，需要确定产品功能，以及产生这些功能所需的程序组件/模块：“如果我有以下这些部件，我可以构造这个产品。”
4. 然后，将这些程序组件/模块与你以前写的程序相比较，估算它们的规模
5. 最后，将程序组件/模块估算综合给出总规模
6. “如果你对产品的理解还不足以产出一个概要设计，那么你所知道的还不足以做出一个计划”

1.7. 估算练习-2

1. 计算一组实数的均值和标准差，用JAVA程序读取文本文件中的一组实数，然后计算其均值和标准差
2. 试完成概要设计之后，估算代码行和所需开发时间（分钟）
   1. 代码行
   2. 开发时间

1.8. 整合多个估算结果

1. 整合一个开发人员做的多个估算
   1. 累积各个部分的估算
   2. 进行一次线性回归计算
   3. 计算一个预测区间
2. 多个开发人员可以整合独立进行的估算，通过以下方式
   1. 进行单独的线性回归预测
   2. 将计划的规模或者时间相加
   3. 将个人范围的平方相加，再对其计算平方根获得预测区间

1.9. 估算误差：示例

1. 对于一项估算精度为± 50%的1000小时的工作，估算范围就是从500到1500小时。
2. 如果估算被分成独立的25个部件，每个存在50%的误差，那么
   1. 总时间会和前面一样是1000小时
   2. 估算范围会是从900到1100小时
3. 当估算多个部件时，总的误差会比各个部件误差的总和要小。
   1. 误差趋于抵消了
   2. 假设没有共同的偏差
4. 估算要点之一：尽可能划分详细一些

1.10. SCRUM 中的Story point

1. 度量实现一个故事（Story）需要付出的工作量
   1. 抽象的：混合了对于开发特性（feature）所要付出的努力、开发复杂度、个中风险以及类似东西
   2. 相对的：设定标准之后，考虑其他特性（feature）与标准之间的相对大小关系
      1. Fibonacci: 0, 1, 1, 2, 3, 5, 8, 13, 21,34, 55, 89
      2. 拆分
2. 估算要点之二：建立对结果的信心
3. 估算要点之三：依赖数据

1.11. 关于估算方法的反思

1. 估算的目标
   1. 规模估算VS. 时间估算——估算结果重要吗？
   2. 估算要点之四：估算要的是过程，而非结果；估算的过程是相关干系人达成一致共识的过程
2. 怎么做估算
   1. 达成共识
   2. 建立信心
      1. 足够详细
      2. 依赖数据
      3. 最好的猜测（注意检验猜测所依据的假设）
3. 思考题：PROBE方法如何实现上述估算要点？

1.11.1. 相对大小矩阵（C++语言）

1.11.2. 线性回归调整规模估算

1. 如果线性相关，那么就可以使用线性回归。上面的式子可以计算出plan size。
2. 这个线不是45度，是受到估算误差和方法外代码的数量共同影响。

1.11.3. 线性回归调整时间估算

1. 该方法没有使用生产效率进行计算，为什么在PROBE中不使用生产效率？
   1. 这样子使用好不好？因为Plan Size是在一个范围内波动，生产效率也在一个范围内波动，如果将生产效率作为分母，那么可能会导致更大的误差，也就违背了误差的出发点。
   2. 为什么不是用plan size / 生产效率 得到 plan time

2. 估算能力的衡量：
   1. 越接近于回归线，估算能力越强。
   2. 估算能力的强弱看的是多稳定，而不是多接近具体的实际情况。

1.12. 预测区间

1. 置信度越高，置信区间越大。

2. 历史数据的获取 —— 度量

1. 关于度量的争议：度量体现着决策者对试图要实现的目标的关切程度
2. GQM 和GQM+度量体系构建
   1. GQM是对应三个部分
3. PSP基本度项
   1. 规模
   2. 时间
   3. 缺陷
   4. 日程（TSP）
4. 用户和高层关心的问题：什么时候完成、质量怎么样、成本怎么样

2.1. PSP时间度量（时间日志）

2.2. 时间日志示例

2.3. PSP缺陷度量（缺陷日志）

2.4. 历史数据的处理

2.4.1. 某人的历史数据

2.4.2. 简单方法

1. 基本思想是:
   1. 将每个方法的代码行数进行排序
   2. 选择最小值作为VS；
   3. 选择最大值作为VL；
   4. 选择中值作为M；
   5. 选择VS与M的均值作为S；
   6. 选择VL与M的均值作为L。
2. 计算结果：VS = 9.333，VL = 32，M = 12或者13，S = 11.2，L = 22.5。

2.4.3. 正态分布法

1. 使用正态分布法的计算方法如下：
   1. 选择所有数据的均值作为M，计算所有数据的标准差σ。
   2. 那么S = M-σ ，VS = M-2σ ，L = M+σ ，VL=M+2σ
2. 计算结果：
   1. 在上述例子中，VS=-1.67，S=7.68，M=17.04，L=26.39，VL=35.75。

2.4.4. 对数正态分布

1. 大部分人习惯写很多规模很小的程序，少量规模较大的程序
2. 此外，程序的规模不可能出现负数
3. 用e作为自然对数，如何进行处理？
4. 计算方法：
   1. 以e为底计算所有数据的自然对数；
   2. 计算取对数之后的值的均值作为M，计算相应标准差σ。
   3. 那么S=M-σ，VS=M-2σ，L=M+σ，VL=M+2σ 。
   4. 取反对数；
5. 计算结果：
   1. VS = 5.55，S =9.19，M = 15.22，L = 25.21，VL = 41.75。
6. 长期使用相对矩阵会稳定

2.4.5. 三种方法对比

1. 简单方法：计算简单，但是，不稳定
2. 正态分布法：相对稳定，在历史数据基本符合正态分布的情况下，可以给出非常好的相对大小矩阵
3. 对数正态分布法：更加符合人们对于程序的规模的直观感觉

2.4.6. 相关性

1. PROBE方法依赖历史数据，但是实际历史数据有可能
   1. 历史数据少于3个数据点；
   2. 有足够的历史数据，但是数据的质量不高
2. 相关性描述的是两组变化的数据之间相互关联的程度;
3. 一般情况下，为确保估算质量，对于历史数据的相关性要求r≥0.7。

4. 显著性
   1. 它描述的是上述两组数据的相关关系出现的偶然性
   2. 因此，显著性越小越好。软件工程很多场合下要求显著性s≤0.05（即所谓p值）

2.4.7. PROBE 估算规模

1. 使用一次D方法，就可以使用C方法
2. 使用三次D方法，就可以使用B方法

2.4.8. 极端数据

1. PROBE A方法和B方法的时候，对于数据的相关性有要求。
2. 然而很多时候，历史数据中的一些极端数据会造成相关性的“假象”。

r=0.26	r = 0.91

2.5. 内容

1. 估算
   1. 估算概述
   2. PSP和PROBE
   3. SCRUM和故事点
2. 计划和跟踪
   1. 团队项目规划工作分解结构、开发策略与计划、生命周期模型、日程/质量/风险计划等
   2. 团队项目跟踪与管理、挣值管理、里程碑评审、纠偏活动管理
3. 项目总结

3. 工作分解结构

1. WBS定义
   1. WBS作用
   2. 范围基线
   3. 提供整体观
   4. 不遗漏可交付物
   5. 明确各个角色的责任
   6. 工作包定义
   7. 估算和计划的基础
   8. 理解工作，分析风险
2. WBS示例

3.1. 创建WBS方法

1. 识别和分析可交付成果及相关工作；
2. 确定工作分解结构的结构与编排方法；
3. 自上而下逐层细化分解；
4. 为工作分解结构组成部分制定和分配标志编码；
5. 核实工作分解的程度是必要且充分的

3.2. 好的WBS检查标准

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

3.3. 范围管理

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

3.4. 开发策略与计划

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

3.5. 过程架构-生命周期模型

3.6. 通用计划框架

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

3.7. 日程计划原理和方法

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

3.8. 任务清单

3.9. 资料清单

3.10. 日程计划

3.11. 质量计划原理和方法

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

3.12. 风险计划

1. 风险管理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命周期中规划和实施风险管理活动，以消除潜在问题对项目产生的负面影响。
2. 风险管理大致分成两部分，即风险识别和风险应对。

3.12.1. 风险识别

风险：没有发生，有一定概率发生，发生后有一定影响，才是风险。

问题：已经发生的，比如人员调动等

1. 识别与成本、进度及绩效相关的风险
2. 审查可能影响项目的环境因素
3. 审查工作分解结构的所有组件，作为风险识别的一部分，以协助确保所有的工作投入均已考虑
4. 审查项目计划的所有组件，作为风险识别的一部分，以确保项目在各方面均已考虑
5. 记录风险的内容、条件及可能的结果
6. 识别每一风险相关的干系人
7. 利用已定义的风险参数，评估已识别的风险
8. 依照定义的风险类别，将风险分类并分组
9. 排列降低风险的优先级
10. 可能性很低，但是发生影响程度很大：政策变化、领导层大规模变动、公司倒闭
11. [P（可能性）, I（影响程度）, T(阈值)]

3.12.2. 风险应对

1. 识别风险之后，就应当制定相应的风险管理策略，以应对各类风险。
2. 典型的策略包括
   1. 风险转嫁
   2. 风险解决
   3. 风险缓解

3.13. 计划评审和各方承诺

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

3.14. 项目跟踪意义

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

3.15. 挣值管理方法

1. 项目的挣值管理方法(Earned Value Management，简称EVM)是用来客观度量项目进度的一种项目管理方法。
   1. 每项任务实现附以一定价值（credit）
   2. 100%完成该项任务，就获得相应价值
2. EVM采用与进度计划、成本预算和实际成本相联系的三个独立的变量，进行项目绩效测量。
   1. 简单实现：添加挣值（EV）
   2. 中级实现：添加成本线（AC）
   3. 高级实现：添加预测线（BAC），当任务足够多的时候，我们就可以让预测线尽可能平直，同时我们延伸挣值（EV），找到与预测线（BAC）的交点，我们就可以明确项目的落后时间
3. 这套方法直接应用到软件项目中会存在问题。
4. 在软件项目中，计划投入的时间作为挣值比较合适。

3.15.1. 挣值分析图示

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. 挣值管理会带来什么好处？可以很好的适应项目的动态变化。

3.15.2. 常用EVM度量

1. BAC表示按照PV值的曲线，当项目完成的时候所需预算或者时间
2. 成本差异CV = EV-AC
3. 成本差异指数CPI = EV/AC
4. 日程偏差SV = EV – PV
5. 日程偏差指数SPI = EV/PV
6. 预计完成成本EAC = AC+(BAC-EV)/CPI = BAC/CPI

3.15.3. EVM应用示例（讨论）

1. Plan(计划投入时间)，Actual（实际投入时间）
2. 虽然现在没有落后，但是暴露了隐患

3.15.4. 另外一种EVM的变形——燃尽图

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

3.15.5. EVM的局限性

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

3.16. 里程碑评审

1. 软件项目的里程碑往往是指某个时间点，用以标记某项工作的完成或者阶段的结束。
2. 审查的内容包括：
   1. 项目相关的承诺，如日期、规格、质量等等；
   2. 项目各项计划的执行状况；
   3. 项目当前的状态讨论；
   4. 项目面临的风险讨论等

3.17. 其他计划跟踪

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

3.18. 纠偏活动的管理

1. 典型的纠偏活动包括
   1. 偏差原因分析
   2. 纠偏措施定义
   3. 纠偏措施管理
2. 0-100原则：只要没有全部完成，就没有。
3. 50-50原则：只要宣称开始做，就有50

3.19. 项目总结的意义

1. 软件项目的特点决定了持续改善对于软件工程师的重要性。
2. Rita Mae Brown在书中写到的那样“所谓的愚蠢（Insanity）就是反复做同样的事情，但是期望有不同的结果”
3. 提供一个系统化的方式来总结经验教训、防止犯同样的错误、评估项目团队绩效、积累过程数据等。提供给项目团队成员持续学习和改进的机会。

3.19.1. 项目总结过程

1. 项目总结需要系统化有条理的进行，才能不遗漏重要的内容。因此往往需要事先定义总结过程，然后按部就班开展总结工作。
2. 一般情况下，项目总结都包括
   1. 准备阶段
   2. 总结阶段
   3. 报告阶段

3.20. 基于PMBOK的总结

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

3.20.1. 范围管理

1. 项目范围包括产品范围和项目范围。对项目范围管理的总结应当主要关注项目的需求开发过程与变更管理中的得失，对需求管理实际执行情况的差距进行原因分析，找到改进的机会。典型的问题包括
   1. 是否有未被识别的需求？
   2. 是否有没有得到响应的需求变更？
   3. 需求是否出现蔓延现象等。

3.20.2. 时间管理

1. 项目时间管理所关注的就是项目的日程计划以及对日程计划的跟踪和管理状况。因此主要考察计划的准确程度以及各个里程碑的偏差情况。
   1. 估算偏差有多大？
   2. 日程计划准确程度如何？
   3. 里程碑偏差有多大？
   4. 日程计划有什么变更？为什么？

3.20.3. 成本管理

1. 成本管理包括对成本进行估算、预算和控制的各个过程，从而确保项目在批准的预算内完工
   1. 项目计划投入总时间是多少？实际是多少？
   2. 各个阶段计划投入时间是多少？实际是多少？
   3. 偏差的原因是什么？

3.20.4. 质量管理

1. 项目质量管理包括执行组织确定质量政策、目标与职责的各过程和活动，从而使项目满足其预定的需求。
   1. 项目整体质量状况如何？
   2. 验收测试缺陷率是多少？
   3. 有没有办法在前期消除这些缺陷？

3.20.5. 项目人力资源管理

1. 项目人力资源管理包括组织、管理与领导项目团队的各个过程。
   1. 项目的生产效率如何？
   2. 每个人的生成效率如何？
   3. 每个人对项目的满意程度如何？
   4. 有没有提升的办法？

3.20.6. 项目沟通

1. 项目沟通管理包括为确保项目信息及时且恰当地生成、收集、发布、存储、调用最终处置所需的各个过程
   1. 项目有没有因为沟通不够导致问题？
   2. 各个项目干系人沟通手段有哪些？有没有需要总结的经验教训？
   3. 什么样的沟通方法最为有效？

3.20.7. 项目风险管理

1. 项目风险管理包括风险管理规划、风险识别、风险分析、风险应对规划和风险监控等各个过程。
2. 哪些问题在前期没有预料的相应的风险？为什么？
   1. 哪些风险应对措施比较有效？
   2. 就组织层面考察，哪些风险发生的频度较高？
   3. 整个风险管理有哪些经验教训？

3.20.8. 采购管理

1. 项目采购管理包括从项目组织外部采购或获得所需产品、服务或成果的各个过程。
   1. 项目方案是否合理？
   2. 各类采购而得的工具是否合用？
   3. 供应商服务的评价？
   4. 采购相应的成本和风险考虑？
   5. 项目合同管理的经验教训有哪些？

3.20.9. 整合管理

1. 项目整合管理包括为识别、定义、组合、统一与协调项目管理过程组的各过程及项目管理活动而进行的各种过程和活动
   1. 各类计划之间是否协调一致？
   2. 团队章程的执行状况怎样？
   3. 项目变更的处理流程是否有效？
   4. 项目完成之后相应的产物是否得到妥善保存？
   5. 有没有对组织过程资产的更新？

3.21. TSP项目总结介绍

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

3.22. TSP总结过程阶段

1. 准备阶段
2. 过程数据评审阶段
3. 人员角色评价阶段
4. 总结报告撰写阶段

3.22.1. 过程数据评审阶段

1. 该阶段往往由过程经理或者质量经理带领整个团队分析过程数据，识别过程改进机会。
2. 可以结合典型TSP团队角色，逐个讨论改进领域。如团队领导力、计划准确性、过程优劣、质量管理能力、开发环境以及配置管理等。
3. 此外，也可以就TSP教练的作用进行评价。
4. 过程数据评审阶段还要求开发团队的所有成员都整理过程改进提案（PIP）。

3.22.2. 人员角色评审-项目组长

1. 项目组长的角色评审应当从领导力角度开考察团队的表现。
2. 重点关注团队激励和团队承诺方面的问题。
3. 项目会议的组织情况也需要总结。比如，会议效果、讨论技巧等。
4. 此外，还应当就如何在下一周期做得更好提出改进建议。

3.22.3. 人员角色评审-计划经理

1. 计划经理主要关注项目进度，因此，在总结阶段需要就估算、生产效率、里程碑等话题进行总结。例如：
   1. 项目产品规模的估算值和实际值有多大的偏差？为什么有这些偏差？
   2. 项目的计划开发时间以实际开发时间有没有偏差？原因是什么？
   3. 项目整体的生产效率是多少？
   4. 人均资源水平有多少？
   5. 项目的PV与EV趋势是什么？为什么有偏差？
   6. 跟以前的开发周期相比，生产效率有没有提升？为什么？
   7. 下一个开发周期需要如何提升？

3.22.4. 人员角色评审-开发经理

1. 开发经理进行总结的时候，应当从开发内容和开发策略角度出发，总结得失。例如：
   1. 将实际开发结果与计划开发内容进行对比，看看是否完全实现需求？
   2. 或者从开发策略角度考察，看看事先定义的开发策略是否有效?如何改进？
2. 此外，开发经理也应当就质量话题提出见解。比如:
   1. 现有的设计和实现步骤是否有助于质量目标的实现？
   2. 对于可用性、性能以及兼容性等其他高层次质量要求，现有的设计方法和实现平台是否可以支持？
   3. 现有的质量度量方式效果如何？未来怎样改进？

3.22.5. 人员角色评审-质量经理

1. 质量经理的总结则应该从项目整体质量状况出发，总结质量目标的实现过程，并找出改进机会。因此，可以就如下一些问题开展讨论：
   1. 项目整体质量状况如何？质量目标实现了吗？为什么？
   2. 是否所有预定的质量管理活动都开展了？如果没有，为什么
   3. 项目进展过程中，质量趋势是什么？
   4. 每个阶段的yield分别是什么？为什么有的过低？
   5. 测试开始之后有多少缺陷？哪些缺陷可以通过什么样的方式在前期排除？
   6. 现有的质量管理手段的效果如何？有哪些需要改进？

3.22.6. 人员角色评审-过程经理

1. 过程经理关注团队遵循过程的程度和过程改进方案。因此，在项目总结阶段，过程经理需要总结的问题为：
   1. 是否所有人都如实记录数据？
   2. 团队成员对过程遵循状况如何？为什么？
   3. 记录的过程数据说明了什么？
   4. 现有的过程有哪些不足？
   5. 所有的PIP都提交了吗？
   6. 哪些PIP值得在下个周期实现？如果要实现，对现有过程需要做什么样的调整？

3.22.7. 人员角色评审-支持经理

1. 支持经理主要关注配置管理状况、问题和风险跟踪机制以及复用策略的支持等话题。因此，在项目总结阶段，支持经理需要总结的问题为：
   1. 项目团队开发环境是否合用？
   2. 项目过程中，对于配置项出现了几次变更？原因分别是什么？未来如何改进？
   3. 配置管理活动开展情况如何？是否有未经授权的配置项修改现象出现？
   4. 风险和问题跟踪机制是否有效？是否所有问题都得到处理？
   5. 风险有没有导致对项目的负面影响？
   6. 哪些风险一开始没有被识别出来？
   7. 复用策略是否有效？
   8. 对比上一阶段，复用比例是否上升？为什么？怎么改进？

3.23. 人员角色评审-工程师

1. 此外，由于大部分角色经理同时充当着软件工程师的角色，因此，还需要就工程师角色的工作状况进行总结。工程师重点关注的就是个人的绩效（生产效率、质量水平等）。因此，需要总结的问题包括：
   1. 个人计划的绩效与实际的绩效有没有差别？为什么有偏差？
   2. 对比上个周期有没有进步？为什么？
   3. 下个开发周期将如何改进？
   4. 根据个人总结的PIP，你觉得最值得改进的有哪些内容

4. 引言

1. 引言
2. 角色报告
   1. a项目组长
   2. 开发经理
   3. c计划经理
   4. d过程经理
   5. e质量经理
   6. f支持经理
3. 工程师报告
4. 参考材料

5. 之前的

5.1. PSP简介

5.1.1. PSP渊源和作用

1. 过程改进运动
   1. TQM
   2. Humphrey早期工作
   3. PSP/TSP
2. PSP作用
   1. 个人级管理实践和过程估算和计划
   2. 承诺和拒绝承诺
   3. 理解和改进
   4. 工业水准的过程和规范
   5. 客观决策的数据

5.1.2. 什么是PSP？

1. PSP是包括了数据记录表格、过程操作指南和规程在内的结构化框架。
2. 一个基本的PSP流程包括策划、设计、编码、编译、单元测试以及总结等阶段。
3. 在每个阶段，都有相应的过程操作指南，用以指导该阶段的开发活动
4. 所有的开发活动都需要记录相应的时间日志与缺陷日志。

5.1.3. 典型PSP过程

5.1.4. PSP基本原理

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

5.1.5. PSP不同级别

5.1.6. PSP过程度量

1. 关于度量的争议：度量体现着决策者对试图要实现的目标的关切程度
2. GQM 和 GQM+度量体系构建
3. PSP基本度项
   1. 规模
   2. 时间
   3. 缺陷
   4. 日程（TSP）

5.1.7. PSP时间度量（时间日志）

5.1.8. 时间日志示例

5.1.9. PSP缺陷度量（缺陷日志）

5.1.10. PSP缺陷类型度量标准

5.1.11. 规模度量的困境

1. 精确的度量方式往往不便于早期规划；
2. 有助于早期规划的度量往往难以产生精确度量结果；
3. LOC VS. FP?
4. PROBE的作用

5.2. PROBE估算方法讨论

5.2.1. PROBE原理示例

5.2.2. 相对大小矩阵

• c++语言

5.2.3. PROBE估算流程

5.2.3.1. 线性回归调整规模估算

5.2.3.2. 线性回归调整时间估算

5.2.3.3. 预测区间

5.2.4. 通用计划框架

5.2.4.1. 历史数据的处理

page 22

6. 计划和跟踪

6.1. 团队项目规划

工作分解结构、开发策略与计划、生命周期模型、日程质量/风险计划等。

6.2. 团队项目跟踪与管理

挣值管理、里程碑评审、纠偏活动管理

7. 项目总结