Legacy software series — Part 2— Software life cycles and software aging
In this article I’m covering the traditional life cycle stages of a typical software system. Additionally, I’m describing what is software aging and what causes it.
Software life cycles
1. Initial development
During the initial development, the first versions of the software are planned and developed. Often these are proof of concept type versions, which are used justify further development.
After the initial development phase, the evolution of the software product takes place. In this phase, the abilities and functionalities of the software product are shaped to meet customer needs. This phase may include major upgrades to the software.
3. Servicing and maintenance
When the product has taken shape and only requires minor changes and tweaks, it enters the servicing phase of its life cycle. In servicing phase, no major upgrades are applied, only minor changes and bug fixes.
4. Phasing out
In the phaseout stage, maintaining the software product is no longer cost effective. Fixes are only applied to assure core functionality. The company is essentially waiting for the last users to migrate to new software products.
Finally, the software product is retired and removed from use all together. It will be replaced or removed completely from the market.
These stages were defined by Vaclac et al. (2000).
In theory, software is composed of logical operations based on math, and math does not change, so software should not age. However, the opposite is true, and software does in fact age. This is caused by the changes in the world around the software. The world is constantly shifting and changing, which demands the software to change with it or be obsolete. To be precise, it is not the physical software that is aging. It is the purpose of the software that changes, and to account for that the software needs to change too (Parnas, 1994).
Causes for aging
There are two main causes for software aging. Firstly, developers fail to implement changes to the software. If the software is not frequently updated to match the needs of the customers, the customers will become dissatisfied and start looking for alternative solutions. In theory, a software from 1950s could be used today, but no customer would be satisfied by its performance or features. Secondly, the changes are successfully implemented to the software, but these changes are done by developers who do not understand the original design of the software. This will cause the structure of the software to degrade. If the changes are inconsistent with the original design, the resulting software will have two possibly colliding designs implemented on it. The next developer trying to make changes must now understand the original design and the design of the changes. This addition of complexity to a software can go on for the whole life cycle of the software, accumulating complexity and decreasing maintainability. The problem is aggravated by lack of documentation or incorrect documentation (Parnas, 1994).
Parnas, D. (1994). Software Aging. IEEE. Retrieved from https://www.cs.drexel.edu/~yfcai/CS451/RequiredReadings/SoftwareAging.pdf
Vaclac T. Rajlich, K. H. (2000). A Staged Model for the Software Life Cycle. IEEE Computer. doi:10.1109/2.869374