1. Michael J. Salé, Seidenberg School of CSIS, Westchester DPS 2016
A Case Study on Improving Quality During Legacy Software Maintenance Using a Heuristic
Michael J. Salé, Seidenberg School of CSIS, Westchester DPS 2016

2. Introduction
Many organizations depend on the functionality of mission-critical legacy software and the continued maintenance this software is vital.
There are numerous reasons to maintain legacy software and not reengineer [1] [3].
Developers frequently perform maintenance to legacy systems without any formal plan [4].
This type of legacy software maintenance is problematic and often results in a reduction of software quality also known as software entropy [2].

3. Definitions
Legacy is defined as code without automated tests and lack external or in-line documentation. The environment is that where the developer is unable to discuss the system with its original developers. Some domain knowledge may exist.
A system is of high quality when it meets both functional and non-functional specification.
A functional requirement is met when a system function accomplishes what is set out to accomplish, where a function is a set of inputs, behavior, and the outputs.
Can be tested with test cases. In our case study, involves a product owner accepting a story.
Non-functional requirements are broken down into product requirements, organizational requirements, and external requirements [5] [6].

4. Quality Measures for this Case Study
The customer or product owner has accepted the user story and the functional requirement has been met.
The modification was made with adequate testing. Adequate testing is characterized as tests that show ample coverage (at the code, feature, and use-case levels). – three levels of testing
The modification was made to maximize structural design simplicity and maintain or improve conceptual integrity of the code. This is measured through:
low levels of coupling and high levels of cohesion,
reduction or elimination of code smells (more specifically duplicate code, lazy classes, dead code, speculative generality (or gold plating), and others.
avoiding “bolt-on” code changes.
The modification was made to maintain or improve understandability. This is measured through:
writing self-explaining code and providing documentation or commenting only where needed,
having well-named variables, methods, and classes,
taking refactoring opportunities where needed to improve code readability.

5. Research Summary
This research contributes to the corpus of legacy software maintenance research by: presenting a novel, practical, legacy software maintenance heuristic; and evaluating the heuristic through a case study.
The case study shows that an experimental group of developers using the heuristic improved software quality for a set of legacy software maintenance tasks compared to a control group of developers.
The case study also shows that the heuristic is practical and can be used to complete maintenance tasks in a similar amount of time to teams not using the heuristic.

6. Conceptual Integrity
Fred Brooks one of the founding fathers of software as a discipline, first mentioned Conceptual Integrity. He said: I will contend that Conceptual Integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.
Brook's spent a lot his time in the 1960's thinking and writing about the problem of getting development teams to have in their collective minds the same vision for the project.
Software engineers are not known for their communication skills and this simple fact hampers the communication of vision. Many of us seem to think having a vision in our heads is communication enough.
Software engineers tend to have strong opinions about how problems are best solved. They can be amazingly stubborn about those ideas, even when they conflict with the adopted vision. This threatens conceptual integrity.
Time threatens conceptual integrity. As people come and go and needs change, loss of vision seems inevitable. Features get bolted on to attract new customers or to stave off obsolescence [11].

7. Heuristic Phases
Learning phase: over the shoulder pair code review, feature use, stepping through characterization tests [7]
Assessment phase: code smell detection using tools, using IDE to determine effect analysis – this will determine test coverage depth
Testing phase I: write characterization tests and ensure
Coding phase: CLEAN coding practices
Testing phase II: UATs, Selenium tests, test cases for related functionality

8. Case Study Description
Took place in an undergraduate computer science capstone course
Two groups of participants
Experimental group using the heuristic (Team A)
Control group uses ad-hoc testing/debugging (Team B)
Identical maintenance tasks
Maintenance tasks impact several areas of the code
Inspection of the code post-maintenance task to identify defects introduced by each group
Limitations:
Higher education setting (somewhat artificial – grades versus job security), small development groups, designed around object oriented lang., team A was compensated per IRB.

10. Observations and Results
Team A had appreciably better understanding of the structure of the system.
A benefit of this is that they were able to maintain better conceptual integrity and made better design choices. – Increased code quality by definition.
Team B took what they know about the system early on in the case study and used this over and over again. Every new feature was “bolted on” using current knowledge without learning more. “Risk avoidance was our method.”
Risk avoidance and lack of further learning of the system led to decreased code quality, mostly as non-functional requirements.
Two major incidents of software entropy.

11. References