Within any incremental development paradigm, there exists a tension between the desire to deliver value to the customer early and the desire to reduce cost by avoiding architectural refactoring and rework in subsequent releases. What is lacking is an analytical framework that quantifies opportunities and risks of choosing one or the other of these strategies or a blend of the two. This article demonstrates the use of design structure and domain mapping matrices for analyzing architectural dependencies and proposes an optimization-based decision-making technique to support effective release planning. The optimization models recommend the order in which architectural elements and features should be implemented across different releases so as to: (a) minimize rework cost; (b) maximize early value delivery; or (c) optimize an integrated measure of cost and value. These analytic models can be applied earlier in the life cycle and, hence, provide timely information about the progress and changes that occur at each iteration.

Research in code and architectural analysis has demonstrated that a clear understanding of structural dependencies among software elements helps developers comprehend the impact of change. Yet examples are abundant from industry of major issues due to missed dependencies associated with different views of the architecture. Key concerns include dependencies related to allocation of modules to implementation packages to improve safety-critical testing and allocation of implementation packages to hardware partitions to optimize performance. In this paper, we present an in-depth study of a safety-critical system that underwent major changes as a result of missed architectural dependencies. We describe the challenges that resulted in re-architecting the system, the techniques we used for intervention, our results, and the developers' perspective. While the engineering tools provided coverage of design concerns, they missed implications of end-to-end integration testing, latency, and cost of change. In our study, we observed that the tools led the engineers to focus on data and control flow and therefore to miss many data-entity relationships, resource behavior, and deployment-related dependencies. Research continues to focus on more tooling and automation to assist with dependency analysis rather than interim, easier-to-adopt solutions. Our findings demonstrate that providing developers with a lightweight, semantically well-defined description of dependencies enables them to reason about change impact and propagation implications that they might otherwise overlook.

Tools available for measuring the modifiability or impact of change of a system through its architecture typically use structural metrics. These metrics take into account dependencies among the different elements of a system. However, they fail to capture the semantics of an architectural transformation necessary to control the complexity and cost of making changes. To highlight such limitations, this paper presents a study where we applied a representative structural metric, called 'propagation cost', to archetypical architectural transformations known to affect system modifiability such as rearchitecting a tightly coupled system to a layered pattern. We observe that in its original form the propagation cost metric does not provide consistent indications of architecture health. Enhancing this metric based on the semantics of the architectural pattern and tactics used in the transformation show improvements. Our results demonstrate that these enhancements detect modifiability properties that are not detectable by the propagation cost metric.

We describe an evidence-based architecture discovery approach that organizes architectural decisions in a semi-formal reasoning framework that is self-reinforced by the evidence of accommodating future design decisions. In this approach, the taxonomy of these design decisions follows the SOLID design principles [5]. We apply these principles of software design to the topics that represent the architecture itself. Decisions, once made, serve as a starting point and context for future decisions. Architecture is, therefore, discovered within the confines of decisions already made, and it is managed by ensuring that future design decisions conform to the constraints set forth by the current decisions. When evidence emerges that conformance is not possible, early design decisions must be challenged and adjusted. In this sense, future design decisions serve as a test for, and provide evidence on the validity and robustness of earlier design decisions. By creating a taxonomy of architecture topics and managing constant tension and systematic interaction between early and future design decisions, we have found that this evidence-based feedback mechanism leads to intermediate forms of an architecture that are more stable, more easily reviewed, and evolve more systematically and gracefully over time.

This tutorial describes a structured approach for determining the GSD related risks specific to a given project, selecting appropriate tactics for addressing these risks, and suggesting ways in which the level of risk can be monitored during the execution of the project.

This paper talks through the practices and infrastructure that was used on the experimental Global Studio Project (GSP). While the architecture activities are highlighted, related practices such as project management, requirements engineering and integration and test in a distributed environment will also be discussed as lessons learned.

Summary form only given. Architecture has been established as a key to developing software systems that meet quality expectations of their stakeholders. Object-Oriented Analysis and Design (OOAD) methodologies, however, treat architecture only indirectly or implicitly. The quality of systems developed using such methodologies, thus, depends largely on the skill level and experience of its architect. It has been suggested, therefore, that augmenting these methodologies with software architecture-centric methods such as the Quality Attribute Workshop (QAW) and Attribute Driven Design (ADD) can provide explicit and methodical guidance to an architect in creating systems with desirable qualities.

This paper describes the use of a system which will allow effortless visualization and animation of standard C/C++ piogrhms.tie system brings alive programs so.that students in CS 1 and CS 2 classes can more easily see each instruction and its effects.They can also see the effects of larger entities such as functions.The system serves as an excellent instructional tool and debugger.introduction " Conventional programming environments provide some support 'for program 'understanding, development, and debugging.Once .aprogram is syntactically correct, a student can use a debugger to monitor the Values of variables and step through a program's instructions.Although very useful, this-,process can be quite,involved A-. and laborious.1 The feedback a programmer receives does not provide an over+1 v&w of the program's behavior.It is more instructive to display the dynamics of a program rather than static snapshots of data structure values that are constantly Updated as program instructions are executed.Software visualization systems ,allow custom animations that attempt $0 capture these dynamics [l].Such systems generally require the writing of animation code ' and understanding of the, program one is trying to animate.The aim of our system is to provide automatic animations that are useful and require no additional coding and may lead to understanding of the underlying algorithm.One area, for instance, which has been identified as particularly troublesome for students is parameter passing [2].