EC21_SW_Maintenance - Software Engineering II

Download Report

Transcript EC21_SW_Maintenance - Software Engineering II

University of Southern California
Center for Systems and Software Engineering
Software Maintenance
based on Software Engineering Body of Knowledge (SWEBOK)
CS 577b Software Engineering II
Supannika Koolmanojwong
March 10, 2011
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
Software Maintenance Fundamentals
Key Issues in Software Maintenance
Maintenance Process
Techniques for Maintenance
03/02/2011
© 2011 USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Definition
• IEEE standard [IEEE 1219-98:s3.1.12]:
– “the modification of a software product after
delivery to correct faults, to improve
performance or other attributes , or to adapt the
product to a modified environment.”
03/02/2011
© 2011 USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Nature of Maintenance
• Sustain the software product throughout its
operational life cycle
• Modification requests are logged and tracked
• Impact of the proposed changed is determined
• Code and artifacts are modified
• Testing is conducted
• New version of software product is released
• Need training and daily support
03/02/2011
© 2011 USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
03/02/2011
© 2011 USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
Why we need a software maintenance ?
•
•
•
•
•
Correct faults
Improve the design
Implement enhancements
Interface with other systems
Adapt programs so that different hardware,
software, system features, and
telecommunications facilities can be used
• Migrate legacy software
• Retire software
03/02/2011
© 2011 USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Maintainer’s activities
• Maintaining control over the software's day-today functions
• Maintaining control over software modification
• Perfecting existing functions
• Preventing software performance from
degrading to unacceptable levels
03/02/2011
© 2011 USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Cost of Software Maintenance
• Common perception
– software maintenance cost = fixes faults
• 80% - non-corrective actions
• BUT, many managers put enhancement and
correction together
03/02/2011
© 2011 USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
Factors influencing maintenance costs
•
•
•
•
•
•
Application type
Software novelty/uniqueness
Software maintenance staff availability
Software life span
Hardware characteristics
Quality of software design, construction,
documentation and testing
03/02/2011
© 2011 USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
Software Maintenance Categories
Correction
Enhancement
Proactive
Preventive
Perfective
Reactive
Corrective
Adaptive
•Corrective maintenance: Reactive modification of a software product
performed after delivery to correct discovered problems
•Adaptive maintenance: Modification of a software product performed
after delivery to keep a software product usable in a changed or
changing environment
•Perfective maintenance: Modification of a software product after
delivery to improve performance or maintainability
•Preventive maintenance: Modification of a software product after
delivery to detect and correct latent faults in the software product before
they become effective faults
03/02/2011
© 2011 USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
Software Maintenance Fundamentals
Key Issues in Software Maintenance
Maintenance Process
Techniques for Maintenance
03/02/2011
© 2011 USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
Key Issues in Software Maintenance
•
•
•
•
Technical issues
Management issues
Cost estimation
Measures
03/02/2011
© 2011 USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
1) Technical Issues
• Limited understanding
– 40% to 60% of the maintenance effort is devoted to
understanding the software to be modified
• Testing
– Full testing is costly
– Regression testing - retesting of a software or
component to verify that the modifications have not
caused unintended effects
– When to test (possible for offline testing?)
03/02/2011
© 2011 USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
1) Technical Issues
• Impact analysis
– analysis of the impact of a change in existing software
– identify all systems and software products, estimate of the
resources needed
– Change request; modification request (MR); problem report
(PR)
– Objectives of Impact Analysis
•
•
•
•
03/02/2011
Determine scope of change in order to plan and implement work
Develop estimates of resources needed to perform the work
Analyze cost/benefits of the requested change
Communicate to others of the complexity of a given change
© 2011 USC-CSSE
14
University of Southern California
Center for Systems and Software Engineering
1) Technical Issues
• Maintainability
– In order to save cost, determine maintainability
during development process, review it and control it
– Not emphasized during development process
– Mature process helps enhancing maintainability
03/02/2011
© 2011 USC-CSSE
15
University of Southern California
Center for Systems and Software Engineering
2. Management Issues
• Alignment with organizational objectives
– Usually contrast to org objectives: deliver on time,
limited budget
– Do not show a good number in ROI
– No clear quantifiable benefit for the organization
• Staffing
– Perceived as second-class citizens
– Morale therefore suffers
03/02/2011
© 2011 USC-CSSE
16
University of Southern California
Center for Systems and Software Engineering
2. Management Issues
• Process
– Similar to development process, but has unique activities
• Organizational aspects of maintenance
– Case-by-case policy in task delegation
– Dedicated maintainer or a special team
• Outsourcing
– Usually for less mission-critical systems
– Challenges
• Scope of maintenance and contractual details
• Transition to outsourcer
03/02/2011
© 2011 USC-CSSE
17
University of Southern California
Center for Systems and Software Engineering
3. Maintenance Cost Estimation
• Cost estimation
– Parametric model
• COCOMO for maintenance
– Experience
• Delphi study
03/02/2011
© 2011 USC-CSSE
18
University of Southern California
Center for Systems and Software Engineering
4. Software Maintenance Measurement
• Common categories
– size; effort; schedule; and quality
• Based on Maintainability characteristics
– Analyzability: Measures of the maintainer's effort or resources
expended in trying to diagnose deficiencies or causes of failure, or in
identifying parts to be modified
– Changeability: Measures of the maintainer's effort associated with
implementing a specified modification
– Stability: Measures of the unexpected behavior of software,
including that encountered during testing
– Testability: Measures of the maintainer's and users' effort in trying to
test the modified software
03/02/2011
© 2011 USC-CSSE
19
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
Software Maintenance Fundamentals
Key Issues in Software Maintenance
Maintenance Process
Techniques for Maintenance
03/02/2011
© 2011 USC-CSSE
20
University of Southern California
Center for Systems and Software Engineering
The Incremental Commitment Spiral Model
Jan 11, 2011
21
University of Southern California
Center for Systems and Software Engineering
Software Maintenance Process
• Post-delivery stage
The IEEE1219-98 Maintenance Process Activities
03/02/2011
© 2011 USC-CSSE
22
University of Southern California
Center for Systems and Software Engineering
Another Software Maintenance Process
ISO/IEC 14764-00
Software Maintenance
Process
03/02/2011
© 2011 USC-CSSE
23
University of Southern California
Center for Systems and Software Engineering
Maintenance Activities
• Unique Activity
– Transition: a controlled and coordinated sequence of activities during which
software is transferred progressively from the developer to the maintainer
– Modification Request Acceptance/Rejection: modification request work
over a certain size/effort/complexity may be rejected by maintainers and
rerouted to a developer
– Modification Request and Problem Report Help Desk: an end-user support
function that triggers the assessment, prioritization, and costing of
modification requests
– Impact Analysis
– Software Support: help and advice to users concerning a request for
information (for example, business rules, validation, data meaning and ad-hoc
requests/reports)
– Service Level Agreements (SLAs) and specialized (domain-specific)
maintenance contracts which are the responsibility of the maintainers
• Supporting Activity
• Maintenance planning activity
03/02/2011
© 2011 USC-CSSE
24
University of Southern California
Center for Systems and Software Engineering
Maintenance Activities
• Unique Activity
• Supporting Activity
–
–
–
–
–
software maintenance planning
software configuration management,
verification and validation,
software quality assurance, reviews, audits
user training and maintainer training
• Maintenance planning activity
03/02/2011
© 2011 USC-CSSE
25
University of Southern California
Center for Systems and Software Engineering
Maintenance Activities
• Unique Activity
• Supporting Activity
• Maintenance planning activity
–
–
–
–
03/02/2011
Business planning (organizational level)
Maintenance planning (transition level)
Release/version planning (software level)
Individual software change request planning
(request level)
© 2011 USC-CSSE
26
University of Southern California
Center for Systems and Software Engineering
Release/version planning activity
• Collect the dates of availability of individual requests
• Agree with users on the content of subsequent
releases/versions
• Identify potential conflicts and develop alternatives
• Assess the risk of a given release and develop a backout plan in case problems should arise
• Inform all the stakeholders
03/02/2011
© 2011 USC-CSSE
27
University of Southern California
Center for Systems and Software Engineering
Software configuration management
• Critical element of the maintenance process
• For
– verification, validation,
– audit of each step required to identify, authorize,
implement, and release the software product.
• Track Modification Requests or Problem
Reports
• Control the changes
• Different from CM of software development
03/02/2011
© 2011 USC-CSSE
28
University of Southern California
Center for Systems and Software Engineering
Outline
•
•
•
•
Software Maintenance Fundamentals
Key Issues in Software Maintenance
Maintenance Process
Techniques for Maintenance
03/02/2011
© 2011 USC-CSSE
29
University of Southern California
Center for Systems and Software Engineering
Techniques for Maintenance
• Program Comprehension
– reading and understanding programs in
order to implement changes.
– Code browsers are key tools for program
comprehension.
– Need clear and concise documentation
03/02/2011
© 2011 USC-CSSE
30
University of Southern California
Center for Systems and Software Engineering
Techniques for Maintenance
• Reengineering
– examination and alteration of software to
reconstitute it in a new form, and includes the
subsequent implementation of the new form
– the most radical (and expensive) form of alteration
– It is often not undertaken to improve maintainability,
but to replace aging legacy software
03/02/2011
© 2011 USC-CSSE
31
University of Southern California
Center for Systems and Software Engineering
Techniques for Maintenance
• Reverse engineering
– Analyzing software to identify the software's components and
their interrelationships and to create representations of the
software in another form or at higher levels of abstraction
– Reverse engineering is passive;
– it does not change the software, or result in new software
– E.g. redocumentation, design recovery, refactoring (to improve
performance), data reverse engineering (logical schemas are
recovered from physical databases)
03/02/2011
© 2011 USC-CSSE
32
University of Southern California
Center for Systems and Software Engineering
Distribution of Maintenance Problem Items
03/02/2011
© 2011 USC-CSSE
33
University of Southern California
Center for Systems and Software Engineering
03/02/2011
© 2011 USC-CSSE
34
University of Southern California
Center for Systems and Software Engineering
References
•
•
[Lientz 1981] Lientz, B.P. & Swanson, E. (1981). "Problems in application
software maintenance". Communications of the ACM 24 (11), 763-769.
[SWEBOK 2004] Software Engineering Body of Knowledge version 2004
http://www.computer.org/portal/web/swebok
03/02/2011
© 2011 USC-CSSE
35