Nachhaltige Software: Unterschied zwischen den Versionen
K (Tippfehler korrigiert) |
K (Link auf Weltpressefoto 2013) |
||
Zeile 98: | Zeile 98: | ||
Zu nennen sind folgende Aspekte: |
Zu nennen sind folgende Aspekte: |
||
# Open-Source ist unter dem Aspekt der sozialen Gerechtigkeit als positiv zu bewerten. (Das gilt allerdings nur für diejenigen, die Zugang zum Internet haben und die Quellen in Wert zu setzen verstehen - wie ist da die Situation z. B. für die Bevölkerung im Tschad?) |
# Open-Source ist unter dem Aspekt der sozialen Gerechtigkeit als positiv zu bewerten. (Das gilt allerdings nur für diejenigen, die Zugang zum Internet haben und die Quellen in Wert zu setzen verstehen - wie ist da die Situation z. B. für die Bevölkerung im Tschad? Interessant ist auch ein [http://www.welt.de/newsticker/dpa_nt/infoline_nt/boulevard_nt/article124854966/Afrikanische-Migranten-auf-Weltpressefoto-2013.html kurzer Blick nach Somalia].) |
||
# Steht der Quellcode zur Verfügung, lassen sich Fehler in einer Anwendung prinzipiell beheben (siehe oben stehende Eigenschaft E7). In Open-Source-Lösungen kommt so ein Bugfix allen anderen Nutzern zugute. |
# Steht der Quellcode zur Verfügung, lassen sich Fehler in einer Anwendung prinzipiell beheben (siehe oben stehende Eigenschaft E7). In Open-Source-Lösungen kommt so ein Bugfix allen anderen Nutzern zugute. |
||
# Veröffentlichte Software-Artefakte und Konzepte lassen sich in weiteren Software-Entwicklungen nutzen (Effizienzaspekt). |
# Veröffentlichte Software-Artefakte und Konzepte lassen sich in weiteren Software-Entwicklungen nutzen (Effizienzaspekt). |
Version vom 28. Februar 2014, 10:01 Uhr
Dieser Beitrag ist noch ziemlich unfertig... wir müssen auch noch einiges glattziehen...
- Zur Motivation siehe Vorbemerkung auf der Diskussionsseite.
- Anregungen und kritische Bemerkungen sind sehr willkommen!
Einleitung
Aspekte der Nachhaltigkeit werden heute intensiv mit Blick auf die Hardware-Komponenten informationstechnischer Systeme diskutiert (Stichwort "Green IT"). Für den Bereich der Software-Entwicklung werden in verschiedenen aktuellen Forschungsprojekten zwar verstärkt und mit Erfolg entsprechende Überlegungen angestellt, jedoch ist der diesbezügliche Diskussionsprozess sicherlich noch nicht als abgeschlossen anzusehen.
Zunächst ist festzustellen: Die Entwicklung und Nutzung informationstechnischer Systeme ist grundsätzlich mit einem Verbrauch von Ressourcen (Energie, Rohstoffe etc.) verbunden. Systemoptimierungen unter dem Aspekt der Energieeffizienz sind zwar wünschenswert, lösen diese Problematik jedoch sicherlich nicht: Ein energieeffizientes IT-System ist zwar weniger "schlimm" als seine ineffiziente Variante, lässt sich aber sicherlich nicht allein auf Grund eines minimierten Energiebedarfs als "nachhaltig" bezeichnen. Insofern stellt sich die Frage, ob und ggf. wie sich informationstechnische Systeme schaffen lassen, deren (umfassend betrachtete) Auswirkung auf die Umwelt nicht-negativ ist.
An dieser Stelle unseres Wikis soll beschrieben (und diskutiert) werden, was wir im Umfeld des ENE-Projektes unter nachhaltiger (im Gegensatz zu langlebiger!) Software und unter nachhaltigen Software-Engineering-Prozessen verstehen. Sinnvoll scheint eine Unterscheidung zwischen Software-Anwendung (Nutzung) und Software-Entwicklung (Herstellprozess). Demgemäß sollen nachfolgend mit Blick auf die im ENE-Projekt zu Grunde gelegte Nachhaltigkeitsdefinition die Begriffe der nachhaltigen Software und der nachhaltigen Software-Entwicklung präzisiert werden. Unter anderem stellt sich in diesem Kontext auch die Frage, inwieweit der Begriff der Digitalen Nachhaltigkeit konform ist zu dem im ENE-Projekt verwendeten Nachhaltigkeitsbegriff.
Wodurch zeichnet sich "nachhaltige Software" aus?
In der Literatur recht breit akzeptiert ist der Vorschlag von Dick, Naumann & Kuhn (2011), nachhaltige Software wie folgt zu definieren: "Sustainable software is software whose direct and indirect negative impacts on economy, society, human beings, and environment resulting from development, deployment, and usage of the software is minimal and/or has a positive effect on sustainable development." Mit Blick auf die Zielsetzung des ENE-Projekts ist die erstgenannte Teilbedingung ("minimal impact") an dieser Stelle sicherlich als zu schwach einzustufen, so dass wir das Logische "or" streichen und uns auf das "and" verständigen ("positive effect").
Häufig verwendet wird daneben der Begriff der Digitalen (oder Informationellen) Nachhaltigkeit, für den mehrere verschiedene Definitionen (oder vielleicht treffender ausgedrückt: verschiedene mit dem gleichen Begriff belegte Konzepte) existieren. Recht verbreitet sind die Definitionen von Dapp (ETH Zürich) und Stürmer (Parlamentatische Gruppe "Digitale Nachhaltigkeit" in der Schweiz), die Wissen als immaterielle Ressource auffassen und den Nutzungsaspekt von Information inklusive offener Zugangsmöglichkeiten in den Vordergrund stellen. Insofern scheint diese Sicht (die stark die Open-Source-Philosophie stützt) gegenüber der vorgenannten Definition mit Blick auf das ENE-Projekt zu sehr auf die soziale Dimension reduziert (vgl. auch Martens 2013, der den Nachhaltigkeitsbegriff für unpassend gewählt hält in Verbindung mit diesem Konzept, da dieser Ansatz nicht auf die Schonung natürlicher Ressourcen abzielt).
Subsumieren wir ökonomisch negative Auswirkungen auf Grund der damit einher gehenden sozialen Konsequenzen unter "Mensch und Gesellschaft", so können wir es zunächst bei folgender Definition belassen:
- Nachhaltige Software zeichnet sich dadurch aus, dass die direkten und indirekten negativen Auswirkungen auf Gesellschaft, Mensch und Umwelt, die sich aus der Entwicklung, dem Betrieb und der Verwendung der Software ergeben, minimal sind. Zudem sollen sich mit Blick auf eine nachhaltige Entwicklung durch die Software langfristig positive Auswirkungen ergeben.
Unter "langfristig positiven Wirkungen" verstehen wir dabei im ENE-Projekt (mit der Zielsetzung einer Integrierten Nachhaltigkeit) eine Entwicklung, die den Einklang von Mensch, Gesellschaft und Natur im Sinne eines "bien vivir" unter Einhaltung natürlicher Stoffkreisläufe und frei von irreversiblen Änderungen anstrebt; siehe auch Schweizer-Ries (2013). Technologie sehen wir dabei als treibenden Faktor zur Entwicklung von Hilfsmitteln und Vorgehensmodellen zur Vermeidung nicht-nachhaltiger Lebensweisen.
Bemerkung: An dieser Stelle wird nochmals deutlich, dass "digital nachhaltige" Software nicht per se nachhaltig in unserem Sinne ist.
Was verstehen wir unter "nachhaltiger Software-Entwicklung"?
Eine explizite Definition des Begriffs der "nachhaltigen Software-Entwicklung" ist an dieser Stelle nicht erforderlich, denn oben stehende Definition für "nachhaltige Software" beinhaltet bereits den Entwicklungsprozess. Trotzdem können viele Entwurfsentscheidungen während dieses Prozesses entscheidenden Einfluss auf das Erreichen der Nachhaltigkeitsziele haben.
Negativ-Beispiele, die sich z. B. aus einem ungeeigneten Systementwurf ergeben können:
- Eine Anwendung hat unangemessen hohe Hardware-Voraussetzungen und zwingt die AnwenderIn zum Kauf eines neuen Computers, obwohl der "alte" ansonsten noch gut läuft.
- Eine millionenfach aufgerufene Funktion (z. B. innerhalb einer Massenanwendung mit sehr großer Nutzerzahl) arbeitet algorithmisch ineffizient und führt somit zu einer sehr hohen CPU-Last und einem hohen Energieverbrauch.
- Eine Anwendung zum Abruf von Video-Dokumenten lädt bei jedem späteren Abruf das gesamte Dokument erneut über das Web (kein lokales Caching, keine Download-Möglichkeit).
- Eine App führt zu einem sehr hohen Energieverbrauch (siehe auch Diskussion), da sie eine permanente mobile Web-Verbindung und zusätzlich ein GPS-Signal benötigt.
- Eine Anwendung verwendet proprietäre Datenformate und ein Import der eigenen Daten in andere Systeme ist nicht vorgesehen.
TODO: weitere/bessere Beispiele?
Hingegen dürften nachstehende Positiv-Beispiele in Richtung unseres Kriteriums tendieren:
- E1 Die Anwendung ermöglicht die praktische Durchführung einer Tätigkeit, welche einen positiven Effekt auf die Umwelt hat. Beispiele:
- ein GIS-Werkzeug zur Optimierung des Standorts einer Windkraftanlage
- eine E-Government-Anwendung (digitale Formulare per Internet statt Papier und Fahrt zum Amt)
- ein Soziales Netzwerk, das seine Mitglieder dazu veranlasst, nachweislich mehr Energie zu sparen als Konzeption, Aufbau und Betrieb des Netzwerks benötigt haben/benötigen ;-) (wobei eine positive Gesamtbilanz nachzuweisen wäre).
- E2 In der Anwendung ist konzeptionell ein Mechanismus verankert, durch den ein Beitrag zur Verbesserung des ökologischen Zustands der Erde geliefert wird, z. B. indem automatisch durch die Nutzung der Anwendung Geldbeträge an nachhaltige Projekte gespendet werden.
- Beispiel: Ecosia (das übrigens im Design der Blackle-Version der Google-Suchmaschine als Massenanwendung noch nachhaltiger wäre).
Nachstehende (in Software-Häusern häufig genannte) Beispiele bleiben genauer zu untersuchen hinsichtlich ihrer tatsächlichen Nachhaltigkeit, scheinen jedoch (zumindest mit Blick auf eine schwache Nachhaltigkeit, Stichwort "Effizienz-Revolution" bei Martens & Schilder 2012) ebenfalls als positiv zu bewerten:
- E3 Einzelne Systemteile (z. B. Web-Dienste oder Datenbestände) lassen sich auch in Fremdsystemen oder späteren Neuentwicklungen direkt verwenden.
- E4 Das System ist skalierbar.
- E5 Die Anwendung lässt sich leicht um neue Funktionalität erweitern.
- E6 Ein System bietet langlebige Interfaces an, wodurch nach Änderung der Implementierung (z. B. System-Update) die Applikationen, die diese Interfaces nutzen, weiterhin lauffähig sind.
- E7 Fehler in einer Anwendung lassen sich Nutzer-seitig reparieren. (Dies erfordert eine geeignete Dokumentation, z. B. API-Beschreibung.)
- E8 Eine Web-Anwendung wird in einem Rechenzentrum gehostet (und/oder wird in einem Softwarehaus entwickelt), das seinen Strom aus regenerativen Energiequellen bezieht.
TODO: bessere/weitere Beispiele?
Vorgehensmodell
Eine stringente, allgemein anerkannte Vorgehensweise zur Erreichung der Nachhaltigkeitsziele ist uns nicht bekannt. Sinnvoll scheint zunächst eine Unterscheidung folgender Phasen (die nicht notwendigerweise streng-sequenziell im problematischen "Wasserfall"-Vorgehen zu durchlaufen sind):
- Abgrenzung des Betrachtungsgegenstandes ("Scoping")
- Identifikation von Nachhaltigkeitsindikatoren
- Bilanzprognose
Scoping
TODO
Nachhaltigkeitsindikatoren
TODO evtl. IMAGINE-Ansatz?
- Idee: Rodriguez & Penzenstadler (2013) schlagen vor, umfassend für alle Stakeholder-Gruppen jeweils bedeutsame und relevante Nachhaltigkeits-Indikatoren zu identifizieren und während des Projektverlaufs zu verfolgen.
Bilanzprognose
TODO
- Bem.: Prognose ist zu erneuern nach Rescoping.
Leitsätze für die nachhaltige Software-Entwicklung
- Welche Leitsätze (und Kriterien) lassen sich für mit Blick auf die Nachhaltigkeitsziele positive Software-Entwicklungen benennen?
- Lassen sich "Gestures" im Sinne einer Selbstverpflichtung für die Software-Entwickler zusammentragen (siehe dazu unseren Beitrag für das "Oracle du papillon")? Beispielsweise scheinen die Eigenschaft E2 und die Geste M10 ebenso isomorph wie E3 und H9, E4 und H7 oder E7 und C9.
Beispiele:
- E9 Unnötige Mobilität der Projektbeteiligten ist zu vermeiden.
- E10 Während der Anforderungsanalyse gibt es weitreichende Partizipationsmöglichkeiten für alle Interessensbeteiligten (Stakeholder).
TODO: weitere Merkmale?
Open-Source-Software und Nachhaltigkeit
Eingangs wurde der Begriff der "Digitalen Nachhaltigkeit" diskutiert, der nicht zwingender Weise mit einer Nachhaltigkeit in unserem Sinne einher gehen muss. Auf Grund dieser Unzulänglichkeit schlägt Martens (2013) daher die vielleicht treffendere Bezeichung der "Digitalen Allmende" vor (wobei sich "Allmende" in etwa mit "commons" in die englische Sprache übersetzen ließe). Unabhängig von der verwendeten Begrifflichkeit ist in diesem Umfeld die Open-Source-Philophie von zentraler Bedeutung. An dieser Stelle sei die Frage gestellt, ob und ggf. wie Open-Source einen positiven Betrag zu tatsächlich nachhaltiger Software liefert.
Zu nennen sind folgende Aspekte:
- Open-Source ist unter dem Aspekt der sozialen Gerechtigkeit als positiv zu bewerten. (Das gilt allerdings nur für diejenigen, die Zugang zum Internet haben und die Quellen in Wert zu setzen verstehen - wie ist da die Situation z. B. für die Bevölkerung im Tschad? Interessant ist auch ein kurzer Blick nach Somalia.)
- Steht der Quellcode zur Verfügung, lassen sich Fehler in einer Anwendung prinzipiell beheben (siehe oben stehende Eigenschaft E7). In Open-Source-Lösungen kommt so ein Bugfix allen anderen Nutzern zugute.
- Veröffentlichte Software-Artefakte und Konzepte lassen sich in weiteren Software-Entwicklungen nutzen (Effizienzaspekt).
- Wer arbeitet Ressourcen-effizienter: 40 Leute, die 4 Stunden auf dem Quellcode arbeiten oder 2 Leute, die jeweils 80 Arbeitsstunden zur Verfügung haben?
- ...
- ...
TODO: @Andreas, Peter: Weitere Punkte? Hier gibt es noch viel zu diskutieren!
Verhaltensweisen für den Software-Nutzer
Aus den angestellten Überlegungen lassen sich Verhaltensweisen für den Software-Konsumenten (im Sinne des im ENE-Projekt verwendeten Gesture-Begriffs) ableiten. Hier wurden 10 Verhaltensweisen ausgewählt, die uns möglicherweise einen kleinen Schritt in die positive Richtung zu bewegen erlauben:
- S1 Ich achte bei der Auswahl einer Software darauf, dass keine unnötig hohen Anforderungen an die Hard- und Betriebssystem-Ressourcen gestellt werden.
- S2 Ich bevorzuge Software, die weit verbreitete Dateiformate und Schnittstellen für den Datenimport und -export unterstützt.
- S3 Ich lege Wert darauf, dass die Software nicht unnötigerweise permanent online ist und sich auch offline betreiben lässt.
- S4 Wenn eine (nachweislich) nachhaltige Software-Alternative zur Verfügung steht, bevorzuge ich diese.
- S5 Ich achte darauf, dass die Software Erweiterungsmöglichkeiten und Programmierschnittstellen bietet.
- S6 Wenn eine etablierte Open-Source-Alternative bereit steht, so bevorzuge ich diese.
- S7 Ich nutze Anwendungen mit geringem Energieverbrauch (siehe z. B. Web-Browser-Vergleich, relevant aber insbesondere Server-seitig).
- S8 ...
- S9 ...
- S10 ...
TODO: Das ist unbedingt noch zu diskutieren, ob das überhaupt Sinn macht! TODO: Wem fällt noch mehr ein?
Fazit
Zusammenfassend lassen sich folgende Erkenntnisse festhalten:
- Der Begriff der "nachhaltigen Software" ist nicht gleichbedeutend mit dem der "effizienten Software".
- Die Betrachtungen sind nicht auf einzelne Maßnahmen und Software-Merkmale zu beziehen. Vielmehr muss die Gesamtbilanz positiv im Sinne einer nachhaltigen Entwicklung sein.
- Open-Source-Software kann nennenswerte positive Beiträge zur Erreichung des Nachhaltigkeitsziels leisten (tut es aber nicht immer!). Auch proprietäre "Closed-Source"-Software kann allerdings durchaus nachhaltig sein.
- Ziel weiterer Aktivitäten im Umfeld "Nachhaltige Software-Entwicklung" sollte eine Sensibilisierung der Software-EntwicklerInnen für dieses aus global wichtige Thema sein.
TODO: weitere Punkte/Erkenntnisse?
Referenzen
- Dick, M., S. Naumann & N. Kuhn (2010): A Model and Selected Instances of Green and Sustainable Software. Proceedings of the 9th IFIP TC 9 and 1st IFIP TC 11 International Conference, Brisbane, Australia, Sept. 2010, pp. 248-259.
- Martens, K.-U. (2013): Digitale Nachhaltigkeit. In J. Kegelmann & K.-U. Martens, Hrsg.: Kommunale Nachhaltigkeit, Nomos-Verlag, S. 421-428.
- Martens, J. & K. Schilder (2012): Sustainable Development. In J. Krieger, ed.: The Oxford Companion to Conparative Politics, 2nd ed., Oxford: Oxford University Press, pp. 813-815.
- Penzenstadler, B., V. Bauer, C. Calero & X. Franch (2012): Sustainability in Software Engineering: A Systematic Literature Review. Evaluation & Assessment in Software Engineering (EASE 2012), Proceedings, Ciudad Real, Spain, May 14-15, 2012, pp. 32-41.
- Rodriguez, A. & B. Penzenstadler (2013): Applying the IMAGINE Approach to Software Systems. Proceedings of the 2nd International Workshop on Requirements Engineering for Sustainable Systems, Rio, Brasil, July 15, 2013.
- Schweizer-Ries, P. (2013): Theroethical Reflections and Research Experiences. IAPS Bulletin 40, Autumn 2013, pp. 9-12.