Have you ever inherited something? An inheritance or legacy can definitely be a positive thing. Another word is more thought-provoking: legacy! In contrast to legacy, the term legacy is much more neutral and indicates that something not necessarily positive has been left behind. And what does all this have to do with software?
Even software can be inherited! In this article, I describe how to handle legacy software in compliance with IEC 62304 and provide insights into our processes.
What is legacy software?
IEC 62304 defines legacy software as software that was legally placed on the market and is still on the market today, but was not developed according to the current version of the IEC 62304 standard (or lacks sufficient objective evidence of this). Importantly, "legally placed on the market" is used. Software that is simply old and undocumented does not fall under this definition.
What does the standard say about dealing with legacy software?
Chapter 4.4 of Amendment 1 to IEC62304 (2015) describes how to handle legacy software. The standard offers an alternative path for demonstrating legacy software conformity.
The classic path is development according to chapters 5 to 9 of IEC 62304. The alternative for legacy software is shown in the right-hand path in the illustration above.
The standard aims to offer manufacturers the opportunity to continue using old and proven software. It's not just about generating paper documents. Rather, the standard assumes that the missing documents and activities pose a greater risk. Manufacturers should consider the risk posed by the software and implement measures to mitigate the risk.
Guide to dealing with legacy software
This guide provides a clear summary of what needs to be done if you want to continue using legacy software. I divide the activities into four phases.
Phase 1) Risk management activities
Assess all software anomalies and feedback from the field regarding the legacy software. This requires a rated list of anomalies and feedback. Use your problem-solving process as a guide. If you can make quantitative statements, this will be helpful for the risk assessment. Otherwise, you must always assume the worst-case scenario when conducting the risk assessment!
Create or update the software architecture. The architecture must clearly identify which parts are legacy code! Identify the legacy software by specifying the exact version or revision.
Conduct risk management activities, paying particular attention to legacy software. Also consider how the software will be used in the future:
- same use
- similar usage with slight adjustments
- significantly different use, possibly with a different purpose.
Define the security classification of the legacy software.
Phase 2) Gap analysis (⇾ plan)
Create the list of required deliverables and activities according to your software lifecycle process and safety classification. Your process must, of course, be compliant with IEC 62304.
Compare the available documents and completed activities with the required ones. A table is a good way to do this, with the requirement on the left and the available documents on the right. This will give you a clear overview and make it easy to identify and highlight any missing or insufficient points.
Check your existing documents to see if they are still valid and complete.
Identify gaps (missing documents and activities) and assess how much you can reduce risk by completing the missing documents and activities. You aren't forced to complete everything. It's important to consider which activities are relevant to risk reduction. For example, the standard assumes that detailed design and unit verification can reduce risk during software development, but don't necessarily contribute much afterward, other than generating paper.
Define a plan that specifies which documents and activities need to be created, who is responsible for the task, and by when the task must be completed. Use your software maintenance plan as a guide! In my opinion, the minimum set of documents required is to define the software system requirements and document their testing (test specification + test report). The software architecture is also essential, as it is already required for risk management. Use existing documents, if possible, or build on them. This reduces the effort and ensures that you don't forget any important aspects that you may no longer be aware of. Ideally, you can rely on developers who have experience with this legacy software. In that case, I would recommend involving them. External people offer the advantage of not being biased or blind to the company's internal processes. Keep the focus of all your activities on minimizing risks.
Phase 3) Implementing the activities from the plan to close gaps
The team carries out the activities outlined in the gap analysis plan. Adhere to your software development process and the plan created in the gap analysis. Document what you do, and especially what you don't do, and why.
Phase 4) Justification for using legacy software (rationale)
In the justification, you should document that the software is safe and reliable for its intended purpose. It should include the following points:
- The intended context in which the legacy software is to be used.
- A statement about the security and reliability of the software.
- The version of the legacy software.
Once legacy, always legacy?
Legacy software, or parts of it, with remaining gaps in deliverables and activities will remain legacy software in the future and must be treated according to Section 4.4. However, if all gaps are closed, it is also permissible to declare conformity using the traditional method. This makes it possible to bring legacy software back to the right path.
What are the challenges in dealing with legacy?
There are a few challenges when working with legacy software. Attached is a list of the issues I see.
TOP1: Code, architecture and tools are no longer up to date
If you look at old code or old architecture, you'll often find that it's no longer state-of-the-art. Ideally, you'd like to rewrite everything. But that's time-consuming, and the old software certainly has its place. After all, it's been on the market for a long time and seems to work very well. The microcontrollers and development tools are often outdated, which leads to rejection among developers.
TOP2: Original developers no longer exist
Software knowledge decreases because the developers who originally wrote the software are no longer there. Either the developers have been promoted and no longer write software, or they have already left the company. This leads to knowledge loss and correspondingly increases effort.
TOP3: Lack of knowledge of processes and standards
The processes and knowledge required to handle legacy software are lacking within the company. This leads to a lot of action, but no one knows what to do. This could even lead to trouble with the designated department, which only exacerbates the situation. In this case, external help makes absolute sense.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
TOP4: Unclear goal definition in dealing with legacy
Legacy code isn't a bad thing. Therefore, it's important to define a goal and a strategy. Do you want to move away from legacy software and return to the traditional development process? Or do you simply want to be able to continue using the software with minimal effort? Defining the goal is very important for the decisions that follow in the gap analysis.
TOP5: No staff
Who's going to do all the work? Often, developers are working on new products, and there are few resources available for the older ones. This leads to long lead times. External support is useful here, too.
Our approach to supporting you
If we support you, we will proceed as outlined in the schedule below. The effort required depends on the legacy software and the associated scope of work. The scope can be roughly estimated after an initial consultation and finalized after the review and planning phase. Once the information from risk management and the gap analysis is available, a roadmap for completing the tasks and closing the gaps is in place.
I hope this article has provided you with some clarity on dealing with legacy software. If you have any questions or need support, please feel free to contact me.
Best regards
Goran Madzar