Software development is characterised by technology and methods advancing at a high cadence. At the same time, however, systems with long life cycles are still being developed using earlier technologies and methods.
The software can be in use for many years or even decades. During this period, it must be maintained. This results in various challenges. Software maintenance means a continuous effort during the whole life cycle. Often software under long-term maintenance is no longer a strategic product, although still widely used.
Software Life Cycle
Software is a product on its own, an embedded product element, or part of a system as a system component. Different versions of software may be in use at the same time.
Every piece of software has its life cycle. After being developed (analysis, design, implementation, testing), it is released to the market, monitored, and typically updated several times, and eventually, it will be decommissioned (end of life). Application Life cycle Management (ALM) and Software Development Life Cycle (SDLC) processes support the creation and maintenance of high-quality software.
If the software is an integral part of a system or product, its life cycle is directly linked to the system or product life cycle. A life cycle plan provides high-level information about the manufacturing period, the distribution or sales period, the support or maintenance period and the planned end of life of the different product or system versions. Product life cycles can also be extended compared to previous planning.
In general, the willingness to invest in software maintenance decreases with the proximity to the planned end of life.
Tip #1: Life Cycle Plan Request or create a system or product life cycle plan. Typically, the information comes from business stakeholders, e.g. from product managers. Make sure that the plan is regularly updated. A life cycle plan is an essential input for software maintenance planning.
Software Retirement
An essential aspect of life cycle planning is the retirement of software versions. The more software versions that need to be supported and maintained simultaneously, the more complex and costly it becomes. Ideally, there is only one software version to keep. However, this may not always be an option.
Software retirement must already be taken into account during development. For example, the software can be configurable instead of generating multiple “parallel” versions. Or new software versions are made backwards compatible with existing hardware. Conversely, hardware changes can also be made without affecting the current software versions.
New software versions may be declared mandatory so that earlier versions can be removed from the market. This strategy works best when the customer is offered added value such as new features, bug fixes or performance improvements.
Tip #2: Reduced Number of Software Versions Minimise the number of software versions to be maintained. It significantly reduces complexity and costs.
Legacy Software/System
The term legacy software is often used in software with a long life cycle. If you search for definitions for legacy software, you may find the following: “difficult-to-change code that we don’t understand”, “code that is not tested”, “code that is not documented”, “outdated technology” or similar. While the situation might reflect reality, it is not generally true, specifically not for software with a long life cycle.
Almost any software is complex. Maintaining software is demanding enough, even with extensive documentation and testing availability.
Tip #3: Term “Legacy Software/System” Be careful when using the term legacy software or legacy system. It can be understood in different ways and thus be misleading. Don’t use the term carelessly if you mean software or a system with a long life cycle.
Software Maintenance
As long as a piece of software has not reached its end of life, it is not “finished”. It may contain known and unknown bugs, desired features may be missing, documentation gaps may be detected, the operating environment may change, security vulnerabilities in included libraries may be detected and more. Accordingly, we have to take care of it. This is called software maintenance. See also the section “Triggers for a Software Release” below.
There are various definitions or understandings of software maintenance like “all activities to optimise your software product”, “adding new functions and fixing bugs to enhance the user experience” or “modifying software after launch to correct bugs, improve performance or adapt it to a changing environment”.
When we speak of software maintenance, we talk about software changes compared to the delivered product. There are four categories of change:
Corrective Change: This means fixing bugs and flaws in the software. This category first comes to mind when talking about software maintenance. Bugs and weaknesses are typically reported by users or discovered during development by testers or software developers.
Adaptive Change: Software runs within a particular environment. This environment may change. Adaptive change is meant as adaptation to a changing environment. Examples include modified hardware, cybersecurity threats, operating system updates or new regulatory or legal requirements.
Perfective Change: This category is used to describe changes in the software in the direction of “perfection”. More specifically, it is about extending existing functionality, implementing new features or removing functions that are no longer used.
Preventive Change: Preventive changes are measures to improve the maintainability of the software. Such actions slow down the deterioration of the software. Examples of preventive changes are migration to new technology, refactoring, optimisations, updating included libraries or automation of software development process steps.
Changes always pose risks, regardless of the categories of changes. Both maintenance project risks and product risks must be taken into account. Product risks play an essential role in, e.g. medical device software as patient and user safety is crucial. Another essential aspect to consider is usability.
Also, remember that customers may not want or be able to update the software frequently. Software updates can mean customer visits, training or even laboratory recertification. In this respect, many software solutions cannot be compared to smartphone applications, where we are used to frequent updates.
A software maintenance plan describes the maintenance approach with the following possible content:
- Scope
- Maintenance Team (Roles and Responsibilities)
- Maintainability Assessment
- Software Transition (Handover to Maintenance Team)
- Knowledge Building and Retention
- Dealing with Change Categories
- Off-the-Shelf Software Strategy
- Cybersecurity Threats
- Software Release Strategy (Roadmap)
- Life Cycle and Software Retirement Strategy
- Risks
- Budget
To summarise, it describes your understanding of software maintenance for your software product.
Tip #4: Software Maintenance Plan Create a software maintenance plan during the software development project. It is the basis for the subsequent software maintenance phase(s).
Software Maintenance Team
A dedicated team performs software maintenance. It can be the existing development team, a completely new team (internal or outsourced) or a mixture of both. A good mix of team members – experienced and less experienced, different age categories, experts and beginners – is promising.
The software maintenance team must be carefully formed. In addition to having technical skills, team members must bring social skills, strong motivation and medium- to long-term commitment. Lack of motivation or commitment can negatively impact software maintenance and, ultimately, software quality.
Maintenance team members’ requirements differ from those of members for a new project with state-of-the-art technologies and methods. Finding the right people for outdated or niche technologies can take time and effort. However, keep in mind that technologies can be learned. A software engineer with a strong affinity for the latest technologies and a desire for frequent change might not fit in with a software maintenance team.
“Software maintenance requires people with average skills.” I heard this from a software department manager some years ago. I can’t really agree with that. On the contrary, I am convinced that, regarding the level of skills, there is no difference between working on developing a new product and maintaining an existing one. For example, failure analysis and refactoring on a current product can be very complex and requires highly skilled people.
Tip #5: Software Maintenance Team Members Document the required team member skills. Don’t reduce the requirements because it’s software maintenance. Emphasise motivation and commitment, not just technology, when looking for team members. Motivation and commitment are crucial for long-term software maintenance.
Knowledge Transfer and Retention
Software maintenance requires a high level of knowledge about the software and the system, including domain knowledge. When knowledge needs to be handed over to a new team, it should be done in a planned and well-structured manner. Quality-relevant training must be completed according to the applicable quality management system as a basis for software maintenance activities.
The new team should attend if your organisation offers users the system or product training. It helps in understanding the system from a user perspective.
In addition, it is beneficial to document the knowledge as comprehensibly as possible. The official development, product and training documentation is necessary, but more is needed for software maintenance.
Handing over the software maintenance to a new team poses the risk of the current team becoming demotivated. Appropriate measures to motivate the current team members have to be considered.
However, remember that knowledge can only partially be handed over or documented. Consequently, an initial knowledge transfer is the first step in building knowledge.
Tip #6: Knowledge Transfer Plan/Report Create a detailed knowledge transfer plan for the ramp-up if software maintenance is handed over to a new team (internal or outsourced). It should include topics, knowledge items, sources (current team members) and knowledge receivers (new team members). Use the plan to track progress and report completion. Also consider a reduced ramp-up plan for future new team members.
Tip #7: Knowledge Base Create a knowledge base (e.g. a software maintenance wiki) and keep it up to date. If a knowledge transfer is made, it is recommended that the new team updates the knowledge database during this process.
Software and Environment Updates
No software or system can be kept stable in the long run. Changes within the life cycle are necessary. There are various possible triggers for creating a new software release:
- Customer or business needs (new or changed requirements)
- Safety or business-critical bugs (“pain points”)
- Hardware changes due to discontinuations, with an impact on software
- New regulatory or legal requirements
- Cybersecurity demands or vulnerabilities
- Insufficient maintainability
- Outdated and out-of-support off-the-shelf software
- Outdated and out-of-support development environment
- Outdated and out-of-support runtime environment
- Development or runtime licence issues
In addition, these are the following potential benefits of keeping the off-the-shelf software, the development environment and the runtime environment up to date as well:
- Increased software and environment stability, fewer bugs and vulnerabilities
- Compliance with standards (e.g. IEC 62304)
- Adherence to guidelines (e.g. cybersecurity)
- Ensured manufacturer support
- Technical community support
- Fewer technical dependencies
- Easier communication with authorities and customers
- Increased software developer market value
- More success in recruiting software developers
- In general, more preparedness for all kinds of changes
Tip #8: Technical Debts Update your software, including off-the-shelf software and your development environment, regularly. Thus, you prevent the accumulation of technical debts that make software maintenance more difficult. If you do nothing or take care of “emergency updates” only, it will catch up with you sooner or later.
Conclusion
Long-term software maintenance is challenging. Many aspects have to be considered. It depends on the industry, market situation, regulatory requirements and business goals. There are many ways to maintain software. The challenges might differ, but software maintenance is a topic for every piece of software. You decide what it means for the software supported by your organisation, document it and act accordingly.