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.

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.

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.

No abstract available.

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).

The "Girls on the Go: The Mobile Computing College Experience" is a residential summer camp whose aim is to encourage female high school students to attend college, to consider computer science as viable major, and to pursue computing related degrees. The camp content is designed primarily around a user-centered design process, with the students gaining experience in the development of a zoo-themed mobile app. In addition to technical experience, students participate in sessions that educate them on campus life, the admissions process, and more importantly, what a computing-related career may hold for them. The camp was offered in two consecutive summers, with approximately 20 participants in each iteration. In this paper, we compare differences between the two iterations with the intent of identifying both lessons learned and avenues for improving the experience. We investigate whether the camp had an effect on attitudes towards computer science as a major, and on the careers available to computer science graduates. To this end, our analysis revealed a statistically significant effect upon raising awareness of the role of computer scientists and the relevancy of computing for solving real world problems.

Communication skills, including reading, writing, speaking, and teaming, are among the most sought after by employers of recent Computer Science/Software Engineering (CS/SE) graduates. We have been conducting a project that has developed a general framework for program-level integration of communication into CS/SE education. Our framework has been developed through workshops and field evaluation of training materials (and other resources) by faculty from a wide variety of institutions under the guidance of experts in writing and communication across the curriculum. This paper discusses the current state of communication teaching in the CS/SE domain, and presents our framework and experiences for program-wide implementation of communication skills.

The disciplines of requirements engineering (RE) and software architecture (SA) are fundamental to the success of software projects. Even though RE and SA are often considered separately, it has been argued that drawing a line between RE and SA is neither feasible nor reasonable as requirements and architectural design processes impact each other. Requirements are constrained by what is feasible technically and also by time and budget restrictions. On the other hand, feedback from the architecture leads to renegotiating architecturally significant requirements with stakeholders. The topic of bridging RE and SA has been discussed in both the RE and SA communities, but mostly independently. Therefore, the motivation for this ICSE workshop is to bring both communities together in order to identify key issues, explore the state of the art in research and practice, identify emerging trends, and define challenges related to the transition and the relationship between RE and SA.

There is a growing interest in software summarization and tools for automatically producing summaries. Discussions of relevant papers at recent conferences led to the observation that software summarization needs to consider migrating away from ``is this a good summary?" and towards ``is this a useful summary?" As a result, it has been suggested that to judge usefulness, one needs to view the summary through the lens of a particular task. A preliminary investigation of this suggestion was undertaken at the 2013 ICSE workshop NaturaLiSE. Initial results and lessons learned from this investigation support the notion that task plays a significant role and thus should be considered by researchers building and accessing automatic software summarization tools.

In this paper, we describe our experience running "Girls on the Go: The Mobile Computing College Experience." We decided to do a residential summer camp for HS-age girls to achieve two goals: to encourage our campers to attend college and to interest them in computer science as a possible career option. We centered the camp around the design of a zoo-themed research tool where campers designed a mobile application to be used by researchers to document and study animal behavior. Post-camp surveys gave statistically significant results indicating that the camp increased the girls' confidence in performing computer science and understanding what computer scientists did.

The fact that employers regularly list communication skills among their top requirements for graduates of Computer Science programs and that communication skills are specifically included in ABET program outcomes attests to their significance for Computer Science educators. To prepare students, Computer Science programs typically require students to take a course in technical communications or writing intensive courses. A recent trend emerging from the communication specialist suggests that integrating communication skills with content across the Computer Science curriculum is more effective strategy. The three-year NSF-funded CPATH II project (CCF-0939122 and CCF-0939081) "Incorporating Communication Skills into the Computer Science Curriculum" brought together 40 Computer Science educators and communications specialists to develop assignments and communications supports that implement content and communication skills integration. The results are available on the project website (http://cs-comm.lib.muohio.edu/). Computer Science educators who seek to provide graduates of Computer Science programs with excellent communication skills will find this approach relevant and valuable. Those who have developed integrated materials will be encouraged to contribute to the project repository. Those who are interested in increasing the amount of communication taught in their curriculum will be encouraged to adapt assignments from the repository to their needs.

“Incorporating Communication Learning Outcomes Across the Computer Science (CS) and Software Engineering (SE) Curriculum” is an NSF-funded project that aims to identify the communication skills, specifically those involving reading, writing, speaking, and teaming, needed by CS and SE graduates and then determine how these skills can be taught within CS and SE curricula. This paper presents the results of our first two years of studying the programs at Miami University and North Carolina State University to determine the kinds of communication utilized in our courses and how communication is taught and assessed. When looking at student attitudes towards communication our analyses suggest that students do not consider technical (professional) activities such as code reading, writing, and inspections as communication activities, and the same applies to more complex genres such as software testing or design. They also appear to have difficulty relating writing and reading that may take place in the context of the courses to what they might be doing as software engineers and computer scientists once they start working. On the other hand, initial results indicate that our students' communications skills increase steadily throughout their stay in the university. We have also identified potential strategies for improved instruction in communication.

The rationale for a software system captures the designers' and developers' intent behind the decisions made during its development. This information has many potential uses but is typically not captured explicitly. This paper describes an initial investigation into the use of text mining and parsing techniques for identifying rationale from existing documents. Initial results indicate that the use of linguistic features results in better precision but significantly lower recall than using text mining.

To be successful, CS and SE graduates need strong communication skills (writing, speaking, and teaming), particularly within their discipline. Students exercise these skills during their classes but are not always given explicit domain-specific instruction on these skills, instead relying on instruction provided outside the program. CS and SE faculty are not always comfortable in evaluating these aspects of their assignments and are often unhappy with the results. In this workshop we will lead sessions on teaching writing, speaking, and teaming; situating assignments in workplace-scenarios (to motivate students); and writing communication rubrics that convey faculty expectations to students and support evaluation of student work. For more information, see www.muohio.edu/sigcse_workshop11. A laptop is recommended but not mandatory for this workshop.

One way to improve the communication abilities of new software engineering graduates in the workplace is to integrate communication more effectively in the software engineering curriculum. But faculty typically conceive of communication as outside their realm of expertise. Based on the results of an NSF-funded project, we use theories of situated learning and genre to make the case that communication is integral to software engineering and that faculty are in the best position to guide students in becoming better communicators in the field. We identify software engineering genres and show how those genres may be used to integrate communication in the classroom and throughout the curriculum.

Software engineering educators and trainers are acutely aware that software engineering graduates need strong real-world communication abilities. The National Science Foundation is supporting a three-year project in which industry professionals, CS/SE faculty, and communication-across-the-curriculum specialists are collaborating to develop curricula and teaching resources designed to improve communication abilities of CS/SE graduates by integrating communication instruction and assignments with the technical work in courses across the students' four years of study. Our panelists — an industry practitioner, a CS/SE educator, and a communication specialist — will describe what has been learned in the project's first half and invite comments, insights and advice from the audience.

Student attitudes toward courses with heavy workloads vary depending on how they assess the value and difficulty of the material. In computer science, it is challenging to teach software engineering because the course relies heavily on ldquosoft skillsrdquo and also because students view the material as ldquocommon senserdquo and the assignments as ldquobusy work.rdquo In order to change these attitudes, we changed our junior-level software engineering course to incorporate a weekly laboratory session in order to meet two goals: to reinforce topics that students struggled with during earlier offerings and to make the course more ldquohands onrdquo and applied. This modification in course structure resulted in increased student satisfaction with the course and engagement with the material.

Capstone projects are a valuable opportunity for computer science and software engineering students to take what they have learned over the previous three years of their education and apply it to an open-ended project. Some universities offer multiple capstone projects, defined and supervised by different faculty members. Here we describe a set of dimensions that can be used to categorize capstone projects to determine the level of realism, areas of risk, as well as an overall project type. Instructors can use the capstone dimensions and project type in capstone planning to ensure that projects meet the desired course outcomes.

Communication - between humans - remains at the heart of software development. This workshop will serve as a forum for those invested in this topic to articulate challenges and solutions, and to build links for further work.

A completed software product is the end result of many decisions that must be made throughout the development lifecycle. Unfortunately, the rationale for these decisions is usually not captured and is therefore lost. The Software Using RATionale (SEURAT) system integrates with the Eclipse Interactive Development Environment to support rationale capture and use. In addition to presenting the rationale to the developer/maintainer as needed, SEURAT also supports requirements traceability and impact assessment.

An inverted classroom is a teaching environment that mixes the use of technology with hands-on activities. In an inverted classroom, typical in-class lecture time is replaced with laboratory and in-class activities. Outside class time, lectures are delivered over some other medium such as video on-demand. In a three credit hour course for instance, contact hours are spent having students actively engaged in learning activities. Outside of class, students are focused on viewing 3-6 hours of lectures per week. Additional time outside of class is spent completing learning activities. In this paper we present the inverted classroom model in the context of a software engineering curriculum. The paper motivates the use of the inverted classroom and suggests how different courses from the Software Engineering 2004 Model Curriculum Volume can incorporate the use of the inverted classroom. In addition, we present the results of a pilot course that utilized the inverted classroom model at Miami University and describe courses that are currently in process of piloting its use.

Many, if not most, Computer Science programs contain some form of capstone, or senior, project as a key requirement in receiving a bachelor's degree in Computer Science or Software Engineering. One decision that needs to be made is if all the students should be developing versions of the same project or if each project should be different. In this paper we describe how having multiple teams working on the same project can enrich the capstone experience by supporting reflection on the impact the quality of their code and documentation has on the reliability and maintainability of the final product.

Case studies are a common method for teaching professions such as law and business. At Miami University, we use case studies to teach software engineering by holding a "Senior Challenge" as part of our senior-level software engineering course. The goal is to give the students experience studying, analyzing, and proposing solutions to a real-life information-technology related business problem. The Challenge concludes with a presentation of their findings to a jury of industry professionals including some from the company that wrote the case. The Challenge is structured to teach the students how to analyze a business problem for business and technical objectives, how to describe and defend candidate solutions, and how to effectively present their findings both orally and in writing. This is a difficult project that provides students with experience working with real and significant information-technology problems and in understanding the business impact of their technical decisions

For a number of years, members of the artificial intelligence (AI) in design community have studied design rationale (DR), the reasons behind decisions made while designing. A record of what decisions were made, and why, is especially valuable for software maintenance. One reason for this is that the software lifecycle is a long one. Large projects may take years to complete and spend even more time out in the field being used (and maintained). The combination of a long lifecycle and the typically high personnel turnover in the software industry increases the probability that the original designer is unlikely to be available for consultation when problems arise. J. Lee's survey (1997) presents an excellent overview of DR research. There has also been work specific to software design, such as Boehm's WinWin (1994).