Software Maintenance
1. Software Maintenance Definition
Very often in practice we use programs with poorly designed structures, poor coding, poor logic, and poor documentation.
Often we employ programs created using the best design and techniques at their time, when program size and storage space were principal components. They might have been migrated to new platforms, adjusted for changes in the machine and operating system technology- all without enough regard to the overall software system architecture.
Change is inevitable when computer-based systems are built. That is why, we need mechanisms for evaluating, controlling and making modifications.
Software maintenance includes four activities:
- corrective maintenance: consists of diagnosis and correction of one or more errors reported by the customer;
- adaptive maintenance: modifies software to properly interface with a changing environment;
- perfective maintenance: accounts for the effort to incorporate new capabilities and to make general enhancements;
- reverse engineering
2. Software Maintenance Characteristics
Structured vs. Unstructured Maintenance
Unstructured maintenance happens when there is no well-defined methodology. For example, when there is no good documentation, when there is no information about the tests performed etc..
Structure maintenance may be conducted only if the steps of the software engineering methodology, the waterfall cycle, are properly followed during the project development.
The existence of a proper software configuration does not guarantee problem-free maintenance, but at least guarantees reduction of wasted effort and increasing the quality of change.
Maintenance Cost
Effort expended on maintenance may be divided into productive activities, design modification and coding for example, and "wheel spinning" activities, trying to understand the code for example.
The following expression provides a model of maintenance effort:
M = p + Ke(c-d)
where:M is total effort expended in maintenance
p is productive effort
K is an empirical constant
c is complexity attributed to the lack of good design and documentation
d is a measure of the familiarity with the software
Problems
Among the many classic problems that can be associated with software maintenance are the following:
- difficulties to trace the software evolution
- difficulties to understand someone else’s program
- documentation does not exist or is awful
- most software is not designed for change
All of these problems can be at least partially solved if the disciplined software engineering methodology is followed.
3. Software Maintainability
Controlling Factors
- availability of qualified software staff
- understandable system structure
- ease of system handling
- use of standardized programming languages
- use of standardized operating systems
- standardized structure of the documentation
- availability of test cases
Quantitative Measures
- problem recognition time
- administrative delay time
- maintenance tools collection time
- change specification time
- local testing time
- global testing time
- maintenance review time
- total recovery time
4. Software Maintenance Tasks
4.1. Maintenance Organization
Maintenance requests are channeled through a maintenance controller, who forwards each request for evaluation to a system supervisor. The system supervisor is a member of the technical staff provides the information to a change control authority, called change control board.
4.2. Maintenance Reporting
The software developer normally generates a maintenance request form (MRF), sometimes called software problem report, that is completed by the user who desires a maintenance activity.
For adaptive or perfective maintenance requests a brief change specification, with abbreviate requirements definition, is also submitted.
The MRF is an externally generated document that is used as a basis for planning the maintenance task. Internally the software organization develops a software change report (SCR) that includes:
- the magnitude of effort required to satisfy an MRF
- the nature of modifications required
- the priority of the request
- data about the modification
4.3. Flow of Events
4.4. Record Keeping
There could be suggested the following list of data that worth recording
- program identification
- number of source statements
- number of machine code instructions
- programming language used
- program installation date
- number of program runs since installation
- number of processing failures associated with the runs
- source statements added by the program change
- source statements deleted by the program change
- number of person-hours spent per change
- program change date
- identification of software engineer
- MRF identification
- maintenance start and close dates
- cumulative number of person-hours spent on maintenance
- net benefits associated with the maintenance
5. Software Maintenance Side Effects
5.1 Coding Side Effects
Although every software code modification has the potential for introducing error, the following set of changes tends to be more error-prone than others:
- a subprogram is deleted or changed
- a statement label is deleted or changed
- an identifier is deleted or modified
- file open or close is modified
- logical operations are modified
- design changes are translated into major code changes
- changes are made to logical tests of boundary conditions
Data Side Effects
- redefinition of local and global constants
- redefinition of record or file formats
- increase or decrease the size of arrays
- modifications to global data
- reinitialization of control flags
- rearrangement of arguments for I/O