维护(zhhf08)解析.ppt

第十五讲 软件维护（Maintaining） 本讲（第八章）的主要内容 软件维护的定义 维护的特点 维护过程 软件可维护性 预防性维护 软件再工程过程 修改的副作用 1. 软件维护的定义 在 软件交付使用以后，为了改正错误或满足新的需要而修改软件的过程。 四种类型的维护 改正性维护(Corrective Maintenance) 诊断和改正使用期间所发现的错误 适应性维护(Adaptive Maintenance) 由于硬件、系统软件和应用软件的发展不协调，须为提高软件的适应性而修改软件 完善性维护(Perfect Maintenance) 为满足用户对软件所提出的新的要求，对软件进行修改。 预防性维护(Preventive Maintenance) 为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件。 维护成本占总开发成本的比例 四种维护所占比例 2. 软件维护的特点 结构化维护 所维护的软件的配置是否齐全，如软件结构、全程数据结构、系统接口、性能说明、设计约束等。 （P180） 非结构化维护工作十分困难 仅有程序代码 维护代价高昂 维护问题多 维护的代价 维护费用有上升的趋势 维护的无形代价 美国海军飞行控制软件每条指令的开发成本是50$，而每条指令的维护成本是4000$. Belady建议的估算公式： M = P + K ? exp(c-d) 其中，M是维护总工作量，P为生产性工作量，K 为经验常数，c 是复杂程度，d 是维护人员对软件的熟悉程度。 维护的问题（P181） 理解别人的程序很难。 没有合格的文档，或文档不全。 维护阶段持续时间漫长，“事过境迁”。 绝大数软件在设计时没有考虑将来的维护问题。 软件维护是一项不吸引人的工作。 3. 软件维护过程 维护组织(p182) 维护报告 维护的事件流 保存维护记录 评价维护活动 维护管理员 根据项目的规模，指定一名高级管理人员担任，或由高级管理人员和专业人员组成修改控制组（CCB——change control board），负责对维护申请的审查与批准，指定维护的计划安排、人力和资源分配，批准向用户发布维护结果，对维护活动进行评价和分析。 一般还设置系统监督员、维护人员，系统管理员等 维护报告 维护要求表 软件问题报告表，一种标准化的表格。 由用户填写，描述导致错误的环境等。 软件修改报告的基本内容（P183） 所需要的工作量 维护要求的性质 这项要求的优先次序 与修改有关的事后数据 维护的事件流 （P183图8.2） 保存维护记录 （P171） 评价维护活动 基于所保存的维护记录，可以对维护工作进行评价和一些定量度量。 可以度量维护活动的几个方面 每次程序运行平均失效的次数； 用于每类维护活动的总人时数； 平均每个程序、每种语言、每种维护所做的程序变动数； 增加或删除一个源语句平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； 不同的维护类型所占的百分比。 4. 可维护性 可维护性是指纠正软件系统出现的错误和缺陷，以及为满足新的需求而进行修改、扩充或压缩的容易程度。 决定软件可维护性的因素 可理解性 可测试性 可修改性 可移植性 可重用性 文档是影响以上五个特性的决定因素，因此，文档是影响可维护性的决定因素。 文档是软件可维护性的决定因素 用户文档 功能描述，安装说明，使用手册，参考手册，操作员指南等 系统文档 指从问题定义、需求说明到验收测试计划的一系列和实现有关的文档。主要描述系统设计、实现和测试等各方面的内容。 软件文档应该满足的基本要求（P186） 提高可维护性的方法 建立明确的软件质量目标和优先级别 使用质量保证的技术和方法 进行明确的质量保证审查 选择可维护的程序设计语言 改进程序的文档 维护“老化代码” “老化代码” 是指15年以前开发的程序 参与人员已人去楼空 当时的开发技术被淘汰 没有完全的软件配置 只能够非结构化维护 针对“老化代码”，Yourdon 提出了一些建议: 在维护之前，必须研究程序的使用环境及有关资料。 力图熟悉程序的所有控制流程。 评价现有文档的可用性。 保持详细的维护活动和维护结果记录。 …… 8.5 预防性维护 预防性维护(Preventive Maintenance) 为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件。 维护老系统以适应新的需求（P188） 将再工程用于所要维护的老系统 将再工程用于维护老系统的理由 将再工程用于维护老系统的理由 8.6 逆向工程和再工程 逆向工程(实现设计规范需求,具体抽象) 再工程(复壮或再生) 不仅从已