软件工程之软件维护与再工程

文章链接:https://codemouse.online/archives/2020-05-29183056

软件维护

国标GB/T 11457-95定义:在一软件产品交付使用后对其进行修改,以纠正故障、改进其性能和其它属性,或使产品适应改变了的环境。

软件维护分类

新开发活动:强调要在一定的约束条件下从头开始实施。
软件维护:强调必须在现有系统的限定和约束条件下实施。
两种错误认识

  1. 软件维护是一次新的开发活动 。
  2. 软件维护就是改错 。

分类:

  • 纠错性维护:为了改正软件系统中的错误,使软件能够满足预期正常运行状态要求而进行维护。
  • 预防性维护:为了提高软件的可维护性、可靠性等,为以后进一步改进软件打下良好基础而修改软件的活动。
  • 适应性维护:为了使软件适应内部或外部环境变化而去修改软件的过程。
  • 改善性维护:满足使用过程中用户提出增加新功能或修改已有功能的建议维护。

软件维护方法

  • 结构化维护:采用软件工程的方法进行软件开发,保证每个阶段都有完整详细文档。
  • 非结构化维护:不采用软件工程方法开发软件,软件只有程序而欠缺文档,则维护工作将十分困难。

软件维护问题

  • 理解别人的代码通常非常困难
  • 需要维护的软件没有文档、或资料严重不足
  • 不能指望原来的开发人员来完成或提供解释
  • 绝大多数软件在设计时没有考虑到将来的修改
  • 软件维护这项工作毫无吸引力

软件维护成本

软件维护除费用外的无形代价包括:

  • 占用了其他软件开发可用的资源,使资源利用率降低。
  • 一些修复或修改请求得不到及时安排,使得客户满意率下降。
  • 引入新的潜在的错误,降低了软件质量。
  • 将软件人员抽调到维护工作中,使其它软件开发过程受到干扰。

影响软件维护因素

影响维护工作量的因素主要有以下六种:

  1. 系统的规模
  2. 程序设计语言
  3. 系统年龄
  4. 数据库技术的应用
  5. 先进的软件开发技术
  6. 其它一些因素

软件维护组织

维护组织结构图
软件工程之软件维护与再工程

软件维护过程

对工作安排队列中的任务,由修改负责人依次从队列中取出任务,按照软件工程方法学规划、组织、实施工程。
非纠错性维护:首先判断维护类型,对适应性维护,按照评估后的优先级放入队列。
改善性维护:要考虑是否采取行动,如果接受申请,按照评估后得到的优先级放入队列,如果拒绝申请,通知请求者,并说明原因。

每种维护请求都要进行同样的一系列技术工作:

  • 修改软件需求说明
  • 修改软件设计
  • 设计评审
  • 必要时重新编码
  • 单元测试、集成测试( 包括回归测试)、确认测试等

维护工作最后一步是复审:

  • 依照当前状态,在设计、编码和测试的哪些方面还能用其他方法进行?
  • 哪些维护资源可用但未用?
  • 这次维护活动中主要(或次要)的障碍有哪些?
  • 在维护请求中有预防性维护吗?

软件维护记录

  • 维护申请报告
  • 软件修改报告

软件可维护性

可维护性:指理解、改正、调整和改进软件的难易程度。

  • 可理解性
  • 可移植性
  • 可修改性
  • 可测试性

软件可维护性-可理解性

可理解性:指理解软件的结构、接口、功能和内部过程的难易程度。
提高软件可理解性的措施有:

  • 采用模块化的程序结构;
  • 书写详细正确的文档;
  • 采用结构化程序设计;
  • 书写源程序的内部文档;
  • 使用良好的编程语言;
  • 具有良好的程序设计风格等

软件可维护性-可测试性

可测试性:指测试和诊断软件(主要指程序)中错误的难易程度。
提高软件可测试性的措施有:

  • 采用良好的程序结构;
  • 书写详细正确的文档;
  • 使用测试工具和调试工具;
  • 保存以前的测试过程和测试用例等

软件可维护性-可修改性(主要影响因素)

可修改性:指修改软件(主要指程序)的难易程度。
在修改软件时经常会发生这样的情况:

  • 修改了程序中某个错误的同时又产生新的错误(由程序的修改引起的);
  • 或者在程序中增加了某个功能后,导致原先的某些功能不能正常执行。

软件可维护性-可移植性(主要影响因素)

可移植性:指程序转移到一个新的计算环境的难易程度。
影响软件可移植性的因素有:

  • 信息隐蔽原则;
  • 模块独立;模块化;
  • 高内聚低耦合;
  • 良好的程序结构;
  • 不用标准文本以外的语句等

提高可维护性的方法

通常采用的方法有:

  • 确定质量管理目标和优先级
  • 规范化程序设计风格
  • 选择可维护性高的程序设计语言
  • 改进程序文档
  • 保证软件质量审查方法

再工程技术

  • ****:在软件生存周期中,将软件的某种形式描述转换成更抽象形式的活动。
  • 重构:在同一抽象级别上转换系统的描述形式。
  • 设计恢复:借助工具从已有程序中抽象出有关数据结构设计、总体结构设计和过程设计的信息。

再工程的概念

  • 再工程:指在****所获信息的基础上修改或重构已有的系统,产生系统的一个新版本。

  • 再工程的主要目的:为遗留系统转化为可演化系统提供一条现实可行的途径 。

  • 再工程是一个工程过程,它将****、重构和正向工程组合起来,将现存系统重新构造为新的形式。

  • 通常再工程包含:业务过程再工程、软件再工程 。
    业务过程再工程定义业务目标、标示评估现有业务过程以及修订业务过程以更好满足业务目标。
    软件再工程包含库存目录分析、文档重构、****、程序和数据重构以及正向工程。这一部分通常由软件工程师完成 。

再工程的原因

  • 维护一行源代码的代价可能是最初开发该行源代码代价的14-20倍。
  • 重新设计软件体系结构时使用了现代设计概念,它对将来的维护会有很大的帮助。
  • 用户具有较多使用该软件的经验。
  • 利用****和再工程的工具,可以使一部分工作自动化。

业务过程再工程

  • 每个系统都是由不同的子系统构成,而子系统还可以再细分为更细的子系统,从而整个业务呈现一种层次结构
  • 让那些使用过程结果的人来执行流程;
  • 将信息处理工作合并到生产原始信息的现实工作中;
  • 将地理分散的资源视为它们是集中的;
  • 连接并行的活动以代替集成它们的结果;
  • 在工作完成的地方设置决策点,并将控制加入过程中;
  • 在其源头一次性获取数据。
  • 业务过程再工程是迭代的,没有开始和结束,只有不断的演化。
    软件工程之软件维护与再工程
  • 在业务过程被分析清楚后,可以对软件实施再工程,整个软件再工程过程模型如下
    软件工程之软件维护与再工程

****

  • 用户界面:理解旧软件的用户界面。
  • 数据:底层数据库和外部文件
  • 理解:系统,程序,部件,模式和语句