Eine fehlerfreie Software gibt es nicht! Trotzdem wird Software erfolgreich auch in sehr kritischen Systemen eingesetzt. Die Software Entwicklungsprozesse sind aber inzwischen so ausgereift, daß es möglich ist die Fehleranzahl in der Software verlässlich so weit zu reduzieren, dass die Anzahl von Systemfehlern welche Ihre Ursache in der Software haben, so selten geworden sind, dass Sie von der Gesellschaft akzeptiert werden. In diesen sicherheitsrelevanten Projekten werden vor allem spezifikationsbasierten, effizienzbasierten und struktur-basierten Testentwurfsverfahren verwendet. Risikobasiertes Testen spielt in diesem Bereich bisher keine nennenswerte Rolle. Andererseits steigt die Komplexität und der Umfang von Software auch im sicherheitsrelevanten Bereich stark an. Trends wie Industrie 4.0 und autonomes Fahren fördern diese Entwicklung stark. Unter welchen Bedingungen könnte risikobasiertes Testen im sicherheitsrelevanten Bereich zukünftig eine größere Rolle spielen? Wie kann dieses Testentwurfsverfahren verbessert werden, damit die Methode an sich eine weitere Verbreitung finden kann? Der folgende Blogbeitrag diskutiert die Stärken und Schwächen des risikobasierten Testens und erstellt Möglichkeiten vor um die Methode an sich zu verbessern. Einen Überblick über gängige Testentwurfsverfahren finden sich imBeitrag Gegenüberstellung und Bewertung von verschiedenen Testentwurfsverfahren.
Weiterlesen
Schlagwortarchiv für: Test
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
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
Qualität kostet Geld! Viele können vermutlich diesem Statement zustimmen. Das Statement wird sich auch kaum widerlegen lassen – schon deswegen nicht, weil es sehr allgemein formuliert ist.
Bezogen auf den Software Entwicklungsprozess wird aber oft der sehr vereinfachte Schluss gezogen, dass jede Maßnahme der Qualitätssicherung einfach nur teuer ist.
Ich möchte im nachfolgenden Blog einmal etwas genauer hinschauen und das Review von Requirements aus wirtschaftlicher Sicht betrachten. Lohnen sich Requirements Reviews, so wie sie in allen Standards der Funktionalen Sicherheit gefordert werden, aus wirtschaftlicher Sicht?
„Zeit ist Geld“ ist hier zunächst einmal das Motto, d.h. im ersten Schritt müssen wir überlegen, wie lange das Review eines Requirements im Durchschnitt dauert. Nun, ich gehe davon aus, dass Sie lieber Leser, hier durchaus sehr unterschiedliche Erfahrungen gemacht haben. Ich werde nachfolgend versuchen, trotzdem einen Wert herzuleiten. Weiterlesen
ISO 26262 kalibrierbare Software: Der Anhang C der ISO 26262 beschäftigt sich mit konfigurierbarer Software. Dieser Blog fasst wichtige Anforderungen der Norm an Konfigurierbare/kalibrierbare Software nach ISO26262 zusammen und zeigt praxisrelevante Herausforderungen von Software-konfigurierbaren Embedded Systemen auf.
Zunächst einmal bietet die Verwendung von Kalibrierdaten in konfigurierbaren Systemen nur Vorteile. Das funktionale Verhalten des Gesamtsystems, kann durch einfache und schnelle Änderungen in den Kalibrierdaten an das jeweils gewünschte Verhalten angepasst werden, ohne das der Source Code, bzw. dessen Struktur angepasst werden müssen. Dadurch wird eine mehrfache Wiederverwendung des Source Codes ermöglicht. Wenn es gut gemacht ist, sollten sogar die Unit Tests inklusive des Nachweises der strukturellen Source Coverage weitgehend wiederverwendbar sein. Dies sind durchaus gewichtige Vorteile. Weiterlesen
Managementaspekte des Testens : Validation und Verifikation von Embedded Systemen begleitet mich bereits mein ganzes Berufsleben lang. Oft ist das ja eher ein lästiges Thema – die Zeit ist knapp, die Anzahl der zu bewältigenden Tests, Review und Analysen ist hoch. Die Mitarbeiter sind für das Thema nicht wirklich zu motivieren. Die technischen Ressourcen sind nicht ausreichend. Aus Sicht des Managements steht das zu erwartende Ergebnis schon vorher fest: keine Fehler! Kennen Sie diese Situation, so oder so ähnlich? Als Testmanager in solch einem Projekt hat man es wahrlich nicht immer leicht. Weiterlesen
