软件维护(Software Maintenance)英文_图文.ppt
软件维护
—— 亦称 Software Evolution
1.软件维护的概念 2.维护的特点 3.维护的过程 4.可维护性 5.软件再工程过程
2018年7月2日星期一
计算机科学与工程学院
1
6.8.软件系统维护的基本概念
1.软件维护定义：
是指在软件系统已经交付使用之后，软件使用人员为了 适应新的要求、满足新的需要或为了改正软件中存在的错误 而对软件系统进行修改的过程。
2018年7月2日星期一 计算机科学与工程学院
8
维护工作量的经验模型：
M＝P＋K×exp（c－d） 其中： M是维护用的总工作量； P是生产性工作量； K是经验常数； c是复杂程度（非结构化设计和缺少文档都会增加软件 的复杂程度）； d是维护人员对软件的熟悉程度。
上面的模型表明，如果软件的开发途径不好（即，没 有使用软件工程方法学），而且原来的开发人员不能参加 维护工作，那么维护工作量（和费用）将指数地增加。
2018年7月2日星期一 计算机科学与工程学院 17
⑴ 可理解性(Understandability) 指由文档代码理解功能运行的容易程度。对外又称 user friendliness. 好程序的特征：模块化、结构化、代码与设计风格一致， 高级语言实现。 度量方法：90 - 10 Test ——读源程序10分钟，能否默写 出90%？ ⑵可测试性(Testability) 是指论证程序正确性的容易程度。 好程序的特征：可理解、可靠、简单。 度量方法：程序复杂度（第五章中已讨论）
文档：开发文档 和测试文档
缺乏文档 不能进行回归测试
原因：没有使用良好定义的方法学开发出来。 回归测试：为了保证所做的修改没有在以前可以正常使用的软件 功能中引入错误而重复过去做过的测试。
CH8 维护.ppt
与MRF相应的内部文件，要求说明： ①所需修改变动的性质； ②申请修改的优先级； ③为满足某个维护申请报告，所需的工作量； ④预计修改后的状况。
3、维护的事件流
§3. 维护过程
用户
类型
估计 严重 错误严重
程度
分析 问题
完
适
善
应
计划 改正 进度
§1. 定义
③为了增加新功能，修改已有功能，改造界面， 增加HELP等，而修改软件 —— 完善性维护 （perfective maintenance),约占全部维护活动 的50~66% ；
④为了改进未来的可维护性或可靠性，或为了给 未来的改进奠定更好的基础而修改软件 —— 预防性维护(preventive maintenance)，与其它 维护活动共占总维护的4%左右。
其中：M = 维护用的总工作量;
P = 生产性工作量 (e.g. 分析, 评估, 设计, 编码, and 测 试);
K = 经验常数 ;
c = 复杂度 ( 主要来自缺乏结构化设计和必要的文档)
d = 维护人员对软件的熟悉程度.
3、维护的问题
§2. 维护的特点
说明性文档不可缺少!
•别人的程序很难读懂
③使用手册 —— 说明使用方法以及错误挽救方法；
④参考手册 —— 详尽描述用户可使用的所有系统设
施以及它们的使用方法；给出错误 信息注解表； ⑤操作员指南（如果需要有系统操作员的话）—— 说明操作员处理使用中出现的各种情况的方法。
⑵系统文档：即软件生产过程中每一步产生的文档。
3、复审 各阶段复审重点：
任是十分必要的，这样可以大大减少维 护过程中可能出现的混乱
软件维护PPT课件
• 系统管理员对维护任务做出评价之后，由变化授
权人决定应该进行的活动。
16
2. 维护报告
• 应该用标准化的格式表达所有软件维护 申请（要求）。
• 维护申请报告或称软件问题报告，由申 请维护的用户填写。
• 用户必须完整地说明产生错误的情况， 包括输入数据、错误清单以及其它有关 材料。
• 如果申请的是适应性维护或完善性维护， 用户必须提出一份修改说明书，列出所 有希望的修改。
第9章 软件维护
1
第9章 软件维护
9.1 软件维护的定义
软件维护 ---- 就是在软件已经交付使用之后，
为了改正错误或满足新的需要而修改软件的过 程。
维护的类型有四种： 改正性维护 适应性维护 扩充与完善性维护 预防性维护
2
1.改正性维护 --- Corrective Maintenance
• 在软件交付使用后，因开发时测试的不 彻底、不完全，必然会有部分隐藏的错 误遗留到运行阶段。
13
9.3 软件维护过程
• 维护过程本质上是修改和压缩了的软件定义和开 发过程，而且事实上远在提出一项维护要求之前，
与软件维护有关的工作已经开始了。 • 为了有效地进行软件维护，应事先就开始做组织
工作。 – 首先建立维护的机构 – 申明提出维护申请报告的过程及评价的过程 – 为每一个维护申请规定标准的处理步骤 – 建立维护活动的记录保管，并规定复审的标准
17
• 维护申请报告将由维护管理员和系统管理员 来研究处理。
• 他们应相应地做出软件修改报告，指明： – 所需修改变动的性质； – 申请修改的优先级； – 为满足某个维护申请报告，所需的工作量 – 预计修改后的状况.
数据输入/输出方式、数据存储介 质） 可能发生变化。
软件工程软件维护(“软件维护”相关文档)共6张
就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。 其宗旨就是提高客户对软件产品的满意度。 其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。
Software Engineering
软件工程
❖ 第七章 软件测试
软件维护概述
❖ 软件维护
▪ 就是软件交付使用之后，在新版本产品升级之前这 段时间里，软件厂商向客户提供的服务工作。
❖ 意义
▪ 其宗旨就是提高客户对软件产品的满意度。 ▪ 保持现有系统的价值
其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。 其宗旨就是提高客户对软件产品的满意度。 其宗旨就是提高客户对软件产品的满意度。 其宗旨就是提高客户对软件产品的满意度。 就是软件交付使用之后，在新版本产品升级之前这段时间里，软件厂商向客户提供的服务工作。 其宗旨就是提高客户对软件产品的满意度。
软件维护(Software Maintenance)英文
L-type found most often
24 SE, Maintenance, Hans van Vliet, ©2008
Advantages of L-type departmentalization
Clear accountability Development progress not hindered by unexpected maintenance requests Better acceptance test by maintenance department Higher QoS by maintenance department
20
SE, Maintenance, Hans van Vliet, ©2008
Analyzing software evolution data
Version-centered analysis: study differences between successive versions History-centered analysis: study evolution from a certain viewpoint (e.g. how often components are changed together)
17
SE, Maintenance, Hans van Vliet, ©2008
Categories of bad smells
Bloaters: something has grown too large Object-oriented abusers: OO not fully exploited Change preventers: hinder further evolution Dispensables: can be removed Encapsulators: deal with data communication Couplers: coupling too high
第7章软件维护
适应性维护 --- Adaptive Maintenance
• 在使用过程中， – 外部环境（新的硬、软件配置） – 数据环境（数据库、数据格式、 数据输入/输出方式、数据存储介 质）
可能发生变化。
• 为使软件适应这种变化，而去修改 软件的过程就叫做适应性维护。
我们仔细说明软件或开发人员已经不在附近了。 4）绝大多数软件在设计时没有考虑将来的修改。 5）软件维护不是一项吸引人的工作，形成这种观念很
大程度上是因为维护工作经常遭受挫折。
2．维护的代价高昂
在过去的几十年中，软件维护的费用稳步上升。软件维护 成本是软件开发成本的四倍左右。维护费用只不过是软件维 护的最明显的代价，但还有一些无形的代价：
7.4.3 可维护性复审
• 在软件工程过程的每一个阶段都应该考虑并努力提 高软件的可维护性，在每个阶段结束前的技术审查
和管理复审中，应该着重对可维护性进行复审。
• 在完成了每项维护工作之后，都应该对软件维护本身进行 仔细认真的复审。
--- 维护应该针对整个软件配置，不应该只修改源程序代码。
当对源程序代码的修改没有反映在设计文档或用户手册中 时，就会产生严重的后果。
18%～ 25%
其它维护 4 %
扩充及完善性维护
50% ～ 60%
7.2 软件维护的特点
1．维护过程存在的问题多 1）理解别人写的程序通常非常困难，而且困难程度随
着软件配置成分的减少而迅速增加。 2）需要维护的软件往往没有合格的文档，或者文档资
料显著不足。 3）当要求对软件进行维护时，不能指望由开发人员给
7.6 软件再工程过程（Software Reengineering）
软件工程课件-第八章维护ppt
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步，大约每 过38个月就有新一代的硬件宣告出现；另一方面，应用软 件的使用寿命却很容易超过十年，远远长于最初开发这个 软件时的运行环境的寿命。因此，适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动，是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性，或为了给未来的 改进工作奠定更好的基础而修改软件时，就出现了第四类维 护活动，这类维护活动称为预防性维护。通常，把预防性维 护定义为：“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说，预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分，主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织，但是，即使对
于一个小的软件开发团体而言，非正式地委托责任也是绝 对必要的。维护机构成员一般包括：配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价，见下页图示。
维护机构
维护要求 （软件问题报告）
● 当必须把软件工程师调去从事维护工作时，将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题，都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划，几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题：
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
软件工程阅读之软件维护（中英文对照）
SOFTWARE MAINTENANCE The term“software maintenance”is used to describe the software engineering activities that occur following delivery of a software product to the customer．The maintenance phase of the software life cycle is the time period in which a software product performs useful work．Typically，the development cycle for a software product spans 1 or 2 years，while the maintenance phase spans 5 to 10 years． Maintenance activities involve making enhancements[1] to software products，adapting products to new environments，and correcting problems．Software product enhancement may involve providing new functional capabilities，improving user displays and modes of interaction，upgrading external documents and internal documentation，or upgrading the performance characteristics of a system．Adaptation of software to a new environment may involve moving the software to a different machine，or for instance，modifying the software to accommodate a new telecommunications protocol or an additional disk drive．Problem correction involves modification and revalidation of software to correct errors．Some errors require immediate attention，some can be corrected on a scheduled，periodic[2]basis，and others are known but never corrected． It is well established that maintenance activities consume a large portion of the total life-cycle budget[3]．It is not uncommon for software maintenance to account for 70 percent of total software life-cycle costs（with development requiring 30 percent）．As a general rule of thumb[4]，the distribution of effort for software maintenance includes 60 percent of the maintenance budget for enhancement，and 20 percent each for adaptation and correction． If maintenance consumes 70 percent of the total life-cycle effort devoted to a particular software product，and if 60 percent of maintenance goes to enhancing the product，then 42 percent of the total life-cycle effort for that product is dedicated to product enhancement．Given this perspective，it is apparent that the product delivered to the customer at the end of the development cycle is only the initial version of the system．Some authors have suggested that the appropriate life-cycle model for software is development→evolution→evolution→evolution… This perspective makes it apparent that the primary goal of software development should be production of maintainable software systems．Maintainability，like all high-level quality attributes，can be expressed in terms of attributes that are built into[5] the product．The primary product attributes that contribute to software maintainability are clarity，modularity，and good internal documentation of the source code，as well as appropriate supporting documents．It should also be observed that software maintenance is a microcosm [6] of the software development cycle．Enhancement and adaptation of software reinitiate development in the analysis phase，while correction of a software problem may reinitiate the development cycle in the analysis phase，the design phase，or the implementation phase[7]．Thus，all of the tools and techniques used to develop software are potentially useful for software maintenance． Analysis activities during software maintenance involve understanding the scope and effect of a desired change，as well as the constraints on making the change．Design during maintenance involves redesigning the product to incorporate the desired changes．The changes must then be implemented，internal documentation of the code must be updated，and new test cases must be designed to assess the adequacy of the modification．Also，the supportingdocuments（requirements，design specifications，test plan，principles of operation，user’s manual，crossreference directories，etc.）must be updated to reflect the changes．Updated versions of the software（code and supporting documents）must then be distributed to various customer sites，and configuration control records for each site must be updated． All of these tasks must be accomplished using a systematic，orderly approach to tracking and analysis of change requests，and careful redesign，reimplementation，revalidation，and redocumentation of the changes．Otherwise，the software product will quickly degrade as a result of the maintenance process．It is not unusual for a well designed，properly implemented，and adequately documented initial version of a software product to become unmaintainable due to inadequate maintenance procedures．This can result in situations in which it becomes easier and less expensive to reimplement a module or subsystem than to modify the existing version．Software maintenance activities must not destroy the maintainability of software．A small change in the source code often requires extensive changes to the test suite and the supporting documents．Failure to recognize the true cost of a“small change”in the source code is one of the most significant problems in software maintenance．NOTES [1] enhancement：增强。
软件维护 PPT
100W优质文档免费下 载
VIP有效期内的用户可以免费下载VIP免费文档，不消耗下载特权，非会员用户需要消耗下载券/积分获取。
部分付费文档八折起 VIP用户在购买精选付费文档时可享受8折优惠，省上加省；参与折扣的付费文档均会在阅读页标识出折扣价格。
VIP专享文档下载特权自VIP生效起每月发放一次， 每次发放的特权有效期为1个月，发放数量由您购买 的VIP类型决定。
每月专享9次VIP专享文档下载特权， 自VIP生效起每月发放一次，持续有 效不清零。自动续费，前往我的账号 -我的设置随时取消。
服务特 权
共享文档下载特权
VIP用户有效期内可使用共享文档下载特权下载任意下载券标价的文档（不含付费文档和VIP专享文档），每下载一篇共享文
档消耗一个共享文档下载特权。
年VIP
月VIP
连续包月VIP
享受100次共享文档下载特权，一次 发放，全年内有效
赠每的送次VI的发P类共放型的享决特文定权档。有下效载期特为权1自个V月IP，生发效放起数每量月由发您放购一买次，赠 V不 我I送 清 的P生每 零 设效月 。 置起1自 随5每动 时次月续 取共发费 消享放， 。文一前档次往下，我载持的特续账权有号，效-自
9.3.5 维护评价
一般来说，可以从以下七个方面来评价维护工 作：
（1）每次程序运行时的平均出错次数； （2）用于每一类维护活动的总“人时”数； （3）每个程序、每种语言、每种维护类型所做 的平均修改数； （4）维护过程中，增加或删除每条源程序语句 花费的平均“人时”数； （5）用于每种语言的平均“人时”数； （6）一张维护申请报告的平均处理时间； 买的VIP时长期间，下载特权不清零。
100W优质文档免费下 载