Menu
Menu
In this article, we will try and clarify three terms:
Naturally, the question behind is: what are those?
It is not that simple. These three often cause both discussions and confusion. Therefore, we should start from the beginning.
A software unit is a part of a software item, which is further a part of a software system. A software system is, then, defined as
an integrated collection of software items organized to accomplish a specific function or set of functions.
It is worth noting that a single item can have numerous units, just as there can be many items within a software system.
On the other hand, we define a software item as
any identifiable part of a computer program, such as source code, object code, control code, control data, or a collection of these items.
You would think that virtually anything can be considered a software item, and that is correct! And the good thing is it is up to you to define software items in a way you find appropriate. You can also decide for yourself how big or small your items will be. The easiest path to take is to have an undivided software system – in such cases, a software system equals a single item. This usually does not happen, and each system is divided into at least several items because it simplifies things such as maintenance and finding out which part or parts of the software contribute to hazardous situations.
Assume the “Brickman” above is a software system then his head, arms, and legs could be items. You could stop here but, if it suits your needs, you may want to further refine the armes into upper/lower arm, hand, and elbow. Again, you can choose to keep on refining the Brickman but at some point, it does not make sense to tear the bricks apart any longer.
To go back to the definition of an item, you may have noticed that there is no clear rule of what can and cannot be an item, but every item must be identifiable both in the source code and throughout the documentation.
In case you were worried we forgot about software units, we did not – one step at a time.
So, a software unit is used to indicate when an item is not further divided, and this is usually where the coding happens. Also, items that are not further refined can be called units.
Try not to be too confused by this – you can, for example, opt for using only items since it provides more freedom, without the need to change documentation for terminology only. In your documentation, you can show where the units are and that you are aware that the unit requirements from the standard apply, regardless of whether they are named units or items.
One more thing – you can mix items and units on the same architectural level, too.
Important clarification: a software unit is not equivalent to the unit in ’’unit testing’’ used by developers to test software. Still, you can use one or many unit tests to test a software unit if that is appropriate for your design and needs.
As far as the system level is concerned, you are strongly recommended to invest time in defining your software system accurately, since it is essential to understand the boundaries of a system in order to manage software risk management, maintenance, and future releases.
To sum it all up, when working with medical device software, you will most definitely work with software systems, items, and units. As you can see from this blog post, they are quite flexible and you can work around them and with them in a way that suits your organisation best. However, in order to do that, you must first understand and study the terminology itself.
We hope this article helped. You can find our other articles here.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC62304 and also actively participated in the creation of IEC82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
