软件项目跟踪与监督

软件项目跟踪与监督 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的所有步骤落实 2 如何跟踪 跟踪的四个问题 跟踪中要解决以下四个问题 确定跟踪对象 采集信息 分析信息 报告信息 1 测量量的确定 要采集的度量包括与技术有关的和与管理有关的在确定要采集的度量时可参照HP的经验 从工程实际出发 管理人员和工程人员总结自己工作中实际需要的度量 采用目标 提问 度量 G Q M 的框架 分析目标 提出要解决的问题 从问题中提出度量 HP的经验 尽早确定所要采取的度量采取目标 提问 度量 G1 G2 Q1 Q2 Q3 Q4 M1 M2 M3 M4 M5 例子 目标 减少工作量和缩短进度其中一个问题是 当要求更改代码时 何时作更改 何时不作更改 他们分析得出的度量是 M1 问题发生率M2 缺陷密度M3 代码稳定性M4 复杂性M5 要更改的模块数 起步核心测量 SEI建议DOD的软件组织采用四个起步核心测量 软件规模 工作量 进度 缺陷 监控什么 在项目中受监控的典型方面 进度 工作量 总成本 质量 范围 scope 风险 职员流动 项目的其它被标识的主要目标 技能水平改变 过程度量 过程度量量化过程或开发环境例子 生产率 质量 资源度量 缺陷插入率 缺陷及其消除率 产品度量 产品度量独立于其过程例子 规模 可靠性 质量 也是过程度量 代码的复杂性 功能性 过程方法 作工作的规程 检查工作的规程 返工 输出 产品测量过程测量 标准工具 输入 过程的测量与分析 为什么要采集过程性能数据 要管理过程就需要 能预测过程的未来性能减小过程结果的偏差人们不能控制那些未测量和理解的东西这是连续过程改进的基础 2 定义度量的原则 通过G Q M方法能确定出与经营目标密切相关的测量和度量 在定义这些度量时 必须考虑以下原则 可重复性 其它人能重复测量 得到同样的结果 利于交流 对记录的测量结果 其它人能精确地知道它包含什么 不包含什么 测量的单位是什么 数据 数据是控制的核心 管理改进必须基于测量结果为使数据分析有用 必须了解数据的含义及如何对它作有意义的分析开始时仅采集一小组有用的数据管理者需要保证注意力明显地集中在项目所有的关键方面 包括那些难于测量的 不能只关注那些易于测量和跟踪的方面 3 测量量的采集 任何等级都必须采集度量多数度量存在于开发工作中 必须人人动手采集过程度量等有瞬时的特点 如不及时采集 无法补救要预先确定需采集的最小集合 再不断补充 与谁有关 监控要求小组所有成员参加从每个小组成员的个人计划开始在高层次上 处理经过整理的 更为一般的问题 如何能采集到正确的数据 对事不对人采用工具 4 项目报告 项目受监控 控制的等级依赖于管理层次 项目经理要求每日更新 其它开发经理 例如技术管理者 可能满足于月更新采集的数据要及时 正确 详细 3 有关SPTO 基本的监控 监控活动是否按计划进行监控缺陷是否均已解决监控问题是否均已处理L2 基本的监控L3 建立监控的门槛值 监控风险 L4 定量监控 跟踪基线 SPTO针对项目计划进行跟踪项目计划中列出了跟踪要求 包括被跟踪的主要工作产品 跟踪频度 跟踪机制 跟踪内容 其跟踪内容除了规模 成本和工作量 进度外 还有风险 资源 包括关键计算机资源 技术活动和纠正措施计划中列出了被跟踪量的估计值或预测值 它们作为跟踪的基础跟踪时 将采集的实际值与计划中的估计值相比较 来确定进展 它们有时被称为跟踪基线 对软件工程技术活动的跟踪 活动9中提出对软件工程技术活动进行跟踪 这是等级2中唯一与工程技术活动有关的实践 要求软件工程组的成员定期向其直接领导报告技术状态 包括活动的进展和问题 将其交付的供后续工作用的工作产品的内容与计划做比较 报告任何工作产品中的问题 并建立文档 跟踪问题到问题结束 纠正措施 如果计划和实际进展间存在明显偏差 就要采取纠正措施 这首先要做评价和判断 评价 评价项目性能和项目相对计划的状态 决定偏差是否明显 是否需要采取行动 要分析产生偏差的原因 当然首先必须明确定义 明显 的含义 判断 采取哪种行动 措施项有两种可能 改变正在进行工作的方式 调整计划 跟踪方式 跟踪软件工程技术活动 必要时采取纠正措施 如定期报告机制 软件工程组进行定期的内部评审以便对照软件开发计划跟踪技术进度 计划 性能和问题按照文档化规程在所选择的项目里程碑处进行正式评审以评价软件项目的完成情况和结果 如同行评审 各种报告和表格 跟踪和监控方式填写数据采集表格 项目人员定期向其直接领导报告 其主要方式是填写数据采集表格 如周报 周状态报告 它们既包括相对计划的进展 管理方面 又包括技术进展和技术问题 技术方面 一般SPTO需设计和提供适用的对各类人员的跟踪表格 内部评审 内部评审 软件项目组内部定期进行的评审目的是跟踪技术进展 计划完成情况 当前状态和问题一般一线软件经理和软件作业领导参加评审 需要时 和软件经理和其他软件经理一起评审 正式评审 里程碑处的正式评审 目的是评价跟踪的结果 进行监控而不是跟踪评价时使用的材料必须经过有关软件经理的评审和批准 分析软件活动的约定 计划和状态 识别出重大问题 相应的措施和做出决策 并建立文档 分析软件项目风险 必要时 做出修订软件开发计划的决定 4 跟踪表格 项目报告 进度表 周工时表 在项目进度上 作状态标记 PERT CPM 周状态报告 进度指示器 全面监控 活动层监控的甘特图 周工时表 个人周状态报告 进度监控 甘特图 进度指示器 全面监控 到该日止已完成所计划的活动数进度指示器1 到该日止计划要完成的活动数到该日止已完成的在关键路径上所计划的活动数进度指示器2 到该日止计划的要完成的在关键路径上的活动数 项目报告 工作量 周工时表 进入实际时间 预计遗留工作量 周状态报告 工作量指示器 用于全面监控 工作量表活动层监控 工作量表 活动层监控 工作量指示器 用于全面监控 到该日为止总的实际人 小时工作量指示器1 总的所计划的完成活动的人 小时总的所预期的 遗留 实际的人天工作量指示器2 总的所计划的人天 项目报告 成本 成本报告类似于工作量成本分量 工作量 可能分别计算正常的和加班的 出差 硬件 软件 通讯 项目报告 质量 缺陷日志 测试日志 ItemWise质量记录 缺陷矩阵 质量指示器 ItemWise质量记录 缺陷泄漏矩阵 评审的重要性 泄漏缺陷 需求评审 设计评审 功能测试 静态分析 结构测试 25 15 10 需求缺陷 设计缺陷 编码缺陷 返工的费用呈指数式增长 质量指示器 全面监控 质量指示器1 对已完成的QC作业 总的实际缺陷数 对已完成的