Many software product companies create cross-functional development teams that own a product or a defined set of features. These product teams often require a deep and collective understanding of the product domain, a rich context within which to understand the product requirements and to make decisions throughout the development process. Little is known about what supports or impedes these teams in collectively achieving this deep understanding. This paper identifies certain organisational conditions that impact teams in this respect. Using Constructivist Grounded Theory method, we studied 18 teams across seven software companies creating products for a diverse range of markets. The study found certain organisational and planning process factors play a significant role in whether product development teams have the potential to collectively develop deep domain understanding. These factors also impact individual and development team dynamics. We identify two essential metaphorical dynamics, broadening the lens and blurring boundaries, that cross-functional product teams employ in order to fully embrace product ownership, visioning, and planning towards achieving this rich context for understanding product requirements. We also conclude that the highly specialised nature of many organisational models and development processes is contraindicated for cross-functional product development teams in achieving this deep collective understanding and we call for a revisiting of conventional organisational and product planning practices for software product development.

Architectural technical debt in software-intensive systems is a metaphor used to describe the “big” design decisions (e.g., choices regarding structure, frameworks, technologies, languages, etc.) that, while being suitable or even optimal when made, significantly hinder progress in the future. While other types of debt, such as code-level technical debt, can be readily detected by static analyzers, and often be refactored with minimal or only incremental efforts, architectural debt is hard to be identified, of wide-ranging remediation cost, daunting, and often avoided. In this study, we aim at developing a better understanding of how software development organizations conceptualize architectural debt, and how they deal with it. In order to do so, in this investigation we apply a mixed empirical method, constituted by a grounded theory study followed by focus groups. With the grounded theory method we construct a theory on architectural technical debt by eliciting qualitative data from software architects and senior technical staff from a wide range of heterogeneous software development organizations. We applied the focus group method to evaluate the emerging theory and refine it according to the new data collected. The result of the study, i.e., a theory emerging from the gathered data, constitutes an encompassing conceptual model of architectural technical debt, identifying and relating concepts such as its symptoms, causes, consequences, management strategies, and communication problems. From the conducted focus groups, we assessed that the theory adheres to the four evaluation criteria of classic grounded theory, i.e., the theory fits its underlying data, is able to work, has relevance, and is modifiable as new data appears. By grounding the findings in empirical evidence, the theory provides researchers and practitioners with novel knowledge on the crucial factors of architectural technical debt experienced in industrial contexts.

Summary form only given. The complete presentation was not made available for publication as part of the conference proceedings. We have successfully placed the adjective 'agile' in front of about every important noun in our software development/IT world: agile design, agile testing, agile management, agile database, agile architecture, agile user-interaction ...."What is next?" is the question I've been asked again and again. What is the future of software engineering? The next best thing? Is it DevOps, cloud-something, micro-services, AI? The adjective agile has lost some of its weight and novelty, only a few laggards are still asking "what is it?" It is time to reflect on the fundamental aspects of agility: what does it really means, what are the fundamental principles behind it, that made its successes. The agile movement has had some tremendous impact in the way we work, putting the human being and human interaction more central in these processes, by using extensively iterations, direct interactions, and feedback loops. But at the same time, some aspects of agile have become dogmatic, fossilized, and the agile movement has not been always very agile in its application to itself. These dogmatic aspects have slowed the expansion of its own principles to some of the more complex or much larger software development endeavours. Now, the increasing need for speed, the availability of opensource software repositories, the shifts in technology, such as the cloud, the emergence of software ecosystems are creating new needs in terms of process and project management, that can exploit the fundamental principles of agile, beyond the dogma of this or that method, this or that practice. As the amount of software in use is growing and will outgrow the capacity of our industry to maintain and evolve it, the industry faces a massive amount of technical debt, which we do not know well how to mitigate or repay. Agile has been very valuable, but once its lessons are fully integrated in the way we work we have to look beyond and stop repeating it like a mantra.

Owing to the critical role of software-intensive systems in society, software engineers have the accountability to consider sustainability as a goal while structuring a software system. However, there are no practical guidelines providing a tangible decomposition of the sustainability aspect. Moreover, there are limited quantifiable methods to support sustainable design and analysis.The purpose of this study is to help software practitioners to take sustainability into account by providing systematic guidelines for the software engineering process. We propose a framework that presents a meta model to decompose sustainability requirements and an assessment approach to evaluate sustainability achievements.This work presents an integrated framework that combines a goal-based approach, scenario-based approach, and feature modeling to gather sustainability related requirements and corresponding features. For sustainability assessment, software analysis and machine learning techniques are utilized to analyze software products based on sustainability metrics and criteria.The empirical study conducted with participants from academia and industry revealed that the proposed framework improves participant's ability to consider sustainability aspect in their software engineering tasks through focusing on requirements, design, and evaluation. With the provided sustainability meta-model, the participants could extract more stakeholders, requirements, and features in shorter time. Moreover, the empirical study result also demonstrated that this study is capable to indicate specific scenarios that should be redesigned to improve the sustainability achievements level.

For technical reasons the number of authors shown on this cover page is limited to 10 maximum.

To make a single diagnosis, today's radiologists must examine thousands of images; yet little effort has been put into refining this time-consuming, repetitive task. Meanwhile, automatic or radiologist-generated annotations may impact how radiologists navigate image stacks as they review lesions of interest. Observation and/or interviews of 19 radiologists revealed that stack scrolling dominated the resulting task examples. We iteratively crafted and obtained radiologist feedback for a variety of prototypes, then evaluated their scrolling and annotation-review support for lay users. With a simplified stack seeded with correct / incorrect annotations, we compared the effect of four scrolling techniques (traditional scrollwheel and click-and-drag, plus sliding-touch, and tilt rate control) and visual vs. haptic annotation cues on scrolling dynamics, detection accuracy and subjective factors. Scrollwheel was fastest overall, and combined visual / haptic annotation cues sped target-finding relative to either modality alone. We share insights on integrating our findings into radiologist practice.

Context: Mobile app development is a relatively new phenomenon that is increasing rapidly due to the ubiquity and popularity of smartphones among end-users. Objective: The goal of our study is to gain an understanding of the main challenges developers face in practice when they build apps for different mobile devices. Method: We conducted a qualitative study, following a Grounded Theory approach, in which we interviewed 12 senior mobile developers from 9 different companies, followed by a semi-structured survey, with 188 respondents from the mobile development community. Results: The outcome is an overview of the current challenges faced by mobile developers in practice, such as developing apps across multiple platforms, lack of robust monitoring, analysis, and testing tools, and emulators that are slow or miss many features of mobile devices. Conclusion: Based on our findings of the current practices and challenges, we highlight areas that require more attention from the research and development community.

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.

The term “Technical Debt” was coined over 20 years ago by Ward Cunningham in a 1992 OOPSL A experience report to de scribe the tr ade-offs between delivering the most appropriate — albeit likely immature — product, in the shortest time possible. Since then the repercussions of going into “technical debt” have become more visible, yet not necessarily more broadly understood. This panel will bring together practitioners to discuss and debate strategies for debt relief.

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 This paper presents a contextual model for software‐intensive systems development to guide the adoption and adaptation of agile software development practices. This model was found especially useful when the project context departs significantly from the “agile sweet spot”, that is, the ideal conditions in which agile software development practices originated from, and where they are most likely to succeed, “out of the box”. This is the case for large systems, distributed development environment, safety‐critical systems, system requiring a novel architecture, or systems with an unorthodox business model or governance model. Copyright © 2011 John Wiley & Sons, Ltd.

A complete and detailed (full) Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, this is typically too onerous for systematic industrial use as it is not cost effective to write, maintain, or read. The key idea investigated in this article is that DRD should be developed only to the extent required to support activities particularly difficult to execute or in need of significant improvement in a particular context. The aim of this article is to empirically investigate the customization of the DRD by documenting only the information items that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a specific DRD information item depends on its category (e.g., assumptions, related requirements, etc.) and on the activity it is meant to support. We investigate this hypothesis through two controlled experiments involving a total of 75 master students as experimental subjects. Results show that the value of a DRD information item significantly depends on its category and, within a given category, on the activity it supports. Furthermore, on average among activities, documenting only the information items that have been required at least half of the time (i.e., the information that will probably be required in the future) leads to a customized DRD containing about half the information items of a full documentation. We expect that such a significant reduction in DRD information should mitigate the effects of some inhibitors that currently prevent practitioners from documenting design decision rationale.

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.

This paper relates seven years of experience teaching Software Project Management both in academia as part of an undergraduate software engineering program and to software engineering graduate students, and to practitioners in industry. It explains some of the difficulties and constraints for such a course. It describes the current syllabus and its rationale. The course is constructed based on a conceptual model of software development that accommodates a wide range of process models, traditional and agile, large and small. The course is illustrated by drawing from a range of concrete processes: RUP®, DSDM®, MSF®, Scrum and XP, of software engineering standards (from IEEE and ISO) and a few project management tools. The paper then maps this course to the IEEE SWEBOK (Software Engineering Body Of Knowledge), to IEEE Standard 1490, better known as the PMBOK (Project Management Body of Knowledge), and more particularly to the recent IEEE-CS/ACM SE2004 (Software Engineering Curriculum 2004), showing how the course can be made an integral part of a well-rounded software engineering program.

Mission to Mars is an educational board game illustrating the planning process in iterative software development; it brings together concepts such as: iteration (sprint), backlog, story cards and storypoints, velocity (productivity), impact of defects, technical debt, and risks. The game is a low-cost, Monopoly-style board game, played in groups of 2 to 4 students, where some factors such as uncertainty in estimation, actual velocity, and occurrence of defects are simulated by a throw of dice. Hard constraints and dependencies between stories are added to stimulate discussion on the strategy to pursue and how to mitigate risks. The game has been played in various contexts, academic and industrial, in several countries around the world with several hundred players, and it available to the software engineering community under a Creative Commons (by-nc-sa) license. .

Architectural Knowledge (AK) is defined as the integrated representation of the software architecture of a software-intensive system or family of systems along with architectural decisions and their rationale, external influence and the development environment. The SHARK workshop series focuses on current methods, languages, and tools that can be used to extract, represent, share, apply, and reuse AK, and the experimentation and/or exploitation thereof. This sixth edition of SHARK will discuss, among other topics, the approaches for AK personalization, where knowledge is not codified through templates or annotations, but it is exchanged through the discussion between the different stakeholders.

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.

Over the last 30 years we have tried very hard the rich process models approach, and we have not been extremely successful at it. Maybe we should try "lean and mean" software process models, rather than making them "richer." At minimum, we should try to analyze why the rich approaches have not worked; where they failed. Could it be that we were trying to solve the wrong problem? or that the real problems by far overshadow the process model issue? Or maybe the whole construction paradigm we use for software development is not suitable anymore? My position is that we should try the route of very simple software process models, to ensure a wider applicability, greater versatility, and acceptance. Possibly these new process models would be based on other paradigms of software or system development than the "technical-rational" construction idea. I would be wary of richer process models.

This is the introduction of the 3rd workshop on Software Development Governance (SDG), which will take place as part of ICSE 2010. This year we have combined two successful workshops (SDG - software development governance and LMSA -- leadership and management in software architecture) since both workshops deal with decisions that are part of the development process e.g., business and organizational decisions that impact the technical decisions concerned with the product architecture and the product quality.

Software architecture is taking a bad rap with the agilists---proponents of agile and lean software development approaches: "BUFD big up-front design", "YAGNI You Ain't Gonna Need It", "massive documentation", "smells of waterfall", it is pictured as a typical non-agile practice. However, certain classes of system, ignoring architectural issues too long "hit a wall" and collapse by lack of an architectural focus. 'Agile architecture': a paradox, an oxymoron, two totally incompatible approaches? In this tutorial, we examine the real issues at stake, beyond the rhetoric and posturing, and show that the two cultures can coexist and support each other, where appropriate. We define heuristics to scope how much architecture a project really needs, to assign actual value to an otherwise invisible architecture; and we review management and development practices that do work in the circumstances where some significant architectural effort is needed, when you are actually going to need it.

Architectural Knowledge (AK) is defined as the integrated representation of the software architecture of a software-intensive system or family of systems along with architectural decisions and their rationale, external influence and the development environment. The SHARK workshop series focuses on current methods, languages, and tools that can be used to extract, represent, share, apply, and reuse AK, and the experimentation and/or exploitation thereof. This fifth edition of SHARK will discuss, among other topics, the contributions of this community to a Body of Knowledge on software architecture.

Evangelists for Agile methods strongly encourage all projects to follow every practice of their chosen method. Based on a Grounded Theory study involving 40 participants at 16 organizations, and corroborated by 4 independent case studies, we argue that development methods and practices must be adapted to fit their contexts. Understanding Agility in context will help development teams, their managers, and Agile coaches to adapt development processes to fit their projects' contexts.

The explicit documentation of the rationale of design decisions is a practice generally encouraged, but rarely implemented in industry because of a variety of inhibitors. Methods proposed in the past for design decisions rationale documentation (DDRD) aimed to maximize benefits for the DDRD consumer by imposing on the producer of DDRD the burden to document all the potentially useful information. We propose here a compromise which consists in tailoring DDRD, based on its intended use or purpose. In our view, the adoption of a tailored DDRD, consisting only of the required set of information, would mitigate the effects of DDRD inhibitors. The aim of this paper is twofold: i) to discuss the application of value-based software engineering principles to DDRD, ii) to describe a controlled experiment to empirically analyze the feasibility of the proposed method. Results show that the level of utility related to the same category of DDRD information significantly changes depending on its purpose; such result is novel and it demonstrates the feasibility of the proposed value-based DDRD.

Software architecting is a highly knowledge-intensive process demanding and producing a large and rich amount of information. To remain competitive, companies and organizations working in the IT sector must be able to manage this knowledge portfolio and effectively exploit and reuse it. In the era of Web 2.0, knowledge grids, social networking, global development and semantic Web, this working session addresses the problem of building a knowledge community in the field of software architecture. To this end, we aim at exploring the wishes of academics and industrial organizations, on the one hand, and their boundaries on he other. Our goal is to compare and contrast the inputs from academia and industry, and gain a shared understanding about what can be done now, and in the near future.

Several Software Architecture Design Methods (SADM) have been published, reviewed, and compared. But these surveys and comparisons are mostly centered on intrinsic elements of the design method, and they do not compare them from the perspective of the actual needs of software architects. We would like to analyze the completeness of SADM from an architect's point of view. To do so, we define nine categories of software architects' needs, propose an ordinal scale for evaluating the degree to which a given SADM meets the needs, and then apply this to a small set of SADMs. The contribution of the paper is twofold: (i) to provide a different and useful frame of reference for architects to select SADM, and (ii) to suggest SADM areas of improvements. We found two answers to our question: "do architectural design methods meet the needs of the architect?" Yes, all architect's needs are met by one or another SADM, but No, no architectural design method meets simultaneously all the needs of an architect. This approach may lead to improvements of existing SADMs.

This International Workshop on Global Software Development for the Practitioner (GSD2006) was held in conjunction with the 28th International Conference on Software Engineering (ICSE 2006) on May 23rd, 2006 in Shanghai, China. The workshop was motivated by the industry trend towards developing software in globally distributed settings: geographically distributed teams, or outsourcing parts of the software development to other organizations in other parts of the world. Topics presented and discussed in the workshop focused on grounded, practical strategies and techniques that address the geographic, temporal, organizational, and cultural boundaries inherent in global software projects.

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.

Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use case model for an architectural knowledge system.

Agile development methodologies are gaining acceptance in the software industry. If they are to be used for constructing security-critical solutions, what do we do about assurance? This paper examines how conventional security assurance suits agile methodologies for developing software-intensive systems. It classifies security assurance methods and techniques with regards to their clash with agile development. Suggestions are made for alleviating mismatches between these two methods.

The Rational Unified Process® (RUP®) is a software engineering process framework. It captures many of the best practices in modern software development in a form that is suitable for a wide range of projects and organizations. It embeds object-oriented techniques and uses the UML as the principal notation for the several models that are built during the development. The RUP is also an open process framework that allows software organizations to tailor the process to their specific need, and to capture their own specific process know-how in the form of process components. Many process components are now developed by various organizations to cover different domains, technologies, tools, or type of development, and these components can be assembled to rapidly compose a suitable process. This tutorial will introduce the basic concepts and principles, which lie under the RUP framework, and show concrete examples of its usage.

No abstract available.

The presence of a solid architectural vision is a key discriminator in the success or failure of a software project. This tutorial examines what software architecture is and what it is not. It discusses and illustrates how to describe architecture through a set of design viewpoints and views and how to express these views in the UML, in the spirit of the new IEEE Standard 1471:2000:Recommended practice for architectural description. The tutorial shows of how architectures drive the development process and how to capture architectural design patterns using the UML. It is illustrated by several widely applicable architectural patterns in different domain.

Interest in the use of processes to provide assistance in software development activities remains at a high level. But the focus of attention has shifted in recent years. Early work emphasizing the study of languages for defining processes was rapidly eclipsed by process evaluation and improvement work, most notably the Capability Maturity Model (CMM). As process improvement has matured as a strategy and philosophy it has also given rise to a strong reaction to the perception that it is unduly ponderous and constraining. Movements such as Extreme Programming (XP) have cast themselves as lightweight alternatives, emphasizing the primacy of freedom and flexibility. Both philosophies and communities continue to grow in size, development, and depth of understanding.The goal of this panel will be to explore the differences between these major approaches to the use of process in software development by bringing together leading articulate exponents of the approaches. Each panelist will be charged with presenting a very concise characterization of the approach being represented. But the focus of the panel will be on understanding the nature of the differences in approach, and the reasons for these differences. Similarities will be sought as well.An underlying hypothesis of the panel is that the differences in approach arise in large measure from differences in objective and differences in assumptions about the software development context. Thus, for example, one approach may be intended to support very long range organizational objectives, while the other may be more tactically oriented. One approach may assume that evolvability is an overriding objective, while another may be more focused on speed to market. One may make stronger assumptions about the skills and training of project personnel. The panel will attempt to delve into these issues to see if it may be possible to suggest criteria for suggesting which approach (and possible adaptation) should be selected for a given development situation.In a larger sense, the goal of this panel is to suggest the possibility of a discipline of software process engineering. Insofar as the panel is able to suggest that development situations can be used to guide the selection of process approaches to the provision of assistance, might this then be an indication that process formalisms could play a role in subsequent specification of detailed processes, and evaluation of their effectiveness?The panel will react to this and related questions. While lively interchanges among the panelists will be stimulated and expected, similar interchanges with the audience will also be cultivated.

The software engineering process is a growing concern for many software development organizations. The need for well-educated software engineers is bringing new software engineering programs to universities. In many programs, software process education adds up to a few hours of lectures in an introductory software engineering course. This paper presents the structure and the content for a full, one-semester course on software processes, which has been designed in close collaboration with industry. The course is based on a software process called UPEDU (Unified Process for EDUcation), pronounced Yoopeedoo, and has been customized from the Rational Unified Process (RUP) for the educational environment. Many artifacts derived from a project case study are used as examples or templates. The content of the course is oriented towards the cognitive skills needed to perform the various activities required in the software process.

The presence of a solid architectural vision is a key discriminator in the success or failure of a software project. This tutorial examines what software architecture is and what it is not. It discusses and illustrates how to describe architecture through a set of design viewpoints and views and how to express these views in UML (Rumbaugh et al., 1998), in the spirit of the new IEEE Standard: Recommended practice for architectural description. The tutorial shows of how architectures drive the development process and how to capture architectural design patterns using UML (Unified Modeling Language). It is illustrated by several widely applicable architectural patterns in different domains.

ARCADE is a research project in computer architecture. We first discuss its motivations and goals, wich are primarily the design of a dynamically adaptive system, and the use of performance evaluation methods as a design tool. The resulting system is intended to serve as a support for education in computer architecture and operating systems. Then, we present the overall structure of the system, and finally, we consider in more detail hardware tools that will be provided for the dynamic adaptation to varying load conditions.