《软件工程》第8章 维护-大纲

改错或修改的要求不能及时满足引起的用户不满； 维护时的改动，引入潜伏错误，导致软件质量降低； 软件工程师从事维护工作造成的开发过程混乱。 生产率的大幅下降 维护工作量：生产性劳动+非生产性劳动。
分析评价，修改设计，编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序，缺乏必要的文档说 明，难于确定数据结构、系统接口等特性的情况下，进行 的软件维高昂
明显代价：高昂的维护费用，已上升达80%左右； 无形代价：
的工作环境，或适应已变动的数据或文件； （4）为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错，以及验证、修改的回归测试过程， 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求， 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化， 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等，或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审

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

工学二部计算机教研室
（2）并行方式
关系重大的软件一般采用同时运行新系统和 旧系统，这就是并行方式。
优点： 旧系统
① 能对系统进行全面测试，减少了新系统风险； ② 给用户熟悉新系统的时间。
缺点：
新系统 双系统要投入更多的人力财力。
工学二部计算机教研室
（3）逐步方式
分期，分部分地交付使用 克服了上面两种方式的缺点，既能防止直接转换 产生的危险性，又能减少并行方式的费用 必须考虑好新旧系统的配合问题和接口问题
工学二部计算机教研室在没有使用就解决一个 重要问题时的样子工学二部计算机教研室
向服务器上传文件时的样子
工学二部计算机教研室
当你发现上周五还非常好用， 到了周一却不能运行时的样子
工学二部计算机教研室
当所有人都在办公室挥汗如雨的加班 而你却能安然的回家度周末时的样子
工学二部计算机教研室
当听到老板说项目如果能如期完工 将会有一笔奖金时的样子
工学二部计算机教研室
文档 重构
代码 重构
逆向 工程
六、软件再工程过程
正向 工程 数据 重构 库存 目录 分析
恢复设计结果的过
文档 重构
程，从程序代码中
抽取数据结构、体
代码 重构
逆向 工程
系结构和处理过程
的设计信息。
工学二部计算机教研室
六、软件再工程过程
正向 工程 数据 分析源代码，标注 重构 库存 目录 分析
工学二部计算机教研室
（3）可修改性
与设计时采用的原则和策略相关。（耦合、内聚、
控制域和作用域、局部化程度）
（4）可移植性
（5）可重用性 决定软件可维护性的最终因素是软件设计阶段所采用

维护申请
维护决策机构
维护管理员
系统管理员
配置管理员
维护人员
每个维护申请通过维护管理员转告给系统管理员，系
统管理员一般都是对程序(某一部分)特别熟悉的技术人
员，他们对维护申请及可能引起的软件修改进行评估，
并向修改控制决策机构(一个或一组管理者)报告，由它
最后确定是否采取行动。
30
维护团队组织
31
维护报告MRF
18
软件维护的代价高昂
有形代价逐年上升： ➢1970年软件维护费用占总费用的35%——40%； ➢1980年软件维护费用占总费用的40%——60%； ➢1990年软件维护费用占总费用的70%——80%。
19
软件维护的代价高昂
• 维护费用只不过是软件维护最明显的代价，其他 一些还不明显的代价将来可能更为人们关注。其 他无形的代价还有：
• 在拟定进一步维护计划前，把软件修改报告提 交控制决策机构审查批准。
34
软件修改报告(SCR)
软件名称 源程序名称 相关文档列表
维护描述： 日期
备份程序名称
修改内容
修改原因
特别说明
增加代码行数 注释修改 修改开始日期
删除代码行数
修改代码行数
相关文档修改 修改完成日期
维护人
35
维护请求
其他
类型
改正性
7
适应性维护
• 在使用过程中，
– 外部环境（新的硬、软件配置） – 数据环境（数据库、数据格式、数据输入/
输出方式、数据存储介质）
可能发生变化。 • 为使软件适应这种变化，而去修改软件
的过程就叫做适应性维护。
8
完善性维护
• 在软件的使用过程中，用户往往会对软 件提出新的功能与性能要求。