软件工程第7章 软件维护与再工程
《软件工程》PPT课件
第一章第四课时
喷泉模型 软件工程的任务与研究范围 软件开发的原则与开发方法
返回
喷泉模型
瀑布模型要求在软件开发的初期就完全确定软件的需求,这在很多 情况下往往是做不到的.螺旋模型试图克服瀑布模型的这一不足.SM 把软件开发过程安排为逐步细化的螺旋周期序列,每经历一个周期, 系统就细化和完善一些.SM每—螺旋周期由六个步骤组成： <1> 确定任务目标： 根据初始需求分析项目计划,确定任务目标、可选 方案和限制.<2>选择对象：对各种软硬件设备、开发方法、技术、 开发工具、人员、开发管理等对象进行选择：并决定软件是进行研 制、购买还是利用现有的.<3>分析约束条件：软件开发的时间、经 费等限制条件.<4>风险分析：评估目标、对象、约束条件三者之间 的联系,列出可能出．现的问题及问题的严重程度等,把最重要的问 题作为尚未解决的关键问题的风险.<5>制定消除风险的方法：应有 详尽的说明和周密的计划,并估计可能产生的后果.依此来开发软件, 为制订下一周期的计划打下基础.<6>制定下一周期的工作计划：在 第一个螺旋周期,确定目标、选择对象、分析约束,通过风险分析制 订消除风险的方法,初步开发原型1,制定系统生存周期计划.
软件工程的任务与研究范围
•软件产品的特点 •软件工程的研究内容与方法 •软件工具与软件支撑环境 •软件管理
软件开发的原则与方法
•软件开发的原则 • 自顶向下与模块结构 •软件开发的方法 •1.非自动形式的系统开发方法 •〔1〕系统流程图〔2〕结构分析法〔3〕结构化设计法 •〔4〕数据结构法〔5〕层次输入——处理——输出方法<HIPO法> • 2.半自动形式的系统开发方法 •〔1〕软件需求工程法〔2〕问题说明语言与分析法 • 3. 自动形式的系统开发方法 〔HOS方法〕：由计算机自动确定规 范、自动分析、自动编程、自动执行与模拟,以规范语言AXES、资 源分配工具RTA为工具.能自动进行分析、设计,工作量少、设计规范, 也能自动进行修改和维护.该方法适用于系统分析和设计.
软件工程自考课程内容大纲
（一）课程内容第1节软件工程的产生第2节软件工程过程和软件生存周期第3节软件生存周期模型、方法和工具（二）考核知识点与考核要求第1节软件工程的产生1. 软件的特点，要求达到识记层次。
2. 软件生产的发展，要求达到识记层次3. 软件危机的产生、表现、原因，要求达到领会层次。
4. 软件工程的定义、性质、目标、内容、面临的问题，要求达到领会层次。
第2节软件工程过程和软件生存周期1. 软件工程过程概念，要求达到识记层次。
2. 软件生存周期概念，要求达到识记层次。
第3节软件生存周期模型、方法和工具1. 软件生存周期模型1.1 软件生存周期模型的定义、重要性，要求达到识记层次。
1.2 软件生存周期模型的作用、准则，要求达到识记层次。
1.3 瀑布模型、增量模型、螺旋模型、喷泉模型、变换模型、基于知识的模型，要求达到识记层次。
2. 软件开发方法2.1 软件开发目标，要求达到识记层次。
2.2 方法的作用和重要性，要求达到识记层次。
2.3 结构化方法、Jackson方法、维也纳方法、面向对象方法，要求达到识记层次。
3. 软件开发工具3.1 工具的重要性，要求达到识记层次。
3.2 工具箱，要求达到识记层次。
3.3 开发环境，要求达到识记层次。
3.4 计算机辅助软件工程，要求达到识记层次。
第2章软件可行性研究与项目开发计划（一）课程内容第1节可行性研究第2节系统流程图第3节成本－－效益分析第4节项目开发计划（二）考核知识点与考核要求第1节可行性研究1.可行性研究的任务，要求达到识记的层次。
2.可行性研究的具体步骤，要求达到领会层次。
第2节系统流程图，要求达到识记层次。
第3节成本－－效益分析1.投资回收率达到识记层次。
2.回收期要求达到识记层次。
3.纯收入要求达到识记层次。
第4节项目开发计划，要求达到识记层次第3章软件需求分析（一）课程内容第1节需求分析的任务第2节结构化分析方法第3节数据流图（DFD）第4节数据字典（DD）第5节加工逻辑的描述第6节 IDEF方法第7节结构化分析方法小结（二）考核知识点与考核要求第1节需求分析的任务1.需求分析的概念，要求达到识记层次2.需求分析的基本任务，要求达到领会层次第2节结构化分析方法1.结构化分析方法，要求达到识记层次2.结构化分析步骤，要求达到领会层次第3节数据流图（DFD）1.数据流图，要求达到识记层次2.数据流图中的符号、画数据流图注意的事项，要求达到领会层次。
软件工程师中的软件维护与迭代
软件工程师中的软件维护与迭代随着科技的飞速发展，软件工程师的作用愈发突出。
在软件的生命周期中，软件维护与迭代是软件工程师不可或缺的一环。
本文将从软件维护与迭代的概念、目的与流程，以及软件工程师在其中的重要角色等方面进行探讨。
第一章软件维护的概念与目的软件维护是指对现有软件系统的修改、修正、增强和优化等活动。
其目的是确保软件系统能够持续运行并适应不断变化的需求。
1.1 软件维护的分类根据维护对象的不同，软件维护可分为以下几类：纠错性维护、适应性维护、完善性维护和预防性维护。
1.2 软件维护的重要性软件维护是保障软件系统稳定性和可用性的关键环节。
一个良好的软件维护能够提高软件系统的质量、可靠性和安全性。
第二章软件迭代的概念与流程软件迭代是指对软件系统的持续改进与优化。
通过不断迭代，软件系统能够跟上时代发展的步伐，适应用户需求的变化和市场竞争的挑战。
2.1 软件迭代的定义软件迭代是在软件系统中引入新功能、修复缺陷、改进性能等的过程。
它通常按照短期的开发周期来进行，以便及时响应用户的需求。
2.2 软件迭代的流程软件迭代通常包括以下几个关键步骤：需求收集与分析、系统设计、编码与测试、发布与反馈、优化与重构。
每个步骤都需要软件工程师的积极参与与协作。
第三章软件工程师在软件维护与迭代中的角色作为软件维护与迭代的关键参与者，软件工程师扮演着多重角色，发挥着重要作用。
3.1 需求专家软件工程师在软件维护与迭代过程中，负责收集用户反馈，理解用户需求，并将其转化为可行的技术方案。
3.2 架构师软件工程师在软件迭代中，负责设计系统的整体结构和架构，确保软件系统的可扩展性和可维护性。
3.3 开发者软件工程师在软件维护与迭代中，负责编码、调试和测试等具体的开发工作，确保软件系统的质量与稳定性。
3.4 测试人员软件工程师在软件迭代中，承担着软件系统的测试工作，确保新功能的正确性和可靠性。
3.5 故障处理专家软件工程师在软件维护中，负责处理系统故障和缺陷，确保及时修复并提供技术支持。
《软件工程导论》课后习题答案
作业及解答（第3章）
• 数据结构的描述 符 号
＝ ＋
含 义
x = a＋b
举
例
被定义为 与 或
[...,...] 或 [...|...] { ... }或 m{...}n (...) “...” ..
23:59:38
x = [a , b]，x = [a | b] 重复 x = {a}， x = 3{a}8 可选 x = (a) 基本数据元素 x = “a” 连结符 x = 1..9
P1 记录存款信息
P2 打印存单 F5存款信息 F3存单 E1 储户 F4利息
F5存款信息 D1存款信息 F7密码 F2取款单
F5存款信息 P3 核算密码
F4利息 F4利息 F6取款信息 P6 设置利率 P4 计算利息
P5 打印利息清单 F8储蓄利率
E2 业务员
23:59:38
F8储蓄利率
F8储蓄利率
23:59:38
重庆工学院计算机科学与工程学院 李梁(liliang@) 李梁
作业及解答（ 作业及解答（第3章）
23:59:38
重庆工学院计算机科学与工程学院 李梁(liliang@) 李梁
作业及解答（ 作业及解答（第3章）
• 3-6 复印机的工作过程大致如下：未接到复印 命令时处于闲置状态，一旦接到复印命令则进 入复印状态，完成一个复印命令规定的工作后 又回到闲置状态，等待下一个复印命令；如果 执行复印命令时发现没纸，则进入缺纸状态， 发出警告，等待装纸，装满纸后进入闲置状态， 准备接收复印命令；如果复印时发生卡纸故障， 则进入卡纸状态，发出警告等待维修人员来排 除故障，故障排除后回到闲置状态。 • 请用状态转换图描绘复印机的行为。
(完整版)软件工程 判断题
判断题：第1章概述1。
由于今天个人计算机不断发展壮大，人们不再采用软件团队的开发方式。
（×)2。
由于软件是产品，因此可以应用其他工程制品所用的技术进行生产。
(×）3. 购买大多数计算机系统所需的硬件比软件更昂贵.（×）4。
大多数软件产品在其生命周期中不需要增强功能。
（×)5。
大多数软件系统是不容易变化的,除非它们在设计时考虑了变化。
（√）6. 一般来说，软件只有在其行为与设计者的目标一致的情况下才能成功。
（×）第4章需求工程1. 在需求分析过程中，分析员要从用户那里解决的最重要的问题是明确软件做什么。
（√）2. 软件需求规格说明书在软件开发中具有重要的作用，它是软件可行性分析的依据。
（×）第5章面向对象基础1. 模型是对现实的简化，建模是为了更好地理解所开发的系统。
(√）2。
UML语言支持面向对象的主要概念，并与具体的开发过程相关。
(×)第6章面向对象分析1. 面向对象分析的核心在于建立一个描述软件系统的模型。
（×）第7章软件体系结构设计1. 系统体系结构的最佳表示形式是一个可执行的软件原型。
(×）2. 软件体系结构描述是不同项目相关人员之间进行沟通的使能器.（√）3. 良好的分层体系结构有利于系统的扩展与维护。
(√）4。
消除两个包之间出现的循环依赖在技术上是不可行的.（×）5. 设计模式是从大量成功实践中总结出来且被广泛公认的实践和知识。
(√）第8章面向对象设计1。
面向对象设计是在分析模型的基础上,运用面向对象技术生成软件实现环境下的设计模型.（√）2。
系统设计的主要任务是细化分析模型，最终形成系统的设计模型.（×）3。
关系数据库可以完全支持面向对象的概念，面向对象设计中的类可以直接对应到关系数据库中的表。
（×)4。
用户界面设计对于一个系统的成功是至关重要的，一个设计得很差的用户界面可能导致用户拒绝使用该系统。
第9课软件工程基础知识
7.4、系统设计知识
耦合是软件结构中各个模块之间相互关联程度的度量。 非直接耦合：如果两个模块没有没有直接关系，它们之间的联系完全是 通过主程序的控制和调用来实现的。 数据耦合：如果两个模块借助于参数表传递简单数据。 标志耦合：如果两个以上的模块都需要其余某一数据结构子结构时，不 使用全局变量的方式而是用记录传递的方式 控制耦合：如果一模块明显地把开关量、名字等信息送入另一模块，控 制另一模块的功能。 外部耦合：当模块与软件以个的环境有关时就发生外部耦合。例如：输 入输出把一个模块与特定的设备、格式、通信协议耦合在一起。 公共耦合：多个模块引用一全局数据区的模式。例如C语言中的external 数据类型、磁盘文件等都是全局数据区。 内容耦合：一个模块访问另一模块的内部数据；一个模块不通过正常入 口转到另一模块内部；两个模块有部分程序代码重叠；一个模块有多个 入口；
7.4、系统设计知识
内聚是一模块内部各个元素彼此结合的紧密程度的度量 偶然内聚：如果一个模块完成一组任务，这组任务彼此间即使有关系， 其关系也是松散的。 逻辑内聚：把几种逻辑上相关的功能组合在一起，每次被调用时，由传 送给的模块参数来确定该模块应完成哪一种功能。 时间内聚：如果一个模块所包含的任务必须在同一时间间隔内执行，这 个模块属于时间内聚，例如初始化模块。 过程内聚：如果一个模块的处理元素是相关的，而且必须按特定的次序 执行。 通信内聚：如果一个模块的所有功能都通过使用公用数据而发生关系。 顺序内聚：如果一个模块的处理元素是相关的，而且必须顺序执行，通 常一个处理元素的输出数据作为下一下处理元素的输入数据。 功能内聚：如果一个模块包括且仅包括为完成某一具体任务所必须的所 有成份，或者说模块中所有成分结合起来是为了完成一个具体的任务。
软件技术第07章
（2）半自动形式的开发方法
① 软件需求工程法 ② 问题说明语言/分析器 问题说明语言/
3．自动形式的系统开发方法
7.2 结构化分析方法
7.2.1 SA方法的特点 1．分解和抽象 2．文档的规范化 3．面向用户 4．系统的逻辑设计和物理 设计分开进行
7.2.2 数据流程图 1．数据流程图的概念
一般来说， 一般来说，结构图包括以下四种成 分。
（1）模块
模块用矩形框表示， 模块用矩形框表示，矩形框中标明 模块的名称，它反映该模块的功能。 模块的名称，它反映该模块的功能。
（2）调用
在结构图中， 在结构图中，用带有箭头的连线表 示模块之间的调用关系。 示模块之间的调用关系。
（3）模块间信息传递
图7.2所示的是一个描述研究生从入学 所示的是一个描述研究生从入学 到毕业的业务活动的数据流程图。 到毕业的业务活动的数据流程图。
2．数据流程图的组成符号
一般来说， 一般来说，数据流程图由四种基本成 分构成：数据流、数据处理、 分构成：数据流、数据处理、数据存储和 外部实体。 外部实体。 它们的符号如图7.3所示 所示。 它们的符号如图 所示。
（2）程序的动态分析
程序的动态分析是使用测试用例在计 算机上运行程序， 算机上运行程序，使程序在运行过程中暴 露错误。 露错误。
（3）自动测试工具
自动测试工具实际上是人们编制的用 于测试的软件，并用它来代替人工测试。 于测试的软件，并用它来代替人工测试。
3．测试的层次
（1）模块测试
模块测试又称单元测试。 模块测试又称单元测试。 模块测试的目标是发现局部模块的逻 辑与功能上的错误和缺陷。 辑与功能上的错误和缺陷。 它主要对以下几个方面进行测试。 它主要对以下几个方面进行测试。
软件工程学维护
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、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
3. 软件维护实施
开发组可承担软件初期维护，但当软件转入正 常使用以后，其维护工作则一般由专门的维护 机构承担。软件维护机构人员组成有：维护负 责人、系统监督员、配置管理员、维护工程师。 其中，维护负责人全权负责维护任务，包括技 术与管理两个方面的工作。
4. 软件再工程
软件再工程是指对已存在软件系统的重构与扩 充。
再工程主要用于一些老系统改造，所涉及活动 有：逆向工程、重构工程、正向工程。
典型的软件再工程过程模型如下图所示。在某些情况下这 些活动以线性顺序发生，但也并非总是这样。例如，为了理 解某个程序的内部工作原理，可能在文档重构开始之前必须 先进行逆向工程。
在维护活动开始之前就明确维护 责任是十分必要的，这样做可以大大 减少维护过程中可能出现的混乱。
维护管理员
转交维护要求
系统管理员
评价后上交， 促成决定活动
指定维护人员
程序技术人员
变化授权人
2. 维护报告
应该用标准化的格式表达所有软件维护要求。 软件维护人员通常给用户提供空白的维护要求表—— 有时称为软件问题报告表，这个表格由要求一项维护活动 的用户填写。如果遇到了一个错误，那么必须完整描述导 致出现错误的环境(包括输入数据、全部输出数据以及其他 有关信息)。 对于适应性或完善性的维护要求，应该提出一个简短 的需求说明书。如前所述，由维护管理员和系统管理员评 价用户提交的维护要求表。
哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供 的反馈信息对有效地管理软件组织十分重要。
4. 保护维护记录
哪些数据是值得记录的？
Swanson提出了：
1程序标识；2源语句数；3机器指令条数；4使用的程序设计语言；5 程序安装的日期；6自从安装以来程序运行的次数；7自从安装以来程 序失效的次数；8程序变动的层次和标识；9因程序变动而增加的源语 句数；10因程序变动而删除的源语句数；11每个改动耗费的人时数； 12程序改动的日期；13软件工程师的名字；14维护要求表的标识；15 维护类型；16维护开始和完成的日期；17累计用于维护的人时数；18 与完成的维护相联系的纯效益。
和用户文档类似，系统文档的结构也应该能把读 者从对系统概貌的了解，引导到对系统每个方面每个 特点的更形式化更具体的认识。
可维护性复审
为什么要进行可维护性复审？
可维护性是所有软件都应该具备的基本特点，必须在开发 阶段保证软件具有可维护因素。
在完成了每项维护工作之后，都应该对软件维护本身进行 仔细认真的复审。
不能准确反映软件当前状态的设计文档可能比完全没有文 档更坏。
如果对软件的可执行部分的修改没有及时反映在用户文档 中，则必然会使用户因为受挫折而产生不满。
在软件再次交付使用之前，对软件配置进行严格的复 审，则可大大减少文档的问题。
在需求分析阶段的复审过程中，应该对将来要改进的 部分和可能会修改的部分加以注意并指明；应该讨论 软件的可移植性问题，并且考虑可能影响软件维护的 系统界面。
5.可重用性
所谓重用（reuse）是指同一事物不做修改或稍加改动 就在不同环境中多次重复使用。大量使用可重用的软件构件 来开发软件，可以从下述两个方面提高软件的可维护性。 (1) 通常，可重用的软件构件在开发时都经过很严格的测试， 可靠性比较高，且在每次重用过程中都会发现并清除一些错 误，随着时间推移，这样的构件将变成实质上无错误的。因 此，软件中使用的可重用构件越多，软件的可靠性越高，改 正性维护需求就越少。 (2) 很容易修改可重用的软件构件使之再次应用在新环境中， 因此，软件中使用的可重用构件越多，适应性和完善性维护 也就越容易。
维护将由申请报告启动，其一般由软件用户提 出。维护机构则对维护申请进行评审。维护活 动需要记录存档，需要进行评价。
维护实施过程的本质
维护实施过程本质上是修改和压缩了的软件定义和开发过 程，而且事实上远在提出一项维护要求之前，与软件维护有 关的工作已经开始了。 首先必须建立一个维护组织 随后必须确定报告和评价的过程 而且必须为每个维护要求规定一个标准化的事件序列
1.库存目录分析
每个软件组织都应该保存其拥有的所有应用系统的库 存目录。该目录包含关于每个应用系统的基本信息
（例如应用系统的名字，最初构建它的日期，已做过的实质性修改次
数，过去18个月报告的错误，用户数量，安装它的机器数量，它的复杂 程度，文档质量，整体可维护性等级，预期寿命，在未来36个月内的预
维护要求表是一个外部产生的文件，它是计划维护
活动的基础。软件组织内部应该制定出一个软件修改报 告，它给出下述信息。 (1) 满足维护要求表中提出的要求所需要的工作量。 (2) 维护要求的性质。 (3) 这项要求的优先次序。 (4) 与修改有关的事后数据。 在拟定进一步的维护计划之前，把软件修改报告提交给 变化授权人审查批准。
此外，还应该建立一个适用于维护活动的记录保管过程， 并且规定复审标准。
1. 维护组织
虽然通常并不需要建立正式的维 护组织，但是，即使对于一个小的软 件开发团体而言，非正式地委托责任 也是绝对必要的。
每个维护要求都通过维护管理员 转交给熟悉该产品的系统管理员去评 价。系统管理员是被指定去熟悉一小 部分产品程序的技术人员。系统管理 员对维护任务做出评价之后，由变化 授权人决定应该进行的活动。
不同类型的维护强调的重点不同，但是基本途径是相同的。 维护事件流中最后一个事件是复审，它再次检验软件配置 的所有成分的有效性，并且保证事实上满足了维护要求表 中的要求。
软件 维护工作 流程如左 图所示。
在完成软件维护任务之后，进行处境复查常常是有好
处的。一般说来，这种复查试图回答下述问题。
在当前处境下设计、编码或测试的哪些方面能用不同方 法进行?
第7章 软件维护与再工程
软件维护分类 软件可维护性 软件维护实施 软件再工程
1. 软件维护分类
所谓软件维护就是在软件已经交付使用之后，为了 改正错误或满足新的需要而修改软件的过程。 可以通过描述软件交付使用后可能进行的以下4项 活动，具体地定义软件维护。 改正性维护 完善性维护 适应性维护 预防性维护
1. 可理解性
软件可理解性表现为外来读者理解软件的结构、功 能、接口和内部处理过程的难易程度。
模块化（模块结构良好，高内聚，松耦合）、详细 的设计文档、结构化设计、程序内部的文档和良好的 高级程序设计语言等，都对提高软件的可理解性有重 要贡献。
2. 可测试性
诊断和测试的容易程度取决于软件容易理解的程度。
适应性维护和完善性维护的要求沿着相同的事件流通
路前进。应该确定每个维护要求的优先次序，并且安排要 求的工作时间，就好像它是另一个开发任务一样。如果一 项维护要求的优先次序非常高，可能立即开始维护工作。
不管维护类型如何，都需要进行同样的技术工作。包 括：
修改软件设计、复查、必要的代码修改、单元测试和集成测试(包 括使用以前的测试方案的回归测试)、验收测试和复审。
3. 可修改性
软件容易修改的程度和本书第5章讲过的设计原理和启 发规则直接有关。耦合、内聚、信息隐藏、局部化、控制 域与作用域的关系等，都影响软件的可修改性。
4. 可移植性 软件可移植系统）转移到另一种计算环境的难易程度。把 与硬件、操作系统以及其他外部设备有关的程序代码集中 放到特定的程序模块中，可以把因环境变化而必须修改的 程序局限在少数程序模块中，从而降低修改的难度。
2. 软件可维护性
可以把软件的可维护性定性地定义为： 维护 人员理解、改正、改动或改进这个软件的难易 程度。
影响软件可维护性的因素有：系统大小、系统 文档、系统年龄。
可通过软件的易理解性、可靠性、易修改性、 易移植性的评价，而对软件系统进行可维护性 综合评估。
决定软件可维护性的因素
维护就是在软件交付使用后进行的修改，修改之前必须理 解待修改的对象，修改之后应该进行必要的测试，以保证 所做的修改是正确的。如果是改正性维护，还必须预先进 行调试以确定错误的具体位置。因此，决定软件可维护性 的因素主要有下述5个。 1. 可理解性 2. 可测试性 3. 可修改性 4. 可移植性 5. 可重用性
良好的文档 软件结构 可用的测试工具 调试工具， 以前设计的测试过程 开发阶段用过的测试方案，以便维护人员进行回归测试。 在设计阶段应该尽力把软件设计成容易测试和容易诊断的。
对于程序模块来说，可以用程序复杂度来度量它的可测 试性。模块的环形复杂度越大，可执行的路径就越多，因 此，全面测试它的难度就越高。
应该为每项维护工作都收集上述数据。可以利用这些数据 构成一个维护数据库的基础。
5. 评价维护活动
可以从下述7个方面度量维护工作。
(1) 每次程序运行平均失效的次数。 (2) 用于每一类维护活动的总人时数。 (3) 平均每个程序、每种语言、每种维护类型所做的程序变 动数。 (4) 维护过程中增加或删除一个源语句平均花费的人时数。 (5) 维护每种语言平均花费的人时数。 (6) 一张维护要求表的平均周转时间。 (7) 不同维护类型所占的百分比。
修改
增加
旧版本
实际寿命 预期寿命
完善性维护
当一个软件系统顺利地运行时，常常出现第三项维护 活动：在使用软件的过程中用户往往提出增加新功能或修 改已有功能的建议，还可能提出一般性的改进意见。为了 满足这类要求，需要进行完善性维护。这项维护活动通常 占软件维护工作的大部分。
预防性维护
当为了改进未来的可维护性或可靠性，或为了给未来 的改进奠定更好的基础而修改软件时，出现了第四项维护 活动。这项维护活动通常称为预防性维护，目前这项维护 活动相对比较少。