软件工程9-10-史济民

《软件工程9-10-史济民》由会员分享，可在线阅读，更多相关《软件工程9-10-史济民（42页珍藏版）》请在金锄头文库上搜索。

1、湘 潭 大 学 第9章 软软件维护维护 软件维护的种类 软件可维护性 软件维护的实施 软件维护的管理 软件配置管理 软件再工程 9.1 软件维护的种类 软件维护是软件生存周期花钱最多、延 续时间最长的活动。 典型情况是维护费：开发费=2：1。 软件维护是指软件系统交付使用后，为 了改正或满足新的需要而修改软件的过 程。 软件维护的最终目的是满足用户对已开 发产品的性能与运行环境不断提高的需 要，进而延长软件的寿命。 按照维护的具体目标，可分为4类： 完善性维护（perfective maintenance） 软件在使用期间不断改善和加强产品的功能与性 能。 完善性维护约占50-60% 。 适应

2、性维护（adaptive maintenance） 使软件适应运行环境的改变而进行的一类维护。 大约占整个维护的25% 。 纠错性维护（corrective maintenance） 在于纠正在开发期间未能发现的遗留错误。 约占总维护量的20% 。 预防性维护（preventive maintenance） 选择那些还能使用数年、目前虽能运行但不久就须 作重大修改或加强的软件，进行预先的维护 。 9.2 软件可维护性 可维护性是衡量维护难易程度的一种软件属性。 影响可维护性的软件属性 可理解性（understandability） 维护者不一定是设计者，软件文档完整、正确便于阅 读和理解，有利

3、于维护。 可修改性（modifiability） 软件开发遵循软件工程原则，其结构清晰，降低了复 杂度，便于修改，且修改带来副作用的概率较小。 可测试性（testability） 可测试性代表软件测试的难易程度。源程序良好的可 理解性、齐全的测试文档都能提高可测试性。 对可维护性的定量度 量 T.Gilb建议把维护过 程中各种活动耗费的 时间记录下来，并以 此来间接度量软件的 可维护性，他建议记 录10种时间。 1. 问题识别时间。 2. 管理延迟时间。 3. 收集维护工具时间。 4. 问题分析时间。 5. 修改规格说明书时间。 6. 改正（修改）时间。 7. 局部测试时间。 8. 整体测试时

4、间。 9. 维护复审时间。 10.分发与恢复时间。 提高可维护性的途径 提供完整和一致的文档 采用现代化的开发方法 9.3 软件维护的实施 不严重 维护 人员 纠错 严重 名单 测试 * 已修改的软件 适应 维护 人 * 维护 人员名单 完善 高 已修改的配置 批准交付 低 用户的配置 开发项 目表 严重性 评价 错误 分析 优先度 评价 维护 过程 配置 复审 问题 分析 区分 类型 纠错项 目表 软软件维护维护 的工作流程 维护 申请 维护的副作用 修改编码的副作用 修改数据的副作用 修改文档的副作用 9.4 软件维护的管理 维护的机构与人员 维护是软件开发单位的责任。 组织形式：高级管理

5、人员和专业人员组成修改控制 组。 管理内容：审批和批准维护申请，维护活动的计划 与安排，人力和资源的分配，批准并向用户分发维 护结果，对维护工作进行评价和分析。 具体责任者：原开发小组或专门的维护小组。 维护时期的配置管理 配置管理数据库 版本控制 变动控制 维护管理文档 两种常用的文档： 维护日志：评价维护有效性的主要依据。主要包括 3方面的内容。 第一，维护前程序的情况，如程序的名称，语句或 指令条数，所用语言，安装启用时间，运行的次数 和其中失效的次数等。 第二，维护中对程序修改的情况，如修改的级别， 增加或删除的源语句数，修改日期和修改者，每一 项改动耗费的人-时数等。 第三，其他重要

6、数据，如维护申请单编号，维护的 类型，维护的起止日期，耗用的总人-时数，维护 完成后的净收益等。 维护申请摘要报告和维护趋势图 ：前者是定 期报告，后者是不定期报告。主要内容为上 次报告以来已经处理了的，正在处理的和正 在处理项目新接到的维护申请项数以及处理 情况，以及新申请中特别紧迫的处理问题。 用途有为后续的开发项目提供经验，估算软 件维护后的质量提高或降低情况等。 维护费用的估算 软件维护可以看做是软件开发的一个缩影，维护的 工作量可以参照开发工作量来计算： MM维护=ACT*EAF*MM开发（人-月） ACT=(修改的指令条数+增加的指令条数)/指令总数 EAF为工作量调节因子。 9.

7、5 软件配置管理 软件配置管理（SCM）:对软件开发组所建立的 软件的修改进行标识、组织和控制的艺术，其 目标是减少错误和提高生产力。 从另一个角度对SCM的定义：配置管理能够系 统地处理变更，从而使得软件系统可以随时保 持其完整性。 SCM是一套规范、高效的软件开发基础，是整 个软件过程的软件质量保证活动之一，可应用 于整个软件过程的保护性活动。 软件配置管理的功能 系统地管理软件系统中的多重版本。 全面记载系统开发的历史过程。 管理和追踪开发过程中危害软件质量以及影 响开发周期的缺陷和变化。 对开发过程进行有效地管理和控制。 配置项 软件配置项的识别是配置管理活动的基础，也是制定配 置管理

8、计划的主要内容，配置项信息可分为3个主要类别 ： 计算机程序（源代码和可执行程序） 描述计算机程序的文档 数据（包含在程序内部或外部） 基线（IEEE定义）：已经正式通过复审批准的某种 规约或产品，它因此可作为进一步开发的基础，并 且只能通过正式的变更控制过程变化。 配置项分为基线配置项（如设计文档和源程序等） 和非基线配置项（如项目的各类计划和报告等）。 配置管理工具 配置管理数据库 版本控制库(version control library) 9.6 软件再工程 软件再工程是将新技术和新工具应用于老的 软件的一种“彻底”的预防性维护。 软件再工程是运用逆向工程、重构等技术， 在充分理解原有

9、软件的基础上，进行分解、 综合，并重新构建软件，用以提高软件的可 理解性、可维护性、可复用性或演化性。 软件再工程过程模型 正向工程信息库分析 文档重构 逆向工程代码重构 数据重构 逆向工程 重构代码 提取抽象 求精简化 “脏的”源代码 干净的源代码 初始的设计说 明 最终的设计说 明 处理 界面 数据库 软件重构 代码重构 应用最新的设计和实现技术 修改老系统的代码 提高可维护性 数据重构 不改变系统结构 小结 在软件生存期中，维护工作是不可避免的 对于大型和复杂的软件，维护费用可以达到开 发费用的十至数十倍 软件的可维护性，主要决定于开发时期的活动 维护工作是开发工作的缩影，但又有自己的特

10、 点。 要缩小维护的副作用，尽量避免在维护中引入 新错误降低软件的质量 要加强对维护的管理尤其是配置管理，有效地 对软件配置进行跟踪和控制，避免造成文档的 混乱 第10章 软软件复用 软件复用的基本概念 领域工程 基于构件的开发 面向对象与软件复用 10.1 软件复用的基本概念 简单讲，软件复用就是将已有的软件成 分用于构造新的软件系统。被复用的软 件成分称为可复用构件，无论是原封不 动地使用还是修改后再使用。 软件共享：一个系统中多次使用一个相 同的软件成分。不是复用。 软件移植：对一个软件修改，使之运行 于新的软硬件平台。不是复用。 软件复用的定义：在构造新的软件系统的过程 中，对已存在的

11、软件人工制品的使用技术。 定义包含两方面的内容： 制造软件构件的技术。是指独立于单个软件系统开发 的、可服务于整个应用领域的构件生产技术。属领域 工程范畴。 使用软件构件的技术。基于构件的开发技术，是指在 软件系统开发中使用已有软件构件的方法和技术。属 于软件工程范畴。 两者共同组成基于构件的软件工程。 10.1 软件复用的基本概念 基于构件的软件工程过程模型 软件复用的措施 软件复用的目的是能更快、更好、成本更低地 生产软件产品。 一般地说，在软件开发中采用复用构件可以比 从头开发这个软件更加容易。 措施： 建立支持软件复用的基础设施：包括可复用构件库、 用于创建复用构件的工具。 建立相应的

12、培训计划，理解和应用软件复用，形成一 个使用软件复用技术的环境。 采用更先进的，可以促进软件复用的软件开发方法 采取相应的激励措施 。 软件复用的粒度 按照可复用的粒度，软件制品从小到大 分为以下几类： 源代码复用。 软件体系结构复用：对已有软件体系结构的 复用。 应用程序生成器：用于对整个软件系统的设 计的复用。 领域特定的软件体系结构的复用：对特定领 域中存在的一个公共体系结构及其构件的复 用。 10.2 领域工程 所谓的“领域”，指的是一组具有相似或相 近软件需求的应用系统所覆盖的功能区 域。 通过领域分析(domain analysis)找出最 优复用，对它们进行设计和构造，形成 为可

13、复用构件，进而建立大规模的软件 构件仓库的过程，就是领域工程。 横向复用和纵向复用 按复用活动所应用的 领域范围，复用可分 为： 横向复用是指复用不 同应用领域中的软件 元素。 纵向复用是指在一类 具有较多公共性的应 用领域之间进行软件 构件复用。 领域 分析 用户需 求 软件开发与 构件开发 目标软 件 确 认 可复用 构件库 检 索 理 解 纵纵向复用领领域工程的活动动内容 领域分析 定义 领域分析是在特定应用领域寻找最优复用， 以公共对象、类、子集合和框架等形式进行 标识、分析和规约。 目标 是获得领域分析模型 领域分析的输入和输出 开发可复用构件 开发构件最终目的是为了复用。建造构 件

14、应遵循的原则与方法： 1. 单个构件的特征 通用性、可变性和易组装性 REBOOT构件模型 2. 创建领域构件的设计框架 除了满足单个构件的特征外，还要考虑应用 领域的特征。应考虑的关键问题主要包括： 标准数据：标识出标准的全局数据结构，使所有设 计的构件都可以用这些标准数据来刻画。 标准接口协议：建立3个层次的接口协议，即构件 内接口，构件外接口和人机接口。 程序模板：成形的结构模型，用作新程序的体系结 构设计模板。 3. 几种流行的典型构件技术 COM/OLE CORBA OpenDoc 建立可复用构件库 三种分类模式 枚举分类:通过定义一个层次结构来描述构件，在该 层次中定义软件构件的类

15、以及不同层次的子类。该分 类的优点是易于理解和使用。 刻面分类：对领域分析后，可标识出一组基本的描述 特征，这些特征称为刻面，意为呈现于用户面前的一 个方面。刻面可描述构件的功能、被操作的数据、构 件应用的语境等，并根据其重要性区分优先次序并被 联系到构件。 属性-值分类：为领域中所有构件定义一组属性，然 后赋给这组属性一组值，通过查询相应属性的值，找 出所需构件。 基于构件的开发 构件集成模型 应用系统工程 在CBSD（基于构件的软件开发）中，通过复用 构件系统开发单个应用系统的构件工程，称为 应用系统工程(ASE)。ASE过程实质是从一个或 多个构件系统中选择构件进行特化，最后把构 件装配成应用系统。 ASE过程的基本步骤： 1. 获取需求； 2. 分析； 3. 设计应用系统； 4. 实现应用系统； 5. 测试应用系统； 6. 应用系统打包。 CBSD的实施不仅需要技术的支持，还需要 机构的保证，即要重组开发组织的结构。 面向对象与软件复用