462,229 research outputs found

    Software Architecture in Practice: Challenges and Opportunities

    Full text link
    Software architecture has been an active research field for nearly four decades, in which previous studies make significant progress such as creating methods and techniques and building tools to support software architecture practice. Despite past efforts, we have little understanding of how practitioners perform software architecture related activities, and what challenges they face. Through interviews with 32 practitioners from 21 organizations across three continents, we identified challenges that practitioners face in software architecture practice during software development and maintenance. We reported on common software architecture activities at software requirements, design, construction and testing, and maintenance stages, as well as corresponding challenges. Our study uncovers that most of these challenges center around management, documentation, tooling and process, and collects recommendations to address these challenges.Comment: Preprint of Full Research Paper, the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE '23

    Non-functional requirements in software architecture practice

    Get PDF
    Dealing with non-functional requirements (NFRs) has posed a challenge onto software engineers for many years. Over the years, many methods and techniques have been proposed to improve their elicitation, documentation, and validation. Knowing more about the state of the practice on these topics may benefit both practitioners’ and researchers’ daily work. A few empirical studies have been conducted in the past, but none under the perspective of software architects, in spite of the great influence that NFRs have on daily architects’ practices. This paper presents some of the findings of an empirical study based on 13 interviews with software architects. It addresses questions such as: who decides the NFRs, what types of NFRs matter to architects, how are NFRs documented, and how are NFRs validated. The results are contextualized with existing previous work.Preprin

    The Critical Need for Software Architecture Practices in Software Development Process

    Get PDF
    Software architecture is the master plan of every reliable software system. It is the building block of any kind of software system which greatly determines the success of the system. This paper argues that every system needs a good architecture and that requires the use of good architecture engineering practices in a software development process. The paper recognized software architecture practice as a discipline pervading all phases of software development and then identifies some of the pertinent areas where architectural practice can be used based on a framework. In addition a model showing how software architecture fits into the phases of a generic software development process lifecycle was presented. The model is to enable software developers and acquirers to use effective software architecture practices during software development in order to exert significantly greater control over software product qualities. Keywords: Software architecture, Software Development, Software, Quality, Stakeholders, Software engineerin

    Linking Quality Attributes and Constraints with Architectural Decisions

    Get PDF
    Quality attributes and constraints are among the main drivers of architectural decision making. The quality attributes are improved or damaged by the architectural decisions, while restrictions directly include or exclude parts of the architecture (for example, the logical components or technologies). We can determine the impact of a decision of architecture in software quality, or which parts of the architecture are affected by a constraint, but the difficult problem is whether we are respecting the quality requirements (requirements on quality attributes) and constraints with all the architectural decisions made. Currently, the common practice is that architects use their own experience to design architectures that meet the quality requirements and restrictions, but at the end, especially for the crucial decisions, the architect has to deal with complex trade-offs between quality attributes and juggle possible incompatibilities raised by the constraints. In this paper we present Quark, a computer-aided method to support architects in software architecture decision making

    Making Software Architecture a Continuous Practice

    Get PDF
    DevOps is an ever growing trend in software development and it conveys a mindset that all things should be continuous. Interestingly, one of the common challenges with DevOps adoption is related to software architecture and this is in large due to the fact that architecture is not part of DevOps. This thesis looks at making software architecture a continuous practice and thus bring it into the DevOps space. A prototype solution, Architector, was implemented to solve this and the results indicate that it shows a viable approach to making software architecture a continuous practice. However, further work is necessary to expand the scope of continuous architecture and to fully validate this claim by applying Architector to a real world software development workflow

    Going Beyond the Blueprint: Unravelling the Compex Reality of Software Architectures

    Get PDF
    The term Software Architecture captures a complex amalgam of representations and uses, real and figurative, that is rendered and utilized by different stakeholders throughout the software development process. Current approaches to documenting Software Architecture, in contrast, rely on the notion of a blueprint that may not be sufficient to capture this multi-faceted concept. We argue that it might not even be feasible in practice to have such a unified understanding of this concept for a given setting. We demonstrate, with the help of in-depth case studies, that four key metaphors govern the creation and use of software architecture by different communities: “blueprint”, “literature”, “language”, and “decision”. The results challenge the current, somewhat narrow, understanding of the concept of software architecture that focuses on description languages, suggesting new directions for more effective representation and use of software architecture in practice
    • …
    corecore