Unmittelbare Kriterien und Metriken

Im Gegensatz zu den bereits genannten Effizienzkriterien, die als Indikatoren für Energieeffizienz angesehen werden können (vgl. Wang et al. 2011; Kansal et al. 2010), ist es auch direkt möglich, die Energieeffizienz eines Systems im Vergleich zu einem Referenzsystem zu bewerten (vgl. Dick et al. 2011; Standard Specification TPC-Energy 1.2.0). Daher wird der Qualitätsaspekt Energieeffizienz, der zur Qualitätseigenschaft Effizienz gehört, den unmittelbaren Kriterien und Metriken zugerechnet (vgl. Naumann et al. 2011, S. 299).

Ebenfalls zu den unmittelbaren Kriterien und Metriken wird der Aspekt der Hardware-Obsoleszenz gerechnet (vgl. Albertao et al. 2010; Hilty 2008, S. 170; Naumann et al. 2011, S. 299). Sie berücksichtigt die Menge an Hardware, die auf Grund höherer Systemanforderungen der eingesetzten Software ausgetauscht bzw. ersetzt werden muss, noch bevor das Produkt das Ende seiner sinnvollen Lebensdauer im Hinblick auf eine nachhaltige Nutzungszeit erreicht hat.

Die Qualitätseigenschaft Prozessnachhaltigkeit bewertet die Wirkung der Produktentwicklung bzw. des Softwareentwicklungsprozesses auf die Nachhaltige Entwicklung. Die wesentlichen Aspekte dieser Eigenschaft umfassen Reisen (vgl. Albertao et al. 2010), den CO2-Fußabdruck, den Energieverbrauch und die Vergeudung von Ressourcen während der Softwareentwicklung (vgl. (Taina 2011, S. 24; Naumann et al. 2011, S. 296–298). Der Aspekt Reisen umfasst die für ein Softwareprojekt notwendigen Dienstreisen und ggf. auch die täglichen Wege zum Arbeitsort. Mögliche Metriken sind Work from Home Days und Long-Haul Roundtrips (vgl. Albertao et al. 2010). Der CO2-Fußabdruck gibt an, wie viel CO2 durch die Softwareentwicklung emittiert wird. Der Aspekt Energieverbrauch gibt den Energieverbrauch an, der durch die Softwareentwicklung hervorgerufen wurde. Im Gegensatz zum CO2-Fußabdruck bleibt hier die Methode, mit der die Energie erzeugt wird, unbeachtet (vgl. Taina 2011, S. 24), sodass auch die Energie aus erneuerbaren Quellen berücksichtigt wird. Der Aspekt der Vergeudung gibt an, wie viel Ressourcen während der Softwareentwicklung für Aktivitäten verbraucht wurden, die keinen sichtbaren Wert für Kunden bzw. Endanwender generiert haben (vgl. Taina 2011, S. 24).