Proceedings of the Second Software Architecture Technology User Network (SATURN) Workshop

The second Carnegie Mellon Software Engineering Institute (SEI) Software Architecture Technology User Network (SATURN) Workshop was held April 25-26, 2006 in Pittsburgh, Pennsylvania. A total of 61 software systems engineers, architects, technical managers, product managers, and researchers exchanged best practices and lessons learned in applying SEI software architecture technology in an architecture-driven development or acquisition project. In the closing session, workshop participants noted these highlights: presentations showing the methods in action, a comparison of multiple SEI Architecture Tradeoff Analysis Method (ATAM) evaluations and cross-wise analysis, the workshop format using interactive presentations, a good mix of academic and industry perspectives, and a sharing of workshop results. This report describes the workshop format, discussion, and results, as well as plans for future SATURN workshops. Key topics covered in the workshop and noted by the participants were the future plans of the SEI's Software Architecture Technology Initiative, the overall integration of software architecture methods and techniques, and the experiences others shared in applying the methods and transitioning them for use. Slides for the presentations and recordings of the keynote talks are available at the SATURN workshop Web site

Integrating Software-Architecture-Centric Methods into Extreme Programming (XP)

This technical note fits the architecture-centric methods of the Carnegie Mellon Software Engineering Institute (SEI) into the framework of Extreme Programming (XP). These methods include the Architecture Tradeoff Analysis Method, the SEI Quality Attribute Workshop, the SEI Attribute-Driven Design method, the SEI Cost Benefit Analysis Method, and SEI Active Reviews for Intermediate Design. This report presents a summary of XP and examines the potential uses of the SEI's architecture-centric methods

Modifiability Tactics

An architectural tactic is a design decision that affects how well a software architecture addresses a particular quality attribute. This report describes how tactics are based on the parameters of quality attribute models. Tactics provide an architectural means of adjusting those parameters, which, in turn, can improve the quality-attribute-specific behavior of the resulting system. This report justifies the tactics for modifiability, using established concepts of coupling, cohesion, and cost motivations as the means of identifying parameters of interest. Various tactics are then described based on their ability to control these parameters. The report also describes a standard set of architectural patterns and their variants in terms of the use of these tactics

A Study of Enabling Factors for Rapid Fielding Combined Practices to Balance Speed and Stability

<p>Agile projects are showing greater promise in rapid fielding as compared to waterfall projects. However, there is a lack of clarity regarding what really constitutes and contributes to success. We interviewed project teams with incremental development lifecycles, from five government and commercial organizations, to gain a better understanding of success and failure factors for rapid fielding on their projects. A key area we explored involves how Agile projects deal with the pressure to rapidly deliver high-value capability, while maintaining project speed (delivering functionality to the users quickly) and product stability (providing reliable and flexible product architecture). For example, due to schedule pressure we often see a pattern of high initial velocity for weeks or months, followed by a slowing of velocity due to stability issues. Business stakeholders find this to be disruptive as the rate of capability delivery slows while the team addresses stability problems. We found that experienced practitioners, when faced with these challenges, do not apply Agile practices alone. Instead they combine practices—Agile, architecture, or other—in creative ways to respond quickly to unanticipated stability problems. In this paper, we summarize the practices practitioners we interviewed from Agile projects found most valuable and provide an overarching scenario that provides insight into how and why these practices emerge.</p

Integrating the Quality Attribute Workshop (QAW) and the Attribute-Driven Design (ADD) Method

The Software Architecture Technology Initiative at the Carnegie Mellon Software Engineering Institute (SEI) has developed a number of architecture-centric methods that are currently in use. The initiative is now focusing on integrating these methods, as well as building bridges between them and software-development processes and software-architecture efforts outside the SEI, while continuing to refine existing methods and models. The goal is to provide software architects with a comprehensive, end-to-end approach for creating and using the right software architecture for the job at hand. This technical note reports on a proposal to integrate the SEI Quality Attribute Workshop (QAW) and the SEI Attribute-Driven Design (ADD) method. The QAW is a way to elicit and articulate detailed quality attribute requirements for a system, which the architecture must support. ADD is an architectural design method that starts with statements of quality attribute requirements and guides the architect through a series of design decisions that help to meet those requirements. Integrating these methods involves tailoring the QAW to provide the types of results needed by ADD and tailoring the ADD method to take full advantage of the results provided by the QAW

Elaboration on an Integrated Architecture and Requirement Practice: Prototyping with Quality Attribute Focus

<p>This experience report builds on an earlier study in which we interviewed eight project teams that were using iterative incremental lifecycles. In the study, we captured the practices the teams felt contributed to rapid delivery. We identified a mix of Agile and architecture practices that teams apply to rapidly field software and minimize disruption and delay. In this paper, we elaborate one practice from the study, prototyping with quality attribute focus. We compared two experiences in prototyping focused on quality attribute considerations applied on Scrum projects. We observe through interviews that feature development and prototyping practice spans multiple levels: feature development/sprint, release planning, and portfolio planning. We also observe other factors including rapid trade-off analysis, flexible architecture, and adoption of a set of enabling prototyping guidelines. The analysis of the observations sheds light on several aspects of the practice that enable the team to respond quickly and efficiently when prototype feedback suggests architectural change.</p

Toward Design Decisions to Enable Deployability Empirical Study of Three Projects Reaching for the Continuous Delivery Holy Grail

<p>There is growing interest in continuous delivery practices to enable rapid and reliable deployment. While practices are important, we suggest architectural design decisions are equally important for projects to achieve goals such continuous integration (CI) build, automated testing and reduced deployment-cycle time. Architectural design decisions that conflict with deployability goals can impede the team’s ability to achieve the desired state of deployment and may result in substantial technical debt. To explore this assertion, we interviewed three project teams striving to practicing continuous delivery. In this paper, we summarize examples of the deployability goals for each project as well as the architectural decisions that they have made to enable deployability. We present the deployability goals, design decisions, and deployability tactics collected and summarize the design tactics derived from the interviews in the form of an initial draft version hierarchical deployability tactic tree.</p

Enabling Incremental Iterative Development at Scale: Quality Attribute Refinement and Allocation in Practice

Software Engineering Institut

Risk Themes Discovered Through Architecture Evaluations

This technical report analyzes the output of 18 evaluations conducted using the Architecture Tradeoff Analysis Method (ATAM) developed by the Carnegie Mellon Software Engineering Institute. The goal of this analysis was to find patterns in the risk themes identified during those evaluations. The major results are * a categorization of risk themes * the observation that twice as many risk themes are risks of "omission" as are risks of "commission" * a failure to find a relationship between the business/mission goals of a system and the risk themes revealed during an ATAM evaluation of that system * a failure to find a relationship between the domain of a system being evaluated and the risk themes associated with the development of that syste

Impact of Army Architecture Evaluations

The Army Strategic Software Improvement Program (ASSIP) is a multiyear effort targeted at improving the way in which the Army acquires software-intensive systems. The ASSIP has funded a number of programs, in conjunction with the Carnegie Mellon Software Engineering Institute (SEI), to conduct software architecture evaluations using the Architecture Tradeoff Analysis Method (ATAM). Additionally, in cases when a system's architecture did not exist or was not ready to evaluate, the ASSIP sponsored Quality Attribute Workshops (QAWs). During the period of this effort, several other programs funded their own ATAM evaluations and QAWs. The goal of this study was to determine the benefits associated with using the ATAM and QAW. This special report describes the results of a study of the impact that the ATAM evaluations and QAWs had on Army programs. All 12 programs that used the ATAM and/or QAW responded to a questionnaire whose objective was to determine the impact of the experience in terms of the quality of the system, the practices of the involved program office, stakeholders, and suppliers, and the overall value of the engagement. The data gathered confirms that the use of ATAM-based architecture evaluations and QAWs are generally beneficial to system acquisitions and suggests that maximal benefit is achievable only if architecture-centric practices are built into the acquisition process