4,037 research outputs found

    An exploratory case study on reusing architecture decisions in software-intensive system projects

    Get PDF
    Reusing architecture decisions from previous projects promises to support architects when taking decisions. However, little is known about the state of art of decision-reuse and the benefits and challenges associated with reusing decisions. Therefore, we study how software architects reuse architecture decisions, the stakeholders and their concerns related to decision-reuse, and how architects perceive the ideal future state of decision-reuse. We conducted a qualitative explorative case study in the software-intensive systems industry. The study has shown that architects frequently reuse decisions but are confined to decisions they already know or have heard about. The results also suggest that architects reuse decisions in an ad-hoc manner. Moreover this study presents a conceptual model of decision-reuse and lists stakeholder concerns with regards to decision-reuse. The results of this study indicate that improving the documentation and discoverability of decisions holds a large potential to increase reuse of decisions and that decision documentation is not only important for system understanding or in the context of architecture reviews but also to support architects in upcoming projects

    Towards guidelines for building a business case and gathering evidence of software reference architectures in industry

    Get PDF
    Background: Software reference architectures are becoming widely adopted by organizations that need to support the design and maintenance of software applications of a shared domain. For organizations that plan to adopt this architecture-centric approach, it becomes fundamental to know the return on investment and to understand how software reference architectures are designed, maintained, and used. Unfortunately, there is little evidence-based support to help organizations with these challenges. Methods: We have conducted action research in an industry-academia collaboration between the GESSI research group and everis, a multinational IT consulting firm based in Spain. Results: The results from such collaboration are being packaged in order to create guidelines that could be used in similar contexts as the one of everis. The main result of this paper is the construction of empirically-grounded guidelines that support organizations to decide on the adoption of software reference architectures and to gather evidence to improve RA-related practices. Conclusions: The created guidelines could be used by other organizations outside of our industry-academia collaboration. With this goal in mind, we describe the guidelines in detail for their use.Peer ReviewedPostprint (published version

    Assisting software architects in architectural decision-making using Quark

    Get PDF
    Non-Functional Requirements (NFRs) and constraints are among the principal drivers of architectural decision-making. NFRs are improved or damaged by architectural decisions (ADs), while constraints directly include or exclude parts of the architecture (e.g., logical components or technologies). We may determine the impact of an AD, or which parts of the architecture are affected by a constraint, but at the end it is hard to know if we are respecting the NFRs and the imposed constraints with all the ADs made. In the usual approach, architects use their own experience to produce software architectures that comply with the NFRs and imposed constraints, but at the end, especially for crucial decisions, the architect has to deal with complex trade-offs between NFRs and juggle with possible incompatibilities raised by the imposed constraints. In this paper we present Quark, a method to assist software architects in architectural decision-making, and the conceptualization of the relationship between NFRs and ADs defined in Arteon, an ontology to represent and manage architectural knowledge. Finally, we provide an overview of the Quark and Arteon implementation, the ArchiTech tool.Peer ReviewedPostprint (published version

    Rationale in Development Chat Messages: An Exploratory Study

    Full text link
    Chat messages of development teams play an increasingly significant role in software development, having replaced emails in some cases. Chat messages contain information about discussed issues, considered alternatives and argumentation leading to the decisions made during software development. These elements, defined as rationale, are invaluable during software evolution for documenting and reusing development knowledge. Rationale is also essential for coping with changes and for effective maintenance of the software system. However, exploiting the rationale hidden in the chat messages is challenging due to the high volume of unstructured messages covering a wide range of topics. This work presents the results of an exploratory study examining the frequency of rationale in chat messages, the completeness of the available rationale and the potential of automatic techniques for rationale extraction. For this purpose, we apply content analysis and machine learning techniques on more than 8,700 chat messages from three software development projects. Our results show that chat messages are a rich source of rationale and that machine learning is a promising technique for detecting rationale and identifying different rationale elements.Comment: 11 pages, 6 figures. The 14th International Conference on Mining Software Repositories (MSR'17

    Report from GI-Dagstuhl Seminar 16394: Software Performance Engineering in the DevOps World

    Get PDF
    This report documents the program and the outcomes of GI-Dagstuhl Seminar 16394 "Software Performance Engineering in the DevOps World". The seminar addressed the problem of performance-aware DevOps. Both, DevOps and performance engineering have been growing trends over the past one to two years, in no small part due to the rise in importance of identifying performance anomalies in the operations (Ops) of cloud and big data systems and feeding these back to the development (Dev). However, so far, the research community has treated software engineering, performance engineering, and cloud computing mostly as individual research areas. We aimed to identify cross-community collaboration, and to set the path for long-lasting collaborations towards performance-aware DevOps. The main goal of the seminar was to bring together young researchers (PhD students in a later stage of their PhD, as well as PostDocs or Junior Professors) in the areas of (i) software engineering, (ii) performance engineering, and (iii) cloud computing and big data to present their current research projects, to exchange experience and expertise, to discuss research challenges, and to develop ideas for future collaborations

    Industrial Implementation of a Documentation Framework for Architectural Decisions

    Full text link
    Architecture decisions are often not explicitly documented in practice but reside in the architect's mind as tacit knowledge, even though explicit capturing and documentation of architecture decisions has been associated with a multitude of benefits. As part of a research collaboration with ABB, we developed a tool to document architecture decisions. This tool is an add-in for Enterprise Architect and is an implementation of a viewpoint-based decision documentation framework. To validate the add-in, we conducted an exploratory case study with ABB architects. In the study, we assessed the status quo of architecture decision documentation, identified architects' expectations of the ideal decision documentation tool, and evaluated the new add-in. We found that although awareness of decision documentation is increasing at ABB, several barriers exist that limit the use of decisions in practice. Regarding their ideal tool, architects want a descriptive and efficient approach. Supplemental features like reporting or decision sharing are requested. The new add-in, was well-perceived by the architects. As a result of the study, we propose a clearer separation of problem, outcomes, and alternatives for the decision documentation framework

    Robotics Software Engineering: A Perspective from the Service Robotics Domain

    Full text link
    Robots that support humans by performing useful tasks (a.k.a., service robots) are booming worldwide. In contrast to industrial robots, the development of service robots comes with severe software engineering challenges, since they require high levels of robustness and autonomy to operate in highly heterogeneous environments. As a domain with critical safety implications, service robotics faces a need for sound software development practices. In this paper, we present the first large-scale empirical study to assess the state of the art and practice of robotics software engineering. We conducted 18 semi-structured interviews with industrial practitioners working in 15 companies from 9 different countries and a survey with 156 respondents (from 26 countries) from the robotics domain. Our results provide a comprehensive picture of (i) the practices applied by robotics industrial and academic practitioners, including processes, paradigms, languages, tools, frameworks, and reuse practices, (ii) the distinguishing characteristics of robotics software engineering, and (iii) recurrent challenges usually faced, together with adopted solutions. The paper concludes by discussing observations, derived hypotheses, and proposed actions for researchers and practitioners.Comment: 11 pages + 1 page for references, 3 figures, 3 tables, in proceedings of ESEC/FSE 202

    On opportunistic software reuse

    Get PDF
    The availability of open source assets for almost all imaginable domains has led the software industry toopportunistic design-an approach in which people develop new software systems in an ad hoc fashion by reusing and combining components that were not designed to be used together. In this paper we investigate this emerging approach. We demonstrate the approach with an industrial example in whichNode.jsmodules and various subsystems are used in an opportunistic way. Furthermore, to study opportunistic reuse as a phenomenon, we present the results of three contextual interviews and a survey with reuse practitioners to understand to what extent opportunistic reuse offers improvements over traditional systematic reuse approaches.Peer reviewe
    • …
    corecore