Back to David Coppit's Homepage.
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 the issues. For example, I might ask the question: "If 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 CSci 420 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 a math class like CSci 243 (Discrete Structures of Computer Science), this takes the form of required homework. In CSci 435 (Software Engineering) over half of their effort is expended on a substantial class project. In CSci 780 (Advanced Software Engineering) students must do a project, and then write a publication-quality paper. There really is no substitute for learning by doing.
I believe that my approach to teaching is effective. I get high scores on teaching evaluations and good feedback from my colleagues who visit my classes to evaluate me. About once a year I will hear from a former student who tells me that CSci 435 course was one of the best and most valuable courses that they took at William and Mary.
In the next three sections I discuss the three courses I have taught recently. I present a short overview of the course, as well as innovative methods that I use to teach the course. I also discuss my past performance and future plans. I do not discuss other courses I have taught such as discrete structures (CSci 243), undergraduate individual studies (CSci 420) and graduate reading courses (CSci 690).
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.
The primary 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. 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. Finally, graduate students in the cross-listed course must be integrated effectively into 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. Work tasks are entered into the system by managers (graduate students), and assigned a priority and difficulty. Undergraduate developers then assign the tasks to themselves, perform the work, and then set the task status to "Waiting for Manager". A manager then verifies the work and closes the task. Importantly, when the task is closed the student earns project points. Individuals are then evaluated based on their progress toward completing their share of the total points for the project. Students can determine their performance at any time from a report which is automatically generated by the task management 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 [1, 2]. I have also 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 is being adopted at other institutions, such as Simon Fraser University and the U.S. Naval Academy.
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. Instead, 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 and discuss papers, and practice presenting them. Later in the semester the teams provide project status reports, and finally write a paper for the "CSci 780 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 Will Thomasson and Rob McGregor, was independently completed and published at ICSE in the same year by a top software engineering researcher. Research done by Meghan Revelle and Tiffany Broadbent in the Fall of 2004 was published at the International Workshop on Program Comprehension [3].
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. A significant portion of 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 are a selection of research papers and accident reports. These papers 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.
My aim in this course is to demonstrate that formal methods can be applied effectively with a modest amount of training. This is an interesting course because it takes advantage of a recent change in philosophy in the formal methods community. In the past researchers developed formal methods that were very powerful but difficult for practitioners to adopt. Recent advances in languages such as Alloy and JML, and in tools such as Java Pathfinder and ESC/Java2 show that much can be gained from less sound but more practical approaches.
[1] David Coppit and Jennifer M. Haddox-Schatz. Large team projects in software engineering courses. In Proceedings of the 36th ACM Technical Symposium on Computer Science Education, pages 137-141, St. Louis, Missouri, 23-27 February 2005.
[2] David Coppit. Implementing Large Projects in Software Engineering Courses. Computer Science Education, 16(1):53-73, March 2006.
[3] Meghan Revelle, Tiffany Broadbent, and David Coppit. Understanding Concerns in Software: Insights Gained from Two Case Studies. In Proceedings of 13th IEEE International Workshop on Program Comprehension, pages 23-32, St. Louis, Missouri, 15-16 May 2005.
Back to David Coppit's Homepage.
Last changed May 21 2007 18:28:43.
David Coppit,
coppit@cs.wm.edu
There have been 1036141 hits since Thu Jun 9 14:49:55 2005