Catálogo de publicaciones - libros

The design, specification, and correct implementation of software and systems architecture are, after the task of requirements specification, perhaps the most important design decisions when building large software or software-intensive systems. Architectures are responsible for software quality, for a number of quality attributes such as maintainability, portability, changeability, reusability, and deployability, but also reliability, security, and safety. Therefore, the design of architectures is a key issue in system and software development. For highly distributed, networked systems and for cyber-physical systems, we need a design and specification concept which supports composition, parallelism, and concurrency and finally real time but keeps all of the general advantages of object-oriented programming. This requires an appropriate concept of interface. If it is extended to these more sophisticated properties, it covers also functional quality aspects.

Change makes software different from any other artifact created by humans. Although this is known since the 1970s, change is still often handled in an ad hoc manner. Agile development and, more recently, DevOps have been proposed as a solution, and success stories are reported from industry. Still, principled and rigorous foundations that can be taught, practiced, and systematically replicated are lacking. We argue that change has to become a first-class concept and that the development tools used by engineers and the run time environment supporting software execution should be structured in a way that naturally accommodates change. We distinguish between evolution and adaptation and discuss how software can be made self-adaptive, and how it can cooperate with humans in-the-loop, supporting continuous verification and assuring dependability. We discuss how several research approaches that were investigated in the past decade may be integrated and extended in a roadmap of future work leading to progress in tool support and automation to achieve dependable adaptation and evolution.

The way we develop software has changed dramatically over time. As an industry we have followed a zig-zag path moving from paradigm to paradigm and from method to method, changing very much like the fashion industry changes clothes. In this paper we will show that with every new method adoption, we walk into a method prison; a prison that is generally very expensive and demoralizing to escape. Like the fashion industry with the latest styles for the season, companies decide to chase the latest exciting method, only to end up in another method prison. And the cycle repeats.

We will discuss method prisons and what characterizes them. We will also show this has led to a method war. A war that has been going on for 50 years or more, and there is still no end in sight.

How foolish is this? How can we software development professionals continue letting this happen? Have we given up and can’t we see a way to put an end to this story? In this article we will show you a way to dramatically change how we deal with methods. A way, which shows the path to a more successful software world, a world based on sustainable change free of method prisons. A smarter way going forward.

Arguably the prime focal point of a software system’s engineering is its architecture. A system’s architecture is the set of principal design decisions made during its development and evolution. All too often, however, the architecture—and every system has an architecture—is left latent. Such disregard arises from many factors; some would go so far as to say that an explicit focus on architecture is unnecessary. This chapter explores different contexts in which software development occurs and, with respect to those contexts, discusses what kind of attention to architecture is needed, why it is needed, how it may be approached, and benefits that may be achieved through such attention. The objective is to highlight the degrees of architectural rigor and effort that are commensurate with the needs of diverse projects.

Software product line engineering has proven successful in several areas where the products are driven or even dominated by software systems. Yet, this promising approach has not spread across all industries that are software driven. For example, in the insurance industry, product line engineering can be adopted to provide standard software products that explicitly account for variability. However, the typical transformation strategies do not fit to the current state of the practice in software development for the insurance industry. The major obstacles are the current structure of the software development practice, the spread of domain knowledge, the speed of innovation, and the general risks, associated with adopting disruptive technologies.

The extended pilot project is a transition strategy, which avoids these problems. A software vendor can use this strategy to introduce product line engineering as the base for its software product business. The core of this approach is a pilot project that involves several insurance companies as charter clients. The goal of the project is to develop the platform for a product line and to derive a first software product for one of the charter clients at the same time. After the completion of the project, the remaining charter clients and further customers derive their own individual software systems.

In this chapter, which draws upon our daily project work at adesso AG, we first show how the various levels of digitalization have affected, or are currently impacting, requirements engineering. Projects within the context of digital transformation in particular place more stringent demands on requirements engineering because these call for new business models to be developed, and these in turn will only succeed if the new software to be developed does the best possible job of meeting users’ real needs. One possible methodology for this is design thinking, because this method places users and their needs at the center of the design process. Starting with a brief overview of the main ideas and approaches behind this methodology, we show how we have successfully employed the design thinking concept in two concrete project situations.

The serverless paradigm has been rapidly adopted by developers of cloud-native applications, mainly because it relieves them from the burden of provisioning, scaling, and operating the underlying infrastructure. In this chapter, we propose a novel computing paradigm—— that extends the serverless paradigm to the edge of the network, enabling IoT and Edge devices, such as gateways and micro clouds, to be seamlessly integrated as . We propose a reference architecture for the Deviceless Edge Computing. We also analyze the main requirements and challenges to realize this novel computing paradigm from two main points of view: (1) required support for application development, in terms of programming models, and (2) required runtime support for deviceless applications, in terms of main deviceless platform mechanisms. Finally, we show how our existing work in the area of Edge Computing and IoT serves as starting point and as one of main enablers for realizing the emerging Deviceless Edge Computing.

Today’s software development is all about data: data about the software product itself, about the process and its different stages, about the customers and markets, about the development, the testing, the integration, the deployment, or the runtime aspects in the cloud. We use static and dynamic data of various kinds and quantities to analyze market feedback, feature impact, code quality, architectural design alternatives, or effects of performance optimizations. Development environments are no longer limited to IDEs in a desktop application or the like but span the Internet using live programming environments such as Cloud9 or large-volume repositories such as BitBucket, GitHub, GitLab, or StackOverflow. Software development has become “live” in the cloud, be it the coding, the testing, or the experimentation with different product options on the Internet. The inherent complexity puts a further burden on developers, since they need to stay alert when constantly switching between tasks in different phases. Research has been analyzing the development process, its data and stakeholders, for decades and is working on various tools that can help developers in their daily tasks to improve the quality of their work and their productivity. In this chapter, we critically reflect on the challenges faced by developers in a typical release cycle, identify inherent problems of the individual phases, and present the current state of the research that can help overcome these issues.

Software architecture work should be integrated with all software development activities. In this context, the past emergence of software architecture as a discipline is discussed with emphasis on the formalization of architectural models and the reuse of reference architectures in software product line engineering. At present, various architectures are established for many domains and applications. Exemplary, we will take a closer look at recent microservice architectures with a focus on quality requirements. As a look into the future, the envisioned role of an architecture owner in agile teams, the relationship between software development and operations, achieving reliability with agile development, runtime adaptivity with architecture information in the running system, and keeping architecture knowledge up to date for long-living software systems are discussed.