Developing a Test Framework to measure Software Sustainability

Sustainable Software Development brings together principles and practices for building software that
is technically superior, delivers exceptional business value, and can evolve rapidly to reflect any
change to your business or technical environment. A sustainable software is a software that is long
lasting, lean and has a positive impact on the environment as well as promotes sustainable human
behavior. The three aspects mentioned in the definition are explained below:Long Lasting :-How well a piece of software will be able to cope with changes. In other words, the goal is
to build "long lasting" software. This in turn relates to qualities such as reliability, (self-)adaptability,
maintainability or context-awareness of software, as well as to development paradigms such as Agile
Lean Software:- Direct environmental impacts of software, such as energy consumption and e-waste
from computers made obsolete due to software upgrades (see custom software development services). In
this sense a sustainable software is one that requires few hardware capacity and reduces its own power
consumption. We could call it "lean" software.
Supports sustainable human behavior :- indirect effects of software on the environment. In this sense
a sustainable software is one that induces sustainable human behaviours. There are an infinity of
examples, as software has invaded all our activities, in daily life or business, and most have an impact on
the way we behave. Consequently, any piece of software should be designed in the awareness of its
impacts on human sustainability. We may cite e-bay, which fosters reuse of physical goods, or paper
virtualization platforms, which reduce the use of paper in offices, or google maps' ability to show you
public transportation routes towards your destination...

Just like any other Testing Sustainability too has to be done throughout the life-cycle
of software development phase using verification and validation techniques.
Software sustainability impact needs to be checked for during development, usage
and its maintenance phase.
Applications today can be classified into the following:-

Application Types

Distributed Application

Desktop based
Application

Commercial
Application

Scientific Application

Educative Application

Web based Application

Cloud Application

Commercial
Application

Commercial
Application

Scientific Application

Scientific Application

Educative Application

Educative Application

Social Networking
Application

Each of the above given applications that are developed today may have its
own sustainability indicators for assessment. Some sustainability indicators are also
overlapping across various applications. Each of these sustainability indicators are
meant to be applied at various stages of the software development life cycle viz.

The Development phase,

Usage phase and
Maintenance phase.

Applications need to be assessed against their sustainability indicators at various

phases of SDLC. The following are the list of various sustainability indicators for the
above given software systems grouped into three categories as social, economic
and environmental further grouped on the basis of phases where it needs to be
evaluated and would have its impact.
Sustainability Indicators for Desktop based Commercial Applications
SOCIAL

ECONOMIC

Developme
nt

Usage

Maintenance

Develop
ment

Portability

Usability

Governance

Supportabil
ity

Community

Analysability

Reliability

Accessibilit

Evolvability

Usa
ge

ENVIRONMENTAL

Maintenanc
e

Develop
ment

Reusabilit
y of code

Testability

Energy
Efficient
Code
Identity

Changeabili
ty

Energy
Efficient
Code
Legality

Adaptability

Procurm

Usa
ge

Mainten
ance

y
Security

Performanc
e
Robustness
Process
Methodolo
gy
Predictabili
ty
Functional
Suitability

ent
testing

One click
Report
generation
ability
Fault
Tolerance
Test
Failure
Testing
Power
Manageme
nt Testing

Interoperabi
ty

Copyright

Licensing

Modularity

Understa
ndability

Scalability
Test for
emulator

Agile and iterative model supports sustainability as constant feedback can be

received from the customers pertaining to the product. These provides less room for
errors and ensure that the product is developed exactly as per the given
requirements. Waterfall model would lead to less sustainable software as it does not
incorporate changes during the SDLC phase.
Sustainability Indicators for Desktop based Scientific Applications
SOCIAL
Develop
ment

Usage

ECONOMIC
Maintena
nce

Develop
ment

Usage

Maintenan
ce

ENVIRONMENTAL
Develop
ment

Usage

Maintena
nce

Sustainability Indicators for Desktop based Educative Applications

SOCIAL
Develop
ment

Usage

ECONOMIC
Maintena
nce

Develop
ment

Usage

Maintena
nce

ENVIRONMENTAL
Develop
ment

Usage

Maintena
nce

Sustainability Indicators for Distributed Web based Commercial

Applications
SOCIAL
Develop

Usage

ECONOMIC
Maintena

Develop

Usage

Maintena

ENVIRONMENTAL
Develop

Usage

Maintenan

ment

nce

ment

nce

ment

ce

Sustainability Indicators for Distributed Web based Scientific Applications

SOCIAL
Develop
ment

Usage

ECONOMIC
Maintena
nce

Develop
ment

Usage

Maintena
nce

ENVIRONMENTAL
Develop
ment

Usage

Maintena
nce

Sustainability Indicators for Distributed Web based Educative Applications

SOCIAL
Develop
ment

Usage

ECONOMIC
Maintenan
ce

Develop
ment

Usage

Maintenan
ce

ENVIRONMENTAL
Develop
ment

Usage

Maintena
nce

Sustainability Indicators for Distributed Cloud based Commercial

Applications
Social
Develop
ment

Economic
Usage

Maintena
nce

Develop
ment

Usag
e

Environmental
Maintenanc
e

Develop
ment

Usage

Maintenan
ce

Sustainability Indicators for Distributed Cloud based Scientific

Applications
Social
Develop
ment

Economic
Usage

Maintena
nce

Develop
ment

Usage

Environmental
Maintena
nce

Develop
ment

Usage

Maintenan
ce

Sustainability Indicators for Distributed Cloud based Educative

Applications
Social
Develop
ment

Economic
Usage

Maintena
nce

Develop
ment

Usage

Environmental
Maintena
nce

Develop
ment

Usage

Maintena
nce

Examples of Efficiency Criteria

Memory consumption

CPU-intensity

Software induced resource consumption

Software induced energy consumption

Examples of Environmental Criteria

Portability

Data medium

Download size

Level of dematerialization

Examples of Social Criteria

Working conditions

Manuals

The ISO 9126-1 software quality model identifies 6 main quality

characteristics, namely:
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
These characteristics are broken down into subcharacteristics, a
high level table is shown below. It is at the subcharacteristic level
that measurement for SPI will occur. The main characteristics of
the ISO9126-1 quality model, can be defined as follows:Functionality

Functionality is the essential purpose of any product or service. For

certain items this is relatively easy to define, for example a ship's
anchor has the function of holding a ship at a given location. The
more functions a product has, e.g. an ATM machine, then the more
complicated it becomes to define it's functionality. For software a
list of functions can be specified, i.e. a sales order processing
systems should be able to record customer information so that it
can be used to reference a sales order. A sales order system should
also provide the following functions:
Record sales order product, price and quantity.
Calculate total price.
Calculate appropriate sales tax.
Calculate date available to ship, based on inventory.
Generate purchase orders when stock falls below a given
threshold.
The list goes on and on but the main point to note is that
functionality is expressed as a totality of essential functions that
the software product provides. It is also important to note that the
presence or absence of these functions in a software product can
be verified as either existing or not, in that it is a Boolean (either a
yes or no answer). The other software characteristics listed (i.e.
usability) are only present to some degree, i.e. not a simple on or
off. Many people get confused between overall process functionality
(in which software plays a part) and software functionality. This is
partly due to the fact that Data Flow Diagrams (DFDs) and other
modeling tools can depict process functionality (as a set of data
in\data out conversions) and software functionality. Consider a
sales order process, that has both manual and software
components. A function of the sales order process could be to
record the sales order but we could implement a hard copy filing
cabinet for the actual orders and only use software for calculating

the price, tax and ship date. In this way the functionality of the
software is limited to those calculation functions. SPI, or Software
Process Improvement is different from overall Process
Improvement or Process Re-engineering, ISO 9126-1 and other
software quality models do not help measure overall Process
costs\benefits but only the software component. The relationship
between software functionality within an overall business process is
outside the scope of ISO 9126 and it is only the software
functionality, or essential purpose of the software component, that
is of interest for ISO 9126.
Following functionality, there are 5 other software
attributes that characterize the usefulness of the software
in a given environment.
Each of the following characteristics can only be measured (and
are assumed to exist) when the functionality of a given system is
present. In this way, for example, a system can not
possess usability characteristics if the system does not function
correctly (the two just don't go together).

Reliability
Once a software system is functioning, as specified, and delivered
the reliability characteristic defines the capability of the system to
maintain its service provision under defined conditions for defined
periods of time. One aspect of this characteristic is fault
tolerance that is the ability of a system to withstand component
failure. For example if the network goes down for 20 seconds then
comes back the system should be able to recover and continue
functioning.
Usability
Usability only exists with regard to functionality and refers to the
ease of use for a given function. For example a function of an ATM
machine is to dispense cash as requested. Placing common

amounts on the screen for selection, i.e. $20.00, $40.00, $100.00

etc, does not impact the function of the ATM but addresses the
Usability of the function. The ability to learn how to use a system
(learnability) is also a major subcharacteristic of usability.
Efficiency
This characteristic is concerned with the system resources used
when providing the required functionality. The amount of disk
space, memory, network etc. provides a good indication of this
characteristic. As with a number of these characteristics, there are
overlaps. For example the usability of a system is influenced by the
system's Performance, in that if a system takes 3 hours to respond
the system would not be easy to use although the essential issue is
a performance or efficiency characteristic.
Maintainability
The ability to identify and fix a fault within a software component is
what the maintainability characteristic addresses. In other software
quality models this characteristic is referenced as supportability.
Maintainability is impacted by code readability or complexity as
well as modularization. Anything that helps with identifying the
cause of a fault and then fixing the fault is the concern of
maintainability. Also the ability to verify (or test) a system, i.e.
testability, is one of the subcharacteristics of maintainability.
Portability
This characteristic refers to how well the software can adopt to
changes in its environment or with its requirements. The
subcharacteristics of this characteristic include adaptability. Object
oriented design and implementation practices can contribute to the
extent to which this characteristic is present in a given system.

The full table of Characteristics and Subcharacteristics for the ISO

9126-1 Quality Model is:Characterist Subcharacteri
ics
stics

Definitions

Suitability

This is the essential Functionality characteristic and

refers to the appropriateness (to specification) of
the functions of the software.

Accurateness

This refers to the correctness of the functions, an

ATM may provide a cash dispensing function but is
the amount correct?

A given software component or system does not

Functionali Interoperabilit typically function in isolation. This subcharacteristic
ty
y
concerns the ability of a software component to
interact with other components or systems.

Reliability

Compliance

Where appropriate certain industry (or

government) laws and guidelines need to be
complied with, i.e. SOX. This subcharacteristic
addresses the compliant capability of software.

Security

This subcharacteristic relates to unauthorized

access to the software functions.

Maturity

This subcharacteristic concerns frequency of failure

of the software.

Fault
tolerance

The ability of software to withstand (and recover)

from component, or environmental, failure.

Recoverability

Ability to bring back a failed system to full

operation, including data and network connections.

Determines the ease of which the systems

Understandabi functions can be understood, relates to user
lity
mental models in Human Computer Interaction
methods.
Usability

Learnability

Learning effort for different users, i.e. novice,

expert, casual etc.

Operability

Ability of the software to be easily operated by a

given user in a given environment.

Efficiency

Time behavior

Characterizes response times for a given thru put,

i.e. transaction rate.

Resource
behavior

Characterizes resources used, i.e. memory, cpu,

disk and network usage.

Analyzability

Characterizes the ability to identify the root cause

of a failure within the software.

Maintainab
Changeability
ility

Portability

Characterizes the amount of effort to change a

system.

Stability

Characterizes the sensitivity to change of a given

system that is the negative impact that may be
caused by system changes.

Testability

Characterizes the effort needed to verify (test) a

system change.

Adaptability

Characterizes the ability of the system to change

to new specifications or operating environments.

Installability

Characterizes the effort required to install the

software.

Conformance

Similar to compliance for functionality, but this

characteristic relates to portability. One example
would be Open SQL conformance which relates to
portability of database used.

Replaceability

Characterizes the plug and play aspect of software

components, that is how easy is it to exchange a
given software component within a specified
environment.

ISO 9126 Observations

For the most part, the overall structure of ISO9126-1 is similar to

past models, McCall (1977) and Boehm (1978), although there are
a couple of notable differences. Compliance comes under the
functionality characteristic, this can be attributed to government
initiatives like SOX. In many requirements specifications all
characteristics, that are specified, that are not pure functional
requirements are specified as Non-Functional requirements. It is
interesting to note, with ISO9126, that compliance is seen as a
functional characteristic.

Using the ISO 9126 (or any other quality model) for derivation of
system requirements brings clarity of definition of purpose and
operating capability .
For example a rules engine approach to compliance would enable
greater adaptability, should the compliance rules change. The
functionality for compliance could be implemented in other ways
but these other implementation methods may not produce as
strong an adaptability characteristic as a rules, or some other
component based, architecture.
Also, a designer typically will need to make trade offs between two
or more characteristics when designing the system. Consider
highly modularized code, this code is usually easy to maintain, i.e.
has a good changeabilitycharacteristic, but may not perform as
well (for cpu resource, as unstructed program code). On a similar
vein a normalized database may not perform as well as a not
normalized database. These trade offs need to be identified, so
that informed design decisions can be made.
Although ISO 9126-1 is the latest proposal for a useful Quality
Model, of software characteristics, it is unlikely to be the last. One
thing is certain, the requirements (including compliance) and
operating environment of software will be continually changing and
with this change will come the continuing search to find useful
characteristics that facilitate measurement and control of the

software production process.

The sustainable software engineering cycle is accompanied by a set of software quality properties,
which are the usual ones known from software engineering plus an additional new one, called Projects
Footprint. The regular properties are interpreted regarding their sustainability benefit for each of the
three pillars economy, society, and environment. The interpretation includes:

development (compile time) related

properties: Modifiability, Reusability,Portability, Supportability
usage (runtime) related properties: Performance, Dependability, Usability,Accessibility
software process related properties: Predictability, Efficiency, Projects Footprint
Following, I give a brief description of Albertaos interpretation of the property Portabilityand his newly
introduced property Projects Footprint. Both are accompanied with appropriate metrics.
The property Portability is measured by the metric Estimated System Lifetime1:7. The environmental
benefit is to maximize the useful lifetime of computer hardware instead of forcing its early
obsolescence due to steadily rising hardware requirements of software systems 2:372.
The property Projects Footprint is measured by four metrics:

the Conference Call Rate is the number of virtual meetings per number of total meetings 1:8-9

the Meetings Rate is the number of total meetings per number of total project weeks 1:8-9

the Work-From-Home Days is the number of person days of work from home per total number
of person days2:372

the Long-Haul Roundtrips lists the absolute number of trips by mean of travel 2:372
The Conference Call Rate should be as high as possible, whereas the Meetings Rateindicates that there
are not too few meetings for valid interpretation of the call rate. The Work-From-Home Days metric
should be as high as possible, which means that emissions from commuting are avoided due to
telework. The Long-Haul Roundtrips values report the absolute number of trips by plane or train (longhaul trips by coach or car are not explicitly mentioned).
Round-Up

Albertaos method introduces a vaguely defined low ceremony improvement cycle that can be
implemented in any software process. In addition to the process description, it comes with an
interpretation of high level software quality properties and metrics that can be used to measure certain
aspects regarding the sustainability interpretation. Besides the traditional quality properties, Projects
Footprint is newly introduced to measure travel and commuting related aspects of a software project
that have an impact on the environment. However, the Long-Haul Roundtrips metric will be better
interpretable if it compares the distances and the carbon dioxide emissions for the chosen means of
travel for all business trips of a software project. This will give us enough meta information to decide
whether the taken choice can be justified or whether it was thoughtlessly taken for convenience as the
simple numbers of roundtrips by plane or train will do.
The next post in this series on Sustainable Software Processes (expected publication date 2/15/2015
8:00 PM UTC+1) will summarize our own approach of a sustainable software process 3,4, which was
influenced by Albertao. It was first published in 2010 and then further refined in 2013.

Procedure Model Purchase

According to the procurement process, two different roles of purchasers need to be taken into account. On the one
hand, there are governmental organizations and large enterprises that use structured tendering procedures in large
scale procurement projects, on the other hand, home users as well as small and micro enterprises must not be
ignored. Indeed, the potential to pursue sustainability goals of the first group is much higher.

Nowadays, especially larger companies and governmental organizations do have a sustain-ability report, which can
influence procurement processes. To visualize the typical steps of purchasing software products while focusing on
sustainability issues, we created an exemplary procedure model that fits into the purchase category.
In both cases, governmental as well as in private environments, the requirements of the software product need to be
defined first. Apart from technical requirements, the Life Cycle Costs (LCC) of the product need to be taken into
account. In that way, the entire product life cycle of the software product and the entire supply chain is already
addressed in the procurement process. The results of the first step are criteria comprising mandatory and optional
requirements. It is advisable to create checklists for the entire software product with these criteria. The checklists can
re-gard energy efficiency criteria, environmental criteria, as well as social criteria and complete the non-functional
criteria for a software product.

Examples of Efficiency Criteria

Memory consumption

CPU-intensity

Software induced resource consumption

Software induced energy consumption

Examples of Environmental Criteria

Portability

Data medium

Download size

Level of dematerialization

Examples of Social Criteria

Working conditions

Manuals
For further criteria refer to our life cycle thinking inspired software product lifecycle.
Based on the checklists and criteria, the procurement process goes on with selecting possible bidders, evaluating
bids, and finally concluding the contract or rather buying the soft-ware product. That means that the persons
responsible for purchasing must not lose sight of the sustainability issues during the whole process. In practice that
means e.g. that appropriate criteria, like the companys social and environmental responsibility, their commitment to
international labor standards [1] or the application of environmental management systems [2], are integrated into the
selection process.
The complexity of the complete procurement process differs from case to case. It depends on the environment in
which the software product will be used. In case of micro and small enterprises, as well as home users, the process
will be less comprehensive. Generally, standard software will be chosen. For standard software products, energy
efficiency and hardware obsolescence criteria can either be used as technical requirements or as award criteria.
Usually, their limit values and weighting in the selection procedure must be documented in the tendering documents.
This implies that these cannot be altered after the tendering procedure has started. It is possible that a larger
enterprise also decides to purchase standard software products, but custom software products are more common in
this surrounding. For custom software, non-functional requirements like energy efficiency or requirements addressing
mitigation of IT infrastructure obsolescence, which may be included by the tendered software product, can be
defined.
In contrast to the hardware side, so far there are no labels for green and sustainable soft-ware. We advocate a label
for software products similar to the ENERGY STAR [3] that indicates that a software product is energy efficient or
meets certain sustainability requirements. Additionally, information on sustainable issues should be easily obtained
especially for home users. Such information could be printed on product boxes or product sheets so that the user can
make informed decisions on which product fits their needs best.
In order to accomplish this, it is necessary to provide measurement methods and typical usage scenarios to endow
bidders and users with acceptable maximum measurement values. In this context, we propose a method to measure
and rate software-induced energy consumption.

Recommendations for a Green Web for

Developers
Support Caching on the Server Side
The caching capabilities of HTTP are designed to reduce the amount of HTTP requests and transferred data volume
significantly. Content that is dynamically generated by scripts or programs on the server side is usually not treated to
be cacheable and therefore not tagged with caching metadata by default.
However, there may be cases where dynamic content changes less frequently than once for each request. Therefore
caching it may be possible without the risk of presenting obsolete data to visitors. In our opinion the following tasks
are important:

retrieving presented content dynamically out of content repositories

presenting dynamically generated charts as images

Concerning the first point, well-engineered content management systems may be configured to use some kind of
caching strategy and to support Expires and Last-Modified headers. Hence, we focus on websites or web
applications that are not run via a Content Management System (CMS), but are implemented directly in scripts and
programs. For instance, assuming a web based application that collects power meter readings of a family home,
calculates its power consumption daily and presents it in charts on a website, the Last-Modified date can be set to the
date and time where the last meter reading has been inserted into the database.
We recommend that web developers implement support for Expires and Last-Modified headers in their web programs
and scripts whenever possible, to decrease the transferred data volume and thus power consumption. The following
example code shows how this may be realized in principle, with the PHP scripting language. A more sophisticated
example is given by Nottingham (2009).
header('Expires: ' . toGMT($expires));
header('Last-Modified: '.toGMT($lastMod));
if(!isModifiedSince($lastMod)) {
header('HTTP/1.1 304 Not Modified');
exit();
}
echo 'ANY CONTENT';
At first, the Expires header is set to a date that is acceptable for the given content type, to assume its freshness. The
Last-Modified header is set with a value that indicates when the underlying content was modified last. After setting the
headers, the Last-Modified-Since header of the HTTP request is compared against the Last-Modified date of the
content. If the content of the browser cache is still valid, the HTTP Not-Modified status is sent. Otherwise the content
is sent with an HTTP Ok status.

Minimize JavaScript
JavaScript is used widely on websites to enhance interactivity. JavaScript code fragments are often embedded
directly in HTML or in specific JavaScript files. The former increases the response size, whereas the latter increases

the amount of HTTP requests especially when more than one JavaScript file is used in a website. To minimize HTML
content size we suggest externalizing any JavaScript code fragments embedded in HTML into special JavaScript
files. On the one hand, this results in an extra HTTP request, but on the other hand it
1.

enables browsers to cache these files and to provide them in subsequent requests without calling the origin
server

2.

reduces the HTML download size especially when the HTML content can not be cached because it must be
recalculated for each request

If JavaScript code resides in dedicated files, we recommend defining distinct Expires header rules in web server
configurations, so that these files expire further in the future than the HTML content files do (assuming that HTML
content changes more frequent than the technical framework).
If more than one JavaScript file is used in a website, it may save some HTTP requests if these files are merged into
one file. Despite increasing the JavaScript filesize, the number of transferred bytes is a little bit smaller, because only
one HTTP request must be sent and probably revalidated when users are pressing the reload button in their web
browser.
The JavaScript filesize can be significantly minimized by removing all unnecessary whitespace characters or
comments. It can be further reduced by removing all functions, methods or code blocks that are not needed within a
particular website. This is true for websites that use only a few functions or methods of huge JavaScript libraries.
Another technique is obfuscation. Most available tools first apply the minimization technique and than shrink the code
by substituting variable, method or function identifiers and also method and function parameter names with shorter
ones. Self defined API functions referenced within HTML code must remain untouched, of course.
Table 1: Minimization vs. obfuscation vs. compression.
prototype-1.6.0.3.js

Uncompressed (KB)

GZIP compressed (KB)

Total size

126.70

28.49

Minimized size JSMin

93.09

22.71

Obfuscated size Dojo ShrinkSafe

87.66

24.94

Table 1 compares the effectiveness of the minimization tool JSMin (http://javascript.crockford.com/) against that of the
obfuscation tool ShrinkSafe (known from the popular Dojo Toolkit http://www.dojotoolkit.org/) while minimizing the well
known JavaScript library Prototype (http://www.prototypejs.org/). As one may notice, obfuscation is more effective
than minimization in the case of special tools used here. This results from the fact that minimization does not
substitute any function identifiers with shorter names as the default obfuscation configuration does. In contrast to
GZIP compression the overall savings of minimization or obfuscation are less effective (and in that special case of
obfuscation even counterproductive, because there are fewer repetitions left in the JavaScript code that may possibly
lead to better compression results). Further comparisons with JavaScript libraries lead to similar results (Dojo Toolkit,
script.aculo.us).
Against this background we recommend to minimize JavaScript with a tool like JSMin and to compress the HTTP
response with GZIP to achieve lower data transfer volumes. We recommend using obfuscation in scenarios where
compression can not be used (e.g. if HTTP clients are not fully compatible with compression algorithms).

Additionally, we recommend minimizing or obfuscating the files before they are deployed on the server instead of
minimizing or obfuscating them dynamically for each HTTP request to save processor time and thus power
consumption.

Minimize and Optimize CSS

Minimizing and optimizing CSS files offers many possibilities to reduce HTTP requests. Savings from 40% to 60% are
possible, if HTML or JavaScript operation is implemented with CSS. Through a layout, which is designed with CSS
(King 2008, p. 177), it is possible to save 25% to 50% of HTML filesize (King 2008, p. 180).
Table 2 shows the filesize of an exemplary CSS stylesheet after optimization and minimization with different
strengths.

Table 2: Comparison of CSS filesizes after minimization.

Without minimization

2,812 Bytes

With standard minimization

2,181 Bytes

With high minimization

2,040 Bytes

With highest minimization

2,021 Bytes

These results were obtained with CSSTidy (http://csstidy.sourceforge.net/). This tool uses some techniques to
optimize CSS code in different ways and strengths. In this case, the standard, high and highest minimizations were
tested.
Standard minimization means that the compression goal is to reach a balance between size and readability. With this
minimization, the file is 631 bytes smaller and the compression ratio is 22.4%. One technique the tool uses are
abbreviations, for example with colour definitions. The long definition{color:#ffcc00;} can be written
as {color:#fc0;}.
The second minimization is "higher"; the readability should be moderate and the size small. The example file was
reduced with this compression by 27.5%. In addition to the other techniques unnecessary whitespaces, strings and
blank lines are deleted. This may constrain the readability but reduce filesize.
The third minimization is the "highest". Its main goal is to achieve the smallest filesize. The readability is not
considered. The compression ratio is the highest: 28.1%. In this case, additionally wordwraps are deleted. The whole
code therefore is in one line.
There are further techniques, which optimize CSS. Examples are to replace inline styles with type selectors, to
remove unnecessary code or to use descendant or contextual selectors instead of inline classes. CSS provides
grouping multiple selectors with the same declaration and grouping multiple declarations with the same selector in
one rule set. Duplicate element declarations can be avoided through the use of inheritance. Some separated property
declarations can be combined in one single declaration. Margin, border, font, background, liststyle and outline are special shorthand notations which combine separate single properties. Names of classes
or IDs should be short or abbreviated. Long names are only important for developers, not for users. On the other
hand, short names should be meaningful for developers in the context, too.
The CSS declarations should generally be saved in an external file and then included in the website documents. This

minimizes the filesize of the web document and the CSS declarations will be loaded once and not with every request
of the website.
CSS can also be used to replace less efficient code. One example is the table definition in HTML, which can be
replaced by CSS. Another point is the usage of embedded JavaScript, as 84.4% of web pages use it. These methods
can often be replaced with more efficient CSS code. Examples are dropdown menus and the rollover effect (King
2008, p. 177).

Optimize Graphical Elements and Logos

54% of an average website is graphics (King 2008, p. 157). Because of this, optimizing images is a promising way to
minimize HTTP responses.
A logo, unlike a picture is a graphical object, which symbolizes mostly a company or an organisation. The logo is
normally included many times in a website. Thus, optimizing the logo can be more efficient than optimizing a picture,
which is mostly shown once on a website.
Typically a logo is not a photograph or chart and in comparison to these smaller, so it can be saved as a GIF or PNG
file. PNG has a better compression algorithm and especially flat-colour images are 10% to 30% smaller than in GIF
(King 2008, p. 169)
There are some possibilities to optimize a logo. The most efficient ones are: changing the colour mode from RGB to
an indexed palette, compressing, saving with special web settings and replacing graphical text with CSS formatted
text.
The following example shows how a logo can be optimized. The logo consists of a graphical object, a background
with colour gradient and graphical text (see Figure 1). The first step is to reduce the colours from RGB to an indexed
palette. In this special case the colours can be reduced to six. Table 4 shows the filesize after optimization.
Table 3: Comparison of PNG filesizes after optimization.
Original logo with RGB colours

16,959 bytes

Logo with 16 colours

2,956 bytes

Logo with 6 colours

1,984 bytes

Logo with 4 colours without text

604 bytes

Figure 1: Original logo with RGB colours.

The next step is the transformation from graphical text to CSS text. First, the graphical text will be deleted from the
image. Afterwards, the text will be included in the image with CSS code, which defines a layer that has the logo as a
background image. The dimensions are equal to the image dimensions. The CSS code for the example is as follows:

div.logo {
margin: 0;
width: 370px;
height: 64px;
padding: 10px 70px;
font: 700 21px "Arial Narrow","Arial",sans-serif;
color: #000;
background-image: url("logo.png");
background-repeat: no-repeat;
}
The final logo with CSS formatted text is shown in Figure 2. Looking at this example the filesize can be reduced from
16,959 bytes to 604 bytes (96% reduction).

Software Development Platform

Umwelt-Campus Birkenfeld
Figure 2: Final logo with 4 colours and CSS font.
Single-pixel, plain-coloured images, e.g. GIFs, are often used to achieve a certain stretching distance. These images
can be replaced with CSS-code, where spacing cells have the same function as the images. This causes the layout
to be the same, but through the usage of CSS the download of the images is not necessary anymore.
Images, which are lying relatively close to each other, can be combined into one picture. Additionally, links on the
single pictures can be set with an image-map (King 2008, p. 165). Another possibility to combine images is to use
CSS sprites. Sprites can be very effective, if many small images like icons are on a website. The required part of the
whole image will be shown with the background-position rule at the designated position on the website (Souders
2007).

Optimize Photographs
The filesize of a photograph is mostly greater than that of a logo. Consequently, there are more options to reduce the
filesize.
reduce the filesize. Generally spoken, images should be stored with special web settings and the dimensions should
be equal to the desired dimensions on the website.
A special technique to reduce the filesize is blurring the background. The blur technique can be used for images,
where some parts are not as important as others (King 2008, p. 169).

Figure 3: File with 100% quality (to increase download performance, we published here only the 80% quality version).
Figure 3 shows the image with 100% JPEG quality and no blur, the filesize is 126,246 bytes. After blurring the
background with strength 8, the filesize is only 18,162 bytes; this image is shown in figure 4. It shows that the person
in the foreground is in a satisfying quality whereas the less important background is blurred. But still, the main image
information is conveyed.

Figure 4: File with 80% quality and blurred background.

Optimize Videos and Animations

Multimedia files like videos account for 98.6% of the transferred bytes in the Internet (King 2008, p. 159). Hence,
minimizing multimedia files can reduce traffic. Basic techniques are editing with special web settings, using special
codecs, reducing the frame rate and using professional equipment Other types of multimedia files are Flash
animations. These can also be reduced and optimized.
Here, non-optimized images and too many animation frames are the problems. The pictures should be optimized with
image processing programs before they are imported in Flash. Animations should have a reduced frame rate (King
2008, p. 170).

References

King, A., 2008. Website Optimization. 1st ed. Sebastopol: OReilly Media.

Nottingham, M., 2009. Caching Tutorial. [Online] Available at: http://www.mnot.net/cache_docs/ [Accessed
10 Oct. 2009].

Souders, S., 2007. High Performance Web Sites. Sebastopol: OReilly Media.

Acknowledgements
This text has been published by INSTICC Press:

Dick, Markus; Naumann, Stefan; Held, Alexandra: Green Web Engineering. A Set of Principles to Support
the Development and Operation of "Green" Websites and their Utilization during a Websites Life Cycle. Filipe,
Joaquim; Cordeiro, Jos (eds.): WEBIST 2010 : Proceedings of the 6th International Conference on Web Information
Systems and Technologies, April 7 - 10, 2010, Valencia, Spain, Volume 1. Setbal: INSTICC Press, 2010, pp. 48 - 55.

Recommendations for a Green Web for Users

Configure the Web Browser
The former sections focused on the web designers and administrators options to reduce network traffic and thus
power consumption. As was mentioned, administrators have no possibility to influence the browser configuration
directly, like e.g. forcing the browser to cache delivered content according to the corresponding HTTP response
header fields. Web users can also contribute a large part to the reduction of network traffic and power consumption
by configuring the caching capabilities of their web browsers in a way that far future expiry dates can take effect, or
by installing web browsers that are fully compatible with GZIP based HTTP compression. Furthermore, there is a lot
of advertisement on web pages today that causes additional, but avoidable network traffic.

Thus, we recommend that one should

configure large caches in Web browsers

not clear caches during browser shutdown

use browsers supporting GZIP compression

use advertisement blockers to block advertisement images and Flash

Visualize Green Power Status of a Website

In order to assess whether a website is hosted with renewable energies, tools like the "Power Indicator" (Naumann
2008b) can help users by visualizing the "green power state" of a website.

Apply "Green IT" on the Client Side

Of course, users of a website also have the possibility to obtain renewable energies within their companies or
households. It is also recommended to utilize the available energy management options of client computers.

References

Naumann, S., Gresk, S. & Schfer, K., 2008b. How Green is the Web? Visualizing the Power Quality of
Websites. In: Mller, A., Page, B. & Schreiber, M. eds., 2008. EnviroInfo 2008. Environmental Informatics and
Industrial Ecology, 22nd International Conference on Environmental Informatics. Aachen: Shaker Verlag, pp. 62-65.

Recommendations for a Green Web for

Administrators
Configure HTTPs Caching Support
Since the configuration of the users web browser cannot be affected by web designers or administrators, they have
to focus on the server-side configuration aspects of caching. Where approx. 80% of the web users have their
browsers configured for caching, however 20% always have an empty cache (Theurer 2007). The inclusion of
caching metadata by the web server will significantly decrease the amount of HTTP requests and HTTP responses.
Caching in HTTP/1.1 is designed to reduce

the need to send requests to servers ("expiration" mechanism) and

the need to send full responses back to the clients ("validation" mechanism).
The validation mechanism does not reduce the amount of HTTP-requests but it reduces the payload of the HTTP
responses that are sent back to the client and thus addresses network bandwidth reduction (Fielding et al. 1999, p.
74).
In order to facilitate the expiration mechanism of HTTP servers, administrators can specify an Expires or CacheControl header in their response. The Expires header as described with HTTP/1.0 (Berners- Lee 1996, p. 41) defines
the absolute date after which the response is expected to be stale. One minor problem with the Expires header is that
it uses explicit date and time strings and thus requires server and client clocks to be synchronized (Crocker 1982, p.
26; Souders 2007, p. 22). Beginning with HTTP/1.1 that limitation has been overcome with the Cache- Control
header. It uses the max-age directive to define the seconds, which the requested resource may remain in the cache.
To stay compatible with older HTTP clients that do not support the HTTP/1.1 protocol, one can define the Expires
header alongside with the Cache-Control header. In that case the Cache-Control header overrides the Expires
header.

The validation mechanism is utilized by HTTP clients that have a resource entry in their cache that has already
expired. In that case the client may send a conditional HTTP request to the server. This conditional HTTP request
looks exactly like a normal HTTP request but in addition it carries a so called "validator" that may be used by the
server to decide whether the resource requested by the client is still up to date or needs to be refreshed. In case that
it needs a refresh the new data is sent to the client, otherwise the server responds with the HTTP status code "304
Not modified". There are two validators that may be used: Last-Modified dates or Entity Tag cache validators. In case
of the Last-Modified date a cache entry is considered to be valid if the requested resource has not been modified
since the given Last- Modified date. An Entity Tag is a unique identifier for a specific version (entity) of a resource
(Fielding et al. 1999, p. 85). The calculation of the Entity Tags depends on the implementation of the web server. The
HTTP/1.1 specification states that servers should send both, Entity Tag and Last-Modified values in their responses.
HTTP/1.1 clients are forced by the specification to use Entity Tags in cache-conditional requests if provided by the
server. In addition clients should also apply a Last-Modified date if one was set (Fielding et al. 1999, p. 86).
In order to reduce the total amount of HTTP requests or HTTP payload sizes we suggest configuring the client cache
support properly. This means:
1.

setting far future expiration dates and cachecontrol headers for resources that infrequently change

2.

setting Last-Modified headers and Entity Tags for all resources that do not need recalculation on subsequent
requests (mainly static content)

A simple example configuration fragment for the popular Apache web server may look like this:
ExpiresActive On
<FilesMatch "\.(html|jpg|png|js|css)$">
ExpiresDefault "access plus 355 days"
FileETag MTime Size
</FilesMatch>
The Apache configuration directive ExpiresDefault handles both, the generation of an Expires header and the
generation of a Cache-Control header for the given resource types.

Use Compression
Today, many modern web browsers support some kind of compression. Compression reduces not only response size
and thus transfer time, but also power consumption as a result of the smaller size and shorter transfer times.
Web browsers usually support the GZIP compression format or DEFLATE. Both formats are especially named in the
HTTP/1.1 specification. The Accept-Encoding header is used by web browsers to indicate which content encodings
they support. A web server may compress the content using one of the compression methods listed by the browser
and must notify the browser within the Content- Encoding response header which compression method is used
(Fielding et al. 1999).
Compression is not as simple as it seems, because there are some older browser versions that claim that they
support compression but actually do not, because of incompatibilities or bugs. On the other hand more than 95%

(ADTECH, 2008) of all installed and used browsers in Europe are known to support GZIP compression. Therefore
regarding our goal of "Green Web Engineering" it is reasonable to enable compression on the server side.
However, not all content types are suitable for compression, e.g. compressed image file formats, compressed music
and video files or PDF documents. Compressing these file types is sometimes even counterproductive. Hence,
compression should be used for files that are well compressible like text based files. With a simple example website
that was compressed via GZIP compression with an Apache web server, we achieved traffic savings as shown in
table 1. The average saving for the whole example site is approx. 60% (assuming PNG-images are not compressed).
Table 1: Total vs. compressed filesize example.
Example content

Total size (KB)

Compressed size (KB)

Savings

index.html

5.45

2.44

55.3%

style.css

2.73

0.68

75.1%

prototype.js

126.00

29.51

76.6%

ida-logo.png

24.80

24.86

-0.2%

ucb-logo.png

9.27

9.28

-0.1%

Apply "Green IT" Concepts

So far, several web hosters exist that offer web hosting with renewable energy. Additionally, administrators can apply
the newest techniques regarding Green IT like virtualization strategies.

References

ADTECH, 2008. Survey Unveils Extent of Internet Explorer Domination Across the European Browser
Landscape. [Online] ADTECH: London. Available at: http://www.adtech.com/news/pr-08-07_en.htm [Accessed 10
Oct. 2009].

Berners-Lee, T., Fielding, R. & Frystyk, H., 1996. Hypertext Transfer Protocol -- HTTP/1.0. Request for
Comments 1945. [Online] Network Working Group. Available at: http://tools.ietf.org/html/rfc1945 [Accessed 10 Oct.
2009].

Crocker, David H., 1982. Standard for the Format of ARPA Internet Text Messages. Request for Comments
822. [Online] University of Delaware. Available at: http://tools.ietf.org/ html/rfc822 [Accessed 10 Oct. 2009].

Fielding, R.; Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. & Berners-Lee, T., 1999. Hypertext
Transfer Protocol -- HTTP/1.1. Request for Comments 2616. [Online] The Internet Society. Available at:
http://tools.ietf.org/html/ rfc2616 [Accessed 10 Oct. 2009].

Souders, S., 2007. High Performance Web Sites. Sebastopol: OReilly Media.

Theurer, T., 2007. Performance Research, Part 2: Browser Cache Usage - Exposed! [Online] Available at:
http://www.yuiblog.com/blog/2007/01/04/ performance-research-part-2/ [Accessed 10 Oct. 2009].

Green Web" Recommendations

For Developers [details]

Support caching on the server side

Minimize and optimize JavaScript

Minimize and optimize CSS

Optimize graphical design elements and logos

Optimize photographs

Optimize videos and animations

For Administrators [details]

Configure HTTPs caching support

Use HTTP compression

Apply "green IT" concepts

For Users [details]

Configure the web browser

Visualize green power status of a website (via e.g. Power Indicator)

Apply "green IT" on the client side

Common Quality Criteria and Metrics

Common Quality Criteria and Metrics relate to quality criteria and metrics well known from the standard quality
models for software e.g. ISO 25000 (SQuaRE). These are then interpret-ed on the background of their contribution to
sustainable development.
Reusability, which is the ability of software components to be reused in other software systems, reduces efforts to
develop other software systems and thus reduces environmental impacts of the development phase [1].
Modifiability, the ability to implement changes of software quickly, reduces environmental impacts that result from
developing and main-taining a software system [1].
Usability and Accessibility of software contrib-ute to social aspects, as they make software easier to learn, more
accessible to users with disabilities, or more accessible to people with-out access to computers with sufficient performance or screen sizes [1].
Predictability, which refers to the development process itself, is the ability of the developers to accurately estimate
person-days for required features. This contributes to social aspects, as it improves the developers conditions of
work by reducing the probability of overtime work [1].

The characteristics in the product quality model are intended to be used as a set
when specifying or evaluating software product quality. So, if we want to consider
sustainability as part of the quality model, it is necessary to define it together with
its subcharacteristics. For doing it, we must take into account that when a software
product is being developed, its sustainability can be considered from two points of
view. First we must ensure that the software product is energy-efficient when it
works, using the resources in the most appropriate manner. In Calero et al (2014)
the authors propose the following subcharacteristics for sustainability, which would
fit with this "short-term" point of view: Energy consumption. Degree to which the
amounts of energy used by a software product when performing its functions meet
requirements. Resource optimization. Degree to which the amounts and types of
resources used by a product when performing its functions meet sustainability
requirements. As in the standard, authors consider that resources can include: other
software products, the software and hardware configuration of the system, and
materials (e.g. print paper, storage media). On the other hand we must ensure that
the software product will endure over time, being only required its replacement if
adapting it to the new circumstances is very difficult to achieve. We refer to this as
Perdurability. The idea of making a software perdurable is to achieve a software
product lasting in time, that is modifiable, reusable, ie those aspects that make the
software developed lasts time and is able to adapt to change without losing its
functionality or other features related to its quality. In order to define perdurability
we need first to identify what it must consider and, for doing it, we are going to use
the standard (ISO:25010, 2010). In the standard, there are 3 characteristics that
could be related with what we are looking for: Reliability. Degree to which a system,
product or component performs specified functions under specified conditions for a
specified period of time Maturity. Degree to which a system meets needs for
reliability under normal operation Working towards Sustainable Software for
Science: Practice and Experiences (WSSSPE 2013) http://arxiv.org/abs/1309.1640

Availability. Degree to which a system, product or component is operational and

accessible when required for use Fault tolerance. Degree to which a system,
product or component operates as intended despite the presence of hardware or
software faults Recoverability. Degree to which, in the event of an interruption or a
failure, a product or system can recover the data directly affected and re-establish
the desired state of the system Maintainability. Degree of effectiveness and
efficiency with which a product or system can be modified by the intended
maintainers Modularity. Degree to which a system or computer program is
composed of discrete components such that a change to one component has
minimal impact on other components Reusability. Degree to which an asset can be
used in more than one system, or in building other assets Analysability. Degree of
effectiveness and efficiency with which it is possible to assess the impact on a
product or system of an intended change to one or more of its parts, or to diagnose
a product for deficiencies or causes of failures, or to identify parts to be modified
Modifiability. Degree to which a product or system can be effectively and efficiently
modified without introducing defects or degrading existing product quality.
Testability. Degree of effectiveness and efficiency with which test criteria can be
established for a system, product or component and tests can be performed to
determine whether those criteria have been met Portability. Degree of effectiveness
and efficiency with which a system, product or component can be transferred from
one hardware, software or other operational or usage environment to another
Adaptability. Degree to which a product or system can effectively and efficiently be
adapted for different or evolving hardware, software or other operational or usage
environments Installability. Degree of effectiveness and efficiency with which a
product or system can be successfully installed and/or uninstalled in a specified
environment Replaceability. Degree to which a product can be replaced by another
specified software product for the same purpose in the same environment However,
if we look in detail these sub-characteristics and their definitions, we can discard
many of them for not being related to long-term issues (the ones we are looking
for). As a result, we obtain a final set of characteristics that could be related to
perdurability. These characteristics must be taken into account when defining the
Perdurability characteristic: Reusability, Modifiability and Adaptability. These
characteristics will not be used exactly as they are defined for defining the
perdurability but they will be used as a basis for doing it and taking into account the
objective of the perdurability. Therefore, we can define the perdurability as the
degree to which a software product can be modified, adapted and reused in order to
perform specified functions under specified conditions for a long period of time.

Emulation (data-centric)
You want to keep your software, but youre worried that technical preservation might leave you
with no hardware or an expensive maintenance bill. The alternative may be emulation. An
emulator is a software package that mimics your old hardware (and, possibly, your operating
environment) so that it can be run on any computer.

Emulation gives you the flexibility to run your software on new hardware, which gives your
software a new lease of life. As always, there are drawbacks. You need to find an emulator. You
might be lucky and find one available under a free-to-use licence, or you might be able to buy
one. However, if your old hardware was rare, you may find that no emulator exists. In this case,
you either have to write an emulator yourself, which requires specialist skills and could be
expensive, or explore another of the sustainability approaches. It is difficult to write an emulator
that perfectly mimics the old hardware. This can lead to differences between the operation of the
old hardware and the new emulator, which could manifest themselves in annoying quirks or
more serious problems.
Emulation allows you to keep your old software, but requires the existence (or in-house
development) of a reliable emulator. It also adds a dependence on the emulation software,
which - like any other software - could itself become obsolete.

http://www.nextgenpms.com/p3.html