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 Arbeitsbedingungen 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:
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 Programmierarbeiten), 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 Softwareprodukten entwickelt.
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
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.
| Begriff | Beschreibung |
| Datenträger-Image | Ein Abbild eines Datenträgers oder einer Partition eines Datenträgers, das in einer Datei gespeichert wird. |
| Energieeffizienz | Allgemein die Menge an „nützlicher Arbeit“ dividiert durch den dabei anfallenden Energieaufwand. Im Kontext dieses Dokuments wird „nützliche Arbeit“ als erfolgreiche Ausführung von Standardnutzungsszenarien operationalisiert. |
| Hardware | Gesamtheit der für die Ausführung von Programmen, die Speicherung von Daten oder den Transport von Daten benötigten Sachgüter. |
| Hardwarekapazität | Quantifizierbare Eigenschaft eines Hardwaresystems, die die Grenze seiner Leistungsfähigkeit auf einer gegebenen Leistungsdimension darstellt (z. B. Arbeitsspeicherkapazität, Rechenkapazität, Bandbreite). |
| Hardwaresystem | Abgrenzbare Einheit von Hardware, die definierte Funktionen erbringt. |
| Indikator | Eine empirisch bestimmbare Größe, die Aufschluss über einen nicht direkt messbaren Sachverhalt gibt. Das Skalenniveau der in diesem Dokument vorgeschlagenen Indikatoren ist unterschiedlich. In einigen Fällen wird eine qualitative Ordinalskala angenommen (z.B. „ungenügend”, „genügend”, „gut”, „sehr gut” oder auch nur „erfüllt“, „nicht erfüllt“), um zu vermeiden, durch Verwendung einer Kardinalskala eine nicht vorhandene Präzision vorzuspiegeln. |
| Nutzungsmuster | Abstrahierte Form einer Sequenz von Interaktionen mit einem gegebenen Softwareprodukt. |
| Nutzungsszenario | Beschreibung eines Nutzungsmusters, in der Regel maschinell ausführbar. |
| Plugin | Ein Softwaremodul, das in ein Softwareprodukt eingebunden werden kann, um dessen Funktionalität zu erweitern. |
| Referenzsystem | Ein Hardwaresystem, das hinsichtlich seiner wichtigsten Kapazitäten (z. B. Arbeitsspeicher, Prozessorleistung) während einer festgelegten Zeitperiode (z. B. ein Jahr) als allgemein üblich definiert wird. Das Referenzsystem dient dazu, Indikatoren wie z. B. „minimaler lokaler Arbeitsspeicher“ relativ zu einer Referenzgröße (der aktuell „üblichen“ Arbeitsspeicherkapazität) ausdrücken zu können. |
| Ressource | Im Kontext dieses Dokuments eine natürliche Ressource, insbesondere ein Rohstoff, eine Energieform oder auch die Absorptionsfähigkeit eines Umweltmediums für Emissionen. Zur Abgrenzung gegen technische Ressourcen, insbesondere Hardwareressourcen, werden letztere hier präziser als „Hardwarekapazitäten“ bezeichnet. Da die Beanspruchung von Hardwarekapazitäten stets zur Beanspruchung natürlicher Ressourcen führt, ist diese Abgrenzung (die in letzter Konsequenz auf eine definitorisch schwierige Grenzziehung zwischen Ökosphäre und Technosphäre hinausläuft) hier nicht von entscheidender Bedeutung. |
| Ressourceneffizienz | Allgemein die Menge an „nützlicher Arbeit“ dividiert durch den dabei anfallenden Aufwand an Ressourcen. Im Kontext dieses Dokuments wird „nützliche Arbeit“ als erfolgreiche Ausführung von Standardnutzungsszenarien operationalisiert. |
| Software | Programme und Daten in digitaler Form. |
| Softwareprodukt | Eine abgrenzbare Einheit von Programmen und Daten, die zur Ausführung und Verarbeitung auf einem Hardwaresystem bestimmt sind. |
| Standardkonfiguration | Eine als Referenz definierte Menge von Bedingungen, unter denen ein gegebenes Softwareprodukt betrieben wird. Sie umfasst die am Softwareprodukt während Installation oder Betrieb vorgenommenen Parametereinstellungen, die bereitgestellte Systemsoftware, ggf. weitere zum Betrieb benötigte Softwareprodukte sowie auf Hardwareebene das Referenzsystem. |
| Standardnutzungsszenario | Ein Nutzungsszenario, das zum Testen eines Softwareprodukts verwendet wird und möglichst repräsentativ für den üblichen Anwendungsfall sein soll. |
[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
Sie verlassen die offizielle Website der Hochschule Trier
