Modularität (Anpassbarkeit an individuelle Bedürfnisse, vorhandene Hardware und finanzielle Möglichkeiten)
Portabilität auf verschiedene (und zukünftige) Betriebs- und Hardwaresysteme
Transparenz, Datenschutz und geringe Ausfälle/Fehlerhäufigkeit
Usability, Barrierefreiheit
4 thoughts on “Kriterien für „Nachhaltige Software“?”
Messbar wird das meines Erachtens kaum sein (fehlende Metriken, teilw. nur qualitative Angaben, Äpfel-Birnen-Vergleiche, schwer fassbare Abhängigkeiten z. B. von Rechnerarchitektur oder von dynamisch eingebundenen Software-Komponenten, …).
Ich denke, es ließe sich aber (möglichst partizipativ…) eine Bewertungshilfe erarbeiten. In Teilen könnte so ein Leitfaden natürlich quantitative Angaben enthalten (z. B. CO2-Ausstoss etc.), aber wie quantifiziere ich z. B. Obsoleszenzeffekte oder den Nutzen von Software-Artefakten mt Blick auf die Ziele nachhaltiger Entwicklung?
Viele mögliche Bewertungskriterien wurden ja bereits benannt, u. a.: Energiebedarf; Beitrag zu Obsoleszenz; Zugänglichkeit (z. B. auch abh. von Vorbildung des Nutzers oder bei schlechter Netzabdeckung in ländl. Bereichen etc.); Offenheit (und Stabilität) der Schnittstellen; benötigte Bandbreite (eingebundene Web-Services sind oft Ressourcen-intensiv); und viele mehr…
• Niedriger Energiebedarf – da wir zurzeit keine Benchmarks haben ist hier wichtig, dass es einen Nachweis gibt, dass der Energiebedarf der Software zumindest gemessen worden ist. Somit können später zumindest die Versionen der gleichen Software miteinander im Punkto Energieeffizienz verglichen werden.
• Geringe Belastung der Hardware – dieselbe Problematik wie beim Energiebedarf, deshalb muss die Hardwarebelastung zumindest gemessen worden sein und die Resultate müssen leicht zugänglich sein
• Geringe im Netz übertragene Datenmenge – analog Energiebedarf und Hardware-Auslastung
• Transparenz (hängt mit den vorerwähnten Kriterien zusammen) – dieser Grundsatz sollte sowohl für den Code (es sollten zumindest die Schnittstellen offengelegt werden) als auch für alle Lebenszyklen der Software gelten. Z.B. was an Ressourcen wird bei der Planung und Implementierung der Software verbraucht? Was an Ressourcen benötigt die Software wenn sie später läuft (RAM, CPU, Netzbelastung etc.)? Welche Daten werden gespeichert und wo? Wie lange verbleiben sie da? Was genau bleibt als Rückstand bei einer Deinstallation der Software?
• Kompatibilität nach Unten – die Kernfunktionalität einer Software ist in einem Modul verfasst, das auch auf einer älteren Hardware lauffähig ist. Altäre Hardware bedeutet, solche die vor 5 Jahren aktuell gewesen ist.
• Wissensaufbau – die Probleme und die Lösungen, die während der Implementierung der Software aufgetaucht sind werden festgehalten und öffentlich zugänglich gemacht – Ziel einschlägige Handbücher für Entwickler
• Abschaltung der nicht verwendeten Hardware ermöglichen
• Unterstützung von energieeffizienten Übertragungsprotokollen
• Speichereffizienz – nur das notwendige speichern und automatisiert später löschen, sparsame Datenformate verwenden
• Auswahl verschiedener Energieeffizienzmodi – Der User soll selber über Energieverbrach vs. Performance entscheiden. Teilweise soll dies ja nach Systemumgebung in der die Software gerade läuft (PC, Tablet, LAN, WLAN…) auch automatisiert geschehen.
• Datenschutz – Nicht mehr erfragen als nötig, nur verschlüsselte Übertragung sensibler Daten, verschlüsselte Speicherung sensibler Daten, keine Weitergabe der Daten
• Minimale Datenübertragung über Mobilfunknetzte – die Software soll erkennen wann eine Mobilfunkverbindung (LTE etc.) besteht, um dann die Datenübertragung zu drosseln oder komplett zu stoppen. Ebenso denkbar ist eine Regel, die besagt, dass Rechenoperationen, die vom Client (z.B. Tablet, Handy) angestoßen sind und im Normalfall auf dem Webserver ausgeführt werden, im Falle einer Mobilfunkverbindung auf dem Clientgerät stattfinden sollen.
Da sich Software stark in ihren Funktionalitäten unterscheidet, sollten diese in die Kriterien einfließen bzw. Kriterien ggf. je nach Funktionalität variieren. Bei entsprechenden Messungen erscheint es sinnvoll für den jeweiligen Softwaretyp typische Endnutzerszenairen zu betrachten.
Ein weiterer Punkt:
Umsetzung von Handlungsempfehlungen zur nachhaltigen Softwareentwicklung, erste Ansätze solcher Handlungsempfehlungen gibt es in versch. wissenschaftlichen Veröffentlichungen.
„Öffentlicher Code“ – Freie Software ermöglicht Anpassungen, modularisierungen, unabhängige Lebensdauer, Tranparenz sowie Portabilität und lokalisierungen
„Offline-Nutzung“ – Daten sollten exportiert werden können und Offline genutzt werden. Die Software selbst sollte auch mit der lokalen Kopie der Datenbank offline nutzbar sein
(vgl zb OpenStreetmap und GoogleMaps – letzteres funktioniert in vielen Regionen nur online. Ersteres kann inklusive Navigationsführung komplett offline genutzt werden)
„Unpersonalisierte Nutzung“ – Es sollte möglich sein, eine Software unpersonalisiert zu benutzen (vor allem im Hinblick auf Internet of Things und Elementen wie Sprachsteuerung immer interessanter)
Messbar wird das meines Erachtens kaum sein (fehlende Metriken, teilw. nur qualitative Angaben, Äpfel-Birnen-Vergleiche, schwer fassbare Abhängigkeiten z. B. von Rechnerarchitektur oder von dynamisch eingebundenen Software-Komponenten, …).
Ich denke, es ließe sich aber (möglichst partizipativ…) eine Bewertungshilfe erarbeiten. In Teilen könnte so ein Leitfaden natürlich quantitative Angaben enthalten (z. B. CO2-Ausstoss etc.), aber wie quantifiziere ich z. B. Obsoleszenzeffekte oder den Nutzen von Software-Artefakten mt Blick auf die Ziele nachhaltiger Entwicklung?
Viele mögliche Bewertungskriterien wurden ja bereits benannt, u. a.: Energiebedarf; Beitrag zu Obsoleszenz; Zugänglichkeit (z. B. auch abh. von Vorbildung des Nutzers oder bei schlechter Netzabdeckung in ländl. Bereichen etc.); Offenheit (und Stabilität) der Schnittstellen; benötigte Bandbreite (eingebundene Web-Services sind oft Ressourcen-intensiv); und viele mehr…
• Niedriger Energiebedarf – da wir zurzeit keine Benchmarks haben ist hier wichtig, dass es einen Nachweis gibt, dass der Energiebedarf der Software zumindest gemessen worden ist. Somit können später zumindest die Versionen der gleichen Software miteinander im Punkto Energieeffizienz verglichen werden.
• Geringe Belastung der Hardware – dieselbe Problematik wie beim Energiebedarf, deshalb muss die Hardwarebelastung zumindest gemessen worden sein und die Resultate müssen leicht zugänglich sein
• Geringe im Netz übertragene Datenmenge – analog Energiebedarf und Hardware-Auslastung
• Transparenz (hängt mit den vorerwähnten Kriterien zusammen) – dieser Grundsatz sollte sowohl für den Code (es sollten zumindest die Schnittstellen offengelegt werden) als auch für alle Lebenszyklen der Software gelten. Z.B. was an Ressourcen wird bei der Planung und Implementierung der Software verbraucht? Was an Ressourcen benötigt die Software wenn sie später läuft (RAM, CPU, Netzbelastung etc.)? Welche Daten werden gespeichert und wo? Wie lange verbleiben sie da? Was genau bleibt als Rückstand bei einer Deinstallation der Software?
• Kompatibilität nach Unten – die Kernfunktionalität einer Software ist in einem Modul verfasst, das auch auf einer älteren Hardware lauffähig ist. Altäre Hardware bedeutet, solche die vor 5 Jahren aktuell gewesen ist.
• Wissensaufbau – die Probleme und die Lösungen, die während der Implementierung der Software aufgetaucht sind werden festgehalten und öffentlich zugänglich gemacht – Ziel einschlägige Handbücher für Entwickler
• Abschaltung der nicht verwendeten Hardware ermöglichen
• Unterstützung von energieeffizienten Übertragungsprotokollen
• Speichereffizienz – nur das notwendige speichern und automatisiert später löschen, sparsame Datenformate verwenden
• Verwendung offener Datenformate – Customer-Lockins mittels Datenformate vermeiden
• Flexibilität bezüglich Peripheriegeräte
• Auswahl verschiedener Energieeffizienzmodi – Der User soll selber über Energieverbrach vs. Performance entscheiden. Teilweise soll dies ja nach Systemumgebung in der die Software gerade läuft (PC, Tablet, LAN, WLAN…) auch automatisiert geschehen.
• Datenschutz – Nicht mehr erfragen als nötig, nur verschlüsselte Übertragung sensibler Daten, verschlüsselte Speicherung sensibler Daten, keine Weitergabe der Daten
• Minimale Datenübertragung über Mobilfunknetzte – die Software soll erkennen wann eine Mobilfunkverbindung (LTE etc.) besteht, um dann die Datenübertragung zu drosseln oder komplett zu stoppen. Ebenso denkbar ist eine Regel, die besagt, dass Rechenoperationen, die vom Client (z.B. Tablet, Handy) angestoßen sind und im Normalfall auf dem Webserver ausgeführt werden, im Falle einer Mobilfunkverbindung auf dem Clientgerät stattfinden sollen.
Da sich Software stark in ihren Funktionalitäten unterscheidet, sollten diese in die Kriterien einfließen bzw. Kriterien ggf. je nach Funktionalität variieren. Bei entsprechenden Messungen erscheint es sinnvoll für den jeweiligen Softwaretyp typische Endnutzerszenairen zu betrachten.
Ein weiterer Punkt:
Umsetzung von Handlungsempfehlungen zur nachhaltigen Softwareentwicklung, erste Ansätze solcher Handlungsempfehlungen gibt es in versch. wissenschaftlichen Veröffentlichungen.
„Öffentlicher Code“ – Freie Software ermöglicht Anpassungen, modularisierungen, unabhängige Lebensdauer, Tranparenz sowie Portabilität und lokalisierungen
„Offline-Nutzung“ – Daten sollten exportiert werden können und Offline genutzt werden. Die Software selbst sollte auch mit der lokalen Kopie der Datenbank offline nutzbar sein
(vgl zb OpenStreetmap und GoogleMaps – letzteres funktioniert in vielen Regionen nur online. Ersteres kann inklusive Navigationsführung komplett offline genutzt werden)
„Unpersonalisierte Nutzung“ – Es sollte möglich sein, eine Software unpersonalisiert zu benutzen (vor allem im Hinblick auf Internet of Things und Elementen wie Sprachsteuerung immer interessanter)