Sustainable Software Processes, Episode 3: A Green Model for Sustainable Software Engineering

In their paper “A Green Model for Sustainable Software Engineering”, Mahmoud and Ahmad (2013)1 present a green software engineering process and a collection of software tools that promote green computing. They claim that their process takes the best of sequential, iterative, and agile software processes, and combines them in a new process. The process comprises nine phases, which are similar to the usual phases of traditional software development processes: Requirements, Design, Unit Testing, Implementation, System Testing, Green Analysis, Usage, Maintenance, and Disposal. An increment milestone can be placed  between Implementation and System Testing. Between Green Analysis and Usage a system release milestone can be placed.

The Requirements phase is described as the most important and critical phase to obtain green software. Therefore, it comes with a general requirements test activity and with a risk assessment activity that takes energy efficiency into account. If any problems are discovered, it is explicitly possible to step back to the beginning.

The Design and the Implementation phases come with some guidelines for architects and developers regarding efficient data structures, efficient algorithms, frameworks, layering, reusing existing components.

The Unit Testing phase is outlined to come just before the Implementation phase, because a test-first approach will reduce energy consumption if the software artifacts are found to be non-conforming to the requirements and hence you step back to the Requirements phase (we will discuss that later on).

A difference to typical processes is the Green Analysis phase. Its purpose is to determine the “greenness” of each product increment. To measure the “greenness”, the metrics of the EU funded GAMES Project2 were designated as appropriate. Especially the resource usage metrics, e.g. CPU usage, or quality metrics, e.g. performance, should be used to check if energy efficiency requirements have been met. If any issues are discovered, the process may step back to the Requirements phase. Simple changes can be directly implemented in the Green Analysis phase, without stepping back, which is described to save energy and resources.

The Usage phase comes with a few simple guidelines that show which requirements should be set to enable users to behave in a more sustainable way.

The Maintenance phase comes also with some guidelines, which are intended to make maintenance more energy conserving, because it is assumed that maintenance is the most energy consuming phase. The reason given by the authors for this assumption is that there is the possibility that basic parts of the software system must be revised to implement updates or new versions.

The Disposal phase comes, like the two preceding phases, with a few guidelines, but even without any process descriptions. The guidelines consider the hardware necessary to execute the software as well as the software itself and range from recycling disposed hardware to reuse of software components to save natural resources and software development efforts.

In addition to the process description, the model comes with a whole bunch of various software tools that can play a major role in promoting green computing. The tools are classified in five categories: operating system frameworks, performance monitoring counters and metrics, codes written for energy allocation purposes, and virtualization.

Figure 1 Schema of the Green Software Engineering Process (own drawing)1:62

Round Up

The Green Model for Sustainable Software Engineering comprises nine phases of which only six come with dedicated process descriptions. The others come with general guidelines regarding the software under development, user behaviour, as well as the development process.

In general, the given measures and guidelines mainly focus on energy consumption and do not consider any further sustainability relevant issues beyond that, e.g. social aspects or environmental aspects with effects on higher levels, like usage or systemic effects (see post Effects of Information and Communication Technology on Sustainable Development).

Regarding the sequence of the phases, there are two issues, which a practitioner immediately figures out: Unit Testing is modeled to come before Implementation, and Usage comes before Maintenance.

The point of Unit Testing in the sequence flow is substantiated by the authors with a test-first or test driven development (abbr. TDD) approach (although not explicitly named as those). This is obviously a misinterpretation of the TDD methodology, because TDD means starting with an initial test code and then developing the functionality in-step with the further development of the test code. Thus, unit testing with TDD should be either outlined as an integrated part of implementation or as executed in parallel with implementation, but never before implementation. Moreover, it will not be possible to step back to Requirements in Unit Testing, because without any implementation, you will not find any issues. Thus, even if we strictly assume a test-first approach, where all unit tests are completely developed before any implementation, the earliest possible point when we will find any issues that urge us to step back to Requirements will be during Implementation.

The same applies for Usage and Maintenance. These phases cannot be sequential, because this would mean that the product is first used and then right after usage it is maintained. In fact, regarding a real product’s life, usage and maintenance occur at the same time. Thus, these phases should be modeled to be executed in parallel and not sequential.

Besides these structural flaws, it is, from my point of view, questionable, which company will drop their well understood and well mastered software processes in favour of a completely new process that only comes with very limited documentation.

However, despite all these concerns, two aspects are important and valuable:

Firstly, Requirements is the most important phase regarding any sustainability issues, because without dedicated requirements no one will be able to check whether a software meets its sustainability objectives or not.

Secondly, the Green Analysis phase is more or less independent from the process itself. Hence, it should be possible to integrate such a testing phase for sustainability objectives in any software process to establish a continuous improvement cycle.

The basic principles are established: guidelines for requirements are given, metrics to measure the extent to which sustainability objectives are met are available, and a specialized testing activity is outlined that checks the software for sustainability objectives and solves any recognized issues.

The next post in this series on Sustainable Software Processes will be the final episode (expected publication date 4/11/2015 8:00 PM UTC+2). In it we will examine how and to which extent the presented processes implement the set of reference processes for sustainable software engineering that were introduced by Lami et al.3 These reference processes add sustainability aspects to the international standards ISO/IEC 122071 and ISO/IEC 15504-42.

Are you interested in reading the previous posts of this series on Sustainable Software Processes?

  1. Mahmoud, S.S., Ahmad, I.: A Green Model for Sustainable Software Engineering. IJSEIA, volume 7, issue 4, pp. 55–74 (2013). http://www.sersc.org/journals/IJSEIA/vol7_no4_2013/5.pdf
  2. Jiang, T., Kipp, A., Cappiello, C., Fugini, M., Gangadharan, G., Ferreira, A.M., Pernici, B., Plebani, P., Salomie, I. and Cioara, T., et al.: Layered Green Performance Indicators Definition. GAMES - Green Active Management of Energy in IT Service centres, Project ICT-248514, Deliverable D2.1 WP2. http://www.green-datacenters.eu/index.php?mact=Uploads,cntnt01,default,0&cntnt01category=PublicDeliverables&cntnt01mode=single&cntnt01sortorder=name_asc&cntnt01upload_id=132&cntnt01returnid=95, 2014-12-26
  3. Lami, G., Fabbrini, F., Fusani, M.: Software Sustainability from a Process-Centric Perspective. Systems, Software and Services Process Improvement. In: Winkler, D., O’Connor, R.V., Messnarz, R. (eds.): Systems, Software and Services Process Improvement. 19th European Conference, EuroSPI 2012, Vienna, Austria, June 25-27, 2012. Proceedings. Communications in Computer and Information Science, volume 301, pp. 97–108. Springer, Berlin, Heidelberg (2012). doi:10.1007/978-3-642-31199-4_9