软件维护.ppt

《软件维护.ppt》由会员分享，可在线阅读，更多相关《软件维护.ppt（29页珍藏版）》请在三一文库上搜索。

1、2019年9月18日,1,软件生存周期的最后一个阶段 系统投入生产性运行以后的时期 需要的工作量非常大： 开发成本的四倍左右 60以上的人力 有资料表明，在数据处理方面，预算的30%-80%往往需用于软件的维护工作 软件开发必须有利于提高软件可维护性,软件维护,2019年9月18日,2,软件维护的定义,改正性维护 对使用中发现的程 序错误进行修改 适应性维护 为配合环境的变化 而进行的修改 完善性维护 增加新功能或修改 已有功能 预防性维护 给未来的改进奠定 更好的基础而修改,在软件交付使用后，为了改正错误或满足新的需要而修改软件的过程,2019年9月18日,3,一直是软件生存周期中被忽视的阶

2、段 关于维护的文献很少 几乎没有提出什么有效的技术途径和“方法” 软件可维护性维护人员理解、改正、改动和改进某软件的难易程度,如何提高软件的可维护性,2019年9月18日,4,一、维护的特点,从三个不同的方面考虑： 1. 为了完成维护任务需要进行的活动，以及软件工程方法学对这类活动的功效的影响；,如何提高软件的可维护性,2019年9月18日,5,最明显的，软件维护的费用随时间稳步上升： 1970年-35%-40% 1980年-40%-60% 1990年-70%-80% 无形的代价: 因为维护现有软件占用了资源,使开发新软件错失良机；当看来合理的维护要求未得到及时满足将引起用户不满；考虑欠周到的

3、维护使软件引入新故障质量降低；为了应急,临时抽人,使正在进行的开发工作打断或混乱；软件生产率大幅度下降 用于维护工作的劳动： 生产性活动(分析评价、修改设计、编写程序代码等) 非生产性活动（理解程序、解释数据结构、接口特点、 性能限度等）,2. 维护的代价,如何提高软件的可维护性,2019年9月18日,6,维护工作量的一个模型： M P K exp ( c d ) 其中 M维护用的总工作量 P生产性工作量 K经验常数 c复杂程度 d维护人员对软件的熟悉程度 模型表明：如果软件的开发途径不好（即，没有使用软件工程方法论），而且原的开发人员不能参加维护工作，那么维护工作量（和费用）将指数地增加,如

4、何提高软件的可维护性,2019年9月18日,7,起因：软件定义和开发的方法有缺点 无严格、科学的管理与规划,3. 维护的问题,例子：某公园有一游船码头，负责人请一位软件开发人员实现 计算机辅助游船管理系统。要求如下： 当游客向租船处查问是否有可以租用的船只，如果租船处有空船，管理员就准备好船只，帮助游客上船，并在联机终端上打入一信息“S”表示租船周期开始。计算机自动把当时时钟值送入信息域。当游客还船时，管理员打入另一信息“E”表示租船周期结束。由管理员向游客结算租船时间和费用。一天结束时，管理员要用一些管理信息总结每天工作状况，要求系统打印出: 租船次数 平均租船时间,如何提高软件的可维护性,

5、2019年9月18日,8,显然，该系统的功能包括两部分： 对输入流的信息进行汇总计算; 打印输出. 因为 平均租船的时间 = 总的时间 / 租船次数 总时间 = （ 第一条租船结束时间 - 第一条租船开始时间） + （第二条租船结束时间 - 第二条租船开始时间） + 或者 总时间 =（第一条租船结束时间 + 第二条租船结束时间 + ） -（第一条租船开始时间 + 第二条租船开始时间 + ）,如何提高软件的可维护性,2019年9月18日,9,BEGIN OPEN MESSAGE-STREAM NUMBER=0 TOTALTIME=0 GET MESSAGE DO WHILE NOT END-OF

6、-STREAM IF CODE=S THEN NUMBER=NUMBER+1 TOTALTIME=TOTALTIME-STARTIME ELSE TOTALTIME=TOTALTIME+ENDTIME ENDIF PRINT NUMBER OF SESSION=NUMBER IF NUMBER=0 THEN PRINT AVERAGE SESSION TIME=TOTALTIME/NUMBER ENDIF CLOSE MESSAGE-STREAM END;,可以写出如下伪码程序：,如何提高软件的可维护性,2019年9月18日,10,如此简单的算法完成了全部的功能要求，当然这只是多种实现方案之一

7、。 可后来，一系列的麻烦接踵而至： 不久，负责人希望软件增加一项新功能： 找出一天中最长租用时间LongestSessionTime 开发人员仔细考虑后，认为需重新设计算法，可是时间与经费都不允许，所以借口推辞（技术原因-OS不允许把新要求扩充近来）-作罢！,如何提高软件的可维护性,2019年9月18日,11,几天后，负责人又提出： 把每天的报告分成上午情况、下午情况两份报告 开发人员再次推托（磁盘原因无法达此目标）， -负责人甚不满！ 接下来，负责人要求修改系统： 从报告中删除一切不完整的信息 因为通信线路的故障造成了部分信息丢失，不改不行 ！ 此紧急状况下，开发人员无充足的时间让从头另做，

8、 -负责人再也无耐心听其找理由了！,如何提高软件的可维护性,2019年9月18日,12,结论：按某种要求改动软件并非易事！ 反思：此例最初的软件方案中，忽略了每个游客 的租船时间概念，制约了开发人员对负责 人后来一系列新要求的满足。 经验教训：在系统设计中应抓住问题的基本量！ -提高软件的可维护性！,如何提高软件的可维护性,2019年9月18日,13,二、 决定软件可维护性的因素 可理解性 读者理解软件的结构、接口、功能和内部过程的难易程度 模块化、详细的设计文档、结构化设计、源代码内部的文档和良好的高级程序设计语言等等，都对改进软件的可理解性有重要贡献 可测试性 诊断和测试的容易程度 良好的

9、文档、软件结构、可用的测试工具和调试工具，及以前设计的测试过程也都是非常重要的 维护人员应该能够得到在开发阶段用过的测试方案，以便进行回归测试,如何提高软件的可维护性,2019年9月18日,14,可修改性 软件容易修改的程度 设计原理和规则直接有关。耦合、内聚、局部化、控制域与作用域的关系等等，都影响软件的可修改性,如何提高软件的可维护性,2019年9月18日,15,三、定量度量可维护性 Gilb建议的可维护性度量指标： 1. 识别问题的时间 2. 管理延迟时间 3. 维护工具的收集时间 4. 分析、诊断问题的时间 5. 修改说明书的时间 6. 改正（或修改）的时间 7. 局部测试时间 8.

10、复查时间 9. 全程测试和回归测试的时间 10. 恢复时间 事实上，上述每个度量都不难做到。记录这些数据可以给管理人员提供新技术和新工具效能指示。,如何提高软件的可维护性,2019年9月18日,16,1. 建立维护组织，明确维护责任,软件维护过程,2019年9月18日,17,2. 维护报告 用标准化的格式表达所有软件维护要求 软件组织内部应该制定出一个软件修改报告，它给出下述信息： (1) 满足维护要求表中提出的要求所需要的工作量； (2) 维护要求的性质； (3) 这项要求的优先次序； (4) 与修改有关的事后数据 在拟定进一步的维护计划之前，把软件修改报告提交变化授权人审查批准,软件维护过

11、程,2019年9月18日,18,3. 维护的事件流,软件维护过程,1,2019年9月18日,19,复查试图回答下述问题： 在当前处境下设计、编码或测试的哪些方面能用不同方法进行？ 哪些维护资源是应该有而事实上却没有的？ 对于这项维护工作什么是主要的（以及次要的）障碍？ 要求的维护类型中有预防性维护吗？ 处境复查对将来维护工作的进行有重要影响，而且所提供的反馈信息对有效地管理软件组织十分重要,软件维护过程,2019年9月18日,20,4. 保存维护记录-哪些数据是值得记录的？ Swanson提出了下述内容： (1) 程序标识 (2)自从安装以来程序运行的次数 (3) 机器指令条数 (4) 使用的

12、程序设计语言 (5) 程序安装的日期 (6)自从安装以来程序失效的次数 (7)源语句数 (8) 程序变动的层次和标识 (9) 因程序变动而增加的源语句数 (10) 因程序变动而删除的源语句数 (11) 每个改动耗费的人时数 (12) 程序改动的日期 (13) 软件工程师的名字 (14) 维护要求表的标识 (15) 维护类型 (16) 维护开始和完成的日期 (17) 累计用于维护的人时 (18) 与完成的维护相联系的纯效益 l 应该为每项维护工作都收集上述数据，构成一个维护数据库,软件维护过程,2019年9月18日,21,5. 评价维护活动 定量度量维护工作： (1) 每次程序运行平均失效的次数

13、 (2) 用于每一类维护活动的总人时数 (3) 平均每个程序、每种语言、每种维护类型所做的程序变 动数 (4) 维护过程中增加或删除一个源语句平均花费的人时数 (5) 维护每种语言平均花费的人时数 (6) 一张维护要求表的平均周转时间 (7) 不同维护类型所占的百分比,软件维护过程,根据对维护工作定量度量的结果，可以做出关于开发技术、语言选择、维护工作量规划、资源分配及其他许多方面的决定，而且可以利用这样的数据去分析评价维护任务,2019年9月18日,22,修改软件冒险 每当往复杂的软件系统中引进一个变动，发生错误的可能性也就增加一分 副作用 在软件维护的范畴中，所谓副作用是指因为修改软件而出

14、现的错误或其他不符合需要的行为,维护的副作用,2019年9月18日,23,三种主要的副作用： 1. 编码的副作用 一个逗号错写成句号，复查时又没有发现，使一次阿波罗外层空间飞行的控制软件失效，产生了近乎悲剧性的后果 下列一些变动更容易引入故障： (1) 删掉或修改一个子程序； (2) 删掉或修改一个语句标号； (3) 删掉或修改一个标识符； (4) 为改进性能而做的变动； (5) 修改打开和关闭文件的语句； (6) 修改逻辑运算符。,维护的副作用,2019年9月18日,24,维护的副作用,2. 数据的副作用 在数据中做下述变动容易产生副作用： (1) 重新定义局部的或全程的常数； (2) 重新

15、定义记录或文件的格式； (3) 增加（或减少）数组或高阶数据结构的长度； (4) 修改全程数据； (5) 重新初始化控制标记或指针； (6) 重新安排输入/输出或子程序的变元。 完善的设计文档能够减少数据的副作用。这种设计文档不仅描述数据结构，而且提供数据与模块之间的交叉参照,2019年9月18日,25,维护的副作用,3. 文档的副作用 维护应该针对整个软件配置，不应该只修改源程序代码。当对源程序代码的修改没有反映在设计文档或用户手册中时，就会产生文档的副作用 准确反映软件当前状态的设计文档的错误,2019年9月18日,26,文档,影响软件可维护性的决定因素 1. 软件文档的组成 l 分用户文

16、档和系统文档两类 主要描述系统功能和使用方法 描述系统设计、实现和测试等各方面的内容,2019年9月18日,27,文档,用户文档至少应该包括下述五方面的内容： (1) 功能描述，说明系统能做什么； (2) 安装文档，说明怎样安装这个系统以及怎样使系统适应特定的硬件配置； (3) 使用手册，简要说明如何着手使用这个系统（应该通过丰富例子说明怎样使用常用的系统功能，还应该说明用户操作错误时怎样恢复和重新启动）； (4) 参考手册，详尽描述用户可以使用的所有系统设施以及它们的使用方法，还应该解释系统可能产生的各种出错信息的含义（对参考手册最主要的要求是完整，因此通常使用形式化的描述技术）； (5)

17、操作员指南（如果需要有系统操作员的话），说明操作员应该如何处理使用中出现的各种情况。 系统文档指从问题定义、要求说明到验收测试计划这样一系列 系统实现有关的文档,2019年9月18日,28,文档,2. 文档工具 使用软件工具开发和维护文档比起手工方式有下述一些优点： (1) 需要的文档可以随时显式在终端上，不需要费力地在手册中查找； (2) 存储在计算机中的文档容易修改和维护，因此保持文档和程序代码完全一致的可能性更大； (3) 可以自动确定文档正文的格式，并且能用整齐清晰的格式印出来； (4) 可以从不同角度自动地分析文档正文，产生不同类型的索引，并且检查拼写和打字的错误； (5) 可以由几个同时书写一份文档； (6) 简化了文档的管理。,2019年9月18日,29,文档,一个功能齐全的正文编辑系统是最重要的文档工具 UNIX操作系统中的nroff/troff系统是典型的格式程序 常见的文档管理工具：,编辑程序和正文格式程序 辅助校对的程序 复杂表格和数学公式的辅助布局程序 图形系统 模式匹配系统 鉴别和管理文档变化的程序,