Automated Decision Support for Recurring Design Decisions Considering Non-Functional Requirements.
Axel Busch · Software Engineering & Management · 2015
Planning high quality software means more than regarding functionality. Considering non-functional requirements, implementing them and understanding their effects on the software architecture remain often an open question. Therefore, in this paper, we present an approach that provides decision support in a software development process for recurring design decisions in the field of non-functional requirements. The approach defines a design decision model that allows to encapsulate the reasoning of design decisions, make them reusable and use them to enable automated feedback in a decision making process. At the end, this approach increases the developer’s productivity by reusing design decisions and therefore allows to implement requirements with lower overhead and to improve the architecture quality by a tool assisted decision support process. 1 Motivation and Introduction Despite of many improvements in software engineering processes, in recent years even high budget software projects delayed or even failed. The increasing size and complexity of these software projects requires an explicit consideration of quality attributes. Otherwise, the software will not fulfill the stakeholders expectations in terms of non-functional attributes like security, usability or reliability. Considering quality attributes in a software architecture design is one major task when making architecture design desicions. Due to missing quantification methodologies for many considered quality attributes, the influence of a decision on other quality attributes remains unclear. Therefore, it is often difficult to estimate in advance which attributes an architectural decision would affect. This means that if a developer has made a decision that improves one specific attribute, the influence on other quality attributes, e.g. performance, remains an open question. Our approach addresses these issues when considering recurring design decisions, following the concept of the component-based software engineering (CBSE) paradigm. Recurring design decisions are decisions that are applicable in many projects and organizations. Examples for recurring design decisions may be introducing an Intrusion Detection System or selecting a messaging middleware. In our approach, we encapsulate the reasoning of such a recurring design decision in one entity to make it reusable and model the effects on the quality attributes on a software architecture to allow automated requirements trade-off decisions. A design decision comprises a generic part that is architecture independent (e.g. component interaction) and a part that is specific for a particular architecture (e.g. concrete components). Such a design decision could be implemented in different ways by different components to be used and different deployment configurations of these components. Each configuration may have its own quality attributes, e.g. different levels of security or different performance properties. These characteristics of design decisions could be encapsulated to one entity, a design decision model entity. This approach provides a design decision repository that contains these entities representing solutions for recurring design decisions, in order to fulfill certain quality requirements. An automated decision support system uses these design decision model entities to support developers at trade-off decisions to select the best suitable solution in an existing architecture according to the project’s non-functional requirements.