软件工程第13章

第13章软件维护软件维护是软件生命周期的最后一个阶段，软件从部署完毕到退役的整个时间内对软件的改动所做的工作都是维护的内容。在项目的各个阶段对项目的可维护性进行充分考虑、对可维护性的严格评审以及在维护阶段有效地组织和管理维护活动，则是保证软件可维护性和降低维护费用的关键。本章重点内容：维护的主要内容、维护的流程、如何在软件的生产过程各个阶段保证软件的可维护性目标。13.1软件维护的基本内容软件维护的主要目标是使已部署的软件按照需求规格说明书的要求（或用户的新需求）运行，这要求软件不仅要满足用户所需要的各项功能需求，同时还要满足用户对软件的非功能需求。软件维护的基本内容则包含了实现这些目标所做的全部工作。13.2软件维护的分类按照维护的起因分类：纠错性维护适应性维护改善性维护预防性维护四类。1.纠错性维护——为改正软件系统中潜藏的错误而进行的活动。用户在使用软件过程中发现软件的错误是激发该种维护的起因。四类13.2软件维护的分类2.适应性维护——为适应软件运行环境的变化而修改软件的活动。软件的运行环境包括两个方面，硬件和软件，软件则大体上包括操作系统、中间件、虚拟机等等。13.2软件维护的分类3.改善性维护——根据用户在软件使用过程中提出的建设性意见而进行的维护活动。主要是针对用户提出的新的软件需求或修改原有的软件需求而进行的维护，该种维护通常占所有维护工作量的一半以上。软件在部署之后一段时间内，用户的改善性维护应该是递减的。13.2软件维护的分类4.预防性维护——为了进一步改善软件系统的可维护性和可靠性，并为以后的改进奠定基础。预防性维护可以采取逆向工程（reverseengineering）和重构工程（re-engineering）方式。13.2软件维护的分类严格按照软件工程标准生产的软件产品在维护过程中纠错性维护的工作量很低，不到总维护工作量的1／5。由于改善性维护和适应性维护需要修改需求规格说明书，应按照需求变更来进行管理，相当于螺旋模型中的又一次迭代过程，因此工作量很大。13.3软件维护的特点软件维护是一种繁琐而又不可或缺的工作，由于维护通常要求维护人员在用户现场进行，而且维护任务可能非常紧急，因此对现场维护人员的压力很大。而且没有丝毫的成就感。13.3.1结构化维护与非结构化维护非结构化维护——软件的配置中只有源代码。由于没有 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 和设计文档，无法对程序的功能进行反向追踪，理解别人的代码是很痛苦的事情。由于配置中没有测试文档，所以维护后的代码无法进行回归测试。因而导致程序的结构化被不断的破坏，维护的质量无法得到保证。13.3.1结构化维护与非结构化维护结构化维护——待维护的软件的配置是完整的。用户提出的维护申请用正向追踪很容易从分析设计文档追踪直至代码中，从而使维护人员很容易定位代码的维护点。所以这种维护不会破坏软件的结构。结构化维护不仅能减少维护的工作量，还能提高维护的质量。图15-3-1非结构化维护和结构化维护维护请求配置理解代码功能理解？修改代码测试复审理解设计 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 规划修改设计修改代码测试复审交付使用软件代码13.3.2维护成本20世纪70年代，软件的维护费用约占软件总预算的35~40%。80年代时，软件维护费用进一步增加，约占软件总预算的60%。近年来，该值已上升到80%左右。随着软件复杂性的不断提高，软件的维护难度越来越大。这不仅导致维护成本不断增高，软件生产率急剧下降，还会带来其他方面的负面影响。维护工作量的估算模型M＝P+Ke(c-d)其中：M：维护所用工作量；P：生产性工作量—分析评价、修改设计和代码；Ke(c-d)：助动性工作量—理解文档和代码；K：经验常数；c：软件的维护复杂度，由软件本身的复杂度，软件的设计质量以及文档化的程度等因素决定；d：维护人员对软件的熟悉程度；可见维护工作量同软件的维护复杂度成指数关系。13.3.3维护可能存在的问题1）无法追踪软件的整个创建过程。2）无法追踪软件版本的进化过程。软件交付使用后对软件不断修复和完善的过程，就是软件版本的进化过程，每一次进化都会使软件的主、次版本号增大。3）理解别人的程序非常困难。4）得不到开发人员的帮助。5）软件配置不完整或不正确。6）分析和设计的缺陷。7）维护工作让人没有成就感。13.4软件维护过程13.4.1维护组织维护组织一般由维护员，维护管理员，系统管理员，修改控制决策机构，配置管理员组成。维护员——真正执行维护的人员；维护管理员——协调维护活动的人员；系统管理员——系统的管理者；修改控制决策机构——决定一次维护的走向。修改控制和决策机构、用户、系统管理员、维护人员之间不能跨越维护管理员进行沟通和采取行动。图15-4-1维护组织信息流图修改控制决策机构系统管理员维护管理员维护员配置管理员维护申请单维护流程用户的维护请求激发了一次维护活动，用户将维护申请提交给维护管理员，维护管理员将该维护请求交给系统管理员对维护活动可能引起的软件修改进行评估，并将评估结果反馈给维护管理员，维护管理员按照维护请求单制定软件修改报告单并提交给修改决策机构进行维护决策。修改决策机构根据情况决定采取的行动（拒绝请求还是接收请求），并把结果反馈给维护管理员，如果允许维护，维护管理员将通知维护员执行该次维护。13.4.2维护的报告与审核用户提出的维护申请必须采用标准的格式，须填写由维护人员制定的：维护申请单（MaintenanceRequestForm，MRF）或软件问题报告单（SoftwareProblemReport，SPR）。如果是纠错性维护，应填写SPR。在填写SPR时，用户必须完整地记录出错信息（什么错误）和出错场景（在什么情况下出现的错误）。其他种类的维护，要填MRF。在MRF中应该附加简短的修改规格说明，也就是在需求规格说明书中应作哪些改动，比如增加功能或修改功能等。13.4.2维护的报告与审核维护管理员将MRF后之提交给系统管理员，并据此对软件改动量作评估。系统管理员核准该维护申请后，维护组织内部要制定一个软件修改报告单（SoftwareChangeReport，SCR），MRF并不是软件文档的配置项。而软件修改的真正依据是SCR，其内容如下：1）本次修改所需工作量；2）本次维护活动的性质；3）本次维护请求的优先级；4）本次修改的背景数据（来自于MRF或SPR的陈述）。将SCR提交给修改控制决策机构，作为维护进一步工作的依据。SCR是保证软件版本进化可跟踪性所必须的文档。13.4.3维护过程的事件流用户的维护请求提交给维护组织后的信息流程如图15-4-2所示。收到维护请求后，维护组织首先要判断维护的类型，即本次维护请求是纠错性维护还是其他类型的维护。对于纠错维护要启动纠错维护流程，如果是其他类型的维护则启动适应性或改善性维护流程。用户和维护组织有时会对维护的类型有不同的看法。图15-4-2维护活动的事件流其他出错维护请求类型“救火活动”当排在队列之首严重性按SE方法学规划、组织、实施工程队列中还有维护请求评估后分类评估后按优先级在对列排队通知请求者并说明原因资源用于开发新的软件采取行动从维护请求队列之首取一任务类型按优先级在对列中排队评估后按优先级在队列排队是否适应性改善性非常严重并不严重是否13.4.4保存维护记录为了能够很好地评价维护的有效性，必须详细记录软件维护过程中的各种数据，这些数据包括：（1）程序标志；（2）源程序行数；（3）目标程序的指令条数；（4）所用的编程语言；（5）安装程序的日期；（6）自安装之日起程序运行的次数；（7）自安装之日起程序失败的次数；（8）程序修改处的层数和标志；13.4.4保存维护记录（9）因程序变动而增加和删除的源程序行数；（10）每处改动所耗费的人时数；（11）程序改动的日期；（12）软件工程师标志；（13）MRF的标志；（14）本次维护的类型；（15）维护开始和结束的日期；（16）用于本次维护累计的人时数；（17）执行本次维护的纯利润。上述数据应保存到维护数据库里，作为维护评价的依据。13.4.5评价维护活动通过每次维护活动的详细记录，可通过下面的指标度量维护的有效性：（1）程序运行的平均失效次数（失效次数／运行的次数）；（2）维护活动耗费的总人时数；（3）各种程序，及各种语言的平均变动数；（4）维护阶段修改每条语句所花费的人时数；（5）维护每种语言的程序平均花费的人时数；（6）一张MRF的平均周转时间；（7）各类维护请求的百分比。13.5维护的副作用维护的副作用是指，由于维护或在维护过程中其他一些不期望的行为引入的错误。副作用可分三类：（1）代码副作用—下面的修改最易引起副作用：①修改或删除子程序；②修改或删除语句标号；③修改或删除标识符；④为提高程序效率而做的修改；⑤修改逻辑操作符；⑥由设计变动引起的代码修改；⑦修改分支处的判断条件；代码副作用大多数可在回归测试中发现。13.5维护的副作用（2）数据副作用数据副作用是由于修改数据结构带来的副作用。容易引起数据副作用的修改包括：①局部和全局常量的再定义；②记录或文件格式的再定义；③增减数据或是由于修改数据结构的定义导致数据结构长度的改变；④修改全局数据；⑤重新初始化控制标志和指针；⑥重新排列I/O 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 或子程序参数表。设计文档化有助于抑制数据副作用，在设计文档中有关于数据结构的详细描述和交叉访问表。13.5维护的副作用（3）文档副作用由于程序修改而没有对文档进行相应的修改引起文档的副作用。必须保持文档和程序的一致性。每次维护之后，再次交付软件之前应仔细评审整个配置，这样才能更好地减少文档的副作用。13.6软件的可维护性软件的可维护性是指软件被理解和被正确改动的难易程度。软件的可维护性差是软件维护工作量和费用激增的直接原因，因此在软件工程的各个阶段都要保证软件具有较高可维护性，从而降低软件维护成本，这是软件工程的重要目标之一。13.6.1影响可维护性的因素软件的可维护性主要受下面因素影响：（1）软件的构造过程是否严格按照软件工程的方法进行；（2）开发团队是否训练有素；（3）软件的开发平台（操作系统和开发语言）是否标准。总结起来就是：开发团队（人）是否使用了通用的工具采用标准的方法来构造软件。13.6.2可维护性的度量通过维护记录可间接度量可维护性。（1）问题、收集维护工具以及分析问题所用的时间；（2）形成修改说明书所用的时间；（3）修改设计和源代码所用的时间；（4）测试所用时间；（5）复审所用时间；（6）完全恢复所用时间。以上时间越短则软件的可维护性越好。13.6.3可维护性复审在软件工程每一阶段的复审中，可维护性都是一个重要的指标。在需求分析阶段的复审中，应在规格说明书中对将来可能修改和可以改进的部分加以注明；在设计阶段的复审中，应该从易于维护和提高设计总体质量的角度对设计进行全面评审；代码复审主要审查代码风格和内部文档（程序注释等）这两个直接影响可维护性的因素。最后，每一阶段性测试，直到软件正式交付之前，都应该进行的预防性维护。正式的可维护性复审放在测试完成之后，称为配置复审。目的是保证配置中所有成分的完整、一致、易于理解且便于修改控制。演讲完毕，谢谢观看！