第8章软件维护

合集下载

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

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

第8章软件维护

系统年龄： – 老系统随着不断的修改，结构越来越乱； – 维护人员经常更换，程序又变得越来越难于理解 – 许多老系统在当初并未按照软件工程的要求进行开发，因而没有文档，或文档太少。 – 在长期的维护过程中文档在许多地方与程序实现变得不一致，在维护时就会遇到很大困难。数据库技术的应用：使用数据库，可以简单而有效地管理和存储用户程序中的数据，还可以减少生成用户报表应用软件的维护工作量。
24
8.4
软件的可维护性
许多软件的维护十分困难，原因在于这些软件的文档不全、质量差、开发过程不注意采用好的方法，忽视程序设计风格等。许多维护要求并不是因为程序中出错而提出的，而是为适应环境变化或需求变化而提出的。为了使得软件能够易于维护，必须考虑使软件具有可维护性。软件可维护性是指纠正软件系统出现的错误和
14
1、维护机构除了较大的软件开发公司外，通常在软件维护工作方面，并不保持一个正式的组织机构。虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。
15
每个维护要求都通过维护管理员转交给相应的系统管理员去评价（系统管理员是被指定去熟悉一小部分产品程序的技术人员）。系统管理员对维护任务做出评价之后，由变化授权人决定应该进行的活动。 16
缺陷，以及为满足新的要求进行修改、扩充或压缩的难易程度。
25
8.4.1 决定软件可维护性的因素
1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
26
1. 可理解性软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。模块化（模块结构良好，高内聚，松耦合）、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等等，都对提高软件的可理解性有重要贡献。 2. 可测试性诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊断和测试是至关重要的，此外，软件结构、可用的测试工具和调试工具，以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。对于程序模块来说，可以用程序复杂度来度量它的可测试性。模块的环形复杂度越大，可执行的路径就越多，因此，全面测试它的难度就越高。

软件工程导论课件第8章

33
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. 软件工程4. 软件工程过程5. 软件生存周期6. 软件生存周期模型第二章软件可行性研究与项目开发计划1. 投资回收2. 纯收人第三章软件需求分析1. 需求分析2. 数据流3. 数据字典4. 加工5. 数据流图第四章软件概要设计1. 模块2. 模块化3. 抽象4. 信息隐蔽5. 模块独立性6. 耦合性7. 无直接耦合8. 数据耦合9. 标记耦合10. 控制耦合11. 公共耦合12. 内容耦合13. 内聚性14. 偶然内聚15. 逻辑内聚16. 时间内聚17. 通信内聚18. 顺序内聚19. 功能内聚第五章软件详细设计1. PAD2. 过程设计语言(PDL)第六章软件编码1. 程序设计风格2. 程序可移植性第七章软件测试1. 语句覆盖2. 判定覆盖3. 条件覆盖4. 判定/条件覆盖5. 条件组合覆盖6. 路径覆盖7. 环路复杂性8. 黑盒测试9. 白盒测试10. 驱动模块11. 桩模块12. 单元测试13. 集成测试14. 确认测试15. 调试第八章软件维护1. 维护2. 校正性维护3. 适应性维护4. 完善性维护5. 预防性维护6. 软件可维护性第九章软件开发的增量模型1. 原型第十章面向对象的方法1. 对象2. 类3. 消息4. 方法5. 继承性6. 单重继承7. 多重继承8. 多态性9. 抽象10. 信息隐藏11. 链12. 关联第十一章软件质量与质量保证1. 软件可靠性2. 效率3. 可维护性4. 可移植性5. 可互操作性6. 适应性7. 可重用性8. 软件设计质量9. 软件程序质量10. 冗余第十二章软件工程管理1. 软件配置管理2. 软件配置项3. 基线4. 文档第十三章软件开发环境1. 软件开发环境2. 软件工具3. CASE4. CASE生存期5. CASE工作台软件工程自考名词解释答案第一章绪论1. 计算机程序及其说明程序的各种文档.2. 文档是有关计算机程序功能,设计,编制,使用的方案或图形资料.3. 用科学知识和技术原理来定义,开发,维护软件的一门学科.4. 软件工程过程规定了获取,供应,开发,操作和维护软件时,要实施的过程,活动和任务.5. 软件生存周期是指一个软件从得出开发要求开始直到该软件报废为止的整个时期.6. 软件生存周期模型是描述软件开发过程中各种活动如何执行的模型.第二章软件可行性研究与项目开发计划1. 投资回收期就是使累计的经济效益等于最初的投资费用所需的时间.2. 在整个生存周期之内的累计经济效益(折合成现在值)与投资之差.第三章软件需求分析1. 需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非不甘落后将用户非不甘落后需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能规约(需求规格说明)的过程.2. 数据流是数据在系统内传播的路径,因此由一组成分固定的数据项组成.3. 数据字典(Data Dic onary, 简称DD)就是用来定义数据流图中的各个成分的具体含义的,它以一种准确的,无二义性的说明方式为系统的分析,设计及维护提供了有关元素的一致的定义和详细的描述.4. 加工又称为数据处理,是对数据流进行某些操作或变换.5. 数据流图,简称DFD,是SA方法中用于表示系统逻辑模型的一种工具,它以图形的方式描绘数据在系统中流动和处理的过程.第四章软件概要设计1. 模块在程序中是数据说明,可执行语句等程序对象的集合,或者是单独命名和编址的元素,在软件的体系结构中,模块是可组合,分解和更换的单元.2. 模块化是指解决一个复杂问题自顶向下逐层把软件系统划分成若干模块的过程.每个模块完成一个特定的子功能,所有的模块按某种方法组装起来,成为一个整体,完成整个要求的功能.3. 抽象是认识复杂现象过程中使用的思维工具,即抽出事物本质的共同的特性而暂不考虑它的细节,不考虑其他因素.4. 信息隐蔽指在设计和确定模块时,使得一个模块内包含信息(过程或数据),对于不需要这些信息的其他模块来说,是不能访问的.5. 模块独立性指每个模块只完成系统要求的独立的子功能,并且与其他模块的联系最少且接口简单.6. 耦合性也称块间联系.指软件系统结构中各模块间相互联系紧密程序的一种度量.7. 无直接耦合指两个模块之间没有直接的关系,它们分别从属于不同模块的控制与调用,它们之间不传递任何信息.8. 数据耦合指两个模块之间有调用关系,传递的是简单的数据值,相当于高级语言的值传递.9. 标记耦合指两个模块之间传递的是数据结构,如高级语言的数组名,记录名,文件名等这些名字即为标记,其实传递的是这个数据结构的地址.10. 控制耦合指一个模块调用另一个模块时,传递的是控制变量(如开关,标志等),被调模块通过该控制变量的值有选择地执行块内某一功能.11. 公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合.公共数据环境可是是全程变量或数据结构,共享的通信,内存的公共覆盖区及任何存储介质上的文件,物理设备等(也有将共享外部设备分类为外部耦合).12. 当一个模块直接使用另一个模块的内部数据,或通过非正常口转入另一个模块内部,这种模块之间的耦合为内容耦合.13. 内聚块又称块内联系指模块的功能强度的度量,即一个模块内部各个元素彼此结合的紧密程度的度量.14. 偶然内聚指一个模块内的各处理元素之间没有任何联系.15. 逻辑内聚指模块内执行个逻辑上相似的功能,通过参数确定该模块完成哪一个功能.16. 把需要同时执行的动作组合在一起形成的模块为时间内聚模块.17. 通信内聚指模块内所有处理元素都在同一个数据结构上操作(有时称之为信息内聚),或者指各处理使用相同的输入数据或者产生相同的输出数据.18. 顺序内聚指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行,前一功能元素的输出就是下一功能元素的输入.19. 功能内聚指模块内所有元素共同完成一个功能,缺一不可.因此模块不能再分割.第五章软件详细设计1. PAD图指问题分析图(Problem Analysis Diagram),是一咱算法描述工具,它是一种由左往右展开的二维树型结构.PAD图的控制流程为自上而下,从左到右地执行.2. 过程设计语言(Process Design Language,简称PDL),也称程序描述语言(Program Descrip on Language),又称为伪码.它是一种用于描述模块自法设计和处理细节的语言.第六章软件编码1. 程序设计风格指一个人编制程序时所表现出来的特点,习惯逻辑思路等.2. 指程序从一个计算机环境移值到另一个计算机环境的容易程序.第七章软件测试1. 语句覆盖是指设计足够的测试用例,使被测程序中每个语句至少执行一次.2. 判定覆盖指设计足够的测试用例,使得被测程序中每个判定表达式至少获得一次”真”和”假”值,从而使程序的每一个分支至少都通过一次.3. 条件覆盖指设计足够的测试用例,使得判定表达工中每个条件的各种可能的值出现一次.4. 判定/条件覆盖标准指设计足够的测试用例,使得判定表达式中的每个条件的所有可能取值至少出现一次,并使每个判定表达式所有可能的结果也至少出现一次.5. 条件组合覆盖是比较强的覆盖标准,它是指设计足够的测试用例,使得每个判定表达式中条件的各种可能的值的组合都至少出现一次.6. 路径覆盖是指设计足够的测试用例,覆盖被测程序中所有可能的路径.7. McCabe定义程序图的环路为程序图中区域的个数.区域个数为边和结点圈定的封闭区域数加上图形外的区域数1.8. 黑盒测试是功能测试又称为功能测试或数据驱动测试.9. 白盒测试是对程序中尽可能多和逻辑路径进行测试,检验内部控制结构和数据结构是否有错,实际的运行状态与预期的状态是否一致.10. 驱动模块是用来模拟被测模块的上级调用模块的模块,功能要比真正的上级模块简单得多,它只完成接受测试数据,以上级模块调用被测模块的格式驱动被模块,接收被测模块的测试结果并输出.11. 桩模块用来代替被测试模块所调用的模块它的作用是返回被测模块所需的信息.12. 单元测试指对源程序中每一个程序单元进行测试,检查各个模块是否正确实现规定的功能,从而发现模块在编码中或算法中的错误.13. 集成测试是指在单元测试的基础上,将所有模块按照设计要求组装成一个完整的系统进行测试,故也称组装测试或联合测试.14. 确认测试又称有效性测试.是为了检查软件的功能与性能是否与需求规格说明书中确定的指标相符合所进行的测试.15. 调试是为了确定错误的原因和位置,并改正错误所进行的工作,因此调试也称为纠错.第八章软件维护1. 在软件运行/维护阶段对软件产品所进行的修改就是维护.2. 为了识别和纠正错误,修改软件性能上的缺陷,应进行确定和修改错误的过程,这个过程就称为校正性维护.3. 随着计算机的飞速发展,计算机硬件,软件及数据环境在不断发生变化,为了使应用软件适应这种变化而修改软件的过程称为适应性维护.4. 在犯罪分子件运行时期中,用户往往会对软件提出新的功能要求与性能要求.这种增加软件功能,增强软件性能,提高软件运行效率而进行的维护活动称为完善性维护.5. 为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护.6. 软件可维护性是指软件能够被理解,校正,适应及增强功能的容易程度.第九章软件开发的增量模型1. 软件开发中的原型是软件的一个早期可运行的版本,它反映了最终系统的重要特性.第十章面向对象的方法1. 对象是人们要进行研究的任何事物,从最简单的整数到复杂的飞机等均可看作对象,它不仅能表示具体的事物,还能表示抽象的规则,计划或事件.2. 具有相同或相似性质的对象的抽象就是类具有相同或相似性质的对象的抽象就是类3. 对象之间进行通信的构造叫做消息.4. 类中操作的实现过程叫做方法,一个方法有方法名,参数,方法体.5. 继承性是子类自动共享父类数据结构和方法的机制这是类之间的一种关系.6. 在类层次中,子类只继承一个父类的数据结构和方法,称为单重继承.7. 在类层次中,子类继承了多个父亲的数据结构和方法,称为多重继承.8. 多态性是指相同的操作或函数,过程可作用于多用户种类型的对象上并获得不同结果.不同的对象收到同一消息可以产生不同的结果,这种现象称为多态性.9. 抽象是指强调实体的本质,内在的属性,忽略一些无关紧要的属性.10. 信息隐蔽是指所有软件部件内部都有明确的范围以及清楚的外部边界每个软件部件都有友好的界面接口,软件部件的内部实现与外部可访问性分离.11. 链表示对象间的物理与概念联结.12. 关联表示类之间的一种关系,就是一些可能的链的集合.第十一章软件质量与质量保证1. 软件按照设计要求,在规定时间和条件下不出故障,持续运行的程度.2. 为了完成预定功能,软件系统所需的计算机资源和程序代码数量的程度.3. 找到并改正程序中的一个错误所需代价的程度.4. 将一个软件系统从一个计算机系统或环境移植到另一个计算机系统或环境中运行时所需的工作量.5. 将一个系统耦合到另一个系统所需的工作量.6. 修改或改进一个已投入运行的软件所需工作量的程度.7. 一个软件能再次用于其他相关应用的程度.8. 设计的规格说明书要符合用户的要求.9. 程序要按照设计规格说明所规定的情况正确执行.10. 冗余是指实现系统规定功能是多余的那部分资源,包括硬件,软件,信息和时间.第十二章软件工程管理1. 软件配置管理,简称SCM,是一组管理整个软件生存期各阶段中变更的活动是一组管理整个软件生存期各阶段中变更的活动2. 软件配置项是软件工程中产生的信息项,它是配置管理的基本单位.3. 基线是软件生存期中各开发阶段的一个特定点,它的作用是把开发各阶段工作的划分更加明确化,使本来连续的工作在这些点上断开,以便于检查与肯定阶段成果.4. 文档是指某种数据媒体和其中所记录的数据.在软件工程中,文档用来表示对需求,工程或结果进行描述,定义,规定,报告或认证的任何书面或图示的信息.它们描述和规定了软件设计和实现的细节,说明使用软件的操作命令.第十三章软件开发环境1. 软件开发环境是相关的一组软件工具集合,它支持一定的软件开发方法或按照一定的软件开发模型组织而成.2. 软件工具是指为支持计算机软件的开发,维护,模拟,移植或管理而研制的程序系统.3. CASE是一组工具和方法的集合,可以辅助软件开发生命周期各阶段进行软件开发.4. 一个组织中的CASE系统从被始需求到完全废弃这一生存期.5. 一个CASE工作台是一组工具集,支持像设计,实现或测试等特定的软件开发阶段.。

软件工程导论第8章维护

从上述关于软件维护的定义不难看出，软件维护绝不仅限于纠正使用中发现的错误，事实上在全部维护活动中一半以上是完善性维护。国外的统计数字表明，完善性维护占全部维护活动的50％～66％，改正性维护占17％～21％，适应性维护占18％一25％，其他维护活动只占4％左右。
应该注意，上述4类维护活动都必须应用于整个软件配置，维护软件文档和维护软件的可执行代码是同样重要的。
软件工程的主要目的就是要提高软件的可维护性，减少软件维护所需要的工作量，降低软件系统的总成本。
8．1 软件维护的定义
所谓软件维护就是在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。可以通过描述软件交付使用后可能进行的4项活动，具体地定义软件维护。因为软件测试不可能暴露出一个大型软件系统中所有潜藏的错误，所以必然会有第一项维护活动：在任何大型程序的使用期间，用户必然会发现程序错误，并且把他们遇到的问题报告给维护人员。把诊断和改正错误的过程称为改正性维护。
8．2 软件维护的特点
8．2．1 结构化维护与非结构化维护差别巨大
1.非结构化维护
如果软件配置的惟一成分是程序代码，那么维护活动从艰苦地评价程序代码开始，而且常常由于程序内部文档不足而使评价更困难，对于软件结构、全程数据结构、系统接口、性能和(或)设计约束等经常会产生误解，而且对程序代码所做的改动的后果也是难于估量的：因为没有测试方面的文档，所以不可能进行回归测试(即指为了保证所做的修改没有在以前可以正常使用的软件功能中引入错误而重复过去做过的测试)。非结构化维护需要付出很大代价(浪费精力并且遭受挫折的打击)，这种维护方式是没有使用良好定义的方法学开发出来的软件的必然结果。
上面的模型表明，如果软件的开发途径不好(即，没有使用软件工程方法学)，而且原来的开发人员不能参加维护工作，那么维护工作量和费用将指数地增加。

《软件工程》第八章软件维护与再工程

软件可维护性－主要影响因素
可移植性：指程序转移到一个新的计算环境的难易程度。
影响软件可移植性的因素有：信息隐蔽原则；模块独立；模块化；高内聚低耦合；良好的程序结构；不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性－主要影响因素
软件维护的概念－维护成本
其它一些因素：如应用的类型、数学模型、任务的难度、IF嵌套深度、索引或下标数等，对维护工作量也有影响
软件维护的过程－维护组织
维护组织结构图
软件维护的过程－维护组织
系统监督员一般都是对程序(某一部分)特别熟悉的技术人员。在维护人员对程序进行修改的过程中，由配置管理员严格把关，控制修改的范围，对软件配置进行审计。维护管理员、系统监督员、修改控制决策机构等，均代表维护工作的某个职责范围。
如果已经开始保存维护记录，可以对维护工作做一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数；用于每一类维护活动的总人时数；平均每个程序、每种语言、每种维护类型所必需的程序变动数；维护过程中增加或删除源语句平均花费的人时数；维护每种语言平均花费的人时数；一张维护请求表的平均周转时间；不同维护类型所占的比例；
软件维护的过程－维护记录
软件修改报告指明：为满足维护申请报告提出的需求所需的工作量、本次维护活动的类别、本次维护请求的优先级、本次修改的背景数据。在拟定进一步维护计划前，软件修改报告要提交给修改决策机构，供进一步规划维护活动使用保存维护记录的第一个问题就是哪些数据值得保存？
软件维护的过程－维护评价
软件维护的概念－维护问题

i第8章软件维护

一些合理的修复或修改请求不能及时安排，使
得客户不满意；变更的结果引入新的故障，使得软件整体质量下降；把软件人员抽调到维护工作中，干扰了软件开发工作。
8.3 软件维护任务的实施
为了有效地进行软件维护，应事先就开始做组织工作。
首先建立维护的组织申明提出维护申请报告的过程及评价的过程为每一个维护申请规定标准的处理步骤建立维护活动的登记制度以及规定评价和评审
3.完善性维护

ቤተ መጻሕፍቲ ባይዱ
在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动叫做完善性维护。例如，完善性维护可能是修改一个计算工资的程序，使其增加新的扣除项目；缩短系统的应答时间，使其达到特定的要求等。

三类维护占总维护比例
维护在软件生存期所占比例
8.2 维护的特点
8.2.1 非结构化维护和结构化维护 1. 非结构化维护只有源程序，没有文档，维护活动只能从阅读、理解分析源程序开始，来了解系统功能、软件结构、数据结构、系统接口、设计约束等。

维护工作非常困难，要花费大量的人力、物力，最终对源程序修改的后果是难以估量的。

8.2.2 维护的困难性 1. 读懂别人的程序是困难的修改别人的程序不如自己重新编写程序 2. 文档的不一致性各种文档之间不一致文档与程序之间不一致主要是开发过程中文档管理不严造成：修改程序忘了修改与其相关的文档某一文档改了，没有修改与其相关的另一文档
3. 软件开发和软件维护在人员和时间上的差异软件维护工作由软件开发人员来进行，维护工作就变得容易通常开发人员和维护人员不同，导致维护的困难。维护阶段持续时间很长，正在运行的软件可能是十几、二十几年前开发的，开发工具、方法、技术与当前的工具、方法、技术差异很大，导致维护困难。 3. 软件维护不是一项吸引人的工作。

计算机文化基础第8章常用工具软件第三节使用系统维护工具Windows优化大师

8.3.1 Windows优化大师界面 8.3.2 检测系统信息 8.3.3 系统优化 8.3.4 系统清理 8.3.5 系统维护
8.3.1 Windows优化大师界面
Windows优化大师适用于Windows的各个操作系统平台，为用户提供了详尽准确的系统信息检测、全面的系统优化、强大的清理功能和有效的系统维护，使用户的操作系统始终保持在最佳状态。
8.3.3 系统优化
Windows优化大师可以对磁盘缓存、桌面菜单、文件系统、网络系统、开机速度和系统安全等方面进行优化。
下面介绍使用Windows优化大师进行开机速度优化的具体方法 (1) 启动优化大师，单击【系统优化】按钮，进入系统优化模块。 (2) 在【系统优化】选项列表中选择【开机速度优化】选项，如图8-35所示。
的学习，要求读者了解各软件的功能特点，掌握各软件的基本操作，从而提高工作和学习的成效。
第8章常用工具软件
8.1 文件压缩工具 8.2 ACDSee看图工具 8.3 使用系统维护工具-Windows优化大师 8.4 使用其他常用软件 8.5 上机实训
8.3 使用系统维护工具—— Windows优化大师
图8-35 开机速度优化
8.3.3 系统优化
(闭时，下次启动会自动运行磁盘错误检查工具，在自动运行前，Windows会等待一段时间便于用户确认是否要运行磁盘错误检查。默认等待时间为10秒，用户可以调整此等待时间。
(4) 在【启动项】列表中勾选开机时不自动运行的项目，单击【优化】按钮，系统开始优化。
(1) 双击桌面上的Windows优化大师图标或选择【开始】→【程序】→ 【Windows优化大师】命令，启动Windows优化大师。
(2) 单击【系统检测】按钮，进入如图8-34所示的系统检测模块。

软件工程导论习题答案

2.需求分析的基本任务是什么?
准确定义未来系统的目标，确定为了满足用户的需要系统必须做什么。
3.怎样建立目标系统的逻辑模型?要经过哪些步骤?
建立目标系统的逻辑模型的过程也就是数据流图的分解过程。它的导出过程如图：
Hale Waihona Puke 4.什么是结构化分析?它的结构化体现在哪里?
结构化分析:使用数据流程图、数据字典、结构化英语、判定表和判定树等工具，来建立一种新的、称为结构化说明书的目标文档-需求规格说明书。
(5)软件开发成本越来越大。
(6)软件成本与开发进度难以估计。
(7)软件技术的发展远远满足不了计算机应用的普及与深入的需要。
4.构成软件项目的最终产品：
应用程序、系统程序、面向用户的文档资料和面向开发者的文档资料。
5．什么是软件生存周期？
软件生存周期是指从软件定义、开发、使用、维护到淘汰的全过程。
6．软件生存周期为什么划分成阶段？
(1) 任何一个阶段的具体任务不仅独立，而且简单，便于不同人员分工协作，从而降低整个软件开发工作的困难程度。
(2) 可以降低每个阶段任务的复杂程度，简化不同阶段的联系，有利于工程的组织管理，也便于采用良好的技术方法。
(3) 使软件开发的全过程以一种有条不紊的方式进行，保证软件的质量，特别是提高了软件的可维护性。
结构化体现在将软件系统抽象为一系列的逻辑加工单元,各单元之间以数据流发生关联。
5.软件需求规格说明书由哪些部分组成?
组成包括：
(1) 引言：编写目的、背景说明、术语定义及参考资料等。
(2) 概述主要功能、约束条件或特殊需求。
(3) 数据流图与数据字典。
(4) 用户接口、硬件接口及软件接口。

第八章软件维护

9
软件维护的机构10软件维的事件流1112
软件维护工作流程
必要的技术工作修改软件需求说明修改软件设计设计评审对源程序做必要修改单元测试集成测试（回归测试）确认测试软件配置评审等。
13
8 .4 软件的可维护性
衡量软件质量的几个主要质量特性：可维护性可使用性可靠性一、软件可维护性的定义指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。
22
进行明确的质量保证审查
检查点复审、验收检查、周期性地维护审查、对软件包进行检查。
选择可维护的程序设计语言改进程序的文档开发软件时考虑到维护
23
相关习题 1．某些软件工程师不同意“目前国外许多软件开发组织把60%以上的人力用于维护已有的软件”的说法，他们争论说：“我并没有花费我的60%的时间去改正我所开发的程序中的错误”。请问，你对上述争论有何看法？ 2．为什么大型软件的维护成本高达开发成本的4倍左右？
7
8.2.3 维护的问题很多 ( 1 ）理解别人写的程序通常非常困难． ( 2 ）需要维护的软件无文档或不全． ( 3 ）软件人员流动性大． ( 4 ）设计时未考虑将来修改需要，修改困难． ( 5 ）维护工作无吸引力，缺乏成就感．
8
8. 3 软件维护过程
首先建立维护组织，确定报告和评价过程，为每个维护要求规定一个标准化的事件序列，并记录维护活动和规定复审标准。一、维护组识所有软件维护申请应按规定的方式提出维护机构通常提供“维护申请报告”或称 “软件问题报告”由申请维护的用户填写。维护机构内部要写“软件修改报告”
26
4．假设你的任务是对一个已有的软件做重大修改，而且只允许你从下述文档中选取两份：(a)程序的规格说明；(b)程序的详细设计结果（自然语言描述加上某种设计工具表示);（c)源程序清单（其中有适当数量的注解)。你将选取哪两份文档？为什么这样选取？

第8章软件维护

08 软件维护一、选择题(1)一般来说，在软件生命周期中成本最高的阶段是( D )。

A.详细设计B.软件编码C.软件测试D.软件维护(2)为软件的运行增加监控设施以应对将来可能出现的问题，这种维护的维护类型是( D )。

A．改正性维护 B．适应性维护 C．完善性维护 D．预防性维护(3)在整个软件维护阶段所花费的全部工作中，哪种维护所占比例最大？（ C ）A．改正性维护 B．适应性维护 C．完善性维护 D．预防性维护(4)产生软件维护的副作用，是指 ( C )A．开发时的错误 B．隐含的错误C．因修改软件而造成了新的错误 D．运行时误操作(5)维护的副作用可分三类，不包括（D ）。

A. 代码副作用B. 数据副作用C. 文档副作用D.人员副作用(6)下列属于维护阶段的文档是 ( C )。

A.软件规格说明B.用户操作手册C.软件问题报告D.软件测试分析报告(7)维护活动必须应用于（ B ）A．软件文档 B．整个软件配置 C．可执行代码 D．数据(8)为了提高软件的可维护性，在编码阶段应注意( D )。

A.保存测试用例和数据B.提高模块的独立性C.文档的副作用D.养成好的程序设计风格(9)为了提高软件的可维护性，在总体设计阶段应注意( B )。

A.保存测试用例和数据B.提高模块的独立性C.文档的副作用D.养成好的程序设计风格(10)以下哪些问题是维护人员经常面对的问题？（ D ）。

A．理解别人的程序非常困难 B．文档不合格C．设计时没考虑未来的修改维护 D．以上都是(11)决定软件可维护性的因素包括（ B ）。

A．可理解性，可测试性，可修改性，可移植性，可用性B．可理解性，可测试性，可修改性，可移植性，可重用性C．可理解性，可靠性，可测试性，可修改性，可移植性D．可理解性，可扩展性，可测试性，可修改性，可升级性(12)软件维护是保证软件正常、有效的重要手段，软件的下述特性中，( D )有利软件的维护。

《软件工程实用教程》第8_章_软件维护技术

第8 章軟體維Βιβλιοθήκη 技術8.2 軟體維護類型8.2.1 改正性維護 1. 利用應用軟體包，可開發出比由用戶完全自己開發的系統可靠性更高的軟體。 2. 結構化技術，用它開發的軟體易於理解和測試。 3. 防錯性程式設計。把自檢能力引入程式，通過非正常狀態的檢查，提供審查跟蹤。 4. 通過週期性維護審查，在形成維護問題之前就可確定品質缺陷。可理解性
第8 章軟體維護技術
8.2.2 完善性維護為了滿足日益增長的新要求，需要修改或再開發軟體，以擴充軟體功能，增強軟體性能，改進加工效率，提高軟體的可維護性，這些維護活動稱為完善性維護。 8.2.3 適應性維護為了使軟體適應新的變化而去修改軟體的維護活動稱為適應性維護。 8.2.4 預防性維護為以後進一步使用軟體打下良好基礎的維護活動稱為預防性維護活動。
第8 章軟體維護技術
8.4.2 軟體維護的副作用 1．修改代碼的副作用 2．修改數據的副作用 3．修改文檔的副作用
（1）確認維護類型（2）實施維護（3）維護評審
第8 章軟體維護技術
4．整理軟體維護文檔程式名稱；使用的程式設計語言；根源程式語句條數，機器代碼指令條數；程式安裝的日期；程式安裝後的運行次數；與程式安裝後運行次數有關的處理故障次數；程式改變的層次，名稱和日期；修改程式所增加的根源程式語句條數；修改程式所減少的根源程式語句條數；
第8 章軟體維護技術
8.3 軟體維護技術
8.3.1 軟體維護過程 1．建立維護機構
第8 章軟體維護技術
2．編寫軟體維護申請報告軟體變更報告包括的內容：所需修改變動的性質；申請修改的優先順序；為滿足該維護申請報告，所需的工作量（人員數，時間數）；預計修改後的結果。 3．確定軟體維護工作流程

软件工程参考资料【最新】

第一章、软件工程学概述软件是程序、数据及相关文档的完整集合。

软件危机是指在就是那几软件的开发和维护过程中所遇到的一系列严重问题。

其表现有：1.对软件开发成本和进度的估计常常很不准确。

2.用户为“已完成的”软件系统不满意的现象经常发生。

3.软件产品质量往往靠不住。

4.软件常常不可维护。

5.软件通常没有适当的文档资料。

6.软件成本在计算机系统总成本总所占的比例逐年上升。

7.软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

总之，为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。

软件工程正式从管理和技术两方面研究如何更好地开发和维护计算机软件的一门新兴学科。

软件工程的定义：概括地说，软件工程是指计算机软件卡发和维护的一门工程学科。

采用工程的概念、原理、技术方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来，以经济地开发出高质量的软件并有效地维护它，这就是软件工程。

软件工程的7条基本原理及其关系：1.用分阶段的生命周期计划严格管理。

2.坚持进行阶段评审。

3.实行严格的产品控制。

4采用现代程序设计技术。

5.结果应能清楚地审查。

6.开发小组的人员应该少而精。

7.承认不断改进软件工程实践的重要性。

关系：这7条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合，然而这7条原理又是相当完备的，人们虽然不能用数学方法严格证明它们是一个完备的集合，但是，可以证明在此之前已经提出的100多条软件工程原理都可以由这7条原理的任意组合蕴含或派生。

软件工程包括技术和管理两方面的内容，是技术于管理紧密结合所形成的工程学科。

所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，已达到既定目标的过程。

软件工程方法学包含3个要素：方法、工具和过程。

软件生命周期：概括地说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，每个时期又进一步划分成若干阶段。

第8章软件维护

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

第8章 软件维护

软件工程导论课件第8章

软件工程实用教程第三版-郭宁主编-课后习题及答案

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

软件工程 张海藩 课后习题答案

软件工程 第8章 软件维护

第8章软件维护

软件工程各章名词解释

软件工程导论 第8章 维护

《软件工程》第八章 软件维护与再工程

i第8章 软件维护

计算机文化基础 第8章常用工具软件 第三节使用系统维护工具Windows优化大师

软件工程导论习题答案

第八章 软件维护

第8章 软件维护

《软件工程实用教程》第8_章_软件维护技术

软件工程参考资料【最新】

第8章软件维护

软件工程张海藩课后习题答案

软件工程第8章软件维护

软件工程导论第8章维护

《软件工程》第八章软件维护与再工程

i第8章软件维护

计算机文化基础第8章常用工具软件第三节使用系统维护工具Windows优化大师

第八章软件维护

第8章软件维护