sw15.ppt

1、2020/7/30,1,第十五章 软件维护,软件维护的分类 维护过程 可维护性 维护的副作用 逆向工程与重构工程,2020/7/30,2,在软件开发过程中始终强调软件的可维护性。原因是,一个应用系统由于需求和环境的变化以及自身暴露的问题,在交付用户使用后，对它进行维护是不可避免的,统计和估测结果表明，信息技术中硬件费用一般占35%，软件占65%，而软件后期维护费用有时竟高达软件总费用的80%，所有前期开发费用仅占20%。 许多大型软件公司为维护已有软件耗费大量人力、财力。因此，必须建立一套评估、控制和实施软件维护的机制,这就是本章重点讨论的内容。,2020/7/30,3,15.1 软件维护的分

2、类,存周期的最后一个阶段,所有活动都发生在软件交付并投入运行之后。维护活动根据起因可分为改正性维护、适应性维护、改善性维护和预防性维护四类： 改正性维护是为诊断和改正软件系统中潜藏的错误而进行的活动。 适应性维护是为适应环境的变化而修改软件的活动。 改善性维护是根据用户在使用过程中提出的一些建设性意见而进行的维护活动。 预防性维护是为了进一步改善软件系统的可维护性和可靠性,并为以后的改进奠定基础。,第十五章 软件维护,2020/7/30,4,15.2 维护过程,软件维护与软件开发阶段的各项活动相比,直到近期才引起人们足够的重视,因此有关维护的技术和方法研究得还很不够。 本节主要讨论: (1)维

3、护阶段的主要活动及软件工程的目标、原则对这些活动的影响; (2)维护阶段的代价; (3)软件维护中经常遇到的一些问题。,第十五章 软件维护,2020/7/30,5,15.2.1 结构化与非结构化的维护,15.2维护过程,2020/7/30,6,非结构化,如果软件配置中唯一可用的是源代码,那么维护只能从“苦读”代码开始。由于缺乏内部文档,读代码是一项很枯燥、很困难的工作。 软件系统的许多微妙之处(例如软件总体结构、全局数据、系统接口、性能和设计方面的约束等)不是搞不清楚就是常常被误解,以致无法估量对源代码修改所产生的后果。 特别是，由于没有保存测试记录,使“回归测试”无法进行。 对于没有使用良好

4、开发方法开发的软件,不得不采用非结构化的方式进行维护并为此付出高昂的代价(浪费大量人力,且让维护人员有挫折感)。,15.2维护过程,2020/7/30,7,结构化,如果欲维护的软件存在一个完整的软件配置,维护活动将从阅读设计文档开始。 首先确定软件的重要结构、性能及接口特征,评估这次维护可能带来的影响并规划出一个具体实施方案;然后从修改设计入手(采用以前讨论过的设计技术)，设计复审通过之后再修改代码,并参照测试规格说明书对软件进行回归测试,测试通过后交付用户使用。 上述过程也称为结构化维护,它是采用软件工程方法学开发软件的自然结果。拥有完整的软件配置能减少维护工作量，提高维护质量。,15.2维

5、护过程,2020/7/30,8,15.2.2 维护的成本,过去的二十年,软件维护的成本在不断增长。 七十年代,一个信息系统机构用于软件维护的费用占其软件总预算的3540%,八十年代接近60%。 若维护方式没有大的改进,未来几年，许多大型软件公司可能要将其预算的80%用于软件系统的维护上。,15.2维护过程,2020/7/30,9,维护的成本,其他因素也已经引起人们的注意。如： 由于资源(人力、设备)优先用于维护任务,影响新软件系统的开发，可能会丧失机会； 有时还要付出一些无形的代价，如某些貌似合理但实际不能满足的维护请求将引起用户不满; 在软件维护过程中引入的潜在错误降低了软件的质量; 从开发

6、小组中临时抽调工程师从事维护工作冲击正在进行的开发等等。 最后，维护旧程序使生产率(按每人月代码行或每人月功能点计算)大幅度下降。,15.2维护过程,2020/7/30,10,15.2.3 可能存在的问题,软件维护中出现的大部分问题都可归咎于软件规划和开发方法的缺陷。 软件开发时采用急功近利还是放眼未来的态度,对软件维护影响极大。 一般说来,软件开发若不严格遵循软件开发标准,软件维护就会遇到许多困难。,15.2维护过程,2020/7/30,11,典型问题,(1)很难甚至不可能追踪软件版本的进化过程,软件的变化没在相应文档中反映出来; (2)很难甚至不可能追踪软件的整个创建过程； (3)理解他人

7、的程序非常困难,当软件配置不全,仅有源代码时问题尤为严重; (4)软件人员流动性很大,维护他人软件时很难得到开发者的帮助； (5)软件没有文档、或文档不全、或文档不易理解、或与源代码不一致； (6)多数软件设计未考虑修改的需要(有些设计方法采用了功能独立和对象类型等一些便于修改的概念),软件修改不仅困难而且容易出错。 (7)软件维护不是一项有吸引力的工作,从事这项工作令人缺乏成就感。,15.2维护过程,2020/7/30,12,15.3 可维护性,软件可维护性指，软件被理解、改正、调整和改进的难易程度。 可维护性是指导软件工程各个阶段工作的一条基本原则,也是软件工程追求的目标之一。,第十五章

8、软件维护,2020/7/30,13,15.3.1 影响可维护性的因素,软件的可维护性受各种因素的影响。设计、编码和测试时漫不经心，软件配置不全都会给维护带来困难。除了与开发方法有关的因素外,还有下列与开发环境有关的因素: 是否拥有一组训练有素的软件人员; 系统结构是否可理解; 是否使用标准的程序设计语言; 是否使用标准的操作系统; 文档的结构是否标准化; 测试用例是否合适; 是否已有嵌入系统的调试工具; 是否有一台计算机可用于维护。 除此之外,软件开发时的原班人马是否能参加维护也是一个值得考虑的因素。,15.3可维护性,2020/7/30,14,15.3.2 若干量化的测度,软件可维护性与软件

9、质量和可靠性一样是难于量化的概念,然而借助维护活动中可以定量估算的属性,能间接地度量可维护性: 察觉到问题所耗的时间; 收集维护工具所用的时间; 分析问题所需时间; 形成修改说明书所需时间； 纠错(或修改)所用时间; 局部测试所用时间; 整体测试所用时间; 维护复审所用时间; 完全恢复所用时间。,15.3可维护性,2020/7/30,15,15.3.3 保证可维护性的复审,可维护性是所有软件都努力追求的一个基本特性。在软件工程每一阶段的复审中,可维护性都是重要指标。 在需求分析阶段的复审中,应对将来可能修改和可以改进的部分加以注释,对软件的可移植性加以讨论并考虑可能影响软件维护的系统界面; 在

10、设计阶段的复审中,应从易于维护和提高设计总体质量的角度全面评审数据设计、总体结构设计、过程设计和界面设计; 代码复审主要强调编程风格和内部文档这两个直接影响可维护性的因素; 最后,每一阶段性测试都应指出软件正式交付之前,应该进行的预防性维护。 软件维护活动完成之际亦要进行复审。 正式的可维护性复审放在测试完成之后,称为配置复审。,15.3可维护性,2020/7/30,16,15.4 维护活动,软件维护工作在维护申请提出之前就开始了,它包括： 建立维护组织,强制报告和评估的过程; 为每个维护申请确定标准化的事件序列; 制定保存维护活动记录的制度和有关复审及评估的标准。,第十五章 软件维护,202

11、0/7/30,17,15.4.1 维护组织,15.4维护活动,2020/7/30,18,维护的一种组织模式,每个维护申请通过维护管理员转告给系统管理员,系统管理员一般都是对程序(某一部分)特别熟悉的技术人员,他们对维护申请及可能引起的软件修改进行评估,并向修改控制决策机构(一个或一组管理者)报告,由它最后确定是否采取行动。 依照这样的组织方式开展维护活动能减少混乱和盲目性,避免因小失大的情况发生。 上述各个岗位都不需要专职人员,但必须为胜任者,并且要早在维护活动开始之前就明确各自责任,避免互相推诿,急功近利的现象。,15.4维护活动,2020/7/30,19,15.4.2 维护的报告与评估,所

12、有的软件维护申请都应该采用标准化的格式,软件开发人员统一发放的维护申请单MRF或称为软件问题报告单,由用户根据需要填写。 如果用户确实发现了错误,必须完整地记录出错现场信息(包括输入数据、列表文件和其他有关信息)； 如果用户提出适应性或改善性维护请求,需同时提交一个简短的修改规格说明书(即简单的需求规格说明书)。 维护管理员将MRF提交给系统管理员评估。 一个维护申请被核准后,MRF成为外部文档,视作规划本次维护任务的依据。,15.4维护活动,2020/7/30,20,维护修改报告单,软件组织内部还要另外制定一个软件修改报告单SCR用于说明: 为满足MRF提出的要求所需工作量； 本次维护活动的

13、性质； 本次维护请求的优先级； 本次修改的背景数据。 将SCR提交给修改控制决策机构,供进一步规划维护活动使用。,15.4维护活动,2020/7/30,21,状况复审,当一项软件维护任务完成之后,进行一次状况复审大有益处。状况复审主要考虑下列问题: 依照当前状态,在设计、编码和测试的哪些方面还能用其他方法进行? 哪些维护资源可用但未用； 这次维护活动中主要(或次要)的障碍有哪些? 在维护请求中有预防性维护吗? 状况复审的目的在于促进未来的维护工作,同时也为有效管理软件组织提供重要的反馈信息。,15.4维护活动,2020/7/30,22,15.4.4 保存维护记录,维护过程中值得记录的数据包括:

14、 1 程序标志; 2 源程序行数; 3 目标程序指令条数; 4 所用编程语言; 5 安装程序的日期; 6 自安装之日起程序运行的次数; 7 自安装之日起程序失败的次数; 8 程序修改处的层数和标志; 9 因程序变动而增加的源程序行数;,15.4维护活动,2020/7/30,23,保存维护记录,10因程序变动而删除的源程序行数; 11每处改动所耗人时数; 12程序改动的日期; 13软件工程师的标志; 14MRF的标志; 15本次维护的类型; 16维护开始和结束的日期; 17用于此次维护累计人时数; 18执行本次维护的纯利润。,15.4维护活动,2020/7/30,24,15.4.5 评价维护活动

15、,如果缺乏真实可信的数据,评估活动毫无意义。在保存了维护记录的前提下,可对维护性能进行度量,统计下列数据是必要的: 程序每次运行的平均失效次数; 各类维护耗费的总人时数; 各种程序、各种语言及各类维护的程序平均变动数; 维护阶段增删一个语句平均花费的人时数; 维护每种语言的程序平均花费的人时数; 一张MRF的平均周转时间; 各类维护请求的百分比。 根据这些统计量可对开发技术、编程语言,以及对维护工作量的预测与资源分配等诸多方面的决策进行评价。,15.4维护活动,2020/7/30,25,15.5 维护的副作用,软件修改是一项很危险的工作,对一个复杂的逻辑过程,那怕做一项微小的改动,都可能引入潜

16、在的错误,虽然设计文档化和细致的回归测试有助于排除错误,但是维护仍然会产生副作用。 软件维护的副作用指，由于维护或在维护过程中其他一些不期望的行为引入的错误,副作用大致可分为三类: (1)代码副作用 (2)数据副作用 (3)文档的副作用,第十五章 软件维护,2020/7/30,26,1. 代码副作用,修改或删除子程序; 修改或删除语句标号; 修改或删除标识符; 为提高执行效率而做的修改; 修改文件的open、close操作; 修改逻辑操作符; 由设计变动引起的代码修改; 修改对边界条件的测试。,15.5维护的副作用,2020/7/30,27,2. 数据副作用,局部和全局常量的再定义; 记录或文

17、件格式的再定义; 增减数据或其他复杂数据结构的体积; 修改全局数据; 重新初始化控制标志和指针; 重新排列I/O表或子程序参数表。,15.5维护的副作用,2020/7/30,28,3. 文档的副作用,维护应统一考虑整个软件配置,而不仅仅是源代码。否则,由于在设计文档和用户手册中未能准确反映修改情况而引起文档副作用。 对软件的任何修改都应在相应的技术文档中反映出来,如果设计文档不能与软件当前的状况对应则比没有文档更糟。 对用户来说,若使用说明中未能反映修改后的状况,那么用户在这些问题上必定出错。 一次维护完成之后,再次交付软件之前应仔细复审整个配置,有效地减少文档副作用。 某些维护申请不必修改设

18、计和代码,只需整理用户文档便可达到维护的目的。,15.5维护的副作用,2020/7/30,29,15.6 逆向工程与重构工程,逆向工程与重构工程是目前预防性维护采用的主要技术。 所谓软件的逆向工程就是分析已有的程序,寻求比源代码更高级的抽象表现形式。一般认为，凡是在软件生命周期内，将软件某种形式的描述转换成更为抽象形式的活动都可称为逆向工程。 与之相关的概念是: 重构，指在同一抽象级别上转换系统描述形式； 设计恢复，指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计的信息(不一定是原设计)； 重构工程,也称修复和改造工程,它是在逆向工程所获信息的基础上修改或重构已有的系统,产生系统的一个新版本。,第十五章 软件维护,2