David Coppit

Teaching Statement

Teaching Philosophy

My teaching philosophy is based on two theories about how people learn. First, people learn best by building relationships between new information and their existing body of knowledge. Such relationships provide the context that helps the student understand the deeper meaning behind the facts, and cause the information to acquire a degree of relevance. Second, students must be active participants in the learning process, learning by doing instead of learning by listening. By applying their new knowledge to non-trivial problems, students improve their retention of the knowledge and expand their set of skills.

I employ a number of teaching techniques as a result of this overall philosophy. During lectures, I ask Socratic "quick questions" in order to keep students engaged. Most of the time, these questions force students to relate the current topic to previous lecture material or topics outside of the subject area. Similarly, my exam questions require students to think deeply about technical and nontechnical issues. For example, I might ask the question: "If even hair stylists are licensed by the state, should software engineers be as well?" To answer this question, students must relate the current state of software engineering practice to the hallmarks and requirements of licensed professions in general.

In order to keep lecture material relevant to students, I immediately follow the presentation of abstract concepts with concrete examples or case studies. I believe that this helps students maintain the context for the material they are learning. For example, I will introduce a software tool with a live in-class demonstration. While such demonstrations are notorious for failing, I believe that the additional effort required to ensure their success is worth the pedagogical benefits. For instance, in my recent course in formal methods, I grounded abstract discussions in theorem proving and model checking with daily use of software tools such as PVS, the Alloy Analyzer, Java Pathfinder, and ESC/Java.

I also expect students to devote a significant amount of time outside of class applying the material I teach in lectures. In undergraduate Software Engineering over half of their effort is expended on a substantial class project. In graduate Advanced Software Engineering students must do a project, and then write a publication-quality paper. There really is no substitute for learning by doing.

The table below summarizes my teaching evaluations relative to the rest of the department. I have included the data on the most important questions. My courses have evaluated near or above the departmental average. According to the department chair, I am considered to be one of the better educators in the William and Mary Computer Science Department. I will discuss these scores in more detail in the next few sections.

Course Sem 8 9 10 11 14 Software Engineering Evals Spr 03 4.3 4.6 4.6 3.8 3.5 Dept Avg Spr 03 4.4 4.4 4.6 4.0 3.6 Evals Spr 04 4.6 4.8 4.5 3.6 4.1 Dept Avg Spr 04 4.4 4.5 4.6 4.1 3.6 Evals Spr 05 3.00 4.00 3.85 2.92 4.00 Dept Avg Spr 05 4.25 4.45 4.52 3.95 3.45 Evals Spr 06 4.75 4.88 4.75 4.50 4.00 Dept Avg Spr 06 4.19 4.33 4.44 3.81 3.49 Evals Spr 07 4.67 4.75 4.58 4.25 3.75 Dept Avg Spr 07 4.24 4.26 4.41 3.89 3.45		Course Semester 8 9 10 11 14 Software Dev. with Formal Methods Evals Fall 05 4.29 4.43 4.43 4.14 4.00 Dept Avg Fall 05 4.25 4.37 4.51 3.99 3.50 Advanced Software Engineering Evals Fall 03 4.8 4.6 4.7 4.3 3.7 Dept Avg Fall 03 4.4 4.5 4.7 4.1 3.8 Evals Fall 04 3.75 4.00 4.00 3.50 2.50 Dept Avg Fall 04 4.26 4.45 4.50 4.01 3.51 Evals Fall 06 4.33 3.33 3.67 3.33 3.33 Dept Avg Fall 06 4.43 4.43 4.57 3.97 3.64
8: Instructor receptive to questions and approachable for help? 9: Was the instructor prepared for class? 10: How well did the instructor know the subject material? 11: Rate the overall effectiveness of the instructor? 14: Rate course difficulty compared to other W&M courses?

The next three sections discuss three courses I have taught recently. I conclude with a self-evaluation and my future goals. I omit discussion of discrete math (which I only taught once), readings courses, and independent studies (which typically involve only a few students).

Software Engineering

This course introduces students to the field of software engineering. It highlights the problems associated with software development projects, and introduces processes, tools, and techniques for addressing them. Over half of the course is devoted to the development of a large software project. This is the primary course that I have taught at William and Mary.

The key challenge in a course like this is how to effectively provide students with experience in real-world software development, given the limitations of an academic setting. Traditional approaches have students work in groups of four on a similar project. Groups of four are better than single developers, but small teams clearly can not expose the kinds of challenges that arise when many people collaborate on a single large project. I firmly believe that students must encounter the difficulties associated with software whose complexity is beyond the ability of a single person to fully understand. Larger teams also provide more opportunity to encounter personnel difficulties that are at the root of collaborative software development. As a result, I have my students work as a single team (composed of subteams) on a large project. Examples of past projects include a multi-player turn-based strategy game, a traffic simulator, and a 3D billiards game.

The "large team" approach is recognized as pedagogically effective, but is rarely employed by educators. First, it typically requires a large amount of managerial effort on the part of the instructor. Second, it is difficult to evaluate the contributions of individual students on a large project. Third, there is a tension between providing all students with essential software engineering experiences, while also allowing them to work independently on different aspects of the project.

Over the last few years I have developed an innovative approach to teaching the "large team" model of software engineering courses. The centerpiece for this approach is a web-based work management system that I developed for the course. Students track work and collaborate around tasks that are entered into the system. Student-managers ensure that tasks are entered and completed, and developers self-organize to complete the tasks. The entire system is quantitative, so that students can determine their performance at any time from a report which is automatically generated by the system.

To ensure that all students experience essential aspects of software development, homework assignments are designed around the course project. For example, all students develop a requirements document, use cases, a detailed design, a formal specification, and a test plan. From each assignment, the best elements are combined to create the official document used by the project for the remainder of the semester.

This approach is both novel and effective. I have published two papers on the approach, and have developed a website for instructors wishing to teach software engineering in this manner (http://www.cs.wm.edu/~coppit/se-for-educators/). Importantly, my approach has been adopted at other institutions, such as Simon Fraser University and the U.S. Naval Academy.

My evaluations have steadily improved over the years as I have developed my approach for the course. In recent years I have significantly outperformed the departmental average, despite the fact that the students report working harder in this course than others. I have gotten several unsolicited emails from former students saying that this course is the most useful that the students took while at William and Mary.

The one outlier to this trend are the evaluations for Spring 2005. In this year I had the students evaluate the course the day after giving them all a particularly low grade on part of the project. It was my fault for not making my expectations clear, and I didn't allow enough time for the students to gain some perspective. (The average and median grade that semester was an 87.)

Advanced Software Engineering

This graduate course uses research papers to present recent research in software engineering, as well as some seminal work. At the graduate level, I assume that students understand how to develop good software. I expose students to cutting-edge research in the context of a project that teaches them how to identify and perform good research in software engineering.

The entire course is taught as a small research effort in which students work in pairs. Students scan the semester's papers early on, and write a proposal for the work they plan to do. I then work with them to refine the proposal. During the semester, students read, present, and discuss papers. Later in the semester the teams provide project status reports, and finally write a paper for the "Advanced Software Engineering Symposium." Students refine their papers based on feedback from each other and myself. The final versions are published in a proceedings. The exam period is the symposium itself, in which the teams present their papers.

I believe that this approach not only exposes students to cutting edge research, but also provides them with more in-depth experience with a specific research area via the class project. Students report that they enjoy learning "the research process" as well as the software engineering material. Although students are not always able to produce original research results, they are very close to the most recent advances in the field. For example, in 2003 research in a paper written by two students was independently completed and published at ICSE in the same year by a top software engineering researcher. Two students in the Fall 2004 course published their work at the International Workshop on Program Comprehension.

Formal Methods in Software Engineering

This is a new course that I developed and taught for the first time in the fall of 2006. A primary goal of the course is to introduce students to rigorous, mathematically-based techniques and tools for the development of software. Because of the heavy use of mathematics, the course begins with a review of discrete mathematics, logic, and proofs. The first part of the semester is spent on manual verification of software. This is difficult for undergraduates, but serves to both sharpen their mathematics skills and to motivate the automated techniques I present in the rest of the course.

The remainder of the course introduces students to a number of exciting developments in formal methods in the past decade. Rather than leaving the course at the level of "impractical math," I ground each of the areas of formal methods in tools that the students use to complete homework assignments and a class project. For example, we use PVS for the segment on theorem proving, the Alloy constraint analyzer for model checking, Java Pathfinder for software model checking, and ESC/Java2 for software theorem proving. The students use these tools to write and validate specifications of software systems, or to verify the correctness of Java implementations.

A key element of the course is a selection of accident reports that help to motivate the need for formal methods in software development. Examples of accidents we discuss are the Therac-25 radiation overdoses, the loss of the Mars Climate Orbiter, and the Patriot missile failure during the first Gulf War. The students reported that these often disturbing accounts provided a new perspective on their role as software developers for such systems.

I was pleasantly surprised by the course evaluations, in which I outperformed the department average in almost every category. I expected a new course to have "rough edges" that would be reflected in the evaluations. As in my undergraduate software engineering class, the scores were high despite the reportedly higher workload.

Future Goals

Overall, each course that I teach requires a different strategy, and I continue to refine my approach as I teach it. For example, in the undergraduate software engineering course, I would like to incorporate more software maintenance and quality issues. At the graduate level, I have replace some technical papers with accident reports and management readings in order to reduce the workload per student, since classes often have only a few graduates. I feel that my Software Development with Formal Methods course was a good success, and I hope to have the opportunity to teach it again.

I also hope to broaden the span of courses I teach. I would like to teach discrete math again, and to also teach courses such as programming languages, data structures, algorithms, compilers, operating systems, and the introductory programming sequence. I feel strongly that with adequate time to prepare professors should be able to teach any course in an undergraduate computer science curriculum effectively.

I also have an interest in more specialized courses. For example, I would like to teach a broad-based non-major course aimed at recruiting students into the major. The strategy I would employ would be to identify real-world computing issues and use them to motivate discussions of computing topics. I'm also interested in courses to bridge the gap between leaning programming syntax and large-scale software engineering. I helped to design a course in advanced programming at William and Mary but have not had the opportunity to teach it.

More generally, I am interested in the design of undergraduate curricula. I find issues such as how to teach software design, how to incorporate mathematics in CS curricula, reconciling the teaching of pointers with a Java-based course sequence, and the role of traditional courses such as compiler design to be very interesting. But I also realize that I have much to learn in this regard, and look forward to working with my peers to improve computer science education.