软件工程 | 第七章 系统维护

admin管理员组

文章数量:1646321

软件工程 系列为本学期（2020春季）软件工程以及软件工程实践课程笔记整理~

---

问题1：针对一个软件系统，在不给代码和文档的情况下如何进行软件维护 ？

问题2：结合自己的实际经验，谈谈如何提升系统的可维护性？

软件交付给用户之后，生命周期进入系统维护阶段。

系统维护：

(1)改正软件运行过程中发生的故障和错误，软硬件维护人员对系统进行必要的修改与完善

(2)对原系统做局部系统更新与改变-->适应用户环境的变化、满足用户提出的新的需求

系统维护在软件生命周期过程中经历的时间最长，任务最为繁重

ps:问题1是老师上课的时候提出的，问题2是在整理完这章节内容的时候自己想到的

---

目录

1.软件维护的原因

2.软件维护的定义

3.软件维护的特点

4.软件维护的费用

5.软件维护的种类

6.软件维护的方法和技术

7.软件维护过程

8.软件维护管理

9.软件可维护性及其度量

10.提高软件可维护性的方法

---

 

1.软件维护的原因

(1)原有的功能和性能不再适应用户的要求；

(2)工作环境发生了变化，软件需要进行相应的变更，比如增加了新的外部设备;

(3)软件运行过程中发生了错误，需要进行修改;

为解决软件中存在的问题而进行的维护活动：问题分析和确认、代码的识别与修改、软件修改后的一系列活动(软件测试、版本配置更新等)

 

2.软件维护的定义

IEEE：软件维护时软件发行之后，修改软件系统和其组件以修正错误、提升性能和其他属性以及适应产品环境改变的过程

这种将软件维护限定为交付之后才发生的行为观点是缺乏远见的-->会使得软件维护更加困难

软件维护：对软件系统提供划算的支持和所有行为的统称，包括软件交付前和软件交付后

  交付前-->交付后的运行计划、支持、后勤保障管理

  交付后-->软件修改、培训和运行

 

 

3.软件维护的特点

如果软件产品完成后没有系统分析、设计、实现以及测试等详细的技术文档，而只有源代码-->维护活动非常困难，对代码的解析和阅读可能会产生错误

如果有完整的软件配置存在(每一个过程都有详细的文档可供查询)，维护工作将变得非常有序

(1)维护代价高，时间漫长：使用期间用户的环境发生变化或者用户产生新的需求

(2)软件维护小心翼翼，严防错误：要求从业人员有高超的软件技术和足够的细心

软件维护过程中可能会引入不需要的错误活动-->软件维护的副作用，包括修改代码、修改数据和修改文档的副作用

(3)软件维护苦难重重，理解为上：软件维护人员不一定是早期的开发人员，要完全理解设计与开发人员的思想非常困难

• 阅读和理解他人程序比较困难——困难程度随软件配置成分减少而迅速增加
• 没有必需的文档、文档资料显著不足
• 软件生命周期长
• 软件在设计时没有考虑到将来的修改问题
• 软件维护在开发企业中没有受到足够重视
• 软件多次维护和升级使得软件状态的跟踪变得十分困难

4.软件维护的费用

(1)影响维护费用的因素：系统规模、程序设计语言、系统使用年限、设计过程采用的技术、软件开发过程的管理技术

(2)Belady的统计公式

M:总的维护费用

P:生产性活动工作量

K:经验常数

C：非结构化维护引起的程序复杂度

D：对软件的熟悉程度

 

5.软件维护的种类

(1)完善性维护

在用户对软件提出新的功能和性能要求时

扩充软件功能、增强软件性能、改进加工效率来提高软件的可维护性

(2)改正性维护

定位、识别和纠正错误，完善软件性能上的缺陷以及一系列的回归测试

(3)适应性维护

用户的软件外部环境(软硬件配置)或者数据环境(数据库、数据格式)发生变化，使软件适应这些需求的变化，eg：升级操作系统

(4)预防性维护

使用软件重用等先进的软件工程方法，对需要维护的软件或者其中一部分进行重新设计、编制和测试-->增加预防性新功能

 

6.软件维护的方法和技术

在具备完备的技术文档的前提下：

(1)快速修复模型

基本过程：修改编码，然后对相应的文档(被修改影响的)进行必要的修改

存在的问题：受时间限制，软件维护缺乏合适的计划、设计、影响分析和回归测试；软件系统的可维护性会下降

(2)迭代维护方法

       过程：系统维护从分析现有系统的需求、设计、编码和测试文档开始，进而修改受影响的高级说明文档，再将这种修改应用到所有的系统文档；进化过程的每一步都是根据对现有系统的分析而对系统进行再设计的

特点：文档可以随着代码的改变而进行更新

 

 

在没有相应的各种软件文档的情况下：

(3)软件逆向工程

• 基本概念：从可以运行的系统出发，运用解密、反汇编、系统分析、程序理解等多种计算机技术，对软件的系统结构、程序流程、算法以及代码进行逆向拆解和分析，从而推导出软件产品的源代码、设计原理、结构、算法、处理过程、运行方法以及相关文档等的过程
• 面临的情况：软件系统的文档和源代码已经不存在，但需要对软件系统进行必要的功能更新和错误改正-->应用软件逆向工程
• 与软件正向工程对应，逆向工程：对系统进行分析和抽象以确定系统的构成以及内部联系

• 逆向工程的分析方法
  • 静态分析方法(不对程序进行操作，从表面和内容进行分析)
    • 词法分析和语法分析：分析程序的源代码-->变量定义以及相关的数据结构
    • 图形、图表法：清晰表示程序的流程和功能
    • 程序切片：针对较长程序段，根据跳转语句、判断语句等将程序分成较小的片段-->每个小片段的功能单一，容易理解
  • 动态分析方法(监视并获取系统运行时产生的动态信息)
    • 代码植入法：添加软件触发器(运行时会按照特定的协议将指定的动态信息传递到指定位置，或者传递给动态信息收集机制)
    • 调试器：前提是要找到有意义的中断点，才能观察中断点处的程序状态；另外不一定有合适的调试器

 

针对缺乏良好的设计结构和编码风格的软件系统

(4)软件再工程

• 基本概念：检测、分析和更替现有系统，实现对已存在的软件系统的新形式重构；目的是理解已有的软件系统，然后对它重新设计实现以增强功能；包括逆向工程、文档重构、结构重构、相关转换以及正向工程。
• 目标
  • 为追加、增强功能做准备
  • 提高可维护性
  • 增强可移植性
  • 提高可靠性：长期的软件维护使得系统的稳定性和可维护性逐渐降低
• 过程
  • 分析现存系统：对基本没有进行修改的部分不重新考虑需求；对多次修改变得不稳定而且维护困难的部分，考虑在新环境下的功能和性能重构
  • 文档重构：稳定的功能模块-->文档藐视保持现状；必须进行重构的关键功能模块-->重构文档
  • 逆向工程，即设计重构：在充分分析源代码的基础上抽象出比源代码更高层次的程序表示
  • 代码重构
  • 数据重构
• 再工程的过程会面临风险，如过程风险、应用领域风险和技术风险等

 

7.软件维护过程

(1)目前有一些可以参考的过程模型，不同维护模型对维护阶段的划分不同，但有3个核心活动集：对现有系统的理解、对拟定变更产生影响的评估、回归测试

(2)IEEE维护过程

问题的标识与分类：提出修改要求时，分析问题的原因和性质，给问题分配维护类别、优先级和唯一标识

问题的需求分析：分析程序，了解问题解决前后程序本身的变化和影响；

                             分为可行性分析(选择解决方法，评估影响和开销)和详细分析(定义修改的要求、执行测试策略和实施计划)两个层面；

问题维护设计：定义最终的修改形式，包括标识被影响的数据、确定受影响的软件模块、隔离不受影响的软件单元、分类软件模块的重要性等

问题维护实施：代码修改、单元测试、修改后与原来程序的整合、集成测试和回归测试、风险分析和审查

回归和系统测试：整个系统在此阶段都要进行测试，并且准备验收测试

接受测试：基于客户或者最终用户的规格书的最终测试

软件发布：提交完整的维护报告、以及维护后的各种文档，发布可安装和运行的修改后的系统版本

 

(3)ISO-12207维护过程模型

过程实施：开始于软件生命周期的初级阶段，维护计划与软件开发计划并行进行

                         为软件维护制定开发计划和程序，创建接收、记录和跟踪维护请求的流程，利用配置管理过程建立组织接口

问题以及修改分析：分析维护的要求，将问题进行归类-->确定占用的开发规模等

实施修改：申明修改的项目以及使用的开发过程

审查\验收维护：评价修改后系统的完整性

系统迁移：软件系统从一个环境迁移到另一个

软件退化：软件退出运行

 

8.软件维护管理

(1)管理关注的是质量和生产效率——即收益与效率，管理包括五个分离的过程：制定计划、组织管理、人员编制、领导实施和管理措施

(2)维护计划的管理

• 计划工作的好坏决定着软件维护工作完成的质量
• 计划的内容：时间、费用、人员、与此相关的一系列质量保证和管理活动

(3)维护组织管理

• 软件维护首先要建立维护组织，建立维护活动的登记、申请制度以及对维护方案的审批制度，规定复审的评价标准
• 基本结构

  维护管理员：评审维护申请、安排维护工作以及软件测试

  维护人员：在维护管理员和系统管理员的指导下对软件进行修改

  配置管理员：审查和修改软件配置-->得到及时更新并匹配新的软件系统

   

 (4)维护流程管理

软件维护申请：一般由用户提出，填写详细的软件维护申请书：申请维护内容、优先级和希望实现的结果

维护工作流程：申请、分析维护-->实施维护过程(对整个过程有详细的记录)-->测试(多为集成测试)与评审

维护活动评价：考核软件代码的质量、度量维护活动过程

 

9.软件可维护性及其度量

(1)软件可维护性：能够被理解、纠正软件系统中出现的错误和缺陷、为满足新的系统需求进行修改、扩充或者压缩的容易程度

可理解性：非程序设计和编码人员理解软件结构、功能、接口和内部处理过程的难易程度

可测试性

可修改性：容易修改的程度与设计原理和启发规则有关，遵循良好的设计原则(高内聚、低耦合)会使修改变得容易

可移植性：把程序从一种计算环境移植到另一种计算环境的难易程度；在早期进行需求分析和设计时就应该考虑；外部接口是最容易发生可移植性问题的地方

可重用性：软件环境和功能发生变化后，不做修改或者稍加改动就可以用于新环境

                 软件重用分为代码重用、设计重用、规范重用和概念重用

                 提高可重用性的方法：采用模块化的程序设计，建立标准统一的数据接口

效率：程序执行预定的功能而又不浪费机器资源的程度

可使用性：程序方便、使用以及易于使用的程度

(2)度量一个软件可维护性的常用方法：质量检查表、质量检测和质量标准

(3)度量软件可维护性的质量特性

可分析性、可修改性、稳定性(软件维护后发生故障的频率)、可测试性、依从性(度量软件中符合与维护性相关的标准的能力)

 

10.提高软件可维护性的方法

(1)建立明确的软件质量目标：不可能同时满足软件可维护性的7种质量特性，在质量特性上有所侧重

(2)使用先进的软件开发工具和技术

目前常用的软件开发方法：模块化开发方法、结构化程序设计方法、面向对象开发方法和面向构件的开发方法

(3)健全明晰的软件质量保证手段——质量审查

• 在检查点进行审查：在软件开发所有阶段考虑质量需求，在声明周期每个阶段的终点设置检查点进行检查

• 验收检查：是验收测试的一部分，交付给用户前的最后一次检查-->需求标准检查、设计标准检查、代码标准检查和文档资料的检查
• 周期性维护审查
• 对软件包进行检查

(4)选择容易维护的程序设计语言：高级语言的维护相对容易

(5)提供完整一致的技术文档

问题1：主要从软件逆向工程和再工程的角度去回答

问题2：可以从最后一部分提高软件可维护性的方法的角度，还可以结合第8部分，规范化管理软件维护过程

---

周日以来感觉自己状态不太好，每天超级困，一开始不知道怎么了，昨天看到桌子上的藿香正气胶囊，傻乎乎吃了两个，中午睡醒来之后好了很多，哈哈哈哈

今天开始准备返校需要的东西了，妈妈有点忙，他们很辛苦，就自己准备好所需要的东西吧

明天上午的课貌似要有小测验，早晨简单复习一下吧

今天还是大学室友的生日，想念和大家在一起的时候，每次准备小礼物比自己生日还要开心

快到期末啦，预计要忙碌起来啦，lhhhhh，加油喽

(附上可爱的一二照片吧，今天发现手机壳被自己摔了一道裂纹，超级心疼。。。)

 

 

本文标签： 软件工程第七章系统维护