第三讲定义必要的可靠性.ppt

*开发产品的FIO确定采购系统的失效强度运行数据供应商的保证专家的经验将所有的组件的失效强度相加得到系统的期待的采购件失效强度将系统的失效强度目标减去上述值得到开发产品的FIO。第29页，共51页，星期日，2025年，2月5日*计算开发组件的FIO例子:系统失效强度目标 =100failure/1,000,000transactions硬件的失效强度 =0.1failure/hourOS失效foraloadof100,000transactions =0.4failure/hour因此，要开发的软件的FIO =95failure/1,000,000transactions第30页，共51页，星期日，2025年，2月5日*注意点如果开发软件的失效强度目标与采购组件的失效强度目标之间差别很大，可以考虑让它们能够适当平衡如果开发软件的失效强度目标难以实现，可以调整系统的失效强度目标，或者调整采购组件的失效强度第31页，共51页，星期日，2025年，2月5日*联合可靠性（1）如果组件的失效相互独立，系统的可靠性可以通过各个组件的可靠性计算得到.对于AND关系:组件的可靠性(Rk)必须以相同的单位来表达QpnumberofcomponentsRkcomponentreliability第32页，共51页，星期日，2025年，2月5日*联合可靠性（2）运用可靠性和失效强度的关系:我们可以得到:也就是说，整个系统的失效强度是各个部件的失效强度之和第33页，共51页，星期日，2025年，2月5日*对于OR的关系如果AND-OR关系，需要具体分析某一软件的多个拷贝布置成OR的形式，并不服从上述公式，因为它们有相同的模式。如果相同的功能，有不同的公司开发，步骤成OR的形式，被称为N-版本开发。第34页，共51页，星期日，2025年，2月5日*5实现FIO的策略为了实现要开发的软件的软件失效强度目标，需要采取相应的策略（strategies）.3个主要的策略:缺陷预防（Faultprevention）缺陷消除（Faultremoval）缺陷容错（Faulttolerance）第35页，共51页，星期日，2025年，2月5日*5.1缺陷预防通过一定的措施避免缺陷的发生.活动:需求审查设计审查Clearcode建立标准(ISO9000-3,etc.)采用带有内部检查机制的CASE工具有效性:采取预防活动后遗留的缺陷的数量.第36页，共51页，星期日，2025年，2月5日*5.2缺陷消除对缺陷的存在通过验证和确认进行检测，然后进行消除.活动:代码审查测试有效性:经过代码审查失效强度的下降.测试前和测试后失效强度比.第37页，共51页，星期日，2025年，2月5日第1页，共51页，星期日，2025年，2月5日*内容错误,缺陷和失效如何定义必要的可靠性失效严重等级失效强度目标特殊情形第2页，共51页，星期日，2025年，2月5日*1.错误–缺陷–失效(1)错误(error)指的是人的行为导致软件包含某一缺陷(fault).缺陷(fault,bug)是导致程序失效或者某一个外部错误的原因(e.g.,anincorrectstate,incorrecttiming).在这三个因素中只有失效(failure)是可以观察到的.错误cause缺陷cause失效第3页，共51页，星期日，2025年，2月5日*1.错误–缺陷–失效(2)失效是面向用户的缺陷是面向开发者的失效依附于对系统的操作，因此是一个动态概念失效是与项目紧密相关的，必须考虑客户的需求第4页，共51页，星期日，2025年，2月5日*2.如何定义必要的可靠性对产品的定义带有失效严重等级“failureseverityclasses(FSC)”的失效.对所有相关的系统选择共同的度量标准.对每一个待测试的系统设置失效强度目标“failureintensityobjective(FIO)”.确定开发的系统的失效强度目标.确定满足软件失效强度目标的工程策略.第5页，共51页，星期日，2025年，2月5日*2.1定义带有严重等级的失效从反面的角度定义了系统必须不能够做什么该定义依据项目特征而定，并且对于整个项目而言是一个统一的标准第6页，共51页，星期日，2025年，2月5日*2.2对相关的系统选择共同的度量标准比如执行的