新过程改进方法与实践案例 978 7 302 23431 9 第三部分 实践案例 ch15 软件开发和集成企业过程改进战术实施.ppt

主题 15.1 数据收集与度量分析 15.1.1 需求管理的度量 15.1.2 项目规模度量 15.1.3 项目进度度量 15.1.4 工作量度量 15.1.5 项目风险度量 15.1.6 过程符合性度量 15.1.7 项目验证和确认过程度量 15.2 过程库(PDB)建立与运用 15.3 过程改进实施总结 15.3.1 实施效果 15.3.2 实施中的问题与解决 15.3.3 学到的经验 数据收集与度量分析 15.1.1 需求管理的度量 15.1.2 项目规模度量 15.1.3 项目进度度量 15.1.4 工作量度量 15.1.5 项目风险度量 15.1.6 过程符合性度量 15.1.7 项目验证和确认过程度量 数据采集与确认 HSHZ公司的度量数据采集与确认，由过程改进部(Process Improvement Group)统一管理。 HSHZ过程改进部是一个独立于公司业务部门、直接对公司高管团队负责的部门。 该部门进行度量数据的汇总和原始记录的检查工作。 同时，采集的数据由另外一条途径进行确认，具体为： 涉及项目工作量度量数据的汇总结果提交后，由公司财务部予以确认。 有关质量、过程性能和客户满意度的度量数据汇总结果提交后，由公司高层管理团队确认。 需求管理的度量 需求的稳定度很大程度上影响了项目的规模、工作量和进度。不稳定的需求将带来负面影响，例如，软件产品质量下降、项目成本升高、项目进度延迟等均与需求控制关系密切，因此跟踪分析需求的稳定性能够体现一个公司管理和控制软件需求的能力。 某项目的需求变化 假设需求基线化评审发生在第3次项目监控时，该图显示，需求评审之后，第4次的需求总数以及第4、5、6次需求变更数都有明显增长，在第7次后，需求趋于稳定。说明在需求基线化评审结束之后相当一段时间需求仍然不稳定。 产生问题的原因可能有以下几种： 需求调研不充分、误解、歧义、不完整、不正确等； 客户需求变化频繁。 解决建议： 在进行需求调研时充分挖掘客户的需求，进行需求确认； 对于频繁变更的需求，项目组可能要采取诸如重新分配资源及重新估算规模、工作量和进度等措施。 项目规模度量 规模变化率超限的可能原因和措施 项目进度度量 进度分析和调整 工作量度量 工作量度量分析 工作量的分析主要包含两个方面的内容： 按照活动和阶段，周期性地监控实际耗费的工作量，并与计划投入的工作量相比较，及时发现工作量偏差的异常。如果必要，重新估算并修改计划。 分析项目中不同活动和不同阶段的计划工作量分布和实际工作量分布。 项目风险度量 风险管理度量分析 项目从第1周到第7周中风险总数一直在增加，风险转化为问题的比例较大。 可能原因： 项目初期风险识别不充分。 突发事件带来了新的风险。 风险缓解措施未被有力执行。 风险缓解措施无效。 应对措施： 识别风险时，可以采用“头脑风暴”方法调动项目组成员充分识别项目风险。 制定有效的缓解措施，并督促风险负责人执行。 过程符合性度量 项目验证和确认过程度量 返工工作度量分析 1) 工作量分析 通过对评审、测试和发布后的缺陷数目及修复相关工作量的跟踪，达到以下效果： 保障缺陷识别、跟踪和解决的日常管理工作量投入； 通过对比评审和测试投入工作量与缺陷数目之间的管理关系，监控同行评审和测试的效果，发现同行评审和测试的改进机会； 把握评审和测试投入工作量之间最佳比例； 在项目执行过程中，通过对验证工作量、返工工作量的对比分析，发现软件过程不足之处，并制定改进措施。 缺陷分布度量分析 2) 缺陷分布分析 在项目进行过程中，项目经理周期性地检查当前的遗留缺陷状况，即能了解整个软件过程中缺陷的分布状况，也可以有效地了解各个阶段评审或测试的有效性。图15-6主要用于分析系统当前遗留缺陷的数量是否太多，主要有哪些类型的缺陷，致命、严重级别的缺陷主要分布在哪里等。如果缺陷总数、致命、严重的缺陷数量较多，要分析缺陷产生及遗留未处理的原因。 致命缺陷产生原因分析饼图 过程库(PDB)建立与运用 过程改进实施总结 实施中的问题与解决 1) 将组织级标准生产过程模型导入定量管理工具 如何将组织级标准过程适用于具体的项目管理过程，即，进行“集成项目管理”(CMM 第三级的关键过程域)是软件过程改进的难点。在过程改进实践中发现，将公司的标准生产过程导入定量管理工具中，可以非常便捷地实现项目过程基于组织标准过程的定义和剪裁。 2) 将目标度量与CMMI过程模型的有机整合 将有关目标驱动的度量与过程改进模型进行整合，将企业战略上关注的目标划分为具体度量元，并付诸实践，能够很好地解决公司高层管理者和企业持续发展中的问题(例如，预算、进度偏差、质量等问题)，才能得到全体员工，特别是以项目为驱动的中层经理们对过程