are here: Freetutes.com
Analysis and Design
It is impossible to produce systems of any size, which do not need to be changed.
Over the lifetime of a system, its original requirements will be modified to reflect
changing user and customer needs. The system's environment will change as new
hardware is introduced. Error, undiscovered during system validaton, may merge
and require repair.
The process of changing of a system after it has been
delivered and is in use is called Software maintenance. The changes may involve
simple changes to correct coding errors, more extensive changes to correct design
errors or significant enhancement to correct specification errors or accomodate
new requirements. Maintenance therefore, in this context, really means evolution.
It is the process of changing a system to maintain its ability to survive.
There are three types of software maintenance with very blurred distinction
- Corrective maintenance
- Adaptive maintenance
- Perfective maintenance
Follwing figure illustrates the maintenance effort distributionin software
Maintenance Effort Distribution
Corrective Maintenance is concerned with fixing reported errors in the software.
Coding errors are usually relatively cheap to correct; design errors are more
expensive as they may involves the rewriting of several programs components. Requirements
errors are the most expensive to repair because of the extensive system redesign
with may be necessary.
Adaptive maintenance means changing the software to new environment such as
different hardware platform or for use with a different operating systems. The
software functionality does not radically change.
Perfective maintenance involves implementing ne wfunctional or non-functional
system requirements. These are generated by software customers as their organization
are business changes.
It is difficult to find up-to-date figures for their relative effort devoted
to these different types of maintenance. A survey by Lientz and Swanson (1980)
discovered that about 65% of maintenance was perfective, 18% adaptive and 17%
corrective shown in figure. And also Lientz and Swanson found that large organizations
devoted at least 50% of their total programming effort for maintaining existing
systems. The costs of adding functionality to a system after it has been put into
operation are usually much greater than providing similar functionality when software
is originally developed. There are a number of reasons for this:
Maintenance staffs are often relatively inexperienced and unfamiliar with the
applications domain. Maintenance has a poor image among software engineers. It
is seen as a less skilled process than system development and is often allocated
to the most junior staff.
The program being maintained may have been developed many years ago without
modern software engineering techniques. Thay may be unstructured and optimized
for efficiency rather than understandability.
Changes made to a program may introduce new faults, which trigger further change
requests. New faults may be introduced because the complexity of the system may
make it difficult to access the effects of a change.
As a system is changed, its structure tends to degrade. This makes the system
harder to understand and makes further changes difficult as the program becomes
The links between a program and its associated documentation are sometimes
lost during the maintenance process. The documentation may therefore be an unreliable
aid to program understanding.
The first of these problems can only be tackled by organization adapting enlightened
maintenance management policies. management must demonstrate to engineer that
maintenance is of equal value and is as challenging as original software development.
The best designers and programmers should be challenged and motivated by system
maintenance. Boehm (1983) suggested several steps that can improve maintenance
Couple software objectives to organizational goals.
Couple software maintenance rewards to organizational performance
Integrate software maintenance personnel into operational teams.
Create a discretionary, preventive maintenance budget, which allows the maintenance
team to decide when to re-engineer parts of the software. Preventive maintenance
means making changes to the software, which improve its structure so that future
maintenance is simplified.
Involve maintenance staff early in the software process during standard preparation,
reviews and test preparation.
The second of the above problems, namely unstructured code, can be tackled
using re-engineering and design recovery tecniques.
The other maintenance problems are process problems. Structure naturally degrades
with changes. Organizations must plan to invest extra effort and resources in
preventive maintenance with the aim of maintaining the structure. Good software
engineerign practice such as the use of information hiding or object-oriented
development helps minimize the structure degradation but effort for structure
maintenance is still required.
Previous Page | Contents
| Back to System Analysis