Agile development methods allow rapid adaptations of requirements to fast changing needs in businesses and society. Their combination with Continuous Requirements Engineering seems to be very effective. However, agile methods are applied to the development process only. Maintenance is often not organized in the same way. Continuous Delivers might be a solution for that. Additionally, the focus on users is important. Currently, often customers are mentioned only. The paper discusses aspect of Continuous business process modeling, Continuous Requirements Engineering, and Human-Centred Design in relation to Continuous Software Engineering. It especially focusses on the problem whether Continuous Requirements Engineering without Continuous Software Engineering makes sense.
Originally, software was developed according to the waterfall life cycle model. The
spiral model changed this approach dramatically. However, the two process phases of
development and application were still distinguished. From the software engineering
point of view application of software goes together with maintenance. Maintenance
begins when software development ends. A lot of attention has been paid to
development methods and related life cycle models. However, the maintenance activities stayed
unstructured at the same time. Because of their advantages for rapid changing
application domains, agile software development methods became more and more popular.
There have been nearly no discussions about agile methods for maintenance. In [
Recently, Fitzgerald and Stol [
The term Continuous Software Engineering can be traced back to 1998. During that
time, it was called “Continuous Engineering for Industrial Scale Software Systems” by
Weber and Müller [
Fitzgerald and Stol use the term BizDev (business development) for a continuous influence between business strategy and development. The more often used term DevOps (development and operations) refers to a “set of practices that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes”1. It relates development of software to operations in the sense of Continuous Monitoring the way the software interacts with by the users. For DevOps the quality assurance plays an important role. This is reflected by Fig. 2. It represents DevOps as intersection of software development, quality assurance, and operations. It can be considered to start with a plan and create the software afterwards. After verifying the quality of the software it can be packaged and release. After configuring (deploying) the software its usage can be monitored. Based on the monitoring a new plan for creating software can be specified. The interconnection of development and operations of DevOps is visualized by Fig. 3.
There are several attempts to provide such a pipeline of a tool chain. Such a tool chain can provide an immediate feedback from users to developers. However, there is no need to have always automatic feedback. Observation by humans can help as well. In some way, the monitoring activity can be considered as some kind of requirements elicitation. From this point of view, DevOps can be considered as part of the requirements engineering activities. However, those activities are part of the Business Strategy as well. We will come back to this aspect in the discussions. 2.2
During the last two decades, agile development methods have been used in a lot of successful projects. They became more and more popular. Nevertheless, most of the time those methods are focused on customers and not on users.
In the first agility principle of [
ISO 9241-210 is the standard for the HCD process that consists of a planning phase and four phases that are performed in an iterative way.
A visual impression of the HCD process model is provided by Fig. 4. Plan the human-centred
design process
Specify requirements Iterate where appropriate
Evaluate design against requirements
Understand & specify context of use Produce design
solutions Design solution
The context of use is tried to be understood in the first phase. Stakeholders are identified. Their roles and tasks are analyzed and typical application scenarios are specified. They include artefacts and tools from the domain. Additionally, surrounding people, services, and objects together with their location are identified.
This analysis allows the specification of requirements. Additionally to the goals of users, functional and nonfunctional requirements are identified.
Based on the requirements, first design solutions are produced. They include first ideas of user interfaces.
The design solutions are evaluated against the requirements. If they are met, the development process comes to an end and the implementation of the application core can be performed.
Otherwise, three possible continuations exist. In case of serious problems, one has to analyze the context of use again and has to proceed with the first phase. This can be considered as the worst case. If the context of use was understood correctly but some requirements were specified in the wrong way, one has to rewrite them or identify some new ones. Finally, it can be possible that only new design solutions are necessary.
Unfortunately, the process model of Fig. 4 does not consider the integration of HCD
into a development process. We do not want to focus on this aspect here. The interested
reader is referred to the following papers [
Currently engineering-based approaches for software development are mainly applied to large enterprises that have relatively long change cycles. Much higher flexibility is required if modifications are necessary more frequently. The engineering processes grow in such cases into continuous engineering that requires Continuous Requirements Engineering. This can only be successful if rigid engineering principles are combined with agility, emergence, and spontaneity to support sustainability and viability of the systems under development.
Innovative enterprises need new approaches, methods, and tools to be capable to embrace the growing variety of opportunities and challenges offered by fast changing and hardly predictable environment. For this type of companies, Continuous Requirements Engineering seems to be very supportive. However, it has to be integrated with management and design approaches.
It is common ground that wrong requirements cause a lot of problems. Many projects totally fail because of wrong specified requirements. Others waste a lot of money because the correction of resulted errors in the implementation is very time consuming and labor intensive.
Therefore, new ideas in identifying continuously the correct requirements are very important.
This was the reason for organizing workshops with this topic. The first one was
organized in 2015 at REFSQ in Essen [
Leah Goldin et al. [
By Qureshi et al. [
Indeed, monitoring of running systems might be very useful. However, this is not specific to adaptive systems. It seems to be useful for any kind of application. In this way, Continuous Requirements Engineering has to find its way to general software systems. Its important role should be reflected in the model of CSE. 2.4
The term Continuous Business Process Modeling is not used so very often. However,
the idea of Continuous Business Process Improvement (CPI) has been discussed for
several years. The book from Harrington [
The term CPI is perfectly defined by Professional Business Solutions Inc. (PBSI): “To maintain their competitive advantage organizations must streamline their operations and processes. Continuous Process Improvement (CPI) is a strategic approach for developing a culture of Continuous Improvement in the areas of reliability, process cycle times, costs in terms of less total resource consumption, quality, and productivity. Deployed effectively, it increases quality and productivity, while reducing waste and cycle time. Since many business processes rely on information and participation from more than one department and even different organizations, CPI is designed to facilitate these processes by integrating the various components into one streamlined system that runs smoothly and efficiently on a partially or completely automated flow of steps.” 3
Milewski et al. [
It seems to be common sense that Continuous Process Innovation is an integrated
part of companies. Bergener et al. [
It is widely accepted that models of organizations in connection with business
process models are very important for BPM and the corresponding IT support. According
to Fleischmann et al. [
Fitzgerald and Stol [
Additionally to those aspects, the idea of modeling seems to be attractive. From our point of view, Continuous Business Process Modeling seems to be an important activity as well in software engineering as in business administration. It should be integrated into the general approach of Continuous Software Engineering of business applications.
Continuous Business-Process Modeling should be part of the Business Strategy.
This idea is supported by Bukša et al. [
An approach that allows the rapid execution of business-process specification was
provided by Fleischmann et al. [
Within the previous paragraphs, the idea of Continuous Software Engineering,
Continuous Human-Centred Design, Continuous Requirements Engineering, and Continuous
Business Process Modeling were recapitulated. Originally, there was the suggestion in
[
Additionally, in [
Fleischmann, Schmidt, and Stary [
Obviously, Continuous Business Process Modeling has to be combined with Continuous Requirements Engineering to become successful.
The usability of software systems will be very important in the future as well. Humans have to be supported in their daily work as good as possible. Good technical solutions and good business processes are not enough. They have to be supported by good user interfaces. Therefore, following extensions visualized in Fig. 5 are suggested for the concept of Continuous Software Engineering.
Continuous Software Engineering might make sense without Continuous Requirements Engineering when no further development of functionalities is planned and only bugs have to be eliminated in a software system. However, this seems to be a very rare situation. Changing environments in reality ask for continuous elicitation of new or changing requirements.
On the other hand, Continuous Requirements Engineering does not make sense if no conclusions are reached. The software has to be adapted to the new needs as soon as possible. Therefore, Continuous Delivery is needed. This can be reached best with Continuous Software Engineering.
Based on references and own experiences some ideas regarding shaping the concept
of Continuous Software Engineering were presented. It was suggested to integrate
Continuous Human-Centred Design, Continuous Business Process Modeling, and
Continuous Requirements Engineering into the approach of Fitzgerald and Stol [