龙教版信息技术九年级下册 第二课 软件系统维护课件（共31张ppt）

课件31张PPT。1.软件维护的概念
2.维护的特点
3.维护的过程
4.可维护性
5.软件再工程过程2019年12月30日星期一1维 护(Maintenance)—— 亦称 Software Evolution2.软件系统维护分为以下四类：
① 诊断和改正错误 —— 改正性维护(corrective maintenance),约占全部维护活动的 17~21%； 2019年12月30日星期一1软件系统维护的基本概念1.软件维护定义：
是指在软件系统已经交付使用之后，软件使用人员为了适应新的要求、满足新的需要或为了改正软件中存在的错误而对软件系统进行修改的过程。 ② 为了 适应变化了的环境（如软硬件升级、新数据库等）而修改软件 —— 适应性维护(adaptive maintenance)，约占全部维护活动的18~25%；1注：① 一般维护的工作量占生存周期70%以上，维护成本约为开发成本的4倍(80 - 20 Rule)；
② 文档维护与代码维护同样重要。 ④为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件 —— 预防性维护(preventive maintenance)，与其它维护活动共占总维护的4%左右。③ 为了增加新功能，修改已有功能，改造界面，增加HELP等，而修改软件 —— 完善性维护（perfective maintenance),约占全部维护活动的50~66% ；13.维护的特点下图描绘了面对一项维护要求时，不同的软件配置所导致的不同工作流程。结构化维护与非结构化维护的对比1(1)、非结构化维护与结构化维护差别悬殊文档：开发文档和测试文档回归测试：为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试。原因：没有使用良好定义的方法学开发出来。1如果有一个完整的软件配置存在:结构化维护，它是在软件开发的早期应用软件工程方法学的结果 在过去的几十年中，软件维护的费用稳步上升。
1970年用于维护已有软件的费用只占软件总预算的35%～40%；
1980年上升为40%～60%；
1990年上升为70%～80%。
有形代价：费用已上升至总预算的80%；
维护费用只不过是软件维护的最明显的代价，还有一些无形代价。
无形代价：
a.可用的资源必须供维护任务使用，以致耽误甚至丧失了开发新软件的良机;
b.当看来合理的有关改错或修改的要求不能及时满足时将引起用户不满；1（2）、维护的代价高昂1c.由于维护时的改动，在软件中引入了潜伏的故障，从而降低了软件的质量；
d.当必须把软件工程师调去从事维护工作时，将在开发过程中造成混乱。软件维护的最后一个代价是生产率的大幅度下降，这种情况在维护旧程序时常常遇到。维护工作的劳动可以分成:
生产性活动，例如，分析评价，修改设计和编写程序代码等;
非生产性活动，例如，理解程序代码的功能，解释数据结构、接口特点和性能限度等。维护工作量的经验模型：1M＝P＋K×exp（c－d）
其中：
M是维护用的总工作量；
P是生产性工作量；
K是经验常数；
c是复杂程度（非结构化设计和缺少文档都会增加软件 的复杂程度）；
d是维护人员对软件的熟悉程度。
上面的模型表明，如果软件的开发途径不好（即，没有使用软件工程方法学），而且原来的开发人员不能参加维护工作，那么维护工作量（和费用）将指数地增加。（3）、维护的问题1别人的程序很难读懂 说明性文档不可缺少!文档与代码不一致开发人员往往不参加维护大多数软件在设计时没有考虑将来的修改上述种种问题在现有的没采用软件工程思想开发出来的软件中，都或多或少地存在着。不应该把一种科学的方法学看做万应灵药，但是，软件工程至少部分地解决了与维护有关的每一个问题。软件维护不是一项吸引人的工作。4. 维护过程1软件维护过程本质：
是修改和压缩了的软件定义和开发过程。
而且事实上远在提出一项维护要求之前，与软件维护有关的工作已经开始了。
首先必须建立一个维护组织；
其次必须确定报告和评价的过程，而且必须为每个维护要求规定一个标准化的事件序列；
最后还应该建立一个适用于维护活动的记录保管过程，并且规定复审标准。（1）、建立维护组织(maintenance team)：
在维护活动开始之前就明确维护责任是十分必要的，这样可以大大减少维护过程中可能出现的混乱。1每个维护要求都通过维护管理员转交给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程序的技术人员。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。（2）、维护报告
应该用标准化的格式表达所有软件维护要求。
⑴ 维护申请报告(Maintenance Request Form)
由用户填写的外部文件，提供错误情况说明（输入数据，错误清单等），或修改说明书等。
它是计划维护活动的基础。
软件组织内部应该制定出一个软件修改报告：
⑵ 软件修改报告(Software Change Report)
与MRF相应的内部文件，要求说明：
①所需修改变动的性质；
②申请修改的优先级；
③为满足某个维护申请报告，所需的工作量；
④预计修改后的状况。11（3）、维护的事件流下图描绘了由一项维护要求而引出的一串事件。首先应该确定要求进行的维护的类型。用户常常把一项要求看作是为了改正软件的错误（改正性维护），而开发人员可能把同一项要求看作是适应性或完善性维护。当存在不同意见时必须协商解决。1（4） 、保存维护记录
对于软件生命周期的所有阶段而言，以前记录保存都是不充分的，而软件维护则根本没有记录保存下来。由于这个原因，我们往往不能估价维护技术的有效性，不能确定一个产品程序的“优良”程度，而且很难确定维护的实际代价是什么。1（5） 、评价维护活动
如果已经开始保存维护记录了，则可以对维护工作做一些定量度量。至少可以从下述7个方面度量维护工作：
（1）每次程序运行平均失效的次数；
（2）用于每一类维护活动的总人时数；
（3）平均每个程序、每种语言、每种维护类型所做的程序变动数；
（4）维护过程中增加或删除一个源语句平均花费的人时数；
（5）维护每种语言平均花费的人时数；
（6）一张维护要求表的平均周转时间；
（7）不同维护类型所占的百分比。
根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务。5. 可维护性(Maintainability )的度量软件可维护性可以定性地定义为：维护人员理解、改正、改动和改进这个软件的难易程度。
我们一直强调，提高可维护性是支配软件工程方法学所有步骤的关键目标。 1—— 软件度量学(Software Measurement)（1）、决定软件可维护性的因素
维护就是在软件交付使用后进行的修改，修改之前必须理解修改的对象，修改之后应该进行必要的测试，以保证所做的修改是正确的。如果是改正性维护，还必须预先进行调试以确定错误。因此，影响软件可维护性的因素主要有下述五个：
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性⑴ 可理解性(Understandability)
指由文档代码理解功能运行的容易程度。对外又称 user friendliness.
好程序的特征：模块化、结构化、代码与设计风格一致，高级语言实现。
度量方法：90 - 10 Test ——读源程序10分钟，能否默写出90%？
⑵可测试性(Testability)
是指论证程序正确性的容易程度。
好程序的特征：可理解、可靠、简单。
度量方法：程序复杂度（第五章中已讨论）1⑶ 可修改性(Reparability)
是指程序容易修改的程度。
好程序的特征：可理解、简单、通用。
度量方法：1其中：D = 修改难度； A = 要修改的模块的复杂度；
C = 所有模块的平均复杂度。
D ? 1表示修改很困难。(4)可移植性(Portability)
是指程序被移到一个新环境的容易程度。
好程序的特征：结构好，不特别依赖于某一具体的计算机或操作系统。(5) 可重用性1（2）、文档
影响可维护性的决定因素，比代码更重要。总的说来，软件文档应该满足下述要求：
（1）必须描述如何使用这个系统，没有这种描述即使是最简单的系统也无法使用；
（2）必须描述怎样安装和管理这个系统；
（3）必须描述系统需求和设计；
（4）必须描述系统的实现和测试，以便使系统成为可维护的。软件系统的文档可以分为用户文档和系统文档两类。
用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的；
系统文档描述系统设计、实现和测试等各方面的内容。a. 用户文档：
①功能描述 —— 说明系统能做什么； 1②安装文档 —— 说明安装系统的方法及适应特定的硬件配置的方法； ③使用手册 —— 说明使用方法以及错误挽救方法；④参考手册 —— 详尽描述用户可使用的所有系统设施以及它们的使用方法；给出错误信息注解表；⑤操作员指南（如果需要有系统操作员的话）—— 说明操作员处理使用中出现的各种情况的方法。b.系统文档：从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。1分析设计编码测试验收配置
复审可靠性
可移植性
可用性可理解性
可修改性
可测试性可理解性
可修改性
可移植性
效率可靠性
效率完整性
一致性
可理解性各阶段复审重点：（3）、维护性复审 可维护性是所有软件都应该具备的基本特点，必须在开发阶段保证软件具有前面提到的那些可维护因素。在软件工程过程的每一个阶段都应该考虑并努力提高软件的可维护性，在每个阶段结束前的技术审查和管理复审中，应该着重对可维护性进行复审。 16. 软件再工程过程软件再工程范型是一个循环模型。该范型组成部分的每个活动都可能重复进行。下面介绍软件再工程过程模型中的每个活动。?定义:随着技术的飞速发展,原有系统由于缺少文档、非优化设计等问题需要重新开发,即称为再工程.软件再工程通过逆向工程、重构和正向工程几个环节,将现存系统开发成新的系统,是有效利用原有系统的现实可行的方法。 1该目录可能包括以下内容：
● 应用系统的名字；
● 最初构建它的年份；
● 已对它进行过的实质性修改的次数；
● 完成这些修改所花费的总工作量；
● 最后一次实质性修改的日期；
● 最后一次实质性修改所花费的工作量；
● 它驻留的系统；
● 和它有接口的应用系统；
● 它访问的数据库；
● 过去18个月所报告的错误；（1）. 库存目录分析 每个软件组织都应该保存其负责维护的所有应用系统的库存目录。2019年12月30日星期一1● 用户数量；
● 安装此应用系统的机器数量；
● 程序结构复杂程度、代码复杂程度和文档复杂程度；
● 文档的质量；
● 整体可维护性（用等级值表示）；
● 预期寿命（以年计）；
● 在未来36个月内的预期修改次数；
● 年度维护成本；
● 年度运行成本；
● 年度业务值；
● 业务重要程度。收集上面列出的信息。按照业务重要程度、寿命、当前可维护性以及其他重要标准对这些信息排序，选出软件再工程的候选者，然后可以明智地为再工程分配资源。定期地修订刚才描述的库存目录表，应用系统的状况（例如，业务重要程度）可能随着时间而改变，因此，再工程的优先级也将发生变化。2019年12月30日星期一1 缺乏文档或文档严重不合格，是很多老系统的通病。面对这种状况，有下述三种做法可供选择：
（1）选择1——保持现状
建立文档是非常耗费时间的，既然系统能正常工作，就让它保持现状好了。在某些情况下，这是一个正确的做法。如：一个程序是相对静止的，正在走向其有用生命的终点，并且可能不会再经历什么变化，那么，让它保持现状确实是一个明智的选择。
（2）. 文档重构2019年12月30日星期一1（2）选择2——在使用时建文档
文档必须被更新，但是，只有有限的资源，因此将采用“在使用时建文档”的方法。
也就是说，不是一次性地为某个应用系统全部重建文档，而是只为系统中当前正在进行修改的那些部分建立完整的文档。随着时间的流逝，将得到一组有用的文档。（3）选择3——完全地重构文档
该系统对于完成业务工作来说是至关重要的，必须完全地重构文档。即使在这种情况下，明智的办法也是尽量把文档工作减少到必需的最小量。
上述每个选择都是可行的，软件组织必须选用最适合于实际情况的方法。2019年12月30日星期一1逆向工程是通过从特定实现语言的映射而把代码转换为模型的过程。
逆向工程是一个恢复设计结果的过程，逆向工程工具从现存的程序中提取数据、体系结构和处理过程的设计信息。
在绝大多数情况下，被逆向工程的程序不是来自于竞争对手，而是本公司自己的产品（通常是多年以前开发出来的）。（3）. 逆向工程（Reverse Engineering ）2019年12月30日星期一1某些老系统具有相对完整的程序体系结构，但是，编写某些模块代码的方法不正确，使得这些模块难于理解、测试和维护。在这种情况下，可以重构有问题的模块的代码。
要完成代码重构工作：首先用重构工具去分析源代码，标注出和结构化程序设计概念相违背的部分，然后重构这些代码（此项工作可使用软件工具自动进行）。接下来复审和测试所得到的重构代码，以保证没有引入新的错误。最后，更新内部的代码文档。
通常，重构并不修改程序的整体体系结构，它着重关注个体模块的设计细节以及在模块内定义的局部数据结构。如果重构工作扩展到模块边界之外并涉及到程序体系结构，则重构变成了正向工程。（4）. 代码重构2019年12月30日星期一1 与代码重构不同，数据重构发生在比代码重构更高的抽象层次上，它是一种全范围的再工程活动。在绝大多数情况下，数据重构从逆向工程活动开始，仔细分析当前的数据体系结构。必要时定义数据模型，标识数据对象和属性，并且复审现存数据结构的质量。
由于数据体系结构对程序体系结构及程序中的算法有很大影响，对数据的修改必然会导致程序体系结构或代码层的改变。（5）. 数据重构2019年12月30日星期一1 正向过程是通过到实现语言的映射而把模型转换为代码的过程。
正向工程也称为更新或再造，它不仅从现存软件中提取设计信息，而且使用这些信息去修改或重建现存系统，以便提高系统的整体质量。
正向工程过程应用现代的软件工程概念、原理和方法来重新开发现存的某个应用系统。在大多数情况下，经过正向工程过程得到的软件，不仅重新实现了现有系统的功能，而且增加了新功能和（或）提高了整体性能。（6）. 正向工程（forward engineering ）