chapter 3: software maintenance process omar meqdadi se 3860 lecture 3 department of computer...
TRANSCRIPT
Chapter 3: Software Maintenance
Process
Omar MeqdadiSE 3860 Lecture 3
Department of Computer Science and Software Engineering University of Wisconsin-Platteville
2
Topic Covered
Maintenance Types Maintenance Prediction Maintenance Process
3
Maintenance Types
Corrective Maintenance: correcting errors and bugs Adaptive Maintenance: adapting to changes in the
environment (both hardware and software) Example: Porting KDE system from Qt3 to Qt4
Perfective Maintenance: adapting to changing user requirements Example: performance improvements, new requirements
Preventive Maintenance: increasing the system’s maintainability Example: Re-Engineering , Refactoring , and updating
documentation
4
Maintenance Types
5
Distribution of Maintenance Types(Lientz and Swanson)
corrective 21%
adaptive 25%
preventive 4%
perfective 50%
Maintenance Prediction
Maintenance prediction is concerned with assessing which parts of the system may cause problems and have high maintenance costs Change acceptance depends on the maintainability of the
components affected by the change Implementing changes degrades the system and reduces its
maintainability Maintenance costs depend on the number of changes and
costs of change depend on maintainability
Maintenance Prediction
Change Prediction
Change Prediction The number of required changes Understanding of the relationships between a system and
its environment Tightly coupled systems require changes whenever the
environment is changed Factors influencing this relationship are
Number and complexity of system interfaces Number of inherently volatile system requirements The business processes where the system is used
9
Maintenance Process
Request for change Planning phase Software comprehension Impact analysis Implementation of the change Focus of the change Change propagation Verification Documentation
Maintenance Process
Change Requests
Change requests are requests for system changes from users, customers or management
In principle, all change requests should be carefully analysed as part of the maintenance process and then implemented
In practice, some change requests must be implemented urgently Fault repair Changes to the system’s environment Urgently required business changes
Change Request Management
Change Management to uniquely identify, describe and track the status of each requested change
Change requests and their status are recorded and tracked in a Change Management Tracking System Manage the system release Analysis of the types and frequency of defects Communicate to maintainers, managers and clients
Project Management and the Quality Assurance team receive information about the status of the Change Requests
More details in Chapter 4
Impact of Change
Evaluate Change Requests Identify all systems/system components affected by a
change request Evaluation of many risks associated with the change Complexity of the change
Estimate Resources develops an estimate of the
Resources needed to accomplish the change Time and schedule Cost and efforts
Measuring Impact of Change
To measure the impact of a change, you need: Program (Software ) Comprehension Size of required changes
LOC Number of functions, routine , and classes that will be
touched
Historical information Productivity Rate, Average LOC per Routine
Time required to complete the system changes
Measuring Impact of Change
Types of System Changes Types of Change Impacts
Requirements changes Affect design, coding, and testingDocument update
Design changes Affect coding and testsAffect associated components Affect system architectureAffect related component interactions
Implementation changes Affect test cases, test data, test scriptsAffect test specification.Code change impact s
- Test changes Affect other tests.
Affect test documentation
Document changes Affect other documents.
Measuring Impact of Change
Program Comprehension (Covered in Chapters 8,9, &10) The words "understanding" and "comprehension" are used as
synonyms 50-90% of the maintenance time is spent in comprehension
Fjelstad-Hamlen found that programmers: studied the program 3.5 times longer than the documents Spent more time in comprehension than in implementing
enhancements
Comprehension is affected by Comprehensibility of the program Skills of the maintainer Information needs and sources
Measuring Impact of Change
Methodologies: Work product: any development artifact whose change is
significant Horizontal traceability: relationships of components across
collections of work products Vertical traceability: relationships among parts of a work
product More details in Chapters: 8,9, & 10
Measuring Impact of Change
Example: Horizontal Traceability
Change Implementation
Change Implementation
Example: Corrective Maintenance includes all repairs of defects in an existing system
Locateerror
Designerror repair
Repairerror
Re-testprogram
Testresults Specification Test
cases
Change Implementation
Example: Corrective Maintenance Defects types:
Requirements specification errors Design errors Coding errors
Facts: 80% of all problems stem from requirements and design Repairing a defect has a 20-50% change of introducing
another defect Person who makes the repair is not generally the person who
wrote the code
Change Implementation
Example: Preventive Maintenance Polish or refine the quality of the software or the
documentation Re-engineering ( Chapters 6 & 7)
Rewriting and upgrading documentation Restructuring poorly written code
Fact Preventive maintenance reduces the system future
maintenance costs
Change Implementation
Example: Adaptive Maintenance Modify software to adapt to changes in the hardware or
software environment Real Examples:
Porting the KDE (K Desktop Environment) system from Qt3 to support Qt4
Modifying ABB industrial systems to deal with changes in the VxWorks and Microsoft Visual Studio (2003 to 2005)
Change Implementation
Example: Adaptive Maintenance
Change Testing
Only modified components need to be reviewed Develop new test cases that exercise the changes Existing and new test cases are required to test the
changes Test results are compared against previous test results
(Regression Testing) More details in Chapters 11 & 12
System Release
Deliver the system to the user System release includes:
Documentation Source code Hardware Training materials Backup procedures
System Release Planning
Determine the contents of a system release (incremental approach)
Establish the schedule of system releases Communicates between maintainers and users Plan hardware, operational procedures and backup
procedures More details in Chapter 4