在此页:
目标用户:
CAST AI 管理员
CAST软件分析与测量前言
当前的文档展示了软件分析和测量信息的本质,这些信息基于应用的源代码和架构的原始事实生成。本文还介绍了生成这类信息的过程。
换句话说,如何将原始事实转化为对质量和数量的评估
该文件的结构如下:
- 质量评估:CAST AIP质量模型评分系统说明
- 数量评估:CAST AIP分级模型说明
文档以指向相关主题(主要是排名系统)的指针结束。
CAST AIP质量模型评分系统说明
AIP质量模型评分系统目标
- 交付软件质量评估和测量结果,以向C级管理人员提供其应用或软件产品的可见性
- 软件质量领域的管理可见性包括
- 识别任何可能导致延迟、意外成本、操作失败、使用质量差的情况或变化
- 比较能力以支持基于过去经验的预测
AIP质量模型评分系统详细
简介
以下部分描述和评论AIP评分系统的设计,从应用源代码、结构和架构的发现开始,到获得整个应用的高级战略质量指标:
- 应用事实
- 质量规则定义
- 质量规则违反定义
- 从质量规则违规识别到质量规则符合率
- 从质量规则符合率到质量规则等级/状态
- 从质量规则等级到技术标准等级
- 从技术标准等级到业务标准等级
- 从模块级到应用级
应用事实
分析服务包含关于应用的各种信息。所有这些信息都可以用于软件分析和测量信息生成。
分析服务包含:
- 不同类型的事实:名称、链接、属性、计数、层次结构等。
- 在不同的层次:文件、包、函数、方法等。
- 例如通常所说的“源代码DNA”
单元层事实
例如:
- 来自代码解析的事实:
- 偏离代码模式扫描的事实:
技术层事实
例如:
- 内部技术依赖性:
系统层事实
例如:
- 跨层和跨技术的依赖:
质量规则定义
- 设计说明
- 质量规则是在应用源代码、结构和架构中寻找的源代码或架构模式的声明,即任何应用事实。
- 质量规则是有帮助的操作质量指标
- 建立中级战术质量指标(参考技术标准定义部分)
- 根据准确的发现来定义纠正措施(与统计模型的结论不同,统计模型只能根据一些测量和统计数据得出,被评估的应用处于某种状态)。
- 设计评论
- 质量规则类似于目标问题度量模型中的度量
从质量规则定义到质量规则违规识别
- 设计说明
- 质量规则违反是应用中的一个对象,该对象具有由给定快照(即在应用的特定版本或修订中)
- 设计评论
- 这个定义支持任何类型的质量规则的合规性比率(cf. next部分)的定义
- 这个定义支持不同的模式搜索方法:
- 识别所有出现
- 识别第一次出现的情况,当它太消耗资源而无法搜索所有的图形时(例如:一些图形处理算法不计算完整的图形,而是在跳转中找到所寻找的模式,并在找到一个模式时立即停止)
从质量规则违规识别到质量规则符合率
- 设计说明
- 质量规则合规性比率是违反质量规则的数量除以违反质量规则的机会数量的比率
- 设计评论
- 需要对应用规模的差异进行合理化,……为了避免显而易见的反对意见:“因为应用更大,违规行为更多”
- 需要根据机会的数量进行合理化,以便更加切合实际,也就是说评估适用/可能造成风险的情况的质量,而不是评估其规模
- 特别要避免产生一种现象:关于特定质量规则的运行良好,而实际上它并不适用于评估应用——完全不适用,或者大部分都不适用。
例如:
- 合规率计算:
从质量规则符合率到质量规则等级/状态
- 设计说明
- 质量规则等级是一个介于1.00和4.00之间的十进制值,计算方法是在质量规则合规性比率和获得特定等级值所需的目标合规性比率之间进行逐段线性插值。
质量规则状态是以下四个层次之一:非常高/高/中等/低风险,基于质量规则等级的下限值,提供解释。
从 到 状态 1.00 1.99 Very High Risk 2.00 2.99 High Risk 3.00 3.99 Moderate Risk 4.00 4.00 Low Risk
- 设计评论
- 质量规则状态要求快速、高效的掌握评估结果,同时支持彩色代码以更快的识别风险情况。
- 需要十进制的质量规则来支持随时间和跨环境更精确的比较(避免状态的突然变化,而不需要在这两者之间进行任何可见的演化)。
- 4级状态模型具有以下优点。
- 避免中性(相对于3或5级状态模型) 。
- 比2级状态模型更微妙。
- 质量规则等级范围是为了避免没有边界的指标,即使这些指标更具有代表性,也只会损害对评估和比较的理解(“总是存在更糟糕的情况,所以这种情况真的是问题吗?”)。
- 从1到4的质量规则等级映射4级状态既简单又符合逻辑,并且避免使用0作为范围间隔,因为如果处理不当可能会导致计算问题(“0除无效”)。
- 逐段线性插值是一个简单的模型但足够灵活,可以对指数型行为进行建模。
例如:
86.46%的合规率转变为1.91级:
技术标准的定义
- 设计说明
- 技术标准是中级战略质量指标
- 技术标准是一个到多个质量规则的聚合
- 一项技术标准将有助于
- 总结一定数量的质量规则,以帮助评估特定质量子特征的质量水平
- 构建高级战略质量指标(参考业务标准定义部分)
- 设计评论
- 中级指标必须:
- 作为管理战略指标和运行指标之间的离合,可以无缝的发展
- 作为管理战略指标和操作指标之间的关键,这些指标可以用于评估质量子特征,独立于技术领域的重要性(因此少量的规则不能防止给定的技术标准影响总分)
- 作为抽象级别来比较不同技术和语言(需要不同操作指标)的类似主题
- 技术标准类似于目标问题度量模型中的问题
- 中级指标必须:
来自质量规则等级到技术标准评分
- 设计说明
- 对于每个模块,即为每个评估的应用子组件提供,
- 技术标准等级为加权平均,具有关键质量规则的封顶机制——具有关键质量规则的封顶机制——所有的质量规则等级
- 因此它是一个介于1.00和4.00之间的小数值
- 它还支持将操作转换为技术标准状态
- 设计评论
- 聚合是基于一个平均公式来解释好和差的实践
- 聚合是基于加权平均来考虑好和差的实践的相对重要性
- 聚合的特点是有一种限制机制来解释差的实践,没有“数量”的好实践可以补偿或抵消这些差实践
- 这种高度非线性的行为需要与人类的感知保持一致:一些实践是如此严重,以至于在技术标准级别上无法忽视
- 例如: 常青藤工程大学数学、物理等科目的考试成绩都很好,但垃圾却很少
- 这种高度非线性的行为需要与人类的感知保持一致:一些实践是如此严重,以至于在技术标准级别上无法忽视
- 决定将权重分配到技术标准中,并将贡献权重值标记为关键(以激活封顶机制)的方法如下:
- 选择任意两个质量规则,它们将有助于给定的技术标准
- 假设质量规则#1的分数是2.00,质量规则#2的分数是3.00
- 根据这两条质量规则检测的质量问题,如果期望技术标准等级为
- 2.50,分配相同的权重
- 接近2.00时,给质量规则#1分配更高的权重
- 接近3.00时,给质量规则#2分配更高的权重
- 基于这两个质量规则检测到的质量问题,如果期望技术标准等级等于2.00,不管质量规则#2的等级和同一技术标准中的任何其它质量规则如何,都要将质量规则#1标记为Critical
示例:
- 将质量规则等级聚合为效率等级。循环中昂贵的调用技术标准等级:
业务标准定义
- 设计说明
- 业务标准是顶级的战略质量指标
- 业务标准是一个到多个技术标准的聚合
- 业务标准将帮助总结一定数量的技术标准,这些技术标准有助于评估特定质量特征的质量水平
- 设计评论
- 需要高水平的指标
- 用一个值或状态快速评估整个质量特征
- 作为抽象级别来比较不同技术和语言的质量特征(需要不同的战略和操作指标)
- 业务标准类似于目标问题度量模型中的目标
- 需要高水平的指标
来自技术标准等级到业务标准等级
- 设计说明
- 对于每个模块,即对于需要提供评估的每个应用子组件
- 业务标准等级是所有贡献技术标准等级的加权平均值,并为关键技术标准设置了上限机制
- 因此它是一个介于1.00和4.00之间的小数值
- 它还支持将操作转换为业务标准状态
- 设计评论
- 聚合是基于一个平均公式来解释好和差的实践
- 聚合是基于加权平均来考虑好和差的实践的相对重要性
- 聚合的特点是有一种限制机制,可以解释任何“数量”的良好实践都无法弥补的不良实践
- 这种高度非线性的行为需要与人类的感知保持一致:一些实践是如此严重,以至于在业务标准级别上无法忽视(参看从质量规则级别到技术标准级别部分)。
示例:
- 将技术标准等级(部分灰色)聚合为性能业务标准等级:
从模块级到应用级
- 设计说明
- 应用等级是其模块等级简单或加权平均数
- 设计评论
- 模块层有助于作为抽象层来比较它们所提供的服务的特性,而不是通过或多或少的代码、相同或不同的技术和语言来比较它们的实现
- 功能数据加权有助于提供更准确的风险评估,因为它考虑了环境。
- 例如: 如果应用的功能基础恰好很小——在计算代码行或文件行数时——那么总体结果将隐藏整个应用所面临的真正风险。
示例:
- 简单的模块平均分为应用级:
- 使用模块的业务价值将模块等级加权平均为应用等级:
AIP质量模型评分系统高级指标
质量分布
- 设计说明
- 质量分布是一种方法的声明,该方法将一组对象按照其某一属性的数值分布到4个类别中,以检查分布是否均衡,以及每个类别中对象的预期分割共享。
- 质量分布是作为质量模型中的质量规则的操作质量指标,即帮助
- 建立中级战略质量指标
- 根据准确的发现来定义纠正措施(与只能根据某些措施和某些统计数据得出评估的应用处于某种状态的统计模型相反)。
- 设计评论
- 质量分布是质量规则的更小版本:与其将测试对象分布到两类(兼容和不兼容)中,在这两类对象上应用合规性到等级的阈值,质量分布将允许在四个类别中分布,每个类别都有自己的一组分割共享到等级的阈值
- 质量分布也允许约束双方的一系列数值,这证明有用,当测量值范围结束时要避免(例如:避免过高(WMC)类的复杂性,还可以避免过低阶级的复杂性,因为它将是一个标志原子化业务逻辑)。
质量测量
- 设计说明
- 质量度量是基于应用中一个模块中所有对象计算的一个数值。
- 质量度量是作为质量模型中的质量规则的操作质量指标,即帮助建立中级战略质量指标
- 但是由于质量度量值关系到整个模块,因此不可能识别要干预的单个对象。一般来说,存在一个同伴质量规则带来一个不同的角度看问题(例如:避免过多的复制粘贴代码质量度量是由避免过多的复制粘贴工件质量规则来补充的:前者查看在整个模块中复制粘贴的代码行数,而后者查看从其它对象复制粘贴的对象的数量;两者都检测到类似但略有不同的情况)。
- 设计评论
- 质量度量是质量规则的模块级版本:不是将测试对象分发到两类(兼容和不兼容)中,在这两类对象上应用合规性到等级的阈值,质量度量将计算单个值来总结所有相关的对象,并使用它自己的一组值到等级的阈值
丰富技术标准定义
设计说明
- 技术标准是一个到多个质量规则、质量分布和质量度量的集合
从质量规则、分布、计量等级到技术标准等级
设计说明
- 对于每个模块,即为每个提供评估的应用子组件,
- 技术标准等级是所有贡献的质量规则、分布和度量等级的加权平均值,并为关键贡献设置了上限机制
AIP质量模型评分系统高级行为
从模块结果到技术等级
- 设计说明
- 技术等级是有关技术模块子集等级的简单或加权平均数
- 设计评论
- 模块由源代码分析作业的结果组成,即“子集”(注意子集没有被评估,因为它们只是模块的构建块)
- 每个作业一个模块
- 一组作业的一个模块
- 用于单个作业一部分的一个模块
- 一个模块的部分多个任务…
- 模块可以包含一个或多个“技术”的对象。
- 技术聚合考虑到与相关技术相关的模块子集
- 模块由源代码分析作业的结果组成,即“子集”(注意子集没有被评估,因为它们只是模块的构建块)
组织树
设计说明
- 模块可以分配给开发人员,作为负责它的人员,即使源代码开发涉及其它人员
- 一个模块一次只能分配给一个开发人员
- 团队是一组开发人员
- 组织是一组团队
- 此组织可用于筛选直接或不直接分配给所考虑组织实体模块的结果
- 模块可以分配给开发人员,作为负责它的人员,即使源代码开发涉及其它人员
- 设计评论
- 整个组织树可选
- 所有级别都是强制性的
使用AIP质量模型评分系统
默认业务标准列表
AIP缺省评估模型定义了以下业务标准:
- 面向业务的业务标准,即健康因素
- 健壮性
- 测量风险水平以及由于修改而导致应用失败和应用缺陷的可能性。测量测试应用所需的工作量。
- CAST健壮性附属于ISO 25010的可靠性特征。
- 性能
- 测量潜在性能瓶颈的可能性,以及与编码实践相关的潜在未来可扩展性问题。
- CAST性能附属符合ISO 25010性能和效率特点。
- 安全性
- 测量与编码实践和应用源代码相关潜在安全漏洞的可能性。
- CAST安全附属机构转换为ISO 25010安全特性。
- 可变更性
- 测量为了实现新特性、纠正错误或更改应用环境而修改应用的容易程度。
- 将可变更性附属机构转换为ISO 25010可维护性特征,重点放在可变更性子特征上。
- 可转移性
- 测量应用跨团队或团队成员(包括内部开发团队和外包开发团队)移动的容易程度。
- CAST可转移性附属机构转换为SO 25010维护性特征,重点放在可转移性子特征上。
- 总质量指数
- 基于CAST提供的数百个度量标准来测量应用的一般可维护性级别。
- CAST总质量指标概括了上述特征和子特征。
- SEI 可维护性
- SEI可维护性评估应用的可维护性级别基于SEI可维护性3-和4-指标索引
- 与其它业务标准不同,此标准提供了应用可维护性的统计度量,将SEI可维护性3-和4-指标索引的结果与500多个项目的结果进行比较
- 健壮性
- 面向开发的业务标准,即规则遵从性度量
- 架构设计
- CAST架构设计测量总结了所有与架构相关的质量规则、分布和测量的遵从性级别
- 编程实践
- CAST编程实践度量总结了所有与编码相关的质量规则、分布和测量的遵从性级别
- 文档
- CAST文档度量总结了所有文档相关的质量规则、分布和测量的遵从性级别
- 架构设计
默认技术标准列表
AIP缺省评估模型定义了以下技术标准:
- 架构——架构模型自动检查应用与用户定义的架构模型的兼容性。(可以使用架构师定义架构模型。一旦分配给应用,架构模型就会变成一个CAST AIP质量规则,并自动计算每个快照。应用可以分配多个模型,这样架构师就可以检查应用架构的不同方面,包括技术和功能方面。
- 架构——多层和数据访问测量遵守多层和多层最佳实践以及数据访问和数据完整性最佳实践。
- 架构——OS和平台独立性测量操作系统级别的资源使用实践。
- 架构——对象级别的依赖关系测量对象级别的耦合实践。
- 架构——重新使用测量遵守代码重用实践。
- 复杂性——算法和控制结构的复杂性衡量算法复杂性控制的复杂性实践方面。
- 复杂性——动态实例化测量遵守与动态实例化相关的实践。
- 复杂性——空代码测量遵守与空代码相关的实践。
- 复杂性——OO继承和多态性测量遵守面向对象复杂性控制的复杂性实践。
- 复杂性——SQL查询测量遵守SQL查询的演进编码实践的方面。
- 复杂性——技术复杂性测量遵守与总体技术复杂性相关的复杂性实践。
- 死代码(静态)测量遵守代码覆盖实践。
- 文档——自动化文档测量遵守与自动化文档相关的注释实践。
- 文档——不良的注释测量遵守注释实践(注释中的代码、语言……)。
- 文档——命名约定的一致性测量遵守命名实践。
- 文档——风格一致性测量遵守编码风格实践。
- 文件——评论的数量测量遵守关于评论数量的评论实践。
- 效率——昂贵的循环调用测量遵守针对庞大且耗时昂贵的循环的性能优化最佳实践。
- 效率——内存、网络和磁盘空间管理测量遵守内存和磁盘空间优化实践的方面。
- 效率——SQL和数据处理性能测量遵守SQL和数据处理性能优化实践的方面。
- 编程实践——错误和异常处理测量遵守对错误处理实践。
- 编程实践——文件组织一致性测量遵守对文件组织实践。
- 编程实践——模块化和OO封装一致性测量遵守面向对象封装实践。
- 编程实践——OO继承和多态性测量遵守面向对象继承实践的尊重和多态性的正确使用。
- 编程实践——结构化测量遵守对结构化实践。
- 编程实践——意外行为测量遵守结构化实践。
- 安全编码——API滥用测量对编程接口或有缺陷的、受危害的API的错误调用导致的API滥用安全性破坏(API实现调用者和被调用者之间的契约。最常见的API滥用形式是由于调用方没有遵守本合同的终止。)
- 安全编码—封装测量在违反信息隐藏原则和恶意用户能够访问应该保持私有的数据时出现的安全漏洞的级别。
- 安全编码——输入验证测量由于信任用户输入和缺乏对用户输入的严格检查/清理而导致的漏洞级别。
- 安全编码——时间和状态测量由于多线程误用和编码实践忽略了软件组件在并发线程和进程中共享和执行这一事实而导致的漏洞级别。
- 容量—组件的数量测量遵守有关包含或包含的对象的数量的分级实践。
- 容量—LOC的数量测量遵守有关代码行数量的调整实践的方面。
注意
- 在特定的SEI可维护性指标3和4质量度量的基础上,有一个特定的可维护性指标(SEI)技术标准,用于构建SEI可维护性业务标准。
- 技术标准的复杂性——功能可发展性(测量软件的能力结构以支持更改和添加新的功能规则没有威胁的可测试性和稳定性)是默认了“分离”(这将意味着和任何子质量标准规则将被忽略)。如果需要,可以重新连接。
默认质量规则列表
由于质量规则的绝对数量,请参见CAST度量和质量规则文档。
默认质量分布列表
AIP默认评估模型定义了以下质量分布:
- 4GL复杂性分布确保了4GL用户界面/表单复杂性级别的均衡分布。表单的复杂程度取决于它们的存在:
- 重表单:重表单是包含多个X(事件数+控件数)的容器(X依赖于技术)。
- 长表单:长表单是包含更多X行代码的容器(X依赖于技术)。
- 高数据层使用表单:高数据层使用表单是一种到数据库对象的链接超过X个的表单(X依赖于技术)。
- 高输出端表单:高输出端表单是指从表单到表单本身之外的对象的链接超过X个(X依赖于技术)。
- 类复杂度分布(WMC)确保了来自面向对象语言的类的每个类度量值的加权方法的平衡分布。
- 类输入端分布确保了来自面向对象语言的类的类输入端度量值的平衡分布。
- 类输出端分布确保了来自面向对象语言的类的类输出端度量值的平衡分布。
- 耦合分布确保了源代码工件的输入端度量值的平衡分布。
- 环路复杂性分布确保了源代码工件的McCabe环路复杂性度量值的平衡分布。
- OO复杂性分布确保了面向对象语言类的复杂性级别的平衡分布。类的复杂程度取决于它们的存在:
- 高环路复杂性类(WMC)
- 继承类的深度(DIT)
- 低内聚类(LCOM)
- 高长度或权重类:具有X行以上代码或X个字段和方法的类
- 调用分布的重用确保了源代码工件的输入端度量值的平衡分布,因为过低的值表明组件的重用很差。
- SQL复杂性分布确保了SQL工件(即包含静态或动态SQL代码的工件)复杂性级别的平衡分布。SQL工件的复杂性取决于它们的存在:
对超过4个表进行查询的工件
带有子查询的工件
工件与组BY
带有复杂SELECT子句的工件
带有UPDATE语句的工件
原始SQL复杂性大于30的工件
- 规模分布确保了源代码工件的代码行数的平衡分布
注意
- 在CAST门户的版本比较页面中使用特定的成本复杂性分布来评估创建、更新和删除工件所需的工作
默认质量测量列表
AIP缺省评估模型定义了以下质量测量:
- 删除代码行/代码行比率(LOC的%)确保评论行中没有太多的删除代码行
- 复杂性卷(LoC的%)确保复杂代码的容量保持足够低
- 复制粘贴的代码(LOC的%)确保复制代码的数量保持在足够低的水平
- SEI可维护性指标3
- SEI可维护性指标4
关键和非关键质量规则的默认遵从性等级阈值
非关键质量规则
AIP默认评估模型对非关键质量规则使用以下阈值:
- 低风险:合规性99%以上
- 中度风险:95%至99%之间的依从性
- 高风险:在90 - 95%之间
- 非常高的风险:低于90%的合规性(注:低于50%的合规性将导致“1”级平台,其中合规性评估不再需要进行比较)

关键质量规则
AIP默认评估模型对关键质量规则使用以下阈值:
- 低风险:合规性99.99%以上
- 中度风险:在99.5到99.99%之间
- 高风险:依从性在99 - 99.5%之间
- 非常高的风险:少于99%的合规性(注:少于98%的合规性导致“1”级平台,在这里合规性评估不再需要进行比较)

CAST AIP模型规模说明
CAST规模模型目标
- 交付软件数量测量结果,以向C级管理人员提供其应用或软件产品的可见性
- 在软件数量范围内的管理可见性包括
- 技术库存
- 与产品相关的测量
- 比较能力,以支持基于过去经验的预测
CAST模型规模详解
简介
下面几节描述和评论AIP分级模型中不同类型的指标:
- 技术规模
- 功能权重
- 技术债务
- 运行时统计数据
技术规模
设计说明
- 技术规模测量是使用应用事实声明要计数的对象类型(例如:方法的数量)或要总结的数值属性(例如:代码行数)。
- 技术规模测量是库存的基础。
功能权重
设计说明
- 功能权重测量是对应用交付给终端用户功能数量的估计。
- 功能权重将抽象的应用事实测量到这样的估计中。
技术债务
设计说明
- 技术债务测量是对修复预先设置的高度违约、中度违约和低度违约百分比成本的估计,这些百分比被认为是构建技术债务以及派生信息。
- 技术债务衡量的是要解决的应用问题的规模。
运行时统计数据
设计说明
- 运行时统计量是与应用的面向用户事务执行相关联的信息占位符。
- 运行时统计数据
- 用于在CAST工程仪表盘和应用分析仪表盘中列出风险最高的事务时提供更多环境
- 可以用来估计应用功能活动的规模
正在使用的CAST模型规模
默认技术规模测量
AIP默认评估模型定义了以下技术规模测量:
- ABAP事务的数量
- ABAP用户出口的数量
- 工件的数量
- 类的数量
- 代码行的数量
- 评论行的数量
- 删除的代码行数
- 复本的数量
- Datablocks的数量
- Datawindows的数量
- 事件的数量
- 文件的数量
- 表的数量
- 功能池的数量
- 功能的数量
- 功能和过程的数量
- 包括的数量
- 接口的数量
- 宏的数量
- 方法的数量
- 模块的数量
- Namespaces的数量
- 包的数量
- 段落的数量
- 处理屏幕的数量
- 程序的数量
- SQL工件的数量
- 节的数量
- 表的数量
- 模板类实例的数量
- 模板类的数量
- 模板功能实例的数量
- 模板功能的数量
- 模板接口实例的数量
- 模板接口的数量
- 模板方法实例的数量
- 模板方法的数量
- 触发器的数量
- 单元的数量
- 用户对象的数量
- 视图的数量
- WEB页的数量
默认功能权重度量
AIP默认评估模型定义了以下功能权重测量:
- Backfired功能点
- 决策点的数量
- 符合OMG的自动化功能点
未经调整的数据功能
未经调整的事务功能
- 增强功能点
添加的功能点
新增数据功能点
添加事务功能点
删除功能点
修改数据功能点
修改的事务功能点
修改的功能点
删除数据功能点
删除事务功能点
违约技术债务测量
AIP违约评估模型定义了以下与技术债务相关的措施
- 技术债务
- 技术债务密度
- 增加违反的技术债务
- 解除违反的技术债务
默认运行时统计量
AIP默认评估模型定义了以下运行时统计信息:
- CPU 时间
- 数据库时间
主要用于填充CAST工程仪表盘的风险指示器——事务级页面,以支持使用事务风险索引交叉引用这些运行时统计信息。
相关CAST排名系统
简介
除了测量系统,CAST AIP还提出了补充的排名系统来指导改进计划。
CAST等级系统不会影响CAST测量系统的结果。
它旨在利用来自CAST测量系统的信息来帮助组织定义改进机会。
CAST排名系统依赖于
- 质量规则和技术标准的权重和关键帮助选项
- 传播风险指数
- 交易风险指数
质量规则和技术标准的权重和关键帮助选项
这种排名功能使得项目管理者、架构师……根据定义的聚合权重和关键权重贡献定义改进操作
- CASTAIPMeasurementSystemexplained-FromQualityRulegradestoTechnicalCriteriongrade
- CASTAIPMeasurementSystemexplained-FromTechnicalCriteriongradestoBusinessCriteriongrade
传播风险指数
这种排名功能使得项目管理者、架构师……根据以下定义的聚集权重采取改善措施:
- CASTAIPMeasurementSystemexplained-FromQualityRulegradestoTechnicalCriteriongrade
- CASTAIPMeasurementSystemexplained-FromTechnicalCriteriongradestoBusinessCriteriongrade
以及执行带有违规对象的调用图。
简而言之:
- 通过违规索引的定义,将聚合权值进行复合,以获得问题在任何给定对象中的集中程度
- 调用图表用于通过风险传播因子的定义,了解任何给定对象对应用其余部分的影响程度
- 将上述两个指标结合起来定义传播的风险指数,以识别最具影响的问题。
违规指数(VI)
聚合权值用于计算关于给定健康因子对象的违规索引。
违规指标综合了目标违规的所有质量规则权重,再乘以技术标准的权重,但将质量规则和技术标准限制在对所考虑的健康因素有帮助的质量规则和技术标准。
风险传播因子(RPF)
执行调用图用于计算关于给定健康因子对象的风险传播因子。
- 对于可转移性, RPF = 0表示可转移性相关问题不影响调用对象
- 对于可变更性, RPF = # of direct callers,因为与可变更性相关的问题只会直接影响使用所考虑的对象
- 对于健壮性、性能和安全性,不同调用路径的RPF = # of distinct call paths,因为健壮性、性能和安全性相关的问题直接或间接地影响使用所考虑对象的所有对象
注意没有为其它业务标准定义RPF值。
产生的传播风险指数(PRI)
PRI = (1 + RPF ) x VI
请注意有一个PRI值仅为可转移性、可变更性、健壮性、性能和安全性而定义。
交易风险指数 (TRI)
这个排名功能使得项目经理,架构师,…根据集合权重定义改进行动,定义如下:
- CASTAIPMeasurementSystemexplained-FromQualityRulegradestoTechnicalCriteriongrade
- CASTAIPMeasurementSystemexplained-FromTechnicalCriteriongradestoBusinessCriteriongrade
以及事务图。
事务风险索引结合了从入口点到事务访问数据实体的事务路径上的健壮性、性能或安全性违规索引。
注意有一个TRI值仅为健壮性、性能和安全性而定义。