Software traceability is beneficial to everyone in an organisation. Engineering managers as well as quality, software engineering and software test engineers can all benefit from using traceability in the software development process.
Traceability can help reduce costs and time, meet customers’ requirements, give a more accurate estimate of time for the next project, and help management understand software design and what software engineers need.
Go deeper with GlobalData
A complete trace matrix is a software engineer’s dream when software needs to be changed. If a failing requirement’s trace can be viewed, the engineer will know where to start looking for a problem in the code, which can significantly reduce troubleshooting time. Likewise, if the engineer knows which code has a problem, he can easily trace it back to suspect requirements or tests that may be affected.
In an audit it is much easier to show that software has been adequately tested, or locate where in the code a particular requirement is implemented and tested, by referring to the trace matrix.
SAVING TIME AND MONEY
Traceability provides the link from customer requirements and safety requirements to product requirements, software requirements, design specifications, source code, test protocols and test results. It gives structure and control to any software project. Uncontrolled projects lead to uncontrolled costs and time.
How well do you really know your competitors?
Access the most comprehensive Company Profiles on the market, powered by GlobalData. Save hours of research. Gain competitive edge.
Thank you!
Your download email will arrive shortly
Not ready to buy yet? Download a free sample
We are confident about the unique quality of our Company Profiles. However, we want you to make the most beneficial decision for your business, so we offer a free sample that you can download by submitting the below form
By GlobalDataIf the development team is not using the trace matrix to code to the design specification, gold-plating (extras added by developers that are not defined in the requirements) will be very difficult to control, schedules will slip and costs will significantly increase.
The trace matrix also helps the development team focus on coding to the requirements, avoiding gold-plating that may not be required by the customer. Gold-plating also has the adverse effect of adding untested code, which can create complexity and cause logic bugs that will not be picked up until the product is in the field. Tests trace, and are written from, the design specifications or requirements and will only test what is there.
Code that gets added during gold-plating is not in the requirements or the design specification, and the software test engineer has no way of knowing it exists. A fully traced test protocol makes the software quality engineer’s job much easier when it is time to show the auditor that the software has been tested.
GETTING MANAGEMENT ON BOARD
Showing management what it takes to implement a simple upper-level product requirement in terms of the number of code modules or units required should make asking for more resources easier too. A graphic view of the trace tree of a similar requirement from a previous project can be a real eye opener.
Estimating the resources required for a new project can also be facilitated by using the trace matrix from a similar project. Knowing that the last project took ‘x’ number of software units and ‘y’ number of tests makes it very easy to estimate how many it will require next time. If the developers have recorded the time it took to code those units and run those tests, the time for a new project or similar requirement can be estimated.
A common complaint about trace matrices is the time it takes to complete one. It is often seen as a waste of time, completed only to fulfil regulatory documentation requirements. This is often the case when the matrix is done at the last minute, at which point it is time consuming complicated and of no value.
However, a trace matrix should be created while the software is being designed. If it is done properly, tracing is a simple job and produces a valuable document that can greatly help in meeting scheduled delivery dates.
SOFTWARE DEVELOPMENTS
Two buzzwords in the software development industry at present are promising to help software developers meet scheduled delivery dates: XP (extreme programming) and
UML (unified modelling language). Either of these could have a place in medical device software development in the future and provide substantial benefits, but there are many lessons to be learned before they will fit into a regulated environment. As the regulatory bodies continue to come together and write better standards, some adaptation or a new version of these terms will appear in the industry.
UML tools can be a great help in creating design documentation and breaking code into objects, but how to trace these into your requirements is still unclear. Some of the requirements tools allow you to paste objects directly into their database, which may be the answer. How the UML model is set up and separated into objects will determine if pasting into a requirements tool makes any sense and gives a trace that provides useful information.
Once the tool has been learned, there are testing and reusability benefits, and less time is needed for coding. The UML is constantly changing and evolving, so keeping up with current standards is essential.
XP has been around for years and is starting to be used more frequently in the medical device industry. The new IEC/ISO International Standard, first edition, 2006–05, mentions ‘evolutionary programming’, which is an XP spinoff. The US FDA is also considering adopting this standard.
XP: MORE INFORMATION NEEDED
XP encourages coding with limited documentation and then filling in the holes later. This can lead companies to release software with incomplete documentation and an unusable trace matrix. Although some medical device companies are using this type of programming and are very excited about it, if XP has not been through an audit where an injury or accident has occurred it may not stand up under this scrutiny.
The FDA’s General Principles of Software Validation; Final Guidance for Industry and Staff from 11 January 2002, is very specific about documentation and traceability before code, so be wary of XP or something similar versus a more traditional waterfall or spiral model for medical device software development.
Turning over incomplete requirements with limited or inadequate traceability is like giving an electronics technician a schematic showing most of the parts and some of the interconnecting lines and asking him to wire it up.
Software traceability can help bring software development into the 21st century. It reduces costs, gives better visibility and adequate test coverage, and helps software engineers meet customer needs. Changes can be implemented much faster and new projects can be estimated more accurately.
