软件工程考核知识点-第8章-软件维护
软件工程导论PPT课件-第8章-维护
分析评价,修改设计,编写代码等
理解代码功能、解释数据结构、接口特点和性能限度等
8.3 软件维护的特性
8.3.3 软件维护的副作用
-结构化维护
结构化维护是指软件开发过程是按照软件工程方法进 行的、各开发阶段文档齐全的软件的维护过程。
-非结构化维护
非结构化维护是指在只有源程序,缺乏必要的文档说 明,难于确定数据结构、系统接口等特性的情况下,进行 的软件维高昂
明显代价:高昂的维护费用,已上升达80%左右; 无形代价:
的工作环境,或适应已变动的数据或文件; (4)为预防软件系统的失效而对软件系统实施修改。
8.2 软件维护的分类
- 改正性维护
对在测试阶段未能发现的、在软件投入使用后才逐渐暴露出来的 错误的测试、诊断、定位、纠错,以及验证、修改的回归测试过程, 称为改正性维护。
- 完善性维护
为了满足用户在使用过程中对软件提出的新的功能与性能要求, 需要对原来的软件的功能进行修改或扩充。
- 适应性维护
使软件适应外部新的软硬件环境或者数据环境发生的变化, 而进行修改软件的过程。
- 预防性维护
为了提高软件未来的可维护性、可靠性等,或为了给未来 的改进奠定更好的基础而修改软件的过程。
8.2 软件维护的分类 预防性维护 4% 适应性维护 21% 完善性维护 50%
改正性维护 25%
四类维护占总维护的比例
修改软件设计、 复查、必要的代 码修改、单元测 试和集成测试、 验收测试和复审
第八章软件维护
④ 软件维护工作是一项难出成果,大家都不愿意干的工作。
8.1.4 软件维护的代价
1.软件维护的工作量大 软件维护的费用在整个软件开发费用的 55%-70%,并且所占比例在逐年上升。而且维 护中还可能产生新的潜在错误。例如 1970 年维护费用约占软件开发费用的 40%,到 1990 年维护费用所占比例就超过了 70%。另外维护还包含了无形的资源占用,包括大量的使用 很多硬件、软件和软件工程师等资源。 在软件维护时,直接影响维护成本和工作量的因素很多,主要如下: (1)系统规模大小 系统规模大小直接影响维护工作量,系统规模越大,仅仅看懂理解就很困难,维护的 工作量就更多。系统规模主要由源代码行数、程序模块数、数据接口文件数、使用数据库 规模大小等因素衡量。 (2)程序设计语言 参与软件开发的人员都知道,解决相同的问题选择不同的程序设计语言,得到的程序 的规模可能不同,由此应选择功能强且适合解决问题的程序设计语言,这样可以使生成程 序的指令数更小。 (3)系统使用年限 使用年限长的老系统维护比新系统所需要的工作量更多。老系统因已经进行多次维 护,参与维护的人员也不断变化,因此这样的系统结构更乱,如果没有系统说明和设计文 档,维护就更加困难。 (4)软件开发新技术的应用 软件开发过程中,使用先进的分析和设计技术,以及程序设计技术,如:面向对象的技术、 构件技术、可视化程序设计技术等,可以减少维护工作量。 (5)设计过程中的技术 在具体对软件进行维护时,影响维护工作量的其他因素还有很多,例如设计过程中应 用的类型、数学模型、任务的难度、开关与标记、IF 嵌套深度、索引或下标数等。 2.软件维护工作量模型 维护活动分为生产性活动和非生产性活动。生产性活动包括分析评价、修改设计和编 写程序代码等。非生产性活动包括理解程序代码,解释数据结构,接口特点和设计约束等。 Belady 和 Lehman 提出软件维护工作模型:
软件工第八章软件维护
• 情况复审的目的在于促进未来的维护工作,同时 也为有效管理软件组织提供重要的反馈信息。
软件维护记录的保存
• 有效的保存维护记录是极端重要的。 • 保存维护记录的第一个问题就是那些数据值得保存? – Swanson为我们指出了下述内容:程序标识、源语 句数、机器指令数、使用的程序设计语言、软件安 装的日期、自安装以来软件运行的次数、自安装以 来软件失败的次数、程序变动的层次和标识、因程 序变动而增加的源语句数、因程序变动而删除的源 语句数、每个改动消耗的人时数、程序改动的日期、 软件工程师的名称、维护要求的标识、维护类型、 维护开始和完成的时间、用于维护的累计人时数、 与完成的维护相关联的纯收益。 – 应该为每项维护工作都收集上述数据。可以利用这 些数据构成一个维护数据库。
– – – – 可用的资源被软件维护所占用。 未能及时满足用户的维护要求时引起用户不满。 维护时改动软件,引入了潜在故障,降低了软件质量。 抽调人员从事维护工作,对新的开发过程造成混乱。
– 导致生产率的大幅下降。
软件维护的代价高昂
• 用于维护工作的劳动可以划分成:
– 生产性活动(如,分析评价、修改设计、编写程序 代码等) – 非生产性活动(例如,理解程序代码功能、解释数 据结构、接口特点、性能限度等)
非结构化维护
结构化维护VS非结构化维护
维护要求
结构化维护
y
n
非结构化维护
文件有吗
苦读代码
分析设计 制定计划 修改计划 编码 n n
n
找到问题 y 编码 复审通过 y 交付使用
软件工程第八章维护
软件工程第八章维护第一点:软件维护的定义和重要性软件维护是指在软件发布后对其进行的一系列操作和活动,旨在确保软件系统的持续可用性、可靠性和性能。
软件维护是软件开发生命周期中的一个重要环节,它涉及到对软件进行修正、优化和升级。
软件维护的重要性体现在以下几个方面:1.保障软件质量:软件在实际运行过程中可能会出现各种问题,维护可以帮助及时修复这些问题,保证软件的正常运行。
2.提高用户满意度:通过维护,可以对软件进行功能优化和界面调整,使其更加符合用户的需求,提高用户的使用体验。
3.降低风险:软件维护可以帮助提前发现并解决潜在的风险,避免因软件问题导致的损失。
4.延长软件寿命:通过不断的维护和升级,可以使软件适应不断变化的环境和需求,延长其使用寿命。
5.提高开发效率:良好的维护可以避免因软件问题导致的重复开发,提高开发团队的效率。
第二点:软件维护的类型和策略软件维护可以分为以下几种类型:1.改正性维护:这种维护类型主要是针对软件中存在的问题和错误进行修复,保证软件的正常运行。
2.适应性维护:随着环境的变化和用户需求的变化,软件需要进行相应的调整和优化,以适应新的环境和工作需求。
3.完善性维护:这种维护类型主要是针对软件的功能进行增强和扩展,以满足用户的新需求。
4.预防性维护:预防性维护是为了避免软件出现潜在的问题和风险,提前对软件进行调整和优化。
在进行软件维护时,可以采取以下策略:1.计划维护:制定详细的维护计划,包括维护的时间、内容、责任人等,确保维护工作的有序进行。
2.变更管理:对于软件的修改和更新,需要进行严格的变更管理,确保每次变更都是经过审核和评估的。
3.版本控制:通过版本控制工具,对软件的不同版本进行管理,确保软件的每个版本都是可追踪和可恢复的。
4.文档管理:对软件的维护过程和结果进行详细的文档记录,方便对软件进行管理和维护。
5.持续集成:将软件的维护工作与开发工作结合起来,通过持续集成的方式,确保软件的质量和稳定性。
第8章软件维护
软件维护步骤
4、修改程序的副作用
副作用是指因修改软件而造成的错误或其它不希望发生的情况。 1)编码副作用:在使用程序设计语言修改源代码时可能引起的错误, 如删除或修改一个标号、标识符、一个子程序,改变程序代码的时序关系, 改变逻辑运算符,改进程序的执行效率,改变程序占用存储的大小等,都 很容易引入错误,应特别小心。 2)数据副作用:在修改数据结构时,有可能造成软件设计和数据结构 的不一致,而导致软件错误。数据副作用是修改软件信息结构引起的,如 重新定义全局或局部常量,重新初始化控制标志或指针等,都容易产生设 计与数据不相容的错误,可通过详细设计文档对数据副作用加以控制。 3)文档副作用:对数据流、软件结构、逻辑模块等进行修改时,必须 对相关技术文档进行修改,否则会导致 文档与程序功能不匹配,使文档不 能反映软件当前的状态。
软件维护步骤
5、重新验证程序:
1)静态确认; 2)计算机确认; 3)维护后的验收。
软件维护步骤
第三步:维护文档整理
记录一些与维护工作有关的数据信息,这些信息 可作为估计软件维护的有效程度,确定软件产品的 质量,确定维护的实际开销等工作的原始数据。
软件维护步骤
第四步:维护活动评价
具体的评价工作可从以下几个方面考虑: (1)每次程序运行时的平均出错次数; (2)花费在每类维护活动上的总的“人时”数; (3)每个程序、每种语言、每种维护类型程序的平均修改次数; (4)维护工作中增加或删除每个源程序语句所花费的平均“人 时”数; (5)用于每种语言的平均“人时”数; (6)维护申请报告的平均处理时间; (7)各类维护申请的百分比。 一方面,可判定此次维护活动开展是否顺利、成功;另一方面, 为今面的维护工作积累经验。
2、结构化维护:进行维护 活动时,首先从评价需求开始,搞清楚 功能、性能上的改变,然后对设计说明文档进行评价、修改和复查; 根据设计的修改,再进行程序的变动;然后根据测试文档中的测试 用例进行回归测试;最后将修改后的软件再次交付使用。
软件工程08 维护
八、维护
1、软件维护概述
1.2 软件维护的特点
1.结构化维护和非结构化维护
软件 代码 评价设计 计划途径 复查 修改设计 重编程序 重编程序 评价代码
复查
复查
交付使用
八、维护
1、软件维护概述
1.2 软件维护的特点
2.维护的代价 软件维护代价包括费用代价和隐含的无形代价,还有维护工作量。其他 无形的代价还有: 1)当看来合理的有关改错或修改的要求不能及时满足时,将引起用户不满; 2)由于维护时的改动,在软件中引入了潜伏的故障,从而降低了软件的质量; 3)当把软件工程师调去从事维护工作时,将在开发过程中造成混乱。
八、维护
3、软件的可维护性
3.3 提高软件可维护性的方法
1.合理的程序结构 合理的程序结构不仅有利于软件的维护工作,同时也是团队集体创作的前 提。 (1)软件的模块化 (2) 预留出一定的空余编码以供扩展 (3) 函数体(对象)的封闭性 2.程序控制的数据化 我们设想如果仅改变程序中的数据,就可以实现对程序控制的修改,这 就是程序控制的数据化。
八、维护
5、软件再工程
逆向工程流程:
源程序 源程序分析器
逆向工程 数据库
模型生成器
数据模型
程序绍了软件的维护、逆向工程和再生工程等内容。通过上述内 容的学习,可以掌握软件维护的基本理论,为做好软件能维护工作奠定基础。
软件工程
王振武
八、维护
学习目标
了解软件维护的分类和特点 了解维护任务的实施过程 理解软件的可维护性和软件维护的副作用 掌握软件再工程
八、维护
1、软件维护概述
1.1软件维护的分类
软件主要涉及以下四个方面: (1)改正性维护 改正性维护主要发生在软件使用初期的磨合阶段,随着软件错误的消除, 改正性维护会随之减少。 (2)完善性维护 完善性维护大多发生在软件运行维护中期。 (3)适应性维护 适应性维护大多发生在软件运行维护后期。 (4) 预防性维护 预防性维护自软件开发之日起即已发生。
软件工程 第8章 软件维护 ppt
3. 维护的事件流
图8.2 维护阶段的事件流
4. 保存维护记录 ◆ 哪些数据是值得记录的? Swanson 提出了下述内容: ① 程序标识; ② 源语句数; ③ 机器指令条数; ④ 使用的程序设计语言; ⑤ 程序安装的日期; ⑥ 自从安装以来程序运行的次数; ⑦ 自从安装以来程序失效的次数; ⑧ 程序变动的层次和标识; ⑨ 因程序变动而增加的源语句数; 因程序变动而删除 的源语句数; 每个改动耗费的人时数; 程序改动的 日期; 软件工程师的名字; 维护要求表的标识; 维 护类型; 维护开始和完成的日期; 累计用于维护的 人时数; 与完成的维护相联系的纯效益。
2. 文档重构
◆ 老程序固有的特点是缺乏文档。具体情况不同,处理这
个问题的方法也不同: 1)如果一个程序是相对稳定的,正在走向其有用生命的终 点,而且可能不会再经历什么变化,那么,让它保持现 状。 2)为了便于今后的维护,必须更新文档,不是一下子把某 应用系统的文档全部都重建起来,而是只针对系统中当 前正在修改的那些部分建立完整文档。随着时间流逝, 将得到一组有用的和相关的文档。 3)如果某应用系统是完成业务工作的关键,而且必须重构 全部文档,则仍然应该设法把文档工作减少到必需的最 小量。
5. 评价维护活动 ◆根据保存的维护记录,至少可以从下述7个方面 度量维护工作:
(1) 每次程序运行平均失效的次数; (2) 用于每一类维护活动的总人时数; (3) 平均每个程序、每种语言、每种维护类型所做的程序 变动数; (4) 维护过程中增加或删除一个源语句平均花费的人时数; (5) 维护每种语言平均花费的人时数; (6) 一张维护要求表的平均周转时间; (7) 不同维护类型所占的百分比。
5. 数据重构 ◆ 与代码重构不同,数据重构发生在相当低的抽象 层次上,它是一种全范围的再工程活动。 ◆ 在大多数情况下,数据重构始于逆向工程活动, 分解当前使用的数据体系结构,必要时定义数据 模型,标识数据对象和属性,并从软件质量的角 度复审现存的数据结构。 ◆ 当数据结构较差时,应该对数据进行再工程。 ◆ 由于数据体系结构对程序体系结构及程序中的算 法有很大影响,对数据的修改必然会导致体系结 构或代码层的改变。
第8章软件维护
8Байду номын сангаас3 软件维护过程
一般过程:建立一个维护组织;提供维护报告(用户);制定软件修 改报告(维护组织);标准化维护工作流程(事件序列)控制;收集 与保存维护活动记录;评价复审维护等。
1. 维护组织 通常,软件维护并不需要维持一个正式的组织机构,但委托一个非专门的 维护管理员负责维护是绝对必要的。每个维护要求都通过维护管理员转交 给相应的系统管理员去评价。系统管理员是被指定去熟悉一小部分产品程 序的技术人员。系统管理员对维护任务做出评价之后,由变化授权人决定 应该进行的活动。下图是一种典型的维护组织方式。
维护工作必须进行的技术工作:包括修改软件设计、复查、必要的代码修改、单 元测试与集成测试、回归测试、验收测试与复审。
图8.2 维护阶段的事件流
在完成软件维护任务之后,需要对本次维护工作进行评审,试图回答下 述问题: 在当前处境下设计、编码或测试的哪些方面能用不同方法进行? 哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 维护工作(处境复查)评审对将来维护工作的进行有重要影响,而且所 提供的反馈信息对有效地管理软件组织十分重要。
维护综述:在软件产品被开发出来并交付用户使用之后,就进入了软 件的运行维护阶段。这个阶段是软件生命周期的最后一个阶段,其基 本任务是保证软件在一个相当长的时期能够正常运行。
软件维护需要的工作量很大,平均说来,大型软件的维护成本高达开 发成本的4倍左右。目前国外许多软件开发组织把60%以上的人力用于 维护已有的软件,而且随着软件数量增多与使用寿命延长,这个百分 比还在持续上升。将来维护工作甚至可能会束缚住软件开发组织的手 脚,使他们没有余力开发新的软件。
《软件工程》第八章 软件维护与再工程
软件可维护性-主要影响因素
可移植性:指程序转移到一个新的计算环境的难易 程度。
影响软件可移植性的因素有:信息隐蔽原则;模块 独立;模块化;高内聚低耦合;良好的程序结构; 不用标准文本以外的语句等
一个可移植的程序应具有结构良好、灵活、不依赖 于某பைடு நூலகம்具体计算机或操作系统的性能
软件可维护性-主要影响因素
软件维护的概念-维护成本
其它一些因素:如应用的类型、数学模型、 任务的难度、IF嵌套深度、索引或下标数等, 对维护工作量也有影响
软件维护的过程-维护组织
维护组织结构图
软件维护的过程-维护组织
系统监督员一般都是对程序(某一部分)特别熟 悉的技术人员。 在维护人员对程序进行修改的过程中,由配 置管理员严格把关,控制修改的范围,对软 件配置进行审计 。 维护管理员、系统监督员、修改控制决策机 构等,均代表维护工作的某个职责范围 。
如果已经开始保存维护记录,可以对维护工作做 一些定量度量,至少可以从如下7方面进行评价:
每次程序运行平均失败的次数; 用于每一类维护活动的总人时数; 平均每个程序、每种语言、每种维护类型所必需的程序 变动数; 维护过程中增加或删除源语句平均花费的人时数; 维护每种语言平均花费的人时数; 一张维护请求表的平均周转时间; 不同维护类型所占的比例;
软件维护的过程-维护记录
软件修改报告指明:为满足维护申请报告提 出的需求所需的工作量、本次维护活动的类 别、本次维护请求的优先级、本次修改的背 景数据。在拟定进一步维护计划前,软件修 改报告要提交给修改决策机构,供进一步规 划维护活动使用 保存维护记录的第一个问题就是哪些数据值 得保存?
软件维护的过程-维护评价
软件维护的概念-维护问题
i第8章 软件维护
得客户不满意; 变更的结果引入新的故障,使得软件整体质量 下降; 把软件人员抽调到维护工作中,干扰了软件开 发工作。
8.3 软件维护任务的实施
为了有效地进行软件维护,应事先就开始做组织 工作。
首先建立维护的组织 申明提出维护申请报告的过程及评价的过程 为每一个维护申请规定标准的处理步骤 建立维护活动的登记制度以及规定评价和评审
3.完善性维护
ቤተ መጻሕፍቲ ባይዱ
在软件的使用过程中,用户往往会对软件提出 新的功能与性能要求。 为了满足这些要求,需要修改或再开发软件, 以扩充软件功能、增强软件性能、改进加工效 率、提高软件的可维护性。 这种情况下进行的维护活动叫做完善性维护。 例如,完善性维护可能是修改一个计算工资的 程序,使其增加新的扣除项目;缩短系统的应 答时间,使其达到特定的要求等。
三类维护占 总维护比例
维护在软件生存期 所占比例
8.2 维护的特点
8.2.1 非结构化维护和结构化维护 1. 非结构化维护 只有源程序,没有文档,维护活动只能从阅读、理 解分析源程序开始,来了解系统功能、软件结构、 数据结构、系统接口、设计约束等。
维护工作非常困难,要花费大量的人力、物力,最 终对源程序修改的后果是难以估量的。
8.2.2 维护的困难性 1. 读懂别人的程序是困难的 修改别人的程序不如自己重新编写程序 2. 文档的不一致性 各种文档之间不一致 文档与程序之间不一致 主要是开发过程中文档管理不严造成: 修改程序忘了修改与其相关的文档 某一文档改了,没有修改与其相关的另一文档
3. 软件开发和软件维护在人员和时间上的差异 软件维护工作由软件开发人员来进行,维护工作就 变得容易 通常开发人员和维护人员不同,导致维护的困难。 维护阶段持续时间很长,正在运行的软件可能是十 几、二十几年前开发的,开发工具、方法、技术与 当前的工具、方法、技术差异很大,导致维护困难。 3. 软件维护不是一项吸引人的工作。
软件工程第8章维护—总结
软件工程第8章维护—总结第一篇:软件工程第8章维护—总结第8章维护周四上午2#211的34节,下午在1#202的78节在软件产品被开发出来并交付用户使用之后,就进入了软件的运行维护阶段。
这个阶段是软件生命周期的最后一个阶段。
大型软件的维护成本高达开发成本的4倍左右。
8.1软件维护的定义在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程。
四项活动:改正性维护,适应性维护,完善性维护(一半以上),预防性维护。
8.2软件维护的特点8.2.1结构化维护与非结构化维护差别巨大1.非结构化维护2.结构化维护8.2.2维护的代价高昂维护工作量的一个模型:M=P+K*exp(c-d)M是维护用的总工作量,P是生产性工作量,K是经验系数,c是复杂程度(非结构化设计和缺少文档都会增加软件的复杂程度),d 是维护人员对软件的熟悉程度。
8.2.3维护的问题很多1.2.3.4.5.理解别人写的程序通常非常困难;没有文档或文档资料显著不足;不能指望开发人员详细说明软件;设计时未考虑将来的修改;维护不是一项吸引人的工作。
8.3软件维护过程1.维护组织未必建立正式的维护组织,但是非正式的委托责任是绝对必要的。
在维护活动开始之前就明确维护责任是十分必要的,可以大大减少维护过程中可能出现的混乱。
2.维护报告即软件修改报告。
3.维护的事件流4.保存维护记录5.评价维护活动8.4软件的可维护性定义:维护人员理解、改正、改动或改进这个软件的难易程度。
8.4.1决定软件可维护性的因素1.可理解性定义:外来读者理解软件的结构、功能、接口和内部处理过程的难易程度。
2.可测试性可以用程序复杂度来度量它的可测试性。
3.可修改性耦合、内聚、信息隐藏、局部化、控制域与作用域的关系等,都影响软件的可修改性。
4.可移植性定义:把程序从一种计算环境(硬件配置和操作系统)转移到另一种计算环境的难易程度。
5.可重用性定义:同一事物不做修改或稍加改动就在不同环境中多次重复使用。
软件工程第8章软件维护
8.1 软件维护的种类
1. 校正性维护(Corrective maintenance) 为了识别和纠正软件错误、改正软件性能上的缺陷、排
除实施中的误使用,应当进行的诊断和改正错误的过 程,就叫做校正性维护。
8.1 软件维护的种类
2. 适应性维护(Adaptive maintenance)
随着计算机的飞速发展,外部环境(新的硬、软件配置)或数据环 境(数据库、数据格式、数据输入/输出方式、数据存储介质)可 能发生变化,为了使软件适应这种变化,而去修改软件的过程就 叫做适应性维护。
8.4.1 影响可维护性的因素
除了与开发方法有关的因素之外,以下因素会对可维 护性有重要影响:
(1)软件设计人员是否受到严格的规范化工作培训; (2)是否采用主流的编程语言; (3)是否采用主流的操作系统; (4)是否采用标准化的文档资料结构和文档形成机制; (5)是否保存规范化的测试资料。
8.4.2 软件可维护性的度量
8.3 软件维护的实施
为了有效地进行软件维护,应事先就开始做组织工作。 首先需要建立维护的机构,申明提出维护申请报告的 过程及评价的过程;为每一个维护申请规定标准的处 理步骤;还必须建立维护活动的登记制度以及规定评 价和评审的标准。
8.3.2 软件维护申请报告
软件维护申请应按规定的方式提出。软件维护组织通 常提供维护申请报告(MRR, Maintenance Request Report),或称软件问题报告,由申请维护的用户填写。
8.1 软件维护的种类
完善性维护 50%
预防性维护5%
改正性维护 20%
适应性维护 25%
图11.1 各类维护的比重
8.2 软件维护的特点
8.2.1 软件维护面临的困难 统计资料表明,有代表性的软件开发组织用于校正性
软件工程课件-第八章维护ppt
2. 适应性维护
计算机科学技术领域的各个方面都在迅速进步,大约每 过38个月就有新一代的硬件宣告出现;另一方面,应用软 件的使用寿命却很容易超过十年,远远长于最初开发这个 软件时的运行环境的寿命。因此,适应性维护就是为了和 变化了的环境适当地配合而进行的修改软件的活动,是既 必要又经常的维护活动。
4. 预防性维护
当为了提高未来的可维护性或可靠性,或为了给未来的 改进工作奠定更好的基础而修改软件时,就出现了第四类维 护活动,这类维护活动称为预防性维护。通常,把预防性维 护定义为:“把今天的方法学应用于昨天的系统以满足明天 的需要”。也就是说,预防性维护就是采用先进的软件工程 方法对需要维护的软件或软件中的某一部分,主动地进行重 新设计、编码和测试。
8.3.1 维护组织 虽然通常并不需要建立正式的维护组织,但是,即使对
于一个小的软件开发团体而言,非正式地委托责任也是绝 对必要的。维护机构成员一般包括:配置管理员、维护控 制员、系统管理员、一般维护工作人员。
每个维护要求都通过维护管理员转交给相应的系统管理 员去评价,见下页图示。
维护机构
维护要求 (软件问题报告)
● 当必须把软件工程师调去从事维护工作时,将在开发 过程中造成混乱。
8.1.2.3 维护的问题很多
与软件维护有关的绝大多数问题,都可归因于软件定 义和软件开发的方法有缺点。在软件生命周期的头两个时 期没有严格而又科学的管理和规划,几乎必然会导致在最 后阶段出现问题。下面列出和软件维护有关的部分问题:
8.1.2.2 维护的代价高昂 8.1.2.3 维护的问题很多
8.1.2.1 结构化维护与非结构化维护差别悬殊
第八章 软件维护
软件维护的机构10软件维 的事件流1112
软件维护工作流程
必要的技术工作 修改软件需求说明 修改软件设计 设计评审 对源程序做必要修改 单元测试 集成测试(回归测试) 确认测试 软件配置评审等。
13
8 .4 软件的可维护性
衡量软件质量的几个主要质量特性: 可维护性 可使用性 可靠性 一、软件可维护性的定义 指纠正软件系统出现的错误和缺陷,以及为 满足新的要求进行修改、扩充或压缩的容 易程度。
22
进行明确的质量保证审查
检查点复审、验收检查、周期性地维护审查、 对软件包进行检查。
选择可维护的程序设计语言 改进程序的文档 开发软件时考虑到维护
23
相关习题 1.某些软件工程师不同意“目前国外许多 软件开发组织把60%以上的人力用于维护已 有的软件”的说法,他们争论说:“我并没 有花费我的60%的时间去改正我所开发的程 序中的错误”。 请问,你对上述争论有何看法? 2.为什么大型软件的维护成本高达开发成 本的4倍左右?
7
8.2.3 维护的问题很多 ( 1 )理解别人写的程序通常非常困难. ( 2 )需要维护的软件无文档或不全. ( 3 )软件人员流动性大. ( 4 )设计时未考虑将来修改需要,修改困难. ( 5 )维护工作无吸引力,缺乏成就感.
8
8. 3 软件维护过程
首先建立维护组织,确定报告和评价过程, 为每个维护要求规定一个标准化的事件序 列,并记录维护活动和规定复审标准。 一、维护组识 所有软件维护申请应按规定的方式提出 维护机构通常提供“维护申请报告”或称 “软件问题报告”由申请维护的用户填写。 维护机构内部要写“软件修改报告”
26
4.假设你的任务是对一个已有的软件做重 大修改,而且只允许你从下述文档中选取两 份:(a)程序的规格说明;(b)程序的详细设 计结果(自然语言描述加上某种设计工具表 示);(c)源程序清单(其中有适当数量的注 解)。 你将选取哪两份文档?为什么这样选取?
软件工程八维护
3、完善性性维护
实践表明,在几种维护活动中,完善性 维护所占的比重最大。即大部分维护工 作是改变和加强软件,而不是纠错。
完善性维护不一定是救火式的紧急维修 ,而可以是有计划、有预谋的一种再开 发活动。
事实证明,来自用户要求扩充、加强软 件功能、性能的维护活动约占整个维护 工作的50%以上。
❖ 模型表明,如果软件的开发途径不好(即,没有使用 软件工程方法学),而且原来的开发人员不能参加维 护工作,那么维护工作量和费用将指数地增加。
影响维护工作量的因素
❖在软件的维护过程中,需要花费 大量的工作量,从而直接影响了 软件维护的成本。
❖许多软件在开发时并未考虑将来 的修改,为软件的维护带来许多 问题。
❖ 应该为每项维护工作都收集下述数据:
(1)程序标识;
(2)源语句数;
(3)机器指令条数;
(4)使用的程序设计语言;
(5)程序安装的日期;
(6)自从安装以来程序运行的次数;
(7)自从安装以来程序失效的次数;(8)程序变动的层次和标识;
(9)因程序变动而增加的源语句数;(10)因程序变动而删除的源语句数;
软件维护的管理流程
维护修改建议
进行测试
分析修改建议
N
是否合理
Y
提交管理部门审查
是否同意
Y
修改
N
撤销
提交管理部门审批
N
是否批准
Y
更新主文档
更新其他文档
提交使用
修改
8.3 软件维护过程
2. 维护报告
❖ 应该用标准化的格式表达所有软件维护要求。
软件维护人员给用户提供空白的维护要求——有时 称为软件问题报告表,由要求一项维护活动的用户 填写。
《软件工程实用教程》第8_章_软件维护技术
第8 章 軟體維Βιβλιοθήκη 技術8.2 軟體維護類型8.2.1 改正性維護 1. 利用應用軟體包,可開發出比由用戶完全 自己開發的系統可靠性更高的軟體。 2. 結構化技術,用它開發的軟體易於理解和 測試。 3. 防錯性程式設計。把自檢能力引入程式, 通過非正常狀態的檢查,提供審查跟蹤。 4. 通過週期性維護審查,在形成維護問題之 前就可確定品質缺陷。可理解性
第8 章 軟體維護技術
8.2.2 完善性維護 為了滿足日益增長的新要求,需要修改或再 開發軟體,以擴充軟體功能,增強軟體性能, 改進加工效率,提高軟體的可維護性,這些 維護活動稱為完善性維護。 8.2.3 適應性維護 為了使軟體適應新的變化而去修改軟體的維 護活動稱為適應性維護。 8.2.4 預防性維護 為以後進一步使用軟體打下良好基礎的維護 活動稱為預防性維護活動。
第8 章 軟體維護技術
8.4.2 軟體維護的副作用 1.修改代碼的副作用 2.修改數據的副作用 3.修改文檔的副作用
(1)確認維護類型 (2)實施維護 (3)維護評審
第8 章 軟體維護技術
4.整理軟體維護文檔 程式名稱; 使用的程式設計語言; 根源程式語句條數,機器代碼指令條數; 程式安裝的日期; 程式安裝後的運行次數; 與程式安裝後運行次數有關的處理故障次數; 程式改變的層次,名稱和日期; 修改程式所增加的根源程式語句條數; 修改程式所減少的根源程式語句條數;
第8 章 軟體維護技術
8.3 軟體維護技術
8.3.1 軟體維護過程 1.建立維護機構
第8 章 軟體維護技術
2.編寫軟體維護申請報告 軟體變更報告包括的內容: 所需修改變動的性質; 申請修改的優先順序; 為滿足該維護申請報告,所需的工作量(人 員數,時間數); 預計修改後的結果。 3.確定軟體維護工作流程
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
软件工程考核知识点-第8章-软件维护第8章软件维护软件投入使用后就进入软件维护阶段。
维护阶段是软件生存周期中时间最长的一个阶段,所花费的精力和费用也是最多的一个阶段。
8.1软件维护的内容软件维护内容有四种:校正性维护,适应性维护,完善性维护和预防性维护。
1.校正性维护在软件交付使用后,由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现,因此必然有一部分隐含的错误被带到维护阶段来。
这些隐含的错误在某些特定的使用环境下会暴露出来。
为了识别和纠正错误,修改软件性能上的缺陷,应进行确定和修改错误的过程,这个过程就称为校正性维护。
校正性维护占整个维护工作的20%左右。
2.适应性维护随着计算机的飞速发展,计算机硬件和软件环境也在不断发生变化,数据环境也在不断发生变化。
为了使应用软件适应这种而修改软件的过程称为适应性维护。
这种维护活动占整个维护活动的25%。
3.完善性维护在软件漫长的运行时期中,用户往往会对软件提出新的功能要求与性能要求。
这是因为用户的业务会发生变化,组织机构也会发生变化。
为了适应这些变化,应用软件原来的功能和性能需要扩充和增强,为达到这个目的而进行的维护活动称为完善性维护,占整个维护活动的50%。
4.预防性维护为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。
这是为以后进一步的运行和维护打好基础,占整个维护工作的4%。
8.2 维护的特点8.2.1非结构化维护和结构化维护软件的开发过程对软件的维护过程有较大的影响。
若不采用软件过程的方法开发软件,则软件只有程序而无文档,维护工作非常难,这就是一种非结构化的维护。
若采用软件工程的方法开发软件,则各阶段都有相应的文档,这容易进行维护工作,这是一种结构化的维护。
1.非结构化维护因为只有源程序,而文档很少或没有文档,维护活动只能从阅读、理解、分析源程序开始。
这是软件工程时代以前进行维护的情况。
2.结构化维护用软件工程思想开发的软件具有各阶段的文档,这对于理解和掌握软件功能、性能、系统结构、数据结构、系统接口和设计约束有很大作用。
这种维护对减少精力、减少花费、提高软件维护效率有很大的作用。
8.2.2维护的困难性软件维护的困难性是由于软件需求分析和开发方法的缺陷。
软件生存周期中的开发阶段没有严格而又科学的管理和规划,就会引起软件运行时的维护困难。
表现在以下几个方面:1.读懂别人的程序是困难的。
2.文档的不一致性。
由于开发过程中文档管理不严所造成的,在开发过程中经常会出现修改程序却遗忘了修改与其相关的文档,使得文档前后不一致。
3.软件开发和软件维护在人员和时间上的差异由于维护阶段持续时间很长,正在运行的软件可能是十几、二十年前开发的,开发工具、方法、技术与当前的工具、方法、技术差异很大,这又是维护困难的另一因素。
4.软件维护不是一项吸引人的事由于维护工作的困难性,维护工作经常遭受挫折,而且很难出成果,不像软件开发工作那样吸引人。
8.2.3软件维护的费用软件维护的费用在总费用中的比重是不断增加的。
七十年代占35%~40%,八十年代上升到40%~60%,九十年代上升到70%~80%。
软件维护费用不断上升,这只是软件维护有形的代价,无形的代价是要占用更多的资源,并在维护时对软件的改动,引入了潜在的故障,从而降低了软件的质量。
用于软件维护工作的活动可分为生产性活动和非生产性活动两种。
生产性活动包括分析评价、修改设计和编写程序代码等。
非生产性活动包括理解程序代码功能、解释数据结构接口特点和设计约束。
维护活动总的工作两由下式表示:M=P+K×exp(C-D)其中:M表示维护工作的总工作量;P表示生产性活动工作量;K表示经验常数;C表示复杂性程度;D表示维护人员对软件的熟悉程度;上式表明,若C越大,D越小,那么维护工作量将成指数增加;C增加表示软件因未用软件工程方法开发,从而使得软件为非结构化设计,文档缺少,程序复杂性高。
D表示维护人员不是原来的开发人员,对软件熟悉程度低,重新理解软件花费很多时间。
8.3维护任务的实施8.3.1维护的组织为了有效地进行软件维护,应事先开始组织工作,建立维护机构。
这种维护机构通常以维护小组形式出现。
维护小组分为临时维护小组和长期维护小组。
8.3.2维护的流程软件维护的流程如下:(1)制定维护申请报告。
(2)审查申请报告并批准。
(3)进行维护并做详细记录。
(4)复审。
1.制定维护申请报告所有软件维护申请报告应按照规定的方式提出。
该报告也称为软件问题报告。
它是维护阶段的一种文档,由申请维护的用户填写。
维护申请报告是一种由用户产生的文档,在软件维护组织内部还要制定一份软件修改报告,该报告是维护阶段的另一种文档。
提出维护申请报告之后,由维护机构来评审维护请求。
评审工作很重要,通过评审回答要不要维护,从而可以避免盲目的维护。
2.维护过程一个维护申请提出之后,经评审需要维护则按下列过程实施维护:(1)首先确定要进行维护的类型。
(2)对校正性维护从评价错误的严重性开始。
(3)对适应性维护和完善性维护。
(4)实施维护任务。
不管维护类型如何,大体上要开展相同的技术工作。
这些工作包括修改软件设计、必要的代码修改、单元测试、集成测试、确认测试以及复审。
每种维护类型的侧重点不一样。
(5)“救火”维护。
在发生重大问题时,需要立即解决的问题。
3.维护的复审在维护任务完成后,要对维护任务进行复审。
8.3.3维护技术有两类维护技术,它们是面向维护的技术和维护支援技术。
1.面向维护的技术面向维护的技术涉及软件开发的所有阶段。
2.维护支援技术维护支援技术包括下列方面的技术:.信息收集;.错误原因分析;.维护方案评价;.软件分析与理解;.代码与文档修改;.修改后的确认;.远距离的维护;8.3.4维护的副作用维护的目的是为了延长软件的寿命并让创造更多的价值,经过一段时间的维护,软件中的错误减少了,功能增强了。
但修改软件会造成软件的错误,这种因修改软件而造成的错误或其他不希望出现的情况称为维护的副作用。
维护的副作用有编码副作用、数据副作用、文档副作用三种。
1.编码副作用在使用程序设计语言修改源代码时可能引入错误。
2.数据副作用在修改数据结构时,有可能造成软件设计与数据结构不匹配,因而导致软件错误。
3.文档副作用对数据流、软件结构、模块逻辑或任何其他有关特性进行修改时,必须对相关技术文档进行相应修改,否则会导致文档与程序功能不匹配、缺省条件改变、新错误信息不正确等错误,使文档不能反映软件当前的状态。
【大中8.4 软件可维护性软件的维护是十分困难的,为了使软件能易于维护,必须考虑使软件具有可维护性。
8.4.1可维护性定义软件可维护性的定义:软件能够被理解、校正、适应及增强功能的容易程度。
软件的可维护性、可使用性、可靠性是衡量软件质量的几个主要特性,也是用户十分关心的几个问题。
软件的可维护性是软件开发阶段的关键目标。
影响软件可维护性的因素较多,设计、编码及测试中的疏忽和低劣的软件配置,缺少文档等都对软件的可维护性产生不良影响。
软件可维护性可用下面七个质量特性来衡量,即可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。
对于不同类型的维护,这七种特性的侧重点也是不相同。
8.4.2可维护性的度量目前有若干对软件可维护性进行综合度量的方法,但要对可维护性作出定量度量还是困难的。
还没有一种方法能够使用计算机对软件的可维护性进行综合性的定量评价。
下面是度量一个可维护的软件的七种特性时常采用的方法,即质量检查表、质量测试、质量标准。
质量检查表是用于测试程序中某些质量特性是否存在的一个问题清单。
质量测试与质量标准则用于定量分析和评价程序的质量。
由于许多质量特性是相互抵触的,要考虑几种不同的度量标准去度量不同的质量特性。
8.4.3提高可维护性的方法从下面五个方面来阐述如何提高软件的可维护性:1.建立明确的软件质量目标如果要程序满足可维护性七个特性的全部要求,那么要付出很大的代价,甚至是不现实的,但有些可维护性是相互促进的,因此要明确软件所追求的质量目标。
2.使用先进的软件开发技术和工具利用先进的软件开发技术能大大提高软件质量和减少软件费用。
面向对象的软件开发方法就是一个非常实用而强有力的软件开发方法,用面向对象方法开发出来的软件系统,稳定性好,比较容易修改,比较容易理解,易于测试和调试,因此,可维护性好。
3.建立明确的质量保证质量保证是指为提高软件质量所做的各种检查工作。
质量保证检查是非常有效的方法,不仅在软件开发的各阶段中得到了广泛应用,而且在软件维护中也是一个非常主要的工具。
为了保证可维护性,以下四类检查是非常有用的:(1)在检查点进行检查。
(2)验收检查。
(3)周期性的维护检查。
(4)对软件包的检查。
4.选择可维护的语言程序设计语言的选择对维护影响很大。
低级语言很难掌握,很难理解,因而很难维护。
一般来说,高级语言比低级语言更容易理解,第四代语言更容易理解,容易编程,程序容易修改,改进了可维护性。
5.改进程序的文档程序文档是对程序功能、程序各组成部分之间的关系、程序设计策略、程序实现过程的历史数据等的说明和补充。
程序文档对提高程序的可阅读性有重要作用。
为了维护程序,人们必须阅读和理解程序文档。
一、名词解释1.校正性维护2.适应性维护3.完善性维护4.预防性维护5.软件可维护性 6.软件维护的副作用二、填空题1.维护阶段是软件生存周期中时间最长的阶段,也是花费精力和费用________的阶段。
2.在软件交付使用后,由于在软件开发过程中产生的错误没有完全彻底在开发阶段发现,必然有一部分隐含错误带到_________阶段。
3.采用手工方法开发软件只有程序而无文档,维护困难,这是一种___________维护。
4.软件维护费用增加的主要原因是维护的_________非常低。
5.软件维护工作的活动分为生产性活动和__________活动。
6.所有软件维护申请报告要按规定方式提出,该报告也称_________报告。
7.有两类维护技术:在开发阶段使用来减少错误,提高软件可维护性的面向维护技术;在维护阶段用来提高维护的效率和质量的_______技术。
三、选择题1.在生存周期中,时间长、费用高、困难大的阶段是( )。
A.需求分析B.编码C.测试D.维护2.为适应软硬件环境变化而修改软件的过程是( )。
A.校正性维护B.适应性维护C.完善性维护D.预防性维护3.软件维护困难的主要原因是( )。
A.费用低B.人员少C.开发方法的缺陷D.维护难4.软件维护费用高的主要原因是( )。
A.生产率高B.生产率低C.人员多D.人员少5.维护阶段的文档是( )。
A.软件需求说明B.操作手册C.软件问题报告D.测试分析报告6.产生软件维护的副作用,是指( )。