软件维护
第八章软件维护
④ 软件维护工作是一项难出成果，大家都不愿意干的工作。
8.1.4 软件维护的代价
1.软件维护的工作量大 软件维护的费用在整个软件开发费用的 55%-70%，并且所占比例在逐年上升。而且维 护中还可能产生新的潜在错误。例如 1970 年维护费用约占软件开发费用的 40%，到 1990 年维护费用所占比例就超过了 70%。另外维护还包含了无形的资源占用，包括大量的使用 很多硬件、软件和软件工程师等资源。 在软件维护时，直接影响维护成本和工作量的因素很多，主要如下： （1）系统规模大小 系统规模大小直接影响维护工作量，系统规模越大，仅仅看懂理解就很困难，维护的 工作量就更多。系统规模主要由源代码行数、程序模块数、数据接口文件数、使用数据库 规模大小等因素衡量。 （2）程序设计语言 参与软件开发的人员都知道，解决相同的问题选择不同的程序设计语言，得到的程序 的规模可能不同，由此应选择功能强且适合解决问题的程序设计语言，这样可以使生成程 序的指令数更小。 （3）系统使用年限 使用年限长的老系统维护比新系统所需要的工作量更多。老系统因已经进行多次维 护，参与维护的人员也不断变化，因此这样的系统结构更乱，如果没有系统说明和设计文 档，维护就更加困难。 （4）软件开发新技术的应用 软件开发过程中，使用先进的分析和设计技术，以及程序设计技术，如：面向对象的技术、 构件技术、可视化程序设计技术等，可以减少维护工作量。 （5）设计过程中的技术 在具体对软件进行维护时，影响维护工作量的其他因素还有很多，例如设计过程中应 用的类型、数学模型、任务的难度、开关与标记、IF 嵌套深度、索引或下标数等。 2.软件维护工作量模型 维护活动分为生产性活动和非生产性活动。生产性活动包括分析评价、修改设计和编 写程序代码等。非生产性活动包括理解程序代码，解释数据结构，接口特点和设计约束等。 Belady 和 Lehman 提出软件维护工作模型：
软件维护的4类活动
软件维护是指软件从开始到结束的整个生命周期中，为了确保软件能够正确地实现需求、提高软件质量、降低软件维护成本而进行的一系列活动。
根据软件维护的定义，可以将软件维护的活动分为以下四类：
1.改正性维护：在软件交付使用后，由于在软件开发过程中产生的错误并没有完全被发现，导致在软件运行时会出现一些错误，所以需要开展改正
性维护。
2.适应性维护：随着计算机硬件和外部环境的变化，软件可能无法正常工作，因此需要开展适应性维护。
3.完善性维护：用户在使用软件的过程中，可能会提出一些新的需求和功能要求，为了满足用户的需求，需要对软件进行完善性维护。
4.预防性维护：为了预防软件在未来出现故障或过时，需要进行预防性维护，例如更新软件设计、改进软件性能等。
这些维护活动可以帮助软件更好地适应外部环境的变化，提高软件的质量和可靠性，延长软件的使用寿命。
第8章软件维护
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1）编码副作用：在使用程序设计语言修改源代码时可能引起的错误， 如删除或修改一个标号、标识符、一个子程序，改变程序代码的时序关系， 改变逻辑运算符，改进程序的执行效率，改变程序占用存储的大小等，都 很容易引入错误，应特别小心。 2）数据副作用：在修改数据结构时，有可能造成软件设计和数据结构 的不一致，而导致软件错误。数据副作用是修改软件信息结构引起的，如 重新定义全局或局部常量，重新初始化控制标志或指针等，都容易产生设 计与数据不相容的错误，可通过详细设计文档对数据副作用加以控制。 3）文档副作用：对数据流、软件结构、逻辑模块等进行修改时，必须 对相关技术文档进行修改，否则会导致 文档与程序功能不匹配，使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序：
1）静态确认； 2）计算机确认； 3）维护后的验收。
软件维护步骤
第三步：维护文档整理
记录一些与维护工作有关的数据信息，这些信息 可作为估计软件维护的有效程度，确定软件产品的 质量，确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步：维护活动评价
具体的评价工作可从以下几个方面考虑： （1）每次程序运行时的平均出错次数； （2）花费在每类维护活动上的总的“人时”数； （3）每个程序、每种语言、每种维护类型程序的平均修改次数； （4）维护工作中增加或删除每个源程序语句所花费的平均“人 时”数； （5）用于每种语言的平均“人时”数； （6）维护申请报告的平均处理时间； （7）各类维护申请的百分比。 一方面，可判定此次维护活动开展是否顺利、成功；另一方面， 为今面的维护工作积累经验。
2、结构化维护：进行维护 活动时，首先从评价需求开始，搞清楚 功能、性能上的改变，然后对设计说明文档进行评价、修改和复查； 根据设计的修改，再进行程序的变动；然后根据测试文档中的测试 用例进行回归测试；最后将修改后的软件再次交付使用。
软件维护的概念
软件维护的概念软件维护是指在软件开发完成并投入使用后，对软件系统进行的修改、优化和修复工作。
软件维护是软件生命周期中重要的一个阶段，它包括对软件系统的各种修改和改进，以保证软件系统的稳定性、可靠性和安全性。
软件维护是保障软件系统持续发展的重要环节，它的目的是通过不断地对软件进行改进和修复，确保软件系统能够适应新的需求和环境变化，提高软件系统的使用价值并延长软件的使用寿命。
软件维护包括对软件系统的多方面工作，主要包括以下几个方面：1.纠错性维护：在软件运行过程中，发现产生的错误和缺陷，并进行修复和改进，以确保软件系统的稳定性和可靠性。
2.适应性维护：对软件进行适应新的硬件、操作系统、数据库、网络环境等方面的变化，确保软件系统能够适应不断变化的技术环境和应用需求。
3.完善性维护：不断对软件进行优化和改进，提高软件的性能、可用性和用户体验，以满足用户不断增长的需求和期望。
4.预防性维护：通过对软件系统进行分析和评估，及时发现和解决潜在的问题和风险，防止软件系统出现严重的故障和漏洞。
软件维护是软件开发生命周期中的重要环节，它对软件系统的稳定性、可靠性和可维护性有着重要影响。
软件维护的目标是通过对软件系统的不断修复、改进和优化，确保软件能够持续地满足用户的需求，并在不断变化的技术和商业环境中保持竞争力。
软件维护可以帮助软件系统不断地适应用户需求和市场变化，同时及时发现和解决软件系统中的问题和隐患，保证软件系统的稳定运行和持续发展。
软件维护的重要性主要体现在以下几个方面：1.保障软件系统的稳定性和可靠性。
软件维护可以及时发现和解决软件系统中的问题和缺陷，确保软件系统能够持续稳定地运行，提高软件系统的可靠性和可用性。
2.延长软件系统的使用寿命。
通过对软件系统的改进和优化，延长软件系统的使用寿命，提高软件系统的投资回报率，减少软件系统更换的成本和风险。
3.提高软件系统的适应性和竞争力。
软件维护可以帮助软件系统适应不断变化的技术环境和市场需求，提高软件系统的灵活性和竞争力，满足用户不断增长的需求和期望。
软件工程学维护
20-40倍。 ② 使用现代设计概念重新设计软件体系结构，对未来的维护
工作将有很大的帮助。 ③ 由于软件原型已经存在，软件开发生产率将远远高于平均
水平。 ④ 由于用户已经有较丰富的软件使用经验，所以很容易确定
为了使软件和变化了的环境（如软/硬件升级、新数据库 等）适当地配合而修改软件的活动。约占全部维护活动的18 % ~25%。
§1. 软件维护的定义
③ 完善性维护(perfective maintenance) 为了增加软件新功能、改已有功能（如改造界面）、增强软
件性能、提高运行效率等，而修改软件的活动。 约占全部维护活动的50% ~66%。
④ 预防性维护(preventive maintenance)
为了改进未来的可维护性或可靠性，或为了给未来的改进奠 定更好的基础而主动修改软件的活动。与其它维护活动共占总 维护的4%左右。
注：① 一般维护的工作量占生存周期70%以上，维护成本约 为开发成本的4倍；
② 文档维护与代码维护同样重要。
§2. 软件维护的特点
1、建立维护组织(maintenance team)
在维护活动开始之前就明确维护责任是十分必要的，这样可 以大大减少维护过程中可能出现的混乱。
§3. 软件维护过程
钱太少 要
任务评价
变
不干！
求 维
客户要求
化
护
授
权
人
任务评价
维护管理员
系 统 管 理 员
2、维护报告
§3. 软件维护过程
⑴ 维护要求表(Maintenance Request Form)
简述软件维护的内容
简述软件维护的内容
软件维护是指对已经开发的软件进行修正、更新和改进，以确保其正常运行并保持最新的功能和技术。
软件维护的目的是为了解决已有的软件存在的问题，保证软件的稳定性和可靠性，并提高软件的性能和效率。
软件维护包括以下几个方面的内容:
1. 代码修改和优化：针对软件中存在的错误、漏洞和不兼容等问题，修改和优化代码，以确保软件的正确性和稳定性。
2. 更新软件版本：更新软件的版本以提高其性能和功能。
通过更新软件，可以修复之前版本的已知问题，增加新的功能，提高软件的可靠性和可用性。
3. 性能优化：优化软件的性能和效率，以提高软件的响应速度和处理能力。
这可以通过修改代码、优化数据库和网络连接等方式来实现。
4. 安全维护：维护软件的安全性，确保软件不受恶意攻击和篡改。
安全维护包括对软件漏洞的修复、安全审计和风险评估等。
5. 技术支持和培训：提供软件的用户和技术支持，回答用户的问题和提供技术支持文档，并对软件的使用人员进行培训，以确保软件的正常运行。
软件维护是保证软件长期正常运行的关键步骤。
通过及时维护和更新软件，可以确保软件的可靠性和稳定性，提高软件的性能和效率，从而满足用户的需求。
软件维护的名词解释
软件维护的名词解释软件维护是指对已经开发完成的软件进行修改、更新、优化和修复等工作的过程。
在软件生命周期中，维护阶段占据了相当重要的地位，它是确保软件持续稳定运行和适应不断变化需求的关键环节。
本文将对软件维护的定义、目标、类型以及重要性进行深入探讨。
一、软件维护的定义软件维护是指在软件开发完成并投入使用后，对软件进行不同程度的修改、补充、纠错和优化的活动。
这些修改主要针对软件的功能、性能、易用性或者适应性等方面。
维护过程包括对软件的分析、设计、编码、测试、文档更新等环节，旨在提高软件的质量和可靠性。
二、软件维护的目标1. 改进功能：软件维护的首要目标是通过添加或修改现有功能来满足用户的新需求。
根据用户反馈和市场变化，软件需要不断演进和发展，以确保其具备更强大的功能和更好的用户体验。
2. 修复缺陷：维护过程中，开发人员会不断发现软件存在的各种问题和缺陷。
为了保证软件的正常运行和稳定性，需要对这些缺陷进行修复和纠正。
3. 提高性能：随着软件使用规模和数据量的增加，性能问题可能逐渐显露出来。
软件维护的目标之一是通过性能优化，提高软件的运行效率和响应速度，以满足不断增长的用户需求。
4. 更新技术：软件的技术环境和外部依赖可能在运行过程中发生变化。
为了确保软件与最新的技术标准和发展趋势保持一致，维护工作还需要对技术进行更新和升级。
5. 管理成本：软件维护也面临着重要的成本问题。
通过优化维护流程、提高开发效率和降低维护成本，可以有效控制长期维护过程中的成本压力。
三、软件维护的类型软件维护根据维护的对象和目的，可以分为以下几类：1.。
软件维护流程
软件维护流程软件维护是软件开发生命周期中非常重要的一个环节，它包括对软件进行修改、优化、更新和完善，以确保软件能够持续稳定地运行。
软件维护流程是指对软件进行维护的一系列步骤和方法，下面将详细介绍软件维护的流程及相关注意事项。
1. 接收问题反馈。
软件维护流程的第一步是接收用户或客户的问题反馈。
这些问题反馈可以来自于软件使用过程中出现的错误、漏洞、性能问题，也可以是用户对软件功能和界面的建议和需求。
在接收问题反馈时，需要及时记录问题描述、问题出现的环境、重现步骤等信息，并对问题进行分类和优先级排序。
2. 分析问题原因。
接收到问题反馈后，需要对问题进行分析，找出问题的根本原因。
这一步需要软件开发人员、测试人员和客户服务人员等多方共同参与，通过分析日志、调试代码、复现问题等方式来深入了解问题的本质。
在分析问题原因时，需要注意综合考虑软件的功能、性能、安全性等方面的因素，确保找出问题的真正原因。
3. 制定维护计划。
在分析清楚问题原因后，需要制定针对性的维护计划。
维护计划包括对问题的修复方案、优化方案、更新方案等内容，同时需要考虑到维护的时间节点、风险评估、资源分配等方面。
制定维护计划时，需要与相关部门和人员进行充分沟通，确保计划的可行性和有效性。
4. 实施维护措施。
制定好维护计划后，需要开始实施维护措施。
这包括对软件进行修改、更新、优化等操作，同时需要进行相应的测试和验证，确保维护后的软件能够正常运行并且问题得到解决。
在实施维护措施时，需要严格按照计划进行，并及时跟进和反馈维护的进展情况。
5. 验收和发布。
维护措施实施完成后，需要进行验收和发布。
验收是指对维护后的软件进行全面的测试和验证，确保软件的功能、性能、安全性等方面都符合要求。
如果验收通过，就可以进行软件的发布，让用户和客户可以使用到最新的软件版本。
6. 监控和反馈。
维护流程的最后一步是监控和反馈。
在软件发布后，需要对软件进行持续的监控和跟踪，及时发现和解决新的问题和Bug。
软件维护手册
软件维护手册目录1. 软件维护的重要性2. 软件维护的步骤- 2.1. 问题识别- 2.2. 问题排查与定位- 2.3. 问题修复- 2.4. 测试与验证- 2.5. 部署与发布3. 软件维护的最佳实践- 3.1. 保持文档和记录- 3.2. 定期检查与更新- 3.3. 紧急情况处理- 3.4. 团队合作与沟通4. 常见问题解答- 4.1. 问题1- 4.2. 问题2- ...1. 软件维护的重要性软件维护是保证软件系统稳定运行和持续可用的关键活动。
通过对软件进行及时的维护，可以修复错误、增强功能、提高性能，并保证系统的安全性。
2. 软件维护的步骤2.1. 问题识别在软件维护过程中，首先需要识别出存在的问题。
这可以通过进行用户反馈、系统巡检和日志分析等方式来发现。
2.2. 问题排查与定位一旦发现问题，需要进行排查和定位。
通过分析相关日志和跟踪执行流程，可以找出问题的根本原因。
2.3. 问题修复在确定了问题原因后，需要采取相应的措施进行问题修复。
这可以包括修复代码、优化配置、更新依赖等操作。
2.4. 测试与验证修复问题后，需要进行测试和验证以确保问题得到彻底解决。
这可以通过单元测试、集成测试和用户验收测试等方式来进行。
2.5. 部署与发布最后，将修复后的软件部署和发布到生产环境中，确保用户能够使用到修复后的系统。
3. 软件维护的最佳实践3.1. 保持文档和记录在进行软件维护时，需要及时记录问题、修复过程和测试结果等信息。
这有助于日后的参考和回顾，提高维护效率。
3.2. 定期检查与更新为了保障软件的安全性和稳定性，需要定期进行巡检和更新。
包括检查系统依赖的版本是否过期，更新补丁和安全更新等。
3.3. 紧急情况处理对于紧急情况，需要及时响应和处理。
建立应急响应机制，并且确保团队成员掌握相应流程和联系方式。
3.4. 团队合作与沟通软件维护是一个团队合作的过程，需要各个角色之间的密切合作和有效沟通。
建立良好的团队文化和流程，可以提高维护效率。
软件工程基础之 软件维护
可维护性改进
代码重构
对代码进行重新组织和优化，使其更易于阅读、理解和维护 。
文档更新
更新软件文档，以反映软件的新功能、性能优化和修复的缺 陷，方便后续维护和开发。
05
适应性维护
环境变化处理
操作系统升级
当操作系统升级时，软件也需要进行相应的调整以适应新的操作系统。这可能涉及到修改软件与操作系统的接口、更 新系统调用等。
软件版本控制
为了确保软件的版本兼容性和升级的顺利进行，需要进行软件版本的控制和管理 。这可能涉及到版本号的分配、版本升级流程的制定和实施等。
兼容性测试
在软件升级后，需要进行兼容性测试以确保新版本软件与旧版本软件的兼容性。 这可能涉及到测试用例的设计、测试环境的搭建和测试执行等。
THANKS
感谢观看
04
完善性维护
功能增强
增加新功能
根据用户需求或市场需求，对软 件进行功能扩展或升级，增加新 的特性和功能。
优化现有功能
对现有功能进行改进和调整，提 高其性能、稳定性和用户体验。
性能优化
提升运行速度
通过优化算法、减少冗余计算或使用 更高效的存储结构等方式，提高软件 的运行速度。
降低资源消耗
优化软件对内存、CPU等资源的利用 ，降低软件运行成本和维护成本。
文档化与标准化
文档是软件维护的重要依据，包 括系统架构、系统功能、接口协
议等方面的文档。
标准化则是指遵循统一的编码规 范、命名规范、接口规范等，提
高代码的可读性和可维护性。
文档化和标准化有助于提高软件 的可维护性和可扩展性，降低维
护成本。
03
改正性维护
错误识别与定位
错误报告
01
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
•
非结构化维护：维护只基于程序代码。 非结构化维护：维护只基于程序代码。 只基于程序代码
如果不采用软件工程方法开发软件， 如果不采用软件工程方法开发软件，软件只有程序而 欠缺文档，则维护工作将变得十分困难。 欠缺文档，则维护工作将变得十分困难。
7
维护代价
8
维护代价
• 软件维护除费用外的无形代价包括
3
软件维护分类(p318) 软件维护分类(p318)
• 纠错性维护（ Corrective ）：为了改正软件系统 纠错性维护（ 中的错误， 中的错误，使软件能够满足预期的正常运行状态的 要求而进行的维护 • 适应性维护（ Adaptive ）：为了使软件适应内部 适应性维护（ 或外部环境变化， 或外部环境变化，而去修改软件的过程 • 改善性维护（ Perfective ）：满足使用过程中用 改善性维护（ 户提出增加新功能或修改已有功能的建议维护 • 预防性维护（ Preventive ）：为了提高软件的可 预防性维护（ 维护性、可靠性等， 维护性、可靠性等，为以后进一步改进软件打下良 好基础而修改软件的活动
n 资源用于开发新的软件。 资源用于开发新的软件。
15
• 每种维护请求都要进行的一系列技术工作 (p321)
修改软件需求说明 修改软件设计 设计评审 必要时重新编码 单元测试 集成测试( 包括回归测试) 集成测试( 包括回归测试) 确认测试等
• 维护工作最后一步是复审
16
维护记录
• 维护人员对程序进行修改前要着重做好两个记录 维护人员对程序进行修改前要着重做好两个记录 进行修改前 (p322)
• 结构化维护：基于完整的软件配置进行的维护 结构化维护：基于完整的软件配置进行的维护 。 完整的软件配置
采用软件工程的方法进行软件开发， 采用软件工程的方法进行软件开发，保证每个阶段都 有完整且详细的文档。虽然不能保证维护没有问题， 有完整且详细的文档。虽然不能保证维护没有问题， 但可以减少维护的工作量，并提高维护的效率与质量。 但可以减少维护的工作量，并提高维护的效率与质量。 从评价设计文档开始， 从评价设计文档开始，根据文档来确定该软件的结构 特性、性能特性和接口特性， 特性、性能特性和接口特性，借此来估计改正或修改 可能带来的影响，根据影响准备相应的处理办法； 可能带来的影响，根据影响准备相应的处理办法；然 后修改设计，进行评审， 后修改设计，进行评审，编写新的程序代码并进行回 归测试；成功后交付使用。 归测试；成功后交付使用。
• 1）针对某一软件产品在软件生存周期内所进行的活动 • 2）当今的软件维护更强调的是服务 。“卖软件就是卖服 务” • 3）软件维护的时间是有限度的，一般而言目前软件产品的 软件维护的时间是有限度的， 免费服务时间为两年左右， 免费服务时间为两年左右，两年以后软件厂商总会推出更 新的版本以适应用户在功能、性能、 新的版本以适应用户在功能、性能、接口等方面所提出的 新需求，从而软件厂商也会找到新的利润增长点。 新需求，从而软件厂商也会找到新的利润增长点。
维护申请报告
• 即软件问题报告,该报告（表）由要求一项维护活动的用户填写。 软件问题报告,该报告（ 由要求一项维护活动的用户填写。 • 对改正性维护，用户需要将错误出现的现场信息详细描述出来， 对改正性维护，用户需要将错误出现的现场信息详细描述出来， 包括输入数据、错误清单以及其它有关材料。 包括输入数据、错误清单以及其它有关材料。 • 对适应性维护或改善性维护，应该给出一个简短的需求规格说 对适应性维护或改善性维护， 明书。 明书。 • 维护申请被批准后，维护申请报告就成为外部文档，作为本次 维护申请被批准后，维护申请报告就成为外部文档， 维护的依据
21
1. 可理解性 • 可理解性表明人们通过阅读源代码和 相关文档， 相关文档，了解程序功能及其如何运 行的容易程度。ห้องสมุดไป่ตู้行的容易程度。 • 一个可理解的程序应具备以下一些特 模块化，风格一致性， 性：模块化，风格一致性，不使用令 人捉摸不定或含糊不清的代码， 人捉摸不定或含糊不清的代码，使用 有意义的数据名和过程名，结构化， 有意义的数据名和过程名，结构化， 完整性等 完整性等。
♣软件维护的概念 软件维护的概念 ♣软件维护的特点 ♣软件维护的特点 ♣软件维护过程 软件维护过程 ♣软件的可维护性 软件的可维护性 ♣再工程技术 再工程技术
1
学习目标
• 了解软件维护的特点，软件维护的过程。 了解软件维护的特点，软件维护的过程。 • 熟练掌握软件维护的定义、软件维护的四 熟练掌握软件维护的定义、 种类型以及决定软件可维护性的因素。 种类型以及决定软件可维护性的因素。 • 了解再工程技术。 了解再工程技术。
12
维护组织结构图
13
• 维护申请提交给维护管理员，他把 维护申请提交给维护管理员， 提交给维护管理员 申请交给某个系统监督员 评价。 系统监督员去 申请交给某个系统监督员去评价。 • 一旦做出评价，由修改控制决策机 一旦做出评价， 确定如何进行修改 如何进行修改。 构确定如何进行修改。 • 在修改程序的过程中，由配置管理 在修改程序的过程中， 严格把关，控制修改的范围， 员严格把关，控制修改的范围，对 软件配置进行审计。 软件配置进行审计。 • 在维护之前，就把责任明确下来， 在维护之前，就把责任明确下来， 可以减少维护过程中的混乱。 可以减少维护过程中的混乱。
4
预防性 维护4% 维护4%
纠错性维护25% 纠错性维护25%
完善性 维护50% 维护50% 适应性 维护21% 维护21%
纠错性维护 适应性维护 完善性维护 预防性维护
5
软件维护的特点
• 结构化维护与非结构化维护差别巨大 • 维护的代价高昂 • 维护的问题很多
6
结构化维护与非结构化维护差别(p318) 结构化维护与非结构化维护差别(p318)
• •
软件维护的过程
• • • • 建立维护组织 确定维护过程 保管维护记录 进行维护评价
11
维护组织
• 除了较大的软件开发公司外，通常 除了较大的软件开发公司外， 在软件维护工作方面， 在软件维护工作方面，并不保持一 个正式的组织机构。 个正式的组织机构。 • 虽然不要求建立一个正式的维护机 构，但是在开发部门确立一个非正 式的维护机构则是非常必要的。 式的维护机构则是非常必要的。
维护活动占用了其他软件开发可用的资源， 维护活动占用了其他软件开发可用的资源， 使资源的利用率降低 一些修复或修改请求得不到及时安排， 一些修复或修改请求得不到及时安排，使得 客户满意率下降 维护的结果把一些新的潜在的错误引入软件， 维护的结果把一些新的潜在的错误引入软件， 降低了软件质量 将软件人员抽调到维护工作中， 将软件人员抽调到维护工作中，使得其它软 件开发过程受到干扰
2
软件维护的概念
• 什么是软件维护
是指软件系统交付使用以后， 是指软件系统交付使用以后，为了改正错误或满足 新的需要而修改软件的过程 国标GB/T 11457-95给出如下定义 国标GB/T 11457-95给出如下定义 ：在一软件产品 交付使用后对其进行修改，以纠正故障、 交付使用后对其进行修改，以纠正故障、改进其性 能和其它属性， 能和其它属性，或使产品适应改变了的环境 三层含义： 三层含义：
22
2. 可测试性
• 可测试性表明论证程序正确性的容易程度。 可测试性表明论证程序正确性的容易程度。 • 一个可测试的程序应当是可理解的，可靠的， 一个可测试的程序应当是可理解的 可靠的， 可理解的， 简单的。 简单的。 • 用于可测试性度量的检查项目如下： 用于可测试性度量的检查项目如下：
程序是否模块化? 结构是否良好? 程序是否模块化? 结构是否良好? 程序是否可理解? 程序是否可靠? 程序是否可理解? 程序是否可靠? 程序是否能显示任意中间结果? 程序是否能显示任意中间结果? 程序是否能以清楚的方式描述它的输出? 程序是否能以清楚的方式描述它的输出? 程序是否能及时地按照要求显示所有的输入? 程序是否能及时地按照要求显示所有的输入? 程序是否有跟踪及显示逻辑控制流程的能力? 程序是否有跟踪及显示逻辑控制流程的能力? 程序是否能从检查点再启动? 程序是否能从检查点再启动? 程序是否能显示带说明的错误信息? 程序是否能显示带说明的错误信息?
14
维护过程
维护请求 其他 类型 适应性维护 类型 改善性维护 非常严重 严重性 并不严重 纠错性维护
评估后按优先 级在队列排队
评估后分类
救火行动， 救火行动，当 排在队列之首
评估后按优先 级在队列排队
维
拒绝 采取的行动 接受
护
通知请求者 并说明原因 按优先级在 队列中排队
过 程
从维护请求队列之首取出一任务 按SE方法学规划、组织、实施工程 SE方法学规划、组织、 方法学规划 y 队列中还有维护请求吗？ 队列中还有维护请求吗？
17
• 保存的数据： 保存的数据：
程序名称 源程序语句条数 机器代码指令条数 所用的程序设计语言 程序安装的日期 程序安装后的运行次数 与程序安装后运行次数有关的处理故障次数
18
程序改变的层次及名称 修改程序增加的源程序语句条数 修改程序减少的源程序语句条数 每次修改所付出的“人时” 每次修改所付出的“人时”数 修改程序的日期 软件维护人员的姓名 维护申请报告的名称、 维护申请报告的名称、维护类型 维护开始时间和维护结束时间、 维护开始时间和维护结束时间、 花费在维护上的累计“人时” 花费在维护上的累计“人时”数 维护工作的净收益等。 维护工作的净收益等。
19
维护评价
• 如果已经开始保存维护记录， 如果已经开始保存维护记录，可以对维护工作做 一些定量度量，至少可以从如下7方面进行评价： 一些定量度量，至少可以从如下7方面进行评价：
每次程序运行平均失败的次数； 每次程序运行平均失败的次数； 用于每一类维护活动的总人时数； 用于每一类维护活动的总人时数； 平均每个程序、每种语言、 平均每个程序、每种语言、每种维护类型所必需的程 序变动数； 序变动数； 维护过程中增加或删除源语句平均花费的人时数； 维护过程中增加或删除源语句平均花费的人时数； 维护每种语言平均花费的人时数； 维护每种语言平均花费的人时数； 一张维护请求表的平均周转时间； 一张维护请求表的平均周转时间； 不同维护类型所占的比例。 不同维护类型所占的比例。