To what extent are hardware replacement cycles decoupled from software replacement cycles?1
Software imposes requirements on the hardware on which it is executed. The faster these requirements increase as the software product is developed further, and the more specific they are, the more they limit the use of hardware products already in existence. If existing hardware products cannot be used, or can no longer be used, to execute the given software product, then this shortens the operating life of the hardware.
The ideal is a software product whose development dynamics permit operators to manage their hardware products independently of these dynamics, i.e., decouple hardware management from software management.
Does the manufacturer of the software product guarantee that the current release can be executed on a reference system that is n years old?*
a) Initially use the specification by the manufacturer (hardware, older operating systems, older frameworks), since no standard configurations have been defined for previous years
b) When this criterion has been applied for a long enough time periode, so that the standard usage scenario can also be executed on earlier standard configurations as well: Can the standard usage scenario still be executed with the current release of the software product on a configurations that was the standard configuration n years ago?
* Thus, the software product can be executed on a standard hardware configuration that has already been in operation for n years.
Can the software product be executed on different currently prevalent productive system environments (hardware and software), and can users switch between them without disadvantages?*
a) Manufacturer specifications (compatible with various operating systems, runtime environments)
b) Execute standard usage scenario on various currently prevalent productive system environments and check for portability of data and software settings
* We recommend that this criterion should not be considered one of the minimum requirements because in principle, there could be very resource-efficient software that runs on just one platform. Nonetheless, platform independence is to be considered beneficial since it gives users more freedom when optimizing procurement of hardware and system software.
Does the amount of hardware capacity used remain constant over time as the software product is developed further and additional functions are added?
This criterion rewards software manufacturers who make it easy for their customers to continue to use their existing hardware. It intentionally does not take into account whether functionality is expanded. Sufficiency means that the amount of resources required will not increase even if the utility they provide increases (which is possible, after all, because of increasing efficiency).
The ideal is a software product that fulfills more and more requirements from one version to the next, but nonetheless does not increase its hardware requirements.
This criterion can be applied only when products have already been assessed several times, i.e., when at least one previous result is available.
a) intertemporal comparisons with the following imaginable results:
|Energy efficiency||Generally, the amount of “useful work” divided by the amount of energy it requires. In the context of this document, “useful work” is operationalized as the successful execution of standard usage scenarios.|
|Hardware||The material goods required to run programs or to store or transport data.|
|Hardware capacity||Quantifiable characteristic of a hardware system which represents its performance limit on a given dimension of performance (e.g., working memory capacity, computing power, bandwidth).|
|Hardware system||Delimitable unit of hardware that performs defined functions.|
|Indicator||An empirically determinable quantity that provides insight into a matter that cannot be measured directly. The indicators proposed in this document have different levels of measurement. In some cases, researchers will have to settle for an ordinal scale (e.g., “insufficient”, “sufficient”, “good”, “very good”, or even merely “fulfilled”, “not fulfilled”) to avoid giving the false impression of non-existent precision arising from a cardinal scale.|
|Reference system||A hardware system that is defined as generally customary in terms of its most important capacities (e.g., working memory, processor performance) during a defined period of time (e.g., one year). The purpose of the reference system is to be able to express indicators such as “minimum local memory” in relation to a reference value (currently “customary” memory).|
|Resource||In the context of this document, a natural resource, in particular a raw material, a form of energy, or also the capacity of an environmental medium to absorb emissions. To differentiate natural resources from technical ones, especially hardware resources, the more precise term “hardware capacities” is used here for the latter. Since using hardware capacities always results in using natural resources, this distinction (which ultimately amounts to a definitionally difficult differentiation between the ecosphere and the technosphere) is not of decisive importance here.|
|Resource efficiency||Generally, the amount of “useful work” divided by the amount of resources it requires. In the context of this document, “useful work” is operationalized as the successful execution of standard usage scenarios.|
|Software||Programs and data in digital form.|
|Software product||A delimitable unit of programs and data for which a license is available.|
|Standard configuration||A set of conditions, defined as a reference, under which a given software product is run; it includes the parameter settings selected during installation or operation, the system software provided, potentially additional software products required for operation, as well as the reference system at the hardware level.|
|Standard usage scenario||A usage scenario that is used for testing a software product and is supposed to be as representative as possible for the customary use case.|
|Usage pattern||Abstracted form of a sequence of interactions with a given software product.|
|Usage scenario||Description of a usage pattern which is generally machine executable.|
 Decoupling software and hardware replacement cycles amounts to long potential hardware operating life. Basic assumption: Every software product requires a system environment as the platform on which it is executed. The system environment is defined as the sum of the hardware and software components of the ICT system that are required for executing the software product. The software product itself can be part of the system environment of other software products.
Example: A web browser requires an operating system, additional system software, and hardware as a system environment, and at the same time it constitutes the system environment for a web application. From the perspective of a given software product, the following question is crucial to understand its influence on hardware operating life: when the software product is replaced by a newer version, which requirements to the lowest level—the hardware—does this generate via the intermediate levels of the system environment?
You are leaving the official website of Trier University of Applied Sciences