Showing posts with label Ecoliability. Show all posts
Showing posts with label Ecoliability. Show all posts

Sunday, March 15, 2009

Pretending to be green and not explicitly measuring it

Last year I already introduced on my blog "Ecoliability" as a potential new quality attribute. I still believe this quality attribute can be of use to explicitly measure how "Green" a company or software is.

On CeBIT green IT a entire hall was dedicated to innovations related to energy saving solutions in the IT-world. Looking at this site it seems those solutions are for a wide scale of potions, from efficient usage of processor time through cloud-computing or SaaS till hard ware solutions to save energy.

If organizations pretending or intending to be green; why not explicitly measure this? Most of the software testers like to talk about quality attributes when they need to test something. It is common knowledge that if certain quality attributes getting more attention in projects it have a positive influence on some attributes and a negative influence on others. For example increasing functionality could have positive effects on usability and efficiency only the sustainability and portability might be lesser.

Management make decisions on those effects. If this is so important for management to decide what to choose based on the impact on certain quality attributes this new quality attribute "Ecoliability" can also be of use and must be introduced.

If we start using this quality attribute it can help management to decide if they accept the costs on other attributes for being "Green" or forcing projects to look for other solutions. If being "Green" is a management decision based on a company’s vision we should help them making it measurable and therefore visible.

If you are "Green" you might think about this and start discussions about this new attribute.

Monday, November 3, 2008

How to deal with "Ecoliability"

Do you like the idea?
I recently started to write about "Ecoliability" as a new quality attribute. Although I'm certainly not the person who is able to dictate what is right or what is wrong; at least I can use my weblog to share my thoughts. Perhaps there are others around the world who also likes the idea of this new quality attribute.

Why the need for this attribute?
As in previous posting I already referred to the trend to focus on data storages to save energy and special forums to explain the benefits of virtual machines. See:
04--7-2008: The green part of development and software testing: "Ecologiability"
11-02-2008: Introduction of the quality attribute: "Ecoliability"

Currently environmental awareness is getting already much attention. Discussions are held how to store data or how to use machines efficiently. Why not make it also important and explicitly measure the outcome of it by assigning those figures to an individual attribute?

Why not using an existing Quality Attribute?
In my opinion you could capture the urge for this green part under several other attributes like:
Efficiency: Time behavior and Resource Utilization: e.g. how much CPU do you need?
Portability: Replacebility: e.g. how easy can an old machine be replaced?

Only is this enough? If we capture the sense of ECO under those attributes, they will just become a part of the whole picture. If we make a single attribute for it: we can measure it as part of the requirements. It might help making decisions and also make it visible that an organization cares. As an example an organization can demand that the new application should reduce the data storage by 10%.

What to measure?
I think there are enough objects we can measure. Only we have to measure with sense . And as technology is evolving all the time and Ecological common sense also I suggest making this attribute the first dynamic Quality Attribute. Only it should be dynamic within borders. Otherwise we get a situation as we have now with the name Agile development. As long as it fits in our picture we call it Agile.
As said before objects to measure can be:
- batch jobs are scheduled on a need for information basis, not only because we just like them to run
- data is stored because we need that data now and not possible in a unknown future
- database tables are defined based on need not on easy of usages or as a workaround
- environments can be mirrored in an virtual environment

I can imagine after making this explicitly mentioned in requirements they would look like:
- Data storage is minimized by 10%
- CPU usage is reduced by 15% of machine "XYZ"
- The environment should exist out of maximum of x-machines
- Backups are created based on business critical data only

Which Possible Dynamic Borders?
Perhaps the borders can be related to:
- Infrastructure: e.g. which machine are we using and how are the connections defined?
- Datastorage: e.g. what is the lifecycle of data? What is the level of redundancy?
- Functionality: e.g. how does the functionality support the infrastructure and data storage borders?

When to measure?
I think it can be measured in all stages from Unit test towards user acceptance testing.
The question is: when do we start measuring?
I dare you reader to think with me how this could work.

Sunday, November 2, 2008

Introduction of the quality attribute: Ecoliability

In a previous post 7 April 2008 The green part of development and software testing: "Ecologiability" I already spoke about introducing a new quality attribute called: "Ecologiability"
In this post I want to change the term as non-native-English-speaker I have difficulties to pronounce this word. I would introduce "Ecoliability"

I still believe that in software testing we should consider this also as a area to focus on as recently more articles are written about green computing. Servers which are using lesser energy. Choices to use virtual environments etc.
http://www.greenercomputing.com/current

There are even discussions about introducing a badge for power efficient servers.
Energy Star for green servers to come this year

If there is discussion about the green part of applications, then it should also be measured. If it can be measured and it is, why not make a quality attribute for it.
You can use this attribute for testing infrastructure and perhaps in the nearby future also applications are designed to use lesser resources of those applications.

Therefore I suggest the idea: If we want to be greener, name it and make it measurable. An approach for this is defining this quality attribute: "Ecoliability"

I can imagine that there are arguments to measure this in other quality attributes like: Efficiency. To measure it in this attribute it just becomes a part of an attribute. I think our environment is more important to be just a part of something. Let us make it explicitly!

Monday, April 7, 2008

The green part of development and software testing: "Ecologiability"

Over the last few months in several resources are paying attention to the ECO effect of our systems. They already started defining infrastructure in such a way that our environment is somehow lesser charged.

Like:
IBM cools data centre with swimming pool
Sun to set up datacentre in coal mine

Another trend to reduce hardware by using virtual development and test environments.

If this trend is continuing, is the quality attribute we know now as efficiency enough to measure the benefits of lesser data storages or virtual environments? Perhaps we need a new one: Perhaps: Ecologiability?

Currently we see functional testing and infrastructure testing as two different specialists areas. I can imagine that this new quality attribute is combining both of those good worlds.

Combining both worlds take more then just another location of data storage. It can go further then that.

Won't it also be good to make this work over the business requirements? Let the business think during defining requirements if all data should be stored and also if old data should be kept.

Let the architects think about an optimal design of databases and infrastructure.

Let the developers search for solutions in function usage that prevents creation of redundant or too much information.

Let organizations think what information they actual need at this moment and leave thoughts like: "In the future we might eventually need this kind of information."

If we use this quality attribute we can define goals for reducing CO2 reduction in terms like: Our infrastructure should create a maximum of xxxxx CO2. The next release should reduce the CO2 creation by 5% per year.

Using terms like this will have impact on the architecture, environments, data usage and also the functions that are initially creating those data. Therefore it will impact development and testing.

To act on frequent basis in development, we should be dynamic in our development. Perhaps this leaves us more towards development methods like: Extreme Programming, Agile Development and SCRUM. As this requirement can change or introduced in every iteration.

As tester we should be able to measure it. We should have knowledge of both worlds: functional and infrastructure testing. We should also be able to adapt ourselves towards those development methods, including their tools.

I ask you, reader, do we need such a new quality attribute? How can we deal with it?