新过程改进方法与实践案例 978 7 302 23431 9 第三部分 实践案例 Ch12 软件外包企业的过程改进实施.ppt

主题 12.1 数 据 采 集 12.2 过程的稳定和改进 12.3 过程改进前后项目性能的定量对比 12.4 改进效果分析 12.5 改进效果的总结 数 据 采 集 12.1 数 据 采 集 12.1.1 项目级数据的收集 12.1.2 组织级的度量数据 12.1.3 数据采集策略与分析项 项目级数据的收集 对于项目级的度量，NLST要求遵循如下过程： 1) 在项目策划阶段。 制定“项目度量计划”。 根据“项目度量计划”，确定需要收集的“项目数据”。 2) 在项目执行过程中，收集“项目数据”时，以“周”为最小周期。 3) 在项目结项后，将“项目数据”放到组织的过程数据库，供组织级数据分析和改进之用。 “项目数据”的收集分为三种类型： 项目管理 问题管理 项目度量报表。 组织级的度量数据 对于组织级的度量数据，进行了以下约定： 1) 明确度量的框架、度量元的构造和作用。 2) 制定度量活动的流程制度，约束并指导度量活动的执行。 3) 明确度量活动的角色职责。 4) 形成组织度量库和过程能力基线，为组织提供有益的数据指导和改进依据。 数据采集策略与分析项 过程的稳定和改进 12.2.1 过程变异特性 12.2.2 控制图的规范表示 12.2.3 特殊变异的检测 12.2.4 稳定过程 过程变异特性 一般变异：是指每一个过程内在的变异。 它包括无数个在过程中总是出现并影响过程所有要素的微小来源。员工不必为这样的系统问题负责，这是管理层的责任。 如果管理层对系统中一般变异的程度感到不满，就应该采取措施减少或者消除这些变异。 特殊变异是由系统外部的原因引起的。 过程监控者(例如，项目经理)的责任是对特殊变异进行检测、消除和矫正。 管理层必须找出这些特殊变异源。发现之后，要制定处理对策。 如果特殊变异是不需要的，就不能让它们再次发生；如果特殊变异是适当的，则必须制定对策来促使它们再次发生。 控制图的规范表示 特殊变异的检测 分析特殊点原因 获得修改后的图 稳定过程 一个稳定的过程是指仅仅包括一般变异，或者说只包括由系统内部的限制而产生的变异的过程。稳定的过程的优点： 管理者知道过程的能力，能够预测绩效、成本以及质量水平。 能够获得最大的生产力，实现最小的成本。 管理者能够度量系统中快速而稳定变化的影响 如果管理者想改变规则，就可以获得数据支持自己的决策。 利用控制图改进过程 过程改进前后项目性能的定量对比 12.3.1 需求稳定性对比 12.3.2 各阶段缺陷注入率对比 12.3.3 缺陷密度对比 12.3.4 缺陷排除率分析 12.3.5 工作量偏差与工期偏差 12.3.6 正负质量成本对比 12.3.7 风险控制能力分析 12.3.8 估算偏差对比 12.3.9 生产率与文档评审效率 需求稳定性对比 需求稳定性定义为：未变更需求数占需求总数的比例，即，100%为完全稳定，在后续阶段没有需求变更。 各阶段缺陷注入率和排除率 缺陷密度对比 正负质量成本对比 风险控制能力和估算偏差 生产率与文档评审效率 CAMEL项目的评审，平均每小时10页 TDC接近每小时12页 KIRIN项目平均每小时11页。 改进效果分析 需求管理的情况 通过在过程中增加“需求理解”阶段，项目组成员，特别是设计人员可以对需求有一个理解或评审的活动，以便更好地理解需求并提出问题，这样，在项目前期就可以很好地与客户进行需求的沟通和交流，取到了较好的效果，大大降低了后期的需求返工。 项目监控情况 以前的项目缺乏详细的日程计划，而提供给客户的计划虽然详细，却不是项目实际监控的依据，导致项目的监控缺少数据支撑和量化指标。 改进后，要求项目组在策划阶段就要明确WBS结构； 制定详细的实际监控的日程 系统集成活动 将集成活动独立了出来，加强了对接口的检查，方便了缺陷的定位。包括： 定制开发项目 新开发项目 通过集成前的检查和集成后的测试，减少了集成缺陷的隐藏以至增大系统测试工作量的现象，无形中也提升了后期缺陷的解决效率。 验证和确认 代码检查报告表样例 代码检查内容示例 改进效果汇总 改进效果汇总 针对问题点进行改进前后的效果对比 针对问题点进行改进前后的效果对比 有效 自动化工具提升了代码检查的效率和质量，同时也为核心代码的重点走查提供了时间保证 代码检查流于形式，代码质量没有把关 缺少对编码规范和质量的把关 有效 规范了项目WBS，细化了任务跟踪模式，初步达到了定量跟踪和监控 项目报告不规范，项目任务的跟踪无法细化和准确 项目监控力度不够 有效 引入了专业的估算方法，拓宽了可估算领域，也加强了有效性，可为项目计划提供有力支撑 缺乏统一的估算方法，依赖于项目经验，对于全新的项目，无从估算 项目估算缺乏有效性