An Evolution Process For Service-Oriented Systems

Evolution of service-oriented systems is quite a new research area, which becomesmore and more important as engineering challenges move from enablingservice-orientation onto the maintenance and evolution of already developedservice-oriented systems. However, the development of suitable evolution processesand methodologies is still an open research problem. The evolution processpresented in this paper has been designed to address the evolution of serviceorientedsystems, which are technically built out of a set of service compositions.The presented process comprises phases and tasks compliant with ISO 20000.The underlying model of service-oriented system consisting of business processesand corresponding service composition models has also been presented. A traceabilitymodel and tools supporting change impact analysis have also beenprovisioned for. Preliminary industrial validation indicates that the evolutionprocess should be easy to adapt by the industry

The Influence of Cognitive Biases on Architectural Technical Debt

Cognitive biases exert a significant influence on human thinking and decision-making. In order to identify how they influence the occurrence of architectural technical debt, a series of semi-structured interviews with software architects was performed. The results show which classes of architectural technical debt originate from cognitive biases, and reveal the antecedents of technical debt items (classes) through biases. This way, we analysed how and when cognitive biases lead to the creation of technical debt. We also identified a set of debiasing techniques that can be used in order to prevent the negative influence of cognitive biases. The observations of the role of organisational culture in the avoidance of inadvertent technical debt throw a new light on that issue.Comment: Presented at 2021 IEEE 18th International Conference on Software Architecture (ICSA) 202

Modelling architectural decisions under changing requirements

Abstract-One of the approaches for documenting software architecture is to treat it as a set of architectural design decisions. Such decisions are always made in the context of requirements that must be fulfilled and in the context of decisions that were made before. Currently, models for representing architectural decisions are mainly concentrated on showing the decision making process of the initial architectural design. However, decisions that have been made in such a process may need to be changed during further evolution and maintenance of the software architecture, typically in response to the new or changed requirements. A graphical modelling notation for documenting architectural decisions (Maps of Architectural Decisions) has been developed by our team. In this paper, it is presented how this notation could be used to model architectural decisions under changing requirements. It is proposed how one decision change could be effectively propagated through the rest of the architectural decision model and how a rigorous and toolsupported process of updating such models could be organized

From Principles to Details: Integrated Framework for Architecture Modelling of Large Scale Software Systems

There exist numerous models of software architecture (box models, ADL’s, UML, architectural decisions), architecture modelling frameworks (views, enterprise architecture frameworks) and even standards recommending practice for the architectural description. We show in this paper, that there is still a gap between these rather abstract frameworks/standards and existing architecture models. Frameworks and standards define what should be modelled rather than which models should be used and how these models are related to each other. We intend to prove that a less abstract modelling framework is needed for the effective modelling of large scale software intensive systems. It should provide a more precise guidance kinds of models to be employed and how they should relate to each other. The paper defines principles that can serve as base for an integrated model. Finally, structure of such a model has been proposed. It comprises three layers: the upper one – architectural policy – reflects corporate policy and strategies in architectural terms, the middle one –system organisation pattern – represents the core structural concepts and their rationale at a given level of scope, the lower one contains detailed architecture models. Architectural decisions play an important role here: they model the core architectural concepts explaining detailed models as well as organise the entire integrated model and the relations between its submodels