Stephan Roth

Stephan Roth
oose eG

About

66
Publications
8,743
Reads
How we measure 'reads'
A 'read' is counted each time someone views a publication summary (such as the title, abstract, and list of authors), clicks on a figure, or views or downloads the full-text. Learn more
188
Citations
Introduction
Stephan Roth is trainer, consultant, and coach for Systems Engineering, Software Engineering, Modern C++, Software Architecture & Design, and Software Craft/Clean Code Development. He works at oose Innovative Informatik eG in Hamburg (Germany). His current interests and research areas are Model-Based Systems Engineering (MBSE) with SysML, Internet of Things, and C++11/14/17/20.
Additional affiliations
January 2012 - present
oose eG
Position
  • Consultant
Description
  • Trainer, consultant and coach for (Model-Based) Systems Engineering, Software Engineering, Software Architecture and Clean Code.

Publications

Publications (66)
Book
Write maintainable, extensible, and durable software with modern C++. This book, updated for the recently released C++20 standard, is a must for every developer, software architect, or team leader who is interested in well-crafted C++ code, and thus also wants to save development costs. If you want to teach yourself about writing better C++ code, C...
Chapter
An engineered system is a composition of multiple entities. The existence of an engineered system is justified by purposes. The exposed system characteristics permit stakeholders to achieve these purposes. Systems are situated in their system context and may be evolved. Due to the digital revolution, a term which refers to the changes coming along...
Chapter
In this chapter, the authors first discuss the organizational structure around systems architecting and then provide some recipes from their own experience for making systems architecting work in the organization. They focus on approaches that can help creating buy‐in for systems architecting on a peer‐to‐peer level. The organizational structure or...
Chapter
Some people take the view that a team or project organization is Agile if it uses an iterative–incremental process for its development process. This chapter takes a look on the historical origins of the agile movement and how it was influenced. The Manifesto for Agile Software Development is a public declaration that consists of four judgmental cor...
Chapter
Many systems exist in different configurations: a product line, a customized product, or different designs for trade studies. This chapter provides a brief introduction to a broad field along with a couple of ideas. The broad field of product line engineering, model‐based product line engineering, and variability management continue to evolve, and...
Chapter
Architecture frameworks are very well known in the world of Enterprise Architecture development, and System of Systems Engineering (SoSE). There are a number of different frameworks for SoSE, especially in the defense domain. Enterprise can mean a small to mid‐size company, a multinational corporation, or a huge joint undertaking with a common goal...
Chapter
Cross‐cutting concerns are those concerns that are relevant on different levels and layers, but also from different perspectives of the system architecture. There are very different concerns that have this nature. In this chapter, the authors discuss some of the major ones. The nonfunctional requirements are often cross‐cutting concerns, because mu...
Chapter
This chapter focuses on roles without looking at the organization. A role usually goes along with a role description, defining the objective of the role and tasks, responsibilities, and competences that are related to the work to be done. Persons with the system architect role are central in system architecture. The system architect is responsible...
Chapter
Defining “architecture” appears to be rather difficult considering the large number of existing definitions. These definitions share some commonality, though in detail differences become obvious. Vitruvius identified three branches of architecture: buildings, time pieces, and machines or mechanics. The importance of principles in architecture fit t...
Chapter
Excellence in being a system architect depends as little on the ability of using systems engineering software tools as the excellence in being a journalist depends on skills in operating word processor software. This chapter provides some tools for the system architect to be established before taking a software tool into use: mind set, leadership,...
Chapter
Requirements engineers capture requirements in direct dialogue with people or entities they call “stakeholders” or “stakeholder representatives” in a requirements engineering context. This chapter covers stakeholders that are often encountered for typical systems‐of‐interest. It discusses the role of requirements engineering as an architecture stak...
Chapter
It can be advantageous to accompany the systems architecting activity with a model. Too extensive modeling is what we also call over‐modeling. Over‐modeling usually leads to an explosion of cost, which cannot be justified by the much slower evolution of benefits. It is therefore extremely important to make the cost‐benefit analysis before starting...
Chapter
This chapter presents an example: the scalable observation and rescue system. The example shall be based on one single system with one single purpose, but extensible to be explored in scenarios involving the interaction of multiple systems for a purpose different from the one of the original single system. Single‐purpose system is based on the very...
Chapter
Digital engineering will be the enabling technology to enable digital threads and digital twins, which in turn pave the way for the use of artificial intelligence technologies. Model‐based engineering (MBE) is a kind of digital engineering combining product lifecycle management and model‐based systems engineering approaches. The abstract syntax def...
Chapter
In this book, the fictitious “Scalable Observation and Rescue System” allows for studying today’s systems architecting challenges with artificial intelligence inside the system‐of‐interest. Artificial intelligence however is expected to break out of the boundaries of such systems under development, also conquering the systems used for system develo...
Chapter
The systems architecting processes are the core processes for the system architect. The actual process for producing the system architecture description consists of doing the architecting and validating or reviewing and approving its output. The system architect has to ensure that the system architecture considers each life cycle stage of the syste...
Chapter
Architecture descriptions provide substantial benefit for maintenance and evolution of systems. Architecture descriptions shall document how selected solutions satisfy requirements or address concerns. Architecture starts to exist as initial solution hypothesis while analyzing and validating business and stakeholder requirements. System architects...
Chapter
The functional architecture is often mentioned in publications about systems engineering or in the context of real system projects. This chapter describes Functional Architectures for Systems (FAS) and begins with the terminology and motivation of functional architectures. The FAS method is a practice‐proven method based on common model‐based syste...
Chapter
Patterns and principles are documented best practices and proven experiences of system architects. Architectural principles describe guidelines that, in general experience, lead to good architecture when followed, while patterns describe basic working solutions for given problems. The functional architecture for systems method can be used to create...
Chapter
The system architect and other architecture stakeholders like to see appropriate architecture views that describe the architecture of the system‐of‐interest. The architecture viewpoints take the role of defining the expectations toward the model, by defining the questions the model should answer via the architecture views. A very simple and abstrac...
Chapter
In this chapter, the authors give a brief description of requirements engineering and use case analysis. They define the most important requirements and use case terms. The authors present the requirements and use case analysis methodology steps of the “Systems Modeling Toolbox” (SYSMOD). The SYSMOD methodology defines common methods and is not spe...
Chapter
Architecture assessment methods assess the quality of architecture. The Architecture Trade‐off Analysis Method (ATAM) is mentioned in the standard as an example for an architecture evaluation framework. ATAM leads to an explicit consideration of the system objectives, related quality attributes, architectural approaches, and decisions. ATAM mainly...
Chapter
A prosperous enterprise brings people together and creates an environment of good cooperation and appreciative togetherness. There are numerous publications and books about soft skills, discussing their importance and suggesting ways how to improve those skills. The internal communication within an organization refers mainly to the communications b...
Chapter
Systems architecting will ensure that the interactions between components are controlled in a proper way and that components are designed to fit each other. When talking of better products, then “better” can have two different meanings: more satisfying or even more enjoyable for customers, and more profitable for the organization. Systems architect...
Book
Full-text available
Mitglieder der Gesellschaft für Systems Engineering e. V. haben in diesem Buch – in leicht verständlicher Form und mit vielen Abbildungen und Quellenangaben versehen – zentrale Grundlagen zum Systems Engineering beschrieben. Ziel des Systems Engineerings ist die erfolgreiche Gestaltung und Realisierung von komplexen Produkten sowie die Organisation...
Chapter
I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date.
Chapter
As I have already explained in this book's Introduction (see Chapter 1), lots of C++ code out there is not clean. In many projects, software entropy has gotten the upper hand. Even if you are dealing with an ongoing development project, for example, with a piece of software under maintenance, large parts of the code base are often very old. The cod...
Chapter
In Chapters 3 and 4 we discussed the basic principles and practices that build a solid foundation for clean and modern C++ code. With these principles and rules in mind, a developer can raise the internal C++ code quality of a software project and, thus often, its external quality, significantly. The code becomes more understandable, more maintaina...
Chapter
The historical roots of object orientation (OO) can be found in the late 1950s. The Norwegian computer scientists Kristen Nygaard and Ole-Johan Dahl carried out simulation calculations for the development and construction of Norway's first nuclear reactor at the military research institute Norwegian Defense Research Establishment (NDRE). While deve...
Chapter
Good craftspeople can draw on a wealth of experience and knowledge. Once they've found a good solution for a certain problem, they take this solution into their repertoire to apply it in the future to a similar problem. Ideally, they transform their solution into something that is known as a canonical form and document it, both for themselves and f...
Chapter
In the section “Unit Tests” (see Chapter 2) we have learned that a good suite of small and fast tests can ensure that our code works correctly. So far, so good. But what is so special about Test-Driven Development (TDD) and why does it justify an additional chapter in this book?
Chapter
For several years, a programming paradigm experienced a renaissance, which is often viewed as a kind of counterdraft to object orientation. The talk is about Functional Programming.
Chapter
Software testing is becoming increasingly important. While software testing has long been a rather neglected discipline that was postponed to the end of the development process, testing is an important and essential cornerstone of modern software development nowadays. The trend towards digitization, in particular, through which software increasingl...
Book
Write maintainable, extensible, and durable software with modern C++. This book is a must for every developer, software architect, or team leader who is interested in good C++ code, and thus also wants to save development costs. If you want to teach yourself about writing clean C++, Clean C++ is exactly what you need. It is written to help C++ deve...
Chapter
Stakeholders in the context of system architecture are the main focus of this chapter. Each section in the chapter is dedicated to one typical architecture stakeholder inside a typical organization and the organizational interface to the system architect. The chapter describes the collaboration between the system architects and the selected stakeho...
Chapter
The authors are convinced that research around product line engineering will provide even more efficient product line approaches than we know today. In this chapter, they draw out a scenario that should start a debate about the advantages and disadvantages of product line engineering. The authors suggest the reader to challenge the current systems...
Chapter
The discipline model-based systems engineering (MBSE) has become very famous in systems engineering in the last years. This chapter presents the three features of a model as defined by Stachowiak in his book about general model theory. The authors second the features of Stachowiak and add some more to give a definition of how they understand and us...
Chapter
This chapter focuses on the definition of system architecture. The term ?architecture? origins from ?architect?, the role that realizes the architecture of something. The process of architecting leads from requirements to one or more designs that satisfy the requirements. The design of a system comprises system elements. The term ?architecture? is...
Chapter
This chapter describes the various perspectives that can be used as a means of grouping or categorizing system architecture views. The functional perspective of system architecture allows for describing the complete system conceptually, even if some implementation details are not yet known. System architecture may consist of the base architecture l...
Chapter
Architecture assessment methods assess the quality of an architecture. The chapter presents an architecture assessment method, the architecture tradeoff analysis method (ATAM), which is based on a structured communication process to incorporate all relevant stakeholders and viewpoints. It focuses on the main important aspects, incorporates stakehol...
Chapter
Architecture frameworks are about the description of architectures. In practice, architecture frameworks are very well known in the world of enterprise architecture (EA) development, and system of systems engineering (SoSE). This chapter first discusses the term EA, and afterward, takes a look at the noteworthy characteristics of an SoS. EA develop...
Chapter
Cross-cutting concerns are those concerns that are relevant across different levels, layers, and perspectives of the architecture. This chapter discusses some of the major ones. Finally, trade studies and budgets are discussed as a means of handling cross-cutting concerns. Often nonfunctional requirements are cross-cutting concerns, because many pa...
Chapter
This chapter briefly describes the requirements and use case analysis. The authors follow the “Systems Modeling Toolbox” (SYSMOD) for SysML. The methodology uses common methods of requirements and use case analysis. The core tasks include: Identify and define requirements; Specify the system context; Identify use cases; Describe use case flows; and...
Chapter
This chapter describes Functional Architectures for Systems (FAS), beginning with the authors' view on the terminology and motivation of functional architectures. The FAS method is a practice-proven method based on common MBSE practices. Model-based functional architecture descriptions model systems independent of their target technology, by means...
Chapter
The systems architecting process is the core process for the system architect. This chapter illustrates how the inputs and outputs of the process as well as the contributing roles could be defined. The system architect has to ensure that the system architecture considers each life cycle stage of the system and its evolution. After making a very gen...
Chapter
This chapter talks about a Virtual Museum Tour system (VMT). In this system one user can log in for controlling the robot via a web application on a computer or a hand-held device, like a smart phone. The system-of-interest is composed of the robot itself together with the infrastructure and remote control software that is needed to operate it. The...
Chapter
When agile approaches are implemented partly and differently in different entities of the organization, the system architect will be affected by the differences, being a multidisciplinary agent who has to collaborate with multiple entities inside the organization. This chapter aims at showing the real-world situation of system architects today, arc...
Chapter
The only purpose of an architecture description (AD) is to explain the architecture of a system to its stakeholders. An AD shall document how a certain design satisfies stakeholder requirements or even stakeholder needs. The AD supports an architect in communication with stakeholders about the system of interest. It documents both, rationales and a...
Chapter
Introducing system architecture in an organization is an organizational change process. A continuous organizational roll-out of the methods and the mindset of systems architecting is required from those who are convinced that systems architecting is one of the enablers for success. This chapter first discusses the organizational structure around sy...
Chapter
Many systems exist in different configurations: a product line, a customized product, or different designs for trade studies. Typically, a single variant of a system affects only a few parts of the system. This chapter first presents some definitions and then describes a concept for variant modeling with SysML. SysML is useful to model variants and...
Chapter
This chapter provides a broad overview about some essential parts of soft skills, and enables the reader to learn about some models from communication psychology and personality typology that are helpful to explain several interpersonal dealings and processes. It highlights the importance of communication in systems engineering projects, and discus...
Chapter
Patterns are good tools to make the implicit knowledge of the system architect explicit. Patterns and principles are documented best practices and proven experiences of system architects. The pattern is described as part of the SYSMOD methodology. It describes the relationship between requirements and architectures on different abstraction levels....
Chapter
Systems architecting is an approach that will help an organization think, develop, produce, and maintain better products. It produces well-founded trade studies, because it is right in between the requirements analysis work and the solution space that is framed by the development of different system elements. Systems architecting can enable a top-d...
Chapter
To avoid the need to consider different kinds of organization, the notion of a role is being used. A role usually goes along with a role description, defining the objective of the role as well as tasks, responsibilities, and competences that are related to the work to be done. This chapter focuses on roles without looking at the organization. It de...

Network

Cited By