Volume IV: What works, what matters, what lasts
Teaching and learning in computer science: Incorporating assessment as a tool against obsolescence
This essay was prepared for the 2002 PKAL Roundtable on the Future, Assessment in the Service of Student Learning.
Computer Science as a discipline, although relatively young, is already a large, rapidly evolving body of knowledge. Driven by the ever-decreasing half-life of technology, computer science educators must continually look for new ways to present content while at the same time realizing that many of the existing technologies face obsolescence in the near future. In addition, the foundations of computer science continue to expand to the point where it is no longer possible to incorporate every new technology into current courses. When new ideas are introduced or complexity is increased, something else must often be taken away in exchange.
The result of this fast-paced change is an opportunity to experiment with alternative models of pedagogy where students take a more active role in learning and the content of what they learn can be driven by their own assumptions about what they need to learn to meet self defined goals. This is in contrast to typical computer science courses that present a topic, work through examples, assign a project incorporating the ideas, assess correctness based on predefined output, and finally administer an exam based on the ideas. The focus of this essay is on experience with a new computer science course that is taught in a very different way. In fact, the course is not so much taught as it is experienced. However, unlike other courses where lack of direction and predefined goals is seen as a negative, this course flourishes in the ambiguity.
A new required course in our computer science major is Software Engineering. The goals of the course are: (1) to provide students with a basic, working knowledge of the state of software engineering as an academic subject including techniques for software construction as well as a heavy focus on evaluation and documentation methodology, and (2) to provide students with an opportunity to learn software engineering by practicing the craft in an environment significantly different than what has been typical of their previous computer science courses.
The entire course is built around a single, large, semester-long, team-oriented software development project, the details of which are specified by each individual group. The instructor provides only a basic guideline as to the types of projects that will be suitable. This is substantially different from the usual computer science project where students tend to work individually on the same problem and problems are predefined with solutions that are based on required output. In this new course, students are given an opportunity to drive the content of their own learning by choosing a project domain containing a problem with no predefined solution. This also means that neither students nor instructor know what will be accomplished before they begin.
An interesting question immediately presents itself: If the assigned problem and solution are not predefined, how does one assess whether the outcome is correct? The answer used in the design of this course was to teach software engineering as an assessment process, a process whereby students analyze and identify the problem, critique and formulate their own solution, and then document the way that they as a group worked to meet that goal. In addition, they evaluate the work of other students as well. The result of this is that students not only learn current technologies necessary to solve their own problem but in addition learn universal techniques that can be applied to any problem. This will be especially useful when current technologies become obsolete and it is necessary for students to become self-learners in the discipline. In other words, it is not the answer that is assessed as much as it is the process by which groups go about attempting to specify the problem and construct their perceived version of the solution.
The required outcomes for the course include a problem statement, three presentations, a documentation binder, group evaluations, peer evaluations, a self evaluation, and a final solution. Two progress reports and one final presentation are subjected to the scrutiny of the entire class where the group is obligated to defend their decisions, assert that their goals are legitimate, and in general convince the rest of the class that they have accomplished their goals. The documentation binder contains a number of written reports designed to record the progress of the project starting with group selection and the problem statement. This binder not only serves as a concrete product of the process but also provides an active record of the learning goals that the students are working to meet. Students must make a daily record of their successes and failures and reflect upon their findings as they proceed.
Peer evaluations were used by each member of the group to assess the other members. In addition, self evaluations were done to help each member think about and address their own place within the group and within the work that was being accomplished. Students realized that there is great difficulty in assessing ones own work in relationship to others, especially when the expectations for each student may be different.
Although almost every computer science course is taught by allowing students to practice and build technology solutions to problems, this course allows students to experience many of those aspects in an environment that they are likely to find themselves in after graduation, an environment where self learning is of great value. A number of "best lessons" can be summarized from this experience:
First, students often set goals that are too lofty and cannot be reached in the context of the semester-long project. Although this causes a degree of frustration, students still give the course high ratings since for the first time they are able to learn the reasons why goals may not be met. In the past this type of internal evaluation was not possible as the students were not part of the initial process for setting learning goals.
Second, students report that they excelled in learning much more than could ever be accomplished in a typical lecture based course. They are motivated by a number of factors including the internal pressures of meeting their own group goals as well as the external expectations of other groups based on the goals that have been published to the public. This management of expectations, both in terms of meeting them and in failure, is a continuing theme.
Third, there is a high degree of observed student satisfaction that perpetuates itself into an ongoing desire to continue the experience. This means that students realize the importance of learning a process when that process can be applied to current as well as future situations. Perhaps the most obvious evidence of this are the number of students who report continued satisfaction with the course content in the years after graduation when technologies have changed, work groups are different, but the need to understand and participate in the evaluation of process remains. In other words, one of the common experiential threads is the ongoing need to be critical of the process one is using to do their work.
Finally, from a teaching and learning perspective, the course definitely places a much stronger focus on learning as students were placed in a situation where active learning is the only way to succeed. This also requires a high degree of self-evaluation in terms of goals and progress toward those goals. Students are seldom given an opportunity to control the content of their own coursework.
This course has succeeded in providing computer science students with a different type of learning opportunity where the role of the instructor is minimized. The way that this is accomplished is through an increased use of student-centered evaluation as a part of the coursework. Students provide the details for all project work that is accomplished but must in turn be willing to evaluate and document the process they utilize as they work toward their group solution. In addition, they must evaluate others who are working on different problems with different experiences. The result is a student who is not only very satisfied but is also prepared to manage the constantly changing discipline they have chosen.