odc是什么意思（odc场地）

　　ODC缺陷分析法
　　软件缺陷管理过程不仅包含软件缺陷记录和统计，更重要的是对缺陷数据进行细致、深入的分析。缺陷分析是缺陷管理中的一个重要环节，有效的缺陷分析不仅可以评价软件质量，同时可以帮助项目组很好地掌握和评估软件的研发过程，进而改进研发过程，未对缺陷进行分析就无法对研发流程进行改进。此外，还能为软件新版本的开发提供宝贵的经验，进而在项目开展之前，制定准确、有效的项目控制计划，为开发高质量的软件产品提供保障。
　　常用的缺陷分析方法有：根本原因缺陷分析法、四象限缺陷分析法、ODC 缺陷分析法、Rayleigh缺陷分析法和Gompertz 缺陷分析法。
　　本节我们来学习下ODC缺陷分析法。
　　ODC(Orthogonal Defect Classification，正交缺陷分类)是获取缺陷的一种分类方案，但它不仅仅是一个分类方案，还是一个软件过程的度量系统，它是建立在包含于缺陷流中的语义信息基础上的，可以帮助评估测试效率，对错误进行跟踪，通过方案的分析机制可以评估客户的满意度。
　　1990 年Ram Chillarege 博士等人提出ODC 概念，并于1997 年基本完成ODC 理论体系建设。1998 年以后，IBM 公司开始在其全球24 个研发机构推广该技术，并取得了很好的经济效益。
　　ODC 一共有8 个属性，如图9-17 所示。当测试工程师发现缺陷并进行提交时，可以为该缺陷分配＂活动(Activity)＂＂触发(Trigger)＂和＂影响(Impact)＂三个属性;开发工程师在修改缺陷时，可以为该缺陷分配＂阶段(Age)＂＂来源(Source)＂＂限定符(Qualifier)＂＂类型(Type)＂和＂目标(Target)＂五个属性。
　　活动(Activity)：是指当前缺陷被发现时的实际操作步骤(如代码审查、功能测试等)。
　　触发(Trigger)：描述暴露该缺陷时系统的环境或引发的条件。
　　影响(Impact)：该缺陷给用户带来哪些方面的影响。
　　阶段(Age)：缺陷是由新代码还是重写的代码引起的。
　　来源(Source)：缺陷出现在内部代码、重用库代码、移植代码还是外包代码。
　　限定符(Qualifier)：定义引起缺陷的原因。
　　类型(Type)：定义缺陷的类型，如算法、初始化等。
　　目标(Target)：将在哪里改正错误，如设计、代码等。
　　ODC 的生命周期包括三种可能的角色、三种可能的循环和六大实施步骤。
　　(1)ODC 实施中可能的三种角色
　　 团队成员：团队成员包括开发工程师、测试工程师、用户。
　　 ODC 负责人：ODC 负责人必须熟悉ODC 分类的执行，需要制定ODC 实施计划，指导团队成员进行ODC 分析。
　　 ODC 特别小组：ODC 特别小组由开发工程师、测试工程师的代表组成，主要负责制定行动计划、确认录入数据的正确性和进行ODC 分析。
　　(2)根据ODC 所需步骤的数量，有三种可能的循环
　　 大循环：除了预备步骤，该循环本身包含五个步骤。
　　 中等循环：包含四个步骤，包含ODC 生命周期的核心组成部分，尽管无法进行完整的ODC 分析，但仍然可以执行一些有用的评估。
　　 小循环：只包含两个步骤，只要找到一定数量的缺陷，随时可能发生确认的活动。
　　(3)ODC 包含以下六大步骤
　　1)预备阶段。获得主管的批准和支持来实施ODC 方法，获得开发团队和测试团队的支持，确定一个ODC 负责人，由负责人来提供培训和指导，分析项目当前状态，确定ODC 特别小组，由开发工程师和测试工程师代表组成。
　　2)计划。需要把项目分成多个组件，每个缺陷都将追踪到相关组件，以供将来分析用，组件的划分可以按照功能名称、物理分布或逻辑关系来确定。确定ODC 分析的时间点，ODC 分析可以在功能测试和用户验收测试之后进行，ODC 分析时间点的选择将直接影响后续质量改进的成效。对于迭代的开发流程，可以在每个迭代结束的时候进行ODC 分析。
　　3)数据录入。在数据录入之前，应该确保所有的开发工程师和测试工程师清楚地理解每一个缺陷的含义。
　　4)数据确认。在数据录入之后，需要进行确认工作来保证录入数据的正确性。
　　5)分析。收集好一定的数据之后，即可以通过各种统计图表来分析这些数据，分析工作可以在项目开发周期的任何时间点进行，通过统计图表分析出影响质量的原因。
　　6)行动。制定一个正式的行动计划来帮助我们持续地提高产品质量，行动计划可以是针对设计文档、源代码、开发流程、测试方法等进行改进的建议，行动计划定义必须清晰且可度量。
　　ODC 模型如图9-18 所示。
　　ODC 分析案例1：使用ODC 评估设计、代码的充分性。
　　首先从缺陷类型的角度来分析缺陷与设计相关的问题，按分配、校验、设计方法、接口、编辑和打包几个维度对缺陷类型进行分类，如图9-19 所示。
　　从图9-19 中可以看出设计方法的问题较多，说明系统设计的水平应该再提高。接下来，在该图基础上可以从限定符维度对设计方法引入的缺陷进行详细的分析，从不同的角度来分析每种缺陷类型的数量。我们设置三种限定符：错误的(Incorrect)、丢失的(Missing)以及外来的(Extraneous)，如图9-20 所示。错误的表示代码存在，编写不正确;丢失的表示代码本应该有的，但开发工程师遗漏了。
　　从图9-20 中可以看出，大多数缺陷是由代码错误引起的，说明我们的代码写得太糟糕，如果该案例丢失的缺陷很多，说明详细设计说明书做得不够好。ODC 分析案例2：使用ODC 分析缺陷对客户的影响。
　　从缺陷影响的角度对缺陷进行分析，ODC 从可安装性、安全性、性能、易维护性、易操作性、易移植性、文档、易用性、标准符合性、可靠性、易获得和需求几个方面来分析缺陷对客户的影响。ODC 分析图如图9-21 所示。
　　从图9-21 中可以看出，该产品问题主要集中在性能、易维护性和易用性方面，如果产品这样上市是很可怕的，必须采取相应的措施来完善这几个方面的问题。
　　ODC 分析案例3：ODC 评估缺陷修复效率。
　　在测试过程中有时会发现测试时间被延迟，通过ODC 按缺陷严重等级的属性可以分析每类缺陷修复的时间。通过描绘缺陷严重等级与修改缺陷的时间图，来分析修复缺陷所花费的时间，如图9-22 所示。
　　从图9-22 中可以看出，致命缺陷和严重缺陷都已经修复，修复所有致命缺陷的时间为17 天，修复所有严重缺陷的时间为20 天。