软件项目监控.pptVIP

* 截至到8月31日 BCWS=39,800 ACWP=35,000 BCWP=37,000 CV=37,000-35,000=2,000 SV=37,000-39,800=-2800 SPI=93% CPI=106% SPI小于1说明截至到8月31日没有完成计划的工作量，即进度落后 CPI大于1说明截至到8月31日费用节省了，完成工作量的价值大于实际花费的价值 * 盈余量监控 盈余量概念还没有被软件界全面接受，原因可能在于建了一半的房屋可以有反映人力和材料消耗的记录，而完成一半的软件项目却没有任何数据。这是对盈余量分析的误解。实际上盈余量分析是一项跟踪项目进度的方法。 * 项目评审 通过一定的方式对项目进行评价和审核 评审活动的类型 商务评审 技术评审 管理评审 质量评审 产品评审 评审时间 定期评审 阶段评审 事件评审 * 定期评审 准备评审要素 确定评审方式 依据采集数据统计项目性能 评审管理/质量/技术等问题 对评审作出结论 计划修改 到达定期 评审时间 * 阶段评审 准备评审要素 组织相关评审 评审本阶段关键任务完成情况 确认产品提交情况 阶段评语 对下阶段计划调整 到达阶段 评审时间 统计报告数据 * 事件评审 按评审过程组织评审 报告事件的情况 对事件处理方案的讨论 确定事件影响的范围 计划修改 事件报告被批准 对评审做出结论 * 监控的优先级 关键路径活动 没有自由浮动的活动 小自由浮动时间活动的监控 高风险的活动 使用关键资源的活动 * 使项目回到正规 几乎所有的项目都会遇到延误和意外事件。项目经理的一项任务就是识别这些事件发生的时间，在最小延迟时间和对项目团队有最小的影响的情况下，消除问题的影响。 * 缩短关键路径 要求项目组人员“Work harder”有一些效果，但是不能轻易使用。 分配额外的资源可以加快进度，但是并不总是奏效，例如分配给某一人员的小模块，再增加一个人员并不一定能够缩短时间。 将非关键路径上的资源调整到关键路径上 注意：缩短关键路径可能使其它路径成为关键路径。 * 重新考虑任务优先关系 网络计划考虑的是理想情况和普通工作情况，因而在无法缩短关键路径时，可以重新考虑任务优先关系。 另一种方法是将活动再进行划分，从而一部分可以与其它活动并行。 重新考虑任务优先关系可能带来风险或者质量上的影响。 * 变更控制（Change Control) 用户的需求可能变化，项目内部可能变化…… 变更需要仔细考虑，因为一个部分的变化可能会对另外部分的造成影响 问题：对程序描述的改变将引起软件的设计和代码的改变，还有什么其它产品可能需要修改？ 答案：测试数据，期待结果和用户手册等 * 变更管理员角色 Configuration Librarian 责任： 识别所有需要变更控制的内容 建立一个保存所有项目文档和代码的中央库 建立一套管理变更的正式过程 维护读取库中内容的记录和库中每一项的状态 * 变更控制过程 用户意识到需要对系统进行修改，考虑将修改请求提交给开发人员 用户端的管理者考虑是否将该修改请求提交给项目承担者 项目承担端的管理者将该任务指派给一个成员，该成员将判断该修改的成本以及修改的影响，并提交一个报告 该报告被提交给用户，用户将考虑是否能够承受额外的成本 * 变更控制过程 用户同意后，一个获多个开发者被授权从主产品上取出要修改的部分的拷贝 拷贝被修改。 新版本开发出来后，将通知用户，用户进行接受测试 当用户满意后，产品的配置项被新版本所代替。 * 项目修复 需要修复的项目 没有人对项目何时结束有一点点概念 产品满目疮痍。 开发组人员工作超时，每周多于60小时 管理层已经无法控制进度，而评估项目状态的准确性丧失殆尽 客户对开发组能否按承诺交付软件不再抱有信心 开发人员，市场人员，项目经理，客户之间关系紧张 开发组士气低落 …… * 修复方案 问题：如何挽救项目 缩减项目规模，以便在计划的时间与工作量内完成项目 把注意力放在短期的改善上，以提高过程的生产率 面对现实，放弃计划 有没有其它方法？ 重新获取控制权 * 修复计划 第一步 评估你的处境 应用W-理论分析 作好修复项目的思想准备 向开发组成员探问拯救项目的方法 变得现实一些 * 项目修复：人员 采取一切措施恢复开发组的士气 采取一个象征性的行动，如给他们特许的条件（允许他们上班晚些，提供更好的工作环境），也可以放一次假 确保为开发组创造了条件 如去掉了过多的进度压力，改善了恶劣的工作条件，剔除了管理上的不当做法 消除重大的人员问题 勇敢地面对问题，该调整的要调整 * 项目修复：人员 消除重大领导问题 更换子项目经理 为经理配备助手 增加新手一定要慎重 充分利用开发人员的时间 减轻他们其它的负担 为他们处理一些日常工作 允许开发组人员各