Blogs in Deutsch

Rückwirkungsfreiheit – Die gelebte Praxis!
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 ->

ISO26262: Rückwirkungsfreiheit – Was ist das?
Es gibt 4 wesentliche Maßnahmen in der Entwicklung sicherheits relevanter Systeme.

  • Design von Systemen von denen keine Gefahr ausgeht
  • Maßnahmen zur Minimierung von zufälligen Hardwarefehlern
  • Maßnahmen zur Minimierung von systematischen Hardware und Softwarefehlern
  • Organisatorische Maßnahmen (Management der Funktionalen Sicherheit)

Insbesondere beim Design von Systemen von denen keine Gefahr ausgeht, kommt immer wieder das Prinzip der Rückwirkungsfreiheit (=Freedom of Interference) zur Anwendung. Was ist das? Wie wird es in der Praxis angewendet? Der nachfolgende Blogbeitrag liefert Antworten auf diese Fragen. Weiterlesen ->

Herausforderungen bei der Ermittlung der strukturellen Source Code Coverage auf dem Target!
Der Nachweis einer 100% strukturellen Source Code Coverage 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 ->

Guter Safety Software Entwicklungsprozess – Was ist das?
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 ->

Implizites Testen – Eine gute Idee (Teil 2)?
Im ersten Teil des Blogs habe ich den Begriff „Implizites Testen“ definiert und Ursachen dafür diskutiert.
Im zweiten Teil geht es nun um die Nachteile solcher Tests und um Lösungsansätze um möglichst diese Nachteile gar nicht erst entstehen zu lassen. 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 – 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: 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 ->

Toolqualifikation – Der Phantomschmerz der Funktionalen Sicherheit (Teil 2)!
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 ->

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->

Requirement/Code Reviews – Das bessere TDD?
Wenn es in den Entwicklungsprojekten mit Requirements mühsam wird, wird Test Driven Development (TDD) oft als die Lösung propagiert. Ist das wirklich die Lösung? Falls ja, warum hat sich TDD bis heute nicht wirklich flächendeckend in der Softwareentwicklung durchgesetzt? Im Folgenden möchte ich meine Gedanken dazu darlegen. Weiterlesen ->

Requirements Reviews aus wirtschaftlicher Sicht betrachtet!
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? Weiterlesen ->

Strukturelle Source Code Coverage und Requirements – Gibt’s da einen Zusammenhang?
Wenn Sie neu in dem Bereich der Funktionalen Sicherheit tätig sind, dann werden Ihnen die Begriffe strukturelle Source Code Coverage und Requirements ziemlich schnell begegnen. Die Spezifikation von technischen Systemen mittels Requirements ist natürlich auch im nicht sicherheitskritischen Bereich sehr verbreitet. Dagegen spielt das Thema strukturelle Source Code Coverage außerhalb der Sicherheitstechnik praktisch keine Rolle.
In diesem Blog möchte ich mich mit diesen beiden Begriffen und den dahinter stehenden Prozesse beschäftigen. Insbesondere die Frage nach der gegenseitigen Abhängigkeit ist spannend. Weiterlesen ->

Security – Ein Begriff, viele Bedeutungen!
Die Varianz der Begriffsbedeutungen fängt schon bei der Übersetzung vom Deutschen ins Englische an.
Der Begriff „Sicherheit“ im Deutschen kann sowohl als „Safety“ als auch als „Security“ übersetzt werden. Im Deutschen gibt es nur einen Begriff für zwei, doch sehr unterschiedliche, Dinge.
Wenn man nun aber einen Schritt weitergeht und Security Themen genauer betrachtet, stellt man plötzlich fest, dass es hier sehr lohnenswert sein, kann die einzelnen Dinge auseinander zu halten. Das Wichtigste ist, sich bewusst zu werden, dass diese Abgrenzungen der einzelnen Themen eine absolute Voraussetzung sind, um Security als Ganzes und in jedem Teilgebiet angemessen zu behandeln. Dieses Bewusstsein zu schaffen ist Ziel dieses Blogbeitrags. Weiterlesen ->

 

DO-178B/C, ISO26262, IEC61508: Wieviel Ebenen von Software Requirements dürfen es denn sein, bitte?
In meinen täglichen Projekten in der Automobilbranche und der Automatisierungstechnik treffe ich immer wieder auf die Frage, wie viele Ebenen von Software Requirements denn nun geschrieben werden müssen. Das ist eine spannende Frage, insbesondere wenn man viel Erfahrung mit Luftfahrtprojekten hat.
Daher möchte ich in diesem Blogbeitrag dieses Thema einmal etwas näher beleuchten. Zunächst möchte ich die Vorgaben der FuSi-Standards IEC 61508, ISO 26262 und DO-178B/C vergleichen. Abschließend gebe ich noch Projekterfahrungshinweise, die auf meiner mehr als 15 jährigen Erfahrung beruhen. Weiterlesen ->

ISO26262: konfigurierbare/kalibrierbare Software – Chance oder Risiko?
Der Anhang C der ISO 26262 beschäftigt sich mit konfigurierbarer Software. Dieser Blog fasst wichtige Anforderungen der Norm 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 ->

EN 50128: Konfigurierbare Systeme: Fluch oder Segen?
Kapitel 8 der EN 50128 beschreibt die Anforderungen an Systeme, die durch Anwendungsdaten oder Anwendungsalgorithmen konfiguriert werden. Dieser Blog fasst die wesentlichen Anforderungen der Norm zusammen und zeigt praxisrelevante Herausforderungen von Software-konfigurierbaren Embedded Systemen auf. Weiterlesen ->

FMEA – Eine mächtige Methode, aber nicht für Software!
In der Funktionalen Sicherheit gibt es eine Methode, die immer zum Einsatz kommt – die FMEA (Failure Mode Effects Analysis).
Insbesondere auf System- und Hardwareebene werden damit systematische Analysen unterstützt. Es gibt auch verschiedene Ausprägungen wie z.B. die FMECA und die FMEDA. In diesem Blogbeitrag verwende ich nur den Überbegriff FMEA.
In der Projektpraxis stellt sich oft die Frage, ob nicht auch auf Softwareebene eine FMEA Sinn macht und erstellt werden muss.
Weiterlesen ->

ISO26262: Fault Injection Test – Braucht man den wirklich?
Die ISO 26262 definiert als eine Test Methode jeweils auf System- Integrations- und Unit-Test Ebene den Fault Injection Test (ISO 26262-4 [System] Tabellen 5, 8, 10, 13, 15, 18; ISO 26262-5 [Hardware] Tabelle 11; ISO 26262-6 [Software] Tabellen 10, 13).
Diese Methode hat ganz sicher einen großen Anteil bei der Implementierung eines möglichst fehlerfreien und damit sicheren Systems. Mir geht es nachfolgend um eine möglichst effiziente Implementierung dieser Test Methode in der Praxis. Dabei möchte ich insbesondere die Vorgehensweisen in der Luftfahrt mit denen in der Automobilbranche vergleichen. Weiterlesen ->

Qualitätssicherung in FuSi-Projekten – Was ist anders?
Die Qualitätssicherung überprüft die Qualität des Produktes. Dies ist zunächst einmal eine geradezu triviale Feststellung. Je nach Definition des Begriffes „Produkt“ unterscheiden sich aber die Aufgaben deutlich. Geht es um die Überwachung eines Produktionsprozesses oder reden wir von der Sicherung der Qualität in einer Software und Elektronikentwicklung? Der nachfolgende Blog beschäftigt sich mit der Qualitätssicherung in der Entwicklung von Software und elektronischer Hardware. Es soll herausgearbeitet werden, wo der Unterschied bei der Qualitätssicherung von FuSi- und Nicht-FuSi-Projekten liegt. Weiterlesen ->

Sandburgen-Bauer oder -Zerstörer?

Welche Eigenschaften kennzeichnen gute Leute die im Testbereich arbeiten? Naja, man kann da einige Kriterien definieren: Fachliche Kompetenz und Methoden Know-How sind sicher unabdingbare Eigenschaften. Darüber hinaus müssen sie Managementfähigkeiten besitzen und Sozialkompetenz mitbringen. Das alles sind sicher notwendige Fähigkeiten. Es fehlt aber ein wichtiger Punkt, den ich in diesem Blog etwas näher beleuchten will: Weiterlesen->

Testen von Plattformen: Eine spannende Herausforderung!

Entwickeln Sie auch Plattformen in Embedded Systemen, um mehreren Kunden Lösungen anbieten zu können ohne für jedes Kundenprojekt eine komplette Neuentwicklung machen zu müssen?
Oder haben Sie vielleicht schon mal ein Embedded Betriebssystem eingesetzt, um möglichst unabhängig von der Hardware Ihre Applikation entwickeln zu können?
Für die Entwicklung der Systeme haben Sie vermutlich durch dieses Vorgehen profitiert, aber wie sah es bei der Verifikation bzw. beim Test aus? War es klar und einfach, die Plattform zu testen? War es einfach, eine vollständige Testabdeckung zu erzielen? Konnten Sie schnell und effizient gute Requirements erstellen? Nein? Dann sind Sie hier richtig! Weiterlesen ->

Managementaspekte in der Validation und Verifikation

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 ->

Re-Use Szenarien in ISO 26262 (Teil 2)

Nachdem der Darstellung der Vielfalt von verschiedenen Re-Use Szenarien im Teil 1, gehe ich nun auf konkreten Maßnahmen ein, die zum Einsatz kommen um den Re-Use von Software erfolgreich zu gestalten. Weiterlesen ->

Re-Use Szenarien in ISO 26262 (Teil 1)

Warum ist die Wiederverwendung von Software, Hardware oder kompletten Steuergeräten ein zentrales Thema? Zwei wesentliche Aspekte sind hier ausschlaggebend:
Die Entwicklungskosten können deutliche reduziert werden, d.h. die Wiederverwendung von Komponenten ist unter wirtschaftlichen Gesichtspunkten sehr attraktiv.

Aber auch aus Sicherheitsgründen, kann die Wiederverwendung von Komponenten deutliche Vorteile bieten. Ein Steuergerät, welches bereits seit Jahren im Feld eingesetzt wird und keine sicherheitsrelevanten Ausfälle zeigt, kann im Vergleich zu einer Neuentwicklung mit deutlich reduziertem Risiko eingesetzt werden.
Um aber diese Vorteile wirklich zur Geltung zu bringen, muss man sich der vielfältigen Re-Use-Szenarien insbesondere in der Automobilbranche bewusst sein. Als zweiten Schritt, muss man die Besonderheiten des zur Diskussion stehenden Wiederverwendungsszenarios identifizieren und entsprechende Maßnahmen ergreifen.
Der Blog teilt sich dabei in zwei Teile. Im ersten Teil geht es um Vielfalt möglicher Wiederverwendungsszenarien sowie die entsprechenden Anforderungen die sich aus der ISO 26262 ergeben. Im zweiten Teil des Blogs werden konkrete Maßnahmen für ausgewählte Re-Use-Szenarien diskutiert. Weiterlesen ->

EN 50128 – Funktionale Sicherheit in der Bahnindustrie

Die Standards EN50126, EN50128 EN50129 beschreiben die Funktionale Sicherheit in der Bahnindustrie. Diese Standards implementieren die IEC61508 für diese Industrie. Die Besonderheit der Bahnindustrie bezüglich der Funktionalen Sicherheit ist, dass die Systeme von einer Staatlichen Behörde (in Deutschland dem Eisenbahnbundesamt) überprüft werden bevor sie in Verkehr gebracht werden dürfen. Der Hersteller muss also den Nachweis der Einhaltung der Funktionalen Sicherheit schon während der Entwicklung des Produktes erbringen. In diesem Punkt sind sich die Luftfahrt und Bahnindustrie sehr ähnlich. Weiterlesen ->

Funktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 2)?

Im ersten Teil des Blog haben wir die Prinzipien der agilen Entwicklung und die der FuSi Entwicklung betrachtet. Darauf aufbauend, wollen wir nun im 2. Teil zum einen mögliche Konfliktfelder diskutieren, wenn man agil in FuSi Projekten entwickeln will. Ebenso beleuchten wir aber auch die Chancen die sich aus dieser innovativen Vorgehensweise ergeben können. Weiterlesen ->

Funktionale Sicherheit und agile Entwicklungsmethoden – Ein unüberbrückbarer Gegensatz (Teil 1)?

Als Motivation für den Beitrag dienen mir folgende Fragestellungen:

  1. Sie entwickeln nach agilen Methoden und müssen zukünftig Funktionale Sicherheitsanforderungen erfüllen? Unter welchen Voraussetzungen funktioniert das?
  2. Sie entwickeln sicherheitskritische Embedded Systeme in Branchen wie der Bahnindustrie, der Luftfahrt, der Automobilbranche, der Medizintechnik oder der Automatisierungstechnik. Ist es möglich in so einem Umfeld agile Entwicklungsmethoden einzusetzen?

Im ersten Teil dieses Blogs betrachten wir die jeweiligen Pole (Agile Entwicklung; FuSi Entwicklung) für sich. Im zweiten Teil diskutieren, wir, was zu beachten ist, wenn die beiden vermeintlich sehr getrennten Welten zusammengebracht werden sollen. Weiterlesen ->

Dokumentieren Sie noch oder spezifizieren Sie schon?

Sie wollen ein neues Projekt beginnen; In groben Zügen ist das zu entwickelnden Produkt auch schon festgelegt. Sie beschließen dass der Zeitpunkt gekommen ist, diese groben Ideen, Funktionen und Lösungsvorschläge zu strukturieren und aufzuschreiben. Diesen Zeitpunkt und die Fragen die sich nun stellen wollen wir nachfolgend etwas genauer beleuchten. Typische Fragen und Gedanken die Ihnen vielleicht jetzt durch den Kopf gehen könnten sind:

  • Schreibt man heutzutage noch Requirements in Textform?
  • Textuelle Requirements bedeuten schwere Prozesse, tausende Seiten geschriebener  Dokumente die sowieso niemand liest und versteht!
  • Ein Bild sagt mehr als 1000 Worte!  Weiterlesen ->

Die Herausforderung Nicht-Funktionale Requirements!

Meiner Beobachtung nach bekommt das Requirements Engineering im Allgemeinen nicht die angemessene Aufmerksamkeit. Wenn man Software und/oder Hardware Projekte betrachtet die Scheitern, ist ein fehlendes, oder falsches Requirements Engineering in vielen Fällen eine Hauptursache. Wenn man einen Schritt weiter geht und sich die Arten von möglichen Requirements betrachtet, dann kann man in einem ersten Schritt, ganz grob eine Einteilung in Funktionale und Nicht-funktionale Requirements vornehmen. Weiterlesen ->

Funktionale Sicherheit – Was ist das?

In den letzten gut 10 Jahren hat der Begriff Funktionale Sicherheit Einzug gehalten in viele Entwicklungsabteilungen. Dies geht einher mit der zunehmenden Verbreitung von elektronischen Systemen.
Für mechanische Geräte und Systeme gibt es Jahrzehnte an Erfahrungen, wie diese zu konstruieren und zu bauen sind, damit von Ihnen und Ihrer Funktion keine Gefahren für den Benutzer und dessen Umwelt ausgehen. Es gibt z.B. Vorschriften, welche mechanischen Schutzeinrichtungen angebracht werden müssen, damit ein Bediener einer Säge nicht mit den Fingern in das Sägeblatt gelangen kann. Weiterlesen ->

Kategorien von Requirements – Warum sind sie sinnvoll?

Wenn ich den aktuellen Stand des Requirements Engineering reflektiere, fallen mir folgende Punkte auf:

  1. Es gibt inzwischen eine Vielzahl guter Werkzeuge zur Dokumentation von Requirements
  2. Es gibt gute und etablierte Methoden zur Erstellung von natürlich sprachlichen Requirements
  3. Es gibt noch relativ wenig standardisierte Methoden zum richtigen Umgang mit immer wiederkehrenden Kategorien von Requirements

Ich möchte in diesem Blog-Beitrag insbesondere den letzten Punkt der Kategorisierung von Requirements beleuchten. Weiterlesen ->

Konfigurationsmanagement – Eine anspruchsvolle Aufgabe!

Kennen Sie die folgende Situation? Ein Software Projekt wird neu gestartet und die einzelnen Aufgaben werden im Projektteam verteilt. Irgendwann sind (fast) alle Rollen vergeben, allerdings hat niemand an das Konfigurationsmanagement gedacht. Diese Rolle wird dann noch schnell dem Projektleiter zugeteilt, den, so die Annahme, da ist eh nicht viel zu tun und daher kann der Projektleiter diesen Job noch leicht nebenbei erledigen. Weiterlesen->

Strukturelle Code Coverage – Sinnvoll oder Aufwand ohne Nutzen?

Sie arbeiten in Software Projekten in denen das Thema Funktionale Sicherheit immer wichtiger ist? 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 der strukturellen Source Code Coverage auch schon begegnet. Meiner Erfahrung nach wird die Erreichung der strukturellen Coverage oft gleichgesetzt mit sehr hohem Testaufwand und es wird des Öfteren bezweifelt ob bei diesem Thema Kosten und Nutzen in einem angemessenen Verhältnis stehen. Weiterlesen ->

Traceability – Aber bitte mit Köpfchen!

Standen Sie auch schon mal vor folgender Situation: Ihr sicherheitsgerichtetes Projekt steht kurz vor dem Abschluss, und Sie haben nahezu alle Teilprodukte untereinander in Beziehung gesetzt („verlinkt“). Es wurde erheblicher Aufwand in diese Tätigkeit gesteckt!
In einem Audit (z.B. interne QS, Kunde, Behörde) sollen Sie aufzeigen, welche Software Requirements sich aus welchen System Requirements herleiten. Jedes Software Requirement ist auf eines oder mehrere System Requirements verlinkt und auch jedes System Requirement ist auf ein oder mehrere Software- oder Hardware Requirements verlinkt. Weiterlesen ->
Blogverzeichnis - Bloggerei.de

Blogbox, bin drin

Ein Gedanke zu „Blogs in Deutsch

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.