第8章软件维护
软件工程课件之第8章维护第6版张海潘编著
用户文档
用户文档至少应该包括下述5方面的内容：
功能描述，说明系统能做什么； 安装文档，说明怎样安装这个系统以及怎样使系统
软件维护过程
维护报告
维护要求表或称软件问题报告表，由申请维 护的用户填写。
软件修改报告，由软件组织内部制定，指明：
满足某个维护要求表中提出的要求所需要的工 作量；
维护要求的性质； 这项要求的优先级； 与修改有关的事后数据；
维护的事件流
维护的事件流
尽管维护申请的类型不同，但都要进行同样 的技术工作：
系统文档
所谓系统文档指从问题定义、需求说明到验收 测试计划这样一系列和系统实现有关的文档。
描述系统设计、实现和测试的文档对于理解程 序和维护程序极端重要
从概貌到每个方面每个特点，从抽象到具体， 有逻辑地介绍系统
可维护性复审
在需求分析阶段的复审过程中，应该对将来要 改进的部分和可能会修改的部分加以注意并指 明；应该讨论软件的可移植性问题，并且考虑 可能影响软件维护的系统界面。
维护的问题
与软件维护有关的绝大多数问题，都可归 因于软件定义和软件开发的方法有缺点：
① 理解别人写的程序通常非常困难，而且困难程 度随着软件配置成分的减少而迅速增加。
② 需要维护的软件往往没有合格的文档，或者文 档资料显著不足。
③ 当要求对软件进行维护时，不能指望由开发人 员给我们仔细说明软件。
的。
软件维护工作量
各类维护工作量 所占比例
维护工作量在软件生 命周期所占比例
第8章 软件维护
系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行 开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现 变得不一致，在维护时就会遇到很大困难。 数据库技术的应用：使用数据库，可以简单而有效 地管理和存储用户程序中的数据，还可以减少生成 用户报表应用软件的维护工作量。
24
8.4
软件的可维护性
许多软件的维护十分困难，原因在于这些软件 的文档不全、质量差、开发过程不注意采用好 的方法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出的， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。 软件可维护性是指纠正软件系统出现的错误和
14
1、维护机构 除了较大的软件开发公司外， 通常在软件维护工作方面，并 不保持一个正式的组织机构。 虽然不要求建立一个正式的维 护机构，但是在开发部门确立 一个非正式的维护机构则是非 常必要的。
15
每个维护要求都通过维护管理员转交给相应的系 统管理员去评价（系统管理员是被指定去熟悉一 小部分产品程序的技术人员）。 系统管理员对维护任务做出评价之后，由变化授 权人决定应该进行的活动。 16
缺陷，以及为满足新的要求进行修改、扩充或 压缩的难易程度。
25
8.4.1 决定软件可维护性的因素
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
26
1. 可理解性 软件可理解性表现为外来读者理解软件的结构、 功能、接口和内部处理过程的难易程度。模块化 （模块结构良好，高内聚，松耦合）、详细的设 计文档、结构化设计、程序内部的文档和良好的 高级程序设计语言等等，都对提高软件的可理解 性有重要贡献。 2. 可测试性 诊断和测试的容易程度取决于软件容易理解的程 度。良好的文档对诊断和测试是至关重要的，此 外，软件结构、可用的测试工具和调试工具，以 及以前设计的测试过程也都是非常重要的。维护 人员应该能够得到在开发阶段用过的测试方案， 以便进行回归测试。在设计阶段应该尽力把软件 设计成容易测试和容易诊断的。 对于程序模块来说，可以用程序复杂度来度量它 的可测试性。模块的环形复杂度越大，可执行的 路径就越多，因此，全面测试它的难度就越高。
软件工程导论课件第8章
5. 数据重构 对数据体系结构差的程序很难进行适应性和 完善性维护，因此，数据体系结构比源代码对程序 的长期生存力有更大影响。 数据重构是一种全范围的再工程活动。由于 数据重构对程序体系结构及程序中的算法有很大影 响，对数据的修改必然会导致程序体系结构或代码 层的改变。
3
2.适应性维护 为适应变化了的环境界面而修改软件的活动， 称为适应性维护。包括： （1）因硬件或支撑软件改变引起的变化； （2）将软件移植到新的机种上运行； （3）因数据环境的变化而做的变更。 这类维护大约占软件维护总工作量的25％。
4
3.完善性维护 为了满足用户要求，就得对软件进行修改和 扩充，我们称这种维护为完善性维护。完善性维护 主要包括： （1）提高处理效率； （2）提高性能。 在整个维护工作中， 完善性维护大约占50％ 左右，区居第一位。
3. 逆向工程 软件的逆向工程是，分析程序以便在比源代码 更高的抽象层次上创建出程序的某种描述的过程， 也就是说，逆向工程是一个恢复设计结果的过程。 4. 代码重构 某些老程序的体系结构比较合理，但是，一些 模块的编码方式却是难于理解、测试和维护的。在 这种情况下，可以重构这些模块的代码。 通常，代码重构并不修改程序的体系结构，它 只关注个体模块的设计细节以及在模块中定义的局 部数据结构。如果重构扩展到模块边界以外并涉及 软件体系结构，则重构变成了正向工程。
13
（四）软件维护过程 维护过程的实质是对软件定义和开发过程的修 改和压缩。维护过程的主要任务是：建立维护机构， 填写维护报告和评价，为每个维护要求规定一种规 范化的处理序列，建立对维护活动的登记制度及规 定评价复审的标准。 1.维护组织 机构中有一名维护管理员总负责，每项维护要 求都通过维护管理员转交给相应的系统管理员去评 价。系统管理员对维护任务做出评价之后，由变化 授权人决定应该进行的活动，最后由系统管理员去 执行维护任务。
软件工程实用教程第三版-郭宁主编-课后习题及答案
软件工程实用教程第三版-郭宁主编-课后习题及答案第一章软件工程引论1.在下列选项中，（D）不是软件的特征。
A．系统性与复制性 B. 可靠性与一致性 C.抽象性与智能型 D.有形性与可控性2.软件是一种（B）产品。
A．有形 B. 逻辑 C. 物质 D. 消耗3.软件工程是一种（A）分阶段实现的软件程序开发方法。
A.自顶向下B. 自底向上C. 逐步求精D. 面向数据流4.与计算机科学的理论研究不同，软件工程是一门（B）学科。
A．理论性 B. 工程性 C. 原理性 D. 心理性5.软件工程与计算机科学性质不同，软件工程着重于（C）。
A．原理探讨 B. 理论研究 C. 建造软件系统D. 原理性的理论6.下列说法正确的是（B）A.软件工程的概念于20世纪50年代提出B.软件工程的概念于20世纪60年代提出C.20世纪70年代出现了客户机/服务器技术D.20世纪80年代软件工程学科达到成熟7.软件工程方法学中的软件工程管理是其中的一个重要内容，它包括软件管理学和软件工程经济学，它要达到的目标是（D）A．管理开发人员，以开发良好的软件B．采用先进的软件开发工具，开发优秀的软件C．消除软件危机，达到软件生产的规模效益D．以基本的社会效益为基础，工程化生产软件第二章软件生命周期及开发模型1.软件生命周期包括可行性分析和项目开发计划、需求分析、总体设计、详细分析、编码、（B）、维护等活动。
A．应用 B. 测试 C. 检测 D. 以上答案都不正确2.软件生命周期模型有多中，下列项目中，（C）不是软件生命周期模型。
A．螺旋模型 B. 增量模型 C. 功能模型 D.瀑布模型3.软件生命周期中时间最长的阶段时（D）A．需求分析阶段 B. 总体设计阶段 C. 测试阶段 D. 维护阶段4.瀑布模型是一种（D）A.软件开发方法B. 软件生存周期C. 程序设计方法学 D. 软件生存周期模型5.软件开发中常采用的结构化生命周期方法，由于其特征而一般称其为（A）A.瀑布模型B. 对象模型C. 螺旋模型D. 层次模型6.在结构化的瀑布模型中，（D）阶段定义的标准将成为软件测试中系统测试阶段的目标A.详细设计阶段B. 总体设计阶段C. 可行性研究阶段 D. 需求分析7.增量模型是一种（B）的模型A.整体开发B. 非整体开发C. 灵活性差D.较晚产生工作软件8.（C）是指模拟某种产品的原始模型A.模型B. 最初模型C. 原型D. 进化模型9.建立原型的目的不同，实现原型的途径也有所不同，下列不正确的类型是（B）A.用于验证软件需求的原型B. 垂直原型C.用于验证设计方案的原型 D.用于演化出目标系统的原型10.原型化方法是一种（A）型的设计过程。
第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 软件维护的基本内容 所谓软件维护就是在软件已经交付使用 之后，为了改正错误或满足新的需要而修改 软件的过程。
软件工程 张海藩 课后习题答案
《软件工程导论》课后习题答案第一章软件工程概论1．什么是软件危机？软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
这些问题表现在以下几个方面：(1)用户对开发出的软件很难满意。
(2)软件产品的质量往往靠不住。
(3)一般软件很难维护。
(4)软件生产效率很低。
(5)软件开发成本越来越大。
(6)软件成本与开发进度难以估计。
(7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。
2．为什么会产生软件危机？(1) 开发人员方面，对软件产品缺乏正确认识，没有真正理解软件产品是一个完整的配置组成。
造成开发中制定计划盲目、编程草率，不考虑维护工作的必要性。
(2) 软件本身方面，对于计算机系统来说，软件是逻辑部件，软件开发过程没有统一的、公认的方法论和规范指导，造成软件维护困难。
(3) 尤其是随着软件规模越来越大,复杂程度越来越高,原有软件开发方式效率不高、质量不能保证、成本过高、研制周期不易估计、维护困难等一系列问题更为突出，技术的发展已经远远不能适应社会需求。
3．怎样克服软件危机？(1) 充分吸收和借鉴人类长期以来从事各种工程项目中积累的行之有效的有效原理、概念、技术与方法，特别是吸取几十年来人类从事计算机硬件研究和开发的经验教训。
在开发软件的过程中努力作到良好的组织，严格的管理，相互友好的协作。
(2) 推广在实践中总结出来的开发软件的成功的技术和方法，并研究更好、更有效的技术和方法，尽快克服在计算机系统早期发展阶段形成的一些错误概念和作法。
(3) 根据不同的应用领域，开发更好的软件工具并使用这些工具。
将软件开发各个阶段使用的软件工具集合成一个整体，形成一个很好的软件开发支环环境。
总之为了解决软件危机，既要有技术措施(方法和工具)，又要有必要的组织管理措施。
4.构成软件项目的最终产品：应用程序、系统程序、面向用户的文档资料和面向开发者的文档资料。
5．什么是软件生存周期？软件生存周期是指从软件定义、开发、使用、维护到淘汰的全过程。
软件工程 第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 结构化维护
存在完整的软件系列文档，那么维护任务就从分析设 计文件开始，确定软件的重要结构特性、功能特性和 接口特性，确定所要求的修改或校正可能产生的影响， 并且计划采用何种维护处理方法，修改设计并进行复 审，编制出新的源程序，利用文档中的信息进行回归 测试，然后重新交付软件。这种维护过程就叫做“结 构化维护”
第8章软件维护
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1）编码副作用：在使用程序设计语言修改源代码时可能引起的错误， 如删除或修改一个标号、标识符、一个子程序，改变程序代码的时序关系， 改变逻辑运算符，改进程序的执行效率，改变程序占用存储的大小等，都 很容易引入错误，应特别小心。 2）数据副作用：在修改数据结构时，有可能造成软件设计和数据结构 的不一致，而导致软件错误。数据副作用是修改软件信息结构引起的，如 重新定义全局或局部常量，重新初始化控制标志或指针等，都容易产生设 计与数据不相容的错误，可通过详细设计文档对数据副作用加以控制。 3）文档副作用：对数据流、软件结构、逻辑模块等进行修改时，必须 对相关技术文档进行修改，否则会导致 文档与程序功能不匹配，使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序：
1）静态确认； 2）计算机确认； 3）维护后的验收。
软件维护步骤
第三步：维护文档整理
记录一些与维护工作有关的数据信息，这些信息 可作为估计软件维护的有效程度，确定软件产品的 质量，确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步：维护活动评价
具体的评价工作可从以下几个方面考虑： （1）每次程序运行时的平均出错次数； （2）花费在每类维护活动上的总的“人时”数； （3）每个程序、每种语言、每种维护类型程序的平均修改次数； （4）维护工作中增加或删除每个源程序语句所花费的平均“人 时”数； （5）用于每种语言的平均“人时”数； （6）维护申请报告的平均处理时间； （7）各类维护申请的百分比。 一方面，可判定此次维护活动开展是否顺利、成功；另一方面， 为今面的维护工作积累经验。
2、结构化维护：进行维护 活动时，首先从评价需求开始，搞清楚 功能、性能上的改变，然后对设计说明文档进行评价、修改和复查； 根据设计的修改，再进行程序的变动；然后根据测试文档中的测试 用例进行回归测试；最后将修改后的软件再次交付使用。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
4．预防性维护
除了以上三类维护之外，还有一类维护活动， 叫做预防性维护。这是为了提高软件的可维 护性、可靠性等，为以后进一步改进软件打 下良好基础。
8.1.2 软件维护的策略
为了控制维护成本，针对以下三种典型的维 护，提出了相应的软件维护策略。 1．改正性维护 2．适应性维护 3．完善性维护
第8章 软件维护
内容介绍
8.1
软件维护过程 8.2 软件可维护性 8.3 小 结
8.1 软件维护过程
8.1.1 8.1.2 8.1.3 8.1.4 8.1.5 软件维护的种类 软件维护的策略 软件维护的过程 软件维护的困难 软件维护的副作用
8.1.1 软件维护的种类
所谓的软件维护，就是在软件运行/维护阶段 对软件产品所进行的修改。 软件维护活动有如下四类 ：
2．适应性维护
Байду номын сангаас
随着计算机飞速发展，外部环境（新的硬、 软件配置）或数据环境（数据库、数据格式、 数据输入/输出方式、数据存储介质）可能发 生变化，为了使软件适应这种变化，而去修 改软件的过程就叫做适应性维护。
3．完善性维护
在软件的使用过程中，用户往往会对软件提 出新的功能与性能要求。为了满足这些要求， 需要修改或再开发软件，以扩充软件功能、 增强软件性能、改进加工效率、提高软件的 可维护性。这种情况下进行的维护活动叫做 完善性维护。
谢谢！
8.1.4 软件维护的困难
软件维护中出现的大部分问题都可归咎于软 件规划和开发方法的缺陷。 软件开发时采用急功近利还是放眼未来的态 度，对软件维护影响极大。 一般说来，软件开发若不严格遵循软件开发 标准，软件维护就会遇到许多困难。
8.1.5 软件维护的副作用
所谓软件维护的副作用，就是指由于修改而 导致的错误或其他多余动作的发生。 下面讨论主要三类的副作用： 1．修改代码的副作用 2．修改数据的副作用 3．修改文档的副作用
8.3 小结
维护是软件生命周期的最后一个阶段，也是 持续时间最长代价最大的一个阶段。 软件工程学的主要目的就是提高软件的可维 护性，降低维护的代价，按照不同的目标， 维护活动可以分为四类：以加强软件功能为 目标的完善性维护；纠正软件遗留错误的改 正性维护；为了适应运行环境变化而进行的 适应性维护；以及为了改进软件的可维护性， 减小将来的维护工作量而进行的预防性维护。
8.2 软件可维护性
8.2.1 决定软件可维护性的因素 8.2.2 提高软件的可维护性
8.2.1 决定软件可维护性的因素
影响软件可维护性的因素主要有如下三个方 面： 1．可理解性 2．可测试性 3．可修改性
8.2.2 提高软件的可维护性
为了提高软件的可维护性，需要从五个这方 面入手。 1．软件的质量目标和优先级 2．提高软件质量的技术和工具 3．质量保证审查 4．程序设计语言 5．软件文档
1. 2. 3. 4. 改正性维护 适应性维护 完善性维护 预防性维护
1．改正性维护
在软件交付使用后，由于开发时测试的不彻 底、不完全，必然会有一部分隐藏的错误被 带到运行阶段来。这些隐藏下来的错误在某 些特定的使用环境下就会暴露。为了识别和 纠正软件错误、改正软件性能上的缺陷、排 除实施中的误使用，应当进行的诊断和改正 错误的过程，就叫做改正性维护。
8.1.3 软件维护的过程
软件维护过程可以看成是一个简化或修改了 的软件开发过程。 典型的软件维护过程可以概括为： 1.建立维护机构； 2.用户提出维护申请并提交维护申请报告； 3.维护人员确认维护类型并实施相应的维护工 作； 4.整理维护记录并对维护工作进行评审； 5.对维护工作进行评价。