Kriterienkatalog für nachhaltige Software

Einleitung

Dieses Dokument ist Ergebnis des ersten von fünf Arbeitspaketen im UFOPLAN-Projekt „Sustainable Software Design –  Entwicklung und Anwendung von Bewertungsgrundlagen für ressourceneffiziente Softwareprodukte unter Berücksichtigung bestehender Methodik“ des Umweltbundesamtes.

Ziel des Projekts ist es, eine Methodik zur Bewertung der Umweltwirkungen von Softwareprodukten zu entwickeln. Diese Methodik soll sowohl die Beschaffung von Softwareprodukten unter Berücksichtigung von Umweltkriterien als auch die Entwicklung ressourceneffizienter Software unterstützen. Insbesondere soll es möglich sein, zwei gegebene Softwareprodukte mit ähnlicher Funktionalität hinsichtlich ihrer Wirkungen auf natürliche Ressourcen zu vergleichen. Durch die Formulierung ambitionierter Mindeststandards sollen darüber hinaus Kriterien für die Kennzeichnung nachhaltiger Softwareprodukte durch ein Umwelt- oder Gütezeichen abgeleitet werden.

Das Projekt leistet damit einen Beitrag, den Fokus von „Green IT“ von der Hardware- auf die Softwareebene auszuweiten. Da Softwareprodukte immaterielle Güter sind, stellt sich dabei insbesondere das Problem, die indirekten materiellen Wirkungen dieser Produkte begrifflich und methodisch klar zu fassen.

Umweltwirkungen eines Produkts entstehen generell durch die Beanspruchung natürlicher Ressourcen1 im Lebenszyklus des Produkts. Wir nehmen diese Lebenszyklusperspektive auch in Bezug auf Softwareprodukte ein (siehe Abb. 1). Dabei berücksichtigen wir insbesondere, dass die für den Betrieb eines Softwareprodukts benötigte Hardware produziert, mit elektrischer Energie versorgt und am Ende ihrer Nutzungsdauer entsorgt werden muss. Jedes Softwareprodukt beansprucht somit einen quantifizierbaren Anteil am Lebenszyklus aller zu seinem Betrieb nötigen Hardwareprodukte (programmierbare Geräte in jeglicher Form, Peripheriegeräte und Datenträger).

Aufgrund der Lebenszyklusperspektive ist dieser Ansatz geeignet für eine Erweiterung in Richtung auch der sozialen Aspekte der Rohstoffgewinnung und der Arbeits­bedingungen in der Hardwareproduktion oder -entsorgung; unser Fokus liegt jedoch auf den Umweltaspekten.

Auf Softwareebene beschränken wir die Perspektive im Folgenden bewusst auf die Nutzungsphase. Ziel der hier definierten Kriterien ist es, ein Softwareprodukt aufgrund von Eigenschaften, zu bewerten, die in der Nutzungsphase beobachtbar sind, sei es durch die Nutzenden selbst oder durch Personen, die spezielle Tests durchführen. Eine zusätzliche Berücksichtigung der Produktionsphase der Software wäre aber durch Erweiterung des Ansatzes prinzipiell möglich. Wichtiger als eine Bewertung des Softwareproduktionsprozesses erscheint uns jedoch dessen Beeinflussung, unter anderem in Form von Empfehlungen an die Verantwortlichen für die Softwareentwicklung. Hierfür wird in einer späteren Arbeitsphase dieses Projekts ein Leitfaden entwickelt.

Generell betrachten wir in diesem Projekt Standard-Anwendungssoftware, also keine Systemsoftware und keine spezielle Anwendungssoftware für wenige Nutzende. Im letzteren Fall müsste der Ressourcenaufwand für die Entwicklung sicher miteinbezogen werden.

Gerade bei der Bewertung weit verbreiteter Softwareprodukte ist grundsätzlich nicht nur eine Momentaufnahme, sondern die Nutzung des Softwareprodukts über längere Zeiträume (auch mehrerer Versionen) zu betrachten. Erst aus dieser Perspektive wird z. B. die Frage der durch Software induzierten Beschaffung von Hardware relevant.

Abstrakt formuliert, stehen zwei durch ein Softwareprodukt verursachte Flüsse im Vordergrund unserer Betrachtung:

  • der Durchfluss von Hardware durch die nutzende Organisation (neue Hardware zu Abfall),
  • der Durchfluss von Energie durch die Hardware (Elektrizität zu Abwärme).

Wenn ein Softwareprodukt im Vergleich zu Konkurrenzprodukten mit ähnlicher Funktionalität einen deutlich geringeren Hardware- und Energiefluss verursacht, kann es als „nachhaltig“ gelten.2

Der Fluss von Hardware kann mit Methoden der Ökobilanzierung von Produkten (Life Cycle Assessment, LCA) hinsichtlich seiner Ressourcenbeanspruchung eingeschätzt werden. Hierfür gibt es Lebenszyklusinventare zur Produktion und Entsorgung der wichtigsten Hardwarekomponenten, die wir als gegeben voraussetzen und nicht weiter behandeln. Ebenso kann der Energiefluss mit Methoden der Ökobilanzierung bewertet werden; die verschiedenen Methoden der Stromerzeugung sind ausreichend untersucht, diese Daten setzen wir also auch als gegeben voraus.

Aus diesen Gründen ist es ausreichend, mit den hier entwickelten Kriterien den Einfluss von Software auf benötigte Hardwarekapazitäten zu adressieren. Stellt man sich eine Wirkungskette von Softwareeigenschaften bis hin zur Beanspruchung natürlicher Ressourcen vor, so behandeln wir hier also ausschließlich den von der Software bis zu Hardwareprodukten und ihrem Stromverbrauch3 reichenden Abschnitt der Wirkungskette, denn nur dieser ist für unseren Untersuchungsgegenstand spezifisch.

Um Software hinsichtlich ihrer Nachhaltigkeit in Bezug auf den ausgelösten Hardware- und Energiefluss zu beurteilen, sind operationalisierbare Kriterien notwendig. Diese Kriterien können dann z. B. zur Information der Verantwortlichen für Softwareentwicklung, Softwarebeschaffung oder zur Vergabe eines Umweltkennzeichens eingesetzt werden.

Der hier vorgeschlagene Kriterienkatalog konzentriert sich auf Umweltwirkungen, die aus dem Betrieb eines Softwareprodukts resultieren. Dies schließt nicht aus, dass für die Vergabe eines Umweltkennzeichens weitere Kriterien zur Anwendung kommen, die sich auf den Prozess der Softwareentwicklung (z. B. Einhaltung von ILO4-Standards beim Outsourcing von Programmier­arbeiten), auf die Funktionalität der Software (z. B. Barrierefreiheit oder Ausschluss bestimmter Kategorien wie „Ballerspiele“) oder weitere Aspekte beziehen. Es erscheint uns jedoch wichtig, die hier behandelten Auswirkungen von Softwareeigenschaften auf die Beanspruchung natürlicher Ressourcen als klar definierten Forschungsgegenstand zu behandeln und nicht schon im Ansatz mit anderen Fragestellungen zu vermischen. Häufig liegen für diese angrenzenden Fragestellungen auch schon Studien und Kriterien vor, die als Ergänzung unseres Kriterienkatalogs benutzt werden können.

Auf den folgenden Seiten ist ein Baum (eine Hierarchie) von Kriterien und Indikatoren beschrieben. Die Blätter des Baumes sind Indikatoren, die zur Operationalisierung des jeweils übergeordneten Kriteriums dienen. Einen Gesamtüberblick über die Kriterien gibt das Inhaltsverzeichnis dieses Dokuments.

Die Aggregation (d. h. die arithmetische oder logische Zusammenfassung) der Indikatoren zu einem Kriterium und danach der Kriterien zu Oberkriterien wird später durch ein Bewertungsmodell geschehen, das wir im Rahmen dieses Projekts der Struktur nach anlegen. Die eigentliche Bewertung durch die Zuweisung von Gewichten, Normierungsfunktionen oder die Ausweisung von MUSS-Kriterien bleibt dem Umweltbundesamt oder anderen Anwendern unserer Kriterien überlassen und kann sich über die Zeit ändern.

Die Gewichtung von Indikatoren und Kriterien kann auch in einem bestehenden Bewertungsmodell nach Softwareklassen variieren. Insbesondere können Indikatoren oder Kriterien im Grenzfall mit 0 gewichtet werden, wenn sie für bestimmte Softwareklassen nicht anwendbar oder irrelevant sind. Wir haben eine auf die Anwendung unserer Kriterien abgestimmte Klassifikation von Software­produkten entwickelt.

  • lokale Anwendung
  • Anwendung mit entfernter Datenhaltung
  • Anwendung mit entfernter Verarbeitung
  • Serverdienst

Diese vier Klassen sind insofern von Bedeutung, als dass unser Ansatz nicht nur den Aufwand für die lokale Ausführung der Software, sondern auch den „remote“ ausgelösten Aufwand, von der Netzwerk-Infrastruktur über dedizierte Server bis hin zur Cloud, zu fassen versucht. Anderenfalls wäre der Ansatz nutzlos, weil die Kriterien durch Verlagerung von Umweltwirkungen an einen anderen Ort erfüllt werden könnten.

Im folgenden Hauptteil dieses Dokuments ist jedes Kriterium charakterisiert durch

  • eine Nummer, je nach Ebene ein-bis dreistellig,
  • eine Bezeichnung (Überschrift),
  • eine Frage, die das Kriterium erläutert,
  • evtl. einen auf die Frage folgenden Kommentar.

Das jeweils unterste Kriterium in der Hierarchie wird durch Indikatoren operationalisiert, die mit einem Kleinbuchstaben gekennzeichnet sind.

Dieser Baum von Kriterien und Indikatoren basiert auf einer umfassenden Literaturrecherche zu Kriterien zur Bewertung von Software, bei der mehr als 130 Kriterien zur Bewertung von Software aus über 60 Quellen analysiert wurden. Ein Entwurf des Kriterienkatalogs wurde auf einem Stakeholder-Workshop am 11. März 2016 in Berlin mit Fachpersonen aus Wissenschaft, Behörden und Industrie diskutiert. Das Feedback der Teilnehmenden während des Workshops und danach wurde bei der Überarbeitung des Dokuments berücksichtigt.

Einige der folgenden Kriterien und Indikatoren verweisen auf ein „Referenzsystem“, eine „Standardkonfiguration“ oder ein „Standardnutzungsszenario“; diese und weitere zentrale Begriffe sind im Glossar definiert.


[1] Definitionen von „Ressource“ und anderen zentralen Begriffen sind im Glossar zu finden. Wir reservieren den Begriff der Ressource in diesem Dokument für natürliche Ressourcen und vermeiden den technischen Begriff der Hardwareressource weitgehend, indem wir Hardwareressourcen direkt durch ihre quantifizierbaren Leistungsdimensionen, also Kapazitäten, beschreiben.

[2] Die Funktionalität eines Softwareprodukts und damit sein Nutzen wird hier nicht bewertet. Ziel ist es ausschließlich, den ausgelösten Aufwand (an Ressourcen) abzuschätzen und zu bewerten. Bei gegebenem Nutzen lässt sich dieser zum Aufwand ins Verhältnis setzen, um die Effizienz zu ermitteln.

[3] In einigen Fällen kann eine Erweiterung dieser Perspektive notwendig sein, indem analog zum Energiefluss auch Flüsse von Verbrauchsmaterialien wie Papier oder Toner durch die Hardware relevant sind. Ob ein solcher Fall vorliegt, kann nach einem erstes Screening vor Anwendung der Kriterien entschieden werden.

[4] International Labour Organization