第9讲 软件项目监控.PPT

第9讲 软件项目监控 内容 项目监控的内容 项目监控框架 项目监控方法与工具 变更控制 项目修复 项目监控的内容 监控项目的进展 比较实际进度与计划的差别 修改计划使项目能够返回预定“轨道” 项目监控框架：过程 项目监控框架：责任（1） 项目指导委员会（Project Steering Committee， Project Board）负责整个项目进度 报告项目情况的组织结构 项目监控框架：责任（2） 项目情况报告的内容 项目监控框架：进度评估 基础：定期信息收集或者发生的特定事件 这些信息必须是客观的和可度量的 但是并非每一次都能够得到符合要求的信息，因而通常需要项目成员进行主观判断 项目进度监控：检查点设置 检查点(Checkpoints)包括： 定期的（如一星期一次，一月一次） 与特定的事件绑定的，如生成一份报告或者交付部分产品 项目监控框架：监测频率 监测的频率依赖于项目的大小和风险情况 团队领导，可能需要每天都了解一下进度 项目经理需要每星期或每月了解情况 管理层次越高，频率越低，信息越抽象 许多公司利用星期一早晨的短会来激励员工实现短期目标 数据收集 尽管整个过程被分成了容易管理的活动，但是项目执行中仍然需要在活动中对任务完成的比例进行评估，这种评估通常是困难的。 思考：某一软件开发者完成了一个需要500行代码的软件的250行，请解释一下为什么不能认为他的工作已经完成了一半？ 答案 许多因素决定了不能用完成的代码行的比例来衡量进度： 对整个软件的代码行的估计可能不准确 写完的代码可能相对容易，或者相对容易 一个软件如果没有通过测试就不能算完成，因而即使代码全部写完了，如果没有测试也不能算完成。 对所需完成内容的深入的了解有助于判断进度，如将整个工作细分为子任务，如设计，编码，单元测试等。 部分完成报告 许多组织采用财务系统中的每周时刻表来记录每个职员在每项工作中花费的时间，但是该表无法告诉项目经理目前产出了什么，进度是否满足要求。 因而可以对每周时刻表进行扩展，以包含完成的工作内容 风险报告 询问小组成员完成计划的可能性 交通灯方法： 识别评价某项工作中的关键元素 将这些关键元素分解为组成元素 对于每一元素： 如果符合计划要求：绿灯 目前已经拖后，但是可以恢复，黄灯 已经拖后，恢复很困难，红灯 进度可视化 Gantt图 进度可视化 滑动图(slip chart) 进度可视化 球图：计划开始，计划结束作为两个球，每次计划改变后，日期添加到球中，如果时间是按计划的，球被填为绿色，否则被填为红色。 每次更新后，图不需重画。 进度可视化 前面的方法不能表示出项目生命周期中偏离计划的情况。 对计划偏离的趋势分析能够避免将来的项目偏离。 时间线图（timeline） 进度可视化 成本监控 监控的意义 成本本身是项目中的重要元素 成本监控也能展示已经花费了多少劳力 简单的监控方法：累积消耗图 累积消耗图 对普通的累积消耗图上加上项目时间信息 盈余量 盈余量（Earned Value):建立在对每个任务或工作包的消耗预测的基础上。 对每一项内容的原始预算成本被称为预算基线或计划工作的预算成本（budgeted cost of work scheduled, BCWS)。 未开始的任务被赋予值0，当它被完成后，将被赋值。在项目中的一点上，全部的值将被成为盈余量或完成工作的预算成本（budgeted cost of work performed, BCWP) 盈余量 当任务未完成时，需要分配一个盈余量给该任务，方法为： 0/100技术：任务被分配值0直到任务完成后，被分配预算值的100％ 50/50技术：任务一开始后，就赋予50%,直到项目结束后赋值100% 里程碑方法：对任务中的一系列里程碑赋予特定值。 建议用0/100方法，因为50/50方法由于活动开始后报告的值过高，容易给人一种错误的安全感，而里程碑方法最好将该任务细分为多个子任务。 预算基线 建立盈余量分析的第一步是为项目建立一个预算基线(baseline budget) 预算基线是建立在项目计划的基础上的，它是根据时间对盈余量值的预测。 盈余量可以用货币单位来衡量，也可以用人员工作量来衡量。 例子 盈余量监控 随着项目的进行，可以不断进行盈余量监控，判断项目的进度。 盈余量监控 每一项任务的真正成本消耗为（Actual Cost work performed, ACWP) 盈余量监控 性能比例： 成本性能指数：CPI＝BCWP（盈余量）/ACWP（真正的成本消耗） 调度性能指数：SPI=BCWP/BCWS(预算成本) 值越大，工作完成得越好 例子 你被指定负责一个软件项目，此项目由四个部分（A, B, C, D）组成，项目总预算为53000元，其中A