840 likes | 941 Views
软件项目跟踪与监督 (PT,PTO). 目的是建立对实际进展的适当的可视性,使管理者能在软件项目性能明显偏离软件计划时采取有效措施 包括: - 对照以文档化的估计、约定和计划评审和跟踪软件完成的情况和结果 - 基于实际的完成情况和结果调整这些计划. 相对计划的管理. 针对计划和规格说明跟踪进展,包括: - 产品规模 - 项目工作量 、 成本和进度 - 活动 - 风险 针对计划跟踪进展的机制包括:内部评审和 ( 与顾客 ) 一起的正式评审. 采取纠正措施. 如果在计划和实际进展间出现偏差,必须作出判断,是否采取行动 - 改变正在进行工作的方式,和 / 或
E N D
软件项目跟踪与监督(PT,PTO) • 目的是建立对实际进展的适当的可视性,使管理者能在软件项目性能明显偏离软件计划时采取有效措施 • 包括: -对照以文档化的估计、约定和计划评审和跟踪软件完成的情况和结果 -基于实际的完成情况和结果调整这些计划
相对计划的管理 • 针对计划和规格说明跟踪进展,包括: -产品规模 -项目工作量、成本和进度 -活动 -风险 • 针对计划跟踪进展的机制包括:内部评审和(与顾客)一起的正式评审
采取纠正措施 • 如果在计划和实际进展间出现偏差,必须作出判断,是否采取行动 -改变正在进行工作的方式,和/或 -调整计划 • 这项判断导致纠正措施,原始计划的档案和调整后的计划都应保存 • 纠正措施必须一跟到底
SPTO目标 目标1 对照软件计划跟踪实际结果和性能 目标2 当实际结果和性能明显偏离软件计划时, 采取纠正措施并加以管理直到结束 目标3 对软件约定的更改得到受到影响的组和个人的认可
关键实践到目标的映射SPTO-1 • 目标1:对照软件计划,跟踪实际结果和性能 要求 • 活动1:将已文档化的软件计划用于跟踪软件活动和传送状态 • 活动5:跟踪软件工作产品的规模(或者软件工作产品更改的规模),必要时采取纠正措施
关键实践到目标的映射SPTO-2 • 目标1:对照软件计划,跟踪实际结果和性能 要求 • 活动6:跟踪项目的软件工作量和成本,必要时采取纠正措施 • 活动7: 跟踪项目的关键计算机资源,必要时采取纠正措施 • 活动8: 跟踪项目的软件进度,必要时采取纠正措施
关键实践到目标的映射SPTO-3 • 目标1:对照软件计划,跟踪实际结果和性能 要求 • 活动9:跟踪软件工程技术活动,必要时采取纠正措施 • 活动10: 跟踪与项目的成本、资源、进度及技术方面有关的软件风险 • 活动11: 记录软件项目的实际测量数据和重新策划的数据
关键实践到目标的映射SPTO-4 • 目标1:对照软件计划,跟踪实际结果和性能 要求 • 活动12:软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进度、计划、性能和问题 • 活动13: 按照文档化规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果
关键实践到目标的映射SPTO-5 • 目标:2:当实际结果和性能明显偏离软件计划时,采取纠正措施并加以管理直到结束 要求 • 活动2:按照文档化规程修订项目的软件开发计划 • 活动5:跟踪软件工作产品的规模(或者软件工作产品更改的规模),必要时采取纠正措施
关键实践到目标的映射SPTO-6 • 目标:2:当实际结果和性能明显偏离软件计划时,采取纠正措施并加以管理直到结束 要求 • 活动6:跟踪项目的软件工作量和成本,必要时采取纠正措施 • 活动7: 跟踪项目的关键计算机资源,必要时采取纠正措施 • 活动8: 跟踪项目的软件进度,必要时采取纠正措施
关键实践到目标的映射SPTO-7 • 目标:2:当实际结果和性能明显偏离软件计划时,采取纠正措施并加以管理直到结束 要求 • 活动9:跟踪软件工程技术活动,必要时采取纠正措施 • 活动11: 记录软件项目的实际测量数据和重新策划的数据
关键实践到目标的映射SPTO-8 • 目标3:对软件的约定的更改得到受影响的组和个人的认可 要求 • 活动3: 高级管理者参与按照文档化规程评审对组织外的个人和组所作的软件项目约定和约定的更改 • 活动4: 将经批准的、影响软件项目约定的更改传达给软件工程组和其它软件一有关组的成员
共同特点-1 • 约定1: 设立软件项目经理专门负责PTO活动及结果 • 约定2: 软件项目的管理遵从文档化的组织方针。该方针规定: ★ 采用并维护一个已文档化的软件开发计划作为跟踪软件项目的基础 ★ 随时向项目经理报告软件项目的状态和问题 ★ 当软件计划未实现时,采取纠正措施,或者调整性能,或者调整计划 ★ 在受影响的组参与和认可的情况下对软件的约定进行更改 • ★ 高级管理者评审所有的约定更改和软件项目对组织外部的个人和组所作的新的约定 • 能力1: 软件开发计划已文档化并得到批准 • 能力2: 软件项目经理明确分配产品和活动的责任
共同特点-2 • 能力3: 为跟踪和监督活动提供足够的资源和经费 • 能力4: 软件经理接受管理技术和管理人员方面的培训 • 能力5: 一线经理受到项目技术方面的定向培训 • 测量与分析1:进行测量并将测量结果用以确定SPTO活动的状态 • 验证实施1: 高级管理人员定期对SPTO活动进行评审 • 验证实施2: 项目经理定期或不定期对SPTO活动进行评审 • 验证实施3: SQA组对SPTO活动进行评审/审核并报告结果
进入准则 (1)已指派负责PTO活动和结果的经理(Co1) (2)已发布组织管理软件项目的方针(Co2) (3)已存在文档化的SDP(Ab1) (4)已明确地分配关于软件工作产品和活动的任务(Ab2) (5) 有足够的资源/经费(Ab3) (6) 软件经理经过培训(Ab4) (7) 一线经理经过定向培训(Ab5) (8) 存在用于AC2,3,13的规程
输入 (1)软件开发计划(SDP原始及当前的) (2)软件策划数据 (3)约定(原始及当前的) (4)问题报告
出口准则 (1)对照软件计划,跟踪了实际结果和性能(G1) (2) 必要时,已采取纠正措施并加以管理直到结束(G2) (3) 受影响的组和个人同意对约定的更改(G3) (4)需要时,已按规程更新了SDP (5)已跟踪了风险 (6)已测量和记录了跟踪数据和重新策划数据 (7)受影响的组及时收到有关项目状态的信息
部分输出 (1) 措施条款 (2) 实际状态 ①里程碑实际完成情况 ②软件活动实际完成情况 ③实际消耗的工作量(针对已完成的工作) ④软件项目的各种实际测量数据(如成本、进度、人员消耗等) ⑤代码的实际规模 ⑥实际发生的风险 ⑦关键计算机资源的实际使用 (3) 经批准的、对软件项目会产生影响的约定更改 (4) 对风险的分析 ①风险发生的可能性 ②高风险区域 ③采取的对策 (5)修订后的SDP (6)有关管理者评审活动的综合报告 (7)重新策划数据
SPTO与等级2其它KPA的关系 • RM:是通过SDP跟踪约定的基础,必要时重新协商约定 • SPP:提供SDP及相关的估计、进展等等 • SCM:是管理和控制那些跟踪和再策划数据的基础 • SQA:评审/审核SPTO的活动和工作产品
需要费用的工作 建立方针 培训人员 编制规程 必要时,跟踪和采取改正措施 记录跟踪和再策划数据 测量SPTO活动的状态 评审 -高级管理者 -项目管理者 -SQA -工程组和其他组
回报 工程组介入对约定的更改 计划与实际结果相适应 管理计划的活动保持可视 计划已基线化 风险被跟踪和保持可视 跟踪和在策划数据作为财富保存
1. 为什么要控制? • 事情不按计划进行: -范围改变 -活动的估计值不同于实际值 -实际问题: *硬件不工作 *通讯连接 -资源 *辞职 *突然离去/意外事故/生病 -未预计的附加活动
变化 “管理的中心问题是更好地理解变化,并从变化中抽出有用信息。” 跟踪的数据要分析
策划和控制 • 策划建立目标,控制跟踪现实 • 跟踪时将实际值与计划值相比较 • 如果现实与计划不一致,现实必须优先 • 控制要求不断的修定开发计划 • 监督与控制的目的是保证在即使偏离计划时仍能实现项目的目标
测量的重要性 • 测量是控制的载体 • 没有控制 软件工程就不是有效的工程学科 仍然是手工劳作(艺术品)
从数据中学习 ·控制:搜集数据 分析数据 解决问题 • P:计划将要作什么,并预计效果 D:作;执行计划 C:检查;评估结果,并从结果中学习---控制 A:行动;真正着手去作 • “PDCA是管理的核心,即确保今日的工作并开发明日更好的工作方法。” • 检查的重要性:“把已有的决策当作是从中吸取经验教训的实验, 那就把PDCA的所有步骤落实。”
跟踪的四个问题 • 跟踪中要解决以下四个问题: ·确定跟踪对象 ·采集信息 ·分析信息 ·报告信息
(1)测量量的确定 • 要采集的度量包括与技术有关的和与管理有关的 • 在确定要采集的度量时可参照HP的经验: -从工程实际出发,管理人员和工程人员总结自己工作中实际需要的度量 -采用目标/提问/度量(G/Q/M)的框架: *分析目标 *提出要解决的问题 *从问题中提出度量
HP的经验 • 尽早确定所要采取的度量 • 采取目标—提问—度量 G1 G2 Q2 Q1 Q4 Q3 M3 M4 M5 M1 M2
例子 • 目标:减少工作量和缩短进度 • 其中一个问题是:当要求更改代码时,何时作更改,何时不作更改? • 他们分析得出的度量是: M1:问题发生率 M2:缺陷密度 M3:代码稳定性 M4:复杂性 M5:要更改的模块数
起步核心测量 • SEI建议DOD的软件组织采用四个起步核心测量 -软件规模 -工作量 -进度 -缺陷
监控什么 • 在项目中受监控的典型方面: -进度 -工作量 -总成本 -质量 -范围(scope) -风险 -职员流动 -项目的其它被标识的主要目标 *技能水平改变
过程度量 过程度量量化过程或开发环境 例子: -生产率 -质量 -资源度量 -缺陷插入率 -缺陷及其消除率
产品度量 产品度量独立于其过程 例子: -规模 -可靠性 -质量(也是过程度量) -代码的复杂性 -功能性
过程方法 返工 检查工作的规程 作工作的规程 输入 输出 标准 工具 产品测量 过程测量
过程的测量与分析 为什么要采集过程性能数据?要管理过程 就需要: • 能预测过程的未来性能 • 减小过程结果的偏差 人们不能控制那些未测量和理解的东西 这是连续过程改进的基础
(2)定义度量的原则 • 通过G/Q/M方法能确定出与经营目标密切相关的测量和度量。在定义这些度量时,必须考虑以下原则: ·可重复性:其它人能重复测量,得到同样的结果; ·利于交流:对记录的测量结果,其它人能精确地知道它包含什么,不包含什么。测量的单位是什么。
数据 数据是控制的核心。管理改进必须基于测量结果 为使数据分析有用,必须了解数据的含义及如何对它作有意义的分析 开始时仅采集一小组有用的数据 管理者需要保证注意力明显地集中在项目所有的关键方面,包括那些难于测量的,不能只关注那些易于测量和跟踪的方面
(3)测量量的采集 • 任何等级都必须采集度量 • 多数度量存在于开发工作中,必须人人动手采集 • 过程度量等有瞬时的特点,如不及时采集,无法补救 • 要预先确定需采集的最小集合,再不断补充
与谁有关? • 监控要求小组所有成员参加 • 从每个小组成员的个人计划开始 • 在高层次上,处理经过整理的/更为一般的问题
如何能采集到正确的数据? 对事不对人 采用工具
(4)项目报告 • 项目受监控、控制的等级依赖于管理层次 -项目经理要求每日更新 -其它开发经理(例如技术管理者)可能满足于月更新 • 采集的数据要及时、正确、详细