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:-

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 ENVIRONMENTALDevelopment Usage Maintenance Developmen

tUsage

Maintenance Development

Usage

Maintenance

Portability Usability Governance Reusability of code

Testability Energy Efficient Code

Supportability Community Analysability Energy Efficient Code

Changeability Legality

Reliability Accessibility Evolvability Identity Adaptability Procurment testing

Application Types

Desktop based Application

Commercial Application Scientific Application Educative Application

Distributed Application

Web based Application

Commercial Application

Scientific Application

Educative Application

Social Networking Application

Cloud Application

Commercial Application

Scientific Application

Educative Application

Security One click Report generation ability

Interoperabity Copyright

Performance Fault Tolerance Test

Licensing Modularity

Robustness Failure Testing

Understandability

Scalability

Process Methodology

Power Management Testing

Test for emulator

PredictabilityFunctional SuitabilityAgile 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 ECONOMIC ENVIRONMENTALDevelopment

Usage Maintenance Development Usage Maintenance Development Usage Maintenance

Sustainability Indicators for Desktop based Educative Applications

SOCIAL ECONOMIC ENVIRONMENTALDevelopment

Usage Maintenance Development Usage Maintenance Development

Usage Maintenance

Sustainability Indicators for Distributed Web based Commercial Applications

SOCIAL ECONOMIC ENVIRONMENTALDevelopment Usage Maintenance Developmen

tUsage Maintenance Developmen

tUsage Maintenance

Sustainability Indicators for Distributed Web based Scientific Applications

SOCIAL ECONOMIC ENVIRONMENTALDevelopment Usage Maintenance Development Usage Maintenance Development Usage Maintenance

Sustainability Indicators for Distributed Web based Educative Applications

SOCIAL ECONOMIC ENVIRONMENTALDevelopment Usage Maintenance Development Usage Maintenance Development Usage Maintenance

Sustainability Indicators for Distributed Cloud based Commercial Applications

Social Economic EnvironmentalDevelopment

Usage Maintenance Development Usage Maintenance Development Usage Maintenance

Sustainability Indicators for Distributed Cloud based Scientific Applications

Social Economic Environmental

Development

Usage Maintenance Development

Usage Maintenance Development

Usage Maintenance

Sustainability Indicators for Distributed Cloud based Educative Applications

Social Economic EnvironmentalDevelopment

Usage Maintenance

Development Usage Maintenance Development Usage Maintenance

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:-

Characteristics Subcharacteristics Definitions

SuitabilityThis is the essential Functionality characteristic and refers to the appropriateness (to specification) of the functions of the software.

AccuratenessThis refers to the correctness of the functions, an ATM may provide a cash dispensing function but is the amount correct?

Functionality Interoperability

A given software component or system does not typically function in isolation. This subcharacteristic concerns the ability of a software component to interact with other components or systems.

ComplianceWhere appropriate certain industry (or government) laws and guidelines need to be complied with, i.e. SOX. This subcharacteristic addresses the compliant capability of software.

SecurityThis subcharacteristic relates to unauthorized access to the software functions.

MaturityThis subcharacteristic concerns frequency of failure of the software.

Reliability Fault tolerance The ability of software to withstand (and recover) from

component, or environmental, failure.

RecoverabilityAbility to bring back a failed system to full operation, including data and network connections.

UnderstandabilityDetermines the ease of which the systems functions can be understood, relates to user mental models in Human Computer Interaction methods.

UsabilityLearnability Learning effort for different users, i.e. novice, expert, casual etc.

OperabilityAbility of the software to be easily operated by a given user in a given environment.

EfficiencyTime 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.

AnalyzabilityCharacterizes the ability to identify the root cause of a failure within the software.

Maintainability Changeability Characterizes the amount of effort to change a system.

StabilityCharacterizes 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.

AdaptabilityCharacterizes the ability of the system to change to new specifications or operating environments.

Portability Installability Characterizes the effort required to install the software.

ConformanceSimilar to compliance for functionality, but this characteristic relates to portability. One example would be Open SQL conformance which relates to portability of database used.

ReplaceabilityCharacterizes 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 Project’s 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, Project’s Footprint

Following, I give a brief description of Albertao’s interpretation of the property Portabilityand his newly introduced property Project’s 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 systems2:372.

The property Project’s Footprint is measured by four metrics:

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

the Meetings Rate is the number of total meetings per number of total project weeks1: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 travel2: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. TheWork-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 (long-haul trips by coach or car are not explicitly mentioned).

Round-Up

Albertao’s 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, Project’s 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 process3,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 company’s 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, list-style 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 PlatformUmwelt-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: O’Reilly 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: O’Reilly 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 Website’s 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. Setúbal: 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. & Schäfer, K., 2008b. How Green is the Web? Visualizing the Power Quality of Websites. In:

Möller, 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 user’s 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 Cache-

Control 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: O’Reilly 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 per-

formance 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 you’re 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