Konfigurationsmanagement ist weit mehr als nur der Einsatz von Versionsverwaltungswerkzeugen wie git oder svn. Dies wird bei einem Blick in die IEC 62304 und die Guidance-Dokumente der FDA sofort klar.
Lesen Sie in diesem Artikel,
- was das Konfigurationsmanagement umfasst,
- welche regulatorischen Anforderungen an das Konfigurationsmanagement Sie beachten müssen und
- welche typischen Fehler beim Konfigurationsmanagement Sie vermeiden sollten.
1. Konfigurationsmanagement: Die Grundlagen
a) Was das Konfigurationsmanagement umfasst
Das Konfigurationsmanagement geht über das Versionsmanagement hinaus. Es beruht auf vier Säulen:
- Versionsmanagement
- Build-Management
- Change-Management
- Release-Management
b) Ziele des Konfigurationsmanagements
Die Ziele des Konfigurationsmanagements sind:
Veränderungen in ausgedehnten komplexen Systemen zu steuern, zu beherrschen und zu dokumentieren – und zwar über den gesamten Lebenszyklus
Dazu ist es erforderlich, Anpassungen, Korrekturen, Erweiterungen kontinuierlich zu lenken und zu kontrollieren. Das jeweilige System und seine sämtlichen Bestandteile sollen stets in einem klar definierten Zustand sein, der sich bis zu den Ursprüngen zurückverfolgen läßt.
Konfigurationsmanagement ist somit grundlegend für einen systematischen und jederzeit nachvollziehbaren Produktentwicklungsprozess.
c) Ziele des Konfigurationsmanagements in der Medizintechnik
Für Medizinproduktehersteller ist es das oberste Ziel, sichere Produkte zu entwickeln, welche den versprochenen Nutzen haben, also ihre Zweckbestimmung tatsächlich erfüllen.
Diese Ziele sind gefährdet, wenn Hersteller (insbesondere bei Software-basierten Medizinprodukten)
- falsche Artefakte ausliefern (z. B. eigene Software, Bibliotheken von Dritten),
- Artefakte oder Versionen dieser Artefakte verwechseln,
- Artefakte unvollständig ausliefern,
- die Software aus den Artefakten falsch zusammengesetzt haben,
- vergessen haben, einen Teil der Software zu prüfen und freizugeben,
- versehentlich bereits behobene Fehler wieder einführen,
- Produkte falsch konfigurieren (für gegebene Umgebung, für bestimmten Kunden),
- den Einfluss der Entwicklungs-, Build-, Test- und Produktionsumgebung auf das Produkt übersehen haben und über Änderungen nicht informiert waren (z. B. beim Kunden),
- weil ein Mitarbeiter etwas tat (Code änderte, Änderungen beantragte, Software auflieferte), wovon andere Mitarbeiter nichts wussten.
Das Ziel des Konfigurationsmanagements besteht darin, einen Beitrag zu leisten, die Komplexität zu beherrschen und die oben genannten Fehler zu vermeiden.
2. Elemente des Konfigurationsmanagements
a) Versionsmanagement
Das Versionsmanagement erfasst und verwaltet die Änderungen der sogenannten Konfigurationselemente. Damit kann man nachvollziehen, wer wann was und weshalb geändert hat.
Beispiele für Konfigurationselemente
- Eigener Source Code
- Fremdkomponenten (SOUP, OTS)
- Plattformen
- Werkzeuge
- Konfigurationseinstellungen (von Produkten, Werkzeugen, Umgebungen). Dazu zählen auch Build-Scripts und Konfigurationsdateien.
- Mediendateien (Bilder, Videos)
- Gebrauchsanweisungen
- Release-Notes
Erst die Versionsverwaltung (das Versionsmanagement) schafft die Grundlage dafür zu wissen, welches Artefakt in welcher Version Teil welcher Version des Produkts geworden ist.
Ohne ein Werkzeug müsste man diese Beziehungen von Hand (beispielsweise tabellarisch) verwalten:
| Produktversion 1 | Produktversion 1.1 | Produktversion 2 | |
|---|---|---|---|
| Datei 1 | Dateiversion 3 | Dateiversion 3 | Dateiversion 3 |
| Datei 2 | Dateiversion 1 | Dateiversion 9 | Dateiversion 11 |
| Datei 3 | Dateiversion 12 | Dateiversion 13 | Dateiversion 13 |
Entwicklungsdokumente wie Anforderungsspezifikationen, Architekturen und Testberichte müssen ebenfalls der Versionskontrolle unterliegen. Sie sind aber meist nicht Teil des ausgelieferten Produkts.
Auch die Laufzeitumgebung von Software und Build-Scripts unterliegen der Dokumentenlenkung, sind aber ebenfalls nicht Teil des Produkts.
b) Build-Management
Das Versionsmanagement reicht noch nicht aus, um bei gegebenen Ausgangsartefakten (z. B. Source-Code) das Produkt reproduzierbar zu erzeugen. So kann etwa die Reihenfolge, in der die Artefakte verarbeitet (z. B. Abhängigkeiten aufgelöst, kompiliert, generiert, zusammengesetzt) werden, eine Rolle spielen.
Produkte reproduzierbar, vollständig und fehlerfrei zu bauen, ist das Ziel des Build-Managements.
Bei tausenden und mehr Artefakten und komplexen „Produktionsvorgängen“ haben Firmen kaum eine andere Chance, als diese Vorgänge zu automatisieren. Werkzeuge für Build-Management (hier eine Liste) und Tools für Continuous Integration sind Stand der Technik.
Die veröffentlichten Konfigurationen sind die Releases; sie werden manchmal auch als Versionen bezeichnet.
c) Change-Management (Fokus: Änderungen an Produkten, nicht an Organisationen)
Oft sind es Anforderungen der Umwelt, die Änderungen begründen: Fehler müssen behoben werden, die Funktion wird umdefiniert, eine neue technische Umgebung verlangt Anpassungen. Change-Management beinhaltet dokumentierte(!) Entscheidungen, ob und in welcher Weise neue Versionen als Antwort auf solche Herausforderungen erstellt werden.
Change-Management hat zum Ziel, den Umgang mit neuen und sich ändernden Anforderungen an ein System ebenso kontrolliert zu steuern wie Anfragen nach einer Fehlerbehebung.
Das Change-Management umfasst den oder die Prozesse, um
- Änderungsanforderungen zu dokumentieren,
- Änderungsanforderungen zu bewerten,
- über Maßnahmen zu entscheiden (z. B. Behördenmeldung, Änderung am Produkt, Untätigkeit, Schulungen)
- Änderungen zu genehmigen,
- die Durchführung von Änderungen zu überwachen.
Manche Firmen haben für die Bewertung und Freigabe von Änderungen ein Change Control Board etabliert.
Wenn dieses Board nicht nur darüber entscheidet, ob, sondern auch wann eine Änderung durchgeführt und freigegeben werden darf, hat dieses Board auch die Hoheit über das Release-Management.
d) Release-Management
Das Release-Management ist der Prozess, durch den Software zur Verfügung gestellt wird. Es legt fest, in welche Version (Release) eines Produkts welche Konfigurationsänderungen einfließen.
Die Entscheidungen darüber werden beeinflusst durch
- die Bedeutung der Änderung für die Patientensicherheit,
- Gesetze, z. B. die Medizinproduktesicherheitsplanverordnung (MPSV), die konkrete Fristen nennt,
- Dringlichkeit der Änderung aus Kundensicht,
- Verfügbarkeit von Personen, die die Änderung verwirklichen können,
- Abhängigkeiten von Konfigurationsänderungen untereinander.
e) Fazit
Auch wenn Versionsverwaltungssysteme der wichtigste und meistgenutzte Werkzeugtyp beim Konfigurationsmanagement sind, umfasst das Konfigurationsmanagement weit mehr als nur das Versionsmanagement.
3. Regulatorische Anforderungen
a) IEC 62304
Die IEC 62304 („Medical device software – Software life cycle processes“) fordert explizit das Konfigurationsmanagement. Dessen Planung muss bereits Teil des Entwicklungsplans sein. Hersteller müssen festlegen,
- welche Artefakte oder Artefakt-Typen der Versionskontrolle zu unterwerfen sind,
- welche diesbezüglichen Tätigkeiten notwendig sind,
- wer (im Unternehmen) die Verantwortung dafür trägt,
- wann die Artefakte unter Konfigurationskontrolle zu stellen sind (unbedingt vor der Verifizierung) und
- wie all dies auch bei der Software-Wartung und Problemlösung geschehen soll.
Der Software-Konfigurationsmanagement-Prozess umfasst nach IEC 62304 die obengenannten Aspekte des Konfigurationsmanagements:
- Bewertung von Änderungen (→ Change-Management)
- Entscheidung über Maßnahmen (→ Change-Management)
- Freigabe von Änderungen (→ Change-Management)
- Historie der Konfigurationen (→ Versionsmanagement)
Spezifisch für die Norm ist die Forderung nach Konfigurationskontrolle explizit auch für SOUPs und die Verifizierung, dass die geplanten Änderungen erfolgreich durchgeführt wurden.
b) ISO 13485
Die ISO 13485 („Medical devices – Quality management systems – Requirements for regulatory purposes“) fordert kein explizites Konfigurationsmanagement. Sie sieht es aber als ein Mittel, um die Identifizierbarkeit und Traceability zu gewährleisten.
c) FDA
Die FDA fordert im „Software Validation Guidance Document“ ebenfalls einen Konfigurationsmanagement-Plan:
„A configuration management plan should be developed […] Controls are necessary to ensure positive and correct correspondence among all approved versions of the specifications documents, source code, object code, and test suites that comprise a software system. The controls also should ensure accurate identification of, and access to, the currently approved versions.“
d) Weiterführende Hinweise
Mapping zur IEEE 828:2012
Etwas umfassender (und vielleicht auch etwas akademischer) definiert die IEEE 828:2012 die Teilprozesse des Konfigurationsmanagements:
- Configuration Identification (CI) → Ein Teil ist Versionsmanagement.
- Configuration Change Control (CCC) → Change-Management
- Configuration Status Accounting (CSA) → z. B. Release Reports, DHF usw.
- Configuration Auditing (CA) → Analytische Qualitätssicherung
- Configuration Release Management (CoRM) → Das passt 1:1 zu der obigen Darstellung.
IEEE 828:2012 und Build-Management
Das Build-Management erstreckt sich gemäß der Norm quer durch die CM-Disziplinen. Beispielsweise müssen die Build-Skripte als CI identifiziert werden. Sie stehen natürlich unter CCC und über die zu einem Release gehörenden bzw. aktuell gültigen Versionen wird Buch geführt (CSA).
Änderungen an Build-Skripten müssen geprüft werden (CA) und das für ein Release zu verwendende Build-Skript muss für selbiges zur Verfügung stehen (CoRM).
4. Die häufigsten Fehler beim Konfigurationsmanagement
In Audits werden regelmäßig folgende Probleme offensichtlich:
- Es sind nicht alle Artefakte unter Versionskontrolle.
- Die Entwicklungs- und Testumgebung ist nicht unter Versionskontrolle.
- Testcode und Produktcode können nicht für bestimmte Zeitpunkte und Versionen zueinander passend wieder herstellt werden.
- Der Hersteller hat sich über die Validierung der Werkzeuge keine Gedanken gemacht.
- Es fehlen Begründungen, weshalb beantragte Änderungen nicht durchgeführt werden.
- Es fehlt eine explizite Änderungsfreigabe.
- Nur der letzte Stand der Software vor Release wird „eingecheckt“.
- Der Nachweis fehlt, dass durchgeführte Änderungen tatsächlich die Anforderung erfüllen.
- Der Hersteller testet nicht die ausgelieferte Version.
5. Fazit und Zusammenfassung
Das Konfigurationsmanagement ist eine Voraussetzung einer professionellen Software-Entwicklung nach Stand der Technik. Zahllose Werkzeuge automatisieren die Schritte und vermeiden Fehler, die bei manuellen Tätigkeiten regelmäßig unterlaufen.
Die Werkzeuge ersetzen aber keine Strategie, um Software marktgerecht zu releasen und Fehler schnell und wirksam zu beheben.
Änderungshistorie
- 2024-10-17: Überschriften nummeriert und ergänzt, Reihenfolge in den Kapitel 1 und 4 geändert, Kapitel 5 eingefügt.
- 2016-08-03: Erste Version des Artikels veröffentlicht
