软件维护与再工程课件.ppt
- 【下载声明】
1. 本站全部试题类文档,若标题没写含答案,则无答案;标题注明含答案的文档,主观题也可能无答案。请谨慎下单,一旦售出,不予退换。
2. 本站全部PPT文档均不含视频和音频,PPT中出现的音频或视频标识(或文字)仅表示流程,实际无音频或视频文件。请谨慎下单,一旦售出,不予退换。
3. 本页资料《软件维护与再工程课件.ppt》由用户(ziliao2023)主动上传,其收益全归该用户。163文库仅提供信息存储空间,仅对该用户上传内容的表现方式做保护处理,对上传内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知163文库(点击联系客服),我们立即给予删除!
4. 请根据预览情况,自愿下载本文。本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
5. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007及以上版本和PDF阅读器,压缩文件请下载最新的WinRAR软件解压。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 维护 工程 课件
- 资源描述:
-
1、 软件演化是指软件在交付以后,对软件进软件演化是指软件在交付以后,对软件进行的一系列活动的总称。行的一系列活动的总称。软件演化:软件演化:软件的维护软件的维护、软件再工程软件再工程。软件维护软件维护阶段覆盖了从软件交付使用到软阶段覆盖了从软件交付使用到软件被淘汰为止的整个时期。软件的开发时件被淘汰为止的整个时期。软件的开发时间可能需要一、二年,甚至更短,但它的间可能需要一、二年,甚至更短,但它的使用时间可能要经历几年或几十年。使用时间可能要经历几年或几十年。再工程再工程的主要目的是为遗留系统转化为可的主要目的是为遗留系统转化为可演化系统提供一条现实可行的途径,是在演化系统提供一条现实可行的途径
2、,是在软件生命周期终止后开始的一个新的阶段。软件生命周期终止后开始的一个新的阶段。2/68软件维护软件维护再工程技术再工程技术3/68再工程技术再工程技术4/68 什么是软件维护什么是软件维护 是指软件系统交付使用以后,为了改正错误或满足新的需要而修改软件的过程 国标国标GB/T 11457-95给出如下定义给出如下定义 在一软件产品交付使用后对其进行修改,以纠正故障;在一软件产品交付使用后对其进行修改,以纠正故障、改进其性能和其它属性,或使产品适应改变了的环境5/68 两种两种错误认识错误认识 软件维护是一次新的开发活动 软件维护就是改错 新开发活动新开发活动强调要在一定的约束条件下从强调要
3、在一定的约束条件下从头开始实施头开始实施 软件维护软件维护强调必须在现有系统的限定和约强调必须在现有系统的限定和约束条件下实施束条件下实施;根据起因不同,软件维;根据起因不同,软件维护可以分为护可以分为纠错性维护纠错性维护、适应性维护适应性维护、改改善性维护善性维护和和预防性维护预防性维护四类四类 6/68 纠错性维护纠错性维护:为了改正软件系统中的错误,使:为了改正软件系统中的错误,使软件能够满足预期的正常运行状态的要求而进软件能够满足预期的正常运行状态的要求而进行的维护行的维护 适应性维护适应性维护:为了使软件适应内部或外部环境:为了使软件适应内部或外部环境变化,而去修改软件的过程变化,而
4、去修改软件的过程 改善性维护改善性维护:满足使用过程中用户提出增加新:满足使用过程中用户提出增加新功能或修改已有功能的建议维护功能或修改已有功能的建议维护 预防性维护预防性维护:为了提高软件的可维护性、可靠:为了提高软件的可维护性、可靠性等,为以后进一步改进软件打下良好基础而性等,为以后进一步改进软件打下良好基础而修改软件的活动修改软件的活动7/68 在实践中,软件维护各种活动常常交织在在实践中,软件维护各种活动常常交织在一起,尽管这些维护在性质上有些重叠,一起,尽管这些维护在性质上有些重叠,但是还是有充分的理由区分这些维护活动但是还是有充分的理由区分这些维护活动 只有正确区分维护活动的类型才
5、能够更有只有正确区分维护活动的类型才能够更有效地确定维护需求的优先级效地确定维护需求的优先级 8/68 结构化维护结构化维护:采用软件工程的方法进行软件开发,保证:采用软件工程的方法进行软件开发,保证每个阶段都有完整且详细的文档每个阶段都有完整且详细的文档 非结构化维护非结构化维护:如果不采用软件工程方法开发软件,软:如果不采用软件工程方法开发软件,软件只有程序而欠缺文档,则维护工作将变得十分困难件只有程序而欠缺文档,则维护工作将变得十分困难 维护时,开发人员从分析需求规格说明开始,明白软件维护时,开发人员从分析需求规格说明开始,明白软件功能和性能上的改变,对设计说明文档进行修改和复查,功能和
6、性能上的改变,对设计说明文档进行修改和复查,再根据设计修改进行程序变动,并用测试文档中的测试再根据设计修改进行程序变动,并用测试文档中的测试用例进行回归测试,最后将修改后的软件再次交付使用。用例进行回归测试,最后将修改后的软件再次交付使用。9/68和软件维护有关的部分问题和软件维护有关的部分问题:理解别人的代码通常是非常困难的,而且难度随着软件配置成分的缺失而迅速增加需要维护的软件往往没有文档、或文档资料严重不足、或软件的变化未在相应的文档中反映出来10/68当软件要求维护时,不能指望由原来的开发人员来完成或提供软件的解释。由于维护持续时间很长,因此当需要解释软件时候,往往开发人员已经不在附近
7、了绝大多数软件在设计时没有考虑到将来的修改问题软件维护这项工作毫无吸引力。一方面是因为软件维护,看不到什么“成果”,但工作量很大,更重要的是维护工作难度大,软件维护人员经常遭受挫折。11/68 软件维护除费用外的无形代价包括软件维护除费用外的无形代价包括 维护活动占用了其他软件开发可用的资源,使资源的利用率降低 一些修复或修改请求得不到及时安排,使得客户满意率下降 维护的结果把一些新的潜在的错误引入软件,降低了软件质量 将软件人员抽调到维护工作中,使得其它软件开发过程受到干扰 12/68 维护的工作可划分成:维护的工作可划分成:生产性活动 如,分析评价、修改设计、编写程序代码等 非生产性活动
8、如,程序代码功能理解、数据结构解释、接口特点和性能界限分析等 维护工作量的模型维护工作量的模型 M:维护的总工作量;P:生产性工作量;K:经验常数;c:复杂程度;d:维护人员对软件的熟悉程度 dcKepM13/68 影响维护工作量的因素主要有以下六种影响维护工作量的因素主要有以下六种 系统的规模:系统规模越大,其功能就越复杂,软件维护的工作量也随之增大 程序设计语言:使用强功能的程序设计语言可以控制程序的规模。语言的功能越强,生成程序的模块化和结构化程度越高,所需的指令数就越少,程序的可读性也越好14/68 系统年龄:老系统比新系统需要更多的维护工作量。数据库技术的应用:使用数据库,可以简单而
9、有效地管理和存储用户程序中的数据,还可以减少生成用户报表应用软件的维护工作量 先进的软件开发技术:在软件开发过程中,如果采用先进的分析设计技术和程序设计技术,如面向对象技术、复用技术等,可减少大量的维护工作量15/68 其它一些因素其它一些因素:如应用的类型、数学模型、:如应用的类型、数学模型、任务的难度、任务的难度、IF嵌套深度、索引或下标嵌套深度、索引或下标数等,对维护工作量也有影响数等,对维护工作量也有影响 16/68 维护组织结构图维护组织结构图 17/68 系统监督员一般都是对程序系统监督员一般都是对程序(某一部分某一部分)特特别熟悉的技术人员。别熟悉的技术人员。在维护人员对程序进行
10、修改的过程中,由在维护人员对程序进行修改的过程中,由配置管理员严格把关,控制修改的范围,配置管理员严格把关,控制修改的范围,对软件配置进行审计对软件配置进行审计。维护管理员、系统监督员、修改控制决策维护管理员、系统监督员、修改控制决策机构等,均代表维护工作的某个职责范机构等,均代表维护工作的某个职责范围围。18/68 修改控制决策机构、维护管理员可以是指修改控制决策机构、维护管理员可以是指定的某个人,也可以是一个包括管理人员、定的某个人,也可以是一个包括管理人员、高级技术人员在内的小组。高级技术人员在内的小组。系统监督员可以有其他职责,但应具体分系统监督员可以有其他职责,但应具体分管某一个软件
11、包。管某一个软件包。19/68 维护团队根据时间的不同维护团队根据时间的不同,可以分为可以分为短期短期团队团队和和长期团队长期团队 短期团队一般是当需要执行相关具体任务短期团队一般是当需要执行相关具体任务时,临时组织起来解决手头的问题时,临时组织起来解决手头的问题 长期团队则更正式,能够专业化创建沟通长期团队则更正式,能够专业化创建沟通渠道,可以管理软件系统整个生存期的成渠道,可以管理软件系统整个生存期的成功演化功演化 无论是短期团队还是长期团队,都要把有无论是短期团队还是长期团队,都要把有经验的员工和新员工混合起来。经验的员工和新员工混合起来。20/68 对于非对于非纠错性维护纠错性维护,则
12、首先判断维护类型,对,则首先判断维护类型,对适应性维护,按照评估后得到的优先级放入队适应性维护,按照评估后得到的优先级放入队列列 对于对于改善性维护改善性维护,则还要考虑是否采取行动,则还要考虑是否采取行动,如果接受申请,则同样按照评估后得到的优先如果接受申请,则同样按照评估后得到的优先级放入队列,如果拒绝申请,则通知请求者,级放入队列,如果拒绝申请,则通知请求者,并说明原因并说明原因 对于工作安排队列中的任务,由修改负责人依对于工作安排队列中的任务,由修改负责人依次从队列中取出任务,按照软件工程方法学规次从队列中取出任务,按照软件工程方法学规划、组织、实施工程。划、组织、实施工程。21/68
13、维护请求维护请求类型类型类型类型严重性严重性评估后按优先评估后按优先级在队列排队级在队列排队救火行动,当救火行动,当排在队列之首排在队列之首评估后分类评估后分类评估后按优先评估后按优先级在队列排队级在队列排队采取的行动采取的行动通知请求者通知请求者并说明原因并说明原因按优先级在按优先级在队列中排队队列中排队从维护请求队列之首取出一任务从维护请求队列之首取出一任务按按SESE方法学规划、组织、实施工程方法学规划、组织、实施工程队列中还有维护请求吗?队列中还有维护请求吗?资源用于开发新的软件。资源用于开发新的软件。y yn n纠错性维护纠错性维护其他其他改善性维护改善性维护适应性维护适应性维护拒绝
14、拒绝接受接受并不严重并不严重非常严重非常严重维护过程图维护过程图22/68每种维护请求都要进行同样的一系列技每种维护请求都要进行同样的一系列技术工作:术工作:修改软件需求说明修改软件需求说明、修改软件修改软件设计设计、设计评审设计评审、必要时重新编码必要时重新编码、单单元测试元测试、集成测试集成测试(包括回归测试包括回归测试)、确确认测试等认测试等 维护工作最后一步是复审维护工作最后一步是复审 依照当前状态,在设计、编码和测试的哪些方面还能用其他方法进行?哪些维护资源可用但未用?23/68 这次维护活动中主要(或次要)的障碍有哪些?在维护请求中有预防性维护吗?24/68 维护人员对程序进行修改
15、前要着重做好两个记维护人员对程序进行修改前要着重做好两个记录录 维护申请报告 软件修改报告 维护请求表(报告)即软件问题报告,该报告维护请求表(报告)即软件问题报告,该报告(表)由要求一项维护活动的用户填写。对改(表)由要求一项维护活动的用户填写。对改正性维护,用户需要将错误出现的现场信息详正性维护,用户需要将错误出现的现场信息详细描述出来,包括输入数据、错误清单以及其细描述出来,包括输入数据、错误清单以及其它有关材料。对适应性维护或改善性维护,应它有关材料。对适应性维护或改善性维护,应该给出一个简短的需求规格说明书。维护申请该给出一个简短的需求规格说明书。维护申请被批准后,维护申请报告就成为
16、外部文档,作被批准后,维护申请报告就成为外部文档,作为本次维护的依据为本次维护的依据 25/68 软件修改报告指明:为满足维护申请报告软件修改报告指明:为满足维护申请报告提出的需求所需的工作量、本次维护活动提出的需求所需的工作量、本次维护活动的类别、本次维护请求的优先级、本次修的类别、本次维护请求的优先级、本次修改的背景数据。在拟定进一步维护计划前,改的背景数据。在拟定进一步维护计划前,软件修改报告要提交给修改决策机构,供软件修改报告要提交给修改决策机构,供进一步规划维护活动使用进一步规划维护活动使用 保存维护记录的第一个问题就是哪些数据保存维护记录的第一个问题就是哪些数据值得保存?值得保存?
17、26/68如果已经开始保存维护记录,可以对维护工如果已经开始保存维护记录,可以对维护工作做一些定量度量,至少可以从如下作做一些定量度量,至少可以从如下7方面进方面进行评价:行评价:每次程序运行平均失败的次数;用于每一类维护活动的总人时数;平均每个程序、每种语言、每种维护类型所必需的程序变动数;维护过程中增加或删除源语句平均花费的人时数;维护每种语言平均花费的人时数;一张维护请求表的平均周转时间;不同维护类型所占的比例;27/68 可维护性(可维护性(maintainability)指理解、改正、调整和改进软件的难易程度。对软件可维护性影响的主要因素有:可理解性(understandabilit
18、y)、可测试性(testability)、可修改性、modifiability)和可移植性(portability)28/68 可理解性可理解性:指理解软件的结构、接口、功:指理解软件的结构、接口、功能和内部过程的难易程度。能和内部过程的难易程度。提高软件可理解性的措施有:采用模块化提高软件可理解性的措施有:采用模块化的程序结构;书写详细正确的文档;采用的程序结构;书写详细正确的文档;采用结构化程序设计;书写源程序的内部文档;结构化程序设计;书写源程序的内部文档;使用良好的编程语言;具有良好的程序设使用良好的编程语言;具有良好的程序设计风格等计风格等 29/68 可测试性可测试性:指测试和诊断
19、软件(主要指程:指测试和诊断软件(主要指程序)中错误的难易程度。序)中错误的难易程度。提高软件可测试性的措施有:采用良好的提高软件可测试性的措施有:采用良好的程序结构;书写详细正确的文档;使用测程序结构;书写详细正确的文档;使用测试工具和调试工具;保存以前的测试过程试工具和调试工具;保存以前的测试过程和测试用例等和测试用例等 30/68 可修改性可修改性:指修改软件(主要指程序)的:指修改软件(主要指程序)的难易程度。难易程度。在修改软件时经常会发生这样的情况:修在修改软件时经常会发生这样的情况:修改了程序中某个错误的同时又产生新的错改了程序中某个错误的同时又产生新的错误(由程序的修改引起的)
20、;或者在程序误(由程序的修改引起的);或者在程序中增加了某个功能后,导致原先的某些功中增加了某个功能后,导致原先的某些功能不能正常执行。能不能正常执行。31/68 可移植性可移植性:指程序转移到一个新的计算环境的:指程序转移到一个新的计算环境的难易程度。难易程度。影响软件可移植性的因素有:信息隐蔽原则;影响软件可移植性的因素有:信息隐蔽原则;模块独立;模块化;高内聚低耦合;良好的程模块独立;模块化;高内聚低耦合;良好的程序结构;不用标准文本以外的语句等序结构;不用标准文本以外的语句等 一个可移植的程序应具有结构良好、灵活、不一个可移植的程序应具有结构良好、灵活、不依赖于某一具体计算机或操作系统
21、的性能依赖于某一具体计算机或操作系统的性能 32/68通常对于软件可移植性的度量考虑如下因素通常对于软件可移植性的度量考虑如下因素 是否是用高级的独立于机器的语言来编写程序?是否采用广泛使用的标准化的程序设计语言来编写程序?是否仅使用了这种语言的标准版本和特性?程序中是否使用了标准的普遍使用的库功能和子程序?程序中是否极少使用或根本不使用操作系统的功能?33/68 程序在执行之前是否初始化内存?程序在执行之前是否测定当前的输入输出设备?程序是否把与机器相关的语句分离了出来,集中放在了一些单独的程序模块中,并有说明文件?程序是否结构化?并允许在小一些的计算机上分段(覆盖)运行?程序中是否避免了依
22、赖于字母数字或特殊字符的内部位表示?34/68 在进行设计评审时,要从易于维护和提高在进行设计评审时,要从易于维护和提高设计总体质量的角度全面评审数据设计、设计总体质量的角度全面评审数据设计、总体结构设计、过程设计和界面设计。在总体结构设计、过程设计和界面设计。在进行代码评审时,要强调编程风格和内部进行代码评审时,要强调编程风格和内部文档。在进行测试时应指出软件正式交付文档。在进行测试时应指出软件正式交付前应进行的预防性维护。在维护活动完成前应进行的预防性维护。在维护活动完成后也要进行评审。后也要进行评审。35/68 通常采用的方法有通常采用的方法有 确定质量管理目标和优先级 规范化程序设计风
展开阅读全文