Ch08-缺陷预防与优化

Chapter8.缺陷预防与优化“奖励那些预防火灾的人”关键过程域分类等级管理类组织类工程类优化级(等级5)Optimizing技术更改管理(TCM)过程更改管理(PCM)缺陷预防(DP)定量管理级(等级4)Manged定量过程管理(QSM)软件质量管理(SQM)已定义级(等级3)Defined集成软件管理(ISM)组间协调(IC)组织过程焦点(OPF)组织过程定义(OPD)培训大纲(TP)软件产品工程(SPE)同行评审(PR)可重复级(等级2)Repeatable需求管理(RM)软件项目策划(SPP)软件项目跟踪和监督(SPTO)软件子合同管理(SSM)软件质量保证(SQA)软件配置管理(SCM)初始级(等级1)Initial无序的过程主题8.1软件缺陷预防的系统性8.1.1缺陷预防与救死扶伤8.1.2构造闭环8.1.3缺陷的分级预防8.1.4举一反三8.2常用的缺陷预防方法8.2.1缺陷预防过程(DPP)8.2.2缺陷趋势分析法8.2.3EDA分析8.2.4过程能力基线缺陷预防法8.3FRACAS与缺陷预防8.3.1FRACAS的基本过程8.3.2FRACAS的起源8.3.3建立FRACAS的目的8.3.4FRACAS的措施8.3.5FRACAS的应用方式8.4过程优化与技术革新8.4.1获得更改建议8.4.2先导性试验8.4.3组织范围内推广故障处理==亡羊补牢1)系统故障时，将问题记录下来，采取措施尽快进行故障恢复，将问题对用户的(危害)影响减小到最小.2)当系统被恢复后，分析故障原因，制定解决措施当软件系统问题的原因被分析定位出来后，需要进行彻底的解决。3)确定解决方案：修改软件代码；修改完一处后，还需要思考其他软件模块、系统中是否也有潜在相同的问题，如果存在，也需要进行彻底的修改解决.4)还需考虑在其他项目或后续项目中如何避免此类问题的再次发生，总结经验案例、知识提取固化、进行案例宣传。(共享经验和教训)软件缺陷预防的系统性与医疗对比的缺陷预防步骤构造闭环单个问题软件产品解决闭环1单个问题软件产品问题清零闭环2多个问题软件产品批量分析TOP改进闭环3构造闭环单个问题软件产品失效分析设计经验缺陷预防闭环4问题个人技能经验设计准则/测试经验闭环5缺陷的分级预防级别导致缺陷的原因解决措施个人级员工技能、经验不足。通过知识经验库，共享经验案例，向软件开发人员提供学习和共享的平台，提升个人经验技能。项目级项目活动执行不到位。通过提取的设计准则、测试经验等应用到新的软件开发项目中，制定成缺陷预防计划，标识各阶段需要进行的缺陷预防活动，并严格执行，以达成避免相同问题在新项目中再次发生的目的。组织级组织制度不合理。例如，软件开发流程中没有对软件单元测试的覆盖率提出要求，这会导致不同项目组所设计的单元测试用例的颗粒度不同。这类问题涉及组织层面，不是由某个开发人员或某个项目组就能解决，需要整个软件组织有专门的人员推动解决，那么就需要获取各个项目中的问题，并进行统计分析，标识出组织流程制度不完善的地方，驱动相应级别进行改进。举一反三总结经验案例：将典型问题总结成经验案例。在案例中，描述此问题发生的场景和现象、产生的原因、解决的步骤和预防的方法，并形成案例文档。在组织中进行宣传，组织开发人员进行学习，使大家都知道这个问题，如果在后续开发过程中遇到类似情况，就可以有意识地进行规避。共性问题的共享：经常会遇到一些较严重、较难发现但又具有共性的问题.例如，如项目组X开发的一个软件模块A中隐藏着一个严重的问题，但由于使用场景较生僻，很难通过普通测试方式发现。此模块已通过CCB(更改控制委员会)的评审，并提供给组织内的其他软件项目使用，但其他项目组当前还没有发现此问题。问题一旦发生，将会影响到软件功能的正常实现，带来较严重的后果。及时在通告问题缺陷，防止其他(人)项目组产生类似问题。常用的缺陷预防方法8.2.1缺陷预防过程(DPP)8.2.2缺陷趋势分析法8.2.3EDA分析8.2.4过程能力基线缺陷预防法常用的缺陷预防措施缺陷预防过程(DPP)根据以往项目经验和数据制定本项目的缺陷预防计划，根据计划进行相应缺陷预防活动，并在开发过程中针对发现的问题进行根因分析，制定改进措施并跟踪执行。缺陷趋势分析法“程序某部分存在更多错误的可能性，与该部分已发现的错误的数量成正比”。后进部门的问题总是最多的。EDA分析(1)缺陷标识：对测试环节发现的缺陷进行分类，标识需进行EDA分析的缺陷，包括致命、严重问题和数量较多的同类问题。(2)分析：对缺陷进行根因分析，分析缺陷的引入活动、引入原因、漏测原因。(3)措施制定：根据分析结果制定改进措施，措施包括：解决问题的纠正措施，预防此类问题再次发生；过程改进的措施，通过改进过程完善研发流程，避免缺陷再次逃逸；判断其他程序中是否还会存在类似问题，并进行专项改进。(4)措施执行及效果分析：执行改进措施，并通过度量，将新的逃逸缺陷与之前的逃逸缺陷进行比较等方式，判断EDA措施的效果。(5)结果固化：如果效果未达成，说明可能没有分析到位，则重新进行分析并制定措施进行改进。如果同类缺陷不再逃逸，预防的措施效果明显，并且此措施对其他项目具有通用性，可将此措施固化到组织的流程制度中，在后续的项目中使用。过程能力基线缺陷预防法建立缺陷发现的能力基线活动缺陷发现比例应发现缺陷初始值实际发现缺陷应发现缺陷调整值软件需求评审10%10510软件设计评审30%301830+5代码评审40%403440+17代码测试20%202220+23过程能力基线缺陷预防法建立模型，预测遗留的缺陷前提假设：企业的状态、人员技能、组织结构等使稳定的。FRACAS故障报告、分析及纠正措施系统(FailureReport，AnalysisandCorrectiveActionSystem)，亦称为“故障信息闭环管理系统”以问题为驱动，通过一套规范化的过程，使发生的产品问题能得到及时报告，并分析故障原因，制定和实施有效的纠正措施，以防止问题再次发生，从而实现产品可靠性增长和质量的提高。目的“建立FRACAS系统的目的是及时报告产品的故障，分析故障原因，制定和实施有效的纠正措施，以防止故障再次发生，改善其可靠性和维修性”。““FRACAS应由承制方(包括转承制方)尽早建立，并在订购(使用)方的协同下加以实现。该系统应保证对合同规定层次的产品在研制阶段和生产阶段所发生的故障及时报告、分析和纠正”措施建立比较完善的产品缺陷信息和知识经验数据库，利用该数据库，可以为产品的质量改进和后续产品的设计、测试提供数据基础和经验参考。能够实现项目间、产品间的信息共享、经验共享、避免类同的问题在不同的地方再次发生。可以提升员工技能，提高工作效率。通过固化问题解决过程中的技术经验教训，闭环到开发和测试，防止再次发生，支持组织能力提升，解决工程师经验欠缺问题。让员工更加关注过程改进。FRACAS会驱动员工们把注意力集中在那些容易出问题的领域上，通过改进这些领域的过程来预防问题的发生，提高产品质量。应用方式方式1：分析问题，提取知识经验当具体的缺陷或问题已经解决后，还需要分析问题的技术根因，也就是分析问题是如何在设计过程中产生的、又是如何被漏测的。对这个问题的技术原因要从多个领域进行分析，例如，开发、测试、可靠性领域。通过分析找到各领域开发过程中考虑不全面或遗漏的地方，标识出待改进的点或区域。根据分析结果，在流程或技术方面总结经验教训，主要包括：设计人员针对这个问题总结设计准则，测试人员总结测试经验，以及可靠性工程师总结故障模式。通过问题分析获得的经验知识，将作为FRACAS其他模式的输入和基础。方式2：缺陷清零当缺陷的原因被分析清楚后，还需要思考，这个缺陷在其他项目、其他领域是否也存在。如果其他版本也存在类似问题，则需要及时采取措施，组织对缺陷进行全面清理。避免各领域的缺陷被激活产生不良的影响和浪费的成本，避免问题爆发和蔓延。方式3：建立知识经验库建立组织的知识经验库，将分析问题得到的技术根因(rootcause)、设计准则、测试经验和故障模式作为组织的智力资产保存起来。建立知识的查询、索引、共享方式，便于各领域的人员在日常工作中进行查询和使用。方式4：批量分析，TOP改进 根据80/20原则，80%的问题是由20%的原因引起，也就是说，大部分问题可能是由少数几类的原因引起的。如果能找出这几类的原因，就能解决多数的问题。将经过根因分析的缺陷按照各种维度(如从功能模块、结果影响、问题发现活动等)进行统计分析，找出共性的、继续解决TOP(优先级最高的)问题以及各领域/工程活动的问题分布，结合质量分析方法和业务知识进行深入的原因分析，再根据分析的结果进行专项改进。分析的结果可作为项目级和组织级改进的输入。改进活动可能涉及专项技术研究、角色职责的定义、组织过程优化、组织规范制定等方面。方式5：举一反三，经验共享当分析解决完项目中一个典型的、有价值的问题时，除了要总结经验和考虑如何避免在本项目后续中再次发生，还需要思考其他产品/项目中是否也存在这样的问题，它们是不是仍在艰难的分析和解决过程中。在组织中建立问题通报的渠道机制和平台，及时通知受影响的项目和产品，避免同样的问题在其他项目中发生，或者将解决问题的经验给其他项目共享，使他们能够更容易地解决问题。方式6：质量回溯有时，发现问题是简单的技术问题，如在编写代码时将判断是否相等的“==”写成了赋值语句“=”；有时，也会发现问题非常复杂，并且解决起来需要修改组织的制度、流程、人员沟通方式、项目管理方式等，不是通过几个人或项目组内部就能解决的。这类问题需要通过质量回溯的方式来解决。质量回溯是一种专项的质量改进活动，通过识别问题根因，找到改进点的方法，用于解决组织层面的重大问题，如组织制度、流程、管理、人员方面的问题。质量回溯为事件触发的启动，其过程包括选择问题、根因分析、改进实施和经验固化4个环节。方式7：项目缺陷预防FRACAS系统的目标是预防相同的问题再次发生，也就是常说的缺陷预防。在新项目的开发过程中，充分利用知识经验，可以预防同类问题的再次发生。在项目开始时，挑选可以使用于本项目的设计准则、测试经验等，挑选的原则是新项目也涉及这些内容。然后将这些知识经验的使用计划到对应的开发活动中，并制定成项目的缺陷预防计划跟踪执行。由系统工程师将设计准则用于指导项目设计活动的开展，如在概要设计、详细设计、编码等活动中使用，作为设计的标准和检查单(Checklist)。由测试工程师将测试经验用于指导测试策略制定、测试设计等活动，补充测试场景，并据此设计成测试用例。由可靠性工程师将失效模式运用到可靠性设计活动中，如SFMEA分析、FIT测试用例设计等。过程优化与技术革新技术更改和过程更改都是对软件过程的优化，是一个“精兵简政”的过程。精兵：意味着对人力资源、技术、工具进行优化。简政：意味着对没必要的流程和组织机构进行职能转变、合并、简化。过程优化中的问题由于软件开发过程的复杂性，因此如果没有充分调查数据、经验的基础，就对其进行简单的优化，将会产生灭顶之灾，如“利润下滑、员工离职、缺乏凝聚力、产品质量下降、客户抱怨增多，等等”，甚至于造成企业的破产。因此，对过程的优化需要以定量管理所获得的数据为基础，针对不必要的活动、环节精简和优化。为了确保过程优化的效果，最好的办法是采取阶段的方法实施：1)获得和评估更改建议。2)在局部范围内进行先导性的实验，获得经验。3)在组织范围内进行推广，积累数据。4)总结经验。8.4过程优化与技术革新8.4.1获得更改建议8.4.2先导性试验8.4.3组织范围内推广过程更改的建议的来源

软件过程评估的结果和建议组织的软件过程改进目标顾客问题和满意度数据的分析质量目标和生产率目标的项目性能

数据的分析过程基准测定的结果过程/任务自动化的潜力成功的过程改进建议的例子软件过程更改建议评审这些建议评价建议软件过程更改建议安排团队进行先导性试验预期效益：生产率、质量、周期时间、顾客或最终用户满意度等建议的优先级：关注具有高优先级评审这些建议“过程更改”的先导性试验1）在先导性试验期间为了优化过程改进的实施工作，调整所建议的过程改进，并将其编写成文档；2)总结经验教训和遇到的问题；3)估计过程改进在组织中广泛应用的利益、风险和影响，并评估不确定性；决定是终止先导性试验继而广泛应用，还是重新策划并继续先导性试验。依据实际的调整经验与教训评估不确定性过程优化在组织范围内推广1)确定支持软件过程主要更改所需要的资源，并提供经费；2）将测量和跟踪软件过程性能变化的数据采集策略文档化，并经评审和同意。同时还要求：该策略得到负责实施受更改影响的软件过程的人员同意；合适时，配备支持工具自动地记录所期望的数据；3)更新培训课程以反映当前的软件过程，并在广泛实施过程更改之前提供培训4)在广泛实施过程更改之前提供必要的咨询支持，需要时继续支持5)将过程更改纳入“组织的标准软件过程”6)将过程更改纳入“项目定义的软件过程”技术革新建议的来源

定期搜索，市场上获得了解领先的相关技术工作和新技术发展比较和评审外界所用的技术比较和评审组织内所用的相应技术

标识新技术已得到成功运用的领域收集和评审使用这些技术的经验数据和文档新的研究成果和技术获得新技术评价这些技术的适用性技术革新建议的使用新技术建议向软件经理和技术人员通报：新技术的信息某些部门使用的信息正被引进到组织中状态信息评审这些建议技术更改管理组系统地分析组织的标准软件过程