我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:2019跑狗图高清彩图 > 运行剖面 >

4、软件可靠性度量和测试

归档日期:07-23       文本归类:运行剖面      文章编辑:爱尚语录

  4.1.1软件可靠性发展史 4.1.2软件可靠性的定义 4.1.3软件可靠性的基本数学关系 4.1.4软件可靠性与硬件可靠性的区别 4.1.5影响软件可靠性的因素 4.1.6软件的差错、故障和失效 4.2.1软件可靠性模型 4.2.2软件可靠性模型参数 4.2.3软件可靠性模型及其应用 4.2.4软件可靠性模型评价准则 4.3.1软件可靠性评测 4.4.1建立以可靠性为核心的质量标准 4.4.2选择开发方法 4.4.3软件重用 4.4.4使用开发管理工具 4.4.5加强测试 4.4.6容错设计 4.5软件可靠性研究的主要问题 用软件系统规模越做越大越复杂,其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高,在一些关键 的应用领域,如航空、航天等,其可靠性要求尤为重要, 在银行等服务性行业,其软件系统的可靠性也直接关系到 自身的声誉和生存发展竞争能力。 特别是软件可靠性比硬件可靠性更难保证,会严重影响整个系统的可靠性。 在许多项目开发过程中,对可靠性没有提出明确的要求,开发商(部门)也不在可靠性方面花更多的精力,往往只 注重速度、结果的正确性和用户界面的友好性等,而忽略 了可靠性。 在投入使用后才发现大量可靠性问题,增加了维护困难和工作量,严重时只有束之高阁,无法投入实际使用。 硬件飞速发展,软件不相适应,硬件越来越可靠,而软件虽然采取了许多办法,但 常在带有剩余缺陷的情况下发布和部署, 使得软件已经成为系统崩溃的主要原因 1983年美国IEEE计算机学会对“软件可靠性”一词正式作出了如下的定义: 在规定的条件下,在规定的时间内,软件不引起系统失效的概率,该概率是系统输入和系统 使用的函数,也是软件中存在的错误的函数; 系统输入将确定是否会遇到已存在的错误(如 果错误存在的话); 在规定的时间周期内,在所述条件下程序执行所要求的功能的能力。 软件可靠性工程应用统计技术,处理在软件开发过 程中或(和)运行期间所采集的失效数 据,以便详细说明并预计、估计和评价 软件的可靠性 研究内容包括软件可靠性的基本概 念和定义、软件可靠性指标体系、可靠 性建模、可靠性设计技术、测试技术和 管理技术等 软件可靠性工程处理以下问题:确定某过程能否提供满足可靠性要求的代码 为过程改进提供度量 预测软件维护阶段的失效率,确定软件维护 工作量 帮助进行安全性认证 确定交付软件产品的时间或停止测试的时机 估计下次故障的可能时间 为软件更新或升级,标识需要重新设计的主 要部件 测定软件的可靠性 10 软件可靠性可靠性是软件的13个质量因素中最关键、 最重要的 软件可靠性是指在规定时间和条件下软件 无故障运行的概率,是系统功能或软件产 品中存在的缺陷的函数 软件故障产生的原因是软件缺陷,但缺陷 并不一定导致故障的产生,高缺陷率的软 件的可靠性不一定就差 软件失效意味着软件运行中断或者无法完 成所规定的任务 11 几个值得关注的问题: 软件的运行环境:软件可靠性与运行环境 密切相关 软件运行的时间间隔:商业软件需要较高 的运行时间间隔(较长的运行寿命),而 任务关键软件则需要在短时间内高效运行 软件失效的时机是随机的 不同于软件的正确性,对于持续运行的软 件其可靠性最终将归于零(以失效结束); 但正确性是软件的特定的某次运行结果, 要么为1,要么为0 12 4.1.4 最明显的是硬件有老化损耗现象,硬件失效是物理故障,是器件物理变化的必然结果,有浴盆曲线现象;软件不发生变化,没有磨损 现象,有陈旧落后的问题,没有浴盆曲线现象。 硬件可靠性的决定因素是时间,受设计、生产、运用的所有过程影响,软件可靠性的决定因素是与输入数据有关的软件差错,是输入 数据和程序内部状态的函数,更多地决定于人。 硬件的纠错维护可通过修复或更换失效的系统重新恢复功能,软件只有通过重设计。 对硬件可采用预防性维护技术预防故障,采用断开失效部件的办法诊断故障,而软件则不能采用这些技术。 事先估计可靠性测试和可靠性的逐步增长等技术对软件和硬件有不同的意义。 硬件可靠性检验方法已建立,并已标准化且有一整套完整的理论,而软件可靠性验证方法仍未建立,更没有完整的理论体系。 软件错误是永恒的,可重现的,而一些瞬间的硬件错误可能会被误认为是软件错误。 13 4.1.5 需求分析定义错误。如用户提出的需求不完整,用户需求的变更未及时消化,软件开发者和用户对需求的 理解不同等等。 设计错误。如处理的结构和算法错误,缺乏对特殊情况和错误处理的考虑等。 文档错误。如文档不齐全,文档相关内容不一致,文档版本不一致,缺乏完整性等。 14 不受控的变更15 4.1.6 缺陷。不符合使用要求或与技术规格说明不一致的任何状态常称为缺陷。 计算的、观测的或测量的值与真实的、规定的或理论上正确的值或条件之间的差别。 故障。在一个计算机程序中出现的不正确的步骤、过程或数据定义常称为故障。上述“差错”中的第二项属于故障。 失效。一个程序运行的外部结果与软件产品的要求出现不一致时称为失效。软件失效证明了软件中存在着故障。上述“差错” 中的第三项属于失效。 16 缺陷(Error,错误):设计和构造进产品 总数是不可预知的,只能估计 缺陷分为已知和未知(新发现)的 缺陷分为已发现的和未发现的 已发现的缺陷包括已纠正的和未纠正的 故障(Fault):运行结果错误故障是缺陷的表现形式,是由存在的缺 陷产生的 但缺陷并不一定导致故障,或者条件不 具备,或者不会产生故障 失效(Failure):系统不能完成所需要的功能而失败 失效是故障在软件运行时所产生的后果 失效 缺陷 故障 已纠正的缺陷 17 软件错误(error):在软件生存期内的不希望或不可接受的人为错误。 软件错误是一种人为过程,相对于软件本身,是一种外部行为。 软件缺陷(defect):是存在于软件(文档、数据、程 序)之中的那些不希望或不可接受的偏差。 其结果是软件运行于某一特定条件时出现软件故障, 这时称软件缺陷被激活。 有时又称“software bug”。 18 软件故障(fault):是指软件运行过程中出现的一种不希望或不可接受的内部状态。 此时若无适当措施(容错)加以及时处理,便产生软件失效。 是一种动态行为。软件失效(failure):是指软件运行时产生的 一种不希望或不可接受的外部行为结果。 19 面向用户面向开发者 软件运行偏离用户需求 程序执行输出错误结果 可根据对用户应用的严重性等级分 如,3次失效/1000CPU小时 如,6个故障/1KLOC 20 描述失效的方法有三个:累计失效函数:即与某时间点相关的平 均累计失效数 失效率函数:用累计失效函数的变化率 表示 平均失效时间MTTF函数:对于一个时 间段,表示若干相邻失效时间间隔的平 均值;对某个时间点,表示到下次失效 的期望时间 指标—平均失效前时间 定义(MTTF—Mean Time 指标—平均失效前时间举例 SF1: 180, 675, 315, 212, 278, 503, 431 SF2: 477, 1048, 685, 396 SF3: 894, 1422 MTTF SF1 370.57MTTF SF2 651.5MTTF SF3 115823 软件失效率如果没有缺陷,软件失效率为0 如果发现的缺陷能被及时、完全修复,失效率会趋向0 实际上,发现的缺陷数会递增,而纠正一个缺陷会引入更多 的缺陷,因而失效率会增加 时间 硬件软件(实际) 软件(理想) 24 4.2 4.2.1软件可靠性模型 为了对软件可靠性进行评估,除了进行软件测试之外,我们还需要借助软件可靠性模型的帮 助。软件可靠性模型(Software Reliability Model)是指为预计或估算软 件的可靠性所建立的可靠性框图和数学模型。 建立可靠性模型可以将复杂系统的可靠性逐级分解为简单系统的可靠性,以便于定量预计、 分配、估算和评价复杂系统的可靠性。 25 基本概念软件可靠性建模过程是根据软件过去的故障 行为建立软件可靠性数学模型的过程 建模的目的是为了预计软件将来的故障行为 建模过程包括以下步骤: 确定所期望的可靠性度量值并预测可能的故障行为 26 每天产品缺陷数 日期(天) 缺陷数 日期(天) 缺陷数 153月10日 12 103月12日 153月14日 对应的趋势图日期(单位:2天) 缺陷数 3/1-3/2 21 3/3-3/4 23 3/5-3/6 16 3/7-3/8 33 3/9-3/10 21 3/11-3/12 17 3/13-3-14 每两天产品缺陷数对应的缺陷数变化趋势图 以1天为单位, 缺陷变化的规 律不是很强 以2天为单位, 缺陷变化趋热 略平滑一点 26 27 软件可靠性模型通常假设失效之间是相互独立的。失效之间没有很强的关联性。对可靠性模 型的评价标准如下: 预测的覆盖率27 28 软件可靠性度量参数软件可靠性R(t)可定义为:在给定条件下,在时间[0,t]内,软件无 故障运行的概率 若用T表示软件无故障运行的时间间隔,F(t)为T的累积分布函数, 则软件可靠性可表示为: 故障率函数λ(t)为:其中,f(t)为F(t)的函数密度,即: 29λ(t)Δt是在时间[0,t]内软件正常运行,在[t,t+Δt]内发生故障的条件概 率,可得: 密度函数f(t)、累积分布函数F(t)、可靠性函数R(t)和故障率函数λ(t)紧 密相关,一般可由任一个惟一地确定另外三个,例如若λ(t)给定,则: 根据f(t)或R(t)可计算平均失效时间函数MTTF,从而预测故障时间 MTTFdt tf30 数据收集和分析是度量软件可靠性的最 重要的先决条件,任何可靠性度量的有效性 都与数据收集的有效性直接相关,数据收集 过程必须有计划、有组织地进行 与软件可靠性相关的数据包括: 缺陷数据的收集常采用问答、报告形式,即发放问题报告表格要求有关人员填写,收集并分析问题报告表格形 成统计数据 检测到的缺陷 已记录的缺陷 已评审的缺陷 确认? 结束 缺陷报告 采取措施? 通过验证? 记录不采取 措施的原因 记录纠正 验证 问题报告 YesYes Yes 32 缺陷数据必须与过程融合才有价值,因而过程数据也需要收集。通常会将项目的持续时间作为主要关心的过程数据, 但实际需要更细分 与软件可靠性测试过程相关的数据包括: CPU时间:具有与人无关性,但易忽略人的工作(如评 日历时间:优点是易于收集,但没有考虑阶段特征,如某些技术在某阶段更有效 运行时间:是为测试而运行软件的总时间,也未考虑阶 段特征 其他数据:包括平均修复时间、完成每个过程活动的人 数、软件生命期各阶段所用时间百分比、各阶段所消耗的资 源数量、各阶段的开始、截止日期、各阶段修复一个缺陷所 需的工作量、各功能模块的缺陷数,等等 33 系统的运行剖面与可靠性的关系 软件的运行剖面是用来描述软件的实际可能发生的操作路径的集合。运行剖面是否能代表、 刻画软件的实际使用取决于可靠性工程人员对 软件的系统模式、功能、任务需求及相应的输 入的分析,也取决于他们对用户使用这些系统 模式、功能、任务的概率的了解。运行剖面构 造的质量将对测试、分析的结果是否可信产生 最直接影响。 33 34 软件可靠性建模需要具备三个条件: 软件功能和运行环境软件运行剖面用于定量描述软件的用户运行环 境,即软件的功能和各功能的使用概率 35 输入数据--

  输入元素--

  向量--

  输入空间 程序输入空间元素数量庞大,程序运行中每个元素被选用的概率互不相同,构成一 定的概率分布,这个概率为软件的运行剖 不同运行模式的出现模式也不同运行模式1 运行模式2 功能 软件运行剖面与可靠性的关系软件可靠性度量、评估和预测与软件的某个特定的运行剖面 密切相关 软件测试期间,为节省时间和成本,通常每个运行剖面只测 试一次,因而不能反映每个剖面的出现概率,由此获得的可 靠性数据也不能反映实际情况 要将测试期间获得的可靠性值变换为实际值,可用以下公式: 其中,λ 是测试值,C为测试压缩系数 38C的含义是:在覆盖全部输入空间条件下,使用期间所要求的执行 时间与测试阶段所要求的执行时间之比 C的计算公式为: 其中, min为最少发生的输入状态的概率 39运行剖面对软件可靠性工程极具价值: 可为开发过程的资源分配提供参考,有利于提高生产率、可靠性和加快开发速度 有利于设计测试用例,以发现影响可靠性最大的故障 有助于用户培训40 确定运行剖面:确定系统各运行模式的发生概率41 软件可靠性建模是围绕着20世纪70年代的先驱工作者Telinski、Moranda、Shooman和 Coutinbo等人的工作展开的。 其基本方法是用过去的失效数据建立可靠性模型,然后用所建立起来的模型估计现在和预测将来的 软件可靠性。 该方法使用的先验条件是给定过去某个时期内的软件失效次数或软件的失效时间间隔。 因此,根据模型使用的这两种数据我们将模型分成如下两类: 两相临失效间的时间间隔模型。42 建立软件可靠性模型的目的是估计软件可靠性,提供开发状态、测试状态以及计划日程状态的参考定量数据,监视可靠性性能 及其变化。 一个好的模型必须有适合具体项目开发过程的正确的假设。如果不知道哪个模型最适合当前项目,那么,一个聪明的办法就 是在一个项目上执行一个以上的模型并且综合分析所得到的结 在软件可靠性模型先驱者的工作成果的基础上,经过更多软件可靠性工作者近40年的努力,软件可靠性模型到目前为止已经 出现了很多种,最为常见且比较具有代表意义的模型不下20个。 下面简单列举其中的几个: 威布尔模型。43 常见的软件差错包括非法转移、误转移、死循环、空间溢出、数据执行和无理数据等。在软件可靠 性分析和设计中,常常利用故障模型来对不同的 故障表现进行抽象。 故障模型可以建立在系统的各个级别上。建立的级别越低,进行故障处理的代价就越低,但模型 所覆盖的故障也越少。 常用的故障模型有基于逻辑级、基于数据结构级和基于系统级的故障模型。 44 软件可靠性模型的建立是通过对所选模型关联参数的统计来确定失效情况、可靠性目标和实现这 一目标的时间,并利用可靠性模型来制定测试策 略,同时确定软件交付的预期可靠性。 此外,它对经费估算、资源计划、进度安排和软件维护等也很重要。软件可靠性建模可归结为模 型的比较与选择、参数选择及模型应用。 模型参数取决于软件性能、过程特性、修改活动和程序变化等。由于软件本身的特性,以及缺乏 可靠性数据,因此建立完全满足这些因素的可靠 性模型非常困难,且难以验证。 45 从现有模型来预计软件可靠性,往往存在偏差。当给定或已知数据的基本分布时,极大似然估计 是模型参数估计最基本的方法,它显然有利于对 预计的改进。最小二乘法能很好地代替极大似然 估计, 它通过故障强度拟合来估计模型参数。对中小样本的情况,它具有较小的偏差和较快的收敛性。 Bayes分析方法提供了一种把先验知识综合到估计过程中的方法,为把不同数据源综合起来提 供了有效的手段,但其分析和计算极为复杂。 46 4.2.2 正如前面所说,当今存在着由很多软件可靠性工作者开发的很多软件可靠性模型。 这些模型使用了由各个软件可靠性工作者定义的各种各样的参数。 因此,在本章讨论中,为了使变量名称一致,也为了书写和读者查阅方便,我们对 变量名称统一定义如下: 47 与软件可靠性模型相关的参数有:ETF:软件中固有缺陷数,是固定的 ETV:同上,是变化的,在开发、维护过程中随时添加 EC(t):某时刻已纠正的缺陷数 ED(t):某时刻已发现的缺陷数 P:在修正缺陷过程中测试的循环次数,常假定 P=ED(t)=EC(t) EC(p):直到第p次测试才修正的缺陷数 :当前故障率θ:故障率的变化 τ:累计执行时间 α:增长率 N:测试用例运行总数 S:成功的测试用例运行总数 48 软件可靠性模型的分类Musa、Okumoto根据模型的5个特征进行分类: 时间域(timedomain):日历时间、执行时间 或CPU时间 类别(Category):软件在无限的时间内可能经历的故障数是有限的还是无限的 种类(Class):故障密度对时间的函数分布(仅对有限故障类) 族(Family):故障密度对它的期望故障数的函数分布(仅对无限故障类) 有限故障数模型 种类 泊松分布二项式分布 其他 指数分布 Mussa (1975) Moranda Schneide wind Goel- Okumoto Jelinski- Moranda Shooman Goel-Okumoto Mussa Keiller-Littlewood Weibul l分布 Schick- wolverto WagonerC1分布 Schick- wolverto Gamma分布 Y-O-O 无限故障数模型 50 基本模型假设:每个缺陷对故障率的贡献是相同的;每 修正一个缺陷故障率均匀地减少,即故障率对 时间的导数是常数;软件固有的故障总数是 有限的,但不固定,即修正缺陷时可能产生新 缺陷 Musa模型: ETV 51利用基本模型可估计要达到某 可靠性目标还必须要发现(检 测出)的缺陷数和需要的时间, 有助于计划人力和时间 设要达到的可靠性目标为λ 当前已检测出的累 积缺陷数 为达到故障率目 标或MTTF目标 必须要检出的累 计缺陷数 为达到目 标还需检 测出的缺 为达到目标需要的时间 测试时间 已检出 的累计 缺陷数 52 对数模型假设:每个缺陷对故障率的贡献不同;常 用的功能的缺陷可及早被检出,故障率的变化 随时间减少;软件固有的故障总数是无限的 Musa模型: Goel-Okumoto模型假设:缺陷对时间的分布是非时对齐的,即发 现的缺陷不一定会立即消除(适用于开发早期) 基本模型: 其中,ab为常数,与单位时间内发生的缺陷有 可得:修正模型: 故障密度函数为Weibull分布 bt abe btae 模型假设 适用阶段 难易度 Mussa基本模 优先固有缺陷数常数故障率 指数分布 集成测试后 无限固有缺陷数对数分布 故障率随时间变化 单元测试到 系统测试 Goel-Ukumoto 非时齐缺陷分布 缺陷可能因修复而产 指数、Weibull分布集成测试后 554.2.4 模型噪声单位斜率线 软件可靠性评价是软件可靠性工作的重要组成部分。软件可靠性评测是主要的软件可靠性评价技术,它包括测试与 评价两个方面的内容,既适用于软件开发过程,也可针对 最终软件产品。 在软件开发过程中使用软件可靠性评测技术,除了可以更快速地找出对可靠性影响最大的错误,还可以结合软件可 靠性增长模型,估计软件当前的可靠性,以确认是否可以 终止测试和发布软件,同时还可以预计软件要达到相应的 可靠性水平所需要的时间和测试量,论证在给定日期提交 软件可能给可靠性带来的影响。 对于最终软件产品,软件可靠性评测是一种可行的评价技术,可以对最终产品进行可靠性验证测试,确认软件的执 行与需求的一致性,确定最终软件产品所达到的可靠性水 57软件测试的类型 与软件可靠性相关的测试主要是动态测试 执行一种有效的方法来收集问题报告缺陷数据、过程数据和产品数据,收集集成测试期间及以后的数据 按照模型规定的原理和方法,将数据输入选定的模型,直接估计软件可靠性或间接地估计与其有关的参数 根据估计结果进行决策:软件能否被释放(发布)? 是否需要增加测试时间以达到可靠性目标?如果需 要,还需要多少时间? 59 Beta测试可以直接反映可靠性水平 系统软件证明测试在要求时间内、在实际的使用环境中运行系统,不对 系统进行维护,收集发现的故障数,以决定整个系统 能否通过可靠性测试 基于测试时间的软件证明测试在相对较长时间内对软件的运行进行软件证明测试 基于测试输入的软件证明测试只针对特定的测试用例进行软件证明测试 60 测试前,先由测试者和用户共同确定以下三个参数: 用户风险因子α:是由用户承担的软件可靠性未达目标而通过测试的风险 生产者风险因子β:是由开发者承担的可靠性已达目标而未被接受的风险 鉴别因子γ:是最大可接受的失效密度和失效密度目标的比值 61 确定可靠性测试判定标准根据已确定的三个参数绘制软件 可靠性证明测试判定图 确定拒绝线 和接受线 规格化是指将测试时间或测试用 例数乘以故障率目标值 ln(ln 规格化的测试时间或测试输入 在测试期间发 现的累计缺陷数 测试通过 测试未完 测试失败 接受线 拒绝线 lnln 测试开始后,失效发生时,将对应的累计故障数和测试时间或测试用例数在图中标 判定测试结果:通过或失败都表示测试结束,若测试未完成,则继续测试 注:基于测试用例的证明测试具有随机性,不 同测试可能得到不同结果,为此可采用模 块化方法选择测试用例,以保证测试的客 1、概述软件可靠性测试有两类: 开发测试:包括性能测试、加载测试、回归测试,目的是发现和修正单元及其集成的缺陷 确认测试:一般只进行加载测试,目的是为了确定软件部件或系统是否被接受 对于软件可靠性建模,开发测试收集的是分组数据, 是不完整的,而确认测试获得的是完全数据 64 软件可靠性测试过程模型开发业务剖面是软件可靠性测试的重要环节,因为可靠 性目标与业务剖面关系密切 软件可靠性目标 开发系统业务剖面 准备测试 软件可靠性定量评估 软件可靠性模型 执行测试 收集、整理故障数据 对比 需求与构造 设计和实现 集成测试和确认测 接受或拒绝65 3、测试的目的 通过在规定的业务剖面下运行软件系统,确认是否能够 完成于业务剖面相关的任务: 提供运行中的故障数据4、用户责任 用户要参与软件测试: 要球组织独立的测试组织66 5、测试的准备和执行 测试准备:准备测试用例、测试程序并决定要使用的自 动化测试工具 测试用例设计须考虑可靠性定量要求和成本及效率,测试 用例的数量和类型选择要与业务剖面及发生概率一致,且 考虑到随机性 测试程序与特定的业务剖面相关,要考虑发生概率 测试执行:从性能测试开始进行加载测试,要考虑业务 剖面和运行模式已分配执行时间和测试用例 测试执行过程需进行故障识别,记录故障发生时间和严重 引发故障的缺陷什么时候、在那里出现?原因是什么?如何定位?什么时候该定位被确认? 要进行的修改有哪些?67 6、测试结果的应用 用户根据测试结果评估可靠性并进行决策 开发者由此产生软件更新需求,或者改进过程和设计 7、需要注意的问题 测试时间计划不周会导致在开发过程后期发现缺陷的风险增加 测试等级及相应的测试时间分配选择不得当将不能保证在不牺牲质量的前提下降低成本 测试工具的选择将影响测试效率和完整性68 4.4 4.4.1建立以可靠性为核心的质量标准 在软件项目规划和需求分析阶段就要建立以可靠性为核心的质量标准。这个质量标准包括实现的功能、可靠性、可维护 性、可移植性、安全性、吞吐率等等,虽然还没有一个衡量 软件质量的完整体系,但还是可以通过一定的指标来指定标 准基线。 静态质量是通过审查各开发过程的成果来确认的质量,包括模块化程度、简易程度、完整程度等内容。动态质量是考察 运行状况来确认的质量,包括平均故障间隔时间(Mean Time Between Failures,MTBF)、软件故障修复时 间(Mean Time RepairFault,MTRF)、可用资 源的利用率。在许多实际工程中,人们一般比较重视动态质 量而忽视静态质量。 69 需求分析质量度量完整性,准确性 设计结果质量度量可读性。可理解性、测试情况数 测试结果质量度量测试工时、差错状况、差错数量 验收结果质量度量完成的功能数量、各项性能指标、可靠性 70 4.4.2 目前的软件开发方法主要有Parnas方法、Yourdon方法、面向数据结构的Jackson方法 和Warnier方法、PSL/PSA方法、原型化方 法、面向对象方法、可视化方法、ICASE方法、 瑞理开发方法等,其他还有BSP方法、CSF方法 等。这里特别要提一下的是Parnas方法。 71 4.4.3 软件重用不仅仅是指软件本身,也可以是软件的开发思想方法、文档,甚至环境、 数据等,包括三个方面内容的重用: 开发过程重用,指开发规范、各种开发方法、工具和标准等。 知识重用,如相关领域专业知识的重用。72 4.4.4 开发一个大的软件系统,离不开开发管理工具,作为一个项目管理员,仅仅靠人来管理是不够的,需要有开发管理 工具来辅助解决开发过程中遇到的各种各样的问题,以提 高开发效率和产品质量。 如Intersolv公司的PVCS软件开发管理工具,在美国市场占有率已超过70%,使用PVCS可以带来不少好处: 规范开发过程,缩短开发周期,减少开发成本,降低项目投资风险;自动创造完整的文档,便于软件维护;管理软件多 重版本;管理和追踪开发过程中危及软件质量和影响开发周 期的缺陷和变化,便于软件重用,避免数据丢失,也便于开 发人员的交流,对提高软件可靠性,保证质量有很大作用。 73 4.4.5 测试设计规范:详细描述测试方法,规定该设计及其有关测试所包括的特性。还应规定完成测试所需的测试用例和测试规程,规定特 性的通过/失败判定准则。 测试用例规范:列出用于输入的具体值及预期输出结果。规定在使用具体测试用例时对测试规程的各种限制。 测试规程规范:规定对于运行该系统和执行指定的测试用例来实现有关测试所要求的所有步骤。 走查(Walk-through),即手工执行,由不同的程序员(非该模块设计者)读代码,并进行评论。 设计审查,关于设计的所有各方面的小组讨论会,利用所获得的信息,找出缺陷及违反标准的地方等。 74 实质:在常规的软件设计中,应用必须的方法和技术,使程序设计在兼顾用户的各种需求时, 全面满足软件的可靠性要求 容错设计75 避错(Defectavoidance) 第一次就做正确 排错(defectremoval) 早发现,早实施 容错(Defect tolerance) 有缺陷,也能正确的完成任务 恢复选用最佳恢复策略,失效后继续工作 76 11 使软件产品在设计过程中,不发送错误或少发生错误的一种设计方法 控制程序的复杂度使系统中的各个模块具有最大的独立性 使程序具有合理的层次结构 当模块或单元之间的相互作用无法避免时,务必使其 联系尽量简单,以防止在模块和单元之间产生未知的 边际效应,使设计人员陷入泥潭,无力自拔 与用户保持紧密联系77 模块:模块是由边界元素限定的相邻的程序元素(例如数据说 明,可执行语句)的序列,而且有一个总体的标识符来代 如pascal和Ada中的块结构中的Begin…end对,或者Java中的{} 因此,过程、函数、子过程、子函数、宏等都可以作为 模块 面向对象中的对象以及对象内的方法也是模块 就是把程序划分成若干个模块,每个模块完成一个子功能,把这些模块集成起来组成一 个整体,可以完成指定的功能,解决实际问 2016-11-2777 78 2016-11-27 78 经验1:工作量E(P 模块最小成本区 接口成本 软件总成本 模块数目 79 人类在认识复杂现象的过程中使用的最强有力的思维工具是抽象。人们在实践中认识到,在现实世界中一定事 物、状态或过程之间总存在着某些相似的方面(共性)。 把这些相似的方面集中和概括起来,暂时忽略它们之间 的差异,这就是抽象。或者说抽象就是抽出事物的本质 特性而暂时不考虑它们的细节。 2016-11-27 79 802016-11-27 80 例:开发一个CAD软件,实现一个二维绘图系统的全部功能,供低级计算机辅 助设计使用。 在我们考虑对任何问题的模块化解法时,可以抽象出很多层次。 在抽象的最高层次使用问题环境的语言,以概括方式叙述问题的解法 在较低的层次采用更过程化的方法,把面向问题的术语和面向实现的术语结合起来叙述问题的解 最后,在最低的抽象层次可以直接实现的方法来叙述问题的解法 81 2016-11-27 81 该软件包括一个计算机绘图界面,向绘图 员显示图形,以及一个数字化仪界面,用 以代替绘图板和丁字尺。所有直线、折线、 矩形、圆及曲线的描画、所有的几何计算、 所有的剖面图和辅助视图都可以用这个 CAD软件实现……。 82 2016-11-27 82 抽象层次II:任务需求的描述。列出“What”而不是“How”。 CAD SOFTWARE TASKS: user interaction task; 2-D drawing creation task; graphics display task; drawing file management task; END 83 2016-11-27 83 抽象层次III:程序过程表示。以2-D绘图生成任务为例:PROCEDURE 2-D drawing creation REPEAT UNTILE (drawing creation task terminates) DO WHILE (digitizer interaction occurs) Digitizer interface task; DETERMINE drawing request CASE Line: line drawing task; Rectangle: rectangle drawing task; Circle: circle drawing task; END;DO WHILE (keyboard interaction occurs) keyboard interaction task; PROCESS analysis/computation CASE View: auxiliary view task; Section: cross sectioning task; ENDREPETITION; END PROCEDURE. 在这个抽 象层次上,给出 了初步的过程表 示,所用的术语 都已面向软件, 而且模块化的工 作已经开始显露。 84 信息隐藏原理指出:应该这样设计和确定模块,使得一个模块内包含的信息对于不需要这些信息的模 块来说,是不能访问的。“只有需要才能知道” 如果绝大多数数据和过程对于软件的其他部分而言是隐蔽的,那么在修改期间由于疏忽而引入的错误 就很少可能传播到软件的其它部分 局部化是指把一些关系密切的软件元素物理地放得彼此靠近 局部变量85 (4)模块独立性(Module independence) 每个模块完成一个相对独立的特定子功能,并且和其他模 块之间的接口很简单。 模块的独立程度可以由两个定性标准来衡量,这两个标准 分别称为耦合性和内聚性。藕合衡量不同模块彼此间互相 依赖(连接)的紧密程度;内聚衡量一个模块内部各个元 素彼此间结合的紧密程度。 一般较较优秀的软件设计应尽量做到高内聚、低耦合,即 减弱模块间的耦合性和提高模块内的内聚性,有利于提高 模块的独立性。 2016-11-27 85 86 2016-11-27 86 争取低耦合、高内聚(增加内聚

  减少耦合) •如果在几个模块中发现共有的子功能,一般应该将该子功能独立出 来作为一个模块,以提高模块的独立性 •合并那些具有较多的控制信息传递的模块以降低模块之间的耦合度 87 2016-11-27 87 模块规模适中:过大不易理解;太小则接口开销过大。注意分解后不应降低模块的独立性。 适当控制——深度、宽度、扇出、扇入 深度=分层的层数。宽度越大系统越复杂 宽度=同一层上模块数的最大值。过大表示 系统复杂度大。 88 2016-11-27 88 系统结构89 2016-11-27 89 扇出=一个模块直接 调用\控制的模块数。 扇出越大意味着模块过分复杂,应该适当增加中间 扇出太小则可以把下级模块进一步分解成若干子模 块,或者把该模块合并到 它的上级模块中 A的扇出90 2016-11-27 90 A的扇入扇入= 直接调用该模 块的模块数 在不破坏独立性的前提 下,fan-in 大的比较好。 一个好的软件结构通常顶层扇出较高,中间层扇出较低,底层又高扇入到公共模块中去 91 2016-11-27 91 4、作用域在控制域内 控制域:包含该模块和所有从属于该模块 的模块 922016-11-27 92 TOP 模块D的作用域超出控制域D的作用域在控制域内 93 2016-11-27 93 定影响94 2016-11-27 94 5、降低接口的复杂程度:接口复杂可能表明模块的独立性 6、设计单入单出的模块。当从顶部进入模块并且从底部退出时,软件是比较容易理解和维护的 95 7、模块功能可预测——相同输入必产 生相同输出。反例: 模块中使用全局变量 或静态变量,则可能 导致不可预测。 2016-11-27 95 96 软件避错设计 默认输入的处理97

本文链接:http://myclayclub.com/yunxingpoumian/269.html