第八章--维护

合集下载

软件工程导论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.持续集成:将软件的维护工作与开发工作结合起来,通过持续集成的方式,确保软件的质量和稳定性。

  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系统 中使用的泛洪式查找,因此提高了信息搜索的效率。
相关文档
最新文档