Implicit Testing – A good idea (Part 1)?

In larger safety-critical projects, quite often I hear the following statement: „Well, the Requirement A is indirectly or implicitly proven with the test XY!“ Do you know this sentence as well? Have you ever experienced what can happen in late project phases when you have tested many requirements indirectly?
The blog defines the term in part 1 and it discusses the causes of implicit testing.
Weiterlesen

Implizites Testen – Eine gute Idee (Teil 1)?

In größeren sicherheitskritischen Projekten begegnet mir immer wieder mal der Ausspruch: „Naja, das Requirement A wird mit dem Test XY indirekt oder implizit nachgewiesen!“. Ist Ihnen das auch schon mal passiert? Haben Sie auch schon mal erlebt, was in späten Projektphasen passieren kann, wenn man viele Requirements indirekt getestet hat?
Der Blog definiert im Teil 1 den Begriff und er beleuchtet die Ursachen des Impliziten Testens. Weiterlesen

User Stories – The better Requirements?

The book „User Stories“ from Mike Cohn (ISBN 978-0321205681) has inspired me to think about the relationship between user stories and requirements. In software development, agile methods are often preferred in recent years. The classic approaches, especially the waterfall model and the V-model, seem to be more and more outdated.
As a result, user stories are preferred more and more. Do user stories really help to deliver better software quality? Weiterlesen

User Stories – Die besseren Requirements?

Das Buch „User Stories“ von Mike Cohn (ISBN 978-3-8266-5898-3) hat mich inspiriert, einmal mehr über den Bezug zwischen User Stories und Requirements nachzudenken. In der Software Entwicklung werden agile Methoden in den letzten Jahren oft bevorzugt eingesetzt. Die klassischen Vorgehensweisen, insbesondere das Wasserfallmodell und auch das V-Modell, scheinen etwas aus der „Mode“ zu kommen.
Konsequenter Weise werden damit User Stories gegenüber den „klassischen“ Requirements auch bevorzugt eingesetzt. Helfen die User Stories aber wirklich, bessere Software Qualität abzuliefern? Gibt es nicht auch viele Aspekte, bei denen es gar keine Unterschiede gibt?
Weiterlesen

IEC61508: Specification – Architecture – Requirements; Is there any difference?

For an increasing number of systems in the industrial automation functional safety requirements must be fulfilled. The IEC61508 compliance must be demonstrated for the software development.
On the other hand, there are commercial requirements which often severely limit the product development budget.
The solution lies in an efficient development process that meets the safety-relevant requirements. A prerequisite for a successful implementation of such a process is a deep understanding of the standard and a clear definition of used terms. In the following blog, I discuss the three terms specification, architecture and requirements.
Weiterlesen

IEC61508: Spezifikation – Architektur – Requirements; Gibt’s da Unterschiede?

Für immer mehr Systeme, gerade auch in der Industrieautomatisierung, müssen Forderungen der Funktionalen Sicherheit erfüllt werden. Für die Software Entwicklung ist dann in der Regel die Erfüllung der IEC61508 nachzuweisen.
Auf der anderen Seite stehen kommerzielle Anforderungen an das Produkt, welche das Entwicklungsbudget oft erheblich einschränken.
Die Lösung liegt dann in einem effizienten Entwicklungsprozess, der die sicherheits-relevanten Forderungen erfüllt. Eine Voraussetzung für eine erfolgreiche Umsetzung eines solchen Prozesses ist ein tiefgehendes Verständnis der Norm und eine klare Definition und gegenseitige Abgrenzung von Begriffen. Im nachfolgenden Blog beschäftige ich mich mit den drei Begriffen Spezifikation – Architektur – Requirements. Weiterlesen

Tool qualification – The phantom pain of functional safety (part 2)!

In the first part (Link) I explained the basic idea, which is behind the tool qualification. I have already given an overview of the four most frequently used measures.
In this article, I will discuss each of these 4 measures in more detail and name the respective advantages and disadvantages. Weiterlesen

Toolqualifikation der Phantomschmerz der Funktionalen Sicherheit (Teil2)!

Im ersten Teil (Link) habe ich den Grundgedanken, der hinter der Toolqualifikation steckt erklärt. Ebenso habe ich bereits einen Überblick über die 4 am häufigsten angewendeten Maßnahmen gegeben.
In diesem Beitrag möchte ich nun jede dieser 4 Maßnahmen genauer vorstellen und die jeweiligen Vor- und Nachteile benennen. Weiterlesen

Tool Qualification – The phantom pain of functional safety (part 1)!

Many companies and project teams that carry out projects for the first time in the field of functional safety have the impression that the topic of tool qualification is critical to success and involves a great deal of effort. Although this issue is, of course, important and also involves a certain cost effort, the subject is interestingly often given an not adequate attention.
This effect is very similar in several, very different industries such as aerospace, automotive or industrial automation.
The following article therefore deals with this topic.
Weiterlesen

Toolqualifikation – Der Phantomschmerz der Funktionalen Sicherheit (Teil 1)!

Viele Firmen und Projektteams die erstmals Projekte im Umfeld der Funktionalen Sicherheit durchführen, haben den Eindruck, dass das Thema Toolqualifikation erfolgskritisch ist und mit hohem Aufwand verbunden ist. Obwohl dieses Thema natürlich wichtig ist und auch einen gewissen Kostenaufwand mit sich bringt, wird dem Thema interessanterweise oft eine nicht angemessene Aufmerksamkeit geschenkt.
Dieser Effekt ist in mehreren, sehr unterschiedlichen Branchen wie Luftfahrt, Automotive oder Industrieautomatisierung sehr ähnlich.
Der nachfolgende Artikel beschäftigt sich daher mit diesem Thema etwas näher. Weiterlesen