Cobbler’s children do not wear shoes. Software engineers build sophisticated software but we often cannot find the needed information and knowledge for ourselves. Issues are the amount of development information that can be captured, organizing that information to make them useable for other developers as well as human decision-making issues. Current architectural knowledge management systems cannot handle these issues properly. In this paper, we outline a research agenda for intelligent tools to support the knowledge management and decision making of architects. The research agenda consists of a vision and research challenges on the way to realize this vision. We call our vision on-demand architectural knowledge systems (ODAKS). Based on literature review, analysis, and synthesis of past research works, we derive our vision of ODAKS as decision-making companions to architects. ODAKS organize and provide relevant information and knowledge to the architect through an assistive conversation. ODAKS use probing to understand the architects’ goals and their questions, they suggest relevant knowledge and present reflective hints to mitigate human decision-making issues, such as cognitive bias, cognitive limitations, as well as design process aspects, such as problem-solution co-evolution and the balance between intuitive and rational decision-making. We present the main features of ODAKS, investigate current potential technologies for the implementation of ODAKS and discuss the main research challenges.

The use of architecture and design patterns have impacts on the quality attributes of a system, and the application of patterns depend on design contexts. There are complex interdependent relationships between them. In this study, we explore how developers use architecture and design patterns with respect to quality attributes concerns and design contexts. We extracted pattern related posts from Stack Overflow and analyzed the architecture discussions. Our study reveals what contexts and quality attributes developers consider when using architecture patterns, and we have identified new and previously unknown relationships between these design elements. These findings can enhance developers' knowledge when they design with architecture patterns, quality attributes, and design contexts.

Despite past efforts, we have little understanding and limited research efforts on how architects make decisions in the real-world settings. It seems that software architecture researchers make implicit assumption that decision making by software architects can be a rational and prescribed process. Such an assumption is disputed in other fields such as economics and decision research. This paper studies the current state of software architecture decision making research in terms of human behaviors and practice. We carried out a literature review on software architecture decision making. We classified papers into decision making behavior and decision making practice and identified the research relationships between them. We found that decision making is a mental activity. Research into the behavioral aspects of software architecture decision making for incorporation into architectural design practices is required. We suggest three research topics on human aspects to improve software architecture practices.

The importance of architectural knowledge (AK) management for software development has been highlighted over the past ten years, where a significant amount of research has been done. Since the first systems using design rationale in the seventies and eighties to the more modern approaches using AK for designing software architectures, a variety of models, approaches, and research tools have leveraged the interests of researchers and practitioners in AK management (AKM). Capturing, sharing, and using AK has many benefits for software designers and maintainers, but the cost to capture this relevant knowledge hampers a widespread use by software companies. However, as the improvements made over the last decade didn't boost a wider adoption of AKM approaches, there is a need to identify the successes and shortcomings of current AK approaches and know what industry needs from AK. Therefore, as researchers and promoters of many of the AK research tools in the early stages where AK became relevant for the software architecture community, and based on our experience and observations, we provide in this research an informal retrospective analysis of what has been done and the challenges and trends for a future research agenda to promote AK use in modern software development practices.

We theorize a two-mind model of design thinking. Mind 1 is about logical design reasoning, and Mind 2 is about the reflection on our reasoning and judgments. The problem solving ability of Mind 1 has often been emphasized in software engineering. The reflective Mind 2, however, has not received much attention. In this study, we want to find out if Mind 2, or reflection, can improve design discourse, a prerequisite of design quality. We conducted multiple case studies with 12 student groups, divided into test groups and control groups. We provided external reflections to the test groups. No reflections were given to the control groups. We analyzed the quality of the design discourse in both groups. We found that reflection (Mind 2) improves the quality of design discourse (Mind 1) under certain preconditions. The results highlight the significance of reflection as a mean to improve the quality of design discourse. We conclude that software designers need both Mind 1 and Mind 2 to obtain a higher quality design discourse, as a foundation for a good design. Copyright © 2016 John Wiley & Sons, Ltd.

Context: Software architecture documentation is used to communicate architectural knowledge. It is often difficult for document users to find all the architectural knowledge they need to do their tasks, and this results in wasted time and mistakes during development. Objective: In this paper we investigate how ontology-based documentation may support users in finding the architectural knowledge they need. Method: We executed a controlled experiment to test for differences in knowledge retrieval efficiency and effectiveness between two groups of master students that used two ontologies built from different understandings of the architectural knowledge needs of document users. Results: Use of the ontology built based on a better understanding of architectural knowledge needs was significantly more efficient or effective for retrieving part of the knowledge needed by document users. We analysed participants' search actions and identified which organisation of knowledge in the ontologies resulted in efficient and effective knowledge retrieval. Conclusion: We found that an improved understanding of knowledge needs allows for the construction of an ontology from which document users retrieve knowledge more efficiently and effectively. In some cases we found that the ontology support for knowledge needs had to be traded off against ontology design criteria.

Understanding the causes of architecture changes allows us to devise means to prevent architecture knowledge vaporization and architecture degeneration.But the causes are not always known, especially in open source software (OSS) development.This makes it very hard to understand the underlying reasons for the architecture changes and design appropriate modifications.Architecture information is communicated in development mailing lists of OSS projects.To explore the possibility of identifying and understanding the causes of architecture changes, we conducted an empirical study to analyze architecture information (i.e., architectural threads) communicated in the development mailing lists of two popular OSS projects: Hibernate and ArgoUML, verified architecture changes with source code, and identified the causes of architecture changes from the communicated architecture information.The main findings of this study are: (1) architecture information communicated in OSS mailing lists does lead to architecture changes in code; (2) the major cause for architecture changes in both Hibernate and ArgoUML is preventative changes.(3) more than 45% of architecture changes in both projects happened before the first stable version was released, which indicates that the architectures of the investigated OSS projects are relatively stable after the first stable release.

Quality attributes are essential in software architecture and they are determined by identifying the concerns of the stakeholders of a system. The concerns of constructing mobile applications (apps) are quite specific due to the characteristics of mobile devices. These concerns have not been adequately addressed in industry standards and practices. In this paper, we present a mobile app development conceptual model comprising six key concepts that impact quality. Using two case studies, we show that these interrelated concepts influence the architectural decisions of mobile apps and their tradeoffs need to be well considered. As such, we suggest that these concepts should be first class entities when designing mobile app architecture to ensure that the quality attributes are satisfied.

The causes of architecture changes can tell about why architecture changes, and this knowledge can be captured to prevent architecture knowledge vaporization and architecture degeneration. But the causes are not always known, especially in open source software (OSS) development. This makes it very hard to understand the underlying reasons for the architecture changes and design appropriate modifications. Architecture information is communicated in development mailing lists of OSS projects. To explore the possibility of identifying and understanding the causes of architecture changes, we conducted an empirical study to analyze architecture information (i.e. architectural threads) communicated in the development mailing lists of two popular OSS projects: Hibernate and ArgoUML, verified architecture changes with source code, and identified the causes of architecture changes from the communicated architecture information. The main findings of this study are: (1) architecture information communicated in OSS mailing lists does lead to architecture changes in code; (2) the major cause for architecture changes in both Hibernate and ArgoUML is preventative changes, and the causes of architecture changes are further classified to functional requirement, external quality requirement, and internal quality requirement using the coding techniques of grounded theory; (3) more than 45% of architecture changes in both projects happened before the first stable version was released.

Formal methods offer an effective means to assert the correctness of software systems through mathematical reasoning. However, the need to formulate system properties in a purely mathematical fashion can create pragmatic barriers to the application of these techniques. For this reason, Dwyer et al. invented property specification patterns which is a system of recurring solutions to deal with the temporal intricacies that would make the construction of reactive systems very hard otherwise. Today, property specification patterns provide general rules that help practitioners to qualify order and occurrence, to quantify time bounds, and to express probabilities of events. Nevertheless, a comprehensive framework combining qualitative, real-time, and probabilistic property specification patterns has remained elusive. The benefits of such a framework are twofold. First, it would remove the distinction between qualitative and quantitative aspects of events; and second, it would provide a structure to systematically discover new property specification patterns. In this paper, we report on such a framework and present a unified catalogue that combines all known plus 40 newly identified or extended patterns. We also offer a natural language front-end to map patterns to a temporal logic of choice. To demonstrate the virtue of this new framework, we applied it to a variety of industrial requirements, and use PSPWizard, a tool specifically developed to work with our unified pattern catalogue, to automatically render concrete instances of property specification patterns to formulae of an underlying temporal logic of choice.

Software documents are used to capture and communicate knowledge in software projects. It is important that this knowledge can be retrieved efficiently and effectively, to prevent wasted time and errors that negatively affect the quality of software. In this paper we investigate how software professionals search for knowledge in documentation. We studied the search behaviour of professionals in industry. Prior knowledge helps professionals to search software documents efficiently and effectively. However, it can also misguide professionals to an incomplete search.

Software architecture (SA) documentation provides a blueprint of a software-intensive system for the communication between stakeholders about the high-level design of the system. In open source software (OSS) development, a lack of SA documentation may hinder the use and further development of OSS, but how much "architecture" documentation is enough and appropriate is largely dependent on the contextual factors of development. In order to understand the state of the practice of SA documentation in OSS projects, we conducted a documentation-based survey to explore how SA is documented in OSS projects. Out of 2,000 OSS projects from four major OSS sources, we found that 108 projects have some SA documentation, which shows that the SA documentation is scarce in OSS development. We analyzed these 108 projects to understand what SA information has been documented and how they have been described. We have found that frequently-documented architectural information is model, system, and mission, natural language is the most frequently-used architectural language for specifying architectural information in OSS SA documents. The results also show that the likelihood that an OSS project will document SA is increased when more developers are involved in the project, and industry and research OSS projects are more likely to create SA documents than freelance projects.

Software architecture design is challenging, especially for junior software designers. Lacking practice and experience, junior designers need process support in order to make rational architecture decisions. In this paper, we present the results of a comparative multiple-case study conducted to find out if decision viewpoints from van Heesch et al., 2012, van Heesch et al., in press can provide such a support. The case study was conducted with four teams of software engineering students working in industrial software projects. Two of the four teams were instructed to document their decisions using decision viewpoints; the other two teams were not instructed to do so. We observed the students for a period of seven weeks by conducting weekly focus groups and by analyzing their work artifacts and minutes. Our findings suggest that junior designers who use decision viewpoints are more systematic in exploring and evaluating solution options. However, the decision viewpoints did not help them in managing requirements and complexity.

Many times we are faced with the proliferation of definitions, concepts, languages, and tools in certain (research) topics. But often there is a gap between what is provided by existing technologies and what is needed by their users. The strengths, limitations, and needs of the available technologies can be dubious. The same applies to software architectures, and specifically to languages designed to represent architectural models. Tens of different architectural languages have been introduced by the research and industrial communities in the last two decades. However, it is unclear if they fulfill the user's perceived needs in architectural description. As a way to plan for next generation languages for architectural description, this study analyzes practitioners' perceived strengths, limitations, and needs associated with existing languages for software architecture modeling in industry. We run a survey by interviewing 48 practitioners from 40 different IT companies in 15 countries. Each participant is asked to fill in a questionnaire of 51 questions. By analyzing the data collected through this study, we have concluded that 1) while practitioners are generally satisfied with the design capabilities provided by the languages they use, they are dissatisfied with the architectural language analysis features and their abilities to define extra-functional properties; 2) architectural languages used in practice mostly originate from industrial development instead of from academic research; 3) more formality and better usability are required of an architectural language.

Software Development Governance (SDG) is an emerging field of research, under the umbrella of information technology governance. SDG challenges increase when software development activities are distributed across multiple locations. Coordination of knowledge management processes requires specific attention in multi-site development. This paper outlines a multi-site software governance structure, based on three aspects: the business strategy that binds the relationship of the remote offices, the structure and composition of the remote teams and the way tasks are allocated across sites. Knowledge management processes (including knowledge creation, knowledge transfer and communication) are identified and the influence of different governance structures on these processes is discussed. We do so through a case study at Océ, a multi-national company in printing systems.

The study of Software Configuration Management (SCM) has so far focused on the use of tools, SCM models, strategies, patterns or best practices. There are few industry studies on how an organization actually practices file branching and merging. In this empirical study at Océ, we have observed that some developers create branches freely without regards to their consequences on merging. This contradicts recommended best practices and SCM processes. So we investigate if there are hidden costs in propagating or merging changes at Océ. The investigation led us to understand that branching and merging can be done freely under certain circumstances to provide development concurrency. However, some files cannot be branched freely and it may be better to use recommended practices to edit them. Some roles were also noted to be more affected by branching of files.

In an agile environment, where the architect's role is not crisply defined, the architect may have to deal with a number of issues that arise during development and are considered architecture-related. Such issues range from feature requests and enhancements through to defects found during testing. Architect specifications that turn into issues boomerang the architect to resolve them. In a case study we looked at issues entered into the issue tracking system that were assigned to architects to understand the root causes for their inception. We found that many of the avoidable issues can be circumvented by better communication between the architect and other stakeholders, and by small adaptations in the development process.

The basic format in which software requirements and architecture designs are documented is essentially file-based, and it has persisted for decades. Current indexing methods used in file-based documentation are not conducive to retrieving software knowledge. We propose to index software documents with a suitable lightweight ontology to improve the retrieval and traceability of software knowledge. Initial results from a prototype implementation have shown promising prospects.

Probabilistic properties are considered as the most important requirements for a variety of software systems, since they are used to formulate extra-functional requirements such as reliability, availability, safety, security and performance requirements. Currently, several probabilistic logics have been proposed to specify such important properties. However, due to the inherent complexity of the underlying temporal logics, these probabilistic logics are rather complex and software developers have problems using them to correctly specify the intended properties. To overcome this problem, we define a formal and graphical property specification language called probabilistic timed property sequence charts (PTPSC) which is a probabilistic extension of property sequence charts (PSC). We illustrate the use of PTPSC in the context of a vehicle-to-vehicle communication device for avoiding traffic accidents.

Database-centric information systems are critical to the operations of large organisations. In particular, they often process a large amount of data with stringent performance requirements. Currently, however, there is a lack of systematic approaches to evaluating and predicting their performance when they are subject to an exorbitant growth of workload. In this paper, we introduce such a systematic approach that combines benchmarking, production system monitoring, and performance modelling (BMM) to address this issue. The approach helps the performance analyst to understand the system's operating environment and quantify its performance characteristics under varying load conditions via monitoring and benchmarking. Based on such realistic measurements, modelling techniques are used to predict the system performance. Our experience of applying BMM to a real-world system demonstrates the capability of BMM in predicting the performance of existing and enhanced software architectures in planning for its capacity growth.

Many claims have been made about the problems caused by not documenting design rationale. The general perception is that designers and architects usually do not fully understand the critical role of systematic use and capture of design rationale. However, there is to date little empirical evidence available on what design rationale mean to practitioners, how valuable they consider them, and how they use and document design rationale during the design process. This paper reports an empirical study that surveyed practitioners to probe their perception of the value of design rationale and how they use and document background knowledge related to their design decisions. Based on eighty-one valid responses, this study has discovered that practitioners recognize the importance of documenting design rationale and frequently use them to reason about their design choices. However, they have indicated barriers to the use and documentation of design rationale. Based on the findings, we conclude that much research is needed to develop methodology and tool support for design rationale capture and usage. Furthermore, we put forward some research questions that would benefit from further investigation into design rationale in order to support practice in industry.

Research into design rationale in the past has focused on the representation of reasons and has omitted the connections between design rationales and design artefacts. Without such connections, designers and architects cannot easily assess how changing requirements or designs may affect the system. In this paper, we introduce a model called Architecture Rationale and Element Linkage (AREL) to represent the causal relationship between architecture elements and decisions. We further model AREL as a Bayesian Belief Network (BBN) to capture the probabilistic relationships between architecture elements and decisions in an architecture design model. Such probabilistic modelling enables architects to quantitatively predict and diagnose impact of change when part of the requirements or designs are changing. Using a partial design of a cheque image processing system, we illustrate how AREL is used to represent the decision model and how BBN is used to predict and diagnose change in the architecture design. We use a UML tool to capture the AREL model and a BBN tool to compute the probabilities of change impact.

Architecture frameworks are methods used in architecture modeling. They provide a structured and systematic approach to designing systems. To date there has been little analysis on their roles in system and software engineering and if they are satisfactory. This study provides a model of understanding through analyzing the goals, inputs and outcomes of six architecture frameworks. It characterizes two classes of architecture frameworks and identifies some of their deficiencies. To overcome these deficiencies, we propose to use costs, benefits and risks for architecture analysis. We also propose a method to delineate architecture activities from detailed design activities.