Can we create projects without software engineering

Software engineering and software engineering research in the age of digitization


Digitization and the associated digital change pervade all areas of life. High-quality software is the central component and driver of digitization. The engineering-based creation of software, software engineering, also plays a central role in digital change and is itself subject to major changes. This article therefore tries to determine the current position of software engineering and its research in the age of digitization.

“Computer science is changing. That is why computer scientists also have to rethink their role in society. "

von Ranga Yogeshwar 2018 at the computer science conference of the GI.

Current status and observations

Digitization not only affects society, it also requires a redefinition of the location of computer science and computer scientists, as suggested by the science journalist Yogeshwar in his quote above. Since all aspects of digitization are based on software, this article is intended to attempt to redefine the role of software engineering and its research in particular. Software-based products, systems or services have already permeated practically all areas of life. This makes software, and thus software engineering, a critical component and central innovation driver of digitization in all areas of life. Scientifically, too, there are new opportunities and challenges for software engineering as a driving discipline in the development of any technical innovation. However, it is precisely the opportunities that must not be sacrificed to the competition for bibliometric numbers as an end in itself.


Specifically, we can currently observe at least these seven trends in software and software engineering:

  1. 1.

    In many products, software plays the role of the essential driver of innovation or products are supplemented by software-based services in order to differentiate themselves significantly on the market. Examples are automated driving or the digitization of business processes.

  2. 2.

    Software integrates devices and services and is therefore the core of so-called systems-of-systems. Examples are the topics summarized under “Industry 4.0”, the Smart Energy Grid or modern multimodal mobility systems.

  3. 3.

    In fact, software is increasingly being developed by people who have not primarily learned it. This is partly due to the undersupply of the labor market and partly to the domain knowledge necessary for development. Necessarily and fortunately, at least the programming of software becomes a commodity, the possibilities and basic features of which everyone should understand at least to some extent.

  4. 4.

    Software is increasingly using AI techniques to learn, improve or adapt functionalities. This restricts and sometimes even prevents the checking of quality properties during the development phase, since the actual behavior of the software can only be foreseen after the training phase and cannot be deduced simply by analyzing the code or conventionally testing requirements. Examples can be found in image and language processing and thus also in safety-critical systems such as autonomous vehicles. Although this has always been partially the case due to the use of databases, for example, the data now play a stronger role in defining the behavior of software. In addition, AI technologies (e.g. through new image and speech recognition processes) have also contributed to an expansion of the spectrum of user interfaces and thus the importance of the user experience.

  5. 5.

    For the research process in software engineering itself, data is also crucial in order to empirically test hypotheses. However, the almost unlimited availability of data in software engineering also harbors risks for the research process. Too often, data is generated from software repositories or through surveys and then published without substantiating it with a theory, a precise context definition or a vision for developing a method, which means that the benefits of this work for the discipline of software engineering remain unclear.

  6. 6.

    Software intervenes more and more normatively in the realities of life. Software products already have an institutional character: They regulate and set specifications, but often without the legitimation of the usual institutions. They will therefore necessarily be increasingly regulated by the state in the future. This includes, in particular, the protection of personal data as an essential component of protecting people themselves.

  7. 7.

    The use of software also has an impact on the cognition and personality of the users as well as on society as a whole. These effects are recognizable today, but not really assessed or even reflected in the development of the software.

With the industrialization and socialization of software and data, it can also be observed that more and more people are actively involved in the development of software, be it by providing requirements, testing systems in the field or participating in software development itself and that ever shorter innovation cycles are accompanied by ever shorter development cycles. Specifically, software can be changed, expanded and adapted to a large extent at runtime thanks to reloadable components and apps. As a data source, humans are now (more passively) part of software ecosystems. But more and more people will also need the ability to program rudimentary software for active configuration (e.g. the many individual devices in the future E-Home) (“programming as a commodity”). In addition, the human being as a user is moving more and more into the focus of development in order to optimize the user experience through new interfaces such as voice input and output or augmented reality. In the future, software engineering will not only have to deal with the development of software, but also with its highly adaptive configurability, user acceptance and the quality assurance of configured software that has been trained using data.

From a technical perspective, the above observations give rise to new challenges, which also require a new definition of the position of the now 50 year old discipline of software engineering [1,2,3,4]:

  1. 1.

    Software engineering takes up regulations and understanding of values ​​and tries to develop processes, algorithms and their configuration data as well as architectures in order to implement them systematically.

  2. 2.

    Software engineering packages software approaches in such a way that non-software technicians can also use them. Database systems that can also be used sensibly by non-computer scientists can serve as an example and role model. The utilization of essential algorithms, especially machine learning, is a further interface for other disciplines, admittedly not only, but also to the social and social sciences.

  3. 3.

    Software engineering is of course primarily concerned with software and the necessary fundamentals for its development. But people and organizations have a decisive influence on both areas. The development and investigation of software engineering artifacts therefore requires the inclusion of the context in which they arise and the context of use. This is one of the reasons why the application of empirical research methods and theories from the social sciences such as psychology or sociology is necessary in order to further integrate human and organizational context factors in the software engineering research process. In this sense, software engineering not only has features of traditional engineering sciences such as mechanical engineering or electrical engineering, but also differs from them through this additional social science character.

Consequences for software engineering

Some consequences for software engineering can be derived from this:

  1. 1.

    One of the most important consequences of these observations is that software or the actions, suggestions and decisions that software makes or executes must be more comprehensible in the future. This applies in particular to adaptive software, to learning software and to software that is intended to be modifiable by end users to the extent specified above. Creating such software is of course also a challenge for software engineering, as both the form of the explanation must be simple and easy to understand for users and, for example, in the case of adaptive and learning software, explanations cannot necessarily be defined and fixed in advance.

  2. 2.

    Software engineering is increasingly pushing itself into the role of more comprehensive systems engineering. Due to the increasingly dominant role of software in technical systems, the relationship between software and systems engineering is changing. While software engineering could previously be viewed as part of systems engineering, today software engineering itself often offers the basic methods for developing software-intensive technical systems. Software engineering is therefore developing from a "secondary occupation" of the systems engineer to the primary driver of development. A number of consequences can be derived from this, which primarily affect development processes. The function-oriented software development process still clashes with the primarily geometrically decomposing system development process. Many methods for the systematisation and automation of software engineering activities in decomposition, synthesis, quality assurance, but also in the management of evolution and variants still have to be transferred to the system development process. Only then can the agile process methods desired by many be incorporated more effectively and profitably into the system development.

  3. 3.

    Software engineering has always been and will become even stronger: an integration discipline. Individual products and services are networked through software. This often only gives software the opportunity to implement innovative scenarios, e.g. B. for energy supply with regenerative forms of energy, mobility in a combination of different modes of transport or production plants networked to create complex value chains. As a result, the software engineers also play an essential role in “finding” or even “inventing” and defining the actual functionality of the systems-of-systems. While the products are becoming more and more integrated through networking, the roles and skills of the developers involved in a product are becoming more and more different. This applies both to products and to the increasingly networked and digitized world of production. Not to be neglected here are the increasingly complex software tools that are used for development itself and, due to the networking, will in turn maintain the connection to the delivered, but observable and updateable product.

  4. 4.

    Software becomes data-driven adaptive. By using machine learning methods to provide software functionality, it can often no longer be checked at development time, since the functionality is determined not only by the code but also by (training) data. Here we have to learn to understand under what conditions and to what extent a system to be built can still be safeguarded at development time, under what conditions runtime monitoring by so-called "monitors" is possible, when an a ‑ posteriori analysis of errors is still permissible or when a System may not be built because it can no longer be safeguarded. And this applies both when the training itself is already completed during the development phase and when the system continues to learn in operation (“life-long learning”).

  5. 5.

    Software must be built in compliance with standards and laws. The necessary increasing regulation of software-based products and services, especially in the area of ​​data protection and personal safety, results in new requirements for software and its development methodology. So far, requirements such as the protection of personal data according to changing declarations of consent for different changing types of data usage over the entire life cycle of the software could not be systematically implemented, let alone proven.

What all these challenges have in common is that, on the one hand, the complexity of the software will continue to increase massively as a result, and on the other hand, more and more people in different roles will be dealing with software and its development and with its functionality and decisions even more than before will depend. In particular, one of the consequences mentioned above is that the need for traceability and explainability of software will also increase. This is the only way to achieve the necessary acceptance among users, organizations and society as a whole. It is also clear that there will be even fewer people than today who will have an overall understanding - or even just a detailed overview. Maintaining the consistency of the various views of a system is therefore becoming more and more important.

Further development of software engineering

In the course of the anniversary "50 years of software engineering" [1] - since the NATO conference in 1968 - there are several discussions about its essence and the further development of software engineering as a discipline. Based on the high practical relevance of software engineering solutions, Basili and Briand [2] propose that software engineering research should be more context-oriented, since the applicability and scalability of software engineering solutions are largely dependent on context factors such as people (e.g. his Personality type and knowledge background), the organization (such as cost and time restrictions) or the domain (such as the criticality or the required compliance to standards). In their context-driven research paradigm for software engineering, they propose to no longer primarily develop top-down general approaches without taking contextual factors into account, but rather to develop bottom-up, in collaboration with practitioners, innovative solutions and thereby identify relationships and develop theories and to evaluate it scientifically primarily through the use of empirical methods. In connection with this, Broy [3] emphasizes the integrative character of software engineering for all established engineering disciplines as well as the need to expand software engineering training due to the strategic and social importance of software so that software engineers can make competent decisions of strategic importance . Booch [4] sees abstraction, separation of concerns, distribution of responsibilities and simplicity for managing complexity as the central fundamentals of software engineering, which will apply to AI systems in the future in order to provide answers to central questions in these systems, such as after their life cycle, their quality assurance or their configuration.

We think that the further development of software engineering and in particular the integrative application of software engineering in combination with other disciplines is essential in the next few years. In the last 50 years, a lot has happened in software engineering. A solid and large collection of methods allows us to precisely dovetail agility with the constructive development and synthesis of the software and analytical quality assurance. By its very nature, requirements engineering has always been a methodology that is highly interested in innovation. Software architecture enables function-oriented, task-oriented, oriented to physical conditions or data-oriented complex challenges to be broken down, organized and implemented in robust solutions. Modeling has found its way into the software development as a trait for the abstraction and representation of the functional essence of a system through the UML and SysML standards, but also through domain-specific language developments. Variant and version management are just as much in the toolbox of software engineers as simulation, test automation and analysis tools for quality assurance as well as measuring tools of all kinds.

However, one of the great challenges for software engineering research results themselves remains their practicability using tools. Tools often arise as a by-product of scientific research or are pushed forward as open source tools by a common community as far as this community is possible. Tools today are highly complex and require both ease of use and the relevant functional reliability and must be scaled to large projects.

What does software engineering have to offer for other disciplines?

Software engineering, like any engineering discipline, is initially a constructive science. In the 50 years since the discipline was founded, it has increasingly been learned what consequences are derived from the special nature of software, namely that it is not material. Software is currently changing the everyday life of individuals, organizations and ultimately society in every respect more quickly than almost any other discipline before. Almost all disciplines and domains are about to be digitized.To determine where we are, we therefore relate software engineering to both the other engineering sciences and the social sciences.

Relation to other engineering sciences

As described in the introduction, the relationship to other engineering sciences is currently shaped by

  1. a.

    the increasing share of software in many technical systems,

  2. b.

    the networking of these systems to form systems-of-systems through software,

  3. c.

    the high proportion of software in the degree of innovation of technical systems and

  4. d.

    the anticipated benefit when specific software-technical procedures are also used in systems engineering.

Ultimately, these factors are mutually dependent, so that we will do them together starting with the last one.

Compared to the artifacts of other engineering disciplines, the property of software to be non-material allows a larger design space that is hardly restricted by physical material properties. Tools and methods have been intensively developed under the heading of agility in recent years, so that fast feedback and innovation cycles are common in the software. We have known since around 2000 that the time-to-market has become even more important in the Internet age and that "a year only takes three months" on the Internet. Negative excesses of rapid development, such as banana software that only matures with the customer, are due to methodical measures such as active beta testers, test-driven development, early reviews (e.g. also pair programming) or continuous monitoring of customer behavior and thus also the customer satisfaction has been intercepted.

When software itself has no physical manifestation, its “production” is reduced to the build process, deployment and configuration. Since these processes can largely be automated, the development process, which is traditionally handled by software engineering, is the limiting factor. The individual developing people, the team structure and composition as well as the boundary conditions through the organization play a greater role than in other engineering sciences. They significantly shape the process of product development and thus ultimately also have an intensive influence on the quality properties of the product itself. These human and organizational factors are therefore also an important influencing factor and thus an object of investigation in software engineering. In addition, software engineering as a discipline offers a wealth of techniques and methods that optimize the efficiency and effectiveness of human interaction in the context of software development.

This results in a number of possibilities for the development of software-intensive technical systems to transfer insights from software engineering. These include, for example, procedural models that no longer assume that an entire system can be planned in advance, but allow the decentralized development of systems that are loosely coupled and are not subject to a common development process, although they share system components and interfaces. This also includes, for example, agile processes to support fast innovation cycles. Since software ultimately also contains a model of reality more or less explicitly and in detail, modeling methods from software engineering, such as UML, SysML or meta-modeling, as well as the synthesis, analysis and transformation of models are special Interest in systems engineering, especially since the handling of models and their analysis and simulation fit the existing engineering approach anyway. In practice, however, it has been shown that the models of software engineering and systems engineering or the underlying paradigms cannot simply be combined and therefore a great deal of fundamental research is still necessary.

The use of modeling techniques is particularly visible when they are not only used for development, but also during the operation of the software. Traditionally, these are, for example, explicit data models or business process models, which should sometimes be within limits, but more often also flexibly adaptable. In the product world, these are digital twins, i.e. purely virtual "twins" of physical artifacts operated by models and simulations, which also contain meta-information and can be used through predictive techniques to predict properties, but especially to monitor and control their physical twins . The joint, because closely interlinked, development of the physical product and its virtual twin requires new technologies. This is also necessary because many physical products are supplemented, expanded, updated or modified by spare parts over time and a digital twin must reflect this and ideally even anticipate it. Here, the existing understanding of "digital engineering" is substantially expanded by not "only" supporting existing development processes with software, but now also using software technology methods to enable new development processes. One vision would be the integrated modeling and analysis in a common design space in which software, but also physical artifacts, are methodically treated together. Of course, these procedures must systematically deal with issues relating to the different life cycles of software and physical artifacts, while ensuring their consistency.

Relation to the social sciences

As always in software engineering: the introduction of new systems changes the behavior and activities (business models and processes, support, etc.) of users. That has to be the case, otherwise the software would be pointless. Digitalization, which is currently advancing massively, will therefore have severe consequences for individuals, organizations, companies and society that are definitely comparable to those of industrialization in the 19th century. Obviously, communication behavior has already changed massively. However, studies also show changes in human cognition due to the ubiquitous usability of digital devices or the way teams work. The effects of newly emerging business models and their social effects can be immense in social and working life if the added value through automation and the associated loss of traditional jobs in favor of newly created digital jobs go hand in hand. In addition, there are business models that create value from personal data and social media applications that at least rebalance basic rights such as privacy or equal treatment through permanent feedback on the actions of individuals.

Research into these effects on individuals, organizations and society as a whole is already underway in the social sciences as a technology assessment and is also influencing software engineering.

Therefore, there are several interfaces between software engineering and the social sciences, which are also relevant because many possibilities of digitization and the resulting forms of use have not yet been implemented, but are only being considered. This includes both techniques of storing and processing personal data in the field of data science and of course the methods of artificial intelligence, which will solve a few more problems in the current hype cycle, but this time all non-problems that need intelligence to solve, should get a grip. Accordingly, software engineering has the following interactions with the social sciences:

  1. 1.

    Software engineering can provide scenarios that make it clear which software functionalities are or can be implemented in the near future. Scenarios that improve the well-being of individuals or the general well-being of people are also definitely of interest here, but also scenarios that are possible but not desirable according to the current understanding of values. In this way, investigations into the long-term consequences and discussions about what is socially desirable can be triggered and conducted in a fact-oriented manner.

  2. 2.

    Software engineering takes up regulations and understanding of values ​​and tries to develop procedures, algorithms and architectures in order to implement them systematically. This point is, so to speak, the opposite of the previous point, where software engineering provides scenarios; here it takes on those from the social sciences.

  3. 3.

    Software engineering supports software development approaches with methods and tools so that non-software technicians can also use them. The database systems already mentioned or end-user computing, which is becoming more widespread in various forms, can serve as an example. This includes simple and intuitive configuration languages, such as those offered in the home automation sector, or wizards for certain particular problems. In addition, software engineering also contributes to the utilization of essential algorithms, especially in the area of ​​machine learning of relationships from data sets, whereby new quantitative methods are effectively available to the social sciences.

  4. 4.

    With the penetration of all areas of life with software-based products and services, people as users, whose user experience needs to be optimized, are increasingly becoming the focus of development. Such usability aspects can only be adequately addressed with social science methods, especially from psychology. The importance of the user experience for the success of software-based solutions has also increased significantly due to a large number of new user interfaces such as for voice input and output or augmented or virtual reality.

  5. 5.

    As already discussed, people and organizations have a decisive influence on software engineering. The development and investigation of software engineering artifacts therefore requires the application of empirical research methods and theories from the social sciences such as psychology or sociology in order to be able to integrate human and organizational context factors in the software engineering research process. In this sense, software engineering not only has features of traditional engineering sciences such as mechanical engineering or electrical engineering, but also differs from them through its more pronounced social science character.

Actually, it has always been a task of software engineering to ensure that software is traceable. However, the complexity of software, which arises from ever more extensive technology stacks and from ever more and more networked application components, continues to rise significantly. Self-learning components, but also traditionally programmed, more intelligent (“smart”) components for checking more and more critical systems with more and more sensors and therefore insecure systems are being installed more and more frequently. Machine learning components further complicate this. The comprehensibility of software, in particular the traceability of decisions and controls that software makes or exercises, will therefore become much more important in the near future. In doing so, traceability during use is also necessary “post mortem”, for example to improve the software or for legal clarifications. If this does not succeed in the long term, robot psychological analyzes for the behavior of intelligent machines in the sense of Asimovs will be necessary.

While the other engineering sciences essentially use the natural sciences and mathematics as basic sciences, for software engineering these are primarily mathematics, but also the social sciences, which is why a cross-fertilization in both directions (between software engineering and social sciences) is useful and necessary.

What constitutes modern software engineering research and which topics need to be discussed?

In order to define current and future research contributions in software engineering and to specify the relationship to other sciences, it is necessary to characterize modern software engineering research in the age of digitization.

Fig. 1 shows the core areas of software engineering research and their interrelationships with application domains and basic sciences. In the sense of the context orientation of software engineering [2] mentioned above and the penetration of all areas of life with software, application domains such as production, logistics, healthcare, but also scientific disciplines themselves (especially computer science) provide the context, i. H. Data and problems from a specific context for software engineering research. In software engineering research, artifacts (such as tools or development methods) and evidence, i.e. H. empirically or formally well-founded insights, provided in order to satisfactorily address the problem in the application context.

As an engineering discipline, software engineering research draws on basic sciences such as mathematics, computer science, other engineering sciences or social sciences in addition to its own research approaches. These provide algorithms and theories and support the design of solutions and the acquisition of knowledge in software engineering. In the following sections we deal in detail with the core of software engineering, including the relationship to application domains and basic sciences.

Core of software engineering research

Software engineering and the associated research have been clearly defined for a long time, and current discussions such as here or in the course of 50 years of software engineering [1] do not change anything. The following definition, made in 1990 in the IEEE Glossary of Software Engineering Terminology [5], is still valid today and does not need to be adapted from the authors' point of view:

  1. 1.

    The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.

  2. 2.

    The study of approaches as in (1).

It defines software engineering as an engineering discipline ("application of engineering to software") with its own methodology ("systematic, disciplined, quantifiable approach"), applied to all phases of the software life cycle ("development, operation, and maintenance of software") ). The two-part structure of the definition also expresses the close interlinking of software engineering (1) and software engineering research (2). The boundaries between the two are sometimes blurred. In software engineering research, the systematic reflection is clearly more pronounced and the desired benefit and the generalizability of the results beyond individual projects is significantly greater. A sharp distinction cannot be drawn, however, since, for example, the development of a framework, tool or meta-model can have both an application and a research character at the same time.

Software engineering research typically differentiates itself into the specific consideration of the different activities in the software life cycle. These are analysis, design, implementation, testing, deployment and maintenance. In addition, there are cross-sectional activities such as project management, quality management, modeling and modeling languages ​​or variant management, which are also part of software engineering research. The central objects of investigation in all these core and cross-sectional activities of the software life cycle can be assigned to four areas:

  1. 1.

    The program (the code or its execution) and the specification (the informal diagram, the formal textual or graphic model, the natural language requirement)

  2. 2.

    The person (as developer, user or in one of the many other roles) and the organization (development team, integration into an overall organization)

  3. 3.

    The product (e.g. software-driven innovation, quality, software logistics) or system (e.g. the integration of software with hardware or the integration of systems)

  4. 4.

    The method (the process, the human activity, the automated processing algorithm in the tool, process models) or the tool to support all phases of the software life cycle (such as modeling or test tools)

As an engineering discipline, software engineering sensibly follows a design science approach in which artifacts can relate to all of the above-mentioned objects of investigation in software engineering. The term “artifact” is relatively broad and includes tools such as automated or supporting algorithms for generating test cases, templates for documenting requirements or a methodology for estimating the cost of software projects. With the penetration of various products and services with software, in addition to the systematic construction of artifacts, creative innovation is playing an increasingly important role and is increasingly supported by approaches such as design thinking or continuous experimentation. Tools play an outstanding role in software engineering, as they make the artifacts developed accessible for practical use. It was only the existence of certain types of tools that made modern development methods, such as agile development, possible. Extreme programming would be unthinkable without a lightweight test infrastructure, fast generators and translators, and development environments with integrated refactoring tools.The convenience of specific editors for programming languages ​​(type-specific auto-completion, highlighting, refactoring in the editor) has changed the programming method of developers massively. If we had such tools in the earlier phases, requirements engineering, architecture and design would also be much more efficient. We also lack good tools for tracking requirements and design decisions that are urgently needed to anticipate the impact of changes.

Software engineering or the application in concrete projects typically includes a pronounced reflection that is used both for optimization within the project and for the transfer of cross-project knowledge. The consequence of this is that part of software engineering research must necessarily be carried out in an industrial context and that empirical methods must therefore be used in order to derive evidence in the industrial context, for example to support decisions as to which process model is to be adapted in which which context works most effectively. The “Manifesto for Agile Software Development” [7], for example, was formulated in 2001 at a meeting of practitioners and brought into practice in software development. The task of software engineering research in this context is to further develop the methods in a scientifically sound manner and to critically and empirically question and evaluate their practical use in order to optimize them depending on the application context by providing evidence.

Due to the application orientation and the digitalization driven by software, influencing factors and influencing groups also play a major role in software engineering research. The influencing factors include reliability (“dependability”), sustainability (“sustainability”) and user friendliness (“usability”). Reliability is traditionally strongly influenced by the use of software-based systems in critical domains such as aviation and includes attributes such as reliability, safety, availability and ultimately also performance, maintainability ) and information security ("Security"), but increasingly also traceability and explainability, especially in the context of modern data-driven applications. Based on the environmentally friendly handling of resources, sustainability also includes ethical aspects such as the fairness of decision algorithms. Usability stands for the user-friendliness or usability of a software-based product or service and is becoming increasingly important, especially with new user interfaces.

The economy, the state and society play a major role as influencing groups, for example by defining the legal framework for the development and use of software, for example through the General Data Protection Regulation with regard to the processing of personal data.

Relation of software engineering to your basic sciences

As an engineering science, software engineering, like other engineering sciences, also depends on the knowledge of basic sciences. For the other engineering sciences, the natural sciences and mathematics are essentially the basic sciences; in software engineering, the situation is more complex due to its immaterial and inherently human character. Of course, computer science, which provides genetic algorithms for search-based software engineering or the related artificial intelligence, and data science as data science are important basic disciplines for software engineering. With the increasing importance of cyber-physical systems, other technical sciences such as electrical engineering or mechanical engineering or physics are important basic disciplines as their basis. As already mentioned, economics and social sciences such as business administration, sociology or psychology are important basic sciences for software engineering research. If biological information processing will soon play a more important role, as is suggested today by human brain projects or the modeling of biological systems with computer science methods, biology and chemistry will also become even more relevant as a basis.

The close relationship between software engineering and basic sciences can already be seen in the Software Engineering Body of Knowledge (SWEBoK) [6], in which separate chapters Computing Foundations, Mathematical Foundations and Engineering Foundations essentially refer to the basic sciences of computer science, mathematics and engineering.

In software engineering research, certain questions arise that are addressed with the help of the basic sciences. These provide algorithms or theories that can be of a formal mathematical, physical or social science nature, which flow into the development and evaluation of solutions in the research process of software engineering and which can flow back into the application domains as artifacts and evidence.

Depending on the object of investigation, software engineering can therefore be very close to mathematics and analytically formal, for example to deal with formal models or programs, but also very empirically and experimentally, for example to investigate specific hypotheses about the human factor in development and use. The third major pillar of knowledge gain, simulation, is already being used intensively in software engineering as a test and becomes even more intensive in other forms with integrated quality assurance of software (for example through architecture or behavioral simulation) in a complex system such as a smart city play a role. In software engineering, however, the properties of classic engineering disciplines are still missing, such as the consistent model-based simulation prior to implementation for early quality assessment. Apart from individual approaches (such as software architecture simulation), however, it is also unclear whether such an early model-based simulation for quality assessment can be directly transferred from the classic engineering disciplines to software engineering, since software itself, in contrast to physical artifacts such as bridges, has an inherent model character Has.

Software and thus software engineering has always been an integration discipline. Of course, this is particularly true for products that are typically integrated from subsystems and components. However, this also applies to development methods in which, depending on the type of subsystem, a wide variety of methods from other information sub-disciplines are used. Software engineers are therefore generalists. In contrast, there are practically independent specialist roles for each sub-aspect of the software. This is the case in the area of ​​networks, operating systems, databases, embedded systems, the cloud, translator construction, the development of (domain-specific) modeling languages, user interaction and, of course, speech and image recognition with statistical methods or machine learning. Software engineering therefore not only accesses basic disciplines such as computer science, but also extends and enriches them. For this reason, computer science in particular and science in general are also listed as application domains in Fig. 1.

Relation of software engineering to your application domains

The major problems and challenges of software development and thus also of software engineering research are today strongly influenced by the application domain. The term application domain can be understood relatively broadly and includes classic domains such as finance, health care, mobility such as automotive or avionics, logistics, entertainment, trade or production. In addition, any scientific discipline such as computer science or any social, engineering or natural science in which larger software systems are currently in use can also be understood as an application domain.

The application domains provide the context; H. Data and problems from a specific context, ready for software engineering research. In software engineering research, artifacts (such as tools or development methods) and / or evidence, i.e. H. empirically or formally well-founded insights are provided in order to satisfactorily address the problem in the application context.

It is now clear that the questions for software development are very related in all domains, but the answers often have to be very different. This is already evident from the very heterogeneous technology stacks and the programming languages ​​used. Accordingly, there are separate versions of software engineering for many domains and therefore also software engineering research. Domain-specific software engineering always means intensive collaboration with domain experts.

Where are you travelling to?

Digitization of software engineering and systems engineering

The digitization currently taking place in practically all domains requires domain-specific, effective processes to quickly create software and further develop it in a reusable manner. Too many domains are still driven today by the development methods customary there, which typically conflict with software development methodology and therefore regularly produce frictions in projects. This applies in particular to the classic engineering domains such as mechanical engineering, civil engineering or electrical engineering. As long as the machine is the dominant element of the product, the development process must of course be defined along the machine and its components and therefore typically offer geometric decomposition. However, since software functionality is increasing more and more and software is becoming the driver of innovation, it makes sense to think about renegotiating the development processes that focus more on a functional decomposition along the software functionality. The software development methods commonly used today, such as the V-model or agile methods, cannot, however, be directly transferred to other disciplines, although there is an observable and justified hope that a generalization of software engineering methods should work for other domains. It is an outstanding task of software engineering in cooperation with the traditional engineering disciplines to develop integrated, holistic development methods and tools based on them. However, the development of a tool that is used by practitioners is by no means trivial today. Explicit tool research is necessary in order to even enable the construction of industrially usable tools, because modern and therefore often intelligent tools could support software development far beyond the current level. However, this only applies if such tools on the one hand have a certain degree of maturity and, on the other hand, enable expandability and project-specific adaptability through explicitly open interfaces and modularization techniques. Systems engineering and especially the use of modeling and simulation techniques, especially in quality assurance, are essential challenges in order to significantly shorten the time to market readiness and the development costs of innovatively further developed products. This is essential, especially in high-wage countries, in order not to lose the ability to innovate.

The relationship between software engineering and data

Of course, data that contain more and more domain-specific information is also playing an increasingly important role in the functionality of software. So far, data has been processed as an object of software functions, but it has not essentially determined the functionality itself, as will increasingly be the case in modern data-intensive systems. This is now changing thanks to machine learning processes. This eliminates the possibility of fully analyzing or testing the software at development time. For this reason, procedures for safeguarding self-learning, highly adaptive software are necessary, which clarify the conditions under which systems can still be analyzed at the time of design, procedures for runtime safeguarding and procedures for a posteriori error analysis. In addition, data play a further role as “first class entities” in the modeling of privacy requirements and general access regulations.

The increasing availability of data also offers software engineering research a great opportunity to empirically test hypotheses. However, the almost unlimited availability of certain types of data, for example from open source repositories, and the very difficult collection of other types of data, for example in the Industry 4.0 context in software engineering, also harbor dangers for the research process. Too often, data is generated and published from software repositories or surveys, for example, without substantiating it with a theory, an exact context definition or a vision, which means that the benefits of this work for the discipline of software engineering remain unclear. With a view to the natural sciences, the philosopher Karl R. Popper expresses with his statement "All knowledge is drenched in theory, including our observations" [8] that experiments to collect data should be based on a hypothesis to be tested and this hypothesis from a Theory follows. A data collection without an underlying theory may indeed be justified in the initial phase of a research process as an exploratory study in order to derive hypotheses from it. However, these must then be evaluated through further empirical studies. In addition, the availability of many open source repositories obscures the fact that software is not just based on code artifacts.

Quality: reliability, traceability, explainability ...

Reliability (dependability), i.e. the degree to which it can be trusted that a system will provide guaranteed services or have guaranteed properties, is becoming increasingly important with regard to the reliability, security and safety of systems. At the same time, however, it is becoming more and more difficult for highly networked, complex and autonomous systems to ensure the reliability and, moreover, the traceability and explainability of systems (e.g. on the socially necessary clarification of liability issues in the case of harmful behavior of autonomous systems, which can be understood as a sustainability aspect). Promising approaches to address this problem are abstraction techniques based on models that help make the complexity, interconnectedness, autonomy and traceability manageable. Model-based approaches should integrate both generating models, for example for model-based testing, and predictive models based on machine learning. These abstraction techniques should then make it possible, for example, to map relevant properties of the behavior of high-frequency trading techniques in the financial sector in order to examine the interaction of several of these algorithms in an open market with the associated analysis techniques. A challenge here is how, on the one hand, one can abstract from the specific details of the algorithms to such an extent that business secrets are preserved and the analysis can be scaled, but on the other hand still meaningful analysis results can be obtained that a person can still understand the results. The example of high-frequency trading from the financial sector again shows the role of the domain.

Application domains always develop a momentum of their own and each require their own versions of software engineering and thus, meaningfully, software engineering research as well.

Concrete questions in software engineering

From the considerations so far, many specific questions arise which software engineering research should address in order to advance software engineering and its research. Examples of specific questions are:

  • Traceability and explainability of software: How can results be plausibly explained even with non-deterministic, data-intensive software systems?

  • Security as a holistic topic: How can security aspects be appropriately considered in the software life cycle? How can a bridge look like between abstract security models with formal evidence and real software that have evolved in dynamic and open environments?

  • Software engineering and sustainability: Which software engineering methods are required to control and understand resource management?

  • Research methodology in software engineering: What can empirical and formal methods achieve in the research process? What role do contextual factors (especially human and organizational factors) play and what theories does software engineering need and what do they look like? Which instruments can design science best support in software engineering?

  • Automation through tools: That much more can be automated in software development is undisputed. This increases the efficiency of the developers and the quality of the products.How can the dormant potential of better and automated support be leveraged? Which tools are particularly helpful? How can the tools be designed so that the entry barrier is as low as possible? How can research prototypes be further developed into commercially usable tools?

  • Quality assurance for data-intensive systems: With which methods can the quality of software systems, whose behavior is determined by data and the environment and which is not yet certain at the time of development, be adequately ensured? How can simulation, model-based software development, runtime monitoring as well as static analysis and dynamic testing be appropriately integrated?

  • Software in Systems-of-Systems: How do you deal in development processes with the fact that there is no longer a central organization for requirements and development coordination? What does consistency mean in such systems and how can it be restored? How do you reconcile different life cycle models and update speeds? How do you integrate the lifelong connection (measurement, update) between the produced and delivered product and its user and manufacturer?

  • Dealing with increasingly complex development and runtime environments: With increasing functionality, how can you give developers the methodical knowledge to use or develop and maintain such elements?

Software engineering challenges

Software engineering is not a natural science, but an engineering science with a strong focus on the four pillars from Fig. 1:

  1. 1.

    Program and specification,

  2. 2.

    People and organization,

  3. 3.

    Product and system as well

  4. 4.

    Method and tool.

These pillars set software engineering apart from traditional engineering. Precisely because of the people involved in the development process, instead of scientific theories, hypotheses arise from proposed methods and, in particular, also take into account human and organizational context factors. These hypotheses about the properties of a newly proposed method must then be tested empirically, for example through controlled experiments or case studies. In order to make a newly proposed method useful in software engineering and to subject it to empirical testing, it is usually necessary to implement it in whole or in part in tools. Only in this way can the degree of automation of the method, which is made possible by a tool, be incorporated into case studies and empirically validated. Tool making is therefore a necessary and important activity accompanying research. The fact that at least prototypes for tools in software development are created in this way is at least helpful for the industrialization of new software engineering methods and should also be given more political support.

It is a central task of software engineering to develop new visions and to pour them into methods and tools and to empirically evaluate their usefulness, effectiveness and efficiency. This is the only way to maintain and expand the key role software engineering plays in business and society in the age of digitization. According to the statement of the automobile manufacturer Henry Fords "If I had asked my customers what they want, they would have said: faster horses", it is necessary to convert visions into practical methods and tools.

The further development of methods, especially in connection with the described change in the role of software engineering and its stronger interlinking with other disciplines (especially systems engineering), is extremely exciting. While the development of software was previously a partial step in higher-level systems engineering, this relationship is changing with the enormously increasing role of software in almost every technical innovation. From the authors' point of view, this increasingly central role of software will also be reflected in the methods of system development - these will become more software-centric. According to this new role of software in innovations, the product is driven by its software, the electrical or mechanical components are either commodities or are developed according to the requirements of the software. This offers a unique opportunity for software engineering to act as an important driver in systems engineering. This opportunity can only be used if software engineering researchers are aware of their role as engineers and innovators, whose research generates visions for new methods.


  1. 1.

    Erdogmus H et al (2018) 50 years of software engineering. IEEE Softw 35 (5): 20-24.

    Article Google Scholar

  2. 2.

    Booch G (2018) The history of software engineering. IEEE Softw 35 (5): 108-114.

    Article Google Scholar

  3. 3.

    Basili V et al (2018) Software engineering research and industry. IEEE Softw 35 (5): 44-49.

    Article Google Scholar

  4. 4.

    Broy M (2018) Yesterday, today, and tomorrow. IEEE Softw 35 (5): 38-43.

    Article Google Scholar

  5. 5.

    IEEE (1990) IEEE standard glossary of software engineering terminology

    Google Scholar

  6. 6.

    Bourque P, Fairley R (2014) SWEBOK V3.0 guide to the software engineering body of knowledge

    Google Scholar

  7. 7.

    Beck K, Beedle M, van Bennekum A, Cockburn A, Cunningham W, Fowler M, Grenning J, Highsmith J, Hunt A, Jeffries R, Kern J, Marick B, Martin R, Mellor S, Schwaber K, Sutherland J, Thomas D (2002) Agiles Manifest. Accessed November 3, 2020

  8. 8.

    Popper KR (1974) Objective Knowledge. An evolutionary draft, 2nd ed.

    Google Scholar

Download references


Our warmest thanks go to our colleagues in software technology and related fields, whose assessments and comments have been incorporated here, among other things, at the last conferences of the department. We would like to thank in particular (in alphabetical order) Sven Apel, Jürgen Börstler, Michael Goedicke, Lars Grunske, Willi Hasselbring, Udo Kelter, Stefan Leue, Florian Matthes, Barbara Paech, Ina Schäfer, Klaus Schmid, Matthias Tichy, Walter Tichy and Stefan Wagner.


Open access funding provided by the University of Innsbruck and Medical University of Innsbruck.

Author information


  1. University of Innsbruck, Innsbruck, Austria

    Michael Felderer

  2. KIT Karlsruhe, Karlsruhe, Germany

    Ralf Reussner

  3. RWTH Aachen, Aachen, Germany

    Bernhard Rumpe

Corresponding author

Correspondence to Michael Felderer.

Rights and permissions

Open Access This article is published under the Creative Commons Attribution 4.0 International License, which permits use, copying, editing, distribution and reproduction in any medium and format, provided you properly credit the original author (s) and source, a link to Include a Creative Commons license and indicate whether changes have been made.