Seite 3: Das EDAP-Schema

Inhaltsverzeichnis

Anders macht es das Bayerische Forschungsinstitut für Digitale Transformationen (bidt). Es schlägt vor, den Prüfungsschritt der ethischen Leitlinien als festen Bestandteil agiler Entwicklungsprozesse direkt im Entwicklungsteam zu verankern. Dafür hat das bidt das Forschungsprojekt „Ethik in der agilen Softwareentwicklung“ gestartet, das von Prof. Dr. Julian Nida-Rümelin (Inhaber des Lehrstuhls für Philosophie und politische Theorie an der Ludwig-Maximilians-Universität München) und Prof. Dr. Alexander Pretschner (Inhaber des Lehrstuhls für Software & Systems Engineering an der Technischen Universität München) geleitet wird. Zusammen mit Niina Zuber und Severin Kacianka veröffentlichten sie das Arbeitspapier "Ethische Deliberation für agile Softwareprozesse: EDAP-Schema". Darin stellen die Autoren ein Tool vor, dass es "agilen Teams erlaubt, die ethische Dimension ihrer Entwicklungsentscheidungen zu strukturieren, klar zu kommunizieren und schlüssig zu überdenken (deliberieren). Dadurch können diese Entscheidungen von Dritten nachvollzogen und geprüft werden."

Der Vorteil des EDAP-Schemas ist, dass es nicht nur die ethische Prüfung in die auszuführenden Teams einbettet, sondern sich vor allem auch einfach in die alltäglichen Prozesse mit einbinden lässt. Die Teams müssen keinerlei neue Strukturen oder Mechanismen erlernen.

Das EDAP-Schema selbst gliedert sich dabei in acht Phasen. Um das Schema etwas plastischer beschreiben zu können, dient das fiktive Unternehmen StahlProduzenten AG als Beispiel. Ein Produktteam entwickelt Software für den internen Betrieb, mit dessen Hilfe sich Maschinen bedienen lassen, die Stahl biegen. Die Software erfordert eine manuelle Bedienung durch Werkarbeiterinnen oder Werkarbeiter. Die neue Anforderung an die Software lautet, dass das Programm auch ohne menschliches Eingreifen den Stahl biegen können soll. Der Stakeholder für dieses Feature ist der Fachbereich Lager/Logistik.

Phase I: Deskriptive Systemanalyse

Die erste Phase ist die einfachste und erfordert eine Beschreibung und Analyse der Gesamtsituation. Hier stellt sich typischerweise die Frage, welche technischen Möglichkeiten es gibt, um auf eine User-Story oder ein Ticket zu reagieren – oder auch welche Abhängigkeiten existieren.

Im Beispielfall hieße das, die notwendigen technischen Anforderungen zu beschreiben und die betroffenen Gruppen (Werkarbeiter vs. Stakeholder) zu identifizieren. Darüber hinaus sollte klar beschrieben sein, was genau der Stakeholder verlangt.

Phase II: Deskriptive Werteanalyse

Die zweite Phase ist dazu da, bestehende Kodizes und Wertevorstellungen zu identifizieren, die bei der Bearbeitung des geforderten Features eine Rolle spielen könnten – beispielsweise ein Code of Ethics oder gar die Menschenrechte. Aber auch Organe wie der Betriebsrat könnten hier als Werteinstanz eine Rolle spielen.

Im Beispielfall der StahlProduzenten AG berücksichtigt das Produktteam keine spezifischen Kodizes. Eine Menschenrechtsverletzung wird ausgeschlossen. Lediglich die Gewerkschaft wird als Ansprechpartner identifiziert, da es um konkrete Änderungen im Arbeitsablauf der Werkarbeiter geht und der Stakeholder sowie die betroffene Gruppe voneinander abweichen.

Phase III: Technische Analyse

Diese Phase teilt die zu erstellende Analyse in drei grobe Bereiche, die bei der weiterführenden Analyse eine Rolle spielen könnten: Pre-Existing Bias, Technical Bias und Emergent Bias. Es ist dabei nicht erforderlich, für alle diese Kategorien etwas zu finden, jedoch kann eine kurze Auseinandersetzung damit aufzeigen, wo welches Feature einzuordnen ist.

Das Pre-Existing Bias konzentriert sich auf das "Begründen des Features durch Institutionen, Praktiken und Einstellungen". Es könnte zum Beispiel Gründe aus der Vergangenheit vorliegen, die das Feature (nicht) sinnvoll erscheinen lassen. Unter Umständen könnte das gewünschte Feature bereits vor einiger Zeit absichtlich abgelehnt worden sein, weil es gewissen Bedenken in unterschiedliche Richtungen gab.

Das Technical Bias schaut auf die technischen Limitationen. Es könnte gegebenenfalls sein, dass es technisch einfach nicht möglich ist, das gewünschte Feature zu implementieren.

Das Emergent Bias analysiert nun mögliche entstandene Einflüsse der Nutzer durch "die Einbindung des Features in die reale Lebenssituation". Im Beispielfall könnte es bedeuten, dass die Werksarbeit für den Bereich nicht mehr benötigt werden – was eine kritische Änderung im Arbeitsablauf vieler Menschen bedeuten könnte.

Phase IV: Werte- und Zielkonflikte

In dieser Phase werden die Ergebnisse der vorherigen Phasen zusammengeführt. Die zentrale Frage ist, ob es möglich ist, dass die Werte der Stakeholder im direkten Gegensatz zu den Werten der betroffenen Gruppen stehen? Und wenn ja, in welcher Form?

Im Beispiel der StahlProduzenten AG ist es so, dass die Gewerkschaft befürchtet, die betroffenen Werkarbeiter könnten hier einen starken Druckpunkt bei künftigen Tarifverhandlungen verlieren, da bei drohenden Streiks das Fernbleiben der Werkarbeiterinnen und Werkarbeiter von ihrem Posten kaum eine Rolle mehr spielen würde, weil die Maschinen autonom arbeiten. Die Werte und Ziele der Stakeholder weichen in diesem Fall von denen der betroffenen Gruppe ab.