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.

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.

In recent years, Judea Pearl, winner of the 2011 Turing Award, developed a fundamentally new theory of inference in causal networks. Our goal is to show how Pearl’s concepts of causal networks and the do-calculus can be used to model intervention in design, i.e. the generation, evaluation, and choosing of design alternatives. Design projects typically feature many episodes in which design alternatives are generated, evaluated and chosen. Using Pearl’s models to support this process requires three extensions to his representation: using signed graphs to indicate when a design feature causes an effect vs. prevents one, using two variants on Pearl’s “do operator” to differentiate between evaluating a design choice vs. making one, and explicitly representing design alternatives. These extensions to Pearl’s causal models allow them to be used to support the design process by aiding decision-making as well as serving as rationale for the design.

Meetings have always been a significant part of working life and software development is no exception, with meetings of all kinds taking place daily. One type of meeting that is critical to software development that has not been widely studied to date is the recurring software maintenance meeting: a regularly scheduled meeting during which the primary product leads consider emerging issues and new directions for an already deployed and functioning software system. In this paper, we describe preliminary results of our ongoing analysis of ten consecutive recurring maintenance meetings of the architecture committee of a major healthcare software company. The results provide a foundation for further analysis in terms of first building a categorization of the kinds of discussions that take place. We present the setting, our approach to analysis, and preliminary observations. A primary outcome is that the kinds of discussions are much more varied than one might have initially expected.

In software design, the various stakeholders generate large numbers of heterogeneous artifacts. These artifacts are often developed in, and managed by, different tools. In this paper, we present our initial prototype of Linecept, a tool that helps stakeholders organize, find, and view disparate design artifacts by organizing them on a timeline that presents a single unified view of the artifacts and who created them. We have used Linecept to retrospectively capture design artifacts for its own creation and in a software design class.

In software design, the various stakeholders generate large numbers of heterogeneous artifacts. These artifacts are often developed in, and managed by, different tools. In this paper, we present our initial prototype of Linecept, a tool that helps stakeholders organize, find, and view disparate design artifacts by organizing them on a timeline that presents a single unified view of the artifacts and who created them. We have used Linecept to retrospectively capture design artifacts for its own creation and in a software design class.

At its heart, design is a decision-making process. These decisions, and the reasons for making them, comprise the design rationale (DR) for the designed artifact. If available, DR provides a comprehensive record of the reasoning behind the decisions made during the design. Unfortunately, while this information is potentially quite valuable, it is usually not explicitly captured. Instead, it is often buried in other design and development artifacts. In this paper, we study how to identify rationale from text documents, specifically software bug reports and design discussion transcripts. The method we examined is statistical text mining where a model is built to use document features to classify sentences. Choosing which features are most likely to be good predictors is important. We studied two evolutionary algorithms to optimize feature selection - ant colony optimization and genetic algorithms. We found that for many types of rationale, models built with an optimized feature set outperformed those built using all the document features.

Design rationale (DR), the reasons behind decisions made during design, can provide valuable insights into the decision-making process. This is especially valuable in software development, where systems are frequently repaired and extended over their lifetime.

Non-functional Requirements (NFRs) play a unique role in the development of any software-intensive system. They often have a significant impact upon the architectural design and drive critical trade-offs. However, such trade-off decisions are often based on assumptions about future workloads, environmental factors, and anticipated system behavior. From a traceability perspective, it is thus necessary to trace individual NFRs into the design and their associated design rationales, and further forward into the running system in order to monitor and assess the design-time assumptions at runtime. When runtime data indicates that a mismatch has occurred that adversely impacts system performance and/or behavior, measures need to be taken, such as applying critical bug fixes, or refactoring performance bottlenecks. In this paper, we explore five different types of NFRs across the design and runtime phases of the development process. Our approach is illustrated by examples from the Dronology System for Fault Tolerance, Security, Usability, Performance, and other critical qualities.

Many universities either have offered or are starting to offer computer science courses taught in a compressed time scale, often where students take only one course at a time. The pace of these classes can differ but often move at a speed where a day of an accelerated class is equivalent to a week of a typical semester class. This format has several advantages-more flexibility for collaborative work, better visibility into how students are spending their time (knowing that if a student is struggling it is not because of work in a different class), and less need for students to multitask between different courses. It also has many challenges. From the student perspective, there's the need to stay on top of things and not fall behind, having to catch up if there are absences due to illness or extra-curricular activities, and staying focused on one subject while working under constant time pressure (which often results in a tendency to rush through assignments to meet deadlines). Participants in this BoF will share their knowledge about teaching in this format. What kinds of assignments and assessments work and don't work during accelerated courses? How can we keep the workload reasonable for the students and for ourselves? What interesting pedagogy does this format facilitate? We invite participation both from faculty who are already teaching in this format and also from those considering an accelerated course who want to learn more about the advantages and disadvantages of this format.

One of the challenges in using statistical machine learning for text mining is coming up with the right set of text features. We have developed a system that uses genetic algorithms (GAs) to evaluate candidate feature sets to classify sentences in a document. We have applied this tool to find design rationale (the reasons behind design decisions) in two different datasets to evaluate our approach for finding rationale and to see how features might differ for the same classification target in different types of data. We used Chrome bug reports and transcripts of design sessions. We found that we were able to get results with less overfitting by using a smaller set of features common to the set optimized for each document type.

Abstract More than 40 years after Rittel and Webber published the first articles on the theory of wicked problems this theory has been applied to a wide range of fields involved in real-world problem solving. Interest in the theory seems greater than ever. This has led to an interest in rethinking the theory. A number of authors do this by imposing interpretations on the theory that are incompatible with each other and with the statements of the theory's authors. We agree that it is time to critically reexamine the theory and rethink what implications it has for design. However, rather than imposing an incompatible interpretation, our approach is see what new conclusions can be drawn from a systematic and critical examination of what Rittel and Webber actually said. This reexamination of their specific claims and arguments is what we call untangling wicked problems. From this untangling, we derive new conclusions about how designers should tackle wicked problems and how design rationale can aid them in doing so.

Decision-making is central to software development. Most problems do not have straightforward solutions but instead require assessing and evaluating multiple candidate solutions depending on the requirements (functional and non-functional) for the specific project. Real problems may have more than one valid solution and software engineering students need to be able to synthesize design alternatives and reason about them to make the best decision for the specific problem under consideration. The work described here uses a web-based system to administer rationale-based assignments where the students are required to explicitly present their rationale for a series of decisions and use the capabilities of the tool to justify their choices. Students using the tool report that it helped them consider more alternatives and put more thought into their decision-making process.

The Computer Science and Software Engineering (CS/SE) profession reports that new college graduates lack the communication skills needed for personal and organizational success. Many CS/SE faculty may omit communication instruction from their courses because they do not want to reduce technical content. We experimented in a software-engineering-intensive second-semester programming course with strategies for improving students' writing of black box test plans that included no instruction on writing the plans beyond the standard lecture on testing. The treatment version of the course used 1) a modified assignment that focused on the plan's readers, 2) a model plan students could consult online, and 3) a modified grading rubric that identified the readers' needs. Three external raters found that students in the treatment sections outperformed students in the control sections on writing for five of nine criteria on rubrics for evaluating the plans and on the raters' holistic impression of the students' technical and communication abilities from the perspectives of a manager and a tester.

There has been significant interest in MOOCs, both inside and outside the educational community. Some of this interest focuses on how they could be used to replace traditional brick-and-mortar education while others are interested in using them to supplement more traditional courses. Instructors can also use MOOCs to gain new insight into teaching and learning by taking on a student perspective. This paper describes how taking several MOOCs has given me a better understanding of student motivation, time commitment issues, and student perception of grading and describes how I am feeding this knowledge back into my own courses.

Software development and maintenance require making many decisions over the lifetime of the software. The decision problems, alternative solutions, and the arguments for and against these solutions comprise the system’s rationale. This information is potentially valuable as a record of the developer and maintainers’ intent. Unfortunately, this information is not explicitly captured in a structured form that can be easily analyzed. Still, while rationale is not explicitly captured, that does not mean that rationale is not captured at all—decisions are documented in many ways throughout the development process. This paper tackles the issue of extracting rationale from text by describing a mechanism for using two existing tools, GATE (General Architecture for Text Engineering) and WEKA (Waikato Environment for Knowledge Analysis) to build classification models for text mining of rationale. We used this mechanism to evaluate different combinations of text features and machine learning algorithms to extract rationale from Chrome bug reports. Our results are comparable in accuracy to those obtained by human annotators.

One way that errors can be introduced into software decisions is when the people designing and implementing the system make poor decisions either because they failed to consider the relevant criteria or because decisions were based on incorrect assumptions. Rationale management systems can be used to support and monitor the decision-making process and can help detect or even avoid some forms of decision-making error.

Computer science instructors are incorporating Massive Open Online Courses (MOOCs), and MOOC material, into their campus courses. The closed instance is the dominant model being followed, in which MOOC material (e.g., in AI, in Programming Languages, in Software Engineering) is ported to a protected LMS so that campus students can use the MOOC video and other material (e.g., assessments) and infrastructure (e.g., autograders) in a "private" manner. In an embedded instance, campus students take a live MOOC as one component of their on-campus course. Another model, albeit nascent, is to exploit self-paced open online courses so that campus cohorts can move through a course when a campus instructor wants, and at a pace the instructor wants, but still availing campus students to the advantages of interacting with global students (and vice versa). The BoF session will allow participants to talk about MOOC-based blended models, form a group interested to archiving experience, synthesizing best practices, creating shared learning-object repositories (e.g., of active learning, in-class activities), and to discuss issues of policy (e.g., FERPA).

Horst Rittel defined his wicked problems theory to differentiate wicked problems, which are open-ended and controversial, from tame problems, which have a single correct solution. Rittel identified ten properties of wicked problems but did not indicate if all of these properties needed to hold before something could be deemed wicked. Failure to correctly classify a problem as wicked is likely to result in either design failure (if wickedness is not identified and problems are tamed prematurely) or design paralysis (if incorrectly perceived wickedness is used as an excuse for not buckling down to do the work of identifying and implementing solutions). Here we augment Rittel’s theory by identifying ten causes of wickedness and describe how those can be used along with his ten properties to identify wicked problems in cases where not all of his properties apply.

No abstract available.