软件维护与项目管理

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