The software architecture is the description of the internal structure of a software system. Typically, the software architecture identifies the components and describes their interaction and dependency. In this article, you will find information on the following topics:
Requirements of IEC 62304 and FDA on the software architecture
Mistake #1: No upfront software architecture
Twice, I had to learn the hard way how important the software architecture is for the success of a product.
But the IBM guys were right. The actual development and value creation happens during the development of the software - and (hopefully) not during programming. Anyone who does not want to understand, pays in several ways:
So, get it right, solve your "problem" (requirements) in the (software) architecture and not during the coding. This is also exactly what the IEC 62304 requires.
Are you unsure how to do this? Do you need someone to assist you in creating a precise and law-confirm software architecture? Contact us now, we would like to help you!
Mistake #2: No standardized notation as UML
The requirement of IEC 62304 to document the software architecture, resulting in some developers knee-jerk opening PowerPoint and painting any box.
That being said, these boxes usually do not reflect the correct architecture, such diagrams are partly value-free. Because a model is only meaningful if the notation elements are defined. But what does an arrow mean by ones "own" modeling language?
Before you invent your own notation, please use UML. More than a dozen types of charts are available that allow you to pretty much be able to express everything you need to develop software conceptually.
That way, you meet the requirements according to IEC 62304 automatically.
The IEC 62304 requires that manufacturers test the software architecture, the standard speaks of verification. The most important aspects of the examination should be:
Review of software architecture as RPG
The architecture is only good if it contains components (at a tier architecture the layers should be maintained in an isolated way (i.e. truly component-oriented)) and if it is appropriate to comply with the system specification.
At least you can check the latter during the architectural review effectively with a role-playing game:
One person plays the part, for example, of the GUI (i.e. dialog and/or presentation layer), another person plays the part of business logic. Then, the GUI screens its screen masks and sees what it has in terms of objects that are of use. If there is, for example, a table that displays all female patients older than 65 with a nephropathy and with a haemoglobin level below 10 mg/dl and with a specific EPO dose, then the "GUI-actor" asks its business logic colleague to obtain this information exactly and to explain what methods cascade accurately, calculates and returns this data in the UML diagram.
You go through this game not only for all the objects of use, but also for all tools. The GUI representative asks the business logic representative, for example, to describe how the architecture responds to a click on the ‘save’ button. With an ultra-thin client, there should be a method in the backend for each object and every tool.
The aim of the person who takes the role of the GUI is to prove that the architecture is unable to obtain or store all the necessary data. After a while - my suggestion would be that - the two "actors" should switch roles. Believe me, there is no other way one can check an architecture. This requires, of course, that you have modeled your architecture.
Representatives of most of the notified bodies have visited me at the Institute, to talk about compliant software development. This gave me the opportunity to ask how they would deal with bad software architectures.
The answers were clear to me, but also surprising: The auditors would make a note of a non “finding” in a poor software architecture. A badly documented software architecture (regardless of whether the architecture itself is good or bad) could, however, cause a problem in the audit.
I can, on the one hand, understand this way of thinking, because there is no law and no standards (e.g. IEC 62304), which dictate a good software architecture. On the other hand, a bad software architecture becomes a problem if it is, for example, responsible for ensuring that risks are not controlled or even caused because of it.
Quality of documentation
Good documentation of software architecture is a condition in order to assess the quality of the architecture.
For the auditgarant I have created several video training sessions, where I explain step by step how to not only write a good documentation, but also how to create a good architecture.
As a guideline, for a "good" documentation of software architectures, you can download the ISO/IEC 42010 (good Wikipedia article) or the template of arc42.
Quality of architecture
This raises the question of the criteria and the assessment criteria for the quality of the architecture. The architecture is mainly driven by "non-functional" requirements. That means that you should check whether a sufficient number - which is relevant for the architecture - of quality requirements are defined. This is where most software/system requirements fall short. And you have to specify a method with which you check the "appropriateness" of the architecture for the quality requirements. For example, ATAM or SAAM. This is where we stumble upon the next problem: Very few people know it, let alone master it.
With the video training of the auditgarant, you will learn, step by step, how to document a "good" and standard-compliant architecture.
Need more help in creating or evaluating ("reviewing") your architecture? Get in contact with me now, I'd like to help you!
When it comes to documentation of software architecture for medical products, I normally face two types of people:
Because of these reasons, the training videos in auditgarant will help you understand more how to develop and document your software architecture compliant to the required standards.
With this knowledge, you will succeed in the next audit!
In case you have documented your software architecture, we would like to help you with a professional review. We can even give you a quick, valuable feedback at minimal cost.