Der dritte Gast in meiner Interview-Serie zum Thema Built-in Quality ist mein geschätzter Kollege und ein wahres Allround-Talent, Christoph Schmitz. Er ist Qualitätsmanager, Software/System-Architekt, Projektleiter, Requirements Engineer von Software, Embedded Software sowie kombinierten Hardware/Software-Systemen.
Pia:
Willkommen, Christoph!
Es freut mich sehr, dass du dir heute Zeit nimmst, um mit mir über Qualität zu sprechen.
Stell’ dich bitte kurz vor – wer bist du, was machst du?
Christoph:
Erstmal vielen Dank für die Einladung. Ich finde es eine sehr gute Idee das Thema Qualität in dieser Form zu besprechen.
Ich bin Christoph Schmitz, habe Informatik studiert und auch in diesem Bereich promoviert.
Während meiner Ausbildung habe ich mich hauptsächlich mit formalen Methoden beschäftigt, d.h. wie kann ich korrekt funktionierende Software entwickeln und anschliessend auch zeigen, dass sie funktioniert. Bei Zühlke war und ist mein Schwerpunkt Software- oder System-Qualität.
Qualität ist meine Leidenschaft. Das hat sich schon früh in meiner Laufbahn gezeigt.
Während des Studiums war ich derjenige, der am längsten gebraucht hat seine Software zu schreiben. Als es nachher darum ging das Ganze laufen zu lassen, war meine Software die, die am besten gelaufen ist. Ich hatte gleich viel Zeit ins Testen wie ins Entwickeln investiert.
Da habe ich gelernt, dass es sich lohnt, früh, bereits während der Entwicklung zu testen und so Fehler zu vermeiden.
Bei Zühlke habe ich fast ausnahmslos sicherheitsrelevante Systeme von Software und Hardware in Kombination entwickelt. Dadurch bin ich immer wieder mit Qualitätsproblemen in Berührung gekommen, die auftreten, sobald man Hardware und Software miteinander verbindet.
Privat bin ich verheiratet und geniesse mein Leben hier in der Schweiz (Christoph kommt ursprünglich aus Deutschland).
Wenn ich nicht arbeite, entspanne ich mich gerne beim Kochen, Backen, Lesen oder beim Sport. Das Lesen ist wohl offensichtlich, wenn du hinter mir schaust
Ich besitze wirklich viele Bücher, zu allen Themen. Von Krimis über Klassiker, Geschichtsbücher, Psychologie, Technik, Wirtschaft und so weiter. Es gibt kaum etwas das mich nicht interessiert.
Pia:
Wir beide kennen uns über Zühlke für deren Kunde wir im letzten Jahr gemeinsam an einer Qualitätsstrategie arbeiten durften. In diesem Projekt ging es konkret um das reibungslose Zusammenspiel von Hardware und Software im Bereich der Gebäudeautomation. Ich habe die Zusammenarbeit mit dir superspannend gefunden und so kam die Idee dich für meine Blogserie zu interviewen.
Wenn du an Qualität denkst, unabhängig von Software oder Hardware, was bedeutet das für dich?
Wann hat ein Produkt gute Qualität?
Christoph:
Qualität ist kein absoluter Begriff. Für mich ist Qualität relativ und hängt stark vom Kunden ab. Würden wir alle perfekte Qualität fordern, könnten wir uns viele Dinge nicht mehr leisten, weil diese viel zu teuer werden würden. Hier muss man also Abstriche machen. Qualität ist auch abhängig vom Bereich, in welchem das Produkt verwendet wird. Ich persönlich habe einen geringeren Qualitätsanspruch an ein Videospiel als an eine Insulinpumpe oder einen Herzschrittmacher. Wenn ich im Flugzeug verreise, habe ich höhere Qualitätsansprüche an die Triebwerke des Flugzeugs als an die Sitze.
Das heisst also ich muss nicht immer maximale Qualität haben, sondern ich muss eine Qualität haben, die für den Zweck gut genug ist. Qualität, welche die Anforderung erfüllt und mit welcher die Kundschaft am Ende zufrieden ist.
Pia:
Absolut.
Du hast viele Projekte im sicherheitskritischen Bereich. Mit dem Flugzeug-Beispiel kann sich sicher jede/r identifizieren. Kannst du noch etwas mehr aus besonders kritischen Bereichen teilen?
Christoph:
Gerne. Wenn ich jetzt in einem kritischen Umfeld wie Eisenbahntechnik unterwegs bin, gibt es Regularien, die bestimmen, wie häufig ein System ausfallen darf. Sie regeln ab welcher Zeitspanne Fehler auftreten dürfen. Das können einige Tausend bis mehrere Millionen Betriebsstunden sein.
Ist ein System nicht ganz so kritisch, kann es sein, dass es akzeptabel ist, wenn statistisch gesehen alle 10 Jahre ein gefährlicher Ausfall auftritt. Bei extrem sicherheitsrelevanten Funktionen darf es statistisch gesehen jedoch nur 1 Mal in 10.000 Jahren einen gefährlichen Ausfall geben. Bei solchen Grössenordnungen sprechen wir also von ganz anderen Ansprüchen an Qualität. Das bedeutet auch, dass anders entwickelt und getestet werden muss. Der Prozess endet auch nicht mit der fertigen Entwicklung. Abhängig vom Einsatzbereich müssen Prüforganisationen und Behörden das System für die Nutzung durch Endkund:innen freigeben. Hierdurch soll sichergestellt werden, dass das Produkt die erforderliche Qualität beinhaltet und keine unnötigen Gefahren vom Produkt ausgehen.
Pia:
Ich sehe schon, das ist eine andere Hausnummer, als was ich gewohnt bin. Ich bin viel in der Finanzbranche unterwegs. Die ist zwar auch reguliert und Risikomanagement ist sehr wichtig, im Endeffekt geht's hier im schlimmsten Fall aber nur um Geld das verloren geht. Es geht nicht direkt um Menschenleben.
Im Transportwesen oder der Medizintechnik hängen schnell mal Menschenleben dran. Ich habe vor Kurzem einen Artikel gelesen, in welchem es um einen beinahe Unfall auf einer Eisenbahnstrecke hier in der Schweiz ging. Da hat mindestens ein System, das für die Warnsignale auf der Strecke zuständig ist, versagt. Der Lockführer hat zum Glück rechtzeitig reagiert. Obwohl alle Signale auf Grün waren, stand ein Baufahrzeug auf dem Gleis, auf dem der gerade mit seinem Zug angefahren kam.
Hast du mit deiner Erfahrung einen Verdacht was da passiert sein könnte?
Christoph:
Das ist von aussen schwierig zu sagen. Da möchte ich nicht spekulieren. Ich weiss, dass alle Signalanlagen dem höchsten Sicherheitslevel entsprechen müssen. Normalerweise ist es so, dass so bald etwas unklar ist, nicht wie ihr wartet funktioniert, die Signale automatisch auf Rot gestellt werden. Das ist ein gutes Beispiel dafür, wie wichtig es ist, dass diese System zuverlässig funktionieren.
Ich hatte mal an einer der Software zur Steuerung von Rangierbahnhöfen mitgearbeitet. Ich hatte einen Teil entwickelt, der die Lokomotive auf der Anlage fernsteuert. Als wir an einem Wochenende zum Testen auf der Anlage waren hat der Kollege gesagt: »So, Christoph, du hast doch die Steuerung geschrieben…Und, funktioniert sie?» «Ja, ich bin sicher, dass sie funktioniert.» «Gut. Bist du dir sicher genug, um dich hier hinzustellen? Laut deiner Software müsste die Lok kurz vorher stehen bleiben.»
Pia:
Puh, krasse Frage…hast du’s gemacht?
Christoph:
Ich habe es nicht gemacht. Ich hätte es aufgrund der Sicherheitsvorschriften auch gar nicht machen dürfen, aber die Lok wäre rechtzeitig stehen geblieben. Ich hätte überlebt (lacht erleichtert).
Das sind so Sachen, da wird einem richtig bewusst wie wichtig korrekt funktionierende Software sein kann.
Pia:
Ja, absolut. Ich bin froh, dass du uns diesen Einblick geben kannst. Gerade in einen Bereich, den viele von uns für selbstverständlich halten. Wir überlegen gar nicht wieviel menschliche Arbeit, Genauigkeit und Gewissenhaftigkeit dahintersteckt, damit die Software tut, was sie soll. Auch in Kombination mit der Hardware. Dass alles korrekt zusammenspielt und keine/r vom Zug überfahren wird.
Ich habe mich neulich mit einem Kollegen zum Thema Fehlertoleranz in der Medizintechnik ausgetauscht. Konkret haben wir über den Einsatz von KI (künstlicher Intelligenz) bei der Erkennung von Krebs gesprochen. Er trainiert KI-Modelle darauf Krebs auf Scans zu erkennen. Nun stellt sich die Frage ob es OK ist, wenn das Modell 1 Mal nicht anschlägt, obwohl es sich um Krebs handelt. Ist es in Ordnung, wenn das Modell 3 Mal falsch alarmiert? Es sich also doch nicht um Krebs handelt. Das muss gut überlegt werden.
Hast du diesbezüglich auch Erfahrung?
Christoph:
Generell ist es immer so, dass der Hersteller eines Produktes sich genau überlegen muss, welches die Zielgruppe ist und was behandelt oder diagnostiziert werden soll. Der Hersteller muss dahingehend entsprechende Leistungsmerkmale definieren. Die Faustregel hierfür lautet: Es darf nicht schlimmer werden als vorher.
Will ich in Europa ein Medizinprodukt auf den Markt bringen, muss ich nachweisen, dass mein Produkt mindestens gleich gut oder besser ist, also einen Fortschritt bringt, als die Produkte, die bereits am Markt sind.
Oftmals kommen Ermessensfragen hinzu. Am Beispiel mit den Krebspatienten: Ist es vertretbar 500 Personen unnötig in Panik zu versetzen, um zu vermeiden eine einzelne Person nicht über ihren Krebs zu informieren? Hier muss man sehr stark abwägen und es spielen viele ethische Fragen mit rein. Ich bin sehr froh, dass ich das nicht entscheiden muss.
Pia:
Das passt gerade perfekt zu meiner nächsten Frage. Wie gross ist dein Handlungsspielraum in einem normalen Projekt im Medizinbereich? Ist alles genau vorgegeben oder hast du je nach Rolle eine gewisse Flexibilität?
Christoph:
Die Sachen sind ganz klar vorgegeben, also anders als in typischen Projekten im Webumfeld.
Klar definierte Anforderungen sind ein Muss. Da kann ich nicht wage bleiben. Hier stehen andere Dinge auf dem Spiel, wenn eine Anforderung nicht präzise definiert ist.
Teilweise ist auch vorgegeben, was für die Softwareentwicklung verwendet werden darf. Beispielsweise dürfen bestimmte Programmier-Konstrukte nicht verwendet werden, weil sie nicht sicher genug sind. Bei der Wahl der Entwicklungswerkzeuge gilt ebenfalls besondere Vorsicht. Entwicklungswerkzeuge sind prinzipiell frei wählbar, müssen aber validiert werden. D.h. es muss sichergestellt sein, dass die Werkzeuge auch genau das tun, was sie behaupten zu tun.
Bei der effektiven Programmierung folgt man typischerweise sogenannten Programmier-Guidelines. Das sind Leitfäden für Entwickler:innen, in welchen festgehalten ist, was gemacht oder verwendet werden darf bzw. nicht gemacht oder nicht verwendet werden darf. Ansonsten sind Entwickler:innen nicht weiter eingeschränkt. Es ist also nicht alles bis ins Detail vorgegeben.
Eine saubere Architektur und ein Design werden erstellt und dokumentiert auf deren Basis die Entwicklung arbeiten kann.
Im Anschluss wird alles durch Verifikation und formales Testen geprüft. Auf Ebene Unit-Test wird dies von dem Entwickler/der Entwicklerin selbst gemacht. Auf den höheren Teststufen, wie Integrationstest oder Systemtest, muss der Code immer durch eine andere Person geprüft werden. D.h. keine/r testet was er oder sie selber geschrieben hat. So wird das Risiko der Betriebsblindheit reduziert.
Für mich sind das keine starken Einschränkungen, sondern vielmehr Leitplanken, die mir anzeigen in welchem Bereich ich mich sicher bewegen kann ohne Gefahr zu laufen in den Abgrund zu stürzen.
Ich sage gerne schon bei Projektbeginn, vor allem wenn es sich um ein sicherheitsrelevantes handelt: Bei allem, was ihr tut, denkt an zwei Dinge:
Wenn ihr einen Fehler macht, kann das im schlimmsten Fall jemand das Leben kosten.
Würdet ihr euer Kind mit diesem Produkt behandeln lassen?
Diese beiden Punkte erhöhen das Qualitätsbewusstsein ungemein. Sie machen aus einem abstrakten Projekt etwas Greifbares.
Das fasziniert und motiviert mich gerade im Medizinbereich. Ich frage mich immer, was kann ich mit diesem Produkt Gutes tun.
Pia:
Sehr schön gesagt.
Wie verhinderst du im sicherheitskritischen Bereich das gegenseitige Schuldzuweisen im Fall von Fehlern?
Ich beobachte das regelmässig in weit weniger kritischen Branchen. Viele machen es sich einfach und schieben die Schuld auf andere, oftmals Personen in der QA-/Tester-Rolle.
Christoph:
Die Gefahr besteht natürlich. Was ich in Projekten mache, ist in meinem Team nach dem Grundsatz zu arbeiten, dass wir gemeinsam etwas entwickeln und so gut und umfänglich, wie wir nur können, testen. Ab einer bestimmten Stufe muss das Produkt aus regulatorischer Sicht an unabhängige Personen für die formale Verifikation weitergereicht werden.
In der Entwicklung haben wir, davon unabhängig, immer das Ziel, dass was wir liefern auch vollumfänglich funktioniert. Wir möchten Fehler soweit möglich vermeiden, selber finden und nicht erst von der nachgelagerten Verifikation gemeldet bekommen.
Schwieriger wird es natürlich, wenn mehrere Teams an einem System arbeiten oder mehrere Systeme zusammenkommen. Da ist es wichtig ein Projektteam zu haben das alle Teilbereiche umfasst, sodass man sich als Ganzes sieht. Es ist essenziell wichtig ein gemeinsames Verständnis zu haben. Wir haben das ganze System gemeinsam gebaut und gemeinsam kriegen wir das System als Ganzes zum Laufen.
Oftmals sind hier die technischen Herausforderungen geringer als die menschlichen. Gerade Zusammenarbeit und Kommunikation stellen oft Hürden dar.
Pia:
Ja, sehe ich auch so. Für mich steht und fällt vieles damit, wie können bzw. wie dürfen die Mitarbeitenden zusammenarbeiten.
Wie gehst du damit um, wenn zwar formal ein gemeinsames Team besteht, das Big-Picture aber nicht bekannt ist, weil die Gesamtsicht nicht dokumentiert ist? Es fehlt z.B. eine Architektur oder Design, welches den Gesamtkontext, den Prozess end-to-end abbildet.
Christoph:
Das habe ich schon häufiger gesehen und das ist ein sehr aktuelles Problem. Viele Firmen hatten früher Produkt A, Produkt B und Produkt C. Durch das Aufkommen des Internets und des IoT (Internet of things) sowie der Smartphones müssen bestehende Produkte stärker vernetzt und zusätzlich Apps für die Steuerung bereitgestellt werden. Auf einmal werden Systeme, die als eigenständige Systeme gedacht waren, zusammengeschmissen. Man beginnt dann oft schon an Sachen zu arbeiten und alles zusammen zu puzzeln, bevor man das grosse Ganze definiert hat. Was möchten wir eigentlich? Was ist unser grosses Ziel, unsere Vision, unser Schlachtplan? Wo möchten wir hin? Oft heisst es nur: Wir machen das jetzt…das macht jetzt jeder. Guck mal, unsere Konkurrenz hat da schon was…wir müssen das jetzt auch haben.
Pia:
Du beziehst dich auf Firmen, die sich früher komplett auf Hardware konzentriert haben und heute mit der zunehmenden Komplexität durch IoT konfrontiert sind.
Christoph:
Genau. Hier prallen natürlich Welten aufeinander.
Hardwareteile haben ganz andere Lebenszyklen als Smartphone Apps. Wenn eine Smartphone App z.B. ein halbes Jahr kein Update erhält, frage ich mich, ob es die Firma überhaupt noch gibt.
Während bei einem Gerät, das ich für meine Wohnung kaufe, erwarte ich, dass es jahrelang funktioniert und nicht, dass ständig jemand vorbeikommen und ein Update machen muss.
Bei Smartphones ist das anders. Die Software soll immer neu und aktuell sein und das Gerät auch. Wenn mein Smartphone 3 Jahre alt ist, gibt es schon drei neue Generationen, die viel besser sind.
Heute trifft die traditionell langlebige Hardware-Welt auf eine fast schon hyperaktive, kurzlebige, digitale Welt. Diese beiden zu vereinen ist eine grosse Herausforderung.
Die Schwierigkeit liegt oft an der Schnittstelle beider Welten.
Ich habe einmal im Projekt erlebt, dass ein Hardware-Team die Integration mit einem Software-Team prüfen wollte und hierfür um deren Anforderungen gebeten hat. Das Software-Team hatte jedoch keine formalen Anforderungen, sondern nur User-Stories ohne jegliche Traceability. Das ist ein echtes Problem.
Es ist ein Prozess, mit dem sich viele Firmen aktuell konfrontiert sehen. Man muss sich finden und gemeinsam definieren, wie man am besten und sinnvoll zusammenarbeiten kann, sodass für alle eine belohnende Zusammenarbeit entsteht, die alle zusammenschweisst.
Pia:
Und wie kann ich jetzt so ein komplexes System-of-Systems durchgängig prüfen? Wer macht was? Wer ist wofür zuständig?
Hast du einen Tipp wie man das organisiert, wie man Zuständigkeiten verteilen kann?
Christoph:
Das Erste ist und davon gehe ich aus, dass jedes Team das eigene System bzw. den eigenen Teil bestmöglich testet.
Für die weitere Integration gibt es verschiedene Ansätze. Man kann alles auf einmal, also einem «Big Bang» integrieren. Bei hoher Komplexität ist das für mich jedoch ein Aufruf zum Desaster.
Nach meiner Erfahrung ist es immer besser mit kleineren Einheiten anzufangen. Also kleine Einheiten die eng zusammenarbeiten miteinander integrieren. Dann mehrere dieser Einheiten miteinander verbinden und so weiter, bis das ganze System integriert ist.
Das hat den Vorteil, dass ich Probleme zwischen einzelnen Systemen oder Teilsystemen schneller erkenne und besser zuordnen kann.
Verantwortlich für die Integration und Verifikation sind die Teams, die an einer gemeinsamen Schnittstelle arbeiten. Es muss allen klar sein, dass es nicht mehr nur ums eigene System geht, sondern um das eigene System zusammen mit anderen Systemen. Das ist der Kerngedanke.
Pia:
Voraussetzung dafür ist aber, dass die Organisation den Mitarbeitenden die Freiheit gibt so zu arbeiten. Es geht nicht, dass Team A, in Abteilung A und Team B, in Abteilung B mit völlig unterschiedlichen Vorgaben angesiedelt ist. Zielkonflikte sind hier vorprogrammiert.
Christoph:
Genau, die Organisation insgesamt muss sich anpassen. Ansonsten wird man immer diese Zielkonflikte haben.
Pia:
Ich sehe du erfüllst oft verschiedene Rollen und manchmal auch mehrere Rollen im gleichen Projekt. Du entwickelst, du bist in der in der Qualitätssicherung, du bist Tester. Ich empfinde dich auch als Berater dafür wie man die Gesamtstruktur besser machen und die Zusammenarbeit verbessern kann.
Wo siehst du dich am Ehesten? Wenn du dich entscheiden müsstest, welche Rolle ist dir am liebsten?
Christoph:
Das ist eine sehr gute Frage. Ich könnte jetzt, typisch Deutsch, sagen, die «eierlegende Wollmilchsau».
Spass bei Seite. Ich möchte nicht nur rein beratend tätig sein, sondern ich möchte mir die Hände schmutzig machen. Ich will sehen, ob das, was ich empfehle, auch wirklich funktioniert. Was ich nicht mag, ist ein schönes Konzept schreiben und dann die Tür zu machen und gehen. Ich möchte dabei sein. Sei es mit dem Aufbau einer Testumgebung oder damit die einzelnen Disziplinen, wie Requirements Engineering, Testing und Entwicklung zusammen zu bringen.
Pia:
Da sind wir uns sehr ähnlich. Ich denke, deshalb hat unsere Zusammenarbeit auch vom ersten Moment an super geklappt.
Abschliessend würde ich gerne von dir wissen, was sind aus deiner Sicht die 3 wichtigsten Erfolgsfaktoren für Qualität bzw. Built-in Quality?
Christoph:
Für Projekte im Hard- und Software-Bereich sind das für mich:
Als Entwickler:in immer daran denken, dass die Hardware nicht so flexibel änderbar ist wie die Software. Zudem ist die Hardware in den meisten Fällen später verfügbar als die Software. D.h. ich muss viel Infrastruktur aufbauen, um meine Software gut testen zu können. Manchmal ist es nötig eine komplette Simulation des Zielsystem zu erstellen .Diese Aufwände muss man von Anfang an berücksichtigen und entsprechend einplanen.
Egal in welcher Rolle, nicht nur auf den eigenen Garten, sondern auf das Gesamtsystem schauen. Als Entwickler:in Verantwortung übernehmen und Bedenken oder Schwachstellen proaktiv ansprechen.
Built-in Quality funktioniert nur wenn wir als Team, rollenübergreifend, zusammenarbeitet und uns gegenseitig unterstützen. Bin ich beispielsweise Entwickler im Projekt frage ich mich, wie kann ich dem Tester das Leben einfacher machen. Wir müssen unseren Egoismus aufgeben und uns als Team sehen. Nur gemeinsam können wir erfolgreich sein.
Pia:
Sehr wahre Worte. Vielen Dank, Christoph.
Gibt es etwas, das du unseren Leser:innen zudem noch mitgeben möchtest?
Christoph:
Hardware ist nicht gleich Hardware. Ich habe an einem System entwickelt, das 32KB verfügbaren Speicher für Software hatte. Hardware kann alles sein, von winzig klein mit kaum Speicher bis zu einem riesengroßen System, wie einem Flugzeug, mit grosser Bandbreite. Es gibt nicht das eine System aus Software und Hardware
Im Embedded Bereich ist man oft gezwungen sehr kleine Programme zu schreiben. Hardware-Speicher ist nämlich teuer. Das stösst bei Software-Entwickler:innen häufig auf Unverständnis. Sie kennen derart kleine Programme nicht, weil es mit gängigen Sprachen wie Java oder C# gar nicht möglich ist so kleine Programme zu schreiben.
Es ist eine andere Herausforderung, die sehr spannend sein kann.
Pia:
Ich hoffe, dass wir ein paar Leute da draussen neugierig gemacht haben, mehr darüber zu erfahren. Ich finde es extrem spannend und habe das Projekt mit dir sehr genossen.
Vielen Dank, Christoph.
Christoph:
Danke dir für das Gespräch und die gute Zusammenarbeit.