ch11: maintaining the system
DESCRIPTION
CH11: Maintaining the System. maintenance process can be difficult * The Changing System * The Nature of Maintenance * Maintenance Problems * Measuring Maintenance Characteristics * Maintenance Techniques and Tools * Software Rejuvenation. TECH Computer Science. The Changing System. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/1.jpg)
CH11: Maintaining the System
• maintenance process can be difficult• * The Changing System• * The Nature of Maintenance • * Maintenance Problems• * Measuring Maintenance Characteristics• * Maintenance Techniques and Tools• * Software Rejuvenation
TECH Computer Science
![Page 2: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/2.jpg)
The Changing System
• Any work done to change the system after it is in operation is considered to be maintenance.
• Unlike hardware, software does not degrade or require periodic maintenance (?).
• Types of Systems:S, P, E
![Page 3: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/3.jpg)
Real world
Problem
Requirementsspecification
System
Information
Comparison
Subject to change
S-System: the solution of the problem is well-know
![Page 4: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/4.jpg)
P-System: based on a practical abstraction of the problem
Real world
Problem
Requirementsspecification
System
Information
Comparison
Subject to change
Abstraction
![Page 5: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/5.jpg)
E-System: embedded in the real world and changes as the world does.
Comparison
Subject to change
Problem
Requirementsspecification
System
Information
Abstraction
Real world
![Page 6: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/6.jpg)
Change During the System Life Cycle
• Everything Change• Take change into consideration during system
development.• Make it easier to change during maintenance
![Page 7: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/7.jpg)
The System Life Span
• Is it possible to build a system right the first time?• Maintenance state of development is the evolutionary
phase of the system.• Legacy systems were built earlier when our needs
and environment were different.
![Page 8: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/8.jpg)
Development Time vs. Maintenance Time
• Typical development project takes between 1 and 2 years, but
• requires an additional 5 to 6 years of maintenance time!
• 80-20 Rule: Twenty percent of the effect is in development and eighty percent is in maintenance.
![Page 9: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/9.jpg)
System Evolution vs. System Decline: When shall we discard the old system and build a new one to replace it?
Is the cost of maintenance too high? Is the system reliability unacceptable?Can the system no longer adapt to further change, and
within a reasonable amount of time? Is system performance still beyond prescribed
constraints?Are system functions of limited usefulness?Can other systems do the same job better, faster, or
cheaper? Is the cost of maintaining the hardware great enough to
justify replacing it with cheaper, newer hardware?
![Page 10: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/10.jpg)
“Laws of Software Evolution”Continuing change: changing till replacing by recreated
version Increasing complexity: structure deteriorates and
complexity increasesFundamental law of program evolution: subjected to
self-regulating with statistically-determinable trends and invariances.
Conservation of organizational stability (invariant work rate): rate in a programming project is statistically invariant.
Conservation of familiarity (perceived complexity): release content of the successive releases is statistically invariant.
![Page 11: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/11.jpg)
The Nature of Maintenance
• Corrective Maintenance: maintenance in respond to problems resulting from faults during day-to-day system usage.
• Adaptive Maintenance: a change introduced in one part of the system requires changes to other parts.
• Perfective Maintenance: make changes to improve some aspect of the system
• Preventive Maintenance: make change to prevent failures.
![Page 12: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/12.jpg)
Use of Maintenance Time
Perfective50%
Adaptive25%
Corrective21%
Pre
ven
tive 4
%
![Page 13: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/13.jpg)
Maintenance Problems
• How do we balance the need for change with the need for keeping a system accessible for users?
• Staff Problems• Technical Problems• The Need to Compromise• Maintenance Cost
![Page 14: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/14.jpg)
Staff Problems
• Limited Understanding: 47% of software maintenance effect is devoted to understanding the software to be modified.
• User’s Limited Understanding: provide incomplete and misleading data when reporting a problem
• Management Priorities: view maintaining and enhancing as more (or less?) important then building new applications
![Page 15: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/15.jpg)
Staff Problems: Morale
• 11.9% of the problems during maintenance result from low morale and productivity.
• During maintenance, 8% of the problems result from a programmer’s being pulled in too many directions at one, and thus being unable to concentrate on one problem long enough to solve it.
![Page 16: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/16.jpg)
Technical Problems
• Number one problem! The y2k problem, “year 2000 problem,” is a good example of where simple but narrow design decisions can have a major effect on maintenance.
• Maintaining object-oriented programs can be problematic: the design often involves components that are highly interconnected by complex inheritance schemes.
![Page 17: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/17.jpg)
More Technical Problems
• Inadequate design specifications and low-quality programs and document account for almost 10% of maintenance effort.
• Testing Difficulties: Testing the system in used can be a problem.Solution: tests are often run on duplicate system
![Page 18: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/18.jpg)
The Need to Compromise
• Programmer may be forced to compromise elegance and design principles because a change is needed immediately.
• The team is forced to concentrate is resources on a problem about which it may have little understanding.
![Page 19: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/19.jpg)
Maintenance Cost
• All the problems of maintaining a system contribute to the high cost of software maintenance.
• Maintenance costs may be up to 80% of a system’s lifetime costs.A series of repairs and enhancements usually leads to
fragmentation of system, poor document, ... -> more difficult and more effort needed for future maintenance.
Staff Specialization: leads to exponential increase in resources devoted to maintenance.
![Page 20: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/20.jpg)
Measuring Maintenance Characteristics
• External view of maintainability: records the following info for each problem the time at which the problem is reportedany time lost due to administrative delay the time required to analyze the problem the time required to specify which changes are to be
made the time needed to make the change the time needed to test the change the time needed to document the change
![Page 21: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/21.jpg)
Internal Attributes Affecting Maintainability
• the more complex the code, the more effort required to maintain it
• measuring how complex:• Cyclomatic Number is a metric that captures an
aspect of the structure complexity of source code by measuring the number of linearly independent paths through the code.
![Page 22: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/22.jpg)
Finding the Cyclomatic number
• = edges - nodes + 2• = number of separated segments in the graph• = number of decision statements in the code + 1• Cautions:
there are other attributes that contribute to complexity that are not captured by its structure
![Page 23: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/23.jpg)
Graphs for Cyclomatic number calculation
numdigit > 0?NO
YES
If numdigit = 0
n = 0?NO
YES
CONTROL FLOW GRAPH EQUIVALENT GRAPH
![Page 24: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/24.jpg)
Readability
• Text: ~= number of years of schooling needed for a person to read a passage with ease and understanding
• Fog Index = 0.4 * number of words / number of sentences + percentage of words of 3 or more syllables
• Software: Readability of source code = 0.295*(average normalized length of variables) - 0.499*(number of lines containing statements) + 0.13*(Cyclomatic number)
![Page 25: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/25.jpg)
Maintenance Techniques and Tools
• Configuration Management keeps track of changes and their effects on other system components.
• Impart analysis is the evaluation of the many risks associated with the change, including estimates of effects on resources, effect, and schedule.
![Page 26: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/26.jpg)
Software maintenance Activities
Manage softwaremaintenance
Analyze softwarechange impact
Understandsoftware under
change
Implementmaintenance
change
Account forripple effect
(Re)testaffected software
PreventiveAdaptiveCorrectivePerfective
NEWSYSTEM
Impact/scopeTraceability
roadmap
ComplexityModularityDocumentationSelf-descriptiveness
Adaptability StabilityConsistency
TestabilityVerifiabilityCompleteness
Existingsystem
ChangeRequest
![Page 27: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/27.jpg)
Workproducts and Traceability
• A workproduct is any development artifact whose change is significant.
• Vertical traceability expresses the relationship among the parts of the workproduct.
• Horizontal traceability addresses the relationships of the components across collections of workproducts.
![Page 28: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/28.jpg)
Horizontal traceability
Requirementsdocument
r1r2r2.2r3 . .
d1d2 . .
d1d2 . .
d1d2d3
Code m.1
Code m.2
Code m.3
Code m.4
Code m.5
Code m.6 Test t.11
Test t.12
Test t.10
Test t.1
Test t.2
Test t.3
Test t.4
Test t.5
Test t.6
Test t.7
Test t.8
Test t.9
Accep-tance test
n.2
...
...
...
...
...
...
...
...
...
...
...
...
Design componentsCode
components
Tests
![Page 29: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/29.jpg)
Underlying graph for maintenance
D2
D1
D3
D4
D5
D6
Dk
D7
D8...
R2
R1
R3
R4
R5
R6
Rj
.
.
C2
C1
C3
C4
C5
C6
Cm
C7
C8...
T2
T1
T3
T4
T5
T6
Tn
T7
T8...
Requirements Design Code Test
![Page 30: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/30.jpg)
Complexity as result of maintenance
• If the number of paths in the graph increase after the change,
• then the system is likely to be more unwieldy and difficult to maintain.
• If number edges go into the node (in-degrees) and number of edges go out the node (out-degrees) increase substantially,
• then the system may be harder to maintain in the future.
![Page 31: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/31.jpg)
Tools for Maintenance
• Text Editors• File Comparator• Compilers and Linkers• Debugging Tools• Cross-reference Generators• Static Code Analyzers• Configuration Management repositories
![Page 32: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/32.jpg)
Software Rejuvenation
• addresses maintenance challenge by trying to increase the overall quality of an existing system
• Redocument: analysis of the source code to provide more info to assist maintenance.
• Restructure: transforming ill-structured code into well-structured one.
![Page 33: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/33.jpg)
Reverse engineer
• Reverse engineer: recreating design and specification information from the code.
• Reengineering: reverse engineer then “forward engineer” to change the specification and design
![Page 34: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/34.jpg)
Taxonomy of software rejuvenation
SPECIFICATION
DESIGN
SOURCE CODE
ForwardEngineering• forwardprogressionthroughprocess
Restructuring• from code• internallyrepresent• iterativelysimplifystructure andeliminatedead code• regeneratecode
Redocumenting• from code• static analysisreports on structure,complexity,volume,data, etc.• not based on software methods
ReverseEngineering• from code• produces designand specificationbased on acceptedsoftware methods• managesrepresentation
Reengineering• from code• reverse-engineer code• forward-engineer:completeand modifyrepresentationregenerate code
![Page 35: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/35.jpg)
Redocumentation
Source code
Componentand variabletables
Cross-reference
Data interfacetables
Pseudocode
Data andcontrol flows
Componentcallinghierarchy
Programtree
Complexityand sizedata
Data usage
Ripple-effect
Test paths
Design TestsCode
Evalu
ate
d u
sin
g s
tati
c an
aly
sis
Leading to additional information about:
![Page 36: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/36.jpg)
RestructuringUnstructured code Structured code
Simplifyinternal
representation
Regeneratestructured
code
Internal representationof the code
![Page 37: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/37.jpg)
Source code
Static analysis Data dictionary
Processspecifications
Componentcallinghierarchy
Pseudocode
Entity-relationdiagrams
Data and controlflow diagrams
Data structurediagrams
Structure charts
Module andvariable tables
Cross-reference
Data interfacetables
Test paths
*NEW* information about, and updates to, all system artifacts
Reverse Engineering
![Page 38: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/38.jpg)
Reengineering
Unstructured code Structured code
Reverseengineer
Regeneratenew
system
STEP 1
Specification
Design
Update internalspecificationand design
STEP 2
STEP 3
![Page 39: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/39.jpg)
Concluding Remark: What this course means for you
• Software development processes• Large software projects• Team Work• Documentation and communication• Learn the terms of the trade• What to expect when you work in software
development co. ($$$) (???)
•“Live Long and Prosper”
![Page 40: CH11: Maintaining the System](https://reader035.vdocument.in/reader035/viewer/2022062301/56813115550346895d976629/html5/thumbnails/40.jpg)