SQECh软件质量度量资料.ppt

结构度量方法 Henry给出的复杂性定义： Cp = ( 扇入× 扇出)2 其中： 扇入 – 调用外部模块的模块数 扇出 – 被外部模块调用的次数 缺陷密度——软件缺陷在规模上的分布 如：每KLOC或每个功能点（或类似功能点的度量——对象点、数据点、特征点等）的缺陷数 缺陷率——缺陷在时间上的分布 如：从应用软件的角度来说，90%以上的缺陷是在发布后两年内被发现出来 。 整体缺陷清除率 在软件开发过程中发现的被清除的所有缺陷数 /发现的总缺陷数 阶段性缺陷清除率 顾客满意度要素 顾客满意度要素的内容 技术解决方案 质量、可靠性、有效性、易用性、价格、安装、新技术 支持与维护 灵活性、易达性、产品知识 市场营销 解决方案、接触点、信息 管理 购买流程、请求手续、保证期限、注意事项 交付 准时、准确、交付后过程 企业形象 技术领导、财务稳定性、执行印象 软件组织的顾客满意度要素及其内容 顾客满意度要素 顾客满意度度量内容 软件产品 功能性、可靠性、易用性、效率性、可维护性、可移植性 开发文档 文档的构成、质量、外观、图表以及索引、用语 项目进度以及交期 交期的根据、进度迟延情况下的应对、进展报告 技术水平 项目组的技术水平、项目组的提案能力、项目组的问题解决能力 沟通能力 事件记录、格式确认、问题解答 运用维护 支持、问题发生时的应对速度、问题解决能力 软件项目的顾客满意度要素及其内容 5.1 软件需求过程的质量度量 5.2 软件过程生产率的度量 5.3 测试阶段的过程质量度量 5.4 维护阶段的过程质量度量 需求一致性度量 Q1 ＝ nui /nr nui是所有复审者都有相同解释的需求数目 nr是需求说明书中需求的个数，包含功能和非功能需求 需求完整性度量 Q2 ＝ nu /(ni × ns) nu是唯一功能需求的数目 ni是由需求规格定义或包含的输入的个数 ns是被表示的状态的个数。 需求确认程度度量 Q3＝nc /(nc＋nnv) nc是已经确认为正确的需求的个数 nnv是尚未被确认的需求的个数 需求稳定性度量 需求稳定性度量是通过需求稳定因子RSI 来表示： RSI = （所有确定的需求数 - 累计的需求变化请求数）/所有确定的需求数 所有确定的需求数 = 初始需求请求列表数 + 接受的需求变化请求数 软件生产率的三维关系 度量量 代码行 功能点 类 测试用例 度量单位 人时（man-hour） 人日（man-day） 人月（man-month） 人年（man-year） 测试用例的深度（TCD, Test Case Depth） - 每KLOC的测试用例数 - 每个功能点/对象点的测试用例数 测试用例的有效性 - 每100或1000个测试用例所发现的缺陷数 测试用例的质量（TCQ, Test Case Quality） - 测试用例发现的缺陷数量/总的缺陷数量 测试执行的效率和质量 - 每个人日所执行的测试用例数 - 每个人日所发现的缺陷数 - 每修改的KLOC所运行的测试用例数 缺陷报告的质量 - 报告的质量不高的缺陷数/报告的总缺陷数 质量不高的缺陷包含： 1）状态为“需要补充信息”的缺陷 2）状态为“不是缺陷”的缺陷 基于需求的测试覆盖 - 已执行的测试覆盖 ＝ Tx／Rft - 成功的测试覆盖 ＝ Ts／Rft Tx表示已执行的测试过程数或测试用例数 Ts是已执行的完全成功、没有缺陷的测试过程数或测试用例数 Rft是测试需求的总数 基于代码的测试覆盖 - 已执行的测试覆盖 ＝ Tc／Tnc Tc是用代码语句、条件分支、代码路径、数据状态判定点或数据元素名表示的已执行项目数 Tnc（Total number of items in the code）是代码中的项目总数 平均失效时间MTTF (mean time to failure) 基于时间缺陷 (或用户问题数) 的到达率 软件成熟度指标 (SMI) 质量度量的统计方法包含以下步骤： 1) 收集和分类软件缺陷信息； 2) 找出导致每个缺陷的原因(例如，不符合规格说明书、设计错误、代码错误、数据处理不对、对客户需求误解、违背标准、界面不友好等)； 3) 使用Pareto规则(80％缺陷主要是由20％的主要因素造成的，20％缺陷是由另外80％的次要因素造成的)，要将这20％的主要因素分离出来。 4) 一旦标出少数的主要因素，就比较容易纠正引起缺陷的问题。 错误的根本原因来源于下面几个方面： 说明不完整或说明错误(IES) 与客户交流不够所产生的误解(MCC) 故意与说明偏离(IDS) 违反编程标准(VPS) 数据表示有错(EDR) 模块接口不一致(IMI) 设计逻辑有错(ED