第7章-软件维护与项目管理
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
预防性维护是：
为了改进软件可维护性、可靠性；
为了适应未来软硬件环境变化； 主动增加预防性的新功能，使得软件不 因各种变化而被淘汰。
8
各种维护所占比例:
适应性维护 18%~25% 改正性维护 17%~21%
其它维护 4%
扩充与完善性维护 50% ～ 60%
9
10
7.1.2 软件的可维护性
27
软件维护过程
为了有效地进行软件维护，应事先就开始做组 织工作： 首先建立一个维护组织； 申明提出维护申请报告的过程及评价的过程； 为每一个维护申请规定标准的处理步骤； 建立一个适用于维护活动的记录保管过程； 规定复审标准。
28
三、结构化维护与非结构化 维护差别巨大
非结构化维护： 只有程序代码，没有设计文档及测试文档， 维护活动从艰苦地评价程序代码开始。 需要付出很大代价，是没有使用良好的软件 工程方法学开发出来的软件的必然结果。
6
③完善性维护（ 50%~60% ）
在软件的使用过程中，用户往往会对软件提出 新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件， 以扩充软件功能、增强软件性能、改进加工效 率、提高软件的可维护性。 这种情况下进行的维护活动叫做扩充与完善性
维护。
7
④ 预防性维护（4%左右）
12
7个特性在各类维护中的侧重点
13
二、可维护性的度量
度量一个可维护性软件的七种特性常用方法： 质量检查表： 是用于测试程序中某些质量特性是否存在 的一个问题清单。 质量测试和质量标准： 用于定量分析和评价程序的质量。由于许 多质量特性是相互抵触的，要考虑几种不 同的度量标准。
14
三、提高可维护性的方法
19
维护审批制度
维护申请 主管部门 维护管理员
系统管理员
20
2. 软件维护报告
用户填写维护申请单交给维护组织，经有关人员 认真分析后，根据分析结果制定软件维护报告， 主要包括以下内容： ①维护要求的性质 ②维护活动的优先顺序 ③计算满足维护申请表中提出的软件变更所需要 的工作量 ④预计软件变更后的情况
23
维护的技术工作
不同类型的维护申请，都要进行同样的技术工作： 修改软件需求说明
修改软件设计
设计评审 对源程序做必要的修改
单元测试
集成测试( 回归测试) 确认测试 软件配置评审等
24
维护完成后的总结
每次软件维护任务完成后进行情况评审，对以 下问题做总结： (1) 在目前情况下，设计、编码、测试中的哪 一方面可以改进?
34
七、文 档
文档是影响软件可维护性的决定因素。往往文 档比程序代码更重要。 软件系统的文档可以分为两大类如下：
用户文档：主要描述系统功能和使用方 法，并不关心这些功能是怎样实现的； 系统文档：描述系统设计、实现和测试 等各方面的内容。
35
用户文档
用户文档主要包括： 用户手册 操作手册 维护修改意见 软件需求规格说明书 上述内容可以分别作为独立的文档，也可以 作为一个文档的不同分册，具体做法应该由 系统规模决定。
（1）建立明确的软件质量目标和优先级 相互捉进的特性： 可理解性和可测试性； 可理解性和可修改性。 相互抵触的特性： 效率和可移植性；效率和可修改性。 各特性的相对重要性应随着程序的用途不同、 计算环境的不同而不同。
15
提高可维护性的方法（续）
（2）利用先进的软件开发技术和工具 面向对象软件开发方法——软件系统稳定性好、 易修改、易理解、易测试，可维护性好。 （3）建立明确的质量保证 质量保证——为提高软件质量所做的各种检查 工作。 非常有用的四类检查：在检查点进行检查、验 收检查、周期性地维护检查、对软件包的检查。
32
五、影响维护工作量的因素
系统大小 程序设计语言：强功能，模块化，结构化 系统年龄：维护人员常换，文档缺少，文档与 程序不一致 数据库技术的应用： 先进的软件开发技术：面向对象、复用技术 其它：应用类型，数学模型，任务难度，开关 与标记、IF嵌套深度、索引或下标数等 许多软件在开发时并未考虑将来的修改，为软 件的维护带来许多问题。
一、软件维护的主要任务 二、软件维护的阶段 三、软件维护的主要问题
18
一、软件维护的主要任务：
软件维护主要任 务包括两点： 1. 维护组织机构
2.软件维护报告
1. 维护组织机构 对大型软件系统：建立专门的维护组织机构。 对较小软件系统：委派专人负责软件维护工作。 维护活动开始之前，必须明确维护活动的审批制 度。审批制度如下页表：
36
用户文档
用户文档至少应该包括下述5方面的内容： (1) 功能描述——系统能做什么； (2) 安装文档——如何安装系统，配置硬件； (3) 使用手册——如何使用系统（例子），出错 时如何恢复、重启系统； (4) 参考手册——详尽描述所有系统设施的使用 方法，解释可能产生的错误信息的含义； (5) 操作员指南——说明操作员如何处理系统使 用中出现的各种问题。
16
提高可维护性的方法（续）
（4）选择可维护的程序设计语言 低级语言：难掌握、难理解、难维护。 高级语言：易理解、易掌握。 第四代语言：更易理解、易编程、易修改、 易维护。 （5）改进程序的文档 程序文档对提高程序的可阅读性有重要意 义。 （6）开发软件时考虑到维护
17
7.1.3 软件维护的实施
42
软件再工程过程模型
软件再工程是一类软 件工程活动，是一个
40
41
7.2 软件再工程
再工程是一个重构活动（类比 重建一所房子） 开始重建前，首先检查一下房子。确定它是否确实需 要重建？ 在拆掉并重建房子前，确定其结构是否牢固。若结构 良好，则可能是“改造”。 开始重建前，确保已经了解房子最初是如何建造的。 （墙内部，了解布线、管道以及内部结构。） 如果开始重建，应该使用最现代的，耐久的材料。 如果决定重建，一定要采用严格的方式，使用现在及 将来都将获得高质量的做法。
26
⑽ 因程序变动而删除的 源语句数； ⑾ 每个改动 耗费的人时数； ⑿ 程序 改动的日期； ⒀ 软件工 程师的名字； ⒁ 维护要 求表的标识； ⒂ 维护类 型； ⒃ 维护开始和完成 的日期； ⒄ 累计用于维 护的人时数； ⒅ 与完成 的维护相联系的纯效益。
26
二、软件维护6个阶段
①软件维护的准备和过度活动：维护计划的构思 与创建，后续的产品配置管理。 ②问题与修改分析阶段：维护人员分析每个请求， 确认并验证其有效性，调查、提出、记录解决 方案，获得软件修改的授权。 ③实施修改阶段。 ④接受修改阶段：由用户检查所做的修改是否解 决了相应的问题。 ⑤迁移阶段：软件被迁移到另一个平台。 ⑥对软件某一部分的弃用。
7.1 软件维护
7.1.1 软件维护概述
7.1.2 软件的可维护性
7.1.3 软件维护的实施
3
7.1.1 软件维护概述
软件维护 ---- 在软件交付使用后，根据需求 变化或硬件环境变化对应用程序进行部分或 全部修改。修改时要充分利用源程序，修改 后要填写程序登记表，并在程序变更通知书 上写明新旧程序的不同之处。 维护的类型有四种： 正确性维护 适应性维护
5
②适应性维护（ 18%~25% ）
在使用过程中，有以下变化： 外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数据输入/ 输出方式、数据存储介质） 企业的外部市场环境、管理需求 为使软件适应这种变化，而去修改软件的过程 就叫做适应性维护。 要有计划、有步骤的进行。
第7章 软件维护与 项目管理
普通人轻视软件维护工作，
会失掉极其宝贵的机会； 维护人员轻视软件维护工作， 会失掉本应精彩的人生； 老板轻视软件维护工作， 会丢掉大片本来属于自己的市场……
第7章 软件维护 与项目管理
7.1 7.2 7.3 7.4 7.5 7.6 软件维护 软件再工程 项目管理 项目度量 风险分析 小结
22
2. 软件维护报告
维护申请报告将由维护管理员和系统管理员研究 处理后，做出软件修改报告，指明：
所需修改变动的性质； 申请修改的优先级； 为满足维护申请报告所需的工作量； 预计修改后的状况。
软件修改报告应提交给变化授权人/修改负责 人），经批准后才能开始进一步安排维护工作。
33
Hale Waihona Puke Baidu
六、维护中的典型问题
(1) 难以跟踪软件版本的进化过程，软件的变化未 在文档中反映出来。 (2)难以读懂他人程序。 (3)无文档或不全。 (4)软件人员流动性大。 (5) 设计时未考虑修改需要,修改困难
(6) 维护工作无吸引力,缺乏成就感
采用软件工程方法至少可部分解决与维护有关 的每一个问题。
软件维护活动所花费的工作占整个生存期工作 量的70%以上。 软件维护代价极高，既破财，又伤神； 有形代价：投入的人力物力。 无形代价：影响更大。
31
维护的无形影响：
可用的资源必须供维护任务使用，以致耽误甚 至丧失了开发的良机。 改错或修改的不及时，引起的用户不满； 由于维护时的改动，在软件中引入了潜伏的错 误，从而降低了软件的质量； 把软件开发人员抽调到维护工作中，干扰了软 件开发工作。 生产率的大幅度下降，尤其在维护旧程序时常 常遇到。
29
三、结构化维护与非结构化 维护差别巨大
结构化维护： 有一个完整的软件配置，维护工作从评价设计 文档开始； 估计改动将带来的影响，计划实施途径； 修改设计文档，并且复审； 编写相应的源程序代码； 使用在测试说明书中包含的信息进行回归测试； 把修改后的软件再次交付使用。
30
四、维护的代价高昂
37
开发文档
开发文档 软件需求规格说明书 数据要求说明书 概要设计说明书 详细设计说明书 可行性研究报告 项目开发计划
38
管理文档
管理文档 测试计划 测试报告 开发进度月报 开发总结报告
39
系统文档
系统文档：指从问题定义、需求说明到验收测 试计划这样一系列和系统实现有关的文档。 描述系统设计、实现和测试的文档对于理解程 序和维护程序来说是极端重要的。 和用户文档类似，系统文档的结构也应该能把 读者从对系统概貌的了解，引导到对系统每个 方面每个特点的更形式化更具体的认识。
完善性维护
预防性维护
4
①正确性维护（改正性维护）
改正软件中存在的错误。占整个维护工作量的 17%~21%。 在软件交付使用后，由于开发时测试得不彻底 或不完全，在运行阶段会暴露一些开发时未能 测试出来的错误。为了识别和纠正软件错误， 改正软件性能上的缺陷，避免实施中的错误使 用，应当进行的诊断和改正错误的过程，这就 是改正性维护。
21
2. 软件维护报告
用标准化的格式表达所有软件维护申请（要求）。 维护申请报告/软件问题报告，由申请维护的用 户填写。 用户必须完整地说明产生错误的情况，包括输入 数据、错误清单以及其它有关材料。 如果申请的是适应性维护或完善性维护，用户必 须提出一份修改说明书，列出所有希望的修改。
软件的维护十分困难，原因在于这些软件的文 档不全、质量差、开发过程不注意采用好的方 法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。
11
一、软件可维护性的定义
软件可维护性定义： 软件能够被理解、校正、适应及增强功能的难 易程度。 软件可维护性可以用7个质量特性来衡量： 可理解性，可测试性，可修改性，可靠性， 可移植性，可使用性，效率
(2) 哪些维护资源应该有但没有?
(3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性 维护? 情况评审对将来的维护工作如何进行会产生重 要的影响。
25
维护档案记录
①程序标识； ②源语句 数； ③机器指令条数； ④使用的程序设计语言； ⑤程序安装的日期； ⑥ 自从安装以来程序运行的 次数； ⑦自从安装以来 程序失效的次数； ⑧程 序变动的层次和标识； ⑨因程序变动而增加的源 语句数；
为了改进软件可维护性、可靠性；
为了适应未来软硬件环境变化； 主动增加预防性的新功能，使得软件不 因各种变化而被淘汰。
8
各种维护所占比例:
适应性维护 18%~25% 改正性维护 17%~21%
其它维护 4%
扩充与完善性维护 50% ～ 60%
9
10
7.1.2 软件的可维护性
27
软件维护过程
为了有效地进行软件维护，应事先就开始做组 织工作： 首先建立一个维护组织； 申明提出维护申请报告的过程及评价的过程； 为每一个维护申请规定标准的处理步骤； 建立一个适用于维护活动的记录保管过程； 规定复审标准。
28
三、结构化维护与非结构化 维护差别巨大
非结构化维护： 只有程序代码，没有设计文档及测试文档， 维护活动从艰苦地评价程序代码开始。 需要付出很大代价，是没有使用良好的软件 工程方法学开发出来的软件的必然结果。
6
③完善性维护（ 50%~60% ）
在软件的使用过程中，用户往往会对软件提出 新的功能与性能要求。 为了满足这些要求，需要修改或再开发软件， 以扩充软件功能、增强软件性能、改进加工效 率、提高软件的可维护性。 这种情况下进行的维护活动叫做扩充与完善性
维护。
7
④ 预防性维护（4%左右）
12
7个特性在各类维护中的侧重点
13
二、可维护性的度量
度量一个可维护性软件的七种特性常用方法： 质量检查表： 是用于测试程序中某些质量特性是否存在 的一个问题清单。 质量测试和质量标准： 用于定量分析和评价程序的质量。由于许 多质量特性是相互抵触的，要考虑几种不 同的度量标准。
14
三、提高可维护性的方法
19
维护审批制度
维护申请 主管部门 维护管理员
系统管理员
20
2. 软件维护报告
用户填写维护申请单交给维护组织，经有关人员 认真分析后，根据分析结果制定软件维护报告， 主要包括以下内容： ①维护要求的性质 ②维护活动的优先顺序 ③计算满足维护申请表中提出的软件变更所需要 的工作量 ④预计软件变更后的情况
23
维护的技术工作
不同类型的维护申请，都要进行同样的技术工作： 修改软件需求说明
修改软件设计
设计评审 对源程序做必要的修改
单元测试
集成测试( 回归测试) 确认测试 软件配置评审等
24
维护完成后的总结
每次软件维护任务完成后进行情况评审，对以 下问题做总结： (1) 在目前情况下，设计、编码、测试中的哪 一方面可以改进?
34
七、文 档
文档是影响软件可维护性的决定因素。往往文 档比程序代码更重要。 软件系统的文档可以分为两大类如下：
用户文档：主要描述系统功能和使用方 法，并不关心这些功能是怎样实现的； 系统文档：描述系统设计、实现和测试 等各方面的内容。
35
用户文档
用户文档主要包括： 用户手册 操作手册 维护修改意见 软件需求规格说明书 上述内容可以分别作为独立的文档，也可以 作为一个文档的不同分册，具体做法应该由 系统规模决定。
（1）建立明确的软件质量目标和优先级 相互捉进的特性： 可理解性和可测试性； 可理解性和可修改性。 相互抵触的特性： 效率和可移植性；效率和可修改性。 各特性的相对重要性应随着程序的用途不同、 计算环境的不同而不同。
15
提高可维护性的方法（续）
（2）利用先进的软件开发技术和工具 面向对象软件开发方法——软件系统稳定性好、 易修改、易理解、易测试，可维护性好。 （3）建立明确的质量保证 质量保证——为提高软件质量所做的各种检查 工作。 非常有用的四类检查：在检查点进行检查、验 收检查、周期性地维护检查、对软件包的检查。
32
五、影响维护工作量的因素
系统大小 程序设计语言：强功能，模块化，结构化 系统年龄：维护人员常换，文档缺少，文档与 程序不一致 数据库技术的应用： 先进的软件开发技术：面向对象、复用技术 其它：应用类型，数学模型，任务难度，开关 与标记、IF嵌套深度、索引或下标数等 许多软件在开发时并未考虑将来的修改，为软 件的维护带来许多问题。
一、软件维护的主要任务 二、软件维护的阶段 三、软件维护的主要问题
18
一、软件维护的主要任务：
软件维护主要任 务包括两点： 1. 维护组织机构
2.软件维护报告
1. 维护组织机构 对大型软件系统：建立专门的维护组织机构。 对较小软件系统：委派专人负责软件维护工作。 维护活动开始之前，必须明确维护活动的审批制 度。审批制度如下页表：
36
用户文档
用户文档至少应该包括下述5方面的内容： (1) 功能描述——系统能做什么； (2) 安装文档——如何安装系统，配置硬件； (3) 使用手册——如何使用系统（例子），出错 时如何恢复、重启系统； (4) 参考手册——详尽描述所有系统设施的使用 方法，解释可能产生的错误信息的含义； (5) 操作员指南——说明操作员如何处理系统使 用中出现的各种问题。
16
提高可维护性的方法（续）
（4）选择可维护的程序设计语言 低级语言：难掌握、难理解、难维护。 高级语言：易理解、易掌握。 第四代语言：更易理解、易编程、易修改、 易维护。 （5）改进程序的文档 程序文档对提高程序的可阅读性有重要意 义。 （6）开发软件时考虑到维护
17
7.1.3 软件维护的实施
42
软件再工程过程模型
软件再工程是一类软 件工程活动，是一个
40
41
7.2 软件再工程
再工程是一个重构活动（类比 重建一所房子） 开始重建前，首先检查一下房子。确定它是否确实需 要重建？ 在拆掉并重建房子前，确定其结构是否牢固。若结构 良好，则可能是“改造”。 开始重建前，确保已经了解房子最初是如何建造的。 （墙内部，了解布线、管道以及内部结构。） 如果开始重建，应该使用最现代的，耐久的材料。 如果决定重建，一定要采用严格的方式，使用现在及 将来都将获得高质量的做法。
26
⑽ 因程序变动而删除的 源语句数； ⑾ 每个改动 耗费的人时数； ⑿ 程序 改动的日期； ⒀ 软件工 程师的名字； ⒁ 维护要 求表的标识； ⒂ 维护类 型； ⒃ 维护开始和完成 的日期； ⒄ 累计用于维 护的人时数； ⒅ 与完成 的维护相联系的纯效益。
26
二、软件维护6个阶段
①软件维护的准备和过度活动：维护计划的构思 与创建，后续的产品配置管理。 ②问题与修改分析阶段：维护人员分析每个请求， 确认并验证其有效性，调查、提出、记录解决 方案，获得软件修改的授权。 ③实施修改阶段。 ④接受修改阶段：由用户检查所做的修改是否解 决了相应的问题。 ⑤迁移阶段：软件被迁移到另一个平台。 ⑥对软件某一部分的弃用。
7.1 软件维护
7.1.1 软件维护概述
7.1.2 软件的可维护性
7.1.3 软件维护的实施
3
7.1.1 软件维护概述
软件维护 ---- 在软件交付使用后，根据需求 变化或硬件环境变化对应用程序进行部分或 全部修改。修改时要充分利用源程序，修改 后要填写程序登记表，并在程序变更通知书 上写明新旧程序的不同之处。 维护的类型有四种： 正确性维护 适应性维护
5
②适应性维护（ 18%~25% ）
在使用过程中，有以下变化： 外部环境（新的硬、软件配置） 数据环境（数据库、数据格式、数据输入/ 输出方式、数据存储介质） 企业的外部市场环境、管理需求 为使软件适应这种变化，而去修改软件的过程 就叫做适应性维护。 要有计划、有步骤的进行。
第7章 软件维护与 项目管理
普通人轻视软件维护工作，
会失掉极其宝贵的机会； 维护人员轻视软件维护工作， 会失掉本应精彩的人生； 老板轻视软件维护工作， 会丢掉大片本来属于自己的市场……
第7章 软件维护 与项目管理
7.1 7.2 7.3 7.4 7.5 7.6 软件维护 软件再工程 项目管理 项目度量 风险分析 小结
22
2. 软件维护报告
维护申请报告将由维护管理员和系统管理员研究 处理后，做出软件修改报告，指明：
所需修改变动的性质； 申请修改的优先级； 为满足维护申请报告所需的工作量； 预计修改后的状况。
软件修改报告应提交给变化授权人/修改负责 人），经批准后才能开始进一步安排维护工作。
33
Hale Waihona Puke Baidu
六、维护中的典型问题
(1) 难以跟踪软件版本的进化过程，软件的变化未 在文档中反映出来。 (2)难以读懂他人程序。 (3)无文档或不全。 (4)软件人员流动性大。 (5) 设计时未考虑修改需要,修改困难
(6) 维护工作无吸引力,缺乏成就感
采用软件工程方法至少可部分解决与维护有关 的每一个问题。
软件维护活动所花费的工作占整个生存期工作 量的70%以上。 软件维护代价极高，既破财，又伤神； 有形代价：投入的人力物力。 无形代价：影响更大。
31
维护的无形影响：
可用的资源必须供维护任务使用，以致耽误甚 至丧失了开发的良机。 改错或修改的不及时，引起的用户不满； 由于维护时的改动，在软件中引入了潜伏的错 误，从而降低了软件的质量； 把软件开发人员抽调到维护工作中，干扰了软 件开发工作。 生产率的大幅度下降，尤其在维护旧程序时常 常遇到。
29
三、结构化维护与非结构化 维护差别巨大
结构化维护： 有一个完整的软件配置，维护工作从评价设计 文档开始； 估计改动将带来的影响，计划实施途径； 修改设计文档，并且复审； 编写相应的源程序代码； 使用在测试说明书中包含的信息进行回归测试； 把修改后的软件再次交付使用。
30
四、维护的代价高昂
37
开发文档
开发文档 软件需求规格说明书 数据要求说明书 概要设计说明书 详细设计说明书 可行性研究报告 项目开发计划
38
管理文档
管理文档 测试计划 测试报告 开发进度月报 开发总结报告
39
系统文档
系统文档：指从问题定义、需求说明到验收测 试计划这样一系列和系统实现有关的文档。 描述系统设计、实现和测试的文档对于理解程 序和维护程序来说是极端重要的。 和用户文档类似，系统文档的结构也应该能把 读者从对系统概貌的了解，引导到对系统每个 方面每个特点的更形式化更具体的认识。
完善性维护
预防性维护
4
①正确性维护（改正性维护）
改正软件中存在的错误。占整个维护工作量的 17%~21%。 在软件交付使用后，由于开发时测试得不彻底 或不完全，在运行阶段会暴露一些开发时未能 测试出来的错误。为了识别和纠正软件错误， 改正软件性能上的缺陷，避免实施中的错误使 用，应当进行的诊断和改正错误的过程，这就 是改正性维护。
21
2. 软件维护报告
用标准化的格式表达所有软件维护申请（要求）。 维护申请报告/软件问题报告，由申请维护的用 户填写。 用户必须完整地说明产生错误的情况，包括输入 数据、错误清单以及其它有关材料。 如果申请的是适应性维护或完善性维护，用户必 须提出一份修改说明书，列出所有希望的修改。
软件的维护十分困难，原因在于这些软件的文 档不全、质量差、开发过程不注意采用好的方 法，忽视程序设计风格等。 许多维护要求并不是因为程序中出错而提出， 而是为适应环境变化或需求变化而提出的。 为了使得软件能够易于维护，必须考虑使软件 具有可维护性。
11
一、软件可维护性的定义
软件可维护性定义： 软件能够被理解、校正、适应及增强功能的难 易程度。 软件可维护性可以用7个质量特性来衡量： 可理解性，可测试性，可修改性，可靠性， 可移植性，可使用性，效率
(2) 哪些维护资源应该有但没有?
(3) 工作中主要的或次要的障碍是什么? (4) 从维护申请的类型来看是否应当有预防性 维护? 情况评审对将来的维护工作如何进行会产生重 要的影响。
25
维护档案记录
①程序标识； ②源语句 数； ③机器指令条数； ④使用的程序设计语言； ⑤程序安装的日期； ⑥ 自从安装以来程序运行的 次数； ⑦自从安装以来 程序失效的次数； ⑧程 序变动的层次和标识； ⑨因程序变动而增加的源 语句数；