确定被开发软件的FIO(1) 如果产品需要开发软件组件,那么需要为这个组件设定FIO。 首先找出系统中预期的采办组件的FI。 根据操作数据,提供商担保,专家经验来估计。 通过从对应的系统FIO减去采办组件的FI,得到每个系统自记开发的软件的FIO。 确定被开发软件的FIO(2) 以Fone Follower为例,如果从硬件提供商那里得到数据,硬件组件的FI是每小时0.1个失效;操作系统在每小时10万次呼叫的情况下,每小时0.4个失效。转换之后得到,采办组件的失效强度为每百万次5次失效。 如果产品的FIO和采办组件的FI有比较大的差别,可以考虑使用其他的组件来替代。 直接累加采办组件的失效强度可以得到总采办FI。 是一种近似的计算方法,但是比较有效。实际的FI低于计算得到的FI。 指定策略以满足FIO(1) 选择正确的可靠性策略,在时间和金钱允许的情况下,尽可能提高满足目标的可能性。 可靠性策略的实施主要由系统工程师和系统架构师完成,但是该策略对测试的影响也非常大。 三种策略: 错误预防,错误清除,容错。 指定策略以满足FIO(2) 错误预防 应用适当的需求获取方法, 进行需求审查, 实现设计方法 进行设计复查, 建立和执行各种标准, 使用好的需求获取工具和设计工具等。 错误预防的有效性 通过估计进行预防活动之后的剩余错误的比例来度量。 指定策略以满足FIO(3) 错误清除 通过代码审查和测试清除错误。 代码审查的有效性由审查之后遗留错误的比例确定。 也许可以通过某种数据模型来估算剩余错误数量。 测试的有效性可以通过测试之前的FI和测试之后的FI的比例来度量。 这样的度量可以改进我们的测试方法。 * * * * * * * * * 定义必要的可靠性 可靠性的定量定义使我们能够精确地平衡客户对可靠性,交付日期和成本的要求,并更加有效地开发和测试产品。 失效/错误 失效(failure) 是指系统运行的行为对用户要求的偏离,是面向用户的概念。 只有在系统运行的时候才可能有失效。 错误(fault) 是指在系统运行时引发或可能潜在地引发失效的缺陷。是面向开发的概念。 失效严重程度类别(1) 失效严重程度类别 一组单个出现时对用户产生相同影响的失效。 指定失效的严重程度,主要是为了结合失效频率来解决失效的优先级。 分级标准 人员生命,成本,系统能力的影响。 还可能包括一些子标准:额外的运行成本,修复和恢复成本,…。 失效严重程度类别(2) 不可能精确估算失效的影响。 根据成本划分的失效严重程度类以10倍的关系划分。通常不超过四个级别。 失效严重程度类 定义 1 100000 2 10000-100000 3 1000-10000 4 1000 失效严重程度类(3) 根据对系统能力的影响划分失效严重程度类。 失效严重程度类 定义 1 用户不能进行一项/多项关键操作。 2 用户不能进行一项/多项重要操作 3 用户不能进行一项/多项操作,但是有不久方法 4 一项或多项操作中的小缺陷 失效强度(1) 失效强度是表示可靠性的一种简单直观的方式。 起初是指单位时间内出现失效的次数。 对于软件来说,执行时间是软件的度量方式。 虽然使用执行指令数目来度量软件的失效强度更加准确,但是和系统其他部分的度量不兼容。 失效强度(2) 有时,将失效强度表示为每个自然单位出现的失效数目更加方便。 比如打印机输出的页数,交易数目,电话呼叫次数等。 每打印10000页出现一次失败,每100000次电话出现电话掉线,… 失效强度的单位也可以用来表示可靠性。 失效强度(3) 如果系统的成功执行要求所有组件的成功执行,那么系统失效强度就是所有组件的失效强度的总和。 过程(1) 为了为每个产品系统分析定义必要的可靠性,我们需要 为产品定义进行了严重程度分类的失效 为所有相关的系统选择一种通用的度量 为每个测试的系统建立失效强度目标。 对于所开发的软件产品,针对该软件我们必须 找出所开发软件的失效强度目标。 指定策略以满足所开发软件的失效强度目标 定义失效 根据用户的需要,对程序行为创建消极需求。通过说明系统不应该做的事情来给出失效的定义。 这些消极需求(错误的行为)应该根据失效严重程度类别列出。而这些类的划分方法对每个项目都有所不同。 我们可以根据情况选择特定的严重程度类划分标准。 定义失效 Fone follower的失效严重程度类 失效严重程度类 定义 1 导致不能转发呼叫的失效。 2 导致不能输入要转发的呼叫号码的失效 3 使系统管理困难,但是可以用别的方法代替的失效 4 引起不方便的失效 选择通用度量 可靠性的度量方式可以选择自然单元。 一个产品可能具有多种自然单元,每个自然单元和一组重要的功能相联系。 此时可以选择时间作为失效强度的基础。 一般时间?执行时间?
原创力文档

文档评论(0)