Resolving merge conflicts manually is a tedious and complex task. While automated approaches exist, many challenges persist. One promising yet underexplored solution is the use of search-based optimization algorithms, which require an evaluation function to measure the quality of intermediary solutions. However, using code compilation and test execution for this purpose is computationally expensive. This study investigates the relationship between conflict resolutions and conflicting content to identify a metric for guiding search-based optimization techniques. We analyzed 9,998 conflict chunks from 1,062 open source projects, focusing on the similarity of resolutions to their parents and the correlation between randomly generated candidates, parent versions, and the resolution. Our findings reveal that conflict resolutions are, on average, 70% similar to both parents. A strong median correlation ( \(\rho=0.791\) ) exists between candidate-parent and candidate-resolution similarities when aggregating parent similarities with the mean function. Based on these findings, we propose and evaluate SBCR, a Search-Based Conflict Resolution approach that uses parent similarity as a guiding function. We found that the resolution candidates generated by SBCR have a median of 86.5% similarity to the expected resolution, achieving 100% of similarity in 25.2% of the conflicts.

Existing commercial and in-house software development tools are often inaccessible to blind and low vision software professionals (BLVSPs), hindering their participation and career growth at work.Building on existing research on Do-It-Yourself (DIY) assistive technologies and customized tools made by programmers, we shed light on the currently unexplored intersection of how DIY tools built and used by BLVSPs support accessible software development.Through semi-structured interviews with 30 BLVSPs, we found that such tools serve many diferent purposes and are driven by motivations such as desiring to maintain a professional image and a sense of dignity at work.These tools had signifcant impacts on workplace accessibility and revealed a need for a more centralized community for sharing tools, tips, and tricks.Based on our fndings, we introduce the "Double Hacker Dilemma" and highlight a need for developing more efective peer and organizational platforms that support DIY tool sharing.

Team projects are an essential part of any software engineering program, and are known to help students in learning the primary course materials while imparting valuable teamwork skills. At the same time, teamwork can also present challenges, to both students and their instructors. Well-known problems include teams not following recommended practices (e.g., producing deliverables out of order or at the last minute) and problematic team dynamics interfering with progress (e.g., social loafing or last-minute heroes). This paper presents TeamCAST, a tool we designed to address both kinsd of problems. The key idea underneath TeamCAST is that, by tapping into the intermediate work that students produce as part of their projects, it becomes possible to gain insight into both team progress and contributions. TeamCAST is designed to provide an easy-to-use platform for students to submit such intermediate work and for instructors to monitor the ongoing projects in an intuitive dashboard. This experience report introduces the primary design decisions underlying TeamCAST and presents the results of an exploratory pilot use in a 179 student software design class.

Teamwork is beneficial for students' learning experiences. However, inherent challenges persist, including free-riding, conflicts, and communication issues. To tackle these issues, the use of peer assessment has been widely advocated, and practiced. For various reasons, however, peer assessment tends to be performed infrequently, limiting its utility for instructors to detect issues in, and intervene with, student teams during a course. One reason is that existing tools do not present peer assessment results over time, not for individual team members, nor for teams as a whole. In this experience report, we introduce a new dashboard that is specifically designed to address time, and report and reflect on the experiences of three instructors who used the dashboard to monitor teams in their courses and intervene when they thought it was necessary.

As GenAI becomes embedded in developer toolchains and practices, and routine code is increasingly generated, human creativity will be increasingly important for generating competitive advantage. This article uses the McLuhan tetrad alongside scenarios of how GenAI may disrupt software development more broadly, to identify potential impacts GenAI may have on creativity within software development. The impacts are discussed along with a future research agenda comprising five connected themes that consider how individual capabilities, team capabilities, the product, unintended consequences, and society can be affected.

Scholars have investigated numerous barriers to accessible software development tools and processes for Blind and Low Vision (BLV) developers. However, the research community has yet to study the accessibility of software development meetings, which are known to play a crucial role in software development practice. We conducted semi-structured interviews with 26 BLV software professionals about software development meeting accessibility. We found four key themes related to in-person and remote software development meetings: (1) participants observed that certain meeting activities and software tools used in meetings were inaccessible, (2) participants performed additional labor in order to make meetings accessible, (3) participants avoided disclosing their disability during meetings due to fear of career repercussions, (4) participants suggested technical, social and organizational solutions for accessible meetings, including developing their own solutions. We suggest recommendations and design implications for future accessible software development meetings including technical and policy-driven solutions.

In this paper, we use the lens of co-creation---a concept originally coined and applied in the fields of management and design that denotes how groups of people collaboratively create something of meaning through an orchestration of people, activities, and tools---to study how fully remote software teams co-create digital artifacts that can be considered as a form of documentation. We report on the results of a qualitative, interview-based study with 25 software professionals working in remote teams. Our primary findings are the definition of four models of co-creation, examples of sequencing these models into work chains to produce artifacts, factors that influence how developers match tasks to models and chains, and insights into tool support for co-creation. Together, our findings illustrate how co-creation is an intentional activity that has a significant role in how remote software teams' choose to structure their collaborative activities.

A type of meeting that has been understudied in the software engineering literature to date is what we term the software maintenance meeting: a regularly scheduled team meeting in which emergent issues are addressed that are usually out of scope of the daily stand-up but not necessarily challenging enough to warrant an entirely separate meeting. These meetings tend to discuss a wide variety of topics and are crucial in keeping software development projects going, but little is known about these meetings and how they proceed. In this paper, we report on a single exploratory case study in which we analyzed ten consecutive maintenance meetings from a major healthcare software provider. We analyzed what kind of information is brought into the discussions held in these meetings and how, what outcomes arose from the discussions, and what information was captured for downstream use. Our findings are varied, giving rise to both practical considerations for those conducting these kinds of meetings and new research directions toward further understanding and supporting them.

Network Analysis has traditionally been applied to analyzing interactions among learners in online learning platforms such as discussion boards. However, there are opportunities to bring Network Analysis to bear on networks representing learners' mental models of course material, rather than learner interactions. This paper describes the construction and analysis of collaborative educational networks based on concept maps created by undergraduates. Concept mapping activities were deployed throughout two separate quarters of a large General Education (GE) course about sustainability and technology at a large university on the West Coast of the United States. A variety of Network Analysis metrics are evaluated on their ability to predict an individual learner's understanding based on that learner's contributions to a network representing the collective understanding of all learners in the course. Several of the metrics significantly correlated with learner performance, especially those that compare an individual learner's conformity to the larger group's consensus. The novel network metrics based on collective networks of learner concept maps are shown to produce stronger and more reproducible correlations with learner performance than metrics traditionally used in the literature to evaluate concept maps. This paper thus demonstrates that Network Analysis in conjunction with collective networks of concept maps can provide insights into learners' conceptual understanding of course material.

Software engineers exhibit higher burnout and suicide rates compared to many other information workers. Consequently, mental wellbeing is a growing concern to technology organizations. To better understand the challenges of supporting mental wellbeing in the context of the work of software engineering, we conducted 14 interviews with software engineers. We examine the different aspects of their lived experiences with mental wellbeing at work, their strategies for managing mental wellbeing, the challenges they face in using these strategies, and recommendations they have for mental wellbeing technologies. We contribute to the HCI literature by discussing how mental wellbeing should be considered within the context of work across individual, team, and organization levels, and highlight the need for integrating mental wellbeing into the technologies employees use at work.

Team-based projects are common in many software engineering classes, but come with a host of well-known problems such as social loafing, free-riding, and undesirable team dynamics. To counter these issues, many instructors use peer assessment. Unfortunately, current peer assessment approaches exhibit several limitations, including a typically time-consuming evaluation process, feedback being too infrequent or too late to make a difference for the project, and student ratings being unreliable. In this paper, we introduce the Daily Smirk, a preliminary prototype of a new peer assessment tool that is based on three primary design decisions: (1) peer assessment is continuous throughout the project, (2) assessment is through a lightweight smiley-based rating system, and (3) assessment is normalized around a neutral state so that additional feedback is only needed for outlier ratings. We elaborate on the design of the Daily Smirk and its primary functionality, and report on a preliminary evaluation in a software design course with three team-based projects.

Meetings are a frequent part of life for a software developer. Software design is often performed, discussed, and reviewed in these meetings. This means that meetings may contain important design information that could be captured for later use. Meeting design tools may be a way to capture design information as a byproduct of discussion that arises in these meetings. In this paper, we identify a list of key meeting support tool features that could support the capture and retrieval of design information and compare these to features currently offered in commercial meeting support tools.

The whiteboard plays a crucial role in the day-to-day lives of software architects, as they frequently will organize meetings at the whiteboard to discuss a new architecture, some proposed changes to an existing architecture, a mismatch between a prescribed architecture and its code, and more. While much has been studied about software architects, the architectures they produce, and how they produce them, a detailed understanding of these whiteboards meetings is still lacking. In this paper, we contribute a mixed-methods study involving semi-structured interviews and a subsequent survey to understand the perceptions of software architects on whiteboard architecture meetings. We focus on four aspects: (1) why do they hold these meetings, (2) what is the impact of the experience levels of the participants in these meetings, (3) how do the architects document the meetings, and (4) what kinds of changes are made in downstream activities to the work produced after the meetings have concluded? In studying these aspects, we identify eleven observations related to both technical aspects and social aspects of the meetings. These insights have implications for further research, offer concrete advice to practitioners, and suggest ways of educating future software architects.

When multiple developers change a software system in parallel, these concurrent changes need to be merged to all appear in the software being developed. Numerous merge techniques have been proposed to support this task, but none of them can fully automate the merge process. Indeed, it has been reported that as much as 10 to 20 percent of all merge attempts result in a merge conflict, meaning that a developer has to manually complete the merge. To date, we have little insight into the nature of these merge conflicts. What do they look like, in detail? How do developers resolve them? Do any patterns exist that might suggest new merge techniques that could reduce the manual effort? This paper contributes an in-depth study of the merge conflicts found in the histories of 2,731 open source Java projects. Seeded by the manual analysis of the histories of five projects, our automated analysis of all 2,731 projects: (1) characterizes the merge conflicts in terms of number of chunks, size, and programming language constructs involved, (2) classifies the manual resolution strategies that developers use to address these merge conflicts, and (3) analyzes the relationships between various characteristics of the merge conflicts and the chosen resolution strategies. Our results give rise to three primary recommendations for future merge techniques, that - when implemented - could on one hand help in automatically resolving certain types of conflicts and on the other hand provide the developer with tool-based assistance to more easily resolve other types of conflicts that cannot be automatically resolved.

Traditional forms of Crowdsourcing such as open source software development harness crowd contributions to democratize the creation of software. However, potential contributors must first overcome joining barriers forcing casually committed contributors to spend days or weeks onboarding and thereby reducing participation. To more effectively harness potential contributions from the crowd, we propose a method for programming in which work occurs entirely through microtasks, offering contributors short, self-contained tasks such as implementing part of a function or updating a call site invoking a function to match a change made to the function. In microtask programming, microtasks involve changes to a single artifact, are automatically generated as necessary by the system, and nurture quality through iteration. A study examining the feasibility of microtask programming to create small programs found that developers were able to complete 1008 microtasks, onboard and submit their first microtask in less than 15 minutes, complete all types of microtasks in less than 5 minutes on average, and create 490 lines of code and 149 unit tests. The results demonstrate the potential feasibility as well as revealing a number of important challenges to address to successfully scale microtask programming to larger and more complex programs.

Background Open source software projects show gender bias suggesting that other demographic characteristics of developers, like geographical location, can negatively influence evaluation of contributions too. Aim This study contributes to this emerging body of knowledge in software development by presenting a quantitative analysis of the relationship between the geographical location of developers and evaluation of their contributions on GitHub. Method We present an analysis of 70,000+ pull requests selected from 17 most actively participating countries to model the relationship between the geographical location of developers and pull request acceptance decision. Results and Conclusion We observed structural differences in pull request acceptance rates across 17 countries. Countries with no apparent similarities such as Switzerland and Japan had one of the highest pull request acceptance rates while countries like China and Germany had one of the lowest pull request acceptance rates. Notably, higher acceptance rates were observed for all but one country when pull requests were evaluated by developers from the same country.

Sometimes, when programmers use a search engine they know more or less what they need. Other times, programmers use the search engine to look around and generate possible ideas for the programming problem they are working on. The key insight we explore in this paper is that the results found in the latter case tend to serve as inspiration or triggers for the next queries issued. We introduce two search engines, CodeExchange and CodeLikeThis, both of which are specifically designed to enable the user to directly leverage the results in formulating the next query. CodeExchange does this with a set of four features supporting the programmer to use characteristics of the results to find other code with or without those characteristics. CodeLikeThis supports simply selecting an entire result to find code that is analogous, to some degree, to that result. We evaluated how these approaches were used along with two approaches not explicitly supporting iteration, a baseline and Google, in a user study among 24 developers. We find that search engines that support using results to form the next query can improve the programmers’ search experience and different approaches to iteration can provide better experiences depending on the task.

One form of crowdsourcing is the competition, which poses an open call for competing solutions. Commercial systems such as TopCoder have begun to explore the application of competitions to software development, but have important limitations diminishing the potential benefits drawn from the crowd. In particular, they employ a model of independent work that ignores the opportunity for designs to arise from the ideas of multiple designers. In this paper, we examine the potential for software design competitions to incorporate recombination, in which competing designers are given the designs of others and encouraged to use them to revise their own designs. To explore this, we conducted two software design competitions in which participants were asked to produce both an initial and a revised design, drawing on lessons learned from the crowd. We found that, in both competitions, all participants borrowed ideas and most improved the quality of their designs. Our findings demonstrate the potential benefits of recombination in software design and suggest several ways in which software design competitions can be improved.

Crowdsourcing has had extraordinary success in solving a diverse set of problems, ranging from digitization of libraries and translation of the Internet, to scientific challenges such as classifying elements in the galaxy or determining the 3D shape of an enzyme. By leveraging the power of the masses, it is feasible to complete tasks in mere days and sometimes even hours, and to take on tasks that were previously impossible because of their sheer scale. Underlying the success of crowdsourcing is a common theme - the microtask. By breaking down the overall task at hand into microtasks providing short, self-contained pieces of work, work can be performed independently, quickly, and in parallel - enabling numerous and often untrained participants to chip in. This paper puts forth a research agenda, examining the question of whether the same kinds of successes that microtask crowdsourcing is having in revolutionizing other domains can be brought to software development. That is, we ask whether it is possible to push well beyond the open source paradigm, which still relies on traditional, coarse-grained tasks, to a model in which programming proceeds through microtasks performed by vast numbers of crowd developers.

Programming today regularly involves searching for source code online, whether through a general search engine such as Google or a specialized code search engine such as SearchCode, Ohloh, or GitHub. Searching typically is an iterative process, with developers adjusting the keywords they use based on the results of the previous query. However, searching in this manner is not ideal, because just using keywords places limits on what developers can express as well as the overall interaction that is required. Based on the observation that the results from one query create a con-text in which a next is formulated, we present CodeExchange, a new code search engine that we developed to explicitly leverage this context to support fluid, expressive reformulation of queries. We motivate the need for CodeExchange, highlight its key design decisions and overall architecture, and evaluate its use in both a field deployment and a laboratory study.

To date, most dedicated code search engines use ranking algorithms that focus only on the relevancy between the query and the results. In practice, this means that a developer may receive search results that are all drawn from the same project, all implement the same algorithm using the same external library, or all exhibit the same complexity or size, among other possibilities that are less than ideal. In this paper, we propose that code search engines should also locate both diverse and concise (brief but complete) sets of code results. We present four novel algorithms that use relevance, diversity, and conciseness in ranking code search results. To evaluate these algorithms and the value of diversity and conciseness in code search, twenty-one professional programmers were asked to compare pairs of top ten results produced by competing algorithms. We found that two of our new algorithms produce top ten results that are strongly preferred by the programmers.

Programming work is inherently interdependent, requiring developers to share and coordinate decisions that crosscut the structure of code. This is particularly challenging for programming in a microtasking context, in which developers are assumed to be transient and thus cannot rely on traditional learning and coordination mechanisms such as an extended onboarding process and code ownership. In this paper, we explore scaffolding coordination and knowledge sharing through a question and answer system, structuring project knowledge and coordination into questions and answers. To investigate its potential for enabling coordination in a microtask setting, we implemented a Q&A system for microtask programming work and conducted a user study where a crowd used it to coordinate their work on a software project over a 30-hour period. The results reveal both the potential for the use of Q&A systems for within project coordination and challenges that this approach brings.

Whiteboard sketches play a crucial role in software development, helping to support groups of designers in reasoning about a software design problem at hand. However, little is known about these sketches and how they support design ‘in the moment’, particularly in terms of the relationships among sketches, visual syntactic elements within sketches, and reasoning activities. To address this gap, we analyzed 14 hours of design activity by eight pairs of professional software designers, manually coding over 4000 events capturing the introduction of visual syntactic elements into sketches, focus transitions between sketches, and reasoning activities. Our findings indicate that sketches serve as a rich medium for supporting design conversations. Designers often use general-purpose notations. Designers introduce new syntactic elements to record aspects of the design, or re-purpose sketches as the design develops. Designers constantly shift focus between sketches, using groups of sketches together that contain complementary information. Finally, sketches play an important role in supporting several types of reasoning activities (mental simulation, review of progress, consideration of alternatives). But these activities often leave no trace and rarely lead to sketch creation. We discuss the implications of these and other findings for the practice of software design at the whiteboard and for the creation of new electronic software design sketching tools.

Whiteboards serve an important role in supporting informal design, providing a fluid and flexible medium for collaborative design. Interactive whiteboards offer the potential for enhanced support for manipulating content, managing sketches, and distributed work, but little is known about how this support affects the practice of informal design. To understand the opportunities and challenges, we first conducted a literature review, identifying 14 behaviors that occur during informal design. We then designed an interactive whiteboard system to support all of these behaviors and deployed the system to three groups of designers. Through usage logs and interviews, we examined the effects of interactivity on whiteboard use across a wide spectrum of design behaviors, identifying ways in which interactive whiteboards support the practices used in physical whiteboards and where they enable designers to work more effectively.

Microtask crowdsourcing organizes complex work into workflows, decomposing large tasks into small, relatively independent microtasks. Applied to software development, this model might increase participation in open source software development by lowering the barriers to contribu-tion and dramatically decrease time to market by increasing the parallelism in development work. To explore this idea, we have developed an approach to decomposing programming work into microtasks. Work is coordinated through tracking changes to a graph of artifacts, generating appropriate microtasks and propagating change notifications to artifacts with dependencies. We have implemented our approach in CrowdCode, a cloud IDE for crowd development. To evaluate the feasibility of microtask programming, we performed a small study and found that a small crowd of 12 workers was able to successfully write 480 lines of code and 61 unit tests in 14.25 person-hours of time.

Bug triaging is an important activity in any software development project. It involves developers working through the set of unassigned bugs, determining for each of the bugs whether it represents a new issue that should receive attention, and, if so, assigning it to a developer and a milestone. Current tools provide only minimal support for bug triaging and especially break down when developers must triage a large number of bug reports, since those reports can only be viewed one-by-one. This paper presents PorchLight, a novel tool that uses tags, attached to individual bug reports by queries expressed in a specialized bug query language, to organize bug reports into sets so developers can explore, work with, and ultimately assign bugs effectively in meaningful groups. We describe the challenges in supporting bug triaging, the design decisions upon which PorchLight rests, and the technical aspects of the implementation. We conclude with an early evaluation that involved six professional developers who assessed PorchLight and its potential for their day-to-day triaging duties.

The use of a studio approach - a hands-on teaching method that emphasizes in-class discussion and activities - is becoming an increasingly accepted method of teaching within software engineering. In such studios, emphasis is placed not only on the artifacts to be produced, but also on the process used to arrive at those artifacts. In this paper, we introduce Calico, a sketch-based collaborative software design tool, and discuss how it supports the delivery of a studio approach to software design education. We particularly describe our experiences with Calico in Software Design I, a course aimed at introducing students to the early, creative phases of software design. Our results show that Calico enabled students to work effectively in teams on their design problems, quickly developing, refining, and evaluating their designs.

While many software design tools exist and are in use daily, when faced with a design problem, developers will more often then not turn to the whiteboard to work on potential solutions. It has been observed that the sketches that software engineers create in this process transition from quite informal, rough sketches to sketches that reflect design notations like UML diagrams or user interfaces with quite precise layout and content. This behavior leads to an interesting opportunity: what if, during this refinement phase, it becomes possible for a whiteboard sketching tool to insert lightweight analyses that provide the developer with feedback about their design at hand? This paper investigates this opportunity, particularly focusing on exploring whether it might be possible to add a lightweight analysis and feedback mechanism to one sketching tool, Calico, that gives the designer insight into the perceived performance of their application.

The earlier a conflict is detected, the easier it is to resolve-this is the main precept of workspace awareness. Workspace awareness seeks to provide users with information of relevant ongoing parallel changes occurring in private workspaces, thereby enabling the early detection and resolution of potential conflicts. The key approach is to unobtrusively inform developers of potential conflicts arising because of concurrent changes to the same file and dependency violations in ongoing parallel work. This paper describes our research goals, approach, and implementation of workspace awareness through Palantír and includes a comprehensive evaluation involving two laboratory experiments. We present both quantitative and qualitative results from the experiments, which demonstrate that the use of Palantír, as compared to not using Palantír 1) leads to both earlier detection and earlier resolution of a larger number of conflicts, 2) leaves fewer conflicts unresolved in the code base that was ultimately checked in, and 3) involves reasonable overhead. Furthermore, we report on interesting changes in users' behavior, especially how conflict resolution strategies changed among Palantír users.

While code is typically presented as a flat file to a developer who must change it, this flat file exists within a context that can drastically influence how a developer approaches changing it. While the developer clearly must be careful changing any code, they probably should be yet more careful in changing code that recently saw major changes, is barely covered by test cases, and was the source of a number of bugs. Contextualized coding refers to the ability of the developer to effectively use such contextual information while they work on some changes. In this paper, we introduce the Code Orb, a contextualized coding tool that builds upon existing mining and analysis techniques to warn developers on a line-by-line basis of the volatility of the code they are working on. The key insight underneath the Code Orb is that it is neither desired nor possible to always present a code's context in its entirety; instead, it is necessary to provide an abstracted view of the context that informs the developer of which parts of the code they need to pay more attention to. This paper discusses the principles of and rationale behind contextualized coding, introduces the Code Orb, and illustrates its function with example code and context drawn from the Mylyn [11] project.

Software designers frequently sketch when they design, particularly during the early phases of exploration of a design problem and its solution. In so doing, they shun formal design tools, the reason being that such tools impose conformity and precision prematurely. Sketching on the other hand is a highly fluid and flexible way of expressing oneself. In this paper, we present Calico, a sketch-based distributed software design tool that supports software designers with a variety of features that improve over the use of just pen-and-paper or a regular whiteboard, and are tailored specifically for software design. Calico is meant to be used on electronic whiteboards or tablets, and provides for rapid creation and manipulation of design content by sets of developers who can collaborate distributedly.

Modeling tools are often not used for tasks during the software lifecycle for which they should be more helpful; instead free-from approaches, such as office tools and white boards, are frequently used. Prior workshops explored why this is the case and what might be done about it. The goal of this workshop is to continue those discussions and also to form an initial set of challenge problems and research challenges that researchers and developers of flexible modeling tools should address.

Modeling tools are often not used for tasks during the software lifecycle for which they should be helpful; more free-from approaches, such as office tools and white boards, are frequently used instead. Why is this? What might be done to make modeling tools more suitable? What key research challenges must be overcome to achieve this? The goal of this workshop is to bring together people who understand the activities and needs of developers and other stakeholders throughout the software lifecycle, user interface design and tool infrastructure to explore these questions.

Despite the availability of a host of software design notations and associated tools, software developers are known to frequently turn to the whiteboard when faced with a specific design problem. There, they typically engage in an informal form of software design that relies heavily on sketching. However, whereas whiteboards afford flexibility and fluidity, they at the same time limit a designer in only being able to draw and erase content. This paper presents Calico, a novel software design tool that leverages electronic whiteboards to enhance the design experience with explicit support for the creative, exploratory aspects of design. Specifically, Calico offers a grid, scraps, and a palette together with gesture-based input to address several natural behaviors exhibited by software designers, including frequent shifts in focus, use of low-detail models, and use of a mix of notations. To evaluate Calico, we performed a laboratory experiment involving eight pairs of graduate students and collected and analyzed six corporate design sessions that employed Calico. Results are promising and indicate the benefits of Calico, while they at the same time highlight several ways in which it can be enhanced.

Supporting developers in examining and evolving a software system in terms of concerns is considered a critical capability in the face of the scale and complexity of today's software. A number of existing approaches make an inroad to providing this support, but they fall short in key ways. This paper introduces ArchEvol, a new programming environment that embodies a new kind of approach, one we term explicit concern-driven development. The vision is threefold: (1) a fine-grained concern model maps concerns to code, (2) concerns are visualized at both the code level, to assist in the actual act of making changes, and the architectural level, to assist in gauging levels of scattering and tangling, and (3) automated support assists developers in maintaining the concern mapping over time. Developers, then, continuously examine, structure, and modify the software they produce in terms of concerns. We introduce our approach, discuss how we have realized it in ArchEvol, and present the results of a first set of evaluations that demonstrate its potential.

In this paper, we report on our experience in designing and deliv-ering two new software design courses in the Informatics major at UC Irvine. When the major was created in 2004, it explicitly con-tained slots for two software design courses to be created from the ground up. The authors led this effort, focusing one course on the topic of system design and one course on the topic of implementation design. We discuss the philosophy and pedagogy behind the courses, present key class activities, and reflect on having offered each course twice over the past two years.

In this paper, we describe a multi-site evaluation of SimSE, an educational software engineering simulation game. This study was designed to build on our previous experience of evaluating SimSE in courses and controlled lab settings at UC Irvine, in order to validate our findings and discover any factors that come into play when SimSE is used in other institutions. The study consisted of three different universities using SimSE in their respective courses and reporting the results to us. The results confirmed several of our previous findings, as well as highlighted a number of critical considerations that must be taken into account when using SimSE in a course.

Design is an inherently creative process, particularly so during the early stages of design when a solution is just beginning to form. At this time, the more formal models and modeling languages to which we are so accustomed in software engineering serve a limited if non-existent role. But this does not mean that modeling is not relevant during early design; on the contrary, it is critical. It is just that a different form of modeling and overall design process takes place. In this paper, we present early results from our foray into exploring how designers can be supported in the early, highly creative stages of software design. We particularly build upon the existing body of work in creativity and general design, and apply key lessons found there to the construction of Calico, a prototype sketching tool for modeling in early design.

In this paper, we present results from our empirical evaluations of a workspace awareness tool that we designed and implemented to augment the functionality of software configuration management systems. Particularly, we performed two user experiments directed at understanding the effectiveness of a workspace awareness tool in improving coordination and reducing conflicts. In the first experiment, we evaluated the tool through text-based assignments to avoid interference from the well-documented impact of individual differences among participants, as these differences are known to lessen the observable effect of proposed tools or to lead to them having no observable effect at all. This strategy of evaluating an application in a domain that is known to have less individual differences is novel and in our case particularly helpful in providing baseline quantifiable results. Upon this baseline, we performed a second experiment, with code-based assignments, to validate that the tool's beneficial effects also occur in the case of programming. Together, our results provide quantitative evidence of the benefits of workspace awareness in software configuration management, as we demonstrate that it improves coordination and conflict resolution without inducing significant overhead in monitoring awareness cues.

Software engineering educational approaches are often evaluated only anecdotally, or in informal pilot studies. We describe a more comprehensive approach to evaluating a software engineering educational technique (SimSE, a graphical, interactive, customizable, game-based software engineering simulation environment). Our method for evaluating SimSE went above and beyond anecdotal experience and approached evaluation from a number of different angles through a family of studies designed to assess SimSE's effectiveness and guide its development. In this paper, we demonstrate the insights and lessons that can be gained when using such a multi-angled evaluation approach. Our hope is that, from this paper, educators will: (1) learn ideas about how to more comprehensively evaluate their own approaches, and (2) be provided with evidence about the educational effectiveness of SimSE.

The essence of any modeling approach for product line architectures lies in its ability to express variability. Existing approaches do so by explicitly specifying variation points inside the architectural specification of the entire product line, usually with optional and alternative elements of some form. This, however, leads to a sizable mismatch between conceptual variability (i.e., the features through which architects logically view and interpret differences in product architectures) and actual variability (i.e., the modeling constructs through which the logical differences must be expressed). We contribute a new product line architecture modeling approach that unites the two. Our approach uses change sets to group related architectural differences and relationships to govern which change set combinations are valid when composed into a particular product architecture. The result lifts modeling of variability out of modeling architectural structure, consolidates related variation points, and explicitly and separately manages their compatibilities.

Workspace awareness techniques have been proposed to enhance the effectiveness of software configuration management systems in coordinating parallel work. These techniques share information regarding ongoing changes, so potential conflicts can be detected during development, instead of when changes are completed and committed to a repository. To date, however, workspace awareness techniques only address direct conflicts, which arise due to concurrent changes to the same artifact, but are unable to support indirect conflicts, which arise due to ongoing changes in one artifact affecting concurrent changes in an-other artifact. In this paper, we present a new, cross-workspace awareness technique that supports one particular kind of indirect conflict, namely those indirect conflicts caused by changes to class signatures. We introduce our approach, discuss its implementation in our workspace awareness tool Palantír, illustrate its potential through two pilot studies, and lay out how to generalize the technique to a broader set of indirect conflicts

Workspace awareness has emerged as a new coordination paradigm in configuration management, enabling early detection of potential conflicts by providing developers with information of relevant, parallel activities. The focus of our work is on detecting and mitigating direct and indirect conflicts by sharing information about ongoing code changes. In this paper, we discuss the results of user experiments designed as a broad and formative evaluation of workspace awareness, specifically focusing on whether users detect conflicts as they arise and act to mitigate potential problems. Our results confirm that workspace awareness promotes active self-coordination among users and can lead to an improved end-product in terms of the number of unresolved conflicts remaining in the code.

Management of shared artifacts is critical to ensure the correct integration and behavior of code created by multiple teams working in concert. Awareness of inter-team development activities and their effects on shared artifacts provides developers the opportunity to detect potential integration problems earlier and take proactive steps to avoid these conflicts. However, current awareness tools do not provide such kinds of awareness making them unsuitable for global software development. In this paper, we discuss their drawbacks, present three strategies to make them suitable for global settings, and illustrate these strategies through a new view for Palantir that better addresses awareness in the large

Traditional techniques of traceability detection and management are not equipped to handle evolution. This is a problem for the field of software architecture, where it is critical to keep synchronized an evolving conceptual architecture with its realization in an evolving code base. ArchTrace is a new tool that addresses this problem through a policy-based infrastructure for automatically updating traceability links every time an architecture or its code base evolves. ArchTrace is pluggable, allowing developers to choose a set of traceability management policies that best match their situational needs and working styles. We discuss ArchTrace, its conceptual basis, its implementation, and our evaluation of its strengths and weaknesses in a retrospective analysis of data collected from a 20 month period of development of Odyssey, a large-scale software development environment. Results are promising: with respect to the ideal set of traceability links, the policies applied resulted in 95% precision at 89% recall

Software product line architectures (PLAs) have been widely recognized as a successful approach in industrial software development for improving productivity, software quality and time-to-market. In this paper, we focus on the usage of a PLA for a quite different purpose, namely, handling privacy constraints in Web personalization. To provide personalized services such as customized recommendations, a personalized Website collects users' personal data, which raises various privacy concerns. We aim at reconciling the benefits of web personalization with privacy constraints that come from users themselves as well as from privacy legislations and regulations that apply to a given user. We propose a dynamic, privacy-enabling personalization infrastructure and conceive it as a PLA. This infrastructure allows for dynamically selecting and instantiating personalization architectures that provide personalized services to each individual user and comply with the prevailing privacy constraints.

Simulation is an educational tool that is commonly used to teach processes that are infeasible to practice in the real world. Software process education is a domain that has not yet taken full advantage of the benefits of simulation. To address this, we have developed SimSE, an educational, interactive, graphical environment for building and simulating software engineering processes in a game-like setting. We detail the design of SimSE, present an initial simulation model of a waterfall process that we developed, and describe an experiment that we conducted to evaluate the educational potential of SimSE and its initial model

Virtually all software engineering courses employ class projects in which students practice their newly-learned skills. By necessity, these projects tend to be of a small scale. In efforts to better educate students in the many aspects and pitfalls of the software process, different alternatives have been tried over time. In this paper, we describe one such experience in which we put all thirty-two students in the course on a single, large project and gave them the open-ended task of building a prototype of "a better software design environment. " This lead to a completely new set of dynamics and interesting opportunities to teach topics that normally would not be covered or illustrated by students' experiences in a regular software project. We introduce our course design, present its progression over the quarter, illustrate its strengths and weaknesses, and discuss critical factors for its repeatability

Software engineering (SE) is very different in focus from traditional computer science: it is not just about computers and software, but as much about the context in which they are used. This means we must teach about software and information, development and design, technical and social issues, while creating solutions as well as understanding and analyzing them. In effect, we must teach a discipline broader than SE or CS alone for SE education to be effective. At UC Irvine, we designed and now offer a program doing just this -- a four-year B.S. degree in Informatics. The major brings topics in SE together with human-computer interaction, computer-supported collaborative work, social analysis, and management, along with other application disciplines. Here, we discuss the philosophy behind the major, its structure, and the questions concerning SE education that the new major raises.

In this poster we describe the diversification of our undergraduate curricula in the computing disciplines at UC Irvine, in particular the creation of Bachelor of Science degree in Informatics.

Because the field of computer science has broadened so much in recent years, traditional degree programs are becoming crowded with new courses, each introducing its own "essential" topic. However, with more and more such courses, it is no longer possible to cover every topic in a single, coherent, four-year program. Many alternative approaches are available to address this situation. At UC Irvine, we have chosen a solution in which we offer four coordinated degree programs: a B.S. in Computer Science & Engineering, a conventional B.S. in Computer Science, a new B.S. in Informatics, and a broad overview B.S. in Information and Computer Science. Of these, the B.S. in Informatics is the most innovative, focusing on software and information design. Context plays a particularly strong role in our B.S. in Informatics: Placing software development in context is critical to the delivery of successful solutions, and we educate our students accordingly. We present our definition of informatics, detail our curriculum, describe its pedagogical characteristics and objectives, and conclude with some critical observations regarding informatics and its place in computer science education.

Research over the past decade has revealed that modeling software architecture at the level of components and connectors is useful in a growing variety of contexts. This has led to the development of a plethora of notations for representing software architectures, each focusing on different aspects of the systems being modeled. In general, these notations have been developed without regard to reuse or extension. This makes the effort in adapting an existing notation to a new purpose commensurate with developing a new notation from scratch. To address this problem, we have developed an approach that allows for the rapid construction of new architecture description languages (ADLs). Our approach is unique because it encapsulates ADL features in modules that are composed to form ADLs. We achieve this by leveraging the extension mechanisms provided by XML and XML schemas. We have defined a set of generic, reusable ADL modules called xADL 2.0, useful as an ADL by itself, but also extensible to support new applications and domains. To support this extensibility, we have developed a set of reflective syntax-based tools that adapt to language changes automatically, as well as several semantically-aware tools that provide support for advanced features of xADL 2.0. We demonstrate the effectiveness, scalability, and flexibility of our approach through a diverse set of experiences. First, our approach has been applied in industrial contexts, modeling software architectures for aircraft software and spacecraft systems. Second, we show how xADL 2.0 can be extended to support the modeling features found in two different representations for modeling product-line architectures. Finally, we show how our infrastructure has been used to support its own development. The technical contribution of our infrastructure is augmented by several research contributions: the first decomposition of an architecture description language into modules, insights about how to develop new language modules and a process for integrating them, and insights about the roles of different kinds of tools in a modular ADL-based infrastructure.

Software Configuration Management (SCM) is an important discipline in professional software development and maintenance. The importance of SCM has increased as programs have become larger, more long lasting, and more mission and life critical. This article discusses the evolution of SCM technology from the early days of software development to the present, with a particular emphasis on the impact that university and industrial research has had along the way. Based on an analysis of the publication history and evolution in functionality of the available SCM systems, we trace the critical ideas in the field from their early inception to their eventual maturation in commercially and freely available SCM systems. In doing so, this article creates a detailed record of the critical value of SCM research and illustrates how research results have shaped the functionality of today's SCM systems.

Building a configuration management (CM) system is a difficult endeavor that regularly requires tens of thousands of lines of code to be written. To reduce this effort, several experimental infrastructures have been developed that provide reusable repositories upon which to build a CM system. In this paper, we push the idea of reusability even further. Whereas existing infrastructures only reuse a generic CM model (i.e., the data structures used to capture the evolution of artifacts), we have developed an experimental infrastructure, called MCCM, that additionally allows reuse of CM policies (i.e., the rules by which a user evolves artifacts stored in a CM system). The key contribution underlying MCCM is that a CM policy is not a monolithic entity; instead, it can be composed from small modules that each addresses a unique dimension of concern. Using the pluggable architecture and base set of modules of MCCM, then, the core of a desired new CM system can be rapidly composed by choosing appropriate existing modules and implementing any remaining modules only as needed. We demonstrate our approach by showing how the use of MCCM significantly reduces the effort involved in creating several representative CM systems.

No abstract available.

As with any other artifact produced as part of the software life cycle, software architectures evolve and this evolution must be managed. One approach to doing so would be to apply any of a host of existing configuration management systems, which have long been used successfully at the level of source code. Unfortunately, such an approach leads to many problems that prevent effective management of architectural evolution. To overcome these problems, we have developed an alternative approach centered on the use of an integrated architectural and configuration management system model. Because the system model combines architectural and configuration management concepts in a single representation, it has the distinct benefit that all architectural changes can be precisely captured and clearly related to each other---both at the fine-grained level of individual architectural elements and at the coarse-grained level of architectural configurations. To support the use of the system model, we have developed Mae, an architectural evolution environment through which users can specify architectures in a traditional manner, manage the evolution of the architectures using a check-out/check-in mechanism that tracks all changes, select a specific architectural configuration, and analyze the consistency of a selected configuration. We demonstrate the benefits of our approach by showing how the system model and its accompanying environment were used in the context of several representative projects.

The typical software engineering course consists of lectures in which concepts and theories are conveyed, along with a small "toy" software engineering project which attempts to give students the opportunity to put this knowledge into practice. Although both of these components are essential, neither one provides students with adequate practical knowledge regarding the process of software engineering. Namely, lectures allow only passive learning, and projects are so constrained by the time and scope requirements of the academic environment that they cannot be large enough to exhibit many of the phenomena occurring in realworld software engineering processes. To address this problem, we have developed Problems and Programmers, an educational card game that simulates the software engineering process and is designed to teach those process issues that are not sufficiently highlighted by lectures and projects. We describe how the game is designed, the mechanics of its game play, and the results of an experiment we conducted involving students playing the game.

Problems and Programmers is an educational card game that we have developed to help teach software engineering. It is based on the observation that students, in a typical software engineering course, gain little practical experience in issues regarding the software process. The underlying problem is time: any course faces the practical constraint of only being able to involve students in at most a few small software development projects. Problems and Programmers overcomes this limitation by providing a simulation of the software process. In playing the game, students become aware of not only general lessons, such as the fact that they must continuously make tradeoffs among multiple potential next steps, but also specific issues such as the fact that inspections improve the quality of code but delay its delivery time. We describe game play of Problems and Programmers, discuss its underlying design, and report on the results of a small experiment in which twenty-eight students played the game.

Current configuration management systems promote workspaces that isolate developers from each other. This isolation is both good and bad It is good, because developers make their changes without any interference from changes made concurrently by other developers. It is bad, because not knowing which artifacts are changing in parallel regularly leads to problems when changes are promoted from workspaces into a central configuration management repository. Overcoming the bad isolation, while retaining the good isolation, is a matter of raising awareness among developers, an issue traditionally ignored by the discipline of configuration management. To fill this void, we have developed Palantir, a novel workspace awareness tool that complements existing configuration management systems by providing developers with insight into other workspaces. In particular, the tool informs a developer of which other developers change which other artifacts, calculates a simple measure of severity of those changes, and graphically displays the information in a configurable and generally non-obtrusive manner. To illustrate the use of Palantir, we demonstrate how it integrates with two representative configuration management systems.

The use of product lines is recognized as beneficial in promoting and structuring both component and architecture reuse throughout an organization. While the business practices of using product lines are well-understood and representations for specifying and capturing the underlying architecture of a product line are coming of age, support environments for managing the evolution of product line architecture are still lacking. In this paper, we present Menage, an environment specifically designed to alleviate this problem. Key features of Menage are its support for: (1) specifying variation points in product line architecture as optional and/or variant elements; (2) tracking the evolution of product line architecture and its constituent elements through explicit versioning techniques; and (3) selecting one or more product architectures out of overall product line architecture by applying user-specified criteria. In this paper, we introduce the approach underlying Menage, discuss its detailed functionality, and demonstrate its use with product line architecture for entertainment systems.

Abstract Software release management is the process through which software is made available to and obtained by its users. Until now, this process has been relatively straightforward. However, the emergence of component‐based software is complicating software release management. Increasingly, software is constructed via the assembly of pre‐existing, independently produced, and independently released components. Both developers and users of such software are affected by these complications. Developers need to accurately document the complex and changing dependencies among the components constituting the software. Users must be involved in locating, retrieving, and assembling components in order to appropriately bring the software into their particular environment. In this paper, we introduce the problem of release management for component‐based software and discuss SRM, a prototype software release management tool we have developed that supports both developers and users in the software release management process. Copyright © 2002 John Wiley & Sons, Ltd.

Distributed software development suffers from limited collaboration capabilities, as developers are unable to easily coordinate their efforts across physical boundaries. Different fields, such as CSCW and groupware, have attempted to bridge this gap, but few of the approaches developed so far have been incorporated in current software development environments. Configuration management (CM) systems are vital to any software development process, support distributed development, and are in widespread use. Unfortunately, they have only limited support for distributed collaboration. We describe Palantir, a system that is aimed at bringing collaborative capabilities to distributed development. Palantir builds upon existing CM systems to introduce project awareness to the developer workspace. In particular, Palantir supports close collaboration among developers by visualizing concurrent changes and showing, in real time, the severity and impact of those changes on the developer's workspace.

Research and experimentation in software architectures over the past decade have yielded a plethora of software architecture description languages (ADLs). Continuing innovation indicates that it is reasonable to expect more new ADLs, or at least ADL features. This research process is impeded by the difficulty and cost associated with developing new notations. An architect in need of a unique set of modeling features must either develop a new architecture description language from scratch or undertake the daunting task of modifying an existing language. In either case, it is unavoidable that a significant effort will be expended in building or adapting tools to support the language. To remedy this situation, we have developed an infrastructure for the rapid development of new architecture description languages. Key aspects of the infrastructure are its XML-based modular extension mechanism, its base set of reusable and customizable architectural modeling constructs, and its equally important set of flexible support tools. This paper introduces the infrastructure and demonstrates its value in the context of several real-world applications.

Software configuration management (SCM) is an important discipline in professional software development and maintenance. The importance of SCM has increased as programs have become larger, more complex, and more mission/life-critical. This paper presents a brief summary of a full report that discusses the evolution of SCM technology from the early days of software development to present, and the specific impact university and industrial research has had along the way.

Even though the number and variety of available configuration management systems has grown rapidly in the past few years, the need for new configuration management systems still remains. Driving this need are the emergence of situations requiring highly specialized solutions, the demand for management of artifacts other than traditional source code and the exploration of entirely new research questions in configuration management. Complicating the picture is the trend toward organizational structures that involve personnel working at physically separate sites. We have developed a testbed to support the rapid development of configuration management systems. The testbed separates configuration management repositories (i.e., the stores for versions of artifacts) from configuration management policies (i.e., the procedures, according to which the versions are manipulated) by providing a generic model of a distributed repository and an associated programmatic interface. Specific configuration management policies are programmed as unique extensions to the generic interface, while the underlying distributed repository is reused across different policies. The authors describe the repository model and its interface and present their experience in using a prototype of the testbed, called NUCM, to implement a variety of configuration management systems.

Open Source Software (OSS) has recently become the focus of considerable interest, yet there remains a need for rigorous analytical inquiry into the subject. This workshop seeks to articulate OSS as an SE paradigm and to address the requirements of OSS in terms of methodology & process, tools & enabling technologies, and human resources & project management. Format: Round-Table Discussion. Size: Maximum 40 participants. Position Papers Required. The Workshop Report will be published in a special issue of IEE Proceedings - Software on Open Source Software Engineering, and workshop participants will be encouraged to submit full research papers based on their position papers for possible inclusion in the special issue.

In the world of software development everything evolves. So, then, do software architectures. Unlike source code, for which the use of a configuration management (CM) system is the predominant approach to capturing and managing evolution, approaches to capturing and managing architectural evolution span a wide range of disconnected alternatives. This paper contributes a novel architecture evolution environment, called Mae, which brings together a number of these alternatives. The environment facilitates an incremental design process in which all changes to all architectural elements are integrally captured and related. Key to the environment is a rich system model that combines architectural concepts with those from the field of CM. Not only does this system model form the basis for Mae, but in precisely capturing architectural evolution it also facilitates automated support for several innovative capabilities that rely on the integrated nature of the system model. This paper introduces three of those: the provision of design guidance at the architectural level, the use of specialized software connectors to ensure run-time reliability during component upgrades, and the creation of component-level patches to be applied to deployed system configurations.

Software architecture research focuses on models of software architectures as specified in architecture description languages (ADLs). As research progresses in specific areas of software architectures, more and more architectural information is created. Ideally, this information can be stored in the model. An extensible modeling language is crucial to experimenting with and building tools for novel modeling constructs that arise from evolving research. Traditional ADLs typically support a small set of modeling constructs very well, but adapt to others poorly. XML provides an ideal platform upon which to develop an extensible modeling language for software architectures. Previous XML-based ADLs successfully leveraged XML's large base of off-the-shelf tool support, but did not take advantage of its extensibility. To give software architecture researchers more freedom to explore new possibilities and modeling techniques, while maximizing reuse of tools and modeling constructs, we have developed xADL 2.0, a highly extensible XML-based ADL. xADL 2.0 supports run-time and design time modeling, architecture configuration management and model-based system instantiation. Additionally, xADL 2.0 has a set of extensible infrastructure tools that support the creation, manipulation, and sharing of xADL 2.0 documents.

No abstract available.

Few tools exist to address the post-development activities of configuring, releasing, installing, updating, reconfiguring, and even de-installing a software system. Certainly there is no unified approach for all of these activities, and none that can take full advantage of a wide-area network. The Software Dock represents an architecture for supporting post-development activities in such a setting. It is designed as a system of loosely-coupled, cooperating, distributed components that are bound together by a wide-area messaging and event system. In this paper we describe the Software Dock architecture and discuss the use of a prototype in deploying a complex system.