软件项目跟踪与监督(PT,PTO) 目的是建立对实际进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施 包括：

Presentation on theme: "软件项目跟踪与监督(PT,PTO) 目的是建立对实际进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施 包括："— Presentation transcript:

1 软件项目跟踪与监督(PT,PTO) 目的是建立对实际进展的适当的可视性，使管理者能在软件项目性能明显偏离软件计划时采取有效措施 包括：
-对照以文档化的估计、约定和计划评审和跟踪软件完成的情况和结果 -基于实际的完成情况和结果调整这些计划

2 相对计划的管理 针对计划和规格说明跟踪进展，包括： -产品规模 -项目工作量、成本和进度 -活动 -风险
针对计划跟踪进展的机制包括：内部评审和(与顾客)一起的正式评审

3 采取纠正措施 如果在计划和实际进展间出现偏差，必须作出判断，是否采取行动 -改变正在进行工作的方式，和/或 -调整计划
这项判断导致纠正措施，原始计划的档案和调整后的计划都应保存 纠正措施必须一跟到底

4 SPTO目标 目标1 对照软件计划跟踪实际结果和性能 目标2 当实际结果和性能明显偏离软件计划时， 采取纠正措施并加以管理直到结束
目标1　对照软件计划跟踪实际结果和性能 目标2　当实际结果和性能明显偏离软件计划时， 采取纠正措施并加以管理直到结束 目标3　对软件约定的更改得到受到影响的组和个人的认可

5

6 关键实践到目标的映射 SPTO-1 目标1:对照软件计划，跟踪实际结果和性能 要求 活动1:将已文档化的软件计划用于跟踪软件活动和传送状态
活动5:跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施

7 关键实践到目标的映射 SPTO-2 目标1:对照软件计划，跟踪实际结果和性能 要求 活动6:跟踪项目的软件工作量和成本，必要时采取纠正措施
活动7: 跟踪项目的关键计算机资源，必要时采取纠正措施 活动8: 跟踪项目的软件进度，必要时采取纠正措施

8 关键实践到目标的映射 SPTO-3 目标1:对照软件计划，跟踪实际结果和性能 要求 活动9:跟踪软件工程技术活动，必要时采取纠正措施
活动10: 跟踪与项目的成本、资源、进度及技术方面有关的软件风险 活动11: 记录软件项目的实际测量数据和重新策划的数据

9 关键实践到目标的映射 SPTO-4 目标1:对照软件计划，跟踪实际结果和性能 要求
活动12:软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进度、计划、性能和问题 活动13: 按照文档化规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果

10

11 关键实践到目标的映射 SPTO-5 目标:2:当实际结果和性能明显偏离软件计划时，采取纠正措施并加以管理直到结束 要求
活动2:按照文档化规程修订项目的软件开发计划 活动5:跟踪软件工作产品的规模（或者软件工作产品更改的规模），必要时采取纠正措施

12 关键实践到目标的映射 SPTO-6 目标:2:当实际结果和性能明显偏离软件计划时，采取纠正措施并加以管理直到结束 要求
活动6:跟踪项目的软件工作量和成本，必要时采取纠正措施 活动7: 跟踪项目的关键计算机资源，必要时采取纠正措施 活动8: 跟踪项目的软件进度，必要时采取纠正措施

13 关键实践到目标的映射 SPTO-7 要求 目标:2:当实际结果和性能明显偏离软件计划时，采取纠正措施并加以管理直到结束
活动9:跟踪软件工程技术活动，必要时采取纠正措施 活动11: 记录软件项目的实际测量数据和重新策划的数据

14

15 关键实践到目标的映射 SPTO-8 要求 目标3:对软件的约定的更改得到受影响的组和个人的认可
活动3: 高级管理者参与按照文档化规程评审对组织外的个人和组所作的软件项目约定和约定的更改 活动4: 将经批准的、影响软件项目约定的更改传达给软件工程组和其它软件一有关组的成员

16

17 共同特点-1 约定1: 设立软件项目经理专门负责PTO活动及结果 约定2: 软件项目的管理遵从文档化的组织方针。该方针规定：
★ 采用并维护一个已文档化的软件开发计划作为跟踪软件项目的基础 ★ 随时向项目经理报告软件项目的状态和问题 ★ 当软件计划未实现时，采取纠正措施，或者调整性能，或者调整计划 ★ 在受影响的组参与和认可的情况下对软件的约定进行更改 ★ 高级管理者评审所有的约定更改和软件项目对组织外部的个人和组所作的新的约定 能力1: 软件开发计划已文档化并得到批准 能力2: 软件项目经理明确分配产品和活动的责任

18 共同特点-2 能力3: 为跟踪和监督活动提供足够的资源和经费 能力4: 软件经理接受管理技术和管理人员方面的培训
能力5: 一线经理受到项目技术方面的定向培训 测量与分析1：进行测量并将测量结果用以确定SPTO活动的状态 验证实施1: 高级管理人员定期对SPTO活动进行评审 验证实施2: 项目经理定期或不定期对SPTO活动进行评审 验证实施3: SQA组对SPTO活动进行评审/审核并报告结果

19 PTO SQA 目的 保证按计划执行 保证按过程执行 焦点 结果 过程 跟踪的基准 SDP中的估计、约定 过程、规程、标准、方针 跟踪内容 l 工作产品的规模、工作量和成本、进度、资源要求（实际值和估计值相比较） l  风险跟踪 l  措施条款跟踪 l  跟踪技术进展 过程活动和工作产品与过程、标准、方针的符合性（过程中隐含计划 ） 跟踪结果 各种跟踪表格 不符合项报告 评审和审计报告 跟踪人 项目负责人和项目工程人员 独立于项目组的SQA人员 方式 全面 抽查

20 进入准则 (1) 已指派负责PTO活动和结果的经理(Co1) (2)已发布组织管理软件项目的方针(Co2)
(3)已存在文档化的SDP(Ab1) (4)已明确地分配关于软件工作产品和活动的任务(Ab2) (5) 有足够的资源/经费(Ab3) (6) 软件经理经过培训(Ab4) (7) 一线经理经过定向培训(Ab5) (8) 存在用于AC2，3，13的规程

21 输入 (1)  软件开发计划（SDP原始及当前的） (2)  软件策划数据 (3)   约定（原始及当前的） (4)   问题报告

22 出口准则 (1)对照软件计划，跟踪了实际结果和性能(G1) (2) 必要时,已采取纠正措施并加以管理直到结束(G2)
(4)需要时，已按规程更新了SDP       (5)已跟踪了风险 (6)已测量和记录了跟踪数据和重新策划数据 (7)受影响的组及时收到有关项目状态的信息

23 部分输出 (1) 措施条款 (2) 实际状态 ①里程碑实际完成情况 ②软件活动实际完成情况 ③实际消耗的工作量（针对已完成的工作）
(1) 措施条款 (2) 实际状态  ①里程碑实际完成情况  ②软件活动实际完成情况  ③实际消耗的工作量（针对已完成的工作）  ④软件项目的各种实际测量数据（如成本、进度、人员消耗等）  ⑤代码的实际规模  ⑥实际发生的风险  ⑦关键计算机资源的实际使用 (3) 经批准的、对软件项目会产生影响的约定更改 (4) 对风险的分析  ①风险发生的可能性  ②高风险区域 ③采取的对策 (5)修订后的SDP (6)有关管理者评审活动的综合报告 (7)重新策划数据

24

25 SPTO与等级2其它KPA的关系 RM:是通过SDP跟踪约定的基础,必要时重新协商约定 SPP:提供SDP及相关的估计、进展等等
SCM：是管理和控制那些跟踪和再策划数据的基础 SQA：评审/审核SPTO的活动和工作产品

26 需要费用的工作 建立方针 培训人员 编制规程 必要时，跟踪和采取改正措施 记录跟踪和再策划数据 测量SPTO活动的状态 评审 -高级管理者
-项目管理者 -SQA -工程组和其他组

27 回报 工程组介入对约定的更改 计划与实际结果相适应 管理计划的活动保持可视 计划已基线化 风险被跟踪和保持可视 跟踪和在策划数据作为财富保存

28 项目控制

29 1. 为什么要控制? 事情不按计划进行： -范围改变 -活动的估计值不同于实际值 -实际问题： *硬件不工作 *通讯连接 -资源 *辞职
*突然离去/意外事故/生病 -未预计的附加活动

30 变化 “管理的中心问题是更好地理解变化，并从变化中抽出有用信息。” 跟踪的数据要分析

31 策划和控制 策划建立目标，控制跟踪现实 跟踪时将实际值与计划值相比较 如果现实与计划不一致，现实必须优先 控制要求不断的修定开发计划
监督与控制的目的是保证在即使偏离计划时仍能实现项目的目标

32 测量的重要性 测量是控制的载体 没有控制 软件工程就不是有效的工程学科 仍然是手工劳作（艺术品）

33 · 控制：搜集数据 从数据中学习 分析数据 解决问题 P：计划将要作什么，并预计效果 D：作；执行计划
C：检查；评估结果，并从结果中学习---控制 A：行动；真正着手去作 “PDCA是管理的核心，即确保今日的工作并开发明日更好的工作方法。” 检查的重要性：“把已有的决策当作是从中吸取经验教训的实验， 那就把PDCA的所有步骤落实。”

34 2. 如何跟踪

35 跟踪的四个问题 跟踪中要解决以下四个问题： ·确定跟踪对象 ·采集信息 ·分析信息 ·报告信息

36 （1）测量量的确定 要采集的度量包括与技术有关的和与管理有关的 在确定要采集的度量时可参照HP的经验：
-从工程实际出发，管理人员和工程人员总结自己工作中实际需要的度量 -采用目标/提问/度量（G/Q/M）的框架： *分析目标 *提出要解决的问题 *从问题中提出度量

37 HP的经验 尽早确定所要采取的度量 采取目标—提问—度量 G1 G2 Q2 Q1 Q4 Q3 M3 M4 M5 M1 M2

38 例子 目标：减少工作量和缩短进度 其中一个问题是：当要求更改代码时，何时作更改，何时不作更改？ 他们分析得出的度量是： M1:问题发生率

39 起步核心测量 SEI建议DOD的软件组织采用四个起步核心测量 -软件规模 -工作量 -进度 -缺陷

40 监控什么 在项目中受监控的典型方面： -进度 -工作量 -总成本 -质量 -范围(scope) -风险 -职员流动
-项目的其它被标识的主要目标 *技能水平改变

41 过程度量 过程度量量化过程或开发环境 例子： -生产率 -质量 -资源度量 -缺陷插入率 -缺陷及其消除率

42 产品度量 产品度量独立于其过程 例子： -规模 -可靠性 -质量（也是过程度量） -代码的复杂性 -功能性

43 过程方法 返工 检查工作的规程 作工作的规程 输入 输出 标准 工具 产品测量 过程测量

44 过程的测量与分析 为什么要采集过程性能数据？要管理过程 就需要： 能预测过程的未来性能 减小过程结果的偏差
人们不能控制那些未测量和理解的东西 这是连续过程改进的基础

45 （2）定义度量的原则 通过G/Q/M方法能确定出与经营目标密切相关的测量和度量。在定义这些度量时，必须考虑以下原则：
·可重复性：其它人能重复测量，得到同样的结果； ·利于交流：对记录的测量结果，其它人能精确地知道它包含什么，不包含什么。测量的单位是什么。

46 数据 数据是控制的核心。管理改进必须基于测量结果 为使数据分析有用，必须了解数据的含义及如何对它作有意义的分析 开始时仅采集一小组有用的数据
管理者需要保证注意力明显地集中在项目所有的关键方面，包括那些难于测量的，不能只关注那些易于测量和跟踪的方面

47 （3）测量量的采集 任何等级都必须采集度量 多数度量存在于开发工作中，必须人人动手采集 过程度量等有瞬时的特点，如不及时采集，无法补救
要预先确定需采集的最小集合，再不断补充

48 与谁有关？ 监控要求小组所有成员参加 从每个小组成员的个人计划开始 在高层次上，处理经过整理的/更为一般的问题

49 如何能采集到正确的数据？ 对事不对人 采用工具

50 （4）项目报告 项目受监控、控制的等级依赖于管理层次 -项目经理要求每日更新 -其它开发经理（例如技术管理者）可能满足于月更新
采集的数据要及时、正确、详细

51 3. 有关SPTO

52 基本的监控 监控活动是否按计划进行 监控缺陷是否均已解决 监控问题是否均已处理 L2:基本的监控 L3:建立监控的门槛值，监控风险……

53 跟踪基线 SPTO针对项目计划进行跟踪 项目计划中列出了跟踪要求，包括被跟踪的主要工作产品、跟踪频度、跟踪机制、跟踪内容
-其跟踪内容除了规模、成本和工作量、进度外，还有风险、资源（包括关键计算机资源），技术活动和纠正措施 计划中列出了被跟踪量的估计值或预测值，它们作为跟踪的基础 跟踪时，将采集的实际值与计划中的估计值相比较，来确定进展。它们有时被称为跟踪基线

54 对软件工程技术活动的跟踪 活动9中提出对软件工程技术活动进行跟踪，这是等级2中唯一与工程技术活动有关的实践。
-要求软件工程组的成员定期向其直接领导报告技术状态，包括活动的进展和问题； -将其交付的供后续工作用的工作产品的内容与计划做比较； -报告任何工作产品中的问题，并建立文档； -跟踪问题到问题结束。

55 纠正措施 如果计划和实际进展间存在明显偏差，就要采取纠正措施。这首先要做评价和判断。
评价：评价项目性能和项目相对计划的状态，决定偏差是否明显，是否需要采取行动。要分析产生偏差的原因。当然首先必须明确定义“明显”的含义。 判断：采取哪种行动。措施项有两种可能： -改变正在进行工作的方式； -调整计划；

56 跟踪方式 跟踪软件工程技术活动，必要时采取纠正措施（如定期报告机制）
软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进度、计划、性能和问题 按照文档化规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果（如同行评审） 各种报告和表格

57 跟踪和监控方式 填写数据采集表格 项目人员定期向其直接领导报告, 其主要方式是填写数据采集表格（如周报，周状态报告）
它们既包括相对计划的进展（管理方面），又包括技术进展和技术问题（技术方面） 一般SPTO需设计和提供适用的对各类人员的跟踪表格。

58 内部评审 内部评审: 软件项目组内部定期进行的评审 目的是跟踪技术进展、计划完成情况、当前状态和问题
一般一线软件经理和软件作业领导参加评审，需要时，和软件经理和其他软件经理一起评审

59 正式评审 里程碑处的正式评审。目的是评价跟踪的结果，进行监控而不是跟踪 评价时使用的材料必须经过有关软件经理的评审和批准
-分析软件活动的约定、计划和状态； -识别出重大问题、相应的措施和做出决策，并建立文档； -分析软件项目风险； -必要时，做出修订软件开发计划的决定。

60 4. 跟踪表格

61 项目报告—进度表 周工时表 周状态报告 在项目进度上， 作状态标记 (PERT/CPM) 活动层监 控的甘特图 进度指示器 —全面监控

62 周工时表

63 个人周状态报告

64 进度监控-甘特图

65 进度指示器—全面监控 到该日止计划要完成的活动数 到该日止计划的要完成的在关键路径上的活动数 进度指示器1=—————————————
到该日止已完成所计划的活动数 进度指示器1=————————————— 到该日止计划要完成的活动数 到该日止已完成的在关键路径上所计划的活动数 进度指示器2=——————————————— 到该日止计划的要完成的在关键路径上的活动数

66 项目报告—工作量 周工时表 周状态报告 进入实际时间， 预计遗留工 作量 工作量表 活动层监控 工作量指示器 -用于全面监控

67 工作量表（活动层监控）

68 工作量指示器-用于全面监控 工作量指示器1=—————————— 工作量指示器2=—————————— 到该日为止总的实际人-小时
总的所计划的完成活动的人-小时 总的所预期的（遗留）+实际的人天 工作量指示器2=—————————— 总的所计划的人天

69 项目报告—成本 成本报告类似于工作量 成本分量： -工作量（可能分别计算正常的和加班的） -出差 -硬件 -软件 -通讯

70 项目报告—质量 缺陷日志/测试日志 Item Wise质量记录 质量指示器 缺陷矩阵

71 Item Wise 质量记录

72 缺陷泄漏矩阵

73 评审的重要性（泄漏缺陷） 返工的费用呈指数式增长 25 需求缺陷 15 设计缺陷 10 编码缺陷 需求评审 设计评审 功能测试 结构测试
静态分析 返工的费用呈指数式增长

74 ------------------------------------------
质量指示器—全面监控 对已完成的QC作业，总的实际缺陷数 对已完成的QC作业，总的预期缺陷数 质量指示器1 = 阶段内发现的总缺陷数 所发现的总缺陷数 质量指示器2 =

75 项目报告—范围 更改请求 范围变化 指示器

76 范围变化指示器 范围指示器2= ----------------------------
由于更改请求所造成的总的工作量(全部经批准的更改请求) 范围指示器1= 到该日为止总的实际工作量 对已批准的，更改请求的总的花费 范围指示器2= 所收到的总的更改请求 所收到的更改请求数 范围指示器3= 时间(所完成的期间或总的计划的期间)

77 缺陷与发现阶段 发现的阶段 缺陷的例子 需求规格说明评审 -不正确的或太强的假定 -不完全的外部界面说明 -过程流不清晰 -需求不可跟踪
-含糊性 -不完全性 项目计划评审 -不恰当的工作量或进度估计 -风险评估有问题 -不恰当的人力安排 -计划不完全 ……

78 缺陷类别 缺陷类别 例子 逻辑 标准 多余的代码 用户界面 性能 重用性 设计问题 存贮管理缺陷 文档缺陷 不一致性 跟踪性 可移植性

79 缺陷问题 关注error-prone模块。如果有重复出现的缺陷，它们经常在同一段代码中出现
许多研究指出，少量缺陷能导致失败中的很大一部分（即，80：20法则） 测量每个模块（或代码段）的缺陷水平并关注其相应的修正措施

80 5. 测量量的利用 开发过程中必须基于度量作分析，不断改进过程（不限于四级）或发现问题 度量放在数据库中供以后项目用
5. 测量量的利用 开发过程中必须基于度量作分析，不断改进过程（不限于四级）或发现问题 度量放在数据库中供以后项目用 估计时最好使用自己的数据 需积累本地区的行业数据

81 状态好坏的标识及措施（L3） □以实际量与估计量的比值来判断状态好坏，该比值称为标志值 □如果比值< ，标志为红色 如果比值 < < ，标志值为兰色 如果比值 < < ，标志值为绿色 □如果规模、工作量、进度、或问题报告的标识值中的任何一个为红色，或者 以上量中有三个同时为兰色，或者 未经策划的活动占至今经策划活动总数的百分比>25%，或者资源方面发生重大问题， 则，必须修订软件开发计划

82 使用度量的例子 如作设计评审：设计文档有20页 估计会有100个缺陷 这次仅发现60个，原因何在？ 同行评审执行得不好？如同行经验不足
同行评审过程有缺陷？ 设计文档质量高？

83 使用数据的例子 合同已签订，项目组评审后发现差2个月。如何能按期交付？

84 测量的好处 测量在以下方面对项目有很大帮助： 项目估计和进展控制 工作产品的评价  通过缺陷分析实现过程改进 对最好实践进行试验确认