第七的章 软件维护.ppt

第七章 软件维护 本章内容是一般掌握内容 本章主要内容 7.1 软件维护的概念 7.2 软件的可维护性 7.3 软件维护的过程 7.4 提高软件可维护性的方法 7.5 软件的逆向工程与再工程 7.1 软件维护的概念 Q：什么是维护？ A：在软件已经交付使用之后，为了改正错误或满足新的需要而修改软件的过程。 Q：维护做什么？ A: ① 诊断和改正错误 —— 改正性维护，约占全部维护活动的 17~20%； ② 为了适应变化了的环境（如软\硬件升级、新数据库等）而修改软件 —— 适应性维护，约占全部维护活动的18~25%； 软件维护的概念 ③为了增加新功能，修改已有功能，改造界面，增加HELP等，而修改软件 —— 完善性维护，约占全部维护活动的50~66% ； ④为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件 —— 预防性维护，约占总维护的4%左右。 三类维护占 维护在软件生存期 总维护比例 所占比例 7.2 软件的可维护性 软件可维护性，是指纠正软件系统出现的错误和缺陷，以及为满足新的要求进行修改、扩充或压缩的容易程度。 衡量软件可维护性的7个质量特性：可理解性，可测试性，可修改性，可靠性，可移植性，可使用性，效率。 软件的可维护性是软件开发阶段各个时期的关键目标。 软件的可维护性是产品投入运行以前各阶段针对上述各质量特性要求进行开发的最终结果。 可维护性的度量 难以做出定量度量，只能对其七种特性进行综合度量。 ⑴ 可理解性：可理解性表明人们通过阅读源代码和相关文档，了解程序功能及其如何运行的容易程度。 好程序的特征：模块化，风格一致性，不使用令人捉摸不定或含糊不清的代码，使用有意义的数据名和过程名，对输入数据进行完整性检查等。 ⑵ 可测试性： 是指软件被测试的容易程度。 好程序的特征：可理解、可靠、简单，有齐全的测试文档。 度量方法：程序复杂度。 可维护性的度量 ⑶ 可修改性：是指程序容易修改的程度。 好程序的特征：可理解、简单、通用。 度量方法： 其中：D = 修改难度； A = 要修改的模块的复杂度； C = 所有模块的平均复杂度。 D ? 1表示修改很困难。 ⑷ 可靠性：表明一个程序按照用户的要求和设计目标，在给定的一段时间内正确执行的概率。 可维护性的度量 ⑸ 可移植性：是指程序被移到一个新环境的容易程度。 好程序的特征：结构好，不特别依赖于某一具体的计算机或操作系统。 ⑹ 可使用性：从用户观点出发，程序方便、实用、及易于使用的程度。 一个可使用的程序应是易于使用的、能允许用户出错和改变，并尽可能不使用户陷入混乱状态的程序。 ⑺ 效率：是指程序能执行预定功能，而又不浪费机器资源（包括内存、外存、通道容量、执行时间等等）的程度。 7.3 提高可维护性的方法 维护的代价： 有形代价 无形代价(占用资源以致延误开发;修改不及时引起用户不满;维护引入新错误，降低了软件质量；等等) 维护的困难性: 文档 影响可维护性的决定因素，比代码更重要。 ⑴ 用户文档： ①功能描述 —— 说明系统能做什么； ②安装文档 —— 说明安装系统的方法及适应特定的硬件配置的方法； ③使用手册 —— 说明使用方法以及错误挽救方法； ④参考手册 —— 详尽描述用户可使用的所有系统设施以及它们的使用方法；给出错误信息注解表； ⑤操作员指南（如果需要有系统操作员的话）—— 说明操作员处理使用中出现的各种情况的方法。 ⑵系统文档：即软件生产过程中每一步产生的文档。 提高可维护性的方法 建立明确的软件质量目标 如：编译程序 强调效率 MIS系统 强调可使用性和可修改性 使用先进的软件开发技术和工具 采用模块化、结构化技术，使用文档工具 进行明确的质量保证审查 在检查点进行审查，验收，周期性的维护审查 选择可维护的程序设计语言 高级语言 采用软件维护的新方法 7.4 软件的维护过程 本质上是修改和压缩了的软件定义和开发过程。 首先建立维护的机构； 申明提出维护申请报告的过程及评价的过程； 为每一个维护申请规定标准的处理步骤； 建立维护活动的登记制度以及规定评价和评审的标准。 建立维护组织 虽然不要求建立一个正式的维护机构，但是在开发部门确立一个非正式的维护机构则是非常必要的。 尽管没有专门机构也要明确职责 避免混乱――随意修改 改善流程――减少抵触情绪 维护报告 ⑴ 维护申请报告 由用户填写的外部文件，提供错误情况说明（输入数据，错误清单等），或修改说明书等。 ⑵ 维护评价报告：与维护申请报告相应的内部文件，要求说明： ①所需修改变动的性质； ②申请修改的优先级； ③为满足某个维护申请报告，所需的工