Jens Knodel

Mitigating the Risk of software change in practice: Retrospective on more than 50 architecture evaluations in industry (Keynote paper)

Architecture evaluation has become a mature instrument to mitigate the risk of software change. It enables decision-making about software systems being changed or being prepared for change. While scientific literature on architecture evaluation approaches is available, publications on practical experiences are rather limited. In this paper, we share our experiences - after having performed more than 50 architecture evaluations for industrial customers in the last decade. We compiled facts and consolidate our findings about the risk of software change and architecture evaluations as a means to mitigate change. We highlight the role of reverse engineering in these projects. In addition, we share our lessons learned and provide data on common beliefs and provide examples for frequently observed misconceptions on the power of reverse engineering. This industrial and practical perspective allows practitioners to benefit from our experience in their daily architecture work and the scientific community to focus their research work on the generalizability of our findings.

Control as a service (CaaS): cloud-based software architecture for automotive control applications

The Internet of Things (IoT) is the interconnection of embedded devices and offers the possibility of exploiting cloud-based services to improve control functions. But how much cloud control is possible when facing real-time challenges in a safety-critical environment? This paper provides first insights and data into cloud-based control by means of a feasibility study in the automotive domain. We present the Control as a Service (CaaS) concept, which investigates cloud-based control scheme for a model car with WLAN / CAN gateway. CaaS delivers successfully an architectural design and a proof-of-concept implementation for a simple cloud-based throttle limitation scenario, in which the throttle values requested by driver (remote control user) is dynamically regulated by a controller implemented as a virtual ECU (Electronic Control Unit) in the cloud. We found that the correct handling of time-varying network delay is one of the most relevant challenges. Therefore we started a simulation study in parallel to design controllers that are capable of coping with network imperfections. Preliminary simulation results indicate the potential of model predictive control.

ArQuE: Architecture-Centric Quality Engineering

The ArQuE project has developed an integrated and comprehensive method that enables goal-oriented,architecture-centric development and strategic quality engineering. The consolidated expertise from applying the ArQuE approach at different industry partners shows the applicability and scalability in the embedded systems domain. The approach leads to reduced maintenance effort and simplified evolution of the respective software systems. The experiences made and knowledge gained in the instantiations of the approach for the industrial systems document the overall project success and give evidence that the overall return on investment of the Argue approach is positive.

How to Perform the Documentation Quality Check (DQC)

he main goal of the Documentation Quality Check (DQC) is to check how adequate the architecture documentation is for its audience and purposes. The evaluation checks both the content and the representation of the architecture documentation. Thinking from the perspective of the audience and considering the purposes of the documentation helps to rate the adequacy of the documentation. In addition, principles of good documentation, such as structure, uniformity, or traceability, can be checked. These principles are determined by the mental capabilities of the readers and can be used across domains and system types.

What Is the Background of Architecture

We will sketch the big picture of architecting in this chapter—it is far more than just a phase for modeling boxes and lines between requirements and implementation. Today’s complex software systems require continuous architecting over the whole lifecycle of the software system. We will place particular emphasis on industrial practice, where architecting can never be done in the ideal way but where one has to continuously make deliberate tradeoffs.

What Are the Key Takeaways of Architecture Evaluation

Thorough and continuous architecting is the key to overall success in software engineering, and architecture evaluation is one crucial part of architecting.

How to Perform an Architecture Evaluation

There are typical indicators that an architecture evaluation would be beneficial. Architecture evaluation is typically conducted as a project, answering specifically formulated evaluation goals. We will show the big picture of how an evaluation project can be set up and structured, including which stakeholders to involve and how to manage their expectations. We will offer support for estimating the effort for an architecture evaluation and the actual project management. Finally, we will share experiences on the interpretation of evaluation results and describe how to structure a concluding management presentation that accurately conveys the evaluation results and presents recommendations.

How to Perform the Solution Adequacy Check (SAC)

The main goal of the Solution Adequacy Check (SAC) is to check whether the architecture solutions at hand are adequate for the architecture drivers identified and whether there is enough confidence in the adequacy. We present a pragmatic workshop-based approach that is based on ideas of ATAM. We provide guidance for the documentation of evaluation results, such as the discussed architecture decisions and how they impact the adequacy of the overall solution. We also provide concrete templates and examples and show how evaluation results and specific findings can be rated and represented.

How to Perform the Code Quality Check (CQC)

The main goal of the Code Quality Check (CQC) is to gather data about the source code base. As such, the CQC is not a direct part of the architecture evaluation.

How to Perform the Architecture Compliance Check (ACC)

The main goal of the Architecture Compliance Check (ACC) is to check whether the implementation is consistent with the architecture as intended: only then do the architectural solutions provide any value. Nevertheless, implementation often drifts away from the intended architecture and in particular from the one that was documented. We will show typical architectural solutions that are well suited to being checked for compliance. Compliance checking has to deal with large amounts of code and thus benefits from automation with tools. Not all violations of architecture concepts have the same weight: we provide guidance for the interpretation of compliance checking results.