Sustainable Software Processes, Final Episode: Discussion and Conclusion

The preceding posts in this series on sustainable software processes summarized the essentials of three software processes described in scientific publications so far. In this final post of the series, we will, as was promised in the first post, examine how and to which extent these processes implement a set of reference processes for sustainable software engineering introduced by Lami et al.1 that complement the international standards ISO/IEC 122071 and ISO/IEC 15504-42.

A short summary of the set of reference processes is given in the following two posts:
Short summaries of the three software processes are given in these posts:

Sustainability Management Process

The Sustainability Management Process enables products, services, and life cycle processes to meet sustainability objectives1:102.

The reference process requires the definition of sustainability principles and criteria. Where Dick et al.’s process gives some exemplary criteria in their LCA-like life cycle for software, Albertao and Mahmoud & Ahmad define a set of fixed metrics, which can be interpreted as manifestations of sustainability criteria. However, there is no explicit task or activity that has a set of sustainability criteria and principles as its outcome.

On the other hand, for all three processes, it is necessary to plan the activities and to allocate the resources, even if this is not explicitly represented in any of the processes. If any activity has to be carried out according to the process description, e.g. the “Reflection Phase” in Albertao2:4, the “Sustainability Reviews and Previews” in Dick et al.5:81, or the “Green Analysis Phase” in Mahmoud & Ahmad6:65, it is certainly necessary to do some kind of planning and resource allocation. So we may certify that all of the three processes plan and implement their sustainability related activities as required by the reference process.

Contrary to this, the reference process requires that the performance of the sustainability activities is monitored for its conformity with the planning. Such an explicit monitoring activity as well as an explicit monitoring if supplied external products and services meet sustainability requirements are missing in all three processes. Furthermore, none of the processes undeniably establishes a sustainability policy that defines those requirements for suppliers. Only Mahmoud & Ahmad’s process description gives a short hint that environmentally approved products should be used throughout the process, which possibly includes also supplied third-party products and services6:63.

Sustainability Engineering Process

The Sustainability Engineering Process guarantees that sustainability objectives are addressed through the whole of the engineering process1:103.

The reference process requires the identification of factors that affect sustainability. As was mentioned above, all processes describe some kind of criteria or metrics as a manifestation of those. However, where Albertao’s and Mahmoud & Ahmad’s processes give a more or less extensive set of metrics, Dick et al.’s process names only a few factors, i.e. energy consumption/efficiency (of the resulting software product)5:83 and greenhouse gas emissions (Product Carbon Footprint or even a Life Cycle Assessment of the whole software life cycle including manufacturing, maintenance, and operation/usage5:81). However, none of the three processes claims to present the ultimate set of metrics or factors and thus remains extensible for future insights.

As demanded by the reference process, all three processes perform a sustainability analysis in order to determine the impact of factors affecting sustainability. Albertao calls it  “Assessment Phase”, Dick et al. call it “Sustainability Review and Preview” and “Process Assessment”, and Mahmoud & Ahmad call it “Green Analysis Phase”.

The reference process requires the definition of sustainability objectives. Each of the three processes defines sustainability objectives as an outcome of their sustainability analysis, if any sustainability problems had been discovered. These sustainability objectives target at a further improvement of the software.

To meet the sustainability objectives, green principles and techniques should be identified and applied during development. Where Albertao does not mention any principles or techniques beyond the given metrics, Dick et al. mention guidelines, hints, or software tools that support architects and developers in improving the architecture or coding so that sustainability objectives are met4:711, 5:81. Mahmoud & Ahmad added a whole bunch of software tools as well as a few simple principles to their process model that should support people in producing green software6:63–8.

Finally, the reference process requires that change requests are analysed regarding their impact on sustainability. Albertao and Dick et al. define a lightweight continuous improvement processes, that can be integrated into any concrete software development process. Hence, it should be expected that, although not explicitly mentioned, change requests are analyzed for their impacts on sustainability in the same fashion as usual requirements are analyzed. Only Mahmoud & Ahmad’s process description gives some explicit hints and guidelines on how to deal with change requests in the maintenance stage6:66.

Sustainability Qualification Process

The Sustainability Qualification Process guarantees that external resources comply with sustainability objectives1:104.
However, the aspects of the Sustainability Qualification Process are not implemented by any of the three software processes.


After this analysis, I was astounded to see how many aspects of Lami et al.’s reference processes are covered by the three processes.

However, regarding the publication dates and citations, it must be acknowledged that Lami et al. based their work on findings of the research group around Naumann et al.7, which is essentially identical to Dick et al.4:711, 5. Mahmoud & Ahmad refer in their publication also to Naumann et al. but additionally, they cite the reference process of Lami et al. Furthermore, Naumann et al., Dick et al., and Mahmoud & Ahmad refer to Albertao2 or Albertao et al.3
Now, with the knowledge of some common roots, the similarities are explicable.

The Sustainability Management Process is partially implemented by the three processes. Where we can assume that the sustainability activities are planned somehow, although not explicitly described in any of the three processes, a monitoring if the sustainability activities are carried out as planned as well as a monitoring if supplied products meet the sustainability requirements/objectives are missing in all three processes.

The Sustainability Engineering Process can be assumed to be completely covered by all three processes, even if some aspects, as the green principles or change requests, are not handled in each process explicitly.

The Sustainability Qualification Process, which deals mainly with the sustainability performance of third-party products and services, is not covered by any of the three processes. Nevertheless, the sustainability performance of third-party products and services should be of high importance, because real-life software projects make usually heavy use of third-party components, beginning with office suits, to integrated development environments, and runtime libraries that are an essential integral part of the software product.

In conclusion, none of the three processes implement the outcomes of the reference processes completely. Naturally, this is excusable for Albertao’s and Dick et al.’s process, because these two processes were designed without Lami et al.’s publication in mind, but Mahmoud & Ahmad’s process was. So it is a little bit surprising that Mahmoud & Ahmad did not implement any aspect of the Sustainability Qualification Process.

However, it should be easy to add the missing aspects of the Sustainability Qualification Process to each of the three processes making them more complete.

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

  1. 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
  2. Albertao, F.: Sustainable Software Engineering. http://www.scribd.com/doc/5507536/Sustainable-Software-Engineering#about, 2014-10-24
  3. Albertao, F., Xiao, J., Tian, C., Lu, Y., Zhang, K.Q., Liu, C.: Measuring the Sustainability Performance of Software Projects. In: IEEE Computer Society (ed.): 2010 IEEE 7th International Conference on e-Business Engineering (ICEBE 2010), Shanghai, China, pp. 369–373 (2010). doi:10.1109/ICEBE.2010.26
  4. Dick, M., Naumann, S.: Enhancing Software Engineering Processes towards Sustainable Software Product Design. In: Greve, K., Cremers, A.B. (eds.): EnviroInfo 2010: Integration of Environmental Information in Europe. Proceedings of the 24th International Conference on Informatics for Environmental Protection, October 6 - 8, 2010, Cologne/Bonn, Germany, pp. 706–715. Shaker, Aachen (2010). http://enviroinfo.eu/sites/default/files/pdfs/vol6516/0706.pdf
  5. Dick, M., Drangmeister, J., Kern, E., Naumann, S.: Green Software Engineering with Agile Methods. In:: Workshop GREENS 2013 – Proceedings. 2nd International Workshop on Green and Sustainable Software (GREENS), May 20, 2013, San Francisco, CA, USA, pp. 78–85. IEEE (2013). doi:10.1109/GREENS.2013.6606425
  6. 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
  7. Naumann, S., Dick, M., Kern, E., Johann, T.: The GREENSOFT Model: A Reference Model for Green and Sustainable Software and its Engineering. SUSCOM, volume 1, issue 4, pp. 294–304 (2011). doi:10.1016/j.suscom.2011.06.004