Kategorien: Software & IEC 62304
Tags:

10 Kommentare

  1. Adrian Wyssmann | Mittwoch, 18. November 2015 um 11:30 Uhr - Antworten

    Die FDA fordert ja die Möglichkeit einer unabhängigen Bestätigung des Resultats “ factual records documenting the result of an examination, which support the pass/fail conclusion in an unambiguous and understandable manner, and which allow for independent confirmation of the result“

    Heisst das nicht auch, dass man in der Lage sein muss, zu zeigen was der Test gemacht hat. Bei manuellen Tests ist das ja einfach, indem man die Test Schritte und Resultate auf Papier bringt (PDF). Wie kann man dasselbe für Automatisierte tests erreichen?

    Für mich ist die Dokumentation eines automatisierten Tests der Test Code selbst, entsprechend würde ich den Source Code archivieren so dass ich jederzeit darauf zugreifen und zeigen kann was der Test gemacht hat.

    Wie sehen Sie dass?


    • Christian Johner | Mittwoch, 18. November 2015 um 18:23 Uhr - Antworten

      Absolut, das sollte man zeigen können. Bei automatisierten Tests sind die Schritte einschließlich der pass/fail-Krititerien im Source-Code. Das sehe ich genau wie Sie. Daher sollte der Test-Code unbedingt der gleichen Dokumentenlenkung unterworfen sein wie der Programm-Code und die Testergebnisse.


  2. Felix Klöckner | Freitag, 28. Dezember 2018 um 17:26 Uhr - Antworten

    Sie weisen darauf hin, dass es aus aus normativer Sicht nicht ausreichend ist nur Unit-Tests (aus Entwickler-Sicht, weisse Kästchen) durchzuführen, sondern dass die Software-Einheiten (Units im normativen Sinne, rote Kästchen) explizit getestet werden müssen.
    Im folgenden Artikel gehen Sie jedoch nicht weiter darauf ein, wie mit den „Entwickler-Tests“ zu verfahren ist. Ich stelle mir daher folgende Frage:
    Einige Entwickler-Tests entstehen klar Bottom-Up, ergeben sich also aus der Art und Weise wie eine Funktionalität umgesetzt wurde, also aus dem Aufbau der weissen Kästchen. Is es ausreichend, wenn die „Anforderungen“ an diese Tests nur implizit innerhalb der (automatisierten) Tests beschrieben sind? D.h., dass hierzu keine getraceten Requirements vorhanden sind? So lassen sich wirkliche Requirements an die Software, also solche bis auf Ebene der normativen Units, von „Erwartungshaltungen“ der Entwickler trennen.
    Lassen sich solche „Entwickler-Tests“ für die Code-Coverage heranziehen?


    • Prof. Dr. Christian Johner | Freitag, 28. Dezember 2018 um 17:32 Uhr - Antworten

      Sehr geehrter Herr Klöckner,

      danke für die wichtige Frage!

      Ich würde Sie sehr ermutigen, die „Entwicklertests“ weiter durchzuführen. Die Anforderungen, die Sie damit abtesten sind im Testcode enthalten. D.h. Sie müssen keine Requirements für jedes weiße Kästchen formulieren.

      Meine Aussage war vielmehr, dass Sie auch und aus regulatorischer Sicht v.a. die roten Kästchen testen.

      Sie dürfen durchaus den Code-Coverage der Entwickler-Tests heranziehen. Das würde ich auch empfehlen, weil dieser Coverage-Grad i.d.R. auch viel höher und aussagekräftiger ist.

      Viele Grüße, Christian Johner


  3. Tayfur Coskun | Mittwoch, 16. September 2020 um 09:40 Uhr - Antworten

    Vielen Dank für die sehr hilfreichen Informationen. In unserem SW Entwicklungsprozess verwenden wir die Software Requirement Specification für die Anfordeurngen an das SW System. Die Software Design Specification bildet das Design und das detaillierte Design wieder. Im Augenblick brechen wir die Anforderungen auf SRS Ebene (Ebene 0 – SW System-Ebene) auf Ebene 1 (Software Design Ebene – Wir nennen die Items auf dieser Ebene Komponenten) runter, und die Anforderungen brechen wir weiter runter auf Ebene 2 (Software detailled design – Hier sind unsere 62304 UNITs).

    Auf diese Weise bekommen wir auch die Akzeptanzkriterien für unsere UNITs. Das heißt, wir definieren auf jeder Ebene unsere Software Architektur formale Anforderungen die auch formal geprüft werden, samt Test-Spezifikation, Testprotokoll und Traceability-Matrix.

    Inzwischen bin ich aber der Meinung, dass die 62304 dieses runterbrechen von Anforderungen gar nicht verlangt, sondern lediglich das Runterbrechen (Dekomposition ) der Architektur und eine Architektur-Traceability.

    Jetzt möchte ich gerne die Anfroderungen aus unserem SDS komplett entfernen, so dass es endlich ein reines Design-Output Dokument wird und nicht selbst wieder neue Anforderungen definiert und die Akzeptanzkriterien auf andere Art und Weise definieren (Generell: Code-Reviews, static code analysis, Entwickler-Unit-Tests + Funktional: Prüfen der Anwendbarkeit der Anforderungen die in der 62304 5.5.4 angegeben sind).

    Jetzt bin ich aber ins Zweifeln gekommen, ob das richtig ist was ich vor habe, weil ich in diesem Artikel gelesen habe: „Generell sollten die Akzeptanzkritieren von Unit-Tests die in der Software-Architektur spezifizierten Anforderungen sein“

    Jetzt war ich eigentlich sicher, dass in die Software Architektur keine Anforderungen rein gehören, damit es ein klares Design-Output Dokument ist. Könnten sie zu dem Punkt ein paar Worte sagen: Software Architektur – Anforderungen ja oder nein?

    Danke im voraus,
    Beste Grüße,
    Ty-4


    • Prof. Dr. Christian Johner | Mittwoch, 16. September 2020 um 19:42 Uhr - Antworten

      Sehr geehrter Herr Ty-4,

      danke für Ihre ausführliche Schilderung!

      Eine Software-Architektur ist (u.a.) die Zerlegung eines Software-Systems in Komponenten und eine Spezifikation der Schnittstellen dazwischen.

      Jede Spezifikation einer Schnittstelle (einer Komponente) ist eine Beschreibung, wie sich die Software-Komponente über diese Schnittstelle verhalten soll. Und diese Beschreibung entspricht Anforderungen — allerdings an eine Komponente und nicht mehr an das Software-System insgesamt.

      Bei den Komponententests (z.B. Unit-Tests) prüfen Sie, ob sich die Software gemäß dieser Spezifikationen verhält. D.h. Sie testen ob die Komponente die Komponentenanforderungen erfüllt.

      Damit setzt eine Software-Architektur die Software-Anforderungen d.h. die Anforderungen an ein Software-System in eine Aufteilung des Systems in Komponenten und in eine Anforderungen an diese Komponenten um.

      Hilft das ein wenig? Falls nicht, haken Sie gerne nach.

      Viele Grüße, Christian Johner


  4. Tayfur Coskun | Freitag, 18. September 2020 um 15:56 Uhr - Antworten

    Vielen Dank für die schnelle Antwort!

    Ja, sie hilft auf jeden Fall schon mal weiter. Demnach ist die Antwort auf die Frage: Ja, in der SW Architektur werden Anforderungen definiert, die von den Software System Anforderungen abgeleitet werden.

    Allerdings widerspricht das der Trennung zwischen Design Input und Design Output. Wenn mich heute jemand fragt was unser SDS eigentlich in dem Sinne ist, muss ich antworten: „Beides, es ist der Design-Output für das Software System (SRS) und der Design-Input für unser Source-Code. Würden sie das auch so interpretieren?

    Wenn ich im Web z.B. nach Templates für die 62304 suche, ist es immer so, dass im SRS-Template Beispiele für Anforderungen drin stehen. Im zugehörigen SDS allerdings werden an der Stelle wo Komponenten oder UNITS definiert werden nur die Anforderungen aus dem SRS erwähnt, die von der Komponente oder UNIT erfüllt werden. Es tauchen keine neuen Anforderungen auf. Gerne kann ich ihnen per E-Mail mal solche Templates schicken, und die Stellen die meine markieren?


    • Prof. Dr. Christian Johner | Samstag, 19. September 2020 um 14:51 Uhr - Antworten

      Sehr geehrter Herr Ty-4,

      sowohl die SW-Architektur als auch die darin identifizierten Anforderungen an die Komponenten sind Design-Output. Damit gibt es keinen Widerspruch.

      Die Trennung von Design-Input und Design-Output bezüglich der Anforderungen bestenfalls auf Ebene des Produkts, aber nicht auf Ebene der Komponenten.

      Wenn es keine Komponenten-Anforderungen gäbe, könnten Sie keine Unit-Tests entwickeln. Denn diese müssen genau diese Anforderungen abprüfen.

      Diese Ableitung von Produkt-Anforderungen aus Stakeholder-Anforderungen, von Komponenten- (z.B. PESS) Anforderungen aus Produkt-(z.B. PEMS) Anforderungen, von Software-Anforderungen aus PESS-Anforderungen, von Unit-Anforderungen aus Software-Anforderungen muss im „vertikalen Tracing“ erkennbar sein. Beispielsweise die IEC 60601-1 beschreibt das sogar explizit z.B. in Bild H2.

      Beste Grüße, Christian Johner


  5. Tayfur Coskun | Montag, 21. September 2020 um 12:26 Uhr - Antworten

    Alles klar. Dann werde ich meine Bemühungen an der Stelle die Anforderungen aus dem SDS zu nehmen und einen anderen Weg für die Akzeptanzkriterien zu finden erst mal einstellen. Vielen Dank wie immer für die schnellen Rückmeldungen.


  6. Andreas Simons | Samstag, 3. April 2021 um 14:00 Uhr - Antworten

    Hallo Herr Johner,

    ich habe gerade mit sehr großem Interesse diesen spannenden Dialog gelesen, da ich an einer verwandten Fragestellung feststecke und etwas den Verdacht habe, dass ich ein paar Aspekte bisher falsch interpretiert haben könnte:

    1. Auch ich war bisher der Annahme, dass es sich bei den Anforderungen (unabhängig, ob sie gegen das (SW) System auf oberstem Level oder – auf tieferem Level – gegen eine SW Unit formuliert sind, um Design Input im Sinne der FDA handelt. Das würde aus meiner Sicht zu einer Art rekursivem Zick-Zack-Pattern führen, bei dem z.B. „System Design“ als Design Output auf dem System Level zu Design Input für die Sub-Systeme auf der nächst tieferen Systemhierarchieebene (z.B. für SW Items oder Units) wird. Auf der unteren Hierarchieebene würde dann wiederum Design Output „als Antwort“ auf diesen Design Input entstehen.

    2. Da die FDA grundsätzlich eine formale Traceability von Design Input zu Design Output und zur Verifikation fordert, bin ich davon ausgegangen, das sich auch diese Forderung auch „entlang der (SW-)Systemdekomposition“ bis auf die kleinste Zerlegungsebene fortsetzt. Was bedeuten würde, dass alle Dokumentationselemente von Design Input über Design Output bis zu deren Verifikation eindeutig auf allen Zerlegungsebenen identifizier- und zuordenbar sein müssten.

    Wenn ich mir Ihre Erklärungen in diesem Thread und allgemein zur 62304 und der Verifikation von SW Items/Units anschaue, dann gewinne ich den Eindruck, dass meine Interpretation etwas über das Ziel hinausschießt, was vermutlich auf Missverständnissen meinerseits beruht. Meine Frage an der Stelle:

    Wenn es auf Komponenten-Level (z.B. für SW Units) eigentlich nur noch Design Ouput und keine Design Input gibt, muss ich jedes Design Output Element auf SW Unit Level eindeutig identifizierbar machen und zu jedem solchen Element (direkte) formale Traceability zu einem Test Case auf SW Unit Level herstellen, der diese Design Entscheidung verifiziert? Das wirkt etwas merkwürdig, weil man ja eigentlich gegen Design Input verifiziert und nicht gegen Design Output?

    Oder wäre der richtige Ansatz, dass man nur per Design Review verifiziert, dass die dokumentierten Design Entscheidungen (also der Design Output) den Anforderungen auf der Design Input Seite folgen?

    Die Durchführung von SW Unit Test würde man dann nur als „allgemeines“ Akzeptanzkriterium definieren (z.B. mit einer Anforderung an die erwartete Code Coverage und einem formalen Review, dass die Tests das Gesamtdesign auch abdecken), ohne dass man hier für jeden Unit Test explizite und granulare Traceability herstellt.


Hinterlassen Sie einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.