zurück ⇧

3 Nutzungsautonomie

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.

3.1 Transparenz und Interoperabilität

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?

3.2 Deinstallierbarkeit

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?

3.3 Wartungsfunktionen

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

3.4 Unabhängigkeit von Fremdressourcen

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.

3.5 Qualität der Produktinformation

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)