In our CS1 course, we found that students were failing at a rate similar to that reported in literature. In an effort to improve this DFW rate, we made a few changes to the course. While the changes led to some improvement, the results were not as significant as we expected. We found that in our CS1 course, first-semester students were passing at a significantly higher rate than non-first-semester students. Upon looking at other STEM and non-STEM courses at the university, we noted that the institution's first term calculus and introductory English courses had similar patterns, however the introductory sociology course did not. Further data analyses challenged several other of our beliefs about who was failing the course. Our findings leave us with several questions. Is this pattern specific to our university? Is this a particular course problem? From the perspective of the discipline, is there something in this data that points to a set of problems for computing education researchers to consider? This poster serves as both a presentation of our initial experiential results and an attempt to start a conversation amongst community members around whom actually is struggling within our early CS courses.

In our CS1 course, we found that students were failing at a rate similar to that reported in literature. In an effort to improve this DFW rate, we made a few changes to the course. While the changes led to some improvement, the results were not as significant as we expected. We found that in our CS1 course, first-semester students were passing at a significantly higher rate than non-first-semester students. Upon looking at other STEM and non-STEM courses at the university, we noted that the institution's first term calculus and introductory English courses had similar patterns, however the introductory sociology course did not. Further data analyses challenged several other of our beliefs about who was failing the course. Our findings leave us with several questions. Is this pattern specific to our university? Is this a particular course problem? From the perspective of the discipline, is there something in this data that points to a set of problems for computing education researchers to consider? This poster serves as both a presentation of our initial experiential results and an attempt to start a conversation amongst community members around whom actually is struggling within our early CS courses.

NOTE: The first page of text has been automatically extracted and included below in lieu of an abstract Main Menu Session 3129 Course Management Systems: Expectations and Outcomes Debra T. Burhans1, Carl Alphonce2, Helene Kershner3, Barbara Sherman 4, Deborah Walters5 1 Canisius College/ 2,3,4,5University at Buffalo (SUNY) In the 1999-2000 academic year, an ambitious overhaul of a large, introductory computer literacy course at the University at Buffalo (SUNY) was initiated with the help of a grant from the Pew Learning and Technology Program1. This course enrolls approximately 1200 students per year, divided into lecture sections of 200 and laboratory sections of 20-40 students. With the help of on-line and LAN-based technologies for teaching, testing, and course management, we transformed the course from a traditional lecture format with short, unstructured laboratory meetings to a more student-centered model with fewer lectures and more structured laboratory experiences. While this course is not specifically targeted towards science and engineering students, the issues addressed herein are of interest to all educators who use or are considering using a course management system. Faculty for the course are technology-savvy computer scientists whose familiarity with computing technology influences their expectations regarding content and performance of off-the-shelf educational technology products. Specifically, expectations with regard to the course included the following: · A course management system (CMS) would decrease time spent on course administration. · Grading time would be reduced by shifting to on-line and web-based training and assessment tools. The CMS would facilitate on-line grade maintenance. · Lecture time would decrease due to the use of interactive, on-line tutorials for topics that have proven difficult to cover in lecture. These interactive materials would be integrated into the CMS. · As a result of the above-mentioned technologies, there would be a cost savings in faculty time and lab assistant expenses that could be recouped by the department (dollars) and by the faculty members involved in the course (more time for research). There were positive outcomes related to the incorporation of technology materials into the course, including a measurable increase in student learning and satisfaction as well as cost savings for the department. However, there were also a number of negative outcomes. Administrative time spent on the course increased considerably, and grading time did not decrease. In addition, troubleshooting computer-related glitches, including problems such as network bottlenecks, software performance, and inability of different pieces of software to communicate with one another, required much more faculty time than anticipated. The expectation that the CMS would allow for coordination and integration of different on-line resources was not realized. While there have been a number of studies of the impact of technology on student learning and outcomes, our focus is on the faculty perspective of teaching with technology. Our experiences using on-line materials including a CMS in a large undergraduate course have led to the identification of a number of factors that influence the effectiveness of computer-based educational technologies. These findings should prove valuable Proceedings of the 2002 American Society for Engineering Education Annual Conference & Exposition Copyright Ó 2002, American Society for Engineering Education Main Menu

This work in progress introduces cross-course collaborative, project-based learning, or C 3 PBL. C 3 PBL builds on established collaborative project-based learning ideas that have been shown to improve retention at various institutions, by introducing collaboration that spans multiple courses in the same term. We discuss how such a collaboration between students in different courses can change the undergraduate educational experience to improve retention, community, and self-confidence. For our work we are focusing on a curriculum based approach, leveraging collaborative project-based learning experiences to affect the mindset and culture of our department. We present lessons learned from an initial pilot of C 3 PBL deployed over two semesters. The pilot looks at the pairing of introductory level courses with an upper level software engineering class. The collaboration is centered on the idea of experienced students in the upper level software engineering course working with novice students from the introductory courses. The logistics explored has lead to more meaningful interaction and assessment in the second semester offering of C 3 PBL.

Following quickly on the heels of the 50th anniversary of the formation of SIGCSE (the organization), we find ourselves preparing to celebrate the 50th SIGCSE Technical Symposium, SIGCSE 2019. SIGCSE 2019 will be held February 27 -- March 2, 2019 in Minneapolis, Minnesota.

Computer programming is a process. Successful programming involves incrementally building and testing a solution. Students' ability to program is typically determined by an assessment of the end-product of a programming session rather than an examination of the actual process students are engaged in. A prerequisite to assessing a student's programming process is having access to that process. While direct one-on-one observation of students while they code has the potential to yield high-quality data, it does not scale well to large classes. One scalable approach is to automatically capture edit events through IDE instrumentation, and programmatically assess the resulting data. In this poster we report on our work to date in developing and deploying a plug-in for Eclipse's Java Development Tools (JDT), explore the data we have collected to date, compare our results with those reported in previous work, and discuss possible directions for future work in using this data for assessment of students' programming process.

Memphis, Tennessee, home of Graceland, Sun Studios, the National Civil Rights Museum, and, of course, the Peabody ducks, sits on the banks of the Mississippi river. Like the mighty Mississippi, which combines the waters of hundreds of tributaries in one massive flow that nourishes countless souls with its rich waters, so the SIGCSE Technical Symposium gathers ideas, techniques, tools and more to engage, energize and empower computer science educators from far and wide. Just a few steps from the river of so many tales and songs, the 2016 SIGCSE Symposium promises to be an event to remember. Alongside the usual offering of papers, panels, special sessions, workshops, birds-of-a-feather (BOFs), posters, lightning talks and demos, there is an assortment of pre-symposium and affiliated events, including the student research competition and talks by our marvelous lineup of keynote and plenary speakers. Our exhibit hall will feature both familiar faces and newcomers and will provide valuable information and resources for computer science education.

Feedback serves a critical role in the learning process. For formative assessment to be effective in supporting a student's learning, feedback must be provided in a timely fashion (so a student can derive benefit while engaging in the learning activity), it must be consistent across multiple submissions of the same student as well as across submissions by different students, and it must be of high quality (i.e. it must give students guidance as to how to improve their submission). In this poster we present a small library of Java classes which aid the writing automated tests for assessing the design of student programming exercises. Through its use of reflection we can allow more free-form assignments, and can provide feedback on both program functionality and design.

Modeling is a key skill in software development. The ability to develop, manipulate and understand models for software is therefore an important learning objective in many CS/SE courses. In this working group, we investigated how and when (software) modeling is taught to help us better understand the key issues in teaching (software) modeling. Several shortcomings were found in common curricula, both in their understanding of the term \modeling" and in how they address its teaching. This WG report summarizes the findings and formulates recommendations on the inclusion of software modeling courses in future CS/SE curricula.

The "Killer Examples" series of workshops are highly interactive workshops which have been an annual occurrence at OOPSLA since 2002. The goals of the workshop are to bring together educators and developers to share their object-oriented expertise, and to provide a forum for discussion of teaching techniques and pedagogical goals. The theme of last year's workshop was pedagogically sound examples for object orientation; this year's workshop continues that theme, but rather than focusing on examples that demonstrate sound object-oriented design, it will focus on examples that expose bad practice and so lead to better appreciation of good practice, as obtained by following sound object-oriented principles. In this year's workshop we focus on the use of examples that expose bad practice. Students, when presented with good (killer) solutions to problems, can appreciate how the solutions incorporate sound OO principles, but they may not understand what is wrong with alternative solutions that also appear good to them. It is important that students learn how to look at a bad solution to a problem and critique it with regard to standard OO principles, such as Law of Demeter or the Liskov Substitution Principle. Skill at critiquing bad code is valuable in code reviews and in other situations involving reviews of existing or proposed solutions to problems. Good examples that demonstrate bad practice can be as simple as a section of code with a poorly named variable that misleads the reader regarding the behavior of the code. Alternatively, a good example might be one that looks to be well-designed at good at first glance, but demonstrates fragility when changes are attempted. Another example might consist of an inappropriate application of a design pattern. Also, a large method that can easily be refactored using the Extract Method refactoring could be another example. Some examples could demonstrate several bad practices, and so require a series of design changes or transformations in order to be converted into a good solution. In our workshop, participants discussed examples exposing bad practice that they have seen or used in their teaching, whether it be in a traditional classroom or in an industry training setting. Such examples are often found in students' solutions to problems or in existing code bases in industrial applications. This poster reports on the outcome of this year's full-day workshop, held at OOPSLA on Sunday,October 25.

Examples are crucial for helping students learn new ideas. In an objects-first curriculum, the objects presented by the instructor play a key role in motivating and explaining an object-oriented approach. We know the example of a Program class with a HelloWorld() method is a bad choice. So what are good examples of objects for beginning CS students? For non-majors? What are good examples of objects for teaching conditional logic? Looping? Composition? Inheritance? In this session, 00 educators present examples of objects successfully used in their CS0 and CS1 classes. Significant time will be made available for discussion of the examples.

The Killer Examples workshops are highly interactive workshops, held annually at OOPSLA since 2002. The workshop goals are to bring together educators and developers to share their object-oriented expertise, and provide a forum for discussion of teaching techniques and pedagogical goals. The theme of last year's workshop was process in the pedagogy of object orientation; the theme of this year's workshop is pedagogically sound examples for object orientation: examples which are structured to support student learning. The workshop solicits examples which can be used in the teaching of object orientation. Submitters present their examples at the workshop; participants in the workshop will critique the examples and actively engage in refining the examples in a way that they support a clear and sound pedagogy. The workshop accepts walk-ins if space permits and walk-ins are determined to have adequate interest and background in the workshop theme to contribute positively to the discussions.

This year's theme of the 'killer examples' workshop is 'worked examples'; examples, emphasizing OO principles, that can be started in the classroom and then finished by the students on their own. The poster will summarize the workshop results and offer the OOPSLA community a forum for the exchange of experiences.

Green is a live round tripping UML class diagram editor plug-in for Eclipse, originally designed with the intention of focusing CS1/CS2 students on modeling and design. Green's ease of use and flexible features has allowed it to grow into a robust tool providing end users with an easy to use application satisfying their individual class diagramming needs. Green's live round-tripping capability allows users to generate (Java) code from UML class diagrams and generate diagrams from (Java) code and have them both update each other as any changes are made. This demo will demonstrate the main features of Green, including forward and reverse engineering, live round-tripping, incremental exploration, and the various aspects of relationship semantics. Since Green is an ongoing project, demonstrations of additional features not in this list may also be included.

Giving students an appreciation of the benefits of using design patterns and an ability to use them effectively in developing code presents several interesting pedagogical challenges. This paper discusses pedagogical lessons learned at the "Killer Examples" for Design Patterns and Objects First series of workshops held at the Object Oriented Programming, Systems, Languages and Applications (OOPSLA) conference over the past four years. It also showcases three "killer examples" which can be used to support the teaching of design patterns.

The "Killer Examples" series of workshops are highly interactive workshops which have been an annual occurrence at OOPSLA since 2002. The goals of the workshops are to bring together educators and developers to share their object-oriented expertise, and to provide a forum for discussion of teaching techniques and pedagogical goals. The theme of last year's workshop was design patterns; the the theme of this year's workshop is process : for teaching, learning and programming. While there is a formal application procedure to guarantee admission to the workshop, we accept walk-ins if space permits and the walk-ins have adequate interest and background to be able to contribute positively to the discussions.