Respektiert der Hersteller des Softwareprodukts die Autonomie des Nutzenden im Umgang mit dem erworbenen Produkt?
Dieses Hauptkriterium geht von der Annahme aus, dass eine relevante Zahl von Nutzenden an einem ressourcenschonenden Einsatz von Software interessiert ist. Wenn es ihnen ohne funktionelle Nachteile möglich ist, werden sie versuchen, mit geringer Hardwarekapazität auszukommen (für die sie in der Regel bezahlen) und auch den Energieverbrauch gering zu halten (der ebenfalls finanziell relevant ist oder zumindest die Akkulaufzeit mobiler Geräte beeinflusst). Dies ist jedoch nur unter der Voraussetzung möglich, dass die Nutzenden nicht zu unnötiger Beanspruchung von Ressourcen gezwungen werden und verstehen, wie sie sie vermeiden können.
Das angestrebte Ideal ist ein Softwareprodukt, das die Freiheit der Nutzenden über die Beanspruchung von Kapazitäten (und damit indirekt von Ressourcen) bei Nutzung des Produkts selbst zu entscheiden, möglichst weitgehend respektiert.
Die folgenden Kriterien sind aus der Perspektive von technikfernen Zielgruppen zu beurteilen, sie sind also in der Regel nicht dadurch schon erfüllt, dass sie bei Nutzung des Produkts durch eine speziell ausgebildete oder speziell geübte Fachperson erfüllt wären. Eine Ausnahme hiervon bildet Kriterium 3.1.2.
Sind ressourcenrelevante Aspekte des Softwareprodukts für Nutzende mit vernünftigem Aufwand nachvollziehbar? Können Nutzende die Daten, die sie mit dem Softwareprodukt erzeugt haben, mit anderen Softwareprodukten weiterverwenden?
Sind die Datenformate (Datei- oder Datenstromformate), die das Softwareprodukt zur Ablage der von Nutzenden erzeugten Daten oder zum Austausch von Daten mit anderen Programmen verwendet, ausreichend dokumentiert, um Interoperabilität zu ermöglichen? Folgen die Datenformate offenen Standards, so dass eine Weiternutzung der Daten mit einem anderen Softwareprodukt möglich ist?*
Zur Anwendung dieses Kriteriums muss definiert sein, welche Standards zum Zeitpunkt der Vergabe zu den offenen Standards gezählt werden.
Indikatoren:
a) Überprüfung der Handbücher und technischen Datenblätter, ob Datenformate ausreichend dokumentiert sind
b) Abgleich mit bekannten und offenen Standards
* Dies ist entscheidend für Vermeidung einer Abhängigkeit vom Softwareprodukt (Customer Lock-In), welche unnötigen Ressourcenverbrauch erzwingen kann, sowohl im Falle der Beibehaltung eines ineffizienten Produkts als auch im Falle eines (aufwändigen) Umstiegs auf ein anderes Produkt.
Sind Anwendungs-Programmier-Schnittstellen (APIs) klar dokumentiert und wird die Verbreitung und Weiterentwicklung des Programms unterstützt? Folgen die Schnittstellen offenen Standards, die Interoperabilität ermöglichen?
Die Gewichtung der Indikatoren ist möglicherweise stark kontextabhängig. Die Auswirkung von offenem Quellcode und bestimmter Lizenzmodelle auf die Beanspruchung von Ressourcen kann nicht im Sinne einer generellen Regel beurteilt werden.
Indikatoren:
a) Wenn es APIs gibt: Überprüfung der Schnittstellendokumentation anhand der Dokumentation des Softwareprodukts und seiner APIs
b) Ist der Quellcode vollständig offengelegt?
c) Ist die Software unter einer Lizenz veröffentlicht, die es erlaubt, die Software weiterzuentwickeln?
Kann das Softwareprodukt über längere Zeiträume genutzt werden, ohne dass schwerwiegende Nachteile (insbesondere Probleme der IT-Sicherheit) auftreten, und hat der Nutzende die Wahl, unnötige Updates zu vermeiden?*
Indikatoren:
a) Wie lang ist der Zeitraum, für den der Anbieter die zukünftige Unterstützung des Produkts mit Sicherheitsupdates garantiert?
b) Reagiert der Hersteller zeitnah auf das Bekanntwerden von Sicherheitslücken?
c) Kann der Nutzende durch Konfiguration die Updatehäufigkeit beeinflussen und dabei insbesondere zwischen Sicherheitsupdates und sonstigen Updates differenzieren?
d) Besteht die Möglichkeit, nur differenzielle Updates zu erhalten?**
* Eine hohe Updatefrequenz verursacht Ressourcenverbrauch und erschwert die Aufrechterhaltung von Transparenz. Das Kriterium der Notwendigkeit von Updates ist grundsätzlich schwer objektivierbar; eine Unterscheidung zwischen sicherheitsrelevanten (und damit zweifellos notwendigen) und anderen Updates ist in jedem Fall sinnvoll und wird daher durch Indikator b) adressiert.
** Dies vermeidet den Austausch des kompletten Programms, der bei häufigen Updates erheblichen Ressourcenaufwand verursachen kann.
Macht das Softwareprodukt die Nutzenden darauf aufmerksam, dass es im Hintergrund automatisch Prozesse startet oder weiterlaufen lässt, die möglicherweise nicht genutzt werden?
Indikatoren:
a) Prüfung anhand der Installation und der Ausführung von Standardnutzungsmustern, welche Prozesse das Softwareprodukt automatisch startet und ob es darauf aufmerksam macht (es macht auf alles aufmerksam/auf einiges/macht nicht aufmerksam)
b) Wenn das Softwareprodukt beim Systemstart automatisch gestartet wird („Autostart“): Macht es darauf aufmerksam, dass dies der Fall ist?
c) Wenn der Nutzende eine Aktion durchführt, die als Beendigung des Programms aufgefasst werden kann, aber mindestens einer der Prozesse noch aktiv bleibt: Macht das Softwareprodukt darauf aufmerksam?
Lässt sich das Softwareprodukt einfach, rückstandsfrei und ohne vermeidbare Nachteile deinstallieren?
Werden Nutzende ausreichend darin unterstützt, das Softwareprodukt rückstandsfrei zu deinstallieren?
Indikatoren:
a) Deinstallation der Software und Vergleich mit dem Zustand vor der Installation, der gleich sein muss.
Werden Nutzende ausreichend darin unterstützt, die während des Betriebs des Softwareprodukts generierten Daten, die sie nicht explizit angelegt haben, nach Bedarf zu löschen?
Dieses Kriterium zielt darauf ab, dass die vorübergehende Nutzung eines Softwareprodukts keine Datenspuren hinterlässt, wenn die Nutzenden dies nicht wünschen. Wenn später beispielsweise eine andere Version des Produkts oder ein Konkurrenzprodukt installiert wird, soll die Historie für die neue Software nicht erkennbar sein. Damit soll Lock-In-Effekten und der Missachtung von Datenschutzprinzipien vorgebeugt werden.
Indikatoren:
a) Ist der Zustand nach dem Löschen der nicht durch den Nutzer ausdrücklich gespeicherten Daten mit dem Zustand vor der Installation in relevanter Hinsicht identisch?
b) Macht das Softwareprodukt transparent, wo die explizit angelegten Daten gespeichert werden (Speicherort)?
c) Wird der Nutzende dabei unterstützt, die auf entfernten Speicherkapazitäten angelegten Datenbestände zu löschen?
Bietet das Softwareprodukt einfach zu benutzende Funktionen, die es erlauben, eingetretene Schäden an Daten und Programmen zu beheben?
Lässt sich der letzte Zustand der Daten nach einem unerwünschten Programmabbruch wiederherstellen?
Indikatoren:
a) Macht der Hersteller dazu Angaben, und lassen sich diese im Test bestätigen?
b) Ist der Zeitraum, in dem Änderungen an den Daten zwischengespeichert werden, parametrisierbar?
Lässt sich die installierte Instanz des Softwareprodukts nach dem Eintreten eines inkonsistenten Zustands wiederherstellen?
Indikatoren:
a) Herstellerangaben und Überprüfung durch Test
Lässt sich das Softwareprodukt möglichst unabhängig von Hardwarekapazitäten betreiben, die nicht der Kontrolle der Nutzenden unterliegen?
Zu welchem Grad vermeidet das Softwareprodukt Zwänge zur Konnektivität, die nicht aus der Funktionserfüllung resultieren?*
Indikatoren:
a) Überprüfung durch Standardnutzungsszenario (Offline-Betrieb möglich/mit Einschränkungen möglich/unmöglich)
* Beispiele für unnötige Konnektivitätszwänge: Verbindung zum Lizenzserver herstellen, wiederholtes Herunterladen von Fonts notwendig.
Unterstützt die angebotene Information über das Softwareprodukt seine ressourcenschonende Nutzung?
Sind alle Angaben für die Nutzenden leicht nachvollziehbar?
Indikatoren:
a) Augenscheinprüfung durch Prüfende; Test mit tatsächlichen Nutzenden
Enthält die Produktinformation alle Angaben, die die Nutzenden benötigen, um die Ressourcenbeanspruchung durch das Softwareprodukt gering zu halten, in strukturierter Form, und sind die Angaben korrekt?
Langfristiges Ziel ist die Entwicklung standardisierter Produktbeschreibungen für ressourcenrelevante Produktinformation. Sobald es hierzu einen befriedigenden Standard gibt, kann seine Einhaltung als Indikator aufgenommen werden.
Indikatoren:
a) Qualitative Beurteilung der Vollständigkeit und Verständlichkeit
b) Bezieht sich die Produktinformation auf die aktuelle Produktversion?
c) Augenscheinprüfung der Korrektheit der Angaben (Angaben sind schlüssig / eingeschränkt schlüssig / nicht schlüssig)
| 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. |
Sie verlassen die offizielle Website der Hochschule Trier
