过程改进方法与实践案例ch18-FRACAS在CMMI 5级环境下的应用.pptVIP

主题 18.1 问 题 提 出 18.1.1 原有的缺陷预防方式 18.1.2 存在的问题分析 18.2 应用FRACAS的目标 18.3 FRACAS在WXX产品部的推行 18.3.1 WXX产品部的产品缺陷分析 18.3.2 FRACAS的推行过程 18.4 角色及职责 18.4.1 推行组 18.4.2 运作组 18.5 WXX产品部的改进实施 18.5.1 失效模式分析过程 18.5.2 经验共享过程 18.5.3 建立FRACAS知识经验库 18.5.4 商用问题清零 18.5.5 质量回溯 18.5.6 重点问题改进 18.6 针对新项目的缺陷预防 18.7 应用效果评估 背景 作为一家国内与国际知名的电信设备制造企业，也是国内最早通过CMMI 5级认证的企业之一。 这些年来，公司按照CMMI 5级的标准制定了严格的研发流程，包括研发管理、系统工程、软件开发、硬件开发、产品测试等流程，并在公司内推行、实施，公司内所有的项目都能按照这些流程进行项目开发。 其中，软件开发流程是按照CMMI 5级的标准制定的，自然也包括软件缺陷预防的流程。 企业缺陷预防过程主要是采用“基于开发过程的缺陷预防”的方式。 达到CMMI 5，只意味着具有不断优化的能力。这种能力体现在不断地采用新方法进行过程更改、技术革新以及新技术和方法进行缺陷预防。 原有的缺陷预防方式 基于软件开发过程的缺陷预防过程 存在的问题分析 各缺陷预防活动相互独立，各活动的分析结果难以相互输入和参考，改进是以单个问题为驱动，没有固定的步骤和过程，缺乏系统性 预防是以项目为单位，只是在项目过程中进行，项目一旦结束，缺陷预防活动就没有载体了，缺乏企业、组织级的预防改进系统。 在根因分析(RCA)、EAD分析后，根据分析结果制定预防措施，但有些措施已不能在本项目中使用。 不同项目由于其业务、环境的特殊性，缺陷原因和预防措施不具备通用性，在一个项目中行之有效的措施，换到其他项目就可能难以使用，共享性较差 由于缺陷预防措施主要来源于研发过程的问题，很少是来自于商用上的问题。没有真正关注研发过程遗漏的问题，商用后的问题没有作为研发改进的输入。 对分析得到的原因和措施的管理较差，缺乏信息系统支持，到下一个项目时可能就找不到了，难以继承使用。 应用FRACAS的目标 问题就是改进的机会，不应只是被动解决问题。 提出达到3个目标： 1) 通过应用FRACAS，提高软件产品质量 2) 将FRACAS建设成软件领域质量改进的核心和重要输入 3) 将FRACAS建设成为软件人员技能提升的重要途径 FRACAS在WXX产品部的推行 18.3.1 产品缺陷分析 18.3.2 FRACAS的推行过程 07~08年软件版本质量目标情况 质量差的根因分析结果 FRACAS的推行过程 组织结构 角色及职责(1/2) 维护工程师： 来自公司的维护部，负责识别商用后的问题中较严重、有改进价值的问题，并导入FRACAS系统中进行分析，是FRACAS系统运转的输入和驱动。 开发工程师： 来自公司的软件开发团队，或来源于引入问题的项目组团队。他们熟悉软件产品，有较强的分析和解决问题的能力。开发工程师负责配合维护工程师共同解决商用问题，并分析问题产生的根本原因。开发工程师还要参与到FRACAS的各种改进应用中，解决软件产品中潜在的问题，改进产品的质量。 系统工程师： 来自公司的系统设计部门，在软件项目中主要负责软件需求分析和架构设计工作，并参与制定组织的技术规范。系统工程师有较强的分析设计能力和经验。在FRACAS改进过程中，系统工程师参与对商用问题的分析，分析在设计过程中遗漏的地方，并提取抽象出设计准则和规范，供后续项目中使用。系统工程师还需要参与到各项改进活动中，通过自己的专业知识和技能，共同确保改进活动的成功。 角色及职责(2/2) 测试工程师：来自公司的测试部门， 负责在商用前对已开发的软件产品进行测试和验证，确保软件产品满足所定义的规格。在FRACAS改进过程中，测试工程师参与对商用问题的分析，找出测试时导致此问题遗漏的原因，并根据分析结果补充测试场景和测试用例，在后续项目中使用。测试工程师也会根据需要参与到各项改进活动中。 可靠性工程师： 来自公司的可靠性部门或系统设计部门，负责产品可靠性设计工作。在FRACAS改进过程中，可靠性工程师参与对商用问题的分析，提炼问题中可用于可靠性设计的内容，如故障模式。将提炼的故障模式加入组织的故障模式库中，为后续新项目的可靠性设计提供参考。可靠性工程师也需要参与到各项改进活动中，提供可靠性设计方面的技术支撑。 推行组 推行组组长：在一个组织中，领导能为整个改进提供资源，是各项改进活动成功的前提。所以