Abstract-Twelve years ago a group of practitioners and researchers came together to try to solve problems relating specifically to Global Software Engineering (GSE) practice. This paper aims to assess whether the many hundreds of GSE research papers written over this period have had an impact on practice. We conducted semi-structured interviews with senior managers and project managers from ten companies, four of which are large multinationals (three in Fortune 100); four are medium sized enterprises, and two are small startups. GSE research is perceived as useful by industry with all participants stating that studying the subject would improve GSE performance; but all were unanimous in saying they did not read articles on GSE. Practitioners go to books, blogs, colleagues, forums, experience reports of 1-2 pages in length, or depend on their own experience to solve problems in GSE. Controversially, many didn't see GSE as separate from general project management. Practitioners don't want frameworks; they want patterns of context specific help. While dissemination techniques need to be improved, that is not sufficient. Experience-based advice is just as important.

Architecture Consistency (AC) aims to align implemented systems with their intended architectures. Several AC approaches and tools have been proposed and empirically evaluated, suggesting favourable results. In this paper, we empirically examine the state of practice with respect to Architecture Consistency, through interviews with nineteen experienced software engineers. Our goal is to identify 1) any practises that the companies these architects work for, currently undertake to achieve AC; 2) any barriers to undertaking explicit AC approaches in these companies; 3) software development situations where practitioners perceive AC approaches would be useful, and 4) AC tool needs, as perceived by practitioners. We also assess current commercial AC tool offerings in terms of these perceived needs. The study reveals that many practitioners apply informal AC approaches as there are barriers for adopting more formal and Empir Software Eng (2018) 23:224-258 DOI 10.1007 The original version of this article was revised due to a retrospective Open Access order. Karlstad University, Karlstad, Sweden explicit approaches. These barriers are: 1) Difficulty in quantifying architectural inconsistency effects, and thus justifying the allocation of resources to fix them to senior management, 2) The near invisibility of architectural inconsistency to customers, 3) Practitioners' reluctance towards fixing architectural inconsistencies, and 4) Practitioners perception that huge effort is required to map the system to the architecture when using more formal AC approaches and tools. Practitioners still believe that AC would be useful in supporting several of the software development activities such as auditing, evolution and ensuring quality attributes. After reviewing several commercial tools, we posit that AC tool vendors need to work on their ability to support analysis of systems made up of different technologies, that AC tools need to enhance their capabilities with respect to artefacts such as services and meta-data, and to focus more on non-maintainability architectural concerns.

No abstract

No abstract

No abstract