Software refactoring plays an important role in software engineering. Developers often turn to refactoring when they want to restructure software to improve its quality without changing its external behavior. Small-scale (floss) refactoring is common in industry and is often performed by a single developer in short sessions, even though developers do much of this work manually instead of using refactoring tools. However, some refactoring efforts are much larger in scale, requiring entire teams and months or years of effort, and the role of tools in these efforts is not as well studied. In this paper, we report on a survey we conducted with developers to understand large-scale refactoring and its tool support needs. Our results from 107 industry developers demonstrate that projects commonly go through multiple large-scale refactorings, each of which requires considerable effort. Our study finds that developers use several categories of tools to support large-scale refactoring and rely more heavily on general-purpose tools like IDEs than on tools designed specifically to support refactoring. Tool support varies across the different activities, with some particularly challenging activities seeing little use of tools in practice. Furthermore, our analysis suggests significant impact is possible through advances in tool support for comprehension and testing, as well as through support for the needs of business stakeholders.

Database normalization is one of the main principles for designing relational databases, which is the most popular database model, with the objective of improving data and system qualities, such as performance. Refactoring the database for normalization can be costly, if the benefits of the exercise are not justified. Developers often ignore the normalization process due to the time and expertise it requires, introducing technical debt into the system. Technical debt is a metaphor that describes trade-offs between short-term goals and applying optimal design and development practices. We consider database normalization debts are likely to be incurred for tables below the fourth normal form. To manage the debt, we propose a multi-attribute analysis framework that makes a novel use of the Portfolio Theory and the TOPSIS method (Technique for Order of Preference by Similarity to Ideal Solution) to rank the candidate tables for normalization to the fourth normal form. The ranking is based on the tables estimated impact on data quality, performance, maintainability, and cost. The techniques are evaluated using an industrial case study of a database-backed web application for human resource management. The results show that the debt-aware approach can provide an informed justification for the inclusion of critical tables to be normalized, while reducing the effort and cost of normalization.

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.

Despite progress in providing software engineers with tools that automate an increasing number of development tasks, complex activities like redesigning and reengineering existing software remain resource intensive or are supported by tools that are error prone. Complex, but common tasks in industry, like evolving large codebases (1M+ SLOC) to meet changing needs, still rely on costly manual efforts and incur significant technical risk. In one example, an organization that we work with estimated 14,000 hours of development work alone (excluding integration and testing) to isolate a feature from the underlying hardware platform. These examples are pervasive in industry. Software engineering research has taken providing effective tools for software evolution for granted for far too long. The time is right for research to take advantage of advances in search-based software engineering and create the next generation of industry-relevant automated software evolution tools. This paper lays out a vision for automated refactoring at scale towards this goal.

Design problems, frequently the result of optimizing for delivery speed, are a critical part of long-term software costs. Automatically detecting such design issues is a high priority for software practitioners. Software quality tools promise automatic detection of common software quality rule violations. However, since these tools bundle a number of rules, including rules for code quality, it is hard for users to understand which rules identify design issues in particular. Research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classified 466 software quality rules from three industry tools-CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either non-design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, to support automatic detection.

Concretely communicating technical debt and its consequences is of common interest to both researchers and software engineers. In the absence of validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices. Most commonly they report using issue trackers or their existing backlog management practices to capture and track technical debt. In a manual examination of 1,264 issues from four issue trackers from open source industry and government projects, we identified 109 examples of technical debt. Our study reveals that technical debt and its related concepts have entered the vernacular of developers as they discuss development tasks through issue trackers. Even when issues are not explicitly tagged as technical debt, it is possible to identify technical debt items in these issue trackers using a categorization method we developed. We use our results and data to motivate an improved definition and an approach to explicitly report technical debt in issue trackers.

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.

Software engineers and architects of complex software systems need to balance hard quality attribute requirements while at the same time manage risks and make decisions with a system-wide and long-lasting impact. To achieve these tasks efficiently, they need quantitative information about design-time and run-time system aspects through usable and quick tools. While there is body of work focusing on code quality and metrics, their applicability at the design and architecture level and at scale are inconsistent and not proven. We are interested in exploring whether architecture can assist with better contextualizing existing system and code quality and metrics approaches. Furthermore, we ask whether we need additional architecture-level metrics to make progress and whether something as complex and subtle as software architecture can be quantified. The goal of this workshop is to discuss progress, gather empirical evidence, and identify priorities for a research agenda on architecture and metrics in the software engineering field.

The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this paper, we report on our survey of 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organizations, and follow-up interviews of seven software engineers. We analyzed our data using both nonparametric statistics and qualitative text analysis. We found that architectural decisions are the most important source of technical debt. Furthermore, while respondents believe the metaphor is itself important for communication, existing tools are not currently helpful in managing the details. We use our results to motivate a technical debt timeline to focus management and tooling approaches.

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 deploy ability 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 deploy ability goals for each project as well as the architectural decisions that they have made to enable deploy ability. We present the deploy ability goals, design decisions, and deploy ability tactics collected and summarize the design tactics derived from the interviews in the form of an initial draft version hierarchical deploy ability tactic tree.

As industry continues to embrace incremental software development, many projects run into the challenge of incrementally evolving cross-cutting concerns such as performance. To better understand how projects are handling this challenge in practice, we captured experiences from two financial services that made a series of performance improvements over several months. We discovered some commonality in how these projects refine the work, enabling incremental requirements analysis and allocation of work. In this paper, we describe two key aspects of this evolution: refining the concern by breaking it into its constituent parts to drive design tasks and allocating the parts to iterations as the software evolves. Two practices we observed that support this evolution include ratcheting broadened to conceptually describe the refinement approach in dimensions of response to stimuli in a given context and analysis conducted concurrently and loosely coupled from implementation work. This refinement supports ongoing exploration of the problem and solution, and evolutionary development, such as course changes, when new information is acquired.

The goal of this fifth workshop on managing technical debt is to engage leading empiricists and practitioners in exploring practical problems to provide opportunities for research that can provide evidence for or against the emerging definition of technical debt and the efficacy of emerging practice.

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.

Although now 20 years old, only recently has the concept of technical debt gained some momentum and credibility in the software engineering community. The goal of this fourth workshop on managing technical debt is to engage researchers and practitioners in exchanging ideas on viable research directions and on how to put the concept to actual use, beyond its usage as a rhetorical instrument to discuss the fate and ailments of software development projects. The workshop participants presented and discussed approaches to detect, analyze, visualize, and manage technical debt, in its various forms, on large software-intensive system developments.

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.

Summary form only given. This presentation will cover recent developments in the theory of negative imaginary systems and their application to the control of highly resonant flexible structures. The theory of negative imaginary systems arose out of a desire to unify a number of classical methods for the control of lightly damped structures with collocated force actuators and position sensors including positive position feedback and integral force feedback. The key result is a stability result which shows why these methods are guaranteed to yield robust closed loop stability in the face of unmodelled spillover dynamics. Related results to be presented connect the theory of negative imaginary systems to positive real systems theory and a negative imaginary lemma has been established which is analogous to the positive real lemma. The presentation will also discuss recent controller synthesis results based on the theory of negative imaginary systems along with applications in the aerospace area such as the control of large space flexible structures.

The technical debt metaphor is gaining significant traction in the software development community as a way to understand and communicate issues of intrinsic quality, value, and cost. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which should be repaid at some point for the long-term health of the project. Little is known about technical debt, beyond feelings and opinions. The software engineering research community has an opportunity to study this phenomenon and improve the way it is handled. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. The goal of this second workshop is to discuss managing technical debt as a part of the research agenda for the software engineering field.

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 in subsequent releases. What is lacking, however, is quantifiable guidance that highlights the potential benefits and risks of choosing one or the other of these alternatives or a blend of both strategies. In this paper, we assert that the ability to quantify architecture quality with measurable criteria provides engineering guidance for iterative release planning. We demonstrate the use of propagation cost as a proxy for architectural health with dependency analysis of design structure and domain mapping matrices as a quantifiable basis for iteration planning.

Traditional analysis and design approaches focus on "fit for purpose." Experience with contextual environment concerns demonstrates that "fit to context" is a consideration that is equally significant for the appropriateness of the chosen architecture. We propose a multilevel, context-aware approach to software architecture that (1) treats contextual environment concerns as first class entities and (2) groups concerns and techniques of different abstraction, scope and grain into separate explicit levels. We categorize contextual environment concerns into enterprise and system. The proposed method groups software architecture in macro-architecture and micro-architecture levels. In a significant departure from most current software architecture practices, we view and treat macro-architecture as a decision analysis discipline while applying the engineering modeling and design practices used in traditional software architecture methods to the micro-architecture level. In this paper we introduce the software architecture approach and method, discuss our current research, and identify the topics that must be addressed and further defined to complete the method.

Summary form only given. Software architecture has become a widely-accepted conceptual basis for the development of non-trivial software in all application areas and by organizations of all sizes. Effectively evaluating architecture is as important as crafting it in order to have assurance that it successfully addresses the target system qualities, which in turn, help fulfill the business goals of the system. We present the Architecture Tradeoff Analysis Method (ATAM), a practical and comprehensive approach for evaluating software architectures that is based on the principles of quality attributes and architectural tactics. We have gained experience with the approach by analyzing the architecture of several systems, and the ATAM is now a standard practice in many large companies.

The output of 18 software architecture evaluations are analyzed to find patterns in the risk themes identified in the evaluations. The major results are: i) A categorization of risk themes ii) The observation that twice as many risk themes are risks of "omission " as are risks of "commission ". iii) A failure to find a relationship between the business and mission goals of a system and the risk themes from an evaluation of that system. iv) A failure to find a relationship between the domain of a system being evaluated and the risk themes associated with the development of that system. The results of this investigation have application to practitioners by suggesting activities on which developers should put greater focus. They also have application to researchers by suggesting further areas of investigation.

We compare five industrial software architecture design methods and we extract from their commonalities a general software architecture design approach. Using this general approach, we compare across the five methods the artifacts and activities they use or recommend, and we pinpoint similarities and differences. Once we get beyond the great variance in terminology and description, we find that the 5 approaches have a lot in common and match more or less the "ideal" pattern we introduced.

This lecture maps the concepts and templates explored in this tutorial with well-known architectural prescriptions, including the 4+1 approach of the Rational Unified Process, the Siemens Four Views approach, and the ANSI/IEEE-1471-2000 recommended best practice for documenting architectures for software-intensive systems. The lecture concludes by re-capping the highlights of the tutorial, and asking for feedback.

In this paper we discuss a set of architecture-based methods for architecture design and analysis that have been developed over the past 10 years at the Software Engineering Institute. We then discuss the need for integrating these architecture-based methods, both with each other and into an organization's system development life cycle, based on experience with NASA's EOSDIS project. We discuss the framework for doing this integration, and present a life cycle view of architecture-based design and analysis methods.

Although originally developed to describe OO design, today UML is also being used to describe software architecture. However, using the same notation for different levels of abstraction can create confusion. In this paper we illustrate some of the important differences between software architecture models and implementation models in UML.

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.

No abstract available.

No abstract available.

The software architecture of a system describes how it is decomposed into components, how these components are interconnected, and how they communicate and interact with each other and with the environment. Software architecture represents critical, system-wide design decisions which affect quality, reconfigurability and reuse, and the cost for development and maintenance. In order to understand architecture as it is practised in the real world, we conducted a survey of a variety of industrial software systems. Our survey revealed the need for rigorous descriptions, systematic techniques, and well-defined processes to make architecture-level software development an engineering practice rather than an art.>

To help us identify and focus on pragmatic and concrete issues related to the role of software architecture in large systems, we conducted a survey of a variety of software systems used in industrial applications.Our premise, which guided the examination of these systems, was that software architecture is concerned with capturing the structures of a system and the relationships among the elements both within and between structures.The structures we found fell into several broad categories: conceptual architecture, module interconnection architecture, code architecture, and execution architecture.These categories address different engineering concerns.The separation of such concerns, combined with specialized implementation techniques, decreased the complexity of implementation, and improved reuse and reconfiguration.