This case study combines known software structure and revision history analysis techniques, in known and new ways, to predict bug-related change frequency, and uncover architecture-related risks in an agile industrial software development project. We applied a suite of structure and history measures and statistically analyzed the correlations between them. We detected architecture issues by identifying outliers in the distributions of measured values and investigating the architectural significance of the associated classes. We used a clustering method to identify sets of files that often change together without being structurally close together, investigating whether architecture issues were among the root causes. The development team confirmed that the identified clusters reflected significant architectural violations, unstable key interfaces, and important undocumented assumptions shared between modules. The combined structure diagrams and history data justified a refactoring proposal that was accepted by the project manager and implemented.

The GEAR process integrates three approaches to architectural requirements engineering: model-driven requirements engineeering, quality attribute scenarios, and global analysis, within an iterative, incremental analysis process. In so doing, it shows where these methods overlap and where they complement each other. It also adds insight into the differences between product requirements and architecture requirements. GEAR incorporates experience from over a dozen diverse industrial software architecture projects.

Abstract Many product families are modest in the sense that they consist of a sequence of incremental products with, at any point in time, only a few distinct products available and minimal variations among the products. Such product families, nevertheless, are often large, complex systems, widely deployed, and possessing stringent safety and performance requirements. This paper describes a case study that tends to confirm the value of using a product‐line approach for the architectural design of a modest product family. The paper describes the process, design alternatives, and lessons learned, both positive and negative, from the architectural design of one such family of medical image analysis products. Realized benefits included identifying previously unrecognized common behavior and sets of features that were likely to change together, aligning the architecture with specific market needs and with the organization, and reducing unplanned dependencies. Most interesting were the unanticipated benefits, including decoupling the product‐family architecture from the order of implementation of features, and using the product‐family architecture as a ‘guiding star’ with subsequent releases moving toward, rather than away from, the planned architecture. Copyright © 2004 John Wiley & Sons, Ltd.

It is now generally accepted that separating software architecture into multiple views can help in reducing complexity and in making sound decisions about design trade-offs. Our four views are based on current practice; they are loosely coupled, and address different engineering concerns [1]. This tutorial will teach you how global analysis can improve your design, and how to use UML to describe these views. You will learn: (1) the purpose of having separate software architecture views, (2) the differnce between using UML for software architecture and the use of UML for designing OO implementations, (3) how to apply global analysis to analyze factors that influence the architecture and to develop strategies that guide the design, (4) the importance of designing for anticipated change to produce more maintainable architectures, and (5) how to incorporate software architecture design in your software process. This tutorial is aimed at experienced softwre engineers, architects, and technical managers. It is assumed that participants know the basic UML diagrams. Experience in developing models and software design is helpful.

The pattern-composition diagram and the attribute/decision graph summarize an architecture and its rationale, respectively. The paper introduces, defines, and discusses these notations, with an example of a reference architecture for a broad class of real-time systems. The design patterns organizing the infrastructure of the example system would be highly recommended for most large systems today, and are therefore nominated as "foundational architectural patterns".

Tichy's Smart Recompilation method can be made smarter by permitting benign type inconsistencies between separately compiled modules. This enhanced method helps the programmer to make far-reaching changes in small, manageable steps.