第八章 软件维护

1. 第八章软件维护 8.1 软件维护的概念 8.2 软件维护的特点 8.3 软件维护的过程 8.4 软件的可维护性

2. 8.1软件维护的概念 软件维护是软件生存周期的最后一个阶段,不属于系统开发的过程。 满足用户对已开发产品的性能与运行环境不断提高的要求，进而 达到延长软件寿命的目的。 改正性 对程序使用期间发现的程序错误进行诊断和改正的过程； 适应性 配合变化了的环境进行修改软件的活动； 满足用户在使用过程中提出增加新的功能或修改已有 功能的建议而进行的工作； 完善性 预防性 为了改善未来的可维护性或可靠性而修改软件的工作。 软件维护的工作量非常大，不同应用领 域的维护成本差别也很大。一般大型软件 的维护成本平均高达开发成本的四倍左右。 改正性 17—21% 适应性 18—25% 完善性 50—66% 预防性 4%左右 软件的易维护性是软件开发过程中每个步骤的一个关键目标。维护费用占软件总支 出的20-30%到70-80%。而无形的代价更是无法估计的。

3. 软件 代码 配置 计划途径 ？ 修改设计 修改程序 修改程序 复查 复查 维护后软 件与记录 8.2 维护的特点(1) 一. 维护方式 维护要求 结构化维护 非结构化维护 每个阶段文档与程序代码 仅有程序代码 评价设计文档开始 评价代码开始 评价设计 评价代码 (1)确定软件的结构特征、 性能特性和接口特性， (2)确定软件修改带来的影 响，找出一种处理方法； (3)修改设计、复审； (4)再编写源程序代码，进行 回归测试； (5)将修改后的软件交付使用 软件结构、 全程数据结构、 系统接口、性 能要求、设计 约束等具体特 点不清楚而很 难确定。 维护成本较低。 很高。 易于维护。 维护困难。

4. 8.2 维护的特点(2) 二.与软件维护有关的问题 开发方法 开发条件 软件开发及维护人员的水平； (1)模块化详细设计文档有助于理解软件的结 构、界面功能和内部流程； 使用标准的程序设计语言； (2)开发过程中严格而科学的管理规划及清晰 可靠的文档资料对发生错误后的理解与纠 错无疑是很重要的。 使用标准的操作系统接口； 使用规范化的文档资料； (3)模块的独立程度对软件修改的难易程度、 改进和移植影响是很大的。 测试用例的有效性。 理解 别人写的程序在没有说明文档时，理解很困难，不为人喜欢； 时间 维护持续时间都很长，开发人员一般不在现场，对软件没有人说明。 设计 问题 绝大多数软件在设计时都没有考虑将来的修改。除非设计中强调了 模块的独立性，否则软件的修改既困难又易发生差错。 软件维护工作量模型：M=P+Kc-d；M：总工作量；P：评价、修改设计和编写代码等 工作量；K：经验常数；c：系统复杂程度；d：维护人员对软件的熟悉程度。

5. 8.3 维护的过程(1) 一.建立软件维护的组织,在组织中有总负责人、系统管理员和维护管理员等。 二.编写维护的报告 用标准化的格式表达所有软件维护的要求。要求包括下列内容： 1.满足维护要求表中提出的要求所需要的工作量； 2.维护要求的性质； 3.该项要求的优先顺序； 4.与修改有关的事后数据。 三.为每一个维护要求规定一个标准化的事件序列(见下页图形) 1.明确维护的类型:纠错性维护,进一步分清是适应性维护还是完善性维护； 2.对纠错性维护从评价错误的严重性开始,分别不同程度采取不同的方法； 3.适应性维护和完善性维护沿着同一路径推进，确定优先顺序后开始工作； 4.对恶性软件故障，应把所有的资源用来解决问题； 5.对任何类型的维护都要进行同样的技术工作，包括：修改软件设计、设计 复审、必要的代码修改、单元测试、集成测试、验收测试和复审等。

6. 不严重 纠错项目表 测试 严重 纠错 分配的人员 复审后供使用 的软件配置 维护要求 已修改配置 适应 分配的人员 完善 高 已修改软件 低 开发项目表 8.3 维护的过程(2) 维护事件序列图 计划改 正进度 严重性 评价 问题 分析 区分 类型 维护 任务 配置 复审 + + 优先度 评价 问题 分析

7. 8.3 维护的过程(3) 程序标识； 因程序变动而删除的源语句数； 源语句数； 每个改动所耗费的人时数； 机器指令条数； 程序改动的日期； 使用的程序设计语言； 软件工程师的名字； 程序安装的日期； 维护要求表的标识； 自从安装以来程序运行的次数； 维护类型； 自从安装以来程序失败的次数； 维护开始和完成的日期； 程序变动的层次和标识； 累计用于维护的人时数； 因程序变动而增加的源语句数； 与完成的维护相联系的纯效益。 每次程序运行平均失效的次数； 用于同一类维护活动的总人时数； 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； 不同维护类型所占的时间比。 增加或删除一个源语句平均花费的人时数 平均每个程序、每种语言、每种维护类型所做的程序变动数；

8. 8.4 可维护性(1) 决定软件可维护性的因素 软件的结构、接口、功能和内部过程的难易程度； 模块化、详细设计文档、结构化设计、源代码内部的文档； 程序设计语言。 诊断和测试的难易程度取决于软件容易理解的程度； 良好的文档对诊断和测试是至关重要的诊断和测试； 软件结构、可用的测试工具和调试工具，以往的测试过程是很重要的； 在设计阶段应尽力把软件设计成容易诊断和测试的。 与设计原理、规则直接相关； 与藕合、内聚、局部化、控制域、作用域等等都有关系。

9. 8.4 可维护性(2) 与可维护性相关的文档 如何使用这个系统； 怎样安装和管理这个系统； 系统需求和设计； 系统的实现和测试。 功能描述:说明系统能做什么； 安装文档:说明怎样安装该系统及使系统适应特定的硬件配置； 使用手册:简要说明如何使用这个系统； 参考手册：详尽描述用户可以使用的系统设施及方法，以及可能产 生的出错信息含义； 操作员指南：说明操作员如何处理使用中出现的各种情况。 从问题定义、需求说明到验收测试这样一系列和系统实现有关的文档。

10. 第八章 小 结 一.软件维护是软件生存周期的最后一个阶段，也是持续时间最长、 代价最大的一个阶段。 二.软件维护包括四类活动：改正性维护、适应性维护、完善性维 护和预防性维护。 三.软件的可理解性、可测试性和可维修性是决定软件可维护性的 基本因素。 四.软件生存周期的每个阶段和软件可维护性密切相关。 五.文档是影响软件可维护性的决定因素。 六.文档分为用户文档和系统文档，它们都必须和程序代码同时维 护才有真正的价值。

11. 第八章 习 题 1.为什么说软件的维护是不可避免的？ 2.软件的维护一般分为哪几类？ 3.影响软件维护的因素有哪些？ 4.软件维护困难主要表现在什么方面？ 5.决定软件可维护性的因素？ 6.软件价格应该计入维护成本吗？为什么？ 7.对前面各章中分析的各应用系统，提出改进和扩充功能的要求？ (1)教材销售采购系统； (2)图书管理系统； (3)房产管理系统。

12. 第九章软件工程管理 9.1 软件项目的特点和管理的职能 9.2 成本估算 9.3 人员的分配和组织 9.4 进度安排 9.5 质量保证 9.6 项目计划 9.7 软件管理工具

13. 100% 工 作 量 技术工作 50% 管理工作 软件规模 9.1 软件项目特点和管理的职能(1) 技术和管理是软件生产中不可缺少的两个方面，对技术而言， 管理意味着决策和支持。只有对生产过程进行科学的估量，作 到技术落实、组织落实和费用落实，才能达到提高生产率，改 善产品质量的目的。因此软件工程管理也是软件工程学中研究 的领域之一。 软件项目的规模越大，所需要 的管理支持工作量越大。统计资料 表明在软件项目的规模达到一定程 度时，所需的软件管理工作量将达 到总工作量的一半。如图所示： 软件项目的规模,决定了采用怎样 的管理水平、开发工具和开发方法。

14. 9.1 软件项目特点和管理的职能(2) 一.软件项目的特点 1.软件项目与其他任何产业项目不同，它是算法、思想、概念、 组织、流程、效率、优化等的融合体； 2.开发软件项目产品,在多数情况下,用户给不出明确的想法和要 求。 3.在开发过程中，程序及其相关的文档资料常常需要修改，在修 改过程中又可能带来新的问题，且这些问题要在很久以后才会 发现。 4.在研制开发过程中，文档资料是不可缺少的，但工作量又是巨 大的,往往也是人们不愿去作的。 5.参加软件项目的工作人员，要求具有一定的业务水平和实际工 作经验，而很难完全避免的人员流动，对工作的影响是很大的。 离开的人员不仅带走了重要的信息，而且带走了工作经验。

15. 9.1 软件项目特点和管理的职能(3) 二.软件项目管理的特殊困难 1.智力密集,可见性差,对没有软件知识和软件开发实践经验的人 员很难做好管理工作。 2.特定的开发环境,加上特定的开发方法、工具和语言。建立在这 种内容、形式各异基础上的研制或生产方式，与其他领域大规 模现代化生产的管理区别很大，给管理造成的实际困难也更多。 3.劳动密集、自动化程度低，加之软件本身的复杂性，各种错误 难以避免，为确保软件质量，给管理提出了更高的要求。 4.使用方法繁琐，维护困难。 5.对从事软件项目开发工作的人员,不仅需要一定的技术水平和工 作经验,而且要求具有良好的心理素质。因此对软件人员的管理 是一个不可忽视的问题。

16. 9.1 软件项目特点和管理的职能(4) 三.软件管理的职能 1.管理的目的:按照工程预定的时间和费用,成功地完成软件的计划、开 发和维护任务。管理贯穿整个软件生存周期。 2.管理的内容 (1)费用管理:对软件开发进行成本核算,使软件生产按照商品生产的规 律办事。包括:以简单、科学方法估算软件开发费用,作为签定开发 合同的根据；管理开发费用的有效使用,即用经济手段来保证产品 如期按质完成。 (2)质量管理:按项目的质量保证计划,确保各个开发阶段的开发和维护 工作全部按软件工程的规范进行,保证软件产品的质量。 (3)配置管理:通过对于程序、文档和数据的各种版本所进行的管理， 保证资料的完整性与一致性。 (4)项目管理：制定《项目实施计划》，按照计划的内容组织和实施软 件的工程化生产。最终目标是以合理的费用和进度，圆满完成计划 所规定的软件项目。

17. 9.2 成本估算(1) 一.成本估算的方法 首先估算出项目总的开发成本，然后在项目内部进行成本分配。由少数专家参与，依靠他们过去的经验，将要开发的软件与过去开发过的软件进行“类比”，以估计新的软件开发所需要的工作量和成本。 一般对开发中的某些局部问题或特殊困难容易低估,甚至没有考虑到。如果所开发的软件缺乏可以借鉴的经验,在估计时就可能出现较大的误差。 将开发任务分成若干子任务,子任务又分成子子任务,直到每一个单元内容足够明确为止；把各个任务单元的成本估计出来,汇合成项目的总成本。 该方法得到的结果比较接近实际。 具体工作人员只主意到自己范围内的工作,对综合测试、质量管理和项目管理等涉及全局的花费可能估计不足，甚至完全忽视。因此可能使成本估计偏低。 一般将上述两种方法结合使用。此外可采用系统的“分类活动结构图”(简称WBS)有效地避免在估计中遗漏任务。例下页的CAD系统产品的两种WBS图。

18. CAD系统产品 系统输入 图形设计 图形输出 用户接口 控制 数据结构 管理 二维图 分析 三维图 分析 设计 分析 图形 显示 外部设备 控制 CAD系统开发过程 项目计划 项目开发 系统测试 项目管理 需求 分析 设计 编码与 单元测试 综合 测试 确认 测试 质量 保证 进度 安排 9.2 成本估算(2) CAD系统产品的WBS图 CAD系统开发过程的WBS图

19. 9.2 成本估算(3) 二.估算中通常采用的技术 1.任务分解技术:估计完成该项任务需要的人力(以人月为单位),再乘以每 人每月的平均支付金额确定软件成本。 2.代码行技术:用每行代码的平均成本乘以行数确定软件成本； 利用任务分解技术例子 利用代码行技术例子 3.算法模型(略)

20. 人力 T 0 Td 9.3 人员的分配和组织(1) 一个软件项目在生命周期的各个不同阶段所需要的人员的类型及其数量是不相同的。 如：计划与分析阶段只需要很少的人，概要设计需要的人略多一些，详细设计又多一 些，到了编码和测试阶段所需人数最多。在运行初期，需要较多的人参加维护，但很 快就可减少下来。如何按照实际需要来确定各阶段所需的人力？有无规律可循？如何 组织？是软件开发中必须解决好的问题。 一.Rayleigh-Norden 曲线(右图) 横坐标：T(时间)；纵坐标:人力； 1.曲线方程： 人力=(K/Td)×eS×(T/Td) 其中 s=－0.5 ×(T/Td)2； Td:曲线达到峰点的时间； K：软件生存周期总工作量； (1)在Td之前，单位时间开发所需的人力逐渐上升； (2)在Td达到峰值，单位时间开发所需的人力达到最大值； (3)在Td之后，单位时间所需的人力逐渐下降。 (4)Td两侧的比为4：6，即计划与开发所需的工作量约占生存期总工作量的40%， 而维护工作量约占生存期总工作量的60%。

21. 9.3 人员的分配和组织(2) 2.软件开发的权衡定律 E=常数/ (T或Td)4 即开发工作量与开发时间的4次方成反比。 例.某软件两种开发时间的比较: 即两年可以完成的工作量25个人年,若将开发时间压缩为1.84人年 (时间缩短不到1/10),而工作量将增至35个人年(增长率达40%)。 3.Brooks定律(时间与人员不能互换原则) 大量软件开发实践说明:向一个已经延迟的项目追加开发人员,可能 使它完成得更晚。当开发人员以算术级数增长时，人员之间的通信将 以几何级数增长，往往“得不偿失”。

22. 9.3 人员的分配和组织(3) 二.人员组织 软件经理 负责管理软件开发部门,在各个项目之间分配和协调各种资源。 项目经理 管理一个具体的的开发项目的各个方面(计划、进度、审查、复查、用户界面等)，领导1—6个程序设计小组。 任 务 每个小组(2—8人)负责项目的一部分开发工作。 程序设计小组 非正式的组织形式，组长和成员完成同样的任务。多数成员经验丰富、技术熟练的程序员. 开发小组 组织形式 主程序员：全面负责系统的设计、编码、测试和安装 辅助程序员:协助主程序员工作。主要任务是设计测试 方案和分析测试结果，以验证主程序员的工作。 程序管理员:完成和项目有关的全部事务工作。 主程序员小组 审查小组 从事质量保证活动，在项目开发的每个阶段(软件生存周期)结束之前,进行技术审查和管理复审。

23. 设计 4 文档 2 分析 3 编码 4 终点 起点 测试 数据2 测试 计划2 产品 测试4 测试 软件6 9.4 进度安排(1) 一.计划评审技术(Program Evaluation and Review Technique简称PERT技术) 1.建立PERT图 例.一个简单软件开发项目的PERT图。图中的每一个圆框代表一项开发活动。 框内的数字表示完成这一活动所需的时间(该例单位:月)，框间的前头 代表活动发生的先后顺序。

24. (3,7) (7,9) 设计 4 文档 2 (0,3) (7,11) 分析 3 编码 4 (15,15) (0,0) (3,5) 终点 起点 测试 数据2 (0,2) (11,15) 测试 计划2 产品 测试4 (2,8) 测试 软件6 9.4 进度安排(2) 2.找出关键路径 从起点到终点,在每个活动框的上方标出该项活动的起止时间,如图。 其中需时最长的路径为关键路径。此例中需时最长15个月，关键路径如 图紫色双前头表示。

25. (3,7) (7,9) 设计 4 文档 2 (0,3) (7,11) 分析 3 编码 4 (15,15) (0,0) (3,5) 终点 起点 测试 数据2 (0,2) (11,15) 测试 计划2 产品 测试4 (2,8) 测试 软件6 9.4 进度安排(3) 3.标出每个活动最迟开始时间 从终动到起点,在每个活动框的下方标出该项活动最迟起止时间。 如图所示。 (13,15) (3,7) (0,3) (7,11) (15,15) (0,0) (9,11) (3,5) (11,15) (5,11)

26. 设计 ③ 文档 2 分析 3 编码 ② 终点 起点 测试 数据2 测试 计划2 产品 测试4 测试 软件6 9.4 进度安排(4) 4.PERT图的使用 (1)确保关键路径上的各项活动按时完成。 (2)通过缩短关键路径上某些活动的时间，达到缩短项目开发的目的。 如图把设计时间从4个月缩短为3个月,编码从4个月缩短为2个月,项目开发时间 从原来的15个月缩短为12个月。此时REPT图中出现两条关键路径。对不在关键路 径上的活动，可根据需要调整起止时机，或者延缓活动的进度。 (3,6) (6,8) (0,3) (6,8) (12,12) (3,5) (0,0) (0,2) (8,12) (2,8)

27. ▲ ▲ ▲ △ ▲ △ △ △ △ △ △ △ △ △ △ △ 9.4 进度安排(5) 二.Gantt图 1.Gantt图是安排软件进度计划的又一种工具。如图： 图的左边列出项目的开发活动,上方列出日历时间。在每一活动的开始和结束时 间各画一个三角形，当活动的开始和结束时候，把三角形涂实。 2.Gantt图优点：简单易用，容易修改，比PERT图更加直观方便。 3.Gantt图缺点：不能显示各项活动之间的依赖关系。 注△：活动开始和结束；▲：活动已开始和结束；SE系统工程师；VV质量保证人员；PG 程序员

28. 产品 修改 产品 转移 产品运行 9.5 质量保证(1) 一.软件质量 1.软件质量含义 (1)软件与明确指定的功能和性能需求的一致性； (2)软件与明确指定的文档开发标准的一致性； (3)软件与未明确指定的，但为全部软件所期望的隐含特性的一致性。 2.影响软件质量的因素:产品运行、产品修改、产品转移。 可理解性(能理解吗?) 可维护性(能修复吗?) 灵 活 性(能改变吗?) 可测试性(能测试吗?) 可移植性(能在另外机器上使用吗?) 可重用性(能再用它的某些部分吗?) 互运行性(它能和另一系统结合吗?) 正确性(能按需要工作吗?) 风险(按计划能完成吗?) 效率(完成预定工作需要计算机资源多吗?) 完整性(安全吗?) 健壮性(对意外环境能作响应吗?) 可用性(能使用它吗?)

29. 9.5 质量保证(2) 二.软件质量保证措施 1.软件质量保证的含义 (1)它是为检验软件产品是否满足需求而采取的一系列有组织、有计划、 规范化的活动； (2)它并不能保证软件的质量,而是保证履行一系列检验软件质量的活动； (3)它只能发现或诊断软件故障,而纠正错误则是系统维护解决的问题； (4)它工作贯穿软件开发的各个阶段。 (5)它需要独立的工作小组,但与开发人员和用户有关。 2.措施:评审、测试。 三.软件评审 1.软件评审的目标。 2.软件评审的准则。 3.评审的步骤：计划；概貌介绍；准备；评审会；返工；复查。 四.测试

30. 9.6 项目计划(1) 一.项目计划的内容 概述 一般性叙述开发的项目,描述计划组织,并简述文档其余部分内容。 阶段 详细说明开发周期各个阶段应完成的日期及不同阶段的重叠时间。 组织 规定从事这个开发项目的每个小组的具体责任。 测试 概述测试所需的工具，及完成系统测试的过程和分工。 变动控制 确定在系统开发过程中需求变动的管理控制机制。 文档 定义与管理与项目有关部分的文档。 培训 培训从事开发的程序员和使用系统的用户计划。 复审和报告 讨论如何报告项目的状况，并确定对项目进展情况进行正式复审的计划。 安装和运行 描述在用户现场安装该系统的过程。 资源和配置 概述关键的细节计划—进度、阶段目标和按合同规定应交付的系统配置成分。 索引

31. 9.6 项目计划(2) 二.项目报告 1.报告内容：在这段时间内已经完成的工作；下阶段计划要完成的工作； 问题范围；到目前为止已经用掉的成本；预算执行情况及其它有关信息。 2.制定项目计划时，应确立一系列阶段目标。在应该完成的每个阶段目标 时(或定期时间)，开发人员应该把正式的进展报告交给管理人员。 三.变动控制 1.任何软件开发都是迭代过程,即在设计软件时会发现需求说明的中问题, 在实现过程中又会暴露出设计中的错误。预先计划控制变动的机制,建 立评价变动的影响和把发生的变动记录下来的过程是十分重要的。 2.变动通常分为两类： (1)为了改正小错误需要的变动。 (2)为了增加和删除某些功能，或者为了改变某个功能的方法而变动的 变动。 3.高级管理人员应该注意防止在工程延期或成本超过预算时,下级管理人 员为勉强按原计划进行而降低质量要求的倾向。

32. 9.7 软件管理工具 一.软件管理工具种类 1.计划工具:主要功能包括完成成本计算,关键路径的分析等,以协助管理人员 制定工程项目计划。 2.报告工具：主要功能是检索文档资料，并产生某种标准形式的报告。 二.软件管理工具 1.EPRT(计划评审技术)软件包:通用的项目管理工具,主要用于分析关键路径。 2.成本估算工具:根据给出的项目详细情况的数据之后,及历史数据,估算出完 成需要的工作量,估算出成本。一般该类工具是各个软件开发组织专用的。 3.项目管理系统：主要完成记录项目复审日期和预算；检索软件规格说明书、 软件设计和程序代码，编辑成相关的报告。 4.故障报告系统：主要完成收集和整理出错情况报告；管理变动报告及其相 应的有关文档的修改。

33. 第九章 小 结 一.软件工程管理是软件工程的重要组成部分。只有进行科学的管理， 才能使先进的技术发挥充分的作用。对于大型的软件开发，管理 工作尤其重要。 二.项目管理是整个管理工作的基础，明确项目管理的智能。 三.了解项目管理的特点。 四.管理工作离不开度量。估计成本的各种方法、计算人力需求的变化 曲线、计算进度的PERT技术和进度计划表，都是标志对软件管理从 定性管理向定量管理的发展趋势。 五.软件的质量保证是贯穿于整个生存周期的重要的活动。 六.影响软件质量的因素是多方面的，可靠性在质量特性中占有主要的 地位。

34. 第九章 习 题 1.软件工程管理的内容？ 2.软件项目有哪些特点？ 3.软件成本估算的一般方法？ 4.为什么在软件开发中，不能用简单增加人员的方法来缩短开发时间？ 5.影响软件质量的主要因素有哪些？ 6.本章第四节的例子是某个软件项目的PERT图。 (1)找出关键路径和完成项目的最早时间； (2)标出每项活动的最早起止时间与最迟起止时间。 7.将上题的内容改用Gantt图来表示。