Software Tools Qualifizierung - Qualitätssicherung in der Softwareentwicklung und im Softwaretest

Zusammen mit der Norm DO-178 C für Software in der Luftfahrt wurde die DO-330 entwickelt, welche sich speziell auf Softwarewerkzeuge bezieht, die für die Entwicklung oder Prüfung dieser verwendet werden sollen. Sie wurde aus der DO-178 ausgegliedert, damit die Norm auch auf andere Software-Bereiche angewendet werden kann.

Für die Software werden verschiedene Tool Qualification Criteria (TQC) definiert, um die anzuwendenden Tool Qualification Level (TQL) zu bestimmen.
Unter Criteria 1 fallen Werkzeuge, deren Ausgabe Teil der Luftfahrtsoftware ist und damit Fehler einfügen könnten. Bspw. Compiler. Hier sind TQL-1 bis 4 anzuwenden je nach Software Level aus DO 178.
Unter Criteria 2 fallen Werkzeuge, die Teil der SW-Prüfung sind und damit SW-Fehler verdecken oder übergehen könnten und ggf. damit dazu beitragen weitere nötige Prüfschritte auszulassen. Bspw. Prüfsoftware für Regressionstest. Dabei gelten TQL-4 bis 5 je nach SW Level.
Unter Criteria 3 fallen Werkzeuge, die SW-Prüfungen übernehmen und mögliche Fehler nicht entdecken. Bspw. Statische Code Analyse, Unit-Test-Software. Hier ist TQL-5 anwendbar.
Dabei gilt der letzte Nebensatz von Criteria 2 immer als entscheidend, ob eine Software unter 2 oder 3 fällt. Das höhere TQL ist dabei immer zu verwenden, je höher das Software Level eingestuft ist, also wie die Auswirkungen bei einem Fehler sein können, von katastrophal bis ohne Auswirkung.

TQL-5 fordert in etwa:
* Anforderungsdefinition (TOR)
* Werkzeug Informationssammlung
* Konfigurationsmanagement
* Qualifikationsplanung
* Tool Qualifikation mit Verifikation und Validierung
* Standard Qualitätssicherung
TQL-4 fordert zusätzlich:
* Anforderungsmanagement
* Qualifikations Plan, Entwicklungsplan, Konfigurationsmanagement Plan, Qualitätsmanagement Plan
* Geeigneter SW-Entwicklungsprozess
* TOR nachweislich erfüllt
TQL-3 fordert zusätzlich:
* Eigene Anforderungs-, Design- und Coding-Standards die nachweislich erfüllt werden.
* Erweitertes Anforderungsmanagement mit abgeleiteten Anforderungen für Module und Komponenten.
* Die Anwendung des Werkzeuges ist beschrieben und der Prozess dokumentiert.
* Erweitertes Konfigurationsmanagement, welches die Entwicklungsumgebung einschließt.
* Anforderungsbasiertes Test Management und komplette TOR-Anforderungsabdeckung und 100% Source Code Statement Coverage.
TQL-2 fordert zusätzlich:
* Unabhängige Werkzeugverifikation.
* Externe Werkzeuganalyse und -definition.
* Werkzeug Source Code Verifikation.
* Verifikation von Low-Level-Requirements und 100% Decision Coverage.
TQL-1 fordert zusätzlich:
* Externe Qualifikation und Freigabe der Werkzeuge.
* Verifikation externer Komponenten (z.B. SW-Umgebung usw.).
* 100% MCDC Coverage.

In der Regel gehören zum Prozess ein Softwarebenutzer und ein SW-Hersteller oder -Entwickler. Ersterer plant die Software Tools Qualifizierung, identifiziert die Werkzeuge und deren Einfluss durch die Nutzung, legt die Werkzeuganforderungen fest um die Qualifikation durchzuführen zu können. Letzterer beschreibt den Entwicklungsprozess (Mindestforderungen an Nachweise und Lifecycle, wie z.B. Servicehistorie und bekannte Fehler usw. beachten!) und damit die Eignung für die Anwendung nach Tool Operational Requirements (TOR, "Benutzeranforderungen" für Einsatzzweck, Schnittstellen und Einsatzumgebung).
Anschließend muss die Integration der SW in die SW-Umgebung geprüft werden, damit hier keine Probleme(Betriebssystem, externe Komponenten) auftreten. Ist dies bestanden, muss die Software so eingestellt werden, dass möglichst wenig Einfluss genommen wird und mögliche Fehler vermieden und reduziert werden. Deterministische Tools sind hier absolut zu bevorzugen, nichtdeterministische führen zu erheblichem Mehraufwand bei der Qualifizierung bis hin zur Unzulässigkeit der Nutzung!
Erst jetzt kann mit der geplanten Qualifizierung der Software (Reviews, Analyse, Funktionstests, Inputs, Outputs, Schnittstellen, Robustheitstests, möglichst große Testabdeckung) begonnen werden.
Des Weiteren muss noch unterschieden werden, ob die Software für sich oder in einem Framework (z.B. Continuous Integration, Toolchains), z.B. zur Automatisierung zum Einsatz kommt. In letzterem Fall muss anschließend noch das komplette Framework genauso qualifiziert werden.

COTS Software oder bereits eingesetzte oder zertifizierte Software macht die Qualifizierung natürlich leichter, da hier bereits meist brauchbare Nachweise beim Hersteller zu finden sind. Es ist aber zu beachten, dass solche Tools ggf. nicht die TOR erfüllen und damit auch solche Tools nicht ohne Nachweis der Eignung eingesetzt werden dürfen! Die Qualifizierung gilt also nur für das jeweilige spezifizierte System. Maximal der Aufwand für die Nachweise reduzieren sich.
Eine gerne verwendete Methode ist die "Proven in use", in dem argumentiert wird, dass andere oder man selber das Werkzeug schon lange einsetzt und noch keine Probleme hat. DO-330 kennt diese Methode nicht an.

Zu einer SW Tools Qualifizierung gehören allgemein also:
* Spezifizierte Anforderungen für jedes Werkzeug.
* Eine übersichtliche spezifische Werkzeugliste mit Informationen nach einer Analyse rund um das Werkzeug: Funktion, Einsatz, Hersteller, Version, (interne) Bezugsquellen, Ansprechpartner, begründete Einstufungen nach Norm, vorhandene Dokumentation, Qualifikationsdokumentation, Status Freigabe, Fehlerdokumentation, Einschränkungen, usw.
* Eine nachweisbar geeigneter SW-Entwicklungsprozess (mind. gleiches Level wie die entstehende Software) und wenn vorhanden Entwicklungsdokumente (Architektur etc.).
* Lifecycle Pflege und auswertbare Daten über Servicehistorie und bekannte Fehler und Probleme.
* Alle Werkzeuge und deren Umgebung werden unter Konfigurationsmanagement gestellt.
* Ein Qualifizierungsplan für die Werkzeuge.
* Vorbereiten des Werkzeugs, um möglichst wenig eigenen Einfluss auf das Resultat zu nehmen und um mögliche Fehler von Anbeginn zu vermeiden oder zu reduzieren.
* Eine nachweisbare umfängliche Qualifizierung des Werkzeugs im angedachten Einsatzbereich.
* Eine dokumentierte Freigabe für den spezifischen Einsatz mit Anforderungsabdeckung und Zusammenfassung der Qualifikation.
* Eine Dokumentation über Vorfälle während des Einsatzes und ggf. Kontakt zum Hersteller.

Meine Empfehlungen:
* Verwende zertifizierte Software und Standardsoftware wo möglich. Eigenentwicklungen nur wenns nicht anders geht.
* Führe Übersichten ein, dokumentiere die Software und ihren Lebenszyklus.
* Arbeite nach State-of-the-art Prozessen, wie wenn du "normale" qualitative Software entwickeln und qualifizieren würdest.
* Reduziere die Komplexität und Vielfalt wo möglich: Software, deren verwendete Funktion und Umgebungen usw.
* Nur absolut notwendige und bewährte SW-Updates zulassen, denn dann muss die Qualifizierung wiederholt werden.

Das alles hört sich sehr aufwändig und kompliziert an, man sollte sich allerdings nicht abschrecken lassen, denn wenn man gewohnt ist nach Prozessen zu arbeiten, dann ist auch so eine Tool Qualifikation für Criteria 2 und 3 nicht mehr Arbeit als auch sonst vorgesehen. Erst bei TQL-1 bis 3 steigen die Anforderungen merkbar an.