Software maintenance

Since maintenance is the most expensive phase of the software life cycle, detecting most of the errors as early as possible in the software development effort can provide substantial savings. This study investigates the behavior of complexity metrics during testing and maintenance, and their relationship to modifications made to the software. Interface complexity causes most of the change activities during integration testing and maintenance, while size causes most of the changes during unit testing. Principal component analysis groups 16 complexity metrics into four domains. Changes in domain pattern are observed throughout the software life cycle. Using those domains as input, regression analysis shows that software complexity measures collected as early as the unit testing phase can identify and predict change prone modules. With a low rate of misclassification, discriminant analysis further confirms that complexity metrics provide a strong indication of the changes made to a module during testing and maintenance.

As the Series/1 is used in more complex, unattended, or critical applications,
users of the product cannot tolerate the mean time to repair of the
current field service support. Long waits for technicians to arrive,
troubleshoot the system, and repair or replace parts are no longer acceptable.
This thesis presents the system architecture and functional capabilities
of a maintenance processor for the Series/1. The maintenance
processor designed herein can be used as the focal point of most system
support activities. This approach has been used in mainframe systems for
some time but has not, in the past, been deemed feasible for smaller systerns
such as the Series/1. This effort demonstrates the feasibility of a
maintenance processor in such systems, resulting in a simplification of
hardware and software while providing a significant improvement in total
system reliability, availability, and serviceability.

Legacy software systems may go through many releases. It is important to ensure that the reliability of a system improves with subsequent releases. Methods are needed to identify decaying software modules, i.e., modules for which quality decreases with each system release. Early identification of such modules during the software life cycle allows us to focus quality improvement efforts in a more productive manner, by reducing resources wasted for testing and improving the entire system. We present a scheme to classify modules in three groups---Decayed, Improved, and Unchanged---based on a three-group software quality classification method. This scheme is applied to three different case studies, using a case-based reasoning three-group classification model. The model identifies decayed modules, and is validated over different releases. The main goal of this work is to focus on the evolution of program modules of a legacy software system to identify modules that are difficult to maintain and may need to be reengineered.