软件工程理论与实践:第11章 系统的维护

上传人:cn****1 文档编号:572743361 上传时间:2024-08-13 格式:PPT 页数:40 大小:1.13MB
返回 下载 相关 举报
软件工程理论与实践:第11章 系统的维护_第1页
第1页 / 共40页
软件工程理论与实践:第11章 系统的维护_第2页
第2页 / 共40页
软件工程理论与实践:第11章 系统的维护_第3页
第3页 / 共40页
软件工程理论与实践:第11章 系统的维护_第4页
第4页 / 共40页
软件工程理论与实践:第11章 系统的维护_第5页
第5页 / 共40页
点击查看更多>>
资源描述

《软件工程理论与实践:第11章 系统的维护》由会员分享,可在线阅读,更多相关《软件工程理论与实践:第11章 系统的维护(40页珍藏版)》请在金锄头文库上搜索。

1、Maintaining the System系统的维护SOFTWARE ENGINEERING 11.1 The changing system 变化的系统Software system are evolutionary.lA customer makes a decision to do something a different way.lThe nature of the system itself changes. Types of Systems, in terms of the way it is related to the environment in which it ope

2、rateslS-systemslP-systemslE-systems软件系统是演化的顾客以不同的方式做某件事系统自身的属性发生了改变系统类型,用系统和系统运行的环境来描述S-systemsFormally defined, derivable from a specificationStatic system, no change requiredExamples: mathematical operations形式化定义、源自说明描述静态系统,无改变需要P-systemsThe system is based on a practical abstraction of the proble

3、m rather then on a completely defined specificationAbstraction and solution may changeExamples: pattern recognition systems系统基于问题的一个可行的抽象,而不是一个完全定义好的说明抽象与解决方案可能变化模式识别系统E-systemsEmbedded in the real world and changes as the world doesThe problem cannot be specified completelyThe success depends on th

4、e customer evaluationExamples: banking systems, ERP systems嵌入真实世界中并随着真实世界的改变而改变问题不能被完全说明成功取决于客户评价Changes during the system life cycle在系统生命周期中的变化A change at any stage of development can also affect the results of previous as well as subsequent stages.在开发中任意环节的改变,都可能影响前面的结果和后面的环节。 软件开发中变动的例子软件开发中变动的例子

5、Table 11.1. Examples of change during software development.Activity from which initial change resultsArtifacts requiring consequent changeRequirements analysisRequirements specificationSystem designArchitectural design specificationTechnical design specificationProgram designProgram design specifica

6、tionProgram implementationProgram codeProgram documentationUnit testingTest plansTest scriptsSystem testingTest plansTest scriptsSystem deliveryUser documentationTraining aidsOperator documentationSystem guideProgrammer guideTraining classesThe system life span 系统生命期Development Time vs. Maintenance

7、Time 开发时间与维护时间Typical development project takes between 1 and 2 years, but . requires an additional 5 to 6 years of maintenance time! 典型的开发项目耗时1-2年,但需要5-6年的维护时间。80-20 RulelTwenty percent of the effort is in development and eighty percent is in maintenance.工作量的20%是开发,而80%是维护。System evolution vs. decl

8、ine 系统演化和系统衰退的比较Is the cost of maintenance too highIs the system reliability unacceptableCan the system no longer adapt to further change, and within a reasonable amount of timeIs system performance still beyond prescribed constraintsAre system functions of limited usefulnessCan other systems do the

9、 same job better, faster or cheaperIs the cost of maintaining the hardware great enough to justify replacing it with cheaper, newer hardware维护的成本太高吗?系统的可靠性可以接受吗?在一个合理的时间内,系统不能再适应进一步的变化了吗?系统性能仍旧超出预先规定的约束条件吗?系统功能的作用有限吗?其他的系统能更好、更快、更廉价地做同样的工作?维护硬件的成本高得足以用更便宜、更新的硬件来取代吗?Laws of software evolution 软件演化法则C

10、ontinuing change(连续的变化):程序持续地被改动,或者变得越来越无用。变动或衰退过程一直持续着,直到用一个重新创建的版本来代替原系统更划算为止。Increasing complexity(递增的复杂性):当一个演化的程序被持续改动时,它的结构恶化了。因此它的复杂性增加,除非进行一些维护或减少它。Fundamental law of program evolution (程序演化的基本法则):程序演化服从于一种动力,这种动力产生了编程过程,从而产生了全局项目和系统属性的度量,它自身由某种统计确定的趋势和恒定性来调节。Conservation of organizational s

11、tability (组织稳定性的守恒):在一个程序的活动周期中,编程项目的总体活动统计上是不变的。Conservation of familiarity(熟悉程度的守恒 ):在一个程序的活动周期中,因程序演化连续发布版本的发布内容(改动、增加、删减)统计上是不变的。11.2 the nature maintenance 维护的本质Corrective( ): maintaining control over day-to-day functionsAdaptive( ): maintaining control over system modificationsPerfective( ): p

12、erfecting existing functionsPreventive( ): preventing system performance from degrading to unacceptable levels 防止系统性能下降到不可接受改正性维护维持控制日常功能适应性维护维持控制系统修改完善性维护完善现有的功能预防性维护Who performs maintenance 由谁进行维护Often, a separate group of analysts, programmers, and designers is designated as the maintenance team.

13、通常,人们会指派一个单独的维护小组,这个小组包括分析员、程序员和设计人员。Maintenance team responsibilities 维护小组的职责维护小组的职责understanding the systemlocating information in system documentationkeeping system documentation up-to-dateextending existing functions to accommodate new or changing requirementsadding new functions to the systemfi

14、nding the source of system failures or problemslocating and correcting faultsanswering questions about the way the system worksrestructuring design and code componentsrewriting design and code componentsdeleting design and code components that are no longer usefulmanaging changes to the system as th

15、ey are made理解系统定位系统文档中的信息保持系统文档更新扩展现有功能以容纳新的或变动的需求给系统增加新的功能找出系统故障或问题的根源定位和纠正故障回答有关系统运行方式的问题重构设计和代码组件重新编写设计和代码组件删除不再有用的设计和代码组件进行系统改动Use of maintenance time维护时间的分配Perfective完善性维护: 50%Adaptive适应性维护: 25%Corrective改正性维护: 21%Preventive预防性维护: 4%11.3 Maintenance problems 与维护有关的问题Staff problemslLimited under

16、standinglManagement prioritieslMoraleTechnical problemslArtifacts and paradigmslTesting difficulties人员问题理解的局限性管理的优先级士气技术问题工件和范例测试困难Factors affecting maintenance effort 影响维护成果的因素Application typeSystem noveltyTurnover and maintenance staff abilitySystem life spanDependence on a changing environmentHar

17、dware characteristicsDesign qualityCode qualityDocumentation qualityTesting quality应用类型系统新奇度人员翻新和维护人员能力系统生命期对变化的环境的依赖硬件特性设计质量代码质量文档质量测试质量Modelig maintenance effortd 对维护工作量建模Belady and Lehman公式 M = p + K c - d其中:M是一个系统花费的所有维护工作量 p表示分析、评价、设计、编码以及测试的总工作量 K是个常量,通过与实际工作量比较而定 c是由于缺乏结构化和文档引起的复杂度 d表示维护小组对软件

18、的熟悉程度,d削弱了cCOCOMO II计算维护工作量公式计算维护工作量公式Size=ASLOC(AA+SU+0.4DM+0.3CM+0.3IM)/100ASLOC:要改动的代码行数AA:评估和修改评分SU:加权因子项CM: 要修改的代码的百分比DM:要修改的设计的百分比IM:要集成的外部代码的百分比 COCOMO II软件理解的评分软件理解的评分Table 11.2. COCOMO II rating for software understanding.Very lowLowNominalHighVery highStructure结构Very lowcohesion, highcoupl

19、ing,spaghetti codeModerately lowcohesion, highcouplingReasonablywell-structured;some weakareasHigh cohesion,low couplingStrongmodularity,information-hiding in dataand controlstructuresApplicationClarity应用程序清晰度No matchbetweenprogram andapplicationworld viewsSomecorrelationbetweenprogram andapplicatio

20、nModeratecorrelationbetweenprogram andapplicationGoodcorrelationbetweenprogram andapplicationClear matchbetweenprogram andapplicationworld viewsSelf-Descriptiveness自描述Obscure code;documentationmissing,obscure orobsoleteSome codecommentaryand headers;some usefuldocumentationModerate levelof codecomme

21、ntary,headers,documentationGood codecommentaryand headers;usefuldocumentation;some weakareasSelf-descriptivecode;documentationup-to-date,well-organized,with designrationale SU增值SU increment5040302010 COCOMO II 评估和修改的评分评估和修改的评分Table 11.3. COCOMO II ratings for assessment and assimilation effort.Asses

22、sment and assimilation incrementLevel of assessment and assimilation effort0None2Basic component search and documentation4Some component test and evaluationdocumentation6Considerable component test and evaluationdocumentation8Extensive component test and evaluationdocumentation11.4 Measuring mainten

23、ance characteristics 度量维护特性External view of maintainability 可维护性的外部属性Internal attributes affecting maintainability 影响可维护性的内部属性External view of maintainability 可维护性的外部属性Necessary dataltime at which problem is reportedltime lost due to administrative delayltime required to analyze problemltime require

24、d to specify which changes are to be madeltime needed to make the changeltime needed to test the changeltime needed to document the change(用平均修复时间度量所)必须的数据问题报告的时间由于行政管理延迟浪费的时间分析问题需要的时间确定进行哪种改动需要的时间进行改动需要的时间测试变动需要的时间记录变动需要的时间External view of maintainability 可维护性的外部属性Desirable data:lratio of total cha

25、nge implementation time to total number of changes implementedlnumber of unresolved problemsltime spent on unresolved problemslpercentage of changes that introduce new faultslnumber of components modified to implement a change可能有用的数据实现改动的总时间与实现的改动的总数目之比未解决问题的数目花在未解决问题上的时间引入新故障的改动的百分比为实现一个改动而修改的组件数In

26、ternal attributes affecting maintainability 影响可维护性的内部属性cyclomatic number 环路数Scoreboard:drawscore(int n)while(numdigits- 0 scorenumdigits-erase();/ build new score in loop, each time update positionnumdigits = 0;/ if score is 0, just display “0”if (n = 0) delete scorenumdigits;scorenumdigits = new Di

27、splayable(di gits0);scorenumdigits-move(Point(700-numdigits*18),40);scorenumdigits-draw();numdigits+;while (n) int rem = n % 10;delete scorenumdigits;scorenumdigits = new Displayable(digitsrem);scorenumdigits-move(Point(700-numdigits*18),40);scorenumdigits-draw();n /= 10;numdigits+;环路数代码中判定语句数环路数代码中

28、判定语句数1环路数计算的例子环路数划分平面数环路数划分平面数线性无关路径线性无关路径e n + 2Fog index可读性度量指标F = 0.4 单词数单词数句子数句子数 3个以上音节的词的百分比个以上音节的词的百分比11.5 Maintenance Techniques and Tools维护技术和工具Configuration ManagementlConfiguration Control BoardlChange ControlImpact AnalysislEvaluation of the many risks associated with the change, includi

29、ng estimates of effects on resources, effort and scheduleAutomated Maintenance Tools配置管理配置管理委员会 变动控制后果分析对与变动有关的多项风险的评估,包括对资源、工作量和进度影响的评估自动维护工具Change control issues 变动控制Synchronization 同步:When was the change made?变动是何时进行的?Identification 标识 : Who made the change?由谁进行改动的?Naming 命名 : What components of

30、the system were changed? 系统的那个组件被改动了?Authentication 鉴定 :Was the change made correctly? 改动正确地进行了吗?Authorization 授权 :Who authorized that the change be made?是谁批准进行的改动?Routing 发送 :Who was notified of the change?改动通知了那些人?Cancellation 取消 :Who can cancel the request for change?谁能取消变动的请求?Delegation委托 :Who i

31、s responsible for the change?谁对改动负责?Valuation 评价 :What is the priority of the change?改动的级别是什么?Impact analysis 后果分析Workproduct( ): any development artifact whose change is significantHorizontal traceability( ): relationships of components across collections of workproductsVertical traceability( ): re

32、lationships among parts of a workproduct工作产品水平可追踪性垂直可追踪性改动起来有重要影响的开发工件工作产品集之间组件的关系工作产品中各部分之间的关系软件维护活动Horizontal traceability 水平可追踪性Underlying graph for maintenance维护的基础图Automated maintenance tools 自动维护工具Text editorsFile comparatorsCompilers and linkersDebugging toolsCross-reference generatorsStatic

33、code analyzersConfiguration management repositories文本编辑器文件比较器编译器和连接器调试工具交叉引用生成器静态代码分析器配置管理库Software rejuvenation 软件再生Redocumentation( ): static analysis adds more informationRestructuring( ): transform to improve code structureReverse engineering( ): recreate design and specification information fro

34、m the codeReengineering( ):文档重构静态分析,得出更多的信息结构重组使代码结构变好逆向工程从代码中重构出设计和说明信息再工程软件再生分类Redocumentation 文档重构Output may include( ):lcomponent calling relationshipsldata-interface tablesldata-dictionary informationldata flow tables or diagramslcontrol flow tables or diagramslPseudocodeltest pathslcomponent and variable cross-references输出可能包括组件调用关系数据接口表数据字典信息数据流表或图控制流表或图伪代码测试路径组件和变量的交叉引用RedocumentationRestructuring结构重组Reverse Engineering逆向工程Reengineering再工程

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 高等教育 > 研究生课件

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号