Model-based methods are gaining more and more popularity in development. Why is that? And what are they exactly?

At IMT, we always strive to make our development process efficient so that we can optimally support our customers in the implementation of their projects. There is no way around model-based methods, as they can improve or simplify the most diverse aspects of system development.

There is a very wide range of model-based methods, which are intended for a wide variety of purposes and it depends very much on the project which methods bring any added value (if any). It is therefore important to choose the right set of model-based methods for each project.

In this article, we try to clarify all the terms surrounding model-based methods and demonstrate how they can be used.

What is a Model?

“A model is a simplified image of reality. Images can take the form of concrete objects or be represented in a purely abstract way.” Wikipedia

A good model shows all relevant properties of the real object, but simplified in the best way possible.

However, it also follows that a model is always optimized for a specific purpose.



Figure 1: Three models of a car, each for a different purpose.

As we can see in Figure 1, models can take a very different form to the real object. There is an almost unlimited number of possible models—the more complex an object, the more possibilities naturally arise. But even for very small things like atoms or light, different models are used in physics.

This may be one of the reasons why the term “model” in “model-based methods” is open to so many different interpretations.

However, the core is always the same and corresponds more or less exactly to the above definition. A model is a simplified representation that depicts all relevant properties of the real object. A model of this kind is less complex and thus simplifies work in relation to the specific purpose.

It is therefore only logical that there is a whole range of “model-based methods” for different areas of application. In the following, we will try to clarify the somewhat confusing terminology that arises.


How can the different approaches be classified?

According to everything we now know about models, the purpose of use as the central property of a model is a suitable parameter for a classification.

This also makes it clear from the outset that we only want to consider approaches for the development of technical systems here. So we can safely disregard the model car from Figure 1. However, the other two models demonstrate two important purposes. These purposes could be subdivided as follows:

  • Behavioral description
  • Information exchange

Even though there is some overlap, the model-based methods can be divided into these two groups based on their basic intention.

Behavioral model-based methods

In starting from a software application, it is obvious that a behavior-describing model can be used to automatically implement this application.

If this approach is extended by a second behavior-describing model, which represents the environment, i.e. the behavior of all interfaces of the first model, it is possible to simulate the behavior of the entire system.

The most common term for such an approach is:

  • Model-based design (MBD)

This also makes it possible to carry out simulations or tests for different development stages. The possible approaches are referred to as:

  • Model in the loop (MIL)
  • Software in the loop (SIL)
  • Processor in the loop (PIL)
  • Hardware in the loop (HIL)

A description of these approaches can be found in the glossary below.

Since the behavior is described by the model, it is not only possible to have the software application generated automatically, but also to verify the implementation in different development phases.


Model-based methods for information management

The third model in Figure 1 shows a highly abstracted structure of a car. A car consists of 2 front wheels, 2 rear wheels and an engine, whereby 2 wheels are driven by the engine via an axle. This type of model is very suitable for representing structures and relationships.

Model-based methods that use similar types of models to manage information include:

  • Model-based enterprise (MBE)
  • Printed Circuit Board (PCB) models in ECAD applications
  • Model-based system engineering (MBSE)

The first two methods are used in the specific disciplines of mechanics and electronics and are integrated in the corresponding development tools. MBSE, on the other hand, is a method for describing architectures of complete systems and thus in principle starts one level higher.

So, which is the best mode-based method?

After the above explanations, it is clear that this is the wrong question. Each of the above methods has its specific purpose. The question should therefore be:

Which model-based methods should I use?

Model-based methods offer many advantages, but often require appropriate tool support. If this is given, it is also possible to use all the above methods without further ado.

If all of these methods are used, the following overall picture emerges:

  • Architecture/design: MBSE
    • Mechanics: MBE
    • Electronics: ECAD
    • Software: Model-based design



Term Abbreviation Description
Model-based design MBD Model-based software development method, in which two behavioral models are used to describe the behavior of the software and the behavior of the environment.

This is also the basis for the use of “in-the-loop” procedures (MIL, SIL, PIL, HIL).

Model-based enterprise MBE Model-based mechanics development method in which the 3D model serves as the central source of information.
Model-based system engineering MBSE The system engineering methodology, in which information about a system and its structure is stored in a central model. Model-based system-engineering.
Model in the loop MIL The simulation of an embedded system in an early development phase, where the model of the software is simulated along with the model of the environment.

Assumes model-based design.

Software in the loop SIL The simulation of an embedded system in a very early development phase, where the generated code of the software model is simulated along with the model of the environment. The generated code runs on development hardware that is not identical to the target hardware. Assumes model-based design.
Processor in the loop PIL The simulation of an embedded system in a very early development phase, where the generated code of the software model is simulated along with the model of the environment. The generated code runs on the target hardware (processor). Assumes model-based design.
Hardware in the loop HIL The testing of an embedded system at a late stage of development, whereby the generated code of the software model is tested on the target hardware in an interaction with a real environment recreated by a HIL simulator. Assumes model-based design.
Electronic computer-aided design ECAD Software for the design of electronics. Also referred to as Electronic Design Automation (EDA).
Printed circuit board PCB printed circuit board or circuit board.


The terms model and model-based can be interpreted very broadly. This has not least to do with the fact that a model is always created for a specific purpose and the set of legitimate models is at least very large, if not infinite.

What they all have in common, however, is that they are simplified or reduced to what is essential. The aim is always to facilitate the activities it carries out.

General advantages and disadvantages of model-based methods:

The advantages lie in the improvement or support of work processes.

The necessary tool support can be considered a disadvantage. This can be further subdivided into tool costs, familiarization with new tools and the danger of tool lock-ins (strong ties to proprietary data formats, etc.).

However, the disadvantages mentioned can be greatly reduced with a considered choice of tools/development tools. Of course, even then it is still necessary to weigh up the advantages and disadvantages. At IMT, we are convinced that every project, regardless of size, can benefit from the use of model-based methods.

Examples for application of model-based methods at IMT:

For the development of specific electronic and mechanical components, we use CAD systems such as “Altium Designer” or “SOLIDWORKS 3D CAD”. The majority of such systems are already established on the market.

When developing larger systems, we mostly use MBD. In addition to the benefits of rapid prototyping, this also enables early fault detection through the simulation/testing approaches offered by the “in-the-loop” processes. Among other things, IMT relies on “MATLAB/Simulink” for this. For example, this is used in the development of measuring instruments.

If the product also has to meet strict standard requirements, it makes sense to combine this with an MBSE approach, which supports proof of conformity with the standard. For example, this is the case in the development of medical technology products.

Model-based methods are often used to implement smaller projects such as test automation tools, which allows “boilerplate code” to be generated. Among other things, IMT uses its own “DATAFLOW Designer” software tool, which follows an MBSE approach.


The (EN) ISO 13485 in its 2016 edition, as well as the FDA Guidances and the European Medical Device Regulation (MDR) require software used in the quality management systems of medical device manufacturers to be validated. While ISO 13485 and the EU MDR do not go into detail on validation should look like, the US FDA published guidelines on January 11, 2002: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. The ISO and IEC working groups have also considered this topic and published ISO/TR 80002-2 in 2017: “Validation of software for medical device quality systems”.

The aim of this article is to demonstrate a simple way to set up tool validation.


Software List

Both ISO 13485 (in chapter 4.1.6) and the FDA Guidance (in chapter 4.8) require software validation to be commensurate with the risk of the software, regardless of the size of the company or the resources available. Accordingly, a quality management system requires an overview of the software applications used and their intended use. Preferably, this overview will also document whether the software is

For standard software such as Microsoft Word, which is installed in the thousands, the probability that an error will be found through the swarm intelligence of its thousands of users is probably much higher than through tool validation. This circumstance should be taken into account in tool validation. It is possible that the process for standard software, which is only used for non-critical purposes, has already been completed at this stage.

Figure 1: Software list


Software Validation Plan

The software validation plan should include the following elements:


These elements can either all be documented in one document with different sub-chapters or they can be outsourced to different documents. The latter is particularly suitable for more extensive requirements documents.

Description of software

The chapter or document describing the software should describe the intended use, the intended users and their environment. Use case diagrams can be beneficial to give a simple, visual overview:

User requirements in the software

The user requirements should be in a testable format and given a unique ID. At IMT, we mostly use the following syntax:

ID Requirement
UR-[ID] [Role] would like [Function] for [Purpose]

for example, such a requirement could be

ID Requirement
UR-001 The Serveradministrator would like to be able to reset passwords, so Users who have forgotten their password can be granted access again.


UR-002 The User would like to save the only partially completed form, in order to be able to continue working after an interruption.


Both requirements have a unique ID and can be tested. Requirements that cannot be tested are to be avoided. For example, “fast” should be replaced by a time such as “2 seconds”, or “bright” by “under an inspection lamp with 1500 lx”.


Test specifications for user requirements

Each user requirement requires at least one test. In addition to a unique ID, the test specification includes the test instruction and the acceptance criterion or expected result. A test for the UR-001 above could look like this:

ID Test steps Expected result
1 Start Admin tool and register with a username and password with administrator rights Admin tool starts and an Admin is logged in
2 Select the user “Vergesslich, Hans” and click on “Reset password” Password reset window pops up
3 Enter a new password and save New password has been set.
4 Log into the app as “Vergesslich, Hans” and enter the new password Login successful.

Risk management plan for this software

Since the effects of a software error in the quality management system are different from those of a medical device, the risk management plan must also be adapted accordingly. In particular, the definitions of the impact categories must be considered differently. Depending on the area of application, the same impact categories take on completely different meanings. The impact category “critical” potentially means the death of a patient in the case of a medical device, but the loss of data in the case of medical device tracking software.

Testing and assessment

Before the validation report can be produced, the software must be tested and the risks assessed.


The software must be tested according to the test specification. In the process, not only a “pass/fail” must be logged for each test step, but also the actual behavior observed, so that the test can be re-enacted. Therefore, the software and its environmental conditions must also be logged. This includes:

Date, examiner and 4-eye-principle evaluation

Using the above example, the report could look as follows:


Test report


Environment used:

Name and manufacturer AG software, ERP system
Version and build V1.0.1, Build
Operating system Windows 10, 64 bit



ID Test steps Expected result Actual result Verdict
1 Start Admin tool and register with a username and password with administrator rights Admin tool starts and an Admin is logged in Tool started P
2 Select the user “Vergesslich, Hans” and click on “Reset password” Password reset window pops up “Reset password” window pops up P
3 Enter a new password and save New password has been set. Password successfully reset P
4 Log in to the app under username “Vergesslich, Hans” and enter the saved password Login successful. Login successful P

The overall test is:

☒ Passed

☐ Failed


Date of assessment: January 01, 2000



Auditor: Max Muster                                     Evaluation: Maximilia Meier

[Signature]                                      [Signature]


Risk analysis

The risk analysis should assess all known problems. In the case of software that is distributed for use in a regulated environment, a corresponding list of known anomalies is often also published. It is worthwhile to check the manufacturer’s support website or to contact support. In addition to problems known to the manufacturer, shortcomings such as missing features must also be assessed. If a risk is not acceptable, control measures must be defined to reduce the risk. As medical device manufacturers who are used to risk management according to ISO 14971, we recommend following the same process.


Software validation report

The software validation report should include the following elements:

NB: For “smaller” applications, it is possible to produce the test report, risk analysis and validation report in one document.

Identifying the software and environment, test report

Often there is a matrix of validated versions and environments for the software. If this is the case, it should be mapped accordingly in the validation report:

Software Version Windows 10, 32 bit Windows 10, 64 bit
V1.0.1, Build n/a Bericht 1.pdf
V1.0.1, Build Bericht 2.pdf Bericht 3.pdf


Risk management report on the known anomalies of the software

The validation report shall further assess the residual risk arising from the use of this software. The focus is on the acceptability of the known anomalies and/or missing functions.


Another aspect to cover is to prove that all requirements for the software have been tested. Depending on the scope of the requirements and the documentation of the tests, two ways of documenting this have emerged:

Forward linking of the requirements to the tests

A column is added to the requirement table where the requirement is checked:

ID Requirement Tested in
UR-001 The Serveradministrator would like to be able to reset passwords, so Users who have forgotten their password can be granted access again. TC 1-4
UR-002 The User would like to save the only partially completed form in order to be able to continue working after an interruption. TC 5-8

This variant is particularly suitable for a small scope of requirements and if the entire validation is created in one document.


Traceability Matrix

In the case of extensive requirements documents or if the test implementation has its own IDs, it is advisable to create a traceability matrix that contrasts the requirements with the test specification and possibly the test report:

Requirement Test specification
Test report
UR-001 TC-1 TR-12
TC-2 TR-13
TC-3 TR-14
TC-4 TR-15
UR-002 TC-5 TR-17
TC-6 TR-18
TC-7 TR-19
TC-8 TR-20

If several reports need to be mapped for different runtime environments and software versions, this can be mapped very easily in a traceability matrix by adding additional columns.


Formal evaluation and approval

Last but not least, the entire package of documentation should be evaluated and documented with an approval decision.


As shown in the images, the validation of the software in the quality management system is nothing more than the systematic, documented execution of the upper left and right corners of the V-model widely used in software development:

This includes:


Embedded „system design“, „system architecture“, „software architecture“, what exactly is behind these terms? What do they mean? What are the definitions? Why is it important to differentiate between these two terms?

This article deals with the answers to these questions.


The system

Here, we are dealing with technical systems, Or more specifically, with embedded systems. An embedded system is defined as follows:

“An embedded system is an electronic computer that is integrated (embedded) in a technical context. In this context, the computer either performs monitoring, control or regulating functions or is responsible for some form of data or signal processing, for example in locking or unlocking, encoding or decoding or filtering.”

Source: Wikipedia


Very similar to this definition (source

“An embedded system is a binary-valued digital system (also called a computer system) that is embedded in and interacts with a surrounding technical system. Here, the computer usually takes over monitoring, control or regulation functions, but is often also responsible for some form of data or signal processing.”


These definitions can be clarified with the following diagram:


Figure 1: General embedded system with the desired function/responsibility, surrounded by external systems and one or more users.


For the sake of simplicity, we usually simply refer to the “system” we are dealing with. Throughout the remainder of this article, we will often only refer to the „system“, which means the corresponding technical or embedded system.


Architecture and design

In order to explain the terms, we must demonstrate how such a system is built. Figure 1 presents the embedded system as a black box. The structure of the system has not yet been defined. The components from which the system is to be built must be defined. This activity is known as “design”. A “system design” is therefore about defining and determining the system structure. Based on the diagram (Figure 2), the result of this design activity could look as follows:


Figure 2: Result (architecture) the first design iteration to define the components (architecture elements).


Design activities tend to be repetitive. This means that the components—referred to here as architectural elements—are decomposed until they are sufficiently defined. Only then can the creation (development) of the system begin.

The result of this design activity is called “architecture”. Figure 2 is therefore a first “system architecture” (strictly speaking, Figure 2 is a reference architecture of a general embedded system), although the term architecture still needs to be defined more precisely in this context. There is no single established definition of the term architecture. You can find a list of definitions here: Definition Software Architecture. While these are definitions of software architecture, they also apply to the term system architecture. The distinction lies in the scope—more on this below.


We use the following definition of architecture (from „Software Architecture in Practice – Third Edition“):


Definition of (software) architecture:

“The (software) architecture of a system is the set of structures needed to reason about the system, which comprise (software) elements, relations among them, and properties of both.”


It contains the following 3 sentences:

  1. The architecture of a system is built from a set of structures.
  2. These are the structures needed to be able to infer the system.
  3. The structures include the elements, their relationships and their properties.


So, what does that mean?

The structures consist of the elements, their relationships and their properties. Architecture consists of structures, which are needed to ensure that the system behaves as required. The whole area of non-functional requirements is also meant here, in addition to the fulfillment of functional requirements. For example, requirements regarding further development usually influence the structure of the system. However, not all structures in a system belong to architecture. Not all structures are architecture-relevant. These structures are then no longer referred to as architecture, but as design.


Design” is on the one hand the activity that leads to an architecture (see above), and on the other hand the term for all non-architectural results of the design activity.


Many definitions simplify things by stating that the rough structure or the structures defined early in the design process are architecture. All later or more detailed structures are design. However, these definitions are insufficient, as more detailed structures may well be necessary to meet the required demands. Also, in agile development, not everything relevant is defined early in the design process.


System versus software

Finally, the distinction between “system architecture” and “software architecture”: As already mentioned above, they differ in scope. The system architecture includes the structures of various system elements, such as hardware, software and mechanics. The software architecture, on the other hand, comprises the structures that define the structure of a software element (an element from the system architecture). This can be seen in the diagrams below:


Figure 3: System architecture diagram with hardware and software elements.



In the further decomposition of a software element, we eventually end up with the software architecture:

Figure 4: Software architecture diagram of software elements “Control Software”.



The most important terms and their definitions are summarized again in the following table:


Term Meaning, definition
Embedded system An embedded system is an electronic calculator or computer, which carries out a defined function and is embedded in a physical environment, is optionally surrounded by other subsystems and has an optional user interface.
Design (activity) The activity that defines how a system is built from several components (architecture elements).
System design (activity) See “Design”— with the specification that it is the design of a system, i.e. various elements such as hardware, software, mechanics.
Software design (activity) See “Design”— with the specification that it is the design of a software (software elements).
Architecture The architecture of a system is the set of structures needed to infer the system, or to ensure that the system satisfies the required properties. The structures include the elements, their relationships and their properties.
The design The structures which, in addition to the architecture-relevant structures (see „Architecture“), also define the structure of the system, but which are not relevant for the required system properties.
The system architecture See “Architecture”— with the specification that it is the design of a system, i.e. various elements such as hardware, software, mechanics.
The software architecture See “Architecture”— with the specification that it is the design of a software (software elements).
Table 1: Terms and their meaning/definition


The documentation for system and software architectures is explicitly required for medical systems with safety-critical requirements, such as patient monitoring systems or ventilators. In addition, proof must be provided that an architecture has also been implemented according to its definition. But even outside the regulated area, the accurate description of an architecture is useful for most applications, because the description of an architecture is not only proof that requirements have been fulfilled, but it also helps to detect errors in the specification at an early stage. This article shows which (auxiliary) means can be used to describe an architecture and what can be followed.


Description of architecture

As explained in the article on system and software architecture, the architecture of a system is “the set of structures needed to infer the system, or to ensure that the system satisfies the required properties.

Admittedly, this definition is rather abstract and shows no concrete reference to hardware, electronics or software. However, a system consists of different structures such as software, electronics or mechanics. In addition, a system can also be characterized by logical structures or temporally sequential processes. In this sense, the term “the architecture” can be misleading, as the singularity of the term architecture might suggest that an architecture consists of a single image. However, practical experience shows that a system must be viewed from many different angles (views) and thus must also be described. For example, a system may be divided into logical units and functions that do not necessarily correspond to the physical division. This can be shown by the following, highly simplified, example:


Figure 1: Logical and physical view of a client-server application and an associated scenario to connect the views.


But which is the right or best view, and most importantly, the one recognized by regulations?

An architecture description usually consists of showing different views, making connections between views, and making the fulfillment of different requirements clear. In this respect, the description of an architecture consists of several views, which highlight different aspects. That is, there is no one true view, but the description of an architecture takes into account different views equally [1].


Views of an architecture

The views are an essential part of the international ISO/IEC/IEEE 42010 standard [link to], which provides guidance on how to describe the architecture of a system. This standard was published in 2011 and is the result of a joint ISO and IEEE revision of the earlier (software-heavy) IEEE 1471 standard [link to]. The original IEEE 1471 standard specified how to describe the architecture of a system. Further requirements, such as the structure of an architecture as well as requirements for description language, were added in 42010. However, the standard does not require a specific architecture description or description language. Instead, the practice of describing an architecture should be standardized.


Views are intended to represent a system by considering stakeholder requirements (concerns) based on defined viewpoints. Figure 2 shows how views, viewpoints, requirements and stakeholders are related.

Figure 2: Dependencies between views, positions, requirements and stakeholders based on the ISO 42010 standard


Due to IMT’s many years of experience in the field of system and software design, the following process has been established to create an architecture description, which is strongly based on the ISO 42010 standard:


The individual steps are described in more detail in the following chapters.


Identifying stakeholders

In order to define the viewpoints in a targeted and, above all, systematic manner, the first step is to identify the stakeholders who work with and for the system, or make decisions about the system. These may include developers, product managers, risk managers, end users, production staff, project managers, etc.


Identifying concerns and requirements

The requirements for the architecture description should be recorded and documented based on the stakeholders identified. In addition to the context interview held with the stakeholders, information on requirements for architecture documentation can also be found in the user or system requirements. Table 1 shows how this might look using Figure 1 as an example.


Stakeholder Expectations of the architecture (concerns)
Software Developer Definition of the target system(s)

Definition of interfaces

Product Manager Expected scalability

Proof of fail-safe operation

Data Protection Officer Evidence of data protection
Table 1: Identifying stakeholders and system-architecture expectations


Definition of appropriate points of view

The viewpoint is characterized by a set of requirements from the corresponding stakeholders, as well as different conventions regarding model types, notations and techniques for the views based on them. Table 2 gives an example of how the viewpoints can be defined. The corresponding notations must be defined in addition to the tabular list. This can be done either in each view separately, or, in terms of the 42010 standard, in a separate viewpoint-specific section.



Viewpoint Concerns addressed Model types Analyze techniques


Interfaces Hierarchical decomposition diagram including description of all interfaces. Reviews
Physical viewpoint Scalability


Target systems

Hierarchical decomposition diagram including description of all interfaces. Reviews

Fault tree analysis


Data processing procedures Data protection Tabular list of data processing operations, including sensitivity classification and intended use. Check-lists
Table 2: Definition of viewpoints



A viewpoint is a type of template that can be (re)used across multiple systems and/or is interchangeable among architects. This template is then used to create system-specific views based on it. A well-known collection of viewpoints is the “4+1 view model” by Kruchen or the arc42 template , which are used in software systems especially. However, the use of viewpoints is not limited to software architectures—they can be applied to any system.


The definition and choice of viewpoints is primarily determined by the concerns of the identified stakeholders. In the following chapters, we present three possible views, although this set is not applicable to every system.


In general, it is recommended to keep the number of views used to a reasonable minimum, as redundancies increase with each additional view. In addition, each view must be maintained, tracked and, most importantly, kept consistent throughout the course of the project. The resulting effort increases with the number of views. In this case, less is more—provided that the views allow the requirements to be proven.


The logical view

The logical view is often used as the (primary) viewpoint for devices consisting of hardware and software. In the process, the system is broken down into its individual logical parts and arranged. In this view, functional requirements can be assigned to components and possible functional redundancies within the system can be identified. Explicit assignment of system requirements makes sense, as this ensures traceability. Proof of traceability is required, especially for safety-critical systems. This applies not only to system architectures, but also to subsystem and software architectures.


Communication paths and timing sequences/dependencies can also be defined within the logical view, depending on the architectural language. A combination is presented, as logical division and the associated processes are extremely dependent. Alternatively, the processes can be represented in a dedicated view, in which case the design of the logical view and process view is usually repetitive.


The physical view

As with the logical view, different physical viewpoints can expand the description and understanding of the system. Physical views can be, for example, electronic, pneumatic or electromechanical views, which are useful depending on the requirements of the system. A physical view can also make sense for distributed software systems, in which implementing non-functional requirements such as scalability, availability or performance can be demonstrated.


The development view

The development view is often only implicit, but it is also very important for a smooth project workflow. This shows how the system to be developed can be divided into small work packages in order to assign them to individual developers or development teams. Not only can internal requirements such as reusability or the selection of development tools be taken into account, but this view also enables development costs and deadlines to be monitored throughout the course of the project. The development view is often not part of the formal system architecture, but is created as part of project planning.


Verification of architecture

Running scenarios is a popular tool for architecture verification. The most important key scenarios are defined depending on the requirements. A scenario is not a view in its own right, but builds on existing views by linking them. Therefore, a complete architecture description is the basis for verification, or rather, the scenarios can only be run if the architecture has been fully described. Analogous to the description of the logical or physical view, the sequence of the scenario is presented in diagram form. Object interaction diagrams are often used to represent the interaction between logical and/or physical elements (see also Figure 1). Such scenarios are not only used to verify an architecture, but also to help understand the structure of a system.



Often, different stakeholders are involved who place different demands on a system. In order to address these concerns specifically and to verify that they have been fulfilled, several views are needed to describe an architecture. These views can be derived from generally defined viewpoints. The viewpoints consist of universally applicable conventions and are thus interchangeable and reusable across multiple systems. Finally, an architecture description can be verified with the help of scenarios to demonstrate fulfillment of the most important requirements.


[1] Basic principle (II) of ISO 42010


References to non-existent chapters or documents, outdated figures, inconsistent terms!

Unmaintained system architecture documentation often raises more questions than it is able to answer. Accordingly, care should be taken to ensure that all information is kept up to date.

However, even with the best intentions, precisely defined workflows, and strictly adhered to development processes, mistakes will creep in every now and then. As a result, the information is not always completely trustworthy and must be checked more often during implementation.

The following section highlights the issue of information management in the system development process. The weaknesses of the “classic” document-centric approach are addressed and alternative approaches are highlighted.

Why is it so difficult to keep the information up to date?

A system architecture has a hierarchical structure, which is usually described in one or more documents by means of figures and text.

Figure 1 Shows an example of the structure of a system architecture. On one hand, the arrows represent the hierarchical dependency, and on the other, the flow of information (terms, etc.) throughout the course of the design process.


Figure 1: System architecture documents (with implementation artifacts) for a system with three subsystems.


Thus, the information is spread over several documents and images, and if one piece of information is used in several places, it is always a duplicate. This means that each time a copy of the information is made, there is no longer any connection to the original information.

The issue here is evident. To make a change correctly, the information must be adjusted in all places where it is used. This is not only very time-consuming, but also prone to error, as it is not known where else the corresponding information is being used.

The continuous copying and passing on of information is strongly reminiscent of the well-known children’s game “Chinese Whispers”, the appeal of which lies in the fact that mistakes are inevitable.

In Figure 2, this simple game is used as an example to show what could happen with a parameter designation—in this case even without introducing a content error. However, this is also very detrimental to the comprehensibility of a system architecture.


Figure 2: Problem of information duplication, illustrated by the children’s game “Chinese Whispers”.


How can information divergence be prevented?

If we look at the “Chinese Whispers” example, the solution is probably obvious.

Figure 3: The first in line ensures that everyone receives the information directly. The information cannot diverge if it always comes from a single source.


And just like that, all the fun of the game is ruined. However, for all other cases where divergent information is no fun, this is very advantageous.

In software development, there is a basic principle that aims to do just that: “Don’t repeat yourself”. The main goal is to avoid redundancy in order to increase consistency. This principle can also be applied to a system architecture. This would make it possible to keep them up to date easily and with little risk of error, benefiting not only the design process, but also the development and lifecycle process.

Another way to achieve this is by continuous synchronizing information. In this case, any changes made to information is automatically propagated to all instances where it appears. This is a decentralized approach in which a software development analogy most closely resembles a Git repository, with the ability to merge multiple information assets.


How can this be implemented?

Single Point of Definition

The code is the design” is another approach from software development that can be seen as either pragmatic or radical. Perhaps this approach is also a result of the “Law of the Instrument” (“If your only tool is a hammer, every problem looks like a nail”).

And while the simplicity of this idea has a certain appeal, it comes with too many limitations.

  • Limitation to software-only projects.
  • Comprehensibility suffers enormously from being overloaded with too many unnecessary details.
  • The purely text-based medium does not allow for any explanatory graphic elements.


A somewhat more general approach is to use a central information manager, which manages information centrally and makes it available for the various areas of application. This idea is nothing new and is used in software development—for example in the “Model View Controller” concept. In systems development, this is often referred to as “model-based…” or “model-driven…”. The term “model” refers to the place where the central data is stored or managed.

In Figure 4, the example of the structure of a system architecture is shown above, with a central information management instance added.


Figure 4: System architecture for a system with three subsystems with centralized information storage.


However, this approach needs stronger support from specific software solutions, since information must be obtained from the “system model”. As a result, the architecture documents are no longer the direct output of the design process, but must be generated from the “system model” in a separate step.

Although this involves changing the usual working tools to a certain degree, the advantages of such a solution outweigh the disadvantages. This can be seen not least from the fact that similar concepts have already been established in other areas. Examples include CAD software for mechanical development or ECAD software for electronics development. In IMT, for example, “SOLIDWORKS 3D CAD” and “Altium Designer” are used for this purpose.



A common name for this approach is “roundtrip engineering”, where information in different documents, software artifacts, etc. is to be kept in sync.  It describes something like the ideal image of a software architecture, or even the implementation of a whole product. Regardless of where the information is edited, it is automatically tracked in all places where it is used. It promises even more: Regardless of whether a new component is added to the architecture or implementation, you get the same complete set of documents, software artifacts, etc. As nice as this would be, it’s not all plain sailing from here.

The fundamental problem is that this assumes a one-to-one relationship between all hierarchical levels. This would not only lead to very strict limitations in terms of implementation, but in some cases it is not even achievable, as abstraction at higher levels means that not all the information is available.


That being said, if we look at this more pragmatically, it becomes apparent that this is not even necessary for the case of application of system development. If it is clearly defined at which level which information is defined, it actually seems to be much more understandable. With the exception of this limitation, centralized data storage, which was introduced earlier, can provide the same functionality.


Can central information be used outside of the system architecture?

Of course, it would be consistent to use this central data in as many aspects of system development as possible. However, this would require all the necessary functions to be integrated into a software solution, or at least a defined interface to share the information. However, since the different areas of system development each have very specific requirements and there are already very good stand-alone software solutions for this (e.g. “SOLIDWORKS 3D CAD” and “Altium Designer”), it would probably involve an enormous amount of effort to also use the information directly in the specific CAD applications.

However, for the most agile part of system development—software development—it is quite possible to use code generation to create the structure and so-called “boilerplate code” for implementation. This allows the benefits of centralized information management to be leveraged right through to implementation. For this purpose, IMT relies on its own in-house developed software tool “DATAFLOW Designer”, which supports not only the provision of boilerplate code but also verifies conformity to standards.



The goal is an up-to-date, consistent and comprehensible system architecture that provides every developer with the required information quickly and easily. To achieve this, the developers should be supported in the best possible way during creation and customization. Central information management is a fundamental building block for this, which makes it possible to support developers in a variety of ways—from design to implementation. The achievable increases in efficiency and quality benefit both the customer and the developer.



Referenzen auf nichtexistierende Kapitel oder Dokumente, veraltete Abbildungen, inkonsistente Bezeichnungen!

Eine ungepflegte Systemarchitektur-Dokumentation wirft oft mehr Fragen auf, als sie zu beantworten im Stande ist. Dementsprechend sollte darauf geachtet werden, dass alle Informationen immer auf Stand gehalten werden.

Doch selbst mit den besten Vorsätzen, präzise definierten Arbeitsabläufen und streng eingehaltenen Entwicklungsprozessen, werden sich immer wieder einmal Fehler einschleichen. Dies hat zur Folge, dass man den Informationen doch nicht immer ganz vertraut und öfter auch in der Implementation nachsieht.

Im Folgenden wird das Problem des Informations-Managements im Systementwicklungsprozess beleuchtet. Dabei werden die Schwächen des «klassischen» dokumentenzentrierten Ansatzes angesprochen und alternative Ansätze aufgezeigt.

Wieso ist es so schwierig die, Informationen aktuell zu halten?

Eine Systemarchitektur hat eine hierarchische Struktur, welche üblicherweise in einem oder mehreren Dokumenten mittels Abbildungen und Text, beschrieben wird.

In Abbildung 1 ist ein Beispiel für die Struktur einer Systemarchitektur dargestellt. Die Pfeile stellen zum einen die hierarchische Abhängigkeit dar und zum anderen den Informationsfluss (Bezeichnungen etc.) im Zuge des Design-Prozesses.

Abbildung 1: Systemarchitektur Dokumente (mit Implementations-Artefakten) für ein System mit drei Teilsystemen.



Die Informationen sind also über mehrere Dokumente und Abbildungen verteilt und wenn eine Information an mehreren Stellen verwendet wird, handelt es sich immer um eine Duplikation. Man erstellt also jedes Mal eine Kopie der Information, wobei keinerlei Verbindung mehr zur Ursprungsinformation besteht.

Damit ist das Problem schon offensichtlich. Um eine Änderung korrekt durchzuführen, muss die Information an allen Stellen, wo diese verwendet wird, angepasst werden. Dies ist nicht nur sehr zeitaufwändig, sondern auch fehleranfällig, da völlig unbekannt ist, wo die entsprechende Information überall verwendet wird.

Das fortlaufende Kopieren und Weitergeben einer Information erinnert stark an das wohl allen bekannte Kinderspiel «Stille Post», wobei hier der Reiz gerade darin liegt, dass es unvermeidlich zu Fehlern kommt.

In Abbildung 2 dient dieses einfache Spiel, zum Aufzeigen dessen, was mit einer Parameterbezeichnung passieren könnte – in diesem Fall sogar, ohne einen inhaltlichen Fehler einzuführen. Für die Verständlichkeit einer Systemarchitektur ist dies jedoch auch sehr abträglich.


Abbildung 2: Problem von Informationsduplizierung, veranschaulicht anhand des Kinderspiels «Stille Post»


Wie kann das divergieren von Informationen verhindert werden?

Wenn wir uns das «Stille Post»-Beispiel ansehen, ist die Lösung wohl offensichtlich.


Abbildung 3: Der erste in der Reihe stellt sicher, dass alle die Information direkt von ihm erhalten. Die Information kann nicht divergieren, wenn sie immer aus einer einzigen Quelle stammt.


Und so einfach ist der ganze Spass des Spiels zunichtegemacht. Für alle anderen Fälle, in denen abweichende Informationen keinen Spass machen, bringt dies jedoch einen grossen Vorteil.

In der Softwareentwicklung gibt es ein Grundprinzip, welches genau darauf abzielt: «Don’t repeat yourself». Hauptziel ist, Redundanz zu vermeiden, um die Widerspruchsfreiheit zu erhöhen. Dieses Prinzip kann auch auf eine Systemarchitektur angewendet werden. Damit wäre es möglich, diese einfach und mit geringem Fehlerrisiko auf Stand zu halten, wovon nicht nur der Design-Prozess profitiert, sondern auch der Entwicklungs- und LifeCycle-Prozess.

Ein weiterer Weg, dies zu erreichen, ist die andauernde Synchronisation der Informationen. Dabei wird die Änderung einer Information automatisch an alle Instanzen, welche diese benutzen, propagiert. Dabei handelt es sich um einen dezentralen Ansatz, bei welchem eine Softwareentwicklungs-Analogie am ehesten einem Git-Repository, mit der Möglichkeit zum Zusammenführen (merge), mehrerer Informationsbestände entspricht.


Wie lässt sich dies umsetzen?

Single Point of Definition

Ebenfalls aus der Softwareentwicklung kommt ein Ansatz, den man entweder als pragmatisch oder radikal betrachten kann, «the Code is the design». Vielleicht ist dieser Ansatz auch ein Resultat des «Law of the Instrument» («Wer nur einen Hammer hat, sieht in jedem Problem einen Nagel»).

Und obwohl die Schlichtheit dieser Idee einen gewissen Reiz hat, bringt sie zu viele Limitierungen mit sich.

Ein etwas generellerer Ansatz ist die Verwendung eines zentralen Informationsmanagers, welcher Informationen zentral verwaltet und für die unterschiedlichen Einsatzgebiete zur Verfügung stellt. Diese Idee ist auch nicht neu und wird in der Softwareentwicklung zum Beispiel im «Model View Controller»-Konzept verwendet. In der Systementwicklung spricht man dabei oft von «Model based …» oder «Model driven …». Dabei versteht man unter «Model» den Ort, an dem die zentralen Daten abgelegt bzw. verwaltet werden.

In Abbildung 4 ist das weiter oben gezeigte Beispiel der Struktur einer Systemarchitektur dargestellt, wobei eine zentrale Informationsmanagement-Instanz hinzugefügt wurde.

Abbildung 4: Systemarchitektur für ein System mit drei Teilsystemen mit zentraler Informationshaltung.

Dieser Ansatz benötigt aber eine stärkere Unterstützung durch spezifische Softwarelösungen, da Informationen vom «System Model» bezogen werden müssen. Als Folge dessen sind die Architektur-Dokumente nicht mehr das direkte Ausgangsprodukt des Designprozesses, sondern müssen in einem gesonderten Schritt, aus dem «System Model», generiert werden.

Doch auch, wenn dies eine gewisse Umstellung in den gewohnten Arbeitsmitteln mit sich bringt, überwiegen die Vorteile einer solchen Lösung. Dies ist nicht zuletzt daran zu sehen, dass sich ähnliche Konzepte in anderen Gebieten bereits durchgesetzt haben. Als Beispiele seien hier die CAD-Software für die Mechanikentwicklung oder ECAD-Software für die Elektronikentwicklung erwähnt. In der IMT werden hierfür zum Beispiel «SOLIDWORKS 3D CAD» und «Altium Designer» eingesetzt.



Eine geläufige Bezeichnung für diesen Ansatz ist «Roundtrip engineering», dabei sollen Informationen in unterschiedlichen Dokumenten, Software-Artefakten, etc. synchron gehalten werden.  Es beschreibt damit so etwas, wie das Idealbild einer Software Architektur oder gar einer ganzen Produktumsetzung. Unabhängig an welcher Stelle ich eine Information verändere wird diese automatisch an allen Stellen, wo sie verwendet wird, nachgeführt. Es verspricht sogar noch mehr, unabhängig davon, ob eine neue Komponente in der Architektur oder der Implementation hinzugefügt wird, erhält man denselben vollständigen Satz an Dokumenten, Software-Artefakten, etc. So schön dies auch wäre, beginnt hier diese Utopie etwas zu bröckeln.

Das grundlegende Problem ist, dass dies eine eineindeutige Beziehung zwischen allen hierarchischen Ebenen voraussetzt. Dies würde nicht nur zu sehr strikten Einschränkungen bei der Umsetzung führen, sondern ist in manchen Fällen zudem nicht erreichbar, da durch die Abstraktion auf höheren Ebenen gar nicht die gesamte Information vorhanden ist.

Doch betrachten wir das etwas pragmatisch, zeigt sich, dass dies für den Anwendungsfall der Systementwicklung auch gar nicht nötig ist. Vielmehr scheint es für mich viel verständlicher, wenn klar definiert ist, auf welcher Ebene welche Information definiert ist. Mit der Ausnahme dieser Einschränkung kann die zentrale Datenhaltung, welche zuvor vorgestellt wurde, dieselbe Funktionalität zur Verfügung stellen.


Kann die zentrale Information auch über die Systemarchitektur hinaus verwendet werden?

Natürlich wäre es konsequent, in möglichst allen Aspekten der Systementwicklung, diese zentralen Daten zu verwenden. Dies erfordert jedoch eine Integration aller dafür notwendigen Funktionen in eine Softwarelösung, oder zumindest eine definierte Schnittstelle, um die Informationen zu teilen. Da die unterschiedlichen Gebiete der Systementwicklung jedoch jeweils sehr spezifische Anforderungen haben und es dafür bereits sehr gute eigenständige Softwarelösungen gibt (z.B. «SOLIDWORKS 3D CAD» und «Altium Designer»), wäre es wohl mit einem enormen Aufwand verbunden, die Informationen auch direkt in den spezifischen CAD-Anwendungen zu verwenden.

Für den agilsten Teil der Systementwicklung, die Softwareentwicklung, ist es aber gut möglich, mit Hilfe von Code-Generierung, die Struktur und sogenannten «Boilerplate-Code», für die Implementation zu erzeugen. Damit können die Vorteile des zentralen Informationsmanagements bis in die Umsetzung hinein genutzt werden. Die IMT setzt hierfür auf das eigene, im Haus entwickelte Software-Tool «DATAFLOW Designer», welches neben dem Bereitstellen von Boilerplate-Code auch beim Nachweis der Normenkonformität unterstützt.



Das Ziel ist eine aktuelle, widerspruchsfreie und verständliche System Architektur, welche jedem Entwickler die benötigten Informationen einfach und schnell zur Verfügung stellt. Um dies zu erreichen, sollte die Entwickler bei der Erstellung und Anpassung bestmöglich unterstützt werden. Ein fundamentaler Baustein dafür stellt das zentrale Informations-Management dar, mit dem es möglich ist, die Entwickler vom Design bis zur Umsetzung auf vielseitige Weise zu unterstützen. Die erzielbaren Effizienz- und Qualitätssteigerungen kommen dabei sowohl dem Kunden als auch dem Entwickler zugute.


Die (EN) ISO 13485 in Ihrer Ausgabe von 2016, genauso wie die FDA Guidances und die Europäische Medical Device Regulation (MDR) fordern, dass Software, welche im Qualitätsmanagement System der Medizingerätehersteller verwendet wird, zu validieren sei. Während die ISO 13485 und die EU MDR nicht weiter beschreiben, wie die Toolvalidierung auszusehen hat, hat die US FDA am 11. Januar 2002 eine Guidance veröffentlicht: “General Principles of Software Validation; Final Guidance for Industry and FDA Staff”. Auch die Arbeitsgruppen von ISO und IEC haben sich Gedanken zu diesem Thema gemacht und 2017 den ISO/TR 80002-2 veröffentlicht: «Validation of software for medical device quality systems».

Ziel dieses Artikels ist es, einen einfachen Weg aufzuzeigen, wie eine solche Tool-Validierung aufgebaut werden kann.


Software Liste

Beide, die ISO 13485 (in Kapitel 4.1.6) und die FDA Guidance (in Kapitel 4.8) fordern, dass die Validierung der Software dem Risiko der Software entspricht, unabhängig von der Firmengrösse oder der zur Verfügung stehenden Ressourcen. Dementsprechend benötig ein Qualitätsmanagementsystem eine Übersicht über die eingesetzten Softwareapplikationen sowie ihres Verwendungszwecks. Vorzugsweise wird in dieser Übersicht auch dokumentiert ob es sich um eine

Eine Standard-Software wie z.B. Word von Microsoft sind zu tausenden installiert, die Wahrscheinlichkeit, dass die Schwarmintelligenz dieser tausenden von Nutzern ein Fehler findet, ist wohl um einiges höher, als meine Tool Validierung. Diesem Umstand darf in der Toolvalidierung Rechnung getragen werden. Der Prozess für Standard Software, welche nur für nicht-kritische Zwecke verwendet wird, kann unter Umständen bereits hier abgeschlossen werden.

Abbildung 1: Software Liste


Software Validierungsplan

Der Software-Validierungsplan bzw. Toolvalidierung sollte folgende Elemente enthalten:

  1. Beschreibung der Software inklusive vorgesehenen Gebrauch, vorgesehene Nutzer und deren Umgebung
  2. Anforderungen an die Software
  3. Testspezifikation für die Softwareanforderungen
  4. Risikomanagement Plan für die zu validierende Software

Diese Elemente können entweder alle in einem Dokument mit verschiedenen Unterkapitel dokumentiert werden, oder aber in verschiedene Dokumente ausgelagert. Letzteres eignet sich vor allem bei umfangreicheren Anforderungsdokumenten.


Beschreibung der Software

Das Kapitel oder Dokument mit der Beschreibung der Software soll den vorgesehenen gebrauch, die vorgesehenen Nutzer und deren Umgebung beschreiben. Use Case Diagramme können hier von Vorteil sein um eine einfache, visuelle Übersicht zu geben:

Abbildung 2: Use Case Diagram – Benutzer Verwalten


Software Nutzer Anforderungen

Die Nutzer-Anforderungen sollten in einer testbaren Form erfasst und mit einer eindeutigen ID versehen werden. Wir bei IMT nutzen hier meist die folgende Syntax:




[Rolle] möchte [Funktion] für [Zweck]

zum Beispiel könnte eine solche Anforderung heissen




Der Serveradministrator möchte Passwörter zurücksetzen können um Nutzern die Ihr Passwort vergessen haben erneut Zugriff zu gewähren.



Der Benutzer möchte das erst teilweise ausgefüllte Formular speichern um nach einem Unterbruch weiter arbeiten zu können.

Beide Anforderungen haben eine eindeutige ID und können getestet werden. Anforderungen welche nicht getestet werden können sind zu vermeiden, so sollte «schnell» durch eine Zeitangabe wie «2 Sekunden» ersetzt werden, oder «hell» durch «unter einer Inspektionslampe mit 1500lx».


Testspezifikation für die Nutzer-Anforderungen

Jede Nutzer-Anforderung benötigt im Minimum einen Test. Zur Testspezifikation gehört neben einer eindeutigen ID, die Prüfanweisung sowie das Akzeptanzkriterium oder erwartete Resultat. So könnte ein Test für obiges UR-001 aussehen:



Erwartetes Resultat


Admin-Tool starten und mit einem Benutzername und Passwort mit Administratorrechten anmelden

Admin-Tool ist gestartet und ein Admin ist eingeloggt


Wähle den User «Vergesslich, Hans» aus und wähle «Passwort zurücksetzen»

Passwort zurücksetzen Fenster erscheint


Setze ein neues Passwort und speichere es

Neues Passwort ist gesetzt.


Logge dich in der Applikation mit dem User «Vergesslich, Hans» und dem soeben gesetzten Passwort ein

Login war erfolgreich.


Risikomanagement Plan für diese Software

Da die Auswirkungen bei einem Fehler der Software im Qualitätsmanagementsystem anders sind, als bei einem Medizinprodukt, muss auch der Risikomanagementplan entsprechend angepasst sein. Insbesondere die Definitionen der Auswirkungskategorien benötigen eine differenzierte Betrachtung. Je nach Anwendungsbereich bekommen die selben Auswirkungskategorien eine völlig unterschiedliche Bedeutung. Die Auswirkungskategorie «kritisch» bedeutet bei einem Medizingerät möglicherweise den Tod eines Patienten, bei einer Software zur Rückverfolgung der Medizingeräte dagegen der Verlust von Daten.


Prüfen und Bewerten

Bevor der Validierungsbericht erstellt werden kann, muss die Software getestet und die Risiken müssen bewertet werden.


Die Software ist gemäss der Prüfspezifikation zu prüfen. Dabei ist zu jedem Prüfschritt nicht nur ein «Pass/Fail» zu protokollieren, sondern auch das tatsächlich beobachtete Verhalten, so dass die Prüfung nachgestellt werden kann. Daher muss auch die Software und ihre Umgebungsbedingungen protokolliert werden. Dazu gehören:

Aber auch Datum, Prüfer sowie eine Bewertung im 4-Augen-Prinzip gehört dazu:

Ein solcher Report für obiges Beispiel könnte wie folgt aussehen:



Verwendete Umgebung:

Name und Hersteller

Software AG, ERP System

Version und Build

V1.0.1, Build


Windows 10, 64bit




Erwartetes Resultat

Tatsächliches Resultat



Admin-Tool starten und mit einem Benutzername und Passwort mit Administratorrechten anmelden

Admin-Tool ist gestartet und ein Admin ist eingeloggt

Tool gestartet



Wähle den User «Vergesslich, Hans» aus und wähle «Passwort zurücksetzen»

Passwort zurücksetzen Fenster erscheint

Fenster Passwort zurücksetzen erscheint



Setze ein neues Passwort und Speichere es

Neues Passwort ist gesetzt.

Passwort erfolgreich zurückgesetzt



Logge dich in der Applikation mit dem User «Vergesslich, Hans» und dem soeben gesetzten Passwort ein

Login war erfolgreich.

Login war erfolgreich



Der Gesamttest ist:



Datum der Prüfung: 1. Januar 2000

Prüfer: Max Muster                        Beurteilung: Maximilia Meier

  [Unterschrift]                                        [Unterschrift]



In der Risikoanalyse sollten alle bekannten Probleme bewertet werden. Bei Software, welche mit dem Zweck des Einsatzes in regulierter Umgebung vertrieben wird, wird oft auch eine entsprechende Liste der bekannten Anomalien veröffentlicht. Hier lohnt es sich auf der Support-Webseite vom Hersteller nachzusehen oder den Support zu kontaktieren. Neben den Problemen die dem Hersteller bekannt sind, sind auch Unzulänglichkeiten wie fehlende Features zu bewerten. Ist ein Risiko nicht akzeptabel, müssen Kontrollmassnahmen definiert werden, um das Risiko zu reduzieren. Als Medizingerätehersteller, welche sich an Risikomanagement nach ISO 14971 gewöhnt sind, empfehlen wir, dabei dem gleichen Prozess zu folgen.


Software Validierungsbericht

Der Software Validierungsreport sollte folgende Elemente enthalten:

  1. Identifikation der Software und Umgebung
  2. Testbericht(e) oder Verweis(e) darauf
  3. Risikomanagementbericht über die bekannten Anomalien der Software
  4. Nachweis, dass alle Anforderungen geprüft wurden. Dies lässt sich am einfachsten über eine Traceability Matrix abbilden.
  5. Formelle Bewertung und Freigabe der Software zur Nutzung

Hinweis: Für «kleinere» Applikationen, kann möglicherweise Testreport, Risikoanalyse und Validierungsbericht auch in einem Dokument erstellt werden.


Identifikation der Software und Umgebung, Testbericht

Oft gibt es für die Software eine Matrix der validierten Versionen und Umgebungen, dann sollte diese im Validierungsbericht entsprechend abgebildet werden:


Software Version

Windows 10, 32 bit

Windows 10, 64 bit

V1.0.1, Build


Bericht 1.pdf

V1.0.1, Build

Bericht 2.pdf

Bericht 3.pdf


Risikomanagementbericht über die bekannten Anomalien der Software

Der Validierungsbericht soll weiter das Restrisiko welche durch die Nutzung dieser Software entsteht bewerten. Insbesondere liegt hier der Fokus auf der Akzeptabilität der bekannten Anomalien und/oder fehlenden Funktionen.



Ein weiterer Aspekt den es abzudecken gibt, ist nachzuweisen dass alle Anforderungen an die Software getestet wurden. Je nach Umfang der Anforderungen und der Dokumentation der Tests haben sich zwei Möglichkeiten herausgeschält dies zu dokumentieren:


Vorwärts-Verlinkung der Anforderungen zu den Tests

Die Anforderungstabelle wird um eine Spalte ergänzt, wo die Anforderung geprüft wird:




Getestet in


Der Serveradministrator möchte Passwörter zurücksetzen können um Nutzern die Ihr Passwort vergessen

TC 1-4


Der Benutzer möchte das erst teilweise ausgefüllte Formular speichern um nach einem Unterbruch weiter arbeiten zu können.

TC 5-8

Diese Variante eignet sich vor allem bei kleinem Umfang an Anforderungen und wenn die gesamte Validierung in einem Dokument erstellt wird.



Bei umfangreichen Anforderungsdokumenten oder wenn die Testdurchführung ihre eigenen ID’s besitzt, empfiehlt es sich eine Traceability Matrix zu erstellen, welche die Anforderungen der Testspezifikation und eventuell dem Testbericht gegenüberstellt:
























Sollen mehrere Berichte für verschiedene Laufzeitumgebungen und Softwareversionen abgebildet werden müssen, so kann dies in einer Traceability Matrix sehr einfach durch zusätzliche Spalten abgebildet werden.


Formelle Bewertung und Freigabe

Zu guter Letzt soll das Gesamtpaket der Dokumentation bewertet und mit einem Entscheid der Freigabe dokumentiert werden.



Bildlich dargestellt, ist die Validierung der Software im Qualitätsmanagementsystem nichts anderes, als die Systematische, dokumentierte Durchführung der linken und rechten, oberen Ecken des in der Softwareentwicklung weit verbreiteten V-Modells:

Dazu gehören:



Für medizinische Systeme mit sicherheitskritischen Anforderungen, wie z.B. Patientenüberwachungssysteme oder Beatmungsgeräte, ist die Dokumentation von System- und Software-Architekturen explizit erforderlich. Ergänzend muss ein Nachweis erfolgen, dass eine Architektur auch gemäss Ihrer Definition umgesetzt ist. Aber auch ausserhalb des regulierten Bereiches ist die sorgfältige Beschreibung einer Architektur für die meisten Anwendungen sinnvoll, denn die Beschreibung einer Architektur ist nicht nur ein Nachweis der Erfüllung von Anforderungen, sondern hilft auch, Fehler in der Spezifikation frühzeitig zu erkennen. Dieser Artikel zeigt, mit welchen (Hilfs-)Mitteln eine Architektur beschrieben werden kann und woran man sich dabei halten kann.


Beschreibung von Architekturen

Wie im Artikel über System- und Software-Architektur erläutert, ist die Architektur eines Systems «die Menge von Strukturen, welche benötigt werden, um auf das System schliessen zu können, respektive, um sicherzustellen, dass das System die geforderten Eigenschaften erfüllt. »

Zugegeben, diese Definition ist ziemlich abstrakt und zeigt keinen konkreten Bezug zu Hardware, Elektronik oder Software. Ein System besteht aber aus verschiedenen Strukturen wie Software, Elektronik oder Mechanik. Zusätzlich kann sich ein System auch durch logische Strukturen oder zeitlich aufeinanderfolgende Vorgänge charakterisieren. In diesem Sinne kann der Begriff «Die Architektur» irreführend sein, da die Singularität des Begriffes Architektur suggerieren könnte, dass eine Architektur aus einem einzigen Bild besteht. Die Praxis zeigt aber, dass ein System aus vielen unterschiedlichen Ansichten (Views) betrachtet und demnach auch beschrieben werden muss. Beispielsweise kann ein System in logische Einheiten und Funktionen unterteilt werden, die nicht unbedingt mit der physikalischen Aufteilung übereinstimmen. Dies kann anhand des folgenden, stark vereinfachten, Beispiels gezeigt werden:  

Abbildung 1: Logische und physikalische Sicht einer Client-Server-Anwendung sowie ein zugehöriges Szenario, um die Ansichten zu verbinden.


Aber welche ist die richtige oder beste, und vor allem von Regularien anerkannte Ansicht?

Eine Architekturbeschreibung besteht in der Regel genau darin, unterschiedlichen Ansichten aufzuzeigen, Verbindungen zwischen den Ansichten herzustellen und das Erfüllen von unterschiedlichen Anforderungen deutlich zu machen. Insofern besteht die Beschreibung einer Architektur aus mehreren Ansichten, welche unterschiedliche Aspekte beleuchten. Das heisst, es gibt nicht die einzig wahre Ansicht, sondern die Beschreibung einer Architektur berücksichtigt unterschiedliche Ansichten gleichwertig[1].


Ansichten einer Architektur

Die Ansichten sind ein wesentlicher Bestandteil des internationalen ISO/IEC/IEEE 42010-Standards [link to], welcher eine Leitlinie bietet, wie die Architektur eines Systems zu beschreiben ist. Dieser Standard wurde 2011 veröffentlicht und ist das Resultat einer gemeinsamen ISO- und IEEE-Überarbeitung des früheren (stark Software-geprägten) IEEE 1471-Standards [link to]. Der ursprüngliche IEEE 1471-Standard spezifizierte, wie die Architektur eines Systems zu beschreiben ist. Weitere Anforderungen wie der Aufbau einer Architektur sowie Anforderungen an die Beschreibungssprache wurden in 42010 ergänzt. Der Standard erfordert jedoch keine spezifische Architekturbeschreibung oder Beschreibungssprache. Stattdessen sollte die Praxis der Beschreibung einer Architektur standardisiert werden.

Ansichten (engl. Views) sollen ein System abbilden, indem sie auf Basis definierter Standpunkte die Anforderungen (Concerns) der Stakeholder berücksichtigen. Abbildung 2 zeigt, wie Ansichten, Standpunkte, Anforderungen und Stakeholder zusammenhängen.

Abbildung 2: Abhängigkeiten zwischen Ansichten, Standpunkten, Anforderungen und Stakeholdern in Anlehnung an den ISO 42010- Standard


Für die Erstellung einer Architekturbeschreibung hat sich folgender Prozess etabliert, welcher stark an den ISO 42010-Standard angelehnt ist:

  1. Identifikation der Stakeholder
  2. Identifikation der Belange / Anforderungen an die Beschreibung
  3. Definition der passenden Standpunkte (Viewpoints)
  4. Erstellung der Ansichten, basierend auf den Standpunkten
  5. Verifikation der Architektur mittels Szenarien, wobei die Schritte 4 und 5 iterativ erfolgen.

Die einzelnen Schritte werden in den folgenden Kapiteln näher beschrieben.


Identifikation der Stakeholder

Damit die Standpunkte gezielt und vor allem systematisch definiert werden können, sollen in einem ersten Schritt die Stakeholder identifiziert werden, welche mit und für das System arbeiten oder Entscheidungen über das System treffen. Das können unter anderem Entwickler, Produkt-Manager, Risk-Manager, Endanwender, Produktionsmitarbeiter, Projekt-Manager usw. sein.

Identifikation der Belange und Anforderungen

Auf der Basis der identifizierten Stakeholder sollen deren Anforderungen an die Architekturbeschreibung erfasst und dokumentiert werden. Ergänzend zum Kontext-Interview mit den Stakeholdern können Hinweise zu Anforderungen an die Architekturdokumentation auch in den User- oder System-Requirements zu finden sein. Tabelle 1 zeigt, wie dies am Beispiel von Abbildung 1 aussehen könnte.



Erwartungen an die Architektur (Concerns)


Definition der Zielsystem(e)

Definition der Schnittstellen


Erwartet Skalierbarkeit

Nachweis zur Ausfall-Sicherheit

Datenschutz Verantwortlicher

Nachweis für den Datenschutz

Tabelle 1: Identifikation von Stakeholdern und Erwartungen an die System-Architektur


Definition der passenden Standpunkte

Der Standpunkt charakterisiert sich durch eine Menge von Anforderungen der entsprechenden Stakeholder sowie durch unterschiedliche Konventionen hinsichtlich Modell-Typen, Notationen sowie Techniken für die darauf aufbauenden Ansichten. Die Standpunkte können wie im Beispiel von Tabelle 2 definiert werden. Ergänzend zu der tabellarischen Aufführung müssen die entsprechenden Notationen definiert werden. Dies kann entweder in jeder Ansicht separat, oder, im Sinne des 42010-Standards, in einem separaten Standpunkt-spezifischen Abschnitt erfolgen.



Adressierte Themen


Analyse Techniken



Hierarchisches Dekompositions-Diagramm mit der Beschreibung aller Schnittstellen.






Hierarchisches Dekompositions-Diagramm mit der Beschreibung aller Schnittstellen.


Fehlerbaum Analyse




Tabellarische Auflistung der Datenverarbeitungsprozesse mit Sensitivitäts-Klassifikation und Verwendungszweck.


Tabelle 2: Definition der Standpunkte


Definition eines Standpunktes

Ein Standpunkt ist eine Art Vorlage, welche über mehrere Systeme (wieder-)verwendet werden kann und/oder unter Architekten austauschbar ist. Eine solche Vorlage wird dann verwendet um auf deren Basis systemspezifische Ansichten zu erstellen. Eine bekannte Sammlung von Standpunkten ist das «4+1 view model» von Kruchen oder das arc42 template, welche insbesondere in Software-Systemen Anwendung finden. Die Verwendung von Standpunkten ist aber nicht nur auf Software-Architekturen limitiert, sie können auf beliebige Systeme angewendet werden.

Die Definition und Wahl der Standpunkte werden primär durch die Belange der identifizierten Stakeholder festgelegt. In den nachfolgenden Kapiteln stellen wir drei mögliche Standpunkte vor, wobei diese Zusammenstellung nicht für jedes System anwendbar ist.

Generell empfiehlt es sich, die Anzahl der verwendeten auf ein sinnvolles Minimum zu beschränken, da Redundanzen mit jedem zusätzlichen steigen. Ausserdem muss jede Ansicht, welche aus den Standpunkten erstellt wird, über den Projektverlauf gepflegt, nachgeführt und vor allem konsistent gehalten werden. Der resultierende Aufwand nimmt mit der Anzahl der Standpunkte und den erstellten Ansichten zu. Unter der Voraussetzung, dass die Standpunkte und deren Ansichten den Nachweis der Anforderungen ermöglichen, ist also in diesem Fall weniger mehr.

Der logische Standpunkt

Der logische Standpunkt wird für Geräte, bestehend aus Hard- und Software, häufig als (primären) Standpunkt verwendet. Dabei wird das System in seine logischen Einzelteile zerlegt und angeordnet. In den daraus erstellten Ansichten können insbesondere funktionale Anforderungen den Komponenten zugeordnet und mögliche funktionale Redundanzen innerhalb des Systems identifiziert werden. Eine explizite Zuordnung der Systemanforderungen ist sinnvoll, da dadurch die Rückverfolgbarkeit (Traceability) gewährleistet wird. Insbesondere für sicherheitskritische Systeme ist ein Nachweis der Rückverfolgbarkeit erforderlich. Dies gilt nicht nur für System-Architekturen, sondern auch für Subsystem- und Software-Architekturen.

Kommunikationswege und zeitliche Abfolgen/Abhängigkeiten können, je nach Architektursprache, ebenfalls innerhalb der logischen Ansicht definiert werden. Da die logische Aufteilung und die dazugehörigen Prozesse eine sehr starke Abhängigkeit haben, bietet sich eine Kombination an. Alternativ können die Prozesse in einer dedizierten Sicht dargestellt werden, wobei für diesen Fall das Design von logischer Sicht und Prozess-Sicht üblicherweise iterativ erfolgt.

Der physikalische Standpunkt

Gleichwertig zum logischen Standpunkt können unterschiedliche physikalische Standpunkte die Beschreibung und das Verständnis des Systems erweitern. Physikalische Standpunkte können beispielsweise elektronische, pneumatische oder elektromechanische Ansichten sein, welche je nach Anforderungen an das System sinnvoll sind. Auch für verteilte Software-Systeme kann ein physikalischer Standpunkt Sinn machen, in der die Umsetzung von nicht-funktionalen Anforderungen wie Skalierbarkeit, Verfügbarkeit oder Performance aufgezeigt werden kann.

Der Entwicklungs-Standpunkt

Eine häufig nur implizit durchgeführte, aber für einen reibungslosen Projektablauf sehr wichtiger Standpunkt, ist die Entwicklungssicht. Dabei wird aufgezeigt, wie das zu entwickelnde System in kleine Arbeitspakete aufgeteilt werden kann, um diese den einzelnen Entwicklern oder Entwicklungs-Teams zuzuweisen. Damit können nicht nur interne Anforderungen wie beispielsweise Wiederverwendbarkeit oder die Auswahl der Entwicklungs-Tools berücksichtigt werden, sondern eine solche Ansicht ermöglicht auch die Überwachung der Entwicklungskosten und Termine im Verlauf des Projektes. Die Entwicklungssicht ist häufig nicht Bestandteil der formalen System-Architektur, sondern wird im Rahmen der Projektplanung erstellt.


Verifikation der Architektur

Ein beliebtes Instrument zwecks Verifikation einer Architektur ist das Durchspielen von Szenarien. Dabei werden in Abhängigkeit von den Anforderungen die wichtigsten Schlüssel-Szenarien definiert. Ein Szenario ist keine eigene Ansicht, sondern baut auf bestehenden Ansichten auf, indem es diese in Verbindung bringt. Demnach ist eine vollständige Architekturbeschreibung die Grundlage für die Verifikation, respektive, die Szenarien können nur durchgespielt werden, sofern die Architektur vollständig beschrieben ist. Analog zur Beschreibung der logischen oder physikalischen Ansichten, wird der Ablauf des Szenarios in der Form eines Diagramms dargestellt. Häufig werden dazu Objekt-Interaktions-Diagramme verwendet um die Interaktion zwischen den logischen und/oder physikalischen Elementen darzustellen (siehe dazu auch Abbildung 1). Solche Szenarien dienen nicht nur der Verifikation einer Architektur, sondern helfen auch, den Aufbau eines Systems zu verstehen.



Häufig sind unterschiedliche Stakeholder involviert, welche unterschiedliche Anforderungen an ein System stellen. Damit diese Anliegen gezielt adressiert und deren Erfüllung nachgewiesen werden kann, bedarf es zur Beschreibung einer Architektur mehrerer Ansichten. Diese Ansichten können von generell definierten Standpunkten abgeleitet werden. Die Standpunkte bestehen aus allgemein anwendbaren Konventionen und sind somit über mehrere Systeme hinweg austausch- und wiederverwendbar. Abschliessend zur Architekturbeschreibung kann diese mit Hilfe von Szenarien verifiziert werden, um die Erfüllung der wichtigsten Anforderungen nachzuweisen.

[1] Grundsätzliches Prinzip (II) der ISO 42010 [ref to 42010]


«System-Design», «System-Architektur», «Software-Architektur», was steckt genau hinter diesen Begriffen? Was ist damit gemeint? Was sind die Definitionen? Warum ist es wichtig diese Begriffe zu unterscheiden?

Mit Antworten auf diese Fragen beschäftigt sich dieser Artikel.


Das System

Wir beschäftigen uns hier mit technischen Systemen. Noch etwas spezifischer mit Embedded Systemen. Ein Embedded System, auf Deutsch ein «eingebettetes System» ist wie folgt definiert:

«Ein eingebettetes System ist ein elektronischer Rechner oder auch Computer, der in einen technischen Kontext eingebunden (eingebettet) ist. Dabei übernimmt der Rechner entweder Überwachungs-, Steuerungs- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.»


Quelle: Wikipedia

Ganz ähnlich diese Definition (Quelle


«Ein eingebettetes System ist ein binärwertiges digitales System (auch Computersystem genannt), das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht. Dabei übernimmt der Rechner meist Überwachungs-, Steuerungs- oder Regelungsfunktionen, ist oft aber auch für eine Form der Daten- bzw. Signalverarbeitung zuständig.»

Diese Definitionen können mit dem folgenden Diagramm verdeutlicht werden:

Abbildung 1: Allgemeines Embedded System mit der gewünschten Funktion / Verantwortung umgeben von externen Systemen und einem oder mehrere Benutzer.


Der Einfachheitshalber wird meist einfach von dem „System“ gesprochen mit welchem man sich befasst. Auch im Rest dieses Artikels wird häufig nur noch von „System“ gesprochen und meint damit das entsprechende technische oder eben das Embedded System.


Architektur & Design

Um die Begriffe zu erklären, muss aufgezeigt werden, wie ein solches System gebaut wird. Abbildung 1 stellt das Embedded System als Blackbox dar. Der Aufbau des Systems ist noch nicht definiert. Es muss definiert werden aus welchen Bestandteilen das System aufgebaut werden soll. Diese Tätigkeit nennt man «Design». Bei einem «System-Design» geht es also um die Definition und Festlegung des Systemaufbaus. Das Resultat einer solchen Design-Tätigkeit könnte dann basierend auf dem Diagramm (Abbildung 2) wie folgt aussehen:

Abbildung 2: Resultat (Architektur) der ersten Design Iteration zur Definition der Bestandteile (Architekturelemente).


Meist läuft eine solche Design-Tätigkeit iterativ ab. Das heisst die Bestandteile – man spricht hier von Architekturelementen – werden soweit zerlegt (engl. «decompose»), bis diese genügend definiert sind. Erst dann kann die Erstellung (Entwicklung) des Systems beginnen.

Das Resultat dieser Design-Aktivität nenn man «Architektur». Die Abbildung 2 ist also eine erste «System-Architektur» (genau genommen ist die Abbildung 2 eine Referenzarchitektur eines allgemeinen Embedded System). Wobei der Begriff Architektur in diesem Zusammenhang noch genauer definiert werden muss. Es gibt nicht eine einzige etablierte Definition des Architektur-Begriffes. Eine Sammlung von Definitionen findet man hier: Dies sind zwar Definitionen für Software-Architektur, gelten jedoch auch für den System-Architektur Begriff. Die Unterscheidung liegt im Anwendungsbereich (engl. Scope) –  dazu aber weiter unten noch mehr.

Wir verwenden die folgende Definition des Architektur-Begriffes (aus «Software Architecture in Practice – Third Edition»):


Definition (Software-) Architektur

“The (software) architecture of a system is the set of structures needed to reason about the system, which comprise (software) elements, relations among them, and properties of both.”

Übersetzt sind darin die folgenden 3 Sätze enthalten:

  1. Die Architektur eines Systems ist aus einer Menge von Strukturen aufgebaut.
  2. Es sind die Strukturen, welche benötig werden, um auf das System schliessen zu können.
  3. Die Strukturen umfassen die Elemente, deren Beziehungen und deren Eigenschaften.

Was bedeutet das nun?

Die Strukturen bestehen aus Elementen, deren Beziehungen und deren Eigenschaften. Architektur besteht aus den Strukturen, welche benötigt werden, um sicherzustellen, dass sich das System wie gefordert verhält. Wobei hier nicht nur die Erfüllung der funktionalen Anforderungen gemeint ist, sondern auch der ganze Bereich der nicht-funktionalen Anforderungen. Beispielsweise haben Forderungen bezüglich Weiterentwickelbarkeit meist Einfluss auf die Struktur des Systems. Es gehören jedoch nicht alle Strukturen eines Systems zur Architektur. Nicht alle Strukturen sind Architektur-relevant. Man spricht bei diesen Strukturen dann nicht mehr von Architektur, sondern von Design.

«Design» ist einerseits die Tätigkeit, welche zu einer Architektur führt (siehe weiter oben), als auch der Begriff für sämtliche nicht Architektur-relevanten Resultate aus der Design Tätigkeit.

Viele Definitionen machen sich das einfacher, indem sie ausführen, die Grobstruktur oder die früh im Design Prozess definierten Strukturen sind Architektur. Alle späteren oder detaillierteren Strukturen sind Design. Diese Definitionen sind allerdings unzureichend, da durchaus detailliertere Strukturen notwendig sein können, um die geforderten Anforderungen zu erfüllen. Auch wird in einer agilen Entwicklung nicht alles Relevante schon früh im Design Prozess definiert.

System versus Software

Zuletzt noch die Unterscheidung zwischen «System-Architektur» und «Software-Architektur»: Wie bereits weiter oben aufgeführt unterscheiden sich diese im Anwendungsbereich (Scope). Die System-Architektur umfasst die Strukturen von verschiedenen System-Elementen, wie Hardware, Software, Mechanik. Die Software-Architektur hingegen umfasst die Strukturen, welche den Aufbau eines Software-Elementes (ein Element aus der System-Architektur) definieren. Dies ist in den nachfolgenden Diagrammen ersichtlich:

Abbildung 3: System Architektur Diagramm mit Hardware und Software Elementen.


Bei der weiterführenden Zerlegung eines Software Elementes landen wir schlussendlich bei der Software Architektur:

Abbildung 4: Software Architektur Diagramm des Software Elementes «Control Software».



In der nachfolgenden Tabelle sind die wichtigsten Begriffe und deren Bedeutung resp. Definitionen nochmals zusammenfassend aufgeführt: 


Bedeutung, Definition

Embedded System

Ein Embedded System (deutsch: eingebettetes System) ist ein elektronischer Rechner oder Computer, der eine definierte Funktion ausführt und eingebunden in einer physikalischen Umgebung ist. Optional von anderen Umsystemen umgeben ist sowie optional eine Benutzerschnittstelle aufweist.

Design (Tätigkeit)

Ist die Tätigkeit, welche definiert wie ein System aus mehreren Bestandteilen (Architekturelementen) aufgebaut ist.

System-Design (Tätigkeit)

Siehe «Design» – mit der Präzisierung, dass es sich um das Design eines Systems d.h. um verschieden Elemente wir Hardware, Software, Mechanik handelt.

Software-Design (Tätigkeit)

Siehe «Design» – mit der Präzisierung, dass es sich um das Design einer Software (eines Software-Elementes) handelt.

Die Architektur

Die Architektur eines Systems ist die Menge von Strukturen, welche benötig werden, um auf das System schliessen zu können, resp., um sicherzustellen, dass das System die geforderten Eigenschaften erfüllt. Die Strukturen umfassen die Elemente, deren Beziehungen und deren Eigenschaften.

Das Design

Die Strukturen, welche neben den architekturrelevanten Strukturen (siehe «Architektur») zwar auch den Aufbau des Systems definieren, für die geforderten Systemeigenschaften allerdings nicht relevant sind.

Die System-Architektur

Siehe «Architektur» – mit der Präzisierung, dass es sich um das Design eines Systems d.h. um verschieden Elemente wir Hardware, Software, Mechanik handelt.

Die Software-Architektur

Siehe «Architektur» – mit der Präzisierung, dass es sich um das Design einer Software (eines Software-Elementes) handelt.

Tab. 1: Begriffe und deren Bedeutung resp. Definition



Nutzen Sie unsere 30-Tage-Testversion


Gewerbestrasse 8  |  9470 Buchs  |  Schweiz  |  Tel. +41 81 750 06 40  |  Email


DATAFLOW Software AG Gewerbestrasse 8 9470 Buchs Schweiz E-Mail:
Vertretungsberechtigte Person(en)
Christian Büchel, CEO
Eingetragener Firmenname: DATAFLOW Software AG Handelsregister Nr: CHE-190.688.043 Mehrwertsteuer-Nummer CHE-190.688.043
Der Autor übernimmt keinerlei Gewähr hinsichtlich der inhaltlichen Richtigkeit, Genauigkeit, Aktualität, Zuverlässigkeit und Vollständigkeit der Informationen. Haftungsansprüche gegen den Autor wegen Schäden materieller oder immaterieller Art, welche aus dem Zugriff oder der Nutzung bzw. Nichtnutzung der veröffentlichten Informationen, durch Missbrauch der Verbindung oder durch technische Störungen entstanden sind, werden ausgeschlossen. Alle Angebote sind unverbindlich. Der Autor behält es sich ausdrücklich vor, Teile der Seiten oder das gesamte Angebot ohne besondere Ankündigung zu verändern, zu ergänzen, zu löschen oder die Veröffentlichung zeitweise oder endgültig einzustellen.
Haftungsausschluss für Links
Verweise und Links auf Webseiten Dritter liegen ausserhalb unseres Verantwortungsbereichs. Es wird jegliche Verantwortung für solche Webseiten abgelehnt. Der Zugriff und die Nutzung solcher Webseiten erfolgen auf eigene Gefahr des jeweiligen Nutzers.
Die Urheber- und alle anderen Rechte an Inhalten, Bildern, Fotos oder anderen Dateien auf dieser Website, gehören ausschliesslich der Firma DATAFLOW Software AG oder den speziell genannten Rechteinhabern. Für die Reproduktion jeglicher Elemente ist die schriftliche Zustimmung des Urheberrechtsträgers im Voraus einzuholen.
Quelle: SwissAnwalt

Vielen Dank!

Wir wünschen Ihnen viel Spass mit DATAFLOW Software


Gewerbestrasse 8  |  9470 Buchs  |  Schweiz  |  Tel. +41 81 750 06 40  |  Email