第八章--维护

合集下载

软件工程导论PPT课件-第8章-维护

软件工程导论PPT课件-第8章-维护
改错或修改的要求不能及时满足引起的用户不满; 维护时的改动,引入潜伏错误,导致软件质量降低; 软件工程师从事维护工作造成的开发过程混乱。 生产率的大幅下降 维护工作量:生产性劳动+非生产性劳动。
分析评价,修改设计,编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序,缺乏必要的文档说 明,难于确定数据结构、系统接口等特性的情况下,进行 的软件维高昂
明显代价:高昂的维护费用,已上升达80%左右; 无形代价:
的工作环境,或适应已变动的数据或文件; (4)为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程, 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求, 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化, 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等,或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审

第八章软件维护

第八章软件维护
3
④ 软件维护工作是一项难出成果,大家都不愿意干的工作。
8.1.4 软件维护的代价
1.软件维护的工作量大 软件维护的费用在整个软件开发费用的 55%-70%,并且所占比例在逐年上升。而且维 护中还可能产生新的潜在错误。例如 1970 年维护费用约占软件开发费用的 40%,到 1990 年维护费用所占比例就超过了 70%。另外维护还包含了无形的资源占用,包括大量的使用 很多硬件、软件和软件工程师等资源。 在软件维护时,直接影响维护成本和工作量的因素很多,主要如下: (1)系统规模大小 系统规模大小直接影响维护工作量,系统规模越大,仅仅看懂理解就很困难,维护的 工作量就更多。系统规模主要由源代码行数、程序模块数、数据接口文件数、使用数据库 规模大小等因素衡量。 (2)程序设计语言 参与软件开发的人员都知道,解决相同的问题选择不同的程序设计语言,得到的程序 的规模可能不同,由此应选择功能强且适合解决问题的程序设计语言,这样可以使生成程 序的指令数更小。 (3)系统使用年限 使用年限长的老系统维护比新系统所需要的工作量更多。老系统因已经进行多次维 护,参与维护的人员也不断变化,因此这样的系统结构更乱,如果没有系统说明和设计文 档,维护就更加困难。 (4)软件开发新技术的应用 软件开发过程中,使用先进的分析和设计技术,以及程序设计技术,如:面向对象的技术、 构件技术、可视化程序设计技术等,可以减少维护工作量。 (5)设计过程中的技术 在具体对软件进行维护时,影响维护工作量的其他因素还有很多,例如设计过程中应 用的类型、数学模型、任务的难度、开关与标记、IF 嵌套深度、索引或下标数等。 2.软件维护工作量模型 维护活动分为生产性活动和非生产性活动。生产性活动包括分析评价、修改设计和编 写程序代码等。非生产性活动包括理解程序代码,解释数据结构,接口特点和设计约束等。 Belady 和 Lehman 提出软件维护工作模型:

软件工程课件之第8章维护第6版张海潘编著

软件工程课件之第8章维护第6版张海潘编著
(1) 必须描述如何使用这个系统,没有这种描述时即 使是最简单的系统也无法使用; (2) 必须描述怎样安装和管理这个系统; (3) 必须描述系统需求和设计; (4) 必须描述系统的实现和测试,以便使系统成为可 维护的。
用户文档
用户文档至少应该包括下述5方面的内容:
功能描述,说明系统能做什么; 安装文档,说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表,由申请维 护的用户填写。
软件修改报告,由软件组织内部制定,指明:
满足某个维护要求表中提出的要求所需要的工 作量;
维护要求的性质; 这项要求的优先级; 与修改有关的事后数据;
维护的事件流
维护的事件流
尽管维护申请的类型不同,但都要进行同样 的技术工作:
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点,从抽象到具体, 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中,应该对将来要 改进的部分和可能会修改的部分加以注意并指 明;应该讨论软件的可移植性问题,并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题,都可归 因于软件定义和软件开发的方法有缺点:
① 理解别人写的程序通常非常困难,而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档,或者文 档资料显著不足。
③ 当要求对软件进行维护时,不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例

第八章巷道维护原理和支护技术

第八章巷道维护原理和支护技术

0.64
0.36
B h
R R
RC RC
0 .778 0 .778
0.222 0.222
B hB
h
R R
RC1 RC1
0.64 0.64
0.36 0.36
B hB
h
第一节 无煤柱护巷
一、护巷煤柱得稳定性
2、 煤柱得应力分布
1)一侧采空
煤柱(体)得承载能力,随着远离煤体
(煤柱)边缘而明显增长。在距煤体(煤柱)
第二节 巷道围岩卸压
一、跨巷回采进行巷道卸压
跨巷 回采
横跨 纵跨
1-不留区段煤柱、先跨;2—留区段煤柱、先跨; 3—留区段煤柱、后跨;4—较宽得煤柱维护上山
第二节 巷道围岩卸压
二、巷道围岩开槽卸压及松动卸压
1、 巷道周边开槽(孔)对围岩应力分布得影响
开槽卸压原理:使作用于 周边围岩得高应力向卸压 压区以外得岩体深部转移
2
第一节 无煤柱护巷
一、护巷煤柱得稳定性
1、 煤柱得载荷
各种方法得基本观点一致:煤柱得宽度必须保证煤柱得极限载荷σ
不超过它得极限强度R(七章一节)。煤柱得宽度B计算式:
1000B
B
D H
1 4
D
2
cot
RC
0.778
0.222
B h
1000B
B
D
H
1 4
D
2
cot
RC 1
边缘一定宽度内,存在着煤柱(体)得承载能
力与支承压力处于极限平衡状态,运用岩体
得极限平衡理论,塑性区得宽度x0:
x0
m 2 f
K H C cot
ln p1 C cot

08.第八章 汽车维护规范

08.第八章 汽车维护规范

失速试验时应注意以下事项: 试验持续时间绝对不准超过5s。失速试验时,踩下制动踏 板相当于固定液力变矩器的涡轮;而踏下加速踏板又相当 于使发动机的输出功率达到最大,其输出转矩也最大。此 时发动机的输出功率没有经液力变矩器向变速器输出,而 是全部消耗在变矩器内的作液上,工作液获此能量后温度会 急剧升高。 在试验时,为保证安全,手制动和脚制动要绝对可靠。 试验应在宽敞、平整的地面上进行。 测试时需两个人,一个人做失速试验,一个人在车外观察 车轮和挡块情况。 要严格掌握工作液温度,试验时其正常温度应为 50℃~80℃。
汽车二级维护首先要进行检测,汽车进厂后,根据汽车 技术档案的记录资料(包括车辆运行记录,维修记录, 检测记录,总成修理记录等)和驾驶员反映的车辆使用 技术状况(包括汽车动力性,异响,转向,制动及燃、 润料消耗等),确定所需检测项目,依据检测结果及车 辆实际技术状况进行故障诊断,从而确定附加作业项目。 附加作业项目确定后与基本作业项目一并进行。二级维 护过程中要进行过程检验,过程检验项目的技术要求应 满足有关的技术标准或规范;二级维护作业完成后,应 经维护企业进行竣工检验,竣工检验合格的车辆,由维 护企业填写《汽车维护竣工出厂合格证》后方可出厂。
失试验结果分析:
若两个挡位(R档位和D挡位)失速值相同且都低于标准
值,原因可能是发动机输出功率不足,或变矩器故障;若失 速值低于标谁值600r/min以上,则说明变矩器有故障。 若D档失速值高于标准值,故障原因可能是:油路压力过 低,前进离合器打滑,第二单向离合器不能正常工作,超速 (或减速)单向离合器不能正常工作。 若R挡位失速值高于标准值,则其故障原因可能是:油路 压力过低,直接离合器打滑,低倒档制动器打滑,超速或 减速单向高合器不能正常工作。 若R和D档位失速值都高于标准值,则其故障原因可能是: 油路压力过低,工作液液面高度不正确,超速(或减速) 单向离合器不能正常工作。

第8章_软件维护(徐东升)

第8章_软件维护(徐东升)

西安文理学院
软件学院
8.2 软件维护的特点 8.2.1 结构化维护与非结构化维护差别巨大
1. 非结构化维护 如果软件配置的惟一成分是程序代码,那么维护 活动从艰苦地评价程序代码开始,对软件结构、数据 结构、系统接口、设计约束等常产生误解,不能进行 回归测试,维护代价大。 非结构化维护需要付出很大代价,这种维护方式 是没有使用良好定义的方法学开发出来的软件的必然 结果。也就是就说在设计时未采用结构化程序设计方 法。
最后,把修改后的软件再次交付使用。
西安文理学院
软件学院
8.2.2 软件维护的代价
1. 有形代价与无形代价
软件维护的代价表现为有形代价和无形代价。 有形代价指软件维护的费用开支。在过去的几十年中,软
件维护的费用稳步上升。
70年代,用于软件维护的费用只占软件总预算的30%~ 40%,80年代上升到60%左右,90年代许多软件项目的维护 经费预算达到了80%。
西安文理学院
软件学院
该模型描述了影响维护的诸多因素中重要的
关系。如果一个系统开发没有遵循软件工程原 则,软件结构不好,c的值就会很高,再加上 维护人员对软件的不熟悉,原来参加开发的人 员或小组不能参加维护,d的值很低。结果是, 维护的工作量和成本将呈指数级增加。
西安文理学院
软件学院
8.2.3 程序修改的步骤及修改的副作用
西安文理学院
软件学院
实际应用中,常常是混合以上几种方法。对 系统不重要的部分采用直接方式,对系统重要部 分采用并行方式,使系统平稳交付使用。
西安文理学院
软件学院
8.1 软件维护的定义
8.1.1 软件维护的基本内容 所谓软件维护就是在软件已经交付使用 之后,为了改正错误或满足新的需要而修改 软件的过程。

软件工程 第8章 软件维护

软件工程  第8章  软件维护

8.4.2 软件可维护性的度量
3. 可测试性 4. 可修改性 5. 可移植性 6. 效率 7. 可使用性 8. 间接度量可维护性的方法
8.4.2 软件可维护性的度量
8. 间接度量可维护性的方法
(1) 了解问题的时间; (2) 行政管理拖延的时间; (3) 收集维护工具的时间; (4) 分析问题的时间; (5) 改变规格说明的时间; (6) 具体的改错或修改的时间; (7) 局部测试时间; (8) 整体测试时间; (9) 维护重审时间; (10) 总体恢复时间。

8.4 软件的可维护性
8.4.1 影响可维护性的因素 软件的可维护性可以简单定义为:纠正软件系统出现 的错误和缺陷,以满足新的要求, 能够被理解、被校正、 被修改或被改善的难易程度。可维护性不但与采用的 分析设计方法和开发人员的技术熟练程度有关,更重 要的是与软件项目的管理技术关系密切。软件的可维 护性成为软件开发阶段各个时期的关键目标。
8.1 软件维护的种类
完善性维护 50%
预防性维护5%
改正性维护 20%
适应性维护 25%
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明,有代表性的软件开发组织用于校正性 维护、适应性维护、完善性维护及预防性维护的费用 占其开发总金额的70%至80%。 很多软件机构被束缚在维护工作上,这是软件维护所 带来的无形支出。

8.2.3 非结构化维护

无说明或者文档资料太少由于没有采用定义良好的软 件项目管理过程来开发软件,软件项目管理的缺陷导 致的叫“非结构化维护”,这会使软件维护付出较高的 代价.
8.2.4 结构化维护

存在完整的软件系列文档,那么维护任务就从分析设 计文件开始,确定软件的重要结构特性、功能特性和 接口特性,确定所要求的修改或校正可能产生的影响, 并且计划采用何种维护处理方法,修改设计并进行复 审,编制出新的源程序,利用文档中的信息进行回归 测试,然后重新交付软件。这种维护过程就叫做“结 构化维护”

软件工程第八章维护

软件工程第八章维护

软件工程第八章维护第一点:软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动,旨在确保软件系统的持续可用性、可靠性和性能。

软件维护是软件开发生命周期中的一个重要环节,它涉及到对软件进行修正、优化和升级。

软件维护的重要性体现在以下几个方面:1.保障软件质量:软件在实际运行过程中可能会出现各种问题,维护可以帮助及时修复这些问题,保证软件的正常运行。

2.提高用户满意度:通过维护,可以对软件进行功能优化和界面调整,使其更加符合用户的需求,提高用户的使用体验。

3.降低风险:软件维护可以帮助提前发现并解决潜在的风险,避免因软件问题导致的损失。

4.延长软件寿命:通过不断的维护和升级,可以使软件适应不断变化的环境和需求,延长其使用寿命。

5.提高开发效率:良好的维护可以避免因软件问题导致的重复开发,提高开发团队的效率。

第二点:软件维护的类型和策略软件维护可以分为以下几种类型:1.改正性维护:这种维护类型主要是针对软件中存在的问题和错误进行修复,保证软件的正常运行。

2.适应性维护:随着环境的变化和用户需求的变化,软件需要进行相应的调整和优化,以适应新的环境和工作需求。

3.完善性维护:这种维护类型主要是针对软件的功能进行增强和扩展,以满足用户的新需求。

4.预防性维护:预防性维护是为了避免软件出现潜在的问题和风险,提前对软件进行调整和优化。

在进行软件维护时,可以采取以下策略:1.计划维护:制定详细的维护计划,包括维护的时间、内容、责任人等,确保维护工作的有序进行。

2.变更管理:对于软件的修改和更新,需要进行严格的变更管理,确保每次变更都是经过审核和评估的。

3.版本控制:通过版本控制工具,对软件的不同版本进行管理,确保软件的每个版本都是可追踪和可恢复的。

4.文档管理:对软件的维护过程和结果进行详细的文档记录,方便对软件进行管理和维护。

5.持续集成:将软件的维护工作与开发工作结合起来,通过持续集成的方式,确保软件的质量和稳定性。

第8章软件维护

第8章软件维护

软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1)编码副作用:在使用程序设计语言修改源代码时可能引起的错误, 如删除或修改一个标号、标识符、一个子程序,改变程序代码的时序关系, 改变逻辑运算符,改进程序的执行效率,改变程序占用存储的大小等,都 很容易引入错误,应特别小心。 2)数据副作用:在修改数据结构时,有可能造成软件设计和数据结构 的不一致,而导致软件错误。数据副作用是修改软件信息结构引起的,如 重新定义全局或局部常量,重新初始化控制标志或指针等,都容易产生设 计与数据不相容的错误,可通过详细设计文档对数据副作用加以控制。 3)文档副作用:对数据流、软件结构、逻辑模块等进行修改时,必须 对相关技术文档进行修改,否则会导致 文档与程序功能不匹配,使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序:
1)静态确认; 2)计算机确认; 3)维护后的验收。
软件维护步骤
第三步:维护文档整理
记录一些与维护工作有关的数据信息,这些信息 可作为估计软件维护的有效程度,确定软件产品的 质量,确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步:维护活动评价
具体的评价工作可从以下几个方面考虑: (1)每次程序运行时的平均出错次数; (2)花费在每类维护活动上的总的“人时”数; (3)每个程序、每种语言、每种维护类型程序的平均修改次数; (4)维护工作中增加或删除每个源程序语句所花费的平均“人 时”数; (5)用于每种语言的平均“人时”数; (6)维护申请报告的平均处理时间; (7)各类维护申请的百分比。 一方面,可判定此次维护活动开展是否顺利、成功;另一方面, 为今面的维护工作积累经验。
2、结构化维护:进行维护 活动时,首先从评价需求开始,搞清楚 功能、性能上的改变,然后对设计说明文档进行评价、修改和复查; 根据设计的修改,再进行程序的变动;然后根据测试文档中的测试 用例进行回归测试;最后将修改后的软件再次交付使用。

第八章 心理健康及其维护

第八章 心理健康及其维护

第八章心理健康及其教育内容简介:心理健康既是动词也是名词还是形容词,动词性心理健康主要是指心理健康是指心理的动态平衡的适应过程,名词性心理健康是指心理健康是一系列心理健康标准,形容词性的心理健康乃是心理运行状态的积极与消极状态,从系统论和热力学熵值来看,心理健康是适应过程和适应状况的统一,是在生物、心理和社会以及主体性自我意义与价值世界的存在中多维、多层次的适应过程与状况的统一。

心理健康等级则是适应过程和熵状态的辩证变化的具体表现,从适应状态中的负熵与正熵的对比中可以更加客观和真实地了解心理健康状况的等级。

心理健康的测量不仅应该关注消极状态,而且也应该关注积极状态,同时对于心理健康的维护,要做到他助模式和自助模式、互助模式的统一,针对大学生群体应该从自身心理特点、学校特点出发,形成自身的心理健康教育模式。

第一节心理适应过程与熵:一条整合积极与消极趋向心理健康范式的思路在心身统一的健康理念下,心理健康已然成为健康的内涵之一。

然而,近百年来,关于心理健康本质以及心理健康标准的诸多研究范式各执一端,众说纷纭,颇有盲人摸象的意味。

对心理健康的完整理解,需要一条能整合各个心理健康研究范式的思路。

一、心理健康概念和标准演变从病态和异常程度来界定心理健康:没有心理问题或者心理疾病属于心理健康,有了心理疾病就属不健康。

在20世纪30、40年代,精神分析、行为主义等做了大量有关心理疾病和心理问题产生机制和文化影响机制的研究,心理健康状况的诊断和判别的测量学构想主要来源于对焦虑、孤独、强迫等精神和行为症状的精神分析和行为主义以及消极认知的有关研究,其中的抑郁测量表、SCL-90症状自评量表、焦虑量表成为观测心理健康状况的重要工具。

对心理疾病的预防和治疗,成为心理健康研究关注的主要内容。

但是,这并非唯一的心理健康看法。

从人的功能实现角度来界定心理健康:心理健康成为一种实现、展现状态,个体心理在本身环境条件许可范围内所能够达到的最佳功能状态,而不是十全十美的绝对状态[1];身体、智能及情感上与他人的心理健康不相矛盾的范围内,将个人心境发展成最佳状杰[2]。

《软件工程学》第8章 维护-习题

《软件工程学》第8章 维护-习题

1.软件生命周期的()工作与软件可维护性有着密切的关系。

A.编码阶段B.设计阶段C.测试阶段D.每个阶段
2.软件维护的四类维护活动是:()
A.改正性维护,适应性维护,完善性维护和预防性维护。

B.适应性维护,完善性维护,抢救性维护和辅助性维护。

C.改正性维护,适应性维护,完善性维护和辅助性维护。

D.适应性维护,完善性维护,抢救性维护和预防性维护。

3.一个软件产品开发完成投入使用后,常常由于各种原因需要对它做适当的变更,通常把软件交付使用后所做的变更称为()
A.维护B.设计C.软件再工程D.逆向工程
4.维护的副作用可分三类,不包括()。

A.代码副作用B.数据副作用C.文档副作用D.人员副作用5.在整个软件维护阶段所花费的全部工作中,()所占的比例最大。

A.改正性维护B.适应性维护C.完善性维护D.预防性维护6.在软件维护的实施过程中,为了正确、有效地修改,需要经历以下三个步骤:分析和理解程序、修改程序和重新验证程序。

()是决定维护成败和质量好坏的关键。

A.分析和理解程序B.重新验证程序C.修改程序D.验收程序
7.人们称在软件运行/维护阶段对软件产品所进行的修改就是维护。

()是由于开发时测试的不彻底、不完全造成的。

A.改正性维护B.适应性维护C.完善性维护D.预防性维护8.黑盒测试法可有效的检查模块的内部逻辑结构的正确性。

……………………()9.在进行需求分析时同时考虑维护问题。

……………………()
10.尽可能在软件开发过程中保证各阶段文档的正确性。

……………………()。

软件工程课件-第八章维护ppt

软件工程课件-第八章维护ppt
例如,在软件交付用户使用之后,解决在开发时没有测 试所有可能的执行通路而带来的问题;
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步,大约每 过38个月就有新一代的硬件宣告出现;另一方面,应用软 件的使用寿命却很容易超过十年,远远长于最初开发这个 软件时的运行环境的寿命。因此,适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动,是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性,或为了给未来的 改进工作奠定更好的基础而修改软件时,就出现了第四类维 护活动,这类维护活动称为预防性维护。通常,把预防性维 护定义为:“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说,预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分,主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织,但是,即使对
于一个小的软件开发团体而言,非正式地委托责任也是绝 对必要的。维护机构成员一般包括:配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价,见下页图示。
维护机构
维护要求 (软件问题报告)
● 当必须把软件工程师调去从事维护工作时,将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题,都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划,几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题:
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊

第八章 维护保养与维修——第九节 外围部分常见故障(自动换刀 液压 气动 冷却)

第八章 维护保养与维修——第九节 外围部分常见故障(自动换刀 液压 气动 冷却)
三、刀架、刀库及换刀装置故障诊断 刀架、

转塔刀架没有抬起动作
控制系统是否有T指令输出信号 控制系统是否有 指令输出信号 抬起电磁铁断线或抬起阀杆卡死 压力不够 抬起液压缸研损或密封损坏 与转塔抬起联接的机械部分研损

转塔转位速度缓慢或不转位
是否有转位信号输出 转位电磁阀断线或阀杆卡死 压力不够 转位速度节流阀是否卡死 凸轮轴压盖过紧 抬起液压缸体与转塔平面产生摩擦、 抬起液压缸体与转塔平面产生摩擦、研损 安装附具不配套

刀具不能夹紧
风泵气压不足 增压漏气 刀具卡紧液压缸漏油 刀具松卡弹簧上的螺丝母松动
♦ ♦
刀具夹紧后不能松开
松锁刀的弹簧压力过紧
刀套不能夹紧刀具
检查刀套上的调节螺母
三、刀架、刀库及换刀装置故障诊断 刀架、
♦ ♦
机械手换刀速度过快
气码用组合行程开关、接近开关等元件损坏、 刀位编码用组合行程开关、接近开关等元件损坏、接触不好或灵敏 度降低

转塔转位不停
两计数开关不同时计数或复置开关损坏 转塔上的24V电源断线 转塔上的 电源断线
三、刀架、刀库及换刀装置故障诊断 刀架、

转塔刀重复定位精度差
液压夹紧力不足 上下牙盘受冲击, 上下牙盘受冲击,定位松动 上下牙盘间有污物或滚针脱落在牙盘中间 转塔落下夹紧时有机械干涉(如夹铁屑) 转塔落下夹紧时有机械干涉(如夹铁屑) 夹紧液压缸拉毛或研损 转塔座落在二层滑板之上, 转塔座落在二层滑板之上,由于压板和楔铁配合不牢产生运动偏大
四、液压传动系统故障诊断

液压泵不供油或油量不足
压力调节弹簧过松 流量调节螺钉调节不当, 流量调节螺钉调节不当,定子偏心方向相反 液压泵转向相反 油的粘度过高, 油的粘度过高,使叶片运动不灵活 液压泵转速太低, 液压泵转速太低,叶片不能甩出 油量不足, 油量不足,吸油管露出油面吸入空气 吸油管堵塞 进油口漏气 叶片在转子槽内卡死

电工手册 第八章 高压电器运行与维护

电工手册 第八章 高压电器运行与维护

第8张高压电器运行与维护8.1油断路运行与维护断路器有很强的灭弧能力,能切断负载电流和短路电流。

由于断路本身的缺陷或对断路器的使用不当,都可能造成事故,严重的断路器爆炸。

8.1.1合闸送电前的检查(1)在合闸送电前要收回发出的所有工作票,拆除临时接地线,并全面检查断路器。

(2)检查断路器两侧隔离开关是否都处于断开位置。

(3)使用1000~2000V兆欧表测量断路器的绝缘电阻,电阻应符合规程规定值。

(4)断路器的三相均片在断开位置,油位、油包都应正常,并无渗漏油现象。

(5)分、合闸指示器处在“分”的位置。

(6)操作机构要优质清洁、完整,搬运跳闸脱扣机构应动作灵活。

(7)检查断路器的继电保护及自动装置是否在投入状态,以便发生情况时切除故障。

(8)仔细检查,确认无误后,应对断路进行一次分、合闸试验,如动作准确灵活,方可投入运行。

8.1.2送电操作步骤(1)根据分、合闸指示器的指示,确认断路器的牌断开状态。

(2)装上合闸熔断器和操作熔断器。

(3)在未装操作熔断器的情况下,先合上电源侧隔离开关,再合上负荷侧隔离开关。

(4)核对断路器名称和编号无误后,将操作手柄顺时针方向旋转90°至“预备合闸”位置。

(5)待绿灯指示灯闪光,将操作手柄顺时针方向旋转45°至“合闸”位置,在手脱离操作手柄后,使手柄自动逆时针返回45°,这时绿灯熄灭,红灯亮,表明断路器已合闸送电。

8.1.3停电操作步骤(1)核对断路器的名称和编号无误后,将操作手柄逆时针方向旋转90°至“预备分闸”位置。

(2)待红灯闪光,将操作手柄顺时针方向旋转45°至“分闸”位置,在手脱离操作手柄后,使手柄自动顺时针返回45°,这时红灯熄灭,绿灯亮,表明断路器已断开。

(3)取下合闸熔断器和操作熔断器。

(4)根据分、合指示器,确认断路器已处于断开位置。

(5)先拉负荷侧隔离开关,后拉电源侧隔离开关。

8.1.4操作时注意事项(1)拉、合操作时,动作要果断、迅速,把操作手柄扳至终点位置,使手柄从上到下要连续运动,确定断路器断开后方可拉相应的隔离开关。

软件工程 第八章维护

软件工程 第八章维护

8.1软件维护的定义 8.1软件维护的定义
所谓软件维护就是在软件已经交付使用之 后,为了改正错误或满足新的需要而修改软 件的过程。 件的过程。 维护的类型有四种: 维护的类型有四种: 改正性维护 适应性维护 完善性维护 预防性维护
改正性维护
在软件交付使用后, 在软件交付使用后,因开发时测试 不彻底、不完全, 的不彻底、不完全,必然会有部分 隐藏的错误遗留到运行阶段。 隐藏的错误遗留到运行阶段。 这些隐藏下来的错误在某些特定的 这些隐藏下来的错误在某些特定的 使用环境下就会暴露出来。 使用环境下就会暴露出来。 为了识别和纠正软件错误 识别和纠正软件错误、 为了识别和纠正软件错误、改正软 件性能上的缺陷, 件性能上的缺陷,而进行诊断和改 正错误的过程就叫做改正性维护。 正错误的过程就叫做改正性维护。
维护工作量的模型
M = p + Ke
c −d
M是维护中消耗的总工作量 p是上面描述的生产性工作量 K是一个经验常数 c是因缺乏好的设计和文档而
导致复杂性的度量 是对软件熟悉程度的度量。 d是对软件熟悉程度的度量。
模型指明, 模型指明,如果使用了不好的软件 开发方法(未按软件工程要求做), 开发方法(未按软件工程要求做), 原来参加开发的人员或小组不能参 加维护,则工作量(及成本) 加维护,则工作量(及成本)将按 指数级增加。 指数级增加。
结构化维护 — 指软件开发过程是按照软 件工程方法进行的, 件工程方法进行的 , 开发各阶段的文档齐 软件的维护过程, 全 , 软件的维护过程 , 有一整套完整的方 技术、 审定过程及文档。 案 、 技术 、 审定过程及文档 。 因此易于维 护。
8.2.2 维护的代价高昂 维护的代价高昂 维护阶段是软件生存期中最长的一个阶 段 ,软件维护的工作量占整个软件生存期的 70%以上,而且还在逐年增加。 1970年用于 70%以上,而且还在逐年增加。 1970年用于 维护已有软件的费用只占软件总预算的35 35% 维护已有软件的费用只占软件总预算的35%~ 40% 1980年上升为 40% 60% 1990年上升 年上升为40 40% , 1980 年上升为 40% ~ 60% , 1990 年上升 70% 80% 为70%~80%。 因此,如 降低软 件维护的成本, 件维护的成本, 就成为提高软件维护效率和 质量的关键。 质量的关键。
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

题清单。
质量测试与质量标准则用于定量分析和评价程序的质量。由于 许多质量特性是相互抵触的,要考虑几种不同的度量标准去度量
不同的质量特性。
问题六:如何提高软件的可维护性?
• (1)建立明确的软件质量目标:
如果要程序满足可维护性七个特性的全部要求,那么要付出很 大的代价,甚至是不现实的,但有些可维护性是相互促进的,因 此要明确软件所追求的质量目标。 • (2.)使用先进的软件开发技术和工具: 利用先进的软件开发技术能大大提高软件质量和减少软件费用。 面向对象的软件开发方法就是一个非常实用而强有力的软件开发 方法,用面向对象方法开发出来的软件系统,稳定性好,比较容 易修改,比较容易理解,易于测试和调试,因此,可维护性 好。
• 代码副作用有时可通过回归测试发现,此时应立即采取补救措施。
然而,有时直到交 i付运行后才暴露出来,故对代码进行上述修 改应特别慎重。
• • •
• • • • • • •
数据副作用 在维护阶段一一旦修改了数据结构’软件设计与数据可能就 不再匹配'错误随即出现数据副作用是指因修改软件的信息结构 而带来的不良后果。容易引起数据副作用的傅包括: (1)局部或全局常量的再定义; (2)记录或文件格式的再定义; (3)增减数据或其他复杂数据结构的体积; (4)修改全局数据; (5)重新初始化控制标志和指针; (6)重新排列I/()表或子程序参数表。 设计文档化有助于限制数据副作用,因为设计文档中详细地描述 了数据结构并提一个交叉访问表,把数据和引用它们的模块对应 起来。
语句覆盖
A=3,B=0
路径:sacbde
判定覆盖
• A=4,B=0 • 路径:sabde
• A=2,B=2
• 路径:sacbe
条件覆盖
• A=3,A!=3,B>1,B<=1
• A>2,
A<=2,B=0,B!=0 • A=3,B=0 • 路径: sacbde • (A=3,B<=1,A>2,B=0) • A=2,B=2 路径:sabe • (A!=3,B>1,A<=2,B!=0)

• (3)建立明确的质量保证:
质量保证是指为提高软件质量所做的各种检查工作。质量保证 检查是非常有效的方法,不仅在软件开发的各阶段中得到了广泛 应用,而且在软件维护中也是一个非常主要的工具。为了保证可 维护性,以下四类检查是非常有用的: (1)在检查点进行检查。 (2)验收检查。 (3)周期性的维护 检查。 (4)对软件包的检查。 (4).选择可维护的语言: 程序设计语言的选择对维护影响很大。低级语言很难掌握,很 难理解,因而很难维护。一般来说,高级语言比低级语言更容易 理解,第四代语言更容易理解,容易编程,程序容易修改,改进 了可维护性。 (5).改进程序的文档: 程序文档是对程序功能、程序各组成部分之间的关系、程序设 计策略、程序实现过程的历史数据等的说明和补充。程序文档对 提高程序的可阅读性有重要作用。为了维护程序,人们必须阅读 和理解程序文档。
• 2.适应性维护
适应性维护是指使用软件适应信息技术变化和管理需 求变化而进行的修改。这方面的维护工作量占整个维护工作 量的18%~25%。由于计算机硬件价格的不断下降,各类系 统软件屡出不穷,人们常常为改善系统硬件环境和运行环境 而产生系统更新换代的需求;企业的外部市场环境和管理需求 的不断变化也使得各级管理人员不断提出新的信息需求。这 些因素都将导致适应性维护工作的产生。进行这方面的维护 工作也要像系统开发一样,有计划、有步骤地进行。
• 4.预防性维护为了改进应用软件的可靠性和可维护性,为
了适应未来的软硬件环境的变化,应主动增加预防性的新 的功能,以使应用系统适应各类变化而不被淘汰。例如将 专用报表功能改成通用报表生成功能,以适应将来报表格 式的变化。这方面的维护工作量占整个维护工作量的4%左 右。
问题二:非结构化维护和结构化维护的主 要区别是什么?
问题四:什么叫软可维护性?它主要由哪 些因素决定?
• 软件可维护性即维护人员对该软件进行维护的难易程度,具体包 • • • • • • • • • • • •
括理解、改正、改动和改进该软件的难易程度。 决定可维护性的因素: 1.系统的大小 2.系统的年龄 3.结构合理性 可维护性可通过7个质量特性来衡量: 可理解性 可测试性 可修改性 可靠性 可移植性 可使用性 效率
软件维护类型:
1.改正性维护折叠编辑本段 改正性维护是指改正在系统开发阶段已发生而系统测 试阶段尚未发现的错误。这方面的维护工作量要占整个维护 工作量的17%~21%。所发现的错误有的不太重要,不影响 系统的正常运行,其维护工作可随时进行:而有的错误非常重 要,甚至影响整个系统的正常运行,其维护工作必须制定计 划,进行修改,并且要进行复查和控制。
问题五:.如何度量软件的可维护性?
目前有若干对软件可维护性进行综合度量的方法,但要对可 维护性作出定量度量还是困难的。还没有一种方法能够使用计算 机对软件的可维护性进行综合性的定量评价。 下面是度量一个可维护的软件的七种特性时常采用的方法,即 质量检查表、质量测试、质量标准。 质量检查表是用于测试程序中某些质量特性是否存在的一个问
问题三:软件维护有哪些副作用?
• 软件修改是一项很危险的工作,对一个复杂的逻辑过程,仅仅做
• • • • • • • • • •
一项微小的改动都可能引入潜在的错误。虽然设计文档化和细致 的回归测试有助于排除错误,但是维护仍然会产生副作用。软件 维护的副作用是指由于维护或在文档化过程中其他一些不期望的 行为引入的错误。副作用大致可分为三类: 代码副作用 虽然每次代码修改都可能引入潜在的错误,但是下列修改最 易出错: (l)修改或删除子程序; (2)修改或删除语句标号; (3)修改或删除标识符; (4)为提高执行效率而做的修改; (5)修改文件的open.close操作; (6)修改逻辑操作符; (7)由设计变动引起的代码修改; (8)修改对边界条件的测试。
第八章
——维护
问题一:什么是软件维护?它有哪几种类型?
• 定义:
软件维护(Software maintenance)是一个软件工 程名词,是指在软件产品发布后,因修正错误、提升性能或 其他属性而进行的软件修改。 软件维护主要是指根据需求变化或硬件环境的写《程序修改登记表》,并在《程序变更通知书》 上写明新旧程序的不同之处。
判定/条件覆盖
• A=3,B=0
• 路径:sacbde
• A=2,B=2
• 路径:sabe
条件组合覆盖
• (1)和(6) • (1)A=3,B>1 • (2)A=3,B<=1 • (3)A!=3,B>1 • (4)A!=3,B<=1 • (5)A>2,B=0 • (6)A>2,B!=0 • (7)A<=2,B=0 • (8)A<=2,B!=0 • A=3,B=2 • 路径:sacbe • (2)和(5) • A=3,B=0 • 路径:sacbde • (3)和(8)
• A=2,B=2
• 路径:sacbe • (4)和(7) • A=2,B=0
• 路径:sabde
• 3.完善性维护是为扩充功能和改善性能而进行的修改,主
要是指对已有的软件系统增加一些在系统分析和设计阶段 中没有规定的功能与性能特征。这些功能对完善系统功能 是非常必要的。另外,还包括对处理效率和编写程序的改 进,这方面的维护占整个维护工作的50%~60%,比重较 大.也是关系到系统开发质量的重要方面。这方面的维护除 了要有计划、有步骤地完成外.还要注意将相关的文档资料 加入到前面相应的文档中去。
• 区别是:软件生命周期、软件配臵的完整性 • 1.非结构化
在非结构化的系统中,每个节点存储自身的信息或信息的 索引(如指针和IP地址)。当用户需要在P2P系统中获取信息时, 他们预先并不知道这些信息 (如某个文件)会在那个节点上存储。 因此,在非结构化P2P系统中,信息搜索的算法难免带有一定的 盲目性,例如最简单的泛洪式查找(类似于广播)和扩展环查找(从 最近的n个节点开始,层层转发直到找到目标或超出了跳数的上 限为止)。 2.结构化 P2P网络中的节点是有固定结构的,每个节点只存储特定的 信息或特定信息的索引。当用户需要在P2P系统中获取信息时, 他们必须知道这些信息(或索引)可能存在于那些节点中。 用户预先知道应该搜索哪些节点,避免了非结构化P2P系统 中使用的泛洪式查找,因此提高了信息搜索的效率。
相关文档
最新文档