Software Entwicklung macht Spaß! Welches Software Entwicklerteam freut sich nicht, eine herausfordernde Kundenanfrage schnell in eine spannende Lösung umzusetzen und einen ersten Prototypen zu präsentieren. Dagegen ist jede Motivation eines Entwicklerteams ganz schnell dahin, wenn man sagt, dass ein Projekt im Wasserfallmodell in den nächsten 2 Jahren umgesetzt wird und dass in der ersten Phase erstmal alle Requirements erfasst werden. Im folgendem Beitrag wird mit dem umgedrehten V-Modell mal ein Perspektivwechsel angeregt, mit dem Ziel den praktischen Nutzen des Requirement Engineering in den Projekten deutlich zu erhöhen.
Strukturelle Source Code Überdeckung: Sie arbeiten in Software Projekten in denen das Thema Funktionale Sicherheit immer wichtiger wird? Die Anwendung von IEC 61508, ISO 26262 oder einer vergleichbaren Norm steht vor der Tür oder Sie befinden sich bereits mitten in so einem Projekt? In diesen Fällen ist Ihnen vermutlich der Begriff Strukturelle Source Code Coverage auch schon begegnet. Viele setzen die Erreichung der strukturellen Coverage oft gleich mit sehr hohem Testaufwand und sie bezweifeln, ob bei diesem Thema Kosten und Nutzen in einem angemessenen Verhältnis stehen. Weiterlesen
Die Durchführung einer Daten- und Kontrollflussanalyse wird in fast allen funktionalen Sicherheitsstandards gefordert. Im Vergleich zu anderen Methoden und Maßnahmen, fristet die Daten- und Kontrollflussanalyse aber eher ein Schattendasein. Der Grund liegt vor allem auch darin, dass bisher die technologischen Fähigkeiten zur Durchführung einer solchen Analyse gefehlt haben.
Die non-intrusive Systembeobachtungstechnologie der Firma Accemic (www.accemic.de) bietet nun die Möglichkeit die Daten- und Kontrollflüsse durch Tests nachzuweisen. Dadurch wiederum wird es möglich die funktionale Vollständigkeit der Requirements systematisch zu überprüfen. Weiterlesen
Die Messung der strukturellen Source Code Coverage ist heutzutage in vielen Funktionalen Sicherheitsstandards als ein wichtiges Verfahren definiert. Die Non-intrusive Messung der strukturellen Coverage bietet hier zukünftig ganz neue Möglichkeiten. Lange Zeit war es industrieweiter Konsense dass die strukturelle Coverage nur in sogenannten White-Box-Tests ermittelt werden sollte und konnte. In vielen Lehrbüchern wird die Messung der strukturellen Source Code Coverage sogar als eigenständige Testmethode angepriesen. Im nachfolgenden Blogbeitrag wird aufgezeigt, warum sich hier zukünftig einiges ändern dürfte. Weiterlesen
Viele verbinden mit der Umsetzung von Funktionaler Sicherheit, viel Formalismus, und unnötig umfangreiche Dokumentation und viele Prozesse mit einem hohen Anteil an theoretischen Überbau. Und ja es gibt solche Projekte sehr oft und in jeder Industrie. Ich habe die Erfahrung gesammelt das solche Projekte oft aber nicht besonders effizient sind, wenn man sie an der echten Umsetzung von wirksamen Sicherheitsmaßnahmen misst. Der nachfolgende Blogbeitrag geht der Frage nach, warum das so ist? Zudem ist der Beitrag ein Plädoyer für eine pragmatische Softwareentwicklung in Projekten der Funktionalen Sicherheit. Weiterlesen
Der Compiler ist DAS zentrales „Tool“, welches man in jeden Software Produktentwicklung benötigt. Er bildet das Bindeglied zwischen der vom Menschen gut lesbaren Hochsprache (z.B. C und C++) und dem für den Hardwareprozessor interpretierbaren Maschinencode. Für die Entwicklung sicherheitsrelevanter Software nach entsprechenden Funktionalen Sicherheitsstandards wie ISO26262 (Auto), EN50128 (Bahn), IEC61508 (Automatisierung, Allgemein) oder DO178C (Luftfahrt) gelten für die während der Entwicklung verwendete Tools besondere Anforderungen (siehe Blogbeiträge zur Toolqualifikation aus 2016: Blog 1; Blog 2). Der Compiler spielt hier eine Sonderrolle. Einerseits ist er das zentrale Tool jeder Entwicklung, andererseits sind die in den Normen vorgeschlagenen Maßnahmen in der Praxis für Ihn nur bedingt anwendbar. Der Blog zeigt einen Prozess aus der Luftfahrt für die Compilerverifikation/-validation auf, der auch für andere Industrien sehr zu empfehlen ist. Weiterlesen
Im letzten Blogbeitrag (Juni 2017) habe ich das Prinzip der Rückwirkungsfreiheit erklärt. Das verwendete Beispiel bezog sich dabei auf die Automobilbranche und die ISO26262.
Nun möchte ich das Thema branchenübergreifend (Bahn, Luftfahrt, Automobil) betrachten und meine Erfahrungen aus der Projektpraxis mit Ihnen teilen. Weiterlesen
Die 100%ige strukturelle Source Code Überdeckung wird ja inzwischen von fast allen Normen (IEC61508, ISO26262, DO 178C etc.) der Funktionalen Sicherheit eindeutig gefordert. Unterschieden wird in den einzelnen SIL/ASIL Leveln nur noch die Art der Source Code Coverage. Weiterlesen
IEC 61508, ISO26262, DO 178C, ISO 25119: Sind Ihnen diese Kürzel schon mal in Ihrem beruflichen Alltag begegnet? Falls ja, dann ist die Wahrscheinlichkeit hoch, dass Sie Funktionale Sicherheitsprojekte bereits in Ihrem Unternehmen durchführen oder dass Sie in näherer Zukunft in diesen Markt einsteigen werden.
Vielleicht haben Sie auch schon selbst die Erfahrung gemacht, bzw. zumindest davon gehört, dass insbesondere Software Projekte im Umfeld der Funktionalen Sicherheit nur mit sehr hohem Dokumentations- / Testaufwand durchführbar sind. Noch dazu sind solche Projekte sehr starr, ineffizient und unflexibel.
Kommt Ihnen eine solche Argumentation oder Erfahrung bekannt vor?
Insbesondere für Sie, aber auch für alle Anderen, möchte ich in diesem Blog aufzeigen das dies nicht so sein muss. Im Gegenteil, ich möchte Sie ermuntern dass Sie sinnlose Dinge aus Ihrem Entwicklungsprozess streichen und dafür eine für in sich schlüssige, auf Ingenieursprinzipien beruhende Vorgehensweise wählen. Weiterlesen
Die Wichtigkeit der Toolqualifikation habe ich im ersten Teil (Link) grundsätzlich 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
