Maintaining the System

中国科学技术大学软件学院孟宁

2012年 11月

Contents

11.1 The Changing System11.2 The Nature of Maintenance11.3 Maintenance Problems11.4 Measuring Maintenance

Characteristics11.5 Maintenance Techniques and Tools11.6 Software Rejuvenation

Chapter 11 Objectives

♦ System evolution

♦ Legacy systems

♦ Impact analysis

♦ Software rejuvenation

11.1 The Changing System

♦ Maintenance: any work done to change the system after it is in operation– Software does not degrade or require periodic

maintenance– However, software is continually evolving

• Maintenance process can be difficult

11.1 The Changing SystemLehman’s System Types

♦ S-system: formally defined, derivable from a specification– Matrix manipulation矩阵运算

♦ P-system: requirements based on approximate solution to a problem, but real-world remains stable– Chess program

♦ E-system: embedded in the real world and changes as the world does– Software to predict how economy functions (but

economy is not completely understood)

11.1 The Changing SystemS-System

♦ Problem solved is related to the real world

11.1 The Changing SystemP-System

♦ The solution produces information that is compared with the problem

11.1 The Changing SystemE-System

♦ It is an integral part of the world it models– The changeability depends on its real-world

context

11.1 The Changing SystemExamples of Change During Software Development

Activity from which Initial change results

Artifacts requiring consequent change

Requirement analysis Requirement specification

System design Architectural design specificationTechnical design specification

Program design Program design specification

Program implementation Program codeProgram documentation

Unit testing Test plansTest scripts

System testing Test plansTest scripts

System delivery User documentationOperator documentationSystem guideProgrammer’s guideTraining classes

11.1 The Changing SystemThe System Life Span 跨度

♦ Will we need maintenance phase?– Even if best practices are followed, still need

maintenance (because of E and P systems)♦ Development time vs. maintenance time

– Recent surveys: 20% vs 80%♦ How much change can we expect?

– System evolution vs. system decline: better to discard and build a new?

• Cost/reliability/adaptability to change unacceptable?

– Laws of software evolution

11.1 The Changing SystemLaws of Software Evolution

♦ Continuing change: leads to less utility♦ Increasing complexity: structure

deteriorates 恶化♦ Fundamental law of program evolution:

program obeys statistically-determined trends and invariants 不变量

♦ Conservation of organizational stability: global activity rate is invariant

♦ Conservation of familiarity: release content (changes) is statistically invariant

11.2 The Nature of MaintenanceTypes of Maintenance

♦ Corrective: maintaining control over day-to-day functions

♦ Adaptive: maintaining control over system modifications

♦ Perfective: perfecting existing functions

♦ Preventive: preventing system performance from degrading to unacceptable levels

11.2 The Nature of MaintenanceWho Performs Maintenance

♦ Separate maintenance team– May be more objective– May find it easier to distinguish how a system

should work from how it does work

♦ Part of development team– Will build the system in a way that makes

maintenance easier– May feel over confident, and ignore the

documentation to help maintenance effort

11.2 The Nature of MaintenanceMaintenance Team Responsibilities

• Understanding the system• Locating information in system documentation• Keeping system documentation up-to-date• Extending existing functions to accommodate new or

changing requirements• Adding new functions to the system• Finding the source of system failures or problems♦ Locating and correcting faults♦ Answering questions about the way the system works♦ Restructuring design and code components♦ Rewriting design and code components♦ Deleting design and code components that are no longer useful♦ Managing changes to the system as they are made

11.2 The Nature of MaintenanceUse of Maintenance Time

♦ Graphical representation of distribution of maintenance effort (Lientz and Swanson)

11.3 Maintenance Problems

♦ Staff problems– Limited understanding (47% of effort is spent

on understanding)– Management priorities: rushing a new product

to the market– Morale 士气 : “second-hand二等公民” status

accorded to maintenance team ♦ Technical problems

– Artifacts and paradigms (e.g., legacy, non-OO)– Testing difficulties (some systems must be

available around a clock)

11.3 Maintenance ProblemsFactors Affecting Maintenance Effort

♦ Application type♦ System novelty♦ Turnover and maintenance staff ability♦ System life span♦ Dependence on a changing environment♦ Hardware characteristics♦ Design quality♦ Code quality♦ Documentation quality♦ Testing quality

11.4 Measuring Maintenance Characteristics

♦ Maintainability is not only restricted to code, but also including specification, design and test plan documentations

♦ Maintainability can be viewed in two ways– External view of the software: users, person

performing maintenance– Internal view of the software: measuring

before delivery

Cyclomatic number环路数目♦ Linearly independent path = e - n + 2

– e: edges, n : nodes

11.5 Maintenance Techniques and Tools

♦ Configuration management– Configuration control board– Change control

♦ Impact analysis

♦ Automated maintenance tools

11.5 Maintenance Techniques and Tools Software Maintenance Activities

♦ Graph illustrates the activities performed when a change is requested

11.5 Maintenance Techniques and Tools Horizontal Traceability

♦ The graphical relationships and traceability links among related workproducts

11.5 Maintenance Techniques and ToolsAutomated Maintenance Tools

♦ Text editors

♦ File comparators

♦ Compilers and linkers

♦ Debugging tools

♦ Cross-reference generators

♦ Static code analyzers

♦ Configuration management repositories

11.6 Software Rejuvenation再生

♦ Redocumentation: static analysis adds more information

♦ Restructuring: transform to improve code structure

♦ Reverse engineering: recreate design and specification information from the code

♦ Reengineering: reverse engineer and then make changes to specification and design to complete the logical model; then generate new system from revised specification and design

11.6 Software Rejuvenation

♦ Graph illustrates the relationship among the four types of rejuvenation

What this Chapter Means for You

♦ The more a system is linked to the real world, the more likely it will change and the more difficult it will be to maintain

♦ Maintainers have many jobs in addition to software developers

♦ Measuring maintainability is difficult♦ Impact analysis builds and tracks links among the

requirements, design, code, and test cases♦ Software rejuvenation involves redocumenting,

restructuring, reverse engineering, and reengineering

谢谢大家！

References软件工程 - 理论与实践（第四版 影印版） Software Engineering: Theory and Practice (Fourth Edition),Shari Lawrence Pfleeger,Joanne M. Atlee ,高等教育出版社软件工程 - 理论与实践（第四版） Software Engineering: Theory and Practice (Fourth Edition),Shari Lawrence Pfleeger,Joanne M. Atlee, 杨卫东译 , 人民邮电出版社软件工程—实践者的研究方法（ Software Engineering-A Practitioner’s Approach ） ; ( 美 ) Roger S. Pressman 著； 机械工业出版社 ISBN ： 7-111-07282-0http://code.google.com/p/advancedsoftwareengineering/