第八章 维 护
?软件维护的定义
?维护的特点
?维护过程
?可维护性
软件维护的定义
?在 软件交付使用以后，为了改正
错误或满足新的需要而修改软件的
过程。
四种类型的维护
? 改正性维护 (Corrective Maintenance)
? 诊断和改正使用期间所发现的错误
? 适应性维护 (Adaptive Maintenance)
? 由于硬件、系统软件和应用软件的发展不协调，
须为提高软件的适应性而修改软件
? 完善性维护 (Perfect Maintenance)
? 为满足用户对软件所提出的新的要求，对软件
进行修改。
? 预防性维护 (Preventive Maintenance)
? 为了改进未来的可维护性或可靠性，或为了给
未来的改进奠定更好的基础而修改软件。
维护成本占总开发成本的比例
?? ?¤?? ?ˉ
?? ?ü ?ü ?ú
四种维护所占比例
17~21%,18 ~ 25%,50 ~ 66%
íê é? D? ?? ?¤
ê ó| D? ?? ?¤
?? ?y D? ?? ?¤
?? ?ü àà Dí
结构化维护和非结构化维护
（ P167）
?所维护的软件的配置是否齐全，如软
件结构、全程数据结构、系统接口、
性能说明、设计约束等。
?如果仅有程序代码，非结构化维护工
作就十分困难。
维护的代价
?维护费用有上升的趋势
?维护的无形代价
?美国海军飞行控制软件每条指令的开发
成本是 50$，而每条指令的维护成本是
4000$.
?Belady建议的估算公式：
M = P + K ? exp(c-d)
其中,M是维护总工作量,P为生产性工
作量,K为经验常数,c是复杂程度,d
是维护人员对软件的熟悉程度。
维护的问题（ P168）
?理解别人的程序很难
?文档不全
?维护阶段持续时间漫长,,事过境迁,
?绝大数软件在设计时没有考虑将来的维
护问题
?软件维护是一项不吸引人的工作
维护组织
?维护管理员
?根据项目的规模，指定一名高级管理人员担
任，或由高级管理人员和专业人员组成修改
控制组（ CCB——change control board），
负责对维护申请的审查与批准，指定维护的
计划安排、人力和资源分配，批准向用户发
布维护结果，对维护活动进行评价和分析。
?一般还设置系统监督员、维护人员，系统
管理员等
维护报告
?维护要求表
?软件问题报告表，一种标准化的表格。
?由用户填写，描述导致错误的环境等。
?软件修改报告的基本内容（ P170）
?所需要的工作量
?维护要求的性质
?这项要求的优先次序
?与修改有关的事后数据
维护的事件流
?（ P170图 8.3）
保存维护记录
?（ P171）
评价维护活动
?基于所保存的维护记录，可以对维护工
作进行评价和一些定量度量。
?可以度量维护活动的几个方面
?每次程序运行平均失效的次数
?用于每类维护活动的总人时数
?平均每个程序、每种语言、每种维护所做
的程序变动数
?增加或删除一个源语句平均花费的人时数
?维护每种语言平均花费的人时数
?一张维护要求表的平均周转时间
?不同的维护类型所占的百分比。
可维护性
?可维护性的定义
?可维护性是指纠正软件系统出现的错误和缺陷，
以及为满足新的需求而进行修改、扩充或压缩的
容易程度。
?可维护性、可靠性、可使用性是衡量软件质
量的主要质量特性
衡量可维护性的七个特性
?可理解性
?可测试性
?可修改性
?可靠性
?可移植性
?可使用性
?效率
文档是软件可维护性的决定因素
?用户文档
?功能描述，安装说明，使用手册，参考手册，
操作员指南等
?系统文档
?指从问题定义、需求说明到验收测试计划的一
系列和实现有关的文档。主要描述系统设计、
实现和测试等各方面的内容。
?软件文档应该满足的基本要求（ P173）
可维护性度量
?从度量影响可维护性的七个特性着手，
即可首先理解性、可测试性、可修改性、
可靠性、可移植性、可使用性和效率，
在进行汇总。
?不同特性的度量方法
提高可维护性的方法
?建立明确的软件质量目标和优先级别
?使用质量保证的技术和方法
?进行明确的质量保证审查
?选择可维护的程序设计语言
?改进程序的文档
维护“老化代码”
?“老化代码” 是指 15年以前开发的程序
? 参与人员已人去楼空
? 当时的开发技术被淘汰
? 没有完全的软件配置
? 只能够非结构化维护
?针对“老化代码”,Yourdon 提出了一些建议,
? 在维护之前，必须研究程序的使用环境及有关资料。
? 力图熟悉程序的所有控制流程。
? 评价现有文档的可用性。
? 保持详细的维护活动和维护结果记录。
? ……
逆向工程和再工程
?逆向工程和再工程的定义
?逆向工程：实现 → 设计 → 规范 → 需求，具体
→ 抽象
?再工程：复壮或再生，不仅从已经存在的程
序中重新获得设计信息，而且使用这些信息
来改建或重构现有的系统，以改进它的的综
合质量或满足新的需求等
?逆向工程的意义
?技术竞争
?安全考虑
?完善软件配置以便于维护和复用
?将逆向工程和再工程用于预防性维护性
程序修改的步骤
?分析和理解程序
? 程序功能和目标
? 程序的结构信息
? 数据流信息
? 控制信息
? 程序的操作要求
?修改程序
? 设计修改程序的计划
? 修改代码，以适应变化
? 修改程序的副作用
维护的副作用
?定义
?指因修改软件而造成的错误或其它不希望
发生的情况。
?三种副作用
?修改代码的副作用
?修改数据的副作用
?修改文档的副作用
修改代码的副作用
?如删除或修改子程序、一个标号，改变
程序代码的时序关系等。
修改数据的副作用
?如对数据结构的修改，有可能造成软件
设计与数据结构的不匹配；重新定义局
部和全局常量、重新定义记录或文件的
格式等等，容易导致设计与数据不相容。
修改文档的副作用
?对数据流、软件结构、模块逻辑或其它
有关特性进行修改时，必须对相关技术
文档进行相应的修改。否则会导致文档
与程序功能不匹配，使软件文档不能反
映软件当前状态。
可维护性复审
?着重对可维护性进行复审
?在不同的开发阶段，针对诸多影响可维
护性的因素进行复审
?影响可维护性的诸多因素
?可理解性
?可测试性
?可修改性
?模块独立性
?编码风格
?文档
?软件维护的定义
?维护的特点
?维护过程
?可维护性
软件维护的定义
?在 软件交付使用以后，为了改正
错误或满足新的需要而修改软件的
过程。
四种类型的维护
? 改正性维护 (Corrective Maintenance)
? 诊断和改正使用期间所发现的错误
? 适应性维护 (Adaptive Maintenance)
? 由于硬件、系统软件和应用软件的发展不协调，
须为提高软件的适应性而修改软件
? 完善性维护 (Perfect Maintenance)
? 为满足用户对软件所提出的新的要求，对软件
进行修改。
? 预防性维护 (Preventive Maintenance)
? 为了改进未来的可维护性或可靠性，或为了给
未来的改进奠定更好的基础而修改软件。
维护成本占总开发成本的比例
?? ?¤?? ?ˉ
?? ?ü ?ü ?ú
四种维护所占比例
17~21%,18 ~ 25%,50 ~ 66%
íê é? D? ?? ?¤
ê ó| D? ?? ?¤
?? ?y D? ?? ?¤
?? ?ü àà Dí
结构化维护和非结构化维护
（ P167）
?所维护的软件的配置是否齐全，如软
件结构、全程数据结构、系统接口、
性能说明、设计约束等。
?如果仅有程序代码，非结构化维护工
作就十分困难。
维护的代价
?维护费用有上升的趋势
?维护的无形代价
?美国海军飞行控制软件每条指令的开发
成本是 50$，而每条指令的维护成本是
4000$.
?Belady建议的估算公式：
M = P + K ? exp(c-d)
其中,M是维护总工作量,P为生产性工
作量,K为经验常数,c是复杂程度,d
是维护人员对软件的熟悉程度。
维护的问题（ P168）
?理解别人的程序很难
?文档不全
?维护阶段持续时间漫长,,事过境迁,
?绝大数软件在设计时没有考虑将来的维
护问题
?软件维护是一项不吸引人的工作
维护组织
?维护管理员
?根据项目的规模，指定一名高级管理人员担
任，或由高级管理人员和专业人员组成修改
控制组（ CCB——change control board），
负责对维护申请的审查与批准，指定维护的
计划安排、人力和资源分配，批准向用户发
布维护结果，对维护活动进行评价和分析。
?一般还设置系统监督员、维护人员，系统
管理员等
维护报告
?维护要求表
?软件问题报告表，一种标准化的表格。
?由用户填写，描述导致错误的环境等。
?软件修改报告的基本内容（ P170）
?所需要的工作量
?维护要求的性质
?这项要求的优先次序
?与修改有关的事后数据
维护的事件流
?（ P170图 8.3）
保存维护记录
?（ P171）
评价维护活动
?基于所保存的维护记录，可以对维护工
作进行评价和一些定量度量。
?可以度量维护活动的几个方面
?每次程序运行平均失效的次数
?用于每类维护活动的总人时数
?平均每个程序、每种语言、每种维护所做
的程序变动数
?增加或删除一个源语句平均花费的人时数
?维护每种语言平均花费的人时数
?一张维护要求表的平均周转时间
?不同的维护类型所占的百分比。
可维护性
?可维护性的定义
?可维护性是指纠正软件系统出现的错误和缺陷，
以及为满足新的需求而进行修改、扩充或压缩的
容易程度。
?可维护性、可靠性、可使用性是衡量软件质
量的主要质量特性
衡量可维护性的七个特性
?可理解性
?可测试性
?可修改性
?可靠性
?可移植性
?可使用性
?效率
文档是软件可维护性的决定因素
?用户文档
?功能描述，安装说明，使用手册，参考手册，
操作员指南等
?系统文档
?指从问题定义、需求说明到验收测试计划的一
系列和实现有关的文档。主要描述系统设计、
实现和测试等各方面的内容。
?软件文档应该满足的基本要求（ P173）
可维护性度量
?从度量影响可维护性的七个特性着手，
即可首先理解性、可测试性、可修改性、
可靠性、可移植性、可使用性和效率，
在进行汇总。
?不同特性的度量方法
提高可维护性的方法
?建立明确的软件质量目标和优先级别
?使用质量保证的技术和方法
?进行明确的质量保证审查
?选择可维护的程序设计语言
?改进程序的文档
维护“老化代码”
?“老化代码” 是指 15年以前开发的程序
? 参与人员已人去楼空
? 当时的开发技术被淘汰
? 没有完全的软件配置
? 只能够非结构化维护
?针对“老化代码”,Yourdon 提出了一些建议,
? 在维护之前，必须研究程序的使用环境及有关资料。
? 力图熟悉程序的所有控制流程。
? 评价现有文档的可用性。
? 保持详细的维护活动和维护结果记录。
? ……
逆向工程和再工程
?逆向工程和再工程的定义
?逆向工程：实现 → 设计 → 规范 → 需求，具体
→ 抽象
?再工程：复壮或再生，不仅从已经存在的程
序中重新获得设计信息，而且使用这些信息
来改建或重构现有的系统，以改进它的的综
合质量或满足新的需求等
?逆向工程的意义
?技术竞争
?安全考虑
?完善软件配置以便于维护和复用
?将逆向工程和再工程用于预防性维护性
程序修改的步骤
?分析和理解程序
? 程序功能和目标
? 程序的结构信息
? 数据流信息
? 控制信息
? 程序的操作要求
?修改程序
? 设计修改程序的计划
? 修改代码，以适应变化
? 修改程序的副作用
维护的副作用
?定义
?指因修改软件而造成的错误或其它不希望
发生的情况。
?三种副作用
?修改代码的副作用
?修改数据的副作用
?修改文档的副作用
修改代码的副作用
?如删除或修改子程序、一个标号，改变
程序代码的时序关系等。
修改数据的副作用
?如对数据结构的修改，有可能造成软件
设计与数据结构的不匹配；重新定义局
部和全局常量、重新定义记录或文件的
格式等等，容易导致设计与数据不相容。
修改文档的副作用
?对数据流、软件结构、模块逻辑或其它
有关特性进行修改时，必须对相关技术
文档进行相应的修改。否则会导致文档
与程序功能不匹配，使软件文档不能反
映软件当前状态。
可维护性复审
?着重对可维护性进行复审
?在不同的开发阶段，针对诸多影响可维
护性的因素进行复审
?影响可维护性的诸多因素
?可理解性
?可测试性
?可修改性
?模块独立性
?编码风格
?文档
