Skip to main content

About this book

This book focuses on the design, development, management, governance and application of evolving software processes that are aligned with changing business objectives, such as expansion to new domains or shifting to global production. In the context of an evolving business world, it examines the complete software process lifecycle, from the initial definition of a product to its systematic improvement. In doing so, it addresses difficult problems, such as how to implement processes in highly regulated domains or where to find a suitable notation system for documenting processes, and provides essential insights and tips to help readers manage process evolutions. And last but not least, it provides a wealth of examples and cases on how to deal with software evolution in practice.

Reflecting these topics, the book is divided into three parts. Part 1 focuses on software business transformation and addresses the questions of which process(es) to use and adapt, and how to organize process improvement programs. Subsequently, Part 2 mainly addresses process modeling. Lastly, Part 3 collects concrete approaches, experiences, and recommendations that can help to improve software processes, with a particular focus on specific lifecycle phases.

This book is aimed at anyone interested in understanding and optimizing software development tasks at their organization. While the experiences and ideas presented will be useful for both those readers who are unfamiliar with software process improvement and want to get an overview of the different aspects of the topic, and for those who are experts with many years of experience, it particularly targets the needs of researchers and Ph.D. students in the area of software and systems engineering or information systems who study advanced topics concerning the organization and management of (software development) projects and process improvements projects.

Table of Contents


Chapter 1. Low Ceremony Processes for Short Lifecycle Projects

Modern software applications, particularly those for mobile devices and web applications, are fundamentally different from traditional applications. Many of those applications are developed by startup businesses, which are under time and financial pressure to release their applications as quickly as possible. They have chosen to use agile methods for their development activities, largely because the administrative overhead for the process is low and the release cycle for the product is short. In this chapter, we contrast software processes based on the amount of management overhead (“ceremony”), describing the characteristics of startup businesses and their use of low-ceremony processes.
Anthony I. Wasserman

Chapter 2. The Right Degree of Agility in Rich Processes

Many companies that change their development process to agile later adapt these methods to their specific needs, take a step back to traditional processes, or do not continue their agile initiative. Particularly in light of the huge diversity of domains from information systems to embedded systems, it is necessary to find the right degree of agility for each context. Our goal is to describe how agility can be integrated into rich processes. Bringing the advantages of these two organizational worlds together should result in a useful, pragmatic, and feasible solution. This integration can be performed using two different approaches: revolutionary and evolutionary. In the revolutionary approach, an agile method is introduced to replace the current development process. In the evolutionary approach, the existing process is enhanced with appropriate and beneficial agile aspects. Both of these approaches have advantages for specific domains or contexts. After comparing the two approaches and related implementations of the revolutionary approach, this chapter focuses on the integration of agile practices, a specific evolutionary approach, due to the lack of existing research. With our comparison on the basis of the advantages and disadvantages of these two integration approaches, their detailed description, and some related implementations, we provide a foundation for further investigation in the field of combining agile and rich processes to find the right degree of agility.
Philipp Diebold, Thomas Zehler

Chapter 3. Assessing Product Development Agility

Agile software development grew out of a variety of alternative software development methods that shared a common set of values and principles. After two decades with these alternative methods, agile software development remains loosely defined, but has been widely accepted. This acceptance has gained the attention of other fields with discussions of applying agile to their work, for example agile systems engineering and agile program management. However, within the larger field of product development, agility was defined in terms of software development, both in practice and in principle. This chapter focuses on a set of general agile characteristics derived from the agile values and principles embraced by many software developers. This set of characteristics provides a basis for (a) assessing difficulties in software development projects employing agile practices, (b) applying concepts of agility to other disciplines beyond software development, and (c) measuring agility. In addition to deriving general agile characteristics, this chapter relates two stories of agile methods adoption that illustrate both the need for and the utility of general agile characteristics.
Daniel X. Houston, Stephen W. Rosemergy

Chapter 4. Value-Driven Process Management

To survive in a fast-changing environment, almost all companies strive for continuous efficiency improvement, reducing the cost of non-quality and optimizing product strategies. Simultaneously, it is thus crucial to improve product strategy and the product development processes. However, such improvement programs often fail due to lack of leadership and organizational misalignment. Operational constraints such as project pressure, client interaction, and strategic dependencies are often neglected, thus making a proposed change program a mere theoretic exercise—without much buy-in from the trenches. Despite access to a substantial body of knowledge of methods such as Capability Maturity Model Integration (CMMI) and Six Sigma, many organizations still struggle in practice. Most organizations fail to align necessary transformations with concrete business objectives. This chapter shows how to set up and drive a value-driven process environment based upon explicit business objectives and how to deliver sustainable value. It goes beyond theoretical method frameworks and emphasizes hands-on change management. Value-driven process evolution underlines the need continuously to manage the transformation based on business objectives and operational constraints. From these, a specific and tailored approach toward achieving engineering excellence is derived. A case study shows how value-driven process management was used over a period of several years. Improving productivity and efficiency is selected as a hands-on example how practically to implement value-driven process evolution.
Christof Ebert

Chapter 5. Are We Ready for Disruptive Improvement?

In the IT industry, the continuous improvement approach as an established way for process management is doomed to fail at critical points. In particular, we consider the aspect of dealing with disruptive business changes requiring a disruptive process improvement response. This chapter is based on the experience of a significant disruption in a large IT company. First, we consider how easy it is to continue on an improvement path that, in such a context, leads to failure. We then explore the alternative non-continuous responses required to avoid failure. We look at elements that can help an organization to be better prepared for disruptive improvements, including experiences with the introduction and impact of Design Thinking and Agile Development.
Andreas Rösel

Chapter 6. Trials and Tribulations of the Global Software Engineering Process: Evolving with Your Organisation

This chapter will provide the reader with a firsthand account of the trials and tribulations of working in and managing a Global Software Engineering (GSE) function. By describing the move from a distributed collection of self-sufficient manufacturing plants with locally managed software engineering resources, to a GSE function as a shared service, the focus will be on how the management of that group had to fundamentally change in order to satisfy the complex projects and customer base which resulted. In parallel it will discuss the effect of regulation on the software engineering management process. Tracing the introduction of financial systems regulations, it will discuss the issues this brought to the GSE process and how they were successfully overcomed. These topics will be augmented by research that the author has carried out into regulated software development.
Oisín Cawley

Chapter 7. The Route to Software Process Improvement in Small- and Medium-Sized Enterprises

The software development industry is dominated by a myriad of small- and medium-sized enterprises (SMEs). The main goal of this chapter is to provide a characterization of SMEs based on previous studies. It also includes an overview of a number of software process models and software process improvement (SPI) models, which are aimed at assisting SMEs in improving the way they develop software. Furthermore, this chapter discusses the extent of SPI approaches published in the literature as a way to understand the particular context and some of the major challenges faced. From there, we propose an approach to integrate software process practices. This proposal is based on the results of our study on this topic carried out in small software companies. It is focused on what small organizations could actually do, more than on what they are currently practicing.
Mary-Luz Sánchez-Gordón, Ricardo Colomo-Palacios, Antonio de Amescua Seco, Rory V. O’Connor

Chapter 8. Managing Software Process Evolution for Spacecraft from a Customer’s Perspective

The Space Administration of the German Aerospace Center designs and implements the German space program. While project management rests with the agency, suppliers are contracted for building devices and their software. As opposed to many other domains, a spacecraft is a unique device with uncommon and custom-built peripherals. Its software is specifically developed for a single mission only and often controls critical functionality. A small coding error can mean the loss of the spacecraft and mission failure. For this reason, customer and supplier closely collaborate on the field of software quality. We report from a customer’s perspective on how we manage software quality and ensure that suppliers evolve their processes: We contribute to standards, tailor quality, and process requirements to establish them in projects, and engage in cross-company product quality collaboration.
Christian R. Prause, Markus Bibus, Carsten Dietrich, Wolfgang Jobi

Chapter 9. Modeling Software Processes Using BPMN: When and When Not?

Software process models capture structural and behavioral properties of software development activities, supporting the elicitation, analysis, simulation, and improvement of software development processes. Various approaches for the modeling and model-driven analysis of software development processes have been proposed but little progress has been made regarding standardization. With increasing demands regarding flexibility and adaptability of development processes, the constant evolution of development methods and tools, and the trend toward continuous product deployment, better support for process engineers in terms of universally applicable modeling notations as well as simulation and enactment mechanisms has become more desirable than ever. In contrast to software process modeling, the discipline of business process modeling has attained a greater level of consensus and standardization, leading most notably to the Business Process Model and Notation (BPMN). The success of BPMN as a standard business process modeling notation has made scholars ponder whether BPMN could also be used for modeling software development processes. This chapter analyzes this question by eliciting fundamental assumptions made in BPMN about the nature of business process models, which ultimately determine which aspects of the process are included in the model and which aspects are either left out or treated as ancillary.
Marlon Dumas, Dietmar Pfahl

Chapter 10. Software Processes Management by Method Engineering with MESP

Software process management (SPM) is seen as a key factor for the resulting quality of software. Based on our experience in industrial process improvement projects, we see two major challenges to apply SPM effectively. Thereby, in our work, we focus on the method aspect of software development processes. First, methods have to be tailored consistently to projects by composing agile as well as plan-driven method building blocks. Second, methods have to be enactable to ensure that they are put into practice as intended. In this chapter, we present our assembly-based method engineering approach called Method Engineering with Method Services and Method Patterns (MESP) and explain how it tackles common SPM challenges. MESP follows the service-oriented paradigm to create formally defined composition-based methods. The methods are created specifically for individual projects based on their characteristics. They are composed based on an extensible repository of formally defined method building blocks extracted from agile and plan-driven methods. With our novel notion of method patterns, we allow to restrict the solution space of method compositions to the desired ones. In addition, we provide tooling to define building blocks and to compose them to methods consistently and we support the correct enactment of methods with a workflow engine.
Masud Fazal-Baqaie, Gregor Engels

Chapter 11. Adapting Case Management Techniques to Achieve Software Process Flexibility

Software processes have to be flexible in order to handle a wide range of software project types and complexities. Large companies that depend on custom-built software may therefore define different software processes in order to adapt to different recurring project contexts (e.g., hot-fix versus migration projects). However, the stakeholders do not always follow the intended “happy path”—not the least because any software project typically has to deal with a considerable amount of uncertainty. Following an agile process may not be possible due to a company’s culture or policy restrictions (e.g., in the healthcare or financial domain) though. In this chapter, we present an approach to introduce more flexibility into software process models by adapting case management techniques to the domain of flexible software process management, in order to cope with key issues that come with software process evolution. Key functionalities of the approach have been implemented in a prototype and showcased to developers and architects via a live experiment. The feedback is promising as it shows that the approach helps to quickly identify context-specific actions and artifacts. This in turn reduces effort in structuring the daily work of software process stakeholders in an environment of evolving process elements specific to different kinds of projects, roles, and technologies.
Marian Benner-Wickner, Matthias Book, Volker Gruhn

Chapter 12. A Researcher’s Experiences in Supporting Industrial Software Process Improvement

Industry–academia collaboration in software engineering is essential for the relevance of research, as research may make important contributions to the improvement of software engineering. Thus, software engineering researchers are an asset in software process improvement. In this chapter, I present different experiences of being an embedded researcher in industry contributing to software process improvement. The process improvement works were focused on helping organizations to move from plan-driven processes to agile and lean processes. We will elaborate on the challenges, essential practices, and related benefits that were observed when working closely with industry in the role of embedded researchers. Supporting examples from different published cases form the basis for this experience report.
Kai Petersen

Chapter 13. Lessons Learned from Co-Evolution of Software Process and Model-Driven Engineering

Software companies need to cope with permanent changes in market. To stay competitive it is often inevitable to improve processes and adopt to new technologies. Indeed, it is well known that software processes and model-driven engineering (MDE) are subject to evolution. Simultaneously, it is known that MDE can affect process tailoring, which makes it possible that evolution in MDE triggers process evolution and vice versa. This can lead to undesired process changes and additional cost, when process adaptations constitute a need for further investments in MDE tooling. However, there is little knowledge so far whether this co-evolution exists and how it looks like. In this chapter, we present two industrial case studies on co-evolution of MDE and software process. Based on these case studies, we present an initial list of co-evolution drivers and observations made on co-evolution of software processes and MDE. Furthermore, we compile our lessons learned to directly help process managers dealing with co-evolution.
Regina Hebig, Andreas I. Schmied, Ingo Weisemöller

Chapter 14. Monitoring and Controlling Release Readiness by Learning Across Projects

Releasing software on time, with desired quality while staying within budget is crucial for success. Therefore, product managers should proactively know which release readiness attributes are not performing sufficiently well (i.e., bottleneck factors) throughout the development cycle and consequently may limit readiness of the software release. We present the Cross-project Analysis for Selection of Release Readiness attributes (CASRR) method to help project managers in (i) systematically studying and analyzing release readiness attributes across multiple projects, (ii) selection of release readiness attributes for monitoring which have previously been shown to become bottlenecks in similar projects in the past, and (iii) learning how bottleneck occurrences are influenced by project characteristics. We applied CASRR to two Open Source Software projects, and analyzed six release readiness attributes in 34 similar projects over a period of two years. Continuous integration rate, feature completion rate, and bug fixing rate are observed as the most frequent bottleneck factors. Bottleneck occurrences of the monitored release readiness attributes are significantly influenced by the maturity of a release. Furthermore, the continuous integration rate is found to be significantly influenced by the team size.
S. M. Didar Al Alam, Dietmar Pfahl, Günther Ruhe

Chapter 15. The Effects of Software Process Evolution to Technical Debt—Perceptions from Three Large Software Projects

This chapter describes a qualitative study with the goal to explore and understand how software process evolution affects technical debt. We investigated three large software development projects with a long development history with the aim to understand how software processes had evolved during the life cycle and how this evolution affected technical debt. We observed how companies had changed their software processes as well as the reasons, benefits, and consequences of these changes on technical debt. The main driving force for the software process evolution was business pressure from management to increase productivity and become cost-efficient. However, these changes were also the source of technical debt. The results show that software process evolution has a clear effect to technical debt. Software process evolution can be used to decrease technical debt by adopting new methods, tools, and techniques. However, software process evolution includes several challenges. These challenges have a possibility to decrease the productivity and quality of new software processes and technical debt might increase.
Jesse Yli-Huumo, Andrey Maglyas, Kari Smolander


Additional information

Premium Partner

    Image Credits