expand this
figure
Maintenance is the single most costly phase of the software product life cycle.
Estimates run from 20% to 75% of total cost, mostly toward the top of this range.
Maintenance is the ``software iceberg'',
except that it grows rather than melts.
Maintenance seems especially difficult.
Productivity reduction by a factor of 40 has been reported!
- Boehm, 1979
When the life-cycle steps are applied to an existing program, this is called maintenance.
However, there is often ambiguity about when a change in requirements initiates a new product life-cycle rather than merely maintenance.
* Corrective < 25%
fix errors
* Adaptive < 25%
respond to
changes in systems environment - operating system, utility software, other
applications, etc.
* Preventative e
improve future
maintainability & reliability
"""technology retirement"""
* Supplementative > 50%
enhance,
respond to requirements changes
often called ``perfective''
Maintenance should
* be requirements- and design-driven, just like the original development process
* follow similar life-cycle
* apply similar process controls
Problem of side effects especially severe in maintenance activities.
Side effects may impact:
* code execution (traditional side effect)
* code structure
* system architecture
* data representation
* data values
* process
* documentation
Environmental concerns especially important
Evaluate:
* request itself
* staff carryover
* material carryforward
* quality of preceeding process
* characteristics of developed products
* corrective
(error)
* is error frequent?
* is error costly?
* is error isolated?
* adaptive
(environment change)
* is change within organization?
* is change localized?
* supplementative/preventative
(enhancement)
* is change mandatory
* is enhancement well-defined?
* does enhancement provide significant return?
* As in all software projects, availability of qualified staff is the dominant factor
* Presence of members of the original design team helps immensely
* knowledge of product
* knowledge of domain
* knowledge of process
configuration and integration
tricks testing, verification & validation
source code
* without question
testing materials
* test plans
! test cases
regression testing
design documents
* essential, although we might pretend otherwise
requirements analysis & specification
o provides coherence
* generate test cases if missing
* understandability of system design
* standardization of programming tools
* standardization of documentation
«Design documentation that doesn't accurately reflect the current state of software is probably worse than no documentation at all.»
- Pressman, 1992
* The most important factor for easy maintenance is a maintainable product
* Cannot begin a structured software process starting with an unstructured system
* One measure estimates maintenance effort increases exponentially in """complexity attributed to poor design and documentation."""
=> design
Process should be design-based
* Terrible!
* Unwise - avoid if at all possible
* Recommended
Main goal is design recovery, but the recovered information is often at too low a level of abstraction.
Useful for
* recovering and comparing file organizations
* program (code) restructuring
Useful as programmer's aide on a large project.
1. Study program before entering """emergency mode."""
2. Become familiar with overall structure, avoiding details.
3. Evaluate existing documentation; diagram and comment if needed.
4. Make good use of cross references and other aids.
5. Make changes with utmost caution.
6. Don't eliminate code unless your sure it isn't used.
7. Declare your own variables rather than reusing.
8. Keep detailed records of activities and results.
9. Temper the urge to throw program away and rewrite it.
10. Insert error checking & diagnostics.
- Yourdan, 1975
1. a subprogram is deleted or changed
2. a statement label is deleted or modified
3. an identifier is deleted or modified
4. changes are made to improve execution performance
5. a file open or close is modified
6. logical operators are modified
7. design changes are translated into major code changes
8. changes are made to logical tests of boundary conditions
- Freedman & Weinberg, 1990
Continuing change - program must change or become less useful
Increasing complexity - structure of evolving program becomes more complex unless active efforts are made
Large program evolution - program evolution is a self-regulating process with statistically significant [local] trends and invariances
Organizational stability - over the lifetime of a program, rate of [change] is approximately constant independent of resources
Conservation of familiarity - incremental system change approximately constant from release to release
- Lehman & Belady, 1985
Maintenance causes most severe political stresses because it:
* is urgent
* has unanticipated resource requirements
* needs unanticipated managerial attention
expand this
figure
expand this
figure